각 디렉토리별 주요 구성 내용은 다음과 같습니다.

1. 핵심 디렉토리: skills/

이 저장소의 가장 중요한 부분으로, 용도에 따라 여러 하위 카테고리로 나뉩니다.

• engineering/ (엔지니어링 기술): 실제 코딩 작업에 사용되는 핵심 도구들입니다.
  • diagnose: 버그 진단 루프 (재현 -> 가설 -> 수정 -> 테스트).
  • tdd: 테스트 주도 개발(Red-Green-Refactor)을 위한 가이드.
  • grill-with-docs: 계획을 문서(CONTEXT.md, ADR)와 대조하며 검토하는 세션.
  • to-prd / to-issues: 대화 내용을 PRD(제품 요구 사양서)로 만들거나 GitHub 이슈로 분할.
  • improve-codebase-architecture: 코드베이스의 구조적 개선 제안.
  • setup-matt-pocock-skills: 이 스킬들을 사용하기 위한 초기 설정 도구.
• productivity/ (생산성 도구): 코딩 외의 일반적인 업무 효율을 높여줍니다.
  • grill-me: 계획이나 디자인에 대해 AI가 사용자에게 집요하게 질문하여 빈틈을 찾는 기능.
  • caveman: 불필요한 수식어를 빼고 핵심만 전달하여 토큰 사용량을 줄이는 통신 모드.
  • handoff: 현재 작업을 다른 에이전트가 이어받을 수 있게 요약 문서 생성.
  • write-a-skill: 새로운 스킬을 만드는 가이드.
• personal/ (개인용): 개인적인 워크플로우를 위한 도구입니다.
  • obsidian-vault: 옵시디언(Obsidian) 메모 관리 관련.
  • edit-article: 기사나 글 편집 지원.
• misc/ (기타): 특정 목적을 위한 도구들입니다.
  • git-guardrails-claude-code: 위험한 git 명령어(push, reset 등) 실행을 방지하는 가드레일.
  • setup-pre-commit: Husky나 Prettier 같은 프리커밋 훅 설정.
• in-progress/ & deprecated/: 현재 개발 중이거나 더 이상 사용되지 않는 예전 스킬들이 포함되어 있습니다.

2. 기타 주요 디렉토리 및 파일

• docs/: 프로젝트의 의사결정 기록(ADR - Architecture Decision Records)이 담겨 있습니다. 왜 특정 구조를 선택했는지에 대한 기술적 배경을 알 수 있습니다.
• scripts/: 스킬들을 시스템에 연결하거나 목록을 확인하는 데 사용되는 쉘 스크립트(link-skills.sh, list-skills.sh)가 들어 있습니다.
• README.md: 전체 프로젝트의 철학(왜 이 스킬들이 필요한지)과 빠른 시작 가이드가 포함되어 있습니다.
• CLAUDE.md / CONTEXT.md: AI 에이전트가 이 프로젝트 자체를 이해하고 작업할 때 참고하는 가이드라인 파일입니다.

요약 표

이 저장소의 스킬들은 단순히 코드를 짜는 것을 넘어, "엔지니어링 원칙(Fundamentals)"을 AI 작업 과정에 녹여내어 더 견고한 소프트웨어를 만드는 데 초점이 맞춰져 있습니다.

MSA 구조인 프로젝트에서 별도의 branch로 개발 중인 서비스를 실행하려다 공유하고 있는 모듈 중 다른 branch에 있고, 개발중인 서비스에서는 사용도 하지 않고, 참조도 하지 않는 파일에 대한 FileNotFoundException으로 애플리케이션 구동이 실패하였다.

Caused by: java.io.FileNotFoundException: SomethingMapper.class

2. 원인 분석

해당 파일에는 인터페이스에 다음과 같은 선언이 있었다.

@Mapper(componentModel = "spring")
public interface SomethingMapper { ... }

componentModel = "spring" 때문에 MapStruct가 생성한 구현체를 스프링 Bean으로 등록하려고 시도, → 하지만 현재 브랜치/서비스에는 SomethingMapper.class가 존재하지 않음. → 스프링이 빈 스캐닝 과정에서 해당 클래스를 찾지 못해 FileNotFoundException 발생.

즉, 공용 라이브러리에 선언된 MapStruct Mapper가 모든 서비스에서 스프링 Bean으로 등록되려 한 것이 원인으로 추정된다.

3. 해결 방법

1) ./gradlew clean build 와 Invalidated Caches를 진행 -> 해결 안됨

2) 원인 파일의 빈 주입 방식 변경 -> 해결

Before componentModel = "spring" 사용 → 스프링 빈 자동 등록 서비스 코드에서 @Autowired / private final 방식으로 의존성 주입

After componentModel = "spring" 제거 → 스프링 Bean 등록 안 됨 MapStruct의 정적 팩토리 메서드 방식 사용:

@Mapper
public interface SomethingMapper {
    SomethingMapper INSTANCE = 
        Mappers.getMapper(SomethingMapper.class);
}

서비스 코드에서 직접 호출:

@Service
@RequiredArgsConstructor
public class CallingService {
...
private final SomethingMapper mapper = 
    SomethingMapper.INSTANCE;
}

해당 파일을 수정하여 배포 후 에러가 나던 서비스의 Invalidated Caches를 진행하고 원래의 branch에서 Application Run을 해보고, branch를 바꿔 Application Run을 하니 제대로 실행되었다.

정리

@Mapper(componentModel = "spring") → MapStruct 구현체가 자동으로 Spring Bean이 됨. 이 경우, classpath에 존재하는 모든 Mapper 구현체가 스프링의 스캔 대상이 되며, 멀티 브랜치/멀티 모듈 환경에서는 공용 라이브러리 JAR까지 스캔돼서 예상치 못한 Bean 로딩 문제가 생길 수 있음. 반대로 Mappers.getMapper() 방식을 쓰면 Spring Bean 관리 대상이 아니므로, 다른 브랜치에 있는 클래스까지 영향을 주지 않음.

✅ 1. GitLab Personal Access Token 생성하기

• GitLab 웹에 로그인

• 우측 상단 프로필 > "Edit Profile" 클릭

• 왼쪽 메뉴에서 "Access Tokens" (또는 "Personal Access Tokens") 선택

• 아래 항목 설정:

  Name: 예: intellij-token

  Expires at: 원한다면 만료일 설정

  Scopes:

  read_repository (읽기만 할 경우)

  write_repository (푸시도 할 경우)

  api (API 연동이 필요할 경우)

• Create personal access token 클릭

  생성된 토큰을 복사해두세요. (다시 볼 수 없습니다!)

✅ 2. IntelliJ에서 GitLab 인증 설정

방법 A: Git 설정에서 토큰 사용

• IntelliJ에서 Preferences 또는 Settings 열기 (Cmd+, 또는 Ctrl+Alt+S)
• Version Control > Git 메뉴로 이동
• Path to Git executable 아래의 Test 버튼으로 git 설치 확인
• "Use credential helper" 또는 "Native" 선택

✅ 3. Git 작업 시 주의 사항

git push 또는 git pull 시 인증을 요구하면:

Username: GitLab 사용자명

Password: 생성한 Personal Access Token 사용

Queue 를 사용한 재시도

큐에 Delay 적용하여 재시도 횟수 별로 시간 차를 두어 호출하게 한다.

정보 유실이 일어나면 안되는 메시지나 빠르게 정보를 취합하는 것 보다 확실한 이벤트 전달이 중요할 때. Ex) 외부 서비스 웹 훅 이벤트 연동 등,,

• 장점 큐에 저장되기 때문에 서버 재시작 등으로 정보가 유실되지 않는다.⭐ 메인 서버 트랜잭션과 분리되어 있기 때문에 서버 부하를 최소화 한다. 큐 시스템 자체 설정에 따라 대용량 트래픽에 대응이 가능하다.

• 단점 기능 구현에 복잡성이 있다. 큐 시스템 운영 및 모니터링이 필요하다.

Resilience4j의 Retry를 활용한 재시도

RetryConfig 에 Duration 규칙을 두어 재시도 횟수별로 시간 차를 두었다.

Resilience4j의 Retry를 사용할 경우 시간 차를 길게 둘 수 없고 너무 많은 호출에 적용하면 서버 부하가 예상된다. 또한 데이터를 생성하거나 수정하는 호출에 경우 멱등성이 회손 될 가능성이 있다. 그렇기 때문에 호출 빈도수가 높고, 서비스 노출성이 높은 외부 API 조회성 호출에 적용하였다.

이 경우 서버 재시작으로 정보가 유실 되어도 Client 단에서 재접속시 정보를 획득 할 수 있고, 단기간 내에 정보 취득이 필요하다고 판단하여 이 방법을 선택하였다.

EX) 서비스에 필요한 정보를 외부 API를 통해 가져오는 건

• 장점 구현이 간단하다. JVM 내에서 처리 가능하다.

• 단점 재시도 대기 중인 요청은 Thread와 자원을 점유하기 때문에 서버 메모리에 부담이 된다. 서버 재시작 등의 이슈가 있을 시 재시도 정보가 유실 될 수 있다. 텀이 긴 재시도는 불가능 하다.

1. Choreography (코레오그래피) 방식

• 이벤트 기반으로 서비스들이 서로 통신하면서 트랜잭션을 관리하는 방식
• 중앙 컨트롤러 없이 각 서비스가 이벤트를 보고 반응

예시 주문 트랜잭션

Order Service에서 주문 생성 이벤트 발행 (OrderCreated)

Payment Service가 이를 받아 결제 승인 (PaymentApproved)

Inventory Service가 재고 차감 (InventoryUpdated)

실패하면 보상 이벤트(OrderCancelled)를 발행하여 롤백

✅ 장점

서비스 간 느슨한 결합 (각 서비스가 독립적으로 동작)

확장성(새로운 서비스 추가가 쉬움)

❌ 단점

서비스 간 이벤트 흐름이 복잡해질 수 있음

디버깅과 트랜잭션 추적이 어려움

2. Orchestration (오케스트레이션) 방식

• 중앙에서 하나의 SAGA Coordinator(조정자)가 전체 트랜잭션을 관리
• 중앙 컨트롤러가 서비스 호출을 순차적으로 수행하고, 실패 시 롤백을 실행

예시 주문 트랜잭션

SAGA Coordinator가 Order Service에 주문 생성 요청

Order Service가 성공하면 Payment Service에 결제 요청

Payment Service가 성공하면 Inventory Service에 재고 차감 요청

어느 한 단계라도 실패하면, 이전 서비스들에 보상 트랜잭션 수행

예: 결제 성공 후 재고 부족 → Payment Service에 결제 취소 요청

✅ 장점

트랜잭션 흐름이 명확하고 관리가 쉬움

디버깅 및 모니터링이 용이

❌ 단점

중앙 SAGA Coordinator에 의존 → 단일 장애점(Single Point of Failure, SPOF) 위험

서비스 간 결합도가 증가할 가능성이 있음

단일 서비스에서 SAGA 패턴을 유사하게 적용하는 방법

(1) @Transactional을 활용한 트랜잭션 처리 (Repository 간 트랜잭션) JPA 기반 Repository는 @Transactional을 활용하여 자동 롤백이 가능합니다.

@Service
public class OrderService {
    @Autowired private OrderRepository orderRepository;
    @Autowired private PaymentRepository paymentRepository;

    @Transactional
    public void processOrder(Order order) {
        orderRepository.save(order); // 주문 저장
        paymentRepository.save(order.getPayment()); // 결제 저장
        // 만약 여기서 예외 발생 시, 두 작업 모두 롤백됨
    }
}

• 이 방식은 같은 DB 내의 여러 Repository를 조작하는 경우 적합
• 예외 발생 시 전체 트랜잭션이 롤백됨 ❌ 외부 API 호출이 포함될 경우에는 적용되지 않음

(2) 외부 API와 함께 사용할 때는 보상 트랜잭션 적용

• @Transactional은 DB 내 트랜잭션만 관리 가능하므로 외부 API 호출이 포함되면 별도의 보상 트랜잭션이 필요함.

ex) 주문 저장 + 결제 API 호출

@Service
public class OrderService {
    @Autowired private OrderRepository orderRepository;
    @Autowired private PaymentService paymentService;

    public void processOrder(Order order) {
        try {
            orderRepository.save(order); // 1. 주문 저장
            paymentService.processPayment(order); // 2. 외부 결제 API 호출
        } catch (Exception e) {
            compensateOrder(order); // 실패 시 보상 트랜잭션 실행
        }
    }

    private void compensateOrder(Order order) {
        orderRepository.delete(order); // 주문 취소 (보상 트랜잭션)
    }
}

• 주문이 저장된 후 결제 API 호출 중 실패하면 주문을 취소하는 "보상 트랜잭션" 실행 ❌ 하지만, 이 방식은 여러 서비스 간의 비동기 이벤트 흐름을 관리하는 것이 아님

(3) 이벤트 기반 SAGA 방식 적용 (Kafka, RabbitMQ 활용) 만약 하나의 서비스 내에서 여러 개의 API와 DB 트랜잭션을 관리해야 한다면, 이벤트 기반으로 관리 가능

Kafka 같은 메시지 큐를 사용하여 비동기 방식으로 트랜잭션을 보상 처리

ex)

@Service
public class OrderService {
    @Autowired private KafkaTemplate<String, String> kafkaTemplate;
    @Autowired private OrderRepository orderRepository;

    public void processOrder(Order order) {
        orderRepository.save(order);
        kafkaTemplate.send("order_created", order.getId().toString()); // 이벤트 발행
    }
}

@Component
@KafkaListener(topics = "order_created")
public class PaymentService {
    @Autowired private PaymentRepository paymentRepository;

    public void processPayment(String orderId) {
        try {
            paymentRepository.save(new Payment(orderId));
        } catch (Exception e) {
            kafkaTemplate.send("order_failed", orderId); // 실패 시 보상 이벤트 발행
        }
    }
}

@Component
@KafkaListener(topics = "order_failed")
public class CompensationService {
    @Autowired private OrderRepository orderRepository;

    public void compensateOrder(String orderId) {
        orderRepository.deleteById(orderId); // 보상 트랜잭션 실행
    }
}

• Kafka를 활용하여 SAGA 패턴처럼 보상 트랜잭션을 수행
• 비동기 이벤트 기반으로 처리 가능 ❌ 구현이 복잡하고 메시지 큐를 관리해야 함

3. 언제 어떤 방법을 쓰는게 좋을지

@Transactional DB의 여러 Repository를 한 트랜잭션으로 처리할 때

• 간단하고 안정적 외부 API 포함 시 트랜잭션 관리 불가
  • 보상 트랜잭션 (Compensating Transaction) 외부 API가 포함된 트랜잭션 처리 시 예외 발생 시 롤백 가능 수동으로 롤백 로직을 구현해야 함

이벤트 기반 처리 (Kafka, RabbitMQ) API & DB 작업이 많고 비동기 처리가 필요한 경우

• 비동기 트랜잭션 관리 가능, MSA에서 확장 가능 구현이 복잡하고 메시지 큐 필요

💡결론 단일 서비스 내에서 여러 개의 Repository를 다룰 때는 @Transactional을 사용하자.

외부 API가 포함될 경우 보상 트랜잭션(Compensating Transaction)을 구현하자.

비동기 이벤트 기반 처리가 필요하면 Kafka를 활용하여 SAGA 패턴과 유사한 흐름을 만들자.

즉, 단일 서비스에서는 전통적인 트랜잭션 관리 방식(@Transactional + 보상 트랜잭션)을 활용하고, 필요에 따라 이벤트 기반 방식도 고려하는 것이 좋다!

AWS 아키텍쳐 구성

API Gateway

Client에서 server로 통신할 때 사용하는 많은 api들의 대문(게이트웨이).

라우팅 설정에 따라 각 엔드포인트로 클라이언트를 대리하여 요청하고 응답을 받으면 다시 클라이언트에게 전달하는 프록시(proxy) 역할을 한다.

Lambda

특정한 경우에만 실행시키는 Serverless 컴퓨팅 플랫폼,

DynamoDB

AWS에서 제공하는 no-sql 데이터베이스.

시퀀스 다이어그램

Base62 인코딩 방식

URL에서는 /, + 기호가 구분자로 사용되기 때문에, 인코딩을 했을 때에 이 문자들이 포함된다면 기대값과 다르게 동작할 수 있다. Base62는 위 2가지 케이스를 제외하고 URL-safe 한 문자들만 모든 방식이라고 할 수 있겠다.

Referrence https://caputdraconis.tistory.com/entry/AWS-%EA%B0%9C%EC%9D%B8-URL-Shortener-%EB%A7%8C%EB%93%A4%EA%B8%B0

before

bootJar {
    dependsOn asciidoctor
    from("${asciidoctor.outputDir}") {
        into 'static/api-docs'
    } 
}

after

bootJar {
    from("${asciidoctor.outputDir}") {
        into 'static/api-docs'
    }
    dependsOn asciidoctor
}

build.gradle에서 bootJar 부분에 dependsOn asciidoctor가 위에 있으면 asciidoctor.outputDir가 활성화 되지 않았다.

다른 부분은 해당 이슈에 대해서 아래 참조 블로그나 검색을 통해 참고할 수 있는 부분이 많이 있었으나 위 부분은 사소한 부분이라 그런지 언급이 없어서 적어 놓기로 하였다.

아래 참조 블로그 글을 통해 REST docs와 이슈에 대해 좀 더 확실히 이해할 수 있게 되었다. 참조: 그건 제 잔상입니다만..

# base image 설정(as build 로 완료된 파일을 밑에서 사용할 수 있다.)
FROM node:16.19.0-alpine as builder

# root 에 app 폴더를 생성
RUN mkdir /app

# work dir 고정
WORKDIR /app

COPY . .

RUN apk --no-cache --virtual build-dependencies add \
    python3 \
    make \
    g++ \
    && apk del build-dependencies

RUN apk --update add rsync

ENV PATH /usr/src/app/node_modules/.bin:$PATH

# RUN npm install 
# 안될 시
RUN npm install --legacy-peer-deps 

# 호스트 머신의 현재 디렉토리 파일들을 컨테이너 내부로 전부 복사
COPY . .

# npm build
RUN npm run build

# nginx 이미지를 사용합니다. 뒤에 tag가 없으면 latest 를 사용합니다.
FROM nginx:1.25-alpine

# 이전 빌드 단계에서 빌드한 결과물을 /app/build 으로 복사한다.
COPY --from=builder /app/build /app/build

# nginx 의 default.conf 를 삭제
RUN rm /etc/nginx/conf.d/default.conf

# host pc 의 nginx.conf 를 아래 경로에 복사
COPY ./nginx.conf /etc/nginx/conf.d

# 80 포트 오픈
EXPOSE 80

# container 실행 시 자동으로 실행할 command. nginx 시작함
CMD ["nginx", "-g", "daemon off;"]

docker pull image

#docker image list 확인 docker image list

docker tag nexus-url:port/path/image:tag #tag 전체경로

docker push nexus-url:port/path/image:tag

nexus image 확인

#docker image 삭제 docker rmi imageId

#삭제 후 이미지 리스트 확인 docker image list

No space left on device: 장치에 남은 공간이 없음 배포 후 발생하는 에러를 확인해보니 아래와 같은 메시지가 확인 되었습니다.

우선은 서버 용량을 추가하고, docker에서 불필요하게 차지하는 부분을 없앨 방법을 찾아 보았습니다.

docker system df -v

💡 docker system df : 현재 사용중인 이미지, 컨테이너 및 볼륨이 얼마나 많은 공간을 사용하고 있는지 확인할 수 있는 명령어. 뒤에 -v (vervose)옵션을 추가하면 사용하지 않는 이미지와 컨테이너도 확인 가능

docker prune

💡 docker prune : 사용하지 않는 컨테이너 이미지를 제거하는 명령어. prune의 가장 큰 특징은 어떠한 옵션을 주는가에 따라 그 역할이 달라진다는 것

option docker volume prune : 미사용 볼륨 제거 docker container prune : 미사용 컨테이너 제거 docker image prune : 미사용 이미지 제거 docker system prune : 미사용 중인 이미지, 컨테이너, 볼륨 모두 제거

우선적으로 docker systme prune 명령어를 통해 일부 용량을 확보 할 수 있었습니다.

추가적으로 재발 방지를 위해, 아래와 같이 일주일이 지난 컨테이너 및 이미지 등에 대하여 주기적으로 삭제하는 크론탭을 daily.cron에 등록하였습니다. prune 명령어에는 —-filter 옵션이 있는데 이를 잘 활용하면 운영에 큰 이점이 있습니다.

docker system prune -af --filter "until=$((7*24))h"

참고 : https://velog.io/@ryu_log/%EA%B8%80%EB%98%90-No-space-left-on-device-Docker-prune

1. docker hub에 로그인이 되지 않을 경우
2. user name과 docker hub 에 로그인된 ID가 일치하지 않을 경우

1. 로그인하지 않아서 발생한 경우

docker hub 회원가입 및 docker login 입력하여 로그인 진행 * shell에서 docker login 시 계정이름 사용할 것! not email!

2. 이미지의 user name과 docker hub에 가입된 ID가 일치하지 않을 경우

아래 이미지에서 노란색으로 표시한 부분이 이미지의 user name 입니다. 기존에 만들어둔것은 nirsa 인데, docker hub (https://hub.docker.com/) 에 가입했던 ID와 달랐습니다.

//기존 이미지 삭제
$ docker image rm [image-name]

// 새 이미지에 user name과 통일시켜 생성
... .gitlab-ci.yml
- docker build -t $DOCKER_HUB_ID/$IMAGE_NAME:latest .
...

referrence : https://nirsa.tistory.com/53

Ubuntu에 Docker를 설치하는 것은 매우 간단합니다. Docker 저장소를 활성화하고 저장소 GPG 키를 가져온 후 패키지를 설치합니다.

$ sudo apt update

// 새 HTTPS 리포지토리를 추가하는 데 필요한 종속성을 설치
$ sudo apt install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

// 리포지토리의 GPG 키를 가져옴
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

// Docker APT 리포지토리를 시스템에 추가
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

// 최신 버전의 도커를 설치
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io

// 특정 Docker 버전을 설치
$ apt list -a docker-ce
$ sudo apt install docker-ce=<VERSION> docker-ce-cli=<VERSION> containerd.io

// 설치가 완료되면 도커 서비스가 자동으로 시작
$ sudo systemctl status docker
# ● docker.service - Docker Application Container Engine
#      Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
#      Active: active (running) since Thu 2020-05-21 14:47:34 UTC; 42s ago
# ...

//도커 패키지가 업데이트되지 않도록 하려면 보류로 표시
$ sudo apt-mark hold docker-ce

// root외 유저에 도커 권한 부여
$ sudo usermod -aG docker $USER

// 설치 확인
$ docker container run hello-world
or
$ sudo docker version

docker 설치 참고 https://jjeongil.tistory.com/1968 https://dongle94.github.io/docker/docker-ubuntu-install/

gitlab-runner 설치

gitlab-runner를 docker와 사용하려면 docker 설치 필요!

$ su - root

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

$ sudo apt install gitlab-runner

$ sudo gitlab-runner register

Q: Enter the GitLab instance URL (for example, https://gitlab.com/):  (GitLab URL 입력하기)
I: https://gitlab.com/  (위에서 확인한 URL 카피하여 복사)

Q: Enter the registration token:  (GitLab Repository Token 입력하기)
I: ~~~~CA~~~~ (위에서 확인한 token 카피하여 복사)

Q: Enter a description for the runner:  (Runner Description 입력하기)
I: ex) GitLab Runner Test

Q: Enter tags for the runner (comma-separated):  (태그 입력하기, 여기서 입력된 태그는 gitlab-ci.yml파일에서 등록된 runner를 구분하기 위해 사용)
I: ex) dev-all

Q: Enter an executor: docker-ssh+machine, custom, parallels, shell, virtualbox, docker+machine, docker, docker-ssh, ssh, kubernetes:  (빌드에 사용되는 executor 선택)
I: ex) docker

Q: Enter the default Docker image (for example, ruby:2.6):  (Docker image default 입력)
I: docker:20.10.12  (위에서 확인한 docker 버전 입력)
or docker:latest

// runner 연결 확인
$ gitlab-runner list

// Docker를 사용해서 배포하는 경우
$ sudo usermod -aG docker gitlab-runner

// GitLab CI에 작성된 docker 명령어들은 모두 dind로 수행
// runner의 설정에 다음의 값들을 수정 및 추가해줘야 함
$ vi /etc/gitlab-runner/config.toml
... 
[[runners]]
  [runners.docker]
    privileged = true
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    network_mode = "host"
    pull_policy = ["always"]
 ...
 :wq //저장 후 나감

 $ service docker restart // 도커 재시작

gitlab-runner 설치 참고 https://yscho03.tistory.com/m/133 https://jforj.tistory.com/227

 - $ sudo apt update
 - $ sudo apt install openjdk-17-jdk
 - $ java -version 
 #경로  
 - default : /usr/lib/jvm/java-[버전]-openjdk-amd64/bin/java
 - $ sudo vi /etc/environment
 PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
 JAVA_HOME="/usr/lib/jvm/java-17-openjdk-amd64"
  - $ source /etc/environment
  - $ echo $JAVA_HOME
  /usr/lib/jvm/java-17-openjdk-amd64

java 설치 참고

gradle 설치

$ sudo apt update
$ VERSION=8.0.2
$ wget https://services.gradle.org/distributions/gradle-${VERSION}-bin.zip -P /tmp
$ sudo unzip -d /opt/gradle /tmp/gradle-${VERSION}-bin.zip
# gradle 설치 디렉터리를 가리키는 latest라는 이름의 심볼 링크를 만듬.
$ sudo ln -s /opt/gradle/gradle-${VERSION} /opt/gradle/latest

#환경변수 설정
$ sudo nano /etc/profile.d/gradle.sh
export GRADLE_HOME=/opt/gradle/latest
export PATH=${GRADLE_HOME}/bin:${PATH}
:wq
$ sudo chmod +x /etc/profile.d/gradle.sh
$ source /etc/profile.d/gradle.sh

# 설치 확인
$ gradle -v
# Welcome to Gradle 6.5.1!
# 
# Here are the highlights of this release:
#  - Experimental file-system watching
#  - Improved version ordering
#  - New samples
# 
# For more details see https://docs.gradle.org/8.0.2/release-notes.html
# 
# 
# ------------------------------------------------------------
# Gradle 8.0.2
# ------------------------------------------------------------
# 
#...

mysql 설치

$ sudo apt-get update

$ sudo apt-get install mysql-server
# 설치 중간 중간 Password를 물어보는데 빈칸으로 두고 OK를 누르면 Ubuntu 서버 비밀번호와 자동으로 동기화 된다.

# 외부 접속 기능 설정 (포트 3306 오픈)
$ sudo ufw allow mysql

# MySQL 실행
$ sudo systemctl start mysql

# Ubuntu 서버 재시작시 MySQL 자동 재시작 - 옵션
$ sudo systemctl enable mysql

# MySQL 접속
$ sudo /usr/bin/mysql -u root -p

참고 : ubuntu에 mysql 설치

리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너(container)로 실행하고 관리하는 오픈 소스 프로젝트이다.

서버에서 다양한 프로그램, 실행환경을 _컨테이너_로 추상화하고 동일한 인터페이스를 제공하여 프로그램의 배포 및 관리를 단순하게 해준다. 백엔드 프로그램, 데이터베이스 서버, 메시지 큐등 어떤 프로그램도 컨테이너로 추상화할 수 있고 조립PC, AWS, Azure, Google cloud등 어디에서든 실행할 수 있다.

그래서 대부분의 서버 사이드 개발회사들이 "도커"라는 프로그램(컨테이너)을 도입하기 시작했다.

컨테이너?

컨테이너는 영어 뜻 그대로 무언가를 담는 "그릇, 용기, 통" 등을 의미한다. 도커는 어느 환경이든 구애받지 않고 어플리케이션 환경을 그대로 푹(?)떠서 여기서 저기로 저기서 여기로 옮기는 컨테이너같은 역할을 한다. 그래서 도커는 곧 "컨테이너"라는 개념으로 통용된다.

도커 설치

설치 파일 다운받기

공식 사이트 또는 Docker hub에서 본인 사양에 맞는 설치 파일을 다운로드한다. 도커 공식 홈페이지

-> 다운로드한 .dmg 파일을 실행하여 Docker.app을 응용 프로그램으로 복사해준다.

-> Docker Desktop을 실행하면 메뉴 막대 상단에 아이콘이 생성된다.

설치 확인

터미널에서 다음 명령어를 통해 정상 설치 유무를 확인할 수 있다.

• docker
• docker --version

Refference [ Docker Desktop] Mac용 Docker Desktop 설치하기

@ExceptionHandler는 Controller계층에서 발생하는 에러를 잡아서 메서드로 처리해주는 기능이다. Service, Repository에서 발생하는 에러는 제외한다.

Controller계층에서 발생하는 에러

@Controller
public class TestController {

    // ...

    @ExceptionHandler
    public ResponseEntity<String> handle(IOException ex) {
        // ...
    }
}

이렇게 @Controller로 선언된 클래스 안에서 @ExceptionHandler 어노테이션으로 메서드 안에서 발생할 수 있는 에러를 처리할 수 있다.

여러개의 Exception 처리

@ExceptionHandler의 value 값으로 어떤 Exception을 처리할 것인지 넘겨줄 수 있는데, value를 설정하지 않으면 모든 Exception을 잡게 되기 때문에 Exception을 구체적으로 적어주는 것이 좋다고 한다.

여러 개의 Exception이 발생할 수 있는 코드가 있다고 하자.

@Controller
public class TestController {

    // ...

    @ExceptionHandler({FileSystemException.class, RemoteException.class})
    public ResponseEntity<String> handle(Exception ex) {
        // ...
    }
}

메서드의 인자로 Exception ex를 받고 있고 @ExceptionHandler의 value값으로 특정 Exception들을 설정해주고 있다. 여러개의 Exception을 잡아야한다면, @ExceptionHandler({IOException.class})처럼 포괄적인게 아닌 @ExceptionHandler({FileSystemException.class, RemoteException.class})로 구체적으로 명시해주는 것을 권장한다고 한다.

We generally recommend that you be as specific as possible in the argument signature, reducing the potential for mismatches between root and cause exception types. Consider breaking a multi-matching method into individual @ExceptionHandler methods, each matching a single specific exception type through its signature. 출처 - 스프링 공식 문서

@ControllerAdvice

@ControllerAdvice에서 @ExceptionHandler 사용

@ControllerAdvice는 @Controller와 handler에서 발생하는 에러들을 모두 잡아준다. @ControllerAdvice안에서 @ExceptionHandler를 사용하여 에러를 잡을 수 있다.

@ControllerAdvice
public class ExceptionHandlers {

    @ExceptionHandler(FileNotFoundException.class)
    public ResponseEntity handleFileException() {
        return new ResponseEntity(HttpStatus.BAD_REQUEST);
    }
}

범위 설정

@ControllerAdvice는 모든 에러를 잡아주기 때문에 일부 에러만 처리하고 싶을 경우에는 따로 설정을 해주면 된다. 방법은 아래와 같다.

• 어노테이션
• basePackages (+basepackagesClasses)
• assignableTypes

// 어노테이션
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}

// basePackages
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}

// assignableTypes
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
public class ExampleAdvice3 {}

주의 사항 어노테이션, basePackages 등 설정자들은 runtime시 수행되기 때문에 너무 많은 설정자들을 사용하면 성능이 떨어질 수 있다! 스프링 공식 문서

@RestControllerAdvice

@RestControllerAdvice는 @ControllerAdvice와 @ResponseBody을 가지고 있다. @Controller처럼 작동하며 @ResponseBody를 통해 객체를 리턴할 수 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@ControllerAdvice
@ResponseBody
public @interface RestControllerAdvice {
    // ...    
}

@ControllerAdvice vs @RestControllerAdvice

@ControllerAdvice는 @Componenet 어노테이션을 가지고 있어 컴포넌트 스캔을 통해 스프링 빈으로 등록된다.

@RestControllerAdvice는 @Controlleradvice와 @ResponseBody 어노테이션으로 이루어져있고 HTML 뷰 보다는 Response body로 값을 리턴할 수 있다.

주의 사항❗❗

ExceptionHandler가 붙은 함수는 꼭 protected / private 처리를 해줘야 한다. 외부에서 함수를 부르게 되면 그대로 에러 객체를 리턴하기 때문이다.

Filter란?

• 웹 애플리케이션에서 들어오는 요청과 나가는 응답을 가로채고 수정하는 데 사용됨
• DispatcherServlet이 실행되기 전에 실행되며 웹 컨테이너에서 관리됨
• Interceptor와는 달리 Request, Response 객체를 수정할 수 있음 (아래 Filter Interface 참고)
• Java Servlet API의 표준 기능
• 인증, 로깅, XSS 방어, 이미지 및 데이터 압축, 인코딩/디코딩 요청 및 응답, 스프링과 무관하게 전역적으로 처리해야하는 작업을 처리하는데 사용됨

Interceptor란?

• DispatcherServlet이 컨트롤러를 호출하기 전/후로 스프링컨 텍스트 내부에서 컨트롤러에 관한 요청과 응답에 대해 처리
• 스프링 컨텍스트 외부에 존재하는 필터와는 달리 인터셉터는 스프링 컨텍스트 내부에 존재하기 때문에 스프링의 모든 빈 객체에 접근이 가능
• HandlerInterceptor 인터페이스를 사용하여 정의할 수 있음
• 세부적인 보안 및 인증, 인가 작업, 로깅, Controller에 넘겨주는 데이터 가공

Filter 메서드

package javax.servlet;

import java.io.IOException;

public interface Filter {

    public default void init(FilterConfig filterConfig) throws ServletException {}

    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException;

    public default void destroy() {}
}

👉 init()

필터 인스턴스 초기화 메서드

서블릿 컨테이너는 필터를 인스턴스화 한 후 한 번 init 메서드를 호출

👉 doFilter()

헤더, 매개변수 또는 속성을 추가하거나 수정하는 등 요청 및 응답 객체를 수정할 수 있음 (Interceptor는 객체 수정 못함)

FilterChain을 사용하여 체인의 다음 필터 또는 요청을 처리하는 서블릿을 호출할 수 있음

👉 destroy()

서블릿 컨테이너는 doFilter메서드 내의 모든 쓰레드가 종료되거나 설정한 제한 시간이 지난 후에 destroy 메서드를 한 번 호출하며, 이후에는 해당 필터의 인스턴스로는 doFilter를 호출하지 않는다.

Filter 구현 예시

@WebFilter(urlPatterns = {"/api/*"}, asyncSupported = true)
@Component
@RequiredArgsConstructor
public class AccessLogFilter extends OncePerRequestFilter {

    private final AccessLogger accessLogger;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
        long stime = System.currentTimeMillis();
        try {
            chain.doFilter(request, response);
        } finally {
            long etime = System.currentTimeMillis();
            long elapsed = etime - stime;
            accessLogger.log(request, response, elapsed);
        }
    }
}

Interceptor 메서드

public interface HandlerInterceptor {

   default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
         throws Exception {

      return true;
   }

   default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
         @Nullable ModelAndView modelAndView) throws Exception {
   }

   default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
         @Nullable Exception ex) throws Exception {
   }

}

👉 preHandle()

요청이 컨트롤러에 의해 처리되기 전에 호출됨 요청을 계속 처리해야 하는지 또는 중지해야 하는지를 나타내는 boolean 값을 리턴 (false면 작업 중단)

👉 postHandle()

요청이 컨트롤러에 의해 처리된 후 view가 렌더링되기 전에 호출됨 model과 view를 수정하는데 사용 가능

👉 afterCompletion()

뷰가 렌더링된 후 호출됨

로깅, 리소스 반환과 같은 정리 작업을 수행하는 데 사용

JWT 인증 Interceptor 구현 예시

@Component
@RequiredArgsConstructor
public class JwtTokenInterceptor implements HandlerInterceptor {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {

        System.out.println("JwtToken 호출");
        String accessToken = request.getHeader("ACCESS_TOKEN");
        System.out.println("AccessToken:" + accessToken);
        String refreshToken = request.getHeader("REFRESH_TOKEN");
        System.out.println("RefreshToken:" + refreshToken);

        if (jwtTokenProvider.isValidAccessToken(accessToken) && jwtTokenProvider.isValidRefreshToken(refreshToken)) {
            return true;
        }else{
            throw new RequestException(ErrorCode.JWT_BAD_TOKEN_401);
        }
    }

}

SQL에서 조인이란 두 개 이상의 테이블을 하나의 집합으로 만드는 연산을 뜻합니다. FROM 절에 두 개 이상의 테이블이 나열될 경우 조인이 수행되며, 조인 연산은 두 테이블 사이에서 수행됩니다. FROM 절에 A, B, C라는 세 개의 테이블이 존재하더라도 세 개의 테이블이 동시에 조인이 수행되는 것은 아니고, 세 개의 테이블 중에서 먼저 두 개의 테이블에 대해 조인이 수행됩니다. 이러한 작업은 FROM 절에 나열된 모든 테이블을 조인할 때까지 반복 수행합니다.

NL Join(Nested Loop Join)

NL Join은 프로그래밍에서 사용하는 중첩된 반복문과 유사한 방식으로 조인을 수행합니다. 반복문의 외부에 있는 테이블을 선행 테이블 또는 외부 테이블 (Outer Table)이라고 하고, 반복문의 내부에 있는 테이블을 후행 테이블 또는 내부 테이블(Inner Table)이라고 합니다.

1. 선행 테이블에서 조건을 만족하는 첫 번째 행을 스캔 (이 때 선행 테이블에 주어진 조건을 만족하지 않는 경우 해당 데이터는 필터링)

2. 선행 테이블의 조인 키를 가지고 후행 테이블에 조인키가 존재하는지 스캔

-> 조인 시도 3. 후행 테이블의 인덱스에 선행 테이블의 조인 키가 존재하는지 확인 -> 선행 테이블의 조인 값이 후행 테이블에 존재하지 않으면 선행 테이블 데이터는 필터링 (더 이상 조인 작업을 진행할 필요 없음)

4. 인덱스에서 추출한 레코드 식별자를 이용하여 후행 테이블을 액세스

-> 인덱스 스캔을 통한 테이블 액세스. 후행 테이블에 주어진 조건까지 모두 만족하면 해당 행을 추출버퍼에 넣음

코드예시

SELECT   /*+ USE_NL (B) */
        A.*
      , B.*
FROM    ITEM A, UITEM B
WHERE A.ITEM_ID=B.ITEM_ID --- 1
AND A.ITEM_TYPE_CD = '100100' --- 2
AND A.SALE_YN = 'Y'  --- 3
AND B.SALE_YN = 'Y'  --- 4

동작순서 : 2 -> 3 -> 1 -> 4

특징

1. 절차적이며, 프로그래밍에서 FOR, WHILE문 과 같은 구조로 수행된다.

2. 선행테이블은 풀스캔하므로, 선행테이블의 크기가 작을수록 유리하다 (So. 두 테이블의 크기 차이가 있는 경우, 유리하게 사용될 수 있는 방법임)

3. 후행테이블에 대해서는 반드시 인덱스가 존재해야 NL 조인이 가능하다.

4. 인덱스 구성 전략이 특히 중요하다. 조인 컬럼에 대한 인덱스가 있느냐 없느냐, 있다면 컬럼이 어떻게 구성됐느냐에 따라 조인 효율이 크게 달라진다.

5. 랜덤 액세스 방식으로 데이터를 읽는다.-> 처리 범위가 좁은 것이 유리하다.

이런 여러가지 특징을 종합할 때, NL 조인은 소량의 데이터를 주로 처리하거나 부분범위처리가 가능한 온라인 트랜잭션 환경에 적합한 조인 방식이라고 할 수 있다.

Sort Merge Join

Sort Merge Join은 조인 컬럼을 기준으로 데이터를 정렬하여 조인을 수행합니다. NL Join은 주로 랜덤 액세스 방식으로 데이터를 읽는 반면 Sort Merge Join은 주로 스캔 방식으로 데이터를 읽습니다. Sort Merge Join은 랜덤 액세스로 NL Join에서 부담이 되던 넓은 범위의 데이터를 처리할 때 이용되던 조인 기법입니다. 그러나 Sort Merge Join은 정렬할 데이터가 많아 메모리에서 모든 정렬 작업을 수행하기 어려운 경우에는 임시 영역(디스크)을 사용하기 때문에 성능이 떨어질 수 있습니다.

일반적으로 대량의 조인 작업에서 정렬 작업을 필요로 하는 Sort Merge Join 보다는 CPU 작업 위주로 처리하는 Hash Join이 성능상 유리합니다. 그러나 Sort Merge Join은 Hash Join 과는 달리 동등 조인뿐만 아니라 비동등 조인에 대해서도 조인 작업이 가능하다는 장점이 있습니다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키를 기준으로 정렬작업을 수행

   • 1 ~ 2번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블의 조인 키를 기준으로 정렬 작업을 수행

   • 3 ~ 4번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

5. 정렬된 결과를 이용하여 조인을 수행하며 조인에 성공하면 추출버퍼에 넣음

코드예시

SELECT  /*+ ORDERED USE_MERGE(B) */
        A.*
      , B.*
FROM  ITEM A, UITEM B
WHERE A.ITEM_ID=B.ITEM_ID   -- 1
AND A.ITEM_TYPE_CD = '100101'   -- 2 
AND A.SALE_YN = 'Y'  -- 3 
AND B.SALE_YN = 'Y'  -- 4

동작 순서 2 -> 3 -> 4 -> 1

특징

1. 인덱스가 없어도 가능한 조인법

2. 대부분 해시조인인 보다 느린 성능을 보이나, 아래와 같은 상황에서는 소트머지 조인이 유용하다.

• First 테이블에 소트연산을 대체할 인덱스가 있을 때
• 조인할 First 집합이 이미 정렬되어 있을 때
• 조인 조건식이 등차(=)조건이 아닐 때

3. 두 테이블의 사이즈가 비슷한경우에 유리하며, 사이즈 차이가 큰 경우에는 불리하고, 비효율적인 방법이다.

Hash Join

Hash Join은 해싱 기법을 이용하여 조인을 수행합니다. 조인될 두 테이블 중 하나를 해시 테이블로 선정하여 조인될 테이블의 조인 키 값을 Hash 알고리즘으로 비교하여 매치되는 결과값을 얻는 방식입니다. HASH JOIN은 비용 기반 옵티마이저를 사용할 때만 사용될 수 있는 조인 방식이며 '=' 비교를 통한 조인에서만 사용될 수 있습니다. 주로 많은 양의 데이터를 조인해야 하는 경우에 주로 사용됩니다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키를 기준으로 해시함수를 적용하여 해시 테이블을 생성 -> 조인 컬럼과 SELECT 절에서 필요로 하는 컬럼도 함께 저장

   • 1 ~ 2번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블의 조인 키를 기준으로 해시 함수를 적용하여 해당 버킷을 찾음 -> 조인 키를 이용해서 실제 조인될 데이터를 찾음

5. 조인에 성공하면 추출버퍼에 넣음

   • 3 ~ 5번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

특징

1. 조인 칼럼의 인덱스를 사용하지 않기 때문에 조인 칼럼의 인덱스가 존재하지 않을 경우데도 사용할 수 있는 기법이다.

2. 메모리 사용이 큰 대용량 테이블 조인시 메모리 외에 임시영역(PGA 메모리)까지 사용하여 저장할 수 있어 유리함

3. 해쉬 함수를 이용하여 조인을 수행하기 때문에 '='로 수행하는 조인에서만 사용가능 합니다.

Spring 기반의 어플리케이션의 보안(인증과 권한, 인가 등)을 담당하는 스프링 하위 프레임워크이다. Spring Security는 기본적으로 인증 절차를 거친 후에 인가 절차를 진행하며, 인가 과정에서 해당 리소스에 접근 권한이 있는지 확인하게 된다. 기본적으로 쿠키-세션 방식을 사용한다.

인증(Authentication) : 해당 사용자가 본인이 맞는지 확인하는 과정 인가(Authorization) : 해당 사용자가 요청하는 자원을 실행할 수 있는 권한이 있는가를 확인하는 과정

간단한 예시로는 인증은 ID와 PW를 통해 로그인하는 행위, 인가는 인증된 사용자가 어떠한 자원에 접근할 수 있는지를 확인하는 절차.

SecurityFilterChain

스프링 시큐리티를 이용하면 개발시에 필요한 사용자의 인증, 권한, 보안 처리를 간단하지만 강력하게 구현 할 수 있다. 일반적인 웹 환경에서 브라우저가 서버에게 요청을 보내게 되면, DispatcherServlet(FrontController)가 요청을 받기 이전에 많은 ServletFilter(서블릿 필터)거치게 된다. Security와 관련한 서블릿 필터도 실제로는 연결된 여러 필터들로 구성 되어 있다. 이러한 모습때문에 Chain(체인)이라는 표현을 쓴다.

스프링 시큐리티 처리과정

1. 사용자가 로그인 정보와 함께 인증 요청을 한다.(Http Request)
2. AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성한다.(Authentication 인터페이스의 구현체다.)
3. AuthenticationManager의 구현체인 ProviderManager에게 생성한 UsernamePasswordToken 객체를 전달한다.
4. AuthenticationManager는 등록된 AuthenticationProvider(들)을 조회하여 인증을 요구한다.
5. 실제 DB에서 사용자 인증정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨준다.
6. 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보인 UserDetails 객체를 만든다.
7. AuthenticationProvider(들)은 UserDetails를 넘겨받고 사용자 정보를 비교한다.
8. 인증이 완료되면 권한 등의 사용자 정보를 담은 Authentication 객체를 반환한다.
9. 다시 최초의 AuthenticationFilter에 Authentication 객체가 반환된다.
10. Authenticaton 객체를 SecurityContext에 저장한다.

최종적으로 SecurityContextHolder는 세션 영역에 있는 SecurityContext에 Authentication 객체를 저장한다. 그 후 인가 처리를 진행한다.

UserDetails

public class PrincipalDetails implements UserDetails {

    private User user;

    public PrincipalDetails(User user) {
        this.user = user;
    }

    //해당 User의 권한을 리턴하는 곳!!
    //인가 처리를 위해 있음.
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Collection<GrantedAuthority> collect = new ArrayList<>();
        collect.add(new GrantedAuthority() {
            @Override
            public String getAuthority() {
                return user.getRole();
            }
        });
        return collect;
    } 
    ...
}

1. 시큐리티가 login 주소요청이 오면 낚아채서 로그인을 진행시킨다
2. 로그인을 진행이 완료가 되면 시큐리티 session을 만들어준다.(Security ContextHolder)
3. 시큐리티 세션 오브젝트 안에 Authentication 타입 객체
4. Authentication 안에 User정보가 있어야 되는데 스프링 시큐리티에서는 User정보를 UserDetails타입 객체로 받는다.

Security Session(Authentication(UserDetails)) 이런 형태가 된다.

UserDetailsService

@Service
public class PrincipalDetailsService implements UserDetailsService {

    @Autowired
    private UserRepository userRepository;

    //시큐리티 session(내부 authentication(내부 UserDetaitls))
    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        User user = userRepository.findByUsername(username)
                .orElseThrow(()->
                new UsernameNotFoundException("해당 username이 없습니다"));
        return new PrincipalDetails(user);
    }
}

로그인 처리시 DB에서 실제 유저 정보를 받아 UserDetails객체를 만들어 준다.

인가

@Configuration
@EnableWebSecurity//스프링 시큐리티 필터가 스프링 필터체인에 등록이 됩니다.
@EnableGlobalMethodSecurity(securedEnabled = true,prePostEnabled = true)// secured 어노테이션 활성화, preAuthorized 어노테이션 활성화
public class SecurityConfig {

    @Autowired
    private PrincipalOauth2UserService principalOauth2UserService;
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception{
        http.csrf().disable();
        http.authorizeRequests()
                .antMatchers("/user/**").authenticated()
                .antMatchers("/manager.**").access("hasRole('ROLE_ADMIN') or hasRole('ROLE_MANAGER')")
                .antMatchers("/admin/**").access("hasRole('ROLE_ADMIN')")
                .anyRequest().permitAll()
                .and()
                .formLogin()
                .loginPage("/loginForm")
                //.usernameParameter("username2") -> userDetailsService의 loadByUsername함수 파라미터값을 바꾸고싶을때
                .loginProcessingUrl("/login")
                .defaultSuccessUrl("/")
        return http.build();
    }
}

스프링 시큐리티 필터에서 인가를 설정할 수 있다.

@Secured("ROLE_ADMIN")
    @GetMapping("/info")
    public @ResponseBody String info(){
        return "개인정보";
    }

    @PreAuthorize("hasRole('ROLE_MANAGER') or hasRole('ROLE_ADMIN')")
    @GetMapping("/data")
    public @ResponseBody String data(){
        return "data정보";
    }

Refference 스프링시큐리티_jm3128

말 그대로 계층이 있는 아키텍쳐. 각 계층은 수평적으로 구성이 되고, 각 계층마다 특정 역할을 한다.

보통은 아래의 4계층으로 구성된다.

• Presentation
• Bussiness
• Persistence
• Database

하지만 Application의 규모에 따라서 3- 5 개 등의 구조를 가질 수 있음.

AOP처럼 횡단관심사로 분리해서 수평 계층으로 구성되어 각각의 layer는 하나의 관심사만 집중할 수 있도록 하는 것이다.

주요 개념

Layered Architecture에서는 각 계층마다 화살표를 통해 흐름을 이어간며 각 계층을 뛰어넘을 수 없다. ( Presentation → Persistence)

왜 뛰어넘을 수 없을까?

@RestController
@RequestMapping("/layered")
@RequiredArgsConstructor
public class TestController {
    private final TestRepository testRepository;
    private final TestService testService;

    @Transactional
    @GetMapping
    public Test getUserInfo(TestReqDto reqDto) {
        Optional<Test> byId = testRepository.findById(1L);
        Test test = byId.orElse(new Test());
        test.updateUserInfo(reqDto);
        return testService.getUserinfo();
    }
}

@Entity
@Table(name = "test")
public class Test {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; // 고유번호 PK
    private String name; // 이름
    private int age; // 나이
    private String gender; // 성별
    private String email; // 이메일
    private String contact; // 연락처

    public void updateUserInfo(TestReqDto updateDto) {
        this.name = updateDto.getName();
        this.gender = updateDto.getGender();
        this.email = updateDto.getEmail();
        this.contact = updateDto.getContact();
    }
}

위의 코드와 같이 Controller에서 Domain 간의 관계가 밀접하게 연관이 되고, 변경사항이 Service와 Repository에 퍼지게 된다. +추후 수정도 어려워진다.

때문에 각 계층은 서로에게 관심을 두지 않고 필요에 의해서 찾는 관계가 되어야한다.

예시

표현계층 (Presentation Layer)

사용자의 요청에 대해서 해석, 응답하는 계층

• 로깅
• 인증(보안)

ex) Controller

@RestController
@RequestMapping("/layered")
@RequiredArgsConstructor
public class TestController {
        private final TestService testService;

    @GetMapping
    public Test updateUser(TestReqDto reqDto) {
        return testService.updateUserInfo(reqDto);
    }
}

응용 프로그램 계층(Bussiness Layer)

실질적인 비즈니스 로직을 처리하는 계층. (보통 Service를 뜻 함.)

도메인(Domain Layer)과 인프라스트럭쳐(InfraStructure Layer)를 연결

// 인터페이스
public interface TestService {
    D_Test updateUserInfo(TestReqDto reqDto);
}

// 구현체
@Service
@RequiredArgsConstructor
public class TestServiceImpl implements TestService {
    private final TestRepository repository;
    @Override
    public Test updateUserInfo(TestReqDto reqDto) {
                if(reqDto.getId() == null || reqDto.getId() == 0) {
                    throw new CommonException("존재하지 않는 아이디 입니다.");
                }
        return repository.findById(reqDto.getId()).orElse(null);
    }
}

영속성 계층(Persistence Layer)

DB에 접근하는 계층. Business에서 온 요청으로 조회 함.

DDD에서 쓸 때에는 도메인 레이어라고 부르는 것 같음

도메인 계층(Domain Layer)

도메인 : 소프트웨어로 해결하고자 하는 문제 영역

예를 들어 쇼핑몰이 있다면 쇼핑몰 자체가 하나의 도메인이 되고, 그 아래

• 고객 (Customer)

• 판매자 (Seller)

• 주문 (Order)

• 포인트 (Point)

• 결제 (Payment)

• 배송 (Delivery) 등등 하위 도메인으로 나눌 수 있다.

  @Entity
  @Table(name = "domain_test")
  public class DomainTest {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id; // 고유번호 PK
    private String name; // 이름
    private int age; // 나이
    private String gender; // 성별
    private String email; // 이메일
    private String contact; // 연락처
  
    public void updateUserInfo(TestReqDto updateDto) {
        this.name = updateDto.getName();
        this.gender = updateDto.getGender();
        this.email = updateDto.getEmail();
        this.contact = updateDto.getContact();
    }
  }

Layered Architecture의 장점

• 배우기 쉬움
• 느슨한 연결을 이용해, 자신의 관심사만 집중할 수 있음
• 비즈니스 로직을 유지해서 유지보수와 확장성 측면에서 이득을 얻을 수 있음.
• 재사용성 높음

Layered Architecture의 단점

• 서비스가 커질수록 복잡도가 증가해 확장성이 떨어짐
• 싱크홀 안티패턴을 고려해야 함.

Refference https://velog.io/@jeb1225/DDD의-계층구조Layered-architecture https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

더티체킹은 Transaction 안에서 엔티티의 변경이 일어나면, 변경 내용을 자동으로 데이터베이스에 반영하는 JPA 특징이다.

Dirty Checking의 뜻은 변경 감지 정도로 생각할 수 있다. 즉, 변경을 감지해서 DB에 반영한다.

예를 들어 다음과 같은 코드가 있다.

@Slf4j
@RequiredArgsConstructor
@Service
public class PayService {

    public void updateNative(Long id, String tradeNo) {
        EntityManager em = entityManagerFactory.createEntityManager();
        EntityTransaction tx = em.getTransaction();
        tx.begin(); //트랜잭션 시작
        Pay pay = em.find(Pay.class, id);
        pay.changeTradeNo(tradeNo); // 엔티티만 변경
        tx.commit(); //트랜잭션 커밋
    }
}

코드를 보면 별도로 데이터베이스에 save 하지 않는다.

1. 트랜잭션이 시작되고
2. 엔티티를 조회하고
3. 엔티티의 값을 변경하고
4. 트랜잭션을 커밋합니다.

여기서 데이터베이스에 update 쿼리에 관한 코드는 어디에도 없다.

이 코드가 어떻게 작동하는지 테스트 코드를 작성하여 수행해보면,

@RunWith(SpringRunner.class)
@SpringBootTest
public class PayServiceTest {

    @Autowired
    PayRepository payRepository;

    @Autowired
    PayService payService;

    @After
    public void tearDown() throws Exception {
        payRepository.deleteAll();
    }

    @Test
    public void 엔티티매니저로_확인() {
        //given
        Pay pay = payRepository.save(new Pay("test1",  100));

        //when
        String updateTradeNo = "test2";
        payService.updateNative(pay.getId(), updateTradeNo);

        //then
        Pay saved = payRepository.findAll().get(0);
        assertThat(saved.getTradeNo()).isEqualTo(updateTradeNo);
    }
}

아래와 같은 로그를 확인할 수 있다. save 메소드로 변경 사항을 저장하지 않았음에도 update 쿼리가 실행되었다.

JPA에서는 트랜잭션이 끝나는 시점에 변화가 있는 모든 엔티티 객체를 데이터베이스에 자동으로 반영해준다.

이때 변화가 있다의 기준은 최초 조회 상태이다.

JPA에서는 엔티티를 조회하면 해당 엔티티의 조회 상태 그대로 스냅샷을 만들어놓는다. 그리고 트랜잭션이 끝나는 시점에는 이 스냅샷과 비교해서 다른점이 있다면 Update Query를 데이터베이스로 전달한다. 이런 상태 변경 검사의 대상은 영속성 컨텍스트가 관리하는 엔티티에만 적용 된다.

detach된 엔티티 (준영속) DB에 반영되기 전 처음 생성된 엔티티 (비영속)

준영속/비영속 상태의 엔티티는 Dirty Checking 대상에 포함되지 않기 때문에 값을 변경해도 데이터베이스에 반영되지 않는다.

Spring Data Jpa와 @Transactional이 함께 할 경우엔 다음과 같다.

@Slf4j
@RequiredArgsConstructor
@Service
public class PayService {

    private final PayRepository payRepository;

    @Transactional
    public void update(Long id, String tradeNo) {
        Pay pay = payRepository.getOne(id);
        pay.changeTradeNo(tradeNo);
    }
}

위 코드의 테스트 코드를 작성해서 실행해보면

@Test
public void SpringDataJpa로_확인() {
    //given
    Pay pay = payRepository.save(new Pay("test1",  100));

    //when
    String updateTradeNo = "test2";
    payService.update(pay.getId(), updateTradeNo);

    //then
    Pay saved = payRepository.findAll().get(0);
    assertThat(saved.getTradeNo()).isEqualTo(updateTradeNo);
}

아래와 같이 정상적으로 update 쿼리가 수행됨을 확인할 수 있다.

변경 부분만 update하고 싶을땐? @DynamicUpdate

Dirty Checking으로 생성되는 update 쿼리는 기본적으로 모든 필드를 업데이트한다.

JPA에서는 전체 필드를 업데이트하는 방식을 기본값으로 사용하며, 전체 필드를 업데이트하는 방식의 장점은 다음과 같다.

• 생성되는 쿼리가 같아 부트 실행시점에 미리 만들어서 재사용가능합니다.
• 데이터베이스 입장에서 쿼리 재사용이 가능하다
  • 동일한 쿼리를 받으면 이전에 파싱된 쿼리를 재사용한다.

출처: 김영한님의 자바 ORM 표준 JPA 프로그래밍

다만, 필드가 20~30개 이상으로 많은 경우엔 이런 전체 필드 Update 쿼리가 부담스러울 수 있다. (사실 이런 경우 정규화가 잘못된 경우일 확률이 높다. 한 테이블에 필드 30개는 확실히 많다.)

그래서 이런 경우엔 @DynamicUpdate로 변경 필드만 반영되도록 할 수 있다.

엔티티 최상단에 아래와 같이 @DynamicUpdate 를 선언해주시면 된다.

@Getter
@NoArgsConstructor
@Entity
@DynamicUpdate // 변경한 필드만 대응
public class Pay {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String tradeNo;
    private long amount;

그리고 다시 테스트 코드를 수행해서 로그를 확인해보면!

변경분 (trade_no)만 Update 쿼리에 반영된 것을 확인할 수 있다.

Referrence 더티 체킹 (Dirty Checking)이란? by 향로