첫 질문에 답하지 마라

• 성능 디버깅 도구에서 이상한 요청은 즉시 답하기보다 배경을 물어야 하며, 그래야 사용자의 실제 문제와 도구의 빈틈이 드러남
• 이는 단순한 XY 문제 대응을 넘어, 잘못된 질문이 나온 혼란 자체를 출발점으로 삼아 사용자와 제품 양쪽의 이해를 높여줌
• Perfetto에서 trace를 모든 지표 계산에 쓰는 방식은 가능하더라도 비효율적이며, 전용 지표 수집 시스템이 더 적합할 수 있음
• trace 분할 요청처럼 겉보기 답과 실제 필요가 다를 때는 periodic trace snapshots 같은 기존 기능이 더 나은 경로가 될 수 있음
• 제품 변경은 반복되는 필요가 충분히 드러난 뒤 결정하는 편이 낫고, 성급한 기능 추가는 큰 기술 부채로 이어질 수 있음

첫 질문에 바로 답하지 않는 이유

• Perfetto 같은 성능 디버깅 도구에서 사용자가 “Perfetto trace를 여러 파일로 어떻게 나누나?”처럼 이상해 보이는 질문을 하면, 바로 방법을 제시하기보다 “그렇게 큰 trace를 수집하게 된 이유가 무엇인가?”를 먼저 물어야 함
• 이 접근은 단순한 XY 문제 해결보다 한 단계 더 나아감
  • 사용자의 질문을 “진짜 의도”로 바꿔 답하고 끝내지 않고, 잘못된 질문이 나온 혼란 자체를 대화의 출발점으로 삼음
  • 사용자는 도구에 대한 더 나은 정신 모델을 얻고, 도구를 만든 쪽은 제품이 어디에서 혼란을 주는지 더 선명하게 파악하게 됨
  • 대화 끝에 제품 자체가 바뀌어야 한다는 결론에 이를 때도 있음
• 엔지니어용 도구를 만드는 사람에게 특히 직접적으로 적용되는 방식임
  • 소비자 제품이나 B2B 서비스에는 덜 직접적으로 옮겨질 수 있지만, 기본 접근은 여전히 유용할 수 있음

요청을 진단하는 방식

• 모든 질문이 깊은 대화를 필요로 하지는 않음
  • 문서를 가리키면 되는 단순하고 반복적인 질문은 별도 논의 대상이 아님
  • 흥미로운 경우는 첫 요청만으로 맥락이 부족하고, 질문 자체가 평소와 다르게 보일 때임
• 이상한 질문은 다음 기준으로 어긋난 지점을 찾음
  • 이전에 본 적 있는 질문인지 확인하고, 없다면 드문 요청으로 보고 속도를 늦춤
  • 다른 질문들과 비교했을 때 합리적인지 살피고, 그렇지 않다면 그 아래에 더 일반적인 질문이 있는지 찾음
  • 도구의 구조와 맞는 요청인지, 사용자가 자신도 모르게 아키텍처와 싸우고 있는지 확인함
• 어긋난 지점을 찾은 뒤에는 빠진 맥락이 드러나도록 질문함
  • 즉각적인 답은 X지만, 이유 Y 때문에 꽤 이상한 요청으로 보이니 더 넓은 문제를 알려 달라는 식으로 대화를 시작함
  • 이후 속도는 사용자가 생각을 얼마나 잘 전달하는지에 따라 달라짐
• 대화는 보통 세 가지 결론 중 하나로 이어짐
  • 사용자가 도구의 철학을 놓치고 있음
  • 올바른 경로가 제품 안에 있지만 잘 보이지 않음
  • 제품 자체가 바뀌어야 함

도구의 철학을 놓친 경우

• 사용자는 원하는 것 또는 해결하려는 문제를 정확히 모르는 상태로 도구를 찾는 경우가 흔함
  • 이는 사용자를 비판하려는 뜻이 아님
  • 팀들은 제한된 시간과 자원 속에서 문제를 풀다가 진전이 없을 때 새로운 디버깅 도구를 찾음
  • 도구가 원하는 기능의 상당 부분을 제공하더라도 “이렇게 동작해야 한다”는 사용자의 모델과 맞지 않으면 기능 요청으로 이어짐
• Perfetto에서 흔한 예는 trace를 모든 지표 계산의 만능 해법처럼 보는 경우임
  • Perfetto trace는 특정 시간 구간 동안 장치가 한 일을 매우 자세히 기록함
  • trace에서 지표를 계산할 수 있기 때문에 사용자는 프레임률, 앱 메모리 사용량 같은 값도 모두 trace에서 계산하려 함
  • 원칙적으로는 어떤 지표든 trace에서 계산 가능함
• 하지만 trace로 모든 지표를 계산하는 방식은 비효율적임
  • trace는 수집과 처리 비용이 큼
  • 단일 숫자만 필요해도 시스템 전체 데이터를 수집하게 됨
  • 전용 지표 수집 시스템이 같은 일을 훨씬 효율적으로 처리할 수 있음
• 도구에는 설계 철학이 있고, 사용자는 당장의 문제에 집중하느라 이를 놓치기 쉬움
  • Perfetto 사용법만 알려주는 것이 아니라, 성능 엔지니어링에 접근하는 법 자체를 가르치는 일이 중요함
  • 시작 시간, 프레임 드롭, 메모리, 전력 같은 주제를 어떻게 생각하고 다룰지 알려야 함
  • 정상 상황과 문제가 생긴 상황 모두에서 어떤 도구를 어떻게 사용할지 이해하게 만들어야 함

올바른 경로가 숨겨진 경우

• 사용자가 문제 자체는 이해하고 있지만, 기존 도구들을 어떻게 조합해야 할지 모르는 경우도 있음
  • 도구는 의도적으로 강력하게 만들어졌고, 다른 팀이 전체 기능 범위를 다 이해한다고 볼 수 없음
  • 실제로 원하는 것을 파악하면, 다른 목적으로 만든 기능이 사용자의 필요를 충족할 때가 많음
• trace 분할 요청이 대표적임
  • 사용자는 긴 trace 안에 관심 구간이 있어 이를 잘라내고 싶다고 말함
  • 이유는 성능과 시각화를 더 쉽게 만들기 위해서임
  • 하지만 이 경우 애초에 긴 trace를 수집하지 않는 방식이 더 적합할 수 있음
• Perfetto에는 이미 periodic trace snapshots가 있음
  • 하나의 긴 기록 대신 짧은 기록을 반복적으로 남기는 기능임
  • 긴 trace를 수집한 뒤 나눌 필요 자체를 없애줌
• 사용자가 물어본 답과 실제로 필요한 답은 다를 수 있음
  • “그게 정확히 필요했던 것”이라는 반응은 사용자가 생각한 요청이 아니라 실제 필요를 찾아냈다는 신호임

제품이 바뀌어야 하는 경우

• 어떤 응답은 제품의 큰 변화로 이어질 수 있는 새로운 필요를 드러냄
  • 이런 경우는 까다로움
  • 요청이 새롭더라도 요청자가 실제로 무엇이 필요한지 명확히 말하지 못할 수 있음
• 기반 소프트웨어에서 잘못된 결정을 내리는 비용은 큼
  • 그래서 없는 것이 실제로 아플 때까지 만들지 않는 쪽을 선호함
  • 여러 팀이 같은 필요를 말하기 시작하면, 그때쯤 진짜로 만들 가치가 있는 핵심이 드러나기 쉬움
  • 한 번의 요청만으로 이 핵심을 찾기는 매우 어렵기 때문에 기다림이 강력함
• Perfetto의 임시 UI 커스터마이징은 잘못된 결정의 예임
  • 사람들은 워크플로에 맞게 UI를 해킹하고 싶어 했고, 그게 어렵다고 계속 불평함
  • 이를 허용하자마자 막대한 기술 부채가 생김
  • 새 기능마다 기존 모든 기능과 상호작용해야 했고, 전체 구조는 빠르게 확장 불가능해짐
  • 제대로 된 plugin API를 설계해 이 문제에서 빠져나오는 데 약 1년이 걸림
• 실제 필요는 “모든 사용자에게 영향을 주지 않으면서 팀이나 사용 사례에 맞게 UI를 개인화하는 방법”이었음
  • 이 필요는 처음부터 명확히 표현되지 않았음
  • 요청 흐름 속에서 이를 일찍 포착하는 책임은 제품을 만드는 쪽에 있었음
• Perfetto trace를 “merge”할 수 있게 한 기능은 잘 처리한 예임
  • 사람들이 계속 요청했지만 바로 만들지 않음
  • 우회 방법을 안내하고 지켜보는 태도를 유지함
  • 제대로 구현하려면 작업량이 크고 잘못 만들기 쉬운 기능임을 알고 있었음
  • 문제 공간을 충분히 이해한 뒤 지난해 유지 가능한 방식으로 구현함

핵심 교훈

• 첫 질문은 실제 질문이 아닌 경우가 많음
  • 답하기 전에 왜 그런 질문을 하는지 물어야 함
  • 어떤 경우에는 사용자가 도구를 어떻게 써야 하는지 배우게 됨
  • 어떤 경우에는 제품 안의 올바른 경로가 숨겨져 있다는 사실이 드러남
  • 어떤 경우에는 아직 만들 가치가 있는 것이 없다는 결론에 도달함
  • 어떤 경우에는 다음 큰 기능을 두 번이 아니라 한 번에 제대로 만들 준비가 됨
• 단순하지만 건너뛰기 쉬운 기법임
  • 빠르게 대응해야 한다는 압박은 계속 존재함
  • 빠른 답변은 매번 생산적으로 느껴짐
  • 그래도 한 걸음 물러나면 양쪽 모두 처음보다 더 많은 것을 얻는 경우가 거의 항상 많음