IBM 연구진이 자사의 AI 코딩 어시스턴트를 사용하는 개발자들을 대상으로 실제 효과를 조사했더니 예상 밖의 결과가 나왔다. 생산성 향상 효과는 분명히 있었지만, 모든 개발자에게 똑같이 나타나지는 않았다.

2024년 중반 IBM 내부에 도입된 watsonx Code Assistant(WCA)를 두고 벌어진 일이다. 5월과 7월 두 차례에 걸쳐 실시한 대규모 설문에는 총 669명이 응답했고, 별도로 15명을 대상으로 한 실제 사용 테스트도 진행됐다.

응답자들은 백엔드 개발자가 59.6%로 가장 많았고, 프론트엔드 개발자 19.9%, QA/테스트 개발자 19.3%가 뒤를 이었다. IBM 경력도 신입부터 30년 넘는 베테랑까지 다양했다.

“새 코드 짜달라”보다 “이게 뭔 코드야?” 질문이 더 많았다

연구진이 주목한 건 개발자들의 사용 패턴이었다. 당연히 새로운 코드 생성 요청이 가장 많을 거라 생각했는데, 실상은 달랐다.

가장 많이 사용된 기능은 코드 설명(71.9%)과 프로그래밍 질문 답변(68.5%)이었다. 정작 코드 생성은 55.6%에 그쳤다. AI를 코드 제조기가 아닌 해석기로 쓰고 있었던 셈이다.

한 개발자의 말이 이를 잘 보여준다. “WCA를 주로 두 가지 용도로 쓴다. 다른 사람이 짠 코드를 처음 볼 때 설명받는 것과, 내 코드가 이상하게 돌아갈 때 뭐가 문제인지 찾는 것.”

또 다른 개발자는 “함수 기능을 설명해주는 게 좋다. 이해하는 데 걸릴 시간을 많이 절약해준다”고 평가했다.

예상 밖의 사용자들도 있었다. 기술 문서 작성자들이 개발자에게 묻기 민망한 전문 용어를 AI에게 물어보기 시작한 것이다. 한 작성자는 “개발자가 준 기술 용어와 코드를 이해하는 데 도움을 받는다. 개발자와 논의하는 시간을 줄여준다”고 말했다.

57% “도움 된다” vs 43% “별로다”

전체적인 수치는 나쁘지 않았다. 7점 척도 조사에서 작업 용이성, 품질 향상, 속도 향상 모든 항목이 플러스를 기록했다. 통계적으로 분명한 개선 효과가 확인됐다.

문제는 개인차였다. 57.4%만 “더 효과적”이라고 답했고, 42.6%는 “오히려 비효율적”이라고 평가했다. 같은 도구를 써도 체감하는 효과가 이렇게 갈릴 수 있나 싶을 정도였다.

만족한 개발자들은 확신에 차 있었다. “코드 제안과 자동완성 기능이 업무 생산성을 크게 향상시킨다.” “새 프로젝트의 여러 클래스를 문서화하고 설명받아 더 빠르게 이해할 수 있었다.”

하지만 불만족한 개발자들의 목소리도 만만치 않았다. “때로는 주제에서 벗어나 시간만 버린다. 원하는 결과 얻으려면 몇 번씩 재시도해야 해서 비생산적이다.”

신뢰성 문제를 지적하는 목소리도 있었다. “100%에 가까운 정확성이 없으면 내가 실제로 모르는 주제에 대해서는 답변을 신뢰할 수 없다.” “답변을 검증하는 데 시간을 써야 한다.”

“인턴 수준”이라는 냉정한 평가

개발자들이 매긴 AI 실력은 5점 만점에 3.20점. 그냥 보통이었다. 응답 속도는 2.88점으로 더 아쉬웠다. “코드 제안이 더 빨라야 한다. 지금은 내 타이핑 속도를 따라오지 못한다”는 불만도 나왔다.

많은 사용자가 현재 성능을 “인턴”이나 “주니어 개발자” 수준으로 평가했다. “어떤 면에서는 프로젝트에 막 시작한 인턴 같다. 많은 감독이 필요하지만 일부 업무는 맡길 수 있다”는 표현이 대표적이다.

또 다른 개발자는 더 구체적이었다. “주니어 개발자가 도와주는 것으로 생각한다. 훨씬 빠르게 코드를 생성하고 보통 더 나은 품질을 제공하지만, 여전히 실수나 예외 상황이 있어서 꼼꼼한 검토와 수정이 필요하다.”

그대로 복붙은 거의 안 해

흥미롭게도 개발자들이 AI 생성 코드를 그대로 사용하는 경우는 거의 없었다. 2~4%에 불과했다. 대신 이런 식으로 활용했다.

수정해서 사용하는 비율은 9~19%, 학습 목적으로 쓰는 비율은 23~35%, 새로운 아이디어를 얻는 용도는 24~37%였다. “결과물이 새로운 아이디어를 준다”, “생각하지 못했던 접근법을 추천해준다”는 평가가 많았다.

한 개발자는 “코드로 마크다운 다이어그램을 만드는 방법을 배웠다”고 말했고, 다른 개발자는 “내가 무엇을 해야 하는지는 알지만 어떻게 해야 하는지 모르거나 잊었을 때 도움이 된다”고 평가했다.

저작권 걱정이 생각보다 컸다

개발자들이 가장 민감하게 반응한 건 저작권 문제였다. 83.4%가 “AI가 다른 사람의 저작권 자료를 재생산할 수 있다”고 우려했다. 다른 연구의 46%보다 훨씬 높은 수치다.

책임은 공동 부담으로 봤다. 89.2%가 사용자 책임을, 96.2%가 AI 책임을 인정했다. 한 개발자는 “도구를 사용하는 사람으로서 어떤 코드가 포함되는지 알 책임이 있다”고 말했고, 다른 개발자는 “저작권 자료는 감지되어야 하고, AI가 이를 할 수 없다면 즉시 개선해야 한다”고 주장했다.

새로운 딜레마도 생겼다. AI와 함께 만든 코드의 저작권은 누구 것일까? 놀랍게도 많은 개발자가 관대했다. AI가 아이디어만 제공해도 39.8%가 공동 저작권을 인정했고, AI가 코드를 생성하고 사용자가 수정한 경우엔 64.4%가 공동 저작권을 인정했다.

“더 창의적인 일 vs 머리 안 쓰게 될 것” 전망 갈려

개발자들은 AI가 자신들의 미래를 어떻게 바꿀지 궁금해했다. 의견은 크게 갈렸다.

낙관론자들은 기대감을 숨기지 않았다. “반복적이고 평범한 코드 생성 작업을 AI가 처리하면 개발자들은 더 어렵고 고차원적이며 창의적인 문제 해결에 집중할 수 있을 것이다.”

비관론자들은 걱정이 앞섰다. “AI를 별로 좋아하지 않는다. 사람들을 게으르게 만들고 생각하지 않는 개념을 조장한다.” “우리 모두 훨씬 바보가 되어서 더 많은 양의 더 나쁜 코드를 관리하게 될 것 같다.”

예상치 못한 부작용도 발견됐다. AI로 생산성이 올라가자 관리자들이 더 많은 업무를 기대하기 시작한 것이다. 한 개발자는 “팀이 AI 사용을 기대받게 되면서 관리진이 이전보다 한 스프린트에 더 많은 작업을 기대한다”고 털어놨다.

한편 28명(4.2%)은 지난 2주간 AI를 아예 사용하지 않았다고 답했다. 이유로는 “스스로 하는 게 더 빨라서”(39.3%), “도움 되는 제안을 안 해서”(32.1%), “코드 관련 업무를 안 해서”(25.0%) 등을 들었다.

일부는 사회적 압박감도 느꼈다. “AI로 생성한 코드가 내 PR에 있는 걸 보이고 싶지 않다. 너무 부끄럽다”는 고백도 나왔다. “도구가 너무 새롭고 팀에서 사용하는 사람이 거의 없어서 AI 생성 코드에 대한 본능적인 의심이 있다”는 지적도 있었다.

연구진은 이번 결과가 2024년 여름 특정 시점의 스냅샷이라는 한계를 인정했다. AI 기술이 빠르게 발전하고 있어 품질과 속도 문제는 곧 개선될 것으로 전망했다. 하지만 한 가지는 변하지 않을 것이라고 강조했다. 어떤 소프트웨어를 만들지 결정하는 인간의 독창성과 통찰력 말이다.

결국 AI 코딩 어시스턴트는 만능 해결책이 아니라 새로운 종류의 도구였다. 잘 쓰면 분명 도움이 되지만, 모든 이에게 똑같이 효과적이지는 않다는 게 이번 조사의 핵심 결론이다.