데이터가 곧 자산 — 같은 게이트를 당신의 도메인에

일곱 편을 지나 — 무엇이 남는가

데이터가 8할이라고 말한 뒤, 우리는 그 8할을 한 덩어리로 두지 않고 다섯으로 쪼개 한 편씩 열었다(8할의 해부도에서 그 지도를 먼저 그렸다). 정제는 같은 것을 같다고 부르게 만들었고, 태깅은 무엇으로 분류할지를 도메인 지식으로 세웠다. 검증은 들일지 말지를 판정했고, 평가는 “좋아졌다”를 측정했으며, grounding은 판단을 도메인 사실에 묶었다. 다섯 편의 how는 각자의 글에 있다.

이제 시리즈를 닫으며 한 가지를 묻는다 — 이걸 다 합치면 회사에 무엇이 남는가? 남는 것은 잘 정제된 데이터셋 한 벌이 아니다. 데이터셋은 결과물이고, 결과물은 시간이 지나면 낡는다. 남는 것은 그 데이터셋을 계속 만들어 내는 무언가, 한 번 세우면 굴러가는 게이트다.

다섯 공정은 하나의 게이트로 수렴한다

각 단계를 따로 보면 다섯 개의 작업이지만, 묶어 보면 하나의 질문에 답한다 — 이 데이터를 신뢰할 수 있는가, 그리고 그 신뢰의 근거를 추적할 수 있는가. 우리는 이걸 출처 규율(provenance discipline)이라 부른다. 무엇을 들였는지(정제·태깅), 왜 통과시켰는지(검증), 정말 좋아졌는지(평가), 사실에 묶였는지(grounding)가 끊기지 않는 한 흐름으로 이어지고, 그 흐름의 어느 지점에서든 “왜 이게 코퍼스에 있는가”에 답이 나온다.

정제 ─┐
태깅 ─┤
검증 ─┼─→ [ 게이트: 신뢰의 근거를 추적 ] ─→ 자산
평가 ─┤
grounding ─┘

오프너에서 다섯 공정을 펼쳤다면, 여기서는 그 다섯이 하나의 게이트로 수렴한다. 한 번 짚고 넘어갈 것이 있다. 이 게이트 안에서 일하는 LLM은 코퍼스를 짓고 판정·측정하는 판단자다. 사용자에게 나가는 주 단위 식단을 짜는 코어 엔진은 LLM 없이 도는 결정론 알고리즘으로, 이 게이트와 별개다. 데이터를 길들이는 자리에서는 회색지대를 판단하는 LLM이, 식단을 짜는 자리에서는 재현 가능한 결정론이 일한다.

왜 이게 moat인가 — 모델은 갈아끼워도 게이트는 남는다

더 좋은 모델이 나오면 한 번에 좋아질 것 같다. 하지만 데이터가 8할이면, 모델을 바꿔 얻는 이득은 그 8할의 위에서 출렁이는 정도다. 반대로, 한 도메인의 데이터를 정제·태깅·검증·평가·grounding으로 길들여 온 게이트와 그 운영 이력은 모델처럼 갈아끼울 수 없다. 우리에게도 그 이력의 한 장면은 LLM의 역할을 생성자에서 판단자로 옮긴 일이었다 — 처음엔 모델에게 통째로 맡겼지만, 결국 데이터를 짓고 그것을 판정하는 자리로 LLM을 다시 앉혔다. 이런 전환은 문서 한 장으로 복제되지 않는다. 굴려 본 시간에서만 나온다.

그래서 정직하게 말하면, 우리가 가진 건 거대한 데이터가 아니다. 자산은 양이 아니라 공정과 규율이다. 작은 도메인에서도 게이트를 끝까지 굴려 봤다는 것, 그 운영 경험이 복제 비용이 높은 쪽이다. moat는 데이터가 많아서 생기는 게 아니라, 데이터를 신뢰 가능하게 만드는 절차를 끝까지 운영해 봤기 때문에 생긴다.

그래서 도메인이 바뀌어도 옮겨간다

게이트의 형태는 한국어 식문화에만 특수하지 않다. 정제→태깅→검증→평가→grounding이라는 골격은 그대로 두고, 도메인이 바뀌면 내용만 바뀐다. 어떤 표기를 일관시킬지, 어떤 축으로 분류할지, 어떤 사실에 판단을 묶을지는 제조든 법무든 의료든 금융이든 각자 다르다. 하지만 “같은 것을 같다고 부르고, 들일지 말지를 판정하고, 좋아졌는지를 측정한다”는 질문의 순서는 옮겨진다. 우리가 식재료를 다룬 자리에 당신의 도메인 사실을 넣으면, 같은 게이트가 선다.

데이터를 자산으로

우리가 하는 일은 기존 제품에 AI 기능을 하나 얹는 게 아니라, 그 아래에서 도는 엔진을 만드는 일이다. 그 엔진의 8할은 도메인 데이터에 신뢰할 수 있는 게이트를 세우는 데서 결정된다. 우리는 이 게이트를 자체 제품에서 매일 굴리며 검증했다.