들어가며

어떤 클래스를 직렬화 가능하게 만들기는 쉽다. 하지만 Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다. 클래스가 Serializable을 구현하면 직렬화된 바이트 스트림 인코딩도 하나의 공개 API가 된다. 이 클래스가 널리 퍼지게 되면 그 직렬화 형태도 영원히 지원해야 하는 문제가 생긴다.

나중에 클래스 내부 구현을 손보면 원래 직렬화 형태와 달라지게 된다. 그러면 구버전과 신버전 사이에 테스트에서 호환성 테스트를 진행해야한다. 직렬화의 두번째 문제는 버그와 보안 구멍이 생기는 위험이 많아진다는 점이다. 역직렬화는 일반 생성자의 문제가 그대로 적용되는 숨은 생성자다. 이 생성자는 전면에 드러나지 않기 때문에 불변식을 모두 보장하거나 생성 도중 공격자가 객체 내부를 들여다 볼 수 없도록 해야 한다는 생각을 떠올리기 힘들다. 세번째 문제는 테스트의 증가이다.

Serializable의 구현 여부는 가볍게 결정할 사안이 아니다. 단 객체를 전송하거나 저장할 때 직렬화를 이용하는 프레임워크용으로 만든 클래스라면 선택의 여지가 없다. Seriazliable을 반드시 구현해야 하는 다른 클래스의 컴포넌트로 쓰일 클래스도 마찬가지다.

Serializable을 구현하지 않기로 했다면 주의해야할 사항은 하나다. 상속용 클래스인데 직렬화를 지원하지 않는다면 하위 클래스에서 직렬화를 지원하려 할 때 부담이 늘어난다.

내부 클래스는 직렬화를 구현하지 말아야 한다. 내부 클래스에는 바깥 인스턴스의 참조와 유효 범위 안에 지역변수 값들을 저장하기 위해 컴파일러가 생성한 필드들이 자동으로 추가된다. 하지만 내부 클래스에 대한 기본 직렬화 형태는 분명하지 않기 때문에 구현하지 말아야 한다.