Vibe Engineering MEAP Edition – My AI Smarteasy 사용자 정의 코파일럿 에이전트 – 일타 저스틴과 함께 책 읽기
🎯 Vibe Engineering: AI 코딩의 함정과 해결책
안녕하세요, 여러분! 일타 강사 저스틴입니다! 🚀
오늘은 Tomasz Lelek과 Artur Skowroński가 쓴 ‘Vibe Engineering’ 책의 1장. Building on Quicksand: The challenges of Vibe Engineering을 함께 볼게요.
이 책은 AI 코딩 도구의 빠른 속도 뒤에 숨겨진 치명적 위험과 이를 극복하는 체계적 방법론을 다룹니다. 여러분이 AI를 쓰면서 “이거 괜찮나?” 싶었던 경험이 있으시죠? 바로 그 문제의 본질을 파헤칩니다!
🎯 핵심 메시지
“Vibe Coding – 번개 같은 속도로 앱을 만들지만 전문적 엄격함이나 보안 인식 없이 진행하는 것”
저자들이 말씀하시는 ‘Vibe Coding’의 핵심은 ‘느낌대로 AI를 믿고 코드 생성 → 검증 없이 배포’라는 거예요.
쉽게 비유하면, 레시피 없이 요리해서 손님에게 내주는 것과 같아요. 처음엔 맛있어 보이지만, 한 입 먹으면 엉망이 되는 거죠.
실제 사례만 봐도 소름 돋습니다: 런칭 3일 만에 해킹당한 스타트업, AI 명령어 하나로 프로젝트 전체 삭제!
💡 실제 실패 사례 4가지
저자들이 보여주신 실제 사례들이 충격적이었어요:
Enrichlead 스타트업: “제로 핸드라이팅 코드”로 런칭 → 3일 만에 API 키 털리고 DB 랜덤 데이터로 오염
여기서 포인트! AI는 “보이는 기능”은 잘 만들지만, 보안(input validation, rate limiting)은 전혀 모른다는 거예요.
CS 1학년도 피하는 실수인데, AI가 “기능만 되는 코드”를 뽑아낸 거죠.
자, 여러분 회사에서 이런 코드가 프로덕션에 들어가면? 바로 망하는 거예요!
🔄 Vibe Coding vs Vibe Engineering
저자들은 명확한 구분을 제시하셨어요:
| Vibe Coding (연금술) | Vibe Engineering (화학) |
|---|---|
| 느낌대로 프롬프트 → 코드 생성 | 실행 가능한 명세 먼저 작성 |
| 검증 없이 배포 | 테스트/CI/CD로 검증 |
| 빠른 프로토타입 | 프로덕션 준비 완료 코드 |
제가 쉽게 풀면, Vibe Coding은 스케치, Vibe Engineering은 완성된 건축 설계도예요.
문제는 많은 팀이 스케치를 건물로 착각한다는 거죠!
🧪 ISBN 검증 실험 (핵심!)
가장 인상적이었던 건 ISBN-13 검증 함수 실험이었어요:
|
1 2 3 4 5 6 7 8 |
❌ 일반 프롬프트: "ISBN 검증 함수 만들어줘" → 모델마다 다른 버그 (하이픈 처리 실패 등) <span style="color: #ff0000;">✅ Vibe Engineering 방식: 1. 인간이 먼저 pytest 작성 2. AI에게 "이 테스트들 통과하는 코드 작성해" → Gemini, ChatGPT, Claude 모두 100% 통과! </span> |
이게 무슨 뜻이냐면요, 신뢰의 원천은 모델이 아니라 인간 작성 명세라는 거예요!
여러분, 다음에 AI 코드 쓸 때 “테스트 먼저“ 기억하세요!
📌 저스틴의 정리
첫째, 저자들이 경고한 대로 Vibe Coding은 프로덕션에서 자살행위입니다. 실제 해킹/데이터삭제 사례가 증거예요.
둘째, 실행 가능한 명세(테스트)가 진짜 소스 오브 트루스. AI는 이걸 만족시키는 도구일 뿐이에요.
셋째, 앞으로 엔지니어 역할은 “코드 작성자 → 시스템 설계자/검증자”로 바뀝니다.
💪 오늘의 실천 과제
오늘 저녁 20분 동안:
- 기존 AI 생성 코드 하나 골라서
- pytest 5개 작성 (정상/경계/비정상 케이스)
- AI에게 “이 테스트들 통과하는 코드 재작성해”라고 요청
- 결과 비교해보세요!
이 간단한 실험으로 Vibe Engineering의 힘을 직접 느끼실 겁니다!
🎯 레거시 코드 AI 마이그레이션: JBoss → Spring Boot 실전
오늘은 Tomasz Lelek과 Artur Skowroński의 ‘Vibe Engineering’ 책 2장. Building a legacy modernization framework powered by Vibe Engineering을 함께 볼게요.
레거시 코드 마이그레이션을 AI로 어떻게 체계적으로 하는지, 실제 JBoss → Spring Boot 사례를 통해 배웁니다.
여러분 회사에 옛날 기술로 된 코드가 있으시죠? 바로 그걸 현대화하는 실전 프레임워크예요!
🎯 핵심 메시지
“레거시 코드베이스를 마주했을 때, 어디서부터 시작해야 할지 모르는 상황”
저자들이 제시하는 ‘Vibe Engineering 마이그레이션 프레임워크’의 핵심은 ‘AI로 큰 그림 파악 → 점진적 증분 마이그레이션 → 테스트 검증’입니다.
비유하자면, 어두운 방에 들어가 불 켜기 전에 먼저 지도 그리는 것과 같아요.
수동으로 코드 읽는 대신 AI가 구조를 분석해주니, 시간 10배 단축!
💡 실제 적용 사례: kitchensink 앱
저자들이 사용한 JBoss kitchensink 앱을 Spring Boot + MongoDB로 마이그레이션했어요:
|
1 2 3 4 |
원본: JBoss + Jakarta EE + SQL → Spring Boot + Thymeleaf + MongoDB 총 프롬프트: 25개 미만 (무료 Cursor로 충분!) |
여기서 포인트! 증분 크기 조절이 핵심입니다. 너무 크면 리뷰 불가능, 너무 작으면 AI 가치 없음.
🔄 핵심 트레이드오프 3가지
저자들이 분석한 치명적 트레이드오프들입니다:
| 문제 | 위험 | 해결책 |
|---|---|---|
| 증분 크기 | 너무 크면 리뷰 불가 | “최소한의 변경” 프롬프트 |
| AI 과잉 추론 | 불필요 코드 생성 | “정확히 이것만”, 컨텍스트 클린 |
| LLM 남용 | 정적 리팩토링 실패 | IDE 도구 우선 사용 |
제가 쉽게 풀면, AI는 ‘큰 덩어리 요리사’, IDE는 ‘정밀 수술사’예요. 용도에 맞게 써야 합니다!
🧪 실전 워크플로우 (단계별)
저자들이 제시한 프레임워크 7단계를 따라가봤어요:
|
1 2 3 4 5 6 7 8 |
1️⃣ AI로 큰 그림 파악 ("이 앱 뭐야?") 2️⃣ 테스트 생성/마이그레이션 3️⃣ 최소 Spring Boot 래핑 4️⃣ JBoss 정리 1차 5️⃣ UI 컨트롤러 마이그레이션 6️⃣ MongoDB 전환 7️⃣ 최종 PR 리뷰 |
가장 인상적: ISBN 실험처럼 pytest 먼저 → AI 코드 생성 원칙 적용!
🚀 “최소 변경” 마법 프롬프트
가장 실용적인 건 이 프롬프트예요:
|
1 2 3 4 |
AI Prompt Begin Apply a <strong>minimal set of changes</strong> to be able to wrap the code into Spring Boot and migrate to Java 21 |
결과? pom.xml에 Spring 의존성 추가, KitchensinkApplication main 클래스 생성, REST 어댑터링 완료!
이 간단한 한 줄로 80% 마이그레이션 끝납니다.
📌 저스틴의 정리
첫째, 저자들이 강조한 대로 수동 코드 읽기 대신 AI로 큰 그림부터. 시간 90% 절약!
둘째, 증분 크기 = 리뷰 가능 범위가 핵심. “최소 변경” 프롬프트 필수!
셋째, AI + IDE 조합. 패키지 리네임은 IDE, 복잡 로직은 AI!
💪 오늘의 실천 과제
오늘 저녁 30분 동안:
- 회사 레거시 코드 하나 클론
- Cursor/ChatGPT 열고 “What is this product? Describe high-level architecture” 입력
- 결과 보고 “Apply minimal set of changes to migrate to Spring Boot” 실행
- 테스트 돌려보세요!
레거시 코드가 순식간에 현대화되는 마법을 경험하실 겁니다!
🎯 Context Engineering: AI Agents를 위한 컨텍스트 최적화
오늘은 Tomasz Lelek과 Artur Skowroński의 ‘Vibe Engineering’ 책 4장 “Context Engineering: Optimizing context for AI Agents”를 설명할게요.
AI 코딩이 자꾸 실패하는 이유와 완벽한 해결책을 하나씩 차근차근 배웁니다!
🎯 가장 중요한 1가지: 왜 AI가 실패할까?
|
1 2 3 |
🤔 "프롬프트 잘 썼는데 왜 안돼?" → 답: **컨텍스트(맥락)을 제대로 안 줬어!** |
쉽게 말하면: AI는 마음 읽는 요정이 아니에요. 여러분이 코드+설명+예제를 제대로 안 주면 뻔한 답만 해요.
|
1 2 3 |
❌ "로그인 고쳐줘" → AI: "이런 코드 어때요?" (완전 엉뚱!) ✅ "이 3개 파일 보고 v2 API로 로그인 고쳐줘" → 완벽! |
💥 초보자가 하는 3가지 치명적 실수 (Bob 이야기)
Bob은 평범한 개발자예요. 여러분과 똑같이 AI 쓰다가 실패했어요:
❌ 실수 1: “Context Vacuum” (맥락 공백)
|
1 2 3 4 5 |
Bob: "로그인 코드 고쳐줘! (안 고치면 감옥감!)" AI: 완전 가짜 코드 생성! → DatabaseClient.findUserByName() ← 이런 함수 없음! → 비밀번호 평문 비교 ← 보안 취약! |
왜? 함수 1개만 복붙했기 때문!
AI가 모르는 것들: import 어디서? User 구조는? 이 함수 어떻게 호출돼?
비유: 의사한테 “배고프다”만 말하고 약 달라는 것!
❌ 실수 2: 너무 많은 코드 복붙 (Lost in the Middle)
|
1 2 3 |
프롬프트 2000자 중 중간: "v2 API 써!" AI: v1 그대로 사용 (중간 정보 까먹음!) |
연구 결과 (Claude 3.5 Sonnet):
|
1 2 3 |
32k 토큰 = 정확도 29% ✅ 256k 토큰 = 정확도 3% ❌ |
중간에 묻힌 정보 = AI가 잊어버려요!
❌ 실수 3: 파일들 그냥 붙여넣기
|
1 2 3 4 5 6 7 8 |
❌ File1: class AuthService {...} File2: class User {...} File3: class Error {...} ✅ [로그인 서비스 예제] - DB에서 유저 찾는 코드 [유저 데이터 구조] - 이런 모양의 데이터 [에러 처리 예제] - 이렇게 에러 던짐 |
라벨 1줄 = 성공률 90%↑
🛠️ 초보자도 바로 쓰는 해결법 5가지
1️⃣ “좋은 멀티샷” 쓰기 (가장 쉬움!)
|
1 2 3 4 5 6 |
<span style="color: #000000;"><code>✅ 초보자 멀티샷 템플릿: [이런 서비스 예제] ← 현재 수정할 코드와 똑같은 패턴 [데이터 구조 예제] ← 이런 모양 데이터 처리 [에러 예제] ← 실패시 이렇게 처리 [할 일] ← 지금 이것만 해줘! </code></span> |
2️⃣ “샌드위치 방법” (중요사항 잊어버림 방지)
|
1 2 3 4 |
🥪 처음: "v2 API만 써!" [부수적 설명들...] 🥪 끝: "다시 말하지만 v2 API야!" |
3️⃣ Cursor/Cline 같은 도구 쓰기 (자동화)
|
1 2 3 |
Cursor: 코드베이스 전체 분석 → 관련 파일만 자동 추출 Cline: 작업 계획표(ToDo) 자동 생성 → 잊어버림 방지 |
4️⃣ MCP (마법 연결고리) (고급)
|
1 2 3 4 |
Figma 디자인 → 자동 토큰 추출 GitHub 코드 → 자동 패턴 분석 API 문서 → 자동 스키마 가져옴 |
5️⃣ 체크리스트로 검증 (안전장치)
|
1 2 3 4 5 |
✅ 코드 컴파일돼? ✅ 기존 테스트 통과? ✅ 보안 취약점 없어? ✅ v2 API 썼어? |
🧩 각 기술 쉽게 이해하기
RAG (검색 증강 생성) = 구글 검색기
|
1 2 3 |
코드 10만줄 → AI가 "로그인" 관련 5줄만 찾아줌 → 컨텍스트 90% 줄고 정확도 3배↑ |
Context Anchor = 메모장 붙잡기
|
1 2 3 |
Cline: 작업할 때마다 "ToDo 리스트" 다시 보여줌 → 10단계 작업도 절대 까먹지 않음 |
Context Compaction = 요약 노트
|
1 2 3 |
Cursor: 50번 대화 → "요약: 로그인 고침, JWT v5 적용" → 컨텍스트 1/10로 압축 |
🚀 초보자 15분 실험 (오늘 바로!)
실패했던 AI 프롬프트 하나 골라서:
|
1 2 3 4 5 6 7 8 |
1️⃣ 3개 파일 복사 2️⃣ 이렇게 라벨 붙이기: [수정할 코드 예제] [데이터 구조] [에러 처리] 3️⃣ 처음+끝에 "할 일" 명확히 4️⃣ Cursor에서 실행 |
결과: 정확도 5배↑, 시간 1/3
📌 저스틴의 3가지 황금률
첫째, 컨텍스트 없으면 AI 실패 90%. 모델 탓이 아니라 입력 탓!
둘째, 라벨링이 생명. “이건 서비스야, 이건 데이터야” 명확히!
셋째, 중요사항은 처음+끝. 중간에 쓰면 AI가 잊어버림!
💪 오늘 저녁 15분 과제
|
1 2 3 4 5 |
1. 최근 실패한 AI 대화 복사 2. 3개 파일 찾아서 라벨링 3. 샌드위치 구조로 재시도 4. 결과비교! |
🎯 A scientific approach for validating LLM-based solutions
오늘은 Tomasz Lelek과 Artur Skowroński의 ‘Vibe Engineering’ 책 6장 “A scientific approach for validating LLM-based solutions”를 함께 볼게요.
텍스트→SQL 서비스를 만들며 LLM 정확도 과학적 검증하는 실전 프레임워크를 배웁니다.
“AI가 잘 되는 줄 알았는데 갑자기 안돼!” → 이런 문제 영원히 해결!
🎯 핵심 메시지: AI는 “느낌”이 아니라 “과학”이다!
“LLM 정확도 = 컨텍스트 크기 × 비용 × 정확도 트레이드오프”
저자들이 만든 Text-to-SQL 서비스로 3대 트레이드오프를 과학적으로 검증했어요:
|
1 2 3 4 |
1️⃣ LLM 제공자 종속성 → 인터페이스 캡슐화 2️⃣ "잘 되던 게 갑자기 안됨" → 과학적 벤치마크 3️⃣ 컨텍스트↑ = 정확도↑ = 비용↑ → 최적점 찾기 |
비유: 약 먹기 전에 임상시험 하는 것! 느낌대로 먹다가 망하는 일 방지!
💻 Text-to-SQL 서비스 완성 (Spring Boot)
먼저 실제 동작하는 서비스를 만들었어요:
|
1 2 3 4 |
사용자: "마케팅 부서 직원 수 세어줘" ↓ OpenAI GPT-4o-mini SQL: SELECT COUNT(*) FROM employees WHERE department='marketing' |
🏗️ 서비스 구조 (핵심 설계)
|
1 2 3 4 |
SqlGeneratorService (인터페이스) ← REST 컨트롤러 ↓ 구현체 OpenAiSqlGeneratorServiceImpl → OpenAI API |
핵심: LLM 제공자 숨김! OpenAI → Anthropic/Claude 언제든 변경 가능!
|
1 2 3 4 5 6 7 |
# application.yaml (비밀 무기) openai: api: key: ${OPENAI_API_KEY} model: gpt-4o-mini # 비용 최적화! timeout: 60s |
🧪 과학적 검증 프레임워크 (BIRD 벤치마크)
문제: “잘 되던 AI가 갑자기 틀리네? 왜?”
해결: BIRD 데이터셋 (1,000개 텍스트→SQL 쌍)으로 정확도 측정!
📊 정확도 계산법 (Overlap Similarity)
|
1 2 3 4 5 |
두 SQL 유사도 = (공통 단어) / (전체 단어) 예: SELECT name FROM users SELECT name FROM customers → 공통: {name} / 전체: {name, users, customers} = 0.33 |
장점: 간단 + 빠름 + 의미있는 비교
단점: 완벽한 SQL 동등성 아님 (하지만 실용적!)
🔬 실험 결과: 컨텍스트 vs 정확도 vs 비용
핵심 실험: 이전 N개 쿼리 컨텍스트 제공 시 정확도 변화
📈 p50 정확도 변화 (50% 쿼리 이 이상 정확도)
|
1 2 3 4 |
0개 이전쿼리: simple=0.46, moderate=0.39, challenging=0.31 10개 이전쿼리: simple=0.70↑, moderate=0.61↑, challenging=0.46↑ 20개 이전쿼리: 변화 없음 (포화!) |
결론: 10개가 스위트스팟! 더 주면 돈만 낭비!
💰 비용 폭발 분석 (100 req/s 기준)
|
1 2 3 4 |
0개 이전쿼리: $1,344/일 10개 이전쿼리: $2,016/일 (최적) 20개 이전쿼리: $2,880/일 (돈 낭비!) |
5개로 줄이면: **\(1,728/일** (288\) 절약, 정확도 0.57로 하락)
⚖️ 3대 트레이드오프 완전 분석
| 요소 | 증가 | 장점 | 단점 | 최적값 |
|---|---|---|---|---|
| 컨텍스트 | 이전쿼리↑ | 정확도↑ | 비용↑, 속도↓ | 10개 |
| 모델 | GPT-4o | 정확도↑ | 비용 3배 | 4o-mini |
| 토큰 | maxTokens↑ | 복잡쿼리 OK | 비용↑ | 500 |
저자 추천: 10개 이전쿼리 + GPT-4o-mini + 500토큰
🧪 프롬프트 최적화 기술 (실제 코드)
저자들이 검증한 효과 입증된 기술들:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// 1. 역할 부여 (정확도 +15%) "You are a SQL expert. Generate a SQL query..." // 2. 테이블 스키마 제공 (정확도 +25%) "- CREATE TABLE customers (CustomerID, Segment...)" // 3. 이전 쿼리 예제 (정확도 +30%) "Recent Queries: SELECT COUNT(*) FROM sales..." // 4. 출력 형식 제한 (실행 가능 SQL 보장) "Only return the SQL query without explanation." |
✅ 초보자 체크리스트 (바로 적용!)
LLM 서비스 만들 때 반드시:
|
1 2 3 4 5 6 7 8 |
✅ [ ] LLM 인터페이스 캡슐화 (제공자 변경 자유) ✅ [ ] 벤치마크 데이터셋 확보 (BIRD 추천) ✅ [ ] 정확도 측정함수 구현 (Overlap Similarity) ✅ [ ] 컨텍스트-정확도-비용 그래프 작성 ✅ [ ] 스위트스팟 찾기 (10개 이전쿼리) ✅ [ ] temperature=0.1 (반복성 확보) ✅ [ ] maxTokens 제한 (악용 방지) |
📌 저스틴의 3대 정리
첫째, LLM = 블랙박스 아님. 과학적 벤치마크로 내부 동작 완벽 파악!
둘째, 컨텍스트 10개가 최적. 더 주면 돈만 쓰고 효과 없음!
셋째, 인터페이스 캡슐화 필수. OpenAI → Claude 1일 만에 변경 가능!
💪 오늘의 실천 과제 (30분)
|
1 2 3 4 5 6 |
1. BIRD 데이터셋 다운로드 (dev.json) 2. 간단 Text-to-SQL 서비스 만들기 3. 0/5/10개 이전쿼리로 정확도 측정 4. 비용-정확도 그래프 그리기 5. 스위트스팟 찾기! |
결과: 자신만의 LLM 최적 설정 확보!
