이름이 비슷하지만 완전 다른 것들
CORS는 웹 보안 정책이고 CQRS는 백엔드 아키텍처 패턴이다.

CORS(Cross-Origin Resource Sharing)

다른 출처 간의 요청을 허용할지 말지를 서버가 제어하는 보안 매커니즘.

다른 출처란?

• 프로토콜, 도메인, 포트 번호 중 하나라도 다르면 다른 출처(origin)으로 간주된다!

예를 들어,
a: https://example.com
b: http://example.com <- 프로토콜 다름
c: https://api.example/com <- 다른 서브도메인
d: https://example.com:8080 <- 포트 다름

CORS의 동작 패턴

클라이언트(브라우저)와 서버 사이에서 다음과 같은 절차(패턴)으로 작동한다.

1. Simple Request(단순 요청)

조건이 충족될 경우, 브라우저는 사전 요청(preflight) 없이 서버에 바로 요청을 보낸다
조건

• GET, POST, HEAD 메서드 중 하나
• 헤더가 다음 중 하나만 포함됨: Accept, Accept-Language, Content-Language, Content-Type (Content-Type은application/x-www-form-urlencoded, multipart/form-data, text/plain중 하나여야 함)

2. Preflight Request(사전 요청)

조건이 맞지 않으면 브라우저는 먼저 OPTIONS 요청을 보내 서버사 요청을 허용하는지 확인한다.

PUT, DELETE같은 메서드 사용 또는 Content-Type: application/json같은 특별한 헤더 포함 시에.

요청 흐름
1. 브라우저 -> 서버: OPTIONS 요청 (preflight)
2. 서버 -> 브라우저: 허용 여부 응답
3. 브라우저 -> 서버: 실제 요청

CQRS 패턴 (Command Query Responsibility Segregation)

명령(Command)과 조회(Query)의 책임을 분리하는 아키텍처 패턴

장단점

장점

• 유지보수성 향상
• 기술 스택 분리 가능 (ex: 명령은 RDB+ JPA/ 조회는 NoSQL + MyBatis)
• 성능 최적화 및 확장성 유리

단점

• 구현 복잡도 증가 (모델/레이어가 두배!)
• 명령과 조회 관 동기화 필요
• 간단한 시스템에서는 오버스펙일 수 있다

적용 예시

• Order: 명령용, OrderData: 조회용 으로 두 모델로 분리
• 단일 DB에서도 명령은 JPA, 조회는 MyBatis 사용 가능

CQRS는 복잡한 비즈니스 로직과 고성능 조회가 필요한 시스템에서 유용하나, 복잡성이 증가하므로 상황에 맞게 신중히! 도입해야 한다.