UXCamp 발표자료

"사용자는 정말 멍청한가?"라는 주제로 발표를 하였습니다. 반나절만에 급조한 자료라 좀 부실하지만 공유합니다:


저작자 표시
신고

블로그를 옮겼습니다: [글 읽기]


저작자 표시
신고

OOP에 대해서, 아는 사람은 다 알만한 이야기 및 이 글에서 인용하고 있는 大山님의 글 객체지향 프로그래밍에 대한 오해와 진실 1편, 2편을 읽고 씁니다(3년 전 글입니다). 딱히 관련 글이라기 보다는 읽고 떠오르는 생각들 몇 가지 + 제가 평소에 가지고 있던 생각을 늘어 놓으려고 합니다.

OOP를 바라보는 (유일하게 올바른 관점이 아닌 다양한 관점 중) 한 가지 관점에 대해 쓰고자 합니다. 하나의 대상을 한 측면에서만 보는 것 보다는 여러 측면에서 보면 좀 더 그 대상에 대해서 잘 알 수 있을 것이라고 생각하기 때문입니다. 제가 제시하고자 하는 관점은 다음과 같습니다:

“OOP는 무엇을 제거 혹은 대체하고자 하는가?”

부연하자면 1) 레퍼런스는 포인터에서 산술연산을 제거하였고, 2) 구조적 프로그래밍은 GOTO 류의 흐름제어 방식을 제거하였는데, 3) OOP는 무엇을 제거/대체하는가에 대해 쓰고자 합니다.

 

포인터 - 산술연산 = 레퍼런스

예를 들어 자바나 C#의 레퍼런스(reference) 개념을 살펴보죠. 레퍼런스는 보안성, 편의성, GC 효율성 등을 향상시키기 위해 기존의 포인터 개념으로부터 산술연산(arithmatic operations)을 제거하였습니다. (결과적으로 보안성, 편의성, GC 효율성 등이 향상 되었는지 아닌지에 대한 판단은 각자 알아서)

포인터는 전지전능한 주소지칭 수단인데, 사실은 전지전능한 주소지칭 수단이 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).

 

스파게티 - GOTO = 구조적프로그래밍

또 다른 예로, 구조적 프로그래밍은 프로그램의 흐름을 제어하는 방법 중 goto를 제거(다익스트라 식으로 표현하자면 의미있는 프로그래머 독립 좌표계 – programmer independent coordinates - 를 훼손하는 장치들을 제거)하였습니다. 구조적 프로그래밍에서는 다음 세 가지 수단만으로 모든 프로그램의 흐름 제어를 구현해냅니다:

  • 순서(sequence) – 쉽게 말해서 코드가 위에서 아래로 실행되는 것
  • 선택(selection) – 쉽게 말해서 if와 switch
  • 반복(iteration) – 쉽게 말해서 while(혹은 do, until, for 등)

조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단인데, 사실은 전지전능한 흐름제어 장치가 없어도 모든 프로그램을 작성할 수 있다는 것을 알게 된 것이죠(성능 이슈 등을 제외한다면).


구조적프로그래밍 - IF = OOP

드디어 본론인데요, OOP는 뭘 제거(혹은 대체)하였을까요? 혹자는 OOP가 구조적 프로그래밍을 대체한다고 말하는데 1/3 쯤 맞는 표현이라고 생각합니다. OOP는 구조적 프로그래밍의 세 가지 흐름 제어 수단(sequence, selection, iteration) 중에서 선택(selection) – 즉 if 문 – 을 제거합니다.

구조적 프로그래밍에 대한 설명에서 “조건문(if)과 결합된 goto 문은 전지전능한 흐름제어 수단”이라고 표현하였는데 이 중 goto는 제거되었으나 if는 살아남은 것이 구조적 프로그래밍이라면 if 까지도 제거하고자 하는 흐름을 OOP라고 보는 관점이 있을 수 있다는 것이죠.

오해의 소지가 있으니 잠깐 부연하자면, 모든 if를 제거해야 진정한 OOP라는 류의 주장은 아닙니다. 이에 대해서는 글 뒷부분에서 좀 더 이야기하도록 하겠습니다(진정한 OOP 따위 대체 뭔가요, 먹는거임? 우걱우걱).

그럼 조건문을 무엇으로 대체하고 있나요? 다형성(polymorphism)이죠. 그냥 다형성이라고 하면 너무 광범위하죠. 이를테면 파라메터 다형성(parametric/parameterized polymorphism)은 OOP 보다는 Generic Programming과 관련이 있습니다. OOP의 핵심이라고 하는 다형성은 특히나 서브타입 다형성(subtype polymorphism)을 말합니다. 이후에는 그냥 다형성이라고만 쓰겠습니다.

그럼 다형성이 조건문을 어떻게 대체하나요? 조건문이란 애초에 선택(selection)을 위한 것인데, 여기에서 선택이란 특정 변수의 값에 따라 이후에 실행할 코드가 달라지도록 하는 것을 말합니다. if 문에서는 조건절의 boolean 값에 따라 선택이 수행되는 것이고, 다형성에서는 메시지(message)에 담긴 파라메터(메시지를 받는 대상 개체도 파라메터로 칩시다. 파이선 self 마냥)에 따라 선택이 수행됩니다.


4. 다형성과 의존성 역전(DI – Depedency Inversion)

if를 다형성으로 대체하는 것이 정말 OOP를 특징지을만큼 중요한가요? 네, 전 그렇다고 생각합니다. 이쯤에서 밥 삼촌(Uncle Bob)을 인용해주어 (올바른) 권위에의 호소를 한 번 시도하도록 하겠습니다:

프로그램이 어떤 언어로 작성되었는지는 중요치 않습니다. 만약 의존성이 역전되어 있다면 이는 객체지향적 설계인 것입니다(It doesn't matter what language a program is written in. If its dependencies are inverted, it has an OO design).

--Robert Cecil Martin, Agile Software Development

if 얘기 하다말고 갑자기 왜 의존성 역전(DI) 떡밥이 나왔을까요? 그 전에, 애초에 의존성 역전이라고 할 때 이 역전이란 뭘 뒤집었다는 뜻일까요? David Parnas 큰형님이 지금으로부터 무려 37년 전에 쓴 논문에 답이 나옵니다:

첫째, 하위 계층의 서비스를 활용함으로써 시스템의 일부가 이득을 취했다(간결해졌다). 둘째 상위 계층을 들어내더라도 여전히 유용하고 사용 가능한 산출물(하위 계층 서비스들)이 남는다. (…중략…) 만약 하위 계층의 모듈이 상위 계층의 모듈을 사용하게끔 설계를 했다면 올바른 위계를 얻어낼 수 없었을 것이고 시스템의 일부만 들어내기가 훨씬 더 어려웠을 것이며, 계층이라는 말 자체가 의미를 잃게 될 것이다(First, parts of the system are benefited (simplified) because they use the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. (..omitted...) If we had designed a system in which the "low level" modules made some use of the "high level" modules, we would not have the hierarchy, we would find it much harder to remove portions of the system, and "level" would not have much meaning in system).

--On the Criteria to be used in Decomposing Systems into Modules

시스템을 모듈화할 때 계층 간의 위계를 명확히 나누고 상위 계층이 하위 계층을 사용(즉 의존)하도록 만들어야 한다는 주장이며 이는 구조적 프로그래밍 혹은 모듈화 프로그래밍의 핵심 설계 원칙 중 하나입니다. 여기에서 상위 계층이란 좀 더 추상적인(abstract) 계층을 말하고 하위 계층이란 좀 더 구체적인(concrete) 계층을 말합니다. 그림으로 그려보면 아래와 같습니다:


모든 화살표가 위에서 아래로 내려가는 모습을 담고 있습니다. 의존성 역전이란 바로 이러한 의존관계를 뒤집는다는 의미로, 의존성 역전이 일어난 설계에서는 화살표 일부가 아래에서 위로 올라갑니다. UML로 치자면 속이 빈 삼각형 화살표(generalization 혹은 realization)로 표현합니다:


의존성 역전이 가능한 이유는 하위 계층이 상위 계층에 의존하면서도 순환 참조(circular dependency)가 일어나지 않게 만들어서 이를 통해 원래 David Parnas가 강조하던 목적(시스템의 일부를 쉽게 들어낼 수 있도록 하는 것)을 여전히 달성할 수 있게 되기 때문입니다.

순환 참조는 어떻게 끊나요? 즉, 위 그림의 속이 빈 삼각형 화살표는 언어에서 어떻게 표현될까요? 상속으로 표현합니다. 자바로 치자면 extends 혹은 implements가 되겠죠. 대표적 사례는? Observer Pattern. (다시 보니 위 그림은 별로 예쁘지 않군요. 대충 예쁜 의존성 역전의 사례를 상상해주세요)

잠깐 딴소리: 아마도 GoF 패턴책이 번역된 후로, 다른 커뮤니티는 모르겠고, 자바 개발자들 사이에서 extends는 꼬지고 implements는 좋은거라는 미신이 널리 퍼졌죠. 좀 과장하자면 구현 상속은 delegation(and/or composition)으로 대체하고 오직 타입 상속이 쵝오, 뭐 이런 얘기인데 “extends == 구현 상속”, “implements == 타입 상속”이라는 잘못된 공식이 오해의 원인이 아니었을까 추측해봅니다. 자바의 경우 “extends == 구현 상속+타입 상속”이라고 해야 맞습니다. 즉, implements이건 extends이건 타입 상속은 일어나는거죠. 단 extends를 했을 때는 구현 상속이 따라오게 되어 있는데 이 때의 문제를 잘 인지하고 해결할 수 있으면 그냥 쓰면 되는 것이죠.

이를테면 blackbox reuse vs. whitebox reuse 문제 같은 것이 있는데, 애초에 public/published 구분 잘 하고, protected 따위 안쓰고 메서드는 몽땅 public, 필드는 몽땅 private 같은 몇 가지 원칙들만 잘 지키면 문제의 소지가 크게 줄어듭니다.

다시 본론으로 돌아와서 지금까지의 얘기를 정리해보자면 이렇습니다:

  1. OOP는 구조적 프로그래밍의 selection(if/switch)을 서브타입 다형성으로 대체합니다.
  2. if를 서브타입 다형성으로 대체하면 하위 계층 뿐 아니라 상위 계층 까지도 더 잘 모듈화할 수 있습니다.
  3. 이러한 생각을 표현하는 말이 의존성 역전(DI) 입니다.

 

5. OOP의 나머지 개념들은 뭔가?

그럼 캡슐화(encapulation), 정보은닉(information hiding)은 안중요한가요? 중요합니다. 다만 OOP와 별 관련 없이 원래 있던 개념들입니다.

 

6. if는 다 잡아 없애야 진정한 OOP인가?

if 뿐만 아니라 switch도 다 없애야 진정한 OOP라능. 농담입니다. --;

두 가지를 이야기할 수 있겠습니다. 첫째, 진정한 OOP 아무 짝에도 쓸모 없습니다. 그런거 추구하지 마세요. 둘째, 상위 계층의 모듈화를 저해하는 if만 제거하세요. 다른 말로 바꿔서 표현하자면, 도메인 로직을 서술하기 위한 if는 남겨두세요.

 

7. OOP에 대하여 지금 서술한 관점이 킹왕짱인가?

저는 그렇다고 생각합니다. 하지만 “제일 좋은 관점”이랑 “완전한 관점”은 다른 것이죠. 제일 좋은 관점이라고 믿고 있기는 하지만 이 관점만으로 밀기엔 불충분하고 생각도 덜 다듬어진 것 같습니다. 따라서 여러 관점을 머리 속에 담아두고 그때그때 가져다 쓰는 식으로 생각하고 있습니다.


신고

The Nature of Order 발표회에 다녀왔습니다. The Nature of Order는 패턴 언어의 창시자로 유명한 건축가 Christopher Alexander의 최근 저서(총 네 권으로 이루어져 있습니다)입니다.

발표회는 예정보다 30분 정도 늦게 시작했고, 예정보다 30분 정도 시간이 더 소요되어서 예정보다 1시간 정도 늦게 끝났습니다. 그리고 예정에 없던 뒷풀이(?)가 있어서 거기까지 따라갔다가 왔습니다. 에또 예정에 없던 UX recipe 모임과의 합류가 이루어지면서 예정에 없던 반가운 몇몇 분들을 뵐 수 있었습니다.

초반에는 김창준님이 Pattern Languages –> Morphogenetic Sequences –> Generative Codes로 이어지는 C.A 사상의 흐름을 간략히 설명해주셨습니다. 이 글을 참고하시면 좋겠습니다.

그 다음에는 원형 테이블에 8명씩 둘러 앉아서 두 명씩 짝을 지어 그림 그리기 놀이를 했습니다. 이름을 뭐라 할까요, generative pair drawing 정도로 하면 적당할까요? 저는 uxfactory의 황리건님과 함께 그렸는데 작품명은 “피카소의 외계인”이었습니다 ㅎㅎ

다음으로는 각 테이블 별로 발제자 분들이 자신이 정한 주제에 대해 10분씩 설명하는 형식으로 발표가 진행되었습니다. OST와 유사한 형태였습니다. 10분씩 세 번의 이터레이션이 있었기 때문에 모든 발표자의 이야기를 다 들을 수는 없었고, 저는 1) 교육, 2) 지식 습득과 커뮤니티, 3) 프로그래밍 이렇게 세 가지를 들었습니다. 각 발표를 들으면서 C.A가 주장하는 15가지 속성은 상당히 범용적이면서도 구체적이어서 여러 분야에 적용해볼 수 있는 유용한 도구가 될 수 있을 것이라는 생각을 했습니다. 특히 TDD에 대한 새로운 관점(center가 지속적으로 파생되며 서로를 보완해가는 과정으로서의 TDD)을 얻게 된 것이 큰 소득이었습니다. 이는 TDD에만 적용된다기 보다는 좀 더 넓은 함의를 지닌다고 생각합니다. 충분히 고민해볼 필요가 있다고 생각합니다.

뒷풀이 자리에서는 최근 머리속을 떠나지 않는 고민(모듈식 설계에 대하여)에 대해 이야기를 나누었는데 이에 대해서는 다음 글에서 쓰도록 하겠습니다.

신고

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) 관점에서 읽어도 큰 영감(과 감동)을 얻을 수 있습니다. 이에 대해서는 "디자인이란 서로를 이롭게 연결하는 것"을 참고해주세요

신고

이번에 읽은 책은 Game Development Essential 시리즈 중 Game Interface Design 입니다. (사실은 지난 주말에 읽었는데 지금 정리해서 올립니다)


기초(foundation), 이론(theory), 실무(practice) 순서로 구성되어 있는데 실무 부분에서는 개발 프로세스, 프로토타이핑 얘기가 나오길래 대충 훑어만 봤습니다.

1장(역사)에서는 초창기 아케이트 게임의 역사를 훑으면서 인터페이스(물리적 인터페이스 포함)가 어떻게 발전해왔는지 소개하고 있습니다. 다이얼 하나 달랑 있던 Pong, 무기 발사 개념이 추가된 Space Invaders, 한 축의 움직임을 더 추가하여 X,Y 양방향 이동을 구현한 Pac Man 등의 순서로 이야기가 전개됩니다. 이 부분을 읽으며 얻은 교훈이라면… 게임이 상당히 다양해보이기는 하지만 초창기의 몇 가지 혁신에 비하면 최근 게임들의 변화는 약간의 변주에 불과한 것이 아닌가 하는 생각(닌텐도는 살짝 예외 ㅋ). 하긴 이런 류의 얘기는 예전에 랄프 코스터 책에서도 언급된 적이 있었던 것 같네요. 게임을 즐기는 행위를 관찰해보면 장르가 아무리 달라도 별 차이가 없어 보인다는 식으로 표현했던 것으로 기억합니다

또 한가지 재미있었던 내용은 오락실 게임의 “High Score”가 만들어낸 사회 현상에 대한 언급. 저자는 오락기 전원이 꺼지면 High Score가 지워지는 것을 단점이라고 말하고 있지만 저는 이게 오히려 장점이었다고 생각해요. 기존 스코어가 지워져야 매일매일 새로운 경쟁이 시작되는 것이죠. :-)

2장(목표와 고려사항)에서는 본격적으로 이론틀을 소개하고 있습니다. 게임 인터페이스의 1차적 목표(primary goal)은 피드백과 컨트롤이라고 정의하고 있고, 2차적 목표(secondary goal)는 몰입(immersion)과 분위기(atmosphere)라고 정의하고 있습니다. 그리고 이후에 지속적으로 게임 컨텐츠 내에 녹아들어서 사용자에겐 최대한 보이지 않는 인터페이스의 장점에 대해 강조하는 내용이 책 전체에 반복됩니다.

읽다보니 중간에 좀 어이없는 인용이 나오는데요 이건 좀 아니다 싶었습니다:

저는 이게 더 직관적이고 플레이어에게 자신이 다루는 탱그와 좀 더 연결되어 있다는 느낌을 주는 방식이라고 생각했습니다. 베타 테스터들은 이 인터페이스에 대해 내내 불만을 토로했죠. 최종적인 게임도 에너지 막대가 없이 출시되었습니다. 이로 인해 판매량이 줄었을 것 같긴 하지만 그래도 저는 이게 더 나은 인터페이스라고 생각합니다.

I felt it was more intuitive and allowed one to become more connected with the object they were driving(a tank). Our beta testers complained about it constantly during testing. The final game has no health meter, and it may have probably hurt sales, but I think it is a better interface. (p21)

예술을 하는게 아니라면 혁신 자체가 목표여서는 안된다고 생각합니다. UI이건 UX이건 ROI를 진지하게 고민할 필요가 있습니다. (예전에 오픈마루 블로그에 쓴 사용자 경험의 비즈니스 가치도 참고)

3장(인터페이스 분류하기)은 기존 인터페이스를 카테고리에 맞게 나누는 작업을 하고 있는데 별로 얻은 인사이트가 없었습니다. 카테고리로 나누는 행위에도 목적이 있을텐데 그냥 나눠놓고 “이 중에서 골라써~”라는 식의 접근은 싫어합니다. 저는 기본적으로 디자이너의 자세에 대해서는 Designing for Interaction에서 나왔던 “디자인이란 그저 그런 여러 옵션 중 하나를 선택하는 것이 아니라 새로운 옵션을 만들어내는 것이다”라는 접근을 선호합니다. 그런 측면에서, 새로운 안을 찾아내기 위해 기존의 인터페이스를 분해하여 좀 더 본질적인 조각들로 나누는 방식이었다면 좋았을텐데 아쉽습니다.

4장(하드웨어 인터페이스)은 다양한 하드웨어와 컨트롤러의 인터페이스를 소개하고 있는데, 그 중 재미있었던 내용은 PS나 Xbox 류에 딸려오는 기본 컨트롤러를 쥐는 방식이 사람마다 조금씩 다른데 대표적으로 오른쪽 버튼(A,B,X,Y)에 관련하여 precise player와 sloppy player라는 이름으로 구분하고 있더군요 ㅋ 전자는 정확히 버튼을 눌러주는 사람, 후자는 엄지를 어중간한 가운데 위치에 놓고 문지르듯 누르는 사람. 저는 게임 종류에 따라 다르게 누르는 것 같아요. 가끔은 검지를 같이 쓰기도(격투게임). 물론 그런 스타일에 대해서도 언급하고 있습니다 ㅎㅎ

5장(장르에 따른 구분)에서는 다양한 게임 장르에 따라 관습적으로 쓰이는 인터페이스 요소들에 대해 설명하고 있습니다. 관습이 중요한 이유 중 하나는 그러한 인터페이스를 원하는 수많은 기존 팬들 때문이라는 측면도 있다고. 중요한 내용이라고 생각합니다. 하지만 한편으로는 이러한 요소를 의도적으로 깨고 시장을 확대한 사례로 닌텐도의 Wii가 있죠. 요즘은 닌테도 때문에… 뭔 얘기를 하건 간에 “아니야, 닌텐도는 그렇게 안했는데 대박났어!”하면서 반론을 하게 된다죠. ㅎ

6장(컨트롤)에서는 제목 그대로 게임을 제어하는 수단으로서의 인터페이스에 대해 설명하고 있습니다. 너무 많은 것을 자동화해주는 바람에 게임의 재미가 반감된 사례로 “The Bard’s Tale”을 소개하고 있습니다. 유사한 사례로 넥슨의 “바람의 나라”도 언급되고 있군요.

6장에서 상당히 깊게 다루는 내용 중 “저장 시스템”이 있는데요, 이 부분은 그동안 유서 깊은 토론들도 워낙 많았고, 아직 제가 못 따라간 부분들도 있고, 내용도 길고 해서… 공부 좀 더 한 다음에 별도의 포스트로 다루고자 합니다.

7장(피드백)은 6장의 컨트롤과 대비되는 부분으로 게임 내 상황에 대해 유저에게 알려주는(피드백) 방식에 대해 다루고 있습니다. 별 특별한 내용은 없었고, 읽다가 발끈한 부분이 하나 있어서 간단히 소개하려고 합니다. MMOG 종류의 인터페이스가 복잡할 수 밖에 없는 이유에 대한 합리화(?)인데요, 저자는 1) MMOG는 장시간 플레이하는 게임이기 때문에 효율성이 극대화 될 필요가 있고, 2) 초보자와 숙련자의 니즈가 다르기 때문에 사용자 정의가 필요하다는 주장을 하고 있습니다.

하지만 그렇게 친다면 대부분의 일반적인 애플리케이션의 UI 또한 1) 장시간 사용하며, 2) 초보자와 숙련자의 니즈가 다르다는 점에서 UI가 복잡할 수 밖에 없다는 주장도 성립하게 될텐데, 좀 이상한 얘기죠. 현재의 MMOG UI를 보고 있으면 과거의 Microsoft Office를 보는 느낌이 듭니다. 버전이 올라가면서 점점 늘어가는 툴바와 메뉴 아이템, 이를 감추기 위한 각종 떡칠(adaptive menu 등)과 사용자 정의 기능, 이러한 떡칠 때문에 더 복잡해지는 UI의 악순환 말이죠.

이러한 악순환을 개선하기 위해서는, The Humane Interface의 다소 급진적인 원칙들을 적용해보기 위해 노력할 필요가 있다고 생각합니다. The Humane Interface는 몰입(immersion)을 강조하는 부분이라거나 하는 면에서 게임 UI 설계와 특히 잘 통하는 면이 있다고 봅니다.

이후 8장, 9장은 실무(practice) 얘기인데, 앞서 말씀드린대로 생략하도록 하겠습니다.

끝!

신고

빌린 책에 줄 긋기

회사 지하에 도서관이 있는데 좋은 책이 참 많습니다. 게다가 책이 없으면 주문도 할 수 있고요. 원서도 아마존에서 개인적으로 주문하는 것에 비해 훨씬 빨리 오는 것 같습니다(어쩌면 운이 좋았을지도). 하여간, 덕분에 더욱 부담없이 이런저런 책들을 읽을 수 있게 되었습니다. 물론 읽어보고 소장해야겠다는 생각이 들면 삽니다. ㅎㅎ

문제는 빌린 책이라서 줄을 긋지 못한다는 것인데요, 이게 저한테는 아주 중요합니다.

저는 성격상 한 자리에 앉아서 공부를 하는 짓은 죽었다 깨어나도 못하는 사람이라서 주로 걸어다닐 때, 식당에서 줄 서서 기다릴때, 화장실 갈 때, 자기 전에, 지하철 출퇴근길에 책을 찔끔찔끔 읽는데 이렇게 띄엄띄엄 읽으면서도 흐름을 놓치지 않으려면 줄도 열심히 그어야 하고, 좀 더 적극적인 책읽기를 해야하고, 다 읽은 후에 밑줄 그은 부분 위주로 빠르게 훑어보면서 어떤 내용이 있었는지 되돌아볼 필요도 있습니다. 마지막으로 밑줄 그은 내용을 개인 위키에 정리해서 올리며, 예전에 읽었던 비슷한 내용들에 링크를 거는 작업을 하면 책 읽기가 끝납니다. 그래서 밑줄을 못 그으면 책을 읽어도 읽은 것 같지가 않단 말이죠. (물론 가볍게 읽는 책은 이런 식으로 하지 않죠)

처음에는 항상 들고다니는 UMPC를 이용해서 페이지 번호와 메모를 기록하는 식으로 해봤으나 하루만에 포기했습니다. 대기모드로 해봤자 부팅이 최소 30초는 걸리고 조작도 불편하며(한 손에 책을 들고 한 손에 UMPC를 들면 키보드는 뭘로 치란 얘기?) 식당에 갈 때나 화장실 갈 때 UMPC랑 책을 다 들도 다닐 수도 없는 노릇이니까요.

두번째로 시도한 것이 iPod Touch의 Notes 애플리케이션입니다. 일단 5초 안에 메모를 시작할 수 있고(여전히 밑줄 긋기에 비하면 느리지만), 주머니에 항상 넣고 다니니까 어디든 책과 함께 가지고 다닐 수 있으니 좋습니다. 게다가 iPod Touch를 쥐고 있는 손으로 타자 입력이 가능하다는 점도(인간에게 꺽어진 엄지손가락을 만들어주신 자연선택 횽아 감사) 마음에 듭니다. 문제라면 화상 키보드에 손가락 하나도 주절주절 긴 문장을 적는다는 것이 상당히 짜증나는 일이라는 점.

그래서 메모 형식을 다양하게 바꿔가며 이런저런 시도를 하고 있습니다. 최근에는 Game Usability라는 책을 읽었는데 Notes 애플리케이션에 메모된 내용은 아래와 같습니다:

Game Usability
67. Think aloud and ... + next para
69. 5.3 LoTA
71. The best...
81. Laitinen 2006
81. XP vs. Task
83. Table 6.1
93. Poor UI ...
  UI, 게임성 분리하여 생각 X
191. FACS
239. Automated capture ...
240. The fact ...
  자동수집 장단점
241. Our next step ...
244. We developed ...
244. Bullets
259. Lessons learned
297. In hindsight ...
298. Usability Experience Challenge
309. Entire chapter
320. Bullets and table
  PX라는 말 만들기 위한 인위적 구분. 항목 자체는 유의미
354. Mind you, ... Games are very ... What u really want to do...
355. I think real ... C also GenderIGD

페이지 번호를 쓰고 점 찍고 내용 적고, 혹시 메모할 내용이 있으면 아래줄에 적는다는 규칙입니다. "See also"는 C also로, "Gender Inclusive Game Design" 같이 긴 문구는 "GenderIGD" 같이 나중에 기억을 되살릴 수 있을 정도로만 축약합니다.

지금까지는 만족스럽습니다. 표기를 좀 더 축약할 방법을 찾는 중입니다. 예를 들어 페이지 번호 다음에 점 찍을 필요가 없다거나(tap 두 번 단축) 등등.

신고
The Humane Interface 3장에 이어 4장 스터디를 끝냈습니다. 4장의 주제는 정량화(quantification) 입니다. 키워드는 GOMS, 인터페이스 효율성, Fitts' Law, Hick's Law 입니다.


1. GOMS

GOMS는 Goals, Operators, Methods, and Selection rules의 약자로 사용자와 컴퓨터 사이에서 일어나는 인터랙션을 작은 단위들로 환원하기 위한 모델입니다. 이 책에서 저자는 단순화된 키보드입력 수준의 GOMS를 소개하고 있는데, 예를 들면:
마우스를 잡고 있던 손을 키보드 위로 옮기고(homing), 세자리 숫자를 입력한 후(keying, keying, keying), 엔터(keying)를 친다.
라는 일련의 동작은
HKKKK
로 표현됩니다. 근데 키보드 위로 옮긴 다음 숫자를 입력하기 전에 사용자가 "뭘 입력할지" 떠올리는 시간(mentally preparing)이 잠깐 필요하다면
HMKKKK
가 되겠죠.

이런 설명을 듣고 나면 전 항상 이런 궁금증이 생깁니다. 이렇게 환원해서 뭘 어쩔건데? 이거 왜 하지?

뭐 다양한 응용을 할 수 있겠지만 인터페이스의 효율성을 측정하고 개선하는 일에 응용할 수 있겠습니다. 예를 들어 keying은 0.2초, homing은 0.4초, m은 1.35초라고 하면, 위 인터페이스를 이용하여 작업을 완수하는데 걸리는 시간은
0.4 + 1.35 + 0.2 + 0.2 + 0.2 + 0.2
가 됩니다. 이런 식의 측정을 통해 화씨/섭씨 변환 UI의 효율성을 개선하는 사례를 소개하고 있습니다.


2. 인터페이스 효율성

저자는 인터페이스 효율성이라는 재미난 개념을 소개하고 있는데요, 쉽게 말하면 사용자가 인터페이스를 통해 컴퓨터에게 실제로 제공한 정보의 양이 컴퓨터가 과업을 수행하기 위해 필요한 정보의 양에 가까울수록 인터페이스의 효율성이 높다고 보겠다는 개념입니다. 전자가 후자에 비해 낮을 수는 없으므로 효율성은 0 에서 1 사이의 값을 갖습니다.

뭐 열역상에서의 효율성이나 정보이론에서의 효율성과 다르지 않은 개념입니다만, 이걸 인터페이스에 이렇게 적용한다는 시각이 재미난거죠. 정보이론의 전통을 따라 인터페이스가 필요로하는 정보량은 비트(bit) 단위로 계산합니다. n가지 선택사항 중 한가지를 고르는 문제가 요구하는 정보량은
log2n
이 됩니다. 설명을 읽어보니 사용자가 화면을 보며 이진검색(binary search)을 한다고 가정한 모양입니다. 그 가정이 맞건 안맞건 이 모델이 예측하는 바가 실제 실험 결과와 유사하다고 하니 저 같은 사람은 그냥 그런갑다 하고 넘어가면 되겠습니다. ㅎㅎ

여기까지 읽으면 또 아까랑 비슷한 의문이 생기죠. 인터페이스의 정보량 왜 측정하는데?

이게 인터페이스가 달성할 수 있는 효율성의 이론적 하한선을 규정해주기 때문입니다. 즉, 언제 디자인에 대한 투자를 멈춰도 좋은지에 대한 쓸만한 판단 기준이 된다는 얘기죠. 이렇게 써놓고 보니, 저자의 아들이 2년 전에 썼던 글 "Know when to stop designing, quantitatively"이 생각납니다. 아버지와 달리 그림도 좀 넣어주고 설명도 좀 친절하단 말이죠 ㅎㅎㅎ


3. Fitts' Law

Fitts' Law는 쉽게 말해서 클릭하기 좋게 만들려면
  • 버튼 크기를 키우던가,
  • 버튼을 화면 구석(변이나 모서리)에 놓던가,
  • 마우스 이동 거리를 짧게 만들던가.
하라는 얘기입니다.

버튼 크기를 키우자는 얘기는 뻔한거라 생략하고, 버튼을 화면 구석에 놓은 사례는 MacOS의 메뉴(항상 화면 상단에 있습니다), MacOS의 Dock(항상 화면 하단 혹은 측면에 있습니다) 등을 떠올리시면 됩니다. 윈도XP의 시작메뉴는 예전 글에서 설명한 이유로 인해 매우 부적절한 사례입니다.

마우스 이동 거리를 짧게 만든 사례는 마우스 우클릭을 하면 버튼 바로 옆에 나타나는 컨텍스트 메뉴, 오피스 2007에 추가된 미니툴바 등을 들 수 있겠습니다:

참고로, Fitts' Law는 수식으로 쓰자면 아래와 같습니다:
a + b log2(D/S + 1)
a,b는 대상 환경에 따라 실험적으로 정해야하는 변수이고 D는 이동거리, S는 버튼의 크기입니다. 여기에도 log가 나오는군요.


4. Hick's Law

Hick's Law는 화면에서 뭘 고르려고 할 때 요소가 많아지만 많이질수록 시간이 늘어난다는 법칙입니다. 에 근데, 그냥 늘어나는게 아니라 base를 2로 하는 log 함수에 따른다는 얘기. 식으로 만들면 Fitt's Law랑 똑같다죠:
a + b log2(n + 1)
이렇게 적어놓고 보면 재미난 함의들이 몇 가지 보입니다. 그 중 하나를 책에서 인용하자면:
하나의 메뉴에서 8개의 선택 항목 중 하나를 선택하는 것이 2개의 메뉴에서 4개의 항목 중 하나를 선택하는 것 보다 빠르다.
라는 것입니다. 과연 그럴까 싶지만 통제된 상황에서 측정해보면 그렇다고 합니다.


5. 결론 혹은 저자가 강조하고자 하는 바

결론은 1) UI의 많은 요소가 정량화 가능하다. 2) 실제로 정량화/측정을 하건 안하건 각 법칙이 갖는 함의들을 체화하여 모든 디자인 과정에서 적절히 녹여내는 것이 중요하다. 입니다. (재미난 점 하나. 이 글 2, 3, 4번 섹션에 각각 수식이 하나씩 나오는데 전부 똑같이 생겼습니다. --; 세상은 로그라능 ㅋ)

PS: 아니 그러고보니, 오늘은 대머리장군님이랑 규하횽아랑 시비가 붙었던 시비시비로군요.

신고
< Newer     Older >

티스토리 툴바