다가오는 루프

• 코딩 에이전트 바깥에서 작업 큐와 하네스가 반복을 관리하는 하네스 레벨 루프가 에이전트 엔지니어링의 새 중심 패턴으로 떠오르고 있음
• 모델이 오래 자율 실행될수록 강한 불변식보다 국소적 방어와 fallback을 덧붙이기 쉬워, 장기 유지 코드에서는 설계 이해와 통제가 흔들릴 수 있음
• 반대로 코드 포팅, 성능 실험, 보안 스캔, 연구처럼 결과를 검증하거나 버리기 쉬운 영역에서는 기계적 반복이 이미 강하게 작동함
• 공격자와 리포터가 루프를 돌리면 유지보수자도 triage, 재현, 대응에 기계를 써야 하는 압박을 받으며, curl 사례는 AI 생성 리포트가 만드는 부담을 보여줌
• 앞으로의 과제는 루프 사용 여부가 아니라, 그 안에서도 인간의 판단과 엔지니어링 규칙, 책임 있는 감독, 이해 가능한 아키텍처를 유지하는 것임

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

• 코딩 에이전트 내부에는 이미 모델이 도구를 호출하고, 결과를 반영하고, 파일을 읽고 수정하고, 테스트를 실행한 뒤 답을 내는 에이전트 루프가 있음
• 새롭게 두드러지는 패턴은 그 바깥의 하네스 레벨 루프임
  • 작업이 큐에 들어감
  • 기계가 작업을 집어 시도함
  • 멈춘 뒤 하네스가 실제로 끝났는지 판단함
  • 끝나지 않았다면 같은 세션에 메시지를 주입하거나, 수정된 컨텍스트로 새 세션을 시작하거나, 다른 기계에 작업을 넘김
• 이 바깥 루프는 모델이 보통 “끝났다”고 말할 지점 이후에도 작업을 계속 살아 있게 만듦
• 루프 자체는 새롭지 않지만, 최근 에이전트 엔지니어링과 Twitter 담론에서 더 자주 보이기 시작함
• Pi 위에서도 이런 흐름이 일부 나타나며, Pi는 하네스이기 때문에 이런 실험의 중심에 놓임

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

• 깊이 신경 쓰는 코드에는 아직 이 방식이 잘 맞지 않음
• 핵심은 취향과 통제임
  • 배포하는 코드를 이해하고 싶음
  • 압박 상황이나 다른 사람과의 논의에서, 먼저 기계에게 설명을 시키지 않고 시스템 동작을 설명할 수 있어야 함
  • 현재로서는 코드 이해가 여전히 중요함
• 손을 떼고 생성된 코드, 특히 루프에서 나온 코드에는 반복되는 문제가 있음
  • 너무 방어적임
  • 너무 복잡함
  • 국소적 추론에 머묾
  • 강한 불변식을 피함
  • 잘못된 상태를 불가능하게 만들기보다 fallback을 추가함
  • 중복 코드와 나쁜 추상화를 만들고, 불명확한 설계를 더 많은 장치로 덮음
• Claude Code와 Fable 같은 조합은 한 문제를 30분 이상 끊기지 않고 작업할 수 있어, 이전보다 human in the loop가 줄어듦
• 현재 손을 뗀 하네스 방식의 코드 품질은 지난가을보다 더 나빠졌다고 느껴질 정도이며, 적어도 이 취향에서는 개선이 거의 보이지 않음

루프가 모델의 습관을 증폭함

• 모델은 국소적 실패를 보면 국소적 방어를 추가하는 경향이 있음
• Andrej Karpathy는 모델들이 예외를 “치명적으로 두려워한다”고 말한 바 있음
• 중요한 불변식이 있는 시스템, 특히 영속 데이터 포맷이나 핵심 인프라에서는 “모든 malformed case를 처리”하는 방식이 올바른 수정이 아닐 수 있음
  • 더 나은 방향은 malformed case를 표현할 수 없게 만들거나 처음부터 쓸 수 없게 만드는 것임
  • LLM은 많은 수동 조향이 있어도 이런 코드를 자연스럽게 내놓기 어렵고, 불가능해진 오류까지 처리하려 할 수 있음
• 이 습관을 루프 뒤에 두면 문제가 증폭됨
  • 각 반복이 작은 방어를 하나씩 더함
  • 시스템은 더 견고해 보이지만 점점 이해하기 어려워짐
  • 손을 더 뗄수록 이런 경향이 커짐
• 명확한 지침 없이 주니어에게 이런 도구를 주면 나쁜 실천을 학습시킬 수 있음
  • 이유를 물으면 그럴듯하게 자기 선택을 변호할 수 있음

루프가 잘 맞는 영역

• 루프 패턴은 이미 일부 영역에서 매우 잘 작동함
• 코드 포팅은 대표적인 사례임
  • Bun 일부를 Zig에서 Rust로 옮기는 작업 같은 대규모 자동 포팅 사례가 있음
  • MiniJinja를 Go로 포팅하는 데도 성공적으로 사용됨
• 성능 탐색에도 잘 맞음
  • 기계가 실험을 시도함
  • 벤치마크를 실행함
  • 실패를 버림
  • 계속 탐색함
• 보안 스캔과 거의 모든 종류의 연구에도 자연스럽게 맞음
  • 복잡한 문제 공간을 탐색하고 결과를 보고하게 할 수 있음
  • 반드시 오래 남을 코드를 커밋할 필요가 없음
• 성공적인 사례들의 공통점은 산출물이 오래 유지될 필요가 없거나, 기존 코드를 변환하거나, proof of concept·아이디어·발견·기계적 변환에 가깝다는 점임
• 하네스에 필요한 것은 완전히 객관적이거나 이진적인 신호가 아니라 다음 반복을 밀어줄 만큼 유용한 신호임
  • 많은 성공 사례는 다른 LLM을 judge나 orchestrator로 씀
  • 기계적 번역은 binary test case로 검증할 수도 있고, LLM으로 판단할 수도 있음
• Claude Code는 전체 실험 워크플로를 만들고 실행하는 데 점점 능숙해지고 있음
  • 생성 코드가 지저분하더라도, 그것은 하네스의 판단 능력보다 모델의 문제에 더 가까움

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

• 지속될 코드를 같은 루프 방식으로 작성하는 것은 아직 편하지 않음
• 기존의 이상은 소프트웨어를 결정적인 기계처럼 이해하는 것에 가까웠음
  • 한 층을 벗기면 더 깊이 이해할 수 있었음
  • 비결정적으로 관찰되는 기계는 최적이라 보기 어려웠음
  • 아키텍처는 더 많은 결정성으로 나아가는 것이 바람직했음
  • 새 엔지니어도 복잡한 코드베이스를 탐색할 수 있게 만드는 것을 좋은 설계로 여김
• 잘 설계된 시스템에는 어디에 불변식이 있고, 어느 부분이 load-bearing이며, 어떤 변경이 안전한지 아는 엔지니어가 있었음
• 큰 소프트웨어는 이미 사람 머릿속에 다 들어가지 않으며, 분산 시스템은 의사가 증상을 보고 가설을 세우고 더 많은 테스트를 주문하듯 진단되는 면이 있음
• LLM은 이 방향을 더 빠르게 밀어붙임
  • 프로덕션 이슈가 나면 기계가 로그를 읽음
  • root cause를 제안함
  • 패치를 올림
  • 다른 기계가 리뷰하고, 때로는 인간 감독 없이 main에 반영함
• 이런 방식은 강력하고 매력적이지만, 사람은 시스템 전체를 예전과 같은 방식으로 이해하지 못할 수 있음
  • 다루고, 모니터링하고, 안정화하지만 반드시 이해하지는 않음
• 모든 코드가 인간 저작을 필요로 하지는 않으며, 과거에도 더 나쁜 코드가 작성됐을 수 있음

완전히 빠져나오기 어려운 압박

• 완전한 기계 주도 미래에서 opt out하기 어려울 수 있음
• 보안이 가장 명확한 사례임
  • 자신이 루프로 소프트웨어를 만들지 않아도, 다른 사람은 그 소프트웨어를 대상으로 루프를 돌림
  • 공격자는 기계를 계속 실행함
  • 공격자가 아니더라도 보안 연구자가 자동화된 작업을 수행함
  • 그 결과 실제 이슈와 노이즈가 함께 들어옴
• Daniel Stenberg의 curl 관련 summer of bliss는 유지보수자가 이미 받는 압박을 보여줌
  • curl의 핵심 개발에서 AI가 큰 역할을 하지는 않는 것으로 보임
  • 그래도 유지보수자는 리포트에 압도되고 있으며, 그중 대부분은 AI 생성 리포트임
• 공격자와 리포터가 루프를 돌리면 방어자도 따라가야 함
  • 반드시 직접 패치를 쓰기 위해서가 아닐 수 있음
  • triage, 재현, 대응 압박 때문에 기계를 써야 할 수 있음
• 경쟁 압박도 비슷함
  • 어떤 팀은 순수한 속도로 다른 팀보다 더 많이 만들 수 있음
  • 작은 그룹이 기계를 잘 조율하면 프로젝트가 갑자기 빨라질 수 있음
  • 어떤 스타트업은 예전에는 50명이 필요하던 일을 5명으로 할 수 있음
  • 누군가는 제품을 대상으로 루프를 돌려 “다른 것처럼 만들라”고 시킬 수 있음
• 모든 소프트웨어가 똑같이 영향받지는 않음
  • 일부 영역은 허술함을 벌하고 신뢰와 책임을 요구함
  • 많은 소프트웨어에서는 속도, 빠른 실험, 넓은 커버리지가 매우 중요함

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

• 루프가 만든 도구는 단순한 일회성 비용이 아니라 지속적인 인지적 의존성을 만들 수 있음
• 과거 소프트웨어 개발은 컴파일러처럼 비용이 드는 도구에 의존했지만, 지금의 도구는 계속 접근해야 하는 시스템에 가까움
• 코드베이스가 루프로 만들어지고, 루프로 리뷰되고, 루프로 패치되고, 루프로 유지된다면 같은 수준의 시스템 접근이 끊겼을 때 문제가 생김
  • 무역 제한으로 가장 강력한 모델 접근이 사라질 수 있음
  • 비용이 감당하기 어려워질 수 있음
  • 팀이 기계 없이 코드를 이해하는 마지막 능력을 잃을 수 있음
• 사람에게 유지보수가 어려운 정도를 넘어, 기계 참여를 유지보수 모델의 일부로 전제하는 코드베이스가 생길 수 있음
• 이미 일부 변화가 보임
  • 완전히 설명할 수 없는 코드를 merge하는 사람이 늘어남
  • issue report나 채팅 논의를 기계가 제공한 컨텍스트로 보강하거나 재작성함
  • 요약과 맥락화를 기계에 의존함
  • LLM을 거쳐 대화하는 사람이 더 자주 보임
• 이것이 반드시 틀렸다고 단정할 수는 없지만, 기존 방식과는 큰 변화임

앞으로 필요한 하네스와 도구

• 더 많은 루프를 조율하는 것만으로는 충분하지 않음
• 변경, 오케스트레이션, 에이전트를 더 잘 시각화해도 이해가 자동으로 회복되지는 않음
• 필요한 방향은 둘 중 하나임
  • 인간을 다시 루프 안으로 충격적으로 끌어들이고, 루프의 변경을 장기적으로 읽을 수 있게 만드는 방법
  • 점점 복잡해지는 시스템을 더 잘 조합하는 방법
• Pi에 대한 생각도 바뀌고 있음
  • Pi는 조심스러웠고, 그 조심스러움은 좋음
  • 모든 상호작용이 따라가기 어려운 기계 떼의 변경으로 변하는 미래는 원하지 않음
  • Pi가 스스로 쓰는 소프트웨어 경쟁을 이기기 위해 유지보수 불가능한 혼란이 되는 것도 원하지 않음
  • Pi가 이런 엔지니어링을 장려하는 것도 원하지 않음
• 그래도 Pi는 하네스이며, 하네스는 새로운 실험의 중심에 있음
• 코딩 작업 큐, 에이전트 오케스트레이션, subagent, durable session은 점점 더 중요해질 것임
• 루프를 맹목적으로 받아들이지 않는 사람도 실험을 시작해야 함
  • 이 미래를 경계 안에 두고 버틸 수 있게 만들 방법을 이해해야 하기 때문임

루프를 통제하는 문제

• 하네스 루프를 받아들이면, 일이 언제 끝났는지 하네스가 결정함
• 에이전트 루프에서는 모델이 결국 “done”이라고 말하고 사람이 리뷰함
  • 그 전에도 보통 사람이 중간에 조향함
  • 사람은 관여하고, 그 과정에서 배움
• 하네스가 운영하는 루프에서는 사람의 역할이 불명확해짐
  • “done” 신호도 의미를 잃고 다른 기계가 판단할 메시지가 됨
  • 사람의 역할은 메신저에 가까워질 수 있음
• 현재 이런 방식으로 만들어진 코드 상당수는 마음에 들지 않고, AI 지원으로 만들어진 소프트웨어와의 상호작용도 즐겁지 않음
• 루프는 강력하지만 책임을 점점 제거하고, 현재로서는 기계에 굴복하도록 부추기는 면이 있음
• 그럼에도 루프의 미래는 올 것으로 보임
  • 아주 작은 팀이 불가능해 보이는 속도로 구축하는 사례가 이미 보임
  • 코드베이스는 더 모호하고 혼란스러운 유기체처럼 변하고 있음
  • 그런 코드베이스는 동시에 유용하고 지저분함
• 앞으로의 질문은 “루프를 돌릴 것인가”가 아니라 다음에 가까움
  • 루프 속에서 판단을 포기하지 않는 방법
  • 좋은 엔지니어링 규칙을 유지하는 방법
  • 책임 있는 인간이 계속 감독할 수 있게 하는 방법
  • 제정신을 유지할 수 있도록 코드 아키텍처를 다시 생각하는 방법