- 린스타트업의 사고방식은 실패를 전제로 함. 즉 이런 방식으로 반드시 성공한다가 아닌 실패를 전제로 우선 사용자가 사용하도록 해서 거기서 발생하는 실패를 통해 어떻게 빨리 낭비없이 성공에 도달하는 가를 정리한 것.
- 가치가설 : 왜 제품이 가치가 있는가에 대한 질문데 대한 가설
- 가치가설 시트 사례
* 사용자 : 요리법을 찾는 사용자는
* 욕구 : 오늘의 메뉴를 빨리 결정하고 싶지만,
* 과제 : 많은 요리법 중에서 결정할 수 없기 때문에,
* 제품의 특징 : 인기 요리법을 찾을 수 있는 검색기능이 가치 있다.
- 성장가설 : 왜 제품 사용자가 증가하는가라는 질문에 대한 가설
* 지출형 성장엔진 : 광고와 같이 돈을 사용해서 사용자를 확보한다
* 바이럴형 성장엔진 : 댓글이나 다른 사용자의 리뷰 등에 영향을 받아 이용을 시작한다
* 밀착형 성장엔진 : 이용을 시작한 사용자가 계속해서 돈을 지불하고 사용한다
- 성장가설 시트 사례
* 사용자 : 요리법을 찾는 사용자는
* 동기 : 매일 요리법 선택에 드는 시간을 단축함으로써,
* 수요발생 : 인기순 검색을 계속 사용하게 된다
- 클라우드는 가격이 비싸다는 선입견을 가질 수 있음. AWS EC2라면 EC2 인스턴스와 동일한 사양의 하드웨어를 자체적으로 구입하는 편이 적게 들지 모른다. 하지만 EC2 인스턴스는 만들거나 버리는 작업이 간단해서 작업시간을 줄여줌. 결과적으로 자체적으로 설치하는 것보다 비용면에서 효과적임
- 왜 AWS인가?
* 클라우드 중에서 가장 오래돼서 신뢰할 수 있음.
* 전 세계를 대상으로 서비스를 제공하고 있어서 낮은 대기시간(latenct)으로 서비스 제공
* Availinility zone를 통해 존 안에서도 충분한 이중화 기능 확보
* API로 모든 조작 가능
* S3(simple storage service)라는 신뢰성 높은 저장소를 제공
- 캐시에 대한 생각. 시간이 걸리는 응답은 캐시에 넣어두는 것이 손쉬운 해결책. 우리가 사용하고 있는 대표적인 캐시구성이 페이지 캐시임. 페이지캐시는 응답 HTML을 통째로 저장해 두는 방법. 이것은 Varnish를 사용해서 구현하고 있음. 페이지 캐시가 매칭되면 백엔드에 있는 애플리케이션 서버까지 요청이 가지 않기 때문에 응답을 고속화하면서 애플리케이션 서버의 부하를 줄일 수 있음. 캐시는 고속화에 매우 효과적인 방법이지만, 양날의 검이기도 함. 예를 들어 운영상 캐시를 삭제하지 않으면 안될 경우가 있음. 하지만 대규모 캐시의 삭제는 백엔드 서버에 높은 부하를 줌. 그 외에 프로그램 버그로 캐시하지 말아야 할 것을 캐시해버려서 사고가 발생하는 경우도 있음. 예를 들어 상용서버에서만 캐시를 사용하도록 코딩되어 있어서 테스트에서 발견하지 못하는 경우도 있음. 또한 대부분의 사용자가 캐시를 통해 응답을 빠르게 받는다 해도, 캐시를 놓친 일부 사용자는 응답을 늦게 받는 경우도 있음. 캐시를 도입한 시스템에서는 이런 사소한 사용자 체험을 놓치는 경우가 있음. 쿡패드에서는 다양한 캐시를 사용하고 있지만 이런 이유들 때문에 캐시는 마지막 수단이라는 것을 마음에 새기고 있다. 캐시 없이 모든 응답을 빠르게 전달할 수 있는 것이 최선책이다.
- AARRR : 스타트업에서 중요한 고객활동 지표
* Acquisition
* Activation
* Retention
* Referral
* Revenue
- API화의 이점 : API화된 시스템은 서로 다른 시스템을 연동해도 어느 한 시스템이 다른 시스템에 영향을 주지 않음. 예를 들어, API화되지 않은 시스템에서는 일부에 고부하가 걸리면 전체에 영향을 끼침. 이에 반해 API화된 시스템에서는 부하가 높은 부분을 일시적으로 중지시키거나 개별기능단위 전용서버를 증설해서 대응 가능. 자신의 서버가 다운돼도 다른 시스템에 영향을 주지 않고 시스템 분리가 용이한 연계장식을 isolation이라 함.
- 애자일 개발방식
* 프로세스나 툴보다 사람간의 상호작용을 중시한다. 개발자간, 개발자와 기획자간 커뮤니케이션도 중요함
* 포괄적인 문서보다는 동작하는 소프트웨어를 중시한다. 문서는 커뮤니케이션에 문제가 없을 정도의 최소한의 것만 위키로 정리하고, 동작하는 소프트웨어와 소스를 문서도 대체한다. 처음부터 상세한 부분까지 모두 결정한 후에 만드는 것이 아니라 개발해가면서 그리고 서비스해가면서 사용자와의 커뮤니케이션을 통해 더 좋은 서비스를 모색한다.
* 계획상의 협상보다 고객과의 협력을 중시한다.
* 계획을 따르기보다 변화에 대응하는 것을 중시한다. 처음 서비스하는 것이 많기 때문에 개발일정을 정밀하게 확정하는 것 자체가 어렵다. 하지만 가능한 한 짧은 단위로 출시함으로써 시장이나 고객의 변화에 대응한다.
- 일반적으로 스케일아웃이란 서버대수를 늘려 시스템 성능을 향상시키는 방법. 그에 반해 스테일업이란 성능이 더 좋은 CPU, 대용량 메모리, 고속 디스트를 탑재하거나 또는 서버 자체를 성능 좋은 서버로 교체함으로써 처리능력을 향상시키는 것.
'IT' 카테고리의 다른 글
| 비즈니스를 위한 데이터 과학 (0) | 2014.11.13 |
|---|---|
| 시장의 신화 1 - 시장의 탄생 (0) | 2014.11.11 |
| 나는 앱으로 백만장자가 되었다 (0) | 2014.10.22 |
| 스마트패드 생존전략 (0) | 2014.10.22 |
| 플랫폼을 말하다 (0) | 2014.10.19 |
