[프로그래밍 이야기 2] 델파이가 쏘아 올린 캡슐화의 정점, 프로퍼티의 계보

프로그래밍 세계에서 어떤 유산은 이름은 잊혀도 그 흔적은 생태계 전체를 지배하곤 합니다. 델파이가 바로 그렇습니다. 2000년대 초반, 전산실과 소프트웨어 개발사를 제패했던 델파이는 이제 주류에서 비껴난 듯 보이지만, 그가 남긴 프로퍼티라는 유산은 현대 모든 언어의 세포 속에 살아 숨 쉬고 있습니다.

프로그래밍에서 객체의 내부 데이터를 보호하는 캡슐화는 매우 중요한 원칙입니다. 하지만 순수 C++나 Java 스타일처럼 모든 변수에 get_hp, set_hp 같은 메서드를 일일이 만드는 방식은 개발자의 생산성을 갉아먹고 코드를 장황하게 만듭니다. 이 지점에서 변수처럼 보이지만 실제로는 함수처럼 동작하는 우아한 해법인 프로퍼티가 등장합니다.

1. 델파이(Delphi)와 프로퍼티의 탄생

프로퍼티의 역사는 1995년 델파이 1.0의 출시와 함께 시작됩니다. 당시 천재 개발자 안데르스 헤일즈버그가 설계한 VCL(Visual Component Library)은 이미 완성된 형태의 프로퍼티 문법을 선보였습니다. 놀라운 점은 다른 메이저 언어들이 이 개념을 '현대적 표준'으로 받아들이기까지 걸린 시간입니다.

• C# (2002년): 델파이의 설계자 헤일즈버그가 MS로 이직한 후, 7년이 지난 뒤에야 C# 1.0의 핵심 기능으로 프로퍼티가 이식되었습니다.

• Python (2002년): 파이썬 역시 2002년 출시된 Python 2.2에 이르러서야 property() 내장 함수를 도입하며 이 개념을 수용했습니다. (우리가 흔히 쓰는 @property 데코레이터 문법은 2004년 Python 2.4에서야 완성됩니다.)

델파이가 90년대 중반에 이미 완성한 철학이 업계 전반의 표준이 되기까지 무려 7년에서 10년 가까운 세월이 걸린 셈입니다. 델파이는 시대를 너무 앞서 나갔던 선구자였습니다.

2. GUI 도구들의 숨은 엔진과 게임 제작 도구

델파이가 닦아놓은 영향력은 윈도우를 넘어 리눅스와 게임 엔진 진영으로도 뻗어 나갔습니다. Qt 프레임워크는 C++ 위에서 매크로를 통해 델파이식 생산성을 이식했고, GTK 역시 GObject 시스템을 통해 프로퍼티 개념을 구현했습니다.

특히 언리얼 엔진이나 Qt 같은 추상화된 도구에서 프로퍼티는 프로그래머뿐만 아니라 디자이너에게도 안전한 인터페이스를 제공합니다. 예를 들어 캐릭터의 HP를 수정할 때, 단순 변수라면 -1이나 음수를 넣어 논리적 오류를 일으킬 수 있지만, 프로퍼티를 통하면 내부적인 안전 코드가 이를 즉시 차단합니다. 1995년 델파이 개발자들이 폼 위에 버튼을 올리며 누렸던 그 안전함이, 오늘날 거대 게임 엔진의 물리 법칙을 제어하는 기반이 되었습니다.

Delphi

// 1995년부터 존재했던 델파이의 안전 로직 예시
property HP: Integer read FHP write SetHP;

procedure TCharacter.SetHP(Value: Integer);
begin
  if Value < 0 then FHP := 0  // 음수 입력을 사전에 차단
  else FHP := Value;
end;

3. 명확성과 생산성의 충돌: 추상화의 딜레마

재미있는 점은 현대 언어들이 이 유산을 대하는 태도입니다. 시스템의 투명성을 극단으로 추구하는 Go(2009년)나 Rust(2015년) 같은 언어들은 언어 차원에서의 프로퍼티를 거부했습니다. 변수처럼 보이는데 내부적으로 함수가 실행된다는 점이 부수 효과(Side Effect)를 숨겨 성능 최적화와 디버깅을 방해한다고 본 것입니다.

하지만 이들 언어로 만든 엔진이나 개발 도구조차 응용 레이어(Application Layer)에서는 결국 프로퍼티와 유사한 구조를 다시 구축합니다. 원초적인 언어 설계에서는 배제되었을지언정, 실제 제품을 만드는 '추상화된 도구'의 영역에서는 프로퍼티 없이는 생산성을 감당할 수 없기 때문입니다. 이는 프로퍼티가 응용 소프트웨어 제작에 있어 '선택'이 아닌 '필수' 기능임을 반증합니다.

또한, 비슷한 체급의 언어 사용자들 사이에서도 이 문제는 거대한 생산성 장벽으로 작용합니다. C# 사용자들은 당연하게 누리는 이 우아한 캡슐화를, Java 사용자들은 여전히 장황한 Getter/Setter 메서드를 수동으로 작성하며 견뎌내고 있습니다. 원초적인 명확성을 지키려는 고집과 현대적인 생산성 사이의 간극은, 같은 OOP 진영 내에서도 서로를 이해하지 못하는 문법적 장벽이 되곤 합니다.

4. 델파이가 남긴 흔적

델파이는 현재 예전만큼의 인기를 누리지 못합니다. 하지만 역설적으로 자신이 남긴 유산이 다른 모든 주류 언어에 퍼졌기 때문이기도 합니다. 1995년 델파이만이 줄 수 있었던 압도적인 편리함을 이제는 C#과 파이썬 등 어디서나 누릴 수 있게 되었습니다.

어떤 언어들은 비록 주류에서 물러나더라도 그들이 발명한 철학을 통해 영생을 얻습니다. 캐릭터의 HP가 잘못된 값으로 떨어지는 것을 막아주던 델파이의 소박한 안전 코드는, 오늘날 수조 원대 규모의 게임 엔진과 엔터프라이즈 소프트웨어의 근간이 되었습니다. 델파이는 아쉽게 저물어가고 있지만, 우리가 무심코 사용하는 모든 속성 창과 코드 속에는 여전히 30년 전 그 뜨거웠던 전성기의 유전자가 살아 숨 쉬고 있습니다.