--- title: "코딩 에이전트의 다음 단계는 ‘프롬프트’가 아니라 ‘루프’다" published: 2026-06-23T11:06:41.000Z canonical: https://jeff.news/article/4326 --- # 코딩 에이전트의 다음 단계는 ‘프롬프트’가 아니라 ‘루프’다 Armin Ronacher가 코딩 에이전트 위에 얹히는 하네스 루프의 부상에 대해 길게 쓴 글이야. 자동 반복 작업은 포팅, 벤치마크, 보안 탐색에서는 이미 강력하지만, 오래 살아남아야 하는 코드까지 맡기면 이해 가능성과 책임이 무너질 수 있다는 우려가 핵심이야. ## 루프가 코딩 에이전트의 중심으로 올라오고 있음 - 글쓴이는 요즘 직접 Claude에 프롬프트를 던지는 대신, Claude를 계속 프롬프트하는 “루프”를 작성하는 사람들이 늘고 있다고 봄 - 작업이 큐에 들어가고, 기계가 집어 들고, 시도하고, 멈추면, 바깥 하네스가 진짜 끝났는지 판단함 - 끝이 아니라고 판단하면 같은 세션을 이어가거나, 수정된 컨텍스트로 새 세션을 열거나, 다른 기계에 넘김 - 모델이 “나 끝났음”이라고 말한 뒤에도 작업이 계속 살아 있는 게 핵심임 - 여기서 말하는 루프는 코딩 에이전트 내부 루프와 다름 - 내부 루프는 모델이 도구를 호출하고, 파일을 읽고, 코드를 고치고, 테스트를 돌리는 익숙한 흐름임 - 새로 중요해지는 건 그 바깥의 하네스 레벨 루프임 - 이 하네스가 완료 여부, 재시도, 세션 지속, 다른 에이전트 투입을 결정함 ```mermaid sequenceDiagram participant 사람 participant 하네스 participant 코딩에이전트 participant 테스트 participant 평가기 사람->>하네스: 작업을 큐에 넣음 하네스->>코딩에이전트: 코드 수정 지시 코딩에이전트->>테스트: 실행 및 결과 확인 테스트-->>코딩에이전트: 실패 또는 성공 신호 코딩에이전트-->>하네스: 완료 보고 하네스->>평가기: 진짜 완료인지 판단 요청 평가기-->>하네스: 추가 반복 필요 하네스->>코딩에이전트: 컨텍스트 보강 후 재시도 ``` ## 오래 살아야 하는 코드에는 아직 찝찝함이 큼 - 글쓴이는 자신이 깊게 신경 쓰는 코드에서는 이 방식이 아직 잘 맞지 않았다고 말함 - 이유는 취향도 있지만, 더 크게는 통제감과 이해 가능성임 - 압박 상황이나 사람과의 토론에서 “이 시스템이 뭘 하는지”를 직접 설명할 수 있어야 한다고 봄 - 지금은 코드를 이해하는 능력이 여전히 중요하다는 입장임 - 현재 모델이 만드는 코드는 글쓴이 기준으로 너무 방어적이고, 복잡하고, 지역적 판단에 갇히는 경향이 있음 - 강한 불변식(invariant)을 세워 잘못된 상태를 애초에 만들 수 없게 하기보다, 실패 지점마다 fallback을 덧붙이는 쪽으로 감 - 중복 코드, 나쁜 추상화, 불명확한 설계를 기계 장치로 덮는 패턴도 자주 보인다고 함 - 사람 개입 없이 30분 이상 이어지는 작업에서는 이 문제가 더 커진다고 봄 > [!WARNING] > 루프는 매 반복마다 “작은 방어 코드”를 추가할 수 있음. 겉보기엔 더 튼튼해진 것 같지만, 실제로는 시스템이 점점 이해하기 어려워질 수 있다는 게 이 글의 가장 날카로운 지점임. - 특히 중요한 시스템에서는 “모든 이상 케이스를 처리하자”가 정답이 아닐 수 있음 - 영속 데이터 포맷이나 핵심 인프라에서는 잘못된 상태가 쓰이지 못하게 만드는 게 더 좋은 설계일 때가 많음 - 그런데 LLM은 지역적 실패를 보면 그 주변에 방어막을 치는 식으로 반응하기 쉬움 - Karpathy가 모델들이 예외(exception)를 “죽을 만큼 무서워한다”고 말한 맥락도 여기와 닿아 있음 ## 그렇다고 루프가 안 먹히는 건 절대 아님 - 글쓴이는 루프 패턴이 이미 놀랄 만큼 잘 작동하는 영역도 분명하다고 인정함 - 코드 포팅이 대표적임 - Bun 일부를 Zig에서 Rust로 옮기는 작업 사례가 언급되고, 글쓴이도 MiniJinja를 Go로 포팅할 때 성공적으로 써봤다고 함 - 기존 코드를 다른 형태로 옮기는 작업은 새 설계를 발명하는 것보다 검증하기 쉬움 - 성능 실험도 루프와 잘 맞음 - 기계가 여러 실험을 시도하고, 벤치마크를 돌리고, 실패를 버리고, 계속 탐색할 수 있음 - 오래 유지할 코드가 아니라 실험용 코드나 증거를 만드는 데 가까우면 품질 기준이 달라짐 - 보안 스캐닝과 연구 작업도 복잡한 문제 공간을 탐색하고 보고서를 내는 식이라 루프와 궁합이 좋음 - 성공하는 루프의 공통점은 결과물이 오래 살아야 하는 코드가 아니거나, 검증 가능한 기계적 변환이라는 점임 - 바이너리 테스트 케이스로 검증할 수도 있고, 다른 LLM을 평가자나 오케스트레이터로 둘 수도 있음 - 하네스가 필요한 건 완벽한 객관식 정답이 아니라 다음 반복을 밀어줄 만한 신호임 - 그래서 실험 워크플로를 만들고 직접 실행하는 능력은 이미 꽤 강력하다고 봄 ## 문제는 인간이 시스템을 덜 이해하게 되는 방향임 - 글쓴이는 소프트웨어가 결정적인 기계에서 진단해야 하는 유기체처럼 바뀌고 있다고 표현함 - 예전의 이상은 시스템의 레이어를 벗겨가며 이해를 깊게 하는 것이었음 - 좋은 아키텍처는 새 엔지니어도 복잡한 코드베이스를 탐색할 수 있게 만드는 데 자부심이 있었음 - 어디에 불변식이 있고, 어떤 부분이 하중을 버티고, 어떤 변경이 안전한지 아는 사람이 있는 게 중요했음 - 대형 시스템은 LLM 이전에도 이미 한 사람 머리에 다 들어가지 않는 경우가 많았음 - 분산 시스템은 증상을 보고, 가설을 세우고, 테스트를 더 돌리고, 처방을 시도하는 식으로 다뤄져 왔음 - 하지만 LLM은 이 흐름을 훨씬 더 빠르고 멀리 밀고 있음 - 장애가 나면 기계가 로그를 읽고, 원인을 제안하고, 패치를 올리고, 다른 기계가 리뷰해서 메인에 넣는 흐름까지 가능해짐 - 이건 강력하지만, 동시에 “우리가 더 이상 전체를 같은 방식으로 이해하지 않는다”는 걸 받아들이는 일이기도 함 - 코드를 치료하고, 모니터링하고, 안정화할 수는 있음 - 하지만 반드시 이해하는 건 아닐 수 있음 - 모든 코드가 인간 저작권을 필요로 하는 건 아니지만, 모든 소프트웨어가 이렇게 만들어져도 괜찮은지는 별도 문제임 ## 보안과 경쟁 압력이 루프를 강제로 밀어붙일 수 있음 - 루프를 쓰지 않겠다고 개인이나 팀이 결정해도 완전히 벗어나긴 어려울 수 있음 - 공격자는 계속 자동화된 기계를 돌릴 수 있음 - 보안 연구자도 자동화 루프를 돌리고, 그 결과 진짜 이슈와 노이즈가 함께 쏟아질 수 있음 - curl 메인테이너들이 AI 생성 리포트에 압도되고 있다는 사례가 이런 압력을 보여줌 - 공격자와 리포터가 루프를 쓰면 방어자도 결국 루프를 써야 할 가능성이 큼 - 꼭 패치를 자동으로 쓰게 하자는 뜻은 아님 - triage, 재현, 우선순위 판단만 해도 사람 힘으로 감당하기 어려운 볼륨이 될 수 있음 - 자동화된 문제 제기에 자동화된 선별이 따라붙는 흐름은 꽤 현실적임 > [!IMPORTANT] > “루프를 쓸까 말까”보다 더 현실적인 질문은 “남들이 루프를 쓰는 세상에서 내 팀은 어떤 경계와 검증 장치를 둘 것인가”에 가까움. - 경쟁에서도 비슷한 일이 벌어짐 - 어떤 팀은 작은 인원으로 기계를 잘 오케스트레이션해서 훨씬 빠르게 만들 수 있음 - 5명이 예전의 50명 팀이 하던 일을 하는 스타트업도 나올 수 있음 - 누군가는 당신의 제품을 대상으로 “저거랑 비슷하게 만들어”라는 루프를 돌릴 수도 있음 ## 진짜 숙제는 판단을 포기하지 않는 방법임 - 글쓴이가 가장 불편해하는 건 기계 의존성이 돈 문제를 넘어 인지 의존성으로 간다는 점임 - 예전에는 컴파일러 같은 도구에 돈을 냈지만, 지금은 지속적인 모델 접근이 개발 능력의 일부가 됨 - 코드베이스가 루프로 작성되고, 루프로 리뷰되고, 루프로 패치되고, 루프로 유지되면 같은 급의 모델이 없을 때 어떻게 되느냐는 문제가 생김 - 비용, 접근 제한, 무역 규제, 팀의 이해 능력 저하가 모두 리스크가 됨 - 그래서 단순히 더 많은 루프를 오케스트레이션하는 것만으로는 부족함 - 변경을 더 잘 보여주는 시각화만으로도 인간의 이해가 자동 복구되진 않음 - 인간을 다시 의미 있게 끌어들이는 방법이 필요함 - 아니면 점점 복잡해지는 시스템을 더 잘 조합하고 제한하는 새로운 아키텍처가 필요함 - 결론은 루프의 미래가 오지 않을 거라는 얘기가 아님 - 글쓴이는 오히려 루프가 미래라는 데 의심이 거의 없다고 말함 - 다만 그 미래에서 좋은 엔지니어링 규칙, 인간의 감독, 책임 있는 판단을 어떻게 남길지가 핵심 질문임 - “기계에게 맡기느냐”가 아니라 “기계가 반복하는 세계에서 인간이 무엇을 판단해야 하느냐”의 문제임 --- ## 기술 맥락 - 이 글에서 중요한 선택지는 코딩 에이전트를 한 번 쓰는 수준이 아니라, 하네스가 작업 완료를 판단하고 다시 실행하게 만드는 구조예요. 왜냐면 모델 한 번의 답변보다 반복 실행과 평가가 실제 생산성을 크게 바꾸기 때문이에요. - 루프가 잘 맞는 작업은 대체로 검증 신호가 있어요. 포팅은 기존 테스트를 통과하면 되고, 성능 실험은 벤치마크 숫자가 있고, 보안 탐색은 재현 가능성이 있으니까 하네스가 다음 반복을 결정하기 쉬워요. - 반대로 장기 유지 코드는 “테스트가 통과했다”만으로 충분하지 않아요. 불변식이 어디에 있는지, 나쁜 상태를 애초에 막는지, 팀원이 설명 가능한 구조인지가 중요한데, 이 부분은 현재 LLM이 지역적 방어 코드로 덮어버리기 쉬워요. - 그래서 앞으로 팀이 설계해야 할 건 프롬프트만이 아니에요. 작업 큐, 평가 기준, 중단 조건, 사람이 반드시 봐야 하는 변경 범위, 자동화가 해도 되는 영역을 정하는 하네스 자체가 개발 프로세스의 핵심 컴포넌트가 될 가능성이 커요. - 보안 쪽 압력도 무시하기 어려워요. 공격자와 리포터가 자동 루프를 돌리면 유지보수자는 최소한 triage와 재현에 기계를 붙여야 버틸 수 있거든요. 이건 선택이라기보다 운영 규모의 문제에 가까워요. ## 핵심 포인트 - 에이전트 내부 루프와 별개로, 작업 큐·재시도·평가·재시작을 담당하는 하네스 레벨 루프가 커지고 있음 - 현재 모델은 지역적 실패를 보고 방어 코드를 덧붙이는 경향이 있어 오래 유지할 코드에서는 복잡도를 키울 수 있음 - 코드 포팅, 성능 실험, 보안 탐색, 연구처럼 검증 신호가 있는 작업에서는 루프가 이미 꽤 잘 먹힘 - 공격자와 리포터가 자동 루프를 쓰면 방어자도 triage와 재현을 위해 루프를 쓸 수밖에 없다는 압력이 생김 - 앞으로의 질문은 루프를 쓸지 말지가 아니라, 인간의 판단과 좋은 엔지니어링 규칙을 어떻게 남길지에 가까움 ## 인사이트 이 글은 ‘AI 코딩 좋다/싫다’가 아니라 자동화의 단위가 바뀌고 있다는 얘기라서 중요해. 한국 개발팀도 곧 코드 생성보다 작업 큐, 검증 하네스, 자동 리뷰, 보안 triage 설계를 더 진지하게 다루게 될 가능성이 큼.