20년차 개발자가 18개월간 Claude Code를 쓰다가 전면 중단을 선언했고, 그 글이 2026년 개발 커뮤니티를 흔들었습니다. 그런데 이건 러다이트의 글이 아닙니다 — 1983년 배인브리지가 예측한 '자동화의 역설'이 소프트웨어에서 처음 대규모로 재현된 사건입니다. METR·DORA·GitClear·Veracode의 상반된 데이터를 전부 펼쳐놓고, 같은 도구가 에어비앤비에서는 18개월을 6주로 줄이고 그에게는 우울증을 준 이유를 끝까지 따져봅니다.
2026년 8월, brettcodes.com에 「I'm done using AI」라는 글이 올라왔습니다. 20년차 개발자가 AI 코딩 도구를 전면 중단하겠다고 선언하는 글입니다.
이런 글은 흔합니다. 그런데 이 글이 유독 크게 번진 이유가 있습니다. 그가 안 써본 사람이 아니기 때문입니다.
그는 2025년 초부터 약 18개월간 Cursor, Zed, Claude Code를 진지하게 썼습니다. 그리고 2026년 중반에는 이런 상태에 도달했습니다.
Linear를 Claude Code에 연결해서, 코드를 한 줄도 직접 편집하지 않고 사소하지 않은 프로젝트를 처음부터 끝까지 만들어냈다.
에이전트 코딩이 약속했던 바로 그 지점입니다. 그리고 정확히 그 지점에서 그는 그만뒀습니다.
"이 방식으로는 계속 일할 수 없었다. 분명히 말해서, 그것이 내 삶을 망치고 있었기 때문이다."
이 글은 그를 옹호하지도, 반박하지도 않습니다. 대신 세 가지를 합니다.
첫째, 그의 경험을 데이터로 검증합니다. 2025~2026년에 쌓인 연구들은 서로 정면으로 충돌하는데, 그 충돌 자체가 이 현상을 설명합니다. 둘째, 이 현상의 이름을 찾습니다. 놀랍게도 1983년에 이미 정확히 예측되어 있었고, 항공업계는 40년째 이 문제와 싸우고 있습니다. 셋째, 그래서 어떻게 배치할 것인지를 설계합니다. 같은 도구가 에어비앤비에서는 18개월치 작업을 6주로 줄였습니다. 차이는 모델이 아니라 배치에 있었습니다.
먼저 한 가지만 짚고 갑니다. 이 글의 결론은 "AI를 쓰지 말자"도 "그는 틀렸다"도 아닙니다.
그의 진단은 대체로 정확했습니다. 다만 그가 찾은 해법이 '전부 그만두기' 하나뿐이었다는 것 — 그게 진짜 문제입니다.
글에 흩어져 있는 이유를 분류하면 다섯 갈래입니다. 그리고 이 다섯 개는 성격이 전혀 다릅니다. 뒤섞어서 읽으면 논지가 흐려지므로 나눠 봅시다.
| 분류 | 그가 말한 것 | 검증 가능한가 |
|---|---|---|
| ① 역할 변화 | 작성자에서 리뷰어가 되면서 우울과 무기력이 왔다. 자기가 더 이상 쓰지 않는 소프트웨어로부터 "거리감"을 느꼈다. | 그렇다 — 3부의 이론과 6부의 연구가 정확히 이걸 설명한다 |
| ② 품질 | 속도는 빨라졌지만 소프트웨어 품질이 나빠졌다 | 그렇다 — 2부의 GitClear·Veracode·DORA 데이터 |
| ③ 학습 상실 | 장인정신과 배움의 기회를 잃었다 | 부분적으로 — 인지 부채 연구와 항공 사례 |
| ④ 환경·윤리 | 데이터센터의 전력·물 소비, "훔친 출처"로 학습한 데이터 | 쟁점이 갈린다 — 이 글의 범위를 넘어선다 |
| ⑤ 존재론적 불안 | 자기 커리어의 미래에 대한 실존적 공포 | 부분적으로 — 9부의 고용 데이터 |
이 글이 다루는 것은 ①②③⑤입니다. ④는 중요하지만 별도의 글이 필요한 주제이고, 이 글에서 다루면 나머지 논의가 묻힙니다.
그의 글에서 가장 많이 인용된 대목은 감정적인 부분이 아니라 이 실무적 관찰입니다. 그는 "사소한 작업에만 AI를 쓰기"를 시도했지만 유지하지 못했다고 말합니다.
"AI가 전부 다 할 수 있는데 테스트를 직접 타이핑하고 있으면 바보 같이 느껴진다."
이 문장이 중요한 이유는, 이것이 감정 고백이 아니라 구조적 관찰이기 때문입니다. 한계비용이 0에 수렴하는 도구 앞에서 "여기까지만 쓰겠다"는 개인의 의지는 안정적인 균형점이 아닙니다. 경계는 계속 밀립니다.
이 문제는 6부에서 경사면 문제라는 이름으로 다시 다루고, 7부에서 해법을 제시합니다. 미리 요약하면 이렇습니다 — 경계를 의지가 아니라 구조로 박아야 합니다.
주목할 만한 대목이 하나 더 있습니다. 환멸의 시기에 그는 취미 게임 프로그래밍으로 돌아가 Playdate용 게임 코딩 책을 완성했고, Rust로 Usagi라는 2D Lua 게임 엔진을 만들었습니다.
즉 그는 프로그래밍이 싫어진 게 아닙니다. 프로그래밍은 여전히 좋아했고, 일에서만 그것이 사라진 상태였습니다. 이 구분이 이 글 전체의 열쇠입니다.
여기서부터가 이 글의 본론입니다. "AI 코딩이 생산성을 올리는가"라는 질문에 2026년 현재 정직한 답은 하나가 아닙니다. 연구들이 서로 다른 방향을 가리키는데, 그 불일치가 우연이 아니라 정보입니다.
함께 읽기: 이 논쟁의 정반대 극단 — Redis를 만든 antirez의 "코드를 읽지 말고 아이디어만 보라"는 주장 — 은 코드를 보지 마라, 아이디어를 잡아라에서 다뤘습니다. 그 글이 수용의 극단이라면 이 글은 거부의 극단이고, 둘은 같은 데이터를 놓고 반대편에 섭니다. 아래 증거 중 METR·GitClear는 그 글에서 더 깊이 파고들었으니, 여기서는 요점만 짚고 그 글에 없던 증거들(대규모 긍정 RCT, 보안, 신뢰도, METR 자신의 2026년 철회)에 무게를 둡니다.
가장 규모가 큰 긍정적 증거는 마이크로소프트·MIT·프린스턴·와튼 연구진이 수행하고 『Management Science』에 실린 세 건의 무작위 대조 실험입니다. 마이크로소프트, 액센츄어, 그리고 포춘 100대 기업 한 곳에서 개발자 4,867명을 대상으로 GitHub Copilot 사용군과 대조군을 비교했습니다.
주목할 점이 두 개 있습니다. 코드 품질에서 부정적 영향은 관측되지 않았고, 경험이 적은 개발자일수록 이득이 컸습니다. 이건 이 글 후반의 논의에 계속 등장하는 사실입니다.
2025년 7월, METR이 발표한 무작위 대조 실험은 정반대 결과를 냈습니다. 숙련 오픈소스 개발자 16명에게 자기 저장소의 실제 이슈 246개를 주고, 과제별로 AI 사용 허용/금지를 무작위 배정했습니다.
| 시점 | 측정한 것 | 결과 |
|---|---|---|
| 실험 전 | 개발자들의 예상 | AI가 24% 빠르게 해줄 것 |
| 실험 후 | 개발자들의 체감 | AI가 20% 빠르게 해줬다 |
| 실측 | 실제 소요 시간 | 19% 느려졌다 |
세 갈래 괴리입니다. 그리고 이 실험의 진짜 발견은 "AI가 느리다"가 아니라 "당사자가 자기 생산성을 정확히 측정하지 못한다"입니다. 39%포인트의 간극을 본인들은 전혀 눈치채지 못했습니다.
여기서 이 글은 정직해야 합니다. METR 자신이 2026년 2월에 이 결과를 "역사적(historical)"이라고 표시하고 실험 설계를 바꿨습니다. 그들의 설명은 이렇습니다.
그러니 이 수치를 "AI는 개발자를 느리게 만든다"의 증명으로 쓰면 안 됩니다. 이 실험이 확실하게 증명한 것은 체감과 실측이 크게 어긋난다는 사실 하나입니다. 그것만으로도 충분히 중요합니다.
구글의 2025년 DORA 리포트는 개인이 아니라 조직 단위를 봅니다. 그리고 이 리포트의 결론이 이 논쟁에서 가장 균형 잡힌 그림입니다.
| 지표 | 2024년 리포트 | 2025년 리포트 |
|---|---|---|
| 처리량(throughput) | 음의 관계 | 양의 관계로 전환 — AI 채택이 처리량과 제품 성과를 함께 끌어올린다 |
| 안정성(instability) | 부정적 | 여전히 부정적 — 계획에 없던 긴급 배포가 늘어난다 |
DORA가 지목한 원인은 명확합니다. 볼륨입니다. AI는 코드 생성 속도를 리뷰·테스트·배포 인프라가 흡수할 수 있는 속도보다 빠르게 만듭니다. 강한 자동화 테스트, 성숙한 버전 관리, 빠른 피드백 루프 같은 통제 시스템이 없는 조직에서는 변경량 증가가 곧 불안정성 증가가 됩니다.
그래서 DORA 2025의 표어가 "AI는 증폭기(amplifier)"입니다. 잘하는 조직은 더 잘하게 되고, 망가진 조직은 더 빠르게 망가집니다. 도구가 아니라 주변 관행이 결과를 결정합니다.
GitClear는 수억 줄의 커밋 변경을 추적해 코드베이스의 모양이 어떻게 바뀌는지를 봅니다. 2026년 연구는 특히 뼈아픕니다.
| 지표 | 변화 | 무엇을 뜻하나 |
|---|---|---|
| 커밋 내 복사·붙여넣기 | +41% | 같은 코드가 여러 곳에 복제된다 |
| 코드 블록 중복 | +81% (2023 대비, 사상 최고) | 고쳐야 할 때 여러 곳을 고쳐야 한다 |
| 오류 은폐 구문 | +47% | 예외를 삼키는 코드가 늘었다 |
| 2주 내 코드 처닝 | +15% | 쓴 지 2주 만에 다시 고치는 코드 |
| 리팩터링(이동) 라인 | −70% | 아무도 정리하지 않는다 |
| 'moved' 코드 비율 | 2022년 21% → 2026년 3.8% | 구조 개선이 사실상 멈췄다 |
가장 상징적인 사실은 이겁니다. 2024년은 기록상 처음으로 '복사·붙여넣기'가 '리팩터링'을 넘어선 해였습니다.
원인 분석도 설득력이 있습니다. 어시스턴트는 탭 한 번으로 새 코드 블록을 삽입하기는 쉽게 만들지만, "이미 코드베이스 어딘가에 있는 비슷한 함수를 재사용하라"고 제안하지는 잘 못합니다. 컨텍스트 창의 한계가 구조적으로 중복을 유도합니다.
(이 지표들의 연도별 추이와 리뷰 병목 데이터는 antirez 편의 8부에서 더 자세히 다뤘습니다.)
Veracode는 100개 이상의 모델에 자바·파이썬·C#·자바스크립트 80개 코딩 과제를 시켜 결과물을 보안 테스트했습니다.
생성된 코드의 45%가 OWASP Top 10 취약점을 포함했고, 이 비율은 2025년부터 2026년 초까지 여러 차례의 테스트 주기에서 개선되지 않았습니다. 모델 성능은 계속 올랐는데 보안 통과율은 제자리입니다.
이유는 생각해보면 당연합니다. 모델은 "동작하는 코드"를 목표로 학습됐지 "공격당하지 않는 코드"를 목표로 학습되지 않았습니다. 그리고 학습 데이터인 공개 코드의 상당수가 이미 취약합니다.
마지막으로 2025년 스택오버플로 개발자 설문입니다. 채택률과 신뢰도가 반대 방향으로 움직였습니다.
| 항목 | 수치 |
|---|---|
| AI 도구를 쓰거나 쓸 예정 | 84% |
| 정확성을 신뢰 | 40%(2024) → 29% |
| 불신(46%) vs 신뢰(33%) | 불신이 더 많다 |
| "매우 신뢰" | 3% |
| 불만 1위 | "거의 맞는데 딱 맞지는 않은" 코드 (45%) |
| 그 코드 고치는 데 시간이 더 든다 | 66% |
이 마지막 두 줄이 앞으로 이 글에서 계속 돌아올 지점입니다. 완전히 틀린 코드는 싸게 걸러집니다. 진짜 비싼 것은 거의 맞는 코드입니다.
Brett이 경험한 것은 이 지표들이 한 사람 안에서 동시에 일어난 상태입니다. 빨라졌고, 품질은 나빠졌고, 본인은 그 균형을 정확히 볼 수 없었습니다.
Brett의 글에서 가장 많이 조롱받은 대목은 "리뷰어가 되면서 우울해졌다"는 부분입니다. 배부른 소리라는 반응이 많았습니다.
그런데 이건 감상이 아닙니다. 1983년에 학술적으로 예측되어 있었고, 항공업계는 그 이후 40년간 이 문제와 싸워 왔습니다.
1983년, 인지심리학자 리샌 배인브리지(Lisanne Bainbridge)는 『Automatica』에 「Ironies of Automation」이라는 짧은 논문(브리프 페이퍼)을 실었습니다. 자동화 설계의 고전이 된 글이고, 발표 40년이 지난 지금도 인용 수가 계속 늘고 있습니다.
논문의 뼈대는 두 개의 역설입니다.
여기에 딸린 개념이 루프 밖 성능 문제(out-of-the-loop performance problem)입니다. 시스템에서 능동적 관여가 사라진 사람은 단지 연습만 잃는 게 아니라 상황 인식(situation awareness) — 지금 시스템이 무엇을 왜 하고 있는지에 대한 살아 있는 감각 — 을 잃습니다. 그리고 그 감각이야말로 개입이 필요한 순간에 필요한 바로 그것입니다.
이 이론이 가장 극적으로 확인된 곳이 항공입니다.
1997년, 아메리칸항공의 기장 워런 밴더버그(Warren VanderBurgh)는 사내 강연에서 자기 회사 조종사들을 이렇게 불렀습니다. "마젠타 선의 아이들(Children of the Magenta Line)." 비행 컴퓨터가 항법 디스플레이에 그려주는 마젠타색 경로선을 따라가는 데 너무 익숙해져서, 비행기를 조종하는 대신 자동화를 관리하게 됐다는 지적이었습니다. 그 결과 손으로 비행하는 능력이 퇴화하고 있었습니다.
당시 그가 인용한 수치는 항공 사고의 68%가 자동화 의존과 관련되어 있다는 것이었습니다.
그리고 2009년, 에어프랑스 447편이 대서양에 추락했습니다. 속도 센서(피토관)가 결빙되자 오토파일럿이 스스로 해제되며 멀쩡한 비행기를 조종사에게 돌려줬습니다. 보호 기능도 함께 축소된 상태였습니다. 조종간을 잡은 부조종사는 기수를 들어올렸고, 항공기는 실속에 빠졌습니다. 실속 경보가 울리는 동안에도 조종실의 누구도 자신들에게 무슨 일이 벌어지고 있는지 파악하지 못했습니다.
이후 FAA는 조종사들에게 수동 비행 연습을 권고하는 안전 경보(SAFO)를 발행했습니다. 자동화를 끄라는 게 아니라, 의도적으로 손으로 비행하는 시간을 확보하라는 것이었습니다.
이제 대응표를 보십시오. 놀라울 만큼 정확하게 겹칩니다.
| 항공 | 소프트웨어 (2026) |
|---|---|
| 조종사 | 개발자 |
| 오토파일럿 · FMS | 코딩 에이전트 |
| 마젠타 선을 따라가기 | 에이전트가 만든 diff를 승인하기 |
| 수동 비행 능력의 퇴화 | 직접 설계·디버깅 능력의 퇴화 |
| 자동화 해제 = 가장 어려운 상황 | 프로덕션 장애 = 아무도 이 코드를 안 써봤다 |
| 상황 인식 상실 | "이 시스템이 왜 이렇게 동작하는지 모르겠다" |
| FAA의 수동 비행 권고 | 7부의 '손코딩 예산' |
Brett이 "작성자에서 리뷰어가 되면서 무기력해졌다"고 쓴 것은, 배인브리지의 언어로 옮기면 역설 1의 정확한 서술입니다. 그에게 남은 일은 쉬워진 게 아니라 자동화하기 어려웠던 잔여물만 남은 상태 — 즉 판단, 검증, 책임뿐이었습니다. 재미있는 부분(문제를 풀어내는 과정)은 전부 기계로 넘어갔고, 지루하고 어려운 부분(남의 코드를 읽고 틀린 곳을 찾는 일)만 남았습니다.
그리고 그가 느낀 "소프트웨어로부터의 거리감"은 상황 인식의 상실입니다.
배인브리지 프레임의 가치는 비관이 아니라 처방의 방향을 바꾼다는 데 있습니다.
| 흔한 처방 | 배인브리지가 시사하는 처방 |
|---|---|
| "AI를 더 잘 쓰는 법을 배워라" | 사람이 루프 안에 남는 지점을 설계하라 |
| "리뷰를 더 열심히 해라" | 리뷰만 남기지 말고 직접 만드는 몫을 보존하라 |
| "어차피 다 자동화된다" | 자동화율이 높아질수록 사람 숙련도 요구는 올라간다 |
| "도구를 쓸지 말지 정해라" | 쓰되 무엇을 남길지를 정해라 |
Brett의 존재론적 불안(⑤)은 개인적 감정이 아니라 업계의 오래된 공포입니다. 그런데 이 공포의 역사를 알면 두 가지가 동시에 보입니다 — 왜 매번 틀렸는지, 그리고 왜 이번에는 조금 다른지.
| 시기 | 약속 | 실제로 벌어진 일 |
|---|---|---|
| 1957 FORTRAN | 수학자가 직접 식을 쓰면 되니 프로그래머가 필요 없다 | 어셈블리 프로그래머가 고급 언어 프로그래머가 됐다 |
| 1982 제임스 마틴 | 『Application Development Without Programmers』 — 제목 자체가 시대의 낙관 | 4GL은 단순 조회·리포트에서만 통했다 |
| 1980s말~90s초 CASE 도구 | 다이어그램으로 시스템 전체를 모델링하면 완전한 앱이 생성된다 | 대부분 실패. 생성 코드는 비효율적이고 커스터마이즈가 어려웠다. 결정적으로 정확한 다이어그램을 그리는 일이 프로그래밍만큼 어려웠다. |
| 2000s 오프쇼어링 | 개발을 통째로 외주화하면 된다 | 명세와 커뮤니케이션 비용이 절감분을 잡아먹었다 |
| 2010s 로우코드·노코드 | 비개발자가 드래그로 앱을 만든다 | 단순 워크플로에는 성공. 복잡해지는 순간 '시민 개발자'가 다시 개발자가 됐다 |
| 2020s LLM | 자연어로 말하면 코드가 나온다 | 이번엔 다르다 — 다만 사람들이 생각하는 방식으로는 아니다 |
CASE 도구의 실패 원인이 특히 시사적입니다. 모델을 정확하게 그리려면 프로그래밍과 같은 종류의 논리적 엄밀성이 필요했습니다. 즉 '프로그래밍을 없앤 것'이 아니라 '프로그래밍을 다이어그램으로 옮긴 것'뿐이었습니다. 그래서 아무도 실질적인 이득을 못 봤습니다.
매 파도가 프로그래머를 없애는 대신 새로운 종류의 프로그래머를 만들었습니다.
1986년 프레드 브룩스는 「No Silver Bullet」에서 소프트웨어의 어려움을 둘로 나눴습니다.
| 복잡성 | 정의 | 예시 |
|---|---|---|
| 우발적 accidental | 본질과 무관하게 도구와 방법이 만들어낸 어려움 | 메모리 수동 관리, 빌드 설정, 보일러플레이트, 테스트 프레임워크 마이그레이션 |
| 본질적 essential | 무엇을 왜 만들지 이해하는 환원 불가능한 어려움 | 요구사항 정의, 개념적 일관성, 트레이드오프 판단, "이건 만들지 말자" |
브룩스의 주장은 "지금까지의 모든 도구는 우발적 복잡성만 공격했고, 그래서 10배 향상은 오지 않는다"였습니다. 40년간 이 예측은 대체로 맞았습니다.
그럼 LLM은 왜 다른가. 여기서 정직해야 합니다. 이번 파도는 앞선 것들과 구조적으로 다른 점이 하나 있습니다.
이 세 번째 칸이 이 글에서 가장 중요한 문장일지 모릅니다. AI 코딩의 불만은 "AI가 못해서"가 아니라 "AI가 잘해서" 생깁니다. 재미있는 부분이 먼저 자동화되기 때문입니다. 그리고 그건 배인브리지의 역설 1과 정확히 같은 이야기입니다.
지금까지 읽으면 "그래서 AI 코딩은 실패인가"로 기울 수 있습니다. 아닙니다. 같은 도구가 어떤 문제에서는 압도적으로 작동합니다. 그리고 그 차이가 어디서 오는지를 아는 것이 이 글에서 가장 실무적인 부분입니다.
2025년 에어비앤비 엔지니어링 팀은 React 테스트 3,500개 파일을 Enzyme에서 React Testing Library로 마이그레이션했습니다. 수작업 추정치는 18개월이었습니다.
| 항목 | 결과 |
|---|---|
| 총 소요 기간 | 6주 (추정 18개월 대비) |
| 투입 엔지니어 | 6명 |
| 첫 4시간 | 전체 파일의 75% 자동 마이그레이션 완료 |
| 4일 후 | 97% 완료 |
| 나머지 3%(약 100개) | LLM 출력을 출발점으로 삼아 수동 마무리 |
| 테스트 의도·커버리지 | 유지됨. 마이그레이션된 테스트는 검증을 통과했다. |
방법론도 인상적입니다. "샘플 → 튜닝 → 스윕(sample, tune, sweep)" 루프입니다. 실패한 케이스를 사람이 분석하고, 그 실패 원인을 겨냥해 프롬프트와 스크립트를 고치고, 해당 파일들만 다시 돌립니다. 사람은 개별 파일을 고치지 않고 루프를 고쳤습니다.
이 사례와 Brett의 상황을 나란히 놓으면 차이가 선명합니다.
| 조건 | 에어비앤비 마이그레이션 | Brett의 일상 개발 |
|---|---|---|
| ① 검증 함수가 있는가 | 있다 — 테스트가 통과하는지 기계가 판정한다 | 없다 — "이게 좋은 설계인가"는 기계가 못 답한다 |
| ② 정답이 정의되는가 | 있다 — 동작 보존. 목표가 명확하다. | 모호하다 — 요구사항 자체가 협상 중이다 |
| ③ 반복적·대량인가 | 3,500개 동형 작업 | 매번 다른 일회성 문제 |
| ④ 되돌리기 싼가 | 싸다 — 실패해도 원본 파일이 그대로다 | 비싸다 — 잘못된 설계는 몇 달 뒤에 청구된다 |
| ⑤ 사람이 루프 안에 있는가 | 있다 — 사람이 실패를 분류하고 루프를 고쳤다 | 없다 — 사람은 diff 승인 버튼 옆에 있었다 |
같은 모델, 같은 도구입니다. 다른 것은 문제의 모양과 배치뿐입니다.
그리고 ⑤가 결정적입니다. 에어비앤비 엔지니어들은 리뷰어가 되지 않았습니다. 그들은 자동화 자체를 설계하는 사람으로 남았습니다. 배인브리지의 표현을 빌리면, 이들은 루프 밖으로 밀려난 게 아니라 한 단계 위의 루프 안으로 옮겨갔습니다.
같은 다섯 조건을 만족하는 작업 유형을 모아보면 패턴이 보입니다.
| 잘 되는 작업 | 왜 |
|---|---|
| 프레임워크·언어 버전 마이그레이션 | 검증 함수(테스트·컴파일) 존재, 동형 반복, 정답 명확 |
| 테스트 코드 생성 (기존 동작 기준) | 실행이 곧 검증. 실패해도 손해가 작다. |
| 정형화된 보일러플레이트·스캐폴딩 | 본질적 복잡성이 거의 0인 영역 |
| 대량 리네이밍·API 시그니처 변경 | 컴파일러가 판정자 역할을 한다 |
| 로그·에러 메시지 분석, 재현 스크립트 작성 | 탐색 비용이 높고 검증은 즉시 가능 |
| 익숙하지 않은 언어·라이브러리 첫 진입 | 대규모 RCT에서 경험이 적을수록 이득이 컸던 이유 |
| 잘 안 되는 작업 | 왜 |
|---|---|
| 핵심 도메인 모델 설계 | 본질적 복잡성 그 자체. 검증 함수가 없다. |
| 성숙한 대형 코드베이스의 미묘한 수정 | METR 실험 조건이 정확히 이것이었다 |
| 보안이 중요한 코드 | Veracode 45% 실패율 |
| 원인이 불명확한 프로덕션 장애 | 상황 인식이 필요한데, 그게 바로 위축된 능력이다 |
| "왜 이렇게 되어 있지?"를 밝히는 일 | 코드에 없는 맥락이 답이다 |
조직 지표가 좋아져도 개인은 무너질 수 있습니다. 그 간극을 만드는 메커니즘이 세 개입니다.
생성 비용은 0에 수렴했지만 검증 비용은 그대로입니다. 이 비대칭이 모든 문제의 뿌리입니다.
그리고 검증 비용은 코드의 정확도에 따라 선형이 아닙니다.
명백히 틀린 코드는 컴파일조차 안 되니 1초 만에 걸러집니다. 완전히 맞는 코드는 읽고 넘어가면 됩니다. 문제는 95% 맞는 코드입니다. 겉보기에 합리적이고, 대부분의 경우에 동작하고, 특정 경계 조건에서만 틀립니다. 이걸 찾으려면 처음부터 직접 쓰는 것보다 더 깊이 이해해야 합니다.
스택오버플로 응답자의 45%가 불만 1위로 꼽은 것이 정확히 이겁니다. 그리고 66%가 그 코드를 고치는 데 시간이 더 든다고 답했습니다.
이것이 METR의 19% 슬로다운을 설명하는 가장 그럴듯한 가설입니다. 성숙한 코드베이스에서 숙련자가 하는 일은 대부분 경계 조건 판단인데, AI는 정확히 그 영역에서 "거의 맞는" 답을 대량 생산합니다.
실무 함의: 생성 속도를 자랑하는 지표(코드 라인 수, PR 수)는 이 비용을 전혀 잡지 못합니다. 측정해야 할 것은 생산량이 아니라 검증 처리량입니다.
Brett의 "테스트를 직접 치는 게 바보 같이 느껴진다"가 여기 해당합니다.
한계비용이 0에 가까운 도구 앞에서는, 매 순간 "이번만 쓰는 것"이 언제나 합리적입니다. 그래서 부분 사용은 안정적인 균형점이 아닙니다. 경계는 매일 조금씩 밀리고, 어느 날 돌아보면 아무것도 직접 쓰지 않고 있습니다.
각 화살표는 개별적으로 다 합리적입니다. 그런데 도착점은 아무도 원하지 않았던 곳입니다.
해법은 의지가 아니라 구조입니다. 다이어트가 의지로 안 되는 것과 같은 이유입니다. 7부에서 다룹니다.
MIT 미디어랩의 인지 부채 연구는 에세이 쓰기 실험이었지만, 결과는 코딩에 그대로 옮겨집니다. LLM 사용 그룹은 뇌 영역 간 연결성이 가장 약했고, 방금 자기가 제출한 문장조차 인용하지 못했으며, 결과물에 대한 소유감이 가장 낮았습니다.
Brett의 표현 — "내가 더 이상 쓰지 않는 소프트웨어로부터 거리감을 느꼈다" — 은 이 발견의 1인칭 서술입니다.
여기에 동기 이론을 겹치면 그림이 완성됩니다. 자기결정이론은 내재적 동기의 세 축으로 자율성 · 유능감 · 관계성을 듭니다.
| 축 | 에이전트 중심 워크플로에서 벌어지는 일 |
|---|---|
| 자율성 | 시작점이 "관리자의 도입 압박"이었다면 이미 훼손된 상태로 출발한다 |
| 유능감 | 내가 잘해서 된 것인지 모델이 잘해서 된 것인지 구분되지 않는다. 성공이 자기 효능감으로 환산되지 않는다. |
| 관계성 | 코드로 동료와 나누던 대화(리뷰·페어)가 기계와의 대화로 대체된다 |
세 축이 동시에 깎이면 무기력이 옵니다. 이것이 Brett이 "우울과 무관심"이라고 부른 상태의 구조적 설명입니다. 그리고 그가 취미 게임 개발로 회복했다는 사실이 이 진단을 뒷받침합니다 — 거기서는 세 축이 모두 살아 있었습니다.
여기가 이 글의 결론부입니다. 원칙은 하나입니다.
도구를 쓸지 말지를 정하지 말고, 사람에게 무엇을 남길지를 정하십시오.
| 개입 | 근거 | 구체적 실행 |
|---|---|---|
| 흡수 능력부터 키운다 | DORA: 불안정성의 원인은 생성이 아니라 흡수 실패 | 테스트·CI·자동 롤백이 없는 팀은 AI 도입 이전에 그것부터. 순서를 바꾸면 손해가 커진다. |
| 볼륨을 제어한다 | 리뷰 처리량이 진짜 병목 | PR 크기 상한, 하루 머지 개수 상한, 리뷰 SLA |
| 보안 게이트를 강제한다 | Veracode: 45%가 OWASP 취약점, 2년째 개선 없음 | AI 코드 여부와 무관하게 SAST·의존성 스캔을 머지 조건으로 |
| 구조 지표를 본다 | GitClear: 중복 +81%, 리팩터링 −70% | 복붙 비율·중복 블록·'moved' 라인 비율을 대시보드에 올린다. 안 보면 반드시 나빠진다. |
| 주니어의 몫을 지정한다 | 스탠퍼드: 22~25세 AI 노출 직군 고용 격차 19% | 에이전트가 주니어 업무를 먹으면 5년 뒤 시니어가 없다. 주니어에게 남길 작업을 명시적으로 예약할 것. |
| 온콜 규칙을 바꾼다 | 아무도 안 써본 코드가 프로덕션에 있다 | 머지한 사람이 아니라 "설명할 수 있는 사람"을 담당자로. 설명 가능자가 없으면 머지 불가. |
이 글이 Brett의 편을 드는 글로 읽히면 곤란하므로, 그의 글의 약한 곳도 짚습니다.
| 약점 | 내용 |
|---|---|
| n=1 | 한 사람의 경험이다. 같은 도구로 커리어 만족도가 올라간 사람도 많다. |
| 교란 요인 | 번아웃, 조직 문화, 강제 도입에 대한 반발이 도구 효과와 뒤엉켜 있다. "AI 때문"과 "AI를 강요당했기 때문"은 다른 진단이다. |
| 전부 아니면 전무 | 경사면 문제는 실재하지만, 해법이 전면 중단뿐인 것은 아니다. 7부의 구조적 경계가 대안이다. |
| 환경·윤리 논거 | 중요한 쟁점이지만 그의 글에서는 수치 없이 제시된다. 별도의 검증이 필요하다. |
그리고 AI 코딩이 실제로 준 것도 명확합니다.
그럼에도 그의 글이 중요한 이유는 하나입니다. 조직 지표는 개인이 지불하는 비용을 잡지 못합니다. DORA는 배포 빈도를 재지 개발자의 존재론적 불안을 재지 않고, 생산성 대시보드에는 "이 사람이 5년 뒤에도 이 시스템을 이해할 수 있는가"를 재는 칸이 없습니다.
Brett의 글은 그 재지 않는 항목에 대한 보고서입니다. 그래서 데이터가 아니라 증언의 형태로 왔고, 그래서 널리 퍼졌습니다.
| 흐름 | 주장 | 증거 |
|---|---|---|
| ① 크래프트 회귀 | 손으로 만드는 것에 다시 가치를 둔다. "Not By AI" 배지, 인간이 만든 소프트웨어 선언, 아티저널 코딩 담론. | Brett의 글이 여기 속한다. 규모는 작지만 목소리는 크다. |
| ② 검증 중심 엔지니어링 | 생성은 맡기되 명세와 검증을 인간의 일로 재정의한다. 스펙 주도 개발, AGENTS.md, EARS 수용 기준. | 현재 가장 실용적인 주류. 글쓰기 편에서 다뤘다. |
| ③ 자동화 심화 | 사람을 루프에서 더 빼는 방향. 에이전트가 계획·구현·검증까지. | Anthropic Economic Index: Claude Code 대화의 79%가 '자동화' 유형(claude.ai는 49%) |
마지막 데이터가 의미심장합니다. Anthropic Economic Index는 사용 패턴을 자동화(AI가 직접 수행)와 증강(AI가 사람 능력을 보완)으로 나누는데, 에이전트 도구인 Claude Code는 자동화 비중이 79%로 채팅형(49%)보다 압도적으로 높습니다.
즉 에이전트 도구는 구조적으로 사람을 루프 밖으로 밉니다. 이건 사용자의 게으름이 아니라 도구 형태의 귀결입니다. 그리고 배인브리지가 1983년에 경고한 것이 정확히 이 상태입니다.
Brett의 존재론적 불안에는 데이터가 있습니다. 스탠퍼드 디지털 이코노미 랩의 「Canaries in the Coal Mine?」는 ADP의 고빈도 행정 데이터로 미국 노동시장을 추적합니다.
| 발견 | 수치 | 해석 |
|---|---|---|
| 22~25세, AI 노출 직군 | 덜 노출된 또래 대비 19% 낮은 고용 (2026년 8월 기준, 2025년 8월 최초 관측 이후 계속 확대) | 소프트웨어 개발자가 대표적 노출 직군 |
| 경력자 | 유사한 격차 없음 | 대체가 아니라 입구가 좁아지는 중 |
| 경로 | 해고가 아니라 신규 채용 감소 | 조용히 진행되므로 늦게 발견된다 |
이 데이터가 7부의 "주니어 몫 예약"을 단순한 온정주의가 아니라 인력 파이프라인 관리의 문제로 만듭니다. 지금 주니어에게 아무것도 안 남기는 조직은 5년 뒤 시니어를 외부에서 사와야 하고, 그때는 모두가 같은 처지일 겁니다.
작업을 시작하기 전 30초. 다섯 개 중 네 개 이상 '예'면 에이전트에게 넘겨도 안전합니다.
출발점
이론
데이터
이어서 읽기
Brett의 글이 널리 퍼진 이유는 그가 옳아서가 아닙니다. 그가 끝까지 가봤기 때문입니다.
에이전트 코딩이 약속한 지점 — 코드를 한 줄도 건드리지 않고 프로젝트가 완성되는 상태 — 에 실제로 도달한 사람이 거기서 무엇을 발견했는지에 대한 1인칭 보고서이기 때문입니다. 그리고 그가 발견한 것은 43년 전 논문이 예측한 그대로였습니다. 재미있는 부분이 먼저 자동화되고, 사람에게는 판단과 책임만 남고, 남은 그 일을 할 능력은 조용히 녹슨다.
그래서 이 글의 마지막 질문은 "그가 옳았는가"가 아닙니다.
왜 그에게는 '전부 그만두기' 말고 다른 선택지가 없었는가.
그의 조직에는 손코딩 예산도, 작업 분류 기준도, 주니어에게 남길 몫도, 흡수 능력에 대한 투자도 없었습니다. 있었던 것은 도입 압박뿐이었습니다. 그런 환경에서 개인이 취할 수 있는 유일한 방어가 전면 중단이라면, 그건 그 개인의 극단성이 아니라 설계의 부재입니다.
그 선택지를 만드는 것이 2026년 엔지니어링 리더십의 일입니다. 도구를 도입하는 것보다 훨씬 어렵고, 훨씬 중요합니다.
RELATED
