▲

2년간의 ‘vibecoding’을 끝내고 다시 손으로 코드를 쓰기 시작했다

 (atmoio.substack.com)
8P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • AI 코딩 도구를 활용해 점점 더 큰 작업을 맡기며 놀라움을 느꼈지만, 결과물의 일관성과 구조적 완성도가 부족함을 확인
  • 세부 명세서를 작성해도 AI 에이전트가 장기적 맥락을 유지하거나 설계를 진화시키지 못함, 결국 코드베이스 전체가 불균질한 조각들의 집합으로 변함
  • 코드 조각은 개별적으로는 완전해 보이지만, 전체적으로는 구조적 무질서(sloppy) 와 맥락 붕괴가 발생
  • 이러한 경험 끝에 작성자는 AI가 만든 코드로는 사용자 신뢰나 데이터 보호를 보장할 수 없다고 판단, 직접 코드를 작성하는 방식으로 회귀
  • AI 코딩은 여전히 유용하지만, 기술 부채와 개발자 통제력 상실을 초래할 수 있어 신중한 활용이 필요함

AI 코딩의 초기 흥분과 한계 인식

  • 대부분의 사용자는 간단한 작업으로 AI 코딩을 시작해 점차 복잡한 과제를 맡기며 성능에 감탄함
    • 그러나 일정 시점 이후 AI의 오류와 비일관성이 드러나며, 기대와 현실의 간극이 발생
  • 사용자는 결과가 만족스럽지 않을 때 자신의 프롬프트 문제로 돌리며 더 구체적인 명세를 작성하려 시도
    • Obsidian 등 도구를 이용해 세밀한 스펙 문서를 작성하지만, AI가 이를 장기적으로 발전시키지 못함

명세 기반 접근의 실패

  • 실제 개발에서는 설계 문서가 발견과 구현 과정에서 지속적으로 변하는 ‘살아 있는 문서’ 임
    • 그러나 AI 에이전트는 초기 명세에 고정되어 유연한 수정이나 재해석이 불가능
  • 복잡한 구조를 다루는 동안 에이전트는 문제의 전체 맥락을 잃거나, 무리하게 진행하는 경향
    • 결과적으로 코드가 겉보기에는 완전해 보여도 내부 일관성과 구조적 무결성이 결여됨

코드 품질의 붕괴와 ‘vibecoding’의 한계

  • AI가 작성한 코드는 부분적으로는 훌륭해 보이지만, 전체적으로는 의미 없는 조합이 됨
    • 작성자는 코드베이스 전체를 검토한 후, 그 안에 ‘순수한 난잡함(slop)’ 이 존재함을 발견
  • AI는 프롬프트와 자기 일관성에는 충실하지만, 전체 시스템의 조화나 인접 패턴의 일관성을 고려하지 않음
    • 이는 마치 소설의 일부 문단은 훌륭하지만, 전체 장(chapter)은 엉망인 ‘vibewriting’ 과 유사한 현상

인간 중심 개발로의 회귀

  • 작성자는 AI가 생성한 코드를 제품으로 배포하거나 사용자 데이터 보호에 활용할 수 없다고 판단
    • “이 코드로 사용자에게 거짓말하지 않겠다”는 결심과 함께 직접 코딩으로 복귀
  • 직접 작성 시 속도, 정확성, 창의성, 생산성이 오히려 향상됨을 체감
    • 단순한 코드 생성 속도가 아닌 전체 개발 효율을 기준으로 평가할 때 인간의 우위 확인

AI 코딩의 지속적 활용과 경계

  • 작성자는 여전히 일부 작업에서 LLM을 제한적으로 활용(약 40%)
    • 반복 작업이나 단순 코드 생성에는 유용하지만, 기술 부채와 코드 이해도 저하가 누적됨
  • 장기적으로는 개발자가 코드베이스의 정신적 모델을 잃고, AI 없이는 문제 해결이 불가능해지는 위험 존재
    • 이동 중(기차·비행기 등)에는 AI 의존으로 인해 생산성이 0%가 되는 상황도 발생
  • 다른 개발자들은 “‘명세만 잘 쓰면 된다’는 사고는 워터폴 모델의 재현이며, 실제 개발은 즉흥적 탐색과 상호작용이 필수라고 지적

결론

  • AI 코딩은 여전히 강력한 도구지만, 전체 시스템의 맥락과 구조적 일관성을 유지하는 능력은 부족
  • 인간 개발자의 직관적 판단과 즉흥적 조정 능력이 여전히 핵심이며,
    AI는 보조 수단으로서 신중히 통제된 방식으로 사용해야 함
▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 나는 AI가 기초적인 것들을 너무 잘한다는 점이 오히려 위험하다고 봄
    학생들이 “AI가 대신 해주니까”라며 직접 코드를 안 쓰게 되고, 그 결과 중간 단계나 어려운 개념을 몸으로 배우지 못하게 됨
    나는 CS 교사로서 학생들에게 “기계가 아니라 네가 직접 코드를 써야 한다”고 강조함

    • 학습은 근육 운동과 같음
      포크리프트로 무게를 드는 건 쉽지만, 근육은 안 생김
      배우는 과정에서의 고통이 바로 성장의 핵심임
      물론 직장에서는 결과물이 더 중요하지만, 그래도 고차원적 사고를 할 사람은 필요함
    • 최근 면접에서 이런 문제를 실제로 봤음
      지원자는 이론 지식은 완벽했지만, 자신이 쓴 코드의 작동 원리를 전혀 설명하지 못했음
      결국 “GenAI가 대부분 작성했다”고 고백했는데, ‘배운 것’과 ‘직접 해본 것’의 괴리가 너무 컸음
    • 교육 방식도 바뀌어야 함
      코드를 ‘어떻게 짜는가’보다 ‘코드가 어떻게 작동하는가’를 가르치는 게 더 중요함
      예전엔 어셈블리어로 직접 짜던 시절이 있었지만, 지금은 그보다 컴파일러의 원리를 이해하는 게 더 가치 있음
      실제로 대부분은 컴파일러나 OS를 직접 만들 일은 없지만, 그 원리를 아는 게 프로그래밍 언어의 한계를 이해하는 데 도움 됨
    • “기계가 코드를 짜게 해선 안 된다”는 말은 예전에도 있었음
      컴파일러가 처음 나왔을 때도 같은 논쟁이 있었고, 결국 우리는 더 높은 추상화 단계로 올라갔음
    • 나는 코드를 ‘사고의 도구’ 로 봄
      단순 구현만으로는 사고가 깊어지지 않음
      AI에게 구현을 맡기면, 결국 ‘눈 가린 사람끼리 길 찾기’가 됨
      직접 코드를 다루며 생각하는 과정이 필수적임

  • 나는 “AI가 간단한 일은 잘하지만 큰 일은 더 잘한다”는 말에 공감하지 못함
    실제로는 늘 실망스러운 결과만 얻었음
    코드가 제대로 작동하지 않거나, 반복적인 수정 지시가 필요했음
    피드백 루프가 어렵다면 결국 스스로가 유일한 피드백원이 되고, 그때 AI의 한계를 절감하게 됨

    • 나는 AI에게 구체적인 명세를 주면 꽤 잘 작동함
      예를 들어 TaskManager 구조나 메모리 소유권 규칙 등을 명확히 설명하면, 테스트까지 통과하는 코드를 잘 만들어줌
    • AI 활용은 피드백 루프의 질에 달려 있음
      Ryan Dahl처럼 “이제 코드를 직접 안 쓴다”는 사람도 있지만, 그건 반복적 피드백을 통해 협업하듯 다듬었기 때문임
      AI는 아이를 가르치듯 다뤄야 함
    • 프롬프트를 따로 문서로 정리해두면 좋음
      입력·출력·예상 오류를 명확히 기술하고, 반복 실험하며 수정함
    • 나는 Beads라는 툴을 써서 작업을 세분화함
      Claude가 질문하고, 리서치하고, 코드 리뷰까지 해줌
      마치 유능한 주니어 개발자를 멘토링하는 느낌임
    • 반면 어떤 사람은 Opus 4.5로 완벽히 작동하는 코드를 얻는다며, “두 개의 다른 세계가 존재하는 것 같다”고 말함

  • 나는 “vibe coding”을 처음엔 열린 마음으로 시도했지만 점점 회의적으로 변함
    반복적이고 명확한 코드에는 좋지만, 비즈니스 핵심 로직에는 부적합함
    Claude는 종종 명세를 무시하거나, 같은 로직을 여러 번 반복하거나, 수정한다고 해놓고 그대로 두는 경우가 많음
    모델이 점점 둔해진 느낌도 있음
    지금은 설계 논의나 디버깅용으로만 사용함

    • 좋은 코드는 본질적으로 간결함임
      AI가 채워주는 ‘지루한 부분’이 많다는 건, 애초에 코드 구조가 잘못된 것일 수도 있음
    • 코딩의 어려움은 코딩 자체가 아니라 요구사항을 구현 계획으로 바꾸는 과정임
      이 부분에서 LLM은 여전히 도움이 됨
      많은 개발자는 어차피 이미 정해진 설계안을 받아서 구현만 하므로, AI가 속도를 높여줄 수 있음

  • 나는 “AI가 설계 변경을 반영하지 못한다”는 주장에 동의하지 않음
    오히려 “그게 바로 인간의 역할”임
    예를 들어 API 구조를 바꾸라고 하면, AI는 관련된 모든 부분을 찾아 수정하고 테스트까지 돌릴 수 있음

    • 하지만 LLM이 만든 테스트는 종종 과도하거나 부족함
      구현 세부사항에 집착하거나, 개념적 검증이 빠져 있음
      그래도 인간이 쓴 테스트도 비슷하니 이해는 감
    • 나는 AI가 만든 코드가 부분적으로는 좋아 보여도 전체적으로는 엉성하다는 점을 느꼈음
      직접 코드를 쓰지 않으면 추상화의 거칠고 불균형한 부분을 체감할 수 없고, 그게 결국 구조적 품질 저하로 이어짐
    • AI가 한 번에 수백 줄을 쓰는 반면, 나는 한 함수씩 만들며 개선점을 발견함
      이 차이가 코드의 완성도를 가름함
    • AI가 만든 코드가 마음에 안 들 때 수동으로 고치다 보면 ‘죄책감’ 이 들기도 함
      하지만 중요한 건, 어떤 작업이 정말 수동 개입이 필요한지 판단하는 능력임
    • Opus 4.5 이후로는 AI가 일주일 걸릴 일을 몇 시간 만에 해줌
      다만 고급 구독(예: Claude Max 200달러)을 써야만 효율이 나옴
    • 어떤 사람은 “개발자의 일은 검증된 코드를 전달하는 것이지, AI를 관리하는 게 아니다”라며 반박함
      AI 도구 숙련도를 객관적으로 평가할 방법이 필요하다고 지적함

  • 나는 “vibe coding을 2년 전부터 했다”는 말에 의문을 가짐
    Karpathy가 이 용어를 만든 건 불과 1년 전임 (출처)

    • 어떤 사람은 GPT-4로 자기 자신을 수정하는 Python 프로그래머를 만들었다고 함
      GPT가 스스로 사용할 API를 설계하고, 그에 맞춰 구현하게 했다는 점이 흥미로움
      하지만 이후 모델들이 자기 수정·복제 관련 대화를 차단하기 시작했다고 함
    • 다른 사람은 “용어는 새롭지만, Copilot이나 Cursor로 이미 다들 그렇게 코딩하고 있었다”고 말함
    • 요즘은 ‘vibe coding’을 단순히 AI가 코드를 대신 짜주는 행위 전반으로 쓰는 경우가 많음
      완전한 에이전트형 도구가 아니어도, ChatGPT나 Claude로 충분히 가능함
    • 어떤 이는 “AI가 만든 코드는 처음엔 좋아 보이지만 엉망이었다”는 단계를 지나,
      이제는 리서치 단계부터 AI와 협업해 좋은 결과를 얻는다고 함

  • 나는 학생들에게 “스포츠를 TV로 본다고 운동이 되는 건 아니다”라고 말함
    vibe coding도 마찬가지로, 직접 손으로 코드를 써야 얻는 성취감이 있음

    • 최근엔 Copilot 없이 직접 코드를 쳐봤는데, 문제를 하나씩 해결하며 완성했을 때 정말 뿌듯했음
    • 반대로 회사에서는 LLM 접근이 제한되어 있지만, 퇴근 후 개인 프로젝트에서는
      AI가 만들어주는 ‘반쯤 완성된 코드’ 덕분에 다시 의욕이 생김

  • 나는 진짜 엔지니어들이 ‘vibe coding’을 맹목적으로 하는지는 의문임
    나는 오히려 대화로 조각하듯 코드를 다듬는 방식을 씀
    요구사항을 제시하고, AI와 함께 설계안을 검토하며, 구조를 점진적으로 완성함
    이 과정은 느리지만, 협업과 사고의 깊이를 유지할 수 있음
    AI는 수많은 코드 학습을 바탕으로 새로운 아이디어를 제시하고, 나는 경험으로 그걸 조율함
    결국 AI는 나를 확장한 버전(me++) 처럼 느껴짐
    아직 완전한 에이전트에게 맡길 준비는 안 됐지만, 이 방식이 가장 생산적임

  • 나는 AI가 쓴 코드가 부분적으로는 훌륭하지만 전체적으로는 엉망인 소설과 같다고 느낌
    챕터 단위로 보면 완벽하지만, 전체 맥락에서는 혼란스러움

    • 어떤 사람은 “200페이지짜리 AI 소설을 읽고 만족한 적 있냐”고 반문함
      그렇다면 1만 줄짜리 vibe-coded 코드베이스가 제대로 작동하리라 기대하는 건 무리임
    • 다른 사람은 “소설은 창작이지만, 엔지니어링은 명확한 규칙을 따르므로 다르다”고 주장함
    • 또 어떤 이는 GPT-4.5로 쓴 두 편의 장편소설을 아들이 즐겁게 읽었다며 반박함
    • 이 비유는 AI 활용 능력을 평가하는 좋은 기준이 될 수도 있음
    • 나는 “인간의 손이 닿지 않은 완전한 vibe-coded 앱은 절대 신뢰하지 않는다”고 말함
      인간의 사고와 감정이 반영되지 않으면, 사용자 경험도 일관성을 잃고 인지적 마찰이 생김
    • 한 개발자는 CAD 소프트웨어를 LLM으로 보조받아 개발 중인데,
      설계가 명확할 때는 LLM이 보일러플레이트 작업을 폭발적으로 가속화해준다고 함
      하지만 디자인은 여전히 인간의 몫임
      그의 프로젝트는 GitHub 공개 버전에서 볼 수 있음

  • 나는 LLM이 만든 코드가 부분적으로는 훌륭하지만 전체 구조가 약하다는 점을 인정함
    하지만 코드베이스를 이해하고 직접 검토하면 충분히 보완 가능함
    vibe coding은 프로토타입 제작에는 훌륭함
    빠르게 감각을 잡고, 이후 리팩터링하며 확장하는 방식이 효과적임

    • 그러나 “코드를 직접 보지 않으면 vibe coding이 아니다”라는 의견도 있음
      즉, 결과물만 보고 판단하는 게 진짜 vibe coding이라는 주장임
답변달기