원문 링크: http://www.catb.org/~esr/faqs/smart-questions.html
Revision 3.10 버전을 기준으로 작성되었습니다.
여러분의 참여가 큰 도움이 됩니다.
Issues와 Pull requests를 통해 더 나은 번역에 함께 해주세요.
- 면책 조항
- 서론
- 질문하기 전에
- 질문할 때
- 어느 포럼에 질문할 지 신중히 고르세요
- Stack Overflow
- 웹 및 IRC 포럼
- 두 번째 단계로, 프로젝트 메일링 목록을 사용하세요
- 의미있고 구체적인 제목을 사용하세요
- 답변하기 쉽도록 하세요
- 명확하고, 문법적으로 옳으며, 오타가 없도록 작성하세요
- Send questions in accessible, standard formats
- 당신이 마주친 문제 상황에 대한 정확한 정보를 제공하세요
- 양으로 승부하지 마세요
- 버그를 찾았다고 성급히 주장하지 마세요
- 당신이 자신을 낮춘다고 우리가 숙제를 대신 해주지는 않을 겁니다
- 당신의 추측 말고 실제로 발생한 현상만 알려주세요
- 발생한 현상을 시간 순서대로 알려주세요
- 과정이 아니라 당신이 원하는 목표를 알려주세요
- 개인 이메일로 답변을 요구하지 마세요
- 명시적으로 질문하세요
- 당신이 작성한 코드에 대해 질문할 때
- 숙제를 올리지 마세요
- 쓸데없는 문구는 넣지 마세요
- 당신이 진짜 급하더라도 "급합니다" 같은 문구는 넣지 마세요
- 예의를 갖추는 것은 절대로 손해보는 일이 아닙니다
- 문제가 해결되었다면 이를 알려주세요
- 답변을 이해하는 법
- RTFM과 STFW: How To Tell You've Seriously Screwed Up
- 답변이 이해가 안 간다면...
- 답변이 무례하게 느껴진다면
- 루저처럼 반응하지 않기
- 하지 말아야 할 질문
- 좋은 질문과 나쁜 질문
- 당신이 답변을 받지 못한다면
- 도움이 되는 방식으로 질문하는 법
- 연관 자료
- 감사의 말
많은 프로젝트 웹사이트에서 도움 받는 방법 섹션에 이 문서로의 링크를 걸어 놓습니다. 좋습니다. 그게 이 문서의 목적이니까요. 하지만 당신이 프로젝트 웹사이트 운영자이며 이 문서로 링크를 걸고자 한다면, 제발 우리는 당신 프로젝트의 안내 데스크가 아니라는 것을 링크 근처에 눈에 띄게 표시해주세요.
그러한 공지가 없으면, 우리는 이 문서를 작성했다는 이유만으로 우리가 온 세상의 기술적인 문제를 다 해결해야 한다고 생각하는 바보들에게 끊임없이 시달리게 된다는 것을 배웠습니다.
만약 당신이 도움이 필요하기 때문에 이 문서를 읽게 되었고, 이 문서의 저자들이 당신을 도울 수 있을 것이라고 생각했다면, 바로 당신이 우리가 방금 언급한 바보인 겁니다. 우리한테 질문하지 마세요. 우리는 당신을 무시할 겁니다. 우리가 이 문서를 작성하는 건 당신이 쓰는 소프트웨어 혹은 하드웨어에 대해 잘 아는 사람들에게서 도움을 받는 방법을 알려주기 위해서인데, 그 "잘 아는 사람"은 99.9%의 경우에 우리가 아닙니다. 당신이 이 문서의 저자 중 한 명이 당신이 원하는 전문가라는 것을 확실히 아는 것이 아니라면, 모두의 행복을 위해 제발 우리를 가만히 내버려두세요.
해커의 세계에서 기술적인 질문에 대해 당신이 받게 되는 답변의 종류는 당신이 질문을 하는 방식만큼이나 답변을 만드는 난이도에 달려 있습니다. 이 가이드는 당신이 만족스러운 답변을 얻을 가능성이 높아지도록 질문하는 방법을 알려줍니다.
오픈 소스의 사용이 널리 퍼지면서, 질문에 대한 좋은 답변을 해커뿐 아니라 숙련된 사용자에게서도 많이 받을 수 있습니다. 이건 좋은 일이죠. 사용자는 초보자들이 자주 겪는 실수에 대해 조금 더 관대한 경향이 있습니다. 그러나 답변자가 숙련된 사용자더라도 이 글에서 제시하는 방법으로 해커처럼 대하는 것이 일반적으로 유용한 답변을 얻을 수 있는 가장 효과적인 방법입니다.
가장 먼저 이해해야 할 것은 해커는 어려운 문제와 생각을 불러일으키는 좋은 질문을 정말 좋아한다는 것입니다. 질문을 싫어했다면 굳이 여기에 있지 않았을 겁니다. 당신이 흥미로운 질문을 준다면 정말 고마울 겁니다. 좋은 질문은 상쾌한 자극이고 선물이니까요. 좋은 질문은 우리의 이해를 증진시키고, 생각해보지 않았거나 알아차리지 못했던 문제를 드러냅니다. 해커들 사이에서 "좋은 질문입니다!" 라는 말은 진심 어린 칭찬입니다.
그럼에도 불구하고 해커는 간단한 질문에도 적대감이나 오만함을 드러내며 답변한다는 이미지가 있습니다. 어떨 때는 우리가 초보자와 이 분야를 처음 접하는 사람만 보면 무례하게 대하는 것처럼 보이기도 합니다. 하지만 이건 사실이 아닙니다.
우선 우리는 당연히 질문하기 전에 스스로 생각도 해보지 않는 사람과 숙제를 스스로 하지도 않는 사람에게 적대적입니다. 그런 사람들은 그저 시간 낭비입니다. 받기만 하고 주는 건 없으며, 우리가 더 흥미롭고 대답할 가치가 있는 다른 질문에 쓸 수 있었을 시간을 빼앗습니다. 우리는 이런 사람들을 "루저"라고 부르기로 약속했어요.
당장 우리가 만든 프로그램을 쓰는 것이 중요하고 기술적인 세부 사항을 배우는 것에는 큰 관심이 없는 사람이 많다는 걸 우리도 잘 압니다. 대부분의 사람들에게 컴퓨터는 그저 도구일 뿐입니다. 해야 할 더 중요한 일이 있고 살아야 할 삶이 있지요. 우리는 그걸 존중하며 우리가 열광하는 기술적인 문제에 모든 사람들이 관심을 가질거라 기대하지 않습니다. 그렇지만 우리는 그런 관심을 가지고 문제 해결에 적극적으로 참여하고자 하는 사람들에 맞추어 답변을 할 겁니다. 그리고 그건 안 바뀔겁니다. 바뀌어서는 안되고요. 만약 바뀐다면 우리는 우리가 가장 잘 하는 일에 약해지게 될겁니다.
우리는 (대부분) 자원 봉사자입니다. 우리는 바쁜 삶 와중에 시간을 내어 질문에 답하고, 때로는 넘쳐나는 질문에 압도됩니다. 그래서 우리는 무자비하게 걸러냅니다. 구체적으로, 우리는 루저로 보이는 사람들의 질문을 걸러서 대부분의 시간을 위너의 질문에 효율적으로 답변할 수 있도록 합니다.
이러한 태도가 불쾌하거나, 거만하거나 혹은 잘난 체하는 것처럼 보인다면 당신의 가정을 다시 확인하세요. 우리는 당신에게 납작 엎드리라고 말하는 게 아닙니다. 사실 우리 대부분은 당신이 적절한 노력을 기울인다면 우리의 문화로 반갑게 맞이하고 동등하게 대할 것입니다. 하지만 스스로를 도우려 하지 않는 사람을 도우려 애쓰는 것은 우리에게 그저 비효율적일 뿐입니다. 모르는 건 괜찮지만, 바보같이 구는 건 괜찮지 않습니다.
그러니까 우리의 주목을 받기 위해 기술적으로 유능할 필요는 없지만, 유능함으로 이어지는 태도, 즉 주의 깊고, 사려 깊고, 관찰하고, 솔루션 개발에 적극적으로 참여하는 태도를 보여줄 필요는 있습니다. 당신이 이런 종류의 차별을 못 견디겠다면 우리에게 개인적으로 기부를 요구하는 대신 돈을 내고 상업적 지원을 받는 것을 추천합니다.
당신이 우리에게 도움을 청하기로 결정했다면, 루저가 되지 마세요. 루저처럼 보이지도 마세요. 빠르고 긍정적인 답변을 받는 가장 좋은 방법은 똑똑하고 자신감 있으며 그저 특정 문제에 대해 도움이 필요한 사람처럼 질문하는 것입니다.
(이 문서의 개선 요청은 언제든지 환영입니다. esr@thyrsus.com 또는 respond-auto@linuxmafia.com 으로 제안 사항을 보내주세요. 다만 이 문서는 네티켓에 대한 일반적인 가이드가 아니며, 기술 포럼에서 유용한 답변을 도출하는 것과 특별한 관련이 없는 제안은 일반적으로 거부합니다.)
기술적인 질문을 이메일이나 뉴스 그룹, 혹은 웹사이트 채팅창에 올리기 전에 다음을 수행하세요.
- 글을 올리기로 마음먹은 포럼의 아카이브나 메일링 리스트에 답이 있는지 먼저 검색하세요.
- 인터넷 검색을 통해 답이 나오는지 확인하세요.
- 매뉴얼에 답이 있는지 확인하세요.
- FAQ에 답이 있는지 확인하세요.
- 관찰과 실험을 통해 답을 찾을 수 있는지 확인하세요.
- 잘 아는 친구한테 물어보세요.
- 당신이 프로그래머라면, 소스 코드를 읽어보고 답이 나오는지 확인하세요.
질문할 때 당신이 이를 이미 했다는 사실을 알려주세요. 이를 통해 당신이 사람들의 시간을 낭비하는 게으름뱅이가 아니라는 걸 확인할 수 있습니다. 더 나은 방법은 당신이 이를 통해 무얼 배웠는지를 보여주는 겁니다. 우리는 답변에서 배울 수 있는 사람을 위해 답변하는 것을 좋아합니다.
당신이 얻은 오류 메시지를 그대로 구글(구글 그룹과 웹 페이지 포함)에 검색하세요. 어쩌면 오류를 수정하는 방법을 알려주는 문서 혹은 메일링 리스트를 바로 찾아낼 수도 있습니다. 그렇지 않더라도 이메일이나 뉴스 포스팅에서 도움을 요청할 때 "다음 문구를 구글에 검색해봤지만 유용한 결과를 얻지 못했습니다" 라고 말해주는 건 도움이 됩니다. 첫째로 어떤 검색어가 도움이 안되는지에 대한 정보를 제공해주며, 둘째로 당신이 사용한 검색어가 당신이 만든 글타래와 연결되어 비슷한 문제를 겪는 다른 사람들이 당신의 질문 및 답변 글타래로 안내받을 수 있도록 합니다.
천천히 하세요. 단 몇 초의 구글링으로 복잡한 문제가 풀릴거라 기대하지 마세요. 전문가에게 물어보기 전에 우선 FAQ를 읽고 이해해보고, 편히 앉아 긴장을 풀고 문제에 대해 생각해보세요. 당신이 얼마나 찾아보고 생각해봤는지는 질문에 다 드러납니다. 당신이 준비가 되어있다면 더욱 기꺼이 도와주려 할겁니다. 첫 번째 검색에서 답을 얻지 못했다고 (혹은 너무 과도하게 얻었다고) 바로 질문 폭격을 날리지 마세요.
질문을 차분히 정리하세요. 깊게 생각하세요. 성급하게 들리는 질문은 성급한 답변을 얻거나, 전혀 얻지 못합니다. 당신이 문제를 해결하기 위해 얼마나 많은 생각과 노력을 기울였는지 보여줄수록 실제로 도움을 받을 가능성이 높아집니다.
잘못된 질문을 하지 않도록 유의하세요. 잘못된 가정에 기반한 질문을 하면 해커 아무개씨는 당신에게 실제로 도움이 되지 않는, 하지만 질문 그 자체에 대한 답변을 해줄겁니다. 그리고 속으로 "멍청한 질문같으니..." 라고 생각하면서 당신이 실제로 필요한 답변이 아닌 질문 그 자체에 대한 답변을 얻는 경험을 통해 속쓰린 교훈을 얻기를 기대할 겁니다.
당신에게 답변을 받을 자격같은 게 있다고 착각하지 마세요. 그런 건 없습니다. 애초에 당신은 돈을 내고 서비스를 받고 있는 게 아닙니다. 당신이 답변을 받는다면, 그건 다른 이의 지식을 수동적으로 요구하는 것이 아니라 실질적이고 흥미롭고 생각을 불러 일으키는 질문을 통해 커뮤니티 전체의 경험에 기여했기 때문입니다.
반면에 당신이 해결책을 만드는 과정에 적극적으로 참여할 수 있다는 의지와 노력을 보여주는 것은 아주 좋은 시작입니다. "정확히 어떻게 해야 하는지 알려주세요." 같은 질문 보다는 "혹시 관련된 자료는 어디서 찾을 수 있나요?", "제 예시에서 빠진 게 뭐죠?", "어떤 사이트를 찾아봐야 하나요?" 같은 질문이 답변을 받을 가능성이 높습니다. 누군가 올바른 방향만 알려준다면 당신이 진정으로 이 과정을 마칠 의지가 있다는 것이 명확히 드러나기 때문입니다.
어디에 질문을 올릴지 정말 잘 고르세요. 만약 당신이 아래와 같이 질문한다면, 당신은 무시당하거나 루저로 취급당할 가능성이 높습니다.
- 다른 주제를 다루는 포럼에 질문을 올리는 경우
- 고급 기술 질문을 다루는 포럼에 아주 기초적인 질문을 올리는 경우나 그 반대의 경우
- 너무 많은 뉴스 그룹에 동일한 질문을 올리는 경우
- 당신의 지인도 아니고 당신의 문제를 해결해줘야 할 책임도 없는 사람한테 개인적으로 이메일을 보내는 경우
해커는 그들의 커뮤니케이션 채널이 쓸모없는 글에 침식되지 않도록 잘못 올라온 질문은 날려버립니다. 그런 일이 당신에게 일어나길 원하진 않겠죠.
그러니 당연히 첫 번째 단계는 올바른 포럼을 찾는 겁니다. 다시 말하지만 구글(그리고 다른 웹 검색 방법들)과 친해지세요. 이를 이용해서 당신을 괴롭히고 있는 하드웨어 혹은 소프트웨어와 가장 연관된 프로젝트 웹 페이지를 찾아내세요. 보통 그 페이지에는 FAQ(Frequently Asked Questions: 자주 묻는 질문) 목록과 프로젝트 메일링 리스트, 그리고 아카이브의 링크가 있을 겁니다. 이 메일링 리스트는 당신 스스로의 노력 (당신이 방금 찾아낸 FAQ를 전부 읽어보는 것을 포함)을 통해서 답을 찾지 못했을 때 마지막으로 도움을 요청하러 갈 곳입니다. 프로젝트 웹 페이지에 버그 보고 절차, 혹은 그에 대한 링크가 있을 수도 있습니다. 그렇다면 그 절차를 따르세요.
당신이 익숙하지 않은 사람이나 포럼에 이메일을 보내는 건 가장 위험합니다. 유익한 웹 페이지를 만든 사람이라고 해서 그 사람이 당신의 무료 컨설턴트가 되길 원한다고 가정하지 마세요. 당신의 질문이 환영받을거라고 낙관적으로 생각하지 마세요. 확실하지 않다면, 다른 곳에 보내거나 그냥 아예 보내지 마세요.
웹 포럼, 뉴스 그룹 혹은 메일링 리스트를 고를 때, 이름만 가지고 판단하지 마세요. FAQ나 헌장을 찾아보고 당신의 질문이 실제로 다루어지는 곳이 맞는지 확인하세요. 글을 올리기 전에 백트래픽을 조금 읽어본담녀 그곳에서 일이 어떻게 돌아가는지 감을 잡을 수 있습니다. 미리 당신의 문제와 관련된 키워드를 뉴스 그룹이나 메일링 리스트 아카이브에서 검색해보는 것은 큰 도움이 될 겁니다. 이를 통해 답을 찾을 수도 있고, 그렇지 않더라도 질문을 정제하는 데 도움이 됩니다.
가능한 모든 도움말 채널에 글을 마구 써대지 마십시오. 이는 마치 공공장소에서 소리를 지르는 것과 같고, 사람들을 짜증나게 합니다. 부드럽게 접근하세요.
당신의 토픽이 뭔지 알아야 합니다. 흔히 하는 실수 중 하나는 유닉스 혹은 윈도우 프로그래밍 인터페이스를 둘 모두에서 사용할 수 있는 언어/라이브러리/툴 관련 포럼에 올리는 겁니다. 이게 왜 문제인지 이해가 안 간다면, 이해가 갈 때까지 질문을 올리지 마세요.
일반적으로, 같은 질문이라면 공개 포럼에 올리는 것이 비공개 포럼에 올리는 것보다 유용한 답변을 얻을 가능성이 더 큽니다. 여러 이유가 있는데, 우선 단순히 잠재적 답변자의 수에 차이가 있기 때문이고 그 다음으로 청중의 수가 다르기 때문입니다. 해커는 더 많은 사람에게 유용한 지식을 전달할 수 있기를 원하니까요.
숙련된 해커와 유명한 소프트웨어의 개발자들은 받지 않았어야 할 메시지의 홍수에 시달리고 있습니다. 어쩌면 당신의 메시지가 낙타의 등을 부러뜨리는 마지막 지푸라기가 될지도 모릅니다. 개인 이메일 계정에 쓸모없는 이메일이 너무 많이 와서 이를 견디지 못한 유명 프로젝트의 기여자들이 지원을 철회한 경우도 종종 있었습니다.
먼저 검색하고 그 다음에 Stack Exchange에 질문을 올리세요.
최근 몇 년동안 Stack Exchange 사이트는 기술 및 기타 질문에 답하는 주요 커뮤니티가 되었고, 심지어 이제는 많은 오픈 소스 프로젝트에서 선호하는 포럼이 되었습니다.
Stack Exchange를 살펴보기 전에 구글 검색부터 하세요. 구글은 실시간으로 색인을 만듭니다. 아주 높은 확률로 누군가가 이미 비슷한 질문을 했을 것이며, 많은 경우 Stack Exchange 사이트가 검색 결과 상단에 위치합니다. 구글 검색으로 아무 것도 못 찾았다면, 당신의 질문과 가장 관련 있는 특정 사이트에서 다시 검색하세요 (아래 참조). 태그 기능을 활용하면 검색 결과를 좁혀나갈 수 있습니다.
여전히 아무 것도 못 찾았다면, 가장 연관 있는 사이트에 질문을 게시하세요. 포맷팅 도구를 쓰세요. 특히 코드를 올리는 경우라면, 반드시 포맷팅 도구를 쓰세요. 그 다음, 질문의 내용과 관계가 있는 태그를 추가하세요(당신이 문제를 겪고 있는 프로그래밍 언어, 운영체제 혹은 라이브러리). 더 많은 정보를 요청하는 댓글이 달린다면, 질문 글 수정을 통해 해당 내용을 추가하세요. 어느 답변이든 도움이 되었다면 추천 버튼을 눌러주세요. 어떤 답변이 당신 문제에 대한 해결책을 주었다면, 투표 버튼 아래에 있는 체크 버튼을 눌러 답변을 채택하세요.
Stack Exchange는 100개가 넘는 사이트로 성장했지만, 많은 경우 당신은 아래에 소개한 곳에 질문을 올리게 될 겁니다.
- Super User는 범용 컴퓨팅에 관한 질문을 올리는 곳입니다. 당신의 질문이 코드나 프로그램에 관한 것이 아니라 단순히 네트워크 연결을 통해 작동하는 경우라면 아마도 여기에 올리는 게 맞을 겁니다.
- Stack Overflow는 프로그래밍에 관한 질문을 올리는 곳입니다.
- Server Fault는 서버와 네트워크 관리에 대한 질문을 올리는 곳입니다.
안드로이드, 우분투, TeX와 LaTeX, SharePoint 등의 프로젝트는 이를 위한 자체 사이트를 가지고 있습니다. Stack Exchange 사이트에서 최신 목록을 확인하세요.
당신이 속한 로컬 사용자 그룹 또는 당신이 사용하는 리눅스 배포판 커뮤니티에서 초보자들이 도움을 얻을 수 있는 웹 포럼 혹은 IRC 채널을 홍보할 수도 있습니다(영어를 모국어로 사용하지 않는 나라에서는 초보자용 포럼이 여전히 메일링 리스트일 확률이 높습니다). 이런 곳은 처음으로 질문을 올리기에 좋은 곳입니다. 만약 당신이 생각하기에 이 문제가 상대적으로 쉽거나 흔한 문제라고 보인다면 더욱 그렇습니다. 널리 홍보된 IRC 채널은 질문을 올리라고 활짝 열린 곳이고 실시간으로 답변을 받게 되는 경우도 종종 있습니다.
사실, 만약 당신이 문제를 겪고 있는 프로그램을 리눅스 배포판에서 얻었다면 (최근에는 매우 흔한 경우죠), 해당 프로그램의 프로젝트 포럼에 질문을 올리는 것보다 해당 리눅스 배포판의 포럼에 질문을 올리는 것이 나을 수 있습니다. 해당 프로그램 프로젝트의 해커는 단순히 "우리가 만든 빌드를 쓰세요" 라고 할 수도 있습니다.
웹 포럼에 글을 올리기 전에, 검색 기능이 있는지 확인하세요. 만약 있다면, 당신의 문제와 연관된 키워드를 몇 개 검색해보세요. 도움이 될 수도 있습니다. 웹 검색을 이미 했더라도 (이미 했어야 하고요), 그래도 포럼에서 한 번 더 검색해보세요. 당신이 사용한 웹 검색 엔진이 이 포럼을 최근에 색인하지 않았을 수도 있습니다.
최근 들어 많은 프로젝트가 이메일은 질의응답 대신 개발에 사용하고, 웹 포럼 또는 IRC 채널에서 사용자 지원을 수행하는 경향이 있습니다. 그러니 프로젝트에 대한 도움이 필요하다면 이런 채널을 먼저 찾아보세요.
IRC에서는 한번에 문제 상황을 길게 서술해서 채널에 올리지 않는 것이 좋습니다. 어떤 사람들은 이를 도배라고 생각합니다. 문제를 한 줄로 요약해서 올리는 것으로 대화를 시작하는 것이 좋습니다.
프로젝트에 메일링 리스트가 있다면 개발자 개인이 아니라 메일링 리스트에 질문을 올리세요. 누가 당신의 질문에 가장 잘 대답해줄 수 있을지 당신이 알고 있다고 믿어도 말입니다. 프로젝트 문서와 홈페이지를 통해 프로젝트 메일링 리스트를 찾고 거기로 질문을 보내면 됩니다. 왜 그래야 할까요?
-
한 명의 개발자에게 좋은 질문이라면 그룹 전체에도 좋은 질문입니다. 반대로 말해서, 당신의 질문이 메일링 리스트에 올리기에는 멍청해보일까봐 걱정되는 거라면, 그게 개발자 개인을 괴롭히는 변명이 될 수는 없습니다.
-
메일링 리스트에 질문을 보내면 개발자들이 업무 부담을 잘 분배할 수 있습니다. 개발자 개인은 (특히 프로젝트 리더라면) 당신의 질문에 답하기에는 너무 바쁠 수 있습니다.
-
대부분의 메일링 리스트는 보존되며 검색 엔진에 의해 색인됩니다. 당신이 질문이 메일링 리스트를 통해 답변을 받는다면, 미래의 질문자는 이를 또 질문하는 대신 웹 검색을 통해 찾을 수 있게 됩니다.
-
특정 종류의 질문이 자주 올라오는 것이 발견된다면 개발자들은 이 정보를 활용해 문서 또는 소프트웨어 자체를 개선하여 혼동을 줄일 수 있습니다. 하지만 이런 질문들이 사적으로 주어진다면, 사람들이 어떤 질문이 자주 하는지에 대한 큰 그림을 아무도 그려볼 수 없게 됩니다.
만약 프로젝트가 "유저"와 "개발자" (혹은 "해커") 메일링 리스트(포럼)를 모두 가지고 있고 당신이 코드를 해킹하고 있는 게 아니라면 질문은 "유저" 메일링 리스트(포럼)에 올리세요. 당신이 개발자 메일링 리스트에 질문을 올린다면 환영받기보단 개발자간의 소통을 방해하는 소음으로 취급될 가능성이 높습니다.
하지만 당신의 질문이 사소한 게 아니라고 정말로 확신하고, "유저" 메일링 리스트(포럼)에서 며칠째 답변을 받지 못하고 있다면, "개발자" 메일링 리스트(포럼)에 올려보는 것을 시도해보세요. 질문을 올리기 전에 며칠 정도 지켜보거나 최소한 지난 며칠동안 보관된 메시지를 살펴보면서 그들이 소통하는 방식을 배우는 것이 좋습니다 (이는 사실 모든 종류의 사적인 메일링 리스트에 해당되는 조언입니다).
만약 당신이 프로젝트 메일링 리스트의 주소를 못 찾았고, 그 대신 프로젝트 관리자의 주소밖에 찾지 못했다면, 관리자에게 메일을 보내세요. 하지만 그런 경우라도 메일링 리스트가 없다고 가정하지는 마세요. 메일링 리스트를 찾으려 시도했지만 찾을 수 없었다는 사실을 언급하세요. 또한, 당신의 메일이 다른 사람들에게 포워딩 되어도 상관 없다는 사실을 언급하세요. (많은 사람들은 개인 이메일이라면 거기에 특별한 비밀 내용이 없더라도 공개되지 말아야 한다고 생각합니다. 당신의 메일이 포워딩되는 것을 허락함으로써 수신자에게는 메일에 어떻게 대응할 지에 대한 선택지가 생깁니다)
메일링 리스트, 뉴스 그룹 또는 웹 포럼에서 게시글의 제목은 단 50자 이내로 검증된 전문가의 관심을 끌 수 있는 소중한 기회입니다. 이를 "도와주세요" (혹은 "제발 도와주세요!!!" 같은 제목이라면 조건 반사로 삭제될 겁니다) 같은 쓸데없는 문구로 낭비하지 마세요. 고뇌의 깊이로 우리를 감동시키려 하지 말고, 그 자리에 매우 간결한 문제 설명을 쓰세요.
많은 기술 지원 조직에서 사용되는 좋은 제목 양식은 "대상-변동" 구조입니다. "대상" 부분은 무엇이 문제인지를 서술하고, "변동" 부분은 예상되는 동작 방식에서 어떻게 벗어나는지를 서술합니다.
멍청한 방식:
노트북 화면이 제대로 안 나옵니다. 도와주세요.
좋은 방식:
기형적인 X.org 6.8.1 마우스 커서, Fooware MV1005 비디오 칩셋 사용 중.
더 좋은 방식:
Fooware MV1005 비디오 칩셋에서 X.org 6.8.1 마우스 커서가 기형적으로 나옵니다.
"대상-변동" 구조로 서술하는 과정은 생각을 구체적으로 정리하는 데에 도움이 됩니다. 지금 마우스 커서만 제대로 안 나오는 건가요, 아니면 다른 그래픽에도 문제가 생겼나요? 특정 X.org의 버전에서만 생기는 문제인가요? 혹시 6.8.1 버전에서만? Fooware 비디오 칩셋에서만 생기는 문제인가요? MV1005 모델에서만? 이 결과를 보는 해커는 당신이 무엇에 대한 문제를 겪고 있는지와 동시에 당신이 겪고 있는 문제를 단번에 이해할 수 있게 됩니다.
좀 더 일반적으로, 당신이 질문 게시판의 검색 결과를 쭉 훑으며 제목만 읽고 있다고 상상해보세요. 당신의 제목이 질문의 내용을 잘 반영해야 당신과 비슷한 질문을 가지고 게시판을 검색하는 다음 사람이 새로운 질문을 올리는 대신 당신이 올린 질문과 그 답변을 따라갈 수 있게 됩니다.
당신이 답장에서 새로운 질문을 하는 경우라면, 제목을 꼭 바꾸어서 당신이 질문을 하고 있다는 것을 보여주세요. "Re: 테스트" 혹은 "Re: 버그 발견" 같은 제목은 주목받기 어렵습니다. 또한 이전 글의 인용을 최소화하여 새로운 독자들이 따라가는 데 필요한 만큼만 남기세요.
단순히 게시판의 최근 메시지에 답장을 누르는 식으로 아예 새로운 글타래를 시작하지 마세요. 이러한 방식은 청중을 제한시킵니다. 일부 메일 프로그램은 사용자가 글타래를 기준으로 정렬할 수 있도록 하며 글타래의 나중 메시지들을 숨기는 기능을 제공합니다. 이런 기능을 사용하는 사람들은 당신의 글을 영원히 보지 못할 겁니다.
제목을 바꾸는 것만으로는 충분하지 않습니다. 여러 메일 프로그램은 제목이 아닌 다른 정보를 이용해 글타래를 구별합니다. 그냥 새로운 메일을 쓰세요.
웹 포럼에서는 통용되는 방식이 조금 다릅니다. 왜냐하면 각 게시글은 특정한 토론 글타래에 훨씬 밀접하게 연관되어 있고, 해당 글타래 밖에서는 보이지 않기 때문입니다. 웹 포럼에서는 답장에서 질문을 올릴 때 제목을 바꾸는 것이 필수가 아닙니다. 심지어 답장에 제목을 쓰도록 허용하지 않는 포럼도 있으며, 쓴다해도 거의 아무도 읽지 않습니다. 답장에 질문을 올리면 해당 글타래를 지켜보고 있는 사람만 이 질문을 보게 되기 때문에 이는 모호한 행동입니다. 그러니까 이 글타래를 보고 있는 사람만 당신의 질문을 보길 원하는 게 아니라면, 새 글타래를 여세요.
질문 글을 "답변을 ~~에 보내주세요" 같은 문구로 마무리하는 것은 당신이 답변을 받게 될 가능성을 많이 낮춥니다. 당신이 메일 프로그램의 Reply-To 헤더를 고치는 데 쓰일 단 몇 초도 할애할 수 없다면, 우리도 당신의 문제를 생각하는 데 단 몇 초도 할애할 수 없습니다. 당신의 메일 프로그램이 이런 기능을 지원하지 않는다면, 더 나은 메일 프로그램을 쓰세요. 당신이 사용하는 운영체제가 이런 기능을 지원하는 메일 프로그램을 하나도 지원하지 않는다면, 더 나은 운영체제를 쓰세요.
웹 포럼에서 이메일로 답변하기를 요구하는 것은 이 정보가 민감하다고 믿는 경우(그리고 이 글에 답변해주는 누군가는 알 수 없는 이유로 웹 포럼 전체는 이 정보를 알면 안되지만 당신은 알아도 된다고 생각해주는 경우)가 아니라면 아주 무례한 행동입니다. 누군가가 글타래에 답변을 올렸을 때 이메일 사본을 받기를 원한다면, 웹 포럼에 요청하세요. 거의 모든 웹 포럼에서는 "글타래 지켜보기", "답변이 오면 이메일 알림" 같은 기능을 지원합니다.
우리는 경험적으로 대충 대충 게으르게 글을 쓰는 사람은 생각이나 코딩을 할 때도 대충 대충 게으르게 한다는 것을 깨달았습니다. 내기해도 될 정도에요. 게으르고 대충 생각하는 사람을 위해 답변을 하는 것은 보람이 전혀 없습니다. 그럴 시간에 우리는 다른 일을 할 겁니다.
그러니 당신의 질문을 명확하게 잘 표현하는 것은 매우 중요합니다. 당신이 그럴 여력이 없다면, 우리도 똑같이 당신 질문에 주목할 여력이 없습니다. 글을 잘 다듬는 데에 더욱 노력하세요. 딱딱하거나 격식을 차려서 쓸 필요는 없습니다. 애초에 해커 문화는 격식을 차리지 않고, 비속어와 유머가 섞인 글을 즐깁니다. 중요한 건 정확해야 한다는 겁니다. 당신이 여기에 신경을 많이 쓰고 있다는 것이 보여야 합니다.
(역자 주: 영어 기준으로 작성되어 있어, 우선 그대로 따릅니다. 추후에 한국어에 맞게 수정할 수 있습니다.)
맞춤법과 문장 부호를 잘 지켜서 작성하세요. "its"와 "it's", "loose"와 "lose", "discrete"와 "discreet"을 혼동하지 마세요. 전부 대문자로 작성하지 마세요. 이는 소리 지르는 것으로 읽히며 무례한 것으로 간주됩니다. (전부 소문자로 작성하는 것도 가독성을 떨어트립니다. Alan Cox라면 봐줄 수 있지만, 당신은 안돼요.)
일반적으로, 당신이 얼간이처럼 글을 쓴다면 아주 높은 확률로 무시당할 겁니다. 그러니까 채팅 줄임말을 쓰지 마세요. "you"를 "u"로 쓰는 것은 타자 2타를 아끼는 댓가로 당신이 얼간이처럼 보이게 만들 겁니다. 아니면 l33t script kiddie hax0r처럼 쓰는 것으로 확실히 소름끼치는 침묵만 돌려받을 수도 있습니다.
당신의 모국어를 쓰지 않는 포럼에 질문을 올리는 상황이라면, 맞춤법과 문법 오류에 대한 관용을 약간 받을 수 있습니다 - 하지만 게으름에 대한 관용은 포함되어 있지 않습니다(그리고 웬만하면 그 차이점을 찾을 수 있습니다). 그리고 답변자의 모국어가 무엇인지 아는 상황이 아니라면, 영어로 쓰세요. 바쁜 해커들은 이해할 수 없는 언어로 쓰인 질문은 가볍게 무시할 것이고, 영어는 인터넷 세상의 공용어입니다. 영어로 쓰면 당신의 질문이 읽히지도 않고 삭제될 가능성을 최소화할 수 있습니다.
당신이 영어로 쓰려 하는데 모국어가 아니라면, 잠재적 답변자들을 위해 언어적 문제를 미리 알리는 것은 도움이 될 수 있습니다. 아래에 예시가 있습니다.
- English is not my native language; please excuse typing errors.
- (해석: 영어는 제 모국어가 아닙니다; 오류를 용서해주세요.)
- If you speak Korean, 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 Korean and English. I'll be glad to translate responses, if you only use one or the other.
- (해석: 제 질문을 한국어와 영어로 올렸습니다. 당신이 둘 중 한 언어만 사용한다면 기꺼이 다른 언어로 번역하겠습니다.)