Humane Interface의 핵심은 사람들이 하고자 하는 것고, 상식적으로 이를 쉽게 그것을 할 수 있도록 인터페이스를 설계하는 것이다.

Humane Interface 는 점진적으로 커지는 경향을 보이는데다가 Humane Interface 에 입각한 인터페이스 설계자는 인터페이스가 커지는 것에 대해서 걱정하지 않는다는 점에서 Minimal Interface와 분명한 대조를 이룬다. 그렇다고 해서 Humane Interface 를 갖는 클래스가 구현할 때도 커져야 한다는 것은 아니다. 근본적인 기능면에서는 양자는 상당히 흡사하다.

Java 와 Ruby 의 List 컴포넌트를 비교하면 둘 사이의 차이점을 확연하게 볼 수 있다. Java 는 25개의 메소드 선언을 포함하는 java.util.List 인터페이스를 갖고 있다. Ruby 는 Array 클래스(이름과 달리 배열이 아니라 list)를 갖고 있는데 메소드 숫자는 78개이다. 메소드 숫자는 서로 다른 스타일이 존재한다는 단서라고 할 수 있다. 두 컴포넌트는 기본적으로 동일한 서비스를 제공하지만, Ruby 의 Array 는 많은 부가적인 기능을 포함하고 있다. 이들 기능은 Java 의 Minimal Interface 기반 위에서 어렵지 않게 구축할 수 있다.

둘 사이의 차이를 확연히 하기 위해서 작은 예제 하나를 보자. List 이 마지막 항목을 얻는 것인데, Java 에서는 다음과 같이 할 수 있다:

aList.get(aList.size -1)

Ruby 에서 같은 것을 수행하면:

anArray.last

사실 더 놀라운 것은 Ruby 의 Array 는 first 메소드도 갖고 있다는 점이며, anArray[0] 가 아니라 anArray.first 로 쓸 수 있다.

Ruby의 부가 기능 중에서는 좀 더 복잡한 기능도 있다. Ruby 의 Array 는 flatten 메소드를 갖고 있는데, 중첩된 Array 를 단일 수준으로 변환할 수 있다.

irb> [1,2,[3,4,[5,6],7],8].flatten => [1, 2, 3, 4, 5, 6, 7, 8]

강조하고 싶은 점은 last 와 같이 단순한 기능이든 flatten 과 같은 복잡한 기능이든 Ruby 의 부가적인 기능 모두는 Java 의 List 인터페이스의 메소드 숫자를 늘리지 않고도 클라이언트가 직접 구현할 수 있다는 것이다. Minimal Interface 지지자 관점에서는 동일한 서비스를 제공한다면 최소한의 메소드를 갖는데 초점을 맞추는 반면 Humane Interface 지지자들은 필요하다면 메소드를 추가하는 경향을 보인다.

그렇다면 무엇을 기준으로 Humane Interface 에 메소드를 추가해야 하는가 하는 의문을 갖게 된다. 누구나 원하는 것 모두를 추가한다면 너무 복잡한 클래스를 만들게 될 것이다. Humane Interface 지지자들은 클래스의 가장 일반적인 용도가 무엇이냐를 식별하고 이를 쉽게 수행할 수 있도록 설계하려고 노력한다.

이러한 원칙은 메소드를 부여하는 것에 국한된 것이 아니라 작명에도 적용된다. RubyConf 에서 Tanaka Akira 는 자주 쓰이는 메소드에 짧은 이름을 붙이는 것이 유용하다는 것을 강조했다. 자주 사용되기 때문에 친숙해져 있기 때문에 짧은 이름을 쓰는 것이 기억하는 면에서나 가독성, 타이핑 측면에서 유리하다는 것이다. DateTime 클래스에서 기본 날짜 형식을 파싱하는 디폴트 메소드는 parse 인 반면 어떠한 형식의 날짜도 모두 지원하는 보다 유연한 메소드 이름은 strptime 인데 상대적으로 자주 쓰이지 않는다는 측면을 이러한 현상의 한 예로 볼 수 있다.

Ruby 의 Humane Interface 철학이 만들어낸 또 하나의 재미있는 현상은 메소드 이름에 대한 별칭이다. List 의 길이를 원할 때, length 나 size 중에 무엇을 사용해야 할까? 라이브러리에 따라 다른 경우가 일반적이지만 Ruby 의 Array 는 둘 모두를 갖고 있다. Ruby 사용자 관점에서는 라이브러리 사용자가 어떤 것을 쓸 지를 기억하는 것보다는 둘 다 지원하는 것이 더 쉽다는 것이다.

인터페이스 설계에 있어 어떤 스타일이 가장 좋으냐는 쉽게 풀리지 않는 우문이다. 끝으로 Humane Interface 지지자의 주장을 요약해 보겠다. (다른 측면을 보려면 간결함을 지향하는 인터페이스(Minimal Interface)를 보라.)

객체의 강점은 객체가 갖는 데이터보다는 주로 행위에서 찾을 수 있다. 최소한의 서비스만 제공한다면 다수의 사용자들은 동일한 사례에 대해 동일한 코드를 양산할 것이다. flatten 메소드가 없다면 수많은 사람들이 각자 재귀함수를 작성할 것이다. 이것은 어려운 일은 아니지만, 빈번하게 발생하는 일이라면 많은 사람들이 각자 노력을 기울일 필요가 있는가?

last 와 같이 단순한 서비스의 경우에도 라이브러리 사용자는 관용구와 같은 idiom 을 배울 필요가 있다. 직관적인 사용법이 있다면 돌아갈 필요는 없다. 좋은 소프트웨어는 사용자를 먼저 생각해야 하고, 그들의 삶을 편안하게 해주어야 한다. Humane Interface 는 이러한 원칙을 따른다.

Humane Interface 는 보다 많은 일을 수행함으로써 사용자를 부담을 덜어준다. 특히 개발자에게는 소스코드 읽기와 작성 모두에 있어 일반적인 작업을 쉽게 해주는 API 가 필요하다.

Humane Interface 나 Minimal Interface, 모두 훌륭한 근거를 갖고 있다. 쉬운 판단은 아니지만, 개인적으로는 Humane Interface 쪽이 끌린다.

원문: HumaneInterface

* forgiving API라는 표현도 쓰네요. (2008.7.1 추가)