아키텍처 간략 정리

1. MVC (Model-View-Controller)

구성 요소

• Model: 데이터와 비즈니스 로직을 관리합니다.
• View: 사용자에게 정보를 시각적으로 표시합니다.
• Controller: 사용자 요청을 처리하고 Model과 View를 연결합니다.

특징

• 역할이 분리되어 코드의 가독성과 재사용성이 높습니다.
• 사용자가 View와 상호작용하면 Controller가 이를 처리하고 Model을 업데이트한 후, View에 결과를 표시합니다.

활용

• 웹 애플리케이션(스프링 MVC, Ruby on Rails 등)
• 데스크톱 애플리케이션

2. MVVM (Model-View-ViewModel)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: UI 요소.
• ViewModel: View와 Model 사이의 중간 계층으로, View의 상태를 관리하고, 데이터 바인딩을 지원합니다.

특징

• 양방향 데이터 바인딩을 통해 View와 ViewModel의 동기화를 자동으로 처리합니다.
• View는 데이터에 대한 의존성을 최소화합니다.

활용

• WPF(Windows Presentation Foundation)
• Angular, Vue.js, React + Redux/MobX와 같은 SPA(Single Page Application) 프레임워크

3. MVP (Model-View-Presenter)

구성 요소

• Model: 데이터와 비즈니스 로직.
• View: 사용자 인터페이스(UI).
• Presenter: View의 로직을 담당하며 Model과 상호작용한 후 데이터를 View에 전달합니다.

특징

• View는 단순히 UI를 표시하는 역할만 하고, 모든 로직은 Presenter에서 처리됩니다.
• View와 Presenter는 1:1 관계를 갖습니다.

활용

• 안드로이드 애플리케이션
• 레거시 데스크톱 애플리케이션

4. Clean Architecture

구성 요소

• Entities: 애플리케이션의 비즈니스 규칙을 캡슐화.
• Use Cases: 애플리케이션의 특정 작업이나 기능을 정의.
• Interface Adapters: 데이터와 UI의 변환 계층.
• Frameworks & Drivers: 데이터베이스, UI, 외부 API 등.

특징

• 의존성 규칙: 안쪽 계층은 바깥쪽 계층을 알지 못합니다.
• 비즈니스 로직이 프레임워크와 독립적이어서 확장성과 유지보수가 용이합니다.

활용

• 대규모 시스템
• 멀티 플랫폼 애플리케이션

5. Layered Architecture (계층형 아키텍처)

구성 요소

• Presentation Layer: 사용자 인터페이스.
• Application Layer: 비즈니스 로직.
• Data Layer: 데이터베이스 및 데이터 액세스.

특징

• 계층 간 명확한 분리가 이루어집니다.
• 단순하고 이해하기 쉬운 구조지만, 복잡한 시스템에서 성능 저하가 있을 수 있습니다.

활용

• 전통적인 웹 애플리케이션(3-tier 아키텍처)
• 엔터프라이즈 애플리케이션

6. Microservices Architecture

구성 요소

• 애플리케이션을 독립적으로 배포 가능한 작은 서비스들로 나눕니다.
• 각 서비스는 고유한 비즈니스 기능을 담당하며 API로 통신합니다.

특징

• 독립적인 배포와 확장이 가능합니다.
• 서비스 간 통신 오버헤드가 있고, 분산 시스템의 복잡성이 증가할 수 있습니다.

활용

• 대규모 분산 시스템
• 클라우드 네이티브 애플리케이션

7. Event-Driven Architecture

구성 요소

• Event Producer: 이벤트를 생성하고 발행.
• Event Consumer: 이벤트를 처리.
• Event Broker: 이벤트를 전달하거나 중개.

특징

• 비동기 통신을 기반으로 설계되어 높은 확장성을 제공합니다.
• 복잡한 이벤트 흐름을 관리하기 위한 설계가 필요합니다.

활용

• IoT 시스템
• 실시간 애플리케이션(채팅, 트랜잭션 시스템)

8. Hexagonal Architecture (Ports and Adapters)

구성 요소

• Core (Application Logic): 애플리케이션의 핵심 비즈니스 로직.
• Ports: 외부와의 상호작용을 정의하는 인터페이스.
• Adapters: 특정 구현을 제공하여 Core와 통신.

특징

• 비즈니스 로직과 외부 시스템 간의 의존성을 최소화합니다.
• 높은 테스트 가능성과 확장성을 제공합니다.

활용

• 복잡한 도메인 로직이 있는 시스템
• 시스템 간 통합이 필요한 애플리케이션

9. Serverless Architecture

구성 요소

• 클라우드 기반 서비스와 함수(Function-as-a-Service)를 이용하여 애플리케이션을 실행.
• 서버를 관리하지 않고도 클라우드 제공자가 모든 인프라를 처리.

특징

• 확장성과 비용 효율성이 높습니다.
• 서버 환경에 대한 제어가 제한적입니다.

활용

• 이벤트 중심 애플리케이션
• 간단한 API 백엔드

10. CQRS (Command Query Responsibility Segregation)

구성 요소

• Command: 데이터 변경 작업(쓰기).
• Query: 데이터 읽기 작업.

특징

• 읽기와 쓰기를 분리하여 각 작업을 최적화합니다.
• 복잡한 시스템에서 동시성과 확장성을 지원합니다.

활용

• 이벤트 소싱 시스템
• 고성능 읽기/쓰기 작업이 필요한 시스템

11. Pipe and Filter Architecture

구성 요소

• Filters: 데이터를 처리하는 독립적인 컴포넌트.
• Pipes: 필터 간 데이터를 전달.

특징

• 데이터 흐름을 직관적으로 표현할 수 있습니다.
• 처리 단계가 많아지면 성능 저하가 발생할 수 있습니다.

활용

• 데이터 처리 파이프라인
• 이미지 또는 오디오 프로세싱

12. Service-Oriented Architecture (SOA)

구성 요소

• 독립적인 서비스들로 구성되며, 각 서비스는 특정 비즈니스 기능을 제공합니다.
• 서비스는 표준 프로토콜(예: SOAP, REST)을 통해 통신합니다.

특징

• 서비스 간 의존성이 낮아 확장성과 재사용성이 높습니다.
• 복잡한 통합과 관리가 필요합니다.

활용

• 엔터프라이즈 애플리케이션
• 분산 시스템

CSR에서 자바 스프링 백엔드 아키텍처

1. 계층형 아키텍처 사용 (Layered Architecture)
2. RESTful API 서버로 프론트엔드와 데이터 통신
3. JPA + Hibernate를 통한 데이터베이스 연동
4. JWT를 통한 보안 및 인증 처리
5. 마이크로서비스 및 API Gateway 적용 가능 (Spring Cloud Gateway)
6. 비즈니스 로직, 예외 처리, 로깅, 모니터링 구성

➡️ CSR 환경에서는 프론트엔드가 주로 UI를 렌더링하고, 자바 스프링 백엔드는 데이터 제공, 비즈니스 로직 처리, 보안, 데이터베이스 연동을 주로 담당합니다.

아키텍처 패턴 선택 가이드

1. 프로젝트 규모:
   • 작은 프로젝트: MVC, MVP
   • 대규모 프로젝트: Microservices, Clean Architecture
2. 프론트엔드 및 백엔드 협업:
   • 단일 애플리케이션: MVVM, MVC
   • 분리된 환경: RESTful API 기반 MC
3. 확장성 요구:
   • 높은 확장성: Microservices, Serverless
4. 실시간 처리:
   • 실시간 데이터: Event-Driven, CQRS

언어별 연산 속도

단순 연산 기준으로 나눠본 언어별 연산 속도 + 특징

Python

• 인터프리터 언어
• 연산 속도 : 1초에 1억
• C 기반의 확장 라이브러리(ex:Numpy)를 활용해 연산이 빠를 수 있음
• PyPy (JIT 컴파일러) 약 2~10배 빠름

JavaScript

• 인터프리터 언어
• 연산 속도 : 1초에 1억 ~ 5억
• JIT 컴파일러를 통해 연산속도 보완

Java

• 컴파일 언어
• 연산 속도 : 1초에 5억 ~ 10억
• Java는 JVM 위에서 실행되며, JIT컴파일링, 런타임 최적화 등이 있음, 기본 연산속도로 따졌을 때 Python보다 약 1020배, JavaScript보다 약 25배 빠름

C / C++

• 컴파일 언어
• 연산 속도 : 1초에 10억 ~ 50억
  • C와 C++은 컴파일 언어로, 코드가 기계어로 직접 변환되기에 가장 빠른 속도
• 하드웨어와 매우 가까운 수준에서 작업 가능

C#

• 연산 속도 : 1초에 5억 ~ 10억
• C#은 Java와 유사한 속도, .NET의 JIT 컴파일러와 런타임 최적화가 되어있음

PHP

• 인터프리터 언어
• 1초에 약 1억 ~ 2억
• C 기반으로 구현된 함수와 라이브러리를 호출

데이터 베이스 구현 언어

현재 주력 데이터베이스들인 MySQL, PostgreSQL, Oracle등 대부분의 데이터베이스는 C 또는 C++로 구현되어 있어 기계어에 가까운 최적화된 실행 성능을 갖고 있다.

정리

기본 연산속도가 가장 빠른 언어는 C, 그 외의 언어는 연산속도를 보장하기 위해 JIT 컴파일러, c언어 기반의 최적화된 라이브러리 등을 지원하여, 연산속도를 보완한다.

추가로 개발자들이 사용하는 것들(ex: MySQL, PHP, 파이썬 라이브러리)이 C 기반으로 만들어지는 이유를 추측하자면, 연산속도를 포함하여 low한 레벨에서 하드웨어에 가깝게 빠른 동작을 실행하려면 메모리, Disk I/O등 C언어 방식으로 직접 관리하는 것이 가장 최적화에 도움을 주는 방식이기 때문이 아닐까 생각된다.

개요

보안을 위해 jwt 토큰저장방식을 Cookie - httpOnly,Secure 옵션을 넣어 사용하는 것으로 합의

토큰 발급 api 구현 후 프론트엔드 병민님의 요청으로 현재 쿠키의저장로직이 다른 페이지로 이동 시 사라지는 것을 확인

• 현재 통신방식
  • 서버 - ec2서버도메인
  • 클라이언트 - localhost

현재 상황

서버

• ec2서버 도메인
• SSL 미적용으로 http 통신

클라이언트

• localhost로 각자 pc에서 요청
• SSL 미적용으로 http통신

문제점

현재 서버와 클라이언트의 도메인이 일치하지 않아 서버측에 쿠키 발급 요청시 도메인이 일치하지 않아 토큰 저장까지는 하지만, 해당 페이지를 벗어났을 때 쿠키가 제거됨. 브라우저에서 막는 것으로 추정

서버에서 발급해준 쿠키의 Domain 옵션이 localhost로 변경되지 않고, 서버측 도메인으로 강제 설정되어있는 상태

생각할 수 있는 해결 방안

• 임의로 바디로 넘겨주기(제대로 도메인 적용해서 배포하기 전까지)
• 프론트를 서버에 띄우기
• 각자 프론트 컴퓨터에 백엔드 서버 돌아가게 해주기
• EC2랑 로컬에 SSL 적용해서 HTTPS 통신 되게 한 후, Samesite=None Secure=true 설정

⇒ 도메인 적용 전까지 바디로 넘겨주며, 서버에 배포해 동일한 도메인 사용 후에 Cookie로 서버측에서 발급하는 형태로 진행 예정