Vibe Engineering – My AI Smarteasy 사용자 정의 코파일럿 에이전트 일타 저스틴과 책 읽기
1강. AI 코딩, 혹시 사상누각을 짓고 계신가요?
안녕하세요, 여러분! 일타 강사 저스틴입니다! 😊
요즘 AI 코딩 도구 정말 핫 하죠? 챗GPT나 커서 같은 도구로 코드를 뚝딱 만들어내면 기분이 정말 짜릿합니다.
하지만 여러분! 그 느낌에만 취해 있다면 정말 위험할 수 있어요. 오늘은 우리가 왜 Vibe Coding에서 벗어나 진짜 Engineering을 해야 하는지 알려드릴게요!
🎯 사상누각 위에 집을 짓지 마세요
여러분, 사상누각이라는 말 들어보셨나요? 모래 위에 지은 집이라는 뜻이죠.
AI가 순식간에 만들어준 코드가 당장은 잘 돌아가는 것처럼 보일 수 있어요. 하지만 그 원리를 100퍼센트 이해하지 못하고 그대로 쓴다면 어떨까요?
그건 바로 모래 위에 건물을 올리는 것과 똑같아요. 나중에 유지보수 할 때 와르르 무너질 수 있거든요!
💸 보이지 않는 빚, 신뢰 부채
여기서 아주 무서운 개념이 하나 등장합니다. 바로 신뢰 부채입니다.
개발자가 AI 코드를 검증 없이 그냥 복사해서 붙여 넣으면 당장은 일이 빨리 끝난 것 같죠? 하지만 그건 사실 미래의 시간을 대출 받은 거예요.
나중에 시니어 개발자가 그 코드에 숨겨진 버그를 잡느라 며칠 밤을 새우게 됩니다. 이게 바로 갚아야 할 빚이라는 사실! 꼭 기억하세요.
📉 70퍼센트의 함정
구글의 전문가들은 70퍼센트의 문제라고 부르는 현상을 발견했어요.
AI는 뻔하고 쉬운 70퍼센트의 코드는 정말 기가 막히게 잘 짭니다. 하지만 나머지 30퍼센트가 문제예요.
보안이나 예외 처리 같은 중요하고 디테일 한 부분에서 AI는 자주 실수합니다. ISBN 검증 코드를 짜라고 하면 형식을 맞추는 건 잘하지만 하이픈이나 공백 처리를 빼 먹는 식이죠.
🛠 해결책은 실행 가능한 사양
그럼 우리는 어떻게 해야 할까요? AI를 버려야 할까요? 절대 아닙니다!
우리는 AI에게 그냥 “코드 짜줘”라고 하면 안 됩니다. 대신 실행 가능한 사양을 줘야 해요.
이게 뭐냐고요? 바로 테스트 코드입니다!
“이 코드가 성공했다는 것을 증명할 테스트 3개를 먼저 통과해라”라고 계약서를 내미는 거예요.
2강. AI는 독심술사가 아닙니다! (맥락 엔지니어링)
여러분, 혹시 AI한테 “이거 에러 좀 고쳐줘”라고 코드 한 조각만 툭 던져본 적 있으신가요?
그때 AI가 엉뚱한 라이브러리를 가져오거나, 없는 함수를 만들어내는 환각을 경험해보셨죠?
오늘은 AI가 왜 그런 실수를 하는지, 그리고 AI의 뇌를 200퍼센트 활용하는 컨텍스트 엔지니어링에 대해 알려드릴게요!
🗑 쓰레기를 넣으면 쓰레기가 나옵니다 (GIGO)
컴퓨터 과학의 명언이 있죠. Garbage In, Garbage Out!
AI는 여러분의 마음을 읽는 독심술사가 아닙니다. 여러분이 로그인 함수 딱 하나만 복사해서 주면, AI는 그 코드가 어떤 데이터베이스를 쓰는지, 어떤 암호화 방식을 쓰는지 전혀 모릅니다.
이런 상태를 컨텍스트 진공이라고 불러요.
정보가 없으니 AI는 그럴듯한 거짓말을 지어내기 시작합니다. 이게 바로 여러분이 겪은 실패의 진짜 원인이에요!
🔗 AI에게 USB를 꽂아주세요 (MCP)
그럼 어떻게 해야 할까요? 일일이 코드를 복사해서 붙여넣어야 할까요? 아니요, 그건 너무 지루한 일이죠.
여기서 등장하는 구세주가 바로 MCP입니다. Model Context Protocol의 약자예요.
쉽게 말해 AI에게 여러분의 프로젝트, 피그마 디자인, 깃허브 저장소를 직접 연결해주는 USB 케이블 같은 겁니다.
이제 AI는 “로그인 버튼 만들어줘”라는 말에 상상해서 그리는 게 아니라, 피그마에 있는 디자인 토큰을 직접 읽어와서 정확한 색상 코드를 씁니다. 이게 바로 진짜 엔지니어링이죠!
🥪 중간 실종 사건과 샌드위치 기법
“그럼 프로젝트 파일 전부 다 주면 되겠네?”라고 생각하셨나요? 땡! 틀렸습니다.
AI는 한 번에 너무 많은 정보를 주면, 글의 중간에 있는 내용을 까먹어버려요. 이걸 중간 실종 현상이라고 합니다. 마치 시험 전날 벼락치기 할 때 중간 단원은 기억 안 나는 것과 똑같죠.
그래서 우리는 샌드위치 기법을 써야 합니다.
가장 중요한 핵심 지시는 맨 처음과 맨 마지막에 배치하세요. AI의 주의력을 꽉 잡아둘 수 있습니다.
3강. 코끼리를 냉장고에 넣는 법 (레거시 대탈출)
여러분, 회사에 가면 10년 묵은 레거시 코드 꼭 하나씩 있죠? 손대면 터질 것 같고, 도망가고 싶은 그 녀석 말이에요.
AI가 나왔으니 “이거 전부 최신 코드로 바꿔줘!”라고 한방에 시키고 싶으실 겁니다. 하지만 그랬다간 대참사가 일어납니다.
오늘은 거대한 레거시 프로젝트를 AI와 함께 안전하게 탈출하는 하이브리드 전략을 알려드릴게요!
🐘 코끼리는 한 입 크기로 드세요
AI에게 “이 프로젝트 전체를 리팩토링해줘”라고 하면 어떻게 될까요? AI는 그럴듯한 코드를 뱉어내지만, 여러분은 그 코드를 절대 리뷰할 수 없습니다.
너무 많이 바뀌어서 어디서부터 검증해야 할지 모르거든요. 이걸 리뷰 불가능 상태라고 합니다.
핵심은 스윗 스팟을 찾는 겁니다.
너무 작게 바꾸면 AI를 쓰는 의미가 없고, 너무 크게 바꾸면 사람이 검증을 못 해요. 딱 한 번에 검증 가능한 만큼만 바꾸는 게 기술입니다.
🏠 집을 부수지 말고 옆에 새로 지으세요
레거시를 고칠 때 가장 좋은 방법은 하이브리드 접근법입니다.
기존 코드를 그 자리에서 고치다가 망가지면 되돌릴 수 없죠? 그렇다고 새 프로젝트를 만들자니 설정하다 지치고요.
그래서 우리는 복사본을 이용합니다.
새 리포지토리에 기존 코드를 그대로 복사해두고, 거기서 AI와 함께 마음껏 실험하는 거예요. 원본은 안전하게 두고 말이죠!
🧹 AI의 기억을 지워주세요 (컨텍스트 클리닝)
이게 정말 중요한 꿀팁입니다! 🍯
데이터베이스 코드를 다 고치고 나서 UI 코드를 고칠 때, AI에게 “이제 데이터베이스 얘기는 잊어버려”라고 해야 합니다.
이걸 컨텍스트 클리닝이라고 해요.
AI가 이전 작업의 기억을 계속 가지고 있으면, UI를 짤 때 자꾸 데이터베이스 로직을 섞으려고 하거나 헷갈려 합니다.
한 단계가 끝나면 과감하게 대화창을 새로 여세요. AI의 뇌를 맑게 해주는 겁니다!
💪 오늘의 정리
첫째, AI에게 한 번에 너무 많은 수정을 시키지 말고 스윗 스팟을 찾으세요
둘째, 원본을 건드리지 말고 하이브리드 방식으로 안전하게 실험하세요
셋째, 작업 단계가 바뀔 때마다 컨텍스트 클리닝으로 AI를 리셋하세요
4강. 느낌적인 느낌은 그만! 과학수사대 출동! 🕵️♂️
여러분, AI가 짜준 코드를 보고 “오, 뭔가 그럴듯한데?” 하고 그냥 넘어가신 적 있나요?
이걸 Vibe Coding이라고 하죠. 그냥 느낌으로 코딩하는 겁니다. 하지만 프로는 느낌으로 일하지 않습니다.
특히 AI는 매번 다른 답을 내놓는 비결정적인 친구예요. 오늘은 이 변덕쟁이 AI를 과학적으로 검증하고, 비용까지 아끼는 비법을 알려드릴게요!
📦 AI 모델과 결혼하지 마세요 (캡슐화)
여러분, 지금 챗GPT API를 코드 곳곳에 직접 박아두셨나요? 그럼 나중에 큰일 납니다!
만약 내일 당장 더 싸고 좋은 모델이 나오면요? 일일이 다 뜯어고칠 건가요?
그래서 우리는 캡슐화 전략을 씁니다.
“AI야, SQL 쿼리 좀 짜줘”라는 요청을 인터페이스 뒤로 숨기는 거예요.
이렇게 하면 나중에 GPT-4에서 Llama 3로 갈아타도, 우리 서비스 코드는 단 한 줄도 안 고쳐도 됩니다. AI 모델을 건전지 갈아 끼우듯 쉽게 교체하는 거죠!
📏 느낌 대신 숫자로 말해요 (유사도 검증)
AI가 SQL을 짜줬는데, 이게 진짜 정답일까요? 매번 DB에 돌려볼 순 없잖아요.
이때 필요한 게 과학적 벤치마크입니다.
우리는 중첩 유사도(Overlap Similarity)라는 걸 쓸 거예요.
어렵지 않아요! 정답 쿼리에 있는 핵심 단어(테이블 이름, 컬럼명)가 AI가 만든 쿼리에도 들어있는지 확인하는 겁니다.
“느낌상 맞는 것 같아요”라는 말은 이제 그만! “유사도가 0.9입니다“라고 숫자로 증명하세요!
💸 돈 낭비 막는 스윗 스팟 찾기
“AI한테 예시를 많이 보여주면 더 똑똑해지겠지?”라고 생각하시죠? 맞습니다. 이걸 Few-shot이라고 해요.
하지만 예시를 무작정 많이 주면 어떻게 될까요?
실험을 해봤더니, 예시 10개를 줬을 때 성능이 확 오르다가, 20개를 주면 성능은 제자리인데 돈(토큰 비용)만 40퍼센트 더 나갑니다!
이걸 수확 체감의 법칙이라고 하죠.
우리는 그래프를 그려서 정확도는 높고 비용은 낮은 스윗 스팟(Sweet Spot)을 찾아야 합니다. 무조건 많이 주는 게 능사가 아니에요!
5강. AI도 ‘성급한 최적화’의 병에 걸립니다! (성능 튜닝)
“AI야, 이 코드 성능 좀 높여줘”라고 부탁해 보신 적 있나요?
그럼 AI는 십중팔구 병렬 처리니 멀티 스레드니 하면서 아주 복잡하고 있어 보이는 코드를 짜줍니다.
그런데 여러분, 그게 진짜 빠를까요? 아니요! 오히려 더 느려질 수도 있습니다.
오늘은 AI가 저지르는 성급한 최적화의 함정을 피하고, 진짜 필요한 곳만 골라내는 Vibe Performance Engineering의 핵심을 알려드릴게요!
🛑 어둠 속에서 총 쏘지 마세요 (성급한 최적화)
개발자들 사이에서 전설처럼 내려오는 말이 있죠. “성급한 최적화는 만악의 근원이다.”
데이터가 고작 10개뿐인데 AI에게 “최적화해줘”라고 하면, AI는 모든 CPU 코어를 다 쓰는 병렬 스트림을 제안합니다.
결과는요? 스레드를 관리하느라 오히려 단일 스레드보다 더 느려집니다!
데이터가 얼마나 들어올지 모르는 상태에서 최적화하는 건 어둠 속에서 총을 쏘는 것과 같아요. 절대 맞지 않습니다.
🔥 핫패스(Hot-path)를 찾으세요
우리 시스템의 모든 코드가 다 중요할까요? 천만의 말씀!
파레토 법칙 들어보셨죠? 전체 트래픽의 80퍼센트 이상은 특정 20퍼센트의 코드가 담당합니다. 이걸 바로 핫패스라고 부릅니다.
하루에 한 번 호출되는 ‘오늘의 단어’ API를 0.1초 줄이는 건 아무 의미 없어요.
하지만 초당 100번 호출되는 ‘로그인’ API를 0.01초만 줄여도 전체 서버 비용이 확 줄어듭니다! AI에게 일을 시킬 땐 바로 이 핫패스부터 찾아서 던져줘야 합니다.
🔢 AI에게 숫자(N)를 알려주세요
그럼 AI가 헛다리 짚지 않게 하려면 어떻게 해야 할까요?
정답은 데이터의 규모(N)를 알려주는 겁니다!
“이 리스트에는 최대 1만 개의 데이터만 들어올 거야”라고 말해보세요.
그럼 AI는 복잡한 병렬 처리 코드를 싹 지우고, 대신 아주 단순하지만 강력한 해시맵(HashMap)을 제안할 겁니다.
AI의 추측을 여러분의 데이터로 대체하는 순간, 진짜 엔지니어링이 시작되는 거죠!
💾 미리 다 읽을까? 나중에 읽을까? (Eager vs Lazy)
성능 개선을 위해 AI는 종종 캐싱을 제안합니다. 데이터를 메모리에 저장해두는 거죠.
이때 AI는 주로 Eager Loading을 좋아합니다. 앱이 켜질 때 데이터를 몽땅 다 읽어오는 방식이죠. 빠르긴 한데, 데이터가 수백 기가바이트라면요? 메모리가 터져서 서버가 죽습니다!
반대로 Lazy Loading은 필요할 때만 읽어옵니다.
이 트레이드오프는 AI가 결정할 수 없어요. 여러분이 “데이터가 크니까 필요할 때만 읽어와”라고 명확히 지시해야 합니다.
6강. 코더(Coder)에서 설계자(Architect)로 진화하라! (완강) 🎓
드디어 Vibe Engineering 시리즈의 마지막 강의입니다! 여기까지 오신 여러분, 정말 대단해요! 👏👏
1강부터 5강까지 우리는 AI가 주는 ‘속도의 환상’을 깨고, 진짜 ‘공학적 규율’을 세우는 법을 배웠습니다.
오늘은 이 모든 여정을 하나로 묶어, 여러분이 AI 시대에 어떤 엔지니어가 되어야 하는지, 그 마지막 열쇠를 드리겠습니다!
🏗️ 코더(Coder)의 시대는 끝났습니다
여러분, 혹시 아직도 타자 치는 속도가 개발자의 실력이라고 생각하시나요?
이제 코드를 짜는 건 AI가 더 빠릅니다. 70퍼센트의 뻔한 코드는 AI에게 맡기세요.
대신 여러분은 설계자(Architect)이자 검증자(Verifier)가 되어야 합니다.
“어떻게 구현할까?”를 고민하는 시간보다, “무엇을 만들 것이며, 그것이 올바른지 어떻게 증명할까?”를 고민하는 시간이 훨씬 더 중요해졌습니다.
🔄 황금 루프: Vibe → Specify → Verify → Own
우리가 배웠던 모든 기술은 결국 하나의 루프로 이어집니다. 이 황금 루프를 꼭 기억하세요!
- Vibe (탐색): 처음엔 AI와 대화하며 아이디어를 탐색하세요. (브레인스토밍)
- Specify (명세): “느낌”을 멈추고, **실행 가능한 사양(테스트 코드)**으로 계약서를 쓰세요. (1강)
- Verify (검증): AI가 짜온 코드를 유사도 점수나 벤치마크로 냉정하게 평가하세요. (4, 5강)
- Own (소유): 검증된 코드를 내 것으로 만드세요. 리팩토링하고 문서화해서 완전히 이해해야 합니다. (2, 3강)
이 루프를 도는 사람만이 AI의 주인이 될 수 있습니다!
🧠 AI는 마법이 아니라 ‘공학’입니다
AI 코딩 도구는 요술봉이 아닙니다. 아주 강력하지만, 다루기 까다로운 엔진일 뿐이죠.
우리가 배웠던 맥락 엔지니어링(Context Engineering) 기억나시죠?
엔진에 좋은 연료(정확한 데이터, 트래픽 정보)를 넣지 않으면, 엔진은 고장 나거나 엉뚱한 곳으로 폭주합니다.
“AI가 알아서 해주겠지”라는 막연한 믿음을 버리세요.
대신 “이 AI가 내 의도대로 작동하게 하려면 어떤 제약을 줘야 할까?”를 끊임없이 질문하세요.
💪 오늘의 정리 (최종)
첫째, 코드를 짜는 노동자가 아니라, 의도를 정의하는 설계자가 되세요
둘째, 탐색에서 검증으로 이어지는 **황금 루프(Specify → Verify → Own)**를 실천하세요
셋째, AI는 마법이 아닙니다. 철저한 공학적 규율로 통제하세요
💪 마지막 실천 과제
지금 여러분의 프로젝트에서 가장 골치 아픈 레거시 모듈 하나를 정하세요.
그리고 오늘 배운 황금 루프를 적용해, AI와 함께 완벽하게 리팩토링 해보세요!
여러분은 이제 Vibe Engineer입니다. AI라는 거인의 어깨 위에 당당히 서시길 바랍니다! 감사합니다! 🙇♂️
