좋은 Codex 루프는 실패를 대화가 아니라 시스템에 남긴다

# 좋은 Codex 루프는 실패를 대화가 아니라 시스템에 남긴다

Codex를 쓰다 보면 "아까 말했잖아"라는 순간이 생긴다.

건드리지 말라고 한 파일을 또 보거나, 검증 없이 끝내거나, 사용자가 원하지 않은 리팩토링을 하거나, 운영 작업과 사용자 작업을 섞는 식이다.

이때 가장 쉬운 반응은 다시 말하는 것이다. 더 강하게, 더 자세하게, 더 길게 지시한다.

하지만 같은 실패가 반복된다면 문제는 프롬프트의 강도가 아닐 수 있다. 실패가 시스템에 반영되지 않았다는 뜻일 수 있다.

## 실패를 시스템에 남기는 절차

```mermaid
flowchart TD
    A["실패 관찰"] --> B["실패 유형 이름 붙이기"]
    B --> C{"반복될 수 있는가?"}
    C -->|No| D["대화에서 바로잡기"]
    C -->|Yes| E["적절한 위치 선택"]
    E --> F["지침 / Skill / Reference / Test / Script / Thread"]
    F --> G["다음 작업에서 재확인"]
```

## 어디에 남길까

| 반복되는 문제 | 남길 위치 |
|---|---|
| 같은 금지사항을 계속 말한다 | AGENTS.md 또는 프로젝트 지침 |
| 같은 절차를 계속 설명한다 | Skill |
| 긴 배경지식을 매번 붙인다 | Reference |
| 같은 명령을 매번 알려준다 | Script 또는 Test |
| 역할이 자주 섞인다 | Thread 분리 |
| 결과 확인이 누락된다 | Acceptance checklist |

## 핵심

대화 안에서만 고친 실패는 다음 대화에서 쉽게 사라진다.

반대로 시스템에 들어간 실패는 다음 작업의 조건이 된다. "이 파일은 건드리지 말 것"이 지침에 들어가고, "수정 후 이 테스트를 돌릴 것"이 검증 루틴이 되고, "이 종류의 작업은 별도 스레드에서 할 것"이 작업 경계가 되면 Codex는 같은 요청을 받아도 다른 환경에서 움직인다.

> 실패를 대화에만 남기면 같은 일이 반복된다.  
> 실패를 시스템에 남기면 Codex가 같은 문제 앞에서 다르게 움직이기 시작한다.

좋은 Codex 루프는 실패를 대화가 아니라 시스템에 남긴다

// COMMENTS

ON THIS PAGE