PEC · VIBE CODING

진짜 바이브 코딩

말로 느낌을 표현하면 코딩이 되는 시대

BOAZ · 2026

02 단순한 바이브 코딩을 넘어서

단순히 바이브 코딩만 가르치지 않습니다

MINDSET

마인드셋

+

SKILLSET

스킬셋

=

RESULT

AI Native Builder

= 진짜 바이브 코딩

03 바이브 코딩의 정의

바이브 = 느낌

짬바 — 짬에서 나오는 바이브

WHO NAMED IT

"vibe coding" 을 처음 이름 붙인 사람

Andrej Karpathy — "느낌에 완전히 몸을 맡기고, 코드가 존재한다는 사실조차 잊는다."

04 느낌을 따라 코딩하기

코드를 직접 치지 않고,
말로 느낌을 표현하면 코딩이 된다

코딩… 많이 된다

05 원래 코딩이란

컴퓨터가 이해할 수 있는
글을 쓰는 일

06 코딩 = 글쓰기

코딩은 글쓰기 — 그래서 언어의 종류가 다양합니다

◀ 기계가 이해하기 쉬움

사람이 이해하기 쉬움 ▶

어셈블리어

C · Java …

Python

Python 조차 문법이 있다 — 문법을 지켜 써야 컴퓨터가 이해합니다

07 코딩 = 말하기

이제 코딩은 말하기

◀ 기계가 이해하기 쉬움

사람이 이해하기 쉬움 ▶

어셈블리어

C · Java …

Python

NEW

English 🗣️

이제 영어로 말하면 코딩이 된다

08 그래서 어떻게 해?

그래서 어떻게 시작해?

EASIEST WAY

제일 쉬운 바이브 코딩

→ 인터넷에서 바로 하기

09 첫 번째 실습

아래 도구 중 택 1 — 동작하는 웹서비스 만들기

Claude

ChatGPT

Gemini

저는 Claude 활용 — 이 프롬프트를 그대로 요청합니다

"여행 MBTI 진단 웹앱을 만들어줘. 사용자에게 몇 가지 질문을 하고 결과에 따라 여행 유형을 알려줘. 모바일에서도 보기 좋게 만들어줘."

10 같은 프롬프트, 다른 결과물

같은 프롬프트라도 결과물은 다를 수 있다

AI = LLM = Large Language Model

WHY DIFFERENT

확률론적으로 다음 단어를 결정

다음에 올 단어를 확률로 고릅니다 → 그래서 같은 프롬프트로 요청해도 매번 다른 결과물이 나올 수 있어요.

11 결과물 리뷰

1차 결과물을 함께 리뷰해 봅시다

[ 결과물 링크 자리 — 발표 중 직접 첨부 ]

잘 만든 점

브랜딩이 있다
디자인 컨셉이 있다
질문 수가 12개로 충분하다

아쉬운 점

질문 내용의 근거가 부족하다
UI 완성도 부족 — 다시하기 버튼 글자가 안 보임
결과에 대한 분석이 없다

12 어떻게 더 잘 만들까?

더 잘 만드는 법 = 맡 · 당 · 쪼

맡 — 맡긴다

프롬프트 한 줄로 완성된 웹서비스 1차 초안

당 — 당연히 실패

충분하지 않았다 — 앞에서 본 아쉬운 점들

쪼 — 쪼갠다

개선하려면 쪼개야 한다 → 디테일한 프롬프트

13 쪼개진(디테일한) 프롬프트

"예쁘게 만들어줘"가 아니라 "무엇이 부족한지"를 명확히 정의

[ 디테일한 개선 프롬프트 자리 — 발표 중 직접 입력 ]

처음 프롬프트

만들고 싶은 것만 말했다

쪼갠다

개선 프롬프트

분석 축 · 질문 수 · 결과 구조 · 데이터 구조까지 쪼개서 전달했다

14 개선된 결과물 확인

쪼갠 프롬프트로 다시 만든 결과물

[ 개선 결과물 링크 자리 — 발표 중 직접 첨부 ]

좋아진 점

결과에 대한 설명 가능성(Explainability)이 생김
관광공사 API 연동을 고려한 데이터 구조
최종 결과가 다음 행동으로 이어짐

아직 아쉬운 점

데모 수준의 추천 — 개인화 데이터 부족(로그인 없음)
실제 데이터가 연결되어 있지 않다

15 쪼개진 프롬프트 — 실제 전문

여행 성향(MBTI 스타일) 진단 웹앱 — 단일 HTML · 모바일 우선

[1] 분석 축 — 4축 × 양극단

· 계획(P) ↔ 즉흥(S) — 미리 설계 vs 그날 기분

· 도시(C) ↔ 자연(N) — 도심 밀도 vs 산·바다·숲

· 휴양(R) ↔ 체험(E) — 쉼 vs 새로운 활동·도전

· 가성비(B) ↔ 프리미엄(L) — 합리적 vs 경험 투자

→ 우세 극 조합 4글자(PCRB·SNEL) · 총 16유형

[2] 질문 — 16문항(축당 4문항 균등)

· "실제 여행 행동" 2지선다 (예: 2주 전 → A 일정표 / B 항공·숙소만)

· 한 문항 = 한 축, 선택지가 그 축 한쪽 극에 점수

· 문항 가중치 → 축별 합계 100 (예: 30/30/25/15)

· 한 문항씩 · 진행률 표시 · 이전 문항 되돌아가기

[3] 결과 구조 — 아래 요소 모두 포함

· 유형 카드: 코드+이름+태그라인+이모지+설명 (boarding pass 메타포)

· 축별 분석: 4축 막대그래프+% + 1~2문장 해석 (Explainability)

· 추천 여행 스타일: 우세 극 4개 맞춤 팁 4개

· 추천 국내 여행지 5곳: [4] 데이터 매칭 점수 순

· 결과 공유: Canvas 요약 이미지 + 텍스트 복사 · 다시 진단

[4] 데이터 구조 — TourAPI 연동 염두 객체 배열

{ name, region, keyword, contentTypeId, contentId:null, traits{place,style,budget}, blurb }

· 지금은 정적 → keyword로 TourAPI 호출해 contentId·사진·주소·좌표 채우도록 필드 분리

· 전국(서울·부산·제주·강원·경기…) 30곳 내외, traits 조합 골고루

[5] 디자인 / UX

· 모바일 우선(≤480px) · 큰 터치 영역 · 가독성 폰트 · 여행·항공 테마

· 접근성: 포커스 · 대비 · prefers-reduced-motion · 결과 텍스트 잘림 없이

16 AI 가 잘하는 것 vs 못하는 것

잘하는 것

만들기

구현은 빠르고 능숙합니다

못하는 것

무엇을 만들지 생각하기

방향과 기획은 AI 의 약점입니다

17 그저 그런 서비스 vs 정말 좋은 서비스

시작도 개선도 AI 와 함께 — 질문하고 답하며 만들 수 있어요

그러나 무엇을 만들지는 AI 가 잘 못합니다

그저 그런 서비스

= AI 만으로 만든 서비스

정말 좋은 서비스

= 나만의 기획으로 만든 서비스

18 이 강의가 알려주는 것

이 강의가 알려주는 것

강의가 알려줍니다

만드는 법

여러분의 몫입니다

기획 자체

한국 관광공사
Open API

사이트 활용법 · 내 서비스에 API 연결하는 법 · API 의 간단한 동작 원리

To be continued —

BOAZ · 진짜 바이브 코딩

진짜 바이브 코딩 — 한국관광공사 여행 MBTI 웹서비스 만들기