이 아티클은 <이 시대의 개발자로 일하기> 시리즈의 2화입니다.

재능은 ‘Game’ 을 이기게 한다.
그러나, 팀워크와 이해력은  ‘Champion’ 을 만든다
<마이클 조던>

Intro

개발자 역시 다른 직군과 다르지 않습니다. 다양한 프로젝트에서 협업은 선택이 아닌 필수입니다. 사이드 프로젝트를 준비하거나 진행하는 경우에도 카페나 SNS 등의 커뮤니티 활동을 통해 협력자를 만나거나 구하곤 합니다. 이렇게 여러 사람이 모여 일을 하는 데에는 이유가 있습니다. 사람은 누구나 잘하는 분야가 서로 다르고, 각자 잘 못하는 부분을 보충하기 위해서라도 협업은 필요합니다. 설사 모든 것을 혼자서 진행할 수 있는 사람이라도 혼자서 모든 일을 하기에는 일이 너무 많습니다. 결국 힘든 업무에 스트레스를 받거나 지쳐 결과물의 품질을 타협하거나 아쉽게 중도 포기하게 됩니다.

ⓒ 네이버 영화

“너, 나 감당할 수 있겄냐?...”

영화 <신세계>의 정청(황정민 배우)이 이자성(이정재 배우)에게 한 명대사에 이런 말이 있죠. ‘너 나 감당할 수 있겄냐?’ 감당할 준비가 되어 있는 분들만이 1인 프로젝트를 진행하고 결과물을 얻을 수 있으리라 생각합니다. 그런데, 협업을 하면 이 모든 어려움이 해결되는 걸까요?

물론 협업을 한다고 해서 모든 어려움이 사라지진 않습니다. 과도한 업무에 대한 스트레스 대신 협업과 소통에 어려움을 느끼고 스트레스를 받는 경우도 존재합니다. 특히 같은 직군에 있는 사람과의 협업보다 서로 다른 직무의 사람들이 협업하는 경우 어려움을 느끼는 경우가 많습니다. 서로 직무를 이해하지 못한 상황에서 별다른 소통 없이 기능이나 일정을 결정하거나 조율하는 경우에 협업자에 대한 불만이나 협업 자체에 스트레스를 많이 경험합니다.

경험이나 배움을 위해 진행하는 프로젝트에서는 이러한 어려움과 스트레스를 저울질해 본인에게 더 나은 방법을 선택할 수 있을지도 모릅니다. 하지만 결과를 도출해야 하는 회사에서는 특정한 방법을 선택하기 어렵거나 선택할 수 있는 권리 자체가 없을 수도 있습니다.

그렇다면 개발자는 어떤 방법을 통해 원활히 협업하고 소통할 수 있을까요?

양 한 마리만 그려줘

원활한 협업을 위한 첫 번째 과제는 원활한 소통이라고 생각합니다. 원활한 소통을 하기 위해 중요한 것은 잘 말하고, 잘 듣는 것이죠.

우리는 종종 각자의 언어로 자신의 생각만을 말하는 경우가 있습니다. 대화 상대를 배려하지 않거나 상대가 나의 생각을 모두 이해하고 있다고 믿으면서 말이죠. 반대로 상대의 이야기를 듣고 자신이 이해하는 상상 속의 상대를 그려내어 의도를 곡해하거나 말하는 바를 모두 이해했다고 생각하는 경우도 많습니다. 이러한 상황은 서로에게 악의는 전혀 존재하지 않고 호의만 품은 경우에도 발생합니다. 생각한 바를 그대로 전달하는 게 아니라, 수단으로 언어를 선택했기 때문에 발생할 수밖에 없는 한계입니다.

생텍쥐페리의 <어린 왕자>에서 '나'는 '어린 왕자'의 요구를 받아 그림을 그립니다. 처음 그린 양은 병들었고, 다음 그린 양은 심지어 양이 아닌 염소였으며, 그다음 양은 늙었습니다. 엔진을 고치기에 급급했던 '나'는 상자 하나를 그려주고 ‘어린 왕자'는 그 그림에 만족합니다. 작품 속의 ‘나'와 ‘어린 왕자'는 서로에게 악의도 없었고, 심지어 ‘나'는 '그림 1호(코끼리를 삼킨 보아뱀)'를 알아봐 준 '어린 왕자'에게 호의를 품고 있습니다. 이들은 잘 말하고, 잘 들은 걸까요?

ⓒ 셔터스톡


서비스에 기능을 추가하는 경우에 빗대어 보겠습니다. '개발자'는 '기획자'의 요청을 받아 기능을 구현합니다. 처음 기능 구현은 '기획자'의 의도대로 동작하지 않았고, 다음 기능 구현은 완전히 다른 기능이었으며, 그다음 구현은 성능(품질)이 안 좋아 서비스에 사용할 수 없었습니다. 작품 속의 '나'와는 달리 '개발자'는 여기서 멈출 수 없습니다. 버튼 하나를 만들고 '네가 생각한 기능은 이 버튼을 누르면 내부적으로 작동할 거야'라고 말할 수는 없으니까요. '개발자'는 예외 처리가 덕지덕지 붙은 결과물을 보며 ‘처음부터 잘 말했으면 좋지 않았을까?...’ ‘기획자’가 무엇을 원하는 건지 모르겠다!’고 생각 합니다. '기획자'는 ‘기능 하나 구현하는데 불가능한 것이 왜 이리 많지?..’  또는 심지어 ‘개발자'가 무능하거나 일을 하기 싫은 게 아닌가?’라는 생각까지 합니다. 최종적으로 기능은 구현되었지만 실제로 사용하지 않는 경우도 종종 있습니다.

사용하는 용어의 용례가 달라 소통에 실패하는 때도 있습니다. 극단적인 예로 '이벤트(event)'라는 용어를 사용하는 경우가 있을 수 있겠네요. 개발팀에서 다른 직무의 팀에 '이벤트 리스트'를 요청합니다. 한국에서 이벤트의 일반적인 용례는 '행사'를 의미합니다. 사업이나 마케팅, 운영 직무에 있는 분들에게 이벤트는 일반적인 용례에 따라 '행사'를 의미하는 경우가 많습니다. 특정한 목적을 위해 '기획' 해야 할 대상인 거죠.

컴퓨터 과학에서 이벤트는 다른 용법으로 사용됩니다. 무엇인가가 일어났음을 의미하는 소프트웨어적인 메시지를 뜻합니다. 사용자의 행위나 애플리케이션의 동작 등에 이벤트가 발생합니다. 이러한 용례에서 이벤트는 속성의 변화를 확인하기 위해 '감시 또는 발생' 시켜야 할 대상입니다. 개발팀에서는 '사업이나 운영에서 사용할 데이터들을 집계하기 위해 감시하거나 추적해야 할 시점 목록'을 요청한 거라고 볼 수 있겠네요. 하지만 요청을 받는 곳에서는 '진행해야 할 행사의 목록'이라 생각할 수도 있습니다. 물론 이러한 오해는 일반적으로 발생하지 않습니다. 일반적인 상황에서는 맥락을 통해 용례를 파악할 수 있기 때문입니다.

인식과 개념의 동기화

최우선의 목표는 프로젝트 참여 인원 모두가 같은 구상을 할 수 있는 개념과 의식의 공유입니다. 서로의 의도를 파악하고 같은 결과를 생각할 수 있도록 개념을 확인합니다. 조금 더 구체적으로는 모두와 내가 이해하는 것이 맞는지 확인하는 과정이라고 할 수 있습니다.

다른 사람과 영화나 소설, 게임이나 만화 이야기를 하며 즐거웠던 경험이 한 번쯤 있을 겁니다. 같은 작품 이야기를 하더라도, 대화하는 상대에 따라 얻는 즐거움은 달랐을 거라 생각합니다. 해당 작품을 보지 않은 사람과 이야기할 때 세계에 대한 설명을 생략하면 이해하기 어려운 경우도 있습니다. 인식과 개념이 다르기 때문입니다. 하지만 처음부터 같은 작품을 즐겼던 상대와는 사전에 공유된 인식과 개념이 있기에 다른 상상을 하더라도 공감할 수 있는 부분이 있겠지요.

공통의 관심사를 가진 사람과 대화가 잘 통하듯, 상대의 말뜻을 정확히 이해하기 위해서는 서로의 생각을 동기화하는 과정이 필요합니다. 용어와 의미의 개념을 재확인하며, 정확한 의도 전달을 위해 노력합니다. 다소 용법과 다르다 해도, 프로젝트 내의 합의와 약속을 통해 재정의하여 사용하는 때도 있습니다.

ⓒ 셔터스톡


물론 이러한 과정은 생각한 것보다 더 많은 에너지를 소모합니다. 인식과 개념을 공유하는 과정을 거치는 것보다, '언제' '무엇이' '어떻게' 변화하는지 혹은 '언제' '무엇을' '어떻게' 보여주는지만 서로 전달하고 진행하는 편이 빠를 수도 있습니다. 하지만 그런 경우에도 결과물에는 피드백이 필요합니다. 여유가 생겼을 때 어떤 결과물이 나왔고, 어떤 개선점이 필요한지, 의도에 맞는지 공유해야 합니다.

협업하는 상대와 사전에 같은 인식과 개념을 공유한다면, 결과적으로 의사 전달에 필요한 시간과 에너지를 절약하게 될 것입니다.

내 머리 속의 지우개

바쁜 일정을 소화하다 보면 어제 작성한 코드 조각이 새롭게 느껴집니다. 왜 이렇게 했을까 고민하게 되거나, 과거의 자신을 원망하기도 합니다. 업무에서뿐만 아니라 다른 일에서도 마찬가지입니다. 장을 보다 깜빡 잊고 사오지 않는 일도 종종 있지요. 사람은 기계가 아니기 때문에, 상황과 조건이 같아도 항상 같은 결과가 나오지 않습니다. 물론 현실의 상황과 조건을 통제하는 것도 어렵구요. 마찬가지로 사람의 기억은 어딘가의 데이터베이스처럼 조건을 걸어 질의(query)할 수도 없지요. 사전에 인식과 개념을 공유하고 바람직한 소통을 통해 모두가 만족하는 결론을 내린다고 하더라도 잊는다면 무의미한 일이 됩니다.

자기계발서처럼 메모하는 습관의 중요성이나 장점에 관해 설명하진 않겠습니다. 메모하는 습관은 도움이 될 수 있지만, 메모 행위만으로는 협업이나 소통에 도움이 안 되기 때문입니다. 중요한 것은 미래의 자신이 과거의 논의와 결정을 필요한 순간에 다시 확인하는 것입니다.

가장 간단하게 도구를 이용하는 방법이 있습니다. 커뮤니케이션을 위한 도구는 많습니다. 특히 이메일과 메신저는 대부분이 사용합니다. 그래서 이메일과 메신저 서비스에는 검색 기능이 있고, '협업을 위한' 수식어가 붙는 도구들은 강력한 기능을 가지고 있습니다. 한 번의 버튼으로 모든 팀원에게 내용을 공유할 수 있는 기능도 존재합니다. 따라서 이런 도구를 이용한 소통은 나중에 다시 찾아보기 쉽습니다. 찾기 쉬움과 어려움의 문제는 별개로, 도구를 사용한 소통은 망각의 문제를 다소 해결해 줍니다.

그런데 기록과 검색을 할 수 있는 커뮤니케이션 도구를 사용해도 소통의 통로(도구)의 수가 늘어나면 검색이 어려워집니다. 어떤 내용의 대화를 했다는 것만 기억하고, 상세한 내용이나 날짜, 사용한 도구를 기억하기는 쉽지 않습니다. 심지어는 누구와 대화했는지조차 기억하지 못하는 경우도 있습니다. 소통의 통로가 다양할 경우, 상세한 내용을 기억하기 위해 모든 도구를 찾아보는 사태가 생깁니다. 커뮤니케이션 도구를 기록용으로 사용하는 의미가 퇴색하는 것이죠. 따라서 협업에서는 사용하는 도구를 제한하고, 업무에 대한 화제는 사적 통로(전화, 카카오톡 등)를 이용한 소통을 지양하는 편이 좋습니다. 부득이하게 사적 통로를 이용한 경우에도 공식적으로 사용하는 사내 메신저나 메일 등을 이용해 다시 한번 정리하는 것이 좋습니다.

메신저는 목적상 빠른 대화를 위한 도구입니다. 대화의 흐름이나 과정에 따라 필요한 정보를 찾기 힘들어지는 경우도 있습니다. 따라서 협업을 위한 커뮤니케이션 도구를 사용할 때는 키워드가 될만한 단어를 포함하는 것이 좋습니다. 더 나아가서는 대화가 어느 정도 마무리된 후, 정리하여 '협의가 이루어진 커뮤니케이션 도구'를 통해 공유하는 방법도 있습니다. 또한 도구를 통하지 않은 소통(대면 미팅 등) 역시 기록되지 않기 때문에, 따로 담당자를 정하여 정리하고 검토하여 공유하는 편이 좋습니다.

이런 방법들은 협업하는 사람들이 모두 같은 방법을 사용하여 기록하고 공유할 때 더 높은 효과를 발휘합니다. 나 혼자만의 기록이 아니라, 함께 한 모두의 기록이 유용하고 많은 정보를 가지고 있기 때문입니다. 하지만 자신에게 유용하다 해서 상대 혹은 팀원 모두에게 특정 도구를 강요해서는 안 됩니다. 가장 중요한 것은 합의와 약속이니까요.

Outro

개발자 모두 소통의 실패를 줄이기 위해 여러 가지 노력을 합니다. 각자 나름의 방법도 가지고 있을 것입니다. 상대에 따라 여러 방법을 전략적으로 사용하시는 개발자도 있을 것이고, 본인에게 맞는 방법을 찾지 못해 이런저런 시도를 하며 고민하는 개발자도 있겠지요. ‘이렇게 하면 문제 없이 소통할 수 있어요!’라고 호언장담하지는 않겠습니다. 각자 개인의 상황이란 것이 다르고, 우선순위와 성향도 다르기 때문입니다. 다만, 지금까지 정리 드린 팁들을 적절히 활용하여 내게 맞는 정답을 찾아보시길 바라겠습니다.



▶ <이 시대의 개발자로 일하기> 시리즈 보러 가기 



글ㅣ맹창훈
외교관을 꿈꾸다 개발자로 전향한 문과 개발자로서, 컴투스, 스노우파이프 등에서 여러 게임 프로젝트를 경험한 후 호두랩스 Gamification lab 서버 팀에서 교육 격차를 해소 하는 공동 목표를 함께 실현하고 있는 프로그래머입니다.