[온보딩 사이트 만들기 2] 디자인에 Data 붙여넣기: Firebase & GA4 연동

지난 [온보딩 사이트 만들기 1] 코딩보다 중요한 설계: 디자이너의 PRD 작성법 에서는 AI 코딩을 시작하기 전, 방향성을 잃지 않기 위해 PRD와 SPEC 등 설계 문서를 작성하는 과정을 이야기했다.

뼈대와 예쁜 UI를 만드는 것까지는 성공했지만 단순히 회사 정보를 텍스트로 보여주기만 하는 정적인 페이지라면 굳에 웹사이트로 개발할 필요 없이 노션으로 공유하는 것과 다를 바가 없다고 생각했다.

내가 원한 것은 동료들이 직접 쉽게 수정할 수 있고, 사용자 데이터가 쌓여 스스로 증명하는 진자 프로덕트 였다.

이번 Part2에서는 예쁜 껍데기에 Firebase와 GA4를 연동한 과정을 공유하려 한다.

개발자 없이 Admin 만들기: Firebase 세팅

온보딩 사이트는 정보의 최신화가 생명이었다. 복지 제도가 바뀌거나 장비 신청 가이드가 변경될 때마다 내가 코드를 수정해서 배포할 수는 없어 동료 누구나 쉽게 글을 고칠 수 있는 환경이 필요했다.

Firebase logo / 출처: 구글 검색

① 별도 Admin 없이 사내 계정 권한 부여

가장 큰 고민은 ‘관리자 페이지’를 따로 만들 리소스가 없다는 것이었다. 그래서 AI에게 이렇게 요구했다.

별도의 어드민 페이지를 만들지 마. 대신 구글 로그인을 붙여서, 
우리 회사 이메일(@0000.co.kr)로 로그인한 사람에게만 화면상에 '수정/삭제' 버튼이 보이게 해줘.

이 로직 하나로 개발 범위가 절반으로 줄었다. 외부인은 보기 권한만 갖고, 사내 동료들은 로그인 즉시 현재 보고 있는 화면에서 심리스하게 문서를 편집할 수 있는 운영 환경이 구축되었다.

Firebase Console 바로가기

② 마크다운(Markdown) 도입

Markdown viewer / 출처: https://markdownlivepreview.com/

동료들이 HTML 태그를 입력하게 할 수는 없었기에 콘텐츠 등록은 마크다운기반으로 설계했다. 노션에 글을 쓰듯 #이나 * 기호만으로 텍스트를 포매팅하여 쉽게 정보를 업데이트할 수 있게 만들었다.

③ 누가 고쳤지? — Edit Log 저장: 제작과 운영의 안전장치

여러 사람이 하나의 문서를 수정하다 보면 내용이 꼬일 수 있다. 서버 관리가 필요 없는 Firebase를 DB로 연동하여 콘텐츠가 수정될 때마다 수정자 정보, 수정 시간, 변경 내용이 Edit Log로 남도록 안전장치를 마련했다.

Firebase 콘텐츠 Edit Log

단순히 누가 고쳤나 기록하는 것을 넘어 Firebase DB 연동은 제작 과정과 실제 운영 단계 모두에서 필수적인 데이터 전략이었다.

제작 단계: 코드 수정 시 데이터 휘발 방지 AI Studio로 디자인을 수정하거나 기능을 추가할 때마다 코드가 통째로 갈아엎어지는 경우가 많았다. 그래서 초기에 Hard Coding으로 내부에 직접 저장된 콘텐츠는 디자인을 고칠 때마다 초기화되거나 날아가버리는 이슈가 있었다. 이를 방지하기 위해 모든 데이터를 DB로 분리했다.

운영 단계: 실수를 되돌리는 Emergency Fix

1. 최신 로그 기반의 데이터 복구 사내 동료들이 편집 권한을 가지게 되면서 실수로 중요 콘텐츠를 삭제하거나 내용을 잘못 수정할 위험이 있었다. 이때 Firebase DB에 저장된 이전 기록을 활용해 유실된 데이터를 돌려주는 복구 기능을 만들었다.
2. 마스터 계정 전용 노출 이 복구 버튼이 모든 사람에게 보이면 혼란을 초래할 수 있다고 판단했다. 이 버튼은 지정한 마스터 계정으로 로그인햇을 때만 화면에 나타나도록 권한 로직을 추가했다.

Emergency Fix Button

디자인의 근거 마련기: GA4 세팅

열심히 만든 온보딩 사이트를 사용자들이 많이 사용하는지, 어떤 정보를 가장 많이 확인하는지, 어디서 길을 잃는지 데이터로 확인하고 싶었다. 특정 메뉴를 많이 방문한다 정도가 아니라 특정 메뉴의 어떤 정보를 가장 많이 확인하는지 알고싶었다.

Google Analytics logo / 출처: 구글 검색

① 마이크로 인터렉션 추적: 무엇을 많이 클릭했는가?

메뉴별 화면에는 수많은 복지, 규정, 가이드 콘텐츠들이 ‘카드 형태’로 나열되어 있다. 기본적인 GA4 세팅에서는 이런 페이지들의 클릭이 ‘페이지 제목' 하나로만 잡히는 문제가 있었다. 이를 해결하기 위해 각 콘텐츠 카드별로 고유한 URL ID값을 부여했다.

Content Edit Popup — URL 슬러그 추가

이후 GA4의 측정 기준을 페이지 경로 및 화면 클래스와 링크 텍스트로 세분화했다.

결과 단순히 ‘온보딩 페이지에 100명이 들어왔다’가 아니라, ‘100명 중 80명이 <업무 시작 가이드> 메뉴를 클릭했고, <프린터 및 스캐너> 카드를 30명이 클릭했다는 세밀한 데이터 추적이 가능해 졌다.

② 퍼널 데이터 세팅: 어디서 이탈하는가?

전체적인 이탈률을 세팅한 뒤 사용자들이 실제로 화면 안에서 어떻게 움직이는지 시각적으로 확인하기 위해 경로 탐색 분석 데이터를 함께 보았다.

데이터를 추적하는 과정에서 한 가지 기술적인 허들이 있었다. 온보딩 사이트는 React 기반의 Single Page Application으로 해시 라우팅을 사용하고 있어서 GA4 기본 세팅에서는 모든 페이지 경로가 / 하나로만 수집되고 있었다. 그래서 측정 기준을 페이지 제목과 개별 세팅한 슬러그값으로 바꿔가며 흐름을 보았다.

Google Analytics Graph

흐름을 분석해보니 메인화면에서 하위메뉴로 잘 넘어가는 듯 보였던 사용자들이 다시 메인화면으로 돌아가는 현상이 있었다. 원하는 콘텐츠를 한 번에 찾지 못해 방황하는 현상으로 판단했고, 메인 화면에 검색 기능을 새롭게 설계했다.

3. 넥스트 스텝: Antigravity와 터미널로 이동

Firebase로 DB를 붙이고, GA4로 트래킹 코드를 심고, 마크다운 렌더링 로직까지 추가되자 온보딩 사이트의 덩치가 커졌다. 덩치가 커지면서 Google AI Studio가 조금씩 한계를 드러내기 시작했다.

코드를 요청하면 AI가 요구하지 않은 부분까지 최신 기술을 접목해 모두 바꿔버리면서 블랙화면 오류가 나타났다. 이때문에 폴더와 파일에 대해 강제성을 부여해야 했지만 Google AI Studio는 내가 파일을 삭제해도 다시 생성하거나 명령어를 무시하는 경우가 많아 완벽한 제어가 어려웠다.

더 이상 브라우저 기반의 AI 툴로는 이 프로젝트를 고도화 할 수 없다고 판단했고 Antigravity와 Terminal을 활용해 로컬 환경으로 이동했다. 다음 Part 3에서는 Claude Code를 활용해 작업환경을 전환한 과정을 공유하고자 한다.