1. Spring Security

1.1 Spring Security 란?

• 보안을 손쉽게 적용하기 위한 Spring Framework의 하위 프로젝트
• 인증(Authentication)과 인가(Authorization)에 대한 다양한 기능을 제공
• Filter 기반의 아키텍처로 구성되어 있어, 다양한 커스터마이징이 가능

1.2 Spring Security 인증 및 인가 흐름

2. OAuth 2.0

2.1 OAuth2.0 이란?

• Open + Authorization (개방형 인가)
• 웹 및 애플리케이션 인증 및 권한 부여를 위한 개방형 표준 프로토콜
• 외부 Resoure에 접근하기 위해 사용

2.2 기본 용어

2.2.1 서버 및 클라이언트

• Resource Owner(사용자)
• Client(애플리케이션)
• Authorization Server(인증 서버, 토큰 발급)
• Resource Server(API 서버, 자원을 실제로 소유)

2.2.2 기타

• Authorization Code (인증 코드)
• Scope (범위)

2.3 인증 방식

2.3.1 Authrozation Code Grant

• 서버 기반 애플리케이션(Server-side Application)에서 가장 많이 사용되는 인증 방식
• 사용자에게서 직접 자격 증명 정보를 받지 않고, “인가 코드(Authorization Code)”를 발급받아 이를 이용해 액세스 토큰(Access Token)을 얻는 구조

2.3.2 Implicit Grant

• 브라우저에서 동작하는 자바스크립트 기반 애플리케이션과 같이 클라이언트 비밀(Client Secret)을 안전하게 보관하기 어려운 환경에서 사용하던 방식

2.3.3 Password Credentials Grant

• 사용자가 클라이언트에 직접 아이디/비밀번호 등의 자격 증명을 입력하고, 클라이언트가 이를 권한 서버에 전달하여 인증 및 액세스 토큰을 발급받는 방식

2.3.4 Client Credentials Grant

• 서버 대 서버 혹은 백엔드 서비스 간 통신과 같이, 사용자 대신 애플리케이션 자체가 리소스에 접근해야 할 때 사용하는 방식

2.4 통합 흐름

1. 개념

1.1 DB Lock 이란?

• DB Lock은 여러 트랜잭션이 동시에 같은 자원에 접근할 때 데이터 무결성(정합성)을 보장하기 위해 사용되는 메커니즘
• 쉽게 말해, 어떤 사용자가 데이터를 사용하고 있는 동안에는 다른 사용자가 그 데이터를 동시에 수정하면 안 되기 때문에, ‘잠금’을 걸어서 충돌(Conflict)을 방지

1.2 왜 Lock이 필요한가?

• 여러 사용자가 동시에 DB를 사용하는 경우 같은 데이터를 동시에 수정하려고 시도하는 경우 충돌 제어 및 데이터의 일관성을 보장하기 위해

1.3 언제 Lock을 사용하는가?

• 사용해야 하는 경우!
  • 동시에 읽기/쓰기가 빈번하게 일어나는 중요한 테이블에 대해, 데이터 무결성을 엄격히 보장해야 할 때.
  • 은행 이체, 재고 관리, 주문 처리와 같이 동시에 발생하면 안 되는 시나리오를 제어할 때.
    

    

• 주의해야할 점!
  • 불필요한 락은 성능 저하를 유발할 수 있으므로, 적절한 수준에서 사용하는 것이 중요
  • DeadLock!!
    • DeadLock발생 여부를 꼭 확인해야함!

1.4 Lock의 생명주기

1.4.1 트랜잭션 시작!

• DB와의 트랜잭션을 시작
• 아직 특정 자원에 대한 락이 획득된 상태는 🙅

1.4.2 Lock 획득

1. 쿼리 요청
2. Lock 체크
3. 대기 혹은 Lock 획득

1.4.3 트랜잭션 종료

1. 트랜잭션 커밋 혹은 롤백
2. 락 해제

2. Lock 종류

2.1 낙관적 락 (충돌이 발생하지 않을 것이라고 가정)

• 데이터베이스의 락을 사용하는 것이 아닌 application 레벨에서 버전 관리
• 특정 작업을 수행하기 전에 별도의 락(lock)을 걸지 않고, 작업 완료 시점에서 데이터의 변경 여부를 확인하여 충돌 여부를 판단 (@Version 활용)
• 데이터 충돌이 거의 없을것이라고 가정한 경우 사용
  • LockModeType.OPTIMISTIC로 적용
• 충돌 시 ObjectOptimisticLockingFailureException 발생

2.2 비관적 락 (충돌이 자주 발생할 것이라고 가정)

2.2.1 공유락(Shared Lock, S Lock)

• 여러 트랜잭션이 동시에 데이터를 읽기할 수 있지만, 쓰기 하려면 공유락을 해제하고 배타락으로 변경
• 다른 트랜잭션이 쓰기하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_READ로 적용

2.2.2 배타락(Exclusive Lock, X Lock)

• 오직 한 트랜잭션만 해당 데이터를 읽거나 쓸 수 있음
• 다른 트랜잭션이 접근하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_WRITE로 적용

2.3 분산 락

• 여러 인스턴스나 분산 환경에서 락을 설정
• 데이터베이스에 직접 Lock을 걸지 않고, 외부에서 권한을 받아 처리
• Redis, **Zookeeper 등... 을 활용하여 적용**

1. 개념

1.1 아키텍처란?

• 시스템을 효율적이고 안정적으로 만들기 위해, 각 구성 요소를 큰 그림으로 설계하는 설계도이다.

1.2 소프웨어 아키텍처란?

• 소프트웨어 아키텍처는 소프트웨어가 제공하는 가치인 기능과 구조 중 구조에 속한다.

1.3 왜 아키텍처를 고민을 해야할까?

1. 확장성(Scalability) 확보
   • 사용자 수가 늘어날 때, 시스템이 문제 없이 확장 가능
2. 유지보수(Maintainability) 용이
   • 아키텍처가 잘 정리되어 있으면, 버그 수정이나 새로운 기능 추가 시 어떤 부분을 건드려야 할지 명확
   • 모듈별 역할과 의존성을 분리하면, 유지보수 비용과 시간이 크게 감소

1.4 아키텍처를 잘 구현하기 위한 패턴들

1.4.1 레이어드 아키텍처 (Layered Architecture)

• 애플리케이션을 계층(Layer)으로 구분하여, 각 계층이 맡은 역할을 분리하는 전통적인 방식
• 장점
  • 역할이 명확해지면서, 코드를 이해하기 쉽고 유지보수가 용이
  • 초기에 구조를 잡기 쉬움
• 단점
  • 계층이 늘어날수록 호출이 복잡해질 수 있음
  • 변화가 많은 대규모 프로젝트에서 유연성이 떨어질 수 있음

1.4.2 헥사고날 아키텍처 (Hexagonal Architecture)

• 도메인 로직을 ‘중심(코어)’에 두고, 외부와의 연결(어댑터)을 육각형(포트와 어댑터) 형태로 구분하는 패턴
• 장점
  • 도메인(핵심 비즈니스 로직)과 인프라(데이터베이스, UI, 외부 시스템)를 느슨하게 결합
  • 테스트와 교체가 용이
• 단점
  • 초기 진입장벽이 다소 높음 (개념 이해와 구조 설계가 복잡)

1.4.3 클린 아키텍처 (Clean Architecture)

• 핵심 비즈니스 로직이 프레임워크나 외부 라이브러리에 의존하지 않도록 계층을 구성
• 장점
  • 변경에 강하고, 테스트하기 쉬운 구조
  • 의존성 역전 원칙(DIP)을 철저히 적용하여 유지보수성 극대화
• 단점
  • 설계 단계가 복잡하고, 팀 내 이해 합의가 필요
  • 과도하게 적용 시 오히려 개발 속도 저하

1.4.4 마이크로서비스 아키텍처 (Microservices Architecture)

• 시스템을 작고 독립적인 서비스들로 나누어 개발, 배포, 확장을 각각 독립적으로 진행하는 방식
• 장점
  • 서비스별로 독립된 스케일링 가능 (효율적 자원 활용)
  • 한 서비스 장애가 전체 시스템에 영향을 덜 줌
  • 기능별로 다른 기술 스택을 자유롭게 도입할 수 있음
• 단점
  • 서비스 간 통신, 배포 파이프라인 등 복잡도 상승
  • 운영, 모니터링, 트랜잭션 관리 측면에서 추가적인 관리 부담

1.4.5 이벤트 드리븐 아키텍처 (Event-Driven Architecture)

• 이벤트(메시지)를 통해 각 컴포넌트가 느슨하게 연결되도록 만드는 아키텍처
• 장점
  • 비동기 처리가 가능해, 높은 확장성과 성능을 기대할 수 있음
  • 각 컴포넌트가 독립적으로 메시지를 발행/구독하기 때문에 결합도가 낮음
• 단점
  • 트랜잭션을 다루기가 어렵고, 이벤트 플로우가 복잡해질 수 있음
  • 이벤트 중복 처리, 메시지 정합성(consistency) 관리 필요

2. 클린 아키텍처

2.1 클린 아키텍처란

• 소프트웨어 구조가 유연하고 확장 가능하며, 유지보수가 쉽도록 설계하는 방법론 중 하나로, 로버트 C.마틴(Robert C. Martin, Uncle Bob)의 제안

2.2 클린 아키텍처 필수 요건

1. 의존성 규칙(Dependency Rule)
   • 의존성은 바깥 레이어에서 안쪽 레이어로만 흐릅니다.
   • 핵심 비즈니스 로직(도메인)은 프레임워크, UI, DB를 전혀 몰라야 합니다.
2. 도메인 로직(핵심 비즈니스 로직)의 독립성
   • 도메인 모델(Entity 등)은 순수 자바 코드로 작성해, 프레임워크나 DB 관련 코드를 넣지 않습니다.
   • 도메인 정책(Validation, Calculation 등)은 도메인 레벨에서 처리하고, 바깥 레이어(프레임워크/인프라) 의존 로직을 섞지 않습니다.
3. 인터페이스를 통한 의존 역전(DIP)
   • 도메인이나 Use Case 측에서 필요한 기능(DB 저장, 메시지 전송 등)은 인터페이스로 정의합니다.
   • 실제 구현은 Adapter(구현체) 가 담당하고, 도메인/Use Case는 구현체를 몰라야 합니다.
4. 테스트 용이성
   • 도메인/Use Case가 외부 환경(DB, 네트워크 등)에 의존하지 않도록 설계합니다.
   • Mock/Stub을 이용해 유닛 테스트가 쉽도록 구조를 마련합니다.