[1편] 개발자도 춤추게 만드는 커뮤니케이션 기법.

 

기획하시는 분들은 사이트를 보실 때 어떤 것부터 보시나요?  뭐하는 사이트인지, GNB의 구성, 컨텐츠의 흐름, 전체적인 느낌.. 일단 제가 기획자가 아니니까 이 정도까지만.. 들을 본다던지 하시겠죠?  그렇다면, 개발자는 웹사이트를 어떻게 바라보고, 무엇부터 볼까요?  저 같은 경우에는 일단 개발언어를 보고, 뭔가 특이한 스크립트같은 기교들이 눈에 들어오게 되죠. GNB 눌러보며 메뉴이동도 하구요.  그러다 눈에 띄는 내용이 있다면 글도 좀 보고...

간혹 현업에서 보지못한 새롭거나 획기적인 컨텐츠나 구성이 있다면, 개발자분 중에 이상한 드립을 쳐서, 기획자와 개발자 사이에 으르렁거리며 원수같은 분위기를 조성하는 초석이 되기도 하죠.  예컨데... "아니.. 우리회사 기획자는 왜 이런 것도 기획 못하나 몰라?" 같은..?^^;

 

눈에 보이는 것이 전부는 아닌 프로그래밍

 

"김 팀장. 결제창 붙이는거, 그거 개발하는데 뭐가 어려워?"

"그거 뭐 그냥 업체가 제공해주는거 가져다 붙이기만 하면 되는거 아냐? 메뉴얼도 있는데."

 

얼마전 사이트에 처음으로 PG 서비스를 붙이는데, 이런 이야기를 들었는데, 이런 류의 도발성 멘트... 저에겐 싸우자는 소리로 들렸고, 심장이 벌렁거리고 얼굴이 벌개지면서 대뇌의 전두엽이 짜릿하게 자극시키며, 0.1초만에 입에서 튀어나가는 말.. "그럼 니가 직접하시던가요." 어때요?  심히 아름답진 않죠?

 

 

PG서비스를 하는 업체도 여러곳, 그렇다면 매뉴얼도 여러곳입니다.  의사결정에 따라 PG업체를 정하겠지만, 그게 어느 업체가 됐건 아무리 비슷한 서비스라 하더라도, 타업체의 서비스를 사이트에 입히는 일 처럼 골치아프고 신경쓸거 많아야 하는 일은 없습니다.  내가 직접 만든 서비스도 아니고, 다른 회사에서 만든 PG 서비스를 내 사이트에 맞춰 입힌다는 것 자체가 생각처럼 쉽게 가져다 붙인다고 되는 일은 아니기 때문입니다.

 

내 사이트를 이해하면서 동시에 입히고자 하는 PG서비스에 대한 이해를 해야하구요, 서비스 매뉴얼도 파악해야하고, 그 PG서비스가 제공하는 것들 중에서 우리가 최대한으로 이용할 수 있는 것 까지 알고 있어야 합니다. 만약 일인다역을 하고 있는 개발자라면, 해당 PG서비스를 서버에 설치하고, 데몬을 올리는 일 부터 시작해서, 기획자가 요구하는 기능을 구현하기 위해 고민도 하겠죠.

PG서비스 이야기가 나왔으니 말인데, PG서비스를 통해 전달되는 각종 데이터들이 우리 서비스DB에 정상적으로 잘 저장이 되어야겠죠.  PG는 매출과 직결되기 때문에, 매출내역에 미싱이 되지 않도록 해야 할 것이고, 우리 DB에 누적되는 데이터와 PG사에 누적되는 데이터가 동시에 쌓여야겠죠.  PG서비스가 제대로 구동되지 않으면, 고객 컴플레인도 민감하게 오는 서비스이니 개발자도 여간 신경쓰이는 부분일 수 밖에 없습니다.  여기에 기획자가 만약 해당 PG 서비스를 통해 얻고자 하는 데이터들이 많다면, DB설계를 하면서도 많은 내용을 담아야해서 복잡해질텐데, 데이터가 다양하게 쌓인다는 소리는 관리자 화면에서 기획자가 보고자 하는 이야기가 많다는 뜻이기도 하니까요.

 

이런 데이터들이 쌓여야 매출을 위한 통계도 낼 수 있을 것이고, 어떤 상품매출이 높은지도 알 수 있을 것이고, 카드결제, 가상계좌, 실시간계좌이체 중 어느 부분에 선호도가 높은지 등등...(아주 기본적인 내용이지만, 판매상품의 성격에 따라 다를 수도 있을테구요.) 이런 것들을 끌어내기 위해서 업체가 제공하는 매뉴얼상의 데이터 이외에도 많은 내용을 누적해야 한다면, 개발자는 신경을 많이 쓸 수 밖에 없습니다.

PG서비스에 금액을 계산해서 던지는 그 순간부터 결제가 완료되는 순간만 염두에 두어야하는게 아니라 상품의 구매부터 배송완료되는 부분까지의 프로세스를 모두 이해하고 있어야지만 제대로 구현할 수 있겠죠.  요즘엔 이런 PG서비스에서 더 나아가, 규모가 큰 쇼핑몰이라면 에스크로라는 매매보호서비스때문에 소비자에게 물건이 정상적으로 배달되는 순간까지의 데이터를 핸들링해야하고, 이 때문에 신경쓰고 케어하며 배달해야하는 범위는 더 늘어날 수 밖에 없습니다.

이건 비단 PG 서비스만이 아닙니다. 자체 서비스에 붙이는 소소한 기능들(예를 들어, MMS라든가 메일발송이라든가)에 외부 솔루션을 최초 붙이거나 해야한다면, 내 서비스와 구입한 솔루션 서비스간의 흐름을 모두 이해해야 하기 때문에 조금은 신경써야하는 것들이 많을 수 밖에 없겠죠.  이는 기획자가 기획을 하는데 있어서, 당위성이나 여러 방법론을 고민하는 것과 같이, 개발자 역시도 전반적인 흐름이나 기획자의 요구사항을 구현하기 위한 많은 Background 작업이 필요하기 때문에 개발자의 업무를 조금 더 폭넓게 생각해주셔야 합니다. 

 

 

예를 들어, PG서비스 붙이는 기획안 그렸는데, 개발자가 "이까짓거 그냥 같은 PG쓰는데꺼 캡쳐떠서 copy&paste 한게 다잖아. 이런거라면 나라도 백장은 더 그리겠다! " 이런 반응이라면 당연히.. 기분 안 좋으시겠죠?  상대방이 하는 일에 대한 이해가 완전히 되어 있지 않다면 굳이 불필요하게 기분 나쁜 말은 쓰지 않는게 참 좋은데 말이죠.

 

10년 넘게 이쪽 분야에서 각종 업계를 넘나들며 일하고 있지만, 웹서비스의 중요한 부분은 기획, 디자인, 개발자간의 협업인데, 불필요한 감정싸움과 정치때문에 잘 될 것도 안되는걸 자주 봐왔답니다.  물론 그렇다고 해서 개발자의 영역을 파악하기 위해 책 보고 공부해서 '개발자와의 말싸움에서 밀리지 말아야지.' 라는 생각을 갖기 보다는 어떻게 하면 개발하는 사람 잘 설득해서, "내가 바라는 대로 잘 만들어낼 수 있도록 끌고 갈 수 있는 지혜를 터득할 지"를 고민하시는게 더욱 중요하다고 생각합니다.  가뜩이나 기획적으로도 생각할 일이나 공부해야 할 것들도 많은데 굳이 그런 소모적인 부분에 시간을 쏟을 필요는 없겠죠.

다시 앞으로 돌아가서 PG서비스 개발을 기준으로 이야기한다면, PG 서비스를 붙이는데 기간이 얼마나 되느냐는 기획자의 질문에 개발자가 대략 1, 2주 정도 소요가 된다고 대답했을 때, 이까짓 거 그냥 하면 되겠구만 무슨 2주나 걸리냐고 반문하는 A 유형의 기획자도 있을 것이고, 무엇때문에 그러느냐, 이슈가 있느냐라고 먼저 이유를 묻는 기획자의 B 유형의 기획자도 있을 겁니다

 

보통, 이런 경우.. 개발자 입장에선 앞서 언급했던 매뉴얼 체크 등 여러가지 이유를 이야기합니다. '기존 소스와 서비스모듈을 맞춰야 하고 어쩌고 저쩌고...' 등등을 이야기 할텐데, 기획자와 개발자 간의 원만한 커뮤니케이션은 이 다음 스텝에서 기획자가 어떻게 대처하느냐에 따라 그 결과가 판이하게 달라집니다. 

 

A 유형의 기획자와 같이.. "에이 뭐 그거 짜맞추기만 하면  하루만에 다 하겠네." 라고 이야기하고, B 유형의 기획자는 "개발 요소보다는 신경써야하는게 많은거네요. 조금만 시간을 당겨볼 순 없을까요? 2주는 좀 부담되네요." 라고 이야기 한다고 가정할 때.. 당연히 후자 유형에 동하는 건 당연한 일일 겁니다.

 

 

요즘 들어, "실무자들 간에 커뮤니케이션을 잘 하기 위해선 어떻게 해야할까?"에 대한 아젠다로 많은 고민을 하고 있는데요, MBC 시사 프로그램인 100분 토론을 보며 커뮤니케이션의 방법론에 대해 많은 것을 느낍니다.  토론을 보다보면, 어떤 패널은 상대의 이야기 중 자신의 생각과 다른 부분이 있을 경우 이야기를 다 들어보지도 않고, 사실관계를 중심으로 윽박지르고 상대에게 자신의 의사를 강하게 인지시키는 반면... 변희재나 진중권.. 전원책 같은? 어떤 패널은 상대의 이야기를 다 들어보고, 맞는 부분이 있다면 인정하고 인정하는 와중에 자신의 생각을 덧붙이며 의견을 개진하는 패널도 있습니다.

 

이런 경우, 보통 전자에 해당하는 유형의 패널을 접하는 상대방은 이질적이거나 기분나쁜 감정을 갖기도 하고, 경우에 따라선 상당히 침통한 감정을 갖기도 하는데, 후자 유형의 패널을 접하는 상대는 즐거운 분위기에서 화기애애한 감정이나 분위기를 느끼게 될텐데, 이 같은 정의를 토론이 아닌 업무적 커뮤니케이션으로 옮겨본다면 전자의 경우 많은 충돌로 인해 서로 간에 감정의 골만 깊어지고, 원활한 업무진행에 불가능하겠지만, 후자의 경우 개발자에게 다소 무리한 업무라 할지라도 큰 무리만 없다면 기획 이슈에 대한 기대치를 충족시키기 위해 좋은 기분으로 노력하는 분위기가 형성됩니다.

 

흔히, 개발자나 디자이너와 친밀한 관계가 형성되어야만 기획적 요구사항을 수용하는데 유리하다고 말합니다.  물론 적당한 수준의 친분이야 나쁘지 않겠지만, 굳이 친밀한 관계를 형성하기 위해 간빼주고 쓸개 빼줄 필요는 없다고 생각합니다.  다만, 조금 더 합리적인 수준에서 생각하고 상대의 입장을 생각하는 대화만으로도 기획적인 역량을 온전히 발휘할 수 있지 않을까 생각하며, 글을 마칩니다...

 

 

미시깽. 토끼같은 귀여운 딸래미 둘과 사과같은 남편과 살고 있는 웹개발 13년차.  아이러브스쿨과 SK커뮤니케이션즈 등을 거쳐, 국회입법조사처와 한국지역정보개발원에서 IT관련 빡센 행정업무를 경험하고, 세훈항운(주)에서 다시 웹개발을 시작, 자회사인 (주)온필에서 기술개발팀장으로 있으면서, 여행업이라는 새로운 분야에 대해 배우는 마음으로 시스템 개발에 매진 중.