에이전트 실전 투입 전, 피드백 루프부터 만들어라

에이전트가 실전에서 조용히 망가지는 건 모델 성능 문제가 아닌 경우가 대부분이다. 피드백이 없으니 잘못되는 걸 아무도 모르는 것. 그 사실을 $5억짜리 투자 딜 하나가 다시 일깨워줬다.

Mecka AI라는 2년 된 스타트업이 세쿼이아 리드로 $500M 밸류에이션을 눈앞에 두고 있다. 이 회사가 하는 일은 단순하다 — 로봇이 학습할 고품질 시연 데이터(demonstration data)를 만드는 것. 사람이 직접 작업을 수행하고, 그 동작 궤적을 정밀하게 수집·라벨링한다. 물리적 세계에서 로봇을 훈련시키려면 인터넷 텍스트를 긁어오는 것만으론 안 된다. "좋은 동작이 뭔지"를 직접 보여주는 데이터가 필요하다.

여기서 멈추지 않고 한 겹 더 들어가야 한다. 이 논리는 LLM 에이전트에도 정확히 동일하게 적용된다.

단, 이걸 그대로 따라 하려 하면 함정이 있다. 피드백 루프를 "완성된 구조"로 처음부터 만들려다가 아무것도 못 만드는 게 가장 흔한 실패다. 그 함정을 피하는 방법이 뒤에 있다.

모델보다 피드백 루프가 먼저다

우리 팀이 블로그 자동발행 에이전트를 처음 붙였을 때, 솔직히 "모델만 좋으면 되겠지"라고 생각했다. Claude Sonnet 쓰면 충분할 거라고. 그런데 실제로 운영해보니 문제는 모델이 아니었다. 어떤 출력이 좋고 어떤 게 나쁜지를 에이전트에게 체계적으로 알려주는 구조가 없었던 거다.

로봇 세계에서 Mecka AI가 해결하는 문제와 같다. 모델(로봇 제어 신경망)은 이미 충분히 발전했다. 부족한 건 "이 동작은 맞고, 저 동작은 틀렸다"는 정확한 피드백 데이터다. 에이전트도 마찬가지다. GPT-4o든 Claude든 모델 자체보다, 그 모델이 생성한 출력에 대해 "이건 좋은 출력, 이건 나쁜 출력"을 기록하고 다음 프롬프트에 반영하는 루프가 실전 성능을 결정한다.

최근 OpenAI 수학 문제 해결 관련 논란이 이 지점을 정확히 건드린다. 모델이 정답을 냈는데 풀이 과정이 왜곡된 경우, 외부에서 볼 때 맞는 것 같아도 내부 추론 경로가 신뢰할 수 없는 경우들이 보고됐다. 평가 파이프라인 없이 출력 결과만 믿으면 이런 조용한 실패를 아무도 못 잡는다.

작은 팀이 이걸 신경 써야 하는 이유

Mecka AI처럼 데이터 라벨러 수백 명을 고용할 수는 없다. 하지만 핵심은 규모가 아니라 구조다.

작은 팀일수록 에이전트 출력을 사람이 다 검수하기 어렵다. 그래서 자동 평가 레이어가 없으면 문제가 쌓이다가 한꺼번에 터진다. AdSense 반려, 독자 이탈, 잘못된 정보 발행 — 이런 사고가 터지고 나서야 "아, 에이전트가 이렇게 망가지고 있었구나"를 알게 된다.

수치로 보면 명확하다. 우리 블로그 봇은 본문 1500자 미달 시 재생성을 한 번 하고, 그래도 안 되면 발행을 스킵하는 코드 게이트를 두고 있다. 이 하나의 룰만으로 AdSense "저가치 콘텐츠" 반려 리스크가 눈에 띄게 줄었다. 반면 이 게이트가 없을 때는 500자짜리 글이 그냥 올라가도 아무도 몰랐다. 구조가 없으면 실패가 조용히 누적된다.

우리가 이미 하는 것, 그리고 결정적으로 빠진 것

HEDVION 인프라를 보면 기초적인 피드백 루프는 있다. discord-review.service가 5초 폴링으로 발행된 글을 자동 검수하고 REJECT/WARN/OK를 판정한다. 매일 새벽 4시에는 learn-update.py가 learned/{slug}.json을 갱신해 다음 발행 시스템 프롬프트에 주입된다. 나쁘지 않은 구조다.

그런데 결정적인 게 빠져 있다. REJECT 이유의 분류.

지금은 "이 글이 거부됐다"는 사실은 기록되지만, 왜 거부됐는지가 구조화되지 않는다. 사실 오류인지, 문체 문제인지, 광고 정책 위반인지, 길이 문제인지. 이 분류 없이는 learned.json이 "이런 게 나쁘다"는 구체 정보를 담기 어렵다. 로봇으로 치면 "이 동작이 틀렸다"는 것만 알고 "무엇이 틀렸는지"를 모르는 것과 같다.

Mecka AI가 $5억짜리 사업이 된 이유가 바로 여기 있다. 단순 성공/실패 라벨이 아니라, 실패의 성격을 정밀하게 분류한 데이터를 만드는 것. 그게 모델 성능을 실제로 끌어올리는 원천이다.

실제로 붙이면 어떻게 달라지나

blog 봇이 글을 발행하면 discord-review.service가 검수한다. 지금은 REJECT가 나오면 ARCHIVED 처리로 끝이다. 여기서 한 단계를 더 넣는다 — REJECT 이유를 태그로 분류해서 저장하는 것.

예를 들어 reject_reason: "factual_error", reject_reason: "low_quality_prose", reject_reason: "policy_violation" 식으로. 이 데이터가 learned.json에 쌓이면, 다음 발행 때 시스템 프롬프트에 이렇게 들어간다: "최근 거부된 글 중 사실 오류가 3건 발생했습니다. 구체 사례: [예시]". 에이전트는 추상적인 지시보다 구체적인 실패 사례에 훨씬 강하게 반응한다.

또 하나. 지금 리뷰 검수는 글 단위로만 한다. 특정 주제군에서 reject율이 높은지, 특정 프롬프트 변형에서 성능이 더 나은지는 집계되지 않는다. 이걸 추적하면 에이전트 개선 방향이 명확해진다. "프롬프트를 더 잘 써야지"가 아니라 "topic=finance일 때 reject율이 28%인데 lifestyle은 6%다, 왜 그럴까"로 질문이 바뀐다.

데이터가 없으면 개선이 아니라 추측이 된다.

지금 당장 쓸 수 있는 시사점

첫째, REJECT 이유 분류부터 시작한다. 자동화가 어려우면 Discord에서 수동으로 태그를 달아도 된다. 일주일치 REJECT 목록을 보고 패턴이 보이면 그게 다음 프롬프트 개선의 입력이다. 완성된 구조를 한 번에 만들려다 아무것도 못 하는 것보다, 스프레드시트 하나에 수동으로 기록하는 게 낫다.

둘째, 평가 지표를 하나라도 수치화한다. "글 품질이 좋아진 것 같다"는 느낌이 아니라, reject율이 이번 주 12%에서 다음 주 8%로 떨어졌다는 수치로 확인해야 한다. 지표 없이는 개선했는지 아닌지 알 수 없다. slug별 weekly reject율 집계 쿼리 하나면 된다.

셋째, 성공 케이스도 저장한다. Mecka AI의 robot demonstration data는 좋은 동작 예시를 수집하는 것이기도 하다. 품질이 좋아서 OK가 된 글, 특히 트래픽 반응이 좋았던 글을 learned.json에 "positive example"로 태깅하면 에이전트 출력의 기준점이 올라간다. 나쁜 예시만 피하게 하는 것보다 좋은 예시를 따르게 하는 게 더 효과적인 경우가 많다.

마지막으로 — OpenAI 수학 논란이 보여주듯, "출력이 맞는 것처럼 보인다"는 것과 "실제로 맞다"는 건 다르다. 에이전트 출력을 신뢰하기 전에 한 번 더 검증하는 레이어가 있어야 한다. 그 레이어를 만드는 것 자체가 작은 팀의 가장 중요한 AI 실전 적용 작업이다. 모델을 바꾸는 것보다, 평가하는 구조를 먼저 갖추는 것이 순서다.

원문: AI News & Artificial Intelligence | TechCrunch