提问的智慧（How To Ask Questions The Smart Way）

站务管理 公告与规则 / Announcements & Rules
1

원문: How To Ask Questions The Smart Way

번역: 왕강<yafrank at 126 dot com>
시간: 2013년 10월 26일
내용

목차

번역: 인도네시아어, 벨라루스어, 브라질 포르투갈어, 중국어 간체, 네덜란드어, 프랑스어, 조지아어, 독일어, 그리스어, 히브리어, 일본어, 폴란드어, 포르투갈어, 루마니아어, 러시아어, 스페인어, 태국어
본 문서를 복사·미러·번역·인용하려면 내 복사 규정을 참조하시오.

면책 조항

많은 프로젝트 사이트가 도움을 받는 방법 섹션에 본 문서를 링크하고 있다. 그건 괜찮고 우리가 원하는 바이기도 하다. 그러나 당신이 그 프로젝트의 링크를 생성한 웹마스터라면, 링크 근처에 눈에 띄게 “우리는 이 프로젝트에 대한 지원을 제공하지 않습니다!”라고 밝혀야 한다.

우리는 이런 안내가 없을 때의 고통을 이미 충분히 겪었다. 본 문서를 발표했으니 우리가 세상의 모든 기술 문제를 해결할 책임이 있다고 믿는 바보들에게 계속 괴롭힌당할 것이다.

도움이 필요해서 본 문서를 읽고, 저자에게 직접 도움을 받을 수 있다는 인상을 가진 채 떠난다면, 유감스럽게도 당신이 우리가 말하는 바보 중 하나다. 우리에게 질문하지 마라. 우리는 무시할 것이다. 우리가 하는 일은 당신의 하드웨어나 소프트웨어 문제를 진짜로 아는 사람들에게 어떻게 도움을 받는지 가르쳐 주는 것이지, 99.9%의 경우 우리가 그 전문가는 아니라는 뜻이다. 본 문서의 저자가 당신의 문제 분야의 전문가라고 아주 확신하지 않는 한, 방해하지 마라. 그래야 모두가 더 행복하다.

서론

해커 세계에서 기술 질문에 대한 답은 질문하는 방식과 문제 난이도에 크게 좌우된다. 본 문서는 만족스러운 답을 받을 가능성을 높이는 질문 방법을 가르쳐 준다.

오픈소스 프로그램은 이미 널리 쓰이고 있어, 해커보다는 경험 많은 사용자에게 답을 얻는 경우가 많다. 이는 좋은 일로, 그들은 보통 초보자의 흔한 실수를 더 너그럽게 받아들인다. 그럼에도 우리가 추천하는 방법을 써서 그들을 해커처럼 대하면 보통 가장 효과적으로 답을 얻을 수 있다.

첫 번째로 알아야 할 것은 해커들이 어려운 문제와 사고를 자극하는 좋은 질문을 좋아한다는 점이다. 그렇지 않았다면 우리는 이 글을 쓰지도 않았을 것이다. 흥미로운 문제를 제시해 우리가 씹고 즐길 수 있게 한다면 고맙게 여길 것이다. 좋은 질문은 자극과 선물로, 우리의 인식을 발전시키고 미처 주목하지 못했던 문제를 드러낸다. 해커에게 “좋은 질문이야!”는 매우 뜨겁고 진심 어린 칭찬이다.

또한 해커는 간단한 문제에 대해 적대적이거나 오만하게 반응한다는 명성이 있다. 때로는 신입과 바보들에게 조건반사적으로 무례해 보이기도 하지만, 실상은 그렇지 않다.

우리는 그저 질문하기 전에 생각하고 숙제를 하려 하지 않는 사람들에게는 사과 없이 적대적일 뿐이다. 그런 사람들은 시간의 무한한 싱크홀 같다—받기만 하고 주려 하지 않으며, 재미있는 질문이나 답변 가치가 있는 사람들을 위해 쓰일 시간을 낭비한다. 우리는 그런 사람을 ‘loser’라 부른다(역사적 이유로 때로는 ‘lusers’라고도 쓴다).

우리는 많은 사람들이 단지 우리가 쓴 소프트웨어를 사용할 뿐 기술적 세부사항에 흥미가 없다는 걸 안다. 대부분에게 컴퓨터는 목적을 위한 도구일 뿐이다. 그들에게는 더 중요한 일이 있다. 우리는 이를 인정하며, 모두가 우리를 매료시킨 기술 문제에 흥미를 가지리라 기대하지 않는다. 그러나 우리의 답변 스타일은 진짜로 관심 있고 문제 해결에 능동적으로 참여하려는 사람들에게 맞춰져 있으며, 그래야만 한다. 그마저 변한다면 우리는 우리가 가장 잘하는 일에서 예리함을 잃게 될 것이다.

우리 대부분은 자원봉사자로서 바쁜 삶에서 시간을 쪼개 답변한다. 때로는 역량이 부족하다. 따라서 우리는 특히 loser처럼 보이는 질문을 가차 없이 거른다. 그래야 승자들에게 답변할 시간을 더 효율적으로 쓸 수 있다.

이런 태도가 거슬리고 시혜적이거나 오만하다고 느껴진다면 가정을 점검하라. 우리는 당신이 굴복하기를 바라지 않는다—사실, 당신이 해야 할 일을 했다면 우리 대부분은 매우 기쁜 마음으로 당신과 교류하고 우리 문화를 환영할 것이다. 스스로 돕기를 꺼리는 사람을 돕는 건 우리에게 비효율적이다. 모르는 건 괜찮지만, 바보처럼 행동하는 건 안 된다.

따라서 기술적으로 뛰어나지 않아도 주목받을 수 있지만, 기민하고 생각이 있으며 관찰력 있고 문제 해결에 능동적으로 참여하려는 자세는 반드시 보여야 한다. 그런 차별화를 할 수 없다면 유료 상업 지원을 구하는 편이 낫다.

우리에게 도움을 청하기로 했다면 loser가 되고 싶지 않을 것이고, loser로 보이고 싶지도 않을 것이다. 빠르고 효과적인 답을 얻는 가장 좋은 방법은 질문자가 똑똑하고 자신 있으며 생각이 있는 사람처럼 보이게 하는 것이고, 단지 특정 문제에서 우연히 도움이 필요하다는 암시를 주는 것이다.

(지적 환영: [email protected] 또는 [email protected]으로 제안 보내기. 단, 본 문서는 일반적인 넷리퀴트 가이드가 되려는 게 아니며, 기술 포럼에서 유용한 답변을 이끌어내는 데 특별히 관련 없는 제안은 일반적으로 거절한다.)

질문하기 전에

이메일·뉴스그룹·포럼에 기술 질문을 하기 전에 다음을 하라:

  • 준비 중인 포럼의 과거 문서에서 답변을 검색해 본다
  • 인터넷에서 답을 검색해 본다
  • 매뉴얼을 읽어 본다
  • FAQ를 읽어 본다
  • 직접 확인하거나 실험해 본다
  • 아는 친구에게 물어 본다
  • 프로그래머라면 소스 코드를 읽어 본다

질문할 때 위를 이미 했다고 밝혀라. 기생충이거나 남의 시간을 낭비하는 사람이라는 인상을 줄이는 데 도움이 된다. 거기서 무엇을 배웠는지도 덧붙이면 좋다. 우리는 답에서 배우려는 모습을 보이는 사람의 질문을 좋아한다.

구글 등으로 만난 각종 오류 메시지를 검색하면(구글 그룹과 웹 페이지 모두) 바로 해결 문서나 메일링 리스트 단서를 찾을 가능성이 높다. 결과가 없더라도 “구글에서 다음 문장으로 검색했으나 쓸만한 걸 찾지 못했다”고 언급하면 좋다. 검색 키워드를 질문과 가능한 해결책에 연결하면 비슷한 문제를 겪는 다른 사람도 도움을 받을 수 있다.

서두르지 마라. 몇 초 만에 구글 검색으로 복잡한 문제를 해결하길 기대하지 마라. FAQ를 읽어라. 전문가에게 묻기 전에 뒤로 기대어放松一下(쉬면서) 문제를 생각해 보라. 우리는 당신이 얼마나 읽고 생각했는지 금방 안다. 준비되어 올수록 답변을 받을 가능성이 높다. 첫 검색에 결과가 없거나(혹은 너무 많거나) 해서 모든 질문을 한꺼번에 쏟아내지 마라.

진지하게 생각하고 질문을 준비하라. 가벼운 질문은 가벼운 답변만 얻거나 아예 없다. 질문할 때 문제를 해결하려고 앞서 고민하고 노력한 모습을 보일수록 진짜 도움을 받을 가능성이 높다.

틀린 질문은 하지 마라. 잘못된 가정에 기반한 질문은 어떤 해커가 “바보 같은 질문이…”라고 생각하며 틀린 대로 답해 주어, 당신이 “물은 것”이 아닌 “필요한 것”을 얻지 못하게 할 수 있다.

답변을 받을 자격이 있다고 절대 가정하지 마라. 그런 자격은 없다. 돈을 내지 않았으니까. 흥미 있고 자극적인 질문—커뮤니티에 경험을 기여할 수 있는, 단순히 지식을 요구하는 소극적 질문이 아닌—을 제시하면 답변을 “벌어” 들인다.

반대로, 문제 해결에 기여할 능력과 의지가 있음을 보이는 건 좋은 시작이다. “방향을 제시해 줄 수 있나요?”, “무엇이 부족한가요?”, “어느 웹사이트를 봐야 하나요?”는 보통 “완전한 절차를 알려 달라”보다 답변을 받기 쉽다. 누군가 방향만 제시하면 나머지는 스스로 하겠다는 뜻을 보였기 때문이다.

질문할 때

포럼을 신중히 선택하라

다음을 하면 대부분 무시당하거나 “loser”로 낙인찍힌다:

  • 포럼 주제와 무관한 질문 올리기
  • 고급 기술 포럼에 얕은 질문 올리거나 그 반대
  • 너무 많은 뉴스그룹에 동시 게시
  • 당신을 모르고 답변할 의무도 없는 사람에게 개인 이메일 보내기

소통 채널을 무관한 것으로 오염시키지 않도록 해커들은 장소를 잘못 찾은 질문을 제거한다. 당신도 그 대상이 되고 싶지 않을 것이다.

따라서 첫째로 올바른 포럼을 찾아라. 구글 등은 당신의 어려움과 가장 관련 있는 프로젝트 사이트를 검색하는 데 도움이 된다. 거기엔 보통 FAQ, 메일링 리스트, 문서 링크가 있다. 노력(FAQ 포함)에도 결과가 없다면 그 메일링 리스트가 최후의 보루다.

낯선 사람·포럼에 이메일을 보내는 건 모험이다. 풍부한 웹페이지의 저자가 무료 상담원이 되길 기대하지 마라. 질문이 환영받을 거라고 낙관적으로만 보지 마라—확신이 서지 않으면 다른 데로 보내거나 아예 보내지 마라.

포럼·뉴스그룹·메일링 리스트를 고를 때 이름만 믿지 말고 FAQ나 규칙을 먼저 읽어 당신의 질문이 적절한지 확인하라. 게시 전 과거 글을 훑어 분위기를 파악하라. 게시 전에 해당 그룹에서 키워드로 검색하는 것도 매우 좋은 생각이다. 답을 찾지 못해도 더 나은 질문을 정리하는 데 도움이 된다.

기관총처럼 모든 도움 채널에 “일제 사격”하지 마라. 고함치는 것만큼이나 불쾌하다. 부드럽게 하나씩 해라.

주제를 이해하라! 흔한 실수 중 하나는 이식성 있는 언어·라이브러리·도구 포럼에 유닉스나 윈도우 API 질문을 올리는 것이다. 왜 큰 실수인지 모른다면 개념을 잡기 전엔 아무것도 묻지 마라.

일반적으로 잘 선택한 공개 포럼이 같은 질문을 개인 포럼에 올리는 것보다 유용한 답을 얻기 쉽다. 잠재적 답변자 수도 많고, 포럼 참여자 수도 많으며, 해커들은 다수를 도울 수 있는 질문에 답하기를 좋아한다.

유명 소프트웨어 저자들은 이미 부당한 메시지로 과부하를 겪고 있다. 당신의 한 통이 낙타의 허리를 꺾는 마지막 낙엽이 될 수도 있다. 여러 차례 유명 소프트웨어 저자들이 자신의 소프트웨어 지원을 포기한 적이 있다.

초보자 대상 포럼과 IRC가 보통 가장 빠르게 응답한다

지역 사용자 그룹이나 리눅스 배포판에서 초보자 도움 포럼이나 IRC 채널을 홍보하는 경우가 있다. 이곳은 질문을 시작하기 좋으며, 특히 겪는 문제가 비교적 간단하거나 흔할 때 유용하다. 공개된 IRC 채널은 실시간 답변을 얻을 수 있는 공개 초대장이다.

문제가 있는 프로그램이 배포판에서 나온 것이라면(흔한 경우) 먼저 해당 배포판 포럼·메일링 리스트에 질문하고, 그다음에 프로그램 자체의 포럼·메일링 리스트로 가라. 그렇지 않으면 해당 프로젝트 해커가 “우리 코드를 써라”라고만 답할 수 있다.

포럼에 글을 올리기 전에 검색 기능이 있는지 확인하고, 있다면 키워드 몇 개로 검색해 보라. 이미 전면적인 웹 검색을 했다 해도 포럼은 다시 검색하라. 검색엔진이 포럼의 모든 내용을 아직 색인하지 못했을 수 있다.

프로젝트 사용자 지원은 포럼이나 IRC로 제공하는 추세이며, 이메일은 개발자용으로 남아 있다. 따라서 프로젝트 관련 도움은 먼저 포럼이나 IRC에서 구하라.

두 번째 단계, 프로젝트 메일링 리스트 사용

프로젝트에 개발자 메일링 리스트가 있다면, 개인에게가 아니라 리스트에 질문하라. 그 사람이 가장 잘 답해 줄 것이라 확신해도 리스트를 사용하라. 프로젝트 문서와 홈페이지에서 메일링 리스트를 찾아라. 이유는 다음과 같다:

  • 개인에게 한 질문이 충분히 좋다면 전체 프로젝트에도 유익하다. 반대로 너무 바보 같아 보인다고 해도 개발자를 괴롭힐 이유는 없다.
  • 리스트에 질문하면 부담이 분산된다. 개발자(특히 프로젝트 리더)는 너무 바빠서 답변을 못 할 수도 있다.
  • 대부분의 메일링 리스트는 보관·검색엔진 색인이 되므로, 리스트에서 질문과 답변이 오가면 나중에 누군가 웹 검색으로 찾아볼 수 있다.
  • 자주 묻는 질문이면 개발자가 문서나 소프트웨어를 개선할 수 있다. 개인적으로만 물으면 전체 상황을 아는 사람이 없다.

프로젝트에 ‘사용자’와 ‘개발자’ 메일링 리스트가 따로 있다면 코드를 만지지 않는 한 ‘사용자’ 리스트에 질문하라. 개발자 리스트가 당신을 환영할 거라 가정하지 마라.

문제가 특별하다 확신하고 사용자 리스트에 며칠간 답변이 없다면 개발자 리스트를 시도해 보라. 게시 전 며칠간 과거 글을 관찰해 분위기를 파악하라(사실 어떤 사설·준사설 리스트든 가입 전 관찰하는 게 좋다).

프로젝트 메일링 리스트를 찾지 못하고 유지자 이메일만 있다면 그에게 보내라. 그래도 리스트가 없다고 가정하지 마라. 이메일에서 리스트를 찾으려 했으나 실패했음을 밝히고, 당신의 메일을 타인에게 전달하는 데 반대하지 않음을 명시하라(많은 사람이 비밀은 아니더라도 개인 메일은 공개되길 원하지 않는다. 전달을 허용하면 선택권을 주는 셈이다).* 영어는 제 모국어가 아니니 철자 오류는 양해해 주세요.

  • 여러분이 모르는 언어를 사용한다면 이메일/쪽지로 연락 주세요. 제 질문을 번역하는 데 도움이 필요할 수 있습니다.
  • 기술 용어 자체는 잘 알지만, 그것의 속어 관용 표현은 잘 모릅니다.
  • 모르는 언어와 영어로 동시에 질문했으니, 둘 중 하나로 답변 주시면 기꺼이 번역하겠습니다.

읽기 쉽고 표준적인 파일 형식으로 질문 보내기

의도적으로 읽기 어렵게 만들면 대부분 무시됩니다. 사람들은 읽기 쉬운 질문을 선호하므로:

  • HTML 대신纯文本 사용(HTML 끄기는 어렵지 않음)
  • MIME 첨부는 실제 내용(소스 파일이나 패치 등)이 있을 때만 허용되며, 메일 클라이언트가 자동 생성한 템플릿(메시지 내용 복사본 등)은 금지입니다.
  • 한 줄짜리 문장을 여러 번 개행해서 보내지 마세요(일부만 회신하기 어렵습니다). 독자가 80자 너비 터미널에서 읽는다고 가정하고, 80열 미만에서 줄바꿈하세요.
  • 고정 열 개행 로그 파일이나 세션 기록은 그대로 붙이세요. 데이터는 원본 그대로 포함해, 회신자가 여러분과 똑같은 것을 본다고 확신하게 하세요.
  • 영어 포럼에서는 ‘Quoted-Printable’ MIME 인코딩으로 메시지 보내지 마세요. 비 ASCII 언어에는 필요할 수 있지만, 많은 메일 프로그램이 지원하지 않습니다. 깨지면 “=20” 기호가 사방에 흩어져 보기 싫고 산만하며 내용을 망칠 수 있습니다.
  • 절대로 마이크로소프트 Word·Excel 같은 독점 형식 문서를 읽기를 기대하지 마세요. 대부분 해커는 뜨거운 돼지 똥이 문앞에 떨어진 것처럼 반응합니다. 처리할 수 있어도 하기 싫어합니다.
  • Windows에서 메일 보낼 땐 “똑똑한 인용” 기능 끄기(도구 → 자동 수정 옵션 → 입력 시 자동 서식에서 똑똑한 인용 체크 해제)로 쓰레기 문자가 퍼지는 걸 막으세요.
  • 포럼에서는 이모티콘·HTML 기능(제공될 때) 남용 금지. 이모티콘 한두 개는 괜찮지만, 화려한 색상은 무능력해 보이게 만듭니다. 과도한 이모티콘·색상·글꼴은 실실 웃는 소녀 같아 보입니다. 성적 관심이 아닌 유용한 답변을 원한다면 피하세요.
  • GUI 메일 클라이언트(넷스케이프 Messenger·아웃룩 등)를 쓰면 기본 설정이 요구사항을 만족하지 않을 수 있습니다. 메뉴 기반 소스 보기 명령으로 보낸 편지함 메시지를 확인해 불필요한 잡동사니 없는纯文本만 보내고 있는지 검증하세요.

문제를 정확하고 유용하게 설명하세요

  • 증상을 정확히 설명하세요
  • 환경(호스트·OS·애플리케이션 등)을 설명하고, 배포판과 버전(예: “Fedora Core 7”, “Slackware 9.1”)을 제공하세요
  • 질문 전 조사한 내용과 이해한 바를 설명하세요
  • 문제 확인을 위해 시도한 진단 단계를 설명하세요
  • 최근 컴퓨터나 소프트웨어 설정 변경사항을 설명하세요
  • 가능하다면 제어 가능한 환경에서 문제를 재현하는 방법을 제공하세요
  • 해커가 물어볼 만한 질문을 미리 예측해 답변을 준비하세요

코드 문제라면 제어 가능한 환경에서 재현 방법을 제공하는 것이 특히 중요합니다. 그러면 유용하고 신속한 답변을 받을 가능성이 크게 높아집니다.

사이먼 테이섬(Simon Tatham)이 《버그를 효과적으로 보고하는 방법》을 썼으니 꼭 읽어보세요.

양보다 정제

많은 코드나 데이터를 나열하는 것은 도움이 되지 않습니다. 크고 복잡한 테스트 케이스가 프로그램을 충돌시킨다면 가능한 한 작게 줄이세요.

이유는 세 가지입니다. 첫째, 문제를 단순화하려는 노력을 보여주면 답변 받을 가능성이 높아집니다. 둘째, 단순화하면 유용한 답변을 받을 가능성이 높아집니다. 셋째, 버그 보고서를 정제하는 과정에서 스스로 해결책이나 임시방편을 찾을 수도 있습니다.

급히 버그라고 외치지 마세요

소프트웨어에서 문제를 만났다고 해서 아주 명확한 근거가 없는 한 버그라고 단정하지 마세요. 힌트: 해결책이 되는 소스 패치를 제시하거나 이전 버전에서 회귀 테스트가 잘못된 동작을 보여주지 않는 한, 여러분은 완전히 확신하지 못하는 것입니다. 문서도 마찬가지입니다. 문서 “버그”를 발견했다면 대체 텍스트를 제시할 수 있어야 합니다.

문제를 겪지 않은 다른 사용자가 많다는 걸 기억하세요. 그렇지 않았다면 문서를 읽거나 웹을 검색했을 때 발견했을 테니까요(불평하기 전에 이미 했죠?). 즉, 여러분이 잘못했을 가능성이 큽니다.

소프트웨어 작성자들은 완벽하게 만들기 위해 열심히 노력합니다. 버그라고 주장하면 그들의 능력을 의심하는 것이며, 설사 맞더라도 일부는 기분 나빠할 수 있습니다. 주제 줄에 “버그”를 외치는 것도 특히 세련되지 못합니다.

질문할 땐 사적으로 확신이 있어도 “내가 뭔가 잘못했을 것 같습니다”처럼 쓰세요. 정말 버그라면 답변에서 드러날 것입니다. 그러면 유지자가 사과할 테니, 내가 실수해서 사과할 일보다 낫습니다.

자숭하는 태도로 숙제를 대신할 수 없음

무례하거나 거만하게 굴며 답변을 요구하지 말아야 한다는 건 알지만, 반대로 자숭하는 극단으로 물러나는 사람들도 있습니다: “저는 가련한 초보자이자 실패자입니다만…”. 이건 성가시고 무용이며, 문제 설명이 모호할 때는 특히 혐오감을 줍니다.

낮은 영장류 같은 방법으로 시간 낭비하지 마세요. 대신 배경과 문제를 가능한 한 명확히 설명하는 것이 자신의 위치를 더 잘 보여주는 방법입니다.

때로는 포럼에 초보자 전용 질문 게시판이 있습니다. 정말로 피상적인 문제라면 그곳에 가세요. 그래도 자숭하지 마세요.

증상을 설명하고 추측은 금물

무엇이 문제를 일으켰는지 말하는 건 무용입니다(진단이 대단하다면 왜 도움을 청하겠습니까?). 원시 증상만 말하고 해석이나 이론은 하지 마세요. 그들이 진단하게 하세요. 추측이 중요하다면 분명히 추측일 뿐이라고 밝히고 왜 틀렸는지 설명하세요.

어리석은 예:

커널 컴파일 중 SIG11 오류가 계속 나서, 마더보드의 회로가 끊긴 것 같습니다. 찾는 가장 좋은 방법은?

현명한 예:

제가 조립한 PC(K6/233 CPU, FIC-PA2007 마더보드[via Apollo VP2 칩셋], Corsair PC133 SDRAM 256MB)는 최근 부팅 후 20분쯤 지나 커널 컴파일 중 자주 SIG11 오류를 냅니다. 처음 20분 안에는 문제 없고, 재부팅해도 시계가 리셋되지 않지만 밤새 껐다 켜면 됩니다. 메모리를 모두 교체해도 해결되지 않았고, 관련 컴파일 세션 로그는 첨부했습니다.

이 점을 많은 사람들이 어려워하므로, “모든 진단 전문가는 미주리 출신”이라는 말을 기억하세요. 미국 국무장관의 공식 모토는 “보여줘”입니다(1899년 의원 윌러드 D. 밴디버의 연설에서 유래). 진단자에게는 의심이 아니라, 여러분이 본 것과 최대한 같은 원시 증거를 보고 싶어 하는 실용적 요구입니다. 보여주세요.

시간 순서대로 증상 나열

문제 직전 일은 해결책의 가장 유용한 단서를 포함합니다. 기록에 충돌 전 여러분·컴퓨터·소프트웨어가 무엇을 했는지 정확히 적으세요. 명령행이라면 스크립트 도구로 만든 세션 로그를 첨부하고 관련 20줄 정도 인용하면 큰 도움이 됩니다.

충돌 프로그램에 진단 옵션(-v 등)이 있다면 디버그 정보를 늘려주는 옵션을 쓰세요. “많다”가 “좋다”는 아닙니다. 적절한 수준으로 독자를 쓰레기에 잠기게 하지 마세요.

기록이 길다면(4단락 이상) 앞쪽에 문제를 요약하고 시간 순서대로 자세히 나열하는 것이 좋습니다. 그러면 해커가 주의할 부분을 압니다.

목표를 설명하고 절차는 금물

어떻게 할까(버그 신고가 아닌 경우)를 묻는다면, 먼저 상위 목표를 밝히고 나서 특정 단계에서 막힌 점을 설명하세요.

기술 도움을 청하는 사람들은 종종 더 높은 목표가 있고, 그 목표에 이르는 특정 길에서 막혀 그 길을 어떻게 가야 할지 묻지만, 그 길 자체가 문제일 때가 많아 큰 노력이 필요합니다.

어리석은 예:

그래픽 프로그램의 색상 선택기에서 16진 RGB 값을 어떻게 얻나요?

현명한 예:

제가 선택한 색상으로 이미지 색상표를 바꾸려고 합니다. 지금 아는 유일한 방법은 각 슬롯을 수동으로 편집하는 것인데, 그래픽 프로그램의 색상 선택기에서 16진 RGB 값을 얻을 수 없습니다.

두 번째 표현은 더 적합한 도구를 쓰라는 답변을 가능하게 합니다.

사답을 요구하지 마세요

해커들은 문제 해결 과정이 공개적이고 투명해야 한다고 봅니다. 더 능력 있는 사람이 부족하거나 부적절한 점을 발견하면 초기 답변을 고칠 수 있어야 하며, 답변자도 자신의 지식이 동료에게 보여짐으로써 보상을 받습니다.

사답을 요구하면 이 과정과 보상이 중단됩니다. 하지 마세요. 답변자가 스스로 사답을 선택하게 하세요──그렇게 하는 이유는 질문이 너무 형편없거나 피상적이라서 다른 사람에게는 의미 없다고 판단했기 때문입니다.

이 규칙에 제한적 예외가 있습니다. 질문이 너무 비슷한 답변을 쏟아낼 것 같다면 “이메일로 보내주시면 정리해서 올리겠습니다”는 마법의 문장입니다. 메일링 리스트나 뉴스그룹을 비슷한 답변의 홍수에서 구하는 건 매우 예의 바른 일입니다──단, 약속을 지켜야 합니다.

명확하게 질문하세요

막연한 질문은 한없는 시간 소모 구멍으로 여겨집니다. 가장 유용한 답변을 줄 수 있는 사람들은 보통 가장 바쁜 사람들이라(많은 일을 맡았기 때문에) 한없는 시간 구멍에 민감합니다. 그래서 그런 질문을 싫어합니다.

회신자가 해야 할 일(방향 제시·코드 전송·패치 검토 등)을 명확히 하면 유용한 답변을 받을 가능성이 높아집니다. 그들이 집중할 수 있게 하고, 도움에 쏟을 시간과 노력의 상한을 간접적으로 설정하는 것이기 때문입니다. 좋습니다.

전문가의 세계를 이해하려면, 풍부한 전문 지식은 있지만 응답 시간은 부족하다고 상상하세요. 그들이 내주길 요구하는 시간을 줄수록, 진짜 아는 바쁜 전문가로부터 답변을 받을 가능성이 높아집니다.

그러므로 전문가가 답변하는 데 드는 시간을 최소로 제한하세요──이건 보통 문제를 단순화하는 것과는 다릅니다. 예를 들어 “X를 잘 설명한 곳이 어딘가요?”가 “X를 설명해 주세요”보다 현명합니다. 코드가 작동하지 않으면 “어디가 잘못됐나 봐주실 수 있나요?”가 “고쳐주세요”보다 현명합니다.

코드 관련 질문

문제가 있는 코드를 붙이고 어디서부터 살펴봐야 할지 말하지 않은 채로 디버깅을 요구하지 마세요. 수백 줄을 붙이고 “작동 안 해요”라고 하면 무시됩니다. 수십 줄만 붙이고 “7번째 줄 이후로 가 나와야 하는데 가 나옵니다”라고 하세요.매우 가능성이 높습니다.

코드 문제를 가장 정확하게 설명하는 방법은 문제를 보여주는 최소 테스트 예제를 제공하는 것입니다. 최소 테스트 예제란 무엇입니까? 예상치 못한 동작을 재현하는 데 필요한 최소한의 코드로 문제를 보여주는 것입니다. 어떻게 최소 테스트 예제를 생성합니까? 어떤 줄이나 코드 조각이 문제를 일으킨다는 것을 알고 있다면, 그것을 복사하고 완전한 예제를 구성하는 데 필요한 최소한의 주변 지원 코드를 제공하십시오(최소한이란 소스 코드가 컴파일러, 인터프리터 또는 이를 처리하는 모든 프로그램에 의해 수락될 수 있도록 충분하다는 것을 의미합니다). 문제를 특정 부분으로 좁힐 수 없다면, 소스 코드를 복사하고 문제와 관련이 없는 코드 조각을 제거하십시오. 가능한 한 작은 테스트 예제를 제공하는 것이 가장 좋습니다(양이 많지 않고 정제되면 효과적이라는 점을 참조).

매우 작은 최소 테스트 예제를 생성하는 것이 항상 가능한 것은 아니지만, 노력하는 것은 좋은 연습이며 이는 스스로 해결해야 할 문제를 찾는 데 도움이 될 수 있습니다. 설령 찾지 못하더라도, 해커들은 당신이 노력한 것을 보고 싶어 하며 이는 그들이 더 협조적이 되도록 만들 것입니다.

누군가에게 코드를 검토해 달라고만 하고 싶다면, 처음부터 그렇게 말하고 반드시 어떤 부분이 특히 주의가 필요하다고 생각하는지와 그 이유를 언급하십시오.

숙제처럼 보이는 문제를 게시하지 마십시오

해커들은 "숙제"처럼 보이는 문제를 발견하는 데 능숙합니다. 우리 대부분은 이미 우리의 숙제를 끝냈으며, 그것은 당신이 해야 할 일이며 그것으로부터 배워야 합니다. 힌트를 요청하는 것은 괜찮지만, 완전한 해결책을 요구하지 마십시오.

숙제처럼 보이는 문제에 직면했다고 의심되지만 여전히 해결할 수 없다면, 사용자 그룹, 포럼 또는 (최후의 수단으로) 프로젝트의 “사용자” 메일링 리스트나 포럼에 질문해 보십시오. 해커들이 알아차리더라도, 일부資深 사용자들은 여전히 힌트를 줄 수 있습니다.

무의미한 요구 삭제하기

도움 요청 메시지 끝에 “누가 도와줄 수 있나요?” 또는 "답변이 있나요?"와 같은 의미 없는 것을 추가하는 유혹을 저항하십시오. 첫째, 문제 설명이 완전하지 않다면 이러한 추가 사항은 중복에 불과합니다. 둘째, 중복이기 때문에 해커들은 이러한 것들을 성가신 것으로 간주할 것입니다. 그리고 논리적으로는 틀리지 않았지만 퇴짜 놓는 답변으로 대응할 가능성이 높습니다. 예를 들어 “네, 도움을 받을 수 있습니다” 및 "아니요, 당신을 위한 도움은 없습니다"와 같은 답변입니다.

일반적으로 “예 또는 아니오” 유형의 질문은 피하십시오. “예 또는 아니오” 유형의 답변을 원하지 않는 한.

문제를 "긴급"으로 표시하지 마십시오, 설령 당신에게는 그렇게 보일지라도

이것은 당신의 문제이지, 우리의 문제가 아닙니다. "긴급"이라고 주장하는 것은 역효과를 낼 가능성이 높습니다. 대부분의 해커들은 이러한 메시지를 직접 삭제할 것입니다. 그들은 이를 무례하고 즉각적이고 특별한 주의를 얻으려는 이기적인 시도로 간주합니다. 그리고 “긴급” 또는 유사한 의미를 가진 주제는 스팸 필터 규칙을 트리거할 수 있으며, 잠재적인 답변자들은 당신의 질문을 결코 볼 수 없을 수도 있습니다!

약간의 국소적인 예외가 있습니다. 당신이 해커들을 흥분시킬 수 있는 매우 높은 명성을 가진 곳에서 프로그램을 사용하고 있다면, 이렇게 하는 것이 가치가 있을 수 있습니다. 이 경우, 기한의 압박이 있다면, 매우 정중하게 언급하면 사람들이 충분히 관심을 가지고 더 빨리 대답할 수도 있습니다.

물론, 이것은 매우 위험한 일입니다. 왜냐하면 해커들이 흥미롭게 생각하는 기준은 대부분 당신의 기준과 다르기 때문입니다. 예를 들어, 국제 우주 정거장에서 이러한 게시물을 올리는 것은 괜찮지만, 기분 좋은 자선이나 정치적 이유로 대변하는 것은 거의 확실히 안 됩니다. 실제로, "긴급: 저에게 이 귀여운 작은 물개를 구하도록 도와주세요!"와 같은 게시물은 해커들이 피하거나 화를 낼 것입니다. 설령 그들이 귀여운 작은 물개가 중요하다고 생각하더라도 말입니다.

이것이 믿기 어렵다고 느껴진다면, 나머지 내용을 몇 번 더 읽고, 이해할 때까지 게시하지 마십시오.

예의는 항상 도움이 됩니다

예의 바르게 행동하고, 请 및 谢谢你的关注 또는 谢谢你的关照와 같은 표현을 사용하여, 사람들이 무료로 시간을 내어 도와준 데 대해 감사한다는 것을 알게 하십시오.

솔직히 말해서, 이것은 문법적으로 정확하고, 글이 명확하고, 정확하며, 내용이 있고 전용 형식을 사용하지 않는 것만큼 중요하지 않습니다(동시에 이를 대체할 수도 없습니다). 해커들은 일반적으로 약간은 직설적이지만 기술적으로 날카로운 버그 보고서를 읽기를 선호합니다. 예의 바르지만 모호한 보고서보다는 말입니다. (이 점이 당신을 당황하게 한다면, 우리가 무엇을 배울 수 있는지에 따라 문제를 평가한다는 것을 기억하십시오)

그러나 기술적인 문제를 명확히 설명한 후에는 예의 바르게 행동하는 것이 유용한 답변을 받을 가능성을 높일 것입니다.

(우리는 이 문서의 유일하게 일부資深 해커들이 진지하게 반대하는 부분이 이전에 추천된 "提前谢了"라는 점을 지적해야 합니다. 일부 해커들은 이것이 나중에 누구에게도 감사할 필요가 없다는 것을 암시한다고 생각합니다. 우리의 조언은 提前谢了라고 먼저 말하고, 나중에 답변자들에게 감사를 표하거나, 谢谢你的关注 또는 谢谢你的关照와 같은 방식으로 표현하는 것입니다).

문제가 해결된 후 간단한 설명 추가하기

문제가 해결된 후, 도움을 준 모든 사람들에게 문제가 어떻게 해결되었는지 알리고 다시 한 번 감사의 말을 전하는 메시지를 추가하십시오. 문제가 메일링 리스트나 뉴스 그룹에서 광범위한 관심을 받았다면, 거기에 이 메시지를 추가하는 것이 적절합니다.

가장 이상적인 방법은 원래 질문에 대한 응답으로 이 메시지를 보내고, 제목에 已解决、已搞定 또는 이와 동등한 의미의 명확한 표시를 포함하는 것입니다. 사람들이 드나드는 메일링 리스트에서, 문제 X 및 문제 X-已解决라는 글타래를 본 잠재적인 답변자는 더 이상 시간을 낭비할 필요가 없다는 것을 알게 됩니다(그들이 개인적으로 "문제 X"가 흥미롭다고 느끼지 않는 한). 따라서 이 시간을 다른 문제를 해결하는 데 사용할 수 있습니다.

추가 메시지가 너무 길거나 복잡할 필요는 없습니다. "안녕하세요── 네트워크 케이블이 고장 났었어요! 모두들 감사합니다── 빌"과 같은 간단한 문장도 아무것도 없는 것보다는 낫습니다. 실제로, 문제를 해결하는 기술이 정말로 심오하지 않은 한, 간결하고 친근한 요약이 장황한 설명보다 낫습니다. 문제를 해결한 조치가 무엇인지 설명하고, 전체 디버깅 이야기를 다시 할 필요는 없습니다.

심층적인 문제의 경우, 디버깅 기록의 요약을 게시하는 것이 적절합니다. 문제의 최종 상태를 설명하고, 무엇이 문제를 해결했는지 설명한 다음, 피할 수 있는 우회로를 지적하십시오. 피할 수 있는 우회로 부분은 올바른 해결책 및 기타 요약 자료 다음에 배치하고, 이 메시지를 탐정 추리 소설로 만들지 마십시오. 도움을 준 사람들의 이름을 나열하면 친구를 사귈 수 있습니다.

이러한 유형의 후속 게시물은 예의 바르고 내용이 있는 것 외에도, 다른 사람들이 메일링 리스트, 뉴스 그룹 또는 포럼 문서에서 실제로 문제를 해결한 해결책을 검색할 수 있도록 도와줍니다. 따라서 그들도 이익을 얻을 수 있습니다.

마지막으로, 이러한 유형의 후속 게시물은 도움을 준 각 참가자에게 문제가 해결되었다는 만족감을 느끼게 합니다. 만약 당신이 기술 전문가나 해커가 아니라면, 우리를 믿으십시오. 이러한 느낌은 도움을 요청하는 당신과 전문가들에게 매우 중요합니다. 문제 설명이 끝까지 알 수 없는 것은 항상 좌절감을 주며, 해커들은 그것들이 해결되기를 간절히 바랍니다. 가려운 곳을 긁어주는 것은 당신이 다음에 다시 질문을 게시할 때 매우 매우 도움이 되는 신뢰를 얻을 수 있습니다.

다른 사람들이将来에 유사한 문제를 겪지 않도록 어떻게 할 수 있는지 고려하십시오. 문서나 FAQ 패치를 작성하는 것이 도움이 될지 스스로에게 물어보고, 그렇다면 패치를 유지 관리자에게 보내십시오.

해커들에게 이러한 좋은 후속 조치는 전통적인 예의보다 실제로 더 중요하며, 이는 당신이 다른 사람들을 잘 대함으로써 얻을 수 있는 명성이며, 이는 매우 귀중한 자산입니다.

답변을 해석하는 방법

“망할 매뉴얼을 읽어라”(RTFM)와 “망할 네트워크를 검색해라”(STFW): 당신이 완전히 망쳤음을 이해하는 방법

오래되고 신성한 전통이 있습니다: 만약 당신이 망할 매뉴얼을 읽어라(RTFM)라는 답변을 받는다면, 발신인은 당신이 “망할 매뉴얼을 읽어야 한다”고 생각합니다. 그 또는 그녀는 대부분 옳으며, 읽으십시오.

“망할 매뉴얼을 읽어라”(RTFM)에는 젊은 친척이 있습니다. 만약 당신이 “망할 네트워크를 검색해라”(STFW)라는 답변을 받는다면, 발신인은 당신이 “망할 네트워크를 검색해야 한다”고 생각합니다. 그 사람도 대부분 옳으며, 검색하십시오. (더 부드러운 표현은 “구글은 너의 친구야!”입니다)

포럼에서, 당신은 포럼 문서를 검색하라는 요청을 받을 수도 있습니다. 실제로, 누군가가 이전에 이 문제를 해결한 단서를 제공해 줄 수도 있습니다. 그러나 이러한 배려에 의존하지 마십시오. 질문하기 전에 문서를 먼저 검색하십시오.

일반적으로, 검색하라고 말하는 사람은 이미 당신의 문제를 해결할 수 있는 매뉴얼이나 웹페이지를 열어놓고, 키보드를 두드리고 있습니다. 이러한 답변은 그가 다음과 같이 생각한다는 것을 의미합니다:

  • 첫째, 당신이 찾는 정보는 쉽게 찾을 수 있습니다.
  • 둘째, 스스로 찾는 것이 남에게 먹여주는 것보다 더 많이 배울 수 있습니다.

이렇게 해서 모욕받았다고 느껴서는 안 됩니다. 해커의 기준에 따르면, 답변자가 당신을 무시하지 않은 것 자체가 어떤 존중을 표시하는 것이며, 오히려 감사해야 합니다.

아직도 이해가 되지 않는다면……

답변을 이해할 수 없다면, 즉시 설명을 요구하는 답변을 보내지 마십시오. 먼저 초기 질문에 사용한 것과 동일한 도구(예: 매뉴얼, FAQ, 웹페이지, 아는 친구 등)를 사용하여 답변을 이해하려고 노력하십시오. 설명이 필요하다면, 당신이 이미 이해한 것을 보여주십시오.

예를 들어, 내가 당신에게 “어떤 입력 항목에 문제가 있는 것처럼 보입니다. 지워야 합니다”라고 말했다면, 다음은 나쁜 후속 게시물입니다: “어떤 입력 항목이 뭔가요?”. 반면 다음은 좋은 후속 게시물입니다: “네, 매뉴얼을 읽었습니다.某某 입력 항목은 -z 및 -p 스위스에서만 언급되었지만, 어떻게 지우는지는 언급되지 않았습니다. 어떤 것을 말하는 것인가요, 아니면 내가 무언가를 잘못했나요?”

무례함에 대처하기

많은 해커 커뮤니티에서 무례해 보이는 행동은 의도적인 모욕이 아닙니다. 오히려 그것은 직접적이고 일침형式的인 교류 스타일입니다. 이러한 스타일은 문제 해결에 초점을 맞추고 다른 사람들이 편안함을 느끼도록 만드는 것보다는 혼란스럽게 만드는 데 익숙한 사람들에게는 자연스러운 것입니다.

만약 모욕받았다고 느낀다면, 침착하게 반응하려고 노력하십시오. 누군가가 정말로过分한 일을 했다면, 메일링 리스트, 뉴스 그룹 또는 포럼中的 선배들이 그를 처리할 것입니다. 만약 그렇지 않고 당신이 화를 낸다면, 당신이 화를 낸 대상의 말이 해커 커뮤니티에서는 정상적으로 보일 수 있으며, 당신은 잘못된一方으로 간주될 것입니다. 이는 정보를 얻거나 도움을 받을 기회를 손상시킬 것입니다.

반면에, 당신은 가끔 정말로 무례하고 지루한 말과 행동을 접할 것입니다. 위와는 반대로, 진정한 모욕者에게는 날카로운 언어로 반박하는 것이 받아들여질 수 있습니다. 그러나 행동하기 전에 매우매우 근거가 있어야 합니다. 무례한言論을 바로잡는 것과 무의미한口水战을 시작하는 것은 한 끗 차이입니다. 해커들 스스로가 무모하게 선을 넘는 경우는 드물지 않습니다. 만약 당신이 초보자或 외부인이라면, 이러한 무모함을 피할 기회가 높지 않습니다. 정보를 얻고 싶다면 시간을 보내고 싶지 않다면, 이런 때에는 키보드에서 손을 떼는 것이 가장 좋습니다.

(어떤 사람들은 많은 해커들이 경도의 자폐증 또는 아스퍼거 증후군을 앓고 있다고 주장합니다. 이는 사실일 수도 있고 아닐 수도 있습니다. 만약 당신이 해커가 아니라면, 우리가 머리에 문제가 있다고 생각하는 것이 우리의 기이한 행동을 다루는 데 도움이 될 수 있습니다. 그냥 그렇게 하십시오, 우리는 신경 쓰지 않습니다. 우리는 지금 이런 모습을 좋아하며, 일반적으로 병적인 표시에 대해 의심할 만한 근거가 있습니다.)

다음 절에서, 우리는 당신이 부적절하게 행동할 때 받게 될 “모욕”에 대해 이야기할 것입니다.

패배자처럼 반응하지 마십시오

해커 커뮤니티의 포럼에서 당신은 몇 번이고 망칠 수 있습니다──이 문서에서 설명한 것과 유사한 방식으로. 당신은 어떻게 망쳤는지展示될 것이며, 어쩌면言語中에 약간의 색채가 있을 수도 있습니다.

이런 일이 발생한 후, 당신이 할 수 있는 최악의 일은 당신의 처지를 울부짖으며, 말로 공격받았다고 주장하며, 사과를 요구하며, 큰 소리로 비명을 지르고, 답답해하며, 법적 조치를 위협하며, 그들의 고용주에게 불만을 제기하며, 변기 뚜껑을 닫는 것을 잊는 것 등입니다. 반면에 당신은 다음과 같이 해야 합니다:

견뎌내십시오. 이것은 정상적입니다. 사실, 이것은 건강에 좋고 적절합니다.

커뮤니티의 기준은 스스로 유지되지 않습니다. 그들은 참가자들이 적극적이고 공개적으로 실행함으로써 유지됩니다. 모든 비판이 사적인 메일을 통해 전달되어야 한다고 울부짖지 마십시오. 이것은 일이 진행되는 방식이 아닙니다. 누군가가 당신의 말이 틀렸다고 코멘트하거나 다른 견해를 제시할 때, 개인적인 공격을 받았다고 주장하는 것도 아무 소용이 없습니다. 이것은 모두 패배자의 태도입니다.

또 다른 해커 포럼들도 있습니다. 높은 예의要求에 의해誤導되어, 참가자들이 다른 사람의 게시물에 문제를 제기하는 메시지를 게시하는 것을 금지하고, "사용자를 도우고 싶지 않다면 입 다물라"고 주장합니다. 생각 있는 참가자들이 떠나버리는 결과는 그들을 무의미한 잔소리와 쓸모없는 기술 포럼으로 만들 뿐입니다.

과장된 “우정”(위에서 언급한 방식)과 유용함 중에서 선택하십시오.

기억하십시오: 해커가 당신이 망쳤다고 말하고, (아무리 가혹하게) 그만두라고 말할 때, 그는 당신과 그의 커뮤니티를 돌보는 행동을 하고 있습니다. 그에게는 당신을 무시하고 그의 삶에서 당신을 필터링하는 것이 훨씬 쉬울 것입니다. 감사할 수 없다면, 최소한 존엄성을 유지하고, 큰 소리로 울부짖지 마십시오. 연극적인 초감성 영혼이고 자격이 있는 신참자라고 생각해서, 다른 사람들이 당신을 부서지기 쉬운 인형처럼 대기를 기대하지 마십시오.

때로는 당신이 망치지 않았음에도(또는 단지 다른 사람이 당신이 망쳤다고 상상했을 뿐), 어떤 사람들은 아무 이유 없이 당신을 공격할 수도 있습니다. 이 경우, 불만을 제기하는 것은 문제를 더 망치는 것입니다.

이러한 트롤들은 either 전혀 방법이 없지만 스스로는 전문가라고 생각하는 쓸모없는 자들이거나, 당신이 정말로 망칠 것인지 테스트하는 심리학자들입니다. 다른 독자들은 either 무시하거나 자신만의 방식으로 대응할 것입니다. 이 트롤들은 스스로에게 문제를 일으키고 있으며, 이것은 당신이 걱정할 일이 아닙니다.

또한 스스로를口水战에 휘말리게 하지 마십시오. 대부분의口水战은 무시하는 것이 가장 좋습니다──물론, 그것들이 단순한口水战이며, 당신이 망친 곳을 지적하지 않고, 그 속에 진짜 답변을 교묘하게 숨겨두지 않았다는 것을 확인한 후에는(이것도 가능합니다).

질문 금기

다음은 전형적인 어리석은 질문들과 해커들이 그들에게 답변하지 않을 때의 생각입니다.

질문: 어떤 프로그램이나 X 리소스를 어디서 찾을 수 있나요?

질문: X로 Y를 어떻게 하나요?

질문: 내 셸 프롬프트를 어떻게 구성하나요?

질문: Bass-o-matic 파일 변환 도구로 AcmeCorp 문서를 TeX 형식으로 변환할 수 있나요?

질문: 내 {프로그램, 구성, SQL 문}이 실행되지 않습니다

질문: 내 Windows 컴퓨터에 문제가 있습니다. 도와줄 수 있나요?

질문: 내 프로그램이 실행되지 않습니다. 시스템 도구 X에 문제가 있는 것 같습니다

질문: Linux나 X를 설치하는 데 어려움을 겪고 있습니다. 도와줄 수 있나요?

질문: 어떻게 슈퍼유저 암호를 크랙하거나/채널 운영자의 권한을 훔치거나/누군가의 이메일을 볼 수 있나요?

질문:

어떤 프로그램이나 X 리소스를 어디서 찾을 수 있나요?

답변:

내가 찾은 같은 곳에서, 바보──웹 검색 엔진에서. 세상에, 아직도 구글을 어떻게 사용하는지 모르는 사람이 있나요?

질문:

X로 Y를 어떻게 하나요?

답변:

Y를 해결하려고 한다면, 질문할 때 부적절할 수도 있는 방법을 제시하지 마십시오. 이러한 질문은 질문자가 X에 대해 완전히 무지할 뿐만 아니라 해결하려는 Y 문제에 대해서도 혼란스러워하며, 특정 상황에 사고가 고착되었음을 보여줍니다. 문제를 먼저 정리하십시오.

질문:

내 셸 프롬프트를 어떻게 구성하나요?

답변:

이런 질문을 할 만큼 충분한 지혜가 있다면, “망할 매뉴얼을 읽어라”(RTFM)고 할 만큼 충분한 지혜도 있어야 합니다. 그리고 스스로 찾아내십시오.

질문:

Bass-o-matic 파일 변환 도구로 AcmeCorp 문서를 TeX 형식으로 변환할 수 있나요?

답변:

한번 시도해 보십시오. 시도해 봤다면, 답변을 얻었고, 내 시간을 낭비하지 않아도 됩니다.

질문:

내 {프로그램, 구성, SQL 문}이 실행되지 않습니다

답변:

이것은 질문이 아니며, 내가 무슨 문제가 있는지 추측할 관심도 없습니다──더 중요한 일이 있습니다. 이런 것을 보면, 나의 반응은 일반적으로 다음과 같습니다:

  • 뭐 더 보탤 말 있나요?
  • 오, 정말 안 됐네요. 해결되기를 바랍니다.
  • 이게 나랑 무슨 상관인가요?

질문:

내 Windows 컴퓨터에 문제가 있습니다. 도와줄 수 있나요?

답변:

네, Windows 쓰레기를 지우고 Linux나 BSD 같은 오픈소스 운영 체제를 설치하십시오.

참고: 프로그램에 공식 Windows 버전이 있거나 Windows와 상호 작용하는 경우(예: Samba), Windows 관련 질문을 할 수 있습니다. 다만 문제가 Windows 운영 체제 자체에서 비롯된 것이 아니라 프로그램本身 때문이라는 답변에 놀라지 마십시오. Windows는 일반적으로 너무 형편없기 때문에 이러한 말이 일반적으로 사실입니다.

질문:

내 프로그램이 실행되지 않습니다. 시스템 도구 X에 문제가 있는 것 같습니다

답변:

당신은 수천 명의 사용자가 반복적으로 사용하는 시스템 호출과 라이브러리 파일에 명백한 결함이 있다는 것을 처음으로 발견했을 가능성이完全 있으며, 더 가능성이 높은 것은 당신에게 아무 근거도 없다는 것입니다. 특별한 주장에는 특별한 증거가 필요합니다. 이렇게 주장할 때, 명확하고 상세한 결함 설명 문서를 뒷받침으로 해야 합니다.

질문:

Linux나 X를 설치하는 데 어려움을 겪고 있습니다. 도와줄 수 있나요?

답변:

안 됩니다. 오류를 진단하려면 당신의 컴퓨터를 직접 조작해야 합니다. 지역 Linux 사용자 그룹에서 편리한 도움을 구하십시오(여기에서 사용자 그룹 목록을 찾을 수 있습니다).

참고: 설치 문제가 특정 Linux 배포판과 관련이 있다면, 해당 배포판의 메일링 리스트, 포럼 또는 지역 사용자 조직에 질문하는 것이 적절할 수 있습니다. 이 경우 문제의 정확한 세부사항을 설명해야 합니다. 그 전에 “linux”와 모든 의심스러운 하드웨어 [를 키워드로] 신중하게 검색하십시오.

질문:

어떻게 슈퍼유저 암호를 크랙하거나/채널 운영자의 권한을 훔치거나/누군가의 이메일을 볼 수 있나요?

답변:

이런 일을 하고 싶다는 것은 당신이 비열한 자라는 것을 의미하며, 해커에게 이런 일을 가르쳐 달라고 하는 것은 당신이 바보라는 것을 의미합니다.

좋은 질문과 나쁜 질문

마지막으로, 예를 들어提問의 지혜를 보여드리겠습니다. 같은 질문이라도 두 가지 방식이 있습니다: 하나는 어리석고, 다른 하나는 현명합니다.

어리석은: Foonly Flurbamatic 장치에 대한 정보를 어디서 찾을 수 있나요?

이 질문은 “망할 네트워크를 검색해라”(STFW)式 답변을 구걸합니다.

현명한: “Foonly Flurbamatic 2600”으로 구글에서 검색해 봤지만, 유용한 것을 찾지 못했습니다. 이 장치의 프로그래밍 정보를 어디서 찾을 수 있는지 아는 사람이 있나요?

이 사람은 이미 네트워크에서 검색해 봤으며, 진짜 문제가 있다고 들립니다.

어리석은: 어떤 프로젝트의 소스 코드를 컴파일할 수 없습니다. 왜 이렇게 형편없나요?

질문자는 남이 망쳤다고 가정합니다. 너무 오만합니다.

현명한: 어떤 프로젝트의 소스 코드는 Linux 6.2 버전에서 컴파일되지 않습니다. FAQ를 읽었지만, Linux 관련 내용은 없었습니다. 이것은 컴파일 기록입니다. 내가 뭘 잘못했나요?

질문자는 실행 환경을 명시했고, FAQ를 읽었으며, 오류를 나열했고, 문제가 남의 잘못이라고 가정하지 않았습니다. 이 사람은 주목할 만합니다.

어리석은: 내 마더보드에 문제가 있습니다. 누가 도와줄 수 있나요?

어떤 해커는 다음과 같이 반응할 수 있습니다: “네, 등을 톡톡 두드리고 기저귀도 갈아줘야 하나요?” 그리고 delete 키를 누릅니다.

현명한: S2464 마더보드에서 X, Y 및 Z를 시도해 봤고, 모두 실패한 후 A, B 및 C를 시도해 봤습니다. C를 시도할 때의 이상한 증상에 주목하십시오. 분명히某某 것이某某 일을 하고 있으며, 이는 예상되는 동작이 아닙니다. 일반적으로 Athlon MP 마더보드에서某某 일이 발생하는 원인은 무엇입니까? 내가 문제를 확인하기 위해 무엇을 더 시도해 볼 수 있는지 아는 사람이 있나요?

반면에, 이 사람은 답변을 받을 만해 보입니다. 그 또는 그녀는 문제 해결 능력을 보여주었으며, 하늘에서 떨어지는 것을 기다리지 않았습니다.

마지막 질문에서, “답변을 달라”와 “내가启发을 얻기 위해 무엇을 더 테스트해 볼 수 있을지 도와달라”는 미묘하지만 중요한 차이를 주목하십시오.

사실, 마지막 질문은 기본적으로 2001년 8월 Linux 커널 메일링 리스트(lkml)의 실제 사건에서 비롯되었으며, 이는 내(Eric)가 그때 그 질문을 했던 것입니다. 나는 Tyan S2462 마더보드에 신비로운 다운 현상이 있다는 것을 발견했고, 메일링 리스트 구성원들이 이 문제를 해결하는 데 중요한 정보를 제공했습니다.

이러한提問 방식을 통해 나는 다른 사람들이 씹어 먹을 수 있는 것을 제공했습니다. 나는 참가자들에게 쉽고 매력적으로 만들도록 노력했으며, 동료의 능력에 대한 존경을 표하고 그들과 함께 협의하도록 초대했습니다. 내가 걸어온 우회로를 그들에게 알려줌으로써, 그들의 소중한 시간을 존중했다는 것을 보여주었습니다.

사후에, 내가 모두에게 감사하고 이번 좋은 경험에 대해 코멘트했을 때, Linux 커널 메일링 리스트의 한 구성원은 내가 답변을 얻은 것은 내 이름이 리스트에 올라 있었기 때문이 아니라, 올바른提問 방식을 사용했기 때문이라고 생각한다고 말했습니다.

해커들은 어떤 면에서 매우 냉정한 엘리트주의자들입니다. 나는 이 일에 대해 그가 옳다고 생각합니다. 만약 내가 不劳而获의 기생충처럼 表现得 했다면, 내가 누구였든 간에 무시되거나 꾸중을 들었을 것입니다. 그는 전체 사건을 다른 사람들의提Question에 대한 지침으로 삼으라고 제안했으며, 이는 바로 이 문서의 작성으로 이어졌습니다.

답변을 얻지 못한다면

답변을 얻지 못했다고 해서, 우리가 도와주기를 원하지 않는다고 생각하지 마십시오. 때로는 단지 질문을 받은 그룹 구성원들이 정말로 답변을 모르기 때문입니다. 답변이 없다는 것은 무시당했다는 것을 의미하지는 않습니다. 물론 둘의 차이를 밖에서 보기는 어렵다는 것을 인정해야 합니다.

일반적으로, 질문을 바로 다시 게시하는 것은 좋지 않습니다. 이것은 무의미한骚扰로 간주될 것입니다. 인내심을 가지십시오. 당신의 질문에 답변을 아는 사람은 다른 시간대에 살고 있을 수 있으며, 지금 잠을 자고 있을 수도 있고, 당신의 질문이 처음부터 잘 정리되지 않았을 수도 있습니다.

도움을 받을 수 있는 다른 리소스들이 있습니다. 일반적으로 초보자를 위한 리소스들입니다.

온라인 및 지역 사용자 조직이 많이 있습니다. 그들은 스스로 어떤 소프트웨어도 작성하지 않지만, 소프트웨어에 대해 열정적입니다. 이러한 사용자 그룹은 일반적으로 상호 도움과 초보자 돕기를 위해 형성됩니다.

또한 수많은 대소 상업 회사들이 계약 지원 서비스를 제공합니다. 지원을 받기 위해 약간의 비용을 지불해야 한다고 해서 낙담하지 마십시오! 결국, 당신의 차량의 실린더 헤드 개스킷이 타버렸다면, 당신은 아마도 수리점에 가서 고치기 위해 돈을 지불해야 할 것입니다. 설령 소프트웨어가 당신에게 아무 돈도 들지 않았다고 해도, 지원 서비스가 모두 무료일 것이라고 기대해서는 안 됩니다.

Linux처럼 인기 있는 소프트웨어의 경우, 각 개발자는 적어도 만 명 이상의 사용자를 가지고 있습니다. 한 사람이 이렇게 많은 사용자의 서비스 요구를 처리할 수는 없습니다. 설령 지원을 받기 위해 비용을 지불해야 한다고 해도, 소프트웨어를额外로 구매하는 것보다는 훨씬 적은 비용이 듭니다(그리고 폐쇄 소스 소프트웨어의 서포트는 오픈 소스 소프트웨어보다 일반적으로 더 비싸고, 품질도 떨어집니다).

더 나은 답변을 하는 방법

친절한 태도를 가지십시오. 문제로 인한 스트레스는 종종 사람들이 무례해 보이거나 어리석어 보이게 만듭니다. 실제로는 그렇지 않습니다.

초범犯者에게는 사적으로 답변하십시오. 정직하게 실수를 인정하는 사람들에게 공개적으로 굴욕을 줄 필요는 없습니다. 진짜 초보자는 어떻게 검색하거나 FAQ를 어디서 찾는지조차 모를 수도 있습니다.

확신이 서지 않는다면, 반드시 말하십시오! 권위 있는 틀린 답변은 없는 것보다 더 나쁩니다. 전문가처럼听起来 재미있어서 남에게 잘못된 길을 가르치지 마십시오. 겸손하고 정직하게 행동하여, 질문자와 동료들에게 좋은 본보기를 보여주십시오.

도움을 줄 수 없다면, 방해하지 마십시오. 구체적인 단계에서 농담을 하지 마십시오. 그렇지 않으면 사용자의 설치를 망칠 수 있습니다──어떤 불쌍한 바보가 그것을 진짜 지침으로 받아들일 수도 있습니다.

탐구적인 반문으로 더 많은 세부사항을 이끌어내십시오. 만약 잘 한다면, 질문자는 뭔가를 배울 수 있습니다──당신도 마찬가지입니다. 형편없는 질문을 좋은 질문으로 바꿔보십시오. 우리 모두가 한때는 초보자였다는 것을 잊지 마십시오.

懶惰한 자들에게 “망할 매뉴얼을 읽어라”(RTFM)라고 불평하는 것은 정당하지만, 문서의 위치를 지적하는 것(심지어 구글 키워드 검색을 제안하는 것만으로도)이 더 좋습니다.

답변하기로 결심했다면, 좋은 답변을 주십시오. 다른 사람이 잘못된 도구나 방법을 사용하고 있을 때, 어색한 임시방편을 제안하지 마십시오. 더 나은 도구를 추천하고, 문제를 재구성하십시오.

진짜 질문에 답변하십시오! 만약 질문자가 이미 연구를 하고, X, Y, Z, A, B 및 C를 시도했지만 원하는 결과를 얻지 못했다고 설명했다면, A 또는 B를 시도해 보십시오라고 답변하거나, X, Y, Z, A, B 또는 C를 시도해 보십시오라는 내용의 링크를 제공하는 것은 매우 무익합니다!

당신의 커뮤니티가从中에 배우도록 도우십시오. 좋은 질문에 답변할 때, 스스로에게 관련 파일이나 FAQ 문서를 어떻게 수정해야 같은 질문에 다시 답변하지 않아도 될까?라고 물어보십시오. 그런 다음 문서 유지 관리자에게 패치를 보내십시오.

만약 당신이 연구를 한 후에 답변했다면, 당신의 기술을 보여주십시오. 결국 “사람에게 물고기를 주는 것보다, 낚시하는 방법을 가르쳐 주는 것이 낫습니다”.### 관련 리소스

개인용 컴퓨터, Unix 및 인터넷의 작동 방식에 대한 기초 지식이 필요하다면 Unix와 인터넷 작동의 기본 원리를 참조하십시오.

소프트웨어나 패치를 게시할 때는 소프트웨어 릴리스 관행을 따르도록 노력하십시오.

감사의 글

이블린 미첼(Evelyn Mitchell)은 몇 가지 어리석은 질문 예를 제공하고 질문에 더 잘 대답하는 방법이라는 항목을 작성하도록 영감을 주었으며, 미하일 라멘딕(Mikhail Ramendik)은 특히 귀중한 제안과 개선 사항을 제공했습니다.

1개의 좋아요
基于STM32的同步整流Buck-Boost数字电源 开源
LCD1602 I2C模块无法显示字符
这样设计没问题吧，可以直接画PCB了吗？