AI 코딩 에이전트는 ‘한번 써볼까’ 단계를 지났다. 개발자 한 명이 여러 작업을 병렬로 던지고, 코드 리뷰·리팩터링·버그 수정까지 위임하는 방식이 실무에 스며들었다. 그런데 최근 국내외 보도를 겹쳐 읽으면, 기업의 고민은 ‘성능이 충분한가’에서 ‘이 비용을 계속 감당할 수 있는가’, ‘특정 벤더에 얼마나 묶여도 되는가’로 이미 이동해 있다. 마이크로소프트의 라이선스 취소, 월마트의 자체 개발, 지푸의 신규 진입은 서로 무관한 뉴스처럼 보이지만, ‘비용과 종속을 어떻게 통제할 것인가’라는 같은 질문에 대한 서로 다른 대답이다. 이 글은 그 조각들을 하나의 판단 프레임으로 묶는다.
성능이 아니라 ‘단위경제’가 화두가 된 이유
초기 논의는 대개 “AI가 코드를 얼마나 잘 짜느냐”에 머물렀다. 그런데 실제 파이프라인에 붙이자 다른 숫자가 튀어나왔다. 에이전트는 요청 한 번을 ‘계획→파일 탐색→수정→테스트 실행→실패 시 재시도’라는 루프로 처리한다. 사용자가 보기엔 한 번의 대화지만, 내부에서는 코드베이스 상당 부분을 컨텍스트로 읽어 들이고 모델을 수십 차례 호출한다. 그래서 사용량과 비용은 선형이 아니라 계단식으로 튄다. 한 IT 매체가 ‘코딩 에이전트를 많이 쓸수록 토큰 비용이 인건비 지출을 넘볼 수준으로 커진다’고 지적한 배경이 이것이다. 반면 뉴욕 현장을 전한 보도의 요지는 ‘비용이 올라도 옛 방식으로는 못 돌아간다’였다. 두 문장을 겹치면 결론은 분명하다. 생산성 이득은 실재하지만, 그 이득이 통제되지 않은 비용을 자동으로 정당화하지는 않는다.
그래서 무게중심은 ‘도입 여부’가 아니라 ‘어떤 단위경제로 쓸 것인가’로 넘어갔다. 실무자가 먼저 볼 지점은 세 가지다. ①팀·저장소 단위 월 토큰 상한과 임계치 알림이 걸려 있는가. ②테스트 생성·문서화처럼 반복적이고 정형화된 작업에까지 최상위 모델을 쓰고 있지는 않은가 — 상위 모델과 경량 모델의 토큰 단가는 대개 수 배 이상 벌어지므로, 작업 난도에 따라 모델을 라우팅하는 것만으로 비용이 눈에 띄게 줄어든다. ③에이전트가 컨텍스트로 빨아들이는 파일 범위를 좁힐 설정(무시 목록, 검색 범위 제한)이 있는가. 가장 흔한 오해는 ‘요금제만 무제한이면 끝’이라는 생각이다. 좌석당 정액제라도 대량 호출 구간에서는 별도 종량 과금이나 속도 제한이 붙는 구조가 많아, 파일럿 없이 좌석 수만으로 예산을 잡으면 실측치와 크게 어긋난다.
마이크로소프트의 라이선스 취소가 보내는 신호
마이크로소프트가 사내 개발용으로 쓰던 클로드 코드(Claude Code) 라이선스를 취소했다는 소식은 단순한 ‘계약 종료’ 이상으로 읽힌다. 오픈AI에 대규모로 투자하고 자체 코파일럿 계열을 보유한 기업이 경쟁 진영 계열 도구를 사내에서 쓰던 상황 자체가 전략적으로 미묘했기 때문이다. 여기서 핵심은 ‘어느 도구가 더 낫다’가 아니다. 빅테크조차 코딩 에이전트를 언제든 갈아 끼울 수 있는 ‘중립 유틸리티’가 아니라 협상·전략의 대상인 ‘자산’으로 취급하기 시작했다는 점이다. 도구를 붙이는 결정에 성능만이 아니라 정치·전략이 끼어든다는 뜻이다.
일반 기업이 여기서 가져갈 교훈은 ‘종속의 방향을 미리 설계하라’는 것이다. 에이전트를 깊게 붙일수록 프롬프트 규칙, 커스텀 명령, 워크플로가 특정 도구 문법에 맞춰 쌓이고, 갈아탈 때 이 자산은 그대로 이전되지 않는다. 체크포인트는 이렇다. ①에이전트 설정·프롬프트를 도구 종속 포맷이 아니라 별도 리포지토리에 문서로 관리하는가. ②모델을 교체할 때 동일 과제를 돌려 품질을 비교할 회귀 테스트 세트가 있는가. ③계약이 갑자기 끊겨도 며칠 안에 대체 도구로 옮길 시나리오가 문서화돼 있는가. 초보자가 오해하기 쉬운 지점은 ‘API만 표준이면 이식은 쉽다’는 가정이다. 실제로는 같은 프롬프트라도 모델마다 반응이 달라, 이식의 진짜 비용은 코드 재작성이 아니라 ‘품질 재검증’에서 발생한다. 이 비용을 0으로 잡는 순간 종속은 이미 시작된 셈이다.
자체 개발 vs 상용 구독: 월마트가 던진 손익 문제
월마트가 자체 AI 코딩 에이전트를 만들어 사내에서 인기를 끌고 있으며 ‘빅테크 종속을 깬다’는 취지로 소개된 사례는, 앞의 두 흐름에 대한 하나의 대답이다. 개발 조직이 충분히 크고 호출량이 반복적으로 크면, 외부 구독 비용과 종속 리스크를 함께 줄이기 위해 사내 도구를 만드는 선택이 경제성을 가질 수 있다. 다만 이 사례를 ‘자체 개발이 정답’으로 일반화하는 순간 판단이 어긋난다. 규모의 문제를 원리의 문제로 착각하는 것이기 때문이다.
손익 감각으로 바꿔 보자. 자체 구축에는 도구를 짜는 초기 비용만 드는 게 아니다. 모델 API 요금, 실행 인프라, 그리고 계속 도구를 손봐야 하는 유지보수 인력이라는 ‘보이지 않는 고정비’가 따라붙는다. 대략의 방향은 이렇다. 개발 인원이 수 명~수십 명 규모라면 상용 구독이 거의 항상 저렴하고 빠르다 — 유지보수 인력 한 명의 연봉이 구독료 총액을 이미 웃도는 경우가 많다. 반대로 수백 명 이상이 상시로 쓰고 월 호출 비용이 상당 규모로 반복된다면, 사내 도구가 수개월~1년 안팎에서 손익분기를 넘길 여지가 생긴다. 진짜 함정은 ‘모델까지 직접 만든다’와 ‘상용 모델 위에 우리 워크플로만 얹는다’를 구분하지 못하는 것이다. 월마트류 접근은 대개 후자, 즉 기성 모델을 감싸 사내 규칙·데이터·보안에 맞춘 얇은 계층에 가깝다. 이 구분을 놓치면 두 방향의 실패가 열린다. 비용을 과대평가해 불필요한 자체 모델 학습에 뛰어들거나, 유지보수 부담을 과소평가해 만든 도구가 방치되는 것이다.
경쟁 심화 속에서 독자는 무엇으로 골라야 하나
지푸(Zhipu·智谱)가 ‘Z코드’라는 AI 코딩 플랫폼을 내놓고 클로드 코드·코덱스(Codex)와 정면 대결을 선언한 것처럼, 시장은 한 곳으로 수렴하기보다 다변화하고 있다. 선택지가 늘면 협상력이 생기지만, 동시에 ‘어느 게 제일 똑똑한가’라는 막연한 비교 피로도 커진다. 이 질문은 애초에 답이 없다. 필요한 건 조직 상황에 맞춘 고정된 비교 축이다.
실무에서 바로 쓰는 5가지 축은 다음과 같다. ①비용 구조: 좌석당 정액인지 토큰 종량인지, 대량 호출 구간의 상한·알림이 있는지. ②데이터·보안: 사내 코드가 학습에 쓰이지 않는다는 계약 조항과 저장 리전·보존 정책이 명시돼 있는지. ③이식성: 프롬프트·설정을 표준 형식으로 빼내 종속을 낮출 수 있는지. ④품질 검증: ‘우리’ 저장소로 동일 과제를 던지는 통제된 비교가 가능한지 — 벤더 벤치마크가 아니라 자사 코드에서의 성적이 유일하게 믿을 지표다. ⑤책임·유지보수: 에이전트가 생성한 코드의 리뷰·승인 책임이 사람에게 명확히 남는지. 6개월~2년 관점에서 보면, 단일 승자가 전부를 지배하기보다 ‘용도별 다중 도구’와 ‘비용을 측정·통제하는 역량’이 조직의 경쟁력을 가를 가능성이 높다. 결국 도구 선택보다 중요한 건, 무엇을 쓰든 비용·종속·품질을 수치로 측정하고 필요하면 갈아탈 수 있는 내부 근육을 갖추는 일이다. 그 근육이 없으면 어떤 도구를 골라도 3개월 뒤 같은 고민을 반복하게 된다.
자주 묻는 질문
AI 코딩 에이전트를 쓰면 개발 비용이 정말 줄어드나요?
생산성은 오르지만 총비용이 자동으로 줄지는 않습니다. 에이전트는 요청 한 번을 ‘계획→탐색→수정→테스트→재시도’ 루프로 돌리며 코드베이스를 반복해 읽어, 토큰 사용량이 계단식으로 늘어납니다. 사용량이 클수록 토큰 비용이 인건비에 근접할 수 있다는 지적이 나오는 만큼, 팀·저장소 단위 사용량 상한과 임계치 알림을 먼저 걸고, 정형 작업에는 경량 모델을 쓰는 라우팅부터 잡는 것이 비용 통제의 출발점입니다.
마이크로소프트가 클로드 코드 라이선스를 취소한 건 그 도구 품질이 나빠서인가요?
품질 문제로 단정할 근거는 없습니다. 보도는 취소 사실을 전할 뿐이며, 오히려 오픈AI 투자·자체 도구를 보유한 빅테크가 코딩 에이전트를 전략 자산으로 다루기 시작했다는 신호로 읽는 편이 합리적입니다. 일반 기업에는 ‘특정 도구에 깊이 묶이기 전에 설정·프롬프트를 별도 리포지토리로 관리하고, 회귀 테스트와 대체 시나리오를 준비하라’는 교훈에 가깝습니다.
우리 회사도 월마트처럼 자체 코딩 에이전트를 만드는 게 나을까요?
개발 인원 규모와 반복 호출량이 가릅니다. 수 명~수십 명 규모면 유지보수 인력 인건비가 구독료를 웃도는 경우가 많아 상용 구독이 거의 항상 저렴하고 빠릅니다. 수백 명 이상이 상시로 쓰고 월 호출 비용이 크다면 자체 도구가 손익분기를 넘길 여지가 생깁니다. 단, 대부분의 ‘자체 개발’은 모델을 새로 만드는 게 아니라 기성 모델 위에 사내 규칙을 얹는 얇은 계층이라는 점을 구분해야 유지보수 비용을 오판하지 않습니다.
여러 코딩 에이전트 중 하나를 고를 때 가장 먼저 봐야 할 기준은?
비용 구조, 데이터 정책, 이식성 세 가지가 먼저입니다. 좌석당 정액인지 토큰 종량인지, 사내 코드가 학습에 쓰이지 않는다는 조항이 있는지, 프롬프트·설정을 표준 형식으로 빼낼 수 있는지를 확인하세요. 그다음 벤더 벤치마크가 아니라 ‘자사 저장소’로 동일 과제를 던지는 통제된 품질 비교를 하면, ‘제일 똑똑한 도구’가 아니라 ‘우리에게 맞는 도구’를 고를 수 있습니다.
좌석당 정액 요금제면 비용 걱정은 없는 것 아닌가요?
그렇지 않습니다. 좌석당 정액제라도 대량 호출 구간에서 별도 종량 과금이나 속도 제한이 붙는 구조가 많습니다. 에이전트는 자동 루프로 모델을 수십 차례 호출하기 때문에, 한 명의 좌석이 예상보다 훨씬 큰 사용량을 낼 수 있습니다. 좌석 수만으로 예산을 추정하지 말고, 실제 파일럿에서 인당·저장소당 월 토큰 실측치를 확보한 뒤 상한을 설정하는 것이 안전합니다.