1. The Interaction Design of APIs

얼마 전에 “The Humane Interface”에 대해 언급하면서 모드 없는 인터페이스, 모드 없는 소스 코드에서 사용자 인터페이스(UI – User Interface)에 적용되는 원칙이 프로그래밍 인터페이스(API – Application Programming Interface)에도 적용되는 사례를 이야기 했었는데요, 오늘 이와 관련하여 재미있는 슬라이드를 보았습니다.

The Interaction Design Of APIs
View more presentations from Alex Payne.

트위터의 API 디자이너인 Alex Payne이(pass님이 알려주셔서 추가) Stanford HCI Group에서 발표한 “The Interaction Design of APIs” 라는 제목의 슬라이드입니다. 슬라이드 쪼가리(ㅎㅎ)만 보고 내용을 유추해서 이야기해보면:

  1. API를 설계할 때에도 HCI(Human-Computer Interaction)의 관점에서 생각할 필요가 있음
  2. 좋은 프로그래밍 인터페이스의 조건, 나쁜 프로그래밍 인터페이스 요소
  3. 마지막으로 좋은 API가 갖추어야 할 자질들(qualities)

2번 중 나쁜 API의 사례로 자바의 날짜 관련 클래스들(java.util.Calendar, java.util.Date)이 언급되고 있군요. 정말 공감이 됩니다 (그나마 예전에 비해 좋아졌죠. 초창기에 java.util.Date는 mutable 이었습니다. java.util.Calendar가 나오면서 Date는 value object 취급을 받게 되었으나, 아직도 예전의 흔적 – deprecated APIs - 이 남아 있습니다). 그밖에도 Mac OS의 Keychain Service(아마 키입력을 담당하는 API인 것 같아요. Mac은 전혀 몰라서 계정과 암호를 담당하는 부분이라고 합니다. 한날님 감사), Win32의 다이얼로그 관련 API(ㅎㅎ 어디 이것 뿐이겠어요) 등을 나쁜 API로 소개하고 있습니다.

3번과 관련해서는, “The Humane API”의 자질로 탐색 가능성(explorable), 예측 가능성(predictable), 일관성(consistent)을 꼽고 있습니다.

2. The Humane Interface

사실은 “The Humane Interface”에서도 프로그래밍 인터페이스에 대하여 살짝 언급하는 부분이 있죠(p60). 해당 부분 번역이 특히 엉망이라 대충 읽고 넘어 갔었는데 구글 책 검색을 통해 원문을 찾아 읽었습니다. 대충 요약하자면 모드(mode)가 있는 시스템의 경우, 클라이언트가 시스템에 연결된 후 현재의 상태를 알아내기 위한 추가적인 작업을 수행하여야만 한다는 단점이 존재하는 점을 지적하고 있습니다. (그런 의미에서 HTTP는 잘 설계된 프로토콜이라는 얘기 ㅋㅋ) 엑셀 등에 존재하는 매크로 기능에 대해서도 언급하고 있는데 이 부분은 다음 기회에.

앞에서 소개한 슬라이드도 그렇고, 이 책도 그렇고 주로 Published API의 관점에서 이야기를 하고 있지만 꼭 그렇게 한정지을 필요는 없습니다. 의존(dependency)의 자기유사성(self-similarity)에서 스케일에 따라 다양한 종류의 의존성이 나타나는데 이들이 서로 유사한 속성을 공유한다는 이야기를 한 적이 있는데, API 설계 또한 이것과 마찬가지로, 스케일에 따라 다양한 측면에서 유사성을 발견할 수 있습니다. 라이브러리를 설계하건, DSL을 고안하건, 프레임워크를 만들건 다를 바 없습니다. 그런거 안하고 그냥 코딩만 하는 경우라도 다를 바 없습니다. 함수 하나 만들고, 다른 함수에서 이 함수를 호출하는 간단한 코드에도 이미 인터렉션(두 함수 사이의)이 존재하니까요.

이 책에서 말하는 “좋은 인터페이스”의 장점 중 하나는 사용자들의 올바른 습관 형성을 도와준다는 것인데요, 이 또한 API나 라이브러리, 프레임워크에 그대로 적용되는 이야기 입니다. Rails 류의 프레임워크가 제공하는 “Convention over Configuration” 철학의 진짜 장점은 타자를 적게 치게 해주어서 블로그를 5분만에 만들게 해주는 따위의 것에 있다기 보다는 프레임워크를 쓰는 개발자가 루비라는 언어, 그리고 웹이라는 기술을 올바르게 활용하는 좋은 습관을 들이도록 도와준다는 점에 있다고 생각합니다. xUnit 류의 단위 테스트 프레임워크도 마찬가지이고요.

이런 도구나 프레임워크를 열심히 사용하다보면 어느 순간 습관이 바뀌어 있고, 그 후에는 이런걸 쓰건 안쓰건 자신이 예전과 다르게 코딩하고 있음을 발견하게 됩니다.

3. 설계(design)와 디자인(design)

이처럼, 화면 설계(UI Design)와 프로그램 설계(API Design) 사이에는 통하는 면이 많습니다. 최근에 Kent Beck이 쓴 “Design is beneficially relating elements”라는 글은 아마도 설계(design)를 염두에 두고 쓴 글이겠지만, 기획(design) 혹은 디자인(design) 관점에서 읽어도 큰 영감(과 감동)을 얻을 수 있습니다. 이에 대해서는 "디자인이란 서로를 이롭게 연결하는 것"을 참고해주세요

신고
< Newer     Older >

티스토리 툴바