세션이 끝날 때마다 AI는 모든 걸 잊습니다. 어제 함께 작업한 코드도, 내가 선호하는 방식도, 프로젝트 맥락도 전부요. 그렇다면 매번 처음부터 다시 설명해야 할까요? Anthropic 엔지니어 Eugene Yan은 다르게 접근합니다.

Eugene Yan은 아마존·알리바바 등에서 ML 팀을 이끌었고 현재 Anthropic에 재직 중인 엔지니어입니다. 그가 최근 자신의 블로그에 AI와 일하는 방식을 정리한 글을 올렸습니다. 요점은 하나입니다. AI를 도구가 아니라 신입 동료를 온보딩하듯 설계하면, 매 세션의 결과물이 다음 세션의 발판이 되어 복리처럼 쌓인다는 것입니다.
출처: How to Work and Compound with AI – eugeneyan.com
컨텍스트를 인프라처럼 구조화한다
AI는 세션마다 빈 슬레이트로 시작합니다. 그래서 그는 프로젝트 디렉토리에 CLAUDE.md를 둡니다. 신입 사원에게 건네는 온보딩 문서처럼요. 용어집, 프로젝트 코드명, 중복되는 팀원 이름 해소 같은 내용이 여기 들어갑니다.
한 발 더 나아가 프로젝트마다 INDEX.md를 만들어 관련 문서와 채널을 주석과 함께 정리합니다. URL만 나열하면 모델이 모든 링크를 열어봐야 하는데, 각 항목에 “언제 읽어야 하는지”를 적어두면 그 수고를 한 번으로 줄일 수 있습니다.
취향을 설정으로 굳힌다
그는 ~/.claude/CLAUDE.md를 일종의 행동 계약서로 씁니다. “불확실할 땐 추측 대신 모른다고 말해라”, “실패하면 재시도 전에 근본 원인을 먼저 파악해라” 같은 선호가 담깁니다. 이 파일은 매 세션 시작 시 자동으로 로드됩니다.
반복 작업은 스킬로 만듭니다. 스킬이란 이름·트리거·절차를 담은 마크다운 파일로, 모델이 필요할 때 불러옵니다. 예를 들어 /polish 스킬은 코드를 검토하고, 결과물의 성격에 따라 eval을 돌리거나 브라우저로 확인하거나 실행 후 오류를 읽는 흐름을 스스로 판단해 처리합니다. 단계만 적힌 게 아니라 어떤 단계를 적용할지에 대한 판단도 인코딩된 셈입니다.
스킬을 만드는 방법도 현실적입니다. 한 번 직접 해보고, 모델에게 “우리가 방금 한 걸 스킬로 만들어달라”고 한 다음, 피드백을 세션 안에서 바로 제공하면 transcript에 수정 이유가 쌓입니다. 그 transcript를 기반으로 스킬을 업데이트하길 몇 번 반복하면 출력물이 수렴합니다.
검증을 앞당기고 모델 스스로 확인하게 한다
그는 검증을 사다리로 봅니다. 아래는 저렴하고 결정론적인 것, 위로 갈수록 비용이 크고 판단이 필요한 것입니다. 목표는 문제를 가능한 낮은 단계에서 잡는 것입니다.
실용적인 방법으로는, 시스템이 지표를 생성하면 모델이 직접 eval을 돌려 최적화하게 하고, 브라우저에서 렌더링되면 Claude in Chrome으로 결과를 확인하게 합니다. Docker 이미지를 빌드할 때도 모델이 직접 빌드하고 오류를 읽고 수정하고 다시 빌드하는 루프를 돌립니다. 검증 루프를 모델에게 주면 사람이 중간에 개입하는 횟수가 줄어듭니다.
장시간 세션에서는 “모델이 모델을 감시”하는 구조도 씁니다. 1차 세션이 작업하는 동안 별도의 2차 세션이 원본 스펙과 최근 turns를 비교해 방향이 틀어지면 피드백을 줍니다. 이를 두 가지로 나눕니다. 실행 드리프트(작업을 올바르게 하고 있는가)는 자주 체크하고, 방향 드리프트(올바른 작업을 하고 있는가)는 가끔 체크합니다.
점점 더 큰 단위로 위임한다
초기에는 모델과 페어 프로그래밍, 즉 짧은 작업에 빠른 피드백을 주고받는 방식을 씁니다. 모델이 강해질수록 더 큰 덩어리를 위임합니다. 의도·제약·성공 기준을 미리 설명하고 실행을 맡기는 식입니다.
그는 현재 동시에 3~6개 세션을 병렬로 돌립니다. 병목은 이미 작업 실행이 아닙니다. 명세를 잘 쓰고 결과물을 빠르게 리뷰해 파이프라인을 막히지 않게 하는 것이 진짜 병목입니다.
루프를 닫아 다음 세션을 더 낫게 만든다
과거 세션 transcript를 AI에게 읽히면 설정의 빈틈을 찾을 수 있습니다. 그는 자신의 2,500개 user turn을 스캔했을 때 상당수에 “확인했어요?”, “아직 틀렸는데요” 같은 표현이 있었다고 말합니다. 이는 모델이 자동으로 했어야 할 일을 사람이 재요청한 흔적입니다. 이 패턴이 CLAUDE.md나 스킬 업데이트의 재료가 됩니다.
수정은 반드시 세션 안에서 합니다. 그래야 transcript에 “이렇게 했고, 이렇게 원했고, 이유는 이것”이 쌓여 다음 업데이트 때 쓸 수 있습니다.
“AI를 훈련시키는 것”이 아닌 협력자를 키우는 것
그는 글 말미에 이렇게 씁니다. “우리가 하는 것은 협력자를 훈련시키는 것이다, 한 번의 피드백씩.” 그리고 이 원칙들이 AI에만 해당하는 게 아니라 인간 팀과 일하는 방식과도 다르지 않다고 말합니다.
세션마다 백지에서 시작하는 제약이 오히려 시스템을 정리하는 계기가 됩니다. 어떤 맥락을 보존할지, 어떤 취향을 설정으로 굳힐지, 어떤 작업을 스킬로 만들지를 생각하게 만들기 때문입니다. 그 결과물이 매 세션마다 조금씩 더 나은 출발점이 됩니다.
구체적인 설정 구조와 스킬 예시가 궁금하다면 원문을 읽어보세요. SETUP.txt도 함께 제공되어 있습니다.

답글 남기기