Vibe 코딩은 저품질 작업에 대한 변명이 될 수 없어요

(addyo.substack.com)

4P by GN⁺ 4시간전 | ★ favorite | 댓글 1개

AI 기반 바이브 코딩은 혁신적이지만, 품질 없는 속도는 위험하다는 경고의 글

"더 빨리 움직이고, 더 많이 망가뜨려라"
"vibe coding, 두 명의 엔지니어가 50명의 기술 부채를 만들어낼 수 있는 방식"

이 실리콘밸리의 오래된 슬로건을 비튼 표현은 최근 엔지니어링 커뮤니티에서 “vibe coding”이라는 개념으로 회자되고 있음
AI 기반 개발이 소프트웨어 제작 방식을 혁신하고 있는 것은 사실이지만, 그렇다고 해서 엄격함, 리뷰, 장인정신을 버릴 수 있는 면허는 아님
"vibe coding"은 낮은 품질의 작업을 정당화하는 핑계가 될 수 없음

장점을 인정하자면, AI 보조 코딩은 게임 체인저가 될 수 있음
새로운 프로그래머나 비전문가의 진입 장벽을 낮추고, 그들이 필요를 설명하는 것만으로 작동하는 소프트웨어를 만들어낼 수 있게 함
이는 창의력을 해방시키며, 더 많은 사람들이 자신의 문제를 맞춤형 소프트웨어로 직접 해결할 수 있게 함
이러한 흐름은 퍼스널 소프트웨어의 언번들링(기성 앱 대신 소규모 AI 기반 도구 사용)이라는 트렌드의 일부로 간주됨
숙련된 엔지니어들도 이득을 볼 수 있음

하지만 경험 많은 엔지니어라면 누구나 말하듯, 속도는 그 끝에서 바퀴가 빠진다면 아무 의미가 없음
그리고 바로 여기에서 균열이 보이기 시작함 — vibe와 실제 현실 사이의 간극, 즉 유지보수 가능하고 견고한 소프트웨어를 구축하는 데 따르는 현실의 차이

불편한 진실: 품질은 자동으로 따라오지 않음

hype는 크지만, vibe coding에 대한 베테랑 개발자들의 회의도 만만치 않음
핵심 비판은 이렇다: AI가 빠르게 코드를 뱉어낸다고 해서, 그 코드가 좋은 것은 아니다
사실, AI가 생성한 코드를 그대로 믿고 사용하는 것은 꽤 위험할 수 있음
“두 명의 엔지니어가 50명 분량의 기술 부채를 만든다”는 농담은 완전히 농담만은 아님
검토되지 않은 AI 코드가 기술 부채를 대규모로 확대시킬 수 있음
→ 이 부채는 코드를 취약하고 유지보수하기 어렵게 만들며, 장기적으로 큰 비용을 초래함

vibe coding으로 만들어진 프로젝트는 종종 겉보기에는 훌륭해 보임 ("잘 작동하네, 배포하자!")
하지만 실제로는 다음과 같은 위험 요소를 숨기고 있음:
- 에러 처리가 없음
- 성능이 떨어짐
- 보안 방식이 불안정함
- 논리 구조가 약하고 깨지기 쉬움
이런 프로젝트는 모래 위에 지어진 구조물 같고,
내가 부르는 표현으로는 “카드로 만든 집(house of cards code)” 임 —
겉보기에는 완성된 듯하지만, 현실적인 압력에는 쉽게 무너짐
주니어 개발자의 첫 대형 기능이 거의 작동하지만 예상 못 한 입력 하나로 바로 망가지는 장면을 본 적 있다면, 그 느낌을 알 것임
AI는 많은 양의 코드를 빠르게 만들어낼 수는 있지만, 양이 질을 의미하지는 않음

"AI는 팀에 합류한 매우 열정적인 주니어 개발자 같은 존재다"
→ 이 개념은 Forrest Brazeal의 일러스트를 통해 잘 설명됨

이 위험은 단순한 가설이 아님, 실제 유지보수 측면에서도 문제는 현실적임
AI가 만들어낸 모듈이 지나치게 복잡하거나 이해하기 어려울 경우, 누가 유지보수를 담당할 것인가?
심지어 처음 작성한 개발자조차도 AI가 만든 코드를 완전히 이해하지 못한다면,
그 코드는 향후 수정이나 확장에 있어 악몽이 될 수 있음

보안은 또 다른 커다란 문제임
AI는 겉보기에는 잘 작동하는 코드를 만들 수 있지만, 그 안에는 SQL 인젝션 같은 치명적인 취약점이 숨어 있을 수 있음
혹은, 에러 처리가 부실하게 되어 있을 가능성도 있음
이러한 문제가 철저한 리뷰 없이 프로덕션에 반영된다면 실제 사고로 이어질 수 있음

또 하나의 문제는 프롬프트 과적합(overfitting to the prompt) 임
→ AI는 당신이 요청한 대로 정확히 수행하지만, 그게 진짜로 필요한 것과는 다를 수 있음
인간 개발자는 구현하면서 설계의 오류나 오해를 발견하고 이를 수정함
반면, AI는 이런 오해를 전혀 인지하지 못하고, 사람이 이를 발견해 고치지 않으면 문제는 방치됨

물론, 이 모든 것이 AI가 좋은 코드를 절대 못 쓴다는 뜻은 아님 —
AI는 때때로 훌륭한 코드를 만들어냄
하지만 그 코드를 실제로 사용해도 되는지를 판단하려면, 다음 세 가지가 반드시 필요함:
- 맥락(context)
- 비판적 검토(scrutiny)
- 경험과 전문성(expertise)

2025년 현재, 우리가 사용하는 AI는 열정은 넘치지만 경험이 부족한 어시스턴트와 같음
1년 차 신입 개발자에게 아무런 감독 없이 전체 시스템 설계를 맡기지 않는 것처럼,
AI의 코드도 검토 없이 받아들이면 안 됨
“AI 매직”에 대한 기대는 이제 소프트웨어 엔지니어링의 현실과 조화를 이루어야 함

그럼 어떻게 균형을 잡을 것인가?
중요한 건 vibe coding을 완전히 배척할 필요는 없다는 것
vibe coding은 때로 매우 유용할 수 있음
하지만 중요한 건 훈련된 방식으로 통합하는 것 — 즉, AI를 제한이 명확한 도구로 보는 시각
이는 곧, 사람이 루프 안에 있어야 하며, 우리가 가진 품질 기준과 엔지니어링 원칙을 지키는 방식으로 AI를 사용하는 것

AI는 대체자가 아니라 인턴입니다 (사람이 루프 안에 있어야 함)

vibe coding을 효과적으로 활용하려면 AI를 ‘매우 빠르지만 미숙한 팀의 인턴 개발자’로 대하라는 마인드셋 전환이 필요함
즉, 당신 — 시니어 엔지니어나 팀 리드 — 가 여전히 결과물에 대한 최종 책임자임
AI가 초안을 빠르게 뽑아줄 수는 있지만, 비판적인 시각으로 리뷰하고, 수정 및 품질 기준 충족 여부를 확인해야 함

숙련된 개발자들은 이 과정을 직관적으로 따름
AI가 코드를 제안했을 때, “Accept”를 누르고 바로 넘어가는 것이 아니라 아래와 같이 대응함:
- AI가 작성한 코드를 먼저 읽고 이해함 — 마치 주니어 개발자가 작성한 코드처럼 대함
- 코드가 단일 블록이나 난잡할 경우 모듈화 및 리팩터링 — 더 작고 명확한 단위로 쪼개는 작업 수행
- 누락된 예외 처리나 엣지 케이스를 직접 추가 — null 체크, 입력 검증 등은 AI가 자주 빠뜨림
- 느슨한 타입이나 불완전한 추상화를 강화 — 암묵적 가정을 명시적 계약으로 전환
- AI가 선택한 아키텍처나 방식이 비효율적인지 평가 — 예: 브루트포스 처리, 글로벌 상태 도입 등
- 테스트 작성 또는 수동 테스트 수행 — AI가 유닛 테스트를 생성했다면, 그 테스트가 유효한지도 반드시 검토

이 모든 과정을 통해 AI가 만든 코드에 엔지니어링의 통찰(wisdom) 을 주입하게 됨
이 조합은 매우 강력할 수 있음 — AI는 속도를 제공하고, 사람은 신뢰성을 보장함
실제로 연구 및 현업 경험에 따르면, 시니어 개발자가 주니어보다 AI 코딩 도구에서 더 큰 가치를 얻음
그 이유는 시니어는 AI의 출력을 바르게 이끌고, 오류를 고칠 수 있는 지식과 경험이 있기 때문임
반면, 주니어는 AI를 절대적인 권위처럼 잘못 믿을 위험이 큼

따라서 중요한 규칙이 하나 생김:
→ AI가 작성한 코드는 반드시 리뷰 후 반영할 것
신입 개발자의 PR을 검토하듯, 한 줄 한 줄 읽고 완전히 이해한 뒤에만 머지해야 함
AI가 더 똑똑하다고 전제하지 마라 — 대부분의 경우 그렇지 않음
이해가 안 되는 부분은:
- 프롬프트를 다시 다듬어 명확히 요청하거나
- 직접 해당 코드를 다시 작성하는 것이 바람직함
AI의 출력은 ‘초안’일 뿐이며 반드시 리뷰를 거쳐야 함
팀 개발 환경이라면:
- 누군가가 AI를 이용해 코드를 만들었다면,
- 그 코드에 대해 리뷰에서 직접 설명하고 방어할 수 있어야 함
- “그냥 작동하니까요”는 통하지 않음 — 사람이 이해하고 유지보수할 수 있어야 진짜 코드임

또 하나의 모범 사례: 설계는 사람이, 구현은 AI가
즉, AI는 CRUD API 같은 이미 정의된 작업을 빠르게 구현하는 데 활용
반면, “확장 가능한 마이크로서비스 아키텍처를 설계해줘” 같은 요청은 사람이 해야 함
고수준의 설계 및 핵심 의사결정은 사람의 몫으로 남겨야 함
요약하면: AI에게는 단순 반복 작업(grunt work)을, 사람에게는 사고와 판단(brain work)을 맡기자

커뮤니케이션과 문서화도 매우 중요해짐
복잡한 알고리즘이나 생소한 라이브러리를 AI에게 요청했다면,
- 그 선택의 이유와 의도를 꼭 문서화해야 함
- 미래의 유지보수자 또는 미래의 나 자신이 그 코드를 왜 그 방식으로 만들었는지 알 수 있어야 함
몇몇 팀들은 중요한 AI 코드 생성 시 사용한 프롬프트 자체를 기록하기도 함
→ 디버깅 시 AI와의 “대화 내역”을 참조할 수 있어 유용함

결론적으로, 사람의 개입은 선택사항이 아닌 필수사항임
사람이 빠진 채 AI 코드만 사용하는 건, 소프트웨어 품질에 주사위를 던지는 일
AI가 시니어 엔지니어의 전체적인 이해력을 대체할 수 있는 시대는 아직 아님
vibe coding은 파트너십이어야 함 —
→ AI는 속도를 낼 수 있고, 사람은 그 속도에 안전벨트를 채워주는 역할

고품질 vibe coding을 위한 실전 규칙

이제까지의 논의를 실행 가능한 규칙과 베스트 프랙티스로 정리해보자
이것은 새로운 시대의 “빠르게 움직이되, 모든 걸 망치진 말자” 핸드북이라 할 수 있음
vibe coding을 하면서도 품질을 지키기 위한 가드레일 역할을 하는 규칙들임

Rule 1: Always Review AI-Generated Code / AI 코드 반드시 리뷰하기
- 예외 없음. AI가 작성한 모든 코드는 주니어 개발자가 작성한 코드처럼 리뷰해야 함
- 개별 리뷰이든 동료 리뷰이든 반드시 수행
- Copilot, ChatGPT, Cursor 등 어떤 AI라도 마찬가지
- 리뷰할 시간이 없다면, 그 코드를 쓸 시간도 없는 것
- 리뷰 없이 AI 코드를 머지하는 건 리스크를 그대로 끌어안는 것과 같음
Rule 2: Establish Coding Standards and Follow Them / 코딩 스타일과 기준을 설정하고 준수할 것
- AI는 학습한 코드 스타일을 그대로 반영하므로, 일관된 팀 기준이 없다면 품질이 들쭉날쭉해짐
- 팀의 스타일 가이드, 아키텍처 패턴, 코딩 규칙을 명확히 정의해야 함
- 예: “모든 함수에는 JSDoc과 유닛 테스트가 있어야 한다” → AI가 생성한 코드도 마찬가지로 적용
- 계층 구조나 레이어드 아키텍처를 사용하는 프로젝트에서,
  AI가 UI 코드 안에 DB 호출을 넣지 않도록 리팩터링 필수
- 흔한 AI 실수(ex: 복잡한 함수, deprecated API 사용 등)를 잡는 lint 또는 정적 분석 룰 도입 추천
Rule 3: Use AI for Acceleration, Not Autopilot / AI는 가속기이지 자동 조종 장치가 아님
- vibe coding은 잘 알고 있는 작업을 빠르게 처리하는 용도로 사용해야 함
- 좋은 활용 예:
  - 보일러플레이트 생성
  - 컴포넌트 스캐폴딩
  - 언어 변환
  - 간단한 알고리즘 뼈대 작성
- 위험한 사용 예:
  - 애매한 설명으로 모듈 전체를 설계하게 하기
  - 잘 모르는 도메인에 코드 생성 시도
- 코드가 영구적으로 남을 예정이라면, 반드시 vibe 모드에서 engineering 모드로 전환 필요
Rule 4: Test, Test, Test / 테스트는 무조건 해야 한다
- AI가 코드를 생성했다고 해서 자동으로 정답이 되는 건 아님
- 모든 주요 경로에 대해 테스트 작성 필수
- AI가 테스트도 만들어줬다면, 그 테스트가 실제로 유효한지도 검토 필요
- 특히 UI 기능이나 유저 입력이 많은 부분은 직접 클릭, 비정상 입력 테스트 필수
- vibe-coded 앱은 해피 패스만 잘 작동하고, 예외 입력에 취약한 경우가 많음
Rule 5: Iterate and Refine / 반복하고 다듬기
- AI가 처음 준 결과물이 만족스럽지 않다면, 그냥 넘어가지 말고 다시 시도하거나 리팩터링
- vibe coding은 대화 기반의 반복적 프로세스임
- 예:
  - “이 코드 더 간결하게 해줘”
  - “작은 함수들로 나눠줘” 등 프롬프트 재조정
- 또는 직접 리팩터링 → 수정 포인트 → 다시 프롬프트 → 반복
- AI와의 사이클 사용 전략이 효과적
Rule 6: Know When to Say No / 거절할 줄 알아야 함
- vibe coding이 항상 최선은 아님
- 중요한 설계나 보안이 필요한 상황에선 직접 작성하는 것이 낫다
- 예:
  - 보안 관련 모듈은 직접 설계하고, 일부만 AI 활용
  - 단순한 문제에 대해 AI가 복잡하게 답할 경우, 직접 짜는 게 더 빠름
- AI가 문제를 제대로 해결하지 못할 때는 고집하지 말고 수동 모드로 전환할 것
- "AI가 해줬으니까"는 내가 내 코드를 이해하지 못해도 된다는 핑계가 아님
Rule 7: Document and Share Knowledge / 문서화하고 지식을 공유하라
- AI가 생성한 코드도 직접 쓴 코드만큼 문서화가 되어야 함 (때로는 더 많이)
- 비직관적인 결정이나 특이한 구현이 있다면 주석을 남겨야 함
- 어떤 부분이 AI 생성인지 팀원에게 명확히 공유
- 일부 팀은 주요 AI 코드에 사용한 프롬프트를 그대로 저장함 → 디버깅에 유용

위 규칙을 따름으로써, 팀은 vibe coding의 생산성을 최대한 활용하면서도 리스크를 최소화할 수 있음
핵심은 AI가 사람을 대체하는 게 아니라 보완하는 것
AI는 반복 작업을 빠르게, 사람은 비판적 사고와 창의성을 담당
우리는 AI와 함께 코드를 만드는(co-create) 시대에 살고 있음

vibe coding이 잘 작동하는 경우 vs 무너지는 경우

vibe coding이 어디에서는 빛나고, 어디에서는 그렇지 못한지를 명확히 아는 것도 중요함
모든 프로젝트나 작업이 AI 기반 워크플로우에 동일하게 적합한 것은 아님
아래는 업계 경험과 사례를 기반으로 정리된 활용 구분

👍 잘 작동하는 상황 (Great Use Cases)
- Rapid prototyping (빠른 프로토타입 제작)
  → vibe coding의 스위트 스팟. 작은 앱이나 기능 아이디어가 있을 때
  → AI 어시스턴트를 이용해 빠르게 개념 증명 또는 프로토타입을 만들 수 있음
  → 코드가 조금 엉성해도 괜찮음 — 핵심은 아이디어 검증
  → 주말 프로젝트 등에서 AI만으로 앱을 만들고 개념을 테스트하는 사례 다수
- One-off scripts / Internal tools (일회성 스크립트, 내부 도구)
  → 로그 파일 파싱, 개인 작업 자동화, 내부 대시보드 등
  → 실패해도 리스크가 크지 않은 환경에서는 vibe coding이 시간 절약에 효과적
  → 프로덕션급 품질이 필요 없는 상황에서 “당장 되는 것”을 빠르게 만들 수 있음
- Learning and exploration (학습 및 실험)
  → 새로운 언어나 API를 배울 때 AI에게 예제 생성을 요청
  → 완벽한 코드가 아니더라도 학습 재료로서 충분
  → 마치 **가상의 TA(조교)**가 다양한 시도를 보여주고, 그걸 사람이 다듬는 느낌
- Boilerplate-heavy tasks (보일러플레이트 작업)
  → 예: 비슷한 데이터 클래스 10개 생성, CRUD 구현
  → 구조만 명확하다면, AI는 반복적인 패턴을 정확히 따라 해줌
  → 기계적인 작업을 빠르게 넘기고, 사람은 중요한 부분에 집중 가능
👎 문제가 발생하는 상황 (Not-So-Great Use Cases)
- Enterprise software / Complex systems (엔터프라이즈급 소프트웨어, 복잡한 시스템)
  → 복잡한 비즈니스 로직, 동시성, 보안, 컴플라이언스 요구사항이 있는 시스템
  → AI는 명시적으로 말해주지 않으면 그런 조건을 모름, 알고 있어도 반영이 부족할 수 있음
  → 예: 핀테크 결제 시스템, 항공우주 제어 소프트웨어 등은 절대 AI 단독으로 맡기면 안 됨
  → 이런 환경에서는 일부 보조만 가능하며, 최종 품질은 사람의 QA와 전문성이 필수
- Long-term maintainability (장기 유지보수성)
  → 수년간 지속될 코드베이스는 시작부터 구조가 중요함
  → AI로 땜질하며 만든 코드들은 일관성이 떨어지고, 후속 유지보수에 큰 부담
  → 차라리 초기에 시간을 들여 명확한 프레임워크와 설계를 잡는 것이 좋음
  → 많은 초기 사용자들이, vibe coding으로 아낀 시간이
  나중에 리팩터링과 정리 작업으로 도로 들어간다는 경험 공유함
- Critical algorithms / Optimizations (고성능 알고리즘 또는 최적화 작업)
  → 예: 커스텀 메모리 관리, 초고속 정렬 알고리즘 등
  → AI는 소규모 입력에 대해서는 괜찮지만, 스케일에 대한 고려가 부족함
  → 경고 없이 느려지거나, 잘못 동작할 수 있음
  → 이런 부분은 여전히 사람의 창의성과 깊은 이해력이 필요함
- Explainability and clarity (명확성과 설명 가능성)
  → 코드가 다른 개발자나 감사자에게 명확하게 읽혀야 하는 상황
  → AI가 과하게 추상화하거나 복잡한 방식으로 접근할 경우, 가독성과 유지보수성이 심각하게 저하
  → 현재 AI는 “짧고 간결한 코드”를 항상 지향하지 않음 → 때론 과도하게 verbose하거나 불필요하게 추상화됨
  → 이런 경우, 사람의 리팩터링과 명확한 코드 작성이 필요함
요약하자면, vibe coding은 강력한 가속 도구지만 만능 해결사는 아님

속도가 중요하고, 결과를 몇 번 고쳐도 되는 작업에는 매우 효과적
반면, 미션 크리티컬한 소프트웨어를 한 번에 AI에게 맡기는 건 위험한 시도임
비유하자면: 레이스카 드라이버에게 학교 버스를 맡기는 격 — 좋은 도구지만 잘못된 용도

언젠가 AI가 모든 개발의 기본 툴이 될 수 있을지는 모르지만, 오늘은 아님
오늘 우리가 할 일은, AI를 올바른 문제에, 올바른 방식으로, 올바른 책임 하에 사용하는 것

결론: 신중하게 vibe하라 – 속도를 즐기되, 장인정신을 잃지 말자

vibe coding과 AI 기반 소프트웨어 개발은 도구의 진화에서 거대한 도약을 의미함
이 흐름은 일시적인 유행이 아니라, 이제 자리를 잡은 현실이며, 앞으로 더 정교해질 것
미래를 내다보는 엔지니어링 팀이라면 이를 외면해서는 안 됨
이전의 자동화 도구나 고급 프레임워크가 기존 개발 방식을 앞질렀듯,
AI를 잘 활용하는 팀이 그렇지 않은 팀을 능가할 가능성이 큼
이 글의 메시지는 vibe coding을 거부하라는 것이 아님 —
→ 눈을 뜬 채로, 엔지니어링의 기본을 지키며 접근하라는 것

가장 중요한 교훈: 속도는 품질 없이는 무의미함
버그 많고 유지불가한 코드를 빨리 배포하는 건 속도를 내며 낭떠러지로 가는 것일 뿐
최고의 개발자란, AI로 속도를 높이되 시스템을 무너뜨리지 않는 사람들
AI가 무게를 들어주고, 사람이 그것이 제대로 서 있는지를 확인하는 구조
그 균형점(sweet spot) 을 찾는 것이 핵심

기술 리더와 매니저를 위한 실천 포인트:
→ AI는 책임감 있게 사용하는 도구라는 문화를 팀에 정착시켜야 함
- vibe coding을 장려하되, 코드베이스를 지키기 위한 명확한 기대치와 룰도 같이 세워야 함
- AI 생성 코드도 무조건 코드 리뷰 대상으로 삼고,
  - “이 코드 이해돼?”라는 질문이 자연스러운 문화 형성
- 팀 전체가 AI와 효과적으로 협력할 수 있도록 역량 강화에 투자
  - 좋은 프롬프트 작성법, AI 제안 평가법 등 새로운 스킬셋 도입
- 이는 과거 고급 언어 전환, Git 도입 때와 같은 패러다임 변화임
  → 빨리 적응하는 팀이 이득을 볼 것

우리가 소프트웨어 엔지니어링에서 진짜로 중요하게 여겨야 할 것은 여전히 다음과 같음:
- 사용자 문제를 해결하는 것
- 신뢰할 수 있는 시스템을 만드는 것
- 계속해서 배우는 것
vibe coding은 수단이지, 목적이 아님
사용자에게 더 빠르고 더 나은 가치를 제공한다면 훌륭한 도구
하지만 그 과정에서 우리가 믿어야 할 품질과 보안을 희생하게 만든다면, 사용을 자제해야 함
본질은 여전히 유효함:
→ 명확한 사고, 요구사항 이해, 변화에 대비한 설계, 철저한 테스트

마지막으로 이 정신을 새기자:
→ “빠르게 움직이되, 망가뜨리지 말 것 – 혹 망가뜨리더라도 반드시 고칠 수 있도록.”
속도감 있게 코드를 만들되, 그 바탕엔 견고한 엔지니어링 기반이 있어야 함
AI는 장인의 손에 쥐어진 강력한 끌일 수 있음
→ 하지만 여전히 그 끌을 다루는 건 사람의 손

그러니 개발자들이여, vibe하라 – 하지만 신중하게 vibe하라
미래를 받아들이되, 우리를 여기까지 이끈 기본 원칙은 놓치지 말자
vibe coding은 낮은 품질을 정당화하는 핑계가 아니라,
→ 인간의 판단력과 기계의 생성 능력이 결합될 때 우리가 얼마나 더 큰 것을 만들 수 있는지 보여주는 기회

이 원칙을 내면화한 팀은 단순히 빨라지는 것이 아니라,
→ 오랫동안 살아남을 가치 있는 소프트웨어를 만들게 될 것임

Happy coding — 그리고 vibe는 높게, 품질은 더 높게.

▲

GN⁺ 4시간전 [-]

Hacker News 의견

"vibe coding"의 의미가 무엇인지 재정의했음
- 원래 트윗은 AI가 생성한 코드를 품질에 상관없이 받아들이고 원하는 결과가 나오지 않으면 무작위로 다시 시도하는 것에 대해 언급했음
- 사람들이 이제 이 용어를 "AI 에이전트에게 광범위한 작업을 맡기는 것"으로 사용하고 있는지 궁금함
AI 코딩의 과대광고가 너무 커서 현실적으로 충족할 수 없음을 느꼈음
- 복잡한 코드베이스에 대한 단위 테스트를 AI 코딩 앱에 맡겼으나 80%가 실패했음
- 경험 많은 인간 개발자는 이를 시작점으로 사용할 수 있었고, 반복적인 작업을 줄여줌
- AI는 현재 반복적인 작업을 가속화하는 데 유용하지만, 인간 개발자를 대체할 수는 없음
2000년대 초반 대기업들이 저소득 국가에 개발 작업을 아웃소싱하려 했던 시기를 떠올리게 함
- 아웃소싱된 개발자들이 시스템의 핵심 아이디어를 이해하지 못하고, 명세서에 적힌 대로만 개발함
- 결과적으로 명세서와 구현이 원하는 품질 수준에 도달하려면 많은 시간이 소요됨
- AI 코딩도 비슷한 상황이며, 프로토타입이나 빠른 솔루션에는 유용하지만 인간의 이해와 창의성을 대체할 수 없음
AI를 팀의 초급 개발자로 대하는 것은 더 많은 시간이 소요될 수 있음
- AI가 생성한 코드는 그럴듯해 보이지만, 실제로는 문제가 있을 수 있어 주의가 필요함
사용 사례에 따라 다름
- 컨설턴트로서 비즈니스 프로세스 자동화와 클라우드 시스템 통합 작업을 주로 함
- AI 에이전트와의 협업이 게임 체인저가 되었고, 기술 요구 사항 작성과 코드 리뷰에 집중할 수 있게 됨
- 제한된 예산 내에서 더 많은 것을 달성할 수 있게 되어 출력 품질이 크게 향상됨
소프트웨어 품질에 대한 다양한 관점이 존재함
- 사용자 관점의 품질: 버그가 적고, 문제를 정확히 모델링하며, 불필요하게 복잡하지 않음
- 개발자 관점의 품질: 코드가 깔끔하고 명확하며, 확장이나 변경이 용이함
- AI가 공식 명세와 테스트 방법을 만족시키는 데 집중한다면, 두 번째 종류의 품질은 중요하지 않게 될 수 있음
AI 보조 코딩이 개발자의 성장에 부정적인 영향을 미칠지에 대한 질문이 있음
- 장기적으로 개발자의 수요가 증가할지, 단기적으로 감소할지 궁금함
vibe coding을 통해 작업의 난이도를 파악함
- 프로토타입을 만들고, 라이브러리를 테스트하여 문제를 해결할 수 있는지 확인함
- LLM이 잘못된 매개변수나 함수를 제안할 때도 있지만, 시간을 절약할 수 있음
사람들은 에너지를 절약하려는 경향이 있으며, vibe coding은 저노력 개발을 가능하게 함
- 중요한 프로젝트에는 적합하지 않지만, 개인 프로젝트에는 유용할 수 있음
전체 기사가 "vibe code를 프로덕션에 배포하기 전에 인간이 검토해야 한다"는 문장을 부풀린 것처럼 보임

답변달기