by
Jun 19. 2018
코드만큼 중요한 의사소통
문서 작성을 너무 미워하지 말자
나 같은 공대생들에게 글쓰기는 언제나 아킬레스건이었다(물론 지금 나도 그렇다). 대학교 교양수업 시간에 책을 읽고 A4 용지 한 장 짜리 독후감을 써오는 과제가 있었다. 문과인 룸메와 같이 들었던 수업이었는데 과제를 받았을 때 나와 룸메의 반응은 정반대였다. 친구는 어떻게 A4 용지 한 장에 자신의 생각을 모두 담을 수 있냐며 3장짜리의 글을 한 장으로 줄이느라 고통스러워하는 반면 나는 A4 용지 한 장을 채울 말을 생각하느라 애를 먹었고 마감 직전에 글자 포인트를 조금 키우거나 글 사이의 간격을 조정해서 가까스로 제출을 하곤 했다. 늘이고 키운 글이라도 글솜씨가 훌륭했으면 괜찮았을 텐데 그마저도 아니었다. 교수님에게 되돌려 받은 독후감 용지에는 빨간 글씨로 된 피드백이 수두룩했다.
글쓰기가 별로라면 말이라도 좀 잘했으면 좋으련만. 발표 능력은 글쓰기 능력과 철저히 비례했다. 발표 자료 작성 시 금기 사항을 신입생 때의 나는 매우 잘 따랐다. 인터넷에서 찾은 자료들을 그대로 복붙 해 스크린에 글씨를 빼곡히 채우고 MS 파워포인트에서 제공하는 기본 템플릿을 사용했으며(지금 생각하니 매우 부끄럽다) 발표날에는 청중에게 등을 보인채 스크린의 글을 읽어 내려갔다. 발표가 망했다는 것을 자각했지만 자료 작성에 들인 시간이 얼마 되지 않았다는 것을 쿨함의 지표로 삼으며 스스로를 위로했는데 보다 못한 교수님이 수업 때 결과물이 좋아도 발표가 엉망이면 좋은 학점을 주지 않겠다고 엄포를 놓았고 성적을 담보로 삼고 나서 발표 능력은 크게 개선됐다.
당시에 난 글이나 말로 상대방에게 내 생각을 전달하는 것은 부차적인 문제로 생각했다. 어차피 개발자들은 코드로 대화하니까 말이나 글로 깔끔하게 설명하지 못해도 코드와 코드에 담긴 주석이 훌륭하면 충분히 커버할 수 있다는 것이 내 지론이었고 여기에 불필요한 문서 작성은 지양하자는 업계의 분위기도 더해져 대학을 떠나기 전까지 글과 말의 중요성을 깨닫지 못했다.
그런데 예상과는 달리 실제 세계에선 의사소통 능력이 매우 중요하다. 학교 다닐 때와는 달리 회사에서 만드는 소프트웨어는 규모가 크기 때문에 혼자서 모든 코드를 이해하는 것은 불가능하다. 자세한 동작 원리를 알 수 없는 소프트웨어에 코드를 추가하기 위해선 먼저 분석해본 동료 개발자의 도움을 받고 만드는 기능이 영향을 줄 수 있는 모듈 개발자와 의견을 교환하는 과정이 필요한데 이때 자신이 분석한 내용을 동료에게 설명하기도 하고 역으로 설명을 받기도 하며 때로는 자신의 주장을 관철하기 위해 설득하기도 해야 한다. 코드를 짜기 전에 먼저 말부터 꺼내고 봐야 하는 것이다. 그런데 이 과정이 길어지면 코드 작성은 뒷전으로 밀려나고 하루 종일 코드 한 줄 못 짜고 말하고 듣기만 하다가 퇴근하는 일이 벌어지기도 한다. 부차적인 일로 생각했던 일이 어느새 주된 일이 된다. 그것도 코드 작성보다 우선적인 일로.
동료와 회의하다 보면 말로는 도저히 설명할 수가 없어 그림을 그리게 되는데 시간이 지나면 어느새 칠판은 수학 도형문제 해설지처럼 변한다. 그런데 한 폭의 그림을 그리고 목을 쉬면서 얘기해도 단번에 동료들을 이해시키는 것은 어렵다. 그래서 개발자들도 회의 전에 잘 정리된 프레젠테이션 자료를 준비하기도 하고 회의에 앞서 중요히 설명해야 할 부분들의 멘트를 정리하기도 한다. 역으로 듣는 일도 마찬가지다. 모든 일들이 비슷하겠지만 소프트웨어는 눈에 보이지 않는 추상적인 개념에 대해서 논하기 때문에 아무리 설명을 들어도 머릿속에 직관적으로 와 닿지 않는다. 그렇기 때문에 집중해서 '잘' 들어야 한다. 회의 시작 전에 대강 어떤 것을 설명할 것인지 예상하고 회의 중에도 중요한 포인트들은 수첩에 써둘 필요가 있다.
너무 일찍 말하기 듣기 쓰기의 중요성을 배웠다. 좀더 늦게 배웠어야 했는데