»
S
I
D
E
B
A
R
«
Small but meaningful turning point..
Feb 17th, 2010 by Wegra Lee

From bad team cultures to good team cultures, the transition begins now.

At last I successfully moved to other department about 8 months after I had decided to do it.

It’s a new challenge for me. I’ll be in charge of leading one small development group. The size of it is not decided yet, but expected less than 4 at the beginning. That is perfect to make a robust and productive self-organized team. I’m very excited at the fact that I finally get a chance to do the things what I believe right.

Hopefully, I wanna meet talented and open-minded persons. If not, I must spend much more time to share the visions, philosophy, values, etc. I have plan to overcome it and I can do that, anyway.

Vision is also very important. At that time I led the Mobile SecondLife project around one and half years ago, the situation was really terrible. No developer believed the project has any reasons to keep going. We could say for sure that if we would unveil the product to the public, everyone will laugh, and no one will use it. What if I had the right to decide? Definitely I would cancel it as soon as possible, and dispatch those talented engineers to other valuable projects. Even with the talented members, the project ended up with nothing. Nothing at all. Except some lessons. : )

I learned many lessons from the project. The most important one among them is that a leader must fulfill at least one desire that every members can share and agree on. Here are some examples.

  • The project must be fun. It’s the thumb of the rules.
  • The project must be successful at least from the technical perspective.
  • The product must be meaningful, so members can write its name to their resume with proud.
  • Member’s capabilities must got improved continuously.

I’ll do my best to gift my coworkers an unforgettable experience in a good way.

Cumulative Flow Chart in Kanban: Real Usage Example
Feb 16th, 2010 by Wegra Lee

Edge of Chaos | Agile Development Blog 에 Kanban 의 Cumulative Flow Chart 활용 예[1]가 실려서 옮겨본다.

(Kanban 에 대한 배경 지식이 전혀 없다면 One day in Kanban land [2] 를 먼저 읽어보고 오자. 흥미가 생긴다면 Lean and Kanban[3]의 글들을 시간을 두고 찬찬히 읽어보길 권한다.)


Cumulative Flow 다이어그램을 잘 활용하면 라인 정지(stop-the-line)[4] 나 애자일 회고(retrospective)를 시작해야할 시점을 쉽게 발견할 수 있다. 여기 TargetProcess[5] 개발 과제로부터 실례가 있다.

차트를 보면 우리가 12월 초에 병목을 겪었음을 볼 수 있다. 꾀 복잡한 유저 스토리 하나가 원인이었다. 이론적으론 유저 스토리 하나가 개발 주기에 심각한 영향을 미치거나 병목을 발생시키면 안되지만, 규칙을 조금 어기면 실제 그런 일이 일어날 수도 있다.

문제의 유저 스토리는 jQuery 자바스크립트 프레임워크를 ExtJS 프레임워크[6] 로 교체하는 것이었다. 이 작업은 개발자 한 명이 별도의 브랜치에서 1개월에 걸쳐 구현하였다. 그 한 달 동안 나머지 멤버들은 몇 차례의 릴리스를 성공적으로 마쳤다. 테스터들은 그 유저 스토리에서 별 문제점을 발견하지 못했고, 인수 테스트(acceptance test) 역시 모두 통과하였다. 이 코드를 메인 코드 브랜치에 반영하는 것은 당연한 수순이었고, 그렇게 했다.

불행히도, 코드 반영 후 스모크 테스트 중 꾀 많은 빌드 에러들이 발생하였다. 버그를 다 잡는데는 1주일 이상이 소요되었고, 그 동안 우리는 아무것도 릴리스하지 못했다. 이미 반영된 코드를 다시 롤백하는 것 역시 만만치 않았기 때문에 뾰족한 수가 없었다.

여기서 얻은 교훈은 근본적으로 보다 복잡한 유저 스토리에는 테스트에 더 많은 노력을 들이라는 것이다. 이런류의 스토리는 어플리케이션에 다방면에 걸쳐 영항을 미치고, 보통의 스모크 테스트만으론 충분치 않다. 그래서 우리는 병합 전에 더 세심한 테스팅과 검증이 필요함을 의미하는 새로운 부류의 서비스를 제공할 것이다. 일단 “기술적으로 복잡한 스토리”라고 불러보자.

일반적으로, Cumulative Flow 차트는 과거 데이터를 분석하는데 훌륭한 툴이긴 하지만, 긴급한 병목을 식별해 내는데는 Kanban Board 가 훨씬 효과적이다. Kanban Board 에서 최대 허용 작업 수(limit)에 도달함은 곧 무엇가 문제가 있음을 뜻한다.


References

  1. Cumulative Flow Chart in Kanban: Real Usage Example (Edge of Chaos | Agile Development Blog)
  2. One day in Kanban land (wegra.org)
  3. Lean and Kanban
  4. Stop-the-line (Thoughts in the Wilderness)
  5. TargetProcess
  6. ExtJS framework (Ext JS)
수용하기.. 혁신을 이끌어 내는 방법
Feb 9th, 2010 by Wegra Lee

쉬어가기[1]는 창의력을 끌어내는데 주안점을 두고 있고, 직접보기[2]는 생각을 현실화시켜 진정 원하는 것을 찾아가는데 초점을 맞추고 있다.

그리고 이제부터 살펴볼 수용하기는 변화를 권하고 받아들임으로써 개발자들에게 능동적 에너지를 불어 넣으려는 자세이다. 따라서 조직에서 권한을 쥐고 있는 윗사람들에게 크게 요구되는 자세이다.

조직에 변화를 불러 일으키려 할 때, 윗사람이 주도하는 하향식(top-down) 시도는 좋은 결과를 낳기 어렵다[3][4]. 특히나 한국처럼 수직적 위계질서가 철저한 문화에서는 윗사람의 지나가는 말 한 마디가 수십, 수백명을 고생하게 만들 만큼 파급이 크다. 심지어 조직 운명이 뒤바뀌기도 한다. 때문에 설사 올바른 말을 하더라도 확대 해석되고 준비도 없이 무조건적으로 즉시 수행하려해서 한 바탕 소동이 벌어지곤 한다.

효과적이고 지속적인 변화를 위해 윗사람에게 필요한 자세는, 변화를 겸허히 수용하고, 그런 분위기를 조성하고 문화를 만들어가는 것이다.

잠시 아쉬운 경험담을 하나 떠올려보겠다. 얼마전 수백명에 달하는 조직 구성원 전체가 모여 이것 저것을 공유하는 자리가 있었다. 그 중 임원들에게 궁금한 것을 여쭐 수 있는 시간이 주어졌고, 이런저런 이야기를 하다가 한 임원께서 조직의 변화에 대해 잠시 언급하셨다.

“조직은 쉽게 변하지 않는다. 조직이 변하길 기대하기보단 각자의 위치에서 스스로 변화시킬 수 있는 것을 찾아보아라.”

다소 차이가 있을 수 있으나 내가 이해한 의미는 이렇다. 현실의 모습을 있는 그대로 솔직히 이야기한 것이고, 남에게 바라기 앞서 스스로 변화를 시도하라는 좋은 이야기였다.

하지만 난 이 말에 적잖이 실망할 수 밖에 없었다. 왜일까? 만약 이렇게 이야기했다면 어땠을까?

“조직은 쉽게 변하지 않는다. 하지만 좋은 의견을 주면 내가 힘이 닿는데까지 그렇게 변화시킬 수 있도록 도와주겠다. 중간층에 있는 분들도 팀원들이 좋은 아이디어를 주면 최대한 반영할 수 있도록 힘써달라. 만약 내 힘이 필요하다면 누구든 도움을 요청하라. 다함께 힘이 닿는데까지 일할 맛 나는 팀을 만들어보자.”

조직은 쉽게 변하지 않는다는 사실엔 변함이 없다. 하지만 전자는 개인의 변화 의지를 크게 억누르는데 반해, 후자는 의욕을 한층 불살라줄 것이다.

중요한 것은.. 말과 격려에서 끝나면 안된다는 것이다. 불편사항을 누구든 편하게 개진할 수 있고, 개선 방법을 논의할 수 있는 장을 마련해 주어야 한다. 사람들이 쉽게 나서지 못한다면, 익명이 보장되는 토론장을 만들어주는 것이 큰 도움이 될 것이다. 애자일 회고(Retrospective) 제도[5]를 도입해 보는 것도 적극 권장한다. 그리고 이렇게해서 나온 좋은 아이디어들을 작은 것부터라도 하나씩 수용해가며 차근차근 개선되는 모습을 보여줘야 한다.

그럼 윗사람들이 주의해야할 점 몇 가지 집어보자.

‘이봐들! 개선 아이디어를 가져와봐!’ 라고 강압하는 것은 좋지 않다. 이런 명령은 실무자들이 스스로 불편사항을 찾고 자율적으로 개선해나가는 분위기에 찬물을 끼얻을 우려가 있다. 단, 익명 보장 등 조치를 취해 주었는데도 아무도 의견 개진 없이 시간만 흐른다면 한 번쯤 발동을 걸어주는 것은 필요할 수 있다.

‘얼마나 개선되었는지 보고해봐!’ 와 같은 요청은 더 큰 위험을 안고 있다. CMMI 나 SPICE 등 개발 역량 평가 모델의 더 높은 등급을 받기 위해 벌어지는 상황이 재현될 가능성이 높다. 다시 말해 수치적으로 측정 가능하고, 형식적인 변화에 치중될 우려가 생긴다. 심할 경우, 개발자들은 변화에 회의를 느끼고 더 이상 적극적으로 참여하지 않게 될 것이다.

가만히 놓아 두어도 개발자들은 알아서 쓸데 없는 일과 꼭 필요하지만 귀찮은 일 그리고 수작업 등을 줄이고 생산성을 높이는 방향으로 변화시킨다. 더 효율적인 솔루션을 찾아 시도해보고 적용한다. 물론 시행착오를 거친다. 그래서 더 안좋아지는 부분이 생기면 되돌아가거나 다른 안을 시도해보며 결국 생각할 수 있는 최선의 방식으로 수렴해간다. 제도와 권위로 가둬놓지만 않으면 팀은 좋은 방향으로 진화해 나갈 수 있다.

정리해보자.

  • 윗사람은 변화를 주도하기 보다는, 변화 에너지를 불어 넣고 변화를 돕고 그 모습을 수용하자.
  • 아랫사람은 능동적으로 변화에 참여하고 장단점을 몸소 체험하며 배우자.
  • 상향식도 하향식도 아니다. 함께 만들어가는 변화이다.

References

  1. 쉬어가기.. 혁신을 이끌어 내는 방법 (wegra.org)
  2. 직접보기.. 혁신을 이끌어 내는 방법 (wegra.org)
  3. 하향식 변화 도입에 대한 환상 (김창준, 애자일 컨설팅)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Bad Team Culture – Lessons Learned as a Last Will (wegra.org)
[updated] Talk about the Apple iPad
Feb 8th, 2010 by Wegra Lee

Charlie Rose 라는 프로그램에서 전문 저널리스트들을 모아 iPad 에 대한 의견들을 나눠보았다.

패널 구성은 이렇게..

Charlie Rose (Host)

Walt Mossberg (The Wall Street Journal)

David Carr (The New York Times)

Michael Arrington (TechCrunch.com)

그리고 여기 김주영이라는 분께서 트위터에 한글로 열심히 번역해 주신 글이 있다. 공감가는 이야기들을 많이 하고 있다.

[updated] 김주영 님의 번역 중 스티브 잡스에 대한 평 일부를 발췌해본다.

Walt Mossberg : iPad는 CEO로서 Steve Jobs를 이해할 수 또 다른 예라고 생각합니다. 그는 시장조사형 비즈니스맨이 아닙니다. 고객들에게 개선필요 사항을 묻거나 하지 않습니다. 대신 소비자 자신도 알지 못하는 필요를 알아내서 뛰어난 디자인의 제품으로 만들어내서 이들을 사로잡는 거죠. Steve Jobs는 중대하고도 대담한 결정을 피하려하지 않습니다. 애플, 픽사 그 밖에 비즈니스맨으로 그의 발자취를 보면 잘 드러납니다. 한 편으로는 크게 실패할 위험이 있다는 말도 됩니다.

Walt Mossberg : 실패보다는 성공할 가능성이 크다고 생각은 합니다. 하지만 Steve Jobs는 모두가 시도했다가 실패한 영역으로 뛰어들었습니다. 심지어 빌게이츠처럼 똑똑한 사람도 윈도우즈 테블릿PC에 열정을 쏟았지만 대실패였지요. Steve Jobs는 기술, 소프트웨어, 하드웨어를 한데 모아 버무려서 새로운 제품을 시도하고 어떤 점이 사람들을 흥분시키는지고 매혹시키는지를 소비자들에게 이해시키는 사람입니다. 이것이 곧 그의 스타일인거죠.

Nexus One: The Stories
Feb 8th, 2010 by Wegra Lee

구글다운 발상의 Nexus One 홍보이다.

차례로, Nexus One 의 제작 과정을 주로 하드웨어에 포커싱해서 보여주고 있다. 이름있는 거대 폰 제조사들은 이와 별반 차이 없는 과정을 통해 폰을 제조할 것이지만, 일반인에게는 생소한 현장의 모습을 멋전 앵글에 담아 전문적이고 신뢰할 수 있다는 이미지를 심어주는 듯 하다.

테스팅 과정에서의 추락(tumble) 실험이 인상적이고, 의외로 아직 사람의 손이 많이  간다는 생각이 들었다.

Nexus One: The Story – Episode 1: Concept & Design

Nexus One: The Story – Episode 2: Display & 3D

Nexus One: The Story – Episode 3: Testing

Nexus One: The Story – Episode 4: Manufacturing

iPad UI Conventions
Feb 5th, 2010 by Wegra Lee

얼마전 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)
Apple, A4 칩의 의미
Feb 5th, 2010 by Wegra Lee

최근 지인으로부터 애플이 자체 설계한 A4 칩을 공개한 이유와 숨은 전략은 무엇일까 라는 질문을 받고 간략히 생각나는대로 대답해 주었다. 이 글은 그 대답을 토대로 정리해본 글이다.

먼저 A4 에 대해 알아보자. A4 는 애플이 iPad 를 위해 직접 설계한 핵심 SoC 칩으로[1], 애플이 제작년쯤 인수한 fabless 칩 설계 회사인 P.A. Semi 팀에 의해 제작되었다. 하지만 직접적으로 공개된 정보라고는 1GHz 라는 것 외에는 없다. ARM 계열인 것은 분명하지만, Cortex A8 인지, A9 인지도 불분명하고, 코어 개수가 2개인지 4개인지, 혹은 1개뿐인지도 역시 모른다. 통합된 GPU 는 이전까지처럼 Imagination Technologies 사의 PowerVR 계열인지, 이마저도 자체 설계했는지도 알 수 없다. 그야말로 가장 핵심중 하나이면서도 미궁속에 가려진 비밀스런 부품이다.

이렇게 중요한 정보들을 숨긴체 딸랑 ‘우리가 설계했고 1GHz 로 동작하는 칩이다’ 는 사실만 공개한 애플의 의도는 무엇일까? 그 질문에 대한 ‘내가 애플이라면’ 식의 답변들이다.

1. 자사가 코어 기술력을 확보하고 있음을 보여줌으로써, 회사의 신뢰도를 높이고 혁신 기업이라는 이미지를 더욱 강하게 쌓는다.

2. 타사에서 H/W 스펙만으로 비교 홍보하는 것에 대한 방어 수단이 될 수 있다.

같은 칩을 사용했다면 코어 수가 많고 클럭이 높은 제품이 raw performance 가 좋다는 것은 부인할 수 없는 사실이다. 하지만 이처럼 상세 내용을 꼭꼭 숨긴 칩이라면 이런 류의 공격을 효과적으로 방어할 수 있다. 클럭까지 숨겼다면 더욱 완벽할듯 한데.. 이를 공개한 정확한 의도는 알 수 없다.

3. 자체 기술력 확보를 통해 특정 회사와의 종속성을 약화시킨다.

지금까지 iPhone 에 들어가는 SoC 는 삼성이 설계/제조한 것으로 알려져 있다. 하지만 이제부터는 삼성이 아닌 다른 foundry 업체에도 주문이 가능할 것이다. 칩 물량 조달의 유연성을 증가시키고 향후 삼성보다 더 앞선 기술력의 foundry 가 있다면 옮겨탈 수도 있다. 물론 가격 협상에도 유리한 위치를 잡게 된다.

4. 자사 제품의 출시 주기와 동기화시킨다.

애플은 대략 1년 주기로 신제품을 출시한다. 신제품 출시 시에 소프트웨어뿐 아니라 하드웨어까지 함께 업그레이드해서 wow! effect 를 최대화 시키는 것은 선호되는 제품 판매 전략 중 하나이다.

하지만 SoC 를 만드는 타사의 기준으로 봤을 때, 고객은 애플만이 아니다. 자체 개발 사이클이 있고, 경쟁 회사가 있고, 또 고객은 애플만이 아니다. 좋은 제품을 하루라도 먼저 내놓아 수많은 고객사들에게 홍보해야만 한다. 따라서 애플의 스케줄을 기다려주지 않는다. 오히려 애플의 경쟁사들이 애플보다 먼저 칩을 확보해 하루라도 빨리 출시하려 열을 올린다. 실례로, Palm Pre 는 iPhone 3GS 와 동급의 칩을 탑재하고 이를 홍보하면서 더 일찍 시장에 출시되었다. 결과적으로 큰 타격을 입진 않았지만, iPhone 3GS 의 wow effect 는 감소할 수 밖에 없다. 또한 최근 공개된 Google Nexus One 부터 시작해서 경쟁적으로 쏟아지는 high end 제품들은 iPhone 3GS 보다 월등히 빠른 CPU 를 탑재하고 있고, 기술적으로 봤을 때 4세대 iPhone 역시 이 정도 수준의 CPU 를 탑재할 것이 뻔하다.

2번의 이유와 함께 고려해보면, 자세한 내막을 숨긴 커스텀 칩을 사용시에는 애플 신제품의 비교 대상은 애플의 전세대 제품 밖에 없다는 이점이 발생한다. 먼저 치고나온 경쟁사 제품들로 인한 wow effect 감소를 약화시키는 효과가 생길 것이다.

5. 애플 제품이 요구하는 블럭만을 조합하여 칩의 원가, 전력, 면적 등을 절감시킨다.

애플의 제품은 타사 유사 제품들에 비해 제한된 기능만을 제공하는 것이 특징이다. LCD 도 하나뿐, FM 라디오도 없고, DMB, 외장 메모리 등등.. SoC 제작사 입장에서는 많이 쓰일만한 이런 기능들을 되도록 갖춰주는 것이 판매 시장이 커지므로 쉽게 버릴 수 없다. 물론 그들도 다양한 라인업을 구성하고 대응하지만 애플 입장에서 딱 맞는 것은 찾기 쉽지 않을 수도 있다.

만약 정말 이런 상황이고, 불필요한 컨트롤러 블럭을 제거하는 것이 충분한 이점을 제공한다면 커스텀 칩을 설계하지 않을 이유가 없다. 전력 소비를 줄이고, 면적을 줄여 제조 원가를 낮추고, 혹 제거한 면적만큼 연산 유닛이나 캐쉬 등 성능을 향상시킬 수 있도록 최적화할 수도 있다. 이는 결국 제품 디자인과 소프트웨어 최적화에까지 이어질 것이다.

(SoC 들에 대해선 자세히 분석해보지 않았기 때문에 다소 억지스러운 추측일 수 있다.)

6. 철학적인 면도 있을 수 있다.

2007 년 스티브 잡스가 아이폰을 처음 발표[2]할 당시 이런 말을 인용한 바 있다.

“People who are really serious about software should make their own hardware.”

- Alan Kay

내 나름의 해석은 이렇다. 소프트웨어와 하드웨어는 완전히 독립된 개체가 아니다. 소비자는 이 둘이 융합된 하나의 제품을 경험하게 된다. 따라서 최상의 제품을 제공하기 위해서는 이 둘을 완전히 하나로 융합시켜 사고하고 만들어야 한다. 서로가 상대를 제약하거나, 다른 쪽이 활용하지 못하는 요소가 포함되어 있는 것은 낭비이다.

물론 철학만으로 도전하기에는 무리수가 많을 수 있다. 현실적인 뒷받침이 필요한데, 앞서 떠올려본 1~5 번이 그에 해당한다.


References

  1. [iTunes podcast] Apple announces iPad (Apple Keynotes)
  2. [iTunes podcast] Macworld 2007 Keynote Speech (Apple Keynotes)
What’s New in iPhone OS 3.2 (perhaps 4.0?)
Feb 4th, 2010 by Wegra Lee

지난달 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 등 경쟁 제품들의 깜짝쇼가 있을 지 기대해보자.


References

  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)
애자일 도입 실패 이유?
Feb 3rd, 2010 by Wegra Lee

STEN [1] 에서 재미난 설문을 하고 있다. 아직 진행중이지만 상황을 대략 파악할 정도는 나온 듯 싶다.

“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?”

1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%)
2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%)
3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%)
4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%)
5. 기타 (1.6%)

나는 4번을 찍었다. 물론 다른 이유들도 많다. 예를 들어 팀원 & 조직 전체가 변화의 필요성에 대해 공감한 상태에서 진행하느냐도 포함될 수 있다. 그리고 어느 하나의 이유보다는 여러 가지가 복합적이다.

나도 애자일 도입을 외치지만, 수많은 경험을 통해 아주 신중하게 접근해야 함은 뼈저리게 느끼고 있다. 어설프게 접근했다가는 ‘해봤는데.. 별 효과 없더라.’라는 부정적 인식만 남기기 쉽기 때문이다. 그리고 이는 소위 heavyweight 개발 프로세스 등 SE 가 지금껏 저질러왔던 과오이다. 애자일에서도 똑같은 일이 반복된다면 개발 문화를 개선할 수 있는 기회가 언제 다시 올 지 예측하기 어렵다.


References

  1. STEN (Software Test Engineer Network)
[updated] 직접보기.. 혁신을 이끌어내는 방법
Feb 2nd, 2010 by Wegra Lee

쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.

‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.

정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.

시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.

혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.

이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.

고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.

이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.

  1. 내가 말했던 건 이게 아니었어요. 이러저런 모습을 상상했었는데요. 다음 릴리즈땐 이렇게 고쳐봐주세요.
  2. 내가 의도했던게 이게 맞긴 한데.. 직접 써보니 좀 이상하군요. 다른 아이디어가 있을까요?
  3. 이 부분은 제 생각과 다르긴 하지만.. 솔직히 지금이 더 좋아 보이는군요. 이대로 갑시다.

직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.

또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.

이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.

결론?

조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]

[updated]

사례를 몇 가지 추가해보기로 하였다.

  • Developing Torchlight [5] – Runic Games 사에서 Torchlight 라는 게임을 제작하는 방식을 이야기한다. 그들은 짧은 주기로 항시 play 가능한 게임을 만들어 개발자, QA 팀, 심지어 그드의 가족, 친구들까지 초대해서 게임을 즐기게 했다고 한다. 시장에서의 성공 여부는 아직 판가름하기 이르지만 기대를 가지고 지켜보고 있다.
  • 와우 성공 요인은? [6] – 초창기 와우 개발을 이끌었던 블리자드의 수석 PD 인 셰인 다비리 를 인터뷰한 내용이다. 초창기 가장 어려웠던 점 중 하나는 블라지드로써는 낯선 장르였던 MMORPG 의 비전을 경영진에 설득하는 것이었다고 한다. 직접 만들어 알파 버전을 보여주니, 절대 성공할 수 없다고 말하던 사람마저 하루 아침에 자신의 편이 되었다 한다.
  • Eclipse [7] 와 Jazz/RTC [8] – 오픈소스 개발 환경 프로젝트 중 역사상 가장 성공적인 프로젝트 중 하나인 Eclipse 와 그 개발 과정에서 얻은 노하우까지 툴에 녹이고 있는 Jazz/RTC 프로젝트도 좋은 예가 될 수 있다. 이들은 1년 주기의 정식 릴리스 사이에 6주 정도의 간격으로 다수의 안정적인 Milestone 버전을 내놓는다. 그리고 이전 릴리스 대비 어떤 기능이 개선되었는지 알기 쉽게 보여주는 New & Noteworthy 를 함께 알려주어서 사용자들이 정식 릴리스를 기다리지 않고도 새로운 기능들을 빠르게 접해볼 수 있다. Milestone 버전은 충분히 안정적이기 때문에 critical 한 프로젝트가 아니면 큰 부담 없이 새 milestone 을 테스트해본다. 이런 방식으로 사용자 커뮤니트의 빠른 피드백을 유도해 지속적으로 다음 릴리스에 반영해나간다.
  • Mobile SecondLife [9] – 내가 참여해 진행하다 중단된 프로젝트다. 과제 초창기부터 개발진에서는 도저히 성공 가능성이 없다고, 이걸 누가 쓰겠냐며 과제의 의미를 찾지 못하고 있었다. 링크의 데모는 연구 성격의 개념적 시연이어서 상당히 제한적인 환경에서만 동작 가능했다. 이를 바로 상품화하려 하니 현실적인 제약들 때문에 흥미로운 개념들의 거의 모두를 다 들어낼 수 밖에 없었다. 남은 것만으로는 정말 시도할 가치가 없는 과제였다. 하지만 그 목소리가 경영진에까지 전파되지는 못했다. 수개월간의 고생 끝에 만들어진 베타 버전을 임원에게 시연한 바로 다음날 과제는 바로 중단되었다.

References

  1. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
  2. You Can’t Innovate Like Apple (Pragmatic Marketing)
  3. 유명 마케터 이해선 대표의 메시지 (제레미의 TV 2.0 이야기기)
  4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
  5. Agile Approach in Game Development (wegra.org)
  6. 와우 성공 요인은? 전 수석 PD 셰인 다비리 인터뷰 (Inven Communications)
  7. Eclipse (Eclipse Foundation)
  8. Jazz/RTC (IBM Rational)
  9. Mobile SecondLife (Samsung)
»  Substance: WordPress   »  Style: Ahren Ahimsa