Agentic Work의 경제학

Coding Agent는 예전이라면 개발자가 몇 시간을 써야 했던 코드를 몇 분 만에 만들어낼 수 있다. 이제는 그다지 이례적인 경험도 아니다. 작업에 따라 차이는 꽤 인상적이다. 과거 반나절 정도 걸렸을 구현이 몇 분 뒤 첫 번째 완성형 Diff로 나타나는 경우도 있다.

그러면 아주 자연스러워 보이는 계산이 따라온다.

10× 더 빠른 코드 생성
=
10× 더 빠른 소프트웨어 개발
=
10× 더 낮은 비용

이 계산의 첫 번째 줄은 맞을 수 있다. 하지만 뒤의 두 등호는 맞지 않는다.

코드 생성에 가치가 없어서가 아니다. 오히려 반대다. 나는 현재 Coding Agents를 매우 적극적으로 사용하고 있고, 실제로 분명한 생산성 향상을 경험하고 있다. 내 업무만 놓고 보면 현재 효과를 대략 20% 정도로 본다. 여기에는 생성된 변경을 진지하게 Review하는 시간까지 이미 포함되어 있다. 이것은 과학적 Effect Size가 아니라, 내가 지금 일하는 환경에서 체감하는 개인적인 추정치다.

오류는 다른 곳에 있다. 우리는 하나의 생산 단계가 빨라진 것을 전체 생산 시스템이 빨라진 것으로 착각한다.

Software Engineering은 코드 작성만으로 구성되지 않는다. 변경 전에 문제를 이해하고, Requirements를 해석하고, Architecture와 Solution을 결정해야 한다. 변경 뒤에는 테스트, 통합, Debugging, Verification, Review, Security, 운영, 비즈니스 Acceptance가 이어진다. 이 단계들 중 일부는 AI로 더 빨라질 수 있다. 다른 일부는 거의 그대로 남는다. 그리고 기계가 생성하는 변경의 양이 늘어날수록 오히려 더 중요해지는 단계도 있다.

그래서 경제적으로 흥미로운 질문은 다음이 아니다.

모델이 얼마나 싸게 Tokens를 생성할 수 있는가?

더 중요한 질문은 이것이다.

원하는 변경이 기술적으로나 업무적으로 충분히 검증되어 실제로 받아들일 수 있는 변경이 되기까지 어떤 비용이 필요했는가?

이 글에서는 이 운영 단위를 Cost per Accepted Change라고 부르겠다.

이것은 ROI와 동일하지 않다. 변경 하나가 몇 유로만으로 생성되고 테스트되고 Accepted될 수 있어도, 비즈니스적으로 아무 가치가 없을 수 있다. 반대로 비용이 큰 변경이 막대한 비즈니스 가치를 만들 수도 있다. Cost per Accepted Change는 우선 Engineering Process의 효율을 측정한다. 경제적 가치는 그보다 한 단계 위에 있다.

따라서 이 글의 흐름은 Token에서 시작해 Agent Run과 Accepted Change를 거쳐 조직으로 이동한다. 그리고 마지막에는 단기 생산성 계산에서 쉽게 빠지는 질문으로 간다. 변경이 끝난 뒤 조직에는 어떤 역량이 남아 있으며, 미래를 위해 어떤 역량을 새로 축적하고 있는가?

잘못된 배수

Software Engineering은 Coding이 아니다.

당연한 말처럼 들리지만 AI 생산성에 대한 많은 논의에서는 놀랄 만큼 빨리 잊힌다. 기존에 세 시간 걸리던 활동이 18분으로 줄어들면, 눈에 보이는 속도 향상은 실제로 10배다. 하지만 그 활동이 전체 8시간짜리 변경의 한 부분에 불과했을 수도 있다.

나머지 작업이 자동으로 사라지는 것은 아니다.

업무 Requirement는 여전히 이해해야 한다. Architecture Decision은 기존 시스템과 맞아야 한다. Tests는 단순히 존재하는 것으로 충분하지 않고, 의미 있는 주장을 검증해야 한다. Diff가 문법적으로 완벽해도 업무적으로 틀릴 수 있다. Migration이 로컬에서는 동작하지만 운영 환경에서 실패할 수 있다. Security Requirement도 모델이 자신 있게 지켰다고 말한다고 해서 충족되는 것은 아니다.

Coding Agents는 이런 활동도 지원할 수 있다. 이것이 바로 그들의 중요한 가치 중 하나다. 그렇다면 우리는 이 전체 단계에서 실제로 얼마나 빨라졌는지를 측정해야 한다. 구현 코드 생성 속도만의 배수를 전체 Software Engineering의 배수로 사용해서는 안 된다.

10× Code Generation
≠
10× Software Engineering
≠
10× Cost Reduction

현재의 실증 연구도 측정 결과가 어떤 범위를 보느냐에 따라 크게 달라진다는 점을 보여준다. 잘 알려진 무작위 GitHub Copilot 실험에서는 모집된 소프트웨어 개발자 95명이 명확히 제한된 JavaScript 과제를 수행했고, Copilot을 사용한 그룹이 평균 55.8% 더 빨리 과제를 완료했다. 이후 Microsoft, Accenture, 또 다른 Fortune 100 기업에서 진행된 세 개의 더 큰 무작위 현장 실험은 총 4,867명의 개발자를 포함했고, 통합 분석에서 완료한 과제가 26.08% 증가했다. 이 연구는 현재 Management Science에 게재되어 있다. 그럼에도 개별 실험 사이의 결과 차이는 상당히 컸고, 통합 추정치의 표준오차는 10.3%포인트다.

다른 환경에서는 정반대 결과가 나왔다. METR은 2025년에 숙련된 오픈소스 개발자들에게 수년 동안 익숙하게 다뤄온 Repository에서 실제 Tasks를 수행하게 했다. 당시 AI Tools를 사용한 무작위 실험에서 개발자들은 평균적으로 19% 더 오래 걸렸다. METR 역시 이 결과가 2025년 초 도구와 특정 환경을 대상으로 한 역사적 Snapshot이라는 점을 명확히 강조한다. 2026년에는 더 최신 모델로 후속 실험을 진행했고 방향은 오히려 가속 쪽으로 기울었지만, Selection과 측정 문제가 너무 커서 저자들 스스로 정확한 효과 규모를 신뢰하기 어렵다고 평가했다.

더 흥미로운 것은 2026년 9월에 개정된 NBER Working Paper Writing Code vs. Shipping Code다. 이 연구는 50만 명이 넘는 GitHub 개발자와 그들의 AI Usage Telemetry를 사용한다. 더 새로운 세대의 Coding Tools가 도입될수록 측정된 Commits는 크게 증가한다. Autonomous Coding Agents의 경우 저자들은 Commits에 대해 누적 240% 효과를 보고한다. 하지만 더 높은 생산 단계로 갈수록 효과는 크게 약해진다. Projects에서는 80%, 실제 Releases에서는 30%만 남는다. 이것 역시 Working Paper이며 최종적인 인과적 진실은 아니다. 그러나 이 글의 문제를 아주 잘 보여준다. Writing Code와 Shipping Code는 서로 다른 생산 단계다.

따라서 중요한 배수는 Editor 안에 있지 않다. 완전한 생산 Flow 안에 있다.

Token에서 Accepted Change까지

언어 모델의 가장 단순한 경제 지표는 Token당 가격이다. 정확하고 비교하기 쉬워 매력적이다.

하지만 답하는 질문은 아주 작다.

더 유용한 계층은 다음과 같다.

Cost per Token
↓
Cost per Run
↓
Cost per Successful Run
↓
Cost per Accepted Change
↓
Economic Value

Cost per Token은 요금표 기준으로 Inference가 얼마나 비싼지 답한다.

Cost per Run은 실제 Run 하나가 Context와 Output을 얼마나 사용했는지까지 포함한다.

Cost per Successful Run은 Agent가 실패하거나 중단되거나 쓸 수 없는 해결 경로를 택할 수 있다는 점까지 고려한다.

Cost per Accepted Change는 최종적으로 변경이 받아들일 수 있는 수준이 되기까지 몇 번의 시도, Tests, 수정, Reviews, 그리고 얼마나 많은 Human Work가 필요했는지 계산한다.

그 위에야 비로소 Economic Value가 있다. 이 변경이 실제로 어떤 경제적 가치를 만들었는가?

다르게 말하면:

Model Pricing은 계산 비용을 알려준다. 문제 해결 비용을 알려주지는 않는다.

이 차이는 근본적이다. 20센트짜리 Agent Run 결과를 내가 45분 동안 고쳐야 한다면, 5달러짜리 Run을 10분 Review 후 바로 받아들이는 것보다 오히려 비쌀 수 있다.

그리고 기술적으로 Accepted된 변경도 아무도 필요로 하지 않는 Feature일 수 있다.

따라서 Cost per Accepted Change는 ROI를 대체하지 않는다. ROI 바로 아래의 운영적 Engineering Level이다.

Generation은 실제로 얼마가 드는가?

Token 기반 요금에서는 우선 세 가지 직접 가격 범주가 특히 중요하다. Input Tokens는 모델이 받는 Context를 포함한다. Prompt, Conversation History, Source Code, Agent Instructions, Tool Results, 경우에 따라 Repository의 상당 부분이 여기에 들어간다. Cached Input은 재사용 가능한 Context로, Provider가 할인된 가격으로 청구할 수 있다. Output Tokens는 모델이 생성한 사용량을 포함한다. Reasoning Model의 경우 가시적인 답변 텍스트에는 나타나지 않는 내부 Reasoning Tokens가 추가로 포함될 수 있다.

Agentic Workflow에서는 이 계산이 단일 Chat보다 복잡해진다. Agent는 파일을 읽고 Tools를 실행하며, 결과를 다시 받고, 코드를 수정하고, Tests를 실행하고, 그 출력까지 다시 처리한다. 같은 Repository Context를 여러 번 보기도 하고, 잘못된 Hypothesis 때문에 여러 Loop를 돌 수도 있다.

Tool Calls도 플랫폼에 따라 추가 비용이 생길 수 있다. 긴 Context는 별도 가격 규칙을 가질 수 있다. 예를 들어 GPT-5.6 Sol의 API Request가 272,000 Input Tokens를 넘으면 전체 Request에 2× Input, 1.5× Output 요금이 적용된다. Cache Write는 일반 Input 요금의 1.25배다. GPT-6 Astra 역시 별도의 Cache-Write 및 Long-Context 규칙을 가진다. Codex 같은 Product Surface에는 또 다른 예외가 있을 수 있다.

즉, 모델의 List Price만으로는 Agentic Flow의 전체 비용 함수를 설명할 수 없다.

2026년 9월 모델 가격

2026년 9월 10일 기준 OpenAI의 GPT-5.6 Sol과 GPT-6 Astra 표준 텍스트 Token 가격은 다음과 같다.

모델	Input / 1M	Cached Input / 1M	Output / 1M	비고
GPT-5.6 Sol	$4.00	$0.40	$20.00	2026-11-21까지 최소 유지되는 Promotion 가격
GPT-6 Astra	$10.00	$1.00	$50.00	기준일의 Standard 가격
Astra / Sol 비율	2.5×	2.5×	2.5×	해당 List Price 기준

이 값들은 OpenAI의 공식 모델 페이지와 Token Rate Card에서 가져온 것이다. OpenAI는 현재 Sol 가격이 기간 한정 Promotion임을 명확히 밝히고 있다.

따라서 명목상 Astra의 Token당 가격은 Sol보다 2.5배 높다.

이 문장은 맞다.

하지만 다음 문장은 여기에서 도출되지 않는다.

Astra는 해결한 Task당 2.5배 비싸다.

더더욱 다음 문장은 성립하지 않는다.

Astra는 Accepted Change당 2.5배 비싸다.

구체적인 가격은 2027년이면 이미 달라져 있을 가능성이 높다. 하지만 계산 구조는 여전히 유효하다.

Reasoning은 고정 배수가 아니다

“High Reasoning은 세 배 비싸다” 같은 문장은 특히 조심해야 한다. OpenAI에서 같은 모델 안의 Reasoning Level을 올린다고 해서 Token당 List Price가 자동으로 올라가는 것은 아니다. 현재 Rate Card는 GPT-5.6의 Reasoning Level이 달라도 동일한 요금을 적용한다.

다만 더 많은 Reasoning은 더 많은 Usage를 만들 수 있다. OpenAI는 output_tokens_details 안에 Reasoning Tokens를 표시하며, 이들은 Output Usage에 포함된다. max_output_tokens 역시 가시적 Output과 Reasoning Tokens를 모두 포함한다.

따라서 경제적으로 정확한 표현은 다음과 같다.

Reasoning Effort는 고정된 가격 할증이 아니다. 더 높은 Effort는 추가 Compute와 추가 Tokens를 만들 수 있으며, 그 규모는 Task, Model, Run에 따라 달라진다.

이건 단순한 용어 문제가 아니다. 어떤 Task에서는 더 높은 Reasoning이 Token 수를 늘리더라도 후속 Agent Run 두 번을 없애면 전체 비용이 더 낮아질 수 있다. 반대로 이미 매우 Converged된 단순 작업이라면 같은 추가 Reasoning이 단순한 낭비일 수 있다.

Change는 Implementation보다 크다

의도적으로 단순화한 예를 들어보자. 전통적인 Engineering으로 총 8시간이 필요한 Change가 있고, 그중 Implementation 자체가 3시간이다.

Coding Agent가 정확히 이 부분을 10배 가속한다. 180분 Implementation이 18분이 된다.

동시에 다른 단계로 일이 이동한다. Agent가 더 많은 Tests를 만들고 스스로 Iteration하며, 개발자는 Review와 Verification에 더 많이 투자한다. 다음 수치는 실증 평균이 아니라 설명을 위한 모델 계산이다.

작업 단계	전통적	Agentic
이해 / 분석	60 min	55 min
Architecture / Decision	45 min	50 min
Implementation	180 min	18 min
Tests / Iterations	75 min	90 min
Review / Verification	60 min	100 min
Integration / Acceptance	60 min	67 min
합계	480 min	380 min

실제 Code Production은 90% 줄었다. 하지만 총 시간은 8시간에서 6시간 20분으로만 줄어든다. 약 **21%**다.

이건 전혀 실망스러운 결과가 아니다.

비싼 Engineering Organization에서 지속적으로 약 20% 생산성 향상을 얻는다면 경제적으로 매우 매력적이다. 단지 “10×”와 나란히 놓으면 덜 화려하게 보일 뿐이다.

바로 이 지점이 많은 AI 논의의 문제다. 현실적인 System-Level Gain은 하나의 작업 단계에서 나온 거대한 가속 배수와 비교되면 작아 보인다.

실증 결과도 이런 조심스러운 관점을 지지한다. 명확히 제한된 조건에서는 매우 큰 가속이 가능하지만, 복잡한 실제 업무 환경에서는 효과가 크게 달라지고 Production Chain을 따라가면서 약해질 수 있다.

따라서 내 개인적인 약 20% 추정 역시 그저 개인 추정일 뿐이다. 어떤 연구도 입증하거나 반박하지 않는다.

더 비싼 모델이 더 쌀 수 있다

현재 OpenAI 가격을 사용하면 이 문제를 더 구체적으로 계산할 수 있다.

어려운 Change 하나를 가정하자. 각 Agent Run은 약 200,000 Input Tokens와 15,000 Output Tokens를 사용한다. 첫 Run은 Uncached Input을 쓰고, 후속 시도에서는 큰 Context가 모두 저렴한 Cache로부터 읽힌다고 강하게 단순화하자.

Sol은 세 번의 시도가 필요하다. Astra는 이 예에서 한 번에 Accepted 가능한 Solution을 만든다.

Human Labor는 $100/h Fully Loaded Cost를 가정한다. 이것 역시 설명용 숫자다.

지표	GPT-5.6 Sol	GPT-6 Astra
Token Category별 List Price	1×	2.5×
Run당 Tokens	200k Input + 15k Output	200k Input + 15k Output
Run 수	3	1
Correction Loops	2	0
Model Cost	$1.86	$2.75
Steering / Correction Time	70 min	25 min
Review / Verification	35 min	20 min
Human Active Time 합계	105 min	45 min
$100/h 기준 Human Cost	$175.00	$75.00
Accepted	Run 3 후	Run 1 후
Cost per Accepted Change	$176.86	$77.75

여기서 Sol의 모델 비용은 첫 Run $1.10과, 강하게 Cached된 후속 Run 두 번 각각 $0.38로 구성된다. Astra의 순수 Inference Cost는 $2.75로 실제 더 비싸다.

하지만 전체 계산에서는 Astra가 훨씬 싸다. 가정한 Human Work가 훨씬 많이 줄었기 때문이다.

물론 이 모델 계산은 Astra가 일반적으로 더 좋거나 더 싸다는 것을 증명하지 않는다. List Price가 충분한 Optimization Variable이 아니라는 사실만 보여준다.

가장 싼 모델은 Token Price가 가장 낮은 모델이 아닐 수 있다. 충분히 좋은, 검증된 Change를 가장 낮은 총비용으로 만들어내는 모델이 가장 싸다.

반대 예도 중요하다. Tests가 좋고 Architecture Rules가 명확하며 Decision Space가 작은 표준 CRUD Endpoint라면 Frontier Model은 불필요할 수 있다. 더 저렴한 모델이 같은 Reliability로 같은 Change를 만든다면 추가 Capability는 그저 Margin을 없앤다.

그래서 Model Routing은 품질 문제만이 아니다. 경제적 제어 문제다.

Model Economics는 빠르게 늙는다

지난 2년의 발전만 봐도 이런 분석이 얼마나 빨리 낡는지 알 수 있다.

다음 표는 명시적으로 Benchmark Time Series가 아니다. Benchmarks, Harnesses, Prompting, Reasoning Budgets, Test-Time Compute, 심지어 Dataset 자체도 변했다. 따라서 이 숫자들을 하나의 수학적 “Capability Curve”로 연결해서는 안 된다.

표가 보여주는 것은 다른 점이다. Coding과 Agentic Work에 사용할 수 있는 성능이 크게 좋아지는 동안 List Price는 그대로이거나 오히려 낮아질 수 있었다.

시점	모델	Input / 1M	Output / 1M	관련 Coding / Agentic Signal
06/2024	Claude 3.5 Sonnet	$3	$15	기존 Mid-Tier 가격으로 새 Sonnet 세대
10/2024	Claude 3.5 Sonnet, update	$3	$15	Anthropic 기준 SWE-bench Verified 33.4 → 49.0%, 가격 동일
02/2025	Claude 3.7 Sonnet	$3	$15	내부에서 실행 가능한 489개 SWE-bench Verified subset에서 63.7%; 추가 Test-Time Compute 시 70.3%
05/2025	Claude Sonnet 4	$3	$15	공개 Setup에서 SWE-bench Verified 72.7%
09/2025	Claude Sonnet 4.5	$3	$15	SWE-bench Verified 77.2%, 다른 Thinking / Prompt Setup
02/2026	Claude Sonnet 4.6	$3	$15	가격 동일; 초기 Claude Code 테스트에서 4.5보다 약 70% 선호
04/2026	GPT-5.5	$5	$30	Terminal-Bench 2.0 82.7%
07/2026	GPT-5.6 Sol	현재 $4	현재 $20	Terminal-Bench 2.1 88.8%; 2026년 9월 가격은 임시 인하
06/2026	Claude Sonnet 5	$2	$10	Introductory Price가 2026년 8월 영구 가격으로 전환

Anthropic은 Claude 3.5 Sonnet을 2024년 $3/$15에 출시했고 여러 후속 모델에도 같은 가격을 유지했다. 예를 들어 Claude 3.5 Sonnet 업데이트는 가격 인상 없이 Anthropic이 보고한 SWE-bench Verified 점수를 33.4에서 49.0%로 끌어올렸다. Claude 3.7, Sonnet 4, Sonnet 4.5도 $3/$15를 유지했다.

다만 각 SWE-bench 결과의 비교 가능성은 제한적이다. 예를 들어 Claude 3.7에서는 500개 중 489개 Tasks만 Anthropic Infrastructure에서 내부적으로 실행 가능했고, High-Compute 결과는 Parallel Attempts와 Selection Mechanism을 사용했다. Sonnet 4는 단순한 Two-Tool Setup으로 평가했고, Sonnet 4.5는 Defined Thinking Budget과 추가 Prompt Instruction을 사용했다.

2026년에는 가격 움직임이 더 뚜렷했다. Sonnet 4.6은 $3/$15를 유지했다. Sonnet 5는 6월에 $2/$10 Introductory Price로 출시되었고, Anthropic은 2026년 8월 그 가격을 영구화했다.

OpenAI 역시 “새로울수록 비싸다”는 단순한 공식은 없다. GPT-5.5는 1M Tokens당 $5 Input / $30 Output으로 출시되었다. 이 글의 기준일에는 GPT-5.6 Sol이 $4/$20이지만 기간 한정 Promotion이다. OpenAI는 GPT-5.6 Sol이 Terminal-Bench 2.1에서 88.8%, GPT-5.5가 85.6%라고 보고한다.

GPT-6 Astra에서는 Terminal-Bench가 이미 4.0 버전으로 넘어갔다. 여기서 OpenAI는 Astra 57.9%, Sol 37.3%를 제시한다. 이 값은 과거 Release의 Terminal-Bench 2.0이나 2.1과 연속된 역사적 선으로 비교해서는 안 된다. 반면 이름이 그대로 유지된 DeepSWE v1.1에서 같은 최신 OpenAI Evaluation의 Astra와 Sol은 각각 74.1%, 72.7%로 훨씬 가깝다.

중요한 경제적 교훈은 이것이다.

Capability는 크게 올라가면서도 List Price는 그대로이거나 오히려 내려갈 수 있다.

특정 모델의 오늘 Price-Performance Ratio에만 기반한 Business Case는 결국 하나의 Snapshot이다.

작은 Capability 상승이 큰 Agentic Effect를 만들 수 있다

Benchmark가 몇 퍼센트포인트 오르는 것은 때로 그다지 극적으로 보이지 않는다. 하지만 긴 Agentic Flow에서는 Local Reliability의 작은 개선이 훨씬 큰 전체 효과를 낼 수 있다.

순수한 사고 실험으로, 중요한 결정이 10개 있는 Workflow를 생각해보자. 각 결정이 서로 독립이고 90% 확률로 맞는다고 가정하면:

0.9^10 ≈ 35%

97%라면:

0.97^10 ≈ 74%

이것은 실제 Agent를 이런 식으로 수학적으로 모델링할 수 있다는 뜻이 명백히 아니다. 실제 결정은 서로 독립적이지도 않고 난이도가 같지도 않다. 어떤 오류는 뒤에서 수정할 수 있고, 어떤 오류는 여러 후속 단계를 동시에 오염시킨다.

이 모델은 한 가지 Mechanism만 설명한다. Decision Chain이 길수록, Reliability의 작은 추가 개선이 Human Intervention 없이 전체 Workflow를 끝까지 완료할 확률에 더 크게 영향을 줄 수 있다는 점이다.

그래서 어떤 Model Generation은 Benchmark가 조금 오른 것뿐인데도 주관적으로는 “양자 도약”처럼 느껴질 수 있다. 모든 개선이 한 번의 답변 품질이 극적으로 좋아지는 형태로 나타나는 것은 아니다. 때로는 일곱 번째 Tool Call 이후 Agent가 더 이상 원래 Task에서 Drift하지 않는 것이 진짜 차이다.

Agentic Capability는 모델 Reliability의 비교적 작은 개선에도 비선형적으로 반응할 수 있다.

그 순간부터 명목상 더 비싼 모델이 오히려 훨씬 적은 Human Active Time을 요구할 수 있다.

880억 Tokens는 놀라울 만큼 적은 정보를 준다

현재 고용주는 한 Quarterly Meeting에서 한 분기에 약 880억 Tokens를 사용했다고 자랑스럽게 발표한 적이 있다. 회사 전체는 대략 1,000명 규모다.

첫 생각은 이랬다. 굉장히 많아 보인다.

두 번째 생각이 더 중요했다. 이 숫자는 실제로 무엇을 의미하는가?

Input Tokens인가? Cached Input인가? Output인가? Reasoning인가? Coding Agents인가? 다른 AI Workloads인가? 큰 Repository Context가 반복해서 로딩된 것인가? 매우 효율적인 자동화 Workflow인가? 아니면 비싼 Agent Loop가 필요 이상으로 자주 돈 것인가?

현재 Sol과 Astra의 List Price만 적용해도 Token 숫자 하나가 비용에 대해 얼마나 적은 정보를 주는지 알 수 있다.

880억 Tokens는 1M Token 단위로 88,000개다.

880억 Tokens가 전부 다음 유형이었다고 가정하면…	대략적 비용
Sol Cached Input, $0.40 / 1M	$35,200
Sol Input, $4 / 1M	$352,000
Astra Input, $10 / 1M	$880,000
Sol Output, $20 / 1M	$1,760,000
Astra Output, $50 / 1M	$4,400,000

계산에는 2026년 9월 10일 OpenAI 공식 가격을 사용했다.

물론 어느 극단도 현실적이지 않다. 실제 Workload는 서로 다른 Token Category, Models, Cache Rates, 추가 Tool Costs가 섞인다.

바로 그래서 이 표가 의미가 있다.

같은 880억 Tokens가 이 경계 시나리오에서는 약 $35,000에서 $4.4M까지 달라진다. 125배 차이다.

그리고 실제 비용을 정확히 알더라도 그 사용이 경제적으로 타당했는지는 여전히 알 수 없다.

Token Consumption은 Activity Metric이지 Productivity Metric이 아니다.

880억 Tokens는 훌륭한 자동화의 신호일 수도 있다. 또는 매우 비싼 Loop가 아주 자주 돌고 있다는 신호일 수도 있다. 숫자 하나만으로는 구분할 수 없다.

Usage가 성공 KPI가 될 때

많은 조직이 아직 AI Adoption 초기에 있다. Active AI Users, Agent Runs, Generated Lines of Code, Tokens Consumed 같은 Metrics가 자연스럽게 등장하는 이유다.

이 Metrics는 쓸모없지 않다. Adoption, Infrastructure Demand, Cost Development를 설명한다.

다만 Outcome 자체와 혼동해서는 안 된다.

Usage
↓
Cost
↓
Verified Outcome
↓
Engineering Value
↓
Business Value

Token Consumption 자체가 성공 척도가 되면 이상한 Incentive가 생긴다. 같은 Change를 절반 Tokens로 만든 팀이 같은 작업에 두 배 Inference를 쓴 팀보다 Usage Dashboard에서 더 나빠 보인다.

여기서는 Goodhart’s Law가 꽤 잘 맞는다. Proxy Metric이 목표가 되는 순간 정보 가치가 떨어질 수 있다.

Engineering Dashboard라면 단순 Token 수보다 Successful Agent Runs, Accepted Change당 Retries, Human Active Time, Review Rework, Defect Escape Rate, 또는 Cost per Accepted Change 같은 값이 더 흥미롭다.

이 수준에 와야 Usage가 Production을 설명하기 시작한다.

비싼 Inference도 경제적으로는 매우 쌀 수 있다

여기까지 읽으면 “결국 AI가 생각보다 비싸다는 이야기인가?”라는 잘못된 인상을 받을 수 있다.

그렇지 않다.

절대적인 Inference Bill이 커 보여도 AI는 매우 경제적일 수 있다.

개발자 200명이 있는 조직을 가정하자. 단순 모델로 1인당 월 160시간, 개발자 시간당 Fully Loaded Cost €75를 적용한다.

그러면 분기당 이론적으로 사용할 수 있는 개발자 시간은:

200 developers
× 160 hours
× 3 months
=
96,000 developer hours

진짜 생산성 향상이 10%, 20%, 30%라면 계산상 어떻게 보일까?

생산성 가정	분기당 이론적 Released Capacity	€75/h로 평가
10%	9,600 h	€720,000
20%	19,200 h	€1,440,000
30%	28,800 h	€2,160,000

이 표 역시 전적으로 모델 계산이다.

Released Capacity는 은행 계좌의 현금이 아니다. 특정 활동 시간이 20% 줄었다고 해서 Features가 20% 늘고, Revenue가 20% 늘고, 인원이 20% 줄어드는 것은 아니다. Bottleneck은 다른 곳에 있을 수 있다. Demand가 제한적일 수 있다. 절약한 시간이 일부 사라질 수도 있다.

그래도 규모는 하나를 분명히 보여준다. 분기당 수십만 유로의 Inference Bill이 자동으로 “너무 비싼 것”은 아니다.

비싼 Inference가 비싼 인간 노동을 실제로 더 생산적으로 만든다면, 경제적으로는 놀랄 만큼 저렴할 수 있다.

핵심 한정어는 실제로다.

그리고 계산은 다시 Tokens가 아니라 Accepted Changes로 돌아온다.

Wall Clock은 Human Active Time이 아니다

Agentic Work에는 또 하나의 특성이 있다.

Agent가 분석, Implementation, Tests에 20분을 쓴다고 하자.

이 20분이 모두 Developer Cost인가?

반드시 그렇지는 않다.

그동안 화면만 바라보고 끝나기를 기다린다면 Agent Time과 내가 묶여 있는 시간은 거의 같다. 하지만 Architecture Decision을 준비하거나 Requirements를 명확히 하거나 Documentation을 읽는다면 생산적인 Overlap이 생길 수 있다.

나는 이런 시간을 Documentation, Architecture Work, AI에 대한 추가 학습에 자주 사용한다. 이것 역시 내가 Agentic Work에서 체감하는 실질적인 생산성 효과의 일부다.

그래서 세 가지 시간 개념을 구분할 필요가 있다.

Agent Time은 기계가 독립적으로 일하는 시간이다.

Human Active Time은 사람이 실제로 결정하고, 계획하고, Review하고, 수정하거나 Context를 제공해야 하는 시간이다.

Coordination Time은 그 Human Work의 일부다. Handoffs, Questions, Context Switching, 여러 Agents의 Synchronization, 그리고 자신의 Mental Model을 다시 세우는 시간이 여기에 들어간다.

Wall Clock
├── Agent Time
└── Human Active Time
    └── 그중: Coordination Time

Agent Time과 Human Active Time은 겹칠 수 있다.

그러므로 이 범주들은 단순히 더할 수 없다. Agent Time이 흐르는 동안 같은 Activity나 다른 Activity에서 Human Work가 동시에 일어날 수 있다.

경제적으로 흥미로운 변수는 Agent Runtime만이 아니다.

Agentic Work는 Task의 Duration만 줄이는 것이 아니라, 그 Duration 안에서 인간의 Attention을 다시 풀어줄 수도 있다.

물론 그렇게 풀린 Attention이 가치 있는 Work, Learning, Planning, 또는 다른 생산적 활동으로 실제 이동해야 경제적 가치가 생긴다.

기술적 Parallelism은 인간의 Parallelism이 아니다

여러 Agents를 병렬로 돌리면 완벽한 Scaling처럼 보인다.

한 Agent가 Feature를 구현한다. 두 번째가 동시에 E2E Tests를 만든다. 세 번째는 다음 Change를 이미 분석할 수도 있다.

기술적으로는 인상적이다.

인지적으로는 금방 불편해질 수 있다.

나는 개인적으로 아주 단순한 원칙을 갖고 있다. “한 가지에 집중하고 제대로 한다.” 보편 법칙은 아니다. 내가 복잡한 Engineering Work를 가장 신뢰성 있게 처리하는 방식일 뿐이다.

인지 연구는 적어도 이 뒤의 Mechanism을 뒷받침한다. Task Switching 연구는 안정적인 Task Focus와 Task 사이를 이동할 때 필요한 Cognitive Flexibility를 구분한다. Interruptions에 대한 Reviews는 Primary Task의 Resumption Time과 Accuracy 등에 측정 가능한 영향을 보여준다. 그렇다고 인간이 “Multitasking을 못 한다”는 뜻은 아니다. 다만 전환과 재개에는 Cognitive Cost가 있다는 뜻이다.

Agentic Work에서는 이것이 중요하다.

기계는 세 개 Workstreams를 병렬 실행할 수 있다. 하지만 개발자는 서로 다른 세 가지 System State, Solution Space, Open Decisions를 머릿속에 들고 있어야 할 수 있다.

Agentic Parallelism은 기술적으로 싸다. Human Parallelism은 인지적으로 공짜가 아니다.

그래서 유용하게 병렬화할 수 있는 Agent 수가 Compute와 자동으로 비례하지 않는다.

같은 Solution Space 안의 Parallelism이 더 잘 작동한다

내 경험에서는 병렬 활동이 같은 문제 주변을 돌 때 훨씬 잘 작동한다.

예를 들면:

Feature
├ Implementation Agent
├ E2E Agent
├ Review Agent
└ Human: Architecture and Acceptance

모든 참여자가 같은 업무적 Context 안에 있다. Implementation Agent가 Decision을 내리면 Review Agent가 바로 그 결정을 검증한다. E2E Agent도 같은 Flow를 테스트한다. 나는 하나의 System Model만 활성 상태로 유지하면 된다.

세 Agents가 동시에 서로 전혀 다른 세 Features를 바꾸면 훨씬 어려워진다. Technical Parallelism은 계속 오를 수 있지만 Human Active Time과 Coordination Time은 비례 이상으로 커질 수 있다.

여기서 실무적 Hypothesis 하나가 나온다.

Agentic Parallelism은 기계가 같은 문제의 다른 부분을 맡으면서도 인간에게 여러 System Models를 동시에 열어두라고 강요하지 않을 때 특히 가치가 크다.

따라서 최적 Agent 수는 단순한 Infrastructure Question이 아니다. 결과물을 의미 있게 Coordination하고 Verification할 인간의 능력에도 달려 있다.

진짜 투자 대상은 Agent Infrastructure다

Agentic Work를 Running Token Cost만으로 보면 또 다른 큰 비용 항목을 놓친다. Agents가 신뢰성 있게 일할 수 있는 Environment를 만드는 비용이다.

나는 이제 의도적으로 Agent Implementation에 직접 개입하는 일을 가능한 줄이려고 한다. 나쁜 Agent Run을 매번 수동으로 구조하는 것이 목표가 아니다.

대신 다음 Run을 더 좋게 만드는 구조에 투자한다.

• Agent Files와 Skills,
• 명확한 Architecture Rules와 Module Boundaries,
• 이해하기 쉬운 Slicing,
• 안정적인 Contracts,
• Automated Tests,
• 실행 가능한 Architecture / Quality Checks,
• 명확한 Review Rules,
• 일관된 Naming과 Project Structure.

그러면 Focus 자체가 이동한다.

직접 Implementation을 쓰는 시간은 줄고 Architecture, Solution Design, Constraints, Inspiration, Review, Agent Enablement에 더 많은 시간을 쓴다. 예전부터 좋아하지 않던 일, 예를 들어 Ticket을 깔끔하고 완전하게 쓰는 일조차 AI가 내가 즉석에서 하는 것보다 더 구조적으로 처리하는 경우가 많다.

나는 Agentic Work를 완벽하게 다룬다고 주장하지 않는다. 오히려 반대다. 현재 내 일의 일부는 잘 설계된 Flow가 실제로 어디까지 갈 수 있는지 알아보는 것이다.

하지만 한 가지 변화는 점점 분명하다. 장기적으로 가장 중요한 Prompt는 다음 Change를 만드는 Prompt가 아닐 수도 있다. 비슷한 Changes 백 개를 신뢰성 있게 만들어내는 Infrastructure가 더 중요할 수 있다.

코드에서의 최대한의 지루함

내가 원하는 반복 가능한 Agent Work의 목표는 최대 Creativity가 아니다.

가능한 한 많은 지루함이다.

비슷한 문제는 구조적으로 비슷한 Solution을 만들어야 한다. 새로운 Capability는 예상한 위치에 있어야 한다. API Access는 이전과 같은 Rule을 따라야 한다. State Management는 Feature마다 새로 발명되어서는 안 된다.

이건 인간 팀에도 이미 가치 있다. Agents와 함께라면 경제적으로 더 흥미롭다.

Repeatability가 Implementation Time만 줄이는 것이 아니기 때문이다.

Verification Cost도 줄인다.

Change의 Structure가 어느 정도 예상 가능하면 더 빨리 읽을 수 있다. Tests를 더 정확하게 설계할 수 있다. Architecture Rules를 기계적으로 검사할 수 있다. Surprises가 줄어든다.

Repeatability는 Implementation Cost뿐 아니라 Verification Cost도 낮춘다.

이것은 Agentic Work의 Cost Function을 바꾼다.

아주 단순화해 Agent Instructions, Architecture Rules, Test Infrastructure, Review Automation에 일회성 €10,000을 투자한다고 해보자. 이를 20개의 Accepted Changes에 나누면 Change당 €500의 선행 비용이다. 50개라면 €200, 100개라면 €100이다.

Agent Files
+ Skills
+ Architecture Rules
+ Test Infrastructure
+ Review Setup
=
높은 선행 비용

          ↓

20 Changes → €500 / Change
50 Changes → €200 / Change
100 Changes → €100 / Change

이것도 숫자 예시에 불과하다. 그러나 Mechanism은 전형적인 Fixed-Cost Economics와 같다. 선행 투자 비용은 크지만 반복 가능한 생산의 Marginal Cost는 이후 낮아질 수 있다.

Agentic Work는 일회성 Prompt Work가 재사용 가능한 Production Logic으로 바뀔 때 특히 경제적으로 흥미로워진다.

장기적으로는 개별 Prompt 하나가 얼마나 영리했느냐보다 이쪽에 더 큰 잠재력이 있다고 본다.

Local Models는 다른 비용 함수를 가진다

Cloud Models에는 편리한 특징이 하나 있다. Usage가 대부분 Variable Cost로 이어진다. Tokens를 10배 처리하면 Bill도 대체로 그만큼 커진다.

Local Inference는 Cost Structure를 바꾼다.

지속적인 Provider Price 대신 Hardware Investment, Depreciation, Electricity, Maintenance, Administration, Utilization Risk가 생긴다.

2026년 9월의 구체적인 예로 NVIDIA DGX Spark에서 Qwen3.8-27B를 생각해보자. 공식 Qwen Model은 Apache 2.0으로 공개되어 있다. NVIDIA가 공개한 DGX Spark 사양은 128 GB Unified Memory, 273 GB/s Memory Bandwidth, 140 W TDP의 GB10, 240 W Power Supply다. 현재 미국 List Price는 $4,699다.

기준일 시점에는 이 하드웨어에서 Qwen3.8-27B의 실제 속도를 일반적인 Throughput으로 사용할 만한 Manufacturer Figure가 없다. 명확히 Community Benchmark라고 표시된 한 측정에서는 NVFP4+MTP, Single-Stream Decode에서 약 25.1 Tokens/s를 보고한다. 이는 NVIDIA나 Qwen의 보장이 아니며 Runtime, Quantization, Context Length, Configuration에 따라 크게 달라질 수 있다.

그래도 투명한 모델 계산에는 사용할 수 있다.

가정:

Hardware:              $4,699
Depreciation:          3 years
Working days:          220 / year
Decode:                25.1 Output-Tokens/s
Electricity:           $0.30 / kWh
Power in the model:    240 W

240 W는 Power Supply 정격이며, 의도적으로 보수적인 계산값으로 사용한다. 측정된 지속 Inference 소비전력이라는 뜻은 아니다. Administration, Maintenance, Downtime, Financing, Prompt Processing, Concurrent Users는 포함하지 않는다. 이 계산은 단지 대략적인 Output-Token-Equivalent Capacity만 본다. 따라서 Cloud Output Tariff와의 직접적인 Full-Cost Comparison이 아니라 Local Hardware의 Utilization Calculation이다.

Scenario	높은 Utilization	낮은 Utilization
Active Inference	8 h / working day	1 h / working day
25.1 tok/s 기준 Output Capacity / year	약 159M Tokens	약 19.9M Tokens
3년 Output Capacity	약 477M	약 59.6M
Hardware Depreciation / 1M Output Tokens	약 $9.85	약 $78.79
가정 기준 Electricity / 1M	약 $0.80	약 $0.80
Hardware + Electricity / 1M	약 $10.65	약 $79.59

Utilization이 높으면 Local Inference는 갑자기 매우 저렴해 보인다. 낮으면 Depreciation이 지배한다.

바로 이것이 핵심이다.

Local Inference는 Variable Cloud Cost 일부를 Fixed Cost와 Utilization Risk로 바꾼다.

이 글에서는 생태학적 효율을 의도적으로 다루지 않는다. Energy Consumption은 오직 기업 비용 항목으로만 본다.

Local이 자동으로 더 싼 것은 아니다

앞의 표만 보면 또 다른 잘못된 결론을 낼 수 있다.

Local Qwen이 1M Output Tokens당 약 $11이고 Astra Cloud가 $50라면 Local이 자동으로 더 싸지 않을까?

아니다.

Qwen Token과 Astra Token은 경제적으로 같은 Product가 아니다.

작은 Local Model이 같은 Change에서 더 자주 Drift하고, 더 많은 Retries가 필요하고, 더 약한 Tests를 만들고, Review에서 더 많은 Human Active Time을 사용한다면 명목상의 Token Advantage는 사라질 수 있다.

또한 단순화한 Local 계산에는 Administration, Upgrades, Monitoring, Downtime, Runtime Tuning, Idle Hardware의 Opportunity Cost가 없다.

그래서 여기서도 같은 Metric으로 돌아온다.

Cost per Accepted Change.

높고 예측 가능한 Utilization에서는 Local이 매우 매력적일 수 있다. 단순하거나 고도로 Standardized된 Task Class라면 작은 Model이 경제적으로 최적일 수 있다.

반면 복잡하고 드문 Tasks라면 Frontier Model이 훨씬 높은 Token Price에도 전체 비용은 더 낮을 수 있다.

흥미로운 Architecture는 “Cloud or Local”이 아니라 Portfolio일 가능성이 있다.

Routine / high frequency
→ cheaper or local model

complex / high uncertainty
→ frontier model

critical
→ additional verification

Local을 전략적 옵션으로 보기

순수 Inference Calculation 외에도 Local Models는 두 가지 추가적인 경제 가치를 가질 수 있다.

첫째는 Confidentiality다. Local Model은 핵심 외부 Model Trust Boundary를 제거할 수 있다. 하지만 그것이 전체 Agentic Flow가 자동으로 Local 또는 Secure하다는 뜻은 아니다.

Agent는 여전히 Web Services, MCP Servers, Package Managers, Telemetry Systems, 다른 External APIs로 데이터를 보낼 수 있다.

그래서 Local Model과 Local Workflow는 서로 다른 주장이다.

둘째는 Strategic Optionality다. 조직이 특정 Task Classes에 Local Alternative를 운용할 수 있다면 Provider Pricing, Quotas, Product Conditions 변화에 대한 Exit Option이 생긴다.

현재 가장 싼 Production Path가 아니더라도 이 Option 자체에 가치가 있을 수 있다.

조용히 생기는 Workflow Lock-in

여기에는 약간 아이러니한 변화가 숨어 있다.

처음 팀은 이렇게 말할 수 있다.

AI Subscription이 한 달에 대략 25유로다. 거의 무시해도 될 수준이다.

몇 년 뒤에는 Architecture, Delivery Processes, Team Sizes, Review Flows, Throughput Expectations가 영구적인 Inference를 전제로 설계되어 있을 수 있다.

그러면 계산은 이렇게 바뀔지도 모른다.

지금은 훨씬 비싸지만, 현재 Production Flow는 이것 없이는 돌아가지 않는다.

이 현상에는 Provider의 악의가 필요하지 않다.

정상적인 경제 메커니즘이다. 기술이 Production Process에 깊게 들어갈수록 Switching Cost는 커질 수 있다. Agent Files, Tooling, Prompt Caches, APIs, Evaluations, Organizational Workflows도 특정 Models에 맞게 최적화될 수 있다.

Agentic Work가 Production System에 깊이 통합될수록 실제 Switching Cost는 더 커질 수 있다.

장기적으로는 오늘 Token Price뿐 아니라, 이미 Continuous Inference에 의존하는 조직의 Price Elasticity도 중요한 숫자일 수 있다.

Consumer Subscription은 가격 착시를 만든다

Consumer Subscription은 Enterprise Cost Calculation의 기준으로도 한계가 크다.

ChatGPT Plus는 미국에서 여전히 월 $20다. 세금과 결제 방식에 따라 지역 가격은 다를 수 있다. OpenAI는 현재 $100과 $200의 Pro Tier도 제공한다. 현재 Product Information에 따르면 Pro $100은 Plus의 5배, Pro $200은 20배 Usage Volume을 제공한다. API Usage는 별도다.

여기서 보장된 “API Equivalent Value”를 계산할 수는 없다.

어떤 사용자는 한 달에 Inference를 거의 쓰지 않는다. Heavy User는 훨씬 많은 Usage를 만들 수 있다. Rate Limits, Product Quotas, Caching, Different Models, Internal Routing Mechanisms도 비용 구조를 바꾼다.

Public API List Price도 Provider가 내부적으로 Inference를 생산하는 Marginal Cost와 같지 않다.

그래서 합리적인 Hypothesis는 Subscription Product가 Portfolio Economics로 성립할 수 있다는 것이다. 어떤 사용자는 API List Price 기준으로 Subscription Fee보다 훨씬 큰 Usage Equivalent를 만들고, 다른 사용자는 Quota를 거의 쓰지 않는다. Caching과 Rate Limits도 실제 Cost Structure를 더 바꾼다.

이것만으로 Provider의 실제 Internal Margin을 알 수는 없다.

조직에 필요한 결론은 더 단순하다. Consumer Subscription은 Production Process의 신뢰할 수 있는 비용 모델이 아니다.

Accepted Change에서 Organization으로

지금까지는 운영 관점이었다.

Model은 얼마인가? 몇 Runs가 필요한가? Human Active Time은 얼마나 남는가? Review Effort는 얼마인가? Accepted Changes는 몇 개 나오는가?

이 정도만으로도 단기 Agentic Economics의 상당 부분을 설명할 수 있다.

하지만 두 번째 Balance Sheet가 있다.

AI가 실행의 더 큰 부분을 지속적으로 맡게 되면, 단일 Change의 Cost Structure뿐 아니라 사람들이 경험을 쌓는 방식도 바뀔 수 있다.

그 지점에서 훨씬 느리게 움직이는 경제 변수, Human Capital이 등장한다.

Entry-Level Hiring은 실제로 압박을 받고 있다 – 하지만 AI만의 문제는 아니다

Junior 문제는 이제 AI 논의와 완전히 분리하기 어렵다.

동시에 Observation과 Causality를 매우 신중하게 구분해야 한다.

미국에서는 2026년 8월 개정된 Stanford Working Paper **“Canaries in the Coal Mine?”**이 수백만 명의 행정 ADP Payroll Data를 이용해 눈에 띄는 상관관계를 보여준다. 22~25세의 Highly AI-Exposed Occupations 종사자는 이 연구의 비교 방식에서 비슷한 연령의 Less AI-Exposed Occupations 종사자 경로보다 Employment가 약 19% 낮다. Experienced Workers에서는 같은 Gap이 발견되지 않는다. 특히 중요한 점은, 연구에 따르면 조정이 주로 더 적은 Hiring을 통해 나타나며 Increased Separations를 통해 나타나지 않는다는 것이다. 또한 실제 AI Usage가 Complementary보다 Automating에 가까운 Occupations에서 하락이 더 강하다.

이것은 흥미로운 Pattern에 대한 강한 Descriptive Signal이지만, 단일 원인으로서 AI를 입증하는 Causal Proof는 명백히 아니다. 저자들도 비판 이후 이전 버전을 다시 검토했고, 초기 하락의 일부는 다른 원인일 가능성이 있다고 인정했다. 더 엄격한 Controls에서는 시간적 관계가 2024년 이후에야 더 선명해진다.

다른 데이터도 주의를 요구한다. LinkedIn Economic Graph는 2026년 2월 Software Engineering의 Entry-Level Hiring이 broader Technology Sector 및 미국 Labor Market과 비슷하게 움직였다고 보고했다. 따라서 LinkedIn은 당시 SWE 하락을 주로 더 넓은 Macroeconomic Weakness의 일부로 해석했고, 고립된 AI Effect로 보지 않았다. 동시에 이 데이터에서 2023~2024년 미국 Computer Science 졸업생의 55%는 첫 Full-Time Job을 전통적인 Software Engineering Roles 밖에서 시작했다. 2016년에는 49%였다.

두 사실은 동시에 참일 수 있다. Tech Labor Market 자체가 Cycle상 약할 수 있고, 그 안에서 AI가 특정 Entry-Level Tasks에 추가 압력을 줄 수도 있다.

독일은 추가로 경기 순환적인 IT 문제를 안고 있다

미국 데이터를 독일에 그대로 적용해서는 안 된다.

독일 Bundesagentur für Arbeit는 2025년 ICT Labor Market의 수요가 확연히 약해졌다고 설명한다. 연평균 약 13,000개의 Open ICT Positions가 등록되었고, 이는 전년보다 22% 적으며 2015년 이후 최저 수준이다. 직종별 Unemployment Rate는 3.7%에서 4.5%로 올랐다. 동시에 Social-Security-Contribution ICT Employment는 약 115만 명으로 전년보다 2% 늘었다.

그러므로 그림은 “IT가 붕괴한다”가 아니다.

더 정확히는 장기 Employment는 아직 성장하지만, 단기 New Hiring과 Open Positions는 크게 약해졌고 Demand는 더 높은 자격의 Specialists와 Experts 쪽으로 이동하고 있다.

이 데이터만으로 AI Effect를 말할 수는 없다.

하지만 Juniors에게 Mechanism은 여전히 중요하다. 기업이 약한 시장에서 이미 Hiring을 줄이고 있는 상황에서 Senior-plus-Agent Configuration으로 Productivity까지 높아진다면, Entry-Level Opening을 애초에 만들지 않는 것이 경제적으로 쉬워진다.

노동시장은 대량 Layoff 없이도 아래에서부터 줄어들 수 있다

AI와 노동시장에 대한 공개 논의는 흔히 극적인 사건을 찾는다.

어떤 직업이 대체되었나? 몇 명이 Layoff되었나? 대규모 Automation Wave는 어디에 있나?

실제 영향의 일부는 훨씬 눈에 띄지 않을 수 있다.

애초에 공고되지 않은 Position은 Layoff Statistic에 나타나지 않는다.

기존 팀의 Productivity가 높아져 만들어지지 않은 추가 Junior Team도 Termination Letter를 만들지 않는다.

그래서 Stanford의 Hiring vs. Separations 결과가 흥미롭다.

Hypothesis는 다음이 아니다.

AI가 갑자기 Software Developer라는 직업을 파괴한다.

오히려:

조정의 일부는 특정 Entry Opportunity가 아예 생기지 않는 형태로 나타날 수 있다.

개별 회사 입장에서는 단기적으로 완전히 합리적일 수 있다.

하지만 장기적으로는 다른 경제 질문이 생긴다.

Senior + Agent는 단기적으로 매우 합리적인 조합이다

Experienced Developer는 이미 구축된 Mental Model을 가지고 있다.

Requirement가 불명확한 지점을 더 빨리 본다. Typical Failure Patterns를 안다. 예쁜 Diff와 Robust Solution을 구분한다. 추가 Tests가 필요한 곳과 Proposed Architecture의 Complexity가 과도한 곳을 판단한다.

강력한 Agent는 바로 그 개발자에게 빠른 Execution을 추가한다.

그 결과 매우 매력적인 조합이 나온다.

experience
+
high generation speed
+
automated tests
+
fast iterations
=
high short-term output

회사 입장에서 “그렇다면 왜 Junior를 채용해야 하지?”라는 질문은 이상하지 않다.

Junior는 Onboarding, Mentoring, Review가 필요하다. 그리고 예전에 Beginners가 Productive Contribution을 만들던 Tasks, 즉 Boundaries가 명확한 Implementation, Standard CRUD, Tests, Simple Refactorings는 동시에 Coding Agents가 빠르게 좋아지고 있는 영역이다.

도덕 판단은 필요하지 않다.

단기적으로 Senior + Agent가 경제적으로 더 매력적인 단위일 수 있다.

문제는 오직 단기만 계산할 때 시작된다.

Junior Task는 두 가지를 생산한다

Junior Task는 최소 두 가지 Output을 만든다.

Junior Task
├ Software today
└ Experience tomorrow

첫 번째는 명확하다. Endpoint, Form, Test, Migration, Bugfix가 만들어진다.

두 번째는 거의 어떤 Delivery Metric에도 나타나지 않는다.

Junior는 이 과정에서 시스템이 어떻게 작동하는지 배운다.

실수하고 왜 잘못됐는지 이해한다. Review에서 겉보기에 Elegant한 Abstraction이 왜 나중에 문제가 되는지 배운다. Production Failure를 Debug한다. Business Exception이 Technical Architecture를 어떻게 바꾸는지 본다. 시간이 지나면 더 큰 시스템 범위와 더 많은 Responsibility를 맡는다.

Junior Task는 소프트웨어만 생산하지 않는다. 경험도 생산한다.

AI가 첫 번째 생산을 더 효율적으로 맡는다면 단기적으로 매우 좋은 일일 수 있다.

하지만 그와 함께 두 번째 생산 과정도 사라진다면 Token Calculation에는 없는 장기 Cost Item이 생긴다.

경험은 Human Capital이다

경험은 Documentation을 읽는 것만으로 완전히 대체되지 않는다.

실제 시스템을 반복해서 겪으며 만들어진다.

Implement
→ Make mistakes
→ Debug
→ Receive review
→ Experience production
→ Make decisions
→ Take responsibility
→ Build system understanding

그렇다고 Junior가 “진짜 개발자”가 되기 위해 10년 동안 CRUD를 손으로 써야 한다는 뜻은 아니다.

그런 생각은 오히려 진보에 반대하는 주장에 가깝다.

AI가 Routine Work를 맡는다면 Training을 일부러 비효율적으로 유지할 필요는 없다. 더 흥미로운 질문은 이것이다.

과거의 Practice Surface 중 점점 많은 부분이 자동화될 때, 사람은 어떻게 Systemic Engineering Judgment를 쌓는가?

Agents가 오히려 도울 수도 있다. Code를 설명하고, Alternatives를 보여주고, Reviews를 시뮬레이션하고, Learning Loops를 빠르게 만들 수 있다.

하지만 Agent가 Task를 완전히 대신 수행한다는 사실만으로 이런 학습이 자동으로 생기지는 않는다.

회사는 경험을 살 수 있지만, 시장은 경험을 만들어야 한다

내게 이 문제는 Agentic Economics의 가장 흥미로운 장기 질문 중 하나다.

개별 회사는 이렇게 말할 수 있다.

우리는 Juniors가 필요 없다. Experienced Developers를 채용한다.

완전히 합리적일 수 있다.

다음 회사도 같은 선택을 할 수 있다.

그다음 회사도 그렇다.

어느 순간 Coordination Problem이 생긴다.

회사는 경험을 살 수 있다. 노동시장은 경험을 만들어야만 한다.

Senior를 채용한다는 것은 수년간의 투자 결과를 사는 일이다. Education, Mentoring, Projects, Mistakes, Reviews, Responsibility가 그 안에 있다. 그 비용은 종종 다른 회사들이 지불했다.

많은 조직이 동시에 Juniors를 덜 채용하고, Mid-Level Engineers를 덜 성장시키고, 이미 완성된 Experience만 사려고 하면 노동시장은 장기적으로 더 적은 경험을 생산할 수 있다.

이것은 명확하게 Hypothesis다. 2036년에 갑자기 Seniors가 사라질 것이라는 예측이 아니다.

Markets는 반응한다. Training Models도 바뀐다. New Roles도 생긴다. AI 자체가 Learning Tool이 될 수도 있다.

그래도 경제 질문은 남는다.

완성된 경험만 사고 싶은 조직은 누군가가 먼저 그 경험의 비용을 지불했다는 사실에 의존한다.

새로운 기술 조건 아래의 고전적인 Human-Capital Economics다.

Turnover는 Capability Building을 무의미하게 만들지 않는다

Junior Talent에 투자하는 것에 대한 흔한 반론은 어차피 직원이 회사를 떠난다는 것이다.

사실이지만 설득력 있는 반론은 아니다.

대략적인 참고치로, U.S. Bureau of Labor Statistics는 2024년 1월 Computer and Mathematical Occupations의 현재 Employer Median Tenure를 4.3년으로 보고한다. 이것은 Global Software Developer Turnover Rate가 아니며 Remote vs. Office에 대한 수치도 아니다. 단지 수년간의 Tenure가 드문 일이 아니지만 Lifetime Loyalty도 기대할 수 없다는 정도를 보여준다.

Working Conditions도 Retention에 영향을 준다. 중국 기술기업 직원 1,612명을 대상으로 한 Peer-Reviewed Nature RCT는 주 2일 Work From Home이 Resignation Rate를 약 3분의 1 줄였고, Performance나 Promotion에 측정 가능한 악화가 없었다고 보고한다. 특정 Setting에서는 강한 결과지만 역시 “Remote Employee는 X년 더 머문다”는 보편 공식은 아니다.

사람은 회사를 옮긴다.

그래도 재직 중에는 Domain Knowledge, System Knowledge, Relationships, Productivity가 쌓인다.

Turnover는 Capability Building에 반대하는 근거가 아니다. 오히려 조직이 Capability를 지속적으로 재생산해야 하는 이유다.

경험을 전부 외부에서만 사는 회사는 자신이 공급 형성에 참여하지 않는 시장에 더 의존하게 된다.

Nachwuchs 개발은 자선이 아니라 투자다

그래서 Junior 문제를 주로 도덕적으로 프레이밍할 필요도 없다.

“기업은 사회적 책임으로 Juniors를 채용해야 한다”는 것은 다른 논점이다.

경제적 관점에서는 이것만으로 충분하다.

Junior Talent Development는 Future Capability에 대한 투자다.

이 투자는 Company-Specific Knowledge, Domain Understanding, Technical Succession, Team Relationships, 내부 Responsibility Pipeline을 만든다.

물론 잘 키운 직원이 떠날 수 있다.

Database도 Migration될 수 있고, Server도 Depreciate되고, Platform도 교체된다. 어떤 투자도 영구적인 가치를 보장하지 않는다.

중요한 것은 Expected Value가 시간이 지나도 Investment보다 높은가다.

Agentic Work는 바로 이 계산을 바꾼다. 단순 Junior Tasks의 Direct Production Value는 낮아질 수 있지만 Training Value는 남을 수 있다.

따라서 Training은 과거보다 더 명시적으로 Production System의 일부가 되어야 한다.

교육은 바뀌어야 한다

AI에 대응해 “전통적인 Coding을 더 많이 하자”고 주장하는 것은 그다지 의미가 없다.

Agents가 Code를 신뢰성 있게 생성할 수 있다면 사람은 그 현실과 생산적으로 일하는 법을 배워야 한다.

하지만 그것은 “Prompt Engineering” 과목 하나를 더 추가하는 것보다 훨씬 크다.

Programming Education에서 GenAI를 사용하는 Systematic Reviews는 혼합된 결과를 보여준다. AI는 Learning Performance, Feedback, Problem Solving을 도울 수 있다. 동시에 Overreliance, Incorrect Outputs, 그리고 생성된 Solution을 실제로 Verification할 능력 차이에서 위험이 생긴다. 2025년에 발표된 40개 Empirical Studies Review는 그래서 의도적인 Pedagogical Integration과 Appropriate Assessments의 중요성을 강조한다. 2026년 9월 Heliyon에 발표된 76개 Empirical Studies Review도 AI가 Scaffolding, Process-Oriented Feedback, Human Judgment와 결합될 때 특히 유용하다는 비슷한 결론을 내린다.

Software Engineering 교육은 전체 Production Flow에서 필요한 역량에 더 큰 비중을 둘 수 있다. Problem Understanding, Requirements, System Models, Architecture, Debugging, Review, Trade-offs, Security Awareness, Verification, End-to-End Responsibility가 그것이다.

Coding이 사라지는 것은 아니다.

Code를 읽을 수 없는 사람은 제대로 Review하기 어렵다. 왜 특정 Implementation이 실패하는지 직접 겪어본 적 없는 사람은 Engineering Judgment를 쌓을 기반이 부족하다.

하지만 비중은 달라질 수 있다.

나도 개인적인 환경에서 이 Gap을 본다. 가족 중 한 명이 Semester Project에서 Software Architecture Structure에 대해 매우 좋은 평가를 받은 적이 있다. 하지만 그 Structure에 필요한 Architecture Understanding은 학교 수업 자체보다, 상당 부분 일상적인 Architecture 대화에서 형성되었다.

이건 개인 Anecdote이며 어떤 특정 대학 프로그램의 품질을 증명하지 않는다.

내게는 단지 이런 질문을 보여준다. Technical Execution을 얻는 일이 점점 쉬워질 때, 우리는 과연 좋은 시스템을 인식하고 설계하는 능력을 얼마나 체계적으로 가르치고 있는가?

Specialist에서 End-to-End Understanding으로

Agentic Work의 긍정적 가능성 중 하나는 개발자가 완전한 Flow를 따라 더 넓게 일할 수 있다는 점이다.

DB
→ Service
→ API
→ Client
→ View

모든 Frontend Developer가 갑자기 Database, Backend, Networking, Security, UX Specialist가 되어야 한다는 뜻은 아니다.

Agents는 일부 기술적 Execution을 맡을 수 있다.

그럴수록 Meta-Model이 더 중요해진다.

Frontend Developer가 Backend Specialist와 같은 깊이로 CQRS-Oriented 또는 Hexagonal Microservice를 직접 Implementation할 필요는 없을 수 있다. 하지만 Agent와 함께 작업한다면 각 Layer의 Responsibility, Domain Logic이 어디에 있어야 하는지, Contract가 어떻게 동작하는지, 생성된 Code가 구조적으로 Plausible한지는 이해할 수 있어야 한다.

반대 방향도 마찬가지다.

Agentic Work는 Expert Knowledge를 없애지 않으면서 End-to-End Responsibility를 넓힐 수 있다.

특히 Security, Cryptography, Highly Critical Business Domains는 Generalist가 충분한 AI Support만 있으면 모든 전문 깊이를 대체할 수 있다는 생각과 잘 맞지 않는다.

Agentic Work는 기술적 Execution의 폭을 넓힐 수 있지만, 깊은 Expertise를 불필요하게 만들지는 않는다.

미래의 강한 팀은 넓은 System Model을 가진 사람들과, 경제적으로나 안전 측면에서 실제 Depth가 필요한 곳에 깊이를 제공하는 Specialists로 구성될지도 모른다.

Software Engineering의 무게중심은 이동하고 있다

나는 지금 의도적으로 직접 Code를 가능한 한 적게 쓰려고 한다. Coding이 가치 없다고 보기 때문이 아니라, 잘 설계된 Agentic Flow가 실제로 어디까지 갈 수 있는지 알고 싶기 때문이다.

이미 내 업무는 상당히 달라지고 있다. Direct Code Production에 쓰는 시간은 줄고 Architecture, Solution Design, Constraints, Reviews, Agent Infrastructure, System Understanding에 쓰는 시간은 늘어난다. 나는 이것을 Software Engineering에서 후퇴하는 것으로 보지 않고, 그 안에서 무게중심이 이동하는 것으로 본다.

Agent가 Method를 Implementation할 수 있다. 나는 Agent가 애초에 합리적인 Solution이 나올 확률이 높은 공간 안에서만 일하도록 만드는 데 더 집중한다. 명확한 Module Boundaries, Tests, Architecture Rules, Mechanical Checks가 여기에 들어간다. 하지만 자동 생성 Solution이 Build Green이면서도 Wrong Abstraction을 사용했는지 알아보는 능력도 필요하다.

나는 Agentic Work를 매우 강력한 Tool이라고 생각한다. 동시에 내가 이미 완벽하게 다룬다고 주장하지도 않는다. 바로 그래서 두 작업 방식의 차이가 더 잘 보인다. AI를 더 빠른 Autocomplete로 쓰는 것과, Agents가 독립적으로 Analyze, Implement, Test, Review할 수 있는 Engineering System을 만드는 것은 완전히 다르다. 두 번째 방식에는 훨씬 더 많은 Upfront Investment가 필요하다. 그러나 전혀 다른 Cost Structure도 가능하게 한다.

두 개의 경제적 Balance Sheet

결국 서로 분리되어 있지만 연결된 두 개의 경제적 계산이 남는다.

첫 번째는 운영적이다.

질문은 이렇다.

검증되고 Accepted된 Change 하나의 비용은 얼마인가?

이 계산에는 Model Prices, Input / Output, Caching, Reasoning, Tool Calls, Failed Runs, Retries, Tests, Review, Human Active Time, Coordination Time이 들어가야 한다.

종착점은:

Cost per Accepted Change

두 번째는 전략적이다.

질문은 이렇다.

이 Change 이후 조직은 어떤 Capability를 보유하고 있으며, 미래를 위해 어떤 Capability를 만들고 있는가?

여기에는 Agent Infrastructure, System Understanding, Domain Knowledge, Junior Development, Expert Knowledge, Capability를 지속적으로 재생산하는 능력이 들어간다.

두 번째 Balance Sheet가 첫 번째를 덜 중요하게 만드는 것은 아니다.

기업은 단기적으로도 경제적으로 운영되어야 한다. 측정 가능한 Value를 만들지 못하는 Agentic Flow가 “장기적으로 전략적일 것”이라는 주장만으로 합리적이 되는 것은 아니다.

반대로 Quarterly Calculation도 불완전할 수 있다. 사라진 Junior Task를 모두 Efficiency Gain으로 계산하면서 Future Experience Building의 가치를 0으로 둔다면 그렇다.

Agentic Work의 흥미로운 경제학은 바로 이 두 Time Horizon 사이에 있다.

Token
↓
Agent Run
↓
Successful Run
↓
Accepted Change
↓
Engineering Capability
↓
Business Value
↓
Future Capability

Models는 계속 더 싸졌다가, 더 비싸졌다가, 다시 싸질 것이다. Capability는 올라갈 것이다. 어떤 Tasks는 거의 완전히 자동화될 것이다. 다른 Tasks는 놀랄 만큼 자동화에 저항할 것이다. New Ways of Working이 생길 것이고, 오늘 Token Price를 두고 하는 일부 논쟁은 나중에 보면 예전의 Cloud Storage 1GB 가격 논쟁만큼이나 낡아 보일 수 있다.

하지만 경제 Mechanism은 남는다.

Code Generation은 하나의 Production Step일 뿐이다.

Token Consumption은 하나의 Activity Measure일 뿐이다.

Inference Cost는 하나의 Cost Item일 뿐이다.

Accepted Change는 아직 Business Value가 아니다.

그리고 Short-Term Productivity는 Engineering Organization이 만들어야 하는 유일한 Capability가 아니다.

Agentic Work는 매우 경제적일 수 있다. 내 경험으로도 오늘의 시스템만으로 상당한 생산성 향상이 가능하다는 점은 분명하다. 동시에 실증 연구는 그 규모가 Context에 크게 의존하며, Local Speedup이 전체 Production System을 따라가면 훨씬 작아질 수 있음을 보여준다.

그래서 올바른 결론은 다음 둘 중 어느 것도 아니다.

AI는 Software Development를 극도로 싸게 만든다.

또는:

AI는 사실 너무 비싸다.

더 흥미로운 문장은 더 차분하다.

Agentic Work의 경제성은 Model Cost, Verification, Human Attention, Reusable Infrastructure, Long-Term Capability Building이 함께 있는 전체 시스템에서만 드러난다.

운영적으로 우리는 이렇게 물어야 한다.

검증되고 Accepted된 Change 하나는 우리에게 얼마인가?

전략적으로는 추가로 이렇게 물어야 한다.

그 과정에서 어떤 Capability를 만들고 있으며, 어떤 Capability를 줄이고 있을 수 있는가?

Code는 더 싸지고 있다. Software Engineering이 자동으로 같은 비율로 싸지는 것은 아니다.

Agentic Work의 경제학을 이해하려면 Token Price보다 더 멀리 계산해야 한다.

Token은 청구서에 보인다. Value와 일부 Long-Term Cost는 다른 곳에 있다.

출처와 맥락

이 글의 구체적인 가격과 제품 정보는 2026년 9월 10일의 Snapshot이다. 특히 Model Price, Product Name, Usage Limits, Benchmarks는 빠르게 변한다. 따라서 개별 숫자가 나중에 낡더라도 이 글의 경제적 계산 모델은 계속 읽을 수 있도록 의도했다.

OpenAI – ChatGPT Rate Card / Token-Based Pricing.
GPT-5.6 Sol, GPT-6 Astra 및 다른 모델의 현재 가격과 Long Context, Fast Mode, Regional Processing 관련 설명.
https://help.openai.com/en/articles/20001415

OpenAI – GPT-5.6 Sol.
Model Price, Promotional Rate, Context Window, 현재 Coding Evaluations 및 Efficiency 관련 설명.
https://developers.openai.com/api/docs/models/gpt-5.6-sol
https://openai.com/index/gpt-5-6/

OpenAI – GPT-6 Astra.
현재 가격과 Coding / Agentic Evaluations. 중요: Terminal-Bench 4.0은 이전 Terminal-Bench 버전의 직접적인 역사적 연속선으로 읽어서는 안 된다.
https://developers.openai.com/api/docs/models/gpt-6-astra
https://openai.com/index/gpt-6-astra/

OpenAI – Understanding and Counting Tokens.
Reasoning Tokens는 가시적인 Answer Text에는 나타나지 않지만 Output Usage에 포함되고 Output Tokens로 청구된다.
https://help.openai.com/en/articles/4936856-w

Anthropic – Claude 3.5 Sonnet, Claude 3.7 Sonnet, Sonnet 4.5, Sonnet 4.6, Sonnet 5.
Historical Comparison에 사용한 Price와 Coding Evaluations의 Primary Sources. 각 SWE-bench 결과는 일부 Harness, Prompting, Thinking Budget, Test-Time Compute가 다르므로 본문에서는 하나의 통일된 Time Series로 취급하지 않는다.
https://www.anthropic.com/news/3-5-models-and-computer-use
https://www.anthropic.com/news/claude-3-7-sonnet
https://www.anthropic.com/news/claude-sonnet-4-5
https://www.anthropic.com/news/claude-sonnet-4-6
https://www.anthropic.com/news/claude-sonnet-5

Peng et al. – “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”.
명확히 제한된 JavaScript Task를 사용한 Randomized Experiment. Copilot Group이 55.8% 더 빨리 Task를 완료했다.
https://arxiv.org/abs/2302.06590

Cui et al. – “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”.
총 4,867명 개발자를 포함한 세 개의 Randomized Field Experiments. Pooled Estimate는 완료 Tasks가 26.08% 증가. 2026년 Management Science에 게재.
https://doi.org/10.1287/mnsc.2025.00535

Demirer, Musolff, Yang – “Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools”.
NBER Working Paper 35275, 2026년 9월 개정. 현재 버전은 50만 명이 넘는 GitHub 개발자 데이터를 사용하며 Autonomous Coding Agents의 Commit-Level Effect가 실제 Releases까지 크게 약해진다고 보고한다. Working Paper이며 최종적인 Causal Consensus는 아니다.
https://www.nber.org/papers/w35275

METR – Developer Productivity Studies.
2025년 초 RCT는 숙련된 Open-Source Developers 16명과 246 Tasks를 대상으로 평균 19% Slowdown을 발견했다. METR은 현재 이 결과 자체를 Historical Snapshot으로 설명한다. 2026년 Follow-Up은 더 가속 쪽을 가리켰지만 Selection 및 Measurement Issues 때문에 정밀한 Effect Estimate는 신뢰하기 어려웠다.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
https://metr.org/blog/2026-02-24-uplift-update/

Stanford Digital Economy Lab – “Canaries in the Coal Mine?”.
ADP Payroll Data를 기반으로 한 2026년 8월 개정판. Highly AI-Exposed Occupations의 22~25세 Employment가 Less Exposed Peers보다 상당히 낮고, 차이는 주로 Lower Hiring을 통해 나타난다. 저자들은 결과를 Causal AI Estimate가 아니라 Descriptive Early Indicators라고 명시한다.
https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

LinkedIn Economic Graph – U.S. Software Engineer Talent Landscape / February 2026.
미국 SWE Hiring 부진과 CS Graduates가 Traditional Software Engineering Roles로 직접 진입하는 Pipeline 약화를 설명하는 자료.
https://economicgraph.linkedin.com/content/dam/me/economicgraph/en-us/PDF/us-software-engineer-talent-landscape-2026.pdf

German Federal Employment Agency – ICT Labor Market 2025.
연평균 약 13,000개의 Registered ICT Vacancies, 전년 대비 22% 감소; Unemployment Rate 4.5%; 동시에 약 115만 명이 ICT Occupations에서 Social-Security-Contribution Employment 중.
https://www.arbeitsagentur.de/presse/2026-24-arbeitsmarkt-in-der-informations-und-kommunikationstechnik-ikt-im-spannungsfeld-konjunkturelle-schwaeche-trifft-auf-strukturellen-wandel

U.S. Bureau of Labor Statistics – Employee Tenure 2024.
“Computer and mathematical occupations”의 현재 Employer Median Tenure 4.3년. Software-Developer-Specific 또는 Remote-Tenure Metric은 아니다.
https://www.bls.gov/news.release/tenure.t06.htm

Bloom et al. – “Hybrid working from home improves retention without damaging performance”.
Trip.com 직원 1,612명을 대상으로 한 Randomized Experiment. 주 2일 Work From Home이 실험에서 Resignation Rate를 약 3분의 1 줄였다.
https://doi.org/10.1038/s41586-024-07500-2

Nathaniel et al. – “Literature Review on the Integration of Generative AI in Programming Education”.
Programming Education에 GenAI를 통합한 40개 Empirical Studies의 Systematic Review.
https://doi.org/10.1007/s40593-025-00524-3

“Artificial intelligence in programming education: A systematic review …”, Heliyon 2026.
Programming Education에서 AI를 다룬 76개 Empirical Studies의 Systematic Review.
https://doi.org/10.1016/j.heliyon.2026.e45361

Qwen – Qwen3.8-27B.
공식 Model Weights, Apache 2.0 License, Model Information.
https://huggingface.co/Qwen/Qwen3.8-27B

NVIDIA – DGX Spark.
공식 Hardware Specs: 128 GB Unified Memory, 273 GB/s Memory Bandwidth, 140 W GB10 TDP, 240 W Power Supply. NVIDIA는 2026년 2월 MSRP를 $4,699로 인상했다.
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
https://forums.developer.nvidia.com/t/2-23-2026-price-change-announcement/361713

Qwen3.8-27B on DGX Spark – Community Benchmark.
모델 계산에 사용한 25.1 tok/s는 NVFP4 + MTP의 명시적 Community Measurement이며 Manufacturer Guarantee가 아니다. 다른 Runtime Configuration에서는 결과가 크게 달라질 수 있다.
https://axforge.ai/benchmarks/qwen-3-8-dgx-spark/

OpenAI – ChatGPT Pro tiers.
현재 미국 Product Tiers: Pro $100은 Plus의 5×, Pro $200은 20× Usage. 이 Allowances는 보장된 API Token Quantity가 아니다.
https://help.openai.com/en/articles/9793128

Stephen Monsell – Task switching (2003); Simon Y. W. Li, Farah Magrabi, Enrico Coiera – A systematic review of the psychological literature on interruption and its patient safety implications (2012).
Task 전환과 Interruption에 관한 Review 연구로, Switch Cost, Resumption Time, 오류 등을 다룬다. 이 글의 제한된 인지 Mechanism 논증을 뒷받침할 뿐, Coding Agents에 대한 구체적인 생산성 추정은 아니다. Task switching; Interruption에 대한 Review.