[인프콘 2024] 디버깅 마인드셋: 디버깅의 고통을 절반으로 줄여주는 고수들의 행동패턴 따라하기

소개

안녕하세요. 저는 현재 XL8이라는 실리콘밸리 소재의 스타트업에서 프론트엔드 팀 리드로 일하고 있는 배휘동입니다.

XL8은 인간이 번역하고 검수한 영상 자막 데이터를 전 세계에서 가장 많이 가지고 있어요. 이걸 이용해서 굉장히 뛰어난 성능의 번역 엔진을 만들었죠. 넷플릭스 같은 OTT 컨텐츠의 다국어 자막을 납품하는 회사들이 주 고객입니다.

이 엔진을 이용한 제품이 회사 내에 여러 가지 있는데, 저는 영상 컨텐츠의 자막을 번역하고 편집하는 MediaCAT이라는 SaaS를 맡아서 개발하고 있어요.

발표 계기

디버깅이라는 주제에 대해서는 제 커리어의 비교적 초기부터 관심을 가졌습니다. 블로그에 디버깅에 관련된 글도 몇 편 썼었고요.

• 디버그를 디버깅하기: 단계적 디버깅 프로세스 템플릿
• [디버깅 사례 공유] 제 컴퓨터에서는 됐었는데요...
• [디버깅 사례 공유] 잘못된 IndexedDB 사용으로 인한 무한 Suspense 문제 해결
• 사라지는 HTML 엘리먼트를 개발자 도구에서 검사하는 방법

원래는 이렇게 삽질했던 경험을 늘어놓으면서 정리하는 정도에 만족했는데요.

작년에 우연히, 토스의 Head of FE이자 이번 인프콘에도 참여하신 박서진님과 페어 디버깅을 하면서 신선한 충격을 받았습니다.

함께 풀었던 문제는 제가 회사에서 몇시간동안 씨름하던, material-ui의 드롭다운과 관련된 버그였는데요. 문제를 설명하고 나서 바로 소스코드로 넘어가려던 저를 서진님이 막으시고는 브라우저 콘솔 창을 떠나지 않고 유심히, 소리내서 에러 메시지를 읽으시더군요. '오 신기하네요' 같은 추임새를 넣으시면서요.

그리고 저랑 대화하면서 크롬 디버거의 기능들을 신들린 듯이 사용하시더니, 제가 몇시간 앓던 문제가 20분도 안 돼서 손쉽게 풀렸습니다.

조금 과장하자면 마법 같았습니다. 무척 신기한 경험이었어서, 이것저것 캐물은 다음 회사로 돌아와 팀원들에게 신나게 공유했었죠.

그런데 최근에 저도 이런 마법을 부린 적 있었습니다(관련 글: 어떻게 그 판단을 할 수 있었을까). 회사 동료분과 페어 디버깅을 하던 때였는데요.

동료분은 목록 페이지에서 특정 액션을 한 결과물이, 개별 아이템 페이지에서도 이렇게 반영되어야 하는데 반영이 안 되는 문제가 가끔씩 나타난다고 하셨어요. 재현 조건은 아직 찾지 못한 상태였고요.

저는 이 이야기를 듣자마자 캐시 갱신이 안 된 문제일 것 같았고, 직관적으로 개별 아이템 페이지에 먼저 갔다가 목록으로 돌아가서 동작을 수행했을 때를 확인해보자고 제안했습니다. 그리고 그게 맞더군요. 그렇게 페어 디버깅 세션은 5분도 안 되어 끝났습니다.

왜 디버깅 역량을 키우기 어려운가

이런 마법같은 순간들이, 개발자들이 디버깅 역량을 효과적으로 키우기 어려운 이유를 말해주기도 합니다.

사실 우리 개발자들은 평소에 자주 버그를 맞닥뜨리고, 직접 해결하거나 남들이 해결하는 걸 지켜보기도 하죠. 하지만 고수들의 디버깅을 관찰하더라도, 대개 문제 자체와 해결된 결과물만 보이지 그 안에 어떤 인지적 과정이 있었는지는 알기 어렵습니다.

제가 직관적으로 했던 제안에서, 대체 이런 판단과 의사결정을 어떻게 할 수 있었는지는 숨겨져 있었던 것처럼요.

돌이켜보면, 당시 제 머릿속에서는 이런 일들이 벌어졌습니다.

• 신호 인식: 문제가 발생할 때가 있고 아닐 때가 있다? 특정 동작 이후에 정보 갱신이 안 되는 문제다?
• 과거 경험과의 유사성: 동작 이후 정보 갱신 문제는 대부분 인메모리 캐시가 갱신되지 않은 게 원인이던데.
• 전제조건: 캐시 갱신이 안 되려면 먼저 캐시가 메모리에 들어가야 하고, 그러려면 그 쿼리를 먼저 호출해야 한다.
• 사전지식: 목록 페이지와 개별 아이템 페이지에서 호출하는 쿼리가 다르다는 걸 알고 있었다.
• 과거 경험과의 유사성: 어떤 페이지에 먼저 들어갔느냐에 따라 문제의 재현 여부가 달라지는 경험을 한 적이 있다.

그래서 "개별 아이템 페이지에 먼저 들어가서 특정 쿼리에 대한 캐싱이 된 상태에서, 목록 페이지의 동작을 수행 후 개별 아이템 페이지의 쿼리 캐시가 갱신되지 않은 것 아닐까?" 라는 결론을 낼 수 있던 거였죠.

제가 조금 전 셀프 분석했던 방법은 인지심리학계의 거장 개리 클라인이 만들어서1989년 논문에서 발표한 Critical Decision Method, 줄여서 CDM이라고 부르는 기법입니다.

이 CDM은 인지작업 분석(Cognitive Task Analysis, CTA)이라는 기법의 한 종류인데요. 이러한 분석 방법을 잘 활용해서 전문가들을 인터뷰하면 그들의 머릿속에 숨은 암묵지, 무의식적으로 인식하는 패턴, 저도 모르게 하는 습관 등을 효과적으로 뽑아낼 수 있습니다.

인지작업 분석으로 디버깅 고수들을 인터뷰하다

저는 이 인지작업 분석을 이용해 디버깅 전문가들의 머릿속을 파헤쳐보고 싶다는 생각으로, 친분이 있는 디버깅 고수들을 찾아가 인터뷰를 했습니다. 분야는 프론트엔드, 백엔드, 리서치 등 다양했고요.

한편, 저는 디버깅이라는 게 단순히 소프트웨어에만 국한된 게 아니라고 생각했어요. 그래서 다른 분야의 문제해결 전문가들도 몇 분 인터뷰를 해봤습니다. 문제에 접근하고 해결하는 방식에 공통점을 발견할 수 있을 거라고 기대했거든요.

그리고 ChatGPT에게도 인터뷰를 해봤어요. 사람과 할 때는 인터뷰 시간이 부족해 물어보지 못했던 것들을 잔뜩 물어볼 수 있었고, 기존의 인터뷰를 검증해볼 수도 있었죠. 절대 지치지 않는 인터뷰는 정말 매력적이더군요.

인터뷰의 초반부는 언제나 이런 식으로 시작했습니다. 우선 인터뷰이에게 디버깅할 때 하는 행동들의 종류나 순서를 그려달라고 요청합니다. 인지작업 분석에서는 Task Diagram Mapping이라고 부르는 기법입니다.

그러면 위와 같이 몇 가지 행동을 그려줄텐데, 여기서 디버깅을 잘 하는 사람과 못 하는 사람의 차이가 큰 게 무엇인지 골라달라고 했죠.

그러면 더 중요한 게(위 이미지에서 빨간색 체크) 튀어나오는데요. 이 다음 실제 최근의 디버깅 사례를 듣고, 추가적인 탐침을 하면서, 본인이 말한대로 실제로 행동했는지 교차검증을 했습니다.

이러한 인터뷰 과정에서 확신하게 된 건, 디버깅은 마법이 아니라 마술에 가깝다는 점이었습니다.

마법은 그냥 신비하고, 이해하기 어려운 무언가죠. 반면 마술은 트릭을 알고 손기술을 익힌다면 누구나 배울 수 있는 기술입니다. 여기서 트릭은 고수들의 인지적 작업이 담긴 행동패턴이고, 손기술을 익히는 건 그 행동패턴을 따라하며 훈련하고 체화하는 걸로 볼 수 있겠네요.

그런데 재미있게도, 인터뷰이 본인도 스스로의 트릭과 손기술에 대해 명확히 인지하고, 정리되어있지 않은 경우가 대부분이었어요.

실제로 인터뷰 과정에서 인터뷰이들이 이런 말씀들을 하셨고요.

"와 제가 이렇게 했었군요. 몰랐어요."

"이렇게까지 파고들어본 적이 없었는데 정리가 잘 되었습니다."

"저희 팀원 분들에게 이거 그대로 보여주면 되겠어요."

"이거 하고 나니 제가 자주 하는 다른 기법들도 떠오르더라고요."

즉 고수들도 본인이 어떻게 하는지 잘 모르고, 그러니까 잘 가르쳐주지도 못했던 거죠. 그렇다면 이런 디버깅 고수들의 패턴을 정리해서 주니어들에게 가르치면 큰 효과가 있으리라는 확신이 생겼습니다. 실제로 저 자신의 디버깅 능력도, 일련의 인터뷰 이후로 훨씬 좋아진 걸 체감했기도 했고요.

그러면 지금부터 고수의 디버깅은 무엇이 다른지, 그들이 어떤 생각과 행동을 하는지 제가 정리한 패턴을 보여드리겠습니다.

일반적인 디버깅과 고수의 디버깅

디버깅이라는 행위를 크게 3단계로 보면 이렇습니다. 문제의 원인을 찾고, 해결하고, 사후 처리를 하는 거죠.

그런데 이렇게 보면 이 3단계의 비중이 똑같아 보이지만, 실제로 우리가 디버깅을 할 때 이 3가지에 얼마나 시간과 노력을 쏟는지를 기준으로 생각해보면,

때로는 원인만 하루종일 파악하다가 아무것도 못할 때도 있고

때로는 원인을 대충 보고, 파악했다고 생각한 뒤 바로 해결에 뛰어드는 경우도 많습니다.

문제 해결 과정을 정리해서 팀에 공유하거나, 문제가 애초에 일어나지 않게 환경을 개선하는 등의 사후 처리도 없거나, 비중이 적죠.

반면, 디버깅 고수들은 대략 이런 패턴을 보이더군요.

시간과 노력을 원인 파악에 훨씬 더 쏟는 거죠. 물론 원인을 알아내고 나서도 문제를 해결하기 어려울 때 어떻게 하는가, 해결 후 무엇을 하는가 처럼 뒷부분에도 굉장히 중요한 게 많았지만, 고수들의 전문성의 핵심은 무엇보다도 문제의 근본 원인을 파악하는 데에 있다는 걸 알았습니다.

그러면 원인을 분석할 때 고수들은 뭘 하길래 훨씬 더 빠르고 효과적으로 디버깅을 하는 걸까요?