정적 타입 시스템의 인기가 왜 한동안 줄었다가 다시 높아졌는지에 대한 간단한 이론: 문제는 유행이 아니라 널 처리, 합 타입, 타입 추론 같은 기능을 갖춘 타입 시스템의 품질이었다.
HomeC.V.Blog postsContactPrevious post: 연결 풀은 연결 오류를 전파해야 한다 저는 정적 타이핑이 2000년대부터 2010년대 초반까지 훨씬 덜 인기 있었고, 2010년대 중후반쯤부터 다시 더 인기를 얻기 시작한 이유에 대해 간단한 이론을 가지고 있습니다. 그 이유는 프로그래밍이 유행이 이끄는 산업이기 때문이 아니라, 널리 이용 가능했던 정적 타입 시스템의 품질이 향상되었기 때문입니다.
비유를 하나 들어보겠습니다. 구멍을 파고 싶다면 삽과 맨손 중 무엇을 쓰겠습니까? 삽이 쓸 만하기만 하다면 당연히 삽을 쓸 것입니다. 하지만 여러분이 사용할 수 있는 유일한 삽이 종이로 만들어졌다면 어떨까요? 그러면 그걸로는 땅을 쓸데없이 휘저을 뿐입니다. 차라리 맨손으로 파는 편이 낫습니다.
동적 타입 시스템에서는 프로그램 안의 변수와 필드의 상태와 내용에 대한 모든 생각을 여러분이 직접, 자신의 머리로 해야 합니다. 컴퓨터는 전혀 도와주지 않지만, 그렇다고 방해하지도 않습니다. 이것은 맨손으로 파는 것에 비슷합니다.
반면 90년대와 2000년대 초반에 인기 있었던 초기 Java나 C++98 같은 형편없는 정적 타입 시스템을 받으면, 그것은 종이 삽과 비슷합니다. 이런 정적 타입 시스템은 nullable 포인터와 non-nullable 포인터를 구분하는 것 같은 단순한 일조차 제대로 도와주지 못합니다. 합 타입은 없고 곱 타입만 있습니다. 그러면서도 온갖 곳에 타입 이름을 손수 길게 써 넣는 데 많은 노력을 들이게 만듭니다.
BufferedReader bufferedReader = new BufferedReader(new
FileReader(filename));
는 작은 재앙입니다.
반면 90년대와 2000년대 초반에 인기 있었던 초기 Java나 C++98 같은 형편없는 정적 타입 시스템을 받으면, 그것은 종이로 만든 삽을 건네받는 것과 비슷합니다. 이런 정적 타입 시스템은 큰 비용을 강요하면서도 단순한 일조차 제대로 도와주지 못합니다. nullable 포인터와 non-nullable 포인터를 구분하지 못합니다. 합 타입(태그된 유니온 또는 판별 유니온이라고도 부릅니다)은 없고, 곱 타입(구조체 같은 것)만 있습니다. 그러면서도 온갖 곳에 타입 이름을 손수 길게 써 넣는 데 많은 노력을 쏟게 합니다. 좋은 타입 시스템이라면 대부분의 변수 타입을 그냥 추론해 줄 텐데, BufferedReader bf = new BufferedReader(new FileReader("input.txt")); 같은 것을 써 넣는 데 머리와 노력을 쓰는 것은 낭비입니다.
이를 TypeScript, Haskell, MyPy, Swift, Rust 같은 현대적 타입 시스템과 비교하면, 항상 다음과 같은 것을 얻게 됩니다:
Maybe t가 있습니다. TypeScript에는 T | null이 있습니다. Swift에는 T?가 있습니다. Rust에는 Optional<T>가 있습니다. 타입 시스템은 어디에 null 체크가 필요한지, 그리고 무엇을 빠뜨렸는지를 쉽게 알려줄 수 있습니다. 실제로는 실행 중 null 포인터 오류를 거의 보지 않게 됩니다.let x = 5;가 분명 숫자라고 그냥 알아낼 수 있는데, 우리는 let x: number = 5;를 쓸 필요가 없습니다.정적 타입 시스템이 더 유용해지게 만든 또 다른 요소는 메서드 이름 자동완성 같은 IDE 기능이 더 널리 퍼졌다는 점입니다. 90년대에는 Visual Studio의 Intellisense가 킬러 기능이었지만, 2020년대에는 비슷한 기능이 거의 모든 IDE와 에디터에서 उपलब्ध합니다. 따라서 정적 타입 시스템에 넣어 둔 정보는 프로그램 오류 검사의 유용성과는 별개로, 추가적인 생산성 이점까지 만들어 냅니다.
결론적으로:
© Copyright 2026 Richard Barrell