지난 블로그 글 (기획자가 개발자와 일하는 법)이 말도 안되는 트래픽을 불러온 것 같다. 평소 5명도 오지않던 블로그에 하루에 1500명 이상이 들렀으니 더 이상의 설명은 생략해도 될것 같다. 하지만 지난 글 자체가 워낙 도발적인 단어들로 생각을 표현해서인지, 많은 분들이 기분 나빠 하시거나, 한편으론 일부분 공감하고 계시는 분들도 있고 하니 쓰려던 글은 마저 쓰고 생각을 정리해야 할 것 같다.
1편을 요약하자면,
개발에 대해 잘 모르는 기획자가 개발자에게 무리한 요구를 하거나, 무례한 행동을 보이는 경우에 대한 사례나열이 주를 이루었고, 개발자의 개발지식을 기획자도 배워야 하며(그 수단이 좀 치졸했을 수 있다. 하지만 검색해서 아무리 찾아봐도 모르는 경우가 대부분이고, 이해하기 쉽게 누가 알려주는게 기획자 입장에선 가장 쉽게 이해할 수 있는 방법), 서로 부족한 부분이 있다는 것을 인정하고 채워나가야 된다는 것이 글의 요지긴 했다. 도발적인 단어들을 걷어내고 다시 쓸까도 했지만, 이미 퍼질대로 퍼진 거… 뭐. 앞으로 더이상의 대응은 불필요한 논란만 일으킬 것 같다.
2편을 예고하자면,
기획자란 무엇을 하는 사람인지 다시 한 번 생각해 보고, 개발자가 기획자와 일하기 위해서 어떤 행동을 하는 것이 좋을지에 대해 나열해보고자 한다. 물론 정답일리 없고, 내가 대한민국의 모든 개발자를 다 만나본것도 아니거니와, 여기에 적는 행동들은 극히 일부분에 해당하는 내용들일테니, 자신에겐 해당되는 내용이 아니라고 해서 기분나빠할 필요는 없을 것 같다. 다만 표현함에 있어, 일반화처럼 보여질 수 있지만, 필자는 절대 그렇게 생각 안하고 있다는 것만 알아주셨으면 좋겠다.
기획자란 뭐하는 사람일까
이 이슈에 대해서는 기획자란 뭐하는 사람일까 라는 글에서 이전에 한 번 언급한 적이 있었다.
ckliengt님께서 1편에 남겨주신 댓글을 살짝 언급해보고자 한다.
일반적으로 미국, 캐나다 등지의 소프트웨어 회사에서 개발을 할 때에는, FrontEnd Developer, BackEnd Developer(SD), Business Analyst(BA), Marketer, Business Process Manager(PM), Project Manager(PM), Communitcation Manager로 구성이 되어 있다. 이 사람들은 서로가 채워 줄 수 없는 부분을 채워줄 수 있으며, 애초에 모두가 기획자이다.
솔직히 말하면 잘 모르겠다. 해외에서는 어떻게 하는지 관심은 알지만, 피부에 딱! 다가오는 건 없다.
( 덧. "미국에는 웹기획자가 없다?"는 글을 링크합니다. )
한국에서는 분명 기획자라는 직군이 있고, 그들이 하는 일이 별도로 있다. 그리고 내가 기획자로서 해온 일들은 분명 개발자가 하지 않는 일이 대부분이다. 또 다른 원인으로는, 내가 줄곧 벤처기업에만 다녀서 일지도 모르겠다. 저렇게 파트가 쪼개지는 회사들은 최소한 7명은 있어야 하지 않을까? 스타트업에선 디자이너+개발자+기획자가 끝이다. 셋이면 충분하다. 그리고 디자이너는 UI/UX 디자인과 마케팅 등에 참여하게 되고, 개발자는 프론트엔드+백엔드를 개발하고, 기획자는 시장성분석부터 기획, 마케팅과 고객대응까지 아울러야 한다.
다시 생각해봐도 내가 기획자로 일하는 환경때문에 이런 글을 쓰는 것 같다.
아예, “스타트업”이라서의 가정을 가져가면서 글을 쓰는게 낫겠다.
직군을 인정해야 한다
- 기획자는 '기획'+@의 일을 한다. 당신이 생각하는 '기획'의 파이는 @보다 작다.
온라인과 오프라인에 상관없이, 자주 듣는 말이 있다. 한두번도 아니고 여러번 들었다.
“기획자가 필요해? 없어도 되지 않나”
결론부터 말하면 없어도 된다. 기획자보다 개발자가 더 기획을 잘 한다. 디자이너는 기획한대로 바로 그려낼 수도 있다. 생각하는 것은 다 같이 하고, 기획 까짓거 다같이 하면 그만이다. (여담이지만, 난 프로그램 기획 자체는 전체의 50% 정도만 담당한다. 개발자와 디자이너가 거의 다한다. )
여기서 당신이 잊고 있는게 있다면, 한국의 기획자는 기획만 하지 않는 사람이라는 것이다. 회사에 출근해 밥만 먹고 졸다가 집에가는 월급도둑도 아니고, 분명히 회사에 출근해 하루 8시간 이상 일을 하고 있는 사람이다. 업무의 난이도에 있어 차이는 있을 수 있겠지만, 개발자가 정신노동자에 가깝다면, 기획자는 감정노동자에 가까운 직군이다.
개발자/디자이너의 실무자 눈치도 많이 보는 편이고, 외부에서 받는 평가와 고객들로 받는 불평 불만들을 담당해야 되는 사람이다.
개발자 실수로 데이터가 다 날아갔어도, 기획자는 사용자들에게 굽신거려가며 죄송하다고 말해야 되는 자리에 있는 사람이다.
해외는 해외사정이고, 국내에 기획자라는 직군은 이렇게 일하고 있는 사람이 많다고 생각한다.
내가 현재 기획자라는 직군으로 하는 일들은, 아이템 분석, 시장분석, 사업계획서 작성, 대외적인 사업발표, UI/UX기획, 와이어프레임+개발문서 같은 기획서 작성, 일정관리, QA, 광고디자인, 마케팅, 고객대응, 언론보도 등 프로젝트 진행시 필요한 잡다한 모든 것을 다 도맡아 한다. 이걸 딱 잘라내 하나만 고르라면 비지니스 분석? 마케터? PM? 규정하기 힘들다.
회사의 대표자니 당연한 일들 아닌가 하지만, 개발자가 사업계획서를 쓰고, 사업발표를 하러 다니고 하기 힘들다. 서비스 개발에도 촉각을 다퉈야 하는 상황에, 대외적인 활동을 하게되면 시간이 부족하게 될 수 밖에 없기 때문이다. 브랜딩에도 기획자는 필요하고, 마케팅에도 기획자는 필요하고, 프로그램 개발에도 기획자는 필요하고, 디자인 컨셉잡는 것에도 기획자는 필요하다. 이것들 전부를 팀원 모두가 함께할 수 없기에 여럿 실무자와 별개로 이야기한 기획안들의 밸런스를 맞춰주는 기획자가 필요한 것이다.
그래서, 당신과 함께 일하는 사람의 직함이 기획자라고 되어 있으면, 적어도 기획자가 없어도 된다는 말은 안해야 한다.
기획자가 개발자없어도 된다 라는 말을 하면 기분이 어떨지 생각해봤으면 좋겠다. 대부분 회사는 기획자 몸값이 훨씬 싸다. 아이디어 낼 줄 아는 사람 하나만 두고, 개발자 고용보다 더 낮은 가격에 하겠다는 개발자/업체에 하청주면 그만이다. 뭐하러 기분 상해가며 개발자와 같은 공기마시며 같이 일하는걸까. 그것이 혼자 일하는 것보다 함께 일하는 것이 더 좋은 점이 많기 때문은 아닐까? 기획자가 필요없다고 생각했다면, 직군이 다른 사람들과의 협업능력이 부족한 것은 아닌지 자문해볼 필요도 있다고 생각한다.
무슨 생각을 하는지 알아야 한다
- 기획의도에 대해 물어보자
‘기획’, 그 자체는 밖에서 보고 들은 것들, 눈에 보이는 것들을 바탕으로 하나의 스케치를 그려내는 과정이다. 그 주체가 개발자가 되었든, 디자이너가 되었든 상관 없다. 생각에 생각을 더하면 더 좋은 생각과 덜 좋은 생각이 나눠지게 되고, 조금 더 시장의 반응을 신경쓰는 사람이 ‘기획자’라는 사람이다. 다시 한 번 언급하자면, ‘기획’만 필요하면 기획자는 필요없다. 하지만 ‘기획’자가 필요한건 ‘기획력’이 필요하기 때문이다.
기획 자체에 힘을 불어 넣는 사람. 생각이 옳다, 확신을 갖고 그것을 시장에 내놓을 수 있게 만드는 힘이 기획력이다.
뭐가 더 우선순위로 되어야 하는지, 어떤 것을 어필하며 시장에 내놓아야 하는지 정하는 사람도 기획자다.
개발자끼리 일하는 경우엔 간혹(정말 간혹) 프로젝트가 산으로 가는 경우가 있다. 개발자 입장에서는 어떤 것이 중요한지 중요하지 않은지 판단이 잘 안될 때도 있기 때문이다. 개발자 눈에는 중요해 보이는 부분인데, 시장에선 아무도 신경안쓰는 부분도 있기 때문이다. 그게 기획자가 선택과 집중을 하는 이유다.
버그야 물론 고쳐나가야 좋지만, 크리티컬한것이 아니면 그냥 서비스를 낼 수도 있다.
마케팅이나 시장은 타이밍이 중요하기 때문에, 그것의 우선순위를 잡아줄 수도 있다.
그래서 개발자는 기획자가 무슨생각으로 이렇게 기획을 했는지를 알아야 한다.
기능명세서 목록만 보고 쭉쭉 개발하는 것보다, 훨씬 더 구체적인 의도를 아는 것이 중요한 이유다.
기획요구사항을 정확히 얘기하자
기획서가 부족할 수 있다는 것은 1편에서도 충분히 얘기했다. 불만이 있다면 정확하게 요점을 얘기하고, 요구하는 것이 맞다. 이것도 기획이냐고 던질 성질의 것은 아닌 것 같다. 이런 기획서는 개발 못하겠으니 다시 첨부터 라고 하는 것도 애매하다.
기획자는 개발에 대해 잘 모를 수 있으니, 개발자가 코드상으로 확인가능한 요소들에 대해서 이런것들이 필요하니 더 구체적으로 적어서 넘겨라 라고 하는게 낫다. 이건 전적으로 개발자가 말안해주면 기획자가 다시 태어나도 알기 힘든 부분이다. 말해줘도 이해 못하겠지 라거나, 연차가 몇년찬데 겨우 이것밖에 못하나 라고 속으로 말해봤자, 모른다. 개발요구사항에 대해 요구하듯이, 기획요구사항에 대해서도 충분히 요구해야 된다고 본다. 하지만 의외로 기획자에게 요구사항을 구체적으로 넘기는 개발자는 찾기 힘든 것 같다.
“이런게 있으면 얘기를 해주셨어야죠. 저희는 이런 것 까지는 모르잖아요.” 라고 해도 “기획서대로 했는데요…” 하면서 손놓고 있는 개발자들을 보면 뚜껑이 열릴 지경이다. 까라면 까야죠 뭐- 라는 생각을 가진 개발자는 기획자를 자기에게 맞는 스타일로 조련시킬 수 없다. 내 개발 스타일에 맞춰서 기획하게 하는 것도 개발자가 필요한 역량이라고 본다.
내가 그렇게 합을 맞춰준 개발자가 몇 분 있다. 그분들께는 각각의 스타일에 맞게 기획서를 전달한다. UI를 먼저 보는 분께는 와이어프레임에 기능설명을 디테일하게 달아서 전달하고, 기능을 먼저 보는 분께는 각 기능들의 목적과 구현방법, 필요한 예외상황들과 해야되는 처리 목록을 리스트로 먼저 뽑아서 드린다. 서버처럼 수집해야되는 정보들이 많은 경우에는, 아예 UML 다이어그램을 그려서 드리기도 한다. 한개의 프로젝트를 진행하더라도말이다. 기획서 여러버전을 만드는게 번거롭긴 해도 개발자 당사자가 이해하기 쉬운 포맷으로, 좀 더 수월하게 개발하셨으면 하는 바람 때문이다.
조금 더 바라는 게 있다면, 기획단계에서부터 꾸준히 간섭했으면 좋겠다. 기획자가 개발자는 개발이나하라며 껴주지 않더라도, 억지로라도 간섭하려는 자세를 갖는게 좋은 것 같다. (내 스타일이긴 함)
마치며
오늘의 생각이 내일의 생각과 다를 수 있다. 이제까지 만나서 일해본 개발자들, 개발지망생들 다 합쳐도 50명도 안될 것 같다. 마찬가지로 기획자들을 다 합쳐도 50명도 안될 것 같다. 이건 개발자가 기획자가 일하는 방법에 대한 초안이라고 생각한다. 1편 역시 기획자가 개발자와 일하는 법에 대해서도 꾸준히 다듬어 나가야 될 내용들이다.
연차가 쌓이고, 만나는 케이스가 많아질수록, 내 글들은 한참 더 다듬어야 될 것들이긴 하다.
앞으로 더 좋은 내용들로 채워나갈 수 있도록 좋은 분들을 많이 만났으면 좋겠다.
