AI로 만든 앱 안에 실제로 무엇이 들어 있나: 비개발자를 위한 둘러보기
AI 앱 빌더로 무언가를 출시했고 지금 보고 있는 게 뭔지 이해하고 싶다면, 전문 용어 없이 그 구성 요소들을 친근하게 안내해 드립니다.
설명을 입력하고, 실행을 눌렀더니, 이십 분 뒤 작동하는 앱이 생겼습니다. 훌륭합니다. 그런데 이제 “파일 보기”를 클릭했더니, 다른 언어로 쓰인 것 같은 폴더 트리를 멍하니 보고 있습니다. package.json이 뭐죠? node_modules에는 왜 마흔 개나 들어 있죠? “스키마”는 무슨 뜻이고, 왜 당신에게 그게 하나 있는 거죠?
이 글은 안내 둘러보기입니다. 튜토리얼이 아니라 — 둘러보기요. 다 읽고 나도 이 파일들을 직접 쓰는 법은 모르겠지만, 다음번에 뭔가 이상해 보이면 앱의 어느 구석을 가리켜야 할지는 알게 됩니다.
추상적인 부분이 붙들 구체적인 것이 있도록, 글 내내 세 가지 예시를 쭉 쓰겠습니다:
- 마야(Maya), 마케팅 리드, 팀을 위한 추천 리더보드를 만들었습니다.
- 조던(Jordan), 요가 강사, 수업 예약 사이트를 만들었습니다.
- 샘(Sam), 베이커리를 운영하며, “내일의 크루아상 미리 주문하기” 페이지를 만들었습니다.
셋 다 AI 앱 빌더를 썼습니다. 세 앱 모두 고객 눈에는 완전히 달라 보입니다. 그런데 속을 들여다보면, 놀랄 만큼 비슷한 모양입니다.
프런트엔드: 고객이 실제로 보는 것
프런트엔드는 누군가의 브라우저에 로드되는 모든 것입니다. 버튼, 레이아웃, 글꼴, 애니메이션, 제출 후 폼이 스스로 비워지는 방식까지. 눈에 보인다면, 그건 프런트엔드입니다.
마야에게 프런트엔드는 순위·이름·추천 수가 있는 리더보드입니다. 조던에게는 “예약” 버튼이 있는 수업 달력입니다. 샘에게는 각 항목 옆에 작은 플러스·마이너스 버튼이 달린 페이스트리 목록입니다.
프로젝트 안에서 프런트엔드는 보통 app/, pages/, 또는 src/ 같은 이름의 폴더에 삽니다. .tsx나 .jsx로 끝나는 파일들이 보일 겁니다. 각각은 대략 “하나의 화면”이거나 “화면의 한 조각”입니다. 리더보드 행이 한 파일. 헤더가 또 한 파일. 그걸 다 엮는 페이지가 세 번째 파일입니다.
AI 빌더에게 “버튼을 더 둥글게 해 줘”나 “리더보드를 오른쪽으로 옮겨 줘”라고 하면, 바뀌는 게 이 부분입니다.
백엔드: 생각하는 부분
백엔드는 아무도 보지 못하지만 모두가 의지하는 부분입니다. 고객의 브라우저가 혼자 하기엔 믿을 수 없는 무언가가 일어나야 할 때, 고객의 브라우저가 아니라 다른 어딘가에서 — 서버에서 — 돌아가는 코드입니다.
왜 브라우저가 다 할 수 없을까요? 브라우저는 고객의 기계이고, 그건 믿을 수 없기 때문입니다. 마야의 리더보드가 추천 수를 순전히 브라우저에서만 업데이트한다면, 누구나 우클릭해서 자기에게 추천 9,000개를 더할 수 있습니다. 그래서 백엔드가 규칙이 사는 곳입니다: “이 사람은 이건 할 수 있지만 저건 안 됨”, “이걸 정말로 데이터베이스에 저장하기”, “이 이메일 보내기”.
백엔드는 보통 api/, server/, 또는 app/api/ 같은 이름의 폴더에 삽니다. 거기 있는 파일들은 보통 짧습니다. 각각은 특정 요청 하나를 처리합니다: “예약 만들기”, “오늘의 크루아상 나열하기”, “추천 더하기”.
앱에서 뭔가가 작동하는데 그 결과가 남지 않을 때 — 제출을 클릭하고, 확인 메시지를 봤는데, 내일이면 데이터가 사라졌을 때 — 버그는 거의 항상 백엔드에 있습니다.
데이터베이스: 앱의 기억
앱의 기억을 한 줄로 늘어선 서류 캐비닛이라고 상상하세요. 각 캐비닛 앞면에는 라벨이 붙어 있습니다. 하나는 “users”. 하나는 “bookings”. 하나는 “croissant_orders”. 각 캐비닛 안에서 서랍 하나하나가 한 행입니다. 모든 서랍에는 같은 슬롯 세트가 있습니다: 이름, 이메일, created_at, 상태.
그 구조 — “어떤 캐비닛이 있고, 각 행에 어떤 슬롯이 있는지” — 를 스키마라고 부릅니다. 프로젝트에서 가장 중요한 파일인데, 동시에 아마 가장 따분해 보이는 파일이기도 합니다. schema.ts, schema.prisma, 또는 db/나 migrations/라는 폴더 안의 무언가를 찾으세요. 열어 보세요. 당신의 앱이 세상에 대해 실제로 기억하는 것을 비추는 목록이 보일 겁니다.
조던의 스키마에는 classes 테이블, bookings 테이블, users 테이블이 있습니다. 샘의 것에는 products, orders, order_items가 있습니다. 마야의 것에는 members와 referrals가 있습니다. 스키마의 모양이 제품의 모양이며, 그래서 나중에 그걸 바꾸는 게 버튼 모양을 바꾸는 것보다 더 어렵습니다.
유용한 요령: 앱이 무엇을 기억하는지를 평범한 말로 설명할 수 있다면, 보통 스키마도 설명할 수 있습니다. “나는 각 고객의 이름과 이메일을 기억해. 각 고객에 대해, 그들이 한 주문을 기억해. 각 주문에 대해, 어떤 페이스트리를 몇 개씩 주문했는지 기억해.” 그 문장이, 거의 한 단어 한 단어 그대로, 스키마입니다.
인증: 문 앞의 경비
“인증(Auth)“은 두 단어를 뭉친 것입니다: authentication(당신은 누구인가?)과 authorization(당신은 무엇을 해도 되는가?). 둘 다 보통 auth/라는 폴더 안의 작은 파일 묶음이나, 이름이 낯익을지도 모를 서비스가 처리합니다: Clerk, Auth0, Supabase Auth, NextAuth.
두 질문은 다릅니다. Authentication은 답합니다: “이게 정말 마야인가?” — 보통 비밀번호, Google 로그인, 또는 그녀에게 이메일로 보낸 매직 링크로요. Authorization은 답합니다: “마야가 다른 사람의 추천을 삭제해도 되는가?” — 그리고 대부분의 AI로 만든 앱이 첫 주에 내놓는 정직한 답은 “확인하는 걸 깜빡했어요”입니다.
이건 가장 자주 조용히 깨져 있는 부분입니다. 로그인 화면이 작동하니, 안전하게 느껴집니다. 하지만 백엔드가, 로그인한 사람이 그들이 읽으려는 데이터의 주인과 같은 사람인지 늘 확인하지는 않습니다. 앱에 “내 데이터 대 네 데이터”라는 개념이 조금이라도 있다면, AI 빌더에게 명확히 부탁하세요: “사용자가 자기 데이터만 보고 수정할 수 있게 해 줘.” 그 한 문장이 빠진 확인을 얼마나 자주 드러내는지 알면 놀랄 겁니다.
연동: 당신이 만들지 않았지만 어쨌든 쓰고 있는 것들
여기서 대부분의 비개발자가 실제로 무슨 일이 벌어지고 있는지를 과소평가합니다. 샘의 “크루아상이 준비됐어요” 이메일을 보내는 것은 코드가 아닙니다 — SendGrid나 Resend의 계정입니다. 조던의 수업 결제를 처리하는 것은 코드가 아닙니다 — Stripe입니다. 마야의 리더보드 사진을 호스팅하는 것은 코드가 아닙니다 — S3나 Cloudinary 같은 스토리지 서비스입니다.
각 연동은 두 곳에 나타납니다. 백엔드에 “이봐 Stripe, 이 카드를 청구해”라고 말하는 작은 코드 덩어리가 있습니다. 그리고 키 — 길고 비밀스러운 문자열 — 가 안전한 어딘가에 (보통 아무도 절대 커밋하면 안 되는 .env라는 파일에) 저장되어, 그 요청이 낯선 사람이 아니라 샘의 베이커리에서 왔다는 걸 Stripe에 증명합니다.
당신의 앱이 갑자기 이메일 보내기를 멈추거나 결제 받기를 멈춘 이유가 궁금하다면, 원인은 거의 항상 이 중 하나입니다: 만료된 키, 도달한 사용 한도, 또는 연동의 정책 변경. 코드가 깨진 게 아닙니다. 악수가 깨진 겁니다.
배포: 인터넷에 올라가는 법
마지막 조각은, 디스크 위의 폴더를 고객이 URL로 방문할 수 있는 것으로 바꾸는 부분입니다. 이건 보통 작은 세 가지가 함께 작동한다는 뜻입니다:
- 호스트: 당신의 백엔드를 돌리고 프런트엔드를 제공하는 Vercel, Netlify, Fly, Render 같은 서비스.
- 도메인: 당신의 호스트를 가리키는
mayas-leaderboard.com같은 이름. - 빌드: 지저분한 소스 파일들을 받아서, 실제로 돌아가는 더 가볍고 빠른 버전으로 바꾸는 레시피.
로컬에서는 작동하는데 프로덕션에서는 깨질 때, 말썽은 보통 여기 있습니다. 노트북에는 설정됐지만 호스트에는 안 된 키. 개발에는 설치됐지만 프로덕션에는 안 된 라이브러리. 당신 브라우저에는 있지만 라이브 사이트에는 없는 데이터베이스.
본전을 뽑는 오 분 습관
프로젝트의 모든 파일을 읽을 필요는 없습니다. 그것들 대부분이 무슨 일을 하는지 알 필요도 없습니다. 하지만 일주일에 한 번, 위의 폴더들을 하나씩 열어 보고 AI 빌더에게 평범한 말로 무엇이 바뀌었는지 물어보는 오 분짜리 점검은 해야 합니다.
마야는 금요일 오후마다 이걸 합니다. 이렇게 입력하죠: “이번 주에 스키마에서 뭐가 바뀌었고, 왜 바뀌었어?” 그리고: “내가 요청하지 않은 새 연동이 이 앱에 있어?” 답은 거의 늘 안심이 됩니다. 안심이 안 되는 몇 안 되는 경우에, 그녀는 문제가 아직 작을 때 잡아냅니다.
그게 구성 요소를 이해하는 일의 전부입니다. 개발자가 되려는 게 아닙니다. 그저 더 나은 질문을 할 수 있게 되려는 것입니다.
다음으로 갈 곳
이 둘러보기가 도움이 됐다면, 시간을 들일 만한 후속 글 둘이 있습니다. ‘멀쩡해 보이는’ 버그는 이 구성 요소 중 하나가 조용히 깨졌을 때 어떻게 할지 다루고, 시연 준비 완료 vs 프로덕션 준비 완료는 앱이 첫 단계에서 두 번째 단계로 넘어갔는지 어떻게 가려내는지 다룹니다. 같은 지도, 다른 용도입니다.