Ureka 제작기: 인사이트는 어떻게 조직의 자산이 될까
URL: https://www.bucketplace.com/post/2026-07-08-ureka-%EC%A0%9C%EC%9E%91%EA%B8%B0-%EC%9D%B8%EC%82%AC%EC%9D%B4%ED%8A%B8%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%A1%B0%EC%A7%81%EC%9D%98-%EC%9E%90%EC%82%B0%EC%9D%B4-%EB%90%A0%EA%B9%8C/
Captured: 2026-07-11 09:30 KST
Fetch method: ultimate-fetcher --json via Jina.
Summary
오늘의집 User Insights팀은 리서치 리포트와 데이터 분석 결과가 계속 쌓이지만 실제 질문 앞에서는 잘 꺼내 쓰이지 못하는 문제를 해결하기 위해 Ureka를 만들었다. 이전 글에서 더 많은 동료가 고객의 이야기를 직접 듣게 만든 과정을 다뤘다면, 이번 글은 그렇게 쌓인 인사이트를 조직이 다시 사용할 수 있는 자산으로 바꾸는 방법을 설명한다.
문제는 단순 검색이 아니었다. “이사를 앞둔 고객에게 가장 효과적인 콘텐츠가 무엇인가요?” 같은 질문은 하나의 리포트만으로 답하기 어렵다. 커머스, 콘텐츠, 시공 서비스 등 서로 다른 맥락의 인사이트를 연결해야 한다. 키워드 검색은 문장을 찾아주지만, 어떤 조건에서 나온 발견인지와 다른 발견과 어떤 관계가 있는지는 잡아내지 못했다.
Ureka의 접근은 리포트를 더 많이 쌓는 것이 아니라, 인사이트를 조직이 함께 꺼내 쓸 수 있는 구조로 바꾸는 것이다. 핵심은 인사이트를 문장이나 문서가 아니라 논리 단위로 저장하고, 출처와 맥락을 유지하며, Slack에서 자연어 질문으로 꺼내 쓰게 만드는 흐름이다.
Problem: 쌓이지만 연결되지 않는 리서치 자산
매달 리서치 리포트, 인터뷰 노트, 데이터 분석 결과가 쌓였다. 하지만 실제 업무 질문이 나오면 사람들은 Notion과 Slack을 뒤지고, 결국 누가 어떤 리서치를 했는지 기억에 의존했다. 비슷한 제목의 문서는 많지만 필요한 한 줄은 문서 깊숙이 묻혀 있었다.
더 큰 문제는 중요한 질문일수록 단일 리포트로 답이 나오지 않는다는 점이다. 서로 다른 도메인에서 나온 행동 패턴과 조건을 함께 엮어야 하는데, 그 연결은 특정 연구자의 기억과 경험에 의존했다. 조직 지식처럼 보이지만 실제로는 개인의 기억에 머무르는 상태였다.
Design principle: 문장이 아니라 논리로 저장하기
Ureka는 분석 결과를 단순 문서로 저장하지 않는다. 인사이트를 근거, 조건, 맥락, 관계가 있는 논리 구조로 바꾸려 한다. 문서의 제목이나 키워드가 아니라, 어떤 상황에서 어떤 고객 행동이 관찰됐고 어떤 근거가 있는지를 query 가능한 단위로 저장한다.
이 접근은 RAG를 단순 문서 검색으로 쓰는 방식과 다르다. 리포트를 통째로 LLM에 넣거나 비슷한 문장을 찾는 것만으로는 인사이트 간 관계를 만들 수 없다. 조직이 재사용하려면 발견의 단위, 조건, 증거, 연결이 보존되어야 한다.
System flow
글은 인사이트가 들어가서 답으로 나오기까지의 흐름을 세 단계로 설명한다.
- 넣기: 리서치와 분석 결과를 문장 덩어리가 아니라 논리 구조로 변환한다.
- 잇기: 서로 다른 리포트의 발견을 연결해 조직이 공유할 수 있는 knowledge structure를 만든다.
- 꺼내기: Slack에서
@Ureka를 호출해 자연어 질문을 던지면, 근거 있는 답변을 몇 초 안에 받는다.
Why Slack matters
Ureka가 Slack에 들어간 점이 중요하다. 리서치 저장소가 별도 도구 안에만 있으면 사람들은 질문이 생긴 순간 다시 검색하고 정리해야 한다. 반대로 조직이 이미 대화하는 공간에서 질문할 수 있으면, 인사이트는 repository가 아니라 workflow 안의 대화 상대가 된다.
이것은 리서처의 일을 대체한다기보다, 반복되는 탐색과 기억 의존을 줄여준다. 리서처는 더 깊은 해석과 새로운 질문 설계에 집중하고, 조직 구성원은 이전 인사이트를 더 쉽게 호출할 수 있다.
Operational meaning
Ureka는 UX research repository의 다음 단계를 보여준다. 과거의 repository는 문서를 저장하고 태그를 붙이는 데 집중했다. 그러나 조직이 실제로 필요한 것은 문서 위치가 아니라 질문에 답할 수 있는 근거 있는 연결이다. 따라서 insight system은 검색 엔진이 아니라 조직의 reasoning interface에 가까워져야 한다.
Henry의 NPS 분석 맥락에서도 이 점이 중요하다. NPS, 주문 KPI, 고객 행동, 세그먼트, 여정 단계가 서로 다른 분석 단위로 흩어져 있을 때, 단순 문서 검색은 ecological fallacy나 단위 혼동을 막아주지 못한다. 인사이트를 조직 자산으로 만들려면 각 발견의 분석 단위와 조건이 함께 보존되어야 한다.
Key takeaways
- 리포트가 많아지는 것과 인사이트가 자산이 되는 것은 다르다.
- 중요한 업무 질문은 여러 리포트와 맥락을 연결해야 답할 수 있다.
- 인사이트는 문장보다 논리 단위, 조건, 근거, 관계로 저장되어야 한다.
- Slack 같은 실제 업무 채널에 붙을 때 지식 저장소는 workflow 일부가 된다.
- Research repository의 목표는 검색이 아니라 근거 있는 재사용과 조직 기억의 외부화다.