AI 에이전시가 구축 단계에 돌입하기 전 자동화 및 RAG 프로젝트의 범위를 설정하는 방법

AI 자동화, RAG (Retrieval-Augmented Generation) 시스템, 그리고 에이전트 워크플로우 (agent workflows)를 구축하는 에이전시들은 대개 첫 번째 데모가 어려웠다는 이유로 마진을 잃지는 않습니다.

그들은 더 이른 단계에서 마진을 잃습니다:

• 고객의 목표는 실질적이지만, 첫 번째 마일스톤 (milestone)이 너무 광범위할 때;
• 소스 자료 (source material)가 검색 (retrieval)에 적합한 상태가 아닐 때;
• 승인 게이트 (approval gate)를 명시하기 전에 팀이 "워크플로우 자동화"에 동의해 버릴 때;
• 견적 단계에서는 깨끗한 입력을 가정했다가, 킥오프 (kickoff) 이후에 지저분한 엣지 케이스 (edge cases)를 발견할 때;
• 구현 팀이 단순하다고 판매된 범위를 물려받을 때.

비싼 비용이 발생하는 지점이 항상 구현 (implementation)인 것은 아닙니다. 때로는 누군가 구축을 시작하기 전에 프로젝트의 범위를 좁혔어야 했다는 사실을 너무 늦게 깨닫는 것이 원인이 됩니다.

유용한 구축 전 검토 (pre-build review)

AI 자동화 또는 RAG 구축을 시작하기 전에, 나는 범위를 네 가지 서면 질문으로 줄이는 것을 선호합니다.

1. 첫 번째 유료 마일스톤은 무엇인가?

제품 전체가 아닙니다. 전체 시스템도 아닙니다. 첫 번째 유료 마일스톤입니다.

좋은 마일스톤은 다음과 같은 요건을 갖춥니다:

• 하나의 워크플로우 (workflow) 또는 지식 영역;
• 명확한 입력 (input);
• 명확한 출력 (output);
• 인간의 승인 지점 (human approval point);
• 나중에 자동화가 지연되더라도 가치가 있는 이유.

만약 팀이 해당 마일스톤을 평이한 언어로 설명할 수 없다면, 구현 과정에서 아마도 그 모호함이 비용으로 흡수될 것입니다.

2. 무엇이 인간의 승인을 유지해야 하는가?

AI 프로젝트는 종종 팀이 자동화해야 할 것들만 나열하기 때문에 실패합니다.

범위 설정 (scoping)을 위해서는 다음과 같은 질문이 더 유용합니다:

아직 자동화해서는 안 되는 것은 무엇인가?

예시:

• 최종 고객 답변;
• 재무 승인;
• 정책 예외 사항;
• 코드 병합 (code merges);
• 규제 대상 결정;
• 잘못된 답변이 고객 지원, 법률, 보안 또는 평판 문제를 일으킬 수 있는 모든 것.

이것은 자동화에 반대하는 것이 아닙니다. 이것은 워크플로우가 출시 가능한 상태 (shippable)가 되는 방법입니다.

3. 소스(sources)가 준비되었는가?

RAG 프로젝트의 경우, 취약한 소스 준비 상태는 나중에 모델의 문제로 나타납니다.

구축하기 전에, 소스 세트가 다음을 갖추고 있는지 확인하십시오:

• 안정적인 소유자 (stable owners);
• 예상 질문에 대한 충분한 커버리지 (coverage);
• 오래되었거나 충돌하는 문서의 제거 또는 라벨링 (labeled);
• 거절되어야 하는 질문의 예시;
• 소규모 평가 세트 (evaluation set);
• 출시 후 소스를 업데이트하기 위한 프로세스.

만약 문서가 준비되지 않았다면, 올바른 첫 번째 마일스톤 (milestone)은 검색 (retrieval)이 아니라 소스 정리 (source cleanup)가 될 수 있습니다.

4. 어떤 실패 모드 (failure modes)가 견적을 변화시키는가?

어떤 실패 모드는 허용 가능합니다. 하지만 어떤 모드는 인도 계획 (delivery plan)을 변경합니다.

범위 (scope)에 영향을 미쳐야 하는 예시는 다음과 같습니다:

• 워크플로우 (workflow)에 비공개 자격 증명 (private credentials) 또는 운영 환경 접근 권한 (production access)이 필요한 경우;
• 클라이언트가 비식별 처리된 예시 (redacted examples)를 제공할 수 없는 경우;
• 검색 (retrieval)이 충돌하는 소스들 사이에서 작동해야 하는 경우;
• 출력이 인간의 검토 (human review) 없이 사용되는 경우;
• 시스템이 취약한 내부 도구 (brittle internal tools)와 통합되어야 하는 경우;
• 성공 여부가 팀이 실제로 제어할 수 없는 데이터에 달려 있는 경우.

이것들은 모든 프로젝트를 거절해야 하는 이유는 아닙니다. 가격을 책정하거나, 순서를 정하거나, 혹은 범위를 다르게 좁혀야 하는 이유입니다.

간단한 비동기 검토 형식 (async review format)

에이전시의 경우, 유용한 두 번째 검토 단계는 작게 유지될 수 있습니다:

• 범위 요약 (scope summary);
• 첫 번째 마일스톤 권장 사항;
• 준비 상태의 격차 (readiness gaps);
• 실패 모드 (failure modes);
• 승인 게이트 (approval gates);
• 진행 / 축소 / 연기 권장 사항.

회의, 운영 환경 접근 권한, 또는 클라이언트 자격 증명이 필요하지 않습니다. 비식별 처리된 브리프 (redacted brief)만으로도 팀이 구축 시간을 투입하기 전에 큰 실수를 잡아내기에 충분한 경우가 많습니다.

저는 정확히 이 사용 사례를 위해 페이지를 하나 만들었습니다:

https://mindtrovertlabs-sketch.github.io/scopegrade-storefront/agency-partner-review.html

또한 여기에서 체크리스트 스타일의 무료 미리보기를 확인할 수 있습니다:

https://mindtrovertlabs-sketch.github.io/scopegrade-storefront/preview.html

핵심 요점: AI 에이전시는 범위 설정 (scoping) 단계에서 더 많은 열정을 필요로 하지 않습니다. 그들에게 필요한 것은 무엇에 먼저 자금을 지원하는 것이 안전한지 결정할 수 있는 문서화된 방법입니다.