[멘토링] 전자정부 프레임워크의 메뉴얼에서 “개발/테스팅 시점에만 System.out.println()을 사용하고 운영으로 이관하기 전에 삭제하는 것은 좋은 방법이 아님.“이라고 하는 이유와, 현업에서 로그를 남기는 범위(가능한 많이, 되도록 폭팔하지 않게)

해당 게시글은 (케인)멘토님께 멘토링 세션을 통해 주고받은 질의응답의 내용을 정리한 글 입니다.

😲 Q1.  운영환경이 아닌 개발환경에서 임시로 디버깅을 하기 위해서는 System.out을 사용해도 괜찮을까요?

Java 강의 수강 도중 console에 출력하는 System.out(이하 sout)에 대해서 다루었습니다. sout 관련해서 기존부터 받아왔던 “Sout은 성능면에서나 로그를 남기는 이유와 관련해서나, Sout 사용을 지양하고 logger또는 logger 프레임워크를 사용하는것이 좋습니다” 라는 피드백이 생각나, “왜 개발 및 운영환경에서 Sout의 사용을 지양해야하는지” 이번 기회에 공부해보았습니다…
관련해서 생긴 궁금증으로는 “운영환경이 아닌 개발환경에서 임시로 디버깅을 하기 위해서는 System.out을 사용해도 괜찮지 않을까?“라는 생각이 듭니다. 하지만 이러한 궁금증 관련해서 전자정부 프레임워크의 메뉴얼에서도 “개발/테스팅 시점에만 System.out.println()을 사용하고 운영으로 이관하기 전에 삭제하는 것은 좋은 방법이 아님.“라고 하는데, 그 이유가 궁금합니다…! 개발 도중 마주한 이슈를 해결하기 위해 필요했던 log라면, 운영환경에서 예외발생을 대비한다는 관점에서는 유의미한 log일수 있기 때문일까요?

 

👨‍🎓 A1.  임시로 디버깅을 하기 위해서는 System.out을 사용해도 괜찮지만, 개발 과정에서 이슈를 마주한 문제라면 로그를 남기는것이 유의미합니다.

이미 이슈가 한번 발생했다는 것은 나 혹은 팀원이 비슷한 실수를 할 확률이 높다는것이기 때문입니다. 따라서 결국엔 log level을 관리하는게 더 좋은 방법이라고 생각합니다. 개발 도중 마주한 이슈를 해결하기 위해 필요했던 log라면, 운영환경에서 예외발생을 대비한다는 관점에서는 유의미한 log일수 있기 때문입니다. 단위테스트 등으로 해당 이슈를 막을 필요가 존재하다고 봅니다.

또한, sout을 사용하면 개발 프로덕션과 테스팅 과정에서 받아보는 결과물이 달라질 수 있습니다. 

 

😲 Q2.  그렇다면, 현업에서는 어느정도의 수준까지 log를 관리하시는지 궁금합니다…! 이러한 log관련해서 국내 혹은 국제적으로 표준이 있을까요?

👨‍🎓 A2. 로깅에 대한 표준은 별도로 없습니다. 현업에서는 "가능한 많이, 되도록 폭팔하지 않게" 로그를 남깁니다.

get을 제외한 모든 api를 로그남기기도 하고, 200대의 응답이 아닌 아닌 모든 응답을 남기는 경우도 있습니다. 보통 그 양을 동적으로 조정합니다.