서비스기획자란 무엇인가? 역할과 책임 완벽 정리 [기획자 입문]

 

📷 Photo by Austin Distel on Unsplash

저는 처음 '서비스기획자'라는 직함을 들었을 때, 솔직히 말해서 "기획서를 잘 쓰는 사람?" 정도로만 생각했습니다. 그런데 막상 공부를 시작하고 실무를 들여다보니, 서비스기획자의 역할은 제가 생각했던 것보다 훨씬 넓고 복잡했습니다. PM이나 기획자를 준비하는 분들이라면 누구나 한 번쯤 "기획자가 도대체 뭘 하는 사람인가?"라는 질문을 하게 됩니다. 이 글에서는 그 질문에 대한 명확한 답을 드리겠습니다.

이 글은 서비스기획자의 역할과 책임을 처음 배우는 분, 기획자나 PM으로 커리어를 시작하려는 분, 그리고 현업에서 기획자와 협업하는 개발자·디자이너분들을 위해 작성했습니다.

---

1. 서비스기획자에 대한 흔한 오해 — "기획서 잘 쓰는 사람이 아닌가요?"

서비스기획자라고 하면 많은 분들이 이런 이미지를 떠올립니다.

• 기획서를 잘 쓰는 사람
• 화면(UI)을 설계하는 사람
• 아이디어를 많이 내는 사람

하지만 이것은 서비스기획자가 하는 일의 일부일 뿐입니다. 저도 처음에는 이런 오해를 갖고 있었는데, 공부를 하면서 이 오해가 얼마나 근본적인 것인지 깨달았습니다.

아래 표를 보면 오해와 실제 역할의 차이를 한눈에 볼 수 있습니다.

흔한 오해	실제 역할
기획서를 잘 쓰는 사람	문제를 정의하는 사람
디자이너에게 화면을 지시하는 사람	팀이 같은 방향을 보게 만드는 사람
아이디어를 내는 사람	아이디어 중 무엇을 하지 않을지 결정하는 사람
모든 것을 결정하는 사람	판단 기준을 세우고 조율하는 사람

특히 마지막 행이 중요합니다. 서비스기획자는 "무엇을 만들까?"만 고민하지 않습니다. 오히려 "무엇을 만들지 않을까?"를 결정하는 일이 매우 중요합니다. 리소스는 항상 유한하기 때문입니다.

핵심 문장: "서비스기획자는 만드는 사람이 아니라, 무엇을 왜 만들지를 결정하는 사람이다."

---

2. 서비스기획자의 정의 — 사용자와 비즈니스를 연결하는 다리

서비스기획자를 한 문장으로 정의하면 다음과 같습니다.

사용자의 문제와 비즈니스의 목표를 연결하는 지점에서, 무엇을 · 왜 · 어떤 순서로 만들 것인가를 결정하고 조율하는 사람

이 정의를 쉽게 비유하면, 서비스기획자는 건물의 설계사와 같습니다. 건물을 실제로 짓는 사람(개발자, 디자이너)이 따로 있고, 건물주의 요구(비즈니스 목표)와 실제 거주자의 필요(사용자 문제)를 파악해서 "이런 건물을 이런 구조로 만들어야 한다"고 설계도를 그리는 사람이 바로 기획자입니다.

① 사용자의 문제

사용자가 불편해하거나 원하는 것을 말합니다. 예를 들어 사용자가 "결제가 불편해요"라고 말한다면, 기획자는 그 말을 그대로 받아들이기보다 왜 불편한지를 먼저 파고들어야 합니다. 표면적인 말 뒤에 숨은 진짜 문제를 찾는 것이 기획자의 출발점입니다.

② 비즈니스의 목표

회사가 달성해야 하는 목표입니다. 예를 들면 매출 증가, 가입자 수 증가, 재방문율 증가, 결제 완료율 증가, 이탈률 감소 등이 있습니다. 서비스기획자는 항상 이 목표를 염두에 두고 기능의 우선순위를 결정합니다.

③ 연결하는 지점

사용자가 원하는 것과 회사가 원하는 것이 항상 같지는 않습니다. 기획자는 이 둘 사이에서 무엇이 더 중요한지 판단하고 현실적인 방향을 찾아야 합니다. 이것이 기획자의 가장 핵심적인 역량입니다.

---

3. 서비스기획자의 3가지 핵심 역할

저는 서비스기획자의 역할을 처음 배울 때, "이렇게 많은 역할을 다 해야 해?" 하고 당황했던 기억이 있습니다. 하지만 결국 세 가지 키워드로 정리할 수 있습니다.

서비스기획자
│
├── ① 문제 정의자 (Problem Definer)
├── ② 의사결정 조율자 (Decision Facilitator)
└── ③ 요구사항 번역자 (Requirement Translator)

① 문제 정의자 (Problem Definer)

서비스기획자는 사용자가 말한 불편함을 그대로 해결하려 하지 않습니다. 먼저 그 불편함의 진짜 원인을 찾습니다.

예시: 사용자가 "결제가 불편해요"라고 말했을 때 바로 "결제 화면을 바꾸자"라고 결정하면 안 됩니다. 다음과 같은 다양한 원인이 있을 수 있기 때문입니다.

• 결제 단계가 너무 많다
• 배송비가 마지막에 갑자기 보인다
• 가격이 믿기지 않는다
• 결제 수단이 부족하다
• 회원가입을 해야만 결제할 수 있다

같은 "결제가 불편하다"는 말이라도 원인에 따라 해결책은 완전히 달라집니다. 문제를 잘못 정의하면, 아무리 열심히 만들어도 잘못된 결과가 나올 수 있습니다.

② 의사결정 조율자 (Decision Facilitator)

서비스를 만들 때는 여러 직무의 의견이 충돌합니다.

• 디자이너는 더 보기 좋은 화면을 만들고 싶다
• 개발자는 더 빠르게 구현하고 싶다
• 마케터는 더 많은 노출을 원한다
• 경영진은 더 높은 매출을 원한다

이때 기획자는 누가 맞고 틀린지 심판하는 사람이 아닙니다. 판단 기준을 세우는 사람입니다. 예를 들어 "이번 개선의 가장 중요한 기준은 사용자 이탈을 줄이는 것이다"라고 기준을 명확히 하면, 각 팀의 의사결정이 훨씬 쉬워집니다.

기획자가 사용하는 주요 도구로는 우선순위 매트릭스, OKR, 사용자 스토리 맵, 사용자 여정 지도, 요구사항 정의서 등이 있습니다. (참고: Nielsen Norman Group - UX 성숙도 모델)

③ 요구사항 번역자 (Requirement Translator)

기획자는 서로 다른 사람들의 말을 이해하고, 실행 가능한 형태로 바꾸는 역할을 합니다.

예시: 경영진이 "우리 앱이 좀 불편한 것 같은데 고쳐봅시다"라고 말했을 때, 개발자는 "구체적으로 어떤 기능을 어떻게 고쳐야 하나요?"라고 묻습니다. 이 간극을 메우는 것이 기획자의 역할입니다.

번역 단계	예시
1단계: 모호한 의도 파악	"앱이 불편하다"
2단계: 명확한 목표로 바꾸기	"회원가입 완료율을 높인다"
3단계: 기능 요구사항 정리	"회원가입 입력 항목을 줄인다"
4단계: 개발 가능한 스펙 정의	"이름, 이메일, 비밀번호만 입력하면 가입 가능하게 한다"

---

4. 서비스기획자의 책임 3단계 — 레벨 1에서 멈추지 말 것

저는 기획자의 책임을 공부하면서 가장 크게 반성했던 부분이 있습니다. 많은 초보 기획자들이(저도 포함해서) 레벨 1에서 멈추는 경향이 있습니다.

책임 레벨	내용	핵심 질문
레벨 1. 산출물 책임	기획서, 와이어프레임, 요구사항 정의서 작성	문서가 명확한가?
레벨 2. 과정 책임	팀 커뮤니케이션, 방향 정렬	팀이 같은 이해를 갖고 일하는가?
레벨 3. 결과 책임	출시 후 데이터 분석, 문제 해결 여부 확인	서비스가 실제로 문제를 해결했는가?

"기획서를 냈으니 내 일은 끝났다"는 생각은 레벨 1에서 멈추는 것입니다. 좋은 기획자는 결과까지 책임집니다. "이 기능이 실제로 사용자의 문제를 해결했는가?"라는 질문을 서비스가 출시된 후에도 계속해야 합니다.

이 개념은 한국인터넷진흥원(KISA)의 서비스 운영 가이드라인에서도 강조하는 사용자 중심 설계(UCD, User Centered Design) 원칙과 일맥상통합니다.

---

5. 서비스기획자가 하는 일 vs 하지 않는 일

기획자를 준비하는 분들이 자주 혼동하는 부분이 있습니다. "기획자가 모든 것을 결정하는 것 아닌가?" 하는 오해입니다. 각 직무에는 고유한 전문 영역이 있습니다.

기획자의 역할이 아닌 것	기획자의 역할인 것 ✅
UI 색상과 폰트를 최종 결정하는 일	팀이 같은 목표를 보고 있는지 확인하기
기술 구현 방식을 직접 결정하는 일	사용자 문제와 비즈니스 목표 연결 여부 판단
마케팅 채널을 직접 결정하는 일	우선순위를 정하고 조율하기
혼자 모든 것을 결정하는 일	요구사항을 명확하게 정리하기

기획자는 모든 일을 대신하는 사람이 아닙니다. 각 팀이 같은 방향으로 움직일 수 있도록 돕는 사람입니다. 이 개념을 이해하면, 기획자가 "왜 코딩을 못해도 되는지", "왜 디자인을 직접 하지 않아도 되는지"가 명확해집니다.

---

6. 실제 회사에서 서비스기획자의 하루 — 상상과 현실의 차이

기획자가 하루 종일 기획서만 쓸 것 같다는 생각, 저도 처음에는 그랬습니다. 실제로는 어떨까요?

시간	업무	핵심 역할
오전 9시	어제 배포된 기능의 데이터 확인	결과 책임
오전 10시	개발팀 회의에서 이슈 공유	의사결정 조율
오전 11시	디자이너와 사용자 흐름 검토	요구사항 번역
오후 2시	경영진과 다음 기능 방향 논의	문제 정의 + 번역
오후 4시	다음 스프린트 요구사항 정리	산출물 책임
오후 6시	고객 인터뷰 영상 확인	문제 정의

기획서를 쓰는 일은 중요하지만, 그것은 전체 업무의 일부입니다. 기획자는 하루 동안 여러 사람과 소통하고, 데이터를 확인하고, 방향을 조율합니다. 오히려 커뮤니케이션 역량이 기획서 작성 능력보다 더 중요할 때가 많습니다.

---

7. 기획자를 꿈꾸는 분들을 위한 마무리 조언

저는 이 내용을 공부하면서 "기획자는 권한은 작지만 영향력은 크다"는 말이 정말 와닿았습니다. 팀에서 기획자의 직급이 낮아도, 좋은 기획자 한 명이 팀 전체의 방향을 바꿀 수 있습니다.

기획자를 준비하면서 반드시 기억해야 할 3가지 문장이 있습니다.

1. 기획자는 무엇을 만들지, 왜 만들지를 결정한다.
2. 문제를 틀리게 정의하면, 완벽한 실행도 실패다.
3. 기획자의 권한은 작지만, 영향력은 크다.

이 글과 함께 아래 블로그 내의 관련 글들도 함께 읽으시면 기획자로서의 역량을 더 넓게 키울 수 있습니다.

• 📚 코스피 6,000선 돌파, 지금 무슨 일이 벌어지고 있나 — 데이터 기반 의사결정 사례
• 📚 개념 정리 - SQLD 1과목: 데이터 모델링의 이해 — 기획자가 알아야 할 데이터 기초
• 📚 SQLD 2과목 요약: SQL 기본과 활용 — 기획자가 SQL을 알아야 하는 이유

---

📌 이 글의 핵심 요약
서비스기획자는 사용자의 문제와 비즈니스 목표를 연결하는 사람입니다.
역할: ① 문제 정의자 → ② 의사결정 조율자 → ③ 요구사항 번역자
책임: 레벨 1(산출물) → 레벨 2(과정) → 레벨 3(결과)
기획자는 만드는 사람이 아니라, 무엇을 왜 만들지를 결정하는 사람입니다.