설계 대상이 계속 올라왔습니다
AI를 다루는 기술은 무엇을 설계하느냐가 한 칸씩 올라오며 바뀌어 왔습니다. 말을 고르던 단계에서 시작해, 지금은 여러 AI가 어떤 구조 안에서 함께 움직일지를 설계하는 자리까지 왔습니다.
각 단계는 이 과정 안에도 있습니다 — 프롬프트는 1-1, 컨텍스트는 1-2, 루프는 1-3과 B-12, 그리고 그래프가 이 페이지입니다.
일을 쪼개고, 이동 규칙을 정한다
그래프 엔지니어링은 하나의 AI에게 모든 일을 맡기는 대신, 작업을 여러 개의 노드로 나누고 그 사이의 이동 규칙을 설계하는 방식입니다. 필요한 개념은 네 개뿐입니다.
위 그림 한 장이 전부입니다. 조사 노드가 일을 하고, 결과를 스테이트에 담아 넘기고, 컨디션이 조건을 보고 갈 길을 정하고, 미달이면 엣지를 따라 되돌아갑니다.
조직도를 그리는 일에 가깝습니다
유능한 직원 한 명에게 모든 업무를 맡기면 결과는 나오지만, 안에서 무슨 일이 있었는지 알 수 없습니다. 단일 에이전트가 블랙박스가 되는 이유입니다.
그래프를 설계하는 것은 회사 전체의 조직도를 그리는 것과 같습니다 — 누가 조사를 하고, 누가 검증하며, 어떤 상황에서 일을 다시 시키고, 어디서 대표가 승인할지를 미리 정해 두는 일입니다. AI가 실수하지 않고 일하게 만드는 것은 더 좋은 지시문이 아니라 이 구조입니다.
애매한 판단은 AI, 명확한 규칙은 코드
이 페이지에서 하나만 가져간다면 이것입니다. 모든 노드가 AI일 필요는 없습니다.
검색어를 만들고 문서를 요약하는 일은 매번 답이 달라도 됩니다 — AI 자리입니다. 반대로 "경쟁사가 10개 이상인가", "출처가 3개 이상 포함됐는가"는 언제 물어도 답이 하나여야 합니다 — 코드 자리입니다.
가장 많이 쓰는 배선
구조를 처음부터 새로 짜지 않아도 됩니다. 실무에서 반복해서 나오는 모양이 있습니다.
라우터는 입력 종류가 여러 가지일 때, 병렬은 서로 독립인 조사를 동시에 돌릴 때, 생성자 · 평가자는 품질 기준이 분명한 산출물일 때, 사람 승인은 되돌리기 어려운 결정 앞에 놓습니다.
그래프로 옮겨보면
"한국에서 AI 자동화 SaaS를 만들고 싶다"는 기획 요청을 그래프로 설계하면 이렇게 됩니다.
읽는 순서는 이렇습니다.
요청을 분석한다
무엇을 조사해야 하는지 갈래를 나눕니다
조사를 병렬로 돌린다
경쟁사 · 고객 · 시장 조사를 각각의 노드로 나눠 동시에 실행합니다
노드마다 책임을 숫자로 준다
"최소 10개의 경쟁사", "최소 20개의 실제 의견" — 애매한 표현을 남기지 않습니다
결과를 모아 검증 노드로 넘긴다
각 노드가 남긴 스테이트를 합쳐 조건을 확인합니다
미달이면 그 노드로 돌아간다
경쟁사가 5개뿐이면 보고서를 완성하지 않고 정확히 경쟁사 조사 노드로 되돌립니다
사람에게 승인을 묻는다
"이 방향으로 진행할까요?" — 거절하면 아이디어 생성 노드로 돌아갑니다
구조부터 그려 달라고 하기
구현보다 구조를 먼저 말로 확정하는 게 빠릅니다. 이렇게 부탁합니다.
우리 팀의 "신규 서비스 기획" 업무를 그래프로 설계해줘. 1. 노드를 나누고 각 노드의 책임을 숫자로 적어줘 2. 노드 사이 이동 조건을 "코드로 셀 수 있는 것"으로만 써줘 3. 어디를 병렬로 돌릴지, 어디서 사람 승인을 받을지 표시해줘 4. 조건 미달일 때 어느 노드로 돌아가는지 명시해줘 AI가 맡을 노드와 코드가 처리할 조건을 구분해서 정리해줘.
언제 이걸 꺼내나
모든 작업에 그래프를 씌우면 안 됩니다. 간단한 요약이나 질문 답변에 그래프를 도입하면 구조만 복잡해지고 비용이 낭비됩니다 — 전형적인 오버엔지니어링입니다.
아래가 여러 개 겹칠 때 값을 합니다. 하나뿐이면 대개 루프로 충분합니다.
- 단계마다 조건에 따라 갈라져야 한다
- 서로 독립인 일을 동시에 돌리는 이득이 있다
- 실패했을 때 특정 지점으로 되돌아가 다시 해야 한다
- 중간에 사람이 결정해야 하는 자리가 있다
- 결과를 엄격한 기준으로 검증해야 한다
왜 이 방향으로 가는가
AI의 능력이 빠르게 올라오면서, AI에게 좋은 답을 유도하는 시대는 지나가고 있습니다. 대신 AI가 좋은 방식으로 일하게 만드는 구조적 설계의 시대로 넘어가고 있습니다.
앞으로는 개별 모델의 성능보다 — 어떤 작업을 나누고, 어디서 병렬로 돌리고 검증하며, 어디서 사람에게 결정권을 넘길지 — 이 전체 구조를 얼마나 잘 설계하느냐가 시스템의 품질을 결정하게 됩니다.
- 프롬프트 · 컨텍스트 · 루프 · 그래프의 설계 대상 차이를 말할 수 있다
- 노드 · 엣지 · 스테이트 · 컨디션을 내 업무에 대입해봤다
- AI에게 맡길 것과 코드로 처리할 조건을 갈라봤다
- 패턴 네 가지 중 내 업무에 맞는 것을 골랐다
- 그래프가 과잉인 경우를 판단할 수 있다