AI가 코드를 싸게 만들면, 저장소에는 무엇을 남겨야 할까

AI가 코드를 싸게 만들면, 저장소에는 무엇을 남겨야 할까

IT & AI 뉴스 썸네일

AI가 코드를 만드는 비용이 더 내려가면 오래된 구현을 고쳐 쓰는 방식도 달라질 수 있어요. Adam Chlipala는 코드베이스 전체를 자주 다시 생성하는 미래를 제안해요. 이 구상에서 오래 남는 자산은 소스 코드가 아니라 보안, 성능, 동작을 모호하지 않게 적은 명세예요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
코드의 수명	구현 코드를 오래 보존하기보다 요구사항에서 필요할 때 다시 생성해요	레거시 코드의 가치와 유지보수 방식이 함께 달라질 수 있어요
장기 자산	저장소에는 가능한 한 높은 수준의 요구사항과 제약을 남겨요	보안 정책이나 성능 목표가 바뀌어도 전체 구현에 한꺼번에 반영할 수 있어요
자동화의 조건	사람이 매번 결과를 검토하면 전체 재작성의 비용 이점이 줄어요	생성 속도보다 명세의 정확성과 자동 검증이 더 큰 병목이 돼요
현재의 한계	자연어는 같은 문장도 여러 방식으로 해석할 수 있어요	LLM만으로 프로덕션 시스템 전체를 무감독 재생성하기 어렵다는 반론이에요
제안한 방향	형식 기법과 논리 기반 프로그램 합성을 더 적극적으로 써요	생성된 구현이 요구사항을 만족하는지 수학적으로 다룰 길을 열어요

1. 코드 전체를 다시 쓰는 시대에는 명세가 제품의 원본이 돼요

원문이 그리는 미래에서는 프로덕션 코드가 지금의 어셈블리 코드와 비슷한 위치로 내려가요. 개발자가 직접 오래 관리하는 핵심 자산이 아니라, 더 높은 수준의 표현에서 자동으로 만들어지는 결과물이 되는 거예요. 보안 설계가 바뀌거나 더 나은 알고리듬이 나오면 기존 코드를 부분 수정하지 않아요. 새 요구사항을 반영해 코드베이스 전체를 다시 생성해요. 1

유지보수 단위가 파일과 함수에서 요구사항으로 올라가요

지금은 오래된 코드의 동작을 파악하고 영향 범위를 좁힌 뒤 필요한 부분만 고치는 일이 많아요. 전체 재생성 비용이 충분히 낮아지면 팀은 구현보다 요구사항을 수정할 수 있어요. 예를 들어 모든 서비스에 새 비밀 유지 정책을 적용하거나, 메모리 사용량 상한을 추가한 뒤 전체 시스템을 다시 만들 수 있어요.

728x90

이때 저장소에 남겨야 할 내용도 달라져요. 기능 목록만으로는 부족해요. 허용할 동작과 금지할 동작, 성능 한도, 보안 정책, 오류 처리처럼 구현 결과를 판정할 조건이 필요해요. 어떤 프로그램이 생성돼도 그 조건을 만족하면 받아들일 수 있을 정도로 명세가 구체적이어야 해요. 2

원문은 이를 두 경쟁 업체에 일을 나누는 사고실험으로 설명해요. 한 업체는 명세만 쓰고 다른 업체는 그 명세를 만족하는 프로그램을 구현해요. 구현자가 요구사항을 자신에게 가장 유리하게 해석해도 안전하도록 명세를 작성해야 해요. AI 생성기도 모호한 지시를 뜻밖의 방식으로 구현할 수 있으니 같은 기준을 적용할 수 있어요.

자연어 문서만으로는 버튼 한 번의 재생성이 어려워요

현재의 명세 중심 개발은 자연어 문서를 출발점으로 삼는 경우가 많아요. 하지만 "빠르게", "안전하게", "적절한 권한" 같은 표현에는 판정 기준이 없어요. 같은 요구사항을 읽은 사람이나 모델이 서로 다른 프로그램을 만들 수 있어요. 생성 뒤에 사람이 매번 검토하고 수정해야 한다면 코드 전체를 자주 다시 만드는 모델은 비용을 아끼기 어려워요.

EARS(Easy Approach to Requirements Syntax)는 `WHILE`, `WHEN`, `SHALL` 같은 키워드로 요구사항 문장의 틀을 잡아요. 조건과 반응을 분리하는 데는 도움이 돼요. 다만 키워드 사이에 들어가는 자연어의 뜻까지 하나로 고정하지는 못해요. 구조화된 문서가 곧 검증 가능한 형식 명세가 되는 것은 아니에요. 2

원문은 사람이 개입하지 않는 재생성에 형식 기법이 필요하다고 봐요. 요구사항을 수학적 의미가 분명한 언어로 적고, 생성된 프로그램이 그 조건을 만족하는지 증명하거나 검사하는 방식이에요. LLM은 후보 구현을 찾는 데 쓰고, 논리 기반 도구는 허용 범위를 확인하는 조합도 생각할 수 있어요.

AI 코딩의 속도보다 검증 비용을 먼저 계산해야 해요

코드 생성 시간이 짧아져도 테스트, 보안 검토, 배포 승인에 사람이 오래 매달리면 전체 비용은 크게 줄지 않아요. 특히 코드베이스 전체를 다시 만들 때는 이전 버전과 동작이 같은지 확인하는 회귀 테스트만으로 부족해요. 이전 구현의 우연한 동작을 그대로 보존하는 대신 제품이 지켜야 할 조건을 직접 검증해야 해요.

팀이 지금 준비할 수 있는 일은 모든 코드를 지우고 다시 만드는 것이 아니에요. 요구사항과 구현이 뒤섞인 부분부터 분리할 수 있어요. 접근 제어 규칙, 데이터 보존 기간, 지연 시간 상한, 장애 시 동작을 자동 검사 가능한 조건으로 옮기면 코드 생성 도구가 바뀌어도 남는 자산이 생겨요.

1960년대의 자동 프로그래밍도 비슷한 논쟁을 거쳤어요. 당시 컴파일러와 고급 언어는 하드웨어가 실행할 저수준 코드를 자동으로 만들었어요. 오늘날 개발자는 그 결과물을 직접 관리하지 않아요. 원문은 AI 코드 생성도 프로그래밍의 추상화 수준을 한 단계 올리는 흐름으로 봐요. 다만 자연어에서 곧바로 신뢰할 수 있는 시스템을 만드는 일은 컴파일보다 훨씬 모호하다는 차이가 있어요. 2

왜 중요한가요

이 전망은 "AI가 개발자를 대체할까"보다 소프트웨어의 원본을 무엇으로 볼지 묻고 있어요. 코드 생성 단가가 낮아질수록 기업이 보유한 레거시 코드의 양은 경쟁력이 되기 어려워요. 반대로 제품 규칙을 정확히 표현한 명세, 검증 가능한 테스트, 보안 정책은 새 구현을 만들 때마다 재사용할 수 있어요. 2

현실에서는 전체 재작성이 곧바로 일상화되기 어려워요. 외부 API의 미묘한 동작, 오래된 데이터 형식, 문서에 없는 운영 규칙이 기존 코드에 숨어 있기 때문이에요. 형식 명세를 만드는 데 드는 비용도 작지 않아요. 코드 생성 비용만 내려가고 요구사항 정제와 검증 비용이 그대로라면 병목은 앞단으로 이동할 뿐이에요.

그래도 개발팀이 확인할 질문은 선명해요. 제품의 핵심 규칙이 코드 밖에 명확히 남아 있는지, 새 구현이 같은 규칙을 지켰다고 자동 판정할 수 있는지, 보안과 성능 요구사항을 문장이 아닌 검사 조건으로 표현할 수 있는지 봐야 해요. 이 기반이 있어야 AI가 만든 코드를 빠르게 검토하는 수준을 넘어 구현을 안전하게 교체할 수 있어요.

참고 자료

1. 모든 코드를, 항상 다시 작성하라 — GeekNews
2. Rewrite All the Code, All the Time — Structure and Guarantees, Adam Chlipala