규칙 하나를 바꿀 때 드러나는 플랫폼의 구조

“구매 요청의 승인 기준을 바꿔 주세요.” 플랫폼의 확장성을 평가하려면 새 화면을 만드는 시연과 함께 이런 작은 변경을 요청해 보세요. 입력 폼, 모바일 화면, API, AI 도구에서 같은 규칙이 적용되는지 보면 실제 변경 비용이 드러납니다.

변경 한 건을 끝까지 따라갑니다

가상의 구매 업무에서 특정 품목군에 추가 검토자를 지정한다고 가정합니다. 화면에 검토자 필드를 넣는 것만으로는 충분하지 않습니다. 기존 요청은 어떤 규칙을 따르는지, 이미 승인된 요청은 그대로 실행할지, API로 제출해도 같은 조건을 지키는지 정해야 합니다.

같은 조건을 각 화면과 프롬프트에 반복해 넣으면 한 곳을 빠뜨리기 쉽습니다. 검증을 책임지는 곳을 정하고, 호출하는 여러 화면과 도구가 그 결과를 사용하도록 설계합니다.

공통 모델과 업무별 의미를 구분합니다

영업의 고객, 청구의 고객, 지원의 고객은 동일한 조직을 가리켜도 필요한 속성과 상태가 다릅니다. 식별자와 관계를 연결하면서 각 업무의 소유권을 유지해야 합니다. 모든 필드를 거대한 공통 객체 하나에 넣으면 변경 영향이 오히려 넓어질 수 있습니다.

Microsoft의 도메인 분석 가이드는 모델이 적용되는 경계를 bounded context로 설명합니다. 공통 기반과 업무별 의미를 나누는 설계에 참고할 수 있습니다. Use domain analysis to model microservices

Giz에서 말하는 리빙 모델의 설계 방향은 데이터 정의, 화면 구성과 실행 동작을 연결하는 것입니다. 가치는 명칭보다 규칙 변경이 필요한 곳의 수와 검증 가능한 결과로 평가해야 합니다.

선언한 규칙도 운영 조건을 필요로 합니다

모델이 바뀌어도 이미 실행 중인 요청, 장시간 열려 있던 화면, 외부 시스템의 실패는 남습니다. 규칙의 버전, 동시 수정과 재검토 조건을 명시해야 합니다. 선언적 구성이 인증·트랜잭션·운영 기록의 책임을 대신하지는 않습니다.

제안 시연에서 요청할 결과

실제 담당자가 이해하는 규칙 하나를 선택하세요. 변경 전후의 화면, API 호출과 Agent 동작을 같은 입력으로 비교하고, 허용되지 않는 요청이 같은 이유로 거절되는지도 확인합니다. 바뀐 소스의 양과 함께 검증·배포·복구에 필요한 일을 보면 유지보수 범위가 더 명확해집니다.

Giz 플랫폼 구조 살펴보기