AI는 일을 줄인 게 아니라 쉬운 일을 먼저 가져갔다

2026.09.18

#AI코딩 #개발자생산성 #인지부하 #AI리터러시 #에이전틱AI #검증

AI는 일을 줄인 게 아니라 쉬운 일을 먼저 가져갔다 블로그 커버 이미지 — AI가 반복 작업을 줄이면 사람은 더 편해질 것 같지만, 실제로는 판단과 검증의 밀도가 높아질 수 있다.

AI는 개발을 쉽게 만든 게 아니라, 쉬운 부분을 먼저 가져갔다.

요즘 이 생각을 자주 한다. 처음에는 반대로 느껴진다. AI 코딩 도구를 쓰면 상투적인 코드가 빨리 나온다. 테스트 초안도 만들고, 문서 초안도 쓰고, 반복적인 함수도 금방 채운다. 예전 같으면 손으로 쳤을 코드를 몇 초 만에 만든다.

당연히 편해진 것처럼 보인다.

그런데 하루 전체를 놓고 보면 체감이 조금 다르다. 손은 덜 움직이는데 머리는 더 피곤하다. 코드를 쓰는 시간은 줄었는데, 코드를 읽고 의심하고 고치고 검증하는 시간이 늘어난다. 예전에는 쉬운 일과 어려운 일이 하루 안에 섞여 있었다. 지루한 작업도 있었고, 머리를 세게 써야 하는 작업도 있었다. 그런데 AI가 쉬운 작업을 먼저 가져가면 사람에게 남는 것은 대체로 어려운 일이다.

설계. 맥락 판단. 리뷰. 검증. 책임.

그래서 AI 시대의 피로는 단순히 노동량에서 오지 않는다. 판단량에서 온다.

AI는 쉬운 과제에서 먼저 빛난다

AI 코딩 도구가 효과 없다는 말이 아니다. 오히려 특정한 종류의 일에서는 효과가 분명하다.

GitHub Copilot 초기 실험을 보면 참가자들은 JavaScript로 HTTP 서버를 구현하는 표준화된 과제를 수행했다. Copilot을 쓴 그룹은 통제 그룹보다 55.8% 빠르게 과제를 끝냈다. 짧고 비교적 정형화된 과제에서 AI가 얼마나 강한지 보여주는 결과다.

이런 일은 AI에게 잘 맞는다.

보일러플레이트 코드
반복적인 함수
테스트 초안
문서 초안
익숙한 API 사용 예시
뻔한 리팩터링 후보

문제는 개발자의 일이 원래 이런 작업만으로 되어 있지 않다는 점이다. 실제 업무에는 레거시 맥락이 있고, 팀의 암묵적 규칙이 있고, 배포 리스크가 있고, 사용자가 이미 의존하고 있는 이상한 예외가 있다. 코드 한 줄이 맞느냐보다, 그 코드가 이 시스템 안에서 맞느냐가 더 중요해진다.

AI는 첫 번째 질문에는 강하다. 두 번째 질문에서는 아직 자주 미끄러진다.

복잡한 코드베이스에서는 다른 일이 벌어진다

METR의 2025년 연구는 이 지점을 잘 보여준다. 연구진은 경험 많은 오픈소스 개발자 16명에게 자신이 오래 기여해 온 대형 저장소의 실제 이슈 246개를 처리하게 했다. 각 이슈는 AI 사용 허용 조건과 비허용 조건으로 무작위 배정됐다.

결과가 흥미롭다. AI 사용이 허용됐을 때 개발자들은 오히려 19% 더 오래 걸렸다. 더 흥미로운 건 체감이다. 작업 전 개발자들은 AI가 24% 정도 빠르게 해줄 것이라고 예상했고, 실험 후에도 AI 덕분에 20% 빨라졌다고 느꼈다. 실제 측정은 반대였다.

이 연구 하나로 모든 AI 코딩 도구를 일반화할 수는 없다. 연구진도 특정 시점, 특정 도구, 특정 업무 환경의 스냅샷이라고 조심스럽게 말한다. 그래도 이 연구가 던지는 질문은 무시하기 어렵다.

AI를 쓰면 왜 빨라진 것처럼 느끼는데, 실제로는 느려질 수 있을까.

내가 보기에는 이유가 단순하다. AI는 작성의 고통을 줄여준다. 대신 검토의 고통을 만든다.

예전에는 내가 직접 천천히 썼다. 속도는 느렸지만, 쓰는 동안 이미 어느 정도 이해가 생겼다. AI가 만든 코드는 다르다. 결과물이 먼저 도착한다. 사람은 그 결과물을 따라가며 읽어야 한다. 왜 이렇게 썼는지, 어디까지 맞는지, 무엇이 빠졌는지, 기존 시스템과 충돌하지 않는지 다시 따져야 한다.

작성은 빨라졌는데 이해는 자동으로 따라오지 않는다.

개발자의 일은 작성에서 감독으로 이동한다

2026년 종단 연구는 이 변화를 꽤 적절한 말로 설명한다. AI 코딩 도구가 개발자의 시간을 creation에서 verification으로 옮기고 있으며, 이를 supervisory engineering work라고 부른다. 말 그대로 감독하는 엔지니어링이다.

이 표현이 마음에 든다.

AI를 쓰는 개발자는 더 이상 순수한 작성자만이 아니다. 작은 팀의 리더처럼 행동해야 한다. AI에게 일을 시키고, 나온 결과를 읽고, 틀린 부분을 고치고, 전체 방향을 다시 잡고, 최종 책임을 진다.

이건 코딩을 못 하게 된다는 말이 아니다. 코딩의 성격이 바뀐다는 말이다.

예전의 개발자는 직접 삽을 들고 땅을 팠다. 지금의 개발자는 굴착기를 다루는 사람에 가깝다. 굴착기가 있으면 더 많은 흙을 움직일 수 있다. 하지만 그만큼 더 넓은 범위를 봐야 한다. 어디를 파야 하는지, 어디를 건드리면 안 되는지, 장비가 엉뚱한 방향으로 움직일 때 어떻게 멈출지 알아야 한다.

AI 코딩도 비슷하다. 산출량은 늘 수 있다. 하지만 산출량이 늘면 검수량도 늘어난다.

쉬운 일은 정말로 없애야 할 낭비였을까

여기서 한 가지 불편한 질문이 생긴다.

우리가 없애고 싶어 한 쉬운 일은 정말 전부 낭비였을까.

반복 작업은 분명 지루하다. 개발자가 하루 종일 보일러플레이트만 치는 건 좋은 일이 아니다. 하지만 모든 반복 작업이 순수한 낭비는 아니다. 쉬운 작업은 때로 머리가 어려운 문제에서 잠깐 떨어지는 시간이다.

인지심리학의 incubation 연구를 보면, 창의적 문제 해결에서는 잠시 문제에서 떨어지는 시간이 도움이 될 수 있다. Baird와 동료들의 연구는 부담이 낮은 과제를 수행하는 동안 마음이 어느 정도 떠도는 상태가 창의적 문제 해결에 도움될 수 있음을 보였다. 2025년 Scientific Reports 연구도 창의적 글쓰기 과제에서 incubation 중 mind wandering이 특정 조건에서 창의적 향상과 관련된다고 보고했다.

물론 이걸 과장하면 안 된다. 단순 반복 작업이 언제나 창의성을 높인다는 뜻은 아니다. 그래도 한 가지는 말할 수 있다.

쉬운 일은 가끔 완충 구간이었다.

테스트 이름을 고치고, 간단한 매핑 코드를 쓰고, 문서 문장을 다듬고, 뻔한 함수를 정리하는 동안 머리는 종종 다른 문제를 배경에서 굴린다. 아까 막혔던 설계가 떠오르기도 하고, 리뷰에서 찜찜했던 부분이 다시 생각나기도 한다. 손은 단순한 일을 하지만 머리는 완전히 멈춰 있지 않다.

AI가 이런 완충 구간을 모두 가져가면 사람은 더 고급스러운 일만 하게 될까. 꼭 그렇지만은 않다. 사람에게는 끊임없는 판단만 남을 수 있다.

자동화는 일을 없애지 않고 감시 업무를 만든다

이건 소프트웨어 개발만의 문제가 아니다. 자동화 연구에서는 오래전부터 비슷한 문제가 논의됐다. 자동화는 인간의 일을 완전히 없애는 대신, 인간을 감시자와 검증자로 바꾼다.

자동화 편향 연구는 사용자가 자동화된 의사결정 지원에 과도하게 의존할 때 정보 탐색과 처리의 경계심이 줄어들 수 있다고 설명한다. 특히 검증이 복잡한 작업에서는 자동화 결과를 확인하는 일 자체가 높은 인지 부하를 만든다.

AI 코딩 도구도 마찬가지다.

AI가 만든 코드는 보기에는 그럴듯하다. 변수명도 그럴듯하고, 구조도 그럴듯하고, 주석도 그럴듯하다. 하지만 그럴듯함은 정확함이 아니다. 오히려 그럴듯하기 때문에 검토가 더 어렵다. 엉망인 코드는 금방 버리면 된다. 꽤 괜찮아 보이는 코드는 어디가 틀렸는지 찾아야 한다.

이때 개발자는 두 가지 위험 사이에 놓인다.

하나는 과신이다. AI가 만든 결과를 너무 쉽게 받아들이는 것이다.

다른 하나는 과검증이다. AI가 만든 모든 것을 의심하느라 오히려 더 오래 걸리고 더 지치는 것이다.

둘 다 피곤하다.

생산성을 코드 작성 속도로만 보면 놓치는 것

개발자 생산성을 한 가지 숫자로 보려는 유혹은 오래됐다. 커밋 수, PR 수, 코드 라인 수, 이슈 처리 수 같은 지표는 보기 쉽다. AI 도입 이후에는 여기에 생성 코드량과 자동완성 수용률까지 붙는다.

하지만 SPACE 프레임워크가 말하듯, 개발자 생산성은 단일 지표로 잡히지 않는다. 만족과 웰빙, 성과, 활동, 커뮤니케이션과 협업, 효율과 흐름을 함께 봐야 한다.

AI 도구가 코드 작성 시간을 줄였다고 해서 팀이 더 건강해졌다는 뜻은 아니다. PR이 늘었다고 해서 제품 품질이 좋아졌다는 뜻도 아니다. 더 많은 코드가 더 많은 리뷰 대기열과 더 많은 재작업을 만들 수도 있다.

Google Cloud가 2025년 DORA Report를 소개하며 쓴 표현도 이와 닿아 있다. AI는 팀을 고쳐주는 물건이 아니라 증폭기라는 것이다. 강한 팀은 AI로 더 강해질 수 있다. 약한 팀은 기존 문제가 더 빨리 드러난다.

테스트가 약한 팀은 더 많은 미검증 코드를 얻는다. 리뷰 기준이 약한 팀은 더 많은 그럴듯한 변경을 얻는다. 문서가 약한 팀은 더 많은 맥락 없는 자동화를 얻는다. 배포 체계가 약한 팀은 더 빠른 불안정을 얻는다.

AI는 병목을 없애기보다 병목을 이동시킨다.

코딩 병목이 줄면 리뷰 병목이 보인다. 문서 작성 병목이 줄면 판단 기준의 부재가 보인다. 실행 속도가 빨라지면 승인 구조의 허술함이 드러난다.

해법은 더 많은 자동화가 아니라 더 좋은 작업 설계다

나는 AI 코딩 도구를 덜 쓰자는 말을 하려는 게 아니다. 오히려 반대다. 쓸 거면 제대로 써야 한다.

제대로 쓴다는 건 더 많은 일을 AI에게 던진다는 뜻이 아니다. 사람의 인지 부하가 어디로 이동하는지 보고, 그에 맞게 작업을 다시 설계한다는 뜻이다.

Anthropic은 agentic system을 만들 때 가장 단순한 해법부터 시작하고, 필요한 경우에만 복잡성을 높이라고 권한다. agentic workflow 안에는 중간 점검 gate를 둘 수 있다고 설명한다. OpenAI Agents SDK도 guardrails, handoffs, tracing, human-in-the-loop 같은 요소를 핵심 구성으로 둔다.

이 말들을 개발 현장 언어로 바꾸면 이렇다.

AI가 만든 코드에는 통과해야 할 체크리스트가 있어야 한다.
리뷰어는 코드만 보는 게 아니라 AI가 놓치기 쉬운 맥락을 봐야 한다.
반복 작업을 전부 없애지 말고, 사람에게 필요한 완충 구간을 남겨야 한다.
AI가 생성한 변경은 테스트, 로그, 근거, 재현 절차와 함께 와야 한다.
위험한 변경은 자동 실행하지 말고 사람에게 넘기는 조건이 있어야 한다.
생산성 평가는 작성 속도뿐 아니라 리뷰 부하, 재작업, 장애, 피로를 같이 봐야 한다.

이건 에이전틱 AI 도입에서도 똑같다. AI가 더 많은 실행을 할수록 사람의 일은 줄어드는 게 아니라 바뀐다. 사람은 더 많은 산출물을 보고, 고르고, 버리고, 승인해야 한다. 그래서 Human-in-the-loop는 장식이 아니라 작업 설계의 핵심이다.

AI 시대의 좋은 일은 쉬운 일을 일부 남긴다

우리는 오랫동안 일을 자동화할 때 지루한 일을 없애는 방향으로 생각했다. 그 자체는 맞다. 사람이 기계처럼 반복하는 건 좋은 일이 아니다.

다만 이제는 한 단계 더 섬세하게 봐야 한다.

어떤 쉬운 일은 정말 없애도 된다. 어떤 쉬운 일은 훈련이다. 어떤 쉬운 일은 맥락을 익히는 통로다. 어떤 쉬운 일은 어려운 판단 사이의 완충 구간이다.

AI가 쉬운 일을 모두 가져가면 사람은 더 창의적인 일을 하게 될 수도 있다. 하지만 반대로, 하루 종일 틀리면 안 되는 판단만 하는 사람이 될 수도 있다. 둘의 차이는 도구가 아니라 작업 설계에서 갈린다.

AI 시대의 좋은 조직은 반복 작업을 무조건 없애는 조직이 아니다.

AI에게 맡길 반복, 사람이 직접 해야 할 이해, 반드시 사람이 승인해야 할 판단, 그리고 사람이 숨을 돌릴 수 있는 리듬을 구분하는 조직이다.

개발자의 미래는 코드를 더 빨리 쓰는 사람이 아닐 수 있다. AI가 쏟아내는 가능성들 사이에서 무엇을 받아들이고, 무엇을 버리고, 어디서 멈출지 판단하는 사람에 가까워질 것이다.

그러니 AI 도입의 질문도 조금 바뀌어야 한다.

“얼마나 많은 일을 자동화할 수 있는가”만 물으면 부족하다.

“사람에게 어떤 종류의 일이 남는가”를 같이 물어야 한다.

AI는 일을 줄인 게 아니라 쉬운 일을 먼저 가져갔다. 이제 남은 문제는 사람에게 어려운 일만 몰아넣지 않는 방식으로 일을 다시 설계하는 것이다.