A사는 올해 초 전사에 AI 코딩 도구를 도입했다. 라이선스 비용만 수억 원이다. 경영진은 기대에 차서 말했다. "이제 개발 기간을 절반으로 줄일 수 있겠네요." 개발자들도 동의했다. 실제로 화면 하나, API 하나는 몇 시간이면 나왔다. 예전 같으면 일주일 걸리던 일이다.
그런데 6개월이 지났다. 출시일은 작년과 똑같이 밀렸다.
개발자들은 분명 더 빨라졌다. 코드 라인 수도, 커밋 수도 세 배가 넘는다. 그런데 프로젝트는 왜 빨라지지 않았을까?
6년 전에 쓴 문장
필자는 2019년 스펙 연재의 머릿말에 이렇게 썼다.
"소프트웨어 프로그래머는 인공지능으로 대체될 가능성이 매우 높은 직업이다. 하지만 소프트웨어 스펙을 작성하는 분석 아키텍트는 인공지능으로 대체될 가능성이 가장 낮은 직업 중 하나다."
그때만 해도 먼 미래의 이야기처럼 들렸을 것이다. 하지만 불과 몇 년 만에 앞의 절반은 현실이 되었다. 코딩은 이제 거의 공짜다.
그런데 코딩이 공짜가 되자 이상한 일이 벌어졌다. 프로젝트는 여전히 늦고, 여전히 실패한다. 오히려 그동안 가려져 있던 것이 선명하게 드러났다.
코딩은 처음부터 병목이 아니었다.
코딩이 병목처럼 보였던 이유
『소프트웨어 개발의 모든 것』에서 필자는 "소프트웨어 지식 영역에서 코딩 즉, 구축이 차지하는 비중은 얼마 안 된다"고 썼다. 많은 개발자가 동의하지 않았다. 하루 종일 하는 일이 코딩인데 비중이 작다니.
하지만 그 "코딩 시간"을 들여다보면 순수한 코딩은 많지 않다. 개발자는 코딩을 하면서 동시에 이런 일을 하고 있었다.
- 스펙에 없는 내용을 추측한다.
- 기획자를 찾아가 물어본다. 답이 오기를 기다린다.
- 다른 팀이 만드는 모듈이 어떻게 동작할지 짐작한다.
- 짐작이 틀려서 다시 짠다.
- 요구사항이 바뀌어서 또 다시 짠다.
이 모든 것이 "개발 기간"이라는 이름으로 뭉뚱그려져 있었다. 그래서 개발이 늦으면 코딩이 느리다고 생각했다. 개발자를 더 뽑거나 야근을 시키면 해결될 것이라고 믿었다.
AI는 이 뭉치에서 순수한 코딩만 쏙 뽑아냈다. 그리고 그 시간을 0에 가깝게 줄였다. 그러자 남은 것들이 보이기 시작했다.
진짜 병목은 거기 있었다
프레드릭 브룩스는 "소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라, 무엇을 개발할지 결정하는 일이다"라고 했다. AI는 이 말을 증명하는 거대한 실험이 되었다.
코딩을 걷어내고 나면 프로젝트를 붙잡고 있는 것은 다음과 같다.
- 무엇을 만들지 정하지 않았다.
- 정한 것을 적지 않았다.
- 적은 것을 서로 합의하지 않았다.
- 바뀐 것을 관리하지 않았다.
- 만든 것이 맞는지 확인할 기준이 없다.
어느 것 하나 AI가 대신 해주지 않는다. 그리고 이것들은 모두 스펙, 리뷰, 베이스라인, 검증이라는 이름으로 소프트웨어 공학이 수십 년간 이야기해 온 것들이다.
AI는 병목을 더 키운다
문제는 여기서 끝나지 않는다. AI는 병목을 해결하지 못할 뿐 아니라 오히려 키운다.
사람 개발자는 모르면 묻는다. 적어도 망설이기라도 한다. 하지만 AI는 묻지 않는다. 스펙이 모호하면 가장 그럴듯한 답으로 빈칸을 채우고 자신 있게 결과물을 내놓는다. 겉보기엔 완벽하다. 문제는 그것이 고객이 원한 것이 아니라는 사실을 한참 뒤에 알게 된다는 것이다.
잘못된 방향으로 가는 속도가 열 배 빨라진 것이다.
1:10:100 rule은 AI 시대에도 그대로다. 만드는 비용은 줄었지만 잘못 만든 것을 되돌리는 비용은 줄지 않았다. 그 사이에 데이터가 쌓이고, 다른 시스템이 연동되고, 고객이 써버렸기 때문이다.
경영자에게
AI에 투자한 것이 잘못은 아니다. 하지만 병목이 아닌 곳에 투자한 것이다.
고속도로를 아무리 넓혀도 톨게이트가 하나뿐이면 차는 막힌다. 지금 많은 회사가 고속도로만 넓히고 있다. 톨게이트는 그대로 둔 채 말이다.
진짜로 개발 속도를 올리고 싶다면 병목에 투자해야 한다. 무엇을 만들지 정하고 적는 데 시간을 허락해야 한다. 그것을 리뷰하고 합의하는 문화를 만들어야 한다. 바뀐 것을 추적할 수 있는 기반을 갖춰야 한다. AI는 그 위에서 비로소 제 속도를 낸다.
개발자에게
코딩이 내 일의 전부였다면 지금은 분명 위기다.
하지만 병목을 푸는 일이 내 일이라면 지금은 기회다. 개발자가 할 일이 줄어든 것이 아니다. 일의 무게중심이 코딩에서 무엇을 만들지 정하고, 적고, 검증하는 쪽으로 옮겨 갔을 뿐이다.
『소프트웨어 개발의 모든 것』에서 필자는 "잘 설계된 제품은 임시계약직원이라 할지라도 구현할 수 있어야 한다"고 썼다. 이제 그 임시계약직원 자리에 AI가 들어왔다. 누가 구현해도 같은 결과가 나올 만큼 명확하게 적을 수 있는 개발자, 그 개발자가 AI 시대에 가장 빠른 개발자다.
물론
AI가 쓸모없다는 이야기가 아니다. 오히려 반대다.
병목을 해결한 회사에서 AI는 정말로 열 배의 속도를 낸다. 스펙이 있는 팀은 AI에게 일을 통째로 맡길 수 있다. 베이스라인이 있는 팀은 변경의 영향을 AI에게 분석시킬 수 있다. 리뷰 문화가 있는 팀은 AI가 만든 결과를 빠르게 걸러낼 수 있다.
같은 AI를 써도 어떤 회사는 열 배 빨라지고, 어떤 회사는 열 배 빨리 망가진다. 차이는 AI가 아니라 그 회사가 이미 가지고 있던 체질이다.
이 연재에서는 그 체질에 대해 이야기하려고 한다. AI 시대에 개발자는 무엇을 해야 하는지, AI를 어떻게 써야 정말로 빨라지는지, 경영자는 어디에 투자해야 하는지, 그리고 왜 AI로 만든 시스템이 2~3년 만에 버려지는지.
AI는 코딩을 공짜로 만들었다. 하지만 무엇을 만들지 정하는 일까지 공짜로 만들어 주지는 않는다.
병목은 처음부터 거기 있었다. AI가 불을 켰을 뿐이다.
