모요 AI 분석 어시스턴트 모아이(MOAI) 이야기 2편 : 로그와 사내지식을 읽는 모아이
들어가며
1편에서 저희는 dbt로 분석계 기반을 다시 세우고, 그 위에 모아이 베타를 오픈한 이야기를 했어요. 그리고 글 끝에 이렇게 적었죠. 유저 행동 로그 기반의 복잡한 분석과 사내 지식으로 넘어가면 아직 아쉬운 부분이 있다고요.
이번 글은 그 아쉬운 부분을 채워온 3개월의 이야기예요. 모아이가 더 좋은 답을 하려면 모델을 바꾸는 것보다, 모아이가 읽을 수 있는 것을 늘리는 게 먼저였거든요.
베타가 알려준 빈 곳: 로그
베타 기간에 들어온 질문을 들여다보니, 모아이가 헤매는 질문에는 공통점이 있었어요. 대부분 유저 행동 로그를 봐야 답할 수 있는 질문이었죠.
예를 들어 볼게요. 로그에 current_mpo라는 값이 쌓이고 있어요. 이게 무슨 뜻일까요?
솔직히 말하면, 저희도 몰랐어요. 이 로그를 만든 팀만 알고 있었거든요. 로그는 매일 쌓이는데, 그 로그가 무엇을 뜻하는지는 어디에도 적혀 있지 않았어요. 사람도 모르는 걸 모아이가 알 리 없죠.
1편에서 이야기한 '기준의 불투명성'이 분석계 테이블에만 있던 문제가 아니었던 거예요. 로그에도 똑같이, 어쩌면 더 심하게 있었어요.
ubl-registry: 모든 로그에 설명서 붙이기
그래서 3분기에 ubl-registry를 만들어 배포했어요. 사내 로그의 명세를 기록하고, 누구나 볼 수 있게 만드는 로그 명세 서비스예요.
핵심은 "나중에 정리하자"가 아니라 "만들 때부터 적자"였어요.
이제 신규 로그는 ubl-registry에 명세를 먼저 등록해야 배포할 수 있어요. 이 로그가 언제 찍히는지, 각 값이 무엇을 뜻하는지를 로그를 만드는 시점에 남기는 거죠. 이미 쌓여 있던 기존 로그는 AI로 일괄 명세화해뒀어요. 100% 정확하진 않을 수 있어서, 로그를 잘 아는 동료분들께 틀린 부분을 고쳐달라고 요청드리며 조금씩 다듬고 있어요.
이제 current_mpo 같은 로그도 더 이상 만든 팀만 아는 암호가 아니에요. 누구든 ubl-registry에서 찾아보면 되니까요.
여기서 한 단계 더 나아가, ubl-registry를 MCP tool 형태로 만들었어요. 모아이가 로그 관련 질문을 받으면 직접 ubl-registry를 호출해서, 그 로그가 무엇을 뜻하는지 먼저 확인한 뒤에 분석을 시작해요.
사내 지식까지 읽는 모아이
모아이가 새로 읽게 된 건 로그 명세만이 아니에요.
모요에는 AX팀에서 만들어주신 사내 지식정보 시스템 knowledge가 있어요. 정책, 제품 히스토리, 의사결정 배경처럼 "왜 이렇게 됐는지"에 대한 맥락이 담긴 곳이에요. 이 시스템도 MCP tool 형태로 배포되어 있어서, 모아이가 필요할 때 불러와 쓰고 있어요. (knowledge가 어떻게 만들어졌는지는 AX팀의 글 「모요 지식 시스템 : 흩어진 조직 지식을 하나로 연결하다」에 자세히 담겨 있어요.)
정리하면 모아이가 읽는 범위는 이렇게 달라졌어요.
1편에서 "dbt가 데이터를 어떻게 만드는지를 담는다면, knowledge 레이어는 데이터를 어떻게 읽어야 하는지를 담는다"고 했는데요. 이제는 여기에 "이 로그가 무엇을 뜻하는지", "이 정책이 왜 이렇게 생겼는지"까지 더해진 셈이에요.
숫자로 보는 3개월
베타 오픈 후 3개월, 모아이는 약 4,500개의 질문을 받았어요. 지금은 하루에 꾸준히 50~200개 정도의 질문에 답하고 있어요.
소비처도 넓어졌어요. 처음에는 슬랙봇 형태로만 서빙했다면, 지금은 모아이 자체도 MCP tool로 배포해서 Claude Chat이나 Claude Tag에서도 모아이를 불러 쓸 수 있어요. 이 부분은 AX팀에서 더 자세히 풀어주실 예정이라, 여기서는 살짝만 짚고 넘어갈게요.
늘어난 질문만큼, 검증도 달라져야 했어요
1편에서 모아이 백오피스 이야기를 했었죠. 매일 들어온 질문과 답변을 분석가가 직접 확인하고, 맞았는지 틀렸는지, 틀렸다면 어떻게 답했어야 하는지를 달아두는 구조였어요.
그런데 질문이 가파르게 늘면서 이 방식은 금방 한계에 부딪혔어요. 하루 수백 개의 질문에 분석가가 어드민에서 하나하나 답변을 다는 건 현실적으로 어려웠거든요.
그래서 검증 방식을 두 가지로 바꿨어요.
첫 번째, 도메인별 담당자와 Claude Code skill. 질문을 도메인별로 나누고 담당자를 정했어요. 그리고 각 담당자가 Claude Code에서 skill 형태로 질문을 쉽게 평가할 수 있게 만들었어요. 질문과 답변, 실행된 쿼리를 한 번에 보고 판정을 남길 수 있게요.
두 번째, 어드민 페이지 개선. 최대한 많은 건수를 검증할 수 있도록 어드민도 다시 손봤어요.
이렇게 판정된 결과는 다시 모아이의 기반을 고치는 데 쓰여요. 틀린 답의 원인을 따라가서 분석계 모델링, 로그 명세, knowledge를 보강하는 거죠.
목표는 1편 때와 같아요. 실제 동료들이 던지는 질문만큼 정직한 테스트는 없으니까, 그 질문 하나하나를 놓치지 않고 모아이를 고치는 재료로 쓰는 것. 달라진 건 그 피드백 루프가 이제 사람 손만으로는 돌아가지 않는 규모가 됐다는 점이에요.
마치며
1편이 "믿을 수 있는 데이터를 만드는 이야기"였다면, 2편은 "모아이가 읽을 수 있는 세계를 넓히는 이야기"였어요. 분석계 데이터만 보던 모아이가 이제는 로그의 의미와 사내의 맥락까지 함께 읽고 답하고 있어요.
그래도 무엇보다 중요한 건 따로 있어요. 1편에서 이야기한 dbt 분석계 모델링을 더 견고하게, 어긋난 버전 없이 관리하는 일이에요. 로그 명세도, 사내 지식도 결국 그 위에서 읽혀야 의미가 있으니까요. 모아이가 틀린 답을 할 때마다 저희가 가장 먼저 들여다보는 곳도 여기고요. 이 작업은 앞으로도 계속될 것 같아요.
다음 글에서도 모아이가 어떻게 자라고 있는지, 솔직한 이야기로 다시 찾아올게요! 🗿