코딩 에이전트 Plan-Act 모델 분리, 한도 안에서 버티는 실전 조합
설계는 느린 Pro, 실행은 빠른 Flash로 나눴을 때 실제로 무엇이 달라지는지, 노션 메모와 블로그 자동화 작업에서 겪은 한도·지연·실패 패턴을 정리한다.
블로그 자동화를 돌리면서 같은 작업 안에서 모델을 두 갈래로 쓰기 시작했다. 아키텍처를 짜고 원인을 좁히는 단계는 응답이 느려도 추론이 긴 모델, 파일을 고치고 빌드를 확인하는 단계는 빠르고 호출 한도가 넉넉한 모델. 노션에 적어 둔 코딩 에이전트 메모에도 이 조합이 반복해서 나온다. 이름은 제각각이지만 실무에서는 결국 Plan-Act 분리로 수렴한다.
사실: 왜 나누기 시작했는가
증상은 단순했다. 한 모델에 설계·디버깅·파일 수정·빌드 검증까지 몰아넣으면, 복잡한 단계에서 토큰과 요청 한도가 먼저 닳는다. 특히 “왜 relatedSlugs가 빠지지?” 같은 문제는 원인 후보가 여럿인데, 같은 세션에서 곧바로 여러 파일을 고치려 하면 중간 추론이 짧아지고 엉뚱한 수정으로 이어진다.
노션 메모에는 대략 이런 구분이 적혀 있었다. Plan(설계·분석·딥 디버깅) 은 느려도 되는 고추론 모델, Act(파일 생성·수정·도구 실행) 은 빠르고 호출 제한이 넉넉한 모델. Flash 계열은 단독으로 복잡한 구조 설계에 한계가 있고, Pro 계열은 첫 응답까지 시간(TTFT)이 길어 단순 편집만 반복하면 비용 대비 답답하다는 메모도 함께 적혀 있었다.
실제로 이 레포에서 카테고리별 글을 여러 편 쓸 때, 유사도 게이트와 frontmatter 검증을 Plan 쪽에 맡기고, 통과한 초안의 문장 다듬기와 npm run build 확인은 Act 쪽에 맡기면 호출 수는 늘어도 재시도 루프가 짧아졌다. Plan이 “이번 주제는 finance, 각도는 세제 후 매물 증가”까지 고정해 주면 Act가 엉뚱한 카테고리 파일을 만들 확률이 줄어든다.
이유: 한도·지연·역할이 겹치면 생기는 일
에이전트 호스트마다 요청 한도가 다르다. 메모에 적힌 예시만 봐도 Pro급은 5시간당 15회, Flash급은 60회처럼 한도 격차가 크다. 설계 단계에서 Pro를 여러 번 돌리면 Act에 쓸 여유가 바로 줄어든다. 반대로 Act에 Flash만 쓰면 파일 수정은 빠르지만, “왜 빌드는 되는데 카테고리 리드가 안 바뀌지?” 같은 질문에 표면적인 답만 받고 끝나는 경우가 많다.
또 하나는 컨텍스트 오염이다. Plan이 길게 추론한 뒤 같은 스레드에서 Act까지 이어가면, 이미 쓴 가설이 Act의 수정 방향을 고정해 버린다. 브랜치를 나누듯 세션을 나누거나, Plan 출력을 짧은 체크리스트로만 넘기면 Act는 “무엇을 고칠지”만 받고 실행에 집중할 수 있다. git에서 feature/와 hotfix/를 섞지 않는 것과 비슷한 이치다.
평가: 추천 조합과 막히는 지점
노션 메모 기준으로 가성비 조합은 대체로 이렇게 정리된다. Plan: Pro + 높은 reasoning, Act: Flash + 낮은 reasoning. 대규모 코드베이스를 처음 훑을 때는 Plan에 긴 컨텍스트 모델을 쓰고, 구현은 Flash나 중간급 코딩 모델로 넘긴다.
다만 이 조합이 만능은 아니다. Plan이 만든 체크리스트가 모호하면 Act는 빠르게 잘못된 파일을 여러 번 고친다. 그래서 Plan 산출물에는 검증 가능한 항목만 남기는 습관이 필요하다. “SEO를 개선한다”가 아니라 “relatedSlugs가 존재하지 않는 슬러그면 빌드 전에 grep으로 걸러낸다”처럼 말이다.
에이전트 워크트리 격리 환경에서는 복합 bash가 막히기도 한다. Act 단계에서 for 루프로 여러 URL을 한 번에 검증하려다 거부되면, Plan에서 “URL은 개별 curl로 검증”이라고 미리 적어 두는 편이 낫다. 모델을 나눠도 도구 제약은 공유되기 때문이다.
부연: 어디에 안 쓰는지
Plan-Act 분리는 한 줄짜리 오타 수정이나 이미 정해진 템플릿 채우기에는 오버킬이다. 오히려 세션 전환 비용만 든다. 반대로 장애 원인이 불명확하거나, 카테고리·보안 필터·유사도 게이트가 동시에 걸린 블로그 자동화처럼 판단과 실행이 섞인 작업에는 효과가 크다.
모델 이름은 분기마다 바뀐다. 메모에 있는 ID를 그대로 따르기보다, 느린 고추론 = Plan, 빠른 실행 = Act 역할만 유지하면 된다. API 키·엔드포인트·내부 한도 수치는 글에 넣지 않았다. 독자 환경의 한도표를 보고 Plan 호출 횟수 상한을 스스로 정하는 것이 안전하다.
다음에 볼 포인트는 두 가지다. Plan 출력을 JSON 체크리스트로 고정해 Act 파싱 실패를 줄일 수 있는지, 그리고 빌드 실패 시 Plan으로 되돌릴지 Act에서만 재시도할지 실패 라우팅 규칙을 명시하는 것이다. 지금은 “Plan이 주제를 고정하고 Act가 파일을 쓴다”는 최소 규칙만으로도 한도 소진 속도는 눈에 띄게 줄었다.
출처
- Notion 시드: «커서 사용 가이드» — Plan-Act 모델 비교·추천 조합 요지만 (API 키·엔드포인트 제외)
- 내부 실측: 블로그 자동화 세션에서 Plan/Act 분리 후 재시도 횟수·빌드 실패 패턴 관찰 (2026-08-09)