여덟 레이어, 한 코어 위에서.

단일 모델이 생성과 검증을 겸하면 self-bias가 발생합니다. Curea는 생성 단계와 판정 단계를 분리하고, 판정 특성이 다른 모델 패밀리를 의도적으로 섞어 blind spot을 줄입니다.

빠르고 많이 vs. 느려도 정확. 한 모델이 이 스펙트럼 전체에서 최적일 수 없습니다. AWS Step Functions 기반 상태 기반 워크플로가 단계 전이를 제어하고, 단계마다 맞는 모델이나 프로바이더를 호출합니다.

ABC 베이스 + @lru_cache 싱글톤 위에 실시간 호출은 LangChain, Batch API는 공식 SDK, 이미지·TTS·임베딩이 동일 인터페이스로 다뤄집니다. 어떤 벤더가 어느 단계를 맡고 있는지는 운영 팀이 분기마다 재평가. 모델은 고정 자산이 아니라 교체 가능한 실행 슬롯입니다.

api → application → domain → infrastructure 단방향 의존. 도메인이 인프라를 import 하는 것은 정방향, 그 반대는 금지. 7개 도메인 (generation · batch · qc · embedding · media · shared · model_eval) 이 각각 Controller · UseCase · Service · Provider/Repository 패턴으로 분리되어, 모델·DB·외부 SaaS 교체가 도메인 코드에 영향 없이 가능합니다.

형식 준수, 지문-선지 정합성, 명백한 논리/사실 결함. Stamp 1은 통과·탈락과 무관하게 모든 문항에 적용되는 레이어. 저지연 · 저비용 · 구조화 출력에 강한 모델군이 1차 필터를 맡습니다.

오답지 품질, 난이도 측정, 최종 일관성 · 교육적 적절성. Cross-Vendor 원칙 + 작업 적합성(critique · 비교 · 난이도 판단) + Failure-mode 상보성(생성 라인의 구조화 강점 + 검증 라인의 정성 판단 강점)이 세 가지 이유.

두 AI 도장을 통과한 문제만 교사에게 도달. 교사의 선택은 승인 또는 재생성. 거절 → 새 파이프라인 실행으로 재주입되어 원본은 기록된 채 새 버전이 다시 세 도장을 거칩니다. 교사의 교육적 판단 권한을 아키텍처 레벨에서 보장합니다.

세 도장 중 하나라도 받지 못한 문제는 다음 단계로 넘어가지 못합니다. soft warning이 아니라 hard gate. domain/qc가 BusinessException + ErrorCode 패턴 (QC_EVALUATION_NOT_FOUND 등) 으로 실패를 명시적으로 분류해 다음 라인으로 흐르지 않게 막습니다.

교사의 도장과 재생성 판단은 domain/model_eval로 흘러 신규 모델 자동 적합성 평가 + 인간 피드백의 입력이 됩니다. AI · HUMAN · RLHF × 5차원 매트릭스로 모델 교체 시점을 결정합니다. (Wave 1 · model-eval workstream)

On-Demand 생성이 아닌 배치 사전 생성이 기본. 사용자 요청마다 새로 만드는 구조와 달리, 한번 검증한 재고를 반복 활용하도록 설계되어 운영 부하가 예측 가능합니다.

동일한 Batch Provider 인터페이스로 여러 벤더의 배치 채널을 하나의 추상화로 묶어, 처리량과 안정성이 더 좋은 채널이 등장하면 호출 라우팅을 이동시킵니다.

Keyword Selector → Batch Builder → Batch Poller → QC Pipeline → Main Inventory. Retry Queue가 실패 문항을 실패 사유와 함께 다시 생산 라인으로 돌리고, 모든 생성·검증·교사 도장 이벤트는flywheel_events 테이블에 표준 스키마로 적재되어 데이터 플라이휠 (data-flywheel workstream · shipped)의 입력이 됩니다.

재고 miss 시 실시간 경로로 투명 전환. 교사 입장에서는 두 경로의 차이를 체감할 수 없고, 세 도장 기준은 같습니다.