[바이브코딩 기초 2] 웹 서비스 만들기

AI에게 상품 소개 페이지를 만들어달라고 했습니다. 사진과 가격도 있고, 상품을 누르면 상세 설명도 나옵니다. 이제 새 상품을 올려보려고 하는데 등록할 곳이 없네요.

상품을 추가할 때마다 AI에게 코드를 고쳐달라고 요청할 수도 있습니다. 하지만 가격을 바꾸고, 품절을 표시하고, 공지를 올릴 때마다 그러기는 번거롭겠죠.

처음 기능을 설명할 때 손님이 볼 화면과 대표님이 운영할 화면을 함께 생각하면 이 일을 줄일 수 있습니다. 어떤 도구로 만들든 사용할 수 있는 상품 서비스 예시로 살펴볼게요. 서버·DB·배포라는 말이 낯설다면 1편의 용어 설명부터 볼 수 있습니다.

손님이 하는 일 옆에, 내가 할 일도 적어봅니다

“상품 목록과 상세 페이지를 만들어줘”라는 요청에는 손님이 볼 화면이 들어 있습니다. 그런데 상품은 누가 등록할까요? 이름을 잘못 적었다면 어디서 고칠까요?

기능을 적을 때 두 사람의 입장에서 나눠보면 빠진 화면을 찾기 쉽습니다.

오른쪽 일을 하는 화면이 관리자페이지입니다. 처음부터 많은 기능을 넣을 필요는 없어요. 상품만 소개하는 서비스라면 상품 등록·수정·품절 표시부터 시작할 수 있습니다.

예약이나 회원 기능은 필요할 때 추가합니다. 기획할 때 만들 기능과 당장 만들지 않을 기능을 적어두면 AI에게도 범위를 전달하기 좋습니다.

화면에서 무엇을 보여줄지 정했다면, 저장할 정보도 정합니다

상품 카드에 사진과 가격이 보인다면, 그 값을 보관할 곳도 필요합니다. “상품을 저장해줘”라는 요청에 어떤 항목을 저장할지 함께 적어볼게요.

이 중 ‘품절’과 ‘숨김’도 동작이 다릅니다. 품절 상품은 목록에 남기되 품절 표시를 할 수 있고, 숨긴 상품은 손님 목록에서 아예 제외할 수 있습니다.

이런 규칙을 정하면 화면을 보는 사람과 관리하는 사람이 같은 뜻으로 기능을 사용합니다. 모든 예외를 미리 적기보다, 실제로 쓸 상품 두세 개를 놓고 확인해보면 좋아요.

처음 요청에 여기까지 함께 적어볼 수 있어요

상품을 소개하는 웹 서비스를 만들고 싶어.

손님 화면은 상품 목록·상세와 공지 목록·상세야.
관리자페이지에서는 상품 등록·수정·판매 상태 변경,
공지 작성·수정·게시를 할 수 있게 해줘.

상품에는 이름, 설명, 원 단위 가격, 판매 상태, 사진을 저장해줘.
품절 상품은 표시를 붙여 목록에 남기고, 숨긴 상품은 손님에게 보이지 않게 해줘.
사용자 화면과 관리자페이지는 같은 상품과 공지 데이터를 사용해야 해.
관리자 계정과 로그인은 서비스 회원용과 따로 만들어줘.
관리자는 전용 주소에서 아이디와 비밀번호로 로그인하고, 로그인 상태도 서로 구분해줘.

현재 프로젝트에 있는 기능과 저장·배포 구성을 먼저 확인해줘.
예시 데이터로 화면을 보여준 뒤, 실제 저장과 조회까지 연결하자.

이미 쓰는 프로젝트가 있다면 그 구성을 살펴보고, 새로 만드는 서비스라면 필요한 기능과 운영 방법부터 정할 수 있어요.

상품은 함께 쓰고, 로그인은 따로 만듭니다

손님 화면과 관리자페이지는 같은 상품을 다룹니다. 대표님이 가격을 바꾸면 손님도 새 가격을 봐야 하니까요. 한 프로젝트와 DB 안에서 이 상품 정보를 함께 사용할 수 있습니다.

로그인은 따로 생각합니다. 손님이 서비스를 이용하는 계정과, 대표님이 상품을 등록하고 회원 정보를 보는 관리자 계정을 구분하는 거예요. 관리자 전용 주소에 로그인 화면을 두고, 별도로 정한 아이디와 비밀번호로 들어가게 만듭니다.

예를 들어 상품 소개만 하는 사이트라면 손님에게 회원가입이나 로그인을 요구하지 않을 수도 있습니다. 그래도 대표님은 관리자페이지에 로그인해서 상품을 올리고 수정할 수 있어요.

관리자 로그인을 따로 만들기 위해 상품을 다른 DB에 복사하거나 서비스 전체를 새 프로젝트로 만들 필요는 없습니다. 상품 정보는 함께 사용하면서, 누가 어떤 로그인으로 들어왔는지 따로 확인하는 구조입니다.

‘저장 완료’ 다음에 다시 열어봅니다

AI가 보여준 첫 화면에는 예시 상품만 들어 있을 수 있습니다. 등록 버튼을 누르면 화면의 목록에는 추가하지만, 실제로 DB에 기록하지 않은 상태일 수도 있고요.

저장을 연결했다면 같은 상품으로 다음 동작을 확인합니다.

1. 관리자페이지에서 새 상품을 등록합니다.
2. 새로고침하거나 화면을 닫았다 다시 열어도 상품이 남는지 봅니다.
3. 손님용 목록과 상세에서 같은 상품을 확인합니다.
4. 관리자가 가격을 수정하고, 손님 화면에서도 새 가격을 확인합니다.
5. 판매 상태를 품절과 숨김으로 각각 바꿔봅니다.

등록한 상품을 DB에 실제로 저장하고 다시 읽게 해줘. 관리자페이지에서 수정한 값과 손님 화면의 값이 같은지 확인해줘. 예시 데이터가 남은 화면도 찾아줘.

회원의 활동을 보고 싶다면 기록할 항목도 정합니다. 예약 신청과 취소를 저장했다면 그 기록은 볼 수 있지만, 기록하지 않은 모든 버튼 클릭까지 관리자페이지가 알아서 보여주지는 않습니다.

사진을 넣는다면 휴대폰 사진도 올려봐요

상품 사진은 파일 저장 공간에 보관하고, DB의 상품 정보에 그 사진을 찾을 주소를 기록하는 구성을 많이 씁니다. 저장할 곳을 연결하는 것과 사진 등록 기능을 완성하는 것은 조금 다릅니다.

대표님이 확인할 동작은 다음과 같습니다.

사진을 화면에 필요한 크기로 줄여서 저장해줘. 관리자가 상품 사진을 등록·교체할 수 있게 하고, 업로드 중이거나 실패했을 때도 상태를 보여줘.

사진을 어디에 보관하고 어떻게 전달하는지는 이미지 업로드 설명 글에서 더 볼 수 있습니다.

관리자 계정은 운영할 사람만 준비합니다

관리자 로그인 화면에는 아이디와 비밀번호로 들어가는 기능을 둡니다. 손님 누구나 가입할 수 있는 관리자 회원가입 화면은 만들지 않아요. 최초 관리자 계정은 대표님이 정해서 따로 준비합니다.

AI에게는 이렇게 요청할 수 있습니다.

관리자 전용 로그인 화면을 만들어줘.
서비스 회원 계정과 관리자 계정을 따로 두고, 로그인 상태도 분리해줘.
관리자 공개 회원가입은 화면과 기능 모두 만들지 말아줘.
최초 관리자 아이디와 비밀번호는 내가 정해서 별도로 설정할게.
로그인한 뒤에는 내 비밀번호를 바꿀 수 있게 해줘.

관리자 화면을 열거나 상품·공지를 수정할 때마다
서버에서 관리자 로그인 상태를 확인해줘.
완성하면 내가 접속할 관리자 전용 주소도 알려줘.

관리자 메뉴를 손님에게 보여주지 않아도 주소를 직접 입력하거나 수정 요청을 보낼 수는 있습니다. 그래서 화면 진입과 실제 관리 요청 모두에서 서버가 관리자 로그인을 확인합니다.

관리자 주소를 추측하기 어렵게 정할 수도 있어요. 다만 주소를 아는 것만으로 관리 기능을 사용할 수 있게 두지는 않습니다. AI가 알려준 관리자 주소를 북마크해두면 다음에 상품을 올릴 때 바로 찾아갈 수 있습니다.

확인할 때는 로그인도 각각 나눠봅니다.

손님에게 보낼 주소에서도 한 번 더 확인합니다

내 컴퓨터의 미리보기에서 잘 동작한다면, 실제 서비스 주소에서 쓰도록 배포할 차례입니다. 배포는 만든 코드를 다른 사람이 접속할 환경에 올리는 과정이었죠.

이때는 화면뿐 아니라 DB 연결과 로그인 같은 서버 설정도 필요합니다. 개발 환경에서 사용한 설정을 배포 환경이 그대로 갖고 있는지는 별도로 확인합니다.

현재 프로젝트의 배포 방식을 확인하고,
지금 확인한 코드를 실제 서비스 주소에서 사용할 수 있게 준비해줘.
DB·파일 저장·로그인에 필요한 연결과 서버 설정도 확인해줘.
배포를 시작한 뒤에는 성공 여부와 실제 접속 주소까지 확인해줘.

배포한 주소에서는 손님용 상품 목록을 열어보고, 관리자 전용 주소에 따로 로그인해서 상품 하나를 등록해봅니다. 가능하면 다른 기기에서도 같은 상품이 보이는지 확인합니다. 개발용 계정이나 설정에만 의존하던 부분을 찾는 데 도움이 됩니다.

배포가 실패했다면 진행 기록인 로그를 확인할 수 있습니다. AI에게 실패한 단계와 오류 내용을 전달하고, 고친 뒤 다시 배포합니다.

상품을 바꾸는 일과 서비스를 고치는 일을 나눠둡니다

운영 중에는 상품 가격을 고치는 일도 있고, 화면에 새 기능을 추가하는 일도 있습니다. 어느 쪽을 바꾸는지 알면 매번 코드를 수정할 필요가 있는지도 구분할 수 있어요.

환경변수는 서버 코드가 읽는 설정값입니다. 예를 들어 로그인용 비밀 값을 코드에 직접 적는 대신, 환경변수로 전달해 사용할 수 있어요. 이름을 어떻게 정하고 바꾼 값을 언제 반영할지는 프로젝트의 방식에 맞춥니다.

여기까지 정하면 대표님이 직접 운영할 일과 AI에게 개발을 요청할 일도 구체적입니다. 다음 기능을 생각할 때도 사용자 화면·운영 화면·보관할 정보를 함께 적어볼 수 있겠죠.

컴윗에는 이 과정에서 사용할 기본 코드와 일반 회원 로그인에서 분리한 관리자 구조, DB·파일 저장·로그인 기반, 호스팅·배포를 미리 준비해두었어요. 컴윗 프로젝트에서 시작하면 이런 연결을 하나씩 마련하는 과정을 줄이고, 만들 기능과 운영할 방법을 AI에게 설명하며 작업할 수 있어요.

새 기능을 요청할 때마다 “손님은 무엇을 하고, 나는 어디서 확인하고 수정할까?”를 함께 적어두면 운영에 필요한 화면을 덜 놓칠 수 있습니다.