코딩 에이전트 시대의 의사결정 피로 — 코드는 쉬워졌는데 왜 더 지치는가

코드를 짜는 시간은 확실히 줄었다. 그런데 퇴근 시간이 당겨지진 않았다. 오히려 더 피곤하다는 개발자들이 많다. 무슨 일이 벌어지고 있는 걸까.

Smartsheet의 연구에서 단서가 나온다. 자동화 강도가 전년 대비 55% 증가했고, 전체 활동량은 46% 증가했다. 하루가 길어진 게 아니다. 같은 시간에 더 많은 결정을 내리고 있는 거다.

---

코드는 쉬워졌는데 왜 더 바쁜가

AI가 코드를 쓰기 전, 코드는 비쌌다. 엔지니어의 시간과 전문 지식이 코드의 단가를 결정했다. 그래서 LOC(코드 줄 수)나 커밋 수 같은 지표로 생산성을 측정했다. 어리석은 지표였지만 적어도 측정 가능했다.

지금은 이 지표들이 다시 돌아왔다. 에이전트로 생성한 코드 줄 수, 팀의 AI 코드 비율, 심지어 토큰 사용량으로 직원을 평가하는 회사까지 나왔다. Goodhart의 법칙이 이렇게 빠르게 적용된 적이 있었나.

[💡 잠깐! 이 용어는?] Goodhart의 법칙: "측정이 목표가 되는 순간, 그 측정값은 더 이상 좋은 지표가 아니다." LOC를 목표로 삼으면 불필요하게 긴 코드가 나오는 것처럼.

Smartsheet의 CPTO 프라티마 아로라가 구체적인 사례를 들었다. 팀에서 7배나 더 많은 코드를 생산하는 슈퍼스타 엔지니어가 있었다. 코드 품질도 좋았다. 문제는 팀의 나머지 여섯 명이 대부분의 시간을 그 코드를 리뷰하는 데 써야 했다는 점이다. 팀 전체의 산출물은 늘었지만, 대부분의 구성원은 생산자가 아니라 리뷰어가 됐다.

---

밀도만 높아지는 업무

코드 생성이 자동화되면, 개발자는 그 시간을 다른 데 쓸 수 있을 것 같다. 실제로는 다른 일이 그 자리를 채운다.

에이전트가 백그라운드에서 돌아가는 동안 개발자는 코드 리뷰를 하고, 미팅에 참석하고, 문서를 쓴다. 생산적인 느낌이 든다. 하지만 더 자세히 보면 이렇다.

"시간은 그대로인데 밀도가 달라졌다. 하루에 내리는 결정의 수, 정보를 모아서 판단으로 바꾸는 횟수가 달라진 거다." — 프라티마 아로라

SDLC(소프트웨어 개발 생명주기)에서 병목이 이동했다. 코드 작성은 쉬워졌고, 그 결과 코드 리뷰, DevOps, 보안, 인프라에 부담이 집중됐다.

[💡 잠깐! 이 용어는?] SDLC(Software Development Lifecycle): 요구사항 정의 → 설계 → 구현 → 테스트 → 배포 → 운영으로 이어지는 소프트웨어 개발 전체 흐름.

Smartsheet 연구에서 나온 또 다른 수치: AI가 생성한 코드의 80%는 사람이 편집한 후 최종 확정된다. 에이전트가 초안을 쓰고 사람이 마무리하는 구조다. 편집하려면 먼저 이해해야 한다. 이해하려면 컨텍스트가 필요하다. 컨텍스트를 수집하는 게 새로운 주업무가 됐다.

---

의사결정 피로란

의사결정 피로는 결정을 많이 내릴수록 이후 판단의 질이 떨어지는 현상이다. 대통령이나 CEO가 매일 같은 옷을 입는 이유가 여기 있다. 결정 하나를 아끼는 거다.

코드 리뷰가 왜 스트레스인지 생각해보면 이해가 된다. 좋은 코드 리뷰는 변경사항을 전체 시스템 맥락에서 평가한다. 시스템 전체의 컨텍스트를 머릿속에 넣고 유지해야 한다. 게다가 리뷰어는 게이트키퍼다. 내가 통과시킨 코드에 버그가 있으면 내 책임이 된다.

코드 리뷰 불안(code review anxiety)을 연구한 Intuit의 캐럴 리 박사는 이렇게 설명한다. "본질적으로 당신의 전문 지식을 기여하도록 요청받는 거다. 만약 리뷰를 잘못하면, 그 코드의 게이트키퍼였던 내 잘못이 된다. 그래서 압박이 크다."

여기에 AI 코드의 특성이 더해진다. 레거시 코드가 싫은 이유는 내가 쓰지 않아서다. 맥락을 모른다. AI 생성 코드도 마찬가지다. 아무도 그 코드를 원래 쓰지 않았다. 프롬프트, 스펙, 에이전트가 참조한 문서를 다시 파야 한다. 그게 더 많은 작업을 만든다.

---

시니어가 더 지치는 구조

여기서 역설이 나온다. AI 코딩 도구를 가장 잘 쓰는 사람은 시니어 개발자다. 그런데 Smartsheet 연구에 따르면 시니어들이 더 많은 컨텍스트를 로딩하고 더 작은 변경을 만들어 내고 있다.

아로라는 이렇게 설명했다. "시니어들이 컨텍스트를 훨씬 많이 로딩하고 더 작은 변경을 하는 걸 보게 된다. 결국 가장 복잡한 부분에 시니어가 투입되고, 그만큼 컨텍스트 부담이 크다. 코드 줄 수보다 컨텍스트가 핵심 변수가 된 거다."

비유하면 외과 수술과 비슷하다. AI가 절개 도구를 쥐어줬는데, 수술 전 준비(마취 점검, 환자 이력 파악, 합병증 대비)는 오히려 더 꼼꼼해야 한다. 메스를 자동화했다고 수술실이 쉬워지지 않는다.

역할	AI 이전	AI 이후
주니어 개발자	코드 작성 (단순 구현)	에이전트 프롬프트 + 결과 검증
미드레벨	설계 + 구현	코드 리뷰 부담 증가
시니어 개발자	아키텍처 + 중요 결정	컨텍스트 로딩 극대화 + 복잡 판단 집중

시니어의 판단력은 유한한 자원이다. 하루에 내릴 수 있는 좋은 결정의 수에는 한계가 있다.

---

SDLC 재설계의 필요성

지금의 SDLC는 AI가 없던 시대에 설계됐다. 개별 커밋마다 사람이 리뷰하고, 각 PR마다 게이트키퍼가 서는 구조다. 코드 생산 속도가 10배 빨라졌는데 리뷰 구조는 그대로다.

소프트웨어 테스트가 변화한 방식에서 힌트가 있다. 단위 테스트는 특정 커밋이 약속한 동작을 하는지 확인한다. E2E 테스트는 전체 흐름을 검증한다. 판단도 이렇게 나뉠 수 있다.

개별 커밋을 리뷰하는 것에서 최종 결과물을 검증하는 것으로 전환.

판단 게이트를 사이클의 시작과 끝에 배치하는 방향이다.

시작 게이트: 요구사항 정의, 가드레일, 스펙, 허용 의존성 끝 게이트: 성공/실패 기준, 보안, 신뢰성

Smartbear AI·아키텍처 VP 피츠 놀란의 말이 이 방향을 잘 요약한다. "의도, 기능, 요구사항 관점으로 생각하라. API 호출이나 입출력 형식 같은 저수준 용어로 생각하지 말 것. 개발 속도가 10배 빨라지면 QA 속도도 10배 빨라져야 한다."

생산성 측정 기준도 바뀌어야 한다. LOC와 커밋 수에서 **변경 실패율과 배포 빈도(DORA 지표)**로의 전환이다. 개인의 입력이 아닌 시스템의 출력을 측정하는 방향이다.

[💡 잠깐! 이 용어는?] DORA 지표: Google DevOps Research and Assessment 팀이 정의한 4가지 소프트웨어 딜리버리 지표. 배포 빈도, 변경 리드 타임, 서비스 복구 시간, 변경 실패율로 구성된다.

---

정리

코딩 에이전트가 만든 변화를 정리하면 이렇다.

• 코드 생산은 자동화됐지만, 판단과 리뷰는 사람에게 더 집중됐다.
• AI 생성 코드의 80%를 사람이 편집한다. 편집엔 컨텍스트가 필요하다.
• 시니어 개발자일수록 컨텍스트 로딩 부담이 크고, 의사결정 피로에 더 취약하다.
• 해결책은 SDLC 재설계다. 매 커밋 리뷰에서 시작/끝 게이트 중심으로 구조를 바꿔야 한다.
• 생산성 측정도 바뀌어야 한다. LOC가 아닌 변경 실패율과 배포 빈도.

결국 에이전트 시대의 핵심 역량은 코드를 빠르게 생성하는 것이 아니라, 무엇을 만들지 판단하고 결과를 검증하는 것이다. 판단력은 근육이고, 근육은 회복 시간이 필요하다.

---

참고:

• StackOverflow Blog 원문: https://stackoverflow.blog/2026/05/21/coding-agents-are-giving-everyone-decision-fatigue/
• Smartsheet AI 연구: https://www.smartsheet.com/content-center/inside-smartsheet/research/ai-making-work-denser-not-lighter
• DORA 지표 소개: https://stackoverflow.blog/2021/11/29/the-four-engineering-metrics-that-will-streamline-your-software-delivery/