비즈니스제179호

버그만 잡겠다는 팀장은 왜 없을까

AI가 코드는 짜줘도, 고칠 이유는 아무도 안 줘요

안광섭 (오스왈드)· 오즈의 지식토킹 글쓴이·편집자

버그만 잡겠다는 팀장은 왜 없을까

들어가며

구독자님, 지난주에 이런 일들을 겪었다는 어느 개발자의 글을 읽었어요. 은행 앱은 결제 확인 화면까지 얼굴 인식을 세 번 요구했고, 뒤늦게 뜬 슬랙 창이 포커스를 가로채는 바람에 터미널에 치던 명령어가 단체 채팅방으로 전송됐어요. 냉장고 보증 수리 신청은 긴 양식을 다 채운 뒤 마지막에 실패했고요. 차량 인포테인먼트는 업데이트 이후 주행 중에 재부팅을 해요.

그가 덧붙인 장면이 인상적이었어요. 몇 달 전 그 차량 운영체제를 새로 디자인한 팀의 PM이 링크드인에 훌륭한 일을 해냈다며 자축하는 글을 올렸대요. 매일 그 제품과 싸우는 사용자는 그 글을 계속 떠올리게 되고요.

만드는 쪽의 자축과 쓰는 쪽의 체감이 이렇게까지 벌어지는 시기는 흔치 않아요. 결론부터 말씀드릴게요. AI는 ‘코드를 빨리 못 만드는 문제’를 상당 부분 풀었어요. 그런데 ‘고친 사람에게 아무도 보상하지 않는 문제’는 건드리지 않았어요. 도구가 좋아질수록 격차는 벌어져요.

처리량이 늘어난 건 사실이에요

먼저 분명히 해둘 게 있어요. “AI 때문에 다 나빠졌다”는 식의 이야기가 아니에요. 속도는 실제로 빨라졌어요.

구글 DORA 팀이 전 세계 기술 인력 약 5,000명을 조사한 2025년 보고서를 보면, 응답자의 90%가 업무에 AI를 쓰고 있었고 하루 사용 시간 중앙값은 2시간이었어요. 그리고 2024년 조사와 달리, AI 채택도가 높을수록 소프트웨어 전달 처리량과 제품 성과가 함께 올라가는 관계가 관측됐어요. 팀들이 도구를 어디에 어떻게 쓸지 학습해 나가고 있다는 뜻이에요.

같은 방향의 개별 데이터도 있어요. 코드 변경 이력을 분석하는 GitClear가 2026년 1월에 낸 보고서를 보면, AI를 가장 많이 쓰는 개발자 집단은 비사용자보다 4~10배 많은 결과물을 냈어요. 다만 여기엔 정직한 단서가 붙어요. 그 격차의 상당 부분은 AI 이전부터 있던 개인 역량 차이였고, 같은 사람의 과거와 비교하면 속도 향상은 25% 수준이었어요. AI가 잘하는 사람을 만든 게 아니라, 원래 잘하던 사람이 AI를 먼저 집어 들었다는 해석에 가까워요.

문제는 같은 DORA 보고서에 나란히 실린 다른 결과예요. AI 채택도가 높을수록 배포 불안정성1도 함께 올라갔어요. 장애로 인한 계획에 없던 배포가 늘어난다는 의미예요. DORA는 이 조합을 이렇게 정리해요. AI는 증폭기라고요. 잘 굴러가던 조직의 강점도 키우고, 삐걱대던 조직의 결함도 똑같이 키운다는 거예요.

사라진 건 코드가 아니라 습관이에요

그럼 무엇이 증폭되고 있을까요. GitClear가 2026년에 내놓은 후속 연구가 이 지점을 꽤 구체적으로 짚어요. 2023년부터 2026년까지 코드 변경 6억 2,300만 건을 여덟 개 신호로 나눠 추적한 자료인데요. 방향이 한쪽으로 일관돼 있어요.

가장 눈에 띄는 건 리팩토링2의 실종이에요. 전체 변경 라인 중 ‘옮겨진 코드’, 그러니까 기존 코드를 정리하고 재배치한 비율이 2022년 21%에서 2026년 현재 3.8%로 내려갔어요. 같은 기간 복사해서 붙여넣은 코드 비율은 9.4%에서 15.7%로 올라갔고요. 2022년만 해도 개발자들은 붙여넣기보다 정리하기를 2배 더 자주 택했는데, 지금은 반대로 붙여넣기가 약 5배 우세해요. 선호가 뒤집힌 정도가 아니라 방향이 통째로 바뀐 거예요.

나머지 숫자도 같은 이야기를 해요. 다섯 줄 이상 그대로 반복되는 중복 블록은 2023년 대비 81% 늘어 관측 이래 최고치예요. 새로 쓴 코드가 기존 코드의 다른 함수를 호출하는 빈도는 35% 줄었어요. 새 코드가 기존 코드베이스에 엮이지 않고 혼자 떨어진 파일에 고립된다는 뜻이에요. 1년 이상 손대지 않은 오래된 코드를 다시 열어 정리하거나 폐기하는 작업의 비중은 1.7%에서 0.46%로, 74% 줄었어요.

이게 왜 문제인지는 중복 블록 하나를 떠올리면 쉬워요. 다섯 줄짜리 블록이 열 군데 흩어져 있으면, 그중 하나를 고치는 사람은 나머지 아홉 개를 전부 찾아내서 “여기도 같이 바꿔야 하나”를 판단할 의무를 자동으로 떠안아요. 자기가 모르는 파일과 모르는 도메인까지요. 오늘 30초 아낀 대가를 3년 뒤 누군가가 반나절씩 나눠서 갚는 구조예요.

GitClear는 이 상태를 ‘유지보수성 격차’라고 불러요. 그리고 보고서에서 핵심을 이렇게 요약해요. 문제는 AI가 나쁜 코드를 쓴다는 게 아니라, 지금의 기본 워크플로가 행복 경로 하나, 통과하는 테스트 하나, 닫힌 티켓 하나를 내놓도록 설계돼 있다는 점이라고요. 눈에 보이고 즉시 닫히는 것에는 보상이 가고, 눈에 안 보이고 미뤄지는 것에는 조용히 세금이 붙어요.

그런데 왜 아무도 안 고칠까요

여기서 진짜 질문이 나와요. 도구는 이렇게 좋아졌는데, 왜 아무도 이 부채를 갚지 않을까요. 앞서 인용한 개발자는 그 답을 가상의 발표 문구로 적었어요.

“이번 분기에는 신규 기능을 출시하지 않고, 재설계 계획도 없습니다. 오직 버그 수정에만 집중하겠습니다.”

이 문장을 실제로 분기 계획 슬라이드에 올릴 수 있는 조직이 얼마나 될까요. 저는 거의 못 봤어요. 이유는 단순해요. 신규 기능은 데모가 있고 발표할 스토리가 있고 성과 평가에 쓸 문장이 나와요. 안정화는 성공하면 ‘아무 일도 일어나지 않음’이라는 형태로 나타나요. 잘한 일의 증거가 부재라는 형태로만 존재하는 셈이에요.

bug그래서 이건 기술 문제로 보이지만, 실제로는 측정과 보상의 문제예요. 처리량은 대시보드에 실시간으로 뜨고, 유지보수성은 3년 뒤 청구서로 와요. 관리자가 둘 중 하나만 볼 수 있다면 어느 쪽을 관리하게 될지는 정해져 있어요.

한국은 이 왜곡이 개별 회사의 문화를 넘어 산업 가격표에 적혀 있어요. 공공 소프트웨어 유지관리요율3 이야기예요. 정부는 2017년 국정현안점검조정회의에서 요율을 15% 수준에서 2022년까지 20%로 올려 외산 소프트웨어(약 22%)와의 격차를 줄이겠다고 확정했어요. 그런데 소프트웨어정책연구소의 2019년 산업 실태조사를 보면, 응답 기업의 **29.8%**가 여전히 10% 미만 요율을 적용받고 있었어요. 민간 평균이 14.2%였으니 공공이 더 낮았던 셈이고요. 만드는 값은 쳐주고 고치는 값은 깎는 관행이 수십 년째 문서로 남아 있는 거예요.

결과도 조용히 쌓여요. 금융감독원은 2026년 3월 디지털·IT 부문 업무설명회에서, 최근 발생한 사고의 상당수가 정교한 해킹 기술 때문이 아니라 기본적인 보안 원칙과 내부 통제가 지켜지지 않은 데서 비롯됐다고 짚었어요. 실패의 원인이 첨단이 아니라 기본이라는 진단이에요. 기본은 원래 아무도 칭찬해주지 않는 영역이고요.

이 숫자들도 의심해 봐야 해요

여기까지 읽고 “역시 AI가 문제였네”로 정리하면 곤란해요. 근거들의 한계를 같이 봐야 해요.

먼저 GitClear는 중립적 관찰자가 아니에요. 코드 품질과 개발 생산성을 측정하는 도구를 파는 회사예요. 품질 지표가 나빠지고 있다는 결론은 이 회사의 사업과 이해관계가 겹쳐요. 데이터 규모가 크다는 점과 해석이 중립적이라는 점은 별개예요.

DORA 조사도 상당 부분 자기보고 설문이고, 관측된 건 상관관계예요. AI를 많이 쓰는 팀이 불안정한 건지, 원래 빠르게 밀어붙이는 팀이 AI도 먼저 쓰는 건지는 이 데이터만으로 못 갈라요.

가장 흥미로운 건 한때 널리 인용된 METR 연구예요. 2025년 7월 발표에서 숙련 개발자 16명에게 246개 실제 작업을 무작위 배정4한 결과, AI를 쓸 때 완료 시간이 19% 더 걸렸다는 내용이었어요. 그런데 METR은 2026년 2월에 스스로 실험 설계를 수정했어요. AI로 이득을 크게 보는 개발자일수록 ‘AI 금지’ 조건 참여를 꺼리는 선택 편향이 있었다는 이유였고, 재참여자 기준으로는 오히려 18% 빨라졌다는 추정치를 내놨어요. 요약하면 연구팀 본인이 “AI가 생산성을 높이는지 우리도 아직 모른다”에 가까운 입장으로 물러선 거예요.

다만 이 수정 이후에도 살아남는 발견이 하나 있어요. 인식과 시계의 격차예요. 참가자들은 시작 전 24% 빨라질 거라고 예상했고, 실험이 끝난 뒤에도 20% 빨라졌다고 느꼈어요. 측정값이 어느 쪽이든, 사람이 자기 생산성 변화를 감으로는 정확히 못 잰다는 결론은 그대로 남아요. 그리고 대부분의 조직은 지금 바로 그 감을 근거로 도구를 도입하고 인력 계획을 세우고 있어요.

오스왈드의 시선

GTM 전략을 만들면서 제품 로드맵 회의에 수없이 들어가 봤는데요. 안정화 항목이 우선순위에서 밀리는 장면은 거의 예외 없이 반복됐어요. 흥미로운 건 그 자리의 누구도 품질을 가볍게 보지 않는다는 점이에요. 그런데 분기 목표에 넣을 문장을 고를 때가 되면, “장애를 40% 줄였습니다”보다 “신규 기능 세 개를 출시했습니다”가 이깁니다. 앞의 문장은 안 일어난 일을 증명해야 하고, 뒤의 문장은 보여주면 되니까요.

데이터 쪽 경험을 하나 보태면, 측정되는 것만 관리된다는 말은 조직에서 거의 물리 법칙처럼 작동해요. 그래서 저는 이번 사안의 원인이 AI에 있다고 보지 않아요. 원래 있던 왜곡이고, AI는 그걸 훨씬 빠르게 집행해주는 장치일 뿐이에요. 기능을 만드는 비용이 10분의 1이 되면, 원래도 기능 쪽으로 기울어 있던 저울은 더 심하게 기울어요. 반대로 정리하고 폐기하는 일은 여전히 사람의 판단과 시간을 요구하니 상대적으로 더 비싸 보이고요.

그래서 저는 이 문제를 도구 선택의 문제로 접근하는 조직은 대체로 실패할 거라고 봐요. 커서를 쓰든 클로드 코드를 쓰든, 분기 계획에 ‘고치는 일’의 자리가 없으면 결과는 같아요. DORA가 내린 결론도 정확히 같은 말이에요. AI 도입 성공은 도구 문제가 아니라 시스템 문제라고요.

한 가지는 열어둘게요. 원문을 쓴 개발자도 비관 대신 이런 기대를 남겼거든요. 회사들이 부채를 쌓는 동안, 개인 개발자는 예전이라면 엄두도 못 냈을 소프트웨어를 혼자 만들 수 있게 됐다고요. 같은 도구가 부채를 만들기도 하고, 그 부채에 질린 사람에게 대안을 만들 힘을 주기도 해요.

마치며

세 줄로 정리할게요. AI 도입 이후 처리량은 늘었지만, 리팩토링 3.8%와 중복 블록 81% 증가처럼 코드를 오래 살게 하는 습관은 일제히 후퇴했어요. AI가 나쁜 코드를 써서가 아니라, 닫힌 티켓에는 보상이 가고 안 일어난 장애에는 아무 보상이 없기 때문이에요. 한국은 그 왜곡을 유지관리요율이라는 형태로 가격표에 새겨두기까지 했고요.

이번 분기에 해볼 만한 걸 하나 제안할게요. 로드맵을 열어서 몇 퍼센트가 ‘고치고 정리하는 일’에 배정돼 있는지 세어보세요. 0에 가깝다면 팀의 문제가 아니라 계획서의 문제예요.

혹시 신규 기능 대신 안정화에 분기를 통째로 쓴 조직을 보신 적 있나요? 그 결정이 어떻게 통과됐는지, 그다음 평가에서 그 팀이 어떤 대접을 받았는지가 특히 궁금해요.

💬 안정화에 분기를 쓴 조직의 사례를 댓글로 들려주세요. 다음 호에 반영해볼게요. 📨 로드맵에 품질 항목을 밀어 넣느라 고생하는 동료가 있다면 이 글을 공유해 주세요.

참고자료 & 더 읽기

핵심 출처

배경 지식

함께 읽으면 좋은 지난 호

📝 용어 설명

안광섭 프로필 일러스트

필자 안광섭은 세종대학교 경영학과 교수이자 OBF(Oswarld Boutique Consulting Firm) 리드 컨설턴트이다. 대학에서 경영데이터 관리, 비즈니스 애널리틱스 등 통계 및 데이터 분석을 가르치는 한편, 현장에서는 GTM 전략과 인공지능 전략 컨설팅을 이끌며 기술과 비즈니스의 접점을 설계하고 있다. AI 대화 시스템의 기억 아키텍처(HEMA) 연구로 학술 논문을 발표했으며, 매일 글로벌 AI 논문을 큐레이션하는 Daily Arxiv 프로젝트를 운영하고 있다. 고려대학교 기술경영전문대 석사과정와 KMBA을 졸업했다. 지은 책으로 《생각을 맡기는 사람들: 호모 브레인리스》가 있다.

각주

  1. 배포 불안정성 (delivery instability): 새 코드를 내보낸 뒤 장애나 결함 때문에 계획에 없던 배포를 다시 해야 하는 빈도를 뜻해요. 속도와 달리 사용자가 곧바로 체감하는 지표예요. ↩

  2. 리팩토링 (refactoring): 프로그램이 하는 일은 그대로 두고 코드의 구조만 정리하는 작업이에요. 방을 새로 늘리는 게 아니라 이미 있는 짐을 정리하는 쪽에 가까워요. ↩

  3. 유지관리요율: 소프트웨어 개발비에 곱해서 연간 유지보수 비용을 정하는 비율이에요. 요율이 10%면 1억 원짜리 시스템의 연간 유지보수비가 1,000만 원이 되는 식이에요. ↩

  4. 무작위 배정 (randomized assignment): 참가자나 작업을 실험 조건에 무작위로 나누는 방식이에요. 조건 외의 차이가 결과에 섞이는 걸 줄여줘서, 단순 비교보다 인과관계를 말하기에 유리해요. ↩

SEND A COFFEE

이 관점이 좋았다면, 다음 글에 커피 한 잔

오스왈드에게 커피와 함께 짧은 쪽지를 보내주세요. 응원은 다음 취재와 집필에 보탭니다.

FOR OSWARLD

커피와 쪽지 보내기

“버그만 잡겠다는 팀장은 왜 없을까”을 읽고 떠오른 말을 남겨주세요. 메뉴 이름만큼의 응원금과 함께 전달됩니다.

어떤 커피로 보낼까요?

여러분의 생각이 다음 호를 만듭니다

이번 호에서 가장 공감했거나, 다른 경험을 한 지점은 무엇인가요?

댓글은 무료 회원이면 누구나 남길 수 있어요.

함께 읽으면 좋은 지난 호

제178호비즈니스

내려받을 순 있어요, 돌릴 수 없을 뿐

2.8조 파라미터 Kimi K3와 '오픈'의 재계산

제177호비즈니스

토끼가 죽어도 청구서는 날아온다

재미로 올린 번역 112화, 법원이 매긴 값은 9,637만 원이었어요

제176호비즈니스

새 연준 의장은 왜 스타트업처럼 말할까

"숫자는 아직인데 곧 옵니다", 이 화법이 금리를 움직이기 시작했어요