jen3***
2024-09-28

코드만으로는 부족하다. 함께 일하고 싶은 개발자가 되기 위한 ‘코드 밖’ 커뮤니케이션 스킬 완벽 가이드

어떤 분야든 비슷할 것 같은데, 내가 하는 일만 잘 한다고 하여서 끝은 아니다. 같이 일하던 동료도 나에게 그런 말을 한 적이 있다. 개발만 하면 될 줄 알았더니 같이 프로젝트를 하는 사람이랑 소통을 하는 것도 쉽지 않고, 문서 작업은 더더욱 쉽지 않다고 말이다. 물론 나 또한 쉽지 않다고 생각하기 때문에, 나와 같은 사람이라면 읽어 보면 좋을 책이다. <코드 밖 커뮤니케이션>은 제목에서도 볼 수 있듯이, 코드가 아닌 코드 밖의 커뮤니케이션에 관한 팁을 알려준다. 그러니 IT 프로젝트를 참여하는 팀원들이라면 읽어보면 좋을 것 같다.
파트는 각각 [시각적 커뮤니케이션, 멀티모달 커뮤니케이션, 지식 전달하기, 원격으로 소통하기] 로 총 4개로 분류되어 있다. 그리고 파트 안에는 여러 챕터들이 존재한다. 앞 챕터를 읽어야, 뒤의 챕터가 조금 더 이해가 잘 되는 경우도 있지만! 꼭 읽지 않고 읽고 싶은 챕터부터 읽어도 큰 상관은 없어 보였다.

아 그리고 참고할 것은 이 책 전반에서 필자가 [폴리글롯 미디어]라는 예시를 사용했다. 폴리글롯 미디어 시스템에 기반한 다이어그램이나 이 상자 스타일 형식으로 예시들을 보여준다. 모든 예시들은 가상이지만 전부 필자의 경험과 학습에 기반한 것이라고 하니, 읽기 전에 참고하면 좋을 것 같다.

읽다가 기억해 두면 좋을 것 같거나, 나중에 참고할 문장에 대해서는 하이라이트를 했다. 자주 인용되는 브라이언 푸트와 조셉 요더의 훌륭한 명언이 있다고 한다. '좋은 아키텍처가 비싸다고 생각한다면, 나쁜 아키텍처를 시도해 보라.' 위 인용문을 바탕으로 아래에는 커뮤니케이션에 대해 적은 글도 있다. '좋은 커뮤니케이션이 비용이 많이 든다고 생각한다면 나쁜 커뮤니케이션을 시도해 보라.' 어쩌면 대부분의 상황이 비슷하지 않을까? 하는 생각을 했다. 처음에는 좋아 보이는 나쁜 것들이 반복되면, 결국에는 나쁜 것(또는 상황)이 고착되어 버린다. 그렇게 시간이 흐른 후에는 당연히 좋은 것(또는 상황)으로 돌리려고 노력을 해도, 비용이 커질 수밖에 없다. 가장 쉬운 예로는 바로 '코드'가 그럴 수 있겠다. 어쨌든 돌아가게만 하면 끝이라고 생각한다면, 추후에 유지 보수할 때는 톡톡히 그 대가를 치르게 될 것이니 말이다. 그러니 시작이 참 중요한 것 같다는 생각을 했다. 커뮤니케이션을 쉽게 할 수 있는 방법을 찾는 게 쉽지는 않겠지만, 그럼에도 어쨌든 시작을 잘 하는 것이 중요하지 않을까.

이 책의 앞부분에는 UML에 관련된 게 많이 나온다. 이 책의 제목의 단어 중 하나인 '커뮤니케이션'을 위해서는 다이어그램도 얼마나 중요한지를 알 수 있다. 개발자나 기획자, 마케터 등등 관련 프로젝트 담당자들이랑 소통을 할 때는 상대방이 이해하기 쉽도록 설명해 주는 것이 중요하다. 그렇기 때문에 다이어그램을 만들 때도 이를 고려하여 가독성 있으면서도, 시각적으로도 보기 좋게 만들어야 한다는 것이다. 근래에 UML은 아니고, 플로우차트를 그려서 사수분께 보여드린 적이 있었다. 그때 당시에 각 도형의 위치나 색깔 같은 걸 맞추었었다. 하지만 이 책을 읽다 보니, 다이어그램이나 플로우차트 같은 것을 보여줄 때, 모두 컬러로 보여줄 수 없는 상황도 있을 수 있다는 것이었다. 예를 들어 프린트를 한다고 치자. 근데 그 프린트물이 흑백으로만 출력이 된다면, 컬러의 구분은 의미가 없어진다. 그러니 그런 상황까지 고려할 수 있다면, 컬러 대신 빗금이나 도트 모양 같은 것으로 구분하는 것. 물론 변수는 많을 테니, 그 모든 상황을 다 고려할 수는 없을 테다. 그럼에도 항상 최선이 무엇인지 스스로 생각을 해보는 건 꽤나 중요한 것 같다고 느꼈다.
또 관심 있게 읽었던 부분은 기술 문서 작성과 관련된 부분이다. 일상적으로 적는 글과 기술 문서를 작성하는 것은 읽는 대상이 다르다. 그렇기 때문에 기술 문서 작성을 일상적으로 적는 글처럼 적는 것은 안 된다는 것이다. 읽는 대상을 고려하여, 구조화하고 가독성 있게 쓰는 것이 중요하다는 것. 또 와닿았던 부분은 프로젝트 마인드가 아니라 프로덕트 마인드를 가지고 일을 해야 한다는 것이다. 보통의 프로젝트는 기한이 있기 때문에, 그 프로젝트가 끝난 이후에는 다시 살펴보는 게 쉽지 않다. 하지만 프로덕트 중심으로 사고방식을 전환하고, 프로덕트별로 지식을 정리하면 문서의 검색 가능성도 향상된다고 한다. 프로덕트 중심으로 정리가 되어 있다면, 추후에 이 프로덕트와 관련된 프로젝트를 하는 사람들에게도 쉽게 공유가 될 수 있다는 것이다. 당장 눈앞에 닥친 상황만 보이기 마련인데, 조금 더 포괄적으로 바라봐야겠다는 생각을 했다. 그 외에도 소프트 스킬과 관련된 다양한 정보를 얻을 수 있으니, 코드 외의 커뮤니케이션에 어려움을 겪는 이라면, 읽어보면 도움이 될 것 같다.
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 제공 받아 작성된 서평입니다.