간혹 JavaScript같은 동적 타이핑 언어들이 타입을 명시하지 않아도 되기에, 타이핑을 절약해 생산성 향상을 도모할 수 있다는 글을 봅니다.
글쎄요, 아주 작은 규모의 프로그램이라면 모르겠지만, 규모가 조금만 커져도 이 말은 헛소리가 되고 맙니다. 이러한 형식 미지정 언어 기능은 타이핑 시간은 줄여주겠지만, 코드만으로 필요한 형식을 알 수 없게 되기에 타이핑이 끝난 그 순간부터 고통이 시작됩니다.
다음 코드를 보아 주세요.
var queryAboutSomething = function(server, dataToFill, optionByCustomer) { //... }
인수들이 어떤 타입이어야 하는지 알 수 있나요? 이 함수를 호출하기 위해서는 어떤 개체들을 준비해야 하나요? 제대로된 타입의 개체를 넣지 않으면 함수는 오류를 내고 뻗어버립니다. 아무거나 넣으면 알아서 처리해주는 매직 함수를 작성할 수도 있겠지만, 그러면 인수를 검사하는 코드가 본문보다 길어질 것입니다.
이 인수들의 타입을 알아내기 위해서는 함수 전체를 리뷰해야 합니다. 그래서 결국 타입 정보를 주석이나 문서에 써넣게 되는데, 이런 주석은 코드와 동기화되지 않은 가능성이 매우 높기에 ‘나쁜 주석’의 표본이 되며, 문서에 있다면 함수를 호출할때마다 문서를 뒤적여야 하기에 생산성은 극도로 떨어지게 됩니다. 형식을 지정하는 어떤 표준적인 방법 또한 없으므로 코드 편집 툴이 자동으로 형식을 알려줄 수 있는 방법 또한 없습니다. 컴파일러나 인터프리터가 인수의 형식을 검사해 잘못된 호출을 자동으로 방지할 수 있을만한 기능도 없습니다. 작성은 편하지만 호출할 때는 몇 배의 시간이 필요합니다. 모든 함수의 인수 형식들을 기억할 수 있는 천재적인 머리를 가지고 있다면 이야기가 좀 다르긴 합니다. 설마 헝가리안 표기법을 생각하고 있는 분은 없겠죠?
제가 보기엔 이런 식으로 형식 정보를 알 수 없는 언어들의 생산성은 기계어보다 나을 것이 없어보입니다.
OCaml 같은 암시적 정적 타이핑의 경우, 자동 완성 기능이 잘 갖춰진 편집기가 있다면 명시적 타이핑과 같은 효과를 누릴 수 있을 겁니다.
생산성의 핵심
생산성의 핵심은 코드를 on-the-fly로 작성할 수 있는지 여부에 달려 있습니다. 코드 작성중에 문서나 헤더, 또는 StackOverflow를 뒤적여야 한다면 이미 생산성은 바닥을 기고 있는 겁니다. 또한, 리팩토링도 중요합니다. 내가 만든 식별자의 이름을 원하는 때에 마음껏 바꿀 수 있다면 이름을 정하느라 고민하지 않고 아무거나 쓴 다음 조금씩 고쳐갈 수 있습니다.
가장 큰 도움이 되는 것은 에디터의 이름 자동 완성 기능입니다. 함수를 호출할 때 타입을 포함한 함수의 시그니쳐가 뜹니다. 이걸 한번 쓱 보고 필요한 개체들을 만들 수 있습니다. 자동 완성 기능은 아주 빠른 레퍼런스 문서의 역할을 합니다. Visual Studio는 이를 극으로 밀어붙여 인텔리센스는 시그니쳐 뿐 아니라 문서 대부분을 바로 보여줍니다. 또한 자동 완성 기능은 타이핑 오타도 없애줍니다. 타이핑하는 순간 자동 완성이 되지 않는다면 정의되지 않은 이름이란 것을 순간적으로 알 수 있습니다.
두번째는 코드가 얼마나 읽기 쉬우냐에 달려 있습니다. 디버깅이든 유지관리든 간에 코드는 한번만에 끝낼 수 없습니다. 어떤식으로든 꾸준한 리뷰가 필요합니다. 리뷰시 인수 검사와 같은 데코레이션 사이에 파묻혀 있는 로직을 찾아내야 한다면 역시 생산성이 추락하고 있는 겁니다. 그래서 코드는 가능한한 필요한 로직만 기술해야 합니다. 어떠한 비-로직 코드가 많이 필요하다면 별도의 메서드로 분리해 읽기 쉽게 만들어야 합니다.
세번째는 강력한 디버거입니다. 런타임에 작동하는 인터랙티브 콘솔이 주어진다면 더 좋겠죠. 물론 이 콘솔은 위에서 언급한 이름 제시 및 완성 기능을 완전히 지원해야 합니다. 만약 메모리 변화가 트랜젝션이 가능해서 이러한 콘솔로 작동한 부분을 롤백시킬 수 있다면 실시간으로 소스코드를 수정하는 것도 가능할 겁니다.
동적 타이핑의 유용성
하지만 동적 타이핑도 유용할 수 있습니다. 아주 작은 규모의 프로그램에서만 말이죠. 함수도 필요없이 단순히 순차적으로 실행되고 끝나는 진짜 ‘프로그램’ 말이죠. HTML에서의 스크립트의 역할이 원래 그런 것이었기에 자바스크립트가 암시적 타이핑 언어가 되었을 겁니다. 함수를 정의하더라도 항상 코드 전체를 리뷰하기에 부담없는 사이즈였겠죠. 하지만 그 이상의 규모에서는 안됩니다. 함수같이 구조를 정의하려면 명시적 타이핑이 반드시 필요합니다. 물론 동적 타이핑보다는 OCaml같은 암시적 정적 타이핑이 훨씬 더 낫습니다.
이런 작은 규모에서 유용함을 지키려면 구조 작성 기능이 없어야 할겁니다. 있어도 최대한 사용을 절제해야겠죠.
글이 마음에 드시나요? 그럼 공유해주세요 :)
동적 타입 언어가 무조건 좋다는 얘기는 아니고, 동적 타입의 가장 큰 장점은 타이핑 절약도 있지만 암시적인 인터페이스(implicit interface)를 사용할 수 있다는 점입니다. 예를 들어 Python에서는
read,write,close메서드를 가진 객체 모두를 파일 객체(file object)라고 부르는데, 실제로 이들의 공통된 수퍼타입(supertype) 혹은 명시적인 인터페이스(explicit interface)는 정의되어 있지 않습니다. 따라서 Python에서 함수 인자에 자료형을 제한하는 기능이 있다고 해도, 파일 객체로 제한할 수는 없을 것입니다. 물론 Java 같은 enterprise-y한 언어에서는 이런 사태 자체가 나쁜 냄새라고 판단하여 “당연히 그런 경우 인터페이스를 먼저 선언하고, 해당하는 클래스들이 그걸 구현하도록 해야겠지”라고 조언할 것입니다. (어느쪽이 옳다 그르다는 따지는 건 아닙니다. 때에 따라 더 유용성이 달라질 것입니다.)실제로 동적 타입 언어 사용자들 사이에서는 함수의 인자에 타입 제한을 두는 것이 그리 유용하지 않다고 보는 시각이 많은 것 같습니다. 대신 잘 작성된 단위 테스트(unit test)나 회귀 테스트(regression test) 등을 통해 테스트 자동화를 하여 품질을 올리는 편이 낫다고 생각하는 것 같습니다.
아, 덧붙이자면 저는 함수 인자에 타입 제한을 거는 것이 분명 필요할 때가 있다고 보고, 그리고 가능하다면 그것이 선택적이면 더 좋다고 생각합니다. Haskell 같은 dependent typed 언어만 봐도 타입 유추(type inference)가 아주 잘 작동함에도 불구하고 완전히 일반적이지는 않은 함수인 경우
::연산자를 통해 타입을 임의적으로 제한하죠.저도 Objective-C를 쓰면서 동적 타이핑 옹호론자가 되어가고 있습니다. 이제는 Java의 제네릭 타입 인자를 쓰는 게 부자연스러워요. 그리고 응용로직에서는 타이핑 절약이 필요하다는 것도 조금씩 느끼고 있구요.
이 글에서 제가 생각했던 부분은 타입의 제한보다는 “언어 문법이 문서 읽기를 줄여줄 수 있는가?”에 관한 것입니다. 문법적으로 보다 많은 제약 조건을 설명할 수 있다면 문서를 볼 필요도 줄어들고 오류를 자동으로 검사하기도 쉽지 않을까 했던 것이죠. 하지만 문서는 제약 조건만 기술하는 것이 아니고, XP의 테스트 주도 방식을 접하면서 또 생각이 달라지고 있습니다.
요즘에는 로우레벨과 하이레벨 언어를 구분하는 것에 대해 좀 더 생각하고 있습니다. 하부 시스템은 실행 성능이 빠르고 명확한 로우레벨 언어로 구축하고, 상층의 응용 로직은 유연하고 작성이 빠른 하이 레벨 언어로 구현해야 한다는 것을 깨달아 가는 중입니다. 하나의 프로그램이라도 덩치가 커지면 하부와 상부가 나뉘어져야 될 것 같더군요.