주니어 개발자의 역습
(sourcegraph.com)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’를 쓴 지 벌써 두 해가 되었고, 그 사이 모든 것이 바뀌었음
지금이 바로 변화의 한가운데이며, 이 흐름에 올라타야 할 때임
감독 에이전트라..
개발 단계가 대충 4개라면(개발, 디버깅, QA 및 디버깅, 리팩토링) 4개 레이어에서 일어나는 할루시를 다 잡을 수 있을지..
지금도 프롬프트에 디버깅과 테스트 요구 정교하게 써놔도 뭐가 문제인지 모르겠다는 헛소리가 가끔 나오는데요(Sonnet 3.7).
트랜스포머 아키텍처 자체가 바뀐다면야 모를까.
습득하는 지식이나 경험의 가치가 떨어지는 측면에서 보면 시니어와 주니어의 경계 자체가 모호 해질것같네요.
그리고 소수 독식 시장이 될 것 같습니다. 앞으로는 개발자 채용이 투입 노력이나 경력여부 보다 타고난 사고력 추론능력이 뛰어난 ai 파일럿을 뽑는 방향이 될것같습니다.
vibe coding 에 동의하기 힘든 이유는 code 기반으로 여전히 일해야 한다는 상황을 ai agent 가 해결해 주지 못하기 때문입니다. agent 가 자율적으로 동작하는 환경이라면 기계가 알아듣기 불편한 code 가 왜 필요할까요?
저는 ai agent 가 진정 소프트웨어 개발의 모습을 바꾸는 순간은 바로, 그것을 지휘하는 사용자에게 code 라는 계층을 완전히 추상화한 순간이라 생각합니다. 아직은 그저 코드조각을 빠르게 생성해 내는 수준(물론 이것도 대단하지만)에 불과하다 생각해요.
ai agent 가 우리를 code 에서 해방시켜주는 순간이 오기 전까지는, 변화가 놀랍기는 해도 그게 소프트웨어 업계의 업무 방식을 극적으로 바꾼다는 주장에는 동의하기 힘드네요.
비슷한 지식과 실력이 있다면 적절한 환경에서 비슷한 결과가 나오겠죠.
개발이란 비교적 많은 자료가 공개된 웹 애플리케이션만 있는게 아니고 그래픽 엔진부터 임베디드, 저수준 칩설계까지 엄청 다양하잖아요. 제로거나 제로에 가깝게 시작하는 분야 많습니다. 저도 제 분야에 관해선 깃헙이고 문서고 인터넷에 제대로 참고 가능한게 없습니다. 당연히 그록이고 클루드고 제대로 된 결과를 내지도 않고요. 전체 코드를 모델에 제공한다던지 파인튜닝은 논외입니다.
아마 이런 전문성이 필요한 개발을 하지 않거나 사내에 노출이 금지된 자산이 없으신거 같으신데 본인이 상황을 정확하게 파악하고 있다는 확신을 안 가지시는게 좋습니다.
인터넷에 없으면 AI 가 침범할 수 없다는 논지는 조금 이상하지 않나요? 학습 방법에 대한 연구가 계속 될수록 인하우스 AI가 인하우스 개발자의 자리를 대체할거라고 생각했어요
현대 자동차 메가팩토리 도입과 비슷하다고 생각하고 있습니다.
전통적인 노동자는 셋업 및 메인터넌스로 전환되겠지요. (이 부분은 좀더 이해가 됩니다.)
다만, 추상의 영역을 다루는 부분까지도 그렇게 될 것인지는?
개인적으로는 가능하고 생각하고 있습니다.
마지막 주니어 내용만 아니면 어느정도 동감되긴 하네요.
AI를 못받아들이는 시니어나 기존 회사들은 세대교체가 될것이다 정도가 더 정확한거 같습니다.
감독도 뭘 알아야하지… 노는지 일하는 지 뻘짓하는지 잘하고 있는지… 감독은 전기 껐다 켜는 사람인 줄…
전기 껐다 켜는게 감독이 하는 일이라면… 그 감독이야말로 AI로 대체하기 딱 좋은 사람.