실행 경계(Execution Boundary)를 정하면, AI에게 안심하고 맡길 수 있는 범위가 넓어집니다.

그러면 다음에 일어나는 일은, 맡기는 양을 너무 늘려버리는 것입니다.

저는 얼마 전, AI에게 이렇게 부탁했습니다.

"후보를 찾고, 조건에 맞는 것을 골라서, 제안문을 작성해 주세요."

언뜻 보기에는 하나의 연속된 작업입니다. 실제로 찾는 것까지는 정확했습니다. 고르는 것도 조건대로였습니다.

하지만 제안문은 엉뚱한 것이 나왔습니다.

원인은 능력이 아닙니다. 찾는 단계에서 본 정보 그대로, 쓰는 단계까지 달려갔기 때문이었습니다. 찾을 때는 목록의 헤드라인만으로 충분합니다. 하지만 쓸 때는 상대방이 무엇을 원하는지까지 읽어야 합니다. 같은 "본다"는 행위라도 필요한 깊이가 달랐습니다.

하나의 지시에 3가지 판단을 담았기 때문에, 뒤쪽의 판단일수록 앞쪽의 정보 그대로 처리된 것입니다.

이번에는 기록과 경계를 정비한 뒤에 남는 마지막 문제, 한 번의 지시를 하나의 작업으로 좁히는 운용을 다룹니다.

왜 한꺼번에 전달하면 망가지는가

여러 작업을 한꺼번에 전달하면 다음과 같은 일이 일어납니다.

• 도중에 전제 조건이 바뀌어도 멈추지 않고 진행함
• 어디까지 끝났는지 나중에 특정할 수 없음
• 실패한 부분만 다시 할 수 없음
• 결과물이 나와도 어떤 판단이 옳았는지 검증할 수 없음

특히 곤란한 것은 마지막 단계입니다.

한꺼번에 전달한 작업이 잘 풀리지 않았을 때, 찾는 방법이 나빴는지, 고르는 방법이 나빴는지, 쓰는 방법이 나빴는지를 알 수 없습니다. 다음에 무엇을 바꿔야 할지 결정되지 않아 전부 다시 해야 합니다.

하나씩 전달하고 있다면 어디에서 멈췄는지 알 수 있습니다. 알 수 있다면 바꿔야 할 곳은 하나로 충분합니다.

「1작업」을 구분하는 법

그렇다고는 해도 「1작업」의 정의는 모호합니다.

「조사하기」는 1작업일까요? 「기사 쓰기」는 1작업일까요? 입도(Granularity)로 생각하면 언제까지고 결정되지 않습니다.

판단 기준은 이것입니다.

완료 조건(Definition of Done)을 확인할 수 있는 형태로 하나만 쓸 수 있는가

쓸 수 있다면 1작업입니다. 쓸 수 없다면 아직 여러 개가 포함되어 있습니다.

예를 들어 「후보를 찾고 골라서 제안문을 작성한다」는 완료 조건이 3개 필요하게 됩니다.

1. 후보가 몇 건인지 알 수 있다
2. 조건에 맞는 것을 1건 결정할 수 있다
3. 제안문이 완성된다

3개를 써야 하는 시점에서 나누어야 한다는 것을 알 수 있습니다.

반대로 「후보가 몇 건인지 센다」라면 완료 조건은 한 줄이면 충분합니다.

조건에 맞는 후보의 건수를 기록할 수 있다

완료 조건을 한 줄로 쓸 수 있는 곳까지 나눈다. 이것이 실무에서 사용할 수 있는 기준입니다.

NEXT_ACTION.md に 쓰는 것은 4가지만

작업 단위가 결정되면 그것을 파일로 만듭니다.

# 다음 작업
최종 수정일: YYYY-MM-DD
## 다음에 수행할 하나의 작업
...

4개의 헤더밖에 없습니다. 늘리지 않는 것이 중요합니다.

이 파일이 길어지기 시작한다면, 그것은 작업을 제대로 좁히지 못하고 있다는 징후입니다.

「이번에 하지 않을 것」이 가장 효과적이다

4가지 중 쓰기를 잊기 쉽고 효과가 큰 것이 「이번에 하지 않을 것」입니다.

AI는 부탁받은 작업 주변에서 문제를 발견하면, 선의로 생각하고 고쳐버립니다.

• 덤으로 다른 파일도 정렬한다
• 눈에 띄는 기술(記述)을 한꺼번에 다시 쓴다
• 관련 있어 보이는 작업을 앞질러서 진행한다

모두 선의이지만, 변경 범위가 넓어지면 무엇 때문에 결과가 바뀌었는지 알 수 없게 됩니다.

검증하고 싶은 변수가 1개일 때, 3개가 움직여 버리기 때문입니다.

## 이번에 하지 않을 것
- 다른 파일의 정렬
- 가격이나 설정의 변경
...

금지하기 위해서가 아닙니다. 측정 가능한 상태를 유지하기 위해서입니다.

「대기 중」을 나누면 작업이 멈추지 않는다

또 하나 간과하기 쉬운 것이 「대기 중」입니다.

외부 반영 대기, 인간의 확인 대기, 결과가 나올 때까지의 관찰 기간. 이것들을 「다음 작업」과 같은 장소에 적으면 기다리는 동안 전체가 멈춥니다.

대기는 관찰 대상을 고정하는 시간이지, 리포지토리(Repository) 전체의 정지 시간이 아닙니다.

## 대기 중
- 반영까지 3일 정도 걸릴 것으로 예상 (확인은 3일 후)
- 상대방의 답장 대기
...

기다리기로 결정했을 때는 동시에 「기다리는 동안 할 수 있는 일」을 하나 적어둡니다. 이것이 없으면 대기가 그대로 정지로 이어집니다.

종료 시에 다음 수를 하나만 남긴다

작업이 끝나면 기록을 남깁니다. 형식은 고정합니다.

## YYYY-MM-DD — 작업명
- 목적:
- 입력:
...

매번 모든 것을 길게 쓸 필요는 없습니다. 다만, 「실행한 것」과 「아직 확인하지 않은 것」은 반드시 구분합니다.

이것을 섞어버리면, 다음에 읽을 AI(또는 다음 날의 자신)가 미확인 내용을 확정된 사항으로 취급하게 됩니다. 이는 전형적인 사고의 입구입니다.

그리고 마지막 줄에는 다음 작업(Next Action)을 딱 하나만 적습니다. 두 개를 적으면 다음 지시가 다시 모호해집니다.

왜 「다음 작업을 부탁합니다」로 작동하는가

이 정도로 정돈되어 있다면, 의뢰는 다음과 같이 짧게 줄일 수 있습니다.

START.md에서 현재 위치를 확인해 주세요.
NEXT_ACTION.md의 작업 하나만 진행하고,
종료 시에 로그와 다음 단계를 업데이트해 주세요.

환경이 공유되어 있다면 더욱 짧아집니다.

다음 작업을 부탁합니다.

짧은 지시로 정확하게 움직이는 것은, AI가 눈치를 챘기 때문이 아닙니다.

필요한 문맥(Context), 경계(Boundary), 완료 조건(Completion Condition)이 이미 리포지토리(Repository)에 작성되어 있기 때문입니다.

지시의 짧음은 사전에 작성한 분량에 비례합니다. 매번 긴 프롬프트(Prompt)를 쓰고 있다면, 그것은 기록이 부족하다는 신호입니다.

요약

한 번의 지시를 하나의 작업으로 좁히는 것은 AI의 능력을 제한하는 것이 아닙니다.

판단의 질을 마지막 하나까지 유지하기 위한 운영 방식입니다.

• 완료 조건이 한 줄로 써질 수 있는 수준까지 작업을 나눈다
• NEXT_ACTION.md는 4개의 헤더(Heading)로만 구성한다
• 「이번에 하지 않을 것」을 적어서 측정 가능한 상태를 유지한다
• 「대기 중」과 「대기 중에 진행해도 좋은 작업」을 구분한다
• 종료 시에는 실시한 것과 미확인 사항을 나누고, 다음 단계를 하나만 남긴다

도입부의 실패로 돌아가 보면, 제가 전달했어야 했던 것은 「후보를 찾아서 선택하고 작성해 주세요」가 아니라, 「후보가 몇 건인지 세어 주세요」라는 한 문장이었습니다.

세어 본 결과를 보고 나서, 선택하라는 지시를 내린다. 선택한 결과를 보고 나서, 작성하라는 지시를 내린다.

멀리 돌아가는 것처럼 보이지만, 재작업이 발생하지 않는 만큼 이쪽이 더 빠르게 끝납니다.

다음에는, 그럼에도 작업이 망가졌을 때 어떻게 안전한 지점까지 되돌아갈지를 다룹니다.

그대로 도입할 수 있는 구현 템플릿

이 연재에서 다루고 있는 운영 방식을 자신의 리포지토리에 복사할 수 있는 형태로 정리한 구현 워크북입니다.

• START.md: 새로운 AI가 가장 먼저 읽는 입구
• CURRENT_STATE.md: 현재 유효한 사실과 판단
• AGENTS.md: AI의 작업 규칙과 실행 경계
• NEXT_ACTION.md: 다음 작업과 완료 조건 - 작업 로그와 복구 체크리스트

전 6장 중 「머리말」은 무료로 읽을 수 있습니다.

Discussion