AI 애플리케이션은 단순히 더 많은 에이전트를 추가한다고 해서 신뢰할 수 있게 되는 것이 아닙니다. 각 단계가 명확한 책임, 출력 기준(exit criteria), 그리고 정의된 실패 경로를 가질 때 비로소 신뢰할 수 있게 됩니다.

Khairallah AL-Awady가 X에 게시한 “How to Become a Graph Architect With Zero Experience” 기사는 이 아이디어를 20단계의 로드맵으로 정리합니다. 핵심 제안은 훌륭합니다. 에이전트 네트워크를 설계하기 전에, 단순한 루프(loop)를 숙달하고 그것이 실제로 작동했는지 검증하는 방법을 알아야 한다는 것입니다.

다이어그램이 아닌 루프부터 시작하세요

에이전트-실행자(agent-executor) 루프는 네 가지 부분, 즉 하나의 행동(action), 결과(result), 검증(verification), 그리고 반복 조건(repetition condition)으로 축소될 수 있습니다. 이는 기초적인 것처럼 보이지만, 바로 이 지점에서 많은 시스템이 실패합니다. 객관적인 품질 기준이 없다면, 에이전트는 단지 완료된 것처럼 보이는 출력물만을 생성할 뿐입니다.

검증기(verifier)는 특별한 주의를 기울여야 합니다. 예를 들어 추출 작업에서 검증기는 필수 필드와 형식의 일관성을 확인할 수 있습니다. 코드의 경우 테스트를 실행할 수 있습니다. 게시물의 경우 전송 전에 인간의 검토를 요구할 수 있습니다. 검증이 약하면 루프를 반복하는 것은 단지 오류를 배가시킬 뿐입니다.

문제가 그래프가 될 때 무엇이 변하는가

단일 루프가 잘 해결할 수 있는 문제들이 있습니다. 반면 분기(branching), 병렬 작업, 체크포인트(control points), 그리고 특정 복구 경로가 필요한 문제들도 있습니다. 이 시점에서 그래프(graph)로 생각하는 것이 도움이 됩니다. 노드(nodes)는 작업을 수행하고, 에지(edges)는 다음 단계를 결정하며, 상태(state)는 단계 간에 필요한 정보를 전달합니다.

모든 노드가 언어 모델(LLM)일 필요는 없습니다. 이것은 실무적인 구분입니다. 결정론적 검증(deterministic validation), API 호출, 또는 권한 규칙은 일반적으로 일반적인 코드여야 합니다. 해석, 생성, 그리고 진정으로 언어에 의존하는 결정에만 LLM을 예약하면 비용, 지연 시간(latency), 그리고 가변성을 줄일 수 있습니다.

반복되는 문제를 해결하는 패턴들

반복되는 문제를 해결하는 패턴들

• Roteador: 입력으로부터 적절한 흐름 또는 전문가를 선택합니다.
• Orquestrador 및 워커(workers): 작업을 하위 작업으로 나누고 결과를 취합합니다.
• Fan-out 및 fan-in: 독립적인 부분을 병렬로 실행하고 응답을 통합합니다.
• Gerador 및 평가자(avaliador): 출력을 패턴과 비교하여 검토하고 구체적인 피드백을 반환합니다.
• 인간 게이트(Portão humano): 게시, 지출 또는 삭제와 같은 되돌릴 수 없는 행동 이전에 프로세스를 중단시킵니다.

이러한 패턴들은 복잡한 아키텍처를 만들도록 유도하는 것이 아닙니다. 책임의 분리나 흐름에 대한 명시적인 제어가 필요할 때 사용할 선택지입니다.

신뢰성은 후처리 세부 사항이 아니다

데모에서 작동했던 그래프가 지속적인 사용을 위해 준비되었다는 의미는 아닙니다. 이는 검증 게이트(validation gates), 예측 가능한 오류에 대한 복구(recovery from predictable failures), 재개를 위한 상태 영속성(state persistence), 그리고 각 실행에서 무슨 일이 일어났는지 설명하기 위한 추적 가능성(traceability)이 필요합니다.

시스템을 실행하기 전에, 도구가 응답하지 않을 때, 결과가 검증에 실패할 때, 또는 인간의 승인이 필요할 때 어떤 일이 발생하는지 정의하는 것이 중요합니다. '다시 시도'는 유효한 경로일 수 있지만, 유일해서는 안 됩니다.

가장 성숙한 결정: 그래프를 사용하지 않는 것

이 가이드에서 가장 유용한 지점은 동시에 가장 눈에 띄지 않는 부분입니다. 많은 작업들이 그래프가 필요하지 않습니다. 단일 연산, 단일 검증기, 그리고 단계 간 의존성이 적다면, 간단한 스크립트나 루프가 유지보수와 디버깅이 더 쉬울 것입니다.

에이전트 시스템을 설계한다는 것은 문제를 안전하게 해결할 수 있는 가장 작은 구조를 선택하는 것을 의미합니다. 그래프는 복잡성이 확보되었을 때 도입되는 것이지, 다이어그램이 보기 좋다고 해서 도입되는 것이 아닙니다.

실습 계획

1. 실제 작업을 위한 루프 (loop)를 구축하고 엄격한 검증기 (verifier)를 만드세요.
2. 동일한 작업을 노드 (nodes), 에지 (edges), 상태 (state)로 설계하세요.
3. 어떤 노드가 LLM을 필요로 하고, 어떤 노드가 결정론적 (deterministic)이어야 하는지 표시하세요.
4. 한 번에 하나의 패턴씩 구현하세요: 라우팅 (routing), 병렬성 (parallelism), 또는 평가 (evaluation).
5. 아키텍처를 확장하기 전에 로그 (logs), 체크포인트 (checkpoints), 그리고 실패 경로 (failure route)를 추가하세요.
6. 결과를 단순한 버전과 비교하고, 그래프가 측정 가능한 이득을 가져올 때만 유지하세요.

"그래프 아키텍트 (graph architect)"라는 명칭은 유행에 따라 변할 수 있습니다. 하지만 핵심 역량은 변하지 않습니다: 불확실한 프로세스를 관찰 가능하고, 검증 가능하며, 지속 가능한 시퀀스로 변환하는 것입니다.

출처 및 영감: Khairallah AL-Awady, “How to Become a Graph Architect With Zero Experience (Full Course)”, 2026년 7월 31일 X에 게시됨. 이 텍스트는 원본 스크립트를 독립적으로 요약한 것입니다.