기계 판독 가능한 제약 조건(machine-readable constraints), 아키텍처 그래프(architecture graphs), 결정론적 검증(deterministic validation), 그리고 추적 가능한 아키텍처 트레이드오프(traceable architectural trade-offs)를 사용한 보험 증권 배서(endorsement) 사례 연구.

올바르게 보이는 설계

**배서 (endorsement)**는 작은 보험 정책 변경으로 시작될 수 있지만, 보험 계약의 전체적인 무게를 담고 있습니다. 상업용 재산 보험 가입자는 더 높은 건물 보상 한도, 수정된 자기부담금(deductible), 추가 위치, 또는 다른 효력 발생일을 요청할 수 있습니다. 이 요청은 자동 처리(straight-through processing) 대상이 될 수도 있고, 위험 노출(exposure)을 변경하거나, 제품 규칙을 초과하거나, 위임된 권한을 벗어나기 때문에 언더라이팅(underwriting) 참조가 필요할 수도 있습니다. 오늘 요청되었으나 다음 달부터 효력이 발생하는 더 높은 건물 한도에 대해, 보험사는 승인이 필요한지 결정하고, 수정된 위험 노출에 대한 보험료를 계산하며, 요청된 날짜까지 현재 보험을 유지하고, 배서가 효력을 발휘할 때 새로운 보험 버전을 생성해야 합니다. 이전 버전들은 나중에 청구(claim), 감사(audit), 규제 조사(regulatory inquiry), 또는 보험료 분쟁이 특정 날짜에 적용된 보상 범위에 따라 결정될 수 있으므로 반드시 재구성 가능하도록 유지되어야 합니다.

제안된 마이크로서비스(microservices) 설계는 타당해 보입니다. 클라이언트가 API 게이트웨이(API gateway)를 통해 요청을 제출하면, 배서 서비스(Endorsement Service)가 언더라이팅(Underwriting), 요율 산정(Rating), 그리고 보험(Policy) 서비스와 협력합니다. 배서 결정이 완료되면, 빌링(Billing)이 보험료 조정을 적용하고, 문서(Documents) 서비스가 수정된 보험 양식을 생성하며, 알림(Notifications) 서비스가 결과를 보험 가입자에게 전달합니다.

이 설계는 그럴듯합니다. 검토 과정에서는 이 설계의 핵심 결정 사항들이 명시적(explicit)이고, 강제 가능(enforceable)하며, 추적 가능한지(traceable)를 묻습니다.

관련된 통제 수단(controls)은 이미 워크플로 정의(workflow definitions), API 계약(API contracts), 스키마(schemas), 상태 모델(state models) 또는 아키텍처 결정 기록(architecture decision records)에 존재할 수 있습니다. 문제는 서비스 분해(service decomposition) 자체가 본질적으로 잘못되었다는 것이 아니라, 사용 가능한 산출물(artifacts)이 코딩이 시작되기 전에 검증할 수 있을 만큼 그 보장 사항(guarantees)을 명확하게 만드는지 여부입니다. Underwriting은 승인 결정을, Rating은 보험료 계산을, Policy는 권위 있는 유효 보험(in-force policy) 버전을, 그리고 Endorsement Service는 프로세스를 담당할 수 있습니다. 이러한 경계는 설계 단계에서 어떤 컴포넌트가 Endorsement를 '요청됨(requested)'에서 '승인됨(approved)'으로, 그리고 '승인됨(approved)'에서 '효력 발생(effective)' 상태로 진행시킬 수 있는지를 확립할 때만 신뢰할 수 있습니다. 단순히 Underwriting Service를 호출하는 것만으로는, 동일한 Endorsement 버전에 대한 영구적인 승인이 존재할 때까지 활성화(activation)가 방지된다는 것을 입증하지 못합니다.

버전 정렬(Version alignment) 또한 동일한 정밀도를 요구합니다. 유효한 Underwriting 결정이나 Rating 결과는 요청의 이전 리비전(revision)에 속해 있을 수 있습니다. 활성화(activation) 전에는 승인된 담보(coverage), 수락된 보험료(premium), 요청된 효력 발생일(effective date), 그리고 보험(policy) 버전이 모두 동일한 Endorsement 버전을 참조해야 합니다. 그렇지 않으면 각각 독립적으로는 올바른 결과들이 결합되어 잘못된 비즈니스 결과로 이어질 수 있습니다. 완료 경계(completion boundary) 또한 의도적으로 설정되어야 하는데, 이는 보험 활성화(policy activation), 청구(billing), 문서 생성(document generation), 그리고 알림(notification)이 반드시 동일한 일관성 요구 사항(consistency requirement)을 공유하는 것은 아니기 때문입니다. 문서 시스템의 장애(outage)가 다른 면에서 유효한 보험 변경 사항을 무효화해서는 안 되며, 재시도(retry)가 보험 버전, 보험료 조정, 문서 또는 고객 통신을 중복 생성해서도 안 됩니다. 따라서 아키텍처는 권위 있는 Endorsement 경로와 독립적으로 완료될 수 있는 다운스트림(downstream) 작업(work)을 반드시 구분해야 합니다.

효력 발생일(Effective dates)은 일반적인 워크플로우 상태를 넘어서는 시간적 차원을 도입합니다. 미래 날짜로 지정된 배서(Endorsement)는 현재 보험 계약이 요청된 날짜까지 유효한 상태에서 오늘 승인될 수 있습니다. 허용된 소급 배서(Retroactive endorsement)는 이후의 트랜잭션이 이미 기록된 후에 적용 가능한 보장 기간을 변경할 수도 있습니다. 플랫폼은 비즈니스 도메인에서 보장이 적용되는 시점과 시스템에 변경 사항이 알려진 시점 모두를 보존해야 합니다. 이러한 구분이 없다면, 보험 계약 재구성(Policy reconstruction), 보험료 정산(Premium reconciliation), 보험금 청구 평가(Claims evaluation), 그리고 다운스트림(Downstream) 동기화는 신뢰할 수 없게 됩니다.

경험 많은 아키텍트들은 항상 도메인 분석(Domain analysis), 설계 검토(Design reviews), 상태 모델링(State modelling), 결함 분석(Failure analysis), 그리고 아키텍처 거버넌스(Architectural governance)를 통해 이러한 문제들을 다루어 왔습니다. 에이전틱 AI (Agentic AI)가 그러한 판단을 대체하는 것은 아닙니다. 에이전틱 AI의 가치는 요구사항과 설계 산출물(Design artifacts)을 체계적으로 검토하고, 코딩이 시작되기 전에 누락되거나 모순된 증거를 표시하며, 통합 테스트(Integration testing)나 운영 환경의 동작(Production behaviour)을 통해 문제가 드러날 때까지 기다리는 대신 각 우려 사항을 관련 비즈니스 규칙 및 아키텍처 요소와 연결하는 데 있습니다.

이 글은 해당 프로세스를 탐구합니다. 보험 규칙은 기계가 읽을 수 있는 제약 조건(Constraints)이 되고, 제안된 설계는 아키텍처 그래프(Architecture graph)가 되며, 결정론적 검증(Deterministic validation)은 객관적인 조건을 확인하고, AI 추론(AI reasoning)은 모호성, 불완전한 증거, 숨겨진 의존성 및 트레이드오프(Tradeoffs)를 조사합니다. 인간 아키텍트는 최종 권한을 유지하며, 발견된 사항들은 확인된 위반(Confirmed violations), 아키텍처 리스크(Architectural risks), 또는 판단이 필요한 질문(Questions requiring judgment)으로 분류됩니다.

비즈니스 규칙에서 아키텍처 제약 조건으로

아키텍처 검토는 서비스 계약(Service contract), 워크플로우 구현(Workflow implementation), 또는 상태 전이(State-transition) 코드가 존재하기 전에 시작됩니다. 그 첫 번째 과제는 분산된 비즈니스 지식을 제안된 설계에 대해 기계적으로 평가할 수 있는 제약 조건으로 변환하는 것입니다.

**Constraint Compiler (제약 조건 컴파일러)**는 파이프라인의 첫 번째 에이전트 기능(agentic capability)입니다. 이 컴파일러는 관련 요구사항, 언더라이팅 가이드라인(underwriting guidelines), 제품 규칙, API 계약(API contracts), 아키텍처 결정 기록(architecture decision records), 그리고 엔지니어링 표준을 검색한 다음, 이를 후보 아키텍처 불변량(architectural invariants)으로 분해합니다. 에이전트는 서로 다른 표현들을 공통 스키마(common schema)로 정규화하고, 출처 추적성(source traceability)과 신뢰도를 보존하며, 누락된 조건이나 상충하는 해석을 식별합니다. 또한 모호한 사항에 대해서는 임의로 규칙을 만들어내는 대신 아키텍트나 보험 도메인 전문가에게 전달(route)합니다.

배서(endorsement) 사례의 경우, 지배적인 규칙은 명확합니다: 언더라이팅 검토가 필요한 보장 변경 배서는 동일한 배서 버전에 대해 영구적인 승인 결정이 존재할 때까지 효력이 발생해서는 안 됩니다. 에이전트는 해당 규칙을 적용 가능 조건(applicability condition), 금지된 전이(prohibited transition), 증거 술어(evidence predicate), 버전 상관관계 요구사항(version-correlation requirement), 그리고 심각도 분류(severity classification)로 변환합니다.

{
  "constraintId": "END-APPROVAL-001",
  "source": {
...

결정론적 스키마 검증기(deterministic schema validator)는 생성된 제약 조건이 완전하고 구조적으로 유효한지 확인합니다. 다음 단계에서는 집계(aggregate), 전이(transition), 그리고 증거 식별자(evidence identifiers)가 아키텍처 그래프의 해당 노드 및 관계와 연결됩니다. 이를 통해 검증 엔진은 워크플로우 코드가 작성되기 전에, 제안된 설계가 동일한 배서 버전에 대한 영구적인 승인 없이 배서가 효력을 발생하도록 허용하는지 여부를 판단할 수 있습니다.

이 시점에서 AI는 아키텍처에 결함이 있다고 선언한 것이 아닙니다. AI는 검토에 필요한 **요구사항 측면의 증거(requirement-side evidence)**를 생성한 것입니다. 결함 탐지는 해당 증거가 제안된 아키텍처가 허용하는 사항과 비교될 때 시작됩니다. 그러면 시스템은 단순히 다이어그램에 언더라이팅 서비스(Underwriting Service)가 나타나는지 여부뿐만 아니라, EFFECTIVE 상태로 가는 모든 아키텍처 경로가 활성화되는 정확한 배서 버전에 대한 영구적인 승인에 의해 제어(gated)되는지를 평가할 수 있습니다.

설계를 아키텍처 그래프로 표현하기

아키텍처 설계자들은 다이어그램, API 계약 (API contracts), 스키마 (schemas), 상태 모델 (state models), 그리고 ADR (Architecture Decision Records)을 통해 승인 설계를 표현합니다. Architecture Graph Builder는 에이전트 기반 기능 (agentic capability)입니다. 결정론적 파서 (Deterministic parsers)가 산출물 (artifacts)을 처리하며, 모델 기반 추출 (model-based extraction)이 다이어그램과 의사결정을 해석합니다. 엔티티 해소 (Entity resolution)는 식별자들을 타입이 지정된 노드 (typed nodes)와 관계 (relationships)로 정규화합니다.

이 그래프는 서비스, 경계 컨텍스트 (bounded contexts), 애그리거트 (aggregates), 권위 있는 소유권 (authoritative ownership), 데이터베이스, 의존성 (dependencies), 동기 및 비동기 상호작용 (synchronous and asynchronous interactions), 상태 전이 (state transitions), 버전 바인딩 (version bindings), 일관성 경계 (consistency boundaries), 그리고 아키텍처 결정 사항을 나타냅니다. 각 단언 (assertion)은 출처와 신뢰도를 유지하며, 불확실한 매핑은 확인을 위해 설계자에게 다시 전달됩니다.

본 사례의 경우, 그래프는 Endorsement를 워크플로우 코디네이터 (workflow coordinator)로 기록하고, Underwriting, Rating, Policy, Billing을 각각 언더라이팅 결정, 요율 산정 결과, 유효한 보험 증권 버전, 그리고 금융 트랜잭션의 소유자로 기록합니다. 또한, 어떠한 누락도 결함으로 분류하지 않으면서 승인, 요율 산정, 효력 발생일, 그리고 보험 증권 버전 간의 활성화 경로, 완료 의존성 (completion dependencies), 그리고 바인딩 (bindings)을 포착합니다.

{
  "nodes": [
    {
...

이것은 보편적인 아키텍처 기술 언어 (architecture description language)가 되는 것을 목표로 하지 않습니다. 대신, Agentic AI 리뷰가 제안된 설계를 기계 판독 가능한 제약 조건 (machine-readable constraints)과 비교하고, 구현이 시작되기 전에 누락된 보장 사항 (missing guarantees)을 노출할 수 있도록 충분한 **설계 측면의 증거 (design-side evidence)**를 생성합니다.

코드 작성 전 아키텍처 인텔리전스 파이프라인

리뷰 파이프라인은 두 가지 버전화된 입력을 받습니다: Constraint Compiler로부터 전달된 승인된 제약 조건 세트와 Architecture Graph Builder로부터 전달된 아키텍처 그래프 스냅샷입니다. 리뷰 레이어는 각 제약 조건을 관련 그래프 노드 및 관계에 바인딩하고, 실행 계획 (execution plan)을 생성하며, 적절한 기능 (capabilities)으로 점검 사항을 전달합니다.

그림 2. 구현 전 제약 조건과 설계 증거(design evidence)가 어떻게 비교되는지를 보여주는 Pre-Code Architecture Intelligence Pipeline.

**결정론적 검증 엔진 (Deterministic Validation Engine)**은 객관적인 답변이 가능한 술어(predicates)를 평가합니다. 배서(endorsement) 설계의 경우, EFFECTIVE 상태로 가는 모든 경로에 영구적인 인수(underwriting) 승인이 필요한지, 상태 전이 소유권(state-transition ownership)이 명시적인지, 요율 산정(rating) 결과와 보험 증권 버전(policy version)이 동일한 배서 버전을 참조하는지, 효력 발생일(effective date)이 해당 버전에 바인딩되어 있는지, 그리고 과금(Billing), 문서(Documents), 알림(Notifications)이 활성화 차단 종속성(blocking activation dependencies)인지 등을 검증합니다.

**에이전트 기반 아키텍처 리뷰 (Agentic Architecture Review)**는 구조적 점검만으로는 해결할 수 없는 사항들을 조사합니다: 모호한 소유권, 누락된 증거, 숨겨진 결합(hidden coupling), API·스키마·상태 모델·ADR(Architecture Decision Records) 간의 상충하는 가정, 불완전한 복구 의미론(recovery semantics), 그리고 상충하는 설계 대안 등이 이에 해당합니다. 각 발견 사항(finding)은 이를 규정하는 제약 조건, 평가된 그래프 경로, 소스 아티팩트(source artifacts), 신뢰도(confidence) 및 권장 사항과 연결됩니다.

**증거 및 결정 저장소 (Evidence and Decision Store)**는 요구 사항, 제약 조건, 그래프 요소, 발견 사항, 권장 사항, 수용된 리스크 및 최종 결정에 이르는 계보(lineage)를 보존합니다. **인간 아키텍처 리뷰 (Human Architecture Review)**는 보험 예외 사항, 운영 제약 조건, 경제적 트레이드오프(trade-offs) 및 리스크 수용 문제를 해결합니다.

이 여섯 가지 기능은 결합되어 하나의 통제된 파이프라인을 형성합니다. 결정론적 검증은 가능한 곳에서 확실성을 확립하며, 에이전트 기반 AI (Agentic AI)는 아키텍처적 맥락과 판단이 필요한 곳에만 사용됩니다. 아키텍트는 구현이 시작되기 전 최종 권한을 유지합니다.

규칙 우선, 아키텍처적 판단을 위한 에이전트 기반 AI

이 단계에서는 리뷰 파이프라인(review pipeline)에서 생성된 결합된 증거(bound evidence)를 전달받습니다. 즉, **Constraint Compiler (제약 조건 컴파일러)**로부터 생성된 타입화된 제약 조건(typed constraint), 그에 상응하는 아키텍처 그래프(architecture-graph)의 서브그래프(subgraph), 그리고 두 항목에 부착된 출처(provenance) 및 신뢰도(confidence)가 포함됩니다. 목표는 언어 모델(Language Model)이 모든 것을 검토하게 만드는 것이 아니라, 기계적으로 증명 가능한 결과와 아키텍처적 판단이 필요한 질문을 분리하는 것입니다.

**Deterministic Validation Engine (결정론적 검증 엔진)**은 승인 전제 조건이 누락되었는지, 금지된 전이(transition)가 도달 가능한지, 여러 서비스가 권위 있는 상태(authoritative state)를 수정할 수 있는지, 등급 결과가 다른 승인 버전(endorsement version)을 참조하는지, 유효 날짜(effective date)가 누락되었는지, 또는 차단된 다운스트림 작업(downstream operations)에 정의된 복구 의미론(recovery semantics)이 결여되었는지 등을 평가합니다.

IF endorsement transitions to EFFECTIVE
AND underwritingRequired = true
AND no APPROVED decision exists
...