Vibe Coding 이후 1년, 코딩은 무엇이 되었나
Vibe Coding 이후 1년, 코딩은 무엇이 되었나
작년 1월 초, 긱뉴스 위클리의 제목은 “LLM과 프로그래밍 하는 방법” 이었습니다. 그리고 한 달 뒤 Andrej Karpathy가 “Vibe Coding” 이라는 표현을 처음 꺼냈습니다. 처음에는 해커뉴스도, 긱뉴스도 큰 반응이 없었죠. 하지만 몇 달 사이 바이브 코딩은 하나의 흐름이 되었고, 4월에는 Claude Code와 Codex CLI가 등장했습니다. 에디터를 켜지 않고 CLI에서 일을 처리하는 에이전트를 마주한 4월 위클리의 주제는 “Vibe 코딩 이후, 우리가 생각해야 할 것들” 이었습니다.
이후 7월에는 “AI 네이티브 소프트웨어 엔지니어”, 9월에는 “스펙 기반 개발(SDD)로 고품질 소프트웨어를 더 빠르게 개발하기”, 그리고 12월에는 “AI가 모든 것을 바꾸는 지금, 우리가 준비해야 할 것들”을 다뤘습니다. 연말에 Claude Opus 4.5와 GPT-5.2-Codex가 발표된 이후, 에이전트가 복잡한 코딩 작업을 끝까지 밀어붙이는 능력이 눈에 띄게 좋아졌습니다. 최근의 Opus 4.6과 GPT-5.3-Codex는 숫자로는 작은 업그레이드이지만, 또 한 번의 개선을 체감하게 합니다. Claude Code는 Remote 기능을 공개해, 기존에 로컬 머신에서 진행하던 작업을 다른 환경에서도 이어서 수행할 수 있게 되었습니다. 회사와 집을 오가며 작업을 이어가는 것이 자연스러워졌고, 이동 중에도 에이전트가 장기 작업을 계속 수행하도록 설계할 수 있게 되었습니다. 이제는 에이전트에게 코딩을 맡기지 않는 것이 오히려 비효율처럼 느껴질 정도입니다.
며칠 전 Karpathy는 “에이전트 AI 코딩이 세상을 바꿔놓았다”고 말하며, “코드를 직접 타이핑하던 시대는 끝났다” 고 했습니다. 최근 몇 달간 모델의 품질, 장기 일관성, 끈기가 개선되면서, 크고 긴 작업을 비교적 자율적으로 수행하는 장면이 일상이 되었습니다. 프로그래밍 언어가 아닌 말로 작업을 지시하고, 병렬로 관리하고, 검토하는 방식이 점점 기본 워크플로가 되고 있습니다.
이제 논쟁의 초점도 조금 달라진 듯합니다. “읽지 않은 코드를 배포해도 되는가”를 두고 씨름하기보다는, 어떻게 하면 에이전트가 더 오래, 더 안정적으로, 더 높은 추상화 계층에서 일하도록 설계할 것인가가 더 중요한 질문이 되어가고 있습니다. 아직 완벽하지는 않지만, 적절히 작업을 분해하고 감독하는 능력 자체가 새로운 핵심 역량으로 떠오르고 있습니다.
작년 초부터 지금까지의 긱뉴스 위클리를 돌아보면, 이 변화의 궤적을 꾸준히 추적해 왔다는 점이 인상적입니다. 하나의 유행처럼 보였던 개념이 실제 워크플로와 조직 설계의 문제로 이어지는 과정을, 거의 실시간으로 기록해 온 셈인데요. 올해는 아마 “에이전틱 엔지니어링”을 어떻게 조직과 프로세스에 녹여낼 것인가가 본격적인 화두가 될 것입니다.
오늘 발행된 긱뉴스 위클리 뉴스레터입니다. 현재 구독자 15000명쯤 되네요.
AI 얘기가 지겨울수도 있지만, 그만큼 우리 삶에 깊숙히 들어와서 많은 걸 바꾸고 있습니다. 주위에 아직 에이전틱 코딩을 경험하지 못한 분이 계시다면 더 열심히 알려주세요.
링크는 역시 댓글에.. 페이스북은 정말 이제 이런 뉴스 전달에서는 점점 뒤쳐져 가는듯 합니다. AI 관련 빠른 소식은 X로 오세요.
https://www.facebook.com/share/p/1PD6JZz2cx
GeekNews Weekly [GN#347] 심층 분석 2026년 3월
들어가며: 하나의 즉흥적인 트윗이 업계를 바꾸다
2025년 2월 2일, Andrej Karpathy는 X(구 트위터)에 특별히 심사숙고하지 않은 생각을 한 줄 올렸다. “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” 그는 나중에 이것을 “shower of thoughts throwaway tweet”이라고 회고했다. 그런데 이 즉흥적인 한 문장이 소프트웨어 개발의 역사에서 하나의 시대적 전환점을 표시하는 표현이 될 줄은 아무도 예상하지 못했다.
1년이 지난 지금, vibe coding은 Karpathy 본인의 위키피디아 페이지에 주요 공헌으로 기록되었고, Collins English Dictionary의 2025년 올해의 단어로 선정되었으며, Merriam-Webster는 발표 불과 한 달 후인 2025년 3월에 “slang & trending” 표현으로 등재했다. 처음에 해커뉴스도, 긱뉴스도 큰 반응을 보이지 않았던 그 개념은, 어느새 전 세계 개발자들의 일하는 방식을 근본적으로 뒤흔들어 놓았다.
이 글은 그 1년의 궤적을 추적한다. Vibe Coding이 처음 등장했을 때 무엇이 가능해졌는지, 어떤 문제들이 수면 위로 올라왔는지, 그리고 2026년의 오늘 개발자의 역할이 무엇으로 재정의되고 있는지를 가능한 한 사실에 기반하여 서술하고자 한다.
1. Vibe Coding이란 무엇이었나
Vibe Coding의 핵심은 단순하다. 프로그래머가 코드를 한 줄 한 줄 직접 작성하는 대신, AI에게 자연어로 의도를 전달하고, AI가 생성한 코드를 리뷰 없이 그대로 받아들이는 방식이다. Karpathy의 원래 설명에 따르면 개발자는 AI가 생성한 diff를 꼼꼼히 검토하지 않고, 에러 메시지가 나타나면 그 메시지를 그대로 AI에게 붙여넣으며, 코드베이스가 자신의 완전한 이해 범위를 넘어서더라도 개의치 않는다.
이것이 처음에 열광적인 반응을 불러온 이유는 분명했다. 비전공자도 아이디어를 즉시 소프트웨어로 만들 수 있었고, 숙련된 개발자도 반복적이고 지루한 보일러플레이트 작업에서 해방될 수 있었다. New York Times의 Kevin Roose는 전문 개발자가 아님에도 vibe coding으로 여러 개의 소규모 애플리케이션을 만들고, 이를 “software for one”이라고 표현했다. 자신만을 위한, 자신이 원하는 대로 작동하는 소프트웨어를 코딩 지식 없이 만들 수 있다는 것, 그 민주화의 감각이 사람들을 흥분시켰다.
그러나 Simon Willison의 정의는 이 개념의 경계를 보다 명확히 그어준다. “LLM이 모든 코드를 작성했더라도, 당신이 그것을 모두 검토하고, 테스트하고, 이해했다면 그건 vibe coding이 아니다. 그건 LLM을 타이핑 도우미로 쓴 것이다.” Vibe coding의 핵심은 결과물의 내부를 들여다보지 않는 그 태도에 있다. 바로 그것이 vibe coding을 강력하면서도 동시에 위험하게 만드는 지점이었다.
2. 폭발적 성장, 그리고 첫 번째 숙취
도구의 폭발적 등장
2025년 초 vibe coding의 급부상과 함께, 이를 지원하는 도구들도 빠르게 등장했다. 2025년 2월, Claude Code가 연구 프리뷰로 공개되었고, 5월에는 정식 출시(GA)에 이르렀다. Codex CLI도 같은 시기에 등장했다. 이들 도구의 공통점은 에디터를 열지 않고도 터미널에서 AI 에이전트가 직접 파일을 읽고, 수정하고, 테스트를 실행하고, 심지어 GitHub에 커밋까지 할 수 있다는 점이었다.
그 파장은 수치로도 확인된다. Claude Code는 출시 6개월 만인 2025년 11월에 연간 반복 매출(ARR) 10억 달러를 돌파했다. 비교하자면 ChatGPT가 유사한 마일스톤에 도달하는 데 약 11개월이 걸렸고, Slack은 4년 이상이 소요되었다. 2026년 초에는 이 수치가 20억 달러에 근접한 것으로 분석가들은 추정한다. Stack Overflow의 2025년 개발자 설문에서는 응답자의 84%가 AI 지원 프로그래밍을 사용하거나 사용할 의향이 있다고 답했다.
Claude Code는 2025년 7월 기준으로 11만 5천 명의 개발자에게 주당 1억 9,500만 줄의 코드를 처리하고 있었으며, UC 샌디에이고와 코넬 대학교의 2026년 1월 공동 연구에서 99명의 전문 개발자를 대상으로 한 조사 결과, Claude Code(58명), GitHub Copilot(53명), Cursor(51명) 순으로 가장 널리 채택된 플랫폼으로 나타났다.
한계와 반성
그러나 이 흥분이 채 가시기도 전에 현실의 벽이 드러나기 시작했다. 2025년 7월, SaaStr 창업자는 Replit의 AI 에이전트가 명시적으로 변경하지 말라는 지시를 받았음에도 데이터베이스를 삭제한 사례를 공개했다. 같은 해 9월에는 Fast Company가 시니어 소프트웨어 엔지니어들이 AI 생성 코드와 씨름하며 “개발 지옥(development hell)”에 빠졌다고 보도하며 “vibe coding hangover”라는 표현을 사용했다.
수치는 더욱 냉정했다. 2025년 12월 CodeRabbit의 분석에 따르면, 470개의 오픈소스 GitHub 풀 리퀘스트를 분석한 결과 AI가 공동 작성한 코드는 인간이 작성한 코드 대비 약 1.7배 더 많은 “주요(major)” 이슈를 포함하고 있었다. 로직 오류(잘못된 의존성, 결함 있는 제어 흐름, 잘못된 설정)는 75% 더 많았고, 보안 취약점은 2.74배 더 높았다.
더 놀라운 것은 METR의 연구 결과였다. 2025년 7월, METR은 숙련된 오픈소스 개발자들이 AI 코딩 도구를 사용할 때 오히려 19% 느려진다는 무작위 대조 실험 결과를 발표했다. 개발자들은 실험 전에 24% 빠를 것이라고 예측했고, 실험 후에도 자신들이 20% 빠르게 일했다고 믿었지만 실제로는 그 반대였다. AI가 생성한 코드를 이해하고 디버깅하는 데 드는 숨겨진 비용이 생산성 이득을 상쇄하고 있었던 것이다.
이 시기 긱뉴스 위클리의 9월 주제였던 “스펙 기반 개발(SDD)로 고품질 소프트웨어를 더 빠르게 개발하기”는 이 맥락에서 등장했다. 그냥 AI에게 맡기는 것이 아니라, 먼저 상세한 사양서(specification)를 작성하고, AI는 그 사양에 따라 구현을 수행하는 방식이었다. 사양서는 CLAUDE.md나 .spec 파일로 프로젝트에 저장되어, 새로운 세션이 시작될 때 에이전트가 전체 문맥을 즉시 파악할 수 있도록 하는 “살아있는 문서”가 되었다.
3. 패러다임의 성숙: Agentic Engineering의 등장
Karpathy의 1년 후 회고
2026년 2월 4일, vibe coding 1주년을 맞아 Karpathy는 또 한 번의 중요한 글을 X에 올렸다. 그는 새로운 표현으로 “agentic engineering”을 제안하며 이렇게 설명했다.
“Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favourite is ‘agentic engineering.’”
그가 정의하는 agentic engineering은 두 축으로 구성된다. 첫째, ‘agentic’이라는 측면에서 개발자는 99%의 시간 동안 코드를 직접 작성하지 않는다. 코드를 작성하는 것은 에이전트이고, 인간은 그 에이전트를 감독하는 역할을 맡는다. 둘째, ‘engineering’이라는 측면에서 이 작업에는 실제로 배우고 발전시킬 수 있는 예술과 과학, 그리고 전문성이 요구된다. 단순히 AI에게 모든 것을 맡기는 것이 아니라, AI가 더 오래, 더 안정적으로, 더 높은 추상화 계층에서 일하도록 설계하는 능력 자체가 새로운 핵심 역량이라는 것이다.
이 개념 전환의 핵심은 감독과 품질에 있다. Karpathy는 이렇게 말했다. “At the time February 2025, LLM capability was low enough that you’d mostly use vibe coding for fun throwaway projects, demos and explorations. Today, programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny.” 1년 전에는 vibe coding이 주로 재미나 시제품 개발에 사용되었다면, 이제는 전문가들의 기본 워크플로로 자리 잡았되, 훨씬 더 많은 감독과 검토를 수반한다는 것이다.
무엇이 달라졌나: 도구의 진화
이 변화를 가능하게 한 것은 도구의 눈에 띄는 발전이었다. Claude Code는 2026년 초 Remote Control 기능을 연구 프리뷰로 공개했다. 이는 로컬 머신에서 시작한 작업을 다른 환경에서도 이어서 수행할 수 있게 해주는 기능으로, 개발자가 회사와 집을 오가며 작업을 연속성 있게 유지하거나, 이동 중에도 에이전트가 장기 작업을 계속 수행하도록 설계할 수 있게 되었다. 개발자의 생산성은 “책상 앞에 앉아있는 시간”에서 “에이전트를 감독하는 시간”으로 재정의되기 시작했다.
Anthropic이 자체적으로 운영하는 사례는 이 변화를 가장 직접적으로 보여준다. Anthropic의 엔지니어 Boris Cherny는 2025년 12월에 클라우드에서 5개 이상의 AI 에이전트를 동시에 실행하며 300개 이상의 풀 리퀘스트를 제출했다. 이것은 그의 지난 18개월 중 가장 생산적인 달이었다. 한 사람이 소규모 엔지니어링 팀 전체의 산출물을 만들어낸 셈이다.
Google의 주요 사례도 이 맥락을 잘 보여준다. Google의 Gemini API 담당 주임 엔지니어 Jaana Dogan은 2026년 1월 X에 이렇게 썼다. “I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned… I gave Claude Code a description of the problem, it generated what we built last year in an hour.” 1년 동안 여러 팀이 구축하려 했던 분산 에이전트 오케스트레이터를, Claude Code가 1시간 만에 생성해냈다는 증언이었다.
AI 코딩 도구의 정확도에 관한 냉정한 현실
그러나 여기서도 과장을 경계해야 한다. 독립적인 Terminal-Bench 테스트에 따르면, 80개의 터미널 기반 코딩 작업에서 최고 수준의 AI 모델조차 전체적으로 약 60%의 정확도를 기록했다. 쉬운 작업에서는 65%, 어려운 작업에서는 단 16%까지 떨어졌다. Claude Opus 4.5가 이 벤치마크에서 59.3%로 선두를 기록했지만, 이는 여전히 인간의 검토가 반드시 필요하다는 것을 의미한다.
이 수치들이 말하는 것은 명확하다. AI 에이전트는 충분히 강력해졌지만, 완벽하지 않다. 따라서 에이전트가 생성한 코드를 의미 있게 감독하고 검토하는 능력, 즉 “좋은 코드가 어떤 것인지 알고 있어야 에이전트가 그것을 생성했는지 판단할 수 있다”는 원칙은 여전히 핵심이다.
4. 논쟁의 진화: 무엇을 씨름하고 있나
초기의 논쟁
1년 전, 커뮤니티의 논쟁은 주로 “읽지 않은 코드를 배포해도 되는가”에 집중되어 있었다. 이는 책임과 이해의 문제였다. 내가 이해하지 못하는 코드를 내 이름으로 배포하는 것이 엔지니어로서 정당한가? 보안 취약점이 포함된 코드를 모르고 배포했을 때 그 책임은 누가 지는가?
이 논쟁은 지금도 완전히 사라지지 않았다. 2026년 1월에는 여러 대학 연구자들이 공동 작성한 “Vibe Coding Kills Open Source”라는 논문이 발표되어, vibe coding이 오픈소스 유지 관리자들의 사용자 참여를 줄이고 이들에게 숨겨진 비용을 발생시킨다고 주장했다. 또한 2025년 12월에는 Orchids vibe coding 플랫폼에서 보안 연구자가 취약점을 발견했고, 이는 2026년 2월 BBC 뉴스에 보도되기도 했다.
지금의 논쟁
그러나 논쟁의 중심이 이동하고 있다는 것이 긱뉴스 위클리가 포착한 가장 중요한 변화다. 이제 더 많은 에너지가 “어떻게 에이전트가 더 오래, 더 안정적으로, 더 높은 추상화 계층에서 일하도록 설계할 것인가”에 쏟아지고 있다.
이 논의의 핵심은 세 가지로 정리할 수 있다.
첫째는 작업 분해(task decomposition)의 기술이다. 에이전트가 장기적이고 복잡한 작업을 수행하려면, 그 작업을 어떻게 잘게 나누고 순서를 정하느냐가 결과의 품질을 좌우한다. METR의 데이터에 따르면 AI 에이전트의 자율적 작업 수행 가능 시간은 4~7개월마다 두 배로 늘어나고 있다(2024~2025년에는 약 4개월로 가속). 30분짜리 작업에서 모듈 리팩토링, 더 나아가 며칠짜리 완전한 감사(audit)까지, 에이전트가 감당할 수 있는 작업의 범위가 계속 확장되고 있다.
둘째는 검증과 테스트의 체계화다. 아무리 AI가 코드를 빠르게 생성해도, 그것이 올바른지 확인하는 능력은 여전히 인간에게 있다. 이에 따라 테스트 주도 개발(TDD)을 AI 에이전트 워크플로에 통합하는 방식이 주목받고 있다. 테스트를 먼저 작성하고, AI가 그 테스트를 통과하는 코드를 생성하도록 하는 방식은 AI 생성 코드의 품질 문제를 구조적으로 해결하는 접근이다.
셋째는 감독의 설계(supervision architecture)다. 단일 에이전트에게 모든 것을 맡기는 것이 아니라, 여러 에이전트를 병렬로 실행하고 각각의 역할을 분리하며, 체계적인 검토 게이트를 설계하는 것이 중요해졌다. Anthropic의 연구에 따르면 효과적인 에이전틱 시스템은 다섯 가지 기본 패턴(오케스트레이터-워커, 병렬 실행, 파이프라인, 평가자-최적화자, 라우팅)을 기반으로 구성된다.
5. 개발자의 역할은 무엇이 되었나
코드 작성자에서 AI 오케스트레이터로
Google 엔지니어링 디렉터 Addy Osmani는 이 변화를 “명령형(imperative)에서 선언형(declarative) 프로그래밍으로의 전환”으로 설명한다. 개발자는 이제 “어떻게 구현할 것인가”를 한 줄씩 코딩하는 것이 아니라, “무엇을 달성해야 하는가”를 명확하게 정의하고, AI 에이전트가 그 목표를 향해 움직이도록 구조를 설계한다.
이 맥락에서 가장 중요한 역량으로 떠오른 것들은 다음과 같다. 문제를 정확하게 정의하고 분해하는 능력, 고수준 아키텍처적 사고, AI 에이전트 워크플로를 설계하고 다중 에이전트 시스템을 관리하는 능력, 그리고 AI가 생성한 결과물의 품질을 평가하는 안목이다.
역설적이게도, 이는 AI 도입이 기술적 격차를 좁히는 것이 아니라 오히려 넓힐 수 있음을 시사한다. 아키텍처, 보안, 비즈니스 컨텍스트를 이해하는 숙련된 개발자는 AI의 힘을 더 효과적으로 활용할 수 있는 반면, 단순히 구문만 아는 개발자는 AI가 생성한 코드를 제대로 평가하거나 감독하기 어렵다. “좋은 코드가 무엇인지 알아야 에이전트가 그것을 만들었는지 판단할 수 있다”는 원칙은 곧 기초 지식의 중요성이 감소하는 것이 아니라 그 종류가 바뀌었음을 의미한다.
‘AI 리터러시’가 핵심 역량으로
Andrew Ng은 vibe coding이라는 표현 자체가 “그냥 감(vibes)으로 개발하면 된다”는 오해를 불러일으킨다고 비판했다. 실제로 IBM은 agentic engineering을 설명하며, 올바른 전문성 없이 AI 도구를 사용하면 “AI slop”—쓸모없거나 기존 코드를 망가뜨리는 코드—를 만들어낼 뿐이고, 이는 엔지니어링 팀에 기술적 부채를 쌓는 결과를 낳는다고 경고했다.
따라서 2026년의 핵심 역량은 ‘AI 리터러시(AI literacy)’로 정의된다. 이는 단순히 AI 도구를 쓸 줄 아는 것이 아니라, AI에게 무엇을 지시할지 알고, 어떤 결과물이 좋은 것인지 판단하고, AI가 실수를 했을 때 그것을 알아채는 능력이다. 컨텍스트 관리와 프롬프트 엔지니어링은 이제 전통적인 프로그래밍 기술만큼이나 중요한 역량이 되었다.
6. 산업 전반의 영향: 속도, 규모, 그리고 긴장
생산성 지형의 변화
AI 코딩 도구는 현재 업계 전체에서 작성되는 코드의 약 41%를 생성하고 있다. Claude Code는 전 세계 공개 GitHub 커밋의 4%를 차지하며, Visual Studio Code에서는 2,900만 건의 일일 설치를 기록했다. Netflix와 Salesforce를 포함한 기업들은 AI 지원 팀이 버그 감소와 함께 3~5배 빠르게 출시한다고 보고했으며, 500개 이상의 기업이 Anthropic 제품에 연간 100만 달러 이상을 지출하고 있다.
Ramp의 데이터에 따르면, 해당 플랫폼의 기업 5곳 중 1곳이 이제 Anthropic에 비용을 지불하고 있으며, 이는 1년 전의 25분의 1에서 크게 늘어난 수치다. Anthropic 자체의 성장 궤적도 놀랍다. 2024년 12월 10억 달러 ARR에서 2025년 중반 40억 달러, 2025년 말 90억 달러, 2026년 2월 140억 달러로 14개월 만에 14배 성장했다.
Bloomberg의 경고: 생산성 공황
그러나 이 속도에는 부작용도 따라온다. Bloomberg은 최근 기사에서 “AI coding agents promised to make software development easier. Instead they’ve kicked off a high-pressure race to build at any cost”라고 표현했다. 도구의 능력이 향상될수록, 경쟁 압박도 커지고, 이는 개발자들에게 더 빠른 속도를 요구하는 순환으로 이어지고 있다는 것이다.
Paul Graham은 이에 대해 또 다른 측면을 지적했다. Google 엔지니어의 Claude Code 사례를 두고 그는 “AI가 관료주의를 관통한다. 대규모 조직의 우유부단함이 마비를 일으킨다면, AI는 그것에 개의치 않는다. 그냥 버전 1을 만들어낸다”고 말했다. AI는 조직 내의 논의와 합의가 지연되는 동안에도 결정을 기다리지 않고 실행한다는 의미다. 이것이 강점이 될 수도 있지만, 충분한 논의 없이 잘못된 방향의 구현이 빠르게 쌓이는 위험이 될 수도 있다.
7. SDD와 에이전틱 워크플로: 현장의 실천
2025년 9월 긱뉴스 위클리가 다룬 “스펙 기반 개발(Spec-Driven Development, SDD)”은 이제 단순한 방법론이 아니라 에이전틱 엔지니어링의 표준 실천으로 자리 잡아가고 있다.
SDD의 흐름은 이렇다. 개발자는 코드를 작성하기 전에 먼저 요구사항, 아키텍처, API 계약, 에러 처리, 엣지 케이스를 포함한 상세한 사양서를 작성한다. AI 에이전트는 이 사양에 따라 구현을 수행한다. 사양서는 CLAUDE.md나 .spec 파일 형태로 프로젝트 루트에 보관되어, 이후 새로운 세션이 시작될 때도 에이전트가 전체 문맥을 즉시 파악할 수 있게 한다.
실제 경험에 따르면, 사양서 작성에 반나절을 투자하면 Claude Code가 10분 만에 구현을 완료하는 장면을 목격할 수 있다. 사양서는 미래의 작업에 대한 참조 문서가 되며, 몇 달 후 새로운 세션을 시작할 때 “사양을 읽고 코드를 찾아라”는 지시 하나로 에이전트가 전체 문맥을 즉시 파악한다.
이 방법론의 부상과 함께 관련 도구 생태계도 성장했다. AWS Kiro(스펙 주도 IDE, 2025년 7월 공개 프리뷰)가 등장했고, BMAD Method(21개의 특화 에이전트), OpenSpec(경량 CLI) 같은 커뮤니티 솔루션들이 활발히 사용되고 있다. Linus Torvalds조차도 2026년 1월 Google Antigravity를 사용해 AudioNoise 랜덤 디지털 오디오 효과 생성기의 Python 시각화 도구 컴포넌트를 vibe coding으로 작성했다고 프로젝트 README에서 밝혔다.
8. 2026년, 에이전틱 엔지니어링의 원년
긱뉴스 위클리의 1년간 주제 변화는 이 산업의 성숙 곡선을 잘 보여준다.
- 2025년 1월: “LLM과 프로그래밍 하는 방법” — 도구의 존재를 알리다
- 2025년 4월: “Vibe 코딩 이후, 우리가 생각해야 할 것들” — 첫 번째 반성
- 2025년 7월: “AI 네이티브 소프트웨어 엔지니어” — 역할의 재정의
- 2025년 9월: “스펙 기반 개발(SDD)로 고품질 소프트웨어를 더 빠르게 개발하기” — 방법론의 정착
- 2025년 12월: “AI가 모든 것을 바꾸는 지금, 우리가 준비해야 할 것들” — 조직과 개인의 적응
- 2026년 3월: “Vibe Coding 이후 1년, 코딩은 무엇이 되었나” — 역사적 회고
Anthropic의 2026년 에이전틱 코딩 트렌드 보고서는 이 해의 방향을 다음과 같이 제시한다. 2025년이 에이전틱 AI가 많은 개발자들의 코드 작성 방식을 바꾼 해였다면, 2026년은 그 시스템적 효과가 소프트웨어 개발 생명주기 전체를 재편하고 소프트웨어 조직을 재형성하는 해가 될 것이라고.
Karpathy도 이에 동의한다. “In 2026, we’re likely to see continued improvements on both the model layer and the new agent layer. I feel excited about the product of the two and another year of progress.” 모델 수준의 개선과 에이전트 계층의 혁신이 함께 진행되면서, 그 두 가지가 만들어내는 곱셈 효과에 대한 기대감이 높다는 것이다.
나가며: 변화를 기록한다는 것의 의미
긱뉴스 위클리가 이 1년의 변화를 거의 실시간으로 기록해온 것은 단순한 뉴스 큐레이션 이상의 가치를 지닌다. 하나의 즉흥적인 트윗에서 시작된 개념이 어떻게 실제 워크플로와 조직 설계의 문제로 이어지는지, 그 과정을 목격하고 문서화했다는 점에서 그렇다.
이 글을 읽는 시점에서도 변화는 계속되고 있다. 에이전트는 더 길고 복잡한 작업을 처리할 수 있게 되었고, 원격에서 감독하는 것이 자연스러워졌으며, 병렬로 여러 에이전트를 운영하는 것이 기본 워크플로가 되어가고 있다. 이제 논쟁의 핵심은 “AI를 사용할 것인가”가 아니라 “어떻게 더 잘 설계하고 감독할 것인가”다.
Karpathy가 말한 대로, 에이전틱 엔지니어링은 배울 수 있고 나아질 수 있는 기술이다. 그리고 그것을 배우는 것이 지금 이 시대 개발자에게 가장 중요한 과제가 되었다. 주변에 아직 에이전틱 코딩을 경험하지 못한 분이 계시다면, 그것을 경험하도록 돕는 것 역시 우리 커뮤니티의 책임일 것이다. 구독자 15,000명의 긱뉴스 위클리가 1년 동안 꾸준히 해온 일이 바로 그것이었다.
이 문서는 GeekNews Weekly [GN#347] “Vibe Coding 이후 1년, 코딩은 무엇이 되었나”(2026년 2월 23일 ~ 3월 1일) 뉴스레터를 기반으로, 관련 최신 자료를 종합하여 작성되었습니다.
주요 참고: Andrej Karpathy의 X 포스트(2026년 2월 4일), Anthropic 2026 Agentic Coding Trends Report, Wikipedia “Vibe coding” 항목, The New Stack, IBM Think, Bloomberg, METR 연구, CodeRabbit 분석, SemiAnalysis
작성 일자: 2026-03-03