OpenClaw, Claude Code , AI Agent 등을 이용하여 AI 비서 자동화 모임 정보 공유 카페입니다.
서울시 금천구
IT/모바일
Vibe 코딩을 사용할 때 개발부터 배포까지 반드시 숙지해야 할 7가지-01 | 당근 카페
Ritz
인증 19회 · 1일 전
Vibe 코딩을 사용할 때 개발부터 배포까지 반드시 숙지해야 할 7가지-01
Vibe 코딩을 사용할 때 개발부터 배포까지 반드시 숙지해야 할 7가지
당신은 프롬프트를 쓰고 배포 버튼을 누르기만 한다고 생각하나요? 그렇게 서두르지 마세요.
우리 모두 그 순간을 겪었습니다. AI에 몇 문장을 입력하면, 몇 초 안에 수백 줄의 코드가 화면에 나타납니다. 깔끔하고 구조화되어 있으며 의심스러울 정도로 완벽해 보입니다. 새벽 2시에 더 이상 스택 오버플로 토끼굴은 없습니다. 더 이상 어디서부터 시작해야 할지 궁금해하며 깜빡이는 커서를 응시하지 마세요. 마치 누군가가 소프트웨어 개발을 위한 치트 코드를 건네준 것 같은 느낌입니다.
그것이 바로 바이브 코딩입니다 — 2025년 2월에 OpenAI의 공동 창립자인 안드레이 카르파티가 만든 용어입니다. 그 개념은 겉보기에는 간단합니다. 원하는 것을 설명하면 AI가 코드를 작성합니다. 카르파티 자신은 그것을 "분위기에 완전히 굴복하고, 지수 함수를 받아들이며, 코드가 존재한다는 사실조차 잊는" 작업 방식이라고 설명했습니다.
해방감 있게 들리죠, 그렇죠?
문제는 이렇습니다. 그 용어가 만들어진 지 1년도 채 되지 않아 개발자 커뮤니티는 다른 것에 대해 이야기하기 시작했습니다. 바로 "바이브 코딩 숙취"입니다. 그것이 바로 당신이 빌드 패스트의 환희에서 깨어나 당신의 코드베이스가 생산 혼란에서 한 배치 떨어진 곳에 있는 시한폭탄이라는 것을 깨닫는 지점입니다.
숫자들은 진지한 이야기를 들려줍니다. Veracode 연구(2025)에 따르면 AI 생성 코드의 45%가 보안 취약점을 포함하고 있습니다. Escape.tech는 1,400개 이상의 바이브 코딩 프로덕션 애플리케이션을 스캔한 결과, 65%가 보안 문제를 겪고 있으며, 58%는 적어도 하나의 중요한 취약점을 포함하고 있음을 발견했습니다. 가트너는 2028년까지 주로 AI 생성 코드로 구축된 프로젝트의 40%가 누적된 기술 부채로 인해 취소되거나 대대적인 재작업에 직면할 것으로 예측합니다.
So before you git push --force to production, here are 7 things you need to get right. 여기에 7가지가 있습니다.
1. Never Trust AI Output Blindly — Read It Like a Junior Dev’s Pull Request
지역적으로, 그래서 합병됩니다. 하지만 그 "올바른" 표면 아래에는 결함이 있는 논리, 불필요한 의존성, 또는 교과서 보안 취약점이 조용히 피해를 일으키고 있을 수 있습니다.
AI 생성 코드의 모든 부분을 프로젝트의 비즈니스 맥락을 모르는 똑똑한 주니어 개발자의 풀 요청을 대하듯 처리하세요. 중요한 섹션을 줄마다 읽어보세요. 특히 인증, 데이터베이스 쿼리, 사용자 입력 처리와 관련된 모든 것을요.
몇 가지 주목할 만한 사항:
인증 로직 — AI는 종종 완전해 보이지만 토큰 만료, 세션 무효화 또는 동시 로그인 처리와 같은 중요한 에지 케이스를 놓치는 인증 흐름을 생성합니다.
데이터베이스 쿼리 — AI가 SQL 쿼리에 원시 문자열 보간을 사용하지 않는지 확인하십시오. 그것이 SQL 주입의 고전적인 진입점이며, 여전히 생성된 코드에 항상 나타납니다.
오류 처리 — AI는 행복한 길을 정확히 찾아내는 경향이 있지만, 문제가 발생했을 때 일어나는 일은 얼버무립니다. 항상 물어보세요: 이 API 호출이 실패하면 어떻게 되나요? 입력이 null이면 어떻게 되나요?
수입된 종속성 — AI가 새로 가져오는 모든 라이브러리는 잠재적인 공격 표면입니다. 아직도 유지 관리되나요? CVE를 알고 있나요?
다음은 AI가 일반적으로 어떻게 인증 함수를 생성하는지와 실제로 어떻게 보여야 하는지에 대한 실제 예입니다.
// 이전 ❌ — AI가 종종 생성하는 것
기능 로그인(사용자 이름, 비밀번호) {
const user = db.find(
u => u.username === username && u.password == password
이전 버전은 비밀번호를 일반 텍스트로 저장하고 비교합니다. 데이터베이스가 유출되면 모든 사용자 자격 증명이 즉시 노출됩니다. After 버전은 해싱을 위해 bcrypt, 만료를 사용하는 JWT, 그리고 어떤 필드가 잘못되었는지 드러내지 않는 의도적으로 모호한 오류 메시지를 사용합니다.
이 주제에 대해 광범위하게 글을 써온 베테랑 개발자 사이먼 윌리슨은 다음과 같이 잘 말했습니다. "만약 LLM이 당신의 코드의 모든 줄을 작성했지만, 당신이 그것을 모두 검토하고, 테스트하고, 이해했다면, 그것은 바이브 코딩이 아닙니다." 그것은 LLM을 타이핑 보조로 사용하는 것입니다. 둘 사이의 경계는 얇지만, 그 의미는 엄청납니다.
2. Manage Your Context Window Carefully — AI Doesn’t Remember Yesterday
앱에서 열기
가입하기
로그인
검색
이미지를 전체 크기로 보려면 입력 또는 클릭을 누르세요.
당신은 개발자 Awam의 Friend Link를 통해 무료로 읽고 있습니다. 미디엄의 최고에 접근하기 위해 회원이 되세요.
멤버 전용 스토리
바이브 코딩 시 반드시 맞춰야 할 7가지 — 개발부터 배포까지
개발자 아왐
따르다
13분 읽기
·
1시간 전
들어보세요
공유하다
당신은 프롬프트를 쓰고 배포 버튼을 누르기만 한다고 생각하나요? 그렇게 서두르지 마세요.
우리 모두 그 순간을 겪었습니다. AI에 몇 문장을 입력하면, 몇 초 안에 수백 줄의 코드가 화면에 나타납니다. 깔끔하고 구조화되어 있으며 의심스러울 정도로 완벽해 보입니다. 새벽 2시에 더 이상 스택 오버플로 토끼굴은 없습니다. 더 이상 어디서부터 시작해야 할지 궁금해하며 깜빡이는 커서를 응시하지 마세요. 마치 누군가가 소프트웨어 개발을 위한 치트 코드를 건네준 것 같은 느낌입니다.
여기를 클릭하면 전체 이야기를 무료로 읽을 수 있습니다.
그것이 바로 바이브 코딩입니다 — 2025년 2월에 OpenAI의 공동 창립자인 안드레이 카르파티가 만든 용어입니다. 그 개념은 겉보기에는 간단합니다. 원하는 것을 설명하면 AI가 코드를 작성합니다. 카르파티 자신은 그것을 "분위기에 완전히 굴복하고, 지수 함수를 받아들이며, 코드가 존재한다는 사실조차 잊는" 작업 방식이라고 설명했습니다.
해방감 있게 들리죠, 그렇죠?
문제는 이렇습니다. 그 용어가 만들어진 지 1년도 채 되지 않아 개발자 커뮤니티는 다른 것에 대해 이야기하기 시작했습니다. 바로 "바이브 코딩 숙취"입니다. 그것이 바로 당신이 빌드 패스트의 환희에서 깨어나 당신의 코드베이스가 생산 혼란에서 한 배치 떨어진 곳에 있는 시한폭탄이라는 것을 깨닫는 지점입니다.
숫자들은 진지한 이야기를 들려줍니다. Veracode 연구(2025)에 따르면 AI 생성 코드의 45%가 보안 취약점을 포함하고 있습니다. Escape.tech는 1,400개 이상의 바이브 코딩 프로덕션 애플리케이션을 스캔한 결과, 65%가 보안 문제를 겪고 있으며, 58%는 적어도 하나의 중요한 취약점을 포함하고 있음을 발견했습니다. 가트너는 2028년까지 주로 AI 생성 코드로 구축된 프로젝트의 40%가 누적된 기술 부채로 인해 취소되거나 대대적인 재작업에 직면할 것으로 예측합니다.
이 모든 것은 AI 사용을 두려워하게 하려는 의도가 아닙니다. 정반대입니다. 바이브 코딩은 진정으로 강력하며, 여기서의 목표는 당신이 그것을 올바르게 사용할 수 있도록 돕는 것입니다. 왜냐하면 바이브 코딩으로 번성하는 개발자들과 디버깅 지옥에 빠져드는 개발자들을 구분하는 것은 도구 자체가 아니라, 그들이 출력을 어떻게 처리하는지에 있기 때문입니다.
그래서 생산에 힘을 쏟기 전에, 여기 당신이 제대로 해야 할 7가지가 있습니다.
AI 출력물을 맹목적으로 신뢰하지 마세요 — 주니어 개발자의 당기기 요청처럼 읽어보세요
이것은 당신이 저지를 수 있는 가장 흔하고 가장 비싼 실수입니다.
바이브 코딩은 개발자들이 AI 생성 코드를 진정으로 이해하지 않고 받아들이는 문화를 만듭니다. 테스트가 통과되면 로컬에서 실행되므로 병합됩니다. 하지만 그 "올바른" 표면 아래에는 결함이 있는 논리, 불필요한 의존성, 또는 교과서 보안 취약점이 조용히 피해를 일으키고 있을 수 있습니다.
AI 생성 코드의 모든 부분을 프로젝트의 비즈니스 맥락을 모르는 똑똑한 주니어 개발자의 풀 요청을 대하듯 처리하세요. 중요한 섹션을 줄마다 읽어보세요. 특히 인증, 데이터베이스 쿼리, 사용자 입력 처리와 관련된 모든 것을요.
몇 가지 주목할 만한 사항:
인증 로직 — AI는 종종 완전해 보이지만 토큰 만료, 세션 무효화 또는 동시 로그인 처리와 같은 중요한 에지 케이스를 놓치는 인증 흐름을 생성합니다.
데이터베이스 쿼리 — AI가 SQL 쿼리에 원시 문자열 보간을 사용하지 않는지 확인하십시오. 그것이 SQL 주입의 고전적인 진입점이며, 여전히 생성된 코드에 항상 나타납니다.
오류 처리 — AI는 행복한 길을 정확히 찾아내는 경향이 있지만, 문제가 발생했을 때 일어나는 일은 얼버무립니다. 항상 물어보세요: 이 API 호출이 실패하면 어떻게 되나요? 입력이 null이면 어떻게 되나요?
수입된 종속성 — AI가 새로 가져오는 모든 라이브러리는 잠재적인 공격 표면입니다. 아직도 유지 관리되나요? CVE를 알고 있나요?
다음은 AI가 일반적으로 어떻게 인증 함수를 생성하는지와 실제로 어떻게 보여야 하는지에 대한 실제 예입니다.
// 이전 ❌ — AI가 종종 생성하는 것
기능 로그인(사용자 이름, 비밀번호) {
const user = db.find(
u => u.username === username && u.password == password
이전 버전은 비밀번호를 일반 텍스트로 저장하고 비교합니다. 데이터베이스가 유출되면 모든 사용자 자격 증명이 즉시 노출됩니다. After 버전은 해싱을 위해 bcrypt, 만료를 사용하는 JWT, 그리고 어떤 필드가 잘못되었는지 드러내지 않는 의도적으로 모호한 오류 메시지를 사용합니다.
이 주제에 대해 광범위하게 글을 써온 베테랑 개발자 사이먼 윌리슨은 다음과 같이 잘 말했습니다. "만약 LLM이 당신의 코드의 모든 줄을 작성했지만, 당신이 그것을 모두 검토하고, 테스트하고, 이해했다면, 그것은 바이브 코딩이 아닙니다." 그것은 LLM을 타이핑 보조로 사용하는 것입니다. 둘 사이의 경계는 얇지만, 그 의미는 엄청납니다.
2. 컨텍스트 창을 신중하게 관리하세요 — AI는 어제를 기억하지 않습니다
초보자들이 일관되게 과소평가하는 한 가지는 AI가 장기 기억이 없다는 것입니다. 매 새로운 세션마다 새롭게 시작됩니다. 그리고 단 한 세션 내에서도, 맥락이 길어질수록 출력 품질이 저하되는 경향이 있습니다.
이것은 각 세션 시작 시 AI에 올바른 컨텍스트를 제공하지 않으면 AI가 자체적인 가정을 하게 된다는 의미이며, 이러한 가정은 이미 확립한 아키텍처나 디자인 결정과 완전히 일치하지 않을 수 있습니다. 결과? 고립적으로 작동하지만 나머지 프로젝트에 맞지 않는 코드.
구축할 가치가 있는 습관:
루트 디렉토리에 CONTEXT.md 또는 PROJECT.md를 생성하세요. 간단한 아키텍처 개요, 기술 스택, 주요 디자인 결정, 명명 규칙, 그리고 팀이 따르는 모든 패턴으로 채우세요. 매 새로운 세션 시작 시 이것을 붙여주세요.
작업을 작고 집중된 덩어리로 나누세요. AI에게 한 프롬프트에서 "완전한 체크아웃 기능을 구축"하라고 요청하지 마세요. 그것을 "배송 양식 컴포넌트 구축", 그리고 "주문 제출을 위한 API 엔드포인트 생성" 등으로 나눕니다.
다음 프롬프트로 이동하기 전에 항상 출력을 검토하십시오. 만약 3단계에서 무언가가 이상하고 당신이 그것을 알아차리지 못한다면, AI는 4단계, 5단계, 6단계에서 그 무너진 기초 위에 구축할 것입니다.
자신의 프로젝트에 맞게 조정할 수 있는 최소한의 CONTEXT.md:
<!-- CONTEXT.md — paste this at the start of every AI session -->