그래프 엔지니어링

영상이 그래프의 핵심이라고 부른 기능은, 제 52개 런에서 발동 조건이 한 번 나왔습니다. 14분짜리 개념 강의가 LLM 활용 기법의 계보를 프롬프트 → 컨텍스트 → 루프 → 그래프 네 단계로 세우고 마지막 단계를 설명합니다. 정리는 깔끔한데, 여덟 요소를 제 테스트 케이스 파이프라인에 대고 세어 보니 일곱은 이미 코드로 들어가 있었고, 안 갖고 있던 병렬 실행 하나만이 실측상 진짜 이득이었습니다 — 실제 런 8건의 로그를 다시 분석해 런당 중앙값 9.9분이 나왔습니다.

무엇을 말한 영상인가

순수 개념 강의입니다. 코드 0줄, 실행 데모 0회, 프레임워크 이름 0건. 시장조사 기획이라는 가상 과제 하나를 (a) 단일 에이전트에 통째로 던지는 방식과 (b) 그래프로 쪼개는 방식으로 두 번 풀어 대비시키는 게 구성의 축입니다.

단일 에이전트의 한계를 짚는 대목이 정확합니다. 계획·검색·해석·검증이 한 상자 안에 있으면 결과가 틀렸다는 것만 알 수 있습니다 — 어디서 틀렸는지는 모릅니다. 그래프로 쪼개는 이유가 여기서 나옵니다.

노드마다 수치화된 완료 조건을 붙이라고 합니다. 경쟁사 최소 10개, 시장 규모는 출처 필수, 사용자 의견 최소 20개. 그리고 그 판단을 누가 하는지를 성격으로 가릅니다 — 경쟁사 ≥ 10 은 코드가, “어느 시장이 더 매력적인가” 는 AI나 사람이.

적용 금지 구간을 따로 슬라이드로 뗀 게 드뭅니다. 툴 호출 한두 번이면 끝나는 일에 그래프를 쓰지 말라고 합니다 — 구조 복잡도와 디버깅 지점과 비용이 늘고 “토큰이 그냥 녹는다” 고. 개념 강의가 자기 주제의 안 쓰는 조건을 말하는 경우는 많지 않습니다.

깨본 결과

“새로운 트렌드”가 아닙니다. 노드·엣지·조건부 엣지·상태로 작업 흐름을 짜는 건 워크플로 엔진의 수십 년 된 모델 그대로입니다. 영상 자신도 후반에 “사실 개발자들과 늘 공존해온 패턴” 이라고 인정하는데, 제목과 도입부는 새 유행어로 팝니다.

계보 서사가 앞뒤로 어긋납니다. 도입부 나레이션은 각 단계가 이전 단계의 상위 버전이라고 말하는데, 후반 슬라이드는 정반대로 동심원을 그립니다. 후자가 맞습니다 — 프롬프트가 나쁜 그래프는 여전히 나쁩니다. 앞부분만 보고 “이제 프롬프트는 안 중요하다” 로 읽으면 오독입니다.

루프와 그래프의 구분이 공학적 구분이 아닙니다. 근거로 든 게 이름뿐입니다 — “계속 도는 것” vs “노드와 엣지”. 루프는 역방향 엣지가 하나 있는 그래프라서 이 대비는 성립하지 않습니다. 영상이 실제로 짚으려던 차이는 제어 흐름이 에이전트 머릿속에 암묵적으로 있느냐, 밖에 명시적으로 있느냐인데 그 문장이 끝까지 안 나옵니다.

비용 주장이 자기모순입니다. “AI를 덜 써서 돈을 아낀다” 와 “에이전트가 늘어 토큰이 그냥 녹는다” 가 1분 간격으로 나옵니다. 둘 다 참일 수 있는데 어느 조건에서 어느 쪽인지를 말하지 않아 비용 논의가 방향 없이 남습니다.

그리고 그래프의 실패 모드가 통째로 빠졌습니다. “디버깅 지점이 는다” 한 줄이 전부입니다. 무한 재시도, 상태 비대, 부분 실패와 멱등성, 되돌렸을 때 이미 쓴 비용은 회수가 안 된다는 것 — 실제로 그래프를 운영할 때 사람을 잡는 것들이 하나도 없습니다.

검증 가능한 것이 0건입니다. 출처 0, 코드 0, 실행 0. 수치 주장은 화면의 AI 노드 5개 · 런당 $2.40 딱 하나인데 모델명도 토큰 수도 「1 런」의 정의도 없습니다. 애니메이션 소품에 가까워서 근거로 인용할 수 없습니다.

내 환경에 대봤다

노드 분할·상태 전달·노드별 코드 규칙은 형태만 다르지 같은 자리에 있었습니다. 상태는 단일 객체가 아니라 파일 계약입니다 — 작업 폴더에 json 30종이 누적되고 다음 노드가 그것만 봅니다. 노드별 규칙은 게이트 4종이 한 런에서 여덟 번 호출됩니다. 영상이 “경쟁사 ≥ 10 은 코드로” 라고 말한 바로 그 자리입니다.

생성↔평가는 제 쪽이 제일 활발합니다. 청크 재시도, 열 위반 교정, 게이트 교정 1라운드, 렌즈 산출 검증 재시도 — 52개 런 중 36건이 실제로 발동했습니다.

그런데 영상이 그래프의 핵심이라 부른 것은 안 씁니다. “검증 실패 시 어느 노드로 돌아갈지를 그래프에 미리 적어 둔다” — 제 로그에서 그 조건이 발동한 건 52개 런 중 1번이었습니다. 이유는 명확합니다. 제 파이프라인은 되돌아가는 대신 그 자리에서 교정하기 때문입니다. 되돌리면 앞 노드가 이미 쓴 비용이 통째로 날아갑니다 — 영상이 안 다룬 실패 모드가 바로 그것입니다.

남은 하나가 병렬 실행이었고, 이건 실측했습니다. 적대 리뷰 단계에서 렌즈 셋을 순차로 돌리고 있었는데, 실제 런 8건의 로그를 다시 분석하니 병렬로 바꾸면 런당 중앙값 9.9분이 줄어듭니다. 총 런 시간의 8~9%입니다.

판정

무엇	판정
병렬 실행	채택. 실측 근거가 있는 유일한 순증 — 런당 9.9분
노드 분할 · 상태 전달 · 노드별 코드 규칙	이미 있음. 형태만 다르다
생성 ↔ 평가	이미 있음. 제 쪽이 더 활발하다
사람 승인 게이트	이미 있음
조건부 되돌림 엣지	기각. 52개 런 중 발동 1회. 되돌리면 앞 비용이 날아간다
라우터 · 단일 상태 객체	기각. 파일 계약이 이미 그 자리를 채우고 있다
영상을 근거로 인용	⛔ 금지. 출처 0 · 코드 0 · 실행 0 · 수치 1건(근거 없음)

이 편에서 값을 치른 교훈은 이겁니다 — 개념이 맞다는 것과 내게 이득이라는 것은 다른 문제입니다. 여덟 요소 전부 개념적으로는 옳았습니다. 그런데 일곱은 이미 있었고, 영상이 제일 강조한 하나는 제 로그에서 죽어 있었고, 실제 이득은 영상이 지나가듯 언급한 하나에 있었습니다.

그리고 그 차이는 개념으로는 절대 안 갈립니다. 52개 런의 로그를 다시 읽어야 나옵니다. 남의 정리를 읽고 “우리도 이거 해야겠다” 로 끝냈으면, 저는 발동 1회짜리 기능을 만드느라 시간을 쓰고 9.9분짜리는 놓쳤을 겁니다.