바이브 코딩, 코딩 에이전트, 에이전트 클러스터/플릿이 소프트웨어 개발과 예산, 그리고 주니어·시니어 개발자의 역할을 어떻게 바꿀지를 다룬 글.
안녕하세요, 안녕하세요, 안녕하세요! 다시 여러분을 만나 반갑습니다.
요즘은 제가 하는 말을 좀 조심해야 할 것 같습니다. 지켜보는 사람이 너무 많거든요.
아무튼, 며칠 전 방귀를 뀌었는데 소리가 viiiibecooode, 같았고, 곧바로 투자자 3명이 다가왔습니다. 저는 “아니요 죄송한데 그건 그냥 방귀였어요”라고 말해서 겨우 떼어냈습니다.
요즘 너무 많은 일이 벌어지고 있어서, 이번에도 이 글을 여러 번 쓰려고 했는데요. 시도할 때마다 글이 거대하고 난폭해져서, 올드 옐러처럼 전부 안락사(?)시켜야 했습니다. 이번에는 아직 강아지일 때 그냥 출시하겠습니다. (수정: 젠장. 그래도 끝까지 액션이 빵빵하긴 하네요.)
“바이브 코딩(vibe coding)”의 의미에 대한 짧은 메모: 이 글에서는 바이브 코딩이 성숙해져서 사람들이 실제 엔지니어링에 쓰게 될 거라고 가정합니다. “뇌를 끄고 하는” 버전은 프로토타이핑이나 재미 프로젝트용으로 남겠죠. 저에게 바이브 코딩은 그냥 AI가 일을 하게 두는 걸 뜻합니다. AI의 작업을 얼마나 주의 깊게 볼지는 전적으로 문제에 달려 있습니다. 프로덕션에서는 집중하고, 프로토타입에서는 느긋하게. 어느 쪽이든 손으로 직접 쓰지 않았다면 그건 바이브 코딩입니다.
추가 메모 하나: 복수 파트는 영화처럼 맨 마지막에 나옵니다.
좋습니다! 행정 처리(?)는 끝났으니, 가보자고요!
바이브 코딩은 채팅 기반 코딩을 귀엽게 부르는 말입니다. LLM에게 코드를 쓰게 한 다음, 나온 결과를 다시 먹이고 추가 작업을 시키는 일을 계속 반복하는 방식이죠. 전통적인 코딩은 물론, 코드 자동완성과도 아주 다릅니다.
채팅 코딩은 코딩 어시스턴트에서 꽤 오래전부터 존재했지만, 모두가 함께 외칠 구호가 없었습니다. 그런데 2월 초, OpenAI 공동창업자로도 유명한 저명한 안드레이 카르파티 박사가 채팅의 얼굴에 멋진 이름을 붙였습니다. 그는 이를 “vibe coding”이라 불렀고, 거의 하룻밤 사이에 파란/금색 드레스급 논쟁거리로 급부상했습니다.
오늘 기준으로, 잠깐만요 시계 좀 보고… 여러분이 이걸 읽고 있는 바로 지금, 바이브 코딩은 이상하고 전례 없는, 양자역학 같은 삼중 상태에 진입했습니다.
과장 전문 기관인 저희도 이보다 더 미친 걸 지어내기 어렵습니다. 현실인데 전개 속도가 너무 빨라서 진짜 비현실적으로 느껴져요.
바이브 코딩은 가파르게 상승 중이고, 채팅 기반 코딩—여러분이 _바이브 코딩_이라 생각하는 것, 그리고 제가 예전에 CHOP라고 불렀던 것—도 당분간은 계속 증가하고 있습니다. 하지만 이 글의 주제인 에이전틱 코딩(agentic coding)은 곧 채팅 코딩을 정지해 있는 물체처럼 추월해 로켓처럼 치고 올라갈 겁니다.
3분기(Q3)가 되면, 오늘날의 채팅 코딩은 많은 사람에게 최후의 수단이 될 겁니다. 에이전트로 초고속으로 할 수 없을 때만 쓰는 비상 탈출구요. 그 과정에서 채팅 코딩이 가려지더라도, 바이브 코딩은 계속 살아남을 겁니다.
제가 개인적으로 이걸 어떻게 생각하는지, 그림 1에 최대한 담아봤습니다.

그림 1: AI 코딩 양식(modality)의 겹치는 파도
그림 1의 차트는 프로그래밍의 여섯 개 겹치는 파도를 보여줍니다. 전통적(2022), 자동완성 기반(2023), 채팅 기반(2024), 코딩 에이전트(2025 상반기), 에이전트 클러스터(2025 하반기), 에이전트 플릿/함대(2026)입니다.
그림에서 전통적 코딩과 자동완성 기반 코딩—수동 모달리티 두 개—는 감소하고 있고, 나머지는 지수적으로 상승합니다. 채팅부터 시작해서, 각 새 파도는 이전 파도보다 훨씬 빠르게 상승하죠. 마지막으로, 바이브 코딩도 지수적으로 증가하는 것으로 점선으로 표시되어 있는데, 잠시 후 보겠지만 바이브 코딩은 모달리티가 아니기 때문입니다.
논의를 위한 예고편으로, “에이전트 클러스터”는 개발자가 여러 코딩 에이전트를 병렬로 실행하고 유의미하게 관리할 수 있게 되는 상황을 뜻하는 제가 임시로 붙인 이름입니다. 로컬 머신에 다 올리기 어려울 만큼 많이 돌릴 수도 있죠. 그리고 “에이전트 플릿”은 그림 2 ‘FY26 조직도’처럼 말단(leaf node)을 감독하는 AI 슈퍼바이저가 생겨날 때 벌어지는 일입니다.

그림 2: FY26 조직도
이 그림은 조직의 모든 개별 기여자(IC) 개발자(말단 노드)가 2선 라인 매니저처럼 행동하면서 AI “관리자 에이전트”를 운영하고, 그 관리자 에이전트가 다시 여러 코딩 에이전트 그룹을 감독하는 모습을 보여줍니다. 예를 들어, 한 명의 IC 개발자의 지휘 아래에서 한 관리 에이전트 그룹은 버그 백로그 정리(grooming)를 하고, 다른 그룹은 신규 비즈니스 기능을 만들고, 또 다른 그룹은 장기적인 아키텍처 마이그레이션을 수행합니다. 말 그대로 에이전트 농장입니다!
물론 이건 전개를 아주 거칠게 근사한 것이지만, 충분히 가까울 거라 생각합니다. 우리는 모두 “4번째 파도”인 코딩 에이전트가 올 거라고 예측했고, 그들은 생각보다 빨리 도착했습니다. 그리고 이미 노력만 하면 수동으로 5번째 파도에 올라탈 수도 있습니다. 저는 에이전트 두 개를 병렬로 돌리고 있어요. 그렇게 해보면, 많은 작업이 에이전틱 도움으로 더 수월해질 수 있다는 게 분명해집니다.
에이전트가 에이전트를 돕는 방법은 뭘까요? 오늘은 에이전트 작업자가 막혔는지, 끝났는지, 엇나갔는지를 사람이 알아차리고 적절히 툭툭 건드려야 합니다. 슈퍼바이저 에이전트가 곧 그 대부분을 대신해주기 시작할 겁니다. 그 결과가 6번째 파도입니다. 개발자들은 거대한 코딩 에이전트 플릿에서 작업 큐를 가득 채우며, 기업 레거시 코드의 거대한 산맥을 갈아내듯 처리할 수 있게 될 겁니다. 장관이겠죠.
그리고 이런 마법 같은 에이전트 플릿은 늦어도 2026년 초에는 도착할 겁니다. 왜냐하면 만드는 게 그렇게 어렵지 않거든요—우리는 이미 병렬화에 꽤 능숙합니다.
번개처럼 빠른 도입부는 여기까지. 더 많은 이야기가 남아 있습니다. 만약 이게 여러분에게 큰 충격이라면, 앞으로 몇 달은 거친 물살을 만나게 될 겁니다.
여전히 AI 기반 코드 자동완성 제안을 개발자들이 AI를 쓰는 주요 방식으로 생각한다면, 그리고/또는 Completion Acceptance Rate(CAR)을 아직도 측정하고 있다면, 그림 1에서 전통적 프로그래밍(Traditional Programming)을 나타내는 대충 공룡처럼 생긴 곡선 위에 앉아 있는 겁니다. 이 곡선은 2027년쯤이면 빠르게 미끄러지듯 구시대 유물이 됩니다.
안 좋은 소식이 있습니다. 코드 자동완성은 1년 전까지만 해도 매우 인기 있었고, 그 시절은 이제 먼 프리퀄처럼 느껴집니다. 하지만 지금 자동완성은 AI 세계의 “죽은 사람이 걸어다니는” 수준입니다.
좀 더 아방가르드하다면, 올해는 채팅 기반 프로그래밍이 전개될 거라고 생각할 수도 있겠죠. 즉 Copilot, Cursor, Sourcegraph, Windsurf 같은 IDE 내 채팅 인터페이스입니다. 이 그룹이라면 꽤 괜찮습니다. 중간은 했네요. 어깨 두드려 드립니다. 최소한 유용한 모달리티를 채택했으니까요—코드 자동완성에 비하면 _엄청나게_요. 그리고 채팅은 아직도 성장 중입니다.
하지만 갑자기, Aider.chat과 Claude Code 같은 최신 코딩 에이전트 물결이 등장했습니다—그리고 곧 여러분이 좋아하는 모든 IDE에 비슷하고 더 예쁜 에이전트들이 들어올 거고요, 윙크 윙크 기침 기침.
코딩 에이전트를 한번이라도 써보고 효과적으로 사용하는 법을 익히면, 다시 돌아가고 싶지 않을 겁니다. 에이전트는 채팅 코딩을 밟아버릴 겁니다. 그리고 좋은 점은, 에이전트를 써도 여전히 바이브 코딩이라는 겁니다. 그래서 바이브 코딩은 모달리티가 아닙니다. 수동이 아닌 어떤 AI 모달리티로도 바이브 코딩을 할 수 있으니까요: 채팅, 에이전트, 클러스터. AI가 일을 하고 있으면, 당신은 바이브 중입니다! 에이전트의 유일한 차이는, 그들과 덜 자주 “약속 장소에” 나간다는 겁니다.
에이전트가 등장하면서 패턴이 보이기 시작했습니다. 채팅부터 시작해, 각 다음 모달리티 파도는 이전 파도 대비 보수적으로 잡아도 약 5배 더 생산적입니다. 채팅은 수동 코딩보다 5배 생산적일 수 있고, 에이전트는 채팅보다 5배 생산적일 수 있으며, 이런 식이죠. 참고로, 각 파도가 도전 없이 성숙할 시간을 충분히 얻었다면 아마 이전 대비 10배까지도 갈 겁니다. 하지만 더 새롭고 더 빠른 모달리티가 계속해서 나타나 기존 파도를 눌러버립니다.
제가 오늘 보는 상황은 이렇습니다. 우리는 AI 바다에서 큰 경주를 하고 있고, 점점 더 거칠고 폭력적인 파도에 얻어맞고 있습니다. 살아남는 자는 그 파도를 탈 겁니다. 모든 회사는 그림 1의 하나 또는 여러 채택 곡선 어딘가에 놓여 있습니다. 여러분은 어디쯤인가요?
그리고 여러분, 이것이 제가 생각하는—아주 디즈니화된—미래의 멘탈 모델입니다. 저는 다가올 클러스터와 플릿의 파도가 불가피할 뿐 아니라 사실상 코앞이라고 주장했습니다. 바이브 코딩은 그 풍경에서 내구성 있고 지속적인 특징으로 남을 겁니다—하지만 대부분 사람들이 생각하는 방식은 아닙니다. 바이브 코딩은 단지 “다시는 코드를 쓰지 않게 되는 것”을 뜻합니다.
여기까지 동의한다면, 이제 재무적 영향으로 넘어가봅시다. 먼저 코딩 에이전트가 어떻게 동작하는지 빠르게 설명할게요. 어렵지 않습니다. 돈을 태우기 시작하면 연기가 나면서 더 똑똑해집니다. 그리고 만약 여기까지 동의하지 않더라도, 새 코딩 에이전트를 가지고 놀아보길 권합니다. 진지하게요. 아니면 잘 쓰는 사람을 보세요.
확신하든 회의적이든, 적어도 이 새로운 코딩 에이전트가 실제로 어떻게 작동하는지 봅시다. 마법은 없습니다.
왜 이 몇 주 된 개발이 여러분 회사를 빠르게 곤경에 빠뜨릴 수 있는지 봅시다. 아주 난처한 상황, 곤죽, 진창… 그런 거요.
우리는 이전에도 소프트웨어 코딩 에이전트에 대한 주장을 들어본 적이 있습니다. 하지만 이건 다릅니다. 이런 “진짜” 코딩 에이전트는 여전히 아주 아주 새롭고, 많아야 몇 주 전 물건이며, 1970년대 유닉스 스타일의 텍스트 터미널에서만 돌아갑니다. 이런 걸 얻는 건 평생 걸어 다니다가 누가 공짜로 낙타를 한 마리 주는 것과 비슷합니다. 사실 “원하는 만큼 가져가”라고까지 합니다. 낙타 한 마리 있으면 정말 놀랍죠. 한 마리. 어디든 걸어 다니는 것보다 훨씬 낫지만, 침 뱉고 물고, 엄청난 양의 푸른 잎사귀 먹이를 요구합니다. 주로 50달러, 100달러 지폐요.
많은 분들이 채팅 코딩에 대해 엄청 회의적이었다는 걸 저는 압니다. 사실 개발자들 중 일부는 매니저에게 “나는 계속 코드를 쓰고 싶다”고 명확하고 단호하게 말하기도 했다고 들었습니다. 그게 자기들이 여기 있는 이유라면서요. 쓰기. 코드를. 느리게 말합니다. 제가 귀가 먹은 줄 알고 도움이 될 거라 생각하는 것처럼요. AI에게 코딩 작업을 위임할 일은 절대 없을 거라고 주장합니다. 네! 거기 계신 분! 보입니다.
그 모든 회의론자들은 지금 하는 일을 전부 내려놓거나 들고 있는 걸 바닥에 내던지고, 가장 가까운 낙타에게 달려가 올라타야 합니다. 코딩 에이전트를 다운로드해서 써보세요. 가능하면 2025년 3월 1일 이후에 출시된 걸로요. 왜냐하면 이들은 AI로 코딩하는 것에 대해 여러분이 알고 있거나 안다고 생각했던 모든 걸 완전히 뒤집어 놓기 때문입니다. 저도 불과 3주 전만 해도 제 눈을 의심했어요.
원리상 코딩 에이전트는 단순합니다. 전형적인 바이브 코딩 채팅 세션처럼 LLM이 대부분의 분석과 중노동을 하고, 인간은 주로 헤드폰을 끼고 있는 방식이죠. 하지만 에이전트에서는 느린 인간 부분—양방향 복사/붙여넣기와 그에 딸린 프롬프트 노동—을 여러분이 할 필요가 없습니다. 대신 에이전트가 그걸 맡아서 처리하고, 작업을 끝내거나 막히거나 돈이 떨어질 때만 다시 여러분과 채팅으로 돌아옵니다.
그리고 종종, 거의 도움 없이도 꽤 멀리 갑니다. 필요하면 문제 공간을 탐색하기 위해 토큰을 마구 던지면서 작업을 갈아 넣어, 결국 맞는 답을 찾을 때까지 갈아붙입니다. 인간은 작업의 90~99%에서 병목이 아니게 되지만, 그 외에는 “더 빠른 채팅 바이브 코딩”과 거의 같습니다.
비용을 제외하면 채팅과의 실질적 차이는, 에이전트가 한 번에 훨씬 더 큰 하위 작업을 수행할 수 있다는 점입니다. 여러 개의 개별 단계를 포함하는 큰 작업도요. 그 동안 감독 개발자는 치토스 한 봉지 마무리하고 HN을 구경하는 같은 중요한 일에 자유로워집니다.
구체적으로 말하면, 코딩 에이전트에게 “JIRA 티켓 #_<번호>_가 여기 있어요. 이거 고쳐주세요.”라고 말할 수 있습니다. 그게 전부입니다. 에이전트는 먼저 JIRA 티켓에 접근하려고 애쓸 겁니다. JIRA 커맨드라인 툴을 찾을 수도 있고, 다운로드해도 되는지 여러분에게 물을 수도 있죠. 심지어 티켓 필드를 프로그램으로 가져오려고 자기 자신을 위해 일회성(throwaway) 프로그램을 쓸 수도 있습니다. 이런 일회성 프로그램을 쓰는 걸 우리는 꽤 자주 봅니다.
티켓을 읽을 수 있게 되면, 에이전트는 여러분이 하듯이 여러분 컴퓨터의 도구들을 이용해 코드를 살펴보고 버그를 추적합니다. 각 도구에 대해 권한을 요청하는데, 이게 오늘날 프로세스의 가장 큰 느려짐 원인 중 하나죠. 버그를 찾으면 수정안을 제안하고, 수정 검증을 위한 테스트를 작성하고, 테스트를 실행하고, 테스트가 통과하도록 필요한 변경을 추가로 수행합니다—대부분 여러분 도움 없이, 루프를 돌면서요.
이 새로운 코딩 에이전트는 큰 이슈를 해결할 수도 있고, 더 큰 난장판을 만들 수도 있으며, 전반적으로 “초자연적으로 빠른 인간 개발자”처럼 행동합니다. 다만 항상 약간 눈이 가려져 있고, 약간 마감이 임박한 상태죠.
공상과학처럼 들리지만, 지금 당장 쓸 수 있습니다.
중요한 점은, 이 새로운 에이전트들이 한 번에 처리할 수 있는 건 아직 “적당히 작은~중간 정도”의 작업이라는 겁니다. 예전(12월) 채팅 시대에 우리가 모두 배운 작업 그래프 분해 능력은, 에이전트로 바이브 코딩을 전환하는 지금도 똑같이 중요합니다. 오히려 더 중요하죠. 에이전트가 너무 효과적이라, 쉽게 욕심내고 과하게 시켜서 거위를 질식시켜버릴 수 있기 때문입니다.
거위를 잘 대해주세요. 억지로 너무 많이 먹이지 마세요. 잘게 쪼개고, 코딩 에이전트를 조심히 몰아야 합니다. “내 JIRA 티켓 전부 고쳐줘”처럼 너무 큰 일을 주면, 에이전트는 문제에 몸을 던지지만 거의 진척이 없을 겁니다. 오늘 기준으로는 신중한 감독과 문제 선정이 필요합니다. 요약하면, 다루기 까다로운 짐승들입니다.
하지만 바뀔 겁니다. 짐승 얘기가 나와서 말인데, 눈 깜짝할 사이에 에이전트는 낙타가 아니라 안장이 갖춰진 말로서 여러분의 IDE 속으로 들어올 겁니다. 주로 인체공학적 개선이겠죠. 그래도 환영할 만한 변화입니다. 36미터 거리의 물체에 높은 정확도로 악취 나는 액체를 뿜어내는 도구는 없으면 좋잖아요.
앞으로의 모든 툴 반복(iteration)은 코딩 에이전트를 더 쉽고, 더 병렬화 가능하게, 더 강력하게 만들어줄 겁니다. 그리고 올해에는 이런 “진짜로 드라마틱한” 전진을 더 자주 보게 될 겁니다.
다음은 전차입니다. 기다려 보세요.
이 섹션은 CIO와 재무 담당자를 위한 것입니다. 안녕하세요. 여기까지 읽어주셔서 감사합니다.
몇 주 전에 막 마무리한 FY26 계획에서, 개발자 LLM 사용(지출)을 위한 운영비(opex) 예산을 얼마나 잡아두셨나요? 조금? 많이? 어떤 회사는 개발자 1인당 하루 25달러라는 넉넉한 예산을 고려 중이라고 말해줬습니다. 꽤 대담하죠. 거의 무모한 수준입니다.
결론부터 말하면, 그들은 방향을 맞췄습니다. 코딩 에이전트는 très cher, muy caro, 즉 엄청 비쌉니다. LLM 토큰을 많이 태웁니다. 현재 요금으로 시간당 10~12달러 정도요. 지금 여러분의 코딩 어시스턴트 좌석당 라이선스는 얼마죠? 한 달에 30달러? 대략? 더 적을 수도 있고요.
계산을 위한 경험칙으로, “코딩 에이전트 인스턴스 하나”는 (올 회계연도 동안 상각해서) “주니어급 소프트웨어 개발자 한 명을 추가로 고용한 것”과 대략 비슷한 가치를 가진다고 생각할 수 있습니다—단, 누군가(인간 또는 AI)가 하루 8~10시간 정도 대부분의 시간을 바쁘게 채워주고 있다는 전제에서요.
굉장한 경험칙이죠. 시간당 10달러면, 잘 돌봐주기만 하면 되는 전문 소프트웨어 엔지니어를 쓰는 건데, 싸다고 느끼실 겁니다.
그래서 개발자 1인당 하루 LLM 지출을 $80~$100 정도로 예산 잡는 게 가치가 있을 겁니다. 하루 30달러면 낙타를 3시간 타고 점심 이후에는 다시 걸어 다니는 수준입니다. 하지만 벤자민 프랭클린 한 장(100달러)을 내면, 개발자 한 명이 두 에이전트를 돌보는 보모 역할을 하면서 옆에서 다른 일도 처리할 수 있으니, 산출량이 쉽게 _두 배_가 됩니다. 고민할 필요가 없죠.
하지만.
제가 “에이전트 클러스터”라고 부르는 다음 파도—직전 섹션에서 암시한 전차—는 3분기(Q3)에는 상륙할 겁니다. 이 파도는 각 개발자가 여러 에이전트를 동시에 병렬로 실행할 수 있게 해줍니다. 각 에이전트는 서로 다른 작업을 담당하죠: 버그 수정, 이슈 구체화(refinement), 신규 기능, 백로그 그루밍, 배포, 문서화… 개발자가 하는 거의 모든 일요.
각 개발자는 갑자기 여러 명의 개발자처럼 됩니다. 적어도 잘하는 사람은요. (복선: 복수의 냄새가 납니다.)
에이전트 클러스터는 소프트웨어 개발을 마침내 클라우드로 옮기는 부수 효과도 가져올 겁니다. 사람들은 수십 년 동안 클라우드 IDE를 예측해왔죠! 맞죠? 아마 절반은 한 번쯤 만들어보려 했을 겁니다. 너무 당연한 아이디어 같으니까요.
하지만 로컬에서 IDE를 돌리는 게 항상 더 편했기 때문에, 클라우드 개발은 크게 뜨지 못했습니다. 2025년 하반기(H2) 에이전트 클러스터 파도가 그걸 바꿔버릴 겁니다. 개발자 데스크톱은 에이전트를 수십 개 동시에 돌릴 힘이 없습니다. 수백 개는 말할 것도 없죠. 개발자 업무의 대부분은 사실상 하룻밤 사이에 클라우드로 올라갈 겁니다.
그러니 클라우드 예산도 좀 더 필요하겠죠.
N개의 에이전트를 동시에 돌리면, 개발자의 “시간당 10달러”라는 무해해 보이는 일일 지출이 N배가 됩니다. 그리고 이건 클라우드 비용이 아니라 순수 토큰 소모만입니다. 개발자들이 평균적으로 동시에 에이전트 5개를 돌린다면—에이전트는 대부분 독립적으로 일하고 개발자는 다른 일을 할 수 있으니, 이건 매우 보수적인 숫자입니다—각 개발자는 시간당 50달러, 연간 대략 10만 달러를 쓰게 됩니다.
이쯤 되면 “싼 값”이라기보단 “강도”에 가깝습니다. Q4 2025쯤(적응 기간 감안) 개발자 한 명이 생산성을 대략 5배 높이는데, 첫 해에 추가 상각 비용이 대략 연 5만 달러 정도라면—누가 그 거래를 마다하겠어요?
문제는, 여러분이 2026 운영 예산에 개발자 1인당 연 5만 달러의 LLM 지출을 거의 확실히 포함하지 않았다는 겁니다. 이 상황은 빠르게 “예산 있는 회사”와 “예산 없는 회사”를 갈라놓을 것이고, 가진 자는 더 갖게 될 겁니다. 없는 자는… 절반도 못 갖겠죠. 무슨 말인지 아시겠나요?
더 노골적으로 말하면: 소프트웨어 개발은 이제 돈 내고 타는 고속 탄환열차입니다. 표를 살 돈이 없으면, 무리에서 뒤로 밀려(적색편이처럼) 사라질 위험이 있습니다.
여기서부터 조금 불편해집니다. 이미 땀이 나거나 두근거림이 있다면, 잠깐 쉬세요. 탄산음료를 마시든, 이력서를 꺼내 먼지를 털든… 천천히요. 준비되면 오세요. 기다릴게요.
좋습니다. 이제부터 여러분 모두 쿨하다고 약속, 스카우트 명예로. 갑시다.
클러스터 다음 파도, 즉 “플릿(fleets)”은 개발자가 한 번에 100개 이상의 에이전트를 돌릴 수 있게 해줄 겁니다… 더 많은 에이전트의 도움을 받아서요. 감독(슈퍼바이저) 에이전트가 코딩 에이전트의 그룹/팟을 운영하고, 중재하며, 정말 막힐 때만 인간을 호출하게 될 겁니다.
가까운 미래의 소프트웨어 개발자 새 직업은 그림 2(FY26 조직도)처럼, 코딩 에이전트와 그들의 AI 감독자를 보여주는 대시보드를 관리하는 일이 될 겁니다. 어떤 사람은 이를 경멸적으로 _베이비시팅_이라 부르며 AI가 어른이 음식을 잘게 잘라주고 기저귀를 갈아주고, 지저분한 걸 치우고, 울타리 밖으로 못 나가게 해줘야 하는 징징대는 아기 로봇이라고 비난할지도요. 하지만 우리는 그걸 _소프트웨어 개발_이라고 부르기로 했습니다. 이게 우리의 운명입니다.
CIO 타입의 여러분께: 플릿은 개발자들이 하루에 수천 달러를 쓰게 만들 수 있습니다. 추론 비용이 폭락하더라도 제번스의 역설(Jevons Paradox) 때문에 비용 감소를 상쇄할 만큼 사용량이 늘어날 겁니다. 못 믿겠다면 버그 백로그를 보세요. 거의 무한대입니다.
하루에 수천 달러!? 하지만 그건 정말 가치 있는 지출입니다! 엔지니어링 조직이 (드디어) 여러분이 원하는 만큼 빠르게 움직일 수 있게 될 겁니다. 믿기나요? 다시 스타트업이 된 느낌일 겁니다. 제프 베이조스가 좋아하는 표현처럼, 고객을 “놀라게 하고 기쁘게” 하는 일을 여러분이 상상도 못한 수준으로 해낼 수 있게 됩니다.
하지만 그만큼의 새 예산을 어딘가에서 찾아야 합니다. 회사가 현금이 많다면 운이 좋은 편이겠죠. 방금 들은 소식인데(지금 이 글을 쓰는 시점의 속보로), 여러분이 다 아는 유명 대기업이 올해 LLM 실험을 위한 큰 비자금을 따로 잡아뒀다고 합니다. 얼마나 많은 회사가 그렇게 했을까요? 그리고 그렇게 함으로써, 의도치 않게 올해 예산 계획의 블랙스완 이벤트를 피해간 걸까요?
소파 쿠션 사이에서 동전을 찾듯 긁어모아도 연말까지 개발자 1인당 추가 5만 달러를 마련할 수 없다면, 방법은 하나—어떻게든 돈을 더 조달하는 겁니다. 지금은 스타트업이 대기업보다 이 게임을 더 잘할 수도 있겠네요. 에이전트는 많은 경기장을 평평하게 만들어버린 것 같습니다.
이 이야기에서 무서운 부분은, 돈을 찾거나 조달할 수 없는데도 경쟁력을 유지하고 싶다면, 운영비 예산을 확보하기 위해 고통스러운 삭감을 해야 한다는 겁니다. 그리고 숫자를 다시 돌려보면, 줄이기 합리적인 부서는 딱 하나뿐입니다.
나머지는… 독자 과제입니다. 저는 무슨 일이 벌어질지 모르겠습니다. 저는 그냥 어떤 사람이거든요. 어쩌면 이건 다 과장일 수도 있고, 제 예측이 실현되기까지 6개월쯤 더 걸릴 수도 있겠죠. 저는 Claude와 한참 논쟁했고, Claude는 “모든 추정을 6개월씩 미루면 그럴듯하다”고 양보했습니다. 그러니 나쁜 소식이 아주 나쁘기만 한 건 아닐 수도요!
이제 좋은 소식입니다! 나쁜 소식을 먼저 말해달라고 하셨죠? 뭐 어쨌든, 이제 그건 지나갔습니다. 여기서부터는 쉽습니다. 거의 끝났고, 남은 건 달콤한 복수뿐입니다.
알고 보니, 앞날이 전부 암울한 것만은 아닙니다. 전혀요! 소프트웨어 업계에는 엄청 많은 일이 생길 겁니다. 다만, 야만인처럼 손으로 코드를 직접 쓰는 종류의 일은 아니겠죠.
제가 지난 1년 동안, “주니어 개발자의 죽음”을 쓴 이후로 일관되게 본 패턴 하나는, 주니어 개발자들이 시니어보다 AI 채택에 훨씬 더 적극적이라는 점입니다. 물론 항상 그렇진 않습니다. 어떤 분들은 주니어들이 “일자리를 뺏길까 봐” (다소 비합리적으로) AI 사용을 무서워한다고도 말해줬습니다. (행동 후회 이론(Behavioral regret theory) 참고. 단서 주신 Daniel Rock 박사님 감사합니다!)
하지만 대체로 주니어 개발자—(a) 갓 데뷔한 개발자, (b) 아직 학교에 있는 개발자, (c) 아직도 학교 갈까 고민하는 개발자—는 이걸 정말 빨리 익힙니다. 모두가 이제 표지부터 표지까지 알아야 하는 O’Reilly 『AI Engineering』 책을 집어 들고, 직무 훈련처럼 대합니다. 모두 채팅 코딩을 하고, 모두 코딩 어시스턴트를 쓰고, 그리고 저는 알고 있습니다. 주니어 개발자 여러분 중 상당수가 이미 코딩 에이전트를 쓰고 있다는 걸요.
주니어는 바이브를 탑니다. 이해합니다. 세상은 변하고 있고, 적응해야 한다는 걸. 그래서 적응합니다!
반면 시니어 개발자는… 음, 좋게 말해 고전 중입니다. 저처럼 오래된 친구들 중에는 LLM을 거의 만져본 적도 없고, 심지어 ‘벌거벗은 LLM’을 본 적도 없는 사람도 많습니다. 다른 많은 사람은 코딩 어시스턴트를 아주 살짝만 써봤을 뿐입니다. 업계 리더들로부터 “시니어 개발자 집단이 아예 반대 입장을 취한다”는 얘기도 자주 듣습니다.
예를 들어, 유명 브랜드의 한 테크 디렉터가 방금 제게 말해줬는데요. 그 팀의 한 개발자가 “AI를 버리고 일반 코딩으로 돌아가야 하는 이유”를 컬러 슬라이드와 차트로 설명한 PDF를 보냈다고 합니다. 제가 왜 “기술 역사상 이해도의 분포가 가장 넓다”고 했는지 이제 알겠죠? 아직도 이걸 크립토 같은 거라고 생각하는 사람도 있습니다. 큰일이죠.
보세요, 어떤 시니어는 단순히 바쁘기 때문에 힘든 것일 수도 있습니다. 이해합니다. 하지만 대부분은 더 깊은 이유가 있다고 봅니다. 제가 예전에 프로그래밍 언어에 대해 블로그를 쓸 때, 어떤 언어든 “나는 이 언어가 좋다”고 말만 해도 놀랄 만큼 심각한 난리가 났습니다. 사람들이 댓글에서 소리를 지르고, 디지털 침이 사방으로 튀었죠. 저는 이해가 안 됐습니다. 언어가 좋다는 말 하나에 이렇게까지?
몇 년 지나고 깨달은 건, 사람들이 제 말을 들으면 다 그 언어로 갈아탈 거라고 느꼈고, 그러면 시니어 개발자들은 그 언어를 새로 배워야 한다고 생각했다는 겁니다. 그들은 “새로운 것을 배워야 한다”—진짜로 새로운 것, 거의 다시 시작하는 수준—를 “일자리와 건강보험을 잃고, 파산하고, 병원 계단에서 죽는 것”과 동일시했습니다. 큰 불확실한 변화 앞에서 나타나는, 인간의 본성이죠.
저는 AI 거부자들이 안타깝게도 현 상태(status quo)에 많은 걸 투자하고 있다고 봅니다. 그들은 그것이 직업 안정성과 같다고 생각하지만, 그건 엄청난 착각입니다. 그들은 AI가 아직 X, Y, Z에서 자기들보다 낫다는 걸 증명하지 못했다고 스스로 말하며, 그러므로 아직 준비가 안 됐다고 결론 내립니다.
하지만 제가 보기엔, 준비가 안 된 건 그들입니다. 친구들이여, 여러분이 스스로를 구할 수 있도록 이걸 자세히 풀어놓는 겁니다.
그들이 왜 채택을 거부하든 간에, 그들은 졌습니다. 주니어가 고지를 점령했고, 전투는 이미 끝났습니다. 주니어는 평균적으로 AI를 더 빠르게 채택할 뿐 아니라—놀랍게도—더 저렴합니다. 토큰으로 승리하기 위해 회사가 삭감을 해야 한다면, 어떤 개발자를 남길 것 같나요?
AI 버티기 집단은 이 모든 걸 전혀 예상하지 못합니다. 그래서 주니어 개발자들이 언덕 위에서 라이트세이버를 내리고 이렇게 외쳐야 합니다.
AI가 당신보다 낫다는 걸 증명해야 하는 건 AI의 일이 아닙니다. AI를 사용해서 더 나아져야 하는 건 _당신_의 일입니다.
그렇지 않으면… 아시죠. else 절. else 절. 용암. 거기 빠지는 거요. 제가 이걸 왜 일일이 말해야 하죠?
자! 이제 영화의 끝입니다. 여기까지 오셨네요. 주니어 개발자 여러분, 하이파이브! ✋ 작년엔 이걸 예상 못 했는데, 여러분이야말로 패배자를 섬에서 투표로 쫓아내는 역할을 해냈다는 게 정말 인상적입니다. 그리고 이미 이걸 알아차리고 잘 달리고 있는 시니어 개발자들에게도 하이파이브를. 생각보다 많지 않습니다. 적어도 베이 에어리어 버블 밖에서는요.
나머지 분들은… 그 흐름에 몸을 실으세요. 주니어처럼 하세요. 진지하게요. 사실 누구든, 사람이나 회사든 상관없습니다. 몸을 실으세요. 때가 됐습니다. AI는 이미 여기 있습니다.
Sourcegraph에서는 이 문제 공간을 매일 집요할 정도로 연구합니다. 이 모든 것이 믿을 수 없을 정도로 비싸지만, 놀라울 만큼, 그리고 곧 부정할 수 없을 만큼 가치 있게 되는 세상을 향해 일하고 있습니다. 물론 쓰기로 선택한 사람들에게만요. 코딩 에이전트 군대가 루비콘을 건너 행군 중이고, 이를 기업의 IP 자산과 코드베이스에 연결하는 일이 다음 큰 게임이 되었습니다. 저희는 그 부분에 집중하고 있습니다.
더 넓게 보면, 우리는 일자리가 있을 거라고 생각합니다. 아주 많은 일자리요. 지금 채용이 평평한 것은 회사들이 아직 뭘 해야 할지 몰라서 신호를 보내는 것뿐이라고 봅니다. 하지만 바로 이 회계연도에, 규모를 막론한 기업들은 그 어느 때보다 더 야심찰 수 있습니다. 과장 없이요. 증기에서 전기, 컴퓨팅에 이르기까지 역사에서 패턴이 보인다면, 곧 훨씬 더 많은 사람들이 소프트웨어를 만들게 될 겁니다. 그 생산성 파도는 국가 GDP를 놀라운 수준, 100% 이상까지 끌어올릴 수도 있습니다.
하지만 참여하려면 다음 파도를 배워야 합니다. 개발자는 물론이고, PM이든 기술 인접 직무든—어떤 역할이든—코딩 에이전트를 따라잡고, 계속 따라잡아야 합니다. 더 이상 미적거리고 찍먹할 시간이 없습니다. 지금 당장 자동 코딩 에이전트를 쓰는 법을 익히세요. 그리고 다룰 줄 알게 될 때까지 포기하지 마세요. 여러분에게 맞게 작동할 때까지 밀어붙이세요.
그리고 건방지게 너무 세게 밀어붙이려 하지 마세요. 코딩 에이전트는, 삽으로 일하다가 대형 터널 보링 머신을 갖게 된 것과 같습니다. 강합니다. 엄청 강하죠. 하지만 비싸고, 여전히 심각하게 막힐 수 있으며, 항상 조심스럽게 안내해야 합니다. 그리고 그렇게 빠르진 않습니다—하루 만에 영국 해협을 뚫어버리진 못해요. 그러니 처음부터 비현실적인 기대를 하지 마세요. 대신 ChatGPT가 처음 나왔던 2년 전과 비교해 얼마나 달라졌는지, 그리고 최고의 선택지가 채팅이었던 불과 2개월 전과 비교해 얼마나 달라졌는지에 집중하고, 그 차이에 감탄하세요.
즐기세요. 이름이 바이브 코딩인 데는 이유가 있습니다. 코드를 안 쓰는 건 생각보다 꽤 쉽더군요.
“6개월 뒤면 훨씬 빨라질 테니, 그냥 6개월 뒤로 미루자”는 달콤한 일 미루기 함정에 빠지지 마세요. 그건 “교통이 잠잠해질 때까지 기다릴 거야”라고 말하는 것과 같습니다. 운전 시간은 줄어들 수 있죠. 하지만 도착은 꼴찌입니다.
에이전트는 옵니다. 거대한 플릿으로요. 코딩 에이전트만이 아닙니다. 에이전트는 비즈니스 전반과 프로덕션 기술 프로세스 전반에 걸쳐 어디에서나 솟아오르고 있습니다. 오늘 아침 저는 한 대형 고객과 대화했는데, 그들은 이미 수십~수백 개의 “AI 작업 머신”—거대한 워크플로의 특정 부분을 수행하는 맞춤형 에이전트—을 구축해두었다고 합니다. 미래는 지금입니다. 에이전트는 이미 여기 있습니다.
행동 촉구가 필요하다면, 저는 사람과 회사 모두에게 같은 조언을 합니다. 채팅으로 전환하세요. 자동완성은 버리세요. 손으로 코드를 쓰는 것을 멈추세요. 새로운 세계에서 검증(validation)과 검증/확인(verification)이 어떻게 작동하는지 배우세요. 이 분야를 익히고, 최첨단을 추적하세요. 투덜거리지 말고 엔지니어링 과제로 만드세요. 계속 따라가세요. 할 수 있습니다.
무엇보다, 새로운 코딩 에이전트를 아주 주의 깊게 보세요. 오늘은 대부분 개발자에게 거의 못 쓸 물건일 수도 있지만, 오래 가지 않을 겁니다. 전혀 오래 가지 않아요. 이들은 엄청 비싼 생산성 머신—하지만 인간에 비하면 헐값인—입니다. 모두에게 어려운 선택이 다가옵니다.
올해 말까지 “소프트웨어 엔지니어”라는 새 직업은 직접 코딩이 거의 없고, 에이전트 베이비시팅이 매우 많아질 겁니다. 그걸 빨리 받아들일수록 삶이 쉬워질 겁니다.
여기까지 읽고도 뭘 해야 할지 정말 모르겠다면, 주니어 개발자에게 도움을 요청하세요.
대충 이게 전부입니다. “Cheating is all you need” 2주년이 다가오고 있네요. 그 이후로 얼마나 많은 게 바뀌었는지 정말 미쳤습니다. 이 블로그 글을 과거로 보낼 수 있다면, 2년 전의 저는 믿지 못했을 겁니다.
일주일 전에 이런 아이디어 대부분으로 우리의 뇌를 날려준 제 상사 Quinn Slack에게 감사드립니다. 이 글이 어떤 방식으로든 도움이 되었길 바랍니다. 저는 이제 투자자들한테 방귀나 뀌러 가야겠네요. 차오!