에러 디톡스 정원 개발 회고 - 프로토타입 2일, 한 달 만의 배포

들어가며

에러 디톡스 정원을 만들고 배포까지 끝냈다. 처음엔 배포 중에 겪은 문제들만 정리하려 했는데, 다시 보니 이 프로젝트는 이틀 만에 뼈대를 세우고 한 달을 Google AI studio에서 작업하고, 나흘 만에 몰아서 완성한, 꽤 특이한 리듬으로 진행됐다. 그래서 트러블슈팅 나열보다는 프로젝트 하나를 처음부터 끝까지 되짚는 회고로 남기기로 했다.

---

1. 프로젝트 기간과 진행 리듬

개발 기간은 2026년 7월 15일부터 8월 19일까지, 달력으로는 한 달이 넘는다. 근데 실제로 커밋을 남긴 날은 그중 엿새뿐이다.

 

1차 - 7월 15일~16일 (이틀): 첫 커밋으로 정원 뼈대를 세우고, README와 보안 헤더, 명상 타이머까지 붙여 프로토타입을 끝냈다.

2차 - 7월 17일~8월 15일 (한 달): 핸드폰과 컴퓨터로 Google AI 스튜디오에서 작업을 했다.

3차 - 8월 16일~19일 (나흘): 정원 광장 커뮤니티와 밤 테마를 추가하고 배포를 준비했다. Google AI Studio를 벗어나서 배포하자마자 로그인, API, 세션 문제가 연달아 터져서 그날 저녁 내내 고쳤고, 다음날은 유틸리티 클래스 정리와 접근성 개선으로 마무리했다.

 

다시 열었을 때 가장 먼저 한 건 내가 뭘 만들다 멈췄는지 처음부터 다시 읽는 것이었다. 이틀 만에 만든 코드였는데도 한 달이 지나니 남의 코드처럼 낯설었다.

---

2. 뭘 만들었나 - 에러를 식물로 정화하는 정원

컨셉은 단순하다. 에러 로그와 그때 감정을 적어 내면, Gemini가 분석해서 원인·내용·해결책 요약 카드를 먼저 보여주고, 이어서 식물 생태에 빗댄 위로와 디버깅 조언을 건넨다.

 

에러 종류에 따라 정화하는 식물이 다르다.

에러 유형	식물	은유
비동기/동시성/스레드	유칼립투스	차분한 은빛 잎, 흐름을 조율하는 힘
인프라/네트워크/배포	대나무	휘어져도 부러지지 않는 유연함
데이터베이스/정체	몬스테라	넓은 잎으로 병목을 그늘지게
레거시/스파게티 코드	아이비	엉켜도 끊기지 않는 생명력

에러 로그와 감정을 적으면 Gemini가 이렇게 정화해준다.

 

에러 로그를 붙여넣고 몬스테라를 고르면, 이렇게 요약 카드부터 보여준다.

 

정화한 기록이 쌓이면 정원 테라리움 레벨이 오르고, 다른 개발자의 정화 기록에 응원을 남기는 정원 광장도 있다. Web Audio API로 바람·비·새소리를 그 자리에서 합성해서 파일 로딩 없이 배경음도 켤 수 있다.

 

메인 쉼터와 사운드 믹서, 정원 광장, 테라리움 보관함은 이런 모습이다.

 

늦은 밤 작업할 땐 다크 테마로 전환할 수 있고,

처음 온 사람을 위한 사용 설명서와 TRIZ·SCAMPER·ERRC 기법서도 따로 마련해뒀다.

정원 말고 두 번째 축도 있다. TRIZ, SCAMPER, ERRC 같은 서비스 기획 프레임워크로 브레인스토밍을 정리하는 워크시트 기능인데, 결과를 Google Drive에 JSON으로 저장해두고 다시 불러올 수 있다.

 

스택: React 19 + TypeScript + Vite + Tailwind v4(프론트), Express(로컬 개발 서버), @google/genai(Gemini 연동), Firebase Auth + Google Drive API(로그인/저장), Vercel(배포).

 

---

3. 작업 내용 요약

배포를 재개한 나흘 동안 겪은 문제는 크게 세 가지였다.

 

Vercel에 올리자 API가 통째로 404 - 로컬은 Express(server.ts)가 /api/gemini/refresh를 직접 서빙했는데, Vercel은 vite build 결과물, 즉 정적 파일만 배포하고 있었다. Express 서버 자체가 애초에 실행되지 않은 것이다. server.ts의 프롬프트·검증 로직을 api/gemini/refresh.ts라는 Vercel 서버리스 함수로 옮기고 나서야 해결됐다. Vercel은 api/ 디렉토리 아래 파일을 자동으로 함수로 인식해서 배포해준다.

export const config = { maxDuration: 60 }; // Gemini 응답이 10초 넘게 걸릴 때가 있어서

 

새로고침하면 로그아웃 - Firebase 로그인 세션(localStorage에 저장돼 영구적)과 Google Drive 액세스 토큰(탭 단위로만 살고 1시간 뒤 만료)을 같은 것으로 취급한 게 문제였다. "세션은 있는데 Drive 토큰이 없으면 로그인 실패"로 처리하던 분기를 없애고, 로그인 여부는 Firebase 세션으로만 판단하도록 hasDriveAccess를 따로 분리하고 나서야 안정됐다.

 

배포 전 보안 점검 - HTTP 보안 헤더, 페이로드 크기 제한(DoS 방지), 입력 타입·화이트리스트 검증, 문자열 길이 제한을 한 겹씩 둘렀다. 에러 로그란 게 사용자가 자유 텍스트로 붙여넣는 값이라, 검증 없이 그대로 Gemini 프롬프트에 꽂으면 과도한 페이로드나 프롬프트 인젝션에 취약해진다.

 

---

4. 잘 된 것

이틀 만에 만든 프로토타입이 한 달 뒤에도 다시 붙잡을 수 있을 만큼 멀쩡했다는 것 자체가 잘한 선택이었다.

 

• 프롬프트·검증 로직을 API 핸들러 하나에 몰아둔 구조 덕분에, 나중에 Vercel 서버리스 함수로 옮길 때 로직을 거의 그대로 재사용할 수 있었다.
• 로그인 여부와 Drive 접근 권한을 분리한 설계는, 정원 기능처럼 Drive가 필요 없는 화면에서 불필요한 재로그인 요구를 없애줬다.
• 보안 체크리스트(헤더, DoS 방어, 입력 검증)를 초기 프로토타입 단계에서 미리 넣어둔 덕분에, 배포 직전에 급하게 손댈 게 적었다.

 

---

5. 아쉬웠던 것

• 배포 플랫폼(Vercel)의 API 라우팅 방식을 미리 확인하지 않고 로컬 Express 구조를 그대로 유지한 채 배포부터 해버렸다. 그 바람에 배포 당일 API가 통째로 죽어있는 걸 뒤늦게 발견했다.
• 한 달의 공백 동안 무엇을 만들다 멈췄는지 기록을 남겨두지 않아서, 다시 열었을 때 코드를 처음부터 다시 읽어야 했다. Git 커밋 메시지만으로는 "왜" 그렇게 짰는지가 잘 안 보였다.
• 리프레시 토큰까지는 아직 안 붙여서, Drive 토큰이 55분마다 끊기는 문제는 근본적으로 해결하지 못했다.

 

---

6. 다음에 비슷한 프로젝트를 한다면

• 로컬 개발 서버와 배포 플랫폼의 라우팅 방식이 다를 수 있다는 걸 전제로, 배포 플랫폼부터 먼저 정하고 그에 맞는 구조로 시작할 것 같다.
• 며칠 이상 프로젝트를 쉬게 될 걸 알면, 멈추기 직전에 "왜 이렇게 짰는지" 한 줄이라도 남겨두는 습관을 들이고 싶다.
• 세션을 설계할 때는 "이 정보가 언제 만료되고, 누가 그걸 필요로 하는가"를 먼저 나누는 걸 기본값으로 삼을 것 같다.

 

---

이틀 만에 만든 것도, 한 달을 묵힌 것도, 나흘 만에 몰아서 고친 것도 - 결국 다 이 프로젝트를 완성하는 과정이었다.

---

초록빛 에러 디톡스 가든 | GitHub