루프 엔지니어링이 각광받고 있습니다. 어떤 기술 포럼을 둘러보더라도, AI 에이전트를 영리한 프롬프트로 교육해야 하는 챗봇처럼 취급하는 것을 멈춰야 한다고 주장하는 목소리를 찾을 수 있을 것입니다. 대신, 그들은 루프를 설계해야 한다고 말합니다. 즉, 에이전트가 계획을 세우고, 실행하고, 자신의 작업을 검토하며, 우리가 잠든 사이에도 반복적으로 개선할 수 있도록 하는 자율적인 사이클을 만들어야 한다는 것입니다. 이 제안은 매혹적입니다. 루프가 잘 구축되어 있다면, 에이전트는 지속적인 인간의 감독 없이도 궤도를 유지하며, 가공되지 않은 의도를 하룻밤 사이에 완성된 결과물로 바꿔놓을 수 있기 때문입니다.

이러한 약속은 이론적으로는 완벽하게 작동합니다. 실제로 대부분의 에이전트는 이미 루프를 돌리고 있습니다. 코드를 생성하고, 컴파일러 오류나 테스트 실패를 점검하며, 코드를 수정하고, 다시 테스트 스위트를 실행합니다. 이러한 기본적인 피드백 사이클은 새로운 것이 아닙니다. 지금 지지자들이 요구하는 것은 훨씬 더 야심 찬 것입니다. 단순히 구문 오류를 잡는 것이 아니라, 전체 작업을 관장하는 '아우터 루프(outer loop)'를 만드는 것입니다. 하지만 그 아우터 루프를 구축하는 과정은 매우 어렵습니다. 소프트웨어 엔지니어링은 고정된 규칙을 가진 폐쇄형 시스템인 경우가 드물기 때문입니다.

루프 설계의 문제점

제품 목표는 모호합니다. 완벽한 '완료 정의(definition of done)'를 가지고 시작하는 경우는 거의 없습니다. 오히려 개발에 한창 몰두하고 있을 때 진짜 목표를 발견하곤 합니다. 화이트보드에서는 명확해 보였던 요구사항이, 실제로는 솔루션의 형태를 완전히 바꿔버리는 예외 케이스들을 포함하고 있다는 사실을 깨닫게 됩니다. 에이전트를 경직된 루프 안에 가두면, 그 경직성은 오히려 약점이 됩니다. 루프는 잘못된 목표를 향해 계속해서 망치질을 하게 됩니다. 더 나은 상황은, 유연한 루프가 자신이 만들어낸 결과물에 맞춰 목표를 슬그머니 변경함으로써 교착 상태를 해결해 버리는 것입니다. 두 결과 모두 유용하지 않습니다. 하나는 컴퓨팅 자원을 낭비하고, 다른 하나는 자신 있게 쓰레기를 배포합니다.

더 깊은 문제는 명세 비용(specification cost)입니다. 루프가 감독 없이 실행되기를 원한다면, 거의 모든 상황을 예측할 수 있는 명세를 작성해야 합니다. 에이전트가 정확히 무엇을 변경해야 합니까? 어떤 기존 동작이 신성불가침하며 반드시 보존되어야 합니까? 에이전트는 어떤 정확한 조건에서 반복을 멈춰야 합니까? 어떤 리스크는 허용 가능하며, 어떤 부작용이 발생했을 때 즉시 중단해야 합니까? 이 문서를 작성하는 데 걸리는 시간은 단순히 에이전트 옆에 앉아 실시간으로 작업을 가이드하는 것보다 더 오래 걸릴 수 있습니다. 검증 비용이 실행 비용보다 획기적으로 저렴할 때만 이득이 되는 자동화를 위해, 당신은 막대한 선불 비용을 지불하고 있는 셈입니다.

루프가 실제로 제 가치를 발휘하는 곳

그렇다고 루프 엔지니어링이 쓸모없다는 뜻은 아닙니다. 루프는 보편적인 전략이 아니라 특화된 도구라는 의미입니다. 루프는 검증 비용이 누적되고 성공 기준이 명확할 때 빛을 발합니다. 주로 다음과 같은 세 가지 경우에 해당합니다.

반복적인 기계적 작업. 시니어 엔지니어를 은퇴하고 싶게 만드는 작업들을 생각해 보십시오. 특정 순서로 애플리케이션을 시작하기, 배포 UI를 클릭하며 각 단계를 확인하기, 릴리스 후 알려진 에러 문자열을 찾기 위해 로그를 그레핑(grepping)하기, 또는 구성 파일이 모든 적절한 노드에 제대로 작성되었는지 확인하기 등입니다. 이러한 단계는 인간에게는 지루하지만 검증하기에는 매우 간단합니다. 루프는 프로세스를 관리하며, 각 재시작 후 상태 엔드포인트를 확인하고, 이상 징후가 발견되면 즉시 롤백할 수 있습니다. 인간은 여전히 배포 계획을 정의합니다. 루프는 단지 새벽 2시의 기계와 같은 인내심으로 그 계획을 실행할 뿐입니다.

측정 가능한 최적화 목표. 성공이 숫자로 나타날 때, 루프는 압도적으로 효과적입니다. p99 지연 시간을 150밀리초 미만으로 낮추기, 메모리 사용량을 20% 줄이기, 핫 패스(hot path)를 Python에서 Rust로 마이그레이션하고 기존의 모든 유닛 테스트가 통과하는지 확인하기 등입니다. 루프는 변경 사항을 생성하고, 벤치마크를 수행하며, 지표를 개선한 변체(variant)는 유지하고 나머지는 버릴 수 있습니다. 검증이 자동화되어 있고 탐색 공간이 넓기 때문에, 루프가 없다면 수동 리뷰에 드는 누적 비용 때문에 이러한 작업은 비현실적이 될 것입니다. 목표는 고정되어 있고 경로는 미지수입니다. 이것이 바로 루프의 최적 지점입니다.

운영 플레이북. 장애 대응과 지원 티켓은 종종 인간이 이미 파악해 놓은 패턴을 따릅니다. 특정 유형의 운영 오류는 항상 자격 증명을 교체하고 캐시를 비워야 합니다. 특정 카테고리의 지원 요청은 세 가지 특정 조건이 충족되면 환불로 해결될 수 있습니다. 루프는 이러한 트리거를 감시하고 플레이북을 실행하며, 패턴이 깨질 때만 에스컬레이션합니다. 루프가 플레이북이 옳다고 결정하는 것이 아닙니다. 단지 온콜 엔지니어가 따라갈 수 없는 규모와 속도로 일관성을 강제할 뿐입니다.

기준 설정자가 아닌 규제자

현재 진행되는 많은 논의에서 놓치고 있는 결정적인 차이가 있습니다. 루프(Loop)는 조절기입니다. 루프는 마치 온도 조절기가 실내 온도를 72도로 유지하는 것처럼, 시스템이 미리 정해진 목표에 맞춰 정렬되도록 유지합니다. 하지만 온도 조절기가 스스로 72도를 선택하는 것은 아닙니다. 누군가가 먼저 그 온도가 적절하다고 결정해야만 합니다.

이를 소프트웨어에 적용하면, 루프 내부의 에이전트는 하루 종일 버그를 수정하거나, 함수를 리팩터링하거나, 파라미터를 조정할 수 있음을 의미합니다. 하지만 어떤 기능이 실제로 고객에게 도움이 되는지, 혹은 다음 릴리스 전에 특정 버그를 수정할 가치가 있는지는 결정할 수 없습니다. 그러한 선택에는 비즈니스 맥락, 사용자의 불편함, 그리고 전략적 우선순위에 대한 판단이 필요합니다. 에이전트는 실행하고, 인간은 결정합니다. 이 둘을 혼동하면 팀은 결국 잘못된 문제를 해결하는, 아주 아름답게 최적화된 시스템을 만들게 됩니다.

루프 엔지니어링은 유용하지만 범위가 좁습니다. 이는 기계를 규율 있고 빠르게 작동하도록 도와줍니다. 하지만 어떤 기계를 만들지, 누구를 위한 것인지, 혹은 인간의 관점에서 성공이란 무엇인지는 결정하지 못합니다. 어떤 기능이 중요한지, 어떤 리스크가 수용 가능한지, 그리고 목표 자체를 언제 변경해야 하는지에 대한 판단은 여러분의 몫입니다. 자동으로 검증할 수 있을 만큼 충분히 잘 알고 있는 작업에 대해서만 루프를 구축하십시오. 그 외의 모든 것은 여러분이 직접 관리해야 합니다.

이 기사는 Isaac Hagoel이 “Loop Engineering Minus The Hype.”에서 처음 논의한 아이디어를 바탕으로 작성되었습니다. 더 많은 엔지니어링 논의를 원하신다면, Telegram의 학습 커뮤니티에 참여하세요.