[신투 프디아] 조건 탐지의 시작 - 44개의 지표를 코드로 옮기다

 

 

 

 

 

 

이 글은 알파코에서 진행되는 [신한투자증권] 프로디지털아카데미 과정 중, 김송아 강사님과 함께하는 '파이널 프로젝트'를 기반으로 작성되었습니다

우리 프로젝트의 키포인트는 같은 카테고리끼리는 or, 각각의 카테고리 끼리는 and로 처리돼서 울리는 것이다.

42개(시가, 종가 알림 제외)의 조건들을 모두 if-else로 다 처리하는 건 본능적으로 아니라고 느껴졌다..

 

그래서 모든 조건을 컴포넌트 단위로 분리했다.

인터페이스를 통해 공통 형태를 묶고, 각 조건은 어노테이션으로 매핑되게 하여 팩토리가 자동으로 등록하고 찾아주는 구조이다.

 

덕분에 BOLLINGER_LOWER_TOUCH 같은 조건이 들어오면 자동으로 해당 evaluator(조건탐지기)가 선택돼서 실행된다.

 

 

 

 

 

 

 

구조를 이렇게 짠 이유

1. 조건 추가가 간단해야 했다.

새 지표를 만들 때마다 기존 코드를 건드리는 건 위험했다. 새로운 조건 클래스를 만들고 @ConditionTypeMapping(ConditionType.XXX) 만 붙이면 끝나도록 하였다.

 

2. 테스트가 독립적으로 돌아야 했다.

각 evaluator가 단독으로 테스트할 수 있도록 공통 의존성을 최소화하고, 인터페이스로 분리했다.

 

3. 실시간 데이터와 맞물려야 했다.

Redis에 쌓은 minute: / daily: 데이터를 가져와서 각 evaluator가 판단할 수 있도록 했다

 

 

 

고민했던 부분들

- 지표별 evaluator를 다 따로 두는 게 너무 많은가?

처음엔 공통화하려다, 결국 각각 독립이 낫다고 결론을 내렸다. 이유는 조건마다 판단 계산식이 완전히 달라서 였다. 억지로 통합하려 하면 오히려 if문 지옥이 펼쳐질 것 같았다.

 

- Factory vs Manager 구조를 분리해야 하나?

Factory는 evaluator 등록/조회, Manager는 실제 실행 + Redis 연결 관리로 역할을 분리했다. 단일 책임 원칙(SRP)을 지키려는 시도였다.

 

- Redis 타입이 바뀌면 어떻게 대응할까?

실제로 WRONGTYPE 에러를 몇 번 맞으면서 key 타입 검증 로직을 추가했다. 이때 “안정성은 디테일에서 나온다”는 걸 다시 느꼈다.

 

 

정리하자면

44개의 조건을 코드로 옮긴다는 건 단순한 작업이 아니었다.

확장 가능한 설계에 대해 고민하는 시간이었다.

조건은 계속 늘어날수도, 줄어들수도 있고, 데이터는 매 분 바뀌고, 조건의 조합은 늘 다르다.

 

결국은 로직이 늘어나도 단순하게 유지할 수 있는 구조를 생각했다.