- AI 활용으로 코드와 문서 작성은 빨라졌지만, 그것이 곧바로 팀의 진척으로 이어지진 않습니다. 개인의 작업 속도를 팀의 생산성으로 연결하기 위해 갖춰야 할 흡수 역량을 판단 가능성, 추적 가능성, 복구 가능성으로 확인합니다.
처음에는 제가 쓰던 AI 워크플로를 다듬어 팀과 나누면 충분하다고 생각했습니다. 규칙과 커맨드를 정리해 공유하면, 제가 체감한 속도 향상이 팀으로 확장될 것이라 기대했습니다.
그런데 실제 병목은 다른 곳에 있었습니다. AI 덕분에 코드와 문서는 빨리 나왔지만, 그 속도가 팀의 속도로 온전히 이어지지는 않았습니다.
이 차이가 왜 생기는지 알아보다 흡수 역량(Absorptive Capacity)이라는 개념을 알게 됐습니다. 조직 이론에서 말하는 외부 지식과 정보의 가치를 인식하고, 팀 내부의 역량으로 바꿔 활용하는 능력입니다.
AI가 만든 코드와 문서도 처음에는 외부 지식에 가깝습니다. 겉보기에는 팀 안에 있더라도 곧바로 팀의 역량이 되지는 않습니다.
병목은 작성에서 흡수로 이동했다
AI 이전에도 맥락이 부족한 PR이나 형식적인 리뷰는 있었습니다. 다만 그때는 산출물이 지금처럼 빠른 속도로 쌓이지 않았습니다. 코드를 쓰고 문서를 다듬는 데 시간이 걸렸고, 그 시간은 작성자가 자신의 선택을 한 번 더 정리할 틈이 되기도 했습니다.
AI는 첫 결과를 만드는 시간을 크게 줄였습니다. 이제는 낯선 영역에서도 설계안과 코드, 테스트까지 금방 내놓습니다.
하지만 겉으로 완성돼 보인다는 것과 팀이 받아들일 수 있는 수준이라는 것은 다릅니다. 팀의 기준으로 검증됐는지, 어디까지 확인했고 무엇이 아직 남았는지, 다음 사람이 이어받을 맥락이 남아 있는지를 함께 봐야 합니다.
이 방식을 갖춘 팀은 늘어난 개인의 생산성을 팀의 진척으로 바꿉니다. 반대로 그 방식이 약한 팀은 만드는 빨라진 속도가 반대로 병목으로 이어집니다.
팀 안에 들어왔다고 팀의 지식이 되지는 않는다
AI가 만든 산출물은 쉽게 팀의 워크플로에 들어옵니다. 코드는 저장소에 올라오고, 문서는 위키에 남고, 분석 결과는 회의 안건이 됩니다. 겉으로는 모두 팀의 자산처럼 보입니다.
하지만 만드는 동안 오간 판단은 따로 남기지 않으면 전해지지 않습니다. AI 세션과 대화 로그에만 남은 판단은 팀의 맥락이 되지 못합니다.
이렇게 형식은 갖췄지만 일을 진전시키지 못하고, 받는 사람에게 해석과 검증 부담을 넘기는 산출물을 워크슬롭(Workslop)이라 합니다. 문제는 단순히 검토 시간이 느는 데서 끝나지 않습니다. 그런 산출물을 받게 되면 검토 시간만 늘어나는 것이 아니라 팀 안의 신뢰까지 함께 깎입니다.
이건 작성자 개개인의 꼼꼼함에 맡길 문제가 아닙니다. 워크슬롭이 반복된다면, 팀이 산출물을 어떤 조건으로 받아들이고 있는지부터 봐야 합니다.
팀의 자산이 되기 위한 세 가지 조건
산출물이 팀의 자산이 되려면 세 가지 질문에 답할 수 있어야 합니다.
-
팀이 합의한 기준으로 판단할 수 있는가?
-
시간이 지나도 결정의 근거를 추적할 수 있는가?
-
잘못됐을 때 빠르게 인지하고 되돌리거나 바로잡을 수 있는가?
이 질문은 코드만이 아니라 문서나 기술 결정, 운영 정책 같은 팀이 이어받는 모든 산출물에 해당합니다.
판단 가능성
판단 가능성(Reviewability)은 산출물을 제3자가 이해하고 평가할 수 있을 만큼 근거가 충분한지를 의미합니다. 단순히 가독성의 문제가 아닙니다. 하나의 검토 단위로 정리돼 있어야 하고, 어떤 문제를 풀려 했는지와 어디까지 영향을 주는지 명확히 드러나야 합니다.
팀이 합의한 기준으로 볼 수 있어야 한다는 뜻이기도 합니다. 그럴듯해 보여도 팀이 합의한 아키텍처, 네이밍, 예외 처리, 테스트 방식을 벗어났다면 팀의 자산으로 받아들이기 어렵습니다. 특히 AI 산출물은 겉보기 완성도가 높아, 실제로는 판단하기 어려운데도 검증이 끝난 듯한 착시를 일으키기 쉽습니다.
추적 가능성
추적 가능성(Traceability)은 시간이 지난 뒤에도 결정의 근거와 연결 관계를 따라갈 수 있느냐의 문제입니다. AI를 쓰면 결과물은 금방 나오고, 대화 기록이나 요약도 함께 남길 수 있습니다. 하지만 기록이 있다고 해서 팀이 바로 이해할 수 있는 것은 아닙니다. 어떤 문제에서 시작해 어떤 판단을 거쳐 코드, 문서, 결과물로 이어졌는지가 팀이 읽을 수 있는 형태로 남아 있어야 합니다.
그래야 나중에 같은 판단을 반복하지 않고, 상황이 바뀌었을 때 기존 결정을 재검토할 수 있습니다.
복구 가능성
복구 가능성(Recoverability)은 문제가 생겼을 때 이를 빠르게 알아채고 바로잡을 수 있는 능력을 말합니다.
AI가 만든 결과물은 그럴듯해 보이기 때문에 검토 과정을 쉽게 통과하기 쉽지만, 추후 예기치 못한 리스크가 드러날 수 있습니다. 따라서 목표는 실수를 완전히 막는 게 아니라, 문제가 발생했을 때 팀이 감당할 수 있는 선에서 안전하게 수습할 수 있는 시스템을 만드는 것입니다.
팀의 경계에서 확인해야 할 기준
개인의 작업 방식은 달라도 괜찮습니다. 다만 결과물이 팀의 경계를 넘어올 때는 앞의 세 조건을 확인할 수 있어야 합니다.
가장 익숙한 예시인 PR로 살펴보겠습니다.
지난 글 - 60일 간의 AI 에이전틱 워크플로 - 에서 다룬 방식으로 작업한 PR의 일부분입니다.
PR 본문을 자세하게 쓰자 정도가 목적이 아닙니다. 문제의 원인이 무엇인지, 어디까지 검증했는지, 리뷰어가 무엇을 봐야 하는지, 문제가 생기면 어떻게 대응해야 하는지 처럼, 팀이 받아들이기 전에 필요한 내용을 빠뜨리지 않게 하는 최소한의 장치(harness)가 되어야 합니다.
하지만 이것을 매번 작성자의 성실함에만 맡기면 지속 가능하지 않습니다. 개인의 체크리스트가 아니라, 팀의 워크플로 안에 녹아 있어야 합니다. 누가 어떤 도구를 쓰든 팀의 경계를 넘을 때는 같은 기준의 정보가 남아야 합니다.
좋은 PR의 기준은 AI 이전과 달라지지 않았습니다. 다만 AI라는 증폭기가 생긴 지금은, 예전에는 지키면 좋은 습관이었다면, 이제는 지키지 않았을 때 치러야 할 대가가 훨씬 커졌습니다.
팀의 진척은 흡수에서 나온다
AI가 전에 없던 새 기준을 만든 것은 아닙니다. 다만 AI 산출물이 팀으로 들어오는 속도가 달라지면서 기존 엔지니어링 시스템의 장점과 약점이 더 빨리 드러나기 시작했습니다.
개인의 작업을 팀이 책임질 수 있는 상태로 받아들이는 과정이 탄탄한 팀은 AI로 늘어난 속도를 팀의 생산성으로 흡수할 수 있습니다. 반대로 그 과정이 부족한 팀은 무언가를 생성하는 속도만 빨라질 뿐, 팀은 좀처럼 앞으로 나아가지 못합니다.
팀마다 병목의 지점은 다를 수 있습니다. 하지만 개인의 작성 속도는 빨라졌는데 팀의 진척이 그대로라면, 그 속도를 팀이 소화할 수 있는 시스템을 갖췄는지 먼저 봐야 합니다.
지금까지 말한 팀은 사람만을 뜻하지 않습니다. 다음 작업을 이어받는 주체는 사람일 수도, AI일 수도 있습니다. AI 역시 팀에 남겨진 맥락을 바탕으로 돌아갑니다. 맥락이 비어 있으면 그 내용을 다시 추론하느라 비용을 쓰고, 빈자리를 그럴듯하게 메우려다 환각이나 잘못된 판단으로 이어질 수 있습니다.
조직이 바라봐야 할 것은 “AI를 얼마나 많이 썼는가”나 “산출물을 얼마나 많이 만들었는가”가 아닙니다.
AI가 만든 산출물을 팀이 책임질 수 있는 지식으로 흡수하고 있는가?
이 질문에 답하지 못하면 빨라진 속도는 팀이 갚아야 할 부담으로 남습니다.
참고 자료
- Cohen & Levinthal, ["Absorptive Capacity: A New Perspective on Learning and Innovation"] (Administrative Science Quarterly, 1990)
- Kate Niederhoffer et al., ["AI-Generated 'Workslop' Is Destroying Productivity"] (Harvard Business Review, 2025-09)
TaeZ