매일 바이브코딩

8. 전용 AI 카피라이터 만들기(OpenAI API 활용)

bravenewabyss — Tue, 24 Feb 2026 11:00:24 +0900

지금까지 만든 앱들은 데이터를 저장하고 불러오는 기록의 도구였다. 이번에는 한 단계 더 나아간다. 앱이 스스로 생각하고 글을 쓰게 만드는 것이다. 바로 OpenAI의 API를 연동해서 내 브랜드 전용 AI 카피라이터를 만드는 프로젝트다. 회사를 운영하다 보면 가장 귀찮은 게 인스타그램 캡션 쓰기나 상세페이지 문구 작성이다. 챗GPT한테 시켜도 되지만, 매번 "너는 감성적인 브랜드 마케터야. 톤앤매너는 차분하게"라고 프롬프트를 치는 것도 일이다. 오늘은 클릭 한 번으로 우리 브랜드 톤에 딱 맞는 마케팅 문구를 뽑아주는 나만의 앱을 만든다. 이 기술을 익히면 요즘 유행하는 AI 서비스(SaaS)를 직접 만들 수 있다.

1. 챗GPT랑 뭐가 다를까

그냥 챗GPT 쓰면 되지 않냐고 할 수 있겠지만 챗GPT는 범용적이다. 우리가 만들 앱은 시스템 프롬프트(System Prompt)가 내장된 앱이다. 매번 설정을 입력할 필요 없이 키워드만 던지면 우리 브랜드만의 문체로 결과물이 나온다. 마치 교육이 아주 잘 된 신입 사원을 책상에 앉혀두는 것과 같다. 봄 신상'으로 글 하나 써봐 하면 찰떡같이 알아듣는 녀석을 만드는 것이다.

2. 준비물: OpenAI API 키

먼저 OpenAI 개발자 사이트(platform.openai.com)에 가서 API 키를 발급받아야 한다. 챗GPT 유료 결제와는 별개다. API 사용료는 쓴 만큼 나가는데 텍스트 생성 정도는 몇백 원 수준이라 부담 없다. 발급받은 키(sk-...)를 프로젝트의 .env 파일에 VITE_OPENAI_API_KEY라는 이름으로 저장한다. 이 키는 당연히 절대 깃허브에 올리면 안 된다. 거지가 될 수도 있다.

3. 화면 만들기

커서에게 요청해서 입력 화면을 만든다. React + Vite로 AI 카피라이팅 툴을 만들어달라고 하고 다음 문장을 입력하자.

입력창: 상품명, 주요 특징(키워드), 타겟 고객층
톤앤매너 선택: 감성적인, 유머러스한, 전문적인
생성 버튼: 카피 생성하기
결과창: 생성된 문구가 나오고, 복사 버튼이 있어야 해.

4. 프롬프트 엔지니어링을 코드로

이 앱의 영혼은 바로 API 요청 코드에 있다. 커서가 코드를 짜주겠지만, 우리가 신경 써야 할 건 messages 부분이다. 여기에 우리의 비법 소스를 넣어야 한다. 커서에게 이렇게 수정해 달라고 요청하자.

API 요청을 보낼 때 system 메시지에 이렇게 넣어줘.

당신은 10년 차 감성 브랜드 에디터입니다. 문장은 간결하고 여운이 있어야 합니다. 이모지는 절제해서 사용하세요. 홍보 티가 나지 않으면서 구매 욕구를 자극해야 합니다.

5. 결과 확인

이제 테스트를 해보자.

상품명: 포근한 머그컵

특징: 손잡이가 큼, 따뜻한 색감

타겟: 재택근무 직장인

버튼을 누르고 2~3초 뒤 결과창에 글이 뜬다. 로딩 스피너는 필수다. 직접 썼으면 30분 걸렸을 문장이 3초 만에 나온다.

6. 확장 가능성

이 앱을 조금만 응용하면 무한한 확장이 가능하다.

고객 리뷰 답변기: 리뷰를 붙여넣으면 소중한 리뷰 감사합니다 고객님~ 하고 답변을 써주는 앱

블로그 초안 생성기: 주제만 던지면 서론-본론-결론을 잡아주는 앱

영어 이메일 번역기: 환불 거절해 라고 치면 유감스럽게도 정책상...으로 정중하게 바꿔주는 앱.

지금까지 배운 CRUD(저장) 기술에 AI(생성) 기술을 합치면, 이제 단순한 웹사이트가 아니라 진짜 서비스(SaaS)를 만드는 1인 개발자가 되는 것이다.

7. 외부 API 활용 - 환율 계산기 만들기

bravenewabyss — Sun, 22 Feb 2026 10:15:31 +0900

지금까지 만든 앱들은 모두 Firebase에 직접 데이터를 넣고 꺼내는 방식이었다. 이번에는 다른 걸 해본다. 인터넷에 이미 존재하는 데이터를 가져와서 보여주는 앱을 만든다. 이걸 외부 API를 사용한다고 표현한다.

회사를 운영하다 보면 환율을 확인할 일이 자주 있다. 해외 거래처가 있거나 해외에서 원자재를 수입하거나 해외 솔루션을 쓰고 있으면 달러 환율에 따라 비용이 달라진다. 매번 네이버에서 검색하는 것보다 내가 자주 보는 통화만 모아서 한눈에 보고 금액을 바로 계산할 수 있으면 편하다.

1. API가 뭔데

API는 쉽게 말해서 데이터를 주고받는 창구다. 은행 창구에 가서 오늘 달러 환율 알려주세요 라고 하면 직원이 알려주듯이 환율 API에 요청을 보내면 현재 환율 데이터를 돌려준다. 다만 사람이 아니라 컴퓨터끼리 통신하는 것이고 창구가 아니라 인터넷 주소(URL)로 요청한다는 차이만 있다. 세상에는 무료로 쓸 수 있는 API가 엄청나게 많다. 환율, 날씨, 뉴스, 주식, 지도 등 거의 모든 종류의 데이터를 API로 가져올 수 있다. 바이브 코딩으로 이 API들을 활용하면 만들 수 있는 앱의 범위가 확 넓어진다.

2. 환율 API 선택

무료 환율 API가 여러 개 있다. 이번에는 ExchangeRate-API를 사용한다. 무료 플랜에서 월 1500회까지 요청할 수 있어서 개인이나 소규모 회사에서 쓰기에 충분하다. 먼저 exchangerate-api.com에 가서 무료 계정을 만든다. 가입하면 API 키를 발급받는다. 이 키를 .env 파일에 저장한다. Firebase API 키를 저장했던 것과 같은 방식이다. API 키를 .env 파일에 추가한다. VITE_EXCHANGE_API_KEY=발급받은키 이런 식이다.

3. 프로젝트 시작

이번 프로젝트는 로그인 없이 만든다. 환율 계산기는 누구나 접속해서 바로 쓸 수 있으면 되니까. Firebase도 필요 없다. 데이터를 저장할 일이 없고 외부 API에서 실시간으로 가져오면 되기 때문이다.

React + Vite + Tailwind CSS로 환율 계산기 앱을 만들어줘. ExchangeRate-API를 사용해서 실시간 환율을 가져와. 기능은 이렇게 해줘.

기준 통화를 선택할 수 있어 (기본값은 KRW 한국 원)
자주 쓰는 통화의 환율을 카드 형태로 보여줘 (USD, EUR, JPY, CNY, GBP)
금액을 입력하면 선택한 통화로 실시간 환산해줘
마지막 업데이트 시간을 표시해줘

이번 프로젝트에서 다른 점은 Firebase가 없다는 것이다. 데이터를 저장하지 않으니 Firestore 연결도 필요 없다. 외부 API에서 데이터를 가져와서 화면에 보여주기만 하면 된다. 덕분에 프로젝트 구조가 훨씬 단순하다.

4. API 연동에서 자주 나는 에러

외부 API를 처음 연동하면 거의 100% 에러를 만난다. 흔한 것들을 정리한다. API 키가 안 먹히는 경우. 가입 직후에는 키가 활성화되는 데 시간이 좀 걸릴 수 있다. 몇 분 기다렸다가 다시 시도한다. 그래도 안 되면 .env 파일에 키를 제대로 넣었는지 확인한다. 앞뒤로 공백이 들어간 경우가 의외로 많다. CORS 에러. 브라우저 콘솔에 CORS policy 어쩌고 하는 빨간 에러가 나오면 이거다. 쉽게 말하면 브라우저가 보안상의 이유로 외부 서버에 직접 요청하는 걸 막는 것이다. 대부분의 공개 API는 이 문제가 없지만 간혹 발생한다. AI에게 에러 메시지를 보여주면 해결 방법을 알려준다. 데이터 형식이 예상과 다른 경우. API가 돌려주는 데이터의 구조를 모르면 코드에서 값을 제대로 꺼내지 못한다. 이 API의 응답 데이터 구조를 콘솔에 출력해서 보여달라고 AI에게 요청하면 데이터가 어떻게 생겼는지 확인할 수 있다.

5. 환율 변환 기능

기본 환율 표시가 되면 실제로 유용한 변환 기능을 추가한다. 아래와 같이 요청하면 된다.

금액 입력 기능을 강화해줘. 원화 금액을 입력하면 모든 카드에 해당 금액의 환산 결과가 실시간으로 표시돼. 반대로 달러 카드에 달러 금액을 입력하면 원화로 얼마인지도 보여줘. 양방향 변환이 가능하게 해줘.

이 기능을 만들 때 소수점 처리에 신경 써야 한다. 환율 계산 결과가 0.7283746528 같은 숫자로 나오면 보기 불편하다. 환율은 소수점 둘째 자리까지, 원화 금액은 정수로 표시하고 천 단위 콤마도 넣어달라고 요청한다.

6. 나만의 통화 추가

기본 5개 통화 외에 자주 확인하는 통화를 추가할 수 있으면 더 편하다. 더하기 버튼을 누르면 통화 코드를 검색해서 추가할 수 있는 기능, 추가한 통화는 로컬 스토리지에 저장해서 브라우저를 닫았다 열어도 유지되도록 만들어보자. 이번에는 Firebase 대신 로컬 스토리지를 사용한다. 간단한 설정값을 저장할 때는 굳이 서버에 올릴 필요 없이 브라우저에 저장하면 된다. 로그인이 필요 없는 앱이니 사용자별로 구분할 필요도 없다.

7. 배포

Firebase를 안 쓰니까 환경변수가 API 키 하나뿐이라 배포 설정이 간단하다. Netlify 환경변수에 VITE_EXCHANGE_API_KEY만 추가하면 된다. Git에 커밋하고 GitHub에 푸시한 다음 Netlify에 연결하면 끝이다. 빌드 커맨드와 배포 폴더 설정은 이전 프로젝트들과 동일하다. 배포 후 핸드폰에서 접속해 보자. 외근 중에 거래처와 통화하면서 바로 환율을 확인할 수 있다.

8. API 활용의 가능성

환율 API 하나를 연동해 봤을 뿐인데 활용할 수 있는 API가 얼마나 많은지 알게 되면 아이디어가 쏟아진다. 몇 가지만 예를 들면 이렇다.

날씨 API를 연동하면 매장이나 행사장의 날씨를 미리 확인하는 대시보드를 만들 수 있다. 택배 API를 연동하면 발송한 물건의 배송 상태를 한 화면에서 추적할 수 있다. 구글 캘린더 API를 연동하면 팀 일정을 한눈에 보는 보드를 만들 수 있다.

바이브 코딩의 진짜 힘은 이런 API들을 조합해서 나만의 도구를 만들 수 있다는 것이다. 세상에 이미 있는 데이터를 가져다가 내가 원하는 형태로 보여주는 것. 이전까지는 직접 데이터를 입력하는 앱만 만들었다면 이제는 세상의 데이터를 끌어와서 활용할 수 있게 된 것이다.

커서 Rules 파일로 AI 길들이기

bravenewabyss — Fri, 20 Feb 2026 10:05:54 +0900

바이브 코딩을 하면서 가장 답답한 순간은 AI가 내 말을 듣긴 하는데 자꾸 엉뚱한 방향으로 가는 것이다. 한국어로 답변하라고 했는데 영어가 섞여 나온다거나 새 기능을 추가해달라고 했더니 기존 코드 구조를 바꿔버린다. 파일을 나눠달라고 했는데 하나의 파일에 다 때려 넣는다. 매번 같은 말을 반복하는 건 시간 낭비다.

커서에는 이 문제를 해결하는 기능이 있다. 바로 Rules 파일이다. AI에게 프로젝트의 규칙을 미리 알려주는 설명서 같은 것이다. 한 번 만들어 두면 매번 말하지 않아도 AI가 규칙을 따른다.

1. Rules 파일이란

Rules 파일은 프로젝트 폴더에 넣어두는 텍스트 파일이다. AI가 코드를 작성하거나 수정할 때 이 파일을 자동으로 참조한다. 마치 신입 직원에게 주는 업무 매뉴얼과 비슷하다. 우리 회사는 이렇게 일하니까 이 규칙을 따라라 라고 정리해 두는 것이다. 커서에서는 .cursor/rules 폴더 안에 .mdc 확장자로 파일을 만들면 된다. 예전에는 .cursorrules라는 파일 하나를 쓰는 방식이었는데 지금은 여러 개의 규칙 파일을 폴더에 나눠서 관리할 수 있게 발전했다. 물론 예전 방식도 여전히 작동한다.

2. 어떤 걸 적어야 하나

Rules 파일에 적어야 하는 건 크게 네 가지다.

첫째로 기술 스택이다. 이 프로젝트는 React와 Vite를 사용하고 스타일링은 Tailwind CSS를 쓰며 백엔드는 Firebase를 사용한다고 적어두면 AI가 매번 기술 스택을 물어보지 않는다. 또한 엉뚱한 라이브러리를 가져다 쓰는 일도 줄어든다.

둘째로 코드 스타일이다. 함수 선언을 화살표 함수로 할지 일반 함수로 할지, 변수명은 한국어 주석을 달지 영어만 쓸지 같은 것들이다. 사소해 보이지만 이런 걸 통일하지 않으면 코드가 금방 지저분해진다. AI는 대화마다 스타일이 달라질 수 있기 때문에 규칙을 정해두면 일관성이 유지된다.

셋째로 프로젝트 구조다. components 폴더에는 UI 컴포넌트만 넣고 pages 폴더에는 페이지 단위 파일만 넣어라. utils 폴더에는 공통 함수를 넣어라 처럼 폴더별 역할을 정해두면 AI가 새 파일을 만들 때 올바른 위치에 넣는다.

넷째로 금지 사항이다. 이게 의외로 중요하다. 기존 파일의 구조를 변경하지 말아라, 새로운 라이브러리를 설치하기 전에 반드시 확인을 받아라, 인라인 스타일을 사용하지 말아라 같은 것들이다. AI가 좋은 의도로 코드를 개선하겠다며 건드리는 걸 방지할 수 있다.

3. 실제 예시

프로젝트 개요로는 회사 내부 관리 시스템이며 React와 Vite 기반이고 Firebase Firestore를 데이터베이스로 사용하고 Netlify에 배포한다는 내용을 적었다. 코딩 규칙으로는 컴포넌트는 함수형으로만 작성하고 상태 관리는 useState와 useContext를 사용하며 외부 라이브러리 추가 시 반드시 물어볼 것이라는 내용을 적었다. 응답 규칙으로는 한국어로 답변하고 코드 변경 시 변경 이유를 간단히 설명하며 기존 파일을 수정할 때는 변경되는 부분만 보여달라는 내용을 적었다. 이 정도만 적어둬도 AI의 행동이 확연히 달라진다. 특히 기존 파일 수정 시 변경 부분만 보여달라는 규칙은 AI가 전체 파일을 다시 출력하는 걸 막아서 대화 길이를 크게 줄여준다. 예전에 직접 AI에게 코드를 작성하게 한 뒤에 붙여넣기 하던 시절에는 무조건 복사 붙여넣기 할 수 있도록 전체 코드를 작성해달라고 했었는데. 불과 반년 정도 되는 사이에 바이브코딩도 엄청난 발전을 했다는 게 새삼 실감이 난다.

4. Rules 파일 만드는 법

가장 쉬운 방법은 역시 AI에게 맡기는 것이다. 커서 채팅창에서 이 프로젝트의 기술 스택과 구조를 분석해서 Rules 파일을 만들어줘 라고 하면 된다. 정확하게 하고 싶다면 cursor/rules 폴더에 만들어달라고 요청해도 된다. AI가 현재 프로젝트의 파일 구조와 사용 중인 라이브러리를 분석해서 적절한 Rules 파일을 생성해 준다. 여기에 내가 원하는 규칙을 추가하면 된다.

처음부터 완벽한 Rules 파일을 만들려고 하지 않아도 된다. 작업하면서 AI가 자꾸 틀리는 부분이 나타나면 그때그때 규칙을 추가하는 방식이 현실적이다. 아 또 인라인 스타일 쓰네 라고 느끼면 그때 금지 규칙을 추가하면 된다.

5. 주의할 점

Rules 파일을 너무 길게 쓰면 역효과가 난다. AI의 컨텍스트에도 한계가 있기 때문에 규칙이 수십 페이지가 되면 오히려 중요한 규칙을 놓칠 수 있다. 핵심만 간결하게 적는 게 좋다. 또한 Rules 파일과 실제 대화에서 한 말이 충돌하면 AI가 혼란스러워한다. Rules에는 Tailwind를 쓰라고 적어놨는데 대화에서 이건 그냥 CSS로 해줘 라고 하면 어느 쪽을 따를지 헷갈려한다. 일시적으로 규칙을 무시하고 싶을 때는 이번만 Rules의 스타일링 규칙 무시하고 인라인 CSS로 해달라고 명확하게 말해주는 게 좋다.

마무리

Rules 파일은 바이브 코딩의 생산성을 한 단계 올려주는 도구다. 매번 같은 지시를 반복하지 않아도 되고 AI가 일관된 코드를 만들어 주니까 프로젝트가 커져도 코드 품질이 유지된다. 10분 투자해서 Rules 파일을 만들어 두면 앞으로 매 대화마다 1분씩 아끼게 된다. 대화가 100번이면 100분이다. 만들지 않을 이유가 없음.

6. 출퇴근 관리 앱 만들기 - (2) 기능 구현과 배포

bravenewabyss — Wed, 18 Feb 2026 10:10:15 +0900

지난 편에서 로그인과 역할 분기까지 만들었다. 이번 편에서는 진짜 핵심인 출퇴근 기록 기능과 관리자 대시보드를 만들고 배포까지 마무리한다. 이번 편은 캡쳐 없이 빠르게 과정 설명으로만 진행하겠다.

1. 직원 화면 - 출퇴근 버튼 만들기

직원이 로그인하면 보이는 메인 화면에 출근 버튼과 퇴근 버튼을 넣는다. 커서에 이렇게 요청한다.

직원 메인 페이지에 출퇴근 기능을 만들어줘. 화면 구성은 이렇게 해줘.

상단에 오늘 날짜와 현재 시간을 실시간으로 표시
큰 출근 버튼과 퇴근 버튼
출근 버튼을 누르면 현재 시간이 Firebase에 저장되고 버튼이 비활성화돼
퇴근 버튼은 출근을 찍은 후에만 활성화돼
오늘 이미 출근했다면 출근 시간을 보여주고 출근 버튼은 비활성화해줘
하단에 이번 주 내 출퇴근 기록을 테이블로 보여줘

요청이 꽤 구체적인데 이게 바이브 코딩에서 결과물의 품질을 결정하는 핵심이다. 출퇴근 기능 만들어달라고만 하면 AI가 내 의도와 다른 방향으로 갈 확률이 높다. 구체적으로 말할수록 수정할 일이 줄어든다. AI가 코드를 만들면 npm run dev로 확인한다. 출근 버튼을 눌러보자. 현재 시간이 기록되면서 버튼이 비활성화되고 퇴근 버튼이 활성화되면 정상이다. Firebase 콘솔에서도 확인해 본다.

2. 자주 발생하는 문제들

이 단계에서 자주 마주치는 문제가 몇 가지 있다.

첫 번째는 시간대 문제다. Firebase에 저장된 시간이 한국 시간이 아니라 UTC로 저장되는 경우가 있다. 오전 9시에 출근 버튼을 눌렀는데 기록에 자정이 찍혀 있다면 이 문제다. AI에게 시간을 한국 시간(KST)으로 저장하고 표시해달라고 요청하면 된다.

두 번째는 날짜 변경 시점이다. 자정이 지나면 새로운 날의 출근이 가능해야 하는데 이게 제대로 안 되는 경우가 있다. 날짜 기준은 한국 시간 자정으로 해달라고 하고 자정이 지나면 새로운 출근이 가능하게 해달라고 명시한다.

세 번째는 중복 출근 방지다. 네트워크가 느려서 출근 버튼을 두 번 누르면 출근 기록이 두 개 생길 수 있다. 출근 버튼을 누르면 즉시 비활성화해서 중복 클릭을 방지하라고 요청하고 같은 날에 출근 기록이 이미 있으면 다시 출근할 수 없게 서버 측에서도 체크해달라고 요청한다.

이런 문제들은 직접 테스트하면서 발견하게 된다. 처음부터 완벽할 수 없으니 발견할 때마다 AI에게 수정을 요청하면 된다. 다만 수정을 요청하기 전에 반드시 현재 상태를 Git에 커밋해 두자.

3. 관리자 대시보드 만들기

직원 화면이 완성됐으면 관리자 화면을 만들 차례다. 관리자는 전체 직원의 출퇴근 현황을 한눈에 볼 수 있어야 한다.

관리자 대시보드를 만들어줘. 기능은 이렇게 해줘.

오늘 날짜 기준으로 전체 직원의 출퇴근 현황을 보여줘. 출근한 사람은 초록색, 아직 안 온 사람은 빨간색으로 표시
달력이나 날짜 선택기로 다른 날짜의 기록도 조회할 수 있게 해줘
직원별로 이번 달의 출퇴근 기록을 볼 수 있는 상세 보기 기능
전체 데이터를 테이블 형태로 깔끔하게 정리해줘

관리자 대시보드는 데이터를 읽어오는 양이 많기 때문에 로딩 속도가 느릴 수 있다. 데이터를 불러오는 동안 로딩 스피너를 보여달라고 추가 요청하면 사용자 경험이 좋아진다. 빈 화면에서 갑자기 데이터가 뜨는 것보다 로딩 중이라는 표시가 있는 게 훨씬 자연스럽다.

4. 테스트용 데이터 넣기

관리자 대시보드를 테스트하려면 여러 직원의 출퇴근 데이터가 필요하다. 혼자 테스트하면 데이터가 하나뿐이라 대시보드가 허전하다. 테스트용으로 가상의 직원 5명과 지난 일주일간의 출퇴근 데이터를 Firebase에 넣어주는 스크립트를 만들어달라고 해보자. AI가 테스트 데이터를 생성하는 스크립트를 만들어 줄 것이다. 이걸 한 번 실행하면 대시보드에 여러 직원의 데이터가 표시되어 제대로 작동하는지 확인할 수 있다. 테스트가 끝나면 가짜 데이터는 지우자.

5. 디자인 다듬기

기능이 완성됐으면 디자인을 좀 다듬을 차례다. AI가 만든 기본 디자인도 나쁘지 않지만 몇 가지를 손보면 훨씬 프로페셔널해 보인다.

전체적인 UI를 좀 더 다듬어줘. 로그인 페이지에 회사 이름을 크게 넣어주고 직원 페이지의 출근/퇴근 버튼을 좀 더 크고 눈에 띄게 만들어줘. 출근 버튼은 파란색 계열, 퇴근 버튼은 주황색 계열로 해줘. 그리고 모바일에서도 잘 보이도록 반응형으로 만들어줘.

모바일 대응은 꼭 해야 한다. 직원들이 출퇴근을 찍을 때 대부분 핸드폰을 쓸 테니까. 크롬 개발자 도구에서 모바일 화면 크기로 확인하거나 실제 핸드폰으로 테스트해 보자.

6. 배포 전 체크리스트

Netlify에 배포하기 전에 확인해야 할 것들이 있다.

첫째로 환경변수다. .env 파일의 Firebase 설정값이 Netlify에도 등록되어 있는지 확인한다. 4편에서도 언급했지만 이걸 빠뜨리면 배포된 사이트에서 Firebase 연결이 안 된다.

둘째로 Firebase 보안 규칙이다. 테스트할 때 모든 읽기쓰기를 허용해 뒀다면 이제 제한을 걸어야 한다. AI에게 Firebase 보안 규칙을 설정해달라고 요청하자. 로그인한 사용자만 자기 출퇴근 기록을 읽고 쓸 수 있게 하고 관리자는 모든 기록을 읽을 수 있게 해달라고 요청한다.

셋째로 에러 처리다. 인터넷이 끊겼을 때, 로그인 세션이 만료됐을 때 등 예외 상황에서 앱이 멈추지 않는지 확인한다. 네트워크 에러가 발생했을 때 사용자에게 알림을 보여주는 에러 처리를 추가해달라고 요청하면 좋다.

7. Netlify에 배포

체크리스트를 확인했으면 배포한다. 과정은 메모 앱 때와 같다. 먼저 Git에 최종 커밋을 한다. Netlify에서 GitHub 저장소를 연결하면 자동으로 빌드와 배포가 진행된다. 배포가 완료되면 URL을 받아서 테스트한다. 핸드폰으로도 접속해서 출퇴근 버튼이 잘 작동하는지, 관리자 대시보드가 제대로 보이는지 확인한다.

8. 완성 후 느낀 점

메모 앱에서 출퇴근 관리 앱으로 넘어오면서 복잡도가 꽤 올라갔다. 로그인, 역할 분기, 날짜 처리, 관리자 전용 화면 등 새로운 개념이 여러 개 들어왔다. 하지만 기본 구조는 같다. 데이터를 만들고 읽고 수정하고 삭제하는 CRUD다. 출근 버튼을 누르면 데이터를 만들고 대시보드에서 보여주면 읽는 것이다. 이 패턴을 이해하면 다음에는 더 복잡한 앱도 만들 수 있다. 재고 관리 앱이든 고객 관리 앱이든 결국 CRUD의 확장이다. 복잡한 앱이라고 해서 완전히 새로운 개념이 필요한 게 아니라 같은 패턴을 더 많은 데이터에 적용하는 것이다.

5. 출퇴근 관리 앱 만들기 - (1) 기획과 로그인

bravenewabyss — Mon, 16 Feb 2026 10:05:45 +0900

메모 앱을 만들어 봤으니 이제 좀 더 실용적인 걸 만들어 보자. 이번에 만들 건 직원 출퇴근 관리 앱이다. 내가 바이브 코딩을 시작한 계기가 업무에 필요한 기능을 만들고 싶어서였는데 출퇴근 관리는 소규모 회사에서 항상 애매한 영역이다. 엑셀로 관리하자니 귀찮고 전문 솔루션을 쓰자니 비용이 부담스럽다. 이런 틈새를 바이브 코딩으로 채울 수 있다.

이 프로젝트는 메모 앱보다 복잡하기 때문에 두 편에 걸쳐 진행한다. 이번 편에서는 기획과 로그인 기능까지 만들고 다음 편에서 출퇴근 기록과 관리자 화면을 만든다.

1. 만들기 전에 기획부터

메모 앱 때는 바로 AI에게 만들어달라고 했지만 좀 더 복잡한 앱은 기획이 먼저다. 기획이라고 해서 거창한 게 아니다. 누가 쓰는지 어떤 기능이 필요한지 화면이 몇 개인지 정리하는 것이다. 출퇴근 관리 앱의 사용자는 두 종류다. 직원과 관리자. 직원은 출근 버튼과 퇴근 버튼을 누른다. 관리자는 전체 직원의 출퇴근 기록을 확인한다. 이걸 정리하면 이렇다.

직원 기능은 로그인, 출근 버튼 누르기, 퇴근 버튼 누르기, 내 출퇴근 기록 보기 이렇게 네 가지다. 관리자 기능은 로그인, 전체 직원 출퇴근 현황 보기, 날짜별 기록 조회 이렇게 세 가지다. 화면은 로그인 화면, 직원용 메인 화면, 관리자용 대시보드 이렇게 세 개면 된다.

이 정도만 정리해도 AI에게 요청할 때 훨씬 명확해진다. 처음 글에서도 말했지만 AI는 내 머릿속을 읽지 못한다. 내가 뭘 원하는지 구체적으로 말해줘야 원하는 결과가 나온다.

2. 프로젝트 세팅

새 폴더를 만들고 커서에서 연다. 그리고 채팅창에 이렇게 요청한다.

React + Vite + Tailwind CSS 기반의 출퇴근 관리 앱 프로젝트를 세팅해줘. Firebase Firestore를 데이터베이스로 쓰고 Firebase Authentication으로 로그인을 구현할 거야. 먼저 프로젝트 초기 세팅과 폴더 구조만 만들어줘. 기능 구현은 아직 하지 마.

마지막 문장이 중요하다. 원하는 것을 말하면 즉시 AI가 한꺼번에 모든 기능을 만들려다가 코드가 복잡해질 수 있다. 단계를 나눠서 요청하는 게 바이브 코딩의 핵심 전략이다. AI가 프로젝트를 세팅해 주면 폴더 구조를 확인한다. 3편에서 했던 것처럼 .env 파일에 Firebase 설정값을 넣고 Firebase 콘솔에서 Authentication을 활성화해야 한다. AI에게 Firebase Authentication 이메일/비밀번호 로그인 방식을 사용할 거야. 설정 방법 알려줘 라고 하면 Firebase 콘솔에서 어디를 클릭해야 하는지 안내해 준다. 간단히 설명하자면 Firebase에서 데이터베이스 생성 후 Authentication 메뉴에서 이메일/비밀번호 로그인을 활성화시키면 된다.

다양한 로그인 방법을 선택할 수 있다. 이메일/비밀번호 또는 구글 로그인 정도가 가장 보편적인듯.

사용 설정만 체크하면 끝

3. 로그인 화면 만들기

세팅이 끝났으면 첫 번째 기능인 로그인을 만든다. 채팅창에 로그인 페이지를 만들어달라고 말한다. 이메일/비밀번호 외에 구글도 연동할 수 있는데 원할 경우 구글 연동을 하고 싶다고 하면 세팅법을 알려준다. 원하는 방식으로 선택하자. 로그인 페이지 구현 후 원하는 액션이 있다면 구체적으로 정리하자. 로그인에 성공하면 메인 페이지로 이동하게 해줘. 계정이 없는 사람을 위한 회원가입 링크를 넣어줘. 디자인은 화면 중앙에 로그인 폼이 오도록 해줘. 이런 요청들을 하면 AI가 원하는대로 로그인 페이지를 만들어 줄 것이다. npm run dev로 확인해 보면 이런 화면이 나온다.

4. 회원가입 기능 추가

로그인이 있으려면 회원가입도 있어야 한다. 바로 이어서 요청한다.

회원가입 페이지도 만들어줘. 이메일, 비밀번호, 이름을 입력받아. Firebase Authentication으로 계정을 만들고 Firestore에 사용자 정보도 저장해줘. 사용자 정보에는 이름과 역할을 포함해. 기본 역할은 employee로 설정해.

여기서 역할(role) 필드가 핵심이다. 나중에 관리자 화면과 직원 화면을 분리할 때 이 역할 값을 기준으로 어떤 화면을 보여줄지 결정한다. admin이면 관리자 대시보드를 보여주고 employee면 출퇴근 화면을 보여주는 식이다. 회원가입을 테스트해 보자. 가입 후 Firebase 콘솔을 확인하면 두 군데에 데이터가 생긴다. Authentication 탭에 새 사용자가 추가되어 있고 Firestore에는 users 컬렉션에 이름과 역할 정보가 저장되어 있을 것이다.

5. 로그인 후 화면 분기

이제 로그인하면 역할에 따라 다른 화면을 보여줘야 한다. 이 부분이 메모 앱에는 없었던 새로운 개념이다.

"로그인 성공 후 Firestore에서 해당 사용자의 role을 확인해줘. role이 admin이면 관리자 대시보드 페이지로, employee면 직원 메인 페이지로 이동하게 해줘. 아직 각 페이지의 내용은 '관리자 페이지입니다' '직원 페이지입니다'라는 텍스트만 넣어줘."

복잡한 기능을 만들 때 이런 식으로 빈 껍데기 페이지를 먼저 만들고 나중에 내용을 채우는 전략이 좋다. 한 번에 모든 걸 만들면 문제가 생겼을 때 로그인이 잘못된 건지 페이지 내용이 잘못된 건지 구분이 안 된다. 단계를 나누면 각 단계에서 뭐가 잘못됐는지 명확하게 알 수 있다.

테스트해 보자. 회원가입한 계정으로 로그인했을 때 "직원 페이지입니다"가 나오면 성공이다. 관리자 계정은 Firebase 콘솔에서 직접 만들 수 있다. Firestore에서 해당 사용자 문서의 role 값을 employee에서 admin으로 바꿔준다. admin 계정으로 로그인했을 때 "관리자 페이지입니다"가 나오면 로그인과 역할 분기가 모두 정상 작동하는 것이다.

6. 로그아웃 기능

로그인이 있으면 로그아웃도 있어야 한다. 빠뜨리기 쉬운데 없으면 테스트할 때도 불편하고 나중에 다른 계정으로 전환이 안 된다.

"각 페이지 상단에 로그아웃 버튼을 추가해줘. 누르면 Firebase에서 로그아웃하고 로그인 페이지로 돌아가게 해줘."

간단한 요청이지만 로그인 상태가 유지되는지도 확인해 보자. 로그인한 상태에서 브라우저를 새로고침해도 로그인이 풀리지 않아야 한다. 만약 새로고침하면 로그인 페이지로 돌아간다면 AI에게 "새로고침해도 로그인 상태가 유지되게 해줘. Firebase의 onAuthStateChanged를 사용해서 처리해줘"라고 요청한다.

7. 여기까지의 점검

이번 편에서 만든 건 이렇다. 프로젝트 세팅, 로그인 페이지, 회원가입 페이지, 역할별 페이지 분기, 로그아웃. 기능 자체는 단순해 보이지만 인증이라는 개념이 처음 들어왔다. 메모 앱에서는 누구든 접속하면 모든 메모가 보였는데 이제는 로그인한 사람만 들어올 수 있고 역할에 따라 보이는 화면이 다르다.

다음 편에서는 직원 화면에 출퇴근 버튼과 기록 화면을 만들고 관리자 대시보드에 전체 현황을 보여주는 기능을 구현한다. 그리고 완성된 앱을 Netlify에 배포하는 것까지 진행한다.

코딩할 때 어떤 AI 모델을 써야 할까

bravenewabyss — Sat, 14 Feb 2026 10:02:42 +0900

바이브 코딩을 시작하면 바로 부딪히는 질문이 있다. 클로드를 쓸까 GPT를 쓸까 제미나이를 쓸까. 커서를 열면 모델 선택 드롭다운이 보이는데 거기에 클로드 소넷이니 GPT-4o니 제미나이 프로니 온갖 이름이 쭉 나열되어 있다. 처음에는 뭐가 다른지도 모르겠고 그냥 기본값으로 쓰게 되는데 모델 선택이 바이브 코딩의 결과물에 생각보다 큰 영향을 미친다. 직접 이것저것 써보고 느낀 차이를 정리해 본다.

1. 핵심 차이 요약

일단 2026년 초 기준으로 바이브 코딩에서 가장 많이 쓰이는 모델은 크게 셋이다. 앤트로픽의 클로드(Claude), OpenAI의 GPT, 구글의 제미나이(Gemini).

클로드는 지시를 잘 따른다. 이 파일은 건드리지 마 라고 하면 진짜 안 건드린다. 코드 구조를 깔끔하게 짜는 편이고 긴 대화에서도 맥락을 비교적 잘 유지한다. 특히 React 같은 프론트엔드 코드를 짤 때 결과물이 안정적이다.

GPT는 범용성이 높다. 코딩뿐 아니라 기획이나 문서 작성도 잘하기 때문에 프로젝트 전반에 걸쳐 두루두루 쓰기 좋다. 새로운 아이디어를 브레인스토밍할 때나 코드의 접근 방식을 물어볼 때 유용하다.

제미나이는 구글 생태계와의 연동이 강점이다. 구글 관련 서비스를 다룰 때 유리하고 최근 모델의 성능 향상이 눈에 띈다. 사실 최근에 프로 모델을 쓰면서부터는 거의 모든 논의를 제미나이와 하고 있다. GPT보다 미사여구가 적고 답변이 깔끔한 편.

2. 상황별 추천

나는 상황에 따라 모델을 바꿔 쓴다. 정답은 없지만 자신의 성향에 가장 잘 맞고 원하는 모양이 잘 나오는 모델을 사용하면 된다. 대부분의 프로젝트에 클로드를 쓴다. 프로젝트 구조를 체계적으로 만들어 주고 파일을 나누는 기준도 합리적이다. 처음에 구조가 잘 잡혀야 나중에 기능을 추가할 때 편하기 때문에 이 단계에서의 모델 선택이 중요하다. 기존 코드에 기능을 추가하거나 수정할 때도 클로드가 편하다. 기존 코드를 존중하면서 필요한 부분만 바꾸는 데 강하다. 다른 모델은 가끔 요청하지 않은 부분까지 리팩토링하는 경향이 있었다.

에러가 나서 디버깅할 때는 모델을 바꿔보는 게 좋다. 하나의 모델로 에러를 3번 이상 못 고치면 다른 모델에게 같은 에러를 보여주면 의외로 쉽게 해결될 때가 있다. 모델마다 접근 방식이 다르기 때문이다. 기획이나 아이디어 정리 단계에서는 GPT나 제미나이가 좋다. 어떤 기능을 넣을지 의논하거나 사용자 시나리오를 만들어볼 때 대화가 자연스럽다.

3. 커서에서 모델 바꾸는 법

커서에서 모델을 바꾸는 건 간단하다. 채팅창 하단에 모델 이름이 표시되어 있는데 클릭하면 사용 가능한 모델 목록이 나온다. 여기서 원하는 모델을 선택하면 바로 전환된다. 프로 플랜을 쓰고 있다면 대부분의 주요 모델을 추가 비용 없이 사용할 수 있다. 다만 일부 최신 모델이나 고성능 모델은 별도 요금이 붙을 수 있으니 요금 관련 설정을 확인하는 게 좋다.

4. 모델보다 중요한 것

솔직히 말하면 2026년 시점에서 주요 모델들의 코딩 능력 차이는 예전만큼 크지 않다. 어떤 모델을 쓰느냐보다 어떻게 제대로 요청하느냐가 더 큰 차이를 만든다. 같은 클로드를 써도 그냥 로그인 만들어줘 라고 하는 것과 이메일과 비밀번호 기반 로그인 기능을 만들어줘. Firebase Authentication을 사용하고 로그인 성공 시 대시보드로 리다이렉트해 라고 하는 것은 결과물이 완전히 다르다. 물론 클로드가 점점 똑똑해지고 있어서 웬만하면 기본 기능부터 완벽하게 만들어주긴 하지만.

모델 선택에 너무 스트레스를 받을 필요는 없다. 하나를 주력으로 쓰되 막힐 때 다른 걸 시도해 보는 정도면 충분하다. 직접 써보면서 자기한테 맞는 조합을 찾는 게 최선이다.

고수가 말하는 디버깅 지옥 탈출법(feat. 깃허브)

bravenewabyss — Wed, 11 Feb 2026 08:51:56 +0900

오늘도 커서(Cursor) 깎는 노인처럼 프롬프트 창만 바라보고 있는 여러분을 위해 깃허브를 뒤지다가 발견한 보물 같은 글 하나를 가져왔다. 바이브 코딩으로 앱 30개를 출시하고 실제 돈을 벌고 있는 고수의 노하우다. 이 사람은 콜롬비아 대학에서 ML(머신러닝)을 전공한 찐 개발자 출신인데도 처음 바이브 코딩을 할 때는 우리처럼 디버깅 지옥을 맛봤다고 한다. 코딩이 마법 같다가도 몇시간 동안 에러만 잡고 있는 그 허무함 모두 겪어봤을 것이다. 이 고수가 30번 넘게 앱을 찍어내면서 정립한 AI가 내 코드를 망치지 않게 관리하는 5가지 원칙을 풀어서 정리했다. 이건 진짜 꿀팁이니 꼭 적용해 보자.

1. 직원 교육 매뉴얼을 실시간으로 업데이트하라 (Self-updating rules)

우리가 직원을 채용하면 수습 기간에 일을 가르친다. 그런데 매번 똑같은 실수를 하면 화가 난다. AI도 똑같다. 이 고수는 클로드(Claude)에게 스스로 .cursorrules나 CLAUDE.md 파일을 업데이트하게 시킨다. 어려운 버그를 하나 해결하거나, 우리 프로젝트만의 규칙(예: 변수명은 이렇게 지어라, 디자인은 이걸 써라)이 생길 때마다 AI에게 방금 해결한 내용이랑 규칙을 네가 볼 수 있는 룰 파일에 추가해 놓으라고 시키자. 이렇게 며칠만 지나면 이 파일은 AI가 내 프로젝트를 완벽하게 이해하는 살아있는 직원 매뉴얼이 된다. 맨땅에 헤딩하지 말고 AI를 학습시켜라.

2. 눈을 가리고 일하게 하지 마라 (MCP 활용)

이건 좀 기술적인 이야기지만 핵심은 간단하다. MCP(Model Context Protocol)를 써서 AI에게 '눈'을 달아주라는 거다. 그냥 채팅창에 코드 복사해서 붙여넣지 말고, AI를 내 깃허브(GitHub), 데이터베이스, 파일 시스템이랑 직접 연결해 주라는 뜻이다. AI가 내 코드를 직접 읽고(Read), 문서를 참고하게 하면 뇌피셜로 헛소리하는 환각(Hallucination)이 확 줄어든다. 없는 함수 좀 만들어내지 말라고 화내기 전에 AI가 내 코드를 훤히 들여다볼 수 있게 환경을 세팅해 주자. 초기 세팅 20분이면 삽질 시간 4시간을 아낄 수 있다.

3. 금방 고치겠네 싶을 때가 바로 세이브 타이밍 (Checkpoint)

게임을 하다가 보스 방 앞에 가면 본능적으로 세이브를 한다. 코딩도 똑같다. 이 고수는 이거 간단하네, 금방 고치겠네라는 생각이 드는 순간 멈추고 깃(Git) 커밋(저장)을 하라고 조언한다. 지옥은 항상 그냥 한 줄만 고치면 될 것 같은데? 에서 시작된다. 그 한 줄이 나비효과가 되어 전체 코드를 망가뜨리기 때문이다. 깨끗한 세이브 파일(체크포인트)을 만들어두면 AI가 코드를 걸레짝으로 만들어놔도 언제든 돌아갈 수 있다. 나는 과하다 싶을 정도로 저장을 많이 한다. 되돌려도 채팅으로는 완벽하게 복원되지 않는 경우가 있다.

4. 코딩하기 전에 보고서부터 받아라 (Force explicit reasoning)

사장님 마인드셋의 핵심이다. 직원한테 일 시킬 때 바로 작업부터 하라고 하면 사고 친다. AI에게 코드를 짜라고 하기 전에 반드시 어떻게 짤 건지 계획을 먼저 말해보고 뭐가 문제 될 수 있는지 설명해보라고 명령해라. 커서나 클로드에는 생각 모드(Thinking mode)가 있다. 이걸 켜고 AI가 논리적으로 접근하게 강제해야 한다. 이 과정 없이 바로 코드를 짜게 하면 겉보기에만 멀쩡하고 속은 썩어있는 코드가 나온다.

5. 딴 건 건드리지 마 라고 딱 잘라 말해라 (Scope lock)

이게 진짜 바이브 코딩의 킬러 팁이다. AI는 지나치게 친절하다. 버그 하나 고쳐달라고 하면 편하시라고 제가 파일 12개를 싹 리팩토링 했다고 해맑게 말한다. 명령할 때 항상 범위를 잠가라(Lock). 이 파일의 이 함수만 수정해. 다른 건 절대 건드리지 말고 필요하면 나한테 먼저 물어봐. 이렇게 정확한 명령어를 줘야한다. 범위를 좁게 잡을수록 결과는 예측 가능해지고 버그는 줄어든다.

이 깃허브 글의 핵심은 결국 하나로 통한다. AI를 믿지 말고 관리하라는 것.

매뉴얼(룰 파일)을 만들고,
작업 환경(MCP)을 연결해 주고,
중간 보고(계획 설명)를 받고,
권한(작업 범위)을 제한해라.

앱 30개를 만든 고수의 비결은 코딩 실력이 아니라 AI 관리 능력이다. 우리도 오늘부터 무지성으로 이거 해줘 라고 하지 말고 깐깐한 사장님이 되어보자. 그래야 원하는 결과를 얻어낼 수 있다.

4. 첫 번째 앱 만들기 - 메모 앱

bravenewabyss — Tue, 10 Feb 2026 11:00:28 +0900

Firebase와 Netlify 설정까지 끝냈다면 이제 진짜 앱을 만들 차례다. 환경은 다 깔았는데 정작 뭘 만들지 고민하는 사람이 많을 텐데 처음에는 욕심을 버리고 아주 단순한 것부터 시작하는 게 좋다. 그래서 오늘은 메모 앱을 만든다. 메모를 쓰고 저장하고 삭제하는 것. 이 세 가지면 끝이다.

왜 하필 메모 앱이냐면 이게 가장 기본적인 CRUD이기 때문이다. CRUD는 Create(만들기), Read(읽기), Update(수정하기), Delete(삭제하기)의 약자로 세상 거의 모든 앱이 이 네 가지 동작의 조합이다. 회사 관리 시스템도 쇼핑몰도 SNS도 결국 데이터를 만들고 보여주고 고치고 지우는 것이다. 메모 앱 하나를 제대로 만들면 이 구조가 손에 익고 다음 프로젝트가 훨씬 수월해진다.

1. 커서에게 첫 요청하기

커서를 열고 이전에 만들어 둔 프로젝트 폴더를 연다. 3편에서 Firebase와 Netlify를 연결해 둔 그 폴더다. 채팅창에 다음과 같이 입력한다.

간단한 메모 앱을 만들어줘. React + Vite 기반이고 Firebase Firestore에 데이터를 저장해. 기능은 이거야.

메모를 작성해서 저장할 수 있다
저장된 메모 목록이 보인다
메모를 삭제할 수 있다
디자인은 깔끔하고 심플하게 Tailwind CSS를 사용해줘

여기서 중요한 건 한 번에 너무 많은 걸 요청하지 않는 것이다. 로그인 기능이나 카테고리 분류 같은 건 나중에 추가하면 된다. 처음부터 욕심을 부리면 AI가 만드는 코드가 복잡해지고 문제가 생겼을 때 어디서 잘못된 건지 찾기 어려워진다.

AI가 요청을 받으면 필요한 파일들을 쭉 만들어 줄 것이다. 보통 이런 구조가 나온다.

2. 파일의 역할

바이브 코딩의 핵심은 코드를 직접 짜지 않는 것이지만 AI가 만든 파일들이 각각 무슨 역할인지 정도는 알아두면 좋다. 코드를 읽을 줄 몰라도 된다. 파일의 역할만 파악하면 된다.

App.jsx는 앱의 본체다. 모든 화면이 여기서 시작된다. 레스토랑으로 치면 메인 홀이다. components 폴더 안에는 화면의 부품들이 들어간다. 메모 입력 폼이 하나의 부품이고 메모 목록이 또 하나의 부품이다. 레스토랑의 주방, 카운터, 테이블이 각각 부품인 셈이다.

firebase.js 같은 파일은 Firebase 연결 설정이 담겨 있다. 3편에서 설정한 API 키와 프로젝트 정보가 여기에 들어간다.

AI가 파일을 만들고 나면 터미널에서 개발 서버를 실행하라고 할 것이다. 보통 npm run dev라는 명령어인데 AI가 알려주는 대로 따라하면 브라우저에 내 앱이 뜬다.

3. 처음 보는 에러를 만났을 때

높은 확률로 한 번에 완벽하게 돌아가지 않는다. 브라우저에 빈 화면이 뜨거나 에러 메시지가 나올 수 있다. 당황하지 말자. 이게 정상이다.

에러가 나면 브라우저의 빨간 에러 메시지를 그대로 복사해서 커서 채팅창에 붙여넣으면 된다. 이런 에러가 나는데 고쳐줘 라고 하면 AI가 원인을 분석하고 수정해 준다.

[캡쳐: 브라우저 콘솔에 빨간색 에러 메시지가 표시된 화면. 또는 화면에 에러 오버레이가 뜬 모습]

자주 나오는 에러 패턴이 있다. Firebase 설정이 잘못된 경우에는 Firebase: No Firebase App 같은 메시지가 뜬다. 이건 3편에서 만든 .env 파일의 값을 확인하면 대부분 해결된다. 모듈을 못 찾겠다는 에러가 나면 AI가 알아서 npm install 명령어를 실행해 준다. 핵심은 에러 메시지를 무서워하지 않는 것이다. 에러 메시지는 문제 해결의 단서다. 그걸 AI에게 전달하면 알아서 해결해 준다.

4. 메모 저장이 되는지 확인하기

앱이 정상적으로 뜨면 메모를 하나 작성해서 저장 버튼을 눌러보자. 화면에 메모가 추가되면 일단 프론트엔드는 성공이다. 하지만 진짜 확인해야 할 건 Firebase에 데이터가 저장됐는지다.

Firebase 콘솔에 접속해서 Firestore Database 메뉴를 열어보자. 메모 앱에서 저장한 데이터가 여기에 나타나면 성공이다. 보통 memos라는 컬렉션 안에 문서들이 하나씩 생겨 있을 것이다.

데이터가 안 보이면 Firebase 보안 규칙을 확인해야 한다. Firestore의 Rules 탭에서 읽기와 쓰기가 허용되어 있는지 보자. 테스트 단계에서는 AI에게 Firestore 보안 규칙을 테스트 모드로 설정해달라고 하면 된다. 다만 나중에 실제 서비스로 배포할 때는 반드시 보안 규칙을 강화해야 한다는 점을 기억하자.

5. 삭제 기능 테스트하기

메모 목록에서 삭제 버튼을 눌러본다. 화면에서 메모가 사라지고 Firebase 콘솔에서도 해당 문서가 삭제되면 완벽하다. 여기서 한 가지 짚고 넘어갈 게 있다. 삭제 버튼을 눌렀을 때 확인 창 없이 바로 삭제되면 실수로 지울 수 있다. 이런 세심한 부분은 AI가 알아서 넣어주지 않는 경우가 많다. 삭제 버튼을 누르면 정말 확인 창을 띄워달라고 추가 요청하자. 이런 디테일을 챙기는 습관이 바이브 코딩의 품질을 올린다.

6. 수정 기능 추가하기

메모 앱에서 처음에는 만들기와 삭제만 요청했지만 써보면 수정 기능이 없으면 불편하다는 걸 바로 느끼게 된다. 메모에 오타가 있으면 지우고 다시 써야 하니까. 커서에 메모 목록에서 각 메모를 클릭하면 수정할 수 있게 해달라고 요청하자. 수정 완료 후 저장 버튼을 누르면 Firebase에도 업데이트되게 해달라고 해서 한번에 일을 처리하는 게 토큰도 아끼고 좋다.

이제 AI가 기존 코드에 수정 기능을 추가해 줄 것이다. 이때 기존에 잘 되던 기능이 깨지는지 꼭 확인하자. 새 기능을 추가한 후에는 저장과 삭제가 여전히 정상 작동하는지 한 번 더 테스트한다. 이걸 개발 용어로 회귀 테스트라고 하는데 어렵게 생각할 것 없이 기존 기능 다시 눌러보는 것이다.

7. Netlify에 배포하기

로컬에서 잘 돌아가는 걸 확인했으면 세상에 공개할 차례다. 3편에서 Netlify를 연결해 뒀으니 배포는 간단하다. Netlify와 GitHub가 연결되어 있다면 코드를 GitHub에 푸시하면 자동으로 배포된다. 수동으로 하고 싶다면 Netlify 대시보드에서 빌드된 폴더를 드래그앤드롭해도 된다. 아마 배포를 해달라고 하면 AI가 수동배포할지 자동배포할지 물어볼텐데 클로드를 사용하면 자동배포까지 쉽게 연결해주니 웬만하면 자동배포를 사용하자. 직접 올리는 것도 엄청 어렵지는 않으니 설정이 귀찮으면 바로 직접 배포해도 된다.

배포가 완료되면 Netlify가 부여한 URL로 접속해 본다. 핸드폰으로도 열어보자. 내가 만든 앱이 인터넷 어디에서든 접속 가능한 순간이다.

8. 직접 만든 첫 번째 앱

이제 막 바이브 코딩으로 첫 번째 웹 앱을 만들어서 배포했다. 메모 앱이 별것 아닌 것처럼 보일 수 있지만 여기에는 웹 앱의 핵심 구조가 전부 들어가 있다. 화면을 만들고 데이터를 저장하고 읽어와서 보여주고 수정하고 삭제하는 것. 이 흐름을 한 번 경험하면 다음부터는 어떤 앱을 만들든 이 흐름의 확장판이라는 걸 알게 된다.

다음 편에서는 이 경험을 바탕으로 좀 더 실용적인 앱을 만들어 보겠다. 실제로 업무에서 쓸 수 있는 직원 출퇴근 관리 앱이다. 로그인 기능도 들어가고 데이터를 날짜별로 분류하는 것도 들어간다. 메모 앱에서 배운 CRUD가 어떻게 확장되는지 직접 경험하게 될 것이다.

API 키 관리와 환경변수 - 바이브코딩 보안 기초

bravenewabyss — Mon, 9 Feb 2026 10:00:00 +0900

바이브 코딩을 하다 보면 API 키라는 걸 자주 만나게 된다. 요즘 스레드나 x에서도 바이브코딩 보안 관련된 글들이 심심치않게 보이는 관계로 관련글을 작성해본다. API 키는 Firebase 설정할 때도 나오고 Netlify 연결할 때도 나오고 외부 서비스를 붙일 때마다 등장한다. 오늘은 비개발자도 반드시 알아야 하는 API 키 관리법을 정리한다. 지루하게 느껴질 수 있지만 이거 모르면 진짜 사고다.

1. API 키가 뭔데 왜 중요한가

API 키는 내 서비스가 외부 서비스에 접속할 때 쓰는 비밀번호 같은 것이다. Firebase에 데이터를 읽고 쓸 때 내가 이 프로젝트의 주인이라고 증명하는 열쇠다. 이 열쇠가 다른 사람 손에 들어가면 어떻게 될까. 누군가 내 Firebase 프로젝트에 접속해서 데이터를 마음대로 조작할 수 있다. 유료 API를 쓰고 있다면 남이 내 키로 요청을 보내서 요금 폭탄을 맞을 수도 있다. 실제로 GitHub에 AWS 키를 실수로 올렸다가 하루 만에 수백만 원이 결제된 사례가 꽤 있다. 바이브 코딩하는 사람이 주로 쓰는 Firebase도 무료 한도를 넘기면 과금되니 남의 일이 아니다.

2. 환경변수란

환경변수는 코드와 분리해서 민감한 정보를 저장하는 방법이다. 코드 파일에 API 키를 직접 적는 대신 별도의 설정 파일에 적어두고 코드에서는 그 파일을 참조하는 방식이다. 비유하자면 이렇다. 회사 출입증 번호를 명함에 인쇄하는 사람은 없다. 명함은 누구에게나 돌리는 거니까. 출입증 번호는 지갑 속에 따로 보관한다. 환경변수도 마찬가지다. 코드는 누구나 볼 수 있는 명함이고 환경변수 파일은 나만 가지고 있는 지갑이다.

3. .env 파일 만들기

실제로 하는 방법은 아주 간단하다. 프로젝트 폴더 최상단에 .env라는 파일을 만들고 여기에 API 키를 적는다.

VITE_FIREBASE_API_KEY=여기에실제키값

VITE_FIREBASE_AUTH_DOMAIN=내프로젝트.firebaseapp.com

VITE_FIREBASE_PROJECT_ID=내프로젝트아이디

그리고 코드에서는 이 값을 불러와서 쓴다. AI에게 Firebase 설정을 환경변수로 분리해달라고 하면 알아서 .env 파일을 만들고 코드에서 참조하도록 수정해 준다. Vite를 쓰고 있다면 환경변수 이름 앞에 VITE_를 붙여야 한다. 이건 Vite의 규칙이다. React만 쓴다면 REACT_APP_을 붙인다. AI가 알아서 해주긴 하지만 알아두면 좋다.

4. .gitignore에 반드시 추가

.env 파일을 만들었으면 이게 GitHub에 올라가지 않도록 막아야 한다. .gitignore 파일에 .env를 추가하면 된다. 이전 글에서 Git 설정할 때 AI가 .gitignore를 만들어 줬을 텐데 거기에 .env가 포함되어 있는지 확인하자. 만약 빠져 있다면 AI에게 .gitignore에 .env 파일 추가해달라고 하면 한 줄 추가해 준다. 이 한 줄이 보안 사고를 막아준다.

주의할 점이 하나 있다. 이미 .env 파일을 커밋한 적이 있다면 .gitignore에 추가해도 소용없다. Git은 이미 추적 중인 파일은 무시 목록에 넣어도 계속 추적한다. 이 경우에는 AI에게 Git에서 .env 파일 추적을 해제해달라고 요청해야 한다.

5. Netlify에 환경변수 설정하기

로컬에서 .env 파일로 잘 돌아가던 앱을 Netlify에 배포하면 갑자기 안 되는 경우가 있다. .env 파일은 내 컴퓨터에만 있고 Netlify 서버에는 없기 때문이다. 당연한 건데 처음에는 이것 때문에 한참 헤맸다. Netlify에서는 사이트 설정의 환경변수 메뉴에서 같은 값들을 직접 입력해야 한다. Site configuration에서 Environment variables 항목을 찾아서 .env에 적었던 키와 값을 하나씩 추가하면 된다. 이 과정도 AI에게 물어보면 어디를 클릭해야 하는지 순서대로 알려준다.

6. 흔한 실수들

첫째로 API 키를 코드에 하드코딩하는 것이다. AI에게 빠르게 기능을 만들어달라고 하면 가끔 키를 코드에 직접 넣어버린다. 이걸 그대로 GitHub에 올리면 큰일 난다. 코드를 커밋하기 전에 API 키가 하드코딩된 부분이 없는지 한번 훑어보는 습관이 필요하다.

둘째로 .env.example 파일을 안 만드는 것이다. 나중에 다른 컴퓨터에서 작업하거나 팀원이 생겼을 때 어떤 환경변수가 필요한지 알 수가 없다. .env.example이라는 파일을 만들어서 키 이름만 적어두고 값은 비워두면 가이드가 된다. 이 파일은 GitHub에 올려도 된다. 값이 없으니까.

셋째로 Firebase 보안 규칙을 방치하는 것이다. Firebase API 키는 사실 클라이언트에 노출되는 게 정상이다. 대신 Firebase 보안 규칙에서 누가 뭘 읽고 쓸 수 있는지를 제한해야 한다. 테스트할 때 편하라고 모든 읽기쓰기를 허용해 놓고 그대로 배포하면 아무나 내 데이터베이스를 조작할 수 있다.

마무리

보안은 재미없는 주제다. 하지만 한 번 사고가 나면 재미없는 정도가 아니라 머리가 아프다. 바이브 코딩의 장점은 빠르게 만들 수 있다는 것인데 그 속도 때문에 보안을 건너뛰기 쉽다. .env 파일 만들고 .gitignore에 추가하는 데 5분이면 된다. 그 5분이 나중에 몇 시간 혹은 몇십만 원의 비용을 아껴줄 것이다.

MCP 개념 쉽게 이해하기

bravenewabyss — Sun, 8 Feb 2026 12:16:12 +0900

바이브 코딩 관련 글이나 영상을 보다 보면 요즘 MCP라는 단어가 자주 등장한다. 처음에는 그냥 또 하나의 IT 약자겠거니 하고 넘겼는데 커서 업데이트 노트에도 나오고 클로드 관련 뉴스에도 나오고 심지어 트위터에서 개발자들이 이거 안 쓰면 손해라는 말까지 하길래 제대로 알아봤다. 결론부터 말하면 MCP는 바이브 코딩의 다음 단계라고 부를 만한 것이었다.

1. MCP가 뭔데

MCP는 Model Context Protocol의 약자다. 직역하면 모델 맥락 프로토콜인데 이러면 무슨 소리인지 하나도 모르겠으니까 쉽게 풀어보자. 지금까지 AI에게 코딩을 시킬 때 우리가 하는 건 기본적으로 채팅이다. 텍스트로 요청하고 텍스트로 코드를 받는다. 그런데 AI가 내 프로젝트의 파일을 직접 읽거나 외부 서비스에 직접 접근할 수 있다면 어떨까. 예를 들어 AI가 내 피그마 디자인을 직접 보고 코드를 짠다거나 내 GitHub 이슈 목록을 읽고 알아서 버그를 수정한다거나 하는 것이다.

MCP는 바로 이걸 가능하게 해주는 연결 규격이다. AI 모델과 외부 도구 사이에 표준화된 통로를 만들어 주는 프로토콜이다. USB처럼 생각하면 된다. USB가 나오기 전에는 프린터 연결선 따로 마우스 연결선 따로 키보드 연결선 따로였다. USB가 나오면서 하나의 규격으로 뭐든 연결할 수 있게 됐다. MCP는 AI 세계의 USB다.

2. 왜 갑자기 난리인가

앤트로픽이 2024년 말에 MCP를 오픈소스로 공개했다. 클로드를 만든 그 회사다. 원래 클로드 전용이었는데 규격을 공개하면서 다른 AI 모델도 쓸 수 있게 됐다. 그러니까 한 회사가 독점하는 기술이 아니라 누구나 쓸 수 있는 표준이 된 것이다.

이게 왜 중요하냐면 MCP 서버라는 게 속속 만들어지고 있기 때문이다. MCP 서버란 특정 서비스를 AI에게 연결해 주는 일종의 어댑터다. 피그마 MCP 서버가 있으면 AI가 피그마 디자인을 직접 읽을 수 있고 슬랙 MCP 서버가 있으면 AI가 슬랙 메시지를 읽고 쓸 수 있다. 노션, 구글 드라이브, 데이터베이스, 그 외 수많은 서비스들의 MCP 서버가 이미 나와 있고 계속 늘어나고 있다.

3. 바이브 코딩에서 MCP가 주는 변화

MCP 이전의 바이브 코딩은 이렇다. 피그마에서 디자인을 보고 그걸 말로 설명해서 AI에게 전달한다. "상단에 네비게이션 바가 있고 로고는 왼쪽이고 메뉴는 오른쪽에 배치하고 색상은 네이비" 이런 식이다. 당연히 내 설명과 실제 디자인 사이에 간극이 생긴다.

MCP 이후의 바이브 코딩은 다르다. AI가 피그마 파일을 직접 보고 디자인을 코드로 변환한다. 내가 중간에서 통역할 필요가 없어진다. 정확도가 올라가는 건 물론이고 소통에 드는 시간도 확 줄어든다.

또 하나의 예를 들자면 데이터베이스 구조를 바꾸고 싶을 때 MCP 없이는 현재 데이터베이스의 구조를 내가 확인하고 그걸 AI에게 텍스트로 설명한 뒤 수정 요청을 해야 한다. MCP가 있으면 AI가 데이터베이스에 직접 접속해서 현재 구조를 파악하고 내가 원하는 변경사항을 바로 적용할 수 있다.

4. 커서에서 MCP 사용하기

커서는 MCP를 지원한다. 설정 방법은 생각보다 간단한데 커서의 설정에서 MCP 서버를 추가하는 것이다. 커서 설정에 들어가면 MCP라는 항목이 있다. 여기서 사용하고 싶은 MCP 서버를 추가하면 된다. 예를 들어 파일 시스템 MCP 서버를 추가하면 AI가 프로젝트 폴더의 파일 구조를 좀 더 똑똑하게 탐색할 수 있고 브라우저 MCP 서버를 추가하면 AI가 웹 페이지의 내용을 직접 확인할 수 있다.

다만 아직은 설정 과정에서 JSON 파일을 직접 수정해야 하는 경우가 있어서 완전 초보에게는 진입장벽이 있다. 하지만 이것도 AI에게 커서에 MCP 서버 설정 도와줘 라고 하면 방법을 알려준다. 커뮤니티에서 복사해서 붙여넣기만 하면 되는 설정 파일들도 많이 공유되고 있다.

5. 주의할 점

MCP가 강력한 만큼 주의할 점도 있다. 가장 중요한 건 권한 관리다. AI에게 데이터베이스 접근 권한을 줬는데 잘못된 명령으로 데이터를 날려버리면 그건 AI 탓이 아니라 내 탓이다. 읽기 전용으로 설정할 수 있는 건 읽기 전용으로 해두는 게 안전하다.

또한 MCP 서버의 출처도 확인해야 한다. 공식적으로 검증된 서버와 커뮤니티에서 만든 서버가 섞여 있는데 민감한 데이터를 다루는 서비스라면 출처가 확실한 것만 사용하는 게 좋다. 내 API 키나 접근 토큰이 어디로 흘러가는지 모르면 보안 사고로 이어질 수 있다.

6. 어디까지 온 건가

현재 MCP 생태계는 초기 단계지만 성장 속도가 매우 빠르다. 앤트로픽뿐 아니라 마이크로소프트와 구글도 MCP를 지원하기 시작했다. 이 말은 MCP가 일시적 유행이 아니라 AI 도구의 표준이 될 가능성이 높다는 뜻이다.

바이브 코딩을 하는 입장에서 MCP를 당장 쓰지 않아도 괜찮다. 하지만 이런 게 있다는 걸 알아두면 나중에 프로젝트가 복잡해졌을 때 선택지가 넓어진다. AI가 단순히 대화 상대가 아니라 실제로 내 작업 환경에 연결된 어시스턴트가 되는 세상이 오고 있고 MCP는 그 연결을 만드는 핵심 기술이다.