두물머리(Doomoolmori)
홈페이지에서는 다음과 같은 의미를 담아 회사 이름을 지었다고 합니다.
두물머리는 남한강과 북한강이 만나는 곳으로, 금융과 테크놀로지의 ‘접목’이라는 의미를 담아 두물머리를 설립하였습니다.
겨우 하루밖에 안되는 짧은 시간이었지만 이곳에서 일하면 프로그래밍 언어뿐 아니라 금융과 투자 도메인의 언어를 자연스레 배울 수밖에 없겠다 싶습니다. 얘기를 나눠본 프로그래머들도 대체로 소프트웨어 개발 외에도 담당하는 업무의 도메인 지식과 정보에 관심이 많았습니다.
과제
두물머리에서는 파이썬과 노드, 그리고 스칼라 등 다양한 프로그래밍 언어를 사용해 서비스 코드를 작성하고 있습니다. 아무래도 제게 익숙한 언어가 파이썬인 관계로 우선 파이썬으로 작성된 투자 전략 백테스팅 코드를 다른 프로그래머와 함께 페어 프로그래밍으로 작성해보는 과제를 수행하기로 했습니다.
기존에 작성된 서로 다른 두 전략을 절반씩 실행하는 새로운 전략을 추가하는 것이었는데, 선임자가 작성한 문서를 따라 전략을 추가하는 과정에서 문서와 코드의 문제점과 개선점을 다수 발견해, 어떻게 바꿔가면 좋을지 구체적인 변경 방향과 의견을 제안하게 되었습니다.
해결 과정
이제까지 작성된 백테스팅 코드는 전략에 따라 각각의 디렉토리 안에 파이썬 파일 하나와 해당 전략이 실행될 때 참고할 구글 스프레드 시트의 쌍으로 구성되어 있었습니다.
여러 전략을 구별하기 위해 각각 StrategyName과 같이 고유한 이름을 가지고 있는데, 이를 파이썬 코드와 스프레드시트, 데이터베이스에서 표기하는 방법이 Strategy_Name, Strategy-Name, Strategy Name과 같이 서로 다르고 한 코드 내에서도 다른 값들이 섞여 있어 사용자의 실수를 유발해, 런타임에서 제대로 동작하지 않는 문제를 발생시키고 있었습니다.
그뿐만 아니라 백테스팅시 실행되는 파이썬 코드의 얼개는 프로그래머가 작성해 전략 설계 담당자인 퀀트에게 넘기지만, 전략을 개선해 새로 시뮬레이션해 보고자 할 때마다 프로그래머에게 요청해 해당 전략이 포함된 파이썬 패키지 버전을 올려 새로 설치하고, 서비스를 업데이트해야 했습니다.
퀀트가 작성한 코드 자체는 NumPy나 SciPy 등의 파이썬 패키지에 크게 의존하고 있어 이를 다른 언어나 체계로 바꾸는 것은 어렵지만, 이를 관리하고 실행하는 코드까지 파이썬일 이유는 없습니다. 파이썬 전략 코드의 실행을 위해 꼭 다른 파이썬 실행 파일이 전략 코드를 import 해야 하는 것은 아닙니다. 각 전략 코드가 독립적으로 실행되는 __main__을 갖춰 작성되어 있으면, 노드로 작성된 실행자(runner)가 이를 실행하는 것도 가능합니다.
하지만 우선 왜 하나의 전략에 비슷하게 생긴 여러 이름을 사용하게 되었는지 원인을 파악하였는데, 이는 최초 작성자가 파이썬에 내장된 importlib 모듈을 활용하지 않았기 때문으로 생각됩니다. 전략을 추가할 때마다 StrategyName 디렉토리 안에 비슷한 이름의 strategy_name.py 파일을 만들어, class StrategyName을 작성하고, 같은 디렉토리 안의 __init__.py에서 이를 다시 불러들여 내보낸 후, 데이터베이스에 strategy-name 값을 추가하고 스프레트시트에 Strategy Name 시트를 추가해 변수를 입력하는 작업을 해야 합니다.
이제 백테스팅 시뮬레이션을 수행하는 주 파이썬 파일에 from StrategyName import StrategyName을 추가하고, 외부에서 전달된 전략 이름에 따라 switch 구문 내에서 필요한 전략 클래스를 개체로 만드는 작업을 수행하고 있었습니다. 이 과정에서 하나의 이름이라도 틀리면 런타임에서 문제가 발생합니다. 이 부분을 importlib.import_module을 이용해 단순화시킬 수 있는 방법을 소개했습니다.
여담
해당 업무의 담당자가 파이썬에 능숙한 사용자가 아님에도 헷갈리는 이름을 입력해가며 파이썬 패키지를 갱신하고 재배포하느라 불필요한 작업을 하게 되는 문제를 해결하는 것으로 시작해, 최종적으로는 프로그래머의 도움 없이 전략 담당자가 웹페이지에서 코드를 작성하고 상수와 변수를 쉽게 조정할 수 있는 수준까지 단계적인 개선안을 제안하였습니다.
아마 처음부터 코드와 구조가 이렇게 복잡하고 유지보수하기 어렵진 않았을 것으로 생각합니다. 처음에는 전략도 몇 개 되지 않았을 것이고, 별 문제가 되지 않은 부분도 시간이 지나 처음 설계에서 벗어난 부분이 많아지며 새로 작성해야할 시기를 놓쳐 지금과 같이 복잡해졌을 것입니다. 특히 최종 사용자에게 직접 노출되지 않는 코드들은 더욱 그러기 마련이라 마냥 잘못 설계했다 여기지 않습니다. 다만 경우에 따라서는 의외로 간과했던 부분이 조직과 서비스의 혁신을 가로막기도 하니 가끔 시간을 내서 환기시킬 필요는 있다 생각합니다.
