AI에게 말로 시켜서 앱을 만드는 사람이 부쩍 늘었습니다. Cursor나 Claude Code, v0 같은 도구에 “이런 서비스 만들어줘”라고 하면 정말로 돌아가는 앱이 나오죠. 그런데 만들고 나면 공통적으로 부딪히는 벽이 있습니다. 앱은 돌아가는데, AI가 대체 뭘 만들어놨는지 모른다는 것. 에러가 나면 어디를 봐야 하는지, AI에게 뭐라고 물어봐야 하는지 감이 안 잡힙니다.
이 벽을 넘는 첫걸음은 코드를 읽는 능력이 아닙니다. 내 앱이 어떤 부품으로 이루어져 있고, 각 부품이 어디에서 무슨 일을 하는지 아는 것, 즉 구조의 지도를 갖는 것입니다. 개발자들이 프론트엔드, 백엔드, DB라고 부르는 그 세 부품입니다. 이번 글에서는 이 셋을 비개발자 눈높이에서 완전히 풀어봅니다. 이 지도가 있어야 다음 편부터 다룰 API 키, Git, 배포, 요금 문제도 전부 제자리에 꽂힙니다.
앱은 식당과 구조가 같습니다
웹 앱이든 모바일 앱이든, 사용자를 받는 서비스는 대부분 세 부분으로 이루어져 있습니다. 식당에 비유하면 정확히 맞아떨어집니다.
홀(프론트엔드) 은 손님이 앉는 공간입니다. 메뉴판, 테이블, 인테리어. 손님이 직접 보고 만지는 전부죠. 앱에서는 버튼, 입력창, 화면 전환 같은 눈에 보이는 모든 것이 여기에 해당합니다.
주방(백엔드) 은 손님이 볼 수 없는 공간입니다. 주문이 들어오면 실제로 요리를 하는 곳이고 레시피와 재료 관리 같은 영업 비밀이 모두 여기 있습니다. 앱에서는 로그인 처리, 결제, 권한 확인처럼 중요한 일을 하는 부분입니다.
창고(데이터베이스, DB) 는 재료가 보관되는 곳입니다. 주방이 불이 나서 문을 닫아도 창고의 재료는 남아 있죠. 앱에서는 회원 정보, 게시글, 주문 내역 같은 데이터가 실제로 저장되는 곳입니다.
손님(사용자)이 메뉴판에서 주문하면(프론트엔드), 주문서가 주방으로 전달되고(백엔드), 주방은 창고에서 재료를 꺼내 요리해서(DB 조회) 홀로 내보냅니다. 여러분이 인스타그램에서 새로고침을 할 때마다 이 왕복이 일어납니다.
프론트엔드는 사용자 기기에서 실행됩니다
프론트엔드의 가장 중요한 특징은 “어디에서 실행되는가”입니다. 프론트엔드 코드는 여러분의 서버가 아니라 사용자의 브라우저(또는 폰) 에서 실행됩니다. 사이트에 접속하는 순간 코드가 사용자 기기로 전송되고 사용자 기기가 그 코드를 실행해서 화면을 그립니다.
여기서 바이브 코더가 반드시 알아야 할 결론이 하나 나옵니다. 프론트엔드 코드는 누구나 열어볼 수 있습니다. 브라우저에서 마우스 오른쪽 버튼을 누르고 “검사”를 클릭하면 지금 보고 있는 사이트의 프론트엔드 코드가 그대로 보입니다. 네이버든 토스든 예외가 없습니다. 원래 그렇게 설계된 것이라 막을 방법도 없습니다.
그래서 프론트엔드에는 비밀을 둘 수 없습니다. API 키, 관리자 비밀번호, 결제 검증 로직 같은 것을 프론트엔드에 넣으면 전 세계에 공개한 것과 같습니다. AI에게 코딩을 시키다 보면 AI가 편의상 이런 값을 프론트엔드에 넣어버리는 경우가 실제로 있어서 이걸 모르고 배포했다가 API 키를 도용당해 요금 폭탄을 맞는 사고가 심심찮게 일어납니다. 이 이야기는 2편에서 자세히 다룹니다.
백엔드는 내 서버에서 실행됩니다
백엔드는 반대로 내가 관리하는 서버 에서 실행됩니다. 사용자는 백엔드 코드를 볼 수 없고 백엔드에 “요청”을 보내고 “응답”을 받을 수만 있습니다. 식당 손님이 주방에 들어갈 수는 없고 주문서만 넣을 수 있는 것과 같죠.
그래서 중요한 일은 전부 백엔드에서 해야 합니다.
- 비밀 보관: API 키, DB 접속 정보 같은 비밀 값은 백엔드에만 둡니다.
- 권한 확인: “이 사용자가 이 글을 지울 자격이 있나?“라는 검사는 반드시 백엔드에서 합니다. 프론트엔드에서 삭제 버튼을 숨기는 것은 장식일 뿐입니다. 버튼이 안 보여도 요청 자체는 누구나 보낼 수 있거든요.
- 결제와 계산: 가격 계산을 프론트엔드에서 하고 그 결과를 믿으면, 사용자가 요청을 조작해서 1원에 결제하는 일이 가능해집니다.
정리하면 이렇습니다. 프론트엔드는 보여주는 곳, 백엔드는 결정하는 곳. 프론트엔드가 하는 검사는 사용자 편의를 위한 안내이고, 실제 보안과 판단은 전부 백엔드의 몫입니다.
DB는 데이터가 실제로 사는 곳
“내 앱을 지웠다 다시 배포했는데 회원 정보가 그대로 있네?“라는 경험을 해봤다면, 그건 데이터가 앱이 아니라 DB에 살고 있기 때문입니다. 앱(프론트엔드+백엔드)은 일꾼이고, DB는 금고입니다. 일꾼을 전부 교체해도 금고 안의 내용물은 그대로죠.
바이브 코딩에서 많이 쓰는 Supabase나 Firebase가 바로 이 DB를 대신 운영해주는 서비스입니다. 그래서 이런 구분이 생깁니다.
- 코드를 아무리 고치고 다시 배포해도 → 데이터는 안전합니다.
- 반대로 DB를 초기화하면 → 코드가 멀쩡해도 데이터는 전부 사라집니다.
“뭔가를 되돌리고 싶다”는 상황에서 코드 롤백과 데이터 복구가 완전히 별개의 문제인 이유가 이것입니다. 코드는 Git으로 되돌리고(3편에서 다룹니다), 데이터는 DB 백업으로 되돌립니다. 하나를 되돌린다고 다른 쪽이 따라오지 않습니다.
내 프로젝트에서 어디가 어디인가
개념을 알았으니 내 프로젝트 폴더에 대입해봅시다. AI가 만들어준 프로젝트를 열면 폴더가 잔뜩 있는데, 이름에 규칙이 있어서 대략적인 구분이 가능합니다. 바이브 코딩에서 가장 흔한 Next.js 프로젝트 기준으로 보면 이렇습니다.
app/또는pages/,components/→ 화면을 그리는 프론트엔드입니다. 버튼 문구를 바꾸고 싶으면 여기를 봅니다.app/api/폴더, 또는 파일 상단에"use server"라고 적힌 파일 → 백엔드입니다. 같은 프로젝트 안에 있지만 서버에서 실행되는 코드입니다..env파일 → 백엔드가 쓰는 비밀 값 보관함입니다. API 키, DB 접속 정보가 여기 들어갑니다.- DB는 보통 프로젝트 폴더 안에 없습니다. Supabase나 Firebase의 웹사이트(대시보드)에 로그인해야 보이는, 별도의 공간입니다.
주의할 점이 하나 있습니다. Next.js 같은 최신 도구는 프론트엔드와 백엔드가 한 프로젝트 폴더 안에 섞여 있습니다. 폴더가 하나라고 해서 전부 같은 곳에서 실행되는 게 아닙니다. 어떤 파일은 사용자 브라우저로 전송되고, 어떤 파일은 서버에만 남습니다. 이 구분이 헷갈리면 AI에게 이렇게 물어보면 됩니다. “이 파일은 사용자 브라우저에서 실행돼, 서버에서 실행돼?” 이 질문 하나로 비밀 값을 어디 둬야 하는지가 갈립니다.
이 지도가 있으면 달라지는 것들
구조를 알면 당장 세 가지가 달라집니다.
첫째, 에러가 났을 때 어디를 볼지 알게 됩니다. 화면이 이상하면 브라우저의 개발자 도구 콘솔(프론트엔드의 비명), 저장이나 로그인이 안 되면 서버 로그(백엔드의 비명)를 봅니다. AI에게 물어볼 때도 “브라우저 콘솔에 이런 에러가 떠”와 “서버 로그에 이런 에러가 떠”는 완전히 다른 단서라, 이 구분만 해줘도 AI의 진단 정확도가 크게 올라갑니다.
둘째, 보안 사고의 절반을 예방합니다. 비밀 값은 백엔드에, 권한 검사는 백엔드에서. 이 원칙만 지켜도 바이브 코딩발 보안 사고의 상당수를 피할 수 있습니다.
셋째, AI에게 시키는 말이 정확해집니다. “저장 버튼 누르면 에러 나”보다 “버튼을 누르면 백엔드 API 호출이 실패하는 것 같아. 서버 쪽 코드를 확인해줘”가 훨씬 빨리 해결됩니다. 지도를 가진 사람의 질문은 다릅니다.
정리
- 앱은 홀(프론트엔드)·주방(백엔드)·창고(DB)로 이루어진 식당입니다.
- 프론트엔드는 사용자 기기에서 실행되며 누구나 코드를 볼 수 있으므로, 비밀을 두면 안 됩니다.
- 백엔드는 내 서버에서 실행되며, 비밀 보관·권한 확인·결제 같은 결정은 전부 여기서 합니다.
- DB는 앱과 별개의 공간이라, 코드를 갈아엎어도 데이터는 남고 DB를 지우면 코드가 멀쩡해도 데이터는 사라집니다.
- 헷갈리면 AI에게 “이 코드는 브라우저에서 실행돼, 서버에서 실행돼?“라고 물어보세요.
다음 편에서는 이 구조 위에서 가장 사고가 잦은 주제, API와 API 키를 다룹니다. 왜 다들 키를 숨기라고 하는지, 키가 노출되면 실제로 무슨 일이 벌어지는지, 내 프로젝트의 키가 안전한지 확인하는 법까지 정리하겠습니다.