AI는 소프트웨어 엔지니어링을 더 어렵게 만들었다

원문: AI Didn’t Make Software Engineering Easier. It Made the Hard Parts Harder. — Praveen Rajamani (dev.to, 2026-05-14)

들어가며

AI 도구를 진지하게 사용하기 시작했을 때, 대부분의 개발자들은 같은 기대를 품는다.
“AI가 보일러플레이트를 맡고, 나는 흥미로운 부분에 집중한다.”

Praveen Rajamani도 그랬다. 그런데 실제로는? 흥미로운 부분이 더 어렵고, 더 빈번하고, 더 소진되는 방향으로 변했다.
Google Staff Engineer가 연봉도 복지도 아닌 “일이 너무 서두르고, 의미가 줄었다” 는 이유로 회사를 떠난 사건이 바이럴됐다.
AI가 가장 기술력 있는 조직 중 하나인 Google에서도 이런 영향을 미친다면, 실제로 무슨 일이 벌어지고 있는지 따져볼 필요가 있다.

핵심 주장

기존 소프트웨어 엔지니어링의 구조: 80/20 법칙

원문의 저자는 소프트웨어 엔지니어링을 두 가지 층위로 구분한다.

실행(Execution) — 80%

• 보일러플레이트 코드 작성
• 반복적인 버그 수정
• 티켓 이동 및 문서 업데이트
• 설정 및 환경 구성
• 알려진 동작에 대한 테스트 작성

깊은 사고(Deep Thinking) — 20%

• 진짜 문제 이해
• 제약 조건 속에서의 시스템 설계
• 아무도 예측하지 못한 엣지 케이스 디버깅
• 불완전한 정보 속에서의 트레이드오프 결정
• 무엇을 만들지 않을 것인가 판단

80%는 반드시 필요하지만 학습 가능한 ‘잡무’였다. 20%가 진짜 시니어 엔지니어가 경험으로 가치를 증명하는 영역이었다.

개인적으로도, 조직에서도 오랫동안 공유해온 원칙이 이 구분과 정확히 맞닿아 있다. 루틴한 업무는 기계적으로 최소한의 리소스만 들여 신속히 처리하고, 확보한 시간을 프로세스 개선과 창의적인 업무에 배분하자. 반복 업무를 단순화해 객관적인 시선으로 개선점을 찾다 보면, 비로소 본질적인 작업에 집중할 여유가 생긴다. AI는 이 원칙을 실현하는 데 있어 지금껏 존재한 도구 중 가장 강력한 수단이다. 문제는 그 도구를 ‘어떻게’ 쓰느냐다.

AI가 80%를 삼켜버렸다 — 이제 20%가 전부다

Claude Code, Cursor, GitHub Copilot 같은 도구들은 실행 계층에서 탁월하다. 보일러플레이트는 사라지고, CRUD 엔드포인트는 몇 초 만에 생성되며, 반복적인 테스트는 커피를 다 마시기 전에 완성된다.

그런데 아무도 소리 내어 말하지 않은 것이 있다:

20%는 지속적이고 깊은 집중력을 요구하기 때문에 어려웠다. 이제 엔지니어들은 거기에 영구적으로 살도록 요구받는다 — 그런데 인간의 뇌는 그것을 위해 설계되지 않았다.

보일러플레이트를 세 시간 쓰는 것은 지루하지만 뇌는 회복된다. 세 시간을 분산 시스템의 장애 모드를 설계하고, 아키텍처 트레이드오프를 결정하고, 특정 부하 조건에서만 나타나는 레이스 컨디션을 디버깅하는 데 쓰는 것 — 그것은 완전히 다른 종류의 피로다.

AI는 이 일의 빈도를 줄이지 않는다. 오히려 늘린다.

아무도 인간의 컨텍스트 윈도우에 대해 이야기하지 않는다

AI 세계에서는 모델의 컨텍스트 윈도우에 대한 논의가 끊임없이 이루어진다.
토큰을 얼마나 보유할 수 있는가? 검색을 어떻게 최적화할 것인가?

그런데 아무도 이야기하지 않는 또 다른 컨텍스트 윈도우가 있다.

⚠️ 인간 엔지니어의 컨텍스트 윈도우는 커지지 않는다.
항상 같은 뇌다 — 이제 더 많은 아키텍처 복잡도를 보유하고, 불확실성 속에서 더 빠르게 결정을 내리고, 예전보다 더 자주 시스템 사이를 컨텍스트 스위칭하도록 요구받는다.
모델과 달리, 더 긴 컨텍스트로 업그레이드할 수 없다. 전전두엽 피질에 RAM을 추가할 수 없다.

구글 엔지니어가 새벽 2시에 페이지를 받고 새벽 5-6시까지 잠을 이루지 못했다는 것은 생산성 문제가 아니다. 인지 부하 문제다.

뇌과학적으로도 이는 뒷받침된다. 인간의 뇌는 소위 ‘멍때리는 시간’ 과 같은 정서적 완충 지대 — 신경과학에서 말하는 디폴트 모드 네트워크(Default Mode Network) — 가 있어야 비로소 창의성을 발휘할 수 있다. 집중 모드에서 확산 모드로 전환되는 그 여백이 통찰과 창의적 연결을 만들어낸다. 예전의 80%가 바로 그 역할을 했다 — 루틴한 실행 업무가 사실은 뇌의 재충전 시간이었던 것이다. AI가 그것을 빼앗아가자, 뇌는 쉬지 못한 채 깊은 사고만 끊임없이 요구받는 상황이 됐다.

실제로 이렇게 느껴진다

저자는 이론이 아닌 일상의 경험을 이야기한다.

• 생산성 향상은 실재한다 — 더 빠르게 출시한다
• 그러나 인지 부하 역시 그 어느 때보다 높다
• 실행에서 아낀 모든 시간은 곧바로 더 어려운 사고에 투입된다
• 예전엔 며칠 걸리던 아키텍처 결정이 이제 몇 시간 안에 이루어져야 한다 — 실행 작업이 자연스러운 사고 시간을 주었던 것이 사라졌기 때문이다

“나는 코드를 덜 쓰고 있지 않다. 더 많은 결정을 내리고 있다. 그리고 결정이 비싼 부분이다.”

실전 교훈 — 원문에서 도출한 것들

1. 딥워크 시간을 그 어느 때보다 강력히 보호하라

AI가 얕은 작업을 처리할 때, 얕은 방해가 비례적으로 더 큰 피해를 낳는다.
예전에는 10분을 날렸다면, 이제는 Slack 알림 하나가 아키텍처 결정을 날릴 수 있다.
매일 아침 AI를 열기 전에 최소 두 시간을 차단하는 것이 실질적인 차이를 만든다.

2. “생각할 시간이 필요하다"는 말을 편안하게 하라

AI가 가능하게 하는 속도는 더 빨리 결정하라는 압박을 만든다.
저항하라. “제대로 생각해보겠습니다” 를 전문적인 응답으로 대우하는 것이 지금 가장 과소평가된 기술 중 하나다.

3. 인지 회복을 업무의 일부로 다루어라

예전의 80%는 자연스러운 뇌 회복을 제공했다 — 깊은 사고에서 루틴 실행으로 전환하는 것이 위장된 휴식이었다.
그 휴식이 사라졌다. 딥워크 세션을 저부하 작업으로 의도적으로 마무리하는 것이 실질적인 차이를 만든다.

4. AI를 언제 쓰지 않을지 알아라 — 이해 부채를 경계하라

느리게 코드를 쓰는 것이 시스템을 이해하는 데 도움이 될 때가 있다.

저자는 AI에게 전체 데이터 패칭 레이어를 생성하게 했다. 깔끔해 보였고 빠른 리뷰를 통과했으며 배포했다. 3주 후 캐싱 버그를 맞닥뜨렸는데 디버깅할 수 없었다 — 레이어가 실제로 어떻게 작동하는지 이해한 적이 없었기 때문이다. 직접 작성했다면 두 시간이면 됐을 것을 이틀을 썼다.

이해 부채(comprehension debt)는 실재하며 최악의 순간에 나타난다.

보안 측면에서의 추가 관점

댓글에서 보안 엔지니어 Ofri Peretz가 날카로운 데이터를 더한다:

“AI가 생성한 함수의 63%에서 보안 취약점이 발견됐다. 누락은 대부분 ‘부정 공간(negative space)’ — 인증 체크, 입력 유효성 검사, 프롬프트에서 명명되지 않은 보안 강화. 없는 것을 위한 검토는 있는 것을 작성하는 것보다 더 어려운 인지 작업이다.”

이것이 80/20 프레임의 핵심이다: “AI가 우리를 빠르게 만든다” 와 “일이 더 어렵게 느껴진다” 는 것이 동시에 사실인 이유.

주니어 개발자 문제 — 가장 중요한 질문

저자가 마지막으로 던지는 질문이 가장 묵직하다:

20%에 해당하는 것들 — 시스템 설계, 트레이드오프, 불확실성 속의 디버깅, 무엇을 만들지 않을 것인가 판단 — 이것은 개발자가 수년에 걸쳐 쌓는 것이었다.
주니어 엔지니어들은 80%의 실행 작업 위에 쌓인 토대 위에서 그것을 점진적으로 쌓았다.
그 토대가 이제 빠르게 사라지고 있다.

댓글에서 인용된 스파이더맨의 대사가 이를 완벽하게 요약한다:

Peter: “이게 전부야! 나는 이 슈트 없이는 아무것도 아니야!”
Tony: “슈트 없이 아무것도 아니라면, 그 슈트를 가져선 안 돼.”

AI에 지나치게 의존하는 주니어 개발자는 의도적으로 자신의 성장을 방해하고 있다.

조직의 함정 — 창의성을 고갈시키는 구조

원글의 지적에 한 가지를 더 얹고 싶다. 개인의 인지 부하 문제보다 조직 차원에서 더 위험한 패턴이 이미 곳곳에서 벌어지고 있다.

AI 도입으로 인적 리소스를 감축한 채, 남겨진 사람들에게 난이도 높은 창의적 업무만 몰아주는 방식이다. 단기적으로는 생산성이 오르는 것처럼 보인다. 머릿수는 줄었는데 결과물은 나오니까. 하지만 이것은 인간의 본성을 무시한 설계다.

창의성은 무한히 쥐어짤 수 있는 자원이 아니다. 정서적 완충 없이 창의성만 요구받는 환경은 결국:

• 창의성을 소모품처럼 빠르게 고갈시킨다
• 조기 번아웃을 유발한다
• 장기적으로는 개인도, 조직 전체도 생산성을 떨어뜨린다

소수 정예에게 모든 인지 부하를 집중시키는 것은 단기 스프린트에서나 통하는 전략이다. 마라톤에서는 오히려 독이 된다. 진정한 의미에서 AI를 잘 도입한다는 것은 사람을 줄이는 것이 아니라, 남아있는 사람이 더 잘 숨 쉴 수 있는 구조를 만드는 것이어야 한다.

결론

“AI는 엔지니어를 대체하는 것이 아니다. 엔지니어가 해야 할 모든 것의 타임라인을 압축하고 있다. 그것이 선물인지 부담인지는 오로지 남겨진 것을 얼마나 의도적으로 관리하느냐에 달려 있다.”

AI 시대의 소프트웨어 엔지니어에게 요구되는 것은 달라졌다.
더 많은 코드를 생산하는 능력이 아니라, 더 나은 판단을 더 빠르게 내리는 능력, 그리고 그 판단 능력을 잃지 않도록 인지 건강을 의도적으로 관리하는 능력이다.

AI 도구를 쓸수록 느리게 생각하는 연습을 더 의도적으로 해야 한다는 역설 — 이것이 지금 이 시대 개발자에게 필요한 가장 중요한 통찰이다.