첫 질문에 답하지 마라
요약
질문자가 던진 질문을 답변자가 임의로 단순화하거나 'XY 문제'로 단정 지어 답변하는 행위의 위험성을 경고합니다. 시스템의 관찰 가능한 모든 동작은 누군가에게 의존하게 된다는 점을 강조하며, 질문의 표면적인 방법(절차)이 아닌 근본적인 목적(프로세스)을 파악하는 태도가 중요함을 역설합니다.
핵심 포인트
- 질문을 XY 문제로 성급하게 프레이밍하면 질문자의 의도를 오해하고 잘못된 휴리스틱에 빠질 수 있음
- 답변자가 질문을 더 쉬운 질문으로 임의로 변형하여 답하는 것은 질문의 본질을 놓치는 결과를 초래함
- 시스템의 모든 동작은 사용자에게 의존성을 가지므로, 변경 시 신중한 접근이 필요함
- 사용자가 원하는 '결과(프로세스)'와 그것을 달성하는 '방법(절차)'을 구분하여 분석해야 함
- 질문이 잘못되었다고 판단하기 어렵더라도, 질문의 이면에 있는 맥락을 파악하려는 노력이 필요함
글쓴이는 이 글이 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 도구를 옹호한 사람 중 하나였음. 경영진이 품질과 생산성을 측정할 수 있었다면 성공했을지도 모르지만, 그건 다른 날 할 푸념임
“잘못된 질문을 낳은 혼란 자체가 기회다”라고 하지만, 그 분야의 최고 전문가가 아니라면 어떤 질문이 잘못됐다고 처음부터 판단하기는 꽤 어려움
맞음. 게다가 어떤 조직의 특이한 사정이 그런 “잘못된” 질문으로 이어졌는지 시간을 들여 파악하는 일이 누구에게도 도움이 되지 않을 때가 있음
사실은 답해야 함
귀중한 정신적 자원을 지키는 문지기 역할을 하는 게 아니라면, 즉흥극의 전술처럼 “네, 그리고…”로 가면 됨. 물론 원하는 결과에 도달하는 다른 방법이 있을 수도 있다고 덧붙이면 됨
막힌 상황을 풀기 위해 한 가지 전략만 쓰지 말고, 가능한 전략을 전부 쓰는 편이 좋음
이 표현이 아주 좋음. 메시지가 헷갈릴 수 있는 경로는 무수히 많고, 문제의 뿌리를 찾도록 돕는 데는 여러 접근이 필요함. 그리고 당연히 헷갈린 쪽이 항상 상대방인 것도 아님
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기