Loop Engineering from First Principles — Kyle Mistele, HumanLayer

URL: https://www.youtube.com/watch?v=xIt_mTQp6mY 날짜: 2026-07-25 채널: AI Engineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

"코딩 에이전트에 프롬프트와 루프만 붙이면 소프트웨어를 만들 수 있다"는 업계 서사는 ==과장된 하이프에 가깝고, 실제로는 제어이론(control theory)을 엄밀히 적용해야만 실전에서 쓸 수 있는 루프가 나온다==는 것이 이 발표의 핵심이다.

• Ralph 같은 "블라인드 루프(bash 루프 + 프롬프트)"는 팀 단위로 일하고 규제·SLA·실사용자가 있는 프로덕션 환경에는 잘 맞지 않는다
• 검증(verifier)·코드 리뷰 에이전트를 아무리 많이 붙여도, 결국 아무도 읽지 않는 4만 줄짜리 PR을 계속 찍어내는 구조라면 근본적인 해결이 아니다
• 제어이론의 sensor-controller-actuator 패턴을 적용하면, 코드를 계속 사람이 읽을 수 있는 수준으로 유지하면서도 점진적으로 개선하는 루프를 만들 수 있다

발표자 Kyle은 이것이 여전히 "루프"를 만드는 일이라는 점은 인정하면서도, 그 루프를 제어이론적으로 설계하면 대규모 복잡한 코드베이스에서도 안전하게 자동화를 확장할 수 있다고 주장한다.

---

1. AI 코딩 루프를 둘러싼 하이프와 현실

이 섹션에서는 "루프가 미래다"라는 프론티어 랩들의 서사와, 실제로 팀에서 이를 적용했을 때 부딪히는 현실 사이의 간극을 짚는다.

1.1. 업계 서사: 루프가 소프트웨어 개발의 미래다

1. "루프 올인" 서사의 확산

   1. 바이럴 포스트: 이 발표의 배경이 된 포스트는 원래 작년 7월에 나왔지만, 이번 1월에 바이럴이 되면서 많은 사람이 "루프 만들기"에 뛰어들기 시작했다
   2. Peter Steinberger의 발언: "우리는 더 이상 코딩 에이전트에게 프롬프트를 주는 게 아니라, 에이전트에게 프롬프트를 주는 루프를 설계해야 한다"고 주장 — 이번 주(컨퍼런스 기간) 계속 인용될 슬라이드라고 언급

2. Open Claw / Claude Code도 루프 기반

   1. Open Claw는 악명 높게 루프로 돌아간다: 루프가 코드를 짜고, 루프가 코드를 리뷰하고, 루프가 머지·릴리즈하고, 루프가 버그를 찾고 고친다 — "루프 all the way down"
   2. Boris Cherny(Claude Code 제작자)의 발언: 최근 "엔지니어로서 내 일은 이제 그냥 Claude에게 프롬프트를 주는 루프를 짜는 것"이라고 말함
   3. 미래 전망(반쯤 농담): 결국은 에이전트 스웜(swarm)이 루프를 설계하고, 그 루프가 다시 에이전트를 프롬프트하고, 그 에이전트가 다시 루프를 위한 스웜을 만드는 식으로 계속 중첩될 수도 있다는 냉소적 전망

1.2. 현실: 읽을 수 없는 코드와 비용 문제

1. "어차피 못 읽으니 아예 안 읽는다"는 함정

   1. 생산량 폭증: 루프들이 찍어내는 코드 양이 너무 많아서 전부 읽는 게 불가능해지고, 그러다 보니 "어차피 다 못 읽을 거 그냥 아무것도 안 읽자"는 식으로 흘러간다
   2. 검증에 투자하지만 코드는 못 읽음: verifier·코드 리뷰에 투자는 하고 있지만, 정작 코드 자체는 read-only 상태로 방치되는 것 — 이것이 지난달 이 도시(컨퍼런스 개최지)에서 열린 어느 컨퍼런스의 테제였다고 언급
   3. 프론티어 랩의 속도 vs 나머지의 현실: 프론티어 랩 사람들은 "이게 소프트웨어 개발의 미래이고, 이렇게 하면 10배 빠르며 나머지는 다 뒤처진다"고 믿지만, 아직 이게 얼마나 잘 작동하는지는 불명확하다

2. 구체적 반례: 안정성과 비용

   1. Claude Code 터미널 flicker 버그: 고치는 데 6개월이 걸렸는데, OpenCode 팀은 그 일부 시간 만에 자체 렌더러를 새로 짰다
   2. Open Claw의 안정성 이슈: Open Claw도 악명 높게 안정성 문제가 있다고 언급
   3. 비용 문제: 프론티어 랩처럼 무제한 토큰 예산이 없다면 이 방식은 실제로 매우 비싸다
   4. Matt PCO(성함 정확한 표기 불확실)의 발언 인용: "에이전트 시대에는 나쁜 코드가 과거 어느 때보다 훨씬 더 비싸다"

1.3. Ralph 루프의 한계

1. Ralph는 도구이지 만능이 아니다

   1. Jeff Huntley를 겨냥한 비판이 아님을 명시: 발표자는 이것이 Ralph를 만든 Jeff Huntley에 대한 비판(throw shade)이 아니라고 분명히 함
   2. Ralph의 적용 범위: Ralph는 혁신적이고 날카로운 도구이지만, 특정 유형의 문제에서만 잘 작동한다 — 팀이 아니라 혼자 개발할 때, 그리고 미션 크리티컬 시스템이 아닐 때 잘 맞는다
   3. 대다수는 그 조건에 안 맞음: 대부분의 사람들은 팀으로 일하고, 그 "박스" 안에 들어가지 않는다

2. 오늘 발표의 목표

   1. "진짜 세계"를 위한 루프: 실제 고객, 실사용자, 규제 의무, SLA 등 프로덕션 조건이 있는 복잡한 코드베이스에서 작동하는 루프를 만드는 방법을 다룬다
   2. HumanLayer에서 실제로 하고 있는 방식: 여전히 "루프"를 만드는 것이지만, 코드를 계속 읽을 수 있고 오히려 루프가 코드를 더 좋게 만들도록 설계한다는 것이 차이점

---

2. 제어이론(Control Theory) 기초

발표자는 항공우주 엔지니어인 쌍둥이 형제 이야기를 예로 들며, 전투기가 하늘에서 떨어지지 않게 하는 것과 같은 원리를 소프트웨어 루프에도 적용할 수 있다고 설명한다.

2.1. 제어 루프의 구성 요소

1. 기본 구조

   1. 동적 시스템을 목표 상태로 이끄는 것: 제어이론은 코드베이스 같은 동적 시스템을 원하는 안정적/최적의 종착 상태로 몰아가는 방법에 관한 것
   2. Sensor(센서): 세계(시스템)의 현재 상태를 측정
   3. Set point(설정값): 우리가 원하는 세계의 상태
   4. Measured error(측정 오차): 현재 상태와 설정값의 차이
   5. Controller(제어기): 측정 오차를 읽어서 시스템에 적용할 점진적 변화(제어 신호)로 변환
   6. Actuator(액추에이터): 그 변화를 실제 시스템에 적용
   7. Disturbance(교란): 시스템은 그 사이에도 계속 외부 교란을 받고 있고, 그래서 다시 오차를 재측정하고 처음으로 돌아가는 순환이 반복된다

2. 왜 이게 중요한가

   1. 점진적 개선의 원리: 제어 루프는 시스템을 한 번에 목표 상태로 확 밀어붙이지 않고 점진적으로 바꾼다 — 그래야 overshoot(과도 조정)로 시스템을 불안정하게 만들거나 한번에 다 망가뜨릴 위험을 피할 수 있다
   2. 리스크 최소화: 이 점진성이 리스크를 최소화하는 핵심 메커니즘이다

2.2. 일상 속 제어 루프 사례

1. 누구나 매일 쓰는 제어 루프

   1. 온도조절기(thermostat): 유럽 청중을 위해 설명하자면 미국에서는 이걸 "에어컨(air conditioning)"이라 부르는데, 이것도 제어 루프의 일종
   2. Kubernetes 오토스케일링: 오토스케일링 시스템은 제어 루프 위에 만들어져 있다
   3. Infrastructure as Code: 원하는 상태(desired state), 현재 상태(current state), 반복적 변화라는 제어 루프 패턴을 그대로 쓴다
   4. Postgres의 autovacuum: 제어 루프를 사용하거나 근사한다
   5. React의 virtual DOM: 마찬가지로 제어 루프 패턴을 사용/근사한다

2. 제어 루프가 이상적으로 맞는 조건

   1. 측정 가능한 문제: 변화시키고 싶은 시스템, 측정할 수 있는 문제가 있을 때
   2. 결과에 대한 피드백 확보: 그 변화의 결과에 대해 피드백을 받을 방법이 있을 때 — 이것이 좋은 소프트웨어 엔지니어들이 원래부터 배워온 방식이라고 언급

2.3. 제어 루프 vs "블라인드 Ralph 루프"

1. 정반대의 접근
   1. 블라인드 루프의 정의: 제어 루프는 발표자가 말하는 "블라인드 Ralph 루프"의 정반대다 — 아무도 리뷰하고 싶어하지 않는 형태의 PR을 만드는 방식을 피하게 해준다
   2. 모든 Ralph 루프가 블라인드는 아님: 최고 수준의 Ralph 구현체들은 실제로 제어이론을 적용하고 있다고 언급하며, Jeff Huntley 본인도(그 자리에 있다면) 같은 이야기를 할 거라고 언급
   3. Ralph는 원래 "교육용 장치(teaching device)": Ralph를 너무 문자 그대로 받아들인 경우가 많았을 뿐, 원래는 우리가 항상 이런 식으로 루프를 만들었어야 한다는 걸 보여주는 교육적 예시였다
   4. 진짜 문제는 "점진적이지 않음": Ralph 루프의 또 다른 문제는 그냥 bash 루프일 뿐이라 점진적이지 않다는 것 — 그래서 "agentic control loop(에이전틱 제어 루프)"를 직접 만들어야 한다

---

3. Agentic Control Loop 설계하기

3.1. Set Point와 Sensor 정의

1. Set point 먼저 정의

   1. 원하는 종착 상태 정의: 코드베이스의 어떤 속성(property)에 대해, 그 속성이 도달해야 할 원하는 최종 상태를 먼저 정의한다

2. Sensor를 만드는 여러 방법

   1. 결정론적(deterministic) 방식: ESLint 규칙, ast-grep(AST 기반 규칙), 자체 pack 작업 등
   2. 비결정론적(non-deterministic) 방식: 에이전트 + 스킬 + 자연어 규칙 묶음
   3. 하이브리드(파이프라인) 방식: 위 두 가지를 조합한 파이프라인으로 구성할 수도 있음

3. 실전에서는 컴포넌트 경계가 흐려짐

   1. 에이전트를 쓰면 역할이 섞인다: 실제로는 에이전트를 사용하기 때문에 시스템 구성요소(sensor/controller/actuator) 사이 경계를 약간 흐릴 수 있다
   2. 하이브리드 sensor+controller 예시 — Aiden의 "React Doctor": Claude가 코드베이스에 슬쩍 끼워넣은 React 관련 문제(React slop)를 잡아내는 훌륭한 도구인데, 문제를 알려줄 뿐 아니라 "고쳐야 할 상위 3가지"와 "어떻게 고치는지"까지 같이 알려준다는 점에서 sensor와 controller가 혼합된 형태
   3. Controller+Actuator도 한 에이전트일 수 있음: 점진적 변화를 결정하는 것과 그것을 같은 컨텍스트 윈도우 안에서 바로 적용하는 것이 사실상 하나의 에이전트일 수도 있다

4. Controller에 주목해야 하는 이유

   1. 너무 큰 변화의 위험: 잘 튜닝된 controller가 없으면 한 번에 너무 큰 변화를 만들거나 아예 잘못된 변화를 만들 수 있다
   2. 루프에 넣으면 문제가 커짐: 이런 컨트롤러 문제를 그대로 루프에 넣으면 금방 곤경에 빠진다

3.2. 제어 루프의 다양한 활용 사례

1. 코드 정리를 넘어선 활용

   1. 나쁜 패턴 제거·코드 클린업: 제어 루프를 나쁜 패턴을 솎아내고 코드를 정리하는 데 쓸 수 있다
   2. API 스펙 준수: 우리 API가 타사의 OpenAPI 스펙을 준수하도록 유지
   3. MCP 스펙 준수: 우리 MCP 서버가 현재 채택 중인 MCP 스펙 버전을 준수하도록 유지 (본인도 "확인 안 해봤다"고 농담)
   4. 언어 간 미러링: Python 프로젝트를 TypeScript로(혹은 그 반대로) 미러링
   5. 업스트림 포크 유지: Vibe-coded된 Next.js의 "슬롭 포크(slop fork)"를 업스트림 대비 계속 최신 상태로 유지하는 것도 가능

2. 핵심 질문 3가지

   1. 측정 가능한가: 우리가 측정할 수 있는 무언가를 찾을 수 있는가
   2. 점진적으로 적용 가능한가: 변화를 점진적으로 적용할 수 있는가
   3. 피드백을 받을 수 있는가: 그 변화의 품질에 대해 피드백을 받을 수 있는가

---

4. HumanLayer 실전 사례: RPC API → Effect 마이그레이션

발표자는 HumanLayer 내부에서 실제로 쓰고 있는 제어 루프를 예로 든다. Race(경쟁 상태)에 취약한 코드 일부에 Effect 라이브러리를 도입해 좋았기 때문에, 코드베이스 전체로 점진적으로 확대 적용하는 중이다. (Effect 문법은 "이상하다"고 인정하며, "우리는 사이코들이라 좋아한다"고 농담 — 이 발표는 Effect 자체에 대한 발표가 아니므로 넘어간다고 언급)

4.1. Sensor 구축 — ast-grep 선택

1. 왜 ast-grep인가

   1. 후보군: 에이전트가 직접 찾게 할 수도 있고, grep이나 ripgrep을 쓸 수도 있지만, 대신 매우 강력한 ast-grep을 선택
   2. 언어 애그노스틱: ast-grep은 언어에 구애받지 않아서, 멀티링구얼 모노레포 어떤 언어에도 다 작동한다
   3. 설정 파일 밖에서 동작: TypeScript 설정이나 ESLint 규칙과 별개로(out of band) 동작한다는 게 중요한 포인트 — TypeScript 개발자라면 Claude가 인라인 주석으로 ESLint 규칙을 그냥 꺼버리는 걸 본 적 있을 것이라고 언급

2. 규칙 작성과 확장

   1. 패턴 기반 룰: 위 패턴을 기반으로 마이그레이션 안 된 procedure를 찾는 단순한 규칙을 작성
   2. 점진적 룰 레이어링: 시간이 지나면서 include/exclude 경로를 세밀하게 지정한 규칙들을 계속 추가로 쌓아 다른 패턴들도 잡아낼 수 있다

3. 스캔 결과 다듬기

   1. 위반 목록이 너무 김: 코드베이스를 스캔하면 매우 긴 위반 목록이 나오는데(위반 1건당 약 50개의 key), 그대로 쓰기엔 너무 많음
   2. 4개로 필터링 + 결정론적 정렬: 목록을 4개로 좁히고 결정론적으로 정렬한다

4.2. 안정화 단계 — "Disturbance Dampener"

1. 먼저 출혈을 멈춰야 한다

   1. 왜 이 단계가 필요한가: 한 번에 하나씩 점진적으로 마이그레이션을 시작하기 전에, 먼저 신규 procedure는 전부 Effect를 쓰도록 강제해야 한다
   2. 한 번의 전체 스캔: main 브랜치에서 전체 스캔을 한 번 돌려 모든 위반을 결정론적으로 정렬하고 버전 관리에 기록
   3. 모든 신규 PR 체크: 이후 모든 새 PR에서 브랜치가 마이그레이션 안 된 procedure를 추가했는지 확인

2. 제어 루프 관점에서의 의미

   1. 엄밀히는 제어 루프의 한 부분은 아니지만: "disturbance dampener(교란 감쇠기)"라고 부를 수 있다고 설명
   2. 팀원들이 곧 disturbance: 이 경우 시스템에 대한 교란은 팀원들이 계속 "cloud slot"(AI가 생성한 미흡한 코드)을 배포하는 것이며, 이 체크가 팀원들이 루프의 작업 결과를 되돌리지 못하게 막아준다

4.3. Controller 설계

1. 단순한 Controller부터

   1. 결정론적 첫 항목 선택: bash와 jq로 목록에서 첫 번째 위반을 그냥 결정론적으로 고를 수 있다
   2. 더 영리한 방식: ast-grep으로 가장 작은(가장 리스크가 적은) 마이그레이션 안 된 procedure를 찾아 항상 그걸 고르는 방법으로 리스크를 줄일 수 있다
   3. 에이전트에게 맡길 수도 있음: 정말 원한다면 에이전트가 결정하게 할 수도 있다 — 다만 "결정론적 코드가 할 일을 굳이 에이전트에게 시키면 안 된다"고 생각하지만, 할 수는 있다고 인정
   4. 선택과 실행을 동시에: 복잡도에 따라 에이전트가 마이그레이션할 procedure를 고르는 동시에 바로 실행하게 할 수도 있다(controller+actuator 결합)

2. 더 강력한 버전 — Telemetry 활용

   1. 단순 마이그레이션을 넘어서는 목적: Effect로 옮기는 이유는 단지 마이그레이션 자체가 아니라 에러 처리와 계측(instrumentation)을 더 잘하기 위함
   2. 텔레메트리로 우선순위 결정: 에러가 가장 많거나, 계측이 가장 부족하거나, APM(애플리케이션 성능 모니터링)에 공백이 있는 procedure를 텔레메트리 데이터로 찾아낼 수 있다
   3. 제어 신호에 문제 데이터까지 포함: actuator 에이전트에게 보내는 제어 신호에 "이 procedure를 마이그레이션하라"는 지시뿐 아니라, "이 마이그레이션으로 고쳐야 할 문제에 대한 데이터"까지 함께 보내면, 에이전트가 단순 1:1 이관이 아니라 실제로 코드를 더 좋게 만들 수 있다

4.4. Actuator 구축

1. 에이전트 + 스킬 구조

   1. CLI 코딩 에이전트는 취향껏: 원하는 CLI 코딩 에이전트를 아무거나 쓰면 된다
   2. 스킬에 시간을 많이 투자하라: 스킬을 처음부터 완벽하게 만들 필요는 없고, 실제로 뭐가 효과 있는지 보면서 시간을 두고 반복(iterate)해야 한다

2. "Golden Pattern" 만들기

   1. 손으로 미리 작성한 이상적 예제: HumanLayer는 에이전트를 풀어놓기 전에 "golden pattern"이라 부르는, 직접 손으로 작성한 관용적(idiomatic) 예제를 먼저 만들어둔다
   2. 왜 필요한가: 에이전트는 결국 "패턴 복제기(pattern replicator)"일 뿐이라서, 이 예제가 없으면 문서에 있는 것이나 인터넷에서 학습한 패턴을 그대로 따라하게 된다

3. 실행 흐름

   1. 스킬 + 제어 신호를 함께 투입: 스킬과 제어 신호(control signal)를 함께 actuator 에이전트에 파이핑한다
   2. 응답 템플릿 포함: 스킬에는 응답 템플릿(response template)이 포함되어야 한다
   3. 에이전트가 작업 후 최종 응답 생성: 에이전트가 작업을 계속 수행한 뒤 최종 응답을 만들어낸다
   4. 결정론적 커밋/푸시/PR 생성: 이후 결정론적으로 커밋하고 푸시해서 PR을 만들고, 에이전트의 최종 메시지를 그대로 PR 설명으로 사용한다

4.5. 루프 실행하기

1. CI 플랫폼을 실행 환경으로

   1. GitHub Actions 등 추천: GitHub Actions, GitLab, CircleCI 등을 추천 — 이미 코드 접근 권한, 시크릿 접근 권한, 훌륭한 dispatch/스케줄링 프리미티브를 갖추고 있기 때문
   2. 새 클러스터가 필요 없음: 이를 위해 별도 클러스터를 새로 만들 필요가 없다고 강조

2. 워크플로우 구조

   1. 단일 반복 실행: sense → control → actuate 한 사이클을 실행하고 PR을 만드는 워크플로우를 작성
   2. 매일 1회 스케줄링: 이걸 하루 한 번 실행되도록 스케줄링하면, 매일 아침 출근했을 때 낮은 리스크의 작은 점진적 PR이 하나 기다리고 있게 된다

3. 초기 도입 시의 마찰

   1. 처음엔 실제로 매우 답답했음: 처음 도입했을 때는 실제로 상당히 답답해서 루프를 꺼버린 적도 있다
   2. 원인: 스킬을 계속 업데이트해야 했고, 브랜치를 계속 체크아웃해서 스킬과 코드를 바꾸고 커밋·푸시해야 했다 — 즉 루프 자체의 마찰(friction)이 너무 높았다

---

5. 루프 개선하기 — 피드백 루프와 흐름 제어(Flow Control)

5.1. 낮은 마찰로 사람을 "루프 위에" 두기

1. "Feedback file" 패턴

   1. 버전 관리되는 마크다운 파일: 버전 관리 대상인 마크다운 파일 하나를 피드백 파일로 만든다
   2. 매 실행마다 컨텍스트에 로드: controller가 실행된 후 매번 actuator 에이전트의 컨텍스트에 이 파일을 결정론적으로 로드한다

2. PR 라벨과 코멘트 트리거

   1. 워크플로우별 라벨 부착: 각 워크플로우는 자신이 만든 PR을 식별할 수 있어야 한다 — 여러 개의 서로 다른 루프가 동시에 돌 수 있기 때문에, 각 워크플로우는 자기 PR에 달린 코멘트에만 반응해야 한다
   2. /iterate 코멘트 트리거: 사용자가 PR에 /iterate 코멘트를 남기면 해당 루프 워크플로우가 이를 감지한다
   3. PR 컨텍스트 전체를 결정론적으로 로드: diff, 코멘트, 리뷰 코멘트, description을 모두 스킬과 함께 에이전트 컨텍스트에 로드
   4. 코드 수정 + 피드백 파일 업데이트를 함께 지시: 에이전트에게 코드를 고치라고 지시할 뿐 아니라, 피드백 파일도 함께 업데이트하라고 지시한다

3. 이 방식의 이점

   1. 피드백 이력이 버전 관리됨: 지침이 담긴 피드백 파일이 버전 관리되므로 시간에 따른 변화를 볼 수 있고, 필요하면 되돌릴(revert) 수도 있다

5.2. Flow Control — 중복·적체 방지

1. 문제 상황

   1. 부재 시 PR이 쌓임: 고객사에 일주일 출장을 가거나, 슬라이드 준비에 6일을 쓰는 등 자리를 비우면, 여러 루프에서 만든 PR들이 계속 쌓이고, 중복 작업이 생기고, 서로 충돌하고, 결국 아무도 처리하지 못하게 된다
   2. 루프 작업이 중요하지만 "그 정도"는 아님: 루프의 결과물이 중요하긴 하지만 그렇게까지 중요한 건 아닌데도, 처리해야 할 "잡동사니"만 계속 쌓이는 문제가 생겼다

2. 해결책 — 라벨 기반 실행 여부 체크

   1. 각 루프 워크플로우에 고유 라벨: 각 루프와 그 워크플로우는 PR에 붙는 고유 라벨을 가진다
   2. 실행 전 열려있는 PR 확인: 워크플로우가 시작될 때, 코드 체크아웃·의존성 설치·sense-control-actuate 실행에 앞서, 자신이 마지막으로 만든 PR(또는 자기 라벨이 붙은 어떤 PR이든)이 아직 열려 있는지 확인한다
   3. 열려 있으면 그냥 종료: 열려 있다면 그냥 셧다운한다 — 이는 이 루프가 만든 마지막 산출물을 아직 사람이 리뷰하지 않았다는 뜻이므로, 리뷰할 사람에게 더 많은 작업을 쌓아줄 이유가 없기 때문
   4. 결과: 루프당 항상 최대 1개의 PR만 열려 있게 되어, 적체·중복이 없고 (바라건대) 충돌도 없다

5.3. 속도 올리기

1. 속도가 필요한 이유

   1. 150개 RPC procedure 마이그레이션 사례: 하나씩 하면 6개월이 걸리는데, 이는 기다리기엔 너무 긴 시간이라고 언급

2. 속도를 높이는 여러 방법

   1. controller가 한 번에 여러 개 선택: 한 번에 하나 대신 3개나 5개를 고르게 할 수 있다
   2. 선택한 것들을 개별 구현 단계로 분리: 3개나 5개를 고른 뒤 각각을 별도의 구현 단계(implementation phase)로 처리하면, 각 마이그레이션이 자기만의 컨텍스트 윈도우를 갖게 되어 더 저렴하고 더 신뢰성 있게 된다
   3. 워크플로우 자체를 여러 번 실행: 워크플로우를 4번 실행해서 팀원 4명에게 각각 PR을 하나씩 배정할 수도 있다

---

6. 마무리

1. 정리

   1. 코드를 계속 읽으면서 점진적으로 개선하는 제어 루프를 만들었다
   2. 적응형 flow control 덕분에 아무도 원하지 않는 산더미 같은 리뷰 작업이 쌓이지 않는다
   3. 낮은 마찰로 실시간 재조정(resteer)이 가능하다

2. HumanLayer의 오퍼

   1. 자체 스킬 공개: 이 방식을 직접 써볼 수 있도록 스킬을 만들었으니 시도해보고 공유해달라고 요청 (발표 슬라이드 하단에 자신의 트위터 핸들 안내 — 자막상 정확한 핸들 텍스트는 확인 불가)
   2. 채용 공고: HumanLayer는 샌프란시스코에서 채용 중이며, 미션 크리티컬 시스템에서 AI를 더 잘 활용하는 방법을 고민 중인 사람이라면 이야기 나누고 싶다고 언급

---

주요 발언 모음

"So today I want to talk about how to build loops that work in large complex code bases for systems that have real customers, real users, real regulatory obligations and service level agreements... In other words, I want to talk about how to build loops for the real world."

"Peter Steinberger said that we shouldn't be prompting coding agents anymore, right? We should just be designing loops that prompt our agents."

(Boris Cherny 인용) "this is his entire job as an engineer now is just writing loops to prompt Claude."

"Bad code is much more expensive in the age of agents than it has ever been at any point in the past." (Matt PCO 인용)

"Control loops change a system incrementally instead of just trying to get straight to the end state immediately all at once and risk blowing everything up... They help us to avoid over steering and destabilizing the system and it minimizes risk."

"I don't think you should ever send an agent to do deterministic code's job, but you certainly can."

"No human reviewed the last output. So there's no reason to stack up even more work for humans to review."

핵심 데이터 & 수치

• Claude Code 터미널 flicker 버그 수정 기간: 6개월 소요 — 대비되는 사례로 OpenCode 팀은 그 일부 시간 만에 자체 렌더러를 새로 작성
• ast-grep 위반 스캔 결과: 위반 1건당 약 50개의 key가 나올 정도로 방대해서, 실제 사용 시에는 4개로 필터링 후 결정론적으로 정렬
• 150개 RPC procedure 마이그레이션: 하나씩(1일 1개) 처리하면 약 6개월 소요 — 이를 단축하기 위해 controller가 3~5개씩 선택하거나 워크플로우를 병렬로 여러 번 실행하는 방식을 제안
• PR 적체 문제: 루프당 최대 1개의 PR만 열려 있도록 라벨 기반 체크를 도입해 적체·중복·충돌을 방지

결론 및 시사점

1. 루프 자체가 문제가 아니라 "설계 없는 루프"가 문제다: Ralph 같은 블라인드 루프도 나쁜 게 아니라, 제어이론 없이 무작정 큰 변화를 밀어붙이는 방식이 문제다.
2. Sensor–Controller–Actuator 세 가지를 각각 명시적으로 설계하라: 무엇을 측정할지(sensor), 어떤 점진적 변화를 고를지(controller), 그 변화를 어떻게 적용할지(actuator)를 각각 분리해서 고민해야 프로덕션급 루프가 된다.
3. "디스터번스 댐퍼" 단계를 잊지 마라: 점진적 마이그레이션을 시작하기 전에, 신규 코드가 문제를 다시 만들지 못하게 막는 게이트를 먼저 세워야 한다.
4. 텔레메트리를 컨트롤러에 연결하면 단순 마이그레이션이 실제 개선으로 바뀐다: 어떤 부분을 먼저 고칠지 데이터 기반으로 우선순위를 매기면, 에이전트가 그냥 1:1 변환이 아니라 실질적인 코드 개선을 하게 만들 수 있다.
5. Golden pattern에 투자하라: 에이전트는 결국 패턴 복제기이므로, 손으로 작성한 이상적 예제가 없으면 인터넷에서 배운 평범한 패턴을 그대로 답습한다.
6. 사람을 "루프 안"이 아니라 "루프 위"에 두는 저마찰 피드백 구조가 핵심이다: 버전관리되는 피드백 파일 + PR 코멘트 트리거(/iterate) 조합으로, 사람이 매번 브랜치를 체크아웃하지 않고도 루프를 재조정할 수 있다.
7. Flow control 없이는 루프가 오히려 짐이 된다: 라벨 기반으로 "리뷰 안 된 PR이 열려 있으면 새로 실행하지 않는다"는 규칙만으로 적체·중복·충돌을 원천 차단할 수 있다.