라이브러리는 오류를 기록할까, 애플리케이션에 전파할까

오류를 어디에서 기록해야 할까? 이 토론을 시작한 개발자의 익숙한 가정은 이랬어. 애플리케이션은 오류를 기록하고 돌려주고, 라이브러리는 오류를 돌려준다는 거야.¹

그런데 그는 여러 생태계에서 라이브러리가 로그를 남기고, 그 로그를 조용하게 만드는 일이 중요한 작업이 되기도 한다는 걸 알게 됐어. 그래서 라이브러리가 오류를 전파하는 대신 직접 기록하는 경우에는 어떤 작업 흐름이 필요한지 물었지.¹

로그와 오류는 무엇이 다를까

질문자는 Go의 slog를 만드는 과정에서도 이 문제가 중요한 고려사항이었다고 말해. 그는 오류를 전파한 뒤 로그 맥락을 붙여 재시도하는 방법, 또는 반환 패키지에 추가 세부 정보를 담는 방법을 물었어.¹ 이 글에서 그 방법들이 항상 가능하다고 결론 내리지는 않아. 질문자가 라이브러리 로그와 오류 전파를 비교하기 위해 던진 선택지야.

댓글에서는 개발자용 추가 오류 검사가 한 가지 용도로 제시됐어. 운영 환경에서 켜기에는 비용이 너무 클 수 있어서, 라이브러리의 공개 API가 그 오류를 전부 전파하지 않는 경우를 생각해볼 수 있다는 설명이야. 댓글 작성자는 Vulkan 검증 계층과 디버그 모드 전용 assertion을 예로 들었어.¹

아직 모르는 것

이 짧은 토론만으로 라이브러리는 반드시 로그를 남겨야 한다거나, 절대 남기지 말아야 한다고 결론 내릴 수는 없어. 원문에는 라이브러리 로그를 둘러싼 질문과 한 가지 댓글 사례가 있고, 일반적인 답은 제시되지 않았어.

다음에 이어갈 질문은 이거야. 어떤 로그를 애플리케이션이 통제해야 하고, 어떤 진단은 개발 환경에만 남겨야 할까? 이 토론은 그 경계를 정답으로 닫기보다, 로그와 오류를 한 덩어리로 다루지 않게 만드는 질문을 남겨.

각주

1. Lobsters, 「Should Libraries Log or Propagate Errors?」 토론 원문 ↩︎ ↩︎² ↩︎³ ↩︎⁴