‘AI 코딩 에이전트’가 개발자 커뮤니티를 넘어 기업 IR 자료와 채용 공고에까지 등장하기 시작했다. 커서(Cursor), 클로드 코드(Claude Code)에 더해 중국 Z.ai의 코딩 특화 모델 GLM-5.2와 전용 에이전트 ‘Z코드’, 스페이스X·커서의 공동 모델 추진설, RPA 기업 유아이패스(UiPath)의 코딩 에이전트 통합 플랫폼, 게임사 컴투스의 ‘전 직원 1인 1에이전트’ 선언까지 소식이 겹쳤다. 신제품이 하나 더 나온 게 아니라, 무엇을 ‘도구’로 볼지에 대한 정의 자체가 바뀌는 국면이다. 이 글은 흩어진 보도를 교차해, 지금 경쟁이 어디로 가는지와 도입을 검토하는 실무자가 실제로 무엇을 판단해야 하는지를 정리한다. 결론부터 말하면 판단의 축은 ‘어떤 모델이 제일 똑똑한가’가 아니라 ‘어떤 통제 조건에서 어떤 업무에 붙이느냐’다.
경쟁의 축이 ‘자동완성’에서 ‘작업 완수’로 바뀌었다
2~3년 전 ‘AI 코딩 도구’는 사실상 자동완성이었다. 커서가 대중화한 초기 형태도 요청당 모델을 대체로 한두 번 호출해 코드 한 조각을 예측하고, 조립·검증은 사람이 맡았다. 지금의 ‘에이전트’는 실행 단위가 다르다. 요구사항을 받아 관련 파일 여러 개를 스스로 열고, 수정 계획을 세우고, 테스트를 돌려 실패하면 원인을 분석해 다시 고치는 ‘작업 한 건 완수’를 목표로 한다. 한 작업에 모델을 수십 번 호출하는 구조라, 같은 ‘코딩 AI’라는 이름을 써도 자동완성과는 비용·실패양상·검증 방식이 전부 다르다. Z.ai가 GLM-5.2와 Z코드를 내놓으며 ‘커서·클로드 코드와 격돌’이라는 표현이 붙은 것도, 경쟁이 ‘더 나은 자동완성’이 아니라 ‘더 안정적인 작업 완수율’에서 벌어지고 있기 때문이다.
주목할 변화는 경쟁자의 성격이 다양해졌다는 점이다. GLM-5.2가 미국 개발자 시장에서 회자됐다는 보도는, 상위권 모델 간 성능 격차가 좁혀지면서 ‘오픈웨이트·상대적 저비용’ 조합이 미국·서구 폐쇄형 모델의 실질적 대안으로 올라섰음을 시사한다. 다만 여기서 초보자가 가장 자주 걸려 넘어지는 지점이 있다. ‘벤치마크 1등’과 ‘내 코드베이스에서 1등’은 별개라는 것이다. 벤치마크는 정제된 문제셋(대개 파이썬 위주의 격리된 과제) 기준이라, 사내 레거시 자바 코드베이스, 사내 전용 프레임워크, 촘촘한 코드 컨벤션이 얽힌 실무 환경의 완료율을 대변하지 못한다. 검증하려면 벤치마크 표를 읽는 대신, 자사 실제 이슈 티켓 5~10건을 뽑아 후보 도구 2~3개에 같은 작업을 시키고 ①한 번에 통과한 완료율 ②사람이 다시 손댄 diff 비율 ③작업당 토큰·비용, 이 세 숫자를 나란히 비교하는 편이 훨씬 정확하다.
플러그인에서 ‘오케스트레이션 플랫폼’으로
초기 도구가 IDE 안의 보조 기능이었다면, 최근 키워드는 ‘통합 플랫폼’이다. 유아이패스가 여러 코딩 에이전트를 하나로 묶는 통합 플랫폼을 내놓으며 ‘개발자 진입 장벽을 낮췄다’고 강조한 것이 대표적이다. 핵심은 단일 모델·단일 도구에 종속되지 않고 상황에 맞는 에이전트를 골라 조율(오케스트레이션)하겠다는 전략이다. 기업 입장에서 이 방향이 중요한 이유는 명확하다. 특정 벤더에 락인(lock-in)되면 가격 인상·정책 변경·모델 성능 정체에 그대로 노출되지만, 모델을 갈아끼울 수 있는 구조는 협상력과 대안을 남긴다. 모델 세대 교체 주기가 몇 달 단위로 짧아진 지금, 이 유연성의 가치는 계속 커진다.
다만 플랫폼화가 만능은 아니다. 실무 관점에서 세 가지 체크포인트가 남는다. 첫째, ‘어떤 모델을 쓰느냐’보다 ‘어떤 워크플로에 붙느냐’가 성과를 가른다. 코드 생성 자체보다 코드 리뷰·테스트·배포 파이프라인과의 연결 지점이 병목인 경우가 많아, 여기가 정리돼 있지 않으면 더 좋은 모델을 넣어도 체감이 없다. 둘째, 플랫폼은 편의성을 주는 대신 추상화 계층을 하나 더 얹는다. 문제가 터졌을 때 원인이 모델인지, 플랫폼 연동인지, 사내 설정인지 분리하기 어려워지므로 요청·응답 로그와 감사(audit) 기능이 있는지를 도입 전에 확인해야 한다. 셋째, 가장 흔한 함정은 ‘깔면 생산성이 오른다’는 기대다. 에이전트는 팀의 코드 컨벤션·문서·테스트 커버리지를 ‘근거’로 삼아 움직이므로, 이 재료가 부실한 팀에서는 산출물 품질이 오히려 낮아진다. 도구 도입보다 사내 코드베이스 정비가 먼저라는 순서를 놓치는 조직이 많다.
‘전 직원 1인 1에이전트’는 과장인가 현실인가
컴투스가 전 직원에게 ‘AI 에이전트 한 명씩’을 배치하고 AI 게임 기업으로 전환하겠다고 밝힌 소식은 상징적이다. 코딩·자동화 에이전트가 개발팀 전용 도구를 넘어 기획·아트·운영 등 비개발 직군의 일상 업무로 번지고 있다는 신호다. 기반 기술이 결국 ‘반복 작업을 자연어 지시로 자동화’하는 것이라, 대상이 반드시 코드일 필요는 없다는 논리다. 데이터 정리, 보고서 초안, 리서치 요약, 반복 문서 작성 같은 업무로 적용 범위가 자연스럽게 넓어진다.
그러나 ‘1인 1에이전트’가 ‘업무량 절반 감소’를 뜻하지는 않는다. 에이전트는 정형화된 반복 작업에서 효과가 크고, 판단·조율·최종 책임이 걸린 영역에서는 사람 검수를 전제로만 쓸 수 있다. 오히려 도입 초기에는 산출물을 검토·수정하는 시간이 새로 생겨 단기 생산성이 잠깐 꺾이는 J커브 구간이 흔하다. 이 구간을 넘기려면 두 가지가 필요하다. 하나는 막연한 ‘효율화’가 아니라 측정 가능한 성공 지표다. 예컨대 ‘주간 정기 리포트 작성 시간을 4시간에서 2시간으로’처럼 대상 업무·현재값·목표값을 숫자로 못 박아야 도입 효과를 판정할 수 있다. 다른 하나는 실패해도 되는 범위에서 먼저 돌리는 파일럿 설계다. 전사 선언 전에 한두 팀에서 6~8주간 검증해 성공 지표를 확인하고 확산하는 순서가, 도입 실패의 매몰비용을 가장 크게 줄인다.
도입 전 반드시 계산할 비용·보안·책임 리스크
가장 과소평가되는 것이 비용 구조다. 자동완성은 요청당 한두 번 호출로 끝나지만, 에이전트는 파일 읽기→계획→수정→테스트 실행→실패 분석→재수정으로 한 작업에 모델을 수십 번 호출한다. 겉보기 월 구독료가 저렴해도 사용량 기반 과금이 겹치면 청구액은 전혀 다르게 찍힐 수 있다. GLM-5.2 같은 상대적 저비용 대안이 시장에서 주목받는 배경도 이 지점이다. 그래서 계약 단계에서 ①정액인지 종량인지 ②사용 상한(스로틀·예산 한도) 설정이 가능한지 ③좌석당 과금인지 실사용량 과금인지를 명확히 하고, 파일럿에서 실제 토큰·비용 로그를 뽑아 ‘작업 1건당 평균 비용 × 월 예상 작업 수 × 12’로 연간 환산해봐야 한다. 이 계산 없이 좌석 수만 곱하면 예산이 빗나간다.
보안·품질·책임은 세트로 다뤄야 한다. 첫째, 소스코드는 핵심 자산이므로 입력 코드가 모델 학습에 쓰이는지, 얼마나 보존되는지, 학습 제외·전용 인스턴스·온프레미스 옵션이 있는지를 계약 전에 문서로 확인한다. 규제 산업이나 고객 데이터를 다루는 조직은 이 항목 하나가 도입 가능 여부를 좌우한다. 둘째, 에이전트가 생성한 코드의 라이선스·저작권 문제와 보안 취약점 혼입 가능성이다. ‘그럴듯하지만 미묘하게 틀린’ 코드가 리뷰를 통과하면 당장은 동작해도 유지보수 부채로 남는다. 셋째, 책임 소재다. AI가 짠 코드로 장애가 나도 책임은 결국 사람과 조직에 귀속된다. 따라서 ‘에이전트 산출물은 반드시 사람 리뷰를 거친다’는 원칙, 프로덕션 반영 전 승인 절차, 그리고 롤백 계획을 사전에 정해두는 것이 최소 안전장치다. 정리하면 이 기술의 값어치는 ‘좋다/나쁘다’가 아니라, 어떤 업무를 어떤 통제 조건 아래 맡기느냐에서 갈린다.
자주 묻는 질문
커서, 클로드 코드, GLM-5.2 중 무엇을 골라야 하나요?
벤치마크 순위는 정제된 문제셋 기준이라 참고치일 뿐입니다. 사용하는 언어·프레임워크·코드베이스 규모, 사내 컨벤션에 따라 체감 완료율이 크게 달라지기 때문입니다. 실제 이슈 티켓 5~10건을 뽑아 후보 2~3개에 같은 작업을 시키고, 한 번에 통과한 완료율·사람이 다시 손댄 diff 비율·작업당 비용 세 가지를 비교하는 것이 가장 정확한 선택 방법입니다.
AI 코딩 에이전트를 도입하면 개발 생산성이 바로 오르나요?
초기에는 오히려 잠깐 떨어지는 J커브 구간이 흔합니다. 산출물을 검토·수정하는 시간이 새로 추가되기 때문입니다. 또 팀의 코드 컨벤션·문서·테스트가 부실하면 에이전트가 참고할 근거가 부족해 품질이 낮아집니다. 사내 코드베이스 정비와 ‘어떤 업무를 몇 시간에서 몇 시간으로’ 같은 측정 가능한 목표 설정이 선행돼야 효과가 안정적으로 나타납니다.
소스코드가 외부 AI 모델로 유출될 위험은 없나요?
제공사마다 데이터 정책이 다릅니다. 입력 코드가 모델 학습에 쓰이는지, 보존 기간은 얼마인지, 학습 제외·전용 인스턴스·온프레미스 옵션이 있는지를 계약 전에 문서로 확인해야 합니다. 규제 산업이거나 고객 데이터를 다루는 조직이라면 이 항목 하나가 도입 가능 여부를 결정합니다.
비개발자도 코딩 에이전트를 쓸 수 있나요?
통합 플랫폼과 ‘전 직원 1인 1에이전트’ 사례처럼 적용 범위가 넓어지고 있습니다. 기반 기술이 반복 작업의 자연어 자동화라, 코드가 아니어도 데이터 정리·보고서 초안·리서치 요약 같은 업무에 쓰입니다. 다만 판단과 책임이 걸린 업무는 사람 검수를 전제로 하며, 결과를 그대로 신뢰하지 않고 검증하는 습관이 반드시 필요합니다.
구독료가 저렴한데 왜 비용이 예상보다 많이 나올 수 있나요?
에이전트는 한 작업에 파일 읽기·수정·테스트 재시도 등으로 모델을 수십 번 호출해 토큰 사용량이 자동완성과 비교가 안 됩니다. 정액 좌석 요금 외에 사용량 기반 과금이 겹치면 청구액이 크게 불어날 수 있습니다. 요금 체계(정액/종량)와 사용 상한 설정 여부를 확인하고, 파일럿의 실제 로그로 ‘작업당 비용 × 월 작업 수 × 12’를 계산해 연간 예산을 잡길 권합니다.