AI를 다루는 기술은 프롬프트, 컨텍스트, 하네스를 거쳐 루프 엔지니어링으로 이어지고 있습니다. 앞의 세 단계가 “시킬 때 잘하게” 만드는 기술이라면, 루프는 “시키지 않아도 목표까지 돌고, 정해 둔 기준에서 스스로 멈추게” 만드는 기술입니다.
이 내용을 개발자 관점에서 한 페이지로 정리해 보았습니다.
페이지에 담은 것
| 섹션 | 내용 |
|---|---|
| 4단계 지도 | 프롬프트 → 컨텍스트 → 하네스 → 루프, 단계마다 개발자가 만드는 것 |
| 이너·아우터 루프 | 프레임워크가 이미 제공하는 루프와 우리가 설계하는 바깥 루프의 경계 |
| 6가지 구성 요소 | 트리거, 작업 공간 분리, 스킬, 도구(MCP), 검증자, 상태 파일. 역할과 구현 코드 |
| 종료 조건 시뮬레이터 | 판정 기준과 안전장치(최대 반복, 토큰 한도, 무진전 감지)를 바꿔 가며 루프가 어디서 멈추는지 비교 |
| 실패 패턴 | 비용 폭주, 거짓 완료, 매번 첫날, 질문하면 기억 상실 등 증상에서 빠진 부품을 역추적 |
| 업계에서 본 실패 | “에이전트는 실패했다”는 평가와 코딩 에이전트의 성공을 루프 조건으로 비교 |
| 현업 적용 | 후보 업무 진단, 도입 단계, 사례 3개 분해 |
| 설계 캔버스 | 7칸을 채우면 흔한 설계 실수를 바로 짚어 주는 양식, Markdown 복사 지원 |
정리하면서 느낀 점
에이전트를 직접 만들며 가장 많이 부딪힌 문제는 모델 성능보다 루프의 조건이었다고 생각합니다.
- 스킬만 있고 상태가 없으면 에이전트는 매번 스킬의 1단계부터 성실하게 다시 시작합니다. 스킬은 절차(how)를 알고, 진행 위치(where)는 상태 파일이 알아야 합니다.
- 완료 기준이 판정 불가능한 문장이면 루프는 멈추지 않거나, 덜 된 결과를 완료로 보고합니다.
- 사람에게 질문하려고 에이전트를 종료하면 돌아왔을 때 앞의 맥락을 잃습니다. 같은 스레드에서 대기하다 재개하는 구조가 필요합니다.
업계에서 “에이전트는 실패했다”는 평가가 나오는 것도 비슷한 맥락으로 보입니다. 판정 기준과 되돌리기가 없는 곳에 완전 자율 에이전트를 넣은 시도가 실패했고, 테스트·CI·PR 리뷰라는 루프 조건을 원래 갖춘 코딩 영역에서는 에이전트가 크게 성공했습니다.
