← [9편] 코인마다 다른 전략을 LLM이 배정하기 + 프롬프트 캐싱으로 비용 1/5한 달 운영 결과는 정직했다.기간: 2026-04-04 ~ 2026-05-06 (33일)입금: 50만원잔고: 47만원손익: -6%, -3만원매도: 265건 (일평균 8.0건)승률은 66.8%였다. 100번 매매하면 67번 이긴다. 그런데 적자다. 어디서 새고 있을까. 백테스트는 흑자였다 — bb_rsi_combined가 메이저(BTC/ETH/XRP) 평균 +7.45%, Buy&Hold -24.75% 약세장에서. 백테는 잘 도는데 실전이 안 되는 것.한 달 동안 시도한 게 한두 가지가 아니었다. 자금 추적 자동화, 손절-매수 충돌 통합, 동적 stop_loss, ROI 테이블 상향, 시간 구간 확..

분석 쿼리 한 줄 때문에 운영 DB CPU가 천장을 치는 경험, 다들 한 번씩 있을 거다.우리도 있었다. 그리고 그 원인이 의외로 단순했다. 시간대 변환.UTC로 저장된 데이터를 KST 기준으로 집계하려고 했을 뿐인데, 그게 인덱스를 완전히 무력화했다. 풀스캔이 일어났고, 분석 쿼리 한 번에 운영 DB가 흔들렸다. 이번 글은 이걸 어떻게 풀었는지에 대한 정리.발단: UTC 저장, KST 집계우리 운영 DB는 모든 timestamp를 UTC로 저장한다. 글로벌 서비스를 고려해 일관된 시간대를 쓰는 건 표준이고, 우리도 그렇게 하고 있었다.근데 분석 요구사항은 KST 기준이다. "5월 5일 KST 하루치 메시지 수 집계해줘" 같은 요청.처음엔 단순하게 풀었다.SELECT COUNT(*) FROM messag..

지난 글에서 우리가 CDC 파이프라인을 JDBC source connector로 구축한 얘기를 했다. 동기화하면서 비정규화 변환까지 함께 처리할 수 있어서 우리 요구사항에 잘 맞는 도구였다.근데 솔직히 그 글에서 못 한 얘기가 있다. 이 도구의 가장 큰 약점은 스키마 변경에 약하다는 거다. 운영하면서 이거 때문에 진짜 자주 깨졌다. 오늘은 그 얘기를 좀 해보려고 한다.평일 오후 3시, 슬랙에 빨간 알림상황은 대충 이렇다. 평화롭게 동기화 잘 되던 평일 오후, 슬랙에 알림이 뜬다.🚨 connector user_activity_mart FAILED. config 백업 후 재시작 시도.뭐 알아서 재시작되겠지 싶다. 10분 주기로 FAILED 감지하면 자동 재시작하는 로직을 돌리고 있으니까.10분 뒤. 다시 ..

데이터가 어느 정도 쌓이면 한 번씩 "이거 한 달에 얼마 쓰는 거예요?" 하는 질문이 들어온다. 우리도 그랬다.운영 DB에 분석 데이터까지 다 쌓아두던 시절엔 분석 쪽 비용도 그냥 Aurora 비용 안에 묻혀 있었다. 그러다 DB가 2TB를 넘기기 시작하면서 "분석용 데이터까지 비싼 Aurora 스토리지에 굳이 둘 필요 있나?" 하는 얘기가 나왔다. 거기서부터 S3 + Athena 전환을 검토하기 시작했다.이번엔 그때 우리가 비용을 어떻게 비교해봤는지 정리해보려고 한다. 정확한 청구서는 공개 못 하니까 단가 기준으로 얘기할 거다.비용 구성 비교먼저 두 환경의 비용이 어디서 나오는지부터 정리해보자.Aurora MySQL 비용 구조:스토리지: GB당 월 약 $0.10I/O 비용: 요청당 별도 과금인스턴스: ..

서비스가 어느 정도 자리 잡고 나면 한 번씩 겪는 순간이 있다. 누가 분석 쿼리 하나 던지면 운영 DB가 픽픽 쓰러지기 시작하는 순간.우리도 그랬다. 비개발 직군에서 "이번 달 액티브 유저 수가 얼마야?", "이 콘텐츠 통계 좀 뽑아줘" 같은 요청이 늘어나면서 운영 DB CPU가 점점 천장을 찍기 시작했다. 처음엔 슬로우 쿼리만 잡으면 됐는데 어느 순간부터는 그것만으론 부족했다. 분석용 데이터를 따로 떼어내야 할 시점이 온 거다.그래서 CDC(Change Data Capture) 파이프라인을 구축하게 됐다. 보통 CDC 하면 Debezium을 떠올리는데, 우리는 Kafka Connect의 JDBC source connector로 갔다. 오늘은 왜 그렇게 골랐는지에 대한 얘기다.우리가 풀어야 했던 진짜 문..

전 코인에 같은 전략을 쓰고 있었다← [8편] 코어 머니 로직 전수 리뷰 — 봇이 흘리는 돈 찾기구조적인 한계가 있었다. LLM은 recommended_strategy 하나만 응답하고, 봇은 그걸 전 코인에 똑같이 적용했다. BTC도 ENSO도 WET도 같은 전략. 시장이 혼재될 땐 어떤 코인엔 맞고 어떤 코인엔 안 맞는다.백테스트로 확인해봤다. 코인별 최적 전략이 완전히 달랐다.KRW-ENSO breakout_momentum(entry=10) +92.0%KRW-WET bollinger_bands(bb=2.5) +59.9%KRW-RENDER ma_crossover(short=5, long=20) +45.0%KRW-TAO volatility_br..

봇이 어디선가 돈을 흘리고 있는 것 같다← [7편] 봇이 알아서 돌게 만들기 — 스케줄러, 안전장치, 그리고 웹 사이트 제작승률은 나쁘지 않은데 잔고가 안 늘었다. 어딘가에서 돈이 새고 있는 게 분명했다. 코드를 한참 들여다봐도 명백한 버그는 안 보였지만, 의심 가는 곳이 너무 많았다. 그래서 결심했다. 코어 머니 로직을 전수 리뷰한다.리뷰 범위를 P0~P4 우선순위로 나누고, 마스터 체크리스트 이슈 하나에 묶었다. 돈에 직접 영향 가는 P0 → 토큰/비용 정확도 P1 → 엣지 케이스 P2 → 테스트 보강 P3 → 데이터 위생 P4. 한 번에 다 보지 않고, 순서대로 잡았다.P0: 돈 유실 — OrderResult.success=False의 함정가장 먼저 발견한 위험은 매수/매도 함수의 실패 처리였다.#..

사람이 안 봐도 되는 봇을 만들자← [6편] 실전 투입하자마자 터진 버그 6개 — 테스트에서 못 잡는 것들6편에서 하루 만에 hotfix 6개를 쏟아낸 뒤, 확신이 생겼다. 이대로는 안 된다. 내가 24시간 로그를 보고 있을 수는 없다. 봇이 스스로 검증하고, 문제가 있으면 알아서 멈추고, 정기적으로 상태를 점검하는 시스템이 필요했다.매매 5중 검증 — 믿을 수 있는 거래6편의 버그들을 겪고 나서 매매 과정 전체에 검증 레이어를 쌓았다.# 1. 가격 검증 — 0이나 직전 대비 20% 급변 시 스킵if price 0.2: alert("비정상 가격 감지") return# 2. 주문 체결 검증 — success=True여도 실제 잔고 확인result = trader.buy_market(coin, ..