Loop Engineering

About this offer

AI가 정말 빠르게 변화하고 있다고 느끼는 요즘입니다. 2달 전까지만 해도 최신 개념인 Loop Engineering에 대해서 블로그를 쓰려고 했는데 벌써 Loop Engineering을 넘어서 Graph Engineering이라는 이름이 나왔다고 하네요. 그래도 하던 것부터 마무리 하고 다음으로 넘어가겠습니다. Intro 말을 안해도 다들 AI가 정말 빠르게 발전하고 있다는 것을 느끼고 계실겁니다. 제가 AI를 처음 사용했을 때를 생각해 봅니다 24년 하반기까지만 해도 제가 느끼는 AI의 성능은 썩 좋지 않았습니다. md파일 먹이기 이런 개념도 없었을 뿐더러 뭐하나 물어보면 이상한 답변을 줄 때도 많았습니다. 저만 그런게 아니었나 봅니다. 한층 한층 문제들이 개선되더니 정말 기하급수적인 속도로 지금까지 와버렸습니다. 먼저 어떻게 여기까지 왔나 살펴보겠습니다. Prompt Engineering 프롬프트를 입력하여 AI에게 답변을 듣는 방식입니다. 아직까지 대부분의 사람들이 이 방식으로 AI를 사용하고 있을 것이라 생각합니다. 간단한 질문 (요리 레시피 알려줘, 사주 봐줘) 들은 프롬프트 입력만으로 충분히 해결됩니다. 더 나아가 "너는 10년차 컨설턴트야", "너는 운동 코치야" 라면서 AI에게 페르소나를 입혀주기도 합니다. 그래서 Persona Engineering 이라는 단어가 등장하기도 합니다. 하지만 규모가 큰 작업을 하고 있다면? 회사 업무나 프로젝트 등 장기간 업무를 진행해야 하는 상황입니다. AI가 이전 내용을 기억하지 못하는 상황이 발생합니다. 처음부터 다시 알려줘야 하는 상황이 반복됩니다. Context Engineering 프롬프트 입력 전에 AI가 알아야 할 사전 지식을 미리 각인시켜주고, 매 턴 모델이 뭘 볼지, 뭘 뺄지 정하는 방식입니다. AI에게 작업을 맡기기 전에 미리 필요한 지식을 입력해주고, 실질적으로 업무에 도움이 되는 지식을 AI가 선별해 유용한 답변을 받을 수 있습니다. 하지만 여기서 만족하지 않습니다. AI는 행동하지 않습니다. 결국 답변을 받은 사람이 행동으로 연결해야 한다는 귀찮음이 존재합니다. Harness Engineering AI에게 손발을 달아주고, 규제를 걸어줌으로써 안정적이고 정확하게 AI가 스스로 동작하는 방식입니다. MCP, Tool, SubAgent 등 기존에 등장한 도구들을 AI에게 쥐어줌으로써 사고만 하던 AI에서 행동까지 연결하는 AI로 만들어 줍니다. 하지만 아무런 규제 없이 AI에게 과한 권한을 부여해준다면, AI가 무슨 일을 벌일지 예측할 수 없습니다. 그래서 도구와 더불어, 컨텍스트 관리, 권한 규제 등을 같이 입력해 어느 정도 사람이 통제할 수 있는 AI로 만듭니다. 충분히 쓸만해 보입니다. 그렇지만 한번 행동을 하면 결과가 좋든 나쁘든 사람이 확인을 해야합니다. 결과를 확인하고, 수정하고, 다시 실행하고. 상당히 귀찮습니다. Loop Engineering 사람이 매번 띄우는 대신, 띄우고 검사하고 멈추는 일까지 시스템에 맡기는 방식입니다. 인간의 판단 기준을 검증기와 정지 규칙에 한 번 입력해 놓으면, 루프는 검증기 기준과 정지 규칙을 모두 통과할 때까지 반복하여 돕니다. 결국 루프의 판단은 모델의 성능이 아니라 인간이 박아둔 판단에 기반합니다. Loop의 구성요소 루프라고 하면 while 문 한 줄이 떠오르지만, 실제로 굴러가는 루프에는 조각이 몇 개 더 붙습니다. Addy Osmani는 이를 여섯 조각으로 분류했습니다. Automations - 시작 트리거 '언제 무슨 일을 해줘' 요청입니다. 사람이 "이것 좀 해줘"라고 직접 말하는 단계가 사라집니다. Claude Code 의 /loop(주기 실행) 와 /goal(조건 충족까지 실행) 이 여기에 해당합니다. Worktrees - 병렬 작업 공간 격리 여러 에이전트를 동시에 돌리면 같은 파일을 서로 덮어씁니다. git worktree 로 작업 공간을 분리해야 단일 스레드를 벗어날 수 있습니다. Skills - 프로젝트 지식 입력 매 사이클마다 "우리 프로젝트는 이렇게 돌아갑니다"를 다시 설명할 수는 없습니다. 처음으로 작업을 시작(콜드 스타트)한 모델은 모르는 부분을 추측합니다. 저희는 왜 모델이 그렇게 추측했는지 알 수가 없습니다. 이를 방지하기 위해 사전 지식을 파일로 박아둡니다. Connectors - 바깥 세상과의 연결 MCP로 이슈 트래커, DB, CI를 붙입니다. 여기서 "여기 수정안입니다"가 "PR 열었고 티켓 걸어뒀습니다"로 바뀝니다. Sub-agents - 작업 모델, 검사 모델 분리 작업을 수행하는 모델은 자신이 한 작업을 후하게 채점합니다. 그래서 작업 수행 에이전트와 작업 검사 에이전트를 나눕니다. 모델이나 추론 강도를 다르게 주기도 합니다. State / Memory - 기억 저장소 마크다운 파일이든 보드든, 밖에 적어둬야 다음 사이클이 이어집니다. "에이전트는 잊지만 레포는 잊지 않는다." Osmani의 표현입니다. 여섯 개를 다 갖춰도 빠진 게 하나 있습니다. 정지 규칙 입니다. 언제 멈출지를 정하지 않은 루프는 언제 어디서 끝날지 아무도 모릅니다. 밤새 돌려 수백 달러를 태웠다는 후기는 대부분 정지 규칙이 비어 있던 경우입니다. CodeReferee 사실 Loop Engineering을 알고 있기 전부터, 진행하고 있던 프로젝트가 있습니다. 깃허브 레포의 안정성을 검사하고, 개선사항을 알려주는 서비스입니다. Input을 깃허브 레포로 받으면 검증, 피드백, 수정을 거쳐 안정적인 코드로 재탄생시켜주는 서비스입니다. 알게 모르게 이미 Loop Engineering 개념을 적용하고 있었네요. 자세히 한번 살펴보겠습니다. CodeReferee 루프 Repository URL입력 → Preflight → Sandbox 실행 → Judge → Critic → Refiner → 리포트 먼저 Repository URL을 입력으로 받으면 실행 가능한 유효한 주소인지 검사하는 단계( Preflight )를 거칩니다. Preflight가 통과하면 샌드박스에서 Chaos Engineering 을 통해 장애를 주입하고 평가 결과를 도출합니다 결과를 보고 Judge가 Fail을 주면 Critic이 원인을 분석하고 Refiner가 수정안( diff )을 냅니다. 그 수정안을 샌드박스에 적용해 다시 돌립니다. 여기서 봐야할 점은 Loop 구조가 _run_refinement_rounds 함수 하나에 들어 있고, 70줄이 안 된다는 것입니다. 또한 이 70줄에서 대부분이 "반복"이 아니라 "중단"이라는 점입니다. 검증기 검증기는 Judge입니다. 제가 미리 적어둔 판정 기준표를 보고 Pass와 Fail만 냅니다. LLM이 혼자 판단하지 않게 하려는 목적입니다. 인간이 설정한 Chaos Engineering 통과 기준을 넘은 레포에만 '안정' 판정을 주고, 검사 보고서를 함께 냅니다. 정지 규칙 라운드 상한 3회 - 비용적 측면에서 Trade-off 고려 Refiner가 수정안을 못 내면 즉시 중단 - 고칠 수단이 없는데 반복해봐야 같은 결과입니다. 수정안이 1MB를 넘으면 중단 - 수정 범위가 그 정도면 판정 자체를 믿을 수 없습니다. 인프라 오류면 판정을 건너뛰고 중단 - Docker가 죽은 걸 사용자 코드 실패로 보고하면 안 됩니다. 아직 없는 두 조각 구성요소 여섯 개 중 둘이 제 루프에 없습니다. Automations 가 없습니다. 아직 사람이 띄웁니다. 검증과 중단은 시스템이 하는데, 레포 입력은 사용자가 진행합니다. 그래서 엄밀히 말하면 완전히 도는 루프가 아니라, 띄우면 끝까지 알아서 가는 루프입니다. Worktrees 도 없습니다. 이건 필요가 없어서 안 넣었습니다. 레포 하나를 받아 검증하는 구조라 에이전트 여러 개가 같은 파일을 다툴 일이 없습니다. 병렬은 레포 여러 개를 동시에 검증할 때 필요할 것이라 그때 붙일 계획입니다. 느낀점 구성요소를 다 채우는 게 목표가 아니라는 걸 여기서 배웠습니다. Worktrees는 안 넣은 게 맞고, Automations는 사용자가 레포 입력을 하지 않고 자동화할 방법이 있는지 고민 중에 있습니다. 정지 규칙이 본체였습니다. 제 루프의 정지 조건은 설계가 멋져서 넣은 게 아닙니다. 반복 상한이 없으면 같은 실패를 세 번 더 겪습니다. 수정안 크기 상한이 없으면 레포를 새로 쓴 걸 "수정"으로 받습니다. 인프라 오류와 코드 실패를 구분하지 않으면 Docker가 죽은 걸 사용자 잘못으로 보고합니다. 하나하나 당해보고 박아둔 규칙입니다. 루프는 제 판단의 증폭기입니다. 좋은 기준을 넣으면 좋은 판단이 빠른 속도로 반복되고, 나쁜 기준을 넣으면 자신만만한 오답이 빠른 속도로 반복됩니다. 객관적 숫자를 기반으로 기준을 세우려고 했습니다. 프롬프트를 더 잘 쓰는 일에서 멈추는 조건을 더 잘 쓰는 일로. 재미있는 쪽은 전자지만 결과를 정하는 건 후자였습니다.