계속 반복되는 것 같아서 정리해서 글을 올립니다. 질문하는 요령에 대해서 얘기하고자 합니다.


1. 지나친 예의 제발

“질문해도 될까요?”
“뭔데요?”
“질문을 받아 주셔서 감사합니다.”

이런 메세지가 왔다 갔다 하는데 짧게는 수분, 길게는 몇시간 소요되기도 합니다. 이건 서로 시간만 낭비하는 겁니다. “질문해도 될까요?” 라는 질문은 오히려 예의를 갖추는게 아닙니다. synchronous(얼굴을 맞대고 있는 상황이나 전화 통화를 하는 상태)라면 모를까, asynchronous(메일, 메신저나 SNS와 같은 도구를 통한 커뮤니티를 할 때)의 경우에는 전달하고자 하는 내용을 한꺼번에 정리해서 질문을 하세요. 그래야만 답변자도 편하게 답변할 수 있습니다.


2. 화면 캡쳐 제발

코드를 질문할 때 IDE 화면 캡쳐해서 질문하지 마세요. 질문에 대한 답변을 위해 답변하는 사람 스스로가 질문으로 올라온 코드를 컴파일, 빌드하거나 실행까지 해 보는 경우도 있습니다. 이 경우 화면 캡쳐된 코드는 답변자의 입장에서 제대로 된 답변을 하기 어렵습니다. 화면에 보이는 코드 다시 짜보고 테스트해서 원인 알아 내어 자신에게 알려 달라는 격이니까요. 간단한 코드라면 ideone.com 이라는 사이트를 이용해 보는 것도 좋고, 코드의 범위가 넓은 경우 빌드가 가능한 full source를 git를 올려서 질문을 하는 것이 좋습니다.


3. 일부 코드 제발

일부 코드만 보여주면서 질문하지 마세요. 특정 메모리에 접근한다고 에러가 나는 상황에서 메모리 할당과 같은 변수 초기화를 했는지 안했는지(혹은 제대로 할당을 하였는지)를 확인해 봐야 하는데, 이 부분은 보여 주지 않으면서 포인터 변수 사용하는 부분만 캡쳐해서 “왜 여기에서 에러가 나죠?”라고 질문하면 답변하는 사람 입장에서는 답답할 수 밖에 없습니다.


4. 왈샥 화면 캡쳐 제발

네트워크 패킷의 경우 Wireshark 화면 캡쳐로 질문하지 마세요. 왈샥 캡쳐 화면은 제한된 정보 밖에 전달될 수 없습니다. pcap file을 명시하고 packet number를 명시하면서 질문을 하세요.


5. 가급적 스스로

조금만 생각해 보면 원인을 알아낼 수 있는 간단한 컴파일 에러나 런타임 에러 정도는 스스로 해결해 보도록 노력하세요. 문제라는 것은 언제나 발생할 수 있습니다. 중요한 건 앞으로도 닥치게 될 수많은 문제들을 어떻게 해결해 나가느냐 하는 겁니다. 남들에게 의존하지 말고 스스로 그 문제를 해결해 보도록 노력하세요. 그런 작은 노력 하나하나가 모여 결국 여러분의 실력이 되는 겁니다.