Part 1: 여섯 개의 AI 코딩 물결
- Vibe 코딩은 LLM에게 코드를 작성하도록 요청하고 결과를 피드백하면서 반복하는, 대화 기반 코딩 방식에 붙여진 유쾌한 별칭임
- 기존 코딩이나 자동완성 중심 코딩과는 매우 다른 개념으로, 처음에는 명확한 정의 없이 사용되었으나 Andrej Karpathy가 이를 "vibe coding"이라 명명하면서 급속히 퍼짐
- 현재 vibe 코딩은 다음과 같은 세 가지 상태를 동시에 가짐:
- 업계 80%는 Vibe 코딩의 존재조차 모름, "코딩 에이전트"라는 말조차 처음 듣는 이들도 많음
- 미디어와 SNS를 중심으로 폭발적인 확산 중, 논쟁과 찬반 의견 속에서도 많은 개발자들이 미래 기술로 인식 중
- 기존 Chat 기반 코딩은 이미 구시대 기술로 취급, 더 빠른 속도의 새로운 방식에 열광하는 일부 개발자들은 chat에 더 이상 관심 없음
- 이 글에서는 AI 기반 코딩의 발전 단계를 총 여섯 개의 물결로 설명함:
- 전통적인 코딩 (2022)
- 자동완성 기반 코딩 (2023)
- 대화형 코딩 (2024)
- 코딩 에이전트 (2025 상반기)
- 에이전트 클러스터 (2025 하반기)
- 에이전트 플릿 (2026)
- 이 중 전통적 코딩과 자동완성 기반 코딩은 점차 쇠퇴하고 있으며, 이후 등장하는 방식은 각기 더 빠른 속도로 확산됨
- vibe coding은 이 물결들과 별도로 점선 형태로 나타남
- vibe coding은 위의 모든 방식 위에서 공존하며 특정 방식이 아닌, AI가 대부분 코드를 작성하는 상황 전체를 포괄하는 개념임
- 곧 등장할 "에이전트 클러스터"는 여러 에이전트를 병렬로 관리하는 개념이며, "에이전트 플릿"은 AI 매니저가 하위 에이전트를 감독하는 구조로 확장됨
- FY26 조직도는 이를 묘사한 것으로, 한 명의 개발자가 여러 개의 에이전트 그룹을 운영하며, 각각의 그룹은 버그 수정, 신규 기능 개발, 아키텍처 리팩터링 등 다양한 역할을 수행함
- 현재는 에이전트가 멈추거나 잘못된 방향으로 갈 때 인간이 직접 개입해야 하지만, 곧 슈퍼바이저 에이전트가 그 역할을 대신하게 됨
- 최종적으로는 수십 개 이상의 에이전트를 동시에 다룰 수 있게 되며, 방대한 레거시 코드를 처리하는 자동화 시스템이 될 것임
- 이러한 에이전트 플릿은 2026년 초까지는 확실히 등장할 전망이며, 병렬 작업을 효율적으로 구성하는 기술은 이미 준비되어 있음
Part 2: 당신은 지금 어디에 있나요?
- 여전히 AI를 코드 자동완성 도구로만 사용하거나 Completion Acceptance Rate(CAR)을 중시하고 있다면, Figure 1에서의 전통적 프로그래밍 곡선에 해당됨
- 이 곡선은 2027년 즈음이면 완전히 사라질 것으로 예상됨
- 자동완성은 1년 전만 해도 인기 있었지만 지금은 더 이상 핵심 기술이 아님
- 보다 진보적인 입장이라면 Copilot, Cursor, Sourcegraph, Windsurf 등의 IDE 내 채팅 기반 코딩 도구를 활용 중일 수 있음
- 이 경우는 괜찮은 위치이며, 코드 자동완성보다는 훨씬 생산적인 방법을 도입한 상태임
- 채팅 기반 코딩은 여전히 사용자는 많지만, 최신 기술의 기준은 아님
- 최근 등장한 코딩 에이전트(Aider.chat, Claude Code 등) 는 이 모든 방식을 압도할 가능성을 보이고 있음
- IDE에 자연스럽게 통합될 것이며, 기존의 대화 기반 방식보다 훨씬 빠르고 효율적임
- 에이전트를 한 번 사용해보면 다시는 이전 방식으로 돌아가기 어려움
- 에이전트 기반 코딩 역시 vibe coding의 일종임
- vibe coding은 "AI가 코드를 쓰는 모든 방식"을 의미하며, 특정 기술 방식(modality)은 아님
- 차이점은 에이전트는 대화를 자주 하지 않아도 혼자 작업을 진행함
- 각 코딩 방식의 변화는 다음과 같은 생산성 배수 패턴을 보임:
- Chat 기반 코딩은 수작업보다 약 5배 생산적임
- 에이전트 기반은 chat보다 다시 5배 생산적일 수 있음
- 각 물결은 시간이 지나면 10배 생산성도 가능하지만, 새로운 기술이 더 빨리 등장하면서 곡선이 평탄화됨
- 현재 우리는 거대한 AI 바다의 한가운데에 있으며, 점점 강력해지는 파도(새로운 기술)를 타고 나아가야 하는 상황임
- 모든 회사는 Figure 1에 있는 도입 곡선 중 하나 이상에 위치해 있음
- 스스로가 어느 곡선에 있는지 자문해보는 것이 필요함
- vibe coding은 특정 기술 방식이 아니라 새로운 개발의 철학이자 현실임
- 더 이상 직접 코드를 쓰지 않는다는 것이 핵심
- 코드 작성은 AI에게 맡기고, 인간은 결과 검토 및 조율만 하는 구조로 이동 중임
- 다음 파트에서는 이 기술 변화가 재무적으로 어떤 영향을 주는지 살펴봄
- 코딩 에이전트는 마법이 아니라 비용을 태우면 똑똑해지는 구조임
- 아직 시도해보지 않았다면, 지금 바로 사용해보거나 사용하는 사람을 관찰하는 것이 중요함
Part 3: 새로운 낙타 사용 설명서
- 최신 코딩 에이전트는 불과 몇 주 전에 등장한 매우 새로운 기술이며, 대부분 터미널 기반에서 작동함
- 비유하자면 평생 걸어 다니다가 낙타를 받은 느낌이며, 편리하지만 다루기 어렵고 돈을 많이 먹음
- "하나"만 있어도 걸을 때보다 훨씬 빠르지만, 침 뱉고 물고 도망가기도 함
- 많은 개발자들은 아직도 AI 코딩에 회의적이며, 여전히 직접 코드를 쓰고 싶어함
- 일부는 "나는 코드를 쓰는 사람이야!"라고 명확히 주장하기도 함
- 하지만 이런 생각은 이제 현실에 뒤처짐
- 회의적인 사람일수록 당장 최신 코딩 에이전트(3월 1일 이후 출시된) 를 다운받아 써보는 것을 권장함
- 몇 주 전 필자도 놀랄 정도로 발전한 모습을 직접 확인함
- 에이전트는 vibe coding과 원리는 같지만 사람이 직접 프롬프트를 주고받을 필요 없음
- 복잡한 작업을 스스로 수행하고, 완료되거나 문제가 생기면 다시 사용자에게 연락함
- 전체 작업의 90~99%를 자동으로 수행하므로, 사람은 병목에서 벗어남
- chat 기반 방식과 다른 점:
- 에이전트는 더 큰 작업 단위를 한 번에 처리할 수 있음
- 그동안 개발자는 자유롭게 다른 작업을 할 수 있음 (예: 간식 먹기, Hacker News 보기)
- 예시: "이 JIRA 티켓 해결해줘"라고만 하면,
- JIRA CLI를 찾아보고, 필요하면 설치 요청
- 티켓 필드를 읽기 위한 임시 프로그램 작성
- 코드 분석 → 버그 발견 → 수정 제안 → 테스트 작성 및 실행 → 루프 반복
- 결과적으로 에이전트는 눈부신 속도로 일하는 인간 개발자 같은 존재이나, 방향 감각이 약간 부족함
- 단점:
- 아직은 작은 단위의 작업만 안정적으로 처리 가능
- 과도한 기대는 실패를 부르고, 작업 분해(task decomposition) 능력이 필수임
- 너무 큰 작업은 제대로 수행하지 못하고 길을 잃게 됨
- 따라서 현재는 섬세한 문제 선택과 감독이 필요하며, 에이전트는 고집 센 동물처럼 다뤄야 함
- 하지만 이 상황도 곧 변할 예정:
- 에이전트는 곧 IDE에 자연스럽게 통합될 예정이며, 보다 다루기 쉽고 친숙한 툴로 발전함
- 낙타에서 안장 달린 말, 그리고 머지않아 전차(chariot) 로 진화할 예정
- 결론: 지금은 에이전트와 함께 일하는 방법을 배우기에 최적의 타이밍이며,
- 곧 더 많은 기능, 더 나은 인터페이스, 더 큰 생산성 향상이 따라올 것임
Part 4: 수학은 없다더니
- 이 섹션은 CIO 및 재무 담당자를 위한 내용임
- FY26 예산을 막 마무리한 지금, 개발자당 LLM 사용 비용을 얼마나 책정했는가?
- 하루 $25는 꽤 대담해 보이지만, 사실 적절한 수준에 가까움
- 현실은 더 심각함:
- 코딩 에이전트는 매우 비쌈 — 시간당 $10~12 수준으로 토큰을 소모함
- 기존 코딩 어시스턴트 라이선스가 월 $30 정도라면, 이는 수십 배 이상의 비용 차이를 의미함
- 하지만 계산상, 코딩 에이전트는 하루 8~10시간 사용 시 주니어 개발자 1명을 고용한 것과 비슷한 생산성을 가짐
- 시간당 $10이면 굉장히 저렴한 셈이며, 개발자는 두 명의 에이전트를 동시에 돌릴 수 있음
- 하루 $100 정도를 LLM에 지출하면 개발자 생산성이 2배 이상 증가 가능
- 그러나 진짜 변화는 곧 등장할 에이전트 클러스터(2025년 Q3 예정) 임
- 한 명의 개발자가 여러 개의 에이전트를 병렬로 운영 가능
- 각 에이전트는 버그 수정, 신규 기능 개발, 문서 작성 등 다양한 작업을 독립적으로 수행
- 그 결과, 한 명의 개발자가 마치 다수의 개발자 역할을 수행하게 됨
- 물론 능숙한 사람일수록 그 효과는 더 큼
- 에이전트 클러스터의 등장은 소프트웨어 개발 환경을 클라우드로 전환시키는 계기가 될 것임
- 수십~수백 개의 에이전트를 로컬 데스크탑으로는 처리 불가
- 클라우드 기반 개발 환경이 사실상 표준이 됨
- 따라서, 클라우드 예산도 추가 확보해야 함
- 예를 들어, 개발자 한 명이 5개의 에이전트를 돌리면:
- 시간당 $50 → 연간 약 $100,000 수준의 비용 발생 (클라우드 비용 제외)
- 이는 더 이상 ‘저렴한 투자’가 아닌, 상당한 지출이 됨
- 그러나 생산성은 5배 이상 증가 가능하므로, 장기적으로는 높은 ROI를 기대할 수 있음
- 문제는 대부분의 기업이 2026년 운영 예산에 이러한 LLM 비용을 포함하지 않았을 것이라는 점
- 이로 인해 기업 간 격차가 벌어짐: 예산 있는 기업은 기술 우위를 확보하고, 없는 기업은 도태될 위험 존재
- 결론:
- 소프트웨어 개발은 이제 pay-to-play 초고속 열차
- 티켓(예산)이 없으면, 무리에서 이탈하게 될 위험이 큼
Part 5: 에이전트 플릿이 온다
- 여기서부터는 조금 불편한 진실을 다룸
- 마음의 준비가 안 됐다면 잠시 휴식하고 다시 읽을 것을 권장함
- 에이전트 클러스터의 다음 단계는 “에이전트 플릿(fleet)”이며, 이는 개발자가 100개 이상의 에이전트를 동시에 운용하는 환경을 의미함
- 이때 상위에서 제어하는 슈퍼바이저 에이전트가 등장하여 하위 에이전트 그룹을 관리하고, 문제가 생길 때만 인간이 개입함
- 미래의 개발자 역할은 더 이상 코드 작성자가 아닌,
- 에이전트와 AI 관리자들이 표시된 대시보드를 운영하고 감독하는 역할로 변화함
- 일부는 이를 비꼬아 "AI 아기 돌보기"라고 표현할 수 있지만, 이게 곧 새로운 소프트웨어 개발의 모습임
- CIO 입장에서, 에이전트 플릿 시대에는 개발자 1인당 하루 수천 달러의 LLM 비용이 들 수 있음
- 추론 비용이 감소하더라도, 제번스 역설에 따라 사용량 증가가 비용 절감을 상쇄함
- 예: 당신의 버그 백로그가 끝이 없다는 점을 떠올려 보라
- 하지만 이는 낭비가 아닌 엄청난 가치의 투자임
- 드디어 엔지니어링 조직이 경영진이 원하는 속도로 움직일 수 있게 됨
- 마치 스타트업처럼 민첩하게 고객을 놀라게 하고 기쁘게 만들 수 있는 시대로 진입함
- 단점은 예산이 매우 많이 필요하다는 것
- 일부 대기업은 이미 LLM 실험 예산을 슬러시 펀드 형태로 확보했지만,
- 많은 기업은 이번 예산 편성에서 이를 전혀 고려하지 않았을 가능성이 큼
- 일부 대기업은 이미 LLM 실험 예산을 슬러시 펀드 형태로 확보했지만,
- 연말까지 개발자당 $50,000의 추가 예산을 확보하지 못한다면, 구조 조정 외의 선택지가 없을 수 있음
- 이 변화는 오히려 민첩한 스타트업에 유리하게 작용할 수 있음
- 기술 격차보다는 예산 유무가 기업 경쟁력을 결정하는 시대가 도래함
- 그리고 만약 예산을 마련할 수 없다면, 감축 가능한 유일한 부서는 어디인지 자명함
- 그에 대한 답은 독자의 판단에 맡김
- 다행히, 이 예측이 약간 과장됐을 수도 있음
- Claude(LLM)와 논의해본 결과, 약 6개월 정도 예측을 늦추면 보다 현실적일 수 있음
- 좋은 소식은 지금부터 시작임
- 나쁜 소식은 끝났고, 이제 남은 것은 단 하나: 달콤한 복수
Part 6: 주니어 개발자의 복수
- 미래는 암울하지 않음. 오히려 소프트웨어 업계에는 여전히 많은 일자리가 있음
- 단, 수작업으로 코드를 작성하는 전통적 개발자 역할은 사라질 것
- 지난 1년간 관찰한 패턴 중 하나는, 주니어 개발자가 시니어보다 AI 도입에 훨씬 적극적이라는 점임
- 일부는 AI가 자신의 일자리를 빼앗을까 걱정하지만, 대부분은 변화에 빠르게 적응 중
- O’Reilly의 AI Engineering 책을 학습하고, chat coding과 코딩 에이전트를 능숙하게 사용하고 있음
- 반면, 시니어 개발자들은 거의 LLM을 다뤄본 적도 없거나, 간접적으로만 경험한 경우가 많음
- AI 기술에 대한 노골적인 거부감을 드러내는 사례도 존재
- 예: 한 유명 기업 개발자가 “AI를 포기하고 전통적인 코딩으로 돌아가자”는 슬라이드 PDF를 제출
- 이러한 반응은 새로운 기술에 대한 불안과 기존 지식에 대한 투자 손실에서 기인함
- 새로운 언어나 툴을 익히는 것은 본질적으로 '다시 처음부터 시작해야 한다'는 공포를 동반함
- 그러나 현실은 명확함:
- AI를 외면한 사람들은 이미 게임에서 밀려났음
- 주니어 개발자들은 더 저렴하고, 더 적응력이 뛰어나며, 더 빠르게 학습함
- 기업들이 개발자 인력을 조정해야 할 때, 어떤 개발자를 선택할지는 자명함
"AI가 당신보다 나은 것을 증명할 필요는 없음. 당신이 AI를 더 잘 다룰 줄 알아야 함."
- 즉, 주니어 개발자는 이제 언덕 위에서 빛의 검을 들고 있는 입장이며,
- 시니어 개발자들에게 변화에 적응하라고 외치고 있음
- 이 모든 상황을 통해 얻을 수 있는 교훈:
- 당신이 누구든, 회사든, 개인이든 — 주니어처럼 행동하라
- 지금이 AI 기술을 수용하고 적응할 때임
- Sourcegraph는 이 기술 진화 흐름을 매일 분석하고 있으며,
- 코딩 에이전트를 엔터프라이즈 코드 자산에 연결하는 것이 차세대 핵심 전략임
- 전반적으로 볼 때, AI 도입이 증가함에 따라 소프트웨어 관련 일자리도 오히려 늘어날 것임
- 채용이 정체된 현재는 단지 기업들이 아직 어떻게 대응할지 몰라 신중한 상태일 뿐임
- 역사적으로 기술 전환기마다 생산성이 급증하며 GDP 또한 상승함
- 그러므로 지금 해야 할 일:
- 코딩 에이전트에 대해 학습하고 익히기
- PM이나 다른 기술 직군도 예외 아님
- LLM 기반 개발은 단순한 프롬프트 작성이 아님. 검증, 테스트, 조율 등 실제 개발 실무를 바꿔놓을 것임
- 경고:
- 코딩 에이전트는 강력하지만 터널 굴착기 같은 도구임
- 비싸고, 멈출 수 있고, 방향을 잃을 수 있음
- 지속적인 안내와 현실적인 기대 설정이 필요함
- vibe coding은 그 이름처럼 즐겁게 일할 수 있는 방식임
- 코드를 직접 쓰지 않아도 된다는 점이 의외로 매우 해방감 있음
- “6개월 후면 더 나아질 테니 지금은 기다리자”는 사고는 위험함
- 결국 출발은 늦추고, 도착은 가장 늦어짐
- 에이전트는 오고 있음. 단지 코딩 에이전트가 아니라,
- 전사적 업무 전반에 걸쳐 수백 개의 태스크 에이전트가 이미 도입 중
- 결론적 행동 지침:
- chat으로 전환
- 자동완성은 버림
- 직접 코딩은 줄임
- 검증/검토/실행을 AI 기반 환경에 맞게 학습
- 최신 기술 흐름에 맞춰 계속 실험하고 적용해볼 것
- 지금은 어렵고 불완전해 보이는 코딩 에이전트도 곧 보편화될 것
- 인간 대비 훨씬 저렴한 생산성 기계이며, 기업의 선택은 명확함
- 2025년 말에는 “소프트웨어 엔지니어”라는 직무가 거의 직접 코딩을 하지 않을 것
- 그 대신 에이전트 운영, 조율, 검증 관리가 중심 업무가 될 것
- 끝으로: 지금 뭘 해야 할지 모르겠다면, 주니어 개발자에게 도움을 청할 것
2년 전 ‘Cheating is all you need’를 쓴 지 벌써 두 해가 되었고, 그 사이 모든 것이 바뀌었음
지금이 바로 변화의 한가운데이며, 이 흐름에 올라타야 할 때임