기획자, PM, PO 그 사이 어딘가의 여정

저는 프론트엔드 개발자입니다.

그런데 프로젝트를 진행하다 보면 어느새 PO처럼 우선순위를 잡고,
기획자처럼 화면을 그리고, PM처럼 일정을 조율하고 있더라고요.
서비스와 제품에 관련된 일이라면 직무의 경계를 가리지 않고 폭넓게 작업해온 경험이 꽤 쌓였습니다.

몇 년 전만 해도 이렇게 여러 역할을 넘나드는 일은 "이도 저도 아닌" 커리어로 여겨지곤 했습니다.
하지만 업계가 빠르게 성장하면서 개발자에게도 기획 감각과 도메인 지식이 점점 더 중요해졌고,
이제는 이런 경험이 오히려 강점이 되는 시대가 된 것 같습니다.

저 역시 이 경험들이 중요하다고 생각해 이력서에도 적었는데요.
개발자로서 참고용으로만 가볍게 넣은 이력이었는데, 생각보다 이 부분을 눈여겨봐 주시는 회사가 많았습니다.
다만 "그 경험을 뒷받침할 근거가 있느냐"는 피드백과 함께 포트폴리오나 관련 자료를 요청받는 경우가 종종 있었습니다.
그래서 이번 글에서는 제가 지금까지 해온 작업들을 한번 정리해보려 합니다.

 

기능명세서 & IA 문서

초기 멤버가 아닌 이상, 회사에 입사하면 대부분의 서비스는 이미 만들어져 있는 상태입니다.
그래서 저는 현재 서비스를 기반으로 기본적인 기능과 페이지 구조를 한눈에 파악할 수 있는,
기능명세서 겸 IA 성격의 문서를 가장 먼저 만듭니다.

저는 늘 팀 안에 이런 문서를 만드는 기존 동료가 있었거나, 규칙화된 양식이 있는 경우가 없었습니다
그래서 저는 제3자가 봐도 이해할 수 있을 정도로 직접 정리한 문서를 "기능명세서 같은 문서"라고 부르고 있습니다.

기능명세서겸 IA

위 자료는 전 직장에서 만든 문서의 일부입니다.
입사한 지 한 달도 안 됐을 때 만든 것인데요.
서비스를 빠르게 파악하는 방법으로는 기능명세서 & IA만큼 좋은 게 없는 것 같습니다.
아무래도 입사 초기라 이해가 덜 되는 플로우도 있었는데,
그런 부분은 비고란에 적어두고 나중에 한꺼번에 사수에게 물어보곤 했습니다.

다른 직장에서는 엑셀이나 노션을 전혀 쓰지 않고 컨플루언스만 사용했습니다.
그래서 그 환경에 맞춰 컨플루언스의 데이터 테이블로 기능명세 및 IA를 작성해봤는데요.
컨플루언스 자체에서 제공하는 기능이 제한적이라 보기에 편하지는 않았습니다.
개인적으로는 IA 포맷은 엑셀로 작성하는 게 가장 편하더라고요.

두 프로젝트 모두 백오피스라 B2C에 비하면 상대적으로 덜 복잡한 편이었습니다.
문서는 일단 페이지별로 모두 나열하고,
한 페이지가 많은 정보를 담고 있거나 또 다른 화면으로의 이동을 일으키는
액션, 버튼이 있다면 그것도 별도 페이지처럼 분류해 작성했습니다.

덕분에 이 문서 하나만 보면 서비스의 주요 페이지를 한눈에 파악할 수 있고,
각 페이지가 무엇을 위한 화면인지까지 알 수 있습니다.

다만 이 문서만으로는 사용자 액션과 프로세스 전체를 따라가기는 어렵더라고요.
그래서 그 부분을 보완하기 위해 함께 작성하는 것이 플로우 차트입니다.

 

플로우 차트

요즘은 좋은 플로우 차트 툴이 많은 것 같은데,
대부분의 회사가 피그마를 결제해 쓰는 경우가 많아 저는 피그마의 피그잼을 이용해 만들었습니다.

백오피스에 VOC 기능을 추가하면서 만든 메일 알림 플로우 차트입니다.
워낙 분기가 복잡해서 따로 플로우 차트로 정리했는데요.
단순 텍스트로만 적으면 트리거가 뒤엉키기 쉬운데, 이렇게 시각화해 정리하니
백엔드팀과 실시간으로 협업하기도 한결 수월했고,
사용자에게 "이런 순서로 진행됩니다"라고 설명하기도 편했습니다.

이건 플로우 차트라고 부르기엔 조금 애매한데요.
당시 사내 프로그램을 외부 개발업체에 맡겨 운영하던 상황이었습니다.
그 프로그램과 우리 서비스 사이에 데이터를 주고받아야 하는 부분이 생기면서 불편함이 커졌고,
이를 개선하기 위해 타팀 + 우리 팀 + 외주 개발팀이 함께 협업하기 시작했습니다.
이때 각 팀이 원하는 워크플로우와 실제 상황에서 가능한 방식 사이에 간극이 있어서,
제가 가능한 케이스를 모두 정리해 PPT로 만들고 의견을 조율했습니다.

이건 서비스 전체를 그린 플로우 차트입니다.
여기서 고민 포인트는 서버/DB와 관련된 부분까지 더 넣어야 하나 고민이 되더라고요.
백오피스다 보니 CRUD의 반복이고 일반적인 플로우라 따로 명시하진 않았지만,
메일 만료처럼 놓치면 안 되는 중요한 포인트는 따로 표시해 넣었습니다.

저는 정식으로 PM, PO 교육을 받고 시작한 게 아니라,
어깨너머로 보고 배우거나 개발자 시절 PM에게서 받았던 문서를 떠올리며 만든 것이라
정의나 의미가 교과서적인 것과는 조금 다를 수 있습니다.
그래도 저는 "제3자가 봐도 이해할 수 있게, 최대한 직관적으로"를 목표로 작성했습니다.

이 외에도 신규 서비스, 신규 기능, 리뉴얼 등이 있을 때는 직접 피그마로 디자인을 진행하기도 했습니다.
비개발자인 현업 고객분들은 본인이 요청한 액션이 어떤 흐름으로 진행되고
결과물이 어떻게 나올지를 단편적으로 생각하시는 경우가 많습니다.
그러다 보니 막상 개발이 끝난 뒤 "어, 이게 아닌데요?" 하는 상황이 종종 생기는데요.
저는 이런 소통 비용과 재개발 비용을 줄이기 위해 간단하게라도 디자인을 그려 고객과 미리 맞춰보곤 했습니다.

 

디자인 시안, 와이어프레임, 프로토타입 그 어딘가

이런 식으로 직접 UI/UX를 그리고 사용자 액션을 정의해보기도 했습니다.
꽤 노가다스러운 작업이긴 한데요… 요즘은 디자인 AI 툴을 쓰면 한결 수월할 것 같습니다.
어떤 필드를 써야 사용자가 입력하기 편할지,
별도의 설명 없이도 바로 사용할 수 있을 만큼 직관적인지를 고민하며 화면을 그리고, 디스크립션까지 함께 작성했습니다.

나중에는 같은 작업을 반복하는 게 번거로워서 이렇게 컴포넌트로 만들어두기도 했습니다.
백오피스 페이지는 구조가 비슷한 경우가 많아, 틀을 한 번 잡아두면 여러 곳에 재사용할 수 있겠다고 판단했거든요.
당시 데이터 테이블 라이브러리로 ag-grid를 쓰고 있어서,
ag-grid 기반 테이블 컴포넌트를 그대로 가져와 쓸 수 있다는 점도 편했습니다.
처음에 시간을 조금만 투자해두니 이후로는 그대로 가져다 쓰면 돼서 작업이 훨씬 수월해졌습니다.

 

사용자 의견 직접 수렴하기

제가 만든 건 사내 백오피스였기 때문에, 고객이 곧 사내 팀 동료들이었습니다.
그래서 리뉴얼이 필요하다고 생각되는 서비스에 대해 동료들의 의견을 직접 받아보기도 했습니다.

생각보다 정말 많은 분들이 참여해주셔서 의미 있는 자료가 되었습니다.
막연히 "이게 불편할 것 같다"고 짐작하는 대신,
실제 사용자의 목소리를 근거로 개선 방향을 잡을 수 있었다는 점이 가장 좋았습니다.

 

서비스 메뉴얼 작업 & API 명세서

직접 사용자 메뉴얼 PPT도 손수 만들었습니다.
저 자신을 위한 것이기도 했고, 사용자를 위한 것이기도 했습니다.
새로운 메뉴가 추가될 때마다, 또 새로운 사용자가 올 때마다 일일이 같은 설명을 반복하기엔 시간도 부족하고 지치더라고요. 그래서 메뉴얼을 만들어 모든 사용자가 최신 사용법을 스스로 확인할 수 있도록 했습니다.

그리고 팀의 유일한 개발자였던 만큼 API 명세서도 직접 작성해 넘겼습니다.

고객과 직접 소통하는 위치였다 보니,
요구사항을 정리하고 나면 그 내용을 문서화해 백엔드에 히스토리와 개발 맥락을 전달했습니다.
매번 모여 회의를 하기도 했지만,
제가 먼저 1차로 요구사항을 정리해두면 백엔드가 더 빠르게 파악하고 소통할 수 있었거든요.
이후에는 함께 회의하며 놓친 부분이나 엣지 케이스를 같이 채워나갔습니다.

 

마치며

돌아보면 이 모든 작업의 공통점은 "내 일이 아니다"라고 선을 긋지 않은 데서 출발했다는 점입니다.
기능명세서, 플로우 차트, 디자인 시안, 사용자 의견, 메뉴얼, API 명세서
어느 것 하나 처음부터 제 담당이었던 적은 없습니다.
다만 서비스가 더 잘 돌아가려면 누군가는 정리해야 했고, 그 빈자리가 보일 때마다 손을 들었을 뿐입니다.

프론트엔드 개발자로서 화면을 만드는 일은 여전히 제 중심에 있습니다.
하지만 그 화면이 왜 필요한지, 사용자가 어떤 흐름으로 쓰게 될지,
그 뒤에서 데이터가 어떻게 흘러가는지를 함께 고민해온 경험은
제가 한 단계 더 나은 개발자가 되는 데 큰 자산이 되었다고 생각합니다.