AI 코딩(Vibecoding)의 환상과 현실: 2년간의 실험이 말해주는 것
관련글
2년간의 ‘vibecoding’을 끝내고 다시 손으로 코드를 쓰기 시작했다
After two years of vibecoding, I’m back to writing by hand
들어가며
2026년 1월, 한 개발자의 고백이 개발자 커뮤니티에 파장을 일으켰다. 2년간 AI 코딩 도구를 적극 활용했던 atmoio는 결국 다시 손으로 코드를 작성하는 방식으로 돌아갔다고 선언했다. “나는 이런 코드를 사용자에게 제공할 수 없다. 이것으로 사용자를 속이지 않겠다”는 그의 말은, AI 코딩 도구가 약속했던 생산성 혁명의 이면에 감춰진 불편한 진실을 드러낸다.
이 사건은 단순한 개인의 실망을 넘어, AI 개발 도구 산업 전체가 직면한 근본적인 질문을 제기한다. 우리는 정말로 AI와 함께 ‘더 나은’ 코드를 만들고 있는가, 아니면 단지 ‘더 빠르게’ 기술 부채를 쌓고 있을 뿐인가? 이 글은 atmoio의 경험과 Hacker News 커뮤니티의 다양한 반응을 통해, AI 코딩의 현주소와 앞으로의 방향을 진지하게 고찰한다.
환멸의 서사: 한 개발자의 여정
atmoio의 이야기는 많은 개발자가 거쳐온 익숙한 여정을 담고 있다. 처음 AI에게 간단한 작업을 맡겼을 때의 감탄, 점점 더 큰 작업을 맡기며 느낀 흥분, 그리고 결국 마주하게 된 깊은 실망감. 이 여정은 단순한 기술적 실패의 기록이 아니라, 우리가 AI와 맺는 관계의 본질에 대한 성찰을 담고 있다.
그가 발견한 가장 충격적인 사실은 코드의 ‘이중성’이었다. AI가 생성한 코드는 개별적으로 검토할 때는 훌륭해 보였다. Pull request에서 보는 변경 사항들은 깔끔했고, 프롬프트의 의도를 정확히 반영했으며, 문법적으로도 완벽했다. 그러나 코드베이스 전체를 통독했을 때, 그는 말로 표현하기 어려운 ‘불편함’을 느꼈다. 그것은 마치 각 문단은 훌륭하지만 전체적으로는 맥락이 무너진 소설을 읽는 것과 같았다.
이 현상을 그는 “slop”이라고 불렀다. 순수하고 희석되지 않은 난잡함. 이 단어는 단순히 코드 품질이 낮다는 의미를 넘어선다. Slop은 구조적 무결성의 부재, 전체적 비전의 결여, 그리고 무엇보다도 ‘생각하는 주체’의 부재를 의미한다. AI는 주어진 프롬프트에 충실했지만, 코드베이스 전체를 관통하는 철학이나 일관된 설계 원칙은 존재하지 않았다. 인접한 코드 패턴도 존중하지 않았고, 전체 시스템의 조화도 고려하지 않았다.
더 아이러니한 것은, atmoio가 이 문제를 인식하고 더욱 상세한 명세서를 작성하려 시도했을 때조차 상황은 개선되지 않았다는 점이다. 그는 Obsidian에 장문의 스펙 문서를 작성하고, 30분 이상을 들여 한 페이지 분량의 프롬프트를 작성했다. 마치 완벽한 설계 문서를 작성하면 중급 개발자에게 맡기듯 AI에게 맡길 수 있을 것이라 기대했다. 하지만 현실은 달랐다.
실제 소프트웨어 개발에서 설계 문서는 ‘살아있는 문서’다. 구현 과정에서 발견되는 새로운 사실들, 예상하지 못한 제약사항들, 더 나은 설계 대안들이 지속적으로 문서를 진화시킨다. 개발자는 코드를 작성하면서 끊임없이 원래의 계획을 재평가하고 수정한다. 그러나 AI 에이전트는 초기에 내린 결정에 고착되는 경향이 있었다. 설계 문서의 첫 번째 해석을 기반으로 구현을 시작하면, 이후에 더 나은 방향을 발견하더라도 그 방향으로 전환하지 못했다. 마치 터널에 들어간 기차처럼, 정해진 궤도를 벗어날 수 없었다.
결국 그는 결단을 내렸다. “나는 이 코드를 배포하지 않겠다. 사용자에게 돈을 받지 않겠다. 사용자의 데이터를 이 코드로 보호하겠다고 약속하지 않겠다. 나는 이것으로 사용자에게 거짓말하지 않겠다.” 이 선언은 단순히 코드 품질에 대한 불만을 넘어선다. 그것은 개발자로서의 직업적 양심에 대한 선언이며, AI가 아무리 편리해도 타협할 수 없는 선이 있다는 인식의 표현이다.
“Slop” 현상의 본질: 왜 AI 코드는 전체적으로 무너지는가
atmoio가 발견한 “slop” 현상은 AI 코딩의 가장 근본적인 문제를 드러낸다. 이것은 단순히 버그가 많다거나 성능이 떨어진다는 차원의 문제가 아니다. 코드는 실행되고, 테스트도 통과하며, 개별 기능도 의도대로 작동한다. 그럼에도 불구하고 경험 많은 개발자가 코드베이스를 읽을 때 느끼는 것은 깊은 불편함이다.
이 불편함의 근원은 AI가 코드를 생성하는 방식의 근본적 특성에서 비롯된다. 현재의 대형 언어 모델들은 “다음 토큰 예측”을 기반으로 작동한다. 즉, AI는 지금까지의 맥락을 보고 다음에 올 가능성이 높은 코드를 생성한다. 이 과정에서 AI는 통계적 패턴에 의존하며, 주어진 프롬프트와의 일관성을 유지하려 노력한다. 그러나 여기에는 결정적인 것이 빠져 있다. 바로 ‘의도’다.
인간 개발자가 코드를 작성할 때는 머릿속에 전체 시스템의 멘탈 모델이 있다. 이 클래스가 시스템에서 어떤 역할을 하는지, 이 함수가 전체 데이터 흐름에서 어디에 위치하는지, 이 추상화가 미래의 확장성을 위해 어떤 여지를 남겨야 하는지. 이런 고차원적 이해는 개발자가 수십 번, 수백 번 코드베이스를 읽고 수정하면서 형성된다. 이것은 단순히 코드의 문법이나 개별 함수의 동작을 아는 것을 넘어서는 암묵적 지식이다.
반면 AI는 이런 멘탈 모델을 갖지 못한다. AI는 프롬프트에 주어진 즉각적인 맥락과 학습 데이터에서 본 패턴들을 조합할 뿐이다. 따라서 AI가 생성하는 각 코드 조각은 지역적으로는 최적화되어 있지만, 전역적으로는 조화롭지 못하다. 이것은 마치 도시 계획 없이 각 건물을 개별적으로 최적화한 도시와 같다. 각 건물은 그 자체로는 훌륭할 수 있지만, 도시 전체를 보면 교통 체증, 비효율적인 배치, 일관성 없는 디자인이 난무한다.
더 근본적인 문제는 AI가 ‘설계 결정’과 ‘구현 세부사항’을 구분하지 못한다는 점이다. 인간 개발자는 어떤 것은 나중에 쉽게 바꿀 수 있는 구현 세부사항이고, 어떤 것은 시스템 전체에 영향을 미치는 근본적인 설계 결정임을 안다. 따라서 중요한 설계 결정에는 더 많은 시간을 들이고, 여러 대안을 검토하며, 동료와 토론한다. 그러나 AI는 이 둘을 동등하게 취급한다. 핵심적인 아키텍처 선택도, 변수 이름 하나도 같은 수준의 확신을 가지고 제시한다.
Hacker News의 한 댓글은 이를 날카롭게 지적했다. “AI는 나에게 ‘좋은 이야기’를 들려줬다. 마치 소설을 쓸 때 각 문단은 훌륭하지만, 전체 장을 읽으면 맥락이 무너진 것처럼.” 이 비유는 AI 코딩의 본질을 정확히 포착한다. AI는 그럴듯한 코드를 생성하는 데는 탁월하지만, 그 코드가 더 큰 시스템의 일부로서 조화를 이루게 만드는 능력은 없다.
이 문제는 프로젝트가 커질수록, 시간이 지날수록 악화된다. 처음에는 작은 불일치들이 축적되고, 이것이 점진적으로 코드베이스의 구조적 무결성을 침식한다. 마치 작은 균열이 건물의 기초에서 시작되어 결국 전체 구조를 위협하는 것과 같다. atmoio가 수개월간 축적된 AI 생성 코드를 처음부터 끝까지 읽었을 때 느낀 충격은 바로 이 구조적 붕괴의 발견이었다.
명세 기반 개발의 환상: 워터폴 모델의 재림
atmoio의 경험에서 가장 흥미로운 부분은 그가 ‘더 나은 프롬프트’를 작성하려 시도했다는 점이다. 이것은 많은 AI 코딩 실무자들이 거치는 자연스러운 단계다. AI가 만족스럽지 못한 결과를 내놓으면, 우리는 자연스럽게 “내 지시가 충분히 명확하지 않았구나”라고 생각한다. 그래서 더 상세한 명세를 작성하고, 모든 요구사항을 빠짐없이 나열하며, 예상되는 엣지 케이스까지 문서화한다.
하지만 이 접근법에는 치명적인 결함이 있다. 그것은 소프트웨어 개발을 ‘사전에 완전히 정의 가능한 문제’로 취급한다는 점이다. 이것은 1970년대에 유행했던 워터폴 모델의 기본 가정과 동일하다. 워터폴 모델은 요구사항을 먼저 완벽히 정의하고, 그다음 설계하고, 그다음 구현하며, 마지막에 테스트한다는 순차적 접근을 가정했다. 그러나 수십 년간의 소프트웨어 공학 경험은 이 모델이 현실에서 작동하지 않는다는 것을 보여줬다.
실제 소프트웨어 개발은 본질적으로 ‘발견의 과정’이다. 우리는 코드를 작성하면서 문제를 더 깊이 이해하게 된다. 처음에는 보이지 않았던 제약사항이 구현 과정에서 드러나고, 더 나은 추상화가 떠오르며, 초기 설계의 결함이 명확해진다. 애자일 방법론의 핵심 통찰은 바로 이 ‘발견’을 수용하고, 그에 따라 지속적으로 설계를 진화시키는 것이다.
Hacker News의 한 댓글이 이를 예리하게 지적했다. “실제 회사에서 1시간 동안 복잡한 아키텍처 설계 문서를 작성하고, 이것을 중급 개발자에게 전달한 뒤, ‘이 문서에 대해 아무와도 논의하지 말라’고 하고 휴가를 떠난다고 상상해보라.” 이것이 바로 우리가 AI에게 상세한 명세를 주고 기대하는 것이다. 그리고 이것이 작동하지 않는 이유는 명백하다.
AI 에이전트는 인간 개발자가 가진 가장 중요한 능력, 즉 ‘불확실성 속에서 탐색하고 적응하는 능력’을 갖지 못한다. AI는 주어진 명세를 충실히 따르려 하지만, 그 명세가 불완전하거나 잘못되었을 때 이를 인식하고 되돌아가서 재평가하는 능력이 없다. 인간 개발자라면 “잠깐, 이 접근법은 확장성에 문제가 있을 것 같은데”라고 중간에 멈춰서 방향을 재설정할 수 있다. 그러나 AI는 일단 선택한 경로를 따라 계속 전진한다. 더 나쁜 경우, AI는 명백히 막다른 길임에도 불구하고 “벽을 뚫고 나가려” 시도한다.
이 문제는 AI 에이전트가 개선되더라도 근본적으로 해결되기 어렵다. 왜냐하면 이것은 AI의 기술적 한계가 아니라, 소프트웨어 개발이라는 활동 자체의 본질에서 비롯되기 때문이다. 소프트웨어 개발은 단순히 주어진 명세를 코드로 번역하는 것이 아니다. 그것은 불완전한 이해로부터 시작하여, 구현을 통해 더 깊은 이해에 도달하고, 그 이해를 바탕으로 더 나은 설계를 찾아가는 반복적 과정이다.
따라서 “완벽한 프롬프트”를 작성하려는 시도는 근본적으로 잘못된 방향이다. 문제는 프롬프트의 품질이 아니라, 소프트웨어 개발을 명세 번역 문제로 환원하려는 시도 자체에 있다. 우리가 필요한 것은 더 긴 프롬프트가 아니라, AI와 함께 지속적으로 탐색하고 발견하고 적응할 수 있는 새로운 협업 방식이다.
개발자 커뮤니티의 다층적 반응: 스펙트럼의 양 극단
atmoio의 글에 대한 Hacker News의 반응은 놀랍도록 다양했다. 이 다양성 자체가 AI 코딩의 현주소를 보여준다. 동일한 도구를 사용하면서도, 개발자들은 극명하게 다른 경험을 보고한다. 어떤 이는 “완전히 공감한다. 나도 같은 경험을 했다”고 말하는 반면, 다른 이는 “나는 Claude Opus 4.5로 일주일 걸릴 일을 몇 시간 만에 끝낸다”고 주장한다.
이 차이는 어디서 오는가? 몇 가지 요인이 있다.
첫째, 작업의 성격이다. AI 코딩 도구는 특정 유형의 작업에 특히 잘 맞는다. 명확하게 정의된 CRUD 애플리케이션, 잘 알려진 패턴을 따르는 보일러플레이트 코드, 기존 API의 래퍼 작성 등. 이런 작업에서는 AI가 정말로 생산성을 극적으로 향상시킬 수 있다. 반면 복잡한 비즈니스 로직, 성능 최적화, 보안이 중요한 시스템, 새로운 아키텍처 패턴 등에서는 AI의 한계가 두드러진다.
둘째, 개발자의 숙련도와 작업 방식이다. Hacker News의 한 댓글은 이를 잘 포착했다. “AI를 ‘아이를 가르치듯’ 다뤄야 한다. 프롬프트를 문서화하고, 입력-출력-예상 오류를 명확히 하며, 반복 실험해야 한다.” 이 접근법은 효과적일 수 있지만, 엄청난 노력이 필요하다. 모든 개발자가 이런 수준의 AI 오케스트레이션에 투자할 여력이 있는 것은 아니다.
셋째, 품질에 대한 기준이다. 어떤 개발자는 “작동하는 코드”를 목표로 하는 반면, 다른 개발자는 “유지보수 가능하고 확장 가능한 코드”를 목표로 한다. AI는 전자의 기준에서는 만족스러울 수 있지만, 후자의 기준에서는 부족하다. atmoio의 경우, 그는 사용자의 데이터를 다루는 프로덕션 시스템을 만들고 있었기에 높은 품질 기준을 적용했고, 그 기준에서 AI 코드는 수용 불가능했다.
넷째, 프로젝트의 규모와 수명이다. 작은 프로토타입이나 일회용 스크립트에서는 AI가 훌륭하다. 그러나 수년간 유지보수될 중대형 프로젝트에서는 초기의 빠른 개발이 나중에 기술 부채로 돌아온다. 한 댓글은 이를 지적했다. “AI로 빠르게 프로토타입을 만들고, 그다음 리팩터링하며 확장한다. 하지만 처음부터 AI에게 모든 것을 맡기면 재앙이다.”
특히 주목할 만한 것은 교육에 대한 우려다. 한 CS 교사는 말했다. “학생들이 AI가 해주니까 직접 코드를 쓰지 않게 된다. 그 결과 중간 단계를 몸으로 배우지 못한다. 학습은 근육 운동과 같다. 포크리프트로 무게를 들면 쉽지만 근육은 생기지 않는다.” 이것은 AI 코딩의 가장 심각한 장기적 위험일 수 있다.
또 다른 교사는 면접 경험을 공유했다. “지원자는 이론 지식은 완벽했지만, 자신이 쓴 코드의 작동 원리를 설명하지 못했다. 결국 GenAI가 대부분 작성했다고 고백했다.” 이것은 단순히 부정행위의 문제가 아니다. 그것은 ‘아는 것’과 ‘할 수 있는 것’ 사이의 심연을 보여준다. AI 시대에 우리는 어떻게 진정한 이해와 능력을 구축할 것인가?
반대편에는 AI 코딩에 매우 만족하는 개발자들이 있다. 한 개발자는 “Claude Skills를 활용해 체계적인 워크플로우를 구축했다. Claude가 리서치하고, 질문하고, 코드 리뷰까지 한다. 마치 유능한 주니어 개발자를 멘토링하는 느낌”이라고 말했다. 이들은 AI를 단순한 코드 생성기가 아니라 협업 파트너로 활용한다.
또 다른 개발자는 “요구사항을 제시하고, AI와 함께 설계안을 검토하며, 구조를 점진적으로 완성한다. 이 과정은 느리지만 협업과 사고의 깊이를 유지할 수 있다”고 말했다. 이것은 atmoio가 시도하지 않은 접근법이다. atmoio는 AI에게 큰 작업을 한 번에 맡기려 했지만, 이 개발자는 AI와의 지속적인 대화를 통해 점진적으로 코드를 발전시킨다.
이 스펙트럼은 중요한 시사점을 준다. AI 코딩의 성공은 도구 자체의 능력만으로 결정되지 않는다. 그것은 작업의 성격, 개발자의 기술, 품질 기준, 프로젝트 규모, 그리고 무엇보다도 AI와 협업하는 방식에 달려 있다. atmoio의 실패는 AI의 절대적 한계를 보여주는 것이 아니라, 특정 작업 방식의 한계를 보여준다.
테스트와 검증: 보이지 않는 균열들
AI 코딩의 또 다른 심각한 문제는 테스트와 검증의 영역에서 드러난다. Hacker News의 여러 댓글은 이를 지적했다. “LLM이 만든 테스트는 종종 과도하거나 부족하다. 구현 세부사항에 집착하거나, 개념적 검증이 빠져 있다.”
이것은 단순히 테스트 커버리지의 문제가 아니다. AI가 작성한 테스트는 종종 ‘통과하기 위한 테스트’가 된다. 즉, AI는 자신이 방금 작성한 코드가 통과할 수 있는 테스트를 작성한다. 이것은 순환 논리다. 테스트는 코드의 정확성을 독립적으로 검증해야 하는데, AI가 코드와 테스트를 함께 작성하면 이 독립성이 무너진다.
더 근본적인 문제는, AI가 ‘무엇을 테스트해야 하는지’를 진정으로 이해하지 못한다는 점이다. 인간 개발자는 시스템의 불변 조건(invariant)이 무엇인지, 어떤 엣지 케이스가 위험한지, 어떤 실패 모드가 가능한지를 이해한다. 이 이해는 도메인 지식과 경험에서 나온다. AI는 학습 데이터에서 본 테스트 패턴을 재생산할 수는 있지만, 왜 그 테스트가 중요한지, 다른 무엇을 테스트해야 하는지는 알지 못한다.
한 댓글은 이를 정확히 포착했다. “AI의 코드가 마음에 안 들 때 수동으로 고치다 보면 ‘죄책감’이 들기도 한다. 하지만 중요한 건, 어떤 작업이 정말 수동 개입이 필요한지 판단하는 능력이다.” 여기서 “죄책감”은 흥미로운 심리적 현상이다. 우리는 AI에게 작업을 맡겼으니 AI가 완성해야 한다고 느낀다. 그러나 실제로는 개발자의 개입과 검증이 필수적이다.
atmoio의 경험에서 가장 아이러니한 부분은, 그가 “모든 코드를 리뷰했다”고 생각했는데도 슬롭이 축적되었다는 점이다. 이것은 리뷰의 한계를 보여준다. 개별 PR을 리뷰하는 것으로는 전체적인 구조적 일관성을 보장할 수 없다. 각 변경사항은 그 자체로는 합리적으로 보일 수 있지만, 누적된 변경사항들이 만들어내는 전체 패턴은 혼란스러울 수 있다.
이것은 소프트웨어 아키텍처의 본질적 어려움과 관련된다. 좋은 아키텍처는 명시적 제약뿐만 아니라 암묵적 원칙들로 이루어진다. 이 암묵적 원칙들은 문서화되지 않은 채 숙련된 개발자의 머릿속에 존재한다. “이 레이어는 저 레이어에 의존하지 않는다”, “이 추상화는 이런 식으로 확장된다”, “이 패턴은 이런 경우에 사용한다”. AI는 이런 암묵적 원칙을 이해하거나 존중하지 못한다.
따라서 AI 코딩에서 가장 위험한 것은 겉보기에 작동하는 코드다. 버그가 있다면 우리는 즉시 알아차리고 고칠 수 있다. 그러나 구조적으로 취약하지만 당장은 작동하는 코드는 훨씬 더 위험하다. 그것은 시간이 지나면서 유지보수 비용을 기하급수적으로 증가시키고, 결국 시스템 전체를 재작성해야 하는 상황으로 이어질 수 있다.
인간의 불가대체성: 사고의 도구로서의 코딩
Hacker News의 가장 통찰력 있는 댓글 중 하나는 이렇게 말했다. “나는 코드를 ‘사고의 도구’로 본다. 단순 구현만으로는 사고가 깊어지지 않는다. AI에게 구현을 맡기면, 결국 ‘눈 가린 사람끼리 길 찾기’가 된다. 직접 코드를 다루며 생각하는 과정이 필수적이다.”
이것은 AI 코딩 논의에서 종종 간과되는 핵심을 짚는다. 코딩은 단순히 생각을 코드로 번역하는 것이 아니다. 코딩 자체가 사고 과정의 일부다. 우리는 코드를 작성하면서 문제를 더 깊이 이해하게 되고, 더 나은 해결책을 발견하며, 숨겨진 복잡성을 드러낸다.
이것은 마치 글쓰기와 같다. 우리는 명확한 생각을 먼저 가지고 그것을 글로 옮기는 것이 아니다. 글을 쓰는 과정 자체가 생각을 명확하게 만든다. 같은 방식으로, 코드를 작성하는 과정은 우리의 이해를 심화시킨다. 함수를 어떻게 나눌지, 어떤 추상화를 만들지, 어떤 이름을 붙일지 고민하면서, 우리는 문제의 본질을 더 깊이 파악하게 된다.
AI에게 코딩을 맡기면 이 과정을 생략하게 된다. 우리는 빠르게 작동하는 코드를 얻지만, 그 과정에서 얻었어야 할 깊은 이해는 놓친다. 그 결과 atmoio가 발견한 것처럼, 우리는 자신의 코드베이스의 이방인이 된다. 코드는 우리가 쓴 것이 아니기에, 우리는 그것을 진정으로 이해하지 못한다.
이것은 특히 주니어 개발자에게 심각한 문제다. CS 교사의 우려는 정당하다. 학습 과정에서 겪는 어려움, 버그와 씨름하며 보내는 시간, 여러 접근법을 시도하고 실패하는 경험. 이 모든 것이 진정한 능력을 구축한다. AI가 이것을 대신해주면, 학생들은 표면적 지식만 얻고 깊은 이해는 놓친다.
한 댓글은 교육 방식의 변화를 제안했다. “코드를 ‘어떻게 짜는가’보다 ‘코드가 어떻게 작동하는가’를 가르치는 게 더 중요하다.” 이것은 일리 있다. 우리는 더 높은 추상화 수준에서 생각하는 법을 배워야 한다. 그러나 동시에, 낮은 수준의 구현을 직접 다뤄본 경험이 없으면 높은 수준의 추상화도 피상적이 된다.
atmoio의 결론 “나는 다시 손으로 코드를 쓰기로 했다. 놀랍게도 나는 더 빠르고, 정확하고, 창의적이다”는 이를 확인한다. 그는 모든 것을 고려했을 때 - 코드의 품질, 유지보수 가능성, 자신의 이해도 - 직접 코딩하는 것이 더 생산적이라는 것을 발견했다. 이것은 단순히 속도의 문제가 아니다. 그것은 통제, 이해, 그리고 궁극적으로는 품질의 문제다.
흥미롭게도, atmoio는 여전히 일부 작업(약 40%)에서는 LLM을 사용한다고 말한다. 이것은 균형 잡힌 접근법을 시사한다. AI를 완전히 배제하는 것도, 완전히 의존하는 것도 답이 아니다. 핵심은 어떤 작업에서 AI가 도움이 되고, 어떤 작업에서 인간의 직접적 개입이 필수적인지를 판단하는 것이다.
진짜 문제: 협업 패러다임의 부재
atmoio의 경험과 Hacker News 커뮤니티의 다양한 반응을 종합하면, 한 가지 패턴이 드러난다. AI 코딩에 성공한 사람들과 실패한 사람들의 차이는 도구의 차이가 아니라 접근 방식의 차이다.
실패한 경우의 전형적 패턴은 이렇다: 큰 작업을 AI에게 한 번에 맡긴다. 상세한 명세를 작성하고, AI가 구현을 완료하기를 기다린다. 결과물을 받아서 리뷰하고 머지한다. 이것을 반복한다. 그러다 몇 달 후 코드베이스 전체를 보고 충격을 받는다.
반면 성공한 경우의 패턴은 다르다: 작은 단위로 나눈다. AI와 지속적으로 대화한다. 설계를 함께 검토하고, 구현을 단계적으로 진행하며, 각 단계에서 방향을 조정한다. AI를 자율적 에이전트가 아니라 협업 파트너로 취급한다.
한 개발자의 말이 이를 잘 요약한다. “나는 AI를 ‘아이를 가르치듯’ 다룬다. 프롬프트를 문서화하고, 반복 실험하며, 피드백을 준다.” 또 다른 개발자는 “Claude가 질문하고, 리서치하고, 코드 리뷰까지 한다. 마치 유능한 주니어 개발자를 멘토링하는 느낌”이라고 말한다.
이 접근법들의 공통점은 무엇인가? AI를 블랙박스로 취급하지 않는다는 것이다. 그들은 AI와의 상호작용을 세심하게 설계하고, 프롬프트를 반복적으로 개선하며, 결과물을 주의 깊게 검증한다. 그들은 AI가 완벽하지 않다는 것을 알고, 그 한계를 보완하는 워크플로우를 구축한다.
그러나 이런 접근법은 엄청난 노력이 필요하다. 한 댓글이 지적했듯이, “AI 도구 숙련도를 객관적으로 평가할 방법이 필요하다.” 현재 AI 코딩은 마치 예술처럼 취급된다. 어떤 사람은 잘하고, 어떤 사람은 못하며, 그 차이를 명확히 설명하기 어렵다.
더 근본적인 문제는, 이런 수준의 AI 오케스트레이션이 모든 개발자에게 가능하거나 바람직한 것은 아니라는 점이다. atmoio는 아마도 이런 접근법을 시도했을 가능성이 높다. 하지만 그가 만들고자 하는 제품의 성격, 그가 가진 팀의 규모, 그가 감당할 수 있는 시간과 에너지를 고려할 때, 그에게 최적의 선택은 직접 코딩으로 돌아가는 것이었다.
이것은 중요한 시사점을 준다. AI 코딩의 “실패”는 절대적이지 않다. 그것은 맥락 의존적이다. 같은 도구와 접근법이 어떤 상황에서는 효과적이고 다른 상황에서는 비효과적일 수 있다. 우리에게 필요한 것은 어떤 상황에서 어떤 접근법이 적합한지 판단할 수 있는 프레임워크다.
현재 AI 코딩 도구들은 대부분 “더 빠른 코딩”을 약속한다. 그러나 atmoio의 경험이 보여주는 것은, 진짜 문제는 속도가 아니라는 것이다. 진짜 문제는 품질, 이해, 유지보수성, 그리고 장기적 지속가능성이다. 이런 관점에서 현재의 AI 코딩 도구들은 아직 갈 길이 멀다.
미래의 방향: 어떻게 나아갈 것인가
atmoio의 경험은 AI 코딩의 현주소를 보여주지만, 그것이 AI 코딩의 미래가 이렇게 될 것임을 의미하지는 않는다. 기술은 진화하고 있으며, 우리의 이해도 깊어지고 있다.
첫째, 도구 자체가 개선되고 있다. Claude Opus 4.5, GPT-o3 같은 최신 모델들은 이전 세대보다 훨씬 강력하다. 특히 “reasoning” 능력의 향상은 주목할 만하다. 이들은 단순히 다음 토큰을 예측하는 것을 넘어, 문제를 분해하고, 대안을 평가하며, 자신의 결정을 설명할 수 있다. 이것은 atmoio가 경험한 문제들을 완화할 수 있다.
둘째, 우리는 AI와 협업하는 더 나은 방법을 배우고 있다. 초기에는 모두가 AI를 마법의 지팡이처럼 취급했다. 하지만 이제 우리는 AI의 강점과 약점을 더 잘 이해한다. Claude Skills, Cursor의 Composer, GitHub Copilot Workspace 같은 도구들은 단순한 코드 생성을 넘어 구조화된 워크플로우를 제공하려 시도한다.
셋째, 새로운 개발 패러다임이 등장하고 있다. “agentic coding”은 단순한 vibecoding을 넘어선다. 그것은 AI 에이전트가 자율적으로 작동하되, 인간이 명확한 목표와 제약을 설정하고, 중간 결과를 검증하며, 필요할 때 개입하는 모델이다. 이것은 완전 자동화와 완전 수동 사이의 중간 지점이다.
그러나 이런 진보에도 불구하고, 근본적인 질문은 남는다. AI가 아무리 발전해도, 소프트웨어 개발이 가진 본질적 복잡성 - 발견의 과정, 암묵적 지식, 전체론적 이해의 필요성 - 은 사라지지 않는다. 따라서 미래의 AI 코딩 도구는 “인간을 대체”하는 것이 아니라 “인간의 능력을 증폭”하는 방향으로 진화해야 한다.
이것은 구체적으로 무엇을 의미하는가?
첫째, AI는 단순 작업과 반복 작업에 집중해야 한다. 보일러플레이트 코드 생성, 간단한 리팩터링, 테스트 작성, 문서화. 이런 작업들은 명확히 정의되어 있고, 창의성이 덜 필요하며, AI가 잘할 수 있다. 인간 개발자는 이런 작업에서 해방되어 더 높은 수준의 설계와 문제 해결에 집중할 수 있다.
둘째, AI는 피드백과 검증에 도움을 줄 수 있다. 코드 리뷰, 잠재적 버그 발견, 성능 문제 지적, 보안 취약점 분석. AI는 인간이 놓칠 수 있는 세부사항을 포착하고, 다양한 관점을 제공할 수 있다. 그러나 최종 판단은 여전히 인간이 해야 한다.
셋째, AI는 탐색과 학습을 도울 수 있다. 새로운 라이브러리를 배울 때, 낯선 코드베이스를 이해할 때, 다양한 설계 대안을 평가할 때. AI는 빠르게 정보를 제공하고, 예제를 생성하며, 옵션을 비교할 수 있다. 이것은 개발자의 학습 곡선을 가파르게 만든다.
그러나 모든 경우에, 인간 개발자는 운전석에 있어야 한다. AI는 부조종사, 네비게이터, 조언자가 될 수 있지만, 최종 책임은 인간이 진다. atmoio가 “나는 이 코드를 사용자에게 제공할 수 없다”고 말했을 때, 그는 이 책임을 받아들인 것이다.
한국 개발 환경에의 함의
atmoio의 경험과 글로벌 개발자 커뮤니티의 논의는 한국의 개발 환경에도 중요한 시사점을 준다.
첫째, AI 코딩 도구 도입에 있어 신중한 접근이 필요하다. 많은 한국 기업들이 “AI 전환”을 외치며 개발팀에 AI 도구를 도입하고 있다. 그러나 atmoio의 경험이 보여주듯, 도구의 도입만으로는 부족하다. 어떻게 사용할지, 어떤 작업에 적합한지, 어떻게 품질을 보장할지에 대한 명확한 가이드라인이 필요하다.
둘째, 교육과 훈련의 재설계가 필요하다. 한국의 코딩 교육은 전통적으로 문법과 알고리즘에 집중해왔다. 그러나 AI 시대에는 더 높은 수준의 능력 - 아키텍처 설계, 시스템 사고, 문제 정의 - 이 더욱 중요해진다. 동시에, CS 교사들이 우려하는 것처럼, 기초를 건너뛰면 안 된다. 균형을 찾는 것이 관건이다.
셋째, 주니어 개발자 육성 전략의 재고가 필요하다. 전통적으로 주니어 개발자는 간단한 작업부터 시작해서 점진적으로 복잡한 작업으로 나아간다. 그러나 AI가 간단한 작업을 잘 수행한다면, 주니어 개발자는 어떻게 성장할 것인가? 한국 기업들은 이 질문에 대한 답을 찾아야 한다.
넷째, 코드 리뷰와 품질 관리 프로세스의 강화가 필요하다. AI 생성 코드는 겉보기에는 좋아 보이지만 구조적 문제를 숨기고 있을 수 있다. 따라서 표면적 검토를 넘어 전체론적 코드 리뷰가 중요해진다. 이를 위해서는 시니어 개발자의 역할이 더욱 중요해진다.
다섯째, POSCO의 P-GPT 같은 기업 내부 AI 시스템을 구축할 때, 코딩 지원 기능의 한계를 인식해야 한다. 단순한 코드 생성을 넘어, 어떻게 개발자의 사고를 지원하고, 협업을 촉진하며, 지식을 공유할 것인지를 고민해야 한다.
여섯째, 외주 개발 산업에 특별한 주의가 필요하다. 실제로 일부 외주 회사에서 Claude Skills 같은 AI 도구를 도입하여 단기적 생산성 향상을 경험한 사례가 있지만, 외주 개발에서 AI 도구는 양날의 검이다. 단기적으로는 생산성을 높일 수 있지만, atmoio가 경험한 것처럼 품질 문제가 나중에 폭발할 수 있다. 외주 개발에서는 코드의 장기적 유지보수를 고려하지 않는 경우가 많은데, AI 코딩은 이 문제를 악화시킬 수 있다.
일곱째, 한국 개발자 커뮤니티의 담론 형성이 필요하다. 미국의 Hacker News처럼, 한국에도 AI 코딩의 실질적 경험과 한계를 솔직하게 논의하는 공간이 필요하다. 과장된 마케팅도, 무조건적 반대도 아닌, 균형 잡힌 논의가 중요하다.
결론: 균형의 기술
atmoio의 이야기는 실패의 이야기가 아니다. 그것은 발견의 이야기다. 2년간의 실험을 통해 그는 AI 코딩의 가능성과 한계를 모두 경험했다. 그리고 그는 자신에게 맞는 균형점을 찾았다. 그에게 그것은 주로 손으로 코드를 작성하되, 일부 작업에서는 AI를 활용하는 것이었다.
이것은 모든 개발자에게 적용되는 답은 아니다. 어떤 개발자는 더 많이 AI를 활용하고, 어떤 개발자는 더 적게 활용할 것이다. 프로젝트의 성격, 팀의 구성, 품질 요구사항, 시간 제약에 따라 최적의 균형점은 다를 것이다.
그러나 atmoio의 경험이 주는 가장 중요한 교훈은 이것이다: 맹목적으로 AI를 신뢰하지 말라. AI는 강력한 도구지만, 만능 해결책이 아니다. 그것의 한계를 이해하고, 그 한계를 보완하는 워크플로우를 구축하며, 무엇보다도 개발자로서의 책임을 포기하지 말라.
“나는 이 코드로 사용자에게 거짓말하지 않겠다”는 atmoio의 선언은 울림이 크다. AI 시대에도 변하지 않는 것은 개발자의 직업적 양심이다. 우리가 만드는 소프트웨어는 사람들의 삶에 영향을 미친다. 그것이 작동하는 것만으로는 충분하지 않다. 그것은 신뢰할 수 있어야 하고, 유지보수 가능해야 하며, 장기적으로 지속 가능해야 한다.
AI 코딩은 여전히 진화하고 있다. 앞으로 몇 년간 우리는 더 강력한 모델, 더 나은 도구, 더 효과적인 워크플로우를 보게 될 것이다. 그러나 근본적인 질문은 남는다: 우리는 AI와 어떤 관계를 맺을 것인가? AI를 우리의 대체재로 볼 것인가, 아니면 우리의 능력을 증폭시키는 도구로 볼 것인가?
atmoio의 답은 명확하다. 그는 AI를 도구로, 때로는 조력자로 보지만, 결코 대체재로 보지 않는다. 그는 코딩이 단순히 타이핑이 아니라 사고의 과정임을 이해한다. 그리고 그 사고의 과정은 외주화될 수 없다.
이것이 AI 코딩의 미래다. 완전 자동화의 유토피아도, AI 없는 과거로의 회귀도 아닌, 인간과 AI의 의미 있는 협업. 그 협업에서 AI는 속도와 규모를 제공하고, 인간은 판단과 책임을 제공한다. 그리고 그 둘의 조합이 어느 한쪽만으로는 불가능한 것을 가능하게 만든다.
atmoio는 2년의 여정 끝에 다시 손으로 코드를 쓰기 시작했다. 그러나 그는 AI를 완전히 버린 것이 아니다. 그는 AI와의 관계를 재정의했다. 그리고 그 과정에서, 그는 개발자로서 자신이 진정으로 가치 있게 여기는 것이 무엇인지 발견했다. 품질, 이해, 책임, 그리고 무엇보다도, 자신이 만드는 것에 대한 진정한 주인의식.
이것이 우리 모두가 AI 시대에 찾아야 할 답이다.
작성일: 2026-01-28