오픈소스 Shopify 지원 에이전트 storekeeper 개발기와 그래프 기반 승인 경계 설계 검토 요청

커뮤니티 반응은 전반적으로 설계의 안전성 우선순위에 공감하는 분위기였으며, 많은 사용자가 LLM과 결정론적 코드의 명확한 역할 분리를 지지했다. 일부는 인간 승인 병목과 작업 흐름의 실용성에 대한 우려를 표했고, LangGraph 대신 다른 프레임워크를 쓴 경험을 공유해 비교 관점을 제공했다. 대체로 실전 연동과 오픈소스 레포 제공이 토론을 구체화하는 데 기여했다는 평가가 다수였다.

• 분류기의 출력 스키마를 가능한 한 좁게 제한하고 실패 케이스를 명시적으로 처리하는 테스트 케이스를 마련하라. 모델이 반환할 수 있는 모든 변형을 예시로 포함한 단위 테스트를 작성해 분류 오류가 매핑 단계로 이어지지 않도록 검증해야 한다. 또한 분류 오류가 발생했을 때 사람이 빠르게 식별하고 재분류할 수 있는 로그와 UI를 준비해야 운영 안정성이 확보된다.
• 승인 워크플로에는 감사 로그와 재현 가능한 체크포인트를 의무화하라. 각 승인 항목은 SQLite 같은 영속 저장소에 체크포인트와 메타데이터를 기록하고, 재시작 시 동일 인터럽트 ID로 정확히 복원되도록 구현해야 장애 복구가 가능하다. 승인 거부·수정 이력과 실행 전후 상태 스냅샷을 남겨 추후 문제 발생 시 책임 소재를 추적할 수 있어야 한다.
• RAG로 근거를 가져오는 경우 근거 문서의 신뢰도와 인용 바이어스를 코드에서 평가하는 절차를 두어야 한다. Chroma에서 유사도 상위 결과를 가져온 뒤 코드 레이어에서 출처와 타임스탬프, 정책 적용 가능 여부를 확인해 인용 여부를 결정하면 모델의 발언이 검증된 사실에 기반함이 보장된다. 인용 불일치나 오래된 문서는 자동으로 제외하는 룰을 병행해 잘못된 근거 사용을 방지해야 한다.

RAG

— 외부 문서나 데이터베이스에서 관련 정보를 검색해 LLM의 응답 컨텍스트로 주입하는 방식이며, 검색 결과를 임베딩·유사도 기반으로 선택하고 응답 생성 전에 인용문이나 근거를 함께 결합해 사실성 보강을 목적으로 사용된다.

Structured Output

— 모델이 자유문 대신 JSON 같은 엄격한 스키마로 의도·필드·작업 목록을 반환하도록 유도하는 방식으로, 후속 비즈니스 로직이 예측 가능한 입력을 받아 안전하게 결정적 행동을 수행하게 하는 데 중요하다.

Checkpointing

— 시스템 상태(예: 승인 대기 항목, 인터럽트 ID)를 영속 스토리지에 저장해 프로세스 재시작 시 이어서 처리할 수 있게 하는 메커니즘으로, 오류 복구와 승인 보존을 위해 사용된다.

Vector DB

— 임베딩을 벡터로 저장하고 유사도 검색을 수행하는 저장소로, RAG 워크플로에서 관련 문서를 빠르게 찾아 모델 입력으로 결합하는 역할을 수행한다.