좋은 질문의 예술
Source: Dev.to
Overview
“There are no bad questions.”
기술 분야에서 흔히 쓰이는 말입니다. 의도는 좋습니다: 우리는 심리적 안전을 만들고, 주니어들이 도움을 요청하는 장벽을 낮추고 싶어합니다. 하지만 질문 뒤에 나쁜 의도가 없을지라도, 형편없이 구성된 질문은 분명 존재합니다. 문제 자체가 단순해서 나쁜 것이 아니라, 그 뒤에 있는 사고가 불완전하기 때문에 나쁜 것입니다.
최근 DevOps 커뮤니티 채팅에서 이 점을 다시 생각하게 되었습니다. 어떤 사람이 막힌 쿼리에 대한 도움을 요청했는데—맥락도, 제약도, 최종 목표에 대한 언급도 없었습니다. 사람들은 명확히 해달라고 물었지만, 뒤따른 질문들은 별다른 도움이 되지 않았습니다. 결국 그 스레드는 사라지고 말았습니다.
그 스레드에서 실제로 무너진 것은 지식이 아니라—사고의 분배였습니다.
Transferring the Load
우리는 질문을 단순히 정보 요청으로 보는 경향이 있습니다. 하지만 실제로 질문은 인지 부하(cognitive load) 를 전달하는 행위입니다.
모호한 질문을 하면 단순히 답을 요구하는 것이 아니라, 청자가 당신의 정신 모델을 재구성하고, 누락된 제약 조건을 추측하며, 해결책 공간을 처음부터 탐색하도록 요구하는 것입니다. 즉, 아직 당신이 하지 않은 작업을 청자에게 떠맡기는 것이죠.
잘 구성된 질문은 이미 그 작업의 무게를 담고 있습니다. 반면 형편없는 질문은 그 무게를 전부 청자에게 전가합니다. 그래서 모호한 질문이 “노력 부족”처럼 느껴지는 것입니다.
실제 차이
문제를 해결할 때 이 마찰을 가장 명확히 볼 수 있습니다.
고부하 질문
“내 배포가 작동하지 않아요. 내 머신에서는 작동하지만 프로덕션에서는 실패합니다. 뭐가 문제일까요?”
의미 있는 답변을 할 방법이 없습니다. 답변자는 추측 게임을 해야 합니다. 무엇을 배포하고 있나요? 어디에 배포하나요? “작동하지 않는다”는 정확히 무슨 의미인가요?
저부하 질문
“컨테이너화된 서비스를 Kubernetes에 배포하고 있습니다. 파드가 시작되지만 약 30초 후에 충돌합니다. 로그에는 데이터베이스 연결 시간 초과가 표시됩니다. 같은 네임스페이스의 다른 파드에서는 데이터베이스에 접근할 수 있습니다. 또 무엇을 확인해야 할까요?”
이 질문은 답변자의 시간을 존중합니다. 관찰된 동작, 제약 조건, 배제된 가능성을 포함하고 있습니다. 답변자가 답을 모른다 하더라도 다음에 어디를 살펴봐야 할지 알 수 있습니다.
XY 함정
좋은 질문을 만드는 것은 어려운 일입니다. 왜냐하면 문제의 형태를 이해하기 전에 마주하게 만들기 때문입니다. 이는 XY 문제—시도한 해결책(Y)을 고치려는 질문을 하는 대신 실제 근본 문제(X)를 묻는 것을 피하도록 강요합니다.
예를 들어, 실제 문제는 서비스가 아직 준비되지 않은 데이터베이스에 의존하고 있다는 것(X)인데, 연결 타임아웃을 늘리는 방법(Y)을 묻는 경우가 있습니다.
좋은 질문을 하려면 (X)의 현실을 되짚어 정의해야 합니다:
- 정확히 무엇이 실패하고 있나요?
- 실제로 달성하려는 결과는 무엇인가요?
- 어떤 가정을 하고 있나요?
이 질문들에 답하면 생각을 정리하게 됩니다. 그리고 여기서 흥미로운 일이 일어납니다: 질문을 준비하는 행위 자체가 문제를 해소하는 경우가 많습니다.
엔지니어들은 이를 자주 경험합니다. 버그 보고서를 작성하다가 레이스 컨디션이라는 사실을 깨닫고, 스태프 엔지니어에게 메시지를 초안하면서 중간에 해결책을 찾게 되는 경우가 바로 그것입니다. 답은 외부에서 온 것이 아니라, 혼란을 구조화해야 했기 때문에 스스로 떠오른 것입니다.
AI 평행
문제에 대한 이 엄격한 정의는 바로 현대 도구들이 우리에게 요구하는 바입니다.
대규모 언어 모델의 부상은 우리에게 이 교훈을 강제로 가르쳐 주었습니다.
그들은 이를 프롬프트 엔지니어링이라고 부르지만, 실제로는 단지 엄격한 질문일 뿐입니다.
ChatGPT에 모호한 프롬프트를 주면, 환상을 얻게 됩니다.
시니어 엔지니어에게 모호한 질문을 하면, “?”라는 회의 초대 거절을 받게 됩니다.
즉각적인 AI와 풍부한 답변이 넘치는 시대에, 질문의 품질은 더욱 중요해집니다. 명확함은 통찰을 만들고, 혼란은 단지 소음만을 만들어냅니다.
사전 전송 테스트
Before you ask a technical question—to a colleague, a forum, or an AI—run it through this filter. If you can’t answer these, the question isn’t ready.
- Context: 이것이 어디에서 실행되고 있으며, 작동하는 환경과 무엇이 다른가?
- Goal: 실제로 원하는 결과는 무엇인가 (현재 시도하고 있는 방법이 아니라)?
- Failure: 어떤 관찰 가능한 행동이 문제가 있음을 증명하는가?
- Attempts: 이미 배제한 설명은 무엇인가?
Treat questions as the final artifact of thinking rather than something you ask before thinking. When you can articulate the gap between what you know and what you need, you are usually already halfway to the answer. Good questions aren’t requests for answers; they are evidence of work already done.