1.
OS/390. OS/2라는 비운의 OS를 기억하는 사람이면 짐작할 수 있듯이 OS/390은 IBM 메임프레임이 채택한 OS입니다. 저는 한번도 사용해보지 않았습니다. 유닉스. 현재 대부분 금융기관 서버들이 채택한 OS입니다. AIX,HP-UX 및 Solaris등이 있습니다. 서버용 OS보다는 Desktop 혹은 스마트폰등의 OS로 알려진 OS X도 사실은 유닉스의 한 변종입니다.
리눅스. 우분트 배포판으로 데스크탑 영역까지 넘보고 있지만 아직은 서버용 OS로 많이 사용하고 있습니다. 다만 금융권은 안정성과 유지보수등을 이유로 적용이 활발하지 않습니다. 윈도우. 윈도우 3.0부터 시작하여 현재까지 확고한 데스크탑 OS입니다. 물론 스마트혁명, 클라우드혁명으로 자리가 위태롭다고 하지만 ‘부자는 망해도 3대를 간다’는 말처럼 쉽게 허물어질 OS는 아닙니다.
2.
2000년대 초반 PC통신서비스가 아직 위력을 발휘할 때 윈도우를 서버OS로 사용했던?서비스가 SK텔레콤이 운영하던 넷츠고였습니다. 이 때 넷츠고에서 증권정보서비스를 개발해달라는 요청을 받았습니다. 대부분 서버는?유닉스, 클라이언트는 윈도우환경으로 증권시스템을 개발하던 때라 고민을 했지만 도전을 하기로 했습니다. 시세정보시스템을 구성하기 위?해 윈도우기반으로 공유메모리 및? 네트워크라이브러리를 구축하였습니다. 배치작업을 자동화하기 위한 프레임워크도 구성하였습니다.?시험을 해보니 성능이 나쁘지 않았습니다.
증권사 트레이딩시스템을 이렇게 윈도우로 개발한 업체가?미래로가는길입니다. 당시 컴팩 Proliant Server + 윈도우라는 구성으로 납품을 하였습니다. 유닉스로 개발한 솔류션에?비하여 가격면에서 장점이 있었습니다. 그렇지만 현재 윈도우를 서버OS로 사용하는 증권사를 들어보지 못했습니다.
한 달전쯤 가끔 보는 사장님을 모 증권사 개발실에서 만났습니다.
“일본에서 알고리즘트레이딩과 관련된 솔류션을 찾고 있는데 어떻게 하면 좋냐”라는 질문을 받았습니다.
“한국에서 솔류션하면 다 클라이언트/서버 모델의 솔류션을 생각하는데 그렇게 생각할 필요가 있냐.굳이 유닉스환경에서 개발된 제품이 아니라 윈도우 기반으로 된 제품을 개발하면 되지 않느냐?”
“알고리즘트레이딩을 겨냥한 제품은 아니지만 CEP/ESP와 관련하여 마이크로소프트가 StreamInsight라는 제품을 내놓았다. 또한 윈도우2008 HPC 서버는 아주 훌륭한 성능을 보여주고 있다.”
이런 말을 한 이유는 한가지입니다. Visual C++ 개발자들이 그저 MFC나 VB Script를 이용하여 화면을 개발구성하는?일만 하지 말라는 뜻이었습니다.Visual C++개발자를 육성하려면 많은 비용이 듭니다. 따라서 몸값도 비쌉니다. 그런데 비싼?고급인력을 그저 화면개발로 낭비합니다. 그것도 새로운 라이브러리나 컴포넌트를 개발하는 일이 아니고 이미 개발된 컴포넌트로 화면을?구성하는 일입니다.
3.
미국 거래소중 Direct Edge가 있습니다. Alternative Trading Vanue의 대표주자입니다. 얼마전 보도자료를 하나 내놓았습니다. Low Latency 거래소 구축을 위하여 윈도우를 채택하였다는 내용입니다.
?미국에서 네 번째로 큰 증권거래소가 리눅스와 유닉스 대신 윈도 플랫폼을 선택했다. 이로써 지연성을 340 마이크로초로 줄이고, 작업 처리량은 580% 늘려, 경쟁 우위를 확보했다.
뉴저지주 저지 시티를 기반으로 하는 증권거래소인 Direct Edge가 거래 플랫폼으로 윈도 서버 2008 R2, 마이크로소프트 SQL 서버 2008 및 인포매티카 울트라메시징을 선정했다고 한다. 증권거래소의 경우 낮은 지연성이 경쟁에서 이기는데 있어 아주 중요하다. Direct Edge는 더욱 증대된 거래량을 지원하는 동시에 이미 낮은 자사 시스템의 지연성을 더욱 낮추기를 원했다.
Direct Edge의 수석 기술자인 Steve Bonanno는 “우리가 우리 증권거래소의 플랫폼으로 마이크로소프트를 선정했을 때, 우리의 제1 목표는 미국에서 가장 큰 증권거래소들과 경쟁할 수 있을 정도로 충분히 낮은 지연성을 확보하는 것이었습니다. 우리는 초 당 수십 만 개의 거래 메시지를 발행하는 마이크로소프트 기술을 바탕으로 실시간 처리 엔진을 구축했습니다. 윈도는 340 마이크로초로 업무를 수행했습니다.”라고 말했다.
솔루션을 바탕으로 새 증권거래소를 구축한 Direct Edge중에서
거래소 시스템이면 Mission Critical System중 하나입니다. 통상 서버라는 영역이면 유닉스나 메임프레임이 전통적인 강자였습니다. 그런데 NYSE와 TSE는 리눅스를, Direct Edge는 Windows 2008서버를 채택하고 있습니다. OS만으로 설명하기 힘든 점이 있습니다. Intel이나 AMD가 주도하고 있는 CPU기술을 빼놓을 수 없습니다. 무엇 보다도 Multi-core Processor 및 리눅스/윈도우를 이용한 HPC가 바탕이지 않을까 합니다.
4.
다시 원점으로 돌아가서 Delphi나 Visual C++개발자들이 윈도우 OS에서 화면과 관련된 기능을 개발하여야 하는지 한번쯤 질문을 하였으면 합니다. 홈트레이딩시스템이 주도하는 지금 델파이나 비주얼 C++개발자가 클라이언트 화면을 개발하는 일외에 마땅히 없는? 것이 사실입니다.? 그렇지만 자동매매시스템이 시장을 주도하면 어떻게 될까요?
소프트웨어뿐 아니라 하드웨어등을 고려할 때 Multicore와 같은 기능을 충분히 지원해줄 수 있는 환경은 리눅스 혹은 윈도우라고 생각합니다. 병렬컴퓨팅기술을 위해 OpenMPI등을 적용할 생각도 할 수 있습니다. 파생상품의 가격계산등을 GPU에서 하고자 한다면 GPU Computing기술도 연구하여야 합니다. 더구나 화면을 통해 의사결정을 하지 않으므로 시세를 받아서 자체적인 알고리즘에 따라 계산을 하여야 합니다. 속도도 중요하므로 MFC 보다는 더 낮은 수준의 라이브러리를 다루거나 개발하여야 합니다.? 제가 보기에 준비할 일이 많아 보입니다.
어제 트위터로 @nakyung_papas님이 이런 글을 트윗하셨습니다.
고준남 동양종금증권 e비즈팀 과장은 “예상 체결가격 등의 계산이 중요한 파생상품 HTS에서 단순히 체결속도만 비교하는 것은 무의미하다” 며 “동양증권의 ‘고수’는 서버가 아닌 투자자의 PC에서 계산이 이뤄지도록 해 다른 프로그램들이 따라올 수 없다”
이 글중 서버와 PC를 하나로 합친 다음 현실에 적용해봅시다. 그러면 자동매매를 위한 트레이딩시스템이 무엇을 하여야 할지 그림이 그려집니다.
늘.. 한발 앞선 생각에 자극을 많이 받고 있습니다.
한발 앞선 생각이면 돈을 벌지 못하는데…
반보 앞서라고 하는데…ㅋㅋ
송년회나 하시죠?
내일, 모레는 선약이… 이번주엔 오늘과 금요일 밖엔 시간이 안되네요.
실속도 없이 바쁘기만….ㄷㄷㄷ
다음초(월,화)에 연락을 주세요….(^^)
증권사 전산실에 있으면서 정말 100% 공감합니다.
윈도우즈 프로그래밍 + 유닉스 프로그래밍 모두 해봤는데, 꼭 어떤 플랫폼이 클라이언트하고 어떤 플랫폼은 서버하고 이런 법은 없거든요.
그런데 대부분은 그냥 맹목적으로 윈도우즈는 클라이언트, 비쥬얼 인터페이스만 생각합니다.
네트워크 성능부분은 윈도우즈 플랫폼이 유닉스 보다 더 우수한 것으로 이미 검증이 끝났습니다.
윈도우즈 윈속에서는 이더넷 패킷을 처리하는 방식에서 메모리 복사하는 일을 최소한으로 줄임으로서 더 빠른 처리성능을 갖게 되었죠.
유닉스 진영에서 따라잡기 위해 여러가지 기술들이 등장했지만, 여전히 구조적 한계로 역전시키지 못하고 있습니다.
대다수 개발자를 비롯해 관리자들이 이러한 내용에 대해 알지도 못하고 관심도 없습니다.
윈도우즈 플랫폼 맹신자는 아니지만(차라리 리눅스 광신도가 맞습니다. ^^;) 관리자나 금융권 개발자들이 알아서 공부도 좀 하고 그랬으면 좋겠습니다.
같은 의견이라고 하니 반갑습니다. 아무쪼록 빨리 승진하셔서 전산인프라를 결정하실 위치가 되시면 실천하셨으면(^^)
Winsock에 말씀 하신 기능이 있는줄 처음 알았습니다. 가르침 하나 배웠습니다.
감사합니다..
윈도우즈 윈속프로그래밍 중 IOCP 기술부분 조사하시면 자세한 내용을 아실 수 있습니다.
그나저나 계약직 사원이라 발언권도 없고, 그냥 이 증권사에서 필요한 지식들 익히고 떠나야죠.
가끔 신기술 동향에 관련된 얘기 툭툭 던져줘도 윗사람들이 무지하기도 하고 관심이 없어서 별 관심을 못받더군요.
이곳의 개발환경이나 사내문화가 저 자신의 발전에는 도움이 안되는 것 같습니다.
계약직이라고 하시니 앞에 말을 취소하여야 겠네요.
대신 나중에 자기사업을 하시면 적절한 전략을 짜시도록(^^)
말씀하신 부분은 읽어보겠습니다. 그렇다고 제가 개발하는 사람은 아니니까 “아~~이런게 있구나”정도지만.
감사합니다. 건강하시고.
안녕하세요~~? ^-^~~
간만에 왔습니다. 글 잘 보았습니다..
얼마전에 MFC로 하는 사람이 c#은 바이너리가 아니기 때문에 무조건 C가 빠르다고 하는 사람을
보았습니다. ㅎㅎㅎ 그래서 저는 그런것은 이미 하드웨어가 너무 발전했기 때문에, 그런것을
따지는 것은 이미 예전에 일단락된 논쟁이다.C로 어떻게 짜든 반대의 언어에서 함수하나를
더 최적화해서 빨리하면 게임은 끝이다. 라고 말했더니 그래도 C가 빠르다라고 하길래..
그럼 외국계의 헤지펀드 회사에서 왜 HFT 개발자를 C#개발자로 뽑냐? 라고 했더니..
버벅..버벅…
HFT도 속도가 중요하지만, 속도만 가지고 HFT가 수익을 내는게 아니다..HFT 알고리즘이
마지막에 가서는 제일 중요하다라고 했더니..
버벅..버벅..후후~~ ^-^V;
…….저 지금 무슨 애기한거죠..ㅡㅡㅋ?;;; 횡설수설..
즐거운 성탄절 되십시요~~~ ^-^;;
차려진 밥상에 올려진 밥이나 반찬이 별로 없어도 지나다가 들려서 맛을 보시니 좋네요.(^^)
예전에 본 글중에 C/C++/C#/Java/Python등을 비교한 자료를 보았는데 어찌되었거나 C/C++이 빠르긴 하죠.물론 하드웨어가 워낙 좋아 차이가 아주 미세합니다.
1998년 Java로 HTS를 만든 적이 있었는데 처음 로딩을 할 때 30초가 걸렸습니다. 다른 언어로 개발하자고 했지만 고객이 Java Swing을 선택해서 한 것인데.ㅋㅋㅋㅋ
앞서 미세한 차이라고 했지만 미세한 차이가 마이크로초 혹은 나노초라 하더라도 HFT를 진짜로 하는 곳은 중요합니다. 예를 들어 알고리즘도 언어를 이용하여 전산처리되는데 알고리즘을 어떻게 설계할지, 설계한 알고리즘을 어떤 언어로 개발할지에 따라 Latency는 차이가 나겠죠.
차이를 무시해도 되는 전략이 있을 수 잇고, 나노초라 하더라도 빨라야 하는 전략이 있고 결국 전략이 결정할 문제락 생각합니다.
날이 다시 추워집니다. 건강하세요.
반은 맞고 반은 틀립니다.
자바와 C의 성능비교랑 비슷한 예입니다.
자바도 UI를 구현하지 않으면 비지니스 로직속도만 따지면 C와 근접한 수준입니다.
가상머신에서 돌리는 것을 감안하면 놀라운 성능이지요.
그래서 외국 증권사들도 자바를 이용해 시스템을 구현하기도 하지요.
그런데 정말 근소한 차이로 객체지향 언어의 특성 때문에 속도가 느린 부분이 존재합니다.
C와 C++를 예로 들자면, C++로 객체지향식 프로그래밍을 통해 구현한 로직이 객체 접근과 호출로 인해 C 보다 속도가 다소 차이가 나기도 합니다.
어지간한 구현에서야 C#이나 JAVA로 구현해도 그 차이가 미미할 겁니다.
하지만 나노초 미만의 속도로 전략을 세우려고 한다면 좀 면밀히 따져보고, 성능분석까지 철저히 하고 언어를 골라야 할겁니다.
하다못해 Intel CPU의 SSE4로도 속도가 안나와서 GPGPU를 사용하는 마당에 언어에서 속도가 경쟁사보다 느리다면…..
HFT 개발자를 뽑을 때 C# 개발자를 뽑는 이유는 단지 C#으로 구현할 부분이 필요해서이지, 모든 기능을 C#으로 완벽히 처리할 수 있어서가 아닙니다.
너무 특정 언어에 지나친 기대는 삼가해야 합니다.
비슷한 경우가 있습니다. Messaging 표준중 DDS와 AMQP가 있습니다. 현재 시장에 나온 DDS제품은 오픈소스모델이면서 자바로 개발되었습니다. AMQP는 Redhat에서 Apache Qpid를 가지고 MRG라는 이름으로 판매하고 있습니다. C/C++로 개발되었습니다.
말씀대로 차이가 크지 않습니다.
그런데 말꼬리잡기라고 생각하실 수 있지만 미국에서 C/C++을 찾는 이유는 차이가 마이크로초와 나노초이기때문입니다. 만약 밀리초단위면 다를 수 있습니다. 2007년이전 자바냐 C/C++ 혹은 Python과 같은 스크립트언어냐는 중요하지 않았습니다. 그런데 달라졌습니다. Latency의 기준이 나노초까지 내려가고 있기때문입니다.
경쟁이 밀리초도 아니고 마이크로초 혹은 나노초입니다. 이런 숫자를 놓고 어떤 언어가 적합한지를 따져야 하지 않을까 합니다. 물론 Latency는 언어만의 문제는 아닙니다. 전략을 어떻게 논리화하는지도 중요합니다.네트워크도 중요합니다.
이런 전제로 말씀드립니다.
하드웨어의 비약적인 발전 덕분에 일반적인 경우에는 언어에 따른 속도 차이는 의미가 없어졌지만,
주문 속도에 따라 체결 가격에 영향을 받는 Trading 쪽은 속도가 중요한 부분입니다.
‘지나가는 이’ 님의 말씀처럼 전체 성능에 영향을 미치는 함수를 최적화하는 것이 가장 중요한 것은 맞지만,
같은 조건이라면 .Net 상에서 실행되는 C# 보다는 C 가 빠를 것입니다.
현재 운영 중인 대부분의 HFT 전략은 C++ 로 작성되었고, 일부 Java 로 작성되었다고 알고 있습니다.
(출처 “High-Frequency Trading: A Practical Guide to Algorithmic Strategies and Trading systems”)
C++ 을 선호하는 이유는 두 가지 때문인데, 첫 번째는 속도가 빠르다는 점이고, 두 번째는 가볍다는 점 때문입니다.
사족을 달면 그것이 누를 끼치는 글입니다.
그냥 ‘동의’
건강하세요.
[좋은자료입니다]
네..맞습니다..하지만..
“…단지 C#으로 구현할 부분이 필요해서이지…” 라고 하시는것은 너무 주관적인 기대입니다.
그 회사에서는 c#으로 구현할 부분이 필요해서라고는 하지 않았습니다. 하지만..ㅎㅎ
c#만으로 구현한다고도 하지 않았지요. ^,,^; 하지만, HFT 가 100% c#으로 돌아가는 것을
본 저로서는 아무래도 c# 같읍니다. -_- 아마도 마이크로초로 승부하는 HFT가 아니었나 봅니다.
그럼 즐거운 크리스 마스 보내세요~~
언어를 무엇으로 선택하는지는 전적으로 트레이딩을 하는 회사나 팀이 결정할 일입니다. C#이든 C++든 자신들이 하고자 하는 전략에 부합하면 됩니다. 꼭 어떤 언어가 최선이다라는 정답은 없습니다. 사람마다 어떤 일을 다 똑같이 하지 않기때문입니다.
다만 말씀중 HFT라는 단어를 어떤 의미로 사용했는지, 한국내 어떤 전략을 사용하는 팀을 HFT라고 하셨는지 궁금합니다.
만약 슈퍼메뚜기를 HFT라고 한다면 C#도 가능한 선택일 듯 합니다.
날씨가 너무너무 춥네요. 따뜻한 곳에서 즐거운 성탄이 되셨으면 합니다.
건강하시고.
네..옳으신 말씀입니다. 저도 도스때부터 개발을 10년 이상 했던 사람입니다.
언어또한 순수 C부터 c#까지 다양한 언어를 어쩔수 없이 했었던 시절도 있었습니다.
제가 적었던 글에 c#이 무조건 맞다라는 것으로 이야기 한것이 아닙니다.
좋은자료님께서 잘못아시고 쓰신글이 있는듯하여 적은 글입니다.
HFT또한 아직 100%명확한 기준이 되어 있지 않는 것도 사실이지요…
그리고 정확하게 실전으로 매매를 하는 HFT를 보여주는 자료자체가 극비인 이유로
아예 보기가 힘들겠지요.
하지만, 우리나라가 HFT를 하기가 어려운 구조적인 문제점을 알고있지만, 그렇다고 무조건
못한다는것 또한 아닌듯합니다…….왜냐하면…….-_-;;;
…..저 지금 무슨말하고있지요.ㅡ.ㅡㅋ?? 또 횡설 수설했네요..ㅎㅎㅎ
smallake님 내일또 엄청 추워진다고 합니다..생각만해도 춥네요.ㅜ.ㅜ;;
동네에서 지하철까지 가는 버스가 자주 안오는데…흠……ㅜ.ㅜ; 내일은 또
얼마나 떨어야할찌…….덜덜덜….ㅜㅜ 감기조심하세요…이번 감기가 독하다고 합니다..ㅠ_ㅠ;;;
그럼 안녕히계세요..ㅜ.ㅡ
우리가 잊었던 “겨울이 매섭다”는 사실을 매일 몸으로 배우고 있습니다.
연말입니다.
건강 잘 챙기시고 힘있는 신년출발이 되시길 바랍니다.
이상하네요. 동양고수는 서버가 PC에서 계산되기 때문에 느리다고 생각했는데요… 초당 100건 주문내면 체결상황을 볼 수 없을정도로 랙이 심합니다…
“서버가 PC에서”라는 말은 논리적인 모순인데(^^)
특정한 증권사 시스템이 어떤 구조인지, 소프트웨어나 하드웨어 등등을 보고 판단해야 할 문제가 아닐까 합니다.
이런 경우 모르고 한 소리하면 설화에 휩싸입니다. ㅋㅋ
그래도 궁금한 거.
초당 주문을 100건 내는 시스템이면 무척이나 잘 만든 시스템인데. 랙이 심하다는 말은 지연된다는 뜻일텐데…주문에 대한 체결데이타가 아무리 많아도 시세데이타보다 많지 않을텐데. 아마 PC쪽은 아니고 서버에서 보내주는 쪽에서 지연이 생기는듯 한데.시세지연은 있어도 체결지연은 이해가 쉽지않습니다.