brunch

매거진 왜 우리 소프트웨어는 안나와요

라이킷 68 댓글 7

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Jinho Yoo Sep 18. 2016

무슨 소프트웨어나 서비스를 만들고 싶으세요?

말하지 않거나 적지 못하면 몰라요.

자신이 만들고자 하는 소프트웨어나 서비스를 설명하실 수 있나요?

이 글은 소프트웨어를 만들려고 하는 경영자, 정치인, 비영리 재단 등 소프트웨어 비 전문가들을 위해 쓰는 글입니다

여러 형태의 소프트웨어가 있습니다. 그렇지만 여기에서는 보통 생각하는 ‘웹서비스'나 ‘앱'에 대한 이야기를 주로 하겠습니다.

가끔씩 “내가 대단한 소프트웨어/서비스 아이디어가 있어"라고 말하면서 먼저 말로 막 하시는 분들이 있습니다. 처음에야 들어줍니다. 그래서 세부적으로 구현하려면 어떻게 해야 하는지 적어 달라고 하면 전에 말로 한 내용만 ‘그대로’ 적어서 오는 경우가 있습니다.

잘 와 닿지 않죠? 건축가에게 “나 3층 집 지어줘"라고 고객이 요청했다고 합시다. 그래서 건축가가 더 자세하게 알기 위해 메일로 적어서 보내달라고 했는데 메일이 이렇게 온 겁니다. “나 3층 집 지어줘. 이쁜 걸로.” 여러분이 건축가라면 어떻게 지을까요? 건축가 마음대로 지으면 끝날까요? 아니죠, 결국 고객이 만족하지 못하는 집을 지으면 결국 돈을 못 받을 테니 건축가 마음대로 지어 버리면 안 되겠지요.

지금 이 글을 읽으시는 분들이 이 사실을 꼭 알아야 합니다. 어느 경우에도 설계도를 그리지 않고 뭘 만드는 경우는 기록된 인류 역사 1만 년 이래 없었습니다. 아무리 단편 소설을 쓰더라도 최소한 플롯은 적어두고 시작합니다. 그런데 너무나 많은 사람들이 이 일을 무시하고 개발자한테 옵니다.

준비 안된 고객이 얼마나 문제를 일으키는지 아시나요? 예전에 지인 한분이 애자일의 할아버지(?) 제럴드 와인버그(1950년대에 IBM의 컨설턴트로 시작해서 컴퓨터 산업 역사의 산 증인으로, 컨설턴트들의 컨설턴트로 유명하다. 대표적인 저서로 컨설팅의 비밀, 프로그래밍 심리학, 테크니컬 리더 등이 있다.) 아저씨와 Facebook에서 한국의 소프트웨어 개발 문화(특히 SI)가 얼마나 골 때리는지 이야기를 해 드리니 이런 말씀을 들려주셨습니다.

"어느 국가, 어느 문화를 막론하고 개발자나 테스터에게 가장 귀한 자산은 현명한 고객이다. 그 다음은 무식하고, 그 무식을 숨기려 하지 않는 고객이다. 가장 나쁜 자산은 어리석고 무식하면서도 모든 걸 아는 체 하는 고객이다. 그런 사람은 무슨 수를 써서 라도 피해라. 규칙은 그에게서 당신을 보호하지 못한다."

이 이야기를 여러분은 어떻게 생각하시나요? 소프트웨어를 만드는데 제일 큰 위험 요소는 바로 고객이라는 겁니다. 바로 이 글을 읽으시는 ‘당신’이란 뜻입니다. ‘뭐, 내가 무식해!’라고 화가 나신다면 더 안 보셔도 됩니다. 하지만 몸에 좋은 약은 초반에 쓰니까 계속 쓰겠습니다.

실제 사례: 빽빽하게 구상을 적어온 고 노무현 대통령님

고 노무현 대통령님의 '뉴리더'개발 과정에 대한 신현묵님의 구술 장면 캡쳐(출저:http://archives.knowhow.or.kr/record/all/view/149188)

한겨레 21 에 2010년 5월에 고 노무현 대통령님이 정치인을 위한 소프트웨어를 만들기 위해 유명한 개발자인 신현묵 님을 만났던 이야기가 나옵니다. 기사를 보면 이렇게 되어 있습니다.

그는 소프트웨어를 만들고 싶다고 했다. ‘뉴리더 새 버전 구상’이라는 문서를 가방에서 꺼냈다. 자신이 원하는 소프트웨어에 대한 구상이 빼곡히 쓰여 있었다. 애초에는 대학생들에게 부탁해 제작해보았는데 결과가 만족스럽지 않았고 큰 기업은 의뢰를 거절했다고 했다. 신씨는 노무현 변호사가 건넨 문서를 보자마자 도전 욕구를 느꼈다. ‘뉴리더’는 일정, 개인·단체 정보, 문서 관리는 물론 정보와 메시지 공유 등 사용자 간의 소통을 가능하게 하는 일종의 인맥 관리용 프로그램이었다. 신씨는 “이제 와서 생각해보면 그의 구상은 ‘웹 2.0’이었다”라고 말했다.

어떤 소프트웨어가 필요한지 빼곡히 적혀있던 문서가 양식을 맞춰서 잘 적은 것은 아닐 것입니다. 하지만 보시는 것처럼 ‘이해할 수 있게 적혀있는 덕에’ 평가를 받을 수 있었습니다.

그렇게 3개월 만에 ‘뉴리더’가 완성됐다. 1997년 초였다. ‘뉴리더’가 성공하자 더 진보한 소프트웨어를 내놓기가 손쉬워졌다. ‘뉴리더’는 ‘우리들 98’ ‘노하우 2000’으로 계속해서 진화했다. 2002년 새천년민주당의 대통령 후보가 된 노무현은 선거 관리도 이런 소프트웨어를 기반으로 했다. ‘노하우 2000’은 노무현재단의 ‘사람 사는 세상’ 홈페이지(www.knowhow.or.kr)로 발전했다. ‘뉴리더’ ‘우리들’ ‘노하우’의 기술력은 결국 참여정부의 전자정부 구상에서 핵심 시스템인 ‘이지원’으로 집약됐다.

보시는 것처럼 3개월 만에 만들어진 간단한 소프트웨어 초기 버전이 나오자 진보된 소프트웨어를 만드는 것이 쉬워졌다고 합니다. 이게 소프트웨어가 가진 특징이자 모든 지적 생산물들의 특징입니다. 이런 점을 마음속에 두고 생각해보시면 지금 여러분이 만들고자 하는 소프트웨어가 출시가 가능한지 아닌지 답이 나올 것입니다.

실제 사례 2: 프로토타입 외주 개발 왜 실패할까?

이번 고객은 무조건 여의도에 피라미드 만들어 달라네...

한국의 스타트업 미디어인 벤쳐스퀘어의 2015년 4월 16일자 기사, ‘프로토타입 외주 개발 왜 실패할까’라는 기사에 보면 많은 스타트업의 서비스 기획서들의 문제점을 지적하는 내용이 나옵니다.

스타트업이 스스로 생각한 아이디어를 빠르게 구현한다는 의사결정의 초스피드 장점을 가지고 있다고는 하지만 서비스 개발을 위한 기획서를 보면 코딩을 할 수 없는 단계에 머물러 있는 경우가 많습니다.

1. 사업계획서 또는 아이디어 설명만 있는 경우
2. 한두 페이지의 주요 화면만 있는 경우
3. 유사 서비스의 화면 스크랩만 있는 경우
4. 화면에 대한 설명이 없는 경우
5. 명확한 방향 제시가 없는 경우
6. 아주 많은 것을 한 화면에 넣어놓은 경우
7. 이번에 만들고자 하는 범위가 정해져 있지 않은 경우
8. 서비스 전체의 화면 흐름이 없는 경우
9. 화면 구성을 확정하지 않은 경우.

어떤 문서를 어느 정도 자세하게 작성해서 줘야 개발을 할 수 있을지 아시겠죠? 기사 중에 굉장히 인상이 깊었던 문장은 이것이었습니다.

“어떤 것을 하고 싶은지 말만 하면 다 알아서 해주면 얼마나 좋을까요. 그런데 같은 것을 보면서도 다르게 생각하는 마당에 구체적이지 않다면 마치 사람 많은 곳에 빨리 가고 싶다고 말하는 사람을 택시기사가 대체 어디로 데려가야 한단 말인가요.”

나는 상대방에게 내가 원하는 것을 ‘글'로 설명할 수 있는가?

위의 두 가지 경우를 보고 어떤 생각이 드시나요? 내가 무엇을 원하는지 상대방에게 설명할 수 없을 때 문제가 시작됩니다. 동시에 설명해서 이해만 시킬 수 있으면 성공이 가능하다는 뜻입니다.

안타깝게도 대부분의 한국 성인들은 이렇게 ‘글'로 무언가 의사소통을 하는 법을 배우지 못했습니다. 특히 기업의 임원이나 관리자 급들의 문자 소통 능력은 심각할 수준입니다. .

가끔 정부기관이나 대기업에서 발표자료를 만들어서 가져오면 늘 한숨입니다. 앞에 정작 중요한 내용보다는 온갖 장광설을 적어놓고 중요한 결정사항은 맨 뒤에 있는 경우가 대부분입니다. 이런 문서들을 보고 있으면 너무나 너무나 먼길을 가야 하는 지라 기운이 빠져버립니다. 문장은 또 어떤가요? 이른바 개조식(個條式) 문장으로 ‘~~함', ‘~~~임'으로 끊어지는 문장을 나열합니다. 그런데 이것은 또 정확히 한국어 문장이 아닙니다. 일본어의 箇条書き(かじょうがき) 방식을 조금 바꾼 것입니다. 이런 문서를 계속 읽고 있으면 마치 비포장 도로를 달리는 것처럼 지쳐버립니다.

마치 이런 느낌입니다, "난 아무렇게나 싸질러 놓을테니 너희가 알아서 준비해와"라는. 실제 여러분은 어떠세요?

여러분이 만들고 싶어 하는 서비스나 소프트웨어에 대해 어떻게 적어봐야 할까요? 제가 찾아본 방법 중 가장 쉽고 명쾌하고 여러분이 해보기에 참 좋은 방식을 소개해드리고자 합니다.

Working backwards: 고객에서부터 시작하는 제품 개발법

Amazon의 CTO인 Werner Vogels는 ‘Working backwards’라는 방법을 소개하고 있습니다. 사실 복잡하고 어렵게 제품에 대해 문서로 적는 온갖 방법은 많습니다. 하지만 이것들보다 조금 더 간결하고 명확하게 제품을 설명하는 방법으로는 괜찮다고 생각해서 소개합니다. 그 시작은 바로 이것입니다.

“지금 만들 제품의 보도자료를 만들어 본다.”

한번 상상해 보세요. 지금 만들려는 서비스나 소프트웨어가 언론에 소개된다고 하면 어떻게 만드실 건가요? 아마도 명확하고 정확하게 전달되게 하기 위해 온갖 노력을 벌이고 생각을 정리할 것입니다. 네, 바로 그 과정을 제품을 만들기 전에 해보면서 온갖 생각을 정리해보는 것입니다.

1. 보도자료를 작성한다.

보도 자료라니...

당신이 제일 책상에 앉아서 보도자료를 만들어서 서비스나 소프트웨어를 홍보하려고 한다면 어떻게 할까요? 이 제품을 쓸 사람들은 누구고, 왜 이런 물건을 만들었고, 기능은 뭐고, 이점이 뭔지 등등을 적겠지요? 이 작업을 맘에 들 때까지 계속해서 반복해야 합니다. 적어보아야 하는 것들을 정리해보면 아래와 같습니다.

제목 : 독자(대상 고객)가 이해할 방법으로의 제품 이름을 지어주세요.

부제 : 상품에 대한 수요자가 누구이고, 그들이 얻을 혜택을 설명해야 합니다.. 타이틀 아래에 오직 한 문장으로만 하세요.

요약 : 제품과 그 혜택을 요약해주세요. 독자가 이 아래로 안 읽을게 뻔하니 정말 잘 적으셔야 돼요.

문제점 : 무엇을 해결하려고 이 제품을 만들었나요?

해결법 : 위의 문제를 어떻게 멋지게 풀어냈어요? .

인용 : 회사 대변인으로부터의 인용문을 넣는다. 보통 “~~ 사내 관계자에 의하면~~~~라고 한다"라고 하는 거 있잖아요.

시작하기 : 처음에 어떻게 쓰는 지를 설명합니다. ‘시작하기 쉬워요!’라는 것을 잘 말해야 됩니다.

고객 인용 : 가상 고객이 어떤 혜택을 경험했는지 표현하는 인용 합니다. “제가 ~~ 을 써보니 정말 좋더라고요~~~~.” 같은 문장 들어가는 겁니다.

맺음말과 해야 할 것 : 앞의 내용들 요약정리하고 그다음에 뭘 해야 할지 알려줍니다. 네이버에 검색을 하든지, 홈쇼핑 채널을 보라든지, 전화번호를 주고 전화를 해달라든지 이야기해줍니다.

반드시 A4 한 장으로 작성하시고, 문단은 3~4 문장으로 제한하세요. 늘어나면 과감히 지우시고요. 최대한 고객이 뭘 얻는지에 집중하시고 다른 비즈니스 실행하는 내용은 FAQ에 붙일 겁니다. 그리고 이걸 쓰는데 혼자 쓰지 마시고 관련된 분들 (개발 리더 포함)이 여러 번 같이 쓰시라고 권합니다.

2. FAQ를 작성하라

앞의 보도자료를 적고 나면 자연스럽게 질문과 답변 거리들이 생기게 됩니다. 이걸 생각하면서 고객의 입장에 서게 되는 것이지요. 이것 역시 여럿이 자꾸 쓰다 보면 자연스럽게 작성하게 됩니다.

질문거리가 없다고는 말 못할겁니다.

3. 사용자 경험을 정의하라

이 제품을 가지고 고객이 할 뭔가 다른 점에 대한 고객의 경험이 정확히 어쩔지 적어야 합니다. UI를 가진 제품으로서 고객이 사용할 화면들을 스케치해봐야 합니다. 웹 서비스들이라면 상상할 수 있는 방법으로 코드 조각을 포함해서 사용 예들 (Use case)들을 적습니다. 이 목적은 어떻게 고객이 그들의 문제를 우리 서비스나 제품을 가지고 해결하는지 이야기를 나눠보는 것입니다. 그리고 각 기능 별로 모든 화면을 만든 스토리 보드를 꼭 만들어봐야 합니다.

사용자 워크플로우의 예: (출처 http://yslab.kr/74)

4. 사용자 매뉴얼을 만들어라

사용자 매뉴얼이란 사용자가 진심으로 이게 뭔지 그리고 어떻게 쓰는 것인지 찾기 위해 이용하는 것입니다. 사용자 매뉴얼은 보통 세 가지 장이 있습니다. ‘개념', ‘어떻게 쓰나', ‘관련 자료들을 다 정리하고 있는 참고자료들'. 고객이 다양해진다면 이들을 위한 사용자 매뉴얼도 달라지게 됩니다.

아이폰도 사용자 설명서가 iBooks에 있다는 사실.

악보와 음반의 관계

저걸 다 만들어 보고 기획을 해봐서 뭔가 산출물이 나왔다면 다일까요? 아뇨, 이제 개발자와 만나서 또 이야기를 해야 하고 (앞의 작업을 개발자와 같이 하셨다면 아주 잘 하신 거예요.) 또 일정을 쪼개고 일을 해야 합니다.

다만 지금 한 것은 ‘왜, 무엇을, 어떻게'까지만 고민한 것입니다. 이게 다가 아닙니다. 실제 진짜 개발을 하기 위해서는 더 많은 절차와 분석을 해야 되고 또 처음 여러분이 생각했던 것과는 많이 다른 제품이 될 것입니다.

“아니 그럼 언제 제품이 나와요?”라고 묻는 사람들이 있을 수 있습니다. 지금 당신이 만든 저 문서들이 첫 번째 제품입니다. 많은 사람들이 소프트웨어가 나와야 한다고 할 때 소프트웨어 코드만 생각하는 경우가 많은데 그렇지 않습니다.

이런 질문을 드리고 싶습니다. ‘악보는 음악 작품일까요? 아닐까요?’ 우리 대부분은 음악을 음반으로 들을 경우 음악이란 것의 최후 생산물은 ‘소리가 녹음된 음반'일 것입니다. 그러나 그것을 만들기 위한 기본이 ‘악보'입니다. 지금 여러분은 ‘악보'를 하나 쓰신 겁니다. 그리고 이 악보는 음반을 만드는 기본 작업입니다.

아주 간단한 음악은 뭐 멜로디만 대충 적어 놓고 기타 하나 들고 치면 됩니다. 문제는 당신이 오케스트라를 원하면서 기본적인 악보조차 적지 않고 화성부로 나눠서 편곡하지도 않으면? 아마 오케스트라 단원들이 “저거 뭐하는 놈이여?”하지 않을까요?

게다가 인류의 역사상 제일 복잡한 지적 생산물이 소프트웨어입니다. 이것을 무시하고 ‘빨리빨리'만 외친다면 당장 그만두시고 다시는 소프트웨어나 서비스를 만들겠다 생각하지 마십시오. 그게 우주 평화(?)를 위해 도움이 됩니다. 저는 늘 이야기합니다. ‘소프트웨어 만들지 마세요. 이거 안 만들어도 돈 되는 일 많아요.’. 제대로 된 마음가짐이 없다면 좋은 산출물을 기대도 하지 마세요.

정말 이걸 다 써야 되요? 힘들어요.

네, 알뜰하게 말씀드리면 다 쓰시고 설명하실 수 있어야 합니다. 글로 이야기 한다는 것이 얼마나 어려운 일인지 압니다. 그러나 그러한 과정속에 여러분이 하고자 하는 일이 더 정리되고 정리되고 또 정리될 것입니다. 필요한 정보를 모으고 이를 정리해서 필요한 정보로 정리하는 과정만큼 지식이 정리되고 합리적인 일인지 아닌지 검증할 수 있는 방법도 없습니다. 타인을 납득시킬 수 없는 소프트웨어나 서비스를 만들어 달라고 하면 누가 만들겠습니까.

문서만 한번 다 쓰면 되죠, 이까이꺼!

어, 잠깐. 지금 위의 문서들이 필요한 목적은 문서만 만들려고 하는게 아니에요. 문서를 쓰는 과정중에 나 자신과 의사소통을 하고 또 개발자나 디자이너들에게도 피드백을 얻고자 하는 거에요. 즉 많이 보여주고 수정하고 또 그 과정에서 의사소통을 지속적으로 하기 위해서 하는 거에요. 혼자 싸앉고 죽거나 밑에 말단 직원한테 던져주고 '써와'하는게 아니란 말입니다. 그럴 생각 하셨으면 다시 이 글을 처음부터 읽어보세요.