안녕하세요? 스프링노트팀의 강규영 입니다. 좀 늦었지만 그래도 후기를 올립니다 ^^

저는 UI에 관련된 주제들만 듣고 왔습니다:

• HCI/RIA를 통한 미래가치 창출
• Better Web, Better UX를 위한 Microsoft의 차세대 웹 전략, Silverlight & Windows Live Service

아래 세션은 (제 기대와 달리) 3D UI에 대한 이야기 아니라 주로 하드웨어나 3D 영상 등에 대한 내용이었어요:

• 3Di 비즈니스모델의 가능성
• 3D 인터넷 산업의 활성화 정책 방향

이중에서, 세번째 트랙의 첫번째 세션인 "HCI/RIA를 통한 미래가치 창출"이 재미있었는데요 다음 커뮤니케이션 UI Engineering 팀의 전정환님의 세션이었습니다. 발표 자료 중간 중간에 아는 분들 얼굴도 나오고 해서 특히 재미있게 봤습니다. 간단히 요약하자면 "한메일 익스프레스 개발 사례를 통해 살펴보는 RIA 개발 방법론 소개"입니다. 앞 부분에서는 HCI와 RIA 개념, 웹 2.0과 HCI 등을 간단하게 소개해주셨는데 이 부분은 생략하도록 하고, 프로세스나 방법론에 대해 말씀해주신 중간 부분부터 요약하겠습니다.

우선, RIA 프로젝트를 진행할 때 기존의 흔한 서비스 개발 프로세스를 그대로 적용할 경우 발생하는 문제들을 지적하고 있는데:

• 파워포인트로 작성된 두꺼운 기획서
• 기획 단계와 개발 단계의 엄격한 분리
• 팀간 커뮤니케이션의 어려움
  

등을 언급하셨습니다. 사실 이러한 문제는 기존에도 존재했지만 RIA 프로젝트의 특성 즉, 풍부한 사용자 경험을 제공하는 애플리케이션을 개발해야 한다는 특성으로 인해 기존에 존재하던 문제들이 더욱 부각되는 것이 아닐까 하는 생각을 해보았습니다. 예를 들어 동적이고 풍부한 사용자 인터페이스를 기술하기 위한 수단으로 파워포인트 기반 기획 문서는 그다지 비용-효과적인 방법이 아닙니다, 또, 기존에 존재하는 표준 인터페이스 이외의 새로운 인터페이스를 개발하고 사용자 경험을 향상시키기 위한 여러가지 실험을 해야하는 RIA 프로젝트의 경우, 기획/디자인/개발 단계를 엄격하게 분리하는 것은 작업 효율을 크게 저하시키는 요인이 될 수 있습니다.

한메일 익스프레스 프로젝트에서는 이 문제에 대한 대안으로 사용자 중심 디자인(User Centered Design - UCD)과 기민한 개발 방법(Agile Development)을 혼합한 프로세스를 적용했다고 합니다. 구체적인 실천법(practice)으로는 다음과 같은 것들을 언급했습니다:

• 페이퍼 프로토타이핑과 롤플래잉
• 화면 디자인이 붙지 않은 초기 단계부터 사용자를 참여시키고 피드백을 받기
• 반복적(iterative) 개발
  

첫번째로 언급된 페이퍼 프로토타이핑과 롤플래잉은 종이와 연필(그리고 사람 ^^)만 있으면 당장 해볼 수 있는 훌륭한 기법 중 하나입니다. 새로운 UI를 적은 비용으로 단기간에 실험해볼 수 있다는 표면적인 장점 이외에도, 기획/개발/디자인 직군 간의 대화와 협업을 장려한다는 숨은 장점도 갖습니다. 스프링노트 팀에서도 이 기법을 변형하여 종종 사용하는데, 며칠 전에는 툴바/다이얼로그 개선안에 대해 "포토샵"을 이용한 롤플래잉을 시도해보기도 했습니다, 손이 빠른 디자이너가 포토샵을 조작하여(레이어를 크고 켜거나, 순식간에 요소들을 이리저리 옮겨가면서) 이런저런 UI를 시뮬레이션 해주는 것이죠. 좋은 경험이었습니다.

두번째로는, 개발 속도를 빠르게 하기 위해 화면 디자인이 없는 상태에서 기능 일부를 먼저 구현하는 방식을 소개해주셨는데, 이 방식에는 장단점이 있을 것 같습니다. 예를 들어 "루비 온 레일즈"로 유명한 37signals 에서는 "Getting Real"이라는 책에서 화면 디자인을 가장 먼저 하는 방식을 추천한 바 있습니다. 발표가 끝나고 질문을 할 기회가 생겨서 이 방법에 대해서는 어떻게 생각하시는지 질문을 했었는데, 제 질문 의도가 명확하게 전달되지 않을 것 같았어요. 세션이 끝난 후 휴식시간에 쇼파에서 쉬다가(이 글을 적고 있었어요 ㅎㅎ) 우연히 전정환님, 그리고 같은 팀의 정규돈님을 만나서 이 문제에 대해 이야기를 더 나눌 수 있었습니다. 사이트 특성에 따라 화면 디자인을 붙이는 적절한 순서가 있을텐데, 한메일 익스프레스 프로젝트의 경우에는 기능 구현을 먼저 하는 방법이 더 적당하다고 판단했고, 현재에도 새 기능을 추가할 때 디자인 없이 기능 구현을 먼저 하는 순서를 따르고 있다고 합니다. 참고로 스프링노트 팀에서는 주로 화면 디자인을 먼저하는 방식으로 하고 있습니다.

마지막으로 소개해주신 반복적 개발(iterative development)은 일주일에서 한달 정도의 짧은 주기를 반복하면서 점진적으로 기능을 추가/개선하는 방식을 말하는데, 이 또한 여러가지 장점이 있는 방법으로 널리 알려져 있습니다. 하지만 제 경험상, 반복적 개발을 RIA 프로젝트에 적용하고자 할 때엔 추가적으로 고려해야하는 부분이 있는 것 같습니다. 바로 디자인인데요, 기획이나 개발 파트의 경우 반복적인 작업이 비교적 용이한데, 디자인의 경우 반복(iteration)이 아닌 재작업(rework)을 하게 되는 경우가 많은 것 같았습니다. 예를 들어 개발 파트에서는 리팩토링이나 테스트 자동화 등과 같은 실천법을 통해 반복적 개발을 효과적으로 수행할 수 있는데, 디자인 파트의 경우 반복적 작업의 효율을 높이기 위한 좋은 실천법이 충분히 개발되지 못한 것 같아요. 스프링노트 팀에서는 반복적 프로세스를 유지하기 위해 디자인 파트에서 "재작업"이라는 부담(혹은 희생)을 지고 가고 있는 상황입니다.

어... 맺음말은 없습니다. ㅋㅋ