의미있는 debug 로깅은 필요 하다고 생각합니다. 모든 상황에 대한 test case로 커버하는것 이외에 debug로그를 참고 해서 로직 처리를 좀더 잘 할수도 있더군요. 하지만 개인적으로는 debug는 개발할때만 쓰는 게 맞겠죠.

말씀하신 두려움의 표시는 의미있는 Exception으로 정의를 해서 발생시키는게 더 가치 있는 코드가 아닐까 합니다. 사실 info로그는 보기도 힘들잖아요.

웹어플리케이션에서는 중간에 문제가 발생하면 에러 페이지로 보내면 그만이니 적절한 RuntimeException을 만들어놓고 발생시키면 가져다 쓰는 코드 들은 try {}catch {}도 안하고 바로 바로 쓸수 있어서 거부감도 덜할것 같습니다.

예외/오류에 대한 사용자 로깅이 과연 필요한가요?? - 필요합니다. - 제가 처리하고 있는 업무에서는 100% 그렇습니다. - IFRS를 담당하여 주로 비즈니스 관련된 문제 해결을 도와 주고있습니다. - 실전에서의 데이터는 참으로 다양해서, - 예상하지 못한 혹은 다른 시스템의 오류 - 차세대 개발 후 등등 으로 인해 - 문제가 발생하여, 예기치 못한 결과로 오류를 발생합니다. - 이런 경우, - 예외 / 오류에 대한 로깅이 원인 추적에 도움이 많이 됩니다. 가공해서 의미있는 정보로 만들지 않는 데이터 로깅이 필요할까요?? - 필요없습니다. - 하지만, - 로딩 데이터를 바라보는 여러 관점(예 시스템팀, 영업팀, CRM팀, 기획팀, 마케팅팀 등)에서 - 생각하고 모든 팀들이 요청하지않는 자료라면 - 모두에서 필요로 하지 않는다면 - 쓰레기를 쌓고 있는 것과 다름이 없습니다. - 그렇다면 과감히 로깅을 하지 않는 '용기'가 필요합니다. 일반적으로 흔히들 하고 있는 로직 사이 사이의 로깅은 두려움에 표시가 아닐지 하고 생각해봅니다. 로깅보다 단정문 등을 이용하는 것은 어떨까요?? - 정말로 좋은 의견입니다. - '로깅은 로깅일뿐 디버깅이 아니다.' - 로딩을 프로그램 로직의 디버깅용이라면 - 단정문을 사용하는게 보다 나은 방법이죠.