나는 4시간 동안 Google OAuth를 디버깅했고… 그 후에 기능을 삭제했다 (첫 SaaS를 만들면서 얻은 교훈)
Source: Dev.to
The Plan: Let Users Send Emails From the Platform
백엔드 인텔리전스 레이어가 정상 작동하자, 다음 단계는 명확해 보였다. 상상한 흐름:
- 사용자가 Google OAuth로 로그인한다.
- LeadIt이 Gmail 접근 권한을 요청한다.
- Google이 액세스 토큰과 리프레시 토큰을 반환한다.
- 해당 토큰들을 내 Supabase 데이터베이스에 저장한다.
- LeadIt이 Gmail API를 사용해 자동으로 아웃리치 이메일을 보낸다.
문서상으로는 꽤 직관적으로 보였다.
Setting Up Google Cloud
Google Cloud Console(GCP)에서 다음과 같이 설정을 시작했다:
-
Google Cloud 프로젝트 생성.
-
Gmail API 활성화.
-
OAuth 동의 화면 구성.
-
클라이언트 ID와 클라이언트 시크릿 생성.
-
리디렉션 URI 추가, 예시:
http://localhost:3000/api/auth/callback/google -
https://www.googleapis.com/auth/gmail.send와 같은 스코프를 사용해 Gmail 권한 추가.
이 시점까지는 모두 올바르게 보였다.
Authentication Worked… But the Token Didn’t
OAuth 리디렉션은 성공했고, 클라이언트 ID도 유효했으며, 동의 화면이 표시되고 인증도 완료되었다. 하지만 Gmail 제공자 토큰이 데이터베이스에 전혀 저장되지 않아:
- Gmail API 호출이 안 된다.
- 이메일 전송이 안 된다.
- 자동화가 안 된다.
즉, 인증은 성공했지만 기능은 사실상 무용지물이었다.
The 4‑Hour Debugging Spiral
Database Layer
- 데이터베이스 연결.
- 사용자 테이블 구조.
- 제공자 토큰 필드.
- 행 수준 보안 정책.
모두 정상인 듯 보였다.
Server‑Side Logic
- OAuth 콜백 핸들러.
- 제공자 토큰 파싱.
- 토큰을 데이터베이스에 삽입.
- 세션 처리.
문제점이 발견되지 않았다.
Client‑Side Flow
- 인증 세션.
- 제공자 응답.
- 토큰 가용성.
다시 한 번 눈에 띄는 문제가 없었다.
Google Cloud Configuration
- OAuth 스코프.
- 리디렉션 URL.
- Gmail API 권한.
- 클라이언트 ID 설정.
모두 정상으로 보였다.
The Realization
몇 시간 동안 디버깅을 한 뒤, 나는 간단한 질문을 던졌다: LeadIt의 진짜 핵심은 무엇인가?
답은 Gmail 자동화가 아니었다. 핵심은:
- 기업을 발견한다.
- 그들의 웹사이트를 분석한다.
- 기회 신호를 감지한다.
- AI가 만든 아웃리치 메시지를 생성한다.
자동 이메일 전송은 유용하지만 필수는 아니다.
The Founder Decision: Cut the Feature
OAuth 복잡성에 더 이상 시간을 투자하기보다, 나는 MVP에서 이메일 자동화 기능을 삭제했다. 이제 제품은 다음에 집중한다:
- 기업 검색.
- 웹사이트 분석.
- 리드 발견.
- 리드 스코어링.
- AI‑생성 아웃리치 메시지.
사용자는 생성된 메시지를 복사해 직접 보낼 수 있다.
Simplifying Authentication
또한 MVP에서는 복잡한 OAuth 대신 간단한 Next.js 인증으로 교체하기로 했다. OAuth는 많은 움직이는 부품을 요구한다:
- 클라이언트 ID.
- 리디렉션 흐름.
- 토큰 저장.
- 리프레시 토큰.
- 권한 스코프.
이 모든 것이 개발 시간과 디버깅 노력을 잡아먹는다.
Landing Page Progress
백엔드 작업이 진행되는 동안, 나는 LeadIt 랜딩 페이지를 만들면서 스스로에게 물었다:
- 제품 아이디어가 타당한가?
- 가치 제안이 명확한가?
- 이런 도구를 써보고 싶나요?
초기 피드백은 매우 귀중했다.
What Today Actually Taught Me
- 빠르게 배포하라.
- 불필요한 복잡성을 피하라.
- 필요할 때는 기능을 과감히 줄여라.
때로 가장 현명한 엔지니어링 결정은 문제를 고치는 것이 아니라, 문제 자체를 없애는 것이다.
Final Thought
첫 SaaS를 만든다는 일은 혼란스럽다. 지금 무언가를 만들고 있다면, 궁금하다: 기능을 디버깅하느라 몇 시간을 보낸 뒤, 실제로는 그 기능이 필요 없었다는 걸 깨본 적이 있나요?