AI 에이전트가 기업 현장에서 자꾸 삐끗하는 이유
AutoSynthData: Generating Training Data for Enterprise Agents라는 제목을 처음 봤을 때 솔직히 “또 논문 제목만 거창한 프로젝트겠거니” 했습니다. 그런데 막상 내용을 들여다보니, 요즘 사내에 AI 에이전트 하나씩 들여놓고 “왜 얘는 똑똑한데 일을 못하지?”라며 머리를 긁적이는 분들이라면 반드시 알아야 할 이야기였습니다. 그래서 이 글을 씁니다. 특히 IT 담당자뿐 아니라, “우리 회사도 AI 에이전트 도입해볼까” 고민하는 경영진, 그리고 그냥 AI 트렌드가 궁금한 분들도 “검증 없는 자동화는 위험하다”는 핵심 메시지만큼은 꼭 챙겨가시길 바랍니다.
범용 LLM은 코딩도 하고 시도 쓰고 법률 자문까지 그럴듯하게 해냅니다. 그런데 막상 사내 ERP에 접속해 특정 승인 프로세스를 처리하라고 시키면 엉뚱한 버튼을 누르거나, 존재하지 않는 API를 호출하려 듭니다. 공개 벤치마크에서는 고득점을 받아도 실전에서는 삐끗하는 이유는 간단합니다. 벤치마크는 일반적인 상황을 테스트하지만, 실제 기업은 저마다 다른 툴 조합, 다른 데이터 구조, 다른 내부 규정을 갖고 있기 때문입니다. 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것이라고 전망했는데(Gartner 보도자료), 그 핵심 원인 중 하나로 불명확한 비즈니스 가치와 더불어 환경에 맞지 않는 성능 저하를 꼽았습니다. 더 큰 문제는 이런 실패를 ‘발견’하는 것과 그 실패를 다시 ‘학습 데이터’로 바꾸는 것 사이에 거대한 간극이 있다는 점입니다. 실패 로그 한 건을 안다고 해서 모델이 똑똑해지지는 않습니다. 비슷한 상황을 수십, 수백 번 다른 형태로 연습시켜야 비로소 실력이 붙습니다.
AutoSynthData란 무엇인가 — ServiceNow CoreAI의 해법
바로 이 간극을 메우기 위해 ServiceNow CoreAI 연구팀의 Esakkivel Esakkiraja, Shruthan Radhakrishna, Denis Akhiyarov, Sagar Davasam 등이 내놓은 것이 AutoSynthData입니다. 원리는 생각보다 직관적입니다. 타깃 모델(우리가 개선하고 싶은 모델)이 실패한 지점과, 더 강력한 교사(teacher) 모델이 성공한 지점을 비교합니다. 그 차이에서 “이 모델이 다음에 배워야 할 것”을 자동으로 추출한 뒤, 그 약점을 정조준한 새로운 과제를 만들고 검증까지 거칩니다. 재미있는 건 이 과정이 일회성이 아니라는 점입니다. 모델이 똑똑해질수록 커리큘럼 난이도도 같이 올라가서, 늘 모델이 “아직 어려워하는 지점”을 쫓아다니는 적응형 구조로 돌아갑니다. 마치 헬스 트레이너가 회원의 근력이 늘 때마다 중량을 슬쩍 올리는 것과 비슷합니다. 관련 배경은 ServiceNow CoreAI 연구팀이 허깅페이스 블로그를 통해 공개한 원문에서 확인할 수 있습니다.
task = (시스템 명세, 유저 프롬프트, 검증기) 공식 파헤치기
AutoSynthData가 ‘쓸모 있는 과제’를 정의하는 공식은 단순합니다. task = (시스템 명세, 유저 프롬프트, 검증기). 시스템 명세는 에이전트가 움직이는 환경의 규칙입니다. 어떤 툴을 쓸 수 있는지, DB 초기 상태는 어떤지, 참고할 지식 문서는 무엇인지를 정의합니다. 유저 프롬프트는 ‘진짜 사용자라면 이렇게 요청했을 법한’ 업무의 모양을 담습니다. 마지막으로 검증기는 결과물이 제대로 됐는지 판정하는 심판입니다. 이 셋이 하나라도 빠지면 ‘그럴듯한 질문’은 만들 수 있어도 ‘학습에 쓸 수 있는 과제’는 완성되지 않습니다.
좋은 에이전트 태스크를 만드는 3가지 조건
원문은 좋은 과제의 조건을 세 가지로 정리합니다. 한 줄로 요약하면 “할 수 있고, 그럴 법하고, 아직 못 하는 일”입니다. 이 셋 중 하나라도 어긋나면 학습 데이터로서 가치가 뚝 떨어집니다. 실현 불가능한 과제는 모델에게 혼란만 주고, 비현실적인 과제는 실무와 무관하며, 이미 잘 푸는 과제는 가르칠 게 없습니다.
Feasibility(실현 가능성) 체크포인트
환경이 지원하지 않는 툴을 쓰라고 하거나, 애초에 불가능한 상태 전환을 요구하거나, 사내 정책을 위반하는 행동을 시키는 과제는 바로 탈락입니다. 최소 기준은 단 하나, 현재 환경 안에서 그 요청을 만족시키는 성공 경로가 적어도 하나는 존재해야 한다는 것입니다. 당연한 얘기 같지만, 실제로 자동 생성된 과제 중 상당수가 이 기본 문턱을 못 넘습니다.
Realism과 Difficulty, 두 마리 토끼 잡기
여기서부터가 진짜 까다로운 지점입니다. 에이전트가 ‘실행할 수 있는’ 행동의 범위는 매우 넓지만, 사람이 ‘실제로 요청할 법한’ 범위는 그보다 훨씬 좁습니다. 아무 조합이나 실행 가능하다고 해서 현실적인 과제가 되는 건 아닙니다. 또한 모델이 이미 척척 풀어내는 쉬운 과제만 잔뜩 만들어봐야 학습 신호는 거의 0에 가깝습니다. 그래서 난이도가 핵심 필터로 작동합니다. 실현 가능하고 현실적이면서도, 지금 모델이 아직 일관되게 풀지 못하는 그 좁은 영역을 정확히 찾아내는 것이 AutoSynthData의 진짜 역할입니다.
검증기(Verifier)가 하는 일 — 합격·불합격을 가르는 기준
검증기는 세 가지 성질을 동시에 만족해야 합니다. 먼저 Consistency, 즉 유저 프롬프트·시스템 명세·환경 상태와 모순 없이 판정해야 합니다. 둘째는 Soundness로, 과제를 만족하지 못했거나 제약을 어긴 궤적은 반드시 걸러내야 합니다. 셋째는 Completeness인데, 정답을 단 하나의 경로로만 좁히지 않고 다른 유효한 해법도 인정해야 한다는 뜻입니다. NIST의 AI 위험관리 프레임워크도 신뢰 가능한 AI 시스템의 조건으로 ‘검증 가능성’을 핵심 축으로 꼽는데, 같은 맥락입니다. 검증기 설계가 허술하면 아무리 과제를 많이 뽑아내도 그 위에 쌓인 학습 데이터 전체의 신뢰도가 한꺼번에 흔들립니다.
AutoSynthData 파이프라인 실전 적용 — EnterpriseOps Gym 사례
이 파이프라인은 Malay 외 연구진(2026)이 공개한 EnterpriseOps Gym 데이터셋으로 실제 시연됐습니다. 흐름은 이렇습니다. 모델의 약점을 찾는다, 그 약점을 겨냥한 새 태스크를 생성한다, 검증기로 걸러낸다, 다시 학습시킨다. 그리고 이 사이클을 반복합니다. AutoSynthData: Generating Training Data for Enterprise Agents가 보여주는 것은 결국 “사람이 일일이 실패 사례를 모아 수작업으로 데이터를 만드는 시대는 끝나간다”는 신호입니다. 업계에서 기업용 에이전트 평가·학습 데이터 구축이 점점 중요해지는 이유도 여기 있습니다.
우리 기업에 적용한다면? 체크리스트와 전망
도입을 고민하기 전에 점검할 것이 있습니다. 첫째, 사내 시스템이 명세화되어 있는가. 즉 어떤 툴을, 어떤 규칙으로 쓰는지 문서화돼 있는가입니다. 둘째, 검증 가능한 성공 기준이 존재하는가입니다. “일을 잘했다”를 사람 감으로만 판단한다면 자동화할 수 없습니다. McKinsey의 State of AI 리포트는 조직 대부분이 AI 가치를 아직 완전히 실현하지 못하고 있다고 지적하는데, 그 원인 중 하나가 바로 ‘측정 체계의 부재’입니다. 합성 학습 데이터 자동화가 자리 잡으면 사람이 몇 주씩 걸려 만들던 평가셋을 훨씬 빠르고 싸게 만들 수 있습니다. 앞으로 AI 에이전트 학습 데이터 생산 방식은 “사람이 발견한 실패를 수작업으로 반영”하는 구조에서 “모델 스스로 약점을 추적해 커리큘럼을 갱신”하는 구조로 옮겨갈 가능성이 큽니다.
자주 묻는 질문
Q1. AutoSynthData는 누가 만들었나요?
ServiceNow CoreAI 연구팀이 개발했으며, Esakkivel Esakkiraja, Shruthan Radhakrishna 등이 참여했습니다. AutoSynthData: Generating Training Data for Enterprise Agents라는 이름으로 허깅페이스 블로그를 통해 공개됐습니다.
Q2. 일반 벤치마크와 무엇이 다른가요?
일반 벤치마크는 고정된 문제 세트를 평가하지만, AutoSynthData는 타깃 모델의 실시간 약점을 추적해 그에 맞는 새 과제를 계속 생성합니다. 그래서 모델이 좋아질수록 커리큘럼도 함께 어려워집니다.
Q3. 검증기가 왜 그렇게 중요한가요?
검증기가 부실하면 틀린 결과를 맞다고 판정하거나, 맞는 결과를 틀렸다고 판정할 수 있습니다. Consistency, Soundness, Completeness 세 조건을 모두 갖춰야 학습 데이터 전체의 신뢰도가 확보됩니다.
Q4. 중소기업도 이런 방식을 도입할 수 있나요?
사내 시스템 명세와 검증 가능한 성공 기준만 갖춰져 있다면 규모와 무관하게 적용 가능성이 있습니다. 다만 초기에는 시스템 문서화 작업 자체가 선행되어야 합니다.
Q5. EnterpriseOps Gym은 어떤 역할을 하나요?
AutoSynthData 파이프라인의 실전 적용 사례로 쓰인 공개 데이터셋입니다. 약점 발견부터 재학습까지 이어지는 전체 사이클을 시연하는 데 활용됐습니다.
마무리
결국 기업용 AI 에이전트가 자꾸 헛발질하는 이유는 모델이 멍청해서가 아니라, 그 환경에 맞는 ‘연습 문제’가 부족했기 때문입니다. AutoSynthData: Generating Training Data for Enterprise Agents는 그 연습 문제를 사람 손 대신 모델 스스로 찾아내고 검증까지 하게 만든 시도라는 점에서 눈여겨볼 가치가 있습니다. 당장 도입 여부를 떠나, “우리 조직의 성공 기준이 검증 가능한가”라는 질문만큼은 한 번쯤 진지하게 던져볼 타이밍입니다.
이 문서는 한국 독자를 위해서 허깅페이스 블로그를 번역 및 각색하여 제공됩니다.
출처 – https://huggingface.co/blog/ServiceNow-AI/autosynthdata
함께 읽으면 좋은 글
