얼마전 iPhone OS 3.2 의 새 기능들[1]에 대해 살펴보면서 UI 적인 개선을 약간 엿볼 수 있었다. 글을 올린 직후, iPad 의 UI 관련 사진들만 모아 분석해놓은 자료를 발견해 흥미로운 부분만 부랴부랴 다시 정리해본다.

iPad UI Conventions [2] 에 가보면 현재 50개 이상의 iPad UI 사진이 등록되어 있고, 주목할만한 부분들에 대해 설명/논의하고 있다.

Split views in Popover

화면 orientation 에 따라 split view 가 자동으로 popover 로 변경되는 예이다. Popover 의 UI 를 잘살펴보면, 상단의 navigation/edit/search, 하단의 refresh 등 모든 것이 split view 의 그것과 동일함을 알 수 있다. iPhone 이나 iPod touch 를 사용해본 사람이라면 어떤 식으로 동작할 지 훤히 보일 것이다. 일관성과 직관성에서 최고의 점수를 받을 만한 UI 디자인이라고 생각한다.

Composing Email

데모 때 아래 그림을 보고는 ‘어! 왜 화면을 다 활용하지 않지?’ 라며 의아해했다. 하지만 플리커의 댓글들을 보니  역시 깊은(?) 뜻이 있었음을 알 수 있었다. 메일 작성 영역의 넓이는 정확하게 메일을 볼 때의 넓이와 일치한다. 그 넒이는 iPad를 가로로 놓건, 세로로 놓건 변함이 없다. 즉.. 메일을 보고 작성할 때 항시 동일한 넓이/레이아웃을 유지해준다.

iBooks

책의 상세 내용을 표시해주는 화면이다. 화면을 이동시키지 않고 pop up 스타일로 알려줌으로써 불필요한 화면 전환을 최소화했다.

아날로그의 느낌을 그대로..

iPad UI 의 또다른 특징은 아날로그의 느낌을 많이 강조하고 있다는 것이다. 디지털 인터페이스에 거부감을 느끼거나, 아날로그의 따뜻함을 좋아하는 사람들에게 친숙한 느낌을 선사한다.

다음의 Address Book 의 프레임, 좌측 인덱스, 중앙의 제책(바인딩) 방식, 바탕 재질 등이 종이로 된 전화번호부의 느낌을 잘 살려주고 있다.

그 외 iBooks, Calendar, Map, Pages 등 곳곳에 아날로그적인 느낌을 강조하고 있다.

Custom Input Views

iPad 의 iPhone OS 3.2 에서는 input view 를 확장하고, 심지어 어플 개발자들이 custom input view 를 제작해 사용할 수 있도록 허용하였다. 아래 그림들은 그 활용 예들을 보여준다.

Custom Cut, Copy & Paste 위젯

iPhone 에서 기본으로 제공하는 Cut, Copy & Paste 위젯도 어플 개발자가 자유롭게 수정/확장이 가능한데, 아래는 애플의 Numbers 어플에서 이를 변경/확장한 예이다. Fill 은 액셀의 자동 채움 기능에 해당한다.

다음은 위 그림에서 Fill 선택 후 셀을 우측으로 확장한 결과이다.

그 외에도 재미난 그림들이 제법 있으니 직접 감상해보기 바란다.

Editing in Keynote on the iPad

이번엔 YouTube 에 올라온 동영상이다. iPad 용 Keynote 를 직접 동작시켜보는 영상[3]인데, 역시 상당히 인상적이다.

References

1. What’s New in iPhone OS 3.2 (perhaps 4.0?) (wegra.org)
2. iPad UI Conventions (flickr)
3. Editing in Keynote on the iPad (YouTube)

지난달 iPad 발표와 함께 iPhone OS 3.2 가 공개되었다. 이름은 iPhone OS 이지만 정작 iPhone 용으론 제공되지 않고 있어 의미가 퇴색될 수도 있지만, 애플이 iPhone/iPod touch 와 iPad 의 OS 브랜치를 완전히 나눌 가능성은 높지 않아 보인다. iPhone OS 라는 이름을 버리지 않았고, 또 버전도 그대로 계승하고 있기 때문이다.

그렇다면 iPhone OS 3.2 의 상당수 기능들이 4세대 iPhone 으로 녹아들어가는 것이 자연스럽다. 아마도 iPhone OS 4.0 이 될 새 OS 에는 어떤 기능을 기대해볼 수 있을까? 잠시 시간을 내어 정리해보았다.

내가 등록된 iPhone 개발자가 아닌지라 SDK 를 받아볼 수 없다. 따라서 여기서 얻은 정보들은 모두 인터넷에서 구하였다. 주 흐름은 Concentric Sky 사이트의 iPad: What’s new in iPhone OS 3.2 [1] 를 따랐고, 추가 정보들을 이어서 나열하였다.

iPhone OS 3.2 의 새 기능들

Popover

보통 컨텍스트 메뉴라 부르는 기능으로, 마우스 오른쪽 버튼을 눌렀을 때 클릭한 UI 컴포넌트과 밀접하게 관련된 메뉴만 보여주는 것이다. iPhone 에서는 작은 화면때문에 이 기능을 제한하고 있었지만, iPad 는 화면이 넓어 다시 부활시켰다. 사용자가 관심을 보일때, 즉 필요할 때만 나타났다 사라지므로 전체 화면을 깨끗하게 유지할 수 있다. Popover 영역 밖을 클릭하면 사라진다. Popover 는 단순 메뉴뿐 아니라 (다음에 설명할) split view 도 포함할 수 있다.

iPad 의 넓은 화면에 따른 특성이므로 4세대 아이폰에서 활용될 확률은 높지 않다.

iPhone 적용 가능성: low

Split Views

뷰를 분할해 보여주는 전통적인 방식이다. 예를 들어, email 클라이언트에서 좌측 화면에서는 메일 제목 리스트가 나오고, 우측 화면에서는 메일 내용을 보여주는 식이다. 일정 수준 이상 화면이 넓지 않으면 화면 분할은 오히려 역효과가 난다. Popover 와 같이 iPad 가 화면이 넓어지면서 다시 도입된 기능이라 볼 수 있다.

iPhone 적용 가능성: low

Split View in Popover

Popover 와 split view 는 모두 기존 대화면 UI 시스템에서 널리 쓰이던 방식이다. 하지만 애플은 여기서 끝내지 않았다. 애플은 popover 가 split view 를 포함할 수 있도록 했는데, 꾀 참신한 발상이라 볼 수 있다. 아래는 iPad의 기본 메일 클라이언트이다. 가로로 눞히면 좌측의 이미지처럼 split view 형태로 표현되고, 세로로 세우면 split view 가 사라지면서 대신 버튼을 클릭하면 동일한 view 가 popover 로 나타난다. 멋지지 않은가? 약간이나마 iPhone 개발을 해본 감으로는 이 과정에서 개발자가 해줄 것은 없어 보인다. Cocoa Touch 에서 제공하는 controller 가 자동으로 처리해줄 것이다.

또한 아래와 같은 구성도 가능하다.

여기까지는 iPhone 에서는 기대하기 힘든 특성들이다.

iPhone 적용 가능성: low

Custom Input Views

지금까지 iPhone 사용자가 사용할 수 있는 키 입력 방식은 모두 애플에서 기본 제공한 조합들 뿐이었다. 일본 사용자들을 위한 Emoji (아래 그림 참조)가 유일한 예외였다.

애플은 이제 이를 더욱 진보시켜 일반에 공개했다. 어플 개발자들은 자신만의 키보드를 만들어 제공할 수 있다. 예를 들어 삼성 핸드폰 사용자들이 좋아하는 천지인 입력기도 쉽게 구현해 넣을 수 있게 되었다 (라이선스 이슈가 있겠지만). 나아가 꼭 키보드 모델에 국한될 필요도 없다. Speech-to-text 나 제스처 기반 입력 인터페이스도 추가할 수 있다. 고유의 필기인식 입력기도 가능하다. Handwriting 키보드의 프로토타입이 3.2 에 포함되어 있다고 하니, 2개월 이내에 충분히 만족스러운 품질에 도달하면 처음부터 내장되어 나올 것이다.

이 기능은 iPhone 에서도 충분히 유용하기 때문에 충분히 기대해볼만 하다.

iPhone 적용 가능성: high

Gesture Recognizers

지금까지 제스처 인식은 iPhone 어플 개발자들의 불편사항중 하나였다. 멀티터치를 제공하지만 가장 낮은 수준의 이벤트만을 올려주어서 pinch, long press, drag 등 기본적인 동자도 어플 개발자가 직접 인식 코드를 작성해야만 했다. iPhone OS 가 3.2 로 업그레이드 되면서 애플은 이런 기본 이벤트들을 래핑해서 제공해주기로 결정하였다. Custom input view 와 함께 iPhone OS 기반 제품의 입력 방식을 한 단계 진보시킬 수 있는 특성이다.

4 세대 iPhone 에서 기대할 만한 기능이다.

iPhone 적용 가능성: high

External Display Support

연결된 케이블을 통해 화면을 외부 디스플레이로 출력할 수 있다. 지원 모드는 케이블에 따라 1024×768, 480p, 576p, 480i, 576i 이다.유사 기능이 전부터 private API 로 노출되었으나, 이제 공식적으로 제공되는 듯 싶다.

디바이스의 메인 윈도우와 독립적인 화면 출력이 가능하므로 활용 폭은 더 크나. 예를 들어 iPad나 iPhone 으로 프로젠테이션도 가능하다. 단, 케이블을 연결해야하는 문제가 있으니 회의실에서 iPad 로 연결해 사용하는 시나리오만이 가장 그럴듯하다. 대화면 게임, 영화 감상 등 훨씬 현실적인 활용 예도 많다.

이 역시 다음 세대 iPhone 에서 기대해본다.

iPhone 적용 가능성: high

Core Text

고수준의 텍스트 프로세싱 라이브러리로, iWork 와 같은 고급 사무용 문서 제작 어플리케이션 제작을 가능케 한다. 커스텀 폰트 지원, 텍스트 레이아웃을 지원하며, iPhone 의 cut, copy & paste 위젯까지도 변경할 수 있다. 이 기능을 활용하면 선택된 텍스트를 굵게 변경한다던지, 곧바로 Twitter 나 Facebook 에 공유하는 메뉴를 띄울 수도 있다. 사용자가 입력한 글에 대한 스펠링 체커도 제공된다.

스펠 체킹과 Cut, Copy & Paste 위젯 변경 기능은 iPhone 에서도 충분히 유용할 것으로 보인다.

iPhone 적용 가능성: medium-high

File and Document Support (in addition USB Syncing)

iPad 에서는 어플리케이션들에게 공용 문서 폴더를 제공한다. 이 폴더는 USB 로 Mac/PC 에 연결했을 때 Mac/PC 에서도 바로 볼 수 있다. 즉 USB 드라이브 기능을 겸한다. 이 폴더를 이용해 어플리케이션이 데이터 싱크도 할 수 있고, 자신이 처리하는 파일 타입을 등록해두면, 사용자가 해당 파일을 선택했을 때 그 어플리케이션이 자동으로 실행되도록 만들 수도 있다. 또한 브라우저를 통해 파일 업로드/다운로드도 가능할 듯 싶다.

iPhone 에서도 제공한다면 많은 사람들로부터 환영을 받을 기능이다.

iPhone 적용 가능성: high

PDF Generation

PDF 생성 기능은 다이어트 트래킹, 헬스 어플리케이션 등 현황과 추이를 리포트 형태로 뽑아낼 때 유용하다. 작성한 문서나 웹 컨텐츠 역시 PDF 로 저장하기 좋은 대상들이다.

유용한 기능이긴 하지만, iPhone 처럼 작은 화면에서는 유용성이 많이 떨어질 듯 싶다.

iPhone 적용 가능성: medium

Video Conferencing/Calling

iPad 가 iSight 카메라 없이 소개되었긴 하지만 이 기능을 완전히 배제하진 않은 것으로 보인다. 프레임을 분해해보면 MacBook 용 iSight 카메라가 들어갈 수 있는 공간이 마련되어 있다고 하고, 또 iPhone OS 3.2 에서도 이 기능을 노출하고 있다는 것이 그 반증이다. 만약 카메라가 포함된 iPad 가 등장한다면 비디오 컨퍼런싱에 유용할 수 있다.

반대 의견도 있다. 실제 iPad 에 카메라가 부착되어 있다고 가정하고 사용하는 모습을 시뮬레이션해보면, 사진을 찍건, 컨퍼런싱을 하건 대부분의 경우는 다 어색하다는 것이다. 그래서 일부러 제거한 것이라면 또 다른 가능성을 생각해볼 수 있다. 바로 4세대 iPhone 에 어떤 형태로건 이 기능이 추가될 수 있다는 것이다. 예전에 스크린 패널 뒷면에 카메라를 내장하는 특허도 공개된 적 있지만, 상품화 수준까지 쉽게 구현되리란 상상은 잘 되지 않는다. 가능성이 높진 않아 보인다.

iPhone 적용 가능성: medium

Print to Networked Printers

iPad 로부터 네트워크 프로터로 직접 출력이 가능하다. iWork 은 오피스 어플리케이션들을 십분 활용하기 위한 필수 기능중 하나로 판단된다. 봉주즈 기술을 활용하거나 혹은 직접 네트워크 프린터 세팅을 해주면 모바일 기기에서 바로바로 출력이 된다. 편리한 능력이라 할 수 있다.

상대적으로 iPhone 에서의 유용성은 많이 떨어지지만, 외부에서 받은 PDF 나 공용 폴더의 문서, 또는 메일아나 웹 컨텐츠를 즉각 출력할 수 있다는 것만으로도 가치가 있다. 일부러 제한할 필요는 없어보인다.

iPhone 적용 가능성: high

마무리..

잡스는 다음 iPhone 은 A+ 업데이트가 될 것이라 이야기했다 한다. 하드웨어적인 개선도 있을 수 있고, 소프트웨어적 개선 수준도 지금까지 노출된 것들보다 훨씬 뛰어날 수도 있다. 지금까지의 패턴을 보면, 3~4월 즈음에 iPhone OS/SDK 4.0 이 beta 로 공개될 것이다. 그 때가 되면 소프트웨어적인 개선은 대부분 공개될 것이고, 나머지는 하드웨어만 남는다. 그리고 6~7월이면 모든 것이 드러날 것이다. 그 전까지는 Android, webOS, Symbian, bada 등 경쟁 제품들의 깜짝쇼가 있을 지 기대해보자.

1. iPad: What’s new in iPhone OS 3.2 (Concentric Sky)
2. iPad SDK holds hints of video calls, handwriting “keyboard” (Ars Technica)
3. Apple kills USB syncing for apps, but alternative is coming (Ars Technica)

한 4년쯤 전에 정리를 시작했던 주제로, 지인 몇 명과 논문으로 써볼까 기고를 할까 고민하다 제 때 빛을 보지 못했다. 실례를 찾아 보강하는 것이 가장 큰 숙제였는데, 불행히도 그 후 테스트 관련 업무를 접할 기회가 없었어서 기고까지는 하지 못했다.

Testable Design Fundamentals

In other to make software testable, designer should follow some rules. If you are interested in software design, some of them must be familiar to you. That’s because they are rules for improving software ‘design‘ in testability perspective. Lets look into the rules one by one.

1. Clear Specification: Specification should cover all possible situations even for illegal conditions. Moreover, it must be clearly defined without any ambiguous sentences.
2. Controlability: Target should provide mechanisms to read/write the conditions or to run the operations which are required to verify its functionality. It should be easy enough to implement.
3. Modularity: Adequate modularization is one of the fundamental requirements not only for design, implementation, and reuse, but also for test. For an example, a module which has many relationships with other modules is hard to test independently. It should use stub/mock object of wait until the dependant modules are implemented.
4. Readability: Easy and intuitive naming reduces human errors and decreases design/implementation time. It makes overall testing time shorter.
5. Consistency: All of the above rules should be reflected consistently so that the software can be look like designed and implemented by one person.

Software which satisfies these rules can be called testable. However, it is very hard to measure quantitatively how well the rules are reflected. I’ll remain this issue for other dedicated articles.

(in Korean)

테스트 가능한 소프트웨어를 만들기 위해서는, 설계자는 몇 가지 규칙을 따라야 한다. 소프트웨어 설계에 관심있는 사람이라면, 친숙한 이름의 규칙들을 찾을 수 있을 것이다. 이유인 즉, 이 규칙들은 테스트의 관점에서 소프트웨어의 ‘설계‘를 향상시키기 위한 지침이기 때문이다. 그럼 그 규칙들을 하나씩 살펴보도록 하자.

1. 명확한 기능 명세: 소프트웨어 명세서는 잘못된 상황까지 포함한 모든 가능한 상황을 기술해야 한다. 이 때, 의미가 분명한 문장만을 사용해야 한다.
2. 조작성: 테스트 대상은 그 기능 동작 여부를 판단할 수 있는 정보를 읽고/쓰거나 기능을 동작시킬 수 있는 메커니즘을 제공해야 한다. 또한 소프트웨어 적으로 쉽게 구현할 수 있어야 한다.
3. 모듈화: 적절한 모듈화는 소프트웨어 설계, 구현, 재활용 뿐 아니라 테스트를 위해서도 꼭 필요하다. 예를 들어, 다수의 다른 모듈과 종속성이 있는 모듈은 독립적으로 테스트하기 어렵다. Stub/Mock Object를 사용하거나, 타 모듈들이 구현되기까지 기다려야 한다.
4. 가독성: 쉽고 직관적인 이름(모듈, 함수 등 모든 경우에 해당됨)은 휴먼 에러(human error)를 줄여주고, 설계와 구현 시간을 단축시킨다. 결과적으로 테스트에 소요되는 전체 시간을 단축시키는 효과가 있다.
5. 일관성: 이상의 모든 규칙들은 마치 한 사람의 설계하고 구현한 것처럼 일관성 있게 적용되어야 한다. 각각의 모듈마다 그 정도가 다르다면 휴먼 에러(human error)를 증가시킬 것이다.

이상의 규칙들이 충족된 소프트웨어라면 ‘테스트할 수 있다’고 얘기할 수 있을 것이다. 단, 이런 규칙들이 얼마나 잘 반영되었는지를 정량적으로 측정하는데는 분명한 한계가 있다. 측정 이슈는 주제의 범위를 벗어나므로 본 글에서는 더 자세히 다루지 않을 것이다.

(Read the full article)

Spring Framework 관련 한글책[1]을 보다가 Dependency Injection(DI) 의 번역에 대한 역자주에서 생각해볼만한 것이 있어 보충 설명 겸, 잠시 끄적여본다. DI 의 개념이 아직 모호한 사람이라면 이 글을 먼저 읽어본 후 참조한 wikipedia[2] 의 글을 보면 전체적인 윤곽을 잡는데 도움이 될 것이다.

역자주: 종속객체 주입, 즉 DI(dependency injection)는 스프링에서 가장 기본이 되면서도 매우 중요한 의미를 갖는다. 기존에 가장 많이 쓰이던 번역은 ‘의존성 주입’이었다. 그러나 역자가 보기에 이 번역은 ‘없는 의존성을 만들어 주입한다’는 오해를 일으키고, 이 때문에 DI의 이해가 어려웠다고 생각한다. DI 는 없는 의존성을 주입하는 것이 아니라 의존성은 이미 존재하되, 실제 객체가 필요로 하는 종속객체를 주입하는 것을 의미한다. 따라서 ‘의존성 주입’보다 뜻이 명확하도록 ‘종속객체 주입’이라고 번역했다. .. (후략)

일단.. 이 역자가 잘 봤다고 말하고 싶다. DI 에서 dependency 를 의존성으로 번역한 것은 확실히 잘못된 것이다. UML, OOAD 등 지금까지 IT 기술 관련 대부분의 상황에서는 모듈간 관계를 명시하기 위해 dependency 라는 용어를 사용해왔기 때문에 여기서도 습관적으로 의존성이라는 단어를 선택했으리라 생각한다. 하지만 단어는 문맥에 따라 여러 가지 의미를 가지고 있음을 잊어서는 안된다.

DI 을 직역하더라도 의존성 주입은 아니다. 오히려 위 역자가 사용한 종속객체 주입이 더욱 적절하다. 약간 아쉬운게 있다면 DI 는 object 세상에 국한되지 않기 때문에 ‘객체’ 라는 말은 여전히 논란의 소지가 있다는 점 정도. 범위를 제한하지 않으려면 module 정도의 추상적인 용어를 사용할 수 있겠지만, object 라는 용어도 꼭 OOP 에서 말하는 object 로 제한되는 것은 아니니 상관 없을 듯 하다.

그럼 다시.. 왜 직역을 했는데도 종속성은 틀린 것일까? 이는 DI 패턴의 구조[2]를 살펴보면 쉽게 이해가 된다. DI 패턴은 세 개의 요소로 구성된다. 적절한 한글 대용어를 찾기 어려워 대강 번역해보면 이렇다.

이 패턴은 최소 3개의 구성 요소로 이루어진다: dependent와 그의 dependencies, 그리고 injector (혹은 provider, container). Dependent 는 컴퓨터 프로그램에서 작업(task)을 수행해야할 소비자(consumer)이다. 작업 완료를 위해선 특정 부작업들(sub-tasks)을 수행하는 다양한 서비스(dependencies)들을 활용해야 한다. 마지막으로 Injector 는 dependent 와 그에 필요한 dependency 들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.

위 설명에서와 같이 DI 의 dependency 는 객체간의 관계 속성을 의미하는 것이 아니라 서비스를 제공해주는 ‘실체’를 가리킨다. 그 실체를 (의미 그대로) dependent 에서 주입시켜주는 것이다. 위 역자의 용어에 맞추어보면 대략 이렇게 되지 않을까 싶다.

• Dependent: 의존객체
• Dependency: 종속객체
• Injector: 주입자
• Dependency Injection: 종속객체 주입

이 용어들을 적용해 다시 번역해보면 아래처럼 되겠다. 깔끔하려나.. ^^

이 패턴은 최소 3개의 구성 요소로 이루어진다: 의존 객체(dependent)와 그의 종속 객체들(dependencies), 그리고 주입자(injector, provider, or container). 의존 객체는 컴퓨터 프로그램에서 작업을 수행해야할 소비자이다. 작업 완료를 위해선 특정 부작업들을 수행하는 다양한 서비스(종속객체)들을 활용해야 한다. 마지막으로 주입자는 의존객체와 그에 필요한 종속객체들을 조합해서 작업을 수행할 준비를 갖추는 컴포넌트로써, 이 객체들의 전반적인 라이프 사이클을 관리하기도 한다.

1. Spring in Action SE (Craig Walls / 장시형, 전지훈 / Manning)
2. Dependency injection (wikipedia)