이 기사는 GitHub Copilot app 상에서 /chronicle tips를 실행하여 얻은 분석 결과를 바탕으로 하고 있습니다.

GitHub Copilot app을 일상적으로 사용하다 보면, /usage로 이용량을 확인할 기회가 많아지죠. 저도 그랬습니다. 다만, "얼마나 사용했는지"는 보이지만, 왜 그렇게까지 늘어났는지는 의외로 알기 어렵습니다.

그래서 이번에는 최근 30일간의 이용 데이터를 재검토하여, 어떤 사용 방식에서 billable 토큰(과금 대상 토큰)이 팽창하기 쉬운지 정리했습니다. 결론부터 말씀드리면, 적어도 이번 데이터에서는 비용이 많이 발생한 주된 원인이 "출력이 길기 때문"이라기보다, 긴 세션의 후반부에서 동일한 커다란 입력 컨텍스트 (Input Context)를 반복해서 다시 보냈기 때문인 것으로 보였습니다. 이 부분이 이번의 가장 중요한 발견입니다. 🪙

관련 기사로서, 저는 지금까지 GitHub Copilot app / CLI의 구분 사용법이나 다중 에이전트 (Multi-agent) 설계에 대해서도 써왔습니다. 이번 기사는 그 실천 편에 가까운 위치에 있습니다.

• 다음 큰 작업을 GitHub Copilot CLI부터 시작하고 싶어지는 이유
• 커스텀 에이전트 (Custom Agent) 호출 방식으로 생각하는 Copilot CLI와 VS Code Agent Mode
• GitHub Copilot CLI로 생각하는 다중 에이전트 설계

본 기사는 이미 GitHub Copilot app을 일상적으로 사용하고 있으며, 이 이상의 편리함을 떨어뜨리지 않으면서 낭비되는 토큰만 줄이고 싶은 분들을 위해 작성되었습니다. 단순한 절약 기술이 아니라, 세션 설계 (Session Design)의 관점에서 읽어주시면 감사하겠습니다. ✨

이 기사에서는 다음을 목표로 합니다.

• ✅ 최근 30일간의 Copilot 이용 데이터로부터 무엇이 무거웠는지 정리한다
• ✅ 입력 컨텍스트 (Input Context)의 재전송이 주된 원인으로 보이는 것을 구체적인 사례와 함께 설명한다
• ✅ /compact, /new, /delegate, /model, .github/copilot-instructions.md 등을 사용하여 낭비되는 토큰을 줄이는 실천책을 5가지로 압축하여 제시한다
• ✅ /usage는 유용하지만, 절약은 세션 구조의 변경을 통해 이루어진다는 점을 명확히 한다

읽고 난 뒤에 독자분들이 "다음의 긴 글 작성이나 조사 태스크에서는, 어디서 세션을 끊을지를 먼저 결정하자"라고 생각할 수 있는 상태를 목표로 합니다.

먼저, 이번에 살펴본 범위를 명확히 하겠습니다.

항목	이번의 취급	보충
🖥️ GitHub Copilot CLI	대상	과금 대상 이용의 중심이었기 때문에
...

여기서 한 가지만 보충하겠습니다. 실제 조작 인터페이스는 GitHub Copilot app이지만, 이번에 참조한 세션 스토어(Session Store)에서는 agent_name이 Copilot CLI로 기록되어 있었습니다. 따라서 본 기사에서는 조작 경험은 app, 집계 라벨은 Copilot CLI라는 전제로 수치를 읽고 있습니다.

이번 30일간의 데이터에서는 과금 대상의 거의 모든 것이 세션 스토어 상의 Copilot CLI 라벨에 집중되어 있었습니다. 225 세션으로, 합계는 약 195,166,995 토큰입니다. 반면, Copilot Coding Agent는 단 1 세션뿐이었으며, billable 토큰은 0이었습니다. 즉, 이 데이터셋에 한정하면, 절감 대상은 거의 평소 사용 중인 app 측 세션의 설계 그 자체입니다. 참고로 본 기사의 수치는 2026-07-06 시점의 집계입니다.

이 기사에서 다루는 "비용"은 정확히는 금액이 아니라 billable 토큰의 낭비입니다. 금액이 신경 쓰이는 상황에서도, 우선 토큰이 늘어나는 구조를 없애는 것이 재현 가능한 개선책이 됩니다.

본 기사에서 다루는 GitHub Copilot CLI의 기능은 다음의 GitHub 공식 문서를 전제로 합니다.

• /compact와 긴 세션의 문맥 관리 (Context Management)
• /new, /model, /init 등의 슬래시 커맨드 (Slash Command) 목록
• /delegate의 동작 설명
• .github/copilot-instructions.md에 의한 리포지토리 커스텀 지시
• 프로젝트 스킬 (Project Skill, .github/skills/ / .agents/skills/ 등)로서의 SKILL.md

이후의 개선안은 이러한 기능 설명과 이번 실측 데이터 모두를 바탕으로 작성해 나가겠습니다.

그럼 먼저 전체적인 모습을 살펴보겠습니다.

가장 눈에 띄는 것은 기사 작성 워크플로우 (Workflow)의 비중이었습니다.

분류	세션 수	합계 토큰	1 세션 평균
🧱 세션 스토어 상의 Copilot CLI 라벨 전체	225	195,166,995	867,409
...
이 두 줄만으로도 상황이 매우 명확합니다. 기사 작성 세션 40개만으로 거의 1.9억 토큰을 다 쓰고 있는 상태입니다. 게다가 평균이 450만~500만 토큰대이므로, 짧은 상담이 아니라 길게 지속된 세션이 많았음을 알 수 있습니다.

모델별로 보더라도 무거운 처리가 특정 모델에 쏠려 있었습니다. 여기서는 전체 중에서도 사용량이 많았던 주요 모델을 나열합니다.

모델	합계 토큰
🧠 claude-sonnet-4.6	74,783,370
...
다만, 여기서 중요한 것은 "어떤 모델이 나쁜가"가 아닙니다. 긴 문맥 (Context)을 품은 채로 여러 번 호출하면 어떤 모델이든 토큰은 늘어난다는 점입니다. 이번에는 그 구조를 살펴보겠습니다.

슬래시 명령어 (Slash Command)의 사용 방식도 상징적이었습니다.

명령어	30일간 이용 횟수	읽기
/usage	30	상당히 사용함
/new	1	거의 사용하지 않음
/compact	0	전혀 사용하지 않음
/delegate	0	전혀 사용하지 않음

즉, 측정은 하고 있지만, 끊거나(Cut) 압축하거나(Compress) 분리하는(Separate) 행동으로는 이어지지 않고 있는 것입니다. 이 부분이 개선 여지가 매우 크다고 느꼈습니다.

이번에 가장 강력하게 드러난 낭비 패턴은 거대한 입력 컨텍스트 (Input Context)의 재전송입니다.

대표적인 세션을 나열하면 경향이 잘 보입니다.

세션	턴 (Turn) 수	과금 이벤트 수	입출력 비	관측된 증가 방식
🧾 Fluent UI 2 Text 기사 작성	9	201	83.8	입력이 약 52K → 약 144K까지 증가
...
특히 Fluent UI 2 Textarea

후반부의 1 이벤트당 평균 입력이 44,221 증가했습니다. 후반부를 약 43개 이벤트로 단순 산출하면, 약 190만 입력 토큰입니다. 즉, 후반부 대화에서 무언가 극적으로 새로운 일을 했다기보다, 전반부에서 쌓인 문맥을 그대로 품은 채 비슷한 조작을 반복했을 가능성이 높습니다.

구조를 도식화하면 다음과 같은 이미지입니다.

이 도식의 포인트는 뒤쪽 턴(Turn)으로 갈수록 "이번 요청"보다 "과거 이력의 동반 비용"이 커진다는 점입니다. 따라서 절약하고 싶다면, 세션을 끊거나 / 압축하거나 / 분리하는 것이 효과적입니다.

그럼 이제부터 실천 방안을 5가지로 압축하여 살펴보겠습니다.

이는 agent / skill 설계 개선책입니다. 이번 케이스에서는 이 부분이 가장 상류(Upstream)에 있는 개선 포인트였습니다.

동일한 집필 스타일이나 워크플로우 설명이 세션마다 몇 번이고 재주입되고 있었습니다. 이는 한 번마다의 차이는 작아 보여도, 쌓이면 확실히 영향을 미칩니다.

게다가 이번에는 단순히 "사용자가 긴 지시를 작성해 버린" 것만이 아닙니다. 실제로 이 리포지토리의 zenn-article-orchestrator는 집필 → 병렬 리뷰 → 지적 통합 → 일괄 반영 → 완성 판정까지 수행하며, 공개 가능한 품질까지 완성하도록 설계되어 있습니다. 즉, 기사를 끝까지 완성한다는 전제의 긴 고정 규칙이 agent 측에 모이기 쉬우며, 이 부분이 비대해진 상태라면 사용자의 노력만으로는 비용을 다 낮출 수 없습니다.

write-qiita-article : 35회, 합계 약 289,368자, 평균 약 8,268자
qiita-cli-workflow : 35회, 합계 약 106,382자, 평균 약 3,039자

• 합계하면 약 395,750자
• 현재 리포지토리에는 .github/agents와 .agents/skills/는 있지만, .github/copilot-instructions.md는 없음
• 실제 zenn-article-orchestrator

는 리뷰 라운드(review round)와 완성 판정까지 포함하여 기사를 완성하는 통합 에이전트(integrated agent)로 정의되어 있다.

즉, 이번 논점은 "skills가 없어서 매번 길어지는 것"이 아닙니다. skills는 이미 존재함에도 불구하고, 그럼에도 불구하고 orchestrator 측이 마무리 단계까지 떠안기 쉬운 점에 있습니다.

글자 수를 상당히 거친 기준으로 4자 = 1 토큰이라고 가정하더라도, 재주입(re-injection) 분량만으로 약 9.9만 토큰 상당입니다. 일본어에서는 엄격한 환산은 아니지만, 적어도 "반복해서 붙여넣고 있다는 전제가 무시할 수 없는 양이 되고 있다"는 점은 알 수 있습니다.

상태	개선 전	개선 후
🎛️ 오케스트레이터(Orchestrator) 설계	skills가 있어도 에이전트가 마무리까지 떠안으며, 긴 고정 규칙을 매번 전제로 삼기 쉬움	agent는 역할 분담과 흐름만 가지며, 상세 규칙은 기존 skills / instructions로 최대한 넘김
📚 공유 규칙	매번 프롬프트에 길게 붙여넣음	.github/copilot-instructions.md에 상설
🧩 재사용 절차	skill이 있어도 orchestrator 측에 상세 규칙을 중복해서 가지기 쉬움	기존의 .agents/skills/를 활용하여 agent 측의 중복 규칙을 줄임
🚀 초기 정비	세션마다 매번 설명	copilot init 등의 초기 유도 이후, 리포지토리 측에 고정

이 리포지토리처럼 .github/agents와 .agents/skills/가 이미 있다면, 다음 단계는 skill을 새로 만드는 것보다, 기존 skill과 agent의 책임 분할(separation of responsibilities)을 정리하는 것이라고 생각합니다.

특히 이번과 같은 orchestrator형에서는 개선 대상이 3개 층위로 나뉩니다.

• 이용자의 프롬프트: 매번 작성하는 긴 배경 설명을 줄임
• 스킬(skill): 기존의 .agents/skills/에 있는 기사 구성·프론트매터(frontmatter)·링크 규약·리뷰 관점을 재사용하여 중복을 늘리지 않음
• 에이전트 정의: orchestrator 자체에는 "누구에게 무엇을 위임할 것인가", "어디서 수렴 판정을 할 것인가"만 남기고, skill에 있는 상세한 집필 규약은 최대한 재기술하지 않음

요컨대, 사람을 사용하는 방법뿐만 아니라 agent / skill의 책임 분할 그 자체를 재검토하는 것이 본질입니다.

이번 정의를 볼 때, 특히 재검토 효과가 큰 규칙은 다음과 같습니다.

규칙	현재 위치	수정 방법
📝 프론트매터(Frontmatter) 5개 항목 (title / emoji / type / topics / published: false)	orchestrator의 최종 체크 / write-zenn-article skill 양쪽 모두	skill 측을 정본(Source of truth)으로 삼고, orchestrator에서는 상세 열거를 제외하여 "frontmatter는 skill과 기존 repo 규약에 따른다"로 단축한다
🔢 14자리 16진수 슬러그와 npx zenn new:article	orchestrator의 Step 2 / write-zenn-article skill 양쪽 모두	writer / skill 측의 책임으로 넘긴다. orchestrator는 "writer가 번호를 부여하고 생성한다"라고만 보유한다
🚫 published: false 유지	orchestrator / skill 양쪽 모두	repo-wide instruction이나 skill 측으로 통일하고, orchestrator에서는 공개 판정 플로우만 가진다
🔗 Microsoft Learn 계열 링크에 WT.mc_id=DT-MVP-5004827 추가	orchestrator 최종 체크 / write-zenn-article skill 양쪽 모두	skill 또는 .github/copilot-instructions.md 측으로 넘긴다. orchestrator에 세세한 URL 규칙을 두지 않는다
🧱 기사 구성(장 나누기) · 문체 · 이모지 운용	write-zenn-article skill에 상세히 기술됨. 필요에 따라 agent 측에서도 참조하기 쉬움	skill에서만 관리하고, orchestrator에서는 재기술하지 않는다
✅ 모든 코드 블록에 언어명 / alt 텍스트 / TODO 없음	orchestrator 최종 체크 / skill에도 사실상 유사한 규칙이 있음	기계적인 최종 검사는 orchestrator가, 의미나 이유에 대한 설명은 skill 측에 맡긴다
🔄 리뷰는 read-only로 병렬 진행, 통합 후 일괄 반영	orchestrator 고유	이는 orchestrator에 남겨두어야 할 핵심 규칙이다. 다른 곳으로 옮기지 않는다
📏 수렴 조건 · 최대 라운드 수 · 반려(差し戻し) 조건	orchestrator 고유	이 또한 orchestrator에 남겨두어야 할 핵심 규칙이다. 품질 게이트(Quality Gate)이므로 agent 측에서 보유한다

이 정리를 통해 보면, orchestrator에 남겨두어야 할 것은 플로우 제어와 품질 게이트입니다. 반대로, 작성 규약, 링크 규약, frontmatter 규약, Zenn 기사로서의 형식 규칙은 skill 측에 두는 것이 더 자연스럽습니다.

다시 말해, zenn-article-orchestrator에서 정말 무거운 것은 "리뷰를 병렬로 돌리는 것" 그 자체가 아니라, 플로우 제어에 더해 집필 규약까지 떠안기 쉽다는 점입니다. 이 부분을 분리하는 것만으로도 에이전트 정의의 비대화를 억제하기 쉬워집니다.

이번 관측 범위만으로도, 적어도 약 10만 입력 토큰(Input Token) 상당의 절감 여지가 있었습니다. 이는 "매번 동일한 전제를 대화에 흘려보내고 있는" 만큼을 고려한 보수적인 추정치입니다. 오케스트레이터나 스킬 정의 측까지 정리할 수 있다면, 반복되는 워크플로우 전체에서는 이보다 더 큰 효과를 기대할 수 있습니다.

• 매번 거의 동일한 문체 지시나 출력 형식을 붙여넣고 있을 때
• 팀이나 개인적으로 "이 리포지토리에서는 이렇게 동작해주길 바란다"라는 규칙이 정해져 있을 때
• 여러 세션 / 여러 기사에서 동일한 방식을 반복하고 있을 때
• 오케스트레이터 에이전트가 매번 "마무리까지" 책임지도록 설계되어 있을 때

긴 system prompt 방식의 설명을 매번 대화로 보내는 것보다, 리포지토리에 귀속시켜 재사용 가능하게 만드는 것이 토큰 측면이나 운영 측면에서 더 깔끔합니다. 나아가, orchestrator형 agent라면 기존의 .agents/skills/를 활용하면서, agent 본체의 중복 규칙을 줄이는 단계까지 진행하면 개선의 논리가 완결됩니다.

이는 세션 압축책입니다. Tip 1에서 상류 설계를 가볍게 만든 후, 운영 중 발생하는 비대화를 억제하는 역할을 합니다.

기사의 구성이나 전제가 확정된 후에도, 동일한 세션에서 본문 추가 · 비교 · 바꾸어 쓰기 · 요약을 계속하면, 이미 확정된 문맥까지 매번 재전송되기 쉽습니다.

• /compact 사용 횟수: 30일간 0회
• Roslyn lexer article에서는 후반부 평균 입력이 +21,491
• Fluent UI 2 Skeleton 記事에서는 +39,210
• Fluent UI 2 Textarea에서는 +44,221, 후반부에만 약 190만 입력 토큰이 초과 발생

상태	개선 전	개선 후
🧠 대화 유지 방식	조사 → 구성 → 초안 → 수정을 하나로 계속 진행	orchestrator가 일단 응답을 반환한 시점에서 /compact 수행
📦 유지하는 정보	과거의 도구 출력이나 바꾸어 쓰기(paraphrasing) 이력도 계속 보유	요점만 요약된 상태로 다음 단계로 진행
✍️ 다음 요청	"이전 흐름을 바탕으로 계속해줘"	"여기까지의 결정 사항은 이것이야. 다음은 제3절만 작성해줘"

여기서 전제로 삼고 싶은 것은, 단순한 대화로 글을 쓰는 케이스가 아니라, zenn-article-orchestrator를 통해 집필 → 리뷰 라운드(review round) → 수렴 판정(convergence判定)을 돌리는 케이스입니다. 그 전제하에 보면, Copilot이 작동하는 도중에 /compact를 끼워 넣는 것은 현실적으로 하기 어렵습니다. 따라서 Tip 2에서 말하고자 하는 것은 "실행 중에 개입하는 것"이 아니라, orchestrator가 일단 응답을 반환한 시점에서, 다음 재개 전까지 대화를 가볍게 만드는 것입니다.

/compact는 "길어지면 대충 누른다"기보다, 재개 전의 분기점에서 규칙화하여 누르는 것이 더 효과적입니다. 저라면 다음 4단계 절차로 운용하겠습니다.

• 멈출 지점을 결정한다
  orchestrator라면 "Step 1의 요건 정리가 끝나고 agent가 응답했다", "Step 2의 초안이 나오고 agent가 응답했다", "리뷰 1 라운드 분량을 통합하고 agent가 응답했다"와 같이, 일단 제어권이 사용자에게 돌아온 시점에서 멈춥니다.
• 결정 사항만 3~6행으로 압축한다
  대화의 경위가 아니라, 현재의 초안(draft) 상태와 다음 라운드 입력에 필요한 사실만을 작성합니다.
• 미결 논점을 0~2건만 남긴다
  미결 사항이 많은 상태에서 /compact를 하면, 다음 라운드 시작 시 배경 설명을 다시 해야 할 가능성이 높아집니다.
• compact 후의 첫 요청을 1개 태스크로 고정한다
  "계속해줘"가 아니라, "다음은 Step 3의 리뷰 라운드로 진행해 주세요", "이 지적 사항만 반영해 주세요"와 같이 orchestrator의 다음 1단계로 고정합니다. 실행 중에 개입하는 것이 아니라, 다음 기동 입력을 짧게 만드는 이미지입니다.

타이밍	/compact 전에 남겨야 할 것	compact 후의 첫 요청
🧭 Step 1 요건 정리 직후	독자, 기사 타입, 다루는 범위, 완성 판정의 엄격함	"이 조건으로 Step 2의 초안 작성을 진행해 주세요"
✍️ Step 2 초안 작성 직후	생성된 기사 파일, 초안의 주장, 남은 불안 요소	"이 초안을 대상으로 Step 3~5의 리뷰 라운드를 진행해 주세요"
...

이 부분은 오해하기 쉬운 포인트입니다. orchestrator가 한 번의 흐름을 달리고 있는 도중에, 사용자가 옆에서 /compact를 끼워 넣어 흐름을 비집고 들어가는 운용은 그리 현실적이지 않습니다.

오히려 실무상으로는 다음과 같이 생각하는 것이 자연스럽습니다.

• orchestrator가 Step 1까지 마치고 응답한다.
• 그 시점에 필요하다면 /compact를 한다.
• 요약된 짧은 입력으로 Step 2를 재개한다.

즉, Tip 2는 분기점마다의 재기동 비용을 낮추는 책략으로 읽는 것이 정확합니다.

orchestrator는 동일한 초안의 스냅샷(snapshot)을 고정하고, 3개의 읽기 전용(read-only) 리뷰를 병렬로 실행한 뒤, 마지막에 일괄 반영합니다. 즉, /compact로 남겨야 할 것은 "대화 이력"이 아니라, 현재의 초안 상태입니다.

특히 남길 가치가 높은 것은 다음 5가지입니다.

• 현재의 파일 경로: 어떤 articles/<slug>.md를 대상으로 하고 있는가.
• 직전 라운드에서 반영된 수정 사항: 무엇을 이미 수정했는가.
• 미결 지적 사항: ❌ / ⚠️ / 구성 블로커(blocker) 등, 다음 라운드로 넘기는 것.
• 다음 단계로 나아갈 스텝: Step 3~5를 돌릴 것인지, Step 6로 들어갈 것인지.
• 공개하지 않는다는 전제: published: false

상태를 유지하거나, 수렴하지 않았다면 완성된 것으로 간주하지 않는 것.

실제로는 다음 형식이면 충분합니다.

/compact
지금까지의 결정 사항:
- 대상 파일은 articles/afdc7b2f8597cb.md
...

포인트는 경위가 아니라 재개 조건을 쓰는 것입니다. "이렇게 생각해서 여기까지 도달했다"는 버리고, "다음 턴에 필요한 전제 조건만 남긴다"는 방향으로 작성하는 것이 더 짧아집니다.

/compact

를 한 직후에 다시 긴 배경 설명을 붙여넣으면 효과가 떨어집니다. 따라서 compact 이후의 첫 번째 요청도 짧게 유지해야 합니다.

상태	개선 전	개선 후
🗣️ compact 이후의 요청	"이전 흐름을 바탕으로 Tip 2를 더 자세히, 다른 Tip들과의 정합성도 고려하면서 적절히 표현도 수정해서……"	"위의 요약을 전제로, Step 2 완료 후의 compact 운영 방식만 추가해 주세요"
...

이번 관측을 바탕으로 단순 산출해 보면, Textarea는 약 190만 입력 토큰, Skeleton은 후반부 약 50개 이벤트 × 39,210으로 약 196만 입력 토큰, Roslyn은 후반부 약 73개 이벤트 × 21,491로 약 157만 입력 토큰의 차이가 발생합니다. 따라서, 610 턴 규모의 긴 기사 작성 세션 1개당 150만200만 입력 토큰 정도는 절감할 여지가 있어 보입니다.

• 아직 기사의 주장 자체가 확정되지 않았을 때
• 비교할 안이 2~3개 남아 있어 어떤 것을 채택할지 미정일 때
• 현재 막 1차 정보를 수집하고 있어 참조원을 다 정리하지 못했을 때
• 동일 라운드의 fact-check / proofread / flow-review가 아직 모두 나오지 않았을 때
• 리뷰 결과를 통합하기 전이라 무엇을 채택하고 무엇을 버릴지 미확정일 때

이 단계에서 /compact를 하면, 나중에 "무엇을 버려도 되고 무엇을 남겨야 하는지"가 모호한 상태로 압축되어 버려 오히려 설명 과정을 다시 반복하게 됩니다. orchestrator를 전제로 말하자면, /compact는 동일 라운드 중간에 끼워 넣는 것이 아니라, Step 완료 후나 라운드 통합 후 agent가 돌아온 타이밍에 배치하는 것이 더 적합합니다.

• Step 1의 요구사항 정리가 끝나고 Step 2로 진행하기만 하면 될 때
• Step 2의 초안이 완성되어 다음 리뷰 라운드로 넘어가기만 하면 될 때
• 1 라운드 분량의 리뷰 결과를 통합 반영하여 다음 라운드의 새로운 스냅샷으로 전환할 때
• /usage를 보고 "이대로 대화를 계속 이어가는 것보다 한 번 압축하는 것이 좋겠다"고 판단했을 때
• Step 6의 최종 체크만 남았을 때

/compact는 라운드 경계의 재개 전 압축 포인트로 사용하는 것이 좋아 보입니다.

이는 페이즈 분리 전략입니다.

긴 기사 작성 세션에서는 서로 다른 페이즈의 정보를 동일한 대화에 섞어 두었던 것이 무거워지는 원인이었습니다. 조사 로그, 비교를 위한 시행착오, 본문 초안, 교정 메모가 하나에 담기면 후반부의 입력량이 불어나기 쉽습니다.

• Fluent UI 관련 기사 작성은 18개 세션에서 90,724,709 토큰
• 기타 기사 작성은 22개 세션에서 100,165,318 토큰
• 평균하면 1개 세션당 450만~500만 토큰대
• /new는 30일 동안 단 1회 사용

페이즈 설계	개선 전	개선 후
🔎 조사	본문과 동일한 세션에서 지속	조사 전용 세션에서 결론만 도출
🧱 구성	조사 로그를 품은 채 목차 구성	/new로 목차 전용 세션 시작
✍️ 집필	구성 논의나 비교 로그를 끌고 감	/new로 초안 집필 세션 시작
🎯 마무리	초안의 방황한 이력도 남음	/new로 최종 정제에만 집중

추가로, 페이즈를 나누면 /model 선택도 쉬워집니다. 예를 들어, 조사 후의 목차 정리나 가벼운 표현 정제에서는 매번 똑같이 무거운 모델을 계속 사용할 필요가 없습니다. 세션을 나누는 것이 모델 선택을 용이하게 하는 전제가 됩니다.

이번 관측에서는 후반부에 접어들면서 1 이벤트당 2만4만 입력 토큰(input token)씩 불필요하게 늘어나는 사례가 발견되었습니다. 후반 페이즈를 4050 이벤트 분량만큼 새로운 세션으로 분리할 수 있다면, 기사 1건당 약 100만 입력 토큰 내외, 무거운 케이스의 경우 150만 입력 토큰 이상의 절감 여지가 있습니다.

• 조사 메모가 정리되어 '무엇을 쓸지' 결정되었을 때
• 목차가 결정되어 '이제 본문만 쓰면 될 때'
• 본문이 완성되어 '표와 마무리만 남았을 때'

긴 세션을 억지로 유지하며 연명하기보다, 페이즈 경계에서 기분 좋게 끊어주는 것이 토큰 측면에서 훨씬 유리합니다.

이는 조사 문맥의 격리(isolation) 대책입니다.

무거운 세션에서는 본문 집필과 병행하여 옆길로 새는 조사나 셸(shell) 형태의 탐색도 많이 실행되었습니다. 이것이 메인 대화에 남게 되면, 나중에 본문을 단 한 단락만 쓰려고 해도 조사 로그 전체를 짊어지게 될 가능성이 높습니다.

/delegate

의 이용 횟수는 0회 -
Fluent UI 2 Text 記事執筆

: shell-like 36회 vs built-in read 66회 -
Textarea

: shell-like 30회 vs built-in read 20회 -
Roslyn lexer article

: shell-like 27회 vs built-in read 77회 - 무거운 세션은 첨부 파일(attachments) 주도가 아니었다

즉, 파일 첨부보다는 대화 속에서 발생한 탐색 로그와 그 재전송이 더 큰 영향을 미쳤다고 보는 것이 자연스럽습니다.

상태	개선 전	개선 후
🔍 조사	본문 세션 내에서 그대로 추가 조사	/delegate를 사용하거나 별도 세션으로 분리
🧾 결과 가져오기	생(raw) 로그나 장문 출력을 메인에 남김	요점 3~5행의 요약만 가져옴
🛠️ 도구 선택	넓은 범위의 shell 출력을 반복해서 붙여넣음	가능하다면 built-in read/search를 우선함

/delegate
Fluent 2 Textarea의 사양 차이점만 조사해 주세요.
최종적으로 메인 대화에는 제목 후보 3개와 요점 5행만 반환해 주세요.

옆길로 새는 조사를 1015 이벤트 분량만큼만 메인 대화에서 격리할 수 있어도, 후반부의 입력 팽창을 억제할 수 있습니다. 1 이벤트당 여유 입력량을 2만4만 토큰으로 가정하면, 긴 세션에서 약 20만~60만 입력 토큰 정도의 절감 여지가 있습니다.

• 본문을 쓰는 도중에 사양 확인을 위한 별도의 조사가 발생했을 때
• grep / shell / 로그 확인이 늘어났을 때
• '이 조사 결과는 3줄이면 충분하다'고 판단될 때

조사 자체를 줄일 필요는 없습니다. 조사의 문맥을 메인 기사 집필 세션으로 끌고 들어오지 않는 것이 핵심입니다.

이는 체크포인트(checkpoint) 운용 대책입니다.

이번 사례에서는 /usage 자체는 사용되었습니다. 하지만 확인 후에 세션 구조를 변경하지 않았기 때문에, 사용량 파악이 '사후 확인' 단계에서 멈춰 있었던 것으로 보입니다.

/usage

: 30회 -
/compact

: 0회 -
/new

: 1회 -
/delegate

: 0회

즉, 계기판(meter)은 보고 있었지만, 브레이크를 밟거나 경로를 변경하는 것으로는 이어지지 않았습니다.