AI가 소프트웨어 엔지니어링의 중간층을 없애고 있다?

TL;DR Highlight

AI로 코드 생산은 싸졌지만 이해는 여전히 느려서, 판단력 있는 엔지니어만 값이 오른다

Who Should Read

AI가 만든 대형 PR을 매일 리뷰하며 코드베이스 품질이 걱정되는 시니어·리드 개발자

Core Mechanics

AI가 속도 제한을 없앴다
- 약한 엔지니어링 문화의 프로젝트는 AI로 훨씬 빨리 무너진다고 한다.
- 글의 예시에서는 한 PR이 +24506 -3938줄이고, 리뷰할 PR이 7개에서 13개로 늘어난다.
코드는 싸졌고 이해는 여전히 비싸다
- 큰 변경을 만드는 건 싸고 빨라졌지만 변경이 뭘 하는지 이해하는 일은 여전히 느리다고 한다.
- 이해를 대신할 지름길은 아직 없다는 게 저자 입장이다.
잘못된 결정은 되돌리기 어렵다
- DB에 테이블·컬럼을 추가하는 건 LLM으로 10분이면 되지만 데이터가 쌓이면 못 지운다.
- 마이그레이션 계획, 실패 대비, 고아 외래키 방지는 여전히 사람 몫이라고 한다.
기존 프로세스는 이 속도를 전제로 설계되지 않았다
- 테스트·CI·코드 리뷰는 대량 변경이 불가능하던 시절을 위한 것이라고 한다.
- 병목이 된 검증 쪽에는 생성 줄이기, 더 나은 검증법 찾기, 품질 낮추기 세 선택지뿐이라고 한다.
PR 수가 많다고 생산성이 높은 게 아니다
- 10개 PR을 올리면 다른 엔지니어 셋이 이틀간 리뷰·수정·디버깅하게 될 수 있다고 한다.
- 이러면 일을 다른 사람에게 넘긴 것이지 10배 생산성이 아니라는 주장이다.

Community Reactions

AI는 나쁜 엔지니어를 10배로 증폭한다는 의견
- 오래 근무해 신뢰는 있지만 흥미를 잃은 엔지니어가 특히 위험하다는 의견이 있었다.
- AI는 넣어준 추상화와 계약만큼만 좋다는 의견도 있었다.
실제로 Kafka와 인프라 변경을 막느라 시간을 쓴다는 경험
- 인프라 레이어를 이해 없이 추가하는 사람들 때문에 주 몇 시간을 싸운다는 경험담이 있었다.
- 변경 속도가 올라 두더지 잡기가 됐다고 한다.
에이전트 승인 기준을 정해 쓴다는 경험
- full-auto 모드를 쓰지 않고 이해 못 한 건 승인하지 않는다는 사례가 있었다.
- 모르는 부분은 먼저 따로 공부한 뒤 승인·거부·수정한다고 한다.
과거에도 설명해 주는 사람은 없었다는 반론
- 예전에도 담당자가 떠나 직접 코드를 파야 했다는 경험이 여러 댓글에 있었다.
- 그래서 에이전트에 맡기는 게 왜 더 나쁜지 모르겠다는 의견이 있었다.
AI가 풀지 못하고 고칠수록 문제가 늘면 설계 문제라는 의견
- 그럴 때는 추상화와 아키텍처를 갈아엎어야 한다는 경험칙이 제시됐다.
- 피곤해 계속 승인만 누르다 하루치 작업을 되돌렸다는 경험도 있었다.

How to Apply

PR 템플릿에 직접 설명 칸 넣기
- 오늘 PR 템플릿에 '데이터 출처, 왜 이 구조인지, 새 추상화 이유'를 작성자가 직접 쓰는 칸을 추가한다.
- AI 대화 링크만 있고 칸이 비면 리뷰를 시작하지 않는다.
PR 크기 상한 정하기
- 팀에서 줄 수나 파일 수 상한을 정하고 넘으면 쪼개서 다시 올리게 한다.
- 에이전트에게도 작업을 작은 단위로 나눠 시키도록 가이드한다.
새 인프라·스키마 변경은 설계 설명 요구하기
- Kafka, 서버리스, 테이블 추가는 필요성과 마이그레이션·롤백 계획을 먼저 문서로 받는다.
- 근거 없이 코드부터 올린 건 머지하지 않는다.
생산성을 PR 수가 아닌 팀 처리량으로 보기
- 리뷰 시간과 되돌린 변경 수를 같이 측정해 관리자에게 공유한다.
- PR 수와 줄 수만 보여주는 지표는 쓰지 않는다.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 붙여넣기 (원문의 '이해 확인' 아이디어를 프롬프트로 옮긴 간이 버전)

너는 까다로운 시니어 리뷰어다. 아래 PR 설명과 diff를 보고 작성자가 이해했는지 검증할 질문을 만들어라.

{{PR 설명}}

{{diff}}

다음을 출력해라.
1. 새로 도입된 추상화·인프라·스키마 변경 목록과 각각 필요한 이유를 묻는 질문
2. 데이터가 어디서 와서 어디로 가는지 작성자가 직접 설명해야 할 질문 3개
3. 되돌리기 어려운 변경(마이그레이션 등)과 실패 시 계획을 묻는 질문
4. 이 PR을 3개 이하의 작은 PR로 나누는 제안

이어서 해 볼 것: 질문을 실제 PR 코멘트로 올리고 작성자가 AI 없이 답하게 해 보자.

Terminology

denormalise(비정규화)조회를 쉽게 하려고 같은 데이터를 여러 테이블에 중복 저장하는 것. 편해 보이지만 나중에 데이터가 어긋나기 쉽다.

blast radius한 번의 실수가 영향을 미치는 범위. 폭탄이 터졌을 때 피해 반경과 같은 개념이다.

vibe coder코드를 이해하기보다 에이전트에 프롬프트만 던져 결과를 받는 방식으로 일하는 사람.

orphaned foreign key가리키는 행이 사라져 연결이 끊어진 외래키. 이사 간 주소로 계속 우편을 보내는 것과 비슷하다.