FP 개발자, 시스템 설계 시 '버전'을 잊지 마세요!

게시글은 함수형 프로그래밍(FP)의 강력한 타입 시스템(type system)이 프로그램의 국소적 정확성(local correctness)을 보장하지만, 실제 운영 환경에서는 여러 버전의 코드가 동시에 실행되므로 배포 집합(set of deployments) 전체의 호환성이 중요하다고 강조한다. 특히, 롤링 배포(rolling deploy), 블루-그린 배포(blue-green deploy) 등에서 발생하는 버전 간의 상호 작용(interactions between versions)이 시스템 오류의 주요 원인이 된다고 지적한다. 따라서, 단일 프로그램의 정확성 검증에 집중하는 대신, 배포 환경에서의 호환성 보장(compatibility guarantee)에 초점을 맞춰야 한다.

데이터베이스 스키마 변경(database schema change)은 롤백(rollback)이 어렵고, 데이터 손실의 위험이 있어 주의해야 한다. 게시글은 확장-축소 패턴(expand-and-contract pattern)을 통해 안전하게 스키마를 변경하는 방법을 제시한다. 이는 새로운 컬럼을 추가하고, 데이터를 백필(backfill)한 후, 기존 컬럼을 삭제하는 일련의 과정을 거친다. 이러한 방식은 데이터 격리 아키텍처(Data Isolation Architecture)를 구축하고, 롤백 시 발생할 수 있는 미검증된 상태(untested configuration)를 방지한다. 또한, 데이터베이스 이론에서 말하는 양방향 스키마 변환(bidirectional schema transformation)과 유사한 접근법임을 설명한다.

메시지 큐(message queue)는 데이터의 장기 보존으로 인해 버전 호환성 문제를 더욱 복잡하게 만든다. 특히, Kafka와 같은 시스템은 장기간의 데이터 보존으로 인해 여러 버전의 데이터 형식(serialization format)이 공존하게 된다. 게시글은 이러한 문제를 해결하기 위해 스키마 레지스트리(schema registry)를 활용하여, 배포 시점마다 호환성 검사(compatibility check)를 수행하는 방법을 제시한다. 또한, 이벤트 소싱(event sourcing) 시스템에서 발생하는 의미론적 드리프트(semantic drift) 문제를 해결하기 위해, 데이터의 의미 변화를 인지하고, 적절한 조치를 취해야 함을 강조한다.

게시글은 'Parse, Don't Validate' 원칙을 버전 경계(version boundary)에도 적용하여, 배포 전에 스키마 호환성 검사(schema compatibility check)를 수행하는 것이 중요하다고 강조한다. Confluent의 스키마 레지스트리, GraphQL의 Apollo GraphOS, 데이터베이스 마이그레이션 도구 등을 예시로 들며, 이러한 도구들이 런타임(runtime)에서 발생하는 문제를 빌드 타임(build time)으로 옮겨, 사전 검증(pre-validation)을 가능하게 한다고 설명한다. 궁극적으로, 배포 시점에 현재 실행 중인 모든 버전과의 호환성을 확인하는 자동화된 시스템(automated system) 구축을 목표로 해야 한다.