루프 나온지도 얼마 안 됐는데 그래프 엔지니어링? 5분만에 쉽게 설명해드림. > AI 엔지니어링

이전글헤르메스 에이전트 쓰면 쓸수록 똑똑해집니다! 스스로 진화하는 AI 비서 … 다음글 Codex 마스터 클래스 1시간 편집본 | 하네스 설계부터 서비스 배포까…

최고관리자

26-08-29 21:46 0개 20회

루프 나온지도 얼마 안 됐는데 그래프 엔지니어링? 5분만에 쉽게 설명해드림.

# 그래프 엔지니어링 상세 정리 > **원본 영상:** [루프 나온지도 얼마 안 됐는데 그래프 엔지니어링? 5분만에 쉽게 설명해드림.](https://www.youtube.com/watch?v=BtM2JZCMtL8) > **채널:** ZeroCho TV > **게시일:** 2026년 7월 28일 > **영상 길이:** 18분 46초 > **핵심 주제:** 루프 엔지니어링과 그래프 엔지니어링의 관계, 도입 시점, 상태 관리, LangGraph 기반 구현 개념 > **광고 안내:** 영상 중간에 Hostinger VPS 협찬 구간이 포함되어 있습니다. *** ## 1\. 영상의 핵심 메시지 이 영상은 최근 등장한 \*\*그래프 엔지니어링(Graph Engineering)\*\*이라는 표현을 소개하면서, 이것이 완전히 새로운 기술은 아니라고 설명합니다. 영상의 관점을 한 문장으로 정리하면 다음과 같습니다. > **루프가 단순할 때는 프롬프트나 반복문으로 충분하지만, 작업·조건 분기·병렬 처리·상태가 많아져 사람이 흐름을 머릿속으로 추적하기 어려워지면 노드와 엣지로 명시적인 그래프를 설계해야 한다.** 그래프 엔지니어링은 AI에게 단순히 “완료할 때까지 반복하라”고 요청하는 방식보다 한 단계 더 구조적입니다. * 각 작업 단계를 \*\*노드(Node)\*\*로 정의합니다. * 다음 단계로 이동하는 조건을 \*\*엣지(Edge)\*\*로 연결합니다. * 모든 단계가 공유하는 데이터를 \*\*상태(State)\*\*로 표준화합니다. * 실행 위치를 저장해 중단된 작업을 **체크포인트에서 재개**합니다. * 작업 성격에 따라 AI, 일반 프로그램, 사람을 적절한 노드에 배치합니다. 영상은 이러한 방식이 LangGraph 같은 도구를 통해 이미 구현되어 왔으며, ‘그래프 엔지니어링’이라는 이름만 최근에 새롭게 주목받은 것이라고 설명합니다. *** ## 2\. ‘그래프 엔지니어링’이라는 용어에 대한 영상의 입장 영상은 그래프 엔지니어링이라는 말이 기존 AI 엔지니어링 용어가 너무 자주 바뀌는 현상을 풍자하는 농담에서 시작됐다고 설명합니다. 영상이 제시하는 흐름은 다음과 같습니다. 1. 프롬프트 엔지니어링 2. 컨텍스트 엔지니어링 3. 하네스 엔지니어링 4. 루프 엔지니어링 5. 그래프 엔지니어링 처음 표현을 확산시킨 사람들은 “아직도 루프 엔지니어링을 이야기하느냐, 이제 그래프로 넘어가야 한다”는 식으로 빠르게 바뀌는 용어를 풍자했지만, 영향력 있는 인물들의 말이 진지하게 받아들여지면서 강의와 로드맵이 만들어졌다고 설명합니다. 영상에서는 다음과 같은 과장된 주장과 출처가 불명확한 정보가 함께 확산됐다고 지적합니다. * 특정 기업이 기존 기술을 그래프 엔지니어링으로 대체했다는 주장 * 유명 대학이나 AI 기업이 그래프 엔지니어링을 공식 채택했다는 주장 * 그래프 엔지니어링을 도입하면 정확도가 일정 비율 향상되고 비용이 크게 줄어든다는 일반화 특히 정확도 향상과 비용 절감 수치로 언급된 사례는 영상의 조사에 따르면 특정 산업용 도면 작업에만 적용된 좁은 연구였으며, 모든 AI 업무에서 같은 효과가 발생하는 것처럼 확대 해석해서는 안 된다고 설명합니다. > 이 문서는 영상 내용을 요약한 것이며, 위 용어의 기원과 사례에 관한 주장은 영상 제작자의 설명을 기준으로 정리했습니다. *** ## 3\. 프롬프트부터 그래프까지의 관계 각 엔지니어링 개념은 완전히 대립하는 기술이 아니라, AI 시스템에서 설계하는 범위가 점점 넓어지는 관점으로 이해할 수 있습니다. | 개념 | 설계 대상 | 핵심 질문 | | --- | ----- | ----- | | **프롬프트 엔지니어링** | 한 번의 지시와 질문 | 어떻게 요청할 것인가? | | **컨텍스트 엔지니어링** | 모델이 판단할 때 보는 정보 | 무엇을 보여줄 것인가? | | **하네스 엔지니어링** | 모델을 둘러싼 규칙·도구·권한·환경 | 어떤 환경에서 일하게 할 것인가? | | **루프 엔지니어링** | 실행·검증·수정·종료의 반복 | 어떻게 반복하고 언제 멈출 것인가? | | **그래프 엔지니어링** | 여러 작업·분기·병렬 처리·상태의 전체 흐름 | 복잡한 실행 경로를 어떻게 명시적으로 연결하고 관리할 것인가? | ### 개념이 서로 대체되는 것은 아니다 그래프 안에서도 각 AI 호출에는 프롬프트와 컨텍스트가 필요합니다. AI가 사용할 도구와 제한은 하네스로 구성되고, 그래프의 일부 경로는 반복되는 루프가 될 수 있습니다. 즉, 다음과 같은 포함 관계로 이해하는 것이 자연스럽습니다. * 그래프 안에 여러 루프가 존재할 수 있습니다. * 루프를 실행하는 에이전트에는 하네스가 필요할 수 있습니다. * 하네스는 컨텍스트와 도구를 관리합니다. * 각각의 AI 호출에는 프롬프트가 들어갑니다. *** ## 4\. 루프도 그래프의 일종이다 영상은 루프와 그래프 사이에 명확한 경계선이 없다고 강조합니다. 그래프는 일반적으로 다음 두 요소로 구성됩니다. * **노드:** 작업이나 절차를 나타내는 상자 * **엣지:** 다음 작업으로 이동하는 경로를 나타내는 화살표 루프 역시 노드와 엣지로 구성되며, 한 경로가 이전 노드로 되돌아가는 그래프입니다. 따라서 수학적·구조적으로 보면 **루프도 그래프의 한 형태**입니다. 그래프 엔지니어링은 루프와 완전히 다른 기술이라기보다, 단순한 순환 구조가 복잡해졌을 때 이를 명시적인 노드·엣지·상태로 관리하는 방법에 가깝습니다. *** ## 5\. 그래프 엔지니어링이 필요한 세 가지 상황 영상은 작업 상자가 늘어나고 흐름이 복잡해지는 대표적인 이유를 세 가지로 설명합니다. ### 5.1 실패 원인마다 대응 방법이 다른 경우 단순 루프에서는 어떤 실패가 발생하더라도 이전 단계로 돌아가 다시 작업하게 만들 수 있습니다. 하지만 실무의 실패는 원인이 서로 다릅니다. 예를 들면 다음과 같습니다. | 실패 유형 | 올바른 대응 예시 | | ----- | --------- | | **테스트 실패** | 코드를 수정하고 테스트 재실행 | | **요구사항 모호함** | 사람에게 질문하고 답변을 기다림 | | **외부 서버 장애** | 코드를 수정하지 않고 일정 시간 대기 후 재시도 | | **권한 부족** | 필요한 권한 요청 또는 작업 중단 | | **사용량 제한 초과** | 재시도 시간을 예약하거나 캐시된 결과 사용 | 외부 서버가 죽은 상황에서 코드를 다섯 번 다시 작성하게 하는 것은 의미가 없습니다. 실패 유형을 먼저 분류하고 원인에 맞는 경로로 이동해야 하므로 그래프의 분기가 늘어납니다. ### 5.2 여러 작업을 동시에 처리하는 경우 서로 독립적인 파일 다섯 개를 순서대로 수정하면 시간이 오래 걸립니다. 독립적으로 처리할 수 있다면 작업을 여러 갈래로 나누어 동시에 실행하고, 완료된 결과를 마지막에 합칠 수 있습니다. 이를 그래프 용어로 표현하면 다음과 같습니다. * **Fan-out:** 하나의 작업을 여러 병렬 작업으로 분배 * **Worker nodes:** 각 파일이나 하위 작업을 독립적으로 처리 * **Fan-in:** 병렬 작업 결과를 하나로 합침 * **Final verification:** 합쳐진 결과에 전체 테스트 실행 ### 5.3 작업 단계 사이에서 상태를 공유해야 하는 경우 노드가 많아지면 각 단계가 다음 단계로 데이터를 전달해야 합니다. 노드마다 서로 다른 형식으로 데이터를 읽고 쓴다면 전체 시스템이 복잡해집니다. 따라서 그래프에서는 다음 정보를 표준화된 상태로 관리합니다. * 현재 처리 중인 파일 * 파일별 작업 완료·실패 여부 * 오류 유형과 메시지 * 재시도 횟수 * 사람의 검토·승인 여부 * 생성된 결과물의 위치 * 다음에 실행할 노드 정리하면 **조건 분기, 병렬 처리, 상태 관리**가 늘어나면서 단순 루프가 복잡한 그래프로 발전합니다. *** ## 6\. 그래프의 모든 노드가 AI일 필요는 없다 그래프 엔지니어링이라는 이름 때문에 모든 작업을 AI 에이전트가 수행해야 한다고 오해하기 쉽습니다. 영상은 각 노드가 다음 중 어느 것이든 될 수 있다고 설명합니다. * LLM 또는 AI 에이전트 * 일반 프로그램 함수 * 셸 명령어 * 테스트 명령어 * 문자열 검색이나 정규식 * 외부 API 호출 * 일정 시간 대기 * 사람의 검토와 승인 예를 들어 테스트 통과 여부는 AI에게 자연어로 물어보기보다 `npm test` 같은 결정론적인 명령을 실행하고 종료 코드로 판정하는 것이 더 안전합니다. 그래프 엔지니어링의 목적은 AI 노드를 많이 만드는 것이 아니라, **업무에 필요한 서로 다른 절차를 가장 적합한 방식으로 연결하는 것**입니다. *** ## 7\. 단순 루프와 그래프 구조 비교 ### 단순 루프 ``` flowchart TD A["작업 수행"] --> B["테스트 실행"] B -->|통과| C["완료"] B -->|실패| A ``` 이 구조는 간단하고 이해하기 쉽지만 모든 실패를 동일하게 취급합니다. ### 실패 유형을 구분하는 그래프 ``` flowchart TD A["작업 수행"] --> B["테스트 실행"] B -->|통과| C["완료"] B -->|실패| D["실패 유형 분류"] D -->|테스트 오류| A D -->|요구사항 모호| E["사람에게 질문"] D -->|외부 장애| F["대기 후 재시도"] E --> A F --> B ``` 두 번째 구조에서는 실패 원인에 따라 다음 행동이 달라집니다. 이러한 조건 분기가 여러 겹으로 늘어나면 프롬프트나 단순 반복문만으로 관리하기 어려워집니다. *** ## 8\. 그래프를 코드로 정의하는 이유 영상은 단순한 프롬프트와 셸 반복문 대신 그래프를 코드로 정의할 때 얻는 장점을 네 가지로 정리합니다. ### 8.1 실행 전에 전체 흐름 검사 그래프를 시각화하면 다음 문제를 실행 전에 발견할 수 있습니다. * 도달할 수 없는 노드 * 끝나지 않는 반복 경로 * 어디에도 연결되지 않은 막다른 길 * 처리되지 않은 실패 유형 * 반드시 거쳐야 하는 검증 단계의 누락 ### 8.2 중단된 지점부터 재개 사람의 승인을 기다리거나 서버가 종료된 경우 현재 상태를 저장해 두었다가 같은 지점에서 작업을 이어갈 수 있습니다. ### 8.3 이전 상태로 되돌려 다른 경로 재실행 결과가 좋지 않다면 특정 체크포인트로 돌아가 다른 분기나 다른 설정으로 다시 실행할 수 있습니다. ### 8.4 특정 노드만 교체 전체 시스템을 다시 만들지 않고 특정 노드의 프롬프트·도구·AI 모델만 교체해 성능과 비용을 개선할 수 있습니다. *** ## 9\. 루프에서 그래프로 넘어가야 하는 시점 영상은 그래프 엔지니어링을 무조건 도입하라고 권하지 않습니다. 다음과 같은 상황이 생길 때 도입을 검토할 수 있습니다. * 조건문이 여러 겹으로 중첩됩니다. * 실패 원인별로 이동해야 할 단계가 다릅니다. * 여러 작업을 병렬로 실행하고 다시 합쳐야 합니다. * 사람이 승인할 때까지 멈춰야 합니다. * 중단된 작업을 며칠 뒤 이어서 실행해야 합니다. * 현재 작업이 어느 단계인지 추적하기 어렵습니다. * 여러 노드가 공유하는 데이터 형식을 통일해야 합니다. * 특정 단계만 다른 모델이나 도구로 교체하고 싶습니다. 반대로 흐름이 머릿속으로 쉽게 따라갈 수 있을 정도로 단순하다면 프롬프트와 루프만으로도 충분합니다. > **루프로 시작하고, 복잡성을 감당하기 어려워지는 순간 그래프로 전환한다.** *** ## 10\. 실습 1: 단순 루프를 코드로 표현하기 영상의 실습은 단순한 루프 구조를 코드로 표현하는 것부터 시작합니다. 기본 노드는 다음과 같습니다. 1. 작업 수행 2. 테스트 실행 3. 반복 횟수 초과 시 사람에게 이관 기본 흐름은 다음과 같습니다. 1. 코드를 수정합니다. 2. 테스트를 실행합니다. 3. 통과하면 종료합니다. 4. 실패하면 다시 수정합니다. 5. 최대 5회 실패하면 사람에게 넘깁니다. 이 구조는 노드가 적고 실패 유형이 하나이므로 단순 반복문으로도 관리할 수 있습니다. *** ## 11\. 실습 2: 실패 분류 노드 추가하기 단순 루프의 문제는 모든 실패를 하나로 묶어 처리한다는 점입니다. 이를 개선하기 위해 **Classifier 노드**를 추가합니다. Classifier는 반드시 복잡한 AI 모델일 필요가 없습니다. 오류 메시지 파일을 읽고 문자열을 검색하는 간단한 프로그램으로도 만들 수 있습니다. 예시는 다음과 같습니다. * 오류 메시지에 `test failed`가 있으면 테스트 오류 경로 * `ambiguous`가 있으면 요구사항 확인 경로 * `external`이나 연결 오류가 있으면 외부 장애 경로 분류 결과에 따른 행동은 다음과 같이 달라집니다. * 테스트 오류 → 코드 수정 노드 * 요구사항 모호 → 사람에게 질문하는 노드 * 외부 서버 장애 → 60초 대기 노드 분류 노드가 추가되면서 기존 세 개의 상자가 다섯 개 이상으로 늘어나고, 단순 루프가 조건 분기를 가진 그래프로 발전합니다. *** ## 12\. 실습 3: 여러 파일 병렬 처리하기 영상에서는 하나의 파일을 수정하던 루프를 여러 파일에 동시에 적용하는 예시를 보여줍니다. ### 동작 순서 1. 처리할 파일 목록을 확인합니다. 2. 분배 노드가 파일별 작업을 생성합니다. 3. 여러 Worker 노드가 파일을 동시에 수정합니다. 4. 모든 Worker가 끝날 때까지 기다립니다. 5. 결과를 하나로 합칩니다. 6. 프로젝트 전체 테스트를 실행합니다. 작업 대상 파일 수에 따라 Worker 노드가 동적으로 늘어날 수 있습니다. 이렇게 그래프가 펼쳐졌다가 다시 합쳐지는 과정에서는 각 작업의 완료 여부와 결과를 안정적으로 추적할 상태가 필요합니다. *** ## 13\. 상태\(State\)를 표준화해야 하는 이유 그래프에서 상태는 노드 사이를 이동하는 **공통 데이터 묶음이자 작업일지**입니다. 영상의 예시를 기준으로 상태 객체는 다음 정보를 가질 수 있습니다. ``` files: parser.ts: pending formatter.ts: failed attempt_count: 2 error_type: test_failure human_reviewed: false next_node: fix_code ``` 실제 상태 구조는 프로젝트에 따라 달라지지만 다음 원칙이 중요합니다. * 모든 노드가 같은 상태 형식을 이해해야 합니다. * 각 노드는 자신이 담당하는 필드만 명확하게 수정해야 합니다. * 실패와 재시도 이유가 상태에 기록되어야 합니다. * 다음 실행이 상태만 읽고 작업을 이어갈 수 있어야 합니다. * 상태 변경 내역을 통해 전체 실행 과정을 추적할 수 있어야 합니다. ### 상태가 작업일지가 되는 과정 각 노드는 작업을 시작할 때 현재 상태를 읽고, 작업을 마치면 결과를 상태에 기록합니다. 예를 들면 다음과 같습니다. * 파일 A: 통과 * 파일 B: 테스트 실패 * 재시도 횟수: 2회 * 첫 실패 원인: 테스트 오류 * 두 번째 실패 원인: 외부 연결 중단 * 사람 승인 여부: 대기 중 이 기록이 있으면 왜 계획보다 반복 횟수가 늘어났는지 확인할 수 있으며, 작업이 중단돼도 처음부터 다시 실행할 필요가 없습니다. *** ## 14\. LangGraph로 구현하는 기본 구조 영상은 그래프 엔지니어링을 구현하는 대표적인 도구로 LangGraph를 소개합니다. 구체적인 코드 문법보다 다음 구조를 이해하는 것이 핵심입니다. ### 1단계: 상태 구조 정의 노드들이 주고받을 데이터의 필드와 형식을 클래스나 객체로 정의합니다. ### 2단계: 노드 함수 작성 각 함수가 상태를 입력받아 작업을 수행하고 수정된 상태를 반환하게 합니다. 예시는 다음과 같습니다. * `work`: 코드나 파일 수정 * `test`: `npm test` 실행 * `classify`: 오류 유형 분류 * `wait`: 외부 서비스 복구 대기 * `human`: 사람의 답변 또는 승인 요청 * `finish`: 완료 결과 정리 ### 3단계: 노드와 엣지 연결 * `add\_node`와 같은 방식으로 함수들을 노드로 등록합니다. * `add\_edge`로 노드 사이의 이동 경로를 연결합니다. * 조건부 엣지로 테스트 결과와 오류 유형에 따라 분기합니다. ### 4단계: 종료와 재시도 조건 정의 * 최대 재시도 횟수 * 테스트 통과 여부 * 사람에게 이관할 조건 * 외부 서비스 재시도 간격 * 전체 시간과 비용 제한 ### 5단계: 그래프 컴파일 및 실행 정의한 상태 그래프를 컴파일하면 실행 가능한 그래프 애플리케이션이 됩니다. 그래프를 시각화해 노드와 엣지가 올바르게 연결됐는지 확인할 수도 있습니다. *** ## 15\. 체크포인트와 중단 후 재개 그래프 엔지니어링의 중요한 장점 중 하나는 현재 상태를 데이터베이스에 체크포인트로 저장하고 나중에 이어서 실행할 수 있다는 점입니다. ### 사람이 승인해야 하는 예시 1. AI가 작업 결과를 생성합니다. 2. Human 노드에서 실행을 중단합니다. 3. 현재 상태와 다음 실행 위치를 데이터베이스에 저장합니다. 4. 사람이 며칠 뒤 결과를 검토하고 답변합니다. 5. 저장된 상태를 불러옵니다. 6. Human 노드 다음 단계부터 실행을 재개합니다. 단순 셸 반복문은 터미널이 꺼지거나 프로세스가 종료되면 현재 위치를 잃기 쉽습니다. 반면 그래프는 상태와 실행 위치를 저장해 긴 작업과 승인 대기를 안정적으로 처리할 수 있습니다. ### 재개할 때 확인해야 할 것 * 저장된 상태의 스키마가 현재 코드와 호환되는가? * 외부 데이터가 중단 시점 이후 변경되지 않았는가? * 이미 실행한 노드를 다시 실행해도 안전한가? * 동일 작업이 중복 처리되지 않도록 설계됐는가? * 사람의 승인 결과가 올바른 실행 ID에 연결됐는가? *** ## 16\. 노드별로 다른 모델 사용하기 그래프에서는 각 노드를 독립적인 부품처럼 교체할 수 있습니다. 모든 작업에 가장 크고 비싼 AI 모델을 사용할 필요는 없습니다. | 작업 유형 | 적합한 처리 방식 | | ----- | --------- | | 문자열 검색, 테스트 통과 여부 | 일반 코드와 명령어 | | 오류 유형 단순 분류 | 규칙 기반 또는 작은 모델 | | 문서 요약과 형식 변환 | 빠르고 저렴한 모델 | | 복잡한 설계와 디버깅 | 추론 성능이 높은 모델 | | 중요한 최종 검증 | 강한 검증 모델 또는 사람 | 노드별로 적합한 모델과 도구를 선택하면 비용과 속도를 최적화할 수 있습니다. *** ## 17\. 그래프 엔지니어링의 주요 장점 ### 복잡한 흐름의 가시성 작업 절차를 그림으로 확인할 수 있어 조건 분기, 병렬 처리, 반복과 종료 경로를 이해하기 쉬워집니다. ### 실패 원인별 대응 모든 실패를 동일하게 재시도하지 않고, 오류 종류에 따라 수정·대기·질문·중단으로 나눌 수 있습니다. ### 병렬 실행 서로 독립적인 작업을 동시에 처리하고 결과를 안전하게 합칠 수 있습니다. ### 장기 작업의 지속성 체크포인트와 상태를 저장하면 프로세스 종료나 사람의 승인 대기 후에도 작업을 이어갈 수 있습니다. ### 구성요소 교체 특정 노드의 모델·프롬프트·도구만 교체해 전체 시스템을 단계적으로 개선할 수 있습니다. ### 실행 과정 추적 상태 변경 기록을 통해 어느 단계에서 실패했고, 왜 반복됐으며, 누가 승인했는지 분석할 수 있습니다. *** ## 18\. 그래프 엔지니어링 도입 시 주의할 점 영상은 그래프가 복잡해 보인다는 이유만으로 노드를 늘리지 말라고 경고합니다. ### 18.1 필요하지 않은 노드 추가 간단한 작업을 여러 노드로 잘게 나누면 토큰 비용, 코드량과 디버깅 시간이 늘어납니다. > 흐름이 단순하다면 루프만으로 처리하고, 실제 복잡성이 생겼을 때 그래프로 전환합니다. ### 18.2 모든 작업을 AI에 맡기기 결정론적인 명령으로 정확히 처리할 수 있는 작업까지 AI 노드로 만들면 환각과 비용이 증가합니다. * 테스트 실행 → `npm test` * 문자열 검색 → `grep` 또는 정규식 * 파일 존재 확인 → 일반 프로그램 로직 * JSON 형식 검증 → 스키마 검증기 AI는 의미 해석과 복잡한 판단이 필요한 단계에 선택적으로 사용해야 합니다. ### 18.3 분기만 만들고 동일한 작업 수행 오류를 여러 종류로 분류한 뒤 모든 경로가 다시 같은 작업으로 연결된다면 분류의 의미가 없습니다. 분기는 실제로 다른 대응이 필요할 때만 만듭니다. ### 18.4 종료 조건이 없는 반복 그래프 안에 무한 루프가 생기지 않도록 다음 제한을 설정해야 합니다. * 최대 재시도 횟수 * 전체 실행 시간 * 토큰과 API 비용 상한 * 동일 오류 반복 횟수 * 진전이 없을 때 중단 * 사람에게 이관할 조건 그래프를 시각화하면 종료되지 않는 순환 경로를 비교적 쉽게 발견할 수 있습니다. ### 18.5 상태 스키마를 자주 바꾸기 상태를 데이터베이스에 저장한 뒤 코드의 상태 구조를 변경하면 이전 체크포인트를 불러올 때 문제가 발생할 수 있습니다. 상태 버전 관리와 마이그레이션 전략이 필요합니다. *** ## 19\. 루프와 그래프 선택 기준 | 상황 | 권장 방식 | | --- | ----- | | 한 가지 작업을 검증 결과에 따라 반복 | 단순 루프 | | 실패 유형이 하나이고 재시도 방식도 동일 | 단순 루프 | | 노드와 경로를 머릿속으로 쉽게 추적 가능 | 단순 루프 | | 실패 유형별 대응이 다름 | 그래프 | | 여러 작업을 병렬로 나누고 합쳐야 함 | 그래프 | | 사람의 승인까지 장시간 대기 | 그래프와 체크포인트 | | 중단된 실행을 특정 위치에서 재개 | 그래프와 상태 저장 | | 노드별 모델·도구 최적화 필요 | 그래프 | | 실행 경로를 시각적으로 감사해야 함 | 그래프 | *** ## 20\. 실무 적용 예시: 코드 수정 자동화 그래프 ### 목표 여러 파일의 포맷과 테스트 오류를 자동으로 수정하되, 요구사항이 모호하거나 외부 서비스에 문제가 있으면 적절한 경로로 분기합니다. ### 노드 구성 1. **Load state:** 기존 작업 상태 불러오기 2. **Distribute:** 수정할 파일을 병렬 작업으로 분배 3. **Workers:** 파일별 수정 수행 4. **Merge:** 수정 결과 합치기 5. **Test:** 전체 테스트 실행 6. **Classify:** 실패 원인 분류 7. **Fix:** 코드 오류 수정 8. **Wait:** 외부 시스템 복구 대기 9. **Human:** 요구사항 확인과 승인 요청 10. **Finish:** 결과 정리와 완료 처리 ### 종료 조건 * 테스트 전체 통과 * 최대 수정 5회 * 전체 실행 시간 제한 * 동일 오류 2회 이상 반복 시 사람에게 이관 * 외부 서비스 장애가 지정 시간을 넘으면 중단 ### 상태 예시 ``` run_id: run-2026-001 files: parser.ts: passed formatter.ts: retrying attempt_count: 2 last_error: test_failure human_approval: pending next_node: fix started_at: 2026-07-28T09:00:00Z ``` *** ## 21\. 그래프 설계 체크리스트 ### 구조 * 각 노드의 역할이 하나의 명확한 작업으로 정의되어 있는가? * 노드 사이에 전달되는 상태의 형식이 표준화되어 있는가? * 모든 조건 분기에 실제로 서로 다른 대응이 연결되어 있는가? * 도달할 수 없는 노드나 막다른 경로가 없는가? * 병렬 실행 후 결과를 합치는 지점이 명확한가? ### AI 사용 * 일반 코드나 명령어로 처리할 수 있는 작업을 불필요하게 AI에게 맡기지 않았는가? * 의미 판단이 필요한 노드에만 AI를 사용했는가? * 작업 난이도에 맞게 노드별 모델을 선택했는가? * AI 출력은 스키마 또는 결정론적 검증기로 확인하는가? ### 안정성 * 각 루프에 최대 반복 횟수가 있는가? * 시간·토큰·API 비용 상한이 있는가? * 외부 시스템 장애와 속도 제한을 처리하는가? * 사람에게 넘겨야 할 조건이 정의되어 있는가? * 같은 작업을 재실행해도 중복 부작용이 발생하지 않는가? ### 상태와 재개 * 현재 노드와 다음 노드가 상태에 기록되는가? * 작업 결과와 실패 원인이 기록되는가? * 체크포인트가 영구 저장되는가? * 중단 후 재개 과정을 실제로 테스트했는가? * 상태 스키마 변경에 대비한 버전 관리가 있는가? *** ## 22\. 광고 구간 요약 영상의 07:41\~08:40 구간은 Hostinger VPS 협찬 내용입니다. 영상에서는 장시간 또는 24시간 실행되는 AI 비서와 자동화 작업을 운영하려면 개인 컴퓨터를 계속 켜두기보다 VPS 같은 서버를 사용할 수 있다고 설명합니다. Hostinger의 VPS 상품, 할인 코드와 무료 도메인 혜택을 소개한 뒤 실습으로 돌아갑니다. 이 내용은 그래프 엔지니어링의 필수 구성요소가 아니라 영상 제작을 지원한 서비스 소개입니다. 그래프는 로컬 컴퓨터, 사내 서버, 클라우드와 다른 VPS에서도 구현할 수 있습니다. *** ## 23\. 타임라인별 상세 목차 | 시간 | 내용 | | --- | --- | | **00:00** | 그래프 엔지니어링 용어가 등장한 배경 | | **01:08** | 그래프 엔지니어링 5분 핵심 요약 시작 | | **01:39** | 루프도 그래프의 일종이라는 설명 | | **02:12** | 노드가 많아질 때 그래프가 필요한 이유 | | **02:47** | 실패 원인별 조건 분기 | | **03:19** | 여러 작업의 병렬 실행과 결과 병합 | | **03:36** | 노드 사이의 표준화된 상태 관리 | | **04:20** | 모든 노드가 AI일 필요는 없다는 설명 | | **04:42** | 실행 전에 그래프를 코드로 정의하는 이유 | | **05:04** | 사전 검사·재개·되돌리기·노드 교체의 장점 | | **05:32** | 루프에서 그래프로 넘어가야 하는 시점 | | **05:52** | LangGraph와 기존 그래프 기반 에이전트 기술 | | **06:51** | 이론 부분 핵심 정리 | | **07:41** | Hostinger VPS 협찬 구간 | | **08:40** | 그래프 엔지니어링 실습 시작 | | **09:08** | 단순 루프를 코드 구조로 표현 | | **09:43** | 실패 분류 노드와 조건별 처리 추가 | | **10:33** | 여러 파일을 동시에 처리하는 병렬 그래프 | | **11:16** | 중간 결과와 실패 기록을 상태로 관리 | | **12:50** | LangGraph 상태·노드·엣지 구현 개념 | | **13:55** | 그래프 시각화와 실행 흐름 확인 | | **14:46** | 체크포인트를 이용한 중단 후 재개 | | **16:14** | 노드별로 다른 AI 모델 사용하기 | | **16:39** | 그래프 설계 시 주의할 점 | | **17:45** | 최종 정리 | *** ## 24\. 최종 정리 영상에서 말하는 그래프 엔지니어링은 루프 엔지니어링을 대체하는 완전히 새로운 기술이 아닙니다. **단순 루프가 여러 조건 분기, 병렬 작업, 사람의 승인과 장기 상태를 포함하면서 복잡해졌을 때 전체 흐름을 명시적으로 관리하는 방법**입니다. 핵심 내용을 다섯 문장으로 압축하면 다음과 같습니다. 1. **루프도 그래프의 한 종류이며 두 개념 사이에 절대적인 경계는 없습니다.** 2. **실패 유형별 분기, 병렬 처리와 상태 관리가 많아지면 그래프가 필요합니다.** 3. **노드는 AI뿐 아니라 일반 함수, 테스트 명령어, 외부 API와 사람도 될 수 있습니다.** 4. **표준화된 상태와 체크포인트가 있어야 중단된 장기 작업을 안정적으로 이어갈 수 있습니다.** 5. **흐름이 단순하면 루프를 유지하고, 사람이 구조를 추적하기 어려워질 때 LangGraph 같은 그래프 도구를 도입합니다.** 결국 그래프 엔지니어링의 가치는 새로운 용어 자체보다 **복잡한 AI 작업을 눈으로 검토하고, 코드로 통제하고, 중단 후 복구하며, 각 단계에 가장 적합한 도구를 배치할 수 있다는 점**에 있습니다. *** ## 참고 자료 및 작성 기준 * 원본 영상: [https://www.youtube.com/watch?v=BtM2JZCMtL8](https://www.youtube.com/watch?v=BtM2JZCMtL8) * ZeroCho 강좌: [https://www.zerocho.com/lecture](https://www.zerocho.com/lecture) * ZeroCho GitHub: [https://github.com/zerocho](https://github.com/zerocho) * 영상 설명란과 전체 한국어 자동 자막을 기준으로 정리했습니다. * 자막의 명백한 오인식은 영상 문맥에 맞게 교정했습니다. * 영상 속 광고는 기술 요약과 분리해 표시했습니다. * 일부 코드와 상태 예시는 영상의 개념을 이해하기 쉽게 재구성한 것으로, 실제 구현 시 사용하는 LangGraph 버전과 환경에 맞게 조정해야 합니다.

콘텐츠를 불러오는 중..