1.
인터넷 서비스 사업의 개요
2015.12.31
김수보, 대디하우스

2.
인터넷 서비스
- 2 -
핫플레이스 건설 계획 설계 / 건설 / 시공
초기 상가 분양/임대
모객 성공
모객 실패
• 상가 임대료 Up
• 상인회로 질서 유지
• 광고 유치 등
• 상가 임대료 Down
• 입점 상인 감소
축제
거리
리뉴얼
바가지요금
금지
상인회 활동
사람이 많이 모이는 핫플레이스를 만들고 상인을 모집한다는 점에서 상가건설과 비슷

3.
서비스 아이템 정하기
- 3 -
오픈빨
정비례
증가형
급격한
증가형
한계
증가형
반짝
증가형
오픈빨
이후
서비스가 활성화되지 않는 경우
서서히 잊혀져감
모객 이벤트의 반복으로만 서비스가 존속
가치 있는 데이터가 남지 않음
필수 생활형 서비스
굳이 노력하지 않아도 일정 수준 유지
오래 지속되는 경향이 있음
유지비용이 높으면 서비스가 망함
자가 전파형 서비스 모델
자기 증식형 서비스 모델
노력하지 않아도 계속 증가
자기 증식형 서비스 모델
노력에 따라 증가 기울기가 상승
돈이 아니라 <서비스 자체 매력>에 의한 사용자의 증가 패턴이 예측되어야 함

4.
고객 모집
고객이탈
사용자
판매
업자
서비스
제공자
돈
상품
환경
수수료, 광고
서비스,
놀이터계속
이용
돈을 쓰는 모객
- 매체 마케팅
- 할인권 등
돈을 쓰지 않는 모객
- 입소문
- 추천인
• 서비스 효용가치 부족
- 제일 심각한 신호
• 나쁜 경험의 축적
- 두번째 심각한 신호
• 서비스제공자에 대한 불만
- 사과와 보상을 통해 해결
모객영역 서비스 영역
• 가치 있는 데이터
- 고객 성향 정보
• 2차 부산물로 가공
- 상권분석 정보 등
• 제휴사 협업
- 회원 광고, 메일
이탈 영역
• 저절로 굴러가게 하기
- 이용, 피드백, 품질 3박자
- 운영자의 적절한 개입
- 지속적인 이슈 메이킹
• 지속적인 자극
- 새로운 기능의 출시
- 불편한 기능의 개선
서비스 모델 만들기
4
서비스 영역에서 <사용자>, <판매업자>, <서비스제공자>의 액션 시나리오 그리기

5.
사업 모델 만들기
5
서비스 지속성, 경쟁현황, 고객확보 전략, 고정비, 변동비 등을 예측함

6.
서비스 기획
- 6 -
세부적인 화면과 기능을 확정하고 개발할 <제품>과 개발 후 해야 할 <활동>들을 기획함
서비스 컨셉 수립 서비스 Flow 수립
서비스 기능 확정
• MVP 도출 및 규제 확인
- 핵심 기능 우선 구현
- 이용자 약관, 이메일/SMS 인증
• MVP 후 추가 배포 계획
- 사용자 피드백에 따라 계획 변경
- 주기적/정기적 기능 배포
- 배포를 통해 이용 활성화 자극
• 시장진입 전략과 UI/UX 정의
- 서비스와 브랜드 정체성
- 사용자의 가입장벽을 낮춤

7.
개발 기획
- 7 -
변경에 빠르게 대응할 수 있는 <어플리케이션 구조>와 확보해야 할 <데이터>를 기획함
기능과 화면의 구현 계획 수립 적재하고 활용할 데이터 적재 계획 수립
• ORM, Class Diagram, ERD는 과정
• 결과는 사업에 활용할 데이터
• 이 과정이 없으면 데이터가 안맞는다.
• 또는 원하는 데이터가 안 쌓인다.
• 기구축된 사회적 기술 인프라 활용 검토
- 서버 임대 : Cloud
- 플랫폼 임대 : Parse.com
- 인증 임대 : Social Login
• 어플리케이션 구조 설계 및 구현
- 기능 변경 및 확장에 유연한 형태로 구조 설계
- 재활용 가능한 기능은 공통화(추후 플랫폼으로 제공)

8.
운영개발 구조의 정의
- 8 -
※ 번역글 : http://bit.ly/instatechhist
※ 원 문 : http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances
인스타그램 런칭 후 1년 만에 가입자 1,400 만명, 서버 수백 대, 개발자 3명
- 심플하게 유지한다. (=기능의 추가 및 변경, 관리가 용이한 구조로 만든다.)
- 바퀴를 재발명 하지 않는다. (=가능한 인프라를 활용한다.)
- 가능한 명확하고 증명된 방법을 이용한다. (=최신기술의 시행착오를 줄인다.)
DNS DNS
WAS WAS WAS
DB #1 DB #2 DB #3
WAS
1번유저 2번유저 3번유저
nginx 를 이용하여 Round Robin으로 호분배
 현재는 Amazon의 ELB를 사용
 DNS는 Amazon의 Router53 사용
 SSL과 ELB레벨 종료 (성능향상)
High-CPU Extra Large 25대
- 7GB Memory
- 20 Unit
- Django
Quadruple Extra Large 12대
- PostgreSQL
- Horizontal Sharding
Image Server Amazon S3
Cache Server Amazon CloudFront
Search PostgreSQL  Apache Solr
- Geo Search에서 Media Search로 확장
Feed Redis
Cache Memcached  Elastic Cache
Push
Open Source twisted
- Pyapns
- 200개 worker
Monitoring Munin, Pingdom, PagerDuty, Sentry
- 100대 이상의 서버관리
Scale Out
Scale Out

9.
개발과 시스템 비용의 투자
- 9 -
☞ 사용자의 증가(2010~2013) ☞ 사진 업로드량의 증가 (2010~2012)
☞ 서비스 회사의 투자와 기대수익의 패턴

10.
기술구조의 변화에 따른 투자비용의 증가
- 10 -
단말 어플
서비스로직
인프라 임대
단말 어플
서비스로직
임대 인프라
상용 데이터
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 구축
단말 어플
서비스로직
임대 인프라
상용 데이터
인프라 서비스
인프라 구축
파일럿
서비스오픈
수익화
플랫폼화
프로젝트 팀 서비스 사용자 제휴 사업자 연계 서비스
• 아이디어를 시스템화
하는 단계
• 유즈케이스 정리
• 데이터항목 정리
• 사용자 패턴에 적합
한 기술구조로 구축
• 실전 데이터 축적
• 클라우드 인프라
• 제휴사업 기능 개발
• 수익화 로직 추가
• 제휴사업용 데이터가공
• 3rd Party 기능 개발
• 수수료 기반 유통플랫폼
개발

11.
실리콘밸리 스타일 - 인스타그램
- 11 -
•HTML5로 연습삼아 만들어봄
•친구들에게 줘 봄
•파티를 통해 엔젤투자가를 만남
•재평가를 통해 MVP를 도출함
•프로토타입을 만듬
•그 이후에야 제대로 만듬
•여러 번 버린 이후에야 성공
•앱을 출시

12.
실리콘밸리 스타일 - 핀터레스트
- 12 -
• 아이디어만으로 동업자를 만남
• 앱을 만들어 보았으나 실패
• 아이디어를 바꿈
• 3번째 동업자를 만남
• 투자를 거절당함
• 팀이 해체됨
• 50개의 다른 버전을 만듬
• 4개월 후 200명 가입
• 7,000명에게 편지를 씀
• 엄마들이 사용하기 시작함
• 3년만에 2,500만명 가입

13.
성장과 위협
- 13 -
런칭시기 성장기 수익화 성장 지속기
서비스
관점
• 알리는 시기
• 반응을 보면서 업데이트
• 사용자의 지속적인 유입
• 판매자 진입 시도
• 지속성장 또는 유지
• 수익형 트랜잭션의 적절
한 개입
• 급격한 성장
• 가입자 정체
• 사용율은 증가
사업관점 • 수익상품 기획 • 상품판매 • 상품판매/수익화
• 지속적인 상품개발/판매
• 가두리 모델/공유 모델
• 플랫폼의 판매
• 제휴의 확산
기술관점 • 트러블 슈팅 중심 운영
• 데이터 정합성 확보
• 대량 트래픽 수용
• 운영개발 (DevOps)
• 선행개발
• 수익형 플랫폼 개발
• 서버 구조가 급격히 복잡
• 어플 구조가 교묘해짐
• 레거시의 증가
• 신규 기능의 지속적 배포
• 전략적 기술 운용
재무관점 • 홍보비, 마케팅비 중심 • 개발비, 시스템 비용증가
• 개발인력의 증가
• 시스템 구매 비용
• 영업인력의 증가
•
조직관리 • 영업과 서비스, 개발 조직
의 분리
• 논공행상의 문제 발생