프로토타입과 페이퍼 목업을 만드는 이유

제가 다니는 회사 블로그에 기록하는 개발일기입니다. 원문은 여기. 참고로 이 글은 별도 CCL을 적용합니다.

지난 글에 서 왜 우리가 폭포수 방식을 버리고, 다른 방식을 선택하기로 마음 먹었는지, 그 이유를 적었습니다. 그 때 폭포수 방식이 가진 중대한 결점을 하나 언급했죠. 바로 '프로토타입의 부재'입니다. 어떤 분들은 디자인 시안을 프로토타입이라 생각하기도 합니다. 제가 가진 지식이 많이 모자라서 디자인 시안도 프로토타입으로 봐야 하는지는 잘 모르겠습니다만, 우리가 추구하고 말하는 프로토타입은 '작동하는' 프로토타입니다. 이 단어가 핵심입니다. 작동하는.

웹은 인터랙티브(interactive)한 매체입니다. 사용자와 상호작용을 한다는 얘깁니다. 링크를 클릭하면 화면이 이동하고, 뭔가 버튼을 누르면 글이 등록되든, 이전 화면으로 돌아가든, 뭔가가 튀어나오든 아무튼 사용자의 움직임에 따라 반응을 합니다. 그것도 실시간으로 말이죠. (실시간. 이 단어가 또한 우리가 만드는 서비스의 중요한 키워드이기도 합니다) 저는 사용자의 움직임에 반응을 하지 않는 프로토타입은 아무런 가치가 없다고 봅니다. 잘 만들어진 디자인 시안은 시각적인 쾌감을 줍니다. 마치 실제로 뭔가 작동하는 서비스를 만든 것 같은 환각을 주기도 합니다. 하지만요, 그건 화면설계와 다를 게 하나도 없는, 종이쪼가리에 불과합니다. 물론 일종의 '청사진'으로 쓸 수는 있습니다만, 그 이하도 그 이상도 아닙니다. 디자이너가 근사하게 뽑아낸 디자인 시안을 종이에 프린트하거나 화면에 펼쳐놓은들 그걸로는 아무런 기능도 확인할 수 없으니까요.

그래서 저희는 일단 프로토타입을 만들기로 했습니다. 그렇다고 무작정 코드를 타이핑할 수는 없지요. 최소한의 방향은 필요합니다. 그래서 나온 결과물이 '단 한 장의 기획안'입니다. 이 기획안에는 서비스를 구성하는 각 기능을 간략히 기재했습니다. 이걸 두고 팀원들이 둘러앉아 포커를 쳤습니다. (어떤 포커를 쳤는지 궁금하신 분들은 이 글을 참조하세요) 며칠간 포커를 치면서 대략적인 할 일 목록(Task)를 뽑아냈습니다. 여기서 중요한 것은 할 일 목록을 뽑아낸 것이 아닙니다. 그 과정에서 각자 생각하는 '논리 실험'을 주고 받는 것이 중요합니다. 개발자A는 '이 기능을 이렇게 받아들였고, 그러므로 이렇게 구현하고, 그러니 이렇게 시간이 걸릴 것이다'고 말하고, 그 말을 들은 나머지 사람들이 각자 자신이 생각하는 걸 이야기합니다. 때론 일치하고 때론 전혀 다릅니다. 포커를 치는 동안 '천 명의 사람이 있으면 천 개의 생각이 있다'는 걸 배웁니다. 아울러 포커를 칠 때는 하루에 8시간 일한다고 생각하면 안됩니다. 물론 '예측'이니만큼 의미가 좀 덜할 수도 있습니다만, 아무튼 하루에 4~6시간을 일한다고 생각하고 일정을 산정하는 것이 좋습니다. 왜냐구요? 저도 하루에 8시간을 일해본 경험이 없습니다. 불가능해요.

포커를 치고난 뒤부터는 2주 단위로 이터레이션을 합니다. 이터레이션을 시작하는 날에는 각 개발자들이 포커의 결과물로 만들어진 일감을 선택해서 '이번 이터레이션에서는 이걸 하겠다'고 발표합니다. 이 사이에 중요한 일 하나가 더 있는데, 바로 '일감 쪼개기'이죠. 한 장짜리 기획안에 들어 있는 기능들은 큰 덩어리일 가능성이 높습니다. 이 덩어리를 잘게 쪼개지 않고 그대로 진행하면 기간만 조금 줄어들 뿐 별로 달라질 것이 없죠. 그래서 이 덩어리를 조금 잘게 쪼개서 일감을 등록해놓습니다. 잘게 쪼갤수록 좀 더 현실에 가까워지고, 구현할 방법을 찾아내기도 수월합니다. 그 결과 관리하기도 쉽죠.

이렇게 쪼개진 일감을 각자 선택하면서 또 다시 예상 시간에 대한 이야기가 나오기 마련입니다. 왜 그럴까요? 우리가 포커 게임의 결과로 일감을 만들고, 예상 시간을 산정하기는 했지만 그것 역시 논리 실험에 지나지 않습니다. 그 일감 중 몇 개를 골라서 실제로 구현을 하다보면 일을 시작할 때는 발견하지 못한 장애물이 등장하기 마련입니다. 누누히 얘기합니다만, 어떤 방법론을 사용하든 이렇게 실제로 구현을 해봐야만 발견되는 장애물을 예상하고 일정에 포함하지 않으면 백전백패합니다. (그래서 버퍼를 넣는다, 고 할테지만, 글쎄요. 그 '버퍼', 제대로 버퍼 노릇을 하던가요?)

이터레이션이 진행되는 동안 저(기획자)는 뭘 할까요? 더구나 전통적인 화면설계(스토리보드)는 만들지 않는다고 했으니 말이죠. 아울러 우린 흔히 하듯이 엑셀이나 프로젝트 관리 툴로 WBS를 만들지도 않습니다. 저는 이 때 목업(Mockup)을 만듭니다. 제가 목업을 만들기 위해 사용한 툴은 발사믹(Balsamiq Mockups)입니다. 굳이 이런 툴을 사용하지 않고, 그냥 펜으로 종이에 그려서 만들어도 됩니다. 저 역시도 펜으로 종이에 목업을 그리기도 했습니다.

제가 그린 페이퍼 목업.

목업을 만드는 이유는 개발자들의 이해를 돕기 위해서입니다. 전체 일감을 쪼개어 등록해두고 개발을 시작하지만, 실제로 일을 하다보면 시야가 좁아질 수 있습니다. 아울러 기능을 작은 단위로 잘게 쪼개어 개발을 하기 때문에 내가 지금 만들고 있는 기능이 다 합쳐졌을 때 어떤 모습으로 구현되느냐에 대한 이해를 명확히 할 필요가 있습니다. 목업을 만들어서 이를 좀 더 이해하기 쉽게 하고, 아울러 모든 이들이 같은 결과물을 예상하도록 하는 거지요.

굳이 손으로 그린 목업을 다시 컴퓨터를 이용해 만든 이유는 배포하기 쉽기 때문입니다. PDF파일로 만들어서 구글Docs 같은 곳에 올려두면 언제라도 찾아볼 수 있으니까요. (물론 손으로 그린 뒤에 스캔을 해서 이미지 파일로 만들어도 좋겠지요) 다른 목업 툴도 많은데, 발사믹을 선택한 이유가 바로 여기에 있습니다. 목업이 너무 정교하면 마치 화면설계처럼 거기에 갇힐 우려가 있습니다. 목업을 통해 생각을 발전시켜야 하는데, 목업이 생각의 종결점이 되면 안되잖아요. 그래서 적당한 툴을 찾다가 발사믹을 선택했죠. 발사믹의 장점은 마치 손으로 그려놓은 것 같은 구불구불한 선입니다. 안타깝게도 한글은 서체 지원이 잘 안되서 딱딱한 고딕 계열의 서체를 써야합니다만. (아 그러고보니 이걸 개선해달라고 요청한다는 걸 깜빡 잊었네요.) 너무 정교하지 않으면서도 간편하게 제가 생각하는 모습을 스케치해서 팀원들과 공유할 수 있지요. (실제로 써보시면 아실텐데, 발사믹 목업은 기존 폭포수 개발방식에는 사용할 수 없을 겁니다.)

목업은 주요 화면 몇 개와 중요한 기능에 대해서만 만들었습니다. 이 과정에서 사실 '차라리 이걸 화면설계로 해버릴까' 하는 마음과 '이렇게 자꾸 하다보면 이게 화면설계가 되겠는데?' 하는 마음이 교차했습니다. 그래서 대표적인 화면 목업이 나온 뒷부터는 더 이상 목업을 만들지 않습니다. 그러나 앞으로도 페이퍼 목업은 계속 만들 듯 합니다. 특히 새로 합류하게 되는 디자이너와 의견 교환을 위해서 말이죠.

이터레이션 선정 회의 혹은 개발 과정에서 나타난 이슈를 해결하기 위한 회의를 진행해보면 재밌는 현상을 목격할 수 있습니다. 제가 10년 넘도록 이 일을 하면서 정말 희귀하게 목격한 현상입니다. 개발자가 새로운 아이디어를 제공하기 시작해요. 때론 그것이 오류를 해결하기 위한 차원일 때도 있으나, 많은 경우 좀 더 나은 사용자 경험을 제공하기 위해서입니다. '이렇게 하면 더 좋은 서비스를 제공할 수 있다'는 생각으로 아이디어를 제시하는데, 어떤 때는 그 아이디어로 개발자의 일이 훨씬 더 어려워지기도 합니다. 그럼에도 개발자들은 꾸준히 좋은 아이디어를 제시합니다. 이것이 바로 일정에 사람을 짜맞추는 개발 방식으로는 절대 얻을 수 없는 소득입니다. 만약 내가 낸 아이디어가 내 짐으로 돌아오면 아무도 새로운 아이디어를 내지 않을 겁니다. 개발자는 아이디어와 그 아이디어를 실현할 수 있는 능력을 동시에 가진, 흔치 않은 집단입니다. 이 집단의 창의력을 살려줘야 서비스가 발전합니다.

2주간의 이터레이션이 종료하면 모두 모여 앉아 이번 이터레이션에 만든 프로토타입을 사용해봅니다. 비록 아직은 많이 엉성하지만, 실제로 작동합니다. 링크를 클릭하면 이동하고, 로그인도 되고 회원가입도 됩니다. 몇 차례의 이터레이션이 지난 지금은 작동하는 기능이 제법 많습니다. 이렇게 하면 어떤 장점이 있을까요? 무엇보다 오류가 발생할 경우 그걸 발견하기가 쉽습니다. 우리는 프로젝트 막판에 가서 한 번 크게 실패하는 방식을 택하지 않고, 몇 주 단위로 지속적으로 작게 실패하는 방식을 택했기 때문입니다. 뭔가 잘못되었거나 작동하지 않으면 바로 알 수 있습니다.