AI 업계에서 언젠가부터 XX 엔지니어링이라는 표현이 부쩍 자주 눈에 띕니다. XX 자리에 작년까지는 ‘프롬프트’와 ‘컨텍스트’가, 올해는 ‘하네스’와 ‘루프’가 들어갔고 최근에는 ‘그래프’도 등장했어요. 오늘은 살짝 유행이 지난(?) ‘루프 엔지니어링’에 대한 제 생각과 경험, 그리고 AX 공유회를 통해 코르카가 조직 안에서 어떻게 루프를 돌리고 있는지 공유해보겠습니다. 결론부터 말하면, 저는 ‘에이전트를 위한 루프 설계’와 ‘조직의 주간 반복 이벤트 설계’를 효과적으로 만드는 방법이 놀랍도록 닮아 있다고 생각합니다.
루프는 단순한 유행이 아닌 ‘진짜’다
아마 개발자 분들은 ‘루프’ 하면 for나 while 같은 반복문이 떠오르실 텐데요. 요즘은 휴먼 인 더 루프(Human-in-the-loop), 휴먼 온 더 루프(Human-on-the-loop), 그리고 루프 엔지니어링처럼 더 넓은 맥락에서 이 단어가 쓰이기 시작했습니다.
더 넓은 루프를 본격적으로 유행시킨 사람 중 하나가 Claude Code를 이끄는 Boris Cherny입니다. 지난 2026년 6월 17일, Cherny가 Meta의 @Scale 컨퍼런스에서 청중과 나눈 질답, 그 첫 질문도 루프에 관한 것이었어요.
“루프는 그저 다음 유행 주기(hype cycle)에 불과한가요, 아니면 진짜인가요?”
Cherny의 답은 단호했습니다.
“루프는 진짜입니다. 2년 전만 해도 우리는 소스 코드를 손으로 직접 작성했습니다. 그다음에는 에이전트가 코드를 작성하도록 전환했죠. 이제는 에이전트가 다른 에이전트에게 프롬프트를 보내고, 그 에이전트가 코드를 작성하는 단계로 넘어가고 있습니다. 소스 코드에서 에이전트로의 전환이 컸던 만큼, 루프 역시 그에 못지않게 중요하고 큰 도약입니다.”
이 말을 뒷받침하듯 요즘 주요 코딩 에이전트에는 goal 기능이 내장되어 있어 누구나 쉽게 루프를 돌릴 수 있습니다. 사용자가 입력한 프롬프트를 한 번 수행하고 끝나는 게 아니라 ‘목표’를 활성화하는 기능이죠. goal을 사용하면 에이전트는 활성화된 목표, 즉 완료 조건이 충족될 때까지 다음 할 일을 스스로 설계해 반복하게 됩니다.
코르카에서도 몇 달 전부터 goal을 굉장히 적극적으로 사용하고 있습니다. 한 저장소에서는 대담한 목표를 세워 에이전트가 몇십 시간 동안 자율 실행하는 걸 가끔씩 조율(steering)하는 일도, 다른 저장소에서는 피드백 주기가 짧은 일을 맡기는 일도 이제 당연해졌어요. 코딩하는 모습이 또 한번 크게 변한 셈입니다.
그러나 루프는 만능이 아니다
루프가 거대한 도약이라는 Cherny의 말에는 크게 공감하지만, 당연히 루프가 만능은 아닙니다. 끝나지 않는 무한 루프는 코딩할 때 가장 피하고 싶은 문제 중 하나잖아요? 저도 goal 사용 초창기에 Codex에게 “열린 이슈를 모두 닫아라” 같은 어설픈 목표를 제시했다가, 30시간이나 돌면서 토큰을 다 녹이고 있길래 강제 종료했던 기억이 나네요. 반면 오랫동안 돌 거라고 기대하며 goal을 걸어놓고 잤는데, 일어나 보니 ‘이러저러한 승인이 필요한데 3회 응답 없으니 중단했습니다’에 그쳐 있어 허탈했던 적도 많고요.
이런 실망을 피하고 루프를 더 효과적으로 설계·실행하고 싶다는 욕구 때문에 루프에 ‘엔지니어링’이라는 단어가 붙은 게 아닐까 싶어요. 그런 의미에서 제 나름대로 해석해본 효과적 루프 엔지니어링의 필요조건은 다음과 같습니다.
- 에이전트가 스스로 루프를 ‘닫을’ 수 있는 검증 도구와 권한을 적절히 제공해야 한다 (예: 문법 체크용 린터, 속도 체크용 벤치마크, 브라우저 검증용 하네스, 독립 에이전트의 리뷰 필수, 특정 URL에 대한 외부 쓰기 명시적 허용 등)
- 에이전트가 구현 완료 여부를 기계적으로 판단할 수 있어야 한다 (예: 코드 수행 시간 얼마 이하, 테스트 코드 전부 통과, 테스트 커버리지 얼마 이상 등)
- 에이전트가 구현과 검증을 되도록 적은 비용과 시간으로 수행할 수 있어야 한다 (예: 설계는 똑똑하고 느린 모델로 핑퐁, 구현은 저렴하고 빠른 모델이 병렬로 작업, 가능하다면 에이전트 대신 최대한 기계적 코드로 수행, 정지 조건과 예산 조건 등)
- 에이전트가 검증에 실패했을 때 현상이 아닌 본질을 고치며 자가개선해야 한다 (예: 단순 재시도 대신 구조적 패턴과 패턴의 패턴을 개선, 메모리가 아닌 AGENTS.md와 문서 등에 규칙으로 반영, 검증기 자체 로직과 범위도 개선 대상으로 삼기 등)
- 에이전트가 잘하고 있는지, 잘했는지 인간이 관찰/개입/리뷰하기 쉬워야 한다 (예: 의사결정과 결과를 파일로 남기게 하기, 의사결정이 필요할 때는 멈추고 묻게 하기, HTML과 Mermaid로 상태를 시각화하기 등)
사실 이 목록은 제 경험만으로 정리한 것이었는데, 찾아보니 Anthropic 루프 입문 가이드와 구글의 Addy Osmani도 비슷한 지점을 짚고 있더군요. Anthropic은 “에이전트가 결과를 보고 측정하고 조작할 수 있는 도구를 줘야 하며, 검증이 정량적일수록 스스로 검증하기 쉬워진다”, “테스트 통과 수나 점수 임계값처럼 결정론적인 기준이 그래서 효과적이다”라고 말합니다. Osmani는 Loop Engineering이라는 글에서 루프를 자동화·워크트리·스킬·커넥터·서브에이전트 5가지 요소로 해부하고, 그 아래에 대화 밖에 남는 ‘외부 메모리’를 여섯 번째 요소로 깔아둡니다.
코르카에서도 이런 조건을 잘 갖춰 루프를 더 잘 돌리는 노하우를 서로 공유하는 일이 점차 흔해지고 있어요. ‘루프를 설계한다’, ‘루프를 닫는다’ 같은 표현도 훨씬 더 자주 쓰게 됐고요. 코딩에서 쓰이던 루프 개념을 에이전트 차원으로 올려서 대화하는 게 너무나 자연스러워진 거죠.
그런데 이 5가지를 적어놓고 보니 어딘가 익숙했습니다. 코르카가 더 높은 차원, 즉 조직 차원에서도 이미 유사한 루프를 돌리고 있었더군요. 매주 목요일 아침 반복되는 AX 공유회가 그 매개체입니다.
조직에도 루프가 있었다: AX 공유회의 어제와 오늘
AX 공유회의 전신은 작년 11월 시작된 ‘에이전틱 엔지니어링 주간회고’입니다. 문라이트 팀과 함께 제품의 기술부채를 AI와 함께 갚아나가는 실천법을 나누는 데 집중했었죠. 그러나 아무래도 문라이트 팀은 제품 팀이다 보니 당장의 기능 수정과 배포가 좀 더 중요했기에, 저를 비롯해 AX 자체를 업으로 삼은 몇몇 사람이 주도하는 느낌이 강했습니다. 조금씩 코드 품질이 높아지는 환경이 갖춰지고 작은 실천도 생겼지만 변화 속도가 엄청나게 빠르진 않았어요. (당시 경험을 바탕으로 클로드 코드 밋업에서 “레거시 코드베이스에서 에이전트와 사람을 함께 일잘러로 만드는 환경 구축하기”라는 발표도 했답니다)
그래도 전사적 분위기가 점차 조성되고, 올해 2-3월에 이벤트 명칭이 ‘에이전틱 엔지니어링 공유회’를 거쳐 ‘AX 공유회’로 바뀌면서 눈덩이가 굴러가기 시작했습니다. 더 이상 특정한 누군가가 이끌거나 특정 팀만 참여하는 그림이 아니었어요. 전사 구성원이 매주 목요일 아침에 모여, 3명씩 요즘 AI와 함께 어떤 실험을 했고 어떤 시행착오를 겪었는지 공유했습니다. 자기가 새로 만들어본 도구를 자랑하며 사내에 데뷔시키는 분도 있었고요. 최근 읽은 책이나 시청한 컨퍼런스 요약, 요즘 유행하는 스킬·도구 사용기를 나누는 분도 있었습니다. 어느새 이 공유회가 코르카의 AX 저변 확대와 신규 입사자 온보딩까지 돕는 효자 이벤트가 되었어요.
AX 공유회로 조직에서 루프 돌리기
AX 공유회가 지금은 코르카에 매우 잘 정착되었지만 우여곡절도 적지 않았어요. 특히 ‘주간 반복 이벤트가 형식적인 시간이 아니라, 개인과 조직 차원에서 진정 유의미한 시간이 되려면?’에 대한 고민이 많았습니다. 그래서 초반에는 이 시간을 더 유익하게 만들기 위한 논의와 실험으로 포맷을 진화시켜 나갔습니다.
이런 과정을 거쳐 안정된 2026년 8월 기준 AX 공유회 포맷은 다음과 같습니다. 정확히 1시간 동안 합니다.
- 지난 공유회 회고 때 적은 ‘다음 일주일간 시도해볼 것’을 정말 실천했는지, 어떻게 실천했는지, 그 외 하고 싶은 이야기 등을 자유롭게 나눕니다.
- 이번 주 공유자 3명이 자기 이야기를 공유하고, ‘요거 하나 실험/시도해보세요!’를 남깁니다.
- 각자 회고하며 오늘의 감상과 함께 ‘다음 일주일간 시도해볼 것’을 적습니다.
표면적으로는 2번이 핵심으로 보이지만 사실 2번은 미끼 상품이고, 그걸 둘러싼 1번과 3번이 중요했습니다. 그래야 이게 누군가가 주도하는 ‘세미나’가 아닌 모두가 함께하는 ‘공유회’가 되고, 개인과 조직이 꾸준히 성장할 수 있으니까요. 그래서 AX 공유회에는 3가지 타이밍에 사용되는 문화 겸 장치가 점진적으로 발전했습니다.
- 공유회 종료: 회고할 때 ‘시도해볼 것’을 작고 명확하게 적지 않으면 은근히 핀잔을 듣습니다. (예: “A님 이거 정말 하실 수 있나요?” “B님 회고에 시도할 게 없는데요?” “C님 이거 완료했는지 어떻게 알죠?”)
- 공유회 사이: 코르카의 에이전트 동료 Ceal이 회고 내용을 바탕으로 리마인드 메시지를 보냅니다. 다음날에는 뭘 하기로 했는지 정리해서 스레드를 열고, 여기에 :done: 표시나 댓글을 달지 않은 사람들에게는 최대 2번 DM을 보내 “이렇게 작게라도 해보세요”라며 말을 걸어요. 가끔 Ceal이 고장 나서 메시지를 못 보낼 때면 구성원들이 농담 삼아 “Ceal 잡도리가 안 와서 못 했다”는 핑계를 대시곤 하더군요.
- 공유회 시작: 대놓고 한 명 한 명 물어봅니다. “하셨나요? 어떤 거 하셨나요? 왜 못하셨나요? 몇 주째 못하셨네요? 이번 주에는 어떻게 하실래요?” 솔직히 이게 상당한 압박이라, 목요일 아침에 부랴부랴 조금이라도 시도하는 분들이 있어요. 죄송한 마음도 들지만 저는 긍정적인 부수 효과라고 생각합니다. ‘목요일은 뭔가 시도하는 날’이라는 작은 공통 습관이 생긴 것으로도 볼 수 있고요.
그리고 이러한 AX 공유회의 포맷과 장치들은 위에서 얘기했던 ‘효과적 루프 엔지니어링의 필요조건’과 상당히 닮아 있습니다.
| 효과적 루프의 필요조건 | 에이전트 루프에서는 | AX 공유회에서는 |
|---|---|---|
| ① 루프를 닫을 검증 도구와 권한 | 린터, 테스트, 벤치마크, 브라우저 하네스, 독립 에이전트의 리뷰 | 목요일 아침에 한 명 한 명 “하셨나요?” 묻는 시간, Ceal이 반응 없는 사람에게 DM 보내기 |
| ② 기계적인 완료 판단 | 테스트 전부 통과, 커버리지 N% 이상 | 공유회 시작과 끝의 긍정적 + 조직적 압박 |
| ③ 적은 비용과 시간 | 설계는 느린 모델, 구현은 빠른 모델 병렬, 정지 조건과 예산 | 1시간 고정, 공유자는 3명만, 이미 쓰는 슬랙 위에서 굴러가게 하기. 그리고 Ceal과 동료가 “이렇게 작게라도 해보세요”라며 시도 단위 자체를 계속 줄여주기 |
| ④ 실패시 본질을 고치기 | 재시도 대신 패턴을 고치고 AGENTS.md와 문서에 규칙으로 반영 | 같은 사람이 계속 못 하면 그 사람을 더 재촉하는 대신 포맷과 장치(핀잔, Ceal, 시작 질문)를 고쳐 다음 주 공유회에 반영하기 |
| ⑤ 관찰·개입·리뷰 가능성 | 의사결정과 결과를 파일로 남기기, 상태 시각화 | 회고와 시도를 공유회 노션과 슬랙 스레드에 남겨 사람들이 가장 자주 보는 곳에 모아두기 |
표를 채우면서 저도 새로 알아차린 건 ①과 ④입니다. 내 회고를 내가 채점하지 않고 목요일 아침에 동료가 물어봐 주는 건 구현 에이전트와 리뷰 에이전트 분리와 같은 구조였어요. 그리고 누군가 몇 주째 시도하지 못하고 있을 때 그 사람을 더 재촉하는 대신 ‘우리 포맷이 무엇을 놓쳤나’를 따져 장치를 고쳐온 것은, 실패를 개별로 때우지 않고 규칙에 반영하는 일에 가깝습니다. 실제로 Ceal의 리마인드나 공유회 시작 질문도 그렇게 하나씩 생겨난 장치예요.
끼워 맞춘 걸로 보일 수도 있겠지만 저는 이 유사성이 우연이 아니라고 생각해요. 두 경우 모두 ‘자율적으로 움직이는 주체에게 명확한 완료 기준과 피드백을 주는 문제’이기 때문입니다. 주체가 사람이든 에이전트든, 기준과 피드백이 없으면 끝나지 않는 루프에 빠지거나 흐지부지 종료되거든요. 그래서 루프를 돌리는 에이전트와 인간 모두에게 적절한 도움이 필요합니다.
맺으며
루프의 본질은 오래 돌리는 데 있지 않습니다. 인간의 명확한 의도를 에이전트가 훌륭히 대행해, 더 짧은 시간에 원하는 품질로 작업이 완료되는 게 중요합니다. 그러려면 실행 주체(인간과 에이전트의 역량)와 환경(루프 엔지니어링 방법론) 모두 꾸준히 발전시켜야겠죠.
마찬가지로 조직의 주간회의, 1:1, AX 공유회 같은 반복 이벤트의 본질은 그 형식이 유지되는 게 아니라 그 이벤트를 통해 달성하고자 했던 목적이 충실히 이행되는 데 있습니다. 목적 달성에 드는 시간과 에너지는 점차 줄어들어야 하고, 그러려면 실행 주체와 환경이 함께 발전해야 하죠. 현재의 AX 공유회 또한 2026년 8월 어느 날의 스냅샷에 불과하니 앞으로도 재미있는 실험과 시도를 계속할 예정입니다.
여러분 조직의 반복 이벤트에는 ‘닫는 조건’이 있나요? 에이전트를 위한 루프 엔지니어링 철학 중 개인이나 조직에는 미처 적용하지 못한 게 있는지 한번 돌이켜보셔도 좋겠습니다.