“제 컴퓨터에서는 동작하는데요?”라는 것은 웃음거리가 될 수 있지만, 개발자 세계에서 많이 퍼진 태도를 의미하기도 한다. 우리는 책임을 지고 문제를 찾아야 한다.
그렇다면 버그가 발생하면 어떻게 해야 할까? 일반적으로는 두 가지 접근 방식이 있다. 처음에는 문제가 발생하는 환경을 복제해야 한다. 운영 스테이지가 아닌 QA, Dev 등 비슷한 환경이 구성되어 있어야 한다. 아니면 원격 디버깅을 사용해야 한다.
프로젝트를 진행하면서 사용자가 보고한 버그를 재현하려고 했던 경험이 있다. 환경을 비슷하게 맞췄지만 버그가 재현되지 않았다. 결국에는 사용자와 커뮤니케이션을 하면서 네트워크 환경이 다르다는 것을 인지하고 네트워크 스로틀링을 통해 확인하였다.
다른 버그에서도 재현이 되지 않은 상황이 있었다. Datadog을 통해 사용자가 특정 UI에서 다른 패턴으로 이용하는 것을 알아챘다. 그대로 해보니 버그가 재현되었다.
이런 상황에서는 사용자 행동을 최대한 분리하는 것이 중요하다. 사용자 패턴이 녹화된 영상을 통해 사용자 행동을 검증하는 것이 도움이 될 수 있다. (Datadog 사랑해요!)
복제된 환경에서 미묘한 차이점을 이해하는 것이 핵심이고, 버그를 재현할 수 있는 방법을 찾아야 한다.
그러나 장애물이 존재할 수 있다. 장애물이란 문제를 보고하는 사람일 수도 있고, 개발자일 수도 있다. 혹은 화가 난 사용자일 수도 있다.
그나마 다행인 점은 컨테이너 기술의 출현으로 균일한 환경을 쉽게 갖출 수 있다는 점이다. 하지만 미묘한 차이는 존재한다. 환경에 상당한 영향을 미치는 네트워크, 데이터 규모와 같은 요소가 있다. 대규모 환경에서 초당 10,000개의 요청이 있을 때만 나타나는 문제를 어떻게 재현할 수 있을까? 결국 모니터링 도구를 잘 이용해야 한다. 모니터링 도구는 이러한 상황을 관리하고 관찰하는데 매우 유용할 수 있다.
로깅도 애플리케이션의 중요한 기능이다. 여러 케이스를 디버깅하는데 매우 정확한 도구이다. 로깅은 모니터링 도구와 마찬가지로 사전에 준비되어야 한다. 로깅을 하지 않는 곳은 디버깅이 되지 않기 때문이다. 이상적으로는 테스트를 잘 수행하여 이런 상황이 발생하지 않아야 한다. 그러나 실제는 그렇지 않다.
오류를 파악하기 어려운 경우에는 동시성 관련 문제가 발생할 가능성이 매우 높다. 문제 현상이 일관되지 않을 경우에는 연관된 스레드를 확인하고 예상대로 동작되는지 확인해야 한다. 단일 스레드를 사용하여 특정 메서드에 동시성 경쟁 문제가 있는지 확인해야 한다.
이렇게라도 찾으면 다행이지만, “포기” 해야 하는 경우도 발생한다. 문제를 일관되게 재현하는 것이 불가능하다는 것을 받아들여야 할 때가 올 수도 있다. 이럴 경우에는 문제를 좁히기 위해 로깅을 추가하는 것이 중요하다. 해당 오류가 다시 발생하면 분석할 정보가 많아지기 때문이다.
결국, 오류 해결은 끈기와 끊임없는 학습 및 경험에 관한 것이다. 디버깅 경험을 통해 어떻게 개선하고 성장할 수 있는지 이해하는 것이다.
“제 컴퓨터에서는 잘 동작하는데요?”라는 것은 소프트웨어 개발 세계에서 종종 목격된다. 이 업종에 종사하는 사람들은 오류에 대한 소유권을 가져야 하며, 사용자 환경과 행동을 최대한 비슷하게 복제하려고 노력해야 한다. 명확하게 커뮤니케이션을 해야 하며, 모니터링 도구 및 로깅을 통해 원인을 판단해야 한다.
그러나 네트워크, 데이터 규모의 차이로 인해 디버깅에 영향을 미칠 수 있다. 어떤 경우에는 오류가 일관되게 재현되지 않을 수도 있다. 이런 경우에는 잠재적 원인에 대해 가정을 할 수 있어야 하고, 가정을 재현하는 테스트 케이스를 만들고, 향후 발생했을 경우에 더 많은 정보를 얻기 위해 로그를 추가해야 한다.
디버깅은 끈기와 적응력이 필요한 학습 경험이며, 모든 개발자의 성장에 필수적이다.
오류가 없는 것이 가장 좋지만, 오류를 만나게 되면 성장을 위한 발판으로 삼았으면 좋겠다.
잠깐, 글이 유익했나요?
