코드 리뷰가 다시 짜기보다 비싸졌다 — AI가 뒤집은 개발 경제학

개발자라면 누구나 알고 있는 불문율이 하나 있습니다. “이미 짜놓은 코드는 함부로 다시 짜지 마라.” 그런데 요즘 이 상식이 흔들리고 있습니다. AI가 코드를 찍어내는 비용이 거의 공짜에 가까워지면서, “고쳐 쓰는 것보다 버리고 새로 짜는 게 싸다"는 말이 진지하게 나오고 있는데요. 오늘은 소프트웨어 개발의 오래된 경제학이 어떻게 뒤집히고 있는지 이야기해보려 합니다.

왜 우리는 코드를 함부로 안 버렸을까

먼저 짚고 넘어갈 게 있습니다. 지금까지 코드를 다시 짜는 일이 왜 그렇게 금기시됐을까요.

이유는 단순합니다. 코드를 쓰는 비용이 비쌌기 때문입니다. 사람이 한 줄 한 줄 타이핑하고, 그 안에 쌓인 수많은 버그 수정과 예외 처리의 흔적을 다시 만들어내려면 엄청난 시간이 들었습니다. 넷스케이프가 코드를 통째로 다시 짜겠다고 결정했다가 회사가 휘청였던 일화는 개발자들 사이에서 두고두고 회자되는 교훈이죠.

그래서 개발의 무게중심은 늘 “이미 있는 것을 이해하고 고치는 쪽"에 있었습니다. 새 코드를 쓰는 시간보다 남의 코드를 읽고 파악하는 시간이 훨씬 길다는 게 정설이었고요. 코드 리뷰, 리팩터링, 문서화 같은 활동이 중요했던 이유도 결국 “비싼 자산을 어떻게 오래 잘 굴릴 것인가"의 문제였습니다.

AI가 바꾼 비용 구조

여기서 게임의 룰이 바뀝니다. AI 코딩 도구가 등장하면서 코드를 생산하는 비용이 급격히 떨어졌기 때문입니다.

한때 반나절 걸리던 기능 구현이 이제는 프롬프트 몇 줄로 몇 분 만에 나옵니다. 단순한 CRUD 화면이나 데이터 변환 스크립트 정도는 거의 즉석에서 만들어지죠. 코드를 쓰는 행위 자체가 더 이상 병목이 아니게 된 겁니다.

문제는 다른 비용은 그대로라는 점입니다. 사람이 남이 짠(혹은 AI가 짠) 코드를 읽고, 의도를 파악하고, 미묘한 버그를 찾아내는 리뷰 비용은 거의 줄지 않았습니다. 오히려 AI가 그럴듯해 보이지만 미묘하게 틀린 코드를 대량으로 쏟아내면서, 검증의 부담은 더 커졌습니다. 생산은 싸지고 검토는 그대로니, 두 비용의 비율이 뒤집히기 시작한 겁니다.

“리뷰하느니 다시 짠다"는 역전

이 변화가 만드는 결론이 흥미롭습니다. 만약 어떤 코드 조각을 리뷰하고 이해하는 데 한 시간이 걸리는데, AI에게 명세를 주고 다시 짜게 하면 십 분이면 끝난다면, 우리는 어떤 선택을 해야 할까요.

전통적으로는 답이 정해져 있었습니다. 당연히 있는 걸 고쳐 쓴다. 하지만 비용 곡선이 바뀐 지금은 “차라리 버리고 새로 짜는 게 합리적"인 상황이 생깁니다. 특히 다음과 같은 경우가 그렇습니다.

• 작성자가 떠났거나 맥락이 사라진 고아 코드
• 테스트는 잘 갖춰져 있지만 내부 구조가 엉망인 모듈
• 명세는 명확한데 구현만 지저분한 작은 컴포넌트

핵심은 “명세와 테스트가 명확하다"는 전제입니다. 무엇을 만들어야 하는지가 분명하다면, AI에게 그 명세를 다시 던져 새 구현을 받는 편이 기존 코드를 한 줄씩 해독하는 것보다 싸질 수 있습니다. 코드가 자산에서 일회용 출력물에 가까워지는 셈이죠.

그래서 진짜 비싸진 것은 무엇인가

하지만 여기서 성급한 결론을 내리면 곤란합니다. 코드를 다시 짜는 게 싸졌다고 해서, 개발이 통째로 쉬워진 건 아니기 때문입니다.

오히려 가치의 무게중심이 이동했습니다. 코드 자체가 싸지면서, 진짜 비싸진 것은 무엇을 만들지를 정의하는 능력입니다. 명세가 모호하면 AI는 모호한 코드를 무한히 찍어냅니다. 테스트가 부실하면 새로 짠 코드가 맞는지 검증할 방법이 없죠. 결국 명세, 테스트, 아키텍처 판단 같은 “사람이 의도를 못 박는 활동"의 가치가 올라갑니다.

흥미로운 건 코드 리뷰의 성격도 바뀐다는 점입니다. 예전엔 “이 한 줄이 맞나"를 보던 리뷰가, 이제는 “이 덩어리를 통째로 신뢰할 수 있나, 아니면 버릴까"를 판단하는 의사결정에 가까워집니다. 줌인에서 줌아웃으로, 검토의 해상도가 달라지는 거죠.

물론 이 흐름이 모든 곳에 적용되진 않습니다. 수십 년간 미세한 버그 수정이 쌓인 결제 시스템이나 보안 모듈처럼, 코드 한 줄에 녹아든 맥락이 곧 자산인 영역에서는 “다시 짜기"가 여전히 자살행위에 가깝습니다. 역전이 일어나는 건 어디까지나 맥락이 얕고 명세가 분명한 코드에 한해서입니다.

지금 우리가 보고 있는 건 단순한 도구의 발전이 아니라, 소프트웨어를 자산으로 볼 것인가 소모품으로 볼 것인가라는 근본 질문의 재배치입니다. 코드를 쓰는 비용이 0에 수렴할 때, 개발자의 진짜 일은 코드를 짜는 것이 아니라 “무엇이 옳은지 정의하고 판단하는 것"으로 옮겨갑니다. 여러분의 코드베이스에서, 다시 짜는 게 더 싼 부분은 어디이고 절대 손대면 안 되는 부분은 어디인가요. 그 경계를 구분하는 감각이, 앞으로 가장 비싼 기술이 될지도 모릅니다.