대기업 IT 서비스 기획자는 어떤 일을 하나요?
AI서비스기획자가 알려주는 IT 서비스 기획 실무
이 글은 '20년 3월에 작성된 글입니다. 기존에 사용하던 블로그에서 가지고 왔습니다. :)
저는 2019년 AI서비스기획 직군으로 입사한 2년 차 직장인입니다. 실무 경험에 비추어 대기업에서 IT 서비스 기획자가 하는 일을 알려 드리겠습니다.
이 글은 IT 서비스 기획 직무 입사를 준비하시는 분들께 도움이 되는 글입니다. 또, IT 서비스 기획자가 되고 싶지만 실제로 어떤 일을 하는지는 정확하게 모르는 분께도 도움이 될 것입니다. IT 서비스 기획자로 취업을 준비하시는 분이라면 아래 글을 참고해주세요.
입사 전에 할 것이라고 생각했던 업무와 실제로 경험한 업무가 다른 점을 정리했습니다. 생각과 가장 달랐던 것은 서비스 기획자가 "서비스 출시 전부터, 출시 후까지" 모든 것을 관리해야 한다는 점입니다. 어떻게 보면 당연한 말일 수도 있지만 공부할 때와 직접 경험할 때의 느낌은 많이 다르더군요.
저는 대학원에서 IT 서비스 기획 관련 공부를 했습니다. HCI 관련 (Human Computer Interaction) 대학원에서 서비스 기획에 대해 배울 때는 신규 서비스에 대한 아이디어를 내고 이를 뒷받침할 수 있는 가설을 만들었습니다. 가설에 대한 근거를 마련하기 위해 실험을 진행했습니다. 따라서 그 당시엔 신규 서비스 기획에 대해서만 신경 쓰면 되었습니다.
그런데, 실무에서는 실제 서비스 중인 모든 서비스를 출시 전부터 후까지 모두 관리해야 합니다. 만약 서비스를 출시한 이후에 오류가 생겼다면 그 원인을 파악해서 수정하는 것만 해도 매우 많은 노력과 시간이 소요됩니다. 그리고 오류를 수정하는 작업이 신규 서비스를 출시하는 것보다 중요하기도 합니다.
경험했던 바를 기반으로 서비스 기획 실무에 어떤 업무가 있으며, 서비스 기획자에게 필요한 역량과 어려운 점까지 알려드리겠습니다.
목차
"IT 서비스 기획자는 어떤 일을 하나요?"
1. 서비스 기획
2. 기술/개발 기획
3. 운영 기획
4. 통계 기반 기획
IT 서비스 기획자는 어떤 일을 하나요?
1. 서비스 기획
서비스 기획자는 서비스 개발 전부터 후까지 자신이 담당한 서비스를 관리해야 합니다
미국에서는 서비스 기획자를 "PM, Project Manager"라고 부르는 만큼, 서비스 기획자는 자신이 관리하는 프로젝트 전반을 담당하는 사람이라고 할 수 있습니다.
서비스 기획자는 회사 사업 전략을 이해하고, 사업 목표를 이루기 위한 연도 별 로드맵을 그립니다. 그리고 개발자, 디자이너와 논의하여 기획안을 개발 가능하게 세부 조정합니다. 서비스가 출시되면 오류가 있는지 검수하고 로그를 분석하여 개선 기획안을 만듭니다. 기획자는 개발, 디자인, 운영 등 다양한 카운터파트와 함께 일해야 하므로 다른 부서가 하는 일에 대한 이해가 필요합니다.
1.1 신규 서비스를 기획합니다.
✔️연도 별 로드맵을 수립합니다.
- 팀원들과 아이디에이션을 통해 고객에게 필요하고, 실현 가능한 아이디어를 정리합니다.
- 각 서비스 별로 출시할 시기, 서비스 특성과 가치를 정의합니다.
✔️서비스 관련 카운터파트와 사전 협의합니다.
- 서비스가 구현 가능한지 개발 측과 협의하거나, 사업 상의 이슈는 없는지 사전 확인합니다.
- 이슈가 있을 경우 이를 해결할 수 있도록 서비스 기획안을 수정합니다.
✔️예산을 땁니다. 그리고 관리합니다.
- "올해 우리 회사에 이러이러하게 좋은 서비스를 출시하려고 하는데, 이걸 하려면 이만큼 돈이 필요합니다."라고 기획서를 제출합니다.
- 따온 예산을 개발, 디자인, 운영 협력사가 있을 경우 프로젝트 별로 할당하여 관리합니다.
- 협력사/업체와 계약, 예산 조정, 월 별 혹은 프로젝트 별 비용을 지급합니다.
대기업에서는 협력사/업체를 많이 씁니다. (물론 기업마다 다릅니다.) 그들에게 지급할 비용을 관리하고 커뮤니케이션하는 것만 해도 하루가 다 가는 MAGIC을 경험할 수 있습니다.
돈을 기획자가 직접 지급하는 것은 아닙니다. 지급을 위한 서류를 작성하고 결재받는 과정을 여러 번 거쳐야 합니다. 아무리 컴퓨터로 한다고 해도 과정이 복잡하고 비효율적으로 진행됩니다.
✔️서비스를 출시합니다.
- 협력사/업체와 신나게 커뮤니케이션을 합니다.
- 기획서를 주면 업체에서 결과물을 가져옵니다. 피드백을 주고 수정하여 가져오면 또 피드백을 줍니다.
- 출시 데드라인에 맞춰서 적절한 수준에 다다를 때까지 반복합니다.
협력사가 디자인/개발한 경우 더 꼼꼼하게 확인해야 합니다. 내가 의도한 바를 상대가 한 번에, 그리고 정확하게 이해하는 것을 어려운 일입니다. 기획했던 바와 다른 결과물을 보게 될 것입니다.
이 과정을 너무 많이 반복한다면, 기획자가 기획서를 꼼꼼하게 작성하지 않은 것이 문제일 수도 있고, 업체에서 제대로 읽지 않은 것이 문제일 수도 있습니다.
협력사에 들어가는 돈과 시간으로 인해 요즘 대기업들이 협력사를 안 쓰고 회사 내부 인력으로 서비스를 출시하려고 노력하고 있습니다. 신입 채용의 기회라고 할 수 있습니다.
1.2 기존 서비스를 고도화합니다.
✔️기존 서비스에서 개선이 필요한 기능을 수정합니다.
✔️실제로 출시한 서비스에서 부자연스러운 부분이 발견되면 이를 보완할 수 있는 추가 기획을 진행합니다.
✔️혹은 서비스 사용해 보고, 보다 좋게 만들 수 있는 아이디어가 떠오르면 이를 적용합니다.
✔️IT 서비스 기획자의 경우, 주요 기능 접근성 향상을 위한 UI 시나리오 및 디자인 수정이 이에 해당합니다.
1.3 출시한 서비스를 관리합니다.
✔️서비스 출시/업데이트 후 약 1~2 주간은 이상이 있는지 직접 서비스를 사용하며 확인합니다.
이미 협력사의 결과물을 확인하고 서비스를 출시했겠지만, 그래도 빈틈이 나올 확률이 높습니다. 꼼꼼히 확인합니다.
✔️오류가 있을 경우 최대한 빠르게 관련 담당자에게 수정을 요청합니다.
✔️고객 불만이 접수될 경우, 대응합니다. (최대한 빨리 수정합니다.)
고객 불만과 오류에 빨리 대응해야 합니다. 회사는 고객의 목소리에 가장 예민합니다.
2. 기술/개발 기획
기획자는 기획을 실현하는 데에 필요한 기술을 직접 개발하지 않습니다. 하지만 서비스를 출시하기 위해 기술이 적절한 수준으로 개발되었는지 판단해야 합니다. 기술을 서비스에 맞게 적용하는 과정에서 개발자와 끊임없이 협의해야 합니다. 출시 후 기술 이슈를 발견하면 수정 개발을 요구합니다.
2.1 서비스에 적용할 기술을 검증합니다.
✔️회사의 전략 혹은 새로운 기획에 따라 신규 기술을 적용해야 할 때가 있습니다.
✔️신규 기술이 서비스 가능한 수준인지 서비스에 시범적으로 적용하여 정성/정량적으로 평가하고 판단합니다.
신규 기술의 성능은 기술을 개발한 팀/업체에서도 검증합니다. 하지만, 서비스 기획자가 판단하는 서비스 가능한 수준과 기술 개발자가 생각하는 수준이 다르기 때문에 서비스 기획 측에서도 검증해야 합니다. (개발자는 서비스 기획자에 비해 기술 친화적으로 생각하는 편입니다)
같은 조직 내에서 기술을 개발했더라도 서비스 기획 측면에서의 기술 평가는 필요합니다.
2.2 기술 적용 방법에 대해 협의합니다.
✔️기술을 서비스에 최적화하여 적용하기 위해선 개발자와 여러 번의 협의가 필요합니다.
- 예를 들어, 영상에서 동물이 나온 구간을 인식하는 기술을 개발했습니다. 객체가 1초만 나와도 인식하면 "기린"이 나오는 장면을 검색했을 때 1초짜리 영상까지 검색됩니다. 서비스적으로 불완전해 보이기 때문에 몇 초 이상의 장면만 인식할지 정합니다.
✔️기술을 서비스에 적용할 범위를 정합니다.
- 예를 들어, 동물을 인식하는 알고리즘을 개발했습니다. 동물이 중심이 되는 콘텐츠에만 알고리즘을 적용하는 것이 동물 장면을 추출하는 데에 효율적입니다. (동물이 나오지도 않는 영상을 인식시키면 쓸 데 없는 돈과 시간이 소요됩니다) 알고리즘을 적용할 콘텐츠 범위를 한정합니다.
2.3 기술 오류를 수정합니다.
✔️서비스 출시 전, 후에 기술 상의 이슈를 발견하면 개발자에게 수정 요청합니다.
✔️수정 완료 후 서비스에 제대로 적용되었는지 확인합니다.
3. 운영 기획
기술이 불완전하면 서비스가 출시되기 전에 기술을 적용한 결과를 사람이 검수해야 합니다.
특히 AI는 결과물에 대한 검수가 꼭 필요합니다. 검수 작업을 하는 인력을 운영 인력으로 지칭합니다. 알고리즘을 돌리고 결과물을 검수하기 위해 운영 인력에게 운영 툴을 제공하고, 운영 툴 사용 방법을 알려줍니다. 운영에서 툴과 기술에 대한 수정 요구 사항이 있을 경우, 이를 개발자에게 전달합니다.
3.1 운영을 관리합니다.
✔️운영 프로세스와 시간을 최대한 단축하기 위해 효율적인 운영 정책을 만듭니다.
- 기술의 결과물을 100% 다 검수할 수 없습니다.
- 최소한의 인풋으로 최대한의 정확도를 보장할 수 있는 운영 정책을 만듭니다.
✔️운영 툴과 기술을 수정합니다.
- 운영자의 기술과 운영 툴에 관한 요구사항을 수집하고, 개발자에게 수정 요청합니다.
3.2 기술/기획 변화가 생기면 운영도 바꿉니다.
✔️새로운 기술이 적용되거나 새로운 기획이 생길 때마다 검수해야 하는 범위가 달라집니다.
✔️새롭게 검수해야 하는 부분과 운영 정책을 전달합니다.
4. 통계 기반 기획
기획 단계에서 각 서비스 별로 사용 로그 수집이 필요한 기능을 기재합니다. 로그 수집 기능 개발은 서비스 개발과 함께 이루어집니다. 수집된 로그를 모니터링하는 방식과 적재 기간 등을 정합니다.
4.1 로그를 모니터링하고 인사이트를 도출합니다.
✔️일별, 주별, 월별 등 정해진 기간 별로 서비스 사용 로그를 모니터링합니다.
✔️주기적으로, 혹은 로그에 큰 변화가 있을 경우 로그 변화 history를 파악하여 원인을 알아냅니다.
✔️서비스 기획 방향성을 정하기 위해 로그를 분석합니다.
- 예를 들어, 왼쪽에 있던 버튼을 오른쪽으로 옮겼더니 로그 수가 급격하게 떨어집니다.
- 버튼의 접근성을 높이기 위해 왼쪽으로 다시 배치합니다.
4.2 로그 정합성을 관리합니다.
✔️로그에 오류가 발생할 경우 개발 수정을 요청합니다.
✔️기획/개발이 수정된 후 그에 맞춰 로그도 수정 개발 요청합니다.
- 수정 개발 요청을 위해서 개발자가 이해할 수 있는 형태로 기획서를 작성하여 보냅니다.
- 어떤 화면의 어떤 로그를 어떻게 바꿔달라는 것을 명확하게 전달합니다.
저는 현재 로그를 메일로 데일리 리포트 형식으로 받고 있습니다. 로그는 눈에 보이지 않기 때문에 기획서에서 요구 한대로 로그가 쌓이고 있는지 확인하는 것이 서비스를 검수하는 것보다 어렵습니다.
여기까지 대기업 IT 서비스 기획자가 하는 일의 종류입니다.
정리하자면 크게 1. 서비스 기획, 2. 기술/개발 기획, 3. 운영 기획, 4. 통계 기반 기획으로 나뉩니다.
사실 각각의 업무를 더 잘 이해하시기 위해선 구체적인 사례가 필요한데, 분량이 많아지다 보니 업무명과 간단한 설명 위주로 작성했습니다. 나중에 정보가 필요하겠다 싶으면 자세하게 적어보도록 하겠습니다.
제가 작성한 내용이 꼭 "대기업"에만 해당하는 것은 아닙니다. 다만, 업체를 많이 끼고 일을 한다던가 하는 대기업의 특성이 반영되어 있어 대기업을 다니시거나, 준비하시는 분께 조금 더 맞는 설명이라고 할 수 있습니다.
"대기업 IT 서비스 기획자는 어떤 일을 하나요? (IT 서비스 기획 실무)"
20.03.31
