켄트 벡의 오리사냥 – Optimistic Typing

멋쟁이 켄트 벡님께서 Duck Hunt라는 글을 올리셨다. Ruby와 같이 Dynamic Typing 언어에는 Duck Typing이라는 개념이 있다. 다음의 말로 흔히 설명되는, 타입을 인식하는 방식이다.

If it walks like a duck and quacks like a duck, I would call it a duck.

Duck Typing을 사용하면 어떤 클래스나 인터페이스 타입의 오브젝트인지에 상관없이 호출되는 메소드가 해당 오브젝트에 존재하기만 하면 그냥 사용할 수 있다. 어떤 것이 오리처럼 말하고 행동하면 그 실체가 뭐든 상관하지 않고 그것을 오리라고 취급하겠다는 것이다.

내가 처음 이 개념을 들었을 때는 이런 어이없는 개념이 뭐가 좋다는 것일까라고 의아는데, Ruby 테스트 코드에서 이것을 가지고 mock을 만든는 것을 보고 바로 반해버렸다. 자바와 같은 Static Typing 언어에서는 stub이나 mock object를 만들기 위해서는 mock과 실제 사용할 오브젝트가 같은 인터페이스를 구현해야 한다. 인터페이스를 통한 다형성을 활용해서 테스트 목적으로 특별히 준비된 객체를 실제인 것마냥 사용할 수 있다. 하지만 이게 불편한 점이 있는데, 때로는 인터페이스 내에 메소드가 워낙 많아서 그것을 빈 메소드로라도 다 구현하는 것이 번거롭기 때문이다. 테스트에서는 딱 한개의 메소드만 필요할 때도 모든 인터페이스를 다 구현해야 한다. 비록 IDE의 도움으로 쉽게 인터페이스의 구현 클래스를 찍어낼 수 있기는 하지만, 그 늘어선 긴 메소드들을 보는 것은 별로 유쾌한 일이 아니다.

반면에 Ruby에서는 그 mock에서 호출되어서 실제 객체처럼 동작해줄 그 메소드만 정의되면 어떤 객체든 mock처럼 사용할 수 있다. 미리 타입을 체크하고 확인하지 않고, 일단 호출하고 보는 Ruby에서는 그것이 자연스럽게 가능하다. 그래서 mock을 만들기가 정말 쉽다.

물론 자바도 매번 모든 인터페이스의 메소드를 다 구현하지 않고, 필요한 메소드의 동작만을 넣도록 할 수 있는 다양한 stub/mock 라이브러리가 존재한다. 심지어는 검증 기능까지 포함되어 있기 때문에 테스트에서 사용하기에 편리하다. 하지만 duck typing을 사용하는 Ruby에서는 그런 라이브리러 조차 필요가 없다. 그래서 테스트 코드가 매우 직관적이다.

심지어는 미리 정의되지 않은 메소드의 호출도 다이나믹하게 처리하는 기능도 가능하다. 메소드 호출이 스태틱한 호출이 아니라, 말그대로 다이나믹한 메시지 전달이라는 개념으로 처리가 되기 때문에 가능한 개념이다. (요즘 사용하는 php5에서도 overloading이라는 개념으로 비슷한 기능을 만들 수가 있다)

반대로 이런 다이나믹한 타이핑 개념은 개발자의 부주의나 실수를 사전에 검증해주지 못한다. 일단 런타임 때까지 타입을 정확히 체크할 방법이 없다. 또한 그것을 쉽게 인식해 낼 수 없기 때문에 IDE와 같은 툴의 지원이 상대적으로 약해진다. 타입체크는 물론이고 자동완성과 같은 기능도 쉽게 만들 수 없다. 로드 존슨이 QCon에서 다이나믹 타이핑 언어와 자바를 비교하는 질문에 대해서 다이나믹 언어가 tooling에 취약점을 가지고 있는데 이 것은 툴에 대한 의존도가 높아지는 엔터프라이즈 개발 등에서는 큰 단점이라고 답변한 적이 있다. 물론 Ruby같은 경우는 단위테스트를 통한 타입추측 기법(과연 개발자들이 충분한 테스트를 만들기는 하는지 의문이지만)과 같은 방법을 연구하고 있기도 하지만, 여전히 그 점에서는 불편한 것은 사실이다. Duck typing 방식에 대해서 생각해보자면, 유사한 이름으 가진 메소드가 있는 다른 객체를 잘못 호출했을 경우(오타 또는 실수로 인해서 엉뚱한 것을 호출하게 될 가능성이 충분히 있다) 런타임 시에도 쉽게 확인이 되지 않아서 매우 찾기 힘든 버그를 만들어낼 가능성도 있다.

어쨌든 이런 재밌는 duck typing이라는 용어에 대해서 켄트 벡은 처음 듣는 사람에게 복잡한 설명이 필요로 하는 불친절한 언어라는 인상을 받은 것 같다. 그래서 좀 더 직관적이고 빠르게 설명이 가능한 Optimistic Typing이라는 용어를 제안했다. 마치 CVS나 SVN과 같은 optimistic 방식의 SCM이나 하이버네이트의 optimistic locking 처럼, 일단 낙관적으로 또는 긍정적으로 생각하고 호출하고 보는 방법을 설명하기에는 괜찮은 용어라고 생각된다. 적어도 duck typing을 처음 들었을 때같은 당황스러움은 없지 않을까 싶어서 나아보이기는 하는데… 과연 이 용어가 널리 사용되게 될지는 모르겠다.

켄트 벡의 글을 읽다가 떠오른 용어가 있다.

"아니면 말고 타이핑".

일단 호출해보고 아님 말고… 너무 무책임하게 느껴지는 말인가.

Related posts:

1. Ruby를 공부하면서…