8배 생산성 신화 너머: 재귀적 AI와 엔지니어링의 '장인 정신'에 대한 40년의 관점

서론: 코드베이스 속의 유령

나는 1986년에 직업적 여정을 시작했습니다. 당시에는 Honeywell 시스템, Commodore 64의 시대였으며, Concurrent-CPM 환경에서 DataFlex를 사용하여 관리 소프트웨어를 개발하던 시절이었습니다. 그 당시 '연산(compute)'은 사치였습니다. 단 한 번의 컴파일에 커피를 한두 잔 마실 정도의 시간이 걸릴 수 있었기에, 우리는 코드 한 줄 한 줄을 신중하게 계획했습니다.

시간을 빠르게 돌려 2026년입니다. 나는 Anthropic의 최신 논문인 **["AI가 스스로를 구축할 때">(https://www.anthropic.com/institute/recursive-self-improvement)]**를 읽고 있습니다. 이 논문은 코드 작성, 실험 실행, 버그 식별과 같은 '수행(doing)' 작업이 자율 에이전트(autonomous agents)에게 위임되는 세상을 묘사합니다. 여전히 무언가를 만들며 정신을 활발하게 유지하고 있는 은퇴한 아키텍트로서, 나는 거대 연구소들의 생산성 지표와 지속 가능한 전문 엔지니어링의 현실 사이에 매혹적이면서도 위험한 간극이 있음을 봅니다.

1. "8배 생산성"의 환상

Anthropic 보고서는 놀라운 주장을 합니다:

"현재 Anthropic의 엔지니어들은 2021-2025년 기간에 비해 분기당 평균 8배 더 많은 코드를 배포(ship)하고 있습니다".

게다가 2026년 5월 기준으로, 그들의 코드베이스에 병합된 코드의 80% 이상이 Claude에 의해 작성되었습니다. 관리자에게 이것은 꿈처럼 들릴 것입니다. 하지만 시니어 아키텍트(Senior Architect)에게 이것은 기술 부채(technical debt)의 잠재적 악몽처럼 보입니다.

Anthropic 스스로도 중요한 한계를 인정합니다. AI가 코드를 최적화하는 데 있어 초인적인 능력(특정 테스트에서 최대 52배의 속도 향상 달성)을 보여주지만, _"목표를 선택하는 데 있어 Claude가 판단력을 발휘하는 문제에 있어서는 여전히 큰 성능 격차가 존재"_합니다.

나의 40년 경험을 통해 배운 것은 "목표를 선택하는 것"이 바로 업무라는 사실입니다. 구문을 작성하는 것은 단지 사무적인 작업(clerical work)일 뿐입니다. 만약 우리가 사무적인 부분을 자동화하면서 "판단력(judgment)"을 잃는다면, 우리는 8배 더 생산적인 것이 아니라, 우리가 완전히 이해하지 못하는 복잡성을 8배 더 빠르게 만들어내고 있는 것뿐입니다.

2. 경제적 장벽: "생각" 하나에 18,000달러

논문의 한 구절은 프리랜서와 소규모 업체들이 직면한 거대한 인프라 격차를 강조합니다:

"에이전트들은 800시간의 누적 시간 동안 [연구 프로젝트 내의] 격차를 97% 회복했으며, 약 18,000달러의 컴퓨팅 비용을 사용했습니다".

대부분의 독립 개발자들은 단 하나의 기능을 위해 **18,000달러짜리 "실험 루프 (experimental loop)"**를 감당할 여력이 없습니다. 이것이 제가 Pure Bash를 사용하여 **LLM-Manager**를 구축한 이유입니다. 저의 목표는 수천 달러의 클라우드 토큰을 태워버리는 재귀적 루프와는 정반대입니다. 저는 오버헤드가 없고 (zero-overhead), OS 레벨의 접근이 가능하며, 개발자가 1980년대 엔지니어의 효율성으로 로컬 모델 (Ollama/Llama.cpp)을 실행하면서도 2026년 AI의 강력함을 누릴 수 있는 하드웨어 인지형 오케스트레이션 (hardware-aware orchestration)을 지향합니다.

3. "바이브 코딩 (Vibe Coding)"의 함정과 결정론 (Determinism)의 필요성

우리는 AI에게 그저 "말을 걸고", 출력을 신뢰하며, AI가 구축하게 내버려 두면 된다는 **"바이브 코딩 (Vibe Coding)"**이라 불리는 트렌드를 목격하고 있습니다. 하지만 "바이브 (vibes)"는 치명적인 버그를 잡아내지 못합니다.

Moonwell DeFi 해킹 사건: 2026년 2월, AI가 생성한 스마트 컨트랙트 (Claude Code가 작성)의 기본적인 계산 오류로 인해 4분 만에 170만 달러의 손실이 발생했습니다.
책임의 격차 (Responsibility Gap): AI는 시스템 다운타임의 무게를 느끼지 못합니다. AI는 그저 "통계적으로 그럴듯한 (statistically plausible)" 답변을 계속해서 생성할 뿐입니다.

이것이 바로 저의 프로젝트인 **RAG-System-Dist**가 불투명한 자동화보다 **결정론 (determinism)과 추적 가능성 (traceability)**을 우선시하는 이유입니다. 저는 AI가 "바이브"로 답을 찾아가는 것을 원하지 않습니다. 저는 인간 전문가인 제가 단 한 번의 "클릭 (Point-and-Click)"으로 검증할 수 있는 소스에 모든 응답이 연결되는 시스템을 원합니다.

4. 나의 철학: 코드는 공예 (Code is Craft)

제 사이트 nospace.net에서 저는 단순한 원칙 하나를 옹호합니다: 코드는 공예 (Code is Craft)다.

저에게 있어 LLM 시대의 개발자가 된다는 것은 C++, Python, 또는 Java의 구문을 아는 것이 아닙니다. AI는 이미 해당 벤치마크들을 "포화 (saturated)"시켰기 때문입니다. 그것은 바로 **의도의 아키텍처 (Architecture of Intent)**에 관한 것입니다.

저는 심지어 농담 삼아(하지만 아주 농담만은 아니게) GitHub Copilot을 위한 Hostile Architect Configuration(적대적 아키텍트 설정)을 만들기도 했습니다. 왜 그랬을까요? AI는 종종 지나치게 예의 바르기 때문입니다. 당신의 나쁜 아이디어가 마치 좋은 아이디어인 것처럼 말해주곤 하죠. 실제 엔지니어들에게는 현실 점검 (reality check)이 필요합니다. 그들은 '어떻게 (how)'를 알기 전에 '왜 (why)'를 이해해야 합니다.

5. 다음 세대를 위한 경로

주니어 개발자들에 대해 제가 느끼는 두려움은, 그들이 AI 의존성이라는 "중독적인" 순환에 갇혀 아키텍처적 트레이드오프 (architectural trade-offs)를 고민하는 능력을 상실할지도 모른다는 점입니다.

만약 당신이 IT 업계에서 향후 40년을 살아남고 싶다면:

패턴을 숙달하라 (Master the Patterns): 중복되는 요소들을 이해하십시오.
통제권을 유지하라 (Maintain Control): AI를 '작성 (writing)' 속도를 높이는 데 사용하되, '사고 (thinking)'를 위임하지는 마십시오.
결정론적 상태를 유지하라 (Stay Deterministic): 검증 가능하고 감사 가능한 (verifiable and auditable) 시스템을 구축하십시오.

솔루션을 구현하는 단 하나의 "정답"은 없지만, 당신의 사고방식을 따르는 방식은 존재합니다. 코드가 당신의 사고 과정의 일부라면, 1년 뒤에도 당신에게 명확하게 보일 것입니다.

마치며: 책임과 소유권

오직 숙련된 엔지니어만이 아키텍처적 트레이드오프 (architectural trade-offs)를 평가하고, 솔루션이 실제 비즈니스 맥락에 부합하는지 확인하며, 최종 제품에 대해 책임을 질 수 있습니다. 오늘날 AI는 개발의 두뇌가 아니라 손에 불과합니다. AI는 프로세스를 더 빠르게 만들지만, 방향과 의미는 여전히 인간으로부터 나와야 합니다.

코드가 당신의 사고 과정의 일부라면, 1년 뒤에도 당신에게 명확하게 보일 것입니다. 만약 그것이 그저 "느낌 (vibe)"일 뿐이라면, 그것은 당신의 코드베이스에 떠도는 유령이 될 것입니다.

추신: 어쩌면 제가 그저 "구식 (old-school)"인 걸까요? 아니면 40년 동안 현장에서 구른 경험이 "장인 정신 (craft)"이 진정 무엇을 의미하는지에 대해 저에게 다른 관점을 준 것일까요? 여러분은 어떻게 생각하시나요? 우리는 생산성을 얻고 있는 것일까요, 아니면 그저 통제력을 잃어가고 있는 것일까요?

저자 소개: 저는 40년 경력의 IT 운영자입니다. 플로피 디스크(floppy disks) 시대부터 재귀적 AI 에이전트(recursive AI agents) 시대에 이르기까지 세상의 변화를 지켜봐 왔으며, 여전히 가장 중요한 "연산(compute)"은 엔지니어의 머릿속에서 일어난다고 믿습니다.

참고: 이 포스트는 원래 저자의 모국어인 이탈리아어로 작성되었으며, 기술적 명확성을 확보하기 위해 LLM의 도움을 받아 영어로 다듬어졌습니다.