AI 에이전트 성능은 모델보다 작업 분해와 세션 구조에서 더 크게 갈린다

AI 에이전트 성능은 모델보다 작업 분해와 세션 구조에서 더 크게 갈린다

AI 에이전트 얘기를 하면 대부분 모델 비교부터 시작한다. 어떤 모델이 코드를 더 잘 쓰는지, 긴 문맥을 더 오래 잡는지, 설명이 더 자연스러운지 같은 이야기다. 물론 중요하다. 그런데 실제로 자동화를 운영해 보면 체감 성능을 바꾸는 건 의외로 다른 데 있을 때가 많다.

같은 모델을 써도 어떤 에이전트는 일을 차분하게 끝내고, 어떤 에이전트는 금방 흐트러진다. 차이는 종종 모델 능력보다 작업을 어떻게 나눴는지, 세션을 어떻게 분리했는지, 병렬 작업을 어떤 규칙으로 굴리는지에서 난다.

최근 GeekNews에서도 Claude Code의 숨겨진 기능들, 세션 포크, 병렬 워크트리, 하네스 설계 같은 이야기가 같이 보였다. 이 글은 그중에서도 특히 작업 분해와 세션 구조가 체감 성능을 어떻게 바꾸는지에 초점을 둔다. 같은 모델이라도 작업을 어떤 단위로 끊고, 어떤 세션에 배치하느냐에 따라 결과 품질이 크게 달라진다.

왜 같은 모델인데 결과가 달라지나

실전에서 자주 보는 차이는 이런 식이다.

• 하나의 긴 세션에 모든 일을 몰아넣으면 금방 흐려진다
• 반대로 작업을 잘게 나누고 역할을 분리하면 훨씬 안정적이다
• 실패했을 때 다시 시작할 수 있는 세션은 체감 성능이 높다
• 같은 모델이라도 병렬 작업 규칙이 없으면 오히려 품질이 떨어진다

즉, 에이전트의 체감 성능은 “얼마나 똑똑한가”만이 아니라 얼마나 덜 엉키게 설계했는가에도 크게 좌우된다.

모델보다 먼저 성능을 바꾸는 요소들

내 기준으로 실제 차이를 많이 만드는 건 아래 네 가지다.

1. 작업 분해

큰 작업을 한 번에 던지면 결과 편차가 커진다.

반대로 아래처럼 나누면 안정성이 올라간다.

• 요구사항 정리
• 작업 범위 확인
• 구현
• 검증
• 리뷰
• 결과 요약

이건 코딩 작업뿐 아니라 글쓰기, 운영 점검, 상태 확인도 마찬가지다.

2. 세션 구조

세션이 단순 채팅창이 아니라 작업 컨테이너처럼 설계돼야 한다.

예를 들면:

• 메인 세션: 요청 해석, 작업 분배
• 구현 세션: 실제 코드 수정
• 리뷰 세션: 리스크 점검
• 조사 세션: 외부 근거 확인

이렇게 나누면 같은 모델이어도 훨씬 덜 꼬인다.

3. 병렬 실행 규칙

병렬 실행은 빠르지만, 규칙 없이 돌리면 오히려 더 위험하다.

• 누가 소스 오브 트루스인지
• 어떤 작업은 직렬이어야 하는지
• 어떤 결과를 먼저 합칠지
• 충돌 시 누가 멈출지

이 기준이 없으면 속도는 빨라져도 품질은 떨어지기 쉽다.

4. 실패 후 복귀 경로

잘 되는 자동화보다 실패해도 다시 이어지는 자동화가 실제로 더 유능하게 느껴진다.

• 마지막 성공 단계 기록
• 실패한 세션 위치 확인
• 부분 성공과 전체 성공 구분
• 재시도 규칙

이런 게 있으면 모델이 조금 흔들려도 전체 체감 품질이 덜 무너진다.

왜 작업 분해가 먼저냐

AI 에이전트는 애매한 요청도 일단 뭔가로 바꾸려는 경향이 있다. 이게 장점이기도 하지만, 큰 작업에서는 오히려 위험하다.

예를 들어 이런 요청은 흔들리기 쉽다.

• “알아서 다 고쳐줘”
• “이거 전체적으로 개선해줘”
• “블로그 글 하나 써줘”

반대로 이렇게 나누면 훨씬 낫다.

• 범위: 어느 파일 / 어느 주제 / 어느 서비스인지
• 목표: 무엇을 바꿔야 하는지
• 검증: 무엇으로 확인할지
• 출력: 무엇을 남길지

작업 분해가 잘 되면 모델이 바뀌어도 품질 하한선이 유지된다.

세션 구조가 성능을 바꾸는 이유

사람도 마찬가지지만, 에이전트도 한 세션 안에 너무 많은 역할이 섞이면 금방 성격이 무너진다.

예를 들어 메인 허브가 동시에:

• 사용자 응답도 하고
• 코드 수정도 하고
• 리뷰도 하고
• 외부 조사도 하고
• 상태 보고도 하면

결국 맥락이 섞인다.

세션 구조가 좋은 시스템은 보통 아래가 분리돼 있다.

• 사용자 대화
• 실제 구현 작업
• 리뷰
• 긴 배경 작업
• 상태 확인

이렇게 나누면 단순히 보기 좋다는 수준이 아니라, 실패 원인도 더 빨리 좁혀진다.

병렬 실행은 성능 향상이 아니라 조율 문제다

병렬 실행은 요즘 에이전트 도구에서 자꾸 강조되는 기능이다. 실제로 잘 쓰면 좋다. 하지만 무조건 많이 돌린다고 성능이 좋아지진 않는다.

예를 들어 아래는 병렬로 돌리기 좋다.

• 여러 자료 조사
• 독립된 파일 분석
• 리뷰 후보 여러 개 비교
• 초안 후보 생성

반대로 아래는 함부로 병렬화하면 충돌이 난다.

• 같은 파일 수정
• 같은 브랜치에 연속 반영
• 이전 결과를 전제로 하는 작업
• 검증 전에 다음 단계가 이어지는 작업

즉, 병렬 실행은 “더 빠르게”의 문제가 아니라 무엇을 동시에 해도 되는지 구분하는 문제다.

실제로 유능해 보이는 에이전트의 공통점

내가 보기에 실제로 유능하게 느껴지는 에이전트는 보통 이런 특징이 있다.

• 작업 단위가 짧고 선명하다
• 세션 역할이 분리돼 있다
• 실패했을 때 다시 이어갈 수 있다
• 검증 단계가 있다
• 병렬 실행이 무질서하지 않다
• 최종 결과를 사람이 검토하기 쉽게 요약한다

재밌는 건 이 중 대부분이 모델 스펙보다 운영 구조의 품질에 가깝다는 점이다.

내가 선호하는 최소 구조

복잡하게 가지 않아도, 아래 정도만 있어도 체감이 확 달라진다.

1. 메인 허브 하나

• 사용자 요청 해석
• 작업 라우팅
• 결과 종합

2. 구현 세션 하나

• 실제 코드 변경
• 테스트 실행

3. 리뷰 세션 하나

• 리스크 확인
• 누락 점검

4. 상태 확인 경로 하나

• 마지막 성공 단계
• 실패 위치
• 재시도 가능 여부

이 정도만 있어도 “모델이 들쭉날쭉하다”는 느낌이 꽤 줄어든다.

바로 적용할 체크리스트

에이전트 자동화가 자꾸 흐트러진다면 아래만 먼저 봐도 좋다.

1. 큰 작업을 너무 한 번에 던지고 있지 않은가
2. 메인 세션이 너무 많은 역할을 동시에 맡고 있지 않은가
3. 병렬 실행 기준이 없는 상태로 여러 작업을 동시에 돌리고 있지 않은가
4. 실패 후 어디서부터 다시 시작할지 모르는 구조는 아닌가
5. 구현과 검증이 한 단계로 뭉개져 있지 않은가

이 중 몇 개만 고쳐도 체감 성능이 달라진다.

마무리

AI 에이전트 성능은 분명 모델 영향을 받는다. 하지만 실전에서는 그것만으로 설명되지 않는 차이가 크다. 같은 모델이어도 어떤 시스템은 유능하고, 어떤 시스템은 금방 흐트러진다.

그 차이를 만드는 건 종종 아래다.

• 작업 분해
• 세션 구조
• 병렬 실행 규칙
• 실패 후 복귀 경로

그래서 에이전트를 더 잘 쓰고 싶다면, 다음에는 모델 비교표만 보지 말고 이 일을 어떻게 쪼갤지, 어떤 세션에 맡길지, 실패하면 어디서 다시 시작할지부터 먼저 설계해 보는 편이 낫다.