📋 Loop Engineering
프롬프트를 AI 코딩 에이전트로 던지는 시대는 달라지고 있어요
Addy Osmani의 이 아티클은 한번 읽어보셨으면 좋겠어요. 정리해보면 이래요.
Peter Steinberger는 이렇게 말했어요.
"이제 코딩 에이전트에게 직접 프롬프트를 보내면 안 됩니다. 에이전트를 프롬프트하는 루프를 설계해야 합니다."
Boris Cherny도 같은 말을 했죠.
"나는 더 이상 Claude에게 직접 프롬프트하지 않아요. 내 일은 루프를 작성하는 것.."
↓
루프를 만드는 다섯 가지 요소 + 메모리
-
Automations - 주기적으로 스스로 일감을 찾아오는 자동화
-
Worktrees - 여러 에이전트가 동시에 작업해도 파일이 충돌하지 않게 하는 격리
-
Skills - 프로젝트의 맥락과 규칙을 파일로 남겨 매번 설명하지 않게 하는 것
-
Plugins & Connectors - 이슈 트래커, Slack, CI 같은 외부 도구와 연결
-
Sub-agents - 작성하는 에이전트와 검토하는 에이전트를 분리
그리고 여섯 번째로 중요한 건 Memory..
단일 대화가 아니라 외부에 상태를 기록하는 공간이 필요하다는 거죠. markdown 파일이나 Linear 보드 같은..
↓
중요한 이유는 있어요
모델은 실행이 끝나면 모든 걸 잊어버려요. 그래서 메모리는 컨텍스트가 아니라 디스크에 있어야 합니다.
"모델은 잊지만, 레포지토리는 잊지 않습니다!"
이 한 문장이 루프 엔지니어링의 본질을 가장 잘 설명하는 것 같아요.
Claude Code의 /loop, /goal, worktree isolation 같은 기능들이 이 구조와 거의 1:1로 맞아떨어집니다. Codex도 마찬가지고요.
특히 /goal은 지정한 조건이 충족될 때까지 반복 실행하는데, 완료 판단을 코드를 작성한 모델이 아니라 별도의 모델이 한다는 점이 흥미롭습니다. Sub-agents 철학이 종료 조건에도 적용된 거죠.
↓
루프가 여전히 해결해주지 못하는 것들
루프가 아무리 정교해져도 결국 남는 문제들이 있어요.
-
Verification은 여전히 사람이 해야 해요. 루프가 혼자 돌아가면서 실수도 혼자 저지르기 때문이죠.
-
Comprehension Debt > 루프가 코드를 빠르게 생산할수록, 내가 실제로 이해하는 양은 점점 줄어듭니다.
-
Cognitive Surrender > 루프가 잘 돌아가기 시작하면, 결과를 무비판적으로 받아들이게 되는 위험.
마지막으로 이 얘기는 계속 자문해야 한다고 봐요.
"똑같은 루프를 만들어도 결과가 정반대인 두 사람이 있습니다. 한 명은 깊이 이해하는 일을 더 빠르게 하기 위해 루프를 쓰고, 다른 한 명은 이해를 피하기 위해 루프를 씁니다. 루프는 그 차이를 모릅니다. 당신만 압니다."
"루프를 만들되, 엔지니어로 남아 있으려는 사람이 루프를 만들어야 합니다. 그냥 '시작' 버튼을 누르는 사람이 되지 말고..."
루프 설계는 프롬프트 엔지니어링보다 어렵지, 쉽지 않습니다.
