dog paw / development

AI 코딩은 공짜가 아니다 — 생산성보다 먼저 부딪히는 건 비용이다 본문

개발/AI

AI 코딩은 공짜가 아니다 — 생산성보다 먼저 부딪히는 건 비용이다

goldtagworks 2026. 4. 23. 15:20

AI가 알아서 다 만들어준다는 말은 듣기 좋다. 너무 좋다.
도메인도 이해하고, 코드도 짜고, 테스트도 하고, 나중엔 책임까지 대신 져줄 것처럼 말한다. SNS만 열어도 비슷한 문장이 끝없이 나온다. “혼자서 앱 만들기”, “AI 에이전트가 개발자를 대체한다”, “바이브 코딩으로 MVP를 3일 만에 완성했다.” 썸네일은 더 세다. 지금 안 타면 뒤처질 것처럼 보이게 만든다.

 

그런데 직접 오래 돌려본 사람은 안다.
이 얘기가 왜 이상하게 들리는지.

 

자리를 비우고 돌아오면 멈춰 있다. 승인을 기다리다가.
조금 길게 태워보면 또 다른 이유로 끊긴다. 컨텍스트가 불어나서 느려지거나, 요청 제한에 걸리거나, 토큰을 너무 많이 써서 더는 밀어붙이지 못한다. “알아서 다 해준다”는 말과 실제 사용 경험 사이에 아주 두꺼운 벽이 하나 끼어 있는데, 이상하게 그 얘기는 잘 안 나온다.

 

그 벽의 이름은 성능이 아니다.
비용이다.

 

많은 사람들이 여기서 착각한다. AI가 아직 멍청해서 자율 개발이 안 되는 거라고. 물론 그것도 일부는 맞다. 긴 작업에서 흔들리고, 문맥이 꼬이면 엉뚱한 결론으로 미끄러지고, 조금만 애매한 요구를 던져도 그럴듯한 소설을 쓴다. 그런데 실제로 꾸준히 써보면 더 먼저 부딪히는 건 그게 아니다. “이걸 계속 돌릴 수 있느냐”에서 막힌다. 기술적 한계보다 운영 가능한 비용이 먼저 목을 조른다.

 

클라우드 LLM은 공기가 아니다. 요청 한 번 던지고 끝나는 검색창이 아니라, 읽고 판단하고 쓰고 다시 읽는 모든 과정이 과금 구조 위에 올라가 있다. 프롬프트가 길어질수록, 이전 대화가 누적될수록, 첨부파일이 많아질수록, 중간중간 계획을 세우고 다시 수정할수록 비용은 조용히 쌓인다. 사용자는 채팅창 하나를 보고 있지만, 실제로는 계속 meter가 돈다.

 

구독제는 그래서 더 오해를 부른다. 월정액을 내면 무제한처럼 느껴지니까. 하지만 실제 체감은 전혀 다르다. 일정 시간 이상 고강도로 쓰면 속도가 눈에 띄게 흔들리고, 어떤 플랜은 아예 사용량 상한에 닿았다는 식으로 끊긴다. 이름은 Pro든 Max든 거창한데, 막상 하루 종일 진짜 일처럼 쓰기 시작하면 “생각보다 오래 못 버티네?”라는 말을 하게 된다. 이건 서비스 품질이 나쁘다는 얘기가 아니다. 그냥 현재의 가격과 자원 배분 구조가 그렇다는 뜻이다.

 

이 차이를 말로만 들으면 감이 안 온다.
직접 몇 시간만 몰아서 써보면 바로 온다.

 

예를 들어 문서 한두 장 요약하고, API 레퍼런스 좀 물어보고, 간단한 컴포넌트 몇 개 만드는 정도면 꽤 만족스럽다. “이 정도면 돈값 하네”라는 생각도 든다. 문제는 거기서 한 단계 더 넘어갈 때다. 코드베이스를 길게 읽히고, 파일 여러 개를 오가게 하고, 설계를 바꾸고, 테스트 실패를 다시 고치고, 배포 설정까지 연결하는 순간부터 사용량은 전혀 다른 곡선으로 올라간다. 체감상 생산성은 올라가는데, 동시에 “이걸 매일 이 강도로 써도 되나?”라는 불안도 같이 커진다.

 

개인 사용자에게는 이게 아주 현실적인 장벽이다.
월 몇 만 원도 망설이는 사람이 많다. 이상한 일이 아니다. 커피값은 쉽게 쓰면서 왜 AI 구독료는 아까워하냐고 비웃는 식의 반응을 종종 보는데, 그건 소비 심리를 너무 단순하게 보는 거다. 커피는 마시면 바로 끝난다. 만족이 즉시 온다. 반면 AI 요금제는 “이번 달에 내가 이걸 얼마나 쓸까”, “써도 진짜 체감 이득이 있을까”, “안 쓰는 날엔 그냥 돈이 새는 거 아닌가” 같은 계산이 먼저 들어온다. 게다가 많은 사람은 호기심으로 결제했다가, 며칠 반짝 쓰고, 다시 예전 방식으로 돌아간다. 효용이 없어서가 아니라, 효용이 매달 자동이체를 정당화할 만큼 선명하게 고정되지 않았기 때문이다.

 

더 비싼 플랜으로 가면 얘기는 더 노골적이 된다.
개인이 월 수십만 원을 AI에 쓴다? 이건 벌써 얼리어답터나 업으로 직접 효율을 뽑는 사람 이야기다. 일반적인 직장인, 학생, 주니어 개발자에게는 “그러면 좋겠지”의 영역이지, 너무 자연스러운 기본값은 아니다. 그러니까 AI 자율 개발론을 열심히 말하는 사람이 어떤 요금제와 어떤 사용 환경을 전제로 말하는지 먼저 봐야 한다. 같은 화면을 보고 있어도 출발선이 다르면 결론도 달라진다.

 

여기서 흔히 나오는 말이 있다.
“그럼 회사에서 결제해주면 되잖아.”

 

말은 쉽다. 현실은 그보다 훨씬 복잡하다.

 

회사가 직원 개개인의 AI 요금제를 비용 처리한다는 건, 그 순간부터 그 도구를 공식 업무 체계 안으로 들인다는 뜻이다. 그러면 그냥 “좋아 보이니까 써보세요”로 끝나지 않는다. 질문이 바로 붙는다. 얼마나 빨라지는가. 어디까지 맡길 수 있는가. 코드 품질은 어떻게 검증하는가. 외부 모델에 붙는 데이터는 안전한가. 개인정보, 고객사 정보, 내부 소스코드가 섞이면 어떤 규정으로 통제하는가. 장애가 나면 책임은 누구에게 귀속되는가.

 

문제는 많은 조직이 이 질문에 아직 답을 못 갖고 있다는 점이다.
AI 자체를 몰라서가 아니다. 오히려 너무 빨리 변해서다. 지난 분기엔 괜찮아 보였던 정책이 이번 분기엔 낡고, 특정 서비스 기준으로 짜둔 가이드가 몇 달 지나면 통째로 무의미해진다. 도입을 검토하는 사람 입장에선 보수적으로 갈 수밖에 없다. “생산성 향상 가능성”은 있는데, 보안과 책임 구조는 아직 흐리다. 그러니 일부 팀에서 실험적으로 쓰는 수준을 넘기기가 쉽지 않다.

 

그래서 현실에서는 계층이 갈린다.
회사 카드로 팀 단위 플랜을 끊고 적극적으로 쓰는 곳이 있다. 보통은 빅테크나, AI 도입을 전략적으로 밀어붙이는 스타트업이거나, 의사결정권자가 기술 변화에 민감한 조직이다. 반대로 훨씬 많은 회사에서는 개인이 자비로 쓴다. 아니면 무료 플랜만 건드린다. 아니면 보안 이슈 때문에 아예 못 쓴다. 이 차이가 중요한 이유는, 공개 콘텐츠에서 말하는 “이렇게 하면 된다”가 대개 첫 번째 환경을 전제로 하고 있기 때문이다. 듣는 사람의 대부분은 거기에 없다.

 

그러니 비용 얘기를 빼고 AI 자율 개발을 말하면 자꾸 공중전에 뜬다.
할 수 있냐 없냐가 아니라, 누가 어떤 조건에서 얼마나 지속 가능하게 쓸 수 있냐를 먼저 봐야 한다. 여기서 자꾸 미끄러지니까, 현장에서 느끼는 답답함과 온라인 담론이 어긋난다.

 

그럼 바로 이런 반론이 들어온다.
클라우드가 비싸면 로컬 LLM을 쓰면 되지 않느냐고.

 

이 말도 절반은 맞다.
오픈소스 모델은 최근 1~2년 동안 정말 빠르게 좋아졌다. 예전에는 “장난감은 되겠지만 실전은 무리”에 가까웠다면, 이제는 특정 작업에선 꽤 쓸 만한 수준까지 올라온 모델들이 있다. 추론, 요약, 번역, 제한된 범위의 코드 생성 정도는 환경만 잘 맞추면 기대 이상으로 버틴다. 그래서 로컬 LLM을 미래의 대안으로 보는 시선 자체는 타당하다.

 

문제는 “대안이 존재한다”와 “지금 당장 클라우드 수준을 대체한다”는 전혀 다른 문장이라는 점이다.

 

코딩 에이전트를 제대로 돌린다는 건 단순히 한 번 답변 잘하는 모델을 뜻하지 않는다. 파일을 읽고, 수정하고, 다시 계획을 세우고, 실패 로그를 보고, 앞선 결정을 잊지 않은 채 루프를 몇 번씩 이어갈 수 있어야 한다. 여기서 모델의 절대 성능만 중요한 게 아니다. 긴 컨텍스트 내구성, 도구 호출 안정성, 에이전트 루프에서의 일관성, 추론 속도, 그리고 결정적으로 하드웨어 자원이 같이 묶여 들어온다.

 

이 지점부터 로컬은 갑자기 기술 토론이 아니라 장비 토론이 된다.
메모리가 얼마나 필요한가, 양자화를 어느 수준까지 걸 것인가, 추론 속도를 어느 정도 포기할 것인가, 배치와 컨텍스트를 어떻게 나눌 것인가. 말은 “로컬로 돌리면 된다”인데, 실제로는 꽤 비싼 그래픽카드와, 발열과, 전력과, 세팅 시간을 같이 사는 셈이다. 클라우드 요금을 아끼겠다고 들어갔다가, 다른 종류의 초기 비용과 운영 부담을 맞는 구조다.

 

게다가 이쪽은 사용자가 직접 감당해야 하는 복잡성이 있다.
클라우드 모델은 비싸지만 바로 쓸 수 있다. 로컬은 한 번 세팅되면 편할 수 있지만, 그 한 번이 사람을 지치게 만든다. 드라이버 문제, 라이브러리 호환, 속도 튜닝, 모델 교체, 프롬프트 최적화, 작업별 모델 선택. 익숙한 사람은 재밌어하지만, 대부분의 사람에게는 본업 전에 작은 인프라 팀이 하나 더 생기는 느낌이다. “비용 병목을 피하려고 왔는데 왜 갑자기 내가 하드웨어 운영자처럼 살고 있지?”라는 순간이 온다.

 

그래서 지금 시점의 정직한 답은 이 정도다.
로컬은 가능성 있다. 어떤 작업에선 이미 충분히 쓸 만하다. 하지만 클라우드 최신 모델을 대체하는 범용 코딩 에이전트 경험을 누구에게나 쉽게 주는 단계냐고 물으면, 아직은 아니다. 특히 “AI가 알아서 다 만든다”는 식의 서사를 뒷받침할 만큼 매끈한 기본값은 더더욱 아니다.

 

이쯤 되면 낙관론의 마지막 카드가 나온다.
“지금은 그래도 곧 해결된다.”

 

이 말은 묘하게 강하다.
대개 완전히 틀린 말이 아니기 때문이다. 실제로 모델은 좋아지고 있다. 비용도 긴 호흡으로 보면 내려가는 추세가 맞다. 하드웨어도 언젠가는 더 싸지고 더 강해질 가능성이 크다. 몇 년 전만 해도 말도 안 되던 게 지금은 꽤 자연스러운 기능이 된 사례도 많다. 그러니 방향성만 놓고 보면, 낙관론자들이 허무맹랑한 소리만 하는 건 아니다.

 

그런데 이상한 건 따로 있다.
이 문장이 너무 오래 같은 형태로 반복된다는 점이다.

 

2년 전에도 “곧 된다”였다.
작년에도 “조금만 더 가면 된다”였다.
지금도 “방향은 맞으니 곧 해결된다”다.

 

계속 맞는 말처럼 들리는데, 이상하게도 항상 현재형의 문제는 다음 시점으로 이월된다. 비용은 조금 더 내려가면 해결될 것이고, 성능은 다음 모델이면 해결될 것이고, 자율성은 다음 에이전트 프레임워크면 해결될 것이라고 말한다. 듣는 입장에서는 늘 문턱 앞에 서 있는 것처럼 느껴지지만, 막상 걸어가 보면 문턱이 같이 이동한다.

 

이건 기술 발전이 없다는 얘기가 아니다.
발전은 분명히 있다. 다만 “발전이 있다”와 “그래서 지금 당장 당신의 워크플로우를 전면적으로 갈아엎어도 된다”는 다른 주장이라는 뜻이다. 바로 이 틈에서 문제가 생긴다. 아직 도착하지 않은 미래를 근거로, 현재의 행동 변경을 너무 강하게 요구할 때다.

 

실무자는 여기서 보수적일 수밖에 없다.
새 도구를 배우고, 프롬프트 패턴을 익히고, IDE 플러그인을 갈아끼우고, 리뷰 프로세스를 바꾸고, 문서 문화까지 다시 짜는 건 생각보다 큰 일이다. 팀 전체 워크플로우를 건드리는 일은 더 크다. 그런데 그 기반 논리가 “언젠가 좋아질 테니 지금 전면 도입하자”라면, 이건 기술 전략이라기보다 신념에 가깝다. 미래에 대한 베팅은 할 수 있다. 하지만 베팅을 하는 쪽은 언제나 비용을 먼저 낸다.

 

그래서 AI 자율 개발론을 말하는 콘텐츠를 보다 보면 자꾸 묘한 기시감이 든다.
현재의 솔루션을 파는 게 아니라, 미래의 기대치를 팔고 있다는 느낌.

 

문장 구조는 대체로 비슷하다.
AI는 빠르게 발전하고 있다. 곧 많은 작업을 대체할 것이다. 그러니 지금 들어와야 한다. 지금 배우지 않으면 늦는다. 이 말을 들으면 불안해진다. 그리고 그 불안을 해결하기 위해 강의를 사고, 커뮤니티에 들어가고, 툴 체인을 구독하게 된다. 미래가 실제로 어떤 형태로 오든, 수익 구조는 현재에 이미 완성된다.

 

물론 이게 전부 사기라는 얘기는 아니다.
앞서가는 사람들이 트렌드를 과장 섞어 설명하는 건 늘 있어 왔다. 생태계가 커지는 과정에서 그런 사람들도 역할을 한다. 문제는 소비자가 그걸 현실 조언으로 받아들이느냐, 전망성 마케팅으로 걸러 듣느냐에 있다. 둘은 겉으로 보면 비슷한데, 비용 얘기를 꺼내는 순간 확 갈린다.

 

정말 실전에서 굴려본 사람은 비용 얘기를 피하지 못한다.
토큰 제한, 플랜 상한, 장시간 작업에서의 끊김, 팀 결제 승인 난이도, 로컬 장비 비용, 세팅 피로도 같은 얘기가 자연스럽게 나온다. 반대로 이런 질문에 구체적 숫자나 사용 시나리오 대신 “그건 곧 해결될 문제예요”로만 넘어가면, 그 사람은 대개 현실 솔루션보다 기대감 자체를 더 많이 팔고 있는 것이다.

 

내가 보기엔 여기서 한 번 선을 그어야 한다.
AI는 유용하다. 지금도 충분히 유용하다. 이건 의심할 필요가 없다. 반복 작업을 줄여주고, 처음 보는 라이브러리 문서를 빠르게 읽게 해주고, 테스트 케이스 초안을 만들어주고, 보일러플레이트를 덜 치게 해준다. 일정 수준 이하의 탐색 비용을 크게 깎아주는 것도 사실이다. 예전 같으면 한 시간 걸렸을 삽질이 10분 만에 끝나는 순간도 자주 나온다.

 

그런데 그 유용함의 성격을 과장하면 곤란해진다.
지금의 AI 코딩 도구는 만능 자동 개발자가 아니라, 아주 강력한 보조 도구에 가깝다. 좋은 페어 프로그래머 같을 때도 있고, 속도 빠른 인턴 같을 때도 있고, 지치지 않는 문서 검색기 같을 때도 있다. 하지만 중요한 판단을 스스로 책임지는 주체는 아니다. 컨텍스트가 길어지면 흔들리고, 요구가 애매하면 자신감 있게 틀리고, 결과물에 대한 책임은 언제나 사람에게 되돌아온다.

 

이 책임 문제를 빼고 얘기하면 더 위험하다.
프로덕션에서 장애가 났을 때 “이건 AI가 짠 코드라서요”라고 말한다고 책임이 사라지지 않는다. 고객에게 장애 공지가 나갈 때도, 회고 문서가 작성될 때도, 승인 체계를 통과시킨 사람과 배포 버튼을 누른 사람이 남는다. 법적 책임이든 조직적 책임이든, 지금의 시스템은 AI를 책임 주체로 다루지 않는다. AI가 실수했다는 서술은 가능하지만, AI에게 책임을 물을 제도는 없다.

 

결국 지금 우리가 써야 할 문장은 이것에 더 가깝다.
AI는 일을 덜어준다. 하지만 대신 살아주지는 않는다.

 

이 차이를 흐리면 사용자는 이상한 자책을 하게 된다.
길게 못 돌리는 건 내가 프롬프트를 못 써서 그런가. 요금제가 버티지 못하는 건 내가 활용법을 몰라서 그런가. 로컬 세팅이 너무 복잡한 건 내가 기술력이 부족해서 그런가. 꼭 그렇지만은 않다. 꽤 많은 경우, 그건 개인 역량의 문제가 아니라 현재 비용 구조와 도구 성숙도의 문제다. 구조적인 병목을 개인의 무능처럼 받아들이기 시작하면, 그다음부터는 현실 판단이 흐려진다.

 

나는 그래서 “AI가 만능이 아니다”라는 식의 뻔한 결론을 말하고 싶은 게 아니다.
그 말은 너무 쉬워서 별 의미가 없다. 더 중요한 건, 지금 사실인 것과 나중에 사실이 될 수도 있는 것을 구분하는 일이다.

 

AI가 언젠가 더 싸고, 더 길게, 더 안정적으로 돌아갈 수는 있다.
로컬 모델이 더 좋아져서 클라우드 의존도를 크게 낮출 수도 있다. 자율 에이전트가 훨씬 믿을 만해질 수도 있다. 다 가능하다. 그런데 그 가능성을 현재 완료형으로 말하기 시작하는 순간, 현실 감각이 무너진다. 사용자는 지금의 병목을 설명받는 대신, 미래의 홍보 문구를 듣게 된다.

 

그러니 비용 병목 앞에서 자꾸 막히는 경험을 너무 쉽게 자기 탓으로 돌리지 않았으면 한다.
그건 당신이 뒤처져서가 아니라, 아직 구조가 거기까지 안 왔기 때문일 수 있다. 지금 AI를 제대로 써보려는 사람이라면 오히려 이 벽을 빨리 보는 게 정상이다. 계속 돌리고 싶어도 못 돌리고, 더 맡기고 싶어도 제한에 걸리고, 효율은 느끼는데 지속 가능성은 애매한 그 모순. 바로 거기에 지금 시점의 진실이 있다.

 

“언젠가”를 파는 사람의 말은 아마 완전히 틀리진 않을 것이다.
문제는 그 언젠가가 오늘 회의에서, 이번 분기 예산에서, 이번 배포 사고에서, 당신 대신 답해주지 않는다는 데 있다.