좋은 프로그래밍 질문은 어떻게 만들까

질문을 잘하는 사람은 단순히 예의를 잘 지키는 사람이 아니다. 자기 문제를 구조화해서 설명할 수 있는 사람이다.

초보자일수록 질문을 미루다가 오래 헤매거나, 반대로 너무 넓게 물어봐서 답을 들어도 바로 적용하지 못하는 경우가 많다.

그래서 질문의 기술은 사교의 기술이 아니라 문제 정의의 기술에 가깝다. 답변자가 편하려고 형식을 갖추는 것이 아니라, 형식을 갖추는 동안 질문자 자신이 문제를 다시 보게 되기 때문이다.

좋은 질문은 문제 설명부터 다르다

안 돼요 대신 무엇을 하려고 했고, 어디서, 어떤 메시지가 떴는지를 적으면 질문의 질이 급격히 올라간다. 이 과정에서 스스로 원인을 찾는 경우도 많다.

질문은 정답을 받아 오는 행위이기 전에, 현재 상태를 문장으로 정리하는 연습이다. 그리고 이 정리는 대화 상대가 사람이든 AI든 똑같이 효과가 있다.

같은 문제, 두 가지 질문

실제로 어떻게 달라지는지 보는 편이 빠릅니다. 아래는 흔히 올라오는 형태의 질문입니다.

BEFORE

파이썬 파일 읽기가 안 돼요. 계속 에러 나는데 왜 그런가요?
코드는 인터넷에서 본 그대로 썼습니다. 도와주세요.

답변자가 되물어야 할 것이 최소 네 가지다. 그래서 답이 늦어진다.

같은 상황을 아래처럼 쓰면, 답변자가 한 번에 대답할 수 있고 무엇보다 쓰는 사람 스스로 확인할 것이 생깁니다.

AFTER

[하려던 것] data.txt를 읽어 줄 수를 세려고 합니다.
[환경] macOS, Python 3.12, 터미널에서 python main.py 실행

[코드]
with open("data.txt") as f:
    print(len(f.readlines()))

[기대] 12 출력
[실제] FileNotFoundError: [Errno 2] No such file or directory: 'data.txt'
[시도] 파일 이름 철자 확인함. 같은 폴더에 있는 것도 확인함.

여섯 줄을 채우는 동안 대개 pwd를 찍어 볼 생각이 먼저 든다.

이 예시에서 원인은 대개 파일이 없어서가 아니라 실행 위치가 달라서다. 그런데 그 사실은 환경과 실행 명령을 적는 칸을 채우는 순간 드러난다. 형식이 답을 대신 찾아 주는 것이 아니라, 형식이 빠진 정보를 눈에 보이게 만드는 것이다.

한 가지 규칙

에러 메시지는 요약하지 말고 그대로 붙여 넣으십시오. 대충 이런 에러가 났다는 서술은 정보가 거의 없습니다. 반대로 코드는 전부 붙이지 말고, 문제를 재현하는 가장 짧은 형태로 줄이십시오.

질문 전에 적어 볼 항목

하려던 작업 한 문장
실행한 코드 또는 명령
운영체제, 언어 버전, 실행 방법
기대한 결과
실제로 나온 결과와 에러 전문
이미 시도해 본 해결책과 그 결과

질문을 던질 시점

언제 물어야 하는가도 자주 나오는 고민이다. 너무 빨리 물으면 스스로 찾는 힘이 안 붙고, 너무 늦게 물으면 하루를 통째로 날린다. 시간으로 자르는 것보다 상태로 자르는 편이 낫다.

기준은 이렇다. 새로운 시도가 떠오르는 동안에는 계속 해 본다. 그런데 아까 했던 것을 다시 하고 있다는 것을 알아차렸다면, 그때가 물어볼 시점이다. 같은 검색어를 두 번째 넣고 있거나, 이미 고쳤다가 되돌린 코드를 다시 고치고 있다면 혼자서는 더 진행되지 않는 상태다.

그 시점에 앞의 여섯 칸을 채우면 두 가지 중 하나가 일어난다. 채우다가 답을 찾거나, 답변자가 바로 답할 수 있는 질문이 완성되거나. 어느 쪽이든 반복하던 자리에서는 벗어난다.

재현 코드를 줄이는 것이 핵심이다

질문의 품질을 가장 크게 바꾸는 작업은 사실 문장 다듬기가 아니라 코드 줄이기다. 300줄짜리 파일을 통째로 올리면 답변자는 읽지 않는다. 대신 문제가 사라질 때까지 코드를 반씩 지워 보면, 대개 열 줄 안쪽으로 줄어든다.

그리고 이 축소 과정에서 절반 이상은 질문을 올리기 전에 답이 나온다. 지웠는데도 에러가 남았다면 원인은 지운 쪽이 아니고, 지웠더니 사라졌다면 원인은 방금 지운 쪽이다. 질문 준비가 그대로 디버깅이 되는 구간이다.

답을 받은 다음이 진짜다

질문의 가치는 답을 받는 순간이 아니라 그 답을 소화하는 순간에 결정된다. 초보자가 가장 많이 손해 보는 지점은 여기다. 코드가 왔고, 붙여 넣었고, 돌아갔다. 그리고 사흘 뒤 비슷한 문제에서 똑같이 막힌다.

그래서 답을 받은 뒤에 세 가지를 확인하는 습관이 필요하다. 첫째, 받은 코드에서 내 코드와 달라진 부분이 정확히 어디인지 짚는다. 둘째, 그 변경이 왜 문제를 없앴는지 한 문장으로 쓴다. 셋째, 그 한 문장을 내 메모에 남긴다. 세 번째까지 해야 다음에 같은 단어가 나왔을 때 기억이 떠오른다.

AI에게 물을 때도 구조는 같다. 오히려 AI는 되묻지 않고 그럴듯한 답을 바로 내놓기 때문에, 맥락을 빠뜨린 질문의 손해가 더 크다. 환경과 버전과 실제 에러 문장을 빼놓으면 존재하지 않는 함수 이름이 답으로 나오는 일도 드물지 않다. 사람에게 쓰던 여섯 칸 형식을 그대로 쓰는 편이 안전하다.

형식을 지나치게 지키면 생기는 문제

다만 이 조언을 문자 그대로 밀어붙이면 역효과가 난다. 옆자리 동료에게 한마디면 끝날 것을 열 줄짜리 템플릿으로 만들어 묻는 것은 서로의 시간을 쓰는 일이다. 대화가 오갈 수 있는 자리라면 한 문장으로 먼저 던지고, 되물음에 답하며 좁혀 가는 편이 빠르다.

형식이 정말 필요한 자리는 상대가 되물을 수 없는 곳이다. 공개 게시판, 이슈 트래커, 시차가 큰 팀 채널처럼 한 번 보내면 다음 답까지 시간이 걸리는 통로에서는 정보를 앞에서 다 주는 편이 이득이다. 또 하나, 완벽한 질문을 만들려다 하루를 통째로 쓰는 것도 지나치다. 삼십 분 넘게 같은 자리에서 막혀 있다면 불완전하더라도 일단 묻는 편이 낫다.

흔한 함정

질문에 내가 추측한 원인을 단정해서 쓰면 답변자가 그 추측에 갇힙니다. 아마 인코딩 문제인 것 같은데요 대신, 관찰한 사실과 추측을 분리해서 적으십시오.

문제를 잘 설명하는 순간, 이미 절반쯤은 스스로 이해하기 시작한 것이다.

학습 습관

더 볼 것

질문을 다듬는 일은 검색어를 다듬는 일과 뿌리가 같습니다. 검색을 잘하는 법을 같이 읽어 두면 좋고, 질문에 붙일 최소 재현 예제를 만드는 감각은 심층 가이드의 짧은 예제들을 따라 쳐 보며 익히는 편이 빠릅니다.

이 글의 포인트

좋은 질문은 문제의 맥락을 줄이지 않고 짧게 정리한다.
기대한 결과와 실제 결과를 나눠 적는 습관이 중요하다.
코드는 재현 가능한 최소 형태로 줄이고, 에러는 전문 그대로 붙인다.
되물을 수 있는 자리에서는 짧게 묻는 편이 더 낫다.
질문을 쓰는 과정 자체가 사고를 정리하는 훈련이 된다.