기본 콘텐츠로 건너뛰기

누구를 위하여 종을 울리나

제목이 조금 거창하지만...

스타트업에게 이야기 할 때 많이 하는 얘기가 있습니다.
요즘은 IT서비스를 플랫폼화 하여 성장하는 기업이 주류 입니다.

플랫폼은 다수의 공급자와 다수의 수요자를 연결하는데 의미가 있습니다.

거기서 많은 시행착오를 일으키기도 하는데요..

선택의 기로에 설 때가 많습니다.
선택이란 양쪽이 좋은 것 보다 선택 받지 못한 다른 한 쪽이 손해 또는 이득이 적어지는 경우가 대부분 입니다.

이 경우 가장 중요한 것은

누가 나에게 이득을 주느냐

입니다.
설계한 서비스를 이용함으로서 한쪽은 재화를 지불 하고 다른 한 쪽은 재화를 얻는 경우가 대부분 일 것입니다.
재화를 지불하는 곳이 재화에 상응하는 편리함을 제공하지 않는다면 
이용자가 줄어들어 아무리 많은 공급자를 가지고 있다 하더라도
서비스는 지속되기 어렵습니다.

이걸 가장 잘 알았던 기업이 애플이었죠.

아무리 개발자가 불평이 많아도 
이용자가 서비스 이용이 편리하여 돈을 써주기 때문에
구글의 플레이 스토어 보다도 
애플의 앱스토에 충실 고객이 늘어납니다.

사이먼씨의 이야기를 빌리자면
마틴 루터 킹 같은 종교 지도자나 애플의 유저를 끌어들이는 정책은 일치하고
돈을 지불하는 것에 안심감 및 프라이드 마저 느낄 수 있도록 해주었기 때문에
일방적으로 개발자에 불친절한 앱 관리 시스템에
개발자는 애플을 욕하면서도 앱스토어 출시를 하게 되는 것이지요.

인재파견 및 소개 회사도 마찬가지 입니다.
다수의 수요자는 기업이고, 다수의 공급자는 취업 희망 개인입니다.
물론 양쪽을 편하게 해주면 좋겠지만,
경제 구조상 수익률을 위해 동일 시간에 최대한 노력을 해야하기 때문에
한 쪽은 신경을 덜 쓰게 됩니다.

이 경우 취업 희망자에게 아무리 신경을 쓴다 하더라도 
기업이 불편하면 안쓰게 됩니다.
그럼 돈을 지불할 기업이 사라지니 결국 이 플랫폼은 돈이 돌지 않아 망하게 될 겁니다.

그렇다고 구직자를 대충 대하라는 것이 아닙니다,
최대한의 서비스를 하되,
시간이 부족하다면,
보다 기업의 채용 담당자의 채용까지 걸리는 노력을 줄여줄 수 있도록
플랫폼에서 서비스를 제공해야 하는게 아닐까 싶습니다.

아마존 역시 무사무시한 서비스 강국의 일본에서 
야후와 라쿠탠을 제치고 1위 쇼핑몰이 되었습니다.
묻지마 환불 전략으로
유저가 어떤 이유에서든 환불을 요구하면 들어줍니다.
그러니 조금 더 비싸도 안심하고 아마존을 이용합니다.
그 결과 비쌈에도 불구하고 
그 많은 글로벌 쇼핑몰이 포기했던 일본 시장 1위를 차지했지요.

스타트업 대표이든 
어느 조직에 속해있든

매출을 위한 노력을 할 때
제한 시간과 리소스 분배에 고민할 때에는 
이걸 생각하기를 바랍니다 

누구를 위하여 종을 울리나.




giip :: Free mixed RPA orchestration tool! 

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...