AI 에이전트를 팀 개발에 도입하면 처음에는 생산성이 올라가는 느낌이 납니다.
코드가 빠르게 나오고, 반복 작업이 줄어들고, 팀원들도 점점 익숙해집니다.
그런데 어느 순간 이런 상황이 생깁니다.
AI 에이전트가 만들어낸 결과물이 의도한 방식과 다르게 동작하거나,
팀이 정한 컨벤션에서 벗어난 코드가 조용히 쌓입니다.
무엇이 언제부터 어긋났는지 설명하기 어렵습니다.
느낌으로 AI 에이전트를 운영하고 있었던 것입니다.
일반적인 소프트웨어는 같은 입력에 같은 출력이 나옵니다.
에이전트를 활용한 개발은 다릅니다.
목표를 주면 AI가 스스로 판단하며 단계를 결정하고 실행합니다.
같은 명령을 줘도 매번 다른 경로로 실행될 수 있고,
중간 판단이 하나 어긋나면 결과물이 조용히 틀어집니다.
기존 테스트 방식으로는 이 문제를 잡기 어렵습니다.
"이 함수가 이 값을 리턴하는가"가 아니라,
"이 목표를 줬을 때 의도한 방식으로 실행됐는가"를 확인해야 하기 때문입니다.
OpenAI는 최근 에이전트를 체계적으로 평가하는 방법론을 정리해 공개했습니다.
Eval(평가)이라 부르는 이 접근법의 구조는 네 단계입니다.
1) 프롬프트를 실행하고,
2) 실행 결과(트레이스와 산출물)를 캡처하고,
3) 사전에 정의한 체크 항목으로 점수를 내고,
4) 그 점수를 시간이 지나도 비교합니다.
한 번의 확인이 아닙니다.
"이번 버전이 더 나은가?"라는 질문에 수치로 답할 수 있어야
개선과 퇴보를 명확히 알 수 있습니다.
체크 항목은 네 가지 관점으로 나눌 수 있습니다.
1) 결과 목표: 작업이 완료되었는가. 의도한 산출물이 나왔는가.
2) 프로세스 목표: 의도한 단계와 방식을 따랐는가.
3) 스타일 목표: 팀이 정한 컨벤션을 지켰는가.
4) 효율 목표: 불필요한 반복 없이 목표에 도달했는가.
이 네 가지를 단일 pass/fail로 합치면 안 됩니다.
각각 독립적인 시그널로 두어야
어디서 무엇이 무너졌는지 빠르게 파악할 수 있습니다.
체계적인 테스트에는 두 가지 원칙이 중요합니다.
첫째, 에이전트에게 무언가를 시키기 전에 성공이 무엇인지를 먼저 정의해야 합니다.
측정할 수 없는 기준은 기준이 아닙니다.
"잘 동작한다"는 것을 구체적인 체크 항목으로 쪼개는 과정 자체가
에이전트의 의도를 명확히 하는 작업이기도 합니다.
둘째, 수동으로 고친 것은 반드시 테스트 기준으로 만들어야 합니다.
한 번 손으로 고치고 넘어간 것은 다음에도 같은 방식으로 다시 어긋납니다.
실제 실패가 새로운 검증 기준이 되어야 합니다.
리더로서 이 방법론을 보며 든 생각이 있습니다.
AI 에이전트를 도입하는 것과 신뢰하는 것은 다른 문제입니다.
도입은 빠르게 할 수 있지만, 신뢰는 검증 체계가 갖춰졌을 때 생깁니다.
팀이 AI를 실행 주체로 쓰기 시작했다면,
그 실행을 검증하는 기준도 함께 만들어야 합니다.
에이전트가 잘 동작한다는 느낌이 아니라,
잘 동작하고 있다는 근거가 필요합니다.
에이전트를 팀에 안착시킨다는 것은
함께 신뢰할 수 있는 기준을 만드는 일에서 시작합니다.
'일과 생각' 카테고리의 다른 글
| AI는 대화를 어떻게 "기억"하는가 - 컨텍스트 윈도우와 컴팩션에 대하여 (0) | 2026.03.07 |
|---|---|
| CTO에서 CTSO로, 이사회에서 새로운 역할을 제안받았습니다. (0) | 2026.03.06 |
| 경영진으로 4년, 창업자로 1년을 보내며 배운 사업의 3요소 (0) | 2026.03.05 |
| AI 시대일수록 기술 리더가 직접 코드를 짜야 하는 이유 (0) | 2026.03.04 |
| AI-First 개발에서 기술 리더는 주니어 개발자를 어떻게 성장시킬 것인가 (0) | 2026.03.03 |