AI 에이전트 구축에 관한 조언

고마워. 나는 에이전트들이 공유 데이터베이스와 내장된 결정론적 노드를 사용하게 하고 있어. 각 에이전트는 다음 에이전트로 넘기기 전에 반드시 구조화된 데이터베이스를 업데이트해야 해. 그래야 프롬프트에서 나오는 확률적 출력값이 아니라 동일한 구조화된 데이터를 기반으로 작업할 수 있거든. 지금 가장 큰 문제는 이메일에서 잠재 고객의 답장을 모니터링하고 그 고객의 브리핑을 업데이트하는 에이전트야. 특정 시점이 되면 서비스 범위 설정과 가격 책정을 CLO에게 넘겨야 하는데…

에이전트 로직이 고장 나는 경우는 드묾. 진짜 문제는 모호한 핸드오프임. 영업 인테이크 경로의 경우, 각 단계에서 무엇이 남는지(리드 필드, 상태, 다음 작업)에 대한 작은 스키마를 정의해서 DB에 저장하고, 다음 에이전트가 그 필드만 읽게 하셈. 채팅 기록을 통째로 넘기면서 상태가 재구성되길 바라지 말고. 함대에 역할을 더 추가하기 전에 지루하더라도 하나의 경로를 확실하게 만드는 것부터 시작하셈.

답변 감사합니다. 제가 정확히 하려던 방식이 바로 그겁니다. 하나의 에이전트를 사용해 다양한 소스(이메일, 웹사이트 채팅 등)에서 데이터를 추출하고, 다른 모든 에이전트가 신뢰할 수 있는 소스로 사용할 수 있도록 결정론적이고 구조화된 데이터베이스에 채워 넣는 것이죠. 제가 겪고 있는 어려움은 이메일을 모니터링하는 에이전트가 이메일 응답의 비정형 데이터를 가져와 데이터베이스에 구조화하는 과정입니다. 가끔은 아주 잘 작동하는데, 때로는 잠재 고객의 내용에 따라 고전하기도 합니다...

이 아키텍처로 한번 빌드해봐: https://github.com/munch2u-a11y/Habitus-AI.git

좀 다르긴 한데. 뭐랄까, 어떤 거든 쓸 수 있는 오픈 웨이트 백엔드 같은 느낌임.

나도 같은 길을 걸었네. Claude chat에서 Claude Code로 넘어갔지. 근데 성과를 낸 건 도구가 아니라 에이전트가 한 말을 무조건 믿지 않기로 한 거였어. 에이전트가 뭘 했다고 주장하면 같은 턴에서 반드시 명령어 출력 결과를 확인해야 해. 안 그러면 안 한 거나 다름없거든. "배포 및 검증 완료"라고 해놓고 실제론 안 된 적이 많아서 크게 데였거든. 게다가 서브 에이전트들한테는 좁은 범위의 툴 화이트리스트만 줘서, 코드 짜는 놈이 프로덕션 서버를 재시작하지 못하게 막았지. Cloud agents 쓸 때 raw 명령어는 어떻게 확인해?

나는 Cursor에서 코드 에이전트들이 뭘 하는지 추적하고 있고 브랜치 보호 설정을 해둬서, PR을 병합할 때 내 승인이 필요해. 코드는 반드시 CI 테스트를 통과해야 하고 Cursor의 bugbot과 security bot이 검토하게 되어 있어.

에이전트를 통해 비즈니스를 운영하는 것에 진심이라면 www.vectorstep.io를 확인해보셈. 실제 프로덕션급 에이전트 사용을 위해 만들어졌고, 9월 말에 완전히 오픈 소스로 전환됨.

VectorStep도 살펴봤습니다.

우리의 사용 사례(규제된 법률 운영, 고객 대면 워크플로우)에서는 플랫폼으로 채택하지 않을 생각입니다. 우리는 폐쇄형 액션 타입을 가진 도메인별 서비스를 운영하며, 고객 대면 작업에는 명시적인 사람의 승인을 거치고, 자동 전송 금지 같은 엄격한 규칙을 적용합니다. 신뢰도 점수가 부작용을 유발하는 중앙 집중식 오케스트레이터 방식이 아닙니다.

여러분의 스택이 그들과 비슷하다면 확인해 볼 가치는 있겠지만, 우리 시스템에 바로 도입하기는 어렵습니다.