웹트레이딩시스템과 SPA

1.
90년 초반 여의도로 들어와 트레이딩시스템을 개발한 이후 수많은 프로젝트를 수행했습니다. 클라이언트와 관련한 기술구조는 다양하였지만 서버의 기술구조는 동일합니다.

접속서버 – AP서버 – 계정계(정보계) – FEP – 한국거래소

물론 OS는 시대에 따라 바뀌었습니다. 90년대말 선마이크로시스템즈가 시장을 지배할 때 Solaris를 기반으로 하였지만 IBM이 시장을 지배할 때는 AIX 그리고 현재는 Linux를 기반으로 합니다. 저와 함께 한 개발자들이 만들었던 서버플랫폼은 요즘 유행하는 NginX처럼 Event Driven이었습니다. Apache와 같이 멀티프로세스와 멀티쓰레드 구조를 택한 제품들도 있었습니다.

지난 이 십여년동안 서버구조는 큰 차이를 보이지 않았지만 클라이언트는 다양하게 변화하였습니다. PC시대를 주도한 HTS(Home Trading System)은 Visual C++를 이용한 IDE(클라이언트 플랫폼) 혹은 Delphi를 이용한 기술이 등장하였고 현재는 Visual C++가 흡수한 상태입니다. 저는 Delphi를 처음 채택한 회사의 창업자로 참여하였습니다. 윈도우를 기반으로 한 기술구조는 큰 변화가 없었지만 인터넷시대를 맞이한 기술적 대응은 다양하였습니다.

증권산업이 인터넷시대에 대응한 두가지 방법인 HTS와 WTS중 웹트레이딩시스템(WTS)는 HTS와 비교하여 좀더 웹친화적인 기술구조를 택하였습니다. 저도 다양한 기술을 택하여 서비스를 구현하였습니다. 처음 시도한 웹트레이딩시스템은 일은증권이 발주한 ITS(Internet Trading System)입니다. 기술은 막 부상하고 있던 Java의 Swing을 이용하는 프로그램이었습니다. 같은 때 다음이 신영증권에서 비슷한 프로젝트를 진행하였습니다. 98년쯤으로 기억합니다. 트레이딩시스템에 바라는 투자자의 요구와 괴리있는 기술을 택한 발주자의 책임으로 실패하였습니다. 이유는 최초 프로그램이 동작할 때까지의 시간이었습니다. 1분이 넘는 시간을 기다려줄 투자자는 없기때문입니다. Java로 실패한 이후 도전한 프로젝트는 Java Applet을 이용한 WTS입니다. 교보증권에서 발주한 프로젝트였습니다. 바로 직전 동양증권 웹시스템을 개발할 때 증권차트를 개발한 경험과 Swing의 실패를 참고로 시도하였습니다. 채널의 특성상 시장점유율이 높지는 않았지만 운영상의 오류는 없었습니다. 사실 Java를 이용한 WTS는 시장에서 환영을 받지 못하였습니다. 설치할 때의 불폄함때문입니다. 이후 새롭게 시도한 기술이 Ajax와 Javascript를 이용한 WTS입니다. 미래에셋증권에 납품하였습니다. ActiveX기술을 이용하여 서버와의 통신 및 차트를 담당하도록 하였고 Ajax와 iFrame 및 Javascript Library를 이용하여 증권화면을 개발하였습니다. Javascript + Ajax + Tomcat +JSP로 이루어진 시스템입니다. 응답속도는 1초를 넘지 않았습니다.

이상이 PC와 인터넷시대의 웹트레이딩시스템입니다. 그리고 Java로 FX거래시스템을 만들고 회사문을 닫았습니다. 이후 시대가 바뀌었습니다. 스마트폰이 등장하면서 PC를 뛰어넘는 ICT혁명이 여의도를 변화시켰습니다. 2008년 초반 아이폰을 이용한 시세조회시스템을 개발하는 모습을 보았지만 작은 화면이 PC를 대체할 것이란 예상을 솔직히 하지 못했습니다. ‘손안의 혁명’ 입니다.

서버의 기술구조는 여전히 변화가 없었지만 PC를 기반으로 한 클라이언트 플랫폼의 경우 변화가 진행중입니다. MTS가 HTS를 뛰어넘는 조건에 멀티디바이스플랫폼을 가진 회사들이 더 큰 경쟁력을 보입니다. 사실 보기에 따라 WTS와 MTS는 같은 관점을 볼 수 있습니다. 네이티스기술이 아니라 멀티디바이스를 지원할 수 있는 웹기술구조로 택하는 경우에 한합니다.

2.
얼마전부터 웹트레이딩시스템을 구축하는 프로젝트를 진행중입니다. 프로젝트를 시작하기 전 WTS의 기술구조를 마지막으로 했던 미래에셋증권 WTS을 했던 경험에 기반한 이해였습니다. Node.js를 이용한 기술기반이라고 하여 Websocket을 이용한 프로젝트로 이해했습니다. 그런데 실제로 프로젝트를 시작하니 많이 달랐습니다. 틀리지는 않았지만 핵심이 비켜나간 이해하였습니다.

핵심은 Node.js는 node.js이지만 서버기반이 아니라 데스크답 어플리케이션을 개발하기 위한 node.js였습니다. JSP와 Java 및 MVC기반으로 구현한 Server Side Rendering Application이 아니었습니다. 제가 놓쳤던 흐름이 몇 년사이에 있었던 것입니다. Node.js가 미친 영향이고 Client Side Rendering Application을 구현하는 기술구조나 방법론이 보편화하였더군요. 이런저런 검색을 해보니 Client Side Rendering Application 보다는 SPA가 더 일반적인 표현입니다. SPA=Single Page Application입니다. SPA는 제가 아는 웹과 동작흐름에서 많이 다릅니다.

또다른 설명도 있습니다.

Download (PDF, 326KB)

HTML이 아닌 데이타(JSON, JavaScript Object Notation) 교환으로 어플리케이션이 동작을 합니다. 기술구조로 보면 웹보다는 클라이언트/서버에 가깝습니다. 그래서 WTS라고 하지만 Home Trading System의 HTS이면서 HTML Trading System의 HTS이라고 할 수 있습니다.

현재 프로젝트는 오픈소스 프레임워크를 사용하지만 조사를 해보니 SPA를 위한 다양한 프레임워크가 있더군요.

JavaScript Frameworks in 2016

좀더 자세한 비교를 원하시면 Comparison of Single-Page Application Frameworks을 읽어보시면 어떨가요?

Download (PDF, 639KB)

물론 Single Page Web Applications: JavaScript End-to-End의 글쓴이중 한명인 Michael S. Mikowski가 Do you really want an SPA framework?에 정리한 주장을 읽어보면 다른 관점을 이야기합니다.

Long cycle times not only kill productivity, but they also stifle innovation because only so many solutions can be tried within any given period of time. The key to success is to learning how to fail really fast.

개인적으로 프로젝트를 진행하면서 가장 큰 관심을 단위테스트입니다. 여의도 프로젝트가 그렇듯이 시간때문에 형식적인 경우가 많고 데이타검증을 이유로 수작업에 의존하는 경우가 많습니다. 가능하면 코드화, 자동화를 하고 싶지만 쉽지 않을 듯 하고 대신 Selenium IDE를 활용하는 방안만 고민해보고 있습니다.

3.
검색을 하면서 놀란 점은 SPA와 관련한 자료들이 대부분 최근에 나온 것들입니다. 해석을 하면 최근의 경향이나 관심을 반영하고 있고 앞으로 성장가능성이 크다고 생각합니다. SPA를 공부해보고 싶으면 Comparison of Single-Page Application Frameworks이 좋을 듯 합니다. 검색하시면 온라인으로 찾을 수 있습니다. 귀찮으시면 아래와 같은 논문도 좋을 듯 합니다. Single page architecture as basis for web applications입니다.

Download (PDF, 4.01MB)