발표자 Kyle는 AI 코딩 에이전트를 "루프(loop)"로 반복 실행해 소프트웨어를 만드는 최근 업계 흐름을 비판적으로 진단하고, 제어 이론(control theory)의 원리를 적용해 "실제로 팀에서, 실제 고객·규제·SLA가 있는 대규모 코드베이스에서" 안전하게 작동하는 루프를 설계하는 구체적 방법론을 HumanLayer의 실제 사례(RPC→Effect 마이그레이션)로 시연한다.
1계층 — 핵심 주장
- 지금 업계 전체가 "루프"를 잘못 만들고 있다. 프롬프트를 코딩 에이전트에 파이프로 흘려보내는 방식만으로 소프트웨어를 만들 수 있다는 믿음이 과대포장(hype)되어 있으며, 검증기(verifier)나 코드 리뷰 에이전트를 여럿 붙여도 결국 "아무도 읽고 싶어 하지 않는 4만 줄짜리 PR"을 계속 찍어내는 구조에서 벗어나지 못한다.
- "랄프(Ralph)" 방식(Geoffrey Huntley가 제안한, bash 반복문으로 코딩 에이전트에 프롬프트를 계속 밀어 넣는 기법)은 그 자체로 나쁜 게 아니라 특정 조건(1인 개발, 팀 작업 아님, 중요 시스템 아님)에서만 잘 맞는 날카로운 도구다. 실제 고객·실제 사용자·규제 의무·SLA가 있는 "팀 단위" 대규모 코드베이스에는 이 전제가 맞지 않는다.
- 해법은 "제어 이론(control theory)"을 명시적으로 적용한 "제어 루프(control loop)"를 설계하는 것이다. 목표 상태(setpoint) → 현재 상태 측정(센서) → 오차 계산 → 점진적 변경 신호 생성(컨트롤러) → 변경 적용(액추에이터) → 재측정, 의 피드백 루프 구조를 코드베이스 개선에 그대로 적용해야 "맹목적인 랄프 루프(blind Ralph loop)"의 정반대, 즉 점진적이고 안전하며 사람이 실제로 검토 가능한 루프를 만들 수 있다.
- 루프는 코드 품질/마이그레이션뿐 아니라 API 스펙 준수, MCP 스펙 준수, 언어 간 미러링, 포크 유지보수 등 "측정 가능하고, 점진적으로 바꿀 수 있고, 변경 결과에 대한 피드백을 받을 수 있는" 모든 문제에 범용적으로 적용 가능한 패턴이다.
- 실전에서 루프가 실패하는 이유는 대개 "컨트롤러 설계"와 "흐름 제어(flow control)"의 부재 때문이다. 사람이 잠깐 자리를 비우거나 스킬을 매번 수동으로 고쳐야 하면 루프는 곧 골칫거리(마찰, 중복 PR, 밀린 리뷰)가 되어 결국 꺼지게 된다. 이를 막는 구체적 장치(PR 라벨, 열린 PR 존재 시 스킵, 버전관리되는 피드백 파일, 댓글 트리거)가 있어야 실제로 지속 가능하다.
2계층 — 근거 / 논리 구조
2-1. 왜 지금의 "루프 열풍"이 문제인가 (배경 진단)
- 이 발표가 다루는 원본 포스트는 사실 작년 7월에 올라온 것이었지만, 올해 1월 입소문을 타면서 업계에 "루프 만들기" 붐이 시작됐다.
- 최근에는 Peter Steinberg(발표 자막상 표기, 실제로는 코딩 에이전트/에이전트 루프 논의로 유명한 Peter Steinberger로 추정)가 "더 이상 코딩 에이전트에 프롬프트를 직접 넣지 말고, 에이전트에게 프롬프트를 넣는 루프 자체를 설계해야 한다"고 말했고, Claude Code의 창시자 Boris Cherny(자막 "보리스 테르니")는 "엔지니어로서 내 유일한 업무는 이제 Claude에게 명령을 내리는 루프를 작성하는 것"이라고 말했다.
- 발표자는 이 흐름을 극단으로 밀어붙이면 결국 "에이전트 무리가 루프를 설계하고, 그 루프를 위해 또 다른 에이전트 무리를 만드는" 재귀적 자동화로 귀결되며, 이 과정에서 생성되는 코드량이 너무 많아 "아예 읽지 않는 게 낫다"는 암묵적 태도로 이어진다고 지적한다. 즉 검증·코드리뷰에는 투자하지만 실제로는 그 코드를 읽기 전용(read-only)으로만 취급하는 역설적 상황이 발생한다.
- 프론티어 랩(최상위 AI 연구소)들은 이것이 "10배 빠르게 움직이고 나머지는 뒤처지는" 소프트웨어 개발의 미래라고 믿지만, 발표자는 "현재로선 이게 얼마나 효과적인지 확실하지 않다"고 유보적 입장을 취한다.
- 비용 문제: Claude Code 터미널의 깜빡임(flicker) 버그를 고치는 데 6개월이 걸린 반면, 오픈소스 진영(자막상 "오픈 클로"로 표기됐지만 문맥상 오픈소스 코딩 에이전트 CLI인 OpenCode 계열로 추정)은 훨씬 짧은 시간에 자체 렌더러를 새로 작성했다. 다만 이 오픈소스 도구 역시 안정성 문제로 악명이 높다. 결론적으로 프론티어 랩 소속이거나 토큰 예산이 무제한이 아니라면, 이런 식의 코드 생성은 "엄청나게 비싼" 접근이다. Matt Pocock(자막 "맷 포콕")도 최근 "에이전트 시대에는 나쁜 코드의 비용이 과거보다 훨씬 커졌다"고 언급했다.
2-2. 제어 이론의 기본 구조 (핵심 프레임워크)
발표자는 이 논의를 관통하는 핵심 프레임워크로 제어 이론(control theory)을 제시한다. 제어 이론은 "동적 시스템(코드베이스)을 원하는 안정적/최적의 최종 상태로 이끄는 방법"이며 다음 요소로 구성된다:
- 센서(Sensor): 세상의 현재 상태를 측정.
- 기준점(Setpoint): 내가 원하는 바람직한 상태.
- 측정 오차(Error): 현재 상태와 기준점의 차이.
- 컨트롤러(Controller): 측정 오차를 읽어, 시스템에 적용할 "증분 변화(incremental change)"에 대한 제어 신호로 변환.
- 액추에이터(Actuator): 그 제어 신호를 실제 시스템 변화로 적용.
- 이후 시스템은 교란(disturbance)을 겪고, 다시 측정 → 오차 재계산 → 처음으로 돌아가는 피드백 루프가 반복된다.
- 일상 예시: 온도조절기(에어컨)의 제어 루프, Kubernetes 오토스케일링, IaC(코드형 인프라: 원하는 상태/현재 상태/점진적 변경), Postgres의 오토배큠(autovacuum), React의 가상 DOM 모두 제어 루프 혹은 그와 유사한 패턴을 사용한다.
- 제어 루프가 이상적으로 작동하는 조건: (1) 바꾸고 싶은 시스템이 있고, (2) 측정 가능한 문제가 있으며, (3) 변경 결과에 대한 피드백을 얻을 방법이 있을 때.
- 훌륭한 엔지니어는 항상 "점진적으로 시스템을 바꾸는 것"을 지향하며, 한 번에 최종 상태로 도약하려다 모든 걸 망가뜨릴 위험을 감수하지 않는다. 이런 장치들은 과도한 조정으로 인한 시스템 불안정화를 막고 위험을 최소화한다.
- 결론: 제어 루프는 "맹목적인 랄프 루프(blind Ralph loop)"의 정반대 개념이다. 다만 모든 랄프 루프가 맹목적인 건 아니며, 최고의 랄프 실천자들은 실제로 제어 이론을 내재적으로 적용하고 있다. 랄프는 어디까지나 "교육용 도구"인데 일부가 그것을 너무 문자 그대로(literal) 받아들이는 것뿐이고, 사실 이것이 우리가 항상 루프를 만들어온 방식이다. 랄프 루프의 진짜 약점은 "점진적이지 않다"는 것, 즉 단순 반복일 뿐이라는 점이다.
2-3. 에이전틱 제어 루프를 만드는 단계별 절차 (일반 방법론)
- 기준점(setpoint) 정의: 코드베이스의 특정 속성에 대해 원하는 최종 상태를 정의.
- 센서(sensor) 추가: 결정론적(ESLint 규칙, AST grep, 패키지 작업 등) 또는 비결정론적(에이전트+스킬+자연어 규칙) 방식, 혹은 둘을 조합한 파이프라인으로 구성 가능.
- 하이브리드 사례: Airbnb의 "React Doctor"는 센서+컨트롤러가 결합된 도구로, React 코드의 모든 문제점을 알려주고 그중 가장 먼저 고쳐야 할 3가지와 수정 방법까지 제시한다.
- 컨트롤러/액추에이터 설계: 경우에 따라 단일 에이전트가 같은 컨텍스트 창 안에서 점진적 변경을 결정하고 바로 적용할 수도 있지만, 발표자는 컨트롤러를 별도로 정교하게 설계할 것을 강조한다. 컨트롤러가 없거나 잘 조율되지 않으면 한 번에 너무 큰 변화 혹은 완전히 잘못된 변화를 만들 수 있고, 이를 무한 루프에 넣으면 금방 문제가 커진다.
- 루프의 범용성: 나쁜 패턴 정리뿐 아니라 — 외부 OpenAPI 스펙 준수 확인, 현재 사용 중인 MCP 스펙 버전 준수 확인, Python↔TypeScript 프로젝트 미러링, 업스트림 대비 자체 포크(V 기반 Next.js 포크 예시) 유지보수 등에도 동일 패턴을 쓸 수 있다.
- 핵심 질문 3가지: 측정 가능한 것을 찾을 수 있는가? 점진적으로 적용할 수 있는가? 변경 품질에 대한 피드백을 받을 수 있는가?
2-4. HumanLayer 실전 사례: RPC → Effect 마이그레이션 루프 (구체적 실행 논리)
- 배경: HumanLayer는 사내 RPC API를 "Effect"(TypeScript 라이브러리, 특유의 독특한 문법)로 점진적으로 마이그레이션 중. 처음에는 레이스 컨디션이 발생하기 쉬운(자막상 "인종 차별적인" 코드로 오역됨 — 원문은 "race-prone code") 일부 코드에 도입했다가 마음에 들어서 전체 코드베이스로 확대하기로 결정.
- 1단계: 센서 구축 — 마이그레이션되지 않은 프로시저를 찾는 센서. grep/ripgrep이나 에이전트도 쓸 수 있지만, 언어에 구애받지 않고 TypeScript 설정/ESLint 규칙과 무관하게 동작하는 AST grep을 채택. (참고: TypeScript 개발자라면 Claude가 인라인 주석으로 ESLint 규칙을 몰래 비활성화하는 것을 본 적이 있을 텐데, AST grep은 이런 "우회"에 영향받지 않는다.) 패턴 기반 규칙을 만들고, 시간이 지나며 포함/제외 경로가 세분화된 규칙을 계속 추가. 다국어 모노레포에서도 모든 언어에 대해 작동.
- 위반 목록 정리: 스캔 결과 위반 건당 약 50개 키(key)에 달하는 방대한 목록이 나와 이를 4개 키로 추려 결정론적으로 정렬.
- "교란 감쇠기(disturbance dampener)" — 실용적 우회: 기존 프로시저를 점진적으로 옮기기 전에, 먼저 "모든 신규 프로시저는 Effect를 쓰도록 강제"해야 한다. 이를 위해 main 브랜치에서 전체 스캔을 한 번 실행해 모든 위반사항을 결정론적으로 정렬해 버전관리 시스템에 기록하고, 이후 새 PR이 생성될 때마다 해당 브랜치가 마이그레이션되지 않은 프로시저를 추가했는지 확인한다. 여기서 "교란(disturbance)"은 팀원들이 계속 코드를 배포하는 행위이며, 이 장치는 팀원들이 루프의 성과를 되돌리지 않도록 보장하는 역할(엄밀한 제어 루프 요소는 아니지만 "교란 감쇠기"라 부를 만함)을 한다.
- 2단계: 컨트롤러 설계 (출혈이 멈춘 뒤 진행) — 단순한 컨트롤러는 위반 목록에서 결정론적으로 첫 항목을 선택(bash+JQ 등)하거나, 더 영리하게는 AST grep으로 "가장 작은 미마이그레이션 프로시저"를 항상 선택해 위험을 낮춘다. 원한다면 에이전트에게 선택을 맡길 수도 있으나(발표자는 결정론적 코드의 역할을 에이전트에 맡기는 것에 신중한 입장), 복잡도에 따라 에이전트가 마이그레이션 절차를 선택하고 동시에 처리하게 할 수도 있다.
- 더 정교한 컨트롤러: 단순 1:1 마이그레이션을 넘어 실제 코드 개선을 이끌어내기 위해, 원격 측정(telemetry) 데이터를 분석해 어떤 프로시저에 오류가 가장 많은지, 계측(instrumentation)이 가장 부족한지, APM에 공백이 있는지를 파악하고, 액추에이터 에이전트에게 제어 신호를 보낼 때 마이그레이션 대상 프로시저뿐 아니라 "이 마이그레이션으로 고치려는 문제"에 대한 전체 데이터까지 함께 전달한다.
- 3단계: 액추에이터 구축 — 에이전트 + 스킬의 조합. 원하는 CLI 코딩 에이전트를 사용하되 스킬을 다듬는 데 상당한 시간을 투자해야 하며, 처음부터 완벽할 필요 없이 효과가 검증된 방식으로 점진 개선한다. HumanLayer는 에이전트 실행 전에 "골든 패턴(golden pattern)" — 에이전트가 그대로 따라 할 수 있는 관용적(idiomatic) 손수 작성 예시 — 을 수작업으로 미리 만들어두는 방식을 선호한다. 이렇게 하지 않으면 에이전트가 문서나 인터넷에서 학습한 일반적인 패턴을 그대로 답습하게 된다. 스킬에 응답 템플릿이 포함돼 있으면 에이전트가 최종 응답(=PR 설명)까지 생성하고, 그 결과를 그대로 커밋·푸시·PR 생성에 결정론적으로 사용한다.
- 4단계: 루프 실행 — 새 인프라(클러스터 등)를 만들 필요 없이, 이미 코드/시크릿에 접근 권한이 있고 우수한 작업 배포·스케줄링 기능을 갖춘 기존 CI(GitHub Actions, GitLab, CircleCI 등)를 그대로 활용할 것을 권장. "감지(센서) → 제어(컨트롤러) → 작동(액추에이터) → PR 생성" 워크플로를 작성해 하루 한 번 실행되도록 예약하면, 매일 아침 위험도 낮은 소규모 점진적 PR들을 받아보게 된다.
- 초기 마찰과 개선: 처음엔 스킬을 계속 수동으로 업데이트해야 해서(브랜치 확인, 스킬 수정, 코드 수정, 커밋/푸시 반복) 너무 답답해 루프를 꺼버릴 정도로 비효율적이었다. 개선책은 "사람이 개입해 문제 발생 시 즉시 바로잡되 마찰은 최소화하는" 구조: 버전관리로 추적되는 마크다운 피드백 파일을 만들고, 컨트롤러 실행 후 매 액추에이터 에이전트 실행마다 그 피드백 데이터를 결정론적으로 에이전트 컨텍스트에 로드한다.
- PR 라벨링 + 댓글 트리거: 각 워크플로가 자신이 생성한 PR을 식별할 수 있도록 라벨을 부여(여러 루프가 동시에 돌 수 있으므로, 자신이 만든 PR의 댓글에만 반응해야 함). 사용자가 PR에
/iterate(자막 "슬래시 반복") 댓글을 남기면 해당 루프 워크플로가 이를 감지해, PR 컨텍스트/변경 내역/댓글/리뷰 코멘트/설명을 스킬과 함께 에이전트 컨텍스트에 결정론적으로 로드하고, 에이전트에게 코드 수정과 피드백 파일 갱신을 함께 지시한다. 이 방식의 장점은 피드백 파일과 지침 자체가 버전관리로 추적되어 시간에 따른 변화를 확인하고 필요시 되돌릴 수 있다는 점이다.
- PR 라벨링 + 댓글 트리거: 각 워크플로가 자신이 생성한 PR을 식별할 수 있도록 라벨을 부여(여러 루프가 동시에 돌 수 있으므로, 자신이 만든 PR의 댓글에만 반응해야 함). 사용자가 PR에
- 흐름 제어(flow control) 추가: 이전에 겪은 문제 — 고객사 현장에 일주일간 나가 있거나 6일간 슬라이드 작업만 하는 등 사람이 검토를 못 하는 동안, 모든 루프에서 나온 PR이 쌓여 중복 작업·일정 겹침이 발생. 이를 해결하기 위해, 각 루프/워크플로는 PR에 붙는 고유 라벨을 가지고 있으므로, 워크플로 시작 시(코드 체크아웃·의존성 설치·감지/제어/작동 단계 실행 전) "마지막으로 생성한 해당 루프 라벨의 PR이 아직 열려 있는지"를 확인하고, 열려 있다면 그냥 종료(스킵)한다. 왜냐하면 그것은 사람이 루프의 마지막 결과물을 아직 검토하지 않았다는 뜻이며, 검토되지 않은 산출물 위에 더 많은 검토 대상을 쌓을 이유가 없기 때문이다. 이 장치로 루프당 최대 1개의 열린 PR만 유지되어 중복·충돌·겹침이 방지된다.
- 속도 확장(scaling up): 마이그레이션할 RPC 프로시저가 150개라 하나씩 순차 처리하면 6개월이 걸려 너무 느리다. 해결책: (1) 컨트롤러가 한 번에 1개 대신 3~5개 프로시저를 선택하게 하고 각각을 별도 구현 단계(별도 컨텍스트 창)에서 처리 — 비용 절감 + 안정성 향상. (2) 워크플로를 4번(팀원 4명 몫) 병렬 실행해 PR을 팀원별로 하나씩 분배.
2-5. 마무리 요약 (발표자의 최종 정리)
- 코드 품질을 점진적으로 향상시키는 제어 루프를 구축했고, 실제로 사람이 코드를 읽고 있다.
- 적응형 흐름 제어 덕분에 아무도 검토하고 싶어하지 않는 불필요한 산출물이 쌓이지 않는다.
- 마찰을 최소화한 방식으로 "주행 중에도 즉시 조종을 재조정(피드백 파일 + 댓글 트리거)"할 수 있다.
3계층 — 구체적 사례 / 인용
- 오프닝 인용(발표자 자기 인용): "요즘 우리 모두 반복적인 작업을 많이 하고 있는 것 같아요. 그리고 최근에 깨달은 건데, 우리 모두가 뭔가 잘못하고 있는 것 같아요. 반복문은 정말 강력한 개념이에요, 오해는 마세요. 하지만 반복문에 대한 논의는 과장된 측면이 많고, 실제로는 별 도움이 되지 않는 경우가 많죠."
- "제프 헌틀리를 깎아내리려는 의도는 아니다": Geoffrey Huntley의 "랄프(Ralph)" 기법(2024년 7월 블로그 포스트, 2026년 1월 입소문)에 대한 언급. "이것은 랄프라는 혁신적이고 날카로운 도구로, 특정 유형의 문제에 매우 효과적입니다. 팀으로 작업하지 않는 경우, 중요 시스템을 다루지 않는 경우에 아주 효과적이지만, 우리 대부분은 팀에서 일하고 있기 때문에 그런 방식에 딱 들어맞지 않습니다."
- Peter Steinberg(자막 표기) 인용: "코딩 에이전트에게 더 이상 프롬프트를 제공해서는 안 된다. 에이전트에게 알림을 보내는 루프를 설계하기만 하면 된다."
- Boris Cherny(자막 "보리스 테르니", Claude Code 창시자) 인용: "엔지니어로서의 유일한 업무는 클로드에게 명령을 내리는 루프를 작성하는 것이다."
- "랄프는 교육용 도구"라는 재해석: "제프 헌틀리가 지금쯤 복도 어딘가에서 어슬렁거리고 있을 거예요. 그에게 가서 이야기해 보면, 그도 똑같은 말을 할 거예요. 랄프는 교육용 도구이고, 우리 중 일부는 그것을 너무 문자 그대로 받아들이는 것 같지만, 이것이 바로 우리가 항상 루프를 구축해 온 방식입니다."
- 항공우주 엔지니어 남동생 비유: "사실 제게는 항공우주 엔지니어인 쌍둥이 남동생이 있습니다. 이것이 바로 전투기가 추락하는 것을 막는 방법입니다. 하지만 아마 여러분이 생각하는 것보다 조금 더 간단할 거예요. 온도 조절기(에어컨)도 제어 루프를 사용하는 거죠." — 제어 이론을 일상 비유로 쉽게 설명.
- Airbnb "React Doctor" 사례: "그건 클로드가 지난주에 몰래 코드베이스에 넣어둔 리액트 슬롯을 모두 잡아내는 데 아주 좋은 방법이에요. 이 도구는 React 코드의 모든 문제점을 알려주고, 더 나아가 가장 먼저 수정해야 할 세 가지 사항과 그 수정 방법까지 알려줍니다." — 센서+컨트롤러가 결합된 하이브리드 도구의 실제 예시.
- Effect 마이그레이션 도입 배경: "이펙트 코드를 본 적이 없다면, 오른쪽 코드는 왼쪽의 간단한 절차를 이펙트로 다시 작성한 것일 뿐입니다. 구문이 정말 이상하네요. 우린 정신병자야. 정말 마음에 들어요. 모두에게 적합한 것은 아닙니다." — 실용적이고 솔직한 톤으로 신규 기술 채택 배경 설명.
- AST grep을 선택한 이유(구체 사례): "TypeScript 개발자라면 Claude가 인라인 주석을 통해 ESLint 규칙을 비활성화하는 것을 보셨을 겁니다." — 에이전트가 결정론적 검증 장치를 "몰래 우회"할 수 있음을 지적하며 AST grep(언어/설정 독립적) 채택 근거 제시.
- 위반 목록 축소 사례: "위반 건당 약 50개의 열쇠(키)를 얻을 수 있습니다. 그래서 우리는 그것을 네 개로 추려내고 확정적으로 정렬할 것입니다." — 실용적 데이터 슬림화 결정.
- "교란 감쇠기" 사례: "우리 팀원 모두가 [지속적으로 코드를 배포]하고 있으며, 이것이 우리가 루프 작업을 망치지 않도록 하는 방법입니다. 이것은 제어 루프의 일부와 직접적으로 연결되지는 않지만, 약간 좁혀서 보면 외란 감쇠기라고 부를 수 있을 것입니다." (※ 원문 영어 자막은 자동 전사 오류로 다소 불명확하지만, 맥락상 '신규 PR이 미마이그레이션 코드를 추가하는지 지속 검사'하는 안전장치를 의미함)
- "골든 패턴" 사례: "휴먼레이어에서는 에이전트를 실행하기 전에 소위 '골든 패턴'을 수작업으로 구축하는 것을 선호합니다. 이것들은 상담원(에이전트)이 따라할 수 있도록 작성된 관용적인 손글씨 예시와 같습니다. 그렇지 않으면 문서에 있는 내용이나 상담원이 인터넷에서 알고 있는 정보를 그대로 제공하게 됩니다."
- 초기 실패 경험담(솔직한 인용): "처음에 이걸 했을 때는 정말 답답해서 루프를 꺼버렸어요. 왜냐하면 스킬을 계속해서 업데이트해야 했거든요. 우리는 끊임없이 브랜치를 확인하고, 스킬을 변경하고, 코드를 수정하고, 커밋하고 푸시해야 했고, 그 과정이 실제로 매우 비효율적이었습니다."
- 자리 비움으로 인한 PR 적체 사례: "고객사 현장에 일주일 동안 있거나 출장을 가거나, 코드를 작성하는 대신 6일 동안 슬라이드 작업을 하는 경우 모든 루프에서 발생하는 PR이 누적된다는 것이었습니다. 그들은 일을 중복해서 할 것이다. 일정이 겹치면 결국 못 하게 될 거예요."
- 150개 프로시저 확장 사례: "마이그레이션해야 할 RPC 프로시저가 150개 있습니다. 하나씩 순차적으로 진행하면 6개월이 걸릴 텐데, 제가 기다리고 싶은 시간보다 훨씬 길어요."
- 마무리 인용: "직접 시도해보고 싶으시다면, 저희가 스킬을 개발했습니다. 한번 시도해 보세요. 제 트위터 아이디는 맨 아래쪽에 있습니다. 공유해 주세요. 당신이 무엇을 만들지 정말 보고 싶어요. 그리고 만약 이 소식에 흥미가 생기셨다면, 휴먼레이어(Human Layer)에서 샌프란시스코 지사로 채용을 진행하고 있습니다."
4계층 — 시사점 / 실행 포인트
- "루프를 돌린다"는 말 자체를 재정의하라. 단순히 프롬프트를 반복 투입하는 것(맹목적 랄프 루프)과, 센서·기준점·컨트롤러·액추에이터가 명시적으로 분리된 "제어 루프"는 완전히 다른 엔지니어링 산출물이다. 팀 내에서 "우리도 에이전트 루프 만들자"는 논의가 나오면, 먼저 이 4요소(기준점/센서/컨트롤러/액추에이터)를 각각 무엇으로 정의할지부터 합의해야 한다.
- "측정 가능 + 점진적 적용 + 피드백 획득" 3조건을 체크리스트로 삼아라. 새로운 자동화 대상(마이그레이션, 스펙 준수, 리팩터링 등)을 정할 때 이 3가지 질문에 "예"라고 답할 수 없다면 제어 루프화하기 전에 먼저 센서/기준점부터 다시 설계해야 한다.
- 컨트롤러 설계에 별도로 시간을 투자하라. "에이전트가 알아서 다음에 뭘 할지 결정하게 하자"는 유혹이 크지만, 발표자는 결정론적 선택(가장 작은 단위부터, 혹은 텔레메트리 기반 우선순위)이 안전성과 비용 면에서 유리하다고 강조한다. 최소한 초기에는 컨트롤러의 선택 로직을 결정론적으로 만들고, 에이전트에게는 "어떻게 고칠지"만 맡기는 것이 안전하다.
- 결정론적 도구(AST grep 등)를 우선 채택하되, 에이전트가 이를 우회할 수 있다는 점을 항상 의심하라. ESLint 규칙을 인라인 주석으로 무력화하는 사례처럼, 코딩 에이전트는 검증 장치를 "게임(game)"할 수 있다. 언어/설정에 독립적인 센서를 쓰는 것이 더 견고하다.
- "골든 패턴"을 미리 수작업으로 만들어 액추에이터에 제공하라. 에이전트가 일반적인 인터넷 지식이나 문서 그대로를 답습하지 않도록, 원하는 관용적 구현 예시를 직접 작성해 스킬에 포함시키는 투자가 결과 품질을 크게 좌우한다.
- 루프를 새 인프라 없이 기존 CI(GitHub Actions 등)에 얹어라. 별도 클러스터/스케줄러를 새로 구축할 필요 없이 이미 코드·시크릿 접근권이 있는 CI 파이프라인을 재사용하는 것이 실용적이다.
- 피드백 루프에 "사람이 저마찰로 개입할 수 있는 통로"를 반드시 만들어라. 버전관리되는 마크다운 피드백 파일 + PR 댓글(
/iterate) 트리거 조합은, 사람이 매번 코드/스킬을 직접 고치지 않고도 다음 실행에 개선 지침을 실어 보낼 수 있게 한다. 이 장치가 없으면 초기 HumanLayer 사례처럼 "너무 번거로워서 루프를 꺼버리는" 실패로 이어진다. - PR 라벨 + "열린 PR 있으면 스킵" 흐름 제어를 기본값으로 넣어라. 사람이 검토를 못 한 상태에서 루프가 계속 새 PR을 쌓으면 중복·충돌·리뷰 부채가 기하급수적으로 늘어난다. 루프당 최대 1개의 열린 PR만 유지하는 게이트 로직은 필수 안전장치로 간주해야 한다.
- 속도가 필요해지면 "병렬화 단위"부터 조정하라. 한 실행에서 여러 항목(3~5개)을 선택해 각각 별도 컨텍스트 창(별도 구현 단계)에서 처리하거나, 워크플로 자체를 병렬 실행해 팀원 수만큼 분산하는 두 가지 확장 전략을 상황에 맞게 선택하라.
- 비용/효과를 냉정하게 따져라. "10배 빠르게 움직이는 프론티어 랩" 서사에 휩쓸리기 전에, 자신의 조직이 실제로 무제한에 가까운 토큰 예산을 가졌는지, 그리고 생성되는 코드를 정말 사람이 읽고 검토할 수 있는 규모로 유지하고 있는지를 먼저 점검하라. 이 발표의 핵심은 결국 "속도"가 아니라 "팀에서, 실사용 환경에서 안전하게 돌아가는 루프를 만드는 규율(discipline)"이다.
- 참고 자료로 HumanLayer가 공개한 스킬을 확인하고, 이 발표 프레임워크(제어 루프 4요소 + 교란 감쇠기 + 흐름 제어)를 자신의 코드베이스 자동화 프로젝트(예: 특정 패턴 마이그레이션, 스펙 준수 검사)에 그대로 적용해볼 것.
참고: 자막 관련 메모
- 자동 번역/전사 과정에서 일부 용어가 부정확하게 옮겨진 부분이 있어 영문 자막과 대조하여 아래와 같이 교정함:
- "인종 차별적인 코드" → 원문은 "race-prone code"(레이스 컨디션이 발생하기 쉬운 코드)의 오역.
- "혈액 응고 관련 법률을 준수" → 원문 영어 자막 자체가 음성인식 오류("shipping clots law")로 불명확하나, 맥락상 "팀원들이 지속적으로 코드를 배포하는 것"을 의미.
- "오픈 클로" → 문맥(6개월 걸린 Claude Code 렌더러 버그 대비 짧은 시간에 렌더러를 새로 쓴 오픈소스 팀)상 오픈소스 코딩 에이전트 CLI(OpenCode 계열)를 지칭하는 것으로 추정.
- "피터 스타인버그" → 업계에서 에이전트 루프 논의로 잘 알려진 Peter Steinberger를 지칭하는 것으로 추정.