[일]. 질문 잘하기
우연치 않게 네이버에 계신 프론트엔드 개발자 JBEE님의 NAVER DEVIEW 발표를 보게 되었다.
"질문하기" 라는 막연한 행동이 정리되었고 이 내용을 정리하고 잘된 예를 발견해서 공유하고자 한다.
https://jbee.io/essay/good_questionor/
질문하기는 보통 수업시간이 끝날 때 즈음 교수자가 권유하게 된다.
하지만 다들 알고 있듯이 한국에서는 공개적인 장소에서는 질문을 잘하지 않는다.
그래서 질문하는 학생들을 좋아하는 교수자들이 생겨났고
이런 것들을 보면서 "질문하는 것은 좋은 것이다"라는 생각과
질문을 한다는 것은 적극성을 나타내는 어필이라고 생각했다. ( 열심히 하고 있습니다!!.. )
그래서 무조건 질문하는 게 좋다, 쪽팔림을 두려워하지 말고 질문해서 답을 찾는 게 옳은 일이다.
하지만 위 생각들은 직장생활에서 상대방을 전혀 고려하지 않는 일이라는 것을 알게 되었고
질문을 무조건 많이 하는 게 좋은 것이 아니라
짧은 시간의 정확한 질문을 통해 정확한 답을 얻는 것이 좋은 질문이라는 생각을 하게 되었다.
직장에서의 질문하기와 돈을 내고 수업을 듣는 학생의 질문하기를 똑같이 생각하면 안된다!
역지사지로 단순 구글링만 해도 나오는 질문들을 나에게 계속한다면 피곤할 것이다.
질문 잘하기
1. 질문할 대상 찾기
문제가 발생했을 때 또는 모르는 것이 생겼을 때, 이를 해결할 수 있는 가장 빠른 방법은 자신의 상황을 잘 알고 있는 누군가에게 질문하는 것입니다. 그 누군가는 옆 동료가 될 수도 있고 멘토나 사수 등이 될 수 있습니다.
2. 질문하기 전 구글링 하기
당연히 위에서 말한 ‘문제’와 ‘모르는 것’은 구글링으로 해결되는 문제를 의미하지 않습니다.
우리가 마주하게 되는 대부분의 문제는 이미 웹 상에 그 해결책이 있습니다.
3. 질문할 대상을 배려하기(시간낭비를 줄이기)
무턱대고 ‘A’을 모른다고 하면 질문을 받는 사람 입장에서는 난처할 수밖에 없습니다. 그 이유는 다음과 같기 때문입니다.
- ‘A’와 관련된 내용을 정말 전부 모르는 것인가
- 그것이 아니라면 정확히 무엇이 문제인 것인가
- 무엇을 하다가 A까지 갔을까
- 현재 A로 무엇까지 해보았을까 (trial)
4. 질문 정리하기
1. 지금 이슈가 된 것이 무엇인가?
- 지금 개발 중인지, QA 중인지, 배포 후 긴급 대응인지
- 이슈가 발생한 환경은 무엇인지 (OS, 브라우저 등)
- 어떠한 상황에서 이슈가 발생했는지
2. 어디까지 해보았나?
- 발생한 이슈의 원인이 무엇이라고 생각하는가?
- 그 원인을 토대로 내린 결론은 무엇인가
- 결론대로 시도를 해보았는가
이러한 내용들이 담긴 질문을 한다면 답변자는 약간의 시간만 들여서 수월하게 문제를 함께 해결해볼 수 있습니다. 즉 답변자는 다음과 같은 액션을 취할 수 있습니다.
- 이슈의 원인을 다시 짚고 그에 따른 새로운 해결 방안을 제안
- 파악된 원인을 기반으로 다른 시도를 제안
- 올바른 방향의 결론이었다면 함께 디버깅을 진행
옳바른 예시 Tensorflow-KR에서 발취
 |
1. 자신의 수준을 먼저 이야기했다. -> 아마추어 개발자입니다. : 상대방은 아마추어가 알아들을 수 있도록 대답할 것임 2. 원하고자 하는 목표를 먼저 제시 -> flask 서버 간 실시간 통신을 구현하고 싶다. : 질문자의 목적을 명확하게 알아들을 수 있음 : 재질문 요소 제거 3. 세부 목표 제시 -> 실시간으로 보여주고싶다. : 현재 해결하고 싶은 세부 목표 : 정량적인 수치 표시 4. 어디까지 해봤나 -> socket.io 같은 걸로도 시도해봄 : 상대방이 수준을 파악하고 그 이후의 과정만 답변하면 되도록 함 5. 질문 최종 정리 -> 원하고자 하는 것을 최종 정리 |
좋은 발표와 자료를 써주신 https://jbee.io/ 님 감사합니다.