강남역에서 부산역으로 가려면 서쪽으로 가야 하나 동쪽으로 가야 하나?

이런 질문을 받는다면 어떻게 답할 것인가? 쉽게는 경부고속도로를 타기 위해서 서쪽으로 간다고 말할 수도 있다. 혹은 동쪽으로 가서 중부 고속도로를 타는 것이 낫다고 말할 수도 있다. 동도 서도 아닌 일단 남쪽이라고 말하는 사람도 있겠고 서울역쪽으로 가서 기차를 타겠다고 말하는 사람도 있을 것이다.

하지만, 누군가 한겨울에 반팔에 자전거를 타고 이런 질문을 한다면 조금 다른 것들을 답하게 될 것이다. 지금 바로 출발할 것인지, 왜 부산에 가려고 하는지, 예산은 어떻게 되는지 등 더 많은 질문과 현황을 파악한 다음에야 답을 하게 될 것이다. 그리고 그 답은 교통에 대한 정보 일 수도 있지만, 가까운 자전거 보관소에 대한 정보가 될 수도 있고, 내 옷을 벗어주는 것이 될 수도 있다.


내가 엔지니어 또 관리자로서 늘 듣는 질문은 종종 매우 비슷하다. “서버가 필요한데 Java가 좋을까요 아니면 Python이 좋을까요?”, “관리자 페이지에 버튼 하나가 필요한데 며칠이나 걸리나요?”, “개발자는 어떻게 채용해야 하나요?” 이 질문은 보는 것과 달리 보통 충분한 또는 좋은 선택지가 없다. 좋은 선택지가 없을 때에는 상황을 파악 다음 질문과 선택지를 다시 정리하고 답을 한다. 대부분의 전문가의 일이 그렇다. 개떡같이 말할 때 찰떡같이 답해야 하고, 이를 억울해 할 수는 없다. 그러나, 이런 상황이 반복된다면 조금 다른 이야기를 할 수 있다. 1


불필요하게 닫힌 질문은 단순히 경험의 부족일 수도 있지만 조직의 구조적인 문제와 태도, 능력 부족 혹은 과한 자기 확신, 무례함과도 종종 연결되어 있다. 잘못된 선택지로 축약된 질문은 문제를 제대로 이해하지 못했거나, 문제를 제대로 정의하지 못한 것에서 오는 경우가 많다. 다른 의도가 숨어 있어서 그런 경우도 있다. 그래서 이런 질문을 답할 때는 문제를 다시 정의하고 답을 찾는 것도 중요하지만, 더불어 이러한 질문이 나온 배경에 대해서도 고민하고 답을 해야 한다. 생각보다 단순하지도 쉽지도 않은 일이다.

언젠가 어떤 엔지니어가 위에 적은 것과 비슷한 질문을 2 한 적이 있다. 서쪽 동쪽을 떠나 부산으로 가는 수많은 교통편에 설명하다, 현재 상황과 너무 무관해서 물어보니 돌아온 답변은 비유하자면 “점심에 국밥이 먹고 싶어요”였다. 점심 메뉴를 고르라고는 했지만, 그럼에도 불구하고 부산에 돼지국밥을 먹으러 가는 선택을 하면 왜 안 되는 가를 어떻게 설명해야 하나 고민하는데, 별일 아니라는 듯이 짜증 내며 “그냥 서쪽인지 동쪽인지만 알려주시면 알아서 갈게요”라는 말이 나왔다. 그의 상황과 의도를 알았기에 나는 더 이상 그에게 틈이 있는 일을 주지 않았다.


의견을 구하는 질문에서는 충분한 정보와 열린 선택지 그리고 시간이 필요하다. “A와 B 중에 뭐가 좋나요?”, ”개발 언제까지 되나요?”가 아니라 “~~~ 때문에 ~~~~ 을 하려고 합니다. A와 B 중에 어떤 게 좋나요?” 여기에 시간과 의견을 더하면 더 완벽하긴 하다. “~~~ 까지 결정해야 하는데 제가 생각했을 때는 A가 최선인 것 같고 B도 고민해 본 상황입니다.” 이런 것들을 정리해서 이야기하면 더 풍부한 이야기를 들을 수 있다. 이것은 예의에 대한 이야기가 아니다. 효율에 대한 이야기다.

열린 질문을 하는 것을 다시 말하면 오버커뮤니케이션이라고 한다. 선택지만 제시하는 것이 아니라 문제와 배경에 대해서 설명하는 것. 단순히 선택지에서 선택만 하는 것이 아니라 선택의 이유에 대해서 혹은 선택지에 없는 것도 물어보며 답해주는 것이 오버커뮤니케이션이다. 열린 질문을 하고 답하는 것은 분명 최적의 방법은 아니다. 하지만, 이를 이용해서 잘못된 선택지로 인해서 문제가 생길 확률과 문제가 발생했을 때 해결할 수 있는 시간을 줄일 수 있다. 단기적으로는 최적에서 멀어지지만, 장기적으로는 최적에 더 가까운 결과를 얻을 수 있다. 스몰톡이나 회식처럼 발산되는 대화들은 감정적으로는 가까워지만 문제 해결에는 도움이 안 된다는 점에서 오버커뮤니케이션의 주가 될 수는 없다.


이 모든 이야기를 요약하면 질문에 대한 이야기이다. 좋은 답은 좋은 질문에서 온다. 또, 성장에 대한 이야기이기도 하다. 좋은 질문은 경험, 훈련, 태도에서 나온다. 시간이 지나고 경험은 쌓이겠지만 태도는 쉽게 변하지 않는다. 내가 최선을 다한다고 해도, 내가 모르는 것을 타인에게 최적의 상태로 질문을 할 수는 없다는 것을 인정해야 한다. 또, 좋은 답을 해줄 수 있는 사람들과 함께하는 것이 중요하다. 아무리 배경이 화려해도, 질문을 듣는 귀와 말하는 입이 없는 사람은 그 배경이 전부인 경우가 많다.

나에 대한 이야기이기도 하다. 충분히 질문하고 있는가. 충분히 답하고 있는가. 혹시 구조적으로 잘못되어 좋은 질문과 답이 오갈 수 없도록 하고 있는 것은 아닌가? 내가 했던 수많은 잘못된 질문에 대해서 좋은 답을 준 이들에게 감사하고 있는가. 내가 잘못 대답한 것에 대해서 되잡으려고 노력했는가. 하나하나 되돌아보다 보니 문제에 관심 없는 사람이 질문을 무기 삼는 상황에 괴로웠던 예전이 떠오른다. 말을 더 해야 한다.


  1. 그래서 위와 같은 질문에 대한 답은 전혀 다른 언어, 기능 구현 없이 점검시간에 일괄처리, 개발자가 아니라 서비스도입이 필요한 상황이 되기도 한다. ↩︎

  2. 물론 실제로는 서버 아키텍처에 대한 기술적인 내용이었다. ↩︎