# 첫 질문에 답하지 마라 > Clean Markdown view of GeekNews topic #29623. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29623](https://news.hada.io/topic?id=29623) - GeekNews Markdown: [https://news.hada.io/topic/29623.md](https://news.hada.io/topic/29623.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-18T18:02:55+09:00 - Updated: 2026-05-18T18:02:55+09:00 - Original source: [lalitm.com](https://lalitm.com/post/dont-answer-the-first-question/) - Points: 1 - Comments: 1 ## Topic Body - **성능 디버깅 도구**에서 이상한 요청은 즉시 답하기보다 배경을 물어야 하며, 그래야 사용자의 실제 문제와 도구의 빈틈이 드러남 - 이는 단순한 **XY 문제** 대응을 넘어, 잘못된 질문이 나온 혼란 자체를 출발점으로 삼아 사용자와 제품 양쪽의 이해를 높여줌 - Perfetto에서 trace를 모든 지표 계산에 쓰는 방식은 가능하더라도 **비효율적**이며, 전용 지표 수집 시스템이 더 적합할 수 있음 - trace 분할 요청처럼 겉보기 답과 실제 필요가 다를 때는 **periodic trace snapshots** 같은 기존 기능이 더 나은 경로가 될 수 있음 - 제품 변경은 반복되는 필요가 충분히 드러난 뒤 결정하는 편이 낫고, 성급한 기능 추가는 큰 **기술 부채**로 이어질 수 있음 --- ### 첫 질문에 바로 답하지 않는 이유 - Perfetto 같은 **성능 디버깅 도구**에서 사용자가 “Perfetto trace를 여러 파일로 어떻게 나누나?”처럼 이상해 보이는 질문을 하면, 바로 방법을 제시하기보다 “그렇게 큰 trace를 수집하게 된 이유가 무엇인가?”를 먼저 물어야 함 - 이 접근은 단순한 [XY 문제](https://en.wikipedia.org/wiki/XY_problem) 해결보다 한 단계 더 나아감 - 사용자의 질문을 “진짜 의도”로 바꿔 답하고 끝내지 않고, 잘못된 질문이 나온 **혼란 자체**를 대화의 출발점으로 삼음 - 사용자는 도구에 대한 더 나은 정신 모델을 얻고, 도구를 만든 쪽은 제품이 어디에서 혼란을 주는지 더 선명하게 파악하게 됨 - 대화 끝에 제품 자체가 바뀌어야 한다는 결론에 이를 때도 있음 - 엔지니어용 도구를 만드는 사람에게 특히 직접적으로 적용되는 방식임 - 소비자 제품이나 B2B 서비스에는 덜 직접적으로 옮겨질 수 있지만, 기본 접근은 여전히 유용할 수 있음 ### 요청을 진단하는 방식 - 모든 질문이 깊은 대화를 필요로 하지는 않음 - 문서를 가리키면 되는 단순하고 반복적인 질문은 별도 논의 대상이 아님 - 흥미로운 경우는 첫 요청만으로 맥락이 부족하고, 질문 자체가 평소와 다르게 보일 때임 - **이상한 질문**은 다음 기준으로 어긋난 지점을 찾음 - 이전에 본 적 있는 질문인지 확인하고, 없다면 드문 요청으로 보고 속도를 늦춤 - 다른 질문들과 비교했을 때 합리적인지 살피고, 그렇지 않다면 그 아래에 더 일반적인 질문이 있는지 찾음 - 도구의 구조와 맞는 요청인지, 사용자가 자신도 모르게 아키텍처와 싸우고 있는지 확인함 - 어긋난 지점을 찾은 뒤에는 빠진 맥락이 드러나도록 질문함 - 즉각적인 답은 X지만, 이유 Y 때문에 꽤 이상한 요청으로 보이니 더 넓은 문제를 알려 달라는 식으로 대화를 시작함 - 이후 속도는 사용자가 생각을 얼마나 잘 전달하는지에 따라 달라짐 - 대화는 보통 세 가지 결론 중 하나로 이어짐 - 사용자가 도구의 **철학**을 놓치고 있음 - 올바른 경로가 제품 안에 있지만 잘 보이지 않음 - 제품 자체가 바뀌어야 함 ### 도구의 철학을 놓친 경우 - 사용자는 원하는 것 또는 해결하려는 문제를 정확히 모르는 상태로 도구를 찾는 경우가 흔함 - 이는 사용자를 비판하려는 뜻이 아님 - 팀들은 제한된 시간과 자원 속에서 문제를 풀다가 진전이 없을 때 새로운 디버깅 도구를 찾음 - 도구가 원하는 기능의 상당 부분을 제공하더라도 “이렇게 동작해야 한다”는 사용자의 모델과 맞지 않으면 기능 요청으로 이어짐 - Perfetto에서 흔한 예는 trace를 모든 지표 계산의 만능 해법처럼 보는 경우임 - Perfetto trace는 특정 시간 구간 동안 장치가 한 일을 매우 자세히 기록함 - trace에서 지표를 계산할 수 있기 때문에 사용자는 프레임률, 앱 메모리 사용량 같은 값도 모두 trace에서 계산하려 함 - 원칙적으로는 어떤 지표든 trace에서 계산 가능함 - 하지만 trace로 모든 지표를 계산하는 방식은 **비효율적**임 - trace는 수집과 처리 비용이 큼 - 단일 숫자만 필요해도 시스템 전체 데이터를 수집하게 됨 - 전용 지표 수집 시스템이 같은 일을 훨씬 효율적으로 처리할 수 있음 - 도구에는 설계 철학이 있고, 사용자는 당장의 문제에 집중하느라 이를 놓치기 쉬움 - Perfetto 사용법만 알려주는 것이 아니라, 성능 엔지니어링에 접근하는 법 자체를 가르치는 일이 중요함 - 시작 시간, 프레임 드롭, 메모리, 전력 같은 주제를 어떻게 생각하고 다룰지 알려야 함 - 정상 상황과 문제가 생긴 상황 모두에서 어떤 도구를 어떻게 사용할지 이해하게 만들어야 함 ### 올바른 경로가 숨겨진 경우 - 사용자가 문제 자체는 이해하고 있지만, 기존 도구들을 어떻게 조합해야 할지 모르는 경우도 있음 - 도구는 의도적으로 강력하게 만들어졌고, 다른 팀이 전체 기능 범위를 다 이해한다고 볼 수 없음 - 실제로 원하는 것을 파악하면, 다른 목적으로 만든 기능이 사용자의 필요를 충족할 때가 많음 - **trace 분할** 요청이 대표적임 - 사용자는 긴 trace 안에 관심 구간이 있어 이를 잘라내고 싶다고 말함 - 이유는 성능과 시각화를 더 쉽게 만들기 위해서임 - 하지만 이 경우 애초에 긴 trace를 수집하지 않는 방식이 더 적합할 수 있음 - Perfetto에는 이미 [periodic trace snapshots](https://perfetto.dev/docs/getting-started/periodic-trace-snapshots)가 있음 - 하나의 긴 기록 대신 짧은 기록을 반복적으로 남기는 기능임 - 긴 trace를 수집한 뒤 나눌 필요 자체를 없애줌 - 사용자가 물어본 답과 실제로 필요한 답은 다를 수 있음 - “그게 정확히 필요했던 것”이라는 반응은 사용자가 생각한 요청이 아니라 실제 필요를 찾아냈다는 신호임 ### 제품이 바뀌어야 하는 경우 - 어떤 응답은 제품의 큰 변화로 이어질 수 있는 새로운 필요를 드러냄 - 이런 경우는 까다로움 - 요청이 새롭더라도 요청자가 실제로 무엇이 필요한지 명확히 말하지 못할 수 있음 - 기반 소프트웨어에서 잘못된 결정을 내리는 비용은 큼 - 그래서 없는 것이 실제로 아플 때까지 만들지 않는 쪽을 선호함 - 여러 팀이 같은 필요를 말하기 시작하면, 그때쯤 진짜로 만들 가치가 있는 핵심이 드러나기 쉬움 - 한 번의 요청만으로 이 핵심을 찾기는 매우 어렵기 때문에 기다림이 강력함 - Perfetto의 **임시 UI 커스터마이징**은 잘못된 결정의 예임 - 사람들은 워크플로에 맞게 UI를 해킹하고 싶어 했고, 그게 어렵다고 계속 불평함 - 이를 허용하자마자 막대한 기술 부채가 생김 - 새 기능마다 기존 모든 기능과 상호작용해야 했고, 전체 구조는 빠르게 확장 불가능해짐 - 제대로 된 plugin API를 설계해 이 문제에서 빠져나오는 데 약 1년이 걸림 - 실제 필요는 “모든 사용자에게 영향을 주지 않으면서 팀이나 사용 사례에 맞게 UI를 개인화하는 방법”이었음 - 이 필요는 처음부터 명확히 표현되지 않았음 - 요청 흐름 속에서 이를 일찍 포착하는 책임은 제품을 만드는 쪽에 있었음 - Perfetto trace를 “merge”할 수 있게 한 기능은 잘 처리한 예임 - 사람들이 계속 요청했지만 바로 만들지 않음 - 우회 방법을 안내하고 지켜보는 태도를 유지함 - 제대로 구현하려면 작업량이 크고 잘못 만들기 쉬운 기능임을 알고 있었음 - 문제 공간을 충분히 이해한 뒤 지난해 유지 가능한 방식으로 구현함 ### 핵심 교훈 - 첫 질문은 실제 질문이 아닌 경우가 많음 - 답하기 전에 왜 그런 질문을 하는지 물어야 함 - 어떤 경우에는 사용자가 도구를 어떻게 써야 하는지 배우게 됨 - 어떤 경우에는 제품 안의 올바른 경로가 숨겨져 있다는 사실이 드러남 - 어떤 경우에는 아직 만들 가치가 있는 것이 없다는 결론에 도달함 - 어떤 경우에는 다음 큰 기능을 두 번이 아니라 한 번에 제대로 만들 준비가 됨 - 단순하지만 건너뛰기 쉬운 기법임 - 빠르게 대응해야 한다는 압박은 계속 존재함 - 빠른 답변은 매번 생산적으로 느껴짐 - 그래도 한 걸음 물러나면 양쪽 모두 처음보다 더 많은 것을 얻는 경우가 거의 항상 많음 ## Comments ### Comment 57718 - Author: neo - Created: 2026-05-18T18:02:56+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/dt92ad/don_t_answer_first_question) - 글쓴이는 이 글이 XY 문제보다 훨씬 더 나아간다고 하지만, 오히려 **XY 문제**를 다루는 방법을 흥미로운 통찰과 함께 자세히 설명한 글로 보임 - 이 글이 **진짜로 XY 문제에 관한 글**이라고는 생각하지 않음. XY 문제보다 훨씬 넓게 적용되고, 답변하는 쪽이 “이건 XY 문제다”라고 가정하는 것만큼 위험하지도 않음 질문을 XY 문제로 프레이밍하면, XY 문제처럼 보이는 질문에 답할 때 사람들이 쓰는 역효과 나는 휴리스틱으로 다시 돌아갈 가능성이 큼 조언을 구하려다 주변 사람들이 내가 XY 문제를 겪고 있다고 단정해서, 내가 쓴 말을 제대로 읽어줄 사람에게 도달하기 전까지 계속 해명해야 했던 적이 셀 수 없이 많음. 프로그래밍 문화의 XY 문제 대응은 **보정이 잘못된 상태**라고 느끼고, 이 글은 그 오보정에 대한 반박처럼 읽힘 질문자가 나보다 훨씬 덜 안다고 느껴도 속도를 늦추고 패턴 매칭하지 않는 태도가 중요함. 애초에 XY 문제일 가능성이 압도적으로 높은 것도 아니고, 설령 맞더라도 아닌 것처럼 다루는 편이 나을 수 있음 - 좋은 글이었음. 질문받은 내용을 더 단순한 질문으로 바꿔서 그쪽에 답하지 않도록 조심해야 한다는, 같은 동전의 반대면 같은 얘기가 떠올랐음 예를 들면 “암스테르담과 샌프란시스코의 거리가 얼마인가요?”라는 질문에 “비행기로 12시간 걸립니다”라고 답하는 식임 질문은 **거리**에 관한 것이었지만, 거리를 아는 건 어렵고 비행시간은 더 흔히 떠올리기 쉬우니 답변자가 더 쉬운 질문으로 바꿔 답해버린 것임 이런 일이 꽤 자주 보이고, 특히 질문자와 답변자 사이에 **권력 거리**가 있을 때 더 흔한 듯함 - 여러 이유로 시스템 현대화 중에 **ingress 라우터**에 404 페이지를 추가했더니 문제가 생겼음. 한 개발자가 예전 404 동작을 돌려달라고 했는데, 예전 페이지에는 내비게이션 바와 메뉴가 있었기 때문임 더 캐묻자 일부 고객 설정에서는 로그인할 때 항상 404가 나고, 고객들이 예전 404 페이지를 통해 실제로 가야 할 곳으로 이동하고 있었다는 사실이 드러남 이런 순간을 위해 lolcry를 발명했음 🤣😭 - ```text > GET /hyrums-law HTTP/1.1 > Host: ingress.customer.doctor_eval.work > < HTTP/1.1 404 Not Found < Content-Type: text/plain < < API 사용자 수가 충분히 많아지면, < 계약에서 무엇을 약속했는지는 중요하지 않다: < 시스템에서 관찰 가능한 모든 동작은 < 누군가가 의존하게 된다. < ``` - @lalitm, 이 문제는 인터넷보다 오래됐고 이미 이름도 있음. 바로 **요구사항 분석**임 Ed Yourdon 등은 사용자가 얻고자 하는 결과인 **프로세스**와, 그 결과를 얻는 방법인 절차를 구분했음. 예를 들어 고객에게 주문이 발송됐다고 알리는 것은 프로세스이고, 그 정보를 이메일로 보내는 것은 절차임 시스템 사용자는 해법을 그 시스템의 기능처럼 생각하는 경향이 있음. 프로그래머도 예외가 아니라서 “X에서 Y를 풀기” 변형이 많은 것임. 분석가의 일은 특정 구현 형태에서 요구사항을 추출하는 것이고, 엔지니어로서는 그 뒤에 해법을 구현하면 됨 얼마 전 syslog(3)가 밀려서 이벤트가 로그에서 사라질 때가 있으니 로깅을 더 빠르게 만들자는 논의에 참여했음. 하지만 진짜 문제는 빠른 로깅이 아니었음. 사용자는 더 빠른 로깅을 원하는 게 아니라 문제를 해결하고 싶어 함. 필요한 정보를 제공하는 것이 프로세스이고, 모든 것을 로그에 쓰는 것은 그 방법 중 하나일 뿐임 Yourdon은 CASE 도구를 옹호한 사람 중 하나였음. 경영진이 품질과 생산성을 측정할 수 있었다면 성공했을지도 모르지만, 그건 다른 날 할 푸념임 - “잘못된 질문을 낳은 혼란 자체가 기회다”라고 하지만, 그 분야의 최고 전문가가 아니라면 어떤 질문이 **잘못됐다**고 처음부터 판단하기는 꽤 어려움 - 맞음. 게다가 어떤 조직의 특이한 사정이 그런 “잘못된” 질문으로 이어졌는지 시간을 들여 파악하는 일이 누구에게도 도움이 되지 않을 때가 있음 - 사실은 답해야 함 귀중한 정신적 자원을 지키는 문지기 역할을 하는 게 아니라면, 즉흥극의 전술처럼 “**네, 그리고…**”로 가면 됨. 물론 원하는 결과에 도달하는 다른 방법이 있을 수도 있다고 덧붙이면 됨 막힌 상황을 풀기 위해 한 가지 전략만 쓰지 말고, 가능한 전략을 전부 쓰는 편이 좋음 - 이 표현이 아주 좋음. 메시지가 헷갈릴 수 있는 경로는 무수히 많고, 문제의 뿌리를 찾도록 돕는 데는 여러 접근이 필요함. 그리고 당연히 헷갈린 쪽이 항상 상대방인 것도 아님