엔지니어들과 비엔지니어들의 커뮤니케이션 방법 2가지

가끔 엔지니어와 비엔지니어가 커뮤니케이션하는 것을 보면 아쉬운 점들이 있다. 내 경험상 이 두 그룹의 사람들이 커뮤니케이션할때 중요한 것 2가지를 얘기해 본다.

What You Know, What You Don’t Know, What You Think

이 말은 전 미국국무장관 이었던 Colin Powell 이 한말로 유명한데 그는 어떤 사건에 관해서 상대방과 얘기를 할때 다음의 포맷을 썼다고 한다.

Tell me what you know. (너가 아는 것을 말해보라)

Tell me what you don’t know. (너가 모르는 것을 말해보라)

Then tell me what you think. (너 생각을 말해보라)

Colin Powell 은 주로 보안과 관련된 context 에 관해서 전략등을 짤때 위의 커뮤니케션이 효과적이었다고 하는데 위의 방법이야말로 엔지니어들이 커뮤니케이션을 할때 가장 명확히 해야하는 방법이다. 엔지니어들의 포맷에 맞게 조금 바꾸자면 -

1. This is something I know for sure (내가 확실하게 알고 있는 사실)

2. This is something I have no idea of (내가 전혀 모르고 있는 것)

3. This is something I’m guessing based on my knowledge (내 지식에 근거해서 추측하고 있는 부분)

엔지니어들은 주로 1번과 3번을 섞는 경우가 많고 심할 경우에는 2번을 1번으로 혼동하여 말하는 경우도 많이 있다. 엔지니어들은 특정 질문데 대한 답을할때 본인이 바로 며칠전에 직접 해봐서 기록으로 남아있지 않은 것이라면 2번 (내가 전혀 모르는 것) 혹은 3번(내 지식에 근거해서 추측)에 들어간다. 이중에서 3번(내 지식에 근거한 추측)이 가장 큰 부분을 차지한다. 수치화하기는 쉽지 않지만 경험상 ‘확실한 사실’ 은 30% 정도에 불과하다. 40%는 추측에 근거한 대답이고 나머지 30% 정도는 아예 모르는 부분. 그런데 많은 경우 엔지니어들은 질문을 받으면 팩트로 대답을 해야하는 일종의 강박관념 같은 것이 있다. 이부분은 물어보는 사람들이나 회사문화에도 문제가 있다. 비엔지니어가 엔지니어에게 물어볼때 뭔가 확실한 대답을 얻지 못하면 답답해 하는 경우가 많고 심한 경우 그 엔지니어가 무능하다고 생각한다. 이러니 종종 엔지니어들은 추측하는 부분을 사실처럼 말하는 경우가 있다 (실제로 혼동하는 경우도 많지만). 이것이 큰 생산성 소모와 시간낭비로 이어진다. 엔지니어가 어떤 특정질문에 대해서 실제로는 추측이지만 사실처럼 얘기를 했는데 그것이 잘못된 정보로 밝혀질 경우 그 다음부터는 그 엔지니어가 팩트라고 해도 늘 사실확인을 다시 해야하는 불편함이 생긴다. 하지만 이 3가지를 확실히 구분해서 말을 해주면 그 엔지니어가 추측이나 모른다고 하는 부분만 확인을 하면 되니 위의 수치상으로는 무려 30% 의 생산성 증가가 있는 셈이다. 나같은 경우에는 비엔지니어들과 대화할때 이부분을 확실히 명시해 둔다. 내 대답은 3가지의 카테고리중 어느부분이라고. 그리고 추측이나 모르는 대답일 경우 확인사실을 위해서는 약 얼마간의 시간이 필요하다고 얘기한다. 이정도만 하더라도 비엔지니어들과의 신뢰를 쌓는데 큰 도움이 된다. 추측이면 추측이고, 모르는 것이면 모른다고 당당히 말해도 전혀 거리낌이 없는 문화가 중요하다.

두번째: 이 기능은 개발이 가능한가요?

내가 본 몇몇 회사의 경우 아이디어 회의때 엔지니어들을 동반하지 않는 경우가 있다. 이유는 엔지니어들은 아이디어 회의나 기능에 관한 대화를 시작할때 그것이 기술적으로 가능한지 안한지를 먼저 생각한다는 것이다. 비엔지니어들이 이렇게 생각하는것을 나는 어느정도 이해한다. 나도 기능에 관한 아이디어를 얘기할때 기술에 대해서 아예 모르는 사람들은 좋다고 하는 경우가 많이 있는데 엔지니어들은 그 얘기를 듣자마자 머릿속에 구현을 먼저 생각하니 그 기능 자체의 유용성에 관한 생각은 뒷전으로 되버리는 것. 이럴때 내 경험상 의외로 간단한 해결방법이 있다. 회의나 대화전에 다음의 순서에 맞게 대답을 하게 하는 것이다.

1. Is this a good feature to develop? (기술적 구현을 다 떠나서 이것은 있으면 좋은 기능인가요?)

2. Then, can we develop it technically? (좋은 기능이라면 기술적으로 구현이 가능한가요?)

3. Then, when should we develop it? (기술적으로 구현이 가능하다면 언제 개발을 하는게 좋을까요?)

위의 순서에 따르자면 특정 기능을 얘기할때 일단 기술적 구현은 모두 잊어버리고 오로지 그 기능의 유용성만 생각한다. 여기서 통과가 되면 일단 그 기능은 to-do list 에 들어가는것. 그래서 2번째 기술적 구현을 얘기할때 불가능 하다면 바로 대화를 끝내면 된다. 많은 경우 IT 업계의 특성상(가파른 기술력 증가) 기술적 구현이 몇개월 혹은 몇주안에도 가능해질때가 많다. 하지만 처음부터 기술구현의 불가능으로 아예 리스트에도 있지 않다면 영원히 개발이 안되는 경우가 있다. 그 다음 기술적 구현에 관한 얘기를 할경우 많은 엔지니어들은 ‘저 기능을 만들기 위해서는 사람이 얼마나 많이 필요한데..’ 라는 생각으로 기술적 구현이 가능함에도 부정적으로 얘기하는 경우가 종종 있다. 그래서 3번의 질문이 있는 것. 기술적 구현도 가능하다고 하면 다음 ‘언제 개발하는 것이 좋은가?’ 라는 질문으로 지금 당장의 리소스로도 구현이 가능하다면 OK 인 것이고 상황이 힘들다면 역시 to-do list 에 올려놓는다. 그러면 언젠가 그 개발에 필요한 보충인력이나 자본이 확보되면 바로 개발을 할수 있는 상태가 되는 것이다. 여기서도 역시 엔지니어들의 커뮤니케이션 만큼 중요한 것이 비엔지니어들의 태도와 회사문화이다. 예를들어 특정기능에 관한 기술적 구현이 가능하다고 대답하면 ‘그럼 당장 개발하죠’ 라는 쉬운 대답이나 ‘엔지니어인데 이정도는 당연히 만들어야지' 라는 생각보다 현재의 리소스로 개발이 가능한지에 관한 대화가 뒤따라야 한다. 많은 경우 엔지니어들은 ‘개발이 가능합니다' 라는 대답을 하면 비엔지니어들이 바로 당장 개발을 하자는 의견을 보여서 당혹스러워 하니 실제와 다르게 대답하는 경우가 종종있다.