데이터 기반 의사결정을 이끄는 IT 기획 직무의 핵심 역량 분석 실무에서 차이를 만드는 능력

데이터 기반 의사결정을 이끄는 IT 기획 직무의 핵심 역량 분석을 처음 깊게 정리했을 때 제가 가장 먼저 다시 생각하게 된 것은 IT 기획자가 과연 무엇을 잘해야 하는 사람인가였습니다.

 

예전에는 요구사항을 정리하고 화면이나 기능을 정의하며 개발 일정과 관련 부서를 조율하는 능력이 뛰어나면 좋은 IT 기획자라고 생각했습니다. 물론 이런 능력은 지금도 중요하지만 실제 서비스를 운영하고 여러 프로젝트를 경험하다 보면 그것만으로는 부족하다는 것을 금방 느끼게 됩니다.

 

특히 이용자가 많은 서비스나 다양한 업무 시스템에서는 회의에서 목소리가 큰 사람의 의견이나 담당자의 경험만으로 중요한 기능의 우선순위를 결정하기가 점점 어려워집니다.

 

어떤 기능을 먼저 개선해야 하는지, 이용자가 어느 단계에서 서비스를 이탈하는지, 새롭게 적용한 기능이 실제 성과를 만들었는지 등을 판단하려면 객관적으로 확인할 수 있는 근거가 필요하기 때문입니다.

 

저도 실무적인 관점에서 IT 기획 업무를 살펴보면서 데이터를 잘 다룬다는 것은 숫자를 많이 보는 능력이 아니라 숫자 속에서 사업과 이용자의 문제를 발견하고 그것을 실행 가능한 의사결정으로 연결하는 능력이라는 점이 가장 중요하다고 느꼈습니다.

 

그렇다고 IT 기획자가 전문 데이터 분석가처럼 모든 통계 기법이나 분석 도구를 완벽하게 다뤄야 한다는 의미는 아닙니다. 오히려 어떤 데이터를 봐야 하는지 질문할 수 있고 지표의 의미를 정확하게 이해하며 분석 결과를 사업과 서비스의 언어로 해석하는 능력이 중요합니다.

 

데이터가 아무리 많아도 잘못된 지표를 보고 있다면 판단 역시 잘못될 수 있고 분석 결과를 제대로 설명하지 못한다면 좋은 근거가 있어도 조직의 실행으로 연결하기 어렵습니다.

 

오늘 제가 준비한 포스팅에서는 데이터 기반 의사결정을 이끄는 IT 기획자에게 어떤 역량이 필요한지부터 문제 정의와 지표 설계, 데이터 해석, 서비스 개선, 개발자와 분석가 사이의 협업, 의사결정 결과를 다시 검증하는 과정까지 실제 업무 흐름에 맞춰 자세하게 정리해보겠습니다.

데이터 기반 의사결정을 이끄는 IT 기획은 문제 정의에서 시작됩니다

데이터 기반 업무라고 하면 가장 먼저 대시보드나 분석 도구부터 떠올리기 쉽지만 제가 실제 업무를 정리하면서 가장 중요하다고 느낀 출발점은 문제를 정확하게 정의하는 능력이었습니다.

 

문제가 명확하지 않은 상태에서 데이터를 많이 수집하면 숫자는 계속 늘어나지만 정작 어떤 결정을 내려야 하는지는 더 어려워질 수 있습니다.

 

예를 들어 서비스의 매출이 감소했다고 가정해보겠습니다. 단순히 매출 그래프만 확인해서는 원인을 알기 어렵습니다.

 

신규 이용자가 줄었을 수도 있고 방문자는 그대로인데 구매 전환율이 낮아졌을 수도 있습니다. 기존 고객의 재구매가 감소했거나 특정 상품군의 판매가 줄었을 가능성도 있습니다.

 

IT 기획자는 이런 상황에서 바로 해결책을 제안하기보다 문제가 발생한 범위를 먼저 나눠보는 능력이 필요합니다.

 

저라면 전체 이용자와 신규 이용자를 구분하고 유입부터 탐색, 장바구니, 결제까지 주요 단계를 살펴본 뒤 어느 구간에서 이전과 다른 변화가 발생했는지를 확인하는 방식으로 접근합니다.

 

이 과정에서 중요한 것은 데이터를 보는 목적입니다. 단순히 숫자가 증가했는지 감소했는지를 확인하는 것이 아니라 어떤 사업적 질문에 답하기 위해 해당 데이터를 확인하는지 분명해야 합니다.

 

예를 들어 회원가입 완료율이 떨어졌다면 전체 완료율만 볼 것이 아니라 특정 기기나 운영환경에서 문제가 집중되는지, 특정 입력 단계에서 이탈이 증가했는지 등을 나누어 확인할 수 있습니다.

 

문제 정의가 구체적일수록 개발자나 데이터 담당자에게 요청하는 내용도 명확해집니다.

 

“회원가입 데이터를 한번 분석해주세요”라는 요청과 “최근 회원가입 완료율 감소가 특정 단계의 이탈 증가 때문인지 확인하고 기기별 차이도 함께 비교해주세요”라는 요청은 결과의 활용 가능성에서 큰 차이가 있습니다.

 

또한 데이터에서 나타난 현상과 원인을 구분하는 태도도 필요합니다.

 

특정 화면에서 이탈률이 높다는 사실이 확인됐다고 해서 반드시 그 화면의 디자인이 문제라고 단정할 수는 없습니다. 가격이나 정책, 처리속도, 이용자 유입 경로 등 다른 요인이 영향을 주었을 가능성도 함께 살펴봐야 합니다.

 

데이터 기반 IT 기획의 출발점은 데이터를 많이 확보하는 것이 아니라 지금 어떤 문제가 발생했고 어떤 질문에 답해야 다음 행동을 결정할 수 있는지를 명확하게 정의하는 것입니다.

 

이런 문제 정의 능력이 갖춰지면 데이터를 확인하는 시간이 오히려 줄어들 수 있습니다.

 

수십 개의 지표를 무작정 살펴보는 대신 현재 의사결정에 필요한 몇 가지 지표에 집중할 수 있기 때문입니다.

 

결국 IT 기획자가 데이터 활용에서 가장 먼저 키워야 할 능력은 분석 도구의 기능을 많이 외우는 것이 아니라 사업과 이용자의 문제를 데이터로 검증할 수 있는 질문으로 바꾸는 능력이라고 생각합니다.

IT 기획 직무의 핵심 역량은 지표를 설계하고 정확하게 해석하는 능력입니다

서비스를 기획하면서 제가 생각보다 어렵다고 느꼈던 부분이 좋은 지표를 정하는 일이었습니다.

 

방문자가 늘고 페이지 조회가 증가하면 서비스가 성장하는 것처럼 보일 수 있지만 실제 사업 목표와 연결되지 않는다면 그 숫자만으로 좋은 성과라고 판단하기 어렵습니다.

 

예를 들어 온라인 서비스에서 방문자 수는 증가했지만 구매 전환율과 재구매율이 동시에 낮아졌다면 단순한 트래픽 증가를 성공이라고 평가하기 어렵습니다.

 

반대로 전체 방문자 수는 크게 증가하지 않았지만 핵심 고객의 이용 빈도와 구매 금액이 꾸준히 늘었다면 사업적으로 더 의미 있는 변화일 수도 있습니다.

 

그래서 IT 기획자는 사업 목표와 서비스 행동을 연결하는 지표를 설계할 수 있어야 합니다.

 

제가 지표를 정리할 때 편했던 방법은 최종 목표와 중간 행동을 나누는 것이었습니다.

 

예를 들어 최종 목표가 유료 이용자 증가라면 회원가입 수만 보는 것이 아니라 무료 이용에서 유료 이용으로 전환되는 비율, 첫 결제까지 걸리는 기간, 일정 기간 이후 계속 서비스를 이용하는 비율 등을 함께 살펴볼 수 있습니다.

 

지표의 정의도 명확해야 합니다.

 

같은 활성 이용자라는 표현도 조직마다 기준이 다를 수 있습니다. 단순히 로그인한 사람을 활성 이용자로 볼 것인지 핵심 기능을 실제로 사용한 사람만 포함할 것인지에 따라 결과가 완전히 달라질 수 있습니다.

 

따라서 지표명뿐만 아니라 계산 기준과 기간, 포함 대상과 제외 조건까지 정리해두는 것이 좋습니다.

 

지표를 해석할 때는 평균값 하나에 지나치게 의존하지 않는 것도 중요합니다.

 

전체 평균에서는 큰 변화가 없어 보이지만 신규 고객과 기존 고객을 나누거나 모바일과 PC를 구분하면 특정 집단에서 큰 문제가 나타날 수 있습니다.

 

기간을 비교할 때도 계절이나 프로모션, 서비스 장애처럼 숫자에 영향을 줄 수 있는 사건을 함께 확인해야 합니다.

 

좋은 지표는 숫자가 크고 보기 좋은 지표가 아니라 실제 사업 목표와 연결되어 있으며 그 숫자가 변했을 때 조직이 다음 행동을 결정할 수 있는 지표입니다.

 

저는 특히 지표가 목표로 변하는 순간을 조심해야 한다고 생각합니다.

 

예를 들어 이용시간을 높이는 것이 목표가 되면 서비스 이용시간은 증가했지만 이용자가 원하는 업무를 완료하는 데 오히려 시간이 오래 걸리는 문제가 생길 수도 있습니다.

 

따라서 지표를 정할 때는 어떤 행동을 유도하기 위해 이 숫자를 보는지와 함께 숫자가 좋아졌을 때 발생할 수 있는 부작용까지 생각해보는 것이 필요합니다.

 

결국 IT 기획자의 지표 설계 역량은 숫자를 관리하는 기술이라기보다 사업의 성공을 관찰 가능한 행동과 수치로 바꾸는 능력에 가깝습니다.

데이터 분석 결과를 서비스 개선으로 연결하는 실행 역량이 중요합니다

데이터를 확인하고 의미 있는 패턴을 발견했는데도 실제 서비스가 바뀌지 않는 경우가 생각보다 많습니다.

 

저도 데이터 기반 기획을 살펴보면서 분석 자체보다 분석 이후 무엇을 할 것인지 결정하는 과정이 더 어렵다는 것을 느꼈습니다.

 

예를 들어 결제 단계에서 이용자 이탈이 높다는 사실을 확인했다고 가정해보겠습니다.

 

이 사실만 가지고 바로 결제 화면을 전면 개편하는 것은 성급할 수 있습니다. 먼저 어느 단계에서 이탈이 발생하는지 확인하고 특정 결제수단이나 기기에서 문제가 집중되는지 살펴봐야 합니다.

 

이후 원인에 대한 가설을 세우고 가장 적은 비용으로 검증할 수 있는 개선안을 정하는 것이 좋습니다.

 

입력 항목이 너무 많다는 가설이 있다면 일부 불필요한 입력을 줄여볼 수 있고 결제수단 선택 과정이 복잡하다고 판단한다면 화면 구조를 단순화하는 방법을 검토할 수 있습니다.

 

여기서 IT 기획자의 역할은 데이터를 근거로 개선 우선순위를 정하고 개발자와 디자이너, 사업 담당자가 이해할 수 있는 요구사항으로 바꾸는 것입니다.

 

모든 문제를 동시에 해결할 수 없기 때문에 영향도가 큰 문제인지, 얼마나 많은 이용자에게 발생하는지, 개발 난이도와 비용은 어느 정도인지 등을 함께 비교해야 합니다.

 

개선 기능을 배포한 뒤에는 결과를 다시 확인해야 합니다.

 

기능을 출시했다는 사실이 프로젝트의 끝이 아니라 처음에 해결하려고 했던 문제가 실제로 개선됐는지를 확인하는 과정까지 포함해야 합니다.

 

제가 데이터 기반 기획의 실무 흐름을 간단하게 정리한다면 아래와 같이 나눠볼 수 있습니다. 제가 만든 아래 표를 참고해보세요!

 

항목	설명	비고
문제 발견	핵심 지표와 이용 흐름을 확인해 평소와 다른 변화가 발생한 구간과 영향을 받는 이용자를 구체적으로 파악합니다.	현상과 원인을 구분하기
가설과 실행	문제가 발생한 원인에 대한 가설을 세우고 영향도와 개발 비용을 고려해 우선순위가 높은 개선안을 실행합니다.	근거 없는 전면 개편은 주의
성과 검증	배포 전후의 핵심 지표를 비교하고 처음 정의한 문제가 실제로 개선됐는지 확인합니다.	출시보다 결과 확인까지 관리

 

데이터 기반 기획은 분석 보고서를 만드는 것으로 끝나지 않습니다. 문제를 발견하고 원인에 대한 가설을 세운 뒤 개선안을 실행하고 결과를 다시 데이터로 검증하는 과정까지 이어져야 실제 의사결정에 활용됐다고 볼 수 있습니다.

 

성과를 확인할 때도 좋은 결과만 찾으려고 해서는 안 됩니다.

 

예상과 다르게 지표가 개선되지 않았다면 처음 세운 가설이 잘못됐는지, 실행 방식에 문제가 있었는지, 다른 외부 요인이 영향을 주었는지를 다시 확인하면 됩니다.

 

오히려 예상과 다른 결과를 기록하고 다음 개선에 활용하는 조직이 장기적으로는 더 많은 학습을 축적할 수 있습니다.

 

이런 과정을 반복하면 IT 기획자는 단순히 요구사항을 문서로 전달하는 역할에서 벗어나 문제를 정의하고 근거를 통해 우선순위를 정하며 결과까지 책임 있게 확인하는 역할로 확장될 수 있습니다.

IT 기획자는 개발자와 데이터 분석가를 연결하는 협업 능력이 필요합니다

데이터 기반 의사결정을 실제 조직에서 운영하다 보면 IT 기획자가 혼자 모든 데이터를 분석하고 결론까지 내리는 경우는 많지 않습니다.

 

저 역시 이 부분을 정리하면서 기획자의 개인적인 분석 능력 못지않게 중요한 것이 여러 전문 직군과 협업하는 능력이라고 느꼈습니다.

 

서비스에서 원하는 데이터를 확보하려면 개발 과정에서부터 필요한 이벤트와 로그가 제대로 기록되도록 설계해야 할 수 있습니다.

 

기능을 출시한 뒤 갑자기 데이터를 보고 싶다고 해도 처음부터 필요한 정보가 수집되지 않았다면 과거 이용자의 행동을 정확하게 확인하기 어려울 수 있습니다.

 

그래서 기획 단계에서부터 어떤 지표로 기능의 성공 여부를 판단할 것인지 생각하고 필요한 데이터가 무엇인지 개발 담당자와 함께 확인하는 습관이 중요합니다.

 

데이터 분석가와 협업할 때도 단순히 자료 추출을 요청하는 방식보다 의사결정의 배경을 공유하는 것이 좋습니다.

 

예를 들어 “최근 3개월 이용자 데이터를 뽑아주세요”라는 요청만으로는 분석 담당자가 어떤 기준으로 데이터를 나눠야 하는지 알기 어렵습니다.

 

반면 “최근 재구매율이 감소한 원인을 확인하려고 하며 신규 고객과 기존 고객의 구매주기 차이가 있는지 보고 싶다”고 설명하면 분석 목적에 맞는 방법을 함께 논의하기 쉬워집니다.

 

IT 기획자에게 기본적인 데이터 구조에 대한 이해가 필요한 이유도 여기에 있습니다.

 

모든 데이터베이스 기술을 직접 구현할 필요는 없지만 어떤 데이터가 어떤 시점에 생성되는지, 이용자를 어떤 기준으로 구분하는지, 중복이나 누락이 발생할 가능성이 있는지를 이해하면 분석 결과를 해석할 때 큰 도움이 됩니다.

 

기본적인 질의와 데이터 조회 방법을 이해하는 것도 실무에서는 유용합니다.

 

간단한 수치를 확인할 때마다 다른 사람에게 요청하지 않고 직접 검증할 수 있다면 의사결정 속도를 높일 수 있기 때문입니다.

 

다만 도구를 잘 사용하는 것과 올바르게 해석하는 것은 별개의 문제라는 점도 기억해야 합니다.

 

데이터를 활용하는 IT 기획자에게 중요한 협업 능력은 분석가에게 숫자를 요청하는 것이 아니라 어떤 결정을 위해 무엇을 확인해야 하는지를 설명하고 개발자와 함께 필요한 데이터가 수집될 수 있도록 기획 단계부터 준비하는 것입니다.

 

디자이너와의 협업에서도 데이터는 유용하게 활용할 수 있습니다.

 

특정 화면을 개선할 때 단순히 디자인 취향을 비교하는 것보다 이용자가 실제로 어디에서 어려움을 겪는지 행동 데이터와 고객 의견을 함께 확인하면 문제를 보다 구체적으로 정의할 수 있습니다.

 

사업 담당자에게 결과를 설명할 때는 분석 방법을 지나치게 자세히 설명하기보다 어떤 문제가 확인됐고 사업에 어느 정도 영향을 미치며 어떤 선택지가 있는지를 명확하게 전달하는 능력이 중요합니다.

 

결국 IT 기획자는 개발과 디자인, 데이터와 사업 사이에서 서로 다른 언어를 연결하면서 하나의 의사결정으로 모아주는 역할을 수행해야 합니다.

데이터를 설명하고 의사결정을 설득하는 커뮤니케이션도 핵심 역량입니다

좋은 분석 결과가 있다고 해서 조직이 바로 움직이는 것은 아니었습니다.

 

실무에서는 같은 데이터를 보고도 부서마다 전혀 다른 결론을 내릴 수 있고 각자의 목표에 따라 중요하게 생각하는 지표도 달라질 수 있습니다.

 

이때 IT 기획자는 숫자를 나열하는 사람이 아니라 데이터를 이해하기 쉬운 의사결정 자료로 바꾸는 역할을 해야 합니다.

 

저는 데이터를 설명할 때 가장 먼저 결론을 분명하게 정리하는 방식이 효과적이라고 느꼈습니다.

 

대시보드의 모든 숫자를 처음부터 하나씩 설명하기보다 현재 어떤 문제가 확인됐는지, 그 문제가 어느 정도 규모인지, 어떤 근거로 원인을 추정하는지, 그래서 어떤 행동을 제안하는지를 순서대로 이야기하면 듣는 사람이 훨씬 쉽게 이해할 수 있습니다.

 

예를 들어 “결제 전환율이 3% 감소했습니다”라고 말하는 것보다 어느 이용자 집단에서 언제부터 감소했고 전체 매출에 어떤 영향을 줄 가능성이 있는지를 함께 설명하면 의사결정의 중요성이 명확해집니다.

 

데이터의 한계를 설명하는 능력도 필요합니다.

 

두 지표가 동시에 움직였다고 해서 반드시 하나가 다른 하나의 원인이라고 단정할 수는 없습니다.

 

데이터가 충분하지 않거나 측정 방식이 변경됐다면 그 사실을 숨기지 않고 현재 확인할 수 있는 범위와 추가 검증이 필요한 부분을 구분해서 전달하는 것이 좋습니다.

 

이런 태도는 의사결정 속도를 늦추는 것이 아니라 오히려 잘못된 확신으로 큰 비용을 쓰는 것을 줄여줍니다.

 

회의에서도 데이터는 상대방을 이기기 위한 무기로 사용하지 않는 것이 중요했습니다.

 

현업 담당자가 오랜 경험을 바탕으로 제시하는 의견에는 데이터만으로 발견하기 어려운 맥락이 있을 수 있습니다.

 

따라서 데이터와 현장의 경험이 충돌할 때 어느 한쪽을 즉시 틀렸다고 판단하기보다 왜 차이가 발생했는지를 다시 확인하는 것이 더 좋은 결과로 이어질 수 있습니다.

 

데이터 기반 의사결정에서 중요한 것은 숫자로 상대방을 설득하는 것이 아니라 확인된 사실과 해석, 아직 검증되지 않은 가설을 구분해 설명하고 조직이 다음 행동을 선택할 수 있도록 만드는 것입니다.

 

의사결정 이후 기록을 남기는 습관도 도움이 됩니다.

 

당시 어떤 데이터를 근거로 어떤 가설을 세웠고 왜 해당 개선안을 선택했는지 기록해두면 결과가 나온 뒤 판단 과정을 다시 검토할 수 있습니다.

 

결과가 좋았다면 어떤 판단이 유효했는지를 학습할 수 있고 결과가 좋지 않았다면 데이터 해석이나 가설, 실행 과정 중 어디를 개선해야 하는지 확인할 수 있습니다.

 

이런 기록이 쌓이면 개인의 경험에 머물던 판단이 조직의 지식으로 축적되고 새로운 기획자도 과거의 의사결정 과정을 이해하기 쉬워집니다.

 

결국 뛰어난 IT 기획자는 데이터를 볼 줄 아는 사람을 넘어 데이터를 이용해 여러 사람의 판단을 하나의 실행 방향으로 연결하고 결과에서 다시 학습할 수 있는 사람이라고 생각합니다.

데이터 기반 의사결정을 이끄는 IT 기획 직무의 핵심 역량 분석 총정리

데이터 기반 의사결정을 이끄는 IT 기획 직무의 핵심 역량 분석을 전체적으로 정리하면 가장 먼저 필요한 것은 문제를 명확하게 정의하는 능력입니다.

 

데이터가 많다고 좋은 의사결정이 자동으로 만들어지는 것은 아닙니다. 어떤 문제가 발생했고 어떤 질문에 답해야 다음 행동을 선택할 수 있는지를 먼저 정해야 필요한 데이터를 찾을 수 있습니다.

 

두 번째는 사업 목표를 측정 가능한 지표로 바꾸는 능력입니다.

 

단순히 방문자와 조회 수처럼 쉽게 확인할 수 있는 숫자만 보는 것이 아니라 서비스가 실제로 해결하려는 문제와 사업 성과를 보여줄 수 있는 핵심 지표를 선정해야 합니다.

 

지표의 계산 기준과 기간, 대상도 명확하게 정의해야 여러 부서가 같은 숫자를 같은 의미로 이해할 수 있습니다.

 

세 번째는 데이터를 해석하는 능력입니다.

 

숫자가 증가하거나 감소했다는 사실만 확인하지 않고 어떤 이용자에게 변화가 나타났는지, 언제부터 발생했는지, 다른 지표와 어떤 관계가 있는지를 살펴봐야 합니다.

 

특히 데이터에서 확인된 현상과 원인에 대한 가설을 구분하는 습관이 중요합니다.

 

네 번째는 분석을 실행으로 연결하는 능력입니다.

 

문제가 발견되면 가능한 원인을 정리하고 영향도와 개발 비용, 이용자 경험 등을 고려해 개선 우선순위를 정합니다.

 

이후 실제 기능이나 정책으로 반영하고 배포가 끝난 뒤 처음 목표로 했던 지표가 개선됐는지 다시 확인해야 합니다.

 

다섯 번째는 협업 역량입니다.

 

IT 기획자가 혼자 모든 분석을 수행할 필요는 없지만 개발자에게 어떤 데이터가 필요한지 설명하고 데이터 담당자에게 분석의 목적을 전달하며 디자이너와 이용자의 행동을 함께 해석할 수 있어야 합니다.

 

이를 위해 데이터가 어떤 구조로 생성되고 수집되는지에 대한 기본적인 이해와 필요한 데이터를 직접 확인할 수 있는 기초적인 활용 능력을 갖추면 실무에서 도움이 됩니다.

 

마지막은 커뮤니케이션과 의사결정 능력입니다.

 

분석 결과를 그대로 보여주는 것만으로는 부족합니다. 무엇이 확인됐고 사업적으로 어떤 의미가 있으며 어떤 선택지가 있는지를 이해하기 쉽게 설명해야 합니다.

 

확인된 사실과 해석, 아직 검증되지 않은 가설을 구분해서 전달하는 것도 중요합니다.

 

결국 데이터 기반 IT 기획의 경쟁력은 분석 도구를 몇 개 사용할 수 있는지로만 결정되지 않습니다.

 

사업의 문제를 데이터로 확인할 수 있는 질문으로 바꾸고 필요한 지표를 설계하며 분석 결과에서 의미를 발견하고 그것을 실제 서비스 개선으로 연결하는 전체 과정이 하나의 역량으로 이어져야 합니다.

 

이런 역량이 쌓이면 IT 기획자는 요청받은 기능을 정리하는 역할을 넘어 무엇을 먼저 만들어야 하는지, 왜 그것이 필요한지, 실제로 효과가 있었는지를 근거를 가지고 설명할 수 있는 의사결정자로 성장할 수 있습니다.

질문 QnA

 

IT 기획 업무를 오래 들여다볼수록 데이터를 잘 활용한다는 말의 의미가 단순하지 않다는 생각이 들었습니다.

 

숫자를 빠르게 찾는 것도 필요하고 분석 도구를 익숙하게 사용하는 것도 도움이 되지만 그것만으로 좋은 기획자가 되는 것은 아니었습니다.

 

오히려 중요한 것은 지금 해결해야 할 문제가 무엇인지 정확하게 설명하고 그 문제를 확인할 수 있는 데이터를 찾은 뒤 결과를 실제 행동으로 연결하는 과정이었습니다.

 

처음부터 복잡한 분석을 하려고 부담을 가질 필요도 없습니다. 현재 담당하고 있는 서비스에서 가장 중요한 지표 몇 가지를 정하고 그 숫자가 왜 변했는지를 꾸준히 확인하는 것부터 시작해도 충분합니다.

 

기능을 하나 개선할 때도 개발이 완료되면 끝이라고 생각하기보다 개선 전 어떤 문제가 있었는지 기록하고 배포 이후 같은 지표를 다시 확인해보는 습관을 들이면 데이터와 기획 업무가 자연스럽게 연결됩니다.

 

무엇보다 데이터는 사람의 경험을 무시하기 위한 도구가 아닙니다. 현장에서 쌓은 경험으로 좋은 가설을 만들고 데이터를 통해 그 가설을 확인하면서 더 나은 판단으로 발전시키는 것이 훨씬 현실적인 활용 방법입니다.

 

결국 좋은 IT 기획자는 숫자를 많이 보여주는 사람이 아니라 복잡한 숫자 속에서 중요한 문제를 발견하고 여러 구성원이 이해할 수 있는 언어로 설명한 뒤 실제 서비스가 더 나은 방향으로 움직이도록 만드는 사람이라고 생각합니다.