[Codex] 루프 엔지니어링(Loop Engineering)이란? Codex로 AI 코딩 에이전트 자동화하기

intro

최근 출산 휴가를 앞두고 팀 인력 부족(퇴사 등)이라는 악재까지 겹쳐 어떻게 하면 내가 하는 업무를 멈추지 않고 조금이라도 휴가 중에 계속 어시스트를 할 수 있을까를 고민하면서 한 달 정도 틈날 때마다 AI Agent System을 구축하고 있었다.

사내 표준으로 지정된 Codex 기반으로 GitLab issue 작성, 코드 작업, MR 작성, 세션 회고까지의 workflow를 구축해서 테스트를 진행하였고 현재 매일 오전 6시마다 정상 동작하고 있다.

이게 최근 Google Senior SW Engineer가 언급한 루프 엔지니어링이었다.

Addy Osmani의 글 “Loop Engineering”을 읽고 나서 내가 구축한 시스템과 개념이 일치하는 것을 확인할 수 있었고 내가 가고 있는 방향이 틀리지 않았음을 확신할 수 있었다. 핵심은 한 문장이다.

“이제 코딩 에이전트에게 프롬프트하지 마라. 에이전트에게 프롬프트하는 루프를 설계하라.” — Peter Steinberger

최근에 내가 사내에 Codex 기반으로 루프 엔지니어링을 도입하면서 정리한 개념과 실제로 내가 어떻게 적용했는지, 그리고 직접 써보며 느낀 한계와 주의점까지 이 글에 정리한다.

1. 🔁 루프 엔지니어링이란?

루프 엔지니어링(Loop Engineering)이란, 사람이 에이전트에게 단계별로 프롬프트를 입력하는 방식 대신, 에이전트가 목표를 달성할 때까지 스스로 반복하도록 만든 시스템을 설계하는 것을 말한다.

기존 방식은 사람이 루프의 일부였다. 내가 지시 → 에이전트 실행 → 내가 확인 → 다시 지시. 이 순환을 사람이 직접 돌렸다.

루프 엔지니어링은 이 순환 자체를 시스템으로 만든다. 사람은 더 이상 매번 프롬프트를 입력하는 손이 아니라, 루프를 설계하고 검증하는 엔지니어가 된다.

Claude Code 개발을 이끈 Boris Cherny도 같은 이야기를 한다.

“나는 더 이상 Claude에게 프롬프트하지 않는다. Claude에게 프롬프트하고 무엇을 할지 알아내는 루프를 돌리고 있다.” — Boris Cherny

원문은 Claude Code 기능을 예로 들지만, 핵심 개념은 도구에 종속되지 않는다. 나는 같은 패턴을 Codex로 구현했다.

2. 🧩 루프를 이루는 5가지 구성요소 (+ α)

루프 엔지니어링은 결국 다섯 개의 부품을 조립하는 일이다. 아래 표는 원문의 5요소를 Codex 환경에서 어디에 대응시켰는지까지 함께 정리한 것이다.

구성요소	역할	Codex에서의 대응
Automations (자동화)	루프의 심장박동. 스케줄에 맞춰 탐색·트리아지 작업을 알아서 실행	Automations 기능 사용
Worktrees (워크트리)	병렬 작업이 서로의 파일을 건드리지 않도록 격리	git worktree로 작업별 디렉토리 분리(Git 내장 기능)
Skills (스킬)	프로젝트 지식을 재사용 가능한 문서로 정리해 매번 설명 안 해도 되게 함	Skills 기능
Plugins / Connectors	에이전트를 실제 도구(이슈 트래커, CI 등)와 연결	Codex 단일 AI Agent가 사내 표준이라 MCP 대신 API로 통합
Sub-agents (서브 에이전트)	만드는 에이전트(maker)와 검증하는 에이전트(checker)를 분리	별도 에이전트로 검증 단계 수행

여기에 여섯 번째 요소가 사실상 필수다.

• 외부 메모리(External Memory): 모델은 실행이 끝나면 컨텍스트를 잃는다. 그래서 진행 상태를 markdown 파일이나 이슈 보드 같은 곳에 기록해 둬야 다음 루프가 이어받을 수 있다. 루프가 “기억”을 갖게 하는 장치다.

핵심 원칙 하나: 만드는 쪽(maker)과 검사하는 쪽(checker)을 절대 같은 에이전트로 두지 마라. 자기가 짠 코드를 자기가 채점하면 통과는 잘 되지만 품질은 보장되지 않는다.

3. ⚙️ 하루치 루프는 이렇게 돈다

말로만 들으면 추상적이니, 실제로 한 사이클이 어떻게 도는지 정리하면 이렇다.

1. 아침 자동화 트리거 — 오전 6시에 예약된 Automation 기능이 동작하여 이전 자동화에서 등록한 MR이 merge되었는지 확인한다. merge되었다면 다음 작업을 미리 작성해둔 개선 레벨에 맞춰 작업 목표를 설정한다. 만약 merge되어 있지 않다면 리뷰를 해줄 팀원이 타업무에 의해 바빠진 것으로 판단하고 새로운 이슈 대응을 하지 않고 상태 기록으로 넘어간다.
2. 워크트리 격리 — 발견된 이슈에 대해 커넥터를 통해 이슈 문서를 등록하고 별도 워크트리를 만들어 수정 작업을 격리한다.
3. maker / checker 분리 — 한 서브 에이전트가 해결책 초안을 만들고, 다른 서브 에이전트가 테스트 기준으로 검증한다.
4. 커넥터가 실제 작업 처리 — 미리 작성된 API 커넥터가 MR을 작성한다.
5. 상태 기록 — markdown 상태 파일에 진행 상황을 남겨, 다음 사이클이 이어받는다.

여기서 사람이 하는 일은 실제 작업을 merge할지 의사결정을 하는 것뿐이다. 아직은 테스트 단계이고 동작하는 프로젝트의 코드 베이스가 많은 사람들을 거쳐가면서 일관성이 깨져있으며 하나의 코드 파일이 1000줄이 넘는 것도 많아서 최종 승인은 사람이 하도록 제한해두었다.

4. 🚧 루프가 대신 해주지 못하는 것

도입하면서 가장 경계한 부분이다. 루프 엔지니어링은 레버리지를 옮길 뿐, 사람의 판단을 없애주지 않는다. 원문이 짚는 세 가지 위험은 실제로 와닿았다.

• 검증 책임은 여전히 엔지니어의 몫이다. 루프가 빨라질수록 “통과했으니 됐겠지” 하고 넘기기 쉽지만, 최종 책임은 사람에게 있다. 실제로 merge 승인 권한은 팀원들에게만 있다.
• 이해 부채(Comprehension Debt)가 쌓인다. 에이전트가 만든 코드를 내가 읽지 않은 채 머지가 누적되면, 어느 순간 아무도 시스템을 이해하지 못하는 상태가 된다. 나는 팀원들에게 코드 리뷰 문화를 강조하여 이 부분을 해결하고자 한다.
• 인지적 항복(Cognitive Surrender). 에이전트의 출력을 무비판적으로 수용하는 습관이 가장 위험하다. 편해질수록 더 의식적으로 의심해야 한다.

5. 💭 도입하며 느낀 점 (정리)

사내에 Codex로 루프를 도입하면서 내가 내린 결론은 이렇다.

• 작게 시작하기. 처음부터 완전 자율 루프를 만들 생각은 아니었다. 회사에서 사내 Coding Agent로 Codex를 제공하니 거기에 주어진 토큰을 소모하기 위해 Codex 앱을 설치하고 AGENTS.md 파일을 작성하고 스킬과 서브 에이전트를 만들었다. 이후 장기 휴가를 앞두고서 팀원들에게 도움이 됐으면 하는 마음에 루프를 만들었다. 한 개의 루프가 안정적으로 돌고 신뢰가 쌓인 뒤에 범위를 넓히는 게 맞다.
• 포스트모템(Post Mortem, 회고) 스킬 구축. 루프를 설계해서 테스트를 해보면 일관성이 깨지거나 반복적인 문제가 발생한다. 나는 이 부분에 대해 각 세션에서 동작하는 workflow 마지막에 이번 세션을 회고하는 스킬을 배치하였다. Automation을 동작시키는 사람(엔지니어)이 승인하는 경우에만 workflow에 관련된 모든 Codex 관련 파일을 수정하게 된다.
• maker/checker 분리는 타협 대상이 아니다. 비용을 아끼려고 한 에이전트에 둘 다 맡기는 순간 품질이 무너진다.
• 결국 사람은 엔지니어로 남는다. 루프를 설계하고, 그 출력을 검증하고, 의심하는 역할. 자동화의 목적은 사람을 빼는 게 아니라, 사람을 반복 작업에서 빼서 판단에 집중시키는 것이다. 내가 작성한 루프에 대한 검증이 끝나면 우리 팀원들은 기술적 지식 학습에 더 시간을 투입해서 판단과 검증에 집중하게 될 것이다.

루프를 만들어라. 그리고 엔지니어로 남아라. (Build the Loop. Stay the Engineer.)

프롬프트를 던지는 데 하루를 쓰고 있었다면, 그 시간을 루프를 설계하는 데 쓰는 편이 훨씬 낫다. 나는 그 전환을 Codex로 시작했고, 앞으로 우리 팀의 모든 프로젝트에 도입할 것이며, 더 나아가서 사내 모든 프로젝트에 루프를 설계해서 도입하는 것이 목표이다.

---

참고 자료

• Addy Osmani - Loop Engineering

Codex 카테고리 내 다른 글 보러가기

첫 번째 글입니다 가장 최근 글입니다