출처 https://youtu.be/dR81q1bJVSA · 채널 Bloom AI · 길이 06:23 · 공개 2026-08-01 17:00 (KST) 포맷 내레이션 + 슬라이드 해설 영상. 화면은 크게 두 종류다 — 정보가 담긴 자체 제작 슬라이드·다이어그램(00:06, 00:23, 00:26, 00:57, 03:25, 03:43, 04:28, 04:47)과 나머지 구간을 채우는 스톡 B롤(송금하는 손, 코드 화면, 체스 두는 노인 등). 이 노트의 장면은 정보가 있는 슬라이드만 골랐다. 원본 자막(자동 생성):
raw/transcripts/2026-08-01-bloom-ai-graph-harness-engineering.ko-orig.srt표기 주의 yt-dlp가 받아온
ko-orig는 한국어 음성인식 자동자막이라 오타가 섞인다(LRM·LM은 모두 LLM,머즈 워드는 버즈워드,채봇은 챗봇,랭체인 재단은 랭체인(LangChain)). 다행히 이 영상은 채널이 만든 한국어 자막이 화면에 새겨져 있어, 아래 「원문 인용 모음」의 모든 문장은 해당 시점의 프레임을 뽑아 화면 자막을 한 줄씩 직접 읽어 옮겼다. 대조 결과 두 군데가 자동자막과 달랐다 — [04:14] 화면 자막에는 자동자막에 없는(그래프 엔지니어링이)라는 설명 괄호가 들어 있고, 화면 자막 스스로도 [04:19]하니스/ [04:41]하네스로 표기가 흔들린다(이 노트 본문은 하네스로 통일). 03:25 슬라이드와 내레이션이 어긋나는 부분(내레이션 “자연어 문의” vs 슬라이드 “사용자 이메일 분석”)은 슬라이드 표기를 따랐다 — 03:43 그래프의 노드 이름이 슬라이드 쪽이기 때문이다. 00:26에 인용된 랭체인 글의 영어 원문은 3 Years of Graph Engineering with LangGraph(Sydney Runkle·Harrison Chase, 2026-07-22)에서 대조해 확인했고, 04:28 다이어그램의 출처 URL도 화면 하단을 확대해 자릿수까지 대조했다. 관련: 2026-07-25-harness-loop-graph-engineering · 2026-07-19-loop-engineering-to-graph-engineering · loop-engineering · moc-ai-agents-harness
한눈에 보는 요약
- 용어 인플레가 진짜 주제다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링 → 루프 엔지니어링, 그리고 이제 그래프 엔지니어링. 영상은 “이것도 갑자기 사라질 유행어 아닌가?”라는 의심에서 출발한다.
- 랭체인 스스로 버즈워드라고 인정한다. 다만 같은 글에서 이유도 댄다 — LLM은 견고하지도 결정론적이지도 않은 새로운 종류의 소프트웨어라서, 안정적으로 굴리려는 새 전략이 계속 나오고 그때마다 새 용어가 붙는다는 것.
- 모든 것의 출발점은 결정론적 처리와 확률론적 처리의 구분이다. 같은 입력·상태·규칙이면 항상 같은 결과가 나와야 하는 일(송금 100만 원은 몇 번을 돌려도 100만 원)과, 표현이 달라도 의도를 알아들어야 하는 일(“환불” 키워드가 없는 “돈이 아직 안 들어왔어요”)은 성격이 다르다.
- AI 에이전트를 만든다는 건 모든 업무를 AI에 맡기는 게 아니다. 전체 업무를 먼저 분해하고, 어떤 업무는 LLM에 맡기고 어떤 업무는 코드로 제한할지 정하는 것이 첫 단계다.
- 그다음 각 업무를 노드(함수)로 만들고 흐름을 설계한다. 입력이 들어오면 LLM이 분석하고, 그 결과에 따라 검색 노드로 갈지 답변 생성 노드로 바로 갈지 갈린다. 이 구성과 통제가 그래프 엔지니어링이다.
- 그래서 하네스 엔지니어링과 결국 같은 이야기다. 하네스는 LLM 주변에 시스템 프롬프트·메모리·권한·검증·로그 같은 환경을 설계하는 일이고, 그래프는 그 환경 안에서 흐름을 짜는 일이다. 영상의 결론은 “완전히 다른 새 개념이 아니라, 각 단계에 적절한 컨텍스트와 모델의 추론을 적절한 위치에 배치한다는 동일한 큰 아이디어”.
- 다만 영상이 근거로 띄운 인포그래픽은 정반대를 말한다 — “DIFFERENT LAYERS. THREE DIFFERENT JOBS. DON’T CONFUSE THEM.” 같은 화면 안에서 주장과 자료가 엇갈린다(아래 8번 장면 참고).
- 실무로 옮기면 질문이 바뀐다. 좋은 모델·좋은 프롬프트를 고르는 문제가 아니라 “LLM에게 무엇을 판단하게 하고 무엇을 판단하지 못하게 할 것인가”, 그리고 상태 공유·실행 순서·실패 시 복귀 지점·사람 승인 시점을 어떻게 설계할 것인가의 문제다.
장면별 상세 설명
[00:06] 1. 6개월 사이에 쌓인 용어들
영상은 최근 쏟아진 아티클 네 개를 한 화면에 깔면서 시작한다. 왼쪽 위는 뒤에서 다시 크게 나오는 “AGENT HARNESS ENGINEERING vs. LOOP ENGINEERING vs. GRAPH ENGINEERING” 비교 인포그래픽, 오른쪽 위는 “Microsoft, Stanford and Anthropic Discovered Graph Engineering — Why they moved beyond RAG, and why it works”, 왼쪽 아래는 “Kimi K3 + Graph Engineering”(RAG는 텍스트를 검색하지만 그래프 엔지니어링은 지식을 검색한다는 주장), 오른쪽 아래는 랭체인의 “3 Years of Graph Engineering with LangGraph”.
내레이션이 짚는 흐름은 이렇다. 프롬프트 엔지니어링이 나왔고, 다음은 컨텍스트 엔지니어링, 하네스 엔지니어링, 루프 엔지니어링이 나오더니, 이제는 그래프 엔지니어링까지 나왔다.
[00:23] 2. 그래서 드는 의심
영상이 시청자 대신 물어주는 질문이 화면을 채운다. “이것도 갑자기 사라질 새로운 유행어 아닌가?” 이 영상의 전체 구조는 이 질문에 답하는 형태다 — 절반은 “맞다, 버즈워드다”, 나머지 절반은 “그런데 버즈워드가 계속 나오는 데는 이유가 있다”.
[00:26] 3. 랭체인의 대답 — 버즈워드가 맞다, 그런데
화면에 인용된 문단은 랭체인의 「3 Years of Graph Engineering with LangGraph」의 한 대목이다.
At the end of the day, the goal is to harness the power of LLMs to do useful things for us. Whether you use prompting or agents or loops or graphs, those are implementation details. The reason so many terms exist that getting LLMs to do work is hard. They are a new type of non-robust, non-deterministic software and we’re constantly trying new strategies to get them to work. And these new strategies lead to new buzzwords. (결국 목표는 LLM의 힘을 붙들어 우리에게 쓸모 있는 일을 시키는 것이다. 프롬프팅이든 에이전트든 루프든 그래프든 그건 구현 세부사항이다. 용어가 이렇게 많은 이유는 LLM에게 일을 시키는 것이 어렵기 때문이다. LLM은 견고하지도 결정론적이지도 않은 새로운 종류의 소프트웨어이고, 우리는 그것을 작동시키려고 끊임없이 새 전략을 시도한다. 그리고 그 새 전략들이 새 버즈워드를 낳는다.)
핵심은 마지막 두 문장이다. 용어가 계속 갈리는 건 유행 때문이 아니라 문제가 아직 안 풀렸기 때문이다. buzzwords에만 형광펜이 쳐져 있지만, 진짜 무게는 non-robust, non-deterministic에 있다.
[00:57] 4. 모든 논의의 출발점 — 결정론적 vs 확률론적
결정론적 처리는 동일한 입력·동일한 상태·동일한 규칙이 주어지면 항상 같은 결과가 나오는 처리다. 은행 앱에서 100만 원을 송금하면, 그 금액을 계산하고 검증하는 코드는 몇 번을 실행하든 100만 원을 처리해야 한다. 어떨 때는 100만 원, 어떨 때는 101만 원이어서는 안 된다.
이런 일을 LLM에 맡기면 안 되는 이유가 바로 여기 있다. “사용자가 100만 원을 보내 달라고 했지만 상황을 보니 101만 원이 좋겠다”고 모델이 자의적으로 판단해 송금해 버리면 그건 사고다. 그래서 권한, 송금, 데이터 저장, 파일 삭제처럼 정확성과 안전성이 걸린 작업은 코드로 결정론적으로 처리해야 한다.
반대로 LLM 기반 처리는 확률론적이다. 같은 프롬프트를 넣어도 글자 하나까지 같은 결과가 나온다는 보장이 없다. 대신 얻는 게 있다. 규칙 기반 챗봇은 “환불”이라는 키워드가 문장에 있어야 작동했고, “돈이 아직 안 들어왔어요. 결제 취소해 주세요” 처럼 표현이 달라지면 같은 요구인데도 못 알아들었다. LLM은 문맥을 분석해 이게 환불 문의라는 것을 추론한다. 예측은 어렵지만 변형된 입력과 비정형 자연어를 유연하게 받아낸다.
정리하면 의도 분석, 요약 생성, 검색어 생성처럼 정답을 하나로 못 박기 어려운 작업이 LLM의 자리다.
[03:25] 5. 두 처리 방식을 합치는 첫 단계 — 업무 분해
AI 에이전트를 만든다는 것은 모든 업무를 AI에게 맡긴다는 뜻이 아니다. 먼저 에이전트가 수행할 전체 업무를 분석한 뒤, 어떤 업무를 LLM에 맡기고 어떤 업무를 코드로 제한할지 정해야 한다. 슬라이드는 고객 문의 이메일 처리 에이전트를 예로 네 줄로 배정을 보여준다.
| 업무 | 처리 방식 |
|---|---|
| 사용자 이메일 분석 | LLM 기반 |
| 관련 문서 검색 | 코드 기반 |
| 답변 생성 | LLM 기반 |
| 개인정보 포함 여부 분석 | 코드 기반 |
배정 기준이 각각 다르다는 점이 중요하다. 이메일 분석과 답변 생성은 정답이 하나가 아니어서 LLM에 맡기고, 개인정보 검출은 정규 표현식으로 확정적으로 잡아낼 수 있어서 코드에 맡긴다.
[03:43] 6. 노드로 만들고 흐름을 설계한다 — 이게 그래프 엔지니어링
앞서 나눈 각 업무를 하나의 노드, 즉 함수로 만들고 작업의 흐름을 잇는다. 다이어그램의 범례는 두 가지다 — 속이 빈 파란 테두리 원은 확률론적(LLM) 노드, 파랗게 채워진 원은 결정론적(코드) 노드. 회색 원(입력, 전송)은 그래프의 진입점과 종료점이다.
| 간선 | 종류 | 도착 노드의 처리 방식 |
|---|---|---|
| 입력 → 이메일 분석 | 실선 | 확률론적 (LLM) |
| 이메일 분석 → 관련 문서 검색 | 점선(조건 분기) | 결정론적 (코드) |
| 이메일 분석 → 답변 생성 | 점선(검색 건너뛰기) | 확률론적 (LLM) |
| 관련 문서 검색 → 개인정보 포함 여부 분석 | 실선 | 결정론적 (정규 표현식) |
| 개인정보 포함 여부 분석 → 답변 생성 | 실선 | 확률론적 (LLM) |
| 답변 생성 → 응답 품질 검수 | 실선 | 확률론적 (LLM) |
| 응답 품질 검수 → 전송 | 실선 | 종료점 |
점선이 그래프 엔지니어링의 핵심이다. 최초 입력이 들어오면 LLM이 내용을 분석하고, 그 분석 결과에 따라 때로는 검색 노드로, 때로는 답변 생성 노드로 바로 보낸다. 흐름을 고정하지 않고 모델의 판단으로 갈래를 정하되, 갈래 자체는 엔지니어가 미리 그려둔 것이다.
슬라이드(5번 장면)에는 없었지만 그래프에는 응답 품질 검수 노드가 하나 더 붙어 있다. 답변을 만든 뒤 전송하기 전에 한 번 더 확률론적으로 거르는 단계다.
이런 식으로 각 업무를 LLM 노드로 처리할지 코드 기반 결정론적 방법으로 처리할지 구성한 뒤 그 흐름을 통제하는 방식으로 에이전트를 개발하는 것 — 이게 바로 그래프 엔지니어링이다.
[04:28] 7. 그럼 이건 하네스 엔지니어링 아닌가
여기까지 들으면 자연스럽게 드는 의문이다. 결국 LLM 주변에 코드와 도구를 배치해 안정적으로 동작하게 만드는 것이면, 그것도 결국 하네스 엔지니어링 아닌가? 영상의 답은 “맞다”이다.
화면의 다이어그램(출처: x.com/akshay_pachaar)은 하네스를 세 겹의 동심원으로 그린다. 가운데에 LLM(stateless model)이 있고, 그 바로 바깥이 Runtime — 오케스트레이션 루프, 출력 파싱, 프롬프트 구성, 에러 처리. 그다음 링이 Capabilities — 도구, 메모리, 상태 관리, 컨텍스트 관리. 가장 바깥이 Safety & Scale — 가드레일, 검증 루프, 서브에이전트 오케스트레이션, 툴 스코핑, 사전 컴파일 루프. 사용자 요청은 바깥에서 들어오고, 툴 호출은 바깥으로 나가고, 루프는 계속 돈다. 그림 오른쪽 말풍선이 요점을 못 박는다 — “The harness is multi-layered, not a single wrapper.”(하네스는 여러 겹이지 단일 래퍼가 아니다.)
내레이션의 정의도 같은 방향이다. 하네스 엔지니어링은 LLM이 실제 업무를 수행할 수 있도록 모델 주변의 환경을 설계하는 일이고, 그 환경에는 시스템 프롬프트, 메모리, 코드 기반의 권한·검증·로그가 모두 들어간다.
[04:47] 8. 세 용어의 관계 — 그리고 화면과 주장이 엇갈리는 지점
1번 장면에 작게 깔렸던 인포그래픽이 전체 화면으로 돌아온다. 세 용어를 각각 한 줄로 정의한다.
| 용어 | 하는 일 | 구성 요소 |
|---|---|---|
| Agent Harness Engineering | BUILDS THE ENVIRONMENT (환경을 만든다) | Tools, Memory, Permissions, APIs, Filesystem, Runtime |
| Loop Engineering | IMPROVES THE WORK (작업을 개선한다) | Think → Act → Check → Feedback → Repeat |
| Graph Engineering | CONTROLS THE WORKFLOW (워크플로를 통제한다) | Nodes, Branches, Joins, Parallel, State |
그리고 하단에 세 단계의 관계가 화살표로 놓인다 — ENVIRONMENT → FEEDBACK → FLOW.
내레이션의 결론은 통합 쪽이다. 그래프 엔지니어링은 하네스 엔지니어링이나 루프 엔지니어링과 완전히 다른 새로운 개념이 아니라, 각 단계에서 적절한 컨텍스트와 모델의 추론을 적절한 위치에 배치한다는 동일한 큰 아이디어라는 것.
그런데 화면에 띄운 인포그래픽은 정반대를 말한다. 오른쪽 아래 박스는 “DON’T CONFUSE THEM. BUILD BETTER AGENTS.”, 왼쪽 아래 박스는 “[DIFFE]RENT LAYERS. THREE DIFFERENT JOBS.” 즉 이 그림의 저자는 셋을 혼동하지 말라고 경고하는 쪽이다. 같은 화면 안에서 주장과 근거 자료가 어긋난다.
둘 다 틀린 말은 아니다. 랭체인의 글도 “루프 엔지니어링·하네스 엔지니어링과 같은 아이디어”라고 쓰니 내레이션의 편이고, 2026-07-25-harness-loop-graph-engineering는 “세대교체가 아니라 층위가 다른 개념”이라며 인포그래픽의 편이다. 정확히 말하면 문제의식은 하나이고 층위는 셋이다 — 셋 다 확률론적 LLM을 결정론적 코드로 감싸려는 시도지만, 감싸는 지점이 환경(하네스)이냐 반복(루프)이냐 흐름(그래프)이냐가 다르다.
부록 — 에이전트를 설계할 때 실제로 답해야 하는 질문들
영상 마지막(05:29~06:02)이 사실상 체크리스트다.
- 업무를 먼저 쪼갰는가. 에이전트가 할 일을 통째로 LLM에 던지지 말고 단위 업무로 분해한다.
- 각 업무를 어느 쪽에 배정할 것인가. 자연어 해석·추론처럼 유연성이 필요한 영역은 LLM, 권한·검증·결제·저장·실행처럼 정확성과 안전성이 필요한 영역은 코드.
- 두 영역이 어떤 상태를 공유하는가.
- 어떤 순서로 실행되는가.
- 실패했을 때 어디로 돌아가는가.
- 언제 사람에게 승인을 받는가.
- 그리고 이 모든 것을 관통하는 질문 — LLM에게 무엇을 판단하게 하고, 무엇을 판단하지 못하게 할 것인가.
3~6번을 그래프로 그려내는 것이 그래프 엔지니어링이고, 좋은 모델을 고르거나 좋은 프롬프트를 쓰는 것보다 이 구조 설계가 앞으로 더 중요한 업무가 될 것이라는 게 영상의 마무리다.
원문 인용 모음
화면에 새겨진 채널 한국어 자막을 프레임 단위로 읽어 옮겼다(띄어쓰기도 화면 표기 그대로).
- [00:02] “최근 AI 업계에서 그래프 엔지니어링이라는 표현이 갑자기 화두가 되고 있습니다.”
- [00:21] “이것도 갑자기 사라질 새로운 유행어 아닌가? 🤔” — 자막이 아니라 전체 화면 텍스트 카드.
- [00:34] ”…우리가 계속해서 LLM을 안정적으로 작동시키기 위해 새로운 방법을 찾고 있다는 겁니다.”
- [01:22] “어떨 때는 100만원을 송금하고, 어떨 때는 101만원을 처리해선 안되죠.”
- [01:45] “따라서 권한, 송금, 데이터 저장, 파일 삭제와 같이 정확성과 안전성이 중요한 작업에는 코드 기반으로 결정론적으로 처리해야 합니다.”
- [02:25] “돈이 아직 안 들어왔어요. 결제 취소해주세요.” … “문장의 표현은 다르지만 환불이라는 키워드가 없다는 이유로 제대로 동작하지 않았습니다.”
- [03:04] “AI 에이전트를 만든다는 것은 모든 업무를 AI에게 맡긴다는 게 아닙니다.”
- [04:02] “그 흐름을 통제하는 방식으로 에이전트를 개발해야 된다. 이게 바로 그래프 엔지니어링입니다.”
- [04:11] “결국 (그래프 엔지니어링이) LLM 주변에 코드와 도구를 배치해 안정적으로 동작하는 것이라면 이것도 결국 하니스 엔지니어링 아닌가?” — 괄호와
하니스표기 모두 화면 자막 그대로. 자동자막에는 괄호가 없다. - [04:40] “따라서 그래프 엔지니어링은 하네스 엔지니어링이나 루프 엔지니어링과 완전히 다른 새로운 개념이 아니라 각 단계에서 적절한 컨텍스트와 모델의 추론을 적절한 위치에 배치한다는 동일한 큰 아이디어라고 설명할 수 있죠.”
- [05:29] ”…어떤 순서로 실행되며 실패했을 때 어디로 돌아가고 언제 사람에게 승인을 받을지 그래프로 설계하자는 것이 그래프 엔지니어링입니다.”
- [05:50] “LLM에게 무엇을 판단하게 하고 무엇을 판단하지 못하게 할 것인가, 그리고 LLM이 일하는 업무 절차와 환경을 어떻게 설계할 것인가, 그 구조를 설계하는 것이 가장 중요한 업무가 될 것이죠.”