다가오는 루프

다가오는 루프(The Looming Loop)란 무엇일까요?

최근 에이전트 엔지니어링 분야에서 아주 흥미로운 변화가 관찰되고 있습니다. 기존의 코딩 에이전트 내부 루프를 넘어, 작업 큐와 하네스(Harness)가 전체 반복 과정을 관리하는 '하네스 레벨 루프(Harness-level loop)'가 새로운 중심 패턴으로 떠오르고 있는 것이죠.

모델이 스스로 판단하여 더 오래 자율 실행될수록, 시스템 전체를 관통하는 명확한 설계 규칙(불변식)보다는 임시방편적인 국소적 방어와 예외 처리(fallback)가 덕지덕지 붙기 쉽습니다. 이는 장기적으로 코드의 설계를 이해하고 통제하는 능력을 흔들리게 만듭니다. 반면, 코드 포팅이나 성능 실험, 보안 스캔처럼 결과를 빠르게 검증하고 버릴 수 있는 영역에서는 이 기계적 반복이 벌써 엄청난 효율을 보여주고 있습니다.

앞으로 마주할 진짜 과제는 "루프를 쓸 것인가 말 것인가"가 아닙니다. 이 거대한 흐름 속에서도 어떻게 인간의 판단력과 엔지니어링 규칙, 책임 있는 감독, 그리고 이해 가능한 아키텍처를 유지할 것인가입니다.

코딩 에이전트 바깥에서 도는 루프

기존의 코딩 에이전트 내부에는 모델이 도구를 호출하고, 결과를 확인하고, 코드를 수정한 뒤 테스트를 실행해 답을 내는 '에이전트 루프'가 이미 존재했습니다. 하지만 지금 주목해야 할 패턴은 그 바깥에서 작동하는 하네스 레벨의 루프입니다.

작업 흐름은 대략 다음과 같은 순서로 진행됩니다.

• 작업 대기: 해결해야 할 작업이 큐(Queue)에 들어갑니다.
• 시도: 기계(에이전트)가 작업을 집어 들고 해결을 시도합니다.
• 판단: 작업이 멈추면, 하네스가 이 작업이 실제로 완전히 끝났는지 검증합니다.
• 반복 및 이관: 만약 끝나지 않았다면, 하네스가 기존 세션에 추가 피드백 메시지를 주입하거나, 컨텍스트를 새로 정리해 새 세션을 시작하거나, 아예 다른 기계로 작업을 넘겨버립니다.

이 바깥쪽 루프는 모델이 스스로 "완성했다"고 판단하고 손을 뗄 만한 시점 이후에도, 작업이 성공할 때까지 억지로 생명을 불어넣어 계속 돌아가게 만듭니다. 이러한 패턴은 최근 트위터(X) 등 개발자 커뮤니티의 에이전트 엔지니어링 담론에서 끊임없이 언급되고 있으며, 소프트웨어 테스팅 환경인 Pi 위에서도 이런 실험적 흐름이 적극적으로 나타나고 있습니다.

오래 유지할 코드에서 생기는 불편함

우리가 깊이 신경 쓰고 오랫동안 관리해야 하는 소스 코드에는 아직 이 방식이 잘 맞지 않습니다. 가장 큰 원인은 '개발자의 주관(취향)'과 '시스템에 대한 통제력' 때문입니다.

• 시스템 동작을 완전히 이해하고 싶어 하는 욕구: 우리는 급박한 장애 상황이나 팀원과의 치열한 기술 논의 속에서, AI에게 매번 설명을 구하지 않고도 시스템이 왜 이렇게 동작하는지 즉각 설명할 수 있기를 원합니다. 즉, 여전히 인간의 직접적인 코드 이해가 핵심입니다.
• 손을 뗀 채 생성된 코드의 한계: 루프를 반복하며 자동으로 생성된 코드에는 고질적인 부작용이 있습니다. 코드가 지나치게 방어적이고 복잡해지며, 전체 맥락 대신 당장의 국소적 에러 해결에만 몰두합니다. 전체를 꿰뚫는 강한 아키텍처적 불변식을 설계하기보다는 대충 에러를 넘기는 fallback 장치만 끊임없이 덧댑니다. 결국 중복 코드와 조잡한 추상화가 가득한 시스템이 되어 버립니다.

Claude Code와 Fable 같은 강력한 도구들은 인간의 개입 없이도 하나의 문제를 30분 이상 쉬지 않고 집요하게 물고 늘어질 수 있습니다. 하지만 역설적이게도 이렇게 탄생한 코드의 실질적인 품질은 예전보다 더 어수선하고 지저분해졌다고 느끼는 개발자들이 많습니다.

루프가 모델의 나쁜 습관을 증폭하는 방식

LLM은 본질적으로 에러나 실패를 보면 그 자리에 국소적인 방어막을 치는 성향이 있습니다. 안드레 카파시(Andrej Karpathy)는 모델들이 예외(Exception)가 발생하는 것을 "치명적일 정도로 두려워한다"고 지적한 바 있죠.

하지만 영속 데이터 포맷이나 핵심 인프라처럼 구조적 안정이 중요한 시스템에서는 "모든 잘못된 데이터 형식을 예외 없이 우회 처리하는 것"이 결코 올바른 해결책이 아닙니다. 오히려 애초에 잘못된 형식이 생성되거나 유입될 수 없도록 시스템 구조를 굳건하게 닫아버리는 것(Make invalid states unrepresentable)이 최선입니다.

문제는 이 해결 과정을 자동화 루프에 맡겨버릴 때 발생합니다.

• 루프가 돌 때마다 코드가 해결해야 할 구멍에 얇은 땜질용 패치가 하나씩 더해집니다.
• 테스트는 통과하므로 겉보기에는 시스템이 더 견고해진 것처럼 보입니다.
• 하지만 내부를 열어보면 도저히 전체 흐름을 이해할 수 없는 난해한 코드가 쌓여 있습니다.
• 이러한 도구를 숙련되지 않은 주니어 개발자에게 쥐여주면, 그럴듯한 변명에 속아 나쁜 아키텍처 습관을 정답으로 오해하고 학습하게 될 위험이 큽니다.

전통적 개발 방식과 루프 기반 개발 방식의 비교

루프 패턴이 압도적인 효율을 내는 영역

그렇다면 하네스 레벨 루프는 전혀 쓸모없는 것일까요? 그렇지 않습니다. 영구히 유지보수할 필요가 없거나 결과물의 정답 여부를 기계적으로 명확히 판별할 수 있는 영역에서는 이미 독보적인 효율을 자랑합니다.

• 대규모 코드 포팅(Porting): 예를 들어 Bun 프로젝트의 일부를 Zig에서 Rust로 옮기거나, MiniJinja를 Go 언어로 자동 포팅하는 작업에서 눈부신 성과를 거두었습니다.
• 성능 및 벤치마크 탐색: 기계가 새로운 성능 최적화 실험 코드를 작성하고, 벤치마크를 돌려본 뒤, 성능이 개선되지 않으면 가차 없이 버리고 다음 실험을 이어가는 방식입니다.
• 보안 취약점 스캔 및 탐색 연구: 아주 넓고 복잡한 보안 영역을 탐색해 보고서를 제출하는 것 역시 루프 패턴이 완벽하게 해결해 낼 수 있는 이상적인 과제입니다.

이러한 성공 사례들의 공통점은 코드가 역사적인 아키텍처적 가치를 가질 필요가 없거나, 기계적인 변환 및 발견 단계에 머무른다는 점입니다.

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

우리는 오랫동안 소프트웨어를 완벽하게 예측 가능한 '결정론적인 기계'로 설계하고 이해해 왔습니다. 코드 한 꺼풀을 벗겨내면 더 깊고 명확한 작동 원리를 이해할 수 있는 것, 그리고 새로운 엔지니어가 와도 쉽게 탐색할 수 있는 코드를 좋은 아키텍처의 표준으로 삼았죠.

하지만 대규모 시스템이 인간의 머리로 담을 수 없을 만큼 복잡해지면서, 이제 시스템 장애가 나면 기계가 로그를 읽고 원인을 추론하여 스스로 패치를 올리고, 또 다른 AI가 이를 리뷰해 운영 환경에 곧바로 반영하는 풍경이 낯설지 않게 되었습니다.

이 방식은 엄청나게 매력적이고 빠르지만, 결정적인 부작용을 낳습니다.

우리는 시스템을 통제하고 모니터링하며 어떻게든 돌아가게 만들 수는 있지만, 그 시스템이 정확히 어떤 아키텍처적 원리로 굴러가는지 아무도 완벽하게 설명하지 못하는 유기체적 상태를 마주하게 됩니다.

완전히 빠져나오기 어려운 시스템 경쟁의 압박

이런 기계 주도의 흐름이 마음에 들지 않는다고 해서 혼자서만 이 미래를 거부(Opt out)하기란 쉽지 않습니다.

가장 대표적인 분야가 보안입니다. 내가 기계식 루프로 코드를 짜지 않더라도, 해커나 공격자들은 나의 오픈소스나 제품을 타깃으로 24시간 내내 자동화된 루프를 돌리며 취약점을 캐내고 있습니다. 오픈소스 curl의 메인 유지보수자인 다니엘 스텐버그(Daniel Stenberg)의 사례처럼, 개발자들은 끊임없이 쏟아지는 정교한 AI 생성 버그 리포트와 스팸성 취약점 공격에 압도당하고 있으며, 이에 대응하기 위해 방어자 역시 울며 겨자 먹기로 AI 자동화 대응 루프를 도입할 수밖에 없는 처지에 놓여 있습니다.

비즈니스 경쟁 역시 마찬가지입니다. 50명이 필요하던 작업을 단 5명의 인간과 고도로 조율된 기계 하네스로 해결해 내는 스타트업이 등장하고, 믿을 수 없는 속도로 제품을 뽑아내기 시작하면 기존의 전통적인 설계 방식을 고수하던 팀들은 시장의 속도 경쟁에서 뒤처질 수밖에 없습니다.

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

이 패턴이 고착화되면 단순한 일회성 비용을 넘어 심각한 '인지적 의존성'이 생겨납니다. 과거의 컴파일러는 도구에 불과했지만, 현재의 AI 루프는 끊임없이 상호작용해야 하는 하나의 '의존 시스템'입니다.

만약 특정 국가의 무역 규제로 강력한 거대 언어 모델(LLM)에 대한 접근이 막히거나 비용이 감당할 수 없을 정도로 치솟는다면 어떻게 될까요? 기계의 도움 없이는 아무도 전체 시스템을 이해하지 못하는 코드베이스를 둔 채, 팀 전체가 마비될 위험성이 있습니다. 실제로 이미 많은 조직에서 전체 흐름을 완벽히 설명하지 못하는 코드를 머지하고, 기계가 작성해 준 요약 정보에 완전히 의존해 대화하는 기이한 현상이 나타나고 있습니다.

우리가 나아가야 할 질문들

결국 하네스 루프를 허용하는 순간, 작업의 종결 선언마저 인간이 아닌 하네스의 AI 판단기가 결정하게 됩니다. 인간의 역할은 점차 주도적인 설계자에서 기계들 사이의 메시지를 중개하는 메신저로 밀려날지 모릅니다.

하지만 그렇다고 해서 이 거대한 흐름을 아예 막아설 수는 없을 것입니다. 그렇기에 우리는 이제 맹목적으로 기계식 루프에 굴복할 것이 아니라, 다음과 같은 질문을 품고 도구를 설계해 나가야 합니다.

• 루프 속에서 인간이 지혜로운 판단력을 잃지 않고 중심을 잡는 방법은 무엇인가?
• 기계가 코드를 짜더라도 좋은 엔지니어링 규칙과 아키텍처를 강제할 수 있는 시스템을 어떻게 구축할 것인가?
• 사람이 계속 책임지고 시스템을 감독할 수 있는 직관적인 장치는 무엇인가?
• 이 혼란스럽고 복잡해지는 미래에 제정신을 유지할 수 있는 완전히 새로운 코드 아키텍처는 무엇인가?

루프가 다가오고 있습니다. 우리는 이 루프를 통제할 수 있는 영리한 하네스 엔지니어링의 시대를 준비해야 합니다.