오늘은 디버깅 원칙이라는 글을 읽고 느낀점을 공유해보고자 합니다.
처음에는 가볍게 읽었는데 생각보다 좋은 내용이 많아 정리해보면 좋을 것 같네요.
먼저 해당 블로그 글을 읽고 아래 글을 보면 좋을 것 같습니다.
모든 개발자는 디버깅 과정에서 글에 나온 모든 내용을 의식적 또는 무의식적으로 크거나 작게 행하고 있을 것이라고 생각됩니다.
글쓴이는 디버깅 과정을 크게 네 개의 단계로 구분지었는데요. 다음과 같습니다.
- 의심하기
- 분류하기
- 학습하기
- 연결하기
위 네 개의 단계를 제 경험들을 바탕으로 어떻게 처리하고 있는지 추가 서술해보고자 합니다.
1.의심하기
가장 먼저 의심을 하려면 에러가 발생해야 합니다. 서비스를 운영하다보면 다양한 에러 로그가 생기며 이러한 로그들을 확인하고 개선해 나갑니다.
대표적인 모니터링 툴로는 grafana, prometheus, elasticsearch 등이 있고 구축된 모니터링 툴을 통해 이러한 로그들을 확인합니다.
이러한 로그들을 통해 에러가 발생한 시점과 에러 메세지를 확인하고 의심을 시작합니다.
따라서, 의심을 잘하기 위해서는 로깅을 잘해야 합니다. 디버깅 이전에 적당한 시점에 로깅을 하고 있는지, 예외 핸들링을 세분화해서 하고 있는지도 한 번 검토해보면 좋을 것 같습니다.
체크리스트 작성
사실 혼자서 디버깅을 할 때 체크리스트까지 필요할까..? 라는 생각을 가지고 있습니다. 다만 장애 상황에서 팀원들과 함께 디버깅을 진행한다면 체크리스트를 만들어 서로가 어떤 지점을 분석하고 있는지 공유하는 방식으로 사용한다면 어떨까 하는 생각이 듭니다.
제가 생각하기엔 글에 나온 '중복 작업을 방지할 수 있다'가 가장 포인트이지 않을까 싶네요.
장애 상황이 아닌 상황에서 한 영역에 대해 과몰입하는 것은 개인의 발전에 있어 도움이 되는 요소 중 하나라고 생각하기 때문에 디버깅하는 과정에서 중요한 경험이라고 생각하기 때문에 너무 '몰입하지 말아야지'라는 생각은 하지 않아도 되지 않을까..? 라는 의견도 있네요.
어이없는 실수를 찾아라
이건 디버깅 하면서도 은근 찾기가 어렵습니다 ㅎㅎ.. 제 3자에게 도움을 요청하거나 손으로 직접 변수에 값을 대입해가면서 디버깅하다보면 어이없는 실수를 보다 더 효과적으로 찾을 수 있을 것 같습니다.
2. 분류하기
이 부분이 개발자로서의 역량에 있어 가장 크게 좌우되는 부분이 아닐까 싶습니다.
결함이 발생할 수 있는 지점이 총 4가지로 분류됩니다.
- 논리적 결함
- 의존 기술 결함
- 기반 기술 결함
- 물리적 결함
결함 지점을 찾는 방법으로 제가 주로 하는 방법은 가장 시간이 덜 소요되는 것부터 확인해보는 것입니다.
물론 바로 '아 이건 XX 문제네~' 하는 결함도 있지만 서비스 운영 과정에서 정말 다양한 장애들을 겪을 수 있기 때문에 최대한 결함을 편견없이 바라봐야 된다고 생각합니다.
대부분의 개발자들은 논리적인 결함에 대해서는 잘 해결한다고 생각하지만 의존 기술, 기반 기술은 기초가 중요한 것 같습니다.
전부 다 알 필요는 없지만 사용하는 라이브러리의 메소드 코드는 한 번쯤 확인해보고 이해하는 시간을 가졌으면 좋을 것 같고, 기반 기술의 경우 여러 기술 키워드에 대해 정리하고 공부하는 시간을 어느정도 가져야 하지 않을까 싶습니다.
예시
- 비동기/동기, 블록킹/논블록킹의 차이
- JVM Option
- 변수별 메모리 영역
- 네트워크 timeout 설정
- 도메인 지식 등
3. 학습하기
3번은 2번의 연장선상에 있는 행위라 생각하기 때문에 스킵하겠습니다.
2번에서 의심되는 부분에 대한 공부를 진행하고, 이를 문서화하여 팀원들에게 공유하다보면 개인적인 성장과 동시에 팀 내부 평가도 좋아지니 꼭 문서화 하길 바랍니다.
4. 연결하기
사실 학습하는 이유가 문제를 해결하기 위해 학습하는거기 때문에 다 연장선상에 있는 행위라고 봅니다.
결론
모두가 무의식적으로 하는 일련의 행위를 질서정연하게 작성한 글이었다고 생각합니다.
이 글을 통해 다시 한 번 디버깅하는 내 모습을 되돌아보고 부족한 부분이 있었다면 개선해나가면 좋을 것 같습니다.
저같은 경우 체크리스트는 작성해서 진행해보면 좋을 것 같네요.
감사합니다.
