모요 AI 분석 어시스턴트 모아이(MOAI) 이야기 1편 : 분석 기반 다지기

들어가며

"지난주 신규 가입자 수 알려줘." "이번 달 CRM 캠페인 성과 요약해줘."

요즘 모요에선 이런 질문을 채팅창에 치면 바로 답이 돌아와요. 분석가가 아니어도, 심지어 새벽에 문득 궁금해져도요. 실제로 새벽에 모아이한테 물어봤다는 동료 이야기도 들었거든요. 😄

모아이(MOAI) 는 모요 구성원 누구나 데이터를 자연어로 꺼내볼 수 있는 AI 분석 어시스턴트예요.

그런데 이게 가능해지기까지, 저희는 눈에 보이지 않는 기반부터 다시 쌓아야 했어요. "이 숫자 믿어도 돼?"라는 질문에 자신 있게 답할 수 있어야, 그 위에 AI를 얹을 수 있으니까요.

이 글은 그 기반을 다진 이야기예요. 데이터를 더 잘 쓰기 위해, 먼저 데이터를 더 잘 만들어야 했던 이유부터 시작해볼게요.

분석계, 왜 정비가 필요했나요?

분석계 테이블이 늘어나다 보면, 규모와 상관없이 공통적으로 생기는 문제가 크게 두 가지 있어요.

첫 번째는 '기준의 불투명성'이에요. 테이블마다 집계 기준이 조금씩 다른데, 그게 어디에도 명시되어 있지 않다는 거죠. 결국 그 테이블을 만든 사람만 히스토리를 알고, 그 사람이 없으면 로직을 다시 뜯어봐야 하는 상황이 생겨요.

두 번째는 '관리되지 않는 의존성'이에요. 여기서 의존성은 상위 테이블과, 그 테이블을 참조하는 하위 테이블 사이의 관계를 말해요. 한 테이블의 로직을 수정하면 그 테이블을 참조하는 하위 테이블(마트·집계 테이블 등)도 함께 수정되어야 하는데, 이 부분을 놓치면 조용히 어긋나 버리곤 했거든요.

예를 들어 볼게요. 개통 상태를 판단하는 기준이 상위 테이블에서 한 번 바뀌었다고 해봅시다. 그런데 이를 참조하는 하위 KPI 테이블이 예전 기준을 그대로 쓰고 있으면, 대시보드에 뜨는 "이번 달 개통 건수"가 실제와 조용히 어긋나기 시작해요. 문제는 이 숫자가 CRM 예산 배분이나 캠페인 성과 판단의 근거가 된다는 점이에요. 틀린 숫자 위에서 내린 결정은, 한참 뒤에 "어, 이 숫자 이상한데?" 하고 발견될 때까지 되돌리기 어렵죠.

이러한 문제는 데이터가 늘어날수록 점점 커질 게 뻔했어요.

dbt로 분석계 기반 다시 세우기

저희가 선택한 도구는 dbt(data build tool) 였습니다.

dbt는 단순히 SQL을 실행하는 도구가 아니에요. 테이블 간 위계와 의존성을 명시적으로 관리하고, 컬럼마다 메타데이터를 붙이고, 테스트 코드로 데이터 품질을 검증할 수 있는 프레임워크예요.

저희가 한 건 크게 세 가지였습니다.

① 테이블 위계 정리

기존에 평평하게 쌓여있던 마트 로직을 레이어별로 나누고, 네이밍 컨벤션을 통일했어요. 어떤 테이블이 어떤 테이블 위에 있는지, 한눈에 볼 수 있게 됐습니다.

② 메타데이터 명시

테이블과 컬럼에 설명을 붙였어요. "이 컬럼이 뭘 의미하는지"를 코드가 아닌 문서로 남기는 작업이었죠. 더 이상 만든 사람에게 직접 물어보지 않아도 되는 구조가 됐습니다.

③ 테스트 코드 도입

null 체크, 유니크 검증, 참조 무결성 등 기본적인 데이터 품질 테스트를 파이프라인에 붙였어요. 조용히 깨지는 걸 막기 위한 안전망이었습니다.

1models:
2  - name: dim_user
3  description: |
4    사용자 마스터 테이블
5    - 사용자 기본 정보 및 마케팅 동의 여부
6  meta:
7    owner: 이형준
8    business_refresh_cadence: event-driven
9  columns:
10    - name: user_id
11      description: "사용자 PK"
12      tests:
13        - unique
14        - not_null
15    - name: ci
16      description: "본인 인증 CI (Connecting Information)"
17    - name: email
18      description: "이메일 주소"
19    - name: kakao_id
20      description: "카카오 ID"
21    - name: referral_code
22      description: "레퍼럴 코드"
23    - name: gender
24      description: "성별"
25      tests:
26        - not_null
27        - accepted_values:
28            values: ['male', 'female']

1models:
2  - name: dim_user
3  description: |
4    사용자 마스터 테이블
5    - 사용자 기본 정보 및 마케팅 동의 여부
6  meta:
7    owner: 이형준
8    business_refresh_cadence: event-driven
9  columns:
10    - name: user_id
11      description: "사용자 PK"
12      tests:
13        - unique
14        - not_null
15    - name: ci
16      description: "본인 인증 CI (Connecting Information)"
17    - name: email
18      description: "이메일 주소"
19    - name: kakao_id
20      description: "카카오 ID"
21    - name: referral_code
22      description: "레퍼럴 코드"
23    - name: gender
24      description: "성별"
25      tests:
26        - not_null
27        - accepted_values:
28            values: ['male', 'female']

데이터 챕터 구성원 모두가 함께 달려들어서, 약 130개의 기존 테이블을 1~2분기에 걸쳐 마이그레이션했어요. 쉽진 않았지만, 이걸 해두지 않으면 그 위에 무엇도 얹기 어렵다는 걸 알았기 때문에 가장 먼저 해결했어요.

그래서, 모아이(moai)

기반이 어느 정도 갖춰지자 자연스럽게 다음 질문이 나왔어요.

"이렇게 잘 정리된 데이터를, 개발자가 아닌 분들도 의사결정이 필요한 시기에 꺼내볼 수 있으면 어떨까?"

사실 이 질문은 처음부터 저희 머릿속에 있었어요. AI 분석 어시스턴트를 만들고 싶었기 때문에, 기반부터 손댄 거였으니까요. AI 분석 어시스턴트는 믿을 수 있는 데이터 위에서만 가능한 일이었고, 그 조건이 갖춰졌다고 판단되자 본격적으로 모아이 개발을 시작했습니다.

전문가 수준의 분석을 위한 knowledge 레이어

dbt로 데이터 구조를 잡았지만, 그 다음 과제가 있었어요. SQL을 정확하게 짜는 것과, 그 SQL이 진짜 비즈니스 맥락에 맞는 답을 내는 건 다른 문제거든요.

"이번 달 CRM 성과 알려줘"라는 질문에 숫자를 뽑아내는 건 어렵지 않아요. 하지만 CRM 팀이 실제로 보는 기준인 CPA 목표치, 캠페인 분류 기준, 예산 범위까지 반영한 답을 내려면 AI가 그 맥락을 알고 있어야 해요.

그래서 저희는 knowledge 레이어를 별도로 설계했어요. dbt가 "데이터를 어떻게 만드는지"를 담는다면, knowledge 레이어는 "데이터를 어떻게 읽어야 하는지"를 담아요.

구체적으로는 도메인별 .md 파일로 구성돼 있어요.

• business-kpi.md — 핸드폰·인터넷·요금제의 개통/접수 KPI 기준과 목표 컬럼 매핑
• crm-dr-kpi.md — CRM 팀이 매일 보는 CPA 목표치, 예산, 캠페인 분류 기준
• finance.md — 영업수익, 영업이익, 당기순이익 등 계정 레벨 계층 구조와 분석 패턴
• metric-definitions.md — 활성 유저, 매출, ROAS 등 핵심 지표 정의
• glossary.md — 도메인 용어 사전과 자주 헷갈리는 표현 정리

어떤 테이블을 써야 하는지, 어떤 세그먼트 기준이 맞는지, 어떤 지표 정의를 따르는지 등 각 팀의 분석가가 동료의 질문 하나에 답하기 전에 참고하는 것들을 모아이도 똑같이 참고하는 구조예요. 단순히 데이터를 가져오는 게 아니라, 실제 전문가가 보는 수준의 맥락을 갖고 답하게 만들기 위해 이 레이어를 만든거죠.

6월, 전사 베타 서비스 오픈

6월 중순, 저희는 전사 구성원을 대상으로 모아이 베타를 오픈했어요.

결과는 기대 반, 배움 반이었어요.

모아이는 KPI, CRM, Finance 같은 정형화된 지표들에는 꽤 잘 응답했어요. 자주 쓰는 데이터들이 잘 정의되어 있었으니까요. 간단한 분석 질문에 도움을 받았다는 분들, 실제로 새벽에 궁금한 게 생겨서 모아이한테 물어봤다는 분들 등 아주 잘 사용하고 있다는 이야기들을 많이 들을 수 있었어요.

하지만 베타 오픈이다 보니 유저 행동 로그 기반의 복잡한 분석으로 넘어가면, 아직은 아쉬운 부분들이 있었어요.테이블의 메타데이터가 덜 명시적인 부분, 분석계에서 아직 잘 정의되어 있지 않는 부분들 등 아직 신뢰할 수 있는 데이터가 부족한 영역들이 있거든요.

하지만 이것이 베타 서비스를 빠르게 오픈한 이유이기도 했어요. 내부에서 아무리 잘 만들었다고 생각해도, 실제로 어떻게 쓰이는지 보지 않으면 모르는 게 있으니까요. 오히려 동료들이 실제로 무엇을 궁금해하는지 직접 보면서 어떤 부분을 디벨롭 해야할지 뚜렷하게 볼 수 있게 된 거죠.

지금 저희가 하고 있는 것

베타 이후 저희는 두 가지를 동시에 진행 중이에요.

첫 번째로, 다시 분석계를 정비하고 있어요. 베타에서 드러난 모델링의 빈 곳을 채우는 거죠. 어떤 테이블이 불명확한지, 어떤 지표 정의가 흔들리는지, 모아이를 통해 역으로 발견하고 있어요.

두 번째로, 모아이가 계속 성장할 수 있는 구조를 만들고 있어요.

약 3주간의 베타 기간 동안, 동료분들이 남겨주신 분석 질문이 무려 500개가 넘었어요. 하나하나 들여다보니 저희가 예상하지 못했던 질문들, 그리고 모아이가 틀리게 답한 케이스들이 꽤 있었습니다.

이것들을 놓치지 않으려고 모아이 백오피스를 만들었어요. 매일 들어온 질문과 모아이의 답변을 분석가가 직접 확인하고 그 내용이 맞으면 맞다고, 틀렸다면 왜 틀렸는지, 어떻게 답했어야 하는지를 답변으로 달아두고 있어요.

사실 분석가 입장에서는 매일 답변을 달아야 하니 솔직히 적지 않은 공수예요. 그럼에도 이 구조를 택한 건, 실제 동료들이 던지는 질문만큼 정직한 테스트가 없다고 생각했기 때문이에요. 단순한 로그 수집이 아니라, 질문 하나하나가 모아이를 고치는 재료가 되는 피드백 루프를 만들고 있는 거죠.

마치며

dbt 도입부터 모아이 베타 오픈까지, 돌아보면 "데이터를 잘 쓰기 위한 조건"을 하나씩 쌓아온 과정이었어요. 앞서 이야기 한 것처럼 아직 모아이는 완성되지 않았고, 앞으로 더욱 잘 만들어가야 할 것들이 많아요.

다음 아티클에서는 베타 이후 모아이가 어떻게 바뀌었는지, 어떤 시행착오를 겪었는지 더 솔직하고 풍성한 이야기를 담아볼게요!