brunch

You can make anything
by writing

C.S.Lewis

by Project One Jun 29. 2018

[Project One] 기획, 개발, 프로세스

경험의 중요성

다른 사람들은 어떤지 모르겠지만 나라는 사람은 경험을 해야지만 제대로 깨우치는 유형의 사람이다. 글을 읽고 영상을 보아 상황에 대한 이해를 했더라도 피상적인 것에 불과하다. 실제로 내가 그 상황을 접해야만 글의 저자가, 영상의 화자가 말하고자 하는 바를 명확하게 이해할 수 있다.


사람은 자기 입장에서 세상을 바라볼 수밖에 없다. PM으로서 일을 진행할 때는 제품을 기획하고 프로젝트를 관리하는데 초점이 맞춰져 있었다. 개발자들이 개발할 때 처하는 상황과 생각을 보다 잘 이해하기 위하여 개발을 공부했고 (이 이유만 있는 건 아니지만), 그들의 입장에서 프로젝트를 관리하고자 노력했지만 결국 난 PM이었기 때문에 기획/관리 관점에서 내 생각을 관철하려 했었다.


최근 기획에서부터 개발에 이르기까지 모든 과정에 참여를 해야 하는 상황에 놓이게 되었다. 실제로 개발 업무를 본업처럼 수행하고 있다 보니 피상적으로만 알고 있었던 내용들에 대해 보다 명확하게 이해할 수 있었다.


1. 대부분의 비용이 결정되는 단계는 초기(기획) 단계이다

대학교 때 배운 관리회계 수업이나 현대자동차 신입 연수 과정 등을 포함하여 꽤나 여러 번 들었던 내용이다. 초기 기획 단계에서 어떤 자원으로 어떤 프로세스를 통해 어떤 제품을 개발할 것인지 결정되기 때문에 실제 비용이 집행되는 타이밍은 뒤라 할지라도, 초기 단계에 어떻게 비용이 쓰일지 결정이 된다는 말이다. 너무나도 당연하다고 생각했고, 초기 기획단계가 중요하겠구나라고 피상적으로 이해했던 내용을 이번 한 주를 통해 몸속 깊숙이 이해할 수 있었다. 

기획 내용이 결정이 되면 이를 바탕으로 개발자는 화면을 어떻게 구성하면 좋을지, 서버에는 어떤 정보와 함께 요청을 보내 어떤 결과를 받아올지, 데이터베이스는 어떻게 설계하여 어떤 정보들을 저장하고 있을 것인지 등 서비스 개발을 위한 다양한 요소들이 함께 결정된다. 이렇게 초기에 결정된 개발 사항들은 프로젝트의 기반이 되는 사항들이기 때문에 구축하는데도 시간이 꽤 걸리고 수정하는데도 시간이 다소 소요되는 항목들이다. 하지만 불행하게도 기획서는 수정되는 일이 다반사다. 기획자의 시장에 대한 이해, 고객에 대한 이해가 높아짐에 따라 수정사항이 발생할 수밖에 없고, 이로 인한 임팩트는 나비효과처럼 점점 확대되어 프로젝트의 기반을 뒤흔들어야만 하는 상황들이 발생하게 된다.


대부분의 사람들은 본인들이 한 것을 다시 한번 살펴보는 것을 굉장히 싫어한다. 내가 가해자(?) 입장으로서 기획 내용을 변경할 때는 고객에 대한 이해도가 높아지면서 수정되면 좋겠다고 생각하는 부분들을 비교적 쉽게 이야기할 수 있지만, 내가 피해자 입장으로서 기획 변경으로 인해 개발 내용을 변경해야 하는 상황을 접하게 되면, 이것 만큼 하기 싫은 일도 없을 정도이다.


기획이 변경되면 시간/비용 등 제약 자원들이 소비될 뿐만 아니라 감정적인 부분까지 소비되는 상황까지 발생하고 이로 인해 개발팀의 업무 효율이 낮아질 수밖에 없다. 그래서 굳게 다짐했다. 의미 없이 두는 버튼, 텍스트 하나 없이 명확한 의도를 가지고 철저하게 기획을 수립해나가야겠다고.

(사실 가해자/피해자로 나누는 것 자체가 잘못된 구분이라 생각한다. 이에 대해서는 다음 주제인 “애자일 개발 프로세스”에서 좀 더 이야기해보도록 하겠다.)


2. 애자일 개발 프로세스의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

수아랩에서 PM역할을 맡게 되면서 가장 먼저 공부했었던 내용이 개발 프로세스이다. 제품 개발을 처음 시작해보는 만큼, 어떤 개발 프로세스를 회사에 정립시키는 것이 좋을지 결정하기 위하여 개발 프로세스의 장단점을 비교 분석하였다. 일반적으로 개발 프로세스는 워터폴 방식과 애자일 방식으로 크게 나뉜다.


워터폴 모델은 철저하게 수립된 계획을 기반으로 하여 개발을 진행한다. 완벽히 정의된 기획서를 만들고, 기획서를 기반으로 해야 할 일들을 정리하고, 각 Task마다 소요시간을 체크하여 간트차트 형태로 프로젝트 일정을 관리하는 방식이다. 일반적인 업무 프로세스와 유사한 만큼 사람들이 이해하기도 쉽고 사용하기도 쉬운 방법이긴 하지만, 기획이 수정되거나 특정 Task에서 예상보다 더 많은 시간이 소요되는 상황이 발생하면 전반적인 계획이 뒤틀어져 출시 이전에 밤샘 작업을 하는 상황이 발생할 수밖에 없다.


이에 반해 애자일 개발 프로세스는 이름에서도 알 수 있듯이 계획보다는 개발을 “빠르게” 수행하여 제품을 “빠르게” 출시한 뒤 고객의 피드백을 받아 업데이트 해가는 과정이다. 애자일 개발 프로세스를 도입할 경우 고객으로부터 지속적인 피드백을 받아가며 제품을 꾸준히 업데이트해나갈 수 있기 때문에 보다 나은 제품을 만들어갈 수 있다는 장점이 있지만, 쉼 없이 개발해 나가야 한다는 점이 부담감으로 다가올 수 있다.

<PM업무를 시작하며 정리했던 개발프로세스 장단점 비교 내용>

워터폴과 애자일 방식을 분석한 뒤 각각의 장점을 취합하여 우리만의 개발 프로세스를 정립하고자 했으나, 워터폴 모델과 애자일 모델에 대한 명확한 이해 없이 새로운 방법론을 만들고자 했으니 이는 나의 아주 큰 자만이자 오산이었다. 애자일 방식에는 “애자일 소프트웨어의 열두 가지 원칙”이라는 것이 있다.

 

애자일 소프트웨어의 열두 가지 원칙

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라.

애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발 한다.

팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.


애자일 개발 프로세스는 대개 “빠른 개발과 피드백”으로 통용된다. 하지만 애자일의 원칙을 살펴보면 결과물에 대한 내용과 과정에 대한 내용이 섞여 있다. 사업부와 개발팀의 협업을 강조하였으며, 구성원들의 동기를 부여하고 그들을 믿어주는 것을 강조하였다. 면대면 대화를 통한 내용 공유화 함께 지속 가능한 개발을 중요시한다. 그러나 나는 워터폴과 애자일의 장점을 섞는다는 명목 하에 빠른 개발만을 강조하였고, 이를 위한 개발 문화를 제공해주지 못한 채 기획서와 일정 계획안을 들이밀었다. 개발팀 규모가 작을 때는 의사소통도 활발히 이루어졌지만 개발팀 규모가 커지고, 나 역시 다른 할 일들이 많아지면서 의사소통 회수 조차 줄어들게 되었다. 이로 인해 개발팀은 빠른 개발과 계획 준수라는 살인적인 기준을 만족시키기 위해 밤샘 작업을 하는 경우들이 발생하였고, 근로 의욕이 떨어지는 상황이 발생할 수밖에 없었다. 결국 개발팀에서 발생하는 문제들을 해결하기 위해 여러 번의 워크숍을 수행하였고, 개인 면담을 진행해야만 하는 상황이 발생했다.


“애자일 소프트웨어의 열두 가지 원칙”은 이전에 개발 프로세스에 대해 공부할 때도 읽어본 적이 있었지만, 위와 같은 일을 겪고 난 뒤 읽고 난 뒤 와 닿는 정도가 차원이 달랐다. 빠른 개발과 제품 출시는 고객이 느끼는 효용을 높이기 위해 필요한 사항이지만, 개발팀의 동기를 부여하는 것이 필수 전제 조건이다. 이를 위해 사업부와의 주기적인 접촉을 통해 제품에 대한 고객의 피드백을 개발팀에게 지속적으로 전달해주어야 하고, 이를 통해 다음번 업데이트할 내용에 대해서 다 같이 결정할 수 있는 구조를 만들어야 한다. 면대면 대화를 통해 개발팀에게 보다 나은 제품을 만들 것을 주문하여 그들을 격려하고  칭찬해 나가야 한다.


사람은 경험을 통해 성장해 나간다고 한다. 좀 더 과장을 보태자면 내가 겪은 경험의 집합체가 나라고 해도 될 것이다. PM으로서 사람들이 필요로 하는 서비스를 보다 많은 사람들에게 제공하는 것이 내 궁극적인 목표이고 이를 달성하기 위해 내 나름대로 여러 가지를 공부하고 있지만, 결국 실제로 경험하는 것보다 더 값진 자산은 없는 것 같다. 알리바바의 회장 마윈은 이런 말을 했다고 한다. “당신의 심장이 빨리 뛰는 대신 행동을 더 빨리 하고, 그것에 대해서 생각해 보는 대신 무언가를 그냥 하라"




Written by 김민석


Proejct One 소개 보기


Project One Facebook

작가의 이전글 [Project One] 시작하는 사람들에게

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari