디버깅을 잘 한다.

나는 과거 종종 그런 얘기를 들은 적도 있고, 또 스스로도 제법 잘 한다고 생각한다. (최근 몇 년간은 직접적인 개발과는 거리가 좀 있는 업무들을 주로 수행해 왔다.)

그런데 ‘디버깅을 잘한다’는 말에는 어떤 의미가 포함되어 있을까.

아무 개념 없이 엉터리로 짠 남의 코드에서 산발적으로 발생하는  미지의 문제를 소스 코드만 추적해서 잘아낼 수 있으면 디버깅을 잘 하는 것일까? 분명 이런 능력은 대단한 것겠지만.. 현실적으로는 ‘운이 좋았다’ 이상을 기대하긴 어렵다. 주변에서도 능력 있는 개발자가 다른 프로젝트 합류 후 ‘내가 할 수 있는 일이 없다’고 푸념하고 경우를 몇 번 보았다. 이유는 몇 년 동안 들여다보던 사람이 아니면 도저히 손 댈 엄두가 안나는 코드를 사용하고 있기 때문이었다. 종속된 모듈과 프로젝트가 많고 덩치도 만만치 않아 새로 깔끔히 만들 수도 없다는 것이다. 동작하는 코드를 새로 만들 시간을 달라는 요청은 관리자들에게 쉽게 묵살당한다.

결국 아무리 능력 좋은 개발자도 대상 소프트웨어의 상태/환경에 따라 발휘되는 능력은 극심한 편차를 보이기 마련이다. 좀 더 정리하여 이야기하면, 커버할 수 있는 임계점 이하까지는 쉽게쉽게 문제를 찾아내지만, 그 한계를 넘어서면 거의 컨트롤이 불가하여 평범한 개발자와 별 차이를 보이지 못하게 된다. 이는 인간이 머릿속에 한 번에 담고 분석/추적할 수 있는 정보량이 그리 많지 않기 때문이다.

중요한 것은 디버깅 대상을 단순 명료하게 유지하는 능력이다. 또는 복잡한 대상을 단순하게 변형하는 능력이다. 구체적인 방법들을 떠올려보자.

• 컨벤션을 잘 따른다. 예외 상황을 신경쓸 필요가 없으므로 개발자는 context 에 집중할 수 있게 된다.
• 읽을 수 있는 코드를 작성한다. 해석하는 것과 읽는 것의 차이를 생각해보자.
• Refactoring 을 통해 코드를 항시 명쾌하게 유지한다.
• Testability 를 생각해 디자인한다. 문제가 명확하지 않다면 테스트를 통해 하나하나 문제 쉽게 좁히기 쉽다. 디자인이 잘 되어 있다면 모듈 하나하나를 분리해 독립적으로 검증할 수도 있을 것이다. TDD 같은 실천법을 활용하는 것도 적극 추천한다.

이상은 순수한 소스 코드 & 설계의 관점에서의 디버깅 능력 향상 방법들이었다. 유지보수를 위한 지침과 동일하다고 볼 수 있다. 그럼 다른 관점에서는 또 어떤 방법들이 있을까?

• 다양한 결함 분석 툴을 활용해 잡을 수 있는 문제들을 미리 잡아 놓는다. 사소한 문제들, 혹은 툴이 잘 잡아주는 결함들을 미리 제거해 두면 잠재한 문제의 범위가 좁혀지고, 그만큼 더 집중할 수 있게 된다. (디버깅은 범죄 수사와 마찬가지로, 문제 범위를 좁히고 그에 집중해 파헤쳐보고, 잘못 집었다 싶으면 되돌아가 다른 가능성에 집중에 파헤쳐보는 스타일로 진행된다.)
• 평소의 좋은 로깅 습관이 디버깅을 높기도 한다. 더욱 효율적인 로깅을 원한다면 역시 좋은 로깅 솔루션을 도입하는 것이 좋다. 주변에 찾아보면 다양한 로깅 프레임워크들을 쉽게 구할 수 있을 것이다. 이들은 로그를 다양한 목적에 맞게 구분짓고, 상황에 맞게 조작/필터링 등을 쉽게 할 수 있도록 도와준다.
• 디버깅 툴의 파워 유저가 되자. 이러저러한 모든 것을 만족해도 풀지 못하는 문제가 있을 수 있다. 또는 어쩔 수 없이 좋지 않는 코드를 디버깅해야 하는 경우도 많다. 따라서 디버깅 툴을 확실히 활용할 수 있는 능력은 기본으로 갖춰두어야 한다.
• 개발툴/언어 외적인 보조 방법을 활용한다. 예를 들어 aspect 언어를 활용할 줄 안다면 디버거로 쉽게 잡아내지 못하는 복잡한 상황까지도 아주 간단히 연출해낼 수 있다.

이상은 소스 코드 외적인 방법이었지만, 개인이 충분히 할 수 있는 것들이다. 그럼 마지막으로 소셜 개발자라면 또 어떠한 방법들을 생각해볼 수 있을지 나열해보겠다.

• 유사 도메인의 구루, 혹은 전문 커뮤니티 활용한다.
  오늘날 대부분의 프로젝트는 다수의 외부 라이브러리/플랫폼을 활용하기 때문에, 이 능력의 중요성은 과거보다 훨씬 커졌다. 내가 겪는 대부분의 문제는 누군가 이미 겪어서 그 해결책(혹 ‘어쩔 수 없다’일지라도)이 공개되어 있다. 대답을 찾지 못하더라도 질문을 올리면 늦어도 몇 일 내에 만족할만한 답을 찾을 수 있을 것이다.
  테스트 방법이나 설계에 대한 조언도 쉽게 구할 수 있다. 물론 앞서의 경우보다는  훨씬 복잡한 이슈라 자신이 처한 상황을 명확히 기술해주어야 좋은 답을 얻을 가능성이 그만큼 높아진다.
  중요한 부분이 아니라면 소스 코드를 공개해
• 만든 제품에 대해 피드백을 받을 수 있는 커뮤니티를 만들고, 가능하다면 오픈소스화 한다.
  직접 디버깅 하는 것만이  꼭 능력은 아니다. 더 궁극적인 목적은 결함 없는 제품을 만드는 것이 아닌가? 그러려면 프로젝트가 남의 관심을 받을 만큼 충분히 유용해야하고, 그들의 요구사항을 적극 반영하며 기여자(contributor)들과 지속적으로 좋은 관계를 유지해야 한다.

디버깅 하나 얘기하면서 참 많은 것을 훑었다. 오버라고 생각할 수도 있겠지만, 개발이라는 것이 그리 딱딱 떨어지는 것이 아니고.. 이것이 현실이다. 오히려 위에 나열할 것 외에도 수많은 요소들이 훌륭한 디버거를 만드는 관여될 것이 분명하다.

자!! 그럼 지금까지 나온 좋은 디버거로서의 자질은 정리해보자.

• 명확하고 논리 정연한 코드 작성 능력
• 꾸준한 코드 관리
• Testable 디자인 능력
• 다양한 분석 툴 활용 능력
• 좋은 로깅 습관 & 로깅 툴 활용 능력
• 디버깅 툴 활용 능력
• 주변 전문가, 커뮤니티, 웹 상의 정리된 지식 활용 능력
• 외부 기여자를 끌어모아 적극적인 피드백을 이끌어 내는 능력