회원가입을 하면 원하는 문장을
저장할 수 있어요!
다음
요즘IT를 포함한 많은 글이 이에 대한 장점과 필요성, 조금 더 나아가 데이터를 다루는 이론적인 방법이나 공공기관에서도 적용한 사례 등을 다루고 있습니다. 데이터를 잘 활용해서 더 큰 비즈니스적 임팩트를 만들어 낸다는 것은 멋진 일이지만 이를 이루기 위해 거쳐야 할 난관들이 있기도 합니다. 그중 오늘은 ‘데이터 분석’이라는 과정 중에 가장 먼저 고려해야 하는 “어떤 것을 데이터로 확인하려고 하는가?”에 관한 이야기를 해보려고 합니다.
먼저 비즈니스 흐름과 그 과정에서 데이터가 활용되는 상황을 간단히 설명하겠습니다. 사실 도메인마다, 팀마다 혹은 사람마다 조금씩 다를 수 있기 때문에 하나의 예시 정도로 생각하시면 좋습니다.
보통 (잠재적) 고객이 겪고 있는 문제가 있습니다. 이를 해결하고자 하는 비전을 가지고 창업하고, 이를 해결할 수 있는 솔루션(프로덕트 혹은 서비스)을 통해 고객의 문제를 해결합니다. 성공했다면 임팩트(매출)를 만들게 되는데요.
이때 우리의 솔루션이 고객의 문제를 완전하게 풀어내지 못하거나 미처 인지하지 못했던 새로운 문제가 발생했을 때 솔루션을 지속해서 개선하게 됩니다. 그림으로 표현하면 아래와 같습니다.
이러한 흐름에서 ‘데이터를 통해 일한다’라는 건 우리 솔루션에 혹은 고객에게 어떤 문제가 있는지, 이를 해결하기 위해 어떠한 행동을 우리가 해야 하는지를 결정하는 방법의 하나입니다. (임팩트를 만들어 내는 방법은 너무나 다양하고, 당연히 방법 수만큼이나 결과 또한 다양합니다.)
위 그림을 기준으로 하면 데이터는 솔루션이 임팩트를 더 잘 만들어낼 수 있도록 ‘현재 상황을 확인하는 것’과 ‘개선이 필요한 것을 확인’하는 부분으로 나눠서 생각해볼 수 있습니다. 물론 더 많은 것들이 있습니다.
보통 데이터를 잘 활용하기 위해서 고객의 반응을 확인하곤 합니다. 이때 모든 고객을 만나서 “우리 서비스가 당신의 문제를 잘 해결하고 있나요?”라고 물어볼 수 없기 때문에 ‘고객이 문제를 잘 풀었다면 이러이러한 행동이 나타날 것’이라는 확인되지는 않았지만 현상을 설명하기 위한 가정을 만들게 됩니다.
요즘IT를 예로 들면, 독자들은 ‘트렌디한 IT 이야기를 알고 싶다’라는 문제가 있고, 이를 발행하는 아티클로 해결하고 있습니다. 이때 ‘유익한 글을 쓰면 더 많은 독자가 다른 주변 사람에게 공유를 많이 할 것이다’, ‘적당한 분량과 좋은 내용, 그리고 이미지나 레이아웃 등으로 가독성을 높이면 조회수가 높다’와 같은 내용을 가설로 볼 수 있습니다.
우리가 만드는 많은 프로덕트는 고객이 구매뿐 아니라 공유, 소비, 평가 등 여러 가지 복합적인 활동을 하는 일종의 사회 현상들을 만들어 냅니다. 이러한 활동에는 가격이나 시간, 고객의 개인적인 특성, 프로덕트 내부의 콘텐츠 그리고 미처 생각지도 못한 요인들을 포함하여 많은 요인이 얽혀 있습니다.
앞서 말한 것처럼 우리의 목표는 데이터를 통해 프로덕트의 임팩트(매출)를 더 늘리는 것이며, 어떠한 요인들이 프로덕트를 사용하게 하는지 알아가는 것도 하나의 방법입니다. 이 과정에서 모델링이나 인과관계 등의 어려운 개념이 나오기도 하지만 이를 다루지는 않겠습니다.
그러면 가설을 잘 세워야 하는 이유는 무엇일까요? 만약 ‘어떤 요인이 프로덕트에 영향을 미칠 것이다’와 같은 가설을 잘 만들었다면 이후의 실험을 통해 그 요인의 실제 효과를 추려내는 작업을 거쳐서 프로덕트를 키울 수 있을 것입니다. 하지만 엉뚱한 방향의 가설을 설정했다면 결과 확인은 고사하고 실험을 진행하는 것조차도 어려울 수 있습니다.
최악의 경우, 잘못된 방향으로의 의사결정을 하게 되어 돌이키기 어려운 후회와 반성을 만들어 낼 수도 있습니다. 그렇기 때문에 좋은 가설을 만드는 것은 제한된 리소스를 활용하며 나타나는 시행착오를 줄이는 너무나도 필수적인 단계입니다.
흔히 말하는 도메인 경험, 혹은 문맥이 없는 상황에서 데이터를 해석하는 것은 잘못된 가정과 가설을 만들어낼 가능성이 높습니다. 역설적으로 완전하게 데이터에만 의존하여 의사결정을 하게 되는 경우에도 생길 수 있습니다.
계속 이어지는 요즘IT의 예시입니다. (제 상상이기 때문에 실제와는 전혀 연관 없습니다)
독자들이 얼마나 콘텐츠를 즐기고 있는지 확인하기 위해서 6월 1일부터 첫째 주 동안의 조회수 데이터를 확인했을 때 아래와 같이 결과가 나왔다고 해보겠습니다. (예시와 별도로 데이터는 기술적 오류 없이 정확하게 적재되었고, 쿼리 작업 또한 문제가 없었습니다.)
데이터를 통해 “아, 월요일에는 주말 동안 밀린 업무가 많아 사람들이 많이 읽지 않으니, 콘텐츠 게시 일정을 화요일을 기준으로 조정해야겠다”와 같은 가설을 내릴 수 있습니다. 그러나 만약 ‘6월 첫째 주 월요일이 쉬는 날인 현충일이었다’라는 배경을 알게 되면 다른 의사결정도 고려해보지 않았을까요?
가설의 의미는 앞서 언급했던 것처럼, 사실인지 아닌지 확인하지 않았지만 앞으로 알고자 하는 명제입니다. 그렇기 때문에 사실 좋은 가설과 나쁜 가설이라고 평가하는 것보다는 확인까지의 리소스가 많이 필요한 가설, 혹은 상대적으로 적은 가설로 구분하는 게 괜찮아 보입니다.
불필요한 리소스 낭비를 조금이라도 줄일 수 있는 (좋은) 가설을 만들기 위해 미리 확인하면 좋을 체크리스트 5가지를 소개해 보겠습니다.
‘캐글’을 비롯한 경진대회성 데이터 분석 프로젝트를 진행하다 보면 많이 하는 경험입니다. 바로 “데이터를 뜯어보면 뭐라도 신기한 게 나오겠지”라는 생각으로 데이터를 분석하는 경우입니다.
많은 데이터 직군의 증언에 따르면, 데이터를 확인하면 말 그대로 뭐라도 나오긴 하지만, 그것이 실제로 의미 있는 결과 혹은 액션으로까지 이어지기는 어렵습니다.
물론 데이터 분석에 어느 정도 범위가 적절한지는 정해진 바가 없지만, 목적이 구체적이고 좁은 범위일수록 결론을 내기가 쉽습니다. 반대로 너무 좁으면 분석을 여러 번 나누어서 해야 하는 것도 생각해야 합니다.
예를 들어 ‘좋은 콘텐츠를 정의하는 것이 어떤 요인인지 확인한다’라는 목적과 ‘콘텐츠의 카테고리와 공유하기 기능을 활용하는 것에 길이 혹은 분량이 연관 있는지를 확인한다”라는 2개의 목적이라면 아무래도 뒤의 가설이 더 결론이 나오기 쉬울 것입니다. (개인적으로 아직 익숙하지 않은 방법이지만) 육하원칙에 따라서 목적을 정하는 연습을 하는 것도 꽤 도움이 됩니다.
우리의 프로덕트가 작동하는 과정은 단 하나도 중복되는 것이 없습니다. 대상 고객, 방법과 과정, 고객이 활용하는 시간과 방법 등 여러 요인에 의해 결정되는데, 전부 다른 요인에 따라 발생하는 현상에 대해서도 공통으로 설명할 수 있는 가설인지 확인해야 합니다.
주의할 점으로는 이러한 일반화의 결과가 무조건 사실일 필요는 없습니다. 다수를 대상으로 설명할 수 있으면 좋지만, 그만큼 소수에 해당하는 ‘outlier(잘못 분석된 값)’ 데이터가 있을 수도 있습니다.
예를 들어 외식 도메인이라고 가정해 보겠습니다. ‘배가 고픈 사람은 30분 이내에 식사를 할 것이다’라는 가설을 세웠습니다. 이것이 사실로 확인된다면 식사 준비 시간을 30분 이내로 바꾸어서 많은 고객에게 효과를 낼 수 있을 것입니다. 그렇지만 배가 고프지 않아도 30분 이내에 무언가를 먹는 사람이 있을 수도 있고, 배가 고프지만 30분이 아닌 그 후에도 무언가를 먹는 사람이 있을 수 있습니다.
이처럼 가설을 비틀어 버리는 에러를 있어 보이는 말로 각각 ‘Type 1 / 2 Error’라고 표기하기도 합니다. 그리고 보통 좋은 가설이라면 두 에러의 가짓수가 더 적습니다.
위에서 ‘문맥(컨텍스트)을 이해하지 않는 것은 위험하다’라는 이야기를 했는데요. 반대로 컨텍스트에 너무 의존하게 되는 것 또한 건강하지 못한 현상입니다. 사실 우리는 우리가 인지하던 것과 다른 상황에서의 불편한 감정을 느끼기 때문에(인지부조화, cognitive dissonance) 가설을 만드는 과정에서도 보고 싶은 것만 보려는 상황이 생기기도 합니다.
다행히 다양한 컨텍스트를 가진 사람들과 같이 협업하는 것으로 이러한 것을 어느 정도 방지하고, 객관적인 관점에서 접근할 수 있습니다.
산업과 비즈니스에서는 상대적으로 덜하긴 하지만, 가설을 사실인지 아닌지 확인하기가 어려운 경우도 있습니다. ‘우리 집 고양이는 간식 여러 개 중 츄르를 가장 좋아할 것이다’와 같은 가설은 고양이에게 직접 물어볼 수가 없습니다. 초끈이론과 같이 많은 부분을 설명하지만 검증하는 것이 물리적으로 어려운 경우 역시 확인할 수 있는 가설에 비해서는 좋은 가설이라고 보기에 어렵습니다.
확인이라는 관점에서 조금 더 이야기해보면, 주어진 가설이 꼭 사실이라는 것으로 확인하는 것 외에도 그렇지 않다는 ‘반증’으로 확인하는 것도 좋습니다.
예를 들어 ‘지방의 학생들에 비해 수도권의 학생들이 평균 수학 점수가 더 높을 것이다’라는 가설이 있습니다. 그러나 지방에서 학군이 아주 발달한 도시라면 그렇지 않은 경우도 있을 수 있습니다. 이러한 상황에서 하는 쉬운 실수 중 하나가 ‘지방에서 특정 도시를 제외하곤 수도권의 학생들이 평균 수학 점수가 더 높을 것이다’처럼 가설을 살짝 바꾸는 것입니다.
이를 통해 새로운 인사이트를 만들어 내는 것도 물론 중요합니다. 하지만 내 입맛에 맞는 방식으로 가설을 고쳐서 정보를 얻게 되면 그것이 처음 우리가 풀고자 했던 질문이나 목적에 맞는 답변인지는 별도의 문제라고 생각합니다.
그렇기 때문에 개인적으로는 ‘처음 만든 가설이 틀렸다’라는 것을 인정하는 것 또한 중요합니다. 조금 더 욕심을 낸다면 어떤 부분을 고려하지 못해서, 혹은 가설을 만드는 프로세스에 어떤 개선점이 있는지 기록하고 공유하는 문화를 만들어 갈 수도 있다고 생각하고요. (물론 정말 어려운 길이라고 생각합니다)
앞서 말한 일반화의 관점과 조금 유사하게도 가설은 반복적으로 적용될 수 있어야 합니다. 즉, 고객의 특정 행동을 한번 설명하는 것이 아니라 이후에도 혹은 다른 고객들의 행동에도 적용될 수 있어야 좋은 가설입니다.
그렇지 않고 정말 우연히 발생한 에러에 의한, 다시 볼 가능성이 적은 현상 혹은 극소수의 고객의 행동을 설명하려는 가설이라면? 만드는 것 까진 큰 문제가 없지만 더 많은 사람을 대상으로 하는 가설에 비해서 실험 우선순위가 낮을 수밖에 없습니다.
무엇보다 ‘데이터를 통해 임팩트를 만들어 낸다’라는 관점에서도 좋은 가설은 아닙니다.
성공적인 데이터를 활용한 의사결정에는 좋은 데이터, 적절한 모델링, 분석 기술, 견고한 인프라 등 많은 것들이 필요합니다. 그러나 간과되기 쉬운, ‘어떤 질문을 풀 것인가’에 대한 방향점을 고민한다면 다른 요인들의 활용을 빛나게 할 수 있을 것이라고 확신합니다.
앞서 잠깐 언급한 것처럼 좋은 가설과 나쁜 가설은 없습니다. 다만, 확인하기 비싼 가설과 그렇지 않은 가설, 확인했을 때 의미가 큰 가설, 그렇지 않은 가설 등의 다른 방법으로 나눠볼 수 있다고 생각합니다.
이처럼 어렵고 생각할 것도 많은, 가설을 만들고 실험을 통해 검증하고 실제로 액션을 만들어 반영하는 기나긴 여정은 수없이 많은 고민과 실패를 필요로 할 것입니다. 그럼에도 불구하고 그 끝에 세상을 더 아름답게 만드는 여러분을 응원합니다.
요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
좋아요
댓글
공유
공유
4.7K
