AI 시스템 설계 4단계 프레임워크: 제품 요구사항부터 평가·비용 최적화까지

핵심 메시지

• '그냥 만들어서 출시하라'는 바이브 코딩은 재미용 프로토타입엔 좋지만, 실제 사람이 의존하는 시스템에는 위험하다. 이제 어려운 부분은 코드가 아니라 명세(스펙)다.
• AI 시스템 설계는 제품 요구사항 → 시스템 설계 → 평가·모니터링 → 비용·지연·신뢰성 최적화의 4단계 프레임워크로 접근한다.
• 비즈니스 문제는 사용자가 누구인지, 현재 상태와 고통을 수치로, 그리고 '에이전트로 만들겠다'처럼 해법을 미리 규정하지 않는 방식으로 정의해야 한다.
• 가장 흔한 실수는 무엇이 실패하는지 알기도 전에 시스템을 과잉 설계하는 것이다. 가장 단순한 설계로 시작해 평가하고 반복하라.
• 측정할 수 없으면 개선할 수 없다. 가드레일·응답 품질·도메인 지표·시스템 헬스를 처음부터 평가에 내장해야 한다.

쉽게 이해하기

MongoDB의 데이터 과학자 출신 개발자 애드보킷 아푸르바 조시는, AI 시대에도 '무엇을 만들지'를 깊이 고민해야 한다고 강조한다. 바이브 코딩은 위험이 낮고 결과를 눈으로 확인할 수 있는 재미용 작업에는 잘 통하지만, 다른 사람이 의존하고 실제 결과가 따르는 시스템에서는 '일단 출시'가 위험하다는 것이다. 그는 앤트로픽과 OpenAI 같은 AI 코딩 옹호 진영조차 '스펙이 새로운 코드'이며 제품 요구사항·시스템 설계·평가 기준을 잘 정의하는 것이 핵심이라고 말한다는 점을 든다.

그가 제시하는 프레임워크는 네 단계다. 첫째 제품 요구사항(무엇을, 누구를 위해, 어떤 제약 아래 만드는가), 둘째 시스템 설계(데이터·아키텍처·패턴), 셋째 평가와 모니터링(출시 전후로 실제 동작 검증), 넷째 정확도뿐 아니라 비용·지연·신뢰성 최적화다. 추상적인 설명 대신 그는 건강보험 청구 심사 시스템이라는 실제 사례에 이 단계들을 적용해 각 결정이 다음 단계로 어떻게 이어지는지 보여준다.

제품 요구사항 단계에서는 비즈니스 문제를 정량화한다. 예시로 'MDB 헬스의 의료 심사자가 청구 검토에 평균 2일을 쓰는데 이는 업계 표준의 4~12배이고, 이 지연이 시간에 민감한 치료를 미룬다'처럼 사용자 특정적이고 측정 가능하며 해법에 얽매이지 않게 쓴다. 이어 규제 준수, 데이터 반출 제약, 승인된 벤더·모델 제약, 인간 검토가 필수인 경우, 성능·비용·가동률 요구사항을 먼저 파악한다. AI의 역할(핵심인지 보완인지, 반응형인지 능동형인지, 자율성 수준)도 정의하고, SMART한 성공 지표(예: 90일 내 긴급 청구 처리 시간을 2일에서 1시간으로 단축)를 한두 개 세운다.

시스템 설계 단계에서는 데이터 전략부터 본다. 임상 가이드라인·보장 정책·환자 청구 이력 같은 데이터가 어디에 어떤 형식으로 있고 얼마나 자주 갱신되는지(연·분기·시간 단위), 어떤 검색 기법이 맞는지(벡터 검색, 메타데이터 사전 필터링, 하이브리드 검색, 정확 일치)를 따진다. 곧바로 에이전트로 점프하기보다 청구가 시스템을 흐르는 경로를 그려 아키텍처를 정한다. RAG, AI 에이전트·멀티에이전트, 제어 흐름, LLM 라우터, 휴먼 인 더 루프, 파인튜닝 같은 패턴 중 이 사례엔 RAG + 제어 흐름 + 휴먼 인 더 루프가 맞는다고 본다. 사용자 경험과 피드백 수집(인용 제공, 평결 오버라이드, 잘못된 인용 플래그)까지 설계에 포함한다.

마지막으로 평가·모니터링과 최적화다. 확률적인 LLM 시스템을 위해 입력·출력 가드레일(예: 인용 없는 응답은 무효)을 정의하고, 청구 거부율·인용 누락률·충실성·청구 처리 시간·추천당 비용 같은 지표를 만든다. 출시 후에는 사람이 AI 평결을 뒤집는 빈도나 검토 시간 같은 암묵적 지표로 회귀를 모니터링한다. 정확도가 좋아 보여도 비용·지연·신뢰성은 프로덕션에서 협상 불가이므로, 프롬프트 엔지니어링·리랭킹·메모리·시맨틱 캐싱·배치 처리·구조화 출력 등으로 추가 반복을 거친 뒤 출시한다.

주요 인사이트

• 스펙이 새로운 코드다: AI가 코드를 대신 써주는 시대에 사람이 책임질 어려운 일은 제품 요구사항·시스템 설계·평가 기준을 명확히 정의하는 일로 옮겨갔다.
• 비즈니스 문제는 해법을 규정하지 말고 정의하라. '에이전트로 만들자'가 아니라 사용자·현재 상태·고통을 수치로 적고, 아키텍처 결정은 그 뒤에 따라오게 한다.
• 단순하게 시작해 반복하라. 과잉 설계는 가장 흔한 실수이며, 무엇이 실패하는지 평가로 확인한 뒤 필요한 만큼만 복잡성을 더한다.
• 데이터 갱신 주기를 무시하면 시스템이 낡은 정보로 동작한다. 파이프라인을 데이터 변화 속도에 맞춰 돌려야 한다.
• 정확도만으로는 프로덕션에 못 간다. 비용·지연·신뢰성이라는 비협상 제약을 만족할 때까지 최적화 반복이 필요하다.

자주 묻는 질문

관련 AI 소식