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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

AI coding assistants are said to make developers faster. But what truly matters is not the feeling of speed, but whether more work actually gets finished. Three randomized field experiments provided a numerical answer to that question.

Coding assistants are a technology that provokes sharply divided reactions. People who have used them say they definitely became faster, while those who have not worry that the code may become sloppy. But one point matters here. A feeling of speed alone is not enough to make a judgment. Writing code faster and actually finishing more work are not always the same. Software development does not run on individual speed alone. There are meetings, reviews, tests, deployments, and operations. Even if one person becomes faster, the overall pace can remain unchanged if the next stage is blocked.

So the question shifts to this. If a tool is given, does the amount of work that actually gets finished increase. And for whom does the effect appear most strongly. This question is tricky for a simple reason. The people who start using a tool first may already learn quickly, and the teams that adopt first may already be well organized. Then it becomes difficult to separate what comes from the tool from what comes from people and teams that were already strong.

The cleanest method here is a randomized experiment. People are divided into two groups, and only one side receives access to the coding assistant first, while the other continues working in the usual way. This makes tool use the result of assignment rather than personal preference. It also allows comparison of what differences emerge while both groups work within the same company, in the same period, on similar tasks.

This approach is valuable for a simple reason. It makes it possible to confirm what changes occur in real work flows rather than relying on impressions that a tool seems good. It enables statements not like it felt faster, but like more work got finished.

A study analyzed by researchers from Princeton University, the MIT Sloan School of Management, the University of Pennsylvania, and Microsoft Research combined field randomized experiments conducted at three companies. The subjects were Microsoft, Accenture, and an anonymous Fortune 100 electronics manufacturing company.

The common structure was very simple. Some developers were granted access to a coding assistant first, while others continued working with the existing approach. After comparing outcomes for a set period, access to the tool was opened to all groups. This process reduced the room for factors such as who originally liked the tool to influence the results.

Operational details differed somewhat by company. Microsoft and Accenture clearly separated the two groups for a defined period, while the anonymous company used a design that varied the timing of adoption by team so that comparison was possible. The researchers tracked how weekly completed work volume changed using work management systems and task records.

When data from the three companies were pooled and analyzed across 4,867 people, the group using the coding assistant showed an average increase of about 26 percent in the number of completed tasks. Because the nature of work differed by company, the size of the increase was not identical, but overall the direction that more work was getting finished was confirmed.

Another notable point is who improved more. Developers with shorter tenure or lower skill tended to use the tool more often, and they also tended to show larger gains. Put simply, the people this tool helps first may be not those who are already fast, but those who are in a stage where trial and error is frequent.

Once results show that more work gets finished, the next concern follows. Is quality still okay. Do bugs increase, does review become harder, or does rework rise because tasks were finished faster.

One point matters here. A tool may raise speed, but quality must be protected by how the organization works. If review standards are loose and testing is weak, faster speed can return later as a much larger cost. On the other hand, if coding conventions are clear, test automation is strong, and review culture is solid, the chances increase that a speed boost will not spill into quality decline.

That is why the order of rollout matters. A good starting point is junior developers and newly staffed roles. It can reduce the learning curve and stabilize overall team velocity. At the same time, it is safer to improve review standards, test automation, and coding conventions together. If only the tool is introduced and everything else is left unchanged, the team may simply become busier in proportion to the increased speed.

Adoption rates also need to be managed. Even over time, not everyone may use the tool, and the reason is often less resistance than a mismatch between habits and the existing work flow. Training is also more effective when it focuses less on feature explanations and more on helping the team agree on where to use the tool and where not to use it.

The conclusion is simple. AI coding assistants can make developers faster, but they deliver their biggest effect when they also push the team’s way of working to become more organized. The 26 percent shown by randomized experiments is not hopeful intuition. It is a signal that the amount of finished work can actually increase. And whether that signal becomes a good outcome is determined not by the tool, but by operations.

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.