루프 엔지니어링(Loop Engineering)이라는 말이 채 자리 잡기도 전에, 이번엔 그래프 엔지니어링(Graph Engineering)이라는 용어가 등장했습니다. GeekNews에 소개된 논의에 따르면 그래프 엔지니어링은 완전히 새로운 개념이라기보다, 여러 에이전트 루프를 하나의 작업 흐름으로 엮는 오케스트레이션에 가깝습니다.
후배님, 용어 하나 늘었다고 넘기기엔 이 변화가 벌써 실무와 채용 공고에 흔적을 남기고 있어요. 이 글에서는 프롬프트·루프·그래프 3단 구조가 실제로 무엇을 가리키는지 정리하고, 이 흐름이 시니어 개발자의 역량 정의와 채용시장에 주는 신호를 살펴봅니다.
프롬프트 → 루프 → 그래프, 새로 정리된 3단 구조
MarkTechPost가 2026년 7월 29일 게재한 분석 기사에 따르면, 이 세 용어는 서로 경쟁하는 기법이 아니라 층층이 쌓인 서로 다른 ‘제어 단위(unit of control)’입니다. 프롬프트는 모델의 응답 한 번을 제어하고, 루프는 에이전트 하나의 행동 주기를 제어하며, 그래프는 여러 에이전트로 이뤄진 조직 전체를 제어합니다.
중요한 건 상위 레이어가 생겨도 하위 레이어가 사라지지 않는다는 점입니다. Anthropic의 컨텍스트 엔지니어링 가이드는 시스템 프롬프트를 배경 정보·지시사항·툴 안내·출력 형식으로 구획화하고, 창(window)에 어떤 토큰을 채울지 결정하는 것 자체가 별도의 엔지니어링 문제라고 설명합니다. 프롬프트를 잘 쓰는 능력은 루프·그래프 단계에서도 그대로 필요합니다.
루프에서 그래프로 갈아타는 게 아니라, 루프를 여러 개 쌓아야 비로소 그래프가 됩니다.
루프 엔지니어링과 그래프 엔지니어링, 무엇이 실제로 다른가
루프의 핵심은 ‘정지 조건’
루프 엔지니어링은 2026년 6월 개발자 커뮤니티에서 화제가 된 개념으로, addyosmani.com의 정리에 따르면 자동화·워크트리 격리·SKILL.md·플러그인 연결·서브에이전트 검증·외부 상태 저장이라는 6가지 요소로 구성됩니다. 이 중 가장 까다로운 지점은 ‘완료’와 ‘멈춰버림’을 기계적으로 구분하는 정지 조건 설계입니다. 정지 조건이 불명확한 루프는 요란하게 실패하는 대신, 조용히 토큰만 계속 소비합니다.
그래프는 조직도와 작업도, 두 그래프를 동시에 돌린다
그래프 엔지니어링은 2026년 7월부터 논의가 빠르게 확산됐습니다. 프로덕션 멀티에이전트 시스템은 실제로 그래프 두 개를 동시에 운용하는데, 하나는 역할이 고정된 장기 에이전트로 구성된 ‘조직 그래프’이고, 다른 하나는 작업 단위로 생겼다 사라지는 ‘작업 그래프’입니다. 조직 그래프가 ‘누가’를 정한다면, 작업 그래프는 ‘지금 무엇을’을 정하는 셈입니다.
왜 멀티에이전트가 비싼가 — 성능은 90.2%, 토큰은 15배
Anthropic 공식 엔지니어링 블로그(How we built our multi-agent research system)에 따르면, 리드 에이전트가 서브에이전트 여러 개를 병렬로 운용하는 멀티에이전트 구성은 발표 기준 단일 에이전트 대비 90.2% 높은 성능을 기록했습니다. 토큰 사용량은 일반 대화 대비 약 15배 많았는데, 같은 발표에 따르면 성능 편차의 80%는 토큰 사용량만으로 설명됐습니다.
숫자만 보면 그래프 구조가 항상 이득처럼 보이지만, 실제로는 ‘작업의 가치가 토큰 비용을 넘어서는가’가 먼저입니다. 사람이 결과를 매번 확인할 수 있고 작업이 한 도메인 안에서 끝난다면, 굳이 그래프로 확장할 이유가 없습니다.
채용 공고와 직무 정의가 흔들리는 지점
MarkTechPost는 프롬프트·루프·그래프 엔지니어링이라는 세 용어가 AI 엔지니어링 채용 공고의 같은 한 줄을 두고 경쟁한다고 짚었습니다. 어떤 회사는 프롬프트 엔지니어를 찾는다고 공고를 내고, 어떤 회사는 에이전트 루프·그래프를 설계할 수 있는 사람을 찾는다고 쓰는데, 실제로 원하는 역량은 크게 다르지 않은 경우가 많습니다.
여러분, 이 지점이 커리어 신호입니다. 용어가 빠르게 바뀌는 시장에서는 특정 프레임워크 이름보다 정지 조건을 설계할 수 있는지, 서브에이전트 실패를 복구할 수 있는지 같은 구조적 이해가 더 오래가는 역량이 되거든요.
후배님이 지금 포트폴리오·이력서에 넣어야 할 것
모델·프레임워크 이름을 외우는 대신, 아래 세 가지 경험을 먼저 만들어보세요.
- 정지 조건 설계 경험: 반복 작업에 ‘완료’를 기계적으로 판정하는 조건(테스트 통과, 스키마 검증, 별도 모델 채점 등)을 붙여본 적이 있는지.
- 서브에이전트 실패 복구 경험: 병렬로 돌린 작업 중 하나가 실패했을 때 재시도·롤백·상태 저장을 설계해본 적이 있는지.
- 비용 대비 가치 계산 경험: 그래프로 확장했을 때 토큰 비용 증가분이 결과물 가치를 넘어서는지 따져본 적이 있는지.
저희 팀도 최근 리서치 자동화에 서브에이전트 3개를 붙였다가, 정지 조건 없이 계속 재시도만 반복해 하루 만에 예상 토큰 예산을 다 써버린 적이 있어요. 결국 서브에이전트마다 ‘몇 번 시도 후 사람에게 넘긴다’는 조건을 명시하고 나서야 안정됐습니다. 이런 실패 경험 자체가 지금은 이력서에 쓸 수 있는 자산이 됩니다.
지금 이 흐름에 어떻게 대응할지 판단 체크리스트
- 지금 맡은 작업은 사람이 매번 결과를 확인하는 구조인가, 아니면 무인으로 돌아가야 하는가?
- 완료 여부를 테스트·스키마·별도 모델 채점 등으로 기계적으로 판정할 수 있는가?
- 작업이 여러 도메인에 걸쳐 있어 병렬 처리가 꼭 필요한가, 아니면 루프 하나로 충분한가?
- 그래프로 확장했을 때 늘어나는 토큰 비용을 팀이 감당할 수 있는가?
관련 글
비슷한 흐름을 다룬 이전 글들도 함께 보시면 도움이 됩니다.
- AI 에이전트가 작성한 코드를 어떻게 검증할지 궁금하다면 — AI 코드 리뷰 방식이 바뀐다, Zed Delta가 던지는 질문
- LLM 평가지표(Evals)가 왜 뜨는지, 커리어에 어떤 신호인지 살펴보고 싶다면 — LLM Evals가 뜨는 이유, 개발자 커리어에 던지는 신호
- AI 코딩 에이전트에 어떤 언어가 유리한지 실측 데이터가 궁금하다면 — AI 코딩 에이전트 언어 선택, ‘동적 언어가 유리하다’는 통념이 깨졌습니다
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요