AI가 구현 코드를 빠르게 만들고 다시 고칠 수 있게 되면, 제품팀의 병목도 코드 작성에서 사라진다. Structure and Guarantees의 Adam Chlipala는 2026년 8월 4일 글에서 대규모 코드베이스를 계속 재작성하는 비용이 오늘날 SaaS 구독료 수준까지 내려갈 수 있다고 전망했다. 이 전망의 핵심은 “코드를 더 많이 만들자”가 아니다. 무엇을 다시 만들어도 되는지, 무엇은 절대 바뀌면 안 되는지를 먼저 정해야 한다는 데 있다.
저자는 프로덕션 코드를 희소한 자산으로 보지 말자고 제안한다. 새 보안 요구사항이 생기거나 더 나은 알고리즘이 나오면, 높은 수준의 요구사항에 조건을 추가해 구현을 다시 생성한다는 그림이다. 이때 오래 남는 것은 특정 언어로 쓴 구현이 아니라, 제품이 만족해야 할 기능·보안·성능 조건이다.
코드를 다시 만들 수 있으면 무엇이 제품 자산이 되는가
코드가 바뀌어도 제품의 정체성을 지키려면 요구사항이 구현보다 더 엄격해야 한다. “주문을 빠르게 처리한다”는 문장은 방향을 알려 주지만, 생성 도구가 따라야 할 기준은 되지 못한다. 몇 초 안에 끝나야 하는지, 재고가 동시에 바뀌면 어떤 결과를 보장하는지, 결제가 실패하면 무엇을 되돌려야 하는지가 함께 있어야 한다.
제품팀이 먼저 합의할 것은 네 갈래다. 사용자가 얻어야 할 성공 상태, 정상 흐름에서 벗어났을 때 허용할 예외, 개인정보·결제·권한처럼 절대 넘지 않을 경계, 그리고 화면·API·속도에서 통과를 판정할 방법이다. 이 네 가지가 비어 있으면 생성된 코드는 그럴듯해도 팀마다 다른 제품을 만들 수 있다.
자연어 요구사항은 왜 다시 사람 검토를 부르는가
원문은 자연어만으로 프로덕션 시스템을 완전히 자동 생성하기는 어렵다고 본다. 자연어에는 빈칸이 남기 때문이다. 저자는 EARS처럼 요구사항 문장의 일부를 정형화하는 방식도, 나머지가 자유로운 자연어로 남으면 생성기가 해석할 여지가 생긴다고 지적한다. 그 빈칸을 사람 검토로 계속 메워야 한다면 “항상 다시 쓰기”의 비용은 다시 높아진다.
그래서 제품 문서는 의도를 설명하는 글에서 끝나면 안 된다. 상태·입력·결과·금지 조건을 나눠 적고, 어떤 구현이 와도 통과 여부를 판정할 수 있게 만들어야 한다. 예를 들어 “재고가 있으면 주문을 처리한다”보다 “재고와 결제가 모두 맞으면 주문 한 건을 확정하고, 그 외에는 재고를 차감하지 않는다”가 생성과 테스트를 같은 기준으로 묶는다.
제품팀의 다음 산출물은 기능 목록보다 판정 기준이다
AI가 코드를 대체한다는 말은 제품 판단도 대체한다는 뜻이 아니다. 오히려 구현을 다시 만들 수 있는 선택지가 늘수록, 팀은 더 이른 단계에서 결정해야 한다. 어떤 결과가 사용자에게 성공인지, 어떤 손실은 허용할 수 없는지, 어떤 수치와 로그로 약속 이행을 확인할지를 제품 문서에 남겨야 한다.
Chlipala의 주장은 형식 기법이 이 자동화를 뒷받침해야 한다는 쪽까지 나아간다. 모든 팀이 곧바로 형식 명세를 도입할 필요는 없더라도, 제품 요구사항을 검사 가능한 조건으로 바꾸는 일은 지금 시작할 수 있다. 코드 생성의 속도 경쟁에서 앞서는 팀은 더 긴 프롬프트를 쓰는 팀이 아니라, 다시 만들어도 달라지지 않을 제품 조건을 이미 갖춘 팀일 가능성이 크다.
출처: Adam Chlipala, Rewrite All the Code, All the Time (2026-08-10 확인)