Thariq Shihipar는 Anthropic의 Claude Code 팀에서 일한다. Peter Yang은 이 대담에서 그에게 두 가지를 묻는다. 사람이 프롬프트를 하나씩 보내는 방식에서 벗어나 에이전트가 스스로 오래 일하게 하려면 무엇을 설계해야 하는가, 그리고 그동안 사람은 무엇을 해야 하는가. Thariq는 자신의 영상 편집 작업과 Peter의 팟캐스트 제작 스킬을 화면에 띄워 놓고 답한다.
출발점은 Thariq의 관찰이다. 모델이 똑똑해질수록 방향 제시와 제약과 예시가 덜 필요해졌다. 그렇다면 사람이 할 일도 줄어드는가. 그의 답은 사람의 일이 사라지지 않고 옮겨 간다는 것이다. /goal과 워크플로는 에이전트가 멈추지 않고 일하게 하는 장치이지만, 사람이 먼저 모르는 것을 없애고, 결과를 판단할 기준을 세우고, 만드는 에이전트와 검증하는 에이전트를 나눠 두어야 제대로 작동한다.
그 결과 사람에게 남는 일은 한 프로젝트에 집중하는 것, 지침을 줄이는 것, 시스템의 제약을 배우는 것이다. 올해 목표를 더 생산적이면서 덜 일하는 것이라고 말한 Thariq에게 이것은 더 빠르게만이 아니라 더 낫게 일하는 방법이다. 노트 끝에는 2026-07-20 deep-dive에서 정리한 해석이 남아 있다. 스킬과 작업 공간의 차이, 코드 정리가 다음 구현에 미치는 영향, 짧은 지침과 깊은 이해의 관계를 다룬 기록이다.
/goal과 워크플로 중 무엇을 쓸지는 결과를 얼마나 기계적으로 검증할 수 있는지가 정한다
Thariq는 루프를 에이전트가 피드백을 받으며 조율된 방식으로 오래 일하게 하는 여러 방법을 아우르는 말로 쓴다. Claude Code에는 /loop, /goal, 워크플로가 있고, 셋 모두 에이전트를 오래 실행하는 데 목적이 있다. 대담에서 그가 자세히 설명하는 것은 뒤의 둘이다. /goal은 에이전트가 자신의 종료 조건을 계속 기억하게 하고, 그 조건을 충족해야만 작업을 끝내게 한다. /goal이 필요한 이유는 Claude가 일하는 방식에 있다. 작업 중에 스펙과 맞지 않거나 사용자의 말과 다른 상황을 만나면, Claude는 사람처럼 계속해도 되는지 묻고 일찍 멈출 수 있다. /goal은 스펙 작성과 탐색은 충분히 했으니 실행하고, 막히는 부분은 알아서 채우라고 사용자가 알리는 신호다. 워크플로는 그가 가장 강력하다고 보는 형태로, 하위 에이전트를 띄워 작업을 병렬로 나눠 수행하고 그 결과를 검증한다. 특히 비기술 작업에서는 비결정적인 작업을 어느 정도 결정적인 작업으로 바꾸는 방법이 된다.
무엇을 쓸지는 작업이 정한다. 지연 시간처럼 결정적인 신호가 있으면 /goal을 걸고 에이전트가 auto research처럼 스스로 탐색하게 하면 된다. 디자인이라면 먼저 에이전트가 원하는 디자인을 얼마나 정확히 알 수 있는지를 따진다. Figma 파일이 있으면 Figma MCP를 연결하고 렌더링된 디자인이 Figma와 일치하는지 확인하라는 /goal을 걸 수 있는데, 이 방식은 스크린샷과 비교하는 방식보다 일치 여부를 판단하기가 훨씬 쉽다. 스크린샷밖에 없다면 판단이 모호해지므로, 평가표와 검증 에이전트를 둔 워크플로가 맞다. Peter가 한 줄짜리 요청으로 게임을 만들게 했다가 작업이 엉뚱한 방향으로 흘러간 경험을 말하자, Thariq는 원하는 것을 구체적으로 정하는 데 많은 노력이 든다고 답한다.
그 작업을 마친 뒤의 모습은 영상 시연에서 드러난다. Thariq는 대담 10분 전에 짧은 영상을 찍었다. 영상에서 그는 오버레이를 넣을 곳을 손으로 가리키고, 마지막에는 화면을 검게 전환하라고 말한다. 프롬프트는 몇 문장이다. 저장소에 있는 샘플 영상을 Whisper로 전사하고, 대담 자막에서 reotion으로 표기된 렌더링 도구로 단어마다 강조되는 자막과 여러 오버레이를 보여 주는 UI를 만들고, 영상이 완전히 렌더링될 때까지 멈추지 말라는 목표를 걸었다. 이 한 번의 요청으로 Claude Code는 전사, 자막, 오버레이, 검은 화면 전환을 모두 만들었다.
한 줄 프롬프트가 통하려면 먼저 모르는 것을 없애야 한다
Thariq는 그 프롬프트에 이르기까지 많은 계획과 학습이 필요했다고 말한다. 그가 보기에 계획은 한 번 세우고 실행하면 끝나는 일이 아니라, 탐색하고 조사하면서 자신이 무엇을 모르고 무엇을 원하는지 알아내는 반복 과정이다. 그래서 그는 계획이라는 말이 너무 넓다고 느끼고, 모르는 것을 없애는 일이라고 부르기를 좋아한다. 모르는 것은 대개 두 가지다. 일이 어떻게 작동하는지 모르거나, 자신이 무엇을 원하는지 모른다. 이 일은 학습, 기술 스펙, 목업과 탐색처럼 여러 형태를 띤다.
작동 방식을 모르는 경우의 예가 Whisper다. 그는 계획 단계에서 Claude Code에게 Whisper를 설명하고 엣지 케이스를 알려 달라고 요청했고, Claude Code는 설명 문서를 만들었다. 문서에는 무음 구간이 "Thanks for watching"으로 전사될 수 있고, 한 단어가 두 조각으로 나뉠 수 있으며, Whisper가 화자를 구분하지 못한다는 내용이 들어 있었다. 이 한계를 미리 안 덕분에 그는 Whisper를 기반으로 복잡한 워크플로를 만든 뒤에야 문제를 발견하는 상황을 피했다. 같은 방식으로 피사체 뒤에 글자를 넣으려고 영상 분할 기법을 조사했을 때는, 쓸 만큼 안정적인 방법이 없다는 결론을 얻고 그 시도를 포기했다.
원하는 것을 모르는 경우의 예는 디자인이다. 대담 도중 그는 Peter의 블로그를 참고 자료로 주고, 그 스타일로 오버레이와 자막의 디자인 변형을 탐색하는 HTML 아티팩트를 만들게 했다. 결과물은 Peter의 브랜드보다 Substack의 브랜드에 가까웠지만, 시안끼리 차이가 커서 고르고 다듬을 출발점이 되었다. 그가 디자인 변형을 여러 개 만들게 한 것은, 디자이너가 아니어서 원하는 디자인을 눈으로 보아야 알 수 있기 때문이다. 스킬을 만드는 시점도 같은 원칙을 따른다. 그는 영상 편집 작업을 아직 스킬로 만들지 않았다. 손으로 가리킨 위치를 에이전트가 잘 찾게 하려고 여러 번 유도해야 했고, 지금 결과도 만족스럽지 않기 때문이다. 그는 원하는 결과와 엣지 케이스를 먼저 확실히 알아낸 뒤에 스킬로 만든다.
스펙은 구현 중에 에이전트가 남긴 노트와 시제품으로 다시 고친다
Peter는 10년 동안 문제와 해결책과 목표를 적는 제품 스펙을 써 왔다. 이제 그 문서를 에이전트도 읽으니, 사람이 읽을 부분과 에이전트가 읽을 부분을 나눠야 하는지 묻는다. Thariq는 둘이 밀접하게 묶여 있다고 답하고, 질문의 전제를 바꾼다. 스펙은 처음에 한 번 쓰고 구현에 넘기는 문서가 아니다. 스펙은 사람의 요청에서 시작한다. 에이전트가 기술 탐색을 하고 목업과 설명 문서로 모르는 것을 줄이면, 사람이 그 결과를 다듬어 다시 에이전트에게 준다. 에이전트가 구현을 시작하면 그는 예상하지 못한 점을 구현 노트로 남기게 하고, 필요하면 그 노트를 바탕으로 스펙을 다시 쓴다. 스펙과 구현 사이에는 한 번의 인계가 아니라 여러 번의 왕복이 있다.
구현 비용이 낮아졌다는 점이 이 방식을 뒷받침한다. Peter의 말처럼 가장 단순한 버전을 먼저 만들고 고쳐 나갈 수 있다. Thariq는 앞의 HTML 오버레이 시안을 시제품으로 본다. 마음에 드는 시안이 나오면 그때 React로 다시 구현하는 비싼 단계로 넘어간다. React로 옮기면 코드를 고치고 영상을 다시 렌더링해야 하기 때문이다. 그가 묻는 것은 원하는 개념과 스펙을 증명할 수 있는 가장 작은 단계가 무엇이냐는 것이다.
이렇게 고쳐 쓰는 문서는 HTML로 남아 다음 작업에서 다시 참조된다. Peter는 이것을 살아 있는 문서라고 부른다. Anthropic에서는 이제 문서를 이렇게 공유한다. Claude에게 계획, 이미 끝낸 PR, 상태 보고, 장애 보고를 아티팩트로 만들게 해 동료와 나눈다.
스크립트가 쌓이는 작업은 스킬보다 작업 공간 저장소에서 키운다
Peter는 자신의 팟캐스트 제작 스킬을 보여 준다. 인터뷰 전사를 붙여 넣으면 썸네일 문구, 잘라 낼 부분, 게시물 문안을 만든다. 영상 게시물 스킬은 YouTube 영상을 받아 클립 아이디어를 내고, 클립을 실제로 잘라 자막을 입힌다. 그러나 결과는 완벽하지 않다. 그는 스킬이 B-roll과 오버레이를 넣고, Claude 로고처럼 필요한 자료를 인터넷에서 찾아오기를 바란다.
Thariq는 먼저 하나의 저장소를 계속 쓰면서 작업하는지 묻는다. Peter는 스킬을 모두 사용자 수준에 두고, 출력물은 개인용 폴더에 모은다. Thariq는 스킬이 필요한 때와, 스크립트가 많이 쌓인 저장소를 작업 공간으로 삼아야 하는 때가 다르다고 말한다. 스킬은 그 작업 공간을 만드는 방법을 담은 지침이 될 수도 있다. 스크립트와 도구가 쌓일수록 에이전트가 처음부터 다시 만들어야 하는 일이 줄어든다. 그가 Peter에게 권하는 것은 영상 편집용 하네스, 곧 에이전트가 쓸 도구와 스크립트를 모아 둔 작업 환경을 만드는 일이다.
이 작업 환경에는 외부 도구도 들어간다. Peter는 이미지 생성 API에 웃는 얼굴을 놀란 표정으로 바꾸게 하면 얼굴이 매우 어색해지지만, 얼굴은 그대로 두고 배경과 글자만 바꾸는 일은 잘한다고 말한다. Thariq는 Claude가 다른 도구를 쓰는 데 능하다고 답한다. Gemini나 OpenAI의 이미지 생성 API를 Claude에게 주고, Claude가 생성된 얼굴을 직접 보고 조금씩 고치게 하면 결과를 점진적으로 다듬을 수 있다.
반론. 결과물을 꼼꼼히 읽지 않으면 저장소가 결국 슬롭으로 채워지지 않는가. Peter는 에이전트가 쉬지 않고 일하는데 자신은 그 결과를 모두 꼼꼼히 읽지 않는다며, 저장소를 주기적으로 정리하는 루틴이 있는지 묻는다. Thariq는 Boris가 내놓은 simplify처럼 저장소를 단순하게 만드는 기능이 있다고 답하면서도, 용도에 따라 다르다고 말한다. 영상처럼 출력물을 얻으려고 쓰는 작업이라면 코드 품질은 덜 중요할 수 있고, 에이전트는 끈질기게 방법을 찾아낸다. 출력물만 신경 쓰는 경우라면 폴더 정리는 에이전트를 위한 일이라기보다 작업 공간을 보는 사람의 마음을 편하게 하려는 일인 경우가 많고, 필요할 때 에이전트에게 단순화나 정리를 맡기면 된다.
워크플로의 핵심은 만드는 에이전트와 검증하는 에이전트를 나누는 것이다
Peter는 스킬은 이제 쓸 줄 알지만 워크플로는 전혀 모르겠다고 말한다. Thariq는 짧은 영상 여러 개를 만드는 일을 예로 든다. 주 에이전트가 긴 영상에서 짧은 영상으로 만들 다섯 구간을 고르면, 워크플로가 구간마다 하위 에이전트를 하나씩 띄운다. 좋은 클립이 무엇인지 정의한 평가표를 주면 각 에이전트가 그 기준으로 자기 결과를 확인한다. 이렇게 하면 클립마다 연산을 최대한 투입할 수 있다. 반대로 한 에이전트가 두세 개를 동시에 만들면 Claude가 개별 클립을 덜 검증하거나 덜 공들일 수 있다.
만드는 방법은 단순하다. 클립 10개를 만들되 워크플로를 사용하고, 좋은 클립의 기준은 이 평가표라고 요청하면 된다. 워크플로는 JS 파일이므로, 그 파일을 스킬 안에 함께 저장해 두면 다음에도 같은 워크플로를 다시 쓸 수 있다.
Peter는 워크플로가 스킬보다 나은 점이 하위 에이전트로 컨텍스트를 깨끗하게 유지하는 것이냐고 묻는다. Thariq는 컨텍스트도 한 가지 이유이지만, 다른 이유는 모델이 게으름을 피우는 문제와 검증이라고 답한다. 짧은 영상은 좋은지 나쁜지를 결정적으로 판별할 방법이 없다. 평가표를 읽고 영상을 검토해 피드백하는 검증 에이전트를 둘 수 있다는 점이 워크플로의 장점이다. Anthropic은 모델이 자기 출력물을 선호해 검증할 때 더 관대해지는 현상을 자기 참조 편향(self-referential bias)이라고 부른다. 그래서 작업을 조율하는 Claude, 작업을 하는 Claude, 검증하는 Claude를 나눈다. 셋은 서로 다른 컨텍스트에서 일하므로 편향이 줄고, 각자 더 많은 연산을 쓰며 일찍 멈출 가능성도 낮아진다.
병렬 작업은 Slack으로 보내고 사람은 한 프로젝트에만 깊게 관여한다
Thariq의 병렬 작업은 대부분 자막에서 cloud tag로 표기된, Slack에서 쓰는 Claude로 옮겨 갔다. 로컬에서 해야 할 이유가 없는 한 여러 Claude를 동시에 돌리는 일은 Slack에서 하고, 이를 위해 팀은 개발 환경이 원격에서도 돌아가게 만드는 데 많은 시간을 들였다. 초기 탐색, PR 스펙, 무언가를 이해하려는 작업이 Slack에서 진행된다. 병합하려는 PR이 있으면 Claude에게 PR을 지켜보며 테스트를 고치고 리뷰어를 태그하게 하고, 리뷰어는 같은 채널에서 Claude와 함께 이야기한다. 예전에는 Claude Code 세션 다섯 개를 띄웠다면, 지금은 활성 Claude Code 세션 하나와 여러 Slack 세션으로 일한다. 깊이 집중하는 한 가지 일만 Claude Code에서 주고받으며 반복한다.
사람의 집중력은 별개의 문제다. Peter는 다섯 가지 작업의 스레드가 동시에 진행되면서 계속 자신을 부르면 연속 회의보다 더 지친다고 털어놓는다. Thariq는 집중하는 프로젝트를 하나로 정한다고 답한다. 빌드와 병합처럼 막힌 것을 풀어야 하는 일이나 탐색은 따로 돌리지만, 깊이 생각하는 대상은 하나다. 그가 가장 많은 시간을 잃는 때는 조금 게을러진 상태로 여러 작업을 오가다가 대충 쓴 프롬프트를 보내고, 그 때문에 시간을 낭비했다는 것을 뒤늦게 알게 될 때다. 적절한 병렬 작업의 양은 사람과 일에 따라 다르지만, 그 자신은 가장 집중하는 일 하나를 둔다. 이것은 자신의 우선순위를 정하는 방법이기도 하다.
반론. 결국 에이전트는 Slack으로 일을 맡기는 또 한 명의 직원이 아닌가. Peter는 에이전트가 사람이 온보딩시키고 Slack이나 전화로 대화하는 또 한 명의 직원처럼 될 것이라고 본다. Thariq는 이런 비유가 도움이 될 때도 있지만 생각을 제한하기도 한다고 답한다. Slack의 Claude는 채널마다 자기 메모리를 갖는데, 이것은 하나의 설계 선택일 뿐이고 Slack 정체성이 서로 다른 여러 Claude를 태그하는 방식도 상상할 수 있다. 지속성과 메모리를 가진 에이전트로 생각하는 것은 도움이 되지만, 동료와는 다른 점이 있다. 그는 이것을 Claude Code가 발전한 형태로 보고, 정해진 틀에 넣기보다 모델이 어디로 이끄는지 지켜보려 한다. Claude가 사람보다 기억력이 낫다는 Peter의 말에는, 어떤 면에서는 낫고 어떤 면에서는 못하다며 능력이 고르지 않다고 답한다.
모델이 똑똑해질수록 금지와 예시를 줄이고 이유와 선호를 준다
Peter가 MCP를 많이 켜 두지 않고 CLAUDE.md를 길게 쓰지 않도록 컨텍스트를 관리하는지 묻자, Thariq는 Claude Code의 시스템 프롬프트를 80% 줄였다고 답한다. 모델이 똑똑해질수록 방향 제시와 제약과 예시가 덜 필요해졌기 때문이다. 예전 시스템 프롬프트는 어떤 도구를 설명하고, 사용 예를 다섯 개 들고, 이런 경우에는 절대 쓰지 말라는 식이었다. 이제 모델은 충분히 정렬되어 있어서 예시가 오히려 모델을 제약한다. 예시를 주면 모델은 그 예시와 비슷한 것을 원한다고 받아들이고, 예시를 빼면 더 자유로운 형식으로 답할 수 있다.
금지도 마찬가지다. 사람은 "절대 하지 마라"라고 쓰지만, 실제로는 "웬만하면 하지 마라"라는 뜻인 때가 많다. 하지 말아야 하는 이유를 알려 주는 편이 금지 문장보다 효과적일 수 있다. 그래서 그는 지금의 CLAUDE.md와 많은 스킬이 너무 길다고 보고 점점 더 줄이라고 권한다. MCP는 종류에 따라 다르며, MCP 팀이 도구 검색 같은 기능으로 컨텍스트 부담을 줄여 왔다.
트윗을 쓰게 할 때를 예로 들면, 금지 목록 대신 자신에 대한 맥락을 준다. 자신이 Anthropic에서 Claude Code를 만든다는 것과 따르는 원칙을 알려 준다. 280자 제한은 실제로 지켜야 하므로 여전히 좋은 제약이지만, 트윗이라고만 말해도 모델은 대체로 그 제약을 안다. 더 나아가 한 개의 트윗을 선호하지만 두 개짜리 스레드가 더 낫다면 그렇게 해도 된다고 선호를 말하면, 모델은 좋은 결과를 찾을 여지를 더 얻는다.
기술을 이해한다는 것은 문법이 아니라 시스템의 제약을 아는 것이고, 그 배움에는 수고가 든다
Peter는 Boris가 코딩은 해결된 문제라고 말하는 상황에서, 에이전트가 하는 일을 실제로 이해하려면 어떻게 기술 이해도를 더 높일 수 있는지 묻는다. Thariq는 첫 단계가 배우려는 동기를 스스로 만드는 일이라고 답한다. 일을 끝내는 데 필요하지 않으면 배우지 않게 되기 쉽고, 그 자신도 그렇다. 기술 이해도를 높이는 목표는 자신이 모르는 줄도 모르는 것을 아는 데 있다. TypeScript 문법을 아는 것은 별 도움이 되지 않는다. 백엔드 서비스마다 어떤 장단점이 있는지, 영상 처리 라이브러리들이 어떻게 다른지, 로컬 전사 라이브러리와 원격 전사 라이브러리가 어떻게 다른지를 아는 것이 도움이 된다. 그는 무엇이 가능하고, 지금은 어떻게 하고 있고, 얼마나 좋아질 수 있고, 다른 방식이면 어떨지를 묻는 방식으로 시스템의 제약을 배운다.
Claude는 이런 것을 함께 브레인스토밍하고 가르쳐 줄 수 있지만, 사람이 계속 캐물어야 한다. 무언가를 배우려 시도하는 것은 기분이 좋지만 실제로 배우는 일은 더 많은 노력이 들고, 일처럼 느껴져야 한다. Thariq는 Karpathy도 교육은 재미보다 일처럼 느껴져야 한다고 자주 말한다고 덧붙인다. 계획 단계에서 그가 지적한 실패 양상도 같은 문제다. 사람들은 AI가 쓴 긴 계획과 설명 문서를 대충 훑고 넘어가고, 프롬프트 창은 그냥 해 달라고 누르는 "게으름 버튼"이 되기 쉽다. 진지한 작업에서 매 단계 쉬운 길을 택하면 결국 더 오래 걸린다. 그가 보여 준 계획 문서는 front-end design 플러그인으로 보기 좋게 만든 것이지만, 그는 문서의 디자인보다 사람이 실제로 읽는 문서인지가 중요하다고 말한다.
반론. Claude에게 계속 시키고 결과만 보는 편이 훨씬 쉬운데, 보고서를 만들어 읽는 사람이 얼마나 되는가. Peter는 영상 작업만 해도 Claude에게 계속 시키고 결과만 보면 아무것도 배우지 않아도 되며, Thariq처럼 자세한 HTML 보고서를 만들어 읽는 사람은 예외일 것이라고 말한다. Thariq는 그것이 자신이 사람들에게 권하려는 방식이라고 답하고, Peter에게 질문을 돌려준다. 좋은 짧은 영상에서 제작 품질이 가장 높은 짧은 영상으로 가는 것이 목표라면, 영상 제작과 편집과 기술 개념을 더 배워야 한다. 그는 모두가 더 빠르게만이 아니라 더 낫고 빠르게 나아가기를 원한다고 말한다. Peter가 모든 작업에 HTML 보고서를 만들라는 지침을 넣겠다고 하자, Thariq는 무언가의 작동 방식을 언제 이해하고 싶은지 스스로 가려내려고 노력해야 한다고 답한다.
대담에서 확인되지 않은 채 남은 것도 있다. 손으로 가리킨 위치에 오버레이를 놓는 문제는 Thariq 자신도 만족하지 못했고, 손가락이나 얼굴을 추적해 에이전트에게 메타데이터를 주는 방법은 아이디어로만 언급되었다. 피사체 뒤에 글자를 넣기 위한 영상 분할에서는 쓸 만큼 안정적인 방법을 찾지 못했다. Peter의 블로그를 참고한 디자인 시안은 그의 브랜드를 제대로 반영하지 못했고, 시안을 다듬는 과정은 대담에 나오지 않는다. 워크플로로 만든 짧은 영상이 Peter의 기존 스킬보다 나은지도 시연되지 않았다. Slack에서 스킬을 부르는 방법은 스킬을 쓰라고 말하는 수준이고 사용 경험은 아직 개선 중이다. 대담 시점에 Teams와 Enterprise 요금제에서만 쓸 수 있던 아티팩트가 Max와 Pro 요금제에 언제 제공될지도 정해지지 않았다.
Deep Dive
2026-07-20
스킬은 행동을, 작업 공간은 축적된 성과를 재사용한다
스킬은 작업 순서, 판단 기준, 도구 사용법처럼 되풀이할 방법을 담는다. 작업 공간은 작업 이력뿐 아니라 검증된 스크립트, 자료, 중간 결과와 현재 상태를 축적한다. 스킬이 "어떻게 일할 것인가"를 알려준다면 작업 공간은 "지금까지 무엇을 만들어 두었는가"를 알려준다.
그러나 기존 결과물이 다음 작업에 자동으로 도움이 되는 것은 아니다. 에이전트가 결과물을 찾고, 읽고, 믿을 수 있어야 한다. 따라서 작업 공간을 관리한다는 것은 모든 파일을 보존하는 일이 아니다. 다시 쓸 자산과 판단 기록은 기준으로 승격하고, 일회성 결과는 분리하며, 실패한 임시 파일과 오래된 설정은 폐기하는 일이다. 작업 공간은 결과물을 쌓는 곳이 아니라 검증된 결과물을 다음 작업의 입력으로 바꾸는 곳이다.
코드 정리는 미래의 기본 선택을 관리한다
코드는 실행되는 결과물이면서 다음 코드를 만드는 개발자와 에이전트가 참고하는 지침이다. AI는 기존 코드에서 비슷한 구현을 찾아 새 코드를 만든다. 임시 구현과 중복된 방식이 남아 있으면 AI는 그것을 정상적인 예시로 받아들이고 반복한다. 그러면 과거의 임시 선택이 우리가 원하지 않는 방향으로 확대된다.
따라서 코드 정리는 과거 코드를 보기 좋게 만드는 일이 아니다. 다음 구현이 따라야 할 기준을 분명하게 만드는 일이다. 중복 로직을 하나의 기준 구현으로 합치고, 쓰지 않는 코드를 제거하고, 올바른 사용법을 테스트로 고정해야 한다. 코드가 다음 구현을 잘못 이끌기 시작할 때 정리하면 기술 부채가 복제되는 것을 막을 수 있다.
짧은 지침은 깊은 이해의 결과다
모델이 똑똑해질수록 사용자는 모든 행동을 미리 지시할 필요가 줄어든다. 많은 예시와 절대 규칙은 모델의 선택지를 좁히고, 실제 문제를 검토하는 데 쓸 문맥을 차지할 수 있다. 좋은 지침은 목표, 맥락, 반드시 지킬 조건, 품질 기준과 자율 범위를 분명하게 남긴다.
그렇다고 사람이 덜 배워도 되는 것은 아니다. AI가 구현 방법을 고를 수 있어도 사람은 무엇이 옳은지, 어떤 위험을 허용할지, 결과가 충분히 좋은지 판단해야 한다. 깊이 이해한 사람만 반드시 제한할 부분과 AI에게 맡길 부분을 나눌 수 있다. 짧은 지침은 대충 쓴 지침이 아니라 중요하지 않은 지시를 덜어낸 결과다.
Key Insight
에이전트와 오래 일하려면 스킬로 행동을 재사용하고 작업 공간에서 검증된 성과를 다음 입력으로 승격해야 한다. 사람은 코드와 작업 공간을 정리해 잘못된 과거가 반복되지 않게 하고, 깊이 이해한 뒤 모델에 짧고 정확한 목표와 기준을 줘야 한다.