• 1M 컨텍스트 (Context)를 갖춘 Opus 4.7은 청킹 (Chunking)이나 맥락 손실 없이 단 한 번의 프롬프트로 47개의 파일을 리팩터링 (Refactor)할 수 있게 해줍니다.

• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration)은 4개의 초안을 병렬로 실행하여, 매주 약 14시간의 작성 시간을 절약해 줍니다.

• 'Opus가 계획하고 Sonnet이 실행하는' 패턴은 고성능 티어 (Tier)를 전략 수립에, 저렴한 티어를 단순 반복 작업에 배치할 수 있게 합니다.

• 매일 결과물을 출시해야 하는 1인 운영자에게, 최상위 티어는 단 일주일간의 딥 워크 (Deep work)만으로도 그 비용을 충분히 회수합니다.

저는 1인 AI 크리에이티브 스튜디오를 운영하고 있습니다. 지난주 저는 단 한 번의 Claude Opus 4.7 프롬프트로 47개의 파일을 리팩터링 (Refactor)했고, 한 세션에서 4개의 콘텐츠 초안을 병렬로 실행했으며, 한 달 동안 놓치고 있었던 3개 리포지토리 (Repos) 간의 아키텍처 드리프트 (Architectural drift)를 포착했습니다. 이런 한 주를 보내고 나면 최상위 티어의 비용이 오히려 저렴하게 느껴집니다. 이 포스트는 출시 소식을 알리는 글이 아닙 (이미 존재합니다). 이 글은 이 모델이 실제로 제 스튜디오에서 어떻게 작동하는지, 그리고 왜 1인 운영자가 팀과는 다른 관점에서 티어를 고려해야 하는지에 대한 이야기입니다.

롱 컨텍스트 (Long-context) 작업이 핵심이지만, 2차적 효과가 더 큽니다

가장 명백한 이점은 1M 컨텍스트 윈도우 (Context window)입니다. 저는 작은 리포지토리 (Repo) 전체를 하나의 프롬프트에 붙여넣고, Opus 4.7에게 모든 파일에 걸쳐 특정 패턴을 리팩터링 (Refactor)하도록 요청할 수 있습니다. 청킹 (Chunking)도 필요 없고, "아까 말한 내용을 기억해 줘"라고 말할 필요도 없으며, 턴 (Turn) 사이의 상태를 유지할 필요도 없습니다. 1M 토큰 (Tokens)에 무엇이 들어갈 수 있는지와 프롬프트를 어떻게 구조화해야 하는지에 대한 더 깊은 내용은 1M Context Window Workflows를 참조하세요.

제 업무 방식을 바꾼 것은 바로 이 2차적 효과입니다. 청킹 (Chunking)을 할 필요가 없다는 것은, 청크를 어떻게 나눌지 계획할 필요도 없다는 뜻입니다. 예전 워크플로우 (Workflow)의 절반은 준비 작업이었습니다. 어떤 8개의 파일을 보낼지 선택하고, 나머지를 요약하고, 의존성 (Dependencies)에 대한 정신적 지도 (Mental map)를 그리는 작업 말입니다. 이제 그런 과정은 사라졌습니다. 저는 이제 코드베이스 (Codebase) 전체를 붙여넣고 실제 질문을 던집니다.

이번 달에 있었던 두 가지 구체적인 사례입니다:

1. 제 디자인 토큰 (Design Tokens) 저장소 전체에 걸친 간격 시스템 (Spacing-system) 리팩토링 (Refactor). 47개의 파일과 3개의 중첩된 패키지 (Nested packages)가 포함되었습니다. 예전의 저라면 이 작업을 이틀 동안 4번의 세션에 걸쳐 수행했을 것입니다. Opus 4.7은 단 한 번의 프롬프트 (Prompt)로 이를 완료했으며, 저는 20분 만에 검토할 수 있는 디프 (Diff)를 받았습니다. 약 6시간을 절약했습니다.

2. Shopify 테마 버그를 디버깅 (Debugging)하는 세션이었는데, 원인은 6단계 깊이의 Liquid include였습니다. 테마 전체를 붙여넣고 "왜 모바일에서 장바구니 서랍 (Cart drawer)에 잘못된 가격이 표시되나요?"라고 물었더니, 단 한 번의 시도만에 정답을 얻었습니다. 버그는 제가 4개월 동안 건드리지 않았던 스니펫 (Snippet)에 있었습니다. 예전의 저라면 grep 명령어로 반나절을 보냈을 것입니다.

교훈: 긴 컨텍스트 (Long context)는 단순히 "대화 횟수가 줄어드는 것"이 아닙니다. 그것은 "준비 비용 (Prep tax)이 사라지는 것"입니다. 모든 시간이 곧 나의 비용인 1인 스튜디오에게, 준비 비용은 제 오전 시간을 갉아먹고 있었습니다.

멀티 에이전트 오케스트레이션 (Multi-agent orchestration)은 콘텐츠를 위한 진정한 해방구입니다

저는 많은 콘텐츠를 발행합니다. 블로그에 266개의 기사, 3개의 소셜 채널, 그리고 유튜브 (YouTube) 파이프라인 (Pipeline)을 운영하고 있습니다. Opus 4.7 이전에는 병렬 초안 작성 (Parallel drafting)을 시도할 때마다 에이전트 (Agents)들이 경로를 이탈하거나, 서로 내용을 반복하거나, 브랜드 보이스 (Brand voice)와 모순되는 문제가 발생하여 항상 실패했습니다. 하지만 4.7을 사용하면서, 저는 한 세션 내에서 4개의 병렬 초안 작성 에이전트를 실행할 수 있으며, 이들은 일관성을 유지합니다.

저의 평범한 수요일은 다음과 같습니다. 한 에이전트는 블로그 포스트를 작성합니다. 두 번째 에이전트는 어제의 포스트를 LinkedIn, X, Instagram 캡션으로 재가공 (Repurposing)합니다. 세 번째 에이전트는 지난주 기사들을 브랜드 보이스 규칙에 따라 감사 (Auditing)합니다. 네 번째 에이전트는 다음 5개의 포스트를 위해 Magnific에서 사용할 썸네일 프롬프트를 생성합니다. 이 네 가지 작업이 모두 병렬로 진행되며, 네 에이전트 모두 동일한 브랜드 보이스 문서를 읽고, 네 에이전트 모두 제가 가벼운 편집 후 바로 발행할 수 있는 결과물을 만들어냅니다.

이 작업은 과거에는 순차적 (Sequential)이었습니다. 4시간이 소요되는 콘텐츠 작업 블록이었죠. 이제는 약 90분간의 감독만 하면 나머지는 에이전트들이 처리합니다. 이것이 제가 계속 언급해 온 주당 14시간의 차이입니다. 이것은 마케팅용 수치가 아니라, 저의 예전 Notion 로그와 현재의 Notion 로그 사이의 실제 격차입니다.

비결은 오케스트레이터 에이전트(orchestrator agent, 제가 대화하는 대상)가 Opus 4.7이라는 점입니다. 하위 에이전트(sub-agents)들은 저렴하고 빠른 작업을 위해 Sonnet을 사용할 수 있습니다. 오케스트레이터가 계획을 유지하고, 명령을 내리며, 검토합니다. 이 패턴이 차세대 워크플로우 (workflow)입니다.

Opus가 계획하고, Sonnet이 실행한다 (계층 혼합 패턴)

이것은 제가 실행하는 가장 중요한 단일 패턴입니다. Opus 4.7은 토큰당 비용이 비쌉니다. Sonnet은 저렴합니다. 만약 제가 모든 일에 Opus를 사용한다면, Sonnet이 처리할 수 있는 작업에 예산을 낭비하게 됩니다. 반대로 모든 일에 Sonnet을 사용한다면, 오직 Opus만이 포착할 수 있는 전략적 판단을 놓치게 됩니다.

그래서 저는 이를 분리합니다. Opus 4.7은 고문(advisor)이자 기획자(planner)입니다. Sonnet 4.5는 작업자(worker)입니다. 고문이 전체 문맥(context)을 읽고, 계획을 세우고, 개별 작업들을 Sonnet 하위 에이전트들에게 넘긴 다음, 결과물을 검토합니다. 이러한 분리에 대한 전체적인 추론 과정(언제 에스컬레이션할지, 언제 Sonnet을 유지할지, 핸드오프(handoff)를 어떻게 구조화할지)을 알고 싶다면, Claude Advisor Strategy에 정리해 두었습니다.

지난주의 실제 사례입니다. 저는 새로운 제품 랜딩 페이지를 제작하고 있었습니다. 계획에는 6개의 섹션, 가격 책정 로직, 비교 표, FAQ, 그리고 SEO 메타데이터가 필요했습니다. Opus 4.7은 저의 전체 숍 저장소(repo)를 읽고, 제가 지금까지 출시했던 가장 성과가 좋았던 5개의 랜딩 페이지를 살펴본 뒤, 한 페이지 분량의 브리프(brief)를 작성했습니다: 섹션 순서, 카피 각도, 사용할 정확한 CSS 토큰, 연결할 스키마(schema) 등이 포함되었습니다. 그 후 Sonnet이 각 섹션을 병렬로 실행했습니다. 총 API 비용은 33 EUR였습니다. 예전의 저였다면 이 작업에 이틀을 썼을 것입니다. 지금의 저는 3시간을 썼으며, 그 시간의 대부분은 검토에 사용되었습니다.

멘탈 모델(mental model): Opus는 시니어 디자이너이고, Sonnet은 제작 팀입니다. 시니어 디자이너에게 제작 업무를 맡기지 마세요. 그들이 생각하게 한 다음, 팀이 그들이 계획한 것을 구축하게 하세요. 1인 스튜디오에게 이것은 수학적으로 성립하는 유일한 방법입니다.

심층 감사(Deep audits)는 일상 업무가 놓치는 것을 포착한다

마지막 두 가지 워크플로우는 보상이 가장 느리게 돌아오지만 가장 중요한 것들입니다. 저는 이전에는 할 수 없었던, Opus 4.7을 활용한 두 가지 정기적인 감사(audit)를 실행하고 있습니다.

첫째, 긴 형식의 콘텐츠(long-form content) 전반에 걸친 브랜드 보이스(brand voice) 점검입니다. 일주일에 한 번, 저는 Opus에게 제가 발행한 최근 7개의 기사를 읽게 하고, 이를 저의 브랜드 보이스 문서와 비교하여 일관성에서 벗어난 부분(drift)을 찾아내라고 요청합니다. 대시(em dash) 사용 실수, 의도치 않은 복수 대명사 사용, 규칙상 금지된 AI 특유의 말투(AI tells), 약한 도입부 등이 대상입니다. 1M(100만 토큰) 컨텍스트 윈도우(context window) 덕분에 Opus는 규칙과 7개의 기사 전체를 한 번에 읽을 수 있습니다. 처음 이 작업을 실행했을 때, 저는 완벽하다고 생각했던 기사들에서 23개의 문제를 찾아냈습니다. 저는 이를 수정하고 보이스 문서를 업데이트했으며, 그다음 실행에서는 4개의 문제만 발견되었습니다. 보이스는 한 번의 대대적인 재작성이 아니라, 시간이 흐르며 점진적으로 정교해집니다.

둘째, 코드베이스 전반에 걸친 아키텍처 감사(architectural audits)입니다. 저는 매달 주요 리포지토리(repos)를 대상으로 Opus에게 일관성 결여를 찾아내라고 요청하며 검토를 진행합니다. 하나의 아톰(atom)을 공유해야 함에도 공유하지 않는 컴포넌트, 포크(forked)된 토큰, 서로 모순되는 패턴 등이 대상입니다. 1M 컨텍스트(context) 덕분에 Opus는 세 개의 리포지토리 전체를 동시에 염두에 둘 수 있습니다. 지난달에는 버튼 컴포넌트가 세 곳에서 각각 약간씩 다른 호버 상태(hover state)를 가진 채 재구현된 것을 잡아냈습니다. 수작업으로는 절대 찾아낼 수 없었을 것입니다. 감사가 문제를 지적한 후 수정하는 데는 40분이 걸렸습니다.

이러한 감사 작업에 대한 솔직한 견해는 이렇습니다. 당장 실행하는 순간에는 가치 있게 느껴지지 않습니다. 그저 정리 작업처럼 느껴집니다. 하지만 6개월이 지나면, 기반(foundation)이 깨끗하게 유지되기 때문에 스튜디오의 성과는 복리로 쌓입니다. 이것이 바로 최상위 티어(top tier)를 사용해야 하는 진짜 이유입니다. 저렴한 모델은 작업을 수행하지만, 비싼 모델은 작업물이 부패하지 않도록 지켜줍니다.

결론 (Bottom Line)

여섯 가지 워크플로우(workflows), 하나의 티어 결정. 긴 컨텍스트 리팩터링(long-context refactor)과 심층 디버깅(deep debugging)은 제가 예전에 준비 단계에서 소비하던 시간들을 되찾아줍니다. 멀티 에이전트 초안 작성(multi-agent drafting)과 'Opus가 계획하고 Sonnet이 실행하는(Opus-plans-Sonnet-executes)' 패턴은 제가 예전에 제작 단계에서 소비하던 시간들을 되찾아줍니다. 브랜드 보이스와 아키텍처 감사는 이미 출시한 작업물들을 보호합니다.

1인 스튜디오의 입장에서 계산해 보면 다음과 같습니다. Opus 4.7은 토큰당 비용이 더 높지만, 준비 과정에서 발생하는 세금(prep tax)을 제거하고, 오케스트레이션 (orchestration)을 수행하며, 흐름의 이탈 (drift)을 잡아냅니다. 제가 되찾은 주당 14시간의 시간은 API 비용보다 훨씬 더 큰 가치가 있습니다. 만약 당신이 1인 스튜디오를 운영 중이고, Opus의 가격이 부담스러워 Sonnet을 사용해 왔다면, 결정을 내리기 전에 일주일 동안만이라도 계층 혼합 (tier-mixing) 패턴을 시도해 보세요.

저는 제가 사용하는 전체 설정(기술, 훅 (hooks), 명령 (commands), 위의 오케스트레이션 패턴들)을 Claude Blueprint로 패키징하여 여러분의 스튜디오에도 바로 적용할 수 있도록 했습니다. 만약 소셜 미디어가 당신의 콘텐츠 스택 (content stack)의 일부라면, 저는 여러 플랫폼에 걸쳐 멀티 에이전트 (multi-agent) 결과물을 예약 게시하기 위해 Buffer를 사용합니다. 어떤 방식이든 교훈은 명확합니다. 워크플로우 (workflow)를 먼저 선택한 다음, 그에 맞는 계층 (tier)을 선택하십시오.

이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)