루프 엔지니어링

🏷️ 정보 에이전트 도구

AI 코딩 도구를 쓰다 보면 한 가지 패턴에 갇힙니다. 프롬프트를 던지고, 결과를 보고, 다시 프롬프트하고, 또 결과를 봅니다. 일을 처음부터 끝까지 내가 손에 쥐고 한 턴씩 끌고 갑니다.

Addy Osmani는 이 자리에서 한 발 물러서자고 제안합니다. 글 "Loop Engineering"의 핵심 문장은 이겁니다. 에이전트를 프롬프트하는 사람 자리를 내가 비우고, 그 일을 대신할 시스템을 설계하라. 일을 찾고, 나눠주고, 검사하고, 무엇을 했는지 적어두고, 다음에 뭘 할지 결정하는 작은 시스템을 한 번 짜두는 겁니다.

이름이 루프 엔지니어링인 이유가 여기 있습니다. 프롬프트 엔지니어링이 한 번의 대화를 잘 짜는 기술이라면, 루프 엔지니어링은 그 대화를 자동으로 반복하는 고리 자체를 짜는 기술입니다. 레버리지 지점이 한 단계 위로 올라갑니다.

프롬프트에서 루프로

먼저 무엇이 바뀌는지 봅시다.

기존 방식에서 나는 운전자입니다. 에이전트에게 "이 버그 고쳐줘"라고 하고, 답을 받고, "테스트도 추가해줘"라고 하고, 다시 답을 받습니다. 매 단계가 내 입력에 묶여 있습니다. 내가 자리를 비우면 고리도 멈춥니다.

루프 방식에서 나는 설계자입니다. "매일 아침 CI 실패를 훑어서, 고칠 만한 것은 격리된 작업 공간에서 수정 초안을 잡고, 다른 에이전트가 검토한 뒤 통과하면 PR을 열어라" 같은 흐름을 한 번 정의합니다. 그다음은 시스템이 알아서 돕니다. 오스마니의 표현으로 "한 번 설계했을 뿐, 그 단계 중 어느 것도 직접 프롬프트하지 않은" 상태가 됩니다.

이게 가능하려면 고리를 이루는 부품들이 필요합니다. 오스마니는 다섯 가지를 꼽고, 여기에 기억(상태)을 더합니다. 하나씩 보겠습니다.

다섯 부품과 기억

자동화: 고리의 심장

루프는 누군가 방아쇠를 당겨야 돕니다. 그 방아쇠를 사람이 아니라 일정이 당기게 하는 것이 자동화입니다.

Claude Code에는 일정 간격으로 도는 /loop와 조건이 충족될 때까지 도는 /goal이 있습니다. OpenAI Codex 앱에는 주기를 설정하는 Automations 탭과, 발견된 일이 쌓이는 Triage 인박스가 있습니다. 핵심은 내가 수동으로 "뭐 할 거 없나" 확인하지 않아도 된다는 점입니다. 일이 알아서 표면으로 떠오릅니다.

워크트리: 병렬 격리

여러 에이전트가 동시에 코드를 만지면 충돌합니다. 두 에이전트가 같은 파일을 쓰는 상황이 대표적입니다.

git worktree는 같은 저장소 히스토리를 공유하면서도 작업 디렉터리만 분리해주는 표준 git 기능입니다. Claude Code는 git worktree, --worktree 플래그, isolation: worktree 설정으로 이를 다룹니다. Codex는 스레드마다 워크트리를 자동으로 띄웁니다. 덕분에 에이전트 여러 개를 병렬로 돌려도 서로의 작업을 덮어쓰지 않습니다.

스킬: 코드로 적은 프로젝트 지식

매번 같은 맥락을 다시 설명하는 건 큰 마찰입니다. "우리 프로젝트는 이런 컨벤션을 쓰고, 빌드는 이렇게 하고, 이 부분은 이런 history가 있어." 이걸 고리가 돌 때마다 반복할 수는 없습니다.

스킬은 SKILL.md 파일에 지침·관례·빌드 절차·프로젝트 이력을 적어두는 것입니다. Claude Code와 Codex의 형식이 동일합니다. $ 표기로 명시 호출하거나, 작업 설명에 맞으면 암묵적으로 매칭됩니다. 오스마니가 말하는 "intent debt", 즉 에이전트가 빈 지식을 자신 있는 추측으로 메우는 문제를 줄여줍니다.

이 블로그 작업 환경 자체가 좋은 예입니다. blog-publish, blog-paper-review 같은 스킬에 프론트매터 규칙과 폴더 결정 로직을 박아두면, 에이전트가 매번 규칙을 다시 떠올릴 필요가 없습니다.

플러그인과 커넥터: 도구 연결

에이전트가 코드만 고치고 끝나면 반쪽입니다. 이슈 트래커를 읽고, 데이터베이스를 조회하고, 스테이징 API를 때리고, 슬랙에 알리는 것까지 해야 고리가 닫힙니다.

이 연결은 Model Context Protocol 위에 올라갑니다. 오스마니의 비유가 정확합니다. "여기 수정안이 있어"와 "PR을 열고, Linear 티켓을 링크하고, CI가 초록불이 되면 채널에 알림을 보낸다"의 차이입니다. 플러그인은 이런 커넥터와 스킬을 묶어 팀에 배포할 수 있게 합니다.

서브에이전트: 만드는 자와 검사하는 자의 분리

한 모델이 자기 작업을 자기가 채점하면 신뢰하기 어렵습니다. 그래서 만드는 에이전트와 검증하는 에이전트를 분리합니다.

Claude Code는 .claude/agents/에 에이전트를 정의하고 팀으로 묶어 작업을 주고받게 합니다. Codex는 .codex/agents/에 TOML로 정의하며 모델과 추론 강도를 따로 설정할 수 있습니다. 전형적인 분담은 탐색(explorer) → 구현(implementer) → 검증(verifier)입니다. /goal이 내부적으로 쓰는 패턴도 이것입니다. 새 모델이 일이 끝났는지 판정합니다.

기억: 대화 밖에 두는 상태

모델은 실행 사이에 모든 것을 잊습니다. 그래서 무엇을 했고, 무엇을 시도했고, 무엇이 열려 있는지를 대화 컨텍스트가 아니라 디스크에 적어둬야 합니다.

마크다운 파일, Linear 보드, 외부 저장소 어디든 좋습니다. 오스마니의 문장이 핵심을 찌릅니다. "모델은 실행 사이에 모든 것을 잊으므로, 기억은 컨텍스트가 아니라 디스크에 있어야 한다." 이 블로그 작업에서 핸드오프 문서(raw/drafts/_handoff-*.md)를 남기는 것과 정확히 같은 발상입니다.

하루가 어떻게 도는가

부품을 다 모으면 이런 고리가 됩니다. 오스마니가 든 예시를 따라가 봅니다.

  1. 자동화가 매일 아침 한 번 돕니다.
  2. 분류(triage) 스킬이 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽습니다.
  3. 발견한 것을 마크다운이나 Linear에 적습니다.
  4. 고칠 만한 항목은 격리된 워크트리를 열고, 서브에이전트가 수정 초안을 잡습니다.
  5. 두 번째 서브에이전트가 프로젝트 스킬과 테스트에 비춰 검토합니다.
  6. 커넥터가 PR을 열고 티켓을 자동으로 갱신합니다.
  7. 처리 못 한 항목은 사람이 볼 수 있게 분류 인박스에 남습니다.
  8. 상태 파일이 다음 고리를 위해 진행 상황을 기억합니다.

"한 번 설계했을 뿐, 이 단계 중 어느 것도 직접 프롬프트하지 않았다"가 결과입니다.

고리가 빨라질수록 위험한 것들

여기까지만 보면 만능처럼 들립니다. 오스마니는 글의 절반을 경고에 씁니다. 이 부분이 글의 진짜 무게중심입니다.

검증은 여전히 내 책임입니다. 사람 없이 도는 고리는 사람 없이 실수도 합니다. 검증 서브에이전트가 "끝났다"를 의미 있게 만들어주긴 하지만, "끝났다"는 주장이지 증명이 아닙니다. 고리가 초록불을 켰다고 해서 정답이라는 보장은 없습니다.

이해 부채(comprehension debt)가 쌓입니다. 오스마니의 표현으로 "고리가 내가 쓰지 않은 코드를 빨리 내보낼수록, 존재하는 것과 내가 실제로 파악한 것 사이의 간극이 커진다." 고리의 산출물을 읽는 일은 타협 대상이 아닙니다. 빨리 도는 고리일수록 읽기를 더 해야 합니다.

인지적 항복(cognitive surrender)이 유혹합니다. 같은 고리 설계가 정반대 결과를 냅니다. 내가 이해한 일을 가속하는 데 쓰면 레버리지가 되고, 이해 자체를 회피하는 데 쓰면 독이 됩니다. 오스마니는 "편안한 자세가 위험한 자세"라고 적습니다. 고리는 사려 깊은 가속과 인지 회피를 구분하지 못합니다. 그 구분은 나만 할 수 있습니다.

토큰 비용을 경계해야 합니다. 서브에이전트는 추가 토큰을 태웁니다. 오스마니는 "토큰 비용에 반드시 주의해야 한다, 토큰이 넉넉한지 빠듯한지에 따라 사용 패턴이 크게 달라진다"고 경고합니다. 두 번째 의견이 정말 중요한 곳에만 서브에이전트를 쓰라는 이야기입니다.

결론

루프 엔지니어링의 메시지는 "고리를 짜고, 엔지니어로 남아라"입니다.

레버리지 지점이 프롬프트 설계에서 고리 설계로 옮겨간 것은 맞습니다. 그런데 일이 쉬워지는 게 아니라 더 구조적인 것이 됩니다. 똑같은 고리를 짠 두 사람이 정반대 결과를 얻습니다. 차이는 고리가 아니라 그것을 짠 사람의 의도에 있습니다. 고리 자체는 그 의도를 구별하지 못하니까요.

제 생각에는 이 글의 가치가 다섯 부품 목록이 아니라 후반부 경고에 있습니다. 자동화·워크트리·서브에이전트는 도구일 뿐이고, 어느 도구를 쓸지는 Claude Code든 Codex든 비슷합니다. 정작 중요한 건 고리를 돌려놓고 읽기를 멈추는 순간 무슨 일이 벌어지는가입니다. 검증과 이해를 남에게(혹은 고리에게) 넘기는 순간, 속도는 올라가도 내가 책임질 수 있는 범위는 줄어듭니다.

오스마니의 마지막 문장으로 정리됩니다. "고리를 짜라. 단, 그냥 시작 버튼을 누르는 사람이 아니라, 끝까지 엔지니어로 남을 사람처럼 짜라."