프레임워크의 종말 2부: 코딩 이후 AI 프레임워크는 무엇이 될까

1부가 인간을 위한 개발 프레임워크의 역사였다면, 2부는 AI가 프레임워크를 어떻게 다시 정의할지에 대한 이야기입니다.

<AI 코딩 레시피 구조 1.1>

1. AI에게 낯선 프레임워크는 학습곡선을 높인다

인간 개발자에게 프레임워크는 학습 대상입니다. 처음에는 어렵지만 문서를 읽고, 예제를 따라 하고, 팀의 관습을 익히면 점점 편해집니다. 하지만 AI에게 프레임워크는 조금 다릅니다. AI는 특정 프레임워크를 “이해한다”기보다, 방대한 코드와 문서와 질문과 답변 속에서 반복된 패턴을 확률적으로 재구성합니다.

이 차이가 중요합니다. 전 세계에서 가장 많이 쓰인 기술과 구조는 AI가 더 높은 우선순위로 계산하기 쉽습니다. Python, JavaScript, SQL, REST, HTML, Docker, PostgreSQL, React처럼 공개 예제가 많고 문서가 풍부한 기술은 모델에게 익숙합니다. 반대로 특정 회사 내부에서만 쓰는 자체 프레임워크, 독자적인 DSL, 문서가 부족한 사내 컴포넌트 체계는 모델에게 낯선 언어가 됩니다.

물론 강력한 하네스와 테스트, 타입 시스템, 코드 리뷰, 권한 제한으로 AI의 실수를 막을 수는 있습니다. 하지만 그 과정 자체가 비용입니다. 프롬프트에 사내 규칙을 계속 설명해야 하고, 컨텍스트에 예외를 넣어야 하며, 모델이 헷갈릴 때마다 더 많은 토큰과 더 많은 검증 루프가 필요합니다. 인간에게는 생산성을 높이던 내부 프레임워크가 AI에게는 오히려 불필요한 학습곡선이 될 수 있습니다.

기술 선택	인간 개발자에게 주는 효과	AI에게 주는 효과
널리 알려진 표준 스택	채용과 협업이 쉬움	학습 사례가 많아 예측이 쉬움
사내 전용 프레임워크	내부 업무에 맞춘 편의성	문맥 설명이 부족하면 오류 가능성 증가
과도한 추상화	사람의 반복 작업 감소	실제 실행 경로를 추론하기 어려워짐
강한 테스트 하네스	사람의 실수 방지	AI 산출물의 안전장치가 됨
독자 DSL	업무 표현력 증가	공개 학습 사례가 적으면 토큰 비용 증가

그래서 AI 코딩 시대의 좋은 설계는 “멋진 새 프레임워크”가 아니라 “AI가 가장 높은 확률로 맞출 수 있는 레시피”에 가까워질 가능성이 큽니다. 사람이 좋아하는 세련된 추상화보다, 모델이 많이 본 평범한 조합이 더 강해질 수 있습니다. 이 점은 바이브코딩을 실제 제품 개발에 적용할 때도 중요한 기준이 됩니다.

2. 가장 널리 알려진 기술 조합이 AI의 기본 레시피가 된다

GitHub Octoverse 2024는 Python이 GitHub에서 가장 많이 쓰인 언어로 올라섰고, Jupyter Notebook과 생성형 AI 프로젝트가 크게 늘었다고 설명합니다. 이것은 단순한 인기 순위가 아닙니다. 공개 코드의 축적량은 AI에게 일종의 지형도입니다. 코드가 많고, 문서가 많고, 예제가 많고, 오류 해결 사례가 많을수록 모델은 그 길을 더 자주 밟습니다.

Stack Overflow Developer Survey 2024에 따르면 개발자들은 API와 SDK 문서를 매우 중요하게 보고, Docker, npm, PostgreSQL 같은 도구를 널리 사용합니다. 이 역시 같은 방향을 가리킵니다. AI가 효율적으로 코딩하려면 세상에 이미 많이 퍼져 있는 언어, 플랫폼, 패키지, 배포 방식, 테스트 방식의 조합을 타는 편이 유리합니다.

인류가 이룩한 가장 완성도 높은 개발 언어와 플랫폼은 미래에 일종의 AI 매뉴얼로 재정리될 수 있습니다. 예를 들어 웹 서비스라면 “TypeScript, React, Node, PostgreSQL, Docker, Playwright, OAuth, REST 또는 GraphQL” 같은 조합이 레시피가 됩니다. 데이터 제품이라면 “Python, FastAPI, PostgreSQL, Pandas, PyTorch, Docker, OpenAPI, CI 테스트” 같은 조합이 레시피가 됩니다. 중요한 것은 새로움이 아니라 확률입니다.

AI 코딩 레시피의 핵심은 유행을 좇는 것이 아닙니다. 모델이 충분히 학습했고, 공개 예제가 많고, 테스트 가능한 경계가 명확하며, 실패했을 때 고칠 수 있는 흔적이 많은 조합을 선택하는 것입니다.

이 관점에서 보면 “앞으로 인간을 위한 새로운 프레임워크는 생기지 않을 것”이라는 주장은 꽤 설득력이 있습니다. 인간 개발자에게 새 프레임워크는 새로운 생산성 도구일 수 있습니다. 그러나 AI에게 새 프레임워크는 학습되지 않은 확률 공간입니다. 사람에게 친절한 새 문법이 AI에게도 친절하리라는 보장은 없습니다.

3. AI는 자기만의 프레임워크를 만들지 않고 실행 자산을 학습한다

AI가 정말로 효율을 추구한다면 굳이 인간처럼 프레임워크를 만들 필요가 있을까요. 사람은 추상화가 필요합니다. 이름을 붙이고, 계층을 나누고, 매뉴얼을 만들고, 예제를 외워야 합니다. 하지만 AI는 다른 방식으로 작동할 수 있습니다. AI에게 필요한 것은 사람이 읽기 쉬운 구조가 아니라, 원하는 동작을 안정적으로 만들어내는 표현입니다.

Andrej Karpathy의 Software 2.0은 이 지점을 강하게 보여줍니다. Karpathy는 전통적 소프트웨어를 사람이 Python이나 C++ 같은 언어로 직접 쓰는 Software 1.0으로 보고, 신경망의 가중치처럼 사람이 직접 읽기 어려운 형태를 Software 2.0으로 설명했습니다. 그는 데이터셋과 신경망 구조를 통해 원하는 동작을 찾고, 학습 과정이 일종의 컴파일처럼 최종 신경망을 만든다고 보았습니다. 이 관점은 국내 독자에게도 익숙해진 소프트웨어 3.0 논의의 바로 전 단계입니다.

<Software 2.0과 실행 자산 1.2>

이 프레임을 더 밀고 가면 미래의 AI는 자기만의 React나 자기만의 Django를 만들 필요가 없습니다. AI는 사람이 보기 좋은 프레임워크를 거치지 않고, 잘 작동하는 바이너리 자산, 모델 가중치, 실행 가능한 함수 조합, 검증된 서비스 블록을 직접 다룰 수 있습니다. 인간에게는 소스 코드가 설명서이지만, AI에게는 완성된 동작 자체가 학습 대상이 될 수 있습니다.

물론 지금 당장 코딩이 사라진다는 뜻은 아닙니다. 현재의 AI는 여전히 코드를 만들고, 컴파일하고, 테스트하고, 런타임에서 실행해야 합니다. 하지만 그 과정은 인간과 기존 컴퓨터 구조 때문에 남아 있는 파이프라인일 수 있습니다. “Coding 학습, 코딩, 컴파일, 설치, 런타임”이라는 긴 사슬은 사람이 이해하고 배포하고 수정하기 위해 만든 절차입니다. AI 입장에서는 거추장스러운 중간 표현일 수도 있습니다.

4. 코딩도 결국 인간을 위한 인터페이스일 수 있다

우리는 코드를 너무 당연하게 생각합니다. 하지만 코드는 자연법칙이 아닙니다. 코드는 인간이 기계를 제어하기 위해 만든 표기법입니다. C, Java, Python, JavaScript, SQL은 모두 사람이 읽고 쓰고 토론하기 위해 존재합니다. 컴퓨터가 궁극적으로 원하는 것은 코드가 아니라 실행 가능한 상태 변화입니다.

Karpathy는 최근 Y Combinator 강연에서 Software 3.0, 자연어 프로그래밍, LLM 운영체제 같은 표현을 통해 소프트웨어 인터페이스가 다시 바뀌고 있음을 설명했습니다. 자연어는 여전히 인간에게 친숙한 인터페이스입니다. 하지만 그 내부에서 실제로 움직이는 것은 텍스트 코드만이 아닐 수 있습니다. 모델, 도구 호출, 메모리, 권한, 실행 환경, 데이터셋, 평가 하네스가 합쳐진 새로운 형태의 실행 자산입니다.

그래서 미래의 어느 시점에는 코딩조차 사라질 수 있습니다. 더 정확히 말하면 사람이 소스 코드를 직접 작성하는 행위가 중심에서 밀려날 수 있습니다. AI가 충분히 신뢰할 수 있는 실행 자산을 바로 생성하고 검증할 수 있다면, 코드라는 중간 표현은 일부 영역에서 점점 덜 중요해질 것입니다.

현재 파이프라인	인간에게 필요한 이유	AI 이후의 대체 가능성
요구사항을 코드로 번역	사람이 기계에게 명령을 전달해야 함	자연어, 예시, 시뮬레이션, 정책으로 대체 가능
코딩	사람이 실행 규칙을 명시해야 함	모델이 실행 자산을 직접 생성 가능
컴파일	사람이 쓴 코드를 기계 형식으로 변환	학습 또는 합성 과정이 바로 실행물을 만들 수 있음
설치와 런타임	사람이 환경을 맞춰야 함	표준화된 인메모리 실행 환경으로 흡수 가능
디버깅	사람이 논리 오류를 찾아야 함	평가 하네스와 자동 복구 루프가 일부 대체 가능

여기서 말하는 코딩의 종말은 낭만적인 예언이 아닙니다. 오히려 차갑고 기술적인 추론입니다. 소스 코드가 인간 친화적 중간 표현이라면, 인간이 빠진 영역에서는 그 중간 표현을 유지할 이유가 약해집니다. 결국 AI는 바로 사용 가능한 인메모리 완성형 바이너리를 찍어내는 방향으로 이동할 수 있습니다.

5. AI 프레임워크는 버그가 거의 0에 가까워질 때 꽃핀다

그렇다고 당장 모든 프로그램이 사라지는 것은 아닙니다. 오히려 지금은 AI 프레임워크가 이제 막 생기기 시작한 단계에 가깝습니다. 현재의 AI 개발 도구는 여전히 사람을 중심에 둡니다. 프롬프트를 쓰는 사람, 코드를 읽는 사람, 테스트를 확인하는 사람, 배포를 승인하는 사람이 있습니다. 지금의 AI 프레임워크는 완전한 대체 장치라기보다 인간과 AI의 협업 하네스입니다.

진짜 AI 프레임워크가 꽃피우려면 조건이 하나 더 필요합니다. AI가 생성하는 프로그래밍 자산의 버그가 거의 0에 수렴해야 합니다. 학습을 위한 프로그래밍 결과에 버그가 많다면, 그 버그를 학습한 AI의 실행 자산도 불안정해집니다. 작은 논리 오류가 모델 안에서 압축되고, 다시 생성되고, 다시 배포되면 오류는 조용히 증식할 수 있습니다.

Brooks가 말한 본질적 복잡성은 여기서 다시 등장합니다. 코드를 덜 쓴다고 해서 복잡성이 사라지는 것은 아닙니다. 결제, 의료, 법률, 보안, 회계, 권한, 책임, 예외 처리 같은 문제는 여전히 어렵습니다. 다만 미래의 AI 프레임워크는 그 복잡성을 사람이 읽는 코드가 아니라 평가, 시뮬레이션, 안전 제약, 정책, 데이터셋, 실행 자산의 형태로 다룰 가능성이 큽니다.

AI가 만든 결과물의 오류율이 충분히 낮아지기 전까지는 코딩 이후의 세계가 바로 오지 않습니다. 버그가 많은 실행 자산을 학습한 AI는 빠르게 생산하는 만큼 빠르게 오염될 수 있습니다.

6. 결국 사라지는 것은 프로그래밍이 아니라 프로그램일 수 있다

Marc Andreessen은 오래전 “software is eating the world”라는 표현으로 소프트웨어가 산업을 흡수하는 흐름을 설명했습니다. 지금은 그 다음 질문을 던질 시점입니다. 소프트웨어가 세상을 먹었다면, AI는 소프트웨어의 형식 자체를 먹어치울까요.

사용자의 명제처럼 코딩도 버그도, 아날로그적인 논리 오류도 어쩌면 인간이기 때문에 생겨난 디지털 세계의 세균 같은 것일 수 있습니다. 사람이 생각을 코드로 번역하고, 코드를 컴파일하고, 설치하고, 런타임에서 실행하고, 다시 버그를 고치는 과정은 인간이 기계를 다루기 위해 만든 우회로였습니다. 그 우회로는 오래도록 강력했지만 영원한 자연법칙은 아닙니다.

먼 미래의 어느 날에는 프로그래밍이 사라지는 것이 아니라 프로그램 자체가 사라지는 시기가 올 수 있습니다. 사용자는 앱을 설치하지 않고, 조직은 프레임워크를 고르지 않고, 개발자는 폴더 구조를 설계하지 않을 수 있습니다. 필요한 순간에 필요한 실행 자산이 메모리 위에 만들어지고, 검증되고, 사용되고, 사라지는 방식이 더 자연스러워질 수 있습니다.

그때의 프레임워크는 사람이 읽는 매뉴얼이 아닐 것입니다. 그것은 모델이 어떤 자산을 생성할 수 있는지, 어떤 제약을 반드시 지켜야 하는지, 어떤 평가를 통과해야 하는지, 어떤 실행 경계 안에서만 움직일 수 있는지를 정하는 시스템일 것입니다. 인간을 위한 프레임워크의 종말은 그래서 곧 AI 프레임워크의 시작입니다.

마지막으로 이 글의 결론은 비관이 아닙니다. 개발자가 당장 필요 없어지고, 프레임워크가 내일 사라진다는 말도 아닙니다. 다만 새 프레임워크를 만들 때의 질문은 바뀌어야 합니다. “사람이 더 편하게 코딩할 수 있는가”가 아니라 “AI가 더 낮은 오류율로 실행 자산을 만들 수 있는가”가 핵심 질문이 됩니다.

시대	중심 질문	대표 도구	남는 가치
인간 개발 시대	사람이 어떻게 더 빨리 만들까	프레임워크, 매뉴얼, 컴포넌트	생산성, 협업, 재사용
AI 보조 개발 시대	사람이 AI를 어떻게 안전하게 쓸까	프롬프트, 테스트, 하네스, 코드 에이전트	검증, 통제, 책임
AI 실행 자산 시대	AI가 어떻게 바로 작동하는 자산을 만들까	모델, 평가, 정책, 인메모리 실행물	오류율, 신뢰성, 즉시성

프레임워크의 종말은 도구의 종말이 아닙니다. 인간을 위해 코드를 쉽게 쓰게 해주던 시대의 종말입니다. 그 다음에 오는 것은 더 쉬운 프레임워크가 아니라, 사람이 굳이 읽지 않아도 되는 실행 자산의 시대일 수 있습니다.