주니어 시절 질문하는 게 두려웠다. "이것도 모르나?"라는 반응이 올까 봐. 그래서 혼자 끙끙대면서 반나절을 쓰고, 결국 물어보면 5분 만에 해결되는 경우가 많았다.

시간이 지나면서 깨달은 건, 문제는 "질문을 한다/안 한다"가 아니라 "어떻게 질문하느냐"였다는 것이다.

나쁜 질문의 패턴#

"안 돼요" 질문

이거 안 되는데 어떻게 해야 하나요?

받는 사람 입장에서는 답할 수가 없다. 뭘 하려는지, 뭐가 안 되는지, 어디까지 해봤는지 모른다. "이거"가 뭔지부터 물어봐야 한다.

스크린샷 하나 던지기

에러 스크린샷만 올리고 아무 설명 없는 질문. 받는 사람이 스크린샷을 해독해야 한다. 에러 메시지를 텍스트로 복사해서 올리는 것만으로도 검색 가능하고, 맥락을 파악하기 쉬워진다.

"해주세요" 질문

이 기능 어떻게 만드나요? 코드 좀 짜주세요.

이건 질문이 아니라 업무 위임이다. 본인이 시도한 흔적이 없으면 답변하는 사람도 의욕이 안 난다.

좋은 질문의 구조#

좋은 질문에는 네 가지 요소가 있다:

1. 하려는 것 (Goal)

"Next.js에서 특정 페이지만 ISR로 동작하게 하려고 합니다."

2. 한 것 (Attempt)

"revalidate 옵션을 generateStaticParams에 넣어봤는데..."

3. 기대한 결과 (Expected)

"빌드 후 해당 페이지가 60초마다 재생성될 거라고 예상했습니다."

4. 실제 결과 (Actual)

"그런데 페이지가 항상 SSR로 동작합니다. x-nextjs-cache 헤더가 없습니다."

이걸 합치면:

Next.js 14에서 `/products/[id]` 페이지만 ISR로 동작하게 하려고
generateStaticParams에 revalidate: 60을 설정했는데,
배포 후 응답 헤더에 x-nextjs-cache가 없고 매 요청마다 서버에서
렌더링됩니다.

page.tsx의 관련 코드:
(코드 붙여넣기)

next.config.js:
(코드 붙여넣기)

Node.js 20, Next.js 14.1.0, Vercel 배포 환경입니다.

이 질문은 답변하는 사람이 바로 문제를 파악하고 해결 방향을 제시할 수 있다.

질문 전에 해야 할 것#

좋은 질문을 만드는 과정 자체가 디버깅이다. 놀라운 건, 질문을 정리하다 보면 스스로 답을 찾는 경우가 꽤 많다는 것이다.

"이런 상황에서 이걸 했는데 안 된다"를 정리하려면, 상황을 재현하고, 시도한 것을 나열하고, 기대와 현실의 차이를 명확히 해야 한다. 이 과정에서 "아, 이걸 안 해봤네"가 발견되기도 한다.

이걸 러버덕 디버깅이라고 부른다. 고무 오리에게 설명하듯이 문제를 말로 풀어보면, 생각이 정리되면서 답이 보인다. 질문을 쓰는 행위 자체가 생각을 정리하는 도구다.

그래서 실천하는 습관: 질문을 다 작성한 다음, 보내기 전에 5분만 더 고민한다. 그 5분 안에 답을 찾으면 좋고, 못 찾으면 잘 정리된 질문을 보내는 거다.

질문을 잘 하면 생기는 일#

답변 속도가 빨라진다. 맥락이 충분한 질문은 읽자마자 답할 수 있다. 추가 질문을 주고받는 핑퐁이 없어진다.

신뢰가 쌓인다. "이 사람은 충분히 고민하고 질문한다"는 인상을 주면, 다음에 질문할 때도 기꺼이 도와주는 사람이 생긴다.

본인의 문제 해결력이 올라간다. 질문을 정리하는 과정이 디버깅 훈련이다. 이걸 반복하면 질문하기 전에 스스로 해결하는 비율이 올라간다.

질문은 실력이 부족해서 하는 게 아니다. 시니어도 질문한다. 다만 시니어의 질문은 "이걸 모르겠다"가 아니라 "이 두 가지 접근 중 어떤 게 더 적합할까?"인 경우가 많다. 좋은 질문의 형태가 다를 뿐, 질문 자체를 멈추는 건 아니다.