# 2년간의 ‘vibecoding’을 끝내고 다시 손으로 코드를 쓰기 시작했다 > Clean Markdown view of GeekNews topic #26148. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26148](https://news.hada.io/topic?id=26148) - GeekNews Markdown: [https://news.hada.io/topic/26148.md](https://news.hada.io/topic/26148.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-27T09:42:01+09:00 - Updated: 2026-01-27T09:42:01+09:00 - Original source: [atmoio.substack.com](https://atmoio.substack.com/p/after-two-years-of-vibecoding-im) - Points: 34 - Comments: 9 ## Summary AI 코딩 도구가 빠른 생산성을 약속했지만, 실제로는 **코드베이스의 일관성과 구조적 완성도**를 유지하지 못한다는 한 개발자의 경험 공유입니다. 세밀한 명세서를 제공해도 AI는 장기적 맥락을 잃고 조각난 결과물을 내놓았으며, 이는 결국 **기술 부채와 통제력 상실**로 이어졌습니다. 작성자는 “사용자에게 거짓말하지 않겠다”는 판단 아래 직접 코딩으로 돌아갔고, AI는 반복 작업 등 **제한된 영역에서만 활용**하는 방향으로 전환했다고 합니다. ## Topic Body - **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는 보조 수단으로서 신중히 통제된 방식으로 사용해야 함** ## Comments ### Comment 50040 - Author: alfenmage - Created: 2026-01-27T23:16:44+09:00 - Points: 3 바이브 코딩 개념이 만들어진 지가 만 1년이 채 안 되었는데 무슨 sns식 허세인지 원 ㅋㅋ ### Comment 50355 - Author: jjw9512151 - Created: 2026-01-31T15:34:26+09:00 - Points: 1 명세깎는데 공들이는게 필요하죠.. 명세를 징짜로 소프트웨어 공학때 배운 FM대로 만들고 다듬음 다음 추적성관리 하면서 업데이트하며 작업하면 좋습니다. 플젝하면서 항상 명세서 템플릿 및 프롬프트 버전을 계속 올리는데 이제는 슬슬 진짜로 소프트웨어 공학을 좀더 심도있게 공부해야하나 싶더군요. ### Comment 50193 - Author: [hidden] - Created: 2026-01-29T12:30:22+09:00 - Points: 1 [숨김 처리된 댓글입니다] ### Comment 50132 - Author: dopeflamingo - Created: 2026-01-28T19:07:40+09:00 - Points: 1 작성자는 여전히 일부 작업에서 LLM을 제한적으로 활용(약 40%) ---- 위처럼 기술된 것 보니 저자도 완전히 AI를 버리자는 의견은 아닌 것 같습니다. ### Comment 50114 - Author: zkj9404 - Created: 2026-01-28T16:41:51+09:00 - Points: 1 잘 활용하는 방법을 계속 생각해야 할 때 같습니다. AI를 버리고 개발을 하겠다는건 조금씩 뒤처지는거라 생각듭니다. 이 글의 작성자는 이미 잘 활용하는 방법을 사용했지만, 그럼에도 불구하고 AI를 더 잘 활용하는 방향으로 고민해야 한다 생각합니다. (아직 시행착오가 많을뿐...) ### Comment 50051 - Author: goodnvin - Created: 2026-01-28T08:34:02+09:00 - Points: 1 명세를 업데이트 하세요 ### Comment 50054 - Author: cosine20 - Created: 2026-01-28T09:09:45+09:00 - Points: 1 - Parent comment: 50051 - Depth: 1 맞습니다. 훅을 걸어서 구현이 완료되면 명세를 업데이트 할 수도 있고, 그게 아니어도 수동으로 명세 업데이트하는 command나 skill을 추가하면 되는데 ㅋㅋ ### Comment 50047 - Author: cshj55 - Created: 2026-01-28T05:41:10+09:00 - Points: 1 아 늙기 실타 ### Comment 49985 - Author: neo - Created: 2026-01-27T09:42:01+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46765460) - 나는 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년 전임 ([출처](https://x.com/karpathy/status/1886192184808149383)) - 어떤 사람은 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 공개 버전](https://github.com/AdaShape/adashape-open-testing/releases/tag/adashape-alpha-0.1.4)에서 볼 수 있음 - 나는 LLM이 만든 코드가 **부분적으로는 훌륭하지만 전체 구조가 약하다**는 점을 인정함 하지만 코드베이스를 이해하고 직접 검토하면 충분히 보완 가능함 vibe coding은 **프로토타입 제작**에는 훌륭함 빠르게 감각을 잡고, 이후 리팩터링하며 확장하는 방식이 효과적임 - 그러나 “코드를 직접 보지 않으면 vibe coding이 아니다”라는 의견도 있음 즉, 결과물만 보고 판단하는 게 진짜 vibe coding이라는 주장임