▲

바이브 코드는 레거시 코드임

 (blog.val.town)
12P by GN⁺ 2일전 | ★ favorite | 댓글 4개
  • 바이브 코딩은 AI의 도움으로 코드를 직관에 따라 빠르게 작성하는 방식으로, 결국 이해하지 못하는 코드, 즉 레거시 코드를 남기게 됨
  • 레거시 코드는 누구도 이해하지 못하는 코드로, 기술 부채와 유지보수 문제를 불러오며 새로운 기능 추가 시 오류 발생 가능성이 높음
  • 바이브 코딩은 프로토타입이나 단기 프로젝트에는 빠른 개발 수단이 될 수 있으나, 장기적으로 유지해야 하는 프로젝트에는 부적합함
  • 비전문가가 대형 프로젝트를 바이브 코딩할 경우 신용카드를 아이에게 주는 것과 같은 위험이 존재함
  • 2025년에도 AI와 함께 개발할 때는 신중함과 이해도를 유지하는 것이 중요함

바이브 코딩이란 무엇인가

  • Andrej Karpathy는 "바이브 코딩" 이라는 용어를 AI가 코드를 작성하고, 사용자가 코드 자체의 존재를 잊을 정도로 신경 쓰지 않는 프로그래밍 방식으로 정의함
  • 이 접근법은 개발자가 작성된 코드의 내부를 전혀 이해하지 않아도 결과물을 얻는 점에서 전통적인 소프트웨어 개발과 다름

레거시 코드의 문제와 기술적 부채

  • 아무도 이해하지 못하는 코드는 이미 레거시 코드임
  • 이런 코드는 유지·보수에 많은 시간이 들고 버그나 새로운 기능 추가 시에도 문제점이 크게 늘어남
  • 프로그래밍의 본질은 코드를 많이 만드는 것이 아니라 개념적 이론 구축임을 강조함

바이브 코딩과 프로토타이핑

  • 바이브 코딩은 프로토타입 개발이나 일회용 프로젝트에 빠른 진입과 개발을 제공함
  • 만약 후속 유지보수가 필요 없다면, 코드의 내부를 몰라도 큰 부담이 되지 않음
  • 이로 인해 개발 속도를 대폭 높이고, 새로운 아이디어를 실험하는 데 매우 적합함

바이브 코딩의 이해도 스펙트럼

  • 바이브 코딩은 개발자가 코드에 대한 이해도가 낮을수록 더 많은 바이브를 타는 방식에 있음
  • 기본적으로 엔지니어가 요구 사항을 더 명확히 이해할수록 바이브 코딩이 줄어듦
  • 비프로그래머가 웹과 네이티브 앱의 차이, 데이터 저장 방식도 모른 채 코딩을 요청할 경우 일반적으로 더 많은 바이브 코딩이 발생함

비전문가의 대형 바이브 코딩: 신용카드와 비슷함

  • 비전문가가 바이브 코딩으로 대형 프로젝트를 만들고 유지하려는 것은 신용카드를 개념 없이 아동에게 주는 것과 비슷한 상황임
  • 처음에는 모든 것이 쉬워 보일 수 있으나, 이후 막대한 유지보수 비용과 문제가 뒤따름
  • 결국 '청구서'가 찾아왔을 때 문제 해결 능력이 부족하면 오히려 상황을 악화시킬 수 있음

2025년 AI 시대의 진지한 개발

  • Andrej Karpathy는 AI와 함께하는 개발에서는 신중함과 조심스러움, 그리고 기존 코드에 대해 지속적으로 배우는 자세가 반드시 필요함을 강조함
  • AI의 과장된 자신감을 방어하고, 좋은 코드와 나쁜 코드를 구별하는 인간적인 판단력이 중요함
  • 단순히 AI에게 맡기지 말고, 반드시 코드를 직접 읽고 이해해야 함

Val Town의 AI 도구 활용

  • Val Town은 Townie라는 AI 도우미를 통해 코드 작성, 실행, 확인, 반복적인 개선 과정을 자동화함
  • Townie는 바이브 코딩에 적합한 도구이며, 사용 용도에 따라 자유롭게 활용하거나 엄격하게 제어할 수 있음
  • AI와 함께 개발하는 방식은 매우 빠르게 진화 중이며, 복합 소프트웨어 개발에 있어 이론적 토대의 중요성은 앞으로도 지속됨

비전문가의 무분별한 바이브 코딩에 대한 경고

  • 비프로그래머가 수천 달러를 들여 거대 앱 아이디어를 바이브 코딩하는 것은 좋은 방법이 아님
  • 궁극적으로 누구든 코드의 내부를 직접 읽고 분석하는 인간의 눈이 필요하며, 이해 불가능한 레거시 코드 고치기보다는 처음부터 다시 잘 설계하는 것이 더 효과적임

결론 및 조언

  • 복잡한 소프트웨어를 구축할 때는 이론적 기반이 핵심임
  • AI 발전으로 프로그래밍 방식은 빠르게 변하지만, 인간 개발자의 전문성은 여전히 중요함
  • 비전문가가 AI로 대규모 앱을 만들려고 하면, 결국 코드 전체를 읽고 새로 만드는 게 더 나을 수 있음
▲
sinbumu 11시간전  [-]

방법과 기술의 문제라 생각 그냥 ai쓰지말고 오가닉 손코딩 해야 한다는 애들은 공학계산기 말고 주판 두드리거나 엑셀 팡션 쓰지말고 수기작성하는게 진리란 애들 같음

답변달기
▲
elbanic 1시간전  [-]

잘못된 비유입니다. 공학계산기는 계산기나 엑셀과 마찬가지로 입력값에 따라 결과가 정확하죠. AI가 사용자가 예측한 결과를 그대로 출력한다면 지금껏 숱하게 나온 신기술과 그렇게 많이 다른 기술은 아니었을 겁니다. 시간이 갈 수록 보안과 할루시네이션에 대한 우려가 커지는 이유이기도 하죠. Gen AI는 컨트롤 할 수 없다는 말입니다. 현재 LLM의 한계를 이해하고 적절한 곳에 사용되어야 합니다.

답변달기
▲
tensun 14시간전  [-]

현재 바이브 코딩은 이제 태동기 이며 내년 내후년에는 성숙된 개발 방법론이 되리라 봅니다. devops가 aidevops가 되듯이 aiagile 또는 vibeagile이 되리라 생각합니다.

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 비개발자 친구에 대한 이야기임. 친구가 작년에 SaaS를 직접 코딩해서 런칭했고, 마케팅 거의 없이 입소문과 인바운드만으로 수익을 내기 시작했음. 개발에는 Replit과 Supabase를 썼고, 고객 피드백을 받으면서 앱이 점점 복잡해졌다는 걸 생각하면 정말 대단하다고 느낌. 내 생각엔 이 시장에 기존 업체 두 곳이 있었고, 내 친구가 훨씬 저렴한 월 요금으로 더 현대적인 제품을 보여주니까 그 업체들이 만족하지 않았던 것 같음(기존 제품들은 모두 Windows용 데스크탑 소프트웨어). 그래서 그들은 해커를 고용해 친구의 SaaS를 공격하게 했는데, 이 해커들은 금전 요구 없이 공격함. 불행히도 친구가 경험 없이 빠르게 코딩하다 보니 취약점이 많았음. 첫 번째로, 프런트엔드 코드에 사용자 목록이 노출되어 해커가 모든 고객에게 이메일을 보내버림. 두 번째로, 해커가 Stripe 키를 손에 넣어 모든 고객에게 환불 처리함. 세 번째로, 아직도 해커가 XSS 공격을 시도하며 가끔 필드에 <script>alert()</script> 같은 태그가 등장함. 내 결론은, 경험 없는 사람이 vibe-coding을 하면 곧바로 기술 부채가 쌓인다는 것임. 하지만 동시에, 이 친구가 엔지니어링 경험 없이 몇 달 만에 사업성이 있는 제품을 증명했다는 사실은 놀라움. 지금은 개발자를 채용해서 보완하는 중임. 이런 허술하고 보안 취약한 코드로 괜찮은 비즈니스 가능성을 수백 달러 투자만으로 입증했으니, 결국 그 과정이 가치 있었다고 생각함

    • 나는 경쟁 업체의 소행이라고 가정하는 게 오히려 책임 회피라는 생각이 듦. 실제로는 그저 자동화된 취약점 스캐너가 사이트를 탐지하고, 너무 허술하니까 해커가 진입해 장난친 게 더 그럴듯함. 인터넷에 연결된 서비스에서 이런 익스플로잇 트래픽 자주 보는 사람들은 잘 알 것임

    • 이건 마치 엔지니어 경험 없이 집을 지었다가 누군가 와서 그냥 걷어차 무너뜨려버린 것과 도덕적으로 동일함. 문제는 vibe 코딩 자체가 아니라, 중요한 결정을 내릴 때 필요한 지식이 부족하다는 데서 비롯됨. 이런 문제는 법적 책임 문제로까지 이어질 수 있음

    • 시장에 기존 업체가 이미 있었다면, 사업성 입증에 굳이 이런 MVP가 필요했을까? 본질적으로 저렴하게 제공하면 사람들이 기존 공급자에서 옮길 건지 테스트할 이유가 없음. 친구가 얻은 교훈은, 일부 고객이 초기엔 사용료를 지불하겠지만(재구매율 데이터 없음), 궁극적으로 진짜 제품을 만들기 위해 사람을 채용해야 하고, 그러다 보면 가격 경쟁력도 떨어질 거라는 점임. 마케팅에 본격 투자해야 할 때가 오면 고민이 많아질 것임. 결국 다시 깨닫게 되는 사실은, 아이디어만으로는 아무런 가치가 없고 실행 역량이 관건이라는 점임

    • 네 친구가 별 다른 책임도 없이 계속 사업을 이어갈 수 있다는 게 이 업계의 근본적 문제임. 만약 소프트웨어가 타 엔지니어링 분야처럼 엄격히 관리되는 세상이었다면, 개발자나 기업은 고객 정보 유출로 법적 책임을 질 수밖에 없었을 것임

    • 사업 자체에 증명을 했다고 해도, 고객 입장에서는 이득이 아니라 손해일 수 있음. 돈을 내고 사용하는 동시에 중요한 데이터를 보안상 취약한 곳에 노출시키고, 제품이 제대로 동작하는지조차 불분명한 상황임. 이제 개발자를 채용해 보완한다는데, 생각만큼 쉽지 않을 것임. AI가 학습 자료나 생산성, 학습 도구로 사용될 때는 찬성하지만, 사람이 중간에 투입되지 않으면 끔찍한 결과물이 나올 수 있음

  • 예전에도 비개발자나 주니어 개발자들이 Microsoft Access, Excel 등으로 쉽게 애플리케이션 만들어 배포한 적이 여러 번 있었음. 그때도 한계, 확장성 문제, 관리 악몽이 많았지만, 동시에 이런 흐름이 등장하면서 전문 개발자들도 더 나은 솔루션 개발에 박차를 가했음. PC가 대중화될 때도 마찬가지였는데, 메인프레임 개발자들은 PC 세상의 ‘엉망진창’ 코드를 보며 경악했음

  • 나는 거의 삼십 년 넘게 소프트웨어 엔지니어로 일해왔고 이 글의 댓글들을 전부 읽어봤음. 그런데 vibe coding을 비판하는 거의 모든 근거가, 내가 그동안 봐왔던 ‘사람이 쓴’ 모든 코드베이스에도 동일하게 해당된다고 생각함(물론 예외가 있긴 함)

    • 버리려고 만든 프로토타입이 왜 나쁘다는 것인지 모르겠음. 사업 시작에 있어 가장 중요한 단계임. 레거시 코드 역시 마찬가지임. 실제로 수익을 내는 대부분의 코드는 그 조직 내 개발자의 눈에 이미 레거시로 여겨질 확률이 매우 높음

    • 농담처럼, trunk에 머지된 순간부터 전부 레거시 코드라는 말이 있음

    • 약간 동의하지만, vibe coding의 문제는, 제대로 조사도 안 하고, 기존 코드베이스 구조나 필요한 솔루션이 뭔지 연구하지 않은 상태로 막무가내로 접근할 수 있게 한다는 점임. 어제만 해도 Rust에 익숙하지 않은 동료가 vibe coding으로 새 기능을 만들었는데, 겉으론 ‘동작’하지만 실제로는 엄청 엉망임(tokio async 컨텍스트에서 동기 I/O, 락, 자체 채널 구현 등). 이미 안전한 비동기 추상화가 있는데도 새롭게 잘못된 추상화를 만들어둠. 직접 찾아보거나 먼저 도움 요청했다면 기존 코드에서 예제를 참고할 수도 있었음

  • 모든 코드는 언젠가 레거시 코드가 됨. 내가 주니어 시절부터, 그리고 동료 주니어 개발자들이 작성한 수많은 프로덕션 스크립트나 서비스 코드 리뷰해본 경험에 비춰봤을 때, 이런 절대주의적 시각은 너무 과함. 이 문제는 대부분 조직에서 반복됨. LLM 기반 코드의 품질을 비판하는 글을 쓰는 것도 이해하지만, 커리어 내내 남이 만든 시스템 고치고 확장하거나 리팩터링 해온 개발자라면 이 현실을 더 잘 알 것임. 소프트웨어 엔지니어링 세계에 기계공학처럼 일관성, 인증, 책임, 실질적 결과에 대한 엄격한 기준과 법적 리스크가 도입되지 않는 한 이런 논쟁은 큰 의미 없음. 현대 IT 산업 자체가 완전히 반대 철학, 즉 ‘agile’, ‘빠르게 만들고 망가져도 상관없다’에 기반해 있음. 신속하게, 적은 설계로 자주 배포해보고 잘못 올라가면 되돌리고, 장애나면 ‘어쩔 수 없지’하는 분위기임. 소프트웨어는 장난감처럼 취급받고 있음. 1%만이 제대로 한다고 자부하겠지만, 대부분은 그렇지 않음

    • 네 말 다 맞고, 여기에 덧붙이면 코드란 결국 과학이 아니라는 점임. “정답”인 코드의 기준은 결국 상황마다 다름. 코드는 목표 달성을 위한 도구에 불과함

  • 지금 재미있는 일이 벌어지고 있음. 엔지니어링을 잘 모르는 사람들이, 또 어느 정도는 알면서도 제대로 설명하지 않는 사람들까지, 온라인에 잘못된 내러티브를 퍼트리고 있음. 이들은 이제 주니어 개발자가 10배 생산적이고, PM들마저 직접 코드 배포하고 있다고 주장함. 그런데 잠깐 눈 감고 이런 상황에서 나온 코드를 떠올려보면, 그건 100% 레거시 코드이자 버려질 코드임. 문제의 본질은 AI나 PM이 Figma에서 바로 코드 뽑는 능력, 주니어가 프롬프트 남발하는 게 아님. 기대와 실질이 괴리되는 진짜 이유는, 원래 몇 년이나 걸려 논의해 정의한 용어와 개념을 제대로 구분하지 못하기 때문임.
    린 프로토타입과 disposable 프로토타입(MVP조차 아님)은 다름. MVP는 린 프로토타입의 성공적 검증 후에야 만들 수 있음. 제품은 MVP랑 또 다름.
    vibe coding 툴은 disposable 프로토타입 빠르게 만드는 데 최고, LLM이 탑재된 IDE는 진짜 제품 만드는 데 더 적합함. 지금 단계에서는, 진짜 엔지니어만이 LLM 프롬프트로 린 프로토타입을 코딩하는 수준이고, 나머지는 disposable 코드로 동작하는 단순한 소프트웨어만 만듦

    • “제품은 MVP와 다르다”고 했는데, 이 말을 내가 일했던 거의 모든 회사에 해주고 싶음. 요즘 이사회, C레벨들이 “이번 분기까지 뭔가만 내라”는 태도가 만연하다 보니, 개발자들은 MVP 만들고 곧장 다음 프로젝트로 넘어가게 됨. 진짜 vibe 코딩 여부와 상관없이, 현실은 기능 풍성해 보이면 실제 품질 상관없이 비즈니스 지표가 올라감. 사실 진짜 엔지니어(이제부턴 ‘개발자’를 이렇게 부르는 듯)가 주도적으로 프로토타이핑하는 환경은 많지 않음. 게임, 혹은 일부 tech기업에서나 보기 드묾. 대부분은 오로지 MVP 만들기에만 몰두함. vibe 코딩은 그저 MVP 양산 속도를 높일 뿐, 품질은 그만큼 희생됨

    • “용어 정의”가 실체 없이 혼용되는 추세가 지난 10년간 업계에서 눈에 띄게 커졌음. 이 용어들은 원래 수많은 책과 토론, 오랜 기간 걸쳐 온갖 논의를 통해 맥락이 축적된 단어들임. 노련한 개발자가 한 단어를 쓰면 그 안에 모든 경험과 논쟁 맥락이 담겨 있던 것임. 그런데 신규 입사자들은 이런 맥락 없이 표면적으로만 단어를 ‘카피’해서 의미도 정의 없이 그냥 써버림. 결과적으로 누구도 각 용어가 원래 뭘 의미하는지, 왜 그 상황에 맞는 단어인지 파악하지 못함. 예를 들어, "'agile', 'technical debt', 'DevOps', 그리고 최신의 ‘vibe coding'" 등등. HN에 semantic drift에 대한 글도 올라왔음. 소프트웨어 업계에선 흔한 현상임.
      기술적 예시로 자바스크립트에서 'object', 'JSON', 'dictionary', 'hashmap'을 다 혼합해서 쓰는 걸 들 수 있음. 원래 각각 의미가 다르지만, JS 개발자들에겐 그냥 ‘object’ 하나로 통용됨. 그래서 언어적, 개념적 해상도가 하나의 ‘픽셀’로 다 뭉개지는 것과 같음

    • 과거에는 개발자들끼리 서로 코드에 대한 ‘마음가짐’이 다르다고 이야기했음. 그런데 지금은 누구도 코드를 이해하지 못해 생기는 개발자 피로도가 엄청 늘어났음. 예전에는 이런 상황일 때 엔지니어가 나서서 고장난 부분을 쓸모 있게 고치고, 아키텍트가 복잡도를 줄이는 식이었음. 이제 LLM 시대에는 100배 더 많은 코드가 쏟아지는데, 정작 엔지니어나 아키텍트는 이 흐름에서 완전히 배제됨. 이게 우리가 직접 체감하는 현재 상황임.
      만약 이 문제를 해결하는 테스트 방법(TDD MCP 서버, DDD MCP 서버 혹은 아무 워크플로/아키텍처라도)을 고안하면, 수조짜리 스타트업 가능성 있음. 코드 리뷰 효율을 대폭 높이고 확장할 수 있는 도구가 절실함

    • "동작하는 소프트웨어"의 정의부터 더 명확히 해야 한다고 봄. 예를 들어, LLM이 만든 UI는 다 똑같아 보이고, 미묘하게 잘못됐거나 오류가 숨어 있음. 사용자 테스트 한 번에 바로 문제 드러남. 또, 생성형 UI는 이미 트렌드에만 집착할 뿐, 새로운 무언가를 만들어내지 못하기도 함

    • 대기업의 내부용 코드 작성 방식을 본 적 있는가? vibe 코딩과 별반 다를 게 없음. 오히려 LLM에 펜테스트 통과하도록 튜닝 시키면 뭔가라도 하려고 함. 대기업은 그냥 관심조차 없음

  • 사실 모든 코드는 레거시임. 그래서 vibe coding이 코드를 빠르게 많이 생산해낸다고 특별한 게 아님. 결국 누구도 이해 못할 ‘내 손으로 짠 코드’도 똑같이 엉망임. 모든 코드는 결국 유지보수 관점에선 짐일 뿐임. 라이브러리도 문제를 덜어줄 수 있을 뿐, 자주 바뀌거나 인터페이스가 낙후된 건 더 최악의 레거시임.
    코드를 오래 작성해온 사람일수록 결국 해답은 덜 만드는 것, 즉 전체적으로 필요 자체를 줄여야 한다는 결론에 도달함. 모든 복잡성은 결국 ‘미래의 내가 기억 못 하는 문제’가 됨. 실상 요구사항이란 것도 그때그때 달라지고, 전문가가 말한 요구라 해도 틀릴 수 있음(그리고 그 ‘전문가’가 바로 본인일 수도 있음)

    • "모든 코드는 레거시"라는 주장엔 동의하지 않음. 일부는 작고, 개발자가 여전히 머릿속에 전부 꿰고 있어서 완전하게 ‘실시간’인 코드도 있음. 레거시의 실질적 정의는, 방대한 규모면서 조직에 현재 소유자가 아무도 없는 코드임. vibe 코드는 생성되는 순간 두 가지 조건을 이미 만족함

    • 레거시란, 더이상 이해관계자가 남아 있지 않아, 유지보수도, 맥락 파악도 어렵게 됐을 때를 뜻함

    • 최대한 적은 코드로도 문제를 해결하길 바람. 코드가 내 문제가 아닐 수 있게 만드는 게 관건임. 추상화가 얼마나 ‘샌다’가 관건인데, 지금 LLM이 만드는 추상화는 굉장히 나쁨. 앞으로 얼마나 개선될지는 불명확함.
      더 재밌고 쉽게, 저렴하게 코드 이해할 수 있는 도구에 투자하고 싶음. 내 친구 Glen이 참고가 될 만한 프로젝트를 함: https://glench.github.io/fuzzyset.js/ui/
      Geoffrey Litt 말처럼, LLM은 우리 코드 이해를 돕는 임시 시각화 툴, 디버거 등을 만드는 쪽에서 훨씬 유용할 수 있음

    • 모든 코드가 리스크는 있지만, 모두 레거시인 것은 아님. vibe 코딩된 코드는 애초에 맥락이나 주인이 없으니 곧바로 레거시가 되는 느낌임

    • 모든 코드가 레거시냐는 반론에, 오히려 내가 아주 깊이 이해하는 프로젝트에서 버그의 원인을 한 번에 짚을 수 있고, 머릿속에서 새 기능의 구현을 그릴 수 있는 건 레거시가 아님

  • 내 생각엔 "코드를 수학적으로 바라보는 시대"는 끝났음. 실세계와 연결된 충분히 큰 소프트웨어는 수학적 증명처럼 완벽하게 참(True)임을 보장할 수 없음. 현실 속 시스템은 형식적 보장, 경험에 의한 설계, 실험적 테스트, 노하우, 퍼포먼스 기준 등에 의존하는 공학적 산물임.
    이런 경향은 가장 작은 스크립트까지 확장될 것임. 대부분 소프트웨어는 수학적으로 입증될 필요조차 없음. 그저 목적만 달성하면 됨. 프로그래밍의 장인정신은 충분히 인정하지만, 이제 그 부분을 놓아야 할 때임.
    결론적으로 미래는 다음 두 선택지 중

  • 10만 줄, 50,000개의 테스트로 요구조건을 모두 보장하지만 누구도 읽기 힘든 프로그램, 총비용 5만 달러(API 토큰 비용)

  • 인간이 직접 설계해 30,000줄, 3,000개 테스트, 세련된 추상화, 똑같은 요구조건 충족, 총비용 30만 달러(개발자 인건비)
    내가 소프트웨어 소비자라면, 세부 내막에 관심 없고 가격만 본다면 무조건 6배 더 싼 걸 고름

    • 새 외부 요구로 인한 변경이 필요해질 때를 생각해야 함. 이런 경우, 해당 소프트웨어가 비즈니스의 핵심이라면 곧바로 공급자를 바꿀 수밖에 없음. 그래서 B2B든 B2C든 유지보수와 지원이 반드시 중요함. 소프트웨어는 항상 변화에 대응할 수 있어야 함

    • 즉 “이 코드는 내가, 그리고 Copilot만이 이해했다. 이제는 Copilot만이 안다”라는 농담도 나옴

    • "실세계와 연결된 충분히 큰 시스템은 수학적으로 옳다고 입증할 수 없다"는 데 대해 형식 검증에 종사하는 사람들은 격렬하게 반박할 수도 있고, 속으론 동의할 수도 있음

    • 두 시나리오 중에서 버전업할 때 어디가 더 싸고 빠른지 물어봐야 함. 지금 당장은 인간 개발자 모델 쪽이 저렴하다고 생각하지만, 미래는 확신할 수 없음

    • 사실 두 가지 옵션 모두 현실에선 거의 본 적이 없음

  • 궁극의 발전 단계는, 인간이 읽을 필요조차 없는 완전히 기계 지향적 프로그래밍 언어가 아닐까 싶음. LLM이 굳이 Python이나 Swift처럼 사람이 이해하기 좋은 언어로 변환할 필요가 뭐가 있나? 그냥 바로 동작 가능한 결과만 있으면, 더 이상 유지보수 개념도 무의미해짐. 아직 그 단계는 아니지만, 언젠가는 여기로 갈 것 같음

    • 좋은 소프트웨어란 항상 유지보수 중이어야 함. 새로운 요구가 끝없이 나오니까 기능 배포 한번 하고 영원히 끝이라는 믿음부터가 농담거리임. 미래 변화를 염두에 두고 만든 코드, 테스트, 문서가 그래서 중요함. LLM이 무의미한 블랙박스 코드를 양산한다면 그것만큼 무서운 일 없다고 생각함. LLM이 인간 수준 코딩에 도달해 그걸 아무도 신경 안쓰게 된다는 건 공상과학의 영역임. 코딩은 실질적으로 유용한 소프트웨어를 만드는 전체 과정의 일부에 불과함

    • 사실 기계어가 이미 그런 수준 아닌가? LLM은 인간이 읽을 인터페이스에 최적화됐고, 그래서 JSON을 만들고 BSON은 거의 안씀

    • 이걸 도대체 어떤 문제를 해결한다고 할 수 있을지 의문임. 만들어지는 문제는 분명함

    • 마치 LLM이 인간을 위한 코드를 학습하고, 그대로 넣고, 다시 코드를 돌려서 원하는 동작을 얻는 일종의 ‘전화 게임’ 느낌임. 정말로 행동을 바로 생성할 수 없을까라는 생각도 듦

    • 사람 읽기 힘든 언어라면 Malbolge가 대표적임. 실제 첫 "Hello World" 프로그램도 유전자 알고리즘이 만들어냄

  • 원저자임. 여러분과 나눌 대화에 신남

  • ‘vibe coding’이라는 용어는 너무 완벽한 표현임. 마치 ‘클라우드 컴퓨팅’이 엄청 확장된 것과 같음. 원래는 탄력적으로 EC2 인스턴스 켜서 작업 끝나면 날리는 걸 뜻했지만, 은유가 너무 직관적이라 Gmail조차 모두 ‘클라우드’로 불리게 됨.

답변달기