토글 하나, 이틀의 밤

브라우저에 주소를 입력했다.

stacktube-production.up.railway.app

화면이 떴다. 내가 만든 — 정확히는 AI가 만들고 내가 지시한 — 랜딩 페이지가 인터넷 위에 존재하고 있었다. 기능 소개, 가격표, FAQ. 다 있었다. 관제탑에 주소를 보냈더니 확인해줬다. "랜딩 페이지 정상 렌더링, 모든 섹션 확인."

됐다.

하지만 "됐다"의 유통기한은 짧았다.

회원가입 버튼을 눌렀다. 이메일과 비밀번호를 입력했다. 가입 버튼을 눌렀다. 에러가 나왔다.

validation_failed: Unsupported provider: provider is not enabled

이 에러를 보고 내가 이해할 수 있는 단어는 "not enabled"뿐이었다. 뭔가가 활성화되지 않았다는 뜻. 하지만 뭐가?

에러를 관제탑에 보냈다. 답이 왔다.

"Supabase에서 Email Provider가 비활성화되어 있어서 나는 에러입니다."

Supabase는 이 프로젝트에서 사용자 인증(로그인, 회원가입)을 담당하는 외부 서비스다. 직접 로그인 시스템을 만드는 건 보안 사고 위험이 높아서, 이런 전문 서비스를 쓰는 게 업계 표준이라고 한다.

관제탑의 안내를 따랐다. Supabase 대시보드에 접속했다. Authentication → Providers → Email. 거기에 토글 스위치가 있었다. 꺼져 있었다. 켰다.

다시 회원가입을 시도했다. 됐다.

토글 하나.

하지만 이 토글에 도달하기 전에 다른 문제가 먼저 있었다. 리다이렉트 URL이라는 것이었다.

배포를 하면 주소가 바뀐다. 내 컴퓨터에서는 localhost:3000이었던 주소가, 인터넷에 올리면 xxxxx.up.railway.app이 된다. 당연한 일이다. 하지만 내가 몰랐던 건, 인증 서비스에게 이 새 주소를 "알려줘야" 한다는 것이었다. 로그인 후 사용자를 어디로 돌려보낼지를 인증 서비스가 알아야 하는데, 새 주소를 안 알려줬으니 "어디로 보내야 할지 모르겠다"고 에러를 낸 것이다.

이걸 리다이렉트 URL 설정이라고 한다. Supabase 대시보드에서 Authentication → URL Configuration에 가서, Railway 도메인을 추가해야 했다. 관제탑이 정확한 경로와 입력값을 알려줬고, 그대로 했다.

이렇게 정리하면 간단해 보인다. 실제로는 이 과정에서 이틀 밤을 썼다. 에러가 나고, 관제탑에 보내고, 답을 받고, 적용하고, 다른 에러가 나고, 다시 보내고. 에러의 겹이 세 개였다. 리다이렉트 URL → Provider 비활성화 → 그 사이에 한 개 더. 하나를 고치면 다음 것이 나타났다.

처음에 빨간 에러 화면을 보면 심장이 뛰었다. EP.04에서 그 감각이 줄어들었다고 썼지만, 솔직히 이 시점에서는 아직 완전히 줄어들지 않았다. 특히 배포 후의 에러는 무게가 다르다. 내 컴퓨터에서 에러가 나면 "나만 불편하다"지만, 인터넷에 올린 후에 에러가 나면 "다른 사람도 이걸 보겠구나"라는 생각이 든다. 물론 이 시점에서 다른 사람은 아무도 접속하지 않았지만.

그리고 이 이틀 사이에 보안 사고가 하나 있었다.

관제탑에 에러 로그를 보내는 과정에서, GitHub Personal Access Token이라는 것이 함께 노출됐다. 이건 내 코드 저장소에 접근할 수 있는 열쇠 같은 것인데, 채팅창에 그대로 드러난 것이다.

관제탑이 즉시 경고를 줬다. "이 토큰을 즉시 폐기하세요. GitHub → Settings → Developer settings → Personal access tokens에서 해당 토큰을 삭제하고, 필요하면 새로 발급하세요."

이런 실수는 초보자가 반드시 한 번은 하게 된다고 한다. API 키, 토큰, 비밀번호 같은 것은 코드에 직접 넣거나 채팅에 노출하면 안 된다. 환경변수라는 별도의 공간에 보관해야 한다. 알고는 있었지만, 급하게 에러를 복사하다 보니 함께 딸려 나간 것이다.

이 이틀의 밤에서 배운 것을 정리하면 이렇다.

에러는 겹으로 온다. 하나를 고치면 그 뒤에 있던 다른 에러가 나타난다. 이건 당황스럽지만 정상이다. 첫 번째 에러가 막고 있어서 두 번째 에러가 보이지 않았을 뿐, 두 번째 에러는 처음부터 거기 있었다.

그리고 에러의 원인은 대개 사소하다. 토글 하나가 꺼져 있었다. URL 하나가 등록되지 않았다. 이런 수준이다. 시스템 전체가 잘못된 게 아니다. 어딘가 하나가 빠져있거나, 맞지 않는 것이다.

대부분의 에러는 그렇다. 그리고 그걸 아는 데 이틀이 걸렸지만, 이후로는 에러가 덜 무서워졌다.

---

🔧 이 에피소드의 기술 용어 해설

배포 (Deploy/Deployment) 내 컴퓨터에서만 돌아가는 프로그램을 인터넷에 올려서 누구나 접속할 수 있게 만드는 것. 식당 비유로, 시험 영업에서 정식 개업으로 전환하는 과정.

Railway 코드를 올리면 자동으로 서버를 구성해주는 배포 플랫폼. 직접 서버 컴퓨터를 사고 설치하는 대신, Railway가 그 과정을 대신 해준다.

Supabase Auth 회원가입, 로그인, 비밀번호 관리를 대신 해주는 서비스. 인증 시스템을 직접 만들면 보안 사고 위험이 높아서, 전문 서비스를 쓰는 것이 업계 표준이다.

Provider (인증 제공자) 로그인 방법의 종류. Email, Google, GitHub 등이 각각 하나의 Provider. Supabase에서 해당 Provider를 "켜야" 그 방법으로 로그인할 수 있다.

리다이렉트 URL (Redirect URL) 로그인 성공 후 사용자를 "어디로 돌려보낼지" 알려주는 주소. 배포하면 주소가 바뀌기 때문에, 인증 서비스에게 새 주소를 알려주지 않으면 로그인 후 길을 잃게 된다.

토큰 (Token) 디지털 신분증. API 토큰은 "이 사람은 이 서비스를 쓸 권한이 있다"는 증명서. 노출되면 다른 사람이 내 계정으로 행동할 수 있으므로 즉시 폐기해야 한다.