스프링노트 서비스가 오픈을 했습니다. 오늘은 서비스 자체보다 개발 모델에 대해 이야기를 해보겠습니다.

스프링노트에는 사용자 커뮤니티가 있습니다. 간단한 게시판으로 구성되어 있는데, 거기에 사람들이 개선 아이디어와 버그 보고 등을 올리고 있습니다. 그리고 개선 아이디어에 대해서는 투표를 할 수 있습니다. 표를 많이 받은 아이디어는 우선적으로 구현이 되겠지요. 상당히 민주적인 시스템입니다(민주주의가 최선인지 아닌지의 문제는 차치하고). 또한 현재 개발팀에서 하고 있는 작업이 무엇이고 앞으로 무엇을 할 건지를 모두 공개하고 있습니다. 사용자 커뮤니티 첫 페이지에 가면 "완료된 작업", "현재 작업중", "작업 예정중"이라는 제목을 달고 있는 포스트 잇이 세 장 나란히 붙어 있습니다. 투명하고 개방적인 서비스 개발 모델입니다. 또한, 매일 매일 버그 수정이 있으며 2주에 한 번 씩 큰 기능 개선이 이루어집니다. 빈번한 릴리스와 지속적 개선이 이루어지고 있습니다. (이런 점들을 묶어서 저의 변화 유지 비결 글과 연결한 블로그 글 [1], [2]도 있네요)

투명성, 지속적 개선, 사용자 피드백 등 모두 여러가지 이유에서 실행에 옮기기 어려운 것들이지만 스프링노트는 고무적 결과들을 보여주고 있습니다. 국내의 다른 서비스들과 비교하면 매우 진보한, "웹2.0스러운" 개발 방식이라고 생각합니다. 정말로 사용자를 고려합니다.

스프링노트는 개발 초기부터 사용자와 긴밀한 관계를 가져왔습니다. 초기에 사용자 연구(user research)를 했고, 당시 참가자들을 대상으로 클로즈드 알파/베타를 하고 점차적으로 사용자 숫자를 늘려왔습니다. 이 과정에서 사용에 대한 구체적이고 값진 피드백을 얻었고 이는 다시 좀 더 가치있는 서비스를 만드는 비료가 되어 왔습니다.

하지만 보통 많은 서비스들은 사용자를 크게 고려하지 않습니다. 그게 문제가 됩니다. 사용자가 무엇을 생각하는지, 그 서비스를 어떻게 사용할지에 큰 관심이 없거나, 있다고 해도 상상을 하는 선에서 끝납니다.

사용성 전문가 제이콥 닐슨(Jakob Nielsen)의 역작, 사용성 공학(Usability Engineering)이라는 책에 다음과 같은 이야기가 언급됩니다.

Designers Are Not Users

...
A survey of 2,000 adults in Oregon showed that only 18% could use a bus schedule to find the time of departure [Egan 1991]. This finding does not indicate that the remaining 82% of Oregonians are less intelligent and should never be allowed on a bus. Instead, the likely explanation is that the bus schedule was designed by people with extensive knowledge of buses and local transportation who just knew the meaning of every element on the schedule, and therefore never considered that parts of it might be difficult to understand for people who rarely take a bus.

(강조는 김창준)

싸이월드의 C2 프로젝트는 "리드 유저"라는 용어를 쓰더군요. 리드 유저 프로세스(Lead User Process, LUP가 도대체 뭔지 궁금하시다면 이 동영상을 권합니다)를 사용하고 있는지는 모르겠습니다. 제가 보기에는 거의 테스트 단계에 이르러서 리드 유저로부터 피드백을 받는 것 같던데(서비스 기획/개발 과정에 대한 자세한 정보는 없기 때문에 전적으로 제 추측입니다), 문제는 그 시점에는 바꿀 수 있는 것들의 범위가 그리 많지 않다는 점이죠. 그러면 통상 그들의 피드백은 일종의 자기 정당화(self-justification) 목적으로 사용되기 쉽습니다.

이렇게 개발이 거의 완료된 시점에 하는 사용자 테스트를 총괄적(summative) 테스트라고 합니다. 주로 우리가 만든 것이 얼마나 좋은 반응을 받는지 확인하는 데 사용하죠. 반대로 형성적(formative) 테스트가 있습니다. 기획/개발 초기나 한참 진행 중에 실시하며, 이를 통해서 향후 개발 방향과 계획을 수정하게 하는 테스트입니다. 많은 서비스들이 너무 늦은 시점에 테스트를 합니다. 그러면서 사용자를 고려했고 피드백을 받았다고 말합니다. 하지만 상당수 표면적인 수정만 하게 됩니다. 결국 총괄적 테스트의 한계인 것이죠.

반대로 스프링노트는 초기부터 사용자들의 피드백을 형성적인 면에서 잘 활용했다는 점에서 특히 주목할만 합니다.

그렇다면 정말 사용자의 말만 잘 들으면 성공할 수 있을까요? 역시 제이콥 닐슨의 같은 책에 정 반대되는 이야기가 있습니다.

Users Are Not Designers

...
For example, Grudin and Barnard [1985] compared command abbreviations they defined with abbreviations defined by individual users, and found that users made about twice as many errors when using their own abbreviations. Even when given the chance to redefine their abbreviations after the experiment, six of seven test users kept their poor abbreviation sets virtually intact, typically explaning that while yes, they had some problems with it, it seemed as good as any other set they could think of. Of course, users have other jobs and do not work as user interface professionals.

(강조는 김창준)

저는 애자일의 미래에서 어떻게 보면 이와 관련이 있는 사례를 소개했습니다.

제트 스키를 개발한 가와사키(Kawasaki)사는 제트 스키 경험을 개선하기 위해 무엇을 해야할지 사용자들에게 물었다. 사용자들은 측면에 여분의 패딩을 추가해서 제트 스키를 서서 탈 때 자세가 더 편안하기를 원했다. 회사는 고객들이 요청한 것을 제공하는 데 집중을 했다. 그 동안 다른 제조사들은 앉아서 타는 모델을 개발했고, 가와사키를 시장 최고 자리에서 끌어내리게 되었다. 고객들이 원한 것은 제트 스키 이용시 더 편한 기립 자세였지만 그들은 앉아서도 탈 수 있다는 생각은 해내질 못했다. ‘앉아서 타는’ 모터싸이클 제조 업체였던 가와사키까지도.

이 외에도 VIP 고객의 이야기를 잘 들어서 오히려 반어적으로 실패하는 사례는 클레이튼 크리스텐슨(Clayton M. Christensen)이 그의 여러 저작을 통해 잘 소개해주고 있습니다.

사용자는 설계자가 아니고, 또 설계자는 사용자가 아닙니다. 사용자는 왕입니다. 하지만 사용자가 결정하는 것이 모두 정당화될 수는 없습니다. 사용자와 설계자는 서로 대화와 협력을 해야 합니다. 두 명의 왕이 협력해서 한 나라를 통치한다고 생각해보면 어떨까요?

--김창준