지속 가능한 웹사이트란 단지 지속 가능성에 대해 이야기하는 웹사이트가 아닙니다. 오랫동안 관리하고, 확장하고, 검토할 수 있도록 기술적으로도 잘 만들어져 있어야 합니다. 우리는 바로 이 부분을 계속 다듬어 왔습니다.
그 중심에는 하나의 원칙이 있었습니다. 바로 Single Source of Truth, 줄여서 SSOT입니다. 모든 중요한 정보는 정확히 하나의 신뢰할 수 있는 출처를 가져야 합니다. 색상, 상태 표시, 조직 데이터, 텍스트, 데이터베이스 구조, 품질 프로세스는 여러 곳에 조금씩 다르게 복사되어서는 안 됩니다. 그렇지 않으면 모든 변경이 더 위험해지고, 더 느려지고, 더 비싸집니다.
무엇을 개선했는가
우리는 핵심 규칙이 준수되는지 자동으로 확인하는 새로운 컴플라이언스 검사를 추가했습니다. 여기에는 SSOT 감사와 번역을 위한 i18n 감사가 포함됩니다. SSOT 검사는 이제 무엇보다도 API 라우트에서 데이터베이스 테이블이 생성되거나 오래된 hardcoded-content 패턴이 다시 나타나는 것을 막아줍니다.
배포 프로세스도 더 엄격해졌습니다. 경고를 무시하거나 빌드 후에야 검사하는 대신, 이제 품질 경로가 더 명확하게 흐릅니다. TypeScript, 린팅, 컴플라이언스, 테스트, 그리고 프로덕션 빌드 순서입니다. 이렇게 하면 오류가 더 일찍 드러나고 릴리스 전 신뢰성이 강화됩니다.
디자인 시스템에서는 여러 하드코딩된 색상 값을 중앙 UI 설정으로 옮겼습니다. Open-Graph 이미지, 피드백 오버레이, 오류 페이지, 카테고리 폼, 팩트시트, 히어로 패턴, 고객 프로필을 위한 앱 고유 색상이 이제 이름 붙은 위치에 놓여 있습니다. 이는 숨겨진 의존성을 줄이고 이후의 조정을 더 정확하게 만듭니다.
또 다른 요점은 콘텐츠와 설정의 분리였습니다. "곧 출시"와 같은 서비스 배지는 기술적인 서비스 설정에 고정되어서는 안 되고, 번역에 속해야 합니다. 이런 작은 이동들이 장기적으로 유지보수성에 크게 기여합니다.
왜 이것이 중요한가
하드코딩은 종종 편리하지만 부채를 만듭니다. 여기에 색상 하나, 저기에 독일어 텍스트 하나, 도메인 파일에 상태 클래스 하나, API 라우트에 데이터베이스 구문 하나. 각각의 위치는 무해해 보입니다. 하지만 합쳐지면 이해하기 어렵고 안전하게 변경하기 어려운 시스템이 됩니다.
그래서 SSOT는 그 자체가 목적이 아닙니다. 그것은 우리가 더 빠르고 정확하게 일하도록 돕습니다.
- 변경이 여러 곳이 아니라 한 곳에서 일어납니다.
- 디자인 결정이 일관되게 유지됩니다.
- 번역이 측정 가능해집니다.
- 데이터베이스 구조가 마이그레이션과 스키마 파일에 유지됩니다.
- 리뷰가 탐색 작업 대신 동작에 집중할 수 있습니다.
아직 남은 과제
방향은 명확하지만 작업이 끝난 것은 아닙니다. 다음으로 우리는 기존의 번역 부채를 줄이려 합니다. 새로운 i18n 검사는 이미 새로 누락되는 키를 막고 있지만, 일부 기존 공백은 여전히 기준선(baseline)으로 문서화되어 있습니다.
또한 도메인 설정을 UI 텍스트와 더 분리해야 합니다. active, sold, reserved 같은 상태 값은 도메인 데이터입니다. 독일어 레이블과 시각적 표현은 번역과 UI 매핑을 통해 깔끔하게 나와야 합니다.
디자인 시스템 역시 더 깊은 통합이 필요합니다. 이미 좋은 중앙 구성 요소들이 있지만, 몇몇 오래된 토큰 계층이 겹칩니다. 목표는 명확한 아키텍처입니다. 프리미티브 토큰, 시맨틱 토큰, 컴포넌트 변형, 그리고 영역별 매핑입니다.
우리의 기준
유지보수성은 우리에게 품질의 척도입니다. 그것은 플랫폼이 오늘만 작동하는지, 아니면 1년 후에도 안전하게 발전시킬 수 있는지를 결정합니다.
SSOT, 관심사의 분리, 그리고 DRY 코드는 우리에게 추상적인 개념이 아닙니다. 그것들은 구체적인 작업 규칙입니다. 복사본을 줄이고, 경계를 명확히 하고, 자동화를 개선하고, 변경을 불필요하게 어렵게 만들지 않는 시스템입니다.
우리는 바로 이것을 계속 만들어 나갑니다.