AI 에이전트 성능은 모델만으로 결정되지 않는다

AI 에이전트 성능은 모델만으로 결정되지 않는다

코딩 에이전트나 자동화 봇을 조금만 오래 운영해 보면 이상한 순간이 온다. 같은 모델을 붙였는데 어떤 날은 작업이 매끄럽게 끝나고, 어떤 날은 비슷한 요청도 중간에서 끊기거나 작업 흐름을 잃는다. 처음에는 이 차이를 모델 성능으로 설명하고 싶어진다. 컨텍스트가 부족한가, 추론이 약한가, 코딩 능력이 떨어지는가 같은 쪽으로 먼저 생각하게 된다.

그런데 실제로 OpenClaw 같은 자동화 시스템이나 여러 코딩 에이전트를 같이 굴려 보면, 문제는 종종 모델 자체보다 하네스(harness) 에서 난다. 여기서 하네스는 단순한 모델 wrapper가 아니라, 툴 연결, 세션 구조, 실패 복구, 로그와 상태 확인까지 포함한 운영 환경 전체를 뜻한다.

이 글은 모델이 중요하지 않다는 얘기를 하려는 게 아니다. 오히려 좋은 모델도 작업 환경이 약하면 체감 성능이 빠르게 떨어진다는 점을 정리하려는 글이다.

사람들이 모델부터 바꾸고 싶어하는 이유

AI 자동화를 붙일 때 가장 먼저 눈에 들어오는 건 모델이다.

• 어떤 모델이 더 긴 문맥을 처리하는지
• 코딩은 누가 더 잘하는지
• 설명은 누가 더 자연스러운지
• 가격 대비 성능은 어떤지

이런 비교는 당연히 필요하다. 실제로 어려운 설계 판단, 긴 코드 리팩터링, 장문 문서 이해에서는 모델 차이가 꽤 크게 난다.

문제는 운영 단계에 들어가면 모델이 좋아도 시스템이 그 능력을 제대로 꺼내 쓰지 못하는 경우가 많다는 점이다.

예를 들어:

• 코드 수정 자체는 괜찮게 제안했는데 파일 수정 툴이 불안정해서 실패
• 사용자가 다시 말하기 전까지 실패 사실을 아무도 모름
• 세션이 길어지면서 어디까지 진행했는지 문맥이 흐려짐
• 메시지는 도착했는데 실제 작업은 뒤에서 멈춤
• 오류가 나도 로그가 약해서 “모델이 별로네”로 오해함

이런 건 모델 IQ보다 실행 환경 문제에 더 가깝다.

실제로는 어디서 많이 무너지나

내가 체감한 병목은 대체로 아래 네 군데였다.

1. 툴 연결이 약할 때

파일을 읽고 수정할 수 있고, 상태를 점검할 수 있고, 필요하면 웹도 보고, 실행 결과도 다시 확인할 수 있으면 에이전트는 훨씬 현실적인 답을 준다.

반대로 툴이 없거나 불안정하면:

• 추측으로 답하고
• 사용자를 더 많이 되묻고
• 같은 말을 반복하고
• 실제 수정 대신 “이렇게 해보세요”에 머무르기 쉽다

즉, “모델이 똑똑하냐”보다 “모델이 실제로 뭘 할 수 있느냐”가 체감 차이를 만든다.

2. 세션이 작업 단위로 설계되지 않았을 때

긴 작업에서는 세션이 그냥 대화창이 아니라 작업 컨테이너처럼 동작한다.

• 어떤 파일을 봤는지
• 어디까지 고쳤는지
• 무엇이 실패했는지
• 어디서 다시 시작할 수 있는지

이 정보가 세션 구조에 달려 있다.

메인 대화, 코딩 작업, 리뷰 작업, 배경 점검 작업이 한데 섞이면 금방 흐려진다. 특히 허브가 코딩 작업까지 직접 맡도록 두면, 메시지 처리와 코드 작업이 한 세션 안에서 뒤엉켜 디버깅이 더 어려워진다.

3. 실패 복구가 없을 때

데모 단계에서는 한 번 잘 되면 충분하다. 운영 단계에서는 멈췄을 때 다시 살아나는지가 훨씬 중요하다.

예를 들어:

• Telegram 송신 실패
• polling stall
• background process 종료
• cron/타이머 미동작
• 브라우저 세션 손실

이런 문제는 더 똑똑한 모델로 해결되지 않는다. 필요한 건 보통 아래다.

• 외부 헬스체크
• 재시작 전략
• systemd / timer
• 상태 점검 루틴
• 실패 알림
• 사람이 개입할 수 있는 안전한 경로

실전에서는 정답률보다 복구 가능성이 더 중요할 때가 꽤 많다.

4. 관측 가능성이 약할 때

에이전트가 실패했을 때 최소한 아래는 보여야 한다.

• 지금 서비스가 살아 있는지
• 마지막 작업이 어디서 끝났는지
• 툴 오류인지, 모델 판단 실패인지
• 네트워크 문제인지, 권한 문제인지
• 어느 세션이 어떤 작업을 했는지

이게 없으면 모델이 약한 건지, 툴이 깨진 건지, 환경이 불안정한 건지조차 구분하기 어렵다. 운영 단계에서 관측 가능성이 약하면 개선 속도가 급격히 떨어진다.

짧은 실례 하나

이런 경우가 있다. 사용자는 텔레그램으로 분명히 작업을 지시했고, 에이전트는 응답도 보냈다. 겉으로 보면 작업이 진행된 것처럼 보인다. 그런데 실제로는 뒤에서 background process가 이미 죽어 있었고, 파일 수정 단계는 끝까지 가지 못했다.

사용자 입장에서는 “모델이 대충 말만 하고 끝났네”처럼 느껴진다. 하지만 실제 병목은 모델 판단이 아니라 작업 실행 경로와 상태 확인 구조에 있다. 이런 상황이 반복되면 모델 교체보다 먼저 운영 구조를 봐야 한다.

이런 증상은 대개 하네스 문제다

내 기준으로 아래 증상은 모델 문제보다 하네스 문제일 가능성이 높다.

• 어느 순간 답변이 안 온다
• 같은 요청을 여러 번 다시 시켜야 한다
• 특정 종류의 작업만 이유 없이 자주 실패한다
• 메시지는 오는데 실제 수정은 안 된다
• 긴 작업 결과가 사라진다
• 자동화가 한동안 돌다가 조용히 멈춘다

이럴 때 모델을 바꾸는 건 종종 가장 마지막 선택지다. 보통은 먼저:

• 툴 연결
• 서비스 상태
• 세션 구조
• 재시도/복구 설계
• 로그/상태 확인 경로 를 본다.

그럼 모델은 언제 중요해지나

물론 모델이 중요한 순간은 분명히 있다.

• 긴 설계 판단
• 복잡한 리팩터링
• 장문 문서 이해
• 긴 문맥 유지
• 자연스러운 설명
• 애매한 요구사항 해석

즉,

• 무엇을 풀 수 있느냐는 모델 영향이 크고
• 그 능력을 얼마나 안정적으로 꺼내 쓰느냐는 하네스 영향이 크다

라고 보는 편이 맞다.

내가 선호하는 구조

내 기준으로는 아래처럼 나누는 게 덜 꼬인다.

OpenClaw 같은 허브

• 메시지 수신
• 사용자 요청 해석
• 툴 실행 진입점
• 세션 오케스트레이션(작업 분배와 조율)
• 상태 점검
• 결과 전달

코딩 에이전트

• 코드베이스 탐색
• 구현
• 테스트
• 리팩터링
• 리뷰 반영

로컬/on-device 보조

• 빠른 분류
• 요약
• 민감 정보 전처리
• 저지연 작업

이렇게 역할을 나누면 문제 발생 시 원인도 더 쉽게 좁혀지고, 각 계층의 책임도 분명해진다.

모델을 바꾸기 전에 먼저 확인할 5가지

모델 교체 전에 아래 다섯 가지를 먼저 보는 편이 좋다.

1. 툴 연결이 실제 작업에 필요한 수준으로 열려 있는가
2. 세션이 작업 단위로 분리돼 있는가
3. 실패 시 재시도/재시작 경로가 있는가
4. 로그와 상태 확인 경로가 충분한가
5. 외부 헬스체크나 watchdog이 있는가

이 다섯 가지가 약하면, 더 좋은 모델을 붙여도 체감 개선이 제한적일 때가 많다.

처음 설계할 때 추천하는 순서

처음부터 복잡하게 갈 필요는 없다. 보통은 아래 순서가 좋다.

1. 메인 허브 + 메인 작업기 하나
2. 상태 확인 경로 확보
3. 실패 복구 추가
4. 배경 자동화 추가
5. skill / reference 구조 추가
6. 필요할 때만 on-device 보조 추가

이 순서로 가야 “일단 돌아가는 구조”를 먼저 만들고, 나중에 안정성을 덧붙일 수 있다.

마무리

AI 에이전트 성능은 모델만으로 결정되지 않는다. 좋은 모델은 분명 중요하지만, 운영 단계에서 체감 차이를 만드는 건 그 모델이 들어 있는 작업 환경 전체인 경우가 많다.

정리하면:

• 모델은 능력을 결정한다
• 하네스는 안정성과 재현성을 결정한다
• 실전에서는 똑똑함보다 복구력과 관측 가능성이 더 중요할 때가 많다

그래서 에이전트를 평가할 때는 “어려운 문제를 얼마나 잘 푸는가”만 보지 말고, 실패했을 때 얼마나 빨리 원인을 드러내고 다시 시도할 수 있는가까지 같이 봐야 한다.