코딩 보조 AI가 만든 작업 완료량의 증가
코딩 보조 AI는 개발자를 더 빠르게 만든다고 알려져 있다. 하지만 정말...


    •  

    코딩 보조 AI가 만든 작업 완료량의 증가
    - 도구를 도입한 것이 아니라 무작위 실험으로 확인한 변화

    코딩 보조 AI는 개발자를 더 빠르게 만든다고 알려져 있다. 하지만 정말 중요한 건 속도감이 아니라, 실제로 끝나는 일이 늘어났는지다. 세 개의 현장 무작위 실험은 바로 그 질문에 숫자로 답을 내놓았다.

    빠르다는 말 대신 끝난 일이 늘었는가를 묻다
    코딩 보조 도구는 반응이 극단적으로 갈리는 기술이다. 써본 사람은 확실히 빨라졌다고 말하고, 안 써본 사람은 코드가 허술해질까 걱정한다. 그런데 여기서 중요한 점이 하나 있다. 빨라졌다는 느낌만으로는 판단할 수 없다. 코드를 더 빨리 쓰는 것과, 실제로 일이 더 많이 끝나는 것은 다를 수 있다. 개발은 개인 속도만으로 굴러가지 않는다. 회의가 있고, 리뷰가 있고, 테스트가 있고, 배포가 있고, 운영이 있다. 한 사람이 빨라져도 그 다음 단계가 막히면 전체 속도는 그대로일 수 있다.

    그래서 질문은 이렇게 바뀐다. 도구를 주면 실제로 끝나는 일이 늘어나는가. 그리고 그 효과는 누구에게서 크게 나타나는가. 이 질문이 까다로운 이유는 간단하다. 도구를 먼저 쓰는 사람은 원래 학습이 빠를 수 있고, 먼저 도입하는 팀은 원래 정리가 잘된 팀일 수 있다. 그러면 도구 덕분인지, 원래 잘하던 사람과 팀 덕분인지 구분하기가 어려워진다.

    무작위 배정이 해주는 일
    여기서 가장 깔끔한 방법이 무작위 실험이다. 사람을 둘로 나눈 뒤, 한쪽에만 도구를 먼저 주고, 다른 쪽은 그대로 일하게 둔다. 이렇게 하면 도구를 쓰는지 여부가 개인 성향이 아니라 배정의 결과가 된다. 그리고 두 집단이 같은 회사 안에서, 같은 시기, 비슷한 일을 하는 동안 어떤 차이가 생기는지 비교할 수 있다.

    이 방식이 좋은 이유는 단순하다. 도구가 좋아 보인다는 인상 대신, 실제 업무 흐름에서 어떤 변화가 생기는지 확인할 수 있기 때문이다. “기분상 빨라졌다”가 아니라 “끝난 일이 늘었다”를 말할 수 있게 된다.

    세 회사에서 진행된 현장 실험을 한데 묶어 본 연구
    프린스턴 대학교, 매사추세츠 공과대학 슬론 경영대학, 펜실베이니아 대학교, 마이크로소프트 리서치 연구진이 함께 분석한 연구는 세 개 기업에서 진행된 현장 무작위 실험을 묶었다. 마이크로소프트와 액센추어, 그리고 익명 포춘 100 전자 제조 기업이 대상이었다.

    공통된 구조는 매우 단순하다. 일부 개발자에게 코딩 보조 도구 접근 권한을 먼저 줬고, 나머지는 기존 방식으로 일하게 했다. 일정 기간 비교한 뒤에는 모든 집단에 도구 접근을 열었다. 이 과정 덕분에 “누가 원래 도구를 좋아했는지” 같은 요인이 결과에 끼어들 틈이 줄었다.

    회사마다 운영 방식은 조금 달랐다. 마이크로소프트와 액센추어는 두 집단을 일정 기간 명확히 갈라 비교했고, 익명 기업은 팀별로 도입 시점을 달리하는 방식으로 비교가 가능하도록 설계했다. 연구진은 업무 관리 시스템과 작업 기록에서 주 단위로 완료된 업무량이 어떻게 달라지는지 추적했다.

    완료 작업 수 평균 26퍼센트 증가가 의미하는 것
    세 회사의 데이터를 합쳐 4,867명을 통합 분석한 결과, 코딩 보조 도구를 쓴 집단은 완료된 작업 수가 평균 약 26퍼센트 늘었다. 회사마다 업무의 성격이 달라 증가 폭은 완전히 같지 않았지만, 전체적으로는 “끝나는 일이 더 많아졌다”는 방향이 확인됐다.

    또 한 가지 눈에 띄는 점은 누가 더 크게 좋아졌는지다. 경력이 짧거나 숙련이 낮은 개발자일수록 도구를 더 자주 쓰는 경향이 있었고, 개선 폭도 더 큰 경향이 보고됐다. 쉽게 말해 이 도구가 가장 먼저 도와주는 사람은 이미 빠른 사람이 아니라, 시행착오가 많은 구간에 있는 사람일 가능성이 크다.

    속도만 올리고 품질을 놓치지 않으려면
    끝나는 일이 늘었다는 결과가 나오면 다음 걱정이 따라온다. 그럼 품질은 괜찮은가. 빨리 끝낸 만큼 버그가 늘거나, 리뷰가 더 힘들어지거나, 재작업이 늘지는 않는가.

    이 지점에서 중요한 것은 한 가지다. 속도는 도구가 끌어올려도, 품질은 조직의 방식이 지켜줘야 한다. 리뷰 기준이 느슨하고 테스트가 약하면, 빨라진 속도는 나중에 더 큰 비용으로 돌아올 수 있다. 반대로 코드 규약이 분명하고 테스트 자동화가 잘 되어 있고 리뷰 문화가 단단하면, 속도 상승이 품질 하락으로 번지지 않을 가능성이 커진다.

    그래서 도입 순서가 중요하다. 시작점은 주니어와 신규 투입 구간이 좋다. 학습 곡선을 낮추고 팀 전체 속도를 안정시키는 효과가 기대되기 때문이다. 동시에 리뷰 기준, 테스트 자동화, 코드 규약을 함께 정비하는 편이 안전하다. 도구만 주고 나머지를 그대로 두면, 빨라진 만큼 팀이 더 바빠질 수 있다.

    채택률도 관리해야 한다. 시간이 지나도 모두가 쓰지 않을 수 있는데, 그 이유는 반감보다 습관과 업무 흐름이 맞지 않아서인 경우가 많다. 교육도 기능 설명보다, 어디에서 쓰고 어디에서는 쓰지 않을지 팀이 합의하도록 돕는 방식이 실전에서 더 강하다.

    결론은 단순하다. 코딩 보조 AI는 개발자를 빠르게 만드는 도구이기도 하지만, 팀이 일하는 방식을 더 정돈되게 만들 때 가장 큰 효과를 낸다. 무작위 실험이 보여준 26퍼센트는 희망 섞인 체감이 아니라, 실제로 끝난 일이 늘어날 수 있다는 신호다. 그리고 그 신호를 좋은 결과로 만들지는 도구가 아니라 운영이 결정한다.

    Reference
    Cui, Zheyuan Kevin; Demirer, Mert; Jaffe, Sonia; Musolff, Leon; Peng, Sida; Salz, Tobias. (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Working Paper.