Next.js 앱을 GCS에 올리기까지: 디자이너의 배포 회고 #3
기존 파이프라인에서 막히고, 정적 export로 돌아오기까지
이번 작업에서 의외로 시간을 많이 쓴 건 페이지를 만드는 것보다 실제로 서비스에 올리는 과정이었습니다.
1편과 2편에서 다룬 것처럼 1주일 동안 5개 페이지를 만들었습니다. 하지만 프로덕션에 올리고 안정화하는 과정은 또 다른 문제였습니다.
작업 흐름 한눈에
배포까지의 전체 흐름을 6단계로 압축하면 이렇습니다.
1. 피그마 시안 확정
↓
2. 로컬에서 섹션별 구현 + GitHub push
↓
3. Vercel 프리뷰로 팀 리뷰
↓
4. "프로덕션에 어떻게 올리나요?" — 첫 협업
↓
5. next build + 정적 export → GCS 업로드
↓
6. https://www.mathsecr.com/landing/ 프로덕션 반영
1~3단계(만들기 → 푸시 → 프리뷰)는 앞선 글에서 다뤘습니다. 이번 글의 진짜 시작은 4단계 배포부터였습니다.
프로덕션, 어떻게 올리나요?
Vercel 프리뷰가 잘 떴으니 그대로 프로덕션 도메인에 연결하면 끝날 줄 알았습니다. 참고로 기존 랜딩은 Figma Site에서 별도로 만들어 운영하고 있었어요. 그런데 프론트엔드 동료에게 물어보니 답이 의외였어요.
“현행은 Figma Site를 크롤링해서 GCS에 올리는 구조예요. 기존 방식대로 정적 파일로 만들어 GCS에 올려주시면 돼요.”
문제는 단순했습니다. 제가 만든 Next.js 구조와 회사의 기존 정적 배포 구조가 맞지 않았습니다.
| 빌드 | 출력 | 호스팅 | |
|---|---|---|---|
| 기존 운영 | Figma Site 크롤링 | 정적 파일 | GCS + CDN |
| 내가 만든 것 | Next.js 빌드 | ??? | GCS??? |
Next.js 앱은 보통 Node.js 서버나 Vercel이 필요한데 회사는 GCS 정적 호스팅에 묶여 있었어요. 이 둘을 어떻게 연결할지가 새로운 문제였습니다.
정적 export + GCS 직접 업로드
처음엔 기존 크롤러 파이프라인에 끼워 넣을 수 있지 않을까 생각했지만 크롤러는 Figma Site 같은 단순 정적 페이지용이라 Next.js 앱은 처리할 수 없었습니다. 기술적으로 되는 것과 우리 회사 환경에서 되는 건 달랐습니다.
결국 가장 단순한 방법을 택했습니다. Next.js를 정적 export로 빌드한 결과물(HTML, JS, CSS, 이미지)을 GCS에 직접 복사하는 방식입니다. 빌드 → 파일 복사 → 압축까지 한 번에 처리하는 스크립트도 함께 만들었습니다.
한 가지 추가 허들이 있었습니다. FAQ 페이지는 Google Sheets에서 실시간으로 질문/답변을 관리하는 구조인데 정적 export로 바꾸면서 SSR이 사라져 시트 수정이 반영되지 않았습니다. SEO보다 실시간성이 더 중요했기에 서버 fetch를 클라이언트 useEffect로 옮기고 스켈레톤 UI를 넣어 해결했습니다.
협업과 환경
배포까지 며칠 동안 동료분과 여러번 협업했어요. Vercel 프로젝트 확인, 프리뷰 검토, 배포 방법 문의, GCS 업로드 요청.
특히 “프로덕션 배포는 어떻게 진행하면 될까요?” 라는 질문 한 번이 그 후 작업의 방향을 결정했습니다. 디자이너가 직접 만든다는 건 개발자와 협업하지 않는다는 뜻이 아니었어요. 협업 횟수는 줄었지만, 협업하는 내용 자체가 달라진 거였습니다.
배포까지 거친 환경은 이렇습니다.
| 단계 | 환경 |
|---|---|
| 개발 | Next.js 개발 서버 (npm run dev로 localhost:3000에서 실행) |
| 프리뷰 | Vercel 자동 배포 |
| 정적 export | next build + 자동화 스크립트 |
| 로컬 검증 | 정적 파일을 호스팅하는 서버 (preview_server.py로 localhost:8000에서 실행) |
| 최종 저장소 | 내부 GCS 버킷 |
| 프로덕션 | https://www.mathsecr.com/landing/ |
이 모든 이름을 1주일 전엔 몰랐어요. 알고 나니 전체 흐름이 보이기 시작했습니다.
Git은 생각보다 성실했다
한 번은 동료에게 슬랙이 왔습니다.
작업 폴더에 있던 zip 파일과 스크린샷까지 함께 push되고 있었습니다.
그날 처음 알았습니다. 주의하지 않으면 AI가 git add .처럼 전체 파일을 통째로 올리는 명령을 써서 같은 경로의 파일이 모두 Git에 올라간다는 걸요.
사소한 해프닝이었지만, 시안만 넘겼으면 평생 몰랐을 걸 배운 순간이었어요.
디자이너가 처음으로 올린 PR. 요약은 Claude가 자동으로 정리해줬습니다.
이후 단계는 동료가 이어서 진행했습니다. 빌드 결과물을 GCS 버킷에 올리는 작업은 프로덕션 환경에 직접 접근해야 했고 보안상 service account 키가 필요했습니다.
이어서 CDN 캐시를 비우는 작업도 필요했습니다. 새로 올린 파일이 즉시 반영되도록 기존 캐시를 무효화하는 과정인데 잘못 건드리면 서비스 전체에 영향을 줄 수 있는 작업이었습니다.
두 작업 모두 프로덕션에 직접 영향을 주는 작업이라 이후 단계는 개발자가 맡아 진행했습니다.
디자이너가 배포까지 해본다는 것
배포까지 끝내고 나서 가장 크게 든 생각은 이거였어요.
디자인이 끝나고 나서가 진짜 시작이다
운영까지 올리는 동안 매 순간 “이걸 굳이 디자이너가 해야 하나” 싶었어요. 옆에 있는 개발자가 30분이면 풀 일을 며칠씩 헤매고 있었으니까요.
특히 막막했던 건 작업이 끝났는지조차 모를 때였습니다. 디자인은 “이 화면은 완성”이라는 명확한 종착점이 있는데 배포는 “여기까지 하면 끝”이라는 선이 모호해요. 빌드가 잘 되는지, 정적 파일이 다 옮겨졌는지, 캐시가 잘 무효화되는지 — 매 단계가 새로운 점검이었습니다.
그런데 끝나고 보니 세 가지가 남았습니다.
첫째, 디자인 의도가 끝까지 유지됐습니다.
시안 → 구현 → QA의 단계마다 의도가 깎이는 일반적인 흐름과 달리 처음부터 끝까지 제 머릿속의 디자인이 그대로 운영에 올라갔어요.
둘째, 구현 관점에서 판단하는 힘이 생겼습니다.
시안 단계에서 이미 구현 비용을 알면 구현 가능한 디자인을 더 빠르게 만들 수 있어요. 이건 다음 디자인 결정에 직접 영향을 줍니다.
셋째, 개발자와 대화하는 언어가 달라졌습니다.
“이거 가능해요?”라고 묻기 전에 “이건 정적 export로 처리되니까 클라이언트 fetch로 가야겠죠?”라고 먼저 던질 수 있게 됐어요.
마치며
이번 경험을 통해 깨달은 것은 직접 배포를 한다고 해서 개발자와의 협업이 사라지는 게 아니라는 점입니다.
오히려 대화의 깊이가 달라졌습니다.
시안의 픽셀을 맞추는 대화 대신 인프라의 제약을 공유하고 최적의 경로를 결정하는 대화를 나눴으니까요. 배포는 단순히 파일을 올리는 게 아니라, 만든 걸 실제로 사용자한테 보여주기까지의 마지막 과정이었습니다.
이 과정이 다른 디자이너분들에게도 작은 도움이 되었으면 좋겠습니다. 다음엔 새롭게 리뉴얼된 수학비서로 찾아뵐게요. 읽어주셔서 감사합니다.
시리즈 전체 보기
01 디자이너가 Claude Code로 랜딩 페이지 직접 배포하기 #102 Figma → Code, 디자이너가 직접 옮길 때 알아야 할 것들 #2
03 Next.js 앱을 GCS에 올리기까지: 디자이너의 배포 회고 #3