1. 좋은 질문을 하는 방법을 배운다.

질문을 대강 하면 돌아오는 답변도 대강입니다. 그걸 보는 답변자의 기분 문제는 둘째치고 문제 상황이 뭔지 모르니까요. 전공 지식을 조금이라도 안다면 엄청난 도움이 되겠지만 그게 되면 이미 답을 스스로 찾을 레벨일 것이기 때문에 본인의 상황을 스크린샷이건 의심가는 이전 상황이건 서술을 최대한 자세히 하는 방법을 터득하세요. 로그도 첨부하면 금상첨화.

2. 질문 전에 어느 정도의 리서치라도 한다.

제발, 제발 네이버에서 찾아보고 해결책이 없다는 소리는 하지 마세요. 검색 결과가 많은 구글을 써 보는게 합리적이지 않겠습니까? 그리고 컴퓨터 문제는 마치 의학의 문제와도 같아서 여러 요인이 동일한 증상을 유발할 수 있기 때문에 의사들이 까다로운 진단을 내리듯 가능성이 높은 선택지에서 하나 하나 가능한 해결책을 소거해 나가기 마련이라, 시도의 결과를 알려주는 것 만으로 해결까지 가는 시간을 월등히 줄일 수 있습니다. 윗 질문과 이어서, 리서치를 한 사람은 문제 해결에 도움이 되는 정보가 뭔지도 알게 되기 마련입니다. 실력향상과 답변자의 좋아지는 기분은 부차적이구요.

3. 영어와 친해진다.

프로그래머들 사이에 도는 농담이 있습니다. 구글신은 영어로만 신탁을 내린다는. 현대적 컴퓨터의 발상지가 미국이기도 하고 미국이 테크 중심지이기도 해서, 당연히 이슈 대응도 영어 자료가 많게 마련입니다. 한글 자료는 그 중에서도 쉬운, 일반적인, 요약된 버전이 대부분입니다. 또 영미의 주력 커뮤니티가 질문과 답 찾기에 체계와 분위기 자체가 특화되어 있기 때문에, 영어를 하시는 순간부터 여러분이 접하게 되는 정보의 양과 질이 달라집니다.

4. 하드웨어가 아닌 이상 겁을 내지 않는다.

시스템을 설계한 모든 사람은, 위험에 대비해 보험을 마련합니다. 그 말은 컴퓨터공학에서 대개 되돌릴 수 없는 상황은 별로 없단 말과 같습니다. 누군가 조언하면 일단 시도해 보세요. 해 보기 전에 두려워서 안 된다고 하면 답이 안 나옵니다. 아무리 심각해도 운영체제 재설치 이상의 문제가 있겠습니까?(대개는)

5. 대비책을 자주 마련한다.

4와 이어지는 내용인데, 대비책을 마련해 두어야 최악의 상황에 재시도를 할 수 있게 마련입니다. 소스코드의 경우에는 git으로, 파일의 경우에는 파일 스토리지 클라우드 서비스나 NAS 혹은 백업 스토리지로 미리 안던하게 대피를 시켜 두세요. 꼬이고 꼬여도 다시 구할 수 없는 자료들만 안전하다면 약간의 시간만 들이면 다시

복원할 수 있습니다.

6. 대세를 따르세요.

새로 나온 것들이 아무리 좋다 한들 제대로 돌아가지 않거니 위험하다면 무의미합니다. ‘새롭다’를 바꿔 말하면 ‘검증되지 않았다’ 입니다. 해당 솔루션의 문제 상황 해결법도 많이 공유되지 않았고 사용하는 좋은 방법도 연구되지 않았다는 것이죠. 본인이 로그 단위에서 정보를 얻고 해결할 수 있는 상황이 아니거나 해당 솔루션의 주력 커뮤니티에서 답을 얻을수 있단 확신이 없으면 쓰지 마세요.

7. 답변자를 존중하세요.

답변을 한 사람은 기본적으로 질문자에게 무언가를 베푼 사람입니다. 작게는 시간부터 크게는 지식, 해결책까지요. 그 사람이 낸 아이디어가 충분히 만족스럽지 못하다 해도 그 사람은 할수 있는 한 최선을 베푼겁니다. 짜증내거나 무례한 말투를 사용하거나, 지속적으로 요구하기만 하는 자세만 보이지 않아도 답변자의 호의는 알아서 깎이지 않을 겁니다. 최소한 ㄱㅅ 두 글자 치는것도 그리 어렵지는 않을 테니까요.

윗 내용들만 지켜도 훨씬 건전한 정보 교류가 가능해질 겁니다. 회사 일로 열받아서 주절거렸네요. 뭐 여기에 딱히 그런 분이 보인다는 건 아니고…