자동화·워크트리·스킬 — 기동 장치, 작업 분리, 프로젝트 지식

앞 글 언제 써야 하나 — 구성 요소는 5개 + 기억에서 루프의 구성 요소 여섯 개를 한눈에 봤다. 이 글부터는 그 요소를 하나씩 뜯어본다. 여기서는 앞의 셋, 루프를 기동하는 자동화, 병행 작업을 나누는 워크트리, 프로젝트 지식을 적어 두는 스킬을 다룬다. 나머지 셋은 다음 글 커넥터·서브에이전트·기억 — 검증력, 생성과 검증의 분리, 디스크에서 이어진다.

① 자동화 ── 기동 장치와 정지 조건을 세트로 정한다

자동화는 루프의 기동 장치

자동화는 루프의 기동 장치다. 사람이 매번 손으로 띄우는 게 아니라 스케줄(매일 아침·매시·특정 이벤트 발생 시 등)에 맞춰 자동으로 움직이기 시작해서 상황을 발견하고 트리아지(분류·우선순위 부여)한다.

절대 빠뜨리면 안 되는 정지 조건

절대 빠뜨리면 안 되는 게 완료 조건, 곧 정지 조건의 정의다.

자동으로 기동한다는 건 내버려 두면 하염없이 계속 돌 수도 있다는 말이기도 하다. '어떻게 되면 한 바퀴를 마치는가', '어디까지 하면 멈추는가'를 명시하지 않으면 무한 루프라는 함정으로 직행한다.

자동화를 짤 때는 기동 조건과 세트로 정지 조건을 반드시 정한다. 나중에 곤란해지지 않으려면 이건 정말 꼭 짚어야 한다.

실무 보충: 정지 조건은 완료 판정 하나로는 부족하다. 실무에서는 최소한 다음 세 가지를 함께 걸어 두는 편이 안전하다.

• 완료 판정: 테스트 통과, 특정 파일 생성, 이슈 상태 변경 등 기계적으로 확인 가능한 조건
• 반복 상한: N바퀴를 돌면 완료 여부와 무관하게 중단
• 비용 상한: 토큰·시간 예산. 검증이 매 바퀴 돌면 비용은 바퀴 수에 비례해 늘어난다

특히 사내 결제 계정으로 돌리는 자동화라면 비용 상한이 사실상 최후의 안전장치다.

② 워크트리 ── 병행 작업이 부딪히지 않게 나눈다

동시에 돌리면 작업이 부딪힌다

여러 에이전트를 동시에 돌리면 서로의 작업이 부딪힌다. 한쪽이 편집 중인 파일을 다른 쪽이 다른 의도로 덮어써 버리면 결과물은 망가진다. 이걸 막는 게 워크트리를 통한 작업 분리다.

워크트리는 원래 Git의 기능이다

워크트리는 원래 Git의 기능으로, 같은 리포지터리에서 독립된 작업 디렉터리를 여러 개 잘라내는 구조를 가리킨다(Claude Code에서 Git을 다루는 기본은 Git 조작 자동화에 정리돼 있다). 오스마니는 이 구성 요소가 겨냥하는 바를 이렇게 단정적으로 적는다.

"two agents ... dont step on each other"

(두 에이전트가…… 서로를 밟지 않는다)

각 에이전트에게 독립된 작업 영역을 주면 병행해서 돌려도 간섭이 생기지 않는다. 여러 에이전트를 동시에 돌리는 구성에서는 이 분리가 전제가 된다. 병렬로 돌리고 싶으면 먼저 작업 장소를 나눠라. 그렇게 기억하자.

③ 스킬 ── 프로젝트 지식을 적어 둔다

모르는 건 추측으로 메워 버린다

에이전트는 명시되지 않은 사항을 추측으로 메우려 든다. 코딩 규약, 디렉터리의 의미, 배포 절차, 네이밍 규칙처럼 프로젝트 고유의 약속을 모르면 그럴듯하게 추측하고, 꽤 자주 틀린다.

스킬은 모르면 추측할 수밖에 없는 지식을 쥐여 주는 구조

스킬은 이렇게 에이전트가 모르면 추측할 수밖에 없는 지식을 명문화해서 쥐여 주는 구조다. 오스마니는 그 의도를 이렇게 표현한다.

"write down the project knowledge the agent would otherwise just guess"

(그러지 않으면 에이전트가 추측만 하게 될 프로젝트 지식을 적어 둔다)

한 번 스킬로 적어 두면 이후 모든 실행에서 그 지식이 전제가 된다. 추측의 여지를 줄일수록 루프의 출력은 안정된다. 자주 내리는 지시, 매번 설명하는 전제를 하나 적는 것만으로도 훌륭한 스킬의 첫걸음이다. 실제 파일 형식은 SKILL.md 작성법을 보면 된다.

다음 글: 커넥터·서브에이전트·기억 — 검증력, 생성과 검증의 분리, 디스크