설계

표준 메타데이터가 개정될 때마다 마이그레이션을 찍어야 했던 고정 컬럼 모델을, 메타클래스 인스턴스 기반으로 전환한 설계 기록입니다. JSONField·고정 컬럼 유지를 포함한 세 가지 안을 놓고 왜 EAV에 가까운 구조를 골랐는지, 리터럴 값과 객체 참조를 왜 다른 테이블로 나눴는지, 그리고 두 모델을 한동안 동시에 살려둔 전환 전략을 정리했어요.

속성에 달려 있던 is_mandatory를 클래스-속성 관계 행으로 옮긴 작업입니다. 같은 속성이 클래스마다 필수/선택으로 갈리는데 전역 플래그로는 표현할 수 없었어요. 이관 마이그레이션을 짜다 PostgreSQL의 pending trigger events에 걸렸고, 제약을 백필보다 먼저 만드는 순서로 풀었습니다.

속성의 range가 CharField 하나였습니다. xsd:string 같은 데이터 유형과 클래스 이름이 같은 칸에 문자열로 들어가 있었어요. FK 두 개 + 상호배타 제약으로 쪼개면서, 왜 단일 FK나 Generic FK로 가지 않았는지, 그리고 데이터 마이그레이션 스크립트 없이 로더 재적재만으로 과거 오적재를 정정한 방법을 정리합니다.

Open API의 데이터 계층을 처음부터 provider 인터페이스로 추상화해 mock으로 화면·계약을 먼저 굳히고, 실데이터 전환은 OrmDataProvider 골격 + 한 줄 스위치로 분리한 과정을 정리합니다. 미완 활성화가 곧 비공개 데이터 유출이라 fail-closed로 설계한 이야기도 담았어요.

"거의 안 바뀔 것"이라는 가정으로 정적 JSON에 두었던 네임스페이스 옵션이 실제로는 자주 바뀌고 있었고, 결국 DB 조회로 옮긴 결정과 그 교훈을 정리합니다.

프론트엔드가 먼저 만들어둔 두 작업이 각각 "심사 전 무분별 취소"와 "OID 트리 방향 역전 필요"라는 도메인 문제를 드러낸 과정과, 어떻게 결정·정리했는지에 대한 회고입니다.

편집자가 직접 쓴 글과 RSS에서 수집한 글을 하나의 Post 테이블에 두되, source_type 필드로 분기하는 설계의 장단점과 어드민/쿼리 패턴을 정리합니다.

8개 카테고리 커뮤니티 게시판을 단일 Post 모델로 갈지, 카테고리별로 앱을 나눌지. 이번 프로젝트에서 전자를 택한 이유와 트레이드오프를 정리합니다.

업무상 결제해둔 ITS/V2X 관련 표준 14종(ISO 14817-2, SAE J2735, KS R 1600 시리즈, KS X ISO 14827/15784, ISO TS 19091)을 실제로 읽어보며, 각 표준이 무엇을 규정하고 서로 어떻게 물려 있는지 한 글에 정리합니다.

표준데이터 등록 시스템(SDMS)에 ISO 14817-2의 데이터 개념 라이프사이클을 적용해 기록→제출→사전검증→검증→사전인증→인증→배포의 7단계 상태 머신을 구성한 과정을 정리합니다.

심사 프로세스에 승인/반려 외 제3의 축(보완 요청)을 추가했다가, 상태 머신 복잡도와 UX 혼란을 이유로 철회한 의사결정 과정을 정리합니다.

Exception Not Found의 워크플로우 엔진 DB 설계 8부작을 정리하고, 그 설계를 실제 표준데이터 심사 워크플로우로 구현하면서 무엇을 그대로 따랐고 무엇을 바꿨는지 대조했습니다. 참조 설계가 스스로 지적한 한계 하나는 구현 단계에서 피해갈 수 있었고, 하나는 그대로 남았어요.

RDF, 온톨로지, DCAT, 링크드 데이터 — 표준데이터 관리 시스템을 맡게 되며 급하게 공부했던 시맨틱 웹 개념 정리입니다. 특이한 건 이 공부가 교양으로 끝나지 않았다는 것 — 온톨로지의 클래스·인스턴스·속성·관계가 그대로 시스템의 데이터 모델이 됐고, 그 과정에서 개념과 RDB 사이의 간극도 몸으로 배웠습니다. 정리 뒤에 그 이야기를 붙였습니다.

인프런 클린코드 강의를 들으며 정리한 입문 수준의 핵심 개념과 실무 적용 포인트.