개발자도 아니고 디자이너도 아닌, 그 중간에서 일하는 사람
저는 보안 회사에서 신사업 기획을 담당하고 있는 5년 차 서비스 기획자이자 PM입니다.
처음 이 일을 시작했을 때는 정말 막막했습니다. 사수도 없었고, 회사 안에서도 기획자로 일하는 사람이 저 혼자뿐이었거든요. 지금 내가 하고 있는 게 맞는건가?, 내가 기획하는 프로세스가 제대로 된 방법일까? 같은 의문들이 머릿속을 가득 채웠습니다. 당시는 코로나 시국이라 오프라인 모임도 거의 불가능했고, 지금처럼 GPT 같은 도움 받을 툴도 없었습니다. 제가 할 수 있는 건 책을 뒤적이거나, 온라인에 흩어져 있는 선배 기획자들의 글과 강의에 의지하는 것뿐이었습니다.
아마 지금 막 서비스 기획자나 PM/PO가 되려는 분들도 저와 비슷한 고민을 하고 있을 겁니다. 기획자는 도대체 무슨 일을 하는 사람이지? 내가 하고 있는 게 맞는 걸까? 이 질문들에 답을 찾는 과정은 누구에게나 쉽지 않습니다. 그래서 저는 이 서비스 기획 챌린지를 준비했습니다. 기획을 막 시작하는 분들에게 작은 나침반이 될 수 있으면 좋겠습니다.
기획자는 어떤 일을 하나요?
기획자가 하는 일을 누군가에게 딱 한 줄로 설명하기란 쉽지 않습니다. 서비스 기획자, PM, PO… 부르는 이름도 다양하죠. 그런데 이 차이를 만드는 중요한 요인 중 하나가 바로 조직 구조라고 생각합니다.
기능조직
- 개발팀, 디자인팀, 기획팀처럼 전문 기능별로 조직이 나눠져 있음
- 기획자는 보통 화면을 설계하고, 요구사항을 정의하는 사람으로 역할이 좁혀지는 경우가 많음
목적 조직
- 특정 서비스나 제품 단위로 팀이 조직되어 기획자, 디자이너, 개발자가 한 팀으로 구성됨
- 기획자는 서비스의 문제 정의부터 로드맵, 전략, 운영까지 폭넓은 역할을 맡음
즉, 회사가 기능 중심으로 조직되어 있느냐, 목적 중심으로 조직되어 있느냐에 따라 기획자의 일도 크게 달라집니다. 그래서 어떤 사람은 기획자가 문서만 쓰는 사람이라고 말하고, 또 어떤 사람은 제품 오너처럼 의사결정을 한다고 말하는 거죠.
하지만 이런 차이는 결국 겉으로 드러나는 역할의 범위일 뿐, 기획자의 본질적인 임무는 크게 다르지 않습니다. 결국 기획자는 문제를 정의하고, 해결책을 제안하며, 팀이 하나의 목표로 움직이도록 만드는 사람입니다.
프론트 기획 vs 백엔드 기획
여기서 한 가지 더 짚고 넘어갈 게 있습니다. 개발자가 프론트엔드와 백엔드로 나뉘는 것처럼, 기획자도 조금 디테일하게 본다면 프론트엔드 기획과 백엔드 기획으로 영역이 나뉩니다.
프론트 기획
- 사용자가 직접 눈으로 보는 화면(UI)과 경험(UX)을 설계
- 사용자 시나리오 정의 (회원가입, 결제, 검색 등 단계별 경험)
- 인터랙션 설계 (버튼 클릭 → 다음 화면, 알림 동작 등)
- ...
백엔드 기획
- 화면 뒤에서 돌아가는 로직과 데이터 구조 정의 (DB 테이블 설계, 데이터 흐름)
- 비즈니스 로직 기획 (결제 승인, 재고 관리, 추천 알고리즘 등)
- API 기획 (프론트 화면이 서버와 어떻게 데이터를 주고받을지)
- ...
쉽게 말하면, 프론트 기획은 사용자가 보는 것을 다루고, 백엔드 기획은 사용자가 보지 못하는 것을 다룬다고 할 수 있습니다.
프론트 기획은 화면이 눈앞에 보이기 때문에 상대적으로 직관적으로 이해할 수 있습니다. “이 버튼을 누르면 어디로 이동해야 할까?”, “이 화면 뒤에는 어떤 정보가 보여야 할까?”와 같이 누구나 상상할 수 있는 문제이죠. 그래서 기획을 처음 배우는 분들이 가장 먼저 접하는 분야이기도 합니다.
반대로 백엔드 기획은 눈에 보이지 않는 곳에서 서비스가 정상적으로 돌아가게 만드는 원리를 설계합니다. 화면에서는 단순한 버튼 하나처럼 보이지만, 그 뒤에서는 수많은 데이터와 로직이 맞물려야만 동작합니다. 결제 승인, 재고 차감, 추천 알고리즘 같은 것들이 모두 이 영역에 해당합니다. 그렇기 때문에 백엔드 기획은 훨씬 더 복잡하고 추상적으로 느껴질 수 있습니다.
저 역시 처음에는 프론트 기획부터 시작했습니다. 피그마로 와이어프레임을 그리고, 화면의 흐름을 정의하면서 기획자로서의 첫 경험을 쌓았죠. 그런데 이 일을 계속하다 보니 화면 설계만으로는 해결되지 않는 문제가 많았습니다. 화면 뒤에서 어떤 데이터가 오가고, 어떤 로직으로 서비스가 작동하는지 이해해야만 더 나은 기획을 할 수 있었던 겁니다.
다행히 저는 산업공학을 전공했는데, 이 학문은 통계와 데이터 기반 접근을 많이 다룹니다. 자연스럽게 데이터 분석, DB 구조, 개발에 대한 전공 과목을 들을 수 있었고, 덕분에 백엔드 기획 영역도 조금씩 시작해볼 수 있었습니다. 개발자와 이야기할 때도 단순히 “이 기능 넣어주세요”가 아니라, “이 데이터는 이렇게 저장하고 불러오는 게 더 낫지 않을까요?”처럼 구체적으로 대화할 수 있었죠.
기획자가 회사에서 맡을 수 있는 일
기획자는 서비스를 어떻게 만들고, 어떻게 운영할지 고민하는 사람입니다. 그런데 그 과정은 단순히 화면을 그리는 일에만 머무르지 않습니다.
1. 문제 정의 & 정책 수립
- 플랫폼/서비스 문제 발굴과 정의
- 요구사항 분석 및 정의
- 서비스 정책 수립 및 정책서 작성
2. 서비스 설계
- 서비스 플로우 설계 (Flow Chart)
- 와이어프레임 설계 (Lo-Fi / Hi-Fi)
- 사용자 화면 설계, 관리자(백오피스) 화면 설계
- 권한 관리, 데이터 처리, 운영 규칙 같은 정책 요소까지 포함
3. 품질 검증
- 테스트 시나리오 작성
- 실제 테스트 진행
4. 협업 & 프로젝트 관리
- 내부 부서 의견 및 이슈 조율
- 외부 고객사·파트너와의 커뮤니케이션
- 프로젝트 일정 및 진행 관리
5. 데이터 분석
- 서비스 지표 분석 (MAU, 유입, 이탈, 이동경로 등)
6. 문서 작성
- 기획서, 보고서 작성 (내부 공유용)
- 제안서 작성 (정부 과제·외부 프로젝트용)
결국 기획자는 문제 정의 → 설계 → 검증 → 협업 → 데이터 → 문서화까지, 서비스가 만들어지고 운영되는 전 과정을 폭넓게 다루게 됩니다. 다만 회사와 프로젝트 성격에 따라 어떤 곳은 설계 중심, 어떤 곳은 데이터 분석 중심, 또 어떤 곳은 정책·문서 중심으로 역할이 달라지기도 합니다.
1. 설계 중심 기획
- 스타트업이나 신사업 초기 단계에서 자주 나타납니다. 아이디어를 빠르게 구체화해 시장 반응을 확인해야 하기 때문에, 화면 플로우와 와이어프레임을 만드는 데 대부분의 시간을 씁니다. 뿐만 아니라 권한, 정책, 데이터 흐름까지 함께 설계해야 합니다.
- 예를 들어 회원가입 → 결제 → 주문 플로우를 설계하고, 디자이너·개발자와 직접 맞붙어 빠르게 MVP를 만들어냅니다. 이때 회원 유형에 따라 접근 권한은 어떻게 달라지는지, 결제 정보는 어떤 규칙으로 저장되고 불러와야하는지, 운영자가 이를 관리하려면 백오피스 화면은 어떻게 구성할지까지 함께 설계해야 합니다.
2. 데이터 분석 중심 기획
- 이미 서비스가 운영되고 있는 회사에서 많이 요구됩니다. 신규 기능보다 지금 있는 서비스가 얼마나 잘 쓰이고 있는가가 더 중요한 시기이죠. 기획자는 GA, Amplitude, SQL 등을 활용해 이용자 행동 데이터를 분석하고, 개선안을 제시합니다.
- 만약 이커머스 플랫폼에서 장바구니 이탈률이 높다면, 데이터를 근거로 결제 단계 UX 개선이나 할인 정책 조정 같은 내용을 제안합니다.
3. 정책·문서 중심 기획
- 규제가 많은 산업(금융, 보안, 공공 등)이나 대기업에서 자주 나타납니다. 단순히 화면을 설계하는 것을 넘어, 서비스가 지켜야 할 정책과 원칙을 정리하고, 이를 문서화해야 합니다. 이렇게 정의한 정책은 화면·기능 설계에 직접 반영되며, 동시에 문서로 남겨 조직 전체가 같은 기준을 따르도록 합니다.
- 경우에 따라서는 정부 과제 제안서나 외부 RFP 제안서처럼 회사의 전략과 역량을 대외적으로 보여주는 문서까지 기획자가 작성하게 됩니다.
결국 기획자는 한 가지 모습으로 고정되지 않습니다. 회사의 상황과 프로젝트의 단계에 따라 설계자, 분석가, 혹은 정책 관리자로 다양한 얼굴을 가질 수 있습니다.
기획이라는 일에는 정해진 루트가 없습니다. 전공이 꼭 IT 전공일 필요도 없고, 저처럼 산업공학전공이 기획자가 되기도 하고, 개발하다가 기획을 시작하기도 하고, 심지어 디자이너 출신 기획자도 많습니다.
또 기획에는 하나로 정해진 프로세스도 없습니다. 어떤 회사는 문서 위주의 기획을 하고, 어떤 회사는 아예 문서 없이 피그마 같은 툴로 바로 협업하기도 합니다. 어떤 팀은 스펙을 세세하게 정의하고, 어떤 팀은 만들면서 조율하는 방식을 택하기도 합니다.
그래서 기획자로 성장하는 데 가장 중요한 건 내가 가진 강점을 어떻게 살려내느냐라고 생각합니다. 데이터 분석을 잘하면 데이터 기반 기획자가 될 수 있고, 디자인 감각이 있으면 UX 기획자로 두각을 드러낼 수도 있고, 개발 이해도가 높다면 기술 친화적인 기획자로 자리 잡을 수 있습니다.
기획에 정답은 없지만 분명한 건, 각자의 강점이 쌓일수록 나만의 색깔을 가진 기획자로 성장한다는 점입니다. 중요한 건 어떤 문제를 풀고 싶은지, 내가 가진 강점을 어떻게 활용할지를 고민하는 것입니다.
이번에는 기획자가 맡을 수 있는 다양한 역할을 살펴봤습니다. 다음 글에서는 이 역할들 중에서도 기획의 출발점이라 할 수 있는 문제를 정의하는 일을 다뤄보겠습니다. 좋은 기획은 결국 좋은 문제 정의에서 시작되니까요.