에이전트 개발 현장처럼 유행이 빨리 바뀌는 곳도 없을 것입니다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 루프 엔지니어링에 이어 이제는 그래프 엔지니어링이 주목받고 있습니다.
이렇게 흐름이 바뀌는 배경에는 에이전트를 실제 업무에 적용하면서 드러난 기존 접근 방식의 문제들이 자리하고 있습니다. 이번 포스팅에서는 그래프 엔지니어링이 주목받는 이유와 루프 엔지니어링과의 차이를 살펴보겠습니다. 더불어 구글의 Agent Development Kit(ADK) 2.0으로 그래프 기반 워크플로를 구성하는 방법과 함수·에이전트의 역할을 나누는 기준도 알아보겠습니다.
요즘 그래프 엔지니어링을 이야기하는 이유
새로운 엔지니어링 방법론이 계속 등장하는 이유는 실제 기업의 업무가 복잡하기 때문입니다. 한 번의 요청에 한 번 답하는 작업은 모델의 추론에 맡겨도 되지만 실제 업무는 그렇게 단순하지 않습니다. 자료를 모아 여러 기준으로 검토해 결과를 합치고, 문제가 있으면 이전 단계로 돌아가야 합니다. 어떤 작업은 동시에 처리해야 하고 어떤 결정은 사람이 승인해야 합니다.
이렇게 복잡한 업무를 하나의 에이전트에 모두 넣으면 처음에는 빠르게 만들 수 있지만 작업 흐름을 이해하기 어려워집니다. 왜 특정 도구를 불렀는지, 어느 단계에서 오류가 났는지, 어떤 조건으로 재시도했는지 추적하기 힘들어집니다.
그래프 엔지니어링은 이 문제를 풀기 위한 설계 방식입니다. 해야 할 일을 노드로 나누고 노드 사이의 이동 조건을 연결선으로 표현합니다. 노드에는 에이전트가 들어갈 수도 있고, 정해진 코드를 실행하는 함수나 사람의 승인 단계가 들어갈 수도 있습니다. 즉 그래프 엔지니어링은 모든 일을 AI에게 맡기는 방법이 아니라 AI가 판단할 곳과 코드가 확실하게 처리할 곳을 구분하는 접근이라고 이해하면 됩니다.
그렇다면 루프 엔지니어링과 무엇이 다를까요?
루프 엔지니어링과 그래프 엔지니어링의 차이
루프 엔지니어링은 에이전트가 계획하고, 행동하고, 결과를 확인하고, 다시 계획하는 순환을 설계합니다. 요약, 간단한 조사, 한 가지 도구를 반복해서 사용하는 작업에는 효율적입니다. 목표는 분명하지만 해결 경로를 미리 정하기 어려울 때도 루프가 잘 맞습니다.
그래프 엔지니어링은 여러 역할과 분기, 병렬 작업, 합류 지점이 있는 업무에 적합합니다. 예를 들어 코드 변경을 검토할 때 정적 분석 함수가 변경 파일을 분류하고, 보안 에이전트와 품질 에이전트가 동시에 검토한 다음, 두 결과를 통합하는 노드가 최종 보고서를 만들 수 있습니다. 높은 위험을 발견하면 사람의 승인을 받는 노드로 보내고, 문제가 없으면 배포 단계로 넘깁니다.
둘 중 하나만 선택할 필요는 없습니다. 전체 업무는 그래프로 구성하고 특정 노드 안에서는 에이전트가 루프를 돌며 문제를 풀 수 있습니다. 그래프는 조직도와 작업 지도에 가깝고, 루프는 각 담당자가 문제를 해결하는 사고 과정에 가깝다고 보면 됩니다.
구분 기준은 간단합니다. 실행 순서와 승인 조건을 설명할 수 있고 같은 결과를 반복해서 만들어야 한다면 그래프로 명시하는 편이 좋습니다. 반대로 정확한 경로를 사전에 알 수 없고 에이전트가 탐색해야 한다면 루프를 열어 둡니다. 그래프를 지나치게 세밀하게 만들면 작은 변화에도 코드를 수정해야 합니다. 반대로 루프에 너무 많은 자유를 주면 모델 호출과 도구 사용이 불필요하게 늘어나 비용을 예측하기 어렵고, 같은 요청에도 결과의 품질이 달라질 수 있습니다.
ADK로 만드는 그래프형 실행 구조
ADK는 구글이 공개한 오픈 소스 에이전트 개발 프레임워크입니다. ADK 2.0은 에이전트와 도구, 일반 함수를 노드로 두고 방향이 있는 연결선으로 이어 하나의 그래프 워크플로를 구성합니다. 개발자는 각 노드의 입력과 출력을 상태로 전달하고, 노드가 내보내는 결과에 따라 다음 노드를 고르도록 라우팅할 수 있습니다. 사람의 입력을 기다리는 노드도 둘 수 있습니다. 이전 버전의 순차·병렬·반복 워크플로 에이전트도 동작하지만, ADK 2.0은 분기를 더 세밀하게 통제할 수 있는 그래프 정의로 옮기기를 권합니다.
가장 작은 그래프부터 살펴보겠습니다. 첫 번째 노드에서 정해진 함수가 입력 자료의 형식과 필수 값을 검사합니다. 검사를 통과하면 두 번째 노드의 에이전트가 내용을 요약합니다. 형식이 맞지 않으면 보정 단계로 보냅니다. AI가 잘할 필요가 없는 검증을 함수가 맡으니 결과가 더 안정적이고 토큰 사용량도 줄어듭니다.
그래프를 좀 더 키워야 할 때는 어떻게 해야 할까요? 업무가 커지면 병렬 구조를 더합니다. 시장 조사라면 제품, 고객, 경쟁사 조사를 각각 수행한 뒤 합류 노드에서 하나의 보고서로 통합할 수 있습니다. 작업 수가 입력에 따라 달라지면 실행 시점에 필요한 하위 작업을 만드는 동적 워크플로를 적용할 수 있습니다. 다만 동적 구조는 관찰과 통제가 어려워질 수 있으니 최대 분기 수, 시간 제한, 비용 한도, 실패 시 대체 경로를 함께 정해야 합니다.
한편 그래프 엔지니어링에서는 흐름을 그리는 일만큼 노드 사이의 입력과 출력 기준을 명확히 하는 것도 중요합니다. 모든 대화와 중간 결과를 다음 노드로 넘기면 맥락이 불필요하게 커지고 작업과 관계없는 정보까지 뒤섞입니다. 따라서 각 노드에는 작업에 필요한 데이터만 명시적으로 전달하고, 중간 산출물과 판단 근거는 구조화해 남겨야 합니다.
함수와 에이전트는 어떻게 나눌까?
그래프 엔지니어링의 핵심 메시지는 모든 일을 AI에 맡기지 말라는 것입니다. 기업 업무에는 규칙이 분명한 단계가 많습니다. 데이터 조회, 형식 검증, 승인 조건 판단은 함수로 처리하는 편이 빠르고 정확하고 저렴합니다. 맥락을 해석하고 문장을 만드는 단계만 에이전트에 맡기면 됩니다. 시작은 기존 업무 프로세스를 그래프로 그려 보는 일입니다. 각 단계를 보며 “이 단계에 추론이 필요한가?”를 묻습니다. 필요 없다면 함수 노드로, 필요하다면 에이전트 노드로 둡니다. 이미 운영 중인 사내 API와 배치 로직은 버릴 자산이 아닙니다. 그래프의 함수 노드로 그대로 재활용할 수 있습니다. 이렇게 설계하면 얻을 수 있는 것이 많습니다. 노드 단위로 테스트하니 문제 지점을 빨리 찾습니다. LLM 호출 수를 통제하니 비용을 예측하기 쉽습니다. 사람의 승인이 필요한 지점도 명확하게 둘 수 있어 규제 요구에도 대응할 수 있습니다.
에이전트 워크플로 설계가 고민이라면?
에이전트 도입이 PoC에서 멈추는 이유는 대개 모델이 아니라 구조에 있습니다. 프롬프트 하나에 모든 절차를 담으면 검증할 지점도, 고칠 지점도 사라집니다. 지금 점검할 질문은 두 가지입니다.
- 우리 업무는 입력 전에 워크플로를 그릴 수 있는가?
- 그 가운데 정말 추론이 필요한 단계는 어디인가?
ADK를 기반으로 함수·에이전트·사람의 역할을 나누고 관측 가능한 업무 흐름을 만들고 싶다면 메가존소프트 문의 포털을 통해 상담을 신청해 주세요.
