Monolithic Application은 하나의 응집된 단일 단위로 설계되며, 사용자 인터페이스, 비즈니스 로직, 데이터 액세스 같은 모든 컴포넌트가 긴밀하게 통합되어 하나의 서비스로 실행된다.

이러한 아키텍처는 전체 애플리케이션이 함께 관리되고 배포되기 때문에 개발과 배포가 단순해진다. 그러나 애플리케이션이 커질수록 확장성, 유지보수성, 민첩성 측면에서 문제가 발생할 수 있다. 애플리케이션의 한 부분을 변경하려면 전체 시스템을 다시 배포해야 하고, 확장을 위해서는 개별 컴포넌트만 확장하는 것이 아니라 전체 애플리케이션을 복제해야 할 수도 있다.

따라서 모놀리식 아키텍처는 작은 규모의 애플리케이션이나 복잡성이 낮은 프로젝트에는 적합할 수 있지만, 많은 조직들이 확장 단계에서 이러한 한계를 극복하기 위해 마이크로서비스나 모듈형 아키텍처로 전환한다.

정리: 모놀리식 아키텍처는 단일 서비스로 단순하지만, 확장성과 유연성이 떨어진다.

---

• 비즈니스 로직: 애플리케이션에서 핵심 규칙과 처리 절차를 담는 부분으로, 입력 데이터를 기반으로 원하는 결과를 만들어내는 실제 업무 규칙을 구현한다.
• 마이크로서비스 아키텍처: 애플리케이션을 작은 독립 서비스 단위로 나누어 각각 독립적으로 개발, 배포, 확장할 수 있는 아키텍처. 서비스 간은 주로 API를 통해 통신한다.
• 모듈형 아키텍처: 애플리케이션을 기능별 모듈로 나누어 개발하는 방식으로, 모듈은 서로 독립적이면서도 전체 시스템과 유기적으로 동작한다. 마이크로서비스보다 결합도가 높지만 모놀리식보다는 유연하다.

Microservices는 애플리케이션을 느슨하게 결합된 독립적으로 배포 가능한 서비스들의 집합으로 구성하는 아키텍처 스타일이다. 각 마이크로서비스는 특정한 비즈니스 기능에 집중하며, 일반적으로 HTTP나 메시징 큐 같은 경량 프로토콜을 통해 다른 서비스와 통신한다.

이 방식은 서비스들이 독립적으로 개발, 배포, 확장될 수 있기 때문에 확장성, 유연성, 탄력성을 높여준다. 또한 컴포넌트별로 다양한 기술과 언어를 사용할 수 있으며, 지속적 전달(Continuous Delivery)과 배포를 지원한다. 그러나 마이크로서비스를 관리할 때는 서비스 간 통신, 데이터 일관성, 배포 오케스트레이션 같은 복잡성이 따른다.

정리: 마이크로서비스는 독립 서비스들의 집합으로 확장성과 유연성은 높지만, 관리 복잡성이 크다.

---

• 메시징 큐(Messaging Queue): 애플리케이션 컴포넌트 간에 메시지를 비동기적으로 전달하는 시스템으로, 생산자(Producer)가 보낸 메시지를 큐에 저장하고 소비자(Consumer)가 이를 꺼내 처리한다.
• 예: RabbitMQ, Kafka
• 경량 프로토콜(Lightweight Protocol): 데이터 교환 시 불필요한 오버헤드를 최소화한 단순하고 효율적인 통신 규약.
• 예: HTTP/REST, gRPC
• 지속적 전달(Continuous Delivery, CD): 애플리케이션을 언제든 안정적으로 배포할 수 있도록 자동화된 테스트와 빌드를 거쳐 릴리스 후보를 지속적으로 제공하는 소프트웨어 개발 방식.
• 배포 오케스트레이션(Deployment Orchestration): 여러 서비스나 컨테이너를 자동으로 배포·관리·스케일링하는 프로세스로, 의존성과 순서를 고려해 전체 시스템을 조율한다.
• 예: Kubernetes

서비스 지향 아키텍처는 소프트웨어 컴포넌트(서비스라 불림)를 재사용 가능하고 느슨하게 결합되며 네트워크를 통해 상호작용하도록 설계하는 아키텍처 패턴이다. 각 서비스는 특정 비즈니스 기능을 수행하는 자급자족형 단위(self-contained unit)이며, HTTP와 XML 같은 표준화된 프로토콜과 데이터 포맷을 통해 다른 서비스와 통신한다.

SOA는 서비스가 독립적으로 개발, 배포, 유지될 수 있게 하여 조직이 확장 가능하고, 유연하며, 상호운용성 있는 시스템을 구축하도록 돕는다. 이 접근법은 모듈화, 이질적인 시스템 간의 손쉬운 통합, 변화하는 비즈니스 요구에 대한 민첩성을 촉진한다.

정리: SOA는 표준 프로토콜을 통해 느슨하게 결합된 재사용 가능한 서비스들의 아키텍처다.

---

• 자급자족형 단위(Self-contained unit): 외부에 크게 의존하지 않고, 자체적으로 실행·관리 가능한 독립적인 컴포넌트를 의미한다. 예를 들어, 하나의 서비스가 자신의 데이터 저장, 로직, 인터페이스를 모두 갖추고 있어서 단독으로 동작할 수 있는 형태.
• 데이터 포맷(Data format): 데이터를 저장하거나 교환하기 위해 구조화한 표현 방식이다. 시스템 간 통신에서 공통 규칙을 정해주며, 대표적으로 JSON, XML, CSV 같은 형식이 있다.

서버리스 컴퓨팅(Serverless Computing)은 개발자가 서버 인프라를 관리하지 않고 애플리케이션을 구축하고 실행할 수 있는 클라우드 컴퓨팅 모델이다. 이 모델에서 서버 관리, 확장, 유지보수 작업은 클라우드 제공자가 담당한다.

개발자는 코드를 함수(Function) 형태로 배포하며, 이는 이벤트나 트리거에 반응해 실행된다. 또한 예약된 용량이 아니라 실제 사용량에 따라 비용이 청구된다. 이 접근 방식은 인프라 관리 문제를 추상화하여 개발을 단순화하고, 자동 확장을 가능하게 하며, 운영 부담을 줄여준다.

대표적인 서버리스 플랫폼으로는 AWS Lambda, Google Cloud Functions, Azure Functions 등이 있으며, 이벤트 기반 애플리케이션과 마이크로서비스를 폭넓게 지원한다.

정리: 서버리스는 서버 관리 없이 함수 단위 코드만 실행하는 클라우드 모델이다.

---

• 서버 인프라(Server Infrastructure): 애플리케이션이 실행되기 위해 필요한 하드웨어와 소프트웨어 자원(서버, 네트워크, 스토리지, 운영체제 등)을 통합한 기반 환경.
• 클라우드 컴퓨팅(Cloud Computing): 인터넷을 통해 서버, 스토리지, 데이터베이스, 네트워크, 소프트웨어 같은 IT 자원을 필요할 때 바로 제공받아 사용하는 방식. 사용자는 자원을 소유하지 않고 임대해 쓰는 개념.
• 함수(Function): 서버리스 컴퓨팅에서 실행 단위로 사용되는 작은 코드 블록으로, 특정 입력을 받아 한 가지 작업을 수행하고 결과를 반환한다.
• 트리거(Trigger): 함수를 실행시키는 이벤트나 조건으로, 예를 들어 HTTP 요청, 파일 업로드, DB 변경 같은 상황이 트리거가 될 수 있다.

Service Mesh는 분산 네트워크에서 마이크로서비스 간의 통신, 보안, 관리 기능을 향상시키기 위한 아키텍처 패턴이다. 서비스 메시에서는 지능형 프록시 집합을 사용해 서비스 간 통신을 관리하며, 이를 통해 높은 가용성, 효율적인 로드 밸런싱, 강력한 서비스 디스커버리를 보장한다.

또한 서비스 메시에는 네트워크 동작을 모니터링하는 가시성(Observability), 다양한 트래픽 관리 기능 같은 고급 기능도 제공된다. 일반적인 서비스 메시 구조에서는 각 마이크로서비스에 하나의 프록시가 쌍을 이루어 배치된다. 이 프록시는 주로 사이드카 패턴(Sidecar Pattern)을 사용해 배포되며, 해당 마이크로서비스의 통신을 처리할 뿐 아니라 로드 밸런싱, 지능형 라우팅, 안전한 데이터 전송 등 다양한 네트워크 기능도 구현한다.

사이드카 패턴은 특히 쿠버네티스 환경에서 메인 마이크로서비스 컨테이너 옆에 프록시 컨테이너를 함께 배치하는 방식으로 활용된다. 이러한 설계 덕분에 서비스 메시는 마이크로서비스 자체와 독립적으로 동작할 수 있어 관리와 업데이트를 단순화한다.

정리: 서비스 메시는 사이드카 프록시로 마이크로서비스 간 통신·보안을 관리하는 아키텍처다.

---

• 지능형 프록시(Intelligent Proxy): 서비스 간 트래픽을 중계하면서 보안, 로깅, 라우팅, 모니터링 같은 추가 기능을 제공하는 고급 프록시.
• 로드 밸런싱(Load Balancing): 다수의 서버나 서비스 인스턴스로 들어오는 요청을 균등하게 분산시켜 성능과 가용성을 높이는 기술.
• 서비스 디스커버리(Service Discovery): 분산 환경에서 동적으로 생성되는 서비스들의 위치(IP, 포트 등)를 자동으로 탐색하고 연결하는 메커니즘.
• 사이드카 패턴(Sidecar Pattern): 애플리케이션(주 서비스)과 함께 보조 기능을 담당하는 별도 컨테이너(사이드카)를 배치하는 설계 패턴.
• 지능형 라우팅(Intelligent Routing): 단순히 목적지로 보내는 것이 아니라, 상황(트래픽 상태, 정책, 버전 등)에 맞춰 최적 경로를 선택해 요청을 전달하는 기술.
• 쿠버네티스 환경(Kubernetes Environment): 컨테이너화된 애플리케이션을 자동 배포, 확장, 관리할 수 있는 오케스트레이션 플랫폼 환경.
• 마이크로서비스 컨테이너(Microservice Container): 특정 비즈니스 기능을 수행하는 마이크로서비스를 실행하는 독립적인 컨테이너.
• 프록시 컨테이너(Proxy Container): 마이크로서비스 컨테이너 옆에서 배치되어 트래픽 관리, 보안, 통신 기능을 담당하는 보조 컨테이너.

12-Factor App 방법론은 현대적이고 확장 가능하며 유지보수가 용이한 웹 애플리케이션을 구축하기 위한 원칙들의 집합으로, 특히 클라우드 환경에 적합하다. 이 방법론은 애플리케이션을 이식성, 확장성, 배포 용이성을 높일 수 있도록 개발하는 모범 사례들을 강조한다.

주요 원칙은 다음과 같다.

1. Codebase(코드베이스): 하나의 코드베이스를 버전 관리 시스템에서 추적하며, 여러 배포에 활용한다.
2. Dependencies(의존성): 의존성을 명시적으로 선언하고 격리한다.
3. Config(설정): 설정 정보를 환경 변수에 저장한다.
4. Backing Services(백엔드 서비스): DB, 메시지 브로커 등 백엔드 서비스를 연결된 자원으로 취급한다.
5. Build, Release, Run(빌드, 릴리스, 실행): 빌드 단계와 실행 단계를 분리한다.
6. Processes(프로세스): 앱을 하나 이상의 무상태 프로세스로 실행한다.
7. Port Binding(포트 바인딩): 서비스를 포트 바인딩을 통해 외부로 노출한다.
8. Concurrency(동시성): 프로세스 모델을 통해 확장한다.
9. Disposability(폐기성): 빠른 시작과 우아한 종료를 통해 강건성을 극대화한다.
10. Dev/Prod Parity(개발/운영 환경 일치): 개발, 스테이징, 운영 환경을 최대한 비슷하게 유지한다.
11. Logs(로그): 로그를 이벤트 스트림으로 취급한다.
12. Admin Processes(관리 프로세스): 관리 및 운영 작업은 일회성 프로세스로 실행한다.

정리: 12-Factor App은 클라우드 시대에 맞춘 이식성·확장성·유지보수성을 위한 12가지 원칙이다.