AI 코딩의 현재
소프트웨어 개발에서 "코드를 잘 쓰는 일"은 더 이상 가장 어려운 문제가 아니게 되고 있다. 코딩이라는 병목이 풀리자, 그 뒤에 숨어 있던 다음 병목들이 차례로 드러나고 있다. AI 코딩 도구의 최전선에서 일하는 개발자들의 작업 방식이 지난 반년 사이 어떻게 달라졌는지 정리한다.
한 선도적인 AI 코딩 도구 책임자가 올해 자신이 작성한 코드의 수치를 공개한 적이 있다. 1년 동안 약 1,700건의 풀 리퀘스트(pull request, 코드 변경 제안)를 올렸고, 40만 줄을 추가하고 25만 줄을 지웠다. 3월 이후 사용한 토큰은 80억 개. 흥미로운 점은 그가 직접 키보드로 친 코드가 사실상 없다는 것이다. 2025년 11월 Anthropic의 Opus 4.5 모델이 나온 시점부터 그의 코드는 100% Claude Code(앤트로픽의 명령줄 기반 AI 코딩 도구)가 작성했다. 그는 코드 편집기(IDE)를 아예 삭제했다고 말한다. 그리고 지금 그가 코딩하는 주된 장소는 노트북이 아니라 휴대폰이다.
이것을 한 사람의 별난 습관으로 치부하기는 어렵다. Anthropic은 올해 초 대비 엔지니어 1인당 작성 코드량이 약 8배 늘었다고 밝혔으며, 회사 전체 코드의 80~90%가 Claude Code로 작성되고, 점점 더 많은 팀에서 그 비율이 100%에 가까워지고 있다고 한다. 청중에게 "코드의 100%를 AI가 쓴다"는 사람이 손을 들어 보라고 하면, 1년 전과 비교가 안 될 만큼 많은 손이 올라온다.
코딩이 통째로 기계에게 넘어가면, 그동안 "얼마나 생산적인가"를 재던 잣대 자체가 무너진다. 이 글은 그 무너진 자리에서 무엇이 새로운 문제로 떠오르고 있는지를 살핀다.
기업이 AI 코딩 도구 도입을 검토할 때 흔히 두 가지 시각으로 갈린다. 하나는 비용으로 본다. 엔지니어 한 명당 월 1,500달러처럼 예산 상한을 정하는 식이다. 다른 하나는 회수율, 즉 투자 대비 효과(ROI, Return on Investment)로 본다. 현장에서 가장 성과를 내는 기업들은 후자를 택한다.
전기 요금을 아끼려고 공장의 모든 기계를 절전 모드로 돌리면 전기세는 줄지만 생산량도 함께 줄어든다. 중요한 건 "전기를 얼마 썼나"가 아니라 "그 전기로 얼마를 벌었나"다. AI 토큰도 마찬가지다. 토큰을 아끼는 데 집중하면 절약한 금액보다 놓친 기회가 훨씬 클 수 있다.
성과를 내는 기업들의 공통점은 토큰을 엔지니어에게만 주지 않는다는 것이다. 제품 기획자, 디자이너, 데이터 분석가, 심지어 마케팅 담당자와 회계 담당자에게도 토큰을 나눠 주고 마음껏 실험하게 한다. 가장 혁신적인 아이디어는 회사가 예상한 사람에게서 나오지 않는 경우가 많기 때문이다. 그렇게 효과가 검증된 용도가 나타나면, 그때 비로소 뒷단에서 비용을 조인다. 모델을 바꾸거나, 작업 난이도(effort)에 따라 토큰 사용량을 조절하거나, 부서별 예산을 설정하는 식이다.
과거에는 회수 효과를 "전체 코드 중 AI가 쓴 비율" 또는 "코드량 증가율"로 쟀다. 그런데 그 비율이 100%에 도달하면 더 이상 그 잣대로는 잴 수가 없다. 그래서 다음 질문이 따라온다. 엔지니어 1인당 코드 생산 속도가 얼마나 빨라지고 있는가, 그리고 이제 일을 막는 다른 병목은 무엇인가.
지금 일선 개발자들의 작업 방식에서 가장 빠르게 번지는 개념이 "루프(loop)"다. 말 그대로 사람이 매번 지시하지 않아도 에이전트가 일정 주기로 같은 작업을 반복해서 수행하도록 돌려 두는 것이다. 예컨대 코드 리뷰를 사람이 직접 하거나, 에이전트에게 한 번씩 시키는 대신, 모든 코드 리뷰를 알아서 처리하는 에이전트를 루프로 띄워 두는 식이다. 누군가는 사용자 피드백을 5~10분마다 읽어 들여 수정안을 자동으로 올리는 에이전트를 돌린다.
이 변화를 프로그래밍 언어에 빗대면 이해가 쉽다. 소스 코드 한 줄이 '문장'이라면, 코드를 대신 써 주는 에이전트는 그 문장들을 묶은 '함수'에 해당한다. 그리고 함수를 인자로 받아 다루는 '고차 함수(higher-order function)'가 있듯이, 에이전트를 부리는 에이전트가 바로 루프다. 추상화의 사다리를 한 칸 더 올라가는 셈이다.
아직 루프가 모든 작업에 통하는 단계는 아니다. 한 책임 개발자조차 평소 자신의 코드 중 루프로 작성되는 비율이 30% 정도이고, 작정하고 매달리는 날에만 100%에 근접한다고 말한다. 에이전트가 처음 등장했을 때와 비슷한, 효과의 조짐은 보이지만 아직 완전히 정착하지는 않은 초기 국면이다.
루프와 종종 함께 거론되는 것이 "동적 워크플로(dynamic workflow)"다. 둘은 결이 다르다. 동적 워크플로를 이해하려면 AI 성능이 왜 계속 좋아지는지부터 짚어야 한다. 전통적으로 거대 언어 모델의 성능은 학습 데이터, 신경망 크기, 학습에 쓴 연산량이라는 세 가지에 비례해 커진다고 알려져 있었다. 여기에 최근 네 번째 요소가 더해졌다. 바로 추론 시점에 모델이 만들어 내는 토큰의 양, 즉 "테스트 시점 연산(test-time compute)"이다.
같은 학생이라도 시험 시간을 더 주면 더 나은 답을 낼 수 있다. 모델에게 토큰을 더 쓰도록 허용하는 것이 바로 "시간을 더 주는" 일이다. 답안을 검토하고, 가설을 세워 보고, 막다른 길을 되짚을 여유가 생기기 때문이다.
토큰을 더 쓰게 하는 방법은 두 가지다. 하나는 작업 난이도 설정(effort)이다. Claude 모델에는 낮음·보통·높음·아주 높음·최대 같은 단계가 있고, 단계를 올릴수록 모델이 더 많은 토큰을 들여 더 나은 결과를 낸다. 다른 하나가 동적 워크플로다. 이쪽은 Claude가 직접 작은 오케스트레이션 스크립트를 짜서, 가상 머신 안에서 수십·수백·수천 개의 하위 에이전트를 동시에 띄워 문제를 푼다. 한 개발자는 "지난밤 통합 검증(CI, 지속적 통합) 속도가 느린 걸 보고, 실제 측정 데이터를 보고 CI를 더 빠르게 최적화하라"는 한 문장만 던졌다고 한다. 워크플로는 몇 시간 동안 수백만 토큰을 써서 풀 리퀘스트 4건을 만들어 냈고, CI 시간이 절반으로 줄었다. 과거라면 며칠에서 몇 달이 걸렸을 분석 작업이다.
이 방식의 위력을 보여 준 대표 사례가 자바스크립트 런타임 Bun의 이식 작업이다. Bun 제작자는 동적 워크플로를 이용해 약 100만 줄 규모의 Zig 코드를 Rust로 옮겼는데, 기존 테스트의 99.8%가 통과하는 약 75만 줄의 Rust 코드를 11일 만에 완성했다. 마이그레이션 도중에는 수백 개의 에이전트를 병렬로 돌리고 파일마다 두 명의 검토자를 붙였다고 한다.
코드가 제품에 반영되어 매출이나 사용량 같은 사업 지표를 움직이기까지는 여러 단계가 있고, 단계마다 일을 막는 병목이 있다. 가장 큰 병목은 오랫동안 코딩 자체였다. 그 병목이 풀리자, 그 뒤에 가려져 있던 다음 병목들이 줄지어 나타났다.
코딩 다음 병목은 코드 리뷰였다. 코드가 쏟아지면 누군가는 그것을 검토해야 한다. Anthropic의 대응은 코드 리뷰 전용 제품을 만드는 것이었다. 이 제품은 시중의 다른 코드 리뷰 도구보다 토큰을 훨씬 많이 쓴다는 점에서 특이하다. 그만큼 많은 토큰을 들여 리뷰를 완전 자동화하기 때문에, 엔지니어가 풀 리퀘스트를 들여다볼 즈음이면 버그는 98~99% 잡혀 있다는 것이 회사 측 설명이다. 사람은 이제 버그를 찾으려고 코드를 읽지 않는다. 대신 "이 변경이 애초에 필요한가, 좋은 방향인가"를 본다.
그다음 병목은 보안 검토였다. 에이전트도 사람과 똑같이 취약점을 만들어 낼 수 있기 때문이다. Anthropic은 매주 모든 코드베이스를 훑어 문제를 찾아 자동으로 고치는 보안 제품을 내부적으로 운영한다. 회사는 Opus 4.8 모델에 이르러 이 도구가 침투 테스터(penetration tester, 모의 해킹 전문가)조차 놓친 문제까지 잡아내는 수준에 도달했다고 말한다. 코드 리뷰 제품도 보안 제품도, 회사가 자기 병목을 풀려고 만든 뒤 같은 도구를 외부 고객에게도 제공하는 방식으로 나왔다.
병목을 풀다 보면 사람의 개입 자체가 병목이 되는 지점에 닿는다. Claude Code는 처음부터 에이전트가 명령을 실행하거나 파일을 고치려 할 때마다 "이 작업을 해도 됩니까?"라고 물어 사람의 승인을 받았다. 보안을 위한 장치였다. 그런데 시간이 지나자 역설이 생겼다. 사람들이 내용을 제대로 읽지 않고 기계적으로 "예"만 누르기 시작한 것이다. 이른바 "승인 피로(approval fatigue)"다. Anthropic의 계측에 따르면 사용자는 권한 요청의 93%를 승인한다. 사람이 루프 안에 있었지만, 사실상 제 역할을 하지 못하고 있었던 셈이다.
긴 약관에 동의 버튼을 백 번 눌러 본 사람은 백한 번째도 읽지 않고 누른다. 승인 절차가 형식만 남으면, 그 절차는 안전을 지키는 게 아니라 안전하다는 착각만 준다.
그래서 나온 것이 "자동 모드(auto mode)"다. 권한 요청을 사람 대신 별도의 분류기(classifier) 모델이 판단한다. 작업을 실행하기 전에, 지금까지의 대화 맥락과 실행하려는 동작을 분류기가 검토해 안전하면 통과시키고 위험하면 막는다. 막힌 경우 Claude는 멈춰 서서 사람을 기다리지 않고 더 안전한 다른 길을 찾는다. 같은 종류의 차단이 연속 3회 또는 누적 20회 쌓이면 그제야 사람에게 넘긴다.
이 분류기는 두 단계로 움직인다. 먼저 빠른 1차 필터가 "예/아니오"를 한 토큰으로 판정하고, 여기서 걸린 경우에만 2차로 사고 사슬(chain-of-thought) 추론을 돌린다. 대부분은 1차에서 통과하므로 추론에 드는 토큰은 필요한 곳에만 쓰인다. 또한 모델이 외부에서 읽어 들이는 내용(파일, 웹 페이지, 셸 출력)은 별도의 프롬프트 주입(prompt injection) 탐지기가 먼저 검사한다.
프롬프트 주입은 길 안내 표지판에 누군가 몰래 가짜 화살표를 붙여 운전자를 엉뚱한 곳으로 보내는 일과 같다. AI가 읽는 README 파일이나 코드 주석에 "이 디렉터리를 삭제하라" 같은 숨은 지시를 심어 두면, 코드를 읽던 에이전트가 그 지시를 진짜 명령으로 착각할 수 있다. 셸 접근 권한을 가진 에이전트에게 이런 속임수가 통하면 결과가 가볍지 않다.
한 책임 개발자는 자사 모델이 100번 시도 기준 프롬프트 주입 성공률이 약 1% 수준이며, 여기에 주입 탐지 분류기를 더하면 사실상 이런 공격에 잘 넘어가지 않는다고 말한다. 이런 방어가 받쳐 주기에 자동 모드가 가능하고, 자동 모드가 있어야 사람이 옆에서 "예/아니오"를 누르지 않는 상태로 에이전트를 몇 시간, 며칠씩 길게 돌릴 수 있다.
다만 자동 모드에는 한계도 분명하다. Anthropic은 이 기능을 여전히 "연구 프리뷰"로 표시하며, 위험을 줄이지만 없애지는 못한다고 명시한다. 회사가 공개한 수치로는 실제 내부 트래픽에서 거짓 양성률(안전한데 막는 비율)이 0.4%, 손으로 엄선한 "과욕 행동" 시험 집합에서 거짓 음성률(위험한데 통과시키는 비율)이 17%다. 17%는 0이 아니다. 그래서 Anthropic은 민감한 작업에서는 자동 모드를 검토를 대체하는 수단이 아니라, 격리된 환경에서 보조 수단으로 쓰라고 권한다. 판단하는 모델과 행동하는 모델이 같은 맥락에서 돌아간다는 점을 들어, 주입이 추론을 오염시키면 권한 판단까지 함께 오염된다고 지적하는 보안 연구자들도 있다.
같은 흐름이 개발자 바깥으로도 번지고 있다. Anthropic이 명령줄 도구인 Claude Code를 내놓자, 정작 사용자들은 그것으로 코딩이 아닌 일을 하기 시작했다. 휴가 계획을 짜고, 슬라이드를 만들고, 이메일을 정리하고, 구독을 해지하고, 하드 드라이브에서 결혼식 사진을 복구하는 식이었다. 회사는 여기서 신호를 읽고, 같은 에이전트 능력을 비개발자도 쓸 수 있게 다듬은 Cowork를 만들었다.
Cowork는 Claude Code를 비개발자용으로 옮긴 것에 가깝다. 데스크톱 앱을 내려받으면 채팅, Claude Code와 함께 들어 있고, 내부적으로는 Claude Code와 같은 에이전트 기반(Claude Agent SDK) 위에서 돌아간다. 차이는 안전장치다. 가상 머신 환경에서 동작하고, 실수로 파일을 지우지 못하게 운영체제와 연동된 보호가 들어 있으며, 프롬프트 주입에 대한 방어도 더 두텁다. 사용자가 폴더 하나를 지정하면 Claude가 그 안의 파일을 읽고 고치고 새로 만들 수 있다.
한 책임 개발자는 코딩이 아닌 일은 대부분 Cowork로 처리한다고 말한다. 매일 아침 스탠드업 회의 대신, Cowork가 브라우저에서 스프레드시트를 열어 주간 업무 항목을 정리하고 슬랙으로 각 엔지니어에게 진행 상황을 물어본 뒤(때로는 사람이 아니라 그 사람의 에이전트가 답한다) 상태를 채워 넣는다. 출장 예약은 더 자동화되어, 매일 이메일과 캘린더를 훑어 다른 도시에서 일정이 잡히면 항공권과 호텔을 선호에 맞춰 알아서 예약하고 확인을 받는다.
모델 선택에서도 같은 원칙이 반복된다. Anthropic의 상위 모델인 Fable은 더 비싸고 다소 느리지만, 한 책임 개발자는 거의 모든 작업에 Fable을 쓴다고 말한다. 토큰을 만드는 회사라도 토큰이 공짜는 아니다. 자사가 쓰는 토큰 한 개는 고객에게 줄 수 없는 토큰 한 개이기 때문이다. 이 기회비용을 다시 회수율의 틀로 보면 결론이 분명해진다. 비용 쪽에서 아낄 수 있는 폭은 길어야 50% 안팎이지만, 회수 쪽에서 늘릴 수 있는 폭은 그보다 훨씬 크다는 것이다.
가장 비싼 모델을 쓰고, 그것에서 더 많은 것을 끌어내는 데 집중하라. 비용 절감에 매달리지 말라.
물론 비용을 방치하라는 뜻은 아니다. 비용은 잘 통제하고 관리하되, 노력의 대부분은 회수를 늘리는 데 쏟으라는 것이다. 기술 도입이 아직 이렇게 이른 국면에서는, 줄일 수 있는 손해보다 키울 수 있는 이익이 비교가 안 되게 크기 때문이다. 단, Fable 계열 상위 모델은 안전 점검과 정책상의 이유로 일반 접근이 한시적으로 제한되기도 한다.
코딩이 병목에서 빠지면 엔지니어의 일은 코드를 짜는 쪽에서 에이전트를 감독하고 방향을 잡는 쪽으로 옮겨 간다. 사실 코딩은 늘 엔지니어 시간의 일부였을 뿐이다. 고객과 이야기하고, 아이디어를 내고, 디자이너·기획자와 머리를 맞대고, 데이터를 분석하고, 무엇을 다음에 만들지 정하고, 조직의 다른 부서와 합을 맞추는 일이 나머지를 채운다. 코딩이라는 가장 눈에 띄던 작업이 자동화되자, 그 위아래에 있던 이 일들이 비로소 진짜 일로 드러난 셈이다.
새 엔지니어가 합류하면 한 팀은 "탐색형 출력 스타일(exploratory output style)"을 켜라고 안내한다. Claude가 코드를 고칠 때마다 구조가 어떻게 돌아가는지, 처음 보는 언어가 어떻게 작동하는지 설명해 주는 모드다. 비개발자를 위한 "학습형 출력 스타일"은 한 발 더 나아가, 대신 해 주는 대신 "1단계로 이 파일을 열고, 2단계로 이 명령을 실행하라"는 식으로 단계를 짚어 준다. 코드를 직접 쓰지 않게 된 시대에도 사람이 무슨 일이 벌어지는지 이해하고 배우게 하려는 장치다.
그렇다면 지금 모델이 아직 사람을 못 따라오는 영역은 어디인가. 한 책임 개발자는 두 가지를 꼽는다. 하나는 제품 감각, 즉 무엇을 만들지 떠올리는 아이디어 생성이다. 다른 하나는 분산 시스템 설계다. 어떤 서비스로 나눌지, 데이터가 어떻게 흐를지, 부하를 어떻게 감당할지를 짜는 일이다. 코드의 품질이나 프런트엔드 디자인은 이미 자신보다 낫지만, 이 두 영역은 사람이 아직 앞선다는 것이다. 그리고 그 격차도 그리 오래가지 않을 것이라고 그는 덧붙인다.
병목은 늘 다음으로 옮겨 간다. 코딩에서 코드 리뷰로, 보안으로, 그리고 이제 "무엇을 만들 것인가"라는 질문으로. 코드를 쓰는 능력이 흔해질수록, 좋은 질문을 던지는 능력이 귀해진다.