IT 업계에서 커리어를 시작한지 올해로 5년차가 되었다. 회사에서 나의 직무는 서비스 기획자이다. 그동안 4개의 프로덕트를 만들었고 런칭했다. 이 프로덕트들은 대부분 사내 개발자들이 사용하는 웹 콘솔 프로덕트였다. 내가 해왔던 일의 사이클을 정리해보고, 내가 겪은 경력 개발의 희망편과 절망편을 담아봤다.
제품을 만들 때 서비스 기획자가 하는 일
1. 어떤 제품을 만들 것인지 구체적으로 논의하는 단계
- 사용자 인터뷰나 데스크 리서치 등 리서치로 부터 시작하여, 어떤 제품 혹은 기능을 만들 것인지 담당 Product Owner와 논의하는 단계를 거쳤다. 이 단계의 결과물로는 정리된 리서치 위키 자료, 제품의 목적이나 주요 기능 등이 담긴 Product Spec이 나온다.
- 주요 산출물 : 리서치 위키 자료, Product Spec
2. Product Spec을 기반으로 세부 기획을 시작하는 단계
- 제품 혹은 기능의 전반적인 Spec이 나왔다면, 구체적으로 기능을 쪼개서 진행 일정을 담은 마일스톤을 Product Owner가 만든다. 내가 속한 조직은 Agile 기반 개발 프로세스를 따르고 있으므로, 기능 단위 별로 User story와 DoD를 작성한다.
- 만들어진 User story를 가지고 기획서를 작성한다. 기획서를 작성할 때는, 각 기능의 권한, 범위, 연동 방식 등을 고려한 정책 문서를 만든다. Product Owner와 논의하여 이 제품 혹은 기능을 기획할 때 고려해야 하는 여러 사항들을 논의하는 미팅을 가지고, 문서로 정리하는 과정을 거친다.
- 정책 문서가 완성되면, High-fidelity 화면 기획서를 작성한다. 내가 일하는 조직에는 디자이너가 없으므로, 최대한 구체적으로 화면 요소를 정의한다. 주로 Axure 툴을 사용했다.
- Axure 툴은 프로토타이핑에 특화되어 있는 툴이라, 화면 간, 컴포넌트 간 interaction을 구체적으로 정의할 수 있다. 정책 문서를 기반으로 각 기능에서 발생가능한 모든 케이스를 고려하여 기획서에 담아낸다.
- 주요 산출물 : User Story, 정책 문서, High-fidelity 화면 기획서
3. 제품을 만드는 단계
- 기획서가 완성되면 함께 협업하는 개발팀에 기획서를 설명한다.
- 기획서를 보고 개발자가 하는 질문에 답변하고, 기획서에 빠진 부분이 있다면 그것을 다시 반영하여 기획서를 업데이트 한다.
- 기획서를 기반으로 백엔드 개발자가 데이터 구조나 API 설계 문서를 만든다. 이 과정에서도 개발자가 질문하면 응답하고, 논의가 추가로 필요하거나 기획이나 정책에서 변경되어야 하는 부분이 있다면 논의 후 반영안을 도출하여 기획서 및 제반 문서를 업데이트 한다.
- 프론트 개발자와 화면 구성을 논의하고, 디자인 감각이 있는 프론트 개발자가 더 나은 UX 구성을 제안할 경우 기획의도와 어긋나는 것이 없는지 확인 후 논의하여 반영한다.
- 주요 산출물 : 개발자와의 질의응답, 논의 미팅 노트, 피드백을 반영한 기획서
3과 4분의 3. 제품 개발이 마무리에 접어드는 단계
- 1~2단계에 비해 3단계는, 개발자의 질문에 의해 업무가 결정되는 경우가 많으므로 다른 업무를 병행하는 경우가 많다. 만들고 있는 기능의 QA를 위한 QA 시트를 작성하거나, 사용자 가이드를 작성할 수도 있다.
- 혹은 새로운 기능 혹은 제품으로 1~2단계를 수행하고 있을 수도 있다.
- 주요 산출물 : QA 시트, 사용자 가이드
4. 제품의 품질을 점검하고 오픈하는 단계
- 모든 제품 혹은 기능의 개발이 완료되면, QA를 진행한다.
- 작성해둔 QA 시트를 기반으로 수동으로 기능을 점검하고, 이슈가 발생하면 JIRA 티켓을 발급하여 담당 개발자에게 할당한다. 이 때에, 발생 현상과 재현 방법을 구체적으로 단계 별로 적고, 발생 URL을 표기하여 담당 개발자가 이슈를 빠르게 파악할 수 있도록 돕는다. 스크린샷을 추가하거나 기획서를 첨부하여 어떻게 이슈가 해결되어야 하는지 명확하게 이해할 수 있도록 하는 것이 좋다.
- QA는 2–3차 진행하게 되는데, 어느정도 QA가 완료되면 릴리즈 일정을 결정한다.
- 업데이트 된 기능을 담은 릴리즈 노트를 작성한다.
- 작성해둔 사용자 가이드도 포함하여 릴리즈 배포를 진행한다.
- 주요 산출물 : QA를 진행하는 JIRA 티켓, 릴리즈 노트
5. 릴리즈 후 사용자 피드백을 수집하고 반영하는 단계
- 릴리즈 후 프로덕트를 사용하는 사용자들에게 업데이트 기능을 안내한다.
- 사용자 인터뷰, 설문 등을 통해 사용자 피드백을 수집한다.
- 피드백 중 제품 기능 업데이트가 필요한 부분을 백로그로 추가한다.
- 이터레이션에 맞추어 백로그에 있는 기능을 기반으로 2~4단계를 반복 시행한다.
- 주요 산출물 : 사용자 인터뷰 자료, 사용자 설문 자료, 제품 백로그
희망편 :
커리어 개발을 위해 내가 원했던 것은, 앞서 언급한 사이클 내에서 내가 더 완성도를 높이고 싶은 부분은 어디인지 파악하는 것이었다.
해보고 싶은 일은 많았다. 기획자 입장에서, 백엔드 개발자의 데이터 구조나 API 설계에 대해 기획을 기반으로 기술적인 조언을 할 수 있게 된다거나, 수동으로 수행하는 QA에 자동화를 도입하고 싶기도 했다.
Product Owner와 서비스 기획자로 분리된 역할로 인해, Product Spec을 만드는 단계에서 할 수 있는 역할이 제한적인 것이 아쉬웠으므로 Product Owner의 역할을 맡아서, Product Spec 부터 쓰면서 프로덕트를 만들어보고 싶은 마음도 있었다.
또, 사용자가 대부분 내부 개발자인 프로덕트라 사용자의 수가 적고 외부 시장에 나가는 프로덕트는 아니다보니 겪는 규모의 아쉬움도 있었는데, 회사 바깥으로 릴리즈 할 프로덕트를 만드는 것도 도전해보고 싶은 일이었다.
정리해보자면, 내가 수행해온 업무의 각 단계의 일에서 더 높은 완성도를 낼 수 있도록 노력하거나 경험해보지 못한 분야를 도전해보는 것이 내가 원하는 일이었다.
절망편 :
하지만 내가 처한 상황은 나의 희망과는 다르게 흘러갔다. 우선, 외부에 프로덕트를 내보이는 것은 당장 조직의 목표에 부합하는 일이 아니었다. 이를 포기하는 것은 어렵지 않았다. 더 큰 문제는 따로 있었다. 개발자가 질문하지 않는 기획서를 작성하는 것이 일을 잘하는 것이라는 얘기를 들었다. 그것이 비유적인 표현이었을지라도, 내가 지향하는 업무 방향과 매우 달랐다. 나는 완벽한 문서를 작성해서 개발팀에게 전달하는 것이 아니라, 빈 부분을 함께 채워나가며 더 나은 프로덕트를 만들기를 원했다. 결국에는 여러 안좋은 상황이 겹치면서 내가 그동안 해온 업무까지 할 수 없는 상황으로 흘러갔다. 좋은 것 100가지가 있어도 안 좋은 것 1가지가 모든 것을 망칠 수 있다는 걸 뼈저리게 배웠다.
내가 해왔던 일의 사이클에서 튕겨져 나온지 6개월이 지났다. 바랐던 모양은 아니지만, 지금 속해있는 팀과 업무에서 내가 개발하고자 했던 영역 몇가지를 시도할 수 있게 되었다. 현재 담당하고 있는 업무는 조직에서 만드는 프로덕트 전반의 품질 관리이다. 품질 관리 프로세스를 가시화하기 위해서 웹 콘솔 기반 프로덕트 개발을 계획하고 있다. 명확히 Product Owner로 지정된 것도 아니고, 개발팀 규모도 매우 작아졌지만, Product Spec부터 시작해 세부 기능을 구체화 해나가는 업무를 수행하고 있다.
수작업이 많은 업무에 자동화를 도입할 수 있도록 python을 이용한 자동화 툴을 개발할 수 있는 기회가 생겼다. 아직은 간단한 API를 호출해서 자동화하는 정도이지만, 올해 중에 더 많은 업무에 적용할 수 있는 자동화 툴을 만들어보고 싶다. 회사 바깥으로 나가는 제품을 만들지는 않지만, 담당하는 업무의 확장성 덕분에 회사 내에 다양한 조직과 이야기를 나눌 수 있는 기회가 생겼고, 진행하는 프로젝트를 사내 컨퍼런스에서 발표할 수 있는 기회도 생겼다.
희망했던 범위를 넘어서서 새롭게 하게된 업무도 있다. 조직에 10년간 쌓인 위키를 구조화하고 정리하는 프로젝트를 제안하여 진행할 수 있었다. 이 프로젝트를 진행한 후, 규모가 더 큰 상위 조직의 문서 구조화도 진행해보자는 제안을 받아 검토 중이다.
모든 것은 내가 원하는 대로만 흘러가지 않는다. 여전히 회사에 출근하는 것이 마냥 즐겁지 않고, 마음이 불편할 때도 있다. 하지만 나는 프로페셔널이다. 마음이 불편하다는 이유만으로 내가 얻을 수 있는 기회들을, 내 커리어를 개발할 수 있는 기회를 놓칠 수는 없다. 속박에서 벗어나 자유롭게 해보고 싶은 일을 시도해볼 수 있고, 안전하게 지지해주는 이 환경에 감사하며, 앞으로의 커리어도 잘 이어나가보자. 회사에서의 직무는 여전히 서비스 기획자이지만, 나는 스스로 내가 Tech PM이라고 생각하기로 했다. 이제는 나만의 사이클을 만들어야 할 차례다. 그게 무엇이 될지 아직 나도 잘 모르겠지만!
