Loop Engineering, kaji로도 할 수 있습니다

최근 AI coding agent 주변에서 Loop Engineering이라는 용어를 자주 접하게 되었습니다.

간단히 말하자면, 인간이 매번 프롬프트를 입력하는 것이 아니라, AI agent가 작업, 리뷰, 수정, 검증을 수행하도록 하는 loop를 설계한다는 이야기입니다.

이 흐름은 kaji에서도 상당히 유사한 일을 하고 있습니다.

kaji에서는 설계, 리뷰, 수정, 검증을 workflow로서 연결하여, AI 개발 loop로서 실제로 운용하고 있습니다. 그리고 그 메커니즘은 OSS로서 공개하고 있습니다.

kaji는 무엇을 하고 있는가

kaji는 Claude Code / Codex / Gemini CLI와 같은 agent CLI를 YAML로 정의된 workflow에 따라 실행하는 경량 harness입니다.

이전에 공개한 기사에서는 kaji를 "AI 주도 개발의 설계·구현·검증 플로우를 연결하는 harness"로 소개했습니다.

당시부터 중심에 있었던 것은 단발적으로 AI에게 코드를 작성하게 하는 것이 아니었습니다.

• 설계한다
• 설계를 리뷰한다
• 지적이 있으면 수정한다
• 구현한다
• 코드 리뷰를 한다
• 지적이 있으면 수정한다
• 검증한다
• PR을 만든다

이 일련의 흐름을, 중간 실패나 리뷰 반려를 포함하여 재실행 가능한 workflow로서 다루는 것이었습니다.

즉, kaji는 "AI에게 무언가를 한 번 시키는 도구"라기보다, AI를 포함한 개발 loop를 운용하기 위한 harness입니다.

실제 workflow

현재 kaji에서는 통상적인 운용 workflow를 .kaji/wf/ 하위의 5개로 정리하고 있습니다.

workflow	용도
dev.yaml	표준 개발 workflow
dev-thorough.yaml	정밀 버전 개발 workflow
docs.yaml	docs-only 작업
dev-local.yaml	GitHub 장애 시 등의 local fallback
docs-local.yaml	docs-only의 local fallback

예를 들어, kaji 자신의 개발에서 표준적으로 사용하는 dev.yaml은 다음과 같은 형태입니다.

전체를 한 장으로 그리면 작아지므로, 설계, 코드 리뷰, PR review의 3가지로 나눕니다.

이를 YAML로 정의하면, 우선 loop는 다음과 같습니다.

name: dev
description: |
개발 작업의 표준 workflow. GitHub Issue로부터 PR review / close까지 진행한다.
...

설계 측의 step은 다음과 같습니다.

steps:
- id: design
skill: issue-design
...

코드 리뷰 측도 동일한 구조입니다.

- id: implement
skill: issue-implement
agent: claude
...

나아가, PR 생성 후의 review 수렴도 동일한 workflow에 포함되어 있습니다.

- id: pr
skill: i-pr
agent: claude
...

여기서 중요한 것은 단순히 step을 순서대로 나열한 것이 아니라는 점입니다.

• cycles로 review / fix / verify의 loop를 선언한다
• max_iterations로 loop의 상한을 결정한다
• on_exhaust: ABORT로 수렴하지 않는 loop를 중단한다
• PASS / RETRY / BACK / ABORT의 verdict로 다음 전이를 결정한다
• resume으로 전 단계의 agent session을 계속한다 - Claude와 Codex를 공정별로 구분하여 사용한다
• review-poll과 같은 결정론적인 step은 exec로서 실행한다

이것은 바로 "AI 개발 loop를 어떻게 설계하고, 어떻게 멈추고, 어떻게 검증할 것인가"라는 문제입니다.

Loop Engineering 이야기와 어느 부분이 겹치는가

Addy Osmani의 "Loop Engineering"에서는 loop에 필요한 요소로서 automation (자동화), worktree (워크트리), skills (기술), plugins/connectors (플러그인/커넥터), sub-agents (서브 에이전트), state/memory (상태/메모리) 등을 정리하고 있습니다.

kaji는 이 모든 것을 내장한 거대한 orchestrator (오케스트레이터)가 아닙니다. 오히려 그 반대로, 가능한 한 얇은 workflow harness (워크플로 하네스)로 만들었습니다.

그러면서도 실무에서 필요로 하는 부품들은 상당히 갖추고 있습니다.

관점	kaji에서의 대응
loop	cycles로 review/fix/verify를 반복
feedback	review / verify / verdict로 다음 전이를 결정
stop condition	max_iterations / on_exhaust로 중단
skills	각 step의 실무를 skill (기술)로 분리
state	run state / artifact / log / Issue 코멘트 사용
model assignment	공정별로 Claude / Codex / Gemini CLI를 할당
deterministic step	review-poll과 같이 exec를 통해 LLM을 거치지 않는 step 삽입
human steering	workflow (워크플로)와 skill은 인간이 설계

특히 강하게 의식하고 있는 점은 maker (제작자)와 checker (검사자)를 분리하는 것입니다.

예를 들어 구현은 Claude Code에 맡기고, 설계 리뷰나 코드 리뷰는 Codex에 맡깁니다. 나아가 review와 verify도 분리합니다.

review는 새로운 지적 사항을 찾는 공정입니다.

verify는 직전의 지적 사항이 수정되었는지 확인하는 공정입니다.

이 둘을 분리하지 않으면, AI가 매번 새로운 지적 사항을 만들어내어 loop (루프)가 끝나지 않는 경우가 발생할 수 있습니다.

따라서 kaji에서는 단순히 "리뷰한다"가 아니라, 지적을 하는 review와 직전의 지적 사항이 수정되었는지 확인하는 verify를 나누어 두고 있습니다.

운용 실적이 있다

kaji의 강점은 이름의 참신함이 아니라, 실제 개발에 사용하면서 조금씩 안정화해 온 workflow harness (워크플로 하네스)라는 점입니다.

현행 kaji의 전신에 해당하는 legacy/bugfix_agent v5에서도, 2025-12-04부터 2025-12-06에 걸쳐 E2E 시도를 거듭하며 IMPLEMENT_REVIEW까지 도달하면서, VERDICT의 parse error (파싱 에러)나 Codex의 resume 주변 문제들을 해결해 나갔습니다.

이 단계에서의 지견이 지금의 verdict, resume, loop limit, maker/checker 분리로 이어지고 있습니다.

예를 들어, 주요 부품들은 다음과 같은 시기부터 도입되었습니다.

부품	최초 등장 시점 (기준)	운용상의 역할
legacy/bugfix_agent v5	2025-12-04~12-09	전신 구현에서 loop / verdict / reviewer 분리 과제를 확인
VERDICT	2025-12-27	step의 판정 출력 규약
resume	2026-01-13	이전 session (세션)의 지속
cycles	2026-01-27	review/fix/verify loop
max_iterations / on_exhaust	2026-03-09	loop의 정지 조건
kaji 공개 기사	2026-03-23	workflow harness로서 공개

이후에도 exec를 통한 deterministic step (결정론적 단계), --before를 통한 정지 위치 제어, review-poll, interactive_terminal runner, #247에서의 workflow 5종화 등을 도입했습니다.

즉, kaji는 단순히 "loop를 정의할 수 있습니다"라고 말하는 것에 그치지 않고, 실제로 돌려보고, 막히는 부분을 고치며, 운용하기 쉬운 형태로 정리해 온 것입니다.

Loop Engineering라는 용어는 2026년 6월경부터 눈에 띄게 언급되기 시작했습니다. Addy Osmani 님의 기사는 2026-06-07에 공개되었습니다.

관련된 용어로서, OpenAI는 2026-02-11에 harness engineering 기사를 게시했습니다.

이 기사에서는 harness engineering 전체가 아니라, loop engineering이라는 용어로 최근 논의되고 있는 실무상의 부품, 즉 review/fix/verify 루프(loop), verdict, resume, stop condition에 집중하여 살펴봅니다.

3월 기사로부터 추가된 것

3월에 공개한 kaji 기사에서도 몇 가지 중요한 기능이 추가되었습니다.

deterministic step (결정론적 단계)

LLM에게 판단을 맡길 필요가 없는 처리는 에이전트(agent)를 구동하지 않고 스크립트(script)로서 실행할 수 있습니다.

예를 들어 review-poll은 PR review를 폴링(polling)하는 deterministic step으로서 워크플로(workflow)에 포함할 수 있습니다.

- id: review-poll
exec: [kaji, pr, review-poll]
on:
...

모든 것을 LLM에 넘길 필요는 없습니다.

오히려 결정론적(deterministically)으로 할 수 있는 부분은 일반적인 프로그램에 맡기는 편이 루프(loop) 전체의 안정성을 높입니다.

--from 및 --before

중간부터 재개하고 싶을 때는 --from을 사용합니다.

kaji run .kaji/wf/dev.yaml 57 --from fix-code

사람의 리뷰를 위해 특정 단계(step) 직전에서 멈추고 싶을 때는 --before를 사용할 수 있습니다.

kaji run .kaji/wf/dev.yaml 57 --before implement

PR review만 돌리고 싶은 경우에도 전용 YAML을 늘리지 않고 중간 구동으로 처리합니다.

# review-poll부터 close까지 진행
kaji run .kaji/wf/dev.yaml 57 --from review-poll
# review loop만 돌리고, close 직전에서 멈춤
...

이는 사소해 보일 수 있지만, 실제 운용에서는 상당히 중요합니다.

AI 루프(loop)를 만들 때 필요한 것은 '알아서 전부 하는 것'만이 아닙니다. 어디서 시작하고, 어디서 멈추며, 사람이 어디를 확인해야 하는지를 제어할 수 있는 능력도 필요합니다.

interactive terminal runner (대화형 터미널 러너)

헤드리스(headless) 상태로 에이전트(agent)를 흘려보내기만 하면 무슨 일이 일어나고 있는지 파악하기 어려워집니다.

그래서 interactive_terminal 러너(runner)에서는 tmux pane 위에서 Claude / Codex를 구동하여, harness progress나 heartbeat를 볼 수 있도록 했습니다.

이는 tmux를 사용하는 러너(runner)이므로 tmux가 필수입니다. Windows 네이티브 환경에서는 그대로 동작하지 않으며, WSL 등 tmux가 동작하는 환경이 필요합니다.

[execution]
agent_runner = "interactive_terminal"
interactive_terminal_close_on_verdict = true

전용 대시보드(dashboard)가 따로 있는 것은 아닙니다.

다만 긴 루프(loop)를 돌릴 때 "지금 어느 단계(step)이며, 어떤 에이전트(agent)가 무엇을 하고 있는지"를 볼 수 있는 것만으로도 운용 편의성이 크게 달라집니다.

실제 운용에서 사용 중

이것은 만들고 끝나는 장난감(toy)이 아니라, kaji 자신의 개발을 kaji로 돌리고 있습니다.

GitHub Issue를 보면 설계, 구현, 리뷰, 수정, 검증을 Issue를 기점으로 진행하고 있는 모습을 확인할 수 있습니다.

나아가, 또 다른 개인 운용 프로젝트인 kamo2에서도 사용하고 있습니다.

kamo2는 주가 분석 계열의 대시보드(dashboard)로, 개인 운용상의 운영 환경(production-equivalent environment)에서는 PostgreSQL의 메타데이터 상에서 다음과 같은 규모를 가지고 있습니다.

항목	규모
DB size	약 220 GB
...	raw schema
약 187 GB / 약 2.31억 행
analytics schema
약 33 GB / 약 3,019만 행

또한, 코드 측도 대략 다음과 같은 규모입니다.

항목	규모
Alembic migration files	79
...
물론, 이것은 거대한 서비스는 아닙니다.

하지만, 적어도 "작은 샘플에서 동작했다" 수준에 그치는 것이 아니라, DB도 코드도 어느 정도 규모가 있는 개인 운영 프로젝트에서 AI 개발 루프 (development loop)를 돌리기 위해 사용하고 있습니다.

kaji가 대응하고 있는 리스크

Loop Engineering 이야기에서 중요한 것은 편리함만이 아닙니다. 오히려 루프 (loop)가 강력해질수록 위험한 부분도 늘어납니다.

kaji에서는 그 부분을 워크플로 (workflow) 측에서 최대한 다룰 수 있도록 하고 있습니다.

리스크	kaji 측의 대응
했다고는 하지만 검증되지 않음	review와 verify를 분리하고, verdict로 전이함
...	max_iterations / on_exhaust로 중단
어디서 무엇이 일어났는지 알 수 없음	artifact / log / interactive terminal로 관측
전부 LLM에 넘겨서 불안정해짐	exec / exec_script로 결정론적 단계 (deterministic step)를 혼합

이 부분은 OpenAI의 harness engineering 이야기와도 상당히 유사합니다.

OpenAI의 기사에서는 인간은 코드를 직접 작성하기보다 환경, 의도, 피드백 루프 (feedback loop)를 설계하는 방향으로 역할이 이동한다는 이야기가 나옵니다.

Anthropic의 "Building effective agents"에서도 완전 자율 에이전트 (agent)뿐만 아니라, 미리 정해진 워크플로 (workflow)에 LLM을組み込む(組み込む, 결합하는) 형태가 정리되어 있습니다.

Martin Fowler / Thoughtworks의 harness engineering 기사도, 코딩 에이전트 (coding agent)를 사용하는 측이 가이드 (guide)나 센서 (sensor)를 설계한다는 관점에서 상당히 참고가 됩니다.

최근의 용어로 말하자면 loop engineering입니다만, 실무상으로는 workflow, harness, context, verification, observability를 어떻게 조합할 것인가의 문제라고 생각합니다.

아직 부족한 점

솔직히 kaji는 아직 작은 OSS입니다.

현 시점에서 "무엇이든 할 수 있는 AI 오케스트레이터 (orchestrator)"는 아닙니다.

아직 미흡한 부분은 있습니다.

• scheduled automation은 주 목적이 아님
• 복수 worktree의 병렬 오케스트레이션 (orchestration)은 아직 약함
• 병렬 sub-agent 오케스트레이션 (orchestration)은 아직 미흡함
• 전용 observability dashboard는 없음
• 커넥터 (connector) 군을 내장하기보다, Claude Code / Codex / Gemini CLI 측에 위임하고 있음

이 부분은 오히려 향후 키워나가고 싶은 부분입니다.

특히 원하는 기능은 다음과 같습니다.

• 워크플로 (workflow)의 시각화
• 실행 이력 (run history)의 보기 쉬운 UI
• 복수 worktree의 병렬 실행
• review / verify의 품질을 측정하는 메커니즘
• GitHub / Linear / Slack 등과의 커넥터 (connector) 정리
• 실패한 루프 (loop)의 분석 지원

요약

Loop Engineering이라는 용어는 새롭습니다.

하지만 거기서 이야기되는 "AI에게 단발성으로 작업을 시키는 것이 아니라, 작업, 리뷰, 수정, 검증을 루프 (loop)로서 설계한다"는 문제는 kaji에서 계속 다루어 온 것입니다.

kaji는 만능이 아닙니다.

다만, 실무에서 AI 개발 루프 (development loop)를 돌리기 위해 필요해지는 부품, 즉 workflow, cycle, verdict, resume, stop condition, deterministic step, log, human steering은 상당히 포함되어 있습니다.

만약 이와 마찬가지로, AI coding agent (AI 코딩 에이전트)를 단발성 이용에서 한 단계 더 나아가 운영 가능한 개발 loop (개발 루프)로 정비하고 싶다면, kaji를 시도해 주시면 감사하겠습니다.

사용해 보시고 부족한 점, 이상한 점, 혹은 '이러한 loop (루프)를 돌리고 싶다'는 이야기가 있다면, Issue (이슈)나 PR (Pull Request)을 통해 피드백을 주시면 큰 도움이 됩니다.

참고

• Addy Osmani, "Loop Engineering"

https://addyosmani.com/blog/loop-engineering/ - OpenAI, "Harness engineering: leveraging Codex in an agent-first world"

https://openai.com/index/harness-engineering/ - Anthropic, "Building effective agents"

https://www.anthropic.com/engineering/building-effective-agents - Martin Fowler / Thoughtworks, "Harness engineering for coding agent users"

https://martinfowler.com/articles/harness-engineering.html - LangChain, "Improving Deep Agents with harness engineering"

https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering - Stripe, "Minions: Stripe's one-shot, end-to-end coding agents"

https://stripe.com/blog/minions-stripes-one-shot-end-to-end-coding-agents

Discussion