설계 문서를 열었더니 '무엇을 만들지'보다 '무엇을 건드리지 않을지'가 길었습니다
이번에 쓴 것은 코드가 아니라 설계 문서입니다. 앱 다운로드를 유도하는 숏츠 채널을 새로 만드는 계획이고, 구성은 단순합니다. 영상 앞부분의 hook과 마지막의 킥, 이렇게 두 부분입니다. 한국어, 영어, 일본어 채널을 각각 새로 열고, 앱은 App Store 네이티브 앱을 우선합니다. 킥은 프로필로 시선을 옮겨 앱 목록 페이지로 넘어가게 하는 CTA이고, 여기에 다시 돌아오게 만드는 리텐션 루프를 붙입니다.
문서를 쓰다 보니 분량이 다른 쪽으로 쏠렸습니다. 새 채널이 무엇을 보여줄지보다, 이미 매일 돌아가고 있는 기존 파이프라인을 어떻게 다치지 않게 할지가 더 길었습니다.
새 기능을 기존 시스템에 붙일 때 가장 흔한 사고는 새 기능 자체의 버그가 아닙니다. 새 기능이 공유하는 무언가를 건드려서 멀쩡하던 쪽이 같이 멈추는 일입니다.
그래서 질문을 하나 던져 봅니다. 지금 잘 돌아가는 자동화 옆에 새 갈래를 붙인다면, 새 갈래가 실패했을 때 기존 쪽이 멈추지 않는다는 것을 무엇으로 보장하시겠습니까?
제가 적은 여섯 가지 불변식
설계서에는 기존 가동 파이프라인을 격리하는 불변식 6개를 적었습니다. 핵심 축은 이렇습니다.
- 큐를 분리합니다. 새 채널의 작업이 기존 큐에 섞여 들어가지 않습니다.
- 토큰을 분리합니다. 새 채널의 인증 문제가 기존 채널 업로드에 번지지 않습니다.
- 채널을 분리합니다. ko/en/ja 새 채널 3개는 기존 채널과 별개입니다.
- 렌더 단계는
render_hook플래그로 분기합니다. 플래그가 꺼져 있으면 기존 경로가 그대로 실행됩니다.
나머지 불변식은 이 네 가지를 어기지 않기 위한 세부 규칙입니다. 여기서는 길게 풀지 않겠습니다.
인프라를 다 만든 뒤에도 바로 켜지 않습니다
또 하나는 순서입니다. 인프라를 먼저 완성하고, 48시간 검증 게이트를 통과한 뒤에야 자율 드립, 곧 자동 게시를 시작합니다. 만든 직후에는 '돌아갈 것 같다'는 믿음밖에 없습니다. 실제로 돌려서 기존 쪽이 멀쩡한지 본 다음에 자율 운영으로 넘기려는 것입니다.
당신이라면 새 갈래를 켜기 전에 무엇을 먼저 확인하시겠습니까? 저는 '기존 쪽이 그대로인가'를 먼저 확인하기로 했습니다. 이를 위해 분리를 구조로 못 박고, 켜는 시점은 게이트 뒤로 미뤘습니다.
자가진단 체크리스트
- 새 기능의 큐, 토큰, 출력 대상 중 기존 시스템과 공유하는 것이 하나라도 있습니까?
- 새 코드 경로를 끄는 플래그가 있고, 꺼진 상태에서 기존 경로가 그대로 동작한다고 확인했습니까?
- 새 갈래를 자율 운영으로 넘기기 전에, 기존 쪽이 멀쩡하다는 것을 확인하는 검증 구간을 정해 두었습니까?
솔직한 부분
이 글은 설계 문서에 대한 기록이고, 결과 보고가 아닙니다. 48시간 검증 게이트를 통과했는지, 새 채널에서 앱 목록 페이지로 실제로 얼마나 유입되는지, 리텐션 루프가 작동하는지는 아직 모릅니다. 불변식 6개가 실제 운영에서 모든 사고를 막아 줄지도 확인하지 못했습니다. 설계서는 의도를 적은 것일 뿐이고, 이 의도가 맞는지는 게이트와 운영 데이터가 알려 줄 것입니다.