Vibe Coding - 바이브 코딩

• Andrej Karpathy는 LLM이 충분히 좋아지면서 코드 자체를 거의 의식하지 않고 만드는 새 방식으로 vibe coding을 말함
• Cursor Composer와 Sonnet, SuperWhisper 음성 입력을 조합해 키보드를 거의 쓰지 않고 요구사항을 말로 전달함
• 패딩을 절반으로 줄이는 사소한 요청도 직접 찾지 않고 맡기며, diff를 읽지 않은 채 Accept All을 누름
• 에러 메시지는 설명 없이 복사해 붙여넣고, LLM이 버그를 못 고치면 우회하거나 임의 변경을 반복해 문제가 사라지게 함
• 주말용 일회성 프로젝트에는 쓸 만하지만, 코드가 이해 범위를 넘어 커질 수 있어 코딩보다 보고 말하고 실행하고 붙여넣는 방식에 가까움

---

“vibe coding”의 작업 방식

• vibe coding은 LLM에 전적으로 맡기며 코드 존재 자체를 잊는 데 가까운 방식임
• 도구 예시는 Cursor Composer with Sonnet이고, 음성 입력에는 SuperWhisper를 사용함
• 직접 코드를 찾거나 수정하기보다 다음 흐름을 반복함
  • 화면에서 필요한 변경을 봄
  • Composer에 말로 요청함
  • 결과를 실행함
  • 에러 메시지를 복사해 붙여넣음
• diff는 더 이상 읽지 않고 Accept All을 항상 누름
• 코드가 평소 이해 수준을 넘어 커지면, 실제로 이해하기 위해 한동안 코드를 읽어야 하는 상태가 됨

한계와 예시

• LLM이 버그를 고치지 못할 때도 있음
  • 이때는 버그를 우회함
  • 또는 임의 변경을 계속 요청해 문제가 사라질 때까지 시도함
• 이런 방식은 throwaway weekend projects에는 나쁘지 않다고 평가함
• 한 시간가량의 vibe coding으로 Battleship 게임도 만들었음
  • 사용자가 선택한 임의의 두 LLM 모델이 실시간으로 서로 싸우는 형태임
  • 강한 통계는 아직 없지만, 4o가 4o-mini를 이기는 것 같다고 말함

[GN⁺]

Hacker News 의견들

• 직접 써보니 꽤 괜찮지만 환각은 확실히 조심해야 함
  예를 들어 내 소개 보고서를 500단어로 작성하게 했더니 최소 3개 오류가 나왔음. Stack Overflow 평판을 47,000점이라고 했는데, 실제로는 프로필의 “도달한 사람 수 47k”를 평판 525점과 혼동한 것이었음. 또 내가 PHP monkey-patching 답변을 했다고 인용했지만, 실제로는 15년 전 내가 질문한 것이고 답변자는 다른 사람이었음. 마지막으로 인터뷰 인용문도 내 것이 아니라, 함께 회사를 창업한 형제의 인터뷰였음
  출발점으로는 쓸 만하지만, 결과는 반드시 출처 링크를 따라가며 검증해야 함

  • “꽤 괜찮지만 환각 조심”이라는 평가는 문제를 너무 가볍게 봄. 아무 말이나 지어내는 사람을 채용하지도 않고 오래 고용하지도 않을 텐데, 왜 이런 “AI” 도구는 흥미로운 연구 프로젝트 이상으로 불러도 된다고 보는지 모르겠음. 신뢰성이 어느 정도 생길 때까지 대형 언어 모델을 다시 설계 단계로 돌려야 하지 않나 싶음
  • 이걸 유용한 출발점이라고 보긴 어렵고, AI에 낙관적인 입장에서도 그렇다고 봄. 꼼꼼한 인턴이라면 안 할 사실 오류가 잔뜩 든 보고서는 쓸모없는 것보다 더 나쁨
    어려운 부분이 문장 작성이라면 직접 조사해서 개요를 쓰고, 대형 언어 모델에는 완성된 문장으로 바꾸게 하는 편이 차라리 빠름. 다만 그렇게 하면 결국 산문 스타일이 작업에서 가치가 낮은 부분이라는 걸 증명하는 셈이고, 영문학 전공자였던 입장에서는 아프지만 대체로 맞는 말임
  • 직접 조사해서 500단어 보고서를 처음부터 쓰는 것과, AI가 쓴 뒤 모든 답을 팩트체크하고 수동으로 고치는 것 중 뭐가 더 빠른지 의문임. 그래서 “정답”이 필요한 일에는 AI를 쓰지 않음. 문단이나 문장을 더 읽기 좋게 고쳐 쓰는 데는 쓰지만, AI가 내놓은 정보 자체는 믿지 않음
  • “내가 Stack Overflow에 답변했다”고 잘못 기억한 건 거의 인공 치매 같음
    제품을 제대로 출시할 역량보다 훨씬 이른 시점에 내놓는 곳들이 있고, 법적 방어도 그렇게 탄탄할지 모르겠음. 다만 데이터베이스로 보조한 출력은 이런 잘못된 기억 현상을 강하게 제한할 수 있고 그래야 함. 사람처럼 아이디어를 낸 뒤 데이터와 대조하는 선형적 검증이 필요하고, 그게 실사이자 추론 과정의 일부임. 핵심 제품 진화와 다른 방향의 움직임이 연구개발을 흔들고 있는 것처럼 보이며, 일종의 미루기처럼 느껴짐
  • 최근 몇 년간 대형 언어 모델 기반 제품에 대해 내릴 평가는 정확히 “꽤 괜찮지만 환각 조심”임

• “심층 연구”라고 하면 결국 정답을 맞히는 것까지 포함해 읽힘
  이제는 완전히 틀린 답이 10%만 나와도, 상식적으로 틀렸거나 자기모순이든 간에 모든 상호작용의 신뢰가 크게 무너진다고 보는 사람이 많음. 이미 아는 내용을 재확인하는 용도 말고는, 언어 모델이 실제로 모든 걸 알 만큼 크지 않고 아는 것처럼 들릴 뿐임
  원하는 것은 단순히 맞는 답이 아니라, 내가 직접 조사하는 시간보다 빠르고, 기계가 준 답을 검증하는 시간보다도 빠른 맞는 답임. 답을 아는 시험지를 학생에게 풀게 하는 것과, 내가 답을 모르는 질문에 대해 그 답을 신뢰해야 하는 것은 완전히 다른 수준임

  • 최근 기능들은 광범위한 웹 검색에 기대어 환각을 줄이려 하지만, 웹 자체가 필터링되지 않은 대형 언어 모델 출력으로 빠르게 오염되고 있다는 점이 걱정됨. 어느 시점 이후에는 시사성이 중요하지 않은 질문의 경우, 실시간 웹보다 약 5년 전 웹 스냅샷을 연구 에이전트에 물리는 편이 더 정확해질 수도 있음
  • 스스로 “LLM ≠ AI” 회의론자라고 생각하지만, 사람들이 대형 언어 모델에서 뭔가를 얻는 척하는 모습을 보면 걱정됨. 거의 서비스형 타자기 원숭이에 가까움
    여기저기 가끔 쓰기엔 유용하지만, 여기에 들어가는 돈만큼 유용하진 않음. 물론 그 돈을 받는 회사들에는 유용하겠지만. 진짜 AI라면 혼자 풀 수 있어야 한다고 기대할 예시인데, 현재 대형 언어 모델은 처참히 실패함: https://x.com/RadishHarmers/status/1885884032220643587
  • 그래서 AI 도구를 별로 유용하게 못 느꼈음. 답을 검증하고 고치는 데 쓰는 시간이, 그냥 직접 하거나 배웠을 때보다 더 오래 걸리는 경우가 많음
  • 대형 언어 모델류 AI가 실용적으로 도움이 되는 문제에는 약간 NP스러운 성격이 있다고 늘 생각했음. 문제를 푸는 건 어려워도 해답을 확인하는 건 빨라야 한다는 의미임
    오류나 환각을 받아들일 수 있는 영역이 아니라면, 사람이 해답을 확인하는 시간이 AI가 찾아내는 시간보다 지수적으로 빨라야 실질적 이득이 있음
  • 완전히 틀린 답 비율이 1년 전에는 30%, 몇 년 전에는 60%였고 지금 10%라면 언젠가는 충분히 좋아질 지점이 올 수 있음. 요즘은 답을 검증하는 방법도 점점 나아지고 있음
    모든 문제의 해법이 되진 않겠지만, 많은 공학 문제와 비슷함. 예를 들어 ORM이 모든 쿼리에 좋은 건 아니지만 상당 부분에는 충분한 것과 같음

• 이건 무섭게 느껴짐. 환각과 오류 문제를 인정하더라도, 실제 사용자는 그걸 무시한 채 출력을 자기 PowerPoint에 넣게 될 가능성이 큼
  원래도 경영 컨설팅은 충분히 나빴는데, 그래프와 통계를 마음대로 대량 생산할 수 있게 되면 더 나빠짐. 그래도 예전에는 숫자가 어디서 왔는지 뒤에서 어느 정도 이해가 있었고, 출처도 제공할 수 있었음
  이런 도구가 강력해질수록 이 결과물이 여기저기 스며드는 효과는 더 흔해질 것임

  • 정확성을 신경 쓰거나 안 쓰거나 둘 중 하나임. 신경 안 쓴다면 사람이 지어냈든 AI가 지어냈든 상관없음. 신경 쓴다면 공개 전에 팩트체크를 할 것임. 이 도구가 왜 그걸 바꾸는지는 모르겠음
  • 환각으로 만들어진 연구가 글로 발행되고, 그 글이 다른 AI 연구에 인용되면서 거짓 정보가 계속 밀려 올라가면, 나중에는 그 거짓의 출처가 어디였는지 알기 어려워짐
  • 일종의 백신처럼 볼 수도 있음. 사람이 쓴 컨설턴트 보고서 대부분은 이미 완전히 허술함. 정확도 낮고, 신호 대 잡음비 낮고, 일반론을 양으로 밀어붙이는 형식임
    대형 언어 모델은 사람들이 이런 정보 가치 낮은 콘텐츠에 면역을 갖게 만들고 있음. LLM 수준의 결과물을 내는 사람들은 이제 LLM을 썼다는 의심을 받으며, 더 이상 가치를 더하는 척하기 어려워짐. 결과적으로 컨설턴트에게 더 높은 품질이 요구되고, 정확하고 통찰력 있으며 맥락에 맞는 정보 대신 장황한 말만 생산하는 사람들은 걸러질 것임
  • 솔직히 컨설팅을 해봤고 아직 하는 친구들도 많은데, McKinsey 보고서도 네 번 중 세 번은 현실에 아주 탄탄히 기반하지 않고 추정이 많이 들어감
  • 그 배는 Facebook이 허위 정보 확산을 자유롭게 놔둔 시점, 아니면 그 이전에 이미 떠났다고 봄

• Gemini도 한두 달 전부터 같은 이름의 Deep Research를 갖고 있었음: https://blog.google/products/gemini/google-gemini-deep-resea...
  메타 질문으로, AI 업계에서는 왜 이렇게 이름이 겹치는지 궁금함. Triton(Nvidia, OpenAI)이나 Gro{k,q}(X.ai, groq, OpenAI)가 떠오름

  • OpenAI Triton 제작자에 따르면, “Triton”이라는 이름은 2019년 중반 박사 논문을 공개할 때 붙였음. 1년 뒤 “TensorRT Inference Server”가 “Triton Inference Server”로 바뀌었지만, 자신의 박사 지도교수들이 프로젝트와 연결되는 유일한 이름이라 바꾸지 않았다고 함
  • “메타 질문”이라면 쿼리 앞에 “@Meta AI”를 붙여야 할 것 같음
  • 특정 용어의 재정의를 영업과 홍보에 맞춰 함께 밀어붙이는 비공식 업계 단체 같은 느낌임. 처음에는 “지능”, 그다음은 “오픈 소스”, 그다음은 “추론”을 가져갔고 계속될 것임
    홍보에는 필요하지만 실제로 달성하지 못한 단어는 재정의됨. “grok”이 완벽한 예인데, 원래 SF 책에서는 “완전한 이해”를 뜻했음. 신화 속 Triton은 깊은 바다를 다스렸으니, “딥 러닝” 영업 문구가 곧바로 가져간 셈임
  • Gemini 버전을 출시 때 써보고 싶었지만, 사는 나라가 틀렸던 것 같음. 미국 밖에서는 안 되는 듯함. OpenAI와 DeepSeek에는 그런 문제가 없는데 아쉬움. 기꺼이 돈을 낼 생각이 있는데도 받지 않음
  • Gemini 버전은 그다지 “깊다”고 보긴 어려움. 정보를 많이 띄워주지만 꽤 피상적임. OpenAI 버전은 진짜 깊이에 한 걸음 더 다가간 것처럼 보임
    직접 해보면 대형 언어 모델이 제대로 깊이 들어가게 만드는 건 꽤 어려움. OpenAI의 Deep Research는 대형 연구소가 이걸 어떻게 할 수 있는지 보여주는 첫 사례 중 하나처럼 느껴짐. 보통 어려운 부분은 “에이전트” 자체가 아니라, 모델이 깊이 들어가는 걸 잊지 않게 강제하는 일임

• 잘 눈치챘는지 모르겠지만, 이 기능은 공개되지 않은 o3 모델로 구동되는 듯함. 벤치마크에서 크게 앞서는 이유와 o3가 공개 출시하기엔 너무 비싸다는 주장과도 맞아떨어짐. Google, DeepSeek, Perplexity보다 앞서는 인상적인 모델로 보임

  • 공개 벤치마크에서 이 도구/시스템만 도구와 웹에 접근할 수 있었음. 그래서 성능 향상은 엄밀히 말하면 그 때문일 가능성이 크다고 봄
    o3가 대중에게 공개하기엔 너무 비싸다면, 질문 하나에 수백 번 추론 호출을 해야 하는 도구에 왜 쓰겠음? 훨씬 싼 모델을 쓸 것임. 아마 o3-mini나 o1-mini에, 일부 작업은 o4-mini를 조합했을 가능성이 큼
  • 비싸다는 건 더 비싸게 받고 싶었다는 뜻이었을 수 있는데, DeepSeek가 그들의 손을 강제로 움직였음
  • 이 작업 환경에서의 효과는 특정 모델 하나를 훨씬 넘어서는 문제 아닌가 싶음. 연구 작업의 각 단계마다 같은 크기 모델 하나만 쓴다면 바보 같은 선택일 것임
    최종 답을 종합하거나 상충하는 출처 사이에서 고를 때는 o3가 유리할 수 있지만, 그 지점까지 가려면 아주 많은 단계가 필요함
  • o3가 10개월 뒤 출시되면 그때의 DeepSeek, Google, Meta보다 한 세대 앞서 있을 거라 확신함. 정말 인상적임
  • 이게 공개되지 않은 o3로 구동된다고 믿는 근거가 궁금함

• 학계에서 일하는 사람들에게는 실제로 흥미로운 도구임. 시험해보고 싶지만 지금은 월 200달러를 감당할 수 없음
  다음 프롬프트로 테스트해줄 수 있는 사람이 있으면 좋겠음. 입자물리학 연구 보조원으로서 CERN의 Future Circular Collider(FCC), International Linear Collider(ILC), Compact Linear Collider(CLIC), 여러 Muon Collider 제안과 2024년 기준 주요 차세대 입자 충돌기 계획을 에너지 범위, 충돌 유형, 일정, 기술적 장단점, 비용, 물리 목표, 설계 보고서, 국제 협력, 비용 대비 효과, 발견 가능성, 인프라, 환경 영향, 업그레이드 경로까지 비교하는 기술 요약으로 작성하라는 요청임

  • o3-high로 돌려봤고 결과 링크는 여기 있음: https://chatgpt.com/share/67a0b227-8ee4-800f-a8ed-882e7bab97...
    원문 출력은 HN에 다 적기엔 너무 길었고, FCC, ILC, CLIC, Muon Collider, CEPC/SppC 등을 대상으로 계획 에너지, 충돌 방식, 일정, 비용, 기술 난제, 물리 목표, 국제 지원, 환경 영향, 장기 업그레이드 경로를 표와 출처 형식으로 비교하는 보고서 형태였음

• 이 능력이 정말 AGI와 ASI의 전제조건인지 의문임
  추론, 문제 해결, 연구 검증은 근본적으로 모두 정제된 사고에 가까움. 연구는 여전히 그 중요성에 회의적인 영역인데, 유효한 증명은 정리된 답이 아니라 실행 결과에서 나오기 때문임
  예를 들어 인터넷에서 최고의 청소기를 아무리 조사해도 직접 써보기 전까지는 마케팅, 가짜 리뷰, 인플루언서 사이에 갇히게 됨. 과학 분야는 지루해서 이런 문제에서 좀 보호될 수도 있지만, 제약회사가 고급 의학 “연구 결과”를 담은 맞춤형 블로그 글로 인터넷을 채워 원하는 논문 분위기를 만들 수 있다고 생각하면 무서움. 어느 시점에는 인터넷을 전혀 믿을 수 없게 될 수 있고, 그 시점이 곧 올지도 모름
  생성 텍스트가 폭증하면서 연구의 가치는 엄청난 정보 쓰레기 때문에 많이 줄어들 것 같음. 인터넷이 아직 “진짜”였던 시절에 하던 일로 남을 수도 있음

  • 그런 종류의 용도에는 이 도구를 쓰지 않으면 됨. 그래도 지적은 타당함
    예전에 Hydroflask, Klean Kanteen, Thermos가 뜨거운/차가운 음료에서 어떻게 다른지 비교하려고 실제 측정이 있는 글을 찾았는데, 대부분의 Google 검색 결과는 하드 데이터 없는 일반 비교였음. 그런데도 “Hydroflask가 따뜻한 음료에 더 좋다” 같은 글이 상위에 노출됐음
    이 도구가 그런 글을 무시하고 실제 실험이 있는 글만 쓰게 할 수 있을지, 또 한 사람이 한 실험을 여러 블로거가 반복 인용한 중복 결과를 걸러낼 수 있을지가 관건임
  • 그건 “AGI”를 어떻게 정의하느냐에 전적으로 달림
  • 이건 기능 하나라기보다 거대한 지형에서 한 방향임. 검색 같은 여러 작업, 그리고 추론과 결합한 연구를 더 잘하게 되는 것은 모델을 AGI에 더 가깝게 만듦
    AGI라면 이런 작업을 할 수 있을 것이고, 이런 능력들의 벤 다이어그램이 늘어날수록 AGI의 근본 메커니즘일 수 있는 것을 좁혀볼 수 있음. Moravec은 인간 능력의 지형이 AI 능력에 의해 서서히 잠기는 이미지를 말했는데, AI가 인간이 할 수 있는 모든 것을 실제로나 원리상 할 수 있는 시점에 진정한 범용 AI에 도달했다고 알게 될 것임. Deep Research는 그 홍수에 잠겨가는 또 하나의 섬일 뿐임

• 그래프를 제대로 이해했다면 내부 테스트 통과율이 20% 에 그치는 것 같음. 그렇다면 30분 기다리고 비싼 돈을 내고도, 대체로 틀렸을 가능성이 높은 긴 텍스트 벽을 뒤져야 한다는 뜻인가 싶음
  환각 가능성이 무시해도 될 정도가 아니라면 한 번에 검토할 내용이 너무 많음. 과정이 훨씬 더 반복적이어야 할 것 같음

  • 그 20%를 달성하는 문제 유형 예시는 이런 수준임. 두 함자 사이의 자연 변환을 끝(end)으로 표현하고, 자연 공변환을 코끝(coend)으로 정의한 뒤, 대칭군 Σ4와 Σ7의 delooping nerve 아래 ∞-범주를 두고 자연 공변환의 개수를 묻는 식임
    즉 일반적인 질의가 아니라 최첨단 수학 벤치마크에 가까운 문제임
  • Humanity’s Last Exam에서 26.6% 통과율이면 사실 인상적임. 통과율은 과제 난이도 맥락에서 봐야 함
  • 최첨단 벤치마크 수준의 질문을 할 때에나 해당되는 얘기임
  • 데이터가 부족해 단정하긴 어려움. 한 번의 질의가 하루치 일을 해낸다고 가정하면, 5일치 작업을 검토하는 데 하루보다 덜 걸릴 때는 합리적으로 쓸 수 있음
    실제 연구처럼 준비 작업량이 최종 산출물보다 큰 경우에는 개념적으로 잘 맞을 수 있음. 벤치마크를 대충 보면 연말쯤에는 질의당 50%를 넘길 수도 있어 보이고, 모델 한두 세대마다 두 배로 뛰는 것 같음
  • 그 분야 전문가도 정확히 답하기 어려운 문제들에서 나온 수치임

• 블로그권에는 좁은 분야에서 알려진 전문가나 그 분야에서 유명한 사람들이 있고, 유용한 글을 쓰는 사람도 훨씬 많음. 적어도 다른 인간이 읽어주길 바라는 의미에서 글을 쓰는 것임
  그런데 독자가 전부 봇이 되면 이들이 계속 쓸지 궁금함. 죽은 인터넷이 다가오는 느낌임

  • 봇만 읽는 글쓰기라도 방법을 알 수 있다면 좋다고 봄. 학술 논문도 실제로는 제대로 읽히지 않고, 인용을 위해 잠깐 훑는 경우가 많으며, 저널 논문이나 학위논문 같은 큰 출판물은 더 그렇음
    그래도 사람들이 쓰고 싶을 때 쉽게 접근할 수 있는 지식 세계에 기여할 수 있다는 점은 저자로서 매력적임. 더 이상 제목만 관련 있어 보이는 논문들을 힘들게 뒤질 필요도 없고, 다른 사람이 내 논문을 힘들게 읽지 않아도 괜찮음
  • 당연히 계속 쓸 것임. 아무도 자발적으로 보지 않을 사진을 찍으려고 감당 가능한 가장 큰 카메라를 들고 수백 장씩 찍는 사람도 많음

• 실제로 이 기능에 접근 권한이 있는 사람이 있나 궁금함. 웹사이트에는 오늘부터 Pro 사용자에게 제공된다고 되어 있는데, 회사 계정으로 Pro가 있어도 메시지 작성기에 Deep Research 옵션이 안 보임

  • Pro이고 미국에 있는데 아직 안 보임
  • 약 3시간 전부터 접근 가능해졌음. 일부 기능이 늦는 Windows 데스크톱 앱에서도 보임
    아무 모델이나 열면 웹 검색 옵션 옆 입력창에 (Deep research) 태그가 나타남. 캐시를 지우거나 하진 않았음
  • Pro인데 아직 안 보임
  • Pro 구독 중인 지인 두 명도 아직 접근 권한이 없다고 함
  • 미국 거주, Pro 사용 중인데 아직 접근 불가임

[GN⁺]

Hacker News 의견들

• 매년 소프트웨어 품질 기준이 더 낮아질 수 없다고 생각하지만, 매번 그 생각이 틀림을 깨닫게 됨

  • 왜 제대로 하지도 않을 일을 굳이 하는지 이해가 안 됨
  • 마치 아무렇게나 못 자른 나무를 못질해 의자 비슷하게 만든 뒤 앉는 것과 같음
  • “그냥 앉을 자리만 필요할 때도 있음” 이라는 말도 있지만, 그래도 최소한의 완성도는 있어야 한다고 느낌
  • 어떤 사람들은 영어에 자신이 없어 LLM에 완전히 의존하게 되었는데, 그 결과 자기 표현력과 자신감을 잃는 걸 봄
  • 소프트웨어에서는 처음부터 ‘의자’를 만든다는 걸 아는 경우가 드묾
    • 결국 탐색적 프로그래밍이나 프로토타이핑의 다른 이름일 뿐임
  • 때로는 목적지가 중요하지 않고, 그냥 빨리 어딘가 도달하고 싶은 마음일 뿐임
    • 피곤해서 잠깐 바닥에 앉는 사람을 꾸짖는 것과 같음
  • 요즘은 코드가 실제 하드웨어에서 실행된다는 현실감이 사라진 것 같아 걱정임
    • 젊은 개발자들이 코드의 물리적 결과를 이해하지 못하는 경우가 많음
    • AI와 그 하이프가 언젠가 무너질 거라 생각하지만, 품질을 지키는 싸움은 계속해야 함

• 나도 이런 식으로 가벼운 프로젝트를 할 때 즐거움을 느낌

  • 하지만 보안만큼은 절대 대충할 수 없음
  • AI 코딩 어시스턴트가 인증 없는 API를 만들거나, XSS 위험이 있는 템플릿을 생성한 적이 많았음
  • LLM을 매일 쓰지만, 보안 엔지니어의 역할은 앞으로도 충분히 남아 있을 것이라 확신함

• 이런 접근을 보면, 마치 ‘먹고 코딩하는 사람’ 이 결과물을 제출하는 느낌임

• 이런 방식으로 코딩을 시작하면 어려운 문제 해결 능력이 퇴화할까 걱정됨

  • 하지만 다른 사람은 여전히 필요한 부분은 수동으로 꼼꼼히 할 수 있다고 말함
  • 대신 새로운 걸 시도하는 진입 장벽이 낮아져서 훨씬 자유롭게 탐색할 수 있음

• 요즘은 처음부터 이런 방식으로 배우는 AI 네이티브 개발자들이 많아지고 있음

  • 이제는 코딩이라기보다 AI 코더 관리에 가까운 시대가 된 것 같음

• “자연어 명령으로 수정 가능한 WYSIWYG” 같은 도구는 RAD 툴의 한계처럼 급격한 난이도 절벽이 있을 것 같음

• 어떤 사람들은 “이런 식으로 배우면 안 된다”고 하지만, 나는 노력 대비 완성도를 맞추는 게 중요하다고 생각함

  • Vibe Coding은 학습과 탐색에 좋은 방법임
  • 새로운 노력–완성도 스펙트럼을 열어줄 수 있음
  • 다만 Fred Brooks의 말처럼, 첫 시도가 부족하면 과감히 버릴 수 있어야 함
    • LLM이 만든 첫 구현에 매달리면 문제를 제대로 이해하지 못한 채 잘못된 기준점에 묶일 수 있음

• CSS 정도는 Vibe Coding으로 충분하다고 생각함

  • 하지만 다른 사람은 접근성이나 반응형 디자인을 고려하면 그렇게 단순하지 않다고 반박함
  • 잘 만든 CSS는 오히려 간결하고 유지보수하기 쉬움
  • AI를 끼워 넣는 게 오히려 방해가 될 수 있음
  • 또 다른 사람은 Claude로 작은 웹 유틸리티를 완전히 구현해본 경험이 있다고 함
  • 어떤 사람은 React 기반의 검색 DSL이나 GUI 파이프라인 에디터를 같은 방식으로 만들었다며, 이 접근이 단순한 CSS 수준을 넘어선다고 설명함