동적 타이핑과 정적 타이핑에 대한 개인적인 생각

나는 나 자신을 간서치라고 생각한다.

기술적인 서적을 어제 밤에도 읽었고, 오늘도 읽을 것이지만 항상 '이것이 정말 도움이 되는 것일까' 라는 생각을 한다.

물론 도움이 될 것이지만 확신하지 않으려고 노력하고 매몰되지 않으려고 노력한다.

나는 기본적으로 자바를 사용했지만, 현재까지 사용한 언어들을 보면 Java, Javascript, Python, Clojure 정도가 현업에서 실제로 사용한 언어이며 가끔 읽는 책에 구현된 언어들을 이해하기 위해서 문법을 익혀본 것은 Scala, Golang, Scheme, Common Lisp 등으로 더 많다. (그리고 다른 개발자들도 동일할 것이다. 우린 공부하고 쓰지 않는 기술들이 많다.)

난 논의를 좋아하고 이것으로 하여금 진리를 향해간다고 생각한다. 하지만 여러 논의 중에서 별말을 하지 않는 것 중에 타이핑 문제가 있다.

• A(동적타이핑 옹호자)는 사람들은 소위 '타입'을 맞추는 것이 아니라 만드는 것이 중요하다고 말한다.
• B(정적타이핑 옹호자)는 '타입'을 맞추지 않으면 해당 함수가 무엇을 하는지 확신할 수 없다고 말한다.

여기서 B는 정적타이핑이면서 강타입언어를 사용중이라고 해보자. 계속 이야기를 이어가면

A : 타입이 중요한 것이 아니다. 그저 프로그램이 동작하는 것은 테스트로도 증명할 수 있다.
B : 테스트로 증명할 필요 없이 타입을 지정하면 되지 않나?
A : 왜냐하면 내가 테스트할 것은 리턴하는 값이지 타입이 아니기 때문이다.
    나는 내가 리턴하는 값을 어떤 타입으로 계속 추가하는 것은 복잡도가 늘어날 것 같다.
B : 하지만 적지 않는다고 타입이 없는 것은 아니다. 
    예를들어 해시맵에 프로퍼티가 하나 추가되었다고, 그것이 int가 되는 것은 아니지 않냐.
A : 맞다. 특정 함수를 수행해서 해시맵에 프로퍼티가 추가되었다고 int가 되는 것은 아니다. 
    하지만 함수형 프로그래밍을 하는 입장으로 하나의 함수를 지나갈 때마다 계속 타입이 추가된다면
    이건 안정적으로 보이기만 할 뿐. 이건 개발을 하는 게 아니라 타입맞추기 레고게임을 하는 거다.
B : 하지만 그게 안정성이라는 것이다. 
    우리는 제대로 하긴 쉽지 않지만, 제대로 할 수 있다. 
A : 동적타이핑도 제대로 할 수 있다. 
    이건 타이핑과는 상관없는 일이다. 고작 해주는 건 자동완성기능으로 도움을 받기 쉽다는 것이다.
B : 또 컴파일러로 미리 실패할 수 있다.
A : 우리도 돌려보면 바로 실패를 알 수 있다. 
    그리고 정적타이핑과 동적타이핑이 겪는 버그나 문제는 서로 동일하다.
    의외의 null값이 온다든가, 잘못된 타입이 오던가. 이것들은 동적/정적이건 상관없이 겪는 일이다.
B : 정적 타이핑은 Nullable 여부를 타입으로 지정할 수 있다. 
A : 종종 일어나는 버그를 예로 들자면
    특정 API에서 값을 가져오는데 null이 아니어야 하는데 null인 경우가 있다.
    GraphQL 스키마상 그것은 널이 아니어야 하지만 null이 왔다면
    그 타입은 어떻게 되는가?
B : 애초에 null이 오면 안 되는 것 아닌가?
A : 맞다. 하지만 바깥 세상은 그런 일이 꽤나 자주 일어난다. 공공 API 건 뭐건 돌려보면 값이 다른 수가 있다.
    이 경우에 그저 null이 오면 안 된다고 말할 것인가 아니면 방어코드를 만들어낼 것인가
    당연히 방어코드를 만들 것이다. 
    여기서 말하고자 하는 점은 타입이 있어서 안전하다는 건 
    안에 있는 코드뿐이고, 바깥과 만나는 부분은 전혀 안전하지 않다는 것이다.
    대부분 에러는 그런 곳에서 생긴다는 것을 지적하고 싶다.
B : 그렇다면 동적타이핑은 바깥만 아니라 내부코드도 안전하지 않다는 것이다. 
    바깥이 안전하지 않다고 내부코드도 안전하지 않게 관리하는 것은 옳지 않다.
A : 단순히 컴파일만 시도하고 실행하지 않는 코드를 만든다면 당신의 말을 옳다.
    이런 순서의 차이가 그저 런타임에 알 수 있다는 점만 다르다.
    우리는 실행할 코드를 만들기 때문에 타입은 쉽게 확인할 수 있다.
B : 그것을 미리 하면 더 안전하지 않는가
...

이런 이야기가 아예 의미 없다는 것이 아니다. 서로 이해하고 시야를 넓히는 것은 참으로 중요하다. 하지만 이 논쟁은 끝이 나지 않고 있다. 이 논쟁은 누군가 끝낼 수 있는 성격이 아닌 것 같다. 우리가 개발하는 환경이 바뀌면 달라질까? 난 아니라고 본다. 개발자의 선호에 따라 언어를 선택한다는 것이 나의 생각이다.

그 이유는 어떤 대수적이나 과학적인 이유가 아니고 지극히 경험적 이슈일 확률이 높다. 현명한 사람은 고민해도 해결되지 않는 것을 고민하지 않는 것이라고 한다. 나는 이 문제를 크게 고민하지 않기로 했다.

나는 개인적으로 외부로직과 직접 연결된 코드에는 타입체크가 강하지 않고, 정적이지 않았으면 싶으며 주요 내부 도메인에는 강한 타입을 내세워서 좀 더 견고해 보이도록 만드는 것이 옳지 않을까 싶다.

이것은 어디까지나 내 주장이다. '더는 싸우지 말고 함께 상생하기 할 수 있을까?' 라는 나의 염원이 포함되어 있기에 합리적인 결론은 아닐 것이다.