<aside> 🔁
핵심 결론: AI 에이전트의 반복 실행을 안전하게 운영하려면 PDCA의 품질 게이트가 필요하다. 그러나 루프 그 자체를 더 나은 시스템으로 진화시키려면, 결과를 단순 판정하지 않고 가설을 갱신하는 데밍의 PDSA가 중심이 되어야 한다. 스킬에 내장한 Eval은 이 두 층을 연결하는 가장 작은 실행 단위가 될 수 있다.
</aside>
AI 에이전트를 잘 활용하는 문제는 더 길고 정교한 프롬프트를 한 번 작성하는 문제가 아니다. 목표를 해석하고, 도구를 호출하고, 결과를 검증하며, 실패를 기록해 다음 실행을 바꾸는 반복 구조 자체를 설계하는 문제다. 최근 이 흐름은 루프 엔지니어링 또는 하네스 엔지니어링이라는 이름으로 확장되고 있다.
그런데 이 이름은 새롭지만, 핵심 질문은 낯설지 않다. “실행 후 무엇을 보며, 무엇을 바꾸는가?”라는 질문은 오래전 품질관리와 시스템 사고의 중심에 있었다. W. Edwards Deming은 이 질문에 PDCA보다 PDSA를 더 적합한 언어로 제시했다. AI 에이전트의 루프를 설계하는 지금, 두 약어의 한 글자 차이는 시스템이 단순히 고장 없이 반복되는지, 아니면 매 반복마다 더 나은 판단을 배우는지를 가른다.
| 관점 | PDCA | PDSA |
|---|---|---|
| 네 단계 | Plan – Do – Check – Act | Plan – Do – Study – Act |
| 3단계의 주 질문 | 계획대로 되었는가? | 예측과 실제는 왜 달랐는가? 가설은 맞았는가? |
| 강점 | 통제, 표준화, 반복 가능한 운영 | 지식 생성, 원인 학습, 실험의 확장 |
| 실패의 의미 | 수정해야 할 결함 | 다음 설계를 위한 관측값 |
| AI 에이전트에서의 역할 | 테스트·정책·비용·권한 게이트 | 프롬프트·도구·메모리·평가기 자체의 개선 |
PDCA가 약한 방법론이라는 뜻은 아니다. 배포 전 테스트, 형식 검사, 권한 승인, 비용 상한, 재시도 횟수처럼 운영에 필요한 경계는 PDCA적 사고 없이는 관리하기 어렵다. 다만 AI 에이전트처럼 확률적 모델과 여러 도구가 결합된 환경에서는 통과 여부만 확인하는 Check가 충분하지 않다.
PDSA의 핵심은 Check가 아니라 Study에서 예측과 실제를 비교해 다음 가설을 바꾸는 데 있다.
데밍 연구소의 설명은 분명하다. 데밍은 PDCA가 아니라 PDSA를 강조했고, 세 번째 단계도 Check가 아니라 Study로 보았다. Check가 변경의 성공·실패와 필요한 수정에 무게를 둔다면, Study는 개선 노력의 결과를 예측과 비교하고, 그 차이를 통해 이론과 지식을 갱신하는 데 무게를 둔다.
PDSA의 출발점은 “이렇게 하면 좋아질 것이다”라는 명시적 가설이다. Plan 단계에서 목표만 적는 것이 아니라, 무엇이 어떻게 바뀔 것인지와 성공을 무엇으로 볼 것인지를 적는다. Do는 전체 배포가 아니라 작은 규모의 시험이다. Study는 결과 수치만 읽지 않고, 예상과 실제의 차이·부작용·측정의 한계를 분석한다. Act는 성공한 절차를 고정하는 데 그치지 않고, 가설·방법·범위를 바꾸어 다음 실험으로 연결한다.
flowchart LR
P[Plan: hypothesis] --> D[Do: small test]
D --> S[Study: compare and learn]
S --> A[Act: change method]
A --> P
이 도식에서 중요한 것은 화살표가 원을 만든다는 사실보다, Study가 다음 Plan의 입력을 바꾼다는 점이다. 테스트 통과는 결과일 뿐이다. 왜 통과했는지, 다른 조건에서도 통과할지, 지금의 지표가 사용자 가치와 실제로 연결되는지를 이해하지 못하면 시스템은 쉽게 국소 최적화에 빠진다.
루프 엔지니어링은 모델, 도구, 평가, 메모리, 안전 경계를 하나의 반복 구조로 묶는다.
최근 말하는 루프 엔지니어링은 보통 다음 요소를 묶는다.