개발자가 질문하는 방법 (회사, 상사, 커뮤니티, 개발관련 질문 등)

 

  이번에 진행중인 디자인 패턴의 아름다움 스터디에서, 책 내용관 관련 없지만, '질문하는 방법'에 대해 얘기해보자는 토론 주제가 나왔다. 그래서 내 생각을 정리해봤다.

 

  주의점 : 내 경험과 생각을 적어둔 것 뿐이니 정답은 아닐테고, 더 좋은 방법 역시 있을꺼다. 

'개발자가' 질문하는 방법이라 적어두긴 했지만, 사실 다른 업종도 비슷비슷할 것 같긴하다. 아무튼 내가 개발자니 다른 업종은 잘 몰라서 범위를 축소해 제목을 적어두었다.

 

  내 생각에 질문할 때 들어가야 하는 내용은 다음과 같다.

1. 현재 상황 설명

2. 내가 지금까지 해본 것(모르는걸 질문하는 경우) 또는 내가 생각하는 안건(어떠한 결정 사항에 대해 질문하는 경우)

3. 내가 알고 싶은게 무엇인지

 

 

1. 현재 상황 설명

• 질문 시 물어보는 사람이 헷갈려하면, 답변해줄 사람은 당연히 뭔 내용인지 알 수가 없다. 물론 답변자가 경험상 "아 그거 질문하시는거에요?" 라고 알아채는 경우도 있다. 하지만 이게 자주 발생하면 질문 하는 사람도 피곤하고, 답변하는 사람도 그 질문자의 질문 받는걸 회피하게 될꺼다.

 

• 그러니 우선 글로 먼저 현재 상황을 정리 해봐야 한다. 논리적으로 현재 상황을 정리하다보면 그것 자체로 문제가 해결되는 경우도 많다.

 

• 애초에 현재 상황 자체가 정리가 안된다면, 그냥 원래 하려던 질문을 하면 안된다. 그 경우 애초에 시작점을 못잡은거고, 내가 뭘 모르는지 모르는 상태인거다. 원래 하려던 질문은 우선 접어두고, 시작점으로 돌아가 우선 내가 뭘 모르는지를 알기 위해 질문 해야 한다.

 

• 듣는 사람이 누군지에 따라 현재 상황 설명에 쓰일 용어 및 범위를 달리해야 한다. 예를들어 이미 같은 프로젝트를 개발중이거나 운영중인 상황이라면, 그 프로젝트에서 쓰이는 용어로 질문해도 상관 없다. 하지만 프로젝트와 관련 없는 직원한테 상황 설명 없이 "A 서버 방화벽에 이거 추가해도 되요?" 해봐야 아무런 답변도 들을 수 없을꺼다. 또 비개발자가 대상이라면 그에 맞춰 쉬운 용어로 설명하거나, 비유로써 설명해야 한다. 개발자끼리야 "DB 이거 이중화하려면 비용 더 들고, 계속 폴링해서 정합성 잘 맞춰주셔야되요." 이래도 되겠지만, 비개발자에게 이렇게 설명하면 못알아들을꺼다.

 

• 나도 자주 범하는 문제점인데, 자기 머리속에서 정리됐다고 주어 다 때고 질문하는 경우가 생각보다 많다. 질문 받는 입장에서 어느정도 예상은 가능할 수도 있지만, 아닌 경우가 더 많을 것 같다. 그러니 우선 글로 정리해보고 자기가 질문 받는 입장에서 다시 한 번 읽어보는게 좋은 것 같다.

 

 

 

2. 내가 지금까지 해본 것 또는 내가 생각하는 안건

• 예를들어 내가 모르는 것을 질문하는 경우라면, 현재 상황을 설명한 후 내가 지금까지 시도해본 것, 알아본 것, 해본 것을 알려주는게 좋다.

 

• 또는 결정 사항에 대해 선택을 하지 못해 질문을 하는 경우라면 내가 생각하는 안건들을 미리 제시해주는 것이 좋다. 그 안건들이 아예 틀렸을 수도 있지만, 그건 나중 문제이다. 어쨌든 현재 내가 이해하고 있는 내 안건을 제시해줘야 답변해주는 사람도 질문하는 사람이 어느정도로 이해하고 있는지 알 수 있다.

 

• 이 경우 내 생각에 몇 가지 경우의 수가 좀 있다.
  • 아예 시작점을 못잡아 질문하는 경우 (내가 뭘 모르는지 모르는 경우) -> 그렇다면 '2' 보다는 '1'의 현재 상황 설명에 더 집중하는게 좋을 것 같다.
  • 해결은 했는데, 왜 해결됐는지 궁금한 경우. 맞는데 왜 맞음? (맞왜맞) -> '2'에 적을게 많을 것 같다. 내 궁금증을 해결하기 위해 더 피력해야 한다!
  • 난 암만봐도 맞는거 같은데 왜 안되는지 모르겠는 경우. 맞는데 왜 틀림? (맞왜틀) -> 이 경우라면 개인적으로 '2'를 최대한 중립적으로 알려주는게 좋은 것 같다. 애초에 결과적으로 틀린거니 내 생각이나 로직이 틀린 부분이 있을 확률이 높다. 여기서 내가 해본걸 확정적이라 생각하고 적극적으로 피력하면, XY Problem ('기타 팁' 참고) 으로 들어갈 확률이 높다.
  • 틀렸는데 왜 틀렸는지 모르겟는 경우 (틀왜틀) -> 대부분은 이 경우일 것 같다. 이건 뭐 '1', '2' 전부 적극적으로 피력하는게 좋다.

 

• '2'는 사실 사회 생활과도 관련있다 생각된다. 질문을 받는 사람은 결국 자기 시간과 노력을 질문하는데 사용하게 된다. 그렇다면 질문하는 사람도 나름대로 성의(?)를 보이는게 맞고, 그게 '2'에 해당한다고 생각한다. 흔히 '핑프'라 불리는 경우가 '2'가 아예 없는 경우일 것이다. 특히 상사에게 결정사항에 대해 질문하는 경우, 안건을 미리 생각안하고 질문하면 "너가 더 잘 알잖아. 너가 알아서 해 줘" 밖에 안된다. 몇 번은 괜찮아도 점점 답변해주는 사람이 피하는게 느껴질꺼다. 이건 역지사지로 생각해보면 너무 당연하다. 또한 이 과정이 있어야 답변해주는 사람도 질문자가 어디까지 이해하고 있는지 알 수 있기 때문에, '아 이거 어디부터 설명해야하지?' 와 같은 상황이 적어진다.

 

• '1'과 '2'는 동시에 진행되는 경우도 있다. 상대방이 충분한 배경지식이 있을거라 판단된다면, '2'만 얘기해도 '1'이 포함되는 셈이다.

 

 

 

3. 내가 알고 싶은게 무엇인지

• 명확히 어떤 지점을 알고 싶은지, 혹은 어떤 결정을 원하는지 얘기해주는게 당연히 더 좋다. 범위를 좁힐수록 더 상세한 답변이 올 거다. 코드만 해도 Object giveMeAnyAnswer(Object something); 보다는 입출력값 확실한게 더 좋은걸!

확실한 입출력

 

• 상황에 따라 다를 수 있긴한데, 보통 상사에게 질문할 경우 "어떻게 할까요?" 와 같은 식으로 질문이 끝나면 여러모로 안좋게 끝날 확률이 높다. 물론 동일 선 상에서 다 같이 해결해야하는 경우 의견을 묻는다거나, 아예 시작점을 못잡은 경우, 혹은 애초에 본인이 알 수 없는 사항에 대해서는 당연히 이렇게 질문해도 괜찮을꺼다.

 

• 다만 일반적 상황에서 "어떻게 할까요?"는 안좋은 질문 습관이라 생각한다. 커피 사러 갔는데 커피집 주인이 "카드리더기가 고장나서 결제가 안될꺼같은데 어떻게 할까요?" 라고 질문을 했다면 우린 "너가 해결해야지 나보고 어쩌라고?" 라고 생각날 수 밖에 없다. "카드리더기가 고장나서 현재 카드로는 결제가 불가합니다. 죄송하지만 계좌이체 해주시거나, 현재 수리를 불렀으니 1시간 뒤에 다시 와주시면 정말 감사하겠습니다." 라고 해야 될꺼다. 즉, 본인이 생각한 안건('2') 없이 광역기로 질문하면 안된다.

 

• 흔히 말하는 '오너십'의 관점에서, 일의 주인인 본인이 해결 방법이나 안을 먼저 찾고, 상사에게 질문하여 그 중 고를 수 있도록 하는게 좋다. 그래야 피드백도 받을 수 있다. 역지사지로 본인 아래로 후임 생겼고, 아래 질문을 받았다고 해보자. 둘 중 어떤 질문이 더 마음에 들지 생각해보면 답 나온다.
  • "방금 고객한테서 연락왔는데 결제가 안된다고 하는데 어떻게 할까요?”
  • "방금 고객한테서 연락왔는데 결제가 안된다고 해요. 확인해보니 어제 배포한 코드 부분이 잘못되어서, 일부 고객에게 문제 발생 여지가 있었습니다. 코드 수정해 봤는데 수정한 부분 확인해주실 수 있을까요?”

 

 

 

기타 팁

• Don't ask to ask, just ask (https://dontasktoask.com/) 
  • "~~ 질문좀 해도 될까요?" 이런거 물어보지 말고 그냥 질문하라는 얘기이다.
  • 물론 1:1로 물어보거나 상사(성격에 따라 다름)에게 물어볼 경우나, 초면인 경우라면 매너 차원에서 물어보는 것도 괜찮다.
  • 하지만 뭐 단톡같은데 물어보는 경우라면 특히 하지 말자. 마치 "너가 답변해줄 수 있다매" 느낌으로 부담을 안길 수 있다.

 

• XY Problem (https://xyproblem.info/)
  • 한마디로, A가 문제였는데 B로 질문하는 경우이다. 내 질문이 XY Problem일 수도 있다고 생각하고 주의해야 한다.
  • 내 경우에도 이러한 질문을 받아봤는데, 질문은 "이 API가 8분이상 걸려서 타임아웃 걸리는데 타임아웃 어떻게 늘려요?" 였다. 암만봐도 8분이상 걸릴만한 부분이 아니라서 코드를 확인해보니 String에 대한 '+' 연산이라 느린거였다. 코드 2줄 수정하고 0.1초로 시간이 줄었고, 타임아웃은 자동으로 아무것도 아니게 되었다.

 

• 특히 개발적인 질문의 경우 답변을 받았다면, 그 답변을 가지고 문제를 해결한 후 해결 인증을 하거나 감사인사를 올리도록 하자. 질문 받아주는 사람은 귀하다. 호감작 확실히 해야 한다. 물론 상대 성향에 따라(?) 방치해두는게 더 나을수도 있다.

 

 

 

내 질문 예시

• 문제를 맞추긴 했는데, 더 좋은 방법을 찾게 되어 다시 풀었었다. 근데 암만봐도 난 스스로 생각해내지 못할 것 같은 방법이었다. 그래서 따로 명칭화된 알고리즘이라면 더 공부해보고, 그게 아니었다면 내 머리를 탓하며 슬퍼하기 위해(?) 질문 올린 경우이다.

 

아 그리고 '기타 팁'에 있는 호감작도 해줘야 한다. 관련 문제까지 알려주셨다!

 

 

• 또 다른 예시이다. 현재 상황 설명과 내가 해본 것 위주로 질문했던 것 같다.

 

 

• 업무상의 질문 예시는 블로그에 올리기가 상당히 난감하다. 대강 아래와 같은 식으로 질문했었다.

- A. 클라우드에서 특정 서버에 어떠한 기능을 넣고자 하는 상황이다. (최대한 상세하게 작성했다.)

- B. 그런데 내 생각엔 ~~ 로 하면 될 것 같아 아래와 같이 진행했다. 하지만 원하는대로 되지 않는다.

- C. 혹시 'A'를 할 수 있는 방법이 있을까요? 아니면 제가 생각한 'B' 자체가 잘못된걸까요?

 

 

• 상사에게 결정 사항에 관해 질문하는 경우의 예시도 마찬가지로 블로그에 올리기가 상당히 난감하다. 질문을 위해 내 상황을 글로 적어보는 과정에서 만들어본 자료의 썸네일만 보면 다음과 같다.

현재 상황 설명 (네트워크 상에서 문제가 되던 상황)

 

해결을 위해 생각해본 내 안건 (내가 생각하는 해결안)

 

이걸 기반으로 질문을 했었다.