GHTS

PER, PBR, PSR, PCR등의 가치 지표는 모두 계산 과정에서 '상장 주식 수량'이 들어간다.

일반적인 경우, '상장 주식 수량'은 변하지 않기에 상수로 두고, 가격의 변동만 고려하면 되지만,

주식 분할/병합/소각 등의 이벤트가 발생하면 '상장 주식 수량'이 변한다.

이러한 '상장 주식 수량'의 변화를 고려하지 않으면

잘못된 밸류에이션 평가로 인해서 엉뚱한 종목을 선택하는 참사가 벌어지며,

주식 초보들의 수익율을 갉아먹는다.

이 문제를 해결하지 못하고 헤매다가

결국 매일마다 모든 종목의 '상장 주식 수량'을 갱신하는 방식으로 대응하고 있다.

너무나 무식한 방법인 데, 더 좋은 방법을 모르겠다.

'할 수 있다! 퀀트 투자' (ghts.tistory.com/36)에서 추천된 서적인 데,

직접 구해 읽어보니 두툼한 책이 전부 수많은 가치 지표에 대한 백테스팅으로 가득 채워져 있다.

이 책 때문에 '효율적 시장 가설'이 타격을 입고 '행동 경제학'이 시작되었다는 썰이 있다.

효율적 시장 가설에 의하면 시장에서 지속적인 이윤을 취할 가능성은 없어야 하는 데,

가치 지표를 이용해서 지속적인 수익을 올린 백테스트 결과가 가득하기 때문에,

자연스럽게 효율적 시장 가설에 대한 과학적 실증 반박 자료가 되어 버린 것이다.

이 책에 나온 내용을 요약 정리해서 한글화 한 책이 '할 수 있다! 퀀트 투자'이고,

해당 서적을 읽은 후에 좀 더 세부 사항을 살펴보고 싶다면 이 책을 볼 만하다.

그 많은 숫자와 표는 대충 건너뛰고,

각 지표에 대한 백테스트 결과만 훑어봐도 책 값은 충분히 건진다.

가치 지표 중에서 PBR의 경우 너무 낮으면 오히려 투자 수익율이 떨어지는 데,

해당 내용은 '할 수 있다! 퀀트 투자'에서 PBR 0.2 이하 종목은 피하는 필터로 간략하게

언급되어 있지만, 이 책을 봐야지 그게 얼마나 중요한 내용인지 깨닫게 된다

정말 자세하고 확실하게 나와있어서 전략 짤 때 도움을 받았다.

애초에 가치 전략이라는 게 데이터의 생존 편향을 극복하는 게 중요하기에

지뢰 피하기 위한 PBR 필터는 상당히 큰 역할을 한다.

(생존 편향 : 망한 기업은 가격 데이터가 없기에 무작정 저평가 종목 사다가 파산 종목 고를 위험이 상존한다.)

가치 투자 전략을 짤 때 필수 참고 서적 중 상위권에 속한다고 생각하며 강추~

국내 증권사의 API는 모두 32비트에서만 호출 가능합니다.

32/64비트 경계를 넘어서 OLE/OCX 간단한 호출하는 방법이 인터넷에 나와있지만,
증권사 API 호출 후 응답을 넘겨받는 데 꼭 필요한 'OLE 이벤트'는 작동하지 않더군요.
그래서, API 호출은 무조건 32비트 프로세스에서 해야 합니다.

(DLL, OLE, OCX 무관하게 32비트이어야 합니다.)

매매 전략 구동을 비롯한 모든 코드를 32비트로 실행해도 괜찮다면,

별도의 프로세스로 분리하지 않고 단일 프로세스 내에서 사용하면 간단하고 좋습니다.

그러나, 여하한 이유로 매매 전략을 64비트 프로세스에서 운용해야 한다면

증권사 API 호출을 독립된 32비트 프로세스로 분리한 후 상호 연동 시켜야 합니다.

GHTS에서는 다수의 매매 전략을 동시에 운용하는 상황을 상정하고 작성되었습니다.

모든 동시 다중 처리는 디버깅하기 몹시 까다롭기로 유명한

데이터 동시 액세스 충돌(이하 데이터 레이스) 버그 발생 가능성이 상존합니다.

Go언어에서는 이러한 버그를 추적할 수 있는 '레이스 감지기'를 제공하지만 64비트에서만 지원됩니다.

golang.org/doc/articles/race_detector.html

매매 시스템의 안정적인 운용을 위해서는

데이터 레이스 상황을 적절하게 디버깅 할 수 있어야 하기에

매매 전략을 64비트 프로세스에서 실행할 수 있어야 한다고 결정했으며,

증권사 API를 호출하는 기능을 별도의 32비트 프로세스로 분리했습니다.

그 과정에서 32비트 프로세스와 64비트 프로세스 간 자료교환을 위한 기술적인 문제는 다음과 같이 해결했습니다.

1. Go 자료형을 []byte로 변환
https://pkg.go.dev/encoding/gob

2. []byte 로 변환된 데이터를 전송 및 수신
https://github.com/nanomsg/mangos

RPC로 데이터를 전송하려면 우선 []byte로 변환하는 게 필요한 데, Go언어에는 Gob이라는 내장 변환 기능이 존재합니다.

이렇게 []byte로 변환된 데이터를 프로세스끼리 주고 받도록 해주는 기술로 가장 유명한 게 ZeroMQ입니다.

GHTS도 초반에는 ZeroMQ를 사용했습니다만,

ZeroMQ는 컴파일이 느리기로 유명한 C++언어로 작성된 관계로

ZeroMQ를 적용한 이후 컴파일이 느려져서 전체적인 개발 생산성에 큰 타격을 입었습니다.

이를 해결하기 위해서  비슷한 기능의 순수한 Go언어로 작성된 mangos를 채택했습니다.
https://github.com/nanomsg/mangos

이상 GHTS의 내부 구조가 지금처럼 분리된 이유와

이를 위해서 사용하는 의존성 라이브러리를 선택하게 된 이유를 간략히 설명드렸습니다.