서로 불편하지 않게 질문하는 방법

프로그래밍이랑 컴퓨터 공부를 하다 보면, 질문할 일이 정말 많다. 저ㅓㅓㅓㅓㅇ말 많다.

요즘 들어 질문을 받게 되는 일도 많아, 어떻게 하면 질문자와 답변자가 불편하지 않을 수 있는지 다루는 글을 적어보기로 한다.

 

* 이 글은 이경문 멘토님의 <질문하는 요령> 을 참고했음을 알립니다.

https://gilgil.gitlab.io/2019/08/02/1.html

** 글을 쓰는데 같이 도와준 숑숑 친구에게 감사 ㅎ

질문하는 요령

 

---

0. 질문하기가 무서워요!

 

친구들에게 질문을 하자니, 내가 잘 모른다는 것을 알리기 싫고. 선배한테 물어보자니, 아는 선배가 없거나 겨우 이런거 물어보자니 눈치보이고. 교수님들은 너무 먼 곳에 계신 분 같아 선뜻 물어보기가 뭐하다.

 

사실 구글이라는 좋은 친구가 있기 때문에, 서치 능력이 좋은 사람이라면 구글링으로 거의 모든 정보를 찾을 수 있을 것이다. 하지만 대부분은 분명 구글링을 한다고 하는데도 마땅한 결과가 나오지 않는 경험을 해본 적이 있을 것이다. 질문도 못하고, 구글링도 못하고, 내 과제는 진행이 안되고. 막막할 수 있다.

 

  우선, 선배나 교수님들의 "구글링하면 다 나와." 또는 "구글링해서 나오는거 질문하지 마" 의 의미는 생각보다 그렇게 칼같지 않다.

전자의 경우는 사실이긴 하고(대부분 입문자의 질문은 스택 오버플로우에서 누군가가 이미 질문을 했을 것이다), 그럼 이제 알아볼 것은 후자. 사실 어떻게 보면 당연한게, 답변자 입장에서 질문자가 한 질문에 대한 답이 1초만에 1페이지 상단에 뜰 경우, 기분이 나빠지는 경우가 있다. "겨우 이거 하기 귀찮아서 질문한건가?" 같은 느낌으로.

  그런데, 실제로 자기가 구글링을 했을 때에는 답이 나오지 않는 경우가 있었을 것이다. 이럴 경우에는 질문의 방법을 살짝 바꿔보면 서로가 더 편해질 수 있다.

C에서 받아온 인자값이 파일인지 디렉토리인지 확인하고 싶은데 어떤 키워드로 구글링을 해야 할까요?

이렇게 "키워드" 에 대한 질문을 하면, 답변자도 시간을 많이 뺏기지 않고 질문자 또한 구글링을 하는 스킬을 키울 수 있다. 결국 구글링은 키워드를 어떻게 넣냐의 문제이기 때문에, 이런 식으로 자신이 고민하고 있는 부분에 대해 어떻게 하면 답을 찾을 수 있는지 키워드를 추출하는 센스를 키울 수 있다.

 

 

1. 질문을 할 때 기본으로 해야 할 사항

이제 0번을 지나서, 단순히 키워드를 묻는 것으로 해결이 되지 않는 질문들이 있을 것이다. 간단하게 사례를 들어 생각해보자.

 

A. 코드에 대한 질문

arr[5] += 'a'; 라고 썼는데 오류가 나요!

이렇게 질문을 하면 답변자 입장에서는 어디가 문제인지를 알 수 없다. 게다가 오류가 났는데 오류문을 알려주지 않는다? 사막에서 바늘을 찾으라는 것과 같은 느낌이다. 컴파일러에서 오류를 알려주는 것은 정말 친절하게 고칠 수 있는 error인 것은 덤이고. 이런 경우 질문자가 질문 전에 해주어야 하는 것은 다음과 같다.

 

- 오류에 대한 구글링을 진행한다 (대부분은 여기서 해결이 가능합니다)

- 구글링을 하던 중, 어떤 문서의 일부분에 대해 이해하지 못한다면 문서 + 오류코드 + 본인의 코드 전문 을 질문자에게 준다.

 

그런데 코드가 잘못되었을 때, 오류가 항상 보여지는 것은 아니다. 논리 에러라면 오류 없이 그냥 프로그램이 터지는 경우도 있으니까. 하지만 이럴 경우에도, 아래와 같이 질문을 하는 것은 추천하지 않는다.

이름을 입력했는데 그 다음에 프로그램이 꺼져요!

입력 이후에 프로그램이 터질 수 있는 이유는 수도 없이 많다. 그 상황 뿐만 아니라, 그 상황을 일으키게 한 원인들을 같이 보여주어야 한다.

 

- 코드 전문

- 터지는 부분의 캡쳐화면

- 자신이 어떤 값을 입력했을 때 오류가 났는지

 

사실 코드의 문제는 저학년때는 대부분 디버깅으로 해결할 수 있다. (고학년이 되어도 쌩으로 로우레벨 프로그램을 올린다거나 하는 환경이 아니면 디버깅에서 문제를 찾을 수 있다) 디버깅 얘기를 여기서 하긴 좀 길어지니까, 평소에 VS 같은걸 사용하면서 어떻게 디버깅을 할 수 있는지 익히는 것이 편할 것이다.

 

 

B. 실습 등에 대한 질문

이제 관련 툴 실습을 하다 보면 원하는대로 되지 않는 경우가 분명 생긴다. 익숙하지 않은 사람들은 설치부터 문제가 생깁니다. 난처하죠. 하지만 여러분이 어디서 듣지도 못한 새로운 툴을 가져오는게 아닌 이상, 어딘가에 설명한 문서는 분명히 존재합니다. 그런데도 질문을 하고 싶다면, 아래와 같이 하지는 맙시다.

와이어샤크로 실습을 해야 하는데 저는 예시의 부분이 잡히지 않아요!

어떤 예시를 하는지, 어떤 환경인지, 어떤 실습인지, 어떤 필터를 했는지, 적어도 캡쳐라도!  

적어도 답변자가 질문자가 어떤 상황에 있는지 확인할 수 있을 정도의 충분한 정보를 줍시다. 

 

 

2. 질문을 올리면서 지켜주면 좋을 부분

A. 가급적이면 퍼블릭한 채널으로!

정말 많은 사람들이 질문이 있는데 오픈카톡으로 와라, 아니면 개인톡으로 질문을 하거나, 아무튼 최대한 자신의 질문을 프라이빗하게 하려고 한다. 하지만 스택 오버플로우가 괜히 공개적으로 밝혀져 있는 것이 아니다. 질문자는 자신의 질문에 부끄러워 할 필요가 없으며, 그에 대한 답변을 혼자 독차지할 권리가 없다. 당장은 나 혼자 알고 있는 것이 좋겠다, 라고 생각할지도 모르겠지만 질문은 공개적으로 하여 나중에 같은 질문이 있는 사람이 찾아볼 수 있게 하는 것이 모두에게 좋다.

특히 에브리타임의 경우, 무슨 질문인지 말도 안하고 오픈카톡으로 오세요 라고 하는데 제발 하지 마라. 만약 그 질문이 자신의 과제를 공개해야 하는 부분이라서 하는거라면 더더욱 하지 마라. 과제와 같은 사항은 그렇게 직접적으로 도움을 받아서는 안된다고 생각한다. 그냥 부끄러워서 그러는거라면, 에타 어차피 익명인데 대체 왜 그러는건지??? 

 

오픈카톡, 갠톡으로 오세요의 가장 큰 문제점은, 서로에게 비효율적이라는 것이다.

- 오픈카톡을 가는 것 자체가 귀찮음

- 어찌저찌 오카방을 들어가서 질문을 들었는데 답변자가 모르는 내용이다? 처음부터 리셋

- 만약 답변자가 답을 틀렸을 때, 이를 수정해줄 사람이 없음.

 

결론 : 가능하면 서로 도울 수 있게, 퍼블릭한 채널에서 질문을 합시다.

 

 

B. 질문해도 될까요? 하지 마세요

어차피 질문을 하러 간 사람한테, 질문해도 될까요? 라고 물으면 네 하고 답해주는 시간이 더 걸린다. 대면도 아니고, 온라인으로 물어보면 그 과정이 몇 분은 더 걸린다. 

서로 시간 뺏지 말고, 바로바로 본론으로 들어갑시다. 이건 위에 첨부한 링크에서 다룬 내용이니 빠르게 생략.

 

 

C. 질문하는 내용의 주체가 뭔지 밝히세요 

이건 요즘 에타에서 많이 일어나는 문제라고 생각한다. 기껏 학우들이 질문한 사항을 도와줬는데, 까고 보니 그게 과제였다니. 솔직히 얼굴도 모르는 사람의 성적을 내가 올려준 꼴이 될 수도 있는 것이다. 

위에서도 말했듯이, 과제는 자신의 실력을 평가하는 매체이다. 이를 남의 도움을 직접적으로 받아 완성한다? 본인 스스로 그것이 정당한 방법이라 자신할 수 있는가?

 

이런 문제를 예방하기 위해, 질문자는 최소한 질문하는 내용이 어떤 것에서 나온 것인지 명시해야 한다고 생각한다. 개인 공부인지, 아님 단순한 개념 복습인지, 과제에 대한 질문인지.

 

그리고 이건 개인적인 의견이지만, 답변자들은 과제에 대한 답을 해주는 것을 피했으면 좋겠다. 선한 마음으로 도와준 것이겠지만, 같은 수업을 듣는 다른 학우에게는 피해가 갈 수 있다고 생각한다.

 

 

3. 질문을 올리기 전에 알면 좋을 부분

A. 디버깅

VS에서 디버깅을 통해 간단하게는 자신의 코드가 어떻게 동작하고 있는지, 변수들이 어떻게 변화하는지 등을, 깊게는 프로그램의 동작을 세부적으로 확인할 수 있다. 코드에서 발생하는 문제는 디버깅을 통해 내 프로그램이 어떻게 동작하는지 까보면서 원인을 찾고, 해석해볼 수 있다. 1학년이든 2학년이든 그 이상이든, 디버깅은 앞으로 프로그래밍을 할 때 필요한 것이라 생각한다.

F5를 눌렀을 때 뜨는 무서운 창에 대해 겁을 먹지 말고, 어떻게 쓰는 것인지 차근차근 배워보면 좋을 것이다.

 

B. 레퍼런스 및 공식 문서

각종 프로그래밍 언어들에 대한 설명서부터, 각 툴(프로그램)에 대한 공식 설명서는 거의 존재한다. 프로그래밍 언어에 대한 레퍼런스는 무조건 존재한다. 자신이 쓰는 함수가 어떤 건지 이해를 못하겠다면, 공식 문서 or 레퍼런스부터 찾아보자.

C언어의 printf 레퍼런스 검색 결과

실제로 저 안에 가보면, 함수의 원형, 각 파라미터에 대한 설명, 그리고 함수의 리턴 값, 친절한 곳은 이 함수의 용례를 보여준다. 이것만 읽어도, 함수 하나가 어떻게 동작하는지는 간략하게나마 이해할 수 있다. "이 코드가 무슨 뜻인지 모르겠어요" 를 묻기 전에, 각 함수가 어떤 역할을 하고 있는지 알아보고 다시 한번 코드를 읽어보자.

 

 

C. 영어는 기본.

그렇다고 토익을 막 900점을 넘으라는 말은 아닙니다. 단순하게 영어 원문 레퍼런스를 읽어서 해석할 수 있는 정도면 된다.

기초적인 개념에 대한 자료는 한국어로도 많이 있지만, 아무래도 내 질문의 depth가 더 깊어질수록 한국어로는 나오지 않는 경우가 있다. 아무래도 영어권 사용자가 훨씬 많고, 프로그래밍 자체가 영어를 기반으로 이루어지기 때문에 영어로 서치하는 것이 한국어 서치보다 압도적일 수 밖에 없다.개인적으로는, 결과가 나오지 않을 때만 영어를 쓰는 것보다 구글링할 때 항상 영어 키워드를 쓰는 것이 좋다고 생각한다. 어차피 한국어 결과가 나올 것은, 영어 키워드로 써도 알아서 나온다. 당장은 영어로 된 긴 글을 보기 어려울 수 있지만 읽다 보면 내가 해석해야 할 부분은 익숙해지고, 해석이 된다. 당장 내가 해결해야 하는 부분에 대한 답인데, 한국어인지 영어인지가 중요할까?같은 관점에서, 툴들도 영어로 쓰면 오류 등을 서치하는데 도움이 된다.

 

 

 

결론

솔직히 저는 개발 및 보안 분야에서 고인물이 아닙니다. 그냥 있는 학생1이에요. 그런데도 불구하고 제가 답변자로 있는 케이스가 많아졌고, 그에 따라서 요즘 느낀 점들을 한번 정리해보았습니다.현재 질문을 많이 하는 입장에 계신 분들. 당장은 이 글을 읽으면 뭐가 저리 유난인지, 하기 싫으면 답을 안하고 넘어가면 되는 것이 아닌지 생각할 수도 있습니다. 하지만 그런 사람들이 많아지면 이 분야에서 자리잡힌 질문에 대한 에티켓이 무너진다고 생각해요. 구글링을 통해 볼 수 있는 모든 자료들은 질문자와 답변자가 서로의 에티켓을 지켜 만들어낸 자료입니다. 단순히 본인의 편함 하나를 위해, 이렇게 쌓인 수많은 것을 무너뜨리진 맙시다.서로가 윈-윈이 될 수 있는 질문 문화(?) 가 이뤄지길 바랍니다:)