[바미] AI 에이전트 하나로 충분할까? 작업 흐름과 GraphRAG 이해하기

들어가기 전에

쇼핑몰 고객에게 ‘주문한 물건이 왜 아직 안 오나요?’라는 문의가 들어왔다고 해봅시다.

AI가 자연스러운 문장을 만드는 것만으로 이 질문에 답할 수 있을까요?

 

먼저 어떤 주문인지 확인해야 합니다. 주문 처리 상태와 택배 이동 기록을 찾아야 하고, 두 정보를 비교해야 합니다. 보상 요청까지 포함되어 있다면 담당자의 판단이 필요할 수도 있습니다.

답변을 잘 만드는 것과, 답변에 필요한 일을 순서대로 처리하는 것은 다른 문제입니다.

 

Google Cloud Tech 영상은 그래프 설계와 GraphRAG 실습을 통해 AI가 여러 작업과 데이터를 연결하는 과정을 보여줍니다. 이 글은 그 내용을 중심으로 정리했습니다.

 

내용은 크게 두 가지입니다. 어떤 일을 어떤 순서로 처리할 것인가와 ‘답변에 필요한 정보를 어떻게 연결할 것인가’입니다.

쇼핑몰 사례는 설명을 위해 덧붙였습니다. 영상 후반에는 재난 생존자들이 서로 필요한 도움을 주고받는 ‘Survivor Network’ 예제가 나옵니다.

AI 에이전트는 일반적인 채팅과 무엇이 다를까요?

일반적인 채팅에서는 질문을 보내고 답변을 받습니다. 에이전트는 목표를 이루기 위해 필요한 도구를 호출하고, 그 결과를 바탕으로 다음 작업을 이어가는 AI입니다. 예를 들어 주문 조회 기능을 호출한 뒤 결과를 읽고 배송 조회가 필요한지 판단할 수 있습니다.

 

그렇다고 에이전트가 모든 일을 알아서 정확하게 한다는 뜻은 아닙니다.

어떤 도구를 쓸 수 있는지, 중간 결과를 어디에 남길지, 오류가 생기면 어떻게 멈출지를 정해야 합니다. 영상 초반에서는 이러한 실행 환경과 작업 흐름을 다룹니다.

용어	의미
하네스(Harness)	AI가 사용할 도구, 기억 공간, 실행 제약 등을 갖춘 작업 환경
루프(Loop)	판단, 도구 실행, 결과 확인을 반복하는 과정
그래프(Graph)	작업이나 정보를 점으로, 연결 관계를 선으로 나타낸 구조

 

세 용어는 서로 대체하는 개념이 아닙니다. 하네스 안에서 AI가 루프를 돌고, 각 작업은 더 큰 그래프의 일부로 연결될 수 있습니다.

여기서 말하는 그래프는 막대그래프가 아닙니다

그래프라는 단어를 들으면 매출을 보여주는 막대그래프를 떠올릴 수 있습니다.

 

이 영상에서 말하는 그래프는 점과 선으로 연결 관계를 표현하는 구조입니다. 점을 노드, 연결선을 엣지라고 부릅니다.

다만 무엇을 연결하는지에 따라 의미가 달라집니다.

구분	점으로 표현하는 것	선으로 표현하는 것
작업 흐름 그래프	조회, 검사, 수정 같은 작업	작업 순서와 조건에 따른 이동
지식 그래프	사람, 기술, 지역 같은 정보	보유한다, 필요하다, 위치한다 같은 관계

 

‘주문 조회가 끝나면 답변을 작성한다’는 작업 흐름입니다.

 

‘이 고객이 이 주문을 했고, 이 주문에 이 상품이 포함되어 있다’는 정보의 관계입니다.

둘 다 그래프라고 부르지만 해결하려는 문제는 다릅니다. 이 차이를 알고 나면 뒤의 GraphRAG 설명도 훨씬 명확해집니다.

코드 검토 작업을 그래프로 나누면

영상 초반에는 개발자가 수정한 코드를 검토하는 과정이 예제로 나옵니다. 개발자는 보통 수정한 코드를 다른 사람이 확인할 수 있도록 풀 리퀘스트(Pull Request), 줄여서 PR을 올립니다.

 

영상의 예제에서는 코드 작성 규칙, 불필요한 코드, 변수 이름, 주석, 빌드 여부 등을 검사합니다. 빌드는 작성한 코드를 실행 가능한 형태로 만드는 과정입니다.

 

서로 독립적인 검사는 동시에 진행할 수 있습니다. 하지만 최종 판단은 필요한 검사 결과가 모인 뒤에 내려야 합니다.

코드 검토 요청
  ├─ 코드 작성 규칙 검사 ─┐
  ├─ 불필요한 코드 검사 ─┤
  ├─ 변수 이름 검사 ─────┤
  ├─ 주석 검사 ──────────┤
  └─ 빌드 검사 ──────────┘
                        ↓
                 검사 결과 모으기
                        ↓
             통과 여부에 따라 나누기
               ├─ 통과: 사람의 승인
               └─ 실패: 수정 후 다시 검사

영상은 이 구조를 세 가지 용어로 설명합니다.

• Fan-out은 하나의 작업을 여러 갈래로 나누어 시작하는 방식입니다.
• Join은 필요한 작업이 모두 끝날 때까지 기다린 뒤 결과를 모으는 지점입니다.
• Router는 조건에 따라 다음 경로를 선택합니다.

특히 결과를 모으는 단계는 단순한 요약이 아닙니다. 아직 끝나지 않은 검사가 있는데 통과 처리하지 않도록 기다리는 역할도 합니다.

 

또한 모든 검사에 AI가 필요한 것은 아닙니다. 명확한 규칙으로 확인할 수 있는 항목은 일반 프로그램이 처리할 수 있습니다. 작업 그래프의 각 단계가 반드시 별도의 AI 에이전트일 필요는 없습니다.

순서대로 할 일과 동시에 할 일 나누기

영상에서는 ADK를 이용한 작업 흐름도 소개합니다. ADK는 Agent Development Kit의 줄임말로, 에이전트를 만드는 데 사용하는 개발 도구 모음입니다.

 

ADK가 제공하는 실행 방식은 크게 세 가지로 나뉩니다.

 

실행 방식	동작	예시
순차 실행	앞 작업이 끝나면 다음 작업을 시작	자료 수집 → 내용 정리 → 요약 작성
병렬 실행	서로 독립적인 작업을 동시에 진행	주문 상태와 배송 기록을 각각 조회
반복 실행	결과를 확인한 뒤 필요한 작업을 다시 진행	초안 작성 → 검토 → 수정

 

병렬 실행이 언제나 좋은 것은 아닙니다. 배송 정보를 조회하려면 주문 번호가 필요하므로 주문 번호 확인이 먼저 끝나야 합니다.

반복 작업에는 종료 조건도 필요합니다. 언제 통과로 볼지, 몇 번 실패하면 사람에게 넘길지 정하지 않으면 같은 수정만 계속할 수 있습니다.

 

각 작업에 어떤 입력이 필요하고 어떤 결과를 내놓는지 정리하는 것이 실행 구조 설계의 시작입니다. 표의 예시는 영상 속 실행 패턴을 일상 업무에 대입해 정리했습니다.

여러 에이전트는 중간 결과를 어떻게 전달할까요?

작업을 나눈 뒤에는 결과를 어떻게 주고받을지 정해야 합니다.

 

주문을 조회하는 에이전트가 결과를 찾았더라도 답변을 작성하는 에이전트가 그 결과를 받지 못하면 소용이 없습니다.

영상에서 소개하는 전달 방식은 세 가지입니다.

 

전달 방식	동작
공유 상태	여러 에이전트가 같은 상태값을 읽고 쓰며 중간 결과를 공유
역할별 위임	요청에 맞는 역할을 가진 하위 에이전트에게 작업을 위임
에이전트를 도구처럼 호출	특정 기능을 맡은 에이전트를 호출해 결과를 받음

 

여기서 상태는 작업이 어디까지 진행됐고 지금까지 어떤 결과를 얻었는지를 나타내는 정보입니다.

공유 상태를 사용한다면 어떤 이름으로 결과를 저장하고 누가 읽을지 정해야 합니다. 일을 위임할 때는 담당 에이전트의 역할과 작업 범위가 분명해야 합니다.

 

사람이 많다고 협업이 저절로 잘되는 것은 아닙니다. 에이전트 역시 수보다 역할과 결과 전달 방식이 중요합니다.

작업 순서에서 정보의 관계로

영상 후반에는 재난 생존자들이 서로 필요한 도움을 주고받는 ‘Survivor Network’ 예제가 나옵니다.

사람마다 위치가 다르고, 가진 기술과 필요한 자원도 다릅니다.

 

예를 들어 ‘치료를 도와줄 수 있는 사람이 있나요?’라는 질문에 답하려면 의료 기술만 찾는 것으로는 부족합니다. 그 기술을 가진 사람이 누구이고 어디에 있는지까지 확인해야 합니다. 아래는 정보 관계를 단순하게 표현한 예시입니다.

민수 ─ 보유 기술 → 응급처치
민수 ─ 현재 위치 → 산악 지역
지영 ─ 필요한 도움 → 상처 처치
지영 ─ 현재 위치 → 산악 지역

정보를 이렇게 연결해두면 개별 단어만 찾는 것이 아니라 사람과 기술, 위치를 함께 확인할 수 있습니다.

지식 그래프는 이런 관계를 데이터에 함께 저장합니다. 물론 데이터상으로 연결된다고 실제 현장에서 곧바로 지원할 수 있다는 뜻은 아닙니다. Survivor Network는 정보 관계를 저장하고 조회하는 방법을 보여주기 위한 예제입니다.

GraphRAG는 정보 사이의 관계까지 찾아옵니다

RAG는 AI가 답변하기 전에 외부 자료를 검색해 관련 정보를 가져오도록 만든 구조입니다. 모델이 이미 학습한 내용에만 의존하지 않고, 별도의 자료를 답변의 근거로 활용합니다.

 

GraphRAG는 검색할 때 그래프에 담긴 관계까지 활용합니다.

‘응급처치’라는 기술 설명을 찾는 데서 끝내지 않고, 그 기술을 가진 사람과 위치까지 연결해서 가져오는 식입니다.

 

영상에서는 Spanner라는 데이터베이스를 활용합니다. 데이터베이스는 정보를 저장하고 필요한 조건에 맞추어 꺼내는 시스템입니다. 실습에서는 표 형태의 데이터와 그래프 관계를 함께 다룹니다.

 

중요한 것은 ‘그래프를 썼다’는 사실이 아니라 답변에 필요한 관계가 실제 조회 결과에 포함됐는지입니다.

관련 기술을 찾았는데 그 기술을 가진 사람을 가져오지 못했다면 ‘누가 도와줄 수 있나요?’라는 질문에는 아직 답할 수 없습니다.

같은 뜻인데 단어가 다르면 어떻게 찾을까요?

사용자는 ‘상처를 치료할 사람’을 찾지만, 데이터에는 ‘응급처치’라는 기술 이름이 등록되어 있을 수 있습니다.

단어가 정확하게 일치하는지만 검사하면 관련 정보를 놓칠 수 있습니다. 이 문제를 보완하는 방법이 의미 검색입니다.

 

의미 검색에서는 글을 숫자의 묶음으로 바꿔 표현이 얼마나 비슷한지 비교합니다. 이렇게 바꾼 표현을 임베딩이라고 부릅니다.

의미 검색의 핵심은 글을 의미가 비슷한 항목끼리 찾기 좋은 형태로 바꾸는 데 있습니다. 다만 의미가 가깝다고 해서 항상 정답인 것은 아닙니다.

검색 방식	검색 기준	주의할 점
키워드 검색	입력한 단어나 검색 조건	표현이 다르면 놓칠 수 있습니다.
의미 검색	표현의 의미가 가까운 정도	정확한 이름이나 필수 조건을 놓칠 수 있습니다.
하이브리드 검색	키워드와 의미 검색을 함께 사용	결합 방식과 조건 적용을 확인해야 합니다.

 

영상에서는 두 검색 결과의 순위를 합치는 RRF라는 방법도 나옵니다. 서로 다른 검색 결과를 종합해 후보의 순서를 다시 정하는 방식입니다. 여기서 검색 순위와 필수 조건은 구분해야 합니다.

 

‘산악 지역에 있는 사람만’ 찾아야 한다면 관련성이 높다는 이유로 다른 지역의 사람이 포함되어서는 안 됩니다. 순위를 합치는 기능과 별개로 지역 조건이 실제 검색에 적용되는지 확인해야 합니다.

 

영상에서 ‘데이터베이스에 모델을 설정한다’는 표현은 AI를 처음부터 새로 학습한다는 뜻이 아닙니다. 외부 모델의 연결 정보를 등록해두고 조회 과정에서 호출하는 구조입니다.

검색 기능을 에이전트의 도구로 연결하기

영상은 검색 기능을 만든 다음 에이전트가 사용할 수 있는 도구로 연결합니다.

 

도구는 AI가 실제로 호출할 수 있는 기능을 뜻합니다. 이 실습에서는 키워드 검색, 의미 검색, 두 방식을 함께 사용하는 검색이 도구에 해당합니다.

 

사용자의 질문은 아래 순서로 처리됩니다.

사용자의 질문
  → 에이전트가 사용할 검색 도구 선택
  → 도구가 데이터베이스에서 근거 조회
  → 에이전트가 조회 결과를 바탕으로 답변 작성
  → 사용자 화면에 표시

에이전트의 역할과 행동 기준도 정해야 합니다. 어떤 질문을 담당하는지, 언제 어떤 도구를 쓰는지, 결과를 어떤 형식으로 전달할지 등을 적습니다.

 

구조를 나눠두면 답변이 틀렸을 때 어디부터 확인해야 하는지도 분명해집니다.

문제	확인할 부분
엉뚱한 검색 도구를 선택함	역할 설명과 도구 선택 기준
올바른 도구를 사용했지만 관련 자료가 없음	저장된 데이터와 검색 조건
자료는 맞지만 답변이 틀림	답변 작성 지침과 결과 처리
답변이 지나치게 늦음	각 작업에 걸린 시간과 반복 호출

 

영상의 테스트 화면에서는 어떤 도구를 호출했고 무엇을 돌려받았는지 확인할 수 있습니다. 최종 답변뿐 아니라 답변이 만들어진 과정까지 확인하는 셈입니다.

브라우저에서 답변이 나오면 시스템이 완성된 것일까요?

후반부에서는 검색과 에이전트를 사용자 화면까지 연결합니다.

 

화면을 만드는 React, 서버에서 요청을 받는 FastAPI, 에이전트를 실행하는 Runner가 등장합니다. 각 구성 요소의 역할은 아래와 같습니다.

구성 요소	역할
사용자 화면	질문을 입력받고 결과를 표시
서버	화면에서 보낸 요청을 받아 처리 기능으로 전달
에이전트 실행 부분	도구 호출과 답변 생성 과정을 실행
세션 관리	현재 대화의 상태와 기록을 관리
데이터베이스	검색에 필요한 정보를 저장하고 제공

 

세션은 하나의 대화나 작업이 이어지는 범위를 뜻합니다.

영상의 실습에서는 대화 정보를 실행 중인 프로그램의 메모리에 보관합니다. 프로그램을 껐다 켜도 기록이 남는 저장 방식과는 다릅니다.

 

실제로 운영할 서비스라면 프로그램을 재시작한 뒤에도 필요한 정보를 복구할 수 있어야 합니다.

영상의 전체 구조도에는 장기 기억과 여러 종류의 입력을 처리하는 기능도 나옵니다. 하지만 모든 기능을 이 영상에서 끝까지 구현하고 검증하는 것은 아닙니다. 일부는 이후 영상에서 다룰 내용으로 소개됩니다.

24시간 운영하려면 추가로 정해야 할 것이 있습니다

제공된 영상 파일명에는 ‘24/7 시스템’이라는 표현이 들어 있습니다. 24/7은 하루 24시간, 일주일 내내 운영한다는 뜻입니다.

하지만 화면에서 질문과 답변이 한 번 오갔다고 지속적인 운영까지 검증된 것은 아닙니다.

 

실제 운영 단계에서는 아래 항목도 확인해야 합니다. 영상에서 직접 구현한 내용이 아니라 운영 관점에서 덧붙인 질문입니다.

• 외부 검색 기능이 응답하지 않으면 어떻게 하나요?
• 같은 요청을 다시 처리해도 문제가 없나요?
• 반복 수정은 언제 멈추나요?
• 서버가 재시작되면 대화를 복구할 수 있나요?
• 누가 어떤 데이터에 접근할 수 있나요?
• 답변 품질과 사용 비용은 어떻게 확인하나요?
• 자동으로 처리하기 어려운 일은 누구에게 넘기나요?

그래프를 도입했다고 이런 문제가 자동으로 해결되지는 않습니다. 기억을 저장한다고 시스템이 스스로 성능을 개선하는 것도 아닙니다.

 

작업 흐름을 구현하는 것과 장기간 안정적으로 운영하는 것은 별개의 과제입니다.

모든 업무에 여러 에이전트와 그래프가 필요할까요?

앞서 든 고객 문의를 기준으로 보면 상황에 따라 필요한 구조가 달라집니다. 주문 번호 하나로 배송 상태를 조회하는 정도라면 간단한 프로그램과 하나의 에이전트로 충분할 수 있습니다.

 

반면 여러 정보를 함께 조회하고, 조건에 따라 담당자를 바꾸고, 실패한 작업을 다시 처리해야 한다면 명시적인 작업 흐름이 도움이 될 수 있습니다.

 

데이터도 마찬가지입니다. 기존 데이터베이스 조회만으로 필요한 관계를 충분히 가져올 수 있다면 지식 그래프를 따로 도입할 필요는 없습니다.

 

복잡한 구조 자체가 목표가 되어서는 안 됩니다. 현재 작업에서 막히는 지점이 무엇이고, 그래프나 여러 에이전트가 실제로 그 문제를 해결하는지부터 따져봐야 합니다.

중간 정리

지금까지의 내용은 작업, 정보, 검토라는 세 가지 관점으로 나눌 수 있습니다.

관점	핵심 질문
작업 흐름	어떤 작업을 먼저 하고, 무엇을 기다리고, 실패하면 어디로 돌아가나요?
정보 관계	답변에 필요한 사람·기술·위치 등의 관계를 가져올 수 있나요?
실행 검토	어떤 도구가 어떤 근거를 가져와 최종 답변을 만들었나요?

 

작업 흐름 그래프는 실행 순서를 다루고, 지식 그래프는 정보의 관계를 다룹니다. GraphRAG는 이러한 관계를 검색과 답변에 활용합니다.

마치며

AI 에이전트 시스템에서 중요한 것은 에이전트의 수가 아닙니다. 어떤 일을 맡길지, 필요한 정보를 어디에서 가져올지, 결과를 다음 단계에 어떻게 전달할지를 정해야 합니다. 문제가 생겼을 때 멈추거나 다시 처리하는 방법도 여기에 포함됩니다.

 

처음에는 현재 맡고 있는 업무 하나를 골라 순서대로 해야 하는 일, 동시에 해도 되는 일, 사람이 확인해야 하는 일로 나눠보면 됩니다.

 

그다음 답변에 어떤 정보가 필요하고 서로 어떻게 연결되는지 정리합니다. 이 두 가지가 분명해지면 에이전트와 검색 기능을 어디에 써야 할지도 구체적으로 판단할 수 있습니다.

참고 자료

• Google Cloud Tech — Graph Engineering 101
• Google Codelabs — Build a Multimodal AI Agent with Graph RAG, ADK & Memory Bank
• ADK 워크플로 공식 문서