Picture this. Thursday morning. The CFO’s assistant just sent you a calendar invite for Q3 AI Infrastructure Spend at 2:00 pm. No agenda. Just that number from last month’s cloud bill, 40 percent above forecast. You have five hours. Do you own the narrative, or does finance own it for you?

Those who escaped that conversation had a governance architecture in place before the bill arrived.

The training budget was the wrong number all along

Training is a project. Inference is a utility. When an AI agent is embedded in a workflow, it runs every time that workflow runs, around the clock, at scale, with no natural stopping point.

Inference workloads are set to overtake training revenue in 2026, with Deloitte Tech Trends 2026 estimating inference will account for two-thirds of all AI compute this year. Public cloud API pricing has fallen nearly 80 percent year over year, yet Gartner places AI spending at $2.52 trillion in 2026. A volume problem, not a unit cost problem. PwC’s 29th Global CEO Survey of 4,454 chief executives finds 56 percent report AI has produced neither increased revenue nor decreased costs; only 12 percent have achieved both. The differentiator is governance architecture, not model choice.

The triple convergence: 3 forces you cannot fight separately

The inference cost crisis would be manageable in isolation. What makes it genuinely difficult is that it arrives simultaneously with two other structural forces, each carrying its own financial and legal consequences.

Convergence #1: The agentic cost amplifier

The FinOps Foundation’s State of FinOps 2026 report, covering 1,192 organizations and $83 billion in cloud spend, finds AI workloads account for 18 percent of cloud spend at AI-forward enterprises, up from 4 percent in 2023. A three-hour recursive loop generates approximately $3,700 in unplanned compute before any guardrail activates; at ten agents simultaneously, $37,000 per incident. Analytics Week’s March 2026 analysis documents an estimated $400 million absorbed annually from recursive loop failures alone. McKinsey’s 2024 Global Survey on the State of AI finds 78 percent of knowledge workers use unsanctioned AI tools, generating inference costs and compliance obligations FinOps teams cannot see.

Convergence #2: The compliance architecture you cannot defer

Article 5 prohibited practices have been enforceable since February 2025, with penalties up to 7 percent of global annual turnover. The Digital Omnibus on AI, approved in committee on March 18, 2026, extends the compliance window for new Annex III high-risk system deployments under Articles 9-15, covering risk management (Article 9), audit logging (Article 12), and human oversight (Article 14), to December 2027. Building that architecture takes 12 to 18 months, and at 3 percent of global annual turnover, the maximum Annex III exposure for a $10 billion enterprise is $300 million. A credit decision through a public cloud endpoint may simultaneously violate GDPR Articles 44-49 (international transfers), Article 22 (automated decisions), and EU AI Act lineage requirements. The US CLOUD Act compounds this: choosing Frankfurt over Virginia does not solve your sovereignty problem if your provider is headquartered on California Avenue.

Convergence #3: The data gravity reversal

AI follows data. When egress costs plus transfer restrictions plus sovereignty exposure exceed owned inference capacity costs, the placement decision has been made for you.

Infrastructure is a placement discipline, not a platform choice

Five questions classify every workload before any platform is selected: Where should this run? How fast must it respond? Who owns its cost and compliance trajectory? What regulations govern where inference can legally execute? And at what volume does owned capacity beat pay-as-you-go cloud?

Ask those five questions, and three tiers emerge naturally. Public cloud for variable, burst and experimental workloads. Private on-premises for predictable high-volume production inference, where owned capacity consistently delivers 4x to 8x lower cost per token on Hopper-generation or later GPU hardware (H100 or equivalent at 75 to 85 percent utilization, GPT-4-class model, production batch sizes above 32). Edge for latency-critical and sovereignty-constrained decisions, where round-trip latency is a disqualifier. Some workloads will stay in the public cloud indefinitely. The goal is to stop letting infrastructure decisions make themselves.

Placement in practice

Those five questions are not theoretical. A single case shows how they play out under real compliance pressure.

One Tier 1 North American financial institution, processing more than 1 million credit decisions per month, saw cloud bills exceed forecast by 3x. A compliance audit identified two exposure points: the CLOUD Act made EU customer data accessible to US law enforcement, and audit logging failed to capture the lineage trail required under Annex III, Point 5(b), of the EU AI Act (AI systems assessing the creditworthiness of natural persons).

Applying the five questions took two hours. At 1.2 million decisions per month, on-premises was the obvious tier (cloud latency 340ms versus 22ms, same GPT-4-class model, both environments). Both compliance exposure points required moving inference to an EU-headquartered private stack. The workload migrated in 83 days. Monthly spend fell from $85,000 to $35,000. CLOUD Act exposure was eliminated. EU AI Act lineage requirements were met. The cost reduction per decision, combining compute, compliance overhead and latency cost, was 59 percent (GPT-4-class model at production batch sizes).

What to put in front of the CFO

The CFO’s question is whether the investment is working, provable in a number that someone is accountable for. The answer is a different denominator: cost per unit of business output. Four numbers: (1) compute cost per decision (the institution above: $0.071 on public cloud, $0.029 on private infrastructure, GPT-4-class model); (2) compliance overhead per decision (audit logging and regulatory evidence management, fixed regardless of tier); (3) latency cost per decision (340ms versus 22ms is measurable in abandoned transactions and SLA penalties); (4) human-equivalent benchmark (if your loaded analyst rate puts a human decision at $1.80 to $3.20, the CFO needs to be shown how to scale it).

Resilience is a cost line, not a design philosophy

In building the cloud outage database at whencloudsfail.opey.org, I have tracked more than 400 enterprise-impacting AI platform incidents since 2023. Duration of disruption correlates more strongly with provider dependency concentration than with incident severity. Claude AI experienced three major incidents in the first two weeks of March 2026, peaking at 4,700 down detector reports. Azure OpenAI logged a confirmed 20-hour degradation across seven regions on March 9 and 10. The difference between those bills is not a resilience philosophy. It is a number. Build resilience into the architecture or pay for it in the incident.

Resilience and governance are the same problem. The architecture question and the ownership question have the same answer.

Stop the organizational blame game

Deloitte’s 2026 State of AI in the Enterprise, across 3,235 senior leaders, finds only 1 in 5 companies has a mature governance model for autonomous AI agents. Three fixes: (1) a cross-functional governance body meeting quarterly, per-decision cost by workload class as its single agenda; (2) a named owner for every inference endpoint accountable for cost and the Article 14 model card; (3) real-time guardrails with automated kill switches. Gartner reports only 44 percent of organizations have adopted financial guardrails for AI.

Leaders who act vs. leaders who react

Gartner’s 2026 CIO Agenda finds 94 percent of CIOs expect major changes within 24 months, yet only 48 percent of digital initiatives meet their targets. Score yourself:

Question	Act	React
Cost per inference call named for top 3 workloads?	Yes	No
Named owner per production AI endpoint?	Yes	No
Cloud DPAs reviewed for EU AI Act data lineage?	Yes	No
Hard budget guardrails auto-stopping agents?	Yes	No
All AI workloads classified by 5-dimension frame?	Yes	No
Per-decision cost with compliance overhead to CFO?	Yes	No
Cross-functional AI governance body (quarterly)?	Yes	No
Shadow AI deployments inventoried across all BUs?	Yes	No

Predominantly NO: the 90-day sprint below is your path forward.

Your 90-day reckoning

Execute these phases sequentially. You cannot move a workload to the correct tier in Phase 3 if you have not classified it in Phase 1.

Phase	Focus	Owner	Deliverable
Days 1-30	Expose the bill	FinOps lead	Inventory all workloads; name a cost owner for each; calculate cost per decision for top 10; audit DPAs for EU AI Act class.
Days 31-60	Wire the guardrails	AI Eng lead	Deploy cost monitoring; set hard budget limits per agent; activate zombie alerts; first governance meeting; present dashboard to CFO.
Days 61-90	Move first workload	CIO	Migrate highest-cost predictable workload; complete EU AI Act gap assessment; brief board on per-decision cost; publish placement policy.

The competitive consequence of waiting

McKinsey’s Global Tech Agenda 2026, surveying 632 business leaders, finds that nearly two-thirds of top performers have technology leaders deeply involved in enterprise strategy, compared with 52 percent at others. PwC’s AI Vanguard, the 12 percent achieving both revenue and cost gains, carries nearly four percentage points higher profit margins. The separation is governance architecture, not model choice. The CIOs who navigate this most effectively are not managing AI as a technology initiative. They are managing it as a financial and regulatory obligation. The CIO who built this architecture before Thursday’s meeting does not dread that calendar invite. They sent it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Citius, Altius, Fortius. More than a slogan, “Faster, Higher, Stronger Together” is a phrase etched in the minds of many IT decision-makers. Technology is essential. Nobody wants to fall behind. Doing so could mean losing out on many advantages and, consequently, significant business.

Therefore, it’s not surprising that Gartner forecasts global IT spending to reach $6.31 trillion this year, a 13.5% increase compared to 2025 — and nearly 3% more than Gartner forecasted in February, at 10.8% growth.

A sustained push in AI infrastructure, software, and IaaS is key to this growth, according to the research firm. “These shifts are reinforcing a multi‑speed IT market, with hyperscaler purchases and AI‑centric software segments significantly outperforming more traditional categories,” Gartner reported in a statement.

John-David Lovelock, analyst and distinguished vice president at Gartner, underscored that accelerated momentum in AI infrastructure and advanced memory played a significant role in the firm’s growth revision.

“As AI workloads scale, data center investment is ramping rapidly, which in turn is driving increased demand for high‑performance compute,” Lovelock said in the statement. “This dynamic is creating meaningful growth opportunities for companies delivering AI‑optimized processors, accelerators, and enabling technologies.”

What will grow the most? Spending on data center systems, at 55.8%, to exceed $787 million in 2026.

Supply constraints and strong demand have also resulted in record price increases for high-bandwidth memory, according to Lovelock, as hyperscaler demand drives sharp increases in investments in servers. “These trends collectively make AI infrastructure the most attractive segment for capitalizing on the robust expansion in IT spending,” he said.

Those same higher memory prices are impacting device replacement cycles, according to the firm. Device spending is growing, to be sure, but at a lower rate (8.2%) than the IT sector overall.

“Together, these dynamics highlight a widening divergence across IT markets, as AI infrastructure and GenAI software see substantial upward revisions while device growth reflects ongoing cost and pricing pressures,” Lovelock noted.

수십 년 동안 기업 기술은 비교적 익숙한 발전 경로를 따라왔다. 새로운 기술은 처음에는 일부 고급 사용자만 활용하는 전문 도구로 등장했고, 전담 팀이 관리하며 특정 부서 예산으로 운영됐다. 이후 기술이 가치를 입증하면 점진적으로 위상이 높아졌다. 먼저 공용 서비스로 확장되고, 이후 핵심 기술 스택에 편입되며, 최종적으로는 조직 운영 전반에 스며드는 구조로 자리 잡았다. 데이터베이스, 네트워크, 클라우드 컴퓨팅이 모두 이러한 흐름을 거쳤다.

인공지능은 이러한 여정을 기존 기술 대비 약 4분의 1 수준의 시간 만에 완료했다.

이제 근거는 더 이상 이론에 머물지 않는다. 다양한 산업에서 AI는 파일럿 프로젝트 단계를 넘어 실제 운영 의존 단계로 이동했다. 금융 서비스 기업은 불과 3년 전까지만 해도 연구 수준으로 여겨졌던 모델을 활용해 신용 평가와 사기 탐지를 수행하고 있다. 제조업은 AI를 활용해 생산 일정을 실시간으로 최적화하고 있으며, 의료 시스템은 임상 워크플로우에서 AI 기반 진단 지원에 의존하고 있다. 유통 기업 역시 수요 예측, 가격 책정, 고객 경험 전반에 AI를 동시에 적용하고 있다.

이러한 변화는 CIO와 기술 리더에게 분명하면서도 동시에 무거운 과제를 던진다. AI는 더 이상 CRM이나 ERP와 같은 소프트웨어로 분류해 평가하고 관리할 대상이 아니다. AI는 인프라다. 이를 여전히 기존 소프트웨어처럼 취급하는 조직은 범주 자체를 잘못 설정하는 오류를 범하고 있으며, 그 영향은 시간이 지날수록 누적된다.

인프라의 기준점

인프라와 소프트웨어를 구분하는 기준은 무엇인가. 이는 단순한 용어상의 차이가 아니다. 인프라는 조직 운영을 지탱하는 핵심 기반이다. 다른 모든 기능이 그 위에 구축되는 토대이기도 하다. 인프라는 단순히 투자 대비 수익(ROI)으로 평가하지 않는다. 안정성, 복원력, 그리고 전략적 선택 가능성을 기준으로 판단한다. 예를 들어 네트워크가 중단되면 투자 가치 여부를 따지는 것이 아니라 즉시 서비스를 복구한다. 모든 시스템이 그 위에 의존하기 때문이다.

AI는 점점 더 많은 기업에서 이미 이러한 인프라 기준을 넘어섰다. AI는 이제 고객 접점 프로세스, 내부 운영, 컴플라이언스 워크플로우, 경쟁 전략에 동시에 내재화돼 있다. 따라서 AI 시스템이 성능 저하를 일으키거나 장애가 발생하면 특정 팀의 불편에 그치지 않는다. 이는 곧 조직 전체의 운영 이슈로 이어진다.

이 변화는 기술 리더의 의사결정 방식에도 실질적인 영향을 미친다. 인프라 관련 결정은 연간 예산 사이클에서 단기적으로 내려지는 것이 아니라, 장기적인 관점에서 전략적으로 이루어진다. 이 과정에서는 이중화와 리스크 관리가 핵심 요소로 고려된다. 또한 인프라는 단순한 사용 정책이 아니라 체계적인 거버넌스를 필요로 한다. 기능 확장뿐 아니라 복원력 확보를 위한 투자도 요구된다. 더 나아가 IT 부서가 아닌 이사회 차원의 책임 체계까지 필요하다.

그러나 많은 조직은 아직 이러한 수준에 도달하지 못했다. 최근 기업 기술 리더를 대상으로 한 조사에 따르면, 상당수 조직이 여전히 AI 비용을 소프트웨어나 연구개발(R&D) 예산으로 분류하고 있다. 또한 전담 거버넌스 조직 대신 임시 협의체 형태로 AI를 관리하고 있으며, 모델 드리프트, 벤더 종속성, 데이터 출처 등 AI 리스크에 대한 명확한 관리 체계도 부족한 상황이다. 이는 핵심 시스템을 이미 클라우드에서 운영하면서도 이를 부서 단위 실험으로 취급하는 것과 다르지 않다.

거버넌스 격차가 진짜 위험

AI 거버넌스의 성숙도 격차는 기술 자체의 문제가 아니다. 모델도 존재하고, 플랫폼도 갖춰져 있으며, 활용 사례 역시 충분히 축적돼 있다. 문제는 조직에 있다. 기술 발전 속도에 맞춰 거버넌스와 운영 모델을 업데이트하지 못한 것이 핵심이다.

효과적인 AI 거버넌스를 위해 필요한 요소를 보면 그 이유가 분명해진다. 가장 먼저 필요한 것은 가시성이다. 어떤 AI 시스템이 실제 운영되고 있는지, 누가 이를 책임지고 있는지, 어떤 데이터를 활용하는지, 그리고 어떤 의사결정에 영향을 미치는지를 파악해야 한다. 그러나 이를 제대로 관리하는 기업은 많지 않다. 특히 공식 IT 통제 밖에서 운영되는 ‘섀도우 AI’가 빠르게 확산되고 있다. 직원들이 소비자용 AI 도구를 활용해 민감 데이터를 처리하고, 고객 커뮤니케이션을 생성하며, 비즈니스 의사결정에 활용하는 사례가 늘고 있지만, 조직 차원에서는 이를 인지하지 못하는 경우가 많다.

가시성을 넘어, 거버넌스에는 명확한 책임 구조가 필요하다. AI 시스템이 차별적인 결과를 생성했을 때 누가 책임지는지, 어떤 기준으로 모델을 운영 환경에 배포하는지, 성능 변화는 누가 모니터링하는지에 대한 명확한 답이 있어야 한다. 이러한 문제는 단순한 벤더 계약이나 사용 정책으로 해결되지 않는다. 역할 정의, 보고 체계, 감사 기능을 포함한 체계적인 관리 구조가 필요하며, 이는 재무 통제나 데이터 보안과 동일한 수준의 엄격함을 요구한다.

규제 산업에서는 이러한 요구가 이미 구체화되고 있다. 유럽연합의 AI 법안(EU AI Act), 미국 증권거래위원회(SEC)의 알고리즘 의사결정 관련 지침, 그리고 금융 및 의료 규제 기관의 산업별 프레임워크는 모두 같은 방향으로 나아가고 있다. 즉, 중요한 의사결정에 영향을 미치는 AI 시스템에 대해 문서화, 위험 분류, 책임 구조를 의무화하는 것이다. 이러한 규제 대응을 위해서는 프로젝트 단위가 아닌 인프라 수준의 거버넌스가 필요하다.

구축 vs 구매, 전략이 바뀌었다

기술 리더가 직면한 전략적 질문도 달라지고 있다. 지난 10여 년 동안 기업의 주요 AI 전략은 기존 소프트웨어 플랫폼에 포함된 기능을 구매하는 방식이 중심이었다. 예를 들어 예측 모듈이나 추천 엔진을 도입하고, 일부 차별화된 영역에서만 맞춤형 솔루션을 구축하는 형태였다. 그러나 파운데이션 모델 시대가 도래하면서 이러한 접근 방식은 근본적으로 재편됐다.

대형 언어 모델과 멀티모달 파운데이션 모델은 AI 네이티브 역량을 구축하는 비용을 크게 낮췄다. 이제 핵심 질문은 AI를 사용할 것인가가 아니라, 조직 전략에 부합하면서도 지속 가능하고 경쟁력을 갖춘 AI 아키텍처를 어떻게 설계할 것인가로 바뀌었다. 이는 어떤 파운데이션 모델을 선택할지, 파인튜닝과 맞춤화를 어떻게 운영할지, 독점 데이터로 어떻게 장기적인 경쟁 우위를 확보할지, 그리고 여전히 재편 중인 시장에서 벤더 종속을 어떻게 피할지에 대한 의사결정을 포함한다.

이러한 결정은 단순한 도입이 아니라 인프라 아키텍처에 해당한다. 클라우드 아키텍처, 데이터 플랫폼 설계, 네트워크 구조를 결정할 때와 동일한 수준의 엄격함이 요구된다. 이들 결정은 수년에 걸친 영향을 미치고, 전환 비용이 크며, 다른 시스템과 깊이 연결돼 있다. 기능이나 사용자당 가격에 초점을 맞춘 구매 관점으로 접근하는 CIO는 충분한 전략적 고려 없이 내려진 결정으로 인해 향후 제약에 직면할 가능성이 크다.

전환은 어떻게 이뤄지고 있나

AI를 인프라로 다루는 것은 단일 프로젝트가 아니다. 이는 예산, 거버넌스, 인재, 벤더 전략 전반을 동시에 변화시키는 운영 모델의 전환이다. 이러한 변화를 성공적으로 수행한 조직은 몇 가지 공통된 특징을 보인다.

첫째, AI 투자를 프로젝트 예산에서 분리해 자본 및 운영 인프라 예산으로 전환했다. 이는 단순한 회계상의 변화가 아니라 장기적이고 지속적인 투자 의지를 조직 내에 명확히 반영하는 신호다.

둘째, 명확한 책임 구조를 갖춘 전담 AI 거버넌스 조직을 구축했다. 이 조직은 기술, 법무, 리스크, 사업 부문이 교차하는 위치에 자리하며, 분기별 회의에 그치는 위원회가 아니라 모델 관리, 운영 모니터링, 기준 준수를 실시간으로 수행하는 실행 조직이다.

셋째, AI 시스템의 안정성과 최신성을 유지하기 위한 데이터 인프라와 MLOps에 대한 투자를 강화했다. 모델 성능은 시간이 지나면서 저하되고, 데이터 분포는 변화하며, 규제 요구도 계속 추가된다. 따라서 데이터 파이프라인, 모니터링 시스템, 재학습 프로세스에 대한 지속적인 투자가 필요하다. 이는 다른 기업 인프라와 마찬가지로 패치, 업데이트, 용량 관리가 지속적으로 이뤄져야 하는 것과 같은 맥락이다.

넷째, 장기적으로 올바른 AI 아키텍처 결정을 내리기 위한 조직 내 지식을 축적하기 시작했다. 이는 데이터 과학자와 머신러닝 엔지니어 채용에 그치지 않고, 기술 리더십과 사업 부서, 이사회 전반에 걸쳐 AI 이해도를 높이는 것을 의미한다. 충분한 도메인 지식 없이 내려진 인프라 결정은 기술 부채로 이어지며, AI 역시 동일한 결과를 초래할 수 있다.

지금이 결정적 시점

과거 클라우드 전환 초기, 경쟁사보다 먼저 견고한 인프라를 구축하고 클라우드 네이티브 역량을 확보한 기업은 수년간 지속되는 경쟁 우위를 확보했다. 클라우드 리더와 후발주자 간 격차는 한 번 벌어지면 쉽게 좁혀지지 않았다. 인프라는 누적 효과를 갖기 때문이다. 더 나은 인프라는 더 뛰어난 역량을 만들고, 이는 더 우수한 인재를 끌어들이며, 다시 더 나은 인프라로 이어진다.

AI 역시 동일한 흐름을 따르고 있으며, 전략적으로 대응할 수 있는 시간은 점점 줄어들고 있다. 현재 AI를 인프라로 인식하고 거버넌스, 아키텍처, 인재, 운영 체계에 투자하는 조직은 향후 모방하기 어려운 경쟁력을 구축하고 있다. 반면 AI를 여전히 프로젝트 단위로 평가하는 소프트웨어 도구 집합으로 보는 조직은 단순히 뒤처지는 것이 아니라, 점점 회복이 어려운 격차에 놓이게 된다.

CIO에게 주어진 과제는 명확하다. AI가 인프라 수준의 투자와 거버넌스를 필요로 하는지 여부는 더 이상 논쟁의 대상이 아니다. 이미 많은 조직에서 그렇다. 중요한 것은 조직의 운영 모델, 거버넌스 구조, 전략 수립 방식이 이러한 현실을 얼마나 빠르게 반영하고 있는가다.

만약 이를 반영하지 못하고 있다면, 그것이 현재 조직이 직면한 가장 중요한 기술 과제다. 이는 개별 AI 프로젝트보다 더 중요하며, 여전히 AI를 소프트웨어 항목으로 분류하는 예산 체계 내부에서는 체감되지 않을 수 있지만 훨씬 더 시급한 문제다.
dl-ciokorea@foundryco.com

In the high-stakes world of enterprise technology, we are culturally conditioned to celebrate addition. We throw launch parties for platform modernizations, issue press releases for AI integrations and track delivery velocity as a proxy for progress. Roadmaps grow longer. Backlogs get fuller. Teams stay busy.

Yet in my work advising boards and executives on capital allocation, I have found that the most dangerous number in an IT organization is not how much you are building. It is how much you are refusing to retire.

I call this the innovation tax. It is the silent, compounding levy placed on engineering capacity by software assets that have outlived their economic utility. Unlike financial debt, which appears clearly on the balance sheet with a defined interest rate and maturity date, this tax hides in the margins of the P&L. It shows up as slower delivery, declining morale, rising operating expenses and an ever-present sense that, despite record effort, the organization is falling behind.

For CIOs attempting to position themselves as strategic business partners rather than delivery executives, this liability is existential. If you cannot explain where engineering capacity is being consumed, you cannot credibly argue for new investment.

The psychology of hoarding

To understand why this tax persists, we must look beyond the spreadsheet and look at the human brain. The barrier to decommissioning legacy software is rarely technical. It is emotional.

I experienced this firsthand during a portfolio review for a mid-sized logistics company. I had identified a legacy reporting module that cost $250,000 annually to maintain but was used by only three customers. The math was obvious. We should kill it.

I walked into the meeting expecting a quick approval. Instead, I faced a wall of emotional resistance. The VP of Sales argued that killing the feature would damage the relationship with those three customers. The Engineering Director, who had written the original code for that module a decade ago, argued that it was “stable core infrastructure” that shouldn’t be touched.

I realized in that moment that we weren’t debating economics. We were debating identity. Psychologists call this loss aversion. We feel the pain of losing something roughly twice as intensely as the pleasure of gaining something of equivalent value. When a product manager considers deleting a feature, they don’t see a gain in efficiency. They see a loss of optionality.

This is compounded by a deep-seated bias to overvalue things we created ourselves. That Engineering Director didn’t want to save the module because it generated value. He wanted to save it because it represented his contribution to the company’s history.

I eventually solved this not with logic but with process. I worked with the CTO to establish a quarterly “sunset committee,” an operational body with one KPI: code retirement. By formalizing asset destruction, we removed the emotional weight from the creators and placed it on a governance framework. In the efficiency economy, detachment is a competitive advantage.

The mechanics of carry cost

Consider the difference between a project and an asset. A project has a distinct end date. An asset has an indefinite carry cost.

I recently audited a portfolio for a logistics enterprise where leadership was baffled by their inability to ship new features. They were not suffering from a lack of talent but from asset congestion. Every feature they had shipped in the previous five years was still active and requiring security patching, infrastructure monitoring, compliance reviews and dependency updates.

This situation is often mislabeled as technical debt, implying a code-quality issue that can be resolved with refactoring. That framing is dangerously incomplete. This is a capital allocation problem. When you allow low-value assets to persist, you are effectively taxing every future initiative. New work must accommodate old assumptions that no longer serve the business.

Industry data supports this view. Gartner estimates that unmanaged technical debt and portfolio complexity can consume up to 35 percent of IT budgets, effectively crowding out investment in innovation. If a third of your technology spend is devoted to sustaining yesterday’s ideas, you are not underfunded. You are misallocated.

The zombie asset diagnostic

After seeing this pattern repeat across dozens of organizations, I developed a specific diagnostic to identify what I call “Zombie Assets.” These are features that are technically alive but functionally dead. They consume compute resources and engineering attention but generate zero marginal value.

I use a simple heuristic called the Rule of Two. When I audit a portfolio, I look for features that have not been touched by a user in two months or updated by a developer in two years. If a feature hits both markers, it is a candidate for the morgue.

I applied this Rule of Two at a healthcare SaaS company that was struggling with margin compression. We scanned their codebase and usage logs and found that nearly 22 percent of their features met the criteria. These weren’t obscure back-end scripts; they were customer-facing buttons and reports that had simply fallen out of fashion.

The engineering team was terrified to turn them off. They cited the “Sunk Cost Fallacy” in reverse, arguing that because they had spent millions building them, they had to keep them running “just in case.” To prove them wrong, we ran a “Scream Test.” We turned off the features in the staging environment and waited for someone to complain.

Silence.

We then turned them off in production. Still silence.

By decommissioning those zombie assets, we reclaimed 18 percent of the engineering team’s capacity in a single quarter. That capacity was immediately redeployed to a high-priority AI initiative that had been starved for resources. We didn’t need to hire more engineers. We just needed to stop maintaining the dead. This diagnostic is now the first step in every turnaround I lead.

The hidden talent drain

This compounding burden not only affects financial performance. It quietly destroys talent density. Top engineers want to work on meaningful problems. They want to build new capabilities, modernize systems and see their work drive measurable outcomes.

I recall a specific exit interview with a senior architect who was leaving a well-funded fintech startup. When I asked her why she was leaving, she didn’t mention money or culture. She said, “I spend 70 percent of my week patching a system that should have been turned off two years ago. I’m not an engineer anymore. I’m a curator.”

When most of an engineer’s time is spent patching brittle systems that exist solely because no one dares to retire them, disengagement follows. The cost of this churn is often invisible until it is too late. As top talent leaves, the remaining team becomes increasingly specialized in maintaining legacy systems and further cementing the status quo.

Research from McKinsey on developer velocity highlights that the top quartile of companies experience 4-5x faster revenue growth than their peers, largely because they minimize low-value toil. The correlation is clear. You cannot retain top talent if you treat them as museum curators for legacy code.

The innovation tax isn’t just a code problem; it’s a talent problem. The Audit Interview Protocol is designed to filter for “Capital Judgment”—ensuring you hire engineers who prioritize asset retirement and simplicity over blind code generation.

The portfolio surgeon’s playbook

Breaking this cycle requires governance rather than heroics. CIOs must institutionalize a governance of subtraction.

• Automatic sunsetting thresholds: Features should not live indefinitely by default. Adoption metrics must trigger impairment reviews automatically. When usage drops below a defined threshold, the burden of proof shifts. Product teams must justify continued investment by demonstrating positive margin contribution.
• Zero-sum roadmaps: In capital-constrained environments, complexity must be budgeted. Introducing new scope requires retiring equivalent legacy scope. This forces trade-offs before code is written, not years later.
• Maintenance margin reporting: CIOs should report the percentage of R&D spend devoted to defensive versus offensive work. Forrester research indicates that organizations allowing defensive spend to exceed 40 percent experience declining innovation velocity.

From code bloat to capital discipline

The innovation tax is not a failure of engineering. It is a failure of governance. Boards would never allow factories, real estate or inventory to remain on the books without periodic impairment testing. Software deserves the same discipline.

In the efficiency economy of 2026, leaders are remembered not for the volume of code they shipped but for the durability of the value they created. Sometimes the most profitable, strategic and courageous decision a CIO can make is to hit delete.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

For decades, enterprise technology followed a familiar arc. A new capability would emerge as a specialty tool, useful to a handful of power users, managed by a dedicated team, funded through a departmental budget line. Over time, if the technology proved its value, it would graduate: First into a shared service, then into the core technology stack and finally into the fabric of how the organization operated. Databases. Networks. Cloud computing. Each followed this trajectory.

Artificial intelligence has just completed that journey, in roughly a quarter of the time any previous technology took to do it.

The evidence is no longer theoretical. In sector after sector, AI has moved from pilot project to operational dependency. Financial services firms are running credit decisioning and fraud detection on models that would have been considered research projects three years ago. Manufacturers are using AI to optimize production schedules in real time. Healthcare systems are relying on AI-assisted diagnostics in clinical workflows. Retailers have AI embedded in demand forecasting, pricing and customer experience — simultaneously.

What this means for CIOs and technology leaders is both clarifying and demanding: AI is no longer a software category to be evaluated, procured and managed alongside your CRM or ERP. It is infrastructure. And organizations that continue treating it otherwise are making a category error with compounding consequences.

AI is no longer a software category to be evaluated and managed alongside your CRM or ERP. It is infrastructure, and the sooner leaders govern it accordingly, the better.

The infrastructure threshold

What distinguishes infrastructure from software? The question is more than semantic. Infrastructure is load-bearing. It is the substrate on which other capabilities are built. You don’t evaluate infrastructure purely on ROI; you evaluate it on reliability, resilience and strategic optionality. When your network goes down, you don’t ask whether the investment was worth it; you restore service, because everything else depends on it.

AI has crossed that threshold for a growing number of enterprises. It is now embedded in customer-facing processes, internal operations, compliance workflows and competitive positioning simultaneously. When AI systems degrade or fail, it is no longer an inconvenience affecting a single team. It is an operational event.

This shift changes the calculus for technology leaders in practical ways. Infrastructure decisions are not made annually during budget cycles; they are made strategically, with long time horizons and with explicit attention to redundancy and risk. Infrastructure requires governance frameworks, not just usage policies. It demands investment in resilience, not just capability. And it requires accountability at the board level, not just the IT department.

Many organizations are not there yet. A recent survey of enterprise technology leaders found that the majority still classify AI expenditure under software or R&D budgets, manage AI through ad hoc working groups rather than dedicated governance structures and lack clear frameworks for AI-related risk, including model drift, vendor dependency and data provenance. This is the equivalent of treating your cloud computing infrastructure as a departmental experiment, after it already runs your core systems.

The governance gap is the real risk

The maturity gap in AI governance is not primarily a technology problem. The models exist. The platforms exist. The use cases are well-documented. The gap is organizational: A failure to update governance and operating models at the speed that the technology has evolved.

Consider what meaningful AI governance actually requires. It starts with visibility: Knowing what AI systems are in production, who owns them, what data they consume and what decisions they influence. Surprisingly few enterprises have achieved this. Shadow AI — models and tools deployed outside formal IT channels — is now pervasive. Employees are using consumer-grade AI tools to process sensitive data, generate customer communications and inform business decisions, often with no organizational awareness.

Beyond visibility, governance requires accountability structures. Who is responsible when an AI system produces a discriminatory outcome? Who approves a model for production use? Who monitors for drift? These questions require answers that are not captured in a vendor contract or an acceptable-use policy. They require defined roles, escalation paths and audit capabilities, the same rigor applied to financial controls or data security.

For regulated industries, the stakes are already crystallizing in regulatory requirements. The EU AI Act, evolving SEC guidance on algorithmic decision-making, and sector-specific frameworks from banking and healthcare regulators are all moving in the same direction: Toward mandatory documentation, risk classification and accountability for AI systems that affect consequential decisions. Compliance will require infrastructure-level governance — not project-level oversight.

The build-or-buy question has changed

The strategic question facing technology leaders has also shifted. For most of the last decade, the dominant AI strategy for enterprises was to buy capabilities embedded in existing software platforms, a forecasting module here, a recommendation engine there and occasionally to build bespoke solutions for differentiated use cases. The foundation model era has rewritten this calculus.

Large language models and multimodal foundation models have dramatically lowered the cost of building AI-native capabilities. The question is no longer whether to use AI, but how to architect AI capabilities that are defensible, maintainable and aligned with organizational strategy. This means decisions about which foundation models to rely on, how to manage fine-tuning and customization, where proprietary data creates durable advantage and how to avoid vendor lock-in in a market that is still consolidating.

These are infrastructure architecture decisions. They require the same rigor as decisions about cloud architecture, data platform design or network topology. They have multi-year implications, significant switching costs and deep interdependencies with other systems. CIOs who approach them with a procurement mindset, focused on features and per-seat pricing, will find themselves constrained by decisions made without adequate strategic consideration.

What the transition actually looks like

Treating AI as infrastructure is not a single initiative. It is a shift in operating model that touches budgeting, governance, talent and vendor strategy simultaneously. Organizations that are executing this transition well tend to share a few common patterns.

First, they have moved AI investment out of project budgets and into capital and operational infrastructure budgets, with explicit recognition of the long-term, ongoing nature of the commitment. This is not just an accounting change; it signals organizational intent and enables the kind of sustained investment that infrastructure requires.

Second, they have established dedicated AI governance functions with clear ownership, typically sitting at the intersection of technology, legal, risk and business leadership. These functions are not committees that meet quarterly to review policies. They are operational teams that maintain model inventories, monitor production systems and enforce standards in real time.

Third, they have invested in the data and MLOps infrastructure that AI systems require to remain reliable and current. Model performance degrades. Data distributions shift. New regulatory requirements emerge. Sustaining AI capabilities requires ongoing investment in the underlying data pipelines, monitoring systems and retraining workflows, exactly analogous to the patching, updating and capacity management that sustains any other piece of enterprise infrastructure.

Finally, they have begun building the institutional knowledge required to make good AI architecture decisions over time. This means not only hiring data scientists and ML engineers, but developing AI literacy across technology leadership, business stakeholders and the board. Infrastructure decisions made without adequate domain knowledge produce technical debt. AI infrastructure decisions made without adequate understanding of model behavior, risk and strategic tradeoffs will produce the same.

The window for getting this right is narrowing

The organizations that built robust cloud infrastructure ahead of the curve, those that developed genuine cloud-native capabilities while competitors were still debating lift-and-shift strategies, ended up with durable competitive advantages that persisted for years. The gap between cloud leaders and laggards proved difficult to close once it opened, because infrastructure advantages compound: Better infrastructure enables better capabilities, which attract better talent, which enables better infrastructure.

AI is following the same dynamic, and the window for deliberate, strategic positioning is narrowing. The organizations treating AI as infrastructure today, investing in governance, architecture, talent and operational discipline, are building advantages that will be difficult to replicate. The organizations still treating AI as a collection of software tools to be evaluated project by project are not just behind. They are behind in a way that is becoming harder to correct.

For CIOs, the mandate is clear. The question is not whether AI deserves infrastructure-level investment and governance. It already does, in most organizations that have deployed it meaningfully. The question is whether your organization’s operating model, governance structures and strategic planning processes have caught up to that reality.

If they haven’t, that is the most important technology problem you have right now — more important than any individual AI initiative, and more urgent than it may appear from inside a budget cycle that still classifies AI as a software line item.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

챗GPT, 클로드 코워크, 깃허브 코파일럿과 같은 대규모 언어모델(LLM)은 콘텐츠 생성, 코드 작성 지원, 협업 업무 등에서 개인과 조직이 인공지능과 상호작용하는 방식을 근본적으로 바꿔놓았다. 이러한 발전의 중심에는 ‘토큰화(Tokenization)’라는 개념이 자리 잡고 있다. 토큰화는 사용자의 입력을 모델이 어떻게 해석하고 처리할지, 나아가 어떤 기준으로 과금할지를 결정하는 핵심적인 과정이다.

토큰화를 이해하는 일은 활용 효율을 높이고 비용을 예측하려는 기술 전문가는 물론, 주요 AI 플랫폼 간의 세밀한 차이를 파악하려는 사용자에게도 필수적이다.

토큰화 이해하기:토큰과 단어, 문장의 차이

토큰화는 대규모 언어모델이 텍스트를 더 작고 관리하기 쉬운 단위인 ‘토큰’으로 분해하는 방식을 의미한다. 토큰은 단어 또는 문장처럼 명확한 언어학적 경계로 구분되지 않는다. 하나의 문자일 수도 있고, 단어의 일부이거나 전체 단어, 심지어 문장부호까지 포함할 수 있는 하위 단위다.

예를 들어 영어 단어 ‘unbelievable’은 사용되는 토크나이저에 따라 ‘un’, ‘believ’, ‘able’과 같이 여러 개의 토큰으로 나뉠 수 있다. 이러한 방식은 다양한 언어와 복잡한 어휘, 프로그래밍 문법까지 보다 효율적으로 처리할 수 있게 해준다. 결과적으로 토큰화는 단어 또는 문장 단위 분절보다 훨씬 더 세밀한 구조를 갖는다. 이를 통해 LLM은 문맥과 의미를 유연하게 관리할 수 있다.

프롬프트 입력 생애주기 : 사용자 입력에서 모델 응답까지

프롬프트가 LLM을 거치는 과정은 사용자가 질문, 지시문, 코드 조각 등을 입력하는 순간부터 시작된다. 입력된 텍스트는 먼저 해당 플랫폼 고유의 토크나이저를 통해 토큰 시퀀스로 변환된다. 각 토큰에는 고유한 식별 번호가 부여되며, 이 과정을 통해 프롬프트는 숫자 기반의 표현으로 바뀐다.

LLM은 이 숫자 시퀀스를 입력받아 신경망 아키텍처를 통해 처리한다. 모델은 앞선 토큰이 제공하는 문맥을 바탕으로 다음에 올 가능성이 가장 높은 토큰을 예측하도록 학습돼 있다.

모델은 입력을 처리하는 동시에 토큰 단위로 응답을 생성한다. 이 과정은 최대 토큰 한도에 도달하거나 시퀀스 종료 마커를 만날 때까지 반복된다. 생성이 완료되면 토큰 시퀀스는 다시 사람이 읽을 수 있는 텍스트로 변환된다. 이 전체 과정에서 프롬프트와 생성된 응답 모두가 총 토큰 수에 포함되며, 이는 사용량과 비용 산정의 핵심 기준이 된다.

토큰 사용량 계산:사용량 측정과 과금 방식

토큰 사용량은 LLM 서비스 사용자와 제공자 모두에게 중요한 지표다. 성능과 비용, 대규모 도입의 타당성에 직접적인 영향을 미치기 때문이다. 대부분의 플랫폼은 프롬프트에 포함된 토큰 수와 응답에 포함된 토큰 수를 합산해 사용량을 계산한다.

예를 들어 사용자가 50토큰으로 분해되는 프롬프트를 입력하고, 모델이 100토큰으로 구성된 응답을 반환했다면 해당 상호작용의 총 사용량은 150토큰이 된다. 이 방식은 사용자의 요청이 요구한 연산량에 비례해 비용을 부과하는 구조다.

토큰화는 매우 세밀하게 이뤄지기 때문에 동일한 문장이라도 사용 언어, 문장부호, 또는 적용된 토크나이저 알고리즘에 따라 토큰 수가 달라질 수 있다. 그 결과, 같은 프롬프트를 입력하더라도 모델이나 플랫폼에 따라 토큰 사용량에 차이가 발생할 수 있다. 이러한 특성을 이해하면 보다 효율적인 질의를 설계하고, 예상 사용량을 더욱 정확히 산정할 수 있다.

플랫폼 비교:챗GPT, 클로드 코워크, 깃허브 코파일럿

토큰화의 기본 원리는 플랫폼 전반에서 유사하지만, 실제 구현 방식과 최적화 전략은 서비스마다 다르다.

오픈AI가 개발한 챗GPT는 바이트 페어 인코딩(Byte Pair Encoding, BPE) 기반 토크나이저를 사용한다. 텍스트를 서브워드 단위로 분할해 처리 효율성과 어휘 범위 간 균형을 맞추는 방식이다. 상호작용당 토큰 한도와 과금 구조가 비교적 명확하게 문서화돼 있어 사용자는 토큰 소비량을 비교적 정확하게 예측할 수 있다.

앤트로픽의 클로드 모델을 기반으로 한 클로드 코워크 역시 서브워드 기반 토큰화를 적용한다. 다만 BPE의 다른 변형을 사용하거나, 학습 데이터 특성에 맞춘 고유 알고리즘을 적용할 가능성이 있다. 이로 인해 토큰 분절 방식과 사용량 계산 세부 구조는 오픈AI 접근 방식과 일부 차이를 보일 수 있다.

클로드 코워크는 안전성과 문맥 유지에 상대적으로 더 큰 비중을 둔다. 이러한 설계 철학은 프롬프트를 분해하고 처리하는 방식에도 영향을 줄 수 있다. 그 결과, 동일한 입력이라도 챗GPT와는 다른 토큰 수가 산출될 가능성이 있다.

주요 생성형 AI 솔루션 기능 비교

구분	챗GPT	클로드 코워크	깃허브 코파일럿
토큰 사용량	BPE 기반 토크나이저를 사용해 텍스트를 서브워드 단위로 분해한다. 상호작용당 토큰 한도가 명확하게 문서화돼 있으며 사용량이 비교적 투명하게 공개된다.	서브워드 토큰화를 기반으로 하며, 모델 특성에 맞춘 고유 알고리즘을 사용할 수 있다. 안전성과 문맥 유지에 초점을 두며 토큰 분절 및 사용량 산정 방식에서 일부 차이가 발생할 수 있다.	코드에 최적화된 토크나이저를 사용한다. 프로그래밍 문법과 구조에 민감하며 복잡한 코드에서는 토큰 사용량이 증가할 수 있다. 사용량은 일반적으로 사용자에게 직접적으로 노출되지 않는다.
프롬프트당 비용	토큰 수를 기준으로 한 투명한 과금 체계를 제공해 프롬프트별 비용 예측이 용이하다.	토큰 소비량을 기준으로 과금하며, 알고리즘 차이에 따라 세부 요금 구조가 다소 달라질 수 있다.	내부적으로는 토큰 사용량에 기반하지만, 사용자에게는 주로 구독 기반 요금 체계가 제공된다.
제공 모델 다양성	GPT-3.5, GPT-4 등 다양한 모델 버전을 제공해 정확성과 효율성 요구에 따라 선택할 수 있다.	클로드 계열 모델 옵션을 제공하며, 협업 및 보안 중심 환경에 적합하도록 구성돼 있다.	GPT 아키텍처 기반으로 코드에 특화해 파인튜닝된 코덱스 모델을 주로 사용하며, 정기적으로 업데이트가 이뤄진다.
사용자 경험	일반 질의응답과 대화형 활용에 적합하도록 설계돼 예측 가능하고 직관적인 사용자 경험을 제공한다.	협업 워크스페이스에 초점을 맞추며 안전성, 확장된 문맥 처리, 팀 중심 워크플로를 강조한다.	코드 편집기에 직접 통합돼 개발 흐름을 방해하지 않으면서 실시간 코드 제안을 제공한다.
라이선스 비용	무료 플랜과 유료 구독 옵션을 포함한 구독 기반 모델을 운영한다.	개인 및 기업 환경을 고려한 라이선스 옵션을 제공한다.	월간 또는 연간 구독 형태로 제공되며, 초기 사용자를 위한 무료 체험 기간을 제공하는 경우가 많다.
기타 주요 특징	API 접근을 지원하며, 다양한 애플리케이션 연계를 위한 문서와 지원 체계를 갖추고 있다.	윤리적 응답과 안전성에 중점을 두며, 복잡한 작업을 위해 더 긴 문맥 창을 지원한다.	소프트웨어 개발 업무에 특화돼 있으며, 주요 통합개발환경(IDE)과 깊이 연동되고 다양한 프로그래밍 언어를 지원한다.

각 플랫폼은 특정 사용자 요구를 충족하도록 설계됐다. 토큰화 방식과 과금 구조, 사용자 인터랙션 전략 역시 주요 타깃층에 맞춰 구성돼 있다. 비용과 사용량의 명확성을 중시하는지, 협업 기능을 필요로 하는지, 혹은 매끄러운 코드 지원을 원하는지에 따라 적합한 플랫폼은 달라진다. 이러한 차이를 이해하면 자신의 목적에 가장 부합하는 서비스를 선택하는 데 도움이 된다.

깃허브 코파일럿은 코드 지원에 특화된 도구로, 오픈AI의 GPT 아키텍처를 기반으로 한 코덱스 모델을 활용한다. 프로그래밍 언어에 최적화된 토크나이저를 적용해 코드 문법, 들여쓰기, 주석 등을 높은 정확도로 처리한다. 그 결과 코드 구조에 매우 민감하게 반응하며, 장황하거나 복잡한 코드 조각에서는 토큰 사용량이 급증할 수 있다. 또한 개발 환경에 통합돼 작동하기 때문에 사용자는 토큰 소비를 직접 인지하지 못하는 경우가 많다. 다만 내부적인 과금 및 성능 구조는 LLM의 일반적인 원칙을 따른다.

요약하면 세 플랫폼 모두 서브워드 또는 문자 기반 알고리즘을 활용해 프롬프트를 토큰으로 변환한다. 그러나 토큰화 세부 방식과 사용량 계산 구조, 처리 전략은 각 플랫폼의 목표 사용자와 활용 분야에 따라 달라진다. 챗GPT는 범용 질의에 대해 투명성과 예측 가능성을 제공하고, 클로드 코워크는 협업과 보안 중심 환경에 맞춰 설계됐다. 깃허브 코파일럿은 코드 중심 업무에 최적화돼 있다.

토큰 최적화 모범 사례

고도화된 LLM 플랫폼을 효율적으로 활용하려면 토큰 최적화가 필수다. 프롬프트 구조와 처리 방식을 신중하게 설계하면 불필요한 토큰 소비를 줄이고 응답을 간결하게 유지할 수 있다. 이는 궁극적으로 비용 절감으로 이어진다.

깃허브 코파일럿을 사용할 경우, 개발자는 코드 주석을 간결하게 작성하고 프롬프트에 과도한 설명을 포함하지 않는 것이 바람직하다. 예를 들어 모든 요구사항을 장황하게 나열하기보다 “리스트를 정렬하는 파이썬 함수 생성”처럼 명확하고 구체적인 지시를 제시하면 적은 토큰으로도 정확한 결과를 얻을 수 있다. 또한 복잡한 작업은 여러 개의 작은 프롬프트로 나누는 것이 토큰 과다 사용을 방지하는 데 도움이 된다.

클로드 코워크와 같은 협업 플랫폼에서는 상황과 참여자에 맞춰 프롬프트를 조정하는 전략이 효과적이다. 간결한 문장을 사용하고 실행 가능한 요청에 집중하면 팀 단위 논의 과정에서 토큰을 효율적으로 배분할 수 있다. 예를 들어 장문의 배경 설명 대신 “오늘 프로젝트 회의 내용을 요약”이라고 요청하면 보다 정확하고 간결한 응답을 얻을 수 있다.

챗GPT를 사용할 때는 중복 표현을 피하고, 관련된 질문은 가능한 한 하나의 프롬프트로 통합하는 것이 좋다. 여러 개의 개별 질문을 나열하기보다 “플랫폼 X의 핵심 기능은 무엇인가?”처럼 구조화된 질문을 제시하면 더 적은 토큰으로 포괄적인 답변을 받을 수 있다. 불릿이나 번호 목록을 활용해 요구사항을 명확히 하면 모호성을 줄이는 데도 도움이 된다.

공통적으로는 프롬프트 이력을 점검하고 토큰 사용 패턴을 분석하는 습관이 중요하다. 플랫폼별 문서와 도구를 활용하면 보다 효율적인 프롬프트 템플릿을 구축할 수 있다. 결국 효과적인 프롬프트 설계와 플랫폼 특성에 대한 이해가 LLM 워크플로에서 최적의 토큰 활용을 이끄는 핵심 요소다.

결론

토큰화와 토큰 소비 구조에 대한 이해는 고급 LLM 플랫폼을 활용하는 전문가에게 필수적인 지식이다. 토큰이 단어 또는 문장보다 더 세밀한 단위로 작동한다는 점을 인식하면, 보다 효율적인 프롬프트를 설계하고 사용 비용을 정확히 예측할 수 있다.

챗GPT, 클로드 코워크, 깃허브 코파일럿은 프롬프트 입력부터 응답 생성까지의 기본 생애주기에서는 공통점을 보이지만, 토큰화 알고리즘과 적용 분야에 따라 사용자 경험에서 차이를 보인다. 이러한 과정을 이해하면 보다 전략적인 선택이 가능하며, 업무 흐름을 최적화하고 최신 언어모델의 역량을 최대한 활용할 수 있다.

**이번 기사는 IASA 최고 아키텍트 포럼(Chief Architect Forum, CAF)과의 협력을 통해 제작되었다. IASA는 비즈니스 기술 아키텍트를 위한 세계적인 비영리 전문 협회이며, 그 안에 있는 CAF는 IASA(International Association of Software Architects)가 운영하는 리더십 커뮤니티다. CAF는 비즈니스 기술 아키텍처의 발전을 연구하고 도전하며, 최고 아키텍트의 영향력과 리더십을 확장하는 것을 목표로 한다. 또한, 아키텍처 전문가들이 내부 및 외부에서 리더십을 발휘할 수 있도록 지원하는 커뮤니티 역할을 하고 있다.
dl-ciokorea@foundryco.com

Large language models (LLMs) such as ChatGPT, Claude Cowork and GitHub Copilot have revolutionised the way individuals and organizations interact with artificial intelligence for content generation, coding assistance and collaborative work. At the core of these advancements lies the concept of tokenization — a fundamental process that dictates how user inputs are interpreted, processed and ultimately billed. Understanding tokenization is crucial for tech-savvy professionals seeking to optimise their usage, predict costs and appreciate the nuanced differences between leading AI platforms.

Understanding tokenization: Tokens versus words and sentences

Tokenization refers to the method by which LLMs break down text into smaller, more manageable units called tokens. Unlike words or sentences, tokens are not strictly defined by linguistic boundaries; rather, they are subunits that may represent a single character, a fragment of a word, an entire word or even punctuation marks.

For instance, the English word “unbelievable” might be split into tokens such as “un,” “believ” and “able,” depending on the underlying tokenizer. This approach allows models to handle a wider range of languages, complex vocabulary and even programming syntax with greater efficiency. Consequently, tokenization is more granular than word or sentence segmentation, enabling LLMs to manage context and meaning with remarkable flexibility.

Prompt input lifecycle: From user entry to model response

The journey of a prompt through an LLM begins when a user submits their input — be it a question, instruction or code snippet. This input is first processed by a tokenizer specific to the platform, which converts the raw text into a sequence of tokens. Each token is then assigned a unique identifier, forming a numerical representation of the prompt. The LLM receives this sequence and processes it using its neural architecture, which has been trained to predict the most probable next token based on the context provided by preceding tokens.

As the model processes the input, it generates a response token by token, constructing the output iteratively until a stop condition is met — such as reaching a maximum token limit or encountering an end-of-sequence marker. The resulting output is then detokenized, meaning the sequence of tokens is translated back into human-readable text before being presented to the user. Throughout this lifecycle, both the prompt and the generated response contribute to the total token count, which is central to calculating usage and costs.

Token consumption calculation: Measuring and charging usage

Token consumption is a critical metric for both users and providers of LLM services, as it directly impacts performance, cost and feasibility of large-scale deployments. Most platforms calculate token usage by summing the number of tokens in the prompt and the response. For example, if a user submits a prompt that tokenizes into 50 tokens and the model returns 100 tokens in its reply, the total consumption is 150 tokens for that interaction. This approach ensures that users are billed proportionally to the computational effort their queries require.

The granularity of tokenization means that the same phrase may yield different token counts depending on the language, punctuation or even the specific tokenizer algorithm in use. As such, users may notice slight variations in token consumption when interacting with different models or platforms, even when submitting identical prompts. Understanding these nuances allows professionals to craft more efficient queries and better estimate their usage.

Platform comparisons: ChatGPT, Claude Cowork and GitHub Copilot

While the foundational process of tokenization is conceptually similar across platforms, each service employs its own implementation and optimizations. ChatGPT, developed by OpenAI, utilizes a byte pair encoding (BPE) based tokenizer, which splits text into subword units to balance efficiency and coverage of vocabulary. Token limits per interaction and billing structures are well-documented, allowing users to predict consumption with reasonable accuracy.

Claude Cowork, powered by Anthropic’s Claude model, also relies on a subword tokenization method but may use a different variant of BPE or a unique algorithm tailored to its training data. The specifics of token segmentation and consumption calculation can thus differ slightly from OpenAI’s approach. Claude Cowork often emphasizes safety and context retention, which may influence how prompts are broken down and processed, potentially leading to distinct token counts for similar inputs.

Comparing various features of popular Generative AI solutions

Feature	ChatGPT	Claude Cowork	GitHub Copilot
Token consumption	Employs a byte pair encoding (BPE) tokenizer, breaking text into subword units. Token usage is transparent, with well-documented limits per interaction.	Relies on subword tokenization, possibly with a unique algorithm tailored to its model. Token segmentation and counts may differ slightly, with focus on safety and context retention.	Optimised for code, its tokenizer is sensitive to programming syntax and structure. Token usage can rise with complex code and is generally abstracted from the user.
Cost per prompt	Transparent pricing based on token count, allowing for easy estimation of costs with each prompt.	Charges are based on token consumption, though the billing structure may vary slightly due to algorithmic differences.	Costs are linked to underlying token use, but users typically see subscription-based pricing rather than per-prompt charges.
Variety of models available	Offers several model versions (e.g., GPT-3.5, GPT-4), catering to different needs for accuracy and efficiency.	Presents model options within the Claude family, with configurations aimed at collaborative and secure use cases.	Primarily uses Codex, which is a GPT-based model fine-tuned for code, with updates released periodically.
User experience	Designed for general queries and conversations, offering a predictable and straightforward experience.	Focuses on a collaborative workspace, emphasising safety, extended context and team-oriented workflows.	Integrated directly into code editors, providing real-time code suggestions with minimal disruption to development flow.
Licence cost	Usually subscription-based, with options for free tiers and paid plans depending on usage volume.	May offer both individual and enterprise licensing, tailored to collaborative environments.	Charged as a monthly or annual subscription, often with a free trial for initial usage.
Additional notable features	Provides API access, with extensive documentation and support for integration into various applications.	Emphasizes ethical responses and safety in outputs, supporting longer context windows for complex tasks.	Specialised for software development tasks, with deep integration in popular IDEs and support for multiple programming languages.

Each of these platforms is crafted to meet specific user needs, and their approaches to tokenization, billing and user interaction reflect their primary audiences. Whether one is seeking clarity in cost and usage, collaborative features or seamless coding assistance, understanding these distinctions can help users select the platform that best fits their requirements.

GitHub Copilot, designed primarily as a coding assistant, leverages the Codex model, a derivative of OpenAI’s GPT architecture. Its tokenizer is optimised for programming languages, enabling it to handle code syntax, indentation and comments with high fidelity. As a result, tokenization in Copilot is particularly sensitive to code structure, and token consumption may spike with verbose or complex code snippets. Additionally, Copilot’s integration within development environments means that token usage is often abstracted from the user, though underlying billing and performance considerations remain consistent with LLM principles.

In summary, while all three platforms convert prompts into tokens using subword or character-based algorithms, the specifics of tokenization, usage calculation and processing are shaped by their respective target audiences and applications. ChatGPT offers transparency and predictability for general-purpose queries, Claude Cowork tailors its approach for collaborative and secure interactions, and GitHub Copilot optimizes for code-centric workloads.

Best practices in token optimization

Effective token optimization is essential for maximising the value and efficiency of interactions with advanced LLM platforms. By carefully considering how prompts are structured and processed, users can reduce unnecessary token consumption, streamline responses and ultimately lower costs. Below, we explore practical strategies and examples for optimising tokens in GitHub Copilot, Claude Cowork and ChatGPT.

With GitHub Copilot, developers should aim to write concise code comments and avoid overly verbose explanations within prompts. For instance, rather than elaborating every requirement, providing clear, targeted instructions—such as “generate a Python function to sort a list”—can produce accurate results while minimising token usage. Additionally, breaking down complex tasks into smaller, manageable prompts helps maintain clarity and reduces the likelihood of excessive token consumption.

For collaborative platforms like Claude Cowork, it is beneficial to tailor prompts to the specific context and participants. Using succinct language and focusing on actionable requests ensures that token usage is distributed efficiently during team discussions. For example, instead of a lengthy background, stating “summarise today’s meeting notes for the project” provides precise guidance and optimizes the response length.

When engaging with ChatGPT, users should avoid redundant phrasing and combine related queries into single prompts where feasible. By framing questions such as “What are the key features of platform X?” instead of listing multiple isolated questions, users can obtain comprehensive answers in fewer tokens. Employing bullet points or numbered lists within prompts can also help clarify requirements and reduce ambiguity.

Across all platforms, reviewing prompt history and analysing token consumption patterns can lead to more strategic usage. By leveraging platform-specific documentation and tools, users can refine their approach and develop prompt templates that consistently yield efficient results. Ultimately, mindful prompt engineering and a clear understanding of platform behaviour are key to achieving optimal token utilization in LLM workflows.

Conclusion

A thorough understanding of tokenization and token consumption is indispensable for professionals engaging with advanced LLM platforms. Recognizing that tokenization operates at a level finer than words or sentences enables users to craft more efficient prompts and anticipate usage costs with greater accuracy. While the lifecycle from prompt input to model response shares commonalities across ChatGPT, Claude Cowork and GitHub Copilot, platform-specific differences in tokenization algorithms and application focus lead to distinct user experiences. By staying informed about these processes, users can make more strategic choices, optimise their workflows and fully leverage the capabilities of modern language models.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

느린 헬프데스크 지원을 포함한 IT 비효율로 인해 많은 기업이 매년 수백만 달러의 비용을 부담하고 있으며, 다수의 직원과 IT 리더가 매주 여러 시간의 업무 시간을 잃고 있는 것으로 나타났다. AI 기반 헬프데스크 제공업체 아테라(Atera)의 설문조사 결과에서 확인된 내용이다.

헬프데스크 지연과 기타 IT 비효율이 흔하고 비용 부담이 크다는 점은 이미 알려져 있었지만, AI 기반 헬프데스크 제공업체 아테라(Atera)를 위해 실시된 이번 조사는 이러한 문제를 수치로 구체화했다.

조사에 따르면 직원의 3분의 2 이상이 프로세스 탐색, 이슈 재등록, 기술적 문제 해결 등 이른바 ‘메타 업무’에 하루 근무 시간의 최소 10%를 사용하고 있는 것으로 나타났다. 또한 약 3분의 2는 IT 시스템 지연으로 하루 최소 10분을 잃고 있으며, 이러한 지연은 직원 1인당 주당 100달러 이상의 비용을 기업에 발생시키는 경우가 많았다.

수천 명의 직원을 보유한 대기업의 경우 이러한 비용은 빠르게 누적될 수 있다.

IT 리더 역시 이러한 문제에서 자유롭지 않았다. 응답자의 약 4분의 3은 접근 권한 문제, 느린 시스템, 승인 지연, IT 문제 해결 지연 등으로 인해 매주 평균 최소 1시간을 잃고 있다고 밝혔다.

아테라의 설립자이자 최고경영자인 길 페켈만은 헬프데스크 요청 이후 직원 1명이 평균 약 3시간 30분의 업무 시간을 잃는다고 설명했다. 그는 “티켓을 생성한 시점부터 담당자의 응답을 받을 때까지의 시간, 문제 해결에 소요되는 시간, 그리고 업무 전환에 따른 비용이 모두 포함된다”며 “직원이 기존에 하던 업무를 중단하고 다른 일을 처리한 뒤 다시 원래 업무로 돌아오는 과정에서도 추가적인 시간이 소요된다”고 말했다.

간과된 비용

아테라는 자사의 AI 기반 헬프데스크 솔루션 홍보를 위해 이번 조사를 의뢰했지만, 다른 IT 전문가들은 조사 수치가 오히려 보수적일 수 있다고 평가했다. 애플리케이션 보안 기업 블랙덕 소프트웨어(Black Duck Software)의 수석 디렉터이자 기술 전문가인 콜린 호그-스피어스는 대부분의 조직이 IT 비효율로 인한 비용을 과소평가하고 있다고 지적했다.

호그-스피어스는 많은 대기업이 운영 비효율과 업무 지연으로 대표되는 이른바 ‘IT 마찰(friction)’로 인해 200명 이상의 인력에 해당하는 생산성 손실을 떠안고 있지만, 이러한 비용이 단일 예산 항목으로는 드러나지 않는다고 설명했다. 그는 “이번 연구의 수치는 실제 기업 환경에서 목격하는 상황과 일치한다”며 “진정한 문제는 마찰이 존재한다는 점이 아니라, 대부분의 재무팀이 이를 검토하도록 요청받은 적이 없다는 데 있다”고 말했다.

이어 IT 리더가 디지털 경험 측정 도구를 도입하고 분기별 검토를 수행해야 한다고 권고했다. 호그-스피어스는 “CFO가 분기마다 인력 규모는 검토하면서도 마찰 지표를 본 적이 없다면, 기업은 ‘유령 인력’에 비용을 지출하고 이를 간접비로 처리하고 있는 셈”이라며 “IT 마찰은 단순한 비용 센터가 아니라 보이지 않는 인력 손실”이라고 표현했다.

또한 일부 IT 마찰은 불가피하며, 기업 규모가 클수록 문제가 더욱 심화된다고 덧붙였다. 규정 준수 요구사항, 멀티클라우드 환경, 복잡한 배포 구조 등이 이러한 문제를 가중시킨다는 설명이다. 그는 “유능한 CIO는 이 부담을 줄일 수는 있지만 완전히 없앨 수는 없다”며 “우수한 디지털 경험을 제공하는 조직은 그렇지 않은 조직보다 생산성 손실이 현저히 적으며, 이는 리더십의 중요성을 입증한다”고 분석했다.

완벽함의 신화

디지털 전환 컨설팅 기업 콘트라코(contraco)의 최고경영자 프랭크 멜트케는 일부 IT 비효율은 불가피하다고 설명했다. 그는 “마찰이 전혀 없는 IT 환경은 환상에 가깝다”며 “완전히 마찰이 없는 환경이 존재한다면, 그것은 보안이 취약하거나 비용이 지나치게 높은 경우일 것”이라고 말했다.

멜트케는 강력한 보안 프로토콜과 규정 준수 요구사항이 일정 수준의 메타 업무를 유발한다고 설명하며, “이번 연구는 실제 마찰을 측정했지만, 필요한 마찰과 불필요한 마찰을 구분하지는 않았다”고 지적했다. 이어 “성공적인 IT 리더의 목표는 모든 마찰을 제거하는 것이 아니라, 조직을 보호하기 위해 필요한 프로세스가 적절히 작동하도록 하는 것”이라고 전했다.

일부 IT 마찰이 불가피하더라도, 이러한 문제는 특히 중소기업(SMB)에 더 큰 영향을 미친다고 멜트케는 분석했다. 이번 아테라 설문조사는 미국 내 직원 1,000명 이상의 기업을 대상으로 정규직 직원 1,000명과 C-레벨 및 고위 리더 500명을 포함해 진행됐지만, 더 작은 조직을 조사할 경우 문제가 더욱 심각하게 나타날 수 있다는 설명이다.

그는 “대기업 직원이 헬프데스크 티켓을 기다리며 45분을 잃는다면, 중소기업 직원은 문제를 직접 해결하려다 그보다 더 많은 시간을 잃을 수 있다”고 말했다.

1인 기업의 경우 상황은 더욱 심각하다. 멜트케는 “대표이자 실행 인력이며 IT 부서 역할까지 모두 수행해야 한다”며 “문서 서식 지정, 이메일 통합 문제 해결, 작업 수동 태깅 등에 소비되는 모든 시간은 곧바로 매출 창출 기회를 잠식한다”고 설명했다.

이에 따라 멜트케는 중소 조직이 IT 환경을 단순화할 것을 권장했다. 그는 “지속적인 유지보수와 수작업 데이터 입력이 필요한 저가 단일 기능 애플리케이션을 여러 개 조합하기보다, 소수의 강력하고 신뢰할 수 있는 도구에 집중해야 한다”며 “CRM, 청구, 일정 관리를 통합 제공하는 단일 프리미엄 플랫폼이 무료 도구 다섯 개를 조합한 분산형 스택보다 훨씬 뛰어난 성과를 낼 것”이라고 조언했다.

AI, 해결사가 될 수 있을까?

일부 전문가들은 AI 기반 헬프데스크 서비스가 응답 속도를 높이고 직원들이 보다 신속하게 생산성을 회복하는 데 도움을 줄 수 있다고 보고 있다. 프랭크 멜트케는 AI가 아직 거버넌스 관련 마찰을 해소하는 데에는 한계가 있지만, 헬프데스크의 일부 기능을 자동화하는 데는 효과적이라고 설명했다.

그는 “자동화된 헬프데스크 도구는 반복적인 1차 지원 이슈, 비밀번호 재설정, 접근 권한 요청, 그리고 이미 알려진 오류 패턴을 매우 효율적으로 처리하며, 어떤 인력 기반 대기열보다 빠르게 대응할 수 있다”며 “대량의 반복 티켓을 처리하는 조직에게 이는 실질적이고 측정 가능한 성과로 이어진다”고 말했다.

아테라의 설립자이자 최고경영자인 길 페켈만 역시 AI 기반 헬프데스크의 필요성을 강조하며, 해당 서비스가 응답 시간을 수 시간에서 수 분 단위로 단축할 수 있다고 밝혔다. 또한 AI는 숙련된 IT 인력을 확보하는 데 어려움을 겪는 기업에도 실질적인 도움이 될 수 있다고 설명했다.

그는 “현재 시장에서는 우수한 IT 인력이 매우 부족한 상황”이라며 “AI를 활용하면 기존 인력이 이전에는 수행하지 못했던, 기업에 매우 중요한 프로젝트에 집중할 수 있게 된다”고 말했다.
dl-ciokorea@foundryco.com