https://www.youtube.com/watch?v=tuH1ZTl9s9Q
description: |
1. 이건 꼭 알아야 한다^1
[? 질문] ‘바이브 코딩(느좋 코딩)’이란 정확히 무엇이며, 왜 사람들이 멋있다고 느끼는가^1
[= 답] 바이브 코딩은 AI에게 코딩의 대부분(사실상 전부)을 맡겨, 사람은 자연어로 지시만 하면서 소프트웨어를 만드는 방식이고, 코딩을 몰라도 “한글로 명령만 해서” 결과물을 빠르게 만들 수 있어 멋있어 보이며 실제 시도하는 사람과 관련 플랫폼도 늘었다.^1
[? 질문] 바이브 코딩은 누구에게 ‘좋고’, 누구에게는 ‘자제’가 필요한가^2
[= 답] 코딩 경험이 없는 사람/코딩 학습자/코딩 숙련자로 나눠 볼 때, 코딩 학습 단계에서는 AI에게 코드 완성까지 맡기는 것을 자제하고 검색 도구 수준으로 제한하는 게 좋다. 반면 코딩을 전혀 안 해 본 사람에게는 바이브 코딩을 바로 추천하며 “최고의 코딩 맛보기 도구”가 될 수 있다.^2
[? 질문] 바이브 코딩을 쓸 때의 현실적인 한계와 안전장치는 무엇인가^3
[= 답] AI에게 전부 맡기면 실패하기 쉽고 항상 검증이 필요하며, AI는 “거짓말”, “ADHD”, “치매” 같은 특성(일관성 부족, 맥락 놓침, 환각, 장기 작업 취약)을 보일 수 있다. 특히 코드가 길어질수록 멍청해지는 문제가 크고, 실무에서 그대로 쓰기 어렵다는 의견이 많다. 따라서 도구 선택(에이전트/추론 모델), 계획 수립 후 실행, 보안 검토, 개인정보 최소화 같은 가드레일이 필요하다.^3
2. 큰 그림^1
이 콘텐츠는 최근 유행한 “바이브 코딩”을 정의하고, 실제로 어떤 사람들에게 어떤 방식으로 도움이 되는지, 그리고 어디까지 믿어도 되는지(한계와 검증 필요성)를 현실적으로 설명한다.^1 동시에 초보/학습자/숙련자 관점에서 AI 코딩의 활용 강도를 달리해야 한다는 기준을 제시하고, 도구 선택과 진행 요령, 보안 주의점까지 다룬다.^2
- 바이브 코딩의 정체는 ‘좋은 느낌(vibe)’으로 AI에게 코딩을 맡기는 것이며, 한국식으로 번역하면 ‘느좋 코딩’이다.^1
- 대상별 권장 사용법이 다르다: 코딩 학습자는 과의존을 줄이고, 코딩을 안 해 본 사람은 맛보기로 적극 활용해볼 만하다.^2
- 한계와 가드레일이 핵심이다: AI는 길어지면 성능이 떨어지고 검증이 필요하며, 보안·개인정보·배포 난이도 같은 현실 이슈를 고려해야 한다.^3
3. 하나씩 살펴보기^1
3.1 ‘바이브 코딩’이 뜬 배경과 용어 정리: vibe = 좋은 느낌, 그래서 ‘느좋 코딩’^1
화자는 “최근에 바이브 코딩이 뜬 적이” 있다고 말하며 유행의 출발점을 깐다.^1 이어서 처음에는 ‘바이브’가 바이브레이션(vibration) 같은 것의 약자라고 생각했지만, 실제로는 “좋은 느낌”이라는 뜻이었다고 정정한다.^1
여기서 한국 인터넷 문화의 표현을 끌어와, 요즘 “느좋(느낌 좋다)”라고 부르니 바이브 코딩을 번역하면 “느좋 코딩이 되겠다”고 연결한다.^1 즉, 용어 자체를 어렵게 정의하기보다 “그럴듯하고 멋져 보이는 느낌”을 풍기는 단어로서의 뉘앙스를 먼저 전달한다.^1
3.2 바이브 코딩의 구체적 의미: “그냥 AI에게 모든 걸 맡기는 코딩”^1
화자는 바이브 코딩을 아주 직설적으로 정의한다.^1
중요한 포인트는, 바이브 코딩을 하기 위한 별도의 엄격한 방법론/절차/프레임워크가 있는 게 아니라는 점이다.^1
즉 바이브 코딩은 ‘테크닉’이라기보다 태도/사용 방식의 라벨에 가깝고, AI에게 작업을 위임하는 정도가 극단적으로 높다는 점이 핵심이다.^1
3.3 사람들이 바이브 코딩을 멋있다고 느끼는 이유: ‘코딩을 전혀 몰라도 한글로 명령’하면 결과물이 나온다^1
화자는 바이브 코딩으로 “이런 거 만들었다, 저런 거 만들었다” 자랑하는 글을 보면 “좀 멋있어 보이지 않습니까?”라고 말하며 대중의 심리를 짚는다.^1
그 멋의 핵심은 다음과 같이 묘사된다.^1
- 코딩을 전혀 몰라도
- “그냥 한글로만 명령을 하면”
- “멋있는 소프트웨어를 이렇게 만들 수” 있다는 점^1
이 매력 때문에 바이브 코딩을 실제로 시도하는 사람도 “많아지는 것 같다”고 하고, 더 나아가 “바이브 코딩이 가능한 플랫폼”이라고 홍보하는 사이트들도 많아졌다고 말한다.^1
즉, 개인 단의 유행을 넘어 제품/플랫폼 마케팅 포인트로도 확장되는 흐름을 짚는다.^1
3.4 화자의 1차 평가: ‘순살 코딩’처럼 보여도 나는 “매우 좋다” — 단, 조건이 있다^1
화자는 바이브 코딩을 옆에서 보면, AI가 “본인 느낌대로 코딩하면서 철근을 몇 개 빼먹으면서 이렇게 순살 코딩을 하는 현장” 같을 수 있다고 비유한다.^1
여기서 “철근을 빼먹는”은 겉모습은 그럴듯하지만 구조적으로 중요한 것(안정성/정합성/예외처리/보안/테스트 등)을 누락하는 상황을 풍자한다.^1
그래서 이런 모습을 보면 “코딩 그렇게 하면 안 되는데 에잉 쯧쯧” 같은 대사가 저절로 나올 수 있다고 인정한다.^1
하지만 결론은 의외로 긍정이다.^1
3.5 ‘세 가지 종류의 사람’ 프레임: 코딩 비경험자 / 코딩 학습자 / 코딩 숙련자^2
화자는 사람을 세 부류로 단순화해 구분한다.^2
- 코딩 안 해 본 사람
- 코딩 학습자
- 코딩 숙련자
그리고 각 그룹에 대해 바이브 코딩(=AI 코딩 위임)을 어떻게 대해야 하는지 다른 처방을 내린다.^2
3.5.1 코딩 숙련자·비경험자: “다 컸으니까… 마음대로”^2
화자는 “일단 이 분들은 다 컸으니까 그냥 ‘느좋’ 코딩하든 말든 자기 마음대로 하시면” 된다고 말한다.^2
이 말은 ‘금지/허용’의 도덕적 판단이 아니라, 책임을 질 수 있는 능력/필요성이 다르다는 뉘앙스다.^2
다만, 곧바로 다음 그룹(학습자)에 대해서는 다른 기준을 제시한다.^2
3.5.2 코딩 학습자: AI에게 “코드 완성”을 맡기면 공부가 아니라 ‘관람’이 된다^2
화자는 코딩 학습자에 대해 “AI 쓰는 걸 좀 자제해야 한다”고 말한다.^2
그 근거로 수학 공부 비유를 든다.^2
- 수학 공부를 하려는데 AI에게 수학 문제까지 풀게 하면
- 그건 공부가 아니라 “AI가 재롱 부리는 거 관람”이라는 것이다.^2
이 비유의 요지는 다음과 같다.^2
- 학습의 본질은 본인이 문제 해결 과정을 거치며 사고력을 만드는 것인데
- 정답/완성물을 AI가 대신 만들어주면
- 학습자는 수동 소비자가 되어버린다.^2
그래서 코딩 공부 단계에서는 다음이 “가장 좋다”고 권한다.^2
- AI에게 “코드 완성까지 시키는 건 좀 자제”
- AI는 “검색 도구 정도로 사용”
여기서 ‘검색 도구’는 문맥상:
- 문법/개념을 찾아보는 용도
- 에러 메시지 해석
- 예제 코드를 참고하는 수준
정도로 제한하라는 취지로 읽힌다.^2
[!IMPORTANT] 코딩 학습자에게 주는 핵심 경고 학습 단계에서 AI가 코드를 다 완성해주면 ‘내 실력’이 늘지 않고, 공부가 아니라 “AI 재롱 관람”이 될 수 있다는 문제의식이 이 콘텐츠의 중요한 축이다.^2
3.5.3 코딩 안 해 본 사람: 바이브 코딩을 “당장” 추천 — 최고의 ‘코딩 맛보기 도구’^2
반대로 코딩을 전혀 안 해 본 사람에게는 바이브 코딩을 “당장 해 보는 걸 추천”한다고 말한다.^2
그 이유를 “최고의 코딩 맛보기 도구”라고 표현한다.^2
여기서 “맛보기”는 정식 커리큘럼 이전에 흥미를 붙이고, 내가 만들고 싶은 것을 실제로 만들어보는 동기 부여 장치라는 의미로 전개된다.^2
3.6 코딩의 목적과 초보가 포기하는 지점: ‘재밌는 소프트웨어’ vs ‘노잼 망치질/톱질’^2
화자는 코딩의 목적을 “재밌는 소프트웨어 만드는 거 아니겠습니까?”라고 설정한다.^2
그러나 현실적으로 그 목적에 도달하려면 “코드로 망치질, 톱질 하는 법”을 배워야 하는데, 그 과정이 “보통은 노잼이라 포기를 많이” 한다고 말한다.^2
이 비유에서:
- 망치질/톱질 = 문법, 환경설정, 디버깅, 라이브러리 사용법 같은 기초 노동
- 노잼 = 즉각적인 결과물이 안 나와 지루함
- 포기 = 학습 이탈
의 구조가 형성된다.^2
바이브 코딩이 이 지점에서 작동하는 방식은 다음과 같다.^2
- “코딩을 하면 AI가 이거 톱질 망치질을 전부 해 주잖아요.”
- 그래서 “초보도 이제 바로바로 재밌는 소프트웨어를 만들어 볼 수” 있다.^2
결론적으로 사람(사용자)이 해야 할 일은 “로직 작성 이런 거밖에” 남지 않는데, 화자는 이것이 “원래 개발의 본질”이라고 말한다.^2
- 코딩은 “머릿속에 있는 로직을 표현하는 수단일 뿐”이라는 관점으로 정리된다.^2
[!TIP] 초보가 바이브 코딩으로 얻는 이득 결과물을 빠르게 만들어보며 흥미를 유지하고, 사람이 집중해야 할 “로직(무엇을 만들지, 어떻게 동작해야 하는지)”에 더 빨리 닿게 해준다.^2
3.7 AI로 하다 막히면 ‘그때’ 코딩을 찍먹하라: 사용 경험이 늘면 “천재/튜링상”도?^2
화자는 AI로 코드를 짜다 보면 “슬슬 안 되는 것도 있을” 것이라고 말한다.^2
그럴 때는 “코딩 한번 찍먹해 보시면” 된다고 제안한다.^2
즉, 처음부터 정공법으로 문법을 다 배우고 시작하기보다는:
- AI로 먼저 만들어본다
- 막히는 지점에서 필요한 만큼만 코딩을 학습한다
- 그렇게 “코딩 유스 풀이 점점 늘어나면” 더 큰 성장이 가능하다
라는 흐름을 제시한다.^2
그리고 다소 과장 섞인 기대를 던진다.^2
- “여러분 중에 천재도 나오고 튜링상 수상자도 나오지 않을까요?”^2
이는 바이브 코딩이 진입장벽을 낮춰 더 많은 사람이 창작/실험을 시작하면, 그 중 일부는 큰 성과를 낼 수도 있다는 낙관을 표현한 것이다.^2
3.8 바이브 코딩은 가이드가 거의 필요 없다: 툴만 잘 고르면 된다 (에디터/CLI, 폴더 오픈, 명령) ^3
화자는 “바이브 코딩은 그냥 시작하면 되는 거라 딱히 가이드가 필요 없긴” 하다고 말한다.^3
다만 “사용할 툴부터 잘 고르면” 된다고 하며 최소한의 준비 절차를 제시한다.^3
화자가 말하는 준비/시작 단계는 다음 순서로 제시된다.^3
- 파일 수정을 “제가(지 스스로) 알아서” 해주는 에디터나 CLI 프로그램 설치하면 준비 끝^3
- 작업용 폴더를 하나 만들고, 에디터에서 폴더를 오픈^3
- AI에게 코딩하라고 명령 내리면 됨^3
- 또는 CLI 프로그램을 쓸 거면(혹은 쓰는 경우에도) “에디터 하나 설치하시는 게 낫”다^3
- 에디터에서 작업 폴더 오픈 + 터미널 켜기 + CLI 프로그램 오픈 후 코딩 시작^3
여기서 ‘커서(CURSOR) 같은 AI 에디터’나 ‘제미나이/기타 CLI’ 같은 키워드가 영상 메타에 있으나, 본문에서는 특정 제품명을 길게 설명하기보다 **형태(에디터/CLI)와 작업 흐름(폴더-에디터-터미널-명령)**을 강조한다.^3
3.9 더 잘 되게 하는 요령 1: 에이전트/추론 모델 + ‘계획→실행’이 개발자 방식이라 정확도가 높다^3
화자는 바이브 코딩 도구를 쓸 때 “보통 에이전트 아니면 이제 추론해주는 모델을 사용하는 게 좋다”고 말한다.^3
그 이유는 이런 모델/모드가 다음을 수행하기 때문이라고 설명한다.^3
- 코딩을 시키면
- 여러 단계에 걸쳐
- 어떤 스텝으로 할지 “계획부터 적고”
- 그걸 차례로 실행하는 과정을 보여준다^3
그리고 이 방식이 “원래 개발자들이 코딩하는 방식”이라서 “그렇게 하는 게 가장 정확도가 높다”고 결론낸다.^3
즉, 단발성 코드 생성보다 작업을 단계로 쪼개고 계획을 세우는 프로세스가 성공률을 높인다는 주장이다.^3
만약 도구가 계획을 자동으로 안 해준다면, 사용자가 프롬프트로 보완하라고 한다.^3
- “계획표를 먼저 이렇게 뽑으라고 한 다음에”
- “그거대로 코드를 짜라고 명령”하면
- “훨씬 결과가 나을 수 있다.”^3
[!TIP] 계획을 먼저 뽑아내는 프롬프트 전략 에이전트가 알아서 단계화를 안 해주면, 먼저 “구현 계획/스텝”을 출력하게 하고 그 계획을 기준으로 코드 생성을 진행하면 결과가 좋아질 수 있다고 말한다.^3
3.10 백엔드/배포가 복잡하면: 백엔드를 쉽게 만들어주는 서비스도 고려, 거기에 맞춰 코딩 지시^3
화자는 만들고 싶은 프로젝트에 “백엔드 서버가 필요한” 경우를 든다.^3
이때 “배포 방식이 복잡”하면 “관리도 어렵기 때문에” 백엔드를 쉽게 만들어주는 서비스들을 “한번 써 보는 것도 나쁘지는 않”다고 말한다.^3
그리고 작업 방식은 다음처럼 이어진다.^3
- 그런 서비스를 선택한다
- “거기 맞춰서 코드를 또 짜라고 명령”한다
- “그걸 올리기만 하면 배포 끝”이라고 정리한다^3
즉, 바이브 코딩은 코드 생성뿐 아니라 배포/운영 난이도를 낮추는 플랫폼 선택과 함께 갈 때 효용이 커진다는 관점이다.^3
3.11 보안/개인정보 가드레일: 검토시키되, 개인정보는 최대한 다루지 말 것 + 소셜 로그인 권장^3
화자는 구현이 진행되다 보면 “서버, DB, 회원 인증”이 들어가는 경우가 있다고 말한다.^3
이런 경우 “보안 측면에서 보강할 게 있냐고” AI에게 “한번 검토시키는 것도 좋다”고 제안한다.^3
동시에 개인정보에 대해서는 강한 주의를 준다.^3
이는 바이브 코딩으로 빠르게 만들수록 보안/프라이버시 설계가 허술해질 수 있으니, 애초에 개인정보를 덜 다루는 방향으로 제품을 설계하거나 외부 인증(소셜 로그인)으로 책임 영역을 줄이라는 조언으로 읽힌다.^3
[!WARNING] 개인정보를 적게 다루는 설계가 안전장치가 된다 AI에게 보안 보강 포인트를 검토시키는 것 자체는 유용하지만, 아예 개인정보를 “최대한 다루지 않는” 방향과 “소셜 로그인” 같은 선택을 권장한다는 점을 강조한다.^3
3.12 단점 1: 코딩이 처음이면 문제라고 ‘인식조차’ 못 할 수 있다 (느낌이 다 비슷해짐) ^4
화자는 “단점도 여러 가지”가 있다고 전환한다.^4
그중 하나로 AI 코딩을 하다 보면 “느끼는 점이 다 똑같은 것 같”다고 말한다.^4
이는 결과물이:
- 비슷한 구조/패턴/표현으로 수렴하거나
- 독창성/개성/설계 의도가 희미해지는 문제
를 암시한다.^4
그리고 “코딩이 처음이면 이런 걸 문제라고 인식조차 못 할 수도” 있다고 덧붙인다.^4
즉, 초보는 결과물의 품질 문제(설계 냄새, 유지보수성, 성능/보안 리스크, 과도한 복잡성 등)를 평가할 기준이 없어서, ‘그럴듯함’에 속기 쉽다는 우려가 깔려 있다.^4
3.13 단점 2(가장 큼): 코드가 길어지면 AI가 멍청해진다 — 비싼 모델 말고 ‘약간 읽을 줄 알면’ 해결도 가능^4
화자는 바이브 코딩의 큰 단점으로 “코드가 길어지면 AI가 멍청해진다는 단점이 가장 클 텐데”라고 말한다.^4
이는 프로젝트 규모가 커질수록:
- 문맥 유지가 어려워지고
- 앞뒤 일관성이 무너지고
- 수정 시 부작용이 증가하는
상황을 지칭한다.^4
이 문제를 해결하려고 “더 비싼 모델”로 가려는 사람들도 있다고 언급한다.^4
하지만 화자는 다른 해결책도 있다고 말한다.^4
- “코드를 약간만 읽을 줄 알면 해결되는 일도 많을 거고요.”^4
즉, 무조건 모델 스펙업만이 답이 아니라, 사용자가 최소한의 독해/검증 능력을 갖추면 상당수 문제를 줄일 수 있다는 주장이다.^4
3.14 실무에서는 왜 어렵다는 말이 나오는가: ‘다 맡기면 망한다’ + ‘항상 검증’ + ‘세세한 지시 필요’^4
화자는 “실무에서도 바이브 코딩은 쓰기 어렵다는 의견이 많습니다”라고 말하며 현업 관점을 소개한다.^4
이어서 사내에서 “느좋 코딩으로 이것저것 실험을 해보고 리포트 같은 걸 써 놓은 분”이 있다고 언급하며, 그 사람의 말을 빌려 핵심 경고를 전달한다.^4
인용 요지는 다음과 같다.^4
- “AI에게 모든 걸 맡기면 당연히 망할 수밖에 없고요.”
- “항상 검증이 필요”하다.^4
그 이유를 화자는 독특한 표현으로 설명한다.^4
- AI가 “가끔 거짓말하고 ADHD가 있고 치매가 있기 때문에” 그렇다^4
이 표현은 의학적 진단을 말하려는 게 아니라, 사용자 경험상 AI가 보이는 행동 특성을 풍자적으로 묘사한 것이다:
- 거짓말 = 그럴듯한 오답/환각
- ADHD = 집중이 튀고 지시를 놓침/산만함
- 치매 = 긴 문맥에서 이전 내용을 잊어버림
을 뜻하는 비유로 사용된다.^4
또한 “다른 개발자”의 경험도 소개한다.^4
- “빠른 프로토타입 만들 때만 편”했고
- 코드가 길어지면 “멍청해져서 세세하게 지시가 필요”했다고 한다^4
즉 실무에서의 난점은:
- 빠르게 초안을 뽑는 데는 좋지만
- 규모가 커지면 관리/수정/정합성에서 비용이 급증하고
- 사람의 검증·지시·설계가 오히려 더 중요해진다는 점으로 제시된다.^4
[!IMPORTANT] 실무 관점의 결론 “전부 맡기면 망한다” → 그래서 “항상 검증이 필요”하다는 경고가 반복된다. 바이브 코딩은 프로토타이핑엔 유리하지만, 길어질수록 세세한 지시와 검증 부담이 커진다는 증언이 붙는다.^4
3.15 결론적 권유: 만들고 싶던 서비스/툴이 있으면 도전해보되, 과의존은 금물 (사이드 프로젝트 성격) ^4
화자는 종합 결론으로, 평소에 만들고 싶었던 “서비스나 툴 같은 게 있으면 바이브 코딩으로 도전 한번 해 보시면” 된다고 권한다.^4
본인 사례로도 “이런 게임 20분 만에 한번 만들어 봤”다고 말한다.^4
이어서 농담 섞인 확장 아이디어를 덧붙인다.^4
- “바나나 드랍 기능”을 추가한 다음
- 스팀에 출시하면
- “매출 100억 확정”이라는 식으로 과장된 농담을 한다^4
하지만 곧바로 현실 제약을 다시 상기시킨다.^4
- “한계점도 있으니까 너무 의존하진 마시고요.”^4
마지막으로 “바이브 코딩이라는 말을 처음 쓴 사람”에 대한 관찰을 덧붙여 균형을 잡는다.^4
- 그 사람은 “코알못이 아니라 코딩에 통달한 분”이었다^4
- 그분이 바이브 코딩했다고 소개한 프로젝트를 보면 “간단한 사이드 프로젝트”였다^4
- “이런 점 한번 생각해 보시고요”라고 마무리한다^4
즉, 바이브 코딩을 만든/유행시킨 사람조차도:
- 코딩을 모르는 사람이 아니라 숙련자였고
- 적용 사례도 거대한 상용 시스템이 아니라 간단한 사이드 프로젝트였다는 점을 들어
“바이브 코딩을 어디까지 믿고 어디에 쓰는 게 적절한지”를 시청자가 스스로 판단하라는 메시지로 끝낸다.^4
4. 핵심 통찰^2
- [h 바이브 코딩은 방법론이 아니라 ‘AI에게 전부 맡기는 사용 태도’에 붙은 이름]이며, 유행과 플랫폼 마케팅까지 확산될 만큼 진입장벽을 낮춘다.^1
- [h 코딩 학습자에게 바이브 코딩의 과의존은 학습을 ‘관람’으로 바꿀 위험]이 있다. AI는 검색 도구처럼 제한적으로 쓰는 편이 낫다는 기준을 제시한다.^2
- [h 코딩 비경험자에게는 바이브 코딩이 최고의 ‘맛보기’ 도구]가 될 수 있다. 초보가 재미를 빨리 경험하고 로직 중심으로 사고하게 만드는 장점이 있다.^2
- [h 성공률을 올리려면 ‘계획→실행’ 프로세스가 핵심]이며, 에이전트/추론 모델을 쓰거나 계획표를 먼저 뽑게 하는 식으로 작업을 단계화해야 한다.^3
- [c “AI에게 모든 걸 맡기면 망한다”는 실무 경고]가 반복된다. 검증은 선택이 아니라 필수이며, 길어질수록 AI가 취약해진다.^4
- [h 개인정보를 최소화하는 제품 설계가 실질적인 안전장치]로 제시된다. 가능하면 개인정보를 덜 다루고 로그인도 소셜 로그인으로 처리하라고 권한다.^3
실행 관점에서의 행동 항목(콘텐츠가 권하는 방향을 ‘행동’으로 풀어쓴 것):
- 코딩 학습자라면: AI에게 “완성 코드”를 시키기보다, 모르는 개념/에러/문법을 묻는 “검색 도구”로 제한한다.^2
- 비경험자라면: 만들고 싶은 작은 결과물을 정하고 바이브 코딩으로 바로 만들어보며, 막힐 때 필요한 만큼만 코딩을 배운다.^2
- 도구 사용 시: 에이전트/추론 모델을 우선 고려하고, 아니면 먼저 계획표를 출력하게 한 뒤 그 계획대로 실행시키는 프롬프트를 사용한다.^3
- 서버/DB/인증이 붙으면: 보안 보강 포인트를 검토시키되, 개인정보는 최소화하고 소셜 로그인을 고려한다.^3
- 프로젝트가 커지면: “길어질수록 멍청해진다”는 전제를 두고, 사람이 코드를 읽고 검증하는 루틴을 반드시 둔다.^4
5. 헷갈리는 용어 정리 (해당 시에만)^1
바이브 코딩: AI에게 코딩을 사실상 전부 맡기고, 사용자는 자연어로 지시하며 결과물을 만드는 방식/태도.^1
느좋(느낌 좋다): ‘좋은 느낌’이라는 뜻의 속어로, 화자는 vibe를 이 표현으로 번역해 “느좋 코딩”이라 부른다.^1
에이전트(Agent): 코딩 작업을 여러 단계로 나누어 계획을 세우고 순차 실행하는 식으로 일을 진행하는 AI 동작 방식/도구 유형으로 언급된다.^3
추론 모델: 코딩 시 계획과 단계적 실행을 더 잘 보여주거나 수행하는 모델 유형으로 언급된다.^3