2016-07 IT Articles

Tags

, ,

Java에서의 View를 위한 Template Engine 비교


http://www.slideshare.net/jreijn/comparing-templateenginesjvm

Java환경에서 서버단을 개발하고 있다면, view를 위한 템플릿 엔진을 뭘 사용할까 고민될 수 있겠다. 이때 약간 참고해볼만한 자료.

다만, Velocity가 없는게 좀 아쉽긴 하지만.. velocity는 더이상 spring진영에서도 지원하지 않는.. 프로젝트가 거의 홀딩된 상태라 .. 앞으로는 사용이 확산될 것 같아 보이진 않는다.

Thymeleaf나 Freemarker를 보통 주변에서 선택하는 걸로…

 

OAuth2 개념잡기

facebook을 돌아다니다 우연찮게 .. 다시 보게 된 슬라이드. 역시 기본 개념을 잡기엔 나쁘지 않지만, 상세한 내용을 보기엔 조금 부족하다.

상세한 내용은 실제로 OAuth를 구축하거나 사용할일이 있을때 보는 걸로.

 
http://www.joinc.co.kr/w/man/12/oAuth2/About
이곳이 좀 더 상세하다. 일단 개념만 알아두어도 추후에 API의 사용자 인증이 필요해질 때 사용할 수 있을 것..

2016-03 IT Articles

코드 리뷰

https://brunch.co.kr/@supims/11

이 글에서 의미있었던 부분은 개인적으로 코드 리뷰를 하지 말아야 할때를 언급한 것이라 봅니다.

코드 리뷰를 하면 좋다는 것을 대부분 알고 있지만, 저는 모든 경우에 좋다곤 생각하지 않습니다. 그 좋다는 방법론, 이론 등도 경우에 따라서는 오버 스펙이 되기 때문이죠.

코드 리뷰 가이드도 꽤 좋습니다. 기본적으로 자동화가 가능한 부분은 IDE나 툴로 한번 미리 거치면 리뷰할 거리가 더 적어질 것 같습니다.

이 리뷰 가이드를 참고해 미리 미리 코딩할때 주의해보는 것도 좋구요🙂

현재 리뷰를 딱히 하고 있지 않지만, 리뷰를 할때 참고하여 진행해볼만 하겠습니다.

REST API 가이드

http://bcho.tistory.com/914

Apigee 의 가이드와 거의 유사하면서도 요약본 느낌입니다.  참조 문서에도 걸려있네요🙂

저 가이드대로 개발해보고 싶은데, 실상은 잘 안됩니다. 특히 네이밍과 URL구조에서 결정하는데 쉽지 않더군요.  경험 부족이기도 하고, 쉬운 방법으로 끝내려는 유혹에 …

가장 기본적인 리소스와 액션에 대한 설계 부분만 빼면.. 나머지는 대부분 가이드대로 개발하는건 어렵지 않은데 말이죠.. ㅠ.ㅠ

Microservices in Practice: From Architecture to Deployment

https://dzone.com/articles/microservices-in-practice-1?edition=147257&utm_source=Spotlight&utm_medium=email&utm_campaign=cloud%202016-02-23

마이크로 서비스의 아키텍처와 배포 설계까지 총 망라한 글. 기본적인 이해를 돕고, 전체적으로 조망할 수 있는 좋은 가이드 입니다.

특히 이 구조가 무조건 좋다고 막 도입하려는 개발자들이 있는데, 이런 분들 경계해야할 대상 1호 입니다. 오버 스펙이 될 가능성이 꽤 높거든요.

모놀리틱 구조가 무조건 나쁜건 아닙니다. 규모가 커지고 감당이 안될 사이즈면 MS로 나누고, MS가 너무 나뉘면 서비스 Discovery가 나빠지고, API구조가 나빠지는 등의 단점도 생기기도 하구요. 장단점이 존재하기에 적절한 사이징이 좋습니다.

 

 

2016-01 IT Articles

간만에 다시 블로그에 들어와 기록을 남겨봅니다🙂 원래 새해가 되면 이런거잖..

SpringBoot, PhantomJS를 이용해 바코드, QR 코드가 포함된 동적 이미지 쿠폰 만들어보기

http://brantiffy.axisj.com/archives/498

바코드나 QR코드 lib으로 생성하고, 생성된 코드를 HTML template과 함께 렌더링, 이것을 다시 PhantomJS로 화면 캡처 (실제로 예전에 해본경험으로 잘 되더군요 .. ) 하여 image로 저장후 이 이미지를 서비스하는 방식..

여기서 좋은팁을 하나 얻었는데..

 <img id=“barcode” alt=“Barcode” src=“data:image/png;base64,${barcode}” /

처럼 image를 base64로 인코딩하고 이를 img src로 지정할 수 있었다는 사실!!

 

Customer Lifetime Value (고객총가치)

http://www.andrewahn.co/marketing/customer-lifetime-value/

CLV를 이용한 마케팅을 이해하기 위한 좋은자료로 보입니다.  또 하나 도움이 되는 자료는

http://sungmooncho.com/2011/11/21/customer-lifetime-value/

 

CLV란 말 그대로 고객 생애 가치로.. 고객이 가입하여 탈퇴할때까지의 이익의 총합이라 보면 되겠다.

다시 말하면 고객이 매년 기업에게 기여하는 이익에서, 그 고객을 이탈하지 않게하려는데 들인 비용을 빼고, 여기에 실제로 이탈하지 않을 확률을 곱한 것을.. 매년 더해가면 된다.

마케팅비를 들여서라도 이탈률을 줄이는게 이득이라면 CLV가 올라 것이고, 그렇지 않다면 마케팅을 잘못한것!

마케팅을 하지 않고, 다른 방식으로 이탈율을 줄일 수 있다면 더욱 CLV가 좋아질 것. 회사는 이 CLV가 올라가는 방향으로 의사결정을 하면 될것입니다.

Open Source S/W Applicaiton Performance Monitoring – Scouter

https://github.com/scouter-project/scouter

https://github.com/scouter-project/scouter/blob/master/scouter.document/main/Quick-Start_kr.md 을 보는게 더 도움이 될수도🙂

Java기반 환경이라면 모니터링 용도로 사용해볼만 할수도 있지 않을까 하는 생각이 드는.. 오픈 소스이므로 필요하면 기여도 가능!

 

라이브러리 Vs 프레임워크

http://www.wegra.org/blog/?p=1220

저도 가끔 면접볼때 질문하는 내용중의 하나입니다. 둘의 차이점을 말해보라구요. 제 지인인 wegra가 정리한 내용인데 깔금한 도식이라 공유!

프레임워크 : 전체의 틀이 정해져있고, 그 틀에 본인 코드를 맞춰야 하는 것!

라이브러리 : 본인 코드에 라이브러리 기능을 불러와 사용하는 것!

 

나도 제다이가 될 수 있다!!

http://gizmodo.com/a-new-wearable-lets-you-control-spheros-bb-8-using-the-1750989688?utm_campaign=socialflow_gizmodo_facebook&utm_source=gizmodo_facebook&utm_medium=socialflow

스타워즈 BB-8을 force band로 컨트롤하는 .. 마치 포스를 사용해서..

BB-8은 현재 $150 정도, force band는 프로토타입이라 현재는 스마트폰으로 컨트롤 해야하는군요.

 

Java 8 람다와 Functional ?

http://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220412722908&parentCategoryNo=&categoryNo=6

람다와 FP에 대한 개념을 뒤섞여서 설명해놓은 글로 보이지만.. FP의 기본 개념을 알아가는 과정에서 빠르게 훑고 지나갈만한 글 같습니다.

람다는 FP의 표현식중의 하나라고 그냥 생각하는게 더 나을것 같습니다.  익명 함수를 간결하게 표현하는 방법 정도?

http://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220415977706&parentCategoryNo=&categoryNo=6&viewDate=&isShowPopularPosts=false&from=postView

이글도 자바 8의 새로운 기능에 대해  빠르게 훑고 지나갈 수 있습니다.🙂

자세한 내용은 좀 더 심도있는 글을 보셔야 겠지만요.. 그냥훑고 지나가는 정도만..

 

드론이 벌써..

드론이 회자된게 얼마되지 않은것 같은 느낌이었는데.. 벌써 승객용 드론이 나왔네요.

세계 최초 승객용 드론, EHang 184

물론 아직 안전성이나 법규적인 측면이나 실제로 운행은 불가능해보이지만.. 여기까지 기술이 온게 대단해보입니다.

미국은 벌써 이 드론의 관제시스템까지 개발하고 있다니 이미 한참이나 앞서있군요.

많은 드론들을 충돌없이 어떻게 관제할까?

관제 시스템까지 구축되면 군사, 물류부터 승객 이송도 현실화 될 것 같습니다. 아마 법규도 곧 따라오겠지요.

 

ORM은 언제 사용해야하나?

http://mikehadlow.blogspot.ca/2012/06/when-should-i-use-orm.html

Model Complexity 가 높고, Throughput도 높아야 하면 역시 expert만이 ..

성능상 이슈가 적고, Model Complexity가 높은경우 ORM을 사용하라고 되어 있는데.. 대체로 동감.  성능 이슈가 나오면 아직 ORM은 대응하기가 쉽지 않은게 사실.

개인적으로는 Model 복잡도와 관계없이, 성능 이슈가 적은 시스템에서 ORM을 적용하여 경험을 쌓은 뒤, Model 복잡도가 높은 곳에 적용, 그 다음에 둘다 해당하는 곳에 적용하는 식으로 가는게 어떨까 싶다.

확실히 ORM일 잘 안다면..(ORM이 내부적으로 어떻게 동작한다는 것을 잘 파악하고 있다는 의미.)  유지보수나 개발 생산성은 상당히 개선될 수 있을 것으로 보인다.

BASE (basically available, soft state, eventually consistent) – An ACID Alternative

http://queue.acm.org/detail.cfm?id=1394128

Atomic, Consistency, Isolation, Durability 속성을 보장하는 DB로 인해, DB는 굉장히 믿을만한 시스템이고, 트랜잭션 자체를 안심하고 사용할 수 있었던데 반해, 대용량 웹 서비스에서는 확장성의 한계가 명확했다.

이 확장성의 한계를 극복하고자하는 방법으로 BASE를 설명하는데, 실제로 이 방법은 이미 내가 차명하는 프로젝트에 개념이  적용되어 있었다… 분산 DB가 아닐뿐..

이벤트 드리븐, 메시지 큐,  몇가지 방법으로 한 트랜잭션을 짧게 가져가면서도 분산된 데이터를 보관하고, 성능을 상당히 향상시키면서도 데이터의 정합성을 보장할 수 있다.

다만, DB가 아니라 개발자가 이 부분을해야한다는 단점!!

Advantages of Monolithic Version Control

http://danluu.com/monorepo/

단일 repository의 장점들을 언급한 글인데, 상당히 동감하는 바가 있다. 지금도 프로젝트를 진행할때 프로젝트를 나누는 기준 (즉, repo를 분리하는 기준)을 정할때 항상 의견이 분분하다.

나는 보통 이렇게 정한다. 디펜던시가 프로젝트간에 굉장히 높다라면.. 단일 repo에 하나의 parent 프로젝트로 하고, 하위에 모듈을 두는 형태로 진행한다.

이렇게 했을때의 장점중 하나는, 디펜던시로 인한 오류의 확률을 줄이고, 개발할 당시부터 개발툴의 도움을 받아 오류의 포인트를 빠르게 찾아낼 수 있다. 단점은 뭐 말할필요도 없이 프로젝트가 커지는것이고!!

Swagger

HTTP에 JSON으로 제공하는 API가 있다면 Swagger로 커뮤니케이션 수단과 테스트 수단으로 사용해보자.

얼마전까진 없었는데 이젠 client lib도 자동 generation까지 해주네요. 우왕 굿!

공식 사이트  http://swagger.io/

요약하면.. 컨트롤러와 request, response 엔티티의 코드 주석겸 어노테이션을 달면,  괜찮은 퀄리티의 테스트가 가능한!! API I/F 화면을 구성 + client library까지 자동으로 생성해줍니다.

경쟁 제품으로 spring-restdocs, iodocs 등도 있습니다.🙂

 

https://www.socallinuxexpo.org/sites/default/files/presentations/SCALE%2014x-%20Swagger.pdf

https://www.socallinuxexpo.org/sites/default/files/presentations/SCALE%2014x-%20Swagger.pdf

 

FaceBook의 새로운광고 포맷 Canvas

페이스북, 새로운 광고 포맷 ‘캔버스’ 테스트 중

페이스북이 새로운 브랜드나 영화, 제품을 홍보할 수 있는 멀티미디어 스토리텔링 광고 포맷을 테스트 중이다. 모바일에 최적화되어 있으며 페이스북 타임라인의 글을 클릭하면 동작하고 사진과 동영상으로 구성되어 있다. 페이스북에 따르면 기존 모바일 웹보다 10배 빠른 로딩 속도를 보이며 BMW, Universal 같은 기업이 이미 사용중이라고 한다.

음. 모바일 웹보다 10배 빠른 로딩속도는 무슨 근거일까 궁금..🙂

 

 

IT Artciles 2015-05

Tags

, , , , , ,

프로그래머가 알아야할 97가지 중 최고 9개와 아키텍트가 알아야할 97가지 중 최고 7개

http://kwon37xi.egloos.com/4632235

프로그래머와 아키텍트가 명심해야할 일종의 명언? 느낌이 드는 몇가지를 소개하는 곳!

개인적으로 ‘소프트웨어 아키텍트가 알아야할 97가지 ‘란 책을 읽어보았을때 굉장히 유용한 내용이 많았습니다. 아키텍트로 성장하고 싶은 개발자라면 한번 읽어보면 좋을것 같습니다.

위 글에서 가장 중요한 것을 각각 하나씩 뽑으라면.. 전 이렇게 뽑겠습니다.

프로그래머 – 보이스카웃 규칙  (떠난 자리는 아름답게~~ )

아키텍트 – 아키텍트는 프로그래머이다.   (훌륭한 아키텍트는 좋은 개발자에서 출발하지 않나 싶..)

[번역] Node.js를 떠나며 – express를 만든 TJ의 글

Node JS진영에서 프로그래머로 활동했던 개발자의 회고(?), 혹은 GO로의 전향글입니다.

자신이 직면했던 문제를 해결하는데 있어 Node.js는 최적의 솔루션이 아니었음을 얘기하면서 Node.js의 문제점을 얘기하고, Go가 대안이 될 수 있음을 설명합니다.

Go versus Node섹션이 가장 재미있는데요. 개인적으로 javascript언어를 그닥 선호하지 않는 저로서는 이 저자의 얘기가 와닿긴 합니다.

이에 반박하는 글은 아래의 URL링크를 보시면 됩니다.

View story at Medium.com

TDD는 죽었다 – Rails를 만든 DHH의 글

 

TDD을 고민해봤던 개발자라면 한번 봐볼만한 글입니다. TDD를 해본 개발자를 찾는 구인광고를 많이 봤는데요..

TDD를 제대로 해본 개발자가 얼마나 될까요? 저도 테스트 케이스를 만드는 편입니다만..전 TDD로 제대로 개발해본적이 없습니다. TDD는 개발방법론이라 테스트를 만들었다고 TDD를 한 것은 아닙니다.

웹 플랫폼 개발에서 TDD가 과연 가능한가에 대해서도.. 생산성이 얼마나 높아지는지에 대해서도 의문이 있습니다.

Full Stack 개발자란?

http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/

스타트업에서 full stack 개발자를 찾는다는 구인광고를 많이 보게 된다. 대체 풀스택 개발자란 무엇인가?

일반적으로는 front-end + back-end 를 모두 아우르는 개발자로 인식되고 있는 것 같은데.. 위 글에서는 그것보다는 OSI 7 Layer🙂 처럼 조금 더 상세히 기술하고 있네요.

UX와 Business 까지를 풀스택에 포함되어야 하느냐는 저도 의문이긴 하지만.. 최종 완성형 풀스택 개발자는 저 모습이 맞긴 할것 같습니다.

그런데..저정도 개발자라면 창업할거 같은..🙂

 

IT회사의 번아웃을 막는 방법

https://subokim.wordpress.com/2013/04/12/prevent-burnout/

다른 업계는 모르겠지만.. IT업계에서는 이한몸 불살라 제품을 만드는 이들이 꽤 많은것 같습니다🙂

여기에서 한번 좌절하거나 이 한몸 불살라도 제품이 성공하지 못하거나.. 제품을 제때 만들지 못할때 번아웃 되기도 하죠.

거기다  야근도 잦은 편이고, 장애는 휴일/주말/새벽을 고려하지 않으니까요..  업무시간이 명확하게 규정되기 힘든 업무환경 탓도 있는것 같습니다.

이런 번 아웃을 막는 방법에 대해 블로그글이 있기에 쭈욱 읽어봤는데요.

번아웃 현상이 있는지 진단하는 방법, 번아웃의 원인, 번아웃의 결과, 번아웃의 방지법이 상세하게 나와있어 꽤 재미있게 읽었습니다.

개발자에게는 예전에는 그렇지 않았는데… 개발이 재미가 없고, 해도 안될거 같고, 보수적으로 대응하게 된다면.. 번아웃 된것이지 않을까요?🙂

 

IT Articles 2015-04

Tags

, ,

Cash.me

https://cash.me/

square 라는 fin tech 기업에서 내놓은 참신한 이체 or 지불 수단입니다.

도메인에서 말하듯이.. 나에게 돈을 던지라는 메시지가 명확하네요🙂

실제로 cash tag라는 형태로 cash.me에 본인의 unique한 tag를 생성한 후 돈을 지불하는 사람에게 이 tag를 알려주고 돈을 부칠 수 있도록  합니다.

돈을 지불(이체)하는 사람에게는 이 tag에 접근하면 신용(체크)카드 번호와 메시지를 입력하고 본인이 입력한 금액을 tag소유자에게 전달하는 형태로 보입니다.

cash tag라는 형태가 참신했고, 수수료도 비지니스용으로는 1.5%로 저렴(?)한 편이라 훌륭하네요. 다만, 물건 구매를 위한 결제수단으로 사용 가능할지는 의문입니다. 메시지에 본인의 상품 구매 거래번호를 입력안하면 그냥 돈만 이체하는 형태가 되지 않을까하는 의구심? 

뱅크월렛 카카오처럼 현금 이체방식이 아닌 .. 지불하는 사람은 카드 지불로.. 수신자는 1.5% 수수료를 제한형태로 받기 때문에.. 직장인 점심값 N빵용으로는 적절해 보이지도 않을 뻔했으나.. 친구간은 수수료가 무료라고 하니 적절하네요🙂

가장 적절한 사용처는 Donation(기부)이 아닐까 싶은데요. 기부받는 대상은 1.5% 수수료가 그리 높지 않고.. 지불하는 사람도 현금이 아닌 카드로 하기때문에🙂

GitHub에서 분석한 Java Library 패턴

http://www.javacodegeeks.com/2015/04/we-analyzed-60678-libraries-on-github-here-are-the-top-100.html

전세계적인 프로젝트Repository(?)를 분석한 결과이니  대략의 Java개발 흐름 ? 혹은 개발에 필수적인 Library들을 알수 있습니다.

Testing, Mocking, Logging은 아마 개발과 유지보수를 위해 필수적으로 들어가는건 당연할 것 같습니다만..

Parsing이 좀 의외였는데요. REST API가 늘어가는 추세라 그럴까요?🙂  어쨌든 시스템간 연동이 많다라고도 해석할 수 있을듯 싶습니다.

 

 

2015-03 IT Articles

Tags

, , , , , , , ,

admin bootstrap themes

https://daveismyname.com/free-bootstrap-admin-themes-bp#.VPz9sFOsU7Z

저같은 back-end 개발자들에게는 front 구현 역량이 좀 부족한 것은 사실입니다. 정확히는 생산성과 퀄리티가 떨어지죠.🙂

특히 UI관련해서는 센스가 부족하기도 하고, 작업하다보면 개발자스럽게 화면이 나옵니다.

다행히 BootStrap같은 UI Template이 나와서 많은 도움이 되었죠.

어떤 프로젝트를 하던간에 admin tool은 거의 만들텐데요. 내부 운영자가 사용하는 만큼 Ux guide나 제한조건등을 까다롭게 따지지 않는다면 위의 BootStrap Theme를 이용하면 백엔드 개발자가 순식간에 운영툴을 만들수 있을겁니다.

S/W엔지니어의 이력서 작성법

http://www.haeyounglee.com/post/41769497481/how-to-write-a-killer-resume#.VP5KCFOsWba

요약하면, 중요한 업무 내용와 자랑거리들을 기술적 업무를 부각시키면서 구체적으로(수치등) 적시하고,  절대 거짓말과 과장을 하지 말라 입니다.

저도 이력서를 상당히 많이 보고, 면접을 봤습니다만, 아무래도 이력서의 내용이 위와 같다면 눈길이 가는게 사실입니다. 여기에 과거 경력이 좋은 경우는 더 눈길이 갑니다.

면접을 진행하면, 구체적으로 업무와 성과를 적시해놓은경우 질문과 답변이 더 원활한경우가 많았고, 거짓으로 점철된 경우 금방 탄로납니다.🙂

면접을 볼때, 태도도 굉장히 중요한데요. 자신감있게 응하면서, 아는것과 모르는 것을 정확히 구분해, 아는 것은 얘기하고 모르는 것은 모른다고 솔직하게 얘기하는게 저에게는 더 와닿았습니다.  모호한게 말한다면 .. 개발도 모호하고 대충 개발할것 같은 느낌적인 느낌때문이죠🙂

대규모 분산 시스템 추적 플랫폼, Pinpoint

http://helloworld.naver.com/helloworld/1194202

한줄로 요약하면 네트워크 환경에서 method calll을 추적하는 method.printstacktrace의 느낌? 입니다.

bytecode instrumentation 기법 (http://ukja.tistory.com/17 참고, java의 bytecode를 직접 수정하는 .. )을 이용해서  aop 기법과 같이 소스 수정없이 원하는 코드에 추적코드를 심습니다.

추적코드를 통해 분산환경에서 어떤 로직들이 순서대로 콜되었는지 트리형태로 보여줄 수 있게 됩니다.

네트워크 환경에서 디버깅에 유용할 것 같습니다🙂

 Spring-Integration

http://projects.spring.io/spring-integration/#quick-start

EIP (http://www.eaipatterns.com/)을 지원하는 프로그래밍 모델 확장판입니다. 대략 풀어서 설명해보면 엔터프라이즈환경에서 이기종 플랫폼간의 메시징 서비스를 제공하여 통합을 이끌어내는 것이 아닐까 싶습니다.

EIP에서 얘기하는 아래의 개념은 모두 구현되어 있다고 하네요.

  • Endpoint
  • Channel (Point-to-point and Publish/Subscribe)
  • Aggregator
  • Filter
  • Transformer
  • Control Bus

외부 시스템과의 통합은 아래와 같은 메시징 프로토콜을 지원합니다.

  • ReST/HTTP
  • FTP/SFTP
  • Twitter
  • WebServices (SOAP and ReST)
  • TCP/UDP
  • JMS
  • RabbitMQ
  • Email

다양한 플랫폼상의 메시징 교환이 일어나는 곳이라면 spring-integration을 고려해봐야 하지 않을까요?

 

Spring Cloud Config

http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_client_side_usage

spring 개발 환경에서 유동적 정보를 context에 전달하기 위해서 spring profile 이나 여러 configuration을 사용할 겁니다. 보통은 startup시 jvm에 parameter로 전달하거나 혹은 properties파일을 이용합니다.

MSA(Micro Service Architecture)가 한창 뜨고 있는 요즈음(?)에 이런 설정정보들을 각각의 프로젝트에서 관리할 수도 있겠지만 cloud 서비스처럼 한곳에서 이런 설정정보를 제공한다면 조금 더 개발 및 관리가 수월할수도 있을것 같습니다.

이를 사용하려면 어느정도 규모가 있는 환경에서 다양한 프로젝트가 구동되어야겠지만요..🙂

 

MicroService

http://channy.creation.net/articles/microservices-by-james_lewes-martin_fowler#DecentralizedDataManagement

마이크로 서비스 아키텍처의 개념을 어느정도 잡을 수 있는 글입니다. 마틴 파울러 아저씨(?)의 글을 번역한 글입니다.

MSA를 지향할때 무조건적인 신봉은 금물입니다. SOA도 좋은 모델이었지만.. 거의 실패(?)했죠..

MSA도 그럴 가능성이 없다고는 못합니다. 올바른 곳에 올바른 솔루션을 도입해야하는 이유죠.

실제 제가 하고 있는 업무에서는 몇가지 고려할 점이 있었습니다. 트랜잭션 문제? 장애 상황 대처? 분산된 데이터 관리 문제? 어디까지가 마이크로 서비스인가? 등등등..

모놀리딕에서 간단한 문제를 더 복잡하게 푸는것은 아닐까? 라는 생각이 들기도 하지만 분명 이 아키텍처가 도움이 됩니다. 전면적인 도입보다는 순차적, 선별적으로 개념을 도입해보는건 어떨까요?

 

2015-02 IT Articles

Tags

, ,

구글, HTTP/2 지원

http://www.bloter.net/archives/220155

구글이 2016년부터 표준 통신 프토토콜 HTTP/2 개발에 동참. 기존 SPDY를 밀고 있던 구글이 표준 프로토콜 개발에 참여하나 보네요. SPDY의 장점이 HTTP/2에 반영되어서 더이상 SPDY가 필요없다라고 하니, 실제로 HTTP/2표준에 실질적인 영향력을 끼치고 있다고 봐야겠죠.

조금 더 상세한 내용은 slideshare에 있는 자료를 보시면 되겠습니다.

요약하면 성능 이슈로 인해 HTTP 2에서는

  • header compression
  • multiplexed streams
  • server push
  • stream priority

를 지원한다네요🙂 대체  얼마만에 버전업인가요. !!

 

기획자의 세가지 생각정리 역량

http://platum.kr/archives/16111

기획의 순서가 자료수집분석=>논리구성 =>스토리 구성의 단계로 이루어지는데 이중 핵심은 논리구성에 있다고 합니다.  논리구성은 특히 무엇을 원하는지, 왜 그것을 해야하는지에 대한 기획의 의도이기 때문에 저도 가장 중요한 영역이라고 봅니다.

위의 글에서는 세가지의 역량을 ..

  • 생각의 폭 : 넓은 시야를 갖는 일
  • 생각의 깊이 : 의미있는 메시지를 찾아내는 일
  • 생각의 함축 : 핵심을 단순하게 구성하는 일

이라고 언급하는데요. 기획뿐만 아니라 사실 개발자로서도 중요한 역량이 아닌가 싶습니다. 생각이 깊이란 역량은 문제의 핵심을 짚어내는 능력이라고 말을 바꿔도 되는데, 개발에서도 같은 역량이 필요하죠.

개발도 넓은  시야를 가지면, 같은 문제를 여러 해법으로 풀어낼 수 있고, 문제의  핵심을 짚어내면 문제를 아주 명확하게 정의할 수 있게 됩니다. 그리고 아주 중요한 말이 있죠. “Simple  is the best.” 문제의 핵심을 단순하게  풀어낼 수 있는 역량은 아주 중요합니다. 개발도 단순해지지만 유지보수가 월등히 쉽습니다.

저는 저런 역량을 가지고 있는지 되돌아 봐야겠네요🙂

Docker 1.5  Release

http://blog.docker.com/2015/02/docker-1-5-ipv6-support-read-only-containers-stats-named-dockerfiles-and-more/

컨테이너 환경인 docker가 최신 버전을 릴리즈했는데요. 특징으로는

  • IPv6 support
  • Read-only containers
  • Stats
  • build시 spec 파일 지정 기능

등이 있습니다.

다만, 클라우드 플랫폼을 구축할때는 거의 필수적인 docker에 대해 특히 stats api를 반기는 분위기인데요.. 아무래도 docker의 상태를 알아야 할테니까요🙂

 

오픈 소스 로드 밸런서 HAProxy

http://helloworld.naver.com/helloworld/textyle/284659

안정적인 서버 운영을 위해서는 부하분산을 위한 로드밸런싱이 필요하죠. 제가 다니는 회사에서는 L7 스위치를 사용하고 담당자가 있어서 간단한 신청절차만 거치면 부하분산이 쉽게 이루어집니다만..

스타트업이나 작은 업체에서는 H/W 구매나 이에 대한 지원이 상당히 부담스럽겠죠.

이때 간단히(?) 구성할 수 있는 S/W기반의 로드 밸런서 입니다.   기본적으로 reverse proxy 방식으로 동작하므로 apache의 mod_proxy와 거의 동일한것 같네요.

성능상 큰 이슈가 없다면 apache mod_proxy_balancer(http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html)가 개인적으로 더 간단하지 않을까(?) 싶습니다만.. ..

성능에 조금 욕심이 있고,  아파치는 이것에 최적화는 안되어있을테니.. 좀 더 제대로 써보겠다 싶으면 HAProxy로 구성하는게 좋아보입니다.

 OAuth 2.0

http://helloworld.naver.com/helloworld/textyle/24942

http://oauth.net/2/

최근 제가 개발하고 있는 서비스에서 회원제약조건 (회사서비스계정만 사용할 수 있도록한 ..?) 을 어떻게 풀 수 있을까를 고민하다.. OAuth2 지원을 고려하고 있습니다. OAuth를 지원하면, 이미 OAuth인증을 지원하는 타 서비스에 가입된 사용자를 저희 서비스의 사용자로 용이하게 끌어들 일 수 있으니까요.

OAuth는 플랫폼의 시대에 적절한 인증과 권한을 위한 오픈 프로토콜(?)입니다. OAuth버전이 1.0, 1.0a, 2.0 등이 있고, 1.0과 2.0은 호환되지 않습니다. 현재는 2.0으로 옮겨가는 추세로 보이며..대표적으로 facebook과 google이 있겠죠. 1.0a는 트위터가 지원하나 봅니다.

OAuth의 client가 되면, 타 서비스에 가입된 유저를 끌어오는게 용이해지는 반면, 사용자의 정보는 제한적으로 접근가능하겠죠. 반대로 타 서비스에 사용될 수 있는 사용자 플랫폼을 만들어 Service Provider 혹은 Resource Server가 된다면 .. 사용자 lock-in을 효과적으로 할 수 있겠죠. (구글과 페북처럼요 .. )

특히 모바일 환경에서 앱마다 서비스 가입절차를 거치지 않고 페북이나 구글의 인증을 타고 사용하는 것이 많이들 보이는데요. OAuth 기술을 사용하고 있겠죠?🙂

2015-01 IT Articles

2014년이 지나고 새해가 밝았네요.

2015년에도 꾸준히 트렌드를 쫓아가보도록 하겠습니다🙂

apache Spark의 Resilent Distributed Dataset

https://crackjamx.wordpress.com/2014/07/30/201407-it-articles/ 에서 언급했던 spark의 근간이 RDD임을 말하는 slide입니다. 보니까 좀 더 spark의 기본구조를 이해하는데 도움이 되네요.

결국 메모리상에서 분산 processing을 용이하도록 하기 위해 read-only 데이터를 캐싱하고 lazy-execution을 통한 최적화, 거기에 check point를 저장하여 적절한 fault tolerancing을 하여 최적의 성능을 끌어냈다라는 의미인듯합니다. 실제 하둡보다 빠르고 오퍼레이션도 많아서 사용하기 좋다로 받아들이면 될거 같습니다🙂

 

Which Programming Lang?

초심자들이 어떤 개발언어를 선택해야하는지, flow chart(?)로 그린 재미있는 그림입니다.

한글 번역판은.

http://mcchae.egloos.com/11148354

그냥 재미로 보시면🙂

스타트업을 위한 기술 스택

http://www.codeok.net/%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EA%B8%B0%EC%88%A0%20%EC%8A%A4%ED%83%9D

꼭 스타트업 뿐만 아니라 기존 업무에서도 적용할만한 기술들이 꽤 있습니다.

저의 경우에는, 랭귀지와 프레임웍은 익숙한 java와 spring을 선택하겠지만.. 초기에 진입할만한 부분에서는 선택지가 많네요.

front영역에서는 bootstrap과 jquery, 더 나아간다면 angularJs를 선택하여 one page webapp(?) 구현해보고 싶네요.

웹서버에서는 nginx와 apache중에 개인적으로 apache를 더 선호합니다. nginx가 성능이 apache보다 몇배 이상 빠르다하더라도 실제로 운영환경에 있어서 성능을 극한까지 끌어다쓰는 웹 서비스가 얼마나 될까요? 거기다 스타트업이?🙂

그보다는 문서화가 잘 되어 있고, Q&A가 많은 쪽을 저는 선택할거 같습니다. 성능 이슈는 웹 서버보다는 application 영역에서 문제가 될겁니다🙂

image서버는 구축한다면 squid 나 varnish를 사용하여 구축할거 같습니다. storage share부분은 NFS로 하면 쉽지 않을까?하는 생각도 듭니다.. 물론 클라우드 제품이나 CDN 사용할 수 있겠죠오~~🙂

큐는 rabbitmq나 redis 로 쉽게 구축이 가능하고, 작업큐 형태로 비동기 worker 분산의 용도라면 http://gearman.org/ 을 사용할것 같습니다.  사실 간단한 비동기 worker라면 DB table을 queue용도로 사용하고, batch 시스템에서 주기적으로 테이블을 읽어가며 실행하면 단순하게는 가능합니다.

개인적으로 주기적인 작업을 위해서 cron을 사용하는 것은 초기에 나쁘지 않지만, 장기적으로는 소스 관리 및 스케쥴 관리가 잘 안되서 선호하지 않습니다. 장애알림도 쉽지 않죠 ..

이외에도 많은 기술 스택이 필요하겠지만, 초기 성공여부가 불투명하다면 Paas 사용이 더 좋을거 같고, 성공하고 있는 서비스의 경우는 자체 구축하는게 비용 절감측면에서 유리하다고 생각합니다.

db replication와 서버 fail over는 미리 염두해 두시면 불의의 사태에 당황하지 않을거 같네요.🙂

 

Java Performance Fundamental

http://novathin.kr/75

자바 성능보다는 jvm 아키텍처에 대해 알수 있는 자료로 보입니다. 꼭 성능에 관심이 없더라도 한번 살펴보시면 좋습니다.

눈에 확 잘 들어오진않네요🙂 일단 ppt 페이지가 너무 많아요 ㅠㅠ

 

 

[번역] 결제기술의 혁신과 디지털화폐의 출현

Tags

, , , , ,

원문 : Innovations in payment technologies and the emergence of digital currencies
디지털화폐의 출현 다운로드

이글은 재미삼아(?)라고 하기엔 너무 난해한 내용이 많아서 대략 직역 + 의역이 포함되어 있을 수 있습니다.

========================

[결제기술의 혁신과 디지털화폐의 출현]

By Robleh Ali of the Bank’s Financial Market Infrastructure Directorate, John Barrdear of the Bank’s Monetary
Assessment and Strategy Division, and Roger Clews and James Southgate of the Bank’s Markets Directorate.(1)

* 현대의 전자결제시스템은 안전하게 결제를 처리하기 위해 신뢰할만한 중앙의 서드파티에 의존한다. 새로운 화폐와 분산된 결제 시스템과의 조합인 Bitcoin과 같은 디지털 화폐가 최근에 나타남을 볼 수 있다.
* 디지털 화폐로의 화폐양상이 상당히 주목을 끌고 있지만, 그들의 결제 시스템 기저에 깔려있는 분산된 원장(대장)이 중요한 혁신이다.
* 은행 예금과 같이 오늘날의 대부분의 금융 자산은 순수하게 디지털 기록으로서 존재한다. 이것은 금융시스템이 더 일반적으로 분산된 원장으로 변화하도록 그 가능성을 열었다.

[ Overview]
 화폐와 결제 시스템은 본질적으로 연결되어 있다. 교환의 수단으로서의 기능을 하는 자산으로 
보면, 거기에는 자산을 이동시키는 안전한 방법 - 결제 시스템 - 이 필요하다. 그리고, 어떤
 시스템에서는 물리적인 은행지폐나 동전의 교환보다는, 저장된 가치를 기록하는 수단 - 원장
 - 도 필요하다. 
현대의 결제시스템은 컴퓨터화 되어있고, 대부분의 돈은 오직 상업적 은행의 계좌에 디지털 
기록으로만 존재하고 있다.

이 아티클은 최근의 결제 기술 혁신에 대해 고려하고, 비트코인과 같은 개별적으로 발전된, 
인터넷 기반의 디지털 화폐의 출현에 포커싱하고 있다. 디지털 화폐 체계는 새로운 결제 
시스템과 새로운 화폐를 결합한다.사용자들은 기존 화폐나 물건, 서비스를 어떤 서드파티
(은행과같은) 없이도 서로 교환하는데 있어 디지털 화폐로 거래할 수 있다. 디지털화폐의 
출현은 어떤 중앙 은행에 의해 통제되지 않는다. 현재 가장 많이 사용되는 디지털 화폐인 
Bitcoin은 2009년도에 나타나 수천개의 비지니스업체에서, 전세계적으로 피자에서 
웹호스팅까지 어떠한 물건에 대해서도 결제수단으로 인정받고 있다. 대부분의 디지털 화폐
(비트코인을 포함하여)는 예정된 공급경로를 고정된 최종 공급으로까지 이르도록 구체화한다
(역자 주: 공급량이 한정되어 있다고 해석하면 될것같다.). 새로운 화폐의 등장을 포함하여 
어떻게 디지털화폐가 작동하는지에 대한 개괄적인 내용이 이 아티클에 포함된다.

최근 많은 미디어가 새로운 화폐와 그 화폐내의 상당히 큰 가격변동에 초점을 맞추고 있다. 
그러나, 이 아티클은 디지털화폐의 핵심 변혁이 은행과 같은 중개자없이도, 전체적으로 
분산방식으로 동작하는 결제 시스템이 나올 수 있는 ’분산된 원장’ 에 있다는 점을 논의한다. 
이러한 혁신은 암호화(보안 통신), 게임 이론(전략적 의사결정)과 peer-to-peer 네트워킹
(중앙기관없이 연결된 네트워크)을 포함하는 그런 원리들로부터의 진보를 나타낸다.
결제 시스템이 처음 컴퓨터화되었을때, 기저에 깔린 프로세스는 대부분 바뀌지 않았다. 
분산원장기술은 결제 시스템이 어떻게 동작할 수 있는지에 대한 근본적인 변화에 대해 말한다. 
그리고, 원칙적으로 이 분산화된 접근방법은 결제에 대해서만 국한되지 않는다. 예를 들면, 
대다수의 금융자산 (이미 디지털 기록으로만 존재하는 주식과 채권과 같은)은 중앙 
데이터베이스에 저장되어 있다.

이 아티클에 별첨은 디지털 화폐 경제에 대해 더 자세하게 다루고 있다. 그것은 돈이 역할을 
어디로 확장되는지, 그러한 체계의 디자인에 내제된 유인동기와, 리스크가 중요해지는 지점까지
 도달했다면 영국의 화폐 그리고 금융의 안정성을 위협할 어떤 위험성에 대해 설명한다.
(http://www.youtube.com/watch?v=CxDKE_gQX_M&feature=youtu.be )

화폐와 결제 시스템은 본질적으로 연결되어 있다. 이들은 함게 발전해왔고, 이런 연결고리는 영국 경제를 지탱하는 화폐와 결제시스템의 안정을 책임지는 영국 은행을 포함해, 많은 중앙 은행들의 부채상환능력(responsbilities)에 확실히 남아있다. 최근 결제기술들의 혁신은 즉각 많은 관심을 불러일으켰는데 특히 디지털화폐로의 결합과 같은 것들이다.

이 아티클은 결제 기술과 안전하고 신뢰수 있는 결제의 토대가되는, 16세기부터 현재에 이르기까지 발전해온 원리들에 대해 대략적으로 얘기한다. 최신 결제 시스템으로 이전 될 필요가 있는, 여전히 발생하고 있는 핵심적인 리스크를 다룬다. 그리고 나서, 결제 시스템과 화폐에 있어 최신 개발 이면에 있는 동기와 이것이 새로운 기술적, 경제적 모델을 어디까지 나타내는지에 대해 다룬다. 특별히, 디지털화폐의 토대가되는 핵심 기술 발전 (분산된 원장의 출현)에 대해 초점을 맞추도록 한다. 이런 새로운 기술이 전통적으로 결제 시스템에서 발견되는 위험을 어디까지 제거하는지도 고려할뿐만 아니라, 그것이 가지고 있는 새로운 리스크도 다룬다. 마지막으로 이런 분산원장모델이 결제를 넘어 어떻게 다르게 적용될 수 있는지도 다룬다. 짧은 비디오는 이 아티클에서 다루는 핵심주제의 일부를 설명하고 있다.

이글에 별첨된 단편물, ‘The economics of digital currencies’는 디지털 화폐가 화페로서 어디까지 확장되는지를 다룬다. – 현존하는 체계가 장기적으로 맞딱드릴수 있는 도전들, 그리고 디지털화폐체계가 조만간 영국의 화폐와 금융 안정성에 대해 잠재적으로 영향을 주는것으로서, 은행의 미션(화페와 금융안정 – 역자주)과 맞딱드릴 위험에 대해 초기 평가를 제공한다. 소비자 보호, 세금, 자금세탁과 같은 다른 이슈들은 이글의 범위에서 벗어나지만, 이런 이슈들과 관련이 있는 타기관의 문헌이 별첨글에 언급되어 있다.

The evolution of payment technology (결제 기술의 진화)

오늘날 대부분의 경제에서 사용되는 결제 기술은 초기 뱅킹시스템에서 진화하였고, 여전히 그것을 근간으로한 구조적 특성을 가지고 있다. 초창기 결제는 근본적으로 가치있는 아이템(금화같은)의 교환에 의해 이루어졌다. 16세기 골드스미스 은행이 나타났을때, 그들은 물리적으로 자산을 교환하는것보다 원장내에서 변경을 통해 결제가 이루어지도록 하는 고객 예금 원장을 보관했다. 이것은 같은 은행을 공유하는 고객들에게만 작동했다. 시간이 지나, 은행들 사이에서의 결제 필요성이 모든 은행사들이 계좌을 보유할 수 있고, 은행간 결제를 더 단순하게 만드는 중앙 ‘정산(clearing)’은행의 출현을 이끌었다. 3페이지의 box가 지급결제 시스템의 진화에 대해 더 자세히 알려준다.
Modern payment systems(현대의 결제 시스템)
현대의 결제 시스템에서, 결제는 동일한 양만큼 고객의 계좌에서 계좌잔액을 줄이고, 수신자의 계좌에서 잔액을 증가시키는 형태로 이루어진다. 16세기 이래로 변하지 않는 프로세스이다. 차이점은 잔액을 기록하고, 타은행간 전송하는 기술에 있다.

과거 50년간 기술적 발전은 두가지 핵심적인 방법으로 결제시스템에 영향을 주었다. 첫째, 기록과 원장은 종이에서 전자적인 형태로 바뀌었다. 이는 거래를 완료하는 속도를 증가시키고, 운영 위험을 줄여주었다. 둘째, 저비용의 기술들의 출현이 모바일 머니와 같은 새로운 지급결제체계가 출현하도록 하였다. 4페이지의 그림2에 논의되어 있다.

새로운 기술의 적용에도, 중앙집중적 결제 시스템의 기본 구조는 바뀌지 않고 남아있다. 그 중심부에는 중앙원장(central ledger)이라는 중앙기관의 기록을 통해 일어나는, 정산은행(중앙은행에 의해 일반적으로 수행되는 서비스)으로서 수행되는 청산(settlement)과정에 있다. 각 참여사들(보통 상업적 금융 기관)은 중앙은행에 계좌잔액을 잡아놓고, 원장에 기록할뿐만 아니라, 참여은행 자신의 (내부)원장에도 반영한다. 그리고나서 개개인의 고객들, 지사들 혹은 다른 (보통 작은) 은행들이 참여은행에 계좌잔액을 잡아놓고, 그들 자신의 내부원장에 다시 반영해놓는다. 이러한 ‘tiered’ (계층형) 배열은 그림1에 잘 묘사되어 있다. 예제는 상업은행에서 중앙은행을 통해 이루어지는 개개인간의 결제를 보여준다.

그림1

 

[A brief history of money and payment systems]
역사적으로 돈에 대한 많은 표현(물리적, 전자적)이 있어왔다. 경제학자들은 돈이 사회에서 가
지는 역할을 통해 그 표현을 구별하였다. 특히, 경제이론의 관점에서부터 결제를 이루어지게 
하는 교환의 수단, 오늘날부터 미래에 이르기까지 구매력(물건이나 서비스를 살 수 있는 역량)
을 전달하는 곳에서의 가치의 저장, 그리고 판매를 위한 어떤 물건의 가치를 측정하는 계좌의
단위로서까지 생각될 수 있다. 

돈이 교환의 수단으로서의 기능을 하기위해서는, 가치 전달이 가능한 어떤 시스템 (곧, 
결제 시스템)이 필요하고, 물리적인 은행지폐 혹은 동전의 교환을 하지 않는 어떤 시스템에게는
저장된 가치를 기록하는 수단인 원장이 필요하다. 

귀한 금속으로 만들어진 동전은 세계의 많은 지역에서 결제를 이루어지게하는 최초의 방법중 
하나였다. 소유권이 표시된 증서의 물리적인 점유와 그 물리적인 전송 행위는 결제 시스템으로
동작했다. 

골드스미스 은행이 16세기에 나타났을때, 그들은 금보관을 위한 영수증으로서 증서(근본적으로
약식차용증서)를 발행하였다. 이러한 차용증서는 개개인간 거래가 가능하였다. 
각 은행은 그 자신만의 원장을 보관하였고, 초창기에는 은행간 정산(settlement)는 없었다.
거기에는 개별은행들과 지점들이 서로 연결할 수 있는 방법이 없었다. 그래서 그 증서들은 
그 은행과 발행한 곳의 지점에서만 사용될 수 있었다. 이것은 다른 은행으로 돈을 보내는데
필요한 어떤 결제건에 있어서, 증서를 가지고 있는 사람이 먼저 금으로 바꾸고, 물리적으로
새로운 은행에 그것을 이송해야하는 번거로운 프로세스를 필요로 한다. 

이러한 거래비용을 줄이려는 압력이 은행들간에 지급요구를 받아들이도록 하는 시작점이 되었다.
이러한 혁신은 자금을 이송하기 위해 종이돈을 금으로 바꾸는 부담을 줄이는 등 상인들이 
다른은행의 증서를 직접 자신의 은행으로 예치할 수 있는 것만큼이나 더 편리한 거래를 
만들었다. 그럼에도 다른 은행에서 증서를 수리함에 있어, 지불금액을 받아야하는 은행은
새로운 문제에 부딪혔는데, 지불하는 은행이 금으로 정산이 진행될때까지 증서가 노출되는
것이었다. 증서를 받는 곳이 몇몇은행으로 제한되고, 이것은 쌍방으로 겨우 처리될 수 있었다.
그러나 이 시스템에서 은행수가 증가하자, 은행간 결제는 더 어렵게 되었고, 더 효율적인
시스템을 만드려는 은행들의 동기가 커져갔다. 

결국 드러난 해결책은 하나의 'clearing(청산)'은행을 이 시스템의 중앙에 배치하고, 모든
 회원은행이 청산은행에 계좌를 가지고 있는 것이었다. 이 시스템은 모든 회원은행이 시스템에 가져올 위험에 수반되는 계좌잔액을 예치함으로써 동작할 수 있었다. 청산시스템이 동작하는
은행은 사실상, 중앙은행의 기능을 가지고 있는 것이다.

 New developments in payment systems and alternative currencies

결제기술과 대안통화는 최근에 다양하게 발전되어 왔다. 이러한 변혁들은 더 다양한 사용자층에 결제를 더 쉽게 접근할 수 있도록하는데에 초점이 맞추어져있는(모바일 폰 결제처럼) 반면, 여전히 신뢰할만한 중앙의 기관(은행)에 의존하고 있다. 더 최근에는 근본적으로 다른, 중앙기관(central authority)에 의존하지 않고 보안에 의존한 분산된 구조의 결제시스템이라는 변혁이 일어나고 있다. 그림 2에서는 최근의 혁신에 대한 4개의 카테고리와 그것들의 특징들을 기술하고 있다. 이것은 새로운 결제 시스템, 새로운 화폐를 만드는지의 여부에 따라 나누어져있다. (Table A에 요약됨).

Table A

이러한 단순 분류 방법에 반하는 의견이 있다. 예를 들면, 특정 지역 화폐(local currencies)가 기술적으로 새로운 통화를 나타내는 것에 반해, 1:1의 고정환율에서 운영되고 국가적 화폐가 배경이되는 운영 체계는 실제 통화와 유사하다. 마지막 카테고리에서 후보(candidate) 결제시스템으로의 디지털 화폐와 잠재적인 화폐의 형태로서의 디지털화폐를 구분하는 것도 중요하다. 비트코인이 새로운 화폐와 새로운 결제 기술을 함께 보여주었지만, 이론적으로 분산 원장 기술은 새로운 화폐의 생성없이도 사용될 수 있었다. Haldane과 Qvigstad가 강조했지만, 실제 중앙은행은 기술적으로 최근의 디지털화폐에서 사용하는 분산 원장과 동일한, 분산 원장 결제 시스템에서의 디지털-온리 채권을 발행할수 있다.

Figure 2. Recent innovations in payment technologies

Category I : Wrappers
혁신의 첫번째 카테고리는 사용자 인터페이스와 현존하는 결제 시스템 아키텍처상의 접근성을 
향상시키는 래퍼 서비스를 제공하는 것에 초점을 맞추고 있다. 이러한 변혁이 새로운 화폐와
새로운 핵심 결제 시스템을 나타내지는 않는다. 핵심동기는 마켓 세그먼트를 새롭게 획득하기
위한 새로운 진입점이 될수도 있고, 마켓쉐어(점유율)을 늘리기 위해 그리고 고객이 더 비싼 
다른 결제 시스템의 사용을 줄이도록하는 기존 결제시스템이 될수도 있다. 사용자의 모바일폰
번호와 그들의 은행 계좌를 연동함으로써 기존 인프라스트럭쳐하에서 결제가 이루어지는
Google Wallet, Apple Pay와 Paym이 그 예가 될 수 있겠다.

Catgory II : Mobile Money
스마트카드나 시스템제공자의 books(장부)에 credits(예금)으로 저장된 돈이라는 이 체계는
새로운 결제 시스템을 나타내기도 하지만, 국가적인 화폐로 계속 사용되기도 한다. 한예로, 
케냐에서의 유명한 서비스인 M-Pesa를 들 수 있는데, 모바일 폰으로 결제를 포함한 
금융 서비스를 누구에게나 제공하고 있다.

Category III : Credits and local currencies (크레딧과 지역 화폐) 
이 카테고리는 통화로서 발행되지 않은 계산화폐(unit of account)와 교환의 수단으로써
 새로운 화폐에 대한 사용자의 신뢰에 의존한다. Credits(크레딧)은 사기업들이 특정 플랫폼
(온라인 게임안에서와 같은)에서 사용될 수 있는 대안 계산화폐로 돈을 교환하는 구조이다.
그렇기는 하지만, 일반적으로 자금이체는 래퍼 서비스의 사용을 포함하여 기존 결제 시스템을 사용한다. local currencies(지역  화폐?)는 사람들이 한국가의 화폐를  특정 
지역에서만 사용될 수 있는 지역 등가물(지역 특산품?)로 교환하는 것과 유사하다. 
UK 지역 화폐 (Bristol Pound와 같은)는 종종 잘 지원받고 있고, 스털링(sterling, 
영국 은화의 표준 순도, 법정순은)과는 고정된 환율로 남아있다. Naqvi와 Southgate가 
더 자세히 지역 화폐를 다루고 있다.

지역 화폐의 개발과 적용에 대한 핵심 동기는 특정지역에서의 경제활동을 부흥시키기 위해 
참여자들 사이에서의 사용촉진과 관련이 있고, 지역의 지속가능성과 더 짧아진 
supply chains(공급 체인)을 제공함에 있다.

Category IV: Digital currencies (디지털 화폐)
디지털 화폐는 새로운 분산 결제 시스템과 새로운 화폐 모두를 구체화한 것이다. 이 모든 
체계는 컴퓨팅 네트워크를 통해 공유되는, 공개적으로 볼 수 있는 원장이라는 것을 보여주고 있다. 각 디지털 화폐가 핵심적으로 정의하는 특징은 사용자가 원장에 변경을 가하는것
(이것은 거래가 잘 처리되었다고 인정하는 것)에 동의하도록 하는 프로세스에 있다. 

대부분의 디지털 화폐는 ‘암호화된 화폐’인데, 암호학 분야로부터 온 기술적인 방법을 통해 
합의를 추구한다. 또한, 암호화되지 않은 방법을 통한 합의를 추구하는 몇몇 디지털 화폐들이 
있는데, 그중에서 가장 유명한 것은 Ripple이다. (1)

(1) : 중앙집중적인 원장을 가진 디지털 화폐도 가능하다. 이런 방식으로 동작하는 
디지털화폐의 최근예는 아니기때문에 이 글에서는 논의하지 않는다. 

이 섹션의 남은 부분은 현재 디지털화폐의 예중에서 가장 주요한 Bitcoin의 소개와 디지털 화폐를 셋업하고 사용하는 동기에 대한 짧은 토론을 포함하고 있다.

What is Bitcoin? (비트코인이란?)

비트코인은 디지털 화폐로 기능하는 첫작품이자 가장 주요한 화폐이다. 2009년 1월에 등장했고, 개인적으로 개발되었으며, 인터넷 기반의 화폐이고, 결제 진행을 위해 은행과 같은 중개자가 필요하지않은 결제시스템이다. 더 나아가, 비트코인의 공급은 중앙은행에 의해 컨트롤되지 않는다. 이것은 일반적으로 ‘암호화된 화폐’로 회자되는데, 안전한 거래를 보증하기 위해 암호학분야의 기술에 기반하고 있기 때문이다. Litecoin이나 Peercoin과 같은 암호화된 화폐가 현재 수백개정도 있다. 이것들의 대부분은 비트코인에 명시적으로 기반하였거나, 영감을 받았다.

비트코인 사용자는 자신이 누구인지 드러낼 필요가 없다. 사용자는 자신의 컴퓨터에 디지털’지갑’을 보유하고, 특정 소프트웨어를 사용하여 전통적인 화폐나 물건 혹은 서비스를 교환함에 있어 서로간의 화폐를 매매하면 된다. 현재 전세계적으로 수천개의 업체가 피자에서 웹호스팅까지 무엇이든 결제하는데 있어 비트코인을 허용하고 있다. 결제는 두 사용자간에  전세계에서 언제든 일어날 수 있다. 사용자는 아래에 더 자세히 설명하겠지만, 이전 거래건을 검증하는 것(역자주: 비트코인 채굴을 얘기하는 것같음)에 대한 보상으로로 비트코인을 획득할 수 있고, 전통적인 화페에서의 교환처럼 다른 사용자들로부터 구매할 수도 있고, 물건이나 서비스로 교환하여 얻을 수 있다.

디저털 화폐 시스템의 핵심적인 혁신은 분산된 방식으로 결제가 이루어지도록 ‘분산 원장’의 사용에 있다. 이것의 동작 방식, 그리고 결제 기술에서 이것이 어떻게 핵심적인 혁신인지는 이글의 아래단락에서 설명되겠지만, 기본 프로세스는 다음과 같다. 결제를 원하는 사용자는 결제 지시문을 발행하여 다른 사용자의 네트워크를 통해 배포된다. 사용자들은 표준 암호화 기법으로 이 거래건이 올바른지 확인할 수 있도록 하고, 그 결제 당사자는 거래중인 그 화폐를 소유한다. ‘miners’라고 알려진 네트워크상의 특정 사용자들은 거래건 블록을 함께 모으고, 그것을 검증하기 위해 경쟁한다. 이런 서비스의 보상으로, 거래건 블록을 성공적으로 검증한 채굴자(miner)에게는 새롭게 생성된 화폐와 진행중인 거래건에 대한 수수료를 받는다. 페이지 7,8의 박스그림은 이 결제 시스템을 사용할때 거래가 어떻게 동작하는지 단계별로 보여준다.

후보 블록들은 퍼즐을 푼 보상으로 새로운 비트코인을 할당하지 않고, 거래가 없었다는 관점으로보아  ‘아무것도 없다’고 본다. 이것은 초창기 비트코인의 양적인 측면에서 효과적으로 생성되도록 했다. 첫번째 블록들이 블록당 새로운 50비트코인을 생성했고, 비트코인 프로토콜은 매 210,000 블록들 (대략 매 4년마다)마다 이러한 보상이 절반이 되도록 되어 있다. 현재는 블록당 25비트코인이고, 2017년쯔음에는 블록당 12.5비트코인으로 줄어들 것이다. 계획된 전체 비트코인의 량은 2100만 비트코인이고, 2040년이면 거의 그 수치에 다다를 것이다. 현재는 1300만 비트코인을 살짝 넘어서고 있고, 전세계적으로 1~2백만 이상의 사용자들에게 분산되어 있을것으로 추정된다.

비트코인의 가격은 이것이 출시된 후, 급격하게 올랐는데, 대충 과거 2년동안 5000%정도 올랐다. 이것은 상당한 불안정성을 나타내기도 하고, 이것이 주목할만한 논쟁거리가 되기도 하고, 미디어의 주목을 끈다는 것도 나타낸다.

스크린샷 2015-01-14 오후 6.45.54 스크린샷 2015-01-14 오후 6.45.59스크린샷 2015-01-14 오후 6.46.07

Motivation for the development and adoption of digital currencies (디지털 화폐의 개발과 채택에 대한 동기)

컴퓨팅 기술을 사용하고 신뢰를 하는 대중의 의지가 일반적으로는 증가하는 단계를 넘어서서, 디지털 화폐의 채택은 세가지 핵심요소에 의해 진행되었다. 바로 이데올로기, 금점적 보상과 낮은 거래 수수료의 추구이다.

비트코인의 근본적인 동기는 크게 이데올로기적인 것으로 드러났다. 디지털 화폐는 화폐의 공급과 결제 시스템의 중앙집중화된 제어를 피하기 위해 과격하게 설계되었고, 서드파티에 있어야할 참여자들이 필요로하는 신뢰의 정도를 최소화하는 방향을 설계되었다. 비트코인의 블록체인의 첫번째 블록(‘genesis block’)은 이런 문구를 포함하고 있다.
‘타임즈 (런던타임즈) 2009년 1월 3일 은행의 두번째 구제금융 고비에 있는 Chancellor(행장?)’
그날의 신문기사를 참조하여, 추측컨데 비트코인이 그날전에는 생겨나지 않았을 수 있었다는것을 설명하고 비트코인과 현대의 화폐경제의 구조사이에서의 개념상 차이점을 부각시키기 위함이 아니었을까 한다. 사용자들의 완전한 비트코인의 채택은 널리사용되는 화폐시스템에서는 경제적으로 거의 소외될 수 있을 것이다, 비록 직설적으로 말해 비트코인을 허용하는 업체가 상대적으로 적다는데서 기인하지 않음에도 불구하고 말이다. 추가적으로, 어떤 참여자들은 그 시스템에서 제공하는 익명성 근처에 이끌렸을지도 모른다.

두번째로,어떤이들은 디지털 화폐를 금융투자를 위한 자산클래스로 보고 있다. 이것은 이 화폐체계가 계획된 고정공급량과 증가하고있는 대중성 사이에서의 상호작용에 의해 움직인다. 각 공급에 대한 미래궤도가 미리결정되어있고, 확실히 알려져있기 때문에, 그들의 가격 이동성은 근본적으로 오직 수요변화만 반영할 것이다. 디지털 화폐가 내재적인 수요(생산요소로도 사용되지 않고, 소비자제품으로써도 추구되지 않는)가 없기때문에, 중간 혹은 장기적인 미래 가격 성장에 대한 기대는 주로 지원하는 거래건의 미래성장에 관련된 기대치에 따라 움직일 것이다.

디지털 화폐의 옹호론자들은 기존의 전자 소매 결제 시스템 혹은 해외 이체에 비해 낮은 거래 수수료를 제공한다고 주장한다. 이러한 전제에 기반하여, 많은 수의 스타트업 업체들이 정산을 위한 브릿지 메커니즘(교두보?)으로써 디지털화폐를 사용하는 결제장치를 제공하려하고 있다. 디지털 화폐에서의 낮은 거래 수수료의 지속가능성은 이 글의 자매편에서 더 자세히 다룬다.

The distributed ledger as a key technological innovation (핵심 기술 혁신으로서의 분산 원장)

이 섹션은 분산 원장 – 디지털 화폐의 핵심적인 기술 혁신 – 에 대해 개념을 알아보고, 분산된 결제 시스템 환경에서 ‘double spend(중복 사용)’문제를 어떻게 해결하는지 알아보도록 한다. 분산 원장(암호화된 화폐에서 ‘블록체인’)은 인터넷을 포함하여 여러가지 이전 혁신의 출현으로 가능하게 되었다. 이것은 암호학으로부터 온 개념에 기인하는데, 게임이론과 p-to-p 네트워킹와 같은 것들이다. 마지막으로, 이 섹션은 중앙집중화된 그리고 분산 결제 시스템 모두의 리스크에 대해서도 다루도록 한다.

 double-spend problem (중복 사용 문제)

전자결제시스템의 핵심적인 문제중의 하나는 돈이 중복으로 사용될 수 없다는것을 확인하는 방법이다. 만일 Anne이 1유로 동전을 하나 가지고 있다면, 그녀가 Bill과 Clare 둘다에게 1유로씩 줄 수 없다. 물리적인 교환법은 사용자들이 같은 돈을 두번 쓸 수 없도록 한다. 디지털 기록에 기반한 결제 시스템은 디지털 기록의 복제와 수정이 간단하기 때문에 중복 사용문제를 방지하는 방법을 반드시 가져야 한다.

현대의 뱅킹 시스템에서 사용되는 접근법 (이전의 문서 기반 기록의 컴퓨터화된 복제 기법)은 각 개인이 가지고 있는 돈에 대한 최종적인 기록으로 마스터원장을 관리하는 특별한 주체(일반적으로 은행)에 대한 것이다. 다음에는, 은행들은 하나의 중앙몸체(일반적으로 중앙은행)의 원장에 기록된 계좌를 가지게 된다. 원장은 올바르지 않다고 생각되는 어떤 거래를 방지하는 역할을 한다. 이런 시스템을 사용하기 위해서, 사람들은 이런 중앙집중화된 원장들이 신뢰할만하고, 시의 적절하게, 그리고 정직한 방식으로 관리될 것이라는 믿음을 가져야 한다.

완전히 분산된 결제 시스템(모든 참여자들사이에서 원장의 복사본이 공유되는 환경)을 구현하기 위한 대안적인 접근법과 프로세스는 사용자들이 원장에의 변화(즉, 그 기반위에서 거래가 올바르다는 것)에 동의하는 것에서 출발한다. 누구라도 원장에 대해 처리할 거래를 체크할 수 있기 때문에, 이러한 접근법은 중앙기관의 필요성을 없애고, 그러므로 어떤 한 주체로서 무결성에 자신있는 참여자들의 필요성을 없앴다.

Making payments securely with a distributed ledger
전자결제시스템은 거래가 정확하다는 것을 기록하는데에 신뢰할만한 방법을 가져야함을 
모든 참여자가 동의할 수 있어야 한다.  비트코인과 같은 분산된 시스템에서는, 두가지의 
도전을 만나게 된다. 첫번째는, 안정성을 고안하는 것과 전세계에 분산된 무수한 복사본이 있는
 공개된 원장을 업데이트할 신뢰할만한 방법이다. 두번째는, 리소스를 제공하거나 협력할 
중앙기관없이, 거래를 검증하기 위한 리소스를 사용자가 투입할만한 필요성을 유발하는 것이다.
 이 박스기사는 거래에 대해 주요 단계들을 설명함으로써 비트코인이 어떻게 이러한 도전들을 
극복했는지 설명한다. 핵심개념은 Nakamoto(2008)에 처음으로 약술되었다. 

Step1 - Agreeing the transaction 
앤은 이전에 거래 블록을 성공적으로 검증하였던 비트코인 채굴자이고, 그 보상으로 새로운 
25 비트코인을 받았다. 빌은 온라인에서 가구를 팔고 비트코인을 받는 목수이다. 앤은 서랍장 
하나에 대해 빌에게 1비트코인을 지불하기로 결정했고, 거래 수수료 0.01비트코인을 
지불하기로 했다. 

비트코인 사용은 거래 수수료를 지불하도록 하는 요구조건은 없고, 만일 제공한다면, 그
수수료는 사용자들의 재량에 따르도록 한다. 그러나, 비트코인 채굴자들은 그들이 처리할 
거래를  선택할 수 있어서, 높은 수수료를 제공한다면 그들에게 앤의 거래를 검증하는데 있어
 커다른 인센티브를 주게 된다. 

Step2 - Creating the transaction message
앤은 세가지 기본요소와 함께 메시지를 생성하는데, 비트코인을 얻었던 이전 거래건에 대한 
레퍼런스, 결제할 주소 (빌주소를 포함), 그리고 서로 결제할 비트코인 수량이다. 이 메시지는
 또한 디지털 서명과 앤이 결제단계에 취할 수 있는 어떤 조건과 같은 다른 요소들도 가질 수 있다. 

특정 주소를 가진 비트코인은 검증을 위해 존재하는 블록체인에서 공개적으로 취득할 수 있는
이전 거래건들의 결과물들로부터 파생된다. 이 예에서, 앤의 채굴행위로부터 얻은 25비트코인의
 이전 결과물들이 새로운 거래의 입력으로 들어간다. 비트코인 거래는 여러개의 입력과 결과물
을 가질 수 있다. 앤에 기인한 ‘변경’이 거래의 결과물로 지불되었고, 결과물에서 그 원인이
 되는 입력에 포함된 어떤 증명(credit)이 거래 수수료로 받아들여진다. 

Inputs: 
 * 앤의 25 비트코인 (그녀의 이전 트랜잭션의 결과물)
Outputs:
 * 빌에게줄 1비트코인
 * 앤에게 소속된 23.99비트코인 (트랜잭션에서오는 그녀것의 ‘변경’)
 * 채굴자가 트랜잭션을 성공적으로 검증했을때의 트랜잭션 수수료로서 0.01 비트코인

앤은 결제에서 어떤 조건을 걸 수 있는게 가능하기때문에, 빌은 그들이 만나게 되지 않는 한 
그의 수익을 사용할 수 없다. 대부분의 결제는 어떤 조건을 걸지는 않지만, 더 복잡한 거래
에서는 어떤 자금이 집행되기전에 만나게 되는 여러개의 조건들을 요구할 수도 있다. 
이런 역량은 기술이 더 복잡한 거래를 지원하도록 확장가능하게 한다. 

Step 3 - Signing the transaction message
메시지가 한번 생성되면, 앤은 지불자의 주소를 제어한다고 증명할 수 있게 디지털로 서명한다
. 현실세계의 서명과 유사하게, 디지털 서명은 거래 메시지가 결제를 원하는 사람에 의해 
생성되었음을 증명한다. 

디지털 서명은 공개키 암호화의 형태로 존재한다. 이것은 대칭되는 개인키로 인코딩된 메시지를
 복호화하는데 사용될 수 있는 공개키를 생성함으로써 동작한다. 디지털 서명을 생성하기 위해,
 앤은 개인키로 서명하고자하는 메시지를 암호화한다. 이 메시지는 대응되는 공개키로만 복호화
될 수 있어서 그녀의 거래가 검증될 수 있도록 브로드캐스팅할 수 있다. 공개키 암호화에 대한
 더 많은 정보는 기술 첨부문서에 포함되어 있다. 

Step 4 - Broadcasting the transaction message
앤은 서명된 메시지를 검증을 위해 네트워크상에 브로드캐스팅한다.

비트코인 채굴자는 p-to-p 네트워크에 놓이게되는데 - 중앙집중화된 협력관계 없이 공식적으로
 형성되지 않는 연결 네트워크이다. - 채굴자가 그렇게 해야만 하는 의무는 없음에도 불구하고
, 비트코인 프로토콜은 모든 메시지가 ‘best-efforts’기반하에 네트워크로 전송되어야 하고
, 누군가에게 이웃하는 피어(네트워크 연결된 상대방)에게 메시지가 공유되도록 하고 있다. 
이것은 앤의 거래가 한번에 전체 네트워크로 브로드캐스팅하지 않는 것을 의미하지만, 대신 
먼저 그녀의 피어들중 랜덤한 누군가에게 가고, 그 다음 다시 그들의 피어들에게 가고,
 계속 그런 방식으로 가게 된다. 

P-to-p 네트워크는 일반적으로 수 많은 다른 환경에서 사용자들 사이에 데이터를 빠르고 효과
적으로 공유하는 방법이다. 예를 들면, 어떤 비디오 스트리밍 서비스는 이 기술을 사용하고 있
다. 

Step 5 - Transaction Verfication (‘mining’)
마이너들은 앤의 새로운 거래건을 얻어와서 그것과 다른 사람들것을 새로운 후보 ‘블록들’로 
합성한다. 그리고 나서 그들은 다른 채굴자들과 같은 방식으로 그것들을 검증하여 경쟁한다. 
거래 블록의 검증은 두가지 요소를 가지고 있는데, 유효성검증과 합의이다. 거래 블록의 유효성
검증 - 디지털 서명이 옳은지 확인하는 것을 포함 -은 아주 짧은 시간만 걸릴 뿐이다. 합의를
 이루는 것은 근본적으로 상당히 어려운데, 각 채굴자가 ‘증명작업’으로 알려진 컴퓨팅 자원을
 반드시 투자하도록 하고 있다. 비트코인에서 사용되는 증명작업은 별책부록에 더 자세히 설명
되어있다.

증명작업은 처리하기 어렵도록 하고 있지만, 확인하기에는 단순하다. 이것은 부정행위가 연루된
 거래건을 탐지하기에 매우 쉽도록 만들어서 시스템의 유인동기가 거래건 검증의 호의(보상)에
 따라 균형이 유지되도록 하고 있다. 그 시스템이 공격당할 수 있는 유일한 방법은 부정 거래
를 ‘검증’할 네트워크상의 충분한 컴퓨팅 파워를 모으는 것이다. 이것은 전체적으로 시스템과 
공격자가 훔칠 수 있는 비트코인의 가치에 대한 신뢰를 무너뜨린다. 그러므로, 그 시스템을 공
격하는것 보다는, 그 시스템의 존속을 위해 필요한만큼의 컴퓨팅파워를 모을 수 있는가가 더 이
치에 맞는말이다. 

Step 6- Success
클레어는 채굴자이고, 앤의 거래 블록을 검증하는데 성공하여서, 새로운 비트코인의 보상과 
함께, 앤의 거래건으로부터 거래 수수료를 받을 것이다. 클레어는 이러한 결과를 브로드캐스팅
하고, 다른 채굴자는 자신들이 가지고 있는 블록체인의 복사본의 끝에 그 블록을 추가하고, 
step 5로 되돌아간다. 빌은 그에게 보내진 1비트코인을 받고, 앤에게 서랍장을 보낸다. 
비트코인에서 사용되는 증명 작업은 채굴자가 거래 블록의 검증을 성공적으로 검증하는데 필요한
 시간이 무작위적이라는것을 의미한다. 그러나 네트워크에 새롭게 참여하는 채굴자 혹은 더 
빠른 컴퓨터를 투자한 기존 채굴자들에게, 성공적인 검증에 걸리는 시간은 줄어들 수 있다. 
각 성공에 대한 소식을 전체 네트워크에 알리기 위한 시간을 위해, 증명작업 문제의 
난이도는 주기적으로 조정되어서 블록들 사이의 평균시간은 전체적으로 비트코인에서는 10분정도
로 고정되어 있고 이것은 결제가 즉시 이루어지지 않는다는 것을 의미한다. 

Coinbase transactions 
각 블록에서의 첫번째 거래건은 하나의 특별한 ‘coinbase’ 거래건인데, 채굴자에게 새로운 
비트코인을 보상으로 주고, 그 블록안에서 거래에서 제공받은 거래 수수료를 채굴자에게 지불하
는 거래건이다. 각 코인베이스 거래에 새로운 비트코인을 할당하는 것은 모든 210,000블록마
다 반으로 줄어든다. (평균적으로 블록당 10분정도로 계산해볼때, 대략 4년 정도의 시간이
걸린다.) 현재는 블록당 25비트코인이  할당되고, 2017년쯔음에는 블록당 12.5비트코인이 할당될 것이다. 이러한 화폐 공급 법칙에 대한 이유(그리고 그것과 관련된 이슈)는 별첨문서에
논의될 것이다. 

Orphaned blocks
분산 시스템의 특징은 근본적으로 동시에 다음블록에 대한 두개의 다른 후보블록을 두명의 채굴
자가 성공적으로 검증할 수 있다는 것이다 - 설령 그것이 거의 일어나지 않는다하더라도 말이다
 -. 이런 일이 일어날때, 두 복사본들은 네트워크에서 메인체인의 브랜치로 초창기에 보유하게
 되지만, 채굴자들은 그들이 처음받았던 블록이 어느쪽에서 왔건간에, 후보블록에 대해 작업을
 계속 진행한다. 

가장 큰 완성된 합계를 나타내는 블록체인은 비트코인 네트워크에서 진짜인것으로 받아들여진다
(때로는 가장 긴 체인이라 언급된다.). 어느쪽이든 대다수의 네트워크에서 수용한 브랜치가 
처음에 선택될 것이다. 그러나 대부분의 컴퓨팅 리소스와 함께한 브랜치가 궁극적으로 선두에 
서야 한다. 이 브랜치는 뒤이어 나오는 블록들이 그것의 가장위쪽에 위치하도록 할것이고, 
그러므로 궁극적으로 그 경기를 이길것이다. ‘더 짧은’ 브랜치에 있는 사라지는 블록들을 가진
 채굴자들은 더 긴 브랜치로 교체할 강력한 동기를 가질 것이다. 왜냐면 짧은 브랜치에 투여했
던 그런 작업이 결코 대다수의 네트워크에서 받아들여지지 않을 것이기 때문이다. 

이런 시나리오에서, 버림받은 더 짧은 브랜치에 있던 블록들을 ‘고아’라고 불르고, 아래 
Figure A에서 붉은 색부분으로 보여지는 블록들이다. 고아블록에 있는 트랜잭션은 다시 검증
되어야할 필요가 있을 것이다. 채굴자들은 고아블록에서 보상을 요구할 수 없는데, 이것은 가장
 긴 블록체인의 부분이 아니기때문이다. 
스크린샷 2015-01-16 오후 3.57.45

완료된 가장 큰 합계를 가진 체인이 이긴다는 규칙은 비트코인 네트워크에서 부정행위와 대결하
는 가장 중요한 요소이다. 이전 블록들을 수정하려하는 (그래서 비트코인이 두번 중복으로 사용
될 수 있는)공격자는 그런것을 만회할만큼 충분한 컴퓨팅 파워를 제어할 수 있어서 가장 긴 
순혈의 블록체인을 추월해야할 것이다. 성공을 확정짓기 위해서는, 공격시도자는 네트워크상의 
대부분의 컴퓨팅 자원을 얻고 보유해야 할 필요가 있다. 이러한 이유로, 이러한 공격을 ’50%
+1’ 공격이라고 알려져 있다.

Achieving consensus
분산된 결제 시스템에서 특징적인 것은 원장으로 제출되는 변경(역자 주: 거래?)에 대해 합의가 이루어지는 방식에 관한 것이다. 누가 신뢰할 수 있는지를 누구도 완벽하게 확신할 수 없을때, 네트워크에서 사람들 사이에 합의를 도출하는 방법은 컴퓨터과학 영역에서 오랜 문제로서 인식되어 왔다. 모든 statements(명세서?)에 대해 일괄 승인을 제공하는 것은 충분하지 않은데, 왜냐면 이것이 좀 더 이득을 얻기 위해 속임수를 쓸 유인동기를 만들기 때문이다.

또한, 제출된 변경에 대해 승인할지 말지를 사용자들이 투표를 하도록 하는 것 또한 충분하지 않다. 이것은 투표를 왜곡하기 위해, 컴퓨터 네트워크상에서 한 사람이 많은 노드를 생성하는 것이 상당히 쉽기 때문이다. 대신에 디지털 화폐는 게임이론을 이용하고, 원장에 가해지는 어떠한 변경작업이 ‘cheap talk’ (빈말, 역자주 : 게임이론에서 사용되는 의사결정에 영향을 안주는 커뮤니케이션) – 발행하는데 있어 상당히 자유롭기 때문에, 매우 적은 가중치를 받도록 해야하는 명세서 – 이라고 인지한다. 타인에 의해 실제로 승인될 원장에 대한 변경을 위해, 그러한 변경을 가하는 사람들 – 거래 검증자로서 역할을 하는 ‘채굴자’ – 은  그 제출을 발행하는데 비용이 든다는 것을 입증해야 한다.

암호화폐는 그런 검증절차에 헌신하는 사용자들에게, 암호화된 ‘증명작업’이 제출이 승인되기전에 계산에 시간을 들임으로써 비용을 들였다는 것을 보여주도록 입증할 책임을 지도록 한다. 페이지 7-8에서의 박스와 기술적인 첨언이 이런 증명작업에 대해 더 자세하게 설명하고 있다. 다른 어떤 디지털 화폐는 거래의 일부분으로써 소멸되는 소량의 화폐 형태로 그 비용을 부과한다. 그림 3은 분산된 결제 시스템의 예를 보여주고 있다.

Risk in payment systems
Centralised systems
모든 현존하는 계층화된 결제 시스템에게는 공통적인 리스크들이 존재한다. Finan, Lasaosa와 Sunderland(2013)에 3가지의 가장 큰 리스크를 다음과 같이 정의하였다.
* 신용 리스크 : 결제은행이 시스템상의 다른 회원사들에게 빚지고 있는 상당량의 돈에 대해 지급 불능이 될 수 있다.
* 유동성 리스크 : 기본적으로는 지급불능에 빠지지 않은 회원사은행이 특정 시점에 요구되는 결제에 대해 정산할 수 있는 자금을 갖지 못할 수 있다.
* 운영 리스크 : 결제 거래건에 포함되는 은행중의 하나가 IT 장애와 같은 어떤 이벤트로 인해 임시적 혹은 항구적으로 기능을 중지할 수도 있다.

이러한 리스크는 중개 은행 시스템에도 동일하게 적용된다. 3페이지의 박스에 논의된것처럼, 이러한 구조는 결제가 더 효율적으로 되어야한다는 필요에 따라 진화하였고, 결제 시스템이 컴퓨터화되었을때, 이런 중개 구조가 남게 되었다. – 저런 원천시스템에 존재하는 주요 신용과 유동성 위기도 함께. 시스템적으로 중요한 결제 시스템의 자체적인 규제는 이런 시스템적 리스크를 상당히 줄이거나 없애는 여러가지 측정지표들이 출현했다. 이러한 의사결정 당시, 규제자들은 트레이드오프와 맞딱뜨리게 된다:한편으로는, 시스템적으로 중요한 결제 시스템의 자체적인 규제가 경제에서 리스크와 불확실성을 줄임으로써 결제활동을 촉진시키는 안정적이고 효율적인 결제에 도움이 된다; 그러나 다른 한편으로는, 결제 시스템에서 시스템적 리스크를 줄이는데 필요한 측정지표들은 참여자들이 이러한 리스크를 감당할만한 돈을 보증하도록 하고 있다. 경제이론은 그러한 ‘진입장벽’이 기존멤버들간의 경쟁력을 약화시키고, 그 다음에는 높은 거래 수수료로 나타날 것이고, 경제활동 수준을 약화시킬 것이라고 제시하고 있다. 그러나 기존 결제 시스템 아키텍처에 제한하고 보면, 이러한 요구사항은 영국의 금융 안정성을 더 넓게 보호하기 위해서 필요하다.

중요하지만 일반적으로 시스템적이지 않은다른 위험은 fraud(부정행위)이다. 예를 들면, 인터넷상에서 구매를 하고자하는 신용카드 사용자는 상점에게 신용카드의 상세내용을 노출해야 한다. 만일, 이러한 카드정보가 도용당한다면, 그 절도범은 부정행위를 위해 카드소지자의 계좌에서 결제가 가능하다.

 

Decentralised systems
기존 분산된 결제 시스템은 중개작업을 없앰으로써 위에서 논의한 신용위험과 유동성 위기를 제거한다 : 결제는 지급인과 수취인 사이에 직접적으로 이루어진다. 이것을 검증하기위해, 사용자들은 그들이 사용하는 분산된 시스템에 대한 신뢰가 필요하고, 차용된 암호 기술은 올바르게 구현되어왔다.

일반적으로, 이러한 방식으로 디자인된 분산 시스템들은 전체 시스템이 하나의 중앙집중화된 서드파티에 의존하지 않기때문에 시스템적 운영 리스크에 더 탄력적이다. 분산 시스템은 네트워크에 참여하는 참여자들만큼 많은 여분의 백업을 효과적으로 가지고 있다. (쉽사리 수천이상이 될수도 있고, 전통적으로 운영된 중앙집중화된 결제 시스템보다는 훨씬 많다)

부정 행위에 대한 리스크의 본질 – 그리고 고객이 돈을 잃기 쉬울 수 있는 다른 방법들 – 중앙집중화된 시스템과 분산된 시스템 사이에 상당히 다른점이 있다. 분산 시스템에서는 결제를 진행할때 사용자가 완전히 결제 세부내역을 노출할 필요가 없고, 그러므로 결제 내역이 소매상인으로부터 도난당하는 리스크를 제거한다. 그러나, 디지털화폐의 직접적인 손실에 대한 리스크는 상업은행에 (전자적으로) 예치된 예금보다 높다: 만일 해킹당한 하드 드라이브때문에 사용자의 개인키를 분실했다면, 그들의 디지털 화폐는 복구불가능하다고 말할 수 있다. 이것은 상업은행에서 인터넷뱅킹에 사용되는 비밀번호를 잃어버리는 것과 다른데, 당사자 은행에 연락하여 복구하거나 리셋할 수 있기 때문이다. 이런 관계로, 디지털 지갑은 온라인으로 접근 가능한 은행계좌보다 물리적 화폐를 가지고 있는 물리적 지갑과 비슷하다.

더 실질적으로, 분산된 시스템은 만일 합의를 이루는 프로세스가 손상되었다면, 시스템전체적인 부정행위의 위험에 노출된다. 예를 들면, 암호 화폐체계는 현재 공격의사를 가진 공격자가 채굴자들의 전체 네트워크에 대한 대부분의 컴퓨팅 파워를 지속적으로 제어 해야만 하도록 설계되었다. 한때, 느슨하게 결합된 채굴자연합이 비트코인 네트워크에서 컴퓨팅 파워의 대다수를 차지한 적도 있다. 어떤 연구자는 성공적인 공격을 위한 필수적인 임계점이 50%이하일수 있다고 제시하기도 했다. 이러한 이슈는 첨부문서에 더 깊숙히 다루고 있다.

Applications of the distributed ledger beyond payment systems

새로운 기술의 도입은 이전 기술과 관련 깊은 비지니스 프로세스에 대해 다시금 생각하게 만든다. 결제 케이스에서는, 문서로 된 원장이 처음 컴퓨터화되었을때, 기반 프로세스들은 거의 변화되지 않았다.

새로운 기술의 도입으로부터 얻는 많은 효과들이 즉시 일어나지 않는데, 기술을 사용하는 프로세스들이 재고민될 필요가 있기 때문이다. 예를들면, Brynjolfsson and McAfee(2014)는 전기모터가 공장에 처음 도입되었을때, 생산성 향상이 30년 후에나 일어났다는 것을 발견했다. 이것은 새로운 공장 관리자그룹이 공장에서 모든 기계들에게 동력을 전달하는 하나의 증기기관 대신 전력을 공급하는 것, 그리고 작은 전기모터가 각 기계에 적합할 수 있다고 깨닫는 사람이 될정도의 시간만큼이라는 것이다. 초기 설치가 비용을 줄였던 반면, 공장에서 오는 가장 큰 이득이 기계의 한계치보다는 가장 효율적인 재화의 흐름에 따라 재구성되는 것이라고 창시자들은 주장한다. 이익을 만드는 것을 전력공급 그자체가 아니라 그것을 가능하게 만든 프로세스에서의 변화란 것이다.

비슷한 방식으로, 분산 원장의 잠재적인 영향은 결제 시스템 단독으로보다는 더 광범위하게 이루어질 수 있다. 대다수의 금융 자산 -대출,채권,증권,파생상품과 같은-은 이제 전자적인 형태로만 남아있고, 금융 시스템 그 자체는 이미 디지털기록의 집합이라는 의미로만 남아있다. 이러한 기록들은 현재 계층적 구조(즉, 은행에 집중된 형태로 저장된 개인계좌의 기록과 함께, 중앙 은행에 따로 만들어둔 계좌들)로 남겨져있는데, 미래에는 금융시스템의 기존 인프라스트럭쳐가 다양한 분산 시스템으로 점차적으로 대체될 것(이 글이 이런 관점에서 예측하지 않음에도)이라고, 적어도 이론적으로는 가능할 것이다. 어떤 개발자들은 이미 부가정보를 덧붙임으로써 다른 자산에 대한 토큰으로써 디지털 화폐를 사용한다는 의미로 ’coloured coins’라는 이름의 화폐를 개발했다. 이러한 발전은 어떤 형태의 금융 자산, 예를 들면 회사의 주식과 같은, 이 분산된 원장에 기록되도록 하였다. 분산된 원장 기술은 또한 금이나 은처럼 중앙집중적인 등록이 존재하지 않는 물리적인 자산에도 적용될 수 있다.

어떤 시사해설자(Wenger(2013))는 비트코인을 이해하는 것의 핵심은 인터넷 기저에 깔린 것과 같은 동류의 프로토콜로서 그것을 생각하는 것이다라고 제안하기도 했다. 어떤이들은 이러한 유사점을 더 확장하여, 디지털 화폐가 ‘internet of money’로서 생각될 수 있다고 제안했다. 그러나 근본적으로는 잠재적 적용처가 단순한 결제이상으로 더 확대되었기때문에, 분산원장기술은 아마도 ‘internet of finance’의 첫번째 시도라고 더 잘 묘사될 수 있을것같다.

Conclusion (결론)

최근에 설계된, 디지털 화폐는 위험성과 동시에 좋은점을 가지고 있다. 이 글의 자매글에 설명되어있다시피, 디지털 화폐는 현재 영국에서 화폐 혹은 금융 안정성에 대한 물질적 리스크를 가지고 있진 않지만, 잠재적인 리스크가 오랜시간동안 나타날 수 있음을 생각해볼만 하다. 분산된 원장은 순수한 기술적 혁신인데, 디지털 기록이 어떤 중앙기관 없이도 안전하게 보관될 수 있음을 나타낸다.

디지털 화폐의 총 자본의 양은 금융 안정성에 위협이 되기에는 현재는 너무 적지만, 앞으로 더 증가한다면 배제하지는 못할 것이고, 금융 안정성에 영향을 줄 정도의 잠재력을 가졌던 유동성 디지털 화폐사이에 자산 가격 거품붕괴가 있을 수 있다는 것을 곧 상상할 수 있을 것이다. 화폐안정성에 대한 잠재적인 리스크는 한때나마 디지털 화폐가 경제환경에서 현실적으로 사용되는 것과 같은 것이 될것이다. 만일, 일부의 사람들이 디지털 화폐로 현실세계와 동떨어진(배타적인) 거래를 한다면, 이수요에 대한 은행의 영향력은 잠재적으로 약화될 것이다. 그러나 기존 디지털 화폐체계의 동기는 전방위적인 적용을 하기엔 상당한 수준의 장애물을 만난다. 이것은 자매글에 더 자세히 다뤄져있다.

금융자산을 포함하여 궁극적으로 모든 거래는 기록되어야 하고, 이 기록의 대부분은 디지털이다. 많은 금융 시스템의 구조는 중앙집중화된 서드파티에 저장되어 있는 기록상의 결제와 유사하다. 이런 디지털 정보 플랫폼에 대한 분산 기술의 적용은 광범위하게 연결되어 있는데, 디지털화된 제품을 가진 다른 산업들도 새로운 기술에 의해 새로운 형태를 띠게 된다. 금융 산업에의 분산 원장의 영향은 결제보다 훨씬 더 넓어질 수 있다.

 

Annex (별첨부록)

Technical issues (기술적 이슈)
여기 기술적 별첨부록은 디지털 서명과 암호화된 해쉬펑션에 대해 더 자세히 다룬다. 또한 디지털 화폐가 부정행위에 안전한지도 논의한다.

Digital signatures and pulic-key cryptography(디지털 서명과 공개키 암호화)
디지털 서명은 특정 메시지가 특정인에게 승인되었음을 수학적으로 증명한다. 이것은 공개키 암호화 기법을 사용하고, 두개로 분리되었지만 수학적으로 서로 관계된 키인 개인키와 공개키 기반으로 이루어졌다.

비트코인주소는 공개키의 버전이고, 이것은 광범위하게 사용될 수 있고, 공개될 수도 있다. 주소와 그것의 개인키는 무작위 알파벳 문자열이다. 하나의 주소는 일반적으로 34자리 문자열이고(예를 들면 1FfmbHfnpaZjKFvyi1okTjJJusN455paPH), 반면 개인키는 51자리 글자이다.

각 비트코인 주소는 개인키와 대응되도록 쌍으로 이루어져있어서, 소유자의 주소에 안전하게 보관되고 주소로부터(그러므로 소유권을 증명하는) 거래건을 사인하기 위해 필요하다. 또한, 다수의 개인키와 연결된 주소들을 생성하는 것도 가능하다. 이것은 개인키중 어떤것이라도 하나의 트랜잭션을 사인하기위해 사용될 수 있게끔 셋업될 수 있거나 그 모든것들이 함께 사용되는 형태로 될 수 있다.

Figure A는 비트코인에서 거래를 서명하는 과정을 그리고 있다. 앤은 그녀의 개인키로 거래 복사본을 암호화하고, 거래 상세내용의 평문과 암호화된 버전 모두를 브로드캐스팅한다. 누구라도 앤의 공개키로 암호화된 버전을 결합할 수 있는데, 이는 다른 평문 버전을 얻기 위함이다. 만일 이것이 앤이 브로드캐스팅한 평문버전과 같다면, 앤이 개인키가 사용되었음이 틀림없다는 것을 증명한다.

스크린샷 2015-01-16 오후 4.05.00

 

Cryptographic hash functions and Bitcoins proof of work scheme
메인 글에서 논의했듯이, 비트코인의 채굴자는 그들이 제출한 거래 블록이 네트워크상에서 인정되기전에, 증명 작업을 제출해야한다. 원래대로라면, 계좌잔액을 확인하기위해서는 모든 사용자가 이전의 모든 거래건을 알 필요가 있는데, 이것은 모든 사용자가 거래가 실제로 일어났고, 거기에서 주문중임을 동의한다는 것이 중요해진다. 만일 두 사용자가 다른 거래건의 히스토리를 본다면, 잔액이나 중복사용에 대해서 같은 결론을 이끌어낼 수 없을 것이다. 블록 체인은 모든 이용자가 거래가 이미 일어났고, 거기에서 주문중이라는 관점에서 합의에 이르게 되는 방법으로 동작한다. 비트코인에 있어서, 사용자가 거래의 히스토리셋에 동의하는 방법은 어떤 사용자가 대부분의 작업이 생성되도록 했는지에 대한 히스토리를 선택하는 것이다. 그 ‘작업’은 컴퓨터로서는 완료되기 힘든 일거리지만, 검증하기에는 다른 컴퓨터들은 쉽다.

간단한 예로는, 사람들이 3개의 주사위를 던져 같은것이 나올때까지 반복적으로 굴리는 것이다.  누군가가 이것을 해낼때, 모든 사람들은 사실로 받아들이고, 다음 메시지로 넘어간다. 이것은 trial and error형태로 시간소모적인 일이지만, 성공은 즉시 누구나에게 가시적인 작업이다. 누군가에게 성공적으로 세개의 주사위를 하나로 만들도록 굴리는데 걸리는 시간은 랜덤하지만, 기대값은 알려져 있다. 많은 사람들이 참여할 수록, 각각의 사람들의 시도는 더 빨라지고, 누군가가 성공할때까지의 시간은 더 짧아진다. 이것을 상쇄하기 위해, 각 사람들이 4개의 주사위를 던지고, 4개를 하나의 숫자로 만들도록 요구할수도 있다. 더 많은 사람들이 참여했을때, 문제를 더 어렵게 만듬으로써 세밀하게 조정하여, 누군가가 성공하는데 걸리는 평균 시간은 대략적으로 항상 일정한 수준으로 만들 수 있다.

비트코인에서 사용되는 증명 작업은 cryptographic hash function이라는 특별한 알고리즘을 사용하는데, 이것은 입력값으로 일정량의 정보를 취하고, 표준길이를 가진 출력값 (hash value)를 생성해낸다. 생성된 해쉬값이 입력값(1개의 문자일지라도)이 변하면 다르기때문에 그 함수는 암호화된 것이라 하고, 주어진 입력값에 대해 해쉬값이 어떻게 생성될지 미리 알기는 거의 불가능하다. 예를들면, 비트코인에서 사용되는 SHA-256 해쉬함수는 다음과 같이 생성한다.
스크린샷 2015-01-16 오후 4.05.08
비트코인 프로토콜은 채굴자가 세개의 입력값을 조합하고, SHA-256해쉬함수에 그것을 넣도록 한다.

  • 이전 블록의 참조값
  • 거래건의 후보블록의 상세내용
  • nonce라고하는 특별한 숫자값

만일 생성된 해쉬값이 특정 입계값보다 낮으면, 증명 작업은 완료된다. 만일 그렇지 않으면, 채굴자는 nonce에 다른 값을 넣어 재시도 해야한다. 거기에는 nonce에 대해 무슨값이 들어가는지 말해주는 방법이 없기때문에, 다른 두개의 입력값과 조합될때, 충분한 해쉬값을 생성해낼 것이고, 채굴자는 nonce값에 대해 trial and error방법으로 단순한 사이클을 돌게 된다. (그림 B)

스크린샷 2015-01-16 오후 4.05.30

Are digital currencies fraud-proof? (디지털 화폐는 부정행위에 안전한가?)
디지털 화폐의 현재의 디자인은 부정행위 – 잘못된 거래건의 생성 -가 에이전트, 혹은 에이전트의 연합에 의해서만 가능하다고 가정하고 있고, 이는 일정시간 동안 채굴 네트워크상에 컴퓨팅 리소스의 대부분을 제어해야만 가능하다고 한다 (50% + 1 attack). 그러나, 많은 연구진들은 엄밀히 대다수의 컴퓨팅 파워보다는 더 적게 가지면서도 그러한 부정행위가 가능할 수 있다고 제시하고 있다. 잠재적인 취약점은 두가지의 핵심 영역으로 구별되는데 (1) 네트워크상의 공격자의 위치; 와 (2) 공격자가 남은 네트워크에 메시지를 뿌릴때의 전략적인 타이밍이다.

이러한 취약점을 평가하기 위해, 검증 네트워크의 간단한 예를 잘 생각해보는게 도움이 된다. 그림 C는 하나의 예를 보여준다. 개인 채굴자들은 p-to-p 네트워크에 있고, 그들 각각은 전체 컴퓨팅 파워의 일부 영역을 담당하고 있다. Clare가 네트워크상의 컴퓨팅 리소스중 가장 작은 영역을 담당하고 있음에도 불구하고, 그녀는 상당히 네트워크상에서 ‘중심’적인데, 그녀가 즉시 합쳐서 과반이 되는 다른 노들들과 연결되어 있기 때문이다.
스크린샷 2015-01-16 오후 4.05.35

네트워크상에서 공격자의 위치는 중요한데, 디지털 화폐 네트워크상에 메시지가 전파되는 시간이 길어질수록, 블록체인에서 fork(비슷한 시간에 성공적으로 검증된 다음블록에 대한 2개의 후보블록)가 발생할 확률이 높아지기 때문이다. 네트워크상에 중심에 위치한 가상의 공격자는 (Clare같은) 네트워크상의 대부분의 노드와 매우 빠르게 통신할 수 있을 것이고, 만일 다른 사용자 (David같은)가 비교적 상당히 멀리있다면 다수표를 엄격히 요구하지는 않을 것이다. 더 일반적으로, 중심위치에 있는 정직한 사용자들조차 같은 이유로 일정 시간동안 전체 결제중 네트워크상의 컴퓨팅파워에 대한 공헌도를 초과하는 몫을 얻는 것으로 기대될 수 있을 것이다.

채굴자들에게는 거래 블록들을 검증하는 절차에서 성공을 브로드캐스팅할때 전략적으로 시간대를 선택할만한 유인동기가 존재한다. 예를 들면, Bill이 후보블록 N을 성공적으로 검증할때를 가정해보면, 그는 그 성공을 즉시 외부로 드러내지는 않는다. 대신에 그는 블록 N+1의 검증을 시작할것이고, 잠깐의 지연 이후에 네트워크의 나머지에게 그의 성공을 알리게 된다. Bill의 전략은 다른 채굴자들이 그들의 가지고 있는 블록 N에 대한 후보군들의 검증을 시도할 수 있는, 여분의 시간을 소비하도록 할 것이고, Bill에게 다음블록을 검증을 시도할 첫번째 자리를 가지게 할 것이다. 시간이 지나면, Bill의 전체 결제에 대한 몫은 평균적으로, 그의 전체 컴퓨팅파워를 제공한 것에 대한 몫을 초과할 것이다.

채굴은 제로섬 게임 – 한 채굴자에 대한 초과수익은 타인의 비용에서 와야한다 – 이므로, 때로는 한 채굴자가 초과된 규모의 보상을 받을때, 이것이 다른 채굴자가 낙오하거나 pool에 첫번째로 참여할 유발요인이 되어서 결국엔 네트워크상의 컴퓨팅 리소스의 과반을 컨트롤하는 풀을 이끌게 되는 (시스템이 부정행위의 리스크를 초과하게되는) 이라고 논쟁이 일어나기도 한다. 이러한 현상의 완벽한 분석은 아직 완전하지 않지만, 최근 연구들은 디지털화폐 네트워크상에 부정행위 방지에 관련된 유인동기가 완전히 탐구되진 않았다는 것을 설명할만큼은 충분하다.

 

Fin Tech 현황과 전망

Tags

, , ,

핀테크 산업의 현황과 전망을 개인적으로 정리해봅니다.

한창 해외에서 핀테크가 유해하고 있지만, 국내에서는 이제 걸음마 단계로 보입니다. 금융 규제로 인해 핀테크 스타트업들이 나올 수 없는 구조라고 얘기들을 합니다.  ( http://www.asiae.co.kr/news/view.htm?idxno=2014122718254191772 참조)

예를 들면, 페이게이트의 사건과 같은 것이죠.

http://www.iamday.net/apps/article/talk/2674/view.iamday

다행인지 모르겠으나.. 높으신 분이 천송이 코드 발언으로 금융 규제에 대한 문제가 부상하게 되었고, 그로인해 급물살을 타면서 국내에도 그 길이 열리고 있는것 같습니다

그전에도 금융과 IT를 결합하여 각 은행이 뱅크월렛이나 각 카드사의 앱카드 형태로 진행되었지만, 사실상 실패했죠.

최근 다음카카오의 카카오페이, 뱅크월렛 for 카카오로 핀테크가 급물살을 타기 시작했고, 각 PG사에서도 간편 결제를 지원하고, 스타트업들도 열심히 달리고 있네요🙂  NHN의 라인페이도 있죠(해외 신용카드가 있어야하는게 함정! 대부분 visa나 master 카드가 있어서 문제는 없죠. )

이런 기사들도 눈에 띕니다.

http://besuccess.com/2014/10/startupalliance_fintech/

금융사에서도 보고서들이 나오네요 .

https://www.kbfg.com/kbresearch/index.do?alias=vitamin&viewFunc=default_details&categoryId=3&menuId=&boardId=&rBoardId=307&articleId=1002782&sTxt=&sType=&pageNo=1

http://www.wfri.re.kr/client/PublishHp.do?command=view&list_dis_txt=PUB&isu_frq=PG00122&isu_kd=PG01122&isu_dis=PG21122&list_unq_no=RP00000001474&topMenuNo=H20000&leftMenuNo=H20200&leftSubMenuNo=H20201

스타트업중에서 눈에 띄는 곳은 비바버블리카에서 나온 간편송금 서비스인 Toss ( https://toss.im/ ) , 비트코인 서비스를 제공하는 Korbit ( https://www.korbit.co.kr/ ) 정도를 보고 있고, 크라우드 펀딩이나 소액 대출 서비스도 있습니다.

그러나 아직 갈길이 굉장히 멉니다. 해외에서는 페이팔, 애플 페이, 중국의 알리바바와 같은 굉장히 거대한 업체들의 서비스가 있고, 다양한 금융 분야에서 스타트업들이 성행하고 있고, 국내 금융시장은 정부의 보호(?)아래 변화가 많지 않았다고 보니까요.

그러나 해외서비스가 국내에 상륙하면 어떻게 될까?라는 금융과 IT업계의 걱정에 대해서는 개인적으로는 크게 걱정은 하지 않습니다. 진입장벽에 비해 시장이 작지 않나?라는 생각때문이죠.

그것보다는 국내 컴퓨팅 환경이, PC에서 이제 모바일로 많이 옮겨간 시점에서 이 분야의 변화와 발전없이 가기엔 비용과 불편함이 상당할 것으로 봅니다. 금융환경은 다른 산업의 인프라 성격이죠. 인프라가 탄탄하지 않았을 경우, 그 발전은 더딜 수 밖에 없습니다.

과거는 은행,증권,카드사가 인프라로 동작하면서 사용자와의 접점을 가지는 주요 플레이어였다면, 이제는 핀테크기업이 사용자와 기존 금융사 사이에서 매개체 역할을 하다, 일정기간이 지나면 금융사는 사용자와의 접점을 잃게 되고, 주요 플레이어로서의 지위가 약해지면서 핀테크 기업이 그 역할을 하게 되지 않을까 생각해봅니다.

메인프레임에서 PC, PC에서 웹, 웹에서 모바일과 SNS로의 변화를 생각해보면 그 중심에 있던 기업이 점점 달라졌었죠. (IBM->MS->Google->Facebook 정도가 되려나요.)  핀테크도 이런 큰 변화의 물결에 있는건 아닐까 생각해봅니다.