기획자와 개발자 간의 커뮤니케이션에 대한 37,856 번째 글

그렇다, 아마 그럴 거다. 기획자/디자이너/개발자간의 커뮤니케이션에 대해서는 정말 쓰여진 글이 많을 거라서, 거기에 하나를 더 보태는 것은 크게 의미가 없을 거다. 게다가 이 문제에 대한 내 관점은 기획자 쪽으로 치우칠 수밖에 없다. 개발자로써의 삶을 살아본 적이 없기 때문이다. 아마 개발도 해 보시고 기획도 해 보시는 분들이 더 나은 관점을 제시할 수 있으리라 본다.그럼에도불구하고 그냥 단순히, 개발자들과의 협업을 위해서 기획자가 어떻게 더 노력할 수 있는지에 대한 생각을 위주로, 내 나름의 깜냥을 적어 보기로 한다.

문제가 발생하는 경우는 이런 경우가 많다고 본다. 예를 들어 가계부 프로그램을 만들어 본다고 하자. 사실 우리나라의 경우 비즈니스 기획을 하는 사람이 서비스 기획까지 이어서 하는 경우도 많기 때문에, 기획자의 80%의 관심은 세상을 바꾸고 돈을 많이 벌 수 있는 프로그램이 가계부 프로그램일지 아닐지를 검증하는데에 가 있을 것이다. 즉 좀더 비즈니스/마케팅적인 데에 관심이 갈 수밖에 없다는 것이다. 그도 그럴것이, 비즈니스적으로 성공 가능성이 없는 서비스라면 애시당초 기를 써서 만들 필요도 없는 것 아닌가.

그러다 보니 정작 가계부 프로그램 자체에 대한 기획은 “상위기획 워드문서” + “파워포인트로 만든 스토리보드” 정도가 될 가능성이 있다. 기획자의 머릿속에는 좀더 많은 것들이 있을지언정, 이를 다양한 유저 케이스별로 검토하고 제 3자가 이를 알 수 있도록 문서화하는 작업이 없으면 “상위기획 워드문서”+”파워포인트로 만든 스토리보드” 만 가지고는 아무리 기획자적 소양을 가진 개발자라도 실제로 개발을 시작할 수는 없다.

예를 들어 실제로 가계부 프로그램을 만들려면 이러한 다양한 것들이 정해져야 한다. 그리고 이러한 것들은 “상위기획 워드문서”+”파워포인트로 만든 스토리보드” 정도의 문서에는 아마도 나와 있지 않을 것이다.

– 이 가계부를 누가 쓰는 것인가? 남편과 아내만 쓰나, 아니면 회원 가입을 받아서 철수엄마랑 똘이아빠도 쓰게 할 것인가?
– 남편과 아내는 각각 동일한 사용 권한을 가지는가, 아니면 그렇지 않은가? 아내가 쓴 컨텐츠에 대해서 남편은 고치거나 삭제할 수 있는가? 반대의 경우는?
– 가계부의 항목난에는 현재 있는 항목들 외에 향후 어떤 항목들이 추가될 수 있는가? 예를 들어, 지금은 신용카드로 지불한 내용과 현금으로 지불한 내용을 따로 구분해서 계산하지 않지만, 향후 그럴 니즈가 발생할 가능성이 50% 이상 되는가? 그처럼 향후에 발생할 가능성이 50% 이상 되어서, 마치 도로를 미리 깔듯 인프라를 설계할 때 미리 고려되어야 할 것은 또 뭐가 있는가?
– 가계부의 금액난은 원화만 입력받을 것인가, 외화도 수용할 것인가?
– 가계부의 월별 사용내역 보기는, 매달 1일부터 말일까지를 보여주는 것인가 아니면 검색일 기준으로 그 앞 한 달치를 보여주는 것인가? 매월 사용내역을 다 archive로 기록할 것인가, 아니면 최근 몇달치만 갖고있을 것인가?

이러한 질문을 찾자면 한 20개는 더 찾을 수 있을 것이다. 하물며 지극히 간단한 가계부 프로그램도 이러할진대, 복잡한 웹 서비스는 얼마나 고려 요소가 많겠나.

이러한 다양한 유저 행동에 따라서 예측 가능한 결과치들과 이에 수반되는 데이터 입출력 시나리오가 촘촘히 결정이 되어야 비로소 개발에 들어갈 수 있다. 그렇지 않고 겉에 보이는 모습만을 규정하면 이를 만들어 낼 수가 없는 것이다. 이를 위해서는 2명 이상의 기획자들이 롤 플레잉을 계속 하면서 다양한 유저 행동을 시뮬레이션 하고, 정책이 부딪힐 때는 서로 싸워 나가면서 합의점을 찾는 게 필요하다. 제대로 된 용어인지 콩글리시인지는 모르겠지만 대략 “아이디어 바운싱” 이라고 해야 할까? (콩글리시 맞는 듯하다 ㅠ)

기획자는 물이 안 나올때까지 우물을 파는 사람처럼, 하나라도 디자이너와 개발자에게 더 정의해 주고 모호성을 줄여줄 수 있는게 없는지 계속 찾아보고 고민해 봐야 한다. 그리고 이러한 고민의 근저에는 동료 의식이 있어야 한다. 자신의 기획안을 들고 실제로 밤을 새고 땀을 흘려가며 속된말로 “노가다”를 뛸 사람들은 바로 다름아닌 당신의 동료들인 것이다. 이걸 늘 기억하면, 대강대강 기획할 수가 없는 것이다.

그리고, 분명한 방점을 찍어주어야 한다. 100개의 기능이 있다면, 개발자는 100개의 기능을 다 공들여서 개발해야 한다. 왜냐하면 중요하지 않은 기능이더라도 적어도 버그는 나면 안되니까. 따라서 사실 100개의 기능이 아닌, 중요하고 핵심적인 20개의 기능을 주는 게 더 낫다. 그러나 서비스를 하다보면 사실 주변부 기능이 전혀 없을 순 없다. 이럴 경우, 어떤 기능이 핵심인지를 분명하게 명시해 주어야 하고 (이는 비즈니스 목표와 밀접히 연관되어 있을 것이다), 여기에 노력의 초점이 맞추어 지도록 해야 한다.

항상 기억해야 할 점은, 어떤 서비스이든지 간에 가장 핵심이 되고, 80%의 유저가 80%의 경우에 수행하는 행동은, 결국 두세개일 가능성이 크다는 점이다. 당신이 워드를 쓸 때, 위키를 쓸 때, 아이튠스를 쓸 때, 온라인 캘린더 프로그램을 쓸 때, 블로그를 쓸 때… 주로 쓰는 기능은 무엇인가? 아마 몇 가지 기능이 거의 대부분일 것이다. 여기에 핵심을 맞추어야 한다. 이러한 핵심 기능은 강력하고 스케일러블하게 만들고, 나머지 주변부 기능들은 최소화하려는 노력을 해야 한다. 비즈니스적인 관점에서 보았을 때 이러한 핵심적인 기능은 어떤 것인지를 정의해야 한다. 그렇지 않은 기획은 연필로만 그렸지, 컬러를 입히지 않은 그림과 같다. “결국 우리가 하려는 게 뭔가? 어디를 바라보고 나가야 하는가?”에 대해서 강력한 비전 제시가 있어야 한다. 어떤 공간의 청소를 하는데 “여기는 세번 쓸고, 저기는 네번 닦아야 한다”는 자세한 지침도 도움 되지만, 그 이전에 “우리는 여기를 깨끗이 꾸며서, 청소년들을 위한 독서공간으로 만들고자 한다”는 미션을 부여하면 일을 하는 사람들이 거기에 맞추어서 자기들 나름대로의 아이디어도 내면서 한 방향으로 움직일 수 있다. 사람은 누구나 생각하는 동물이므로…

기획자들은 모호하게 아는 상태에서 어설프게 말하지 말자. 사실 기술의 세세한 부분은 몰라도, 해당 기술에 대해서 어느정도의 컨셉을 파악하고 있어야 하는게 기획자의 몫이다. 대기업에 있었을 때, 주로 외주업체 써서 일을 진행하다 보니 서비스 기획자들이 기술의 개념에 대해서 잘 파악하지 못하고 있는 것을 가끔 보았다. 그런데 문제는 그러다보니 R&D 팀과 이야기가 진행될 수가 없다.

예를 들어서 이런 거다. 카메라폰으로 찍은 사진을 웹으로 올리려는 서비스가 있다고 치자. 이러한 모바일 어플리케이션을 구현하기 위해서는 실제로 적지않은 기술적 장벽들이 존재한다. 어플리케이션을 기존 폰 사용자에게 배포하기 위해서는 (해외의 경우) 자바로 구현해야 하는 게 맞는데, 자바의 경우 기존에 J2ME에서 정의한 스펙 그대로 개발할 경우 해당 모바일 어플리케이션이 휴대폰의 멀티미디어 파일 시스템에 액세스할 수 없어서, 위에서 말한 어플리이션을 구현할 수가 없게 된다. 따라서 자바 익스텐션을 폰 개발시 구현시켜 주어야 하고, 이를 위해서 해당 조직과 협의해야 한다. 그러고 나면 다음 문제가 발생하는데 이는 어플리케이션에서 보여줄 썸네일을 만드는 것이다. 이를 폰더러 썸네일 이미지로 만들라고 하면, 폰의 빈약한 CPU와 비디오 메모리가 버벅댈 것이다. 따라서 JPEG 헤더에 들어있는 EXIF 썸네일 이미지를 추출해 오는 편이 더 나은 유저 경험을 제공할 것이다. 물론 이러한 문제를 풀고 나면 다음 문제가 또 나타날 것이다.

이는 그냥 머리속에서 떠오른 예에 불과하지만, 이러한 문제들을 기획자가 면밀하고 정확히 알아야, 일을 하나씩 풀어나가고 뭔가 “매조지”를 지을 수가 있다. 그러나 내가 보았던 대부분의 기획자들은 자바 익스텐션이 뭔지, Exif 섬네일이 뭔지를 모른다. 모르는 것은 전혀 문제가 아니다. 나도 모르고, 실은 그런거 모르는 개발자들도 많으니까. 그러나 찾아보아야 한다. 썬의 J2ME 화이트페이퍼라도, 아니 위키 페이지라도 한번 찾아볼 생각을 하지 않는 것은 좀 문제가 있다는 것이다. JSR-75 라는건 어디서 많이 들어서 아는데, 그 단어를 감싸고 있는 더 큰 맥락은 모르는 분들도 많이 보았다.

물론 세세한 기획적인 요소들은 어느정도 시니어 레벨이 되면 일일이 본인이 기획하지 않아도 될 것이다. 시니어 포지션에서는 어쩌면 “가계부 프로그램이 우리가 만들어야 하는 프로그램이 맞는가?”에 신경이 가 있는게 맞을지도 모른다. 그러나 예를 들어 집을 짓는 것을 생각해 볼 때, 실제로 집을 짓는 과정에 처음부터 참가해서 바닥부터 벽돌을 쌓아본 사람이, 그렇지 않은 사람에 비해서 속칭 “십장”이 되었을 때 집을 더 잘 지을 수 있지 않을까?

++

기획자들에게도 마찬가지로, 개발자들에게도 첫번째로 갖추어야 할 덕목은 동료의식과 협력의식이다. 일이 되게끔 하는게 목적이지, 자신의 인텔리전트를 과시하거나 남의 헛점을 짚어내는 게 목적이 아닌 것이다. 적은 외부에 있는 경쟁자지 내부의 동료가 아니다. 따라서 그렇게 하는 사람들은 조직적인 시각에서 보았을 때는 사실 마이너스 요소일 수 있다. 내가 인터랙션하는 사람이 정확히 어떤 부분에서 나를 만족시켜 주지 못하고 있는지를 효과적으로 짚어주어야만 한다. 어차피 개발자와 기획자, 디자이너는 서로 다른 면들을 볼 수밖에 없기 때문에, 다른 사람이 나와 완벽히 동일한 관점에서 생각하기를 기대한다면 그건 그렇게 생각하는 사람이 잘못된 거다. 따라서 다들 조금씩 희생해야 한다. 과정 가운데에서 서로 맞추어 가는 노력을 모두가 조금씩은 기울여야 한다는 얘기다.

이건 검증된 것도 아니고, 예외의 경우도 존재하겠지만, 내가 경험한 바에 따르면 실패한 서비스의 A급 인재보다 성공한 서비스에 관여한 B급 인재가 더 유리한 위치에 서게 되는 것을 종종 보았다. 우리 사회도 트랙 레코드라는 것이 점점 중요해지는 세상이 된 것같다. 당신이 리니지를 개발한 핵심 인력이라면 평생 밥 먹고 살 걱정을 하겠는가? 그러나 당신은 스스로를 정말 머리좋은 사람이라고 규정짓지만, 그게 하나의 서비스나 제품으로 나타난 결과치가 없을때 스스로를 잡 마켓에서 포지셔닝하는데 크든 적든 애로를 겪을 것이다. 그러므로 기획자와 개발자가 한 프로젝트에서 날카롭게 각 세울 생각을 하는 건 넌센스다. 어떻게 해서든 서로 도와서 다같이 걸작 서비스를 만들어낼 생각을 해야 하는 것이다.

마지막으로 기획자든, 개발자든 커뮤니케이션을 잘 해야 한다. 70~80%의 대부분의 문제는 서로 비슷하거나 같은 생각을 하고 있는데 커뮤니케이션을 잘 하지 못해서 발생하는 것 같다. 참 불행히도, 세상을 움직여 가는 사람들 중에는 말 잘 하고 글 잘 쓰는 사람이 꽤나 많다. 스티브 잡스와 빌 게이츠의 공통점을 따지고 보면 결국 무엇이겠나.. 게다가 여러 사람들이 공동으로 작업하는 프로젝트에서 커뮤니케이션만큼 중요한게 없다.

++

쓰고 보니 마치 우리 회사의 경우에 비추어 글을 쓴게 아니가 하는 오해를 받을 수도 있겠다.그러나 전혀 그렇지 않고, 실은 대기업에서의 경험을 염두에 둔 부분이 많다. (이게 우리 회사 이야기라면 메일로 썼지, 왜 블로그로 쓰겠나.) 물론 우리 회사에서도 개발자와 기획자 간의 트러블이 전혀 없다고 하면 거짓말이겠지만 우리회사만큼 공동의 미션에 강력히 참여하면서 성공적으로 협업해 나가는 회사는 없을 거라고 생각한다. 작은 회사라서 모두가 한 공간에 모여있는 게 큰 도움이 되는 듯하다.

기본적으로, 이 긴 글의 요약은 우리 모두 더 나은 기획자가 되자는 것이다. 그런 의미에서, 작년 겨울껜가 유노님이 CSS와 웹표준에 대해서 공부하는 모습을 너무 멋지게 보았던 기억이 있다.