582 ／ 719
AI 워크플로우를 혁신하는 그래프 엔지니어링의 본질
최근 X 등 소셜 미디어에서 그래프 엔지니어링이라는 용어가 자주 등장한다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링에 이어 새로 나온 개념이다. 처음에는 또 다른 유행어일지 모른다는 의구심이 있었으나, 이 개념은 AI를 활용하는 방식의 본질적인 변화를 제시한다.
AI 에이전트를 움직이는 세 계층
그래프 엔지니어링을 제대로 보려면, 그것이 홀로 서 있지 않다는 점부터 짚어야 한다. AI 에이전트를 실제로 움직이는 구조는 세 계층으로 나뉜다. 맨 아래에서 하네스가 환경을 깔고, 그 위에서 루프가 반복하며, 최상위에서 그래프가 여러 루프의 흐름을 지휘한다.
프롬프트 엔지니어링과 컨텍스트 엔지니어링이 ‘AI에게 무엇을 묻고 무엇을 줄지’의 계보라면, 하네스·루프·그래프는 ‘AI가 어디서 일하고, 어떻게 반복하며, 어떤 순서로 움직일지’의 계보다. 두 계보는 경쟁하지 않는다. 같은 작업을 다른 각도에서 본다.
| 계층 | 한 줄 정의 | 역할 |
|---|---|---|
| 하네스(환경) | AI에게 도구·권한·저장 공간처럼 일할 환경을 만들어 준다 | 인프라(기반) |
| 루프(피드백) | 목표를 한 번 설정하면 끝나거나 막힐 때까지 스스로 반복한다 | 피드백 |
| 그래프(흐름) | 여러 루프를 동시에 돌려 하나로 모은다 | 오케스트레이션 |
이 논의가 갑자기 뜨거워진 계기가 있다. Claude Code를 만든 개발자가 “이제 프롬프트 대신 루프를 짠다”고 말한 것이다. 그로부터 두 달도 안 돼 논의는 그래프와 하네스로 넘어갔고, 지금 개발자들 사이에서 가장 빠르게 퍼지는 화두가 됐다.
주의할 점은 세 계층을 혼동하지 않는 것이다. 하네스는 인프라, 루프는 피드백, 그래프는 오케스트레이션이다. 그래프는 루프가 아니고, 루프는 하네스가 아니다. 층을 섞으면 “에이전트를 여러 개 붙였는데 왜 결과가 더 나빠졌는가” 같은 혼란이 생긴다. 각 층이 맡은 일을 구분할 때 비로소 전체가 맞물려 돌아간다.
하네스는 환경을 만든다
하네스는 모델을 둘러싼 시스템이다. LLM 하나만으로는 파일을 읽지도, 명령을 실행하지도, 지난 작업을 기억하지도 못한다. 하네스는 그 모델에 손과 발, 그리고 기억을 붙여 준다. 중심에는 계획·위임·검증을 맡는 오케스트레이터 에이전트가 있고, 그 아래 아홉 가지 구성요소가 자리한다.
| 구성요소 | 하는 일 |
|---|---|
| 계획 | 할 일을 작성한다 |
| 저장소 | 상태를 저장한다 |
| 컨텍스트 | 정보를 압축하고 격리한다 |
| 서브에이전트 | 여러 작업을 병렬로 실행한다 |
| 메모리 | 단기와 장기 기억을 나눠 유지한다 |
| 스킬 | 검증된 워크플로우를 재사용한다 |
| 샌드박스 | 위험한 실행을 격리한다 |
| 승인 | 사람이 개입할 지점을 만든다 |
| 도구 | 함수와 MCP로 외부와 연결한다 |
하네스 안에서 에이전트는 하나의 순환으로 움직인다. 컨텍스트(프롬프트·메모리·스킬·대화)가 모델에 주입되면, 모델이 추론해 결정을 내리고, 도구와 MCP로 실제 행동을 한다. 그 결과는 스크린샷·테스트 결과·로그로 관찰·검증된 뒤 파일시스템과 git에 저장된다. 별도의 제어 장치가 이 흐름을 압축하고 조율한다. 핵심은 ‘검증’과 ‘저장’이 흐름 안에 내장돼 있다는 점이다. AI가 스스로 답을 내고 그 답이 맞는지까지 스스로 우기는 구조를 끊는 것이 하네스 설계의 출발점이다.
루프는 증거가 나올 때까지 반복한다
루프는 선이다. 모든 행동이 순서대로 한 걸음씩 일어난다. 1단계가 끝나야 2단계가 시작되고, 그렇게 완료까지 이어진다. 채팅창에 질문을 던지고 답을 받는 방식과 가장 다른 점은, 루프에는 멈추지 않고 스스로 나아가는 힘이 있다는 것이다.
작동 원리는 단순하다. 목표를 한 번 설정하면, AI가 작업을 수행하고, 결과가 충분한지 스스로 점검한다. 충분하지 않으면 다시 시도하고, 충분하면 결과를 보고하고 멈춘다. 큰 목표를 던져 두면 AI가 스스로 계획을 세우고 반복해 결과를 다듬는다. 사람이 매 단계를 지시할 필요가 없다.
실제 사용은 더 간단하다. Claude Code나 데스크톱 앱에서 /loop를 입력하고 원하는 작업을 설명하면 된다. 이때 멈추는 규칙을 함께 정해 두는 편이 좋다. “5번 실패하면 멈추고 알려줘”처럼 종료 조건을 주면, 루프가 헛돌거나 비용을 무한정 쓰는 상황을 막는다.
그래프는 여러 루프를 하나로 묶는다
그래프는 네트워크다. 루프가 한 줄이라면, 그래프는 그 줄 여러 개를 병렬로 묶은 것이다. 기획자가 방향을 정하면 여러 작업자가 동시에 일하고, 통합자가 결과를 하나로 모아 최종 결과물을 낸다. 서로 의존하지 않는 일을 동시에 굴리고 마지막에 합치는 이 구조가 그래프 엔지니어링의 뼈대다.
이제 이 최상위 층, 그래프를 자세히 들여다본다.
AI 워크플로우를 설계하는 새로운 관점
그래프 엔지니어링은 AI와 상호작용하는 방식을 근본적으로 재설계하는 개념이다. 기존의 프롬프트 엔지니어링과 컨텍스트 엔지니어링이 AI에게 ‘무엇을 물을지’ 또는 ‘어떤 정보를 줄지’에 집중한다면, 그래프 엔지니어링은 AI가 작업을 수행하는 ‘주변의 일’을 어떻게 설계할지에 초점을 맞춘다. 이는 모든 작업이 거대한 채팅창 하나에 몰리지 않도록 체계적인 워크플로우를 구축하는 방식이다.
다음은 세 가지 엔지니어링 개념의 핵심을 비교한 내용이다.
| 엔지니어링 유형 | 핵심 역할 | 적용 영역 |
|---|---|---|
| 프롬프트 엔지니어링 | AI에게 더 나은 질문을 던지는 방법 | AI 모델과의 직접적인 대화, 질의 |
| 컨텍스트 엔지니어링 | AI에게 더 나은 정보를 제공하는 방법 | AI 모델에 제공하는 배경 지식, 데이터 |
| 그래프 엔지니어링 | AI 주변의 워크플로우를 설계하는 방법 | AI가 개입하는 작업의 단계, 순서, 협업 |
일반적으로 사람들은 새로운 아이디어를 조사할 때 AI 채팅창을 열고 “이 아이디어를 추진해야 할까?”라고 묻는다. AI는 시장 규모, 경쟁사, 시장 진입 계획 등 자신감 있는 답변을 제공한다. 하지만 이 방식은 하나의 AI 모델이 중요성을 판단하고, 시장을 조사하며, 근거를 해석하고, 추천안을 작성하고, 심지어 답변의 확신도까지 스스로 평가하는 문제를 낳는다. 이는 하나의 AI 모델에 과도한 신뢰를 부여하는 행동이며, 자칫 잘못된 판단으로 이어질 수 있다.
그래프 엔지니어링은 이 문제를 다르게 접근한다. 하나의 질문을 받으면 플래너가 질문을 여러 각도로 나눈다. 리서처들이 고객, 경쟁사, 유통, 가격, 리스크 등을 각각 조사한다. 그 후 회의론자가 나와 약한 근거들을 걸러낸다. 살아남은 근거들을 병합 담당이 하나의 추천안으로 만들고, 마지막으로 사람이 그 결정을 승인한다. 최종 결과물은 여전히 보고서 형태일 수 있으나, 그 뒤에 있는 일의 설계는 훨씬 정교하고 신뢰할 만하다.
일, 흐름, 그리고 기억: 그래프의 세 요소
그래프 엔지니어링에서 말하는 그래프는 기본적으로 화살표로 연결된 잡(job)들이다. 잡은 워크플로우의 한 단계이며, 화살표는 다음 단계를 나타낸다. 워크플로우를 따라 흐르는 공유 메모는 상태(state)라고 부르는데, 이는 시스템이 지금까지 무엇을 알고 있는지를 의미한다.
- 잡: 무엇을 하는가 (예: 고객 리서치, 경쟁사 분석)
- 화살표: 그다음 어디로 가는가 (예: 리서치 결과가 회의론자로 전달)
- 상태: 지금까지 무엇이 쌓였는가 (예: 고객 리서치 데이터)
이 세 가지 요소는 처음에는 기술적으로 들리지만, 현실에서 일이 진행되는 방식과 동일하다. 예를 들어 유튜브 에피소드 제작을 생각하면, 단순히 ‘대본 쓰기’ 하나의 잡이 아니다. 리서치, 논지 수립, 사례 탐색, 후킹 문구 작성, 대본 집필, 제목 아이디어 도출, 썸네일 구상, 도식화 등 여러 잡이 존재한다.
이 잡 중 일부는 순서대로 진행해야 한다 (예: 논지가 대본보다 먼저). 그러나 다른 잡은 동시에 진행할 수 있다 (예: 한 리서처가 사례를 찾는 동안 다른 리서처는 반론을 찾는다). 이처럼 병렬 작업이 가능한 지점에서 그래프의 가치가 발휘된다. 채팅 형식은 모든 것을 순차적으로 느끼게 만들어, 여러 조각의 작업이 있을 때 느리고 비효율적이며 결과의 신뢰도를 떨어뜨린다.
그래프는 일을 작은 팀처럼 설계한다. 한 부분이 계획을 세우고, 여러 부분이 동시에 작업하며, 다른 부분이 결과를 검사하고, 또 다른 부분이 병합하고, 마지막에 사람이 승인한다. 이는 AI를 다루는 문제를 넘어, 특정 일을 어떤 팀 구조로 굴릴지에 대한 관점으로 전환된다.
두 가지 ‘그래프’의 역할
AI 분야에서 그래프라는 용어를 사용하면 두 가지 다른 의미로 혼동이 생긴다. 다음 표는 이 두 가지 유형을 명확히 구분한다.
| 그래프 유형 | 목적 | 예시 | 주요 역할 |
|---|---|---|---|
| 지식 그래프 | AI가 사물 간의 관계를 추론하도록 돕는다. | 고객-회사-제품-도구-문의-기능-팀 연결 | AI가 복잡한 데이터 속에서 관계를 파악하고 추론하게 한다. |
| 에이전트 그래프 | 일이 어떤 순서로 움직이는지 설계한다. | 아이디어 검증 워크플로우 (플래너 → 리서처 → 회의론자 → 병합) | AI가 올바른 단계들을 밟아 작업을 수행하게 한다. |
이 글의 논의는 주로 에이전트 그래프에 집중한다. 이는 창업가, 크리에이터, 운영자 등 작은 팀 단위에서 즉시 활용할 수 있는 실용적인 개념이기 때문이다.
결국 가장 효과적인 시스템은 두 가지 그래프를 모두 활용한다. AI가 비즈니스 내의 관계를 이해함과 동시에, 올바른 작업 단계를 수행하는 능력을 갖추는 것이 목표이다.
그래프를 활용할 때
그래프 엔지니어링은 모든 작업에 필요한 것은 아니다. 간단한 이메일 요약이나 프로젝트 이름 브레인스토밍에는 필요하지 않다. 그러나 AI로 심층 리서치, 시장 진입 계획 수립, 고객 문의 분류, 코드 리뷰, 영업 미팅 준비, 고객 피드백 종합, 반복되는 콘텐츠 워크플로우 등 여러 단계와 복잡성이 있는 작업을 수행할 때 그래프식 사고가 중요해진다.
그래프를 사용하는 세 가지 핵심 규칙은 다음과 같다.
- 다단계 작업: 일에 여러 단계가 존재한다.
- 병렬 진행: 그중 일부는 동시에 진행할 수 있다.
- 검증 필요: 최종 결과물이 사용되기 전에 검사가 필요하다.
이러한 조건이 충족될 때, 그래프는 다이아몬드 모양을 형성한다. 하나의 질문에서 시작하여 여러 갈래로 퍼져 동시 진행되고, 결과가 검증된 후 하나의 답으로 합쳐지는 구조이다. 시작점과 끝점은 하나이지만, 중간 단계가 확장되는 형태이다.
실제 사례: 쇼피파이 장부 정리 제품 아이디어
“쇼피파이 판매자를 위한 AI 장부 정리 제품을 출시해야 할까?”라는 질문을 그래프로 풀면 다음과 같다.
- 플래너: 질문을 받아 고객의 고통, 경쟁 구도, 시장 진입 쐐기, 가격 압박, 리스크를 이해해야 한다고 정의한다.
- 리서처 (병렬 진행):
- 고객 리서처: 쇼피파이 판매자의 장부 정리 고통(퀵북스 사용 여부, 자동화 니즈 등)을 파악한다.
- 경쟁사 리서처: 기존 쇼피파이용 장부 정리 도구, 회계 법인의 수작업, 앱스토어 제품, 프리랜서 시장의 대체 가능성 등을 조사한다.
- 유통 리서처: 쇼피파이 판매자들이 모이는 채널, 읽는 뉴스레터, 신뢰하는 에이전시, 검색어 등을 분석한다. 이 세 리서치는 서로 의존하지 않으므로 동시에 진행한다.
- 회의론자: 리서치 결과를 검토하여 근거가 약한 주장, 오래된 정보, 빠진 경쟁사, ‘고통’과 ‘돈 낼 의사’를 혼동하는 지점, AI가 자신감만으로 말한 부분을 가려낸다. AI 리서치가 실패하는 주요 원인 중 하나가 AI 스스로 답을 쓰고 스스로 채점하기 때문인데, 회의론자는 이 문제를 해결한다.
- 병합: 살아남은 근거를 바탕으로 추천안을 만든다. 추진 여부, 시장 진입 쐐기, 첫 고객, 테스트할 사항, 그리고 어떤 근거가 나오면 생각이 바뀔지 등을 포함한다.
- 사람 승인: 이 단계에서 사람이 최종 결정을 내린다. 쇼피파이 랜딩페이지 분석, 에이전시 대표 인터뷰, 장부 정리 비용 계산기 개발, 혹은 시장 진입 포기 등이다.
그래프 엔지니어링은 사람 대신 결정을 내려주지 않는다. 결정을 내릴 때 필요한 근거를 더 효과적으로 만들어내는 방법을 제공한다.
시작은 단순하게: 자동화보다 구조가 먼저
그래프 엔지니어링을 시작할 때, 많은 사람이 랭그래프(LangGraph)나 오토젠(AutoGen) 같은 복잡한 프레임워크부터 사용하려는 경향이 있다. 그러나 첫 그래프는 수동으로 운영해도 무방하다. 핵심은 구조이다. 각 잡에 고객 리서치, 경쟁사 리서치, 유통 리서치, 검사, 병합 등의 역할을 부여하는 것이 중요하다.
다음 표는 그래프 구현의 세 가지 레벨을 보여준다.
| 레벨 | 특징 및 구현 방식 | 장점 및 유의사항 |
|---|---|---|
| 초급 | 레인을 나누어 수동으로 진행한다. 도구 없이 구조만 사용한다. | 이해하기 가장 쉽다. 수동 버전이 눈에 띄게 나은 결과물을 만들지 못하면, 자동화해도 평범한 결과물만 빠르게 나온다. |
| 중급 | 클로드 코드나 코덱스를 사용하거나, 저장소를 두어 각 단계가 파일을 생성한다 (예: plan.md, customer.md). |
종이 흔적이 남아 워크플로우를 추적하고 버전을 비교하며 재사용할 수 있다. |
| 고급 | 랭그래프, 오토젠 그래프플로우, n8n, make.com 또는 자체 스크립트로 그래프를 자동화한다. | 상태 저장, 사람 개입 승인, 순차/병렬/조건 분기, 루프, 외부 시스템(슬랙, 이메일 등) 연동 등 복잡한 워크플로우를 지휘한다. |
중요한 점은 도구가 핵심이 아니라는 것이다. 도구는 워크플로우를 충분히 이해한 다음에 적용해야 한다. 이해하지 못한 워크플로우를 자동화하면 혼란만 가중된다. 워크플로우를 먼저 이해하면 자동화는 자연스러운 다음 단계가 된다. 첫 연습은 자동화에 앞서 화이트보드 도구에 그래프를 그려보는 것이다.
다양한 업무에 그래프 적용
그래프 엔지니어링은 다양한 비즈니스 영역에 적용될 수 있다.
- 고객 지원: 문의 분류 (결제, 제품, 버그), 계정 맥락 확인 (신규, 고액, 이탈 위험), 문서 검색, 답변 초안 작성, 검사 (정확성, 톤, 리스크), 사람 승인 (환불, 법적 리스크 등). “AI야, 티켓에 답해줘”보다 훨씬 체계적이다.
- 콘텐츠 제작: 리서치, 논지 수립, 사례 탐색, 후킹 문구 작성, 대본 집필, 검사 (구체성, 호흡, 후킹 효과), 제목 아이디어, 썸네일 콘셉트, 자막, B롤 제작. 콘텐츠 리드가 실제로 일하는 방식과 유사하다.
- 코딩: 계획 수립, 코드 수정, 변경분 리뷰, 테스트 실행, UI 확인, 예외 상황 탐색, 사람 승인 (최종 풀 리퀘스트). AI 코딩 도구의 미래 방향은 코드를 쓰는 모델이 아닌, 계획-테스트-리뷰-점검의 전체 워크플로우에 있다.
그래프 엔지니어링이 중요한 이유
그래프 엔지니어링이 의미 있는 가장 큰 이유는 결과물의 품질이 ‘누군가 완벽한 프롬프트를 기억해내는 능력’에 덜 의존하게 만들기 때문이다.
- 일관된 검토: 검사가 워크플로우의 한 단계로 내재화되어 사람의 기분이나 여유에 좌우되지 않는다.
- 깔끔한 위임: 넘겨야 할 일이 잡 단위로 잘려 있어 명확하다.
- 명확한 승인 지점: 사람이 개입해야 할 지점이 명확하게 설계도에 나타난다.
시간이 지남에 따라 그래프의 각 노드에 도구, 메모리, 검사, 권한을 붙일 자리가 생긴다. 이는 AI 작업이 단순한 채팅을 넘어 하나의 운영체제로 진화하는 것을 의미한다.
한 가지 경고: 에이전트가 많다고 반드시 결과물이 좋아지는 것은 아니다. 오히려 소음만 늘어나거나, 여러 AI 작업자가 똑같이 틀린 생각을 자신 있게 반복하거나, 시스템이 서로 조율하는 데 더 많은 시간을 소비할 수 있다. 목표는 가능한 한 큰 그래프를 만드는 것이 아니라, 일의 품질을 높이는 가장 작은 그래프를 만드는 것이다.
좋은 그래프는 다음 원칙을 따른다.
- 가짜 대기 제거: 서로 의존하지 않는 단계를 병렬로 배치하여 불필요한 대기 시간을 없앤다.
- 작업과 검사 분리: AI 스스로 답을 내고 스스로 채점하는 문제를 피한다.
- 전략적 사람 승인: 실수의 대가가 큰 지점에만 사람 승인을 둔다.
- 적절한 종료: 답이 충분히 좋아졌으면 더 이상 작업을 진행하지 않는다.
- 유용한 상태 유지: 회의 메모, 근거, 초안, 출처, 결정 등 유용한 상태를 기록으로 남긴다.
특히 마지막 항목은 과소평가된다. 그래프 엔지니어링의 진정한 복리 효과는 개별 작업의 개선을 넘어, 당신의 일이 기억을 만들어내기 시작한다는 데 있다. 고객 리서치 그래프를 돌릴 때마다 더 나은 고객 메모가 쌓이고, 콘텐츠 그래프를 돌릴 때마다 더 나은 사례와 독자 인사이트가 쌓인다. 지원 그래프를 돌릴 때마다 더 나은 제품 피드백이 쌓이는 식이다.
이러한 ‘기억’은 컨텍스트가 비즈니스의 해자(垓子)가 되는 지점이다. 그래프가 결과물을 만드는 동시에, 다음 그래프를 더 똑똑하게 만들 기억까지 축적한다. 이것이 비즈니스의 자산이 된다.
첫 그래프 만들기
다음 단계로 첫 그래프를 만들 수 있다.
- 기존 AI 워크플로우 선택: 현재 AI로 매주 반복하는 워크플로우를 하나 고른다 (예: 아이디어 조사, 팟캐스트 준비, 고객 피드백 분석).
- 최종 결과물 정의: 최종 결과물을 한 문장으로 명확히 쓴다 (예: “이 스타트업 아이디어를 테스트할 가치가 있는지에 대한 한 장짜리 추천안이 필요하다”).
- 잡 나열: 훌륭한 사람이라면 해당 작업을 위해 할 일들을 나열한다 (예: 질문 명확화, 고객 조사, 경쟁사 조사, 유통 분석, 리스크 분석, 근거 검사, 추천안 작성).
- 화살표 그리기: 앞 단계가 없으면 정말로 할 수 없는 일에만 화살표를 긋는다 (예: 고객 리서치와 경쟁사 리서치 사이에는 화살표가 필요 없지만, 회의론자 앞에는 반드시 필요하다).
- 사람 승인 지점 추가: 비용이 큰 결정 앞에 사람 승인을 둔다.
- 수동으로 실행: 거창한 자동화 프로젝트 없이, 잡과 화살표만으로 수동으로 한 번 워크플로우를 돌려본다.
이 과정을 한 번 거치고 나면 AI로 하는 일이 다르게 보이기 시작한다. “이 작업에 완벽한 프롬프트가 뭘까”를 고민하는 대신, “이 일에 가장 적합한 워크플로우가 무엇일까”를 고민하게 된다. 그리고 그 답을 만들어낼 경로를 설계한다.
이러한 이유로 그래프 엔지니어링은 주목할 만한 개념이다. 이는 프롬프팅 이후에 오는 논리적인 다음 단계이다. AI에서 가장 많은 것을 얻어내는 사람은 일을 알맞은 조각으로 나누고, 각 조각에 적절한 맥락을 주며, 결과물을 검사하고, 사람이 있어야 할 자리에 두는 법을 아는 사람이다. 제대로 작동하는 그래프가 하나 생기면, 당신은 더 이상 AI에게 프롬프트를 던지는 사람이 아니라 AI의 일을 관리하는 사람이 된다.