이 글은 [이현의 Human AX]에서 발행되었습니다.

AX 실전 벤치마크 사례, 퀄리티 있는 AI 인사이트를 
매주 이메일로 받아보고 싶으시다면, 뉴스레터를 구독해 주세요.

[구독하러 가기]

사실 지난 한 달동안 정말 정신없이 바쁜 하루를 보냈습니다. AX팀에 새롭게 합류하게 되면서 저의 역할과 책임이 커졌다고 느꼈거든요.

AI로 업무 문제를 해결하고, 그 과정을 팀 안에 퍼뜨리는 게 제 역할이었습니다.

그 중 하나로 바이브코딩을 활용해 직접 서비스를 만들어 내부 사용자들 대상으로 오픈했어요.

Claude Code와 대화하며 기능을 쌓아 올렸고, 화면이 완성될 때마다 작은 성취감을 느꼈습니다. UI는 원하는 대로 나왔고, 기능도 잘 작동했어요. '이게 되는구나'라는 감각이 생겼습니다.

그런데 배포 다음 날, 동료가 한마디를 던졌습니다.

"로그인이 많이 느린 것 같다는 피드백이 있는데요?"

처음엔 네트워크 문제겠지 생각했어요. 그런데 아니었습니다. UI가 아무리 완성되어 있어도, 백엔드에 결함이 있으면 서비스는 제 가치를 다하지 못한다는 걸 깨닫게 되었거든요.

실은 이 부분은 제가 서버 세팅을 할 때 미처 생각하지 못한 부분이었습니다. 바이브코딩이 가르쳐주지 않는 영역이 있다는 걸 그때 처음으로 실감했어요.

범인은 코드가 아니었다

원인을 찾기 위해 Claude Code에게 상황을 설명했습니다. 배포 설정과 DB 연결을 하나씩 들여다보기 시작했는데, 생각지도 못한 곳에서 문제가 발견되었어요.

Supabase 데이터베이스 리전이 한국이 아니었습니다. Vercel 네트워크 리전도 북아메리카로 설정되어 있었어요.

이미지: 한국 서비스의 경우 올바른 Vercel 설정

프로젝트를 처음 생성할 때 각 플랫폼이 제안하는 기본값을 그대로 두고 진행했습니다. 그 기본값이 어디로 설정되어 있는지 확인하지 않았고, 둘 다 한국이 아니었다는 사실은 배포 다음 날, 사용자의 피드백으로 처음 알게 된 거예요.

저는 '코드를 작업하는 내내 이 정도 속도면 괜찮겠지'라고 생각했습니다. 다른 동료들도 속도는 그렇게 연연하지 않았어요.

그런데 실제 사용자는 달랐습니다. 배포 하루 만에 받은 피드백 덕분에 초기에 빠르게 대응할 수 있었고, 동시에 내 기준과 사용자의 기준이 다를 수 있다는 것도 새삼 실감했습니다.

참고로 여기서 '사용자'란 B2B, B2G 고객 등으로 구분되는 '영업고객'이 아닌 '내부 임직원'이었습니다. 그래서 첫 MVP겸 내놓은 서비스여서 망정이었지 정말로 실제 고객을 상대로 이런 서비스를 배포했었음 어땠을까 생각하니 더 아찔하더라구요.

그럼에도 불구하고

이것이 의미하는 바는 간단하지만 치명적입니다.

한국 리전으로 인프라가 세팅되지 않은 경우에 한국 사용자가 로그인 버튼을 누르는 순간, 요청이 수천 킬로미터를 날아가 미국이나 유럽에 있는 서버에 닿고, 다시 돌아오는 왕복이 발생해요. 빛의 속도로 이동해도 편도에만 최소 150~280ms가 소요됩니다.

로그인처럼 여러 단계 인증이 연결된 작업이라면, 이 지연이 겹겹이 쌓여 사용자에게는 "이 앱, 왜 이렇게 느리지?"라는 인상으로 남게 되죠.

AI가 작성한 코드에는 문제가 없었습니다. 문제는 코드 밖, 인프라 설정의 '기본값'에 있었어요.

기본값이라는 함정

바이브코딩을 경험해 보신 분들은 알 거예요. AI는 정말 빠르게, 그리고 그럴듯하게 코드를 만들어냅니다. 화면이 뚝딱 나오고, 기능이 붙어가는 속도가 놀랍죠. 그러다 보면 자연스럽게 '작동하고 있다 = 다 된 것이다'라는 착각에 빠지게 됩니다.

그런데 이번 경험을 통해 서비스를 만드는 것과 운영하는 것 사이에는 분명한 간극이 있다는 걸 배웠어요.

Supabase, Vercel 같은 글로벌 플랫폼들의 기본 설정은 전 세계를 대상으로 최적화되어 있습니다. 한국 서비스를 위해 설계된 것이 아니에요.

대부분의 기본 리전은 미국 동부(us-east-1)입니다. 개발자라면 이를 당연히 변경하겠지만, 바이브코딩으로 처음 서비스를 만드는 기획자는 이 설정값이 얼마나 중요한지 모른 채 프로젝트를 시작하게 돼요.

그러나 지금이 때가 아니라는 클로드?

해결 방향은 명확했습니다. Supabase DB를 서울 리전으로 새로 생성해 데이터를 옮기고, Vercel 네트워크 리전도 한국으로 변경한 뒤 재배포하는 것.

그런데 여기서 Claude Code가 한 가지 제안을 했어요. 이번 분기는 서비스를 사용할 일이 빈번하니, 분기가 끝나고 안전할 때 시스템 작업 공지를 띄우고 진행하자는 것이었습니다. 안전을 우선한 합리적인 제안이었어요.

저는 잠깐 고민했습니다. 그런데 생각할수록 지금 진행하는 게 맞다는 확신이 들었어요. 분기 말이 되면 옮겨야 할 데이터도 훨씬 많아지고, 그만큼 검증도 어려워집니다. 지금의 로그인 속도 문제가 사용자 불만으로 이어져 회사에 영향을 미칠 수 있다는 점도 무시할 수 없었어요. (내부 임직원 성격의 사용자이기는 했지만 어느정도는 파트너십을 맺고 있는(?) 관계도 있었거든요. 설명은 길어질 거 같아 생략할게요!)

그래서 저의 이 생각과 맥락을 Claude Code에게 그대로 전달했습니다. 그리고 하나의 방법을 제안했어요.

"새 리전 DB로 API와 쿼리문을 통해 데이터를 다 옮겨놓은 뒤, 로컬 서버에서 먼저 확인하고 Vercel 배포만 마지막에 하면 시스템 중단 없이도 마이그레이션할 수 있지 않아?"

이미지: 클로드 코드에게 다른 방법을 제안하자 내놓은 답변

Claude Code는 그 방법이 더 낫다고 답했습니다. 시스템 중단 없이 진행할 수 있고, 배포 전 로컬에서 충분히 검증할 수 있다는 근거도 덧붙여 주었어요. AI가 제안한 안전한 방법을 제가 더 나은 방법으로 수정하고, AI가 다시 그것을 검증해준 셈이었습니다.

그 과정 덕분에 비개발자임에도 확신을 갖고 진행할 수 있었어요.

DB를 서울 리전으로 이관하고, Vercel 네트워크 리전을 한국으로 바꾼 뒤 재배포했습니다. 결과는 숫자로 바로 나타났어요. 로그인 속도가 80% 가량 상승했습니다. 

마무리하며 : 바이브코딩이 가르쳐주지 않는 것

바이브코딩은 정말 강력합니다. 기획자가 서비스를 직접 만들 수 있게 해주는 것 자체가 혁신이에요.

하지만 이번 경험을 통해 저는 두 가지를 배웠습니다.

첫째, AI는 내가 무엇을 묻느냐에 답하지, 내가 무엇을 묻지 않았는지는 알려주지 않습니다.

리전 설정처럼 코드 밖의 인프라 결정은 기획자가 먼저 알고 있어야 해요.

둘째, AI의 제안은 출발점이지 정답이 아닙니다.

Claude Code가 '기다리자'고 했을 때, 저는 비즈니스 맥락을 함께 전달하며 더 나은 방향을 제안했어요. AI는 기술적 실행을 도왔고, 판단은 제가 했습니다.

바이브코딩으로 서비스를 만들고 계신 분이라면, 오늘 내용 꼭 한 번 짚어보시길 바라요. 

바이브코딩 에이전트와 씨름하고 있는 사이, 우리는 생각보다 간단하지만 중요한 문제를 놓치고 있을 수 있습니다.
 

[Human AX 함께하기]

오늘 글이 도움이 되셨다면 아래 뉴스레터를 구독해 주세요.
기술을 넘어 ‘사람’과 ‘문제해결’에 집중한 AI 인사이트를 주 1회 이메일로 전해 드려요.
📬이현의 Human AX 뉴스레터 구독하기