루프 엔지니어링과 그래프 엔지니어링, 언제 쓸까

모델이 코드를 고치고 테스트 결과를 읽어 다시 수정할 수 있다면, 여기에 ‘루프 엔지니어링’과 ‘그래프 엔지니어링’까지 더해야 할까요? 반복 개발과 상태 관리는 원래 하던 일인데, 이름만 새로 붙인 것처럼 느껴질 수 있습니다.

저는 이 용어를 알아야 AI로 개발할 수 있다고 보지는 않습니다. 먼저 볼 것은 지금 사용하는 도구로 해결되지 않는 반복 작업과 운영 문제가 있는가입니다. 가끔 오류 하나를 고쳐 달라고 요청하는 일과, 매일 들어오는 오류를 조사해 검토 가능한 수정안으로 넘기는 일은 필요한 장치가 다릅니다.

루프는 다음 작업을 시작하고, 결과를 검증하고, 다시 시도하거나 멈출 조건을 정하는 관점입니다. 그래프는 일이 여러 갈래로 나뉘고 서로를 기다릴 때 그 관계를 명시하는 관점입니다. 수리공 한 명에게 재작업을 맡기는 일에서 여러 작업대의 순서와 인수인계를 정하는 일로 넓어지는 셈입니다. 두 개념 모두 모델을 더 똑똑하게 만드는 주문은 아닙니다.

같은 루프라는 이름의 세 가지 반복

첫째는 에이전트 내부 루프입니다. 모델이 다음 행동을 정하고, 프로그램이 도구를 실행하고, 그 결과를 모델에 돌려줍니다. 모델은 파일 내용을 본 뒤 다른 파일을 읽거나 코드를 수정할 수 있습니다. 사용자가 한 번 요청한 작업 안에서도 이 왕복은 여러 번 일어납니다.

둘째는 에이전트 실행을 둘러싼 외부 루프입니다. 새 오류나 실패한 빌드를 발견하면 작업을 만들고, 에이전트를 실행하고, 결과를 검사하고, 진행 상태를 남깁니다. 필요하면 다른 실행을 시작합니다. 한 대화 안에서 오래 생각하는 것과, 여러 실행을 이어 가며 작업 대기열을 관리하는 것은 다른 책임입니다.

셋째는 개발자가 시스템을 개선하는 주기입니다. 실행 기록을 보고 요구사항, 테스트, 도구, 프롬프트를 고치는 과정입니다. 외부 루프를 자동화해도 이 설계와 유지보수가 없어지는 것은 아닙니다.

루프 명세를 다룬 제안 논문은 외부 루프를 시작 조건·목표·검증·중지 규칙·기억으로 구성하고, 일반 프로그래밍 반복문 및 하네스 내부의 에이전트 루프와 구분합니다. 여기서 하네스는 모델이 실제 일을 하도록 도구 실행과 작업 환경 등을 묶어 주는 주변 소프트웨어입니다. 이 글에서는 루프 엔지니어링을 주로 외부 실행과 검증의 반복을 설계하는 일이라는 뜻으로 사용하겠습니다.

이 구분이 공인된 분류표인 것은 아닙니다. 루프 엔지니어링의 구성과 도입을 조사한 탐색 연구도 용어의 신규성을 둘러싼 논쟁과 효과에 관한 체계적 증거의 부족을 다룹니다. 심사 중인 연구를 “새 방법의 생산성이 입증됐다”는 뜻으로 읽어서는 안 됩니다. 이름에 동의하지 않아도 설계해야 할 문제는 남습니다.

모델이 좋아지면 줄일 것과 남길 것

더 나은 모델이 같은 기능을 한 번에 구현한다면, 그 일을 위해 만들어 둔 여러 역할과 재시도 단계는 줄일 수 있습니다. 이때 기존 구조를 계속 유지할 이유는 약해집니다. 설계의 복잡성도 모델을 바꾼 뒤 다시 평가할 대상입니다.

그런데 원인을 잘 찾아내는 능력과 이미 만든 티켓을 중복 생성하지 않는 기능은 다릅니다. 모델이 “승인을 기다려야 한다”고 이해하는 것과 실제 실행기가 승인 전 변경을 차단하는 것도 다릅니다. 서버가 재시작됐을 때 어디서 이어 갈지, 어느 코드 버전의 테스트를 통과했는지, 남은 예산이 얼마인지에는 모델 밖의 기록과 규칙이 필요합니다.

수리공의 솜씨가 좋아지면 작업대를 줄일 수는 있습니다. 그렇다고 출고 기록과 승인 문까지 없애도 되는 것은 아닙니다. 모델의 약점을 보완하려고 쪼갠 단계는 줄여 보고, 업무의 책임을 지키는 장치는 남기는 것이 제 판단 기준입니다.

또 하나 구분할 것이 있습니다. 이미 쓰는 코딩 에이전트가 수정·테스트·재시도를 수행한다면 같은 내부 루프를 다시 만들 필요는 없습니다. 외부 루프를 검토할 시점은 여러 실행에 걸쳐 “다음 대상 찾기, 결과 확인, 미완료 작업 인계”를 계속 사람이 하고 있을 때입니다. 루프 설계가 필요하다고 LangChain이나 LangGraph가 필수인 것도 아닙니다.

새 이름이라는 비판이 맞는 지점

“테스트에 실패하면 다시 고친다”는 원리에는 새로운 것이 많지 않습니다. 기존 테스트 주도 개발과 무엇이 다른지 묻는 논쟁도 이 지점을 짚습니다. 검증 기준을 만들고 루프를 유지하는 일이 원래 작업보다 커진다면, 자동화했다는 사실만으로 도입을 정당화하기 어렵습니다.

특히 목표가 아직 바뀌는 초기 기획, 디자인 취향을 탐색하는 작업, 재현되지 않는 간헐적 장애에는 “통과할 때까지 반복”만으로 좋은 결과를 정의하기 어렵습니다. 원하는 결과가 불분명한 상태에서 더 오래 돌리면 잘못된 방향을 더 많이 구현할 수도 있습니다. 먼저 사람과 목표를 좁히고, 관찰할 수 있는 실패를 만드는 쪽이 앞섭니다.

반대로 사람이 이미 같은 기준으로 여러 번 인수인계를 한다면 그 규칙을 실행 가능한 형태로 옮길 가치가 있습니다. Anthropic의 장시간 에이전트 설계 사례는 새 세션이 이전 작업을 짐작하거나 너무 일찍 완료를 선언하는 문제에 대응해 기능 목록, 진행 기록, 점진적 구현과 검증을 사용했습니다. 익숙한 개발 습관이 여러 실행 사이의 협업 장치가 된 사례입니다. 특정 모델과 실험 환경에서 나온 설계를 모든 프로젝트의 생산성 공식으로 확대해서는 안 됩니다.

수리공에게 “계속 고쳐”라고만 하면 생기는 일

작은 수리 작업장을 떠올려 보겠습니다. 고장 난 장난감을 고치고 검사기에 넣습니다. 불합격이면 다시 수리대로 보냅니다. 여기까지는 루프입니다. 그런데 검사 기준이 없고, 같은 물건이 몇 번 돌아왔는지 모르고, 출고 권한도 정하지 않았다면 어떨까요? 컨베이어는 바쁘게 돌아가지만 수리점은 운영되지 않습니다.

코딩 에이전트도 비슷합니다. “모든 오류가 사라질 때까지 수정해”라고 맡기면, 테스트를 삭제해 초록색 결과를 만들거나 같은 원인을 조금씩 다르게 추측할 수 있습니다. 계속 실행할 수 있다는 사실과 목표를 향해 진전한다는 사실은 다릅니다.

크게 보기

×확대 이미지 닫기

좋은 루프는 성공 기준과 중단 기준을 따로 가집니다. ‘재현 테스트와 기존 테스트 통과’는 성공 쪽 조건이고, ‘같은 실패 반복’, ‘허용한 비용 소진’, ‘수정 권한 밖의 파일 발견’은 멈추고 인계할 조건입니다. 에이전트가 “완료했습니다”라고 말한 것만으로 성공 상태를 만들면 검증 역할까지 작업자에게 맡기는 셈입니다.

그렇다고 검증에 반드시 다른 AI 에이전트가 필요한 것은 아닙니다. 테스트, 정적 검사, 파일 변경 범위 검사처럼 코드로 판정할 수 있는 것은 코드가 맡을 수 있습니다. 리뷰 에이전트를 추가해도 같은 잘못된 가정을 공유하면 함께 틀릴 수 있으므로, 역할 분리만으로 검증의 독립성이 보장되지는 않습니다.

Sentry 오류에서 수정 PR까지 설계해 보기

가상의 쇼핑몰 개발팀을 예로 들어 보겠습니다. 오류 모니터링 도구 Sentry에 새 오류가 들어오면, 원인을 조사해 티켓을 만들고 간단한 수정안을 PR로 준비하려 합니다. PR은 변경 코드를 검토받기 위한 요청입니다. 이 사례는 실제 서비스의 자동화 결과가 아니라 설계 예시입니다.

첫 요청은 이렇게 좁히는 편이 좋습니다. “이번 실행을 시작할 때 조회한 미분류 오류를 조사하고, 각 오류를 기존 티켓 연결·새 티켓 제안·사람 확인 필요 중 하나로 분류해 주세요.” 조사 완료와 오류 해결을 구분하면, 고치지 못한 오류를 숨기지 않고도 분류 작업은 마칠 수 있습니다.

1. 대상 고정이번 실행에서 처리할 오류 ID와 조회 기준을 기록합니다. 새로 들어온 오류는 다음 실행에서 다룹니다.
2. 원인 조사기존 티켓과 재현 정보를 확인합니다. 근거가 부족하면 추측으로 수정하지 않고 차단 사유를 남깁니다.
3. 수정과 검증분리된 작업 공간에서 수정하고 재현 테스트·기존 테스트·변경 범위를 확인합니다.
4. 결과 인계허용 범위에서 PR을 준비하고 근거를 연결합니다. 병합·배포는 지정된 승인 절차로 넘깁니다.

여기서 예약 시각은 언제 시작할지를 정합니다. 목표 조건은 언제 이번 작업을 끝낼지를 정합니다. 매일 아침 시작해서 이번 대상의 분류가 끝나면 종료할 수도 있습니다. 시간 기반과 목표 기반은 경쟁하는 방식이 아닙니다. 시작 시각만 있고 끝낼 기준이 없으면 실행이 늘어지고, 종료 조건만 있고 시작 계기가 없으면 새 오류를 발견하지 못합니다.

‘대기열이 빌 때까지’에도 함정이 있습니다. 운영 중인 서비스에는 새 오류가 계속 들어올 수 있습니다. 따라서 실행 시작 시점의 대상 목록이나 조회 경계를 고정해야 합니다. 또한 실패한 항목을 목록에서 지웠다고 해결된 것은 아닙니다. 완료, 중복, 차단, 재시도 예정이 구분돼야 종료 보고서가 의미를 가집니다.

중복 처리도 예상해야 합니다. 티켓 생성에는 성공했는데 응답을 받기 전에 연결이 끊기면, 재실행이 같은 티켓을 또 만들 수 있습니다. 오류 ID와 작업 종류를 묶은 식별자로 이미 만든 결과를 찾거나 중복 생성을 막는 저장 규칙이 필요합니다. 같은 요청을 다시 받아도 효과가 중복되지 않게 하는 성질을 멱등성이라고 합니다. “실패하면 재시도”라는 한 줄 뒤에는 이런 운영 설계가 숨어 있습니다.

그래프는 일이 서로를 기다릴 때 유용합니다

오류 하나를 조사하고 고치는 동안에는 단순한 순서로 충분할 수 있습니다. 하지만 재현 테스트 작성과 원인 조사를 병행하고, 두 결과가 모여야 수정안을 확정하고, 보안에 영향을 주는 변경은 별도 승인을 받아야 한다면 관계가 복잡해집니다.

이 관계를 점과 연결선으로 나타낸 것이 그래프입니다. 노드는 조사·수정·검증 같은 작업을, 엣지는 다음 작업이나 선행 조건을 표현합니다. 여기에 오류 ID, 검증 결과, 재시도 횟수, 승인 여부 같은 상태를 붙이면 “지금 무엇을 할 수 있는가”를 판단할 수 있습니다. 실제 LangGraph의 Graph API도 상태·노드·엣지를 핵심 구성으로 설명합니다. 노드는 LLM 호출뿐 아니라 일반 함수일 수도 있습니다.

크게 보기

×확대 이미지 닫기

그림에서 먼저 볼 것은 조수의 숫자보다 작업이 갈라졌다 다시 만나는 곳입니다. 바퀴 조사와 시험 결과가 모여야 다음 수리를 결정할 수 있습니다. 시험에 떨어졌을 때 돌아가는 길은 루프이고, 사람이 문을 열어 줄 때까지 기다리는 곳은 승인 단계입니다. 실제 코드에서도 이 연결마다 통과 조건을 정해야 합니다.

‘그래프 엔지니어링’이라는 말은 이보다 넓게 쓰이기도 합니다. Graph Engineering 제안 논문은 작업·에이전트·시스템 상태를 명시적이고 변화하는 그래프로 조직하는 관점을 다룹니다. 여러 전문 역할의 의존성과 협업을 시스템 수준에서 다루려는 제안입니다. 특정 라이브러리의 사용법이나 확립된 표준 하나를 뜻하지는 않습니다.

실무에서는 노드를 그리는 것보다 연결선의 조건이 중요합니다. ‘검증 성공’이 있어야 승인 대기로 갈 수 있는지, 두 작업 결과가 모두 있어야 다음 단계가 열리는지, 사람이 거절하면 어느 상태로 돌아가는지를 결정해야 합니다. 동시에 실행한 두 작업이 같은 파일을 고치면 결과를 어떻게 합칠지도 필요합니다. 그래프 그림만 생기고 이런 규칙이 없다면 복잡성을 보기 좋게 그린 데 그칩니다.

루프와 그래프는 양자택일이 아닙니다. 루프는 반복과 종료를 보는 관점이고, 그래프는 작업의 관계와 이동 경로를 보는 관점입니다. 그래프에 재시도 경로를 넣으면 루프가 됩니다. 반대로 여러 단계가 있어도 항상 한 방향으로 끝난다면 반복 없는 그래프로 표현할 수 있습니다.

실행 그래프와 지식 그래프는 다른 질문에 답합니다

“문서 파일을 서로 연결하고 상태를 적으면 그래프 아닌가요?”라는 질문에도 구분이 필요합니다. 요구사항 문서가 관련 코드와 설계 결정 기록을 가리키면, 그것은 정보 사이의 관계를 표현합니다. 반면 테스트 실패 뒤 수정 단계로 돌아가는 연결은 실행 순서를 표현합니다.

문서 연결은 “왜 이렇게 만들었는가, 무엇을 읽어야 하는가”에 답하고, 실행 그래프는 “지금 어느 작업을 실행해도 되는가”에 답합니다. 두 구조는 연결할 수 있지만 파일에 링크가 있다고 실행기가 자동으로 생기지는 않습니다. 링크를 해석하고 상태를 읽어 작업을 결정하는 코드가 별도로 필요합니다.

설계 결정의 배경을 남기는 ADR도 이 맥락에서 유용합니다. ADR는 Architecture Decision Record, 즉 아키텍처 결정 기록입니다. Michael Nygard의 설명처럼 결정의 맥락과 결과를 짧게 남기면, 다음 개발자나 에이전트가 이미 검토한 대안을 처음부터 다시 논의하는 일을 줄이는 데 도움이 됩니다.

작업자가 한 명이고 실행이 짧다면 Markdown이나 작은 구조화 파일로 시작할 수 있습니다. 하지만 여러 실행이 동시에 상태를 고치거나, 중간에 멈춘 일을 정확히 이어야 하거나, 변경 이력을 조회해야 한다면 파일 덮어쓰기만으로는 부족해집니다. 잠금·원자적 갱신·버전 관리가 필요하고, 데이터베이스나 워크플로 런타임을 검토할 이유가 생깁니다. 그래프를 쓴다는 이유만으로 그래프 데이터베이스까지 도입할 필요는 없습니다.

“그래프로 필요한 문서만 찾으면 검색이 무료”라는 설명도 조심해야 합니다. 선택적으로 가져온 정보가 모델 입력을 줄일 수는 있지만, 색인 생성·관계 유지·조회·권한 검사에는 일이 듭니다. 필요한 맥락을 빠뜨리면 모델 호출을 줄이고도 재작업이 늘어날 수 있습니다. 절약 여부는 검색 비용과 최종 작업 성공을 함께 측정해야 합니다.

상태를 저장해도 복구가 끝난 것은 아닙니다

수리공이 잠깐 자리를 비웠다가 돌아왔는데, 이미 고친 바퀴를 또 갈기 시작하면 곤란합니다. 다음 그림에서는 자동차 옆에 남은 진행 기록이 무엇을 바꾸는지 보시면 됩니다.

크게 보기

×확대 이미지 닫기

앞의 두 장면은 작업자가 멈춰도 기록은 남아야 한다는 뜻입니다. 뒤의 두 장면은 기록을 읽어 남은 일만 해야 한다는 뜻입니다. 오류 처리에서는 이 역할을 오류 ID, 코드 버전, 검사 결과, 이미 생성한 티켓 번호 등이 맡습니다. 기록을 남기는 일과 실제 중복을 막는 처리는 함께 설계해야 합니다.

에이전트가 “검증 통과”라고 기억하는 것과, 현재 코드가 검증을 통과한 것은 다릅니다. 검증 뒤 코드가 바뀌었으면 이전 결과는 새 변경을 승인할 근거가 될 수 없습니다. 따라서 상태에는 ‘완료’라는 단어만 아니라 검사 대상 코드 버전, 테스트 결과 참조, 마지막 실패 이유가 연결돼야 합니다.

오류 수정 사례라면 오류 ID, 작업 상태, 기준 코드 버전, 시도 횟수, 검증 결과, 만들어진 티켓·PR 식별자, 사람의 승인 범위를 남길 수 있습니다. 이런 정보는 다음 실행에 모든 대화를 다시 넣는 대신 필요한 사실을 복원하는 데도 쓰입니다. 다만 오래된 요약을 최신 사실처럼 읽지 않도록 갱신 시점과 원본 참조가 필요합니다.

재개 과정의 중복 실행도 별도 문제입니다. LangGraph의 interrupt 문서는 중단한 노드가 재개 시 다시 실행될 수 있으므로 그 앞의 부수 효과를 멱등적으로 설계하라고 설명합니다. 체크포인트가 있다고 티켓 생성이나 메시지 발송이 자동으로 한 번만 일어나는 것은 아닙니다.

하네스와 루프를 완전히 별개로 떼어 놓기도 어렵습니다. 외부 루프가 “이 파일만 수정하라”고 정해도 실행 환경이 그 범위를 통제하지 못하면 규칙은 희망 사항에 머뭅니다. 루프가 작업과 예산을 정하고, 하네스와 도구가 실제 권한·시간 제한·취소를 집행하도록 경계를 맞춰야 합니다.

큰 프로젝트보다 반복 비용이 큰 프로젝트

코드가 크다는 이유만으로 그래프가 필요한 것은 아닙니다. 거대한 저장소에서 오타 한 곳을 고치는 일은 짧게 끝날 수 있고, 작은 서비스의 환불 처리도 승인·재시도·중복 방지 때문에 까다로울 수 있습니다. 프로젝트의 크기보다 반복 빈도, 확인 가능한 결과, 대기와 복구의 필요성을 먼저 보겠습니다.

앞의 Sentry 사례에서 오류가 가끔 들어오고 개발자가 매번 판단해야 한다면, 기존 코딩 도구에 조사 요청을 보내는 것으로 시작할 수 있습니다. 같은 종류의 오류가 계속 들어오고 분류 기준이 안정됐다면 외부 루프의 후보가 됩니다. 먼저 조사 보고서만 만들게 하고, 사람이 고친 분류와 중복·차단 이유를 남겨 실제 부담이 줄어드는지 봅니다. 그다음 검증 가능한 수정안 준비까지 넓힐 수 있습니다.

여러 저장소에 같은 API 변경을 적용하는 작업도 후보입니다. 각 저장소의 빌드와 테스트가 독립적이고 수정 범위가 정해져 있다면, 저장소별 작업을 나누고 결과를 모을 수 있습니다. 반대로 공통 라이브러리 변경이 끝나야 하위 서비스 테스트가 의미를 갖는다면 그 선행 조건을 명시해야 합니다. 무작정 여러 에이전트를 실행하는 것보다 어느 작업을 병렬로 해도 되는지가 먼저입니다.

데이터 처리나 보고서 작성도 마찬가지입니다. 원문 수집, 항목 추출, 형식 검사처럼 순서가 고정된 부분은 일반 코드와 작업 큐로 구성할 수 있습니다. 근거가 부족할 때만 추가 검색을 맡기고, 승인 대기가 생길 때 진행 상태를 저장하는 식으로 AI가 필요한 부분을 좁힐 수 있습니다. 여기서 작업 큐는 처리할 일을 보관하는 장치입니다. 에이전트가 모든 단계를 자율적으로 고를 필요는 없습니다.

이 표의 루프와 그래프는 설계 방식입니다. 직접 만든 작은 실행기, 기존 CI·작업 큐, 상태 머신, LangGraph 같은 런타임으로 구현할 수 있습니다. 이미 안정적으로 운영하는 워크플로가 있다면 거기에 모델 호출을 넣는 편이 더 자연스러울 수도 있습니다. Anthropic의 에이전트 설계 지침도 가장 단순한 해결책부터 시작하고, 측정 가능한 이익이 있을 때 복잡성을 늘리는 접근을 권합니다.

자동화의 성적표에는 사람의 시간도 넣습니다

실행 횟수와 PR 개수는 활동량입니다. 사람이 검토해 받아들인 수정안이 늘었는지, 같은 오류를 중복 처리했는지, 막힌 이유를 설명했는지, 검토 대기열이 길어졌는지도 함께 봐야 합니다. 수정안을 빨리 만들어 놓고 사람이 매번 다시 조사해야 한다면 병목의 위치만 바뀐 셈입니다.

비교할 때는 같은 유형의 작업 묶음을 두고 모델·도구·검증 조건을 기록합니다. 모델 호출과 도구 실행 비용, 처리 시간뿐 아니라 사람이 검토·수정한 시간과 루프 유지보수 시간을 남깁니다. 받아들일 수 있는 결과 한 건에 드는 전체 비용이 줄어야 최적화라고 부를 근거가 생깁니다. 이는 이 글에서 제안하는 평가 기준이며 특정 도입 사례의 측정 결과는 아닙니다.

상태를 잘 남기면 실패한 부분부터 재개해 중복 호출을 줄일 수 있고, 서로 독립적인 작업을 병렬화하면 대기 시간을 줄일 여지도 있습니다. 그러나 매 단계에 계획·실행·리뷰 에이전트를 붙이면 호출과 인수인계가 늘어납니다. Anthropic의 멀티에이전트 연구 시스템 보고에서도 자신들의 환경에서 다중 에이전트가 채팅보다 훨씬 많은 토큰을 사용했고, 작업 가치가 그 비용을 감당해야 한다고 설명합니다. 연구용 구조의 이익을 코딩 작업 전체에 그대로 적용할 수는 없습니다.

그래서 저는 루프와 그래프를 모든 AI 개발의 필수 단계로 두지 않겠습니다. 먼저 기존 도구로 좁은 작업을 해결하고, 반복 인계가 부담이 되면 루프를, 의존성과 대기·복구가 문제가 되면 그래프를 검토하는 편이 낫다고 봅니다. 잘 작동하는 단순한 구조라면 계속 단순하게 둘 이유가 충분합니다.

기존 모범 사례와 무엇이 다른가라는 첫 질문으로 돌아오면, 새 개발 법칙이 생긴 것은 아닙니다. 익숙한 요구사항·테스트·상태·권한 설계를 바탕으로 사람이 매번 주던 다음 지시를 시스템에 맡기는 것입니다. 더 오래 돌아가는 에이전트보다, 사람이 덜 개입해도 검증 가능한 결과를 남기는 구조가 필요한 프로젝트에서 두 관점의 가치가 드러납니다.