IT 서비스 기획 직무를 준비하는 취업 준비생의 포트폴리오를 함께 점검하다 보면 화면 설계와 사용자 흐름은 상당히 잘 만들어졌는데, 왜 해당 기능을 추가하거나 개선해야 하는지 설명하는 단계에서 답변이 약해지는 경우가 있습니다. 회원가입 절차를 줄이고 추천 기능을 추가했으며 마이페이지 구조를 개편했다고 설명하지만, 기존 사용자들이 어느 단계에서 많이 이탈했는지, 어떤 행동 데이터를 근거로 기능의 우선순위를 정했는지 질문하면 사용자에게 더 편리할 것 같았다는 답변에서 멈추는 식입니다. 기획의 형태는 갖춰졌지만 판단의 근거가 충분하지 않은 것입니다.
프로젝트를 조금 더 자세히 확인하면 데이터가 없었던 것이 아니라 제대로 활용하지 않은 경우도 있습니다. 방문자 수와 클릭 수, 회원가입 수 같은 숫자는 수집했지만 어떤 지표를 중심으로 서비스 상태를 봐야 하는지 정하지 않았고, 사용자 행동 데이터도 전체 평균만 확인해 특정 단계나 사용자 군에서 발생하는 문제를 발견하지 못하는 경우입니다. 기능 개선 전후의 수치를 비교하지 않았기 때문에 실제로 기획한 변화가 효과가 있었는지도 설명하기 어렵습니다.
반대로 직접 데이터 분석가 수준의 복잡한 분석을 하지 않더라도 서비스 목적에 맞는 지표를 정의하고, 사용자 행동을 단계별로 나누어 확인하며, 그 결과를 기능 우선순위와 실험 방향으로 연결할 수 있는 기획자는 프로젝트 설명이 달라집니다. 왜 이 기능이 필요한지와 무엇을 개선하려는지가 데이터로 뒷받침되기 때문입니다. IT 서비스 기획자에게 필요한 데이터 역량은 분석 도구를 많이 다루는 능력만을 의미하지 않습니다. 서비스 상태를 지표로 읽고, 사용자의 실제 행동을 이해하며, 그 결과를 제품과 기능의 의사결정으로 연결할 수 있는 능력에 가깝습니다. 이번 글에서는 이를 지표, 사용자, 의사결정 세 가지 기준으로 나누어 정리하겠습니다.
지표는 서비스 상태를 느낌이 아니라 숫자로 판단하게 만드는 기준입니다
- 서비스 목표와 연결되는 핵심 지표를 먼저 구분할 필요가 있습니다
서비스 기획에서는 다양한 숫자를 볼 수 있습니다. 방문자 수, 페이지뷰, 가입자 수, 전환율, 재방문율, 결제율, 이탈률처럼 확인 가능한 데이터가 많기 때문에 처음에는 많이 보는 것이 좋은 분석처럼 느껴질 수 있습니다. 하지만 모든 지표를 동일하게 보면 어떤 변화가 중요한지 판단하기 어려워질 수 있습니다.
서비스 지표를 볼 때는 다음과 같은 기준으로 나눌 수 있습니다.
- 서비스가 해결하려는 핵심 목적이 무엇인지 확인합니다.
- 사용자가 목표 행동에 도달하는 과정을 구분합니다.
- 각 단계에서 확인할 수 있는 지표를 연결합니다.
- 결과를 보여주는 지표와 원인을 찾는 지표를 나눕니다.
- 일간과 주간, 월간 가운데 적절한 기간을 정합니다.
- 기능 변경 전후를 같은 기준으로 비교할 수 있는지 확인합니다.
예를 들어 회원가입 개선이 목적이라면 전체 방문자 수보다 가입 시작률과 완료율, 단계별 이탈률이 더 직접적인 지표가 될 수 있습니다. 결제 경험을 개선하려는 프로젝트라면 가입자 증가보다 장바구니에서 결제까지의 전환과 결제 실패 비율을 보는 편이 목적과 가깝습니다. 서비스 기획자의 데이터 역량은 숫자를 많이 모으는 것이 아니라 현재 해결하려는 문제를 가장 잘 보여주는 숫자가 무엇인지 구분하는 능력에서 시작됩니다.
- 숫자를 보는 것과 지표를 정의하는 것은 서로 다른 작업입니다
프로젝트에서 전환율이 20%라고 작성해도 어떤 사용자를 분모로 계산했는지가 없다면 해당 숫자의 의미를 정확하게 알기 어렵습니다. 기획자는 분석 결과를 받아보는 입장이더라도 지표가 어떤 기준으로 계산되는지는 이해할 필요가 있습니다.
- 숫자 중심의 확인: 서비스 가입자가 지난달보다 늘었다는 결과를 확인합니다.
- 지표 중심의 확인: 방문 사용자 가운데 실제 회원가입을 완료한 사용자의 비율을 정의하고 기간별로 비교합니다.
- 조건까지 포함한 확인: 이미 가입된 사용자나 내부 테스트 계정을 제외할지와 같은 기준을 정합니다.
- 서비스 판단까지 연결한 확인: 방문자는 증가했지만 가입 완료율이 낮아졌다면 유입 확대보다 가입 과정의 문제를 추가로 확인할 수 있습니다.
이렇게 지표의 기준을 이해하면 숫자가 변했다는 사실만 보는 데서 벗어날 수 있습니다. 특히 개발자나 데이터 분석가와 협업할 때도 어떤 사용자를 기준으로 집계하는지, 중복 행동은 어떻게 처리하는지, 성공 상태를 무엇으로 정의하는지를 더 구체적으로 논의할 수 있습니다.
- 결과 지표와 과정 지표를 함께 보면 문제 위치를 찾기 쉬워집니다
서비스 기획에서는 최종 결과만 보는 것보다 사용자가 그 결과에 도달하기까지의 과정도 함께 볼 필요가 있습니다. 매출과 가입자 수 같은 결과가 떨어졌다는 사실만으로는 어느 기능을 개선해야 하는지 판단하기 어렵기 때문입니다.
다음과 같은 방식으로 지표를 연결할 수 있습니다.
- 최종적으로 확인할 결과 지표를 먼저 정합니다.
- 사용자가 결과에 도달하는 주요 단계를 나눕니다.
- 각 단계에서 이탈과 전환을 측정합니다.
- 특정 단계에서 변화가 집중되는지 확인합니다.
- 사용자 군이나 기기별 차이가 있는지 살펴봅니다.
- 기능 변경 이후 같은 지표를 다시 측정합니다.
예를 들어 구매 건수가 감소했다면 방문자가 줄었는지, 상품 조회는 유지되지만 장바구니 전환이 떨어졌는지, 장바구니까지는 정상인데 결제 완료율이 낮아졌는지를 나누어볼 수 있습니다. 이런 지표 구조가 있으면 사용자가 구매하지 않는다는 넓은 문제를 어느 단계에서 변화가 발생했는지 확인할 수 있는 기획 문제로 바꿀 수 있습니다.
- 기획자에게 필요한 지표 역량은 분석가 역할을 대신하는 것이 아닙니다
데이터 역량이 중요하다는 말을 들으면 서비스 기획자도 SQL과 Python을 깊게 공부해야 한다고 생각할 수 있습니다. 실제 채용공고에 SQL이나 데이터 분석 경험이 포함되는 경우도 있지만 모든 기획자에게 데이터 분석가와 동일한 기술 수준이 필요한 것은 아닙니다.
- 기초적인 수준: 주요 지표의 의미와 계산 기준을 이해하고 대시보드를 읽을 수 있습니다.
- 업무 활용 수준: 서비스 문제와 연결되는 지표를 선택하고 필요한 데이터를 분석 담당자에게 요청할 수 있습니다.
- 직접 분석 수준: SQL 등을 활용해 간단한 사용자 행동과 지표를 직접 확인할 수 있습니다.
- 협업 수준: 분석 결과를 그대로 받아들이기보다 기준과 기간, 대상이 적절한지 확인하고 추가 분석 방향을 논의할 수 있습니다.
- 의사결정 수준: 분석 결과를 기능 우선순위와 실험, 개선 계획에 연결할 수 있습니다.
따라서 서비스 기획자의 데이터 역량은 도구 자체보다 지표를 읽고 질문을 만들며 기획 판단으로 연결할 수 있는 수준에서 먼저 시작하는 것이 중요합니다.
사용자 데이터는 실제 사용자가 서비스에서 무엇을 하는지 이해하는 근거가 됩니다
- 사용자가 원하는 것과 실제로 행동하는 것은 다를 수 있습니다
서비스 기획에서는 인터뷰와 설문, 사용자 의견을 통해 요구사항을 수집할 수 있습니다. 이런 정성적인 자료는 중요하지만 사용자가 말한 내용과 실제 행동이 항상 같지는 않을 수 있습니다. 따라서 사용자 행동 데이터와 함께 보는 것이 도움이 됩니다.
사용자 행동을 이해할 때는 다음 내용을 확인할 수 있습니다.
- 사용자가 처음 어떤 경로로 서비스에 들어오는지 살펴봅니다.
- 어떤 기능을 가장 많이 사용하는지 확인합니다.
- 특정 단계에서 사용을 중단하는 비율을 봅니다.
- 같은 기능을 반복해서 사용하는 패턴이 있는지 살펴봅니다.
- 신규와 기존 사용자의 행동 차이를 구분합니다.
- 기능 변경 이후 행동이 실제로 달라졌는지 확인합니다.
예를 들어 사용자 인터뷰에서는 검색 기능이 불편하다는 의견이 많았지만 실제 행동 데이터에서는 검색 이후 상품 상세페이지까지 이동하는 비율이 높고, 결제 단계에서 이탈이 크게 나타날 수도 있습니다. 이 경우 검색 개선 의견을 무시하는 것이 아니라 정성적인 의견과 실제 행동을 함께 비교하면서 현재 어떤 문제의 우선순위가 더 높은지 판단할 추가 근거를 만들 수 있습니다.
- 사용자 수가 많다는 것과 사용자가 만족한다는 것은 같은 의미가 아닙니다
서비스 성과를 볼 때 월간 사용자 수나 다운로드 수처럼 규모를 보여주는 숫자가 먼저 눈에 들어올 수 있습니다. 하지만 많은 사용자가 들어오는 것과 지속적으로 서비스를 이용하는 것은 다른 문제입니다.
- 유입 중심의 관점: 광고나 검색을 통해 많은 사용자가 서비스에 방문하는지를 봅니다.
- 활성화 중심의 관점: 방문한 사용자가 핵심 기능을 실제로 경험하는지 확인합니다.
- 유지 중심의 관점: 한 번 사용한 사람이 이후에도 다시 돌아오는지 살펴봅니다.
- 행동 중심의 관점: 재방문하더라도 핵심 기능을 충분히 사용하는지 확인합니다.
- 경험 중심의 관점: 반복되는 오류와 불필요한 단계를 겪으면서 사용자가 이탈하고 있지는 않은지 살펴봅니다.
서비스 기획자가 사용자 데이터를 볼 때 전체 사용자 수만 확인하지 않고 사용자가 들어온 뒤 어떤 행동을 하고 어디에서 떠나는지까지 봐야 하는 이유가 여기에 있습니다.
- 사용자 군을 나누면 전체 평균에서 보이지 않던 문제를 발견할 수 있습니다
전체 사용자의 평균만 보면 서비스가 안정적인 것처럼 보이지만 특정 사용자 군에서는 큰 문제가 발생하고 있을 수 있습니다. 따라서 필요한 경우 사용자를 의미 있는 기준으로 나누어 행동 차이를 확인할 수 있습니다.
사용자 분석에서는 다음과 같은 구분을 활용할 수 있습니다.
- 신규 사용자와 기존 사용자를 나누어 봅니다.
- 모바일과 PC 사용자의 행동을 비교합니다.
- 유입 채널별 전환 차이를 확인합니다.
- 특정 기능 사용 경험이 있는 사용자와 없는 사용자를 구분합니다.
- 결제 사용자와 비결제 사용자의 행동을 비교합니다.
- 서비스 이용 기간에 따라 행동 패턴이 달라지는지 살펴봅니다.
예를 들어 전체 회원가입 완료율은 비슷하지만 모바일 신규 사용자만 특정 단계에서 높은 이탈을 보인다면 전체 가입 프로세스를 전부 변경하기보다 해당 환경의 문제를 먼저 확인할 수 있습니다. 이런 경험은 기획자가 데이터를 이용해 단순 평균에서 벗어나 실제로 문제가 발생하는 사용자와 상황을 좁혀가는 능력과 연결됩니다.
- 사용자 데이터는 기능 추가보다 문제를 더 정확하게 정의하는 데 활용할 수 있습니다
기획 프로젝트에서 기능 아이디어를 먼저 만들고 데이터를 그 기능의 필요성을 증명하는 자료로 사용하는 경우가 있습니다. 하지만 데이터는 이미 정한 결론을 뒷받침하기보다 실제 문제가 무엇인지 찾는 데 활용하는 편이 좋습니다.
- 아이디어 중심의 접근: 추천 기능을 추가하면 사용자가 더 오래 머물 것이라고 예상합니다.
- 사용자 데이터 중심의 접근: 어떤 사용자가 어느 단계에서 탐색을 중단하는지 먼저 확인합니다.
- 문제 중심의 접근: 원하는 상품을 찾지 못하고 검색을 반복하는 행동이 특정 사용자 군에서 나타나는지 살펴봅니다.
- 기획 연결: 실제 탐색 문제가 확인된다면 추천, 검색 개선, 필터 개선 등 여러 해결 방법을 비교할 수 있습니다.
- 검증 연결: 기능을 적용한 뒤 탐색시간과 상품조회, 구매 전환 등이 실제로 변화했는지 다시 확인합니다.
이렇게 접근하면 데이터는 이미 만든 기능을 정당화하는 자료가 아니라 사용자 문제를 발견하고 해결 방법을 비교하는 자료가 됩니다.
의사결정은 데이터를 기능과 우선순위, 개선 방향으로 연결하는 과정입니다
- 데이터가 있다고 해서 자동으로 좋은 기획 결정이 만들어지는 것은 아닙니다
데이터 기반 의사결정이라는 표현 때문에 수치가 높은 선택을 하면 항상 올바른 결정이라고 생각하기 쉽습니다. 하지만 서비스 기획에서는 사용자 가치와 개발 비용, 일정, 사업 목표처럼 데이터 외의 조건도 함께 고려해야 합니다.
의사결정을 할 때는 다음 요소를 구분할 수 있습니다.
- 데이터에서 실제로 확인된 사실이 무엇인지 정리합니다.
- 가능한 원인과 확인되지 않은 가설을 구분합니다.
- 문제가 영향을 주는 사용자 규모를 확인합니다.
- 개선했을 때 기대할 수 있는 효과를 살펴봅니다.
- 구현에 필요한 개발 범위와 일정을 확인합니다.
- 적용 이후 다시 검증할 지표를 정합니다.
예를 들어 특정 기능의 이용률이 낮다고 해서 바로 삭제해야 하는 것은 아닙니다. 신규 사용자가 해당 기능을 찾기 어려워 이용률이 낮은 것인지, 소수지만 핵심 고객이 반복적으로 사용하는 기능인지 추가 확인이 필요할 수 있습니다. 데이터 기반 의사결정은 숫자가 결정을 대신하는 것이 아니라 판단에 필요한 불확실성을 줄이는 과정이라고 보는 편이 좋습니다.
- 분석 결과와 기획 결론 사이에는 해석과 우선순위 판단이 필요합니다
서비스 데이터를 분석해 특정 지표가 떨어졌다는 사실을 확인해도 실제 기획에서는 무엇을 먼저 개선할지 선택해야 합니다.
- 분석 결과 중심의 판단: 결제 완료율이 이전 기간보다 낮아졌다는 사실을 확인합니다.
- 원인 탐색 중심의 판단: 결제 단계별 데이터를 비교해 특정 인증 과정에서 이탈이 증가했는지 살펴봅니다.
- 사용자 영향 중심의 판단: 해당 문제가 전체 사용자 중 어느 정도에게 영향을 주는지 확인합니다.
- 개발 비용까지 포함한 판단: 개선 효과와 구현 난도, 다른 기능 일정까지 함께 비교합니다.
- 우선순위 결정: 즉시 수정할 문제인지 다음 개선 주기에 포함할 문제인지 판단합니다.
이 과정이 있어야 데이터가 대시보드 안의 숫자로 끝나지 않고 제품 로드맵과 기능 개발의 우선순위로 연결됩니다. 서비스 기획자의 데이터 역량은 분석 결과를 직접 만드는 능력뿐 아니라 결과를 현실적인 제품 결정으로 번역하는 능력에서도 드러납니다.
- 기능을 적용한 뒤 다시 측정해야 기획의 효과를 검증할 수 있습니다
프로젝트에서는 기능을 개발하고 화면이 정상적으로 나오면 완성되었다고 생각하기 쉽습니다. 하지만 데이터 기반 기획에서는 기능이 실제 사용자 문제를 개선했는지를 적용 이후 다시 확인하는 과정이 필요합니다.
기능 개선 이후에는 다음과 같은 흐름을 만들 수 있습니다.
- 변경 이전의 기준 지표를 기록합니다.
- 어떤 사용자를 대상으로 변경했는지 구분합니다.
- 변경 이후 동일한 지표를 다시 측정합니다.
- 예상했던 방향으로 행동이 달라졌는지 확인합니다.
- 다른 지표에 예상하지 못한 변화가 생기지 않았는지 살펴봅니다.
- 결과에 따라 추가 수정이나 다음 실험을 결정합니다.
예를 들어 회원가입 단계를 네 단계에서 세 단계로 줄였다면 화면이 간결해졌다는 평가만으로 끝내지 않고 가입 시작 대비 완료율과 각 단계의 이탈을 다시 비교할 수 있습니다. 이런 경험이 포트폴리오에 포함되면 기능을 설계했다는 수준을 넘어 문제 발견 → 변경 → 측정 → 재검증의 기획 흐름을 보여줄 수 있습니다.
- 데이터 역량은 기획자의 의견을 없애는 것이 아니라 판단 근거를 더 명확하게 만듭니다
데이터 중심 기획을 강조하다 보면 모든 기획을 숫자로만 결정해야 한다고 생각할 수 있습니다. 하지만 아직 출시하지 않은 서비스처럼 충분한 행동 데이터가 없는 상황도 있고, 정성적인 사용자 경험이 더 중요한 문제도 존재합니다.
- 데이터가 충분한 경우: 실제 사용자 행동과 지표를 이용해 문제의 크기와 발생 지점을 확인할 수 있습니다.
- 데이터가 부족한 경우: 인터뷰와 사용성 테스트, 시장 조사 등을 이용해 가설을 만들 수 있습니다.
- 새로운 기능의 경우: 먼저 작은 범위에서 테스트하고 이후 데이터를 수집해 판단 근거를 늘릴 수 있습니다.
- 서로 다른 근거가 충돌하는 경우: 데이터 결과와 사용자 의견이 왜 다르게 나타나는지 추가로 확인할 수 있습니다.
- 최종 의사결정 단계: 데이터와 사용자 가치, 사업 목표, 기술적 제약을 함께 비교해 선택할 수 있습니다.
따라서 기획자의 데이터 역량은 개인적인 판단을 없애는 능력이 아니라 왜 이런 결정을 했는지를 다른 직군이 이해할 수 있는 근거로 만드는 능력에 가깝습니다.
- conclusion
IT 서비스 기획자가 데이터 역량을 준비해야 하는 이유는 데이터 분석가처럼 복잡한 모델을 만들기 위해서가 아닙니다. 서비스 기획은 사용자의 문제를 정의하고 기능의 우선순위를 정하며 개발 이후 결과를 다시 확인하는 일을 반복하기 때문에 각 판단을 뒷받침할 근거가 필요합니다. 이 과정에서 지표와 사용자 행동 데이터는 기획자의 감각을 대신하는 것이 아니라 더 정확한 질문을 만들고 선택의 범위를 좁히는 자료가 됩니다.
지표에서는 서비스 목표와 연결되는 숫자가 무엇인지 이해해야 합니다. 사용자 영역에서는 전체 평균보다 실제 사용자가 어떤 경로로 움직이고 어느 단계에서 이탈하는지 확인할 수 있어야 합니다. 의사결정에서는 분석 결과를 그대로 결론으로 사용하는 것이 아니라 영향 범위와 개발 난도, 사용자 가치까지 함께 고려해 기능 우선순위와 개선 방향으로 연결해야 합니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 서비스 목적과 연결되는 핵심 지표를 구분할 수 있는지 확인합니다.
- 전환율과 이탈률 같은 지표의 계산 기준을 이해하고 있는지 살펴봅니다.
- 사용자의 행동 흐름을 단계별로 분석할 수 있는지 확인합니다.
- 전체 평균과 특정 사용자 군의 차이를 구분할 수 있는지 점검합니다.
- 데이터에서 확인된 사실과 아직 검증되지 않은 가설을 나눌 수 있는지 살펴봅니다.
- 기능 적용 이후 같은 지표를 다시 측정해 결과를 검증할 수 있는지 확인합니다.
서비스 기획자의 데이터 역량 준비 흐름은 다음과 같이 연결할 수 있습니다.
- 서비스 목표 정의 → 핵심 사용자 행동 파악 → 주요 지표 정의 → 사용자 흐름 데이터 확인 → 문제 발생 단계 구분 → 원인 가설 설정 → 필요한 추가 데이터 확인 → 기능 개선안 비교 → 개발 범위와 우선순위 결정 → 기능 적용 → 지표 재측정 → 결과 분석 → 추가 개선 → 포트폴리오와 면접 연결.
결국 IT 서비스 기획자의 데이터 역량에서 중요한 것은 SQL이나 분석 도구를 몇 개 사용할 수 있는지만이 아닙니다. 지표를 통해 서비스 상태를 읽고, 사용자 데이터를 통해 실제 행동과 문제를 이해하며, 그 결과를 기능과 우선순위의 의사결정으로 연결할 수 있는가가 핵심입니다. 이런 흐름이 프로젝트 안에 남아 있으면 화면 설계 능력뿐 아니라 왜 그 기능을 기획했고 어떤 결과를 기대했으며 실제로 무엇이 달라졌는지를 근거를 가지고 설명할 수 있습니다.
