Graph Engineering 실습 20분만에 마스터하기
📺 원본 영상: Graph Engineering 실습 20분만에 마스터하기
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-08-29
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환한 STT 자료를 바탕으로 작성했습니다. 화면에 표시된 프롬프트, 코드, JSON 구조, 실행 로그 및 대시보드의 세부 내용은 포함되지 않을 수 있습니다.
개요
이 영상에서 말하는 Graph Engineering(그래프 엔지니어링)은 복잡한 AI 작업을 여러 개의 노드로 분리한 뒤, 노드 사이의 실행 순서와 상태 전달, 병렬 처리, 검증 및 사람의 승인을 명시적으로 설계하는 방법을 의미한다. 강연자는 강남구·마포구·종로구의 Airbnb 숙소를 조사하는 사례를 통해, 하나의 파일럿 파이프라인을 먼저 검증하고 이를 여러 지역으로 확장하는 과정을 보여준다. 핵심은 에이전트의 수를 늘리는 데 있지 않으며, 어떤 작업을 병렬화하고 어디서 결과를 합칠지, 어느 단계에 결정론적 검증과 사람의 판단을 배치할지를 설계하는 데 있다.
영상의 워크플로는 환경 설정, 웹 데이터 수집, 프로그램 기반 검증, 지역별 병렬 조사, 결과 병합, LLM 추천, 추천 결과 재검증, Human-in-the-loop(사람 참여형 의사결정)의 순서로 진행된다. 각 단계가 생성한 결과를 파일로 저장해 다음 노드에 전달하기 때문에, 중간 단계에서 오류가 발생해도 전체 그래프를 처음부터 다시 실행하지 않고 해당 지점부터 복구할 수 있다. 이러한 구조는 AI 에이전트를 단순한 대화형 도구가 아니라 추적 가능하고 재실행 가능한 업무 시스템으로 만드는 실용적인 접근법이다.
Graph Engineering은 무엇을 설계하는가
강연자가 제시하는 그래프의 기본 단위는 Node(노드)와 State(상태)이다. 노드는 환경을 구성하거나 데이터를 수집하고 검증하는 하나의 작업 단위를 뜻하며, 상태는 한 노드가 다음 노드에 넘겨주는 입력과 결과를 의미한다. 실제 에이전트 시스템에서는 각 노드가 독립된 실행 환경이나 별도 에이전트가 될 수 있으므로, 노드 사이에 어떤 정보를 어떤 형식으로 전달할 것인지가 그래프의 안정성을 결정한다.
영상에서는 이러한 상태 전달을 프로젝트 폴더 안의 파일로 모사한다. 정리된 결과는 Markdown 폴더에, 가공되지 않은 원본 데이터는 raw 폴더에, 실행 과정은 log 폴더에 저장하며, 각 노드는 앞선 단계가 만든 파일을 읽어 다음 작업을 수행한다. 이는 실제 그래프 프레임워크의 메모리나 상태 저장소를 그대로 구현한 것은 아니지만, 서로 독립적인 노드가 명시적인 산출물을 통해 협업한다는 원리를 이해하기에는 효과적인 실습 구조다.
강연자는 Codex와 같은 실행 환경에서는 에이전트와 도구 호출이 내부적으로 작업 그래프와 유사한 형태를 만들 수 있다고 설명한다. 다만 영상에서는 별도의 API 기반 멀티에이전트 시스템까지 구축하지 않고, 익숙한 개발 환경 안에서 각 단계를 독립된 에이전트라고 가정해 전체 흐름을 시연한다. 따라서 이 영상의 실습은 특정 그래프 프레임워크의 문법을 학습하는 과정이라기보다, 그래프형 에이전트 워크플로를 설계하는 사고방식을 익히는 데 초점이 맞춰져 있다.
전체 그래프보다 먼저 만들어야 할 하나의 파이프라인
강연자가 가장 먼저 강조하는 원칙은 전체 작업을 곧바로 병렬화하지 않는 것이다. 영상에서는 강남구 한 곳만을 대상으로 환경 설정부터 숙소 수집과 검증까지 이어지는 End-to-end(종단 간) 파이프라인을 먼저 완성한다. 하나의 지역에서도 안정적으로 끝나지 않는 작업을 세 지역이나 수백 개 대상으로 확장하면, 동일한 오류가 동시에 반복되면서 토큰과 실행 시간, 외부 API 비용이 함께 증가하기 때문이다.
파일럿 파이프라인은 단순한 데모가 아니라 그래프 전체의 실행 계약을 정의하는 역할을 한다. 입력에는 여행 지역과 날짜 같은 조건이 들어가고, 출력에는 숙소의 식별자와 가격, 평점, 리뷰 수 등 후속 검증에 필요한 필드가 포함된다. 강연자는 AI가 임의의 숙소를 만들어내지 않도록 실제 API 데이터만 사용하라는 조건을 명시하고, 결과 파일의 저장 위치와 완료 보고 형식까지 프롬프트에 포함한다.
이 과정에서 중요한 것은 프롬프트를 길게 쓰는 것 자체가 아니라 입력과 출력의 경계를 분명하게 만드는 일이다. 출력 형식이 느슨하면 후속 노드가 데이터를 안정적으로 읽을 수 없고, 검증 코드 역시 매번 달라지는 구조를 처리해야 한다. 반대로 초기 파일럿에서 데이터 규격과 저장 규칙을 고정하면, 같은 파이프라인을 여러 에이전트로 복제해도 각 결과를 동일한 방식으로 검사하고 합칠 수 있다.
💡 [영상 참조] 강연자는 이 구간에서 실행 환경의 폴더와 상태 파일, 지역 및 여행 조건이 포함된 프롬프트를 화면으로 보여준다. STT에는 파일의 전체 구조와 프롬프트 원문이 포함되어 있지 않으므로 세부 형식은 원본 영상에서 확인해야 한다.
모든 노드에 LLM을 넣지 않는 설계
그래프를 구성한다고 해서 모든 노드를 LLM으로 실행할 필요는 없다. 강연자는 실행 폴더 생성이나 정해진 파일 배치처럼 결과가 명확한 환경 설정 작업을 Deterministic Task(결정론적 작업)로 분류한다. 영상에서는 편의를 위해 LLM에 환경 생성을 맡겼지만, 실제 운영 환경에서는 단순 스크립트로 처리하는 편이 더 빠르고 저렴하며 결과도 일관적이라고 설명한다.
같은 원칙은 데이터 검증에도 적용된다. JSON이 정상적으로 파싱되는지, 필수 필드가 존재하는지, 조사 지역이 요청한 지역과 일치하는지, 평점이나 가격이 지정한 조건을 만족하는지는 코드로 정확하게 판정할 수 있다. 이런 문제를 다시 LLM에게 묻는다면 답변의 일관성이 떨어질 수 있을 뿐 아니라, 반복 실행할 때마다 토큰 비용과 지연 시간이 발생한다.
반면 여러 숙소의 가격, 평점, 리뷰 수를 종합해 최종 후보를 추천하는 일은 단순한 참·거짓 판정으로 환원하기 어렵다. 강연자는 이처럼 의미 해석과 선택이 필요한 단계에는 LLM을 배치하고, 파일 처리와 규칙 검증에는 일반 코드를 배치한다. 결국 좋은 그래프는 LLM을 많이 사용하는 그래프가 아니라, LLM이 필요한 판단과 일반 프로그램이 더 잘하는 처리를 구분한 그래프라고 볼 수 있다.
실시간 웹 데이터를 에이전트에 공급하는 방법
Airbnb 숙소 추천을 실제로 수행하려면 에이전트가 현재 웹페이지의 데이터를 안정적으로 가져올 수 있어야 한다. 그러나 Airbnb처럼 JavaScript로 동적으로 렌더링되는 사이트는 단순 HTTP 요청만으로 필요한 결과를 얻기 어려울 수 있으며, 브라우저 실행과 Proxy(프록시), 페이지 렌더링 및 응답 정리까지 여러 문제가 따라온다. 강연자는 이 복잡성을 하나의 수집 계층으로 감싸기 위해 Oxylabs Web Scraper API를 사용한다.
영상 설명에 따르면 해당 API는 공개 웹페이지 접근, JavaScript 렌더링, 프록시 운영 및 결과 반환을 하나의 요청 흐름으로 처리한다. 강연자는 먼저 플레이그라운드에서 요청 결과와 스냅샷을 확인한 뒤, 같은 요청 방식을 그래프의 조사 노드에 연결하는 방법을 보여준다. 강남구 파일럿 실행에서는 API가 HTTP 200 응답과 약 3.05MB의 Airbnb 원본 데이터를 반환했다고 설명한다.
수집 결과에는 가격과 평점, 리뷰 수 등이 정리된 Markdown 및 JSON 데이터가 포함되며, 가공 전 응답도 별도의 raw 파일로 보존된다. 원본 데이터가 남아 있으면 후속 변환이나 추천 노드가 실패하더라도 값비싼 웹 수집을 다시 실행할 필요가 없다. 원본은 재처리의 기준점이 되고, 정리된 데이터는 후속 노드가 읽기 쉬운 인터페이스가 되므로, 두 계층을 분리하는 것이 복구 가능성과 감사 가능성을 함께 높인다.
💡 [영상 참조] 강연자는 Oxylabs 대시보드와 플레이그라운드, 실제 API 응답 및 수집된 숙소 파일을 화면에서 차례로 확인한다. 화면에 표시된 전체 JSON과 숙소별 세부 데이터는 STT만으로 복원할 수 없으므로 원본 영상을 참조해야 한다.
검증 가능한 데이터 계약 만들기
사람이 결과 파일을 직접 열어보면 데이터가 그럴듯한지 판단할 수 있지만, 자동화된 그래프에서는 매 실행마다 사람이 수집 결과를 확인할 수 없다. 따라서 수집 노드 다음에는 결과를 프로그램으로 검증하는 별도의 노드가 필요하다. 강연자는 파일 존재 여부, JSON 파싱 성공 여부, 지역 값의 일치 여부, Listing ID(숙소 식별자)와 가격 등 필수 값의 존재 여부를 확인하는 검증 코드를 작성하도록 요청한다.
영상에서는 별도의 언어를 지정하지 않았지만 Python이 선택되었으며, 강연자는 대량의 구조화 데이터를 비교적 간결한 코드로 처리할 수 있다는 점을 이유로 든다. 생성된 검증기는 조건을 만족하면 PASS, 그렇지 않으면 FAIL을 반환하고 그 결과를 로그로 저장한다. 파일럿 데이터에서는 12개 숙소가 모두 검증을 통과한 것으로 설명된다.
여기서 검증 노드는 단순한 오류 확인을 넘어 다음 단계로 진행할 자격을 판정하는 Gate(게이트)가 된다. 수집 결과가 실패했는데도 추천 노드가 실행되면, LLM은 불완전하거나 잘못된 데이터를 그럴듯한 추천으로 포장할 수 있다. 반대로 검증 결과를 명시적인 상태로 남기고 PASS 데이터만 다음 노드로 전달하면, 잘못된 입력이 그래프 후반으로 전파되는 것을 줄일 수 있다.
💡 [영상 참조] 이 부분에서 강연자는 화면에 생성된 Python 검증 코드와 PASS 결과를 표시한다. 코드는 음성에서 필드 단위로 낭독되지 않았으므로, 본 리포트에서는 검증 목적과 실행 원리만 정리했다.
Fan-out으로 독립 작업을 병렬화하기
강남구 파일럿이 통과한 뒤에는 같은 조사 파이프라인을 강남구, 마포구, 종로구의 세 지역으로 확장한다. 메인 에이전트는 세 개의 독립된 서브에이전트를 생성하고, 각 에이전트는 지정된 지역만 조사해 별도의 파일에 결과를 저장한다. 이처럼 하나의 실행 흐름을 여러 독립 작업으로 펼치는 구조를 Fan-out(팬아웃)이라고 한다.
지역별 숙소 조사는 서로의 결과를 기다릴 필요가 없으므로 병렬화에 적합하다. 강남구의 데이터를 수집하는 과정은 마포구나 종로구의 데이터에 의존하지 않으며, 한 지역의 요청이 실패해도 다른 지역의 성공 결과까지 폐기할 이유가 없다. 각 노드가 독립된 API 요청과 상태 파일을 갖도록 만들면 실패한 지역만 재시도할 수 있어, 전체 시스템의 장애 격리 능력이 높아진다.
강연자는 동일한 스크래핑 API를 사용하면 각 에이전트에 별도의 브라우저 환경을 제공하거나 브라우저 간섭을 관리하는 부담을 줄일 수 있다고 설명한다. 또한 독립적인 요청 구조이므로 세 개뿐 아니라 더 많은 작업으로 확장할 수 있다고 주장하지만, 실제 확장 한도는 API의 동시 요청 제한과 비용, 대상 사이트 정책, 네트워크 용량 및 데이터 처리 성능에 따라 달라질 수 있다. 따라서 병렬화를 설계할 때는 작업의 독립성뿐 아니라 외부 서비스의 Rate Limit(호출 제한)과 재시도 정책도 함께 고려해야 한다.
💡 [영상 참조] 강연자는 세 지역의 서브에이전트가 동시에 실행되는 화면과 Oxylabs 대시보드의 요청 통계를 보여준다. 대시보드에 표시된 세부 요청 기록은 원본 영상에서 확인할 수 있다.
병렬 검증과 실패 격리
조사만 병렬로 실행하고 검증을 하나의 작업으로 묶으면, 특정 지역의 오류가 어디서 발생했는지 파악하기 어려워질 수 있다. 영상에서는 파일럿 단계에서 만든 Python 검증 코드를 재사용해 각 지역 결과를 독립적으로 검사한다. 세 조사 노드가 각각 대응하는 검증 노드로 이어지므로, 수집과 검증이 지역 단위의 완결된 가지를 형성한다.
이 구조의 장점은 검증 규칙을 새로 만들지 않고도 파일럿에서 확인한 계약을 전체 그래프에 적용할 수 있다는 점이다. 각 지역의 JSON이 동일한 스키마를 따르고 필수 조건을 만족하는지 같은 코드로 판정하므로, 병렬 실행이 늘어나도 품질 기준은 일관되게 유지된다. 영상에서는 지역별 검증이 모두 PASS를 기록했고, 병합 단계에서 총 11개의 후보가 검증된 결과로 전달되었다고 설명한다.
다만 파일럿에서는 12개의 강남구 숙소가 통과한 것으로 언급되고, 병렬 실행 후 병합 결과에서는 전체 후보가 11개라고 설명된다. 이는 서로 다른 실행 시점이나 검색 조건에 따른 결과일 수 있지만, STT만으로 두 수치의 관계를 확정하기는 어렵다. 실시간 웹 데이터는 예약 가능 여부와 가격, 검색 날짜에 따라 달라질 수 있으므로, 운영 시스템에서는 실행 ID와 검색 조건, 수집 시각을 각 결과에 함께 기록해야 재현성을 확보할 수 있다.
Fan-in으로 결과를 하나의 판단 문맥에 모으기
병렬 조사가 끝나면 각 지역의 결과를 하나의 컨텍스트로 모아 비교해야 한다. 여러 갈래로 펼쳐졌던 실행을 다시 하나로 합치는 이 과정을 Fan-in(팬인)이라고 한다. 영상에서는 지역별 검증 결과를 병합한 Markdown 파일을 읽고, 검증을 통과한 후보 가운데 세 개의 숙소를 선정하도록 LLM에 요청한다.
추천 노드에는 인터넷을 다시 검색하지 말고 제공된 검증 데이터만 사용하라는 제약이 적용된다. 이러한 제한은 추천의 근거를 특정 데이터 세트 안에 가두기 때문에, LLM이 출처를 알 수 없는 정보를 추가하거나 존재하지 않는 숙소를 만들어낼 가능성을 낮춘다. 추천 결과에는 순위와 Listing ID를 비롯해 가격, 평점, 리뷰 수 등 선택 근거를 추적할 수 있는 필드를 포함하도록 설계한다.
강연자가 화면에서 소개한 1위 후보는 마포구 숙소로, 가격은 16만 3천 원, 평점은 4.91, 리뷰는 125개라고 설명된다. 2위는 강남구 숙소로 가격 16만 5천 원, 평점 4.97, 리뷰 90개라고 언급되며, 종로구 후보도 세 번째 추천에 포함된다. 다만 종로구 숙소의 구체적인 수치는 음성에서 완전히 제시되지 않았으므로 임의로 보완할 수 없다.
| 추천 순위 | 지역 | 가격 | 평점 | 리뷰 수 | 음성에서 언급된 판단 근거 |
|---|---|---|---|---|---|
| 1위 | 마포구 | 163,000원 | 4.91 | 125개 | 비교적 낮은 가격과 높은 평점 |
| 2위 | 강남구 | 165,000원 | 4.97 | 90개 | 높은 평점 |
| 3위 | 종로구 | 음성 미제공 | 음성 미제공 | 음성 미제공 | 세 번째 후보로 선정 |
이 표는 영상의 음성에서 직접 언급된 수치만 정리한 것이며, 화면에만 표시된 세부 조건은 포함하지 않았다. 특히 가격의 통화 단위와 숙박 일수, 세금 및 수수료 포함 여부는 STT에서 확인되지 않으므로 실제 예약 가격으로 단정해서는 안 된다. 추천 결과를 실사용하려면 원본 데이터의 검색 날짜와 인원, 숙박 기간 및 결제 조건을 함께 확인해야 한다.
LLM의 추천도 다시 검증해야 하는 이유
수집 데이터가 검증되었다고 해서 LLM이 만든 추천 결과까지 자동으로 정확해지는 것은 아니다. 추천 과정에서 후보 수가 달라지거나 Listing ID가 원본에 없는 값으로 바뀔 수 있고, 가격과 평점이 잘못 복사될 가능성도 있다. 강연자는 결과가 생성될 때마다 검증하는 습관이 중요하다고 강조하며, 추천 노드 뒤에도 별도의 프로그램 검증을 배치한다.
추천 검증기는 결과가 정확히 세 개인지, 추천된 숙소가 검증된 후보 집합에 속하는지, 필요한 값이 올바르게 포함되었는지를 검사한다. 이 단계 역시 의미 판단보다는 구조와 참조 무결성을 확인하는 일이므로 LLM 대신 Python 코드로 처리한다. 영상에서 해당 검증은 모두 PASS한 것으로 나타나며, 통과한 추천 결과만 마지막 승인 노드로 전달된다.
이처럼 입력 데이터와 생성 결과를 모두 검증하면 그래프의 신뢰 경계가 분명해진다. 웹 수집 뒤의 검증은 외부 데이터의 품질을 보장하고, 추천 뒤의 검증은 LLM 출력의 형식과 근거 연결을 확인한다. 완벽한 진실성을 보장할 수는 없지만, 적어도 어떤 단계가 어떤 조건을 통과했는지 추적할 수 있어 오류 발견과 재실행이 쉬워진다.
상태 저장은 부가 기능이 아니라 복구 전략이다
영상의 모든 주요 노드는 결과를 파일로 저장하고, 다음 노드는 그 파일을 명시적으로 읽는다. 이 방식은 실행 중인 에이전트의 대화 문맥에만 정보를 맡기지 않고, 각 단계의 산출물을 Durable State(지속 가능한 상태)로 남긴다는 의미가 있다. 그래프가 중간에 중단되더라도 마지막으로 성공한 상태를 기준으로 작업을 이어갈 수 있으며, 문제가 발생한 노드만 다시 실행할 수 있다.
특히 원본 응답과 정리된 데이터, 검증 결과, 추천 결과를 분리하면 오류의 위치를 좁히기 쉬워진다. 원본은 정상인데 정리된 JSON이 잘못되었다면 변환 단계의 문제이고, JSON은 정상인데 추천이 틀렸다면 추천 노드나 프롬프트의 문제로 볼 수 있다. 로그까지 함께 저장하면 어떤 실행이 어떤 입력과 조건을 사용했는지 추적할 수 있어 디버깅과 감사에 도움이 된다.
이 구조를 실제 운영 환경으로 옮길 때는 단순한 파일명보다 실행 ID와 노드 ID, 상태 버전, 생성 시각 및 입력 해시를 함께 관리하는 편이 안전하다. 동일한 파일을 덮어쓰면 과거 실행을 재현하기 어렵고, 여러 에이전트가 동시에 쓸 때 충돌이 발생할 수 있기 때문이다. 영상의 폴더 기반 실습은 이러한 원칙을 간단히 보여주지만, 규모가 커지면 객체 저장소나 데이터베이스, 워크플로 엔진의 체크포인트 기능으로 확장할 필요가 있다.
Human-in-the-loop가 필요한 지점
모든 검증을 통과한 뒤에도 최종 선택은 사람에게 맡긴다. 영상에서 마지막 노드는 추천 검증이 PASS인 경우에만 승인 요청을 만들며, 사용자는 세 후보 가운데 하나를 승인하거나 거절하고 수정 조건을 제시할 수 있다. 사람의 판단이 그래프에 명시적인 노드로 포함되는 이러한 구조를 Human-in-the-loop(사람 참여형 의사결정)라고 한다.
사람이 추천을 거절하면 그 이유를 새로운 상태로 입력해 그래프를 다시 실행할 수 있다. 예를 들어 특정 지역을 제외하거나 가격 조건을 바꾸고 싶다면, 피드백을 앞단의 검색 조건에 반영해 조사부터 다시 수행하도록 설계할 수 있다. 이때 거절은 단순한 종료가 아니라 다음 실행을 위한 구조화된 입력이 된다.
영상의 데모에서는 실제 결제와 예약을 수행하지 않으므로 사람의 승인이 그래프의 마지막 단계다. 그러나 예약 노드가 뒤에 연결된다면 승인은 그래프 중간의 안전 게이트가 되며, 승인된 경우에만 외부 시스템에 실제 변경을 가하는 작업이 진행된다. 결제, 계약, 데이터 삭제처럼 되돌리기 어렵거나 비용을 발생시키는 행동일수록 자동화 직전에 사람의 승인을 배치하는 것이 중요하다.
실무 설계로 확장할 때의 핵심 원칙
영상의 사례를 일반화하면 그래프 설계는 먼저 전체 업무를 입력, 처리, 검증, 판단, 승인 단계로 분해하는 데서 시작한다. 이후 하나의 작은 대상에 대해 End-to-end 파이프라인을 실행하며 데이터 규격과 오류 조건을 확정하고, 안정성이 확인된 뒤 독립적인 구간만 Fan-out한다. 병렬 작업이 끝나면 각 결과를 동일한 기준으로 검증한 뒤 Fan-in해 하나의 판단 문맥으로 모아야 한다.
병렬화의 기준은 작업량이 많다는 사실이 아니라 작업 사이의 의존성이다. 지역별 조사는 독립적이므로 동시에 실행할 수 있지만, 추천은 모든 지역의 검증된 결과가 준비되어야 시작할 수 있다. 검증되지 않은 일부 결과를 먼저 추천 문맥에 넣으면 실행 시점에 따라 결과가 달라질 수 있으므로, Fan-in 앞에는 모든 필수 분기의 완료와 성공 여부를 확인하는 동기화 조건이 필요하다.
또한 실패를 정상적인 상태로 취급해야 한다. 외부 API는 일시적으로 실패할 수 있고, 웹페이지의 구조가 바뀌거나 일부 데이터가 누락될 수 있으므로, 재시도 횟수와 대기 전략, 실패 결과의 저장 방식 및 부분 성공 처리 규칙을 미리 정해야 한다. 영상에서 강조한 원본 데이터와 로그 저장, 지역별 독립 검증은 이러한 회복 가능한 그래프를 만드는 출발점이다.
강연에서 사용한 웹 수집 도구에 대한 주의
영상 후반에는 Oxylabs Web Scraper API의 무료 체험과 프로모션 코드, 결제 할인에 관한 안내가 포함된다. 강연자는 카드 등록 없이 체험할 수 있고 프로모션 코드를 사용하면 최대 2,000개의 스크래핑 결과를 제공받을 수 있으며, 결제 시 할인도 적용된다고 설명한다. 이러한 조건은 영상 게시 시점의 홍보 정보이므로 현재도 동일하게 적용되는지는 서비스의 공식 페이지에서 별도로 확인해야 한다.
도구의 기술적 편의성과 별개로 웹 수집에는 대상 사이트의 이용약관, robots 정책, 개인정보 보호, 저작권 및 관할 지역의 법률을 검토해야 한다. API가 특정 페이지에 기술적으로 접근할 수 있다는 사실이 해당 데이터를 모든 목적으로 자유롭게 이용할 수 있다는 뜻은 아니다. 특히 숙소 예약처럼 가격과 재고가 실시간으로 변하는 분야에서는 수집 시점과 실제 결제 시점의 차이도 사용자에게 분명히 알려야 한다.
강연자는 요청이 발생하는 지리적 위치를 지정할 수 있어 항공권처럼 검색 위치에 따라 결과가 달라질 수 있는 작업에 활용할 수 있다고 설명한다. 다만 위치별 가격 차이를 실험할 때에도 동일한 날짜와 통화, 쿠키 상태, 로그인 여부 및 기타 조건을 통제해야 의미 있는 비교가 된다. 지리적 요청 옵션은 유용한 실험 도구가 될 수 있지만, 그것만으로 가격 차이의 원인을 확정할 수는 없다.
참고할 만한 기술적 확장 방향
이 영상의 파일 기반 그래프를 실제 시스템으로 발전시키려면 각 노드의 입력과 출력을 명시적인 Schema(스키마)로 정의하는 것이 우선이다. JSON Schema나 데이터 모델을 사용하면 필드 타입과 필수 값, 허용 범위를 코드 수준에서 강제할 수 있으며, 프롬프트에도 같은 계약을 반영할 수 있다. 이는 강연 내용과 별개의 일반적인 엔지니어링 확장 방향이지만, 영상에서 강조한 프로그램 기반 검증을 더 체계적으로 구현하는 방법이다.
다음으로는 Idempotency(멱등성)를 고려해야 한다. 동일한 노드를 같은 입력으로 다시 실행해도 중복 결제나 중복 파일 생성처럼 원치 않는 부작용이 생기지 않아야 하며, 외부 API 요청 결과를 캐시할지 여부도 작업 특성에 따라 정해야 한다. 수집 노드는 검색 시점이 중요하므로 캐시 만료 정책이 필요하고, 검증 노드는 동일한 입력에 대해 언제나 같은 결과를 반환하도록 만드는 것이 바람직하다.
마지막으로 관측 가능성을 확보해야 한다. 각 노드의 시작과 종료 시각, 입력 버전, 실행 비용, 재시도 횟수, 성공 및 실패 사유를 구조화된 로그로 남기면 병목과 오류를 빠르게 찾을 수 있다. 특히 여러 에이전트가 병렬로 실행되는 환경에서는 전체 실행 ID와 개별 분기 ID를 연결해 추적해야, Fan-out 이후 어느 분기가 Fan-in에 포함되었는지 확인할 수 있다.
마무리 / 핵심 정리
이 강연이 전달하는 가장 중요한 메시지는 AI 에이전트의 성능보다 작업 구조의 품질이 먼저라는 점이다. 하나의 파일럿 파이프라인을 끝까지 검증하고, 독립적인 작업만 병렬로 펼친 뒤, 결과를 프로그램으로 검사하고 다시 하나의 판단 문맥으로 모으는 과정이 안정적인 그래프의 뼈대를 만든다. 여기에 각 노드의 상태와 원본 데이터를 저장하면 실패한 지점부터 재시도할 수 있고, 실행 결과의 근거도 추적할 수 있다.
LLM은 추천처럼 의미 판단이 필요한 구간에서 가치가 크지만, 환경 설정과 JSON 검증 같은 결정론적 작업까지 맡길 필요는 없다. 일반 코드가 더 정확하고 저렴한 부분은 스크립트로 처리하고, LLM 출력도 다시 프로그램으로 검증해야 한다. 이러한 역할 분리는 비용 최적화를 넘어 그래프의 예측 가능성과 재현성을 높이는 핵심 설계 원칙이다.
마지막으로 Human-in-the-loop는 자동화를 방해하는 예외가 아니라, 중요한 의사결정을 안전하게 통제하기 위한 정식 노드다. 추천을 승인하는 단순한 예제부터 실제 결제나 예약 직전의 승인까지, 사람이 개입해야 하는 위치는 업무의 위험도와 되돌릴 수 있는 정도에 따라 달라진다. 결국 좋은 Graph Engineering은 에이전트를 무작정 늘리는 기술이 아니라, 데이터와 판단, 검증과 책임의 경계를 명확히 연결하는 시스템 설계다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Graph Engineering 실습 20분만에 마스터하기 |
| 채널 | 코드팩토리 |
| 영상 길이 | 약 21분 18초 |
| 리포트 작성 | 2026-08-29 |
| 작성 방식 | YouTube 영상 STT 변환 후 문맥 교정 및 에디팅 |
| 자료 한계 | 화면의 프롬프트와 코드, JSON 원문 및 대시보드 세부 정보는 미포함 |
| 홍보 정보 | 무료 체험과 프로모션 조건은 영상 내 안내이며 현재 조건은 별도 확인 필요 |
💬 본 리포트는 영상의 음성 내용을 중심으로 재구성했으며, 화면에만 표시된 코드나 데이터는 추측하여 보완하지 않았다. 정확한 프롬프트와 실행 화면, 당시의 서비스 프로모션 조건은 원본 영상 및 해당 서비스의 공식 안내를 참조해야 한다.