예전에 Trading Desk 에서 사용하는 시스템들은 모두 Java 또는 C/C++ 가 아니면 거들떠 보지도 않았었던게 사실이나, 지금은 그런 생각이 없어진지 오래이다. 초창기 한국에 나가 작업을 했을때면 모두들 묻는 질문이 '이거 어떤 언어로 만들어 진 트레이딩 시스템이죠?' 이었는데, 그땐 내 자신도 사용하는 언어가 꽤나 큰 작용을 했다는 것을 인정하지 않을 수가 없다. 밑 바탕이 된 언어가 무엇이냐에 따라 그만큼 어플리케이션에 주어지는 Credit 도 많았을 뿐 아니라, 사용할 증권사 입장에서도 마음을 놓으며 구매할 수 있는 입장이었기에 말이다.
그게 벌써 1997년, 10년전 일이 되었다.
이후로 월가에서 4년을 RiskMetrics Group 에서 일하면서, 조금씩 이러한 고정관념에서 탈피하기 시작하였는데... 그 이유는 비즈니스 어플리케이션을 만들고 디자인하는데 있어 가장 중요한 것은 언어가 아니라, 완성된 어플리케이션이 얼마나 end user 입장에서 자유롭게 사용할 수 있으며 추가기능을 마음껏 interface 할 수 있느냐로 바뀌기 시작했기 때문이다. 따라서 회사내에서 대표했던 위험관리 시스템들은 제각가 사용하는 언어와 플랫폼이 다르기 마련이었다. 포트롤리오 위험관리 시스템의 경우는 Java 와 Delphi, 그리고 웹서비스를 제공하며 SQL 서버로, Credit Risk Management 시스템의 경우는 Java 와 Oracle, Pension Risk Management 의 경우는 Delphi 와 SQL 서버로 팀별로 최상의 솔류션을 제공하려 애썼다. 물론 이런 제품들은 모두 1년에 두번 또는 한번씩 Upgrade 와 새로운 제품을 출시하는 Package 화된 제품들이었기에 이런 상황이었다.
그 이후로 지금의 회사로 Asset Management 옮겨 Fixed Income 트레이딩 데스크에서 일을 하다보니, 이와는 또 다른 상황을 접하게 되었다. 매일같이 하루 하루 트레이딩을 하며 해당 포지션을 포트폴리오 메니지먼트 시스템에 입력하게 되고, Risk 관련 시스템과 연동하여 하루 Market 을 마감함과 동시에 그날까지의 상황을 리포트로 출력하여 분석하게 되니, 하루에도 몇번씩 특수한 상황에 접하여 수정을 하게 되는 부분이 발생하게 되었다. 따라서 이러한 부분을 감안하여 전체적인 시스템을 모듈화함과 동시에 Daily Process 에 민감한 부분은 C/C++ 로 API 를 만들어 TCL 스크립에서 라이브러리화 하여 재상용이 가능하도록 하였고, 따라서 순간 순간 Emergency case 에는 컴파일작업없이 쉽게 TCL 스크립과 PERL 스크립을 수정하여 바로 테스트함과 동시에 쉽게 production box (실제 사용되는 시스템)에 설치할 수 있도록 하고 있다. 물론 우리회사 뿐만이 아니라 주위의 많은 회사들에서도 이와 비슷한 방향으로 시스템 개발 방향을 잡고 있는것으로 듣고있다.
쉽게 Business logic 이 설정되지 못하거나 순간순간 바뀌어야 할 경우, 개인적인 생각이며 경험에 비춰보면 스크립 언어만큼 뛰어난 것도 없다고 생각한다. 특히나 트레이딩 데스크와 같이 시 분을 다퉈야 하는 경우는 더욱 그러하다 생각한다. 스크립 언어가 다시 부활하고 있는가 보다.
Python, Perl, Tcl, 그리고 Ruby 와 Ruby on Rails 까지...
쉽게 개발하고 테스트할 수 있는 환경이 발전에 발전을 거듭하고 이와 함께 Eclipse 개발자 환경이 발전을 계속하고 있는데, 이는 분명 Business users 들과 하루하루 접하며 사는 software engineer 들에게는 한번 더 고민하고 생각해 보아야 할 부분이다. 남들에게 show off 하려는 제품이 아닌, 사용자들에게 최적화 되고 문제가 발생했을 때 보다 신속하게 대처하고 Fix 하기 위해 적합한 개발툴이 무엇인가 하는 그런 고민 말이다...
그게 벌써 1997년, 10년전 일이 되었다.
이후로 월가에서 4년을 RiskMetrics Group 에서 일하면서, 조금씩 이러한 고정관념에서 탈피하기 시작하였는데... 그 이유는 비즈니스 어플리케이션을 만들고 디자인하는데 있어 가장 중요한 것은 언어가 아니라, 완성된 어플리케이션이 얼마나 end user 입장에서 자유롭게 사용할 수 있으며 추가기능을 마음껏 interface 할 수 있느냐로 바뀌기 시작했기 때문이다. 따라서 회사내에서 대표했던 위험관리 시스템들은 제각가 사용하는 언어와 플랫폼이 다르기 마련이었다. 포트롤리오 위험관리 시스템의 경우는 Java 와 Delphi, 그리고 웹서비스를 제공하며 SQL 서버로, Credit Risk Management 시스템의 경우는 Java 와 Oracle, Pension Risk Management 의 경우는 Delphi 와 SQL 서버로 팀별로 최상의 솔류션을 제공하려 애썼다. 물론 이런 제품들은 모두 1년에 두번 또는 한번씩 Upgrade 와 새로운 제품을 출시하는 Package 화된 제품들이었기에 이런 상황이었다.
그 이후로 지금의 회사로 Asset Management 옮겨 Fixed Income 트레이딩 데스크에서 일을 하다보니, 이와는 또 다른 상황을 접하게 되었다. 매일같이 하루 하루 트레이딩을 하며 해당 포지션을 포트폴리오 메니지먼트 시스템에 입력하게 되고, Risk 관련 시스템과 연동하여 하루 Market 을 마감함과 동시에 그날까지의 상황을 리포트로 출력하여 분석하게 되니, 하루에도 몇번씩 특수한 상황에 접하여 수정을 하게 되는 부분이 발생하게 되었다. 따라서 이러한 부분을 감안하여 전체적인 시스템을 모듈화함과 동시에 Daily Process 에 민감한 부분은 C/C++ 로 API 를 만들어 TCL 스크립에서 라이브러리화 하여 재상용이 가능하도록 하였고, 따라서 순간 순간 Emergency case 에는 컴파일작업없이 쉽게 TCL 스크립과 PERL 스크립을 수정하여 바로 테스트함과 동시에 쉽게 production box (실제 사용되는 시스템)에 설치할 수 있도록 하고 있다. 물론 우리회사 뿐만이 아니라 주위의 많은 회사들에서도 이와 비슷한 방향으로 시스템 개발 방향을 잡고 있는것으로 듣고있다.
쉽게 Business logic 이 설정되지 못하거나 순간순간 바뀌어야 할 경우, 개인적인 생각이며 경험에 비춰보면 스크립 언어만큼 뛰어난 것도 없다고 생각한다. 특히나 트레이딩 데스크와 같이 시 분을 다퉈야 하는 경우는 더욱 그러하다 생각한다. 스크립 언어가 다시 부활하고 있는가 보다.
Python, Perl, Tcl, 그리고 Ruby 와 Ruby on Rails 까지...
쉽게 개발하고 테스트할 수 있는 환경이 발전에 발전을 거듭하고 이와 함께 Eclipse 개발자 환경이 발전을 계속하고 있는데, 이는 분명 Business users 들과 하루하루 접하며 사는 software engineer 들에게는 한번 더 고민하고 생각해 보아야 할 부분이다. 남들에게 show off 하려는 제품이 아닌, 사용자들에게 최적화 되고 문제가 발생했을 때 보다 신속하게 대처하고 Fix 하기 위해 적합한 개발툴이 무엇인가 하는 그런 고민 말이다...
Comments