AI Agent 쓰다 보면 메인 세션이 더러워진다!

요즘 Codex를 사용해서 프로젝트를 진행하고 있다.

기능을 구현하다 보면 중간중간 이런 점검이 필요해진다.

• 디자인 토큰을 제대로 사용했는지
• 성능적으로 문제가 될 부분은 없는지
• 보안 정책이 안전하게 설정되어 있는지
• 구현 방향이 프로젝트 구조와 잘 맞는지

문제는 이런 점검을 메인 Session에서 바로 시키면, 현재 작업 흐름이 쉽게 복잡해진다는 점이다.

나는 이 문제를 해결하기 위해 Codex의 subagent를 사용해보기로 했다.

Subagent는 무엇인가?

Codex의 subagent는 독립적인 agent thread를 가진다.

쉽게 말하면, 메인 Session 안에서 모든 작업을 처리하는 대신 특정 작업을 별도의 agent에게 맡기고, 메인 Session은 요약된 결과만 받는 구조다.

예를 들어 내가 메인 Session에서 아래 기능들을 구현했다고 해보자.

• 로그인 기능 구현
• 게시글 업로드 기능 구현
• 댓글 기능 구현

이후 “디자인 토큰을 제대로 사용했는지 검사하고 싶다”는 상황이 생겼다.

이때 기존에는 보통 두 가지 방식이 있었다.

방법 1. 새로운 Session을 열어서 검사하기

첫 번째 방법은 새로운 Session을 열고, 거기서 디자인 토큰 검사를 요청하는 방식이다.

이 방식의 장점은 메인 Session을 건드리지 않는다는 점이다.
하지만 단점도 명확하다.

새로운 Session은 현재 작업 맥락을 모른다.

내가 어떤 기능을 만들었는지, 어떤 파일을 수정했는지, 프로젝트에서 어떤 규칙을 쓰는지 다시 설명해야 한다.

결국 Context를 아끼려고 새 Session을 열었는데, 필요한 맥락을 다시 주입해야 하는 문제가 생긴다.

또 결과를 받은 뒤에는 다시 메인 Session으로 옮겨야 한다.

이 과정에서 일부 내용이 누락되거나, 메인 Session의 현재 판단 흐름과 어긋나는 지적이 섞일 수 있다.

정리하면 이 방식의 단점은 이렇다.

• 현재 작업 맥락을 다시 설명해야 한다.
• 결과를 다시 메인 Session으로 옮겨야 한다.
• 맥락이 분리되어 판단이 어긋날 수 있다.
• 반복하면 꽤 번거롭다.

방법 2. 현재 Session에서 바로 검사하기

두 번째 방법은 현재 Session에서 바로 요청하는 방식이다.

예를 들면 이렇게 요청하는 것이다.

지금까지 구현한 화면들이 디자인 토큰을 제대로 사용하고 있는지 검사해줘.

이 방식은 편하다.
현재 Session은 이미 작업 맥락을 알고 있기 때문에 추가 설명이 거의 필요 없다.

하지만 문제는 Context Window가 더러워진다는 점이다.

디자인 토큰 검사를 시키면 agent는 관련 파일을 탐색하고, 컴포넌트 구조를 확인하고, 토큰 정의를 읽고, 중간 판단을 한다.

성능 검사를 시키면 렌더링 구조, 리스트 처리, memo 사용 여부, 네트워크 요청 흐름까지 살펴본다.

이 과정은 검사 작업에는 필요하다.

하지만 메인 Session 입장에서는 불필요한 정보가 많이 섞이게 된다.

메인 Session은 원래 로그인, 게시글, 댓글 기능 구현 흐름을 이어가야 한다.
그런데 중간에 디자인 검사, 성능 검사, 보안 검사, 파일 탐색 로그가 끼어들면 작업 흐름이 점점 흐려진다.

Session이 길어질수록 이런 문제가 생긴다.

• 핵심 작업 맥락이 흐려진다.
• agent가 부가적인 검사 내용을 과하게 참고할 수 있다.
• 대화가 길어져 토큰 비용이 증가한다.
• 나중에 다시 읽었을 때 작업 흐름을 파악하기 어렵다.
• 메인 Session이 구현 공간이 아니라 검토 로그 저장소처럼 변한다.

즉, 편하지만 오래 쓰기에는 부담이 있다.

그래서 Subagent를 사용한다

subagent를 도입하면 구조가 달라진다.

메인 Session은 계속 기능 구현의 흐름을 유지한다.
대신 디자인 토큰 검사나 성능 검토처럼 별도의 관점이 필요한 작업은 subagent에게 맡긴다.

subagent는 독립적인 agent thread에서 작업한다.

즉, 내부적으로 파일을 읽고, 탐색하고, 판단하더라도 그 과정이 메인 Session의 Context Window를 직접 오염시키지 않는다.

메인 Session은 최종적으로 정리된 결과만 받는다.

예를 들면 이런 식이다.

• design-system subagent
  디자인 토큰, 색상, 폰트, spacing, radius 사용 검사
• performance subagent
  불필요한 리렌더링, 리스트 렌더링, 무거운 컴포넌트 검사
• supabase-rls subagent
  RLS, auth, storage policy, anon key 위험 검사
• spec-planner subagent
  기능 요구사항, 화면 흐름, 데이터 구조, 구현 순서 정리

이렇게 역할을 나누면 메인 Session은 구현에 집중하고, subagent는 특정 관점의 검토에 집중할 수 있다.

Subagent는 더 똑똑한 agent가 아니다

중요한 점은 subagent를 “더 똑똑한 agent”로 보면 안 된다는 것이다.

subagent의 핵심 가치는 지능이 아니라 작업의 격리에 있다.

하나의 agent가 모든 일을 계속 처리하면 편하긴 하다.
하지만 프로젝트가 커질수록 맥락이 쉽게 섞인다.

반대로 subagent를 사용하면 작업 단위를 분리할 수 있다.

메인 Session은 구현 흐름을 유지하고, subagent는 특정 검토 작업을 수행한다.
그리고 메인 Session은 그 결과를 요약해서 받는다.

예를 들어 이렇게 요청할 수 있다.

현재 변경사항을 기준으로 design-system subagent를 실행해서
디자인 토큰을 제대로 사용하고 있는지 검사해줘.

또는 성능 검사를 따로 맡길 수도 있다.

performance subagent를 실행해서
현재 구현에서 렌더링 성능 문제가 생길 만한 부분을 검사해줘.

이렇게 하면 메인 Session에 불필요한 탐색 과정이 쌓이지 않는다.

내가 생각하는 장점

subagent를 사용하면 역할이 명확해진다.

메인 Session은 작업 관리자에 가깝다.
전체 구현 흐름을 유지하고, 최종 판단을 내린다.

subagent는 특정 영역을 맡는 검토자에 가깝다.
필요한 파일을 탐색하고, 특정 관점에서 문제를 찾고, 요약 결과만 반환한다.

내가 느낀 장점은 아래와 같다.

• 메인 Session의 Context Window를 깨끗하게 유지할 수 있다.
• 디자인, 성능, 보안처럼 관점이 다른 작업을 분리할 수 있다.
• 중간 탐색 과정이 메인 흐름에 섞이지 않는다.
• 결과를 요약 형태로 받아서 판단하기 쉽다.
• 반복적으로 사용하는 검사 작업을 agent 역할로 고정할 수 있다.

언제 쓰면 좋을까?

모든 작업을 subagent로 나눌 필요는 없다.

작은 코드 수정이나 단순 질문은 그냥 메인 Session에서 처리하는 편이 낫다.
Codex에는 /review 같은 전용 명령도 있기 때문에, 일반적인 코드 리뷰용 subagent를 따로 만드는 것도 우선순위가 낮다고 본다.

subagent는 아래처럼 반복적이고 관점이 명확한 작업에 잘 맞는다.

• 디자인 시스템 준수 여부 검사
• 성능 병목 가능성 검사
• Supabase RLS/Auth 보안 검사
• 배포 전 체크리스트 검사
• 기능 구현 전 스펙 정리

정리

AI 코딩 에이전트를 오래 쓰다 보면 단순히 “코드를 잘 짜는가”보다 중요한 문제가 생긴다.

바로 Context 관리다.

처음에는 하나의 Session에서 모든 작업을 처리해도 괜찮다.
하지만 기능 구현, 디자인 검사, 성능 검토, 보안 점검이 한 Session 안에 계속 쌓이면 흐름이 쉽게 복잡해진다.

Codex subagent는 이 문제를 줄이는 데 도움이 된다.

핵심은 단순하다.

메인 Session은 깨끗하게 유지하고,
복잡한 검토 작업은 독립된 subagent에게 맡긴다.

나에게 subagent는 “더 많은 agent를 쓰는 기능”이라기보다,
AI와 함께 개발할 때 생기는 Context 오염을 줄이는 작업 분리 방식에 가깝다.