안녕하세요, 오랜만에 인사드립니다. 저는 38세의 부업 엔지니어로서 평일 밤과 주말에 AI 에이전트와 자동화 트레이딩 봇을 만지고 있습니다.

자동화 트레이딩 봇을 개발하는 과정은 아이디어를 얻고 난 후에도 긴 여정이 되는 경우가 많습니다. 전략을 코드로 변환하고, 과거 데이터로 백테스팅하며, 매개변수를 조정하는 작업은 쉽게 몇 주가 걸릴 수 있습니다. 게다가 보통 대부분의 아이디어는 '이건 쓸모없다'라는 간단한 말과 함께 백테스팅 단계에서 폐기되곤 합니다. 이런 종류의 재작업은 1인 개발자에게 정신적으로 매우 힘든 일입니다.

최근에 새로운 전략 하나가 머리에 떠올랐습니다: '저평가된 소형주가 대기업에 인수(TOB)될 가능성이 더 높지 않을까?' TOB(Tender Offer Bid, 공개 매수 제안)가 발표되면 주가가 보통 급등합니다. 따라서 이 가설이 사실이라면, 저는 영리하게 투자할 수 있을 것 같습니다.

보통이라면 여기서부터 백테스트 코딩을 시작했을 것입니다:
"저평가된 소형주의 조건을 정의하고, 과거 주식 데이터로 TOB 발생을 시뮬레이션하며, 수익률을 계산한다..."

하지만 이번에는 모든 무거운 작업을 건너뛰고, 더 근본적인 것을 먼저 조사하기로 결정했습니다.

즉, 원시 데이터로 가설의 '심장'을 직접 때려보는 것입니다.

수익률 측정 전에 '메커니즘'을 측정하기

모든 투자 가설에는 수익을 창출할 것이라고 전제하는 '메커니즘'이 있습니다.

저의 가설은 다음과 같았습니다:

1. 메커니즘: "저평가된 소형주는 인수(TOB)될 가능성이 더 높다."
2. 결과: TOB 발표가 주가를 끌어올려 수익을 창출한다.

많은 사람들은 '2. 결과'를 측정하기 위해 복잡한 백테스트 구축에 곧바로 뛰어듭니다. 하지만 핵심 전제인 '1. 메커니즘'이 틀렸다면, 백테스팅에 쓴 모든 시간은 낭비가 됩니다. 정말 가혹합니다.

그래서 이번에는 수익률이라는 간접적인 지표를 보는 대신, 가설의 핵심인 "저평가된 소형주가 실제로 인수될 가능성이 더 높은가?"를 원시 데이터(raw data)로 직접 검증하기로 했습니다. 이는 소프트웨어 개발에서의 PoC (Proof of Concept, 개념 증명)와 유사합니다. 가장 결정적이고 불확실한 부분부터 먼저 공격하는 것입니다.

582건의 TOB 사례로 정면 돌파하다

제가 한 일은 간단했습니다:

1. 데이터 수집 (Data Acquisition): 지난 몇 년간의 약 582건의 TOB (Takeover Bid, 공개매수) 사례(공시 정보)를 수집했습니다.
2. 정의 (Definition):
   • 소형주 (Small-cap): 시가총액 하위 20%에 해당하는 주식.
   • 저평가 (Undervalued): PBR (Price-to-Book Ratio, 주가순자산비율)이 1배 미만인 주식.
   • 저는 이 두 조건을 모두 충족하는 경우를 "저평가된 소형주"로 정의했습니다.
3. 검증 (Validation):
   • 모든 상장 기업을 "저평가된 소형주" 그룹(전체의 약 20%)과 "기타" 그룹(약 80%)으로 나눕니다.
   • 각 그룹에서 실제로 TOB가 발생한 기업의 비율을 계산합니다.

만약 가설이 맞다면, "저평가된 소형주" 그룹의 TOB 발생률이 "기타" 그룹보다 현저히 높아야 합니다.

코드는 대략 다음과 같은 모습이었습니다. 백테스팅 코드보다 100배는 더 단순합니다. pandas를 사용하여 모든 상장 기업의 TOB 사례 데이터와 재무 데이터를 결합하고, 각 기업이 "저평가된 소형주" 조건을 충족하는지 플래그(flag)를 표시한 뒤, 그룹별로 집계하는 방식입니다.

import pandas as pd

# all_stocks_df: 모든 상장 기업의 DataFrame (is_small_cap, is_value_stock 플래그 포함)
...

그리고 이 간단한 코드를 실행한 결과는 다음과 같았습니다:

저평가된 소형주 그룹의 TOB 발생률: 2.33%
기타 그룹의 TOB 발생률: 3.02%

...어라?

*오히려 _더 낮았습니다.

저평가된 소형주가 TOB를 통해 인수될 확률이 다른 주식보다 낮았습니다. 제 가설의 핵심은 데이터에 의해 즉각적으로 반박되었습니다. 말 그대로 즉사였습니다.

솔직히 이 결과를 보고 조금 웃음이 났습니다. 이런 사실을 깨닫지 못한 채 백테스팅 (backtesting) 코드를 작성하느라 몇 주를 보냈을 생각을 하니... 진심으로 공포스럽기까지 하네요. 휴.

(물론 "저평가된 (undervalued)" 또는 "소형주 (small-cap)"의 정의를 다시 내린다면 결과가 달라질 수도 있습니다. 하지만 일반적인 정의와 비교했을 때 이토록 명확한 차이가 나타났기에, 이 가설을 탐구하는 우선순위는 낮다고 판단했습니다.)

교훈: 과도한 처리 이전에, 가설의 '심장'을 겨냥하라

이번 경험을 통해 얻은 교훈은 간단합니다:

연산이나 구현 부하가 큰 검증을 수행하기 전에, 가설의 핵심 "메커니즘 (mechanism)"이 맞는지 확인할 수 있는 더 간단한 방법이 있는지 먼저 고려하십시오.

이는 비단 자동 매매 (automated trading)에만 국한된 이야기가 아닙니다.

• AI 에이전트 (AI agent)를 구축한다면, 복잡한 흐름을 조립하기 전에 핵심 프롬프트 (prompt)가 단독으로 의도한 대로 작동하는지 테스트하십시오.
• 웹 스크래핑 (web scraping) 도구를 만든다면, 모든 페이지를 크롤링 (crawling)하기 전에 단일 페이지에서 타겟 요소를 안정적으로 추출할 수 있는지 시도해 보십시오.

1인 개발자로서 리소스는 언제나 한정되어 있습니다. 특히 시간은 유한합니다. 그렇기에 가장 위험한 가설, 즉 무너졌을 때 모든 것을 망가뜨릴 수 있는 가장 취약한 부분인 "심장"을 가장 먼저 다루는 것이 믿을 수 없을 정도로 중요합니다. 저는 이번에 그 사실을 그 어느 때보다 절실히 느꼈습니다.

결국 이 "저평가된 소형주 TOB 전략"은 개발 프로세스에 진입하기도 전에, 단 1센트의 수익도 계산해 보지 못한 채 무덤으로 떠났습니다. 하지만 덕분에 몇 주간의 헛된 노력을 피할 수 있었습니다. 그 자체로도 가치 있는 실패 기록입니다.

다음에 또 실수하게 된다면 다시 글을 쓰러 오겠습니다.

X (Twitter)에서도 활동 중입니다:
@oji_ai_dev 에서 더 상세한 개발 로그와 기타 잡다한 이야기들을 트윗하고 있습니다.