IT 서비스는 도대체 어떻게 만들어지는 걸까?
기획자는 어디까지 책임져야 할까?
‘기획자? 아이디어 내고 PPT에 예쁘게 정리해서
개발 요청하면 되는 거 아니에요?‘
라고 생각했죠.
아마 많은 사람들이 저랑 비슷하게 생각할 것 같아요.
하지만 아이디어를 실제 구현하는 프로세스를 한 바퀴 경험하고 난 뒤 기획자는 그저 ‘생각을 정리해 표현하는 사람’이 아니라는 걸 깨달았습니다.
아이디어가 실제 구현되는 과정,
진짜 현실 버전
서비스 하나가 만들어지는 과정은 생각보다 길고 복잡합니다. 겉으로는 웹 혹은 앱 하나지만, 안에는 수많은 단계와 사람이 얽혀 있어요.
그 흐름을 아주 간단하게 정리하면 이렇게 됩니다.
1. 아이디어
“이런 기능 있으면 좋겠다!”
“서비스가 불편한데 바꾸고 싶다.”
이 단계는 누구나 할 수 있죠.
하지만, 이걸 진짜 ‘만들 수 있는 무언가’로 바꿀 수 있는 건 기획자의 몫이었습니다.
2. 기획
여기부터 기획자의 진짜 일이 시작됩니다.
어떤 기능이 들어가야 하지?
사용자 경험은 어떻게 되지?
이건 버튼으로? 드래그로?
기술적으로 구현 가능한가?
말 그대로 아이디어를 ‘실행 가능한 형태’로 번역하는 단계예요. 그래서 기획자가 개발 지식이 없으면 엉뚱한 그림만 그리게 되고, 개발자는 “이걸 어떻게 만들라는 거죠…?”라고 철벽방어가 시작되는 거죠.
3. 디자인
기획서를 바탕으로 디자이너가 실제 인터페이스(UI)를 만듭니다.(단순 기능 개선 기획의 경우 디자이너 없이 개발되는 경우도 많지만요.)
사용자가 어떤 화면을 보고
어디를 클릭하고
어떤 색감과 느낌을 받게 할지
기획자는 여기서도 빠질 수 없어요.
왜냐면, 디자인이 기획과 다르게 나오면 그건 또 다른 참사니까요. (이건 이 위치가 아닌데요 같은 일, 정말 자주 생깁니다.)
4. 개발
개발자들이 디자이너가 만든 시안을 바탕으로 실제로 기능을 구현합니다.
여기서부터 나오는 말들이 바로 프론트엔드, 백엔드, API, DB, 서버…(무서운 용어 군단 등장)
이때 기획자가 이 기능은 어떻게 연동되고, 어떤 데이터를 써야 하는지를 제대로 전달하지 않으면, 개발자 입장에서 명확한 방향이 없습니다.
그래서 이 단계에서도 기획자는 계속 질문받고 설명해야 해요.
“이 버튼 누르면 어디로 가는 건가요?”
“이 데이터는 어디서 가져오죠?”
기획자는 이쯤 되면 약간 챗GPT(120 다산콜센터 예시 들고 싶은데 요즘 분들은 모를 것 같아서..) 같은 존재가 됩니다. 끊임없이 답해야 하니까요.
5. QA (Quality Assurance, 품질 테스트)
기획 의도대로 잘 작동하는지 테스트하는 단계입니다.
버튼이 눌러지긴 하나
로그인은 제대로 되는가
예상치 못한 에러는 없는가
기획자는 여기서도 원래 의도를 기준으로 계속 확인합니다.
예를 들면, 이런 대화요.
“여기 버튼이 눌렀을 때 이 페이지가 맞나요?”
“아? 원래는 모바일 페이지로 넘어가야 합니다.”
원래 의도한 바와 에러의 차이를 잡아내는 역할도 기획자 몫이에요.
6. 배포
테스트를 마치면 드디어 실제로 세상에 서비스가 공개됩니다. 그런데, 이 과정에서도 기획자는 가만히 있지 못합니다.
배포 후 오류 점검
사용자 반응 체크
기획자는 마지막까지 “이게 잘 작동하는가?”를 살펴야 해요.
기획자는 끝까지 책임을 안고 있는 직군이에요. 심지어 사용자 반응이 안 좋으면 제일 먼저 호출되는 사람도 기획자죠.
그래서, 기획자는 어디까지 책임지는가?
짧게 말하면: 처음부터 끝까지.
- 아이디어를 구조화하는 사람도,
- 사용자 흐름을 설계하는 사람도,
- 디자이너와 개발자 사이에서 의견을 조율하는 사람도,
- 마지막까지 품질을 확인하고
사용자 반응을 체크하는 사람도,
전부 기획자의 몫이에요.
이걸 몰랐던 나의 과거를 떠올리며…
처음엔 진짜 이렇게 복잡한 줄 몰랐어요.
아이디어 기반 기획서를 한 장 잘 쓰면 끝이라고 생각했어요.
하지만 IT 서비스는 절대 혼자서는 만들 수 없는 팀 스포츠고, 그 중심에서 모두를 이해하고 연결하는 역할이 바로 기획자라는 걸, 부딪히고 깨지면서 배웠습니다.
