Spotify의 고백: 최고 개발자들이 두 달째 코드를 안 쓴다
Spotify의 공동 CEO Gustav Söderström이 올해 2월 투자자들에게 한 말이 개발자 커뮤니티를 뒤흔들었습니다. "우리 최고 엔지니어들은 12월 이후 단 한 줄의 코드도 직접 쓰지 않았다." 내부 AI 시스템 'Honk'(Anthropic Claude Code 기반)가 대신 씁니다. 엔지니어는 Slack으로 자연어 명령을 던지고, 컴파일된 결과물을 받아 테스트한 뒤 프로덕션에 머지합니다. 출근 전에. 지하철 안에서.
표면만 보면 눈부신 성과입니다. 2025년 50개 이상의 신규 피처를 출시했고, 분기 영업이익은 €7억 1천만을 기록했습니다. Honk는 매달 650개 이상의 에이전트 생성 PR을 머지하고 있습니다. 투자자들은 박수를 쳤습니다.
하지만 개발자들은 다른 걸 들었습니다.
"조립 라인의 심판관" — AI 피로의 실체
소프트웨어 엔지니어 Siddhant Khare는 이 상황을 "AI 피로(AI fatigue)" 라고 불렀습니다. 시니어 엔지니어가 자신이 설계하지 않은 로직을, 자신이 짜지 않은 코드를, 하루 종일 리뷰하는 역할로 전락했다는 겁니다. Reddit r/technology에서 이 발언은 48시간 만에 14,000개 이상의 업보트를 받았고, 반응의 온도는 찬사와는 거리가 멀었습니다.
이건 감정적 반응만이 아닙니다. 데이터가 뒷받침합니다. AI 코드베이스에서 코드 처닝(churn)이 39% 증가한다는 연구 결과가 있습니다. 더 많이 쓰고, 더 많이 다시 쓰고, 더 많이 버립니다. 또 다른 연구에서는 개발자 88%가 AI 도구 사용의 부정적 부작용을 경험했고, 53%는 생성된 코드가 겉으로 맞아 보이지만 실제로는 신뢰할 수 없다고 답했습니다. Anthropic 자체 연구(2026년 1월)에서는 AI를 쓴 개발자들이 작업 속도는 빨라졌지만 코드 이해도 테스트에서 17% 낮은 점수를 받았습니다.
더 빠르고, 더 이해 못 한다. 이걸 개선이라고 부를 수 있을까요?
언급되지 않은 맥락: 해고, 그리고 남은 자들
Söderström의 발언에는 빠진 사실이 하나 있습니다. 2023~2025년 사이 Spotify는 전체 인력의 약 20%, 약 1,500명을 해고했습니다. CEO Daniel Ek은 나중에 "구조조정이 예상보다 훨씬 큰 운영 혼란을 가져왔다"고 인정했습니다.
타임라인을 다시 읽으면 불편한 질문이 생깁니다. 인력의 20%를 자른 뒤, 남은 엔지니어들이 코드를 직접 쓰지 않는 '감독자'가 됐다는 건 어떤 의미일까요? AI 덕분에 시니어가 더 고차원 업무에 집중하게 된 걸까요, 아니면 손이 부족해서 AI에게 떠넘기게 된 걸까요? Spotify는 이 질문에 답하지 않았습니다. 그 침묵 자체가 답일 수 있습니다.
아무도 언급하지 않은 리스크: 저작권 공백
Earnings Call에서 아무도 꺼내지 않은 주제가 있습니다. 미국 저작권청은 인간이 창작한 저작물만 저작권으로 보호된다고 판결했습니다. 만약 Spotify의 최고 엔지니어들이 정말로 단 한 줄도 직접 쓰지 않았다면, Claude가 생성하고 인간이 승인만 한 코드의 저작권 지위는 법적으로 불분명합니다.
이건 이론적 리스크가 아닙니다. 매달 650개 이상의 PR, 즉 엔지니어가 법정에서 "나는 이 코드를 쓰지 않았다"고 진술할 수 있는 코드가 프로덕션에 쌓이고 있습니다. 아직 어떤 기업도 법원에서 이 문제를 다툰 적이 없습니다. Spotify가 첫 번째 사례가 되고 싶지 않다면, 지금 당장 이 리스크를 직시해야 합니다.
보안 부채: AI가 만든 구멍을 AI로 메울 수 있나
Spotify 사례가 개발자 역할의 문제라면, Veracode의 2026 소프트웨어 보안 보고서는 팀 전체의 리스크를 수치로 보여줍니다. 160만 개 애플리케이션을 분석한 결과, 보안 부채(1년 이상 미해결 취약점)가 74%에서 82%로 증가했고, 고위험 취약점은 8.3%에서 11.3%로 뛰었습니다. 보고서의 결론은 냉혹합니다: "AI 시대의 개발 속도는 포괄적 보안을 달성 불가능하게 만든다."
핵심 문제는 AI가 '나쁜 코드'를 쓴다는 게 아닙니다. 처리량 비대칭(throughput asymmetry) 입니다. AI 도구는 개발자가 코드를 생성·배포하는 속도를 보안팀이 리뷰·테스트·수정할 수 있는 속도보다 훨씬 빠르게 만들어버립니다. 품질 검사관 없이 생산량을 3배 늘린 공장을 상상해보세요. 단위당 불량률은 같아도, 고객에게 도달하는 절대적 불량품 수는 폭발적으로 늘어납니다.
"AI가 만든 취약점은 AI로 고치면 되지 않나?"라는 질문이 자연스럽게 나옵니다. 하지만 Veracode 데이터는 이 낙관론을 부정합니다. AI 보안 도구가 광범위하게 도입됐음에도 리메디에이션 격차는 지난 1년간 줄지 않고 오히려 늘었습니다. AI 도구가 생성하는 오탐(false positive)이 리뷰어의 부담을 가중시켜 오히려 역효과를 낳는 경우도 있습니다.
개발자가 관중이 되는 순간 잃는 것
Spotify 이야기에서 가장 무거운 질문은 이겁니다. "시니어 엔지니어가 AI 산출물을 감독하는 데 시간을 쓴다면, 그들을 시니어로 만든 깊은 전문성은 누가, 어떻게 쌓나?"
심리학의 자기결정이론(Self-Determination Theory)은 인간의 내재적 동기를 세 가지 핵심 욕구로 설명합니다: 자율성, 유능감, 관계성. AI 보조 개발이 잘못 설계될 때, 이 세 가지를 동시에 침식합니다. 코드를 직접 쓰는 고통스러운 과정 — 버그를 추적하고, 아키텍처를 고민하고, 트레이드오프를 결정하는 과정 — 이 바로 주니어를 시니어로 만드는 경로입니다. 이 과정을 AI가 대체하면, 주니어는 산출물은 쌓지만 전문성은 쌓지 못합니다.
Spotify는 AI로 학습 경로를 단축할 수 없습니다. Claude를 감독하는 것으로는 차세대 시니어 엔지니어를 키울 수 없습니다. 하지만 투자자에게는 개발 속도가 사상 최고라고 보고할 수 있습니다. 이 두 사실 사이의 간극이 바로 리스크가 사는 곳입니다.
테크 리드가 지금 당장 해야 할 것
AI 코딩 도구를 금지하자는 게 아닙니다. 생산성 이점은 실재합니다. 문제는 그 이점을 누리면서 리스크를 통제하는 구조를 설계했느냐입니다.
첫째, 보안을 '생성 시점'으로 당기세요. CI/CD 파이프라인의 커밋 이후 보안 검사는 AI 시대에 너무 늦습니다. AI 코딩 어시스턴트에 보안 인식 프롬프트와 가드레일을 설정하고, 프리커밋 훅으로 고위험 패턴을 코드가 리포지토리에 들어오기 전에 차단해야 합니다.
둘째, AI 생성 코드 거버넌스를 구축하세요. 어떤 코드가 AI로 생성됐는지 추적하는 출처 관리(provenance tracking), 민감 영역의 AI 코드 의무 리뷰, 감사 추적(audit trail) 없이는 문제를 측정할 수도, 관리할 수도 없습니다. 저작권 이슈까지 고려하면 이건 선택이 아닙니다.
셋째, 개발자를 '관중'이 아닌 '설계자'로 재포지셔닝하세요. AI에게 구현을 맡기기 전에 개발자가 요구사항, 아키텍처 결정, 엣지 케이스, 수용 기준을 직접 명세화하는 워크플로우가 필요합니다. AI가 코드를 짜더라도 설계의 저자는 사람이어야 합니다. 이게 전문성과 주인의식을 지키는 실질적 방법입니다.
넷째, 보안 투자를 개발 속도에 비례해 키우세요. 개발 속도가 2~3배 빨라졌는데 보안 예산과 인력이 그대로라면, 그건 명시적으로 더 많은 리스크를 수용한다는 결정입니다. 의식적으로 내린 결정이라면 괜찮습니다. 하지만 그냥 방치한 거라면, 그 부채는 언젠가 반드시 터집니다.
속도의 반대편
Spotify의 사례는 AI-First 워크플로우의 빛과 그림자를 동시에 보여주는 교과서입니다. 속도는 실재합니다. 그 속도의 뒤편에서 조용히 쌓이는 것들 — 코드 품질 저하, 보안 부채, 저작권 공백, 그리고 개발자 전문성의 공동화 — 도 실재합니다.
"AI가 코드를 짜는 동안 팀은 무엇을 잃고 있나"에 대한 답은 하나가 아닙니다. 하지만 공통점이 있습니다. 측정하지 않으면 관리할 수 없고, 설계하지 않으면 통제할 수 없다는 것. AI-First 팀 리빌딩의 진짜 과제는 속도를 포기하는 게 아니라, 속도가 만들어내는 부채를 보이게 만드는 구조를 설계하는 겁니다. 그게 테크 리드의 일입니다.