집에 안쓰는 구형 맥북이 있다.

MacBook Pro 2017
CPU : i5 어쩌구 인가? 기억 안남
RAM : 8GB
GPU : 모름 아무튼 내장 그래픽
SSD : 256GB 인가 아무튼 그쯤

이 정도 스펙인데 집에서 뒹굴거리길래 홈서버를 구축해서 요긴하게 써먹고 있다.

홈서버를 구축하면서

• 집 공유기를 통해서 포트포워딩도 해보고
• DDNS 설정도 해보고
• 개인 프로젝트 배포도 해보고
• CI/CD 구축도 해보고 아무튼 잘 굴려먹고 있었다.

물론 CI/CD 구축할땐 그냥 AI로 짰다. 그냥 아하 이렇게 하는 거구나? 하는 느낌

그런데..

문제 발생

그런데 어느 순간부터 배포하려고 PR 날리면 Actions가 너무 오래 돌다가 timeout 나기 시작했다.

이것 저것 찔러보면서 해결하려고 애쓴 모습

AI로 코드를 짰으므로, 클로드 열심히 돌려가면서 원인을 찾으려고 애썼지만 문제는 지속됐다.

문제 현상

1. Actions 실행 중 반응 없다가 time out
2. 홈서버 접속해서 docker ps 로 상태를 확인하려고 하면 반응 없음
3. 그때마다 colima 자체를 껐다가 다시 켜야하는 상황

그래서 찾은 문제의 원인은 바로 ...

💡 OOM Out Of Memory 메모리가 터진 것이였다.

8GB RAM 사용 현황:
  macOS:           ~3GB
  Colima VM:       ~1GB
  기존 컨테이너들:     ~1GB
  Maven 빌드:       ~2GB+
  ─────────────────────
  합계: 7GB+ → OOM → Colima VM 강제 종료 → docker ps 블로킹

내 맥북은 구형이기 때문에 Docker가 해당 os버전까지 지원해주지 않는다. (건방지게) 그래서 Colima라는 Linux 가상 머신을 띄워서 도커를 띄우고 있었다. 그게 리소스를 꽤 먹는데다가 컨테이너도 왕창 띄워놨었다.

그리고 결정적으로 빌드 자체를 홈서버에서 하고 있었다 그 커다란 maven 의존성 덩어리를 배포할때마다 빌드하고 있었으니 간당간당했던 내 맥북이 뻗어버린 것이다.

정리하자면

• 구형 맥북에
• Colima위에
• 도커 띄우고
• 컨테이너 왕창 띄우고
• 게다가 빌드 자체를 홈서버에서 하고 있었는데다
• 클로드 코드가 짜준 코드여서 근본적인 원인 탐색을 못하고 있었다.

그래서 이 참에 그냥 CI/CD 과정을 배워보기로 했다.

CI/CD란?

📝 CI (Continuous Integration) — 코드를 push할 때마다 자동으로 빌드·테스트 CD (Continuous Deployment) — CI 통과 후 자동으로 서버에 배포

git push 하나로 → 빌드 → 테스트 → 배포 전부 자동화

결국 푸시만 하면 알잘딱 빌드와 테스트, 배포까지 해주는 아주 똘똘한 방식이다.

지금까지의 방식

1. Actions VM 실행
2. github Repo에서 코드를 checkout 해옴
3. VM 위에서 maven 빌드
4. JAR 파일 생성
5. SCP로 JAR 파일 홈서버로 전송 (JAR가 있어야 이미지를 만들 수 있기 때문)
6. 홈서버에 SSH 접속
7. git pull로 최신 코드 땡겨옴
8. 그 상태에서 Docker 빌드 (이미지 생성) → 💥 주로 여기서 OOM 발생 💥
9. 배포

steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 21
    uses: actions/setup-java@v4
  - name: Build JAR
    run: mvn package -DskipTests -q && cp target/*.jar app.jar

  - name: SCP JAR to server          # JAR를 홈서버로 전송
    uses: appleboy/scp-action@v0.1.7
    with:
      source: "app.jar"
      target: ${{ secrets.DEPLOY_PATH }}

  - name: Deploy via SSH # ssh로 홈서버 접속
    uses: appleboy/ssh-action@v1.0.3
    with:
      script: |
        cd ${{ secrets.DEPLOY_PATH }}
        git pull origin main
        docker compose up -d --build   # 💥 홈서버에서 Docker 빌드 → OOM

이 방식에 문제점이 있다면

1. 서버에서 빌드하기 때문에 서버에 부하가 크다 (얼마나 부하가 큰지는 측정을 못해봤음 ㅠ)

어쨌든 PR 날릴 때마다 서버가 통으로 멈추는건 아주 크나큰 문제였다.

사실 최초의 코드는 더욱 심각했다.

name: Deploy to Home Server

  on:
    push:
      branches: [main]

  jobs:
    deploy:
      runs-on: ubuntu-latest
      steps:
        - name: Deploy via SSH
          uses: appleboy/ssh-action@v1.0.3
          with:
            host: ${{ secrets.SSH_HOST }}
            port: ${{ secrets.SSH_PORT }}
            username: ${{ secrets.SSH_USER }}
            key: ${{ secrets.SSH_PRIVATE_KEY }}
            script: |
              set -e
              cd ${{ secrets.DEPLOY_PATH }}
              git pull origin main
              ./mvnw package -DskipTests      # 홈서버에서 Maven 빌드
              docker compose up -d --build    # 홈서버에서 Docker 빌드
              echo "✅ 배포 완료"

• CI 과정은 아예 생략,
• 곧바로 ssh로 서버 접속해서 pull받고,
• maven build, docker build를 둘 다 서버에서 했다.
• 결국, 부하가 두배로 드는 최악의 코드였다.

해결책

Github Container Registry (ghcr.io)를 도입하기로 했다.

ghcr.io란? github에서 운영하는 Docker 이미지 저장소

Github Container Registry를 이용해서 도커 이미지를 pull받아 이미지만 실행시키는 방식을 사용하도록 했다.

1. Actions VM 실행!
2. github Repo에서 코드 checkout
3. maven 빌드
4. 생성된 jar를 토대로 docker 빌드
5. 생성된 이미지를 ghcr.io에 업로드
6. SSH로 홈서버 접속
7. git pull로 최신 코드(docker-compose.yml) 땡겨옴
8. docker compose pull로 이미지 pull 받아오기
9. 그 상태에서 Docker Run
10. 배포

steps:
  - uses: actions/checkout@v4
  - name: Set up JDK 21
    uses: actions/setup-java@v4
  - name: Build JAR # maven 빌드
    run: mvn package -DskipTests -q && cp target/*.jar app.jar
  - name: Set up Docker Buildx # docker build 도구
    uses: docker/setup-buildx-action@v3
  - name: Log in to ghcr.io # ghcr.io 로그인
    uses: docker/login-action@v3
  - name: Build and push Docker image   # VM에서 이미지 빌드 + ghcr.io push
    uses: docker/build-push-action@v5
    with:
      context: .
      push: true
      tags: ghcr.io/0xdf0101/mock_invest:latest

  - name: Deploy via SSH
    uses: appleboy/ssh-action@v1.0.3
    with:
      script: |
        git pull origin main
        docker compose pull             # ghcr.io에서 이미지 pull
        docker compose up -d            # 실행만 (빌드 없음) ✅

이렇게 했을 시 장점

1. VM에서 maven과 image 빌드를 다 하고, 서버에서는 이미지 실행만 하기 때문에 서버의 부하가 줄어든다!
2. ghcr.io에 push 했기 때문에 같은 이미지를 다른 환경에서도 그대로 실행 가능
3. 이미지가 환경 자체를 포함하기 때문에 일관성 증가

결론

✅ ghcr.io를 도입함으로써 서버의 부하를 줄이고, OOM을 예방할 수 있었다. (두 방식에 대한 메모리 변화량도 기록하고 싶었으나 Grafana를 띄우니까 또 뻗었다.)

배운 점

• '한정된 자원'이라는 것을 처음 경험해봤다. 지금까지는 제공되는 빵빵한 서버에 빵빵한 리소스 위에 배포를 했다면, 이제는 정말 '한정된 자원'에 최적화 하는 경험을 해본 것 같다.
• 그저 '동작만 하는 코드'를 만들어내는게 중요한 것이 아니라 구조를 이해하고 설계하는 능력이 필요함을 느꼈다.
• 사실 이제 막 배워가는 단계라 '최적화'인지는 잘 모르겠슈

컴퓨터 구조를 공부해보자 ! 컴퓨터공학을 전공했는데 가오 떨어지게 컴퓨터 구조를 모르는건 말이 안된다. CS를 찬찬히 공부할건데, 그 중 가장가장가장 기초가 되는 CPU의 작동 방식에 대해서 알아보자.

CPU의 기본 구성

CPU는 3가지 요소로 구성되어 있다.

1. ALU Arithmetic Logic Unit : 이름처럼 실제 연산을 수행하는 장치이다.
2. CU Control Unit : 명령어를 받아서 해석하고, 실제 제어 신호로 변환하는 역할을 한다.
3. Register : CPU 내부에 있는 작은 메모리이다. 연산, 제어 시 데이터를 잠시 저장하는 용도로 사용한다.

Control Unit

Control Unit은 ..(이하 CU)

1. 사용자의 명령어를 읽어와서 (Fetch)
2. 그것을 잘 해석한 다음 (Decode)
3. 제어신호로 바꿔서 (Execute; 연산 자체는 ALU가 하긴 함) 실제 연산을 수행하도록 하는 장치이다.

메커니즘

📝 사용자의 프로그램, 혹은 명령어는 메모리(RAM)에 올라가 있다. 성질이 급한 CPU 입장에서 연산을 수행할때마다 메모리에 갔다오는 것을 눈뜨고 봐줄 수 없다. 메모리는 시스템 버스를 타고 다른 마을로 가야 하는 굉장히 멀리있는 동네이기 때문이다. (정확히 말하면, CPU의 속도에 비해 메모리 조회 속도가 너무 느리기 때문에 매번 CPU가 기다려야만 한다)

그래서 수행할 명령어를 레지스터에 담아놓고, 그 레지스터를 조회해서 명령을 수행한다.

여기서 두가지 레지스터가 등장한다.

1. PC Program Counter : 다음에 실행할 명령어의 메모리 주소를 담고 있는 레지스터
2. IR Instruction Register : 지금 실행할 명령어를 담고 있는 레지스터

전체적인 과정은 이렇다.

1. PC를 조회해서 다음 명령어가 저장된 메모리 주소를 알아온다.
2. 이때 PC는 자동으로 다음 명령어를 가리킨다 (CPU가 순차적으로 실행할 수 있는 이유임)
3. 해당 주소의 메모리의 명령어를 가지고 와서 IR에 저장을 해둔다.
4. 그 IR에 담긴 명령어를 CU가 해석을 하고, 그에 맞는 제어 신호를 생성해서 시스템 버스에 태워 보낸다.
5. 그 제어 신호를 받은 ALU가 그 신호에 맞게 연산을 수행한다.

📝 클럭 신호란? 시스템 동기화를 위한 타이밍 신호

똑딱똑딱 이 박자에 맞춰서 장치들이 작동한다. 마치 심장 박동과 같다!

배운 점

• 레지스터라는게 와닿지 않았는데 어떤 용도로 어떻게 사용되는 지 알 수 있었다.
• 어쨌든 내가 키 하나를 누르고 화면 하나를 띄울때마다 이 메커니즘을 기초로 작동한다는 거잖아?
• 조상님들은 진짜 개쩌는거 같다.

Spring Security는 여러가지 필터 덩어리로 이루어져 있다. Filter이므로, DispatcherServlet보다도 앞에 서서 (마치 문지기마냥) 요청을 가장 먼저 받아보고, 적절하게 인증, 인가 처리를 하는 아주 야무진 녀석이다.

하지만 IoC에 의해서 작동하기 때문에 내부에서 어떻게 실제 인증, 인가가 이루어지는지 와닿지가 않는다. 그래서 천천히 뜯어보면서 공부해보았다.

전체적인 흐름은 이러하다

📌 세션 방식을 사용했다.

인증 Authentication vs 인가 Authorization

인증이란 사용자가 누구인지 식별하는 과정이고, 인가란 인증된 사용자가 어디까지 접근하느냐를 구성하는 것이다.

📌 인증에 실패하면 401을 응답받고, 인가에 실패(권한 없는 접근)하면 403을 응답받는다.

Security의 인증 과정

세션 방식을 사용했으므로 일단 모든 요청을 보낼 때, 쿠키에 세션ID를 지참해서 보내줘야 한다. 그럼 그 쿠키가 없는 경우가 바로 로그인이 안된 경우(인증이 안된 상황)라고 할 수 있다.

0. SecurityContextHolderFilter

1. FilterChain의 가장 앞단에 서서 가장 먼저 지참한 쿠키를 까본다.
2. 쿠키에 적힌 세션ID를 확인하고, 세션 저장소에 해당 세션이 있는지 확인한다.
3. 만약 존재한다? 그럼 그 세션의 Authentication 객체를 SecurityContextHolder에 꽂아넣어준다.

📝 여기서 잠깐!! SecurityContextHolder는 뭘까? 그건 바로 처리하는 Thread의 ThreadLocal을 의미한다. 다른 Thread가 접근할 수 없는 Thread 내부 독립된 공간에 Auth 객체를 보관한다. Controller, Service, Repository등을 신나게 돌아다니다 사용자를 식별해야하는 경우가 생기면 ThreadLocal에서 Auth 객체를 꺼내보는거다.

4. 만약 존재하지 않으면 AuthenticationFilter로 넘겨서 인증 과정(로그인)을 거치도록 한다.

1. AuthenticationFilter

1. 사용자가 보내온 ID/PW를 받아본다.
2. 그리고 UsernamePasswordAuthenticationToken을 발급해준다.

   📝 여기서 UsernamePasswordAuthenticationToken은 말 그대로 Username과 Password를 입력받아 인증하는 고전적인 방식에서 사용되는 토큰이다. 다른 인증 방식에서는 다른 토큰을 입력받는다.

❓그럼 어떻게 알고 UsernamePasswordAuthenticationFilter와 Token을 발급해준걸까? 그건 내가 SecurityConfig에다 설정을 해두었기 때문이다.

// SecurityConfig.java
http  
    .formLogin(form -> form  // <<<<<<<<< 이 설정을 켜면 해당 filter가 활성화된다. 
            .loginPage("/login")  
            .loginProcessingUrl("/login")  
            .usernameParameter("email")  
            .passwordParameter("pa![](https://velog.velcdn.com/images/path__find_er/post/6f297b09-f333-481b-89d9-4fe942b576c6/image.png)
ssword")  
            .defaultSuccessUrl("/main")  
    )  
    .userDetailsService(userDetailService)

이 토큰이 바로 다름아닌 Authentication 객체이다. 단지, 아직 미인증 상태일 뿐이다.

public class UsernamePasswordAuthenticationFilter extends AbstractAuthenticationProcessingFilter {  
...

    public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException {  
        if (this.postOnly && !request.getMethod().equals("POST")) {  
            throw new AuthenticationServiceException("Authentication method not supported: " + request.getMethod());  
        } else {  
            String username = this.obtainUsername(request);  
            username = username != null ? username.trim() : "";  
            String password = this.obtainPassword(request);  
            password = password != null ? password : "";  
            UsernamePasswordAuthenticationToken authRequest = UsernamePasswordAuthenticationToken.unauthenticated(username, password);  
            this.setDetails(request, authRequest);  
            return this.getAuthenticationManager().authenticate(authRequest);  
        }  
    }

2. AuthenticationManager (ProviderManager)

📌 AuthenticationManager는 인터페이스이고, ProviderManger가 그 구현체이다.

1. 앞서 말했듯, 인증 방식은 여러가지이다.
2. 그러므로 실제 '인증' 로직을 처리할 여러 AuthenticationProvider들 중에서 적절한 Provider를 찾는 역할을 한다.
3. AuthenticationProvider를 순회하면서 해당 인증을 할 수 있는 Provider를 찾는다.

📝 여기서 사용되는 디자인패턴이 바로 전략 패턴 Strategy Pattern이다. Provider들은 supports() 메서드를 갖고 있고, ProviderManager가 해당 메서드를 실행해보면서 인증 절차를 처리할 수 있는 녀석인지 식별한다.

// ProviderManager.class

@Override  
public Authentication authenticate(Authentication authentication) throws AuthenticationException {  
    Class<? extends Authentication> toTest = authentication.getClass();  
    AuthenticationException lastException = null;  
    AuthenticationException parentException = null;  
    Authentication result = null;  
    Authentication parentResult = null;  
    int currentPosition = 0;  
    int size = this.providers.size();  
    for (AuthenticationProvider provider : getProviders()) {  
       if (!provider.supports(toTest)) {  // <<<<<<<<<<< 갖고있는 provider 순회하면서 supports() 실행
          continue;  
       }  
       if (logger.isTraceEnabled()) {  
          logger.trace(LogMessage.format("Authenticating request with %s (%d/%d)",  
                provider.getClass().getSimpleName(), ++currentPosition, size));  
       }  
       try {  
          result = provider.authenticate(authentication);  
          if (result != null) {  
             copyDetails(authentication, result);  
             break;  
          }  
       }
       ...

3. AuthenticationProvider

1. 이제 얘가 진짜 사용자인지 검증하는 로직을 실행하게 된다.
2. 무엇을 검증하는가?
   • 요청에 담겨온 ID/PW
   • 내 서비스가 저장하고 있는 ID/PW 이 두개를 비교해서 맞으면 인증된 사용자인 것이다. (당연한 소리)
3. 그래서 내 서비스가 저장하고 있는 ID/PW를 가져와야 한다.
4. 하지만 서비스마다 저장, 조회 방식이 다른데 어떡할까?? 하고 스프링은 당황할 수 있다.
5. 여기서부터 개발자가 두두등장 해야한다.

@Override  
protected final UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication)  
       throws AuthenticationException {  
    prepareTimingAttackProtection();  
    try {  
       UserDetails loadedUser = this.getUserDetailsService().loadUserByUsername(username);  
       // <<<<<<<<< 내가 작성한 UserDetailsService를 호출하는 (건방진) 모습
       if (loadedUser == null) {  
          throw new InternalAuthenticationServiceException(  
                "UserDetailsService returned null, which is an interface contract violation");  
       }  
       return loadedUser;  
    }

4. UserDetailsService

📝 AuthenticationProvider 까지는 요청만 보내면 스프링이 알아서 일해주는 영역이다. 그러나 서비스를 설계한 내가 적절하게 저장된 ID와 PW(그니까.. 사용자 정보)넘겨줘야한다.

1. UserDetailsService를 구현한다.

   @Slf4j  
   @RequiredArgsConstructor  
   @Service  
   public class CustomUserDetailService implements UserDetailsService {  
    private final UserRepository userRepository;  
    @Override  
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {  
   
        User user = userRepository.findByEmail(email).orElseThrow(() -> new EntityNotFoundException("해당 사용자를 찾을 수 없습니다."));  
   
        return new CustomUserDetails(user);  // <<<<<< Provider가 원하는 형태로 넘겨줌
    }  
   }

2. AuthenticationProvider는 요청에 담겨온 ID를 UserDetailsService에 넘겨준다.

3. 넘어온 ID를 토대로 내 DB에 저장된 사용자를 찾아서 Provider에게 넘겨준다.

⚠ 검증을 내가 하는게 아니다. 단순히 나는 저장된 사용자 정보를 넘겨주기만 하고, 그 정보를 넘겨받은 Provider가 검증하는 것이다!

📝 내가 작성한 코드를 스프링이 호출해서 (loadUserByUsername()) 정보를 받아가고 있으니 이게 바로 제어 역전 IoC라 할 수 있겠다!

4. 사용자 정보(UserDetails)를 넘겨받은 AuthenticationProvider는 실제 검증을 한다.

5. 인증이 완료된 이후

1. 인증이 되었다면, 그때 비로소 SecurityContextHolder에 Authentication 객체를 넣어준다!
2. 여기서 Authentication 객체는 아까 발급받은 토큰이고, Authenticated 값이 true가 된다. 즉 인증 완료 되었다는 의미이다.
3. 여기에 넣어줄 뿐 아니라 세션 저장소에도 넣어준다.
4. 그리고 클라이언트에게 세션ID를 건네주고, 다음 요청부터는 클라이언트가 쿠키를 싸와야 한다. (HTTP의 무상태성 어쩌구 저쩌구..)

[!warning] 요청이 마무리된 이후 ThreadLocal은 반드시 초기화해주어야 한다. 요청 하나당 Thread 하나가 배정되어서 일을 하는데, 다음 요청 처리하려고 봤더니 ThreadLocal에 이전의 Auth 정보가 남아있다면? ⇒ 대참사

기타 궁금한 사항

Q. Authentication 객체는 무엇을 담고 있을까?

Principal: 인증된 사용자의 주체 (user details).
Credentials: 사용자의 인증 자격 증명 (보통 비밀번호).
Authorities: 사용자의 권한 (roles or permissions).
Authenticated: 인증 여부를 나타내는 boolean 값.

배운 점

• IoC가 이런 거구나, 내가 짠 코드를 스프링이 호출한다는게 이런거구나
• 스프링은 진짜 개쩌는구나 진짜 이걸 설계한 조상님들은 대단하다.
• 이제 스프링 프레임워크가 제공하는 규격만 지키면 필요한 부분을 적절히 커스텀해서 쓸수 있다. 예를 들면, OAuth같은거
• 진짜 개쩐다 스프링

View와 Model을 함께 제공하는 Controller, json 데이터만 딸랑 던져주는 RestController를 지금까지 하나의 클래스에서 혼용했다.

코드를 짜면서도 스스로 짜증났다. 굳이 굳이 @ResponseBody를 붙여줘야 하는게 너무 귀찮고 짜증났다.

하지만 둘은 성격이 매우 다르기 때문에 추후 유지보수를 위해서라도 분리할 필요가 있었다.

단순히 view만 넘겨주는 컨트롤러는 그냥 ViewResolver에게 위임했다.

@Configuration  
@RequiredArgsConstructor  
public class WebConfig implements WebMvcConfigurer {  
    @Override  
    public void addViewControllers(ViewControllerRegistry registry) {  
        registry.addViewController("/").setViewName("index");  
        registry.addViewController("/main").setViewName("main");  
        registry.addViewController("/login").setViewName("login");  
        registry.addViewController("/signup").setViewName("signup");  
        registry.addViewController("/signup/set-username").setViewName("signup/set-username");  
    }  
}

그리고 json 데이터만 넘겨주는 RestController들(API 담당)만 따로 모아 클래스를 만들었다.

@RestController  
@RequiredArgsConstructor  
@Validated
@Slf4j  
public class UserController {  

    private final UserService userService;  

    @GetMapping("/users/{userId}")  
    public ResponseEntity<UserInfo> getUser(@PathVariable Long userId) { // <<< 파라미터 검증 필요  
        UserInfo userinfo = userService.getUser(userId);  
        return ResponseEntity.ok().body(userinfo);  
    }  

    /**  
     * 로컬 회원가입 요청 로직 (OAuth X)  
     */   
     @PostMapping("/api/v1/users")  
    public ResponseEntity<Void> createUser(@Valid @RequestBody UserCreateRequest request) {  

        userService.signUp(request);  

        log.info("회원 등록 완료 : {}", request.username());  
        return ResponseEntity.ok().build();  
    }  

    /**  
     * OAuth로 회원가입 시 username을 따로 입력받는 컨트롤러  
     */  
    @PostMapping("/api/v1/users/username")  
    public ResponseEntity<Void> setUsername(@NotBlank @Size(min=4, max=20) @RequestParam("username") String username,  
                                            @AuthenticationPrincipal OAuth2User oAuth2User) {  

        log.debug("입력받은 아이디 : {}", username);  
        String email = oAuth2User.getAttribute("email");  
        // --> 사용자 식별용 이메일  
        userService.updateUsername(email, username);  

        return ResponseEntity.ok().build();  
    }  
}

View와 API를 서로 분리했더니 좋은 점은?

예외처리가 매우 용이해진다. 반대로, 분리하지 않으면 예외처리가 참 거지같다.

애시당초에 분리해야겠다는 생각 자체를 한 것이 예외처리를 하면서였다. 예외처리를 하는데 어떤 건 String을 반환하고 어떤 건 ResponseEntity를 반환하고 하니 자꾸 꼬였다.

그래서 view 컨트롤러와 API 컨트롤러의 Advice를 각각 나눴다.

@Slf4j  
@ControllerAdvice(annotations = Controller.class)  
public class ViewExceptionAdvice {  

    @ExceptionHandler({EntityNotFoundException.class, EmailNotFoundException.class})  
    public String handleNotFoundException(RuntimeException e, Model model) {  
        log.error("Not found Exception : {}", e.getMessage(), e);  
        model.addAttribute("exception", e.getMessage());  
        return "error";  
    }  
}

얘는 view만 넘겨준다.

@Slf4j  
@RestControllerAdvice(annotations = RestController.class)  
public class ApiExceptionAdvice {  

    /**  
     * 회원가입시, email이나, username이 중복된 경우 예외 처리  
     */  
    @ExceptionHandler({EmailDuplicateException.class, UsernameDuplicateException.class})  
    public ResponseEntity<List<ErrorResponseDto>> handleDuplicateExceptions(RuntimeException e) {  
        String field = (e instanceof EmailDuplicateException) ? "email" : "username";  

        // List.of()를 사용해서 딱 하나의 에러만 담긴 리스트 생성  
        List<ErrorResponseDto> errors = List.of(new ErrorResponseDto(field, e.getMessage()));  

        return ResponseEntity.status(HttpStatus.CONFLICT).body(errors);  
    }  

    /**  
     * @Valid에 의해서 검증하다 예외가 터지면 얘가 처리함  
     */  
    @ExceptionHandler(MethodArgumentNotValidException.class)  
    public ResponseEntity<List<ErrorResponseDto>> handleValidationExceptions(MethodArgumentNotValidException e) {  
        List<ErrorResponseDto> errors = e.getBindingResult().getFieldErrors().stream()  
                .map(error -> new ErrorResponseDto(error.getField(), error.getDefaultMessage()))  
                .toList();  

        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(errors);  
    }  

    /**  
     * @Valided에 의해서 파라미터만 검증하다 터지는 예외 처리  
     */  
    @ExceptionHandler(ConstraintViolationException.class)  
    public ResponseEntity<List<ErrorResponseDto>> handleConstraintViolationException(ConstraintViolationException e) {  

        List<ErrorResponseDto> errors = e.getConstraintViolations().stream()  
                .map(violation -> {  
                    String propertyPath = violation.getPropertyPath().toString();  
                    String fieldName = propertyPath.substring(propertyPath.lastIndexOf('.') + 1);  
                    return new ErrorResponseDto(fieldName, violation.getMessage());  
                })  
                .toList();  

        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(errors);  
    }  
}

js에 던져줄 적당한 양식을 맞췄고, 중복 코드도 줄었을 뿐더러 가독성도 높아졌다. 얘는 이제 js에 던져줄 List<ErrorResponseDto만 잘 포장해서 넘겨주면 된다.

⚠ 주의할 점 @RestControllerAdvice(annotations = RestController.class) advice에 이런 식으로 못박아버리면 @RestController가 붙은 애한테만 반응한다. 고로, 맨 처음 내가 했던 것처럼 view Controller와 섞인 클래스에는 반응을 안한다!

결론과 배운 점

결론

응답의 형태(HTML vs JSON)에 따라 컨트롤러를 나눴다. 결국 고급진 말로 관심사의 분리를 실천했다.

관심사 분리를 통해 유지보수성을 높일 수 있었다. 앞으로도 관심사의 분리를 고려하며 코드를 짜자!

배운 점

1. 무작정 코드를 짜기보단 '어떻게 구조화를 할 것인지' 생각할 필요가 있는 것 같다.
2. 차분히 설계하는 시간보다 이렇게 리팩토링 해가는 과정이 더 오래걸리는거 같다(체감 상)
3. 코드 컨벤션을 맞추는 이유를 알겠다. 왜 API 스펙을 맞추는지도... 지금이야 혼자 개발하니까 나 혼자 끙끙대지만 다른 사람과의 협업이였으면 한대 맞았을 수 있다는 생각이 든다.
4. 대 AI 에이전트 시대에 결국 필요한건 구현보단 이런 설계 능력이랑 규격을 정하는 능력이지 않을까? (아님 말고)

애시당초에 SSR과 CSR을 혼합해서 쓰는게 맞나 싶다

기타 알게된 점

• @Valid를 쓰면 객체(DTO)를 검증하는 데 쓴다. BindingResult 안쓰면 MethodArgumentNotValidException이 터지니까 얘를 잡아주면 된다.
• @Validated를 쓰면 파라미터 단위를 검증 할 수 있다. 얘는 ConstraintViolationException이 터지니까 얘를 잡아주면 된다.

Spring을 배우면서 pom.xml에 의존성을 추가하고 라이브러리를 가져다 쓰는 걸 아주 습관적으로 반복했다. 하지만 생각해보면 어떻게 작동되는지는 궁금하지도 않았고 알 필요도 없다고 생각했다.

노란 밑줄 굉장히 거슬림

그러나 Spring에서의 Auto Configuration을 배우는 과정 중에, ✅ maven과 Spring이 어떻게 상호작용 하는지, ✅ 어떻게 외부 라이브러리를 가져와서 사용하는지, ✅ 그로 인해 어떤 편리함이 있는지, 알게 되어서 정리한다.

메커니즘

1. pom.xml에 의존성 추가

개발자는 외부 라이브러리의 의존성(spring boot, lombok, mysql 등)을 pom.xml에 추가한다. 이는 마치 필요한 부품의 목록을 작성하는 것과 같다.

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>com.mysql</groupId>
            <artifactId>mysql-connector-j</artifactId>
            <scope>runtime</scope>
        </dependency>

      ...

2. 의존성 관리

빌드 초기 단계(패키징, IDE프로젝트 로딩, complie 등)에서, pom.xml을 참고하여 maven Central Repository(mvn 원격 저장소) 으로부터 실제 코드를 다운받고, 로컬 저장소에 캐싱한다.
(그래서 mvn clean package를 처음하면 라이브러리를 다운 받느라 빌드하는데 시간이 오래 걸린다.)

그리고 다운받은 라이브러리 jar 파일은 프로젝트 classpath에 올려진다. 📌 classpath에 올려졌다는 표현은, 애플리케이션 실행시 JVM의 ClassLoader가 JAR 파일을 읽을 수 있는 상태가 된다는 의미이다.

3. @EnableAutoConfiguration에 의한 라이브러리 빈 자동 등록

스프링 부트가 실행되고, @EnableAutoConfiguration 어노테이션을 통해 외부 라이브러리 빈 등록이 시작된다. @EnableAutoConfiguration 은, classpath에 있는 라이브러리를 확인하고, 필요한 빈을 자동으로 등록해주는 어노테이션이다.

1. META-INF/spring/*.imports 목록을 쭉 스캔한다. 이때 이 목록에는 제공할 수 있는 모든 AutoConfiguration이 담겨있다. (Spring 2.7 ~ 이상의 버전에만 해당)

   org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration  
   org.springframework.boot.autoconfigure.aop.AopAutoConfiguration  
   org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration  
   org.springframework.boot.autoconfigure.batch.BatchAutoConfiguration  
   org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration  
   org.springframework.boot.autoconfigure.cassandra.CassandraAutoConfiguration  
   org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration
   ...

2. /*.imports 목록의 클래스를 탐색하면서 @Conditional 조건을 체크한다.

   @AutoConfiguration(
    after = {DispatcherServletAutoConfiguration.class, TaskExecutionAutoConfiguration.class, ValidationAutoConfiguration.class}
   )
   @ConditionalOnWebApplication(
    type = Type.SERVLET
   )
   @ConditionalOnClass({Servlet.class, DispatcherServlet.class, WebMvcConfigurer.class})
   @ConditionalOnMissingBean({WebMvcConfigurationSupport.class}) // ----> 이런 이런 조건들을 classpath의 jar와 비교함
   @AutoConfigureOrder(-2147483638)
   @ImportRuntimeHints({WebResourcesRuntimeHints.class})
   public class WebMvcAutoConfiguration {
    public static final String DEFAULT_PREFIX = "";
    public static final String DEFAULT_SUFFIX = "";
    private static final String SERVLET_LOCATION = "/";
   
    @Bean
    @ConditionalOnMissingBean({HiddenHttpMethodFilter.class})
    @ConditionalOnProperty(
        prefix = "spring.mvc.hiddenmethod.filter",
        name = {"enabled"}
    )
    public OrderedHiddenHttpMethodFilter hiddenHttpMethodFilter() {
        return new OrderedHiddenHttpMethodFilter();
    }
   

3. classpath에 올려진 jar파일을 기준으로 조건을 체크하고, 조건 만족 시 해당 `AutoConfiguration` 클래스의 빈을 생성하고 등록한다. 
   정확히는, **개발자가 직접 등록한 빈이 없을 때**(`ConditionalOnMissingBean`) 작동한다. 그러므로 우리가 직접 설정을 커스텀 할 수 있게 된다. ⭐

## 마무리 
> 결국, 습관적으로 추가했던 의존성이 실제로 어떻게 가져와지며, 어떻게 빈으로 등록이 되는지를 알 수 있게 됐다!
> 
> 그리고, Spring이 없었다면 얼마나 많은 과정을 거쳐 사용해야했는지 생각한다면, Spring의 자동화 로직은 참 편리한 것 같다!

개요

[!note] 객체가 필요로 하는 의존성을 외부에서 직접 주입받는 것을 DI 라고 한다

프로그래밍에서 구성 요소간의 의존관계가 소스코드 내부가 아닌 외부의 설정파일 등을 통해 정의되게 하는 디자인 패턴 중의 하나

[!note] 의존성이란? 의존성이라는 아주 멋들어지는 말을 써서 약간 헷갈릴 수 있는데, A를 실행하기 위해 B를 호출하거나 기능을 빌려써야 한다. == A가 B에 의존한다. 그냥 필요하다는 말임

• IoC 패턴 중 하나
• 객체간 의존성을 낮춤[^1]
• 외부에서 객체를 생성하고 전달

Dependency Inversion Principle (의존성 역전 원칙)

• 상위 모듈이 하위 모듈[^2]에 의존관계를 가지지 않도록 구현해야 한다는 원칙.
• 추상클래스는 그 구현체의 내용에 의존관계를 가지지 않는다.
• 구현체가 추상클래스에 의존관계를 가질 수 있다.

[!note]

DIP: 의존성 역전 원칙의 핵심

1. 전통적인 의존 관계의 문제점

• 상위 모듈이 하위 모듈의 구체적인 구현에 직접 의존함. [cite: 2026-01-20]
• 하위 모듈 변경 시 상위 모듈까지 수정해야 하는 강한 결합이 발생함. [cite: 2026-01-20]

2. 역전(Inversion)의 메커니즘

• 상위 모듈과 하위 모듈 사이에 추상화(인터페이스)를 둠. [cite: 2026-01-20]
• 하위 모듈이 상위 모듈이 정의한 인터페이스에 의존하게 함으로써 의존 방향을 역전시킴. [cite: 2026-01-20]

3. 설계의 이점

• 상위 모듈은 상세 구현의 변화로부터 독립됨. [cite: 2026-01-20]
• 코드의 재사용성이 높아지고, 테스트 시 가짜 객체(Mock)를 주입하기 쉬워짐. [cite: 2026-01-20]

  4. 요약

  DIP는 상위 모듈이 하위 모듈을 무시하는 것이 아니라, 둘 다 추상화에 의존하게 하여 변화에 유연하게 대처하는 원칙임. [cite: 2026-01-20]

주입 방법

📌 @Autowired : 이 어노테이션을 달고 있다는 말은 "나 객체 필요해요" 하고 손들고 있는거랑 똑같음

종류

• Constructor Injection
• Setter Injection
• Field Injection
• @Configuration + @Bean

Constructor Injection

@Component
public class AppStartupRunner implements ApplicationRunner {

    private Greeting greeting;

    @Autowired
    public ApplicationRunner(Greeting greeting) {
        this.greeting = greeting;
    }

    @Override
    public void run(ApplicationArguments args) {
        greeting.sayHello();
    }
}

• 말 그대로 생성자를 통해 사용
• lombok이랑 연계해서 많이 사용됨
• 이걸 권장함
• 생성자가 하나면, @Autowired가 있다고 간주함

Setter Injection

@Component
public class AppStartupRunner implements ApplicationRunner {

    private Greeting greeting;

    @Autowired
    public void setGreeting(Greeting greeting) {
        this.greeting = greeting;
    }

    @Override
    public void run(ApplicationArguments args) {
        greeting.sayHello();
    }
}

• setter에다가 주입
• 근데 꼭 set~ 형태가 아니여도 됨, 다른 이름으로 해도 무방함

Field Injection

@Component
public class AppStartupRunner implements ApplicationRunner {

    @Autowired
    private Greeting greeting;


    @Override
    public void run(ApplicationArguments args) {
        greeting.sayHello();
    }
}

• 명시적이지 않아서 그다지 권장하진 않는 듯

  @Configuration + @Bean

  @Configuration
  public class GreetingConfig {
  
   @Bean
   American innerGreeting() {
       return new American();
   }
   // bean 으로 등록된 American 을 파라미터로 넣어준다
   @Bean
   Greeting englishGreeting(American american) {
       return new EnglishGreeting(american);
   }
  }

• 이러면 매개변수로 bean을 넘겨줘야 하니까 뒤지게 귀찮은게 아닌가 싶음

주입할 Bean을 좀 더 명확하게 하고 싶다면? @Primary, @Qualifier

🎯 동일 타입 빈 충돌 해결: @Primary & @Qualifier

1. 사용 배경

• 인터페이스 하나에 여러 구현체가 빈으로 등록된 경우 발생함.
• 의존성 주입 시 어떤 구현체를 선택할지 스프링에 명시적인 기준을 제공하기 위함임.

  2. 주요 전략

• @Primary: 해당 빈을 기본 우선순위로 설정함. 주입 받는 곳에서 별도 설정이 없으면 이 빈이 채택됨.
• @Qualifier: 빈에 별칭을 부여하고 주입 시 해당 이름을 명시함. 가장 강력하고 구체적인 선택 방법임.

  3. 우선순위 규칙

• 두 어노테이션이 충돌할 경우, 더 구체적인 @Qualifier가 @Primary보다 우선권을 가짐.

다형성을 활용한 설계에서 발생하는 주입 모호성을 해결하는 도구이며, 유지보수 편의를 위해 @Primary를 기본으로 하되 특수한 상황에 @Qualifier를 병용함.

🏗️ 생성자 주입을 권장하는 이유 (DI)

1. 불변성 확보

• final 키워드 사용이 가능하여 의존관계가 실행 중 변하지 않음을 보장함.
• 객체의 안정성이 높아지며 조작의 위험을 방지함.

  2. 테스트 용이성

• 스프링 컨테이너 없이도 순수 자바 코드로 의존성을 주입하여 단위 테스트 가능함.
• Mock 객체 주입이 간편해짐.

  3. 완전한 객체 상태

• 객체 생성 시점에 모든 의존성이 주입되어야 하므로 NPE 발생을 사전에 차단함.
• 컴파일 시점에 의존성 누락을 확인할 수 있음.

  4. 순환 참조 탐지

• 애플리케이션 구동 시점에 순환 참조 문제를 즉시 발견하여 Fail-fast가 가능함.

  5. 요약

  생성자 주입은 객체의 안전성과 테스트 효율성을 극대화하며, 롬복(@RequiredArgsConstructor)과 결합 시 코드 가독성까지 챙길 수 있는 표준 방식임.

Model - View - Controller 관심사의 분리 Separation of Concerns, SoC가 주된 목적 즉, 각 객체가 자기가 잘하는 일에 집중하게 해서 코드의 재사용성과 유지보수성을 높임

• Model: 비즈니스 로직 및 데이터 처리 담당
• View: 모델이 처리한 결과 데이터의 화면 생성 담당 ex) JSP
• Controller: 요청 처리 및 흐름 제어 담당

Model

시스템의 비즈니스 데이터와 그 데이터를 처리하는 규칙을 정의한 컴포넌트

App의 상태 Data와 비즈니스 로직 Logic을 관리하는 부분

주요 특징

• 비즈니스 로직을 다루므로 '실질적인 일'을 하는 부분이라고 할 수 있다!
• 독립성 : View, Controller에 대한 정보를 전혀 몰라야 함 (코드 내에 UI 관련 라이브러리, 컨트롤러 객체 등이 들어가면 안됨!)
• 상태 저장 : DB와 연동되어 데이터를 CRUD함
• Service, Repository 계층을 포함한다!

View

모델이 보유한 데이터를 시각적으로 표현하여 사용자에게 출력하는 컴포넌트

사용자에게 보여지는 결과물을 생성하는 부분

주요 특징

• 수동성 : 데이터를 저장하거나 처리하는게 아니라 그냥 전달받은 데이터를 화면에 그리는 역할만 함
• 로직 최소화 : 출력 로직만 포함되어야 하며, 비즈니스 로직은 포함되지 않음!
• 독립성 : 모델의 구현은 몰라도 상관 없음. 그냥 전달받은 데이터를 잘 그려내기만 하면 된다!

Controller

사용자의 요청을 해석하여 적절한 모델 서비스를 호출하고 그 결과에 맞는 뷰를 선택해 응답을 제어하는 컴포넌트

사용자의 입력 Request를 받아 Model과 View를 연결하는 중개자

주요 특징

• 흐름 제어 : 전체적인 애플리케이션의 워크플로우를 결정함
• 가교 : 모델로부터 데이터를 전달받아 뷰로 넘겨주거나, 사용자의 입력을 모델이 이해하도록 변환함. 즉, Client, Model, View의 가교 역할을 한다
• 비즈니스 로직 배제 : 직접적인 비즈니스 로직을 포함하지 않음 그저 모델에게 일을 잘 시키는데 집중함

MVC 패턴의 장점

1. 유지보수성이 좋음

• 디자인을 바꿀땐 View만 고치면 되고, 비즈니스 로직을 수정할땐 Model만 고치면 됨
• 즉, 서로 간섭 없이 유지보수할 수 있다!

  2. 확장성

• 하나의 모델에 여러 뷰를 붙일 수 있음
• 웹이나, 모바일 등

3. 테스트 용이성

• 화면 없이 백엔드 로직만 떼어내서 유닛 테스트 하는데 용이함

참조

개요

[!note] Cookie는 웹사이트를 방문할 때 사용자의 컴퓨터에 저장되는 작은 텍스트 파일이야. 쉽게 말해, 브라우저가 사용자의 정보를 저장하는 작은 메모리 조각이지

쿠키의 필요성

[!note] 쿠키가 필요한 이유는, HTTP의 무상태성 Statelessness 때문이다.

서버는 매 요청을 새로운 요청으로 간주해서, 네가 방금 전에 로그인을 했는지, 아니면 어떤 페이지를 봤는지 전혀 기억하지 못해. 만약 무상태성만 있다면, 다음 페이지로 넘어갈 때마다 "네가 김유진이야?"라고 다시 물어봐야 하는 문제가 생기지.

이때 쿠키가 등장해. 서버는 로그인에 성공한 사용자에게 '너는 김유진이다' 라는 정보가 담긴 쿠키를 넘겨줘. 브라우저는 이 쿠키를 저장했다가, 같은 서버에 요청을 보낼 때마다 이 '신분증' 을 함께 보내줘. 덕분에 서버는 매번 로그인 정보를 받지 않아도 사용자를 식별할 수 있는 거야.

주로 다음과 같은 용도로 사용돼.

• 로그인 상태 유지: 한 번 로그인하면 다시 로그인할 필요가 없도록.
• 개인 맞춤 설정: "오늘 다시 보지 않기" 같은 옵션을 저장.
• 장바구니 기능: 로그인하지 않아도 장바구니에 상품을 담아둘 수 있도록.
• 트래킹 기능: 사용자의 행동을 기록하고 분석하는 용도

쿠키 종류

1. 세션 쿠키 Session Cookie
   • 사용자가 브라우저를 사용하는 동안만 유효함.
   • 브라우저는 사용자가 브라우저를 사용하는 동안 Cookie 정보를 서버로 전달.
   • Expires , Max-Age [^1] 를 설정안함
2. 지속 쿠키 Persistent Cookie
   • 사용자가 브라우저를 종료하더라도 유지되는 쿠키
   • Expires 혹은 Max-Age 가 같이 설정되는 쿠키

쿠키 속성

SESSION=61f39beb-0a39-4705-8f8e-8738caf6a162; Domain=.dooray.com; Path=/; Secure; HttpOnly; SameSite=None

• Name : 세션 키 이름
• Value : 세션 값
• Domain : 어느 도메인에서 쿠키를 사용할 수 있는지 지정
• Path : 어느 경로에서 쿠키를 사용할 수 있는지 지정

  Set-Cookie: cart=items; Path=/shop
  → /shop, /shop/cart, /shop/payment에서 사용 가능
  → /profile에서는 사용 불가
  

Set-Cookie: session=abc; Path=/ → 모든 경로에서 사용 가능

- `Expaires` / `Max-Age` : 쿠키의 유효(만료)기간[^2]

Set-Cookie: session=data; Expires=Wed, 31 Jul 2025 23:59:59 GMT Set-Cookie: session=abc; Max-Age=3600 (1시간 후 만료) Set-Cookie: remember=yes (브라우저 종료시 삭제)

```

• HttpOnly
  • 보안을 위해 사용 (XSS 공격 방지)
  • JavaScrip 에서 쿠키에 접근 불가능하게 만듦
• SameSite
  • 크로스 사이트(다른 도메인) 요청에서 쿠키 포함여부를 결정

참조

https://developer.mozilla.org/ko/docs/Web/HTTP/Guides/Cookies

[^1]: 만료 시간을 의미 [^2]: Expires는 정확한 날짜를, Max-Age는 남은 시간을 지정함