지금까지의 개발 프레임워크는 컴퓨터보다 사람을 위해 존재했습니다. 문제는 앞으로도 그럴 필요가 있느냐는 것입니다.
1. 프레임워크는 원래 인간의 기억을 줄이기 위해 태어났다
개발 프레임워크를 생각하면 보통 생산성이 먼저 떠오릅니다. React, Django, Rails, Spring, Laravel, Next.js 같은 이름은 모두 “더 빨리 만들기 위한 도구”처럼 보입니다. 하지만 조금 더 깊게 보면 개발 프레임워크의 본질은 속도가 아니라 기억의 외주화입니다. 사람이 매번 같은 결정을 처음부터 다시 하지 않도록, 자주 쓰는 구조와 규칙과 컴포넌트를 미리 정리해 둔 것이 프레임워크입니다.
표준화된 폴더 구조, 라우팅 규칙, ORM, 인증 모듈, 빌드 설정, 배포 방식, preset, boilerplate, 공식 매뉴얼은 모두 인간 개발자의 인지 부하를 줄이는 장치였습니다. 개발자는 프레임워크를 통해 “이번 프로젝트에서는 파일을 어디에 둘까”, “상태 관리는 어떻게 할까”, “DB 연결은 어떤 방식으로 통일할까” 같은 질문을 매번 새로 풀지 않아도 됐습니다. 프레임워크는 인간이 실수하지 않도록 울타리를 만들고, 팀이 같은 언어로 말하도록 문법을 제공했습니다.
이 관점에서 보면 프레임워크의 종말이라는 말은 “도구가 사라진다”는 뜻이 아닙니다. 더 정확히는 인간을 위한 프레임워크가 새로 태어나야 할 이유가 줄어든다는 뜻입니다. 사람이 직접 코드를 읽고, 외우고, 수정하고, 협업하는 시간이 줄어들수록 사람 친화적인 설계 규칙의 가치는 이전과 달라질 수밖에 없습니다.
| 프레임워크 요소 | 인간에게 해준 일 | 왜 필요했나 |
|---|---|---|
| 표준 폴더 구조 | 어디에 무엇을 둘지 결정 비용을 줄임 | 팀원이 코드를 빠르게 찾기 위해 |
| preset과 boilerplate | 반복 설정을 복사 가능한 형태로 제공 | 초기 세팅 실수를 줄이기 위해 |
| 컴포넌트와 라이브러리 | 자주 쓰는 UI와 로직을 재사용 | 사람이 매번 새로 구현하지 않기 위해 |
| 공식 매뉴얼 | 학습 경로와 권장 방식을 문서화 | 사람이 따라야 할 기준이 필요했기 때문 |
| 커뮤니티 패턴 | 문제 해결 경험을 축적 | 사람마다 다른 시행착오를 줄이기 위해 |
프레임워크는 결국 “사람이 혼자 기억하기 어려운 결정을 사회적으로 저장한 장치”였습니다. 그래서 유명한 프레임워크일수록 코드보다 문서가 중요했고, 기능보다 관습이 중요했습니다. 좋은 프레임워크는 단순히 코드를 덜 쓰게 만드는 도구가 아니라, 사람이 덜 헷갈리게 만드는 사회적 계약에 가까웠습니다.
2. Brooks가 말한 복잡성은 프레임워크의 존재 이유를 설명한다
Fred Brooks의 《The Mythical Man-Month》가 지금도 자주 언급되는 이유가 여기에 있습니다. 이 책은 대형 소프트웨어 프로젝트가 왜 단순한 인력 투입으로 해결되지 않는지 설명한 고전입니다. Brooks는 특히 No Silver Bullet에서 소프트웨어의 어려움을 본질적 복잡성과 우발적 복잡성으로 나누었습니다.
본질적 복잡성은 문제 자체에서 오는 어려움입니다. 결제 시스템이라면 돈, 권한, 환불, 정산, 보안, 예외 상황이 얽힙니다. 병원 시스템이라면 환자, 처방, 기록, 책임, 규제가 얽힙니다. 이것은 도구가 좋아져도 사라지지 않습니다. 반면 우발적 복잡성은 도구와 환경 때문에 생기는 어려움입니다. 어색한 언어, 불편한 빌드, 느린 컴파일, 반복 설정, 부족한 문서, 팀 간 커뮤니케이션 비용 같은 것입니다.
개발 프레임워크는 바로 이 우발적 복잡성을 줄이기 위해 성장했습니다. 사람이 비즈니스 문제를 이해하는 데 써야 할 에너지를, 라우팅 설정이나 DB 연결이나 화면 렌더링 규칙에 낭비하지 않게 만든 것입니다. 그래서 프레임워크는 사람을 돕는 도구였고, 그 도움의 핵심은 “생각해야 할 것을 줄여주는 것”이었습니다.
Brooks의 관점에서 보면 프레임워크는 은총의 은탄환이 아니라, 우발적 복잡성을 꾸준히 낮추는 청소 도구에 가깝습니다. 마법처럼 소프트웨어의 본질을 없애지는 못하지만, 사람이 본질에 더 오래 머물 수 있게 해줍니다.
이 말은 프레임워크가 하찮다는 뜻이 아닙니다. 오히려 반대입니다. 지금까지 프레임워크가 중요했던 이유는 인간 개발자가 소프트웨어라는 너무 복잡한 구조물을 다루기 위해 보조 기억장치가 필요했기 때문입니다. 표준화는 기억을 줄였고, 매뉴얼은 학습을 줄였고, 컴포넌트는 반복을 줄였고, preset은 실수를 줄였습니다.
3. Design Patterns는 사람을 위한 공동 언어였다
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides의 《Design Patterns: Elements of Reusable Object-Oriented Software》도 같은 맥락에서 읽을 수 있습니다. 이 책은 23개의 객체지향 설계 패턴을 정리한 책으로, 소프트웨어 공학에서 매우 큰 영향을 남겼습니다. 중요한 점은 이 책이 단순히 “좋은 코드 예제 모음”이 아니었다는 것입니다. 이 책은 개발자들이 복잡한 설계를 같은 이름으로 부르게 만든 사전이었습니다.
예를 들어 Singleton, Factory, Observer, Adapter 같은 이름은 코드 자체보다 사람 사이의 대화에서 더 큰 힘을 발휘했습니다. “여기는 Observer로 풀자”, “이건 Adapter가 필요하다”, “Factory로 분리하자”라는 말은 수십 줄의 설명을 몇 단어로 압축했습니다. 이것은 기계가 아니라 사람을 위한 압축이었습니다.
프레임워크도 마찬가지입니다. Next.js의 App Router, Rails의 Convention over Configuration, Spring의 Dependency Injection, Django의 batteries included 같은 표현은 모두 사람이 구조를 빨리 이해하기 위한 언어입니다. 개발 프레임워크는 코드 실행 장치이기 이전에 조직의 의사소통 장치였습니다.
| 인간 협업 문제 | 디자인 패턴과 프레임워크가 준 해법 | AI 시대의 변화 가능성 |
|---|---|---|
| 설계 의도를 설명하기 어렵다 | 패턴 이름으로 의도를 압축 | AI는 이름보다 대량 사례의 통계적 유사성을 더 잘 활용 |
| 팀원이 구조를 빨리 배워야 한다 | 매뉴얼과 관습을 제공 | 사람이 덜 읽으면 매뉴얼의 가치가 낮아짐 |
| 반복 설계를 피하고 싶다 | 컴포넌트와 추상화를 제공 | AI는 반복 구현 자체를 거의 비용 없이 생성 가능 |
| 코드 리뷰에서 기준이 필요하다 | 표준 구조와 모범 사례 제공 | 하네스와 테스트가 기준 역할을 더 많이 맡을 수 있음 |
그래서 인간을 위한 프레임워크는 본질적으로 “기억과 합의를 절약하는 기술”이었습니다. 컴퓨터가 프레임워크를 필요로 한 것이 아니라, 사람이 프레임워크를 필요로 했습니다. 컴퓨터는 Rails인지 Django인지 Next.js인지에 관심이 없습니다. 결국 CPU가 보는 것은 실행 가능한 명령이고, 런타임이 보는 것은 주어진 규칙에 맞는 상태 변화입니다.
4. 대중적인 기술은 AI에게도 더 쉬운 지형이 된다
그렇다면 AI 코딩 시대에는 모든 프레임워크가 곧바로 무의미해질까요. 그렇지는 않습니다. 현재의 AI는 여전히 인간이 남긴 코드, 문서, 오픈소스, 질문과 답변, 예제, 공식 매뉴얼 위에서 움직입니다. 따라서 대중적으로 많이 쓰인 언어와 프레임워크는 AI에게도 더 잘 아는 지형이 됩니다.
GitHub Octoverse 2024는 Python이 GitHub에서 가장 많이 쓰인 언어로 올라섰고, 생성형 AI 프로젝트와 데이터 과학 활동이 크게 늘었다고 설명합니다. Stack Overflow Developer Survey 2024도 개발자들이 API와 SDK 문서를 강하게 의존하고, Docker, npm, PostgreSQL 같은 익숙한 도구가 널리 쓰인다는 사실을 보여줍니다. 이 데이터는 한 가지를 말합니다. 인간 개발 생태계의 표준은 곧 AI가 가장 많이 학습한 표준이 됩니다.
여기서 재미있는 역설이 생깁니다. 인간을 위한 프레임워크는 사라질지 몰라도, 인간이 가장 많이 쓴 프레임워크의 흔적은 AI에게 가장 안전한 레시피가 됩니다. React, Python, PostgreSQL, Docker, REST, OAuth, HTML, SQL처럼 널리 퍼진 기술은 AI가 예측하기 쉽습니다. 반대로 회사 내부에서만 쓰는 독자 DSL, 사내 전용 프레임워크, 문서가 부족한 추상화는 AI에게 낯선 지형입니다. 이 변화는 소프트웨어 3.0 논의와도 이어집니다.
AI 코딩 시대의 위험은 “프레임워크를 쓰느냐 마느냐”가 아니라, AI가 충분히 배운 지형 위에 있는지입니다. 사람에게 익숙한 도구가 아니라 모델에게 익숙한 도구가 더 낮은 오류율을 만들 가능성이 큽니다.
1부의 결론은 여기까지입니다. 과거의 개발 프레임워크는 철저히 사람을 위한 장치였습니다. 표준화, preset, 쉬운 컴포넌트, 매뉴얼, 디자인 패턴은 모두 인간의 생산성과 협업을 위해 존재했습니다. 그러나 개발이라는 행위에서 인간의 비중이 줄어들수록, 사람을 편하게 하기 위한 새로운 프레임워크가 계속 태어날 이유도 줄어듭니다.
2부에서 계속됩니다. AI가 가장 잘 쓰는 기술 조합, 코딩 이후의 바이너리 자산, 그리고 인간을 위한 프레임워크 이후에 등장할 AI 프레임워크의 가능성을 이어서 다룹니다.
댓글 없음:
댓글 쓰기