↓ 본문으로 건너뛰기
dbalog journal
  1. Posts/

AI한테 일을 넘겼는데 왜 더 지칠까

·6 분
생각 AI 에이전트 개발생산성 DX 개발문화
목차

처음 AI 코딩 에이전트를 제대로 붙여 쓰기 시작했을 때 많은 사람이 비슷한 말을 했다. “나만의 주니어 개발자가 생긴 것 같다.” boilerplate를 대신 쳐주고, 귀찮은 wiring을 처리하고, 테스트를 만들고, 막혀 있던 작업을 앞으로 밀어준다. 손이 하나 더 생긴 기분이었다.

요즘은 한 발 더 나갔다. 멀티 에이전트, 레포 전체를 이해하는 에이전트, 여러 작업을 병렬로 돌리는 오케스트레이션까지. 이제는 “주니어 한 명"이 아니라 “AI 작업자 여러 명을 운영하는” 쪽에 가깝다.

그런데 이상한 일이 생긴다. 코드는 분명히 빨리 나오는데, 하루를 마치면 예전보다 더 지친다. 어제보다 하루 더 늙어서 피곤한 줄 알았는데, 관련 논문이 있더라고요.

생산성은 올랐는데 경험은 나빠졌다
#

2026년 5월에 나온 논문 한 편이 이 막연한 감각을 데이터로 보여준다. Annie Vella와 Kelly Blincoe가 쓴 The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study다. 6개월 간격으로 같은 개발자들에게 두 번 설문을 돌린 종단 연구다(처음 158명, 추적 101명, 두 시점이 매칭되는 95명).

두 시점에서 공통으로 나온 결과는 우리가 기대하던 그림이다.

  • 82%가 코드를 직접 “작성"하는 데 쓰는 시간이 줄었다.
  • 84%가 생산성이 좋아졌다고 답했다.

그런데 같은 기간, 다른 숫자가 반대로 움직였다.

개발자 경험(DX)이 한 가지 이상 영역에서 나빠졌다고 답한 비율이 14%에서 27%로 거의 두 배가 됐다.

구체적으로는 몰입(flow)이 떨어지고 인지 부하가 늘었다. 피드백 루프 같은 일부 항목은 오히려 좋아졌지만, 전체적으로 “일하는 느낌"은 나빠진 쪽이 늘어난 것이다. 논문은 이걸 생산성-경험 역설(productivity-experience paradox)이라고 부른다. 더 많은 일을 더 빨리 처리하는데, 정작 일하는 경험은 꼭 같이 좋아지지 않는다.

일이 ‘짜는 것’에서 ‘판단하는 것’으로 옮겨갔다
#

같은 논문이 짚는 핵심은 노동의 성격이 바뀌었다는 점이다. 개발자의 일이 작성(creation)에서 검증·평가·수정·조율 쪽으로 옮겨간다. 논문은 이 새로운 노동에 감독 엔지니어링(supervisory engineering work)이라는 이름을 붙인다. 코드를 짜는 게 아니라, AI가 짠 코드를 방향 잡고 평가하고 고치는 일이 업무의 중심이 된다는 것이다.

극단적인 사례는 OpenAI가 직접 올렸다. Harness engineering이라는 글에서, 5개월 동안 약 100만 줄짜리 베타 제품을 만들었는데 사람이 직접 친 코드는 사실상 0줄이었다고 한다. 그동안 엔지니어가 한 일은 코드 작성이 아니라, 에이전트가 신뢰할 만한 결과를 내도록 환경·피드백 루프·제약을 설계하는 것이었다. 그들이 그 환경을 부르는 이름이 하니스(harness)다.

이게 공짜로 굴러가지는 않는다. 자율 코딩 에이전트의 PR 45만 건을 분석한 The Rise of AI Teammates in Software Engineering (SE) 3.0은, 에이전트가 사람보다 빠르게 코드를 올리지만 그 PR의 수용률은 더 낮고 코드 구조는 더 단순하다는 걸 보여준다. 빨리 만든다고 다 받아들여지는 게 아니다. 누군가는 그걸 읽고, 믿어도 되는지 판단해야 한다. 그 “누군가"는 여전히 사람이다.

사람의 검토 용량은 그대로다
#

여기서 진짜 병목이 드러난다. AI는 거대한 diff를 병렬로 빠르게 쏟아낸다. 그런데 사람이 코드를 읽고 이해하는 속도는 10년 전과 거의 같다. 생산 쪽만 폭발적으로 빨라지고, 검토 쪽은 그대로다. 이 비대칭이 피로의 한 축이다.

더 고약한 건 LLM이 “이해한 느낌"을 아주 강하게 준다는 점이다. 변경마다 자연어 설명이 붙으니, 읽었다고 느끼지만 실제로 상태가 어떻게 바뀌는지는 다 못 따라가는 상태에 쉽게 빠진다. 그러다 보면 “AI가 그렇게 했는데요"가 점점 자연스러운 말이 된다. 이게 단순한 태만이 아닐 수도 있다는 게 무서운 지점이다. AI가 만들어내는 작업량이 이미 사람의 검토 용량을 넘어섰다는 신호일 수 있다.

코드리뷰가 버그 잡기보다 지식을 옮기는 일에 가깝다는 이야기는 따로 한 번 정리한 적 있다. 검토가 무너지면 잃는 건 버그 검출이 아니라 그쪽이다.

예전의 피로와는 결이 다르다
#

흥미로운 건 이 피로가 옛날 구현 피로와 성격이 다르다는 점이다.

예전 개발은 깊은 몰입(flow), 단일 맥락, 긴 집중 상태를 오래 유지하는 일이 많았다. 반면 에이전트 워크플로는 백그라운드 작업, 폴링, 승인, 여러 세션 동시 모니터링, 부분 집중, 끊임없는 맥락 전환을 요구한다. 겉보기엔 “덜 일하는 것"처럼 보이는데, 실제로는 사람이 계속 감독 상태에 머물게 된다.

이건 구현자의 피로라기보다 관리자의 피로에 가깝다. 결정 피로(decision fatigue), 잘게 쪼개진 주의력, 상황을 계속 파악하고 있어야 한다는 부담. 업계에서는 이걸 판단 세금(judgment tax)이라고 부르기도 한다. 코드를 만드는 마찰은 사라졌는데, 그 코드를 믿어도 되는지 판단하는 부담은 그대로거나 오히려 늘었다는 것이다.

장기적으로는 다른 비용도 붙는다. The Augmentation Trap은 단기 생산성을 위해 AI에 기대다 보면 그 생산성을 떠받치던 숙련 자체가 침식될 수 있다고 본다. 편해질수록 판단력이 약해지는 메커니즘은 전에 한 번 다뤘으니 여기서는 줄인다. 요지는, 지금 느끼는 피로가 미래의 능력을 당겨쓴 결과일 수도 있다는 것이다.

진짜 질문은 다른 데 있다
#

지금 AI 논의는 대개 “개발자가 사라지나"에 쏠려 있다. 그런데 위 흐름을 보면 더 중요한 질문은 따로 있다.

사람이 AI 작업자들을 어떻게 감독하고, 이해 가능한 상태로 유지할 것인가.

평가(eval) 설계, 거버넌스, 감독, 오케스트레이션 같은 영역이 빠르게 중요해지는 이유다. The Productivity-Reliability Paradox는 진짜 병목이 모델 성능이 아니라 사양(specification) 규율이라고까지 말한다. 무엇을 시킬지 정확히 정의하지 못하면, 더 빠른 에이전트는 더 빠르게 틀린 것을 만들어낼 뿐이다. Anthropic의 Building Effective Agents나 멀티 에이전트 시스템 구축기가 강조하는 것도 결국 같다. 에이전트를 신뢰 가능하게 만드는 건 모델이 아니라 그 둘레를 설계하는 일이다.

아직 아무도 답을 모른다
#

조심할 부분은, 이 변화가 아직 정리된 상태가 아니라는 점이다. 지금 연구들은 관찰 연구, 설문, 인터뷰, 초기 사용 패턴 분석 수준이 많다. 지금의 인지 부담이 단순한 과도기 현상인지, 아니면 에이전트 기반 개발의 구조적 특성인지는 아직 아무도 확신하지 못한다.

다만 분명한 건 하나다. 우리는 “코딩을 더 빠르게 하는 도구"를 하나 들인 게 아니다. 개발자의 역할, 검토 문화, 일의 구조 자체를 바꾸는 무언가를 들였다.

그러니 더 피곤한 게 이상한 일은 아니다. 일의 종류가 바뀌었으니까. 생산성 지표만 보면 보이지 않는 비용이, 조용히 경험 쪽에 쌓이고 있을 뿐이다. 어제보다 하루 더 늙어서가 아니라.

참고한 글 / 연구

관련 글