똑똑하게 질문하는 법

질문하는 장소를 신중하게 선택하세요. 다음과 같은 행동을 하면 무시당하거나 루저로 낙인찍힐 가능성이 높습니다:

해커들은 자신의 소통 채널이 무관한 내용으로 넘쳐나는 것을 막기 위해 부적절하게 보내진 질문을 무시합니다. 이런 일이 당신에게 일어나는 것을 원하지 않을 것입니다.

따라서 첫 번째 단계는 적절한 포럼을 찾는 것입니다. 구글과 다른 웹 검색 방법이 당신의 친구입니다. 문제를 일으키는 하드웨어나 소프트웨어와 가장 밀접하게 관련된 프로젝트 웹페이지를 찾는 데 사용하세요. 보통 FAQ(자주 묻는 질문) 목록과 프로젝트 메일링 리스트 및 아카이브 링크가 있을 것입니다. 이 메일링 리스트는 당신의 자체적인 노력(찾은 FAQ를 읽는 것 포함)으로 해결책을 찾지 못했을 때 도움을 구할 마지막 장소입니다.

• 주제에 맞지 않는 포럼에 질문을 올리는 것
• 고급 기술 질문이 기대되는 포럼에 매우 초보적인 질문을 올리거나, 그 반대의 경우
• 너무 많은 뉴스그룹에 동시에 게시하는 것
• 면식도 없고 개인적으로 문제 해결 책임도 없는 사람에게 개인 이메일을 보내는 것

검색한 다음, Stack Exchange에서 질문하세요.

최근 몇 년간 Stack Exchange 커뮤니티 사이트들이 기술적 질문과 기타 질문에 답하는 주요 자원으로 부상했으며, 많은 오픈 소스 프로젝트의 선호 포럼이기도 합니다.

Stack Exchange를 보기 전에 구글 검색부터 시작하세요. 구글은 실시간으로 색인합니다. 누군가 이미 비슷한 질문을 했을 가능성이 매우 높으며, Stack Exchange 사이트는 종종 검색 결과 상위에 나타납니다. 구글에서 아무것도 찾지 못했다면, 질문과 가장 관련 있는 특정 사이트에서 다시 검색하세요. 태그로 검색하면 결과를 좁히는 데 도움이 됩니다.

그래도 아무것도 찾지 못했다면, 가장 주제에 맞는 하나의 사이트에 질문을 올리세요. 서식 도구를 사용하고, 특히 코드에는 서식을 적용하며, 질문의 내용과 관련된 태그를 추가하세요 (특히 문제가 되는 프로그래밍 언어, 운영 체제, 또는 라이브러리의 이름). 댓글 작성자가 추가 정보를 요청하면, 원래 게시물을 편집하여 포함시키세요. 답변이 도움이 되면 위쪽 화살표를 클릭하여 추천하고, 답변이 문제를 해결했다면 투표 화살표 아래의 체크 표시를 클릭하여 정답으로 수락하세요.

지역 사용자 그룹이나 리눅스 배포판에서 초보자가 도움을 받을 수 있는 웹 포럼이나 IRC 채널을 안내할 수 있습니다. 이곳은 특히 비교적 단순하거나 흔한 문제에 부딪혔다고 생각될 때 질문하기 좋은 첫 번째 장소입니다.

웹 포럼에 게시하기 전에, 검색 기능이 있는지 확인하세요. 있다면, 당신의 문제와 비슷한 키워드로 몇 번 검색해 보세요. 도움이 될 수 있습니다.

IRC에서는 채널에 처음 들어가자마자 긴 문제 설명을 쏟아내지 않는 것이 좋습니다. 일부 사람들은 이것을 채널 도배로 해석합니다. 채널에서 대화를 시작할 수 있도록 한 줄짜리 문제 설명을 말하는 것이 가장 좋습니다.

프로젝트에 개발 메일링 리스트가 있다면, 누가 가장 잘 답할 수 있는지 안다고 생각하더라도 개별 개발자가 아닌 메일링 리스트에 글을 쓰세요. 프로젝트의 문서와 홈페이지에서 프로젝트 메일링 리스트의 주소를 확인하고 사용하세요.

프로젝트에 "사용자" 메일링 리스트와 "개발자" (또는 "해커") 메일링 리스트가 모두 있고, 당신이 코드를 해킹하는 것이 아니라면, "사용자" 리스트에서 질문하세요. 개발자 리스트에서는 당신의 질문이 개발 트래픽을 방해하는 소음으로 경험될 가능성이 높습니다.

메일링 리스트, 뉴스그룹, 또는 웹 포럼에서 제목은 약 50자 이내로 자격 있는 전문가의 관심을 끌 수 있는 황금 같은 기회입니다. "도와주세요"와 같은 헛소리로 낭비하지 마세요 ("도와주세요!!!!"는 더더욱 안 됩니다. 이런 제목의 메시지는 반사적으로 삭제됩니다). 고통의 깊이로 우리를 감동시키려 하지 마세요. 대신 그 공간을 초간결한 문제 설명에 사용하세요.

좋은 제목 규칙 중 하나는 많은 기술 지원 조직에서 사용하는 "대상 - 이상 현상" 형식입니다. "대상" 부분은 문제가 있는 것이 무엇인지를 지정하고, "이상 현상" 부분은 예상 동작과의 차이를 설명합니다.

"답장을 ...으로 보내주세요"로 질문을 끝내면 답변을 받지 못할 가능성이 매우 높습니다. 메일 에이전트에서 올바른 Reply-To 헤더를 설정하는 데 몇 초도 투자할 수 없다면, 우리도 당신의 문제에 대해 생각하는 데 몇 초도 투자할 수 없습니다.

웹 포럼에서 이메일로 답장을 요청하는 것은 명백히 무례합니다. 스레드에 누군가 답글을 달 때 이메일 사본을 원한다면, 웹 포럼에서 보내도록 요청하세요. 이 기능은 "이 스레드 구독", "답변 시 이메일 발송" 등의 옵션으로 거의 모든 곳에서 지원됩니다.

경험상 부주의하고 엉성한 글쓴이는 보통 부주의하고 엉성한 사고와 코딩을 합니다 (충분히 확률이 높습니다). 부주의하고 엉성한 사고를 하는 사람들의 질문에 답하는 것은 보람이 없습니다. 우리는 다른 곳에 시간을 쓰는 것을 선호합니다.

따라서 질문을 명확하고 잘 표현하는 것이 중요합니다. 그렇게 할 수 없다면, 우리도 관심을 기울일 수 없습니다. 언어를 다듬는 데 추가 노력을 기울이세요. 딱딱하거나 격식을 차릴 필요는 없습니다 — 사실, 해커 문화는 정확하게 사용된 비격식적이고, 속어적이고, 유머러스한 언어를 높이 평가합니다. 하지만 정확해야 합니다. 당신이 생각하고 주의를 기울이고 있다는 표시가 있어야 합니다.

영어가 아닌 포럼에서 질문하는 경우에도, 맞춤법과 문법 오류에 대해 약간의 여유는 있지만, 게으름에 대한 여유는 전혀 없습니다 (네, 우리는 보통 그 차이를 구별할 수 있습니다).

질문을 인위적으로 읽기 어렵게 만들면, 그렇지 않은 질문에 비해 무시될 가능성이 높습니다. 따라서:

일반 텍스트 메일을 보내세요, HTML이 아닌. MIME 첨부 파일은 보통 괜찮지만, 실제 콘텐츠(첨부된 소스 파일이나 패치 등)인 경우에만 그렇고, 메일 클라이언트가 생성한 보일러플레이트가 아닌 경우에만 그렇습니다.

해커들이 Microsoft Word나 Excel 같은 폐쇄적 독점 문서 형식을 읽을 수 있을 것이라고 절대 기대하지 마세요. 대부분의 해커들은 이런 것에 대해 현관 앞에 돼지 분뇨 더미가 쌓인 것과 비슷한 반응을 보입니다.

웹 포럼에서는 "스마일리"와 "HTML" 기능을 남용하지 마세요. 스마일리 한두 개는 보통 괜찮지만, 화려한 색상 텍스트는 사람들이 당신을 유치하다고 생각하게 만드는 경향이 있습니다.

문제나 버그의 증상을 주의 깊고 명확하게 설명하세요. 문제가 발생하는 환경(기기, OS, 애플리케이션 등)을 설명하세요. 배포판과 릴리스 버전을 제공하세요 (예: "Fedora Core 7", "Slackware 9.1" 등).

질문하기 전에 문제를 이해하기 위해 수행한 조사를 설명하세요. 문제를 직접 파악하기 위해 취한 진단 단계를 설명하세요. 컴퓨터나 소프트웨어 구성의 최근 변경 사항을 설명하세요.

가능하다면, 통제된 환경에서 문제를 재현할 수 있는 방법을 제공하세요. 이것은 특히 코드의 버그라고 생각되는 것을 보고할 때 중요합니다.

정확하고 상세해야 합니다. 이 목적은 단순히 방대한 양의 코드나 데이터를 도움 요청에 쏟아붓는 것으로는 달성되지 않습니다. 크고 복잡한 테스트 케이스가 프로그램을 망가뜨리고 있다면, 가능한 한 작게 줄여보세요.

이것은 최소 세 가지 이유로 유용합니다. 하나: 질문을 단순화하는 데 노력을 기울이는 것이 보이면 답변을 받을 가능성이 높아집니다. 둘: 질문을 단순화하면 유용한 답변을 받을 가능성이 높아집니다. 셋: 버그 보고서를 다듬는 과정에서 스스로 수정이나 해결 방법을 개발할 수 있습니다.

소프트웨어에 문제가 있을 때, 매우 매우 확실하지 않는 한 버그를 발견했다고 주장하지 마세요. 힌트: 문제를 수정하는 소스 코드 패치나 이전 버전에 대한 회귀 테스트를 제공할 수 없다면, 아마 충분히 확실하지 않은 것입니다.

문제가 당신에게만 발생하지 않는 다른 많은 사용자가 있다는 것을 기억하세요. 그렇지 않았다면 문서를 읽고 웹을 검색하면서 알게 되었을 것입니다. 이것은 아마도 소프트웨어가 아니라 당신이 무언가를 잘못하고 있을 가능성이 매우 높다는 것을 의미합니다.

질문할 때, 실제로 버그를 발견했다고 개인적으로 꽤 확신하더라도, 당신이 무언가를 잘못하고 있는 것처럼 글을 쓰는 것이 가장 좋습니다. 정말로 버그가 있다면, 답변에서 알게 될 것입니다.

무례하거나 거만하게 답변을 요구해서는 안 된다는 것을 이해한 일부 사람들은 반대 극단으로 후퇴하여 비굴해집니다. "저는 그저 한심한 초보 루저일 뿐이지만..." 이것은 산만하고 도움이 되지 않습니다. 실제 문제에 대한 모호함과 결합되면 특히 짜증납니다.

시간을 낭비하지 마세요, 우리의 시간도요. 대신, 배경 사실과 질문을 가능한 한 명확하게 제시하세요. 그것이 비굴해지는 것보다 자신을 위치시키는 더 나은 방법입니다.

해커들에게 당신이 문제의 원인이라고 생각하는 것을 말하는 것은 유용하지 않습니다. (당신의 진단 이론이 그렇게 대단하다면, 다른 사람에게 상담을 구하겠습니까?) 따라서, 해석과 이론이 아닌 무엇이 잘못되었는지의 원시 증상을 말하고 있는지 확인하세요. 해석과 진단은 그들이 하도록 하세요.

무엇이 잘못되었는지 파악하는 데 가장 유용한 단서는 종종 직전에 발생한 사건에 있습니다. 따라서, 당신이 정확히 무엇을 했고, 기기와 소프트웨어가 무엇을 했는지를 폭발 직전까지 설명해야 합니다.

설명이 길어지면 (약 4단락 이상), 문제를 맨 위에 간결하게 진술한 다음 시간순 이야기를 따르는 것이 유용할 수 있습니다. 그렇게 하면 해커들이 당신의 설명을 읽을 때 무엇을 주시해야 하는지 알 수 있습니다.

무언가를 하는 방법을 알아내려는 경우 (버그를 보고하는 것이 아닌), 목표를 설명하는 것부터 시작하세요. 그런 다음에야 막혀 있는 특정 단계를 설명하세요.

기술적 도움이 필요한 사람들은 종종 높은 수준의 목표를 마음에 두고 있으면서 목표를 향한 하나의 특정 경로에서 막힙니다. 그들은 그 단계에 대한 도움을 구하러 오지만, 경로가 잘못되었다는 것을 깨닫지 못합니다.

해커들은 문제 해결이 공개적이고 투명한 과정이어야 한다고 믿습니다. 이 과정에서 첫 번째 답변 시도가 더 지식이 있는 누군가가 불완전하거나 부정확하다는 것을 알아차리면 수정될 수 있고 수정되어야 합니다.

개인 답장을 요청하면, 이 과정과 보상을 모두 방해하게 됩니다. 이렇게 하지 마세요. 개인적으로 답장할지는 응답자의 선택입니다.

개방형 질문은 개방형 시간 낭비로 인식되는 경향이 있습니다. 유용한 답변을 줄 수 있는 사람들은 가장 바쁜 사람들이기도 합니다. 그런 사람들은 개방형 시간 낭비에 알레르기가 있으므로, 개방형 질문에도 알레르기가 있는 경향이 있습니다.

응답자에게 무엇을 해달라고 원하는지 (포인터 제공, 코드 전송, 패치 확인 등) 명확하게 하면 유용한 응답을 받을 가능성이 높아집니다. 이것은 그들의 노력에 초점을 맞추고, 응답자가 도움에 할당해야 하는 시간과 에너지에 암묵적으로 상한선을 둡니다.

어떤 종류의 문제를 찾아야 하는지 힌트를 주지 않고 다른 사람에게 깨진 코드를 디버깅해 달라고 요청하지 마세요. 수백 줄의 코드를 올리면서 "작동하지 않습니다"라고 말하면 무시당할 것입니다. 십여 줄의 코드를 올리면서 "7번째 줄 이후에 를 기대했지만 가 대신 발생했습니다"라고 말하면 응답을 받을 가능성이 훨씬 높습니다.

코드 문제에 대해 정확하게 설명하는 가장 효과적인 방법은 최소한의 버그 시연 테스트 케이스를 제공하는 것입니다. 최소 테스트 케이스란? 문제의 예시입니다. 바람직하지 않은 동작을 보여주기에 충분한 코드만 있으면 됩니다.

해커들은 숙제 질문을 잘 알아봅니다. 우리 대부분이 직접 해봤으니까요. 그 질문들은 당신이 경험에서 배울 수 있도록 당신이 풀어야 하는 것입니다. 힌트를 요청하는 것은 괜찮지만, 전체 해결책을 요청하는 것은 안 됩니다.

"누가 도와줄 수 있나요?" 또는 "답이 있나요?"와 같은 의미 없는 질문으로 도움 요청을 마무리하는 유혹을 참으세요. 첫째: 문제 설명을 반쯤이라도 제대로 작성했다면, 이런 추가 질문은 기껏해야 불필요합니다. 둘째: 불필요하기 때문에, 해커들은 이것을 짜증스럽게 여기며 "네, 도움을 받을 수 있습니다" 또는 "아니요, 당신을 위한 도움은 없습니다"와 같은 논리적으로 완벽하지만 무시하는 답변을 돌려줄 가능성이 높습니다.

그것은 당신의 문제이지, 우리의 문제가 아닙니다. 긴급함을 주장하는 것은 역효과를 낼 가능성이 매우 높습니다. 대부분의 해커들은 즉각적이고 특별한 관심을 끌려는 무례하고 이기적인 시도로 그런 메시지를 삭제할 것입니다.

예의를 갖추세요. "부탁드립니다"와 "관심 가져주셔서 감사합니다" 또는 "배려해 주셔서 감사합니다"를 사용하세요. 사람들이 무료로 도움을 주는 데 시간을 쓴다는 것에 감사하다는 것을 분명히 하세요.

솔직히 말해서, 이것은 문법적으로 정확하고, 명확하고, 정밀하고, 서술적이며, 독점 형식을 피하는 것만큼 중요하지 않습니다 (그리고 대체할 수도 없습니다). 해커들은 일반적으로 정중하지만 모호한 것보다 다소 무뚝뚝하지만 기술적으로 날카로운 버그 보고서를 선호합니다.

그러나, 기술적인 부분이 잘 갖춰져 있다면, 예의는 유용한 답변을 받을 확률을 높여줍니다.

문제가 해결된 후 도움을 준 모든 사람에게 메모를 보내세요. 어떻게 되었는지 알려주고 다시 한번 도움에 감사하세요. 문제가 메일링 리스트나 뉴스그룹에서 일반적인 관심을 끌었다면, 그곳에 후속 글을 올리는 것이 적절합니다.

후속 글은 길고 복잡할 필요가 없습니다. 간단한 "안녕하세요 — 네트워크 케이블 불량이었습니다! 감사합니다, 여러분. - 빌"이 아무것도 없는 것보다 낫습니다. 사실, 해결책에 진정한 기술적 깊이가 없다면 짧고 달콤한 요약이 긴 논문보다 낫습니다.

예의 바르고 유익할 뿐만 아니라, 이런 종류의 후속 글은 메일링 리스트/뉴스그룹/포럼의 아카이브를 검색하는 다른 사람들이 정확히 어떤 해결책이 도움이 되었는지 알 수 있게 해주어 그들에게도 도움이 될 수 있습니다.

"RTFM"이라는 답변을 받았다면, 보낸 사람은 당신이 매뉴얼을 읽었어야 한다고 생각합니다 (RTFM = Read The Fucking Manual). 그 사람이 거의 틀림없이 맞습니다. 가서 읽으세요.

RTFM에는 더 젊은 친척이 있습니다. "STFW"라는 답변을 받았다면, 보낸 사람은 당신이 웹을 검색했어야 한다고 생각합니다 (STFW = Search The Fucking Web). 그 사람이 거의 틀림없이 맞습니다. 가서 검색하세요.

이런 답변에 불쾌해하지 마세요. 해커 기준으로, 응답자는 당신을 무시하지 않은 것만으로도 당신에게 거친 종류의 존경을 보여주고 있는 것입니다. 대신 이 할머니 같은 친절함에 감사해야 합니다.

답변을 이해하지 못하겠다면, 즉시 설명을 요구하지 마세요. 원래 질문에 답을 찾으려고 사용했던 도구들 (매뉴얼, FAQ, 웹, 숙련된 친구)을 사용하여 답변을 이해하세요. 그런 다음에도 설명을 요청해야 한다면, 배운 것을 보여주세요.

해커 서클에서 무례해 보이는 많은 것들은 불쾌감을 주려는 의도가 아닙니다. 오히려, 문제 해결에 더 관심이 있는 사람들에게 자연스러운 직설적이고 헛소리를 걸러내는 소통 스타일의 산물입니다.

무례함을 감지했을 때, 침착하게 반응하려고 노력하세요. 누군가 정말로 막나가고 있다면, 리스트나 포럼의 선임자가 그 사람을 지적할 가능성이 매우 높습니다.