현명하게 질문하는 방법

This is a translated work. The original post was written by Eric S. Raymond, and you can read it here.

According to Eric S. Raymond’s copying policy, permission is granted, already.

이 문서는 번역본입니다. 원본은 에릭 S. 레이몬드에 의해 작성되었으며, 다음 링크를 통해 읽을 수 있습니다.

에릭 S. 레이몬드의 복사 정책에 의하면, 추가적인 번역 허가 절차는 별도로 필요하지 않습니다.

Eric Steven RaymondThyrsus Enterprises<[email protected]>

Rick Moen<[email protected]>

Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen

번역

만일 이 문서를 복사, 미러, 번역 혹은 발췌 하고자 한다면 다음 복사 정책 문서를 확인해 주십시오.

사전 고지

많은 프로젝트들이 도움 요청 방법 부분에 이 문서 링크를 답니다. 링크 다는 것 자체는 괜찮습니다. 그리고 우리가 의도한 사용이기도 하죠. - 다만, 이 글을 읽는 당신이 본인 프로젝트 페이지에 링크를 달려는 웹페이지 주인이라면, 해당 링크 주변에 이 링크는 당신 프로젝트의 문의 창구가 아님을 명확히 보여주는 경고를 게재하시기 바랍니다.

그런 경고가 없다 보니 이 문서를 작성했다는 이유 하나만으로 마치 우리의 임무가 전세계 모든 기술적 문제를 해결하는 것이라고 생각하는 수많은 멍청이들을 상대하게 된다는 점을 고생 끝에 깨달았습니다.

만약 도움이 필요해 이 문서를 읽고 있으며, 이 문서의 작성자들로부터 직접 도움을 받을 수 있으리라는 인상을 받고 있다면 당신이 우리가 얘기하는 그 멍청한 놈들 중 하나 입니다. 우리 한테 질문하지 마십시오. 우린 그냥 무시할 겁니다. 우리가 여기 제시하는 것들은 당신이 다루고 있는 소프트웨어나 하드웨어를 실제로 잘 아는 사람에게서 도움을 받는 방법을 제공할 뿐, 99.9%의 경우 우린 그 전문가가 아닙니다. 당신이 다루고자 하는 문제의 전문가가 작성자 중 한 명이라는 확신이 있지 않는 이상, 우릴 그냥 내버려 두세요. 모두가 더 행복해질 수 있습니다.

소개

해커들의 세계에서는, 당신이 올린 기술적 질문에 달리는 답변의 질은 그 질문의 난이도 뿐만 아니라 질문하는 방식에도 의존합니다. 이 가이드는 더 만족스러운 답변을 받기 위한 질문 방법을 가르쳐주고자 합니다.

오픈 소스 사용이 점차 확대되어가는 요즘, 해커 수준의 좋은 대답을 해커는 아니지만 경험 많은 사용자로부터 받을 때도 많습니다. 이건 좋은 일입니다; 직접 사용자들은 초보자가 겪는 실패에 대해 조금이나마 더 참을성이 많은 경향이 있습니다. 그럼에도 불구하고, 일반적으로, 해커 수준으로 경험 많은 유저들을 대할 때도 여기서 제공할 방법으로 하는 것이 유용한 대답을 얻을 수 있는 가장 효과적인 방법일 것입니다.

가장 먼저 이해해야 하는 것으로, 해커들은 사실 어렵거나 양질이면서 생각 하게 만드는 질문을 좋아합니다. 그렇지 않았다면, 우린 이 자리에 있지 않았을 겁니다. 만약 당신이 우리가 고민할만한 흥미로운 질문을 제공한다면 오히려 우리가 감사할 일입니다; 좋은 질문은 고무적이고 선물과도 같습니다. 좋은 질문들은 우리의 이해를 더 발전시키거나, 혹은 자주 생각지 못했던, 아니면 아직은 알아차리지 못했던 문제들을 드러내곤 합니다. 해커들 사이에선, “좋은 질문이군요!“는 아주 강하고 진심이 담긴 칭찬입니다.

그런데 해커들은 간단한 질문을 마주할 때 적대적이거나 거만해 보인다는 명성을 가지게 되었습니다. 간혹 초보자임을 알고서 무례하게 대하거나 거만하게 행동하는 것처럼 여겨지곤 합니다만 이것은 사실이 아닙니다.

분명히 말하는데, 우리는 질문하기 전에 본인이 스스로 해야만 하는 것들조차 하지 않거나, 생각하기조차 싫어하는 사람에게 적대적입니다. 그런 사람들은 시간만 축내요 - 그들은 되갚음도 없이 답만 가져가거나, 더 흥미로운 질문이나 대답을 해줄 가치가 있는 다른 사람에게 할애할 수 있었을 시간을 낭비하는 상황을 초래합니다. 우린 이런 사람을 “루저"라고 부릅니다(역사적인 이유로 간혹 “lusers"로 표기하곤 합니다).

우리는 많은 사람들이 우리가 만든 소프트웨어를 그저 사용하고자 하거나 기술적인 상세 내용에 관심이 없다는 점을 알고 있습니다. 대부분의 사람들에겐, 컴퓨터는 전적으로 도구이자 결과물을 만들어 내기 위한 수단일 뿐이죠; 대중은 해야만 하는 더 중요한 일들이 있고 또 다른 나름대로의 삶이 있죠. 우리는 그 점을 인정하고, 우리를 신나게 하는 기술적 문제에 대해서 모두가 관심을 갖기를 기대하지는 않습니다. 그럼에도 불구하고, 우리의 답변 방식은 그런 흥미로운 것들을 인지하고 문제-해결에 능동적으로 참여할 의지가 있는 사람들에게 맞추어져 있습니다. 그 점은 변하지 않을 것입니다. 변해서도 안되고요; 만약 변한다면, 우리가 잘하는 분야에 있어서 덜 효율적인 사람들이 될테니까요.

우린 (대부분) 봉사자들입니다. 우린 바쁜 삶 와중에 질문에 답변하고자 시간을 내고 간혹 그 질문의 양에 압도되기도 합니다. 따라서 거침없이 걸러냅니다. 특히, 우리의 질문-답변 시간을 승자들에게 더 효율적으로 사용하고자 루저들의 것으로 보이는 질문은 과감히 버립니다.

만약 이런 태도가 몹시 불쾌하고, 기분 나쁘고 거만하다고 생각한다면, 당신의 전제를 재확인하세요. 우린 당신에게 굽신거리라고 요구하는 것이 아닙니다 - 사실상, 우리 중 대부분은 당신을 동등하게 대하려고 노력하고 해커 문화로 환영하고 싶지만, 이는 당신도 그런 대접을 받을 수 있도록 스스로 노력할 것을 요구합니다. 그러나 스스로를 돕지 않는 사람들까지 돕기를 바라는 것은 순전히 비효율적입니다. 무지한 것은 괜찮습니다; 멍청하게 구는 것은 괜찮지 않습니다.

자, 우리에게 관심을 받기 위해서 이미 기술 분야에 능통할 필요는 없지만, 완벽으로 이끄는 태도를 보이는 것은 필요합니다 - 깨어있고, 사려 깊고, 관찰력 있고, 해답을 찾는 과정에 능동적으로 참여하고자 하는 의지 말이죠. 이런 불평등을 도저히 견딜 수 없다면, 해커들이 개인적으로 당신을 돕기 위해 봉사하기를 바라지 말고 상업적인 지원 계약을 체결하여 도와줄 직원에게 비용을 지불할 것을 권장합니다.

만약 도움을 받기 위해 우리에게 오고자 최종적으로 결정했다면, 그런 루저들 중 하나가 되지 않기를 바랍니다. 당신 스스로도 그렇게 보여지긴 싫을 겁니다. 빠르고 즉각적인 답변을 받는 최고의 방법은 똑똑하고, 확신에 차있고, 단서도 가지고 있는 사람이 마침 특정 문제와 관련해서 도움이 필요한 것처럼 행동하는 것입니다.

(이 문서에 대한 개선점은 환영합니다. 제안 사항은 [email protected] 이나 respond-[email protected]로 메일주세요. 주의할 점은 이 문서가 네티켓을 가르치기 위한 문서로 제작된 것이 아니라는 점입니다. 또한 기술 관련 포럼에서 유용한 답변을 이끌어내기 위한 방법과 관련이 없는 제안들은 거절합니다.)

질문 전에

기술적 질문들을 이메일이나 뉴스 그룹 혹은 웹사이트 채팅에 질문하기 전에, 다음을 지키세요:

1. 작성하려는 포럼이나 메일링 리스트의 과거 문서에서 답을 찾아볼 것
2. 인터넷 검색을 통해 답을 찾아볼 것
3. 매뉴얼을 읽어 답을 찾아볼 것
4. FAQ(자주 묻는 질문)란을 읽어 답을 찾아볼 것
5. 검사, 실험을 통해 답을 찾아볼 것
6. 숙련된 친구에게 물어 답을 찾아볼 것
7. 프로그래머라면, 소스 코드를 읽어 답을 찾아볼 것

질문을 할 때는, 이러한 것들은 먼저 했다는 것을 명확히 보이십시오; 이것은 당신이 게으른 스폰지가 아닐 뿐만 아니라 다른 사람 시간을 낭비하려는 것이 아님을 확인하는데 도움이 됩니다. 더 좋은 방법은, 이런 과정을 통해서 당신이 무엇을 배웠는지 명시하는 것입니다. 우린 제공할 해답을 통해 추가적으로 무언가 배울 능력이 있는 사람이라는 것을 스스로 증명한 사람에게 답변하는 것을 선호합니다.

본인에게 주어진 에러 메시지든 뭐든 간에 구글에 검색해보는 등의 전략을 취하세요 (웹 페이지 뿐만 아니라 구글 그룹도 검색하세요). 이 방법은 당신의 질문에 대한 답이 있는 문서나 메일링 리스트 쓰레드로 곧바로 연결될 수도 있습니다. 그렇지 않더라도, “구글에 다음과 같은 구절을 검색했지만 괜찮아 보이는 결과를 얻지 못했음"을 언급하는 것은 이메일이나 뉴스 포스팅에서 도움을 구하기 좋은 방법입니다. 어떤 검색들은 도움이 되지 않았는지를 기록해 둔다는 측면에서라도 말이죠. 뿐만 아니라, 그런 내용을 추가함으로써 당신과 유사한 문제를 가지고 있는 사람들은 검색어를 통해 곧장 현재 쓰레드로 연결될 수 있도록 하여 문제와 해결책을 찾을 수 있게 합니다.

시간을 가지세요. 복잡한 문제를 구글링 몇 초로 해결할 수 있을거라고 기대하지 마세요. FAQ를 읽고 이해하고, 편히 앉아서, 차분히 마음을 가라앉히며, 전문가에게 문의하기 전 해당 문제에 대해 생각할 조금의 시간을 갖길 바랍니다. 우릴 믿어요, 우린 당신이 얼마나 많이 읽고 고민했는지를 질문에서 식별해낼 수 있으며, 충분히 준비된 채로 왔다면 더욱 진심으로 돕고자 할 것입니다. 단지 첫 검색 결과가 적절한 대답을 제공하지 않았거나 (혹은 너무 많은 결과를 제공했다고) 즉각적으로 질문 포화를 열지 말기를 바랍니다.

질문을 준비하세요. 숙고하세요. 서두른다는 느낌이 드는 질문은 대강의 답변을 받거나 아예 답을 받지 못합니다. 도움을 구하기 전에 문제를 해결하고자 노력과 고민을 했다는 점이 더 드러날수록, 실제로 도움을 받을 확률은 더 높아집니다.

잘못된 질문을 할 가능성을 인지하세요. 만일 틀린 전제 하에서 질문을 한다면, 아무개 해커는 아마도, 업로드 된 잘못된 질문 그 자체에는 올바른 답이지만 실질적으로 아무 도움이 안 되는 답변을 달며 “멍청한 질문이네…“라고 생각할 것입니다. 그리고 나선, 실질적으로 필요한 것이 아닌 본인이 잘못 물은 질문에 답변을 받은 경험을 통해 당신이 교훈을 얻기를 기대할 겁니다.

당신이 답변을 받을 자격이 있다고 생각하지 마세요. 아닙니다; 어쨌든, 당신은 비용을 지불하는 서비스 이용자가 아닙니다. 만일 당신이 답변을 제공 받는다면, 단지 수동적으로 타인의 지식을 요구하는게 아니라, 오히려 집단에게 추가 지식을 제공할 수도 있는 주요하고, 흥미롭고, 생각할 거리를 제공하는 질문을 했기 때문에 답변을 얻게 되는 겁니다.

한편, 답변을 찾아가는 과정에서 도움을 주고자 하는 의지가 있고 능력도 있음을 명확히 밝히는 것은 좋은 출발입니다. “혹시 누가 링크라도 제공해줄래요?”, “내 예시에서 빠진게 뭐죠?”, 그리고 “어떤 사이트를 추가로 체크해봤어야 좋았을까요?” 등이 “내가 하면 되는 정확한 절차만 순서대로 적어주세요.“보다 정답을 얻기 유리합니다. 왜냐하면 당신은 누군가 정확한 방향만 제공한다면 답 찾는 과정을 완수할 거라는 진실된 의지를 명확히 보였기 때문이죠.

질문할 때

포럼을 신중히 선택할 것

어디에 질문할지 선택하는 것은 중요합니다. 아래의 행동을 하면 무시 당하거나, 루저 취급을 받을 겁니다:

• 주제에서 벗어난 포럼에 질문하는 행위
• 상당한 수준의 기술적 질문이 예상되는 포럼에 매우 기초적인 질문을 하거나 혹은 그 역에 해당하는 행위
• 서로 다른 뉴스 그룹에 너무 많이 포스팅하는 행위
• 당신과 아는 사이도 아니고, 당신의 문제에 책임이 있지도 않은 사람에게 개인 이메일을 보내는 행위

해커들은 관련 없는 것들로부터 본인들의 커뮤니케이션 채널이 잠식 당하는 것을 막기 위해서 부적절한 질문들은 날려버립니다. 당신도 이런 일이 발생하기를 원하진 않겠지요.

따라서, 첫 번째 단계는 올바른 포럼을 찾는 것입니다. 다시 말하지만, 구글이나 다른 웹 검색 방법은 당신의 친한 친구입니다. 당신에게 어려움을 주고 있는 하드웨어나 소프트웨어와 가장 밀접한 관련이 있는 프로젝트 웹페이지를 찾기 위해 그 방법을 사용하세요. 보통 그런 웹사이트는 FAQ(자주 묻는 질문) 목록의 링크나, 프로젝트 메일링 리스트 링크, 혹은 과거 문서 링크가 있습니다. (FAQ등을 읽는 것을 포함한) 당신의 노력을 통해 해결책을 찾지 못한 경우라면, 메일링 리스트가 마지막으로 도움을 요청할 장소입니다. 프로젝트 페이지들은 보통 버그 신고 절차를 제시하고 있거나, 그에 대한 링크를 제공합니다; 제공한다면, 절차대로 진행하세요.

익숙하지 않은 포럼이나 사람에게 이메일부터 발송하는 것은, 어떤 경우라도 위험합니다. 예를 들어, 정보 제공 웹페이지의 저자가 당신의 무료 상담사라고 가정하지 마십시오. 당신의 질문이 환영받을 거라는 낙관적인 추측을 하지 마세요 - 불확실하다면, 다른 곳으로 발송하거나 발송 자체를 하지 마세요.

웹 포럼이나 뉴스 그룹, 메일링 리스트를 고를 때에는 이름 자체를 너무 과하게 신뢰하지 마세요; FAQ나 공지 등을 통해 당신의 질문이 주제에 적합한지 확인하기 바랍니다. 이전에 포스팅된 기존 트래픽을 몇 개 읽어서 그 곳에서는 어떤 식의 대화가 이루어지는지 확인하기 바랍니다. 사실, 뉴스 그룹이나 메일링 리스트에 포스팅하기 전에 그곳에서도 문제에 관련된 키워드를 검색해보는 것이 좋은 방법입니다. 정답을 찾을 수 있을 뿐더러, 그렇지 않더라도 더 좋은 질문을 구성하는데 도움이 되기 때문입니다.

도움이 될 것으로 보이는 다수의 채널에 한꺼번에 질문을 올리지 마세요. 그것은 마치 소리지르는 것과 같아서 사람들을 짜증나게 합니다. 하나 하나 차근차근 진행하세요.

어떤 주제인지 정확히 알기를 바랍니다! 오래되고 잦은 실수 중 하나는 유닉스나 윈도우즈 프로그래밍 인터페이스 관련 질문을 두 운영체제 모두에서 사용 가능한 도구, 라이브러리, 언어 관련 포럼에 올리는 실수입니다. 이게 왜 문제가 되는지 이해를 못하겠다면, 이해할 때까지 질문을 하지 않는게 최선입니다.

일반적으로, 잘 선택된 공개 포럼에 질문하는 것이 사적인 포럼에 하는 것보다 유용한 답변을 받을 확률이 높습니다. 이에는 다양한 이유가 있습니다. 하나는 잠재적 답변자의 수가 많다는 점입니다. 다른 이유는 보고 있는 사람이 많다는 점입니다; 해커들은 소수의 사람에게 도움이 되는 것 보다는 다수의 사람을 가르칠 수 있는 질문에 대답하는 것을 선호합니다.

어느 정도 이해는 되지만, 숙련된 해커나 유명 소프트웨어 제작자들은 잘못 타게팅된 메시지들을 적당한 수준을 넘어서 너무나 많이 받고 있습니다. 이 메시지 홍수에 하나를 더 보탬으로써, 당신이 드디어 낙타의 등을 부러뜨리는 마지막 지푸라기가 되는 극단적인 경우일지도 모릅니다. - 꽤나 자주, 유명 프로젝트 공헌자들이 더 이상 견딜 수 없는 수준의 쓸모 없는 이메일 트래픽 등의 부수적 피해로 도움을 중단하는 경우가 발생합니다.

스택 오버플로우

검색하세요, 그리고나서 스택 익스체인지에 질문하세요.

최근 수 년동안, 스택 익스체인지 커뮤니티 사이트들은 기술적이거나 여타 다른 질문에 대한 대답을 제공하는 주요한 자원이 되었고, 심지어 꽤 많은 오픈-소스 프로젝트의 선호되는 포럼이기도 합니다.

스택 익스체인지를 찾기 전에 구글 검색부터 시작하세요; 구글은 실시간으로 색인을 합니다. 누군가 유사한 질문을 이미 했을 확률이 매우 높고, 스택 익스체인지 사이트들은 검색 결과 최상단 근처에 위치합니다. 구글 검색 결과로부터 별다른 것을 찾지 못했다면, 당신의 질문과 가장 관련 있는 사이트로 특정해 재검색하세요(아래 참조). 태그로 검색하는 것도 검색 결과를 좁히는데 유용합니다.

그래도 아무것도 찾지 못했다면, 가장 주제에 맞는 하나의 사이트에 질문을 남기십시오. 코드와 관련해서는 특히, 형식을 맞춰주는 도구(pre-formatting tools)를 사용하고, 본인의 질문과 가장 본질적으로 관련 있는 태그를 추가하시기 바랍니다 (특히 프로그래밍 언어 이름, 운영 체제, 또는 문제가 있는 라이브러리를 적으세요). 만약 누군가가 댓글로 더 자세한 정보를 요구한다면, 해당 정보를 포함할 수 있도록 메인 포스트 자체를 수정하시기 바랍니다. 특정 답변이 도움이 된다면, 윗 방향 화살표를 클릭해 추천하세요; 특정 답변이 해결책이었다면, 추천 화살표 아래의 체크 표시를 클릭해 답변으로 채택하기 바랍니다.

스택 익스체인지는 100개가 넘는 사이트로 발전하였습니다, 그러나 아래에 후보로 가장 적합한 것들을 제시합니다.

• Super User는 일반 사용자의 컴퓨팅과 관련한 질문에 적합합니다. 당신의 질문이 코드나 네트워크 환경 하에서만 사용하는 특정 프로그램과 연관이 없다면 이 곳이 적합합니다.
• Stack Overflow는 프로그래밍 관련 질문에 적합합니다.
• Server Fault는 서버와 네트워크 관리 질문에 적합합니다.

몇몇의 프로젝트는 본인들만의 사이트를 가지고 있습니다. 예를 들어, 안드로이드, 우분투, TeX/LaTeX 그리고 SharePoint등이 그러합니다. 스택 익스체인지 사이트를 통해 최신 리스트를 확인하길 바랍니다.

웹과 IRC 포럼

지역 사용자 모임이나 리눅스 배포판은 초보 사용자들이 도움 받을 수 있는 웹 포럼이나 IRC 채널을 홍보할 것입니다. (비 영어권 국가들의 경우, 초보 사용자 포럼은 메일링 리스트일 확률이 높습니다.) 이러한 곳들은, 특히 본인이 상대적으로 간단한, 혹은 공통적인 문제에 걸려 넘어졌다고 판단한다면 질문하기에 적합한 곳들입니다. 홍보 중인 IRC 채널은 아무나 입장해서 질문할 수 있고 실시간 답변을 받을 확률이 높습니다.

사실, 문제를 일으키는 프로그램을 리눅스 배포판(최근에 더 흔해졌기 때문에)으로부터 제공 받았다면, 해당 배포판의 포럼/리스트에 질문하는 것이 프로그램의 프로젝트 포럼/리스트에 질문하는 것보다 낫습니다. 프로젝트 해커들은 아마도 “우리 빌드를 사용하세요"라고 답하고 말 것입니다.

어떤 웹 포럼이든 포스팅하기 전에, 검색 기능이 있는지 확인하십시오. 있다면, 당신의 문제와 관련된 몇 개의 검색어를 시도하세요; 혹시 도움이 될지 모릅니다. 일반적인 웹 검색을 마쳤더라도(그랬어야만 하고), 포럼에서도 어쨌든 검색해보십시오; 웹 전반 검색 엔진이 해당 포럼까지 최근에 색인하지는 않았을지도 모릅니다.

프로젝트들 사이에서 사용자 지원은 웹 포럼이나 IRC 채널을 통해 하고 이메일을 기반으로 하는 대화는 개발 트래픽을 위해 아끼는 경향이 늘어나고 있습니다. 따라서 특정한 프로젝트와 관련된 도움을 구하는 것이라면 그런 채널을 찾아보길 바랍니다.

IRC에서는, 입장 하자마자 본인의 문제 상황과 관련된 설명을 길게 늘어놓지 않는 것이 좋습니다; 몇몇 사람은 이 행동을 채널-도배로 받아들입니다. 최고의 방법은 채널에서 대화를 열기 위해 우선 한 줄 정도로 상황 설명을 하는 것입니다.

두 번째 단계로써, 프로젝트 메일링 리스트를 활용할 것

프로젝트가 개발 메일링 리스트를 가지고 있다면, 비록 당신의 질문에 대답해줄 최선의 사람이 누구인지 알 것 같더라도 개인에게 메일을 보내지 말고 리스트에 작성하십시오. 프로젝트 문서나 홈페이지를 통해 프로젝트 메일링 리스트 주소를 찾은 후 그 것을 사용하세요. 이러한 방법을 권장하는 이유가 여럿 있습니다:

• 한 명의 개발자에게 좋은 질문은 모든 그룹에게도 가치가 있습니다. 반대로, 질문이 메일링 리스트에 올리기는 너무 멍청하다고 스스로 추측한다면, 그 역시도 개별 개발자를 괴롭힐 변명이 될 수 없기는 마찬가지 입니다.
• 리스트에 질문 하는 것은 개발자 부담을 분산 시킵니다. 개별 개발자(특히, 프로젝트 리더)는 당신의 질문에 대답하기에는 너무 바쁠지도 모릅니다.
• 대부분의 메일링 리스트는 보관되고, 일반적으로 보관된 메일들은 검색 엔진에 의해 색인됩니다. 만약 당신이 리스트에 질문을 올리고 답변이 달린다면, 미래의 질문자는 질문을 찾을 수 있고 다시 질문할 필요 없이 웹상에서 답변을 구할 수 있게 됩니다.
• 만약 특정 질문이 자주 반복되는 것으로 보인다면, 개발자들은 해당 정보를 활용하여 소프트웨어나 문서를 덜 헷갈리게 개선할 수 있습니다. 그러나 개별적으로 질문한다면, 아무도 해당 질문이 어느 정도나 반복되는지에 대한 전체적인 그림을 그릴 수 없게 됩니다.

만약 프로젝트가 “사용자"와 “개발자”(또는 “해커”) 메일링 리스트나 포럼을 모두 가지고 있다면, 코드를 해킹하고 있지 않는 이상, “사용자” 리스트/포럼에 질문하기 바랍니다. 개발자 리스트에서도 환영받을 거라고 기대하지 마시기 바랍니다. 그 곳에선 아마도 해당 질문을 소음이나 개발자 트래픽 낭비 정도로 취급할 것입니다.

그러나, 당신의 질문이 사소한 것이 아니라고 확신 할 수 있거나, “사용자” 리스트/포럼에서 수 일간 답변이 달리지 않는 경우라면, “개발자” 리스트/포럼을 시도하시기 바랍니다. 포스팅 전에 해당 프로젝트만의 방식 등을 배우기 위해 수 일 동안 있었던 메시지나 보관된 메시지를 읽으며 며칠 간 숨어있기를 권장합니다. (사실 이것은 사적이거나 사실상 사적인 리스트에도 해당하는 좋은 충고입니다)

만약 프로젝트의 메일링 리스트 주소는 찾을 수 없고 해당 프로젝트 관리자의 주소만 보인다면, 관리자에게 작성하기 바랍니다. 하지만 그런 경우일지라도, 메일링 리스트가 존재하지 않는다고 추측하지 마십시오. 이메일에 분명하게, ‘메일링 리스트를 찾아 보았으나 적절한 것을 찾지 못했음’을 명시하기 바랍니다. 또한, 당신의 메일이 다른 사람들에게 전달되는 것을 개의치 않음을 밝히십시오. (많은 사람들이 사적인 이메일은 사적인 것으로 남아야 한다고 믿습니다. 그 안에 사적인 것이 아무 것도 없더라도 말이죠. 전달을 허락함으로써 응답자가 당신의 이메일을 어떻게 다루어야 할지 선택할 기회를 제공합니다)

의미있고 특정적인 제목 헤더를 사용할 것

메일링 리스트, 뉴스 그룹, 웹 포럼을 막론하고, 제목 부분은 50 글자 이하로 숙련된 전문가의 관심을 끌 수 있는 최상의 기회입니다. 그런 기회를 “제발 저 좀 도와주세요"등의 헛소리로 낭비하지 않기를 바랍니다 (“쫌 도와줘!!!!” 따위는 바로 버려집니다). 당신의 괴로움 수준으로 우리를 놀래키려 하지 마십시오; 해당 공간은 상당히-구체적인 문제 설명을 위해 사용하기 바랍니다.

제목 란의 좋은 예시는, 많은 기술 지원 단체들이 사용하고 있듯이, “목적 - 편차” 입니다. “목적” 부분은 문제점이나 문제들의 그룹을 명시하고 “편차” 부분은 예측된 행동으로 부터 벗어난 편차를 설명하는 부분입니다.

멍청함: 도와줘! 내 노트북 비디오가 제대로 작동하질 않아!

현명함: X.org 6.8.1 에서 마우스 커서 동작 이상, 아무개제조사 MV1005 비디오 칩셋

더 현명함: 아무개제조사 MV1005 비디오 칩셋에서 X.org 6.8.1 마우스 커서 - 이상 행동

“목적 - 편차” 방식으로 설명하는 과정 자체가 스스로 문제를 더욱 자세히 생각하게 만들어줍니다. 무엇이 영향을 받았나요? 단지 마우스 커서인가요 아니면 다른 그래픽도 문제인가요? 이 문제가 X의 X.org 특정 버전에서만 그런가요? 그 버전이 6.8.1 인가요? 아니면 이 문제가 아무개제조사 비디오 칩셋에서만 문제인가요? 아니면 모델 MV1005만 문제인가요? 결과를 읽는 해커는 당신이 무슨 문제를 겪고 있는지 뿐만 아니라 어떠한문제를 겪고 있는지를 한 눈에 알 수 있습니다.

더 일반적으로, 제목들만 보이는 질문 보관 색인을 보고 있다고 상상해보기 바랍니다. 제목 부분을 본인의 질문과 더 잘 부합하도록 적음으로써 비슷한 질문을 검색하고 있는 다음 사람이 추가적인 질문을 다시 올리는 것보다 더 쉽게 답변이 달린 쓰레드를 찾을 수 있도록 만들어줍니다.

답변에 추가 질문을 한다고 하면, 질문을 하고 있다는 것을 확실히 하기 위해 제목 부분을 수정하는 것을 확실히 하기 바랍니다. “답변: 테스트"나 “답변: 새로운 버그” 처럼 보이는 제목은 유용할 만큼의 관심을 받을 확률이 줄어듭니다. 또한, 새로운 독자들에게 문맥을 파악할 최소한의 일관성을 위해 이전 답변의 일부를 인용하기 바랍니다.

완전히 새로운 쓰레드를 시작할 것임에도 단순히 리스트의 메시지에 답변을 클릭하지 마십시오. 이것은 당신의 답변 대상을 제한합니다. 일부 메일 리더 프로그램은, 예를 들어 mutt의 경우, 유저가 쓰레드로 정렬하고 쓰레드를 접음으로써 일부 메시지들을 가릴 수 있도록 합니다. 그런 기능을 사용 하는 사람들은 당신의 메시지를 영원히 보지 못합니다.

제목 변경으로는 충분하지 않습니다. Mutt와 다른 메일 리더 프로그램들은 이메일을 쓰레드에 편입하기 위해 제목 뿐만 아니라 다른 정보들도 확인합니다. 차라리 완전히 새로운 이메일을 작성하십시오.

웹 포럼에서의 좋은 방법에 해당하는 규칙은 약간 다른데, 이는 메시지들이 더 엄격한 논의 쓰레드 규정에 의해 관리되기 때문에 다른 쓰레드에서는 잘 보이지 않기 때문입니다. 답변에서 질문을 할 때는 제목 변경이 불필요합니다. 모든 포럼이 답변에 제목 부분을 허용하는 것은 아닐 뿐더러, 허용하더라도 그것을 아무도 읽지 않습니다. 어쨌든, 답변에서 질문을 하는 것이 바보 같은 짓인 이유는 그 쓰레드를 읽는 사람 외에는 누구도 읽지 않을 것이기 때문입니다. 따라서, 해당 쓰레드 인원만 질문을 읽기를 본인 스스로 바라지 않는 이상 새로운 쓰레드를 시작하기 바랍니다.

답변하기 쉽도록 할 것

질문을 “대답은 여기로 보내주세요…“로 마치는 것은 대답을 받을 확률을 낮춥니다. 이메일 프로그램에서 회신란을 정확히 수정하는 몇 초 조차도 감수하기 싫은거라면, 답변자들오 질문을 해결하고자 고민하는 몇 초를 감수하기 싫을 것입니다. 만약 사용 중인 프로그램이 이런 기능을 지원하지 않는다면, 더 나은 프로그램을 사용하기 바랍니다. 만약 당신의 운영체제가 이런 기능을 지원하는 이메일 프로그램을 단 하나도 지원하지 않으면, 더 나은 운영 체제를 사용하기 바랍니다.

웹 포럼에서 정보가 민감한 것들이라고 생각하지 않는 이상, 답변을 이메일로 요구하는 것은 예의 없는 행위입니다. (누군가는 알 수 없는 이유로 그렇게 해줄지도 모르나, 전체 포럼은 아닙니다.) 만약 쓰레드 답변에 대한 복사본을 이메일로 받기를 원한다면, 웹 포럼 자체가 발송하도록 설정하기 바랍니다; 이 기능은 대부분의 포럼이 “쓰레드 즐겨찾기"나 “답변 이메일로 보내기” 등의 옵션을 통해 지원하고 있습니다.

깔끔하고 문법적으로 올바르고 오/탈자가 없도록 쓸 것

우리는 부주의하고 대충 글을 쓰는 사람들이 생각이나 코딩에 있어서도 부주의하고 대충일 가능성이 (내기할 수 있을 만큼) 크다는 것을 경험을 통해 발견하였습니다. 부주의하고 대충 생각하는 사람들을 위해 답변하는 것은 가치가 없습니다; 차라리 우리 시간은 다른 곳에 쓰는게 낫습니다.

따라서 당신의 생각을 명확하게 표현하는 것이 중요합니다. 그렇게 하기 귀찮다면, 우리도 관심을 갖기 귀찮습니다. 당신의 표현을 다듬을 별도의 노력을 취하세요. 딱딱하거나 격식을 차릴 필요까진 없습니다 - 사실, 해커 문화는 적재적소에 잘 사용된 격식 차리지 않은, 혹은 심지어 (비)속어인, 유머러스한 언어를 더 가치 있게 생각합니다. 하지만 적절히 사용되어야 합니다; 당신이 생각하고, 집중하고 있다는 것을 나타내는 무언가가 필요하기 때문입니다.

맞춤법, 문장부호와 대문자를 정확히 사용하십시오. “않"을 “안"으로, “돼"를 “되"로 “데"를 “대로 혼동하지 마십시오. 쩐뿌 떄문짜로 짞썽하찌(TYPE IN ALL CAPS) 마십시오. 이는 소리지르는 것으로 읽히고 무례하다고 여겨집니다. (모두 소문자로 적는 것은 덜 짜증나지만, 읽기 어렵습니다. Alan Cox는 괜찮아도 너는 안돼요)

더 일반적으로, 문맹처럼 쓰면 무시될 것입니다. 따라서 카톡 줄임말 같은 것들을 사용하지 마십시오. “맞아요"를 “ㅇㅇ"로 쓰는 행위들이 몇 글자 덜 입력하는 것을 위해 문맹처럼 보이게 만듭니다. 더 심각한 경우: 댕댕이, 머머리와 같은 인터넷 용어를 사용하는 것은 사망 선고나 다름없고 그 어떤 대답 없이 차가운 침묵만이 돌아올 것임을 보장합니다. (혹은, 경멸이 섞인 도움이나 비꼬는 대응이 있을지도 모름)

본인의 모국어가 아닌 포럼에서 질문을 하는 경우, 약간은 느슨한 맞춤법 검사나 문법 검사가 이루어질지는 모르나 게으름에 대해선 그런 느슨함은 없습니다. (맞아요, 우린 그런 차이를 구분해낼 수 있습니다) 또한, 응답자의 모국어가 무엇인지 알지 못하는 경우, 영어로 쓰십시오. 바쁜 해커들은 이해하지 못하는 언어로 된 질문은 치워버리는 경향이 있고 영어는 인터넷에서 인정받는 언어입니다. 영어로 씀으로써 질문이 안 읽히고 버려지는 경우를 최소화할 수 있습니다. 만약 외국어로써 영어로 작성하고 있다면, 잠재 응답자들에게 언어상의 어려움을 알리고 그런 애로사항을 피하는 좋은 형식들이 있습니다. 예를 들어:

• 영어는 제 모국어가 아닙니다; 타이핑 오류는 양해를 구합니다. 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이 아닌, 일반 텍스트 메일(plain text)을 보내십시오. (HTML을 끄는 것은 어렵지 않습니다)
• MIME 첨부는 일반적으로 괜찮습니다. 그러나 그 안에 실질적인 내용이 있을 경우에만 그렇습니다. (소스 파일이나 패치 파일 첨부 등의 경우) 그러나 메일 클라이언트에 의해 작성된 양식은 괜찮지 않습니다 (예를 들어, 본인 메시지의 복사본 등).
• 전체 문단이 한 줄이고 줄넘김이 여러차례 된 이메일을 보내지 마십시오. (이는 메시지 일부에 대한 답변을 하기 너무 어렵게 만듭니다.) 응답자가 80 글자 혹은 그 이하 너비의 텍스트 화면에서 메일을 읽을 거으로 가정하고, 줄넘김을 그에 맞게 설정하기 바랍니다.
• 그러나, (로그 파일이나 세션 정보 등)처럼 고정된 열 너비에서 출력된 데이터는 줄 넘기기 하지 마십시오. 데이터는 있는 그대로 포함되어야 합니다. 따라서 응답자들이 당신이 본 것과 같은 것을 보고 있다고 확신할 수 있어야 합니다.
• MIME Quotes-Printable 인코딩을 영어 포럼에 보내지 마십시오. 이 인코딩은 ASCII가 제공할 수 없는 언어 사용자의 포럼에서는 필요할지 모르나 대부분의 이메일 프로그램은 지원하지 않습니다. 이 인코딩이 부서질 경우, 깨진 글자들의 나열은 보기 어렵고 거슬립니다 - 어쩌면 전송한 내용의 원래 의미를 해칠수도 있습니다.
• 절대, 절대로 해커들이 마이크로소프트 워드나 엑셀처럼 특허권 있는(proprietary) 문서 양식을 읽을 수 있으리라 기대하지 마십시오. 대부분의 해커들은 당신이나 제공한 파일에 대해서 문짝에 던져진 아지랑이 피어오르는 돼지 거름을 본 것처럼 반응할 것입니다. 비록 어떻게 열어볼 수는 있을지언정, 그래야 한다는 점에 분개할 것입니다.
• 만약 윈도우 기계에서 이메일을 보내야 한다면, 마이크로소프트의 문제가 많은 “Smart Quotes"기능을 끄기 바랍니다. (Tools>AutoCorrect Options, AutoFormat As You Type 아래의 smart quotes 체크박스 해제) 이로써 당신의 메일이 쓰레기 글자들로 변하는 것을 막을 수 있습니다.
• 웹 포럼에서, “웃는 이모티콘"이나 “HTML"기능을 (제공된다면)남용하지 마십시오. 한 개나 두 개는 괜찮지만 여러개의 색깔까지 있는 화려한 글자들은 너를 찐따처럼 보이게 만듭니다. 진지하게, 과도한 이모티콘 사용, 색깔, 특이한 폰트 사용은 실실대는 10대 소녀처럼 보이게 할 뿐, 답변보다 섹스에 관심있는게 아니라면 좋은 아이디어가 아닙니다.

만약 넷스케이프 메신저, MS 아웃룩과 같은 그래픽 환경 이메일 클라이언트를 사용한다면, 기본 설정으로 사용될 경우 규칙들을 어길 수도 있음을 인지하십시오. 대부분 그런 클라이언트들은 메뉴 기반의 “소스 보기"가 있습니다. 보낸 메일함에 있는 메일 등에 사용하여, 쓸데 없는 것들이 포함되지 않고 일반 글자(Plain Text) 양식으로 전송되는지 확인하시기 바랍니다.

문제에 대해 정밀하고 정보가 충분히 제공되도록 할 것

• 문제의 증상이나 버그를 조심스럽게 그리고 명확하게 묘사할 것
• (기기, 운영 체제, 프로그램, 뭐든지) 그 것이 발생하는 환경을 묘사할 것. 제조사의 배포판이나 출시 버전을 제공할 것. (예, “Fedora Core 7”, “Slackware 9.1”, 등)
• 질문 전에 문제를 이해하기 위해 시도했던 검색 과정을 서술할 것
• 질문 전에 문제를 스스로 규정하고 해결해보고자 했던 진단 절차를 서술할 것
• 관련 있을 가능성이 있는 컴퓨터 변화나 소프트웨어 설정 변경을 서술할 것
• 가능하다면, 통제된 환경에서 해당 문제를 재발생 시킬 수 있는 방법을 제공할 것

해커들이 물을 만한 것들에 대해서 심사숙고 하는데 최선을 다하고, 도움 요청에 앞서 그런 질문에 대한 답을 하십시오.

만약 코드의 버그를 신고하는거라면 통제된 환경하에서 해당 문제를 재발생시킬 수 있는 방법이 해커들에게 특히 중요합니다. 이렇게 한다면, 유용한 답변을 받을 확률과 속도가 동시에 월등히 개선됩니다.

Simon Tatham은 버그 신고 효율적으로 하는 방법에 대해서 훌륭한 에세이를 작성하였습니다. 읽어보기를 강력히 권장합니다.

양은 정확도가 아니다

정확하고 정보를 충분히 제공해야만 합니다. 이 목적은 도움 요청을 위한 데이터나 엄청난 양의 코드를 단순히 쏟아붇는다고 달성되지 않습니다. 프로그램 작동을 멈추는 크고 복잡한 테스트 케이스가 존재한다면, 가능한 작게 줄이는 것을 시도하기 바랍니다.

이것은 최소 세 가지의 이유로 유용합니다. 째: 질문을 단순화하고자 노력한 것을 보이는 것은 답변을 받을 확률을 높인다, 둘째: 질문을 단순화하는 것은 유용한 답변을 받을 확률을 높인다, 셋째: 버그 신고를 다듬는 과정에서 해결 방법을 스스로 찾을 가능성이 있다.

버그를 찾았다고 섣불리 판단하지 말 것

소프트웨어 사용상 문제가 발생했을 때, 아주 아주 확신하지 않는 이상 버그를 발견했다고 주장하지 마십시오. 힌트: 문제를 해결할 수 있는 소스 코드 패치를 제공할 수 없거나, 이전 버전과 비교해 잘못된 행동을 유발하는 부분을 찾는 회귀 테스트(regression test)를 진행하기 전에는 확신하지 못하는 겁니다. 이는 웹페이지나 문서에서도 적용됩니다; 문서에서 “버그"를 발견했다면, 대체 텍스트를 제공하거나 원래 있어야 할 페이지를 제공해야만 합니다.

당신이 겪는 문제를 다른 수많은 사람들은 겪지 않는다는 점을 기억하기 바랍니다. 그게 아니라면, 웹 검색 과정이나 문서를 읽는 도중에 학습할 수 있었을 겁니다(불평 전에 이 과정을 거쳤겠죠, 아닌가요?). 이는 매우 높은 확률로 당신이 뭔가를 잘못한 거지, 소프트웨어 탓이 아님을 의미합니다.

소프트웨어 제작자들은 가능한 잘 작동하도록 매우 노력합니다. 만약 버그를 찾았다고 주장한다면, 그것이 사실이라고 하더라도 그 개발자들 일부에 대한 공격이 될 수도 있고, 그들의 노력을 물거품으로 만드는 것입니다. 특히 제목 부분에 “버그"라고 소리치는 것은 현명하지 못합니다.

질문을 할 때는, 당신 스스로가 무언가 잘못했다고 적는 것이, 비록 속으로 진짜 버그를 찾았다고 꽤나 확신할지라도 현명할지도 모릅니다. 실제로 버그였다면, 답변에서 그와 관련해 소식을 들을 수 있습니다. 그런 식으로 행동하는 편이, 실제 버그가 있었을 때 관리자가 당신에게 사과하는 상황이 되며, 버그가 아니라서 당신이 관리자에게 사과해야 하는 상황이 되는 것보다 낫습니다.

굽신거리는 것은 숙제를 대신해주지 않는다

답변을 요구하는 사람 중에, 무례하거나 거만하게 행동해서는 안된다는 것을 이해하는 사람 중 일부는 오히려 후퇴하여 반대로 극단적인 굽신거리는 모습을 보입니다. “나도 내가 찐따 뉴비 루저라는 걸 알아요, 하지만…”. 이건 의미 없고 도움이 되지 않습니다. 이 모습은 특히 실제 문제에 대해 애매모호한 태도와 동시에 발생할 때 짜증을 유발합니다.

순전히 정치적인 목적으로 당신의 시간이나 혹은 우리의 시간을 낭비하지 마십시오. 차라리, 배경 상황이나 질문을 가능한 명확하게 드러내십시오. 그러는 쪽이 비굴한 것보다 나은 상황을 만듭니다.

가끔 웹 포럼은 초보 사용자 질문을 위한 별도의 공간을 제공합니다. 초보 사용자 질문이라고 느끼면 그 공간으로 가세요. 그렇다고 거기서 굽신거리라는 뜻은 아닙니다.

추측이 아니라, 문제의 증상을 묘사할 것

해커들에게 당신이 생각하는 문제의 원인을 알리는 것은 도움이 되지 않습니다. (만약 당신의 진단 이론이 그렇게 대단하다고 생각되면 왜 타인의 도움을 필요로 하나요?) 따라서, 무언가 정상적으로 작동하지 않는 증상의 있는 그대로를 말하고 있는지 확실시 하고, 당신의 해석이나 이론을 늘어놓지 마십시오. 해커들이 알아서 해석하고 진단하도록 내버려 두세요. 만일 당신의 추측이 주요하다고 느껴지면, 추측이라는 점을 명백히 명시하고 그 해답이 왜 작동하지 않는지 서술하십시오.

멍청함: 계속해서 커널 컴파일 과정에 SIG11 에러를 마주하는데 마더보드의 미세한 크랙이 원인인 것 같아요. 맞는지 확인하는 제일 좋은 방법이 뭐죠?

현명함: 집에서 빌드한 256MB 커세어 PC133 SDRAM + (Apollo VP2 칩셋을 가진) FIC-PA2007 마더보드의 K6/233머신이 커널 컴파일 과정에서 파워-온 이후 20분간 SIG11에러를 빈번하게 쏟아냅니다. 다만, 첫 20분 동안은 안그랬습니다. 재부팅은 클럭을 재시작하지 않는데, 밤사이 전원을 내려두는 것은 클럭 재시작을 유발합니다. RAM을 모두 바꾸는 것도 도움이 되지 않았습니다. 컴파일 세션과 일반적으로 연관있다고 여겨지는 로그 부분은 다음과 같습니다.

앞서 보여준 예시가 대부분의 사람들에게 잘 와닿지 않을 것으로 판단되기 때문에, 한 구절을 상기시켜 드립니다: “모든 진찰 전문의는 미주리 주 출신이다”. 미주리 주의 공식 모토는 “보여라"입니다. (1899년 유래, 하원 의원 Willard D. Vandiver가 “나는 옥수수, 목화, 우엉과 민주당원을 기르는 주에서 왔다. 의미 없는 허풍은 나를 설득시키지도 만족시키지도 못한다. 나는 미주리주 출신이다. 내게 실체를 직접 보여달라"고 함) 진찰 전문의에겐 시각적으로 즉각 확인할 수 있는 직접적 증거가 추측이나 요약보다 ‘확인할만한 가치가 있는 것’입니다. 그냥 보여주십시오.

문제의 증상을 시간 순서대로 묘사할 것

무언가 고장난 것을 해결하기 위해 가장 유용한 단서는 보통 바로 직전에 일어난 사건에 있습니다. 따라서, 부서지기 전에 당신이 무슨 짓을 했는지, 혹은 기계나 소프트웨어가 무슨 짓을 했는지 묘사하는 것이 당신 설명의 중점이 되어야 합니다. 커맨드 라인의 경우, 세션 로그(예를 들어, 스크립팅 유틸을 활용)나 20여 줄 정도의 관련 인용을 보이는 것이 유용합니다.

부서진 프로그램이 (예를 들어, 더욱 상세한 출력을 요구하는 -v와 같은) 진단에 쓰일 옵션을 가진다면, 기록을 위한 디버깅 자료에 추가될 수 있도록 그런 옵션을 선택하는 것을 시도하십시오. 하지만 많은 것이 반드시 더 좋은 것은 아님을 기억하십시오; 정보를 충분히 제공할 뿐, 읽는 이를 쓰레기더미에 질식시키지 않을 수준의 디버그 레벨을 잘 선택하기 바랍니다.

설명이 (대략 4개 문단을 넘어서) 매우 길어진다면, 차라리 문제를 가장 상단에 명시하고, 시간 순서대로 있었던 일들은 그 아래에 나열하는 것이 도움이 됩니다. 그런 경우엔, 해커들이 당신의 설명을 읽으며 무엇을 찾아야 할지 알 수 있습니다.

단계가 아니라 목적을 설명할 것

만약 당신이 (버그를 신고하는 것과 다르게) 어떤 것을 하는 방법을 찾고자 시도중이라면, 그 목적을 묘사하는 것으로부터 출발하십시오. 그래야만 당신이 가로막힌 곳으로부터 목적으로 가는 길을 단계별로 설명할 수 있습니다.

기술적 도움을 필요로 하는 사람들은 자주 더 상위 수준의 목표를 마음에 가지고 있고 그 목표를 향한 단 하나만의 특정한 경로가 있다고 생각합니다. 그 경로에 대해 도움을 구하러 오지만, 경로가 틀렸을거란 생각은 하지 못합니다. 이것을 해결하기 위해 상당한 노력을 필요로 합니다.

멍청함: 아무개 그림판 프로그램에서 16진수 RGB 값을 얻기 위해 색 선택기를 어디서 찾을 수 있나요?

현명함: 이미지의 컬러 표에서 원하는 색상으로 색을 교체하려고 시도중입니다. 현재로서 제가 생각할 수 있는 유일한 방법은 각 표의 칸을 수정하는 것이지만 아무개 그림판에서 16진수 RGB 값을 얻기 위한 색 선택기를 찾을 수가 없네요.

두 번째 버전의 질문이 더 똑똑한 것입니다. 임무를 수행하기 위한 더 좋은 도구를 제안할 수 있도록 하기 때문입니다.

개인 이메일로 회신을 요구하지 말 것

해커들은 ‘문제 해결이란 앞서 달린 답변이 불완전하거나 부정확하다는 것을 더 전문가인 뒷 사람이 알아차린 경우엔 수정할 수도 있고, 수정해야만 하는 공개적이고 투명한 과정’으로 믿습니다. 또한, 도운 사람들은 그의 동료들에게 유능하고 박식한 것으로 보여졌다는 점에서 답변 행위의 보상을 얻습니다.

개인 회신의 요청은, 과정과 보상을 모두 망치는 것입니다. 하지 마십시오. 사적으로 회신할 것인지의 선택은 응답자의 몫입니다 - 그리고 답변자가 만약 그렇게 하기로 했다면, 본인이 보기에 다른 사람이 흥미를 느끼기에는 너무도 당연한 것이거나 질문의 형식 자체가 틀렸기 때문일 것입니다.

이 규칙엔 한 가지의 예외가 있습니다. 본인이 생각하기에 질문이 서로 유사한 답변을 너무나 많이 받을 것으로 생각되는 경우, “이메일 주시면 그룹을 위해 제가 답변들을 요약하겠습니다"라는 마법의 단어들을 추가하면 됩니다. 메일링 리스트나 뉴스 그룹을 동일한 포스팅의 엄청난 양의 홍수로부터 구하려는 시도는 공손한 것입니다 - 하지만 요약하겠다는 약속은 반드시 지켜야 합니다.

질문을 명확히 밝힐 것

열린 질문은 보통 끝이 없는 시간 낭비로 여겨집니다. 당신에게 답을 줄 수 있을 것으로 여겨지는 사람들도 대개 (그 사람들도 생업이 있기 때문에) 엄청나게 바쁜 사람들입니다. 그런 사람들은 끝없는 시간 낭비에 알레르기 반응을 일으키기 때문에 마찬가지로 열린 질문에도 알레르기 반응을 보입니다.

당신이 응답자들에게 원하는 것(링크 제공, 소스 코드 제공, 패치 확인 등 뭐든지)에 대해서 분명히 밝힌다면 유용한 대답을 확보할 가능성이 큽니다. 이는 당신을 돕기 위해 응답자들이 가용한 최대 범위의 시간과 노력을 기울이게 합니다. 좋은 일이죠.

전문가들이 사는 세상을 이해하고자 한다면, 아주 사소한 것에 응답하기 위한 엄청난 양의 자료와 시간을 필요로 하는 전문 분야를 생각해보세요. 당신이 구하고자 하는 헌신의 양이 적을수록, 굉장히 바쁜 사람들로부터 양질의 답을 구할 확률이 더 높아집니다.

따라서 해당 분야 전문가에게 필요로 될 시간 소모를 줄이도록 질문을 다듬는 것이 유용합니다 - 그러나 이건 꼭, 질문을 ‘단순화’하라는 것과 같은 의미는 아닙니다. 결국은, 예를 들자면, “X를 이해하기 위해 유용한 링크를 알려줄 수 있나요?“라는 질문이 “X좀 설명해줄래요?“보다 현명한 질문입니다. 정상 작동하지 않는 소스 코드가 있다면, 누군가 어디가 틀린 것 같은지 묻는 것이 고쳐 달라고 하는 것보다 보통 현명한 질문이 될 것입니다.

코드에 대해 질문할 때

어떤 문제에 관해 이상이 있는지에 대한 힌트도 없이 당신이 만든 고장난 소스코드를 디버깅해달라고 요구하지 마십시오. 수백 줄의 소스 코드를 업로드하고선 “작동이 안되요"라고 떠드는 것은 무시당할겁니다. 열댓 줄의 소스 코드를 업로드한 후, “7번째 줄 이후 를 기대하고 있습니다만, 가 발생하는데요"라고 질문하는 것이 대답을 들을 확률을 높여줍니다.

코드 문제에 관해 상세히 질문할 수 있는 가장 효과적인 방법은 버그임을 보여주는 최소한의 테스트 케이스를 제공하는 것 입니다. 최소한의 테스트 케이스란 무엇을 의미할까요? 이는 문제 상황 묘사를 뜻합니다; 딱 원치 않는 행동을 드러내기 위해 충분할 정도면 됩니다. 어떻게 최소 테스트 케이스를 만들까요? 코드의 어느 줄이나 섹션이 문제의 행동을 생성하는지 알고 있다면, 그 부분을 복사한 후 완벽한 예시가 될 수 있도록 보충 부분을 추가합니다. (예를 들어, 코드 처리를 위한 컴파일러/인터프리터/뭐든간에 작동할 정도면 됩니다.) 만약 특정 섹션을 지목할 수 없는 상황이라면, 소스 코드의 복사본을 만든 후 문제 행동을 생성하는데 영향을 주지 않는 부분을 제거해나갑니다. 최소 테스트 케이스가 작을수록, 좋습니다. (“양은 정확도가 아니다"부분을 참고하세요)

아주 작은 최소 테스트 케이스를 만드는 것이 항상 가능한 일은 아니지만, 그렇게 하고자 시도하는 것은 아주 좋은 훈련이 됩니다. 간혹 스스로 문제를 해결하는 방법을 찾게 도와주기도 하고 - 그렇지 않더라도 해커들은 뭔가 시도했다는 점을 확인할 수 있어서 좋습니다. 해커들이 더 협력적일 수 있도록 만들죠.

만약 단순히 코드 리뷰를 원하는 것이라면, 미리, 리뷰가 필요한 특정 부분과 왜 필요한지를 명확히 명시하시기 바랍니다.

숙제 문제를 올리지 말 것

해커들은 숙제 문제를 아주 잘 찾아냅니다; 대부분이 이미 풀어본 것이기 때문이죠. 그런 문제들은 당신이 경험으로부터 학습할 수 있도록, 당신이 직접 풀라고 만든 것입니다. 힌트를 구하는 것은 좋지만, 전체 해답은 안됩니다.

숙제는 통과할 것으로 예상되지만, 어쨌든 풀지 못했을 때는, 유저 그룹 포럼이나 (최후의 수단으로) 프로젝트의 “사용자” 리스트/포럼에 도움을 구하시기 바랍니다. 해커들은 알아차리겠지만, 숙련된 사용자들이 최소한 힌트를 제공할 겁니다.

의미 없는 질문을 제거할 것

“누구든 절 도와줄 수 있나요?“라든지 “정답이 있나요?“와 같은 구문상 아무 의미 없는 질문으로 요청을 마무리하고 싶은 욕망을 참으십시오. 우선: 문제 서술을 절반정도만 완벽히 했다면, 그런 추가 질문은 헛소리에 불과합니다. 둘째: 헛소리이기 때문에 해커들은 성가시다고 여깁니다 - “네, 도움 받을 수 있습니다"라든지 “아니요, 여기선 당신을 도울 사람이 없네요"같이 별 달리 분쟁을 일으키진 않지만 무시하는 듯한 답변을 받을 겁니다.

일반적으로, 예-아니오 대답을 듣고자 하는 것이 아니라면, 그런 질문을 피하는 것을 권장합니다..

아무리 본인에게 긴급하더라도, “긴급"등의 라벨을 붙이지 말 것

당신 문제지, 우리 문제가 아닙니다. 긴급하다고 주장하는 것은 역효과를 일으킬 확률이 높습니다: 대부분의 해커들은 그런 메시지를 즉각적이고 특별한 관심을 이끌어내려는 이기적이고 무례한 시도로 판단해 삭제하고 말 것입니다. 더욱이, ‘긴급’(이나 유사한 주의를 끄는 단어가 제목에 배치되면)은 거의 스팸 필터에 걸립니다 - 대답해주길 기대한 사람들은 정작 아예 못 볼지도 모릅니다!

한 가지 준-예외가 있습니다. 해커들이 흥분할만큼 세간을 끄는 곳에서 프로그래밍을 사용하는 경우라면 언급할 가치가 있겠습니다; 그런 경우라면, 시간이 얼마 남지 않았음을 정중하게 표현한다면, 사람들이 더 급하게 답을 해줄만한 이목을 끌 수 있습니다.

그러나, 해커들의 관심도는 당신이 생각하는 것과 다를 확률이 크기 때문에, 이는 매우 위험한 행동입니다. 예를 들어, 국제 우주 정거장에서 글을 쓰는 것은 해당하겠으나, 자선 단체나 정치적 이유로 쓰는 것은 확실히 해당하지 않겠죠. 사실, “긴급: 아기 물개를 살리는데 도움을 주세요"는 아기 물개가 중요하다고 생각하는 해커들로부터 생각지도 못한 뜨거운 관심을 받을 수도 있죠.

이게 혼란스럽다면, 이 방법론 파트를 글을 올리기 전에 몇 번이고 반복해서 다시 읽기를 권합니다.

공손함은 해치지 않는다, 간혹 도움이 된다

예의를 갖추세요. “부탁드립니다” 라든지 “관심을 보여주셔서 감사합니다” 혹은 “해결해주셔서 감사합니다"를 사용하시기 바랍니다. 무료로 당신을 돕고자 다른 사람들이 시간을 썼다는 점에 감사하고 있음을 명확히 보이세요.

솔직히 말하자면, 이는 문법이 올바르고, 명확하고, 정밀하고 충분히 설명하고, 사적 포맷(proprietary format)을 사용하지 않는 것보다 중요하지 않습니다. (그리고 대체되지도 않습니다.); 일반적으로 해커들은 허무맹랑한 예의차림 보다는 차라리 무뚝뚝하지만 기술적으로 아주 날카로운 버그 리포트를 선호합니다. (이게 혼란스럽다면, 우린 우리 스스로가 뭔가 배울 것이 있는 질문에 가치를 둔다는 점을 기억하기 바랍니다.)

그러나, 만약 기술적 해결이 필요한 질문이 연속으로 필요하다면, 정중함은 유용한 답변을 받을 확률을 증가시킨다는 점은 확실합니다.

(이 방법론(HOWTO)과 관련해 베테랑 해커들로부터 받은 진지한 반대 의견은 “앞서 감사드립니다(Thanks in advance)“에 대한 이 글의 추천에 관한 것임을 밝힙니다. 일부 해커들은 이 표현을, 문제가 해결된 이후로는 감사하지 않음을 암시하는 것으로 받아들입니다. 저희의 권고는 “앞서 감사드립니다"를 먼저 밝히면서 뿐만 아니라, 예를 들자면, “관심 보여주셔서 감사드립니다"라든지 “해결해주셔서 감사합니다"와 같이 다른 방법으로도 감사함을 표하는 것입니다.)

해결책에 대한 간단한 노트를 남길 것

문제가 해결되고 난 뒤에는 도움을 준 사람들에게 노트를 남기세요; 어떻게 진행되었고 그들의 도움에 감사하다는 점을 다시금 상기시켜 주시기 바랍니다. 메일링 리스트나 뉴스 그룹에서 다수의 관심을 받은 문제였다면, 결과 보고성 포스트를 그 곳에 남기는 것이 적절합니다.

이상적인 모습은 원래의 질문을 시작했던 포스트에 답변으로써, ‘고침(FIXED)‘나 ‘해결함(RESOLVED)’ 또는, 비슷한 수준으로 명확한 태그를 제목에 붙이는 것입니다. 굉장히 답신이 많은 메일링 리스트에서는, “문제 X"로 시작해서 “문제 X-해결됨"으로 끝나는 쓰레드는 보자마자 (본인 스스로가 문제 X에 관심이 있는 경우를 제외하고서는) 시간을 낭비할 필요가 없음을 알 수 있어서, 그 시간을 다른 문제 해결에 사용할 수 있게 됩니다.

결과 보고성 포스트는 길고 복잡할 필요가 없습니다; 단순히 “잘 지내셨나요 - 그냥 네트워크 선 고장이었어요! 고마워요, 다들! - 빌” 정도면 없는 것보다는 낫습니다. 사실, 실제로 기술적으로 의미 있는 경우를 제외하고서는 긴 논문 같은 답변보다 짧고 달달한 요약이 더 좋습니다. 문제 해결 과정을 다시 되풀이 나열할 필요 없이 어떤 방법으로 해결할 수 있었는지만 밝히세요.

꽤 깊이 있는 문제의 경우에는 문제 해결 기록의 요약을 남기는 것이 적합합니다. 마지막 문제점을 명시하세요. 어떤 방법이 해결책이었는지 서술하고 그 이후에 해서는 안되는 사항을 명시하기 바랍니다. 결과 보고성 포스트를 수사물로 만들지 않기 위해, 해서는 안되는 행동인 막다른 행동에 대한 글은 올바른 해결책 부분과 다른 요약 부분 뒤에 배치하기 바랍니다. 도움을 준 이들의 이름을 밝히세요; 그렇게 서로 친구가 될 수 있습니다.

감사 표시와 정보 제공 측면을 제외하고서도, 이런 종류의 결과 보고성 포스트는 메일링 리스트/뉴스그룹/포럼에서 해당 문제를 검색하는 다른 사람들이 정확히 어떤 해결책으로 도움을 받았는지 정확히 파악할 수 있게 함으로써 그들에게도 도움이 됩니다.

마지막으로 중요한 점은, 이런 결과 보고성 포스트는 문제 해결을 도왔던 사람들 모두에게 문제가 잘 마감되는 만족스러운 기분을 느끼게 해줍니다. 만약 당신 스스로가 기술자나 해커가 아니라면, 이런 기분이 당신이 도움을 위해 노크당한 전문가나 고수들에게 매우 중요하다는 우리 말을 믿으세요. 문제가 해결되지 않고 허무하게 남아있는 흔적을 바라보는 것은 실망스러운 일입니다; 해커들은 그게 해결되는 모습을 보고싶어 몸이 간질거립니다. 그 간지러움을 긁어주는 선의는 다음에 혹시 질문을 할 필요가 있을 때 해커들이 성심성의껏 도와주리라는 것을 의미합니다.

미래에 같은 질문을 다른 사람들이 하는 것을 예방하기 위해 무엇을 할 수 있는지도 고려하십시오. 문서나 FAQ에 패치하는 것이 도움이 될지 자문해보고, 도움이 될 것으로 보인다면 관리자에게 패치를 발송하기 바랍니다.

해커들 사이엔 이런 결과 보고성 포스팅이 통상적인 정중함보다 더 중요한 행동으로 여겨집니다. 이는 매우 귀중한 자산이라고 할 수 있는 타인과 잘 지내는 사람이라는 명성을 얻게 해줍니다.

답변 해석하는 방법

RTFM과 STFW: 제대로 말아먹었음을 구분하는 방법

아주 오래 전부터 내려오는 전통이 있습니다; 답변에 “RTFM"이라고 적혀있다면, 답변한 사람은 당신이 ‘X발 매뉴얼 좀 읽어(‘Read The Fucking Manual’)라고 생각하는 것입니다. 답변자가 분명히 맞습니다. 가서 읽고 오세요.

RTFM은 어린 사촌이 있습니다. 답변에 “STFW"이라고 적혀있다면, 답변한 사람은 당신이 ‘X발 인터넷 검색 좀 해봐라(‘Search The Fucking Web’)고 생각하는 것입니다. 답변자가 분명히 맞습니다. 가서 검색하고 오세요. (이것의 부드러운 버전은 “구글은 친구야!(Google is your friend!")입니다.)

웹 포럼의 경우에는 포럼 보관소를 검색하라는 말을 들을 수도 있습니다. 사실, 몇몇 사람은 기존에 같은 문제가 해결된 쓰레드의 링크를 제공할만큼 친절할지도 모릅니다. 하지만 이런 배려에 의존하지 마십시오; 묻기 전에 스스로 보관소-검색을 하시기 바랍니다.

꽤 자주, 매뉴얼 읽으라고 하거나 인터넷 검색하라고 답변하는 그 사람들이 해당 답변을 입력하면서 당신이 필요로 하는 정보가 담긴 해당 매뉴얼이나 웹페이지를 열어둔 경우가 많습니다. 이런 답변은 따라서 (a) 당신이 필요로 하는 정보가 너무 찾기 쉽거나, (b) 이 정보를 떠 먹이기 보다는, 스스로 찾는 과정에서 당신이 더 배울게 많다는 점을 의미합니다.

이런 점에 상처 받지 마십시오; 해커들 기준에서는 당신의 응답자는 최소한 무시하지 않은 만큼, 나름대로의 존중을 보인 것입니다.당신은 오히려 이런 할머니 스타일의 친절함에 감사함을 느껴야 합니다.

이해가 안되면

답변이 이해가 안된다고 곧바로 더 명확히 알려달라고 요구하지 마십시오. 평소에 시도하던 동일한 방법들을 통하여 원래의 질문에 (매뉴얼, FAQ, 인터넷, 숙련된 친구 등) 답변을 이해하기 위해 스스로 답해보시기 바랍니다. 그리고 나서도 더 명확해야 할 필요가 있다면 그 과정에서 추가로 배운 것을 보여주시기 바랍니다.

예를 들어, 이렇게 말해주었다고 합시다: “젠트리에서 막힌 것 같은데; 뚫어봐”. 그리고, 이것이 나쁜 추가 질문입니다: “젠트리가 뭐임?”. 다음은 앞의 것 보다는좋은 추가 질문입니다: “ㅇㅋ, 매뉴얼 패이지 읽어봤는데 젠트리는 -z랑 -p 스위치 관해서만 언급되고 있어. 어디에도 젠투리 뚫는것 관련해서는 얘기가 없는데. 쟤네 중에 하나 말한거임 아님 내가 뭔가 빼먹은거임?”.

무례함 다루기

해커 문화에서 무례한 것으로 보여지는 것들은 상처 주기 위한 의도가 아닙니다. 그보다는, 상대를 따듯하게 만드는 것보다 문제 해결에 더 관심이 있는 사람들에겐 자연스러운, 직접적이고, 헛소리는 집어치우는(cut-through-the-bullshit) 대화 방식에 의한 부산물입니다.

무례한 대응을 받으면, 침착하게 반응하려고 애쓰세요. 만약 누가 정말로 과하게 행동하면, 해당 리스트 뉴스 그룹에서 고위급의 사람이 그/그녀를 나무랄 것입니다. 만약 그런 일이 벌어지지 않고, 당신이 화를 낸다면, 당신이 화내고 있는 대상이 해커 커뮤니티의 규범에 맞게 행동한 것이고 당신이 틀렸다고 판단될 것입니다. 이는 당신이 원하는 도움을 받을 기회에 악영향을 미칩니다.

반면에, 가끔은 무례함을 마주하여 신경 쓰지 않는 태도를 보일 수도 있습니다. 이 태도의 장점은, 실제 범죄자를 강하게 반격하고 날카로운 도구로 그들의 틀린 행동을 해부해버릴 수 있다는 점입니다. 그러나, 이런 자세를 취하기 전에 본인 입장을 아주 아주 명확히 인지하기 바랍니다. 무례함을 바로잡는 것과 의미 없는 불꽃 전쟁 사이의 선은 매우 얇고 해커들은 그 선을 자주 넘지 않는 편입니다; 만약 당신이 초보자이며 외부인이라면, 그 선 넘은 수준을 알아차리기란 쉽지 않습니다. 당신이 흥미거리가 아니라 정보를 쫓는 거라면, 이런 위험을 감수하기보다는 차라리 키보드에서 손가락을 떼는 것이 좋습니다.

(일부 사람들은 다수의 해커들이 약한 수준의 자폐 혹은 아스퍼거 증후군을 겪고 있어서 “정상적인” 사람들의 사회적 교류의 뇌 일부가 정상 작동하지 않는 것 같다고 주장합니다. 이는 사실일수도, 아닐 수도 있습니다. 만약 당신이 스스로 해커가 아니라면, 우리의 태도를 뇌 다친 환자의 행위로 여기면 좀 편할지도 모릅니다. 그렇게 하세요. 우린 관심 없습니다; 우린 우리답기를 좋아하고, 의학적 라벨링에는 일반적으로 건강한 비판을 가지고 있습니다.)

눈치 필터에 관한 제프 비글러(Jeff Bigler)의 관찰도 관련 있을 뿐더러 읽어볼 가치가 있습니다.

다음 섹션에서는 다른 이슈에 대해 말하고자 합니다; 당신이 잘못 행동 했을 때 겪게 될 다양한 “무례함"에 관해서 다루겠습니다.

루저처럼 반응하지 않기에 대하여

여기서 상세히 밝힐 방법, 혹은 유사한 방법으로 - 당신이 몇 번이고 해커 커뮤니티 포럼에서 말아먹을 확률이 높습니다. 그리고 아주 다양한 방법으로 어떻게 말아먹었는지 전해듣겠죠. 공개적으로요.

이런 일을 겪고 당신이 취할 최악의 대처는 해당 경험에 대해 징징거리거나, 모욕을 당했다고 주장하거나, 사과를 요구하거나, 소리지르거나, 숨을 참거나, 고소할거라고 위협하거나, 다른 고용인에게 불평을 하거나, 변기 커버를 올려놓은 채 떠나거나, 등등입니다. 자 당신이 할일을 보여드리죠:

그냥 넘어가요. 정상입니다. 사실, 건강하고 적절한 겁니다.

커뮤니티의 기준은 기준 스스로 관리되는 것이 아닙니다: 기준은 공개적으로, 그리고 가시 범위에서 그 기준을 능동적으로 적용하는 사람들에 의해 관리됩니다. 모든 비난은 사적인 이메일로 이루어져야만 한다고 징징대지 마세요: 이제 그런식으로 하지 않습니다. 당신의 주장이 틀렸다거나 누군가가 당신과 다르게 생각한다는 댓글을 달았다고 개인적으로 모욕을 당했다고 주장하는 것도 도움이 되지 않습니다. 그게 바로 루저의 태도예요.

초-긍정적이고, 타인의 포스트에서 실수를 지적하는 포스팅은 금지되며 “돕지 않을거면 아무말도 하지 마라"를 권장하는 포럼이 있었습니다. 이것은 실제로 도움을 줄 수 있는 참여자들이 다른 곳으로 떠나는 결과를 낳았고 의미 없는 다독임만 남게 되어 결국 기술 포럼으로써 무용지물이 되었죠.

(그런 의미의) 과장된 “친근함”, 혹은 “유용함”: 하나만 고르세요.

기억하기 바랍니다: 해커가 당신이 말아 먹었다고 말하고 (얼마나 무뚝뚝 했든지간에) 그러지 말라고 하면, (1) 당신과 (2) 커뮤니티를 위한 걱정에서 하는 말입니다. 해당 답변자한테도 마찬가지로 무시하고 본인의 삶을 위해 당신을 필터링하는 편이 훨씬 쉬운 방법입니다. 그런 면에서 감사할 줄도 모르면, 최소한의 존엄이라도 가지고 징징대지 마세요. 그리고 무슨 자격이 있는 마냥 망상에 빠진, 과장된 초예민 영혼을 가진, 신입이라는 이유로 부서지기 쉬운 인형처럼 대해 주기를 기대하지 마십시오.

간혹 사람들은 당신이 말아먹지 않았음에도 (혹은 그들의 상상 속에서나 말아먹었는데도) 별다른 이유도 없이 불타오르거나 개인적으로 공격하는 일이 있습니다. 이 경우에는, 불평하는 것이 실제로 말아 먹는 방법입니다.

이런 분탕종자들은 실제로는 해결법도 없으면서 전문가인체하는 사람들이거나 당신이 말아먹는지 아닌지 실험하는 심리학자들일 겁니다. 다른 독자들은 그런 사람들을 무시하거나, 혹은 알아서 그런 사람들을 다루는 법을 찾을 겁니다. 분탕종자는 스스로를 향한 문제나 만들 뿐이지, 당신이 걱정할 필요는 없습니다.

함께 불꽃 전쟁에 휘말리지 않도록 주의하세요. 대부분의 불꽃 전쟁은 무시하는 게 최선입니다 - 다만, 진짜 불꽃 전쟁인지, 말아 먹은 이유에 대한 링크는 아닌지, 혹은 (간혹 실제로 일어나지만) 아주 교묘하게 숨겨진 당신 질문에 대한 진정한 답변인지를 확인하고 나서요.

묻지 말아야 하는 질문

여기 고전적인 멍청한 질문들과 해커들이 무시할 때 속으로 생각하는 것을 소개합니다.

Q: X 프로그램 혹은 X 자료는 어디에서 구할 수 있나요?

A: 내가 찾은 데랑 같은데서, 임마 - 검색! 하나님, 아직도 사람들은 구글 사용법을 모르나요?

Q: Y하려면 X 어떻게 써야 하나요?

A: Y를 하고 싶은 거라면, 부적절할지도 모르는 방법을 미리 전제하고 물어서는 안됨. 이런 형태의 질문들은 보통 프로그램 X에 대해 완전히 무지하거나, 풀고자 하는 Y 문제에 대해 혼란스러운 경우, 그리고 특정 상황의 세부 사항에 너무 집중한 경우에 일어남. 본인 문제를 더 명확하게 설명하기 전까진 그냥 무시하는 게 최선임.

Q: 쉘 프롬프트는 어떻게 설정하나요?

A: 이 질문 올릴 수 있는 지능이면 RTFM 하고 직접 찾을 듯.

Q: AcmeCorp 문서를 Bass-o-matic 파일 변환기를 활용해 TeX 파일로 변환할 수 있나요?

A: 해보세요. 되면, (a) 답을 찾은거고, (b) 내 시간낭비좀 그만하세요.

Q: 내 {프로그램, 설정, SQL 명령어} 가 작동을 안함.

A: 이건 질문도 아니고, 해야 할 더 중요한 일들이 있어서 - 실제 질문을 찾기 위한 스무고개 하고 싶지도 않음. 이런 걸 목격하면, 내 반응은 보통 다음 중 하나임: 더 추가할 건 없음? 아 안됐네, 빨리 고쳐지길 빌게. 그리고 이게 나랑 정확히 무슨 상관임?

Q: 제 윈도우 PC에 이상이 있어요. 도와주실 수 있나요?

A: 넹. 마이크로소프트는 갖다 버리고 Linux나 BSD같은 오픈 소스 운영체제를 설치하세요. 주의: 공식적으로 윈도우 빌드를 지원하는 프로그램이나 윈도우 PC와 상호작용 해야하는 (예를 들어, Samba처럼) 프로그램에 대한 질문이라면 물어볼 수는 있습니다. 다만 문제가 프로그램이 아니라 윈도우라는 답변에 놀라지 마십시오. 윈도우는 고장나기 매우 쉽고 대부분의 경우에 고장난게 이유이기 때문입니다.

Q: 제 프로그램이 작동하지 않아요. 제 생각엔 시스템 기능 중 X가 고장난 것 같아요.

A: 수백 수천명이 사용하는 시스템의 라이브러리나 시스템 콜의 확실한 결점을 발견한 첫 번째 사람이 당신일 가능성이 분명 존재하긴 하지만, 차라리 무슨 소리 하고 있는지 모를 확률이 더 높습니다. 대단한 주장에는 대단한 증거를 필요로 합니다; 이런 주장을 할 거라면, 분명하고 확실히 명시된 실패 케이스를 근거로 제시해야만 할 것입니다.

Q: Linux 혹은 X를 설치하는데 문제가 있어요. 도와주실 수 있나요?

A: 아니요. 그거 해결하려면 기기에 직접 접속할 수 있어야 합니다. 지역 리눅스 사용자 모임에 가서 직접적인 도움을 요청하기 바랍니다. (여기에서 사용자 모임 리스트를 확인할 수 있습니다. [역자 주: 현재 접속 불가]) 주의: 리눅스 설치에 관한 질문은 해당 배포판 메일링 리스트나 포럼, 혹은 지역 사용자 모임 포럼에선 적절할지도 모릅니다. 그리고 문제는 해당 배포판입니다; 이러한 경우, 문제의 정확한 상세 정보를 서술하고 있는지 명확히 하기 바랍니다. 다만, 질문에 앞서서 “리눅스"와 모든 의심스러운 하드웨어를 포함하는 검색을 하기 바랍니다.

Q: 관리자 계정/채널 관리자 권한 훔치기/타인 이메일 훔쳐일기는 어떻게 하나요?

A: 그런 짓을 하고싶을만큼 후진 삶을 살고 해커들한테 그런거 도와달라고 할만큼 멍청한 사람

좋은 질문과 나쁜 질문

마지막으로, 예시를 통해 현명한 질문을 하는 방법을 보여드리겠습니다; 같은 문제에 대한 멍청한 방법 하나와 똑똑한 방법 하나로 구성되어 있습니다.

멍청함: Foonly Flurbamatic 제품은 어디서 찾을 수 있나요? 이 질문은 답신으로 “STFW”만이 달릴 것입니다.

현명함: “Foonly Flurbamatic 2600” 검색을 구글을 활용해 시도했는데, 유용한 결과가 없습니다. 이 기기에 대한 프로그래밍 정보를 얻기 위한 링크를 구할 수 있을까요? 이 질문은 이미 인터넷 검색을 해보았고 진짜 문제가 있는 것처럼 들립니다.

멍청함: foo 프로젝트의 코드가 컴파일되지 않습니다. 왜 고장났나요? 의뢰인은 타인이 말아 먹었음을 전제로 하고 있습니다. 거만한 놈…

현명함: Nulix version 6.2에서 foo 프로젝트 코드가 컴파일되지 않습니다. FAQ를 확인했지만, Nulix 시스템 관련된 문제는 보고되어 있지 않습니다. 아래는 컴파일 시도 관련된 로그입니다; 제가 잘못한 부분이 어디일까요? 이 의뢰인은 작업 환경 명시, FAQ 확인, 에러 명시, 자신의 잘못으로 전제를 모두 만족합니다. 이 질문은 주목을 받을 가치가 있어보입니다.

멍청함: 제 메인보드에 문제가 있습니다. 아무나 도와주실 수 있나요? 김 아무개씨가 받을 것으로 예상되는 답변은 “좋아. 혹시 트림이랑 기저귀 교체도 도와줄까?“이며 뒤이어 딜리트 키 연타가 이어집니다.

현명함: S2464 메인보드에서 이미 X, Y 그리고 Z까지 시도했습니다. 그래도 안되서, A, B 그리고 C도 시도하였습니다. C를 시도했을 때 발생한 흥미로운 증상도 참고해주세요. 분명히 일부 부품이 깜빡이지만, 결과는 예상과 다릅니다. 애슬론 MP 메인보드의 깜빡임 증상의 일반적인 원인은 무엇인가요? 문제 해결을 위해 시도해볼 다양한 테스트 아이디어를 아무나 제공해주실 수 있나요? 반면에, 이 사람은답변할 가치가 있어 보입니다. 그/그녀는 답변이 하늘로부터 떨어지기를 수동적으로 기다리는 것이 아니라, 문제-해결 지식을 보였습니다.

마지막 질문과 관련해서, “답변을 주세요"의 요구와 “번뜩이는 해답을 얻기 위해 필요한 추가적인 진단 방법을 찾게 도와주세요” 사이의 미묘하지만 주요한 차이를 알차리시길 바랍니다.

사실, 마지막 질문의 형태는 2001년 8월 리눅스-커널 메일링 리스트(lkml)에서 있었던 사건을 거의 그대로 반영합니다. 나(에릭)은 질문했던 당사자입니다. 나는 S2462 메인보드에서 미스테리한 락업을 목격했습니다. 리스트 멤버들은 그 문제를 해결하기 위해 필요한 주요한 정보를 제공하였습니다.

보여드린 방식으로 질문을 함으로써, 사람들에게 생각할거리를 제공하였습니다; 관심 갖고 참여하기에 매력적이고 쉬워 보이게 만든 것이죠. 동료들의 능력을 존경함을 보이고 동료로써 문제 해결 상담에 초대하였습니다. 이미 시도하였으나 막다른 골목이었던 항목을 말해줌으로써 그들의 시간의 가치를 존중한다는 점도 추가로 드러냈습니다.

결국, 모두에게 감사함을 표하고 문제가 얼마나 잘 해결되었는지 표현하자, 한 lkml 멤버는 해당 문제가 리스트의 “유명인"이 질문했기 때문이 아니라, 해당 질문을 구성한 양식이 좋았기 때문에 도움을 받은 것으로 생각했습니다.

해커들은 어떤 면에선 자비 없이 능력주의입니다; 그가 맞았음을 확신합니다. 만약 제가 스폰지처럼 행동했다면 제가 누구인지와 관계없이 무시 당하거나 질문이 불타올랐을 겁니다. 이 일련의 사건을 다른 사람들을 위한 설명으로써 작성하는 것이 어떠냐하는 그의 제안에 이 가이드가 구성되었습니다.

답을 구할 수 없다면

답을 구할 수 없다면, 우리가 당신을 돕지 않는다고 감정적으로 받아들이지 마십시오. 가끔은 질문 받은 그룹의 멤버들이 답을 모를 때도 있습니다. 무반응이 무시당하는 것과 동일하지 않습니다. 물론 외부에서 보기에 그 차이를 구분하기는 어렵지만 말이죠.

일반적으로, 단순히 질문을 재포스팅하는 것은 안좋은 생각입니다. 이는 의미없이 짜증나는 일로 보입니다. 참을성을 가지세요: 답변을 해줄만한 사람이 다른 시간대에 살고 있어서 취침중일지도 모릅니다. 아니면 애초에 당신의 질문이 잘 구성되어 있지 않을지도 모릅니다.

도움을 요청할 다른 곳이 있을지도 모릅니다, 간혹 초심자의 필요에 더 잘 맞는 곳이 있을 때가 있습니다.

세상엔 소프트웨어를 스스로 만들어본적이 없음에도 불구하고, 소프트웨어의 열정적인 팬이 구성하는 온라인이나 지역 사용자 그룹이 많습니다. 이런 그룹은 서로를 돕고 새로운 사용자를 돕는 방향으로 구성되어 있을 때가 많습니다.

크든 작든 도움을 위해 계약할 수 있는 상업 회사도 상당히 많습니다. 일정 도움을 받기 위해 비용을 지불해야 한다는 생각에 언짢아하지 마십시오. 결국, 자동차 엔진의 헤드 가스켓이 고장나면, 아마도 정비소에 가서 고치기 위한 비용을 지불할 것임을 매한가지입니다. 비록 소프트웨어가 어떤 비용 지출도 유발하지 않았더라도, 지원조차 항상 무료로 제공될거라는 기대는 하지 마십시오.

리눅스처럼 인기있는 소프트웨어의 경우 개발자당 10,000명의 사용자가 있습니다. 각 개발자가 10,000명의 사용자의 지원 문의를 처리하는 것은 불가능합니다. 지원을 위해 비용을 지불하게되더라도, 소프트웨어까지 구매하기 위해 지출해야 하는 것에 비하면 적은 양이라는 점을 반드시 기억하기 바랍니다. (그리고 비공개 소프트웨어 지원은 오픈 소스 소프트웨어 지원에 비해 불완전하면서도 훨씬 비쌉니다.)

도움이 되는 방향으로 질문에 답하는 방법

친절하세요. 문제와 관련된 스트레스는 그들이 실제로 아니더라도 사람을 무례하거나 멍청하게 보이게 합니다.

초범에게의 회신은 오프라인으로. 누군가 솔직한 실수를 했다고 해서 공개적인 망신을 줄 필요는 없습니다. 진정한 초보자는 문서 보관에서 어떻게 검색해야 하는지, 어디에 FAQ가 있는지 모를지도 모릅니다.

확실하지 않으면, 그렇다고 하십시오! 틀렸으면서 권위주의적으로 들리는 답변은 안하느니만 못합니다. 단지 전문가처럼 보이는게 재미있어서 누군가를 틀린 방향으로 안내하지 마십시오. 겸손하고 솔직하십시오; 요청자와 동료 모두에게 선례를 남기시기 바랍니다.

돕지 못할거면 방해하지 마십시오. 사용자의 설정을 쓰레기로 만들 수도 있는 농담을 하지 마십시오. - 불쌍한 초보자는 당신의 농담을 지시사항으로 해석할 수도 있습니다.

더 상세한 정보를 이끌어내기 위해 추가 질문을 하십시오. 이 것을 잘해내면, 질문자는 무언가를 배울 수 있습니다. - 당신도 마찬가지입니다. 안 좋은 질문을 좋은 것으로 바꾸도록 시도해 보십시오; 우리도 한 때는 초보였다는 것을 기억하기 바랍니다.

RTFM을 외치는 것이 때때로 게으름벵이에게 답변한다는 핑계로 정당화되지만, 문서 링크(심지어 구글에 검색할 키워드 제안이라도)가 훨씬 낫습니다.

어쨋든 물음에 답할거라면, 좋은 답변을 주십시오. 누군가 안좋은 도구나 접근법을 활용중이라면 대충 해결책을 제안하지 마십시오. 좋은 도구를 제안하세요. 질문을 재구성하기 바랍니다.

실제 질문에 답하십시오! 질문자가 너무 성실해서 본인이 해야할 검색을 마쳤고, 질문에 X, Y, Z, A, B, C를 모두 시도하였음에도 좋은 결과가 없었다는 점을 밝혔다면, “A나 B를 시도해보세요"나 “X, Y, Z, A, B 또는 C를 시도해보세요"를 담는 링크를 제공하는 것들은 전혀 도움이 되지 않습니다.

질문으로부터 커뮤니티가 무언가를 배울 수 있도록 도와주세요. 누군가 좋은 질문을 했다면, “관련 문서나 FAQ를 어떻게 수정하면 누구도 이 질문을 다시 할 필요가 없을까?“하는 식으로 스스로 질문해보십시오. 그리고 문서 관리자에게 패치를 전송하십시오.

질문에 대한 답을 하기 위해 검색을 했다면, 당신의 기술을 보여줘야지 답이 엉덩이에서 갑자기 튀어나온 것처럼 답을 작성하지 마십시오. 좋은 질문에 답하는 것은 배고픈 사람에게 한끼를 대접하는 것과 같지만, 예시로 검색 방법을 가르치는 것은 일생동안 식량을 재배하는 방법을 보이는 것과 같습니다.

관련 자료

PC(personal computer), 유닉스, 인터넷이 어떻게 작동하는지 기본적인 가이드가 필요하다면, 유닉스와 인터넷 기초(The Unix and Internet Fundamentals HOWTO)를 참조하십시오.

소프트웨어를 출시하거나 소프트웨어를 위한 패치를 작성할 때, 소프트웨어 출시 연습(Software Release Practice HOWTO)을 참조하십시오.

감사 인사

Evelyn Mitchell은 멍청한 질문들의 일부 예시를 제공하였고 “도움이 되는 방향으로 질문에 답하는 방법” 섹션을 작성할 동기를 부여하였습니다. Mikhail Ramendik은 개선을 위한 일부 가치 있는 공헌을 하였습니다.