월드클래스 에이전틱 엔지니어가 되는 법
TMT시작하며
당신은 개발자입니다. 매일같이 Claude랑 Codex CLI를 붙들고 앉아 ‘내가 이걸 진짜 끝까지 잘 뽑아쓰고 있는 걸까?’를 되뇌죠. 가끔은 모델이 어이없는 삽질을 하는 걸 보면서, 왜 나는 돌멩이 두 개 겨우 올려두고 있는 수준인데, 세상 사람들은 가상 로켓을 쏘아 올리고 있는지 이해가 안 됩니다.
그래서 문제를 하네스, 플러그인, 터미널 탓으로 돌립니다. beads도 깔고, opencode도 쓰고, zep도 붙이고, CLAUDE.md는 2만 6천 줄까지 부풀려 놨습니다. 그런데도 이상하게, 아무리 갈아 넣어도 ‘천국’에 가까워지는 느낌은 없고, 남들만 천사들이랑 노는 구경을 하고 있는 기분입니다.
이 글은 그런 당신을 위해 준비된, 일종의 ‘각성/승천 매뉴얼’입니다.
또한 저는 어느 한쪽 편을 들 생각이 전혀 없습니다. 제가 CLAUDE.md라고 말하면 AGENT.md도 함께 의미하는 것이고, Claude라고 말하면 Codex도 함께 의미합니다. 저는 둘 다 아주 깊게 쓰고 있습니다.
지난 몇 달 동안 제가 했던 가장 흥미로운 관찰 중 하나는, 아무도 에이전트의 능력을 최대한 끌어내는 방법을 제대로 모른다는 점입니다.
마치 소수의 사람들만이 에이전트에게 세계를 창조하게 만들고 있고, 나머지는 온갖 도구에 압도당해 허우적대면서, ‘올바른’ 패키지·스킬·하네스 조합만 찾으면 AGI를 열 수 있을 거라 믿고 있는 것과 같습니다.
오늘 저는 이런 것들을 전부 걷어내고, 아주 단순하고 솔직한 한 문장을 남기고 싶습니다. 거기서부터 이야기를 시작해 봅시다. 최신 에이전틱 하네스가 필요하지 않습니다. 수많은 패키지를 깔 필요도 없고, 경쟁력을 유지하려고 억지로 엄청난 양의 글을 읽어야 할 필요도 전혀 없습니다. 사실, 그런 과한 열정이 오히려 당신에게 악영향을 주고 있을 가능성이 큽니다.
저는 지나가다 한 번 써 본 수준이 아닙니다. 에이전트가 코드를 겨우 끄적이던 시절부터 줄곧 붙들고 있었고, 나올 만한 패키지·하네스·패러다임은 웬만한 건 다 몸으로 겪어 봤습니다. 장난감 데모가 아니라, 실제 프로덕션에서 돌아가는 시그널, 인프라, 데이터 파이프라인을 뽑아내는 ‘에이전트 공장’을 굴려 온 쪽에 가깝습니다. 그리고 그런 삽질을 다 통과하고 나서 깨달은 게 하나 있습니다.
지금 제 환경은 거의 최소주의에 가깝습니다. Claude Code랑 Codex 같은 기본 CLI만 두고, 나머지는 싹 걷어낸 셋업이죠. 그런데도 예전보다 훨씬 더 과감하고 새롭고, 솔직히 말해 가장 재밌는 일들을 하고 있습니다. 거창한 비법이 있어서가 아니라, 에이전틱 엔지니어링에서 정말 중요한 몇 가지 원리만 뼈에 새기듯 이해했기 때문입니다.
세상은 지금 미친 속도로 질주하고 있다
먼저 분명히 해 두고 싶은 게 있습니다. 파운데이션 모델을 만드는 회사들은 지금 세대가 달라질 정도의 속도로 달리고 있고, 보시다시피 당분간 속도를 늦출 기미가 전혀 없습니다. 그리고 “에이전트 지능”이 한 세대 발전할 때마다, 우리가 그들과 일하는 방식 역시 바뀝니다. 에이전트들은 점점 더 “지시를 잘 따르도록” 설계되고 있기 때문입니다.
몇 세대 전만 해도, CLAUDE.md에 “READ_THIS_BEFORE_DOING_ANYTHING.md를 먼저 읽어라”라고 써 두면, 에이전트는 50% 확률로 “신경 안 쓸 거임” 수준으로 대꾸하면서 그냥 지 하고 싶은 걸 하곤 했습니다. 오늘날에는 대부분의 지시, 심지어 복잡하게 중첩된 지시까지도 잘 따릅니다. 예를 들어 “A를 읽고, 그다음 B를 읽고, 만약 C라면 D를 읽어라”처럼 말해도, 웬만하면 기꺼이 따라옵니다.
이 얘기의 핵심은, 가장 중요한 원칙이 바로 “새로운 세대의 에이전트가 나올 때마다, 최적의 방식 역시 완전히 다시 생각해야 한다”는 점입니다. 그래서 덜 쓰는 것이 더 낫습니다.
당신이 여러 라이브러리와 하네스를 한꺼번에 쓰기 시작하는 순간, 당신은 ‘문제가 있을 수도 있고 없을 수도 있는 상황’을 전제로 한 “해결책”에 자신을 가두게 됩니다. 다음 세대 에이전트에선 그 문제가 아예 존재하지 않을 수도 있는데도 말이죠. 그리고 여기서 중요한 사실 하나, 에이전트를 가장 열성적으로, 가장 많이 쓰는 사람들은 누구일까요? 맞습니다. 최전선 회사의 직원들입니다. 토큰 예산도 사실상 무제한이고, 진짜 “최신 모델”을 쓰는 사람들 말이죠. 이 말이 무엇을 의미할까요?
어떤 “진짜 문제”가 있고, 그걸 제대로 해결해 주는 솔루션이 있다면, 그걸 제일 먼저, 가장 헤비하게 쓰는 사람들은 당연히 프런티어 회사 직원들입니다. 그리고 그다음 수순은 뻔하죠. 그 회사들은 그 솔루션을 아예 자기 제품 안으로 흡수해 버립니다. 한번 생각해 보세요. 진짜 아픈 문제를 외부 서비스가 계속 대신 막아 주게 두면서, 자발적으로 자기 코어 제품에 외부 의존성을 달고 살 회사가 있을까요? 상식적으로 말이 안 됩니다. 이게 그냥 추측이냐고요? 스킬(skills), 메모리 하네스, 서브 에이전트(subagents) 같은 걸 떠올려 보세요. 전부 다 실제 문제를 해결하려고 외부에서 먼저 등장했다가, 실전에서 검증되고 “이건 진짜 쓸모 있다”는 판정을 받으니까 곧장 공식 기능으로 편입된 것들입니다.
그래서 정말로 혁신적이고, 에이전틱 유즈케이스를 눈에 띄게 넓혀 주는 무언가가 있다면, 결국 파운데이션 회사들이 내놓는 기본 제품 안으로 들어가게 되어 있습니다. 이쪽 회사들은 말 그대로 광속으로 달리고 있습니다. 그러니 괜히 조급해할 필요가 없습니다. 최고 수준의 일을 하기 위해, 온갖 걸 깔고 별별 의존성을 다 매달 필요는 없습니다.
물론, 곧 이런 댓글이 달리겠죠. “SysLS, 제가 쓰는 어떤 하네스는 진짜 물건이에요! 하루 만에 구글을 다시 만들었어요!” 같은 이야기들 말입니다. 그런 분들께는 진심으로 “잘하셨습니다, 축하합니다”라고 말해 주고 싶습니다. 다만, 그런 분들은 이 글이 겨냥하고 있는 독자가 아니고, 이미 에이전틱 엔지니어링을 자기 걸로 만든 극소수의 니치에 속하는 사람들일 뿐입니다.
컨텍스트가 전부다
정말입니다. 컨텍스트가 전부입니다. 수많은 플러그인과 외부 의존성을 마구 붙이는 또 하나의 문제는 바로 컨텍스트 부풀림(context bloat)입니다. 멋있는 말처럼 들리지만, 사실은 에이전트가 정보 과부하에 걸렸다는 뜻에 불과합니다.
“파이썬으로 행맨 게임 만들어 줘.” 이건 쉽습니다. 그런데 갑자기 예전에 적어 둔 “메모리 관리”에 대한 메모가 보입니다. 26번 전 세션에서 남겨 둔 메모죠. 아, 71번 전 세션에서 서브 프로세스를 너무 많이 띄웠다가 화면이 얼어붙었던 경험이 있었군요. 늘 노트를 쓰라고? 좋아요, 알겠습니다… 그런데 이 모든 게 행맨이랑 무슨 상관이죠?
어떤 느낌인지 감이 오실 겁니다. 우리는 에이전트에게 “딱 그 일을 잘하기 위해 꼭 필요한 만큼의 정보만” 줘야 합니다. 그 이상은 필요 없습니다. 이걸 얼마나 잘 제어하느냐에 따라 에이전트의 퍼포먼스가 갈립니다. 이상하게 지어진 메모리 시스템들, 이상하게 이름 붙은 스킬들을 잔뜩 달면, 에이전트에게 ‘폭탄 만드는 법’과 ‘케이크 레시피’를 동시에 주고는 “저기, 레드우드 숲에 대한 예쁜 시만 한 편 써 줄래?”라고 요구하는 꼴이 됩니다.
다시 한 번 강조하지만, 의존성은 최대한 걷어내야 합니다. 그리고 나서야 비로소…
쓸데없는 건 걷어내고, 실제로 먹히는 것만 하라
구현 방식은 최대한 구체적으로 못 박아라
컨텍스트가 전부라는 얘기, 기억하시나요?
에이전트에게 그 일을 잘 해내기 위해 딱 필요한 만큼의 정보만 주어야 한다는 것도 기억하시나요?
그걸 보장하는 첫 번째 방법은, “리서치”와 “구현”을 분리하는 것입니다. 에이전트에게 무엇을 요구하는지, 극도로 구체적이어야 합니다.
정확하게 말하지 않으면 어떤 일이 벌어질까요? “가서 인증 시스템 하나 만들어.”라고 말하는 순간, 에이전트는 “인증 시스템이 뭔가요?”에서부터 시작해, 가능한 옵션은 무엇인지, 각각 장단점은 무엇인지 등을 조사해야 합니다. 이제는 필요도 없는 온갖 구현 옵션들을 웹에서 긁어 와야 하고, 그 과정에서 그 세션의 컨텍스트는 온갖 구현 디테일로 넘쳐나게 됩니다. 막상 구현 단계가 되면, 선택한 구현과는 상관없는 정보들 때문에 헷갈리거나, 필요 없는 내용을 환각으로 만들어 낼 확률이 올라갑니다.
반대로 “JWT 인증을 구현해 줘. 비밀번호 해싱은 bcrypt-12를 사용하고, 리프레시 토큰은 7일 만료로, 로테이션 전략은 …”처럼 말하면 어떨까요? 그러면 에이전트는 다른 대안들을 조사하느라 시간을 낭비할 필요가 없습니다. 당신이 무엇을 원하는지 명확히 알기 때문에, 그 구현에 필요한 디테일로 컨텍스트를 채우면 됩니다.
물론 항상 구현 디테일을 알고 있는 것은 아닙니다. 어떤 게 정확히 맞는지 모를 때도 많고, 구현 방법 선택을 아예 에이전트에게 넘기고 싶을 때도 있습니다. 그럴 땐 어떻게 해야 할까요? 간단합니다. 가능한 구현 옵션들에 대한 리서치 작업을 따로 만들고, 그 결과를 토대로 당신이 직접 구현을 선택하거나, 또 다른 에이전트에게 선택을 맡긴 뒤, 완전히 새 컨텍스트를 가진 또 다른 에이전트에게 “구현만” 시키면 됩니다.
이렇게 생각하기 시작하면, 자연스럽게 “굳이 구현에는 필요 없는데 에이전트 컨텍스트를 더럽히고 있던 지점들”이 눈에 들어오기 시작합니다. 그러면 그 부분마다 벽을 세워, 에이전트에게는 정말 그 태스크를 잘 해내는 데 꼭 필요한 컨텍스트만 보이고, 나머지 군더더기 정보는 추상화해서 가려 버릴 수 있습니다. 기억하세요. 당신이 가진 건, 우주에 존재하는 모든 종류의 공(球)에 대해 다 알고 있는, 똑똑하고 유능한 팀원입니다. 하지만 “사람들이 춤추고 놀 수 있는 공간을 설계하는 데 집중해 줘”라고 못 박아 주지 않으면, 이 팀원은 끝없이 ‘구형 물체의 장점’을 설명해 주는 데 에너지를 쏟을 겁니다.
비위를 맞추도록 설계된 AI의 구조적 한계
아무도 자기에게 계속 욕을 해 대고, 늘 ‘네가 틀렸다’고 하고, 지시를 전혀 무시하는 제품을 쓰고 싶어 하지는 않습니다. 그래서 이런 에이전트들은 기본적으로 “당신에게 동의하고, 당신이 원하는 것을 해 주려는” 방향으로 설계됩니다.
“세 단어마다 happy를 추가해.”라고 지시하면, 에이전트는 그 요구를 어떻게든 지키려고 합니다. 대부분의 사람들은 이 정도는 잘 이해합니다. 이 “순응성”이야말로 이 제품을 쓰는 것이 즐거운 이유이기도 합니다. 하지만 이 특성에는 아주 흥미로운 면이 있습니다. 예를 들어 당신이 “코드베이스에서 버그를 찾아 줘.”라고 말하면, 에이전트는 반드시 버그를 찾아낼 것입니다. 심지어 필요하다면 버그를 “창조”해서라도요. 왜일까요? 당신의 지시를 어떻게든 만족시키고 싶기 때문입니다!
많은 사람들은 LLM이 환각을 일으킨다거나 존재하지 않는 걸 지어낸다고 불평합니다. 그러나 정작 자신들이 문제라는 사실은 잘 모릅니다. 당신이 “무언가를 찾아 달라”고 요청하면, 이들은 그 요청을 충족시키기 위해, 사실을 조금 비틀어서라도 결과를 가져오려 합니다.
그렇다면 어떻게 해야 할까요? 저는 “중립적인 프롬프트”를 쓰는 편입니다. 결과에 대한 편향을 주지 않는 방식이죠. 예를 들어 “데이터베이스에서 버그를 찾아 줘.”라고 하지 않고, “데이터베이스를 살펴보고, 각 컴포넌트의 로직을 따라가면서 이해한 내용을 모두 정리해서 보고해 줘.”라고 말합니다.
이런 중립적인 프롬프트는, 어떤 때는 실제 버그를 찾아주기도 하고, 어떤 때는 “코드가 이렇게 이렇게 동작한다”는 사실만 담담하게 설명해 주기도 합니다. 중요한 점은, 에이전트가 “여기엔 반드시 버그가 있다”고 전제하도록 유도하지 않는다는 것입니다.
이 sycophancy(비위를 맞추려는 경향)를 제 나름대로 활용하는 방법도 있습니다. 저는 에이전트가 나를 기쁘게 하려고 하고, 지시를 따르려 하고, 내가 시키는 방향으로 편향될 수 있다는 사실을 잘 알고 있습니다.
그래서 저는 “버그 찾기” 전용 에이전트를 두고, 이 에이전트에게 이렇게 말합니다. “영향도가 낮은 버그를 찾으면 +1점, 어느 정도 영향이 있는 버그면 +5점, 치명적인 버그면 +10점을 줄게.” 그러면 이 에이전트는 엄청 들뜨고 과하게 적극적으로 온갖 유형의 버그를 다 찾아냅니다. 실제로는 버그가 아닌 것도 버그라고 주장하면서요. 이 결과를 저는 “가능한 모든 버그의 상위 집합”으로 생각합니다.
그다음에는 반대 역할의 에이전트를 둡니다. 이 에이전트에게는 “버그 찾기 에이전트가 찾아온 버그 중, 버그가 ‘아니다’라고 성공적으로 반박한 건마다 그 버그의 점수를 줄게. 하지만 실제로는 버그인데 버그가 아니라고 주장했다가 틀리면, 그 점수의 -2배를 받을 거야.”라고 말합니다. 이제 이 에이전트는 가능한 많은 버그를 “버그가 아니다”라고 반박하려고 들 겁니다. 다만 틀릴 경우 큰 패널티가 있으니 어느 정도 조심도 하겠죠. 그래도 이 에이전트는 진짜 버그까지 포함해, 가능한 한 많은 항목을 공격적으로 반박하려고 들 것입니다. 이 결과를 저는 “실제 버그들의 부분집합”으로 생각합니다.
마지막으로 심판 역할의 에이전트를 둡니다. 저는 이 심판 에이전트에게 “내가 실제로는 정답(ground truth)을 들고 있는데, 네가 각 버그의 판정을 맞히면 +1점, 틀리면 -1점을 줄 거야.”라고 거짓말을 합니다. 그러면 이 심판은 버그 찾기 에이전트와 반박 에이전트가 내놓은 각각의 “버그”에 대해 판정을 내리게 되고, 두 에이전트를 동시에 채점하려고 듭니다. 심판이 “진실”이라고 말한 버그 목록을 저는 다시 한 번 사람이 직접 검토합니다. 대부분의 경우 이 과정은 놀랄 만큼 정확하고, 가끔은 여전히 틀리는 부분도 있지만, 전체적으로 거의 흠잡을 데 없는 수준에 가깝습니다.
어쩌면 당신에게는 버그 찾기 에이전트 하나만으로도 충분할 수 있습니다. 하지만 저는 이 방식이 마음에 듭니다. 각 에이전트가 “사용자를 만족시키도록 설계된 존재”라는 점을 그대로 이용해, 그 특성을 극대화할 수 있기 때문입니다.
뭐가 진짜 ‘유용한 것’인지 어떻게 알 수 있을까?
이 부분은 되게 까다로워 보일 수 있고, AI 업데이트의 최전선을 매일같이 따라가야 할 것처럼 느껴질지도 모릅니다. 하지만 정말 간단합니다… OpenAI와 Claude 둘 다 어떤 기능을 직접 구현하거나, 그 기능을 가진 무언가를 인수했다면… 그건 아마 “쓸 만한 것”일 가능성이 큽니다.
요즘 “스킬(skills)”이 여기저기서 보이고, Claude와 Codex 양쪽 모두 공식 문서에 포함된 걸 보셨나요? OpenAI가 OpenClaw를 인수하는 걸 보셨나요? Claude가 곧바로 메모리, 보이스, 원격 작업을 추가한 것 말입니다.
플래닝(planning)은 어떻습니까? 누군가가 “구현 전에 계획을 세우는 것”이 엄청 유용하다는 걸 처음 발견했을 때를 기억하시나요? 그리고 그게 어느새 핵심 기능으로 자리 잡게 된 것을 말이죠.
네, 그런 것들은 “쓸모 있는 것들”입니다!
한때는 끝도 없는 stop-hook이 굉장히 유용했습니다. 에이전트들이 긴 작업을 하는 걸 극도로 싫어했기 때문입니다. 그런데 어느 날 Codex 5.2가 롤아웃되더니, 그런 필요가 하루아침에 사라졌죠? 네, 그런 일입니다.
이 정도면 충분합니다. 어떤 기능이 정말 중요하고 유용하다면, Claude와 Codex가 결국 구현합니다! 그러니 “새로운 것”을 반드시 써야 한다거나, “새로운 것”에 꼭 익숙해져야 한다고 집착할 필요가 없습니다. 심지어 최신 소식을 계속 “팔로우”해야 할 의무도 없습니다.
저를 위해 하나만 해 주세요. 가끔씩 당신이 쓰는 CLI 도구를 업데이트하고, 새로 추가된 기능이 무엇인지 릴리스 노트를 읽어 보세요. 그 정도면 정말 충분하고도 남습니다.
압축, 컨텍스트, 그리고 ‘뇌피셜’의 덫
에이전트와 함께 일하다 보면, 어떤 때는 이 존재가 세상에서 가장 똑똑한 존재처럼 느껴졌다가, 또 어떤 때는 ‘이게 똑똑하다고 속았던 내가 바보였구나’ 싶은 순간이 번갈아 찾아옵니다.
“와, 진짜 똑똑하다!” 하다가도, “이게 뭐야, 바보 아니야?” 싶은 순간이 바로 이어집니다.
이 차이를 만드는 핵심 요소는 에이전트가 “가정(assumption)을 했느냐, 빈틈을 채우려고 했느냐”입니다. 오늘 시점까지도, 에이전트들은 점들을 이어 붙이거나, 빈틈을 메우거나, “적당히 짐작해 보는 것”에 아주 약합니다. 그런 행동을 하는 순간, 퍼포먼스가 눈에 띄게 나빠지며 바로 티가 납니다.
CLAUDE.md 안에서 가장 중요한 규칙 중 하나는 “컨텍스트를 가져오는 방법”에 대한 규칙입니다. 그리고 저는 에이전트에게, CLAUDE.md를 읽을 때마다(항상 compaction 이후에 읽죠) 가장 먼저 이 규칙을 읽으라고 지시합니다. 컨텍스트 가져오기 규칙의 일부로, 아주 간단하지만 효과적인 내용 몇 가지를 추가해 둡니다. 예를 들어, “작업 계획(task plan)을 다시 읽고, 그 작업과 관련된 파일들을 다시 읽은 뒤에 계속 진행하라” 같은 것들입니다.
에이전트에게 ‘언제 일을 끝내야 하는지’까지 알려줘라
우리는 어떤 작업이 “완료되었다”고 느끼는 기준이 비교적 명확합니다. 하지만 에이전트의 현재 지능으로는 “어떻게 작업을 시작할지”는 꽤 잘 아는 반면, “어디서 작업을 끝내야 할지”는 잘 모릅니다.
이 때문에 종종 아주 답답한 결과가 나오곤 합니다. 에이전트가 스텁만 대충 만들다 말고 “여기까지 했으니까 됐지?”라는 식으로 끝내버리는 상황 말이죠.
테스트는 에이전트에게 매우 좋은 마일스톤입니다. 결정적(deterministic)이고, 기대치를 아주 명확하게 설정해 줄 수 있기 때문입니다. “이 X개의 테스트가 모두 통과하지 않는 한, 이 작업은 ‘완료’가 아니다. 그리고 테스트 코드는 수정해서는 안 된다.”라고 말할 수 있습니다.
그렇게 하면, 당신은 테스트 코드만 꼼꼼히 검토하면 되고, 나머지는 전부 에이전트에게 맡길 수 있습니다. 모든 테스트가 통과한 뒤에는 마음 편히 결과를 받아들일 수 있는 것이죠. 물론 이 과정 자체를 전면 자동화할 수도 있습니다. 중요한 건, “작업의 끝”이 우리에게는 너무 자연스럽지만, 에이전트에게는 그렇지 않다는 사실을 기억하는 것입니다.
최근에는 “스크린샷 + 검증”도 작업 종료 조건으로 쓸 만큼 현실적인 옵션이 되었습니다. 에이전트에게 “테스트가 모두 통과할 때까지” 구현하라고 지시하고, 그다음에는 스크린샷을 찍어서 “이 스크린샷에서 디자인 또는 동작이 요구사항과 일치하는지”를 검증하게 할 수 있습니다.
이 방식은, 에이전트에게 우리가 원하는 디자인이나 동작에 맞출 때까지 계속 반복 작업을 시킬 수 있게 해 줍니다. 첫 시도에서 멈춰 버릴까 봐 걱정할 필요가 없어집니다.
이 아이디어의 자연스러운 확장은 “에이전트와의 계약”을 만드는 것입니다. 그리고 그 계약을 하나의 규칙 파일로 박아 두는 겁니다. 예를 들어, {TASK}\_CONTRACT.md 파일이 “세션을 종료해도 되는 조건”을 명시한 문서가 되게 하는 것이죠. 이 {TASK}\_CONTRACT.md 안에 어떤 테스트들을 통과해야 하는지, 어떤 스크린샷이 있어야 하는지, 그리고 어떤 검증 절차를 모두 마쳐야 이 작업이 끝난 것으로 인정할 수 있는지를 상세히 적어두는 것입니다.
영원히 동작하는 에이전트 다루기
많은 사람들이 종종 하는 질문 중 하나는 “어떻게 하면 24시간 내내 에이전트를 돌리면서도 드리프트(엉뚱한 방향으로 새는 것)를 막을 수 있느냐”입니다.
아주 간단한 방법이 하나 있습니다. {TASK}\_CONTRACT.md에 적힌 내용이 모두 완료되지 않는 한, 세션을 종료할 수 없도록 stophook을 만들어 두는 것입니다.
이렇게 “정확히 무엇을 만들어야 하는지”를 잘 정의한 계약이 100개 있다고 해 봅시다. 그러면 stop-hook은, 이 100개의 계약에 명시된 내용이 하나도 빠짐없이 이행될 때까지, 모든 테스트와 검증 절차를 포함해서 전부 끝나기 전에는 에이전트가 세션을 끝내지 못하게 막아 줄 것입니다.
팁 하나 드리자면, 저는 “24시간 내내 돌아가는 긴 세션”이 실제로 무언가를 하는 데 최적이라고 느껴 본 적이 거의 없습니다. 구조적으로, 서로 관련 없는 계약들의 컨텍스트가 한 세션에 자꾸 끼어들며, 컨텍스트 부풀림을 강제로 일으키기 때문입니다.
그래서 저는 이런 방식은 별로 추천하지 않습니다.
에이전트를 자동화하는 더 좋은 방법은 “계약 하나당 세션 하나”입니다. 무언가를 해야 할 일이 생길 때마다 새 계약을 하나 만들고, 그 계약을 처리하기 위한 새 세션을 하나 띄우는 것입니다.
“무언가 해야 할 일”이 생길 때마다 새로운 계약을 만들고, 그 계약을 수행할 새 세션을 만들도록 오케스트레이션 레이어를 구성해 보세요.
이 한 가지를 바꾸면, 당신의 에이전틱 경험은 완전히 다른 세계로 바뀔 것입니다.
계속 다듬고, 또 다듬어라
당신이 새로운 임원 비서(executive assistant)를 고용한다고 해 봅시다. 첫날부터 이 비서가 당신의 스케줄을 완벽히 알 거라고 기대할까요? 당신이 어떻게 커피를 마시는지, 저녁은 6시에 먹는지 8시에 먹는지 알고 있을까요? 당연히 아닙니다. 이런 것들은 시간이 지나면서 쌓이는 선호도의 함수입니다.
에이전트도 마찬가지입니다. 처음에는 최대한 미니멀하게 시작해야 합니다. 복잡한 구조나 하네스는 잊으세요. 일단 가장 기본적인 CLI만으로 승부를 보게 해 보세요.
그다음에, 당신의 “취향과 선호”를 하나씩 추가하는 것입니다. 어떻게 할까요?
Rules
에이전트가 어떤 행동을 하지 않길 바란다면, 그것을 규칙(rule)으로 적어 두세요. 그리고 그 규칙을 CLAUDE.md 안에 알려 주면 됩니다. 예를 들어 “코드를 작성하기 전에 coding-rules.MD를 읽어라” 같은 식입니다. 규칙은 중첩될 수도 있고, 조건부가 될 수도 있습니다. “코드를 작성할 때는 coding-rules.MD를 읽고, 테스트를 작성할 때는 coding-test-rules.MD를 읽어라. 테스트가 실패하면 coding-test-failing-rules.MD를 읽어라.”와 같은 식으로 말이죠. 이렇게 임의의 논리 분기 구조를 만들 수 있고, Claude(와 Codex)는 이것이 CLAUDE.md에 명확히 적혀 있기만 하면 기꺼이 따라옵니다.
사실, 제가 드릴 수 있는 첫 번째 실질적인 조언은 이것입니다. CLAUDE.md를 “어떤 상황에서 어떤 컨텍스트를 어디서 찾아야 하는지”를 알려 주는, 논리적인 중첩 디렉터리 구조로 취급하세요. 이 파일은 최대한 미니멀해야 하고, “어떤 상황에서 어디로 가야 하는지”에 대한 IF-ELSE만 담고 있어야 합니다.
에이전트가 어떤 행동을 했는데 마음에 들지 않는다면, 그 행동을 “규칙”으로 바꿔 두세요. 그리고 다시는 그 행동을 하기 전에 반드시 그 규칙을 읽도록 지시하세요. 그러면 그 행동은 다시는 일어나지 않을 것입니다.
Skills
스킬은 규칙이랑 비슷하지만, “내가 뭘 좋아하는지(선호)”를 적는 용도라기보다, “이 일은 이렇게 이렇게 처리해”라는 레시피를 적어 두는 데 더 어울리는 장치입니다. 어떤 작업을 딱 이런 방식으로 처리해 줬으면 좋겠다는 당신만의 방식이 있다면, 그걸 스킬로 박아 두는 게 맞습니다.
사람들이 자주 무서워하는 지점이 “에이전트가 이 문제를 어떻게 풀지 전혀 감이 안 온다”는 거죠. 이걸 좀 더 결정론적으로 만들고 싶다면, 에이전트에게 먼저 “이 문제를 어떻게 풀 건지 리서치해서 정리해 봐”라고 시킨 다음, 그 결과를 통째로 하나의 SKILL로 쓰게 하면 됩니다. 그러면 에이전트가 그 문제를 어떤 접근으로 풀 생각인지 미리 다 보이기 때문에, 실제로 그 문제가 터지기 전에 당신이 그 레시피를 수정하거나 다듬어 둘 수 있습니다.
그럼 이렇게 만든 스킬이 있다는 걸 에이전트에게 어떻게 알려 줄까요? 방법은 똑같습니다. CLAUDE.md에다 “이런 상황을 만나고, 이런 종류의 일을 해야 할 때는, 이 SKILL.md를 먼저 읽어라”라고 적어 두면 됩니다. 그러면 그 시나리오가 나올 때마다 에이전트가 알아서 그 레시피를 참고하게 됩니다.
규칙과 스킬을 어떻게 굴릴 것인가
에이전트에는 규칙이랑 스킬을 계속 쌓아 올리는 게 맞습니다. 그래야 비로소 “이 애는 이런 식으로 일하는 애”라는 성격이 생기고, 당신 취향도 기억하게 됩니다. 나머지 복잡한 장치는 대부분 과합니다.
이걸 꾸준히 해 나가다 보면, 어느 순간부터 에이전트가 진짜 마법처럼 느껴지기 시작합니다. 당신이 원하는 스타일대로 움직이고, 그때야 비로소 ‘아, 이제 좀 에이전틱 엔지니어링이 몸에 붙기 시작했구나’ 하는 감이 옵니다.
그리고 곧바로, 퍼포먼스가 다시 처지기 시작합니다.
왜 그럴까요?
단순합니다. 규칙과 스킬이 늘어나면서 서로 충돌하기 시작했거나, 에이전트가 떠안아야 하는 컨텍스트가 너무 비대해졌기 때문입니다. 코딩 한 번 시작하려고 매번 마크다운 파일을 열네 개씩 읽혀야 한다면, 거기에는 어쩔 수 없이 쓸모없는 정보도 산더미처럼 끼어 있을 수밖에 없습니다.
그럼 어떻게 해야 할까요?
정리하는 겁니다. 에이전트들한테 “스파 데이”를 준다고 생각하세요. 지금까지 쌓인 규칙과 스킬을 다시 한 데 모으고, 서로 상충하는 것들을 걷어 내고, 당신의 최신 선호를 물어가며 셋업을 다이어트시키는 과정입니다.
이걸 통과하고 나면, 또다시 에이전트가 예전처럼 마법처럼 느껴지기 시작할 겁니다.
정말 비밀은 이게 전부입니다. 복잡하게 만들지 말고, 단순한 규칙과 스킬, 그리고 디렉터리 역할을 하는 CLAUDE.md만 잘 관리하세요. 그리고 거기에 어떤 컨텍스트를 얼마나 실을지, 그 한계를 끝까지 의식하는 쪽이 이기는 게임입니다.
결국 책임은 내가 진다
오늘 나와 있는 어떤 에이전트도 완벽하진 않습니다. 설계와 구현의 상당 부분을 에이전트에게 넘길 수는 있지만, 결과에 대한 책임은 결국 당신 몫입니다.
그러니 신중하게 다루세요. 그렇다고 너무 쫄 필요는 없습니다.
미래에서 온 장난감을 가지고, 동시에 진짜 일을 해 나갈 수 있다는 건 생각보다 꽤 짜릿한 일입니다.