AI 제품의 진짜 해자는 모델이 아니라 업무 환경과 평가셋이다
오픈 모델이 빠르게 좋아지고 싸지는 시대다. 그렇다면 AI 제품은 무엇을 쌓아야 하는가? 답은 모델 이름보다 업무를 재현하는 환경, 모델이 선택할 수 있는 의미 구조, 그리고 합격을 판정하는 평가셋에 가깝다.
TL;DR
- 모델은 교체될 수 있지만 업무 환경과 평가 기준은 제품에 남는다.
- 자유 생성보다 의미 구조와 출력 계약을 중간에 두면 에이전트를 통제하기 쉽다.
- 작은 팀도 반복 업무 10개와 합격 기준부터 적으면 도메인 AI의 첫 평가셋을 만들 수 있다.
왜 지금 중요한가
최근 AI 시장의 경쟁 단위가 바뀌고 있다. 한 모델을 골라 프롬프트를 붙이는 방식만으로는 차별화하기 어렵다. 오픈웨이트 모델이 빠르게 등장하고 가격과 성능도 수시로 바뀌기 때문이다.
이때 중요한 질문은 “어떤 모델이 최고인가?”가 아니다. “우리 업무를 어떤 환경으로 재현하고, 어떤 결과를 합격으로 볼 것인가?”다.
핵심 흐름
모델은 부품이 되고 환경은 자산이 된다
Vertical AI 사례를 모델 출시 뉴스로만 보면 핵심을 놓친다. 법률이나 상담 같은 업무를 문서, 도구, 지시, 결과물, 채점 기준이 있는 환경으로 만들면 모델을 바꿔도 학습과 검증의 틀이 남는다.
공개 게시물에 등장하는 환경 수나 성능 개선 수치는 게시자 서술인 경우가 많아 독립 검증이 필요하다. 수치와 별개로 업무를 재현 가능한 실험 단위로 바꾸는 전략은 제품 설계에 직접 참고할 수 있다.
LLM의 역할은 SQL 작성이 아니라 의미 선택이 될 수 있다
데이터 분석 에이전트가 SQL을 마음껏 쓰게 하는 대신 Dimension, Metric, Filter, Order, Comparison을 고르게 하는 방식이 있다. 실행기는 이 구조를 받아 SQL을 조립한다.
이 방식은 모델의 언어적 유연성을 유지하면서 데이터베이스가 허용하는 범위 안에 결과를 묶는다. AI 제품의 중간 표현은 안전장치이자 평가 대상이 된다.
리더보드보다 실제 업무 평가가 중요하다
공개 리더보드의 순위와 실제 업무의 순위는 다를 수 있다. 비용, 정확성, 답변 실패, 사람의 후처리, 사용자 영향은 서로 다른 지표다.
| 평가 축 | 질문 |
|---|---|
| 품질 | 정답·근거·형식을 지키는가? |
| 안전 | 모를 때 멈추거나 사람에게 넘기는가? |
| 비용 | 과업 하나에 얼마가 드는가? |
| 운영 | 사람이 수정하는 데 얼마나 걸리는가? |
| 제품 영향 | 실패가 재작업이나 사용자 이탈로 이어지는가? |
실제 사례 / 신호
agent.md로 반복되는 코드 품질 지침을 작업 환경에 고정하는 사례와, 수백 번의 LLM 호출로 코드 리뷰 반복을 측정한 사례는 같은 방향을 가리킨다. 에이전트 품질은 호출 횟수보다 작업 계약과 종료 조건을 설계하는 능력에서 나온다.
또 다른 흐름은 Skill과 MCP 서버를 하나의 portable bundle로 묶는 Agent Plugin 제안이다. 지식과 도구가 패키지 단위로 이동하면 실행 환경과 검증 기준을 함께 배포해야 한다는 요구가 커진다. 다만 새로운 표준의 실제 채택 범위는 계속 확인해야 한다.
실전 활용 팁: 업무를 평가 가능한 단위로 바꾸는 법
업무 하나를 다음 다섯 요소로 적어본다.
- 입력: 어떤 문서와 데이터가 들어오는가?
- 도구: 모델이 호출할 수 있는 도구는 무엇인가?
- 출력: 결과물의 형식과 필수 필드는 무엇인가?
- 금지: 하면 안 되는 행동은 무엇인가?
- 합격: 사람이 승인할 수 있는 최소 기준은 무엇인가?
이 다섯 요소가 있으면 프롬프트가 아니라 테스트 가능한 과업이 된다. 다음 모델을 시험할 때도 같은 환경과 평가 기준을 재사용할 수 있다.
바로 해볼 실험
이번 주에 반복 업무 10개를 고른다. 각 업무마다 성공 예시 2개, 실패 예시 2개, 반드시 확인할 항목 5개를 만든다.
모델 세 개를 같은 입력에 연결하고 품질, 비용, 사람의 수정 시간을 기록한다. 처음부터 강화학습이나 대규모 데이터 수집을 할 필요는 없다. 중요한 것은 모델이 바뀌어도 비교할 수 있는 고정된 시험장이다.
리스크 / 반론
업무 환경과 평가셋을 만든다고 자동으로 좋은 제품이 되지는 않는다. 잘못된 평가 기준을 최적화하면 에이전트가 점수만 올리고 실제 사용자 가치는 놓칠 수 있다. 과거 업무만 담은 평가셋은 새로운 실패를 발견하지 못할 수도 있다.
전문 영역에서는 개인정보와 고객 데이터의 처리 경계를 먼저 정해야 한다. 공개 자료의 성공 수치도 독립 검증 없이 일반화해서는 안 된다. 평가셋 자체도 주기적으로 갱신하고 실제 실패 사례를 추가해야 한다.
결론
모델이 빠르게 교체되는 시장에서 오래 남는 제품은 모델 하나를 소유한 제품이 아닐 수 있다. 업무를 재현하고, 의미 구조로 제한하고, 결과를 평가하는 학습 스택을 가진 제품일 가능성이 더 크다.
다음 AI 기능을 만들 때 먼저 물어보자. 모델이 바뀌어도 남아야 하는 업무 환경과 합격 기준은 무엇인가?