루프 엔지니어링 정리했더니, 다음은 그래프 엔지니어링이네요

지난번에 루프 엔지니어링 자료를 올리고 나서 한 가지가 계속 걸렸습니다.

에이전트가 둘, 셋으로 늘어나도 계속 루프 엔지니어링만 적용하면 될까요?

찾아보니 여기서부터 이야기가 그래프 엔지니어링으로 넘어가더군요. 한 에이전트를 반복시키는 대신 여러 에이전트가 같은 상태를 보고, 각자 맡은 일을 동시에 처리하고, 상황에 따라 다음 경로를 바꾸는 방식입니다.

예를 들어 코드 오류와 서버 장애는 대응이 달라야 합니다. 하나는 코드를 고쳐야 하고 다른 하나는 잠시 기다렸다가 다시 시도해야 하니까요. 요구사항이 애매하면 추측해서 진행하는 대신 사람에게 질문하는 경로도 필요합니다.

작업을 여러 에이전트에 나누면 또 다른 문제가 생깁니다. 중간 결과와 공통 작업 일지를 어디에 남길지, 실패한 지점부터 어떻게 이어갈지, 어느 단계에서 사람 승인(Human-in-the-Loop)을 기다릴지를 미리 정해야 합니다.

이번 자료에는 이런 분기와 상태 공유를 21장으로 정리했습니다. 루프 엔지니어링과 그래프 엔지니어링의 차이, 전환을 고민할 기준 3가지, LangGraph와 n8n·Flowise로 구현하는 방법, 그래프 엔지니어링이 오히려 과잉 설계가 되는 경우까지 담았습니다.

https://www.onlydecks.app/r/aMuu0yw

저는 조건 분기, 이중 검수, 병렬 처리 중 하나라도 복잡해지면 그래프 엔지니어링을 검토할 시점이라고 봤습니다.

에이전트를 둘 이상 쓰는 분들은 중간 상태를 어떤 방식으로 넘기고 계신가요?