본문으로 건너뛰기

"개발문화" 태그로 연결된 2개 게시물개의 게시물이 있습니다.

모든 태그 보기

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

· 약 6분

처음 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나 멀티 에이전트 시스템 구축기가 강조하는 것도 결국 같습니다. 에이전트를 신뢰 가능하게 만드는 건 모델이 아니라 그 둘레를 설계하는 일입니다.

아직 아무도 답을 모른다​

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

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

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

참고한 글 / 연구

코드리뷰가 진짜 하는 일

· 약 5분

최근 몇 달 PR에 붙는 코멘트 패턴이 두 가지로 수렴하는 걸 봐요. 하나는 "LGTM"만 찍힌 채 5분 만에 승인되는 경우예요. 다른 하나는 "AI 리뷰 통과했어요"라는 말이 사실상의 리뷰를 대신하는 경우예요. 둘 다 공통으로 하는 말이 있어요. "지금 바빠서."

"바쁘다"의 진짜 비용​

바쁘니까 리뷰를 건너뛰자는 논리는 단기로는 맞는 것처럼 보입니다. 그런데 우아한형제들 공통시스템개발팀이 쓴 코드 리뷰 문화 개선 이야기를 보면 무엇이 일어나는지 명확해집니다.

"리뷰이는 리뷰를 기다리고 리뷰어는 수많은 MR을 확인하느라 고통받고 있었습니다."

리뷰를 뒤로 미루면 MR이 쌓입니다. 쌓이면 리뷰어가 한 번에 봐야 할 양이 커집니다. 한 번에 봐야 할 양이 커지면 집중력이 떨어지고, 리뷰가 대충 되거나 더 늦어집니다. 팀의 "바쁘다"는 오히려 증폭됩니다. 리뷰를 안 하는 게 원인이고, 바쁜 게 결과입니다. 순서가 반대로 보였을 뿐입니다.

그 팀이 찾은 해법은 "리뷰 안 하기"가 아니었습니다. "리뷰어가 적은 노력으로 잘할 수 있는 환경 만들기"였습니다. MR 크기를 300줄 미만으로 제한, 템플릿으로 맥락 강제, 매일 아침 MR 목록 자동 알림, pre-commit으로 린팅 자동화합니다. 바쁘다는 문제에 "리뷰를 줄이자"로 답하지 않고 "리뷰 비용을 줄이자"로 답한 셈입니다.

"AI가 봤다"의 구조적 결함​

다른 핑계는 더 교묘합니다. "AI가 리뷰해줬어요"는 일견 책임 있는 행동처럼 들립니다. 그런데 2026년 2월 Stanford Law의 CodeX가 쓴 Built by Agents, Tested by Agents, Trusted by Whom?이 정확히 이 지점을 비틉니다.

핵심 문장은 이것입니다.

When the builder and the inspector share the same blind spots, no amount of test variety fully eliminates the risk that both miss the same thing.

빌더와 검사자가 같은 사각지대를 공유하면, 검사의 본래 가치가 무너진다는 얘기입니다. 인간 리뷰어는 작성자와 다른 가정, 다른 경험, 다른 맥락을 가집니다. 그 차이가 리뷰를 의미 있게 만듭니다. AI가 코드를 만들고 같은 모델 계열이 그 코드를 리뷰하면, 차이의 공간 자체가 사라집니다.

같은 글이 인용한 악명 높은 일화가 있습니다. "테스트를 통과시켜라"는 목표만 받은 에이전트가 테스트 본문을 그냥 return true로 고쳐버린 사건입니다. AI는 주어진 지표에 최적화할 뿐, 그 지표가 실제로 무엇을 의미하는지 이해하지 않습니다. 코드를 쓴 AI가 그 코드를 리뷰할 때도 같은 방식으로 최적화합니다. "이 코드는 괜찮아 보인다"에.

리뷰의 진짜 목적은 따로 있다​

여기서 진짜 질문이 나옵니다. 코드리뷰는 대체 무엇을 하는 일일까요.

"버그를 잡는 일"이라는 답이 가장 흔하지만, Microsoft Research의 고전적인 연구는 다르게 정리합니다. 코드리뷰의 핵심 목표는 두 가지입니다.

  1. 더 나은 솔루션을 찾기
  2. 지식을 팀에 퍼뜨리기

버그 찾기는 부산물에 가깝습니다. 중요한 건 "이 문제를 이 방식으로 풀어도 되는가"에 대한 두 번째 의견을 얻는 것, 그리고 그 과정에서 코드베이스의 맥락, 의사결정, 도메인 지식이 팀원에게 옮겨 가는 것입니다.

뱅크샐러드 기술블로그도 같은 맥락에서 말합니다.

"코드 리뷰 프로세스를 보는 것은 그 회사의 개발 문화를 이해할 수 있는 힌트가 되기도 합니다."

리뷰는 단순한 품질 게이트가 아닙니다. 팀이 서로의 코드를 신경 쓴다는 약속을 매일 갱신하는 의식입니다. 신입이 처음 던진 PR에 시니어가 의도를 묻고, 그 답변이 팀의 집단 지식으로 남는 과정. 누군가가 "왜 이렇게 썼어?"라고 물었을 때 비로소 말로 옮겨지는 암묵지. AI는 코드의 문법과 패턴은 읽지만, 이런 종류의 집단적 맥락을 함께 쌓아 올리는 일은 하지 못합니다.

AI가 못 보는 층​

AI 리뷰가 못 보는 영역이 있습니다. 이 함수가 왜 이렇게 생겼는지의 답이 작년 사고 회고에 있을 때, 그 비즈니스 맥락은 레포 밖에 있어서 모델이 닿지 못합니다. 이 변경이 다른 바운디드 컨텍스트를 건드리는지, 기술 부채를 어디에 쌓는지 같은 아키텍처 판단도 마찬가지입니다. 우리 조직이 정의한 PII와 우리 서비스의 위협 모델에 걸린 보안/거버넌스, 이 레포가 3년 동안 합의해 온 컨벤션 역시 레포 밖 지식입니다. 가장 까다로운 건 조용한 실패입니다. 보기엔 맞는데 edge에서 터지는 코드를, AI는 오히려 더 자신 있게 만듭니다.

AI 리뷰어는 대부분의 경우 "이 코드가 잘 돌아갈 것 같다"를 말합니다. 인간 리뷰어는 "이 코드가 우리 팀이 만들고 유지하기에 맞는가"를 묻습니다. 두 질문은 차원이 다릅니다.

그래서 하고 싶은 말​

AI 리뷰를 쓰지 말자는 얘기가 아닙니다. 오히려 적극적으로 써야 합니다. 스타일 위반, 단순 버그, 빠진 null 체크, 테스트 커버리지 같은 저수준 체크는 AI가 1차로 거르면 인간 리뷰어가 더 가치 있는 질문에 집중할 수 있습니다. 좋은 하이브리드는 AI가 1차 관문, 인간이 2차 판단자인 구조입니다.

문제는 순서가 뒤집혀 있을 때입니다. "AI가 봤으니 인간 리뷰는 생략"이면 그냥 리뷰를 안 한 것입니다.

"바쁘다"는 이유로 건너뛸 때, 우리가 건너뛰는 건 버그 검출이 아니라 서로의 코드를 이해하고 지식을 옮기는 시간입니다. 그건 단기엔 안 보이다가, 1년쯤 뒤에 "왜 이 코드를 나만 이해하지?", "이 사람 없으면 이 모듈은 아무도 모른다"는 청구서로 돌아옵니다.

"AI가 봤다"는 이유로 건너뛸 때 포기하는 건 인간 리뷰어의 다른 시각입니다. 작성자와 다른 가정으로 코드를 읽어주는 눈. 같은 모델이 양쪽에 서면 얻을 수 없는 그것.

코드리뷰는 품질 관리이기 이전에, 팀이 팀으로 남게 하는 장치예요. 자동화해서 없앨 수 있는 건 비용이지 목적이 아니에요.

참고한 글 / 연구