AI가 생긴 이후로 왜 더 바빠졌을까?

#1. 나는 완성된 코드에 대해 설명할 수 있는가

저는 점심시간이 되면 밥을 먹기 전에 꼭 하는 일이 있습니다. 바로 성능이 좋은 AI모델에 오래 걸릴 만한 업무를 지시하는 일입니다. 화장실에 가기 전에도, 회의실에 들어가기 전에도 각 모델과 에이전트들에게 프롬프트를 하나씩 남깁니다. 저는 잠깐 자리를 비우지만, AI는 그동안 계속 일하도록 하려는 의도에서 입니다. 시간 활용과 더불어, 비싼 구독료를 냈으니 AI모델까지 쉬게 두기는 어쩐지 아깝기 때문이기도 합니다.

나름 효율적인 업무습관처럼 보이지만, 잘 생각해 보면 이것 때문에 더 오래 앉아있게 되고, 밥을 먹고 나서도 늘 AI의 생성 결과를 검토해야 했습니다. 결국, 저를 도와줄 도구가 늘어날수록, 그 도구들에게 일을 맡기는 시간과 검토하는 시간도 늘어났습니다.

제 시간을 아끼려고 쓰기 시작했는데,
어느새 AI의 빈 시간까지 챙기고 있는 셈입니다.

이런 모습이 저만의 습관은 아니었습니다.

2026년, HBR(하버드 비즈니스 리뷰)의 「AI Doesn’t Reduce Work—It Intensifies It(AI는 일을 줄이지 않는다. 업무 강도를 높인다)」연구에서도 같은 모습을 발견하였습니다. 연구자가 관찰한 직원들은 회의나 식사 전에 AI에 프롬프트를 보내고, AI가 작업하는 동안 다른 일을 했습니다. 여러 에이전트를 동시에 실행하기도 했습니다. 저와 비슷한 방식으로 하루를 채우는 사람들이 많았던 겁니다.

공통된 문제는 그다음입니다. 자리를 비운 사이 결과물은 늘어날 수 있지만, 돌아와 읽고 판단할 사람은 여전히 저를 포함한 “지시자”입니다. 더 바빠진 일상에서 먼저 확인해 볼 것은, 늘어난 결과물만큼 ‘해당 업무에 대한 검토와 이해가 함께 이뤄지고 있는지?’에 대한 점입니다.

딸깍

개발자들에게도 익숙한 장면일 겁니다. 구현할 서비스에 대한 설명을 텍스트로 지시하면 일목요연하게 구성된 아키텍처와 모듈, 코드가 생성됩니다. “Accept”, “Yes”.. 몇 번의 딸깍 끝에 프로그램이 돌아갑니다. 배포 테스트까지 통과하면 마음이 놓입니다. 오늘도 일을 하나 끝냈습니다. 그런데, 동료나 상사, 또는 고객이 “이 코드는 왜 이렇게 구현하셨어요?”라고 물으면 잠깐 멈칫하게 됩니다. 작동하는 것은 확인했지만, 그 이유까지 설명할 준비는 미쳐 하지 못했기 때문입니다.

“작동하는 코드를 얻었다”와
“그 코드를 이해했다”의 의미는 다르다

이 간극을 살펴본 실험이 있습니다. 「How AI Impacts Skill Formation (AI가 역량 형성에 미치는 영향)」에서는 개발자들이 새로운 라이브러리를 배우며 과제를 수행한 뒤, AI 없이 얼마나 이해했는지 평가했습니다. 아래의 그림 왼쪽을 보면 AI의 도움을 받은 집단의 평균 수행 시간(23분)은 AI 없이 수행한 집단(24.7분)보다 조금 짧았습니다. 다만 이 차이는 통계적으로 유의하지 않았습니다(p=0.391>0.05). 이 실험에서는 시간을 절약했다고 결론 내릴 근거는 충분하지 않다는 말과 같습니다.

출처: Shen·Tamkin(2026), Figure 1을 바탕으로 재구성

반면, AI의 도움을 받은 집단의 학습(50점) 성과는 AI의 도움을 받지 않는 집단(67점) 보다 낮았습니다. 그리고 이 점수 차이는 통계적으로 유의했습니다(p=0.010 <0.05).

AI를 어떻게 활용하느냐에 따라 이해도가 다르다.

또 하나 눈길을 끄는 것은 오른쪽 그림입니다. ‘AI를 활용하면 무조건 코드 이해도 점수가 낮다’는 말은 맞지 않습니다. ‘AI에게 전면 위임(39%)’과 ‘생성 후 이해 질문(86%)’이라는 이 둘의 차이는 명확했습니다. 한쪽은 코드 완성본 결과를 받는 데서 멈췄고, 다른 쪽은 받은 코드가 왜 그렇게 작동하는지 질문을 이어갔습니다. 코드를 생성받은 뒤에도 학습으로 이해할 기회는 얼마든지 있다는 말입니다.

또한 ‘반복적 디버깅 위임’처럼 오류가 날 때마다 수정을 맡기는 것과 “왜 이 부분에서 오류가 났나요?”를 묻는 것은 다릅니다. 즉, AI와 대화한 횟수보다, 그 대화 속에서 자신이 이해하고 판단하는 과정에 얼마나 참여했는지가 중요하다는 것입니다.

예를 들어, 외부 API를 호출하는 코드를 받았다면, 정상 응답을 확인 Response [200] 이 끝이 아닙니다. “샘플 요청은 처리됐는데 응답이 유실되면 어떻게 되는가?”, “재시도하면 같은 작업이 두 번 실행되지 않나?”, “반복된 값이 두 번 들어오면 어떻게 처리되는가?”라고 핵심 질문들을 하는 것입니다. 새로운 기술을 배울 때만큼은 이해를 쌓는 일을 게을리해서는 안됩니다.

코드는 빨리 나오는데, 왜 퇴근은 늦어질까, 그리고 우리는 지금 무엇을 해야 하는가에 대해 인사이트를 얻고 싶으시다면 아래 프로그래머스에서 전문을 읽으실 수 있습니다.

https://community.programmers.co.kr/post/14191