스타트업은 어떻게 일하는가?
우리는 어떻게 일하는가?
본 글의 경우 필자가 다녔거나 혹은 다니고 있는 회사에서 일하는 방식에 더해 주변에 스타트업에서 일하는 사람들과 한 이야기를 바탕으로 썼을 뿐, 각자의 회사마다 일하는 방식이 다르기 때문에 일하는 방식에 대한 절대적인 가이드나 표준은 절대 아님을 밝힌다. 혹시나 스타트업에서 더 나은 문화를 추구하거나 혹은 내부적인 문화를 만들려고 노력하는 분들에게 도움이 되길 바라는 마음에 글을 쓴다. 아마 대부분의 회사는 아래의 사진과 같은 업무 프로세스를 가질 것이다.
회사에 따라 부분적인 과정을 스킵하고 넘어가는 경우도 있고 별도의 QA 인원을 둘 수 없는 경우에는 개발자가 QA를 진행할 수도 있다. 이렇게 우리는 하나의 서비스 혹은 하나의 기능을 만들기 위해 이렇게 길고 다양한 과정을 거친다. 만약 이러한 과정에서 만약 조금이라도 미스 커뮤니케이션이 일어난다면 아마 유관부서는 그만큼 다시 이 과정을 거쳐야 한다. 그래서 많은 서비스 회사에서는 커뮤니케이션에 많은 비용을 투자하기도 한다.
문제 도출 및 일정 산정
모든 과정의 첫번째는 문제 도출이다. 우리에게 필요한 서비스 혹은 필요한 기능이 무엇인지를 먼저 파악을 해야 한다. 이 과정에서는 많은 부서와 깊은 연관을 가진다. 사업부, 영업 조직, CS 조직, 혹은 마케팅 조직 등등 다양한 유관 부서와의 커뮤니케이션을 통한 새로운 기능이 추가될 수도 있고, 혹은 분기별 사업 목표일 수도 있다. 이 과정에서 진행해야할 프로젝트의 우선 순위를 정하게 된다. 그렇게 정해진 우선 순위에 따라 프로젝트 별 일정을 산정을 하며, 그에 따라 필요한 인력을 투입하게 된다. 만약 프로젝트의 기능이 큰 경우나 우선순위 여부에 따라서는 별도의 TF 팀을 꾸리기도 한다.
기획
기획 단계에서 서비스에 대한 기획이 이뤄지며, 이 과정에서 기획자들은 개발자 혹은 디자이너와 꾸준한 커뮤니케이션을 한다. 이 역시 회사에 따라 다를 수 있지만, 보통 이 과정에서 필요한 이슈들을 Jira 나 Trello 와 같은 협업 도구를 이용하여 이슈 번호를 생성하기 시작한다.
물론 이러한 협업 도구를 이용하지 않고 칸반 보드를 이용하여 포스트잇을 붙여 스케줄을 관리하는 경우도 있다.
현재 진행 중인 프로세스에 대해서는 가볍게는 Backlog, In progress, Review, Done 등으로 나뉘게 된다. Backlog 등은 앞으로 우리가 해야할 일들에 대한 이슈들을 모아둔 과정이다. 여기에 있는 이슈들은 우선순위에 따라 In progress 로 옮겨지게 된다. In progress 는 현재 진행 중인 업무들에 해당하며, 이 과정을 지나 Review 과정을 거쳐 Done 처리가 된다.
기획 단계에서의 산출물은 PDF 혹은 PPT 등으로 나오기도 하며, 일부 회사에서는 Confluence 에 문서화 하는 경우도 있다.
디자인
디자인 단계에서는 기획 단계에서 나온 기획 문서에서 정의한 프로토 타입을 토대로 시각화 하는 과정을 거친다.
위키 백과에 따르면 프로토 타입을
정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델으로 정의하고 있다.
이 과정에서 디자이너들은 Adobe 사의 Photoshop이나 XD 를 이용하거나 Sketch, Zeplin 등을 이용한다. 아마 많은 사람들에게 포토샵은 익숙하지만 XD 나 Sketch, Zeplin 는 익숙하지 않을 것이다. Sketch 는 UI 디자인을 하기에 유용한 툴이고, Zeplin 은 그에 따라 산출물을 보여주기 위한 것이라고 생각하면 된다.
개발
개발 단계는 크게는 프론트엔드 개발, 백엔드 개발 두가지로 나뉘어진다. 또 프론트 엔드는 흔히 자바스크립트를 이용하는 프론트 개발 과 HTML, CSS 를 이용하는 마크업을 개발하는 마크업 개발이 있다.
회사에 따라 마크업 개발자가 별도로 분리되어 있는 경우가 있지만 프론트 엔드 개발자가 마크업과 자바스크립트 개발을 같이 하는 경우도 있다. 마크업 개발자는 디자이너에게 받은 디자인 산출물을 HTML 과 CSS 를 기반으로 하여 화면을 그리는 역할을 한다. 자바스크립트 개발자는 개발이 완료된 마크업에 백엔드 개발자로부터 받은 API 데이터를 연동한다. 이때 주로 자바스크립트 프레임워크를 많이 이용한다.
이 과정에서 사용하는 것 다양한 툴이 있다.
API 문서화
백엔드 개발자와 프론트 엔드 개발자는 보통 API 를 기반으로 커뮤니케이션을 한다. 그러기 위해서는 제일 중요한 것은 문서화가 중요하다. 물론 일부 정적인 문서를 작성하는 경우가 있지만 그러한 경우는 보통 히스토리 관리가 안되어 작성하고 나서 한달만 지나고 나면 레거시가 되는 경우가 허다하다. 제일 중요한 것은 실제의 API 를 확인할 수 있는 것이 제일 중요하다. 그때 보통 사용하는 것이 Postman, API Doc, Swagger 등을 사용한다.
개발 관련 문서화
개발을 하다보면 개발 관련해서 문서화를 해야하는 경우가 굉장히 많다. 보편적으로 이슈 트래킹, 컨벤션 혹은 개발 과정의 히스토리를 기록한다. 이때 보통 이용하는 것이 Confluence 이다. 기타 여러개의 다른 플랫폼과 호환성 역시 좋아 많은 기업에서 애용한다.
형상 관리 도구
개발을 할때 앞의 2가지는 빼놓을 수 있지만 제일 중요하면서도 빼먹을 수 없는 것이 바로 형상 관리 도구이다. 아마 어떠한 형태로든 개발자라면 한번씩은 접해봤을 도구일 것이다. 과거에는 SVN 을 많이 이용을 했었고, 현재는 Git 을 많이 이용한다. (아직도 SVN 을 이용하는 곳도 있다.) 그리고 그 Git 이라는 시스템을 지원 해주는 플랫폼으로는 Github, Gitlab, Bitbucket 등이 있다. 오픈 소스도 마찬가지이지만, 이 과정에서 개발자들끼리 서로 코드리뷰를 진행하며, 만약 리뷰를 해야 하는 소스가 중요한 소스라고 하면 별도의 회의 시간을 가질 정도로 중요한 과정이다.
이러한 과정을 거쳐 개발을 하게 되고, QA 과정으로 들어가기 전 새니티 테스트를 진행하게 된다. 그리고 새니티 테스트가 완료가 되면 전문 테스터에게 리뷰를 받은 후 배포하는 과정이 이뤄진다.