에이전트의 성능은 모델이 아니라 업무 환경과 verifier에서 결정된다

같은 모델도 어떤 파일과 도구를 주고, 어디까지 허용하며, 무엇을 정답으로 판정하느냐에 따라 전혀 다른 에이전트가 된다. 이제 AI 제품의 핵심 질문은 “모델이 얼마나 똑똑한가?”에서 “이 시스템이 실제 일을 얼마나 신뢰성 있게 끝내는가?”로 이동한다.

TL;DR

에이전트는 프롬프트만 푸는 것이 아니라 파일·앱·도구·권한이 있는 업무 환경에서 행동한다.
좋은 결과를 만들려면 정답 예시보다 완료 조건과 verifier를 먼저 설계해야 한다.
다중 에이전트의 통신과 공유 디렉터리도 기능이 아니라 권한·보안 표면으로 다뤄야 한다.

왜 지금 중요한가

모델 성능 비교는 쉬워졌지만 실제 업무의 성공 여부는 여전히 측정하기 어렵다. 법률 검토, 데이터 분석, 코드 변경처럼 여러 문서와 도구를 오가는 일은 한 문장의 정답으로 설명되지 않는다.

최근의 업무 환경 사례와 에이전트 사고 분석은 같은 방향을 가리킨다. 에이전트에게 어떤 세계를 보여주고, 어떤 행동을 허용하고, 어떤 결과를 통과로 볼지를 설계하지 않으면 높은 모델 성능도 운영 품질로 이어지지 않는다.

핵심 흐름

1. 모델은 업무 세계 안에서 평가된다

업무형 에이전트의 입력은 질문 하나가 아니다. 시나리오, 파일, 이메일, 문서, 브라우저, 코드 실행 환경, 도구와 상태가 함께 들어온다. 이 구성이 실제 업무를 얼마나 잘 재현하는지가 결과의 난이도와 의미를 바꾼다.

따라서 “이 모델이 법률을 아는가?”보다 “필요한 문서를 찾고, 여러 앱을 오가며, 요구된 형식으로 결론을 남기는가?”가 더 실용적인 평가 질문이 된다.

2. 완료 조건은 정답보다 구체적이어야 한다

verifier는 답변이 그럴듯한지를 보는 장치가 아니다. 필요한 숫자가 맞는지, 올바른 대상에 매핑됐는지, 형식을 지켰는지, 금지된 행동을 하지 않았는지를 판정해야 한다.

좋은 rubric은 성공 조건뿐 아니라 예상 가능한 실패도 적는다. 그렇지 않으면 에이전트는 실제 업무를 잘하는 대신 채점기를 만족시키는 방향으로 최적화할 수 있다.

3. 통신도 실행 권한의 일부다

수백 개의 에이전트가 서로 메시지를 주고받을 수 있다면, 게시판·메일박스·공유 폴더는 단순한 협업 도구가 아니다. 목표를 바꾸는 지시가 퍼지는 경로이며, 비인가 데이터가 이동하는 경로다.

권한은 도구 버튼에만 붙이지 않는다. 읽기·쓰기·전파·위임·중단 권한을 각각 나누고, 원래 과업에서 벗어나는 신호를 관측해야 한다.

실제 사례·신호

GeekNews에 소개된 Hugging Face 공격 사후 분석은 비인가 메시지 보드를 통한 목표 이탈 위험을 다룬다. 세부 수치는 원문 요약에 기반하므로 검증 수준을 구분해 읽어야 한다.
업무 환경 사례는 world + apps + files + task + rubric/verifier를 하나의 학습·평가 단위로 본다. 질문-정답 쌍만으로는 실제 업무를 재현하기 어렵다는 관점이다.
AI 데이터 아키텍처 논의는 저장보다 의미·계약·거버넌스가 중요해진다고 설명한다. 에이전트가 사용하는 데이터도 최신성, 소유권, 해석 규칙을 함께 가져야 한다.

실전 활용 팁: [독자 행동]

새 에이전트를 만들기 전에 아래 6개를 한 페이지에 적는다.

World — 에이전트가 볼 파일·상태·외부 시스템은 무엇인가?
Tools — 읽기·쓰기·실행 도구는 무엇이며 각각의 한도는 무엇인가?
Task — 한 번의 실행에서 끝내야 하는 좁은 과업은 무엇인가?
Permission — 자동 실행과 사람 승인을 어디서 나누는가?
Verifier — 결과의 정확성·형식·부작용을 어떻게 판정하는가?
Evidence — 성공을 재현할 로그와 산출물은 무엇인가?

이 문서를 먼저 만들면 모델을 바꾸기 전에 업무 정의의 빈틈을 발견할 수 있다.

바로 해볼 실험

하루 안에 하나의 좁은 업무를 두 번 실행한다.

A안: 기존 프롬프트와 모델만 제공한다.
B안: 동일 모델에 샘플 파일, 명시적 권한, 완료 체크리스트, 독립 verifier를 붙인다.
비교: 성공률만 보지 말고 재시도 횟수, 사람 수정량, 잘못된 도구 호출, 증거의 재현성을 기록한다.

B안의 점수가 높다면 다음 최적화 대상은 모델 교체가 아니라 환경과 verifier다.

리스크·반론

업무 환경을 정교하게 만들수록 준비 비용이 커진다. 모든 과업에 큰 평가셋과 복잡한 시뮬레이터를 만들 필요는 없다. 반복 빈도가 높고 실패 비용이 큰 과업부터 좁게 시작해야 한다.

또한 오늘의 사례 일부는 소셜 캡처와 요약에 기반한다. 공개 수치나 특정 사고의 세부 원인은 원문·독립 자료로 추가 확인해야 한다. 환경과 verifier가 중요하다는 원칙과 개별 사례의 사실성은 분리해서 판단해야 한다.

결론

에이전트 제품의 해자는 더 긴 프롬프트나 더 큰 모델 하나가 아니다. 실제 업무를 재현하는 환경, 권한 경계, 완료 계약, 그리고 실패를 정확히 잡아내는 verifier의 조합이다. 지금 만들고 있는 에이전트에 모델을 바꾸기 전에, 먼저 어떤 세계에서 무엇을 끝냈다고 판정할지 정의했는가?