연결이 많아질수록 중요한 것은 경계입니다
기업 시스템에는 데이터베이스, API, 화면, 승인 규칙과 자동화 도구가 있습니다. 각 요소가 같은 업무를 조금씩 다르게 정의하면, 작은 변경도 여러 곳을 고쳐야 하는 일이 됩니다. 리빙 모델의 목적은 모든 것을 한 파일에 넣는 것이 아니라, 같은 결정을 반복하지 않는 데 있습니다.
선언과 실행의 관계
필드의 자료형과 검증 규칙, 조회 권한, 화면 표시와 실행 가능한 동작을 일관된 모델에 연결합니다. 런타임은 이 선언을 해석해 화면과 도구에 제공합니다. 실제 트랜잭션은 서버가 책임집니다. 화면 구성요소가 데이터베이스 권한을 임의로 판단해서는 안 됩니다.
변경의 단위를 작게 만듭니다
새로운 승인 조건이 생겼을 때 웹 폼, API와 에이전트 프롬프트에 각각 조건을 추가하면 시간이 지나며 차이가 생깁니다. 서버 동작의 공통 계약을 변경하고 각 호출자가 그 결과를 해석하도록 설계하면 중복을 줄일 수 있습니다.
모델만으로 해결되지 않는 것
직렬화된 함수는 외부 클로저에 의존하지 않아야 하며, 버전이 바뀌었을 때 동시 편집과 실행 중 요청을 어떻게 처리할지 정해야 합니다. 데이터와 코드를 선언적으로 연결해도 인증, 트랜잭션, 관측과 운영 검증은 여전히 필요합니다.
도입에서 물어볼 세 가지
- 이 규칙을 결정하는 곳이 정확히 하나인가?
- 화면과 에이전트가 같은 서버 동작을 호출하는가?
- 변경 전후를 실제 데이터와 실행 기록으로 확인할 수 있는가?
이 질문에 답할 수 있는 작은 업무부터 구축하면 플랫폼의 추상화가 현장의 편의로 이어집니다.