코딩 에이전트의 다음 단계는 ‘프롬프트’가 아니라 ‘루프’다

루프가 코딩 에이전트의 중심으로 올라오고 있음

• 글쓴이는 요즘 직접 Claude에 프롬프트를 던지는 대신, Claude를 계속 프롬프트하는 “루프”를 작성하는 사람들이 늘고 있다고 봄

  • 작업이 큐에 들어가고, 기계가 집어 들고, 시도하고, 멈추면, 바깥 하네스가 진짜 끝났는지 판단함
  • 끝이 아니라고 판단하면 같은 세션을 이어가거나, 수정된 컨텍스트로 새 세션을 열거나, 다른 기계에 넘김
  • 모델이 “나 끝났음”이라고 말한 뒤에도 작업이 계속 살아 있는 게 핵심임

• 여기서 말하는 루프는 코딩 에이전트 내부 루프와 다름

  • 내부 루프는 모델이 도구를 호출하고, 파일을 읽고, 코드를 고치고, 테스트를 돌리는 익숙한 흐름임
  • 새로 중요해지는 건 그 바깥의 하네스 레벨 루프임
  • 이 하네스가 완료 여부, 재시도, 세션 지속, 다른 에이전트 투입을 결정함

sequenceDiagram
    participant 사람
    participant 하네스
    participant 코딩에이전트
    participant 테스트
    participant 평가기
    사람->>하네스: 작업을 큐에 넣음
    하네스->>코딩에이전트: 코드 수정 지시
    코딩에이전트->>테스트: 실행 및 결과 확인
    테스트-->>코딩에이전트: 실패 또는 성공 신호
    코딩에이전트-->>하네스: 완료 보고
    하네스->>평가기: 진짜 완료인지 판단 요청
    평가기-->>하네스: 추가 반복 필요
    하네스->>코딩에이전트: 컨텍스트 보강 후 재시도

오래 살아야 하는 코드에는 아직 찝찝함이 큼

• 글쓴이는 자신이 깊게 신경 쓰는 코드에서는 이 방식이 아직 잘 맞지 않았다고 말함

  • 이유는 취향도 있지만, 더 크게는 통제감과 이해 가능성임
  • 압박 상황이나 사람과의 토론에서 “이 시스템이 뭘 하는지”를 직접 설명할 수 있어야 한다고 봄
  • 지금은 코드를 이해하는 능력이 여전히 중요하다는 입장임

• 현재 모델이 만드는 코드는 글쓴이 기준으로 너무 방어적이고, 복잡하고, 지역적 판단에 갇히는 경향이 있음

  • 강한 불변식(invariant)을 세워 잘못된 상태를 애초에 만들 수 없게 하기보다, 실패 지점마다 fallback을 덧붙이는 쪽으로 감
  • 중복 코드, 나쁜 추상화, 불명확한 설계를 기계 장치로 덮는 패턴도 자주 보인다고 함
  • 사람 개입 없이 30분 이상 이어지는 작업에서는 이 문제가 더 커진다고 봄

• 특히 중요한 시스템에서는 “모든 이상 케이스를 처리하자”가 정답이 아닐 수 있음
  • 영속 데이터 포맷이나 핵심 인프라에서는 잘못된 상태가 쓰이지 못하게 만드는 게 더 좋은 설계일 때가 많음
  • 그런데 LLM은 지역적 실패를 보면 그 주변에 방어막을 치는 식으로 반응하기 쉬움
  • Karpathy가 모델들이 예외(exception)를 “죽을 만큼 무서워한다”고 말한 맥락도 여기와 닿아 있음

그렇다고 루프가 안 먹히는 건 절대 아님

• 글쓴이는 루프 패턴이 이미 놀랄 만큼 잘 작동하는 영역도 분명하다고 인정함

  • 코드 포팅이 대표적임
  • Bun 일부를 Zig에서 Rust로 옮기는 작업 사례가 언급되고, 글쓴이도 MiniJinja를 Go로 포팅할 때 성공적으로 써봤다고 함
  • 기존 코드를 다른 형태로 옮기는 작업은 새 설계를 발명하는 것보다 검증하기 쉬움

• 성능 실험도 루프와 잘 맞음

  • 기계가 여러 실험을 시도하고, 벤치마크를 돌리고, 실패를 버리고, 계속 탐색할 수 있음
  • 오래 유지할 코드가 아니라 실험용 코드나 증거를 만드는 데 가까우면 품질 기준이 달라짐
  • 보안 스캐닝과 연구 작업도 복잡한 문제 공간을 탐색하고 보고서를 내는 식이라 루프와 궁합이 좋음

• 성공하는 루프의 공통점은 결과물이 오래 살아야 하는 코드가 아니거나, 검증 가능한 기계적 변환이라는 점임

  • 바이너리 테스트 케이스로 검증할 수도 있고, 다른 LLM을 평가자나 오케스트레이터로 둘 수도 있음
  • 하네스가 필요한 건 완벽한 객관식 정답이 아니라 다음 반복을 밀어줄 만한 신호임
  • 그래서 실험 워크플로를 만들고 직접 실행하는 능력은 이미 꽤 강력하다고 봄

문제는 인간이 시스템을 덜 이해하게 되는 방향임

• 글쓴이는 소프트웨어가 결정적인 기계에서 진단해야 하는 유기체처럼 바뀌고 있다고 표현함

  • 예전의 이상은 시스템의 레이어를 벗겨가며 이해를 깊게 하는 것이었음
  • 좋은 아키텍처는 새 엔지니어도 복잡한 코드베이스를 탐색할 수 있게 만드는 데 자부심이 있었음
  • 어디에 불변식이 있고, 어떤 부분이 하중을 버티고, 어떤 변경이 안전한지 아는 사람이 있는 게 중요했음

• 대형 시스템은 LLM 이전에도 이미 한 사람 머리에 다 들어가지 않는 경우가 많았음

  • 분산 시스템은 증상을 보고, 가설을 세우고, 테스트를 더 돌리고, 처방을 시도하는 식으로 다뤄져 왔음
  • 하지만 LLM은 이 흐름을 훨씬 더 빠르고 멀리 밀고 있음
  • 장애가 나면 기계가 로그를 읽고, 원인을 제안하고, 패치를 올리고, 다른 기계가 리뷰해서 메인에 넣는 흐름까지 가능해짐

• 이건 강력하지만, 동시에 “우리가 더 이상 전체를 같은 방식으로 이해하지 않는다”는 걸 받아들이는 일이기도 함

  • 코드를 치료하고, 모니터링하고, 안정화할 수는 있음
  • 하지만 반드시 이해하는 건 아닐 수 있음
  • 모든 코드가 인간 저작권을 필요로 하는 건 아니지만, 모든 소프트웨어가 이렇게 만들어져도 괜찮은지는 별도 문제임

보안과 경쟁 압력이 루프를 강제로 밀어붙일 수 있음

• 루프를 쓰지 않겠다고 개인이나 팀이 결정해도 완전히 벗어나긴 어려울 수 있음

  • 공격자는 계속 자동화된 기계를 돌릴 수 있음
  • 보안 연구자도 자동화 루프를 돌리고, 그 결과 진짜 이슈와 노이즈가 함께 쏟아질 수 있음
  • curl 메인테이너들이 AI 생성 리포트에 압도되고 있다는 사례가 이런 압력을 보여줌

• 공격자와 리포터가 루프를 쓰면 방어자도 결국 루프를 써야 할 가능성이 큼

  • 꼭 패치를 자동으로 쓰게 하자는 뜻은 아님
  • triage, 재현, 우선순위 판단만 해도 사람 힘으로 감당하기 어려운 볼륨이 될 수 있음
  • 자동화된 문제 제기에 자동화된 선별이 따라붙는 흐름은 꽤 현실적임

• 경쟁에서도 비슷한 일이 벌어짐
  • 어떤 팀은 작은 인원으로 기계를 잘 오케스트레이션해서 훨씬 빠르게 만들 수 있음
  • 5명이 예전의 50명 팀이 하던 일을 하는 스타트업도 나올 수 있음
  • 누군가는 당신의 제품을 대상으로 “저거랑 비슷하게 만들어”라는 루프를 돌릴 수도 있음

진짜 숙제는 판단을 포기하지 않는 방법임

• 글쓴이가 가장 불편해하는 건 기계 의존성이 돈 문제를 넘어 인지 의존성으로 간다는 점임

  • 예전에는 컴파일러 같은 도구에 돈을 냈지만, 지금은 지속적인 모델 접근이 개발 능력의 일부가 됨
  • 코드베이스가 루프로 작성되고, 루프로 리뷰되고, 루프로 패치되고, 루프로 유지되면 같은 급의 모델이 없을 때 어떻게 되느냐는 문제가 생김
  • 비용, 접근 제한, 무역 규제, 팀의 이해 능력 저하가 모두 리스크가 됨

• 그래서 단순히 더 많은 루프를 오케스트레이션하는 것만으로는 부족함

  • 변경을 더 잘 보여주는 시각화만으로도 인간의 이해가 자동 복구되진 않음
  • 인간을 다시 의미 있게 끌어들이는 방법이 필요함
  • 아니면 점점 복잡해지는 시스템을 더 잘 조합하고 제한하는 새로운 아키텍처가 필요함

• 결론은 루프의 미래가 오지 않을 거라는 얘기가 아님

  • 글쓴이는 오히려 루프가 미래라는 데 의심이 거의 없다고 말함
  • 다만 그 미래에서 좋은 엔지니어링 규칙, 인간의 감독, 책임 있는 판단을 어떻게 남길지가 핵심 질문임
  • “기계에게 맡기느냐”가 아니라 “기계가 반복하는 세계에서 인간이 무엇을 판단해야 하느냐”의 문제임

기술 맥락

• 이 글에서 중요한 선택지는 코딩 에이전트를 한 번 쓰는 수준이 아니라, 하네스가 작업 완료를 판단하고 다시 실행하게 만드는 구조예요. 왜냐면 모델 한 번의 답변보다 반복 실행과 평가가 실제 생산성을 크게 바꾸기 때문이에요.

• 루프가 잘 맞는 작업은 대체로 검증 신호가 있어요. 포팅은 기존 테스트를 통과하면 되고, 성능 실험은 벤치마크 숫자가 있고, 보안 탐색은 재현 가능성이 있으니까 하네스가 다음 반복을 결정하기 쉬워요.

• 반대로 장기 유지 코드는 “테스트가 통과했다”만으로 충분하지 않아요. 불변식이 어디에 있는지, 나쁜 상태를 애초에 막는지, 팀원이 설명 가능한 구조인지가 중요한데, 이 부분은 현재 LLM이 지역적 방어 코드로 덮어버리기 쉬워요.

• 그래서 앞으로 팀이 설계해야 할 건 프롬프트만이 아니에요. 작업 큐, 평가 기준, 중단 조건, 사람이 반드시 봐야 하는 변경 범위, 자동화가 해도 되는 영역을 정하는 하네스 자체가 개발 프로세스의 핵심 컴포넌트가 될 가능성이 커요.

• 보안 쪽 압력도 무시하기 어려워요. 공격자와 리포터가 자동 루프를 돌리면 유지보수자는 최소한 triage와 재현에 기계를 붙여야 버틸 수 있거든요. 이건 선택이라기보다 운영 규모의 문제에 가까워요.