AI가 없앤 것은 개발자 중산층이 아니라 피드백 한계다

AI가 속도 제한을 없앴다는 불편한 주장

Florian Herrengt는 "AI가 소프트웨어 엔지니어링의 중산층을 없애고 있다"고 썼다. 글의 핵심 문장은 더 직접적이다. AI는 약한 엔지니어링 문화를 가진 프로젝트를 훨씬 빠르게 실패하게 만든다. 예전에는 팀원이 휴가 중에 나쁜 설계와 무리한 기술 선택이 쌓였다면, 2026년에는 평범한 월요일 아침에 24,506줄 추가와 3,938줄 삭제가 담긴 AI 생성 PR이 올라온다는 것이다.

이 주장은 과장처럼 들리지만 현장의 감각을 건드린다. AI 코딩 도구는 생산 속도를 올린다. 하지만 이해, 리뷰, 운영 책임의 속도는 같은 비율로 오르지 않는다. 누군가 Claude 대화 링크를 설계 근거로 보내고, 리뷰어가 "어느 부분을 읽어야 하느냐"고 묻는 장면은 웃기면서도 날카롭다. LLM 코딩은 10배가 아니라 2배에 가깝다가 말한 병목도 여기 있다. 코드는 빨라졌지만 피드백 루프는 그대로다.

중산층이 아니라 검증 계층이 사라진다

"개발자 중산층"이라는 표현은 논쟁적이다. 더 정확히 말하면 AI는 중간 수준 개발자를 없애기보다 중간 수준의 검증 관행을 무너뜨린다. 코드를 작성한 사람이 왜 그렇게 했는지 설명하지 못하고, 리뷰어는 거대한 diff를 시간 안에 이해하지 못하며, 매니저는 기능이 동작하는 데모만 보고 진행을 승인한다. 그 결과 시스템은 작동하지만 누구도 소유하지 않는 상태가 된다.

GitHub Copilot 연구는 AI 보조가 개발자 생산성과 만족도를 높일 수 있음을 보여줬다. DORA의 AI 관련 연구도 AI 도입이 성과와 조직 맥락에 따라 다르게 작동한다고 본다. 즉 문제는 AI 도구 자체가 아니다. 도구가 만든 출력물을 조직이 어떤 기준으로 받아들이는지가 문제다.

한국 개발 조직의 현실적 위험

한국의 많은 개발팀은 이미 일정 압박과 리뷰 부족을 겪는다. 여기에 AI 코딩 에이전트가 들어오면 "빨리 되는 것처럼 보이는" 변경이 폭증할 수 있다. 특히 SI, 내부 시스템, 스타트업 MVP에서는 작동하는 화면이 곧 진척으로 해석된다. 하지만 AI가 만든 우회 로직, 중복 테이블, 불필요한 큐, 과한 서버리스 구성은 몇 달 뒤 장애와 유지보수 비용으로 돌아온다.

AI 슈퍼파워, 집중과 실행의 병목은 AI 시대에도 인간의 집중과 follow-through가 병목이라고 봤다. 코딩에서도 같다. 에이전트가 코드를 많이 만들수록 사람은 더 엄격하게 범위를 자르고, 가설을 세우고, 테스트를 요구해야 한다. "일단 Claude에게 고치라고 하자"는 문화는 버그를 없애는 것이 아니라 원인 분석 능력을 약화시킨다.

AI 코딩 규칙은 속도보다 책임을 설계해야 한다

실무 규칙은 복잡할 필요가 없다. 첫째, AI가 만든 PR도 사람 작성 PR과 같은 크기 제한을 둔다. 둘째, 설계 결정은 대화 링크가 아니라 짧은 결정 기록으로 남긴다. 셋째, 생성된 코드에는 재현 테스트와 롤백 계획을 요구한다. 넷째, 작성자가 설명하지 못하는 변경은 병합하지 않는다. 다섯째, 리팩터링과 기능 추가를 한 PR에 섞지 않는다.

OpenJDK AI 금지, 오픈소스의 새 방화벽은 AI 생성 기여의 provenance와 리뷰 비용을 문제 삼았다. 기업 내부 코드도 같은 질문을 피할 수 없다. Martin Fowler의 Continuous Integration 설명이 오래전부터 작은 통합과 빠른 피드백을 강조한 이유는 AI 시대에 더 선명해졌다. 대량 생성은 작은 통합의 반대 방향으로 팀을 밀어낸다.

개발자의 다음 역량은 설명 가능성이다

AI가 낮은 수준의 반복 구현을 줄이는 것은 분명하다. 그러나 그것이 곧 중간 개발자의 종말을 뜻하지는 않는다. 오히려 중간 개발자가 고급 개발자로 올라가기 위해 필요한 능력이 더 명확해졌다. 시스템 경계를 설명하고, trade-off를 문서화하고, 테스트 전략을 세우고, 에이전트 출력의 위험을 읽는 능력이다. SimpleEnglish, 에이전트 문서 품질의 작은 표준가 말한 문서의 선명함도 같은 맥락이다.

결국 AI 코딩의 승자는 가장 많은 코드를 만든 팀이 아니라 가장 빠르게 이해 가능한 변경으로 압축하는 팀이다. 코드는 더 싸졌고, 이해는 더 비싸졌다. 조직은 이 가격 변화를 인정해야 한다.

자주 묻는 질문

Q1: AI가 중간 개발자를 실제로 대체하나요?

A: 일부 반복 구현 업무는 줄어들 수 있다. 하지만 더 큰 변화는 이해하지 못한 코드를 대량 생성하는 조직과 설명 가능한 변경을 만드는 조직의 격차다.

Q2: AI 코딩 도구 사용을 금지해야 하나요?

A: 전면 금지는 현실적이지 않다. 대신 PR 크기, 설계 기록, 테스트, 작성자 설명 책임을 강화하는 편이 낫다.

Q3: 대화 링크를 설계 문서로 쓰면 안 되나요?

A: 참고 자료로는 가능하지만 설계 문서의 대체물은 아니다. 결정, 근거, 대안, 위험을 사람이 요약해야 리뷰가 가능하다.

Q4: 리뷰어의 부담은 어떻게 줄이나요?

A: 작은 PR, 자동 테스트, 변경 의도 요약, 위험 구간 표시, 생성 코드와 수동 수정의 구분이 필요하다.

Q5: 개발자가 지금 키워야 할 역량은 무엇인가요?

A: 프롬프트보다 시스템 이해, 디버깅, 테스트 설계, 운영 감각, 설명 가능한 의사결정 기록이 더 중요해진다.