스타트업은 정말 애자일Agile하게 일할까?
나이 마흔 스타트업 적응기 8
스타트업에 입사하기 전 나의 선입견은 '스타트업은 애자일하게 일할 것이다'라는 것이었다. 내가 생각했던 애자일은 이를 테면 스토리보드라 불리는 상세기획안 단계를 생략하고, 상위 아이디어를 가지고 서로 논의하면서 디자인과 개발을 바로 바로 진행하는 방식이 아닐까 막연히 생각했었다. 그러면서 내가 이런 새로운 업무 방식에 적응할 수 있을지도 걱정이었다.
애자일은 문서작업 및 설계에 집중하던 개발 방식에서 벗어나 좀 더 프로그래밍에 집중하는 개발 방법론이다. 애자일(Agile)이란 단어는 ‘날렵한’, ‘민첩한’이란 뜻을 가진 형용사다. 애자일 개발 방식도 그 본래 의미를 따른다. 정해진 계획만 따르기보다, 개발 주기 혹은 소프트웨어 개발 환경에 따라 유연하게 대처하는 방식을 뜻한다.
출처 : [네이버 지식백과] 애자일 - 프로그래밍에 집중한 유연한 개발 방식 (용어로 보는 IT, 이지현)
1년 넘게 이곳에서 실제로 기획자로 근무하다 보니 알게된 것은 '스타트업이라고 실무자들이 반드시 애자일한 방식으로 일하는 것은 아니다'라는 사실이다. 업무 프로세스는 프로젝트 성격에 따라 달라진다고 보는 것이 맞을 것이다.
기능 구현이 가능한지 여부가 핵심인 프로젝트일 경우는 기획에 앞서서 개발팀이 먼저 선행 연구를 하고, 어느 정도 핵심 기능 개발이 완료되면 그 때 기획자와 디자이너가 투입되어 시각화 작업을 진행한다. 그야말로 애자일한 방식이라 할 수 있다.
반면에 결제 프로세스를 붙인다거나, 댓글 기능 추가 등 일반적인 기능 개선의 경우는 업무 프로세스가 달라진다. 기획자가 먼저 정책을 세우고, 예외 케이스들까지 챙겨서 최대한 꼼꼼한 상세 기획안을 만드는 것이 중요하다. 상세 기획안을 기반으로 디자인, 개발, 테스트까지 순차적으로 진행하게 된다. 워터폴 방식이라 불리는 전통적 형태의 개발 방식이다.
전통적 방식으로 기획안을 먼저 Fix하고 개발을 시작하더라도, 진행 과정에서 더 좋은 방안이 튀어나오거나 또는 기획자의 판단 미스로 중간에 기획안을 수정할 일들이 종종 발생하곤 하는 것이 사실! 이럴 때는 회의를 소집하여 기획안 업데이트 내용을 공유하고 개발 반영 여부를 협의한다. 이 지점에서 스타트업이 다르다고 느낀 점이 있다. 기획안 수정에 대해 훨씬 개방적인 자세로 받아들이고, 더 좋은 개선안을 개발자 스스로도 많이 제안한다는 것. 기획자로 일하면서 놀랐던 지점이다. 중간 중간 개선사항을 반영하면서도 프로젝트 전체 일정 이 많이 지연되는 것도 아니었다.
과거에 규모가 큰 IT회사에서는, 최종기획안 이후에 기획안을 수정할 일이 생기면 담당 개발자에게 백번 사죄하며 부탁하곤 했었다. "이제 와서 말씀드려 정말 죄송합니다. 수정사항이 생겨서 이것 좀 반영이 가능하실까요? 개발 일정에 지연이 생긴다면 다음에 반영해주시고요. 가능하면 이번에 같이 넣어서 어떻게 좀..." 나의 단골 멘트였다. 지금 와서 돌이켜보니 개발자가 기획안 수정을 극도록 싫어했던 건 타이트한 일정과 과도한 업무 탓이 아니었을까. 환경은 똑같은 사람을 친절하게 만들기도, 불친절하게 만들기도 한다. 오픈 일정을 조정할 수 없는 타이트한 상황 속에서 계획했던 일이 변경되고 늘어나는 것을 좋아하는 사람이 누가 있을까?
스타트업이 빠르고 민첩하게 일할 수 있는 이유?
개발 일정에 대한 문제를 곰곰히 생각하다가 내 나름의 깨달음이 있었다. 스타트업에서 프로젝트의 전체 속도를 높일 수 있는 비결은 바로 앞단의 의사결정 기간을 최소화한다는 것! 탑다운 방식의 대규모 조직일수록 프로젝트 진행 여부나 방향성에 대해 임원진들이 보고를 받고, 의사결정을 하느라 시간을 다 잡아먹고, 실무 개발자에게 주어지는 시간은 너무나 촉박한 것이 문제였다. 실무자들이 애자일하게 일하는 것도 중요하지만 무엇보다 의사결정자들이 애자일하게 일하는 것이 더 중요하지 않을까?
