[Insight] 개발의 절반은 '디버깅'이다

개발의 복잡성과 디버깅의 중요성

 

개발자로서 연차가 쌓이면서 바뀌는 습관이 하나 있습니다. 예전에는 "어떻게 하면 이 기능을 빨리 구현할까?"를 고민했다면, 이제는 "이 기능이 멈췄을 때, 어떻게 하면 빨리 원인을 찾을 수 있을까?"를 먼저 고민한다는 점입니다.

특히 하드웨어를 제어하는 장비 개발 분야에서, 코드가 '도는 것'은 시작에 불과합니다. 진짜 싸움은 현장에서 예기치 않은 이유로 '멈췄을 때' 시작됩니다.

 

오늘은 제가 프로젝트를 진행하며 뼈저리게 느낀 '디버깅을 위한 개발 철학'과, 새로 합류하는 팀원들에게 꼭 해주는 이야기를 나누려 합니다.

 

1. 미래의 나를 구하는 '방어적 코딩'

 

우리는 종종 'Happy Path(모든 조건이 완벽한 상황)'만을 가정하고 코드를 짭니다. "센서는 당연히 켜져 있겠지", "통신 케이블은 연결되어 있겠지", "파일은 그 경로에 있겠지".

하지만 현장은 가혹합니다. 센서는 오동작하고, 케이블은 빠지며, 작업자는 엉뚱한 버튼을 누릅니다. 이때 프로그램이 아무런 말 없이 죽어버리거나(Crash), 멍하니 멈춰 있다면(Hang), 그것만큼 개발자를 절망스럽게 하는 것은 없습니다.

그래서 저는 코드를 짤 때 항상 '최악의 상황'을 먼저 작성합니다.

• 가정하지 마라: 리턴 값, 포인터, 하드웨어 상태를 믿지 말고 검증하는 코드를 먼저 넣습니다.
• 친절한 Log을 남겨라: 단순히 return false;로 끝내지 마십시오. 왜 실패했는지, 어떤 데이터가 문제였는지 로그를 남기고 리턴해야 합니다.

if (Sensor == On)이 아니라 if (Sensor == Off) { Log("Sensor Timeout"); return Error; }를 먼저 고민하는 것. 이것이 퇴근 시간을 앞당기는 방어적 코딩의 시작입니다.

 

2. 백문이 불여일견: '동작의 시각화 (Visualization)'

방어적 코딩으로 로그를 남겼다 해도, 수만 줄의 텍스트 로그를 실시간으로 분석하는 것은 불가능에 가깝습니다. 특히 모션이 움직이고 시퀀스가 빠르게 돌아가는 장비 제어에서는 더욱 그렇습니다.

그래서 제가 강조하는 것이 '로직의 시각화'입니다.

실시간 센서 데이터 그래프, 상태 머신(State Machine)의 흐름도, 에러 로그 창이 하나의 대시보드에 시각적으로 표현된 화면.

 

코드가 내부적으로 어떻게 돌아가고 있는지를 직관적인 UI나 그래픽으로 표현해야 합니다.

• 상태 머신(State Machine)의 시각화: 현재 장비가 '대기' 상태인지, '이동' 상태인지, '에러' 상태인지 텍스트가 아닌 블록 다이어그램의 색상 변화로 보여주십시오.
• 데이터의 그래프화: 모터의 속도나 센서 값을 숫자로만 보지 말고, 실시간 그래프로 그리십시오. 튀는 값(Noise)이나 지연(Delay)이 한눈에 보입니다.
• 오버레이(Overlay) 활용: (지난번 SkaldLogger 처럼) 화면 위에 현재 수행 중인 작업의 로그를 투명하게 띄우십시오.

개발 단계에서 이런 시각화 툴을 만드는 것이 시간 낭비처럼 보일 수 있습니다. 하지만 장비가 오동작할 때, "아, 여기서 멈췄구나"라고 1초 만에 파악할 수 있다면, 그 툴을 만드는 데 쓴 시간은 이미 보상받고도 남습니다.

 

3. 꼰대 같지만, 신입 개발자에게 꼭 하는 잔소리

 

새로운 팀원이 오면 제가 웰컴 키트처럼 꼭 하는 잔소리가 있습니다. 당장은 귀찮게 들릴지 몰라도, 나중에 피가 되고 살이 되는 이야기들입니다.

1. "기능 구현이 다가 아니다. 70%는 예외 처리다."
   • 신입 때는 '정상 동작'을 구현하는 데만 온 힘을 쏟습니다. 하지만 프로의 코드는 '비정상 상황'에서도 우아하게 대처해야 합니다. "이게 안 되면 어떡하지?"를 항상 먼저 고민하세요.
2. "로그는 네가 없을 때 너를 대신하는 목격자다."
   • Log("Error"); 같이 성의 없는 로그는 범죄 현장에 "누군가 왔다 감"이라고 써놓는 것과 같습니다. 언제, 어디서, 어떤 값을 가지고, 왜 에러가 났는지 육하원칙에 가깝게 남기세요. 나중에 로그 파일만 보고도 상황을 재구성할 수 있어야 합니다.
3. "제발 눈으로만 디버깅하지 마라."
   • 코드를 뚫어져라 쳐다본다고 버그가 잡히지 않습니다. 브레이크 포인트를 걸고, 변수 값을 확인하고, 제가 앞서 말한 시각화 도구를 적극적으로 활용하세요. "제 생각에는..." 이라는 추측보다는 "데이터를 보니..." 라는 팩트를 가져오세요.

4. 결론: 디버깅하기 쉬운 코드가 좋은 코드다

클린 코드, 디자인 패턴, 최적화... 모두 중요합니다. 하지만 현장의 엔지니어에게 가장 좋은 코드는 '문제가 생겼을 때, 스스로 아픈 곳을 말해주는 코드' 입니다.

 

개발자는 코드를 짜는 시간보다 디버깅하는 시간에 더 많은 인생을 씁니다. 지금 작성하는 그 한 줄의 에러 처리와, 귀찮음을 무릅쓰고 만든 시각화 기능이, 먼 훗날 새벽 2시 현장에 있는 '미래의 나'를 구해줄 유일한 동아줄이 될 것입니다.

"구현(Implementation)은 기능의 완성이지만, 시각화(Visualization)와 방어적 코딩은 품질의 완성입니다."