8. 타입은 약속이다

해외여행을 가면 흔히 “돼지코”라고 부르는 멀티 어댑터를 챙긴다. 국내에서 쓰던 플러그는 모양이 달라 현지 콘센트에 그대로 꽂히지 않는다. 어댑터를 끼우는 순간 모양이 맞아떨어지고, 그제야 플러그는 콘센트에 안착한다. 이 순간 우리가 확인한 것은 콘센트 안쪽에서 정말 필요한 전력이 안정적으로 나오는가가 아니라, 오직 플러그와 구멍의 모양이 서로 맞는가뿐이다.

이 모양의 일치는 사실 약속이다. 이 모양의 구멍을 가진 플러그와 콘센트는 서로 연결될 수 있다는 약속이다. 그 뒤에서 어떤 회로가 동작하는지는 이 규격이 다루지 않는다. 우리는 콘센트를 뜯어서 내부 배선을 확인하지 않는다. 모양만 맞으면 그 뒤의 복잡한 배선은 신경 쓰지 않아도 된다는 것이 표준 규격이 우리에게 해 주는 일이다.

프로그래밍에서 타입이 하는 일도 똑같다. 7장에서 getUser()와 getCompany()를 이어 붙일 수 있었던 이유는 getUser()가 돌려주는 값의 타입이 User이고, getCompany()가 받아들이는 값의 타입도 User였기 때문이다. 컴파일러는 두 함수를 실제로 실행해 보지 않고도 오직 타입이라는 모양표만 대조해서 이 둘이 이어 붙을 수 있는지를 미리 판단한다. 타입은 함수가 무엇을 돌려주고 무엇을 받아들이겠다고 미리 걸어 두는 약속이다.

이 약속에는 한계도 있다. 어댑터는 플러그 모양만 바꿔 줄 뿐, 콘센트 뒤편에서 실제로 어떤 전력이 나오는지까지 보장해 주지는 않는다. 모양이 맞는 어댑터를 꽂았는데도 현지 전력 사정이 불안정해 기기가 오작동하는 경우는 드물지 않다. 타입도 마찬가지다. getCompany()가 User 타입을 받아 회사를 돌려준다고 약속했다 해도, 그 함수 내부에 엉뚱한 회사를 돌려주는 버그가 숨어 있을 수 있다. 타입은 모양이 맞는다는 것만 보장할 뿐, 그 안에서 일어나는 일이 우리가 기대한 의미와 정확히 같다는 것까지 보장하지는 않는다.

그럼에도 이 약속은 값을 가진다. 타입이 없었다면 함수를 이어 붙일 때마다 그 함수 내부를 열어서 정말 원하는 값을 돌려주는지 매번 확인해야 했을 것이다. 타입 덕분에 우리는 내부를 들여다보지 않고도 겉모습만 맞으면 안심하고 이어 붙일 수 있다. 이것은 정직함의 문제가 아니라 효율의 문제다. 모든 것을 매번 열어서 확인하려 들면 아무 일도 진행되지 않는다.

그런데 왜 우리는 내부를 보지 않아도 괜찮은 걸까. 무엇을 포기했기에 이런 편리함을 얻을 수 있었을까. 다음 화에서는 이 감춤, 즉 추상화가 무엇을 버리고 무엇을 남기는지 살펴본다.