[디버깅 전문가를 만나다] 3. 릴레잇 CTO 양웅철님 (1/2)
![[디버깅 전문가를 만나다] 3. 릴레잇 CTO 양웅철님 (1/2)](/content/images/size/w960/2024/04/image-19.png)
'디버깅 전문가를 만나다' 인터뷰 시리즈는...
💡 ‘디버깅 전문가를 만나다’ 인터뷰 시리즈는 CTA(Cognitive Task Analysis, 인지작업 분석) 기법을 이용해 디버깅 전문가들을 인터뷰함으로써 그들의 머릿속에 숨겨진 문제해결 패턴을 추출해내는 프로젝트입니다. 소프트웨어 디버깅을 넘어 삶을 디버깅하는 다양한 문제해결사들의 이야기를 담았습니다.
제 인터뷰는 크게 다음 세 가지 기법을 주로 사용합니다. 참고로 이 인터뷰 기법들은 김창준님의 인터뷰 교육 세션, 그리고 제가 직접 CTA 관련 논문을 읽으면서 익힌 것들입니다.
- 작업 지도 그리기(Task Diagram Mapping): 전문가가 디버깅을 하기 위해 주로 하는 행동에 대해 물으며 함께 디버깅의 지도를 그린다. 이 큰 그림에서 무엇이 중요하고 무엇이 덜 중요한지 구분한다.
- 결정적 의사결정의 순간 파헤치기(Critical Incident/Decision Method): 전문가가 근래에 디버깅하면서 전문성을 발휘했던 사례의 기억을 떠올리게 한다. 전문가가 거쳐간 첩경에서 어떤 중요한 의사결정을 했는지, 그 때 어떤 신호를 감지했기 때문에 그 의사결정을 할 수 있었는지 등을 파헤친다.
- 전문성 탐침 질문을 이용해 보충하기(Knowledge Audit + Collaborative Development of Expertise): 처음에 그렸던 작업 지도와 실제 사례에서의 기억을 비교한다. 처음에는 중요하다고 생각했는데 별로 실천하지 않았던 행동, 처음에는 기억 못했는데 중요하다는 게 밝혀진 행동 등을 확인한다. 제약조건을 바꿔가며 추가적인 기억을 탐색하고, 어떤 단계에서 어떤 도구와 습관을 활용하는지 파악한다.
분야를 막론하고 전문가들은 초능력자처럼 손쉽게 문제를 해결하고는, 본인이 무엇을 보고 무엇을 했는지 인지하지도 못할 때가 많습니다. 이러한 암묵적인 인지 과정을 위와 같은 기법으로 파헤쳐서 교육에 적용하면 그 성과가 엄청나게 향상된다는 사실이 여러 연구를 통해 밝혀졌습니다. 실제로 저도 개발자뿐 아니라 여러 분야의 전문가들을 인터뷰하면서 문제를 발견/진단/해결하는 데 핵심이 되는 지식/기술/태도를 무척 빠르게 습득할 수 있었습니다. 이 글이 여러분의 문제해결 역량 발전에도 큰 도움이 되길 기대합니다.
소개
세 번째 디버깅 전문가는 릴레잇의 CTO 양웅철님입니다. 릴레잇은 스타트업을 위한 B2B 세일즈 CRM 소프트웨어를 운영하고 있고(제품 이름도 릴레잇입니다), 2019년에 와이컴비네이터에서 투자를 받기도 했습니다. 릴레잇 이전에 한국신용데이터에서 백엔드 리드를 맡으셨던 웅철님과 함께 일하면서 코딩, 제품 개발, 피플 매니징 등 정말 많은 걸 배웠는데요. 오늘은 그중에서도 코딩 - 디버깅에 국한하여 인터뷰한 내용을 공유합니다.
Task Diagram: 양웅철님의 디버깅 행동 지도 그리기
지난 인터뷰들에서 문제의 원인을 찾는 게 디버깅의 전부가 아니라는 생각이 들었어요. 그래서 웅철님에게는 조금 더 넓혀서 물어봤습니다.
Q. 다른 사람이 가져운 문제를 디버깅할 때, 웅철님이 주로 하는 행동의 종류나 순서를 3-5개 정도 그려주시겠어요?
웅철: 일단 문제를 정확하게 확인하고, 어디까지 디버깅을 해봤는지 확인하고, 정확한 재현 조건도 확인하고, 내가 직접 재현도 해보고… 대충 여기까지 하면 문제 이해가 되겠네요.
휘동: 그럼 이 네 가지가 문제 이해를 위한 행동들이군요.
웅철: 네. 그 다음은 제가 직접 디버깅을 해볼텐데… 아. 그 전에 이런 정보 수집도 더 하는 것 같아요. 예를 들어 문제를 가져온 분이 생각하는 문제의 원인이 뭔지도 들어보는 거죠. 그분이 감이 있을 수도 있고 없을 수도 있겠지만.
휘동: ‘문제 이해’에만 다섯 가지 항목을 쓰셨는데요. 이게 그만큼 중요하다고 생각해서, 그러니까 이것들을 하고 나면 해결은 쉽다고 생각해서 이렇게 하신 건가요? 아니면 하다 보니까 이런 얘기가 그냥 나와버린 걸까요?
웅철: 음… 후자네요. 제가 디버깅할 때 어떤 순서로 하는지 처음부터 생각하다 보니 나온 것 같아요.
휘동: 그렇군요.
웅철: 실제로 디버깅을 할 때에는, 여기서도 먼저 정보 수집이네요. 관련 문서를 찾아보거나, 구글 검색을 해서 스택오버플로우와 깃헙 이슈를 찾아보거나. 그리고 관련 코드 변경 이력을 Git에서 뒤지거나. 이 코드 변경 이력을 보면 ‘언제부터 발생한’ 문제인지를 확인하기 쉬워지니까, 이게 재현 조건과도 연관이 있네요. 그래서 결국에는 이것들도 다 문제를 이해하기 위한 것이었다는 생각이 드는군요.
휘동: 문제 원인의 이해를 위한 과정을 상세하게 적어주신 거군요.
웅철: 맞아요. 근데 이쯤에서, 코드 보다 보면 저절로 문제가 해결되는 경우도 많죠.
휘동: 바로 해결된다기보다는, 원인을 이해하고 나면 해결이 너무 직관적으로 쉬운 케이스들을 말씀하시는 거죠?
웅철: 그쵸. 여기까지 왔는데 여전히 원인을 정확히 모르겠다면, 그때부터는 진짜 디버깅인데요. 여기서 가장 먼저 하는 건, 아시다시피 저는 Rails 기반이니까요. 로컬에서 IRB나 PRY 같은 개발자 콘솔을 띄워서 의심가는 지점에 브레이크포인트를 찍어보는 겁니다.
휘동: 오. 그 ‘의심가는 지점’ 어디인지 아는 게 아주 중요하겠네요.