해커와 오픈 소스 커뮤니티에서 기술적 질문을 효과적으로 던지고 유용한 답을 얻는 법을 설명하는 가이드.
Copyright © 2001,2006,2014 Eric S. Raymond, Rick Moen
| 개정 이력 |
|---|
| 개정 3.10 |
| Stack Overflow 절 추가 |
| 개정 3.9 |
| URL 수정 |
| 개정 3.8 |
| URL 수정 |
| 개정 3.7 |
| ESL 화자를 위한 유용한 힌트 |
| 개정 3.7 |
| 여러 언어 번역본이 사라짐 |
| 개정 3.6 |
| 소규모 업데이트 및 새 링크 |
| 개정 3.5 |
| 오탈자 수정 및 번역 링크 일부 추가 |
| 개정 3.4 |
| "코드에 대해 질문할 때" 절 신설 |
| 개정 3.3 |
| Kai Niggemann의 좋은 제안을 반영 |
| 개정 3.2 |
| Rick Moen의 편집 반영 |
| 개정 3.1 |
| "Google이 당신의 친구!" 문서화 |
| 개정 3.0 |
| 웹 포럼 예절에 대한 대폭 추가 |
많은 프로젝트 웹사이트가 도움을 얻는 법 섹션에서 이 문서를 링크합니다. 그건 좋습니다. 우리가 의도한 용도이기도 합니다. 하지만 프로젝트 페이지에 그런 링크를 거는 웹마스터라면, 링크 근처에 눈에 잘 띄게 다음 안내를 표시해 주세요. 우리는 당신의 프로젝트를 위한 헬프 데스크가 아닙니다!
우리는 이 안내문이 없으면, 이 문서를 공개했다는 이유만으로 우리가 세상의 모든 기술 문제를 해결해 주어야 한다고 착각하는 멍청이들에게 반복적으로 괴롭힘을 당한다는 사실을 뼈저리게 배웠습니다.
당신이 도움이 필요해서 이 문서를 읽고, 이 문서의 저자들에게서 직접 도움을 받을 수 있다는 인상을 가진 채 떠난다면, 당신 은 우리가 말하는 그 멍청이 중 하나입니다. 우리에게 질문하지 마세요. 우린 그냥 무시할 겁니다. 우리는 당신이 다루는 소프트웨어나 하드웨어를 실제로 아는 사람들에게서 도움을 얻는 법을 보여주려는 것이지, 그 99.9%는 우리 자체가 아닙니다. 당신이 다루는 것에 대해 저자 중 누군가가 틀림없이 전문가라는 걸 모르는 한, 우리를 내버려 두면 모두가 더 행복해질 겁니다.
해커 세계에서는, 기술적 질문에 대해 얻는 답변의 질이 답을 찾아내는 난이도만큼이나 ‘질문을 어떻게 하느냐’에 좌우됩니다. 이 가이드는 만족스러운 답을 얻을 가능성이 높은 방식으로 질문하는 법을 알려줍니다.
오픈 소스의 사용이 보편화된 지금, 때로는 해커 못지않게 숙련된 다른 사용자들에게서도 좋은 답을 얻을 수 있습니다. 이는 좋은 일입니다. 사용자들은 초보가 흔히 겪는 실패에 대해 조금 더 관대하기 마련이니까요. 그래도 여기서 권하는 방식대로 숙련 사용자들을 해커처럼 대하는 것이 그들로부터 유용한 답을 얻는 데에도 대개 가장 효과적입니다.
먼저 알아야 할 것은, 해커는 사실 어려운 문제와 그에 대한 좋고 사려 깊은 질문을 좋아한다는 점입니다. 그렇지 않았다면 여기 있지 않았을 겁니다. 곱씹을 만한 흥미로운 질문을 주면 우리는 당신에게 감사할 것입니다. 좋은 질문은 자극이자 선물입니다. 좋은 질문은 우리의 이해를 발전시키고, 우리가 미처 알아차리지 못했거나 생각하지 못했던 문제를 드러내 주기도 합니다. 해커들 사이에서 “좋은 질문이네!”는 강력하고 진심 어린 칭찬입니다.
그럼에도 불구하고, 해커들은 단순한 질문에 적대적이거나 거만하게 보이는 명성을 가지고 있습니다. 우리가 반사적으로 초보자와 무지한 사람에게 무례하게 굴어 보일 때가 있죠. 하지만 그건 사실이 아닙니다.
우리가 미안하지도 않게 적대적인 대상은, 질문하기 전에 스스로 생각하거나 숙제를 할 의지가 없어 보이는 사람들입니다. 그런 사람들은 시간 블랙홀입니다. 주기만 하고 돌려주지는 않으며, 우리가 더 흥미로운 질문과 답할 가치가 더 높은 사람에게 쓸 수 있는 시간을 탕진하게 만듭니다. 우리는 이런 사람들을 “루저”(역사적 이유로 가끔 “루저(luser)”라고도 씁니다)라고 부릅니다.
우리는 우리가 만든 소프트웨어를 그냥 쓰기만 하고 기술적 세부사항을 배울 흥미는 없는 사람이 많다는 걸 압니다. 대부분의 사람에게 컴퓨터는 단지 도구, 수단일 뿐이며 그들은 더 중요한 일을 하고 살아갑니다. 우리는 이를 인정하며, 우리를 매혹시키는 기술적 문제에 모두가 흥미를 느끼리라 기대하지 않습니다. 그럼에도, 우리가 질문에 답하는 방식은 그러한 문제에 흥미를 느끼고 해결 과정에 적극 참여하려는 사람들에게 맞춰져 있습니다. 이건 변하지 않을 겁니다. 변해서도 안 됩니다. 변한다면 우리가 가장 잘하는 일에서 덜 효율적이 될 테니까요.
우리는 (대부분) 자원봉사자입니다. 우리는 바쁜 일상에서 시간을 내어 질문에 답하고, 때때로 압도당합니다. 그래서 우리는 가차 없이 필터링합니다. 특히 루저처럼 보이는 사람들의 질문은 버리고, 질문에 답하는 시간을 ‘승자’에게 더 효율적으로 쓰려고 합니다.
이 태도가 불쾌하거나, 잘난 체하거나, 오만하다고 느껴진다면, 당신의 가정을 점검하세요. 우리는 당신이 우리에게 절하길 요구하지 않습니다. 사실, 가능하게 만드는 노력을 한다면 우리 대부분은 당신을 동등한 존재로 대하고 우리 문화에 환영하는 것을 무엇보다도 좋아합니다. 하지만 스스로 돕고자 하지 않는 사람을 돕는 것은 비효율적입니다. 무지해도 괜찮습니다. 하지만 멍청한 척하는 건 괜찮지 않습니다.
따라서, 우리의 관심을 끌기 위해 미리 기술적으로 유능할 필요는 없지만, 유능함으로 이끄는 태도—예민함, 사려 깊음, 관찰력, 해결책 개발에 적극적으로 동참하려는 의지—를 보여줄 필요는 있습니다. 이런 구별을 받아들일 수 없다면, 해커에게 개인적으로 기부된 도움을 구하기보다 상업적 지원 계약을 유료로 받기를 권합니다.
우리에 도움을 청하기로 했다면, 루저가 되지 마세요. 루저처럼 보이지도 마세요. 신속하고 성의 있는 답을 얻는 최고의 방법은, 평범한 문제 하나에 대해 도움이 필요할 뿐인, 똑똑하고 자신감 있고 단서가 있는 사람처럼 질문하는 것입니다.
(이 가이드에 대한 개선은 환영합니다. 제안은 esr@thyrsus.com 또는 respond-auto@linuxmafia.com으로 보내 주세요. 다만 이 문서는 일반적인 네티켓 가이드가 아니며, 기술 포럼에서 유용한 답을 이끌어내는 것과 직접 관련 없는 제안은 대체로 거절할 것입니다.)
이메일, 뉴스그룹, 웹사이트 게시판으로 기술적 질문을 하기 전에 다음을 하세요.
게시하려는 포럼이나 메일링 리스트의 아카이브를 검색하여 답을 찾으세요.
웹을 검색하여 답을 찾으세요.
매뉴얼을 읽어 답을 찾으세요.
FAQ를 읽어 답을 찾으세요.
점검하거나 직접 실험하여 답을 찾으세요.
실력 있는 친구에게 물어 답을 찾으세요.
당신이 프로그래머라면 소스 코드를 읽어 답을 찾으세요.
질문을 올릴 때, 먼저 위의 일들을 했다는 사실을 보여 주세요. 그래야 당신이 게으른 스펀지처럼 남의 시간을 낭비하는 사람이 아님을 증명할 수 있습니다. 더 좋게는, 이 과정을 통해 배운 것 을 보여 주세요. 우리는 답에서 배울 수 있음을 보여준 사람의 질문에 답하는 것을 좋아합니다.
오류 메시지의 텍스트로 구글 검색을 해 보는 것 같은 전술을 쓰세요(웹 페이지뿐 아니라 Google Groups도 검색). 이렇게 해서 바로 해결 문서나 메일링 리스트 글타래를 찾을 수 있습니다. 설령 아니더라도 “다음 문구로 구글링했지만 유망해 보이는 결과가 없었습니다”라고 도움을 요청하는 글에 적어두면 좋은 일입니다. 이렇게 하면 어떤 검색이 도움이 되지 않는지도 기록되며, 검색어가 당신의 문제와 해결 글타래에 연결되어 비슷한 문제를 가진 다른 사람들도 당신의 글타래를 찾는 데 도움이 됩니다.
시간을 들이세요. 몇 초의 구글링으로 복잡한 문제를 해결할 수 있으리라 기대하지 마세요. FAQ를 읽고 이해하고, 기대지 말고 편히 앉아 전문가에게 접근하기 전에 문제를 곰곰이 생각하세요. 믿으세요. 그들은 당신의 질문만 보고 당신이 얼마나 읽고 생각했는지 알아챌 것이며, 준비되어 오면 기꺼이 도와줄 가능성이 높습니다. 첫 검색에서 답이 없었다고(혹은 결과가 너무 많다고) 해서 당신의 질문 무기를 한꺼번에 난사하지 마세요.
질문을 준비하세요. 곰곰이 생각하세요. 성급해 보이는 질문은 성급한 답을 얻거나, 아예 답을 얻지 못합니다. 도움을 구하기 전에 문제 해결에 생각과 노력을 기울였음을 보여줄수록 실제 도움을 얻을 가능성이 커집니다.
틀린 질문을 경계하세요. 잘못된 가정에 기초한 질문을 하면, J. Random Hacker는 “멍청한 질문…”이라고 생각하며 쓸모없이 문자 그대로의 답을 할 가능성이 큽니다. 당신이 필요로 한 게 아니라 당신이 요청한 걸 받는 경험이 교훈이 되길 바라면서요.
답변을 받을 권리가 있다고 절대 가정하지 마세요. 당신은 그렇지 않습니다. 결국 이 서비스에 돈을 내는 게 아니니까요. 답을 받으려면, 커뮤니티의 경험에 암묵적으로 기여하는, 단지 수동적으로 지식을 요구하는 게 아닌, 실질적이고 흥미롭고 사려 깊은 질문을 해야 합니다.
반대로, 해결책을 함께 개발하는 과정에 참여할 능력과 의지가 있음을 분명히 하는 것은 매우 좋은 출발입니다. “누가 방향을 알려줄 수 있나요?”, “제 예제에 무엇이 빠졌나요?”, “어떤 사이트를 확인했어야 하나요?”는 “제가 사용할 정확한 절차를 올려 주세요.”보다 답을 얻을 가능성이 높습니다. 당신이 방향만 알려주면 정말로 나머지 과정을 마칠 의지가 있음을 분명히 하기 때문입니다.
어디에서 질문할지 민감하게 선택하세요. 다음과 같은 경우 당신은 무시되거나 루저로 치부될 수 있습니다.
주제에 맞지 않는 포럼에 질문을 올림
고급 기술 질문이 기대되는 포럼에 매우 기초적인 질문을 올리거나 그 반대
너무 많은 뉴스그룹에 교차 게시함
당신과 아는 사이도 아니고 문제 해결에 개인적 책임도 없는 사람에게 개인 메일을 보냄
해커들은 소통 채널이 무관한 내용으로 잠기지 않도록, 부적절하게 겨냥된 질문을 날려버립니다. 당신에게 이 일이 일어나길 바라지 않을 겁니다.
따라서 첫 단계는 올바른 포럼을 찾는 것입니다. 다시 말하지만 구글과 다른 웹 검색은 당신의 친구입니다. 문제가 있는 하드웨어나 소프트웨어와 가장 밀접한 프로젝트 웹페이지를 찾으세요. 보통 FAQ(자주 묻는 질문) 목록, 프로젝트 메일링 리스트와 아카이브 링크가 있습니다. (찾아낸 FAQ를 읽는 것을 포함한) 당신의 노력으로 해결하지 못했다면, 이 메일링 리스트가 도움을 청할 마지막 장소입니다. 프로젝트 페이지에 버그 보고 절차가 설명되어 있거나 그에 대한 링크가 있을 수 있습니다. 있다면 따르세요.
낯선 사람이나 포럼으로 이메일을 던지는 것은 기껏해야 위험합니다. 예를 들어, 유익한 웹페이지의 작성자가 당신의 무료 컨설턴트가 되기를 원할 거라고 가정하지 마세요. 당신의 질문이 환영받을지 낙관적으로 추측하지 마세요. 확신이 없다면 다른 곳으로 보내거나 아예 보내지 마세요.
웹 포럼, 뉴스그룹, 메일링 리스트를 선택할 때 이름만 믿지 말고, FAQ나 헌장을 찾아 당신의 질문이 온토픽인지 확인하세요. 게시 전에 이전 트래픽을 조금 읽어 그곳의 관행을 익히세요. 사실, 게시 전에 뉴스그룹이나 메일링 리스트 아카이브에서 당신의 문제와 관련된 키워드 검색을 하는 것이 매우 좋습니다. 답을 찾을 수도 있고, 아니라면 더 나은 질문을 구성하는 데 도움이 됩니다.
가능한 모든 지원 채널에 산탄총을 난사하지 마세요. 그건 소리 지르는 것과 같아서 사람들을 짜증나게 합니다. 조용히 단계적으로 접근하세요.
당신의 주제를 정확히 아세요! 전형적인 실수 중 하나는, 유닉스나 윈도우 프로그래밍 인터페이스에 대한 질문을 양쪽 모두에서 이식 가능한 언어/라이브러리/도구 전용 포럼에 올리는 것입니다. 왜 실수인지 이해가 안 된다면, 이해할 때까지 아무 질문도 하지 않는 것이 좋습니다.
일반적으로 잘 고른 공개 포럼에 올리는 질문이 비공개 질문보다 유용한 답을 얻을 가능성이 높습니다. 이유는 여럿입니다. 하나는 잠재적 응답자 풀의 규모입니다. 다른 하나는 청중의 규모입니다. 해커는 소수에게만 도움이 되는 질문보다 많은 사람을 가르치는 질문에 답하길 더 원합니다.
이해할 만하게도, 숙련된 해커와 인기 소프트웨어의 저자들은 이미 과도한 오타겟 메시지를 받고 있습니다. 당신이 홍수를 더하면, 극단적인 경우 낙타의 등을 부러뜨리는 마지막 짚이 될 수도 있습니다. 실제로 인기 프로젝트의 기여자 중에는 개인 계정으로 오는 쓸모없는 이메일 트래픽이라는 부수 피해가 견딜 수 없게 되어 지원을 철회한 사례가 적지 않습니다.
검색하고, 그다음에 Stack Exchange에 물어보세요
최근 몇 년 동안, Stack Exchange 사이트 커뮤니티는 기술 및 기타 질문에 답하는 주요 자원으로 자리 잡았고, 많은 오픈 소스 프로젝트가 선호하는 포럼이 되었습니다.
Stack Exchange를 보기 전에 구글 검색부터 시작하세요. 구글은 실시간으로 인덱싱합니다. 누군가 이미 유사한 질문을 했을 가능성이 매우 높고, Stack Exchange 사이트는 종종 검색 결과 상단에 나타납니다. 구글에서 찾지 못했다면, (아래 참조) 당신의 질문과 가장 관련 있는 특정 사이트에서 다시 검색하세요. 태그로 검색을 좁히는 것도 도움이 됩니다.
여전히 못 찾았다면, 가장 온토픽인 한 사이트에 질문을 게시하세요. 특히 코드에 대해서는 서식 도구를 사용하고, 당신의 질문 내용과 관련된 태그(문제 중인 프로그래밍 언어, 운영체제, 라이브러리 이름 등)를 추가하세요. 댓글로 추가 정보를 요청받으면 본문 글을 편집하여 반영하세요. 도움이 된 답에는 위쪽 화살표로 추천을, 문제 해결을 제공한 답에는 투표 화살표 아래의 체크를 눌러 정답으로 수락하세요.
Stack Exchange는 100개가 넘는 사이트로 성장했지만, 가장 가능성 높은 후보는 다음과 같습니다.
Super User: 범용 컴퓨팅 관련 질문. 코드나 네트워크 연결로만 대화하는 프로그램에 대한 질문이 아니라면 여기가 맞습니다.
Stack Overflow: 프로그래밍 관련 질문.
Server Fault: 서버 및 네트워크 관리 관련 질문.
여러 프로젝트는 Android, Ubuntu, TeX/LaTeX, SharePoint처럼 고유 사이트를 갖습니다. 최신 목록은 Stack Exchange 사이트에서 확인하세요.
당신의 지역 사용자 그룹이나 리눅스 배포판은 초보자들이 도움을 받을 수 있는 웹 포럼이나 IRC 채널을 광고할 수 있습니다.(비영어권 국가에서는 초보자 포럼이 여전히 메일링 리스트일 가능성이 큽니다.) 비교적 단순하거나 흔한 문제에 걸렸다고 생각한다면 이곳이 첫 질문 장소로 좋습니다. 공지된 IRC 채널은 그곳에서 질문하라는 열린 초대이며, 종종 실시간으로 답을 받을 수 있습니다.
사실, 요즘 흔하듯 문제가 된 프로그램을 리눅스 배포판에서 받았다면, 프로그램의 프로젝트 포럼/리스트보다 배포판 포럼/리스트에서 먼저 묻는 것이 더 나을 수 있습니다. 프로젝트 해커들은 “우리 빌드를 쓰세요”라고 답할지도 모릅니다.
어떤 웹 포럼에 글을 올리기 전에, 검색 기능이 있는지 확인하세요. 있다면 당신의 문제와 비슷한 키워드로 몇 번 검색해 보세요. 도움이 될 수 있습니다. 앞서 일반적인 웹 검색을 했더라도(그랬어야 합니다), 포럼 내 검색도 하세요. 웹 전체 검색 엔진이 해당 포럼을 최근에 모두 인덱싱했으리라는 보장은 없습니다.
프로젝트별 지원은 웹 포럼이나 IRC 채널에서 이루어지고, 이메일은 개발 트래픽에 남겨두는 경향이 증가하고 있습니다. 따라서 프로젝트 특화 도움을 구할 때는 먼저 이런 채널을 찾아보세요.
IRC에서는 시작부터 장문의 문제 설명을 채널에 덤프하지 않는 게 좋습니다. 어떤 사람들은 채널 플러딩으로 해석합니다. 대화를 시작하도록 유도하는 한 줄짜리 문제 설명으로 시작하는 게 최선입니다.
프로젝트에 개발 메일링 리스트가 있다면, 개인 개발자가 아닌 메일링 리스트에 쓰세요. 누가 가장 잘 답할지 안다고 생각되더라도 그렇습니다. 프로젝트 문서와 홈페이지에서 프로젝트 메일링 리스트 주소를 확인하고 그것을 사용하세요. 그럴만한 이유가 몇 가지 있습니다.
한 개발자에게 물을 만한 좋은 질문은 전체 그룹에도 가치가 있습니다. 반대로, 질문이 메일링 리스트에 올리기엔 너무 바보 같다고 의심된다면, 개인 개발자를 괴롭힐 핑계가 되지 않습니다.
리스트에 질문하면 개발자 사이에 부담이 분산됩니다. 개인 개발자는(특히 그가 프로젝트 리더라면) 당신의 질문에 답할 시간이 없을 수 있습니다.
대부분의 메일링 리스트는 아카이브되고 검색 엔진이 인덱싱합니다. 리스트에 질문했고 답이 달리면, 미래의 질문자는 동일 질문을 또 하기보다 웹에서 당신의 질문과 답을 찾을 수 있습니다.
특정 질문이 자주 올라오는 것이 보이면, 개발자들은 그 정보를 이용해 문서나 소프트웨어를 덜 혼란스럽게 개선할 수 있습니다. 그러나 질문이 개인적으로만 오가면, 어떤 질문이 자주 나오는지 전체 그림을 아무도 알 수 없습니다.
프로젝트에 “user”와 “developer”(혹은 “hacker”) 메일링 리스트/웹 포럼이 모두 있고 당신이 코드를 해킹하지 않는다면, “user” 리스트/포럼에 물어보세요. 개발자 리스트에 환영받을 것이라 가정하지 마세요. 개발자들은 당신의 질문을 개발 트래픽을 방해하는 잡음으로 느낄 가능성이 큽니다.
하지만 당신의 질문이 사소하지 않음 이 확실하고 “user” 리스트/포럼에서 며칠간 답이 없다면 “developer” 쪽을 시도하세요. 게시하기 전에 며칠 잠복하거나 최소한 최근 며칠간의 아카이브 메시지를 훑어 그곳의 방식에 익숙해지는 것이 좋습니다(사실 이는 어떤 사적/반사적 리스트에도 좋은 조언입니다).
프로젝트 메일링 리스트 주소를 찾을 수 없고 유지자 주소만 보인다면, 유지자에게 써도 됩니다. 하지만 그 경우에도 리스트가 없다고 가정하지 마세요. 적절한 메일링 리스트를 찾으려 했지만 찾지 못했다는 점을 메일에 언급하세요. 또한 당신의 메시지를 다른 사람에게 전달해도 괜찮다는 점도 적어두세요. (많은 사람은 비밀이 없더라도 개인 이메일은 개인적으로 남아야 한다고 믿습니다. 전달을 허용하면 상대가 당신의 메일을 처리할 선택지를 갖게 됩니다.)
메일링 리스트, 뉴스그룹, 웹 포럼에서 제목은 50자 안팎으로 전문가들의 관심을 끌 황금 같은 기회입니다. “도와주세요”(더구나 “제발 도와주세요!!!!”) 같은 잡담으로 낭비하지 마세요. 그런 제목의 메시지는 반사적으로 폐기됩니다. 고통의 깊이를 우리에게 과시하려 하지 말고, 공간을 초간결한 문제 설명에 사용하세요.
많은 기술 지원 조직이 쓰는 좋은 제목 규칙은 “대상 - 일탈”입니다. “대상”은 문제가 있는 것(들)을 지정하고, “일탈”은 기대 행동에서 벗어난 점을 설명합니다.
멍청한: 도와주세요! 노트북에서 비디오가 제대로 동작하지 않습니다!
현명한: X.org 6.8.1에서 마우스 커서 형태가 이상함, Fooware MV1005 비디오 칩셋
더 현명한: X.org 6.8.1/Fooware MV1005 비디오 칩셋에서 마우스 커서가 이상한 모양임
“대상-일탈” 설명을 쓰는 과정은 문제에 대해 더 자세히 생각을 정리하도록 도와줍니다. 무엇이 영향을 받나요? 마우스 커서만인가요, 다른 그래픽도인가요? X의 X.org 버전에 특이한 일인가요? 6.8.1 버전에만? Fooware 비디오 칩셋에만? MV1005 모델에만? 결과를 본 해커는 한눈에 무엇에 문제가 있고 어떤 문제가 있는지 즉시 이해할 수 있습니다.
더 일반적으로, 제목 줄만 보이는 질문 아카이브의 인덱스를 본다고 상상해 보세요. 다음에 당신과 유사한 질문을 검색하는 사람이 답을 찾기 위해 글타래를 따라갈 수 있도록, 제목이 질문을 잘 반영하도록 하세요. 같은 질문을 또 올리지 않게요.
답글에서 질문을 한다면, 제목을 바꿔 질문임을 표시하세요. “Re: test”나 “Re: new bug” 같은 제목은 관심을 덜 끕니다. 또한 새 독자에게 단서를 주는 데 필요한 최소한으로만 이전 메시지 인용을 줄이세요.
완전히 새로운 글타래를 시작하려고 리스트 메시지에 그냥 ‘답장’만 누르지 마세요. 그러면 청중이 제한됩니다. mutt 같은 일부 메일 리더는 스레드별 정렬과 스레드 접기 기능이 있어, 그렇게 쓰면 아예 당신 메시지를 보지 못할 수 있습니다.
제목만 바꾸는 것으로는 충분하지 않습니다. mutt(그리고 아마 다른 메일 리더들도)는 스레드 할당에 제목이 아니라 헤더의 다른 정보를 봅니다. 대신 완전히 새로운 이메일을 시작하세요.
웹 포럼에서는 메시지가 개별 토론 스레드에 훨씬 더 강하게 묶여 있고 그 스레드 밖에서는 보이지 않는 경우가 많기 때문에 관행이 약간 다릅니다. 답글에서 질문할 때 제목을 바꾸는 것은 필수는 아닙니다. 답글에 별도의 제목 줄을 허용하지 않는 포럼도 있고, 허용하더라도 거의 아무도 읽지 않습니다. 그러나 답글로 질문하는 행위 자체가 의심스러운 관행입니다. 그 스레드를 보고 있는 사람에게만 보이기 때문입니다. 따라서 현재 그 스레드에 활동 중인 사람들만 상대로 원한다 는 확신이 없다면, 새 글타래로 시작하세요.
“답장은 …로 보내 주세요”로 질의를 끝내면 답을 받을 가능성이 크게 줄어듭니다. 메일 프로그램에서 올바른 Reply-To 헤더를 설정하는 몇 초도 감수하지 않는다면, 우리도 당신의 문제를 몇 초 생각해 주지 않을 겁니다. 메일 프로그램이 이를 지원하지 않으면, 더 나은 메일 프로그램을 쓰세요. 운영체제가 이런 기능을 가진 메일 프로그램을 지원하지 않는다면, 더 나은 운영체제를 쓰세요.
웹 포럼에서 이메일로 답을 달라고 요구하는 것은 대놓고 무례합니다(정보가 민감해서, 알 수 없는 이유로 당신에게만 알려주겠다는 경우가 아니라면). 누군가가 스레드에 답하면 이메일 복사본을 받고 싶다면, 포럼의 알림 기능을 사용하세요. 거의 어디에나 “이 스레드 구독”, “답변 시 이메일 보내기” 같은 옵션이 있습니다.
경험상, 대충대충 글 쓰는 사람은 생각과 코딩도 대충대충인 경우가 많습니다(내기를 걸 만큼 자주). 덜렁대고 대충대충 생각하는 사람의 질문에 답하는 것은 보람이 없습니다. 우리는 시간을 다른 데 쓰고 싶습니다.
따라서 질문을 분명하고 잘 표현하는 것이 중요합니다. 그렇게 할 수 없다면, 우리는 주의를 기울일 수 없습니다. 언어를 다듬는 데 추가 노력을 들이세요. 딱딱하거나 형식적일 필요는 없습니다. 사실 해커 문화는 정밀하게 사용된 비격식, 속어, 유머를 가치 있게 여깁니다. 하지만 정확 해야 합니다. 당신이 생각하고 주의를 기울이고 있다는 표시가 있어야 합니다.
철자, 구두점, 대소문자를 정확히 쓰세요. “its”와 “it's”, “loose”와 “lose”, “discrete”와 “discreet”를 혼동하지 마세요. 모두 대문자로 쓰지 마세요. 고함으로 읽히고 무례하다고 여겨집니다. (모두 소문자도 약간 덜 성가실 뿐 읽기 어렵습니다. Alan Cox는 그래도 되겠지만 당신은 안 됩니다.)
더 일반적으로, 반문맹처럼 쓰면 무시당할 가능성이 큽니다. 그러니 인스턴트 메신저식 줄임말을 쓰지 마세요. "you"를 "u"로 쓰는 건 두 타를 아끼려 반문맹처럼 보이는 겁니다. 더 나쁜 건: l33t 스크립트 키디 hax0r처럼 쓰는 겁니다. 이건 완전히 치명타이며, 돌아오는 것은 돌같이 침묵(최선의 경우엔 경멸과 빈정거림 한아름)뿐입니다.
당신의 모국어가 아닌 포럼에서 질문한다면, 철자와 문법 오류에 대해 약간의 여유는 받을 수 있지만, 게으름에 대해서는 어떠한 여유도 없습니다(네, 우리는 보통 둘의 차이를 알아봅니다). 또한, 응답자의 언어를 모른다면 영어로 쓰세요. 바쁜 해커들은 이해하지 못하는 언어로 된 질문을 그냥 버리는 경향이 있고, 영어는 인터넷의 공용어입니다. 영어로 쓰면 읽지도 않고 버려질 가능성을 최소화합니다.
영어로 쓰지만 영어가 제2외국어라면, 잠재적 응답자에게 언어적 어려움과 이를 우회할 선택지를 알리는 것이 좋습니다. 예:
영어는 제 모국어가 아닙니다. 오탈자를 양해해 주세요.
당신이 $LANGUAGE를 쓰신다면 이메일/쪽지 주세요. 제 질문 번역을 도와주실 수 있을지 모릅니다.
기술 용어에는 익숙하지만, 일부 속어와 관용구는 어렵습니다.
제 질문을 $LANGUAGE와 영어로 모두 게시했습니다. 둘 중 한 언어만 쓰셔도 제가 번역해 드리겠습니다.
질문을 인위적으로 읽기 어렵게 만들면, 그렇지 않은 질문에 비해 건너뛰어질 가능성이 큽니다. 그러니 다음을 지키세요.
HTML이 아닌 일반 텍스트 메일을 보내세요. (HTML을 끄는 방법은 어렵지 않습니다.)
MIME 첨부는 보통 괜찮지만, 실제 콘텐츠(첨부 소스 파일이나 패치 등)일 때만 허용됩니다. 메일 클라이언트가 생성한 상투적 덤(당신의 메시지의 또 다른 사본 같은)은 안 됩니다.
전체 문단이 단일 다중 래핑 줄로 된 이메일을 보내지 마세요. (메시지 일부에만 답하기 너무 어렵습니다.) 응답자가 80자 폭 텍스트 화면에서 메일을 읽는다고 가정하고 줄바꿈 폭을 80자보다 작게 설정하세요.
하지만 로그 덤프나 세션 트랜스크립트 같은 데이터 는 어떤 고정 컬럼 너비로도 줄바꿈하지 마세요. 데이터는 있는 그대로 포함해서, 응답자가 당신이 본 것을 그대로 보고 있다는 확신을 가질 수 있어야 합니다.
영어 포럼에 MIME Quoted-Printable 인코딩을 보내지 마세요. ASCII가 커버하지 못하는 언어를 게시할 때 필요할 수 있지만, 많은 메일 에이전트가 이를 지원하지 않습니다. 깨지면 텍스트 여기저기에 흩어진 =20 같은 글리프가 보기 흉하고 산만할 뿐 아니라, 텍스트의 의미를 망칠 수도 있습니다.
Microsoft Word나 Excel 같은 폐쇄형 독점 문서 포맷을 해커가 읽을 수 있으리라 절대 기대하지 마세요. 대부분의 해커는 이것들을 당신 문 앞에 김이 모락모락 나는 돼지 분뇨를 쌓는 것만큼이나 불쾌하게 여깁니다. 설령 처리할 수 있더라도, 그렇게 해야 하는 사실 자체에 불만을 느낍니다.
윈도우 머신에서 이메일을 보내는 경우, 마이크로소프트의 문제 많은 “Smart Quotes” 기능을 끄세요(도구 > 자동고침 옵션에서 ‘입력할 때 자동 서식’의 스마트 따옴표 체크박스를 해제). 그래야 메일에 쓰레기 문자가 뿌려지는 일을 피할 수 있습니다.
웹 포럼에서 “스마일리”와 “HTML” 기능(있을 경우)을 남용하지 마세요. 스마일리 하나 둘은 보통 괜찮지만, 색색의 화려한 텍스트는 당신이 한심해 보이게 만듭니다. 스마일리와 색과 폰트를 과도하게 쓰면 깔깔거리는 십대 소녀처럼 보일 것이며, 성적 관심이 답변보다 더 중요하지 않는 한 대개 좋은 생각이 아닙니다.
Netscape Messenger, MS Outlook 같은 GUI 메일 클라이언트를 사용한다면, 기본 설정으로는 위 규칙을 위반할 수 있음을 조심하세요. 대부분의 이런 클라이언트에는 메뉴 기반 “소스 보기” 명령이 있습니다. 보낸 편지함의 항목에 이를 사용해, 필요 없는 첨부물 없이 일반 텍스트가 전송되었는지 확인하세요.
문제나 버그의 증상을 조심스럽고 명확하게 설명하세요.
문제가 발생하는 환경(기기, OS, 애플리케이션 등)을 설명하세요. 배포판과 릴리스 레벨도 제공하세요(예: “Fedora Core 7”, “Slackware 9.1” 등).
질문 전에 문제를 이해하려고 수행한 조사를 설명하세요.
질문 전에 스스로 문제를 특정하려고 수행한 진단 단계를 설명하세요.
컴퓨터나 소프트웨어 구성에 최근 있었던 관련 가능성이 있는 변경을 설명하세요.
가능하다면, 통제된 환경에서 문제를 재현 할 수 있는 방법을 제공하세요.
해커가 물을 법한 질문을 최대한 예상하고, 도움 요청에 미리 답하세요.
특히 코드의 버그라고 생각되는 것을 보고하는 경우, 해커가 통제된 환경에서 문제를 재현할 수 있게 하는 것이 중요합니다. 이렇게 하면 유용한 답을 얻을 확률과 속도가 엄청나게 좋아집니다.
Simon Tatham이 쓴 효과적으로 버그 보고하는 법은 훌륭한 에세이입니다. 강력히 읽기를 권합니다.
정확하고 유익해야 합니다. 도움 요청에 방대한 코드나 데이터를 덤핑하는 것은 목적에 부합하지 않습니다. 프로그램을 깨뜨리는 큰 복잡한 테스트 케이스가 있다면, 잘라내 최대한 작게 만드세요.
이건 적어도 세 가지 이유로 유익합니다. 하나: 질문 단순화에 노력을 들였다는 인식이 답을 받을 가능성을 높입니다. 둘: 질문을 단순화하면 유용한 답을 받을 가능성이 커집니다. 셋: 버그 리포트를 정제하는 과정에서 스스로 해결책이나 우회책을 찾을 수도 있습니다.
소프트웨어에 문제가 있을 때, 당신의 입장이 아주 매우 확실하지 않다면 버그를 발견했다고 주장하지 마세요. 힌트: 문제를 고치는 소스 패치를 제공하거나, 이전 버전에 대한 회귀 테스트로 잘못된 동작을 입증하지 못한다면, 충분히 확신한 게 아닙니다. 이는 웹페이지와 문서에도 적용됩니다. 문서의 “버그”를 찾았다면, 대체할 텍스트와 들어갈 페이지를 함께 제공해야 합니다.
당신의 문제를 겪지 않는 다른 사용자들이 많다는 사실을 기억하세요. 그렇지 않았다면 문서를 읽고 웹을 검색하는 동안 이미 알았을 겁니다(불평하기 전에 그렇게 했죠, 그렇죠?). 이는 아주 그럴듯하게, 소프트웨어가 아니라 당신이 뭔가를 잘못하고 있을 확률이 높다는 뜻입니다.
소프트웨어를 만든 사람들은 가능한 최선으로 동작하게 하려고 매우 열심히 일합니다. 버그를 찾았다고 주장하면 그들의 역량에 흠집을 내는 셈이며, 당신이 옳더라도 일부는 기분이 상할 수 있습니다. 특히 제목 줄에 “bug”라고 소리치는 건 외교적이지 못합니다.
질문할 때, 실제로 버그를 찾았다고 꽤 확신하더라도, 당신 이 뭔가 잘못하고 있다고 가정하는 어투로 쓰는 것이 가장 좋습니다. 정말 버그가 있다면 답에서 듣게 될 겁니다. 버그가 진짜라면 관리자가 당신에게 사과하고 싶어하도록 만들고, 당신이 실수했을 때는 당신이 사과해야 하는 상황을 피하세요.
무례하거나 오만하게 굴어 답을 요구하면 안 된다는 걸 이해한 일부 사람들은 반대로 굽실굽실의 극단으로 물러납니다. “저는 한심한 뉴비 루저라는 걸 압니다만…” 같은 것 말이죠. 이는 산만하고 도움이 되지 않습니다. 특히 실제 문제에 대해 모호함과 결합되면 더 짜증납니다.
당신과 우리의 시간을 원시적인 영장류 정치에 낭비하지 마세요. 대신 배경 사실과 질문을 가능한 한 명확하게 제시하세요. 굽실대는 것보다 이렇게 자신을 포지셔닝하는 편이 낫습니다.
웹 포럼에는 초보자 질문 전용 공간이 따로 있는 경우가 있습니다. 당신이 초보자 질문이라고 느낀다면 그곳으로 가세요. 하지만 그곳에서도 굽실거리지 마세요.
당신의 문제를 무엇이 일으킨다고 생각하는지를 해커에게 말하는 것은 유용하지 않습니다. (진단적 가설이 그 정도로 그럴듯했다면, 왜 다른 사람에게 도움을 구하겠습니까?) 그러니 무엇이 잘못되는지에 대한 날것의 증상을 말하는지 확인하세요. 해석과 진단은 그들에게 맡기세요. 추측을 말하고 싶다면, 분명히 그렇게 표시하고 왜 그 답이 당신에게는 작동하지 않는지도 설명하세요.
멍청한: 커널 컴파일 중에 연속 SIG11 오류가 납니다. 메인보드 트레이스에 미세한 크랙이 있다고 의심합니다. 그걸 확인하는 가장 좋은 방법은 뭔가요?
현명한: 제가 조립한 K6/233, FIC-PA2007 메인보드(VIA Apollo VP2 칩셋), Corsair PC133 SDRAM 256MB에서, 커널 컴파일 도중 전원 투입 20분 이후부터 잦은 SIG11 오류가 납니다. 첫 20분에는 결코 발생하지 않습니다. 재부팅으로는 시간이 리셋되지 않지만, 밤새 전원을 꺼두면 초기화됩니다. RAM을 전부 교체해도 개선이 없었습니다. 전형적인 컴파일 세션 로그의 관련 부분은 다음과 같습니다.
위의 포인트가 많은 사람에게 어렵다는 점을 고려해 기억할 문구를 하나 드립니다. “모든 진단자는 미주리에서 왔다.” 그 미국 주의 공식 모토는 “증명해봐(Show me)”입니다(1899년, Willard D. Vandiver 하원의원이 “나는 옥수수와 목화와 도꼬마리와 민주당을 키우는 나라에서 왔습니다. 거품 어린 웅변은 저를 설득하지도 만족시키지도 못합니다. 나는 미주리 출신입니다. 당신은 내게 보여줘야 합니다.”라고 말하며 얻었습니다). 진단자들의 경우 회의주의라기보다, 당신의 짐작과 요약이 아니라, 당신이 본 것과 최대한 가까운 날것의 증거를 보아야 하는 문자 그대로의 기능적 필요입니다. 우리에게 보여주세요.
무슨 일이 잘못되었는지 알아내는 데 가장 유용한 단서는 종종 직전 사건들에 있습니다. 따라서, 폭발에 이르기까지 당신이 무엇을 했고, 기계와 소프트웨어가 무엇을 했는지 정확히 설명해야 합니다. 커맨드라인 프로세스의 경우, script 유틸리티 같은 것으로 세션 로그를 남기고 관련 20줄 정도를 인용하는 것이 매우 유용합니다.
문제가 된 프로그램에 -v 같은 진단 옵션이 있다면, 트랜스크립트에 유용한 디버깅 정보를 추가할 수 있는 옵션을 선택해 보세요. 더 많은 것이 반드시 더 좋은 것은 아닙니다. 독자를 쓰레기에 빠뜨리지 말고 정보를 더하는 디버그 레벨을 선택하세요.
설명이 길어지는 경우(약 4단락 이상), 위에 문제를 간결히 요약하고 시간순 이야기를 이어가는 것이 유익할 수 있습니다. 그러면 해커들은 읽으면서 무엇에 주의를 기울여야 할지 알 수 있습니다.
무언가를 하는 방법을 찾으려는 경우(버그 리포트가 아니라), 목표 설명부터 시작하세요. 그 다음에 그 목표로 가는 과정 중 막힌 특정 단계를 설명하세요.
종종 기술적 도움이 필요한 사람은 고수준의 목표를 염두에 두고, 그 목표로 가는 특정 경로에 집착하다가 막힙니다. 그들은 그 단계에 대한 도움을 구하지만, 그 경로가 틀렸다는 것을 깨닫지 못합니다. 이를 넘어서려면 상당한 노력이 들 수 있습니다.
멍청한: FooDraw 프로그램의 컬러 피커에 16진수 RGB 값을 넣으려면 어떻게 하나요?
현명한: 제가 선택한 값으로 이미지의 컬러 테이블을 바꾸려고 합니다. 지금 보이는 유일한 방법은 각 테이블 슬롯을 편집하는 것인데, FooDraw의 컬러 피커가 16진수 RGB 값을 받지 않습니다.
두 번째 질문은 현명합니다. 작업에 더 적합한 도구를 제안하는 답을 허용하기 때문입니다.
해커는 문제 해결이 공개적이고 투명한 과정이어야 하며, 초안 답변은 더 아는 누군가가 미완성이나 오류를 발견하면 수정되어야 한다고 믿습니다. 또한, 도와주는 이들은 동료들에게 유능하고 박식하다는 인정을 받는 것에서 보상의 일부를 얻습니다.
개인 답변을 요구하면, 과정과 보상을 둘 다 방해합니다. 그러지 마세요. 개인적으로 답할지는 응답자 의 선택입니다. 그렇게 할 때는 대개 그 질문이 다른 이들에게 흥미롭지 않을 만큼 형편없거나 자명하다고 생각하기 때문입니다.
이 규칙에는 제한된 예외가 하나 있습니다. 매우 비슷한 답변이 많이 달릴 게 확실한 질문이라면, “이메일로 보내 주시면 모아서 그룹에 요약해 올리겠습니다”라는 마법의 문구가 있습니다. 실질적으로 동일한 게시물의 홍수를 리스트나 뉴스그룹에 일으키지 않도록 노력하는 것은 예의입니다. 하지만 약속한 요약은 반드시 지켜야 합니다.
열린 질문은 열린 시간 블랙홀로 인식되는 경향이 있습니다. 유용한 답을 줄 가능성이 가장 높은 사람들은(자기 자신이 일을 가장 많이 맡기 때문에라도) 가장 바쁜 사람들입니다. 그런 사람들은 열린 시간 블랙홀에 알레르기 반응을 보이므로, 열린 질문에도 알레르기가 있는 경향이 있습니다.
응답자에게 무엇을 해 주길 원하는지(포인터 제공, 코드 전송, 패치 확인 등)를 명시하면 유용한 답을 얻을 가능성이 커집니다. 이는 그들의 노력을 집중시키고, 도움에 할당해야 하는 시간과 에너지의 상한을 암묵적으로 설정합니다. 좋은 일입니다.
전문가들이 사는 세계를 이해하기 위해, 전문성은 풍부하지만 응답할 시간은 희소하다고 생각해 보세요. 암묵적으로 요구하는 시간 약속이 적을수록, 정말 좋고 정말 바쁜 사람에게서 답을 얻을 가능성이 커집니다.
따라서 전문가가 처리하는 데 필요한 시간 약속을 최소화하도록 질문을 구성하는 것이 유익합니다. 하지만 이는 종종 질문을 단순화하는 것과 같지 않습니다. 예를 들어 “X에 대한 좋은 설명으로 가는 포인터를 주시겠습니까?”가 보통 “X를 설명해 주시겠습니까?”보다 현명한 질문입니다. 오작동하는 코드가 있다면, 고쳐 달라고 하기보다 무엇이 잘못인지 설명해 달라고 요청하는 편이 보통 더 현명합니다.
힌트도 없이 남에게 당신의 깨진 코드를 디버깅해 달라고 하지 마세요. 수백 줄의 코드를 올리며 “안 됩니다”라고만 하면 무시당합니다. “7번째 줄 이후에 <x>를 기대했는데 <y>가 발생합니다”라고 말하며 10여 줄만 올리면 답을 얻을 가능성이 훨씬 큽니다.
코드 문제를 정확히 설명하는 가장 효과적인 방법은 최소 버그 재현 테스트 케이스를 제공하는 것입니다. 최소 테스트 케이스란 무엇일까요? 문제의 삽화입니다. 바람직하지 않은 동작을 드러내기에 충분한 만큼의 코드, 그 이상은 없는 코드입니다. 최소 테스트 케이스를 어떻게 만들까요? 문제 동작을 내는 줄이나 섹션을 안다면 그것을 복사하고, 컴파일러/인터프리터/처리 애플리케이션이 받아들이는 완결 예제가 되도록 보조 코드를 딱 필요한 만큼만 추가하세요. 특정 섹션으로 좁히지 못하겠다면 소스를 복사해 문제 동작에 영향을 주지 않는 덩어리를 제거해 나가세요. 최소 테스트 케이스가 작을수록 좋습니다(“양은 정확성이 아니다” 절 참조).
정말 작은 최소 테스트 케이스를 항상 만들 수 있는 것은 아니지만, 시도 자체가 좋은 훈련입니다. 스스로 문제를 해결하는 데 필요한 것을 배우게 도와줄 수 있습니다. 그렇지 않더라도, 해커들은 당신이 시도했다는 사실을 좋아합니다. 그들을 더 협조적으로 만듭니다.
단지 코드 리뷰가 필요하다면, 처음부터 그렇게 밝히고, 특히 어떤 부분이 왜 검토가 필요하다고 생각하는지도 명확히 하세요.
해커들은 숙제 문제를 잘 알아봅니다. 우리 대부분도 그런 걸 해 봤으니까요. 그런 질문은 당신 이 풀어야 하며, 그래야 경험에서 배웁니다. 힌트를 묻는 건 괜찮지만, 전체 해답을 요구하면 안 됩니다.
숙제 문제를 건네받은 것 같지만 그래도 못 풀겠다면, 사용자 그룹 포럼이나(최후의 수단으로) 프로젝트의 “user” 리스트/포럼에서 물어보세요. 해커들은 알아차릴 것이지만, 숙련 사용자 중 일부는 힌트를 줄지도 모릅니다.
“누가 도와줄 수 있나요?”, “답이 있나요?” 같은 의미 없는 질문을 덧붙이고 싶은 유혹을 이기세요. 첫째, 문제 설명을 그럭저럭 썼다면 이런 덧붙임 질문은 기껏해야 군더더기입니다. 둘째, 군더더기이므로 해커들은 이를 성가시게 여기며 “네, 도와줄 수 있습니다”, “아니요, 당신에겐 도움이 없습니다” 같은 논리적으로 흠잡을 데 없지만 무시하는 답을 돌려줄 가능성이 큽니다.
일반적으로, 예/아니오 답변만 원하지 않는다면 예/아니오 질문은 피하는 게 좋습니다.
그건 당신 문제이지 우리의 문제가 아닙니다. 긴급함을 주장하는 것은 대개 역효과입니다. 대부분의 해커는 즉각적이고 특별한 관심을 끌려는 무례하고 이기적인 시도로 간주해 메시지를 삭제합니다. 게다가 제목 줄의 'Urgent'(혹은 주목을 끌려는 유사 표현)은 스팸 필터를 촉발하는 경우가 많아, 수신자가 아예 보지 못할 수도 있습니다!
반쪽짜리 예외가 하나 있습니다. 해커들이 흥분할 만한 고프로필 장소에서 그 프로그램을 사용하고 있다고 언급할 가치는 있습니다. 이런 경우 시간 압박이 있다면 정중히 밝히세요. 사람들이 더 빨리 답하고자 흥미를 느낄 수 있습니다.
하지만 이는 매우 위험한 일입니다. 해커의 흥미 기준은 당신과 다를 가능성이 큽니다. 예컨대 국제우주정거장에서 게시했다면 해당되겠지만, 훈훈한 자선이나 정치적 목적을 대행하는 것이라면 거의 확실히 아닙니다. 사실 “긴급: 아기 물범을 구하는 걸 도와주세요!” 같은 글은 아기 물범을 중요하게 여기는 해커들에게조차 외면이나 비난을 확실히 받을 것입니다.
이게 이해되지 않는다면, 무엇이든 게시하기 전에 이 안내를 여러 번 읽어 이해할 때까지 반복하세요.
예의를 지키세요. “부탁드립니다”, “읽어 주셔서 감사합니다”, “검토해 주셔서 감사합니다” 같은 표현을 쓰세요. 사람들이 무료로 시간을 들여 도와준다는 점에 감사함을 분명히 하세요.
솔직히 말해, 이는 문법적·명확·정확·서술적이고, 독점 포맷을 피하는 것 등만큼 중요하지 않으며(그것들을 대체할 수도 없습니다). 해커들은 일반적으로 정중하지만 모호한 버그 보고보다 다소 퉁명스러워도 기술적으로 날카로운 버그 보고를 더 좋아합니다. (이게 의아하다면, 우리는 질문이 우리에게 무엇을 가르치는지로 그 가치를 평가한다는 점을 기억하세요.)
하지만 기술적 준비가 갖춰졌다면, 정중함은 유용한 답을 얻을 가능성을 높입니다.
(베테랑 해커들에게서 이 HOWTO에 대해 받은 유일한 진지한 이의는 우리가 이전에 “미리 감사합니다” 사용을 권했던 점입니다. 일부 해커는 이것이 이후에 누구에게도 감사하지 않겠다는 의도로 읽힌다고 느낍니다. 우리의 권고는 “미리 감사합니다”를 먼저 쓰고 또한 이후에 감사 인사를 하거나, “읽어 주셔서 감사합니다”, “검토해 주셔서 감사합니다”처럼 다른 방식으로 예의를 표현하라는 것입니다.)
문제가 해결되면 도와준 모든 이에게 결과를 알리고 다시 감사의 메모를 보내세요. 문제에 리스트나 뉴스그룹에서 일반적 관심이 붙었다면, 그곳에 후속 게시를 하는 것이 적절합니다.
최적으로는, 원래 질문 게시가 시작한 스레드에 답장하며, 제목에 ‘FIXED’, ‘RESOLVED’ 같은 명백한 태그를 포함하세요. 빠르게 돌아가는 메일링 리스트에서는, “문제 X” 스레드가 “문제 X - FIXED”로 끝나는 것을 본 잠재적 응답자는 (X가 개인적으로 흥미롭지 않다면) 시간을 낭비하지 않고 다른 문제를 푸는 데 그 시간을 쓸 수 있습니다.
후속 글은 길고 복잡할 필요가 없습니다. “안녕하세요 — 네트워크 케이블 불량이었습니다! 모두 감사합니다. - Bill”처럼 짧게라도 없는 것보다 낫습니다. 사실, 해결책에 진짜 기술적 깊이가 없다면 장광설보다 짧고 달콤한 요약이 더 좋습니다. 어떤 조치가 문제를 해결했는지 말하되, 전체 트러블슈팅 과정을 재연할 필요는 없습니다.
깊이가 있는 문제의 경우, 트러블슈팅 역사를 요약해 게시하는 것이 적절합니다. 최종 문제 진술을 설명하고, 해결책이 무엇이었는지 설명하며, 그 후에 피할 수 있었던 막다른 길도 표시하세요. 막다른 길은 올바른 해결책과 다른 요약 자료 뒤에 배치해, 후속을 추리 소설로 만들지 마세요. 도와준 사람들의 이름을 언급하세요. 그런 방식으로 친구를 사귈 수 있습니다.
예의 바르고 유익하다는 것 외에도, 이러한 후속은 리스트/뉴스그룹/포럼 아카이브를 검색하는 다른 이가 어떤 해결책이 당신에게 도움이 되었는지 정확히 알도록 도와, 그들에게도 도움이 됩니다.
마지막으로, 그리고 무엇보다, 이런 후속은 도운 모든 이가 문제에 대해 만족스러운 마무리 감각을 느끼게 합니다. 당신이 기술자나 해커가 아니더라도, 이 느낌이 당신이 도움을 청한 구루와 전문가들에게 매우 중요하다는 점을 믿어 주세요. 해결되지 않은 채 흐지부지 끝나는 문제 내러티브는 답답합니다. 해커들은 그것이 해결되길 바라는 가려움이 있습니다. 그 가려움을 긁어 주면 생기는 호의는, 다음에 질문해야 할 때 당신에게 매우, 매우 도움이 될 것입니다.
앞으로 다른 이들이 같은 문제를 겪지 않게 하려면 어떻게 할 수 있을지 생각해 보세요. 문서나 FAQ 패치가 도움이 될지 자문하고, 그렇다면 그 패치를 유지자에게 보내세요.
해커 사이에서는, 이런 좋은 후속 행동이 전통적 예의보다 더 중요합니다. 이는 ‘남들과 잘 어울리는’ 평판을 얻는 방법이며, 매우 가치 있는 자산이 될 수 있습니다.
오랜 전통이 있습니다. “RTFM”이라는 답을 받았다면, 보낸 사람은 당신이 Read The Fucking Manual(매뉴얼 좀 제대로 읽으라) 했어야 한다고 생각하는 겁니다. 그/그녀가 거의 틀림없이 옳습니다. 가서 읽으세요.
RTFM에는 더 어린 친척이 있습니다. “STFW”라는 답을 받았다면, 보낸 사람은 당신이 Search The Fucking Web(웹 검색 좀 제대로 하라) 했어야 한다고 생각하는 겁니다. 그/그녀가 거의 틀림없이 옳습니다. 가서 검색하세요. (좀 더 순한 버전은 “Google이 당신의 친구!”입니다.)
웹 포럼에서는 포럼 아카이브를 검색하라는 말도 들을 수 있습니다. 누군가는 심지어 이전에 이 문제가 해결된 글타래로의 포인터를 친절히 제공할 수도 있습니다. 하지만 이런 배려를 기대하지 마세요. 질문 전에 아카이브 검색을 하세요.
종종, 당신에게 검색하라고 하는 사람은 당신이 필요한 정보를 담은 매뉴얼이나 웹페이지를 열어, 그것을 보면서 타이핑하고 있습니다. 이런 답변은 응답자가 (a) 당신이 필요한 정보를 찾기 쉽다고 생각하며, (b) 누군가가 숟가락으로 떠먹여 주기보다 직접 찾아보는 편이 더 배운다고 생각함을 의미합니다.
여기에 기분 나빠하지 마세요. 해커 기준으로, 당신을 무시하지 않고 반응해 줬다는 사실 자체가 일종의 거친 존중 표시입니다. 이런 할머니 같은 친절에 감사해야 합니다.
답이 이해되지 않는다면, 즉각적으로 설명을 요구하는 반발을 하지 마세요. 원래 질문에 답을 찾으려고 사용했던 도구(매뉴얼, FAQ, 웹, 실력 있는 친구)를 이용해 답을 이해해 보세요. 그래도 설명이 필요하다면, 그 사이에 배운 것을 보여주며 질문하세요.
예를 들어, 제가 당신에게 “zentry가 걸린 것 같네요. 지워야 합니다.”라고 말했다고 합시다. 나쁜 후속 질문은 “zentry가 뭔가요?”입니다. 좋은 후속 질문은 “man 페이지를 읽었는데 zentry는 -z와 -p 스위치 아래에서만 언급됩니다. 둘 중 어느 것도 zentry 지우기에 대해 말하고 있지 않습니다. 둘 중 하나인가요, 아니면 제가 뭔가 놓치고 있나요?”입니다.
해커 문화의 무례해 보이는 것의 상당수는 모욕하려는 의도가 아닙니다. 오히려 문제 해결을 타인을 따뜻하고 포근하게 만드는 것보다 더 중시하는 사람들에게 자연스러운, 직설적이고 허튼소리를 잘라내는 소통 방식의 산물입니다.
무례함이 느껴질 때는 차분히 반응하도록 노력하세요. 누군가 정말 선을 넘고 있다면, 리스트/뉴스그룹/포럼의 상급자가 나서서 지적할 가능성이 매우 큽니다. 그게 일어나지 않았는데 당신이 화를 낸다면, 무례하다고 여긴 사람이 해커 커뮤니티 규범 내에서 행동했고 당신 이 잘못한 것으로 여겨질 가능성이 큽니다. 그러면 원하는 정보나 도움을 얻을 가능성이 줄어듭니다.
반대로, 정말 불필요한 무례함과 허세를 마주칠 때도 있습니다. 위의 뒤집개는 진짜 위반자를 날카롭게 후려치는 것이 용인된다는 뜻이기도 합니다. 날카로운 언어로 그들의 오행동을 해부하는 것이죠. 하지만 시도 전에 당신의 근거가 매우 탄탄한지 확인하세요. 무례함을 바로잡는 것과 쓸데없는 불화(플레임워)를 시작하는 것 사이의 경계는 얇아서, 해커 자신도 종종 넘나들곤 합니다. 당신이 뉴비나 외부인이라면 넘어질 확률이 높습니다. 정보가 목적이라면, 위험을 감수하기보다 손을 키보드에서 떼는 편이 낫습니다.
(일부는 많은 해커가 경미한 자폐 스펙트럼이나 아스퍼거 증후군을 갖고 있어, “정상” 인간의 사회적 상호작용을 윤활하는 뇌 회로 일부가 부족하다고 주장합니다. 사실 여부는 별개입니다. 당신이 해커가 아니라면, 우리를 뇌 손상자쯤으로 생각하는 것이 우리 괴벽을 견디는 데 도움이 될지도 모릅니다. 얼마든지 그렇게 생각하세요. 우리는 개의치 않습니다. 우리는 우리가 어떤 존재이든 그것을 좋아하며, 임상적 꼬리표에 대해 대체로 건전한 회의주의를 갖고 있습니다.)
Jeff Bigler의 tact filter(완곡필터) 관찰도 관련 있고 읽을 가치가 있습니다.
다음 절에서는, 당신이 잘못했을 때 보게 될 다른 종류의 “무례함”에 대해 이야기합니다.
해커 커뮤니티 포럼에서 당신은 아마 여러 번 실수할 겁니다—이 글에서 자세히 설명한 방식으로, 혹은 유사한 방식으로요. 그리고 당신은 공공연히, 때로는 화려한 곁가지와 함께, 어디서 어떻게 잘못했는지 지적받게 될 것입니다.
이럴 때 최악은 경험에 대해 푸념하고, 폭언을 당했다고 주장하고, 사과를 요구하고, 비명을 지르고, 숨을 참거나, 소송을 위협하고, 사람들의 고용주에게 항의하고, 변기 뚜껑을 올려 두는 등등의 행동입니다. 대신 이렇게 하세요.
극복하세요. 정상입니다. 사실 건강하고 적절합니다.
커뮤니티 규범은 저절로 유지되지 않습니다. 사람들이 이를 적극적으로 적용하고, 눈에 띄게, 공개적으로 유지됩니다. 모든 비판이 개인 이메일로 전달되어야 한다고 징징대지 마세요. 그렇게 작동하지 않습니다. 누군가가 당신의 주장 하나가 틀렸거나 관점이 다르다고 언급했을 때 개인적 모욕을 받았다고 우기는 것도 무익합니다. 그런 태도는 루저의 태도입니다.
지나치게 “친절한”(그런 식으로) 곳에서는, 참여자가 다른 이의 게시물에서 잘못을 지적하는 것이 금지되고 “사용자를 도울 의사가 없다면 아무 말도 하지 마라”고 말합니다. 그 결과, 알짜배기 참여자들이 떠나고, 남은 곳은 의미 없는 잡담으로 전락하여 기술 포럼으로서 무용지물이 됩니다.
과장되게 “친절한” 것과 유용한 것: 둘 중 하나를 고르세요.
기억하세요. 해커가 당신에게 실수를 지적하고(얼마나 퉁명스럽든) 다시는 그러지 말라고 말할 때, 그는 (1) 당신과 (2) 그의 커뮤니티를 걱정해서 그렇게 하는 겁니다. 그에게는 당신을 무시하고 삶에서 당신을 필터링하는 게 훨씬 더 쉽습니다. 감사할 수 없다면, 최소한 품위를 지키고, 징징대지 말고, 당신이 연극적으로 과민한 영혼과 권리의식을 가진 신참이라는 이유로 유리 인형처럼 대접받기를 기대하지 마세요.
때로는 당신이 실수하지 않았거나(혹은 그들의 상상 속에서만 실수했는데도) 개인적으로 공격당하고, 이유 없이 플레임을 당하는 경우도 있습니다. 이 경우, 불평하는 것이 진짜 실수하는 길입니다.
이런 플레임러들은 단서가 없으면서도 자신을 전문가라 믿는 라머(lamer)이거나, 당신이 실수를 할지 시험하는 의사 흉내쟁이일 뿐입니다. 다른 독자들은 그들을 무시하거나 나름대로 상대합니다. 그들의 행동은 그들 자신에게 문제를 만들며, 당신이 걱정할 일은 아닙니다.
플레임전에 끌려 들어가지도 마세요. 대부분의 플레임은 무시하는 게 최선입니다—그것이 진짜 플레임인지, 당신이 어디서 잘못했는지에 대한 포인터는 아닌지, 또는 당신의 진짜 질문에 대한 영리하게 암호화된 답은 아닌지 확인한 다음에요(이런 일도 있습니다).
다음은 전형적인 멍청한 질문과, 해커가 왜 답하지 않는지에 대한 생각입니다.
Q: 프로그램이나 자원 X는 어디에서 구하나요?Q: X를 사용해서 Y를 하는 방법은?Q: 셸 프롬프트를 어떻게 설정하나요?Q: AcmeCorp 문서를 Bass-o-matic 파일 컨버터로 TeX 파일로 바꿀 수 있나요?Q: 제 {프로그램, 구성, SQL문}이 작동하지 않습니다Q: 윈도우 머신에 문제가 있어요. 도와줄 수 있나요?Q: 제 프로그램이 작동하지 않습니다. 시스템 기능 X가 고장 난 것 같아요.Q: 리눅스나 X 설치에 문제가 있어요. 도와줄 수 있나요?Q: 루트 크랙/채널 운영권 탈취/남의 이메일 읽는 법은? **Q:**프로그램이나 자원 X는 어디에서 구하나요? **A:**나도 찾을 곳이지, 친구 — 웹 검색의 반대편. 세상에, 아직도 Google 쓰는 법을 모르는 사람이 있나? **Q:**X를 사용해서 Y를 하는 방법은? **A:**당신이 원하는 게 Y라면, 적절하지 않을 수도 있는 방법을 전제하지 말고 그 질문 자체를 하세요. 이런 형태의 질문은 종종 X에 대해 무지할 뿐 아니라 자신이 해결하려는 문제 Y가 무엇인지 혼란스럽고, 자신의 특정 상황의 디테일에 과도하게 집착하고 있음을 보여줍니다. 이런 사람들은 자신의 문제를 더 잘 정의하기 전까지 무시하는 것이 대개 최선입니다. **Q:**셸 프롬프트를 어떻게 설정하나요? **A:**이 질문을 할 정도로 똑똑하다면, RTFM해서 스스로 알아낼 만큼 똑똑합니다. **Q:**AcmeCorp 문서를 Bass-o-matic 파일 컨버터로 TeX 파일로 바꿀 수 있나요? **A:**직접 해보세요. 그렇게 했다면 (a) 답을 알게 되고, (b) 내 시간을 낭비하지 않게 됩니다. **Q:**제 {프로그램, 구성, SQL문}이 작동하지 않습니다 **A:**이건 질문이 아닙니다. 나는 당신의 실제 질문을 캐내려고 스무고개를 할 만큼 한가하지 않습니다. 보통 이런 걸 보면 다음 반응 중 하나입니다.
거기에 더 덧붙일 게 있나요?
아, 유감이네요. 잘 해결되길 바랍니다.
그래서 그게 나와 무슨 상관이 있지요? **Q:**윈도우 머신에 문제가 있어요. 도와줄 수 있나요? **A:**네. 그 마이크로소프트 쓰레기를 버리고 리눅스나 BSD 같은 오픈 소스 운영체제를 설치하세요.
참고: 공식 윈도우 빌드가 있는 프로그램이거나 윈도우 머신과 상호작용하는 프로그램(예: Samba)과 관련된 질문이라면 할 수는 있습니다. 다만, 문제가 프로그램이 아니라 윈도우에 있다는 답을 들어도 놀라지 마세요. 윈도우는 전반적으로 너무 고장 나 있어서 그런 경우가 매우 흔합니다. **Q:**제 프로그램이 작동하지 않습니다. 시스템 기능 X가 고장 난 것 같아요. **A:**수백/수천 명이 쓰는 시스템 호출과 라이브러리의 명백한 결함을 당신이 최초로 발견했을 가능성도 있지만, 당신이 전혀 감을 못 잡고 있을 가능성이 훨씬 큽니다. 비범한 주장은 비범한 증거를 요구합니다. 이런 주장을 할 때는 실패 사례에 대한 명확하고 철저한 문서를 뒷받침해야 합니다. **Q:**리눅스나 X 설치에 문제가 있어요. 도와줄 수 있나요? **A:**아니요. 이건 문제 해결을 위해 당신의 머신에 직접 접근해야 합니다. 손을 써 줄 수 있는 현지 리눅스 사용자 그룹에 물어보세요. (사용자 그룹 목록은 여기에서 찾을 수 있습니다.)
참고: 특정 배포판에 관한 포럼이나 메일링 리스트에서, 그리고 문제가 그 배포판에 관한 것이라면 리눅스 설치 질문이 적절할 수 있습니다. 또는 지역 사용자 그룹 포럼에서도요. 이 경우 실패의 정확한 세부를 반드시 설명하세요. 하지만 먼저 “linux”와 의심스러운 모든 하드웨어 조각을 포함해 꼼꼼히 검색하세요. **Q:**루트 크랙/채널 운영권 탈취/남의 이메일 읽는 법은? **A:**그런 일을 하고 싶어 하는 당신은 저열하고, 해커에게 그런 도움을 청하는 당신은 바보입니다.
마지막으로, 같은 문제에 대한 질문 쌍을 통해 현명하게 질문하는 방법을 예시합니다. 하나는 바보같이, 다른 하나는 현명하게 묻는 방식입니다.
멍청한: Foonly Flurbamatic에 대한 정보를 어디에서 찾을 수 있나요? 이 질문은 답으로 곧장 “STFW”를 부릅니다.
현명한: 웹에서 “Foonly Flurbamatic 2600”을 구글링했지만 유용한 결과를 얻지 못했습니다. 이 기기에 대한 프로그래밍 정보를 가리키는 포인터를 받을 수 있을까요? 이 질문은 이미 STFW했고, 실제 문제가 있을 수도 있음을 암시합니다.
멍청한: 프로젝트 foo의 코드를 컴파일할 수 없습니다. 왜 고장 났죠? 질문자가 누군가 다른 사람이 망쳤다고 가정합니다. 거만한 녀석…
현명한: 프로젝트 foo의 코드는 Nulix 6.2에서 컴파일되지 않습니다. FAQ를 읽었지만 Nulix 관련 문제에 대한 내용은 없습니다. 제 컴파일 시도 로그를 첨부합니다. 제가 뭘 잘못한 걸까요? 질문자는 환경을 명시했고, FAQ를 읽었고, 오류를 보여주었으며, 자신의 문제가 남의 탓이라고 가정하지 않습니다. 이 질문은 관심을 받을 만합니다.
멍청한: 제 메인보드에 문제가 있습니다. 아무나 도와줄 수 있나요? J. Random Hacker의 반응은 아마 “그렇죠. 트림과 기저귀도 필요하신가요?”일 것이고, 이어서 삭제 키가 눌릴 겁니다.
현명한: S2464 메인보드에서 X, Y, Z를 시도했습니다. 되지 않아 A, B, C도 시도했습니다. C를 시도했을 때의 이상한 증상을 주목하세요. 분명 플로비시가 그롬미킹하고 있는데, 결과가 예상과 다릅니다. Athlon MP 메인보드에서 그롬미킹의 일반적 원인은 무엇인가요? 문제를 특정하기 위해 더 할 수 있는 테스트가 있을까요? 이 사람은 답을 받을 만합니다. 그는/그녀는 높은 수준의 문제 해결 지능을 보여주었고, 하늘에서 답이 떨어지기를 수동적으로 기다리지 않았습니다.
마지막 질문에서, “답을 주세요”라는 요구와 “깨달음에 이르기 위해 추가로 할 수 있는 진단을 알려 주세요”라는 요청 사이의 미묘하지만 중요한 차이를 주목하세요.
사실, 마지막 질문의 형태는 2001년 8월 linux-kernel 메일링 리스트(lkml)에서 실제로 일어난 사건을 바탕으로 합니다. 그때 질문한 사람은 저(에릭)였습니다. 저는 Tyan S2462 메인보드에서 이상한 멈춤을 보고 있었습니다. 리스트 구성원들이 그것을 해결하는 데 필요한 핵심 정보를 제공해 주었습니다.
제가 그런 방식으로 질문함으로써, 사람들에게 씹을 거리를 주었습니다. 그들이 관여하기 쉽고 매력적으로 만들었습니다. 저는 동료들의 능력을 존중하고 동등한 입장에서 자문을 구했습니다. 또한 이미 달려본 막다른 길을 말해 그들의 시간을 존중했습니다.
그 후 모두에게 감사하며 이 과정이 얼마나 잘 작동했는지 언급했을 때, 한 lkml 구성원이 이렇게 작동한 것은 제가 그 리스트의 “이름”이어서가 아니라, 제가 올바른 형식으로 질문했기 때문이라고 관찰했습니다.
해커는 어떤 면에서는 매우 무정한 능력주의자입니다. 저는 그가 옳았다고 확신합니다. 내가 스펀지처럼 행동했다면 내가 누군지와 상관없이 비난받거나 무시당했을 겁니다. 그의 제안—이 사건 전체를 다른 이의 교훈이 되도록 글로 쓰라—이 곧바로 이 가이드를 쓰게 했습니다.
답을 얻지 못했다면, 우리가 도울 수 없다고 느낀다고 해서 개인적으로 받아들이지 마세요. 때로는 묻는 그룹의 구성원들이 단순히 답을 모를 수 있습니다. 무응답은 무시와 같지 않습니다. 외부에서는 구분이 어렵겠지만요.
일반적으로, 질문을 그냥 재게시하는 것은 좋지 않습니다. 이는 쓸데없이 성가시게 보일 것입니다. 인내하세요. 답을 가진 사람은 다른 시간대에서 자는 중일 수도 있습니다. 또는 처음부터 질문이 잘 형성되지 않았을 수도 있습니다.
초보자의 필요에 더 잘 맞는 다른 도움 자원이 있습니다.
직접 소프트웨어를 쓰지는 않았더라도, 소프트웨어에 열정적인 온라인 및 지역 사용자 그룹이 많이 있습니다. 이런 그룹은 종종 서로 돕고 신규 사용자를 돕기 위해 구성됩니다.
또한 크고 작은 상용 회사들도 도움을 유료로 제공합니다. 도움에 돈을 내야 한다는 생각에 낙담하지 마세요! 자동차 엔진 헤드 개스킷이 터지면, 정비소에 가져가 수리비를 지불하듯이요. 소프트웨어가 공짜였다 해도, 지원이 항상 공짜일 거라고 기대할 수는 없습니다.
리눅스처럼 인기 있는 소프트웨어의 경우, 개발자 1명당 사용자 1만 명은 넘습니다. 1만 명이 넘는 사용자의 지원 전화를 한 사람이 감당하는 것은 불가능합니다. 지원에 비용을 지불해야 하더라도, 소프트웨어 구매 비용까지 치렀을 때보다 훨씬 적다는 점을 기억하세요(그리고 폐쇄형 소프트웨어의 지원은 보통 오픈 소스보다 더 비싸고 덜 유능합니다).
부드럽게. 문제와 관련된 스트레스는 사람을 무례하거나 멍청해 보이게 만들 수 있습니다. 실제로 그렇지 않더라도요.
첫 위반자에게는 비공개로 회신하세요. 정직한 실수를 저질렀을지도 모르는 사람을 공개적으로 망신 줄 필요는 없습니다. 진짜 뉴비는 아카이브 검색법이나 FAQ 위치를 모를 수 있습니다.
확실하지 않다면, 모른다고 하세요! 그럴듯하게 들리지만 틀린 답은 아무 답도 없는 것보다 나쁩니다. 전문가처럼 들리는 재미 때문에 엉뚱한 길로 사람을 이끌지 마세요. 겸손하고 정직하세요. 질문자와 동료 모두에게 좋은 본보기가 됩니다.
도울 수 없다면, 방해하지 마세요. 사용자의 설정을 망칠 수도 있는 농담을 하지 마세요. 불쌍한 사람이 그걸 지시로 받아들일 수도 있습니다.
더 많은 세부사항을 이끌어내는 탐색 질문을 하세요. 잘하면 질문자가 무언가를 배울 것이고, 당신도 그럴 수 있습니다. 나쁜 질문을 좋은 질문으로 바꿔 보세요. 우리 모두 한때는 뉴비였다는 것을 기억하세요.
게으른 사람에게 RTFM을 중얼거리는 것이 정당할 때도 있지만, 문서로 가는 포인터(핵심 구문을 구글링하라는 제안만이라도)가 더 낫습니다.
어차피 답할 거라면, 값지게 답하세요. 누군가가 잘못된 도구나 접근을 사용하고 있을 때 조잡한 임시방편을 제안하지 마세요. 좋은 도구를 제안하세요. 질문을 재구성하세요.
실제 질문에 답하세요! 질문자가 자신의 연구를 충분히 했고, 쿼리에 X, Y, Z, A, B, C를 이미 시도했지만 효과가 없었다고 포함했다면, “A나 B를 시도해 보세요”라고 답하거나 “X, Y, Z, A, B, C를 시도해 보라”고만 말하는 링크를 보내는 것은 극도로 비도움입니다.
커뮤니티가 질문에서 배우도록 도우세요. 좋은 질문을 처리할 때, “관련 문서나 FAQ가 어떻게 바뀌면 아무도 이걸 다시 답할 필요가 없을까?”를 자문하세요. 그런 다음 문서 유지자에게 패치를 보내세요.
답을 찾기 위해 조사를 했다면, 엉덩이에서 답을 뽑아낸 것처럼 쓰지 말고 당신의 기술을 보여 주세요. 좋은 질문 하나에 답해 주는 것은 굶주린 사람에게 한 끼를 먹이는 것과 같지만, 예시로 연구 기술을 가르치는 것은 평생 먹을 거리를 키우는 법을 가르치는 것과 같습니다.
Evelyn Mitchell은 바보 같은 질문 예시 일부를 제공했고 “좋은 답을 주는 법” 섹션에 영감을 주었습니다. Mikhail Ramendik은 특히 가치 있는 개선 제안을 제공했습니다.
