며칠을 막힌 채 보내면 본인도 지치고 일정도 밀립니다. 결국 물어야 할 것을 늦게 묻는 것뿐입니다.
이 파트에서 다루는 내용
질문은 민폐가 아니라 팀의 시간을 아끼는 일입니다
신입이 가장 많이 하는 오해가 질문하면 폐를 끼친다는 생각입니다. 그래서 막힌 채 며칠을 혼자 붙들고 있다가, 결국 5분이면 풀릴 문제였다는 걸 나중에 알게 됩니다.
팀 관점에서는 신입이 막혀서 하루를 날리는 것이 훨씬 큰 손해입니다. 적절한 질문은 팀 전체의 시간을 아낍니다.
다만 아무렇게나 묻는 것과 잘 묻는 것은 다릅니다. 이 파트는 그 차이를 다룹니다.
시도도 안 해 보고 바로 묻는 것도 문제입니다. 스스로 찾는 능력이 늘지 않고, 답하는 사람도 매번 처음부터 설명해야 합니다.
충분히 시도하되 적정 시점에 묻는 것. 이 균형을 잡는 기준이 다음 섹션의 15분 규칙입니다.
언제 물어야 하는지 기준을 정합니다
널리 쓰이는 방법 하나는 시간 기준입니다. 막혔을 때 일정 시간은 스스로 시도하고, 그 시간을 넘으면 묻는 것입니다. 흔히 15분에서 30분을 기준으로 삼습니다.
핵심은 그 시간 동안 아무것도 안 하고 기다리는 것이 아니라, 스스로 시도한 뒤에 묻는 것입니다. 그래야 질문의 질도 높아집니다.
- 오류 메시지를 정확히 읽습니다 (터미널 코스 연계)
- 로그를 확인하고 재현해 봅니다
- 관련 코드와 기존 사례를 찾아봅니다
- 공식 문서와 사내 위키를 봅니다
- 시도했는데 막혔을 때
- 여러 방향 중 판단이 필요할 때
- 위험한 작업이라 확인이 필요할 때
- 이미 정해진 관례가 있는지 모를 때
운영 장애, 데이터 손실 위험, 보안 문제는 시간 규칙과 무관하게 즉시 알립니다. 혼자 해결하려다 키우는 것이 가장 나쁩니다.
좋은 질문에는 형식이 있습니다
무엇을 하려는지, 무엇을 시도했는지, 어떤 결과가 나왔는지가 들어간 질문은 답하기 쉽습니다. 반대로 안 돼요 한 마디는 답하는 사람이 되물어야 해서 시간이 두 배로 듭니다.
질문을 형식에 맞춰 정리하는 과정에서 스스로 답을 찾는 경우도 많습니다. 이것을 러버덕이라고 부릅니다.
오류 메시지 전문, 실행 환경, 재현 절차를 함께 줍니다. 스택트레이스는 요약하지 말고 그대로 붙입니다. Caused by 아래가 진짜 원인일 수 있습니다.
아마 이것 때문인 것 같아요보다, 확인한 사실을 적습니다. 추측은 답하는 사람을 엉뚱한 방향으로 이끌 수 있습니다.
[하려는 것]
주문 생성 API에 재고 검증을 붙이려고 합니다.
[시도한 것]
OrderService.create 에서 StockService 를 주입받아 호출했습니다.
[결과 / 오류]
기동 시 순환 참조 오류가 납니다.
"The dependencies of some of the beans ... form a cycle"
[확인한 것]
StockService 도 OrderService 를 참조하고 있었습니다.
Spring Boot 코스 Part 3의 순환 참조 내용을 봤는데,
설계로 푸는 방향이라고 되어 있어 어떻게 나눌지 판단이 필요합니다.
[질문]
공통 로직을 제3의 클래스로 빼는 게 맞을까요?
아니면 다른 방법이 있을까요?이렇게 정리하면 답하는 사람이 맥락을 바로 파악합니다. 그리고 정리하다 보면 이미 절반은 스스로 답에 다가가 있습니다.
가능하면 기록이 남는 곳에 묻습니다
같은 질문은 여러 사람이 반복해서 하게 됩니다. 답이 기록에 남으면 다음 사람은 검색으로 찾을 수 있습니다. 특히 검색이 제한된 폐쇄망일수록 사내 기록의 가치가 큽니다.
개인 메시지보다 팀 채널에 묻습니다. 다른 사람도 답을 보고, 나중에 검색됩니다. 답하는 사람도 편한 시간에 답할 수 있습니다.
구두로 들은 답이나 개인 메시지로 받은 답을, 팀 위키나 문서에 정리해 둡니다. 같은 질문의 반복을 막고 본인 복습도 됩니다.
급하지 않으면 비동기로 남겨 두고 기다립니다. 정말 급한 것만 직접 부릅니다. 무엇이 급하고 안 급한지 구분하는 것도 능력입니다.
질문은 스스로 시도한 뒤에, 형식을 갖춰, 기록이 남는 곳에 합니다. 이 세 가지를 지키면 질문이 민폐가 아니라 팀의 자산이 됩니다. 잘 묻는 신입이 빨리 성장하고 팀에서도 환영받습니다.