그래프 엔지니어링, 트윗 하나가 쏘아올린 논쟁 — 루프는 끝났나

이번 주 유튜브에 같은 논쟁을 다루는 영상이 몰렸습니다. Sean's AI Stories는 "루프냐 그래프냐"를 21분짜리 실습으로 풀었고, Greg Isenberg는 "그래프 엔지니어링이 왜 당신의 Claude/Codex를 10배로 만드는가"를 올렸고, Dr. Maryam Miradi는 보험 청구 에이전트 예제로 같은 주제를 다뤘습니다. Microsoft Research의 Alex Lavaee까지 나와서 "제로 슬랍(zero slop)"을 이야기했고요. 발단은 7월 18일 Peter Steinberger의 트윗 한 줄이었습니다 — "아직도 루프 얘기 하고 있어, 아니면 이제 그래프로 넘어갔어?" 몇 시간 만에 57만 뷰가 찍혔습니다.

🪜 엔지니어링 사다리

이 바닥 용어는 계층적으로 쌓입니다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링 → 루프 엔지니어링 → 그래프 엔지니어링 순으로, 뒤에 나온 개념이 앞의 것을 대체하는 게 아니라 그 위에 한 켜를 더 얹는 구조입니다.

🔁 루프 엔지니어링: 목표만 주고 나머지는 맡긴다

루프는 간단합니다. 사람이 정하는 건 목표와 통과 기준뿐이고, 거기 도달하는 구체적인 단계는 에이전트가 스스로 판단합니다. 산출물을 만들고, 평가하고, 문제를 찾고, 고치고, 다시 평가하는 사이클을 품질 기준을 만족할 때까지 반복하는 방식이죠. /loop로 반복시키고 /goal로 종료 조건을 거는 식의 구현이 대표적입니다.

문제는 이 루프가 동시성을 잘 못 다룬다는 점입니다. 에이전트 하나가 순차적으로 "생각 → 도구 호출 → 결과 확인"을 반복하는 구조라서, 서로 다른 작업을 병렬로 굴리려면 결국 사람이 옆에서 여러 개의 루프를 따로 띄워야 합니다.

🕸️ 그래프 엔지니어링: 경로까지 미리 그려둔다

그래프는 여기서 한 발 더 나갑니다. 목표와 기준 외에 작업이 진행될 전체 경로까지 사람이 미리 설계합니다. 노드(에이전트나 작업 단위)와 엣지(다음에 뭘 할지)를 명시적으로 그려두고, 필요하면 병렬 브랜치를 갈랐다가 다시 합류시키고, 검증기(verifier)와 정지 조건을 배치합니다. LangGraph 기준으로는 StateGraph를 선언하고 add_node로 노드를 등록한 뒤 add_edge로 연결해 컴파일하는 흐름입니다.

여기서 재미있는 정의 하나: 루프는 그래프의 특수한 경우입니다. 자기 자신을 가리키는 엣지 하나짜리 노드일 뿐이라는 거죠. 그래서 "그래프로 넘어간다"는 게 루프를 버린다는 뜻이 아니라, 그래프의 각 노드 안에 루프가 그대로 들어간다는 뜻에 가깝습니다.

선택 기준을 정리하면 이렇습니다.

• 사람이 결과를 매번 읽고 판단한다 → 프롬프트로 충분
• 자동 검증 가능하고 에이전트 하나로 끝난다 → 루프
• 병렬 처리·여러 에이전트 조율이 필요하다 → 그래프

🤨 근데 이거 2023년 DAG 아니야?

가장 날카로운 반박은 이겁니다. "상태 머신, DAG, 워크플로우 엔진은 수십 년째 있었다. Airflow도 10년 전부터 태스크 그래프였다." 한 회의론자는 "그래프 엔지니어링에 헛소리 인증한다. 루프 엔지니어링도 이미 충분히 헷갈렸는데"라고 직격하기도 했습니다. 더 근본적인 지적은 이겁니다 — 에이전트에게 목표를 주고, 왜 중요한지 설명하고, 성공을 어떻게 측정할지 정의하는 게 핵심인데, 그걸 루프로 그리든 그래프로 그리든 본질은 안 바뀐다는 겁니다. 화려한 토폴로지를 그려봤자 "완료되고 정확하다"의 기준을 못 정하면 의미가 없다는 거죠.

재미있는 건 "그래프 = DAG"라는 비판 자체도 정확하진 않다는 점입니다. 프로덕션 에이전트는 실패한 툴 호출 재시도, 부족한 정보 재요청, 검증 후 답변 수정처럼 사이클이 필수인데, DAG는 정의상 사이클을 가질 수 없습니다(Directed Acyclic Graph). 그러니 지금 쓰이는 "에이전트 그래프"는 엄밀히는 DAG가 아니라 사이클을 허용하는 일반 그래프에 더 가깝습니다.

종합하면: 기술적 진화 자체는 실재합니다. 초기 에이전트는 다음에 뭘 할지, 어떤 도구를 쓸지, 결과를 어떻게 해석할지, 계획을 언제 수정할지, 언제 멈출지까지 전부 모델 혼자 판단해야 했습니다. 지금은 모델이 "신뢰할 수 있는 실행 시스템 안의 한 부품"으로 역할이 좁아지고, 병렬 처리·도구 다양성·사람 승인 같은 실제 프로덕션 문제를 그래프 구조로 풀고 있다는 것 — 이건 진짜입니다. 다만 "정확도 18% 향상", "비용 85% 절감" 같은 수치는 특정 사례(산업용 다이어그램 처리 등)에서만 나온 걸 일반화한 경우가 많아서, 기술 진화는 진짜지만 바이럴 마케팅식 용어 포장은 걸러 들을 필요가 있다는 게 대체적인 결론입니다.

📚 정리

• 발단은 Peter Steinberger의 트윗 한 줄 (2026.7.18) — "루프 얘기 하고 있어, 그래프로 넘어갔어?"가 몇 시간 만에 57만 뷰
• 엔지니어링 용어는 계층적 — 프롬프트 → 컨텍스트 → 하네스 → 루프 → 그래프, 대체가 아니라 누적
• 루프: 목표+통과기준만 사람이 정하고 나머지는 에이전트에게. 단, 동시성 처리가 약함
• 그래프: 경로(노드·엣지·분기·합류)까지 사람이 설계. 루프는 그래프의 특수 케이스(자기참조 엣지 1개짜리 노드)
• 회의론도 만만치 않음 — "그냥 수십 년 된 DAG/상태 머신 아니냐"는 비판. 다만 실제 에이전트 그래프는 사이클을 허용해 엄밀한 DAG는 아님
• 결론은 "진화는 진짜, 마케팅은 걸러 듣기" — 모델의 역할이 "모든 걸 판단"에서 "신뢰할 수 있는 부품"으로 좁아진 건 실질적 변화, 과장된 수치는 특정 사례 일반화인 경우가 많음

참고: MarkTechPost 「Prompt Engineering vs Loop Engineering vs Graph Engineering」, Gao Dalie 「Forget Loop Engineering. Graph Engineering is about THIS」, Turing Post 「Is Graph Engineering Real? Why Everyone Is Talking About It」, LangChain 「3 Years of Graph Engineering with LangGraph」