작은 발자국들의 위대한 여정

엔티티 연관관계 (식별/비식별, Cardinality, 선택/필수)

뭉지(moonz) — Sun, 20 Jul 2025 15:33:40 +0900

엔티티 간 연관관계를 얘기할 때에는, "엔티티 간 식별 관계" 와 "엔티티 간 연결되는 개체 수", "선택/필수 관계"를 이용해서 관계를 정의할 수 있다.

1. 부모, 자식 관계가 있는 엔티티 간 식별 여부를 정의하는 "식별 관계"

2. 관계가 있는 엔티티 간 하나의 엔티티에서 다른 엔티티에 몇개의 개체와 대응되는 갯수를 의미하는 "Cardinality"

3. 대응되는 개체의 필수 여부를 정의하는 "선택/필수 관계"

식별 관계와 비식별 관계

먼저 엔티티 간 식별 관계이다.

식별/비식별 관계는, 자식 개체가 부모 객체 없이도 식별될 수 있는지, 부모 객체 없이는 식별될 수 없는지를 의미한다.

식별 관계

자식 엔티티가 부모 엔티티의 식별자 (PK)를 본인의 식별자 (PK)로 사용하거나

복합키일 경우, 자신의 식별자에 부모의 식별자를 포함시키는 경우 식별 관계로 본다.

자식 엔티티는 부모 엔티티 없이 식별될 수 없을 만큼, 개체 간 아주 강한 의존관계를 가진다.

<예시>

1:M 관계로, 주문과 주문 상세 엔티티 관계가 있다.

주문 상세 엔티티는 주문의 PK인 주문번호를 자신의 PK로 갖기 때문에, 주문 데이터의 식별자 없이 주문 상세 데이터를 식별할 수 없다.

1:1 관계로, 조인 전략을 맺는 엔티티 간 관계를 예시로 들 수 있다.

김영한 님의 JPA 강의에서 만난 예제인데, 판매 상품 정보들의 공통점 데이터가 하나의 상품 테이블에 존재하고

각 ALBUM, MOVIE, BOOK 은 해당 ITEM 테이블을 상속받으면서, 각자의 속성을 관리하는 테이블이 있다. (객체의 상속 관계를 나타내는 '조인 전략' 방법이다.)

이때 세 테이블은 ITEM 테이블의 PK 를 자신의 PK이자 FK로 참조하고 있다.

출처 : 김영한님의 <자바 ORM 표준 JPA 프로그래밍 - 기본편 - 고급 매핑> 강의 자료 중

비식별 관계

자식 엔티티가 부모 엔티티와 독립적인 식별자 (PK)를 갖고 있어

자식 엔티티가 부모 엔티티와 독립적으로 존재할 수 있는, 엔티티 간 약한 의존 관계를 가진다.

<예시>

멤버 테이블과 팀 테이블이 있다. 멤버 테이블은 팀 테이블의 식별자를 PK에 포함하지는 않고, FK로 갖는다.

팀에 속해있지 않은(TEAM_SEQ를 FK로 갖지 않는) 멤버도 독립적으로 존재할 수 있다.

Cardinality

관계가 있는 엔티티 간 하나의 엔티티에서 다른 엔티티에 몇개의 개체와 대응되는 지에 따라 여러 종류가 존재한다.

1. 1:1 관계

2. 1:N 관계

3. M:N 관계

1:1 관계

하나의 엔티티에서 다른 엔티티에 대해 하나의 개체만 대응되는 관계이다.

<사례> 회원과 회원 정보 테이블. 회원 데이터 한개는 하나의 회원 정보 테이블 데이터와 매핑되기 때문에 1:1 관계이다.

1:N 관계

하나의 엔티티에서 다른 엔티티에 대해 2개 이상의 개체와 대응되지만, 반대 방향으로는 단일 개체만 매칭되는 관계이다.

<사례> 회원과 주문 테이블. 회원 데이터 한개는 2개 이상의 주문을 할 수 있지만, 주문 데이터 한개는 2개 이상의 회원과 연결될 수 없는, 1:N 관계이다.

M:N 관계

하나의 엔티티에서 다른 엔티티의 2개 이상의 개체와 대응되고, 반대 방향으로도 2개 이상의 개체와 대응되는 관계이다.

<사례>

주문과 상품 테이블. 주문 데이터 한개는 2개 이상의 상품 데이터를 갖을 수 있고, 상품 데이터 한개도 2개 이상의 주문 데이터와 대응될 수 있기 때문에 M:N 관계이다.

보통 M:N 관계는 1:M, N:1 관계로 풀어질 수 있도록 중간 테이블을 두는 것이 일반적이다. ex) 주문:상품 관계 (M:N)는 주문 : 주문_상품 = 1:M, 주문_상품 : 상품 = N:1 으로 구성.

필수/선택 관계

마지막으로 엔티티 간에는 필수 관계, 선택 관계가 있다.

필수 관계인 경우, 엔티티 내 개체가 생성될 때, 상대 엔티티에 대응되는 개체를 무조건 하나 가져야 한다. 그렇기 때문에 외래키(FK) 에는 Null을 허용하지 않는다.

선택 관계는 앤티티 내 개체가 상대 엔티티에 대응되는 개체 없이 독립적으로 존재할 수도 있다. (선택적인 관계) 이런 경우를 위해 외래키 (FK) 에 Null을 허용한다.

이러한 선택/필수 관계는 관계를 맺는 두 엔티티 입장에서 다를 수 있다.

<사례>

1) 고객 (부모) 과 주문 (자식) 관계

주문 데이터는 반드시 고객 데이터를 가져야 하지만 -> 자식 엔티티에게는 필수 관계

고객 데이터는 주문 데이터를 반드시 가질 필요는 없다. -> 부모 엔티티에게는 선택 관계

2) 할인 정책 (부모) 과 상품 (자식) 관계

상품은 할인 정책을 갖을 수 있지만, 필수는 아니다. -> 자식 엔티티에게는 선택 관계

할인 정책은 하나 이상의 상품에 적용될 수도 있고, 아닐 수도 있다. -> 부모 엔티티에게도 선택 관계

(할인 정책은 항상 적용될 상품이 있어야 한다는 개념을 적용한다면, 부모 엔티티에게는 필수 관계일 것이다.)

Spring Boot에서 비동기 처리 구현 (@Async, @EnableAsync)

뭉지(moonz) — Sun, 29 Jun 2025 18:11:20 +0900

비동기적인 방식은

A가 B에게 작업을 요청하고, B의 작업이 실행되는 것과 상관없이 A 자신의 작업을 이어서 진행하는 방식을 의미한다.

동기/비동기에 대한 구체적인 설명은 아래 글에 정리하였었다.

동기/비동기(Sync/Async), Blocking/Non-Blocking

시작하기에 앞서, 간단히 기준이 되는 용어를 보겠습니다.Blocking/Non-Blocking : '제어권'을 두고 구분동기/비동기 : 결과값을 기다리느냐로 구분 1. Blocking VS Non-Blocking : 제어의 관점요청한 작업이 전

thisisprogrammingworld.tistory.com

Spring Boot에서는 몇개의 애노테이션 설정만으로 비동기 방식을 구현할 수 있도록 제공한다.

- @EnableAsync, @Async 이용

1. 설정 클래스에 @EnableAsync 적용

@Configuration 애노테션이 붙은 설정 클래스에 적용해주어야 비동기 기능이 활성화된다.

보통 해당 클래스 내에 비동기 작업을 처리하는 스레드 풀에 대한 설정도 함께 해준다.

@EnableAsync
@Configuration
public class AsyncConfig {
    /*
    비동기 작업들 실행 시 사용될 Thread Pool
    모두 Default 값으로 설정
     */
    @Bean
    public Executor asyncThreadPoolExecutor() {
        ThreadPoolTaskExecutor executer = new ThreadPoolTaskExecutor();
        executer.setCorePoolSize(1);
        executer.setMaxPoolSize(Integer.MAX_VALUE);
        executer.setQueueCapacity(Integer.MAX_VALUE);
        executer.setThreadNamePrefix("AsyncThread-");
        executer.initialize();
        return executer;
    }
}

일반적으로, Spring 은 SimpleAsyncTaskExecutor 클래스를 사용해 비동기 처리를 수행한다.

다만, 아래 두가지 방법으로 오버라이딩할 수 있다.

애플리케이션 레벨에서 오버라이딩 : AsyncConfigurer 인터페이스를 implements하면서 getAsyncExecutor() 메서드를 오버라이딩하고, 이 메서드 내에서 원하는 구현체를 반환하도록 한다.
개별 메서드 레벨에서 오버라이딩 : @Async 애노테이션의 name 속성을 이용하여 특정 Bean 이름을 지정할 수 있다. 이 애노테이션이 붙은 메서드에서는 지정된 클래스에서 관리되는 스레드 풀을 이용하게 된다. ex) @Async("threadPoolTaskExecutor")

ThreadPoolTaskExecutor 는 일반 요청 시에는 사용되지 않는 스레드 풀이고

비동기 메서드를 수행할 때 (@Async를 적용하여 비동기 작업을 수행하려할 때, @EventListener를 적용한 비동기 이벤트 리스너가 수행될 때), 혹은 직접 이 Executor를 사용하겠다고 정의한 경우 사용된다.

Spring Boot 3.x 에서의 ThreadPoolTaskExecutor 설정 방법

Spring Boot 3점대 를 사용한다면, ThreadPoolTaskExecutor 를 직접 설정하지 않고 설정 파일에 입력하는 것만으로도 설정 가능하며, Spring Boot가 자동으로 관리해준다.

다만, 여러 스레드 풀의 설정을 해줘야한다면 별도 설정 클래스에서 빈을 등록해주는 것이 관리 측면에서 좋을 것으로 보인다.

# application.yml
spring:
  task:
    execution:
  pool:
    core-size: 5
    max-size: 10
    queue-capacity: 100
    thread-name-prefix: "Async-"

ThreadPoolTaskExecutor 클래스 에 대해 설정할 수 있는 값들은 아래와 같다.

spring.task.execution.pool.core-size: core thread 갯수. 가상 스레드가 활성화되어 있으면 의미 없음. (Default : 8)
spring.task.execution.pool.max-size: 늘릴 수 있는 최대 스레드 갯수. 큐가 가득 차버리면 (즉, 100개의 작업이 대기 중인 상황) 스레드 풀은 최대 16개까지 증가하도록 하여 부하를 수용할 수 있다. 다만 큐 용량이 무한대라면 무시되는 값이다. (Default : Integer 범위 최대 값)
spring.task.execution.pool.queue-capacity : 큐 용량. 이 용량이 무제한이라면, max-size 속성이 무시된다. (Default : Integer 범위 최대 값)
spring.task.execution.pool.keep-alive : 스레드가 회수되기 전 유휴 상태로 유지하는 시간 제한. 10초 설정하면, 10초 동안 유휴 상태가 유지되면 회수된다. (Default : 60s)

2. 비동기로 수행시키고 싶은 메서드에 @Async 적용

간략히 0부터 9까지 순회 출력하는 메서드를 작성하였다.

비동기 메서드는 public 접근제어자 로 구현되어야 한다.
- Spring에서는 AOP 기반의 프록시 패턴을 이용하여 프록시 객체를 통해 비동기 메서드에 접근한다.
  프록시 객체를 거치지 않고 직접 메서드를 호출할 경우 비동기적으로 동작하지 않는다.
- 물론 동일한 클래스 내부에서 해당 메서드를 직접 호출할 경우에도 비동기적으로 동작하지 않는다.
같은 맥락으로, 자기 호출 (self-invocation) 하는 경우에도 비동기적으로 동작하지 않는다.

@Component
public class AsyncTask {

    @Async("asyncThreadPoolExecutor")
    public void async() {
        for (int i=0; i<10; i++) {
            log.info("async() - {}", i);
        }
        log.info("2. async() Method Finished. (time: {})", LocalTime.now());
    }
}

위 메서드를 호출하는 테스트코드를 작성하여,

테스트 코드에서 async() 메서드를 호출 했을 때 async() 메서드 호출이 완료되기 전에

테스트 코드 내 다음 로직이 실행되는지 확인하였다.

@SpringBootTest
class AsyncTaskTest {
    @Autowired
    private AsyncTask asyncTask;

    @Test
    void async() {
        System.out.println("1. Before async() Calling : " + LocalTime.now());
        asyncTask.async();
        System.out.println("3. async() finished : " + LocalTime.now());
    }
}

동기적으로 처리된다면 1 > 2 > 3. 순으로 메세지가 출력되지만, 비동기로 처리되어 1 > 3 > 2. 순으로 메세지가 출력되는 것을 확인하였다.

참고

✍ 관련 Github Code

[AWS S3] Presigned URL과 생성 방식

뭉지(moonz) — Tue, 6 May 2025 13:45:22 +0900

서론

회사에서 개발하고 있는 서비스의 파일 저장소로써 AWS S3 서비스를 이용하려 하고 있다.
어드민 사이트에서 파일을 업로드하면, 대외 서비스에서 특정 고객들에게만 해당 파일 다운로드를 제공하는 서비스인데,
제한된 사용자에게만 파일을 제공하는 방법에 대해 고민하다 AWS 에서 제공하는 Presigned URL이란 방법을 알게 되었다.
Presigned URL을 서비스에 적용하기까지 알아본 내용들을 글로 정리해두려 한다.

Presigned URL

Presigned URL은 AWS S3에서 요청자의 권한을 제어하는데 제공하는 방법 중 하나이다.
Presigned URL은 접근 제어 정책을 따로 업데이트하지 않고도 URL을 통해 임시적으로 접근 권한을 제공하는 것이다. 사용자에게 접근권한을 부여하는 토큰인 셈이다.
S3에서 권한을 제어하는 방법들은 Presigned URL 외에도 IAM 사용자 정책, 액세스 포인트 등을 활용하는 방법들이 있다. 이 권한 제어 방법들은 별도 글에서 정리해보려 한다.

Presigned URL은 아래와 같이 생겼다.
https://<버킷명>.s3.<리전명>.amazonaws.com/<객체명>?response-content-disposition=inline&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Security-Token=<임시 인증 정보>&X-Amz-Algorithm=<서명 방식>&X-Amz-Credential=<AWS 인증 정보>&X-Amz-Date=20250506T043725Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host&X-Amz-Signature=<서명 값>

생성

Presigned URL을 생성할 때에는 아래 정보들이 필요하다.

버킷 명
객체 key (파일 경로와 파일 명)
요청하려는 HTTP 메서드 (다운로드는 GET, 업로드는 PUT, 객체의 메타 데이터 읽는 것은 HEAD)
URL 만료 시간
- AWS CLI 나 SDK로 URL을 생성한다면, 최대 7일까지 유효 기간을 설정할 수 있다.
- 만약 Presigned URL의 생성자의 권한이 수정/삭제/비활성화 처리 되면, 생성자의 Credentials로 만든 Presigned URL도 만료 된다.

생성된 Presigned URL을 받은 사용자는 제한 없이 Presigned URL을 이용해 특정 Operation을 할 수 있지만, URL 을 생성하려는 유저가 갖고 있는 Operation에 제한된다.
예를 들어, 버킷 A에 대해 파일 읽기 권한만 있는 생성자는 버킷 A에 대한 파일 읽기 작업을 수행하는 Presigned URL만 생성할 수 있고, 쓰기 작업을 수행하는 Presigned URL은 생성할 수 없다.

방법 1) SDK를 이용한 Presigned URL 생성

애플리케이션에서 AWS SDK를 이용해 Presigned URL을 생성하는 방법이다.
이 방법은 자격 증명을 거치고 나면 따로 AWS S3 와 통신하지 않고도 애플리케이션에서 Presigned URL을 생성할 수 있는 방법이다.
네트워크 통신을 하지 않아도 된다는 점이 좋다.

소스코드

Import (gradle) :

    implementation(platform("software.amazon.awssdk:bom:2.27.21"))
    implementation("software.amazon.awssdk:s3")

AWS 자격 증명 값 세팅 방법 3가지 :
만약 접근하려는 버킷/파일의 접근 제어 정책이 세팅되어 있다면
Presigned URL을 생성하는 역할의 객체를 Bean으로 등록할 때 인증/인가를 체크하기 위해
해당 버킷/파일의 Operation 권한이 있는 계정의 Credentials 정보를 세팅해야한다.
AWS Credentials 정보를 세팅하는 방법은 3가지가 있다.

1. 기본 AWS 자격 증명 파일 (루트/.aws/credentials)에 설정된 AWS 자격 증명 값을 사용하여 인증하는 방법

<루트 경로>\.aws\credentials 파일에 아래 정보를 넣어준다.

[default]
aws_access_key_id = <버킷의-access-key>
aws_secret_access_key = <버킷의-secret-key>

소스코드에서는 ProfileCredentialsProvider 객체를 생성하면서 위 credentials 파일에 작성한 프로파일 값 ('default') 을 지정한다.

@Configuration
public class AwsS3Config {
	@Bean(name = "s3Presigner")
    public S3Presigner s3PresignerWithCredentialFiles() {
        return S3Presigner.builder()
                .region(Region.of(region))
                .credentialsProvider(ProfileCredentialsProvider.create("default"))
                .build();
    }
}

2. 설정 파일 (application.yaml 혹은 application.properties)에 설정된 AWS 자격 증명 값을 사용하여 인증하는 방법

다만, 설정 파일에 Access Key와 Secret Key를 직접 노출하여 세팅하는 것보다는 환경변수로 대체하는 것이 보안 상 안전하다.

@RequiredArgsConstructor
@Configuration
public class AwsS3Config {
	@Value("${amazon.s3.access-key}")
    private String accessKey;
	@Value("${amazon.s3.secret-key}")
    private String secretKey;
	@Value("${amazon.s3.region}")
    private String region;		// ex: "ap-northeast-2"

    @Bean(name = "s3Presigner")
    public S3Presigner s3PresignerWithStatic() {
        AwsBasicCredentials awsCredentials = AwsBasicCredentials.create(accessKey, secretKey);
        return S3Presigner.builder()
                .region(Region.of(region))
                .credentialsProvider(StaticCredentialsProvider.create(awsCredentials))
                .build();
    }
}

3. 운영 체제의 환경 변수에 설정된 AWS 자격 증명 값을 사용하여 인증하는 방법

자격증명 정보를 세팅한 AWSStaticCredentialsProvider 객체를 AmazonS3ClientBuilder에 전달하여 빌드한다.

@Configurations
public class AmazonConfig {
	@Value("${amazon.s3.access-key}")
    private String accessKey;
	@Value("${amazon.s3.secret-key}")
    private String secretKey;
	@Value("${amazon.s3.region}")
    private String region;		// ex: "ap-northeast-2"

	@Bean
    public AmazonS3 awsS3Client() {

        BasicAWSCredentials basicAWSCredentials = AwsBasicCredentials.create(accessKey, secretKey);
        ClientConfiguration clientConfiguration = new ClientConfiguration();
        clientConfiguration.setProtocol(Protocol.HTTPS);
 
        return S3Client.builder()
                .region(region)
                .credentialsProvider(StaticCredentialsProvider.create(basicAWSCredentials))
                .clientConfiguration(clientConfiguration)
                .build();
    }
}

만약 Access Key가 잘못되거나 Secret Key가 잘못되어 세팅되면 403 상태 코드와 함께 아래와 같은 에러 코드를 반환받는다.

InvalidAccessKeyId : Access Key를 잘못 세팅한 경우
SignatureDoesNotMatch : Secret Key를 잘못 세팅한 경우
Access Denied : 권한이 없는 경우 (Presigned URL이 만료된 경우 등 여러 권한에 문제되는 상황에서 반환된다.)

SDK 통한 생성 메서드 (java) :
GET 요청을 할 수 있는 Presigned URL을 생성하는 로직이다. S3Presigner 객체를 이용한다.

위에서 언급했던 버킷명, 객체명, 유효 시간, 요청 메서드 를 입력한다.

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import software.amazon.awssdk.services.s3.model.GetObjectRequest;
import software.amazon.awssdk.services.s3.model.S3Exception;
import software.amazon.awssdk.services.s3.presigner.S3Presigner;
import software.amazon.awssdk.services.s3.presigner.model.GetObjectPresignRequest;
import software.amazon.awssdk.services.s3.presigner.model.PresignedGetObjectRequest;
import software.amazon.awssdk.utils.IoUtils;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.HttpURLConnection;
import java.net.URL;
import java.time.Duration;

@Slf4j
@Service
@RequiredArgsConstructor
public class AmazonS3Utils {
    private final S3Presigner s3Presigner;

    /* Create a pre-signed URL to download an object in a subsequent GET request. */
    public String createPresignedGetUrl(String bucketName, String keyName) {
        GetObjectRequest objectRequest = GetObjectRequest.builder()
                .bucket(bucketName)
                .key(keyName)
                .build();
        GetObjectPresignRequest presignRequest = GetObjectPresignRequest.builder()
                .signatureDuration(Duration.ofMinutes(10))  // The URL will expire in 10 minutes.
                .getObjectRequest(objectRequest)
                .build();

        PresignedGetObjectRequest presignedRequest = s3Presigner.presignGetObject(presignRequest);

        log.info("Presigned URL: [{}]", presignedRequest.url().toString());
        log.info("HTTP method: [{}]", presignedRequest.httpRequest().method());

        return presignedRequest.url().toExternalForm();

    }

방법 2) AWS Lambda를 이용한 Presigned URL 생성 (feat. python - boto3 라이브러리)

Presigned URL 생성 로직을 애플리케이션에서 하지 않고 AWS 에서 제공하는 Lambda 를 이용할 수 있다.
AWS Lambda는 서버를 프로비저닝하고 관리하는 것 없이 코드를 실행시킬 수 있도록 제공하는 AWS 서비스이다. (지원하는 언어는 Node.js, Python, Ruby, Typescript, Java, Go, C# 이다.)
Lambda는 필요할 때 함수를 실행시키고, 트래픽에 따라 자동 확장을 지원하기 때문에
실시간 처리가 필요한 기능에서 유용하게 사용된다.
우리 팀에서 Presigned URL 생성 로직 실행을 애플리케이션이 아닌 Lambda 서비스를 이용하게 된데에는 아래 세가지 정도의 이점이 있었다.

중앙 집중화

이번에 생성하는 S3 버킷은 여러 유관 부서 혹은 서비스에서도 호출할 가능성이 있다.
그래서 사용자의 권한 관리를 쉽게 하는 것 등 앞으로의 운영 편의성도 고려해야 했다.
별개로 Lambda 함수를 실행시키기 전, 호출 서비스들에 대한 검증 절차도 필요했는데
AWS의 API Gateway 를 이용하여 API Gateway에서 해당 요청을 검증하는 Authorizer 를 등록해 이를 수행하도록 했다.
Authorizer에는 다양한 인증 처리 방식을 사용할 수 있는데,
이번에 만드는 버킷의 경우, 요청 서비스들이 공통적으로 사용자 토큰 (jwt 토큰)을 가지고 있었기 때문에 JWT 토큰을 검증하는 로직을 Authorizer로 등록하여 요청 클라이언트를 인증하는 방식도 통일하였다.
Authorizer도 Lambda 로 구현하였다.

다만, 나의 상황과 달리
호출하는 서비스마다 인증하는 방식이 상이하다면, 인증 절차를 위한 Authorizer Lambda 함수를 서비스 갯수만큼 추가해야할 수 있다.

2. 보안 강화 (보안 중앙 관리)
S3 버킷에 접근해야하는 여러 사용자(부서/서비스) 별 IAM 정책을 생성해주어야 하는데,
S3 버킷의 Presigned URL을 생성하는 주체를 Lambda로 제한하게 되면 각 사용자 (부서/서비스)마다 IAM 권한을 부여/관리 하지 않아도 된다.
그리고 이를 사용하고자 하는 서비스들은 해당 Lambda를 호출할 수 있는 JWT 토큰만 갖고 있으면 된다.

3. 유지보수 용이: Presigned URL 생성 로직을 한곳에서 관리하면,
여러 서비스에서 중복으로 로직을 개발해야 하는 부담을 줄일 수 있고
Presigned URL 생성 로직을 수정하거나 인증 방식을 수정해야할 때 Lambda 함수에서만 수정하면 된다는 점에서 유지보수가 용이해진다.

4. 로깅 용이 : Presigned URL을 생성하며 발생하는 이슈에 대해 모니터링 시에는 CloudWatch Logs로 중앙 관리/확인할 수 있다.

Lambda 함수 코드 내에서 출력하는 로그는 자동으로 CloudWatch Logs에 전송된다.

결론적으로, 호출자 검증 및 권한 관리를 위한 Authorizer 함수와 S3 Presigned URL 생성 함수를 Lambda에 등록하였다.

물론 Lambda 서비스를 사용할 때 고려해야할 점들도 존재한다.

Lambda 서비스 사용 시 고려해야할 단점.

Cold Start

Lambda 서비스는 외부 트리거에 의해 Lambda 인스턴스가 함수를 실행하는 방식으로 동작하는데,
만약 인스턴스가 없거나, 기존 인스턴스가 만료되었다면, 함수 인스턴스를 생성하면서 컨테이너 준비, 초기화 작업을 거치는 과정을 수행해야 한다.
이로 인해 사용자 응답에 지연이 발생하게 된다.
특히 요청이 갑자기 몰렸을 때에는 이를 처리하기 위해 신규 인스턴스들을 생성하고 이때에도 초기화 작업을 수행하게 된다.

2. 제한된 환경 (실행 시간, 메모리 사용량, 환경 변수 크기)

Lambda 로 함수를 실행하는 것에는 몇가지 제한이 있다.
실행 시간은 최대 900초로 제한되고, 메모리도 본인이 설정한 값으로 제한되기 때문에 함수가 실행되는 동안의 메모리 사용량도 확인해야 한다.
Lambda는 환경 변수를 사용하여 함수에 설정 정보를 제공하는데, 제한 크기가 4KB이다.
그래서 Lambda 로 실행시키고자 하는 로직이 실행 시간이 너무 소요되거나, 많은 메모리를 필요로 한다면 Lambda를 사용하기 어렵다는 문제가 있다.

나의 선택은,

결론적으로 우리가 방법 2를 선택한데에는 아래와 같은 배경도 고려하였기 때문에, 운영하는 서비스와 팀의 상황에 맞게 다른 선택을 할 수 있을 것이다.

Lambda 서비스를 사용하면 결국 네트워크도 타고, 비용도 발생하는 것이기 때문에 개인적으로는 방법 1) 이 낫지 않을까 란 생각이었는데
현재 요청 트래픽 수준에서는 비용이 감당 가능하며,
여러 서비스에서 중복 구현해야하는 이슈를 해결하는 것에 더 의의를 두고자 한다는 DevOps의 의견에 따르기로 했다.
팀 내 DevOps에서 S3 서비스를 관리하는데, 여러 서비스가 호출할 버킷이다보니 관리/운영을 쉽게하고자 하는 니즈도 있었다.
제공할 서비스가 Cold Start 이슈를 고려할만큼 사용자 트래픽이 한번에 다량으로 발생하지는 않는다는 점도 이유이다.

추가) 서비스 구성 : API Gateway + Lambda

AWS의 API Gateway 서비스는 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스이다.
우리 팀에서는 AWS API Gateway를 구성하여, AWS Lambda 서비스를 호출하는 요청을 검증하는 Authorizer를 추가하였다.
이외에도 기본적으로 설정된 공통 응답을 제공하고 (‘게이트웨이 응답’ 메뉴에서 확인 가능하다.) 사용량을 제어할 수 있는 등 기본적으로 게이트웨이에서 수행하는 기능들을 제공한다.

<참고 이미지: API Gateway 를 Lambda 서비스의 트리거로써 연동>

Cloud Front까지 구성한다고 하면 아래와 같은 모습이 될 수 있다.

전체 구성도이다.

인증 없이 접근 가능한 버킷과 인증을 통해서만 접근 가능한 버킷을 자물쇠로 구분하였다.

[Nginx] 파일 접근 시 Permission denied 오류 해결

뭉지(moonz) — Tue, 25 Feb 2025 21:05:53 +0900

nginx를 설치하고 실행해보는 작업을 진행하는 중에 발생한 오류이다.

문제 상황

서버 내 특정 경로에 있는 이미지를 가져올 수 있도록 nginx에서 루트 경로 설정을 한 뒤 브라우저에서 해당 이미지를 조회하니, 아래와 같이 403 에러가 발생하였다.

파일명도 잘못 조회한거였지만, 미리 준비해놓은 에러 화면이 아닌 403 화면이 나온 것이다.

✍ 접근 방식

nginx의 error.log 파일을 확인해보니 아래와 같이 Permission Denied 가 출력되어있다.

[error] 7781#0: *18 open() "/nas/error.html" failed (13: Permission denied), client: {접근 IP}, server: {접근 Host}, request: "GET /favicon.ico HTTP/1.1", host: "{서버 IP}", referrer: "https://{서버 IP}/3907131079.png"

로그에서는 /nas/error.html 파일을 열려고 했는데, Permission denied 이슈로 이 파일을 여는데 실패했다고 말하고 있다.

사용자가 요청한 3907131079.png 를 조회하려했는데, 해당 디렉토리에 파일이 없어서 nginx 설정 파일에서 설정한 에러 파일 error.html 을 로드하려고 그 에러 파일에 접근하니 시스템에서 권한 이슈로 거부를 한것으로 최종 파악하였다.

Permission Denied 이니, 디렉토리 혹은 파일의 권한 문제로 유추하였다.

접근하려한 파일과 디렉토리를 확인하다보니

해당 파일의 루트 디렉토리의 소유자가 root 임을 확인하였다.

그런데 Nginx는 user1 라는 계정으로 동작 중이었다.

**Nginx 실행 유저는 nginx 설정 파일에서 확인할 수 있다. (파일명 : nginx.conf)

$ cat nginx.conf
user  user1;    # user1로 설정해둔 것 확인.
worker_processes  4;
...생략

디렉토리/파일의 소유자는 'll' 명령어만으로도 확인 가능하다.

⭐️ 해결

루트 디렉토리의 소유자를 nginx가 실행되는 계정으로 변경하였다.

그리고 파일 소유자에 대해 쓰기, 읽기, 실행할 수 있도록 권한을 설정하였다.

$ chmod user1:user1 -R {루트 경로}
$ chown 755 -R {루트 경로}

다시 존재하지 않는 경로를 호출해보니 error.html 파일이 정상 로드되는 것을 확인하였다.

결과

원인은 nginx에서 루트로 설정한 디렉토리들의 권한은 root:root로 부여되어 있는데 nginx 실행 유저는 user1로 설정해두었기 때문에

루트 디렉토리 하위에 있는 파일에 접근하려하여 문제가 된 것이다.

루트 디렉토리의 파일 소유자를 nginx 실행 계정과 동일하게 지정하고,

파일 소유자에 대해 파일 쓰기/읽기/실행 권한을 부여하여 해결하였다.

Cookie (feat. JWT Token, SSO)

뭉지(moonz) — Sun, 7 Jul 2024 14:53:50 +0900

사용자 인증 토큰을 쿠키 스토리지에?

단일 서비스의 사용자 인증 기능을 위해 동작하던 "사용자 인증 애플리케이션"에서

다수 서비스의 사용자 인증 기능을 제공하는 서버로 동작해야함과 동시에

해당 서버를 통해 인증된 사용자는 사내 다른 서비스에 접속시에도 로그인 상태를 공유해야했기 때문에 SSO 기능까지 가능하도록 구현해야했습니다.

어떤 방식으로 구현할 지 고민한 내용 중 JWT 토큰을 저장할 위치와 관련하여 "쿠키" 에 대해 알아본 내용들을 정리합니다.

SSO 기능을 제공하려면 크게 두가지 요구사항이 있었습니다.
1) 로그인 후, 새 탭에서 접속했을 때에도 로그인이 되어야 한다.

2) 서브 도메인이 같으면 인증 토큰이 공유되어야 한다. (단, 다른 서브 도메인에 접속 시에는 쿠키가 전달되지 않는다.)

기존 "사용자 인증 애플리케이션"은 사용자 인증 과정을 거치고 나면 JWT를 발급해주고 있었습니다. body에 토큰을 담아 응답하면 Frontend에서 이를 세션 스토리지에 저장하고 있었어요.

잠시 세션 스토리지와 로컬 스토리지, 그리고 쿠키에 대해 알아보겠습니다.

Session Storage

특징

간단한 key-value를 저장하는 스토리지입니다.
말그대로 브라우저 세션 동안만 데이터가 유지됩니다.
탭 간에도 공유되지 않기 때문에 같은 브라우저라도 다른 탭을 띄우면 데이터는 공유되지 않습니다.
브라우저 또는 탭을 닫으면 데이터가 삭제됩니다.

활용

세션 스토리지는 브라우저 탭 내로 제한되기 때문에 잘 활용되지 않습니다.

잠시 필요한 정보 (일회성 로그인) 같은 데이터는 저장할 수도 있습니다.

Local Storage

특징

간단한 key-value를 저장하는 스토리지입니다.
세션 스토리지와 유사하지만, 오리진(domain/port/protocol)이 같으면 (동일 출처 내의) 모든 탭에서 데이터가 공유됩니다.
- 호스트 : https://www.example.com의 로컬 스토리지 데이터는 https://api.example.com과 공유되지 않습니다.
- 프로토콜 : http://example.com에서 저장한 로컬 스토리지 데이터는 https://example.com과 공유되지 않습니다.
- 포트 번호 : https://example.com:8080에서 저장한 로컬 스토리지 데이터는 https://example.com:3000과 공유되지 않습니다.
브라우저를 종료하거나 OS를 재시작해도 데이터가 삭제되지 않습니다.

활용

지속적으로 필요한 데이터 를 저장하는데 활용됩니다.

세션 스토리지와 로컬 스토리지보다 먼저 나왔던 기능이 쿠키 입니다.

Cookie

특징

HTTP Cookie는 세션 스토리지/쿠키 스토리지와 다르게 데이터를 저장할 때 만료 기한을 정할 수있습니다.
웹사이트에 접근하는 디바이스에 Cookie가 저장되며, 여러 개의 Cookie가 저장될 수 있으나 4kb라는 용량 제한이 있습니다.
Cookie는 브라우저 단위로 생성됩니다. 즉 Chrome, Explorer, Edge, Safari, FireFox, Opera 등 서로 다른 브라우저에서 생성된 Cookie는 서로 다른 것으로 인식됩니다.
요청을 할 때마다 서버로 저장된 Cookie도 함께 전달되기 때문에 그중 필요하지 않은 데이터들이 있다면 용량을 불필요하게 낭비하게 됩니다.
서버로 전송되지 않아도 되는 데이터들은 로컬/세션 스토리지에 저 장하는 것입니다.

활용

HTTP 요청 자체만 보낼 때에는 서버가 누구인지 알 수 없습니다.

하지만 Cookie에 내가 누구인지 담아서 서버에 요청을 보낼 때 함께 전달하면 서버는 Cookie를 읽어서 요청자가 누구인지 파악합니다.

이처럼 Cookie는 웹 서버가 사용자의 기기에 'stateful'한 정보를 저장할 수 있도록 하기 때문에

온라인 쇼핑몰에서 고객의 장바구니에 아이템을 추가한 상태 정보를 저장하거나 '일주일간 다시보지 않기'와 같은 기능에 사용되는 등 "사용자의 브라우저 활동을 트래킹"하는데 활용됩니다.

그리고 제가 Cookie를 사용하고자 하는 목적이기도 한,

웹서버에서 사용자가 로그인했는지, 그들이 어떤 계정으로 로그인했는지를 "인증"하는데에도 사용될 수 있습니다.

사용자가 인증을 거치고 나면 Cookie에 정보를 저장함으로써 사용자가 민감한 정보를 포함한 페이지 각각에 접근할 때 마다 로그인을 통해 스스로를 인증해야 하는 불편함을 없앨 수 있습니다.

최종적으로, 하위 도메인 간 값이 공유되어야 하기 때문에, 이를 지원하는 쿠키를 선택했습니다. (쿠키는 하위 도메인이 동일하면 공유가 가능합니다.)

또한 새 탭으로 로그인했을 때 쿠키 스토리지 내 값은 사라지지 않는다는 특징이 있었습니다.

그래서 쿠키에 JWT 토큰을 저장하는 방식으로 시도해보기로 하였습니다.

다만 쿠키에 값을 저장하면 서버에 요청을 보낼 때 자동으로 값이 전송되기 때문에 보안 공격에 취약합니다.

또한 쿠키에 값을 저장할 때 얼마나 값을 유지할지도 설정할 수 있는데요 이 기간도 길게 설정한다면 보안적으로는 더 취약하겠죠.

그래서 쿠키를 적용하면서 최대한 보안에 취약하지 않는 방안이 있을지 찾아보았습니다.

그 과정에서 알게된 쿠키의 옵션들은 아래와 같습니다.

Cookie의 옵션 종류

Cookie에 값을 저장할 때는 다양한 종류의 옵션을 함께 지정할 수 있는데, 이 옵션들을 통해 브라우저에서 정보가 저장되고 공유될 수 있는 상태를 제한할 수 있습니다.

Max-Age

Cookie가 브라우저에 유 지되는 최대 설정 옵션 (단위 : second)

-1로 세팅 시 브라우저가 종료될 때까지 유지되는 Cookie가 생성된다. (일명 '세션 쿠키')

Expires

쿠키가 만료되는 날짜를 설정하는 옵션
- 'Session' 이라는 값으로 세팅 시 브라우저 종료될 때까지 유지되는 Cookie가 생성된다. (일명 '세션 쿠키')

Session cookie 와 Persistent cookie
1. Session Cookie
인메모리 쿠키라고도 알려져있는 세션 쿠키는 메모리에 저장됩니다.
사용자가 웹사이트를 돌아다닐 동안 즉, 브라우저 세션 동안만 일시적으로 존재합니다.
결국 웹 브라우저를 닫으면 자동으로 삭제되는 것이 가장 큰 특징입니다.
그렇기 때문에 아래에 나올 Persistent cookie (지속성이 있는 쿠키) 보다 보안 측면에서 유리합니다.
반면 Persistent cookie는 말 그대로, 브라우저에 오랜 기간 저장되기 때문에 그만큼 공격에 노출될 가능성이 높습니다.

세션 쿠키로 세팅하기 위해서는 쿠키의 유효 시간을 지정하는 쿠키의 옵션인 Expires 옵션을 'Session'으로 세팅하거나 Max-Age 옵션을 -1로 사용하면 됩니다.
사용자가 브라우저를 닫을 때 무조건 쿠키에 저장한 정보가 초기화되어야 한다면 세션 쿠키를 사용하면 된다.

2. Persistent Cookie
지속성이 있는 쿠키는 특정 일자나 기간에 만료되는 쿠키입니다.
Persistent cookie는 디스크에 저장되기 때문에, 브라우저를 닫거나 컴퓨터를 재시작하더라도 남아있게 된다.
이러한 기능 덕분에,
사용자가 브라우저를 닫고 다시 재접속했을 때에도 이전에 등록했던 정보들을 저장하고 있어 사용자가 재접속했을 때 로그인을 유지시켜주는데 쓰이기도 합니다.

앞서 말한 대로, Persistent cookie는 Session cookie보다 공격에 노출될 가능성이 높기 때문에 보안에 도움이 되는 여러 옵션들과 함께 생성하길 권장하고 있습니다.

Secure

해당 옵션이 설정되면, 쿠키가 암호화된 연결 간에만 전달될 수 있도록 하고 암호화되지 않은 연결 간에는 전달되지 못하도록 합니다. HTTPS가 대표적입니다.

이를 통해, 네트워크 도청 (스니핑/스누핑 공격) 으로 인해 쿠키가 도난당할 가능성을 줄여줍니다.

Http-only

해당 옵션이 설정되면, Javascript와 같은 클라이언트 사이드에서 접근할 수 없게 됩니다.

이러한 제한은 XSS 공격으로부터 막아주는 효과가 있습니다.

XSS 공격 (Cross Site Scripting, XSS) 이란?
공격자가 웹 페이지에 악의적인 스크립트를 삽입하여, 사용자의 브라우저에서 실행되게 만드는 공격입니다.
이를 통해 공격자는 사용자의 세션 쿠키를 탈취하거나, 사용자를 가장하여 악의적인 행위를 수행할 수 있습니다.

기본적으로 Cookie는 Javascript를 통해 조회 가능한데, 쿠키를 HttpOnly 설정하면 이를 막을 수 있는 효과가 있습니다.

하지만 HttpOnly 옵션을 설정하면 서버에서만 쿠키를 읽을 수 있기 때문에 한번 이상의 서버로의 API 호출이 불가피합니다.

즉 클라이언트 측에서 쿠키 값을 확인하거나 수정하는 작업이 불가능합니다. 이러한 단점을 감수하더라도 보안을 위해 HttpOnly 옵션을 사용하는 것이 안전합니다.

Same-site

Same-site 옵션은 쿠키를 전달할 수 있는 정도를 제한하는 옵션입니다.

상태는 총 세가지로 설정할 수 있습니다. Strict / Lax / None

- Strict

브라우저는 하위 도메인이 같은 도메인으로만 쿠키를 전달할 수 있도록 제한합니다. 즉 퍼스트(first) 쿠키만이 전달됩니다.

blog.naver.com 과 map.naver.com 은 하위도메인이 .naver.com 으로 같기 때문에 쿠키를 공유할 수 있습니다.

이는 CSRF 공격에 방지하는데 도움이 됩니다.

CSRF 공격이란?
CSRF 공격은 사용자가 로그인한 상태에서 공격자가 준비한 악의적인 요청을 서버에 전송하게 만듭니다. 이 과정에서 사용자는 자신도 모르는 사이에 공격자가 의도한 행위를 실행하게 됩니다.
SameSite 쿠키 속성을 설정하면, 하위 도메인이 동일한 곳으로만 쿠키를 전달하도록 제한하여 쿠키가 의도치 않은 곳으로 전송되는 것을 막을 수 있습니다.

- Lax

브라우저는 하위 도메인이 같은 도메인으로 쿠키를 전달할 수 있을 뿐만 아니라

하위 도메인이 다른 도메인에도 쿠키를 전달할 수 있지만, 이때는 서버의 상태를 바꾸지 않을 것이라 기대하는 요청(ex. GET 메서드) 시에만 가능합니다.

또한 다른 출처의 요청인 third-party 쿠키 는 전달 불가합니다. 다만 예외적으로 Top Level Navigation (웹 페이지 이동) 의 경우 유저가 링크를 누르거나 리다이렉트를 통해 이동된 경우에는 third-party 쿠키가 전달됩니다.

ㄴ <img> 태그나 <iframe> 태그 내에서 페이지를 이동하는 경우에는 Top Level 이라 부를 수 없으므로 전송되지 않습니다.

- None

동일한 하위 도메인이든, 다른 도메인이든 상관없이 쿠키가 전달 됩니다.

단, None으로 하려면 무조건 쿠키의 Secure 옵션을 true로 설정해야 정상 전송됩니다.

ㄴ 만약 SameSite 속성을 None 으로 설정했음에도 Secure 속성이 false라면 쿠키가 전달되지 않습니다.

크롬 브라우저는 2020년 2월 배포된 80버전부터 same-site 옵션의 기본값을 Lax로 설정했습니다.

HSTS (HTTP Strict Transport Security)

보안에 취약하지 않게 하는 또다른 방법으로, HTTPS를 강제하는 기술이 있습니다.

HSTS는 브라우저와 웹 서버 간 통신 시에 무조건 HTTPS 통신만 할 수 있도록 강제하는 기술입니다.

이용자가 웹 서버에 처음 접속할 때, 응답 헤더에 Strict-Transaport-Security 헤더를 내려보내서

HSTS를 지원하는 브라우저라면 이를 해석하고 추후 접속 부터는 해당 도메인에 대해 HTTPS 로만 접속합니다.

만약 브라우저에서 HTTP 접속이 시도되면

HTTP 응답 코드 302를 이용해 페이지 이동(redirection)이 일어나면서 강제로 HTTPS로 프로토콜을 변경시킵니다.

HSTS 설정 시 지정할 수 있는 값이 3개 있습니다.

설정	값	설명
max-age	31536000 (s) -> 1년	해당 시간동안 HSTS 응답을 받은 웹 사이트에 대해 HTTPS 접속을 강제함.
includeSubDomains	true	HSTS가 적용될 도메인의 서브 도메인까지 적용되고 있음을 알려줌.
preload	true	브라우저의 Preload List에 도메인 추가할 것을 알려줌.

응답 헤더에 설정된 모습 :

Strict-Transport-Security: max-age=31536000; includeSubDomains ; preload

네이버를 예로 봐보겠습니다.

www.naver.com 호출 시 응답 헤더 내에 Non-Authoritative-Reason: HSTS 라는 세팅과 함께 응답을 받고 (사진)

그 후 바로 https로 리다이렉트 됩니다. (초록색 Network)

HSTS Preload List

HSTS Preload List는 HSTS가 적용된 웹 사이트의 명단 정보에 대한 리스트 입니다.

본인의 서비스에 HTTPS 적용을 한 후 HSTS Preload List에 등록하면,

이용자가 서비스에 처음 접속하는 브라우저에서부터 HTTPS로 접속하게 할 수 있습니다.

다만 등록하기 위해 준수해야하는 가이드가 있고,

가입 후 SSL 보안인증서 만료 등과 같이 가이드를 지키지 못하는 이슈가 있을 때 사이트가 접속이 안될 수 있다는 점,

추후 해당 리스트에서 삭제하고자 할 때 진행이 오래 걸린다는 점 등에서

따로 HSTS Preload List에 등록하지는 않았습니다.

네이버의 경우도 최초에 접속 시 http에서 https로 리다이렉트되는 것을 보면 알 수 있듯, HSTS Preload List에 등록되지 않은 상태입니다.

우측은 HSTS Preload List에 등록된 페이스북.

참고

끝.

[SQL, 프로그래머스] 주문량이 많은 아이스크림들 조회하기

뭉지(moonz) — Sun, 16 Jun 2024 15:54:36 +0900

Lv4 '주문량이 많은 아이스크림들 조회하기' 문제를 풀어보았습니다.
구체적인 프로그래머스 문제는 링크 참고 바라며, 문제는 간략히 설명합니다.

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

사용할 테이블 정보

두 테이블 모두 아이스크림 가게의 주문 정보를 담은 테이블입니다.
first_half 테이블은 상반기의 아이스크림 주문 정보를 담은 테이블. (flavor 칼럼이 기본 키, shipment_id 칼럼이 july 테이블의 shipment_id의 외래 키)
july 테이블은 7월의 아이스크림 주문 정보를 담은 테이블입니다.

7월에는 워낙 아이스크림 주문량이 많아서 같은 아이스크림 맛이지만, 다른 두 공장에서 아이스크림 가게로 출하를 진행하는 경우가 있습니다.
즉, 같은 맛일지라도 출하 번호가 다른 데이터가 존재합니다.

두 테이블 모두 출하 번호, 아이스크림 맛, 총 주문량 칼럼을 갖고 있다.

생각의 과정

두 테이블을 합쳐서 아이스크림 맛의 총 주문량을 조회해야 한다.

두 테이블을 JOIN 하고, 이때 ON 절에는 flavor 칼럼으로 조건을 걸어야겠다.

july 테이블은 flavor가 중복인 케이스가 있으니 GROUP BY flavor를 통해

SQL 쿼리 작성 (MySQL)

SELECT flavor
FROM (
    SELECT first_half.flavor, SUM(first_half.total_order) + SUM(july.total_order) AS sum_total_order
    FROM first_half
    JOIN july
    ON first_half.flavor = july.flavor
    GROUP BY flavor
) AS total
ORDER BY sum_total_order desc
LIMIT 3
;

다른 방식의 쿼리문 (MySQL)

수정 내용

JOIN 대상 테이블을 미리 GROUP BY한 july 테이블을 조인 대상으로 걸었다.
총 주문량의 합을 SELECT 대상으로 두지 않고 ORDER BY절에서만 사용하도록 했다.

SELECT j.flavor
FROM first_half
JOIN (
    SELECT flavor, SUM(total_order) AS total_order
    FROM july
    GROUP BY flavor
) AS j
ON first_half.flavor = j.flavor
GROUP BY flavor
ORDER BY first_half.total_order + j.total_order desc
LIMIT 3;

필요한 지식

JOIN, SUM, GROUP BY, ORDER BY, LIMIT

예외(Exception) 처리

뭉지(moonz) — Fri, 14 Jun 2024 16:53:33 +0900

적절한 예외 핸들링은 애플리케이션에 필수적이지만 생각보다 중요성을 간과할 수 있는 부분이라 생각합니다.
이 글에서는 예외를 다룰 때마다 고민했던 포인트들과 예외를 처리하고 생성하는 Best Practice에 대해 정리합니다.

1) 예외 처리 (Handling Exceptions) 할 때

메서드가 에러로 인해 완료되지 않았을 때 상태를 복구한다.

메서드에서 예외가 발생했을 때, 호출자는 부작용이 없다고 가정할 수 있어야 합니다.

계좌 이체 코드 (한 계좌에서 출금하고 다른 계좌에 입금하는 코드)를 예로 들면,

출금 로직은 정상적으로 성공했는데 입금 로직에서 예외가 발생하면, 출금이 그대로 완료되지 않도록 해야 합니다.

이를 위해 처리할 수 있는 방안은, 입금 거래 과정 중 한 곳이라도 예외가 발생하면 그전에 정상적으로 완료한 출금을 롤백하도록 하는 것입니다.

롤백 방식은 코드의 상황에 따라 다를 수 있겠지만, 여기에서는 try-catch문의 catch문에서 롤백 처리하도록 하겠습니다.

입금 로직을 try 문으로 감싸고 예외가 발생하면 catch 문에서 출금을 롤백한 후에, 예외를 던지도록 합니다.

이때 예외는 새로 정의한 커스텀 예외를 던지면서 원래 예외를 내부 예외에 포함키도록 하였습니다.

private static void TransferFunds(Account from, Account to, decimal amount) {
    String withdrawalTrxID = from.withdrawal(amount);
    try {
        to.deposit(amount);
    }
    catch (Exception ex) {
        from.RollbackTransaction(withdrawalTrxID);
        throw CustomException(ex);
    }
}

예외를 적절하게 잡아서 다시 던진다.

예외가 발생하면, 그 정보들의 일부가 스택 트레이스 (Stack trace)에 담깁니다.

스택 트레이스는 예외를 발생시킨 메서드에서 시작해서 예외를 잡는 메서드에서 끝나는,

메서드의 호출 계층 목록입니다.

즉, 어디에선가 예외가 발생했는데

그 예외를 잡을 때, 기존 예외의 정보를 담지 않고 새로운 예외로 다시 던지게 되면

스택 트레이스가 현재 메서드에서 다시 시작되기 때문에

예외를 처음 던진 원래 메서드와 현재 메서드 사이의 스택 트레이스 (메서드 호출 목록)이 사라지게 됩니다.

결국! 발생한 Exception의 Stack trace 정보를 유지하려면 기존 Exception을 인자로 전달해야 하는데,

이 내용은 아래 3-2에서 다시 다루겠습니다.

"예외를 잡아서 다시 던질 때는 기존의 예외 정보도 함께 포함시켜 던져야 한다"가 포인트입니다.

2) 예외 발생 (Throwing Exceptions) 시킬 때

이미 정의된 exception을 적용하지 못할 때만 새 Exception 클래스를 도입하자.

Ex)

객체의 현재 상태에서 프로퍼티 설정이나 메서드 호출이 적절하지 않다면, InvalidOperationException 예외를 발생시킨다.
만약 부적절한 파라미터를 전달받았다면, ArgumentException 예외 또는 ArgumentException에서 파생된 미리 정의된 클래스 중 하나를 발생시킨다.

**이때 예약된 예외 클래스 (reserved exception) 는 발생시키지 않도록 주의해야 합니다.

reserved exception이란, 일반적으로 시스템 수준의 예외에 해당됩니다.
이러한 예외는 사용자가 재정의하거나 확장하지 않는 것을 권장하고 있습니다.
Java에서는 `java.lang.Exception`이 해당.

Exception Builder 메서드를 사용하자.

보통 프로젝트에서 같은 예외를 각기 다른 위치에서 던지는 것은 흔하게 볼 수 있는데요,

값이 null이거나 비어있는지 체크하고 비어있으면 예외를 던지는 로직만 생각해도

여러 곳에서 중복 코드가 발생할 수 있을 것 같습니다.

이때 예외를 생성해서 반환하는 Helper 메서드를 별도로 생성해서 이러한 중복 코드를 제거할 수 있습니다.

값이 null이거나 비어있는 경우 IllegalArgumentException을 던지려고 하는 로직을 작성해보면 이렇게 될 것 같아요

그리고 값이 있는지 체크해야하는 곳곳에서 이런 코드들이 중복적으로 구현됩니다.

public class ExampleClass {

    public void performAction(String param) {
        if (value == null || value.isEmpty()) {
            throw new IllegalArgumentException(parameterName + " cannot be null or empty");
        }
        // ..
    }
}

이러한 중복 코드를 Helper 메서드로 추출하게 되면??

public class ArgumentValidator {

    public static void throwIfNullOrEmpty(String value, String parameterName) {
        if (value == null || value.isEmpty()) {
            throw new IllegalArgumentException(parameterName + " cannot be null or empty");
        }
    }
}

값을 체크하고 예외를 발생시키는 중복된 코드가 아래와 같이 간단해질 수 있습니다.

public class ExampleClass {

    public void performAction(String param) {
        ArgumentValidator.throwIfNullOrEmpty(param, "param");
        // ..
    }
}

그외

1. 적절한 문법을 사용한다. (영어를 사용할 때 특히 더 중요)

2. finally 문에서는 throw 예외를 두지 말자.

3. 예상치 못할 곳에서는 예외를 던지지 말자.

- equals(), toString(), static 생성자 와 같은 메서드에서는 예외를 던지지 않는다

커스텀 예외 클래스를 생성할 때

1. 사용자 정의 예외는 -Exception 으로 끝나도록 네이밍하자.

2. 사용자 정의(user-defined) 예외 클래스를 만들 때 3개의 생성자는 기본적으로 생성하자.

Exception() : Default.
Exception(String) : 메시지를 전달한다.
Exception(String, Exception) : 메시지와 내부 예외를 전달한다.

2. 필요할 때 추가 프로퍼티를 제공하자.

추가 정보가 필요한 시나리오가 있을 때에만 프로퍼티를 추가하는 것을 권장합니다.

Ex) FileNotFoundException은 'FileName' 필드를 추가로 제공합니다.

3. 그외 예외 처리 관련 참고하면 좋을 9가지

1. 어디에서 예외를 던져야할까?

1) "프로그램의 정상적인 흐름을 제어하기 위해" 예외 던지는 방식을 사용하면 안된다.

예외는 오직 예외인 상황에서 사용해야 한다.

만약 외부 API를 이용해 데이터를 조회했는데 데이터가 존재하지 않는 경우, 이 메서드에서는 예외를 발생시키기 보다 해당 데이터를 전달하는 것이 적절하다.

단, 데이터가 존재하지 않을 때 Null 값 보다는 Null Object pattern을 활용해서 결과를 반환하는 것이 좋다.

그러면 이 데이터를 받은 호출자 메서드에서 그 결과를 확인하고 적절한 액션을 취하면 되는것이다.

호출자에서 적절한 액션을 취하는 것에는
에러를 커스텀 에러로 변환하여 에러를 던질 수도 있고,
에러까지 발생시키지 않아야 하는 경우라면 간단한 로깅만 남기고 로직을 넘어갈 수 있다.
따로 에러를 커스텀 에러로 변환하지 않아도 되는 경우라면
아래 2) 처럼 가장 최상위 계층에서 예외를 처리하도록 할 수도 있다.
상황에 따라 적절한 방식으로 예외 처리하는 것이 필요하다.

2) 가능한 늦게 예외를 처리 한다.

Exception을 throw 하자마자 잡지 않고, 가능한 가장 최상위 계층에서 처리한다.

아래와 같이 divide() 에서 b == 0일 때 던진 에러를, calculate()에서 예외를 처리하게 되면 모든 divide() 를 호출하는 곳에서는 에러를 처리해야할 것이다.

좋지 않은 예외 처리

public void divide(int a, int b) {
    if (b == 0) {
    	throw new DivideZeroError("Cannot divided by zero.");
	}
    // .. 생략
}

public void calculate() {
  try {
    divide(Math.random(), Math.random());
  } catch (Exception e) {
    if (error instanceof DivideZeroError) {
      // ...
    }
  }
}

적절한 예외 처리

public void divide(int a, int b) {
  if (b == 0) {
    throw new DivideZeroError("Cannot divided by zero.");
  }
}

public void calculate() {
    divide(Math.random(), Math.random());
}

그리고 글로벌 핸들러와 같은 최상위 계층에서 예외 처리를 하면 가독성도 좋아지고 코드를 재사용할 수 있다.

@ExceptionHandler(DivideZeroError.class)
public void divideZeroErrorHandler(DivideZeroError error) {
  // 로깅
  // 사용자에게 응답할 에러 response 세팅
}

2. 예외 로그를 남길 시, 하나의 로그로 작성한다.

애플리케이션을 서비스하면, 수많은 요청이 동시에 들어오기 때문에 여러 줄의 로그로 남기게 되면 다른 로그들과 섞여 로그 간 멀어지게 되어 보기 어려울 수 있다.

좋지 않은 예외 처리

try {
  //...
} catch(Exception ex) {
  log.error("error1");
  log.error("error2");
}

적절한 예외 처리

try {
  //...
} catch(Exception ex) {
  log.error("error1. error2");
}

3. 발생하는 예외를 커스텀 예외로 전환시킬 때에는 기존 예외의 원인(Throwable)을 인자로 받는 것이 좋다.

발생한 Throwable을 파라미터를 통해 가져올 수 있는 생성자를 최소한 하나를 구현하고 super 생성자에 Throwable를 전달해준다.

try {
    // do something
} catch (NumberFormatException ex) {
    throw new CustomException("A message that describes the error.", ex, ErrorCode.INVALID_PORT_CONFIGURATION);
}

public class BusinessException extends Exception {
    public BusinessException(String message, Throwable cause, ErrorCode code) {
            super(message, cause);
            this.code = code;
    }
}

특히 이 사항은 직접 경험하며 느낀 내용인데요, 기존 예외의 원인(Throwable)을 인자로 전달한 상황과

인자로 전달하지 않은 상황에는 에러를 디버깅하고 원인을 찾아가는 과정에 차이가 있었습니다.

에러가 발생하는 상황은 아래와 같습니다.

1) 로그인 클래스 A의 메서드에서 쿠키를 처리하는 유틸 클래스 B 호출

2) 유틸 클래스 B의 메서드에서 IllegalArgumentException이 발생.

2) 로그인 클래스 A의 메서드 내에서 2)번 호출 로직에 대한 try/catch문 존재

try {
	CookieUtils.setValidateCookie(generatedTokens);
} catch (Exception ex) {
	throw new CookieProcessFailException(String.format("cause: %S", ex.getClass()));
}

해결

try {
	CookieUtils.setValidateCookie(generatedTokens);
} catch (Exception ex) {
	throw new CookieProcessFailException(String.format("cause: %S", ex.getClass()), ex);
}

4. 예외를 잡는 곳은 상황에 따라 다르다.

예외가 발생한 곳에서 무조건 예외를 처리하려고 하지 않아도 됩니다.

즉, 처리하기 적합하지 않은 곳에서 무리하게 예외 처리하려고 하지 말라는 것인데요

예를 들어 최상위 레이어에서 사용자에게 파일의 위치를 입력 받고, 최하위 레이어에서 이 파일의 내용을 읽어 드리는 어플리케이션이 있습니다. 파일이 존재하지 않는 예외의 처리 방법으로 사용자 입력을 다시 받게 하려면, 최상위 레이어가 예외를 처리해야하고 사이의 레이어들은 체이닝만 하는 것이 좋습니다.

5. 리소스는 정리해야 한다.

try-catch 구문에서 리소스를 연다면, finally 블록에서 리소스들을 정리하거나 try-with-resource 구문을 이용해야합니다.

AutoCloseable 인터페이스를 구현한 리소스라면 try-with-resource 구문을 이용하면 됩니다.

6. 발생할 수 있는 예외는 문서화한다.

JavaDoc을 통해 어떤 예외가 발생할 수 있는지 명시합니다.

/**
 * Member 엔티티를 조회합니다.
 * @param memberId 조회할 회원의 id
 * @throws MemberNotFoundException 조회한 회원이 없는 경우에 예외가 발생합니다.
 */
public Member findOne(String memberId) {
	return memberRepository.findByMemberId(String memberId)
    	.orElseThrow(() -> new MemberNotFoundException(String.format("회원 '%s'이 존재하지 않습니다.", memberId)));
}

7. 예외 메세지를 자세하게 적는다.

사용자 정의 예외를 만들 때에는 예외가 발생한 상황에 대해 로그 메시지를 적을 수 있는데,

어떤 상황에서 예외가 발생했는지 간결하게 적어줍니다.

그러나, 예외 이름 자체에서 어떤 문제로 발생했는지 알 수 있을 경우에는 너무 많은 정보를 적지 않아도 됩니다.

Ex) NumberFormatException : 숫자 포맷이 아닌 포맷의 문자열을 숫자로 변환하려할 때 문제가 발생했음을 짐작할 수 있습니다. 이런 경우에는 어떤 문자열을 변환시키려했는지만 작성해놔도 괜찮습니다.

8. 예외를 상위 메서드로 던질 때 로그를 남기지 마라

예외가 발생한 코드에서 상위 메서드로 예외를 던질 때에는, 별도의 로그 처리를 하지 않아도 됩니다.

상위로 예외를 throw 할 경우 로그가 너무 많아져 가독성을 훼손하기 때문입니다.

다시 상위로 throw하고자 한다면, 로그를 찍지 말고

그상황에 대한 Context를 남기고자 한다면 이를 감싸는 커스텀 클래스로 만들고, 이를 상위로 던지길 권장합니다.

예외를 래핑하는 커스텀 클래스 예시

public class MyException extends BusinessException {
	public MyException(String message, Exception ex) {
		super(message, ex);
	}
}

9. 예외를 잡은 후 처리할 때 유형

예외를 잡았을 때 catch문에서 로그만 남겨야 하는 일은 거의 드뭅니다. 예외를 잡았으면 무언가를 해야합니다.

처리 유형은 3가지 케이스가 있을 것 같습니다.

처리하고 예외 상황 종료
다시 던진다.
새 예외로 커스텀하여 던진다.

10. 로그 메시지는 어떻게 남기는게 좋을까?

<발생 상황 + 어떤 Exception인가 + Exception 메세지> 정도만 알려주어도 좋습니다.

더 나아가서는, <발생 IP + 발생 Port + 발생 스레드> 등의 정보도 포함시킬 수 있습니다.

충분한 로그 예)

“second data reading failed. cause=IOException, message=“socket read failed.”], peer=“10.10.10.13”, port=1234, auth=“base123”, thread=32"

참고글

[SQL, 프로그래머스] 상품 별 오프라인 매출 구하기

뭉지(moonz) — Sun, 9 Jun 2024 14:00:05 +0900

프로그래머스에 여러 문법들을 활용해서 SQL 쿼리문을 짜볼 수 있도록 다양한 문제들을 레벨 별로 제공하고 있습니다.
Lv2 '상품 별 오프라인 매출 구하기' 문제를 풀어보았습니다.

프로그래머스 문제 링크 참고 바라며, 문제는 간략히 설명합니다.

프로그래머스

programmers.co.kr

사용할 테이블 정보

어느 의류 쇼핑몰에서 판매중인 상품들의 상품 정보를 담은 PRODUCT 테이블과
오프라인 상품 판매 정보를 담은 OFFLINE_SALE 테이블이 있으며,
두 테이블 모두 product_id 칼럼을 가지고 있습니다.

생각의 과정

product 테이블과 offline_sale 테이블 각각의 칼럼을 조합하여 결과를 보여주어야 한다.
- JOIN을 수행해야겠다. product_id를 공통으로 가지고 있으니 이를 활용한다.
매출액은 product.price와 offline_sale.sales_amount의 곱이다.
상품코드 별 매출액의 합을 구해야한다.
- 상품코드로 GROUP BY하여 SUM()을 구해야겠다.
매출액으로 내림차순하고, 동일한 매출액이면 상품코드로 오름차순한다.
- ORDER BY 매출액 desc, 상품코드 asc
(참고) 상품ID는 OFFLIE_SALE 테이블에 중복으로 존재할 수 있으나, 상품ID와 판매일까지 고려한 데이터는 중복 존재하지 않는다.
상품이 오프라인 판매 테이블에 존재하지 않을 수 있고, 이럴 경우 어떻게 할지 고려해야 할 것 같다.
- (해당 내용에 대한 설명은 따로 없어 우선 고려하지 않고 문제를 제출하니 테스트 케이스에 이런 경우는 없는지 통과되었다.)

SQL 쿼리 작성 (MySQL)

SELECT product.product_code, SUM(product.price * offline_sale.sales_amount) AS sales
FROM product INNER JOIN offline_sale
ON product.product_id = offline_sale.product_id
GROUP BY product.product_code
ORDER BY sales desc, product.product_code asc;

필요한 지식

INNER JOIN, GROUP BY, ORDER BY, 연산함수 SUM

[SQL, 프로그래머스] 조건에 맞는 도서와 저자 리스트 출력하기

뭉지(moonz) — Sun, 9 Jun 2024 12:48:08 +0900

프로그래머스에 여러 문법들을 활용해서 SQL 쿼리문을 짜볼 수 있도록 다양한 문제들을 레벨 별로 제공하고 있습니다.
Lv2인'조건에 맞는 도서와 저자 리스트 출력하기' 문제를 풀어보았습니다.

프로그래머스 문제 링크 참고 바라며, 문제는 간략히 설명합니다.

프로그래머스

programmers.co.kr

사용할 테이블 정보

어느 한 서점에서 판매중인 도서 정보를 담고 있는 book 테이블과 저자 정보를 담고 있는 author 테이블이 있으며,

두 테이블 모두 author_id 값을 갖고 있습니다.

고민 과정

book 테이블에 있는 정보와 author 테이블에 있는 정보를 합쳐서 보여줘야 한다.
- 그냥 합치면 될 것으로 보이니 INNER JOIN해야지
카테고리 = '경제'로 필터링해야 한다.
- WHERE 절 추가해야지
book.published_date로 정렬해야 한다.
- 마지막에 ORDER BY 추가해야지
그외 고려해야할 것은 없어보인다.
- SQL 짜러 고!

+ (고민 과정에서는 놓쳤지만) published_date를 '2021-04-01'처럼 노출되도록 포맷팅 적용한다.

SQL 쿼리 작성

SELECT book.book_id, author.author_name, DATE_FORMAT(book.published_date, '%Y-%m-%d') AS published_date
FROM book JOIN author
ON book.author_id = author.author_id
WHERE book.category = '경제'
ORDER BY book.published_date;

추가 필요한 지식

INNER JOIN, ORDER BY, DATE_FORMAT()

DATE_FORMAT()

문제 유형인 'JOIN' 개념 외에 Date 포맷팅 적용 방법도 알아야했습니다.
이미 Date 타입인데, 데이터의 포맷을 yyyy-mm-dd HH:MM:SS -> yyyy-mm-dd 형태로 바꾸어주어야 하려면, 아래 문법을 사용합니다.
데이터 포맷팅 규칙은 다양하게 있습니다.

DATE_FORMAT(date, '%Y-m-%d')

모든 포맷을 외우기 힘들다면 아래 예시 정도면 알아두어도 괜찮을 것 같아요

포맷 표현식	예시
'%Y-%m-%d %H:%i:%s'	1999-01-01 00:00:00
'%Y-%m-%d %T'	1999-01-01 00:00:00
'%Y-%m-%d %r'	1999-01-01 12:00:00 AM

**시각 : 정오

[Spring Security] permitAll() 적용되지 않는 이슈 해결

뭉지(moonz) — Tue, 21 May 2024 22:53:58 +0900

서론

다운로드 도메인의 애플리케이션에는 권한 있는 사용자만 접근 가능한 API 1개로만 존재했습니다.

최근, 권한 체크 없이 접근 가능한 API를 한개 더 추가해야하면서 Spring Security의 설정을 수정해야 했습니다.

구체적인 기능에 대한 설명

1) 권한이 있는 사용자에 한해 다운로드할 수 있도록 하기 위해 애플리케이션 내 API에서 요청을 처리하도록 하였고,

2) 권한 체크가 필요 없는, 누구나 다운로드할 수 있는 파일들의 경우 Nginx에서 파일들을 나르도록 처리하고 있습니다.

(해당 서버는 NAS 서버와 마운트 되어있었기 때문에 파일을 매핑하여 전달하는 것이 가능했습니다.)

기존에는 VM 환경에서 구동 중이었으나 컨테이너 환경으로 전환해야하면서

Nginx가 수행하던 역할을 애플리케이션 내에서 처리하기로 결정하였습니다.

그래서 다운로드 애플리케이션 내에 적용되어 있는 Spring Security에

기존에 존재하던 API에 대해서만 권한 체크를 수행하고, 그외 API는 권한없이도 접근할 수 있도록 설정을 추가하기로 하였습니다.

그 과정에서 Security Filter를 잘못 사용되고 있는 부분이 있었고, 이를 해결하면면서 알게된 내용을 글로 정리합니다.

문제 상황

Security Config 클래스에서 기존에는 모든 API에 대해 권한 체크가 필요하도록 설정되어 있었습니다.

기존 SecurityConfig 클래스

@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    private final ObjectMapper objectMapper;

    private final AuthenticationJwtTokenProvider authenticationJwtTokenProvider;

    private final UserDetailService userDetailService;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .cors().configurationSource(corsConfigurationSource())
                .and()
                .httpBasic().disable()
                .csrf().disable()
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .authorizeRequests()
                .anyRequest().authenticated()  // 기존 설정
                .and()
                .exceptionHandling().accessDeniedHandler(new CustomAccessDeniedHandler())
                .and()
                .exceptionHandling().authenticationEntryPoint(new CustomAuthenticationEntryPoint())
                .and()
                .addFilterBefore(new AuthenticationTokenFilter(authenticationJwtTokenProvider, userDetailService), UsernamePasswordAuthenticationFilter.class)
                .addFilterBefore(new JwtExceptionFilter(objectMapper), AuthenticationTokenFilter.class)
        ;

    }

    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        // 생략
    }

    @Override
    public void configure(WebSecurity web) {
        // 생략
    }
}

그런데 신규로 등록한 API는 권한 체크 없이 접근하도록 설정해야 했습니다.

이제 애플리케이션에 존재하는 2개의 API 중 1개(/api/downloads/**)는 권한 체크를 해야하고, 나머지 1개는 누구나 접근할 수 있도록 해야하는 상황이 됐습니다.

누구나 접근할 수 있도록 한 API를 'any접근 API'라고 부르도록 하겠습니다.

수정한 모습입니다.

// 수정한 일부만 발췌
                .authorizeRequests()
                .antMatchers("/api/downloads/**").authenticated()
                .anyRequest().permitAll()
                .and()

이제 'any접근 API'를 호출하면 권한이 없어도 파일을 다운로드받을 수 있을 것이라 예측했는데, 애플리케이션에서는 401 Unauthorized 상태코드와 함께 JWT 토큰이 없다는 에러를 반환해버립니다.

원인

Security Filter를 디버깅해보니, Filter Chain 중 AuthenticationTokenFilter 클래스 내 JWT 토큰을 체크하는 로직에서 토큰이 없어서

HttpServletResponse 에 에러 정보(상태, 에러 메시지)를 세팅하고 return;문을 통해 클라이언트에게 바로 응답 하도록 구현되어 있었습니다.

기존 Security Filter

@Slf4j
@RequiredArgsConstructor
public class AuthenticationTokenFilter extends OncePerRequestFilter {

    private final AuthenticationJwtTokenProvider authenticationJwtTokenProvider;
    private final UserDetailService userDetailService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {

        try {
            Optional<String> token = authenticationJwtTokenProvider.findToken(request);
            // 토큰이 없으면 에러로 세팅하고 필터 중단.
            // 여기서 에러 발생 후 응답 반환.
            if (token.isEmpty()) {
                doErrorHandle(request, response, "Jwt must not null");
                return;
            }

            Optional<UserDetailDto> userToken = authenticationJwtTokenProvider.getUserToken(token.get());
            // 토큰이 없으면 에러로 세팅하고 필터 중단.
            if (userToken.isEmpty()) {
                doErrorHandle(request, response, String.format("Failed translate Jwt to UserDetailDto (token:%s)", token));
                return;
            }

            UserDetailDto userDetailDto = userToken.get();
            // 사용자가 유효하지 않으면 에러로 세팅하고 필터 중단.
            if (!validateUserDetail(userDetailDto)) {
                doErrorHandle(request, response, String.format("Invalid UserDetailDto (userDetailDto:%s)", userDetailDto.toString()));
                return;
            }

            UserDetails userDetail = userDetailService.loadUserDetail(userDetailDto);
            UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(userDetail, "", userDetail.getAuthorities());
            SecurityContextHolder.getContext().setAuthentication(authenticationToken);

        } catch (InvalidAuthenticationException exception) {
            // Exception 발생하면 에러로 세팅하고 필터 중단.
            log.error(ExceptionUtils.getStackTrace(exception));
            doErrorHandle(request, response, "Invalid UserDetail");
            return;
        }

        filterChain.doFilter(request, response);

    }

    private boolean validateUserDetail(UserDetailDto userDetailDto) {
        // true or false 반환
    }

    private void doErrorHandle(HttpServletRequest request, HttpServletResponse response, String message) {
        try {
            log.error(String.format("[authentication token] {msg=%s, url=%s, remote_ip=%s}",
                    message, request.getRequestURI(), request.getRemoteAddr()));

            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, message);

        } catch (IOException exception) {
            log.error(ExceptionUtils.getStackTrace(exception));
        }
    }

사실 저는 'any접근 API'를 호출하면 아예 시큐리티 필터를 안 탈 것이라 생각했는데 Security Filter를 타서 조금 놀랐습니다.(...)

결국 SecurityConfig 클래스에서 permitAll()로 설정한 URI에 상관없이 위 클래스에서 필터를 중단시키는 것이

401 Unauthorized 에러의 원인이었습니다.

해결 방향과 간단한 흐름 정리

해당 문제를 해결하면서 Security Filter를 디버깅해보며 흐름을 확인하니,

개발자가 SecurityConfig에 원하는 설정 정보들을 지정하면,

이를 이용해서 각 요청들에 대해 승인/거부하는 것을 수행하는 필터가 Security Filter Chain 중 있었습니다.

저희는 SecurityConfig에 이미 각 URI에 대해 권한 설정을 해놓았다면,

Security Filter Chain 내에서 요청 URI에 대해 승인/거부 여부를 판단할 수 있도록 맡겨놓으면 되는 것입니다.

승인/거부에 따른 후처리 로직에 대해 커스텀하고 싶다면, 디폴트 클래스를 상속하여 커스텀할 수도 있습니다.

그래서 최종 해결한 방법은,

AuthenticationJwtFilter에서 아래의 경우와 같이 인증/인가에 이슈가 있어도 필터를 중간에 중 지시키지 않도록 하였습니다.

요청 헤더 or 쿠키에 토큰이 없는 경우
토큰이 있으나, 토큰 내 정보를 까보니 유의미한 사용자가 아닌 경우

또한 당연하게도 위 케이스에 해당하면 Authentication 객체를 세팅하지 못하게 됩니다.

그러면 Security Filter에서 인증/인가를 승인할지 거부할지 심사하는 클래스(AccessDecisionVoter)에서 아래 정보들을 보고 심사합니다.

심사할 때 고려하는 값:

Authentication - 인증 정보 (user)
FilterInvocator (요청 정보)와 ConfigAttributes (권한 정보) : Security Config에 설정한 URI 와 그 URI에 세팅한 권한 정보

남은 이야기

WebSecurity 클래스의 ignoring() 메서드에 추가할 순 없었나?

처음에는 아예 필터를 타지 않도록 WebSecurity 에 해당 uri를 추가하고자 했으나

'any 접근 API'가 /api/downloads/** uri 외의 모든 요청에 대해 처리해야하는 API였기 때문에 컨트롤러 모습이 아래와 같았습니다.

그래서 /** 패턴을 추가하면, 권한 체크를 해야하는 /api/downloads/ API마저 권한 없이 접근이 가능해져버려서 해당 부분에 세팅할 수는 없었습니다.

@Getmapping("/**")
public void noAuthFile(HttpServletRequest request, HttpServletResponse response, ...) {
    // 생략
}

문제를 해결하는 과정에서 알게된 Spring Security Filter에 대한 내용은 다른 글에서 정리해보도록 하겠습니다!

잘못된 부분이나 궁금한 점 있다면 편하게 댓글 부탁드려요 =)