1장 타입 검사 훑어보기

[fkdl0048]

타입 검사 훑어보기

타입 검사의 정의와 필요성

타입 검사가 불편함에도 필요한 이유는 버그 때문이다. 버그 중에서도 가장 흔하며 많이 발생하는 오류는 타입 오류이기에 저자는 타입 검사가 필요하다고 말하고 있다. 프로그램을 실행하며 버그(타입 오류)를 검사하는 방법에는 분명한 한계가 있기에 이미 작성된 코드를 잘 활용해야 한다.

따라서 사람들은 코드를 입력받아 프로그램이 타입오류를 일으키는지 자동으로 판단해 주는 프로그램인 타입 검사기를 사용한다.

• 이상적인 타입 검사기: 주어진 프로그램이 타입 오류를 일으키지 않는다면 통과, 타입 오류를 일으키는 경우의 수가 단 하나라도 있다면 거부(오류 메시지)
• 현실적인 타입 검사기: 오류를 일으키는 경우의 수가 단 하나라도 있다면 거부, 주어진 프로그램이 타입 오류를 일으키지 않는다면 통과 + 간혹 가다 거부를 내는 경우도 있다.

이상적인 타입 검사기는 절대 만들 수 없다는 사실이 논리적으로 이미 증명되었다.

현실적인 타입 검사기로도 충분히 유용하다. 그 이유는 타입 안정성(type safety)를 보장하기 때문이다. 만약 타입 검사기에서 통과를 준다면 이는 타입 오류가 없음을 확신할 수 있다. 거부인 경우에는 타입 오류가 없음에도 나올 수 있지만 오류 메시지로 정보를 주기 때문에 개발자가 판단할 수 있다.

이처럼 타입 검사기는 프로그램에서 가장 흔하게 발생하는 (인간이 실수하는 영역)에서 아주 쉽게 버그를 찾아준다. 약간의 불편함이 있기는 하지만 불편함보다 더 큰 가치를 가지는 사례이다.

정적 타입 언어

타입 검사기는 대부분 해당 언어를 만든 사람들이 제작한다. 개발자는 타입 검사기를 통해 자신의 프로그램이 타입 오류를 일으킬 수 있는지만 확인하면 된다. C, C++, C#모두 정적 타입 언어에 해당한다.

정적이라는 단어는 프로그램이 시작하기 전에라는 뜻으로 타입이 올바르게 사용되었는지 확인하는 언어이다. 실행 중에 타입 오류가 절대 일어나지 않는다는 보장과 함께 프로그램이 타입 검사를 통과하지 못하면 언어가 실행되지 않는다.

반대로 동적 타입 언어는 타입 검사기를 제공하지 않는다. 검사기가 없으니 프로그램을 실행하기 전에 타입 검사를 해 볼 수 없다. 정적과 반대의 의미로 프로그램을 실행하는 중에라는 뜻이다.

타입 검사의 원리

타입 검사기의 오류 메시지를 이해하기 위해선 어떻게 작동하는지 알아야 한다. 저자는 쉽게 이해할 수 있도록 자동차 조립 순서에 빗대어 타입 검사 과정을 설명한다. 쉽게 일을 처리하기 위해 더 작은 단위로 나누어 처리하는 것과 같은 원리로 프로그램에서 다루는 단위인 타입을 하나로 바라볼 수 있을 때 까지 분할 후 병합하는 과정을 재귀적으로 거친다. 병합 정렬과 유사한 방식이다.

가장 기본이 되는 이러한 이론을 처음 코딩을 배울 땐 얇고 가볍게 이해했다면 이런 당연한 흐름도 컴퓨터의 동작 원리를 바라봐야 함을 많이 깨닫게 되는 것 같다.

책에서는 타입 검사의 원리를 수학적 증명을 하듯 리터럴, 함수, 삼항연산자 등의 경우로 설명한다.

타입 검사 결과의 활용

앞서 다룬 정적 타입 언어의 장점인 타입 오류를 찾을 수 있다는 점과 오류 메시지로 빠르게 수정가능하다는 점 말고도 정적 타입 언어의 장점은 두 가지 더 있다. 첫 째는 코드 편집기의 유용함이며, 두 번째는 프로그램 성능이다.

코드 편집기는 동적 타입 언어도 지원하긴 하지만 정적 타입 언어에서 더욱 더 유용하다. 자동 완성의 기능만 봐도 타입 검사의 도움을 받아 개발자가 처리해야 하는 정보의 양이 확 줄어든다. 타입 검사기가 프로그램에 대한 각 부품에 대한 탕비을 알아내기에 이를 활용한다. 또한, 리팩터링 과정에서도 앞서 말한 코드 검사기의 이점으로 수정이 편리하다. (정적 타입 한정)

프로그램 성능이 뛰어나다는 것은 결국 프로그램 실행 시간이 짧다는 것을 의미한다. 쉽게 생각하여 add()함수의 경우 동적 타입은 해당 타입이 일치하는지 확인해야 하지만 정적 타입은 이미 타입이 일치함을 알고 있기에 더 빠르게 실행된다. 결국은 트레이드 오프다.

타입 추론

정적 타입 언어가 동적 언어 타입보다 불편한 점은 앞서 다룬 이점들로 인해 타입을 개발자가 직접 표시해야 한다는 점이다. 이러한 단점을 개선하고자 등장한 추론 타입은 정적 타입 언어에서 많이 활용되고 있다. 다만 추론 타입이 사용되면 유용한 지점과 안되는 지점을 명확하게 구분하는 능력이 필요하다.

function readfile(file) {...}이런 코드를 개발자가 본다면 이름을 보고 쉽게 이해는 가능하지만, 인자로 넘겨야 하는 값이 뭔지 알 수 없다. 특정 파일을 나타내는 타입의 값인지, 파일 시스템의 경로를 나타내는 값인지 알 수 없다. 따라서 이런 경우에는 명확하게 타입 표시를 해주는 것이 좋다.

주석이라는 방법이 있지만, 주석은 틀릴 수 있다는 단점이 있다.(주석은 타입을 검사하지 않음, 문서화는 실제 코드를 못 따라감 대부분) 타입 표시는 이러한 단점이 없고 그 자체로 문서화라고 할 수 있다. '절대로 낡지 않는 주석'

반대로 타입 추론이 좋은 경우에는 사용자 정의 타입이 길어 오히려 정보의 과부화를 주는 경우나 타입이 네이밍으로 명확한 경우 등에 해당될 것 같다. C#의 경우 IL에서 실제 타입으로 치환되니 이러한 경우에는 추론을 사용하는 것이 좋다. 타입 추론의 좋은 점은 개발자가 타입 추론의 원리를 이해하지 않고도 혜택을 누릴 수 있다는 점이다.

정적 타입에서 타입 표시는 양날의 검이다. 타입 표시를 모든 곳에 붙였다가는 코드가 너무 장황해지기 십상이다. 그렇다고 모든 타입을 추론이 허용하는 범위 안에서 다 사용하는 것도 올바르지 않다. 이는 항상 트레이드 오프를 생각하며 사용하는 지혜가 필요하다.

• Effective C#: 지역변수를 선언할 때는 var를 사용하는 것이 낫다.

더 세밀한 타입

더 세밀한 타입이란 기존 타입보다 더 세밀하게 분류된 타입을 말하는 것으로 세밀하게 분류될수록 버그를 차단하기 쉬워진다고 말한다. 0으로 나누거나 null을 참조하는 등의 오류를 방지할 수 있다. 이는 null을 타입으로 분류하는 언어와 그렇지 않은 언어에서 해당 에러를 어떻게 분류하는지를 참고하면 알 수 있다.

그렇다고 세밀한 타입이 항상 좋은 것은 아니다. 세밀한 타입은 개발자의 편의성과 연관성이 있기 때문에 세밀하게 분류할수록 사용에 불편함을 겪는다. 이는 일종의 균형 잡기, 트레이드 오프의 문제이다.

정적 타입 언어의 장단점

정적 타입 언어의 장점만 다룬 것 같지만 장점만 있었다면 동적 타입 언어가 존재할 필요가 없었을 것이다. 정적 타입 언어는 타입 오류를 찾을 수 있고, 생산성을 높이기에도 좋으며 성능적으로도 유리하다. 다만 타입 표시라는 양날의 검과 타입 검사기의 '거부'가 틀릴 가능성이 있다는 것이다.

이를 종합하면 동적 타입 언어와 정적 타입 언어가 언제 유용한지 알 수 있다. 정적 타입 언어는 큰 프로그램에 적합하다. 프로그램이 크면 코드가 커지고 버그가 많이 발생하니 찾기 어렵다. 코드가 길어 이해하거나 수정하기도 쉽지 않다. 따라서 타입 오류를 찾고 코드 편집기의 능력을 최대로 이끌어내는 정적 타입 언어가 최적인 것이다.

반면 이러한 복잡한 실험실은 작은 프로그램을 만들 때는 쓸모가 없다. 작은 프로그램은 버그도 적고, 금방 만들 수 있으며 코드도 간단하다. 오히려 타입 표시를 붙이거나 제대로 짰지만 타입 검사에 걸려 시간을 낭비한다. 따라서 작은 프로그램을 만들 때는 동적 타입 언어가 적합하다.

다형성

정적 타입 언어의 단점인 타입 검사기가 거부라고 틀리게 말하는 경우는 절대로 완벽하게 해결할 수 없다. 따라서 거부라고 잘못 말하는 가능성을 줄이는 방법이 필요하다. 그 방법 중 안전하며 대부분을 커버하는 방법이 다형성이다.

다형성은 프로그램의 한 개체가 여러 타입에 속하게 만든다. 여기서 개체라 함은 값, 함수, 클래스, 메서드 등 여러 가지가 될 수 있다. 하나의 값이 여러 타입에 속할 수도 있고, 한 함수를 여러 타입의 함수로 사용할 수 있다는 것이다.

다형성은 거의 모든 정적 타입 언어에서 발견할 수 있는 매우 널리 사용되는 개념으로 타입 안정성을 해치지 않으면서도 타입 검사기의 오판을 획기적으로 줄이며, 동시에 개발자가 쉽게 이해할 수 있는 오류 메시지를 제공하기 때문이다. (코드의 양도 줄여준다.)

정리

처음 책을 구매하고 표지와 제목을 봤을 땐, 단순하게 객체지향에 관한 내용인줄 알았지만, 1장을 읽고 좀 생각을 해보니 좀 더 넒은 의미의 프로그램에 관한 내용이라는 생각이 들었다. 표지에 있는 그림은 마치 뜨개질로 촘촘하게 즉, 견고하게 만들어진 방직물이 떠올랐다. 유연하지만 견고한, 높은 기술에 가까이 갈수록 기본기가 중요해지는 생각도 들고 실생활에도 많은 교훈을 주는 말이지 않을 까 싶다.

유연하게 만들기 위해선 더욱 더 견고하게 만들어야 하며, 견고하게 만들기 위해선 유연하게 만들어야 한다. 이러한 두 가지의 상반된 특성을 가진 것이 객체지향이라는 것인가? 라는 생각이 든다.

논의사항

• AI의 도움으로 책에서 다루는 정적 타입 언어의 장점에서 속도를 제외한다면 대부분 동적 언어에서도 해결할 수 있지 않을까? 라는 생각이 듭니다. 대부분이 휴먼 에러에 가깝다는 생각이 드는데 이런 것들은 AI도움이면 대부분 해결이 가능하지 않을까요? 다른 분들의 생각이 궁금합니다!