AI-native 조직은 왜 Skill보다 Eval에서 시작하는가

AI-native 조직을 만든다고 하면 많은 팀이 먼저 Skill과 에이전트를 만든다. 하지만 실제 속도를 결정하는 것은 Skill의 개수가 아니다. 결과가 좋은지 판정하고, 사람의 수정을 다음 실행에 반영하는 루프를 갖췄는지가 더 중요하다.

TL;DR

AI 기능에서 Eval은 결과를 채점하는 사후 테스트가 아니라, 무엇을 만들지 정하는 새로운 PRD가 된다.
업무를 Skill로 쪼개는 것만으로는 부족하다. 성공 기준, 실패 유형, 사람의 수정이 함께 기록되어야 한다.
좋은 에이전트는 한 번에 정답을 내는 봇이 아니라, 평가 결과를 바탕으로 같은 실패를 덜 반복하는 업무 인터페이스다.
처음부터 거대한 평가 플랫폼을 만들 필요는 없다. 대표 입력 10개와 합격 기준 5개로 작은 회귀 테스트부터 시작할 수 있다.

왜 지금 중요한가

생성형 AI의 구현 비용은 계속 내려가고 있다. 아이디어를 코드나 초안으로 옮기는 속도는 빨라졌다. 반면 “이 결과를 실제 업무에 써도 되는가?”를 판단하는 비용은 쉽게 줄지 않는다.

특히 글쓰기, 코드 리뷰, 고객 응대처럼 정답이 하나가 아닌 업무에서는 결과의 품질을 정의하는 일이 구현보다 어렵다. 그럴듯한 출력이 많아질수록 사람은 모든 결과를 같은 깊이로 읽을 수 없다.

그래서 AI-native 팀의 첫 질문은 “어떤 모델을 붙일까?”가 아니라 “좋은 결과를 어떻게 알아볼까?”가 되어야 한다.

Eval은 결과를 채점하는 문서가 아니라, 팀이 AI에게 맡길 수 있는 업무의 경계를 정의하는 문서다.

핵심 흐름: 업무를 자기개선 루프로 바꾸기

1. 업무를 Skill 단위로 쪼갠다

“마케팅을 자동화한다”처럼 넓은 목표를 그대로 에이전트에게 주지 않는다. 검색 의도 분류, 초안 구조화, 사실 링크 점검처럼 입력과 출력이 비교적 분명한 단위로 나눈다.

작업 단위가 작아야 무엇이 실패했는지 말할 수 있다. 그래야 다음 수정도 프롬프트 전체를 갈아엎는 대신 특정 단계에 집중할 수 있다.

2. 성공 기준을 먼저 쓴다

성공 기준에는 최소한 다음이 들어가야 한다.

반드시 포함해야 하는 정보
절대 하면 안 되는 주장이나 행동
허용되는 길이와 형식
사람이 최종 확인해야 하는 지점
중단하고 되돌려야 하는 조건

이 기준이 없으면 Skill은 그럴듯한 문장을 만드는 프롬프트에 머문다. 반대로 기준이 있으면 새 모델이나 새 프롬프트를 적용할 때도 결과를 비교할 수 있다.

3. 실행 결과와 사람의 수정을 함께 모은다

모델의 출력만 저장하면 개선 방향을 알 수 없다. 사람이 무엇을 지웠는지, 어떤 문장을 고쳤는지, 왜 결과를 보류했는지를 남겨야 한다.

이 기록은 단순한 피드백 창고가 아니다. 어떤 실패가 반복되는지 보여주는 Skill의 다음 버전 입력이다. 사람의 판단을 모두 자동화하려는 것이 아니라, 사람이 반복해서 하는 수정을 구조화하는 방식이다.

4. Eval을 정기적으로 다시 돌린다

새 모델이나 새 프롬프트를 적용할 때 대표 입력 묶음을 다시 실행한다. 평균 점수 하나만 보지 말고 어떤 실패 유형이 늘었는지 확인한다.

비용이 낮은 모델은 반복 작업에, 더 깊은 판단이 필요한 모델은 모호한 사례와 최종 검수에 배치할 수 있다. 이때 모델 라우팅은 단순한 가격표가 아니라 작업 계약에 따른 분배가 된다.

실제 사례 / 신호

한 현장 메모는 AI-native 조직의 운영 단위를 업무의 Skill화 → Eval과 정기 리뷰 → 직무형 에이전트 인터페이스로 설명한다. 핵심은 에이전트를 먼저 많이 만드는 것이 아니라, 각 업무의 결과를 평가하고 개선하는 공용 인프라를 만드는 데 있다.

또 다른 사례는 코딩 에이전트에 연결되어 계속 진화하는 코드베이스 위키를 보여준다. 에이전트의 지능을 모델 하나에만 두지 않고, 프로젝트 안에 축적되는 지식 구조로 분산할 수 있다는 신호다. 지식 표면이 있으면 에이전트는 매번 같은 질문을 처음부터 풀지 않아도 된다.

두 흐름을 합치면 구조는 단순해진다.

업무 계약 → Skill 실행 → 결과 + 사람 수정 → Eval 리뷰 → Skill·지식 업데이트

여기서 중요한 것은 자동화의 양이 아니다. 다음 실행에서 같은 실패를 덜 반복하는지가 핵심이다.

실전 활용 팁: 작은 Eval부터 시작하기

반복 업무 하나를 골라 아래 다섯 항목을 먼저 고정한다.

항목	예시
대표 입력	최근 블로그 후보 10개
성공 기준	출처가 있고, 중복이 없고, 독자 행동이 분명함
실패 유형	내부 메모 노출, 근거 없는 확정, 제목 중복
사람의 수정	삭제·교체·보류 이유
합격 조건	필수 기준 통과 + 치명적 실패 0개

이 표를 5~10개의 대표 입력에 적용하면 첫 번째 회귀 테스트가 된다. 점수를 정교하게 만들기 전에, 같은 입력을 다시 실행했을 때 결과가 나아졌는지 비교할 수 있는 상태를 만드는 것이 먼저다.

바로 해볼 실험

1~3일 안에 다음 실험을 진행한다.

반복 업무 하나와 대표 입력 10개를 고정한다.
합격 기준 5개와 치명적 실패 3개를 적는다.
현재 Skill로 실행하고 결과와 사람의 수정을 저장한다.
가장 자주 발생한 실패 유형 하나만 골라 Skill을 수정한다.
같은 입력을 다시 실행해 실패 유형의 빈도를 비교한다.

성공 기준은 높은 점수 자체가 아니다. 두 번째 실행에서 같은 실패를 덜 반복하고, 사람이 왜 결과를 고쳤는지 설명할 수 있으면 첫 번째 신호다.

리스크 / 반론

Eval을 잘못 설계하면 팀이 측정하기 쉬운 것만 최적화한다. 문장 길이와 형식은 통과하지만 실제 독자에게 쓸모없는 결과가 나올 수 있다. 인간의 취향과 판단을 전부 점수로 환원하는 것도 불가능하다.

따라서 자동 점수 하나로 끝내지 않는다. 정량 기준과 사람의 최종 판단을 함께 두고, 평가 기준 자체가 현실의 결과와 맞는지 주기적으로 검토해야 한다.

피드백을 무제한 저장하는 방식도 조심해야 한다. 개인정보와 비밀 값이 실행 기록에 복제될 수 있으므로 보관 범위, 마스킹, 삭제 정책을 먼저 정해야 한다. Eval은 감시 시스템이 아니라 품질을 개선하는 최소한의 관찰 장치여야 한다.

결론

AI-native 조직의 해자는 Skill의 숫자가 아니다. 실행 결과를 평가하고 사람의 판단을 다음 Skill에 반영하는 속도다. 에이전트가 늘어날수록 이 차이는 더 커진다.

AI 기능이나 자동화 업무를 만들고 있다면 다음 질문부터 던져야 한다.

좋은 결과를 어떤 입력과 조건에서 알아볼 수 있는가?
사람이 결과를 수정한 이유가 다음 실행에 남는가?
모델이나 프롬프트를 바꿔도 같은 기준으로 비교할 수 있는가?
실패했을 때 멈추고 되돌릴 조건이 있는가?

당신의 팀은 지금 Skill을 더 만들고 있는가, 아니면 Skill이 실제로 좋아졌다는 증거를 쌓고 있는가?