기획자의요구와개발자의현실을
모두만족시키는소통의기술
개발자와기획자,한배를탔지만서로다른언어를쓰는이들의갈등은어제오늘일이아니다.분명일하고있는데프로젝트는제자리걸음이라면,이제소통의방식을점검해야할때다.8년의개발경력과5년의기획실무를거치며양쪽의언어를모두섭렵한저자의경험에따르면,갈등을풀수있는실마리는아주높은확률로‘기획자’에게달렸다.기획자가개발과정을이해해야비로소협업의병목구간을정확히파악하고절충해프로젝트를완수할수있는실질적인해법을찾을수있기때문이다.따라서이책은현업에서발생하는수많은문제상황에대해개발자의입장을‘기획자의시선’에서풀어낸다.
1부‘화성에서온기획자,금성에서온개발자’에서는함께일하는개발자가어떤사람인지에대해알아본다.개발자가어떤태도로일을대하고어떻게문제를해결하는지등그들만의고유한특성을파헤친다.이를통해기획자가흔히겪는소통의벽이사실은서로를향한불신이아니라’일‘을바라보는시각차이에서온다는점을깨닫고,개발자의사고방식을입체적으로이해하는기초를다진다.
2부‘개발자와의흔한갈등사례’에서는현장에서가장빈번하게발생하는생생한갈등사례를중심으로기획자가한번쯤품었을법한의문들에대해개발자의속사정을들려준다.그동안‘왜안된다는거지?’라며답답함을느꼈던근본적인원인을짚어보고,갈등의벽을넘기위한대응책을찾는다.
3부‘협업을위한개발기초지식’에서는기획자로서개발자와원활히소통하는데필요한개발지식을살펴본다.클라이언트와서버의관계부터데이터베이스의작동원리,그리고Git이나JSON같은협업도구의개념까지폭넓게다루며,비개발자가기술적장벽을넘어데이터와논리에기반한의사결정을내릴수있도록한다.
4부‘개발자와함께완벽한기획자로성장하는법’에서는앞서배운이해와지식을바탕으로개발자와함께성장하는구체적인실천전략을제시한다.개발자가선호하는기획서작성법부터기획자의치트키가될API검토노하우,그리고질문하나로개발자의방어기제를허무는질문법까지,기획자의전문성을증명하고프로젝트의성공을이끄는실무생존기술을아낌없이공개한다.
만약개발자를이해하기위해이책을집어들었다면이미절반은성공한셈이다.상대방을이해하고자하는마음은협업의가장강력한무기가되기때문이다.이책을통해그들의세계를들여다보고이해의접점을찾는순간,당신이겪는업무스트레스의대부분이눈녹듯사라질것이다.
책속에서
개발자들에게‘된다’는‘모든사항이100%작동함’을의미한다.따라서이들은업무가능여부에관한질문을받으면대부분이일이수행가능한일인지,또불가능한지에대해답변해야하고,또수행가능하다면언제까지할수있는지,어느정도의시간이소요되는지도이야기해야한다.그래서질문을듣는동안요청내용이실현가능한지,불가능한요청은없는지꼼꼼히따진다.마치조금이라도끊어지면열차가달릴수없는기찻길처럼,중간에무언가하나라도구현이불가하다면전체개발이불가능해진다.그러다보니불가능한부분을찾는그들의태도는종종공격적이라고오해를사기도한다.이럴때는최대속도로달리고있어주변을보지못하는경주마처럼그저목표지점(실행가능여부)을향해전력질주하고있을뿐이라고이해하면좋다.(65쪽)
기획자가개발자에게기능구현가능여부를물을때,자연스럽게“언제까지가능한가요?”라는질문을함께던지곤한다.빠듯한일정과성과에대한압박속에서,어떻게든빠르게결과를만들어내고싶은마음은기획자나개발자나마찬가지일것이다.그런데종종개발자로부터이런답변을듣게된다.“이거지금당장하려면하드코딩해야해요”얼핏들으면‘하드코딩’이라는낯선단어뒤에‘된다’라는긍정의메시지가숨어있는것처럼느껴질수있다.‘아,뭔가어려운방법이긴하지만어쨌든된다는거구나!그럼일단그렇게하고,나중에시간될때제대로고치면되지않을까?’하는안도감이들수도있다.(중략)하드코딩이란특정값이나로직을코드안에‘직접박아넣어서’변경이나확장이어렵게만드는것을말한다.우스갯소리로“고수들은귀찮게머리쓰며로직을짜지않고그냥돌아가게만한다”라고도표현하지만,사실하드코딩은결코‘고수’의방식이아니다.오히려당장의편의를위해미래의불편함을예약하는것에가깝다.이렇게하드코딩이된부분은종종잊히며잠재적인위협이된다.유연성이없어매번수정때마다영향이있는지직접챙겨야하는대상이되기도한다.(115-116쪽)
예쁘게디자인된버튼,잘정리된텍스트,사용자를편리하게이끄는인터페이스.눈에보이는화면은말그대로‘빙산의일각’이다.그화면뒤에는수많은코드와로직,DB와의복잡한상호작용그리고알수없는외부시스템과의연동까지거대한시스템이있다.마치거실에조명하나위치를바꾸려고봤더니,그전기선을통해다른조명들이릴레이처럼엮여있어서전체배선을건드려야수정이가능한상황과같다.겉으로보기엔간단한수정요청같아도,개발자에게는이거대한시스템의어느부분을건드려야할지,그파장이어디까지미칠지가늠해야하는복잡한문제로다가온다.특히골치아픈건,내가직접짜지않은‘남의코드’를수정해야할때다.운좋게잘짜이고문서화까지완벽한코드를만난다면정말큰짐을던기분이들지만,현실은시궁창일때가더많다.주석하나없이수수께끼처럼꼬여있는스파게티코드,왜이렇게만들었는지도무지이해할수없는로직,심지어작성자는이미퇴사하고없어서물어볼사람조차없는상황이라면?개발자는그야말로맨땅에헤딩하는심정으로코드해독작업에들어가야한다.(중략)더큰문제는,이런복잡하게얽힌시스템과해독불가능한코드속에‘사이드이펙트’라는언제어디서터질지모르는시한폭탄이숨어있다는것이다.분명버튼A의문구만살짝바꿨는데,갑자기관련없는페이지B에서데이터가꼬이거나,잘되던결제시스템에서오류가뿜어져나올수도있다.(124-125쪽)
데이터규격은컴퓨터와개발자들사이에서,혹은시스템끼리데이터를주고받기위해만든것이다.즉복잡한데이터(정보)를누구나이해할수있도록‘규칙에맞게’정리하기로‘약속’한것으로개발자들에겐없어서는안될중요한매개체다.서로다른시스템,다양한플랫폼이공존하는인터넷과앱서비스환경(웹서버,모바일앱,DB외부API등)에서데이터를주고받는데표준화된규격이필요하다.표준화된규격이없으면데이터를주고받을때마다데이터구분을콤마로할지,탭으로할지,어떤값들을보낼지등을매번정해야한다.또규격없이데이터를주고받으면서로보낸데이터를해석하지못하거나오작동이발생할수있고,복잡한서비스에서는이런문제로큰장애가발생하기도한다.대표적으로가장많이사용하는데이터규격이JSON과XML이다.(214쪽)
개발과정에서는큰아키텍처결정외에도수많은작은기술적결정들이이루어진다.이러한일상적인결정들이모여프로젝트의성공여부를결정한다.예를들어서비스에서간헐적으로에러가발생한다는유저들의민원이어젯밤부터리포팅된상황을생각해보자.개발팀에문의해보니“CPU가피크를찍어서증설이필요하다”라는기술자로서의의견을냈다면,기획자는이결정이추가비용이발생할수있고,상황에따라서비스중단시간이발생할수있다는점을이해해야한다.왜CPU가피크를찍었는지,다른해결책은없는지파악하고의사결정에고려하는것역시중요하다.또다른상황으로,“요청이있을때마다처리하면될거라고예상했던개발방향을배치작업을만들어서커버하겠다”라는개발자의제안을들었다고가정해보자.기획자는이결정이왜필요한지이해해야한다.배치처리는시스템부하를분산시키고효율성을높일수있지만,실시간성이떨어질수있다.이러한트레이드오프를이해하고비즈니스요구사항과맞는지판단해야한다.(351쪽)
