2026-05-26 (화) 개발일지
오늘은 동백전 데모 앱의 iOS/Android 양 플랫폼 OTel 연동을 끝내고, bit-scalp 전략의 1년 백테스트 결과와 손실 패턴 분석을 마무리한 하루였다. 중간에 dev-blog 생성 로직의 톤을 수정하고, VM 디스크 꽉 참 문제를 진단해 문서로 남겼다.
dev-blog 생성 로직 — 정체성 수정
dev-blog가 summarize.py로 생성될 때, 사용자가 보낸 명령을 그대로 인용하면서 “AI 활용 회고 일지” 톤으로 흘러가는 문제가 있었다. 원인은 프롬프트 템플릿(PROMPT_TEMPLATE)과 데이터 수집(_build_context) 두 곳에 동시에 박혀 있었기 때문이다.
프롬프트 도입부에 “이 글의 정체성은 개발 블로그 — AI 사용 후기/프롬프팅 방법론이 아니다” 라는 한 문단을 강화하고, 마지막에 자체 검증 규칙을 추가했다.
글을 다 쓴 뒤 “AI” 라는 단어를 모두 지워도 글이 개발 회고로 성립한다면 톤이 맞은 것이다.
바뀐 점
summarize.py프롬프트 도입부 개선MEMORY.md와feedback_devblog_identity.md생성 — 다음에 로직을 수정할 때도 규칙이 유지되도록
bit-scalp — 1년 백테스트 결과와 손실 패턴 분석
메이저 10종 코인을 대상으로 현재 전략을 1년치 백테스트했다. 총 진입 건수는 15,899건(LONG 13,797 + SHORT 2,102), 전체 승률 62.9%(LONG 61.0%, SHORT 75.2%), 평균 PnL +0.98%/건 이 나왔다.
슬롯 기반 트레이딩 시뮬레이션에서 일 최대 7.2사이클(3슬롯 × 2.4 cycle)인데 반해 진입 가능 건수는 일평균 43.6건이므로 활용도가 16.5%에 불과했다. 슬롯 부족이 명확한 병목.
이어서 손실 패턴을 분석했다. 5,968건의 손실 케이스에서 peak PnL 분포를 보니, 사용자 가설 영역(peak 1-2%)이 30.5% 였고, + 갔다 반전 패턴(peak 양수였다가 마이너스)이 전체의 54.6% 였다. 즉, 이익 구간을 지키지 못하고 떨어진 경우가 절반이 넘는다. 반면 즉시 손실(peak <0.5%)은 22.5%였다.
| 구간 | 비율 |
|---|---|
| peak <0.5% (즉시 손실) | 22.5% |
| peak 1-2% (사용자 가설 영역) | 30.5% |
| + 갔다 반전 | 54.6% |
남은 과제: 슬롯 최적화(→ TP/SL 조정으로 보유 시간 단축)와, 반전 패턴을 탐지하는 조기 청산 로직 검토.
demo_apps — 동백전 iOS/Android OTel 연동 완료
동백전 데모 앱에서 양 플랫폼 모두 APM/RUM trace, log, behavior를 수집하는 파이프라인을 구축했다.
iOS (Riff 9)
- SwiftUI로 7화면(Login, Home, Payment, PaymentResult, QR, Transfer, BalanceDetail) + OTP 플로우 구현
BackendClient.swift로 단일 HTTP 클라이언트 통합OTelAdapter,BehaviorAdapter로 trace/log/behavior 송신- 시뮬레이터 검증 완료, ClickHouse에 모든 trace 도달 확인
Android (Riff 10)
- iOS를 Jetpack Compose로 미러링,
MainActivity.kt+ 7개Screen.kt+BackendClient.kt,Session.kt gradle assembleDebug빌드 성공 (52초, 55 tasks)- adb로 자동 시나리오 진행 가능 (iOS idb 막힌 것과 달리 자유로움)
- OTel endpoint
<INTERNAL_IP>설정, 서버 스택 4종 전부 200 OK 확인
중요 발견: Android의 /ingest/behavior가 400 에러를 반환 — iOS는 동일 endpoint가 정상이므로 SDK Android 쪽 schema 문제로 진단. screen.* trace는 12건(6종 화면) 모두 도달했지만, behavior/RUM은 막힌 상태.
수정·생성 파일: 14개 파일 신규/수정 (DongbaekDemoApp.swift, BackendClient.swift, HomeScreen.kt 등)
otel_study — VM 디스크 가득 참 진단 및 문서화
SSH 연결 후 VS Code 서버가 기동되지 않는 문제를 추적했다. 서버 로그에서 listeningOn==, serverStartTime==35ms — 즉 서버가 35ms 만에 종료되어 포트를 전혀 열지 못했다. 이후 rm -rf ~/.vscode-server`를 실행하자 에러가 “설치 디렉토리 생성 실패”로 바뀌었다.
디스크 사용량을 조사:
df -h→ 루트/가 38GB 중 38GB 사용 (100%)du -sh /*→/전체가 40GB로 나와 모순 발생- 원인: LVM 기본 설치로 물리 디스크 80GB 중 root LV에 38GB만 할당되고 나머지는 VG에 미할당 상태
- 해결:
lvextend와resize2fs로 root LV 확장 필요
SSH 접속 후 VM 내에서 작업할 수 있도록 INCIDENT-HANDOFF.md 문서를 프로젝트 디렉토리에 생성해 전달했다.
게임 — shadowing 경고는 무해, Mac 윈도우 매니저 문제
home.gd:157의 size 파라미터 shadowing 경고(W 줄)는 게임 실행 자체를 막지 않았다. 헤드리스 4초 실행 결과 _ready()가 정상 통과하고 180프레임 후 자동 종료까지 확인되었다. 사용자 화면에 창이 보이지 않던 이유는 Mac에서 에디터 뒤에 게임 창이 깔렸거나, F5 트리거 문제로 실제로 실행되지 않았기 때문. 터미널에서 직접 Godot 바이너리로 실행하도록 우회법을 제시했다.
오늘의 한줄
데모 앱의 양 플랫폼 OTel 연동이 막혔던 behavior ingest 400 에러는 Android SDK schema 쪽에 원인이 있다는 걸 확인했고, VM 디스크 문제는 LVM 할당이 원인이었다.