# 바이브 코딩을 넘어 with Addy Osmani [유튜브 요약] > Clean Markdown view of GeekNews topic #24040. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24040](https://news.hada.io/topic?id=24040) - GeekNews Markdown: [https://news.hada.io/topic/24040.md](https://news.hada.io/topic/24040.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-31T10:22:02+09:00 - Updated: 2025-10-31T10:22:02+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=dHIppEqwi0g) - Points: 55 - Comments: 1 ## Summary 13년간 Chrome 팀을 이끈 **Addy Osmani**가 제시한 메시지는 명확합니다. AI가 코드를 빠르게 써주는 시대에도 **엔지니어링 원칙과 인간의 감독**은 여전히 핵심이라는 것. 그는 **Vibe coding**이 아이디어 탐색에는 유용하지만, 프로덕션 품질을 위해선 **명세 기반 개발, 테스트, 코드 이해**가 필수라고 강조합니다. LLM이 애플리케이션의 70%를 만들어줄 수는 있어도, 나머지 30%의 완성도와 보안, 유지보수성은 결국 **시니어 엔지니어의 비판적 사고와 시스템적 시야**가 결정합니다. AI와 함께 일하되, 그 위에 서서 판단할 수 있는 개발자에게 이 시대의 진짜 레버리지가 생긴다는 점이 인상적입니다. ## Topic Body - Google Chrome 팀에서 13년간 근무한 **엔지니어링 리더 Addy Osmani**가 전문 소프트웨어 엔지니어를 위한 **AI 기반 개발 방법론**을 소개 - **Vibe coding**은 빠른 프로토타이핑에는 유용하지만, **프로덕션 품질 소프트웨어 개발**에는 엔지니어링 원칙과 인간의 감독이 필수적 - AI 도구 활용 시 **명세 기반 개발, 테스트 작성, 코드 이해**를 통해 품질을 담보하고, 모델의 사고 과정을 검토하여 생성된 코드를 완전히 파악해야 함 - LLM은 애플리케이션의 약 **70%까지 빠르게 생성**하지만 나머지 30%의 완성도, 보안, 유지보수성 확보를 위해서는 **시니어 엔지니어의 전문성**이 더욱 중요해짐 - 비동기 백그라운드 에이전트, 병렬 코딩 등 **새로운 개발 워크플로우**가 등장하며, 엔지니어는 비판적 사고와 코드 이해 능력을 유지하면서 AI를 활용하는 **평생 학습자**가 되어야 함 --- ### Vibe Coding vs. AI 보조 엔지니어링의 차이 - **Vibe coding**은 AI와의 창의적 흐름에 완전히 몰입하여, 고수준 프롬프팅에 집중하고 코드 자체는 잊어버리는 방식 - AI 제안을 깊은 검토 없이 수용하고 **빠른 반복 실험**에 집중 - 프로토타입, MVP, 학습 목적으로 유용하며 **속도와 탐색**을 정확성과 유지보수성보다 우선시 - **AI 보조 엔지니어링**은 AI를 강력한 협업자로 활용하되 엔지니어링 원칙을 대체하지 않는 접근법 - AI는 **전체 소프트웨어 개발 생명주기**에서 보일러플레이트, 디버깅, 배포 등을 돕는 force multiplier 역할 - 인간 엔지니어가 아키텍처 설계, 모델 검토, **모든 생성 코드 이해**에 대한 책임을 유지 - 최종 제품의 보안, 확장성, 유지보수성을 보장하는 것은 엔지니어의 몫 - 소프트웨어 엔지니어링 전문성이 높을수록 LLM을 사용한 **결과물의 질이 향상**됨 - 프로덕션 품질 프로그래밍을 위해서는 **다른 사람에게 완전히 설명 가능한 코드**만 리포지토리에 커밋해야 함 ### Addy의 AI 도구 활용 방법 - **명세 기반 개발(Spec-driven development)** 중심 접근 - 빌드할 내용에 대한 명확한 계획 수립이 핵심 - Vibe coding은 개인 도구, 일회용 프로젝트, 아이디어 시각화용으로 활용 - 프로토타입으로 비전을 명확히 한 후, 실제 요구사항을 문서화하여 **LLM의 고품질 결과물** 유도 - **테스트 작성**을 통한 리스크 감소 - 최신 모델도 때로 복잡하거나 잘못된 코드를 생성할 수 있음 - 테스트로 작동을 증명하고 문제 발생 시 **명확한 식별** 가능 - **Chrome DevTools MCP** 활용 - LLM에 브라우저에 대한 "시각"을 제공하여 렌더링, 콘솔 오류, 경고 등을 감지 - 브라우저를 루프에 포함시켜 **피드백 루프 개선** - 새로운 모델, 도구, 플랫폼에 대한 **지속적인 실험**과 팀 간 인사이트 공유 - 심리적 안전성을 조성하여 함께 학습하는 문화 구축 ### Google에서의 AI 도구 관찰 및 학습 - Google의 **검증된 소프트웨어 엔지니어링 원칙**은 AI 시대에도 유효 - 품질과 실사(due diligence)에 대한 관심은 여전히 중요 - **프롬프트 엔지니어링**과 **컨텍스트 엔지니어링**의 중요성 - LLM에서 최상의 결과를 얻기 위한 올바른 "주문(incantations)" 구성 - 컨텍스트 윈도우 최적화로 고품질 결과 확률 증가 - 프로젝트별 설명, 세부사항, 파일, 예제 등 **LLM 학습 데이터에 없는 콘텐츠** 포함 - **AI native 엔지니어**로의 전환 촉진 - 문제 해결 전에 AI에게 먼저 시도하도록 하는 사고방식 훈련 - 평가 벤치마크, RAG vs. 파인튜닝 등 **AI 전문성 구축** - **인간 감독의 중요성** - AI가 코드 작성과 리뷰를 모두 수행하면 실제로 무엇이 배포되는지 **불확실**해짐 - 증가하는 PR 속도로 인해 인간 리뷰가 병목 지점이 되는 현상 발생 - 코드 리뷰 모범 사례는 여전히 진화 중 ### Addy가 선호하는 도구들 - **Klein in VS Code**를 주로 사용 - Cursor, GitHub Copilot도 많은 기능 제공 - 도구들이 보여주는 **사고 과정(thinking log)** 검토 - 솔루션 구축 과정에서 모델의 의사결정과 생성 코드를 확인 - PR 전에 코드를 검토하여 **향후 유지보수 가능성** 확보 - LLM이 문제 해결에 실패할 때 **직접 디버깅**할 수 있는 역량 유지 - 코드 작동 방식을 이해하지 못하면 정글에 던져진 것처럼 느껴짐 - 전문 엔지니어와 일반인의 차이 - 프롬프트만 입력하는 것은 누구나 가능 - **코드 작동 원리 이해**, 모델 실패 시 수정 능력, 회의에서 명확한 설명 능력이 차별화 요소 ### 70% 문제의 본질 - LLM은 작동하는 애플리케이션의 약 **70%를 매우 빠르게** 생성 가능하지만 나머지 30%에서 어려움을 겪음 - **마지막 30%의 구성 요소** - "Two steps back" 패턴: 한 프롬프트가 UI나 기능을 완전히 다시 작성하는 등 잘못된 방향으로 진행 - **숨겨진 유지보수 비용**: 명확하지 않은 명세로 인해 책임을 LLM에 위임하면 수익 감소 - **보안 취약점**: API 키 노출, XSS 문제 등 전체적 사고 부족으로 인한 문제 - Vibe coding으로 만든 **PoC는 프로덕션 배포 전 재작성** 필요 - 실제 사용자 기반을 다루는 코드베이스에서는 보안과 품질이 필수 - **경험 많은 엔지니어**는 마지막 30%를 훨씬 쉽게 완료 - 주니어 엔지니어는 LLM에 계속 재프롬프팅하는 것 외에 다음 단계를 모르는 경우가 많음 - **비판적 사고와 문제 해결** 마인드셋의 중요성 부각 - 코드를 읽고, 시스템을 이해하고, 모든 부분이 어떻게 연결되는지 파악하는 **성실함은 여전히 필수** ### 효율적인 LLM 사용을 위한 전술 - **프로젝트 관리자 마인드셋** 채택 - 작업을 작고 검증 가능한 단위로 분해 - 모든 요구사항을 한 번에 던지면 효과적이지 않음 - 명확한 기대치 설정과 **AI와의 반복 작업** 준비 - **모듈화되고 테스트 가능한 코드** 작성 - 코드 리뷰 시행 등 소프트웨어 엔지니어링 모범 사례는 AI 시대에도 유효 - **입출력 제약 조건 고려**와 충분한 컨텍스트 제공 - 새로운 습관이지만 좋은 결과를 얻을 수 있음 - 인간을 루프에 포함시키는 **성실함 유지**가 성공의 핵심 - LLM에 책임을 넘길수록 문제 발생 위험 증가 ### 자율 에이전트 및 새로운 워크플로우 - **비동기 백그라운드 코딩 에이전트**의 등장 - Jewels, Devin, Codex 등의 도구와 GitHub의 실험 - 백로그 일부를 위임하고 **비동기적으로 구현**되도록 하는 아이디어 - 현재 상태 - **테스트 작성/업데이트**, 라이브러리 버전 마이그레이션 등에는 이미 효과적 - 다크 모드 추가 같은 **작은 변경사항** 위임에 적합 - **관리 과제** - 오케스트라의 지휘자로서 모든 작업을 관리하는 적절한 인터페이스 필요 - 동시에 관리할 수 있는 **현실적인 작업 수** 고려 - 인간의 주의력은 유한하므로 철저한 코드 리뷰를 위해서는 **몇 가지 작업만 동시 처리** 가능 - **Vibe designing**의 진화 - Figma의 MCP를 통해 디자이너와 개발자의 협업 강화 - 디자이너가 비전을 기능적 프로토타입으로 전환하여 **프로덕션화 가능한 코드**에 근접 ### EM과 PM 역할의 변화 - **PM 역할** - 문제 프레이밍, 메트릭, 에이전트 정책에 더 많은 시간 투자 - **EM 역할** - 평가(evals), 안전성 검토, 팀이 AI를 자신 있게 활용할 수 있도록 지원 - **결과에 대한 책임**은 변하지 않음 - **제품 엔지니어링에서 취향(taste)의 중요성** - 누구나 프롬프트로 유사한 기능을 만들 수 있으므로 차별화 요소는 취향 - **주니어 vs. 시니어** - AI가 하한선을 높이지만 **상한선도 함께 상승** - 주니어는 더 빠르게 시작 가능 - **명세 작성, 작업 분해, 시스템 아키텍처 이해, 효과적인 리뷰** 능력을 가진 시니어는 더욱 가치 있어짐 - 마지막 30%는 단순 업무가 아닌 **레버리지** ### 새로운 역할과 개발자 교육의 변화 - **전방 배치 엔지니어(Forward deployed engineers)** 등 새로운 역할 부상 - 고객과 더 긴밀하게 협력하며 AI로 기능을 빠르게 구축하고 요구사항 피드백 - 개발자, PM, 디자이너 역할 간 **경계 모호화** 가능성 - **AI 엔지니어링 교육** - 고등학교와 대학에서 프롬프트 및 컨텍스트 엔지니어링 모범 사례 교육 필요성 - **시스템 설계와 엔지니어링** 사고방식 유지 방안 모색 - **트리오 프로그래밍** - 주니어, 시니어, AI가 함께 작업 - 시니어가 AI 생성 코드를 설명하도록 요청하거나 시스템의 다른 부분과의 **연결 방식** 설명 ### AI 작업 시 비판적 사고의 중요성 - AI 도구 사용 시 **수용의 용이함**으로 인한 비판적 사고력 저하 위험 - 특별히 중요하지 않은 작업에서 Tab/Accept를 눌러 모든 것을 수용하는 경향 - 신뢰가 쌓이면서 **비판적 검토 감소** - **코드 리뷰 병목 현상** - AI 생성 코드의 속도 증가로 인간 리뷰가 병목이 됨 - LGTM(Looks Good To Me) 남발 위험 - **대응 전략** - 특정 기능이나 요일에는 **의도적으로 AI 없이 작업**하여 비판적 사고력 유지 - 모든 주요 LLM 제공업체가 다운되면 어떻게 할지 고려 - **코드 작성 vs. 읽기** - 직접 코드를 입력하면 자체 검토가 이루어지고, 다른 사람이 작성자를 알고 검토 - AI 시대에는 **읽기와 검토가 더 큰 비중** 차지 - **AI를 코드 리뷰에 활용** - AI의 "승인"은 하나의 신호일 뿐 - CI/CD 통과, 테스트 성공 등과 마찬가지로 **품질에 대한 개인적 관점** 여전히 필요 - 여전히 작업의 20-30%는 **AI 없이 수행**하여 두뇌를 계속 사용 ### 학습 도구로서의 LLM - **새로운 코드베이스 이해**를 위한 강력한 도구 - 첫 번째 작업이 가치 제공을 위해 새 기능을 프롬프트하는 것이 아니라 **코드베이스 작동 방식 학습**이어야 함 - **프로그래밍 개념, 프레임워크, 아키텍처 패턴** 이해에 유용 - **다른 언어로 작성된 코드베이스** 간 기능 이전 시 필수적 - **팀 문화 조성** - AI를 학습 도구로 사용하는 것이 괜찮다는 인식 확산 - 실험, 모범 사례 공유를 정기적으로 장려 - **신입 사원의 빠른 온보딩** - AI 도구가 24/7 신뢰할 수 있는 멘토 역할 - 시니어 엔지니어에게 하루 종일 질문하는 것보다 부담 없이 학습 가능 - **Claude Code의 학습 모드** - 설명 모드와 학습 모드 제공 - 일시 정지하고 사용자에게 특정 부분을 직접 수행하도록 요청 ### AI 도구의 진화와 기대치 설정 - **도구 진화의 역사** - 템플릿 다운로드 → CLI와 스캐폴딩 → AI 기반 부트스트래핑 - 각 단계마다 개발자 경험이 조금씩 개선 - **학습 데이터의 한계 인식** - GitHub의 permissive 라이선스 코드나 오픈 웹의 패턴 기반 - **최저 공통분모(lowest common denominator)** 패턴 반영 가능성 - 최고 수준의 보안, 성능, 접근성은 보장되지 않음 - **Stack Overflow 복사-붙여넣기와의 유사성** - 과거: 이메일 검증 정규식 같은 것을 Stack Overflow에서 복사 - 현재: LLM이 유사한 패턴 생성하지만 **엣지 케이스나 보안 문제** 가능 - **제3자 라이브러리 vs. 직접 구현** - LLM으로 작은 버전을 직접 구현할 수 있지만 **유지보수 책임** 부담 - 라이브러리는 보안 문제 등에 대한 **중앙 집중식 수정** 가능 - 각 선택의 **트레이드오프** 고려 필요 - **낮은 기대치와 높은 통제력 유지**가 핵심 ### 우수한 소프트웨어 엔지니어의 정의 변화 - **평생 학습자(Lifelong learner)** 중요성은 불변 - 프레임워크, 도구, 산업이 진화해도 새로운 것을 배우려는 개방성 필수 - **성장 마인드셋(Growth mindset)** - 새로운 모델, 도구, 플랫폼을 기꺼이 시도 - 실패를 통한 학습과 제약 조건 이해 - **리더십의 역할** - 리더가 학습에 개방적임을 보여주면 팀의 **심리적 안전성** 조성 - Addy는 매주 월요일 **팀 내부 뉴스레터** 작성 - 개인 프로젝트, 글, 생각 공유 - AI 및 AI 엔지니어링의 중요한 업데이트 선별 - 다른 임원들도 유용하게 활용 - **정보 과부하 시대의 큐레이션** - 소셜 네트워크에서 매 시간 근본적 변화가 발생하는 것처럼 느껴짐 - 리더가 **실제로 중요한 것**을 선별하여 팀에 안내 - **기술력 유지** - 논문, 백서, 블로그, 비디오, 강의 등을 지속적으로 읽고 시청 - 팀이 어디에 시간을 투자해야 할지 가이드 - **제품 개발과의 연결** - 코딩 워크플로우 개선 작업이 **제품 고객 경험 개선**에도 기여 ### 즐겨 사용하는 도구와 추천 사항 - **즐겨 사용하는 프로그래밍 언어: JavaScript** - 개인적 선호보다는 **누구나 웹에 빌드하고 배포**할 수 있는 개방성 때문 - 게이트키퍼 없이 해방감 제공 - **현재 가장 좋아하는 도구: Bolt** - Vibe coding 스캐폴딩 도구 - 최근 커스텀 에이전트 지원 추가 (Claude Code 등 사용 가능) - 고품질 결과물과 훌륭한 디자인 - Supabase, 인증 제공업체 등 **통합 자동화** 기능 - 설정 마찰 제거에 초점 - **추천 도서** - "The Software Engineer's Guidebook" - "AI Engineering" by Chip Huyen - AI 엔지니어링의 **기초적 측면** 학습을 위한 책 ## Comments ### Comment 45690 - Author: riddler - Created: 2025-10-31T11:18:51+09:00 - Points: 1 같은 제목의 책은 11월에 출간된다고 합니다~ https://x.com/TeeDDub/status/1983150672205041823