처음 dreaming 이야기가 나왔을 때는 프로젝트 코드 점검으로 생각하기 쉬웠습니다. 밤에 CLAB이나 SEOJing repo를 돌면서 테스트를 확인하고, TODO를 찾고, 작은 개선을 하는 식입니다. 그런데 진규가 원한 방향은 조금 달랐습니다. 대상은 프로젝트가 아니라 오케이징 자체였습니다.
오케이징이 최근 세션, 티켓, 실패 로그, skill, memory를 보고 스스로 운영 방식을 개선할 수 있으면 어떨까. Claude Code의 Dreaming처럼 사용자가 쓰지 않는 시간에 스스로 돌아보고, 아침에는 필요한 것만 브리핑하면 어떨까. 여기서 OkejING Dreaming이 시작됐습니다.
현재 구상은 두 단계입니다. 새벽에는 조용히 점검하고, 아침에는 진규에게 요약합니다.
| 시간 | 역할 | 전달 |
|---|---|---|
| 새벽 4시 | self-improvement dreaming | local 저장 |
| 아침 8시 | dreaming 결과와 기술 인사이트 브리핑 | Discord origin |
새벽 작업은 조용히 돕니다. 최근 세션과 티켓을 훑고, 반복된 실패나 오래된 skill을 찾고, Hermes docs나 agent workflow 관련 인사이트를 봅니다. 아침 작업은 그 결과를 사람이 읽을 수 있게 정리합니다. 적용된 개선, 승인 필요한 제안, 주목할 기술 흐름을 나눠서 전달합니다.
자가개선이라고 해서 아무거나 바꾸면 안 됩니다. 자동 적용은 저위험 영역으로 제한합니다. 예를 들어 skill 문서에 누락된 pitfall을 추가하거나, 반복된 명령 실수를 절차로 정리하는 정도입니다.
이런 변경은 되돌리기 쉽고, 시스템의 위험도를 크게 바꾸지 않습니다. 그래서 자동 적용 후보가 될 수 있습니다.
반대로 오케이징의 행동 범위를 바꾸는 작업은 승인 없이 하면 안 됩니다. config, gateway, provider, plugin, source code는 작은 변경처럼 보여도 실제 영향이 큽니다.
| 구분 | 예시 |
|---|---|
| 승인 필요 | SOUL.md 수정, Hermes config 변경, gateway restart, provider/model 변경, plugin 설치 |
| 자동 금지 | secret 변경, destructive command, main force push, commit/push/PR, 토큰 권한 변경 |
Dreaming의 핵심은 오케이징이 스스로 좋아지는 것이지만, 동시에 스스로 사고치지 않는 것입니다. 자동화의 범위가 넓어질수록 승인 경계는 더 분명해야 합니다.
작업 보고서는 특정 작업의 결과를 남기는 문서입니다. 브리핑은 다릅니다. 밤사이 발견한 운영 인사이트를 사람이 부담 없이 읽을 수 있게 압축하는 것입니다.
그래서 아침 브리핑에는 긴 로그를 붙이지 않는 편이 좋습니다. 대신 이런 식으로 정리하는 게 맞습니다.
1. 밤사이 적용한 저위험 개선
2. 발견한 문제
3. 승인 필요한 제안
4. 오늘 볼 만한 agent / memory / orchestration 인사이트
5. 다음 실험 후보
오케이징이 아무리 많은 걸 봐도, 진규가 아침에 읽을 수 없으면 의미가 없습니다. dreaming의 절반은 점검이고, 나머지 절반은 압축입니다.
OkejING Dreaming은 프로젝트 자동 수정기가 아닙니다. 오케이징 운영 자체를 조금씩 정리하는 루프입니다. 사용자가 부르지 않는 시간에 최근 흐름을 돌아보고, 저위험 개선은 적용하고, 위험한 제안은 아침에 물어봅니다.
이 구조가 잘 자리 잡으면 오케이징은 단순히 요청에 반응하는 쪽에서 조금 벗어납니다. 물론 마지막 결정권은 여전히 진규에게 있습니다. dreaming은 사람을 대체하는 게 아니라, 사람이 아침에 더 좋은 결정을 하게 만드는 보조 루틴입니다.