AI가 초안을 만들어주는 시간은 짧아졌다. 그런데 왜 문서를 검토하는 시간은 줄지 않는 걸까?
기획안, 회의록, 리서치 자료와 코드까지 이제는 AI에게 요청하면 금방 결과가 나온다. 예전에는 빈 문서에서 첫 문장을 시작하는 데 시간이 걸렸다면, 지금은 몇 분 만에 제법 그럴듯한 초안을 받을 수 있다.
문제는 그다음이다.
내용이 맞는지 확인하고, 필요 없는 문장을 덜어내고, 우리 상황과 맞지 않는 가정을 찾아내고, 결국 어떤 결정을 내려야 하는지 다시 정리해야 한다.
초안은 빨리 나왔는데 읽어야 할 것은 더 많아졌다.
생산의 병목에서 이해의 병목으로
GeekNews에 소개된 「이해가 새로운 병목이다」는 에이전트가 코드를 작성하는 속도보다 사람이 시스템을 이해하는 속도가 느려지고 있다고 설명한다.
코드는 이전보다 빠르게 만들어지지만, 그 코드가 왜 필요한지, 기존 구조와 어떻게 연결되는지, 무엇이 달라졌는지를 사람이 따라가지 못할 수 있다는 것이다.
문서도 크게 다르지 않다고 생각한다.
AI가 조사한 내용을 그대로 팀 채널에 붙여 넣으면 작성자의 시간은 줄어든다. 하지만 그 자료를 받는 사람은 출처가 맞는지, 어떤 내용이 사실이고 어떤 내용이 AI의 추론인지 다시 확인해야 한다. 작성자가 줄인 시간이 검토자에게 넘어간 셈이다.
GeekNews의 다른 글에서는 이를 LLM 결과물을 계속 읽으며 생기는 리뷰 피로로 다룬다. 비슷한 오류와 단정적인 표현을 반복해서 확인하다 보면 AI가 생산성을 높이는 동시에 사람의 집중력을 새로운 병목으로 만들 수 있다는 내용이다.
결국 업무 소음은 글이 길어서만 생기는 것이 아니다. 왜 이 자료를 만들었고, 무엇을 확인했으며, 상대방이 어떤 결정을 내려야 하는지가 보이지 않을 때 생긴다.
AI가 검토까지 해주면 해결될까
그럼 AI가 만든 결과를 다른 AI에게 검토하게 하면 되지 않을까?
일부 오류는 그렇게 줄일 수 있다. 오탈자, 형식, 정해진 규칙 위반처럼 확인 기준이 명확한 문제는 AI나 자동화된 도구가 먼저 찾아줄 수 있다.
다만 모든 문제를 해결하지는 못한다.
GeekNews에 소개된 한 관찰 연구에서는 207개 GitHub 프로젝트의 약 102만 개 PR을 분석했다. AI 리뷰어를 도입한 프로젝트에서 의사결정은 빨라졌지만, 리뷰 품질 지표까지 함께 좋아졌다고 보기는 어려웠다. 모든 PR에 같은 AI 리뷰어를 붙인 경우에는 속도 개선도 나타나지 않았다. 관련 내용
AI가 코드 안에 보이는 문제는 찾을 수 있어도, 왜 이 기능을 만들었는지, 사용자에게 어떤 영향을 주는지, 다른 팀과 어떤 약속이 있었는지까지 모두 알고 있는 것은 아니다.
코드 밖의 맥락은 여전히 사람에게 남는다.
팀의 시간을 줄이는 AI 활용
PM의 관점에서 보면 AI 활용의 기준을 개인의 작성 시간만으로 판단해서는 안 된다는 생각이 든다.
내가 한 시간 걸리던 문서를 10분 만에 만들었더라도, 팀원 다섯 명이 그 문서를 이해하기 위해 각각 한 시간씩 사용했다면 정말 생산성이 높아진 걸까?
그래서 AI가 만든 결과를 공유할 때는 결과물의 양보다 다음 내용이 보여야 한다.
왜 이 자료를 만들었는지, 어떤 출처를 확인했는지, 아직 확인하지 못한 가정은 무엇인지, 그리고 상대방에게 필요한 결정이 무엇인지.
AI가 작성한 긴 보고서 전체를 공유하기보다 내가 확인한 결론과 판단 근거를 먼저 전달하는 편이 나을 수도 있다. 원문은 필요할 때 확인할 수 있도록 남겨두면 된다.
그리고 내가 생각하기에 가장 중요한 것은 AI가 만든 결과의 책임자를 분명하게 두는 것이다.
“AI가 그렇게 답했다”는 말은 설명은 될 수 있어도 책임이 될 수는 없다. 누군가는 그 결과를 읽었고, 우리 업무에 사용해도 된다고 판단해야 한다.
AI는 업무를 줄여줄 수 있다. 하지만 아무 기준 없이 사용하면 작성자의 일을 검토자의 일로 옮길 뿐이다.
생산량이 많아졌다는 이유만으로 일이 잘되고 있다고 생각하면, 팀은 더 빠르게 움직이는 것이 아니라 더 많은 소음 속에서 움직이게 된다.
팀이 읽지 않아도 될 결과물을 줄이는 사람. 그런 사람이 오히려 더 중요해질 것 같다.