Florian Herrengt의 AI is removing the middle class of software engineering는 AI가 엔지니어를 통째로 대체한다는 이야기보다 더 구체적인 균열을 다룬다. 구현이 싸지고 빨라진 만큼, 약한 엔지니어링 문화는 예전보다 훨씬 빨리 무너진다. 그 결과 살아남는 사람은 프롬프트만 잘 던지는 중간층이 아니라, 시스템이 무엇을 하는지 알고 결정을 책임질 수 있는 사람이다.
원문: AI is removing the middle class of software engineering (2026-08-11)
2020년의 휴가와 2026년의 월요일
2020년이라면 이런 장면이 가능하다. 팀에서 가장 시니어인 사람이 코드 품질과 아키텍처를 맡고, 경험이 적은 사람의 PR을 꼼꼼히 리뷰한다. 그러다 휴가를 다녀오면 코드베이스가 엉망이다. 서로 리뷰를 대충 통과시키고, 편하다는 이유로 테이블을 비정규화하고, 근거 없이 서버리스나 Kafka를 넣는다. 그래도 복귀하면 고칠 수 있다.
2026년에는 휴가가 필요 없다. 평범한 월요일 아침, 커피를 내리고 컴퓨터를 열면 리뷰할 PR이 7개다. 첫 번째 PR은 +24,506 / -3,938줄 이고, 설명은 AI가 쓴 글이다. 금요일 이후의 변경량이 예전에는 몇 주 자리를 비웠을 때나 나오던 규모다.
저자가 그리는 실패는 극적인 장애가 아니다. 기능은 어느 정도 동작한다. 그래서 사람들은 같은 방식으로 계속 밀어붙인다. 어느 순간 팀 안에서 시스템이 어떻게 돌아가는지 아는 사람이 사라진다.
사용자가 이상한 버그를 네 번째로 보고한다. 팀도, AI도, Fable도 원인을 못 찾는다. 해당 기능을 만든 사람에게 데이터가 어디서 오는지 물으면 대답은 이렇다. “잘 모르겠다. Claude에게 물어보겠다.” 둘이 나란히 앉아 끝없이 흘러가는 텍스트를 본다. 맞는지 틀린지는 아무도 모르지만, Claude는 매우 확신에 차 있다. 울트라 모드로 한 번 더 검증하자고 하고, 그 사이에 X의 최신 드라마를 이야기한다.
설계 이유를 물으면 Claude 대화 링크가 온다. 그 대화 안에는 자신 있게 추천한 아키텍처, 사과, 번복, 재검토, 그리고 15라운드가 넘는 수정이 묻혀 있다. “어디를 읽어야 하나?” “아마 전부.”
큰 시스템을 처음부터 끝까지 알던 사람은 원래도 드물었다. 차이는 이것이다. 예전에는 누군가는 알고 있었고, 그 사람이 설명해 줄 수 있었다. 지금은 본인도 모르기 때문에 LLM에게 묻는다.
AI가 없앤 것은 속도 제한이다
저자의 문장은 짧다. AI는 약한 엔지니어링 문화의 프로젝트를 훨씬 빨리 실패시킨다.
예전에는 사람들이 앉아서 어떻게 할지 이야기했다. 지금은 몇 시간 에이전트에게 프롬프트를 던지고 PR을 연다. 가장 비극적인 점은, 훈련되지 않은 눈에는 이 방식이 통한다는 것이다. 브랜치를 받아 돌려보면 어느 정도 동작한다. 그래서 같은 일을 반복한다. 그러다 아무도 이해하지 못하는 지점에 도달한다.
비유는 신용카드로 산 고급차다. 부채는 보이지 않고, 멋진 차만 보인다.
고치려면 경영진에게 정당화하기 어려울 만큼 큰 일이 된다. 겨우 고친다 해도 몇 달이면 다시 같은 상태가 된다. 그래서 선택은 또 Claude에게 고치라고 하는 것이다. 루프와 목표를 만들어 전부 확인할 때까지 멈추지 않게 하자고 한다. 오늘 Fable 사용량을 다 썼으니 내일 돌리겠다는 말로 하루가 끝난다.
자리에 돌아오면 리뷰할 PR이 13개다. 이해되지 않는 부분을 물으면 다시 Claude 대화 링크가 온다.
나쁜 엔지니어를 더 이상 감당할 수 없다
모든 팀에는 프로젝트를 가능하게 만드는 사람과, 주변을 더 어렵게 만드는 사람이 있다. 이제는 누구나 하루에, 예전 한 해 분량보다 많은 코드를 만들 수 있다.
앞선 장면에서 실패하는 사람은 한 명이 아니다.
- 2만 5천 줄 PR을 연 사람은 에이전트를 훨씬 전에 멈춰야 했다. 무엇을 하는지 이해하고, 일을 더 잘게 나누고, 새로 생긴 추상화를 하나씩 의심해야 했다.
- 리뷰하는 사람은 그 규모를 리뷰하지 말았어야 했다.
- Kafka를 넣은 사람은 왜 필요한지 정확히 설명할 수 있어야 했다.
- 기능을 만든 사람은 Claude 대화 링크 없이 데이터가 어디서 오는지 말할 수 있어야 했다.
기술 부채 자체가 항상 나쁜 것은 아니다. 중요한 것은 그것이 지름길임을 아는 일이다. 문제는 나쁜 결정을 되돌리기가 매우 어렵다는 점이다.
LLM이 테이블과 컬럼을 잔뜩 추가하는 데는 10분이면 충분하다. 그런데 그 자리에 데이터가 쌓이면 그냥 지울 수 없다. 매일 돈을 내는 사용자를 끊지 않는 마이그레이션을 짜고, 실패했을 때의 계획을 세우고, 고아 외래키가 남지 않게 해야 한다. 최고 모델을 써도 이쪽이 훨씬 어렵다.
그 사이에 더 많은 PR이 들어온다. 한 사람이 오후에 2만 줄을 만들 수 있어도, 그 줄이 실제로 무엇을 하는지는 앉아서 이해해야 한다. 나쁜 결정 하나를 푸는 동안 다섯 개가 더 머지된다.
새로운 AI 경제
나쁜 엔지니어는 OpenAI나 Anthropic 이전부터 부채였다. 나쁜 결정은 복리로 쌓였고, 불필요한 복잡도가 쌓였고, 아무도 이해하지 못하는 시스템을 유지하는 팀이 생겼다. 차이는 그렇게 망가뜨리는 속도에 상한이 있었다는 것 이다.
지금은 구현이 싸다. 받는 돈의 이유는 좋은 결정을 내리는 일, 복잡도를 관리하면서 커질 수 있는 소프트웨어를 만드는 일이다.
저자는 묻는다. 런던이나 샌프란시스코에서 여섯 자리 연봉을 주는 이유가 무엇인가. 명세를 동작하는 코드로 바꾸는 일만 필요했다면, 이미 더 싼 곳에서 할 수 있었다. “소프트웨어는 이미 풀렸다"고 말하는 회사들이 왜 여전히 최고 인재를 비싼 돈으로 데려오는가.
저자의 베팅은 급여가 더 벌어지는 쪽이다. 고용되려면 넘어야 할 막대가 있고, 그 막대는 그날의 최고 모델이 하는 일 이다. 좋은 엔지니어는 AI 덕분에 더 빨리 움직이므로 더 가치 있어진다. 구현만 맡길 주변 사람을 예전만큼 많이 둘 필요가 없다. 반대로 나쁜 엔지니어는 고용 비용이 훨씬 커진다.
저자는 이전에 바이브 코더의 커리어 경로는 끝났다라고 쓴 바 있다. 에이전트에게 프롬프트를 주는 것만으로 누구나 얻는 결과 너머에 기여해야 한다. LLM의 추천을 평가할 판단이 없는데 더 많은 판단을 요청하는 것으로는 문제가 풀리지 않는다.
결국 무엇이 돌아가는지 아는 사람이 필요하다. 그 사람이 팀에서 가장 비싼 사람이다. 그렇지 못한 사람은 더 싸게 고용되거나 대체되고, 돈은 실제로 믿을 수 있는 더 적은 수의 사람에게 몰린다.
저자는 이 구조가 소프트웨어에만 머물지 않는다고 본다. 대부분의 지식 노동에서 같은 일이 벌어진다. AI는 가장 잘하는 사람을 훨씬 생산적으로 만들고, 못하는 사람은 거의 고용할 수 없게 만든다. 예전에는 나쁜 결정이 너무 멀리 가기 전에 누군가가 잡을 가능성이 있었다. 지금은 주변이 리뷰하거나 이해할 수 있는 속도보다 빨리 변경을 만든다.
흔한 반론
원문의 후반부는 반론에 답하는 데 쓰인다.
나쁜 엔지니어는 원래 있었다. 차이는 속도다. 시속 30km로 부딪히는 것과 시속 200km로 부딪히는 것의 차이다. 예전에는 나쁜 엔지니어가 컴파일되는 코드를 만들기도 힘들었고, 만들어도 오래 걸렸으며, 피해 반경은 사람이 타이핑하는 속도에 묶여 있었다. 지금은 점심 전에 1만 줄의 동작하는 코드를 만들 수 있다. 오후에 입히는 피해가 예전에는 몇 달이 걸리던 양이다. 나쁜 결정이 쌓이는 속도는 완전히 달라졌고, 고치는 속도는 그대로다.
프로세스를 고치면 된다. 테스트, CI, 코드 리뷰, 아키텍처 리뷰는 이미 있었다. 문제는 그 장치들이 대량 변경이 불가능하던 세계 를 전제로 만들어졌다는 점이다. 하루에 AI 설명과 함께 PR 10개가 열리면 리뷰는 더 이상 같은 도구가 아니다. 테스트는 생각해서 넣은 동작을 잡는다. 아무도 생각하지 못한 동작은 잡지 못한다. 커버리지가 가득하고 CI가 초록이어도 버그는 나간다. 코드를 만들기 어렵다는 사실 자체가 제한 장치였다. 이해를 담당하는 사람이 병목이 되면 선택지는 세 가지다. 덜 만들거나, 정말로 더 나은 검증 방법을 찾거나, 품질을 낮추는 것이다.
AI를 반대하는 이야기일 뿐이다. 저자는 매일 AI를 쓰며, 모든 코드를 손으로 돌아가고 싶지 않다고 분명히 한다. 핵심은 큰 변경을 매우 싸고 빠르게 만들게 된 반면, 그 변경을 이해하는 일은 여전히 느리고 어렵다는 점이다. 올바른 멘탈 모델을 만드는 지름길은 아직 없다. AI를 많이 쓰면서도 사용 방식의 문제를 인정할 수 있다.
많이 만들면 생산적이다. 하루에 PR 10개를 열면 숫자는 멋져 보인다. 반드시 10배 생산적인 것은 아니다. 이른바 10x 엔지니어는 주변의 생산성을 훔친 사람일 수 있다. 세 명이 이틀 동안 리뷰하고, 가정을 고치고, 회귀를 디버깅하고, 절반을 다시 만들어야 한다면 일은 사라지지 않고 옮겨간 것이다. 더 나쁜 점은, 그 시간이 가장 대체하기 어렵고 이미 부족한 사람들의 주의라는 것이다. PR 수, 변경 줄 수, “끝난” 기능 수는 형편없는 생산성 지표다. 회사 인센티브가 티켓 수를 보상하면 신중한 사람이 나쁜 직원처럼 보이고 대충 밀어붙인 사람이 승진한다.
품질을 지키면 문제 직원이 된다. 다들 빨리 배포하는데 “잠깐"이라고 말하면 그렇게 보일 수 있다. 저자는 더 느리지만 믿을 수 있는 사람의 작업을, 나중에 무슨 문제가 터질지 모르는 빠른 변경보다 선호한다. 사업상 타협은 필요하다. 동시에 척추가 필요하다. 진짜 문제를 만들 것 같으면 말하는 일이 직무의 일부다. 프로덕션이 깨질 때, 그리고 깨질 것이다, 필요한 사람은 그 변경을 이해하고 고칠 수 있는 사람이다.
AI 출력은 컴파일러가 만든 어셈블리와 같다. 컴파일러는 의미를 보존하며 다른 표현으로 옮긴다. 무엇을 할지는 결정하지 않고, 결정적이다. LLM은 결정을 내린다. 아키텍처를 고르고, 추상화를 고르고, 어디에 둘지 정한다. Claude에게 기능을 만들라고 하면 의도를 번역하는 것이 아니라 수십 개의 설계 결정을 대신 내린다. 5년 뒤 완전한 명세를 주고 결과 코드를 신뢰성 있게 검증할 수 있다면 코드 리뷰는 사라질 수 있다. 지금은 아니다. 결과 시스템을 정말로 이해한다면 문제는 없다. 저자가 비판하는 것은 그 행동이 아니다. 다만 매우 큰 PR, 특히 AI가 만든 PR의 대다수에서, 연 사람이 전부를 이해하지 못한다고 돈을 걸 수 있다고 본다.
우리는 이미 99% AI 코드를 배포하고 있고 잘 된다. 저자도 자신이 만드는 코드의 대부분을 AI에서 가져온다. 그래도 결과를 이해하는 일은 직접 해야 한다. “AI가 코드를 쓸 수 있다"와 “더 이상 이해할 필요가 없다"는 같은 말이 아니다.
사용자는 신경 쓰지 않는다. CRUD를 만들고 돈을 받으면 된다. 저자는 이 시각이 비교적 작거나 고립된 프로젝트를 하는 사람에게서 나온다고 본다. 큰 시스템에서는 오늘 고객이 행복한 것만으로는 부족하다. 다른 엔지니어가 시스템을 이해할 수 있어야 한다. 직접 쓰지 않은 시스템의 장애로 새벽에 깨워 본 적이 있는가. 작고 고립되고 쉽게 바꿀 수 있는 것만 만든다면 추한 것을 배포하고 돈을 받고 떠나도 된다. 앞으로 5년 이상 붙들고 있을 것이라면, 무엇을 하는지 생각할 시간이 필요하다. 단순한 CRUD만 만든다고 큰돈을 받는 사람은 원래도 거의 없었다. 회사가 경험 있는 엔지니어에게 돈을 내는 이유는, 그 CRUD가 수년간의 비즈니스 규칙과 제약과 연동이 얽힌 지저분한 실제 시스템 안에 있기 때문이다.
주니어가 아니라 이해가 문제다
저자는 최근에 함께 일한 주니어 두 명을 높이 평가한다. 그들은 코드를 만들기만 하지 않고, 자신이 무엇을 하는지 이해하려 한다. AI로 모르는 것을 탐색하고, 질문을 던져 추론을 다듬고, 가정을 다시 확인한다. 도구를 이해를 늘리는 데 쓴다.
반대로 이해를 포기한 시니어도 보았다. 그들은 더 나쁜 엔지니어가 되었다. 저자는 지금이라면 그 시니어보다 그 주니어 둘과 일하고 싶다.
문제는 AI가 아니다. 문제는 AI를 이해를 쌓는 도구가 아니라 이해를 대신하는 도구 로 쓰는 일이다.
AI가 더 잘하는 기술을 가르치지 말자는 주장에도 저자는 반대한다. 기계가 더 잘한다고 해서 배우는 일이 무의미해지지는 않는다. 계산기는 사람보다 계산을 훨씬 잘하지만 산술과 대수를 가르친다. 맞춤법, 문법, 에세이도 가르친다. 주머니 속 기기가 거의 모든 사실을 바로 찾아주는데도 역사와 지리를 가르친다. 이해하고, 의심하고, 검증하는 멘탈 모델은 다른 경로로 생기지 않는다.
AI 사용을 매니저의 위임과 같다고 보는 시각도 있다. 매니저의 일은 보통 우선순위, 사람, 조정, 자원 배분이다. 소프트웨어를 어떻게 설계하고 구현할지를 맡기는 역할이 아니다. 엔지니어인 채로 기술적 판단을 LLM에 넘기면, 직무에서 가장 중요한 부분을 그만둔 것이다.
주니어를 뽑지 않으면 시니어는 어디서 오느냐는 질문에는 저자도 동의하는 부분이 있다. 초급 역할을 줄이면 업계는 자기 미래를 깎는다. 배우는 사람이 줄면 나중에 시스템을 유지할 사람도 줄어든다. 다만 업계가 개인에게 기회를 빚지고 있지는 않다. 그래야 한다고 생각해도, 회사는 그렇게 행동하지 않는다. 그래도 소프트웨어 산업의 본질은 유지보수다. LLM은 수십만 줄에 걸친 프로젝트를 마음대로 고치지 못한다. 아키텍처를 나누는 기술은 여전히 사람의 일이다. 그것이 경험 있는 엔지니어가 덜 중요해지는 것이 아니라 더 중요해지는 이유다.
누가 신경 쓰겠느냐는 물음에 대한 답은 단순하다. 아무것도 동작하지 않고, 고칠 수 있는 사람이 없고, 새 기능은 끝없이 걸리며, 모든 변경이 다른 곳을 깨뜨릴 때 신경 쓴다. 이런 일은 AI 이전에도 있었다. 다만 예전에는 수년이 걸리던 유지 불가능한 상태에, 이제는 몇 달 만에 도달할 수 있다.
결론 및 시사점
한 줄 결론: AI가 없애는 것은 엔지니어 전체라기보다, 모델을 따라가는 것만으로 버티던 중간층이며, 남는 가치는 무엇이 돌아가는지 알고 결정을 책임지는 쪽에 모인다.
구현이 싸진 세계에서는 산출량이 능력을 증명하지 않는다. 동작하는 코드는 더 이상 희소하지 않다. 희소한 것은 그 코드가 왜 거기 있는지 설명하고, 잘못된 추상화를 멈추며, 운영 중인 데이터를 되돌릴 수 있는 판단이다.
개인에게는 프롬프트로 얻은 결과를 자기 것으로 만드는 일이 최소 조건이 된다. 데이터가 어디서 오는지, 왜 이 서비스를 넣었는지, 이 변경이 깨뜨릴 수 있는 것이 무엇인지 대화 로그 없이 말할 수 있어야 한다. 조직에게는 PR 수와 줄 수를 보상하는 인센티브가 가장 비싼 사람들의 주의를 가장 빨리 소모시킨다는 점이 중요하다.
속도 제한이 사라진 도로에서는 운전 실력이 더 중요해진다. AI는 그 도로의 제한 속도를 없앴다. 사고 없이 도착하는 사람은 더 많이 생성한 사람이 아니라, 더 잘 이해하고 더 일찍 멈춘 사람이다.