2004년 12월에 Bruce Eckel의 Strong Typing vs. Strong Testing을 읽고 다음과 같은 글을 쓴 적이 있다.

컴파일 타임에 최대한 많은 에러 체크를 해주는 Strong Typing이 프로그래머의 생산성 향상에 큰 도움을 준다고 많은프로그래머들이 믿는다. Eckel은 이런 관점에 의문을 던지며 Weak Typing 언어라도 Unit Testing을 강화하면프로그래머의 생산성 향상에 도움을 주며 크고 복잡한 소프트웨어를 충분히 설계할 수 있다고 역설한다.

StrongTyping 언어의 컴파일 타임 에러 체크라는 것도 결국 소프트웨어 테스트의 일부분일 뿐이고 이것만으로 프로그램의 정확성을보장할 수 없다. 또 Weak Typing 언어는 컴파일 타임의 에러 체크를 하지 않는 대신 런타임 에러 체크가 강화 되었다.결국 Strong이든 Weak이든 프로그램의 정확성을 보장하기 위해서는 많은 Unit Test Case를 만들어야하고, WeakTyping 언어가 오히려 빨리 정확한 Unit Test Case를 만들기 유리할 수도 있단 거다.

일례로 파이썬과같이 빠른 속도로 프로토타이핑 할 수 있는 언어의 경우 개발 시간을 단축하고 단축된 시간을 이용해 더 많은 Unit TestCase를 짜면 컴파일 타임 에러 체크가 없다는 단점에도 불구하고 프로그램의 기능을 좀 더 명확히 검증할 수 있다는 것이다.

일단 Eckel도 지적했듯이 제목을 “Static Checking vs Strong Testing”으로 바로 잡아야 한다. 컴파일 타임에 타입 검사를 하느냐 아니냐가 기준이 되기 때문이다.

그 당시에는 Eckel의 말이 그럴듯한 논리라고 생각했으나 2년의 시간이 지나고 나서 내 생각에도 많은 변화가 있었다. 특히 과제 연구로 프로그램 분석(program analysis) 쪽을 공부하면서 Eckel의 이런 주장에 대해 프로그래밍 언어 학계는 냉담하다는 사실을 알았다.

프로그래밍 언어 연구는 거의 대부분 좀 더 정교한 타입 시스템을 도입해서 프로그램을 실행해 보기 전에 여러가지 특성(property)을 보장하는데 목표를 두고 있다. 일례로 Race Free Java의 경우 타입 시스템으로 레이스 컨디션(race condition)이 없음을 컴파일 타임에 보장한다.

이런 학계의 경향과는 정반대로 일부 스크립트 언어의 성공으로 상당수의 개발자는 정적 타입 검사가 없는 언어가 생산성이 좋기 때문에 절약한 시간으로 더 많이 테스트할 수 있고 정적 타입 검사하는 프로그래밍 언어만큼 안정적일 수 있다고 생각하고 있다. 실제로 Eckel이 정적 타입 검사 없이도 성공적으로 크고 복잡한 프로그램을 만들 수 있다는 증거로 든 것이 파이썬의 성공이다.

하지만 이런 주장에는 상당한 무리가 있어 보인다. 정적 타입 검사가 모든 가능성을 점검하는 연역적인 검사인데 비해서, 테스트는 귀납적인 접근 방식이기 때문이다. 모든 가능한 타입에 대해서 테스트 케이스를 작성한다는 것은 비효율적이고, 컴포넌트 통합(integration)에 문제를 일으킬 여지가 많다.

또한 정적 타입 검사가 없으면 런타임에 상당한 오버헤드가 생긴다.예를 들어 파이썬과 동적 타입 체크 언어(사실상 untyped 언어)는 메쏘드를 콜 할 때마다 해당 메쏘드가 해당 오브젝트에 정의되어있는지를 확인하고 아니면 런타임 에러를 발생시켜야한다. C/C++의 경우 바이너리를 링크할 때 이미 알 수 있었을 문제이다. 이런 차이는 수행 속도에 큰 영향을 미친다.

파이썬의 성공은 정적 타입 검사의 부재 때문에 가능했던 것이 아니라 정적 타입 검사의 부재에도 불구하고, 다른 여러가지 요소가 복합되어서 이루어진 것이라고 결론을 내는 것이 맞는 것 같다.