데이터 중심 애플리케이션 설계, 마틴 클레프만 지음. OREILLY.

Data outlives code.
데이터는 코드보다 오래 산다.

몇년 전에 가입한 구글 계정. 구글 홈페이지 UI가 바뀌어도 로그인은 그대로 잘 된다. 홈페이지 코드가 바뀌더라도 회원 정보 데이터는 그대로 살아있다는 뜻이다.

(사진 출처: HISTORY OF GOOGLE SEARCH)

서비스는 계속해서 업데이트 될 수 있다. 하지만 서비스가 바뀌느라 이전에 쌓았던 데이터에도 변동이 생기면 안된다. 화면을 구성하는 코드보다 데이터가 훨씬 오래 살아남는다.

데이터를 오래오래 보기 위해

요즘에는 특히 서비스가 더 빠르게 변한다. 블루-그린 배포를 비롯한 무중단 배포 기법도 많아지고 있으며 마이크로서비스와 같은 새로운 구조의 시스템이 만들어지고 있다.

상하위 호환성

어떤 방식을 사용하든 서비스 코드는 변하기 마련이고, 새로운 코드에서도 기존 데이터를 잘 읽고 사용할 수 있어야 한다. 이를 상위 호환성이라고 한다. 반대의 경우도 마찬가지다. 새로운 코드를 통해 쌓인 데이터를 기존 코드도 잘 해석할 수 있어야 한다. 이를 하위 호환성이라고 한다.

'새 버전이 나왔는데 기존 버전을 왜 신경써야하지?' 라고 생각할 수도 있지만, 주변을 둘러보자. 부모님 세대는 구버전 인터넷 익스플로러를 쓰시는 분들이 많다. (적어도 우리 부모님은 크롬이 뭔지도 모르시고, 작년까지 윈도우 7을 사용하셨다.) 안드로이드 어플은 iOS 앱과 다르게 사용자가 직접 업데이트 버튼을 눌러야 진행된다. 그 전까지는 자연스럽게 기존 버전 앱을 쓰게 된다.

상위, 하위 호환성은 이번 장 전반에 걸쳐 계속해서 언급된다. 이후에 나올 복호화, 부호화 방식의 평가 기준이 되기 때문이다.

발전성

상하위 호환성을 지키면서 우리가 궁극적으로 이루고 싶은 목표는 발전성을 보장하는 것이다. 발전성은 시스템의 일부만 독립적으로, 쉽게 변경할 수 있는 성질을 의미한다. 상하위 호환성을 잘 지원하는 서비스는 발전성도 좋다고 말할 수 있다.

부호화, 복호화, 암호화

정체

부호화, 복호화

• 부호화(직렬화, 마샬링): 데이터를 인메모리 표현에서 바이트열로 변환
• 복호화(역직렬화, 언마샬링): 데이터를 바이트열에서 인메모리 표현으로 변환.

필요성

이 둘은 정확히 반대되는 개념이다. 인메모리 표현은 CPU에서 효율적으로 데이터에 접근하고 조작할 수 있도록 최적화한 데이터 표현 방식을 말한다. 이렇게 최적화한 데이터는 메모리에 저장된다. 따라서 운영체제별, 환경별로 그 최적화 방식이 다를 것이다.

1. 이전 버전과 새로운 버전의 데이터, 코드가 공존하는 시스템을 만들기 위해서는 부호화/복호화 작업이 필요하다.
2. 메모리를 공유하지 않는 다른 프로세스로 데이터를 전송할 때도 부호화/복호화 작업이 일어난다. 예를 들면 네트워크 패킷 통신을 하거나, 파일로 데이터를 주고받는 경우가 있다.

암호화

암호화는 부호화와 다르다. 번역된 단어를 보면 왠지 '오~~ 뭔가 알 수 없는 비밀 부호 같은걸 써서 데이터를 암호화 하는거군~~' 이라는 생각이 들 수도 있는데 (혹은 그 반대거나) 완전히 다른 개념이다. 이 책에서 암호화는 전혀 다루지 않는다.

데이터 부호화 방식 4가지

1. 언어별 내장 부호화 라이브러리 사용
2. JSON, XML, CSV (이진 변형)
3. 이진 부호화 (XML, JSON 보완)
4. 스키마 기반 라이브러리

책에서 소개하는 부호화 형식은 이렇게 총 4가지다. 상하위 호환성을 기준으로 각각의 장단점을 비교한다. 결론적으로는 1번보다 나머지 방식을 사용하는게 낫다. 보안, 효율성, 다른 언어와의 통합 등의 측면에서 문제점이 많기 때문이다.

스키마 기반 라이브러리

여기에 대해서는 꽤 자세히 다루고 있다. 아파치 스리프트(Apache Thrift), 페이스북의 프로토콜 버퍼(Protocol Buffers, protobuf), 하둡의 아브로(avro)의 동작 원리와 장단점을 비교하고 있다. 결론은 스키마를 사용한다고 해서 결코 다른 방식에 비해 비효율적이지 않다는 사실을 밝혀준다. 이를 설명하기 위해 스키마 발전 개념이 등장한다.

스키마는 영원하지 않다

스키마 발전

데이터가 변함에 따라 데이터를 저장하는 틀인 스키마도 변하기 마련이다. 회원가입을 예로 들어보자. 이메일 회원가입만 지원하던 쇼핑몰에서 소셜 로그인을 지원하기 시작하면, 소셜 계정과 쇼핑몰 자체 계정을 연결하기 위한 새로운 스키마가 만들어져야 할 것이다. 이렇게 시간이 지남에 따라 스키마가 변하는 것을 스키마 발전(schema evolution) 이라고 부른다.

아파치 스리프트, 프로토콜 버퍼와 같은 스키마 기반 라이브러리가 부호화를 진행한 결과로, 부호화된 레코드가 나온다. 부호화된 레코드는 결국 기존 데이터 필드를 부호화해서 연결해놓은 것으로, 필드 태그와 데이터 타입, 필드값으록 구성된다. 책에서는 필드 태그와 필드 데이터 타입을 활용해서 어떻게 상하위 호환성을 보장하는지 보여준다. 스키마리스 데이터베이스가 제공하는 것과 동일한 종류의 유연성을 제공할 수 있다.

데이터 플로우

마지막 주제인 데이터 플로우는 프로세스간 데이터 전달 방식을 말한다. 총 3가지 방법을 소개한다.

주체	방식
데이터베이스	DB read/write 시 부호화, 복호화가 이루어진다.
서비스	클라이언트-서버 모델에서 API 버전 간 호환에 집중한다. 2가지 방식을 다룬다. - REST: HTTP 원칙을 토대로 한 설계 철학 - RPC: remote라는 사실을 모른 채 다른 기계와 통신
메세지 브로커 혹은 액터	비동기 메세지 전달 시스템을 사용해서 송/수신자가 각각 부호화, 복호화한다.