칼럼 | IT 기술(記述)이 화술을 대체할 순 없다

문서와 커뮤니케이션을 절대 혼동하지 말자. 문서의 목적은 '의사소통'이 아니라 '상기'다. 
 

한 번은 필자가 컨설팅 서비스를 제공하는 비즈니스 애널리스트 중 한 명이 이런 질문을 했다. 그는 한 기술 문서를 내밀며 "이 정도면 나름 잘 만든 스펙(spec) 문서라고 할 수 있나"라고 물었다. 

필자는 '누군가 조언을 구한다면 사실 동감해주길 원하는 것'이라는 격언의 지혜를 오래전 어렵게 깨달은 바 있다. 그래서 질문을 한 이유를 물으며 똑같이 반문했다. 

아니나 다를까 애널리스트는 "이 문서를 개발자에게 주자 너무 못 썼다고 평가했다. 그래서 당신의 의견을 물어본 것"이라고 말했다. 

역시 동조자를 찾고 있는 게 맞았다. 

그래도 나는 기술 스펙 문서를 살펴보았다. 대부분의 기술 문서와 같이 어느 정도 괜찮은 문서였다. 그러나 똑같은 이유로 별로이기도 했다. 문제는 바로 이 기술 문서가 소통의 창구로 쓰였다는 점이다. 

이는 흔한 패착이며, 비즈니스 애널리틱스나 애플리케이션 스펙에만 국한되지 않는다. CIO, IT 관리자 그리고 일반적인 기업 전반에서 일어나는 일이다. 

기술 문서가 불가피할 때가 있음에도 여러 사람의 동의를 얻고자 한다면 이는 형편없는 차선책에 불과하다. 

의사소통을 위해 문서를 사용하는 것이 왜 의사소통의 본질을 무시하는 일인지 알아보자. 
 

문서 소통의 4가지 근본적인 결함 

문서를 통해 의사소통하고 기업의 모든 이가 이를 따르도록 독려하고자 하는 경우, 의사소통의 4가지 목적 모두에서 차질이 생긴다. 

언어(language)의 근본적 한계: 영어, 라틴어 혹은 심지어 에스페란토어까지 모든 자연어는 부정확할 수밖에 없다. 언어는 상징일 뿐이며, 단어는 다른 단어에 의해 정의되어 무한한 재귀(recursion)의 길로 우리를 인도한다. 수많은 사람은 자신이 읽고 있는 내용을 해석하고자 제각기 다른 어휘로 자신만의 가정을 내린다. 

모호함 해소(Disambiguation): 아무리 훌륭한 작가라도 모호성이 전혀 없거나 얽힌 논리를 완벽하게 풀어낸 글을 작성할 순 없다. 안타깝지만 어떤 사람들은 설사 이러한 시도를 하더라도 결과적으로 계약서 같이 딱딱하고 모호성으로 가득한 글을 쓰고 만다. 이를 읽어야 하는 이들은 최종 사용자 라이센스 계약(EULA) 같은 난해한 글을 이해하는데 헛수고를 거듭한다. 

반대와 갈등(Disagreements): 비즈니스 애널리스트(앱 개발 예제로 돌아가면)가 자신의 설계를 아무리 잘 설명하더라도 이를 만들기 위해 협력하는 이해 관계자들이 늘 모든 지점에 동의할 순 없다. 이해 관계자 비동의(stakeholder disagreements)는 필연적으로 설계 타협 그리고 최악의 상황에는 일관성 없는 스펙으로 이어진다. CIO가 작성하는 예산안도 비슷한 어려움을 겪는다. 

중재(Intermediation): '탈중재화(Disintermediation)'는 현실에서 찾아보기 힘든 고상한 단어다. 대부분 IT 팀은 중재자를 원하기 때문이다. 예컨대 사업부와 소통하기 위해 비즈니스 애널리스트가 중간에서 소통을 조율하는 경우가 많다. IT 기술자와 사업부 담당자는 서로 말이 안 통한다는 편견 때문이다. 

놀랍게도 이 터무니없는 편견이 수십 년 동안, 마치 하나의 불변의 진리인 양 유지됐다. 진작에 타파해야 했는데 말이다. 

기술 전문가들이 기술 전문가가 아닌 이들과 효과적으로 대화할 수 없다면, 이들은 어떻게 기술 전문가가 아닌 배우자와 결혼을 하고 생애 첫 단어가 "엄마!" 혹은 "아냐!"인 아이들을 기를 수 있을까? 마케팅 혹은 회계 관련 직업을 가진 이웃과는 어떻게 함께 바비큐를 즐길 수 있을까? 개가 자신의 음성 명령에 반응하도록 어떻게 훈련시킬 수 있을까? 

CIO는 이러한 함정과 편견에 정정 빠지곤 한다. 아직도 조직 차트(org chart)를 소프트웨어 모듈 컬렉션처럼 취급하는 CIO가 있다. 외부 사용자가 와도 똑같이 따를 수 있는 단일 방법론을 설정하고, 루틴을 정해놓는다. 다른 모든 임원이 동일한 방식으로 기업을 볼 수 있도록 노력한다. 

그러나 완벽한 조직 차트가 없는 것처럼, 각 부서의 인풋과 아웃풋을 소프트웨어 프로그램처럼 규정할 방법은 없다. 
 

대화가 해결책이다

소통의 문제는 IT 설계 문서에만 국한되지 않는다. 문서 기반의 의사소통은 하나의 사례일 뿐이다.

그럼 대안은 무엇일까? 아마 너무 당연해서 김이 빠질지도 모른다. 서로를 이해하려면 역시 대화가 유일한 답이다. 적극적으로 경청해 생각을 주고받아야 한다. 

관심을 표시하기: 경청하고 있는 사람, 혹은 사람들이 말하려는 내용에 실제로 관심을 보인다는 것을 확실히 보여줄 필요가 있다.

상대방이 말하게 하기: 내가 원하는 주제에 대해 이야기하고 있지 않더라도 상대방이 이야기하고 싶어 하는 것에 귀를 기울이자. 내가 필요로 하는 것에 집중하기 전에 다른 사람이 자신의 필요를 표출하도록 할 필요가 있다. 

집중하기: 이야기하도록 하는 것과 한없이 이야기하도록 두는 것은 다른 문제다. 때로는 중간에 끼어들어 말하는 사람이 삼천포에 빠지지 않도록 상기시켜야 한다. 

질문하기 (1) - 명확히 설명하기: 커뮤니케이션 대상이 무엇을 이야기하고자 하는지 명확하지 않을 경우, 추가 설명을 요청하자. 

질문하기 (2) - 다시 설명하기: 대화 상대가 나의 말을 이해하고 있는지 확신이 서지 않을 경우, 나의 관점이 아니라 그들의 관점에서 다시 설명하도록 요구할 수 있다. 

질문하기 (3) - 완료하기: 논의한 내용을 문서로 만들 때는 결론을 정확히 어떻게 표현할지 확인하자. 

상기시키기: 문서가 완료되면 이미 나눈 대화 내용이 반영되었는지 확인하기 위해 주요 이해 관계자와 대면으로 함께 검토하자. 

이 모든 게 다소 이상적으로 보일 수 있다. 모든 이해 관계자와 늘 대면할 수는 없으며, 주제가 커질수록 더 어려워진다. 

예외에 경우도 있다. 나 자신이나 대화 상대가 유창한 언어가 다르다면 대화보다 문서가 더 나을 수 있다. 

이렇듯 때로는 의사소통을 위해 문서에 의존해야 한다는 점도 인정한다. 여러분이 지금 이 글을 읽을 때처럼 말이다. 

*Bob Lewis는 IT 및 비즈니스 효과성 분야를 전문으로 하는 IT 컨설턴트다. ciokr@idg.co.kr