이번 달 내가 사용하기 시작한 Claude Code 기능들

• 1M 컨텍스트 Opus가 나의 수동 파일 붙여넣기 의식을 완전히 대체했습니다.

• 동적 루프 자기 조절 (Dynamic loop self-pacing) 기능이 단순 편집에 낭비되는 토큰 소비를 줄였습니다.

• 예약된 원격 에이전트 (Scheduled remote agents)가 이제 나의 오전 콘텐츠 큐를 처리합니다.

• 기술 자동 트리거 (Skill auto-trigger)가 "X를 하는 것을 기억해"라는 프롬프트의 80%를 제거했습니다.

이번 달에 다섯 가지 Claude Code 2.1 기능이 출시되었으며, 그중 세 가지는 내가 매일 일하는 방식을 조용히 재편했습니다. 나는 베를린에서 1인 스튜디오를 운영하고 있기 때문에, 수동 단계를 제거하는 것이라면 무엇이든 빠르게 복리 효과를 냅니다. 여기 각 기능이 나에게 무엇을 대체했는지, 실제로 어떻게 작동하는지, 그리고 성숙해질 때까지 건너뛰라고 권하고 싶은 두 가지 기능에 대해 설명하겠습니다.

1M 컨텍스트 Opus가 나의 파일 붙여넣기 의식을 없앴습니다

이번 달 가장 큰 변화는 Opus의 100만(1M) 토큰 컨텍스트 창 (context window)이었습니다. 이 전에는 돌이켜보면 나의 작업 흐름이 어리석게 느껴졌습니다. 나는 특정 작업에 어떤 파일이 중요한지에 대한 목록을 머릿속에 가지고 있었고, 파일들을 하나씩 붙여넣고, 컨텍스트가 채워지는 것을 지켜본 뒤, 상황이 여의치 않으면 가장 관련성이 낮은 것들을 정리하곤 했습니다. 나는 하루에도 수십 번씩 이 작업을 했습니다.

1M 컨텍스트를 통해 나는 그저 Claude에게 디렉토리 전체를 가리켜주고 필요한 것을 읽게 합니다. 나의 주요 제품 저장소 (repo)는 대략 340개의 파일로 구성되어 있습니다. 관련 부분을 로드하는 것은 무엇을 포함할지에 대해 내가 판단을 내려야 한다는 것을 의미했고, 나는 종종 틀려서 동일한 프롬프트를 두 번 실행하곤 했습니다. 이제 나는 추측하는 것을 멈췄습니다.

실질적인 이점은 막다른 길에 다다르는 경우가 줄어든다는 것입니다. 지난주에 나는 Claude에게 세 개의 모듈과 내가 존재를 잊고 있었던 설정 파일(config file)에 걸쳐 있는 버그를 추적해 달라고 요청했습니다. 이전의 컨텍스트 창이었다면 그 설정 파일을 결코 붙여넣지 않았을 것이기에 완전히 놓쳤을 것입니다. 전체 저장소가 로드된 상태에서 Claude는 첫 번째 시도에 그것을 찾아냈습니다. 덕분에 약 40분의 시행착오를 줄일 수 있었습니다.

여기에는 실제적인 비용 트레이드오프 (cost trade-off)가 존재합니다. 1M 컨텍스트 (context) 요청은 저렴하지 않으며, 저는 아주 작은 수정을 위해 전체 윈도우 (full window)를 로드하지 않습니다. 이제 저의 규칙은 간단합니다. 사소한 변경은 작은 컨텍스트를 사용하고, 두세 개의 파일로 범위를 제한합니다. 파일 간 리팩토링 (refactor)의 냄새가 나거나 제가 위치를 찾을 수 없는 버그라면, 여섯 번의 작고 혼란스러운 요청에 비용을 지불하는 대신, 전체 윈도우를 열고 한 번에 비용을 지불합니다.

만약 Claude Code를 처음 설정하면서 합리적인 시작 설정을 원하신다면, Claude Blueprint에서 저의 전체 설정을 설명해 두었습니다. 요약하자면 이렇습니다: 반사적으로 가장 큰 윈도우를 사용하지 마세요. 작업에 맞춰 윈도우를 조절하십시오. 1M 컨텍스트는 어려운 문제를 위한 정밀 도구이지, 기본값 (default)이 아닙니다. 이를 기본값처럼 취급하는 것이 한 줄짜리 CSS 수정에 토큰 (tokens)을 낭비하는 방식입니다.

동적 루프 자기 조절 (Dynamic Loop Self-Pacing)이 토큰 누수를 막아주었습니다

이 기능은 미묘해서 릴리스 노트 (release notes)에서 거의 놓칠 뻔했습니다. 동적 루프 자기 조절 (Dynamic loop self-pacing)은 에이전트 (agent)가 자신의 확신 정도에 따라 얼마나 공격적으로 반복할지를 결정하게 해줍니다. 단순한 작업에서는 빠르게 실행합니다. 모호한 작업에서는 속도를 늦추고, 더 많이 확인하며, 앞서 나가기 전에 질문을 던집니다.

이 기능은 제가 프로젝트 메모에 적어두었던

저는 이를 일주일 동안 대략적으로 측정해 보았습니다. 이전에는 전형적인 작업 세션이 일정 횟수의 명확화 루프 (clarification loops)를 거쳤는데, 이제 보니 그 대부분이 불필요한 소음이었다는 것을 깨달았습니다. 셀프 페이싱 (self-pacing) 기능을 켠 후에는 단순한 작업들은 한 번에 끝나는 경우가 더 많아졌고, 진정으로 복잡한 작업들은 더 세심한 주의를 기울였습니다. 결과적으로 쉬운 작업에 낭비되는 토큰 (token) 소모가 줄어들었고, 어려운 작업에서의 실수는 감소했습니다.

주의할 점은, 셀프 페이싱이 자신의 확신 수치 (confidence reading)를 신뢰하며, 그 수치가 가끔 틀릴 수 있다는 것입니다. 이번 달에만 두 번, 질문을 던졌어야 할 상황에서 너무 빠르게 진행해 버린 적이 있었습니다. 그래서 저는 안전 지침 (safety instructions)을 완전히 삭제하지는 않았습니다. "파일을 삭제하거나 배포 설정 (deploy config)을 건드리기 전에는 항상 확인하라"는 식의 얇은 버전의 지침을 남겨두었습니다. 그런 경우야말로 실수가 치명적인 비용을 초래하는 상황이기 때문입니다. 그 외의 모든 것은 페이싱 (pacing) 기능이 처리하도록 두었습니다.

에이전트 지침 (agent instructions)이 서로 충돌하지 않도록 구조화하는 방법에 대한 더 깊은 맥락을 알고 싶다면, Claude Blueprint에서 제가 사용하는 계층화 (layering) 방식을 살펴볼 수 있습니다. 원칙은 동일합니다. 실수의 비용이 저렴한 곳에서는 판단을 자동화하고, 실수의 비용이 큰 곳에서는 규칙을 하드코딩 (hard-code) 하십시오.

이제 예약된 원격 에이전트가 나의 아침 큐를 처리합니다

이것은 제가 이렇게 좋아하게 될 줄 예상치 못했던 기능입니다. 예약된 원격 에이전트 (Scheduled remote agents)를 사용하면 사용자의 컴퓨터가 켜져 있지 않아도 서버 측 (server-side)에서 타이머에 따라 Claude Code 에이전트가 실행되도록 설정할 수 있습니다. 저는 이제 베를린 시간으로 오전 6시에 실행되어 제가 깨어나기 전에 콘텐츠 큐 (content queue)를 준비해 두는 에이전트를 하나 두고 있습니다.

이 기능이 실제로 하는 일은 다음과 같습니다. 지난 며칠 동안 제가 출시한 제품 목록을 가져와서, 각 제품에 대해 세 개의 짧은 소셜 포스트 초안을 작성하고, 제가 검토할 수 있도록 폴더에 스테이징 (stages)해 둡니다. 제가 커피를 들고 자리에 앉으면 초안이 이미 준비되어 있습니다. 빈 파일에서 시작하는 대신 편집을 하게 됩니다. 창작에서 편집으로의 이러한 전환이 일일 생산량 (daily output)을 결정짓는 핵심입니다.

이것이 대체한 것은 제가 두려워했던 수동적인 의식(ritual)이었습니다. 매일 아침 저는 새로운 세션을 열고, 전날 설명했던 컨텍스트 (context)를 다시 설명하며, 똑같은 종류의 포스트를 힘들게 작성하곤 했습니다. 에이전트 (agent)는 다시 설명할 필요가 없습니다. 왜냐하면 그 지침들이 스케줄링된 설정 (config) 안에 살아있기 때문입니다. 에이전트는 업무를 알고 있는 상태로 깨어납니다.

저는 초안을 승인한 후 실제 스케줄링을 위해 Buffer를 함께 사용합니다. 원격 에이전트가 글을 쓰고, 제가 승인하면, Buffer가 한 주 동안 포스트를 게시합니다. 에이전트가 별도의 재형식화 (reformatting) 없이 Buffer가 수용할 수 있는 형식으로 결과물을 출력하기 때문에 인수인계가 깔끔합니다. 예전에는 90분이 걸렸던 작문 작업이 이제는 검토하는 데 약 15분 정도밖에 걸리지 않습니다.

해당 포스트들과 연결된 이미지 작업의 경우, 저는 여전히 Magnific을 수동으로 실행합니다. 왜냐하면 이미지가 게시되기 전에 모든 업스케일 (upscale) 결과물을 직접 확인하고 싶기 때문입니다. 에이전트는 어떤 포스트에 시각 자료가 필요한지 표시해 주지만, 방치된 상태로 이미지를 생성하지는 않습니다. 이는 의도적인 경계 설정입니다. 텍스트 초안은 자동화하기에 위험이 낮지만, 대중에게 공개되는 이미지는 적어도 저에게는 아직 그렇지 않습니다.

이 설정에는 오후 한나절이 소요되었으며, 이후 제가 손대지 않아도 매일 아침 작동하고 있습니다. 한 가지 주의할 점은, 조용히 실패하는(fails silently) 스케줄링된 에이전트는 에이전트가 없는 것보다 더 나쁘다는 것입니다. 저는 실행 결과물이 없을 경우 저에게 알림을 보내는 단계를 추가했습니다. 그래야 조용한 실패로 인해 오전 8시에 빈 대기열 (queue)을 마주하는 일이 발생하지 않기 때문입니다.

지연된 도구 스키마 (Deferred Tool Schemas) 및 기술 자동 트리거 (Skill Auto-Trigger)

여기에는 두 가지 새로운 기능이 있는데, 그 성능이 균일하지는 않습니다. 지연된 도구 스키마 (Deferred tool schemas)는 모든 스키마를 컨텍스트 (context)에 미리 로드하는 대신, Claude가 특정 도구를 사용하기로 결정했을 때만 해당 도구의 전체 정의를 로드할 수 있게 해줍니다. 이론적으로 이는 많은 도구를 사용하는 프로젝트에서 컨텍스트를 절약해 줍니다. 실제로 제 설정에서는 절약 효과가 미미했습니다. 저는 약 6개의 도구를 실행하며, 스키마 오버헤드 (schema overhead)가 병목 현상 (bottleneck)이 된 적은 없었습니다. 만약 30개나 40개의 등록된 도구를 사용한다면 이 기능은 매우 중요할 것입니다. 저와 같은 가벼운 설정에서는 거의 체감되지 않는 조용한 백그라운드 개선 사항일 뿐입니다. 이 기능을 얻기 위해 워크플로우를 바꿀 정도는 아닙니다.

Skill 자동 트리거 시스템은 정반대입니다. 이 기능은 제가 예상했던 것보다 더 많이 일상적인 작업 흐름을 바꿨습니다. Skill은 재사용 가능한 지침 패키지이며, 자동 트리거(auto-trigger)는 Claude가 언제 특정 Skill이 적용되는지 인식하고 저에게 요청하지 않아도 자동으로 로드한다는 의미입니다. 저는 이 블로그 기사를 작성하는 데 필요한 Skill을 가지고 있는데, 이는 제 구조, 단어 수 제한, 그리고 금지어 목록을 강제합니다. 이전에는 제가 기억해서 호출해야 했습니다. 절반 정도는 잊어서 규칙을 무시한 초안을 얻었고, 그 후에 다시 실행해야 했죠.

이제 블로그 작업을 시작하면 글쓰기 Skill이 스스로 작동합니다. 초안은 이미 올바르게 모양 잡힌 상태로 돌아옵니다. 덕분에 'X를 기억해서 해주세요'라는 프롬프트가 약 80% 정도 줄어들었는데, 이 부분이 가장 짜증났던 부분이었는데, 이걸 잊으면 작업을 처음부터 다시 해야 했기 때문입니다.

저는 Shopify 스토어의 제품 설명용 Skill과 ElevenLabs에 전달하는 음성 대본용 Skill도 비슷하게 만들었습니다. 각각의 Skill은 자체적인 맥락에서 작동하기 때문에, 어떤 템플릿을 적용해야 할지 생각할 필요가 없어졌습니다.

솔직한 단점은 다음과 같습니다: 자동 트리거가 원하지 않을 때 가끔 Skill을 발동시킵니다. 제가 작성하던 평범한 README에 블로그 구조를 적용했던 적이 있습니다. 해결책은 각 Skill의 트리거 조건을 더 빡빡하고 구체적으로 만드는 것이었습니다. 모호한 트리거는 오작동(misfire)합니다. 제가 이를 조정하자, 오작동은 거의 사라졌습니다. Claude Blueprint에는 제가 정착시킨 트리거 조건 패턴이 있습니다.

요약

이 다섯 가지 기능 중 세 가지가 이번 달 저의 작업 방식을 진정으로 바꿨습니다: 어려운 문제를 위한 1M 컨텍스트 Opus, 아침 대기열을 위한 예약형 원격 에이전트(scheduled remote agents), 그리고 반복적인 지시를 제거해 준 Skill 자동 트리거입니다. 이들은 매일 복리처럼 작용합니다. 나머지 두 가지인 지연된 도구 스키마(deferred tool schemas)와 동적 루프 셀프 페이싱(dynamic loop self-pacing)은 실제 개선점이지만 상황에 따라 다릅니다. 셀프 페이싱은 제가 그 아래에 단단한 규칙의 얇은 레이어를 유지했을 때 도움이 되었습니다. 지연된 스키마는 제 작은 도구 세트에서는 거의 체감되지 않았지만, 30개 이상의 도구가 있다면 큰 의미가 있을 것입니다.

이 모든 기능에 공통적으로 적용되는 패턴은 동일합니다. 실수가 저렴한 비용으로 발생하는 곳에서는 판단을 자동화하고, 실수가 큰 비용을 초래하는 곳에서는 인간의 검토(human review)를 유지하는 것입니다. 초안 작성(Drafts)과 일상적인 편집(routine edits)은 에이전트(agent)가 실행하도록 두세요. 배포(Deploys), 삭제(deletions), 그리고 공개 이미지(public images)는 직접 제어권을 유지해야 합니다.

만약 여러분만의 Claude Code 설정을 구축하고 싶고, 제가 매일 사용하는 전체 설정(config)과 기술 구조(Skill structure)를 알고 싶다면, Claude Blueprint부터 시작하세요. 이는 제가 처음 시작했을 때 있었으면 좋았을 문서입니다. 이번 주에는 다섯 가지 기능을 모두 시도하지 말고, 단 하나만 시도해 보세요. 복리 효과(compounding)는 실제로 여러분이 계속 유지하게 되는 기능들로부터 나옵니다.

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