객체지향이 만능도 아니고, 객체지향을 하더라도 경우에 따라서는 외부에서 속성 변경을 지양하고 명확한 비즈니스적 의미를 갖는 메서드로 내부 상태를 변경하는 접근이 더 나을 수 있는 건 맞다.


근데 분명한 건, 게터/세터라는 개념이 존재하는 건 전통적인 객체지향 패러다임에선 클래스의 속성이란 걸 외부에서 제어하며 확장 가능하다는 걸 전제로 하기 때문이란 거다. 그걸 문법적으로 어떻게 표현하는지, 또 그게 얼마나 장황한지는 부차적인 문제이고.


"게터/세터가 도대체 왜 필요한가"라고 묻는다면 그건 언어에 대한 비판이 아니라 전통적 객체지향이라는 패러다임 자체에 대한 비판으로 이해할 수 밖에 없다. 객체지향 자체를 하지 말라던가, 아니면 객체지향의 내용을 바꾸어야 한다던가 둘 중에 하나가 되겠지.


객체지향 vs 함수형 같은 건 이야기가 엄청 커질테니 후자만 놓고 본다면, 게터/세터 무용론의 근거는 아마 앞서 이야기 한 비즈니스 메서드로 내부 상태를 관리하는 게 낫다는 주장으로 정리할 수 있을 거다.


앞서 말한대로 그건 나름대로 좋은 설계가 될 수 있는 접근이란 데는 동의하는데, 문제는 그게 게터/세터의 존재의의 자체를 부정하는 주장이 된다면 그런 설계가 모든 객체지향 시스템에 적용가능한 보편성을 증명해야 한다는 것이다.


그런 설계 방식을 다르게 표현하면 "객체의 속성을 임의로 외부에서 바꾸거나 확장하는 것은 불필요하다" 정도로 요약할 수 있는데, 이 건 반례를 쉽게 찾을 수 있기 때문에 보편적인 대안이 될 수 없다고 본다.


가장 큰 문제는, 이는 객체지향에서 클래스의 설계는 미래의 제 3자에 의한 확장에 대해서도 열려 있어야 한다는 원칙을 위배한다는 것이다. 클래스의 변경 가능한 모든 상태를 private로 선언하고, 이를 사전에 정의한 비즈니스 메서드로만 변경한다면 해당 상태의 변경과 관련한 기능을 추가하려면 반드시 소스 수준의 수정이 필요하게 된다. 반면에 해당 상태에 대한 protected 세터만 열려 있더라도 원 클래스의 소스를 수정하지 않고 이를 확장해서 기능을 추가하거나 변경할 수 있다.


또한 상태 변경 뿐 아니라, 예를들어 본래의 클래스를 확장해서 특정 속성이 변경될 때 어떤 이벤트를 발생 시켜야 한다던지, 변경할 수 있는 값의 범위를 제한하고 싶다던지 하는 요구 사항이 있어도, 게터/세터를 배제할 경우 역시 본래의 클래스를 소스 수준에서 고치지 않으면 대응하기 어렵다.


그래서 정리하면, 특정 상황에서 게터/세터를 사용하지 않는 설계가 바람직하다고 주장할 수 있어도, 그걸 일반화해서 전통적 객체지향을 지원하는 언어에서 게터/세터의 존재 자체를 부정하는 건 어렵다고 본다.