계속 읽기 전에 한 가지 분명히 짚고 넘어가고 싶습니다.

저는 여러분에게 어떤 도구를 팔기 위해 이 글을 쓰는 것이 아닙니다. 특정 업체로부터 라이선스를 받았기 때문에 쓰는 것도 아닙니다. 제가 이 글을 쓰는 이유는 Fintech, Healthcare, Lifesciences, MedTech, EnergyTech, InsuranceTech 분야에서 28년 동안 프로덕션 시스템 (production systems)을 출시해 왔으며, 제 팀의 엔지니어들과 나누는 대화가 아무도 솔직하게 다루지 않는 주제이기 때문입니다.

대화는 대략 이런 식입니다. 누군가 저에게 어떤 AI 코딩 도구를 사용해야 하는지 묻습니다. 제가 답변을 시작하려고 하면 그들은 저를 멈춰 세우며 말합니다. "아니요, 어떤 것이 가장 빠른지 또는 어떤 것이 특정 벤치마크 (benchmark)에서 가장 높은 점수를 받았는지를 묻는 게 아닙니다. 제 말은, 이것이 실제로 당신의 작업 방식을 바꾸나요? 당신을 더 나은 개발자로 만드나요? 아니면 그저 똑같은 일을 더 빠르게 할 뿐인가요?"

그것이 바로 제가 여기서 답하고자 하는 질문입니다. 프로덕션 (production) 현장에서, 규제 환경 (regulated environments)에서, 그리고 실제 사람들이 의존하는 실제 인프라 (infrastructure) 위에서 실행되는 실제 코드로부터 얻은 답입니다.

맥락이 중요하므로, 제 배경을 말씀드리겠습니다.

저는 규제 대상인 유틸리티 기업인 Energy Tech 회사의 엔지니어링 부문을 총괄하고 있습니다. 제가 출시하는 코드는 발전 시스템을 구동합니다. 또한 저는 AgentMesh, ARGUS, Bulwark, TorchForge와 같은 오픈 소스 (open source) AI 툴링을 구축하는 Ambharii Labs를 운영하고 있습니다. 저는 Claude Code를 매일 사용합니다. Cursor도 설치되어 있습니다. 그전에는 18개월 동안 GitHub Copilot을 사용했습니다.

저는 중립적인 관찰자는 아닙니다. 하지만 일주일 동안 할 일 목록(todo) 앱에 세 가지 도구를 돌려보고 작성한 리뷰어도 아닙니다. 제가 말씀드리려는 모든 내용은 프로덕션 코드 (production code), 팀 역학 (team dynamics), 그리고 실제 엔지니어링 조직에서 수년간 쌓이는 기술 부채 (technical debt)에 근거하고 있습니다.

이 도구들을 사용하기 시작했을 때 실제로 변한 것.

가장 먼저 변한 것은 저의 작업 속도가 아니었습니다. 그것은 제가 시간을 어디에 쓰기로 선택했느냐였습니다.

AI 코딩 도구가 없던 시절에는 제 하루의 상당 부분이 소위 '번역 작업'에 소비되었습니다. 요구사항을 받아 이를 스캐폴딩 (scaffolding)으로 변환하는 일 말입니다. 아이디어를 실제 로직과 연결하는 보일러플레이트 (boilerplate)를 작성하고, 의미 있는 테스트를 단 하나라도 작성하기 전에 테스트 하네스 (test harness)를 설정하는 일들이었습니다. 이 작업은 어렵지는 않습니다. 다만 느릴 뿐이며, 실제로 판단력이 요구되는 작업과 동일한 인지적 예산 (cognitive budget)을 소모합니다.

Claude Code는 다른 어떤 도구보다 저에게 있어 바로 그 구체적인 문제를 해결해 주었습니다. 모든 상황에서 더 똑똑하기 때문이 아닙니다. 현재의 코드 라인이 아닌 전체 작업 (task) 수준에서 작동하기 때문입니다. 저는 제가 무엇을 만들고 있는지 평이한 언어로 설명할 수 있고, 그러면 Claude Code는 유용할 정도로 충분히 근접한 스캐폴딩을 생성해 줍니다. 덕분에 저의 실제 작업은 이전보다 더 높은 수준에서 시작될 수 있습니다. Energy Tech Enterprise에서 근무할 당시, 저는 두 명의 엔지니어가 한 스프린트 (sprint) 동안 매달려야 했을 데이터 파이프라인 통합 작업을 주말 사이에 재구축하는 데 이 도구를 사용했습니다. 결과물로 나온 코드는 리뷰와 조정이 필요했습니다. 하지만 리뷰에 걸린 시간은 원래 코드를 구축하는 데 걸렸을 시간의 아주 일부분에 불과했습니다.

변하지 않은 것.

이 부분은 대부분의 리뷰에서 생략되곤 하기에, 저는 여기에 더 많은 시간을 할애하려 합니다.

판단력은 변하지 않았습니다. 구체적으로, 프로덕션 (production) 환경에 도달하기 전까지는 드러나지 않을 방식으로 AI가 틀렸을 때를 알아차리는 데 필요한 판단력 말입니다. 지난 분기에 Claude Code는 저를 위해 Redis 페일오버 (failover) 패턴을 생성해 주었는데, 이는 테스트 단계에서는 완벽하게 작동했지만 대규모 환경의 특정 레이스 컨디션 (race condition) 상황에서는 조용히 데이터를 오염시켰을 코드였습니다. 제가 이를 잡아낼 수 있었던 이유는 이전에 그런 실패 모드 (failure mode)를 본 적이 있었기 때문입니다. 어떤 테스트가 이를 감지했기 때문도 아니고, AI가 저에게 경고를 주었기 때문도 아닙니다. 28년 동안 분산 시스템 (distributed systems)이 실패하는 과정을 지켜보며 얻은 패턴 인식 (pattern recognition) 능력은 아직 그 어떤 도구도 따라올 수 없기 때문입니다.

아키텍처 (Architecture)는 변하지 않았습니다. 지난 1년 동안 제가 내린 모든 중요한 아키텍처 결정들 — ARGUS 관측성 계층 (observability layer)을 어떻게 구조화할지, Aether AI의 멀티 테넌트 격리 (multi-tenant isolation)를 어떻게 설계할지, Bulwark의 컴플라이언스 프레임워크 (compliance framework)를 어떻게 분할할지 — 은 AI와 함께한 것이 아니라 저에 의해 이루어졌습니다. AI는 구현 (implementation) 단계에서는 진정으로 유용합니다. 하지만 무엇을 만들지, 혹은 각 구성 요소들이 서로 어떻게 관계를 맺어야 하는지를 결정하는 데에는 유용하지 않습니다. 이 차이는 대부분의 사람들이 인정하고 싶어 하는 것보다 훨씬 더 중요합니다.

프로덕션 장애 (production failures)를 디버깅 (debugging)하는 방식도 변하지 않았습니다. 규제 환경에서 새벽 2시에 무언가 고장 났을 때, 중요한 기술은 불완전한 정보로부터 가설을 세우고, 자신이 완전히 구축하지 않은 시스템을 통해 인과 관계를 추적하며, 압박감 속에서 결정을 내리는 능력입니다. 저는 어떤 AI 도구도 이 기술을 향상시키는 것을 본 적이 없습니다. 오히려 엔지니어들이 생각하기보다 도구에 먼저 손을 뻗게 만듦으로써 이 과정을 더 느리게 만드는 것을 보았습니다.

데이터가 말하는 것 vs 제가 팀에서 보고 있는 것.

2026년 AI 코딩 도구에 대한 연구는 진정으로 모순적입니다.

Stanford HAI의 연구에 따르면, AI에 노출된 직무를 맡은 22세에서 25세 사이의 초기 경력 개발자들은 2022년 정점 대비 고용이 20% 감소했습니다. 주니어 개발자 채용 공고는 2022년부터 2024년까지 60% 급감했습니다. 코딩 부트캠프 (coding bootcamp) 등록률도 40% 하락했습니다.

동시에, 2026년 초 전체 소프트웨어 엔지니어링 채용 공고는 전년 대비 11% 증가했습니다. 노동통계국 (Bureau of Labor Statistics)은 여전히 2033년까지 17%의 일자리 성장을 전망하고 있습니다. 주니어 개발자 역할이 감소하는 동안 AI 엔지니어 역할은 300% 성장했습니다.

엔지니어링 조직 내부에서는 이것이 어떻게 보일까요? 저는 팀을 관리합니다. 저는 통계가 아니라 실제 채용 결정 과정에서 이러한 현상이 전개되는 것을 지켜봐 왔습니다.

우리는 이전과 같은 방식으로 주니어 역할 (junior roles)을 충원하는 것을 중단했습니다. 우리가 그렇게 하기로 결정했기 때문이 아닙니다. 계산법 (calculus)이 조용히 변했기 때문입니다. AI 도구 활용 능력이 뛰어난 시니어 엔지니어 (senior engineer)는 이제 과거에 주니어와 시니어가 함께 작업해야 했던 영역을 혼자서 커버합니다. 이것은 정책적인 결정이 아닙니다. 어떤 공표 수준 아래에서 발생하는 경제적인 결정입니다.

아무도 충분히 크게 이야기하지 않는 결과는 바로 파이프라인 (pipeline)입니다. 시니어 엔지니어는 어디에선가 옵니다. 그들은 채워지지 않고 있는 주니어 역할들로부터 옵니다. AWS CEO Matt Garman은 주니어 계층을 제거하는 것을 "내가 들어본 것 중 가장 어리석은 일 중 하나"라고 부르며, 향후 10년 동안 발생할 재앙적인 기술 격차 (skills gap)에 대해 경고했습니다. 그의 말이 맞습니다. 하지만 그러한 격차를 만드는 결정들은 악의 없이, 그리고 완전한 경제적 합리성에 따라, 정확히 제 팀과 같은 팀들에서 채용 동결 (hiring freeze)이 거듭되면서 내려지고 있습니다.

제 엔지니어들이 계속해서 던지는 질문에 대한 솔직한 답변입니다.

AI 도구가 당신을 대체 불가능하게 만들까요? 아니요. 그 어떤 것도 당신을 대체 불가능하게 만들지는 못합니다.

AI 도구가 당신을 더 생산적으로 만들까요? 네, 특정 작업들에 대해서는 그렇습니다. 스캐폴딩 (Scaffolding), 보일러플레이트 (boilerplate), 문서화 (documentation), 1차 테스트 (first-pass testing), 알려진 패턴의 리팩터링 (refactoring) 등이 그렇습니다. 생산성 향상은 실재하며 결코 작지 않습니다.

AI 도구가 당신을 대체할까요? 그것은 당신이 무엇을 하느냐에 달려 있습니다. 만약 당신의 가치가 정해진 형태를 가진 작업들을 실행하는 데 있다면 — 이 엔드포인트 (endpoint)를 작성하거나, 이 마이그레이션 (migration)을 생성하거나, 이 함수 (function)를 문서화하는 것 등 — 당신은 진정한 위험에 처해 있습니다. AI가 당신보다 그 일들을 더 잘하기 때문이 아닙니다. AI를 어떻게 지시해야 하는지 아는 엔지니어 한 명이 당신보다 더 빠르게 그 일들을 해내고, 그로 인해 당신의 역할에 대한 경제적 타당성이 침식되기 때문입니다.

만약 당신의 가치가 시스템이 왜 그렇게 작동하는지, 실패 모드 (failure modes)가 어떻게 전파되는지, 아무도 완전히 명시하지 않은 제약 조건 세트 (constraint set)에 대해 무엇이 올바른 아키텍처 (architecture)인지 이해하는 데 있다면 — 그 가치는 침식되지 않았습니다. 오히려 증가했습니다. 왜냐하면 그 능력을 갖춘 사람과 그렇지 못한 사람 사이의 격차가 이전보다 훨씬 더 눈에 띄게 되었기 때문입니다.

제가 실제로 사용하는 것과 그 이유입니다.

실제 코드베이스 이해, 다중 파일 변경(multi-file changes), 또는 시스템 수준의 추론(system-level reasoning)이 필요한 모든 작업에는 Claude Code를 사용합니다. 컨텍스트 윈도우(context window)와 메커니즘보다는 의도(intent)를 설명할 수 있는 능력은 복잡한 작업을 수행할 때 충분한 가치가 있습니다.

흐름(flow)을 유지하면서 문맥을 전환하지 않고 인라인 지원(inline assistance)을 받고 싶을 때 사용하는 데일리 드라이버(daily-driver) 편집기로는 Cursor를 사용합니다.

아키텍처 결정, 프로덕션 디버깅(production debugging), 또는 미묘하게 틀린 답변의 비용이 큰 작업에는 둘 다 사용하지 않습니다.

두 도구 앞에는 AgentMesh가 자리 잡고 있습니다. 규제 환경(regulated environment)에서 작업할 때는 AI에게 무엇을 요청했는지, 무엇을 생성했는지, 그리고 비용이 얼마나 들었는지를 추적하는 거버넌스 계층(governance layer)이 필요하기 때문입니다. 코드가 인프라를 실행하는 경우, 이는 선택 사항이 아닙니다.

아무도 묻지 않지만, 반드시 물어야 할 질문이 있습니다.

AI 코딩 도구에 대한 대부분의 대화는 개별 개발자에게 집중됩니다. '내가 이 도구를 사용해야 할까?', '이 도구가 나를 더 빠르게 만들어 줄까?'와 같은 질문 말입니다.

제가 더 중요하다고 생각하는 질문은, 이러한 도구들이 향후 10년 동안 소프트웨어 엔지니어링이라는 기술(craft)에 어떤 영향을 미칠 것인가 하는 점입니다. 오늘날 시니어(senior)인 엔지니어들은 현재 AI 도구들이 주니어 개발자들을 위해 수행하는 작업들을 직접 해보며 배웠습니다. 그들은 자신이 서투르게 작성한 코드를 디버깅했습니다. 이해하지 못하는 에러 메시지를 읽었습니다. 진단해야만 하는 방식으로 실패하는 시스템을 구축했습니다. 그러한 경험이 바로 새벽 2시 Redis 장애 조치(failover) 상황에서 레이스 컨디션(race condition)을 잡아내는 패턴 인식(pattern recognition) 능력을 구축하는 방법입니다.

만약 엔트리 레벨(entry-level) 계층이 현저히 얇아진다면 — 데이터는 실제로 얇아지고 있음을 명확히 보여줍니다 — 2036년에 시니어가 될 엔지니어들은 지금과는 다른 방식으로 형성될 것입니다. 이것이 시니어 레벨에서 더 나은 엔지니어를 만들어낼지, 아니면 더 못한 엔지니어를 만들어낼지는 아직 아무도 답을 알지 못하는 질문입니다. 저를 포함해서 말이죠.

제가 알고 있는 것은 이러한 도구들이 실재하며, 생산성 향상 또한 실재한다는 사실입니다. 그리고 그 결과는 공포나 낙관론이 시사하는 것보다 훨씬 더 복잡한 방식으로 전개되고 있습니다.

저에게는 28년 치의 데이터 포인트가 있습니다. 지금은 제가 목격한 순간 중 가장 불확실한 시기입니다. 이것은 경고가 아닙니다. 그저 현재의 관점에서 정직하게 바라본 모습일 뿐입니다.

Anil S. Prasad는 Ambharii Labs의 설립자이자 Fortune 100 에너지 기술 기업의 엔지니어링 및 제품 총괄(Head of Engineering and Product)입니다. 또한 다양한 기업, 사모펀드(Private Equity), 그리고 벤처 캐피털(VC) 지원 기업들을 대상으로 기술 및 엔지니어링 자문 역할을 수행하고 있습니다. 그는 github.com/anilatambharii 에서 AgentMesh (AI 도구를 위한 거버넌스 프록시), Bulwark (에이전트 보안 프레임워크), TorchForge (엔터프라이즈용 PyTorch 거버넌스)를 포함한 오픈 소스 AI 거버넌스(AI governance) 도구들을 구축하고 있습니다. 그는 규제 대상인 AI 배포(AI deployments) 환경에서 실제로 무엇이 문제를 일으키는지에 대해 글을 씁니다.