▲

첫 질문에 답하지 마라

 (lalitm.com)
1P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • 성능 디버깅 도구에서 이상한 요청은 즉시 답하기보다 배경을 물어야 하며, 그래야 사용자의 실제 문제와 도구의 빈틈이 드러남
  • 이는 단순한 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”할 수 있게 한 기능은 잘 처리한 예임
    • 사람들이 계속 요청했지만 바로 만들지 않음
    • 우회 방법을 안내하고 지켜보는 태도를 유지함
    • 제대로 구현하려면 작업량이 크고 잘못 만들기 쉬운 기능임을 알고 있었음
    • 문제 공간을 충분히 이해한 뒤 지난해 유지 가능한 방식으로 구현함

핵심 교훈

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

함께 보면 좋은 글 β

▲
GN⁺ 2시간전  [-]
Lobste.rs 의견들

  • 글쓴이는 이 글이 XY 문제보다 훨씬 더 나아간다고 하지만, 오히려 XY 문제를 다루는 방법을 흥미로운 통찰과 함께 자세히 설명한 글로 보임

    • 이 글이 진짜로 XY 문제에 관한 글이라고는 생각하지 않음. XY 문제보다 훨씬 넓게 적용되고, 답변하는 쪽이 “이건 XY 문제다”라고 가정하는 것만큼 위험하지도 않음
      질문을 XY 문제로 프레이밍하면, XY 문제처럼 보이는 질문에 답할 때 사람들이 쓰는 역효과 나는 휴리스틱으로 다시 돌아갈 가능성이 큼
      조언을 구하려다 주변 사람들이 내가 XY 문제를 겪고 있다고 단정해서, 내가 쓴 말을 제대로 읽어줄 사람에게 도달하기 전까지 계속 해명해야 했던 적이 셀 수 없이 많음. 프로그래밍 문화의 XY 문제 대응은 보정이 잘못된 상태라고 느끼고, 이 글은 그 오보정에 대한 반박처럼 읽힘
      질문자가 나보다 훨씬 덜 안다고 느껴도 속도를 늦추고 패턴 매칭하지 않는 태도가 중요함. 애초에 XY 문제일 가능성이 압도적으로 높은 것도 아니고, 설령 맞더라도 아닌 것처럼 다루는 편이 나을 수 있음

  • 좋은 글이었음. 질문받은 내용을 더 단순한 질문으로 바꿔서 그쪽에 답하지 않도록 조심해야 한다는, 같은 동전의 반대면 같은 얘기가 떠올랐음
    예를 들면 “암스테르담과 샌프란시스코의 거리가 얼마인가요?”라는 질문에 “비행기로 12시간 걸립니다”라고 답하는 식임
    질문은 거리에 관한 것이었지만, 거리를 아는 건 어렵고 비행시간은 더 흔히 떠올리기 쉬우니 답변자가 더 쉬운 질문으로 바꿔 답해버린 것임
    이런 일이 꽤 자주 보이고, 특히 질문자와 답변자 사이에 권력 거리가 있을 때 더 흔한 듯함

  • 여러 이유로 시스템 현대화 중에 ingress 라우터에 404 페이지를 추가했더니 문제가 생겼음. 한 개발자가 예전 404 동작을 돌려달라고 했는데, 예전 페이지에는 내비게이션 바와 메뉴가 있었기 때문임
    더 캐묻자 일부 고객 설정에서는 로그인할 때 항상 404가 나고, 고객들이 예전 404 페이지를 통해 실제로 가야 할 곳으로 이동하고 있었다는 사실이 드러남
    이런 순간을 위해 lolcry를 발명했음 🤣😭

    • > 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 도구를 옹호한 사람 중 하나였음. 경영진이 품질과 생산성을 측정할 수 있었다면 성공했을지도 모르지만, 그건 다른 날 할 푸념임

  • “잘못된 질문을 낳은 혼란 자체가 기회다”라고 하지만, 그 분야의 최고 전문가가 아니라면 어떤 질문이 잘못됐다고 처음부터 판단하기는 꽤 어려움

    • 맞음. 게다가 어떤 조직의 특이한 사정이 그런 “잘못된” 질문으로 이어졌는지 시간을 들여 파악하는 일이 누구에게도 도움이 되지 않을 때가 있음

  • 사실은 답해야 함
    귀중한 정신적 자원을 지키는 문지기 역할을 하는 게 아니라면, 즉흥극의 전술처럼 “네, 그리고…”로 가면 됨. 물론 원하는 결과에 도달하는 다른 방법이 있을 수도 있다고 덧붙이면 됨
    막힌 상황을 풀기 위해 한 가지 전략만 쓰지 말고, 가능한 전략을 전부 쓰는 편이 좋음

    • 이 표현이 아주 좋음. 메시지가 헷갈릴 수 있는 경로는 무수히 많고, 문제의 뿌리를 찾도록 돕는 데는 여러 접근이 필요함. 그리고 당연히 헷갈린 쪽이 항상 상대방인 것도 아님
답변달기