1.
현대 금융시스템은 정보기술(IT)를 기반으로 하고 있습니다. 또한 모든 시스템은 다양한 방식으로 서로 연결되어 있어서 어떤 곳에서 발생한 위험이 다른 곳의 위험으로 전이되어 커다란 재앙을 일으킬 가능성이 점점 커지고 있습니다. Flash Crash와 Knight Crash를 겪은 미국 월스트리트가 기술적 위험을 관리하기 위한 규제를 세우는 이유입니다.
Technical Risk와 ISO 9000
매매시스템 장애와 SEC 및 FSS
그렇지만 어떤 조치를 취한다고 하더라도 100% 완전할 수 없습니다. 장애가 발생할 확률은 매우 낮게 하는 것이 목표입니다. 이런 배경으로 인하여 미국고 유럽에서 하는 금융관련 행사를 보면 시험(Test)와 관련한 주제가 많습니다. 미국 Lasalle Tech가 분석한 글을 보면 미국의 금융회사들도 한국의 금융회사와 별로 차이가 없는 개발문화를 가지고 있다고 합니다. 즉 ‘선개발 후시험’ 방식입니다.
Typically, testing that happens in exchanges follows a “develop now, test it at the end” approach. Concrete dates are set months in advance that promise specific functionalities for new systems. Teams dedicate a certain number of months to development and the rest is left for testing. For example, if a team plans for a system to roll out in six months, they may plan to spend four of those months developing and two of those months testing. Realistically, for any number of reasons, development takes longer than anticipated and testing time is cut down. In this scenario there is probably five months of developing, which leaves only one month – four small weeks – for testing.
Technology Testing Culture at Exchanges Threatens Markets중에서
이런 개발문화를 인포그래픽으로 정리한 자료도 발표하였습니다.
2.
방법론의 문제는 아니라고 생각합니다만 보통 폭포수 방법론을 적용하는 경우 단위시험과 종합시험을 거치도록 하지만 보통 형식에 그치는 경우가 많습니다. 보통 회사에서 적용하는 방법론을 비전산적으로 정의하면 RDD=Resource Driven Development 이거나 MDD=Master(갑) Driven Development입니다. 시간과 결과가 중요합니다. 이럴 경우 시험은 비용으로 치부합니다. 시험이 약한 시스템은 위험에 노출될 가능성이 커집니다.
앞서 Lasalle Tech가 인포그래픽으로 제안한 방법은 흔히 사용하는 표현을 빌면 ‘Test Driven Development’라고 할 수 있습니다. 위키는 다음과 같이 TDD를 정의합니다.
테스트 주도 개발(test-driven development, TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 우선 개발자는 바라는 향상 또는 새로운 함수를 정의하는 (초기적 결함을 점검하는) 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 케이스를 통과하기 위한 최소한의 양의 코드를 생성한다. 그리고 마지막으로 그 새 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 ‘재발견’ 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.
테스트 주도 개발를 보면 아래와 같이 정의하고 있습니다.
제가 전문가가 아니므로 관련한 자료를 찾아보았습니다. 오래 전에 발표한 자료지만 호응도가 높은 글입니다.
주로 사용하는 언어가 C언어라서 C와 관련한 TDD를 찾아보았습니다. 2002년도 자료입니다. 이미 2002년도에 TDD를 적용하였는데 그 때 저는 산출물을 만들기 바빴습니다.
3.
TDD와 관련한 글을 읽다 보니까 TDD와 애자일방법론이 연결되더군요.
현재까지 나와있는 요구사항으로부터 설계를 하고 구현을 한 후 고객에게 검증을 받고 거기서 나온 피드백을 바탕으로 점점 요구사항과 설계, 구현 등을 구체화시켜 나가는 방법이 지금의 소프트웨어 개발에 있어서는 더 적합합니다. 그래서 나온 것이 반복적 개발 방법론입니다. 반복적 개발 방법론 중 가장 널리 알려진 것이 바로 UP입니다. UP(Unified Process)는 반복적으로 프로젝트를 진행하되 정해진 프로세스의 절차대로 진행하는 것입니다. 반복적으로 개발을 이끌어나가고 있기는 하지만 정해진 프로세스(비즈니스 모델링에서부터 개발까지)에 따라 진행되고, 반복이 진행됨에 따라서 비중이 바뀝니다. 예를 들어 첫 번째 반복에서는 비즈니스 모델링이 비중이 컸다면 이 후 반복으로 진행될수록 개발 및 테스트에 대한 비중이 점점 크게 차지하게 됩니다. 이를 좀 더 개발 활동에 실용적으로 사용할 수 있는 방법을 생각하게 되었는데, 그것이 바로 애자일(Agile) 개발 방법입니다.
애자일(agile) 개발 방법이란?중에서
점점 어려워집니다. 방법론 없는 개발이 곧 방법론인 개발을 하였기때문에 이해도가 많이 떨어집니다. 애자일에서 끝나지 않더군요. Caplin의 블로그를 가보니까 Reactive Programming이라는 것도 있더군요. The Reactive Manifesto을 기초로 한 방법을 택합니다.
InfoQ는 RP가 중요한 흐름이라고 하고 RP Application은 아래와 같은 특징을 갖는다고 합니다.
React to events: the event-driven nature enables the following qualities.
React to load: focus on scalability rather than single-user performance.
React to failure: build resilient systems with the ability to recover at all levels.
React to users: combine the above traits for an interactive user experience.
Reactive Programming as an Emerging Trend중에서
그러면 RP와 기계트레이딩과 무슨 관계가 있을까요? HFT와 RP의 관계를 다룰 동영상입니다.
금융공학도 매우 중요합니다만 트레이딩이 기계화하면서 정보기술이 중요해집니다. 정보기술은 시스템을 동작하도록 하는 핵심요소입니다. 무결점 시스템을 만들어내기 위해서 – 기술적 위험, 운영 위험을 줄이기 위해서는 시험에 중요시하는 방법론이 점점 필요해집니다.
테스트… 정말정말 중요 합니다.
실제 필드에서는 테스트 중요하게 여기지 않는 풍조가 만연한 것 같아요.
개발자가 책임지고 모든 로직을 꼼꼼하게 작성 하는것이 최선이다라는 식이에요.
타 부서 사람들은 테스트 제대로 해주는 케이스를 거의 못 봤어요.
대충대충 설렁설렁 테스트 몇 번 하고나서 오케이 싸인 내고,
실제로 장 운용 중에 사고가 나면 그 책임은 고스란히 개발자에게 돌아가죠.
맞는 말이긴 해요. 그게 바로 개발자가 돈 받는 이유니까요.
근데요, 최소한 자기가 쓸 시스템 테스트 정도는 다 같이 으쌰으쌰 힘 내서 해주는 분위기라도 있었으면 좋겠어요.
[하찮은 ‘돈 나가는 부서’에 속한 직원 나부랭이 따위가 하는 일]이 아닌
잘 못 되면 회사 존망여부가 달린 일이라는 공동체 의식을 가지구요.
MDD, 갑이 주도하는 개발이나 RDD, 자원에 맞추어 개발하는 방식에 젖어 있으면 불가능하죠. 품질보다 품질외의 숫자가 더 중요한 것이 우리의 문화입니다. 비용, 일정 등등.