[한영자막] AI, 제발 토큰만 태우지 마세요

한 줄 핵심

AI 애플리케이션은 범용적인 정답을 찾는 것보다 도메인에 맞는 고신호 평가 기준과 검증 루프를 먼저 설계해야 토큰 낭비 없이 지속적으로 개선된다.

시간별 요약

1. 0:00
   핵심 메시지는 에이전트의 성능을 프롬프트 길이로 끌어올리기보다, 도메인 전문가 지식을 루프와 애플리케이션 설계에 초기에 넣어 계속 개선하는 구조를 만드는 데 있다. 코드 컴파일처럼 명확한 정답이 있는 문제는 자동 최적화가 잘 되지만, 실제 AI 애플리케이션은 목표가 불완전하고 모호해 더 정교한 설계가 필요하다.
2. 2:02
   가장 명확한 yes/no 목표 함수로 단일 라벨 분류 문제를 선택해, 200개 학습·100개 검증·300개 테스트 데이터셋으로 최소 자기최적화 루프를 구성했다. 기본 프롬프트, 오류 분석, 프롬프트 업데이트, 검증 통과 조건, 중단 조건을 분리해 두어 과적합 없이 개선되는지 확인할 수 있게 만들었다.
3. 6:01
   루프는 먼저 학습 데이터에서 오류와 혼동 패턴을 분석하고, 가장 큰 오류 범주에 대해 새 프롬프트를 제안한 뒤 검증 데이터에서만 개선 여부를 판단하는 방식으로 동작했다. 최대 15회 또는 92% 정확도 도달 시 종료하도록 설계해, 테스트 데이터를 미리 보지 않게 막으면서 일반화 성능을 확인했다.
4. 7:00
   결과는 기본 정확도 68%에서 첫 반복만에 10%p가 뛰는 등 전체적으로 83%까지 상승했고, 테스트 데이터에서도 80.2%로 잘 일반화됐다. 가장 큰 개선은 첫 라운드에서 나왔으며, 이후에는 완만한 상승과 정체가 이어져 초기 오류 분석의 질이 성능을 크게 좌우한다는 점이 드러났다.
5. 12:01
   일반적인 correctness나 helpfulness 같은 낮은 신호의 점수보다, 도메인에 맞는 고신호 yes/no 기준을 정의하는 것이 자동 개선에 훨씬 중요하다. 예를 들어 지식베이스 근거 여부, 브랜드명 오기·오역 여부, 알려진 실패 유형 분류처럼 구체적이고 판별 가능한 기준이 있어야 루프가 안정적으로 작동한다.
6. 15:00
   도메인 전문가와 함께 좋은 예시와 실패 모드를 데이터로 구체화하고, 운영 후에는 사람이 직접 결과를 검토해 스코프 변화와 새로운 실패 유형을 추적해야 한다. 또한 검증 장치와 탈출구를 넣어 무한 반복으로 토큰을 태우지 않도록 하고, 사람이 함께 개선하는 시스템으로 설계해야 한다.

실무 인사이트

• 자율 개선 루프를 만들 때는 먼저 '정답을 어떻게 정의할 것인가'를 정하고, 그 다음에 프롬프트와 에이전트를 붙여야 한다.
• 실무에서는 score 하나를 매기기보다, 실패 유형 분류나 근거 일치 여부처럼 판별 가능한 체크리스트를 평가기로 바꾸는 것이 효과적이다.
• 초기 성능 개선은 대부분 첫 오류 분석의 품질에서 나오므로, 도메인 전문가가 함께 본 예시와 실패 케이스를 축적하는 것이 가장 큰 투자다.