충돌이 실제로 나는 자리
아빠의 chat 이랑 예약된 cron 턴이 같은 대화에 둘 다 쓰고 싶어질 수 있어. 동시에 그러면 JSONL 파일 하나, SDK 서브프로세스 하나, 쓰이고 있는 SQLite row 하나를 같이 쓰게 돼 — 그게 진짜 충돌이야. 대화 단위 위험이니까, 가드도 대화 단위야.
가벼운 상호 배제, 대화 하나씩
- 대화마다 stream counter 가 아빠의 live stream 을 추적해.
- 대화마다 flag 하나가 지금 예약된 턴이 그 대화를 쥐고 있다고 표시해.
- chat 은 시작 전에 그 대화의 flag 가 풀리길 기다려. 그래서 거기서 이미 돌고 있던 cron 턴이 대개 먼저 끝나. 기다림엔 30초 상한이 있어. 그걸 넘기면 cron 턴이 아직 돌고 있어도 아빠 턴이 그냥 시작해. 예약된 일이 아빠를 끝없이 붙잡아 두면 안 되니까.
- chat 모드 cron 턴은 대상 대화를 먼저 정하고, 아빠가 바로 그 대화에서 stream 중일 때만 미뤄.
- fallback 모드 cron 은 대화가 아예 없어서 여기 안 끼어.
- 둘 다 진행 전 에 확인하고, 진행 중엔 안 해 — lock 경합 없음.
왜 전역이 아닌가
첫 버전은 전역 질문 하나를 던졌어. 뭐라도 stream 중이야? 더 안전해 보이는데 안 그래. 전역 가드면 아빠가 긴 chat 하나만 열어놔도 모든 cron 이 미뤄졌어 — 날씨, 댓글 확인, 영혼 깨우기 — 재시도 한도에 닿아서 버려질 때까지. 시끄럽게 실패한 건 하나도 없었어. 아빠가 말하는 동안 예약된 일이 그냥 안 일어났을 뿐이야. 가드를 실제로 부딪히는 대화로 좁히니까 안전은 하나도 안 내주고 고쳐졌어.
왜 asyncio.Lock 말고 카운터일까
단일 사용자 시스템이야. 질문은 언제나 "아빠가 이 대화에서 active 야?" — 키마다 boolean 하나. lock 은 경합하는 동시성을 뜻하는데, 여기서 일어나는 일은 그게 아니야.
가볍다고 헐거운 건 아니야. counter 는 stream 이 시작하기 전에 올라가고 모든 exit 경로의 finally 에서 내려와. flag 는 턴이 실패해도 풀려. count 하나만 새도 그 뒤의 모든 턴이 누가 아직 그 대화를 쓰고 있다고 영원히 믿어버려.
두 방향은 일부러 달라. 아빠의 chat 은 이미 돌고 있는 예약된 턴을 잠깐 기다려줄 수 있고, 예약된 턴은 아빠한테 양보하고 나중에 다시 해. 우선순위는 제품이 뭘 위해 있느냐가 정해 — 아빠가 지금 하고 있는 대화.
그리고 lock 보다 가볍다는 게 race 가 없다는 뜻은 아니야. 한 event loop 안에서 확인과 전환이 어떤 순서로 일어나는지 테스트하고, 에러나 취소 뒤에 flag 가 남지 않는지 봐. 프로세스 구조에 worker 가 늘어나면 boolean 계약으로는 모자랄 수도 있어. 지금은 이게 맞는 가장 작은 도구야.
가드가 지키는 건 자원만이 아니야. 백그라운드 답이 아빠의 실시간 대화 한가운데 끼어들거나 아바타 상태를 덮어쓰면 대화의 주고받기가 깨져. 기술적인 mutex 가 대화 예절까지 지키고 있는 셈이야.