URL: https://www.youtube.com/watch?v=GckkaKEQ3vo
채널: Noah Kim
발행일: 2026-10-01
영상 길이: 8분 23초
프로젝트: VibeWise
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
==AI 코딩 도구가 코드를 대신 작성하더라도, 학습자가 설계·범위·자료구조·예외 상황을 직접 결정하게 만들면 바이브 코딩을 학습 과정으로 바꿀 수 있다.==
- AI는 투두 앱이나 단순 애플리케이션을 너무 쉽게 만들어 주어 주니어 개발자의 포트폴리오 기준을 끌어올렸다.
- 결과물을 빠르게 만드는 것과 개발 원리를 배우는 것은 별개의 목표다.
- VibeWise는 코드를 금지하지 않는다. 대신 사용자가 설계와 빌드 체크포인트를 통과해야 구현 단계로 넘어가게 한다.
- 핵심은 AI에게 질문을 던지는 것이 아니라, AI가 질문을 되돌려 사용자가 스스로 결정하도록 만드는 것이다.
이 플러그인은 “AI를 쓰지 말고 직접 코딩하라”는 도구가 아니다. AI가 가장 잘하는 반복 구현은 맡기되, 요구사항 정의·범위 설정·데이터 모델·상태·라우팅·예외 처리와 같은 엔지니어링 판단을 학습자에게 돌려준다.
1. AI 시대에 코딩을 배우는 사람의 진퇴양난
1.1. 생산성과 학습이 서로 다른 방향으로 끌린다
-
AI를 쓰지 않으면 생산성이 낮다
- AI를 활용하면 더 많은 코드를 작성하고 기능을 더 빠르게 구현할 수 있다.
- 실제 개발 현장에서는 결과물의 속도와 완성도가 중요하므로 AI를 외면하기 어렵다.
- 특히 Claude Code 같은 에이전트는 파일 생성, 구조 설계, 구현, 수정까지 한 번에 처리할 수 있다.
- AI가 만들어 준 결과가 눈앞에 나오면 사용자는 자신이 개발을 잘하고 있다고 느끼기 쉽다.
-
AI를 전부 맡기면 학습이 사라진다
- 코드가 생성되는 동안 학습자는 어떤 결정을 했는지, 왜 그 기술을 골랐는지, 어떤 예외를 버렸는지 알지 못할 수 있다.
- 애플리케이션이 완성되어도 내부 구조를 설명하거나 수정하지 못하면 다음 기능을 독립적으로 만들기 어렵다.
- 즉 “코드가 실행된다”와 “개발자가 성장했다”는 같은 사건이 아니다.
- VibeWise는 이 간극을 줄이는 것을 목표로 한다.
1.2. 주니어 개발자에게 요구되는 결과물의 기준이 높아졌다
-
간단한 프로젝트의 차별성이 약해졌다
- 예전에는 투두 앱이나 작은 CRUD 애플리케이션도 학습 결과물로 의미가 있었다.
- 이제는 AI가 그런 프로젝트를 짧은 시간에 만들 수 있다.
- 따라서 사이드 프로젝트의 겉모습만으로 실력을 판별하기 어려워졌고, 주니어에게 기대하는 기준도 높아졌다.
- 교육 과정은 AI의 발전 속도를 따라가지 못해, AI 도움 없이 더 나은 애플리케이션을 설계할 기초를 쌓기 어렵다.
-
학습자의 새 과제
- 코드를 많이 타이핑하는 능력보다 문제를 쪼개고 범위를 제한하는 능력이 중요해졌다.
- 데이터베이스를 왜 선택했는지, 어떤 테이블이 필요한지, 사용자가 처음 무엇을 해야 하는지 설명할 수 있어야 한다.
- AI가 설계안을 제시해도 그것을 검토하고 반박할 수 있어야 한다.
- 이 판단력이 없으면 AI는 생산성을 올리는 도구가 아니라 이해하지 못한 결과물을 쌓는 도구가 된다.
2. VibeWise의 설계 철학
2.1. 사용자가 직접 코드를 쓰게 하는 플러그인은 아니다
-
목표는 타이핑을 강제하는 것이 아니다
- VibeWise는 사용자가 모든 코드를 한 줄씩 작성하도록 막지 않는다.
- 숙련된 개발자에게 반복적인 구현을 AI가 맡는 것은 매우 유용하다.
- 대신 사용자가 애플리케이션의 목적과 설계를 직접 정하고, AI가 그 결정의 빈틈을 질문하도록 만든다.
- “AI를 쓰지 않는 순수성”보다 “AI를 사용해도 학습이 남는 구조”를 선택한다.
-
AI의 기본 동작을 뒤집는다
- 일반적인 AI 코딩 흐름은 사용자가 대략적인 요구를 말하면 AI가 가정을 채우고 기술 스택을 선택한 뒤 구현까지 진행하는 방식이다.
- 사용자는 추천 선택지를 보고 “네, 네, 네”라고 클릭하다가 어느 순간 완성된 애플리케이션을 받는다.
- VibeWise는 사용자가 능동적으로 결정하지 않으면 다음 단계로 진행되지 않도록 한다.
- 객관식으로 A·B·C 중 하나를 골라 주는 대신, 자유 형식으로 자신의 이유와 설계를 적게 한다.
2.2. AI가 대신 만들지 않고 질문을 되돌려준다
-
데이터베이스 질문
- 일반적인 Claude는 필요한 데이터베이스 테이블을 알아서 만들 수 있다.
- VibeWise는 먼저 “어떤 테이블이 필요한가?”라고 묻는다.
- 사용자가 어떤 데이터베이스를 골라야 할지 모르겠다고 하면, AI가 정답을 대신 고르지 않고 “당신은 어떤 것을 선택하는 게 좋다고 생각하는가?”라고 다시 묻는다.
- 과거에 개발자가 당연히 거쳐야 했던 결정 과정을 학습자가 반복해서 경험하게 하는 구조다.
-
범위와 사용자 경험 질문
- 사용자가 URL을 클릭해 애플리케이션을 처음 봤을 때 무엇을 하길 바라는지 묻는다.
- 예시 답변은 “앱을 열고, 로그인하고, 노트를 만들고, 편집을 시작한다”처럼 자유 형식으로 작성한다.
- AI가 체크리스트를 추천해 주는 것이 아니라 버전 1의 범위를 사용자가 스스로 정의하게 한다.
- 그 답변은 이후 구현의 기준이 되며, 무한히 기능을 추가하는 일을 막는 경계가 된다.
3. 데모: Claude로 Notion 복제본 만들기
3.1. 일반 Claude의 흐름
-
입력은 한 문장뿐이다
- 새 폴더를 만들고 Claude Code를 초기화한다.
- “Notion 복제본을 만들고 싶다”고 입력한다.
- 제공한 정보는 학습용이라는 목적, Notion의 어떤 부분을 구현할지, 구현 기술 스택 정도다.
-
AI가 대부분의 결정을 선점한다
- 블록 에디터와 페이지 중 어떤 부분을 먼저 구현할지 AI가 제안한다.
- 기술 스택 목록을 보여 주고 추천 항목을 선택하게 한다.
- 사용자가 “네”를 반복하면 AI는 단일 사용자, 로그인 없음, 백엔드 없음 같은 가정을 채운다.
- 페이지 트리, 무제한 중첩, 블록 유형, 검색, 저장, 데이터 모델, 상태, 라우팅, 에디터, 스타일링이 빠르게 계획된다.
-
11단계 실행 계획의 문제
- AI는 프로젝트 스캐폴딩부터 작은 기능 구현까지 포함한 11단계 계획을 출력한다.
- 주니어 개발자나 대학생이 수천 줄에 달하는 계획과 코드를 훑고 “이 모든 선택을 내가 스스로 생각했다”고 말하기는 어렵다.
- 이들은 구축 과정에 참여하지 않았고, 설계 결정을 직접 만들지 않았다.
- 결과는 숙련된 엔지니어에게는 사소한 기능을 빠르게 구현하는 데 유용하지만, 학습자에게는 이해하지 못한 완성품이 될 수 있다.
3.2. VibeWise가 같은 요청을 바꾸는 방식
-
첫 번째 빌드 체크포인트: 목적과 범위
- 애플리케이션의 목적을 묻고, Notion의 어느 부분을 복제할지 묻는다.
- 버전 1에서 필요한 기능을 사용자의 말로 정의하게 한다.
- 앱을 열었을 때 첫 화면에서 사용자가 해야 할 행동을 직접 적게 한다.
- 이 답변을 기록해, 이후 AI가 임의로 범위를 넓히지 못하게 한다.
-
두 번째 빌드 체크포인트: 동작과 지속성
- 노트를 만들고 앱을 닫은 뒤 다른 기기에서 다시 열어도 내용이 남아 있어야 하는지 묻는다.
- “편집”이 정확히 무엇을 의미하는지 묻는다. 텍스트만 수정하는지, 블록의 순서를 바꾸는지, 여러 블록 유형을 지원하는지 결정해야 한다.
- 제목, 본문, 글머리 기호, 체크박스 등 실제로 지원할 블록을 사용자가 명시한다.
- 사용자가 말한 “폴더”에 다른 폴더를 넣을 수 있는지, 노트만 넣을 수 있는지, 폴더 밖 노트를 허용하는지, 삭제 후 어떻게 되는지도 답하게 한다.
-
설계 체크포인트
- 로그인·노트 작성·편집이라는 기능 이름만으로는 구현 사양이 완성되지 않는다.
- 사용자가 앱을 다시 열었을 때 데이터가 어디에서 복원되는지, 어떤 상태가 저장되는지, 라우팅이 어떻게 동작하는지 정한다.
- 데이터 모델과 저장 계층, 상태 관리, 에디터의 동작을 직접 설명하게 한다.
- 사소해 보이는 결정들이 실제 애플리케이션의 품질과 예외 상황을 좌우한다.
-
구현 체크포인트
- 빌드와 설계 과정이 끝나기 전에는 실제 코드 작성 단계로 넘어가지 않는다.
- 사용자가 전체 설계를 훑고 각 요소가 어떻게 맞물리는지 이해한 뒤 구현을 승인한다.
- 구현 단계에서는 AI가 코드를 생성할 수 있지만, 생성된 코드의 존재 이유와 연결 관계는 사용자가 설명할 수 있어야 한다.
- 결과적으로 VibeWise는 “계획 → 설계 → 구현”을 다시 분리해, 사용자가 계획과 설계를 건너뛰지 못하게 한다.
4. 왜 이런 사소한 질문이 학습에 중요한가
4.1. 엔지니어링은 작은 결정의 연속이다
-
사소한 예외가 실제 제품을 만든다
- 폴더 안에 폴더를 허용할지, 폴더 밖 노트를 허용할지, 삭제된 노트를 복구할지 같은 결정은 겉보기에는 멍청하고 귀찮아 보인다.
- 그러나 실제 제품에서는 사용자가 반드시 이 경계에 부딪힌다.
- 숙련된 시니어 개발자는 이런 예외를 빠르게 떠올리지만, 경험이 적은 학습자는 AI가 알아서 정해 주면 존재 자체를 알지 못한다.
- VibeWise는 이 결정들을 사용자 앞으로 가져와 문제를 미리 상상하도록 한다.
-
소프트웨어 엔지니어링의 재미
- 사용자의 행동을 예측하고, 백엔드 동작을 정의하고, 테이블과 데이터베이스를 설계하는 일이 엔지니어링의 핵심이다.
- 개발의 재미는 코드를 입력하는 속도보다 만들면서 만나는 수많은 작은 문제를 해결하는 데 있다.
- 이 과정이 재미없다면 개발보다 다른 분야가 더 맞을 수도 있다.
- AI가 이 모든 사소한 결정을 추상화해 버리면 결과물은 빨라져도 학습 과정은 사라진다.
4.2. 숙련자와 학습자에게 다른 가치가 있다
-
숙련자에게는 자동화가 레버리지다
- 이미 시스템 설계와 예외 처리 경험이 있는 개발자는 AI가 만든 초안을 빠르게 검토할 수 있다.
- 사소한 기능을 직접 구현하는 시간을 줄이고 더 높은 수준의 문제에 집중할 수 있다.
- VibeWise가 막으려는 것은 이 생산성 자체가 아니라, 학습자가 그 수준의 판단을 갖기 전에 결과물을 얻는 상황이다.
-
학습자에게는 선택의 반복이 필요하다
- 처음부터 완벽한 설계를 맞히는 것이 목표가 아니다.
- 어떤 선택을 했는지, 다른 선택지는 무엇이었는지, 그 선택의 비용은 무엇인지 말해 보는 것이 목표다.
- AI가 정답을 주지 않고 질문을 계속하면 사용자는 자신의 가정을 드러내게 된다.
- 이 기록이 쌓여야 나중에 AI의 설계안을 비판하고 수정할 수 있다.
5. 플러그인의 운영 구조와 사용법
5.1. 세 단계 체크포인트
- 빌드 체크포인트: 애플리케이션의 목적, 사용자 흐름, 버전 1 범위를 정한다.
- 설계 체크포인트: 데이터 모델, 저장 방식, 상태, 라우팅, 블록 유형, 폴더 규칙과 예외를 정한다.
- 구현 단계: 앞의 두 체크포인트를 통과한 뒤 Claude Code가 실제 코드를 작성한다.
이 구조는 일반적인 개발 흐름을 강제한다. 최종 설계를 구성하는 요소를 먼저 생각하고, 전체를 검토한 뒤, 모든 것이 맞물리는 방식을 이해하고, 예외를 추가로 고민한 뒤 코드를 작성한다.
5.2. 사용자의 행동 흐름
- Claude Code에 프로젝트 목표를 입력한다.
- VibeWise가 목적·범위·사용자 경험에 대한 질문을 던진다.
- 사용자가 자유 형식으로 답한다. 추천 목록을 그대로 클릭하는 방식이 아니다.
- VibeWise가 저장된 답변을 바탕으로 다음 설계 질문을 만든다.
- 데이터 지속성, 블록, 폴더, 삭제, 편집, 상태와 라우팅을 정의한다.
- 사용자가 설계를 검토하고 구현을 승인한다.
- Claude Code가 코드를 작성한다.
- 사용자는 완성된 코드뿐 아니라 그 코드가 나온 결정 과정을 설명할 수 있어야 한다.
6. 기대 효과와 한계
6.1. 기대 효과
- AI가 만든 코드의 구조를 읽고 질문할 기회가 늘어난다.
- 기능 이름을 요구사항과 동작 사양으로 구체화하는 연습이 된다.
- 데이터베이스와 상태 관리 같은 보이지 않는 설계 계층을 의식하게 된다.
- 작은 예외와 경계 조건을 먼저 생각하게 되어, “작동하는 데모”와 “제품”의 차이를 배운다.
- AI의 추천을 그대로 채택하지 않고 자신의 선택을 남기게 된다.
6.2. 한계와 주의점
- 질문에 답했다고 해서 답변이 좋은 설계가 되는 것은 아니다. 여전히 사용자는 기술 개념을 공부하고 피드백을 받아야 한다.
- 체크포인트가 너무 길거나 질문이 반복되면 학습자가 형식적으로 답하고 승인 버튼만 누를 위험이 있다.
- 숙련된 개발자에게는 불필요한 마찰이 될 수 있으므로, 플러그인의 강제 수준을 조절할 필요가 있다.
- AI가 작성한 구현을 사용자가 검토하지 않으면 학습 효과는 줄어든다. 체크포인트는 검토를 대신하지 않는다.
- 핵심은 플러그인을 설치하는 것보다, AI에게 맡긴 결정과 자신이 책임지는 결정을 구분하는 습관이다.
주요 발언 모음
“AI를 쓰지 않으면 생산성이 떨어지고, AI에 전부 맡기면 학습이 사라진다.”
“코드를 직접 한 줄씩 작성할 필요는 없지만, 구축하고 설계하며 실제로 고민하는 과정은 거쳐야 한다.”
“개발의 진짜 재미는 만들면서 마주치는 수많은 사소한 문제를 직접 해결하는 데 있다.”
“VibeWise는 바이브 코딩이지만, 사용자가 직접 참여한다는 점이 다르다.”
결론 및 실행 포인트
- AI 코딩 세션을 시작할 때 “무엇을 만들까?”만 묻지 말고 “누가, 어떤 순서로, 어떤 상태에서 사용할까?”를 먼저 적는다.
- 첫 버전에서 지원하지 않을 기능을 명시한다. 범위 밖 항목을 정하는 것도 설계다.
- 데이터 모델·저장 방식·상태·라우팅·예외 상황을 AI가 알아서 결정하게 두지 않는다.
- AI가 제안한 선택지에 “추천이니까”라고 답하지 말고, 자신의 선택과 이유를 자유 형식으로 기록한다.
- 구현 전에 앱을 닫았다가 다시 열었을 때 무엇이 남아야 하는지 정의한다.
- 폴더·노트·삭제·복구·블록 유형처럼 사소한 정책을 제품 요구사항으로 바꿔 적는다.
- 설계가 끝난 뒤 AI에게 구현을 맡기고, 생성된 코드와 설계 문서를 서로 대조한다.
- 숙련자라면 VibeWise를 항상 켜기보다, 새로운 도메인이나 학습 목적의 프로젝트에 선택적으로 적용한다.
- 학습자는 완성된 결과물보다 자신이 설명할 수 있는 결정의 수를 진척도로 삼는다.
- VibeWise 저장소의 README와 이슈를 확인하고, 실제 사용 중 발견한 마찰을 피드백으로 남긴다.
핵심 요약 (20줄)
- AI 코딩 도구는 주니어의 결과물 생산 속도를 크게 높였다.
- 그 결과 투두 앱과 단순 CRUD 프로젝트만으로는 실력을 구분하기 어려워졌다.
- 코드를 빠르게 만드는 것과 개발 원리를 배우는 것은 별개의 목표다.
- Noah Kim은 이 문제를 해결하기 위해 Claude Code 플러그인 VibeWise를 만들었다.
- VibeWise는 코드를 직접 타이핑하라고 강제하지 않는다.
- 대신 사용자가 목적과 범위를 직접 정의하도록 질문한다.
- 데이터베이스 테이블과 기술 스택도 AI가 바로 선택하지 못하게 한다.
- 사용자는 추천 선택지를 클릭하는 대신 자신의 선택과 이유를 적는다.
- 데모에서는 “Notion 복제본을 학습용으로 만들고 싶다”는 한 문장에서 시작한다.
- 일반 Claude는 가정을 채우고 11단계 실행 계획을 제시한다.
- 학습자는 수천 줄의 설계와 코드를 보고도 그것을 스스로 이해했다고 말하기 어렵다.
- VibeWise는 빌드 체크포인트에서 사용자의 첫 화면과 버전 1 범위를 묻는다.
- 다음으로 로그인, 저장, 편집, 블록, 폴더와 삭제 정책을 구체화한다.
- 다른 기기에서 데이터가 남아야 하는지처럼 지속성도 직접 결정하게 한다.
- 개발의 본질은 이런 사소한 예외와 동작을 해결하는 과정에 있다.
- 숙련자에게 AI 자동화는 생산성 레버리지지만 학습자에게는 판단력 상실이 될 수 있다.
- VibeWise는 빌드·설계·구현의 세 체크포인트를 분리한다.
- 구현은 사용자가 설계를 검토하고 승인한 뒤에만 진행된다.
- 이 방식은 바이브 코딩을 없애지 않고 학습 가능한 바이브 코딩으로 바꾼다.
- AI 시대의 개발 학습은 타이핑량보다 설명 가능한 결정과 설계 경험을 쌓는 일이다.
