기록이 정돈되면, AI에게 맡길 수 있는 작업은 단번에 늘어납니다.

현재 위치를 읽게 하면 설명이 필요 없고, 작업 로그를 남기게 하면 검증도 가능합니다. 이 단계에 이르면, 다음에 나타나는 문제는 능력이 아닙니다.

어디까지 진행해도 좋은가입니다.

저는 처음에 AI를 위한 규칙에 "불명확한 점은 적절히 판단하여 진행해 주세요"라고 적었습니다. 정중한 지시라고 생각했습니다.

결과는, 멈춰주길 바라는 지점에서 멈추지 않는 것이었습니다.

판단이 필요한 장면일수록 AI는 스스로 결정했고, 우리가 확인하고 싶었던 상태를 지나쳐 버렸습니다. 잘못된 것은 AI가 아니라, "적절"이라는 기준을 아무도 작성하지 않았다는 점입니다.

이번에는 AI의 작업 규칙을 AGENTS.md로 작성하여, 실행 경계(execution boundary)를 결정하는 방법을 다룹니다.

규칙은 이상이 아니라, 실행 가능성으로 작성한다

AI를 위한 규칙은 작성하는 순간에는 모두 올바르게 보입니다.

하지만 다음과 같은 규칙은 환경에 따라 처음부터 지킬 수 없습니다.

• "항상 최신 main을 가져온다"
• "반드시 운영 환경(production environment)에서 확인한다"
• "모든 것을 자동으로 완료한다"
• "불명확한 점은 적절히 판단한다"

위의 세 가지는 권한의 문제입니다. AI에게 네트워크 권한, 운영 환경 권한, 머지(merge) 권한이 없다면 실행할 수 없습니다.

마지막 하나는 기준의 문제입니다. "적절"에 대한 판단 기준이 없기 때문에, AI는 무엇을 해도 위반이 되지 않으며, 동시에 무엇을 해도 정답이 되지 않습니다.

지킬 수 없는 규칙을 두면 규칙 전체가 장식품이 됩니다.

그러므로 실행 불가능한 의무가 아니라, 확인할 수 없을 때의 동작을 작성합니다.

# 나쁜 작성 방식
- 항상 최신 main을 가져와서 작업한다
- 불명확한 점은 적절히 판단한다
...

"모를 때는 진행하지 말고 보고한다"라고 결정하는 것만으로도 사고의 대부분을 방지할 수 있습니다.

실행 경계는 3가지 질문으로 결정된다

AGENTS.md에 무엇을 쓸지 고민된다면, 다음 세 가지만 먼저 답해 보세요.

• 무엇을 변경해도 되는가
• 어디서 멈출 것인가
• 최종 판단은 누가 하는가

이 세 가지가 결정되어 있다면 세부 규칙은 나중에 추가할 수 있습니다. 반대로 여기가 모호한 상태에서 규칙을 늘려봤자 AI는 판단의 근거를 가질 수 없습니다.

멈추는 조건을 먼저 정해두면, AI에게 맡기는 범위를 안심하고 넓힐 수 있습니다.

AGENTS.md의 최소 구성

처음부터 긴 규약은 필요 없습니다. 다음 4가지 항목으로 시작할 수 있습니다.

# AI 협업 규칙
이 리포지토리(repository)에서는 `main`을 기준으로 한다. main으로의 머지는 인간이 수행한다.
## 작업 시작 시
...

여기서 중요한 것은 규칙의 양이 아닙니다.

"시작할 때 무엇을 읽는가"와 "어디서 인간에게 되돌리는가"가 적혀 있는지 여부입니다.

되돌리기 어려운 조작은 일괄적으로 인간에게 되돌린다

맡길 범위를 판단할 때, 작업의 난이도로 선을 그으면 실패합니다.

어려운 작업일수록 신중하게 다루고 싶어지지만, 실제로 곤란한 것은 쉽고, 빠르고, 되돌리기 어려운 조작입니다.

• 외부 공개, 게시, 전송
• 결제, 구매, 계약
• 파일이나 브랜치(branch)의 삭제
• 운영 데이터(production data)의 업데이트
• 제삼자에게 전달할 성과물의 확정

이것들은 실행 자체는 순식간입니다. 하지만 실행 후에 "역시 아니었다"라고 깨달아도 원래대로 되돌릴 수 없습니다.

반면 조사, 초안 작성, 비교, 수정안 작성, 테스트 실행은 실수해도 다시 할 수 있습니다.

판단의 축을 **난이도가 아닌 가역성(reversibility)**에 둡니다.

다시 할 수 있는 작업은 AI에게 맡기고, 다시 할 수 없는 작업은 인간의 승인 지점으로 만듭니다.

"금지"만으로는 부족하다. 멈춘 뒤의 형식을 작성한다

멈추는 조건을 적더라도, 멈추는 방법을 정해두지 않으면 작업은 공중에 붕 뜨게 됩니다.

"할 수 없었습니다"라고만 보고받으면, 인간은 상황을 재확인하는 것부터 다시 시작해야 합니다.

그래서 정지 시의 보고 형식까지 지정합니다.

## 정지하여 보고할 때의 형식
- 실시할 수 있었던 부분까지
- 멈춘 이유 (권한, 정보 부족, 판단 필요)
...

이 형식이 있으면 정지는 실패가 아니라, 다음 수를 만들기 위한 작업이 됩니다.

AI는 판단을 대행하지 않고, 인간은 상황을 재조사하지 않아도 됩니다.

규칙은 사고가 발생한 순서대로 늘린다

AGENTS.md도 처음부터 완성시키지 않는 편이 지속하기 좋습니다.

상상할 수 있는 위험을 전부 적으면 AI도 인간도 읽지 않게 됩니다. 실제로 발생한 문제를 그때마다 한 줄씩 추가합니다.

규칙이 늘어나는 이유를 사고 이력으로서 남겨두면, 나중에 읽는 사람(과 다른 AI)이 그 한 줄을 지워도 될지 판단할 수 있습니다.

경계가 명확할수록 지시는 짧아진다

실행 경계 (Execution Boundary)를 결정하면, 요청할 때마다 주의 사항을 나열할 필요가 없어집니다.

START.md부터 순서대로 현재 위치를 확인해 주세요.
NEXT_ACTION.md의 한 가지 작업만 수행하고,
종료 시에 로그와 다음 단계(Next Step)를 업데이트해 주세요.

환경이 공유되고 있다면, 이 정도로 짧게 줄일 수 있습니다.

다음 작업을 부탁합니다.

짧은 지시로 진행되는 것은 AI가 눈치를 챘기 때문이 아닙니다.

필요한 문맥 (Context), 경계, 완료 조건이 리포지토리 (Repository)에 남아 있기 때문입니다.

요약

AI에게 맡기는 양을 늘릴 때 필요한 것은 더 똑똑한 지시가 아니라, 실행 가능한 경계입니다.

• 지킬 수 없는 규칙은 쓰지 않는다
• "무엇을 변경해도 되는지", "어디서 멈출 것인지", "누가 결정할 것인지"를 먼저 결정한다
• 되돌릴 수 없는 작업은 인간의 승인 지점 (Approval Point)으로 설정한다
• 멈췄을 때의 보고 형식까지 결정한다
• 규칙은 사고가 발생한 순서대로 추가한다

경계를 결정하는 것은 AI를 제한하는 것이 아닙니다.

안심하고 맡길 수 있는 범위를 넓히는 것입니다.

다음 회차에서는 경계를 결정한 상태에서 작업을 멈추지 않기 위해, 한 번의 지시를 하나의 작업으로 좁히는 운영 방식을 다룹니다.

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

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

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

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

Discussion