AI 쓰는데 왜 일이 줄지 않고 늘까 — 생산성 역설의 구조와 반도체 설계 현장

핵심 결론 AI가 개인의 작업 속도를 높이는 것과 조직의 전체 일이 줄어드는 것은 전혀 다른 문제다. 작업 단가가 내려가면 조직은 절약한 시간을 쉬는 데 쓰지 않고, 더 많은 프로젝트와 더 높은 완성도 요구로 채운다. 여기에 경영진의 기대치 인플레이션이 겹친다. AI 도입을 전제로 일정과 인력 계획이 먼저 짜이고, 현장의 검증과 리뷰 부담은 그 계획에 잡히지 않는다. 병목은 사라지지 않고 코드 작성에서 검토와 결정으로 이동한다. 회사별 AI 정책과 컴퓨트 접근성 격차는 이제 개인 역량 격차로 직결된다. 같은 실력이라도 쓸 수 있는 도구와 토큰 한도와 보안 정책이 다르면 산출물의 속도와 범위가 달라진다.

체감이 아니라 구조의 문제다

AI 도구를 쓰기 시작한 엔지니어라면 누구나 비슷한 경험을 한다. 코드 초안은 빨리 나오고, 문서 정리도 빨라지고, 모르는 라이브러리를 찾는 시간도 줄었다. 그런데 퇴근 시간은 그대로거나 오히려 늦어졌다. 프로젝트는 전보다 많아졌고, 리뷰 요청은 쌓이고, 일정은 더 촉박해졌다.

이 현상을 개인의 적응 문제로 보면 답이 안 나온다. 열심히 안 해서도, 프롬프트를 못 써서도 아니다. 구조가 그렇게 작동한다. 개인 생산성이 오르면 조직은 그 여유를 세 가지 방식으로 흡수한다. 더 많은 일을 같은 인원에게 배정하거나, 같은 일에 더 높은 완성도를 요구하거나, 예전에는 비용 때문에 하지 않던 일을 새로 시작하는 것이다. 어느 쪽이든 개인이 느끼는 일의 총량은 줄지 않는다.

경제학에는 오래된 이름이 있다. Jevons paradox다. 자원의 사용 효율이 좋아지면 단위 비용이 내려가고, 비용이 내려가면 수요가 늘어, 전체 소비는 오히려 증가한다는 관찰이다. AI 시대의 엔지니어링 workload가 정확히 이 패턴을 따른다. 코드 한 줄, 문서 한 장, 분석 한 건의 단가가 내려가자 조직이 소비하는 코드와 문서와 분석의 총량이 그 이상으로 늘었다.

측정 연구가 보여 주는 어긋난 숫자들

체감만으로 논하면 각자 경험담에서 끝나므로, 공개된 측정 결과를 보자. 소프트웨어 개발 영역의 연구지만 구조는 하드웨어 설계에도 그대로 적용된다.

METR의 2025년 무작위 대조 실험은 이 역설을 가장 선명하게 보여 준다. 본인이 수년간 기여해 온 오픈소스 저장소에서 실제 과제 246개를 수행한 숙련 개발자 16명을 대상으로, AI 도구 사용이 허용된 과제와 아닌 과제를 무작위로 나눠 측정했다. 개발자들은 사전에 AI가 약 24% 빠르게 해 줄 것으로 예상했지만, 실제 측정 결과는 AI를 쓴 과제가 19% 더 오래 걸렸다. 더 흥미로운 것은 사후 인식이다. 직접 경험한 뒤에도 개발자들은 AI가 자신을 약 20% 빠르게 해 줬다고 믿었다. 체감과 실측 사이에 약 39%포인트의 간극이 있었던 것이다.

이 연구 하나만으로 'AI는 느리다'고 결론 내리면 안 된다. 반대로 잘 정의된 신규 과제에서는 큰 폭의 속도 향상을 보고한 연구도 많다. 핵심은 간극 자체다. AI가 주는 체감 속도와 실제 처리량은 쉽게 어긋나고, 조직의 계획은 대개 체감 쪽 숫자를 기준으로 세워진다.

조직 단위 데이터는 병목 이동을 보여 준다. Faros AI가 1만 명 규모 개발자 원격측정 데이터를 분석한 결과, AI 사용량이 높은 팀은 과제를 21% 더 많이 닫았고 pull request 제출도 크게 늘었지만, 코드 리뷰 시간은 91% 늘었고 평균 pull request 크기는 154% 커졌으며 버그 수도 9% 증가했다. 만드는 속도는 올랐지만 검토하는 속도가 따라가지 못해 전체 흐름은 비례해서 빨라지지 않은 것이다.

반도체 설계로 옮겨 보면 대응 관계가 분명하다. RTL 생성은 빨라지지만 verification cycle, 리뷰, 타이밍 디버깅, ECO 판단이 병목이 된다. 만드는 양이 늘수록 검증해야 할 양은 그 이상으로 는다. 검증이 설계보다 항상 늦게 늘어나는 조직에서는 AI 도입이 곧바로 검증 조직의 과부하로 나타난다.

메커니즘 1 — 절약된 시간은 여유가 아니라 신규 수요가 된다

조직이 AI로 절약한 시간을 처리하는 기본값은 '같은 일을 더 적은 인원으로'가 아니다. 실제로는 '같은 인원으로 더 많은 프로젝트'가 기본값이다. 칩 프로젝트로 치면 동시 진행 테이프아웃 수가 늘고, 파생 제품과 리스핀 대응이 늘고, 예전에는 인력 부족으로 거절하던 고객 맞춤형 요청을 받기 시작한다.

여기에 완성도 인플레이션이 붙는다. 예전에는 시간 부족으로 타협하던 분석과 문서와 검토가 'AI가 있으니' 당연한 기본값이 된다. 경쟁사 분석은 더 깊게, 문서는 더 자세히, 시뮬레이션 코너는 더 많이. 하나하나는 합리적이지만 합치면 workload는 도입 전보다 커진다.

개인이 이 구조를 바꿀 수는 없다. 다만 읽을 수는 있다. AI로 생긴 여유를 상사가 보기 전에 본인이 먼저 신규 과제로 채워 버리면 평가는 산출량이 아니라 바쁨으로 굳어진다. 반대로 절약된 시간을 어떤 판단 업무에 썼는지를 기록하면, AI 시대의 기여를 설명하는 언어가 달라진다.

메커니즘 2 — 경영진의 기대치 인플레이션

경영진이 AI를 보는 숫자는 현장의 숫자와 다르다. 경영진은 벤더 발표와 언론의 성공 사례와 투자자 기대를 접한다. 시장이 소프트웨어 엔지니어링 생산성에 가격으로 반영한 기대 수준을 추정한 연구에서는 32.6% 수준의 영구적 생산성 향상이 기대에 반영되어 있다는 분석도 나왔다. 숫자의 정확도와 무관하게, 계획 부서가 전제하는 향상 폭은 현장의 보수적 실측보다 크기 쉽다.

문제는 이 기대가 일정표에 먼저 반영된다는 점이다. 프로젝트 기간이 AI 전제로 단축되고, 인력 충원이 그 전제로 보류되고, 동시 프로젝트 수가 그 전제로 늘어난다. 현장에서 AI가 실제로 절약해 주는 폭이 전제보다 작으면, 그 차이는 고스란히 개인의 추가 근무와 일정 압박으로 메워진다. 기대치 인플레이션의 비용을 지불하는 주체가 정해져 있는 셈이다.

더 교묘한 효과도 있다. AI를 쓴다는 사실 자체가 보고와 커뮤니케이션 양을 늘린다. 도입 효과를 증명하라는 요구, 활용 사례를 공유하라는 요구, 사용량 지표 관리까지. 도구를 쓰는 일 외에 도구를 썼음을 보이는 일이 추가되는데, 이 일은 어떤 생산성 지표에도 잡히지 않는다.

합리적인 대응은 기대를 낮추라고 주장하는 것이 아니다. 본인의 업무에서 AI가 실제로 절약한 것과 오히려 늘어난 검토 비용을 숫자로 들고 있는 것이다. 일정 산정 논의에서 'AI가 있으니 빠르다'는 문장에 대응할 수 있는 유일한 언어는 본인 업무의 실측이다.

메커니즘 3 — 회사별 정책과 컴퓨트 격차가 역량 격차가 된다

AI 생산성의 절반은 개인 실력이 아니라 접근성에서 갈리기 시작했다. 어느 회사는 최신 모델과 에이전트 도구를 전 직원에게 열고 토큰 한도도 넉넉한 반면, 어느 회사는 보안 정책상 외부 AI 사용이 원칙적으로 금지되고 사내 승인 모델만 제한적으로 허용된다. 반도체 업계는 특히 격차가 크다. 설계 데이터와 공정 정보가 핵심 기밀이라 외부 클라우드 AI에 코드를 올리는 것이 금지된 조직이 많고, 허용 범위도 회사와 프로젝트마다 다르다.

컴퓨트 격차는 더 직접적이다. AI 에이전트의 성능은 사실상 투입할 수 있는 토큰과 반복 횟수에 비례하는 구간이 있다. 같은 과제도 한도가 넉넉한 환경에서는 에이전트가 수십 번의 시도와 검증을 반복하지만, 한도가 빠듯한 환경에서는 한 번의 생성으로 끝나고 나머지는 사람이 메운다. 몇 달이 쌓이면 같은 직급, 같은 연차 엔지니어 사이에 경험의 총량 자체가 벌어진다.

이 격차는 이직 시장에서도 작동하기 시작한다. AI 도구를 깊게 써 본 경험, 에이전트 기반 워크플로를 설계해 본 경험이 면접에서 구체적인 차별점이 된다. 반대로 접근성이 막힌 회사에 오래 있으면 본인 책임이 아닌 이유로 시장 경쟁력이 깎인다. 대응은 두 가지다. 사내에서 허용 범위를 넓히는 제안에 참여하는 것과, 공개 데이터와 오픈소스 프로젝트 범위에서라도 개인 워크플로를 유지하는 것이다. 회사 정책 위반은 어떤 경우에도 답이 아니다. 정책 안에서의 최대 활용과 정책 밖 개인 학습을 구분하는 선이 중요하다.

반도체 설계 현장에서 역설이 더 크게 느껴지는 이유

첫째, 반도체는 검증 비용이 압도적으로 큰 산업이다. 소프트웨어는 배포 후 수정이 가능하지만 칩은 tape-out 이후 수정 비용이 차원이 다르다. 그래서 생성량이 늘면 검증 부담이 비례 이상으로 는다. AI가 RTL 초안을 열 배 빨리 만들어도 signoff 기준은 그대로이고, 오히려 검토 대상이 늘어 DV와 STA 조직의 일정이 전체 일정을 다시 지배한다.

둘째, 일정이 물리적으로 고정되어 있다. 파운드리 슬롯과 패키지 일정과 고객 샘플 약속은 AI 도입을 이유로 움직이지 않는다. 절약된 시간은 일정 단축이 아니라 그 고정 일정 안에 더 많은 기능을 넣는 방향으로 소비된다. 스펙이 일정 중간에 불어나는 현상이 AI 이후 더 잦아진 배경이다.

셋째, 책임 소재가 분명한 산업이다. AI가 만든 코드에서 버그가 나도 책임은 엔지니어와 조직이 진다. 그래서 검토를 생략할 수 없고, 검토할 양은 생성량에 비례해 는다. 자동화가 늘수록 최종 판단자의 부담이 커지는 구조가 반도체에서는 특히 강하게 작동한다.

개인이 할 수 있는 현실적인 대응

구조를 이해했다고 일이 줄어들지는 않는다. 그래도 같은 workload 안에서도 소진되는 사람과 평가받는 사람은 갈린다.

첫째, AI로 절약한 시간을 보고 가능한 산출물로 바꾼다. 리뷰 코멘트의 질, 조기에 잡은 버그, 일정 리스크를 미리 알린 기록처럼 판단의 결과물을 남기는 것이 단순 생성량보다 평가에서 강하다.

둘째, 본인 업무의 실측을 가진다. AI 사용 전후로 걸린 시간, 검토에 쓴 시간, 되돌린 비율을 가볍게라도 기록하면 일정 논의에서 기대치 인플레이션에 대응할 근거가 생긴다.

셋째, 병목 쪽 역량을 키운다. 조직의 병목이 검토와 결정으로 이동했다면 그 자리의 역량 가치는 오른다. 코드 리뷰, 검증 계획, 타이밍 디버깅처럼 병목에 해당하는 기술은 AI 시대에 오히려 단가가 오르는 영역이다.

넷째, 접근성 격차를 방치하지 않는다. 사내 허용 도구의 한계를 정확히 알고, 허용 범위 안에서 워크플로를 최적화하고, 개인 학습으로 감각을 유지한다. 격차는 아는 사람부터 좁혀진다.

FAQ

Q1. AI를 쓰면 실제로 빨라지긴 하나요? 작업 종류에 따라 갈린다. 잘 정의된 신규 작성과 초안 작업에서는 속도 향상이 반복해서 측정된다. 반면 익숙한 대형 시스템의 수정처럼 맥락과 검토 비용이 큰 작업에서는 METR 실험처럼 오히려 느려지는 결과도 측정됐다. 'AI는 빠르다, 느리다'의 이분법이 아니라 어떤 작업에서 병목이 어디로 이동하는지를 보는 것이 정확하다.

Q2. 일이 늘어나는 것이 결국 회사에는 좋은 것 아닌가요? 조직 산출량 기준으로는 그럴 수 있다. 문제는 산출량 증가가 개인의 지속 가능한 속도를 전제로 하지 않을 때다. 기대치 인플레이션으로 짜인 일정이 상시화되면 소진과 품질 저하가 뒤따라오고, 반도체처럼 검증 비용이 큰 산업에서는 품질 저하의 대가가 특히 비싸다.

Q3. 상사가 AI 전제로 일정을 줄이면 어떻게 대응해야 하나요? 감으로 반박하면 진다. 본인 업무의 실측, 즉 생성 시간 절감분과 검토 시간 증가분을 함께 제시하는 것이 가장 효과적이다. AI가 빠른 구간과 느린 구간을 업무 단계별로 나눠 보여 주면 일정 논의가 감정이 아니라 산정 문제로 바뀐다.

Q4. AI 사용이 금지된 회사에 있으면 커리어가 뒤처지나요? 단기 격차는 생길 수 있지만 결정적이지는 않다. 공개 벤치마크와 오픈소스 범위에서 AI 출력의 특성과 한계를 익히는 학습은 정책과 무관하게 가능하다. 더 중요한 것은 정책 안에서 허용된 도구를 최대치로 활용하는 기록과, 판단 역량을 키우는 방향 자체다.

Q5. 이 역설은 시간이 지나면 해소되나요? 도구가 좋아지면 개인 단위 비효율은 줄어들 것이다. 그러나 수요가 단가 하락에 반응해 늘어나는 Jevons paradox 구조 자체는 도구 성능과 무관하게 작동한다. 해소보다는 형태가 바뀐다고 보는 편이 현실적이며, 그래서 병목 쪽 역량의 가치는 장기적으로 유지될 가능성이 높다.

행동 체크리스트

• ☐ 내 업무를 생성 구간과 검토 구간으로 나누고 각각의 시간을 가볍게라도 측정했다
• ☐ AI로 절약한 시간을 어떤 판단 업무에 썼는지 기록으로 남기고 있다
• ☐ 일정 논의에 쓸 수 있는 내 업무 실측 수치 한두 개를 확보했다
• ☐ 우리 회사의 AI 사용 정책과 허용 범위를 정확히 확인했다
• ☐ 정책 범위 안에서 내 워크플로를 최적화할 지점 한 가지를 개선했다
• ☐ 리뷰, 검증, 디버깅 같은 병목 역량 하나를 올해 학습 목표로 잡았다
• ☐ 신규 과제를 받기 전에 현재 workload 총량을 숫자로 설명할 수 있게 정리했다

함께 읽으면 좋은 글

• RTL, AI에 대체될까 — 숫자가 보여 주는 진짜 경계와 커리어 생존 전략

📩 VLSI Korea 뉴스레터 구독하기

매일 발행되는 반도체 심층 분석을 이메일로 가장 먼저 받아보세요. 구독은 무료입니다.

무료로 구독하기