[바이브코딩 기초 1] AI에게 만들어달랬더니, 모르는 말부터 나옵니다

AI에게 상품을 소개하는 서비스를 만들어달라고 했습니다. 그런데 이런 답이 돌아옵니다.

Next.js로 만들고, DB는 Supabase를 연결하겠습니다. 배포는 Vercel을 사용하면 됩니다.

대표님은 상품 사진과 가격을 보여주고 싶었을 뿐인데, 모르는 이름부터 나오네요. 검색해보면 호스팅, 백엔드, 서버리스처럼 또 다른 용어를 설명합니다.

하나씩 풀어볼게요. 컴퓨터에서 무슨 일이 일어나는지 먼저 보면, 도구 이름도 어디에 쓰는지 구분할 수 있습니다. 상품을 등록하면 손님이 목록과 상세 화면에서 보는 작은 서비스를 예로 들겠습니다.

서버 — 손님이 요청하면 답해주는 컴퓨터

손님이 휴대폰에서 상품을 누릅니다. 그러면 휴대폰은 인터넷으로 “이 상품의 정보를 보내줘”라고 요청하고, 어딘가에 있는 컴퓨터가 상품 이름과 가격을 보내줍니다.

이렇게 요청을 받고 답하는 컴퓨터를 서버라고 부릅니다. 그 컴퓨터에서 요청을 처리하는 프로그램도 서버라고 불러요. 우선은 내 휴대폰 건너편에서 상품 정보를 보내주는 컴퓨터를 떠올리면 됩니다.

서버가 꼭 특별하게 생긴 기계일 필요는 없어요. 개발할 때는 대표님의 노트북에서도 서버 프로그램을 실행합니다. AI가 코드를 작성하고 “이 주소를 열어서 확인해보세요”라고 안내하는 단계죠.

그런데 노트북을 닫으면 실행 중이던 프로그램도 멈추거나 잠듭니다. 와이파이가 끊길 수도 있고요. 손님이 언제 접속할지 모르는데, 대표님 노트북을 계속 켜놓고 지키기는 어렵겠죠.

그래서 실제 서비스에는 인터넷으로 접속할 수 있는 실행 환경을 마련합니다.

호스팅·배포 — 서비스를 둘 곳을 마련하고, 만든 코드를 올립니다

다른 회사가 관리하는 컴퓨터의 실행 공간이나 파일 보관 공간을 빌려 쓰는 서비스를 호스팅이라고 합니다. 내 컴퓨터를 계속 켜두는 대신, 호스팅 업체가 준비한 환경에서 서비스를 실행하는 거예요.

배포는 AI와 만든 코드와 필요한 파일을 그 환경에 올리고, 다른 사람이 사용할 수 있게 준비하는 과정입니다. 코드는 어떤 화면을 보여주고, 버튼을 누르면 무엇을 할지 컴퓨터가 실행할 수 있는 형태로 적어놓은 내용이고요.

도메인을 구매했다고 서비스가 생기는 것은 아닙니다. 그 주소로 접속한 손님을 내가 배포한 서비스로 연결합니다.

처음 배포한 뒤에 코드를 고쳤다면, 새 코드도 다시 배포합니다. 반면 상품 등록 기능으로 이름이나 가격을 바꾸는 일은 보통 데이터를 수정하는 일이에요. 새 상품을 하나 올릴 때마다 서비스 코드를 다시 배포할 필요는 없습니다. 이 차이는 뒤의 DB 설명과 이어집니다.

서버를 한 대 빌리면, 켜둔 시간에도 돈을 냅니다

서버를 빌리는 가장 익숙한 방식은 필요한 크기의 컴퓨터 한 대를 확보해서 계속 켜두는 것입니다. 실제로는 큰 컴퓨터를 나눈 가상 컴퓨터를 빌리는 경우도 많지만, 여기서는 내 서비스가 사용할 컴퓨터 한 대라고 생각해볼게요.

시간 단위로 빌린다면 손님이 없던 시간도 사용 시간에 들어갑니다. 컴퓨터가 내 서비스를 위해 계속 켜져 있었으니까요. PC방에 자리를 잡고 아무것도 하지 않아도 앉아 있던 시간만큼 요금이 나오는 것과 비슷합니다.

밤에 손님이 한 명도 없더라도 접속을 받으려면 서버를 준비해둡니다. 갑자기 사람이 많이 오면 더 큰 컴퓨터를 빌릴지, 여러 대로 나눌지도 고민합니다.

이렇게 직접 준비하고 관리할 일을 줄이는 방법 중 하나가 서버리스입니다.

서버리스 — 컴퓨터 한 대를 계속 빌려두는 부담을 줄입니다

서버리스는 서버를 마련하고 관리하는 일을 제공자에게 맡기고, 필요한 코드를 실행하는 방식입니다. 서버 자체는 있어요. 다만 대표님이 내 서비스 전용 컴퓨터를 한 대씩 빌리거나, 손님이 늘 때 컴퓨터를 더 준비하는 일을 덜 맡습니다.

대표적인 요청 기반 서버리스에서는 “상품 정보를 달라”는 요청이 오면 제공자가 준비한 실행 환경에서 코드를 처리합니다. 비용도 내 서버 한 대를 계속 켜둔 시간보다, 요청을 처리한 횟수나 실행에 쓴 시간·자원 등을 기준으로 계산합니다.

PC방 비유로 돌아가면, 서버를 한 대 빌리는 쪽은 자리를 계속 맡아두는 방식입니다. 요청 기반 서버리스는 일이 있을 때 그 일을 처리할 자원을 쓰는 쪽에 가깝고요.

그러니 서버리스의 장점은 손님이 없는 동안에도 내 서버 한 대 몫을 계속 확보하는 부담을 줄일 수 있다는 점입니다. 서비스를 처음 만들 때처럼 이용자가 언제 얼마나 올지 모르는 경우에 생각해볼 만한 방식이죠.

실제 상품에는 기본료나 저장 공간 요금도 있을 수 있습니다. 서버리스라는 이름만으로 모든 비용이 사라지는 것은 아니에요. 여기서는 어떤 방식으로 서버를 쓰고 비용을 계산하는지 이해하면 충분합니다.

프론트엔드·백엔드 — 눈에 보이는 화면과 뒤에서 처리하는 일

이제 서버에서 무엇을 하는지 조금 더 나눠볼게요. 상품 등록 화면에는 사진 선택 버튼, 이름 입력칸, 가격 입력칸이 있습니다. 손님 화면에는 상품 목록과 상세 설명이 보이고요.

사용자가 보고 조작하는 화면과 그 동작을 프론트엔드라고 부릅니다.

등록 버튼을 누른 뒤에는 다른 일도 필요합니다. 상품 이름을 비워두지 않았는지, 가격에 엉뚱한 값을 넣지 않았는지, 상품을 등록할 권한이 있는지 확인합니다. 입력한 내용을 보관하고, 손님이 요청할 때 찾아주는 일도 있고요. 이런 처리를 백엔드라고 합니다.

프론트엔드·백엔드는 역할을 나누는 말입니다. 반드시 별도 프로젝트나 별도 컴퓨터 두 대를 만들라는 뜻은 아닙니다. 화면과 서버 기능을 한 프로젝트에 작성하는 방법도 있습니다.

DB — 상품과 회원을 다음에도 기억하려면

대표님이 상품을 등록하고 노트북을 닫았습니다. 다음 날 다른 컴퓨터로 접속해도 어제 올린 상품이 보여야겠죠. 손님도 자기 휴대폰에서 같은 상품을 볼 수 있어야 하고요.

이렇게 나중에도 찾아 쓸 정보를 보관하는 곳을 데이터베이스, 줄여서 DB라고 합니다. ‘디비’라고 읽어요.

상품 정보를 표로 적는다고 생각해볼게요.

엑셀의 표와 비슷하게 볼 수 있습니다. 다만 사람이 매번 파일을 열어서 찾는 대신, 서비스의 프로그램이 “1번 상품을 가져와”, “2번 상품의 상태를 바꿔”라고 요청합니다. DB는 그 요청에 맞춰 정보를 기록하고 찾아줍니다.

상품 외에도 회원, 예약, 주문, 공지처럼 계속 기억할 정보가 있습니다. 각각 필요한 항목을 정해 보관해요. DB에 무슨 정보를 넣을지는 만들려는 서비스에 따라 달라집니다.

화면에 “저장했습니다”라는 글자만 띄우는 것과 DB에 실제로 저장하는 것은 다릅니다. AI가 만든 첫 화면은 임시 예시 데이터를 보여줄 수도 있어요. 그래서 “내가 등록한 상품을 저장하고, 다시 접속해도 읽어오게 해줘”라고 요청하는 겁니다.

DB를 관리하는 프로그램도 컴퓨터에서 실행합니다. 이 역할을 맡은 쪽을 DB 서버라고 부르기도 해요. 직접 준비할 수도 있고, DB를 제공하는 서비스를 이용할 수도 있습니다.

서버리스로 요청 처리 코드를 잠깐 실행해도 상품 기록은 계속 남아야 합니다. 그래서 코드를 실행하는 동안 쓰는 임시 메모리와, 데이터를 계속 보관하는 DB를 구분합니다.

스토리지 — 상품 사진과 첨부파일을 보관하는 곳

그럼 사진도 아까 상품 표에 넣을까요?

흔히 사진 파일은 별도 파일 저장 공간에 보관하고, 상품 정보에는 그 사진을 찾을 주소나 경로를 적습니다. 이 파일 저장 공간을 스토리지라고 불러요. 클라우드 드라이브에 사진을 보관하고 필요할 때 꺼내보는 것과 비슷합니다.

DB와 스토리지 모두 무언가를 저장하지만, 서비스에서 주로 맡기는 일이 다릅니다. 상품 정보를 검색하고 수정하는 일과, 사진·동영상·PDF 같은 파일을 보관하는 일을 나눠두는 거예요.

처음 배포할 때 넣은 로고와, 배포 후 손님이 계속 올리는 사진도 다릅니다. 손님이 오늘 올린 사진까지 다음 배포 때마다 사라지면 안 되겠죠. 계속 보관할 파일 저장 공간을 사용하는 이유입니다.

사진 업로드가 궁금하다면 이미지를 저장하고 보여주는 과정을 설명한 글에서 예시를 더 볼 수 있어요.

언어·프레임워크·라이브러리 — AI가 코드를 만들 때 쓰는 도구

지금까지는 서비스를 어디서 실행하고 데이터를 어디에 보관하는지 봤습니다. 이번에는 AI가 코드를 작성할 때 사용하는 이름입니다.

프로그래밍 언어는 컴퓨터가 할 일을 작성하는 문법입니다. JavaScript나 TypeScript라는 이름을 들어보셨다면 이쪽이에요. 버튼을 눌렀을 때 어떤 일을 할지, 입력한 값을 어떻게 확인할지 등을 코드로 적습니다.

라이브러리는 필요한 기능을 가져다 쓸 수 있게 다른 개발자가 만들어둔 코드 묶음입니다. 달력을 표시하거나, 로그인을 처리하거나, 화면에 애니메이션을 넣는 기능을 매번 처음부터 작성하지 않아도 됩니다.

프레임워크는 서비스 전체를 구성할 기본 구조와 자주 필요한 기능을 마련해둔 개발 도구입니다. 여러 페이지를 어떻게 나누고, 화면과 서버 코드를 어디에 작성할지 같은 틀도 제공합니다.

예를 들어 “TypeScript로 Next.js 프로젝트를 만들고 Better Auth를 붙인다”는 말은, TypeScript로 코드를 작성하고 Next.js의 구조를 사용하며 로그인 기능에는 Better Auth를 활용하겠다는 뜻입니다.

AI도 이런 도구를 가져다 씁니다. 따라서 도구 이름을 안다는 것보다 내 서비스에서 어떤 일을 맡겼는지 이해하는 쪽이 도움이 됩니다.

처음에 나온 Vercel·Supabase는 무엇이었을까요?

이름을 다시 보면 역할을 연결할 수 있습니다.

처음의 AI 답변은 “이 도구로 화면과 서버 코드를 만들고, 저 서비스에 데이터를 저장하고, 다른 서비스에서 실행하겠다”는 뜻이었습니다.

이름이 많았던 이유는 맡는 일이 여러 가지였기 때문입니다. 그렇다고 이 목록에 있는 서비스에 전부 가입할 필요는 없어요. 같은 일을 제공하는 서비스도 있고, 필요한 기능을 한곳에서 함께 제공하는 서비스도 있습니다.

AI가 만든 것을 확인할 때도 이 구분을 쓸 수 있어요

화면을 만들고, 요청을 처리하고, 데이터를 보관하고, 다른 사람이 접속할 곳에 올립니다. 각각 무엇을 하는지 알면 AI에게 확인할 내용도 구체적입니다.

• “이 화면은 예시만 보여주는 건가요, DB에 실제로 저장하나요?”
• “내 컴퓨터에서만 보이는 건가요, 다른 사람도 접속할 수 있게 배포했나요?”
• “손님이 올린 사진은 어디에 보관하나요?”

어떤 서비스를 만들든 화면·실행할 곳·데이터를 보관할 곳을 나눠서 살펴볼 수 있습니다. 모르는 이름을 또 만나면, 지금 만드는 서비스의 어느 부분에 쓰는지부터 물어보면 되고요.

컴윗에는 여기서 설명한 호스팅·DB·파일 저장·로그인 기반과 AI가 사용할 기본 코드·개발 규칙을 미리 준비해두었어요. 컴윗 프로젝트에서 시작하면 이런 구성을 하나씩 연결하는 과정을 줄이고, 만들고 싶은 기능을 AI와 구체화할 수 있어요.

AI가 만든 화면을 확인할 때 “무엇을 보여주고, 어디에 저장하고, 어디서 실행하나요?”를 함께 물어보면 조금 덜 막막할 거예요.