이런 분이 읽으면 좋습니다
요약: 소프트웨어 아키텍처는 60년간 메인프레임 → 클라이언트-서버 → 3-Tier → SOA → 마이크로서비스 → 서버리스 → AI 에이전트로 진화했다. 각 전환은 “이전 세대의 병목을 해결하면서 새로운 복잡성을 도입하는” 패턴의 반복이다. 이 글은 각 시대가 왜 등장했고, 무엇을 해결했고, 왜 다음 세대에 자리를 내줬는지를 트레이드오프 중심으로 정리한다. 역사를 모르면 유행에 휩쓸리고, 역사를 알면 제약 조건에 맞는 선택을 할 수 있다.
이 글은 아키텍처 선택의 근거를 이해하고 싶은 개발자를 위해 썼다. “왜 마이크로서비스가 등장했는가”를 모르면 “언제 마이크로서비스를 쓰면 안 되는가”도 판단할 수 없다.
시대별 아키텍처 한눈에 보기
| 시대 | 핵심 패턴 | 해결한 병목 | 만든 병목 | |
|---|---|---|---|---|
| 1960~70s | 메인프레임 + 터미널 | 계산 능력 공유 | 단일 장애점, 극도로 높은 비용 | |
| 1980~90s | 클라이언트-서버 | 분산 처리, UI 분리 | 클라이언트 배포·관리 복잡성 | |
| 1990~2000s | 3-Tier (웹) | 브라우저 = 범용 클라이언트 | 모놀리스 스케일링 한계 | |
| 2000~2010s | SOA + ESB | 서비스 재사용, 시스템 통합 | ESB 단일 장애점, 과도한 XML | |
| 2010s 중반 | 마이크로서비스 | 독립 배포·스케일링 | 분산 시스템 복잡성, 운영 오버헤드 | |
| 2010s 후반 | 서버리스 + FaaS | 인프라 관리 제거 | 콜드 스타트, 벤더 종속, 디버깅 난이도 | |
| 2020s~현재 | AI 에이전트 아키텍처 | 런타임 의사결정 자동화 | 예측 불가능성, 비용 제어, 안전성 |
1960~70s: 메인프레임 — 모든 것의 시작
무엇이었나
IBM System/360으로 대표되는 메인프레임 시대. 한 대의 거대한 컴퓨터에 수십~수백 대의 덤 터미널이 연결되는 구조. 모든 계산, 저장, 로직이 메인프레임 한 곳에서 처리됐다.
왜 이렇게 됐나
컴퓨터가 방 하나를 차지하고 수억 원이 하는 시대였다. “각자 컴퓨터를 갖는다”는 것이 물리적으로 불가능했다. 비싼 계산 자원을 여러 사용자가 시분할(time-sharing)로 공유하는 것이 유일한 선택이었다.
해결한 것
- 대규모 데이터 처리 (급여 계산, 재고 관리, 은행 거래)
- 중앙 집중 관리 — 보안·백업·업데이트를 한 곳에서 처리
만든 병목
- 단일 장애점 — 메인프레임이 죽으면 모든 것이 멈춘다
- 극도로 높은 비용 — 하드웨어·운영·전문 인력 모두 비쌌다
- 유연성 부재 — 새 기능을 추가하려면 메인프레임 팀의 대기열에서 기다려야 했다
1980~90s: 클라이언트-서버 — PC 혁명
무엇이었나
IBM PC와 Apple Macintosh의 등장. 개인용 컴퓨터가 보급되면서 “비싼 메인프레임 대신 저렴한 PC를 클라이언트로, 중간 규모 서버를 백엔드로” 쓰는 2-Tier 아키텍처가 등장했다.
왜 이렇게 됐나
하드웨어 비용이 급락했다. PC 한 대가 수백만 원이면 살 수 있게 되면서, 처리 능력을 클라이언트에 분산하는 것이 경제적으로 합리적이 됐다. 네트워크(LAN)의 보급이 이를 가능하게 했다.
해결한 것
- 비용 절감 — 메인프레임 대비 10분의 1 비용으로 유사한 처리 가능
- UI 향상 — 텍스트 터미널에서 GUI로 전환
- 분산 처리 — 클라이언트가 일부 로직을 처리하므로 서버 부담 감소
만든 병목
- 클라이언트 배포 지옥 — 새 버전을 500대 PC에 각각 설치해야 했다
- Fat Client 문제 — 비즈니스 로직이 클라이언트에 분산되면서 관리가 어려워졌다
- 데이터 일관성 — 오프라인에서 작업한 데이터의 동기화 문제
1990~2000s: 3-Tier와 웹 — 브라우저가 모든 것을 바꾸다
무엇이었나
웹 브라우저의 등장으로 “프레젠테이션 → 비즈니스 로직 → 데이터” 3계층 분리가 표준이 됐다. 클라이언트는 브라우저 하나면 충분했다. PHP, Java Servlet, ASP가 서버 사이드를 지배했고, Oracle과 SQL Server가 데이터 계층을 차지했다.
왜 이렇게 됐나
클라이언트 배포 문제의 완벽한 해결책이 나타났다. 브라우저만 있으면 어떤 PC에서든 최신 버전의 애플리케이션을 쓸 수 있었다. 인터넷의 상용화(1995년 Netscape IPO)가 촉매였다.
해결한 것
- 배포 문제 제거 — 서버만 업데이트하면 모든 사용자가 최신 버전
- 플랫폼 독립 — 윈도우, 맥, 리눅스 어디서든 동작
- 접근성 — 인터넷만 되면 어디서든 사용 가능
만든 병목
- 모놀리스 한계 — 트래픽이 늘면 서버 전체를 스케일업해야 했다
- 배포 단위 = 전체 — 작은 변경에도 애플리케이션 전체를 재배포
- 팀 간 충돌 — 하나의 코드베이스에 수십 명이 작업하면서 머지 지옥
2000~2010s: SOA — 서비스 지향 아키텍처
무엇이었나
비즈니스 기능을 독립적인 “서비스”로 분리하고, ESB(Enterprise Service Bus)를 통해 통신하는 구조. SOAP, XML, WSDL이 표준 프로토콜이었다. 대기업 IT의 지배적 패턴이었다.
왜 이렇게 됐나
기업이 커지면서 시스템 간 통합이 핵심 과제가 됐다. ERP, CRM, HR 시스템이 각각 독립적으로 존재하는데, 이들을 연결하고 데이터를 공유해야 했다.
해결한 것
- 시스템 통합 — 이질적인 시스템을 하나의 버스로 연결
- 서비스 재사용 — “고객 조회” 서비스를 여러 애플리케이션에서 공유
- 기술 이질성 허용 — Java 서비스와 .NET 서비스가 SOAP으로 통신
만든 병목
- ESB = 새로운 메인프레임 — 모든 통신이 ESB를 거치면서 단일 장애점이 됐다
- XML 오버헤드 — 메시지 포맷이 무겁고 파싱이 느렸다
- 거버넌스 오버헤드 — WSDL 관리, 스키마 버전 관리가 팀의 시간을 잡아먹었다
2010s 중반: 마이크로서비스 — 독립의 시대
무엇이었나
Netflix, Amazon, Uber가 선도한 패턴. 하나의 모놀리스를 수십~수백 개의 작은 서비스로 쪼개고, 각 서비스가 독립적으로 개발·배포·스케일링되는 구조. REST API와 JSON이 통신 표준, Docker가 배포 단위, Kubernetes가 오케스트레이션을 담당했다.
왜 이렇게 됐나
세 가지 트리거가 동시에 작용했다:
- 클라우드 보편화 — AWS(2006), GCP, Azure가 인프라를 API로 제공
- 컨테이너 기술 — Docker(2013)가 “어디서든 동일하게 실행”을 해결
- 조직 규모 — 넷플릭스·아마존 규모에서 모놀리스로는 팀 간 독립 배포 불가능
해결한 것
- 독립 배포 — 팀 A의 변경이 팀 B에 영향 없음
- 독립 스케일링 — 트래픽이 몰리는 서비스만 스케일아웃
- 기술 다양성 — 서비스별로 최적의 언어·DB 선택 가능
만든 병목
- 분산 시스템 복잡성 — 네트워크 지연, 부분 실패, 데이터 일관성 문제
- 운영 오버헤드 — 서비스 100개 = 모니터링 100개, 로깅 100개, 배포 파이프라인 100개
- 디버깅 난이도 — 요청이 서비스 5개를 거치면 어디서 문제가 생겼는지 추적이 어렵다
2010s 후반: 서버리스와 FaaS — “서버를 생각하지 마라”
무엇이었나
AWS Lambda(2014), Cloudflare Workers, Vercel Serverless Functions로 대표되는 패턴. 함수 단위로 코드를 배포하고, 요청이 올 때만 실행되며, 인프라 관리가 완전히 추상화됐다.
왜 이렇게 됐나
마이크로서비스의 운영 오버헤드가 문제였다. 서비스마다 서버를 프로비저닝하고 패치하고 모니터링하는 것이 작은 팀에게는 감당이 안 됐다. “코드만 올리면 알아서 실행되는” 모델의 수요가 폭발했다.
해결한 것
- 인프라 관리 제거 — 서버 프로비저닝, 패치, 스케일링 불필요
- 비용 효율 — 실행 시간만큼만 과금, 유휴 시 비용 0
- 자동 스케일링 — 요청 0에서 1만까지 자동 대응
만든 병목
- 콜드 스타트 — 유휴 상태에서 첫 요청 시 수 초의 지연
- 벤더 종속 — Lambda용 코드를 GCP Cloud Functions로 옮기기 어려움
- 디버깅·관측성 — 로컬 재현이 어렵고, 분산 트레이싱이 복잡
- 실행 시간 제한 — 장시간 실행 작업에 부적합
2020s~현재: AI 에이전트 아키텍처 — 코드가 스스로 판단하는 시대
무엇이었나
LLM(Large Language Model)을 런타임 의사결정 엔진으로 사용하는 아키텍처. 전통적인 아키텍처에서 “코드가 정해진 경로를 따라 실행”됐다면, AI 에이전트 아키텍처에서는 “에이전트가 상황을 판단하고 도구를 선택하고 워크플로우를 조합”한다.
왜 이렇게 됐나
2022년 ChatGPT 이후 LLM 성능이 실용 수준에 도달했고, 2024~2025년 도구 사용(function calling), RAG, MCP(Model Context Protocol) 같은 인터페이스가 표준화됐다.
해결하고 있는 것
- 비정형 입력 처리 — 자연어 요청을 구조화된 API 호출로 변환
- 런타임 워크플로우 조합 — 사전에 모든 경우의 수를 코딩할 필요 없음
- 자동화 영역 확장 — 이전에 사람만 할 수 있었던 판단·분류·생성 작업을 자동화
만들고 있는 병목
- 예측 불가능성 — 같은 입력에 다른 출력이 나올 수 있다
- 비용 제어 — 토큰 사용량이 워크로드에 따라 크게 변동
- 안전성 — 에이전트가 의도하지 않은 행동을 할 위험
- 관측성 — “에이전트가 왜 이 도구를 선택했는가”를 추적하기 어려움
AI 에이전트 아키텍처의 구성 요소 (2026년)
| 구성 요소 | 역할 | 예시 | |
|---|---|---|---|
| LLM | 추론 엔진 | Claude Opus 4.6, GPT-4.1, Gemini | |
| MCP 서버 | 도구·데이터 인터페이스 | DB 조회, API 호출, 파일 시스템 접근 | |
| 하네스 | 에이전트 런타임 제어 | CLAUDE.md, hooks, 워크플로우 정의 | |
| RAG | 외부 지식 주입 | 벡터 DB 검색, 문서 컨텍스트 | |
| 가드레일 | 안전 경계 설정 | 입출력 필터, 행동 제한, 비용 한도 | |
| 오케스트레이터 | 멀티 에이전트 조율 | Routines, 에이전트 체인, 병렬 실행 |
패턴의 패턴: 아키텍처 전환의 공통 법칙
60년간의 역사를 관통하는 패턴 4가지:
1. 병목 이동의 법칙
모든 아키텍처 전환은 한 곳의 병목을 해결하면서 다른 곳에 병목을 만든다. 메인프레임의 비용 병목 → 클라이언트-서버의 배포 병목 → 웹의 스케일링 병목 → 마이크로서비스의 운영 병목. 병목이 사라지는 것이 아니라 이동한다.
2. 추상화 상승의 법칙
시간이 지날수록 개발자가 관리하는 추상화 수준이 올라간다. 하드웨어 → OS → VM → 컨테이너 → 함수 → 에이전트. 각 단계에서 아래 계층의 복잡성이 숨겨진다.
3. 제약 조건 결정의 법칙
아키텍처를 결정하는 것은 기술의 “우수함”이 아니라 제약 조건이다. 하드웨어 비용, 네트워크 속도, 팀 규모, 배포 빈도, 규제 요구사항. 같은 시대에도 제약 조건이 다르면 다른 아키텍처가 최선이다.
4. 공존의 법칙
새 아키텍처가 등장해도 이전 세대가 사라지지 않는다. 2026년 현재: 메인프레임(은행), 모놀리스(스타트업), 마이크로서비스(대규모 플랫폼), 서버리스(이벤트 처리), AI 에이전트(자동화)가 모두 공존한다.
결론: 역사를 알면 유행에 휩쓸리지 않는다
기술 트렌드는 빠르게 바뀌지만, 아키텍처의 근본 원리는 60년간 동일했다:
- 단순함이 기본값이다 — 복잡성은 문제가 요구할 때만 추가한다
- 제약 조건이 아키텍처를 결정한다 — 유행이 아니라 팀 규모·트래픽·비용·규제가 답을 준다
- 병목은 이동한다 — 새 아키텍처가 모든 문제를 해결하지 않는다
- 공존이 정상이다 — “이것만 쓰면 된다”는 기술은 없다
다음에 누군가 “마이크로서비스로 전환해야 한다” 또는 “AI 에이전트 아키텍처를 도입해야 한다”고 말하면, 이렇게 물어보라: “지금 우리의 병목이 정확히 무엇이고, 이 전환이 그 병목을 해결하는가?” 이 질문에 구체적으로 답할 수 없다면, 전환은 시기상조다.
다음에 읽을 글
- 모듈러 모놀리스 vs 마이크로서비스: 2026 아키텍처 선택 가이드 — 가장 흔한 아키텍처 선택의 트레이드오프
- AI 시대 1인 개발자 SaaS 구축 전략 — 제약 조건이 극단적일 때의 아키텍처 판단
- 하네스 엔지니어링: 프롬프트에서 런타임 제어까지 — AI 에이전트 아키텍처의 실무 구현