“일단 만들고, 나중에 구조 잡으면 되지 않을까?”

초반에는 이 말이 꽤 합리적으로 들립니다.

너무 처음부터 완벽한 구조를 잡으려고 하면 속도가 안 나고, 아직 아무도 쓰지 않는 제품에 과한 시스템을 붙이는 것도 낭비처럼 보입니다.

저도 처음에는 일단 돌아가게 만드는 쪽에 가까웠습니다.

화면이 뜨고, 기능이 동작하고, 서버에 올라가면 일단 다음으로 넘어갔습니다.

그런데 계속 만들다 보니 생각이 조금 바뀌었습니다.

나중에 붙이는 게 생각보다 쉽지 않습니다.

배포 자동화든, CI/CD든, 브랜치 전략이든, 무중단 배포든 겉으로 보면 “나중에 붙이면 되는 것”처럼 보입니다.

하지만 실제로는 기존 구조를 꽤 많이 건드리게 됩니다.

배포 방식이 바뀝니다.
브랜치 흐름이 바뀝니다.
서버에 코드가 반영되는 방식이 바뀝니다.
환경 변수 관리 방식이 바뀝니다.
컨테이너를 재시작하는 방식도 바뀝니다.

이건 단순히 설정 파일 몇 개를 추가하는 일이 아니었습니다.

제품이 돌아가는 흐름 자체를 바꾸는 일에 가까웠습니다.

더 큰 문제는, 그때 이미 고객이 쓰고 있을 수도 있다는 점입니다.

고객이 사용하는 제품에 배포 구조를 크게 바꾸는 건 단순한 리팩토링이 아닙니다.

서비스가 중간에 멈출 수 있습니다.
예상하지 못한 502가 날 수 있습니다.
새 컨테이너가 정상적으로 뜨지 않을 수 있습니다.
롤백이 준비되어 있지 않으면 대응도 어려워집니다.

dev 환경에서는 괜찮습니다.

“잠깐 안 되네. 다시 보자.”

이렇게 넘길 수 있습니다.

하지만 고객이 돈을 내고 쓰는 production 환경에서는 다릅니다.

그 잠깐의 중단도 사용자 경험이 됩니다.
그리고 그 경험은 신뢰와 바로 연결됩니다.

그래서 이번에 ● goodtek-web에 Git Flow + GitHub Actions 기반 dev CI/CD를 먼저 붙였습니다.

흐름은 이렇게 잡았습니다.

task 브랜치
→ PR
→ CI 검증
→ develop 머지
→ dev 서버 자동 배포
→ health check

겉으로 보면 기능은 하나도 늘지 않았습니다.

사용자 화면이 좋아진 것도 아니고, 새로운 버튼이 생긴 것도 아닙니다.

하지만 제품을 계속 운영할 수 있는 기반은 조금 더 단단해졌습니다.

이번 작업의 목적은 “자동 배포 붙였다”가 아니었습니다.

나중에 고객이 쓰고 있는 제품 위에서 위험하게 구조를 갈아엎지 않기 위해, 지금 dev 환경에서 미리 흐름을 잡아두는 것이었습니다.

처음부터 모든 걸 완벽하게 만들 필요는 없다고 생각합니다.

하지만 나중에 붙이기 어려운 것들은 분명 있습니다.

배포 구조.
데이터 구조.
인증 구조.
권한 구조.
운영 환경.

이런 것들은 제품이 커지고 사용자가 생긴 뒤에 바꾸려면 비용이 커집니다.

그때는 코드만 바꾸는 게 아니라, 이미 사용 중인 서비스를 건드리는 일이 되기 때문입니다.

요즘은 그래서 이런 기준을 세우고 있습니다.

빠르게 만들어도 된다.
하지만 나중에 붙이면 제품을 흔들 수 있는 것들은 너무 늦기 전에 바닥을 깔자.

이번 dev CI/CD 작업도 그런 맥락이었습니다.

아직 완전한 무중단 배포까지 간 건 아닙니다.

하지만 다음 단계로 갈 수 있는 길은 열어뒀습니다.

앞으로는 이런 것들을 차근차근 붙여가야 합니다.

production 배포 workflow.
운영 배포 승인 절차.
GHCR 기반 이미지 배포.
blue/green 배포.
롤백 가능한 구조.

오늘도 화려한 기능은 아니었습니다.

하지만 나중에 고객이 쓰고 있는 제품 위에서 식은땀 흘리며 구조를 바꾸지 않기 위해, 지금 작은 dev 환경에서 먼저 연습하고 있습니다.

여러분은 어떤 것들이 **“나중에 붙이면 늦는 구조”**라고 생각하시나요?