회고
[우테코] 18편 : 오픈미션 12일차
| 서론
안녕하세요 팡일입니다!
오늘은 우아한테크코스 8기 프리코스의 오픈미션 12일차 포스팅입니다. 오늘은 진행한 점들에 대해서 기록하고 공유하려고 합니다!
| 오늘 한 일
1) 기타
CI/CD 구축 -> 하지만 실패
2) QA
QA에 대해 고민하기
QA 대상자 찾아보기
QA 요청 멘트 고민해보기
| 어려웠던 점
1) CI/CD 구축 시도, 그러나 처참한 실패
기존에는 로컬에서 `npm run build`로 프로젝트를 빌드하고, `firebase deploy`를 통해 Firebase Hosting에 직접 배포하는 방식으로 작업해왔습니다. 그리고 배포가 끝난 뒤에는 GitHub에 push하여 버전을 관리하는 식이었죠.
이 흐름 자체는 불편하긴 했지만 큰 문제는 없었습니다. 그래서 “이제는 CI/CD도 한번 구축해봐야 하지 않을까?” 하는 마음으로 GitHub Actions 기반 자동 빌드–배포 파이프라인을 도입하기로 했습니다.
하지만… 결과는 아주 처참했습니다.
분명 로컬에서는 잘 빌드되던 프로젝트였는데, GitHub Actions에서는 매번 같은 오류를 내뱉으며 빌드가 멈춰버렸습니다.
FirebaseError: Firebase: Error (auth/invalid-api-key)
처음에는 단순히 “환경변수 문제인가?” 싶었습니다. GitHub Secrets도 모두 등록했고, PUBLIC_ prefix도 맞췄는데도 계속 실패했습니다. 그러던 중, 원인을 깊게 파고 들어가면서 기대하지 못한 사실을 마주하게 되었습니다.
문제의 핵심은 “Firebase Hosting이 정적 호스팅이라는 사실”에 단순히 있는 것이 아니었습니다. 실패의 본질은 SvelteKit의 빌드 방식과 Firebase Auth의 동작 방식이 충돌한 데에 있었습니다.
SvelteKit은 프로젝트를 빌드할 때 반드시 SSR(Server-Side Rendering) 번들을 먼저 생성합니다. Firebase Hosting이 SSR을 지원하든 말든, SvelteKit 내부 빌드 파이프라인이 SSR 코드를 준비하는 과정 자체는 피할 수 없습니다. 그리고 바로 이 SSR 번들 생성 단계에서, 문제의 Firebase Auth가 실행된 것입니다.
Firebase Auth는 브라우저 전용 API이기 때문에 Node.js 환경(SvelteKit SSR 빌드시점)에서 초기화할 수 없습니다. 하지만 제 프로젝트 구조에서는 Firebase Auth가 포함된 모듈이 SSR 단계에서 정적 import되고 있었고, 결국 서버 환경에서 브라우저 전용 코드를 실행하려고 시도하다가 빌드가 폭발했던 것입니다.
즉, “정적 호스팅이라 Auth가 안 돌아서 실패한 것”이 아니라, “SvelteKit이 SSR 번들을 만들 때 Firebase Auth가 서버에서 실행되면서 실패한 것”이었던 것이죠. 이 사실을 깨닫기 전까지는 Github Repo에서 Secrets도 다시 넣어보고, 환경변수를 출력해보고, Firebase 설정을 무한히 검증해보며 애꿎은 주변 요소만 의심하고 있었습니다.
하지만 근본 원인은 아주 단순했습니다.
| 배운 점
1) CI/CD 구축 시도를 통해 배운 점
: 결국 이번 시도에서 저는 CI/CD를 끝내 구축하지 못했습니다. 여러 가지 원인을 분석하고, Firebase Auth를 SSR-safe하게 분리하는 방법도 찾아보았지만, 프로젝트 전체 구조에서 Firebase 관련 로직이 사용하는 범위가 넓었고, 이를 전면적으로 리팩터링해야만 CI/CD가 안정적으로 동작할 수 있을 것 같았습니다. 물론 가능한 방법이 아예 없었던 것은 아닙니다. SvelteKit에서 SSR과 CSR을 명확히 분리하고, Firebase Auth를 브라우저 단에서만 실행되도록 구조를 재정렬하면 GitHub Actions 기반의 CI/CD도 충분히 구축할 수 있을 것 같았습니다.
하지만 지금 단계에서 그 작업은 개발 효율을 크게 떨어뜨렸고 프로젝트 일정과 우선순위를 고려했을 때 “일단 기존 방식 그대로 배포를 이어가는 것”을 선택하는 것이 더 현실적이라고 판단했습니다. 그래서 현재는 예전처럼, 로컬에서 `npm run build`와 필요 시 `firebase deploy` 이 두 과정을 직접 실행하면서 배포를 이어가고 있습니다.
다만 여기서 하나의 새로운 시도를 해보고 싶다는 생각도 들었습니다. 복잡한 CI/CD 파이프라인이 아니더라도, 스크립트 기반의 간단한 배포 자동화라면 도입해볼 수 있지 않을까 하는 점입니다. 예를 들어, `deploy.sh` 같은 간단한 bash 스크립트, 혹은 npm 스크립트에 빌드+배포 단계를 묶어버리는 방식처럼 말이죠. 이런 “가벼운 자동화”라면 현재 프로젝트 구조를 크게 해치지 않으면서도 배포 과정의 번거로움을 줄일 수 있을 것 같습니다.
이번 시도는 실패로 끝났지만, 그 과정에서 SvelteKit의 빌드 구조, SSR/CSR의 차이, 그리고 Firebase Auth의 동작 환경에 대해 더 깊이 이해하게 되었고, 추후 구조가 안정되었을 때 다시 CI/CD를 시도할 수 있는 기반을 마련하게 되었습니다.
| 내일 목표
1) 테스트
vitest, playright 적용해보기
2) QA
QA 아카이빙 노션 만들기
3) 리팩토링
추가할 기능에 대해서 더 고민해보기
| 한 줄 회고
: "실패는 없다. 성공과 과정이 있을뿐"