코드로 관리하는 설정 기반 스키마 흐름

문제

여러 시장을 위한 흐름은 코드 중복을 낳았고, 제품이나 컴플라이언스가 지역 규칙을 바꾸고 싶을 때마다 엔지니어링 티켓이 필요했습니다.

접근 방식

• 스키마로 폼 렌더링. UI는 jsonform으로 JSON 또는 YAML 설정을 읽습니다. 스키마가 필드와 검증 규칙을 만들어 냅니다. 네이티브 브리지 시작 같은 커스텀 액션은 코드에 남습니다.
• 하나의 단계, 다른 결과. 설정이 시장과 플랫폼별로 단계의 동작을 정합니다. 네이티브 기능을 지원하는 곳에서는 안내와 스캔 버튼을 보여 주고, 아니면 일반 폼 필드와 계속 버튼을 보여 줍니다. 제품 쪽은 코드가 아니라 설정에서 이를 바꿉니다.
• 코드로서의 설정. 변경은 Git으로 제출합니다. 변경마다 자동으로 풀 리퀘스트가 열리고, TypeScript 타입으로 뒷받침되는 엄격한 스키마 검증과 함께 CI가 실행되어, 잘못된 설정은 프로덕션 전에 실패합니다.

설명할 만한 두 가지 결정

렌더링은 jsonform, 액션은 코드. 서버가 보낸 임의의 로직을 실행하는 완전한 서버 주도 UI는 원격 코드 실행 위험과 성능 문제를 부릅니다. 데이터 기반 렌더링과 미리 컴파일된 핸들러에 묶인 액션은 그런 노출 없이 유연성을 지켜 줍니다.

관리자 폼 대신 Git. 거버넌스 없는 손쉬운 편집은 프로덕션 흐름을 망가뜨립니다. 풀 리퀘스트, 타입 검사, CI가 모든 변경을 추적 가능하고, 검토를 거치고, 되돌리기 쉽게 만듭니다.

결과

설정 배포가 더 이상 프론트엔드 배포에 의존하지 않아 다중 시장 업데이트가 몇 주에서 몇 시간으로 줄었고, 지역별 코드 중복도 더는 늘지 않았습니다.