By d9ng in ai — 19 5월 2026

AI와 함께 일하고, 그 결과를 쌓아가는 법

원문: How to Work and Compound with AI by Eugene Yan (2026년 5월 3일)
번역: blog.d9ng.co.kr - 저자의 허락을 받아 번역했습니다.

Eugene Yan은 현재 Anthropic의 Member of Technical Staff로 현장과 최신 연구를 연결하는 일을 합니다. 그 전에는 Amazon에서 Principal Applied Scientist로 Kindle의 책 시리즈 요약, 번역, Q&A 같은 LLM/AI 시스템을 만들었고, Alibaba/Lazada에서 동남아 이커머스의 ML을 리드했습니다. 개인 블로그 eugeneyan.com에 LLM, 추천 시스템, 엔지니어링에 대한 글을 꾸준히 쓰고 있고, applyingml.com과 applied-llms.org도 운영합니다.

AI와 어떻게 하면 효과적으로 일할 수 있을까요? 워크플로(workflow)는 무엇이고, 어떻게 스케일(scale)하며, 시간이 지나면서 시스템을 어떻게 개선할까요? 그리고 이상적으로는 작업이 누적되어야(compound) 합니다. 완성한 산출물(artifact)인 코드, 문서, 분석, 의사결정 모두가 다음 세션의 컨텍스트(context)가 되어야 하고, 매 수정 사항이 미래의 오류를 줄여줄 설정(config)으로 반영되어야 합니다. 저도 아직 배우는 중이지만, 같은 답을 너무 자주 반복하다 보니 다음에 누가 물어보면 링크 하나로 답할 수 있게 여기 정리해둡니다.

AI를 자주 쓰시는 분이라면 이미 많은 부분을 적용하고 계실 겁니다. 그래도 밑바닥 원칙은 폭넓게 적용된다고 봅니다. 좋은 컨텍스트를 제공하고, 본인의 취향(taste)을 설정으로 인코딩하고, 검증(verification)을 쉽게 만들고, 더 큰 작업을 위임하고, 루프(loop)를 닫는 것입니다. 어떤 방식이 본인에게 안 맞으면 원칙을 가져다 본인 식대로 새로 만들면 됩니다. 그리고 읽으시면서 알게 되겠지만, 이 모든 것이 AI에만 해당하는 얘기는 아닙니다. 그냥 새로운 협업자(collaborator)와 일하면서 그 사람을 안내하는 방법일 뿐입니다.

컨텍스트는 인프라다 (Context as infrastructure)

모델 사용자의 컨텍스트를 잘 찾아다닐 수 있게 도와주세요.

예를 들어 제 코드는 전부 ~/src에 있고, 지식 작업은 전부 ~/vault에 있습니다 (projects/, notes/, kb/ 같은 식으로 분류해서요). 작업이 정리되어 있으면 모델이 grep이나 glob으로 컨텍스트를 찾기가 쉽습니다. 디렉토리 트리가 깨끗하면 탐색하기도 좋고, 이전 코드나 프로젝트 문서, 분석을 찾아서 지금 작업에 활용하기도 직관적입니다.

조직의 컨텍스트에 모델을 연결하세요.

모델은 조직 안의 지식을 활용할 수 있는데, 그 지식은 보통 Slack, Drive, Mail 같은 곳에 흩어져 있습니다. 대부분 Claude Code, Cowork, Claude.ai용 MCP가 마련되어 있습니다. 그 위에 저는 프로젝트별로 INDEX.md를 따로 관리합니다. 관련 문서와 채널을 주석과 함께 정리한 인덱스인데, 각 항목에는 URL, 담당자(owner), 그리고 안에 뭐가 들어 있고 언제 봐야 하는지 설명하는 짧은 문단이 들어갑니다. 이 주석이 크게 도움이 됩니다. URL만 나열되어 있으면 모델이 매번 모든 링크를 열어서 뭐가 관련 있는지 확인해야 해서 시간과 컨텍스트가 낭비됩니다. 미리 주석을 달아두면 이 무거운 작업을 한 번만 하고 인덱스에 저장해두는 셈입니다.

새 세션은 매번 신규 입사자에게 안내하듯이 시작하세요.

새 세션이 시작될 때마다 모델은 아무 정보 없이 출발합니다. 그래서 프로젝트별 CLAUDE.md를 새 팀원이 첫날 받는 온보딩 문서처럼 다루면 좋습니다. Claude한테 제 프로젝트별 CLAUDE.md 파일들을 훑어보게 했더니 약어 용어집, 프로젝트 코드명, 이름이 같은 팀원 구분 같은 내용이 들어 있다는 점을 짚어줬습니다. 저는 CLAUDE.md에 추천 읽기 순서도 넣어둡니다. 모델한테 먼저 INDEX.md를 훑고, 그다음 TODOS.md, 마지막으로 특정 주제 노트를 보라고 알려주는 식입니다.

메모리 레이어(memory layer)를 만드세요.

기본적으로 모델은 지난 세션에서 뭐가 있었는지 기억하지 못합니다. 그래서 보존할 가치가 있는 건 디스크에 써둬야 합니다. 저는 메모리 레이어를 두 갈래로 나눕니다. ~/vault에는 프로젝트 상태, 산출물, 도메인 지식 같은 사실(fact)을 두고, ~/.claude에는 (CLAUDE.md, skills/, guides/와 함께) 제 선호(preferences), 워크플로, 개인 취향을 둡니다. 전자는 컨텍스트를 제공하고, 후자는 설정을 제공합니다.

취향은 설정이다 (Taste as configuration)

~/.claude/CLAUDE.md부터 시작하세요.

Claude는 매 세션 시작마다 이 파일을 읽습니다. 저는 이걸 어떻게 행동할지 정해둔 규약이라고 생각합니다. 제 CLAUDE.md에는 얼마나 직설적이어야 하는지, 언제 반박해야 하는지, 실수를 어떻게 다뤄야 하는지, 저에게 뭘 가르쳐야 하는지 같은 선호하는 사항이 들어 있습니다. 간단히 줄인 버전입니다:

<behavior>
- 직설적으로 말하고, 동의하지 않으면 밀어붙일 것. 내 접근에 문제가 있으면 그렇다고 말할 것.
- 뭔가 확신이 안 서면, 확신 있는 척 추측하지 말고 모르겠다고 말할 것.
- 뭔가 실패하면, 다시 시도하기 전에 근본 원인을 조사할 것.
- diff는 작업 범위에 한정할 것. 지나가다 포맷팅 고치거나 무관한 리팩터링하지 말 것.
...
</behavior>

<teaching>
나는 항상 새로운 시스템과 도메인을 배우고 있다. 내가 아직 익숙하지 않을 가능성이
높은 핵심 용어가 나오면, 1~2 문장으로 설명하고 넘어갈 것. 형식:

> 💡 1~2 문장 설명

...
</teaching>

범위는 디렉토리별로 잡으세요. 전역(global), 그다음 레포(repo), 그다음 프로젝트(project).

어디서나 적용되는 사항(예: 행동, 장기 목표, 가르침)은 ~/.claude/CLAUDE.md에 둡니다. 특정 레포의 관례(예: 린팅, 네이밍, PR)는 레포 루트에 둡니다. 프로젝트별 컨텍스트(예: 디렉토리 구조, 도메인 지식)는 프로젝트 디렉토리에 둡니다. 하위 디렉토리에서 Claude Code를 시작하면 트리를 거슬러 올라가면서 각 CLAUDE.md를 로드합니다. 세션 중에 모델이 하위 디렉토리로 들어가면 그 디렉토리의 CLAUDE.md도 가져옵니다. 자세한 건 공식 문서에서 확인하세요.

CLAUDE.md가 너무 길어지면 분리하세요.

긴 CLAUDE.md는 컨텍스트 세금(context tax)이 될 수 있습니다. 세션에 필요 없는 내용까지 매번 로드되니까요. 해결책은 일부 청크(chunk)를 가이드(guide)로 빼서 지연 로드(lazy load)되게 만드는 겁니다. @import는 쓰지 마세요 (그러면 그냥 인라인됩니다). 대신 CLAUDE.md에서 관련 있을 때 읽으라고 알려주세요. 이렇게 하면 eval(평가) 만드는 세션에서는 문서 작성 가이드를 건너뜁니다. 가이드 섹션 예시:

<guides>
- 문서, 1-페이저, 모든 글쓰기: ~/.claude/guides/writing.md
- Eval 구축 및 리포트: ~/.claude/guides/evals.md
- 대시보드: ~/.claude/guides/dashboards.md
...
</guides>

주 1회 이상 반복하는 작업이면 스킬(skill)로 만드세요.

스킬은 이름, 트리거(trigger), 절차(procedure)가 들어 있는 마크다운(markdown) 파일로, 모델이 필요할 때 로드합니다. 스킬을 마크다운으로 쓴 워크플로라고 보시면 됩니다. 로직도 포함할 수 있습니다. 예를 들어 제 /polish 스킬은 산출물의 diff를 봅니다. 메트릭(metric)을 생산하는 거면 관련 eval을 돌리고, 브라우저에서 렌더링되는 거면 Claude in Chrome으로 출력을 확인하고, 둘 다 아니면 코드를 실행해서 출력이나 에러를 읽습니다. 스킬은 각 단계와, 어떤 단계가 언제 적용되는지의 판단을 함께 인코딩합니다. 몇 가지 예시:

/polish: 버그 확인, 코드 단순화, 출력 검증 (eval, Claude in Chrome 등으로), 비판적 피드백이 없을 때까지 반복, PR 초안 작성
/write: 개요를 위해 인터뷰, 리서치 서브에이전트(subagent)를 띄움, 초안 작성, 적대적 비평가(adversarial critic)로 피드백, 비판적 피드백이 없을 때까지 반복
/daily: 캘린더, Slack, PR, 어제의 로그 등을 읽고 오늘의 우선순위를 작성

저는 SKILL.md를 작고 워크플로와 라우팅(routing)에 집중해서 짧게 유지합니다. 지식(템플릿, 스크립트 등)은 별도 파일로 두고, 모델이 필요할 때만 읽고 실행합니다. 지연 로드 가이드와 같은 원리입니다.

스킬은 한 번 직접 해본 다음, 모델한테 스킬로 만들어달라고 부탁해서 만드세요.

저는 대부분의 스킬을 이렇게 만듭니다. 먼저 일반 세션에서 작업을 한 번 직접 해봅니다. 그다음 모델한테 방금 한 걸 스킬로 만들어달라고 합니다. 다음번에 같거나 비슷한 작업에 그 스킬을 돌립니다. 결과를 고쳐야 할 일이 분명 생기는데, 같은 세션 안에서 고칩니다. 그래야 피드백이 세션 트랜스크립트(transcript)에 기록됩니다. 마지막으로 모델한테 그 수정과 피드백을 바탕으로 스킬을 업데이트하라고 합니다. 원하는 출력의 예시로 스킬을 시드(seed)할 수도 있습니다. 모델한테 패턴을 추출하라고 시키면 됩니다. 예를 들어 코드를 어떻게 정리하는지, 문서의 구조와 톤은 어떤지 같은 것을요.

스킬은 파일을 직접 고치지 말고 트랜스크립트(transcript)로 다듬으세요.

스킬의 첫 버전은 원래 세션에만 맞춰져 있어서 잘 작동하지 않는 게 정상입니다. 돌려보고 출력을 고쳐야 할 때, 그 수정을 세션 안에서 하세요. SKILL.md를 직접 열어서 편집하지 마세요. 세션 안에서 피드백을 주면 모델이 before/after 쌍을 얻게 되고, 그게 트랜스크립트에 누적됩니다. 우리가 뭘 했고, 내가 뭘 원했고, 왜 그랬는지의 기록이 쌓이는 것입니다. 출력이 맞게 나오면 그제서야 모델한테 피드백을 스킬에 머지(merge)해달라고 하면 됩니다. 몇 라운드 거치면 스킬이 수렴하고, 최종 출력을 거의 손볼 필요가 없어집니다.

하지만 모든 작업에 이런 컨텍스트가 필요한 건 아닙니다.

브레인스토밍, 탐색, 거친 초안 작업에서는 심플 모드(simple mode, CLAUDE_CODE_SIMPLE=1 claude)를 즐겨 씁니다. 여기서는 CLAUDE.md는 여전히 로드되지만 에이전트 하네스(agentic harness, 훅과 스킬, 도구 위주 루프)는 작동하지 않습니다. 이러면 모델에 더 가까이 다가갈 수 있고, 출시할 때가 아니라 소리내어 생각할 때 원하는 게 바로 이런 거죠.

검증으로 자율성을 확보하라 (Verification for autonomy)

검증을 왼쪽으로 옮기세요. 에러는 작성 시점에 잡으세요.

저는 검증을 사다리(ladder)로 생각합니다. 맨 밑은 싸고 결정적(deterministic)이고, 맨 위는 비싸고 판단이 필요합니다. 가능한 한 가장 낮은 단(rung)에서 문제를 잡고 싶습니다. 사다리 밑쪽에는 모델이 방금 업데이트한 파일에 ruff format, ruff check --fix를 돌리는 post-edit 훅 같은 게 있습니다. 결정적으로 작동하고 토큰도 안 씁니다. 사다리 위쪽에는 테스트, eval, LLM 리뷰 같은 게 있습니다.

모델이 자기 작업을 검증하기 쉽게 만드세요.

모델한테 출력을 개선할 피드백 루프를 주세요. 시스템이 메트릭을 만들면 모델이 eval을 돌려서 최적화하게 하세요. 출력이 브라우저에서 렌더링되면 Claude in Chrome으로 검사하게 하세요. 둘 다 아니면 그냥 돌려서 에러를 읽게 하세요. 예를 들어 Docker 이미지를 만들 때, 저는 모델이 빌드하고, 에러를 읽고, Dockerfile을 고치고, 다시 빌드하게 둡니다. 하니스를 튜닝할 때는 모델이 eval을 돌리고, 트랜스크립트를 읽고, 실패를 고칩니다. 대시보드를 만들 때는 Chrome에서 모델이 툴팁(tooltip)이 렌더링되는지, 라벨이 겹치지 않는지, 내러티브가 숫자와 맞는지 확인합니다.

오래 걸리는 작업은 모델이 모델을 감시하게 하세요.

긴 세션은 에러가 쌓이면서 드리프트(drift, 본래 의도에서 벗어남)될 수 있습니다. 한 가지 해결책은 보조 세션을 띄워서 원본 스펙과 기본 세션의 최근 턴(turn)을 새 컨텍스트로 읽게 하는 겁니다. 제 최소 셋업은 tmux 패널 두 개를 씁니다. 하나는 기본 개발용, 다른 하나는 페어 프로그래머(pair programmer)용. 초기 지시와 후속 프롬프트는 공유 파일에 추가됩니다. 주기적으로 페어 프로그래머가 켜져서, 기본 세션의 최근 트랜스크립트를 스펙과 대조해보고, 뭔가 어긋나면 코스를 바로잡을 피드백을 줍니다.

방법은 여러 가지가 있습니다. 예를 들어 페어 프로그래머가 실행 드리프트(execution drift)를 감시할 수 있습니다. 모델이 작업을 제대로 하고 있는가? 이건 국지적이고 전술적인 영역으로, 에러를 무시한다거나, 잘못된 메트릭을 보고한다거나, 스펙에서 벗어나는 경우입니다. 그리고 방향 드리프트(direction drift)도 있습니다. 모델이 옳은 작업을 하고 있는가? 이건 더 큰 그림이고 전략적이며, 모델이 원래 의도를 잘못 해석하고 몇 시간을 잘못된 걸 만드는 데 쓰는 경우입니다. 실행 드리프트는 자주, 방향 드리프트는 가끔씩 확인하세요.

위임을 통한 확장 (Scaling via delegation)

점점 더 큰 작업 단위를 위임하세요.

어떤 때는 모델과 페어 프로그래밍(pair programming)을 합니다. 짧은 작업, 빠른 피드백, 루프 안에 머무르는 식으로요. 빠른 반복, 탐색적 분석, 프로토타이핑에는 잘 맞습니다. 하지만 모델이 점점 강해지면서, 우리는 더 큰 작업을 위임하는 쪽을 노려야 합니다. 의도, 제약, 성공 기준을 앞에서 설명하고 모델이 일하게 두세요. 검증할 수 없는 건 위임할 수 없으니, 먼저 성공 기준과 메트릭을 정의해야 합니다. 변화는 지시를 한 번에 하나씩 주는 것에서, 계획을 잘 짜고 모델이 끝까지 실행하게 하는 쪽으로 옮겨갑니다:

"이 eval 스위트(suite)들이 있을 때, 스위트별로 격리된 컨테이너를 만들고 각각 빌드되는지 스모크 테스트(smoke test)를 해. 그다음 풀 런(full run)을 돌리고, eval 메트릭과 트랜스크립트를 로그로 남기고, 서브에이전트로 트랜스크립트를 읽어서 eval이 제대로 돌았는지 확인해. 각 eval을 n번 돌려서 신뢰 구간(confidence interval)을 뽑아. 마지막으로 리포트를 생성하고, 리포트 가이드를 따랐는지 검증하고, 결과랑 리포트 URL을 Slack으로 보내."

세션을 병렬로 돌리고 병목(bottleneck)을 찾으세요.

더 큰 작업을 위임하면 동시에 더 많이 돌릴 수 있습니다. Claude 말로는 저는 보통 3~6개 세션을 동시에 돌린답니다. 병목은 일을 하는 것에서, 명확한 스펙을 쓰고 출력을 빠르게 리뷰해서 파이프라인을 계속 굴리는 쪽으로 옮겨갔습니다. 중간 단계가 사라지고 있는 셈입니다. 병렬 세션이 같은 레포를 공유하면 git worktree를 써서 각 세션이 자기 체크아웃을 갖게 하고, 서로 덮어쓰지 않게 하세요.

세션을 관찰하기 쉽게 만드세요.

여러 세션을 돌릴 때는 각각의 상태와 어떤 세션이 주의를 필요로 하는지 알아야 합니다. 제 맥에서는 세션이 끝나면 stop 훅이 소리를 냅니다 (아래 예시). tmux 윈도우 타이틀에는 상태 이모지(⏳ 작업 중, 🟢 완료)와 Haiku가 생성한 짧은 라벨이 붙어서 각 패널이 뭘 하는지 알 수 있게 합니다. Claude Code의 상태 라인은 컨텍스트 사용량과 현재 모드를 보여줍니다. 함께 보면, stop 훅 소리는 작업이 끝났다는 신호이고, tmux 타이틀은 어느 작업인지 알려주고, 상태 라인은 세부 사항을 줍니다.

# Stop 훅 알람 예시
"Stop": [
    {
    "hooks": [
        {
        "type": "command",
        "command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi"
        }
    ]
}

자리에 없어도 체크인할 수 있습니다.

Claude Code의 /remote-control이 이걸 쉽게 해줍니다. 출퇴근 중이거나 줄 서 있을 때 Claude 앱의 코드 탭을 열어서 뭐가 돌고 있고 뭐가 막혀 있는지 확인하고, 필요하면 멈춰 있는 세션을 추가 컨텍스트나 새 지시로 풀어줍니다. 이렇게 하면 세션이 몇 시간씩 idle 상태로 있지 않고 계속 진행됩니다. 다만 정말 급할 때만 하세요. 현재에 머무르거나 잠시 바깥 공기 쐴 때는 말고요.

루프를 닫아라 (Closing the loop)

열린 환경에서 일해서 컨텍스트를 풍부하게 유지하세요.

작업을 공유 문서, 레포, 채널에서 하면, 모델을 포함한 모두가 컨텍스트를 가져다 쓰기 쉬워집니다. 오늘 공유하는 게 내일의 조직 컨텍스트가 됩니다. 간단한 테스트를 해보세요. 새 팀원이 공유된 컨텍스트만으로 지난주에 본인이 한 일을 재현할 수 있는가? 그렇다면 조직 컨텍스트에 잘 기여하고 있는 겁니다. 그렇지 않다면 그 귀한 컨텍스트가 본인 머릿속에만 갇혀 있다는 뜻입니다. 저는 이걸 CLAUDE.md의 지시로 어느 정도 자동화합니다. 의미 있는 작업이 끝날 때마다 worklog 채널에 짧은 업데이트를 올리고, 산출물 PR이나 문서 링크를 같이 붙입니다.

트랜스크립트를 마이닝해서 설정을 업데이트하세요.

모델한테 과거 세션 트랜스크립트를 읽어서 빈틈을 찾아달라고 하세요. 제가 과거 사용자 턴 약 2,500개를 스캔했더니 상당 비율이 "또 ~도 해줄 수 있어?", "~확인했어?", "아직 틀렸어" 같은 표현을 포함하고 있었습니다. 이런 표현은 모델이 시키지 않아도 했어야 할 일이 있다는 뜻이고, 제가 CLAUDE.md나 스킬을 업데이트해야 하거나, 검증 단계가 빠졌거나 깨져 있다는 신호입니다. 빈도(hit count)는 수정이 얼마나 자주 일어나는지 보여주고, 트랜스크립트는 정확히 뭐가 실패했는지 보여줍니다. 그래서 저는 수정을 세션 안에서 합니다. 그래야 트랜스크립트를 다음번 CLAUDE.md나 스킬 업데이트의 입력으로 쓸 수 있으니까요.

주기적으로 리팩터링하고 브랜치를 나누세요.

설정이 커지면 서로 겹치거나 충돌할 수 있습니다. 결과적으로 모델이 어떤 규칙을 무시한다면 다른 규칙이 그것과 모순되기 때문일 수 있습니다. 주기적으로 리팩터링해서 고치세요. 각 규칙이나 선호는 정확히 한 곳에만 있어야 합니다 (중요한 지시는 메인 CLAUDE.md에 반복해도 됩니다). 디렉토리 단위로 흩어진 settings.json이 있는지도 확인하고, ~/.claude로 통합해두세요.

구체적인 셋업은 모델이 좋아지면서 분명 바뀌겠지만, 원칙은 여전히 유효할 거라고 봅니다. 좋은 컨텍스트를 제공하고, 본인의 취향을 인코딩하고, 검증비용을 줄이고, 더 많이 위임하고, 루프를 닫는 것입니다. 우리가 하고 있는 건 한 번에 한 피드백씩 협업자를 훈련시키는 일입니다. 생각해보면 이 원칙들은 인간 팀과 일하는 방식에도 그대로 적용됩니다.

시작하시려면 모델한테 이 SETUP.txt를 읽고 적용해달라고 하세요. 그리고 본인이 쓸 만하다고 느낀 실천이나 원칙이 있다면 댓글이나 연락 주세요.

p.s. 이건 단지 개인 도구 얘기가 아닙니다. 에이전트 하니스를 어떻게 설계하고, 팀 규범을 어떻게 잡고, 조직 인프라를 어떻게 구축할지에도 적용됩니다. 그런 레이어로 한 번 더 읽어보세요.

원문이 유용하셨다면 다음과 같이 인용해주세요:

Yan, Ziyou. (May 2026). How to Work and Compound with AI. eugeneyan.com.
https://eugeneyan.com/writing/working-with-ai/.

또는:

@article{yan2026default,
  title   = {How to Work and Compound with AI},
  author  = {Yan, Ziyou},
  journal = {eugeneyan.com},
  year    = {2026},
  month   = {May},
  url     = {https://eugeneyan.com/writing/working-with-ai/}
}

이 글은 Eugene Yan의 How to Work and Compound with AI (2026년 5월 3일) 한국어 번역입니다. 저자의 허락을 받아 개인블로그와 blog.d9ng.co.kr 및 다모앙에 게재합니다. 저작권은 원저자에게 있습니다.