운영 준비 — 출시 전에 관제탑부터

1인 팀의 역설: 출시하는 순간 나는 CS팀이고 운영팀이고 장애 대응팀이다. 그래서 배포 전에 운영 장비부터 만들었다.

이 순서를 고집한 이유가 있다. 회사에서 여러 번 봤기 때문이다. 출시 일정에 쫓기면 운영 도구는 늘 "나중에"로 밀린다. 그리고 출시 다음 주에 문제가 터지면, 그때부터 사람이 콘솔을 헤매며 수동으로 데이터를 확인한다. 밤에 문의가 오면 노트북을 열어야 하고, 확인하는 데 30분이 걸리니 답변은 다음 날로 넘어간다. 조직이 크면 그걸 대신해 줄 사람이라도 있지만, 1인 팀에서는 그 사람이 나 하나다. 만들 시간이 없어서 미룬 도구 때문에 매일 밤 시간을 잃는 구조가 된다.

배포 전에 만들어둔 것 셋

• 관제탑 : 사용자·등급·결제 상태는 Firebase 콘솔과 RevenueCat 대시보드에서 한눈에 본다. 결제 시스템이 서버 장부에 상태를 적어주는 구조라, "이 사용자 Pro 맞아요?"라는 질문은 대시보드 한 번으로 끝난다.
• 명령어 도구함 : 최소 지원 버전 올리기, 서버 상태 점검, 인증·등급·보안 규칙까지 훑는 종단 검증, 지인에게 체험권 부여 — 이런 운영 작업을 전부 명령어 한 줄로 만들어뒀다. 마우스로 콘솔을 헤매는 대신, 새벽에 문제가 터져도 한 줄이다. 만든 건 물론 AI 팀원이다.
• 앱 안의 계기판 : 설정 화면 맨 아래에 지금 앱이 어떤 업데이트 버전으로 돌고 있는지 작은 태그로 표시한다. "업데이트 적용되셨어요?"라는 질문에 사용자가 스크린샷 한 장으로 답할 수 있게. 원격 진단의 8할은 "지금 무엇이 돌고 있는가"를 아는 것이다.

세 번째 항목이 특히 실전에서 값을 했다. 원격으로 문제를 파악할 때 가장 큰 장벽은 사용자와 내가 서로 다른 것을 보고 있다는 사실 자체를 모른다는 것이다. 사용자는 최신 버전을 쓰고 있다고 믿고, 나는 그렇게 가정한 채 원인을 찾는다. 화면 구석의 작은 태그 하나가 그 오해를 없앤다. 대화가 "안 되는데요"에서 "이 버전에서 안 되는군요"로 바뀌면 절반은 해결된 것이다.

운영 도구를 만들면서 알게 된 건, 이런 것들이 개발이라기보다 기획에 가깝다는 점이다. 어떤 질문이 자주 들어올지 예상하고, 그 질문에 30초 안에 답할 수 있는 경로를 미리 깔아두는 일. 사용자 시나리오를 쓰는 것과 똑같은 사고방식인데, 대상이 사용자가 아니라 미래의 나일 뿐이다.