클로드와 코덱스가 점점 더 어려워질까? 이유는 바로 당신의 컨텍스트가 지나치게 복잡해졌기 때문입니다.

2026.03.06

클로드와 코덱스가 점점 더 어려워질까? 이유는 바로 당신의 컨텍스트가 지나치게 복잡해졌기 때문입니다.

컨텍스트 제어 방법, AI의 과도한 동의 경향(pleasing tendency) 처리 방식, 작업 종료 조건 정의까지 — 지금까지 본 Claude/Codex 엔지니어링 실천 관련 글 중 가장 명확하게 설명한 글입니다.

2026.03.06 - 07:21:39

ClaudeCodexAI

Web3 심층 보도에 집중하고 흐름을 통찰

저자: sysls

번역: TechFlow

TechFlow 리드：구독자 260만 명의 개발자 블로거 sysls가 827명이 공유하고 7,000명이 좋아요를 누른 실전 중심 장문을 썼다. 핵심은 단 한 마디다: 당신이 사용하는 플러그인, 메모리 시스템, 각종 하네스(harness)는 대부분 역효과를 내고 있다. 이 글은 거창한 이론을 다루지 않으며, 실제 프로덕션 프로젝트에서 직접 추출한 실행 가능한 원칙들만 담았다—컨텍스트 제어 방법, AI의 ‘기만적 순응 경향’(pleasing tendency) 대처법, 작업 종료 조건 정의 방식까지. 현재까지 클로드(Claude)와 코덱스(Codex) 엔지니어링 실무를 가장 명확하게 설명한 글이다.

전체 내용은 다음과 같다:

서론

당신은 매일 클로드와 코덱스 CLI를 사용하는 개발자다. 매일 자신이 이 도구들의 능력을 최대한 활용하고 있는지 궁금해한다. 가끔은 AI가 터무니없이 어리석은 행동을 하는 걸 보고도, 왜 어떤 사람들은 인공지능으로 로켓을 만들고 있는 반면, 자신은 돌 두 개조차 제대로 쌓지 못하는지 이해할 수 없다.

당신은 그 원인이 하네스 문제, 플러그인 문제, 터미널 문제라고 생각한다. beads, opencode, zep를 모두 써봤고, CLAUDE.md 파일은 26,000줄에 달한다. 하지만 아무리 시도해도, 왜 점점 ‘천국’에서 멀어지는지, 다른 사람들은 천사들과 어울리며 즐기고 있는지 알 수 없다.

바로 이것이 당신이 오랫동안 기다려온 글이다.

또한, 나는 이 주제에 대한 어떠한 이해관계도 없다. 내가 CLAUDE.md라고 말할 때는 AGENT.md도 포함하며, 클로드라고 말할 때는 코덱스도 함께 포함한다. 두 모델 모두 꾸준히, 그리고 꽤 오래 사용해왔다.

지난 몇 달간 흥미로운 사실 하나를 관찰했다: 거의 누구도 에이전트의 잠재력을 극대화하는 법을 진정으로 모른다는 것이다.

마치 소수의 사람들이 에이전트를 이용해 온 세상을 구축할 수 있는 반면, 나머지 대부분은 방대한 도구의 바다 속에서 헤매며 ‘선택 과잉 증후군’을 앓고 있는 듯하다—‘올바른 패키지, 기술, 하네스 조합’만 찾으면 AGI를 해금할 수 있다고 믿는 것이다.

오늘, 나는 이 모든 것을 깨뜨리고 싶다. 여러분께 간단하고 솔직한 한 마디를 남긴 후, 그로부터 출발하고자 한다. 최신 에이전트 하네스가 필요 없고, 백만 개의 패키지를 설치할 필요도 없으며, 경쟁력을 유지하기 위해 백만 편의 기사를 읽을 필요도 없다. 오히려 당신의 열정이 해가 될 가능성이 크다.

나는 관광하러 온 게 아니다—에이전트가 겨우 코드를 쓸 수 있었던 초기부터 지금까지 쭉 사용해왔다. 모든 패키지, 모든 하네스, 모든 패러다임을 시도해보았다. 나는 에이전트 팩토리(agent factory)를 이용해 신호 처리, 인프라, 데이터 파이프라인을 실제로 구축했고, 이는 ‘장난감 프로젝트’가 아니라 실제 프로덕션 환경에서 운영되는 실제 사례였다. 이런 모든 경험을 거친 후…

오늘 나는 거의 더 이상 단순해질 수 없는 구성만으로 작업하고 있다. 기본 CLI(클로드 코드와 코덱스)만 사용하고, 에이전트 엔지니어링의 몇 가지 핵심 원칙에 대한 이해만 더해, 지금까지 해본 일 중 가장 획기적인 성과를 얻었다.

세상이 빠르게 진화하고 있음을 이해하기

첫째, 기초 모델 기업들이 역사적인 급진적 발전을 겪고 있으며, 이 속도는 당분간 느려질 기미가 전혀 없다는 점을 강조하고 싶다. ‘에이전트 지능’이 한 단계 진화할 때마다, 당신이 이들과 협업하는 방식도 바뀐다. 왜냐하면 에이전트는 점점 더 명령을 따르려는 방향으로 설계되고 있기 때문이다.

단지 몇 세대 전만 해도, CLAUDE.md에 ‘무엇을 하기 전에 반드시 READTHISBEFOREDOINGANYTHING.md를 먼저 읽으라’고 써넣으면, 에이전트가 50% 확률로 “닥쳐”라고 말하고, 자기 맘대로 하고 싶은 일을 시작했다. 오늘날에는 대부분의 명령, 심지어 ‘A를 먼저 읽고, 그 다음 B를 읽고, C라면 D를 읽어라’처럼 복잡한 중첩 명령에도 기꺼이 따르는 경우가 많다.

이는 무엇을 의미하는가? 가장 중요한 원칙은, 새로운 에이전트 세대가 등장할 때마다 ‘최적의 해결책’을 다시 고민해야 한다는 인식이다. 바로 이것이 ‘적을수록 좋다’는 원칙의 근거다.

여러 가지 라이브러리와 하네스를 동시에 사용하면, 당신은 스스로를 하나의 ‘해결책’에 갇히게 된다. 그러나 이 ‘해결책’이 다음 세대 에이전트 앞에서는 아예 존재하지 않을 수도 있다. 그렇다면 누가 에이전트를 가장 열정적으로, 가장 많이 사용할까? 바로 답은 전선(前沿) 기업의 직원들이다. 그들은 무한한 토큰 예산을 갖고 있고, 실제로 가장 최신 버전의 모델을 사용한다. 이것이 무슨 의미인지 아는가?

즉, 만약 진짜 문제가 존재하고, 그것에 대한 좋은 해결책이 있다면, 전선 기업이 바로 그 해결책의 가장 큰 사용자가 될 것이라는 뜻이다. 그리고 그들은 이후 어떻게 할까? 그 해결책을 자사 제품의 핵심 기능으로 통합할 것이다. 한 기업이 왜 진짜 고통 포인트를 해결해주는 외부 제품을 허용하고, 외부 의존성을 만들어야 할까? 이것이 정말 사실임을 어떻게 알 수 있을까? 스킬(skill), 메모리 하네스, 서브에이전트(sub-agent) 등을 떠올려보라—이 모든 것은 실제 문제를 해결하기 위한 ‘해결책’으로 시작되었고, 실제 현장에서 검증되어 진정으로 유용함이 입증된 것이다.

따라서, 어떤 것이 진정으로 혁신적이며 에이전트 사용 사례를 의미 있게 확장시킬 수 있다면, 언젠가는 반드시 기초 모델 기업의 핵심 제품에 통합될 것이다. 믿어도 좋다. 기초 모델 기업은 지금 정말 빠르게 전진하고 있다. 그러니 마음을 편히 하라. 어떤 추가 도구도 설치하거나 외부 의존성에 의존하지 않아도, 최고의 결과물을 낼 수 있다.

내 예측에 따르면, 댓글란엔 곧 이런 말이 등장할 것이다: “SysLS님, 제가 OO 하네스를 쓰는데 정말 훌륭합니다! 하루 만에 구글을 재구축했어요!”—이에 대해 나는 이렇게 답한다: 축하합니다! 하지만 당신은 이 글의 타깃 독자가 아니다. 당신은 커뮤니티 내에서 에이전트 엔지니어링을 진정으로 이해한, 극소수의 특별한 집단을 대표한다.

컨텍스트가 전부다

정말 그렇다. 컨텍스트가 전부다. 천 개의 플러그인과 외부 의존성을 사용하는 또 다른 문제는, 바로 ‘컨텍스트 팽창(context inflation)’에 시달린다는 점이다—즉, 에이전트가 너무 많은 정보에 압도당한다는 것이다.

내가 파이썬으로 문자 맞추기 게임을 만들어 줄 수 있겠느냐고 요청하면? 간단하다. 그런데 잠깐, 26개 전 대화에서 남긴 ‘메모리 관리’ 메모는 뭐지? 아, 사용자의 화면이 71개 전 대화에서 우리가 너무 많은 서브프로세스를 생성해서 멈췄었군. 항상 메모를 남겨야 한다고? 알겠습니다… 그런데 이게 문자 맞추기 게임과 무슨 상관이 있지?

이해하셨을 것이다. 당신은 에이전트에게 작업 수행에 필요한 정확한 정보만을 제공하고 싶을 뿐, 더도 덜도 아니기를 바란다! 이 통제력이 높을수록, 에이전트의 성능도 높아진다. 그런데 이상한 메모리 시스템, 플러그인, 또는 이름과 호출 방식이 혼란스러운 수많은 스킬들을 도입하기 시작하면, 당신은 에이전트에게 폭탄 제조 매뉴얼과 케이크 레시피를 동시에 건네주고 있는 셈이다. 그런데 당신이 원하는 건 단지 ‘레드우드 숲에 관한 시 한 편’을 써달라는 것뿐인데 말이다.

그래서 나는 다시 강조한다—모든 의존성을 제거하고…

진짜 유용한 일을 하라

구현 세부 사항을 정확히 기술하기

컨텍스트가 전부라는 것을 기억하는가?

에이전트에게 작업 수행에 필요한 정확한 정보만을 주고 싶다는 것을 기억하는가?

이를 달성하는 첫 번째 방법은 ‘조사(research)’와 ‘구현(implementation)’을 분리하는 것이다. 당신은 에이전트에게 무엇을 하라고 요청하는지에 대해 극도로 정확해야 한다.

불정확함의 결과는 무엇인가? “인증 시스템을 만들어줘.”라고 요청하면, 에이전트는 ‘인증 시스템이란 무엇인가?’ ‘어떤 선택지가 있는가?’ ‘각 선택지의 장단점은 무엇인가?’ 등을 조사해야 한다. 그러면 에이전트는 사실 필요하지도 않은 정보를 인터넷에서 뒤지게 되고, 컨텍스트는 다양한 가능성의 구현 세부 사항으로 넘쳐난다. 실제 구현 단계에 들어가면, 혼란스러워질 가능성이 높아지고, 선택한 구현 방식에 대해 불필요하거나 관련 없는 환각(hallucination)을 일으킬 수도 있다.

반대로, “bcrypt-12 비밀번호 해싱을 사용한 JWT 인증, 리프레시 토큰 롤오버, 7일 만료…”라고 명시하면, 에이전트는 다른 대안을 조사할 필요가 없고, 당신이 원하는 바를 정확히 알고 있으므로, 구현 세부 사항으로 컨텍스트를 채울 수 있다.

물론, 당신은 항상 구현 세부 사항을 알지는 못한다. 종종 당신도 무엇이 옳은지 모를 때가 있고, 때로는 구현 세부 사항 결정 자체를 에이전트에게 맡기고 싶을 수도 있다. 이런 경우엔 어떻게 해야 할까? 아주 간단하다—다양한 구현 가능성을 탐색하는 ‘조사 작업’을 따로 생성하여, 당신이 직접 결정하거나, 에이전트가 어느 구현 방식을 채택할지 결정하도록 한 후, 완전히 새롭게 구성된 컨텍스트를 가진 다른 에이전트에게 실제 구현을 맡기면 된다.

이런 방식으로 사고하기 시작하면, 작업 흐름 속에서 에이전트의 컨텍스트가 불필요하게 오염되는 지점을 쉽게 발견할 수 있고, 따라서 에이전트 작업 흐름 내에 ‘격리벽’을 설치해 불필요한 정보를 에이전트로부터 추상화하고, 작업 수행에만 특화된 특정 컨텍스트만 남길 수 있다. 기억하라. 당신이 가진 건 우주에 존재하는 모든 종류의 ‘공’을 아는, 매우 재능 있고 영리한 팀원이다—그러나 당신이 ‘사람들이 춤추고 즐길 수 있는 공간’을 디자인하고 싶다고 명시하지 않는 한, 그는 계속해서 공형 물체의 장점만 설명할 것이다.

기만적 순응 경향의 설계적 한계

누구도 자신을 끊임없이 비판하거나, 틀렸다고 말하거나, 지시를 완전히 무시하는 제품을 사용하고 싶지 않다. 그래서 이러한 에이전트는 당신을 동의하고, 당신이 원하는 일을 하려는 노력을 한다.

당신이 “단어 세 개마다 ‘행복’을 넣어줘”라고 하면, 에이전트는 이를 충실히 따르려 한다—이 점은 대부분의 사람이 이미 잘 알고 있다. 바로 이런 순응성이 이 제품을 그렇게 유용하게 만든다. 그러나 여기에 매우 흥미로운 특성이 하나 있다: 즉, “내 코드베이스에서 버그 하나 찾아줘”라고 하면, 에이전트는 버그를 ‘찾아낼 것’이다—심지어 그것을 ‘생성’하더라도 말이다! 왜일까? 바로 에이전트가 당신의 지시를 듣고 싶어 하기 때문이다!

대부분의 사람들은 LLM이 환각을 일으키거나 존재하지 않는 것을 만들어낸다고 빠르게 불평하지만, 그 근본 원인이 바로 자신이라는 사실은 인식하지 못한다. 당신이 무엇을 찾으라고 요청하든, 에이전트는 그것을 ‘제공’한다—사실을 약간 비틀더라도 말이다!

그렇다면 어떻게 해야 할까? 나는 ‘중립적 프롬프트(neutral prompt)’가 매우 효과적이라고 발견했다. 즉, 에이전트를 특정 결과 쪽으로 편향시키지 않는 방식이다. 예를 들어, “데이터베이스에서 버그 하나 찾아줘”라고 하지 않고, “데이터베이스 전체를 스캔하고, 각 컴포넌트의 로직을 따라가면서 발견된 모든 사항을 보고해줘”라고 요청하는 것이다.

이런 중립적 프롬프트는 가끔 버그를 발견하기도 하고, 때로는 단지 코드가 어떻게 작동하는지를 객관적으로 설명하기도 한다. 그러나 에이전트를 ‘버그가 있다’는 전제로 편향시키지는 않는다.

기만적 순응 경향을 다루는 또 다른 방법은, 이를 장점으로 삼는 것이다. 나는 에이전트가 나를 기쁘게 하고, 내 지시를 따르려 한다는 것을 안다. 따라서 나는 이를 어느 방향으로든 활용할 수 있다.

그래서 나는 ‘버그 찾기 에이전트’에게 데이터베이스 내 모든 버그를 식별하라고 지시하고, 영향도가 낮은 버그는 +1점, 중간 정도의 영향은 +5점, 심각한 영향은 +10점을 부여한다고 알려준다. 나는 이 에이전트가 모든 종류의 버그(버그가 아닌 것들도 포함)를 열정적으로 식별해 104점 같은 점수를 보고할 것임을 안다. 나는 이를 ‘모든 가능 버그의 초집합(super-set)’으로 본다.

그 다음, 나는 ‘반박 에이전트’를 배치하여, 각 버그를 성공적으로 반박하면 해당 버그의 점수를 얻지만, 잘못 반박하면 -2배의 점수를 차감받도록 한다. 이 에이전트는 가능한 많은 버그를 반박하려 하지만, 처벌 메커니즘이 있기 때문에 신중하게 행동할 것이다. 그럼에도 불구하고, 이 에이전트는 여전히 버그(진짜 버그도 포함)를 적극적으로 ‘반박’할 것이다. 나는 이를 ‘모든 실제 버그의 부분집합(sub-set)’으로 본다.

마지막으로, 나는 ‘심판 에이전트’를 배치하여 두 에이전트의 입력을 종합하고 점수를 매기게 한다. 나는 심판 에이전트에게 ‘정답이 이미 존재한다’고 알려주고, 맞힐 때는 +1점, 틀릴 때는 -1점을 주도록 한다. 따라서 심판 에이전트는 각 ‘버그’에 대해 버그 찾기 에이전트와 반박 에이전트를 각각 평가한다. 심판이 진실이라 선언한 것을, 나는 직접 검증한다. 대부분의 경우 이 방법은 놀라울 정도로 높은 정확도를 보이며, 가끔 실수가 있긴 하지만, 거의 오류가 없는 수준에 가깝다.

어쩌면 단일 ‘버그 찾기 에이전트’만으로도 충분하다고 느낄 수도 있지만, 이 방법은 나에게 매우 효과적이다. 왜냐하면 각 에이전트가 타고난 ‘기쁘게 하려는’ 성향을 전략적으로 활용하기 때문이다.

무엇이 유용한지, 무엇을 써야 할지 판단하는 법

이 질문은 매우 복잡해 보이고, 당신이 인공지능 최전선의 동향을 끊임없이 추적하고 심층 학습해야 한다고 느끼게 하지만, 사실은 아주 간단하다… 만약 OpenAI와 클로드가 이미 그것을 구현했거나, 그것을 구현한 회사를 인수했다면… 그것은 거의 확실히 유용하다.

‘스킬(skills)’이 이미 어디서나 흔히 보이고, 클로드와 코덱스의 공식 문서 일부가 되었음을 눈치 채셨는가? OpenAI가 OpenClaw를 인수한 사실을 아는가? 클로드가 이어서 메모리, 음성, 원격 작업 기능을 추가한 사실을 아는가?

계획(planning)은 어떠한가? 누군가 ‘먼저 계획하고, 그 다음 구현하라’는 접근이 정말 유용하다는 사실을 발견했고, 그것이 핵심 기능이 된 것을 기억하는가?

맞다, 그런 것들은 유용하다!

무한히 반복되는 stop-hooks가 왜 그렇게 유용했는지도 기억하는가? 바로 에이전트가 장시간 실행되는 작업을 매우 꺼려하기 때문이었다… 그런데 코덱스 5.2가 출시되자, 이 요구사항은 하룻밤 사이에 사라졌다.

이것이 당신이 알아야 할 전부다… 어떤 것이 정말 중요하고 유용하다면, 클로드와 코덱스가 스스로 구현할 것이다! 따라서 당신은 ‘새로운 것’을 써야 할지, ‘새로운 것’을 익혀야 할지 걱정할 필요도 없고, 심지어 ‘업데이트를 따라가야 할’ 필요조차 없다.

한 가지 부탁을 드리겠다. 당신이 선택한 CLI 도구를 가끔씩 업데이트하고, 새로 추가된 기능을 읽어보는 것만으로도 충분하다.

압축, 컨텍스트 및 가정

에이전트를 사용하는 사람들은 종종 거대한 함정 하나를 마주한다: 때로는 지구상에서 가장 똑똑한 존재처럼 보이지만, 또 다른 때는 자신이 에이전트에게 속았다는 걸 믿기 어려울 정도로 어리석어 보이기도 한다.

“이 녀석이 똑똑하다고? 이건 그냥 바보야!”

가장 큰 차이점은 에이전트가 ‘가정을 해야 하거나’, ‘빈 칸을 채워야 할’ 상황에 처했는가 하는 것이다. 오늘날, 이들은 ‘점들을 연결하기’, ‘빈 칸 채우기’, 혹은 ‘가정하기’ 같은 작업에서 여전히 형편없다. 이 작업을 하게 되면, 즉각적으로 그 품질 저하가 눈에 띈다.

CLAUDE.md에서 가장 중요한 규칙 중 하나는 ‘어떻게 컨텍스트를 얻을 것인가’에 관한 규칙이며, 에이전트가 CLAUDE.md를 읽을 때(즉, 매번 압축 후) 가장 먼저 그 규칙을 읽도록 지시한다. 이 컨텍스트 획득 규칙의 일부로서, 단순한 몇 가지 지시어만으로도 엄청난 효과를 낼 수 있다: 작업 계획을 다시 읽고, 계속 진행하기 전에 관련 파일을 다시 읽는 것이다.

에이전트에게 작업을 어떻게 끝내야 할지 알려주기

우리는 인간으로서 ‘작업이 완료되었다’는 감각이 매우 분명하다. 그러나 에이전트에게 있어 현재 지능의 가장 큰 문제는, ‘작업을 시작하는 법’은 알지만 ‘어떻게 끝내야 할지’는 모른다는 점이다.

이 때문에 종종 매우 좌절스러운 결과가 발생한다: 에이전트가 결국 일련의 스텁(stub)만 구현하고 작업을 마치는 것이다.

테스트는 에이전트에게 매우 훌륭한 이정표(milestone)가 된다. 왜냐하면 테스트는 결정론적이며, 당신이 매우 명확한 기대치를 설정할 수 있기 때문이다. X개의 테스트가 모두 통과하지 않는 한, 작업은 완료되지 않았다—그리고 테스트 자체는 수정해서는 안 된다.

그러면 당신은 단지 테스트를 검토하기만 하면 된다. 모든 테스트가 통과하면, 안심할 수 있다. 이 과정을 자동화할 수도 있지만, 핵심은—‘작업의 종료’가 인간에게는 자연스럽지만, 에이전트에게는 그렇지 않다는 점을 기억하는 것이다.

최근에 또 어떤 것이 실현 가능한 작업 종료 지점이 되었는지 아는가? 스크린샷 + 검증이다. 당신은 에이전트에게 테스트가 모두 통과할 때까지 구현을 계속하라고 지시한 후, 스크린샷을 찍고 그 위의 ‘디자인 또는 동작’을 검증하라고 명령할 수 있다.

이를 통해, 에이전트가 첫 시도 후 멈춰버리는 걸 걱정하지 않고도, 당신이 원하는 디자인을 향해 반복적으로 개선해 나갈 수 있다!

이 아이디어의 자연스러운 연장선은, 에이전트와 ‘계약(contract)’을 체결하고 이를 규칙에 통합하는 것이다. 예를 들어, `{TASK}CONTRACT.md`는 당신이 세션을 종료할 수 있도록 허용되기 전에 반드시 완료되어야 할 사항들을 규정한다. `{TASK}CONTRACT.md` 내에서는, 테스트, 스크린샷, 기타 작업 종료 인증 전에 반드시 수행되어야 할 검증 사항들을 명시한다!

영원히 실행되는 에이전트

자주 받는 질문 중 하나는, 사람들이 어떻게 에이전트를 24시간 동안 실행하면서도 벗어나지 않도록 보장할 수 있는가 하는 것이다.

이에 대한 아주 간단한 방법이 있다. `{TASK}_CONTRACT.md`의 모든 항목이 완료되지 않으면, 세션 종료를 차단하는 stop-hook을 생성하는 것이다.

만약 당신이 100개의 명확히 정의된, 구축하고자 하는 내용을 포함한 계약을 가지고 있다면, stop-hook은 모든 100개의 계약(모든 테스트 실행 및 검증 포함)이 완료될 때까지 에이전트의 세션 종료를 막을 것이다!

전문 조언: 나는 24시간 동안 지속되는 긴 세션이 ‘일을 해내는 데’ 최적의 방식이 아니라고 본다. 그 이유 중 하나는, 이 방식이 구조적으로 컨텍스트 팽창을 강제로 유발한다는 점이다—왜냐하면 관련 없는 계약들의 컨텍스트가 모두 동일한 세션에 유입되기 때문이다!

그래서 나는 이 방식을 추천하지 않는다.

보다 나은 에이전트 자동화 방식은—각 계약마다 새 세션을 여는 것이다. 무언가를 해야 할 때마다 계약을 생성하라.

‘무언가를 해야 할 때’ 계약을 생성하고, 그 계약을 처리하기 위해 새 세션을 여는 오케스트레이션 계층(orchestration layer)을 구축하라.

이 방식은 당신의 에이전트 경험을 완전히 바꿔놓을 것이다.

반복, 반복, 또 반복

당신이 비서를 고용했다고 가정하자. 당신은 그 사람이 첫날부터 당신의 일정을 알고 있다고 기대할까? 아니면 당신이 커피를 어떻게 마시는지, 혹은 저녁을 오후 6시가 아니라 8시에 먹는지 알기를 기대할까? 당연히 아니다. 당신은 시간이 지남에 따라 점차 선호도를 형성해 갈 것이다.

에이전트도 마찬가지다. 가장 단순한 구성으로 시작하고, 복잡한 구조나 하네스는 잊어버리며, 기본 CLI에 기회를 주라.

그리고 나서, 점차 당신의 선호도를 추가해 나가라. 어떻게 해야 할까?

규칙(Rules)

당신이 에이전트에게 어떤 일을 하지 말라고 원한다면, 그것을 규칙으로 작성하라. 그리고 CLAUDE.md에서 에이전트에게 그 규칙을 알려주라. 예를 들어: “코드를 작성하기 전에 `coding-rules.md`를 읽어라.” 규칙은 중첩될 수 있고, 조건부일 수도 있다! 코드를 작성할 때는 `coding-rules.md`를 읽고, 테스트를 작성할 때는 `coding-test-rules.md`를 읽고, 테스트가 실패할 때는 `coding-test-failing-rules.md`를 읽는 식이다. 당신은 에이전트가 따라야 할 임의의 논리 분기를 규칙으로 만들 수 있으며, 클로드(및 코덱스)는 CLAUDE.md에 명확한 설명이 있다면 기꺼이 이를 따를 것이다.

사실, 이것이 내가 제시하는 첫 번째 실용적 조언이다: 당신의 CLAUDE.md를 특정 상황과 특정 결과에 따라 어디서 컨텍스트를 찾아야 할지를 설명하는, 논리적이고 중첩된 목록으로 간주하라. 그것은 가능한 한 간결해야 하며, ‘어떤 상황에서는 어디서 컨텍스트를 찾을 것인가’라는 IF-ELSE 논리만 포함해야 한다.

에이전트가 당신이 동의하지 않는 일을 하고 있다면, 그것을 규칙으로 추가하고, 다음에 그 일을 하기 전에 반드시 그 규칙을 읽도록 지시하라. 그러면 에이전트는 분명히 그 일을 다시 하지 않을 것이다.

스킬(Skills)

스킬은 규칙과 유사하지만, 코드 작성 선호도보다는 코드 ‘작업 절차’에 더 적합하다. 당신이 어떤 일을 특정 방식으로 완료하기를 원한다면, 그것을 스킬로 임베드하라.

사실, 사람들은 종종 ‘에이전트가 문제를 어떻게 해결할지 알 수 없어 불안하다’고 불평한다. 이것을 결정론적으로 만들고 싶다면, 에이전트가 먼저 문제 해결 방식을 조사하게 한 후, 그 방식을 스킬 파일로 작성하라. 그러면 당신은 에이전트가 실제로 그 문제에 직면하기 전에, 그 해결 방식을 미리 확인하고, 수정하거나 개선할 수 있다.

어떻게 해야 에이전트가 이 스킬의 존재를 알 수 있을까? 맞다! CLAUDE.md에 ‘이 상황에서 이 일을 처리해야 할 때, 이 `SKILL.md`를 읽어라’고 적어두면 된다.

규칙과 스킬 관리

당신은 분명 계속해서 에이전트에 규칙과 스킬을 추가하고 싶을 것이다. 이것이 바로 당신의 개성과 선호도를 에이전트에게 ‘기억’시키는 방식이다. 거의 다른 모든 것은 불필요하다.

이렇게 하기 시작하면, 당신의 에이전트는 마치 마법처럼 느껴질 것이다. 그것은 ‘당신이 원하는 방식’으로 일을 할 것이다. 그리고 당신은 비로소 ‘에이전트 엔지니어링의 진수’를 깨닫게 될 것이다.

그리고…

성능이 다시 하락하기 시작할 것이다.

왜지?!

아주 간단하다. 당신이 점점 더 많은 규칙과 스킬을 추가할수록, 그것들이 서로 모순되거나, 에이전트가 심각한 컨텍스트 팽창을 겪기 시작한다. 만약 당신이 프로그래밍을 시작하기 전에 에이전트가 14개의 마크다운 파일을 읽어야 한다면, 그 역시 쓸모없는 정보로 가득 차는 동일한 문제를 겪게 될 것이다.

어떻게 해야 할까?

정리하라. 당신의 에이전트에게 ‘스파(SPA)’를 받게 하라—즉, 규칙과 스킬을 통합하고, 업데이트된 선호도를 명시함으로써 모순을 제거하라.

그러면 다시 마법처럼 느껴질 것이다.

이것이 전부다. 이것이 바로 진짜 비결이다. 단순함을 유지하고, 규칙과 스킬을 활용하며, CLAUDE.md를 목록으로 사용하고, 컨텍스트와 설계적 한계를 성실히 주의하라.