개발자이지만 기획해 보자
이번 8기 BaseCamp 2주차는 ‘기획하기’ 주간으로 진행되었다. ‘예매 사이트’를 1주일동안 기획해 보는 것이 주 목적이었다. 아니 기획을 1주일씩이나 진행을 하라고…? 솔직히 하루 이틀이면 끝날 줄 알았다. 그런데…
왜 기획 과정에서 개발 생각을 지양해야 할까? 고민…
멘토님을 월요일에 처음 보게 되었다! 솔직히 멘토님께서 조언해주시는 내용들은 처음에는 많이 와닿지 못했다. 아니 어떻게 기획하는 과정에서 개발을 생각하지 않을 수가 있지..? 데이터 프레임을 짜지 않고 관리자 페이지나 영화 예매 페이지를 기획할 수 있을까? 이런 의문들이 머릿속에 가득했던 것이 사실이다. 그래서 팀원들과 멘토님에게 이러한 이야기를 솔직하게 해 보았는데, 다른 팀원들도 비슷한 생각을 가지고 있었고 그래서 더 자주 회의실을 빌려서 회의를 진행했었다.
나는 이러한 생각이나 과정을 부정적으로 생각하지 않는다. 오히려 이 과정을 통해, 단순히 수동적으로 ‘기획 과정에서 개발은 생각하지 말랬으니 개발 얘기는 배제하고 이야기해보자’ 라는 움직임을 취하는 것이 아니라, ‘왜 개발 과정을 생각하지 않고 기획해야 하는 걸까’ 라는 능동적인 사고를 할 수가 있었다고 생각한다.
멘토님께서 이와 관련하여 남겨주신 코멘트가 기억에 남는다.
기획자는 디테일을 굉장히 중요하게 생각합니다. 그렇지만, 기획자가 신경쓰지 못하는 부분이 한두개씩 나오는 경우가 분명 존재합니다. 이는 보통 개발하면서 나오는 경우가 대부분이죠.
그래서 기획자 - 개발자간 첫 리뷰 때 질문을 정말 많이 해야 합니다. “이러한 부분들은 더 디테일하게 해 달라” 는 질문들이요.
이 과정이 되게 중요한 과정입니다. 이래야 나중에 버그가 생기지 않거든요.
대부분의 기획자는 개발자만큼 개발에 대해 잘 알지 못하는 경우가 많을 것이다. 그러나 대다수의 기획자들은 ‘디테일’을 중요하게 생각한다고 한다. 이 ‘디테일’에 대한 시선이 기획자와 개발자가 다를 수 있다고 나는 생각한다.
예를 들어 보자. A라는 기능을 구현해야 한다고 하면 개발자는 흔히 ‘A라는 기능을 구현하려면 B 기술과 C 기술을 사용해야겠군. 시간은 얼마나 걸릴까? 이 기능은 1달 내에 구현하기는 쉽지 않을 것 같네… 그리고 다른 기능에 종속적이어서 차후에 문제가 생길 것 같은데 어쩌지?’ 라는 식의 생각을 주로 할 것이라고 생각한다. (물론, 신입 개발자의 생각이니 차후 내 생각이 달라질 수도 있겠지만 현재의 나는 이렇게 생각한다.)
반면 기획자의 경우, ‘A라는 기능을 고객이 사용할 때 보다 쉽게 사용할 수 있을까?’, ‘B라는 기능이 좌상단에 버튼의 형태로 위치하고 있는데 이 기능의 중요도는 얼마일까? 그러면 이 위치에 이 버튼이 있는 것이 합당할까?’, ‘기획서에는 단순히 “영화 예매” 라고만 적혀 있는데 이걸 버튼으로 해야 할까? 아니면 누르면 그 화면에서 나타나게 해야 할까? 버튼으로 한다면 눌렀을 때 어떤 동작을 해야 고객이 직관적으로 받아들일 수 있을까? 팝업 창이 너무 많이 뜨는 것은 고객에게 불쾌감을 줄 수도 있겠다…’ 등등 사용하는 사람이 어떻게 받아들이는지를 먼저 고민한다고 생각한다.
교육을 들으며 고민을 발전시키고 결론을 내 보자
그래서, ‘그 기능이 구현되는 데 얼마나 오래 걸릴까?’ 를 먼저 생각할 수밖에 없는 개발자와 ‘이 기능이 있으면 고객이 어떻게 받아들일까?’ 를 먼저 생각할 수밖에 없는 기획자간의 갈등은 어찌 보면 필연적이지 않을까 싶다. 이번 주 중간에 ‘기민한 소프트웨어 개발을 위한 요구사항 작성과 추정(우윤정 수석님)‘이란 교육 세션이 있었는데, 이 교육을 들으면서 위 생각을 더욱 하게 되었다. 그러나 결국, 기능 구현 자체에만 집중하다 보면 정작 그 기능이 왜 필요한지에 대한 고민을 덜 할 수밖에 없고 이는 ‘기능’ 자체는 좋을지 몰라도 ‘품질’이 떨어지는 결과를 낳을 수 있다. 반면 개발자에게 필요한 ‘기간’을 고려하지 않고 기획자의 생각을 밀어붙이게 된다면 결과적으로 프로젝트를 기한 내에 끝마칠 수가 없게 될 수 있다. 아이러니하게도 기획자는 ‘품질’에 집중을 했는데 결국 ‘품질’이 떨어지는 현상이 발생할 수 있는 것이다.
프로젝트의 4개 축에는 ‘기간’, ‘기능’, ‘품질’, ‘비용’이 있다고 한다. 이 4개의 축을 모두 고정할 수는 없고, 한 축이 움직이면 다른 축도 덩달아 같이 움직이는 구조로 이루어져 있다. 만약 ‘품질’을 움직이게 되면 ‘기간’과 ‘기능’ 모두 위협받을 수 있는 것이다. 따라서 ‘품질’을 고정하고, ‘기간’과 ‘기능’ 중 하나를 협상하는 것이 일반적이라고 한다.
교육 중간에 ‘플래닝 포커’ 게임을 잠시 진행했었다. 사용자 시나리오를 설계해 보고, 그 시나리오에 해당하는 기능을 개발한다고 가정한다고 하자. 이 때 과연 얼마의 시간과 노력이 걸릴까를 각자 생각해 보고 숫자를 제시한 뒤, 최고점과 최저점의 점수를 제출한 사람들이 그 이유를 밝히고 다시 숫자를 제시함으로써 서로간 접점을 찾아가는 게임이다.
우리 조는 이 게임을 정해진 시간 내에 완수하지 못했다. 같은 기능이 쓰여 있더라도, 서로 생각하는 중요도가 다르다는 것을 알았고 또 내가 미처 생각하지 못한 부분을 언급받을 때도 있었다. 나는 이 과정을 통해서 왜 기획할 때 개발을 생각하면 안 되는지를 깨달을 수 있었다. 개발자라는 우리들도 서로 생각이 달라서 조율하는 과정이 필요한데, 기획자가 기획할 때부터 이걸 생각해서 제시한다면 그걸 보는 개발자는 이를 어떻게 받아들일까? 그리고, 기획자도 정해진 시간 안에 기획을 해서 개발자에게 제시를 할 텐데, 기획자가 생각하는 ‘디테일’이 개발자가 생각하는 ‘개발’이라는 족쇄에 묶여 발전되지 못할 수 있다는 생각에 미치자 ‘왜 기획 과정에서 개발 생각을 지양해야 할까’에 대한 답을 어느정도 찾을 수 있었다. 나는 모든 것을 한번에, 그리고 혼자서(한 집단이) 할 수는 없다고 결론내렸다. 그래서 서로를 이해하고 접점을 찾아가는 과정이 필요한 것이 아닐까…
기획자의 시선에서 기획서를 만들어 보고 다시 깨닫기
교육을 끝마치고 본격적으로 ‘발사믹’이라는 툴을 사용하여 기획서를 만들고 다듬어 보기 시작했다. 수요일에 교육을 듣기 전에는, 어떤 툴로 기획서를 만들어 볼까 고민하고 조사한 뒤 팀원들끼리 논의를 통해 ‘발사믹’이라는 툴을 사용하기로 하고 (실시간 공유가 가능하다는 점이 큰 장점이었다.) 페이지를 나눠서 구성하는 과정을 거쳤다. 이때는 단순히 페이지 레이아웃에만 신경을 많이 썼었는데, 교육을 듣고 나서 본격적으로 사용자 시나리오를 몇개 구성하여 그에 맞게 각 요소의 위치, 디자인, 어떤 이벤트가 동작할 것인지(버튼, 슬라이딩, 마우스 올리기 등등..) 등등을 세부적으로 생각할 수 있었다. 고객 즉 사용하는 사람의 입장이 되어 ‘내가 이 사이트를 이용한다면 과연 무슨 생각을 할까?’ 이 생각을 먼저 하며 진행하니 조원 모두가 ‘개발’은 희미해지고 ‘기획’에만 온전히 집중할 수가 있었다.
이 시점이 되자 목요일에 멘토님께서 다시 한 번 조언을 해 주셨다.
기능들의 우선순위를 한번 나눠 보세요. 지금 있는 여러가지 기능들을 1차, 2차, 3차로 나눠 보고 그 이유를 한번 생각해 보세요. 반드시 필요한 기능이라면 1차에 있어야겠죠? 이를 기획서에 보기 좋게 반영하는 것이 좋습니다.
기능 간 우선순위를 나누어 보라는 조언이었다. 이 조언을 통해 기획서를 한 단계 업그레이드 할 수 있었다. 우리는 신호등을 본따서 1차 기능에는 빨간색 콜아웃으로, 2차 기능에는 노란색 콜아웃을, 3차 기능에는 초록색 콜아웃을 부착하였다. 이 과정을 거치고 나서야 비로소 ‘기획서’라고 불릴 수 있는 기획서가 탄생하게 되었고, 목적에 맞는 사이트 구성과 여러가지 이벤트들이 생길 수 있음을 알게 되었다. 즉 프로젝트 전체의 ‘품질’이 기획 단계에서 크게 판가름날 수 있음을 깨닫게 되었고 따라서 세세한 디테일이 매우 중요함을 깨닫게 되었다. 개발자로서는 한 단계 시야를 넓힐 수 있어서 좋았고, 기획에 있어 1주라는 시간이 그리 긴 시간이 아니었음을 깨닫게 된 소중한 시간들이었다.
‘2주차 조장’의 역할로 한 주를 보내보자
교육기간 동안, 주차마다 조장을 돌아가면서 맡게 되는데 2주차에는 내가 조장의 역할을 맡게 되었다. 그래서였는지는 모르지만 확실히 1주차때에 비해 말을 엄청 많이 하고, 의견도 엄청 많이 냈었다. 물론, 각자 spring을 공부하고 git도 각자 repository에서 테스트해봤던 1주차와는 다르게 이번 주차에서는 조원들이 함께 진행하는 기획 단계이기 때문에 그럴 수도 있다. 하지만 그것을 감안하더라도 평소에 과묵했던 내 모습과는 많이 다른 모습을 보여주었다고 생각한다.
기획과정을 진행하고 조장을 맡아 회의실도 빌리고 토의를 진행하면서 나한테는 좋은 습관 하나가 붙었다. 바로 ‘기록하는 습관’이다. 교육을 듣거나 회의를 할 때마다 메모장 또는 Typora를 켜서 기록을 하고, 나중에 그것을 정리해서 루키오리TF 위키에 회의록도 올리고 공부 자료도 올리고 그것을 서로 공유하는 것이다. 처음에는 ‘조장이니까’ 라는 생각으로 회의록도 정리하고 발표 자료도 나름 간단하게 만들었지만, 팀원들이 그것을 보고 피드백도 해 주고 내용을 추가하거나 수정도 해 주는 것을 보면서 이 과정들이 굉장히 뿌듯하고 보람찼었다. 나중에는 루키공유 게시판에도 글을 쓰고 싶은데, 내 TF의 다른 팀원들이 자발적으로 먼저 글을 올린 것을 보고 많이 느끼는 바가 있었다. 팀원들에게 더욱 겸손한 자세로 많이 배워야겠다고 생각했다.
베이스캠프 2주차를 지나면서 소감은, 더욱 치열하게 고민해보고 논의해 볼 수 있어서 좋았다고 이야기하고 싶다. 쉽게 넘어가지 않는 팀원들이 있고 나 역시 그러하기 때문에 결과적으로는 더 뿌듯하고 완성도 높은 기획서를 만들 수 있었고 발표 역시 그럴 수 있었다. 발표 할 때 돌발적으로 2건의 질문이 들어왔었는데 잘 대처할 수 있어서 좋았다.
물론, 1주차 소감문에도 썼었지만, 당장 눈앞의 결과에 일희일비하기보다는, 묵묵히 배워나가고 팀원분들에게 좋은 영향을 줄 수 있도록 노력하는 개발자가 되고자 한다.
p.s. 이곳에 올린 기술적인 이야기, 여러 의문들, 그리고 교육 내용들을 꼭 이 블로그에 포스팅해보고, 루키공유 게시판에 1개 이상 공유글을 올려 보자!