바이브 코딩 실전 2화: 코드를 몰라도 이것만은 알아야 합니다

지난 편에서는 한 가지를 꽤 길게 이야기했습니다.

AI가 앱을 만들어주는 것과 실제 제품을 출시하는 것은 다른 이야기다.

그렇다면 이제 슬슬 앱을 만들어야 할 것 같습니다.

그런데 시작하기 전에 딱 한 번만 기초공사를 하고 가겠습니다.

오늘 다룰 것은 개발 언어도 아니고 어려운 코딩 문법도 아닙니다.

딱 다섯 가지입니다.

화면, 서버, DB, API, Git

개발을 해본 사람에게는 너무 당연한 단어들이지만 비개발자 입장에서는 처음 만나면 은근히 서로 비슷해 보입니다.

서버?

데이터베이스?

API?

다 인터넷 어딘가에서 뭔가 해주는 것 아닌가?

대충 맞습니다. 😅

하지만 바이브 코딩을 제대로 하려면 최소한

"지금 문제가 화면 쪽인지, 서버 쪽인지, 데이터 쪽인지"

정도는 구분할 수 있어야 합니다.

오늘 목표는 바로 그것입니다.

복잡한 기술 용어부터 보면 머리가 먼저 퇴근합니다.

그래서 우리가 만들 MyLog 앱을 카페 하나라고 생각해보겠습니다.

사용자는 카페에 들어옵니다.

메뉴판을 보고 주문합니다.

직원은 주문을 주방으로 전달합니다.

주방에서는 음료를 만들고,

필요한 재료는 창고에서 꺼냅니다.

그리고 주문 기록도 남습니다.

이 구조가 앱과 꽤 비슷합니다.

사용자
↓
화면
↓
API
↓
서버
↓
데이터베이스

여기에 하나 더 있습니다.

개발 과정에서 사고가 났을 때 과거 상태로 돌아가게 해주는 장치.

그게 Git입니다.

오늘은 이 다섯 친구의 얼굴만 정확히 익히면 됩니다.

1. 화면, 사용자가 직접 만나는 곳

첫 번째는 가장 쉽습니다.

화면(UI) 입니다.

앱을 실행했을 때 우리가 직접 보는 모든 것이 여기에 해당합니다.

MyLog라면 이런 것들입니다.

제목 입력창

내용 입력창

저장 버튼

기록 목록

검색 버튼

설정 화면

이렇게 사용자와 직접 만나는 부분을 보통 Frontend, 프론트엔드라고 부릅니다.

모바일 앱에서는 조금 다른 표현도 사용하지만 지금 단계에서는

정도로 이해하면 충분합니다.

바이브 코딩을 처음 해보면 재미있는 점이 있습니다.

AI에게

라고 하면 꽤 그럴듯한 화면을 금방 만들어냅니다.

그래서 착각하기 쉽습니다.

"거의 다 만들었네?"

아직 아닙니다.

예쁜 식당 메뉴판을 만들었다고 식당이 완성된 것은 아니니까요.

메뉴판에

아메리카노 4,000원

이라고 적혀 있어도 실제 주방이 없으면 커피는 나오지 않습니다.

앱도 똑같습니다.

버튼이 있다고 기능이 있는 것이 아닙니다.

버튼을 눌렀을 때 어디로 요청을 보내고 무엇을 처리할 것인지가 필요합니다.

여기서 서버가 등장합니다.

2. 서버, 보이지 않는 곳에서 일하는 직원

두 번째는 Server, 서버입니다.

서버라는 말을 들으면 거대한 컴퓨터실부터 떠올릴 수도 있습니다.

🖥️🖥️🖥️

하지만 개념 자체는 어렵지 않습니다.

서버는 사용자의 요청을 받아 필요한 작업을 수행하고 결과를 돌려주는 프로그램이라고 생각하면 됩니다.

예를 들어 MyLog 앱에서 사용자가 로그인 버튼을 눌렀습니다.

화면에서는 이메일과 비밀번호를 입력합니다.

그렇다고 스마트폰이 혼자

"이 사용자가 진짜 회원인지"

알 수 있는 것은 아닙니다.

서버에 물어봅니다.

사용자

"로그인할래"

↓

앱

"이 이메일과 비밀번호가 맞는지 확인해줘"

↓

서버

"확인해볼게"

↓

결과 반환

서버가 확인한 뒤

로그인 성공

또는

비밀번호가 틀렸습니다.

같은 결과를 보내주는 겁니다.

여기서 중요한 포인트가 하나 있습니다.

모든 앱이 반드시 서버를 가져야 하는 것은 아닙니다.

예를 들어 MyLog의 기록을 내 스마트폰 안에만 저장한다고 해보겠습니다.

로그인도 없고,

다른 스마트폰과 동기화도 없고,

나 혼자 사용합니다.

그렇다면 서버 없이도 만들 수 있습니다.

스마트폰 내부 저장소만 사용하면 됩니다.

하지만 우리가 나중에

회원가입

여러 기기 동기화

사진 업로드

백업

사용자별 데이터 관리

같은 기능을 추가한다면 이야기가 달라집니다.

이때부터 서버 역할이 필요해집니다.

3. DB, 앱의 기억을 담당한다

다음은 Database, 데이터베이스입니다.

줄여서 흔히 DB라고 합니다.

DB의 역할은 아주 간단합니다.

데이터를 기억하는 곳입니다.

MyLog 사용자가 이런 기록을 작성했다고 해보겠습니다.

제목 : 바이브 코딩 시작

내용 : 오늘 처음으로 앱을 만들었다.

작성일 : 2026-08-17

앱을 종료해도 이 내용이 남아 있어야 합니다.

내일 앱을 열었을 때도 보여야 합니다.

일주일 뒤에도 있어야 합니다.

이 정보를 저장하는 곳이 데이터베이스입니다.

처음에는 그렇게 생각해도 좋습니다.

예를 들어 사용자 정보를 저장한다면

사용자번호
이메일
닉네임
가입일

같은 정보가 들어갈 수 있습니다.

기록이라면

기록번호
사용자번호
제목
내용
작성일

같은 형태가 될 수 있습니다.

표처럼 생긴 데이터베이스도 많습니다.

하지만 단순한 엑셀 파일과 다른 점은

수많은 사용자가 동시에 접근하고,

빠르게 검색하고,

데이터 관계를 관리하고,

권한을 제어하고,

프로그램에서 자동으로 읽고 쓸 수 있다는 것입니다.

즉 DB는

앱의 기억창고

라고 생각하면 좋습니다. 🧠

이것도 처음에는 헷갈립니다.

서버와 DB를 이렇게 구분하면 편합니다.

서버는 일을 하는 곳

DB는 기억하는 곳

예를 들어 카페라면

서버는 직원이고,

DB는 주문 장부와 재료 창고에 가깝습니다.

직원이 주문을 받습니다.

그리고 주문 기록을 저장합니다.

필요하면 과거 주문을 찾아봅니다.

앱도 비슷합니다.

앱

"내가 작성한 기록 보여줘"

↓

서버

"사용자가 누군지 확인해볼게"

↓

DB

"이 사용자의 기록은 15개야"

↓

서버

"좋아, 앱에 보내자"

↓

앱 화면에 표시

이렇게 움직입니다.

4. API, 화면과 서버가 대화하는 방법

이제 네 번째입니다.

처음 들으면 가장 개발자 냄새가 많이 나는 단어입니다.

API

Application Programming Interface의 약자입니다.

이름부터 약간 도망가고 싶어집니다.

하지만 개념은 생각보다 단순합니다.

API는

프로그램끼리 요청하고 답하는 약속

입니다.

우리가 식당에 가서 주방까지 직접 들어가

"냉장고 두 번째 칸의 고기를 꺼내서 180도로 구워주세요."

라고 하지 않습니다.

메뉴판을 보고 주문합니다.

"스테이크 하나 주세요."

그러면 주방은 정해진 방식으로 처리합니다.

API도 비슷합니다.

MyLog 앱이 서버에

라고 직접 지시하지 않습니다.

대신

내 기록 목록 줘

라는 약속된 요청을 보냅니다.

예를 들면 개발에서는 이런 형태를 자주 보게 됩니다.

GET /logs

뜻은 대략

입니다.

새 기록을 저장한다면

POST /logs

정도로 표현할 수 있습니다.

지금 이 문법을 외울 필요는 전혀 없습니다.

중요한 것은

이것 하나입니다.

AI에게 코드를 맡기다 보면 이런 말을 만나게 됩니다.

API 호출에 실패했습니다.

또는

401 Unauthorized

혹은

500 Internal Server Error

이때 API 개념을 전혀 모르면 모든 오류가 그냥

🚨 빨간 글씨

입니다.

하지만 구조를 알고 있으면 생각이 달라집니다.

"화면은 정상인데 서버 요청에서 문제가 생긴 건가?"

"로그인 토큰이 잘못됐나?"

"서버 자체에서 오류가 발생했나?"

이렇게 문제 범위를 좁힐 수 있습니다.

바로 이것이 비개발자가 기술 개념을 조금은 알아야 하는 이유입니다.

코드를 직접 고치기 위해서라기보다

AI에게 제대로 질문하기 위해서입니다.

5. Git, AI가 사고쳤을 때 우리를 구해주는 타임머신

마지막은 Git입니다.

개인적으로 바이브 코딩에서 가장 빨리 익혀야 할 개념 중 하나라고 생각합니다.

왜냐하면 AI는 정말 빠르게 코드를 바꿉니다.

그리고 가끔 정말 빠르게 망가뜨립니다. 🤖💥

상황은 보통 이렇게 흘러갑니다.

처음에는 잘 작동했습니다.

AI에게 말합니다.

잘 됩니다.

욕심이 생깁니다.

조금 이상합니다.

그래서 다시 말합니다.

잠시 후 앱이 실행되지 않습니다.

그때 깨닫습니다.

"아까 잘 되던 상태로 돌아가고 싶은데..."

그 역할을 하는 것이 Git입니다.

Git을 쉽게 설명하면

프로젝트의 중간 저장 지점을 계속 남기는 시스템

입니다.

게임을 한다고 생각해보겠습니다.

보스를 만나기 전에 세이브합니다.

⚔️

죽었습니다.

다시 세이브 지점으로 돌아옵니다.

Git도 비슷합니다.

예를 들어 이렇게 저장할 수 있습니다.

회원가입 구현 전

↓

회원가입 구현 완료

↓

로그인 구현 완료

↓

기록 저장 기능 완료

↓

검색 기능 추가 전

그러다 검색 기능을 만들면서 프로젝트가 망가졌다면

검색 기능 추가 전

상태로 돌아갈 수 있습니다.

이 저장 지점을 개발에서는 Commit, 커밋이라고 부릅니다.

전통적인 개발에서는 개발자가 자신이 수정한 코드 범위를 어느 정도 알고 있습니다.

하지만 바이브 코딩에서는

라고 요청했는데 AI가 7개 파일을 동시에 바꿀 수도 있습니다.

우리는 바뀐 내용을 완전히 이해하지 못할 수도 있습니다.

그래서

큰 작업을 하기 전에 커밋

하는 습관이 굉장히 중요합니다.

앞으로 이 연재에서도

잘 되는 상태 확인
↓
Git Commit
↓
AI에게 다음 작업 요청

이라는 흐름을 자주 사용할 겁니다.

Git은 개발자의 전유물이 아닙니다.

오히려 AI에게 많은 코드를 맡기는 사람일수록 더 필요한 안전장치입니다.

6. 다섯 가지를 한 번에 연결해보자

이제 MyLog에서 새로운 기록을 저장한다고 생각해보겠습니다.

사용자는 앱 화면에서

제목 : 오늘의 기록
내용 : 바이브 코딩 공부 시작

을 입력합니다.

저장 버튼을 누릅니다.

그러면 전체 흐름은 대략 다음과 같습니다.

[화면]

사용자가 저장 버튼 클릭

↓

[API]

"새로운 기록을 저장해줘"

↓

[서버]

사용자 확인
데이터 검증

↓

[DB]

기록 저장

↓

[서버]

"저장 성공"

↓

[API]

결과 전달

↓

[화면]

"저장되었습니다."

그리고 우리가 이 기능을 성공적으로 만들었다면

Git Commit

"기록 저장 기능 완료"

를 남깁니다.

이게 오늘 배운 내용의 전부입니다.

생각보다 별것 없죠?

7. 잠깐, 로컬 저장은 어디에 들어갈까?

여기서 조금 눈치 빠른 분은 이런 생각을 할 수 있습니다.

맞습니다.

데이터는 꼭 인터넷 서버의 DB에만 저장하는 것이 아닙니다.

스마트폰 안에도 저장할 수 있습니다.

이걸 보통 로컬 저장이라고 합니다.

예를 들면

스마트폰 안

MyLog 데이터

형태입니다.

장점은 인터넷이 없어도 사용할 수 있다는 것입니다.

반면 스마트폰을 바꾸면 데이터가 자동으로 따라오지 않을 수 있습니다.

클라우드에 저장하면

스마트폰
↓
인터넷
↓
서버
↓
DB

형태가 됩니다.

다른 스마트폰에서도 로그인해서 데이터를 가져올 수 있습니다.

우리 MyLog도 처음에는 단순한 로컬 저장에서 출발한 뒤 나중에 클라우드 구조로 발전시켜볼 예정입니다.

8. 오늘의 삽질 방지 팁 🛠️

바이브 코딩을 할 때 이런 요청은 피하는 것이 좋습니다.

AI 입장에서는 범위가 너무 넓습니다.

대신 오늘 배운 구조를 활용하면 훨씬 좋은 질문이 됩니다.

예를 들어

또는

이렇게 문제 영역을 지정하면 AI도 훨씬 정확하게 움직입니다.

좋은 바이브 코딩은 화려한 프롬프트 문장을 만드는 것이 아니라

문제가 어디에 있는지 조금씩 좁혀주는 것

에 가깝습니다.

9. 비개발자가 오늘 기억해야 할 것은 딱 이것

오늘 다섯 가지 용어를 배웠습니다.

다시 한번 아주 짧게 정리하겠습니다.

Frontend / 화면사용자가 직접 보고 조작하는 곳

Server / 서버요청을 받아 실제 작업을 처리하는 곳

Database / DB사용자의 데이터를 기억하는 곳

API앱과 서버가 서로 대화하는 약속

Git코드의 변경 이력을 기록하고 이전 상태로 돌아가게 해주는 안전장치

이 정도만 알고 있어도 앞으로 AI가

"API를 호출하고 DB에 저장하겠습니다."

라고 말했을 때

👽 외계어

에서

🙂 "아, 앱에서 서버로 보내서 저장한다는 이야기구나."

정도로 바뀝니다.

그 차이가 생각보다 큽니다.

10. 코드를 외우는 것보다 구조를 보는 눈

비개발자가 바이브 코딩을 시작하면서 개발자처럼 모든 것을 공부하려고 하면 시작도 하기 전에 지칠 수 있습니다.

우리의 목표는 프로그래밍 언어 시험에서 100점을 받는 것이 아닙니다.

AI가 만든 결과물을 보고

이 기능은 대략 어떻게 움직이는지

문제가 발생했다면 어느 영역을 확인해야 하는지

AI에게 무엇을 질문해야 하는지

이 정도를 판단할 수 있으면 됩니다.

앞으로 코드가 등장하기 시작하겠지만 코드를 한 줄 한 줄 외우는 방식으로 진행하지 않을 생각입니다.

대신

를 계속 따라가겠습니다.

그렇게 몇 편을 지나고 나면 어느 순간 신기한 일이 생깁니다.

코드를 직접 쓰지는 못해도

AI가 이상한 코드를 만들었다는 것은 조금씩 보이기 시작합니다.

바이브 코딩에서 꽤 중요한 능력입니다.

이제 기초공사는 끝났습니다.

다음에는 실제 개발 도구를 선택해보겠습니다.

AI 코딩 도구가 너무 많습니다.

Cursor, Claude Code, Codex 계열 도구 등 이름만 보면 뭘 골라야 할지 더 혼란스럽습니다.

하지만 이번 연재에서는

"가장 좋은 AI가 무엇인가?"

보다는

"비개발자가 제품을 끝까지 만들려면 어떤 기준으로 도구를 골라야 하는가?"

를 중심으로 살펴보겠습니다.

다음 편은

[바이브 코딩 실전 #03] AI 코딩 에이전트는 무엇을 골라야 할까? | 도구보다 중요한 선택 기준

으로 이어집니다.

오늘까지는 아직 코드를 한 줄도 작성하지 않았습니다.

하지만 걱정하지 마세요.

집을 짓기 전에 콘센트가 뭔지는 알고 들어가는 편이 나중에 벽을 다시 뜯는 것보다 훨씬 싸니까요. 🔌

#바이브코딩 #VibeCoding #비개발자앱개발 #AI코딩 #AI에이전트 #앱개발 #비개발자개발 #프론트엔드 #백엔드 #서버 #데이터베이스 #API #Git #MVP개발 #바이브코딩실전