클로드 AI를 통한 스프링 학습

최근 Claude AI Pro를 구매하면서 AI에 대한 관심이 더욱 많아졌다. 기존에는 AI를 그닥 선호하진 않았지만, 세상이 돌아가는 모습을 보면 AI를 사용하지 않을 수 없다. 그래서 이번 기회에 면접 준비겸 학습으로 Claude AI를 적극적으로 활용해보기로 했다.

가장 먼저 해본 것은 스프링에 대한 기본 지식 학습이 잘되어있는지 확인하는 것!

간단하게 프롬프트는 "스프링에 대한 기초적인 지식을 학습했는데, 이를 테스트하고 싶어. 너가 한 문제씩 내면 내가 그걸 답하는 식으로 진행해보자"로 시작했다.

---

첫 번째 문제:
스프링의 핵심 개념 중 하나인 IoC(Inversion of Control)와 DI(Dependency Injection)의 개념에 대해 설명해주세요. 그리고 스프링에서 의존성 주입을 하는 방법에는 어떤 것들이 있나요?

IoC는 제어의 역전이라는 뜻으로 객체의 생성과 생명 주기의 관리를 개발자가 아닌 외부에서 담당하는 개념입니다. 이러한 특징을 가진 스프링은 IoC 컨테이너를 통해 객체를 스프링 빈으로 관리합니다.

DI는 의존성 주입으로 객체가 생성될 때 필요한 의존성들을 객체 내부에서 생성하지 않고, 외부에서 주입받아 객체를 생성하는 개념입니다. 스프링에서 이 개념은 IoC 컨테이너를 통해 의존성에 해당하는 빈을 찾아 주입해주는 형태로 동작합니다.

의존성을 주입하는 방법에는 
1. `@Autowired` 어노테이션을 필드에 적용하여 주입하는 방법 (필드 주입)
2. 생성자를 통해 주입하는 방법 (생성자 주입)
3. `@Autowired` 어노테이션을 Setter에 적용하여 주입하는 방법 (Setter 주입)

이렇게 세 가지가 있습니다.

---

두 번째 문제:
스프링 빈의 생명주기(Lifecycle)에 대해 설명해주세요. 빈이 생성되고 소멸될 때까지 어떤 과정을 거치나요? 그리고 개발자가 빈의 생명주기에 개입할 수 있는 방법에는 무엇이 있을까요?

스프링 빈의 생명주기는 5단계로 이뤄집니다. 각 단계는 `스프링 빈 생성` -> `의존성 주입` -> `초기화 콜백` -> `빈 사용` -> `소멸 전 콜백` 입니다.

스프링 빈 생성은 스프링 IoC 컨테이너에서 생성되어야 할 객체들이 스프링 빈으로 생성되는 과정이며, 의존성 주입은 이러한 빈 생성 과정에서 필요한 의존성들이 주입되는 과정입니다. 그리고 초기화 콜백은 스프링 빈이 생성된 후 초기화 메서드를 호출하는 과정입니다. 이때, 초기화 메서드는 `@PostConstruct`나 `InitializingBean` 인터페이스 구현, `@Bean(initMethod="init", destroyMethod="close")` 어노테이션 활용을 통해 생성할 수 있습니다.
이 후, 빈이 사용되고 서버가 종료되거나 더 이상 빈을 사용하지 않을 때 빈을 제거하기 전에 소멸 전 메서드를 호출하고 빈이 최종적으로 소멸됩니다.
소멸 전 메서드 또한, `@PreDestroy`, `DisposableBean`, `@Bean(initMethod="init", destroyMethod="close")`를 통해 생성할 수 있습니다.

---

세 번째 문제:
스프링에서 `@Component`, `@Service`, `@Repository`, `@Controller` 어노테이션의 차이점은 무엇인가요? 그리고 이들을 왜 구분해서 사용할까요?

각 어노테이션은 기능적으로 비슷합니다. 내부적으로 `@Component`를 갖고 있기 때문입니다. 다만, 역할을 구분한다는 점에서 차이가 있습니다.
- `@Repository`는 영속성 계층에서 활용하며, 데이터 접근 예외를 스프링의 `DataAccessException`으로 자동 변환 해줍니다.
- `@Controller`는 외부의 요청 및 응답을 처리하는 프레젠테이션 계층에서 활용합니다.
- `@Service`는 비즈니스 로직을 처리하는 애플리케이션 계층에서 활용합니다.
- `@Component`는 위의 계층으로 분류하기 어려운 일반적인 객체들에 해당합니다.

여기서 알 수 있듯 가장 큰 차이점은 의미론적인 역할 구분입니다.

---

네 번째 문제:
`@Autowired`를 사용할 때 같은 타입의 빈이 여러 개 있으면 어떻게 될까요? 그리고 이 문제를 해결하는 방법에는 무엇이 있나요?

같은 타입의 빈이 여러 개 있으면 스프링은 어떤 빈을 주입해야 할지 몰라 `NoUniqueBeanDefinitionException` 예외가 발생합니다. 이런 경우 `@Primary` 혹은 `@Qualifier("빈이름")` 어노테이션, 필드명 혹은 파라미터명을 빈 이름과 똑같이 지정하기, List 혹은 Map을 통해 모든 빈을 받는 방법으로 해결이 가능합니다.
`@Primary` 어노테이션은 해당 어노테이션이 붙은 객체를 우선적으로 사용하겠다고 지정하는 것이고, `@Qualifier` 어노테이션은 특정 빈을 명시적으로 지정하여 주입을 받겠다는 의미입니다.
필드명, 파라미터명을 빈 이름으로 지정하면 해당 이름과 똑같은 빈을 찾아서 주입해주고, 주입받고자 하는 필드를 List 또는 Map으로 선언 시 해당 타입과 같은 빈들을 모두 주입해줍니다.

---

다섯 번째 문제:
스프링에서 트랜잭션(@Transactional)은 어떻게 동작하나요? 그리고 @Transactional을 사용할 때 주의해야 할 점은 무엇인가요?

스프링에서 `@Transactinal` 어노테이션은 스프링 AOP로 동작합니다. 스프링이 `@Transactinal` 붙어있는 메서드 및 클래스가 있으면 이를 프록시 객체로 만들면서 트랜잭션을 사용하는 코드들을 어노테이션이 붙은 메서드에 추가합니다. 이때, 주의할 점은 private 메서드에는 적용이 안되는 점과 트랜잭션이 없는 외부 메서드에서 내부 메서드 호출 시 트랜잭션이 적용되지 않는다는 점입니다. 또한, 체크 예외는 기본적으로 롤백 되지 않는다는 점이 있습니다.

---

여섯 번째 문제:
스프링에서 필터(Filter)와 인터셉터(Interceptor)의 차이점은 무엇인가요? 각각 어떤 상황에서 사용하나요?

필터와 인터셉터의 가장 큰 차이점은 어느 지점에서 수행되느냐?의 차이가 있습니다.
필터의 경우에는 Spring DispatchServlet 앞 단인 톰캣 측에서 수행되며, 인터셉터는 Spring DispatchServlet 뒷 단인 스프링 환경 내에서 수행됩니다. 이러한 차이로 인터셉터는 스프링 빈 주입이 가능하나, 필터는 설정이 필요합니다.
이러한 차이로 인해 필터의 경우에는 스프링 시큐리티와 같은 라이브러리의 인증/인가, XSS 방어나 요청/응답 로깅 등에 활용됩니다. 인터셉터는 세부적인 권한 체크, 로그인 체크와 같은 것들에 활용됩니다.

---

일곱 번째 문제:
마지막 문제입니다! `@Configuration`과 `@Bean`의 역할은 무엇이고, 왜 사용하나요?

`@Configuration`과 `@Bean` 은 스프링 Bean을 등록하기 위한 방법입니다. 
Configuration 어노테이션을 통해서 사용자가 직접 스프링 빈을 등록하는 클래스를 정의할 수 있는데요. 내부적으로 Bean 어노테이션을 사용해서 새로운 스프링 빈을 등록할 수 있습니다. 스프링에서는 Configuration 어노테이션이 붙은 해당 클래스를 프록시 객체로 만들어 Bean 어노테이션 메서드 간 호출 시 싱글톤을 보장해줍니다.

이를 사용하는 가장 큰 이유는 외부 라이브러리의 경우 스프링 빈으로 자동 등록되지 않는 경우가 있기 때문에 이를 통해 외부 라이브러리의 객체를 빈으로 등록하고자 할 때 사용합니다. 이외에도 복잡한 빈 설정이 필요하거나 환경별로 다른 빈을 등록할 때 활용합니다.

---

여기까지가 Claude AI가 내준 문제였다. 스프링을 처음 접하면 알게되는 용어들이지만 생각보다 명확하게 답하기가 어려웠다. 많은 부분들을 까먹고 지내고 있었구나. 해당 웨이브를 한 차례 지내고나니 좀 더 많은 것들을 시도해볼 수 있을 것 같다고 생각했다. 여기에는 해당 문제들을 기반으로 한 실습 문제, 더욱 깊은 스프링 지식 문제 혹은 해당 질문에서의 꼬리 질문 등이 있을 거 같다.

 

이외에도 다양한 방식으로 AI를 활용하는 시간을 가져봐야겠다.