그래프 엔지니어링, AI 에이전트가 단독 작업을 멈추는 지점

때로는 데모는 작동하지만 실제 출시는 그렇지 않습니다. 한 가지 작업의 에이전트는 신뢰할 수 있지만, 동일한 코드베이스에 대해 여러 에이전트를 실행하면 결과가 어긋나기 시작합니다. 이웃 에이전트가 방금 배포한 것을 다시 구축하거나, 동일한 파일에 충돌하는 변경 사항을 만들고, 한 시간 전에 다른 에이전트가 배제한 접근 방식을 취하기도 합니다. 그 격차는 조정(coordination)입니다. 즉, 할당, 의존성, 리뷰 워크플로입니다.

프롬프트 엔지니어링이 모델에 제공하는 단어에 관한 것이었다면, 루프 엔지니어링은 한 에이전트가 작업을 완료하기 위해 실행하는 주기에 관한 것이었습니다. 그래프 엔지니어링은 얼마나 많은 에이전트가 시스템으로 작동하는지에 관한 것입니다. 어떤 에이전트가 존재하는지, 각 에이전트가 무엇을 소유하는지, 작업이 어떻게 분할되는지, 결과가 어디서 다시 합쳐지는지, 그리고 여전히 사람이 최종 승인하는 지점은 어디인지에 관한 것입니다.

조정은 설계되어야 합니다

기능을 여러 에이전트로 분할하면 명시해야 할 일련의 의존성이 생성됩니다. 에이전트는 전달받은 내용에 따라 행동하므로 구조에 기록되지 않은 내용은 에이전트에게 보이지 않습니다.

소유권에 따라 서비스를 분할한다고 가정해 보겠습니다. 보안 에이전트는 인증, 권한 및 감사 로깅을 소유하고, 데이터 에이전트는 스키마와 마이그레이션을 소유하며, API 에이전트는 엔드포인트와 그 계약을 소유합니다. 각각은 독자적으로 유능하지만, API 에이전트는 데이터 에이전트의 마이그레이션이 완료될 때까지 엔드포인트를 확정할 수 없습니다. 보안 에이전트는 배포 전 권한과 관련된 모든 변경 사항을 검토해야 합니다. 데이터 에이전트가 필드 이름을 바꾸면, API 에이전트는 이전 필드를 기준으로 빌드하기 전에 이를 알아야 합니다. 이러한 인계, 의존성 및 리뷰 게이트가 실제 시스템입니다. 이는 단일 에이전트의 루프 내부에 존재하지 않으며 저절로 나타나지도 않습니다. 이를 설계하는 것은 귀하의 몫입니다.

각 에이전트가 볼 수 있는 것이 결과를 결정합니다

설정을 그래프로 상상해 보세요. 각 에이전트는 노드(node)입니다. 즉, 작업의 한 부분을 수행하는 단위입니다. 에이전트 간의 연결은 엣지(edge)입니다. 즉, 인계, 의존성, 무엇이 무엇보다 먼저 일어나야 하는지를 알려주는 리뷰 단계입니다.

그래프 자체는 화이트보드에 들어갈 정도로 간단합니다. 여기에는 전문가들에게 작업을 보내는 플래너, 병렬로 실행되는 전문가들, 결과를 확인하는 검증자, 그리고 항상 판단 사항을 승인하는 사람이 포함됩니다.