소개
해커의 세계에서, 기술 문제를 던졌을 때 궁극적으로 유용한 답변을 얻을 수 있는지는 종종 질문하고 추궁하는 방식에 달려 있습니다. 이 가이드는 만족스러운 답변을 얻기 위해 올바르게 질문하는 방법을 가르칩니다.
해커뿐만 아니라, 지금 오픈소스(Open Source) 소프트웨어가 상당히 성행하여, 당신은 종종 다른 경험 많은 사용자로부터 좋은 답변을 얻을 수 있습니다. 이것은 좋은 일입니다. 사용자는 해커보다 초보자가 자주 겪는 문제에 더 관대한 경향이 있습니다. 그러나 경험 많은 사용자를 해커로 간주하고, 이 가이드에서 제안하는 방법으로 그들과 소통하는 것도 그들로부터 만족스러운 답변을 얻을 수 있는 가장 효과적인 방법입니다.
먼저 당신은 해커들이 도전적인 문제나 그들의 사고를 자극하는 좋은 질문을 좋아한다는 것을 이해해야 합니다. 우리가 그렇지 않다면, 우리는 당신이 묻고 싶은 대상이 되지 않았을 것입니다. 당신이 우리에게 되새김질할 가치가 있는 좋은 질문을 주면, 우리는 당신에게 감사할 것입니다. 좋은 질문은 동기부여이자 선물입니다. 좋은 질문은 우리의 이해력을 높일 수 있으며, 종종 우리가 이전에 인식하지 못했거나 생각하지 않았던 문제를 드러냅니다. 해커에게 “좋은 질문!”은 진심 어린 큰 칭찬입니다.
그럼에도 불구하고, 해커들은 간단한 문제를 멸시하거나 오만하게 대하는 나쁜 평판을 가지고 있으며, 이것은 때때로 우리가 초보자와 무지한 사람들에게 적대적으로 보이게 하지만, 실제로는 그렇지 않습니다.
우리는 생각하기를 원하지 않거나 질문하기 전에 해야 할 일을 하지 않는 사람들에 대한 우리의 경멸을 숨기지 않습니다. 그런 사람들은 시간 살인자입니다 —— 그들은 받기만 하고, 결코 주지 않으며, 우리가 더 흥미로운 문제나 대답할 가치가 있는 사람들에게 쓸 수 있는 시간을 소비합니다. 우리는 그런 사람들을 실패자(루저)라고 부릅니다(역사적 이유로, 우리는 때때로 lusers라고 표기합니다).
우리는 많은 사람들이 우리가 쓴 소프트웨어를 사용하기만 원하며, 기술적 세부 사항을 배우는 데 관심이 없다는 것을 인식합니다. 대부분의 사람들에게 컴퓨터는 도구이며, 목적을 달성하기 위한 수단일 뿐입니다. 그들은 자신의 삶이 있고 더 중요한 일이 있습니다. 우리는 이것을 이해하며, 우리를 매료시키는 이러한 기술 문제에 모든 사람이 관심을 가질 것이라고 기대하지 않습니다. 그럼에도 불구하고, 우리가 질문에 대답하는 스타일은 이에 진정으로 관심이 있고 문제 해결에 적극적으로 참여할 의향이 있는 사람들을 가리킵니다. 이것은 변하지 않으며, 변해서도 안 됩니다. 이것이 변하면, 우리는 우리가 가장 잘하는 일에서 효율성을 떨어뜨리는 것입니다.
우리는 (대체로) 자발적으로 바쁜 삶에서 시간을 내어 의문을 풀어주며, 종종 질문에 압도됩니다. 따라서 우리는 일부 주제를 무자비하게 걸러내고, 특히 실패자처럼 보이는 사람들을 버려서 승자(winner)의 질문에 대답하는 데 시간을 더 효율적으로 사용합니다.
당신이 우리의 태도, 거만함, 또는 지나친 오만함을 싫어한다면, 우리의 입장이 되어 생각해 보세요. 우리는 당신이 우리에게 굴복하기를 요구하지 않습니다 —— 사실, 우리 대부분은 당신과 평등하게 교류하는 것을 매우 기뻐하며, 당신이 기본 요구 사항을 충족하기 위해 작은 노력을 기울이면 우리는 당신을 우리 문화에 환영할 것입니다. 그러나 스스로를 돕고 싶어하지 않는 사람들을 돕게 하는 것은 비효율적입니다. 무지는 괜찮지만, 바보인 척하는 것은 안 됩니다.
따라서, 당신은 우리의 주의를 끌기 위해 기술적으로 능숙할 필요는 없지만, 당신이 능숙해지도록 이끌 수 있는 특질 —— 기민함, 생각, 관찰력, 문제 해결에 적극적으로 참여하는 의향 —— 을 보여주어야 합니다. 당신이 이러한 것들을 할 수 없다면, 우리는 당신이 돈을 써서 상업 회사와 기술 지원 서비스 계약을 맺고, 해커 개인에게 무상으로 도움을 요구하는 대신 그렇게 할 것을 제안합니다.
당신이 우리에게 도움을 요청하기로 결정했다면, 물론 당신은 실패자로 간주되기를 원하지 않으며, 실패자 중 한 명이 되기를 원하지 않을 것입니다. 빠르고 효과적인 답변을 즉시 얻을 수 있는 가장 좋은 방법은 승자처럼 질문하는 것입니다 —— 똑똑하고, 자신감 있고, 문제 해결에 대한 생각이 있으며, 가끔 특정 문제에서 약간의 도움이 필요합니다.
(이 가이드에 대한 개선 제안을 환영합니다. 이메일로 제안을 esr@thyrsus.com 또는 respond-auto@linuxmafia.com로 보낼 수 있습니다. 그러나 이 글은 네티켓의 일반 가이드가 아니며, 우리는 일반적으로 기술 포럼에서 유용한 답변을 얻는 데 도움이 되지 않는 제안을 거부합니다.)
질문하기 전에
이메일, 뉴스그룹 또는 채팅방을 통해 기술 문제를 제기하기 전에 다음을 먼저 하세요:
- 질문하려는 포럼의 이전 글에서 답변을 검색해 보세요.
- 인터넷 검색으로 답변을 찾아보세요.
- 매뉴얼을 읽고 답변을 찾아보세요.
- FAQ(자주 묻는 질문) 파일을 읽고 답변을 찾아보세요.
- 직접 확인하거나 실험하여 답변을 찾아보세요.
- 주변의 뛰어난 친구에게 물어보고 답변을 찾아보세요.
- 프로그램 개발자라면, 소스 코드를 읽고 답변을 찾아보세요.
질문할 때, 위의 노력을 했다는 것을 먼저 표시하세요. 이것은 당신이 불로소득을 원하지 않고 다른 사람의 시간을 낭비하지 않는 질문자임을 보여주는 데 도움이 됩니다. 위의 노력을 하는 과정에서 배운 것을 함께 표현하면 더 좋습니다. 왜냐하면 우리는 답변에서 배울 수 있는 능력을 보여주는 사람들의 질문에 더 기꺼이 대답하기 때문입니다.
일부 전략을 사용하세요. 예를 들어, 먼저 Google에서 발생한 다양한 오류 메시지를 검색하면(Google 그룹과 웹페이지 모두 검색), 문제를 해결할 수 있는 파일이나 메일링 리스트 스레드를 직접 찾을 수 있습니다. 결과가 없더라도, 메일링 리스트나 뉴스그룹에서 도움을 요청할 때 Google에서 다음 문장을 검색했지만 유용한 것을 찾지 못했습니다라고 덧붙이는 것은 좋은 일입니다. 검색 엔진이 어떤 도움을 제공할 수 없는지 보여주기만 하더라도 마찬가지입니다. 이렇게 하면(검색한 문자열 포함) 비슷한 문제를 겪는 다른 사람들이 검색 엔진을 통해 당신의 질문으로 안내될 수 있습니다.
서두르지 마세요. 몇 초의 Google 검색으로 복잡한 문제를 해결할 것으로 기대하지 마세요. 전문가에게 도움을 요청하기 전에, FAQ를 다시 읽고, 편안하게 앉아, 이 문제에 대해 시간을 내어 생각해 보세요. 우리를 믿으세요, 그들은 당신의 질문에서 얼마나 많이 읽고 생각했는지 알 수 있습니다. 준비를 하고 오면 답변을 받을 가능성이 더 높습니다. 첫 번째 검색에서 답변을 찾지 못했다고(또는 너무 많은 답변을 찾았다고) 해서 모든 질문을 한꺼번에 던지지 마세요.
질문을 준비하고, 신중하게 다시 생각해 보세요. 성급한 질문은 성급한 답변만 얻거나, 아무런 답변도 얻지 못할 수 있습니다. 도움을 요청하기 전에 문제를 해결하기 위해 노력했다는 것을 보여줄수록, 실질적인 도움을 받을 가능성이 높아집니다.
잘못된 질문을 하지 않도록 주의하세요. 당신의 질문이 잘못된 가정에 기반한다면, 어떤 일반적인 해커(J. Random Hacker)는 마음속으로 바보 같은 질문...이라고 생각하면서, 무의미한 글자 그대로의 해석으로 답변하여, 당신이 질문의 답변(원하는 답이 아닌)에서 교훈을 얻기를 바랄 것입니다.
절대 답변을 받을 자격이 있다고 생각하지 마세요. 당신은 자격이 없습니다. 결국 당신은 이 서비스에 대해 어떤 보상도 지불하지 않았습니다. 당신은 내용이 있고, 흥미롭고, 사고를 자극하는 질문 —— 커뮤니티 경험에 기여할 수 있는 잠재력이 있는 질문 —— 을 제기함으로써 스스로 답변을 얻어야 합니다. 단순히 다른 사람으로부터 지식을 수동적으로 받아들이는 것이 아니라.
반면에, 답변을 찾는 과정에서 무언가를 할 의향이 있다는 것을 표시하는 것은 매우 좋은 시작입니다. 누가 힌트를 줄 수 있나요?, 내 예제에서 무엇이 빠졌나요?, 어디를 확인해야 하나요?가 필요한 정확한 과정을 게시해 주세요보다 답변을 받기 쉽습니다. 왜냐하면 누군가가 올바른 방향을 가리켜주면, 그것을 완성할 능력과 결심이 있다는 것을 보여주기 때문입니다.
질문할 때
질문할 포럼 신중하게 선택
질문할 장소를 신중하게 선택하세요. 다음을 하면 무시되거나 실패자로 간주될 가능성이 높습니다:
- 주제와 맞지 않는 포럼에 질문을 게시.
- 고급 기술 문제를 논의하는 포럼에 매우 초보적인 질문을 게시; 또는 그 반대.
- 너무 많은 다른 뉴스그룹에 동일한 질문을 반복해서 게시(교차 게시).
- 친분도 없고 당신의 문제를 해결할 의무도 없는 사람에게 개인 이메일을 보냄.
해커는 잘못된 장소에 있는 질문을 걸러내어, 그들의 소통 채널이 무관한 것들로 넘쳐나지 않도록 보호합니다. 당신은 이런 일이 자신에게 일어나기를 원하지 않을 것입니다.
따라서 첫 번째 단계는 올바른 포럼을 찾는 것입니다. 다시 말하지만, Google과 다른 검색 엔진은 여전히 당신의 친구입니다. 그것들을 사용하여 어려움을 겪고 있는 하드웨어/소프트웨어 문제와 가장 관련 있는 웹사이트를 찾으세요. 보통 그곳에는 FAQ, 메일링 리스트 및 관련 설명 파일에 대한 링크가 있습니다. 당신의 노력(FAQ 읽기 포함)이 결과가 없다면, 웹사이트에 버그 보고(Bug-reporting) 프로세스나 링크가 있을 수 있습니다. 그렇다면, 링크를 따라가 보세요.
낯선 사람이나 포럼에 이메일을 보내는 것은 가장 위험할 수 있습니다. 예를 들어, 풍부한 콘텐츠를 제공하는 웹페이지의 저자가 당신의 무료 컨설턴트가 되기를 원한다고 가정하지 마세요. 당신의 질문이 환영받을지 너무 낙관적으로 추정하지 마세요 —— 확실하지 않다면, 다른 곳으로 보내거나, 아예 보내지 마세요.
포럼, 뉴스그룹 또는 메일링 리스트를 선택할 때, 이름을 너무 믿지 말고, 먼저 FAQ나 허가서를 확인하여 당신의 질문이 주제에 맞는지 확인하세요. 게시하기 전에 기존 주제를 훑어보면, 그곳의 문화를 느낄 수 있습니다. 사실, 미리 뉴스그룹이나 메일링 리스트의 기록에서 당신의 질문과 관련된 키워드를 검색하는 것은 훌륭한 아이디어이며, 이렇게 하면 답변을 찾을 수도 있습니다. 없더라도, 더 나은 질문을 정리하는 데 도움이 됩니다.
모든 도움 채널에 기관총처럼 한 번에 “쏘지” 마세요. 이것은 소리치는 것처럼 사람들을 불쾌하게 합니다. 하나씩 하세요.
당신의 주제를 명확히 하세요! 가장 전형적인 실수 중 하나는 크로스 플랫폼 이식성에 전념하는 언어, 패키지 또는 도구의 포럼에서 Unix 또는 Windows 운영 체제 프로그램 인터페이스에 대한 질문을 하는 것입니다. 왜 이것이 큰 실수인지 이해하지 못한다면, 그 차이를 명확히 할 때까지 아무것도 묻지 않는 것이 좋습니다.
일반적으로, 신중하게 선택한 공개 포럼에서 질문하는 것이 비공개 포럼에서 동일한 질문을 하는 것보다 유용한 답변을 얻기 더 쉽습니다. 이를 뒷받침하는 몇 가지 이유가 있습니다. 첫째, 잠재적 답변자가 얼마나 많은지, 둘째, 관중이 얼마나 많은지입니다. 해커는 많은 사람들에게 도움이 될 수 있는 질문에 더 기꺼이 대답합니다.
이해할 수 있듯이, 노련한 해커와 인기 있는 소프트웨어의 저자들은 너무 많은 잘못 보낸 메시지를 받고 있습니다. 낙타의 등을 부러뜨리는 마지막 짚단처럼, 당신의 참여도 상황을 극단으로 몰고 갈 수 있습니다 —— 이미 여러 번, 인기 있는 소프트웨어의 일부 저자들이 자신의 소프트웨어 지원에서 손을 떼었습니다. 왜냐하면 그에 따라 개인 이메일로 쏟아지는 무용지물 메일이 견딜 수 없게 되었기 때문입니다.
Stack Overflow
검색하고, 그 다음 Stack Exchange에서 물어보세요.
최근 몇 년간, Stack Exchange 커뮤니티는 기술 및 기타 질문에 답변하는 주요 채널이 되었으며, 특히 오픈소스 프로젝트의 경우 더욱 그렇습니다.
Google 인덱스가 즉각적이므로, Stack Exchange를 보기 전에 먼저 Google에서 검색하세요. 누군가가 비슷한 질문을 했을 확률이 높으며, Stack Exchange 웹사이트들은 종종 검색 결과 중 가장 앞에 나타납니다. Google에서 아무런 답변도 찾지 못했다면, 특정 관련 주제의 웹사이트로 가서 찾아보세요. 태그(Tag) 검색을 사용하면 검색 결과를 더 좁힐 수 있습니다.
Stack Exchange는 100개 이상의 사이트로 성장했으며, 다음은 가장 자주 사용되는 몇 가지입니다:
- Super User는 일반적인 컴퓨터 질문을 합니다. 질문이 코드나 프로그래밍과 관련이 없고, 단순히 네트워크 연결 등이라면, 여기로 가세요.
- Stack Overflow는 프로그래밍 관련 질문을 합니다.
- Server Fault는 서버 및 네트워크 관리 관련 질문을 합니다.
웹사이트 및 IRC 포럼
로컬 사용자 그룹(user group) 또는 사용하는 Linux 배포판이 웹 포럼이나 IRC 채널을 홍보하고 있으며, 초보자 도움을 제공할 수 있습니다(일부 비영어권 국가에서는 초보자 포럼이 여전히 메일링 리스트일 수 있음). 이러한 곳은 질문을 시작하기에 좋은 첫 번째 선택이며, 특히 상대적으로 간단하거나 일반적인 문제라고 느낄 때 더욱 그렇습니다. 광고 후원 IRC 채널은 공개적으로 질문을 환영하며, 보통 즉각적인 응답을 받을 수 있습니다.
사실, 프로그램 문제가 특정 Linux 배포판에서 제공하는 버전에서만 발생한다면(이것은 흔함), 먼저 해당 배포판의 포럼이나 메일링 리스트에서 질문한 다음, 프로그램 자체의 포럼이나 메일링 리스트에서 질문하는 것이 좋습니다. (그렇지 않으면) 해당 프로젝트의 해커는 단순히 “우리 버전을 사용하세요”라고 답변할 수 있습니다.
모든 포럼에 게시하기 전에 검색 기능이 있는지 확인하세요. 있다면, 문제의 몇 가지 키워드를 검색해 보세요. 이것이 도움이 될 수 있습니다. 이전에 일반적인 웹 검색을 했더라도(해야 함), 포럼을 다시 검색하세요. 검색 엔진이 이 포럼의 모든 콘텐츠를 인덱싱하지 못했을 수 있습니다.
포럼이나 IRC 채널을 통해 사용자 지원 서비스를 제공하는 추세가 증가하고 있으며, 이메일은 대부분 프로젝트 개발자 간의 교류를 위해 보존됩니다. 따라서 먼저 포럼이나 IRC에서 해당 프로젝트와 관련된 도움을 구하는 것이 좋습니다.
IRC를 사용할 때, 먼저 긴 문제 설명을 게시하지 않는 것이 좋습니다. 일부 사람들은 이것을 채널 홍수라고 부릅니다. 한 문장의 문제 설명으로 채팅을 시작하는 것이 좋습니다.
두 번째, 프로젝트 메일링 리스트 사용
어떤 프로젝트가 개발자 메일링 리스트를 제공할 때, 개별 구성원이 아닌 리스트에 질문하세요. 그가 당신의 질문에 가장 잘 대답할 수 있다고 확신하더라도 마찬가지입니다. 프로젝트의 파일과 홈페이지를 확인하여 프로젝트의 메일링 리스트를 찾고 사용하세요. 이 방법을 채택하는 몇 가지 좋은 이유가 있습니다:
- 개별 개발자에게 질문할 만큼 좋은 질문은 전체 프로젝트 그룹에도 유익합니다. 반대로, 당신의 질문이 전체 프로젝트 그룹에 너무 어리석다고 생각한다고 해서, 개별 개발자를 괴롭히는 이유가 되지 않습니다.
- 리스트에 질문하면 개발자의 부담을 분산시킬 수 있습니다. 개별 개발자(특히 프로젝트 리더)는 너무 바빠서 당신의 질문에 대답할 수 없을 수 있습니다.
- 대부분의 메일링 리스트는 보관되며, 보관된 콘텐츠는 검색 엔진에 의해 인덱싱됩니다. 리스트에 질문하고 답변을 받으면, 다른 사람들이 웹 검색을 통해 당신의 질문과 답변을 찾을 수 있어, 다시 질문할 필요가 없습니다.
- 일부 질문이 자주 묻는다면, 개발자는 이 정보를 활용하여 설명 파일이나 소프트웨어 자체를 개선하여 더 명확하게 만들 수 있습니다. 개인적으로 질문하면, 가장 일반적인 질문의 전체 시나리오를 볼 수 있는 사람이 없습니다.
프로젝트에 “사용자”와 “개발자”(또는 “해커”) 메일링 리스트 또는 포럼이 있고, 당신이 소스 코드를 건드리지 않는다면, “사용자” 리스트 또는 포럼에 질문하세요. 개발자 리스트에서 환영받을 것이라고 가정하지 마세요. 그 사람들은 대부분 당신의 질문을 그들의 개발을 방해하는 소음으로 간주할 것입니다.
그러나 당신의 질문이 특별하다고 확신하고, “사용자” 리스트 또는 포럼에서 며칠 동안 답변이 없다면, “개발자” 리스트 또는 포럼에서 질문해 보세요. 게시하기 전에 며칠 동안 몰래 관찰하여 그곳의 방식을 이해하는 것이 좋습니다(사실 이것은 모든 비공개 또는 반비공개 리스트에 참여하는 좋은 아이디어입니다).
프로젝트의 메일링 리스트를 찾을 수 없고, 프로젝트 관리자의 이메일 주소만 찾을 수 있다면, 그에게 이메일을 보내세요. 이 경우에도 (프로젝트) 메일링 리스트가 존재하지 않는다고 가정하지 마세요. 이메일에서 적절한 메일링 리스트를 찾으려고 했지만 찾지 못했다고 진술하고, 당신의 이메일을 다른 사람에게 전달하는 것에 반대하지 않는다고 언급하세요(많은 사람들이 비밀이 없더라도 개인 이메일은 공개되어서는 안 된다고 생각합니다. 당신의 이메일을 다른 사람에게 전달하도록 허용함으로써, 해당 인원에게 당신의 이메일을 처리할 선택권을 줍니다).
의미 있고 명확한 제목 사용
메일링 리스트, 뉴스그룹 또는 포럼에서 약 50자 이내의 제목은 숙련된 전문가의 주의를 끌 수 있는 좋은 기회입니다. 지루한 도와주세요, 무릎 꿇고 부탁, 급함(더 심하게 살려주세요!!!!와 같이 반감을 사는 말, 이런 제목은 조건 반사적으로 무시됨)으로 이 기회를 낭비하지 마세요. 당신의 고통 정도로 우리를 감동시키려 하지 말고, 이 공간에서 매우 간결한 설명 방식으로 질문을 제기하세요.
좋은 제목 예시는 목표 —— 차이 식 설명이며, 많은 기술 지원 조직이 이렇게 합니다. 목표 부분에서 어떤 것 또는 어떤 그룹에 문제가 있는지 지적하고, 차이 부분에서 예상되는 동작과 일치하지 않는 부분을 설명합니다.
바보 같은 질문: 살려주세요! 제 노트북 화면이 정상적으로 표시되지 않아요!
똑똑한 질문: X.org 6.8.1의 마우스 커서가 변형됩니다. 어떤 브랜드 그래픽 카드 MV1005 칩셋.
더 똑똑한 질문: X.org 6.8.1의 마우스 커서가 어떤 브랜드 그래픽 카드 MV1005 칩셋 환경에서 - 변형됩니다.
목표 —— 차이 식 설명을 작성하는 과정은 문제에 대한 세밀한 생각을 정리하는 데 도움이 됩니다. 무엇이 영향을 받았나요? 마우스 커서뿐인가요 아니면 다른 그래픽도 있나요? X.org의 X 버전에서만 나타나나요? 아니면 6.8.1 버전에서만 나타나나요? 어떤 브랜드 그래픽 카드 칩셋인가요? 아니면 그중 MV1005 모델뿐인가요? 해커는 한눈에 당신의 환경과 당신이 겪은 문제를 즉시 이해할 수 있습니다.
요약하자면, 제목만 표시되는 보관된 토론 스레드(Thread) 인덱스에서 검색하고 있다고 상상해 보세요. 제목이 문제를 더 잘 반영하게 하면, 다음에 비슷한 문제를 검색하는 사람이 이 토론 스레드에 관심을 가질 수 있어, 동일한 질문을 다시 할 필요가 없습니다.
답변에서 질문을 하고 싶다면, 콘텐츠 제목을 수정하여 질문을 하고 있음을 나타내세요. Re: 테스트 또는 Re: 새 버그와 같은 제목은 충분한 관심을 끌기 어렵습니다. 또한, 일관성에 영향을 주지 않는 범위에서 적절하게 인용하고 이전 콘텐츠를 삭제하면, 새로 온 독자에게 단서를 남길 수 있습니다.
토론 스레드의 경우, 답변을 클릭하여 완전히 새로운 토론 스레드를 시작하지 마세요. 이것은 당신의 관중을 제한합니다. 일부 메일 리더 프로그램(예: mutt)은 사용자가 토론 스레드별로 정렬하고 토론 스레드를 접어 메시지를 숨길 수 있게 해주며, 이렇게 하는 사람은 당신의 메시지를 영원히 볼 수 없습니다.
제목만 변경하는 것으로는 충분하지 않습니다. mutt와 일부 다른 메일 리더 프로그램은 메일 제목 외의 다른 정보를 확인하여 토론 스레드를 지정합니다. 따라서 완전히 새로운 메일을 보내는 것이 낫습니다.
웹 포럼에서 좋은 질문 방식은 약간 다릅니다. 토론 스레드가 특정 정보와 긴밀하게 결합되어 있고, 일반적으로 토론 스레드 외부에서 내부 콘텐츠를 볼 수 없기 때문에, 제목을 변경하지 않고 답변을 통해 질문하는 것이 허용됩니다. 모든 포럼이 답변에 별도의 제목을 허용하는 것은 아니며, 이렇게 하면 기본적으로 아무도 보지 않습니다. 그러나 답변을 통해 질문하는 것은 모호한 방법입니다. 왜냐하면 그것들은 해당 제목을 보고 있는 사람들에게만 읽히기 때문입니다. 따라서, 당신이 해당 토론 스레드의 현재 활성 인구 사이에서만 질문하고 싶지 않다면, 새로 시작하는 것이 좋습니다.
질문에 답변하기 쉽게 만들기
답변을 ...로 보내주세요로 질문을 끝내면 대부분 답변을 받지 못할 것입니다. 몇 초를 들여 메일 클라이언트에서 답변 주소를 설정하는 것이 귀찮다면, 우리도 몇 초를 들여 당신의 질문을 생각하는 것이 더 귀찮습니다. 당신의 메일 프로그램이 이것을 지원하지 않는다면, 더 좋은 것으로 바꾸세요; 운영 체제가 이런 메일 프로그램을 지원하지 않는다면, 더 좋은 것으로 바꾸세요.
포럼에서 이메일로 답변을 요청하는 것은 매우 무례한 것입니다. 답변 정보가 민감할 수 있다고 생각하지 않는 한(누군가가 알 수 없는 이유로 전체 포럼이 아닌 당신에게만 알리고 싶어할 수 있음). 누군가가 토론 스레드에 답변할 때 이메일 알림을 받고 싶다면, 웹 포럼이 당신에게 보내도록 요청할 수 있습니다. 거의 모든 포럼이 이 토론 스레드 추적, 답변이 있을 때 이메일 알림 등의 기능을 지원합니다.
명확하고, 올바르며, 정확하고 문법적으로 올바른 문장 사용
경험상, 부주의한 질문자는 보통 부주의하게 프로그램을 작성하고 생각합니다(장담합니다). 부주의한 사람의 질문에 대답하는 것은 가치가 없으며, 우리는 시간을 다른 곳에 쓰는 것을 선호합니다.
올바른 철자, 문장 부호 및 대소문자는 매우 중요합니다. 일반적으로, 이것이 귀찮다고 느끼고 신경 쓰지 않는다면, 우리도 귀찮아서 당신의 질문에 신경 쓰지 않습니다. 추가 노력을 기울여 문장을 신중하게 선택하세요. 너무 딱딱하고 공식적일 필요는 없습니다 —— 사실, 해커 문화는 비공식적이고, 속어와 유머러스한 문장을 정확하게 사용하는 것을 중요하게 생각합니다. 그러나 그것은 매우 정확해야 하며, 당신이 생각하고 문제에 관심을 기울이고 있다는 징후가 있어야 합니다.
올바르게 철자하고, 문장 부호와 대소문자를 사용하세요. its를 it's로 혼동하지 말고, loose를 lose로 만들거나 discrete를 discreet으로 만들지 마세요. 모두 대문자로 쓰지 마세요. 이것은 무례하게 큰 소리로 외치는 것으로 간주됩니다(모두 소문자도 읽기 어렵기 때문에 별로 좋지 않습니다. Alan Cox는 그렇게 할 수 있지만, 당신은 안 됩니다).
더 솔직히 말하면, 반문맹자처럼 쓴다면[역주: 小白], 대부분 무시당할 것입니다. 인스턴트 메신저의 약어나 화성어를 사용하지 마세요. 예를 들어 的를 d로 단순화하면 당신은 몇 개의 키를 덜 누르기 위해 글자를 줄이는 초보자처럼 보입니다. 더 나쁜 것은, 어린아이처럼 낙서하는 것은 확실히 자살 행위이며, 아무도 당신을 상대하지 않을 것이라고 확신할 수 있습니다(또는 기껏해야 많은 비난과 조롱을 받을 것입니다).
비모국어 포럼에서 질문할 때, 철자와 문법에서 작은 실수를 할 수 있지만, 생각에서 부주의해서는 안 됩니다(맞습니다, 우리는 보통 둘의 차이를 알 수 있습니다). 동시에, 답변자가 사용하는 언어를 알지 못한다면, 영어로 작성하세요. 바쁜 해커는 일반적으로 그들이 이해할 수 없는 언어로 작성된 메시지를 직접 삭제합니다. 인터넷에서 영어는 공용어이며, 영어로 작성하면 아직 읽히지 않은 상태에서 직접 삭제될 가능성을 최소화할 수 있습니다.
영어가 당신의 외국어(Second language)라면, 잠재적 답변자에게 잠재적인 언어적 어려움이 있음을 알리는 것이 좋습니다:
[역주: 다음은 원문을 첨부하여 사용할 수 있도록 함]
English is not my native language; please excuse typing errors.
- 영어는 제 모국어가 아닙니다. 오타나 문법 실수를 용서해 주세요.
If you speak $LANGUAGE, please email/PM me;
I may need assistance translating my question.
- 어떤 언어를 하신다면, 이메일/개인 메시지를 보내주세요. 제 질문을 번역하는 데 도움이 필요합니다.
I am familiar with the technical terms,
but some slang expressions and idioms are difficult for me.
- 저는 기술 용어에 익숙하지만, 속어나 특별한 용법은 조금 이해하기 어렵습니다.
I’ve posted my question in $LANGUAGE and English.
I’ll be glad to translate responses, if you only use one or the other.
- 제 질문을 어떤 언어와 영어로 작성했습니다. 한 가지 언어로만 답변하시면, 기꺼이 다른 언어로 번역하겠습니다.
읽기 쉽고 표준 파일 형식으로 질문 보내기
인위적으로 질문을 읽기 어렵게 만들면, 대부분 무시됩니다. 사람들은 읽기 쉬운 질문을 더 읽고 싶어 하므로:
- HTML이 아닌 일반 텍스트 사용(HTML 끄기는 어렵지 않습니다).
- MIME 첨부 파일은 일반적으로 괜찮습니다. 단, 실제 콘텐츠가 있는 경우(예: 첨부된 소스 코드 또는 패치)에만 해당하며, 메일 프로그램이 생성한 템플릿(예: 단순히 편지 내용의 복사본)이 아닙니다.
- 한 문장이지만 자동 줄바꿈 후 여러 줄이 되는 메일을 보내지 마세요(이것은 부분 콘텐츠에 답변하는 것을 매우 어렵게 만듭니다). 독자가 80자 너비의 터미널에서 메일을 읽는다고 가정하고, 줄바꿈 분할점을 80자 미만으로 설정하는 것이 좋습니다.
- 그러나 일부 특수 파일의 경우 고정 너비를 설정하지 마세요(예: 로그 파일 복사 또는 세션 기록). 데이터는 원래대로 포함되어야 하며, 답변자가 당신이 본 것과 동일한 것을 보고 있다는 확신을 줍니다.
- 영어 포럼에서
Quoted-PrintableMIME 인코딩으로 메시지를 보내지 마세요. 이 인코딩은 비 ASCII 언어를 게시하는 데 필요할 수 있지만, 많은 메일 프로그램이 이 인코딩을 지원하지 않습니다. 줄바꿈을 처리할 때, 텍스트 곳곳에 흩어진=20기호는 보기 흉하고 주의를 분산시키며, 심지어 콘텐츠의 의미를 파괴할 수도 있습니다. - 절대, 영원히 해커들이 마이크로소프트 워드나 엑셀 파일과 같은 폐쇄 형식으로 작성된 문서를 읽을 것이라고 기대하지 마세요. 대부분의 해커의 반응은 누군가가 아직 김이 나는 돼지 똥을 당신의 현관에 부었을 때의 당신의 반응과 같습니다. 그들이 처리할 수 있더라도, 그들은 그렇게 하는 것을 싫어합니다.
- Windows 컴퓨터에서 이메일을 보낸다면, 마이크로소프트의 어리석은
스마트 인용부호기능을 끄세요([옵션] > [교정] > [자동 고침 옵션],스마트 인용부호확인란 선택 해제). 그렇지 않으면 메일 곳곳에 쓰레기 문자가 흩어집니다. - 포럼에서
이모티콘과HTML기능을 남용하지 마세요(제공될 때). 이모티콘 한두 개는 일반적으로 괜찮지만, 화려한 컬러 텍스트는 당신을 무능한 사람으로 보이게 합니다. 이모티콘, 색상 및 글꼴을 과도하게 사용하면 당신은 킬킬거리는 어린 소녀처럼 보입니다. 이것은 일반적으로 좋은 아이디어가 아닙니다. 단, 답변이 아닌 성에만 관심이 있는 경우는 제외.
그래픽 사용자 인터페이스 메일 프로그램(예: 마이크로소프트 아웃룩 또는 유사한 것)을 사용한다면, 기본 설정이 이러한 요구 사항을 충족하지 않을 수 있습니다. 대부분의 이러한 프로그램에는 메뉴 기반 소스 보기 명령이 있습니다. 이것을 사용하여 보낸 편지함의 메일을 확인하여, 보낸 것이 일반 텍스트 파일이며 이상한 문자가 없는지 확인하세요.
문제를 정확하게 설명하고 내용이 있게
- 문제 또는 버그의 증상을 주의 깊고 명확하게 설명하세요.
- 문제가 발생한 환경을 설명하세요(기계 구성, 운영 체제, 애플리케이션 및 관련 정보). 배포판 및 버전 번호를 제공하세요(예:
Fedora Core 4,Slackware 9.1등). - 질문하기 전에 문제를 어떻게 연구하고 이해했는지 설명하세요.
- 질문하기 전에 문제를 확인하기 위해 취한 진단 단계를 설명하세요.
- 최근에 수행한 관련 하드웨어 또는 소프트웨어 변경 사항을 설명하세요.
- 가능한 한
이 문제를 재현할 수 있는 통제된 환경을 제공하는 방법을 제공하세요.
해커가 당신에게 어떻게 반문할지 추측해 보고, 질문하기 전에 해커들이 겪을 수 있는 문제를 미리 답변하세요.
위의 점들 중, 코드에 문제가 있다고 생각하는 문제를 보고할 때, 해커에게 당신의 문제를 재현할 수 있는 환경을 제공하는 것이 특히 중요합니다. 이렇게 하면, 당신이 효과적인 답변을 받을 기회와 속도가 크게 향상됩니다.
Simon Tatham은 《버그를 효과적으로 보고하는 방법》이라는 훌륭한 글을 썼습니다. 강력히 추천합니다.
많이 말하는 것보다 정확하게
정확하고 내용 있는 정보를 제공해야 합니다. 이것은 많은 오류 코드나 자료를 완전히 전사하여 질문에 넣으라는 것이 아닙니다. 프로그램이 충돌하는 상황을 재현할 수 있는 거대하고 복잡한 테스트 샘플이 있다면, 가능한 한 작게 자르세요.
이렇게 하는 것은 최소한 세 가지 이점이 있습니다.
첫째, 문제를 단순화하기 위해 노력했다는 것을 보여주어, 답변을 받을 기회가 증가합니다.
둘째, 문제를 단순화하면 유용한 답변을 받을 가능성이 높아집니다.
셋째, 버그 보고서를 정제하는 과정에서, 당신은 스스로 해결 방법이나 임시 방편을 찾을 수 있습니다.
버그를 찾았다고 쉽게 주장하지 마세요
소프트웨어를 사용하다 문제가 발생했을 때, 매우, 매우 확실한 근거가 없다면, 버그를 찾았다고 쉽게 주장하지 마세요. 힌트: 문제를 해결하는 소스 코드 패치를 제공하거나, 이전 버전에서 동작이 올바르지 않음을 보여주는 회귀 테스트를 제공할 수 없다면, 당신은 완전히 확신하지 못한 것입니다. 이것은 웹페이지와 파일에도 동일하게 적용됩니다. 파일의 버그를 (발견했다고) 주장한다면, 해당 위치의 수정 또는 대체 파일을 제공할 수 있어야 합니다.
많은 다른 사용자가 당신이 발견한 문제를 겪지 않았다는 것을 기억하세요. 그렇지 않았다면 파일을 읽거나 웹페이지를 검색할 때 발견했을 것입니다(불평하기 전에 이미 이것들을 했죠?). 이것은 소프트웨어 자체에 문제가 있는 것이 아니라 당신이 틀렸을 가능성이 높다는 것을 의미합니다.
소프트웨어를 작성하는 사람들은 항상 그것을 가능한 한 완벽하게 만들기 위해 매우 열심히 노력합니다. 당신이 버그를 찾았다고 주장하면, 그들의 능력을 의심하는 것이며, 당신이 옳더라도 일부 사람들을 불쾌하게 할 수 있습니다. 제목에서 버그라고 외칠 때, 이것은 특히 심각합니다.
질문할 때, 개인적으로 진짜 버그를 발견했다고 확신하더라도, 당신이 무엇을 잘못했는지처럼 쓰는 것이 좋습니다. 진짜 버그가 있다면, 답변에서 그것을 볼 수 있습니다. 이렇게 하면, 진짜 버그가 있다면 관리자가 당신에게 사과할 것이며, 이것은 다른 사람을 불쾌하게 하고 나중에 사과를 빚지는 것보다 낫습니다.
비굴함은 당신의 숙제를 대신할 수 없습니다
일부 사람들은 무례하거나 오만하게 질문하고 답변을 요구해서는 안 된다는 것을 알지만, 그들은 다른 극단을 선택합니다 —— 비굴함: 저는 그저 비참한 초보자, 루저라는 것을 알지만.... 이것은 사람들을 괴롭히고 쓸모없으며, 특히 실제 문제에 대한 모호한 설명과 함께할 때 더욱 반감을 삽니다.
원시 영장류의 속임수로 당신과 내 시간을 낭비하지 마세요. 대신, 배경 조건과 문제 상황을 가능한 한 명확하게 설명하세요. 이것이 비굴함보다 당신의 위치를 더 잘 정의합니다.
때때로 웹 포럼은 초보자 질문을 위한 전용 게시판을 설치합니다. 정말로 초보자 문제라고 생각한다면, 거기로 가면 됩니다. 하지만 여전히 그렇게 비굴하지 마세요.
문제 증상을 설명하고 추측은 하지 마세요
해커들에게 문제가 어떻게 발생했다고 생각하는지 말하는 것은 도움이 되지 않습니다.(당신의 추론이 그렇게 효과적이라면, 왜 다른 사람에게 도움을 요청합니까?), 따라서 그들에게 문제의 증상을 원래대로 말했는지 확인하고, 당신의 설명과 이론이 아님을 확인하세요. 해커들이 추측하고 진단하게 하세요. 당신의 추측을 진술하는 것이 중요하다고 생각한다면, 이것이 단지 당신의 추측일 뿐임을 명확히 하고, 왜 그것들이 작동하지 않는지 설명하세요.
바보 같은 질문
커널 컴파일 시 계속 SIG11 오류가 발생합니다.
어떤 플라이 와이어가 메인보드의 트레이스에 걸렸다고 의심합니다. 이 경우 어떻게 확인하는 것이 가장 좋습니까?
똑똑한 질문
제 조립 컴퓨터는 FIC-PA2007 메인보드에 AMD K6/233 CPU(비아 Apollo VP2 칩셋),
256MB Corsair PC133 SDRAM 메모리를 장착하고 있습니다. 커널 컴파일 시, 부팅 20분 후부터 빈번하게 SIG11 오류가 발생합니다.
하지만 처음 20분 동안은 동일한 문제가 발생하지 않았습니다. 재부팅해도 소용없지만, 하룻밤 끄고 나면 다시 20분 동안 작동합니다.
모든 메모리를 교체했지만, 효과가 없었습니다. 관련 부분의 표준 컴파일 기록은 다음과 같습니다….
이상의 점이 많은 사람들이 따르기 어렵다고 느끼는 것 같습니다. 여기 당신에게 상기시켜 줄 수 있는 말이 있습니다: 모든 진단 전문가는 미주리 주에서 왔습니다. 미국 국무부의 공식 좌우명은: 보여주세요입니다(1899년 하원의원 Willard D. Vandiver의 연설에서: 저는 옥수수, 면화, 우엉, 민주당원을 생산하는 나라에서 왔습니다. 웅변으로 저를 설득할 수 없고, 만족시킬 수도 없습니다. 저는 미주리 주에서 왔으니, 보여주세요.). 진단자에게 이것은 의심이 아니라, 그들이 당신이 본 원래 증거와 가능한 한 일치하는 것을 볼 수 있도록 하는 실제적이고 유용한 요구입니다. 당신의 추측과 요약된 결론이 아닙니다. 따라서, 우리에게 보여주세요!
문제 증상을 발생 시간 순서대로 나열
문제 발생 전의 일련의 작업은 종종 문제를 찾는 데 가장 도움이 되는 단서입니다. 따라서, 설명에는 작업 단계와 문제가 발생할 때까지의 기계 및 소프트웨어 반응이 포함되어야 합니다. 명령줄 처리의 경우, 작업 기록(예: 스크립트 도구 실행으로 생성된)을 제공하고, 관련된 몇 줄(예: 20줄)의 기록을 인용하는 것이 매우 도움이 됩니다.
충돌한 프로그램에 진단 옵션(예: -v의 상세 스위치)이 있다면, 기록에 디버그 정보를 추가할 수 있는 옵션을 선택하세요. 기억하세요, 많이가 좋은 것은 아닙니다. 적절한 디버그 수준을 선택하여 유용한 정보를 제공하고 독자를 쓰레기에 빠뜨리지 않도록 하세요.
설명이 길다면(예: 4개 단락 이상), 문제를 먼저 간단히 요약하고, 그 다음 시간 순서대로 자세히 설명하는 것이 도움이 됩니다. 이렇게 하면 해커들이 기록을 읽을 때 주의해야 할 내용을 알 수 있습니다.
과정이 아닌 목표를 설명
어떻게 어떤 일을 하는지 알고 싶다면(버그를 보고하는 것이 아니라), 처음에 목표를 설명하고, 그 다음 당신이 막힌 특정 단계를 재현하는 것을 진술하세요.
기술 도움을 자주 요청하는 사람은 마음속에 더 높은 수준의 목표가 있고, 그들이 목표를 달성할 수 있다고 생각하는 특정 길에서 막혀서, 어떻게 가야 하는지 물으러 왔지만, 그 길 자체에 문제가 있다는 것을 인식하지 못합니다. 결과적으로 많은 노력을 기울여야 해결할 수 있습니다.
바보 같은 질문
어떤 그래픽 프로그램의 색상 선택기에서 16진수 RGB 값을 어떻게 얻을 수 있나요?
똑똑한 질문
저는 그림의 색상표(color table)를 제가 선택한 색상표로 교체하려고 합니다. 제가 아는 유일한 방법은 각 색상 블록(table slot)을 편집하는 것인데,
어떤 그래픽 프로그램의 색상 선택기에서 16진수 RGB 값을 얻을 수 없습니다.
두 번째 질문법이 더 똑똑합니다. 더 적합한 다른 도구를 사용하는 것을 제안하는 답변을 받을 수 있습니다.
개인 이메일로 답변을 요구하지 마세요
해커들은 문제 해결 과정이 공개적이고 투명해야 한다고 생각합니다. 이 과정에서 더 경험 많은 사람이 불완전하거나 부적절한 점을 발견하면, 최초의 답변이 수정될 수 있고 수정되어야 합니다. 동시에, 도움을 제공하는 사람은 그의 능력과 지식이 다른 동료들에게 보여지는 보상을 받을 수 있습니다.
개인적으로 답변을 요구하면, 이 과정과 보상이 중단됩니다. 이렇게 하지 마세요. 답변자가 개인적으로 답변할지 결정하게 하세요 —— 그가 정말로 그렇게 한다면, 보통 그가 질문이 너무 엉성하거나 너무 피상적이라고 생각해서 다른 사람들에게 흥미가 없기 때문입니다.
이 규칙에는 제한된 예외가 있습니다. 질문이 많은 동일한 답변을 유발할 것이라고 확신한다면, 마법의 질문 문장은 저에게 이메일을 보내주시면, 포럼을 위해 이 답변들을 요약하겠습니다입니다. 메일링 리스트나 뉴스그룹을 동일한 답변의 홍수에서 구하려는 것은 매우 예의 바른 것입니다 —— 하지만 약속을 지켜야 합니다.
질문과 요구를 명확하고 명확하게 표현
방대한 질문은 거의 끝없는 시간 블랙홀입니다. 가장 유용한 답변을 줄 수 있는 사람은 보통 가장 바쁜 사람입니다(그들이 바쁜 것은 대부분의 일을 직접 완료해야 하기 때문입니다). 이런 사람들은 무절제한 시간 블랙홀을 상당히 싫어하므로, 그들은 방대한 질문을 싫어하는 경향이 있습니다.
당신이 답변자가 무엇을 해야 하는지 명확하게 표현하면(예: 지적 제공, 코드 일부 전송, 패치 확인 또는 기타), 가장 유용한 답변을 받을 가능성이 높습니다. 왜냐하면 이것은 시간과 에너지의 상한을 정하여, 답변자가 당신을 돕는 데 집중할 수 있게 하기 때문입니다. 이렇게 하는 것은 훌륭합니다.
전문가들의 세계를 이해하려면, 전문 기술을 풍부한 자원으로, 답변 시간을 희소한 자원으로 상상해 보세요. 당신이 그들에게 요구하는 시간이 적을수록, 진정으로 전문적이고 바쁜 전문가로부터 답변을 받을 가능성이 높습니다.
따라서, 당신의 문제를 정의하여, 전문가가 당신의 문제를 식별하고 답변하는 데 필요한 시간을 최소화하세요. 이 기술은 유용한 답변에 상당히 도움이 됩니다 —— 하지만 이 기술은 일반적으로 문제를 단순화하는 것과 다릅니다. 따라서, X를 더 잘 이해하고 싶습니다. 좋은 설명이 어디에 있는지 지적해 주시겠습니까?라고 묻는 것이 X를 설명해 주시겠습니까?보다 낫습니다. 당신의 코드가 작동하지 않는다면, 일반적으로 다른 사람에게 어디가 문제인지 보여달라고 요청하는 것이 다른 사람에게 대신 수정해 달라고 요청하는 것보다 현명합니다.
코드에 관한 질문을 할 때
다른 사람에게 문제가 있는 코드를 디버그하도록 요구하지 말고, 어디서 시작해야 하는지 힌트도 주지 마세요. 수백 줄의 코드를 게시하고 작동하지 않습니다라고 말하면 완전히 무시됩니다. 수십 줄의 코드만 게시하고 일곱 번째 줄 이후에 <x>가 표시되기를 기대했지만, 실제로는 <y>가 나타납니다라고 말하면 답변을 받을 가능성이 높습니다.
프로그램 문제를 가장 효과적으로 설명하는 방법은 가장 정제된 버그 시연 테스트 케이스(bug-demonstrating test case)를 제공하는 것입니다. 가장 정제된 테스트 케이스란 무엇인가요? 그것은 문제의 축소판입니다. 작은 프로그램 조각이 프로그램의 비정상적인 동작을 정확히 보여주며, 다른 주의를 분산시키는 콘텐츠는 포함하지 않습니다. 가장 정제된 테스트 케이스를 어떻게 만드나요? 어떤 줄 또는 어떤 코드 조각이 비정상적인 동작을 일으키는지 안다면, 복사하고 이 상황을 재현하기에 충분한 코드를 추가하세요(예: 이 코드가 컴파일/인터프리트/애플리케이션에서 처리될 수 있도록). 문제를 특정 블록으로 줄일 수 없다면, 코드 사본을 만들고 문제 동작을 생성하지 않는 부분을 제거하세요. 어쨌든, 테스트 케이스는 작을수록 좋습니다(많이 말하는 것보다 정확하게 섹션 참조).
일반적으로, 상당히 정제된 테스트 케이스를 얻는 것은 쉽지 않지만, 항상 먼저 이렇게 시도하는 것은 좋은 습관입니다. 이 방식은 당신이 스스로 이 문제를 해결하는 방법을 이해하는 데 도움이 됩니다 —— 그리고 당신의 시도가 성공하지 못하더라도, 해커들은 당신이 답변을 얻는 과정에서 노력했다는 것을 볼 수 있어, 그들이 당신과 협력할 의향이 더 높아집니다.
다른 사람에게 코드를 검토(Review)해 달라고 요청하고 싶다면, 편지의 처음에 말하고, 특히 어떤 부분에 특별히 관심이 필요한지, 그리고 왜인지 반드시 언급하세요.
숙제 문제를 게시하지 마세요
해커들은 어떤 질문이 숙제 문제인지 잘 구분합니다. 왜냐하면 우리 대부분이 직접 이런 문제를 해결했기 때문입니다. 마찬가지로, 이러한 문제는 당신이 해결해야 하며, 당신은 그것에서 배울 것입니다. 힌트를 요구할 수 있지만, 완전한 해결책을 요구하지 마세요.
숙제 문제라고 의심하지만 여전히 해결할 수 없다면, 사용자 그룹, 포럼 또는 (마지막 수단으로) 프로젝트의 사용자 메일링 리스트 또는 포럼에서 질문해 보세요. 해커들이 알아채겠지만, 일부 경험 많은 사용자는 여전히 힌트를 줄 수 있습니다.
무의미한 질문 문장 제거
무의미한 말로 질문을 끝내지 마세요. 예를 들어 누가 저를 도와줄 수 있나요? 또는 이것에 답이 있나요?.
첫째: 문제에 대한 설명이 좋지 않다면, 이렇게 묻는 것은 불필요한 추가입니다.
둘째: 이렇게 묻는 것이 불필요한 추가이므로, 해커들은 당신을 싫어할 것입니다 —— 그리고 보통 논리적으로 올바르지만 무의미한 답변으로 그들의 경멸을 표시할 것입니다. 예를 들어: 그래요, 누가 당신을 도울 수 있습니다 또는 아니요, 답이 없습니다.
일반적으로, 예 또는 아니요, 맞거나 틀림, 있거나 없음 유형의 질문을 피하세요. 단, 예 또는 아니요 유형의 답변을 원하는 경우는 제외.
급하더라도 제목에 긴급을 쓰지 마세요
이것은 당신의 문제이지, 우리의 문제가 아닙니다. 긴급이라고 선언하면 역효과가 날 가능성이 매우 높습니다. 대부분의 해커는 무례하고 이기적으로 즉각적인 관심을 끌려는 질문을 직접 삭제합니다. 더 심각한 것은, 긴급이라는 단어(또는 관심을 끌려는 다른 제목)는 일반적으로 스팸 필터에 의해 걸러집니다 —— 당신의 질문을 보기를 원하는 사람이 영원히 볼 수 없을 수 있습니다.
반 정도의 예외가 있습니다. 해커들을 흥분시킬 만한 매우 주목받는 곳에서라면, 이렇게 할 가치가 있을 수 있습니다. 이 경우, 시간 압박이 있다면, 정중하게 이것을 언급하면, 사람들은 더 빨리 답변할 흥미를 가질 수 있습니다.
물론, 이것은 위험이 큽니다. 왜냐하면 해커들이 흥분하는 것은 대부분 당신과 다르기 때문입니다. 예를 들어, NASA 국제 우주 정거장(International Space Station)에서 이런 제목을 보내는 것은 문제가 없지만, 자기 만족적인 자선 행위나 정치적 이유로 보내는 것은 확실히 안 됩니다. 사실, 긴급: 이 귀여운 작은 바다 표범을 구해주세요!와 같은 것을 게시하면 확실히 해커들이 무시하거나 그들을 짜증나게 할 것입니다. 그들이 귀여운 작은 바다 표범이 중요하다고 생각하더라도 마찬가지입니다.
이것이 믿기지 않는다면, 이 가이드의 나머지 내용을 몇 번 더 읽고, 이해한 후에 게시하는 것이 좋습니다.
예의는 사람을 해치지 않으며, 때로는 매우 도움이 됩니다
정중하게, 주세요와 관심에 감사합니다 또는 배려에 감사합니다를 자주 사용하세요. 모든 사람이 그들이 시간을 내어 무료로 도움을 제공한 것에 감사하고 있음을 알게 하세요.
솔직히 말하면, 이것은 명확하고, 올바르며, 정확하고 문법적으로 올바르고 전용 형식을 피하는 것보다 중요하지 않습니다(대신할 수도 없습니다). 해커들은 일반적으로 약간 무록하지만 기술적으로 선명한 버그 보고서를 읽는 것을 선호합니다. 정중하지만 모호한 보고서보다.(이것이 당신을 이해하지 못하게 한다면, 우리가 질문이 우리에게 무엇을 가르칠 수 있는지에 따라 질문의 가치를 평가한다는 것을 기억하세요).
그러나, 해결해야 할 일련의 문제가 있다면, 정중한 것이 유용한 답변을 받을 기회를 증가시킬 것입니다.
(우리는 이 가이드가 발표된 이후, 시니어 해커로부터 받은 유일한 심각한 결함 피드백이 미리 감사를 표현하는 것에 대한 것이었다는 것을 주목했습니다. 일부 해커들은 미리 감사합니다가 나중에 누구에게도 감사하지 않아도 된다는 것을 의미한다고 느낍니다. 우리의 제안은 미리 감사합니다라고 먼저 말하고, 그 다음 나중에 답변자에게 다시 감사를 표현하거나, 관심에 감사합니다 또는 배려에 감사합니다와 같은 다른 방식으로 감사를 표현하는 것입니다.)
문제 해결 후, 짧은 보충 설명 추가
문제가 해결된 후, 도와준 모든 사람에게 설명을 보내, 문제가 어떻게 해결되었는지 알리고, 다시 한 번 감사를 표현하세요. 문제가 뉴스그룹이나 메일링 리스트에서 널리 관심을 끌었다면, 거기에 설명을 게시하는 것이 적절합니다.
가장 이상적인 방식은 최초 질문 주제에 이 메시지를 답장하고, 제목에 수정됨, 해결됨 또는 기타 동등한 의미의 명확한 표시를 포함하는 것입니다. 사람들이 오가는 메일링 리스트에서, 토론 스레드 문제 X와 문제 X - 해결됨을 보는 잠재적 답변자는 더 이상 시간을 낭비할 필요가 없다는 것을 알게 됩니다(그가 개인적으로 문제 X가 흥미롭다고 느끼지 않는 한). 따라서 이 시간을 다른 문제를 해결하는 데 사용할 수 있습니다.
보충 설명은 길거나 깊이 있을 필요가 없습니다. 간단한 한 문장 안녕하세요, 알고 보니 네트워크 케이블 문제였습니다! 모두 감사합니다 – Bill가 아무것도 말하지 않는 것보다 낫습니다. 사실, 결론이 정말로 기술적이지 않다면, 짧고 귀여운 요약이 긴 설명보다 낫습니다. 문제가 어떻게 해결되었는지 설명하지만, 문제 해결 과정을 다시 서술할 필요는 없습니다.
깊이 있는 문제의 경우, 디버그 기록의 요약을 게시하는 것이 도움이 됩니다. 문제의 최종 상태를 설명하고, 무엇이 문제를 해결했는지 설명한 후에 피할 수 있었던 맹점을 지적하세요. 맹점을 피하는 부분은 올바른 해결책과 기타 요약 자료 후에 배치하고, 이 정보를 탐정 소설처럼 만들지 마세요. 당신을 도와준 사람들의 이름을 나열하면, 더 많은 친구를 사귈 수 있습니다.
정중하고 내용이 있을 뿐만 아니라, 이러한 유형의 보충은 다른 사람들이 메일링 리스트/뉴스그룹/포럼에서 당신의 문제를 실제로 해결한 방안을 검색하여, 그들도 이익을 얻을 수 있게 합니다.
적어도, 이러한 보충은 각 참여자가 문제 해결로부터 만족감을 얻을 수 있게 합니다. 당신이 기술 전문가나 해커가 아니라면, 우리를 믿으세요. 이 느낌은 당신이 도움을 요청한 마스터나 전문가에게 매우 중요합니다. 문제가 해결되지 않은 채로 남아 있으면 사람들이 낙담합니다. 해커들은 문제가 해결되는 것을 보고 싶어 합니다. 착한 사람에게는 착한 보답이 있습니다. 그들의 욕구를 충족시키면, 다음에 질문할 때 달콤한 맛을 볼 것입니다.
다른 사람들이 미래에 비슷한 문제를 겪지 않도록 하는 방법을 생각해 보고, 파일을 작성하거나 FAQ를 추가하는 것이 도움이 될지 자문해 보세요. 그렇다면 그것들을 관리자에게 보내세요.
해커들 사이에서, 이러한 좋은 후속 조치는 실제로 전통적인 예절보다 더 중요하며, 다른 사람을 잘 대함으로써 평판을 얻는 방법이기도 하며, 이것은 매우 가치 있는 자산입니다.
답변 해석 방법
RTFM과 STFW: 완전히 망쳤는지 아는 방법
오래되고 신성한 전통이 있습니다: RTFM(Read The Fucking Manual) 답변을 받았다면, 답변자는 당신이 맨데이말 매뉴얼을 읽어야 한다고 생각합니다. 물론, 기본적으로 그는 옳으며, 당신은 읽어야 합니다.
RTFM에는 젊은 친척이 있습니다. STFW(Search The Fucking Web) 답변을 받았다면, 답변자는 당신이 맨데이말 웹에서 검색해야 한다고 생각합니다. 그 사람도 대부분 옳으니, 검색해 보세요.(더 부드러운 표현은 Google은 당신의 친구입니다!)
포럼에서, 포럼의 이전 글을 읽으라는 요청을 받을 수도 있습니다. 사실, 누군가는 이 문제를 해결한 이전 토론 스레드를 친절하게 제공할 수도 있습니다. 그러나 이러한 배려에 의존하지 말고, 질문하기 전에 먼저 이전 글을 검색해야 합니다.
일반적으로, 이 두 문장 중 하나로 답변하는 사람은 당신에게 필요한 콘텐츠가 포함된 매뉴얼이나 웹사이트를 줄 것이며, 그들이 이 글자들을 입력할 때도 읽고 있습니다. 이러한 답변은 답변자가 다음을 생각한다는 것을 의미합니다:
- 당신이 필요한 정보는 매우 쉽게 얻을 수 있습니다;
- 당신이 직접 이 정보를 검색하는 것이 당신에게 주입하는 것보다 더 많이 배울 수 있습니다.
당신은 이것 때문에 기분 나빠하지 않아야 합니다; 해커의 기준에 따라, 그는 당신에게 어느 정도 관심을 표시했으며, 당신의 요구를 무시하지 않았습니다. 그의 할머니 같은 자애에 감사해야 합니다.
여전히 이해하지 못한다면
답변을 이해하지 못한다면, 즉시 상대방에게 설명을 요구하지 마세요. 이전에 스스로 문제를 해결하려고 했던 것처럼(매뉴얼, FAQ, 네트워크, 주변의 고수 활용), 먼저 그의 답변을 이해하려고 노력하세요. 정말로 상대방에게 설명이 필요하다면, 당신이 그것에서 무언가를 배웠다는 것을 보여주세요.
예를 들어, 제가 당신에게: zentry가 걸린 것 같습니다; 먼저 그것을 지워야 합니다.라고 답변했다면, 이것은 나쁜 후속 질문 답변입니다: zentry가 무엇인가요? 좋은 질문 방법은 이렇게: 오~~~ 설명을 봤지만 -z와 -p 두 매개변수에서만 zentries가 언급되었고, 그것을 지우는 방법에 대한 명확한 설명이 없습니다. 이 두 가지 중 어느 것을 의미하나요? 아니면 제가 무엇을 놓쳤나요?
무례한 답변 처리
많은 해커 서클에서 무례해 보이는 행동은 고의로 모욕하려는 것이 아닙니다. 반대로, 그것은 직접적이고, 정곡을 찌르는 교류 스타일이며, 이 스타일은 사람들을 편안하게 느끼게 하면서도 모호하게 만드는 것보다 문제 해결에 더 중점을 둡니다.
당신이 모욕을 받았다고 느낀다면, 침착하게 반응하세요. 누군가가 정말로 지나친 일을 했다면, 메일링 리스트, 뉴스그룹 또는 포럼의 선배들이 대부분 그를 주의할 것입니다. 이것이 발생하지 않았고 당신이 화를 냈다면, 당신이 화를 낸 대상의 언어는 해커 커뮤니티에서 정상적으로 보일 수 있으며, 당신이 잘못된 쪽으로 간주되어, 정보나 도움을 얻을 기회를 해칠 것입니다.
반면에, 당신은 가끔 정말로 무례하고 지루한 언행을 겪을 것입니다. 위와 반대로, 진정한 모욕자를 강하게 공격하고, 날카로운 언어로 완전히 반박하는 것은 받아들일 수 있습니다. 그러나, 행동하기 전에 매우 확실한 근거가 있어야 합니다. 무례한 발언을 교정하는 것과 무의미한 말다툼을 시작하는 것은 종이 한 장 차이이며, 해커들 자신도 무모하게 선을 넘는 경우가 드물지 않습니다. 당신이 초보자나 외부인이라면, 이러한 무모함을 피할 기회가 높지 않습니다. 당신이 원하는 것이 정보이지 시간을 보내는 것이 아니라면, 이때는 키보드에 손을 대지 않는 것이 위험을 피하는 것이 좋습니다.
(일부 사람들은 많은 해커가 경미한 자폐증이나 아스퍼거 증후군이 있어, 인간 사회의 정상적인 교류에 필요한 신경이 부족하다고 주장합니다. 이것은 사실일 수도 있고 아닐 수도 있습니다. 당신이 해커가 아니라면, 아마도 우리가 문제가 있다고 생각하는 것이 우리의 이상한 행동을 대처하는 데 도움이 될 것입니다. 그냥 그렇게 하세요. 우리는 신경 쓰지 않습니다. 우리는 우리가 지금 이 모습을 좋아하며, 일반적으로 환자 라벨에 대해 타당한 의심을 가지고 있습니다.)
Jeff Bigler의 관찰 요약은 이것과 관련이 있으며 읽을 가치가 있습니다 (tact filters).
다음 섹션에서, 우리는 또 다른 문제인 당신이 부적절하게 행동했을 때 받을 모욕에 대해 이야기할 것입니다.
실패자 역할을 피하는 방법
해커 커뮤니티의 포럼에서 몇 번 망칠 수 있습니다 —— 이 가이드에서 설명한 방식이나 유사한 방식으로. 그리고 당신은 공개 장소에서 어떻게 망쳤는지 알게 될 것이며, 아마도 공격적인 언어에 약간의 욕설이 섞일 수도 있습니다.
이런 일이 발생한 후, 당신이 할 수 있는 가장 나쁜 것은 당신의 처지를 슬퍼하고, 구두 공격을 받았다고 주장하고, 사과를 요구하고, 큰 소리로 비명을 지르고, 화를 내고, 법적 조치를 위협하고, 고용주에게 불평하고, 변기 뚜껑을 닫는 것을 잊는 것 등입니다. 반대로, 당신은 이렇게 해야 합니다:
견디세요, 이것은 정상입니다. 사실, 그것은 건강하고 합리적입니다.
커뮤니티의 표준은 스스로 유지되지 않으며, 참여자들이 적극적이고 공개적으로 실행함으로써 유지됩니다. 모든 비판이 개인적인 이메일을 통해 전달되어야 한다고 울부짖지 마세요. 그렇게 작동하지 않습니다. 누군가가 당신의 진술이 잘못되었다고 논평하거나 다른 견해를 제시할 때, 개인적 공격을 받았다고 주장하는 것은 아무런 도움이 되지 않습니다. 이것들은 모두 실패자의 태도입니다.
다른 해커 포럼도 있으며, 높은 예절 요구에 오도되어, 참여자가 다른 사람의 게시물에 결점을 찾는 메시지를 게시하는 것을 금지하고, 사용자를 돕고 싶지 않다면 입을 다무세요.라고 주장합니다. 결과적으로 생각이 있는 참여자들이 떠나, 이것은 그것들을 무의미한 잡담과 쓸모없는 기술 포럼으로 전락시킵니다.
과장된 말로: 당신이 원하는 것은 “친절함”(위의 방식으로)인가요 아니면 유용함인가요? 둘 중 하나를 선택하세요.
기억하세요: 해커가 당신이 망쳤다고 말하고, (얼마나 날카롭든) 다시 그렇게 하지 말라고 말할 때, 그는 당신과 그의 커뮤니티를 걱정하며 행동하고 있습니다. 그에게 있어, 당신을 무시하고 그의 삶에서 당신을 걸러내는 것이 더 간단합니다. 당신이 감사를 표현할 수 없다면, 적어도 약간의 존엄성을 보이고, 큰 소리로 슬퍼하지 말고, 자신이 극적으로 초민감한 영혼이고 자격이 있다고 생각하는 새로 온 사람이기 때문에, 다른 사람들이 당신을 깨지기 쉬운 인형처럼 대우하기를 기대하지 마세요.
때때로, 당신이 망치지 않았더라도(또는 그의 상상에서 망쳤더라도), 일부 사람들은 이유 없이 당신을 공격할 것입니다. 이 경우, 불평하는 것은 정말로 문제를 망치는 것입니다.
이러한 문제를 찾아오는 사람들은 방법이 없지만 스스로 전문가라고 생각하는 쓸모없는 사람이거나, 당신이 정말로 망칠지 테스트하는 심리 전문가입니다. 다른 독자들은 무시하거나 자신의 방식으로 그들을 대처합니다. 이러한 문제를 찾아오는 사람들은 그들 자신에게 문제를 찾고 있으므로, 당신은 걱정할 필요가 없습니다.
또한 자신을 말다툼에 휘말리게 하지 마세요. 대부분의 말다툼을 무시하는 것이 가장 좋습니다 —— 물론, 그것들이 단순히 말다툼인지 확인하고, 당신이 망친 곳을 지적하지 않았으며, 동시에 문제의 진정한 답을 그 뒤에 교묘하게 숨기지 않았다는 것을(이것도 가능합니다).
물어서는 안 되는 질문
다음은 몇 가지 고전적인 바보 같은 질문과, 해커가 답변하지 않았을 때 마음속으로 생각하는 것입니다:
질문: X 프로그램 또는 X 리소스를 어디에서 찾을 수 있나요?
답변: 내가 찾은 곳에서 찾으세요, 바보 —— 검색 엔진의 저쪽. 세상에! 아직도 Google을 사용할 줄 모르는 사람이 있나요?
질문: X를 사용하여 Y를 어떻게 하나요?
답변: Y를 해결하고 싶다면, 질문할 때 적절하지 않을 수 있는 방법을 제시하지 마세요. 이러한 질문은 질문자가 X에 대해 완전히 무지할 뿐만 아니라, Y가 해결해야 할 문제에 대해서도 혼란스러워하며, 특정 상황에 사고가 제한되어 있음을 보여줍니다. 이런 사람을 무시하고, 그들이 문제를 명확히 할 때까지 기다리는 것이 좋습니다.
질문: 제 쉘 프롬프트를 어떻게 설정하나요??
답변: 이 질문을 할 만큼 충분한 지혜가 있다면, RTFM할 만큼 충분한 지혜도 있을 것이며, 직접 찾아보세요.
질문: Bass-o-matic 파일 변환 도구를 사용하여 AcmeCorp 파일을 TeX 형식으로 변환할 수 있나요?
답변: 시도해 보면 알 수 있습니다. 시도했다면, 답을 알았을 것이고, 내 시간을 낭비할 필요가 없었을 것입니다.
질문: 제 {프로그램/설정/SQL 문}이 작동하지 않습니다
답변: 이것은 질문이 아닙니다. 당신의 진정한 문제를 찾기 위해 스무 가지 질문을 해야 하는 질문에 관심이 없습니다 —— 나는 더 흥미로운 일이 있습니다. 이런 종류의 질문을 볼 때, 내 반응은 보통 다음 세 가지 중 하나입니다:
- 더 추가할 것이 있나요?
- 정말 안됐네요, 해결하시길 바랍니다.
- 이게 나랑 무슨 상관이죠?
질문: 제 Windows 컴퓨터에 문제가 있습니다. 도와주실 수 있나요?
답변: 네, 마이크로소프트의 쓰레기를 버리고, Linux나 BSD와 같은 오픈소스 운영 체제로 바꾸세요.
참고: 프로그램에 공식 Windows 버전이 있거나 Windows와 상호 작용하는 경우(예: Samba), Windows 관련 질문을 할 수 있습니다. 단, 문제가 Windows 운영 체제가 아니라 프로그램 자체에 의해 발생했다는 답변에 놀라지 마세요. 왜냐하면 Windows는 일반적으로 너무 엉망이어서, 이러한 말이 보통 사실이기 때문입니다.
질문: 제 프로그램이 작동하지 않습니다. 시스템 도구 X에 문제가 있다고 생각합니다
답변: 당신은 수천 명의 사용자가 반복적으로 사용하는 시스템 호출과 라이브러리 파일에 명백한 결함이 있다는 것을 처음으로 알아차린 사람일 수 있습니다. 더 가능성이 높은 것은 당신이 근거가 전혀 없다는 것입니다. 비범한 주장은 비범한 증거가 필요하며, 이렇게 주장할 때, 명확하고 상세한 결함 설명 파일을 뒷받침해야 합니다.
질문: Linux(또는 X)를 설치할 때 문제가 있습니다. 도와주실 수 있나요?
답변: 아니요, 직접 당신의 컴퓨터에서 작업해야만 문제를 찾을 수 있습니다. 로컬 Linux 사용자 그룹에 가서 실제 지도를 구하세요(여기에서 사용자 그룹 목록을 찾을 수 있습니다).
참고: 설치 문제가 특정 Linux 배포판과 관련이 있다면, 해당 배포판의 메일링 리스트, 포럼 또는 로컬 사용자 그룹에서 질문하는 것이 적절할 수 있습니다. 이 경우, 문제의 정확한 세부 사항을 설명해야 합니다. 그 전에, 먼저 Linux와 모든 의심되는 하드웨어를 키워드로 사용하여 신중하게 검색하세요.
질문: root 계정을 크랙하거나 OP 특권을 훔치거나 다른 사람의 이메일을 읽으려면 어떻게 해야 하나요?
답변: 이렇게 하고 싶다는 것은 당신이 비열한 사람이라는 것을 보여줍니다; 해커에게 도움을 요청하는 것은 당신이 바보라는 것을 보여줍니다!
좋은 질문과 바보 같은 질문
마지막으로, 예를 들어 어떻게 똑똑하게 질문하는지 설명하겠습니다. 동일한 문제의 두 가지 질문 방법이 함께 배치되어 있으며, 하나는 바보 같고, 다른 하나는 현명합니다.
바보 같은 질문:
Foonly Flurbamatic에 대한 정보를 어디에서 찾을 수 있나요?
이러한 질문 방법은 STFW와 같은 답변을 받고 싶은 것입니다.
똑똑한 질문:
Google에서 “Foonly Flurbamatic 2600”을 검색했지만 유용한 결과를 찾지 못했습니다. 이 장치를 프로그래밍하는 자료를 어디에서 찾을 수 있는지 아는 사람이 있나요?
이 질문은 이미 STFW했으며, 그가 정말로 문제를 겪고 있는 것처럼 보입니다.
바보 같은 질문:
foo 프로젝트에서 가져온 소스 코드가 컴파일되지 않습니다. 왜 이렇게 엉망인가요?
그는 모든 것이 다른 사람의 잘못이라고 생각합니다. 이 오만한 질문자입니다.
똑똑한 질문:
foo 프로젝트 코드가 Nulix 6.2 버전에서 컴파일되지 않습니다. FAQ를 읽었지만 Nulix와 관련된 문제가 언급되지 않았습니다. 이것은 제 컴파일 과정의 기록입니다. 제가 무엇을 잘못했나요?
질문자는 환경을 지정했고, FAQ도 읽었으며, 오류도 나열했고, 문제의 책임을 다른 사람에게 떠넘기지 않았습니다. 그의 질문은 관심을 받을 가치가 있습니다.
바보 같은 질문:
제 메인보드에 문제가 있습니다. 누가 도와주실 수 있나요?
어떤 해커는 이런 종류의 질문에 보통: 그래요, 등도 두드려주고 기저귀도 갈아줄까요?라고 답변한 다음, 삭제 키를 누릅니다.
똑똑한 질문:
저는 S2464 메인보드에서 X, Y, Z를 시도했지만, 별 효과가 없었습니다. A, B, C도 시도했습니다. C를 시도할 때 이상한 현상에 주목하세요. 분명히 florbish가 grommicking하고 있지만, 결과는 예상치 못했습니다. 일반적으로 Athlon MP 메인보드에서 grommicking을 일으키는 원인은 무엇인가요? 문제를 찾기 위해 다음에 어떤 테스트를 해야 하는지 아는 사람이 있나요?
이 사람은 다른 각도에서 보면, 대답할 가치가 있습니다. 그는 문제 해결 능력을 보여주었으며, 하늘에서 답이 떨어지기를 기다리지 않았습니다.
마지막 질문에서, 답을 알려주세요와 제가 더 해야 할 진단 작업을 지적해 주는 계시를 주세요 사이의 미묘하고 중요한 차이에 주목하세요.
사실, 후자의 질문은 2001년 8월 Linux 커널 메일링 리스트(lkml)에서 실제로 제기된 질문에서 비롯되었습니다. 저(Eric)가 그 질문을 한 사람입니다. 저는 Tyan S2464 메인보드에서 설명할 수 없는 잠금 현상을 관찰했으며, 리스트 구성원들이 이 문제를 해결하는 데 중요한 정보를 제공했습니다.
제 질문 방법을 통해, 저는 다른 사람들이 되새김질할 수 있는 것을 주었습니다. 사람들이 쉽게 참여하고 끌려오게 했습니다. 저는 그들과 동등한 능력을 가지고 있음을 보여주고, 그들과 함께 탐구하도록 초대했습니다. 그들이 겪은 우회적인 길을 알려줌으로써 그들이 다시 시간을 낭비하지 않도록 했으며, 그들의 소중한 시간에 대한 존중을 표시했습니다.
나중에, 모든 사람에게 감사를 표하고, 이번 좋은 토론 경험을 칭찬했을 때, Linux 커널 메일링 리스트의 한 구성원은 제 질문이 해결된 것이 이 리스트의 유명인이라서가 아니라, 올바른 방식으로 질문했기 때문이라고 말했습니다.
해커는 어떤 각도에서 보면 풍부한 지식을 가졌지만 인정이 부족한 사람들입니다. 그가 옳다고 믿습니다. 제가 마치 구걸하는 사람처럼 질문했다면, 제가 누구든 상관없이, 일부 사람들을 화나게 하거나 그들에게 무시당했을 것입니다. 그는 제가 이것을 기록하라고 제안했으며, 이것이 직접 이 가이드의 출현으로 이어졌습니다.
답변을 받지 못한다면
여전히 답변을 받지 못한다면, 우리가 당신을 도울 수 없다고 생각한다고 가정하지 마세요. 때때로 당신의 질문을 본 사람이 답을 모를 뿐입니다. 응답이 없다는 것은 당신이 무시되었다는 것을 의미하지 않습니다. 비록 이 차이를 구별하기 어렵다는 것은 부인할 수 없습니다.
일반적으로, 질문을 단순히 반복해서 게시하는 것은 나쁜 생각입니다. 이것은 무의미한 소음으로 간주됩니다. 인내심을 가지세요. 당신의 질문에 답을 아는 사람은 다른 시간대에 살고 있을 수 있으며, 자고 있을 수 있으며, 당신의 질문이 처음에 잘 조직되지 않았을 수도 있습니다.
다른 채널을 통해 도움을 받을 수 있으며, 이러한 채널은 일반적으로 초보자의 필요에 더 적합합니다.
많은 온라인 및 로컬 사용자 그룹이 있으며, 열정적인 소프트웨어 애호가(그들이 직접 소프트웨어를 작성한 적이 없더라도)로 구성됩니다. 일반적으로 사람들은 이러한 그룹을 만들어 서로 돕고 초보자를 돕습니다.
또한, 많은 상업 회사에 도움을 요청할 수 있습니다. 회사가 크든 작든 상관없습니다. 도움을 받기 위해 비용을 지불해야 한다는 것에 낙담하지 마세요! 결국, 당신의 자동차 엔진 실린더 개스킷이 터졌다면 —— 완전히 가능합니다 —— 당신은 여전히 정비소에 보내고, 수리비를 지불해야 합니다. 소프트웨어가 당신에게 1푼도 들지 않았더라도, 기술 지원이 항상 무료일 것이라고 요구할 수 없습니다.
Linux와 같은 대중적인 소프트웨어의 경우, 각 개발자는 적어도 수만 명의 사용자에 해당합니다. 한 사람이 수만 명의 사용자로부터 도움 요청 전화를 처리하는 것은 근본적으로 불가능합니다. 알다시피, 이러한 도움에 비용을 지불하더라도, 당신이 구매한 유사 소프트웨어와 비교할 때, 당신이 지불하는 것은 미미합니다(일반적으로 폐쇄 소스 소프트웨어의 기술 지원 비용은 오픈소스 소프트웨어보다 훨씬 높으며, 내용도 그렇게 풍부하지 않습니다).
더 잘 질문에 답변하는 방법
태도를 친절하게. 문제가 가져오는 압박은 종종 사람들을 무례하거나 어리석게 보이게 하지만, 실제로는 그렇지 않습니다.
초범자에게 개인적으로 답변. 솔직하게 실수를 인정한 사람들을 공개적으로 모욕할 필요가 없습니다. 진정한 초보자는 검색 방법이나 FAQ를 어디에서 찾는지 모를 수 있습니다.
확실하지 않다면, 반드시 말하세요! 권위 있게 들리는 잘못된 답변은 없는 것보다 더 나쁩니다. 전문가처럼 들리는 것이 재미있다고 해서 다른 사람에게 잘못된 길을 가리키지 마세요. 겸손하고 정직하며, 질문자와 동료 모두에게 좋은 본보기가 되세요.
도울 수 없다면, 방해하지 마세요. 실제 단계에서 농담하지 마세요. 그것은 사용자의 설정을 망칠 수 있습니다 —— 일부 불쌍한 멍청이는 그것을 진짜 명령으로 받아들일 것입니다.
탐색적으로 반문하여 더 많은 세부 사항을 이끌어내세요. 잘한다면, 질문자는 무언가를 배울 수 있습니다 —— 당신도 마찬가지입니다. 바보 같은 질문을 좋은 질문으로 바꾸려고 시도하세요. 우리 모두가 한때 초보자였다는 것을 잊지 마세요.
게으른 사람들에게 RTFM이라고 불평하는 것이 정당하지만, 파일의 위치를 지적하는 것이(단순히 Google 검색 키워드를 제안하더라도) 더 좋습니다.
답변하기로 결정했다면, 좋은 답변을 제공하세요. 다른 사람이 잘못된 도구나 방법을 사용할 때 서투른 임시 방편(workaround)을 제안하지 말고, 더 나은 도구를 추천하고, 문제를 재정의하세요.
긍정적으로 질문에 답변하세요! 질문자가 이미 깊이 연구했고 X, Y, Z, A, B, C를 시도했지만 결과를 얻지 못했다고 표시했다면, A 또는 B를 시도해 보세요 또는 X, Y, Z, A, B, C를 시도해 보세요라고 답변하고 링크를 첨부하는 것은 아무런 도움이 되지 않습니다.
당신의 커뮤니티가 문제에서 배우도록 도와주세요. 좋은 질문에 답변할 때, 어떻게 관련 파일이나 FAQ 파일을 수정하여 동일한 질문에 다시 답변하지 않아도 되는지?라고 자문하고, 파일 관리자에게 패치를 보내세요.
연구 후에 답변을 했다면, 결과를 직접 제시하는 것이 아니라 기술을 보여주세요. 결국 물고기를 주는 것보다 물고기 잡는 법을 가르치는 것이 낫습니다.
관련 자료
개인용 컴퓨터, Unix 시스템 및 네트워크가 어떻게 작동하는지에 대한 기본 지식이 필요하다면, Unix 시스템 및 네트워크 기본 원리를 참조하세요.
소프트웨어나 패치를 게시할 때, 소프트웨어 게시 실천에 따라 운영해 보세요.
감사의 글
Evelyn Mitchel은 몇 가지 바보 같은 질문 예시를 기여하고 더 잘 질문에 답변하는 방법 섹션 작성에 영감을 주었으며, Mikhail Ramendik은 특별히 가치 있는 제안과 개선을 기여했습니다.
이 가이드의 영문판 저작권은 Eric S. Raymond, Rick Moen이 소유합니다.
원문 URL: http://www.catb.org/~esr/faqs/smart-questions.html
출처 명시:개발자 관계 »
