성능 디버깅 도구에서 이상한 요청은 즉시 답하기보다 배경을 물어야 하며, 그래야 사용자의 실제 문제와 도구의 빈틈이 드러남
이는 단순한 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”할 수 있게 한 기능은 잘 처리한 예임

사람들이 계속 요청했지만 바로 만들지 않음
우회 방법을 안내하고 지켜보는 태도를 유지함
제대로 구현하려면 작업량이 크고 잘못 만들기 쉬운 기능임을 알고 있었음
문제 공간을 충분히 이해한 뒤 지난해 유지 가능한 방식으로 구현함



핵심 교훈

첫 질문은 실제 질문이 아닌 경우가 많음

답하기 전에 왜 그런 질문을 하는지 물어야 함
어떤 경우에는 사용자가 도구를 어떻게 써야 하는지 배우게 됨
어떤 경우에는 제품 안의 올바른 경로가 숨겨져 있다는 사실이 드러남
어떤 경우에는 아직 만들 가치가 있는 것이 없다는 결론에 도달함
어떤 경우에는 다음 큰 기능을 두 번이 아니라 한 번에 제대로 만들 준비가 됨


단순하지만 건너뛰기 쉬운 기법임

빠르게 대응해야 한다는 압박은 계속 존재함
빠른 답변은 매번 생산적으로 느껴짐
그래도 한 걸음 물러나면 양쪽 모두 처음보다 더 많은 것을 얻는 경우가 거의 항상 많음