dpdpdndn 블로그

자동매매봇 티켓 분해 DAG

NEW4 min read

자동매매봇 티켓 분해 DAG

근거 설계: TDD · PRD

Wave 너비 분포

Wave너비티켓
12DB-01, BE-01
28BE-02, BE-03, BE-04, BE-05, BE-06, BE-07, BE-08, BE-09
33BE-10, BE-11, BE-12
43BE-13, BE-14, BE-15
52BE-16, BE-17

총 18티켓. 직선형 DAG가 아니다 — wave 2에서 8폭으로 벌어진다.

flowchart LR
    DB01[DB-01 스키마] --> W2[wave2 애그리게이트 8]
    BE01[BE-01 도메인 계약] --> W2
    W2 --> W3[wave3 도메인서비스 3]
    W3 --> W4[wave4 UseCase 3]
    W4 --> W5[wave5 통합 2]

병목 처리

  • 연관 병목은 하나로 묶었다 — enum·값 객체·Repository/Gateway interface를 BE-01 한 티켓으로 합쳤다. 쪼개면 후행이 서로를 기다려 1→1→1 직렬 사슬이 된다.
  • 독립 병목은 쪼갰다 — DB-01(Flyway SQL)은 BE-01(Kotlin 계약)과 파일이 겹치지 않아 wave 1에서 병렬로 간다.
  • 후행 의존 카운트 ≥ 3인 티켓은 BE-01(전 후행)과 DB-01(wave 2 애그리게이트 5개)뿐이며, 둘 다 더 쪼개면 직렬화되는 불가피한 병목이다.

Single Writer per File 검증

같은 wave 내 수정 파일 교집합이 ∅ 인지 확인한다.

Wave 1

티켓수정 파일 범위
DB-01backend/src/main/resources/db/migration/V*__create_autotrading_tables.sql
BE-01backend/.../autotrading/domain/ (enum·값객체·interface), backend/.../order/domain/ConditionalOrderGateway.kt

교집합 ∅ ✓

Wave 2

티켓수정 파일 범위
BE-02autotrading/domain/AutoTradingPolicy.kt, autotrading/infrastructure/mysql/AutoTradingPolicy*
BE-03autotrading/domain/TradingDay.kt, autotrading/infrastructure/mysql/TradingDay*
BE-04autotrading/domain/OrderProposal.kt, autotrading/infrastructure/mysql/OrderProposal*
BE-05autotrading/domain/TradingPosition.kt·TradingFill.kt, autotrading/infrastructure/mysql/TradingPosition*·TradingFill*
BE-06autotrading/domain/TradingCostModel.kt·PositionSizer.kt, ml/tests/test_cost_model_parity.py
BE-07autotrading/domain/RiskGate.kt
BE-08order/infrastructure/toss/TossConditionalOrderGatewayImpl.kt·TossConditionalOrderDtos.kt
BE-09autotrading/infrastructure/notification/DiscordAutoTradingAlertGateway.kt

교집합 ∅ ✓ — 애그리게이트마다 파일 접두사가 다르고, BE-08은 order 패키지 신규 파일만 만든다(기존 OrderGateway.kt 미수정).

Wave 3~5

티켓수정 파일 범위
BE-10autotrading/domain/PaperTradeExecutor.kt·LiveTradeExecutor.kt
BE-11autotrading/domain/AutoTradingDomainService.kt
BE-12autotrading/domain/TradingSettlementDomainService.kt·RiskTierPromotionDomainService.kt
BE-13autotrading/application/RunAutoTradingCycleUseCase.kt + Command/매퍼
BE-14autotrading/application/{Approve,Reject}OrderProposalUseCase.kt·ToggleKillSwitchUseCase.kt·조회 UseCase 2종
BE-15autotrading/application/{SyncPositionFills,SettleTradingDay,EvaluateRiskTier}UseCase.kt
BE-16autotrading/presentation/AutoTradingApiController.kt·스케줄러 2종, application.yml
BE-17backend/src/test/.../autotrading/isolation/·scenario/

교집합 ∅ ✓ — UseCase는 1개 = 1파일 원칙을 지키므로 파일 단위로 갈린다. 공통 파일(application.yml) 수정은 BE-16 통합 티켓 단독에 몰았다.

공용 테스트 헬퍼 선점 소유

BE-01이 소유한다. 아래를 만들고 판정 기준·근거를 티켓에 남긴다.

헬퍼용도
TradeCandidateFixture신호 후보 픽스처 (등급·점수·현재가 조합)
AutoTradingPolicyFixture모드·단계·킬스위치 조합 픽스처
CostModelParityFixtureml/app/cost_model.py와 교차 검증할 공통 입력·기대값 표

후행 wave 티켓은 소비만 하고 새로 만들지 않는다. 새 헬퍼가 필요해지면 직접 만들지 말고 BE-01로 되돌려 보고한다.

실제 사고 이력: 두 티켓에 각각 리뷰 지적이 가서 두 구현자가 주석 한 줄만 다른 동일 헬퍼를 같은 경로에 만든 적이 있다. 설계 단계 Single Writer 검증은 통과한 상태였다.

마일스톤 매핑

마일스톤티켓
M1 페이퍼 루프DB-01, BE-01, BE-02~06, BE-10(Paper만), BE-11, BE-13, BE-16
M2 리스크·안전장치BE-07, BE-09, BE-12, BE-14, BE-15, BE-17
M3 조건부 자동 + 검증신규 티켓 없음 — BE-14 승인 흐름과 BE-12 단계 평가를 운영으로 검증
M4 라이브 전환BE-08, BE-10(Live) — 코드는 미리 배포하되 정책 모드가 PAPER인 한 호출되지 않는다

그래프 뷰