ZeroMQ를 이용한 분산형 구조.

GHTS 2015. 3. 10. 16:01 Posted by 정직한 UnHa Kim

Go언어의 고루틴(goroutine), 채널(channel)은 처음에는 거의 완벽한 동시처리 모델로 보인다.

그러나, Go언어는 같은 메모리 공간에서 여러 고루틴(goroutine)들을 실행하며, 고루틴끼리 서로 완벽하게 메모리를 분리하지는 못한다.

그리고, 채널은 락(Lock)보다 성능이 낮다보니, 프로그래머들은 채널 대신 락을 통해서 메모리를 공유하고자 하는 유혹을 계속 받게 되며, 그로 인해서, 고루틴 간의 채널을 통한 메시지 전송으로 안전한 동시처리를 하겠다는 아이디어는 너무나도 손쉽게 기존의 멀티스레딩 방식의 락을 통해 공유되는 메모리 모델로 되돌아간다.

 

멀티스레드 방식의 공유 메모리 모델이 뭐가 문제인지는 마이크로소프트가 발행한 "멀티스레딩 코드에서 발생하기 쉬운 11가지 문제점" (https://msdn.microsoft.com/en-us/magazine/cc817398.aspx)을 참조하시라.

(여러분이 사용하는 윈도우와 오피스를 개발한 그 마이크로소프트가 맞다.)

MS윈도우에서 실행되는 각종 서버 프로그램을 제작하면서, 성능을 높이기 위해서 멀티스레딩 방식의 공유 메모리 모델을 기반을 채택했던 마이크로소프트 사는 그 과정에서 메모리 공유로 인해서 생기는 문제를 혹독하게 겪고 나서, 위의 글을 배포하기에 이른다.

즉, MS조차도 문제가 많다고 인정한 것이 멀티스레딩의 메모리 공유 모델이다.

 

메모리가 완벽하게 분리되는 모델이 이렇게도 구현하기 힘든 것일까?

아니다. 운영체제 프로세스는 아주 오래 전부터 서로 독립된 메모리 공간을 가진 채 동시에 실행되었다.

(MS-DOS에는 프로세스 간 메모리 분리 기능이 없었고, 도스(DOS)에 기반을 둔 윈도우 3.1, 윈도우 95, 윈도우 98 시절에는 메모리 겹쳐쓰기 문제로 블루스크린과 함께 컴퓨터가 자주 다운되었다.

윈도우NT, 윈도우 2000 내지 윈도우XP부터 프로세스끼리 메모리가 완벽하게 분리되었으며, 이후로는 MS윈도우의 안정성이 눈에 띄게 좋아졌다.)

이렇게 좋은 독립 메모리 프로세스 모델을 놔 두고, 왜 그 골치아픈 메모리 공유형 멀티스레딩 모델이 대세가 된 것인지는 잘 모르겠다. (아마도 성능 차이 때문인듯..)

 

어쨋건 간에 여러 운영체제 프로세스가 서로 분리된 메모리 공간에서 서로 메시지를 주고 받으면서 함께 작동하는 모델... 태고적부터 존재했던 멀티프로세스 모델... 이것이 바로 진정한 액터모델이자 CSP모델이다.

이러한 형태 하에서, 모든 실행단위는 메모리가 완벽하게 분리되며, 당연하게도 멀티스레딩의 메모리 공유로 인한 각종 문제가 원천적으로 봉쇄되며, 예전처럼 순차적 실행을 가정하여  프로그램을 짜더라도, 각 실행단위들은 독립적으로 동시에 실행되면서 멀티코어 CPU의 능력을 모두 활용할 수 있다.

분리된 메모리 공간의 안정성, 손쉬운 순차적 프로그래밍, 멀티코어 CPU의 모든 능력 활용등을 모두 실현할 수 있는 데, 왜 다들 멀티 프로세스 모델을 태고적 구식모델이라고 생각하면서 꺼리는 것일까?

(요즘은 컴퓨터가 너무 좋아져서 멀티 프로세스 모델로 인한 성능 저하가 아직도 문제가 되는 지 의문이다.)

 

어쨋든 간에 프로세스 간에는 메모리가 너무 완벽하게 분리되어 있다보니, 서로 메시지를 주고 받을려면 IPC(Inter-Process Communication : 프로세스 간 통신)이라는 것을 사용해야 한다고 한다.

그런데, 유닉스와 윈도우 간에도 IPC 규격이 다르고, 호환이 안 된다.

요즘은 모든 컴퓨터끼리 인터넷의 TCP/IP으로 정보를 주고받는 게 너무 당연시 하는 세상이다 보니, IPC도 인터넷의  TCP/IP 소켓 방식으로 하는 게 자연스러워 보여졌고, 이것을 중앙집중형 서버에서 맡아서 해 주는 게 메시지큐(현재 국제표준은 AMQP 1.0)이며, 이후  정보교환 기능을 개별 실행단위에게까지 분산(하였지만 간편하게)한 것이 오늘의 주제인 ZeroMQ이다.

그로 인해서, 이제는 동시처리 프로그램을 짜기 손쉬워졌을 뿐만 아니라, 일부 실행단위를 아예 다른 컴퓨터로 이동시켜서 분산형 시스템을 만들기도 쉽게 되었다.

어쩌면 한참 입에 오르내리다가 조용히 사라진 SOAP(서비스 기반 아키텍쳐)의 진정한 후계자는 REST(단순 웹기반 서비스)가 아니라 ZeroMQ일지도 모른다.

어쨋든, 요즘 ZeroMQ가 각광을 받는 게 다들 멀티스레드의 메모리 공유모델에 넌덜머리가 나서이지 않을까 싶다.

 

ZeroMQ(혹은 그 후속작인 nanomsg)을 사용하면 동시처리 프로그램을 안전하고 간편하게 짤 수 있는 것 이외에도 생각하지 못한 장점들이 있다.

 

1. 필요에 따라서 다른 프로그래밍 언어들을 섞어서 쓸 수 있다.

- 주식 API의 예제코드를 그대로 복사해서 붙여넣기 한 후, 획득한 정보를 ZeroMQ를 통해서 다른 모듈에 전송해 주면 된다.

- 매매전략의 통계처리는 간편한 R이나 Python으로 하거나, 그 외 시스템 트레이딩 서적에 나온 예제 코드에 ZeroMQ 메시지 전송기능을 추가해서 그대로 시뮬레이션에 돌려볼 수 있게 된다.

- 처음에는 친숙히고 편한 프로그래밍 언어로 개발하고, 나중에 성능이 문제시 되는 부분만 분리하여 좀 더 어렵지만, 성능이 뛰어난 프로그래밍 언어로 다시 개발해서 교체해 나가면, 장기간 안정적인 발전이 가능해진다.

 

2. 서로 다른 저작권 형태의 소스코드를 섞어서 쓸 수 있다.

- 모두가 공유하는 소스코드는 GPL로 의무적으로 공개하도록 하여서, 소스코드를 공개하는 사람만 착취당하는 '죄수의 딜레마'와 같은 모순을 제거하여서 모두가 협력하여 개선할 수 있도록 유도한다.

- 각자 자기만의 매매전략은 타인에게 공개되는 순간 수익성이 사라지는 특징이 있다.

  (모든 전략은 수용한계(capacity)가 있으며 이를 넘어서면 수익성이 사라진다.)

이렇게 공개되면 안 되는 부분은 상업용 라이센스 모델을 채택하여야 하며, 이러한 비공개 상업용 소스코드와 GPL에 따른 의무적으로 공개해야 하는 소스코드 간에 서로 메시지를 주고 받으면서 하나의 시스템으로 구성하여 배포하되, 각 소스코드는 서로 다른 라이센스를 채택하는 것이 가능해진다.

 

 

즉, 프로그래밍 언어의 제한, 소스코드 라이센트의 제한에서 자유로워진다.

그간 Go언어로 개발해 오다가 독립된 메모리를 보장하는 방법을 고민하다가, 메모리에 안전한 Rust 언어도 만지작 거려보다가 결국은 ZeroMQ에서 답을 찾았다.

이제 슬슬 개발을 다시 시작해야 할 듯 하다.        

'GHTS' 카테고리의 다른 글

Xing API에 숨겨진 지뢰 3  (0) 2018.06.07
Xing API에 숨겨진 지뢰 2  (0) 2018.06.07
Xing API에 숨겨진 지뢰 1  (0) 2018.06.07
ZeroMQ에서 nanomsg로 이전.  (0) 2016.11.02
NH OpenAPI 사용기  (0) 2015.09.09
ZeroMQ를 이용한 분산형 구조.  (0) 2015.03.10

댓글을 달아 주세요

프로그램 매매의 기본 가정과 한계

기타 2014. 11. 24. 21:04 Posted by 정직한 UnHa Kim

일반인에게 프로그램 매매란 뭔가 복잡하고 오묘한 것이라는 인상을 준다.

물론, (원한다면 그리고 능력이 된다면) 복잡하고 오묘한 프로그램을 만들 수도 있다.

그러나, 프로그램 매매의 밑바탕에 깔려 있는 기본 가정(assumption)은 아주 단순하다.


1. 가격변동에는 추세라는 것이 존재한다.

2. 일단 형성된 추세는 상당 기간 지속된다.

3. 끝


'프로그램 매매'라는 거창한 제목에 걸맞지 않게 허무하도록 간단하지만 이게 전부이다.

추세를 포착하는 방법, 추세의 변화에 따른 대응하는 방법등에 있어서는 다양한 기법이 존재할 수 있겠으나 기본적으로는 이것이 기본적인 바탕으로 깔고 있다.


흔히 사용되는 매매 전략은 크게 3가지로 나눌 수 있는 데,


1. 추세 추종형.

2. 매입 - 매도 혼합형.

3. 기타 고급 기법 (자연어 인식, 신경망 인공지능등 정말로 복잡하고 오묘하고 창조적인 전략들..)


글을 쓰고 있는 본인을 포함한 일반인 수준에서는 3번 항목의 고급 기법을 구현하는 것은 쉽지 않으며, 대부분 1, 2번 항목에 해당되는 매매 전략을 쓰게된다.


추세추종형은 그야말로 가격이  상승하거나 하락하는 추세를 포착하고, 상승하는 추세의 종목은 매입하고, 하락하는 추세의 종목은 (공)매도 하면서 추세에 올라타는 전략이다.

즉, 비싸지면 사고, 싸지면 파는 전략.


매입 - 매도 혼합형은 둘 이상의 복수의 종목 간에 일정하게 유지되는 관계를 포착해서, 그 관계에서 벗어날 때, 그 차액(스프레드)를 취하는 전략이다.


간단한 전략을 예를 들어 설명하면,

a. 같은 업종에 속하는 종목끼리는 같은 호황 및 불황의 주기를 겪는다고 가정하고,

b. 각 업체별로 평균 순이익률은 일정하게 유지된다고 가정하면,

c. 장기적으로 볼 때 '순이익률 = 자본 증가율 = 주가 상승율' 간에 비례관계가 있으므로, 주식가격에 로그함수를 취한 결과는 선형 비례관계를 가지게 된다.

d. 이러한 선형 비례관계를 넘어서서 상승하면 과대평가 되었다고 판단하고, 이 비례관계를 밑돌면 과소평가 되었다고 판단하며, 그에 따라 과대평가된 종목은 (공)매도하고, 과소평가된 종목을 매입한다.

즉, 싸게 사서, 비싸게 파는 전략.


(참고로 위에서 나온 수학 개념은 모두 고등학교 교과과정에 들어있다.

선형 방정식은 1차 직선, 2차 곡선등 수학에서 가장 다루기 쉬운 개념 중 하나이며, 요즘은 인간이 공식만 넣어주면 컴퓨터가 알아서 풀어준다.

모든 수익률, 성장률, 이자율은 지수 함수로 표현할 수 있으며, 로그 함수는 이러한 지수 함수를 다루기 간편한 선형 방정식으로 변환해 주는 기능을 한다.

그 외 삼각함수 등 모든 비선형 방정식(선형 방정식이 아닌 모든 것)은 고등학교 때 배운 테일러 급수를 사용하면 선형 방정식으로 변환할 수 있다.


경제학을 포함한 인문계열 출신이 수학이 약함에도 불구하고 프로그램 매매를 할 수 있는 이유.


인문계열 전공자는 수학이 약하지만, 인간에 대한 이해와 통찰력이 있고,

이과계열 전공자는 수학이 강하지만, 단순, 무식, 기계적이라 인간에 대한 이해가 부족하므로,

각 전공마다 일장일단이 있다.)



얼핏 보면, 추세추종형 전략과 매입-매도 혼합형 전략은 서로 반대처럼 보이지만, 둘 다 추세의 지속성과 일관성을 가정한다는 점에서 동일하다.


예를 들어서, 상한가 종목을 매입하는 추세 추종형 전략이 존재한다면, 해당 종목의 상승세가 지속성과 일관성을 가진다는 가정을 기반으로 하는 것이다.


앞서 예로 든 매입-매도 혼합형 전략의 예에서는

- 같은 업종끼리는 비슷한 가격변화를 보이고

- 각 기업의 순이익률이 변하지 않는다는

추세의 지속성과 일관성을 가정을 하는 것이다.


그러나, 이 세상에 영원하거나 변하지 않는 것은 없으며, 모든 추세는 필연적으로 변하고, 꺾이는 시점이 오기 마련이다.

추세가 꺾이거나 변화하면 그에 기반을 둔 전략은 더 이상 수익을 내지 못하며, 오히려 손실이 발생한다.

이것은 추세 추종형, 매입-매도 혼합형 모두 마찬가지이다.
이럴 때, 손실을 최소화 하는 것이 위험관리 전략이다.


투자수익이라는 것이 수익금액과 손실금액의 합산이므로, 수익을 내는 매매 전략 못지 않게, 추세가 변할 때 손실을 최소화하는 위험관리 전략도 중요하다.


이 위험관리 전략이 프로그램 매매에 있어서 장점이자 약점이다.

장점으로는 칼같은 손절매 수행이 되겠으며, 약점으로는 종합적인 판단력이 없어서 예상치 못한 상황에 제대로 대처를 못한다는 점이다.


좀 더 자세하게 부연설명 하자면...


프로그램 매매의 가장 큰 장점은 오작동이 적다는 것이다.

'인간의 두뇌'라는 슈퍼컴퓨터는

- 진화 초기 단계에 생성된 생존, 본능, 감정등 무의식을 주관하는 부분

- 진화 마지막 단계에 생성된 이성적인 사고를 주관하는 부분(대뇌피질)

으로 나뉘어진다.


인간은 위급한 상황이 되거나 강한 감정적 압박을 받으면 이성적인 사고를 주관하는 부분에서 나오는 전기적 신호가 차단되고, 무의식을 주관하는 부분만 작동하게 되는 데, 이것은 '인간의 두뇌'라는 슈퍼컴퓨터가 사고력과 판단력이 마비된 채 '오작동'을 일으킨다는 의미이다.

즉, 주식 가격의 변동에 희비가 엇갈리면서 탐욕, 흥분, 공포에 직면하면 이성적 사고력과 판단력이 마비되어서 정상적인 작동을 할 때 세워둔 원칙을 일관되게 수행하기 어렵다.

알기 쉽게 설명하자면, 알코올은 대표적인 중추 신경 마비 물질이다.

술을 마시면 중추 신경이 마비되어, 대뇌피질의 전기신호가 차단되고, 사고력과 판단력이 마비된다.

술에 취한 인간의 행동 양상을 관찰하면, 인간이 강력한 감정(탐욕, 흥분, 분노, 공포 등)의 순간에 이성적 사고력, 판단력이 마비된 채 어떤 식으로 행동할 지 추정해 볼 수 있다.

즉, 주식시장에서 급등, 폭락 상황 하에서 탐욕과 공포에 맞닥뜨린 인간은 술 취한 상태 정도의 판단력과 사고력만 가진 채 매매를 하게 된다는 의미이다.

술 깨고 나면 자기가 왜 그랬는 지 모르듯이, 탐욕과 공포에서 벗어나고 나면 자기가 왜 그랬는 지 후회하는 것도 마찬가지이다.

이에 반해, 컴퓨터는 이러한 오작동을 하지 않고, 인간의 두뇌라는 슈퍼컴퓨터가 정상적으로 작동할 때 세워둔 규칙을 일관되게 수행할 수 있다.


이에 반해, 프로그램 매매의 가장 큰 단점은 종합적인 판단력이 없다는 것이다.

이 세상에 영원한 것은 없고, 변화하지 않는 것은 없듯이, 모든 추세는 변하거나 꺾이기 마련이고, 전략의 기본 가정은 깨어지기 마련인데, 컴퓨터는 종합적인 판단력이 없으므로 예상치 못한 상황에 적절하게 대처할 수 없다.

이러한 위험성은 수학과 컴퓨터에 대한 과신, 맹신이 더해지면 더욱 악화된다.


주식시장 가격폭락 기록을 보면 단기폭락 사태는 10년에 한 번 꼴로 발생하며, 대공황, 서브프라임 모기지 사태 같은 대폭락 사태는 100년에 한 번 꼴로 발생한다.

http://en.wikipedia.org/wiki/List_of_stock_market_crashes_and_bear_markets

박경철이 지은 '시골의사의 주식투자란 무엇인가'라는 책 1권 '통찰편'을 보면, 이러한 폭락사태에 대한 자세한 분석이 나온다. (강력 추천!)

통계학에서는 10년 혹은 100년에 한 번 꼴로 발생하는 폭락사태를 예외적인 현상(outlier)으로 분류한다.

하지만, 인간의 공포는 탐욕보다 3배나 더 강하므로, 가격상승 추진력에 비해서 가격하락의 추진력이 3배나 더 강하며, 이러한 공포에 대한 인간의 반응 패턴이 변하지 않는 이상, 가격폭락 사태는 주식시장에 내재된 본질적 속성이기에, 이러한 가격폭락 사태를 예외적인 상황으로 취급하는 통계학에 기반을 둔 위험관리 전략에는 근본적인 오류가 있으며, 결정적인 순간에 위험을 과소평가하여 손실을 키운다고 진단한다.

VAR을 비롯한 통계학에 바탕을 둔 위험관리 모델을 기반으로 승승장구 하던 미국 금융업은 2007년 서브프라임 모기지 사태 때 확률에서 벗어나는 상황이 발생하자 엄청난 손실을 입고 전멸할 뻔 했다.

미국 금융업의 전멸을 막으려고, 미국 연방정부의 재정지출로 금융업의 손실을 대신 메꾸어 주었는 데, 그  당시 재정지출 금액이 역대 미국 재정지출을 합한 금액보다 더 컸다고 한다.

즉, 오바마 대통령 1명이 쓴 돈이 미국 역대 모든 대통령이 쓴 돈의 합계보다 더 컸다는 의미.

(재정지출 금액 이라고 기억하고 있음. 혹시, 재정지출이 아니고 재정적자 금액이라면 지적 바람.)


그 결과 미국이라는 大제국은 군사력까지 영향을 받아서, 중동에서 철수하고, 동북아시아 방위도 과거 패전국인 일본의 도움을 받아야 되는 상황에까지 내몰리게 되었다.

이것을 보면 통게학과 컴퓨터에 기반을 둔 위험관리 전략에 대한 과신과 맹신이 대제국도 감당하기 버거울 정도로 심각한 결과를 초래할 수 있다는 것을 알 수 있다.


물론, 1929년 대공황은 증시폭락이 원인이고, 2007년 서브프라임 모기지 사태는 부동산 폭락이 원인이므로 통계학에 기반을 둔 위험관리 모델 탓만 할 수 없다고 볼 수 있는 면도 있으나,

1. 부동산 폭락이 CDO(부동산 담보 채권), CDS(부동산 담보 채권에 대한 보험)을 통해서 증폭된 것은 CDO, CDS 모두 통계학에 기반을 둔 위험관리 모델을 사용해서 수익률과 가격이 책정되었고, 그 모델의 시뮬레이션 데이터에는 부동산 폭락 데이터가 포함되어 있지 않았으므로, 예상치 못한 상황이 닥치자 컴퓨터가 제대로 대처하지 못한 것은 마찬가지임.

2. 부동산과 관련이 없어보이는 주식시장 쪽도 통계학에 기반을 둔 위험위험관리 모델만 믿고 엄청나게 높은 레버리지(혹은 부채비율)를 부담하면서 투자규모를 늘리다가 손실이 커진 것은 분명하고, 컴퓨터의 뒤늦은 칼 같은 손절매가 역으로 대폭락과 미국 금융업 전멸 직전의 위기로 내 몬 것도 분명하다.

3. 미국 경제의 문제점을 통찰력으로 인지하고, 미리 대비한 금융기업들은 멀쩡했으므로, 인간의 두뇌 라는 슈퍼컴퓨터가 종합적인 판단력으로 위험에 더 잘 대처할 수 있다는 것도 분명하다.


수학을 자신의 아이디어를 표현하는 언어로, 컴퓨터를 수학적 표현된 아이디어를 수행할 도구로만  사용하고, 추세는 변화하기 마련이며, 확률에서 벗어난 상황은 발생하기 마련이라는 것을 잊지 말아야 한다.

그리고, 수학과 컴퓨터에 올인하기보다는, 인간의 종합적 판단력과 통찰력에 대한 믿음을 유지해야 한다.


마지막으로 박경철의 저서에 나온 2가지 내용을 언급하고자 한다.


1. 시골의사의 부자경제학 제 1장 1절

'부자의 기준은 무엇인가?'에 대한 내용에서

집도 절도 없이 동굴에서 생활하는 수도승일지라도 재산 증식에 욕심이 없으면 부자이고,

평생 다 못 쓸 재산을 가진 재벌 회장이라도 재산 증식에 욕심이 있으면 부자가 아니라는 내용이 있다.

이 내용을 굳이1장 1절에 넣은 것은 우연이 아니라고 느껴진다.


2. 주식투자란 무엇인가? 1권 통찰편 제 1장 1절.

'정직한 시장이란 없다'라는 내용에서 언론, 애널리스트, 펀드매니저, 상담원등 권위있는 개체들의 말을 액면 그대로 믿거나 흔들리지 말고, 자기자신의 판단력과 통찰력을 활용해라는 내용임.

프로그램 매매는 자기 자신의 통찰력, 데이터 분석력을 활용해서 매매전략, 위험관리 전략을 만들고, 이를 일관되게 수행하는 기법이므로, 이 내용에 부합하는 면이 있다.


단, 해당 저서의 내용 중에 '수학 방정식으로 시장을 표현할 수 없다'는 내용도 있으니, 프로그램 매매에 대한 과신과 맹신은 금물이라는 내용도 그만큼 중요함.

'기타' 카테고리의 다른 글

올바른 수익률 계산법  (0) 2015.11.21
프로그램 매매의 기본 가정과 한계  (0) 2014.11.24

댓글을 달아 주세요

Go언어 소개

프로그래밍 2014. 11. 4. 20:55 Posted by 정직한 UnHa Kim

Go언어는 효율성을 추구하는 실용적인 프로그래밍 언어이다.

1. 개발 생산성

2. 멀티코어 CPU 하드웨어 사용의 효율성

2가지를 모두 추구하는 대신 기능성은 포기했다.


Go언어의 창시자는 C++언어의 복잡성에 학을 떼고, 

공개적으로 미니멀리즘을 추구한다고 하는 데,

어쩔 때는 그게 좀 과한 듯 하다.

(키워드 숫자를 줄이려고 interface가 가변형 자료형을 겸하는 것은 조금 오버이고,

 에러처리도 if문으로 처리한다는 것은 소스코드를 번잡하게 만든다.) 


개발자 생산성 향상을 위해서는 다음 특징을 가진다.

1. 빠른 컴파일.

2. 단순하지만 필수기능은 다 갖춘 문법.

3. 자동 메모리 관리

4. 유니코드 지원

5. 풍부한 표준 라이브러리 및 수많은 제3자 공개 라이브러리.

6 테스트, 테스트 커버리지, 동시 사용 데이터 충돌(레이스) 감지등 풍부 개발 도구 기본 내장


마지막으로...

7. 소스코드 자동 정리 (써보면 입이 떡 벌어진다.)



하드웨어의 효율적 사용을 위해서 다음 특징을 가진다.

1. AOT 컴파일. (C, C++의 컴파일 개념. Java나 C#이 사용하는 JIT컴파일의 반대 개념.)

2. C보다 2배 정도 느리고, Java와는 비슷한 단일 스레드 실행 속도.

3. 멀티코어 CPU를 안전하고 효율적으로 사용하기 위한 독특한 기능 (goroutine, channel)


Go언어에서는 포기한 기능들은 다음과 같다.

1. 상속은 지원하지 않음. 대신 mixin을 지원.

2. 제너릭은 지원하지 않음. 대신, interface{}가 가변형 변수 역할을 함.

(제너릭 기능은 Go언어 창시자들이 미니멀리즘에 기반하여 의도적으로 배제한 것이 아니라,

 Go언어 창시자들이 기술적인 문제를 해결하지 못해서 아직 추가되지 못한 경우임.)

3. 에러처리 구문이 취약함. 대신, defer문, recover()함수를 사용해서 panic상황에 대처 .


이러한 장단점이 혼합된 Go언어를 실제로 사용해 본 느낌과,

1. 기능성이 약간 부족하지만 오히려 간결해서 좋은 면도 있다.

   기능이 풍부하지 않지만 꼭 있어야 하는 기능들은 거의 다 있으며,

   반대로, 쓸데없는 기능이 없기 때문에 남이 개발한 소스 코드를 읽을 때도

   처음보는 기능을 접하는 경우는 거의 없다.

   그래서, 불러다 쓰는 제 3자 라이브러리가 의심스러우면 

    (저작권 문제가 없는 한도 내에서) 거리낌없이 소스 코드를 들여다보고 만지작 거리게 된다.

2. 개발 생산성이 확연하게 높아진다.

3. 실행속도 문제로 걱정할 일이 없다.


트위터가 서비스 초기에 루비(Ruby)언어를 사용했으나, 성능 상의 문제로 인해서 서비스 불안정의 어려움을 겪었고, 결국은 상당 부분을 Java와 Scala언어로 다시 개발해야 했다.

드롭박스도 서비스 초기에 파이썬(Python)언어를 사용했으나, 성능 상의 문제로 인해서 일부분을 Go언어로 대체하였다.


트위터와 드롭박스의 공통점은 높은 개발 생산성을 얻기 위해서

루비(Ruby), 파이썬(Python)등 동적언어를 사용하였으나,

성능상의 문제로 인해서 동일한 기능을 정적 언어로 다시 작성했다는 것이다.


Go언어는 성능이 상당히 좋으므로 

한 번 개발해 놓으면, 성능 문제 때문에 다시 개발해야 할 필요성이 적으며,

개발 과정에서도 비교적 높은 개발 효율성을 얻을 수 있다.


무한 경쟁 시대에 비용 효율성 면에서 강점을 가진다.

(구글이 비용 절감 차원에서 만든 것 같다.)


그 대신에 포기해야 하는 것이 기능성인데, 

막상 써보면 기능이 심하게 부족하다고 느껴지지는 않는다.


물론, C++, Java, C#등을 사용하던 사람은

1. 변수 선언 순서가 반대임.

2. 에러 처리 구문이 없고 if문으로 처리함.

3. 제너릭이 없음

등의 장애물에 좌절하곤 하지만 

실제로 사용해보면 의외로 그럭저럭 쓸만 하다.

(Java도 1.4까지 Generic이 없었지만 다들 잘만 쓰더라.)


Go언어를 가장 잘 설명하는 문구는  '모든 면에서 80%'이다.

파이썬(혹은 루비) 개발 효율성의 80%,

C++ 실행 효율성의 80% (사실은 50%이지만, 동적 언어보다 수백배 빠르므로 체감상 80%)


모든 면에서 약간씩 부족하고 아쉽지만,

비용절감의 면에서는 타의 추종을 불허하고,

여러모로 공동작업이 편하다.




소스코드 1천 라인은 0.2초, 12만 라인은 9.2초만에 컴파일 하는 것을 보여주는 동영상.

Go언어의 무시무시한 컴파일 속도를 체감할 수 있다.

실제로 사용해 보면 파이썬 같은 동적언어를 쓰고 있는 지, 정적 컴파일 언어를 쓰고 있는 지 헷갈림.

동영상 원본 링크 : https://www.youtube.com/watch?v=wwoWei-GAPo

.

TAG go언어

댓글을 달아 주세요