IT회사의 서비스 기획자 업무, 진짜 뭐하냐고요? 회사에서 내가 맡은 일들

기획자는 IT 회사에서 대체 무슨 일을 하는지, 기획자 취업을 준비하고 있는 사람들이라면 궁금한 부분일 것이다.

나 또한 처음 서비스 기획자로 이직을 준비할 때 그러했고, 수없이 검색도 해봤지만 딱히 이게 정해진 업무다! 라는건 잘 와닿지 않았다.

 

결론부터 말하자면, 정답은 없다. 회사마다 다르다.

내가 일했던 곳에서도 팀, 부서, 프로젝트에 따라 기획자의 역할은 다 달랐다.

하지만 한 가지 확실한 건, 문제를 정의하고, 해결 가능한 범위 안에서 정리해 나가는 사람이라는 점이다.

 

이 글에서는 내가 실제 회사에서 기획자로 일하면서 경험했던 업무들을 흐름에 따라 정리해보려고 한다.

다만 회사 내부 정보가 있다보니, 모든 자료를 다 공개하지는 못하기 때문에 가벼운 참고용도로만 보길 바란다.

---

📌 내가 다니던 회사는 주로 내부 고객의 요구사항에 따라 기획~개발이 진행되는 곳이었고, 디자인팀과 개발팀이 별도로 존재했다. 기획자는 개발팀 소속이었기 때문에, 다른 회사와는 업무 범위나 순서가 다를 수도 있다.

 

1. 요구사항 정의 : 내부 고객 니즈 정리

내가 담당했던 프로젝트는 대부분 내부 고객(사내 사용자)의 요구사항을 정리하는 일이었다.

이 과정에서 가장 중요한 건 내부 고객이 원하는 걸 곧장 기능으로 바꾸는 것이 아니라, 충분히 그 내용을 파악하는 것이다.

• 어떤 맥락에서 이 요청이 나왔는가?
• 실제로 어떤 불편함이 있었는가?
• 기능 요청의 목적이 정확히 무엇인가?

이 내용을 바탕으로 개발자와 논의해 요구가 어떤 식으로 구현될 수 있을지, 기술적으로 가능한지를 러프하게 검토한다.

 

나는 아래와 같이 표로 현재 이슈가 무엇인지, 우리(개발팀)가 제안할 수 있는 것은 무엇이며 내부 고객이 제안한 것은 무엇인지 러프하게 정리 후 미팅에 참여했다. 아래 표는 배포 이후 수정 사항에 대해 정리한 것이긴 하지만, 정리해나가는 방식은 비슷하여 참고차 넣어본다.

내부 고객과의 조율 사항 정리 방법 (러프하게)

 

 

2. 개발 가능 범위 판단 : 현실적인 선 그리기

모든 기능을 다 개발할 수는 없다.

그래서 우선순위를 정하고, 백로그를 관리하는 것이 중요한 업무 중 하나였다.

개발자와 함께 다음의 사항들을 논의하고, 실현 가능한 안을 정리하여 백로그를 솎아내는 것이 중요하다.

• 시간/인력 대비 실현 가능한 기능
• 기술 난이도
• 다른 팀과의 연관성

기획자가 할 일은, 개발팀이 너무 무리하지 않으면서도 사용자 니즈를 최대한 반영하는 접점을 찾는 것이다.

 

 

3. 기능 정의 : 복잡하게 쓰지 않고, 명확하게

나는 컨플루언스를 이용해 리스트 형식으로 정리했다.

• 내부 고객과 미팅에서 나온 주요 기능들
• 구현 필요성과 우선순위
• 간단한 설명 및 정책 포함 여부

위 내용들을 목록으로 정리하여, 개발자와 논의하며 빠르게 피드백받는 방식으로 진행했다.

 

 

4. 정책 정리 : 비즈니스와 개발 로직 사이 다리 놓기

이후에는 본격적으로 정책 문서를 정리했다.

• 비즈니스 정책은 내부 고객과 다시 논의
• 서버/프론트 로직은 개발자와 상세하게 조율

개발자와 조율하며 정리한 시스템 내부 로직 예시

 

특히 운영팀, 마케팅팀 등 실제로 그 기능을 사용하는 팀들의 현실적인 업무 흐름도 꼭 반영해야 했다.

단순히 '이렇게 만들면 좋겠다'가 아니라, '지금 있는 문제를 해결할 수 있는가?'가 핵심이었다.

 

 

5. 기획서 작성 : 와이어프레임 + 기획 문서

정책서를 기반으로 와이어프레임을 만들고 기획서를 작성했다.

 

우리 팀의 경우, 디자이너와 한 팀이 아니었기 때문에 디자이너에게는 와이어프레임과 주요 정책을 전달하며 기획 리뷰를 진행하여 요청하는 방식이었다.

 

개인적인 생각으로는 소규모 팀에서 디자인팀이 개발팀과 떨어져 있으면 기획자 입장에서는 조율이 매우 힘들다고 생각했다.

소통이 단절되면 디자인-개발 간 간극이 생기기 쉽고, 그 조율은 전부 기획자의 몫이 되기도 했다.

 

개인적으로는 디자이너가 개발자, 기획자와 같은 팀에 있는 회사가 더 효율적이라고 느꼈다. 물론 프로젝트 성향에 따라 사람바이사람이겠지만, 빠른 소통이 필요한 스타트업에서는 같은 팀에 있는 게 더 효율적이라고 느꼈다. 분명한 건, 서로가 만족할 수 있는 결과물 퀄리티에도 확실히 영향을 준다는 것.

 

 

6. 기획 리뷰 : 개발자 + QA와 함께 체크

기획서를 정리한 뒤에는 개발팀과 QA와 함께 기획 리뷰를 진행했다.

• 정책 누락이 없는지
• 비정상적인 흐름은 없는지
• QA 입장에서 테스트가 가능한 상태인지, 기간은 어느 정도인지 등

QA와 대략적인 진행상황 및 개발 사항들을 체크하고, 필요한 부분은 추가 논의를 진행했다.

 

 

7. 개발 진행 이후에는?

개발이 시작되면 기획자는 디자인-개발-운영팀 사이에서 계속 움직이게 된다.

• 추가 개발 이슈 대응
• 디자인 수정 커뮤니케이션
• 운영팀 테스트 지원 및 개발사항 안내
• QA 기간 이슈 대응 및 릴리즈 전 최종 점검

어떻게 보면 초반엔 정보 수집자, 중간엔 의사 결정자, 끝엔 조율자 역할을 하는 셈이다.

 

 

9. 마무리 : 기획자는 '사이'를 정리하는 사람

기획자는 하나의 답을 가지고 움직이는 사람은 아니라고 생각한다.

요구와 기술 사이, 비즈니스와 UX사이, 팀과 팀 사이에서 계속 질문하고, 정리하고, 설득하고, 조율하는 사람이다.

 

회사마다, 팀마다, 프로젝트마다 기획자가 하는 일은 달라질 수 있다.

하지만 내게 있어 기획자의 업무는 논리와 현실을 연결하는 조율자 역할을 하는 것이었다.

 

앞으로 기획자가 되고 싶거나, 기획자의 일에 관심 있는 사람들에게 이 글이 조금이라도 현실적인 도움이 되었으면 한다.

 

IT회사의 서비스 기획자 업무, 진짜 뭐하냐고요? 회사에서 내가 맡은 일들