GitHub Copilot이 등장했을 때, "코드 보완이 여기까지 왔는가"라며 놀란 엔지니어가 많았을 것이다. 그로부터 수년이 지난 지금, 이제는 Claude Code나 OpenAI Codex와 같은 에이전트형 AI가 리포지토리(Repository) 전체를 분석하여 코드를 수정하고, 테스트를 실행하며, 에러를 조사하여 차이점(Diff)까지 설명해 주는 시대가 되었다.

AI 주도 개발(AI-Driven Development)은 이제 일부 선진적인 팀만의 이야기가 아니라, 개발 현장의 표준이 되어가고 있다.

하지만 이 시점에서 눈에 보이는 과제가 있다.

"AI를 어떻게 사용할 것인가"의 다음에, "AI를 어떻게 관리할 것인가"가 질문되기 시작했다.

클라우드 컴퓨팅(Cloud Computing)이 보급되었을 때 다음 과제가 비용 관리였던 것처럼, AI 활용의 확산 또한 같은 길을 걷게 될지도 모른다. 본 기사에서는 AI FinOps라는 개념을 축으로, 향후 엔지니어와 기업에 요구되는 관점을 정리해 보고자 한다.

2021년에 GitHub Copilot이 퍼블릭 베타(Public Beta)를 시작했을 때, 그 충격은 "코드가 자동으로 보완된다"는 놀라움에 집약되어 있었다. 함수명을 쓰기 시작하면 구현 내용이 나오고, 주석을 쓰면 코드가 된다. 단순한 메커니즘이었지만, 개발 경험을 근본적으로 바꾸는 임팩트가 있었다.

당시의 사용 방식은 어디까지나 "보완"이었다. 엔지니어가 작성하는 코드의 연장선상에 AI가 들어가는 형태로, 주도권은 인간에게 있었다.

그로부터 수년 만에 상황은 크게 변했다.

Claude Code, OpenAI Codex, Cursor 등의 도구는 단순한 보완을 넘어 에이전트(Agent)로서 동작하게 되었다. 구체적으로 무엇을 할 수 있게 되었는가 하면,

• 리포지토리 전체를 분석하여 구조를 파악한다
• 여러 파일에 걸친 수정을 일괄적으로 수행한다
• 테스트를 자동 실행하고, 실패한 케이스를 스스로 조사한다
• 에러 로그를 읽고 원인과 수정안을 제시한다
• 풀 리퀘스트(Pull Request)의 차이점을 자연어로 설명한다

등의 작업을 인간의 세세한 지시 없이도 해낼 수 있게 되었다.

기존의 AI 코딩 지원
엔지니어가 코드를 작성함 → AI가 다음 줄을 보완함
현재의 AI 에이전트
...

이러한 변화는 질적인 변화다. AI가 "보완하는 존재"에서 "태스크(Task)를 실행하는 존재"로 바뀌었다.

에이전트형 AI의 등장으로 변한 것은 AI와의 인터랙션(Interaction) 단위다. 이전에는 "1행·1함수" 단위로 AI와 대화했지만, 지금은 "1태스크·1기능" 단위로 맡길 수 있다.

이 변화는 생산성 향상이라는 측면에서는 환영할 만한 일이지만, 동시에 새로운 과제의 입구이기도 하다.

GitHub Copilot은 월정액 고정 요금 모델로 보급되었다. "한 달에 얼마를 내면 언제든 사용할 수 있다"는 심플한 체계는 엔지니어에게 사용하기 편했다.

하지만 에이전트형 AI가 보급됨에 따라, 이 모델로는 성립하기 어려워졌다.

이유는 간단하다. **"가볍게 사용하는 사용자"와 "헤비하게 사용하는 사용자"의 비용 차이가 보완 도구 시대와는 비교할 수 없을 정도로 커졌기" 때문이다.

LLM(Large Language Model)은 텍스트(코드 포함)를 토큰(Token)이라는 단위로 처리한다. 보완 도구로 사용할 경우, 1회 처리 시 소비되는 토큰량은 그리 많지 않다.

하지만 에이전트형 AI는 이야기가 다르다.

에이전트가 1태스크를 처리할 때의 토큰 소비 이미지
리포지토리 분석(여러 파일 읽기) → 대량의 토큰 소비
코드 수정안 생성 → 토큰 소비
...

한 달에 수백 개의 태스크를 AI 에이전트에게 맡기면 소비되는 토큰량은 방대해진다. 동일한 "월정액"으로 모든 사용자를 감당하는 것은 서비스 제공 측면에서 현실적이지 않게 되었다.

클라우드 컴퓨팅이 보급된 과정을 되돌아보면, 지금의 AI 이용과 구조가 닮아 있다는 것을 깨닫게 된다.

【클라우드의 발자취】
온프레미스(On-premise) (초기 비용·고정 비용)
↓
...

클라우드의 경우, "일단 EC2를 마구 생성하던" 시대가 끝나고, "비용을 가시화하여 최적화하는" 페이즈(Phase)로 이행했다. 그 과정에서 FinOps(Financial Operations)라는 개념과 역할이 탄생했다.

AI도 같은 길을 걸을 가능성이 높다.

AWS를 다룰 줄 아는 것만으로는 부족해졌고, 비용까지 설계할 수 있는 엔지니어가 요구되기 시작했다. AI도 같은 흐름에 진입하고 있다고 느낀다.

AI FinOps란 AI 이용 비용을 가시화(Visualization)·관리(Management)·최적화(Optimization)하기 위한 실천적인 접근 방식이다. 아직 확립된 프레임워크가 있는 것은 아니지만, 클라우드 FinOps의 사고방식을 AI에 적용한 것으로 정리할 수 있다.

구체적으로 다루는 관점은 다음과 같다.

가시화 (Visualization)

• 팀이나 개인별 AI 이용량을 파악한다
• 어떤 태스크에서 얼마나 많은 토큰을 소비하고 있는지 확인한다
• 비용 발생원을 특정한다

관리 (Management)

• 이용 한도(Quota)를 설정하여 비용의 급격한 상승을 방지한다
• 사용하지 않는 AI 기능 및 연동 사항을 점검(Inventory)한다
• 청구 데이터를 정기적으로 리뷰한다

최적화 (Optimization)

• 태스크의 복잡도에 따라 모델을 구분하여 사용한다 (GPT-4o가 필요한지, 경량 모델로 충분한지 등)
• 프롬프트(Prompt) 효율화를 통해 토큰 소비를 줄인다
• 에이전트(Agent)의 실행 범위를 필요 최소한으로 좁힌다

ROI 측정

• AI에 투입한 비용 대비 개발 생산성이 얼마나 향상되었는지 정량화한다
• 비용에 맞지 않는 사용 방식을 특정하여 재검토한다

여기서 강조하고 싶은 점은, AI FinOps의 목적이 AI 이용을 제한하는 것이 아니라는 점이다.

"비용이 많이 드니까 AI를 쓰지 말자"라는 판단은 현실적이지 않다. AI가 개발 생산성에 주는 플러스(+) 영향을 고려하면, AI 없는 개발로 돌아가는 일은 거의 없을 것이다.

잘못된 접근: 비용을 이유로 AI 이용을 금지 또는 제한함
↓
올바른 접근: 최적의 장소에서, 최적의 AI를, 최적의 비용으로 사용함

지향해야 할 점은 "AI를 어디서 사용할 것인가"를 전략적으로 판단하는 것이다. 단순 반복 작업에는 비용이 낮은 경량 모델을 사용하고, 복잡한 설계나 판단이 필요한 장면에는 고정밀 모델을 사용한다. 이러한 모델 선택의 판단 기준이 엔지니어에게도 요구될 것이다.

엔지니어에게 요구되는 스킬셋(Skillset)은 기술의 변화와 함께 변해왔다.

【엔지니어에게 요구되는 스킬의 변천】
~2010년대 초반
서버 구축·운영이 가능함
...

과거에는 AWS를 다룰 줄 아는 것만으로도 희소 가치가 있었다. 지금은 AWS를 다루는 것은 전제 조건이며, 비용 설계와 아키텍처 최적화까지 생각할 수 있는 엔지니어가 요구된다.

AI도 같은 변화를 겪을 가능성이 높다. 지금은 "AI를 사용할 줄 아는 것"에 가치가 있지만, 그것이 당연해진 이후에는 "AI의 비용과 생산성을 양립할 수 있는 것"이 차별화 요소가 될지도 모른다.

당장 모든 것에 대응할 필요는 없지만, 다음과 같은 관점을 조금씩 의식하기 시작하는 것에는 의미가 있다고 생각한다.

이용 상황을 파악하는 습관

자신의 AI 이용이 어느 정도의 비용을 발생시키고 있는지 의식해 본 적이 있는가? 여기서부터 시작된다.

모델 선택의 판단 기준 갖기

"일단 가장 똑똑한 모델을 쓰자"가 아니라, 태스크의 성격에 따라 모델을 선택할 수 있게 되면 비용과 정밀도의 균형을 잡기 쉬워진다.

프롬프트 설계의 효율화

불필요하게 긴 컨텍스트(Context)를 전달하고 있지는 않은지, 같은 정보를 반복해서 전달하고 있지는 않은지. 프롬프트 설계는 토큰 소비와 직결된다.

생산성과의 대비로 생각하기

AI에 들인 비용으로 얼마나 많은 개발 시간을 절감했는가. 감각이 아니라 가능한 범위 내에서 숫자로 파악하려는 의식을 갖는다.

여기서부터는 개인적인 의견으로 읽어주길 바란다.

AI 코딩 지원 도구는 이제 "사용할 것인가 말 것인가"의 선택지가 아니게 되어가고 있다. 설계서 작성, 테스트 설계, 코드 리뷰 보조 등 AI가 관여함으로써 명확하게 효율이 올라가는 공정들이 존재한다. AI를 사용하지 않는 선택은 경쟁력 측면에서 현실적이지 않게 되었다.

에이전트형 AI의 보급에 따라 조직 차원의 AI 비용은 무시할 수 없는 규모가 될 것이다. 지금은 "편리하니까 사용한다"는 페이즈(Phase)지만, 머지않아 "비용 대비 효과를 보며 사용한다"는 페이즈로 이행할 것이다. 클라우드가 그러했던 것처럼.

이는 아직 가설이지만, AI FinOps라는 개념은 향후 중요성을 더할 것이라고 생각한다. 클라우드 FinOps가 독립된 역할(Role)이나 전문성으로 확립되었듯이, AI 이용의 관리·최적화를 담당하는 인재나 프랙티스(Practice)가 생겨나지 않을까.

기업 규모가 커질수록 AI 비용은 무시할 수 없는 예산 항목이 된다. 그 관리를 누가 어떻게 담당할 것인가라는 질문은 이미 시작되었다고도 할 수 있다.

「비용이 많이 드니까 사용하지 않는다」라는 판단은 잘못되었다고 생각한다. AI가 만들어내는 생산성 향상의 가치는 적절하게 사용한다면 비용을 상회한다. 문제는 AI 자체가 아니라, 최적화되지 않은 사용 방식이다.

무엇에 사용할 것인가, 어떤 모델을 사용할 것인가, 어떻게 측정할 것인가. 이러한 질문들과 마주하는 것이 AI 활용의 다음 단계라고 느낀다.

본 기사에서 정리해 온 내용을 되짚어 본다.

• AI 코딩 지원은 보완 도구(Complementary tool)에서 에이전트(Agent)로 진화하며, 처리의 복잡도와 양이 격단히 증가했다
• 이에 따라 종량제 모델(Pay-as-you-go model)로의 이행이 진행되고 있다
• 클라우드가 FinOps라는 개념을 탄생시킨 것처럼, AI도 이용 비용의 관리 및 최적화가 과제가 된다
• AI FinOps는 「금지」가 아니라 「최적화」를 목적으로 하는 사고방식이다
• 향후 엔지니어에게는 AI를 능숙하게 다루는 것뿐만 아니라, 비용과 생산성을 양립시키는 관점이 요구될지도 모른다

AI의 진화는 빠르다. 사용 방식이 바뀔 때마다 그에 따른 과제도 변한다. 코드 생성 다음에 비용 관리가 온다면, 이를 위한 사고방식을 미리 갖춰두는 것은 결코 손해가 아닐 것이다.

당신의 팀이나 조직에서는 AI 비용에 대해 누군가가 고민하고 있습니까?

「사용할 수 있음」이 당연해진 너머에, 다음에 질문될 것은 무엇일까요?