지식노동자의 팀에 필요한 의사소통은 다른 일반적인 사회생활이나 인간 관계에서 필요한 의사소통과 매우 다른 능력이 필요한 것 같다. 이를테면 핀 포인트를 정확하게 찔러서 표현하고, 또 이해할 수 있는 그런 능력. 하나만 맞아라 하는 식으로 산탄총을 쏘는 게 아니라 정확한 급소를 레일건으로 한 번에 찌르는 능력, 그런 것이다. 그런데 최근에 이 능력을 간접적으로 판단할 수 있는 방법을 찾아낸 것 같다.
"plain text로 자신의 생각을 정확하게 표현할 수 있는가".
표현하려는 생각의 옳고 그름을 떠나서, 자신의 생각을 정확하게 텍스트로 표현할 수 있느냐 하는 것이다. 꼭 그 표현을 많은 사람들이 잘 알아먹느냐 그런 의미는 아니다. 그냥 충분한 지적 능력이 있는 사람이 그 표현을 보고 깊이 생각했을 때 의도한 바에 똑같이 도달할 수 있는, 그런 표현을 할 수 있느냐 하는 것이다.
이 능력이 있는 사람은 의사소통 수단의 제약이 큰 상황에서도 비교적 손실 없이 표현을 해낼 수 있고, 그러면서 의사소통 수단이 다양해질수록 더 높은 표현력을 보여주는 것 같다. 반대로 자기 생각을 텍스트로 잘 표현 못하는 사람은 풍부한 의사소통 수단을 활용 가능한 상황에서도 지식노동에서 요구하는 수준의 정밀한 표현은 잘 못하는 경우가 많다.
이게 과연 일반화할 수 있는 가설일지 아닐지 고민해봤는데, 최근 몇 년간을 돌이켜보면 예외 없이 들어 맞는 것 같다. 적어도 메신저로 의사소통 잘하는 사람들 중에 대면 미팅에서 표현 잘 못하는 사람은 아무도 없었고, 그런 사람들은 회의에서 더 다양한 도구를 사용해서 자신의 생각을 표현했고, 짧은 표현에서 의미를 읽어내는 능력도 좋았다. 제약이 많은 상황에서 기본기가 드러나는 것과 비슷한 현상이 아닐까 싶다. 물론, 의사소통은 두 사람이 하는 것이라 이런 사람들이라고 해서 모든 의사소통에 성공하는 것은 아니지만, 비교적 빠른 시간 안에 오류를 교정해냈다.
나는 여전히 인재를 채용할 때 의사소통 능력을 그다지 중요하게 보지 않지만, 만약에 그런 걸 중요하게 봐야 하는 채용 건이 생긴다면 복잡한 문제에 대한 자신의 의견을 짤막한 텍스트로 정확하게 표현할 수 있는지를 테스트해 볼 것 같다. 심도 있게 실무 능력을 봐야 하는 경우는 커뮤니케이션 비용을 과도하게 들여서라도 면접을 봐야 하지만, 테스트해야 하는 것이 지식노동을 위한 의사소통 능력이라면, 의도적인 제약을 거는 것이 오히려 유리할 수도 있다.
그래서, 한 편으로는 코딩 테스트도 비슷한 요소가 필요할 수 있지 않을까 하는 생각이 든다. 나는 코딩 테스트할 때 슈도 코드로 하기보다는 실제로 돌아가는 코드를 만들도록 하는 방식을 선호해왔는데, 도구의 제약을 걸면 그 사람의 프로그래밍 기본기를 더 잘 볼 수 있는 것은 아닐까 하는 생각이 든다. 아마존도 슈도 코드로만 테스트를 했었는데, 그런 의도가 아니었을까. 좀 깊이 고민해봐야겠다.