← 빌드 일지
AI Lab2026-05-12·12분 읽기

Anthropic의 Dreaming, 1인 빌더용으로 직접 구현 — 트레이딩 봇의 첫 꿈, 그리고 다음 날 백테스트가 그걸 뒤집은 이야기

Anthropic 이 Dreaming 을 발표한 지 5일. 주말에 트레이딩 봇용으로 4단계를 직접 구현했다. 첫 dream 이 KST 00~05시 흑자 패턴을 찾았고, 다음 날 풀-히스토리 백테스트가 그걸 뒤집었다. 이게 맞는 루프다.

<!-- Title alternates considered: - "AI가 AI의 기억을 정리한다 — 트레이딩 봇에 적용한 Anthropic Dreaming 4단계" - "앤트로픽 Dreaming을 솔로 빌더가 따라 만들면 — 4단계 구현기" "백테스트가 뒤집은 이야기" 절을 제목에 넣은 이유: 한국어 dev 독자는 hype 보다 정직한 후속 검증을 더 무겁게 본다. "찾았다" 만 있는 글은 이미 영어로도 한국어로도 없다 (Korean 은 0건). "찾았다 + 그게 틀렸다" 가 차별점. -->

Anthropic 이 Dreaming 을 공식 발표한 지 5일 됐다 (2026-05-06, Code w/ Claude). 주말에 1인 트레이딩 봇용으로 4단계를 직접 구현했다. 첫 dream pass 가 KST 0005시 흑자 / 0710시 적자라는 깔끔한 시간대 패턴을 찾아냈다. 다음 날 풀-히스토리 백테스트를 돌리니 그 신호가 무너졌다 — Bonferroni 통과 0개, walk-forward filter 일반화 실패, 47일 손실의 69%가 단 3일에 집중.

Dreaming 이 가설을 떠올렸고, 그 다음 백테스트가 그 가설을 부정했다. 이게 맞는 루프다. 대부분의 "Dreaming 이 뭐야" 글은 두 번째 절반을 빼먹는다.

이 글은 그 빌드, 발견, 그리고 부정의 기록.

앤트로픽의 Dreaming 이란

Dreaming 은 long-running Claude agent 를 위한 메모리 컨솔리데이션 기능이다. 에이전트가 코드베이스나 도메인에서 몇 시간~며칠 작업하면 컨텍스트 창이 raw transcripts, tool 출력, 부분 결론, 모순으로 가득 찬다. Dreaming 은 offline pass 로 누적된 상태를 스캔하고, 패턴을 추출하고, 모순을 해결하고, stale 참조를 잘라내고, 정리된 컨솔리데이션 메모리를 다시 쓴다. 깨어났을 때 에이전트는 더 작고 날카롭고 모순 적은 view 를 가진다.

앤트로픽이 managed-agents 발표에서 디자인을 공개했다 (2026-05-06). 3rd party 가 dream-skill (grandamenium) 로 4단계 루프를 누구나 설치 가능한 skill 로 정형화했다 — Orient → Gather Signal → Consolidate → Prune & Index. 내가 적용한 패턴은 이거다.

1인 빌더가 왜 필요한가

WILD_SNIPER 라는 1인 운영 암호화폐 트레이딩 봇이 있다. 2026-05-10 시점에 active-work/wild-sniper.md 가 331줄까지 부풀어 있었다. "Previous current state" 블록 3개가 서로 모순되고 있었다. 폐기된 봇 버전 (V3.9.x 포크, V4.0 paper 로그) 참조가 라이브 V3.7.1 사실 옆에 그대로 남아있었다. 4/22 의 "전략 락" 입장은 forensic 분석으로 뒤집혔는데 그 override 노트는 다른 섹션에 있었다.

이게 이론적인 지저분함이 아니다. 2026-04-30 봇이 self-kill loop 에 빠졌다 — 일일 손실 한도 트리거 (정상 안전 동작), watcher 데몬이 매 사이클마다 봇 재기동, 봇은 트립된 한도를 다시 감지하고 즉시 재셧다운. Watcher → bot → watcher → bot, 자정까지. 봇 자체는 설계대로 100% 정상 작동했다. Watcher 의 재기동 정책이 트립된 일일 한도를 알지 못한 게 버그. 메타데이터 갭이 사고를 만들었다.

stale 메모리가 그 사고의 직접 원인은 아니지만, 사후분석에서 비용이 명확해졌다 — 봇 메타 상태가 331줄과 모순된 3개 섹션에 흩어져 있으면 운영자가 빠르게 반응할 수 없다. 메모리 위생이 housekeeping 이 아니라 인프라 작업이 된다.

4단계 패턴

/dream-sniper 슬래시 명령어를 작성해서 일요일 09:33 KST 마다 봇 누적 상태에 한 번씩 돈다. 출처: ~/.claude/commands/dream-sniper.md. 4단계.

Phase 1 — Orient (스캔)

모든 입력 surface 를 인벤토리. 줄 수 카운트, 마지막 수정 시각 기록, 패턴 빈도 스캔. 아직 풀 read 는 안 함 — 측정만.

입력은 4 카테고리: 현재 상태 노트 (active-work 메모), 누적된 트레이드 로그 (최근 4주), 런타임 로그 (최근 7일), 봇 헬스 상태 파일. 이 단계는 size 와 recency 만 측정 — 실제 컨텐츠 read 는 Phase 2 에서 일어남.

Phase 1 출력은 작은 JSON 스냅샷: 각 영역의 줄 수, 마지막 수정 시각, 핵심 patterns 카운트. 의도적으로 가볍게 설계.

AI Agent Dreaming의 4단계 — Orient → Gather Signal → Consolidate → Prune & Index

Phase 2 — Gather Signal (시그널 수집)

타겟 추출. 탐색 카테고리는 의도적으로 추상적 — 실제 봇의 진입 조건, 사이즈 산정, 임계값들은 봇 내부에 있고 글에서는 다루지 않는다. Dream pass 는 카테고리에 시그널이 있는지 surface 하는 역할. what 은 봇이 들고 있다.

스캔하는 카테고리: 시간대 패턴 변화, 심볼별 반복 실패 모드, 성공 조건 클러스터, active-work 의 사용자 결정 audit, 사용자 정정 / 선호 변경 propagate.

무거운 분석은 도메인 specialist subagent 에 위임 — 메인 컨텍스트로 전부 끌어오지 않는다. dream pass 를 가볍게, 분석은 sharp 하게 유지하는 패턴.

Phase 3 — Consolidate (통합)

발견을 canonical 메모리에 통합. 상대 날짜 ("어제", "지난주") → 절대 날짜. 모순된 결정은 최신 채택. Stale 참조 제거.

이 단계의 결정적 안전 장치는 보호 파일 리스트. 특정 메모리 파일들 — 자율성 룰, 가족 PII, 다른 프로젝트 컨텍스트, 사용자의 명시 선호 — 는 어떤 dream pass 변경에서도 명시적으로 제외. 이 룰이 없으면 dream pass 가 다른 프로젝트에 load-bearing 한 정보를 명랑하게 "정리" 해버리거나, 더 나쁘게는 사용자의 명시 룰을 drift 시킨다.

Phase 4 — Prune & Index (정리 + 인덱스)

파일 크기 hard cap: wild-sniper.md 200줄 미만 유지. 오래된 "Previous current state" 블록은 archive/wild-sniper-<date>.md 로 이동. 메모리 인덱스에 새 인사이트 한 줄 요약 추가.

archive 는 삭제가 아니다. 전부 복구 가능. 단지 active 파일이 날카롭게 유지됨.

첫 dream — 실제로 발견한 것

첫 pass 는 2026-05-10 23:42 KST 에 돌았다. 풀: V3.7.1 sub-era A, 4/7~4/30 트레이드, N=236.

헤드라인 재확인: 실현 R:R 0.499. trade 당 기대값 -$0.039. 24 활성 거래일 누적 PnL -$9.25. 수학이 내부적으로 일관 — 이 전략은 노이즈가 아니라 느린 누수다.

새 발견은 KST 시간대의 강한 패턴:

시간 (KST)NWRPnL
001283.3%+$1.49
011687.5%+$0.94
041376.9%+$0.04
052564.0%+$0.33
072842.9%-$1.65
081020.0%-$1.69
101910.5%-$2.34

심야 아시아 (00-05 KST): WR 6487%, 순흑자. 아시아 오전 오픈 (07-10 KST): WR 1043%, 순적자. 10시 한 시간만 N=19 에 -$2.34 누수.

깔끔하게 시사적. 쉬운 스토리: "봇은 저거래량 아시아 야간 윈도우에서 엣지가 살아있고 모닝 오픈에서 도살된다."

Dream 전후 메모리 상태 — 1,200줄 혼란에서 180줄 인덱싱으로

정직한 후속 — 다음 날 백테스트가 무너뜨렸다

다음 날 920 라이브 페어드 트레이드, 12개 봇 버전, 47일 데이터 전체로 풀-히스토리 백테스트를 돌렸다. Entry-side feature 만 사용 (entry 시점에 알 수 없는 exit type / slippage 같은 post-trade 관측치를 쓰면 lookahead bias — 첫 pass 에서 그 실수를 했고 두 번째에 고쳤다).

69개 univariate 가설 결과:

  • Bonferroni 통과 (alpha = 0.000725): 0
  • BH-FDR 통과 (alpha = 0.05): 0
  • Raw-p < 0.05 통과: 3 (hour 10, hour 8, Friday)

raw-p 통과 3개 중 가장 강한 신호 (Friday, p=0.0235) 는 128개 금요일 트레이드 중 102개가 단 하나의 금요일 — 2026-04-03 — 에서 나온 거였다. "금요일이 나쁘다" 는 구조적으로 "4월 3일이 나빴다" 였다.

Dream 의 00-05 KST 신호는 보정된 리스트에 안 나타난다. 더 넓은 풀에서: hour 0 raw-p 0.039, hour 1-4 는 raw 통과조차 못 함, hour 5 는 오히려 적자. 패턴은 V3.7.1 sub-era A 안에선 진짜였지만 다른 봇 버전들에 일반화하지 못했다.

Walk-forward 70/30 split (train cutoff 04-20 05:35 KST) 가 결정적 검증. Train 에서 derive 한 filter 를 test 에 적용:

SetNCum PnLWR
Test baseline276-$16.6143.1%
Test filtered250-$14.0642.8%

Filter 가 $2.55 절약. Conservative cost 95% 부트스트랩 CI: [-$23.90, -$11.53]. 양쪽 모두 확실히 negative.

self-correction 라운드의 가장 불편한 발견 — 최악의 3일 (04-03, 04-25, 04-26) 이 -$13.01 을 차지했고, 이게 47일 -$18.82 손실의 69%다. 그 3일 빼면 봇은 거의 손익분기.

"00-05 좋다" 패턴은 시간대에 대한 신호가 아니었다. 몇 개 특정한 catastrophic trading day 가 그 윈도우 밖에 떨어진 부산물이었다. 증상을 패치하면 병은 계속 갉아먹는다.

Dreaming 이 잘하는 일, 못하는 일

잘하는 일:

  • 메모리 위생. 331줄 active-work 가 수동 archive 없이 200줄 미만으로 갈 경로가 생긴다.
  • 패턴 감지. 시간대 발견은 (sub-era A 안에선) 진짜였고 surface 할 가치가 있었다.
  • 가설 생성. Dream 이 다음 날 백테스트의 질문을 줬다.
  • 결정 audit trail. Recent activity 엔트리가 잃어버리기 어려워진다.

못하는 일:

  • 떠올린 패턴을 검증하는 일. 그건 별도 단계 — 백테스트, walk-forward, 다중비교 보정.
  • 확인 pass 없이 dream 출력대로 행동하는 것. 시스템은 가설을 싸게 만들고 행동을 비싸게 만들어야 한다.
  • 도메인 분석을 대체하는 것. Dream pass 는 설계상 얕다 (grep + 카운트 + 위임된 analyst). 진짜 작업은 후속에서 일어난다.

정직한 프레이밍: dream 이 "이거 뭔가 있어 보인다" 를 surface 한다. 다음 날 엄격한 백테스트가 그게 진짜 뭔가인지 답한다. 5/10 dream 은 "00-05 KST 가 흑자 같다" 라고 말했고. 5/11 백테스트는 "아니다, 특정 3일이 catastrophic 했고 시간대 패턴은 그 날들이 어디 떨어졌는지의 부산물이다" 라고 답했다. 두 pass 모두 자기 일을 했다.

비용 / 인프라

Claude Max 구독 잉여 quota 위에서 돈다. healthcheck 한 번 약 2k 토큰, weekly dream 한 번 약 10k 토큰. 일 합계 14k 토큰 미만, 평균 사용자 월 한도의 1% 미만. 대부분 구독자가 plan 의 5~15% 만 쓰고 나머지 85% 는 안 쓰고 매월 사라지는 quota. 그 잉여에 monitoring agent 를 얹으면 추가 비용 $0.

인프라 패턴: cron 1개당 슬래시 명령어 1개, 활성 프로젝트당 cron 2개 (/sniper-healthcheck 4시간마다, /dream-sniper 주간 일요일). 세션 시작 시 auto-rehydrate 로 PC 재부팅 후에도 cron 잡이 수동 개입 없이 살아남는다.

1인 빌더의 Dreaming 스케줄 — 168시간 주간 사이클 (healthcheck / daily journal / Sunday dream)

결론 — 도구보다 루프가 중요하다

Dreaming 은 마법이 아니다. 1인 빌더가 기존 슬래시 명령어 시스템 위에 주말 안에 구현 가능한 4단계 패턴이다. 패턴은 공개되어 있다 — 앤트로픽의 managed agents 발표와 grandamenium 의 dream-skill 레포가 빌드 자료로 충분했다.

이 글에서 가져갈 만한 건 "go install dream-skill" 이 아니다. 루프다 — 빠른 cadence 로 싼 패턴 surface, 느린 cadence 로 비싼 검증. Dream 은 틀려도 된다. 백테스트는 맞아야 하는 부분이다. 두 조각이 다 있으면 시스템이 날카로워진다. Dream 만 있으면 시스템이 자신감 있게 틀려간다.

V3.7.1 은 변경 없이 계속 돈다. 어떤 filter 도 추가 안 했다. 다음 2주는 관찰.

받은 영수증만, 약속은 사절.


English version

Wildeconforce

매일 만들고, 매일 분석하고, 매일 기록합니다.
© 2026 wildeconforce · build-in-public

이 사이트는 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.