AI 시대, 코드는 다시 만들어지고 명세가 소프트웨어의 핵심 자산이 될까

AI를 활용한 코드 생성 비용이 계속 낮아진다면 소프트웨어를 개발하고 유지하는 방식은 지금과 크게 달라질 수 있습니다. 지금까지는 한 번 작성한 프로덕션 코드를 오랫동안 보존하면서 수정하고 개선하는 것이 일반적이었습니다. 하지만 코드를 필요할 때마다 빠르게 다시 생성할 수 있다면 이야기가 달라집니다.

보안 요구사항이 새롭게 발견되거나 더 나은 알고리듬이 등장했을 때 기존 코드를 일일이 수정하는 대신, 변경된 요구사항을 반영해 전체 코드베이스를 다시 생성하는 방식이 가능해질 수 있습니다.

이러한 관점에서 중요한 질문이 하나 생깁니다.

반응형

코드를 언제든 다시 만들 수 있다면, 소프트웨어에서 장기적으로 보존해야 할 것은 무엇일까요?

제공된 자료에서는 그 답을 코드가 아닌 명세(specification)에서 찾습니다. 코드 생성 비용이 충분히 낮아지면 구현 코드는 장기적으로 보존해야 하는 자산이 아니라 명세로부터 만들어지는 결과물이 될 수 있다는 것입니다.

다만 이를 실현하기 위해서는 단순히 AI가 코드를 잘 작성하는 것만으로는 부족합니다. 자연어 요구사항의 모호성을 해결하고, 사람이 계속 개입하지 않아도 요구사항을 만족하는 프로그램을 안정적으로 생성할 수 있어야 합니다. 이 과정에서 형식 기법과 논리 기반 자동 프로그래밍이 중요한 역할을 할 가능성이 제시됩니다.

프로덕션 코드를 계속 보존해야 할 이유가 사라진다면

현재 소프트웨어 개발에서는 기존 코드베이스 자체가 중요한 자산입니다.

오랜 기간 운영된 시스템에는 수많은 기능과 예외 상황, 보안 대응, 성능 개선 등이 코드 형태로 축적되어 있습니다. 따라서 기존 코드를 함부로 버리고 처음부터 다시 작성하는 것은 일반적으로 큰 비용과 위험을 동반합니다.

하지만 AI를 통한 코드 생성 비용이 크게 낮아진다면 이런 전제가 달라질 수 있습니다.

대규모 코드베이스를 다시 구현하는 비용이 현재의 SaaS 구독료 수준까지 낮아지는 상황을 가정해볼 수 있습니다. 그렇다면 개발 조직은 기존 코드를 최대한 오래 유지하는 대신, 요구사항이 바뀔 때마다 프로젝트 전체를 다시 생성하는 방식을 선택할 수 있습니다.

예를 들어 다음과 같은 변화가 가능합니다.

• 새로운 보안 문제가 발견되면 전체 애플리케이션에 새로운 보안 설계를 적용해 다시 생성합니다.
• 기존보다 더 나은 알고리듬이 등장하면 새로운 알고리듬을 반영해 프로그램 전체를 재생성합니다.
• 성능이나 메모리 사용량 같은 비기능 요구사항도 명세에 반영한 뒤 새로운 구현을 생성합니다.

이렇게 되면 기존 코드에 변경 사항을 하나씩 누적하는 방식보다 요구사항을 수정하고 전체 시스템을 다시 만드는 방식이 경제적으로 더 합리적일 수 있습니다.

레거시 코드의 가치가 낮아질 수 있는 이유

코드 재작성 비용이 충분히 낮아지면 오래된 코드가 가지고 있던 가치도 달라질 수 있습니다.

지금은 레거시 코드가 기업의 중요한 자산으로 취급되는 경우가 많습니다. 오랜 기간 쌓인 시스템의 동작 방식과 업무 로직이 코드에 들어 있기 때문입니다.

하지만 AI가 기존 코드를 쉽게 대체할 수 있는 수준에 도달한다면 상황이 달라집니다.

자료에서는 이를 현재의 Assembly language와 고급 프로그래밍 언어의 관계에 빗대어 설명합니다.

오늘날 개발자가 직접 Assembly 코드를 장기간 보존하는 것보다 고급 언어로 프로그램을 작성하고 필요한 저수준 결과물을 도구가 생성하도록 하는 것이 일반적입니다.

이와 같은 변화가 더 높은 수준으로 올라간다면, 지금 우리가 작성하는 일반적인 소스 코드 역시 장기 보존 대상이 아니라 자동 생성되는 결과물로 취급될 수 있다는 관점입니다.

즉, 소프트웨어의 추상화 수준이 한 단계 더 높아지는 것입니다.

과거에는 사람이 저수준 코드를 작성했다면 고급 프로그래밍 언어가 이를 대신했습니다. 앞으로는 사람이 직접 구현 코드를 작성하는 대신 더 높은 수준의 명세를 작성하고, AI나 자동화 시스템이 구현을 만들어내는 형태로 이동할 수 있다는 의미입니다.

자동 프로그래밍은 완전히 새로운 변화가 아니다

AI를 활용한 코드 생성은 갑자기 등장한 개념처럼 보이지만, 더 넓게 보면 자동 프로그래밍이 발전해 온 흐름의 연장선으로 볼 수 있습니다.

자료에서는 1962년의 자동 프로그래밍에 대한 논의까지 거슬러 올라갑니다.

당시에도 고급 프로그래밍 언어와 컴파일러가 등장하면서 관리자가 직접 프로그래밍할 수 있게 될 것이라는 전망이 있었습니다. 프로그래머 입장에서는 자신들의 숙련된 작업이 자동화되는 것에 대한 우려가 나올 수밖에 없었습니다.

하지만 현재 개발자에게 고급 프로그래밍 언어를 사용하는 것은 너무나 당연한 일입니다.

프로그래밍의 추상화 수준은 계속 높아져 왔습니다.

이런 관점에서 AI 코드 생성 역시 기존 개발 방식을 완전히 단절시키는 기술이라기보다, 프로그램을 표현하는 수준을 한 단계 더 높이는 변화로 볼 수 있습니다.

구현 언어와 명세 언어를 완전히 별개의 것으로 보기보다는 같은 프로그램을 서로 다른 수준에서 표현하는 방식으로 이해할 수 있다는 것입니다.

장기적으로 저장해야 할 것은 코드보다 높은 수준의 요구사항

그렇다면 AI가 코드를 다시 만들어주는 환경에서 무엇을 저장해야 할까요?

자료에서 제시하는 핵심은 가능한 한 높은 수준의 요구사항과 명세를 저장하는 것입니다.

프로그램의 구체적인 구현 방식보다 시스템이 무엇을 해야 하는지, 어떤 조건을 반드시 만족해야 하는지를 명확하게 기록하는 것입니다.

예를 들어 보안 요구사항이 새롭게 발견됐다고 가정해보겠습니다.

기존 방식이라면 현재 코드에서 문제가 발생할 수 있는 부분을 찾아 직접 수정해야 합니다.

반면 명세 중심의 방식에서는 고수준의 보안 요구사항을 명세에 추가하고, 해당 명세를 만족하는 프로그램 전체를 다시 생성하는 방식으로 접근할 수 있습니다.

성능 역시 마찬가지입니다.

단순히 "빠른 프로그램을 만들어 달라"고 요구하는 것이 아니라, 특정 성능 조건을 만족하지 못하면 프로그램 생성 자체가 실패하도록 요구사항을 명확하게 표현하는 방식까지 생각할 수 있습니다.

이 구조가 가능해지면 중요한 것은 코드가 아니라 어떤 구현이 만들어져도 받아들일 수 있을 만큼 명확한 명세가 됩니다.

중요한 것은 '코드를 생성하는 AI'보다 '모호하지 않은 명세'

여기에서 중요한 문제가 등장합니다.

AI가 코드를 생성할 수 있다고 해서 자동으로 완전한 자동 프로그래밍이 가능한 것은 아닙니다.

사람이 자연어로 작성한 요구사항에는 모호성이 존재하기 때문입니다.

예를 들어 "충분히 빠르게 동작해야 한다"는 요구사항이 있다고 생각해보겠습니다.

사람에게는 어느 정도 의미가 전달될 수 있지만, 이를 프로그램이 자동으로 구현해야 한다면 문제가 생깁니다.

'충분히 빠르다'는 정확히 어느 정도를 의미하는지 명확하지 않기 때문입니다.

이처럼 요구사항에 해석의 여지가 남아 있다면 AI가 이를 잘못 해석할 가능성이 있습니다.

따라서 단순히 자연어 요구사항을 입력하고 AI가 코드를 생성하는 방식만으로는 사람의 감독 없이 전체 시스템을 반복적으로 재생성하는 수준에 도달하기 어렵다는 관점입니다.

결국 핵심은 AI가 코드를 얼마나 잘 생성하느냐가 아니라 AI가 해석할 필요가 없을 정도로 명세를 명확하게 만들 수 있느냐에 있습니다.

구현자를 믿지 않아도 되는 명세가 필요하다

명세의 중요성을 이해하기 위한 사고실험도 생각해볼 수 있습니다.

하나의 소프트웨어 프로젝트를 두 계약업체에 나눠 맡긴다고 가정해보겠습니다.

첫 번째 업체는 명세만 작성합니다.

두 번째 업체는 해당 명세를 전달받고, 그 요구사항을 만족하는 프로그램을 구현합니다.

여기서 중요한 조건은 두 업체가 서로 경쟁 관계에 있다는 것입니다.

명세를 작성하는 업체는 구현자가 요구사항을 자신에게 가장 불리한 방식으로 해석할 수 있다고 가정해야 합니다.

따라서 "당연히 이런 의미겠지"라는 생각으로 빈틈을 남겨서는 안 됩니다.

모든 중요한 조건을 명확하게 표현해야 합니다.

이러한 방식으로 충분히 엄밀한 명세를 만들 수 있다면 같은 명세를 서로 다른 구현자에게 전달하더라도 요구사항을 만족하는 프로그램을 만들 수 있어야 합니다.

이 관점이 실현되면 기존 코드 자체를 오랫동안 보유하는 것이 기업의 중요한 경쟁력이 되기 어려울 수 있습니다.

대신 경쟁력은 정확한 요구사항을 정의하고 이를 엄밀한 명세로 만드는 능력에 가까워집니다.

자연어는 완전 자동화를 위한 명세로 부족할 수 있다

현재 AI 코드 생성에서 가장 익숙한 방식은 자연어로 요구사항을 전달하는 것입니다.

하지만 자연어는 사람이 이해하기에는 편리한 반면, 프로그램을 완전 자동으로 생성하기 위한 명세로 사용하기에는 문제가 있습니다.

자연어에는 본질적인 모호성이 있기 때문입니다.

자연어 요구사항을 일정한 형태로 구조화한다고 해서 이 문제가 완전히 사라지는 것도 아닙니다.

자료에서는 EARS(Easy Approach to Requirements Syntax)를 사례로 제시합니다.

EARS는 자유롭게 작성한 요구사항을 일정한 문법 구조에 맞춰 표현하는 방식입니다.

예를 들어 자판기의 요구사항을 단순한 자연어 문장으로 작성하는 대신, WHILE, WHEN, SHALL 같은 키워드를 사용해 조건과 동작을 일정한 구조로 표현할 수 있습니다.

이렇게 하면 요구사항의 형태는 훨씬 정돈됩니다.

하지만 키워드 사이에 들어가는 내용은 여전히 자연어일 수 있습니다.

따라서 자연어가 가진 모호성이 완전히 사라졌다고 보기는 어렵습니다.

AI 코드 생성기가 그 내용을 단순하게 오해할 수도 있고, 요구사항을 악의적인 방식으로 해석할 가능성도 남습니다.

결국 자연어를 구조화하는 것과 요구사항을 완전히 형식화하는 것은 다른 문제입니다.

사람이 계속 검토한다면 자동화의 경제성이 떨어진다

현재의 Spec-driven development 방식에서는 자연어 명세를 더 세밀한 명세로 단계적으로 변환하는 접근이 가능합니다.

하지만 변환 과정마다 사람이 결과를 확인하고 잘못된 부분을 수정해야 한다면 새로운 문제가 발생합니다.

바로 사람의 주의력이라는 병목입니다.

코드를 작성하는 작업 자체는 AI가 대부분 처리한다고 해도 사람이 매번 결과를 검토해야 한다면 전체 코드베이스를 지속적으로 다시 생성하는 모델의 경제성이 떨어질 수밖에 없습니다.

전체 코드를 다시 작성하는 것이 일상적인 작업이 되려면 새로운 요구사항을 반영한 재생성이 기존 프로그램을 다시 컴파일하는 것처럼 간단해야 합니다.

즉, 버튼 한 번으로 요구사항을 만족하는 실행 가능한 시스템을 다시 만들 수 있어야 한다는 것입니다.

이를 위해서는 자동화의 범위를 코드 생성 단계에만 두지 않고 개발 과정의 훨씬 앞단인 요구사항과 명세 단계까지 확대해야 합니다.

Deep learning만으로 충분할까

현재 AI 코드 생성의 중심에는 Deep learning이 있습니다.

대규모 데이터를 학습하고 다양한 코드 패턴을 바탕으로 적절한 결과를 생성하는 방식은 강력한 성능을 보여주고 있습니다.

하지만 자료에서는 이것이 완전한 자동 프로그래밍에 필요한 모든 문제를 해결해주는 것은 아니라고 봅니다.

Deep learning 기반 시스템은 대규모 예제를 분석하고 그 패턴을 활용하는 데 강점이 있습니다.

그러나 프로그램이 모든 요구사항을 항상 만족한다는 것을 수학적으로 증명해야 하는 상황에서는 다른 접근이 필요할 수 있습니다.

특히 자동 생성된 프로그램이 보안이나 성능과 같은 중요한 요구사항을 반드시 만족해야 한다면 "그럴 가능성이 높다"는 수준으로는 충분하지 않을 수 있습니다.

이 때문에 논리 기반 자동 프로그래밍이 대안으로 제시됩니다.

논리 기반 자동 프로그래밍이 제시하는 방향

자료에서는 AI가 학습된 패턴을 흉내 내는 방식에만 의존하지 않고, 보다 명확한 구조를 활용하는 여러 방향을 제시합니다.

첫 번째는 재사용 가능한 소프트웨어 컴포넌트 라이브러리입니다.

AI가 이미 학습한 패턴을 이용해 비슷한 기능을 만들어내도록 하는 대신, 검증된 소프트웨어 컴포넌트를 명확한 이름으로 직접 호출하도록 만드는 방식입니다.

두 번째는 의사결정 시스템과 문제 자체를 함께 설계하는 방식입니다.

AI가 해결해야 하는 문제를 무조건 복잡하게 만드는 대신, 시스템 자체를 단순화해 자동화하기 쉬운 형태로 만드는 것입니다.

세 번째는 자동화 대상 환경을 단순화하는 것입니다.

현실 세계는 복잡하고 모든 것을 형식화하기 어렵습니다. 하지만 경제적인 압력이 강해지면 자동화를 쉽게 할 수 있는 영역을 별도로 만들고, 해당 영역을 점점 확대하는 방향으로 움직일 수 있습니다.

이런 환경이 경제의 더 많은 영역으로 확대되고 서로 연결되면 모호하지 않은 요구사항을 수집하는 일 역시 쉬워질 수 있다는 관점입니다.

완전 자동화를 위해서는 형식 기법이 중요해진다

결국 이 논의는 형식 기법(formal methods)으로 이어집니다.

AI가 생성한 프로그램이 요구사항을 만족하는지 사람이 일일이 확인하지 않으려면, 요구사항 자체가 명확한 형식적 의미를 가져야 합니다.

자연어로 "보안이 충분해야 한다", "성능이 좋아야 한다"고 표현하는 수준을 넘어, 시스템이 반드시 만족해야 하는 조건을 보다 엄밀하게 표현해야 합니다.

그리고 그 명세를 만족하는 프로그램을 자동으로 생성할 수 있어야 합니다.

이 구조가 완성되면 소프트웨어 개발 과정은 지금과 상당히 달라질 수 있습니다.

현재는 대략 다음과 같은 흐름이 일반적입니다.

요구사항 → 설계 → 코드 작성 → 테스트 → 수정 → 배포

하지만 장기적으로는 다음과 같은 구조가 가능해질 수 있습니다.

엄밀한 명세 → 자동 생성 → 검증된 프로그램

요구사항이 변경되면 기존 코드를 직접 수정하는 것이 아니라 명세를 변경하고 프로그램 전체를 다시 생성하는 것입니다.

코드 전체를 다시 작성하는 것이 릴리스가 될 수 있다

이러한 미래가 현실화된다면 소프트웨어의 릴리스 개념도 달라질 수 있습니다.

기존에는 새로운 버전이 나오면 이전 코드에 변경 사항을 추가하고 수정한 결과물을 배포합니다.

하지만 코드 생성 비용이 충분히 낮고 명세에서 안정적으로 프로그램을 재생성할 수 있다면, 새로운 릴리스가 사실상 전체 코드베이스의 재작성이 될 수 있습니다.

보안 요구사항이 변경되면 새로운 보안 요구사항을 반영한 전체 프로그램을 다시 생성합니다.

더 나은 알고리듬이 등장하면 새로운 알고리듬과 프로젝트별 요구사항을 결합해 다시 생성합니다.

성능 요구사항이 변경돼도 이를 명세에 반영한 뒤 전체 시스템을 재생성할 수 있습니다.

이렇게 되면 기존 코드 때문에 최신 기술을 적용하기 어렵다는 문제가 줄어들 수 있습니다.

코드가 장기간 보존해야 하는 고정된 결과물이 아니라 필요할 때마다 만들어지는 결과물이라면, 새로운 환경과 요구사항에 맞춰 소프트웨어를 계속 다시 만드는 것이 기본적인 개발 방식이 될 수 있기 때문입니다.

미래의 소프트웨어 경쟁력은 명세로 이동할 수 있다

결국 이 논의에서 가장 중요한 변화는 코드 생성 기술 자체가 아닙니다.

더 중요한 변화는 소프트웨어의 장기적인 가치가 어디에 저장되는가입니다.

현재는 많은 조직이 코드베이스를 중요한 자산으로 관리합니다.

하지만 AI를 통해 코드를 저렴하고 안정적으로 다시 생성할 수 있다면 코드 자체의 희소성은 낮아질 수 있습니다.

그 대신 다음과 같은 것들의 중요성이 커질 수 있습니다.

• 시스템이 무엇을 해야 하는지 정의하는 요구사항
• 보안과 성능 같은 비기능 요구사항
• 요구사항을 모호하지 않게 표현한 명세
• 명세를 자동으로 실행 가능한 프로그램으로 변환하는 기술
• 생성된 프로그램이 요구사항을 만족하는지 검증하는 방법
• 사람의 개입을 최소화할 수 있는 형식 기법

결국 코드가 소프트웨어의 장기 자산이 아니라 명세에서 파생되는 일회성 산출물이 될 가능성을 생각해볼 수 있습니다.

그렇다면 개발자의 역할도 달라질 수 있다

이러한 변화가 현실화된다면 개발자의 역할 역시 달라질 가능성이 있습니다.

지금까지 개발자는 요구사항을 코드로 변환하는 역할을 수행했습니다.

하지만 코드 생성 자체가 자동화된다면 개발자가 집중해야 하는 지점은 더 높은 수준으로 이동할 수 있습니다.

무엇을 만들어야 하는지 정의하고, 어떤 조건을 반드시 만족해야 하는지 명확하게 표현하며, 자동화 시스템이 잘못 해석할 수 있는 부분을 제거하는 작업의 중요성이 커지는 것입니다.

즉, 개발의 핵심이 구현에서 명세로 이동하는 것입니다.

다만 이것이 곧바로 실현될 수 있다는 의미는 아닙니다.

현재 자연어 기반 AI 코드 생성에는 여전히 모호성과 오류라는 문제가 존재합니다. 사람이 계속 생성 결과를 검토해야 한다면 전체 코드 재생성을 일상적인 개발 방식으로 만들기 어렵습니다.

따라서 중요한 과제는 AI에게 코드를 더 잘 작성하도록 가르치는 것만이 아닙니다.

사람의 지속적인 감독 없이도 요구사항을 만족하는 프로그램을 생성할 수 있을 만큼 요구사항을 정확하게 표현하고 검증하는 방법을 만드는 것이 핵심 과제가 될 수 있습니다.

728x90

코드가 사라지는 것이 아니라 코드의 가치가 달라진다

AI 코드 생성 비용이 계속 낮아진다면 소프트웨어 개발 방식은 지금과 다른 방향으로 이동할 수 있습니다.

가장 큰 변화 중 하나는 기존 코드를 오랫동안 유지하고 수정하는 것보다 명세를 변경하고 전체 코드를 다시 생성하는 방식이 경제적으로 가능해지는 것입니다.

이런 환경에서는 레거시 코드의 가치가 지금보다 낮아질 수 있습니다. 코드가 언제든 자동으로 다시 만들어질 수 있다면 굳이 특정 구현 결과물을 장기간 보존해야 할 이유가 줄어들기 때문입니다.

그 대신 더욱 중요한 자산이 되는 것은 정확한 명세입니다.

새로운 보안 요구사항과 성능 조건을 반영할 수 있고, 서로 다른 구현자가 해석하더라도 동일한 요구사항을 만족할 수 있을 만큼 명확한 명세가 필요합니다.

여기에서 자연어의 한계가 나타납니다. 자연어를 일정한 형식으로 구조화하더라도 의미 자체가 모호하다면 완전한 자동화에는 한계가 있습니다.

따라서 장기적으로는 자연어보다 더 명확한 형식 의미론을 가진 언어와 형식 기법, 논리 기반 자동 프로그래밍이 중요한 역할을 할 가능성이 있습니다.

결국 이 관점에서 AI 시대의 핵심 질문은 "AI가 코드를 얼마나 잘 작성할 수 있는가?"에 그치지 않습니다.

더 중요한 질문은 다음과 같습니다.

"코드를 언제든 다시 생성할 수 있는 시대에, 무엇을 정확하게 정의하고 보존해야 하는가?"

만약 그 답이 코드가 아니라 명세가 된다면 소프트웨어 개발의 중심도 달라질 수 있습니다.

코드를 작성하고 수정하는 일이 개발의 중심이었던 시대에서, 정확한 요구사항을 정의하고 이를 기계가 이해할 수 있는 형태로 표현하는 일이 소프트웨어 개발의 핵심이 되는 시대로 이동할 수 있습니다.

그리고 이러한 변화가 현실화되기 위한 가장 중요한 조건은 단순한 코드 생성 능력이 아니라, 모호하지 않은 명세와 이를 신뢰성 있게 실행 가능한 프로그램으로 변환할 수 있는 자동화 기술일 것입니다.

300x250

https://stng.substack.com/p/rewrite-all-the-code-all-the-time

Rewrite All the Code, All the Time