출시 직전 24시간에는 어떤 작업이 몰릴까?

출시 D-1, 24시간에 6건이 동시에 끝났습니다

SaaS의 출시 직전 하루였습니다. 같은 날 6개 작업이 동시에 마무리됐어요. 시간 순으로 정리하면 이렇습니다.

1. 도메인 확장 — 외부 데이터 연동 + 프로필 필드 추가
2. 휴지통 기능 — soft-delete + 복구 + 인증 흐름 안내
3. 기술 스택 단순화 — Electron 폐기 + Jenkins 전환
4. 신규 등록 폼 라이트화 — 진입은 가볍게, 편집은 풍부하게
5. 파서 deprecate — 옛 입력 경로 정리
6. 실제 배포 — EC2 + Jenkins + PM2 + ALB

처음 이 목록을 보면 "출시 직전에 무슨 새 기능을 이렇게 많이 넣지?" 싶을 수 있습니다. 그런데 자세히 보면 새 기능은 1번뿐이에요. 나머지 5건은 정리·결정·단순화·배포 입니다.

이게 출시 직전 24시간의 본질이었습니다. 새 기능 추가가 아니라 정리와 결정이 압도적으로 많았어요. 이번 글은 그 6단계를 정리하면서 발견한 패턴과 일반화 가능한 통찰을 담은 회고입니다.

6단계 작업 흐름

1단계: 도메인 확장 — 출시 후 마이그레이션 비용을 미리 차단

가장 무거운 작업이었습니다. 외부 데이터를 연동하면서 고객 프로필 필드를 대거 추가했어요. 기본정보, 점수, 이력, 내부 히스토리까지.

이 작업이 출시 직전에 들어간 이유는 단순했습니다. 출시 후 마이그레이션 비용이 출시 전 작업 비용보다 압도적으로 크기 때문입니다.

출시 전: DDL 변경 + 25 테스트 작성 + 폼 분리
출시 후: 같은 작업 + 실서비스 데이터 마이그레이션 + 운영 중단 시간 + 사용자 안내 + 롤백 계획

같은 결정이 출시 1주일만 늦어져도 비용이 10배가 됩니다. 그래서 도메인 확장 결정은 출시 직전이 마지막 적기였어요.

여기서 한 가지 신경 쓴 부분이 있었습니다. 민감 데이터 암호화입니다. 신용 정보는 AES-256-GCM으로 암호화했는데, 암호화 키는 한 번 정하면 절대 변경할 수 없습니다. 키가 바뀌면 기존 암호화 데이터를 복호화할 방법이 없어집니다.

2단계: 휴지통 — 사용자 실수의 회복 경로

soft-deleted 고객 데이터를 보여주는 휴지통 화면, 복구 기능, 완전삭제 기능, 그리고 인증 흐름 안내까지. 출시 전에 반드시 필요한 운영 기능이었습니다.

운영 시스템에서 사용자가 가장 자주 하는 실수가 잘못된 삭제입니다. 이 회복 경로가 없으면 사용자가 한 번 실수하면 끝이에요. 출시 직후 가장 빈번한 CS 문의가 "삭제 복구해주세요"일 가능성이 큽니다.

휴지통 + 복구 + 완전삭제 3종 세트가 들어가면서, 사용자의 실수가 자기 복구 가능한 영역으로 들어갔습니다. CS 부담이 줄어드는 효과까지 같이 가져옵니다.

3단계: 기술 스택 단순화 — 출시 직전이 가장 부담 작은 시기

윈도우 설치형 개발로 사용했던 Electron 데스크톱 앱 폴더 80파일을 제거하고, GitHub Actions에서 Jenkins로 전환했어요. 같은 EC2에 Jenkins가 떠 있어서 SSH 키 관리 부담이 사라졌습니다.

이 작업의 흥미로운 점은 출시 직전이 가장 부담이 작은 시기라는 것입니다.

출시 전: 사용자 없음 → 영향 없음
출시 후: 사용자가 사용 중 → 변경 시 영향 큼

기술 스택 정리는 빨리 할수록 좋습니다. 미루면 사용자 수에 비례해서 비용이 늘어납니다. 그래서 출시 직전 24시간에 80파일을 통째로 제거할 결정을 할 수 있었어요. 이걸 출시 후에 했다면 영향 분석이 며칠 걸렸을 겁니다.

4단계: 신규 등록 폼 라이트화 — "진입은 가볍게, 편집은 풍부하게"

1번에서 프로필 필드를 잔뜩 추가했는데, 신규 등록 폼은 정반대로 단순화했습니다. 이름·주민번호·전화·메모만 받고, 나머지는 상세 진입 후 섹션별로 편집하도록 분리했어요.

이게 가장 흥미로운 패턴이었습니다. "신규는 가볍게, 편집은 풍부하게" 입니다.

도메인 확장과 폼 단순화가 같은 날 일어난 이유는 모순이 아니라 분리였어요. 풍부한 데이터는 진입 장벽이 됩니다. 첫 등록할 때 모든 필드를 다 받으면 사용자가 시작도 못 합니다.

그래서:

진입(신규 등록): 최소 정보만, 5초 안에 끝나는 흐름

편집(상세 페이지): 풍부한 정보, 필요할 때만 채우는 흐름

이 분리가 사용자의 첫 인상과 학습 부담을 동시에 낮춥니다. 데이터 모델은 풍부해도, 사용자가 만나는 입력 흐름은 가벼워야 했어요.

5단계: 파서 deprecate — 미래의 자신에게 명시적 신호

옛 PDF 파서 경로를 deprecate 처리했어요. 테스트는 비활성화하고, 신규 기능은 브라우저 직접 추출 경로로만 보장합니다. 의문 사항 정리 문서에서 1건을 확정하고, 2건은 다음 응대 시 결정으로 미뤘습니다.

deprecate가 단순 삭제와 다른 점이 있어요. 코드는 남기되 "쓰지 마라"는 신호를 명시적으로 남기는 것입니다.

삭제하면: 누가 또 같은 걸 만들 위험
유지하면: 어떤 게 옛 경로인지 헷갈림
deprecate: 코드는 보이지만 사용 금지가 명시됨

미래의 자신(또는 새 개발자)이 옛 경로를 보고 헷갈리지 않게 만드는 작업이었습니다.

6단계: 실제 배포 — EC2 + Jenkins + PM2 + ALB

마지막은 진짜 배포였습니다. EC2 + Jenkins + PM2 + ALB 조합이었어요. 몇 가지 신경 쓴 부분이 있었습니다.

.env는 /APPS 디렉토리에 직접 배치하고, rsync에서 exclude

도메인 호스트헤더 라우팅 설정

/api/health 엔드포인트로 healthy 확인

.env를 별도 위치에 두고 배포 시 exclude하는 게 핵심이었습니다. 배포 때마다 환경 변수가 덮어쓰기되는 사고를 막아주고, 환경 변수가 git에 올라가는 위험도 차단합니다.

패턴 발견 — 출시 직전 = 정리·결정의 집중

6단계를 정리하고 보니 한 가지 분포가 보였습니다.

새 기능은 1건, 나머지 5건은 정리·결정·배포입니다. 출시 직전 24시간이 새 기능 추가가 아니라 유지보수 모드 진입의 마무리 작업이었어요.

생각해보면 자연스러운 패턴입니다. 출시 직전은 다음 결정의 비용 임계점이에요.

도메인 확장: 출시 후엔 마이그레이션 비용 폭증 → 출시 전 마지막 적기

기술 스택 정리: 사용자 없을 때 부담 최소 → 출시 전이 적기

폼 단순화: 사용자 첫 인상에 영향 → 출시 전에 결정 필수

코드 정리: deprecate 신호는 출시 전에 박아둬야 → 출시 후 새 개발자 진입 시 혼동 방지

출시 직전이 마지막 적기인 결정들이 자연스럽게 몰립니다. 출시 일정 자체가 결정 마감일 역할을 했어요.

부가 통찰 — 운영 항목 분리가 출시 일정을 보호

이번 출시에서 의도적으로 분리한 항목들이 있었습니다.

PM2 자동기동

HTTPS 인증서(AWS Certificate Manager 활용)

mysqldump 백업 cron

로그 rotate 설정

이 4건은 운영에 필수지만, 출시 일정을 결정짓는 항목은 아닙니다. 다음 plan으로 분리했어요.

이게 출시 일정 보호의 핵심이었습니다. "다 완벽하게 갖춰야 출시한다"는 자세는 출시 일정을 무한 연기시킵니다. 반대로 "필수 운영 항목을 다 빼고 출시한다"는 자세는 사고 위험을 만듭니다.

기준이 필요했어요.

출시 일정에 결정적인 것 — 도메인, 인증, 핵심 기능 → 출시 전 필수

운영 안정성에 결정적인 것 — 백업, 인증서, 로그 → 분리 가능 (출시 직후 1주일 내)

운영 항목은 다음 plan으로 분리하되, 출시 후 즉시 처리한다는 명시적 약속이 함께 갔습니다. 분리가 "안 하겠다"가 아니라 "출시 직후 우선순위"라는 뜻이었어요.

의사결정자가 점검할 4가지

1인 SaaS·MVP·작은 팀의 출시 시점을 검토하실 때 점검할 일반 체크리스트입니다.

1. 새 기능 vs 정리·결정의 비중을 확인합니다

출시 직전에 새 기능이 5건 이상이면 일정이 위험합니다. 출시 D-1은 정리·결정·배포의 시간이지, 새 기능 추가의 시간이 아닙니다. 새 기능이 많이 보이면 출시를 미루거나 일부 기능을 다음 버전으로 분리합니다.

2. 마이그레이션 비용 임계점을 파악합니다

데이터 모델 변경, 암호화 키 결정, 핵심 도메인 확장은 출시 후 마이그레이션 비용이 압도적으로 큽니다. 이런 결정은 출시 직전이 마지막 적기입니다. 출시 후로 미루면 비용이 10배가 됩니다.

3. 기술 스택 단순화 타이밍을 봅니다

사용 안 하는 코드, 옛 인프라, 폐기 예정 라이브러리는 출시 직전에 정리합니다. 사용자가 없을 때 부담이 최소입니다. 출시 후에는 사용자 영향이 변수가 됩니다.

4. 운영 항목과 출시 일정 항목을 분리합니다

PM2 자동기동, 인증서, 백업, 로그 rotate 같은 운영 안정성 항목은 출시 일정을 결정짓지 않습니다. 다음 plan으로 분리하되, 출시 직후 1주일 내 처리한다는 명시적 약속을 함께 둡니다. "완벽한 운영 환경"을 기다리면 출시는 무한 연기됩니다.

비슷한 발상이 다른 시점 결정에서도 흐릅니다. 각 결정의 비용 임계점을 파악하는 것, 분리 가능한 항목과 필수 항목을 구분하는 것, 출시 일정을 결정의 마감일로 활용하는 것. 출시 일정 관리의 핵심 기준입니다.

마무리

SaaS의 출시 D-1에 6개 작업이 동시에 완료됐습니다. 도메인 확장, 휴지통, 기술 스택 단순화, 폼 라이트화, 파서 deprecate, 실제 배포까지. 6건 중 새 기능은 1건뿐이고 나머지 5건은 정리·결정·배포였습니다.

핵심 교훈은 세 가지입니다.

출시 직전은 새 기능보다 정리·결정의 시간이다 — 출시 일정이 결정의 마감일 역할

"신규는 가볍게, 편집은 풍부하게" 패턴이 사용자 진입 부담을 분리한다 — 풍부한 데이터 모델 + 가벼운 진입 흐름 동시에

운영 항목 분리가 출시 일정을 보호한다 — 운영 안정성 항목은 출시 직후 1주일 내 처리한다는 명시적 약속과 함께

1인 SaaS·MVP·작은 팀의 출시를 검토하신다면, 이번 글의 4가지 체크리스트(새 기능 vs 정리 비중 / 마이그레이션 비용 임계점 / 기술 스택 단순화 타이밍 / 운영 항목 분리)를 한 번 살펴보시길 추천합니다. 출시 일정이 결정의 마감일이 되는 순간 작업 우선순위가 명확해집니다.