개발자 Life

문제를 만들었을 때와 같은 사고방식으로는 그 문제를 해결할 수 없다. - 아이슈타인 -

dextto™ 2011. 4. 15. 23:22
지난 이틀 간은 정말 오랜 만에 똥줄 타는 경험을 했습니다.
이번 주 내로 고객(휴대폰 개발을 하고 있으니 통신 사업자입니다)에게 전달 해 줄 버전을 릴리즈 하기로 되어 있었습니다.
그저께 빌드를 했는데 컴파일러가 에러 메세지를 뱉어내며 빌드를 멈추었습니다.
보통 에러 메세지가 나오면 그 위에 어느 파일에서 에러가 났는 지 알 수 있는데, 이 번 놈은 아주 악질이었습니다.
뭔가 알 수 있는 정보가 있어야죠.

결국 이틀 간 삽질하고 어제 밤을 꼴딱 새고서야 원인을 드디어 찾아냈습니다.
디폴트로 들어가는 APK(안드로이드 어플) 파일명에 있는 &(Ampersand)문자가 문제였습니다.
make에 쓰고 있던 명령어에 맞지 않는 문법이 들어온거지요.

순간 얼굴이 화끈거리더군요.
저 파일을 베이스 소스에 머지한 사람이 바로 저였거든요.. ㅠㅠ

왜 저 빌어먹을 사업자가 전달해 준 괴상한 파일의 이름을 꼼꼼하게 읽어보지 않았을까요.(사실 다른 APK에는 확장자 앞에 공백이 들어간 파일도 있었습니다)

사실 제가 머지한 부분이 문제가 되리라고는 꿈에도 생각하지 못했습니다.
아주 당연히 파일을 복사하기만 된다고 생각하고 verify(자기가 넣은 머지코드에 에러가 없는지 빌드해서 확인하는 것)과정을 생략했습니다. 
옆에 있던 동료가 make 파일에 echo로 로그를 마구 박아가며 디버깅해서 찾아줬지요.
동주 선임 땡큐. 역시 공인 아키텍트입니다. ^^

오늘 하고자 하는 이야기는 이 디버깅 과정에서 겪은 어려움을 토로하고 앞으로 조심하자는 게 아니라 문제를 찾는 과정에서 겪은 느낌을 적어보려고 합니다.

문제를 만들었을 때와 같은 사고방식으로는 그 문제를 해결할 수 없다. - 아이슈타인 -


내공이 낮은 저같은 사람들은 일반적으로 큰 문제가 생기면 아드레날린이 치솟아 오르면서 누가 에러를 저질렀는지 부터 찾으려고 합니다. 시간이 촉박할 경우에는 더하죠. 머리가 멍해지면서 사고가 경직되어 갑니다.
그리고 껀수라도 하나 발견하면 담당자를 찾아 마구 쪼아대죠. 이건 어떻게 보면 시간을 아끼기 위한 당연한 조치이긴 하지만요. 저도 먼저 에러 로그만 보고 빌드 에러가 났던 모듈 담당에게 확인해 달라고 요청부터 했으니까요.

내공이 깊은 고수들은 다릅니다.
증상만 보고 원인을 추측하지 않습니다. 하나 하나 다시 뒤집어 가며 살펴 보지요.
그리고 "직관"적으로 문제의 원인을 빠르게 짚어냅니다. 하수가 사용하는 직관(단순 현상만 보는)과는 그 질이 달라 보입니다.

요즘에 앤디 헌트가 쓴 책 "실용주의 사고와 학습(Pragmatic Thinking & Learning - Refactor Your Wetware)"을 읽고 있는데 바로 '2장 초보자에서 전문가에 이르는 여정'에 이러한 내용이 실려 있습니다.

다음 드라이퍼스 모델의 다섯 단계에서 숙련자라고 생각하고 있던 제 자신이 부끄러워 집니다.

단계1: 초보자
단계2: 고급 입문자
단계3: 중급자
단계4: 숙력자
단계5: 전문가

나무를 보지 말고 숲을 봐야겠습니다.


반응형