AI가 만든 일거리는 안 보인다
이 글에서 '통합 부채'는 AI 도입이 실패했다는 뜻이 아니다. 도구가 산출을 늘린 만큼 그것을 검증하고 이어 붙이고 잘못을 수습하는 일이 사람에게 새로 생기는 몫을 뜻한다. 도입 계획에는 사라질 일만 적히고, 이 새로 생길 일은 적히지 않는다.
Section Ⅰ · The Paradox개인은 빨라지고
각자는 빨라졌는데
전체는 느려졌다
AI를 쓰는 사람은 대개 만족한다. 더 빨리 만들고, 막힘이 줄고, 일이 수월해졌다고 느낀다. 그런데 조직 단위로 재면 다른 그림이 나온다.
구글이 매년 내는 DORA의 2024년 분석이 그 대비를 보여 준다. AI 채택이 25% 늘어날 때, 소프트웨어 전달의 처리량은 1.5%, 안정성은 7.2% 내려가는 것으로 추정됐다. 같은 조사에서 개인의 생산성과 몰입, 직무 만족은 분명히 올랐는데도 그랬다. 그리고 이 방향은 2년 연속 같았다.
왜 이런 일이 생길까. 산출이 늘어난 만큼 그 산출을 다루는 일도 늘기 때문이다. 검토할 코드가 많아지고, 확인할 초안이 쌓이고, 어긋난 것을 되돌리는 시간이 붙는다. 같은 조사에서 개발자가 꼽은 첫째 어려움도 생성물의 품질을 믿을 수 있느냐였다. 믿기 어려우면 확인해야 하고, 확인은 사람의 시간이다.
그러니 물음은 'AI가 생산성을 올리는가'가 아니다. 올라간 생산성의 청구서가 어디로 가는가이다.
Section Ⅱ · Three Bills청구서 세 장
사라진 일은 세어도
생겨난 일은 안 센다
도입 계획서에는 대개 없어질 일이 적힌다. 그런데 새로 생기는 일은 계획서 바깥에서 조용히 늘어난다. 크게 세 장이다.
“AI 채택이 늘수록 개인의 생산성과 만족은 올랐지만, 소프트웨어 전달의 처리량과 안정성은 오히려 내려갔다.” (요지 · DORA, Accelerate State of DevOps, 2024)
BCG의 2025년 조사도 같은 곳을 가리킨다. 임원 1,250명 가운데 60%가 AI에서 가치를 거의 보지 못했다고 답했고, 규모화에 성공한 곳은 5%였다. 그리고 문제의 대부분은 알고리즘에서 오지 않았다. 그래서 나온 배분이 10-20-70이다. 알고리즘 10, 기술과 데이터 20, 그리고 사람과 프로세스에 70. 보이지 않는 청구서를 처음부터 예산에 넣으라는 말이다.
Section Ⅲ · Budget It미리 예산에 넣기
청구서를 없앨 수 없다면
먼저 세어 둔다
통합 부채는 나쁜 도입의 증상이 아니라 모든 도입에 붙는 기본 비용이다. 없앨 수 없다면 미리 세어 두는 편이 낫다. 그 설계를 세우려면 다음을 통과해야 한다.
이 편은 Vol. 15와 Vol. 34가 말한 재설계의 이유를 뒤에서 받쳐 준다. 왜 얹기만 해서는 값이 안 나는가. 얹으면 산출은 늘지만 그 산출을 다루는 일도 함께 늘고, 흐름을 다시 짜지 않는 한 그 일은 전부 사람에게 남기 때문이다.
보이지 않는 청구서를 세지 않으면, 조직은 두 번 잃는다. 처음에는 기대만큼 값이 안 나서 잃고, 다음에는 그 이유를 사람들의 저항이나 역량 탓으로 돌리며 잃는다. 청구서는 처음부터 거기 있었고, 다만 아무도 세지 않았을 뿐이다.
AI가 만든 산출은 눈에 보인다. AI가 만든 일거리는 보이지 않는다. 리더의 일은 보이지 않는 쪽을 먼저 세어, 장부 위에 올려 두는 것이다.