2010년 11월 23일

이하의 글은 2010년에 쓴 것입니다. 오래된 글인 만큼, 현재의 생각과 전혀 다른 내용도 많이 포함되어 있고, 당시와는 상황이 많이 달라진 점도 있습니다. 또한, 그 당시에 잘못 알려졌던 정보도 포함되어 있을 수 있습니다. 어찌됐든 저는 제 오래된 글이 회자되는 것을 저어합니다. 읽기에 앞서 양해를 부탁드립니다.

어쩌다가 Toby Lee라는 사람이 내가 쓴 글(이라기 보다는 그냥 나 같지만)에 대해 쓴 오래된 글 하나를 발견했다.

맨날 하는 소리가 똑같은 언어 우월주의자.
구체적인 얘기는 못하면서 항상 레파토리는 똑같다.
디자인패턴은, DI는, 머머는 자바가 꾸져서 필요한 것일 뿐이라고.
So what?

글 내용이 아니면 아닌 것이고 토를 타면 토를 달 것이지, 왜 글 내용이 아니라 나에 대한 인신 공격을 한담… 확실히 발견했을 때 좋은 기분은 아니었다. 그리고 여러 생각이 들어서 두서없이 글을 써보려 한다.

나는 프로그래밍 언어를 디자인하는 입장이고 당연히 이미 존재하는 프로그래밍 언어를 잘 쓰자는 쪽으로 생각하기 보다는 다른 사람이 더 좋은 프로그래밍을 할 수 있도록 하는 프로그래밍 언어를 디자인하자는 관점으로 자주 생각하기 때문에, 프로그래밍 언어 자체에 관심이 없는 사람에게는 언어 우월주의자같은 식으로 보일 수도 있을 것 같다. 하지만 디자인 패턴 등이 언어의 부족한 점을 매꾸기 위한 우아해 보이는 workaround라는 생각에는 변함이 없다.

오히려 언어 우월주의자가 아니라면 Java 자체의 문제에 대해 논하는 것을 그런가보다하고 들을 수 있어야 하지 않을까 하는 생각도 든다. 난 비록 Python 등의 언어를 사용하지만 새로 나오는 언어들에 꾸준히 관심을 주고 어느 정도씩은 공부를 한다. 당연히 새로 나온 언어 중에는 비교적 최신의 PL 연구 결과가 반영된 것들도 많고, 그런 것들에서 기존 언어의 문제점을 발견하기도 한다. 내가 주로 쓰는 언어인 Python에서도 마찬가지다. 다만 내가 보기에 Java나 C 등은 너무 낡아서 쓰고싶지 않지만 그러기에는 너무 자주 마주치는 언어이기 때문에 더 많이 말을 하게 되는 것 같다.¹

대체 Java가 뭐가 어때서? 사실 말을 하자면 한도 끝도 없지만, 내 심정을 솔직하게 표현하자면 Java 쓰는 사람들더러 C가 뭐가 어때서?라고 할 때 어디부터 말을 해야 할까라는 생각이 스치면서 약간 무력감을 느끼는 것과 비슷한 느낌일 것이다. C를 잘 쓰는 사람에게는 사실 Java의 장점을 얘기해도 별로 장점으로 들리지 않을 것이다. 내 생각에 Java는 가비지 컬렉션을 한다는 점 하나만으로도 C보다 좋은 언어이고, 반대로 메모리 관리를 직접한다는 것은 기술의 한계지 결코 장점이 되지는 못한다. 메모리 관리를 최대한 자동화한다는 의도는 좋은 것이고, 현실적으로 충분히 똑똑치 못한 것은 프로그래밍 언어의 연구 과제이다. 그렇다고 과거로 돌아가 모두들 행복하게 포인터로 수동 메모리 관리를 하며 좋은 소프트웨어 개발을 합시다 하는 것은 내가 볼 때는 말이 되지 않는다. 게다가 rich한 표준 라이브러리도 존재하고, JVM이라는 세상에서 가장 성숙한 (외계 기술의 종합체인) 가상 머신 구현도 있다. 여러가지를 따져 볼때 C에 비해 Java는 일장일단이 있는 관계가 아니라 십장일단 혹은 백장일단 정도의 관계가 아닐까 싶다.

물론 언제나 리얼 월드에는 수많은 제약이 존재하고 C나 Java를 쓸 수밖에 없는 경우도 많을 것이다. 나도 산업기능요원 했을 적에는 어쩔 수 없이 1년 넘게 PHP로 삽질을 많이 했다. 당연히 PHP도 잘 쓰면 좋은 언어인데, 어떤 도구라도 잘 쓰면 된다는 말은 참 힘이 빠지는 얘기가 아닐 수 없다. 정작 그런 얘기 하는 사람에게 C로 SI 개발 해보라고 하면 질색할 것이 뻔하다. 질색하는 이유는 C보다 Java에 훨씬 익숙하기 때문도 있겠지만, 어떤 언어가 어떤 일에 적합한지 이미 답을 알고 있기 때문일 것이다.

그리고 모든 도구가 그렇듯, 프로그래밍 언어의 발전 역시 범용 프로그래밍에 좀더 적합해지려는 노력이고, 내가 평소 주장하는 바는 Java보다 범용 프로그래밍에 적합한 언어가 분명 많이 존재한다는 것이다. 모든 프로그래밍에는 common pattern이 많고² 그것들을 좀더 효율적으로 해낼 수 있으면 대체적으로 좀더 좋은 프로그래밍 언어라고 할 수 있는 것이다.

IoC 얘기만 해도 사실 이건 말 그대로 subroutine 관계에 있어서 호출자와 호출 대상을 역전시키는 패턴인데, subroutine은 스택을 가정한 흐름이고 호출이 끝나면 원래 위치로 되돌아간다는 특성 때문에, subroutine만 지원하는 언어에서는 딱히 다른 방도가 없다. 하지만 이걸 모든 프로그래밍 언어에 공통적으로 필요한 패턴으로 보기에는 조금 곤란하다. 그야 GUI 툴킷을 C/Java 등으로 만들 때는 메인 룹이 필요하고 subroutine 관계에서는 IoC 써야 하지만, coroutine이나 하다못해 Python의 generator 같은 것이라도 있으면 IoC를 도입하지 않고 좀더 직관적인 형태로 디자인할 수도 있다.³ Ruby에서 블럭을 쓰는 많은 일들이 Python에서 generator로 해결될 수 있다는 점을 생각해보자. (소싯적에 썼던 글 참고.) 블럭은 기본적으로 IoC이고 generator는 coroutine의 아주 naive한 구현으로 볼 수 있다.

물론 IoC가 필요한 때가 있고, Java 같은 언어를 쓴다면 IoC가 필요하지만 그렇다고 IoC가 필요 없는 프로그래밍 언어가 있느냐고 확신할 것도 없는 것이다. 그리고 IoC가 좋으면 계속 그걸 써도 되고 coroutine이 뭔지 generator가 뭔지 딱히 궁금해하지 않아도 된다. C 개발자가 가비지 컬렉션에 관심 없고 malloc/free 여전히 잘 쓰고 있으니 그 방식으로 프로그램 잘 만드는 거랑 비슷하겠다.

하지만 분명히 프로그래밍 언어의 발전이라는 것은 엄연히 존재하는 건데, 언어 우월주의자라고 욕하는 것은 좀 억울하다. 대부분의 사람들이 도구는 잘 쓰면 그만이라고 생각하고 장인은 도구를 가리지 않는다는 말을 과대 해석하고 misquote하는 세상에서 나 같이 생각하고 사는 사람은 역시 좀 피곤한 것 같다.

마지막으로 나도 misquote 좀 한번 해보자. Henry Ford의 말이다.

If I’d listened to customers, I’d have given them a faster horse.

비유하자면 디자인 패턴은 말을 빠르게 하는 것이다. 좋은 승마법 혹은 말을 잘 키우는 방법이다. 프로그래밍 언어 자체를 변화시키려는 노력은 운송 방식 자체를 개선하려는 의지이고, 언젠가는 차나 나아가 우리가 아직 상상하지 못하는 새로운 운송 방법을 찾아낼 수 있는 가능성이다.