Live chat app · infra migration

라이브 프로덕션을 인수한다는 건 남이 내린 결정들의 결과를 통째로 떠안는 일입니다. 유료 채팅 솔루션(Sendbird) 의존을 Firestore 기반으로 전면 교체해야 했고, 실사용자가 있으니 실수 한 번이 곧 사용자 피해였습니다. 통화 기능은 유지하면서 보안 경계만 다시 그려야 하는 조건이었습니다.

• 01서버가 GitHub 에 접근 불가한 제약 → git bundle 을 S3 서명 URL 로 전달하는 배포 파이프라인 설계
• 02DB 마이그레이션은 새 이미지의 일회용 컨테이너로 앱 기동 전에 선행 — 스키마/코드 불일치 창 0
• 03AI 의 '전체 수정 완료' 보고 폐기 — 항목 단위 추적 문서 + 목록 대조로만 완료 인정
• 04라이브 DB 정리는 CSV 백업 + 롤백 이미지 선확보 후에만 실행

처음 가설은 'AI 에게 전체 코드를 훑게 하면 이전 누락을 잡을 수 있다' 였습니다 — 깨졌습니다. AI 는 '전체 코드를 훑고 다 고쳤다' 고 보고했지만 실측하니 빠진 곳이 많았습니다. 수정된 가설: 완료는 보고로 인정하면 안 되고, 수정 대상 전수를 목록으로 뽑아 대조로만 인정해야 합니다.

• 01실사용자 라이브 — 다운타임·데이터 손실 허용 불가
• 02서버가 GitHub 에 접근 불가 — 표준 배포 경로 자체가 막혀 있음
• 03통화 기능은 기존 솔루션 유지 — 채팅만 도려내는 부분 이식, 보안 경계 재설계 동반
• 04원작자 부재 — 모든 동작은 코드에서 직접 확인

• git bundle → S3 → 서명 URL → 서버 pull 배포 파이프라인 신설

  buy배포 단계 ↑ → GitHub 접근 불가 제약 안에서 무중단 배포 경로 확보

• DB 마이그레이션을 새 이미지의 일회용 컨테이너로 앱 기동 전에 선행

  buy배포 절차 복잡도 ↑ → 스키마와 코드가 어긋난 채 트래픽 받는 시간 창 0

• AI 완료 보고 불신 — 수정 대상 전수 추적 문서를 만들고 목록 대조로만 완료 판정

  buy추적 문서 작성·유지 비용 ↑ → 이전 누락 전수 소거

• 라이브 DB 의 중복 1:1 채팅방 92건 정리 — CSV 백업 + 롤백 이미지 선확보 후 실행

  buy준비 시간 ↑ → 되돌릴 수 없는 작업을 되돌릴 수 있는 작업으로 바꾼 뒤 실행, 사고 0

누락 전수 소거 후 무중단 프로덕션 컷오버를 완료했습니다. iOS 앱스토어 제출 빌드를 업로드했고, 라이브 DB 정리도 백업·롤백 선확보 상태로 실행해 사고 0건이었습니다. (서버/웹 주소는 비공개입니다.)

무중단 프로덕션 컷오버 완료. iOS 앱스토어 제출 빌드 업로드.

AI 의 가장 위험한 산출물은 틀린 결과물이 아니라 '그럴듯한' 결과물이라는 걸 여기서 몸으로 배웠습니다. '다 고쳤다' 는 보고가 제일 위험합니다. 이 사건 이후 모든 프로젝트에서 완료 판정은 목록 대조가 표준이 됐습니다.