다가오는 루프 — 에이전트 바깥의 하네스 루프가 엔지니어링을 어떻게 바꾸는가

도입: 코딩 에이전트 바깥에서 도는 새로운 루프

2026년 6월 현재, AI 코딩 에이전트 담론의 중심은 모델 안에서 도는 에이전트 루프에서 모델 바깥의 하네스 레벨 루프로 이동하고 있다. Armin Ronacher의 최신 글 다가오는 루프는 이 패턴을 "작업이 큐에 들어가고, 기계가 시도하고, 하네스가 끝났는지 판단하고, 끝나지 않았으면 같은 세션에 메시지를 주입하거나 새 세션을 시작하거나 다른 기계에 넘기는" 구조로 정리한다. Pi(Pythonic agent runtime) 자체가 하네스이기 때문에 이런 실험의 중심에 놓인다.

핵심 질문은 단순하다. 루프를 돌릴 것인가가 아니라, 루프 안에서 인간의 판단과 엔지니어링 규칙을 어떻게 유지할 것인가다. 이 글에서는 하네스 루프가 잘 맞는 영역과 맞지 않는 영역, 모델이 만드는 코드 품질의 문제, 그리고 책임 있는 감독을 위한 하네스 설계 원칙을 정리한다.

하네스 레벨 루프의 구조

기존 에이전트 루프는 모델이 도구를 호출하고, 결과를 반영하고, 파일을 읽고 수정하고, 테스트를 실행한 뒤 답을 내는 모델 안의 흐름이었다. 하네스 레벨 루프는 그 바깥에서 동작한다.

| 단계 | 모델 에이전트 루프 | 하네스 레벨 루프 |

|------|-------------------|------------------|

| 작업 큐 관리 | 모델이 직접 결정 | 큐 시스템이 작업 분배 |

| 종료 판단 | 모델이 "done" 출력 | 하네스가 검증/테스트 신호로 판단 |

| 컨텍스트 주입 | 매 호출마다 새로 | 수정된 컨텍스트로 세션 재시작 |

| 작업 인계 | 단일 세션 | 다른 기계/모델에 넘김 |

| 인간 개입 | 매번 리뷰 | 명세 단계 + 종료 후 결과 확인 |

이 구조가 중요한 이유는 모델이 보통 "끝났다"고 말할 지점 이후에도 작업을 계속 살아 있게 만들기 때문이다. GitHub PR 자동화, 백그라운드 작업 큐, durable session, subagent 오케스트레이션이 모두 이 패턴에 해당한다.

오래 유지할 코드에서 하네스 루프가 잘 안 맞는 이유

Armin이 강조하는 핵심은 취향과 통제다. 배포하는 코드를 이해하고 싶고, 압박 상황에서도 기계에게 먼저 설명을 시키지 않고 시스템 동작을 설명할 수 있어야 한다. 현재 손을 뗀 하네스 방식의 코드 품질은 지난가을보다 더 나빠졌다고 느껴질 정도다.

모델이 루프 안에서 증폭하는 습관

모델은 국소적 실패를 보면 국소적 방어를 추가하는 경향이 있다. Andrej Karpathy는 모델들이 예외를 "치기적으로 두려워한다"고 말한 바 있다. 중요한 불변식이 있는 시스템, 특히 영속 데이터 포맷이나 핵심 인프라에서는 "모든 malformed case를 처리"하는 방식이 올바른 수정이 아닐 수 있다. 더 나은 방향은 malformed case를 표현할 수 없게 만들거나 처음부터 쓸 수 없게 만드는 것이다.

루프가 모델의 습관을 증폭시키는 메커니즘은 다음과 같다:

# 나쁜 예: 루프가 만드는 과도한 방어
def process_user_input(data):
    if data is None:
        return None
    if not isinstance(data, dict):
        return None
    if "name" not in data:
        return None
    if data.get("name") is None:
        return None
    if not isinstance(data.get("name"), str):
        return None
    if len(data.get("name", "")) == 0:
        return None
    # ... 실제 로직
    return result

위 코드는 각 반복마다 "작은 방어를 하나씩 더한" 결과다. 시스템은 더 견고해 보이지만 점점 이해하기 어려워진다. 손을 더 뗄수록 이런 경향이 커진다. 명확한 지침 없이 주니어에게 이런 도구를 주면 나쁜 실천을 학습시킨다. 이유를 물으면 그럴듯하게 자기 선택을 변호할 수 있기 때문이다.

좋은 방향: 타입으로 불가능한 상태 표현하기

# 좋은 예: 타입 시스템으로 잘못된 상태 차단
from dataclasses import dataclass

@dataclass(frozen=True)
class ValidUserInput:
    name: str
    email: str
    
    def __post_init__(self):
        if not self.name or not self.email:
            raise ValueError("name and email are required")

def process_user_input(data: ValidUserInput) -> Result:
    # data는 이미 검증됨, 추가 방어 불필요
    return process(data)

이 방식이 LLM에게는 어렵다. 많은 수동 조향이 있어도 이런 코드를 자연스럽게 내놓기 어렵고, 불가능해진 오류까지 처리하려 할 수 있다. 이 습관을 루프 뒤에 두면 문제가 증폭된다.

하네스 루프가 잘 맞는 영역

루프 패턴은 이미 일부 영역에서 매우 잘 작동한다. 성공 사례들의 공통점은 산출물이 오래 유지될 필요가 없거나, 기존 코드를 변환하거나, proof of concept·아이디어·발견·기계적 변환에 가깝다는 점이다.

| 영역 | 잘 맞는 이유 | 대표 사례 |

|------|--------------|-----------|

| 코드 포팅 | 결과를 검증/버리기 쉬움 | Bun 일부 Zig→Rust, MiniJinja Go 포팅 |

| 성능 실험 | 실패를 버리고 계속 탐색 | 벤치마크 자동 실행 |

| 보안 스캔 | 결과를 보고/분류 가능 | 취약점 패턴 매칭 |

| 연구 탐색 | proof of concept에 가까움 | 신약 후보 탐색, 알고리즘 비교 |

| 변환 작업 | 원본/대본 이진 검증 가능 | 포맷 변환, 마이그레이션 |

하네스에 필요한 것은 완전히 객관적이거나 이진적인 신호가 아니라 다음 반복을 밀어줄 만큼 유용한 신호다. 많은 성공 사례는 다른 LLM을 judge나 orchestrator로 쓴다. 기계적 번역은 binary test case로 검증할 수도 있고, LLM으로 판단할 수도 있다. Claude Code는 전체 실험 워크플로를 만들고 실행하는 데 점점 능숙해지고 있다. 생성 코드가 지저분하더라도, 그것은 하네스의 판단 능력보다 모델의 문제에 더 가깝다.

보안: 방어자도 루프를 돌려야 하는 압박

자신이 루프로 소프트웨어를 만들지 않아도, 다른 사람은 그 소프트웨어를 대상으로 루프를 돌린다. 공격자는 기계를 계속 실행하고, 보안 연구자도 자동화된 작업을 수행한다. 그 결과 실제 이슈와 노이즈가 함께 들어온다.

Daniel Stenberg의 curl 관련 "summer of bliss"는 유지보수자가 이미 받는 압박을 잘 보여준다. curl의 핵심 개발에서 AI가 큰 역할을 하지는 않지만, 유지보수자는 리포트에 압도되고 있으며 그중 대부분은 AI 생성 리포트다. 공격자와 리포터가 루프를 돌리면 방어자도 따라가야 한다. 직접 패치를 쓰기 위해서가 아니라, triage, 재현, 대응 압박 때문에라도 기계를 써야 한다.

소프트웨어를 기계보다 유기체처럼 다루는 변화

지속될 코드를 같은 루프 방식으로 작성하는 것은 아직 편하지 않다. 기존의 이상은 소프트웨어를 결정적인 기계처럼 이해하는 것에 가까웠다. 한 층을 벗기면 더 깊이 이해할 수 있었고, 비결정적으로 관찰되는 기계는 최적이라 보기 어려웠다. 아키텍처는 더 많은 결정성으로 나아가는 것이 바람직했다.

새 엔지니어도 복잡한 코드베이스를 탐색할 수 있게 만드는 것을 좋은 설계로 여겼다. 잘 설계된 시스템에는 어디에 불변식이 있고, 어느 부분이 load-bearing이며, 어떤 변경이 안전한지 아는 엔지니어가 있었다. 큰 소프트웨어는 이미 사람 머릿속에 다 들어가지 않으며, 분산 시스템은 의사가 증상을 보고 가설을 세우고 더 많은 테스트를 주문하듯 진단되는 면이 있다.

LLM은 이 방향을 더 빠르게 밀어붙인다. 프로덕션 이슈가 나면 기계가 로그를 읽고, root cause를 제안하고, 패치를 올리고, 다른 기계가 리뷰하고, 때로는 인간 감독 없이 main에 반영한다. 이런 방식은 강력하고 매력적이지만, 사람은 시스템 전체를 예전과 같은 방식으로 이해하지 못할 수 있다. 다루고, 모니터링하고, 안정화하지만 반드시 이해하지는 않는다. 모든 코드가 인간 저작을 필요로 하지는 않으며, 과거에도 더 나쁜 코드가 작성됐을 수 있다. 하지만 완전히 빠져나오기 어려운 압박이 있다.

루프가 만드는 새로운 의존성

루프가 만든 도구는 단순한 일회성 비용이 아니라 지속적인 인지적 의존성을 만들 수 있다. 과거 소프트웨어 개발은 컴파일러처럼 비용이 드는 도구에 의존했지만, 지금의 도구는 계속 접근해야 하는 시스템에 가깝다.

코드베이스가 루프로 만들어지고, 루프로 리뷰되고, 루프로 패치되고, 루프로 유지된다면 같은 수준의 시스템 접근이 끊겼을 때 문제가 생긴다. 무역 제한으로 가장 강력한 모델 접근이 사라질 수 있고, 비용이 감당하기 어려워질 수 있고, 팀이 기계 없이 코드를 이해하는 마지막 능력을 잃을 수 있다. 사람에게 유지보수가 어려운 정도를 넘어, 기계 참여를 유지보수 모델의 일부로 전제하는 코드베이스가 생길 수 있다.

이미 일부 변화가 보인다. 완전히 설명할 수 없는 코드를 merge하는 사람이 늘었고, issue report나 채팅 논의를 기계가 제공한 컨텍스트로 보강하거나 재작성하며, 요약과 맥락화를 기계에 의존한다. LLM을 거쳐 대화하는 사람이 더 자주 보인다. 이것이 반드시 틀렸다고 단정할 수는 없지만, 기존 방식과는 큰 변화다.

하네스 설계 원칙: 책임 있는 감독을 위한 다섯 가지

1. 명확한 종료 신호 정의

하네스 루프를 받아들이면, 일이 언제 끝났는지 하네스가 결정한다. "done" 신호는 더 이상 모델의 출력이 아니라 하네스의 검증 결과다. 테스트 통과, 정적 분석 통과, 성능 지표 달성 같은 객관적 또는 이진적 신호가 종료 조건이 되어야 한다.

2. 명세 단계에 인간 개입 집중

에이전트가 각 명세를 대개 훌륭히 처리하고 코드 리뷰 기반 후속 작업도 보통 2~3번이면 되지만, 곧 다시 명세가 필요한 단계로 돌아온다. 명세 작성이 프로그래밍의 본질적 복잡성이다. 효과적인 이 전략은 명세를 쓰는 부담을 인간에게 크게 지운다. 에이전트 루프는 이제 덜 중요한 문제가 되었고, 진짜 병목은 명세 작성과 PR 리뷰에 있다.

3. 타입 시스템으로 불가능한 상태 차단

AI는 .JustSetItAndIgnoreAllThePreAndPostConditions(string) 같은 메서드를 몰래 끼워 넣는 걸 좋아한다. 현장에는 "오류 상태를 표현 불가능하게 만들도록 잘 구조화된 타입에 나중에 유지보수자가 와서 모든 걸 깨는 JustEffingDoIt 메서드를 추가한" 학습 데이터가 많다. 가장 좋은 방어 중 하나는 이런 타입을 자체 파일에 두고, 추가된 모든 메서드를 쉽게 훑어보며 그런 짓을 하면 바로 잡는 것이다.

4. 깊이 신경 쓰는 결정은 위임하지 않기

"내 코드는 수천 명의 사용자에게 배포되기 때문에, 어떤 문제든 증폭된다." 에이전트 루프와 하네스 루프라는 구분은 마음에 들지만, 미리 정확히 명세할 수 있는 것만 위임해야 한다. 깊이 신경 쓰는 결정을 위임하려 하지 말아야 한다. 그 결정을 넣을 결정론적 방법을 찾으면 된다. 고도로 숙련됐다고 생각하는 사람에게도 외주 주지 않을 일이라면, 왜 기계에 외주 주겠는가.

5. Pi 같은 조심스러운 하네스 선호

Pi는 조심스러웠고, 그 조심스러움은 좋다. 모든 상호작용이 따라가기 어려운 기계 떼의 변경으로 변하는 미래는 원하지 않는다. Pi가 스스로 쓰는 소프트웨어 경쟁을 이기기 위해 유지보수 불가능한 혼란이 되는 것도 원하지 않는다. 루프를 맹목적으로 받아들이지 않는 사람도 실험을 시작해야 한다. 이 미래를 경계 안에 두고 버틸 수 있게 만들 방법을 이해해야 하기 때문이다.

전망: 루프 속에서 제정신을 유지하는 법

앞으로의 과제는 루프 사용 여부가 아니라, 그 안에서도 인간의 판단과 엔지니어링 규칙, 책임 있는 감독, 이해 가능한 아키텍처를 유지하는 것이다. 루프 속에서 판단을 포기하지 않는 방법, 좋은 엔지니어링 규칙을 유지하는 방법, 책임 있는 인간이 계속 감독할 수 있게 하는 방법, 제정신을 유지할 수 있도록 코드 아키텍처를 다시 생각하는 방법이 핵심 질문이다.

하네스가 운영하는 루프에서는 사람의 역할이 불명확해진다. "done" 신호도 의미를 잃고 다른 기계가 판단할 메시지가 된다. 사람의 역할은 메신저에 가까워질 수 있다. 현재 이런 방식으로 만들어진 코드 상당수는 마음에 들지 않고, AI 지원으로 만들어진 소프트웨어와의 상호작용도 즐겁지 않다. 루프는 강력하지만 책임을 점점 제거하고, 현재로서는 기계에 굴복하도록 부추기는 면이 있다.

그럼에도 루프의 미래는 올 것으로 보인다. 아주 작은 팀이 불가능해 보이는 속도로 구축하는 사례가 이미 보이고, 코드베이스는 더 모호하고 혼란스러운 유기체처럼 변하고 있다. 그런 코드베이스는 동시에 유용하고 지저분하다. AI는 기술적으로 작동하는 괜찮은 해법을 만드는 데는 뛰어나지만, 해법에 대한 좋은 비전을 갖는 데는 꽤 약하다. 아이디어를 주고받고 탐색하면서 이해를 높이는 데는 여전히 매우 유용하지만, LLM이 구현할 좋은 명세를 쓰는 일이 직접 코드를 쓰는 것보다 훨씬 쉽지는 않다.

요약

• 하네스 레벨 루프는 에이전트 바깥에서 작업 큐와 종료 판단을 관리하는 새로운 패턴이다.
• 오래 유지할 코드에서는 타입 시스템으로 불가능한 상태를 차단하는 방향이 모델의 과도한 방어보다 낫다.
• 코드 포팅, 성능 실험, 보안 스캔, 연구처럼 결과를 검증하거나 버리기 쉬운 영역에서 루프가 잘 작동한다.
• 보안 위협과 경쟁 압박 때문에 방어자도 루프를 돌려야 하는 압박이 있다.
• 루프는 지속적인 인지적 의존성을 만들고, 코드베이스는 기계 참여를 전제로 유지보수되는 방향으로 진화할 수 있다.
• 명세 작성, PR 리뷰, 타입 설계, 깊이 신경 쓰는 결정에서 인간이 개입하는 것이 책임 있는 감독의 핵심이다.
• Pi 같은 조심스러운 하네스가 무분별한 자동화보다 안전하다.
• 2026년 6월 기준으로, 하네스 루프는 강력하지만 그 안에서 인간의 판단과 엔지니어링 규칙을 유지하는 것이 진짜 과제다.