Bandwidth(인터넷 속도) vs. latency(지연속도)

Bandwidth(인터넷 속도)란 무엇인가?

밴드와이드가 너 높을수록(더 넓은수록) 더 좋다. 하지만 이게 정확히 의미하는게 뭘까? 많은 사람들은 밴드와이드를 인터넷 스피드를 나타내는 단어로만 생각한다. 이건 정확한 표현이 아니다. 밴드와이드는 얼마나 많은 데이터가 특정한 시간에 하나의 노드에서 다른 노드로 전송될 수 있는지에 대한 측정 단위다. 밴드와이드는 다운로드와 업로드가 존재한다.
　
우리가 인터넷 연결에 관해 이야기 할 때, 그건 얼마나 많은 양의 데이터가 서버로부터 당신의 디바이스에 다운로드 될 수 있는지에 대한 측정치가 된다. 예를 들어, 다운로드 속도가 50Mbps(Mega Bits Per Second)라면, 초당 서버에서 다운로드 할 수 있는 데이터의 양이 초당 50메가 라는 의미이다. 보통 당신의 실제 밴드와이드는 최대 밴드와이드보다 작을 것이다. 왜냐하면 인터넷 혼잡이나 그외 외부적인 요인 때문이다.

latency(지연속도)란 무엇인가?

지연속도가 낮으면 낮을 수록 좋다. 지연속도는 최종 서버에서 돌아는데까지 걸리는 시간을 의미한다. 이것을 테스트하기 위해서, 당신의 컴퓨터는 외부서버에 핑을 보내고, 시그널이 송신된후 착신될 때가지의 걸린 시간을 측정한다.
　
지연속도는 낮으면 낮을수록 좋은데, 이는 당신이 액션을 취하고 부터(클릭을 하든, 스크린을 내리든) 결과를 보기까지의 시간이 짧다는 의미이기 때문이다.
　
당신이 인터넷 연결에 요청을 날릴때마다, 그것은 서버에 신호를 보내게 되고 그 신호에 따라 서버로부터 레스폰스를 받아온다. 이것은 매우 짧은 간격으로 이루어지게 되며, 지연속도는 ms단위로 측정되게 된다.

latency(지연속도)에 영향을 미치는 요소들

1. 전파 지연(propagation delay)

   • i) 보내는 측에서부터 받는 측까지 메시지가 전달되는 데 필요한 시간의 양. 따라서 거리의 영향을 받는다.
   • ii) 전파 속도(propagation speed)는 빛의 속도(약 3*10^8 m/s). 하지만 구리선 또는 광섬유(fiber-optic) 케이블을 통해서 패킷이 전달되므로 실제 속도는 더 느리다. 빛의 속도와 패킷이 전달되는 속도의 비율은 물질의 굴절률(refractive index)로 알려져 있다. 이 굴절률이 커질수록, 빛이 이동하는 속도는 느려진다.
   • iii) 경험상 광섬유 케이블에서 빛의 속도는 약 200,000,000 m/s다. 이 경우 실질적으로 뉴욕과 시드니 사이의 왕복시간(RTT, Round Trip Time)은 200300 msec로 0.20.3초 정도 소요된다.
   • iv) 전파지연 = 거리 / 전파 속도
   • v) 예제: (4,800 * 1,000) / (3 * 10^8) = 0.016 s
     • 빛의 속도를 계산하기 편하게 3*10^8로 가정, 거리 단위는 m

2. 전송 지연(transmission delay)

   • i) 링크로 모든 패킷의 비트를 넣는 데 필요한 시간의 양
   • ii) 전송 속도(transmission rate)는 채널 용량(capacity of channel)이라고도 불린다.
   • iii) 전송 지연 = 패킷의 길이 / 링크의 데이터율(*data rate)
     • 데이터율(Data Rate): 데이터 단위(비트,심볼,패킷 등)가 전송되는 속도(비트율 또는 심볼률 등)를 총칭, bps(초당 비트 수) = bits / seconds.
   • iv) 예제: 1,000,000 / (64 * 1,000) = 15.625 s
   • v) 예제2: 10Mb 파일을 1Mbps와 100Mbps 두 링크를 통해 전송한다고 가정
     • a. 1 Mbps 링크를 통할 경우 전체 파일을 전선에 올리는 데 10초가 걸릴 것이다
     • b. 100 Mbps 링크를 통할 경우 전체 파일을 전선에 올리는 데 0.1초가 걸릴 것이다.

3. 처리 지연(processing delay)

   • i) 패킷의 헤더를 처리, 비트 레벨의 에러 체크, 그리고 패킷의 도착지를 결정하는 데 필요한 시간.
   • ii) 패킷 처리 지연: 라우터 등에서 전체 패킷을 받고 처리 전달하는데 걸리는 지연
   • iii) 패킷 스위칭/

4. 라우팅 지연: 패킷을 스위칭/라우팅하는데 드는 지연

5. 대기 지연(queuing delay)

   • i) 들어오는 패킷이 처리될 때까지 큐에서 대기하는 시간의 양

Bandwidth(인터넷 속도)와 latency(지연속도)의 차이는 무엇인가?

위의 정의에도 불구하고 이해가 쉽지 않다면, 다음의 예로 이해해보자. 네트워크를 강으로 비유할 수 있는데, 강의 폭이 bandwidth라면, 상류에서 하류까지 물이 흘러가는 속도를 latency라고 비유할 수 있다. 강의 폭이 넓고 깊을 수록 일정시간에 흘려보낼 수 있는 물의 양은 더 많다. 또한, 강이 굽이 지거나, 흐름을 방해하는 요소가 없을 수록 하류까지 더 빨리 다다를 수 있을 것이다.

인터넷속도와 지연속도는 당신에게 어떤 영향을 미치는가?

Gaming

대부분의 게임은 매우 빠른 인터넷 속도를 요구하지는 않는다. 따라서 밴드와이드가 게임에 미치는 영향은 미미하다.(동시에 여러사람이 같은 bandwidth로 동시에 접속한 상황이 아니라면). 보통 게임은 당신의 컴퓨터와 콘솔에 인스톨되어 있어서 asset을 로컬에 갖고 있기 때문에, 게임을 하는 동안 서버와 당신의 로컬이 정보를 공유해야하는 상황은 그리 많지 않다. 오직 당신의 로컬 디바이스와 서버의 싱크를 맞추는 데만 인터넷 속도가 영향을 미친다.
　
하지만 지역속도는 실시간 온라인 게임에서는 가장 중요한 요인이다. 높은 지연속도는 게임에서 랙을 유발하고 당신의 캐릭터의 액션과 당신의 클릭 사이에 긴 간격을 유발한다. 쉽게말하면 당신이 총을 발사하기 전에 이미 죽어있을 수도 있다는 것이다. 하지만 당신은 서버에서 신호가 당신의 로컬에 도착할때까지 당신의 캐릭터가 죽어있는지 조차 모를 것이다.

Streaming

스트리밍은 서버에서 컨텐츠를 리얼타임으로 다운로드 받아오기 때문에, bandwitdth는 당신의 스트리밍 영상을 보는데 가장 주요한 영향을 미치는 요인이다. 왜냐하면 스트리밍은 모든걸 다운로드 받은 상태에서 영상을 보여주는 것이 아니라, 최소한만 다운로드 한 상태에서 다운로드를 진행하면서 영상을 플레이 시켜주기 때문이다.
　
낮은 bandwidth는 2가지 방식으로 영향을 미친다. 먼저 끔찍할 정도로 자주 그리고 긴 버퍼링을 요구하거나 낮은 데이터 퀄리티를 야기하게 된다.

Video chat

페이스타임이나 스카이프와 같은 피디오 채팅은 bandwidth와 latency의 영향을 동시에 받는다. 낮은 bandwidth는 비디오 채팅의 퀄리티에 영향을 미치고, 화질을 선명하지 않게 한다. Latency은 싱크 이슈나 영상이 움직이지 않고 멈춰있는 현상을 야기한다.

Browsing

당신의 웹 브라우징 경험은 형편없는 인터넷 연결의 영향에 취약하다. 낮은 bandwidth은 페이지 이동시 매우 느린 이동을 야기시킨다. 그리고 높은 latency는 페이지의 로딩자체에는 영향을 미치지 않겠지만 페이지 이동시 렉을 유발하는 요소다.

참고

• https://www.highspeedinternet.com/resources/bandwidth-vs-latency-what-is-the-difference
• https://blog.daum.net/endlessole/174

UML과 방법론의 차이

UML의 구성을 알아보기에 앞서 먼저 UML과 방법론의 차이를 알아야 한다. 필자는 UML을 공부하는 초기에 UML을 하나의 방법론으로 착각하는 오류를 하였다. 물론 똑똑한 독자는 이러한 오류를 범하지 않으리라 생각하지만 혹시나 하는 마음에 먼저 언급하려고 한다.
　
방법론이란 말그대로 어떠한 작업을 할 때 이러저러한 절차를 가지고 작업을 하면 된다라고 하는 것을 이론적으로 정립을 하여놓은 것이다. 소프트웨어공학에서 많은 방법론이 있어왔고 현재도 수많은 방법론이 존재한다. 사실 프로그램을 하는 모든 사람은 나름대로의 방법론을 가지고 있다. 그러한 나름의 방법론이 작업을 얼마만큼 효과적으로 만드는지에 따라 좋은 방법론인지 아닌지 결정 날 것이다. 　
　
그럼 UML은 무엇인가? UML은 이러한 방법론을 적용할 때의 결과물을 나타내기 위한 도구이다. 예를 들면 모든 소프트웨어를 설계 할 때 어떠한 표준적인 규칙을 가지고 설계도를 그려야한다. 이때 설계의 표준이 되는 것이 UML이다. 건축도면에서 나오는 건물 내부의 여러가지 표준적인 표기라 보면 될 것이다. 즉 각자 다양한 방법론을 자기의 프로젝트에 적용하더라도 UML을 공통적으로 적용할 수 있다.

UML의 구성

이제 UML이 어떻게 구성되어있는지 알아보도록 하겠다. 전체 UML은 8가지 다이어그램으로 나타난다. 시스템의 정적인 면을 나타내는 클래스 다이어그램(Class Diagram)이 있고 동적인 면을 나타내는 콜레버레이션 다이어그램(Collaboration Diagram), 시퀸스 다이어그램(Sequence Diagram), 상태 다이어그램(Statechart Diagram), 액티비티 다이어그램(Activity Diagram), 디플로이먼트 다이어그램(Deployment Diagram), 컴포넌트 다이어그램(Component Diagram)으로 구성되어져 있다.
　
이외로 유스케이스 다이어그램(Usecase Diagram)이 존재한다. 유스케이스 다이어그램을 두 부류로 나누지 않은 이유는 다른 모든 다이어그램을 그리기 위해 기반이 되는 다이어그램이기 때문이다.이제 각 다이어그램이 시스템의 어떠한 면을 반영하는지 간단하게 알아보도록 하자.

(1) 유스케이스 다이어그램 (Usecase Diagram)

유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를들어 보험처리 프로그램의 경우에 "고객이 보험증권에 sign한다.", "보험 판매원이 판매통계량을 종합한다." 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 입장에서 이해할 수 있을 정도로 기술을 하여야 한다. 이러한 유스케이스 다이어그램은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다.

(2) 클래스 다이어그램 (Class Diagram)

클래스 다이어그램의 경우 시스템 내부에 존재하는 클래스들을 선별하여 나타내고 각 클래스들의 속성(Attribute)과 행위(Behavior)를 기입한다. 여기서 클래스들 사이에 여러가지 관계(Relationship)를 가질수 있다. 예를 들어 연관관계(Association)은 클래스와 클래스가 어떠한 연관을 가지고 있음을 나타내고 여기서 세부적으로 복합연관(Composition)과 집합 연관관계 (Aggregation) 등으로 나뉘어 질 수 있다. 이외에 상속관계(Generalization), 의존관계(Dependency)가 나타날 수 있다. 클래스 다이어그램을 그리고자 할 때 항상 추상화 단계를 고려하여서 그리도록 하여야 할 것이다. 추상화의 단계가 높은 경우 대충의 속성과 행위를 기입하고 대충의 관계를 기입하여도 충분할 것이다. 이 단계에서 너무 상세한 내용을 찾고 기입하다 보면 클래스 다이어그램 내부에서 구현의 단계에서 이루어져야 할 일이 이루어지는 오류를 범하게 된다. 이러한 오류는 실제 구현 단계에서 커다란 위험의 요소를 내재하게 된다.

(3) 시퀸스 다이어그램 (Sequence Diagram)

시퀸스 다이어그램은 콜레버레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는 메시지를 나타내게 된다. 콜레버레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램 만의 특징이라면 횡축을 시간축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고있다.

(4) 콜레버레이션 다이어그램 (Collaboration Diagram)

콜레버레이션 다이어그램 또한 시퀸스 다이어그램과 함께 메시지의 흐름을 나타낸다. 하지만 콜레버레이션 다어그램은 객체와 객체들 사이의 관계 또한 표기하게 된다. 실제 UML에서 클래스의 인스턴스인 객체를 표기하는 다이어그램이 명시적으로 존재하지 않는다. 이러한 객체들 사이의 관계를 나타내기 위해 별도로 오브젝트 다이어그램(Object Diagram)을 사용하여도 되지만 오브젝트 다이어그램은 클래스 다이어그램과 크게 차이점이 없는 관계로 UML의 표준에는 포함되어있지 않다. 갑자기 이러한 오브젝트 다이어그램을 여기서 언급하는 이유는 객체들 사이의 관계를 표기하기 위해 클래스 다이어그램과 거의 동일한 오브젝트 다이어그램을 그리기 보다는 특별히 클래스 다이어그램과 차이점이 되는 부분을 여기 콜레버레이션 다이어그램에 기입하는 것이 좋을 것이다.

(5) 상태 다이어그램 (Statechart Diagram)

상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행시 객체의 상태는 메시지를 주고 받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다. 실제 시스템에서 실행시 많은 객체가 생성되고 소멸된다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다. 결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간동안의 상태를 표시하여야 한다.

(6) 액티비티 다이어그램 (Activity Diagram)

액티비티 다이어그램은 플로우챠트가 UML에 접목이 되었다면 가장 이해가 빠를 것이다. 시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다. 이러한 액티비티 다이어그램에서 기존 플로우 챠트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우챠트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다라고 보아도 좋다.

(7) (8) 디플로이먼트 다이어그램 (Deployment Diagram) 과 컴포넌트 다이어그램 (Component Diagram)

이 두 다이어그램은 시스템의 물리적인 부분의 구성을 나타낸다. 디플로이먼트 다이어그램은 실제 하드웨어적인 배치와 연결상태를 나타낸다. 그리고 컴포넌트 다이어그램은 소프트웨어의 물리적 단위(Exe, dll 등 기타 library)의 구성과 연결상태를 나타내게 된다.

출처

• https://sfeg.tistory.com/339 [즐거운]

https://m.blog.naver.com/PostView.nhn?blogId=int9708&logNo=220822786169&proxyReferer=https:%2F%2Fwww.google.com%2F
https://subokim.wordpress.com/2013/01/31/platform-story/

플랫폼이란 무엇인가?

‘플랫폼이 무엇인가’ 하는 질문에 대한 답은 대답하는 사람의 수만큼이나 무수히 많다. 플랫폼과 관련하여 출간된 책도 그 수가 적지 않다. 플랫폼 개념에 대한 다양한 내용과 정의 가운데 노규성 선문대학교 경영학부 교수의 저서 <플랫폼이란 무엇인가> 가운데서 ‘플랫폼’과 ‘비즈니스 생태계와 플랫폼’, 그리고 ‘플랫폼 비즈니스 모델’의 내용을 요약·정리한다.
　
급변하는 시장환경에서 최근 더욱 두각을 나타내고 있는 기업은 애플, 구글, 아마존, 페이스북 등 인터넷 혁명을 주도하는 ‘4인방(Gang of Four)’이다. 구글의 회장 에릭 슈밋은 이들의 성공 비결을 ‘자기만의 강력한 플랫폼’이라고 했다. 10년 전의 4인방은 마이크로 소프트(MS), 인텔, 시스코, 델이었지만, 플랫폼 경쟁에서 뒤진 바람에 플랫폼을 효과적으로 활용하고 있는 신4인방에게 자리를 내주고 고전을 면치 못하고 있다. 이처럼 플랫폼이 기업 성패의 핵심요인으로 등장하면서 플랫폼에 대한 관심이 고조되고 있다.

플랫폼의 구성하는 요건

아래의 논문에서 플랫폼을 구성하는 요건을 제시하고 있다. 플랫폼을 규정하는 가장 명확한 정의라고 생각한다.

첫째 상호연결을 필요로 하는 둘 이상의 구분되는 고객 , 군(two distinct group) 이 존재하여야 한다 (양면성). 둘째 한 면의 고객군은 다른 면의 고객군의 규모 가 클수록 더욱 높은 효용을 얻어야 한다 (교차 네트워크 외부성). 셋째 높은 거래비용으로 인하여 서로 다른 고객군들이 자체적인 노력으로 직접 거래하는 것 이 불가능하기 때문에23), 즉 교차 네트워크 외부성을 내부화하는 것이 불가능하기 때문에 플랫폼을 이용하여야 거래가 성립된다 (플랫폼을 통한 외부성의 내부화). 따라서 플랫폼은 거래비용을 최소화하면서 외부성을 해소하는 방안을 제 공하여 주는 실질적 가상적 공간 또는 제도적 장치로 생각할 수 있다.

[클릭] 양면시장(플랫폼)의 정의에 대하여

공급자와 수요자의 상생 생태계

플랫폼하면 기차를 타고 내리는 정거장이 먼저 떠오른다. 그렇다. 플랫폼은 본래 기차를 승하차하는 공간이나 강사, 음악 지휘자, 선수 등이 사용하는 무대 강단 등을 뜻했다. 플랫폼 용어는 16세기에 생성된 이후 일상생활이나 예술, 비즈니스 등의 분야에서 사용해왔다. 그러던 것이 오늘날에는 다양한 분야에 적응 가능한 보편적인 개념으로 확대되어 널리 사용되기에 이르렀다.
　
　
플랫폼의 대표격인 승강장이 어떤 역할을 하는지 살펴보면, 플랫폼의 진정한 의미를 파악할 수 있다. 승강장은 교통수단과 승객이 만나고 연결하는 공간으로, 사람이 많이 몰리는 이곳에서 다양한 형태의 비즈니스 모델로 부가적인 수익 창출을 할 수가 있다. 주요 수익모델인 승차요금 외에도 광고 등 부가적인 비즈니스 모델로 상당한 수익을 창출하고 있는 것이다. 그래서 승강장은 교통수단과 승객이 만날 수 있는 거점 역할을 하며, 교통과 물류의 중심이 되고, 거래가 발생하게 된다. 이것이 바로 플랫폼이다.
　
　
정리하면, 플랫폼이란 공급자와 수요자 등 복수그룹이 참여해 각 그룹이 얻고자 하는 가치를 공정한 거래를 통해 교환할 수 있도록 구축된 환경이다. 플랫폼 참여자들의 연결과 상호작용을 통해 모두에게 새로운 가치와 혜택을 제공해 줄 수 있는 상생의 생태계라고 말할 수 있다. 애플이 기존의 휴대폰 시장의 강자들을 물리치고 스마트폰 시장에서 새로운 강자로 부상할 수 있었던 것은 훌륭한 플랫폼을 기반으로 한 비즈니스 생태계를 구축했기 때문이다.

기능과 참여자에 따라 달라지는 경제적 가치

플랫폼의 가치는 기업의 비즈니스 구조나 시스템에서 차지하는 비중과 비례한다. 만약 플랫폼이 전체 시스템에서 필수적으로 요구되는 기능들을 최대한 많이 포함하고 있다면, 그 가치는 상당할 것이다. 플랫폼은 세 가지 측면에서 기업에 가치를 제공한다.
　
　
첫째는 플랫폼이 어떤 기능을 수행하느냐 하는 것이다. 플랫폼이 핵심 비즈니스를 수행한다면 그 가치는 대단히 크겠지만, 고객 서비스를 위한 플랫폼으로 기능한다면 상대적으로 그 가치는 적을 것이다. 둘째, 플랫폼의 반복적 사용과 공유에 따라 경제적 가치가 발생한다. 플랫폼을 반복적으로 사용할수록 비용절감의 효과를 갖게 해준다. 특히 각 참여자들이 플랫폼을 공유하면 비용이 대폭 절감된다. 셋째, 플랫폼은 네트워크 효과도 제공하여, 교류나 거래를 촉진한다. 즉, 수요자와 공급자, 개발자와 사용자, 프로슈머 등 참여자가 많아지면 많아질수록 네트워크 효과가 발생하고, 이로 인한 가치가 극대화한다.

서비스와 수익 모델의 결합 필요

비즈니스 모델이란 사업을 영위하고 이익을 창출하는 방식, 즉 어떤 상품을 어떤 방식으로 누구에게 판매할 것인가를 설계해보는 것이고, 플랫폼 비즈니스 모델이란 플랫폼 서비스의 모델을 통해 수익을 내는 모델을 의미한다. 서비스 모델에는 서비스의 제공방법, 서비스 모델 프레임워크 등이 포함되며, 수익 모델에는 수익을 창출하는 방법과 수익 모델 프레임워크가 필요하다. 결국 서비스 모델과 수익 모델의 결합을 통해서만 비즈니스 모델이 될 수 있다.
　
　
플랫폼 비즈니스 모델의 특징은 다음과 같다. 첫째, 충분한 규모의 구매자나 판매자를 확보하는 것으로, 플랫폼은 규모의 경제를 실현하기 좋은 창구이다. 에어비엔비와 같은 좋은 플랫폼이 있어도, 그 플랫폼에 참가하는 공급자와 수요자가 없다면 플랫폼은 의미가 없다. 신규 플렛폼이 구매자와 판매자를 확보하기 위해 사업초기에 파격적인 프로모션을 진행하는 것도 그러한 이유이다. 둘째, 해당 플랫폼만의 차별적인 가치가 창출되어 고객에게 제공된다. 셋째, 다수의 사람들이 모인 네트워크를 혁신에 활용한다. 애플의 개방된 플랫폼이 그렇고, 최근에는 트위터나 페이스북에 관심을 갖는 것도 이 때문이다.
　
　
비즈니스를 수행하는 플랫폼이 내포해야 할 요소와 특징으로는 첫째, 플랫폼 주도기업은 설계, 운영, 업그레이드를 담당하고, 둘째 모방이 어려운 해당 플랫폼의 차별화 기반 기술을 가지고 있어야 한다. 셋째, 플랫폼 주도 기업과 참여자, 또는 참여자 간 공동의 이익이 존재해야 한다. 넷째, 비즈니스 플랫폼은 참여자의 기반확대와 업그레이드, 인접분야 확장 등 지속적으로 진화되어야 한다.

플랫폼 비즈니스의 구분

• 하드웨어 플랫폼
  하드웨어에도 “플랫폼”이 있습니다. “Platform Technology” 위키피디아에선 이렇게 설명하고 있습니다. “제품개발을 가능하게 하는 기술이나, 현재 또는 미래의 개발을 지원하는 프로세스”
  　
  제조업은 하드웨어를 대량생산.판매함으로써 돈을 법니다. 그래서 “공산품화”가 중요하죠. 동일품질의 제품을 안정적으로 만듭니다. “프로세스Process”와 “자동화Automation”가 필수죠. 작업공의 기분에 따라 품질이 변하지 않게 해줍니다. 그러면 품질이 일정해지고, 원가가 안정되죠.
  　
  하드웨어에선 이런 “프로세스”와 “물리적 장치”가 “플랫폼”입니다. “현대 소나타와 기아 K5가 플랫폼을 공유한다.” 이런 이야기를 들어보셨을 겁니다. 엔진, 조향장치가 똑같다는 뜻입니다. 여기엔 품질검수기준 및 부품규격 같은 것도 포함이 됩니다. 이게 함께 있어야 플랫폼 운영과 복제가 가능하기 때문입니다. 그게 가능해야 공장을 늘릴 수 있거든요.
  　 　
  즉 하드웨어에서 플랫폼이란, 표준공정을 통해 다양한 제품을 만들어내는 기반과 도구를 지칭합니다.
  　 　
  “소프트웨어”는 어떨까? “소프트웨어”도 하드웨어처럼 “공정”이 중요한 때가 있었습니다. 컴퓨터 안에 설치해서 팔았거든요. 그래서 소프트웨어도 그 PC 제품의 일부분이었습니다.
  　 　
  이 때의 소프트웨어는 하드웨어 부품 중의 하나였습니다. 그래서 프로세스와 제작공정이 중요했죠. 초창기 SI 업체들은 소프트웨어 제작공정을 “플랫폼”으로 만들고 싶어했습니다. 공정화된 품질경영을 앞세웠죠. 훌륭한 제품을 반복생산할 수 있음을 증명하려했습니다. 그 증명서가 “ISO 9001” 인증입니다. 건설업 같은 곳에서 쓰는 국제인증서죠. 암튼, 당시엔 이런 “소프트웨어 생산공정”도 “플랫폼”이라고 불렀습니다. 　
• 소프트웨어 플랫폼
  하드웨어에 관계없이 소프트웨어가 단독역할을 하게되자, 소프트웨어에도 “플랫폼”이라는 개념이 본격적으로 만들어집니다.
  　 　
  수십년 전에는 컴퓨터 종류마다 소프트웨어를 다르게 만들어야 했습니다. CPU와 OS등 실행환경이 달랐기 때문이었습니다. Java와 웹브라우저가 나오면서 이 문제가 극복됩니다. 하드웨어가 아닌 Java, 웹브라우저 위에서 프로그램이 작동하도록 만들어집니다. 그래서 윈도우(OS), 브라우저, 자바 등을 “플랫폼”으로 부르기 시작합니다. 다양한 기능들이 세트로 모여있는 무엇이었거든요.
  　 　
  특정분야에 한정된 실행환경도 새로운 “플랫폼”으로 불려집니다. MAME는 옛날 오락실 게임을 PC에서 실행시켜주는 실행환경용 프로그램입니다.
  처음에 10개 정도일때는 그냥 게임기로 불리었는데, 게임숫자가 40~50개를 넘어가자 게임플랫폼이라고 불리게 됩니다. 일부러 MAME용으로 게임을 만드는 개발회사가 생겼거든요.
  　 　
  “개발플랫폼”이라는 개념도 등장합니다. 개발하기 쉽게 여러가지 환경을 제공해주는 것을 말합니다. 개발플랫폼에는 코딩을 쉽게 해주는 라이브러리들과 코딩을 도와주는 여러가지 도구들이 있습니다.
  　 　
  이렇게 소프트웨어에선 “여러가지 기능을 제공해주는 공통 실행환경”을 플랫폼이라고도 말하게도 되었습니다.
• 서비스 플랫폼
  웹브라우저가 생기면서, 인터넷으로만 돈을 버는 “서비스사업”이 생겼습니다. “인터넷포털”이 돈을 벌게 된거죠. 산업분류로는 “정보통신제공업”, 업계말로는 “인터넷서비스”라고 부릅니다. 이 “인터넷서비스”가 진화를 하자 “서비스플랫폼”이라는 용어가 등장합니다.
  　
  대표사례가 “트위터”입니다. API 를 오픈함으로써 자기네 기능을 자유롭게 쓰게 합니다. 개발자들은 API 를 연동해서 앱을 만들고 광고를 붙여 돈을 벌기시작한 겁니다. 그런 앱들이 많아지자 “트위터”에 쌓이는 컨텐츠가 급격하게 많아지기 시작합니다. 그래서 트위터는 수많은 뉴스정보를 갖게 되었고, 개발자들은 소액이지만 수익활동을 할 수 있게 된 겁니다.
  　
  즉, “서비스플랫폼”이란 다른 서비스들이 내 서비스를 쉽게 활용할 수 있게 해도록 해주는 인터넷 기반의 기술 환경을 말합니다.

서비스 플랫폼 비즈니스 모델의 유형

플랫폼 비즈니스 모델은 가게(store)형, 사슬(chain)형, 상거래(commerce)형, 대리인(agent)형, 웹서비스(web service)형, 그리고 게임 비즈니스 모델로 분류할 수 있다.
　
　
가게형 모델은 수요자와 공급자들이 플랫폼을 근거로 필요한 가치를 교환하는 비즈니스로, 애플의 앱스토어가 이에 해당한다.
　
　
사슬형 모델은 비즈니스 수행을 위한 가치 사슬을 플랫폼에 형성해 두고 이를 기반으로 참여자들의 협업을 통해 가치 활동을 전개해 비즈니스를 완성하는 것으로 홍콩의 리엔펑이 대표적인 사례이다. 패션산업 강자로 알려진 리엔펑은 단 한 명의 재봉사도 없이 의류 생산업체와 고객을 연결해주는 플랫폼 역할에 충실할 뿐이다.
　
　
상거래형 모델은 다양한 상품 공급자와 수요자들이 만나는 상거래 모델과 사이트를 플랫폼으로 운영하는 비즈니스로, 단순한 정보의 중개자에서 거대한 커머스 플랫폼을 구축하는 것을 전략으로 하는 이베이가 이에 해당한다.
　
　
대리인형 모델은 플랫폼으로서 거래 사이트가 직접 매매를 하는 것이 아니라 공급자와 수요자들이 자유롭게 매매할 수 있도록 서비스하는 대리인 역할을 하는 비즈니스로 온라인 서점의 대표주자인 아마존이 소매점 전략에서 에이전트 전략으로 수 한 유통업에서 플랫폼을 통한 디지털 중개업자가 된 아마존의 행보는 플랫폼 전략의 미래를 보여주는 듯하다.
　
　
웹서비스 모델은 플랫폼 기반의 각종 원격 컴퓨팅 서비스를 비즈니스로 하는 모델로, 아마존 웹서비스(AWS)가 대표적이다. AWS는 클라우드 컴퓨팅 환경에서 다른 웹사이트나 클라이언트 측 응용프로그램에 대해 온라인 서비스를 제공하는데, 모두 플랫폼 기반에서 제공되고 있다.
　
　
게임 비즈니스 모델은 플랫폼 기반으로 게임에 관한 수요와 공급을 연결하는 비즈니스이다. 페이스북이 많은 플랫폼 기반의 게임 비즈니스 모델을 확보하고 있으며, 카카오톡 역시 2012년 7월30일부터 플랫폼을 기반으로 한 게임 비즈니스를 시작해 성공을 거두었다. (월간[CEO&] 2015.09월호 참조)

https://steemit.com/kr/@endiyou/4-3

https://steemit.com/kr/@endiyou/3-2

>>> a = b'tail'
>>> b = b'head'
>>> sha256(a).hexdigest()
'0c62f876ef1dea830de9f32c2f4b46dd6d74d50d15896e09ef5a2fcd4ac7e1d7'
>>> sha256(b).hexdigest()
'9f2e6d33a3717ee826353a404ba4618d1aeeb6879ad7936bce8ed5f46814924d'

>>> a = b'e6d85489f5082f21b2ecb993c799bb45e3ba7ca24618c553ff3b650b2b4e0c9btail'
>>> b = b'96f77711bac6bb95014d94f3b19c604176412101054d6d439a9b142ed2642278head'
>>> sha256(a).hexdigest()
'6c8f20b2fea69cded0afe060ebb80b79a5d0e850f1c1f621c0aadb09454f49d0'
>>> sha256(b).hexdigest()
'3401b7f3ab6d4f1555bf53dc0692611c900fb29fcb9679d5ac6b65880d7847d3'

https://steemit.com/kr/@endiyou/2-1

https://steemit.com/kr/@endiyou/1