무엇으로 분류할지가 도메인 지식이다

라벨을 붙이는 일과 무엇으로 나눌지를 정하는 일

이 시리즈(데이터가 8할이라면, 그 8할을 어떻게 다루나)는 데이터 공정을 정제·태깅·검증·평가·grounding으로 나눴다. 앞 칸인 정제가 흩어진 표기를 모아 “같은 것을 같다고 부르게” 만드는 일이라면, 그다음 질문은 자연스럽게 따라온다 — 깨끗하게 모인 그것을, 이제 무엇으로 나눌 것인가. 이 글은 그 태깅 칸 하나를 연다.

태깅은 흔히 가장 단순한 칸으로 취급된다. 사람이든 모델이든 라벨을 갖다 붙이면 끝나는 노동. 우리 경험은 정반대였다. 라벨을 붙이는 일은 쉽다. 어려운 건 무엇으로 나눌지를 정하는 일이고, 그걸 정하는 순간 그 도메인을 얼마나 아는지가 그대로 드러난다.

레시피 하나를 앞에 두고 우리가 던진 질문은 “이걸 어떤 이름으로 부를까”가 아니라 “이걸 무엇으로 분류해야 식단을 짜는 데 쓸모가 있나”였다. 임의의 카테고리 몇 개로는 “생각 없이 따라 하면 되는 한 주의 집밥”을 조립할 수 없었다. 도메인이 요구하는 축이 따로 있었다.

분류 축은 제품 목표에서 역산된다

우리가 세운 원칙은 단순하다. 분류 축은 미리 정해진 표준 분류표에서 가져오는 게 아니라, 제품이 하려는 일에서 거꾸로 도출된다.

“따라만 하면 되는 주간 집밥”을 만들려면 어떤 정보가 필요한가를 먼저 묻는다. 한 주의 식단이 지금 사도 되는 재료로 짜이려면 계절·제철을, 초보가 실제로 만들어낼 수 있으려면 조리 난이도를, 한 주가 한 종류로 치우치지 않으려면 한·양·일·중 같은 구성을 알아야 한다. 이 축들은 임의의 라벨이 아니라, 각각 “왜 이 축이어야 하는가”에 제품 목표로 답할 수 있는 의도가 있는 분류다.

그리고 이 축들은 한국 식문화와 집밥의 맥락을 모르면 애초에 설계할 수 없다. 제철이 무엇을 의미하는지, 어떤 조리가 초보에게 부담인지, 식탁이 한 종류로 쏠렸다는 게 왜 문제인지 — 이걸 아는 것이 곧 도메인 지식이고, 그 지식이 분류 축의 목록으로 굳는다. 그래서 우리는 택소노미 설계를 데이터 정리가 아니라 도메인 이해를 구조로 옮기는 일로 본다.

축들은 서로 따로 노는 라벨이 아니라, 한 주의 다양성과 균형이라는 상위 목표를 함께 떠받친다. 그래서 태그는 그 자체가 목적지가 아니라 다음 공정의 입력이다.

레시피 → [도메인 축들로 분류] → 식단 조합의 입력

식단을 실제로 조립하는 건 별개의 시스템이고, 태그는 그 시스템에 넘기는 재료다.

진짜 어려운 건 분류가 아니라 일관성이다

분류 축을 잘 골랐다고 끝이 아니다. 태깅의 진짜 난점은 재현성이다. 같은 레시피에 매번 같은 축, 같은 값이 붙어야 한다. 한 번은 “중식·쉬움”으로, 다음엔 “한식·보통”으로 흔들리면, 그 위에 세운 검색도 필터도 식단 조합도 전부 신뢰를 잃는다. 분류는 한 번 하면 끝이 아니라, 같은 입력에 같은 출력을 내야 비로소 자산이 된다.

흔들리는 이유는 둘이다. 하나는 경계 사례 — 제철의 전환기, “중간 난이도”의 모호함, 퓨전 요리의 구성 분류처럼 정답이 한쪽으로 깔끔히 떨어지지 않는 지점이 도메인 곳곳에 있다. 다른 하나는 판단의 흔들림 — 사람이 하든 모델이 하든, 그날의 컨텍스트에 휘둘리면 같은 레시피가 다르게 분류된다.

우리의 접근은 일관성을 의지가 아니라 구조로 강제하는 것이다. 기준을 명확히 정의하고, 경계 사례를 감으로 판단하지 않도록 규칙으로 미리 정한다. 예컨대 제철이 바뀌는 전환기에는 한쪽으로 억지로 떨어뜨리지 않고 두 계절을 함께 허용하는 식으로 모호함을 명시적으로 다룬다. 같은 입력에 같은 출력을 내는 결정적 처리를 우선하고, 그럼에도 흔들리는 지점은 측정해서 잡는 루프로 좁혀간다. 좋아졌다는 느낌이 아니라, 어디가 흔들리는지를 보고 고친다.

여기엔 트레이드오프가 있다. 축을 잘게 쪼갤수록 표현력은 높아지지만, 일관성 유지 비용과 경계의 모호함도 같이 커진다. 그래서 우리는 “촘촘한 분류 체계”가 아니라 “재현 가능하면서 식단 조합에 실제로 쓸모 있는 최소한의 축”을 택했다. 표현력보다 신뢰를 앞에 둔 결정이다.

한 가지는 분명히 구분해 둔다. 이 분류와 일관성 판단에 관여하는 LLM은 코퍼스 태깅 단계의 판단자다. 이렇게 태깅된 레시피를 받아 사용자에게 나갈 식단을 실제로 짜는 코어 엔진은, LLM 없이 도는 결정론 알고리즘이다. 계절 필터·구성비·난이도 편향을 입력으로 받아 재현 가능하게 식단을 조립하는 별개의 시스템이다. 태깅 자리에서는 회색지대를 판단하는 LLM이, 식단을 짜는 자리에서는 결정론이 일한다.

택소노미가 자산이 되는 순간

분류 축은 한 번 잘 설계해 일관되게 유지하면, 그 위의 검색·필터·식단 조합 전체가 그 토대 위에서 안정된다. 반대로 축이 도메인을 잘못 반영하거나 일관성이 없으면, 그 위에 세운 모든 게 모래 위에 선 집이 된다. 분류의 품질은 분류로 끝나지 않고 하류 공정 전체의 신뢰도로 번진다.

이건 한 번 헛디뎌서 얻은 교훈이기도 하다. 초기엔 “카테고리만 적당히 붙이면 식단은 짜이겠지”로 접근했다. 그런데 막상 한 주를 조립하는 단계에 가니, 그 라벨로는 균형도 난이도도 제철도 통제할 수 없었다. 그래서 분류표를 버리고 제품 목표에서 다시 역산해 축을 세웠다. “좋은 기준 식단을 갖춰두고 필요한 만큼 개인화한다”는 방향이 잡히면서, 레시피를 미리 갖추고 도메인 축으로 태깅해 두는 구조가 비로소 의미를 가졌다.

옮겨갈 수 있는 건 우리 레시피 축이 아니다. 제품 목표에서 분류 축을 역산하고, 일관성을 구조로 강제한다는 방법이다. 도메인이 바뀌어도 이 순서는 그대로 선다.

분류가 곧 이해다

어느 도메인이든 데이터에 라벨을 붙여야 한다. 하지만 무엇으로 나눌지는 그 도메인을 이해해야만 제대로 정해지고, 매번 같게 붙이는 일관성이 비로소 데이터를 자산으로 만든다. 우리는 한국 식문화에서 이 분류 축을 설계하고 일관되게 유지하는 일을 매일 했다.