바이브 엔지니어링

• "Vibe Engineering" 은 AI 코딩 도구를 활용한 전문 개발 방식의 새로운 명칭으로, 빠르고 무책임한 '바이브 코딩'과 달리 숙련된 엔지니어가 LLM을 활용하면서도 코드 품질과 책임성을 유지하는 접근법을 의미
• Claude Code, OpenAI Codex CLI, Gemini CLI 같은 코딩 에이전트의 등장으로 실무 프로젝트에서 LLM 활용이 급증했으며, 일부 엔지니어들은 여러 에이전트를 동시에 실행하여 병렬 작업을 수행
• LLM을 효과적으로 활용하려면 자동화된 테스트, 사전 계획, 포괄적인 문서화, 버전 관리, 코드 리뷰 문화 등 이미 확립된 최고 수준의 소프트웨어 엔지니어링 관행이 필요
• AI 도구는 기존 전문성을 증폭시키는 특성을 가지며, 시니어 엔지니어가 보유한 기술과 경험이 많을수록 LLM 활용 시 더 빠르고 나은 결과를 얻을 수 있음
• 이 용어는 '바이브 코딩'과의 명확한 구분을 통해 프로덕션 소프트웨어 개발을 위한 더 어렵고 정교한 AI 활용 방식임을 강조하며, 엔지니어링과 바이브의 모순적 조합이 오히려 기억하기 쉬운 장점을 제공 (AI 도구 발전에 따른 개발 프로세스 변화와 전문성의 중요성 부각)

---

바이브 코딩과 바이브 엔지니어링의 구분

• 바이브 코딩은 AI를 활용한 빠르고 느슨하며 무책임한 소프트웨어 개발 방식으로, 전적으로 프롬프트 주도적이며 코드 작동 방식에 대한 주의를 기울이지 않는 접근법
• 스펙트럼의 반대편에는 숙련된 전문가들이 LLM으로 작업을 가속화하면서도 자신이 생산하는 소프트웨어에 대해 자부심 있고 자신 있게 책임을 지는 방식이 존재하며, 이를 바이브 엔지니어링으로 명명
• 장난감 프로젝트가 아닌 실제 프로젝트에서 소프트웨어 엔지니어로서 LLM과 생산적으로 작업하는 것은 어렵다는 것이 덜 알려진 진실이며, 도구 사용법 이해에 많은 깊이가 필요하고 피해야 할 함정도 많음

코딩 에이전트의 등장과 영향

• 2025년 2월 출시된 Claude Code, 4월 출시된 OpenAI의 Codex CLI, 6월 출시된 Gemini CLI 같은 코딩 에이전트 도구들이 등장하여 실제 코딩 문제에 대한 LLM의 유용성이 극적으로 증가
  • 이 도구들은 코드를 반복적으로 수정하고 적극적으로 테스트하여 지정된 목표를 달성할 때까지 작업을 수행
• 경험이 풍부하고 신뢰할 수 있는 소프트웨어 엔지니어들이 여러 개의 에이전트를 동시에 실행하여 여러 문제를 병렬로 처리하고 작업 범위를 확장하고 있음
  • 저자는 처음에는 회의적이었지만 직접 병렬 코딩 에이전트를 실행해본 결과 정신적으로 지치지만 놀랍도록 효과적임을 확인
• tools.simonwillison.net 컬렉션의 대부분은 고전적인 바이브 코딩 방식으로 구축되었으나, 코딩 에이전트와 반복 작업하여 향후 유지보수할 수 있는 프로덕션 품질 코드를 생산하는 것은 완전히 다른 프로세스로 느껴짐

LLM이 강화하는 기존 소프트웨어 엔지니어링 관행들

• 자동화된 테스트: 강력하고 포괄적이며 안정적인 테스트 스위트가 있으면 에이전트 코딩 도구가 빠르게 작동할 수 있으며, 테스트가 없으면 에이전트가 실제로 테스트하지 않고 작동한다고 주장하거나 새 변경 사항이 관련 없는 기능을 깨뜨릴 수 있음
  • 테스트 우선 개발은 루프에서 반복할 수 있는 에이전트에 특히 효과적
• 사전 계획: 무언가를 함께 해킹하기 위해 앉을 때 높은 수준의 계획으로 시작하면 훨씬 더 잘 진행되며, 에이전트와 작업할 때 이것이 더욱 중요해짐
  • 먼저 계획을 반복한 다음 에이전트에게 넘겨 코드를 작성하게 할 수 있음
• 포괄적인 문서화: 인간 프로그래머처럼 LLM도 한 번에 코드베이스의 일부만 컨텍스트에 유지할 수 있으며, 관련 문서를 제공하면 코드를 먼저 읽지 않고도 다른 영역의 API를 사용할 수 있음
  • 좋은 문서를 먼저 작성하면 모델이 해당 입력만으로 일치하는 구현을 구축할 수 있음
• 좋은 버전 관리 습관: 코딩 에이전트가 변경했을 수 있는 경우 실수를 취소하고 무언가가 언제 어떻게 변경되었는지 이해하는 것이 더욱 중요
  • LLM은 Git에 매우 능숙하여 버그의 기원을 추적하기 위해 히스토리를 직접 탐색할 수 있으며, 대부분의 개발자보다 git bisect 사용을 더 잘함
• 효과적인 자동화: 지속적 통합, 자동화된 포매팅 및 린팅, 프리뷰 환경으로의 지속적 배포 등이 에이전트 코딩 도구에도 도움이 됨
  • LLM은 빠른 자동화 스크립트 작성을 더 쉽게 만들어 다음번에 작업을 정확하고 일관되게 반복할 수 있도록 지원
• 코드 리뷰 문화: 코드 리뷰에 빠르고 생산적이면 LLM과 작업할 때 훨씬 더 나은 시간을 보낼 수 있음
  • 다른 사람(또는 무언가)이 작성한 동일한 것을 검토하는 것보다 스스로 코드를 작성하고 싶다면 어려울 것
• 매우 이상한 형태의 관리 기법: 코딩 에이전트에서 좋은 결과를 얻는 것은 인간 협력자로부터 좋은 결과를 얻는 것과 불편할 정도로 유사
  • 명확한 지시를 제공하고, 필요한 컨텍스트를 보장하며, 생산물에 대한 실행 가능한 피드백을 제공해야 함
  • 실제 사람들과 작업하는 것보다 훨씬 쉬운 이유는 그들을 모욕하거나 낙담시키는 것에 대해 걱정할 필요가 없기 때문이지만, 기존 관리 경험이 놀랍도록 유용할 것
• 정말 좋은 수동 QA(품질 보증): 자동화된 테스트 외에도 엣지 케이스를 예측하고 파고드는 것을 포함하여 소프트웨어를 수동으로 테스트하는 데 정말 능숙해야 함
• 강력한 연구 기술: 주어진 코딩 문제를 해결하는 방법은 수십 가지가 있으며, 최선의 옵션을 파악하고 접근 방식을 입증하는 것은 항상 중요했고 에이전트를 풀어 실제 코드를 작성하도록 하는 데 여전히 장애물로 남아 있음
• 프리뷰 환경으로 배포하는 능력: 에이전트가 기능을 구축하면 해당 기능을 안전하게 미리 볼 수 있는 방법(프로덕션에 바로 배포하지 않고)이 있으면 리뷰가 훨씬 더 생산적이 되고 고장난 것을 배송할 위험이 크게 줄어듦
• AI에 아웃소싱할 수 있는 것과 수동으로 처리해야 하는 것에 대한 본능: 모델과 도구가 더 효과적이 됨에 따라 이것은 계속 진화하고 있음
  • LLM과 효과적으로 작업하는 큰 부분은 언제 가장 잘 적용될 수 있는지에 대한 강한 직관을 유지하는 것
• 업데이트된 추정 감각: 프로젝트가 얼마나 걸릴지 추정하는 것은 항상 시니어 엔지니어가 되는 가장 어렵지만 가장 중요한 부분 중 하나였으며, 특히 예산 및 전략 결정이 이러한 추정을 기반으로 이루어지는 조직에서 그러함
  • AI 지원 코딩은 이것을 더욱 어렵게 만들며, 오랜 시간이 걸리던 것들이 훨씬 더 빨라지지만 이제 추정은 우리 모두가 아직 파악하려고 노력하는 새로운 요소에 의존

바이브 엔지니어링의 본질과 의의

• 이러한 새로운 도구의 기능을 실제로 활용하려면 게임의 최고 수준에서 작동해야 하며,
  • 코드를 작성하는 것만 책임지는 것이 아니라
  • 접근 방식 연구,
  • 고수준 아키텍처 결정,
  • 사양 작성,
  • 성공 기준 정의,
  • 에이전트 루프 설계,
  • QA 계획,
  • 기회가 주어지면 속이려고 하는 이상한 디지털 인턴들이 계속 늘어나는 부대 관리,
  • 그리고 코드 리뷰에 많은 시간을 소비하는 것을 포함
• 이 중 거의 모든 것이 이미 시니어 소프트웨어 엔지니어의 특성
• AI 도구는 기존 전문성을 증폭시키며, 소프트웨어 엔지니어로서 더 많은 기술과 경험을 가질수록 LLM 및 코딩 에이전트와 작업하여 더 빠르고 나은 결과를 얻을 수 있음

“Vibe engineering”, really? : 용어 선택에 대한 고찰

• "바이브 엔지니어링"이라는 이름이 어리석은가에 대해: 아마도 그럴 것이며, AI에서 "바이브"라는 개념은 이 시점에서 약간 지쳐 보이고 "바이브 코딩" 자체가 많은 개발자들에게 경멸적인 방식으로 사용됨
  • 그러나 나는 더 건설적인 무언가를 위해 바이브를 되찾을 준비가 되어 있음
• "코더"와 "엔지니어" 사이의 인위적인 구별을 좋아한 적이 없으며 그것은 항상 약간의 진입 장벽처럼 느껴졌지만, 이 경우 약간의 진입 장벽이 정확히 필요한 것
  • 바이브 엔지니어링은 바이브 코딩과의 명확한 구별을 확립하며, 이것이 프로덕션 소프트웨어를 구축하기 위해 AI 도구와 작업하는 다른, 더 어렵고 더 정교한 방법임을 신호
• 이것이 건방지고 논란의 여지가 있을 가능성이 있다는 점을 좋아하며, 이 전체 공간은 여전히 다양한 방식으로 부조리함
  • 이러한 새로운 도구를 적용하는 가장 생산적인 방법을 파악하는 동안 우리 자신을 너무 심각하게 받아들이지 말아야 함
• 과거에 AI 지원 프로그래밍 같은 용어를 정착시키려고 시도했지만 거의 제로에 가까운 성공을 거두었으며, 이번에는 바이브를 문질러서 무슨 일이 일어나는지 보는 것도 나쁘지 않음
• "바이브"와 "엔지니어링" 사이의 명확한 불일치를 정말 좋아하며, 결합된 용어를 장난스럽고 (바라건대) 기억하기 쉬운 방식으로 자기 모순적으로 만듦

[m00nlygreat]

얼마전에도 무슨 코딩?이라고 이름 붙였다가 실패한 걸로 알고 있는데 AI 페어 프로그래밍이 가장 적절한 표현인 것 같네요.

그 이름 내가 만들었다. 라고 주장하기 위한 이름 짓기

[m00nlygreat]

증강 코딩(Augmented Coding)이라고 누군가 주장했다가 빠르게 사라졌었네요

[kimjoin2]

의미없는 명칭 만들기;

[GN⁺]

Hacker News 의견

• 최근 이런 주제를 읽으면 왠지 우울해짐을 느낌, 예전에는 구하기 힘든, 수요가 많고 보수도 좋은 프로그래밍 스킬을 가지고 있었고, 언어나 프레임워크가 빠르게 변해도 똑똑해서 따라갈 수 있다고 느꼈음, 그런데 Simon Willison 같은 사람들이 이런 새로운 에이전트 기반 코딩 방식과 동시다발적 작업 흐름이 미래라고 말하는 걸 보면, 엄청난 노력이 필요할 것 같아 힘든 마음임, 코딩 에이전트를 사용해봤지만 오히려 기다리는 시간이 많아지고, 여러 작업을 관리하는 게 흐름 잡기도 힘들어서 재미가 덜함, 그래서 완전히 다른 분야인 영업 같은 일로 옮기고 싶다는 생각이 듦
  • 나도 그런 기분에 진심으로 공감, 사실 내 목표 중 하나가 "프로그래밍 기술은 쓸모없어지고 누구나 LLM으로 코드를 짤 수 있다"는 생각에 반박하는 것이었음, 실제로 기존 개발 경험이 있는 사람이 코딩 에이전트나 LLM과 함께할 때 훨씬 더 가치가 높아진다고 믿음, 지금까지 배운 걸 활용해 새로운 도구로 더 큰 임팩트를 낼 수 있음, 포스트에서도 언급했듯 AI 도구는 기존 전문가의 역량을 증폭시키는 역할임, 초보자는 ChatGPT로 멋진 UI는 만들 수 있어도, 아키텍처 설계에서 자동화 테스트나 CI/CD, 쿠버네티스 배포, 여러 에이전트 동시 운용 등은 할 수 없으니, 경험 있는 엔지니어의 역할은 훨씬 중요해짐
  • 나도 "여러 대의 대규모 병렬화된 에이전트를 관리하는 것"이 부담스럽게 여겨짐, 겉으로는 매우 강력해 보여서 많은 개발자들이 관심을 두고 있겠지만, 사실 엄청난 스트레스와 관리적 일로 느껴짐, 내가 개발에 처음 빠졌던 때에는 코딩 그 자체가 재미였고, 하루 종일 코딩하며 많이 배웠음, 이제 10년 넘는 경력자가 되고 나서는 "애초에 왜 코딩을 해야 하지?"라는 비즈니스적 사고로 바뀌었음, 회의에서 각 부서가 "이거 할 수 있어요?" 묻기만 하면, 항상 정답은 "YES"임, 기술적으로 거의 다 가능함, 하지만 진짜 중요한 질문은 "얼마나 어렵냐" 혹은 "이걸 왜 해야 하냐"임, 여전히 반복과 다양한 물건을 출시하는 능력이 중요한 게 아니라 본질을 봐야 한다고 생각함
  • 내 마음을 정말 잘 대변해 줌, 나 역시 AI를 봐주며 관리하는 일은 정말 좋아하지 않음, 게다가 이 AI 기반 코딩이 어떤 검증도 되지 않은, 정체불명의 대기업 계정 없이 일할 수 없는 현실을 당연시하게 만드는 점도 무서움
  • 걱정할 필요 없음, 나도 우리 팀의 신입 엔지니어를 멘토링하는 중임, 이 친구는 코드 개선이 너무 힘듦, 왜냐하면 일단 동작하니까 그걸로 만족함, 구조도 별로고, 작은 문제나 보안 이슈가 구석구석 숨어 있음, 겨우 3개의 파이썬 파일로도 이런 일들이 있음, 우리 팀에 10명의 개발자가 있는데 LLM을 같이 쓸 경우, 경험의 차이에 따라 코드 품질 차이는 더 커짐, 공식적으로 LLM을 쓰게 되기 전 6개월 동안 느낀 바로는, 실제로 주니어와 시니어, 경험 많은 사람의 격차가 더 크게 나는 편임, Simon의 의견과 비슷함
  • 본질적으로 지식이 있는 사람일수록 도구에 의해 더 큰 힘을 받음, 그 반대가 아니라는 점만 기억하면 됨
• GPT-4 출시 즈음인 2023년 초, 번역업계에도 비슷한 변화가 있었음, 영어-일본어 번역(내가 일해온 분야)에서 처음으로 머신번역이 인간 수준에 근접함, 그때 많은 전문 번역가들과 다양한 논쟁을 했는데, 이곳처럼 다들 어려운 번역 실력이 의미없어질까봐 실망감을 호소함, LLM을 도우미로 쓰면 이제 과정의 도전적 재미마저 사라진다는 반응이 다수였음, 내가 만난 번역가들은 대부분 프리랜서로 일하며 한 문장씩 신중하게 번역하는 타입이었음, 대규모 번역 프로젝트 관리자가 되는 건 별로 내키지 않는다고 했고, 고도의 문화적/상황적 커뮤니케이션 역량을 쓸 수 있다 해도 동기부여가 적었음, 나는 현재 번역 일을 많이 하진 않지만 AI 발전을 꾸준히 따라가며, 종종 번역 작업으로 모델을 비교 테스트함, 요즘 여러 LLM을 겹쳐(서로의 번역을 교차검수, 개선) 돌리는 멀티 LLM 기반 번역 시스템을 실험해 봄, 일부 문서에서는 정말 최고 수준의 인간 번역과 거의 흡사한 결과가 나옴, API 사용료가 싸지는 않았지만 중요한 번역에는 충분히 투자할 만한 가치가 있었음, 그런 "vibe translation" 시스템 설계할 때, 내 번역가 경험이 분명하게 도움됐음, Simon이 말하는 vibe engineering과 닮음, 지금 내 나이(68세)엔 이게 괜찮지만, 만약 LLM 등이 내 경력 초기(5~10년 차)에 등장했다면 아마 번역가를 포기했을 수도 있을 거라 생각함
  • 번역 이야기는 LLM 논의에 정말 좋은 소재임, 경험 공유 고마움, 한편으로 대부분의 사람들이 번역가에게 깊은 가치를 두지 않음, 예를 들어 누가 책을 번역했는지 거의 기억하지도 않음, 요즘 사람들이 책을 예전만큼 읽지 않으니 더 그럴 수 있음, 또, 이런 이유로 전통적으로 번역은 항상 단어나 행의 수로 계약/결제되는 경향이 있었음, 소프트웨어 보안처럼 최종 체크로 취급받음, 정말 미래 경쟁력을 갖출 수 있는 번역 분야는 법률(사람이 소송이나 책임을 져야 하므로) 혹은 동시 통역/현장 통역(직접 대면하고 진짜 만남이 필요하니까) 정도임
• 요즘 기술 커뮤니티에서 "코딩이 더 빨라지고 생산성이 높아진다"는 주장을 지나치게 미는 것 같아 조금 어이없음, 무작정 빠른 결과만을 중요하게 여기는 분위기임, 실제로 내 경험에선 LLM이 중언부언 어수선한 코드를 뽑아내는 경우가 많았음, 물론 나보다 빠를 수는 있지만 오히려 내가 천천히 짠 코드가 훨씬 낫다고 느낌, 요즘 뭐든 빨리 채팅해서 빠르게 결과를 내고, 빨리 프로덕션까지 가야 한다는 분위기가 옛날 허술한 웹 제품 남발의 원인이었음, vibe coding/engineering 같은 멋스러운 단어 놀음 말고, 왜 이렇게 저품질이라도 빠른 속도가 필요하고 왜 자동화/프로세스 자체는 더 개선할 수 없는지 진지하게 논의해야 함, 예로 단위 테스트 엄청 빨리 만들 수는 있지만, 애초에 왜 이렇게 많은 단위 테스트가 필요한지 질문해야 한다고 생각함, 분명 필요하긴 한데, 추상화(상위 관점)는 발전 중이지만 정작 하위 툴(세부적인 도구)는 발전이 더딘 느낌임
  • 소프트웨어 엔지니어링 논쟁의 본질적 문제는, 도구와 언어는 같아 보여도 실제론 허용치, 보안, 컴플라이언스, 유지보수 기준에 어마어마한 격차가 있다는 점임, 어떤 이는 단순 프로토타입을 빠르게 만들고, 어떤 이는 10년짜리 장기 로드맵이나 민감 데이터를 다룸, 이 두 관점이 섞이다 보니, 빠르게 만들어내는 게 능력이라는 시각과 이러다 끔찍한 결과가 나온다는 우려가 병존하게 됨, 양측 다 틀리지 않지만 실제 업무 맥락과 위험도는 매번 무시된 채 논의가 이뤄지는 것 같음
  • 현실적으로 LLM이 개발 속도에 엄청난 도움이 되는 건 사실임, 5학년 때부터 20년 이상 코딩해왔고, 주변에서도 내 속도를 인정하지만, LLM 도입 후 내 스케일이 엄청나게 커졌음, 이미 판이 바뀌었고 이제 적응하느냐 못 하느냐의 문제임, 미래의 불확실성에 나도 불만이 많지만, 비슷한 처지의 엔지니어라면 충분히 공감함
  • 소프트웨어 개발에서 속도가 왜 그렇게 중요한지에 대한 논리를 펼쳐보려 함, 내 주장이 반드시 옳다거나 실제 데이터가 있는 건 아님, 용어 정의도 불명확할 수 있음, 일단 "사소한(트리비얼) 소프트웨어"란 모두가 그 가치와 해법을 명확히 알고 있고, 자동 검증이 가능하거나, 오직 하나의 구현 방법만 존재하는 경우로 볼 수 있음, 그런데 현실의 대부분의 소프트웨어는 비트리비얼함, 여기엔 항상 버그, 누락 요구사항, 누수되는 추상화, 쓸모없는 기능, 통합 문제, 성능 이슈, 보안 문제, 복잡도, 유지보수 골칫거리 등이 발생함, 아무리 뛰어난 개발자가 짜도, 아무리 코드를 잘 짜도 이런 문제는 불가피함, 이런 문제들은 반복된 피드백, 실사용, 유지보수, 수많은 실험 속에서만 드러나고 조금씩 개선됨, 즉, 코드를 한 번에 완벽하게 만들 수 있는 건 아니고, 여러 번의 반복에서 품질이 좋아져감, 전체 소프트웨어 품질은 이 "피드백 루프"의 양에 지배됨, 루프 하나를 도는 데 걸리는 시간만큼 전체 반복 횟수도 제한됨, 결국 생산 속도가 높을수록 많은 피드백 루프를 경험할 수 있고, 그만큼 더 나은 소프트웨어로 발전한다고 생각함, 느리지만 고품질 코드도 1회 반복밖에 안 되면 한계가 있고, 오히려 질 낮더라도 반복이 무한히 많으면 더 좋은 결과에 다다를 수 있음
  • 5년 후엔 세상 최고의 매몰비용 오류 사례가 될 것 같음
• "vibe coding"보다는 "agentic coding" 혹은 "agentic software engineering" 같은 명칭이 더 적합하다고 생각함, 내 개발 흐름은 Claude의 코드 플랜에서 시작되고, 첫 단계로 항상 명확한 스펙을 만듦, TDD를 활용하며 내가 정한 숨은 코드 품질 규칙도 자동화 도구로 강제함, 예를 들어 디자인 시스템에 어긋나면 코드 커밋이 안 되고, HTTP 핸들러가 반드시 서비스 레이어를 거치도록 계층 분리 체크도 자동화함, 모델에는 TDD를 잘 지키도록 주기적으로 상기시키는데, Claude 4.5는 4.1보다 훨씬 더 잘 기억함, TDD 기반 덕에 PR 코드 리뷰도 엄청 쉬움, PR과 스펙을 Gemini에게 넘겨 불일치, 누락, 오류 등을 자동 지적하는 간단한 도구도 만들었음, 좋은 백업툴임, 하지만 궁극적으로 중요한 건 내가 원하는 결과가 뭔지, 그리고 에이전트가 어디서 벗어나는지 직접 판단할 줄 아는 역량임, 결국 "질 낮은 인풋엔 질 낮은 아웃풋, 질 높은 인풋엔 질 높은 아웃풋"임
  • 모델에게 TDD를 상기시킨다 했는데, vibe coding에서 실제로 에이전트가 TDD의 레드-그린-리팩터 루프를 반복적으로 수행하는지? 아니면 결과 하나를 한 번에 쭉 뽑아내는지 궁금함
  • vibe based라는 명칭 대신 "slop-coding"이 더 어울린다고 생각함
• "vibe engineering"이라는 명칭이 진짜 맞는지 의문임, 실제로는 에이전트에 자동 테스트, 사전 기획, 상세 문서화, 코드 포매팅/린트, 수동 QA 등 온갖 제약을 두는 방식임, 나도 Karpathy 글 읽고 vibe coding 시작해봤고, 일단 코드가 멈춰도 여러 번 재실행하며 전체 프로세스를 신뢰하는 흐름을 경험해 봄, 하지만 경험을 쌓다 보니 결국 모델을 통제해야 된다는 사실을 깨달음, 에이전트 운영이 카트 레이싱과 비슷해서, 트랙 주위의 타이어처럼 여러 제약 조건을 둘 필요가 있음, 제약 장치(Constraint Harness)가 핵심이고 코드 자체는 생성/재생성이 쉬워짐, 앞으로 중요한 건 AI 작업물에 대한 테스트와 제약조건을 잘 쌓는 일임
  • "vibe engineering"이라는 명칭은 너무 가볍고 진지해 보이지 않음, 중립적이고 진짜 기능을 담은 "LLM-assisted programming" 같은 용어가 더 낫지 않겠는가? 물론 임팩트는 적지만
• "사전 기획"은 spec-driven development로도 부를 수 있겠음, 사실 모든 개발이 간단히 말하면 사전 명세에 기반했을 수도 있음, 그러나 "매우 이상한 형태의 관리" 즉 명확한 지시, 충분한 맥락, 실행 가능한 피드백 제공 쪽이 진짜 골자임, 문자로만 보면 agile보다 waterfall 방식에 더 가까움
• 이제 vibe-coding이란 말이 AI 기반 코딩 전체를 아우르는 뜻으로 의미가 전이된 것 같음, 실제로 나도 AI와 함께 작업할 때 페어프로그래밍 느낌에 가깝고, "진짜 vibe-ing이다"란 생각이 듦, 다만 "Take the wheel, LLama of God" 같은 원래의 무작정 맡기는 vibe-coding도 여전히 자주 쓰일 현상이라 따로 새로운 단어가 필요하다고 생각함, “Yolo-Coding”을 제안하고 싶음, no-code, low-code, yolo-code 흐름과도 잘 들어맞음
  • 나는 vibe coder가 no-code와 비슷한 부정적 이미지를 유지하는 게 낫다고 생각함, vibe engineer라는 말은 별로지만, 어쨌든 앞으로 엔지니어/개발자라는 이름 자체가 에이전트 사용을 기본 전제로 하고, "수작업" 개발자는 오히려 예외가 될 수도 있다고 봄
  • $enterprise에서는 "responsible vibing"과 "YOLO vibe coding"을 구분하는 새로운 명칭을 찾다가, 결국 "agent assisted coding"이라는 용어에 도달함, 세 글자짜리 약어가 꼭 필요하니까
  • "vibe coding"의 본래 의미는 Ilya Sutskever가 트위터에서 올린 것처럼, 그냥 프롬프트 입력 후 결과를 리뷰도 없이 복붙해서 실행하는 식임, 분석이나 검증 없이
  • AI-assisted coding은 개인적으로 오토컴플리트나 불친절한 문서 읽기 지원하는 수준이라고 봄, vibe coding은
  • LLM이 짠 코드를 개발자가 전혀 이해 못함
  • 코드 리뷰 없는 채로 당장 기술부채 발생
  • 법적으론 저작권 보호이슈로 EU/US에선 완전 취약 라고 생각함, vibe coding의 최대 치명점은, LLM이 생산한 코드는 본질적으로 보호/저작권 등록이 불가하다는 점임, 영국 등 일부 예외가 있지만 대부분의 나라에선 답 없다고 봄
  • 나도 claude에 /yolo 같은 슬래시 명령을 만들어 별다른 가이드 없이 그냥 실행해 보기도 함
• 비둘기가 랜덤으로 먹이를 뽑아낼 수 있는 장치와 상호작용할 때, 자기 행동 때문에 보상받는 줄 알고 온갖 재밌는 춤과 동작을 반복하게 되는 실험이 있음
  • 그 재미난 춤이 다름 아닌 "테스트 작성"이나 "계획 세우기"와 비슷할 수도 있음
  • 혹시 근거가 되는 논문 같은 것 있을까? "비둘기 재롱둥이"로 검색하면 SNS 동영상만 나와서 찾기 힘듦
• "Augmented Engineering"(AE)이란 이름이 더 나음, AI의 힘으로 역량을 확장할 수 있고 최고의 결과를 낼 수 있으니 "증강 엔지니어링"임, AE는 "Advanced Engineering"으로도 해석 가능함, AI가 즉시 최신 기술 지식을 접할 수 있게 해주니까 당연히 더 발전된 엔지니어링임, 반면 vibe는 별로임
  • 용어를 굳이 신경 쓸 필요는 없으며, 별도 네이밍을 하면 오히려 AI 코딩이 일부 개발자에만 해당되는 것처럼 느껴질 수 있음, 앞으로는 전통적 코딩이 예외적인 방식이 되고, 지금의 vibe라는 말도 곧 사라질 것임
  • 마지막 문장에는 반론이 있음, AI가 단순히 최신 엔지니어링 지식을 이해하게 해주는 게 아니라, 최근 1~10년간 반복된 실수, 오류, 오해, 설계 결함 등도 "즉시" 흡수시킬 수 있는 위험이 있음, 즉 AI가 공급하는 정보를 절대 무비판적으로 신뢰해선 안 되고, 출처도 반드시 확인해야 하며, 그 출처조차 AI가 생성한 것 아닌지도 확인이 필요함, 데이터셋이 계속 오염되고 있으니 더더욱 조심해야 함
  • "Augmented Engineering"이 꼭 별도 이름이어야 하냐고 묻고 싶음, 사실 그냥 "엔지니어링"이지, 참고서 보면서 한다고 "북 어시스티드 엔지니어링"이라고 하지 않듯이, vibe도 마찬가지, 굳이 "Yolo engineering", 혹은 "머신 아웃소스 무책임 무한웃음(Machine Outsourced Irresponsible LMAO Engineering)"이라 불러도 될 듯, 마지막 “Advanced Engineering”도 부풀리기 같음
• Simon은 언제나 정확히 핵심을 짚음, 하지만 진짜 문제는 "코딩"보다는 "vibe"라는 단어임, vibe engineering으로 바꿔도 여전히 "뭘 하는지도 모른 채 무작정 진행한다"는 뉘앙스를 줌, 그나마 "AI-assisted software engineering" 같이 양 끝단을 명확히 구분할 수 있는 용어가 더 낫다고 봄