1. Getting Real Overview
Buy the book
Buy Getting Real in PDF or paperback.
Job Board
Click Here, Inc. is looking for a Senior Web Developer (Geek!). See more on the
Job Board.
Gig Board
Looking for design, copywriting, or programming help with your project? Check the
Gig Board.
Getting Real
• chapter 1 소개
• chapter 2 출발점
• chapter 3 가볍게 유지하기
• chapter 4 우선순위
• chapter 5 기능 고르기
• chapter 6 프로세스
• chapter 7 조직의 구성
• chapter 8 인재 발굴
• chapter 9 인터페이스 디자인
• chapter 10 코드
• chapter 11 문서와 글
• chapter 12 가입 및 서비스 요금
• chapter 13 홍보
• chapter 14 지원
• chapter 15 서비스 개시 이 후
• chapter 16 맺음말
1

2. 소개 chapter 1
Getting Real 이란?
성공적인 웹어플리케이션을 만들고 싶으세요? 그럼 이 "Getting Real"을 적용하세요.
Getting Real 은 보다 작고, 빠르고, 좋은 소프트웨어 구축을 위한 방법입니다.
• Getting Real 은 실제를 대신하는 도구들(차트나 그래프, 박스, 화살표, 도식, 와
이어 프레임. 등) 대신, 실제의 업무를 구축합니다.
• Getting Real 은 날씬합니다. 복잡하지 않고, 소프트웨어를 줄이며, 특징 기능은
보다 줄이고, 사무 작업도 줄이고 기본적이지 않은 모든 것들을 줄여줍니다. (당
신이 필수불가결하다라고 생각하는 것의 대부분은 실제로 그렇지 않습니다).
• Getting Real 은 작게 지속되며, 신속 기민하게 유지됩니다.
• Getting Real 은 즉 사람들이 사용할 때 보는 실제의 화면인 인터페이스로부터
시작합니다. 사람들의 체험에서 시작하여 차츰 시스템을 구축해 나갑니다. 그러
면 소프트웨어는 잘못된 방향으로 가지 않게 하고, 올바른 인터페이스를 얻을
수 있습니다.
• Getting Real 은 반복해 가는 것이며, 변경 비용을 낮추는 방식이기도 합니다.
Getting Real 은 서비스 개시 후에 지속적으로 개선을 거듭해 가는 모든 방법으
로 웹 기반의 소프트웨어에 대해 가장 완벽한 접근 방법입니다.
• Getting Real 은 고객에게 정말로 필요한 것들만을 제공하고, 나머지는 없앱니
다.
Getting Real 의 이점들
Getting Real 은 문제에 봉착했을 때, 아이디어 차원에서 문제를 해결하기보다는 실제
구현의 차원에서 문제를 해결하기 때문에 좋을 결과를 도출해 줍니다. 이것은 현실을
파악하고 처리할 수 있도록 해 줍니다.
Getting Real 은 실제의 화면 구현적인 측면에서 함수 정의서나 다른 임시적인 자료보
다 앞서갑니다. 기능 정의는 합의한 환상이지만 실제 웹 페이지는 현실이기 때문입니
다. 그리고, 그 현실적인 부분이 유저가 실제로 보고 사용하는 것입니다. Getting Real
덕에 중요한 부분을 보다 빠르게 찾아낼 수 있습니다. 바꾸어 말하면, 당신은 추상적인
개념이 아닌 구체적인 것으로부터의 판단을 통해 소프트웨어를 만들어낼 수 있습니다.
2

3. 마지막으로, Getting Real 은, 웹 기반의 소프트웨어에 이상적인 구현 방법입니다. 소
프트웨어를 상자에 채우고, 업데이트를 보낼 때까지 1 년 내지 2 년을 기다리는 방법은
이제 과거의 것입니다. 인스톨 기반의 소프트웨어와 달리, 웹 어플리케이션은 하루하
루 기준으로 진화 개량 할 수 있습니다. Getting Real 은 이런 모든 가치에 대한 혜택에
영향을 줍니다.
< 칼럼> 훌륭한 소프트웨어를 만들려면 …
훌륭한 문장은 간결하다. 문장에 불필요한 말이 들어가지 않고, 단락에도 불필요한 문
장이 없다. 같은 이유로, 도면도 쓸데 없는 선이 있으면 안되고, 기계에도 쓸데 없는 부
품이 있어선 안 된다. 이를 통해 제작자는 문장을 짧게 만들거나 혹은 상세 설명을 피
하면서 윤곽만을 언급함으로도 모든 것을 전할 수 있다.
—From "The Elements of Style" William Strunk Jr. (윌리암 스트렁크)
비대화는 그만
낡은 방식：장황하고, 관료적이고, 우기가 이걸 함으로 해결될 수 있는 프로세스. 흔히
있는 결과：비대화 됨, 평범한 물방울처럼 쉽게 잊혀지는 소프트웨어
Getting Real 에 의해 줄일 수 있는 것들...
• 몇 개월 혹은 몇 년이나 걸리는 긴 스케줄
• 믿을 수 없는 기능적 스펙
• 확대되는 논쟁
• 끝없는 스탭 미팅
• 필요에 의한 많은 고용 인원 수
• 무의미한 버젼 넘버들
• 완벽한 장면을 그린 초기의 로드맵
• 끝없는 환경 설정 옵션
• 아웃소싱 기반의 고객 지원
• 비현실적인 유저 테스트
• 쓸데 없는 사무 작업
• Top-down 방식 구조
3

4. 훌륭한 소프트웨어를 개발하기 위해서, 큰 돈이나 거대한 팀, 또는 긴 개발 사이클은
필요 없습니다. 그런 것들은 대체로 스피드가 늦고, 애매하고, 수정할 수 없는 어플리
케이션이 태어나는 것입니다. Getting Real 은 반대의 접근 방식을 취합니다.
이 책을 통해 우리는 당신에게 아래와 같은 것들을
보여줄 것입니다.
• 자신의 철학을 가지는 중요성
• 왜 작은 규모가 좋은 것인가
• 어떻게 날씬한 구축을 행할까
• 어떻게 아이디어를 현실에 재빠르게 실현시킬까
• 어떻게 프로젝트 팀을 편성할까
• 왜 철저히 디자인을 하지 않으면 안 되는가
• 왜 쓰는 것이 매우 중요한가
• 왜 경쟁을 회피해야 하는 것인가
• 어떻게 어플리케이션을 프로모션 해서 세계로 확대 시킬 것인가
• 성공적인 고객지원의 비밀
• 시작 후, 그 기세를 유지하는 방법
• ...그외 다수
이 책은 전체적인 생각에 초점을 맞추고 있습니다. 당신이 섬세한 코드나 CSS 의 트릭
으로 수렁에 빠지지 않게, Getting Real 프로세스의 주요 아이디어나 철학을 중심으로
소개하겠습니다.
이 책이 당신한테 적합한 책일까요?
당신은 큰 아이디어에 흥미를 가지고 임하고 있는 기업가, 디자이너, 프로그래머, 기획
/마케터 입니다.
당신은 종래의 규칙이 더 이상 적용할 수 없다는 한계를 느낍니다. 해마다 시디롬으로
소프트웨어를 배포하고 있습니까? 2002 년도에 출시된 버전의 수가 몇 개나 되나요?
당신은 개발하고, 출시하고, 수정하고. 다시 이것을 정리하고 반복하는 것 입니다.
혹은 애자일(agile) 개발 방법론이나 비즈니스 구조를 확립하지 않았지만, 진지하게 공
부하고 싶어하는 사람일 수도 있습니다.
당신이 이러한 사람이라 생각된다면, 이 책은 당신을 위한 책입니다.
4

5. Note: 이 책은 주로 웹?어플리케이션 구축을 목적으로 한 내용입니다만, 이 책이 많은
아이디어는, 소프트웨어 개발 이외에도 적용할 수 있습니다. 작은 팀?조직의 개념이
나, 신속한 프로토타이핑, 반복의 예측…이라고 한 많은 아이디어가, 기업?집필?웹디
자인?음악 활동이라고 하는 수많은 창조적인 활동에 도움이 되는 것입니다.. Getting
Real 은, 결코 IT 분야의 일부에게만 적응되는 것이 아니고, 한번 이해하면, 인생의 여
러 분야에서 그 개념을 응용할 수 있습니다. .
37signals 소개
하는 일
37signals 는 단순하고 간결한 소프트웨어를 개발하는 작은 조직입니다. 우리는 그룹
의 협업이나 조직 관리에 도움을 주는 제품을 제공하고 있습니다. 350,000 명이 넘는
개인과 중소기업에서 우리가 만든 웹 어플리케이션을 활용하고 있습니다. "월스트리
트 저널"의 Jeremy Wagstaff 씨는, "37signals 의 제품은, 아름답고 우아하고 직감적으
로 사용할 수 있는 심플한 툴로 화면 구성은 마치 고문실과 같은 소프트웨어로 보인
다."라는 평가도 받고 있습니다.우리의 제품은 당신을 고문을 가하는 것은 없을 것입니
다.
일 처리 방식
요즘 소프트웨어는 너무 복잡합니다. 필요 이상으로 많은 기능에 버튼까지, 게다가 쓰
기 위해 익혀야 할 것도 많습니다. 우리 제품에는 일부러 경쟁사 보다 적은 기능을 담
았습니다. 보다 똑똑하게, 보다 기분 좋게, 자신의 스타일로 일을 처리할 수 있고, 보다
쓰기 쉬운 제품을 만듭니다.
우리의 제품
이 책의 출판 시점에 다섯 개의 제품을 판매하고 한 개의 오픈 소스 웹 어플리케이션
프레임워크를 개발하고 있습니다.
Basecamp 프로젝트 관리를 목표한 바로 이끌고 가는 어플리케이션입니다. Gantt
chart 나, 화려한 그래프, 무거운 현황 기반의 스프레드?시트 대신에, Basecamp 는 메
시지, To-do 리스트, 심플한 일정표, 협업 문서 작성 및 파일 공유기능을 제공합니다.
5

6. 수십 만 사용자는 이 제품을 높게 평가하고 있습니다. Salon.com 의 Farhad Manjoo 씨
로부터 "Basecamp 는 웹 소프트웨어의 미래를 대표합니다."라는 말도 받고 있습니다.
Campfire 심플한 비즈니스용 그룹 채팅 툴입니다. 리얼타임의 커뮤니케이션 툴로서
그룹 채팅의 중요성이 인정되어 도입하고 있는 기업도 증가하고 있습니다. 종래의 메
시저는 1 대 1 의 즉석 대화를 하기엔 훌륭하지만 한 번에 세 사람 이상이 대화를 나누
기에는 끔찍합니다. Campfire 는 이런 문제 뿐만 다른 수 많은 문제를 해결했습니다.
Backpack 개인용 태스크 관리 어플리케이션입니다. Backpack 은 "간단한 25 단계로
인생을 정리하세요"라고 말하는 혼란스럽고 복잡한 소프트웨어의 대안입니다.
Backpack 의 심플한 페이지, 노트, To-do 리스트, 휴대폰/ 메일 기반의 알림 기능은, 지
금까지의 아날로그 태스크 관리로 고생을 해결해 줄 수 있는 새로운 아이디어 상품입
니다. 월스트리트저널의 Thomas Weber(토마스 웨버)씨는, 태스크 관리 소프트에서는
제일가는 것, 뉴욕타임즈의 David Pogue(데이비드 포그) 씨는, "매우 쿨한" 조직 관리
툴 이라고 언급했습니다.
Writeboard Writerboard 를 이용하여 혼자 혹은 다른 사람과 함께 글을 쓰고 공유하고
고치고 비교할 수 있습니다. 지금까지의 번접한 워드프로세서를 대신하는 새로운 문서
작성 도구입니다. Daring Fireball 사의 John Gruber 씨는 "Writeboard 는, 지금까지 본
가운데 제일 알기 쉽고, 심플한 웹어플리케이션이다", 또 웹의 전도사로서 알려진
Jeffrey Zeldman 씨는, "37signals 는 또 했다!" 라는 찬사를 받았습니다.
Ta-da List To-Do 리스트 정리?온라인 관리 어플리케이션입니다. 리스트는 개인용, 또
는 공용으로서 다른 사람과 쉽게 협업할 수 있습니다. 태스크 관리에 이보다 더 간단한
방법은 없습니다. Ta-da List 사용자는 벌써 십만 개 이상의 할 일 목록을 등록했습니
다. 세부 항목은 백만 개를 넘습니다.
Ruby on Rails 는 개발자를 위한 풀 스택의 오픈 소스의 웹 프레임워크로서 실제의 어
플리케이션을 빠르고 쉽게 개발할 수 있도록 해줍니다. 레일즈는 여러분이 아이디어에
전념할 수 있도록 바쁜 일을 처리합니다. "Ruby on Rails 는, 놀랄 만한 것입니다. 비유
한다면 쿵푸 영화 감상입니다. 여러 개의 바쁜 프레임워크 체제가 작은 신참자를 때려
주려 했으나, 반대로 신참자의 창조적인 다양한 방법으로 얻어 맞는 것과 같은 것입니
다."라고, O’Reilly 출판의 Nathan Torkington 씨가 코멘트하고 있습니다.
보다 많은 제품과 회사 안내의 자료는 www.37signals.com 에서 확인 하세요..
6

7. Caveats, disclaimers, and other
preemptive strikes
본문에 들어가기 전에 앞서 Getting Real 에 대해 자주 듣는 불만 사항에 대해 먼저 짚
고 넘어가고자 합니다.:
"이 테크닉은 우리에게 적합하지 않습니다."
Getting Real 은 37signals 의 조직에 꼭 맞는 시스템입니다. 다시 말하면 결코 이세상
의 모든 프로젝트에 적용할 수 있는 것이 아닙니다. 만약 당신이 무기 시스템 및 핵 제
조 공장, 몇 백만 명의 고객 전용의 은행 시스템이나, 생활이나 금융권의 중요한 시스
템을 구축하는 경우는, 우리의 방임주의적인 자세에 주저하겠지요. 그러나 과감히 해
봅시다. 그리고 필요한 대책을 강구하면 좋습니다.
또 Getting Real 은 모두 적용 해야 하는 것이 아닙니다..비록 당신이 Getting Real 의 전
체를 받아 들여지지 않는다고 해도, 그 몇 개의 아이디어를 손에 넣을 순 있을 것입니
다.
"37Singals 이 Getting Real 의 아이디어를 개발하
지 않았잖아요."
우리는, 결코 이러한 기술을 발명했다고는 말하지 않습니다. 우리의 컨셉의 상당수는
오랫동안 주위에서 거론되었습니다. 우리가 말하고 있는 내용이 옛날 어딘가의 블로그
에서 읽었거나 20 년 전의 책에서 읽은 것 같은 것이라고 생각해도 화내지 말아 주세
요. 분명히 있을 수 있는 일입니다. 이러한 테크닉들은 모두 37signals 의 유일한 것이
아닙니다. 중요한 점은 우리가 일을 어떻게 개선해서 성공으로 이끌었는가 하는 점입
니다.
"너무나 흑백논리에서 이야기 하고 있습니다."
우리 어조가 잘난 척 하듯이 들리더라도, 참아 주십시오. 우리는 적당히 얼버무리는 표
현보다 분명히 한 표현 쪽이 좋다고 생각합니다. 그것이 건방지고 오만하게 보인다 하
더라도 괜찮습니다. 경우에 따라선 애매한 표현 보다는, 다소 도발적인 표현이 좋습니
다. 물론 이러한 규칙을 확장하거나 파기해야하는 경우도 있습니다. 그리고 몇 개의 전
7

8. 략은 여러분 환경에는 맞지 않을 수도 있습니다. 여러분의 판단력과 상상력에 맡기십
시오.
"우리 회사에서는 적용할 수 없어요."
Getting Real 을 적용하기에는 회사가 너무 크다구요? Microsoft 조차도 Getting Real
을 적용하고 있습니다. (당신의 회사가 Microsoft 보다 더 큰지 의심이 되는 군요).
비록 여러분 회사를 통상적으로 큰 조직 구조와 장기 스케줄로 운영하고 있다 하더라
도, Getting Real 도입의 여지는 아직 있습니다. 우선은, 큰 조직 단위를 작은 단위로 분
해하는 것입니다. 너무나 많은 사람이 관련되는 경우, 실제로는 아무것도 할 수 없습니
다. 간결하면 간결할수록 업무를 더 빠르고 더 낫게 수행할 수 있습니다.
Getting Real 은 일종의 설득력도 필요합니다. Getting Real 프로세스를 당신의 회사에
적용 해보세요. 동료에게 이 책을 보여주고, 여러분이 짧은 시간에 작은 팀으로 성취할
수 있는 실제 결과를 보여 주세요.
Getting Real 이 새로운 컨셉을 낮은 위험, 낮는 비용으로 시험할 수 있는 방법인 것을
그들에게 설명해 주세요. 이 컨셉을 증명할 수 있도록 큰 프로젝트를 작은 프로젝트들
로 나눌 수 있다는 것을 보여주시고, 실제 데모 결과를 보여주세요.
혹은, 대담하게 가고 싶다면 스텔스처럼 비밀리에 진행하세요. 레이더에 걸리지 않게
비행한 후 실제 결과의 데모를 하는 겁니다. 이것이 Start.com 의 팀이 Microsoft 에서
Getting Real 을 적용한 방법입니다. "나는 Start.com 의 팀워크를 보았습니다. 그들은
승낙을 구하지 않습니다. 그들에게는 지원 공격을 해 주는 상사가 있었고, 그들은 한
번에 조금씩 예산을 요청하고, 그것을 실행하여 피드백에 대응을 합니다"라고
Microsoft 의 기술전도사(Technical Evangelist) 인 Robert Scoble (로버트 스코블)이 얘
기합니다.
- Microsoft 사의 "Start.com" 도입 예
대기업에서는, 프로세스와 회의는 당연한 절차입니다. 무엇이 고객에게 있어서 "옳은"
것인지에 대한 협의 결과를 도출하기 위한 기능 설계와 상세 안의 협의를 이끌어 내는
데도 몇 개월이 걸립니다.
그리하여 딱 맞게 짜여진 소프트웨어는 좋은 접근 방법입니다, 하지만 웹에서는 상상
이상의 이점이 있습니다. 그냥 도입하세요! 그것이 올바로 되었는지 고객의 의견을 들
으세요. 만약 올바르지 않다면, 당신에게 고치라고 할 것이고, 여러분이 원한다면 그날
바로 고쳐 적용할 수 있습니다. 고객 목소리 보다 더 큰 것은 없습니다. 장황한 회의와
8

9. 논쟁을 거듭하며 추진하는 방법은 이제 그만하세요. 그냥 적용하고 문제의 핵심을 증
명해 보이세요.
실행하는 것 보다 말하는 것이 훨씬 쉽다구요?
수 개월짜리 계획은 필요 없습니다.
몇 개월짜리 스펙 기술은 필요 없습니다. 스펙 정의는 기초의 부분에서 끝내고, 상세한
부분은 개발 단계에서 찾아내 개선하십시오. 개발 시작 전에 모든 이슈에 대해 해결하
지 않아도 되고, 모든 세부내역을 밝혀 내려고 하지 않아도 괜찮습니다.
적은 기능을 적용하되 품질은 검증하십시오.
많은 기능을 가지고 완전 새로운 개편 형태의 빅뱅 방법론은 필요 없습니다. 고객이 소
화할 수 있는 작은 기능만 개발 해 주십시오.
작은 버그가 있다면, 서서히 버그를 잡습니다. 유저의 피드백이 빠를 수록, 결과는 좋
아집니다. 아이디어는 계획서 상으로는 좋게 들릴 수 있어도, 실제로는 그렇지 않은 것
도 있습니다. 아이디어가 틀리다는 근본 원리를 더 빨리 발견할 수록 좋습니다.
고객의 피드백의 대응이 빨라지기 시작하면, 고객과의 관계가 구축됩니다. 목표는 고
객이 원하는 것을 구현함으로써 고객을 확보하는 것임을 기억하세요.
—Sanaz Ahari (사나즈 아하리) 프로그램 매니저 Start.com, Microsoft
출발점 chapter 2
적은 구현(Build Less)
경쟁 상대보다 적은 구현
전통적은 명언은 경쟁 상대에게 이기기 위해서는 그들보다 하다 더 하지 않으면 안 된
다고 말하고 있습니다. 상대의 제품에 4 가지 특징이 있다면, 우리는 5 개 (또는 15 개,
또는 20 개 )의 특징이 필요하다. 상대가 x 만큼의 비용을 사용했다면, 우리는 xx 만큼
의 비용이 필요하다. 그들이 20 을 가지고 있으면, 우리는 30 이 필요하다.
이러한 기능 추가 형의 냉전 발상은 쓸데 없습니다. 이러한 방식은 제품을 만드는데 많
은 비용이 들고, 방어적이고, 편협한 방식입니다. 방어적이고 편협한 기업은 앞을 내다
9

10. 보지 못하고 뒤 만 보게 됩니다. 그들은 결코 주도권을 쥐지 못하고, 누군가의 흉내를
낼 뿐입니다.
만약 그러한 기업을 만들고 싶은 것이면, 이 책을 지금 덮어버리는 편이 났습니다.
그러면 무엇을 해야 할까요? 바로 "less (보다 적은)"입니다. 경쟁 상대보다 적게 만들
어서, 그들을 이기는 것입니다. 간단한 문제를 해결하고, 어렵고 까다로운 문제는, 다
른 이들에게 남깁시다. 1 개 기능을 늘리는 것이 아닌, 1 개 기능을 줄여 보세요. 더하는
것보다 덜하게끔 시도해 보세요.
이 책을 통해서, 우리는 이 "보다 적은"의 개념을 소개하고 있습니다. 그 전에, 시작하
는 분을 위해 "보다 적은"을 설명해 보겠습니다.:
• 보다 적은 특징 기능
• 보다 적은 옵션/환경설정
• 보다 적은 인원과 조직 구조
• 보다 적은 회의와 추상화
• 보다 적은 약속
무엇이 당신의 문제인가요?
스스로 소프트웨어를 개발한다.
소프트웨어 개발에 제일 좋은 방법은, 자기 자신의 문제를 해결하려고 하는 것입니다.
스스로 고객 사용자층이 되면, 무엇이 중요하고 무엇이 그렇지 않은가를 알게됩니다.
거기서부터, 상식의 벽을 깨는 제품의 첫 출발을 하게 됩니다. .
여기서의 핵심은 당신은 혼자가 아니다라는 것입니다. 즉, 당신이 이 문제에 봉착하게
되면 같은 배에 타고 있는 수십만 명의 사람도 마찬 가지라는 겁니다. 이것이 당신의
시장 market 입니다. 간단하죠?
Basecamp 는, 1 개의 문제로부터 시작되었습니다. 디자인 회사인 우리는, 프로젝트에
대해 우리의 고객들과 간단히 커뮤니케이션 하는 방법이 필요했습니다. 우리는 직접
고객을 위한 Extranet 을 만들어 적용해 봤습니다. 그러나 프로젝트 갱신이 필요 시에
매번 HTML 을 수작업으로 처리해야 했기에, 제대로 할 수 가 없었습니다. 이러한 프로
젝트 사이트는 마치 신선미가 없는 느낌이 나버렸고, 결국 그만두게 되었습니다. 일을
10

11. 부드럽게 해야 할 아이디어가 결과적으로 역효과가 되어, 클라이언트에도 폐를 끼쳐
버린 적도 있었습니다.
거기서, 우리는 다른 방안을 모색하기 시작했습니다. 그러나, 우리의 주위에 있는 툴은
1) 필요로 하고 있는 기능이 없거나 혹은 2) 필요 없는 기능투성이로 (예를 들면 과금,
어려운 접근 방법, 차트, 그래프 등등.) 결국 스스로 만드는 것이 좋겠다라는 하는 결론
에 이르렀습니다.
스스로 직면한 문제를 해결할 때, 당신은 열정적으로 그 툴을 개발할 수 있습니다. 열
정은 핵심 키워드입니다. 열정은 당신이 정말로 사용하고 싶고, 잘 해 나가고 싶은 그
런 것입니다. 그리고, 다른 사람으로 하여금 그것에 대해 같은 열정을 느낄 수 있게 하
는 최고의 방법이 됩니다.
가려운 곳을 직접 긁어라.
오픈 소스 진영에서도 오래 전에 이 진리를 깨닫다 — 오픈 소스 진영에서도 "가려운
곳을 직접 긁어라."라고 얘기하곤 한다. 오픈 소스 개발자에겐 그들이 원하는 것을 직
접 구해서 다른 이들에게 그 방법을 알려주면, 더 많은 혜택을 얻을 수 있다는 의미로
통용된다.
새로운 어플리케이션의 디자이너 혹은 개발자로서 당신은 매일 수많은 작은 결단을 그
때마다 매일 하게 된다. 파란색 혹은 녹색? 1 개 표 혹은 2 개 표? 정적인가 동적인가?
폐기할지 복구할지? 등등 이러한 결단을 어떻게 내면 좋은가? 만약 이것이 중대한 결
단이라면 조언을 요청하게 되지만, 나머지는 스스로 예상하지 않으면 안 된다. 이러한
자신의 결단이나 예상이 어플리케이션의 일부가 됩니다.
개발자로서 나는 이런 일은 싫습니다. 소프트웨어에 내가 추가하여 넣은 코드들은 작
은 수준의 시한폭탄의 스트레스가 됩니다. 가려운 곳을 직접 긁는 오픈 소스의 개발자
의 경우, 이러한 스트레스에 고민하지 않습니다. 그들의 유저가 문제의 90%정도는 무
엇을 해야 하는지 정확한 대답을 제시해 주기 때문입니다. 그렇기 때문에 회사에서 힘
들게 개발을 하고, 집에 돌아가서도 오픈 소스의 프로젝트에 참가할 수 있습니다. 그게
쉬는 것입니다.
—Dave Thomas, 실용주의 프로그래머
필요는 발명의 어머니
Campaign Monitors 의 소프트웨어는 실제 필요에 의해 만들어졌습니다. 몇 년 전부터
우리는 e-Mail 마케팅의 방법에 대해서 여러 가지 고민하고 있었습니다. 어느 툴은 x 와
11

12. y 는 할 수 하지만, z 는 할 수 없었고, 또 다른 툴은 y 와 z 는 할 수 있지만, x 는 할 수 없
었습니다. 우리는 결코 만족할 수 없었습니다.
결국 우리는 시간을 만들어 우리가 원하는 환상적인 e-Mail 마케팅의 툴을 만들기로 했
습니다.. 우리는 굳이 모두가 사용할 수 있는 툴 보다는 우리와 우리의 고객이 보다 편
리해지게 끔 되는 툴을 만들기로 결정했습니다.
그러면서 알게 된 것은 기존의 제품들의 기능에 대해 만족하지 못하는 것은 우리 외에
도 많다는 것을 알 수 있었습니다. 우리는 어떤 디자인 회사라도 사용할 수 있도록 소
프트웨어를 조금 수정하였고, 소문은 퍼지기 시작하였다. 6 개월이 되기 전에 수 천명
의 디자이너들이 Campaign Monitor 를 사용하여 그들의 고객들에 email 뉴스레터를
발송하게 되었다.
—David Greiner, 창업자, Campaign Monitor
신중해져야 한다
책을 쓸 때는, "재미있는 이야기"이상의 것이 필요합니다. 이야기를 전하려는 열정이
필요하며, 어떤 방식으로든지 약간의 개인적인 투자도 필요합니다. 2 년, 3 년 혹은 여
생을 같이 살아야 한다고 생각해 보세요. 신중해질 수 밖에 없습니다.
—Malcolm Gladwell, (from A Few Thin Slices of Malcolm Gladwell)의 저자
스스로 투자하라.
투자 유치는 차선 책이다.
사업을 시작한 후 초기의 최우선 사항은 대부분 투자가로부터의 자금 투자입니다. 하
지만 외부로부터 자금을 투자 받기 시작한 경우, 그들의 요청에 따를 의무가 생기는 것
을 잊지 마세요. 기대는 높아지고, 투자가는 조속한 자금 회수를 원합니다. 안타깝지
만, 이러한 요구로 인해 제품의 수명이 짧아지는 경우도 있습니다.
최근에는 사업 운영에 필요한 자금이 그렇게 많이 필요 하지 않습니다. 하드웨어는 저
렴해 졌고, 인프라 부분의 소프트웨어는 대부분이 오픈 소스로 무료로 구할 수 있습니
다. 무엇보다도 열정은 돈과 바꿀 수 없는 중요한 것입니다.
12

13. 자신의 손안에 있는 자금만으로 완성할 수 있는 것을 시작하세요. 심사 숙고해서 무엇
이 실제 필수적이고, 없어도 되는지 결정하세요. 10 명 보다 3 명 이서 무엇을 할 수 있
을까요? 1 억 원 보다 2 천만 원으로 무엇을 할 수 있을까요? 6 개월보다 3 개 동안 무엇
을 할 수 있을까요? 직장을 가지고 있으면서도, 정말로 만들고 싶은 어플리케이션을
자유시간에 추진하려면, 어떻게 하면 좋을까요?
제약으로부터 창조는 이루어집니다.
한정된 자원으로의 시작할 경우 제약에 따른 압박감이 점차 강해집니다. 이것은 좋은
현상입니다. 제약은 곧 혁신을 불러 일으킵니다.
제약이 줄 수있는 또 하나의 이점은 아이디어를 미루지 않고 보다 빠르게 실행할 수 있
게 도와준다는 것입니다. 시작 시점 후 1 개월 혹은 2 개월 후에 그 아이디어로 잘 해
나갈 수 있을지를 알 수 있게 됩니다. 만약 잘 할 수 있다고 판단될 경우 외부 투자 자금
이 없어도, 스스로 계속해 갈 수 있습니다. 만약 아이디어가 형편 없다면, 다시 원점으
로 되돌아 갑시다. 수 개월 또는 수 년 후가 아닌 지금 길을 갈 수 있게 됩니다. 그리고
쉽게 되돌아올 수도 있습니다. 탈출 계획이라는 것은 투자자가 개입되면서 책임을 피
하기 위해 생겨난 말입니다.
만약, 눈앞의 이익을 위해서 소프트웨어를 형편없이 만들면, 금방 티가 납니다. 그렇기
때문에 당신 및 고객이 오랫동안 사용할 수 있는 품질 높은 툴을 만드는 것이 중요합니
다.
2 가지 방법
[Jake Walker(제이크 워커)는 투자가로부터의 자금을 받아 Disclive 라는 회사를 설립
하고, 또 하나는 스스로의 자금으로 The Show 라는 회사를 설립하였습니다. 그 두 개
의 방법의 차이가 무엇인지 그 차이점을 들어봅시다.]
첫번째 회사[Disclive]는 : 문제의 근본은 모두, 자금 융통 그 자체가 아니고, 그 돈에 대
한 여러 가지 소문에 대한 것입니다. 기대는 정말이지 높습니다. 직원끼리 급여에 대해
이야기하기 시작하고, 제품을 만들어 파는 것이 모티베이션이라는 둥, 혹은 초기 투자
자가 그들의 투자금을 회수하기 위한 조치를 취할 것이라고 얘기 하기 시작 시작했습
니다. 첫 번째 회사의 경우에 대해 우리의 목적은 회사를 크게 보이게 하는 것이었습니
다. 전혀 불필요한 것이었지요.
후자의 회사[The Show]는 : 우리는 보다 적은 비용으로 약간의 시간만 더 투입하면 보
다 낳은 제품을 만들 수 있다는 걸 깨달았습니다. 그리고, 우리는 사람들이 바로 구매
13

14. 하기 보다는, 좋은 품질을 위해 약간 기다려줄 수 있다는 것에 우리가 가지고 있던 자
금을 투자하여 모험을 해 보았습니다. 그리고 회사는 아직도 소규모입니다 (이 자세는
향후도 계속해 가겠지요) 그 최초의 프로젝트 이래 우리는 스스로 여태껏 외부 자금투
자유입 없이 자체 자금으로 운영할 수 있었습니다. 벤더와의 계약을 약간의 창의적으
로 함으로써, 큰 돈을 들이지 않고도 운영할 수 있었습니다. 성장하고 판매가 늘어남은
물론, 재무적으로도 성정하고 이익을 계속 내는 형태로 유지되었습니다.
— Signal vs. Noise 의 교훈
일정과 예산은 고정시키고, 범위를 유
연하게 하세요.
예산과 일정 범위 내에서 완료하세요.
일정과 예산 범위 내에 프로젝트를 완료하는 간단한 방법을 소개합니다: 결정된 것을
지킨다. 문제에 대해서는 시간이나 돈으로 해결하지 말고, 단지 범위를 축소한다.
이런 전설이 있습니다. : 우리는 일정, 예산, 범위 내에 완료할 수 있다. 하지만 이것은
품질을 떨어뜨리지 않고는 불가능하다.
모든 것을 계획된 일정과 예산안에서 해결할 수 없다 하더라도, 절대로 일정과 예산을
늘리지 말고 범위를 축소시키세요. 향후 이러한 기능을 포함시킬 시간은 언제든지 있
습니다.나중은 끝없이 영원하고 지금은 쏜 살 같이 지나갑니다.
비현실적인 마법 같은 시간, 예산, 범위로 헛점투성이의 싸구려 결과물을 만드는 것보
다도 계획보다 범위가 축소되어 보다 작게 시작하는 것이 낳습니다. 그런 마법은 마술
사 후디니(역주: 세계최고의 탈출 마술사, 1874-1926)에게나 맡기세요. 제대로 된 제품
을 시장에 공급하는 것이 현실 세계의 비즈니스입니다.
시간과 예산을 고정시킴으로써 얻을 수 있는 효과에 대해서 알아보겠습니다.:
• 우선 순위
무엇이 정말로 중요한 것인가를 파악해야 합니다. 최초 출시를 위해 무슨 기능
의 제품을 만들고 있습니까? 이러한 제약은 당신으로 하여금 것은 쓸데없는 것
대신 명백한 결정을 할 수 있도록 있게 해줍니다.
14

15. • 현실성
기대치를 정하는 것이 중요합니다. 만약 시간, 예산 및 일정을 조정한다고 한다
고 해도, 고품질의 제품을 출시 할 수 없을지도 모릅니다. 물론 무엇인가를 출시
할 수 있습니다만 정말 그렇게 출시하고 싶으십니까?
• 유연성
변화관리 능력도 중요합니다. 한번 결정된 것들은 변경하기가 어려워집니다. 유
연성의 요소를 가미시켜 제품 개발 시 경험에 근거한 옵션이 도출되도록 합니
다. 유연성은 당신의 친구입니다.
우리가 추천하고자 하는 것은: "범위를 축소시켜라"고 하는 것입니다. 그것이 비록 반
쪽 기능의 제품이라도, 형편없는 전체 기능의 제품 보다는 낳습니다. (뒷장에서 자세하
게 설명하겠습니다.)
1, 2, 3 ...
어떻게 프로젝트가 예정보다 1 년이나 지연될 수 있을까요? 하루에 하나씩 하는 겁니
다.
—Fred Brooks, 소프트웨어 엔지니어 및 컴퓨터 공학가
라이벌을 만드십시오.
맞서 싸우세요.
당신의 어플리케이션이 어떤 모습일까 생각하는데 있어서 최상의 방법은 반대로 생각
하는 것-'어떤 모습이 되어서는 안되는가?'입니다. 라이벌의 어플리케이션을 분석하고,
당신이 어느 방향으로 가야 할 것인가에 대한 이정표를 수립하세요.
우리는 Microsoft Project 가 너무나 고릴라 같이 거대 했기 때문에 프로젝트 관리 소프
트웨어를 새롭게 개발하자고 의사 결정을 했습니다. 고릴라에 맞서는 두려움대신 이것
을 동기부여의의 기회로 이용했습니다. 그 때문에 우리는 BaseCamp 를 MS Project 과
대비하여 무엇인가 색다른 것이 필요로 했습니다.
15

16. 프로젝트 관리란 차트, 그래프, 리포트 및 통계치에 대한 것이 아닌, 바로 '커뮤니케이
션' 이라는 것을 깨닫게 되었습니다. 그것은 PM 이 단숨에 만들어 일방적으로 배포하
는 것이 아니라, 프로젝트가 추진되기 위해 서로가 각자의 책임에 대해서 사람들이 서
로 얘기하는 것이었습니다.
우리의 적은 프로젝트 관리 독재자와 그가 휘두르는 채찍입니다. 우리는 프로젝트 관
리에 민주화 혁명을 일으키고 싶었습니다 - 고객을 포함하여 구성원 모두 동일하게 참
가할 수 있는 프로젝트 툴로 말입니다. 프로젝트는 모두가 각 프로세스에 대해 오너십/
책임감을 가질 때 보다 더 좋게 변화됩니다.
"WriteBoard" 의 때도 우리는 이미 경쟁 사가 소위 많은 전문 특징에 노력을 기울이고
있던 것을 알고 있었습니다 그래서 오히려 우리는 반대로 요란하지 않는 점을 강조하
기로 결정했습니다. 우리는 사람들이 간단하게 아이디어에 대해 공유하고 협업할 수
있는 어플리케이션을 불필요한 기능은 버리고 개발했습니다. 우리는 서비스 출시 3 개
월만에 10 만명의 Whiteboards 고객을 확보했습니다.
"Backpack" 의 프로젝트 때는 우리의 적은 구조와 엄격한 규칙이었습니다. 사람들은
스스로의 정보를 스스로의 방식으로 자유롭게 정리할 수 있어야 하며, 이것은 사람들
로 하여금 미리 정형화된 연속된 화면이라든가 과다한 입력 요구가 있어서는 안됩니다.
라이벌을 가지고 있다는 것의 또 다른 잇점의 하나는 분명한 매우 마케팅 상의 메시지
를 가질 수 있는 것입니다. 사람은 결전에 대해 열광적입니다. 그리고 그들은 경쟁사와
비교함을 통해 제품을 이해합니다. 다른 라이벌과 함께 그들에게 그들이 듣고 싶어하
는 이야기를 할 수 있습니다. 당신의 제품을 보다 빠르게 많이 이해할 것이며, 그들은
선택할 것입니다. 이것이 그들의 관심과 열정을 더 높여줍니다.
또 하나 중요한 것은 반대로 경쟁을 너무 의식하면 오히려 좋은 결과가 되지 않는 것도
중요합니다. 타사의 제품을 너무 분석하면 스스로의 생각이 틀이 갇혀버리게 됩니다.
주위를 둘러 본 다음, 당신 자신의 시점과 자신의 비전과 자신의 아이디어를 가지고 진
행하십시오.
선구자의 따르지 마라.
마케터(혹은 모든 사람은)는 선구자를 따라서 하라고 훈련 받습니다. 그러나 경쟁 상대
의 강점을 알아내고, 이를 경쟁사보다 빠르고 싼 가격으로 승부하기 위해 노력하는 것
은 인간의 본성입니다.문제는 한 소비자가 다른 사람의 이야기를 듣고 거짓말을 믿어
버렸을 사버린 경우, 그 소비자는 그것을 또 다른 소비자에게 같은 방식으로 전개합니
다. 그리고 그들은 그들이 틀렸다는 것을 싫어합니다.
16

17. 중요한 것은 당신은 전혀 다른 이야기를 해야 하고, 이것이 그들이 지금 믿고 있는 사
실보다 중요하다는 것을 설득시켜야 합니다. 경쟁 상대가 신속할 수록, 당신은 싼 가격
으로 승부해야 합니다. 경쟁 상대가 건강을 이야기하면, 당신은 편리함을 이야기 해야
합니다. x/y 축 기반의 "우리가 더 저렴합니다."라고 외치지 말고, 이미 들어 알고 있는
사실들과 차별되는 실제 이야기를 해주세요.
—Seth Godin, from Be a Better Liar)의 작가/기업가
무엇이 근본의 문제인가
직면한 문제에 대한 가장 민첩한 해결 방법은 바로 경쟁사는 무엇을 하고 있는지 보는
것입니다. 이것은, 특히 우리의 서비스인 BlinkList 로 몸소 체험했습니다. 우리가 서비
스를 시작했을 때, 벌써 10 여개나 되는 소셜 북마크의 서비스가 있었습니다. 상세한
특징 비교를 온라인으로 내는 사람도 나오기 시작했습니다.
그러나, 이런 경쟁으로 머리가 가득한 상황에서는 자칫 길을 잘 못 갈 수 있습니다. 우
리는 큰 비전에 집중했고, 항상 스스로에게 물어 보았습니다. - "무엇이 우리가 해결해
야 할 문제인가, 그 문제를 어떻게 해결해 나가야하는가?"라고.
—Michael Reining, 공동 창업자, MindValley & Blinklist
잡일을 만들지 마세요.
당신의 열정과 갈망이 길을 비추리라...
어플리케이션이 작을 수록 해야하는 일이이 작아집니다. 프로세스를 즐기기 위해서라
도 그것을 작고 관리가 가능하게 작게 유지하세요.
만약 당신의 어플리케이션에 재미가 없다고 느끼면, 무엇인가 문제가 있는 것입니다.
만약 당신이 단지 돈을 위해서 일을 하고 있다면, 금방 표시납니다. 이와는 반대로 당
신의 어플리케이션에 열정을 느낀다면, 그것은 최종 결과물에 묻어납니다. 사람들은
이 두 문맥을 이 차이를 바로 느낄 수 있습니다.
열정을 보여주세요.
17

18. 디자인에서는 결과의 의미가 대단히 주관적이기 때문에 애매모호한 일도 종종 있으나,
정열의 차이도 극명합니다. 제품의 디자인은 흥미를 갖게 하거나 시시함을 안겨주거나
둘 중의 하나입니다. 두 경우 다 그것을 제작할 시의 노력을 예측하는 것은 어렵지 않
습니다.
열의는 물론 바로 즉시 표현되고, 냉담도 역시 잊혀지지 않습니다. 진짜 열정에 싸여
일을 추진하지 않으면, 아무리 정성 들여 만들고 매력적으로 디자인되어있다 할지라도
이것은 숨길 수 없는 공허함이 되어 버립니다.
—Khoi Vinh, Subtraction.com
빵집
지금의 미국의 비즈니스는 그야말로 아이디어를 개발하고, 그것을 유리하게 잘 만들어
판매하여, 이것이 수익을 내고, 확장하거나 다각화 하는 것입니다. 이것이 모든 초기
사업의 전부입니다. 내 아이디어는 이렇습니다. : 즐겁게 빵을 구워, 사람들에게 팔고,
사람들이 이것을 좋아하게 되면 더 많이 팔 수 있습니다. 그리면 빵집은 계속 유지하여
좋은 음식을 만들 수 있고, 이로 인해 사람들은 행복해지게 됩니다.
—Ian MacKaye, member of Fugazi and co-owner of Dischord Records
(from Salon.com People | Ian MacKaye)
Stay Lean chapter 3
"보다 작은"규모
가벼울 수록, 변화하기가 쉬워집니다.
T 사물이 크면 큰 만큼, 그 방향을 바꾸는데 막대한 에너지가 필요하게 됩니다. 물리의
세계뿐만이 아니라, 이것은 비즈니스의 세계에도 적용되는 사실입니다.
그것이 웹 테크놀로지의 이야기가 되면, 변화는 보다 간단하게, 보다 저렴하게 실시할
수 있습니다. 만약 변화의 스피드를 따라갈 수 없어지면, 다른 누군가가 그것을 가로채
갈 것 입니다. 이것이 작은 규모를 제안하는 이유입니다.
18

19. 규모가 커지는 요소는......
• 장기간 계약
• 너무 많은 스텝
• 불변인 결정
• 미팅을 위한 미팅
• 번잡한 프로세스
• 물품 재고 명세서 (물리적 혹은 정신적인)
• 폐쇄적 기술의 소프트웨어, 하드웨어, 테크놀로지
• 독점 형태의 데이터 포맷
• 과거에 정해진 미래
• 긴 로드맵
• 사내 정치
반대로, 규모를 작게 하기 위해서는 ...
• 적시적인 의견
• 팀원의 멀티태스킹
• 제약사항 파악 (제약사항 제거가 아님)
• 보다 적은 소프트웨어, 보다 적은 코드
• 보다 적은 기능/특징
• 작은 팀 규모
• 심플함
• 젤제된 인터페이스
• 오픈 소스의 제품
• 데이터 포맷의 오픈화
• 실패도 쉽게 인정할 수 있는 개방적인 문화
작은 규모는 방향 변경을 쉽고 신속하게 할 수 있습니다. 반응과 진화가 가능합니다.
좋은 아이디어에만 집중할 수 있고, 나쁜 것은 Drop 시킬 수 있습니다. 고객의 소리에
귀를 기울여 대답할 수 있습니다. 새로운 기술을 뒷전으로 하지 않고, 바로 도입할 수
있습니다. 항공모함이 아니고, 쾌속선으로 가세요. 이러한 사실을 즐기세요.
예를 들면, 적은 기능으로 보다 적은 소프트웨어를 만드는 군살 없는 소규모의 회사를
상상해 봅시다. 한편, 많은 기능으로 많은 소프트웨어를 판매하고 있는 대기업도 상상
해 봅시다. Ajax 와 같이 새로운 기술, 새로운 컨셉의 것이 등장하게 되면, 어느 쪽이 보
다 신속히 제품에 도입할까요? 후자와 같은 대규모 상품 전개와 1 년 넘는 로드맵으로
19

20. 움직이는 대기업과 "지금, 우리가 주목 해야 할 것에 주목하자"라고 하는 소규모의 유
기적인 조직 중 어느 쪽이라고 생각하십니까?
물론 소규모의 기업 쪽이 시장의 요구에 민감하게 반응할 수 있는 환경에 있는 것은 분
명합니다. 작은 회사가 방향을 전환한 다음에도, 대규모의 회사는 방향을 바꿀지 계속
논의하거나 언제 돌아올지 모르는 상부로부터의 대응을 기다리는 것이 되겠지요. 대기
업이 어떻게 추진할까를 계획하고 있는 동안, 소규모의 회사는 두발이나 세발 더 앞 설
수 있습니다.
재빠르고 민첩한 한 작은 규모의 비즈니스는, 비즈니스 모델, 제품, 특색, 마켓 메시지
등 모든 것을 재빠르게 바꿀 수 있습니다. 실수가 있어도 재빠르게 수정할 수 있습니
다. 그 외, 우선 순위나 제품의 편성, focus 등도 바꿀 수 있습니다. 그리고 가장 중요한
것은 스스로의 사고 방식도 바꿀 수 있다는 것입니다..
변화에 따른 비용을 적게 하세요.
변화의 장애를 줄여서 유연하게 대처하세요.
변화는 당신에게 있어서 최고의 친구입니다. 변화의 비용이 많이 들수록, 그만큼 그것
을 완수하기 힘들어집니다. 그리고, 경쟁 상대가 보다 빠르게 변화한다면, 당신은 매우
불리한 입장에 놓여집니다. 변화가 너무 많은 이용을 요구하게 되면, 그것은 곧 죽음을
의미합니다.
이러한 것 때문에 군살을 빼는 것의 진가가 발휘됩니다. 만원으로 변화를 완수하는 능
력은, 작은 팀에서는 기본적으로 가능한 것으로써, 큰 조직에서는 결코 불가능한 일입
니다. 이런 이유로 큰 것이 작은 것을 시기 합니다. 거대한 조직에서의 거대한 팀이 몇
주 걸리는 것을 작은 조직에서는 불과 하루 만에 가능합니다. 이러한 장점은 가격을 매
길 수 없습니다. 저비용으로 신속한 변화가 가능하다는 것은 숨은 병기와도 같습니다.
기억하세요: 작기 때문에 가능한 민첩성은 세상의 모든 돈이나 마케팅, 사람으로 얻을
수 없는 것입니다.
그리고 웹 기반 기술에서의 변화는 쉽고 저렴해야 합니다. 변혁은 간단하고 싸지 않으
면 안됩니다. 만약 재빠르게 변화할 수 없다면, 다른 사람이 치고 올라옵니다. 이것이
작은 규모를 유지해야 하는 이유입니다.
20

21. Emergence
Emgergence 는 기민함의 기본 원리이며, 마법의 원리 중에 하나입니다. Emergence
의 특징들은 미리 계획되거나 디자인되는 것이 아닙니다. 그것들은 전체 시스템의 다
양한 결과에 의해서 자연스럽게 나타나게 됩니다. "Emergence"라는 말은 17 세기의
라틴어로 "예측되지 않은 발생"이라는 뜻입니다. 우리는 그것을 예측허가나 계획할 수
없으며, 다만 그러한 발생이 가능한 환경을 만들 수 있을 뿐입니다.
Emergence 의 전형적인 예는 떼를 지어 날아가는 새들에서 찾을 수 있습니다. 컴퓨터
시뮬레이션에서는 3 개의 간단한 규칙만 사용해서 새들이 목적지로 날아가는 동안 장
애물 피한 후에 따시 전열을 갖추는 등의 복잡한 행동들을 구현할 수 있습니다. 이러한
고도의 동작들은 그것에 대한 정해진 규칙이 있는 것이 아니며, 전체 시스템에 의해서
역학적으로 발생(emergence)하는 것입니다.
새들의 시뮬레이션에서와 같이 간단한 규칙들이 복잡한 행동을 이끌어 냅니다. 반면에
복잡한 규칙들은 어리석은 행동을 유발합니다. 많은 나라의 복잡한 세법들이 그러한
예입니다.
소프트웨어 개발에서의 많은 관례들은 불행하게도 Emergence 가 발생할 가능성을 제
거하는 부작용을 가지고 있습니다. 최적화를 위한 많은 노력들은 Emergence 의 발생
에 있어 가장 중요한 상호작용과 관계들의 범위를 줄여버립니다. 떼를 짓는 새들의 예
에서도 흥미롭고 유용한 행동을 만들어 내는 것은 새들간의 관계와 상호작용입니다.
우리가 일들을 고정하고 단단히 묶어버릴 수록 창의나 Emergence 가 발생할 여지는
줄어들게 됩니다. 잘 이해하지 못한 상태에서 요구사양을 확정지어버리거나 너무 이른
시점에 코드를 최적화하려고 하거나, 고객이 시스템을 사용해보기도 전에 복잡한 네비
게이션이나 워크플로우를 만들고 고정해버리는 것들이 그러한 예입니다. 그 결과는 불
필요하게 복잡하고 멍청한 시스템이 될 것이며, Emergence 가 발생할 수 있는 깔끔하
고 우아한 시스템은 결코 될 수 없습니다.
작게 유지하세요. 단순하게 유지하세요. 이루어지게 하세요.
—Andrew Hunt, The Pragmatic Programmers
삼총사
21

22. 버전 1.0 은 3 명의 팀에서 개발 해라.
어플리케이션의 최초의 버전은 단지 3 명만으로 시작하세요. 그것이 당신이 능률적이
고 민첩하게 계속 되게 해주는 맨파워를 부릴 수 있는 마법의 숫자입니다. 개발자와 디
자이너와 스위퍼 (Sweeper, 두 세상을 조율해 줄 수 있는 사람)로 시작하세요.
소수 인원수만으로 어플리케이션을 구축하는 것은 분명한 도전입니다. 그러나 올바른
팀을 가지고 있다면, 그것은 가치 있는 일입니다. 능력이 있는 사람에게는 끝없는 자원
은 필요 없습니다. 그 사람들은 제한적인 환경에서도 도전적인 과제들을 성공시키며,
창조성으로 문제를 해결합니다. 일손이 부족하다고 하는 것은, 프로세스의 초기에 있
어 무엇인가 거래를 해야 하는 의미를 내포하고 있지만 문제 될 것이 업습니다. 그것은
당신에게 나중보다는 먼저 해야 할 우선순위를 생각하게 합니다. 그리고 당신은 정기
적으로 동료의 걱정을 없애기 위해 커뮤니케이션을 하게됩니다..
만약 당신이 첫 번째 버전을 세 사람이 구축할 수 없으면, 추가 인력이 필요한가 아니
면 최초 버전의 규모를 축소해야 하는가를 생각하게 됩니다. 최초 버전은 작고, 타이트
에서도 상관없다는 것을 기억하세요. 당신의 아이디어에 날개가 있을지 어떨지는 곧바
로 압니다. 그렇게 함으로써, 명료하고 심플한 기반의 제품을 가질 수 있습니다.
메트칼프의 법칙(Metcalfe's Law)과 프로젝트 팀
팀은 가능한 한 작게 유지하세요. "커뮤니케이션 시스템의 가치는 그 시스템의 유저수
의 제곱으로 증가한다"는 Metcalfe’s Law(매트칼프 법칙)도 프로젝트 팀에 대해서도
적용됩니다. 팀의 효율성은 팀 내의 멤버의 수의 제곱에 반비례 합니다. 1.0 의 제품의
출시에는 3 명이 최적이라고 생각합니다. 당신은 팀에 가세하려고 한 사람들의 수를
줄이는 것부터 시작하세요. 그리고 한층 더 여러 명 줄이는 겁니다.
—Marc Hedlund, O'Reilly Media 기업가
커뮤니케이션 흐름
커뮤니케이션은 큰 팀보다는 작은 팀에서 잘 통용됩니다. 만약 당신이 프로젝트에 있
어서의 유일한 사람이라고 하면, 커뮤니케이션은 간단합니다. 유일한 커뮤니케이션 경
로는 당신과 고객입니다. 프로젝트에 관련되는 사람의 수가 증가할 수록, 커뮤니케이
션의 경로도 증가합니다. 그것은 사람의 수가 증가함에 따라서 가산되어 가는 것은 아
닌, 사람의 수의 제곱에 비례해 배로 증가해서 갑니다.
22

23. —Steve McConnell, Chief Software Engineer at Construx Software Builders Inc.
(from Less is More: Jumpstarting Productivity with Small Teams)
제한을 수용한다.
제한을 창조적 해결책으로 승화하세요.
세상에 있는 것은 결코 충분하지는 않습니다. 시간도 돈도 사람도 충분하지 않습니다.
그것은 좋은 일입니다.
이러한 제약사항으로 흥분하지 말고, 받아 들이세요. 제약사항은 창조와 초점에 집중
하도록 해줍니다. 제약 사항을 없애려 하지 말고, 그것을 당신에게 유리하게 이용하세
요.
37signals 의 경우도 "Basecamp" 개발시에 많은 제약이 있었습니다. 그것은：
• 운영 디자인 회사 결정
• 기존의 고객과의 일
• 7 시간의 시차(프로그래머 David 은 덴마크에서 개발하고 있었고, 나머지는 미
국에서 있었습니다.)
• 작은 팀
• 외부 조달 투자가 없는 상태
우리는, "충분하지 않다"라고 투덜대고 있었습니다. 우리는 그릇을 작게만 하고 있었습
니다. 작은 그릇은 담을 수 있는 양도 정해져 있습니다. 우리는 큰 태스크를 작은 단위
로 쪼갠 후 한번에 한 개씩 실행 했습니다.. 사전 우선순위를 결정한 대로 단계별로 해
결해 나갔습니다.
그것은 우리로 하여금 창의적인 제품을 개발할 수 있게 해주었습니다. 언제나 작은 규
모로 소프트웨어를 개발하여 우리는 변경 비용을 낮췄습니다. 사람들에게 스스로의 문
제를 스스로의 방법으로 해결하는데 충분한 특징을 도입해, 그들에게 맡겼습니다. 우
리들 내부의 시차와 거리의 문제는 커뮤니케이션을 함에 있어 보다 효율적으로 할 수
있게 해주었습니다. 사람과의 미팅 대신에, 대부분 메신저와 전자메일로 커뮤니케이션
하였으며, 이것이 우리의 문제에 대해 빠르게 집중할 수 있었습니다.
23

24. 제약사항은 가끔씩은 우리에게 장점이 됩니다. 벤처캐피털, 긴 제품 출시 일정, 고용은
잊어버리고, 가지고 있는 자원으로 일에 전념하세요.
해충과 싸우세요
"Creeping elegance"(프로그래머들이 지나치게 고상함에 집착하여 소프트웨어의 기
능성이나 스케쥴, 사용성을 다소 무시하는 현상)는 "기능 해충"으로 표현하는 것이 더
적절할 지도 모릅니다. 이것은 식물의 진액을 빨아먹고식물 전체를 서서히 망가뜨리는
곰팡이와 같습니다. 소프트웨어에서 기능 해충을 방지하는 가장 쉬운 방법은 물론 데
드라인을 압박하는 것입니다. 데드라인에 대한 압박은 구현이 오래 걸리는 기능들을
제외하게 만듭니다. 하지만 일반적으로는 가장 중요한 기능이 구현하는 데 시간도 가
장 오래걸립니다. 따라서 기능 해충과 데드라인의 조합은 중요하지 않은 기능들로만
가득찬 소프트웨어라는 결과를 만들게 되므로 주의해야 합니다.
—Jef Raskin, 저자 ( "Why Software Is the Way It Is" 에서)
있는 그대로
대기업과는 다른 사람의 마음을 생각한 친밀감 있는
방법으로 접근하세요.
많은 작은 기업들이 스스로를 크게 보이게 하려고 행동하는 실수를 합니다. 스스로 작
은 규모를 극복 해야할 약점으로서 생각하는 것 같습니다. 안타깝습니다. 작은 것은 큰
무기입니다-특히 커뮤니케이션의 부분에서는 더 그렇습니다.
작은 회사는 격식이 적고, 관료적인 것이 덜하고, 보다 자유롭습니다. 기본적으로 작
은 회사는 고객과 가까운 위치에 있습니다. 그것은 고객과 직접 개개인에 접근 할
수 있는 방법으로 커뮤니케이션이 생기는 것입니다. 만약 작은 조직이라면, 까다로운
전문 용어를 사용하지 않고 더 친밀한 말로 이야기를 할 수 있습니다. 당신의 사이트나
제품은 기업의 선전문구가 아닌, 인간의 메시지를 전할 수 있습니다. 작은 규모라는 것
은 고객을 깔보는 것이 아닌 고객과 대화할 수 있는 것입니다.
작은 회사에서는 조직 내부의 커뮤니케이션에도 장점이 있습니다. 무엇인가의 서류에
좌지우지되지 않고, 쓸데없이 복잡한 프로세스나 여기저기의 승인 도장도 필요 없게
24

25. 됩니다. 어느 과정에서도 멤버 전원이 오픈 마인드로 정직하게 이야기할 수 있습니다.
아이디어에 속박이 없는 흐름은, 작은 규모의 큰 이점의 하나입니다.
당당히 정직하게
어쩌면 소비자는, 기업의 종업원수나 제품의 수, 즉 기업의 규모를 과장하면 속아 버릴
것이라고 생각할지도 모릅니다만, 영리한 사람(즉 당신이 정말로 타켓으로 하고 싶은
사람)은, 언제나 진실을 압니다. 창피한 이야기입니다만, 저도 과거에 이러한 자신을
크게 보이려고 했던 한 명입니다. 그러나, 그러한 일을 해도, 비즈니스가 의미 있는 것
이 되어, 스스로의 서비스를 정말로 필요로 하고 있던 고객과의 관계가 계속 되어 신뢰
깊은 관계가 생긴 일은 없었습니다. 결국, 회사의 실제의 규모가 작아도 부끄러워하는
않고, 솔직하게 말하면 좋습니다.
—Khoi Vinh, Subtraction.com
언제라도
고객에게 있어서 좋은 고객 서비스는 어떤 비즈니스든지 최대의 기대사항입니다. 우리
조차도 그것을 바라는데, 고객은 어떻겠습니까? 초창기부터 우리에게 문의하는 모든
고객 및 모든 질문에 투명하게 대응했습니다. 웹 사이트에서는 무료 전화 번호를 기재
하여, 우리 휴대폰으로 오게 했고, 명함에도 각자의 휴대폰 번호를 기재했습니다. 우리
는 고객에게 무슨 일이 일어나든지 우리에게 연락할 수 있다고 강조했습니다. 고객들
은 이러한 신뢰에 대해 고마워했고, 이 서비스에의 클레임은 없습니다.
—Edward Knittel, Director of Sales and Marketing, KennelSource
우선순위 chapter 4
커다란 아이디어
친근하고 인간적인 방식으로 대기업과 차별화하세
요.
25

26. 어플리케이션이 지향하는 바를 구체적으로 하나 정의하세요. 무엇을 위한 서비스인가
요? 디자인이나 코딩을 하기전에 어플리케이션의 비전을 분명히 알아야 합니다. 크게
생각하세요. 왜 이 것이 필요합니까?, 다른 비슷한 서비스와의 차별성은 무엇인가요?
비전이 있으면 여러가지 결정들을 일관되게 할 수 있고 한 방향으로 나아갈 수 있습니
다. 뭔가 혼란스러운 상황이 발생하면 스스로에게 물어보세요. "이 것이 우리의 비전과
일치하는가?"
비전은 간결해야 합니다. 핵심적인 생각을 전달할 수 있는 한 개의 문장이면 됩니다.
다음은 37Signals 각 서비스의 비전들입니다.
• Basecamp: 프로젝트 관리는 의사소통이다.
• Backpack: 생활의 앞뒤를 맞추자. Bring life's loose ends together
• Campfire: 글러먹은 메신저 대신 할 그룹 채팅
• Ta-da List: 포스트잇과 경쟁하자
• Writeboard: MS 워드는 너무 복잡해
Basecamp 의 비전은 "프로젝트 관리는 의사소통이다"입니다. 효과적인 의사소통은
프로젝트에 소속된 모든 이들의 참여의식과 주인의식을 높여줍니다. 또 모든 사람들이
공통의 목표를 향해 일할 수 있게 해줍니다. Basecamp 가 이런 비전을 잘 만족시킬 수
있다면 다른 모든 것들은 상대가 안될 것입니다.
Basecamp 의 비전은 더 개방적이고 더 투명한 구현결과를 이끌었습니다. 프로젝트를
하는 회사 내로만 의사소통을 제한하는 대신에 고객들도 접근 할 수 있도록 했으면, 접
근 권한보다는 모든 관련자들이 적극적으로 참여할 수 있게 하는 데 더 주안 점을 두었
습니다. 챠트나 테이블, 보고서, 통계자료 같은 기능을 제공하지 않고 메세지, 코멘트,
to 리스트, 파일 공유 등의 기능에 더 집중한 것도 그 때문입니다. 비전을 정하는 것은
큰 결정이지만 일단 비전을 정하고 나면 그 뒤의 세부적인 결정들은 훨씬 쉬워집니다.
화이트보드의 철학
앤디헌트와 나는 한 때 현금 카드 거래 시스템을 개발했습니다. 주요 요구사항은 사용
자 계좌에서 동일한 건에 대해 출금이 두 번 발생하는 일을 방지하는 것이었습니다. 차
라리 처리가 되지 않는 한이 있더라도 똑 같은 처리가 두번 발생하는 일은 절대 없어야
했습니다.
그래서 우리는 그것을 화이트보드에 큰 글자로 써두었습니다. "사용자에게 에러가 나
는 것이 차라리 더 낫다."
26

27. 그 외에도 대여섯개의 원칙들을 함께 정했고, 이렇게 정해진 원칙들은 다른 결정하기
까다로운 세부사항들을 쉽게 결정할 수 있게 해주었습니다. 또 이 원칙들은 내부적으
로 응집력이 있고 외부적으로는 일관성이 있는 어플리케이션을 만들 수 있도록 도와주
었습니다.
—Dave Thomas, The Pragmatic Programmers
슬로건을 만드세요.
조직에는 슬로건이 필요합니다. 구성원들이 매일 잠에서 깨어나서 일하러 갈 때 마음
속에 기억하고 있어야할 바로 그 것말입니다. 슬로건은 간결하고 분명해야 합니다. 슬
로건은 서너 단어로 정도가 적당합니다. 우리의 존재 이유는 무엇인가? 우리의 동기는
무엇인가? 에 대한 답을 해줄 수 있는 것이 바로 슬로건입니다.
—Guy Kawasaki, 저자 (from Make Mantra)
초기에는 시시콜콜한 것들은 무시하세
요.
큰 것에서부터 작은 것으로 진행하세요.
우리는 세부사항에 집착하는 경향이 있습니다.
• 화면 요소간의 공간
• The perfect type leading
• 완벽한 색이 사용
• 완벽한 문구
• 7 줄 대신 4 줄로 구현하기
• 89% 대 90%
• 750 픽셀 대 760 픽셀
• 한달에 39 달러와 49 달러
성공과 만족은 세세한 것에 있습니다.
27

28. 세세한 것에 성공의 요인이 있다고들 말합니다. 틀린말은 아닙니다. 하지만 그 것이 다
가 아닙니다. 의견 불일치, 회의, 지연 이런 것들도 모두 세세하고 시시콜콜한 것들에
집착할 때 생기는 것들입니다. 이 런 것들은 팀의 분위기를 죽이며 성공의 가능성을 줄
입니다.
단 하나의 코드 조각이나 한 부분의 디자인 때문에 하루 온 종일을 소비하는 경우가 얼
마나 됩니까? 하루동안 열심히 일했지만 실제로 별로 진행된 것이 없다는 것을 깨닫는
경우가 얼마나 자주 있습니까? 이런일은 너무 이른 시점에 세부적인 내용에 집착할 때
생깁니다. 완벽주의자를 위해 준비된 시간은 충분히 있습니다. 그냥 나중에 하면 됩니
다.
개발 첫 주에 헤더의 폰트 크기에 대해서 걱정하지 마세요. 둘 째 주에 맘에 딱 드는 녹
색을 찾으려고 하지 마세요. 세 째 주에 'Submit'버튼을 3 픽셀정도 오른쪽으로 옮기는
일 같은 것은 의미가 없습니다. 페이지에 있는 내용들을 그대로 두고 그냥 사용하면서
잘 동작하는 지만 확인하세요. 모든 것이 명확해지고 나서 조정하고 더 완벽햐?만드세
요.
시시콜콜한 세부사항들은 그것을 사용해보고 상세한 개발을 진행해봐야 비로소 분명
해집니다. 어떤 부분에 더 관심을 가져야할 지도 알 수 있습니다. 어떤 부분이 누락되
었고, 어떤 부분을 보완해야할 지는 실제로 사용해봐야만 알 수 있습니다. 그런 순간이
왔을 때 작업하면 됩니다. 너무 빨리는 하지 마세요.
시시콜콜 악마
나는 일단 클래스들을 몇 개 그려보고 나면 "당장 세부사항들을 파보고 싶은" 마음에
사로잡힌다. 하지만 즉시 세부사항들을 그리기 시작한다면 곧 점점 망쳐지고 있다는
것을 알게될 것이다. 이런 방식을 완전히 잘못된 것이다.
그림을 그릴 때는 먼저 전체적인 구도의 비율을 맞추는 것부터 시작해야한다. 그리고
나서 큰 물체들부터 먼저 그리고, 다음에 더 작은 것들을 그려야 한다. 스케치는 너무
상세해서는 안된다. 사물의 생명감을 살리기 위해 그림자를 넣을 때도 처음에는 단 3
개의 톤(밝음, 중간, 어두움)만으로 표현한다. 그리고 각 물체에 그려진 색체를 체적으
로 평가하고 조정한다. 이 과정을 계속 반복한다.
Always. 항상 큰 것에서 작은 것으로
—Patrick Lafleur, Creation Objet Inc. (from Signal vs. Noise)
28

29. 문제가 발생해야 문제
아직 발생하지도 않은 문제를 위해 시간을 낭비하지
마세요.
사용자 10 만명을 처리할 수 있는 확장성에 대해서 오늘 고민할 필요가 있을까요? 사
용자 10 만이 될 때까지 족히 2 년은 걸릴 텐데 말이죠.
지금 세 명이면 충분한데 굳이 여덟명의 프로그래머를 채용해야 할까요?
앞으로 일 년 동안 두 대만 있어도 충분한데 최신 서버를 당장 12 대나 사야 할까요?
그냥 지금 나는데 필요한 날개를 달아주세요.
사람들은 자주 그들이 아직 당면하지도 않은 문제를 해결하는데 너무 많은 시간을 보
냅니다. 37Signals 는 Basecamp 서비스를 시작할 때 사용자에 대한 과금 기능을 만들
지도 않았습니다. 왜냐하면 Basecamp 는 매 월 요금을 받는 방식이므로 서비스 개시
후에도 30 일의 추가 시간이 있었기 때문입니다. 서비스를 개시한 후에 그들은 과금 기
닯?개발하기 시작했고 결국 아무 문제도 없었습니다. 이런 식으로 그들은 우선 가장
중요한 기능들을 개발하는데 전력을 투구할 수 있었습니다.
실제로 문제를 만나기도 전에 미리 땀빼지 마세요. 기능을 오버스펙으로 개발하지도
마세요. 필요가 생길 때 하드웨어든 소프트웨어를 추가하세요. 한 두 주 늦는다고 해서
세상이 끝나는 것도 아닙니다. 다만 솔직하면 됩니다. 고객들에게 기능 추가나 확장에
대해서 약간의 문제를 겪고 있다고 말하세요. 고객들이 그 것에 대해 기뻐할 리 없지만
여러분의 솔직함에 대해서는 고마워할 것입니다.
결정들을 제 때에 하는 것이 중요합니다. 제 때란 여러분이 결정을 내리기 위한 실질적
인 정보를 가지고 있을 때를 말합니다. 그런 정보들이 생기기 전에는 단지 즉각적인 작
업이 필요한 여러가지 다른 일들을 하고 있으면 됩니다.
맞춤 고객
29

30. 어플리케이션에 딱 맞는 핵심 고객 층을 찾고 그들
에게 집중하세요.
고객이 항상 옳은 것은 아닙니다. 여러분이 누가 옳고 누가 틀렸는 지를 결정해야 합니
다. 좋은 소식은 인터넷에서는 딱 맞는 사람들을 찾기가 더 쉽다는 것입니다.
모두를 기쁘게 하려고 하면 아무도 만족하지 못하게
됩니다.
Basecamp 를 개발할 때, 37Signals 는 주 고객을 디자인 회사로 정했습니다. 이런 식
으로 슬쳄揚?한정함으로써 더 열정적인 고객들을 더 많이 찾을 수 있게 되었습니다.
어떤 고객들은 자발적인 전도사가 되기도 했습니다. 여러분이 만들려고 하는 어플리케
이션이 정말 어떤 사람들을 위한 것인지를 알아야합니다.
지금까지 한 일 중 최고 잘했던 일
Campaign Monitor 에서 웹디자인 시장을 겨냥하기로 한 우리의 결정은 최고의 결정
중에 하나였습니다. 그 결정에 의해서 어떤 기능들이 정말 유용한 것인 지 쉽게 알 수
있게되었고, 그것보다 더 중요한 것은 필요하지 않은 기능들을 버릴 수 있었던 것이었
습니다. 특정 분야로 고객을 한정함으로서 오히려 더 많은 고객을 모을 수 있었고고객
들이 대부분 비슷한 요구사항들을 가지고 있었으므로 개발도 오히려 더 쉬워졌습니다.
Campaign Monitor 에는 웹디자이너가 아닌 사람들에게는 아마도 불필요할 수많은 기
능들이 있습니다.
핵심 고객층에 집중하는 것은 또한 우리가 개발한 소프트웨어에 대한 소문을 퍼뜨리는
데도 더 도움이 됩니다. 우리는 좁게 정의된 고객층을 가지고 있기 때문에 그들이 더
자주 방문하는 온라인 사이트에 광고하고 글을 올릴 수도 있으며, 제품에 대한 커뮤니
티를 형성하기도 더 쉽습니다.
—David Greiner, 창립자, Campaign Monitor
확장은 나중에
30

31. 아직 확장에 대한 문제는 없습니다.
"우리 서비스에 100 만명이 접속해도 확장성에 문제가 없을까?"
하지만 실제 문제가 발생할 때까지 기다리세요. 여러분의 시스템에 과부하를 줄 만큼
엄청난 사람들이 접속한다면 그것은 사실 '만세'를 부를 일입니다. 진실을 말하자만 정
말 대부분의 웹 어플리케이션들은 결코 그 단계에 이르지 못합니다. 그리고 정말 과부
하가 발생한다고 하더라도 그것이 당장 죽고사는 문제는 아닙니다. 여러분은 문제 파
악하고 해결할 시간이 있습니다. 게다가 그 때즘 뙤면 여러분은 실제 데이터들에 대한
경험과 벤치마크 결과를 알고 있을 것이므로 이런 정보들을 이용해서 문제를 더 잘 해
결할 수 있습니다.
예를 들어 Basecamp 는 첫 일년동안은 한 대의 서버에서 동작했습니다. 매우 간단한
설정으로 시작했으므로 모든 것을 준비하는데 일주일이면 충분했습니다. 처음부터 15
개의 클러스터 서벌 시작하거나 확장성을 위해서 몇달을 낭비하는 그런일은 하지 않았
습니다.
과연 문제가 하나도 없었을까요? 몇 개는 있었습니다. 하지만 처음에 우려했던 대부분
의 문제들은 실제로는 거의 문제가 되지 않는 다는 것을 알겠되었습니다. 발생한 상황
에 대해서 솔직히 고객에게 말하고 계속해서 개선을 하는 한 고객들은 크게 문제삼지
않습니다. 되돌아보면 완벽한 준비를 위해서 서비스 시기를 늦추지 않은 것은 정멜잘
한 결정이었습니다.
처음에는 핵심 기능을 튼튼하게 만드는 것을 첫번째 우선순위에 올리세요. 확장성이나
서버 군을 구성하는 사로잡히는 것은 좋지 않습니다. 먼저 멋진 서비스 어플리케이
션을 만들고, 크게 성공했을 때의 문제들은 그 때가서 하세요. 그렇지 않으면 여
러분의 에너지와 시간과 돈을 결코 일어나지 않을 일에 낭비하게 될 지 모릅니다.
여러분이 믿는 말든간에 진짜 중요한 문제는 확장성이 아닙니다. 더 중요한 문제는 확
장성이 필요한 시점에 어떻게 도날하는가 하는 것입니다. 그 시점에 도달하지 못한다
면 확장성이 문제가 될 리가 없습니다.
어차피 수정과 개선이 필요합니다.
사실 모두가 확장성의 문제를 가지고 있습니다. 그 어떤 서비스라도 몇 백만의 사용자
처리가 가능해지려면 처음의 모든 디자인과 구조들을 재검토하고 수정해야합니다.
—Dare Obasanjo, Microsoft (from Scaling Up and Startups)
31

32. 방향성을 가진 소프트웨어
어플리케이션은 어느 한쪽 방향을 선택해야 합니다.
어떤 이들은 소프트웨어는 특정 의견에 편협하게 만들어서는 안된다고 합니다. 그들은
개발자들이 기능들을 제한하거나 어떤 기능 요구들을 무시하는 것은 거만한 자세라고
말합니다. 그들의 소프트웨어는 항상 최대한으로 유연하고 일반적으로 만들어야 한다
고 주장합니다.
우리는 그런 의견은 정말 개떡 같다고 생각합니다. 최고의 소프트웨어는 비젼을 가지
고 있습니다. 최고의 소프트웨어는 한 방향을 선택합니다. 누군가 소프트웨어를 사용
할 때 그들은 기능들 보다는 접근 방식을 더 많이 봅니다. 비젼을 봅니다. 여러분의 비
젼이 무엇인지 정하세요. 그리고 그것에 따라 진행하세요.
기억하세요. 어떤 사용자들이 여러분의 비전을 좋아하지 하더라도, 세상에는 정말 다
양한 비전들이 있다는 것을요. 사람들을 무작정 쫓아간다면 결고 행복한 결과를 만들
수 없습니다.
이 점에 대한 최고의 사례는 최초의 위키 디자인에 대한 것입니다. 워드 커닝햄과 친구
들은 예전에는 공동 문서작업을 위해 필요하다고 여겨지던 많은 기능들을 그들의 위키
에서는 과감히 잘라 버렸습니다. 문서가 변경될 때마다 하나의 속성으로 변경을 한 사
용자를 지정하면서, 대신 소유권과 관련된 가시적은 표시 기능들은 대부분 제거했니
다. 그들은 콘텐트에 대해 개인의 존재감을 없애고, 콘텐트가 시간에 구애받지 않도록
만들었습니다. 그들은 누가 그 내용을 썼고 언제 그것이 변경되었는 지가 중요하지
안?]고 생각했습니다. 그리고 이런 결정들은 정말 커다란 차이를 만들었습니다. 커뮤
니티에 공유의 마인드를 구축하였으며 그것이 바로 위키페디아 성공의 핵심 요소가 었
습니다.
37Signals 의 어플리케이션들도 이와 같은 방식을 따랐습니다. 모든 사람을 만족시키
려고 하는 대신, 각 어플리케이션의 고유의 방식을 가지려고 했습니다. 그리고 어플리
케이션의 동반자가 되어줄 고객 부류를 찾아서 그들과 비전을 공유하였습니다. 여러분
도 우리와 같은 버스에 동승하는 것은 어떻습니까?
32

33. 기능 고르기 chapter 5
제대로 된 절반
반은 엉망인 제품을 만들지 말고 반만 만들어도 제
대로 만드세요.
"물빠지는 구멍이 없는 것만 빼고는 완벽한 부엌"과 같은 상황을 조심하세요. 좋은 아
이디어라고 해서 모두다 추가하려다보면 결국 어느 하나 제대로 동작하는 것이 없는
상태가 되고 맙니다. 중요한 것은 일부분이라도 핵심적인 부분을 확실히 동작하도록
만드는 것입니다.
진짜 핵심인 부분에 집중하세요. 좋은 아이디어들을 종이에 나열해서 적으세요. 서비
스에 필요하다고 생각되는 것들을 모두 적은 다음에 그 중 절반을 골라서 버리
세요. 정말 핵심적이라고 생각되는 기능들만 남겨놓고 나머지를 버리세요. 이 과정을
반복하세요.
Basecamp 에서 37Signals 는 메세지 기능만으로 시작했습니다. 그 기능이 핵심이라는
것을 알았기 때문에 처음에는 마일스톤이나 todo 리스트 같은 다른 기능들은 무시했습
니다. 그리고 그 이후의 결정들은 실제 사람들이 사용하는 방식을 보고 정했습니다. 개
발자들의 초기 직관과 추측에 의존해서 모든 것을 결정하는 것은 좋지않습니다.
가볍고 영리한 어플리케이션으로 시작해서 사용자들의 관심을 끄십시오. 그리고 나서
그 기반위에 기능들을 추가해나가면 됩니다.
중요한 문제가 아닙니다.
핵심적인 것만
"왜 이렇게 하지 않았죠?" 또는 "왜 이렇게 했죠?"와 같은 질문에 대해 우리가 가장 선
호하는 답변은 "왜냐하면 그건 별로 중요하지 않기 때문입니다" 라고 말하는 것입니다.
33

34. 이 문장은 제품을 위대하게 만들어주는 정신을 표현하고 있습니다. 정말 중요한 것을
찾아내고 나머지는 내버려두세요.
37Signals 에서 Campfile 서비스를 개시했을 때 사람들로부터 다음과 같은 질문들을
받았습니다.
"왜 타임스탬프가 5 분마다인가요? 왜 각 줄마다 타임스탬프를 찍지않나요?" 대답: 그
것은 별로 중요하지 않습니다. 초단위나 분단위로 대화내용을 추적해야하는 경우가 얼
마나 있습니까? 95%의 경우는 그렇지 않을 겁니다. 그러니 5 분은 충분합니다.
"왜 볼드체나 이탤릭체 또는 문자에 색을 지정하는 것이 안됩니까?" 대답: 그 것은 중
요한 문제가 아닙니다. 만약 강조하고 싶은 부분이 있으면 대문자를 사용하거나 *를 사
용하면 됩니다. 이런 방법은 추가로 소프트웨어가 필요하지도 않고 기술지원도 필요없
으며 따로 배우지 않아도 됩니다. 게다가 문자로 주고받는 간단한 대화에서 무거운 포
맷팅 기능은 전혀 필>요없습니다.
"왜 현재 방안에 있는 사람의 수를 보여주지 않나요?" 대답: 중요하지 않습니다. 모든
사람의 이름의 리스트가 나오므로 누가 있는 지 쉽게 알 수 있습니다. 12 명이든 16 명
이든 무슨 차이가 있습니다. 그것으로 인해서 사용자의 사용 동작에 차이가 없다면 전
혀 중요하지 않습니다.
이런 기능들을 제공하면 좋을까요? 물론 좋을 겁니다. 하지만 그 것들이 핵심적인 기
능들인가요? 정말 중요한가요? 절대 그렇지 않습니다. 그래서 37Signals 는 이 기능들
을 제공하지 않았습니다. 최고의 디자이너와 최고의 프로그래머는 최고의 기술을 가진
사람도 아니며 가장 재빠른 사람들도 아니고 포토샵이나 개발환경을 멋지게 다루는 사
람들도 아닙니다. 정말 필요하지 않은 것이 무엇인지를 아는 사람들이야 말로 최고라
고 할 수 있습니다. 차별성은 바로 이런 부분에서 나옵니다.
여러분은 대부분의 시간을 별로 중요하지 않은 일에 소모합니다. 만약 여러분이 중요
하지 않을 일에 대해 생각하거나 작업하는 것을 줄일 수 있다면 상상도 못할 생산성을
얻게 될 것입니다.
일단 'NO'라고 말하세요.
기능들이 쉽게 구현되지 못하도록 하세요.
34

35. 어느 것 하나도 제대로 동작하지 않는 엉터리를 만들지 않고 일부라도 제대로 동작하
는 제품을 만드는 비결은 '아니오'라고 말하는 것입니다.
어떤 기능에 대해서 '예'라고 말할 때마다 마치 아이 하나를 입양하는 것과 같습니다.
이 아이는 그 모든 일련의 보살핌이 필요합니다.(디자인, 구현, 테스트 등) 그리고 일단
기능을 정하게되면 그것에 집착하게 됩니다. 고객이 멀리하는 기능을 하나 찾아서 왜
그렇게 되었는 지 알아보세요.
예스맨이 되지마세요.
매 기능의 구현 여부를 쉽게 결정하지 마세요. 기능이 정말 존재할 필요가 있는 지를
기능 스스로 증명하도록 하십시오. 마치 "Fighting Club"처럼 문간에서 들여보내줄 때
까지 3 일은 버티는 그런 기능들만을 고려해야합니다.
이것이 바로 우리가 "아니오"로 시작하는 이유입니다. 모든 새 기능에 대한 요청은 외
부에서 온 것이든 내부에서 온 것이는 먼저 "아니오"를 만납니다. 우리는 요청에 경청
하지만 즉시 행동하지는 않습니다. 첫번째 반응은 "지금은 아닙니다" 입니다. 만약 하
나의 기능에 대한 요청이 다시 들어오면 우리는 좀 더 깊이 살펴볼 때라고 여기게 되며
실제로 고려하기 시작합니다.
그리고 자신의 기능 추가 요청을 받아들이지 않는다고 불평하는 사용자들에게 뭐라고
말하는 것이 좋을까요? 그들에게 그들이 왜 처음 그 서비스를 좋아하게 되었는 지를
상기시키세요. "당신이 우리 서비스를 좋아하는 이유는 우리가 '아니오'라고 말하기 때
문입니다. 우리의 서비스가 100 가지나 되는 기능들을 가지고 있지 않기 때문입니다.
우리의 서비스가 모든 사람을 항상 만족시키려고 하지 않기 때문입니다. "
"천 개의 기능은 필요하지 않습니다."
스티브잡스가 아아튠즈에 대해서 독립음반회사 사람들을 모아놓고 조그만 발표를 했
습니다. 그 날 많은 사람들은 쉴 새없이 손을 들면서 어떤 기능이 제공되는 지, 혹은 어
떤 기능을 추가할 계획이 있는 지 물었습니다. 마침내 쟙스가 말했습니다. "잠깐만요.
손을 잠시 내리고 제 말을 들어보시죠. 저는 여러분이 아이튠즈에 있으면 좋을 만한 아
이디어를 수 천개 가지고 있다는 것을 잘압니다. 하지만 우리는 수 천개의 기능을 원하
지 않습니다. 그렇게 하면 엉망이 될 겁니다. 혁신은 모든 것에 대해서 '예'라고 말하는
것이 아닙니다. 혁신은 정말 중요한 것을 제외한 나머지에 대해서는 '아니오'라고 말하
는 것입니다."
35

36. —-Derek Sivers, 대표 및 프로그래머, CD Baby and HostBaby
(from Say NO by default)
숨은 비용
새 기능을 위한 비용을 밝히세요.
어떤 기능이 '아니오' 단계를 통과했다고 하더라도 여러분은 그 기능에 대한 숨은 비용
을 찾아야 합니다.
예를 들어, 기능의 연쇄(어떠 기능을 위해서 다른 기능이 계속 추가로 필요해 지는 것)
가 생기지 않을 지 살펴보십시오. 37Signals 는 Basecamp 에서 회의를 위한 탭을 추가
해달라는 요청을 받았습니다. 그것은 자세히 살펴보기 전까지는 비교적 간단한 것으로
생각되었습니다. 그런데 회의 기능을 구현하기 위해서는 다음과 같은 개념들이 추가로
필요했습니다. 위치, 시간, 회의실, 참가자, 이메일 초대, 달력 연동, 회의록 작성 등. 물
론 홍보 페이지를 변경하고 소개용 맛보기 페이지와 FAQ/도움말, 서비스 계약 등을 바
꿔야 하는 것은 말할 필요도 없습니다. 이처럼 우리가 알지 못하는 사이에 아주 작은
아이디어 하나가 눈덩이처럼 커져서 두통거리가 되어버립니다.
new 모든 새로운 기능에 대해서 다음과 같이 하세요.
• 1. '아니오'라고 말합니다.
• 2. 그 기능이 스스로의 가치를 증명하도록 합니다.
• 3. 만약 다시 '아니오'이면 끝, 만약 '예'이면 계속
• 4. 화면을 스케치합니다.
• 5. 화면을 디자인합니다.
• 6. 코드를 짭니다.
• 7-15. 테스트하고 고치고, 테스트하고 고치고, 테스트하고 고치고...
• 16. 도움말의 내용이 수정되어야 한다면 그렇게 합니다.
• 17. 필요하면, 서비스 둘러보기를 업데이트합니다.
• 18. 필요하면, 홍보 문구를 업데이트 합니다.
• 19. 필요하면, 서비스 계약 문구를 업데이트합니다.
• 20. 기존에 계약 조건에 대한 위반이 없는 지 살핍니다.
• 21. 가격 정책에 영향이 없는 지 살핍니다.
• 22. 실제 서비스에 적용합니다.
• 23. 이제 한 숨 돌립니다.
36

37. 관리가 가능한가요?
관리할 수 있는 것을 개발하세요.
만약에 여러분이 어떤 가입형 서비스를 시작한다면 계정관리과 지불을 처리할 수 있는
시스템을 가지고 있어야 합니다. 여러분은 회원의 요금이 지불 수단으로 매달 직접 현
금이나 수표를 송금하는 방식이 아니라 신용카드를 이용한 결제 수단이 필요할 겁니
다.
여러분은 구글과 똑같이 무료로 1 기가의 공간을 제공할 수 있습니까? 아마 여러분은
100 메가정도부터 작게 시작해야 하거나 유료 계정에 대해서만 공간을 제공할 수 있을
지도 모릅니다.
여러분의 여건에 맞고 관리가 가능한 제품을 만들고 서비스를 제공하세요. 약속을 하
는것은 쉽습니다. 하지만 그것을 지키는 것은 훨씬 더 어렵습니다. 어떤 일이든 시작하
기 전에 그것이 조직적 전략적 기능적으로 잘 관리될 수 있는 일인 지를 미리 확인 하
십시오.
사람의 해결책
소프트웨어를 범용적으로 만들어서 사람들이 그 들
만의 방식으로 사용할 수 있도록 하세요.
사람들에게 규칙을 강요하지 마세요. 대신 소프트웨어를 범용적으로 만들어서 모든 사
람들이 자신만의 방식으로 사용할 수 있도록 하세요. 사람들이 자신들의 문제를 자신
만의 방식으로 해결 할 수 있는 방법을 창조적으로 찾아낼 수 있도록 하는 겁니다.
Ta-da List 를 개발할 때, 37Signals 는 의도적으로 많은 기능을 빼고 개발했습니다. 할
일 항목에 대해서 사람을 지정하는 기능도 없었고 완료일을 지정하는 방법도 없었습니
다. 아이템들을 분류하는 방법도 없었습니다.
37

38. 이렇게 함으로써 사람들은 더 창조적이 되었고 소프트웨어는 깔끔하고 정돈된 상태를
유지할 수 있었습니다. 사람들은 스스로 문제를 해결하는 방법을 찾았습니다. 완료일
을 지정하고 싶으며 내용 에 '기한: 2006 년 4 월 7 일)' 이라고 추가했고, 분류를 지정하
고 싶으면 단지 '[책]' 이라고 썼습니다. 이상적인 구현인가요? 물론 아닙니다. 욉瞿?構?
유연한가요? 그렇습니다.
만약 37Signals 가 이런 기능들을 위해서 특별한 방식으로 구현된 기능을 제공했다면
그것은 사람들이 원하는 다양한 경우를 모두 만족시킬 수 없었을 것입니다.
문제의 핵심 부분에 대해서는 최선을 다해서 최고의 기능을 제공하세요. 그리고는 한
발 벗어나세요. 사람들이 여러분이 제공한 틀 내에서 그들 자신의 해결책과 규칙을 만
들어 사용할 수 있도록 하세요.
기능 추가 요구는 잊어버리세요.
중요한 것이라면 사용자들이 반복해서 상기시켜줍
니다.
사용자들은 이 세상의 모든 것들을 원합니다. 사용자의 기능 추가 요청은 마치 눈사태
처럼 쏟아져 들어올겁니다. 37Signals 의 서비스 게시판을 보세요. 다른 게시판에 비해
서 기능 요청 게시판의 글들이 월등히 더 많습니다.
아마도 이런 말들을 듣게 될 것입니다. "이 작은 추가 기능", "결코 어렵지 않은", "간단
히 추가 가능한", "몇 초면 구현할 수 있는", "최소의 구현으로 최대의 효과를"
물론 기능을 요구하는 사용자들을 탓할 수는 없습니다. 오히려 그들이 더 많이 말하고
요구하도록 격려하는 것이 옳습니다. 우리가 추가하는 대부분의 기능들은 사용자의 요
청에서부터 시작됩니다. 하지만 앞에서도 말했듯이 그러한 요청에 대한 우리의 첫번째
반은은 '아니오'이어야 합니다. 그렇다면 이렇게 쏟아지는 수많은 요청들을 어뜬뺐?처
리해야 할까요? 어떻게 정리해야할까요? 정리하지 마세요. 그냥 한 번 읽어보고
잊어버리세요.
그렇습니다. 읽고, 던저버린 후 잊어버리세요. 좀 불경스럽게 들릴 수 도 있지만 중요
한 내용이라면 결국 계속해서 나타날 것입니다. 그런 것들이 바로 우리가 기억하고 관
심을 가져야할 중요한 것들입니다.
38

39. 어째서 이런 결론에 도달했냐구요? 우리가 처음 Basecamp 를 시작했을 때, 우리는 모
든 주요한 기능 요구사항들을 Basecamp 의 todo 리스트에 관리했습니다. 어떤 요청이
반복되면 우리는 별표르 ㄹ하나 추가해서 표시했습니다. 그러다가 나중에 적당한 시점
에 리스트에서 가장 요청이 많은 항목들을 구현할 생각이었습니다.
하지만 사실은 우리는 그 리스트를 한 번도 다시 보지 않았습니다. 우리는 다음에 해야
할일을 그냥 알 수 있었습니다. 왜냐하면 사용자들이 그 기능을 계속해서 반복적으로
요청했기 때문입니다. 리스트 같은 것을 만들고 분석할 필요는 전혀 없었습니다. 누군
가 매일 매일 같은 내용을 얘기해 주면 그것을 잊을 수 없는 것이 당연합니다.
또 한가지 사실은, 단 지 몇 명 이상의 사람들이 그 기능을 요청했다고 해서 반드시 그
것을 추가해야한다는 것은 아닙니다. 가끔은 '아니오'라고 말하고 기존의 비젼과 방향
성을 유지하는 것이 더 낫습니다.
Hold the Mayo
사용자들이 원하지 않는 것을 물어보세요.
대부분의 소프트웨어 설문이나 조사를 위한 질문들은 사람들이 무엇을 원하는 지에 대
한 것입니디ㅏ. "추가되었으면 좋겠다고 생각하는 기능은 무엇입니까?", "만약 당신이
딱 하나의 기능을 추가할 수 있다면 그 것은 무엇입니까?", "이 제품을 더욱 유용하게
만들어줄 기능은 무엇일까요?"
하지만 동전의 뒷면을 보세요. 왜 사용자들이 원하지 않는 기능에 대해서는 묻지 않습
니까? "만약 당신아 딱 하나의 기능을 제거할 수 있다면 무엇을 제거하겠습니까?" "어
떤 기능을 전혀 사용하지 않습니까?" "도움이 되지 않고 귀챦기만 한 기능은 무엇인가
요?"
"더 많이"는 절대 답이 아닙니다. 가끔은 어떤 기능을 빼버리는 것이 고객에게 큰 도움
을 주는 일이 될 수 있습니다.
혁신은 '아니오' 에서 시작된다.
[혁신]은 1000 가지 일에 대해서 '아니오'라고 말하므로써 잘못된 길을 가거나 불필요
하게 너무 많은 일을 하지 않도록 하는 것에서 시작됩니다. 우리는 항상 새롭게 진입가
39

40. 능한 시장에 대해서 고민합니다. 하지만 그것은 과감히 '아니오'라고 말하므로써 실질
적으로 중요한 일들에 대해서만 집중할 수 있을 때 가능합니다.
—Steve Jobs, CEO, Apple (from The Seed of Apple's Innovation)
프로세스 6 장
실행가능한 소프트웨어를 향해서
실제로 실행이 가능한 것을 빨리 만드십시오.
동작하는 소프트웨어는 모멘텀을 만들 수 있는 최상의 방법이며, 팀의 활력을 불어넣
고 나쁜 아이디어를 폐기할 수 있는 기회를 줍니다. 따라서 동작하는 소프트웨어를 만
드는 것을 개발 첫째날부터의 최고 우선순위에 두어야 합니다.
동작하는 소프트웨어를 더 빨리 만들어내기 위해서라면, 일부 상세내용을 생략하거나
프로세스의 어떤 과정을 축소해도 됩니다. 동작하는 소프트웨어를 만들었을 때의 보답
은 앞으로 어떻게 진행해야 할 지에 대해 훨씬 더 정확한 관점을 얻을 수 있다는 것입
니다. 사용자 스토리, 와이어 프레임, 그리고 html 로만 구현한 페이지들은 단지 추측에
불과합니다. 동작하는 소프트웨어만이 실제입니다.
실제 동작하는 소프트웨어가 있으면 모든 사람이 더욱 실제와 진실에 가까운 이해와
합의에 도달할 수 있습니다. 결국에는 소용없는 것으로 밝혀질 화면 스케치와 문서 내
용에 대한 과열된 논쟁도 피할 수 있습니다. 원래 사소하다>고 생각했던 부분들이 실
제로는 매우 중요하다는 사실을 깨달을 수도 있습니다.
실제 구현이 실제의 반응으로 이어지며 그것이 진실을 알 수 있는 방법입니다.
합의에 이르게 하는 실제 구현
사람들이 그들의 의견을 조화시키리면 실제가 어떨 지에 대해서 정확한 이해가 필요합
니다. 만약 그들이 스케치와 의견 도출을 하고 있는 단계라면 합의에 이르기는 힘들 것
입니다. 그러나 그들이 실제 구현을 하고 있다면 합의에 도달하기가 더 쉽게 됩니다.
40

41. —크리스토퍼 알렉산더, 아키텍쳐 교수
(Contrasting Concepts of Harmony in Architecture 아키텍쳐에서 조화의 상충하는 개
념들에서)
최대한 빨리 동작가능하게 만드십시오.
나의 경험에 의하면 프로젝트의 규모가 크기에 상관없이, 실제 구현을 병행하지 않은
채 오랫동안 계획 기간을 가진 프로젝트가 스케쥴이나 비용, 기능의 측면에서 성공한
적이 없었습니다. 결국에는 불필요한 것으로 판명되거나 구현이 불가능할 기능을 고안
하거나 개발하기 위해서 시간을 낭비하기가 매우 쉽습니다.
이것은 모든 수준의 개발에 해당하며, "실제로 동작하는 구현을 한다"는 진리입니다.
이것은 프로젝트의 전반에 걸쳐서만 적용되는 것이 아닙니다. 이 것은 더 작게 나누어
진 컴포넌트들의 개발에도 적용됩니다.
주요 모듈의 동작하는 구현이 있다면, 개발자들은 자신들이 개발한 부분과 함께 잘 동
작하는 지 알기 위해서 가능한 그 구현을 빨리 사용해보려고 할 것입니다. 나아가서 만
약 그 구현 결과가 처음에 불완전 하다고 하더라도 이러한 빠른 개발자간 협업을 통해
서 잘 정의된 인터페이스를 만들 수 있게 될 것이며 , 결국 그들이 원했던 대로 기능들
을 구현할 수 있게 해줄 것입니다.
—매트 해머, 개발자 겸 프로덕트 매니저 Kinja
개선과 반복
반복 작업
한 번에 모든 것이 잘되기를 기대하는 것은 무리입니다. 어플리케이션이 점점 커지면
서 개발자에게 직접 말하게 하세요. 스스로 변화하고 발전하게 하십시오. 웹 기반 소프
트웨어에서는 완전한 상태로 출시할 필요는 없습니다. 화면을 디자인하고 사용하고 분
석하십시오. 그리고 다시 반복하십시오.
미리 모든 것을 결정해버리는 것 대신, 반복개발 프로세스에서는 정보에 의한 결정을
하면서 진행해 나갈 수 있습니다. 또 실제 동작 가능한 어플케이션을 더 빨리 얻게 될
것이며, 그 결과로 실제 사용자들로부터의 피드백과 어디에 더 집중해야 할 지에 대한
가이드를 얻을 수 있습니다.
41

42. 반복이 자유에 이르게 합니다.
어차피 계속 반복하게 될 것을 안다면, 한 번에 완전하게 하려고 하지 않을 것입니다.
어떤 문제를 나중에 다시 다루게 될 것을 안다는 것은 아이디어를 끄집어 내서 실제로
동작하는 지를 알게해주는 강한 동기로 작용합니다.
아마 여러분이 저 보다 더 똑똑할 것입니다.
아마 여러분이 저 보다 훨씬 더 똑똑할 것입니다.
그럴 가능성이 매우 높습니다. 하지만 여러분은 보거나 느끼거나 만질 수 없는 것을 잘
상상하지 못한 다는 점에서 다른 대부분의 사람과 같을 것이며 저 역시 그렇습니다.
사람은 주어진 환경에 대해서는 매우 잘 반응할 수 있습니다. 우리는 호랑이가 방으로
들어왔을 때 어떻게 공포에 질릴 지 알고 있습니다. 그리고 홍수가 쓸고간 뒤에 황페해
진 공간을 깨끗이 치울 수도 있습니다. 하지만 불행히도 우리는 미리 계획을 세우는 능
력은 매우 약합니다. 또 우리의 행동에 의한 결과를 예측하거나 정말로 중요한 일들의
우선순위를 가리는 것에도 그리 능하지 못합니다.
아마도 여러분은 이 모든 것을 다 잘할 수 있는 극소수 중의 한 명일 수도 있습니다. 하
지만 그것은 그렇게 중요하지 않습니다.
웹 2.0 은 (우리는 모든 사람이 웹을 사용하고 있다고 가정하고 있습니다.) 영리한 개발
자이 사람들이 가진 것들을 사람들 자신을 위해서 다시 사용되도록 만든 것입니다. 그
방법은, 여러분의 사용자들이 여러분에게 뭔가 할 만한 일이 있는 것들에 대해서 그들
이 생각하는 것을 말하게 하는 것이었습니다.
위의 마지막 문장은 여러분이 왜 우리가 제시하는 방식으로 개발해야하며, 어떻게 홍
보하고 서비스를 시작해야할 지를 설명해줍니다.
여러분의 의도를 분명히 하고, 잘 작동하게 만드십시오. 그리고 나서 서비스를 개시하
고 개선해 나가십시오. 다른 사람들이 여러분 보다 더 똑똑하다고 생각하지 마십시오
—세스 고딘, 저자/기업가
아이디어에서 구현까지
42

43. 브레인스토밍에서 HTML 으로 그리고 코딩으로
우리는 다음과 같은 순서로 'Getting Real'을 실천합니다.
브레인스토밍
아이디어를 가지고 어떤 제품을 만들 지를 정합니다. Basecamp 의 예를 들면, 먼저
37Signal 의 내부의 요구사항을 살펴보았습니다. 그 요구사항들은 다음과 같은 것들입
니다. 프로젝트의 새로운 사항들에 대한 업데이트가 가능해야하며, 고객들이 직접 참
여할 수 있어야 합니다. 또 프로젝트에는 마일스톤이 필요합니다. 참여자들이 지나간
것들에 대해서 쉽게 다시 살펴볼수 있는 하나의 저장소가 필요합니다. 높이 떠있는 새
의 눈으로 보는 것 처럼 프로젝트 전반에 대한 큰 그림을 살필 수 있어야 합니다. 이러
한 내용들을 모아서 밑그림을 그렸습니다.
이 단계는 시시콜콜한 세부사항들에 대한 단계가 아닙니다. 이것은 좀 더 큰 질문을 하
는 단계입니다. 이 어플리케이션은 무엇을 하기 위한 것인가? 그것이 유용하다는 것을
어떻게 알 수 있는가? 우리가 만들고자 하는 것이 정확히 무엇인가? 이것은 비교적 높
은 단계의 생각에 대한 것이며, 픽셀 수준의 토의를 위한 것이 아닙니다. 이 단계에서
아주 세부적인 사항들은 사실 의미가 없습니다.
종이 스케치
스케치는 빠르고 정확하지 않으며 비용이 거의 들지 않습니다. 여러분은 처음에 스케
치로 시작해야합니다. 이것저것 아무렇게나 그려보세요. 박스와 원들과 선들을 그리세
요. 머리속에 들어있는 생각들을 꺼내서 종이에 표현하세요. 이 단계의 목표는 머리속
의 개념들을 대강의 인터페이스 디자인으로 바꾸는 것입니다. 이 것은 일종의 실험의
단계로 정확한 결과를 만들려는 것은 아닙니다.
HTML 페이지 만들기
기능들에 대해서 html 페이지들을 만드세요. 사람들이 화면에서 실제로 보고 느낄 수
있도록 하세요.
Basecamp 의 경우에는 가장 중요한 기능인 "메시지 등록" 화면을 제일 먼저 만들었습
니다. 그리고 "메시지 편집"기능을 만들었습니다.
43

44. 하지만 아직 동작을 위한 코딩은 하지마세요. 단지 html 과 css 로 겉모양만 만드세요.
구현은 나중에 할 일입니다.
코드 작성
html 로 만든 겉모양이 마음에 들고 필요한 기능들이 충분하다고 판단이 되면, 실제 동
작을 위한 코딩을 시작하세요.
이러한 과정에서 항상 유연한 자세를 유지해야 하며, 여러번 반복이 될 수 있다는 것을
기억하세요. 어떤 단계에서라도 하고 있던 내용을 던져버리고 처음부터 다시 시작할
수 있습니다. 전체 단계를 여러번 반복하는 것은 자연스럽고 당연한 일입니다.
사용자 설정을 피하세요
중요하지 않은 세부사항의 동작 방식은 사용자가 직
접 결정을 하지 않아도 되도록 한 가지로 정해야 합
니다.
우리가 자주 만나는 어려운 문제는 "하나의 페이지에 얼마나 많은 메시지나 의미를 담
을 것인가?" 이며, 처음 이런 문제를 만났을 때, 아마 이렇게 생각할겁니다. "사용자가
설정할 수 있도록 하자. 25 나 50 아니면 100 으로 설정할 수 있도록." 이런 식의 접근
이 더 쉬울 지 모르지만, 바람직한 것은 그 중 어느 한 가지로 정하는 것입니다.
사용자 설정을 추가하는 것은 어려운 결정을 회피하
는 것입니다.
전문성을 사용해서 가장 좋은 방식을 정하는 대신, 우리는 고객에게 그것을 미루고 있
습니다. 이런 방식이 사용자에게 친절을 베푸는 것으로 보일 수도 있습니다. 그러나 사
실은 그들을 성가시게 만드는것입니다.(고객은 그렇지 않아도 충분히 바쁩니다.) 사용
자 입장에서는, 끝 없는 선택 사항들로 가득찬 사용자 설정 화면은 두통거리이지 결코
44