애자일 디버깅

가장 재능 있는 애자일 프로젝트 팀에서도 일은 잘못될 수 있습니다.

언제 어느 상황에서든 버그, 에러, 결함, 실수가 나타납니다.

디버깅의 진짜 문제는 디버깅을 타임 박스에서 다룰 수가 없다는 사실인데,

그럼 이 문제를 어떻게 해야 할지 보도록 하겠습니다.

 

- 해결책 로그를 기록하자

 

문제에 부딪치는 일, 그리고 문제를 해결하는 일은 개발자에게 흔히 일어나는 일입니다.

개발자들은 문제가 생겼을 때, 문제를 재빨리 해결하길 원하고 비슷한 문제가 다시 생긴다면

처음에 무엇을 했는지 기억해서 다음에는 문제를 더 빨리 해결하길 바랍니다.

하지만 오롯이 개인의 기억에만 의존한다면, 다음에 수정 방법을 기억해 내기란 꽤나 어렵습니다.

 

• 두 번 불에 데지 말자

 

인터넷 검색보다는 더 생산적으로 해야합니다. 항상 접했던 문제와 발견한 해결책의 로그를 유지하도록 합시다.

비슷한 문제에 대해 "어떻게 고쳤는지 실마리가 없어" 라고 말하는 대신 과거에 사용했던 해결책을 재빨리 찾아볼 수 있습니다.

이것을 '데이로그' 라고 합니다.

 

• 문제 발생일

• 문제나 쟁점의 간단한 설명

• 해결책의 상세한 설명

• 더 많은 상세 내용과 관련된 정보를 담은 기사나 URL 의 참조

• 해결책의 일부나 상세 내용을 깊게 이해하는데 도움이 될 만한 코드 일부, 설정, 다이얼로그 스냅샷

 

데이로그에 정해진 형식이 있는건 아니지만, 위의 항목들을 포함시켜서 적도록 합니다.

컴퓨터 검색이 가능한 형식으로 로그를 기록하면, 이후 상세한 내용을 재빠르게 찾기 위해 키워드 검색을 수행할 수 있습니다.

또한 로그에서 해결책을 찾을 수 없을 때, 다른 소스에서 해결책을 찾았다면 그 즉시 새로운 세부 사항으로 로그를 갱신하도록 합니다.

 

로그를 보관하는 것보다 더 나은 방법은 다른 사람과 로그를 공유하는 것입니다.

로그를 공유 네트워크 드라이브의 일부로 만들어서 다른 사람도 로그를 이용할 수 있도록 하거나 위키를 만들어서 다른 개발자가 로그를 사용하고 갱신하도록 격려합시다.

 

- 경고는 진짜 에러다

 

프로그램에 컴파일 에러가 있을 때 컴파일러나 빌드 툴은 실행 파일 만들기를 거부합니다.

그런 상황에서 개발자에겐 선택권이 없고, 계속 가기 전에 에러를 반드시 수정해야 합니다.

 

하지만 경고는 에러 같지 않습니다. 경고를 무시하고 코드를 계속해서 개발할 순 있지만, 이런 경우 언젠가 폭발할지도 모릅니다.

예를 들어, 코드에서 사용하지 않는 변수에 대한 경고는 해를 끼치지 않지만, 올바르지 않은 어떤 변수의 사용을 암시할지도 모릅니다.

 

일각에선 훌륭한 단위테스트가 이러한 문제를 발견할 것이라고 주장하기도 합니다.

이는 맞는 말이고, 단위테스트는 충분히 도움이 됩니다.

하지만 이러한 종류의 문제를 컴파일러가 발견할 수 있다면 시간과 두통을 모두 줄여줄 것입니다.

 

경고를 에러로 다루기 위해 컴파일러에게 알려줄 방법을 찾고 경고 보고 수준을 미세하게 조정할 수 있다면,

어떤 경고도 무시하지 말게 하도록 합니다.

사실 이 부분은 보면서도 100% 동의가 되지 않긴 합니다. 위에서 이미 적은 것처럼 타임 박스는 한정되어있고,

어떠한 경고는 그냥 무시해도 될 수준이지 않나.. 싶긴 합니다. 어떠한 경고조차 없는 완벽한 상황이 과연 가능한가도 조금은 의문이구요.. 일단 넘어가도록 하겠습니다.

 

다른 프로그래밍 언어나 IDE 를 사용한다면, IDE 나 언어에서 경고를 에러로 어떻게 다룰 수 있는지 알아내도록 합시다.

이런 작업들은, 프로젝트를 시작하면서 정확히 설정하고 가면 좋을 것입니다.

프로젝트 중간쯤에 갑자기 경고를 바꾸는 것은 너무나 걷잡을 수 없고 다루기도 힘드니 말이죠.

 

- 문제를 격리해서 공격하라

 

단위테스트의 긍정적인 효과 가운데 하나는 코드를 레이어로 만드는 것입니다.

코드를 테스트 가능하게 만들려면, 테스트하려는 코드를 다른 소스코드와 분리해야 합니다.

코드가 다른 모듈에 의존하면, 다른 모듈에서 코드를 격리하기 위해 모의 객체를 사용할 것입니다.

이는 코드를 강건하게 만들고, 모의 객체는 문제가 생길 때 위치를 알아내기 쉽게 해줍니다.

 

만약 위처럼 되어 있지 않다면, 어디서 시작할지 알아내는 것 부터 시작해야 합니다.

문제의 영역에 도달하는 작업부터 쉽지 않을 것이고, 이 지점에서 전체 시스템과 싸우고 있는 자신을 발견해 스트레스는 늘어나고 생산성은 상당히 감소하게 됩니다.

 

한번에 전체 시스템과 작업하려고 시도하지 말고, 심각한 디버깅의 경우 문제가 있는 컴퍼넌트와 모듈을 코드 베이스의 나머지 부분과 분리합시다. 단위테스트 코드가 붙어있다면 이미 코드를 분리한 것입니다.

 

• 격리하기 위한 프로토타입

 

복잡한 문제를 인식하는 첫 단계는 문제를 격리하는 것입니다.

예를 들면, 엔진이 비행기 밖으로 나와서 작업대 위에 있을 때 고치기가 더 쉽습니다.

마찬가지로 문제를 일으키는 모듈을 격리할 수 있다면 코드 안에 있는 문제를 고치는 것이 더 쉽습니다.

 

대체로 많은 어플리케이션이 격리하기 어려운 방식으로 작성됩니다.

관심있는 코드를 떼 내고 작업할 시험대를 만드는데 시간을 보내는 편이 훨씬 낫습니다.

 

문제를 격리하는 데는 몇 가지 장점이 있습니다.

문제를 격리해 직접적으로 문제와 관련된 이슈에 관해 집중할 수 있고, 문제의 근본에 도달할 만큼 많이 변경할 수 있습니다. 또한 관련된 코드의 최소 분량과 작업하기 때문에 더 빠르게 문제에 도달할 수 있습니다.

 

- 모든 예외를 보고하라

 

프로그래밍 직업의 일부는 코드가 어떻게 작동해야 하는지 곰곰이 생각하는 것입니다.

그러나 코드가 작동하지 않을 때 무슨 일이 발생했는지 생각하는 편이 훨씬 더 이익입니다.

 

일부 개발자들은 컴파일러가 불평하는 것을 막기 위해 예외를 잡아 무시해 버립니다.

때로는 이렇게 처리하는 것도 어플리케이션 내에서 필요하다고 전 생각합니다.

하지만 처음부터 이런 경우는 거의 없습니다. 할 수 있다면 모든 예외를 처리하고 장애를 복구해야 합니다.

만약 스스로 예외를 처리할 수 없다면, 메서드 호출자에게라도 예외를 전달하도록 합시다.

 

- 유용한 에러 메세지를 제공하라

 

어플리케이션을 실제 세상에 배치하고 사용하면서, 때로는 작업이 실패합니다.

예를 들어 계산 모듈이 실패하거나 데이터베이스 서버 연결이 끊길 수 있습니다.

 

에러가 발생했을 때, 일반적인 에러 메세지로는 사용자가 개발자에게 많은 것을 이야기해 줄 수 없습니다.

가장 일반적인 해결책은 로그를 남기는 것입니다.

현재 팀에서도 여러 부분을 활용해 에러 정보를 남기고 있는데, 우선 Sentry 라는 서비스를 사용해 어플리케이션 내에서 에러 발생시 Sentry 에서 관련 정보를 캡쳐하고 Slack 으로 메세지를 받고 있습니다.

또한 모든 에러에 대해 ES 혹은 Loki 로 로그를 전송해 에러를 추적하고 문제를 해결하는데 활용중입니다.

 

에러를 보고하는 것은 개발자 생산성을 올려 줍니다.

디버깅 정보는 중요하며 얻는 일도 쉽지 않습니다. 디버깅 정보를 버리지 맙시다.

 

 

출처 : 애자일 프랙티스(책)