의사소통의 중요성 1

소프트웨어 개발에서 의사소통은 매우 중요합니다. 아래 그림은 개발자라면 한 번쯤은 보았을 것입니다. 개발에 참여하는 여러 이해관계자들이 어떤 의사소통을 하고 있는지를 재미있게 표현합니다. 고객의 요구(requirement)가 어쩌면 이렇게도 다르게 해석될까라고 의아해 할 수도 있습니다. 안타깝게도 소프트웨어 개발 현장에서 이것은 부인할 수 없는 현실입니다.

의사소통의중요성 2

2010년에 회사 창립 10주년을 기념하여 워크샵을 갔습니다. 그곳에서 우리는 낱말 전달하기 게임을 했습니다. 어릴 적 많이 하던 귓속말 전달하기 게임과 비슷합니다. 대신 낱말을 몸동작으로 전달합니다. 당연히 게임이 진행되는 동안에는어떤 말도 할 수 없습니다.

첫번째 사람은 아주 쉬운 단어라고 생각하고는 다음 사람에게 여유있게 바이올린 연주하는 모습을 보여줍니다. 두번째 사람 너무 쉽다는 듯이 자신만만한 웃음을 지으면, 세번째사람에게 바이올린 연주하는 모습을 보여줍니다. 하지만, 자신감에 넘쳐서였을까요? 바네사 메이를 능가하는 격정적인 바이올린 연주 모습을 보여줍니다. 활을 잡은 오른손이 허리춤까지 오르락 내리락합니다. 세 번째 사람이 알겠다는 듯이 고개를 끄덕입니다. 그리고는 네번째 사람에게 비슷한 동작을 보여 줍니다. 아니 그런데 이건 엉뚱하게도 탁구를 치는 모습입니다. 포핸드 스트로크에 이어서 앞 사람에게서 보지 못한 백핸드까지 구사합니다. 두 번째 사람보다 훨씬 더 열정적입니다. 여기저기 웃음이 터져 나왔습니다. 이 친구 신이 나서 더 열심히 탁구치는 시늉을 합니다.

“바이올린”이라는 낱말이 “탁구”라는 낱말로 변환되는 순간입니다.

하지만 의사소통의 중요성을 강조하는 경우, 회의와 문서에 많은 시간을 들입니다.모두가 완전하게 이해하고 합의에 이를 때까지 회의를 합니다. 문서는 누구나 이해하기 쉽고 자세하게 작성합니다. 당연히 많은 시간이 필요합니다. 프로젝트규모가 클수록 이해관계자는 많아지고, 이해관계자가 많으면 많을수록 의사소통에 필요한 시간은 지수적으로 늘어납니다. 어떤 프로젝트에서 2주간 작업한 문서 때문에 아홉차례나 검토회의를 한 적이 있습니다. 그 검토는 여러 사람들이 이해하고 동의할 때까지 계속되었는데, 그 한 달 내내 나는 회의일정 조정, 검토 준비, 결과 정리 외에는 아무 것도 할 수 없었습니다. 의사소통을 효율적으로하는 가장 효율적인 방벙는 의사소통 당사자를 줄여 의사소통 경로를 짧게 하는 것입니다.

개발 프로젝트에서 의사소통 문제

소프트웨어개발은 폭포(waterfall)모델을 바탕으로 합니다. 물론 현재는 반복(iteration) 기반의 개발이지만, 반복 역시 하나의 작은 폭포(waterfall)입니다. 한 건의 프로그램이 만들어 지는 일련의 과정을 여러 단계로 나누어서 진행합니다. 각 단계에는 역할 담당자가 있고, 역할수행은 산출물로 결정합니다. 소스코드가 나오기 위해서 그에 해당하는 각 단계별 산출물이 있어야 합니다. 시간의 흐름에 따라 주도하는 역할이 변경됩니다.

업무분석가는고객과의 의사소통을 통해서 기능 요구를 정리합니다. 시스템 분석가는 업무분석가로부터 업무내용을 듣고는 기능요구 명세서를 받습니다. 시스템분석가는 이 정보를 바탕으로 분석모델링을 한 다음 그 결과를 시스템 설계자에게 넘깁니다. 시스템 설계자는 그 정보를 바탕으로 설계모델링을 한 다음 프로그래머에게 전달합니다. 프로그래머는 설계모델을 보고 코딩을 합니다. 철저하게 기능 중심으로 자신의 역할을 수행합니다.

이것은 우리가 워크샵에서 했던 낱말 전달하기 게임과 흡사합니다. 다섯 가지 역할 담당자가 요구(requirement) 전달하기 게임을 하고있습니다. 고객의 요구가 프로그래머에게까지 정확히 전달될 확률은 낮아보입니다. 물론 가운데 코딩에 필요한 정보로 각색하는 과정이 있습니다. 역할 참여는 시간흐름 순입니다. 동시에 작업을 해야 한다면 서로 다른 역할에 대한 설득력이 있지만, 서로 다른 시점에 참여하므로 반드시 서로 다른 사람이 해야 할 이유가 없습니다. 경험이 어느 정도되는 프로그래머가 분석을 하고 설계를 하면 어떨까요? 그러면 의사소통 경로가 획기적으로 짧아지지 않을까요?

위와 같은 방식의 작업을 고집하는 사람들이 간과하는 것이 있습니다. 바로 각 활동별 정보량입니다. 분석보다는 코딩이 훨씬 더 많은 정보를 요구합니다. 그래서 분석가는상대적으로 넓은 영역을 가질 수 있고 프로그래머는 좁은 작업영역을 가집니다. 요구되는 정보량이 많다는 의미는 각 단계를 넘어갈 때마다 필요한 정보가 늘어간다는 뜻입니다. 동시에 각 단계별로 궁금해하는 것이 서로 다르다는 뜻이기도 합니다. 그럼 단계를 넘어가면서 필요한 추가 정보를 누구에게서 받아 올 것인가? 설계는 분석보다 더 많은 정보를 필요로 합니다. 분석 산출물에는 없지만 설계단계에 필요한 정보를 어디서 구할 것인가? 결국은 고객에게 얻어오는 수 밖에 없습니다. 따라서 어떤 역할 담당자든 고객과의 의사소통이 반드시 필요합니다. 이런작업 방식에서 역할 담당자는 항상 이전 역할 담당자와 고객, 그리고 다음 역할 담당자 세 역할과의 의사소통이필요합니다. 때로는 그 이전 역할 담당자와의 의사소통도 필요합니다.

해결방안: Cross-functional Developer

심심치않게 볼 수 있는 최악의 시나리오는 프로그래머가 고객과 설계자뿐만 아니라, 업무를 정의한 업무분석가나시스템의 기능요건을 정의하고 개념 모델링을 한 분석가와 이야기를 해야 하는 경우입니다. 이 경우에 프로젝트 팀이 지불하는 의사소통 비용은 너무 커서 프로젝트를 위태롭게 합니다. 프로그래머 입장에서는 코드 작성보다는 소통에 많은시간을 쏟아야 합니다.

의사소통이중요하다고 강조하는 것은 좋습니다. 그러나 쉽게 카오스 상황으로 진입하는 개발 프로젝트에서 의사소통 자체보다 그 효율성이 더 중요합니다. 효율을 높이는 방법은 뜻밖에 아주 간단합니다. 의사소통 경로를 줄이는 것입니다. Cross-functional Developer가 정답을 제시합니다. 분석, 설계, 코딩 활동은순차적으로 이루어 집니다. 설계자가 누구입니까? 노련한 개발자아닌가요? 시스템 분석가가 누구입니까? 역시 충분한 개발자 경험을 가진 엔지니어입니다. 따라서 경험이 충분한 개발자가 분석, 설계, 코딩 전 라인에서 활동하는 것입니다. 이런 방식의 인력 운영은 의사소통경로를 단축시켜줍니다. 더욱 중요한 것은 작업결과를 전달하는 과정에서 발생하는 정보유실이나 착오, 오해와 같은 문제를 없앨 수 있다는 사실입니다

물론 모든개발자가 Cross-functional Developer일 수는 없습니다.프로젝트 수행 모델에 따라서 인력 운용방식을 달라져야 합니다. 예를 들면, 폭포(Waterfall) 모델에서는 Cross-functional Developer가 개발의 흐름을 주도하고 설계나 구현 단계에 필요할 경우 해당인력을 추가하는 방식이 될 것입니다.

반복 수행모델을 바탕으로 하는 애자일 프로세스는 개발자는 Cross-functional Developer를 의미합니다. 그런 분석, 설계가 어렵고 프로그래밍만 할 줄 아는 개발자는 짝(pair) 프로그래밍과 같은 작업을 통해서 빠른 시일 내에 Cross-functional Developer가 될 수 있도록 노력해야 합니다. 디자인이나 데이터 설계와 같은 전문화된 역량을 제외하고 하나의 기능에 대해서 분석, 설계, 코딩에 이르는 영역을 담당할 수 있도록 노력해야 하며, 팀의 선임 개발자는 그것이 가능하도록 지속적인 지원을 아끼지 말아야 합니다.

요약

목표시스템을 주어진 예산과 기간 안에 구축하기 위해서는 원할한 의사소통이 꼭 필요합니다. 이때, 역할 담당자가 많으면 많을수록 의사소통 경로가 길어져서 소통이 어려워집니다. 따라서 전통적인 폭포 모델에서의 역할과 협업 방식을 벗어나 의사소통 경로를 좁힐 수 있는 방안을 생각해 봐야 합니다. 프로젝트의 각 단계를 아우를 수 있는 Cross-functional Developer가 아주 훌륭한 해결책입니다.

tistory에 올려두었던 글을 이곳으로 옮겨왔습니다.

2014.2.5 송태국(tsong@nextree.co.kr)