AI 전환 12개월, 우리 팀 생산성 지표는 실제로 어떻게 변했나

AI를 일상 업무에 들인 지 1년, 우리가 스스로에게 던진 질문은 "AI가 도움이 되는가"가 아니었습니다. 훨씬 어려운 질문은 따로 있었습니다. 그게 진짜인지, 아니면 그냥 기분인지를 어떻게 알 수 있느냐는 것입니다. 이 글은 한 소프트웨어 개발팀이 12개월 동안 변화를 어떻게 실제로 측정했는지, 어떤 지표를 믿었고 어떤 지표를 버려야 했는지에 대한 기록입니다. 화려한 숫자로 채운 성과 보고서가 아닙니다. 우리는 사내 수치를 절대적 사실처럼 단정하지 않으려 일부러 조심했습니다. 대부분의 수치는 프로젝트 상황에 크게 좌우되기 때문입니다. 그 대신 무엇을 어떻게 측정했고, 그 방향이 어디까지 믿을 만한지를 솔직하게 적습니다.

12개월 차, 우리가 실제로 본 지표는 무엇인가

1년이 지난 시점에 우리가 집중한 지표는 네 가지입니다. 요청에서 인도까지 걸린 시간, 인도 후 다시 손대야 했던 재작업 비율, 첫 제출에서 검수를 통과한 비율, 그리고 구성원 사이의 품질 편차입니다. 이것들은 표면적 활동량이 아니라 실제 가치를 비추는 지표입니다.

먼저 말해둘 것이 있습니다. 지표 자체보다 지표를 고르는 방식이 더 많이 바뀌었습니다. 초기 몇 달은 세기 쉬운 것을 셌습니다. 그런데 오래 측정할수록 분명해졌습니다. 세기 쉽다고 해서 믿을 만한 지표는 아니라는 것입니다. 어떤 팀이든 가치를 별로 만들지 않으면서도 엄청난 활동량을 만들어낼 수 있습니다. AI는 이걸 더 위험하게 만듭니다. 대량 생산을 너무나 쉽게 해주기 때문입니다.

그래서 우리는 단순한 원칙으로 돌아갔습니다. 고객과 팀이 실제로 체감하는 것만 측정합니다. 고객은 기다리는 시간을 체감합니다. 인도가 끝났는데도 자꾸 고쳐야 하는 상황을 체감합니다. 안정성, 즉 이번 품질이 지난번과 같은지를 체감합니다. 우리의 네 가지 지표는 전부 그 체감을 중심으로 돕니다. 팀이 얼마나 바빴는지를 중심으로 돌지 않습니다.

우리는 선행 지표와 결과 지표도 분명히 구분했습니다. 결과 지표는 프로젝트가 어디까지 갔는지 알려주지만, 손쓰기엔 너무 늦게 도착합니다. 선행 지표는 이른 신호입니다. 예를 들어 고객에게 나가기 전 사내 검수 단계에서 몇 건의 문제가 잡혔는가 같은 것입니다. 지난 1년이 우리에게 가르친 것은, 선행 지표에 투자하는 편이 훨씬 값지다는 사실입니다. 아직 늦지 않았을 때 바로잡을 기회를 주기 때문입니다.

왜 "코드 줄 수"나 "투입 시간" 같은 단순 지표를 버렸나

우리는 코드 줄 수, 커밋 개수, 총 근무 시간 같은 지표를 버렸습니다. 이것들은 들인 노력의 양을 잴 뿐, 만들어낸 가치를 재지 못하기 때문입니다. AI 시대에는 한 사람이 몇 분 만에 수천 줄을 뽑아낼 수 있습니다. 그래서 이 숫자들은 더 이상 역량이나 결과를 말해주지 못하고, 오히려 잘못된 결정으로 이끕니다.

예전에는 많은 곳에서 "근무 시간"이 곧 "기여"와 거의 같은 말이었습니다. 오래 앉아 많이 쓰는 개발자는 성실한 사람으로 여겨졌습니다. 그런데 AI가 이 연결을 끊어버렸습니다. 도구가 몇 분 만에 기능의 초안을 써낼 수 있게 되자, 사람의 가치는 타이핑이 아니라 요건을 제대로 정의하고, 품질을 제대로 판단하고, 무엇을 남길지 결정하는 데로 옮겨갔습니다.

우리가 계속 "코드 줄 수"에 보상을 줬다면, 정확히 잘못된 행동을 부추겼을 것입니다. 누군가는 AI에게 코드를 잔뜩 뽑게 해서 숫자를 끌어올리면서도, 무겁고 유지보수하기 어렵고 잠재적 결함투성이인 결과물을 만들 수 있습니다. 숫자는 예쁘고 결과는 나쁜 셈입니다. 이것이 전환 첫해에 많은 팀이 빠지는 함정입니다.

그 대신 우리는 결과를 측정하는 쪽으로 옮겼습니다. 어떤 기능이 고객이 기대한 대로 작동하는가. 인도 후에 다시 고쳐야 했는가. 시스템의 다른 부분에 문제를 일으켰는가. 이런 질문들은 재기가 더 어렵고 기록에 더 많은 품이 듭니다. 하지만 훨씬 정직합니다.

또 하나 배운 것은 보기 좋게 발표하기 쉬운 숫자의 유혹입니다. 코드 줄 수는 깔끔한 보고서에 넣기 아주 쉽습니다. 반면 "재작업 비율"은 말하기가 더 껄끄럽습니다. 처음부터 제대로 못 한 게 있었음을 인정하는 셈이기 때문입니다. 그런데 바로 그 불편함이 가치 있는 지표라는 신호입니다. 자랑하려고만 있는 지표는 아무것도 개선하지 못합니다.

리드타임, 재작업률, 검수 통과율: 방향은 어떻게 움직였나

우리가 관찰한 방향으로는, 초안 생성 단계의 리드타임이 뚜렷하게 줄었고, 검수 절차가 단단해지면서 재작업률이 점차 내려갔으며, 첫 검수 통과율은 느리지만 꾸준히 좋아졌습니다. 절대 수치는 공개하지 않고 방향만 말합니다. 그 폭은 프로젝트 종류에 크게 좌우되기 때문입니다.

지표별로 분명히 짚어보겠습니다. 리드타임, 즉 요청을 받은 순간부터 인도까지의 시간은 AI의 변화가 가장 눈에 띄는 곳입니다. 예전엔 며칠씩 걸리던 초안 생성 부분이 상당히 짧아졌습니다. 그런데 흥미로운 것은, 전체 리드타임이 같은 비율로 줄지는 않았다는 점입니다. 코드 생성이 빨라진 만큼 검수와 다듬기 단계로 더 많은 압력이 넘어갔기 때문입니다. 다시 말해 AI는 병목을 없앤 게 아니라 옮겼습니다. 코드 작성 속도만 보면 실제 개선 폭을 잘못 결론 내기 쉽습니다.

재작업률은 우리가 가장 신경 쓰는 지표입니다. 진짜 품질을 알려주기 때문입니다. 초기에 팀이 AI 결과물을 너무 믿던 시기엔, 재작업률이 오히려 올라간 때도 있었습니다. 불편하지만 중요한 사실입니다. AI가 빨리 쓴다고 해서 옳게 쓴 것은 아니며, 완성돼 보이는 초안이 미묘한 결함을 감출 수 있습니다. 우리가 더 꼼꼼히 검수하는 습관을 세운 뒤에야 재작업률이 지속 가능한 방향으로 내려가기 시작했습니다.

첫 검수 통과율은 우리가 아끼는 선행 지표입니다. 어떤 결과물이 첫 제출에서 곧바로 기준을 충족하는가, 아니면 여러 차례 수정을 거쳐야 하는가를 답합니다. 이 지표는 리드타임보다 훨씬 천천히 좋아집니다. 도구의 속도가 아니라 진짜 역량을 비추기 때문입니다. 구성원이 기준을 제대로 이해하고, 제출 전에 스스로 점검하고, 언제 AI를 믿고 언제 믿지 말아야 하는지를 아는지에 달려 있습니다. 이 지표가 느리지만 꾸준히 좋아지는 것이야말로, 우리가 보기엔 팀이 단지 도구로 빨라진 게 아니라 실제로 성숙해지고 있다는 가장 믿을 만한 신호입니다.

지표가 거짓말을 할 때: 측정의 함정과 우리가 빠졌던 오해

지표는 우리가 엉뚱한 것을 잴 때, 너무 짧은 기간만 볼 때, 또는 숫자가 성공을 비추는 대신 성공을 정의하게 둘 때 거짓말을 합니다. 우리의 가장 큰 함정은 속도의 단기 개선을 믿고서, 몇 달 뒤에야 드러나는 숨은 품질 비용을 놓친 것이었습니다.

이 함정에 대한 첫 번째 교훈은 관찰 기간 문제입니다. 초기 몇 주는 모든 속도 지표가 훌륭해 보였습니다. 그때 멈추고 승리를 선언했다면, 우리는 틀린 이야기를 한 셈이 됐을 것입니다. 몇 달이 지나 급하게 만든 결과물이 유지보수와 버그 수정을 요구하기 시작하고 나서야 진짜 비용이 드러났습니다. 지표는 눈앞의 이득만이 아니라 나중의 결과까지 담길 만큼 충분히 오래 관찰됐을 때 비로소 믿을 만해집니다.

두 번째 교훈은 굿하트의 법칙에 관한 것입니다. 어떤 척도가 목표가 되는 순간, 그것은 더 이상 좋은 척도이기를 멈춘다는 생각입니다. 우리가 한 지표를 공개적으로 추적하기 시작하자, 팀의 행동이 그 지표를 예쁘게 만드는 쪽으로, 때로는 건강하지 못한 방식으로 바뀌었습니다. 그래서 우리는 이 지표들을 개인 평가에 기계적으로 곧장 연결하지 않으려 일부러 조심합니다. 지표는 시스템을 이해하기 위한 것이지, 사람을 단순하게 줄 세우기 위한 것이 아닙니다.

세 번째 교훈, 아마도 가장 중요한 것은 활동과 진척의 혼동입니다. AI는 바쁘다는 느낌을 아주 강하게 만듭니다. 화면은 늘 새 코드로 가득하고 모든 것이 끊임없이 움직입니다. 하지만 움직임이 곧 전진은 아닙니다. 팀은 무척 바쁜데 고객에게 가는 가치는 그만큼 늘지 않는 시기가 있었습니다. "많이 하는 중"과 "제대로 끝내는 중"을 분명히 갈라놓고 나서야 진짜 그림이 보였습니다.

끝으로, 우리는 측정할 수 없는 것에 대해 스스로에게 정직해지는 법을 배웠습니다. 가장 중요한 가치들, 이를테면 사고의 명료함이나 옳은 질문을 던지는 능력 같은 것은 숫자로 환산하기가 거의 불가능합니다. 모든 것이 측정 가능한 척하는 게 오히려 실수입니다. 측정은 강력한 도구지만, 자기 한계에 대한 겸손과 함께 가야 합니다.

12개월 데이터에서 우리가 내린 운영 결정과 다음 측정 계획

1년치 데이터에서 우리는 세 가지 결정을 내렸습니다. 코드 생성보다 검수 단계에 자원을 더 투입하고, 도구를 확장하기 전에 사람을 먼저 교육하고, 개인이 아니라 프로젝트 단위로 측정한다는 것입니다. 다음 계획은 인도 시점의 속도만이 아니라 인도 후 장기 품질을 추적하는 것입니다.

첫 번째 결정은 병목이 옮겨가는 것을 관찰한 데서 곧장 나왔습니다. 코드 생성 속도가 더 이상 문제가 아니게 되자, 더 빠르게 쓰는 데 투자해봐야 얻는 게 거의 없었습니다. 가치는 검수 단계에 있습니다. 사람이 무엇이 인도할 만큼 충분히 좋은지를 결정하는 곳입니다. 그래서 우리는 자원과 주의와 교육을 이쪽으로 옮겼습니다. 이것은 큰 사고의 전환입니다. AI를 잘 쓰는 팀에서는 만드는 사람만큼이나 평가하는 사람이 중요합니다.

두 번째 결정은 우리가 늘 믿어온 것을 굳혀주었습니다. 도구가 생산성을 만드는 게 아니라 사람이 만든다는 것입니다. 데이터를 보면 결과의 가장 큰 차이는 도구를 쓰는 사람과 안 쓰는 사람 사이가 아니라, 잘 쓰도록 교육받은 사람과 대충 쓰는 사람 사이에 있었습니다. 그래서 우리는 확장보다 교육을 앞에 둡니다. 제대로 이해하지 못한 절차를 확장하는 것은 혼란을 복제하는 일일 뿐입니다.

세 번째 결정은 가능한 곳에서 개인이 아니라 프로젝트 단위로 측정하는 것입니다. 프로젝트는 고객이 받는 온전한 결과이고, 개인 지표보다 조작하기가 더 어렵습니다. 이 방식은 또한 건강하지 못한 내부 경쟁 대신 협업을 북돋웁니다.

앞으로 우리의 측정 계획은 분명히 장기 쪽으로 기웁니다. 우리는 인도 후 6개월, 1년이 지난 시점에 어떤 결과물이 어떻게 살아가는지를 보고 싶습니다. 유지보수가 얼마나 필요한지, 확장하기 쉬운지, 조용히 기술 부채를 쌓고 있지는 않은지. 이것들은 가장 재기 어렵고 가장 늦게 도착하지만, 진짜 품질에 대해 가장 정직한 지표입니다. 지난 1년이 우리에게 가르친 것은, 옳은 질문이 "AI 덕에 우리가 얼마나 빨라졌나"가 아니라 "우리가 더 오래가고 더 믿을 만한 것을 만들고 있는가"라는 사실입니다. 그것이 우리가 계속 좇을 지표입니다.