안녕하세요. 오늘의집 유저 인사이트(User Insights)팀 Fred, Rosie, Sungbae입니다.

지난번 "오늘의집은 어떻게 200명의 리서처를 만들었을까"라는 글에서는 더 많은 동료가 고객의 이야기를 직접 듣게 만든 과정을 소개했습니다. 이제 리서치는 더 이상 리서처만의 일이 아니게 됐고, 한 해 동안 정말 많은 고객의 목소리가 조직 안으로 들어왔어요. 그렇게 한참을 달리고 나니 새로운 고민이 생겼습니다.

어느 날, 슬랙에 올라온 질문 하나. "이사를 앞둔 고객에게 가장 효과적인 콘텐츠가 무엇인가요?"

예전 같으면 누군가 리포트를 뒤지고, ‘그거 어디서 봤더라…’ 하며 기억을 더듬었을 질문이에요. 하지만 지금은 슬랙에서 ‘@Ureka(유레카)’를 부르면 몇 초 만에 근거 있는 답이 돌아옵니다. 이런 답이 어떻게 이렇게 쉽게 나오는지, 그 과정을 풀어볼게요.

계속 쌓이는 자료, 쉽게 쓰이지 못한 유저 인사이트

매달 리서치 리포트가 쌓였어요. 인터뷰 노트와 데이터 분석 결과도 계속 더해졌고요. 그런데 막상 누군가 "예전에 이런 거 들여다본 적 있지 않아요?"라고 물으면 노션을 뒤지고 슬랙을 검색하다가 결국 "그때 그거 누가 했더라?"하며 기억에 의존해야 했어요. 키워드로 찾아도 비슷한 제목의 문서만 잔뜩 나올 뿐, 정작 필요한 그 한 줄은 다른 리포트 깊숙한 곳에 묻혀 있곤 했고요.

더 큰 벽은 그 다음이었어요. 정말 중요한 질문일수록 리포트 하나로는 답이 나오지 않거든요. 커머스에서 발견한 패턴, 콘텐츠에서 본 행동, 인테리어 시공 서비스에서 확인한 이탈처럼 서로 다른 맥락의 인사이트를 함께 보고 하나의 답으로 이어야 하는데, 그 연결도 누군가의 기억과 경험에 기대어 이루어지고 있었어요. 쌓인 리포트는 많은데 그걸 이어서 꺼내 쓸 방법이 없었던 거예요.

단순한 검색으로도, 사내 문서를 LLM에 통째로 넣는 방식으로도 이 ‘연결’은 쉽게 풀리지 않았어요. 비슷한 문장은 찾아줘도 어떤 조건과 상황에서 나온 결과인지, 서로 어떤 관계에 있는지 잡아내지는 못했습니다. 그래서 저희는 접근을 달리했어요. 리포트를 더 잘 쌓는 게 아니라 조직이 함께 꺼내 쓸 수 있는 구조로 만들기로 했습니다. 특정한 사람의 경험에만 머물던 인사이트를 누구나 평소 쓰는 언어로 질문하고 필요한 답을 얻을 수 있도록요. 이를 위해 논리 구조를 실제 시스템으로 옮기고 그 흐름을 세 단계로 나누어 구현했습니다.

[ 넣기 ] 인사이트를 '문장'이 아니라 '논리'로

처음 마주한 질문은 의외로 근본적이었어요. “분석 결과를 어떻게 저장할 것인가?”

보통 리서치·데이터 자료들은 문서로 저장해요. 발견한 인사이트를 문서로 적고, 태그를 달고, 폴더에 넣습니다. 이렇게 저장한 문서는 검색할 수 있습니다. 하지만 그 문장이 다른 인사이트와 어떤 관계에 있는지, 어떤 조건에서 성립하는지, 여기서 무엇을 해야 하는지는 어디에도 저장되지 않아요. 문장은 남지만 맥락은 증발되는 거예요. 그래서 저희는 모든 인사이트를 하나의 패턴으로 표현하기로 했습니다.

💡 "[ 어떤 고객 ]이 [ 어떤 상황 ]에 있을 때 → [ 어떤 행동·감정·결과 ]로 이어진다."

이렇게 정리하면 조건과 결과가 분리됩니다. 비슷한 조건의 인사이트를 모아 비교할 수 있고, 두 인사이트를 이어 새로운 질문을 만들 수도 있어요.

이 표현 방식은 1차 논리(First-Order Logic, FOL)의 형식을 빌려왔어요. "모든 고객 x에 대해 a가 어떤 조건을 만족하면, 는 어떤 행동을 한다"와 같이 읽을 수 있게 만들면, 인사이트는 단순한 문장이 아니라, 조건과 결과를 가진 하나의 주장 단위(Claim)로 다뤄집니다.

그래프의 중심에 Claim을 두었습니다. 그리고 각 Claim을 네 가지 뼈대로 나눴어요. 누구인지(Customer) · 어떤 상황인지(Context) · 무엇을 했고 어떻게 느꼈는지(Behavior) · 그걸 어떻게 아는지(Evidence). Behavior에는 그 행동이 이어진 결과(Outcome)를 함께 다뤘고, Evidence에는 근거의 종류, 출처가 된 리서치, 데이터를 모은 시점, 표본 크기와 신뢰 등을 함께 담았어요.

물론 이 구조가 한 번에 완성된 건 아니었어요. 인사이트를 옮겨 넣다 보면 예외가 계속 나왔고, 그때마다 규칙을 조금씩 고쳐야 했습니다. 예를 들어 주어는 늘 ‘고객’으로 두기로 했고, ‘안 한다(의도)’와 ‘못 한다(구조의 한계)’를 엄격히 구분하기로 했어요. 같은 뜻을 가진 표현은 하나의 표준 용어로 모으고, 한 문장 안에 서로 다른 고객이 섞여 있으면 나눠 담는 식으로요.

이 과정을 거치며 알게 된 건 인사이트를 구조화하는 일이 사실 ‘정제의 과정’이라는 점이었습니다. 그래서 규칙도 완성된 정답이 아니라 계속 고쳐 쓰는, 살아있는 규칙으로 두었습니다.

새로 쌓이는 인사이트도 같은 방식으로 넣습니다. Ureka 스킬을 활용해 자연어로 된 분석 내용이 어느 섹션에 해당하는지 감지하고, 기존 인사이트와 충돌하는 부분은 없는지 확인해요. 이후 LLM이 내용을 네 가지 뼈대(Customer, Context, Behavior, Evidence)로 자동으로 나눕니다. 추출된 값은 먼저 용어 사전과 대조해 표기를 정리해요. 같은 의미인데 조금 다르게 적힌 값은 하나의 기준값으로 합칩니다. 이후 설명이 너무 짧거나, 꼭 필요한 축이 비어 있는 인사이트는 품질 기준을 통과하지 못하도록 걸러냅니다. 이렇게 정리된 데이터는 DB에 넣을 수 있는 파일로 변환되고, 실제 반영 전에는 담당자가 한 번 더 확인하도록 했어요.

[ 저장하기 ] 흩어져 있던 인사이트를 하나의 맥락으로

검수를 통과한 인사이트는 Neo4j(관계를 중심으로 데이터를 저장하는 그래프 데이터베이스)에 저장됩니다. 하나의 인사이트는 앞에서 정의한 네 가지 뼈대에 맞춰 각각의 정보 단위인 노드(Node)로 저장되고, 고객의 역할이나 라이프 이벤트, 행동, 결과, 감정 같은 차원 노드와도 이어져요. 이렇게 저장하면 모든 인사이트는 더 이상 개별 문서 안에 흩어져 있지 않고 하나의 관계망으로 연결됩니다.

이 구조가 진짜 힘을 발휘한 건, 따로 떨어져있던 인사이트들이 하나의 고객 맥락 안에서 처음으로 연결됐을 때였어요. 오늘의집의 사업 영역은 커머스, 시공, 이사, 렌탈, 인터넷 설치까지 서로 다른 성격을 띠고 있어요.  보통 이 영역들은 각자 다른 팀이 분석하고 다른 리포트에 담깁니다. 하지만 한 명의 '이사하는 고객'은 이 영역들을 전부 관통해요. 집을 구하고, 가구를 구매하고, 시공 업체를 알아보고, 이사 서비스를 고르고, 가전을 렌탈하고, 인터넷을 새로 설치하죠.

[ 꺼내 쓰기 ] 질문하면 근거가 돌아오도록

구조화된 인사이트가 실제 업무에서 쓰이려면, 사람들이 평소 쓰는 말로 질문하고 필요한 답을 바로 얻을 수 있어야 했어요. 그래서 마지막 단계에서는 이 관계망에 직접 질문하고, 근거가 담긴 답을 받을 수 있는 흐름을 만들었습니다.

먼저,  질문이 들어오면 인사이트를 찾는 질문인지, 일반적인 대화인지, 혹은 답할 수 없는 범위의 질문인지 분류해요. 인사이트 검색 질문이라면 증거 탐색, 세그먼트 비교, 원인 추적, 주제 요약 등 어느 유형인지 함께 정합니다. 검색 결과가 너무 적을 땐 키워드를 넓혀 스스로 한두 번 더 시도하고, 그래도 마땅한 근거를 찾기 어렵다면 억지로 답하지 않고 솔직하게 "범위 밖"으로 처리합니다. 예를 들어 누군가 슬랙에서 이렇게 질문했다고 가정해볼게요.

"이사를 앞둔 고객에게 어떤 콘텐츠가 효과적일까?"

이 질문은 인사이트 검색 질문으로 분류돼요. 시스템은 여기서 이사·콘텐츠·레퍼런스 같은 키워드와 조건을 뽑아냅니다. 그리고 키워드 검색, 그래프 역추적, 관계 확장을 결합한 하이브리드 검색(hybrid retrieval)을 수행해요.

하이브리드 검색은 아래 세 가지 방식을 동시에 실행합니다.

• 텍스트 검색 : 질의를 바탕으로 제목이나 설명을 전문으로 찾습니다. 이때 한국어 질문은 오늘의집 안에서 쓰는 도메인 용어 기준에 맞춰 영어 키워드로도 변환합니다. 검색 결과가 단순히 단어가 많이 맞는 문서에 쏠리지 않도록, 질문 맥락과 맞는 인사이트가 우선 나오게 조정합니다.
• 그래프 역추적 : 그래프를 따라가며 같은 차원을 공유하는 인사이트를 모읍니다. 예를 들어 라이프 이벤트가 ‘이사’이거나, 행동이 ‘레퍼런스 수집’인 인사이트를 함께 보는 식이에요. 질문과 맞닿은 차원이 많을수록 더 중요한 결과로 판단합니다.
• 관계 확장 : 질문에 직접 들어간 단어가 없더라도 연결된 이웃 인사이트까지 함께 살펴봅니다. 다만 질문 유형에 따라 확장 범위는 다르게 가져가요. 근거를 찾는 질문은 좁고 정확하게, 원인을 추적하는 질문은 조금 더 넓게 탐색합니다.

이렇게 세 경로에서 모은 결과에는 각각 어떤 방식으로 발견됐는지 출처 태그를 붙입니다. 이후 중복을 제거하고, 각 인사이트에 고객·상황·행동·근거 정보를 함께 붙여 LLM에 전달해요. 단순히 문장 몇 개를 넘기는 것이 아니라, 답을 만들 수 있는 맥락까지 함께 넘기는 방식입니다. 그렇게 돌아오는 답은 이런 모습입니다.

주요 주장에는 근거 번호가 붙고, 흩어져 있던 인사이트는 ‘이사 → 제품 탐색 → 공간 레퍼런스 → 이사/청소/설치 업체 → 콘텐츠 제공’이라는 하나의 흐름으로 엮입니다. 답변은 확인된 인사이트를 기준으로 구성되기 때문에, 아직 근거가 부족한 부분은 추측하지 않고 모르는 내용으로 표시해요.

이렇게 슬랙에서 바로 질문하고 답을 확인할 수 있을 뿐 아니라, 같은 LangGraph* 기반 에이전트를 Ureka MCP*에도 연결해 다양한 업무 환경에서 활용할 수 있도록 만들었어요.

* LangGraph : 여러 단계의 AI 작업 흐름을 구성하는 프레임워크

*MCP : 외부 도구와 데이터를 연결해 활용할 수 있게 하는 연결 방식

왜 '그냥 사내 GPT'가 아니라 그래프였을까

여기서 한 가지 짚고 넘어가야 할 지점이 있어요. ‘유레카’는 단순히 사내 문서를 찾아 답해주는 ‘챗봇’과 무엇이 다를까요?

일반적인 RAG(Retrieval-Augmented Generation, 검색 증강 생성)방식은 사용자의 질문과 의미가 비슷한 문서를 찾고, 그 문서를 LLM에 넘겨 답변을 만들어요. 빠르게 시작하기 좋고, 문서 기반 질의응답에는 충분히 유용한 방식이에요. 하지만 저희가 다루고 싶었던 인사이트 질문에는 조금 다른 어려움이 있었습니다.

가장 큰 문제는 조건과 결과가 쉽게 섞인다는 점이었어요. 예를 들어 “이사 고객”을 검색하면 “이사를 앞두고 있다”처럼 고객의 상황을 설명하는 문장도 나오고, “공간 레퍼런스를 모은다”처럼 그 상황에서 이어진 행동도 나옵니다. 때로는 “이사 시장 규모”처럼 단순한 배경 정보도 함께 검색돼요.

사람이 읽으면 이 차이를 어느 정도 구분할 수 있지만, 단순 유사도 검색만으로는 이 문장이 조건인지, 행동인지, 결과인지 안정적으로 구분하기 어렵습니다. 결국 LLM은 비슷해 보이는 문장들을 받아 답을 만들 수는 있지만, 그 답이 어떤 맥락의 근거에서 나온 것인지까지 명확하게 따라가기는 어려웠어요.

더 중요한 점은 우리가 자주 묻는 인사이트 질문이 단순히 "비슷한 문서를 찾아줘"에 머무르지 않는다는 것이었어요. 예를 들어 "이사 전 고객에게 공간 레퍼런스를 먼저 보여줘야 할까, 구매 가이드를 먼저 보여줘야 할까?"라는 질문은 비슷한 문서 몇 개만으로 답하기 어렵습니다. 이사 전후의 탐색 행동, 구매 단계, 콘텐츠 접점이 어떤 순서로 이어지는지를 함께 봐야 했어요.

앞서 인사이트를 조건과 결과로 나누고, 서로의 관계까지 그래프로 저장해둔 이유가 여기에 있습니다. 유레카는 질문이 들어왔을 때 문장 유사도만 보지 않습니다. 질문에 담긴 조건과 행동이 그래프 안에서 어떻게 이어지는지 함께 탐색해요. 예를 들어 이사라는 조건에서 콘텐츠 탐색, 레퍼런스 수집, 제품 구매, 설치 서비스 탐색으로 이어지는 흐름을 따라가며 관련 인사이트를 찾아옵니다.

그러면 답변에 포함되는 정보도 달라져요. 검색된 인사이트를 요약하는 데서 그치지 않고, 여러 인사이트 사이에서 드러나는 패턴까지 확인할 수 있어요.

• 행동 체인 : 이사 전에는 공간 레퍼런스를 모으고 이후 가구·가전 구매와 설치 서비스 탐색으로 이어지는 흐름
• 세그먼트 집중 : 특정 질문에서 반복적으로 등장하는 고객군이나 구매 단계
• 상반 패턴 : 같은 이사 고객 안에서도 스스로 비교하려는 고객과 추천을 기다리는 고객이 갈리는 지점

이런 관계들은 검색된 인사이트 어디에도 문장 그대로 적혀 있지 않아요. 그래프의 연결을 따라가야만 드러나는 정보예요. 벡터 유사도가 비슷한 문장을 찾아오는 데 강하다면, GraphRAG는 인사이트 사이의 연결을 탐색해 문장 뒤에 있는 관계를 드러내는 데 강점이 있었어요.

하지만 그래프를 쓴다고 해서 검색 문제가 모두 끝나는 건 아니었습니다. 실제 질문은 늘 경계가 흐릿했거든요. 예를 들어 “시공 신청이 왜 저조할까?”라는 질문에는 시공 맥락의 인사이트가 필요합니다. 그런데 단순히 “서비스 신뢰”라는 조건만 따라가면 이사 서비스 인사이트까지 함께 섞일 수 있어요. 반대로 “신규 서비스 인지”를 물을 때는 범위를 너무 좁게 잡으면 꼭 봐야 할 인사이트가 빠질 수도 있고요.

그래서 질문 유형별로 검색 기준을 따로 만들었습니다. 내부적으로는 이런 기준을 검색 가드레일(retrieval guardrails)로 관리했어요. 어떤 질문은 특정 상황 안에서만 찾고, 어떤 질문은 특정 화면이나 행동만 보도록 범위를 정했습니다. 자주 쓰는 질문 묶음에는 “반드시 포함돼야 하는 인사이트”와 “섞이면 안 되는 인사이트”도 정해두고, 검색 결과가 그 기준을 통과하는지 점검했습니다. 답변을 검증하기 전에 답변의 재료가 되는 검색 결과부터 흔들리지 않게 만든 거예요.

그다음 LLM은 이렇게 모은 근거와 그래프에서 확인한 패턴을 종합해 답변합니다. 이때 LLM은 빈 문서 더미에서 그럴듯한 답을 만들어내기보다, 시스템 안에 구조화된 근거와 그래프에서 확인한 패턴을 바탕으로 답을 설명하는 역할에 가까워요.

답변에서도 직접 확인된 근거와 추론한 패턴을 구분했어요. 검색된 인사이트는 근거로 인용하고 그래프를 따라 읽어낸 연결은 "~로 이어지는 패턴이 관찰됩니다"처럼 표현했고요. 마지막으로 답변에 붙은 인용이 실제 근거와 맞는지 다시 확인했습니다.

결국 유레카에서 중요한 건 답을 그럴듯하게 만드는 것이 아니라 검색된 근거와 답변, 인용이 끝까지 맞물리게 하는 일이었어요. 그래서 검색 기준을 세우는 것에서 끝내지 않고, 답변 이후에도 근거 없는 문장과 어긋난 인용을 점검하는 검증 단계를 함께 두었습니다.

운영하고 테스트하며 배운 것들

물론 한 번에 매끄럽게 되진 않았습니다. 사람들이 던지는 질문은 상상했던 것처럼 깔끔하지 않았거든요. 막연하게 묻기도 하고 꼬리질문을 이어가기도 하고, 때로는 저희가 아직 답을 가지고 있지 않은 걸 묻기도 했습니다.

'믿을 수 있는 답'을 주려면 이렇게 다듬어지지 않은 질문들을 어떻게 받아낼지부터 고민해야 했어요.

• 모호한 질문은 되짚어 다시 찾아본다 : 넓게 던진 질문에는 첫 검색이 비기 쉬워요. 그럴 땐 질문을 다른 각도로 다시 해석해 한 번 더 찾아봅니다. "혹시 이런 뜻이었을까?" 하고요. 사람이 키워드를 정확히 골라줄 거라 기대하기 보다 시스템이 먼저 질문의 범위를 좁혀 들어가는 거예요.
• 대화의 맥락을 기억한다 : 한 번에 끝나는 질문은 드물어요. 답을 보고 "그럼 그건 왜 그런데?" 하고 이어 묻는 게 자연스럽죠. 그래서 슬랙 스레드에서 이어지는 질문도 앞선 대화를 기억해 ‘지금 무엇을 묻는 건지’ 그 맥락 안에서 이해하게 했어요.
• 모르는 건 모른다고 한다 : 다시 찾아봐도 마땅한 인사이트가 없으면 그럴듯하게 지어내는 대신 "이건 아직 담겨 있지 않아요"라고 답하게 했습니다. 사실 이 부분에 가장 공을 들였어요. 정성 리서치를 다루는 만큼, 없는 답을 만들어내는 것보다 솔직하게 공백을 드러내는 편이 훨씬 낫다고 봤거든요. 신뢰는 잘 답할 때만큼이나, 모를 때 어떻게 행동하느냐에서도 갈리니까요.

질문을 잘 받아내는 것만큼이나 운영 중에도 결과가 흔들리지 않게 만드는 일도 중요했어요. 같은 인사이트가 여러 번 들어와도 그래프가 같은 상태로 정리되도록 만들었고, 데이터를 다시 처리하더라도 답변의 기반이 흔들리지 않게 했습니다.

무엇보다 인사이트에도 유효기간이 있다는 점을 잊지 않으려 했어요. 몇 년 전 분석이 지금도 맞다는 보장은 없으니까요. 모든 인사이트에 언제, 어떤 데이터로 발견했는지를 함께 기록했고, 시간이 지난 인사이트는 다시 검토 대상으로 삼았습니다. 인사이트는 쌓는 것만큼이나 관리하는 것이 중요하다는 걸 만들면서 배웠어요.

구조가 있어야 인사이트가 흐른다

저희는 여전히 이 시스템을 만들어가는 중입니다. 완성된 무언가를 자랑하려는 게 아니라, 방향이 맞다고 믿으면서 계속 다듬고 있어요.

인사이트는 발견하는 순간이 아니라, 다음 의사결정에 연결되는 순간에 더 큰 가치가 생겨요. 그리고 그 연결을 사람의 기억에만 맡겨두면 오래 지속되기 어려워요. 누군가의 머릿속에 있던 인사이트를 조직이 함께 꺼내 쓰려면, 그것이 흐를 수 있는 구조가 필요했습니다.

지난번에 저희가 200명의 동료를 리서처로 만드는 과정을 이야기했다면, 그들이 만나고 발견한 고객의 이야기가 조직 안에서 계속 살아 움직이도록 만드는 과정을 이야기하고 싶었습니다. 고객의 이야기가 한 사람의 기억에 머무르지 않고, 조직 전체의 자산이 될 수 있도록요. 유저 인사이트팀은 오늘의집의 고객 이해를 데이터와 리서치로 연결하는 일을 합니다. 이 과정이 궁금하시다면 언제든 편하게 이야기 나눠요.