코딩 에이전트로 인해 소프트웨어 생성 비용이 낮아지면서, 유지보수 대신 생성·사용·폐기를 전제로 한 ‘일회용 소프트웨어’가 부상하고 있다. 이에 맞는 아키텍처로 내구적인 코어, 불변 계약(API), 그리고 폐기 가능한 주변 레이어를 제안한다.
URL: https://tuananh.net/2026/01/15/architecture-for-disposable-systems/
Title: Architecture for Disposable Systems
코딩 에이전트 덕분에 소프트웨어를 만드는 비용이 더 저렴해지고, 품질에 대한 기대치도 변하면서 우리는 **일회용 소프트웨어(disposable software)**의 부상을 목격하고 있다. 이는 코드를 무기한 유지보수하는 대신, 생성해서 사용한 뒤 버리는 소프트웨어다.
전통적인 소프트웨어는 확립된 패턴을 따른다. 한 번 만들고, 무기한 유지보수하며, 높은 초기 자본과 장기 유지보수 비용으로 그 값을 치른다. 다시 쓰는 일이 비쌌기 때문에 이런 경제성은 합리적이었다. 우리는 프로젝트 생애주기의 80%를 유지보수에 쓰는 것을 받아들였다. 대안(처음부터 다시 시작하기)은 종종 감당하기 어려웠기 때문이다(제품이 EOL에 도달하기 전까지).
이로 인해 신중한 엔지니어링 문화가 만들어졌다. 깔끔한 코드, 사려 깊은 아키텍처, 그리고 기술 부채를 줄이기 위한 리팩터링. 장기적으로 최적화했다. 장기는 불가피했기 때문이다. 우리는 그 결과와 함께 살아야 했다.
그런데 프롬프트 하나로 에이전트가 5분 만에 기능하는 대체품을 재생성할 수 있다면 무슨 일이 일어날까? “기술 부채를 정리하자”거나 “장기적으로 리팩터링하자”는 유인은 사라진다. 코드가 지금 작동하고, 나중에 다시 생성할 수 있다면, 왜 완벽함에 투자해야 할까?
우리는 이미 **“바이브 코딩(vibe coding)”**의 부상을 보고 있다. 지금 당장 문제를 해결하는 도구를 만드는 것이다. 특정 데이터 파서가 필요한가? 생성하라. 회의를 위한 일회성 대시보드가 필요한가? 생성하라. 사용하고, 망가지거나 구식이 되면 삭제하고 새로 생성하라. 출력이 정확하기만 하면 코드가 “깔끔한지”는 신경 쓰지 않는다.
이건 게으름이 아니다. 소프트웨어 개발의 경제성이 근본적으로 바뀌고 있다는 뜻이다. 생성이 싸지면, 유지보수가 비싼 선택지가 된다.
일회용 소프트웨어로 이동하고 있다면, 이 변화 속에서도 살아남을 수 있는 시스템은 어떻게 설계해야 할까? 답은 3계층 모델에 있다.
진실의 원천(Source of Truth). 사람 손으로 작성되고, 단단하게 다져져 있으며, 변화가 느린 시스템의 기반이다. 핵심 비즈니스 로직, 데이터 모델, 핵심 알고리즘을 담는다. 이 계층은 시스템의 근본 가치를 나타내므로 오래가도록 만든다.
불변 계약(immutable contracts). 구성 요소들이 어떻게 통신하는지 정의하는 인터페이스다. 일회용 부분이 불완전해도 되기 때문에, 이 계약은 완벽해야 한다. API 계약이 견고하다면, 그 아래 구현을 교체해도 시스템을 깨뜨리지 않고 바꿀 수 있다.
AI가 생성한 “글루(glue)” 코드, 데이터 파서, UI 컴포넌트, 통합 스크립트가 여기에 해당한다. 바이브 코딩이 일어나는 곳이다. 생성하고, 사용하고, 필요하면 다시 생성한다. 커넥터 계층이 정의한 계약을 준수하기만 한다면, 내부가 얼마나 지저분한지는 중요하지 않다.
이 모델을 작동시키는 핵심은 **계약 우선 설계(contract-first design)**다. 구현에 맞춰 코딩하는 대신, 엄격한 스키마에 맞춰 코딩해야 한다. OpenAPI, gRPC, Smithy 등 도메인에 맞는 어떤 표준이든 된다. 에이전트는 제약 조건으로서 스키마를 제공받고, 입력과 출력이 계약과 일치하기만 하면 박스 안의 로직이 얼마나 난잡한지는 신경 쓰지 않는다.
핵심 원칙: 불변 계약. 일회용 부분이 불완전할 수 있도록, 계약은 완벽해야 한다.
이 접근은 다음을 가능하게 한다:
아직 완전히 그 지점에 도달한 것은 아니지만, 흐름은 분명하다. 코딩 에이전트가 개선되고 생성 비용이 떨어질수록, 더 많은 소프트웨어가 일회용이 될 것이다. 살아남는 시스템은 내구적인 코어, 불변 계약, 그리고 폐기 가능한 주변부로 만들어진 시스템일 것이다.
문제는 이 전환이 일어나느냐가 아니다. 당신의 아키텍처가 그 전환을 맞이할 준비가 되었느냐이다.
