엑셀로는 안 보이는 질문 : 좋은 상품을 기획하기 위한 블루오션 찾기

소개

지난 주까지의 과제를 진행함에 있어서, 편성표를 타임테이블로 정리하는 데까지 왔는데, 표로는 답할 수 없는 질문이 남았습니다. "그래서.. 어느 상품이 많이 포진되어 있는거고.. 어느 상품이 블루오션인거지..? 내가 런칭해야할 상품은 뭐지?" 이번 2주차 강의에서 스터디장이신 지아코모님께서 데이터를 온톨로지(지식그래프)로 바꾸는 방향을 보여주셨고, 이 지점에서 큰 아이디어를 얻었습니다 :)

진행 방법

시작 전 상태

편성표 수집은 잘 굴러가게 됐습니다. 4개 채널에서 시간과 상품명을 가져와 채널 × 시간 타임테이블로 정리합니다.

그런데 표를 계속 보다 보니 한계가 보였습니다.

표는 "언제, 그리고 무엇"에 답합니다. 하지만 편성 판단에 필요한 건 관계입니다. 어떤 상품이 어떤 상품과 경쟁하는지, 어떤 지역·시즌·가격대 조합이 비어 있는지는 행과 열로는 보이지 않습니다.

내가 직접 내린 판단

판단 1 — 그래프가 필요한 이유를 먼저 정하기

"지식그래프로 만들면 멋있겠다"의 단순함이 아니라, 표로 안 되는 게 뭔지부터 정리했습니다.

제가 원한 건 하나였습니다.

자사 × 경쟁사를 지역 · 시즌 · 가격대 축으로 깔았을 때 비어 있는 조합(white space)이 눈에 보이는 것

이게 곧 저같은 MD의 입장에서는 편성 기회니까요. "예쁜 그래프"가 아니라 "결정을 유도하는 그래프"가 목표라는 걸 먼저 명시했습니다.

판단 2 — 온톨로지와 지식그래프를 구분하기

검토하면서 개념 하나를 새로 배웠습니다. 둘은 다른 층이었습니다.

이걸 알고 나니 작업의 성격이 달라 보였습니다.

온톨로지화는 별도 프로젝트가 아니라, 수집 파이프라인의 출력 형식을 스키마에 맞추는 일이었습니다. 편성표를 긁어서 정해진 어휘로 정규화하면, 그 파일 뭉치 자체가 이미 지식그래프입니다.

판단 3 — 화려함보다 검증을 먼저

배포 경로가 두 가지 있었습니다.

목표로 삼은 화면은 경로 B 수준이었습니다. 하지만 A로 먼저 가기로 했습니다.

PoC의 목적은 화려함이 아니라 이 질문에 답하는 것이기 때문입니다.

(그리고.. 지난 주에 뚫기는 했지만 아직 몇몇 경쟁사들이 API가 동적 크롤링으로도 안 뚫리는 부분들이 있기에.. 후...)

당사 데이터+경쟁사 데이터 일부를 통해 작은 프로토타입을 먼저 진행해보는게 맞다고 생각했어요.

이 그래프를 보고 "겨울 · 고가 · 제주" 같은 빈 구간이 실제로 떠오르는가?

Yes면 경로 B로 올릴 가치가 있다는 신호고, No면 애초에 그래프보다 비교표가 나은 문제였다는 뜻입니다.

결과와 배운 점

이번 작업을 하면서 가장 크게 배운 건, 도구는 목적이 아니라 질문에서 시작해야 한다는 점이었습니다. 처음엔 "우와.. 지아코모님 그래프 짱멋있다.. 편성표 저렇게 만들면 어떨까" 정도의 앞선 마음뿐이지만.. ㅋㅋㅋㅋ 정작 붙잡아야 했던 건 "표로는 왜 답이 안 나오는가"였습니다. 편성표를 아무리 잘 정리해도 '언제, 무엇'까지만 보일 뿐, 정작 MD로서 필요한 '무엇과 무엇이 경쟁하고, 어디가 비어 있는가'라는 관계는 행과 열 사이로 새어나가 버린다는 걸 몸으로 느꼈습니다. 결국 화려한 그래프가 아니라 결정을 유도하는 그래프가 목표라는 걸 먼저 못 박고 나니, 이후의 선택들이 훨씬 단단해졌습니다.

개념적으로도 시야가 한 겹 열렸습니다. 온톨로지(TBox)와 지식그래프(ABox)를 구분하게 된 순간, 온톨로지화가 거창한 별도 프로젝트가 아니라 '수집 파이프라인의 출력 형식을 스키마에 맞추는 일'이라는 게 보였습니다. 정해진 어휘로 정규화만 잘 해두면 그 파일 뭉치 자체가 이미 지식그래프라는 깨달음은, 막연히 어렵게만 느껴지던 작업을 손에 잡히는 실무로 바꿔주었습니다. 개념을 정확히 아는 것이 곧 작업 난이도를 낮춘다는 걸 실감했습니다.

마지막으로, 화려함보다 검증을 앞세운 판단을 빠르게 만들어보고 싶어요. 커스텀 force graph(위 비교표의 경로 B)가 최종 그림이라는 걸 알면서도, 먼저 Quartz(경로 A)로 작은 프로토타입을 돌려 "이 그래프를 보고 정말 white space가 떠오르는가"를 확인하는게 많은 기대가 되네요. 아직 일부 경쟁사 API가 안 뚫리는 현실적 제약도 있었지만, 그걸 핑계 삼기보다 가진 데이터로 가설부터 검증하는 게 맞다고 판단했습니다. 완벽한 결과물을 한 번에 만들려는 욕심 대신, "이 방향이 맞는지 먼저 싸게 확인한다"는 태도를 배운 것이 이번 아이디어의 가장 값진 수확이었습니다. 많은 도움 주시는 스터디장님, 그리고 스터디원분들 정말 감사드립니다.