@Cacheable(value = "store-opening-hours", key = "#store.id")
public StoreInfoResponse getStoreInfo(Long storeId) {
    Store store = findStoreOrThrow(storeId);

    // 생략

    return StoreInfoResponse.from(
        store, representativeTag, getStoreOpeningHours(store));
  }

기존 서비스 로직

문제점 : @Cacheable이 붙어있음에도 redis서버에 키값이 저장이 안됨

✅ 트러블 슈팅 & 해결 과정

문제점에 대해서 찾아본 결과 @Cacheable 프록시 기반이기 때문에 같은 클래스 내부의 메소드 호출 시 동작하지 않음

→ 이 경우 실제로 Redis에 키가 저장되지 않음

*+💡프록시란? *

• 프록시 객체 : 실제 객체 대신 앞에 서서 요청을 가로채고, 필요하면 부가 기능을 수행한 뒤 실제 객체에 위임하는 대리 객체
• 즉, 클라이언트 -> 프록시 객체 -> 실제 객체 순서로 동작
• 캐시처리, 트랜잭션 시작/종료, 로깅 등의 공통 관심사를 비즈니스 코드와 분리하기 위해 Spring은 프록시 기반 AOP 사용 (ex. @Cacheable, @Transactional)
• 동작 방식 : 컨트롤러에서 @Cacheable이 붙은 서비스 로직 호출 -> 프록시 객체가 먼저 호출 가로챔 -> 프록시에서 부가 기능 실행 -> 조건에 따라 실제 서비스 로직 실행 또는 생략 -> 결과 반환

따라서 같은 서비스 로직 내에서 프록시 객체를 호출시에는 프록시를 거치지 않으므로 부가 기능 실행이 불가하다

-> 실제 키값을 저장하는 로직 getStoreOpeningHours를 별도의 전용 서비스 클래스로 분리하여 외부에서 호출되도록 구조를 리팩토링

// 애노테이션 제거
public StoreInfoResponse getStoreInfo(Long storeId) {
    Store store = findStoreOrThrow(storeId);

    // 생략

    // 여기서 캐싱 담당하는 서비스 다시 호출
    return StoreInfoResponse.from(
        store, representativeTag, storeGoogleApiClient.getStoreOpeningHours(store));
  }

// 다른 클래스
@Cacheable(value = "store-opening-hours", key = "#store.id")
  public Map<String, List<String>> getStoreOpeningHours(Store store) {
    // 생략
  }

변경 코드

캐싱은 외부 의존성 호출(외부 API) 계층에서 처리하도록 분리해 책임을 명확히 하고, 프록시 객체가 동작 가능하도록 변경

가맹점 상세 조회 시 성능 및 비용 문제

• 가맹점의 조회수를 저장해서 조회수 별 정렬, 인기 가맹점 등의 기능에 사용해야함
  • 가맹점 상세보기를 누를때마다 DB에서 조회수를 업데이트 할 시, 트래픽 증가 상황에서 응답 지연, DB 부하 발생
• 가맹점 상세보기 api에서 외부 API 기반 정보(영업시간, 길찾기, 메뉴링크 등)를 제공해야함
  • 상세보기 할때마다 외부 API 호출시 한도 초과 및 성능 저하

🔧 상세 트러블슈팅 기록

현재 코드

public StoreInfoResponse getStoreInfoWithoutCache(Long storeId, Long userId) {
    Store store = getStoreOrThrow(storeId); // DB 직접 조회
    store.increaseViewCount();

    String representativeTag =
        storeTagCountRepository
            .findRepresentativeTagByStoreId(storeId)
            .map(Tag::getLabel)
            .orElse(null);

    if (userId != null) {
      User user = getUserOrThrow(userId);
      store.setIsScrapped(storeScrapRepository.existsByStoreIdAndUserId(storeId, user.getId()));
    } else {
      store.setIsScrapped(null);
    }

    return StoreInfoResponse.from(
        store, representativeTag, storeGoogleApiClient.getStoreOpeningHours(store));
  }

1. DB에서 Store 조회
2. 조회수 증가
3. 대표 태그 조회
4. 로그인 시: 스크랩 여부 확인
5. Google API에서 영업시간 조회
6. DTO 변환

🚨 문제 1:

조회수 증가 로직으로 인한 DB 락 충돌

• 현상: 동시 요청 시 RDB의 visit_count가 충돌
• 해결:
  • Redis에서 HGETALL store-views로 우선 처리
  • 별도 스케줄러가 1시간 주기로 Redis 값을 RDB에 반영
  • → DB 부하 감소 + 동시성 문제 해결

🚨 문제 2:

Google Maps API 호출 속도 및 한도 문제

• 현상: 상세보기 화면에 있는 영업시간을 보기 위해 외부 API 호출이 필요하나 구글은 월 한도 제한이 있음
• 해결:
  • 검색 결과에서 받은 place_id와 영업시간 정보를 Redis에 캐싱
  • TTL을 15일 설정으로 일정 주기마다 갱신 가능
  • → 응답 속도 단축, 외부 API 호출 횟수 대폭 감소

✅ 해결 과정

Redis를 활용해서 문제를 해결해보기로 !!

Redis 사용이유

• 인메모리 저장소로서, 읽기/쓰기 속도가 매우 빠름 (마이크로초 단위)
• 싱글스레드 기반으로 명령이 순차 처리되어, 조회수 증가와 같은 연산에서 동시성 이슈를 단순화할 수 있음
• 트래픽 급증 상황에서도 안정적인 처리 가능
• TTL(Time-To-Live) 설정을 통해 외부 API 응답 캐싱에 최적화

Redis 사용방법

1. Redis 설치 (Mac) → 로컬을 위해

    brew install redis
    brew services start redis

   또는 도커 내부에 설치

2. 프로젝트 내 설정

   • gradle에 redis, cache 관련 dependency 추가

       // Redis
           implementation 'org.springframework.boot:spring-boot-starter-data-redis'
     
           // Spring Boot Cache
           implementation 'org.springframework.boot:spring-boot-starter-cache'

   • application.yml에 redis 정보 추가

         data:
           redis:
             host: localhost
             port: 6379

   • 메인 Application에 @EnableCaching 추가

   • RedisConfig와 RedisCacheConfig

       @Configuration
       @EnableRedisRepositories
       public class RedisConfig {
     
           @Value("${spring.data.redis.host}")
           private String redisHost;
     
           @Value("${spring.data.redis.port}")
           private int redisPort;
     
           @Value("${spring.data.redis.password:}")
           private String redisPassword;
     
           @Bean
           public RedisConnectionFactory redisConnectionFactory() {
               RedisStandaloneConfiguration redisStandaloneConfiguration =
                   new RedisStandaloneConfiguration(redisHost, redisPort);
               redisStandaloneConfiguration.setPassword(redisPassword);
               return new LettuceConnectionFactory(redisStandaloneConfiguration);
           }
     
           @Bean
           public RedisTemplate<String, Object> redisTemplate() {
               RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
     
               StringRedisSerializer stringSerializer = new StringRedisSerializer();
               redisTemplate.setKeySerializer(stringSerializer);
               redisTemplate.setValueSerializer(stringSerializer);
               redisTemplate.setHashKeySerializer(stringSerializer);
               redisTemplate.setHashValueSerializer(stringSerializer);
               redisTemplate.setConnectionFactory(redisConnectionFactory());
               return redisTemplate;
           }
       }
     

       @EnableCaching
       @Configuration
       public class RedisCacheConfig {
     
         @Bean
         public CacheManager contentCacheManager(RedisConnectionFactory cf) {
           RedisCacheConfiguration redisCacheConfiguration =
               RedisCacheConfiguration.defaultCacheConfig()
                   .serializeKeysWith(
                       RedisSerializationContext.SerializationPair.fromSerializer(
                           new StringRedisSerializer()))
                   .serializeValuesWith(
                       RedisSerializationContext.SerializationPair.fromSerializer(
                           new GenericJackson2JsonRedisSerializer())) // Value Serializer 변경
                   .entryTtl(Duration.ofMinutes(3L)); // 캐시 수명 30분
     
           return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(cf)
               .cacheDefaults(redisCacheConfiguration)
               .build();
         }
       }
     

3. 서버에서 레디스 설치, 반영

    # 설치
    sudo apt update
    sudo apt install redis-server
   
    # 서비스 재시작
    sudo systemctl restart redis
    sudo systemctl enable redis-server
   
    # 접속 확인
    redis-cli ping   # → PONG

   ec2에 레디스 설치 > 도커에 같이 띄우기

    version: '3.8'
   
    services:
      redis:
        image: redis:7
        container_name: redis
        restart: always
        ports:
          - "***"
        command: ["redis-server", "--requirepass", "****"]
        volumes:
          - redis-data:/data
   
    volumes:
      redis-data:

   Redis 보안 설정은 환경 변수 기반으로 관리하며, 상세 구성은 생략합니다. 서버 환경에서는 Redis를 컨테이너 기반으로 분리 배포하여 운영했습니다.

4. 사용하기

   서비스로직에다가 애노테이션을 붙여주면 되고 이 때 서비스내에서 호출하는 경우에는 사용해도 먹히지 않습니다

   • @Cacheable(value = "view-id", key = "#viewId") (예시)
     • 위의애노테이션이 함수위에 붙어있으면 함수 실행전에 redis먼저 확인
   • 또는 RedisTemplate으로 직접 구현

• value는 크게 상관없음
• key기준으로 먼저 redis에서 찾고 있으면 바로 리턴, 없으면 메소드를 실행한다
• key는 파라미터에 있는애
• 저장되는 값은 return값
• @CacheEvict(value = "store-id", allEntries = true)
  • key = “#storeId” 이런식으로 하면 특정 키 삭제
  • allEntries = true는 모든 키 삭제
• @CachePut(value = "store", key = "#store.id")
• 업데이트, 캐시 덮어쓰기 용도

✨ 결과 (K6)

import http from 'k6/http';
import { sleep, check } from 'k6';

export const options = {
  vus: 60, // 60명의 유저가 동시에 요청
  duration: '1s', // 1초간 유지 → 약 60TPS
};

export default function () {
        const BASE_URL = '***;
        const LOCAL_BASE_URL = '***';
        const res = http.get(`***`);

        check(res, {
                'status is 200': (r) => r.status === 200,
                'response time < 500ms': (r) => r.timings.duration < 500,
        });
}

K6을 활용해서 60TPS의 환경에서 테스트를 진행해보았다.

1. 기존 로직 (No caching)

• 전체 응답 중 약 90%가 성공, 약 10%는 실패

• 19%는 응답시간이 500ms 초과

  avg (평균 응답 시간)	272.91ms
  min (최소값)	18.33ms
  med (중앙값)	218.63ms
  max (최대값)	627.13ms

2. 캐싱을 적용한 조회 로직

• 전체 응답 100% 성공

• 전체 응답시간이 500ms 이내

  avg (평균 응답 시간)	147.53ms
  min (최소값)	18.09ms
  med (중앙값)	146.54ms
  max (최대값)	381.83ms

3. 실제 배포 서버에서의 테스트

• 전체 응답 100% 성공

• 전체 응답시간이 500ms 이내

  avg (평균 응답 시간)	181.68ms
  min (최소값)	38.58ms
  med (중앙값)	186.98ms
  max (최대값)	494.89ms

🔗 Spring Security의 Filter Chain

먼저 스프링에서는 필터를 적용하면 필터가 호출 된 다음에 디스패처 서블릿이 호출된다.

필터 흐름 : HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러

• 예를 들어 인증이 되지 않은 사용자라면 필터에서 적절하지 않은 요청이라고 판단하고 서블릿 호출 없이 끝을 낼 수 있다.

필터는 체인으로 구성되어서, 중간에 필터를 여러개 자유롭게 추가할 수 있다.

• 예를 들어서 로그를 남기는 필터를 먼저 적용하고, 그 다음에 로그인 여부를 체크하는 필터를 만들 수 있다.

JwtAuthFilter

JWT 토큰을 추출하고 검사 후 인증객체를 생성하는 과정 또한 필터로 진행할 수 있다.

@RequiredArgsConstructor
public class JwtAuthFilter extends GenericFilterBean {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        // 헤더에서 JWT 토큰 추출
        String token = jwtTokenProvider.resolveToken((HttpServletRequest) request);

        // 유효성 검사 후 SecurityContext에 저장
        if (token != null && jwtTokenProvider.validateToken(token)) {
            Authentication authentication = jwtTokenProvider.getAuthentication(token);
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }

        // 다음 필터로 넘어가기
        chain.doFilter(request, response);
    }
}

순서는 아래와 같다

1. HTTP 요청 헤더에서 JWT 토큰 추출 (Authorization 헤더)
2. 토큰 유효성 검증 및 사용자 정보 추출
3. 인증 객체 생성(UsernamePasswordAuthenticationToken)
4. SecurityContextHolder에 인증 객체 저장

1,2,3번은 저번에 작성해준 JwtTokenProvide에 이어서 작성했다.

JwtTokenProvider

 // JWT 토큰에서 인증 정보 조회
    public Authentication getAuthentication(String token) {
        UserDetails userDetails = customUserDetailService.loadUserByUsername(this.getUserPk(token));
        return new UsernamePasswordAuthenticationToken(userDetails, "", userDetails.getAuthorities());
    }

    // JWT 토큰의 유효성 + 만료일자 확인
    public boolean validateToken(String jwtToken) {
        try {
            Jws<Claims> claimsJws = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(jwtToken);
            return !claimsJws.getBody().getExpiration().before(new Date());
        } catch (Exception e) {
            return false;
        }
    }

    // Request의 Header에서 token 값을 가져오기
    public String resolveToken(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (bearerToken != null && bearerToken.startsWith("Bearer ")) {
            return bearerToken.substring(7); // "Bearer " 이후의 토큰을 반환
        }
        return null;
    }

    // 토큰에서 회원 정보 추출
    public String getUserPk(String token) {
        return Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody().getSubject();
    }

resolveToken() : Authorization 헤더에서 토큰 추출

• HTTP 요청에서 Authorization 헤더를 가져와서
• Bearer로 시작하는지 검증 후 이후의 토큰만 반환

나는 이 과정을 생략했어서 계속 403에러가 났었다...꼭 토큰 추출해줘야된다...

validateToken() : 토큰의 유효성 검사

• 토큰을 파싱해서 서명 검증 후 유효하면 Claims 객체를 받고
• 객체의 유효기간이 지났으면 false 반환

getAuthentication() : 인증 정보를 추출하여 Authentication 객체를 생성

• 토큰을 파싱해서 Subject로 설정했던 PK를 꺼낸다
• customUserDetailService에서 UserDetails 객체 생성
• UsernamePasswordAuthenticationToken 객체에 유저정보인 CustomUserDetails, 자격증명, 권한정보를 담아보낸다.

여기까지 진행후에 Filter에서 SecurityContext에 Authentication 객체를 setAuthentication()으로 저장해주면 컨트롤러 같은 계층에서 요청시에 참조가 가능하다.

CustomUserDetails & CustomUserDetailService

@AllArgsConstructor
public class CustomUserDetails implements UserDetails {

    private Long id;
    private String nickname;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return null;
    }

    @Override
    public String getPassword() {
        return null;
    }

    @Override
    public String getUsername() {
        return nickname;
    }

    public Long getId() {
        return id;
    }

    @Override
    public boolean isAccountNonExpired() {
        return true;
    }

    @Override
    public boolean isAccountNonLocked() {
        return true;
    }

    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }

    @Override
    public boolean isEnabled() {
        return true;
    }
}

UserDetails를 implement 해주면 되고 난 권한정보는 생략하고 필요한 것만 세팅해줬다. 프로젝트에서 필요한것들로 커스텀해주면 된다.

@Service
@RequiredArgsConstructor
public class CustomUserDetailService implements UserDetailsService {

    private final UserRepository userRepository;

    // pk 받아서 해당 유저를 찾아 CustomUserDetails로 반환
    @Override
    public UserDetails loadUserByUsername(String id) throws UsernameNotFoundException {
        User user =
                userRepository
                        .findById(Long.parseLong(id))
                        .orElseThrow(() -> new UsernameNotFoundException(USER_NOT_FOUND.getMessage()));

        return new CustomUserDetails(user.getId(), user.getNickname());
    }
}

필터 체인에 추가

 @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.csrf(AbstractHttpConfigurer::disable) // CSRF 비활성화
                .sessionManagement(
                        session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) // 세션 비활성화
                .authorizeHttpRequests(
                        authorize ->
                                authorize
                                        .requestMatchers("/v3/api-docs/**", "/swagger-ui/**", "/swagger-ui.html")
                                        .permitAll() // Swagger 경로는 누구나 접근 가능
                                        .requestMatchers("/api/v1/auth/**")
                                        .permitAll()
                                        .anyRequest()
                                        .authenticated() // 그 외의 경로는 인증된 사용자만 접근 가능
                        )
                .addFilterBefore(
                        new JwtAuthFilter(jwtTokenProvider),
                        UsernamePasswordAuthenticationFilter.class); // JWT 필터 추가

        return http.build();
    }

컨트롤러에서 사용하기

위의 과정을 완료하면 스프링 security holder에 인증 객체가 저장이 된 것으로 컨트롤러에서 사용할 수 있다.

@PostMapping("/profile")
public ResponseEntity<ApiResponse<?>> profile(
            @Valid @RequestBody AddUserProfileRequest request,
            @AuthenticationPrincipal CustomUserDetails customUserDetails) {

    userService.updateProfile(request, customUserDetails.getId());

    return ResponseEntity.status(HttpStatus.OK).body(ApiResponse.EMPTY_RESPONSE);
}

Filter가 요청을 처리하면서 Authentication 객체를 SecurityContextHolder에 저장하게되고 컨트롤러에서는 @AuthenticationPrincipal을 통해 CustomUserDetails 객체를 바로 주입받아 위와 같이 사용할 수 있다

authorization header를 포함한 상태에서(자물쇠모양) 요청을 보내면 실행이 되는 것 확인완료!

여기까지 카카오 소셜 로그인 + jwt 토큰을 사용한 인증 + spring security에서 CustomUserDetails 활용에 대해 알아보았다.

📌 앞으로...

• Spring Security에 대해 더 공부가 필요할듯
• 권한도 추가해보자

참고 블로그 🙇 https://velog.io/@win-luck/Springboot-카카오-소셜로그인-Jwt-토큰-발급-및-API-검증

위의 그림이 카카오 공식 문서에 나와있는 서비스 로그인 과정으로 글로 다시 적어보자면 아래와 같습니다

1. 클라이언트가 카카오 로그인 요청
2. 클라이언트는 카카오로부터 code를 받아 서버로 전달
3. code를 통해 서버에서 카카오로 토큰 발급 요청
4. 카카오는 code 등을 검증 후 토큰을 서버로 전달
5. 서버에서 토큰으로 유저 정보 조회, 등록
6. 서버에서 유저에게 JWT 토큰을 생성 및 전달
7. 유저는 요청마다 jwt토큰을 포함해서 서버에 요청

차근차근..해봅시다

일단 초기세팅

https://developers.kakao.com

kakaodevelopers에 들어가서 내 애플리케이션 > 애플리케이션 추가하기 이름이랑 아이콘 이런거 설정해서 하나 만들어준다.생성한 애플리케이션으로 들어가서 아래 항목들을 설정해줘야한다.

• 카카오 로그인 : ON으로 설정
• 동의항목 : 비즈앱으로 등록하면 닉네임, 프로필사진, 카카오계정을 필수/선택으로 받을 수 있다. 이름, 성별, 연령대 등등은 사업자번호가 있어야한다고.. 🥹 나는 세개다 필수로 받아줬다!
• Redirect URI : 카카오 로그인에서 code를 받을때 사용하는 리다이렉트 주소라고 보면된다. 프론트에서 받는거라서 3030으로 설정해주면 되고 난 테스트를 위해 8080까지 2개 등록해줬다. http://localhost:8080/kakao/callback http://localhost:3030/kakao/callback

내 애플리케이션에서 앱 키 > REST API 키와 redirect uri는 env파일 등에 넣어놓고 유출되지 않게 사용하기

다음은 build.gradle 설정

    //OAuth2
    implementation 'org.springframework.security:spring-security-oauth2-client'
    implementation platform('org.springframework.boot:spring-boot-dependencies:3.3.5')
    implementation 'org.springframework.boot:spring-boot-starter-webflux'

    //JWT
    implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
    implementation 'io.jsonwebtoken:jjwt-impl:0.11.5'
    implementation 'io.jsonwebtoken:jjwt-jackson:0.11.5'

    //Spring WebFlux
    implementation 'org.springframework.boot:spring-boot-starter-webflux'

OAuth2, JWT, webflux 설정을 추가해준다

Web Client 설정

카카오 api와의 통신을 위해 WebClientConfig를 추가

 @Configuration
public class WebClientConfig { // Spring WebFlux에서 HTTP 요청을 비동기로 처리하기 위한 WebClient를 설정

    // Netty HTTP 클라이언트 설정
    @Bean
    public ReactorResourceFactory resourceFactory() {
        ReactorResourceFactory factory = new ReactorResourceFactory();
        factory.setUseGlobalResources(false);
        return factory;
    }

    @Bean
    public WebClient webClient() {
        // HTTP 클라이언트 설정
        Function<HttpClient, HttpClient> mapper =
                client ->
                        HttpClient.create()
                                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 1000) // 연결 시간 초과 1초로 설정
                                .doOnConnected(
                                        connection ->
                                                connection
                                                        .addHandlerLast(new ReadTimeoutHandler(10))
                                                        .addHandlerLast(new WriteTimeoutHandler(10))) // 읽기 및 쓰기 시간 초과 10초로 설정
                                .responseTimeout(Duration.ofSeconds(1)); // 응답 시간 초과 1초로 설정

        // HTTP 클라이언트와 연결
        ClientHttpConnector connector = new ReactorClientHttpConnector(resourceFactory(), mapper);

        // WebClient 생성
        return WebClient.builder().clientConnector(connector).build();
    }
}

https://velog.io/@win-luck/Springboot-카카오-소셜로그인-Jwt-토큰-발급-및-API-검증 해당블로그 참고했습니다

카카오 로그인 API 구현

1. Authorization Code 받아오기 (프론트)

https://kauth.kakao.com/oauth/authorize
?client_id=${REST_API_KEY}
&redirect_uri=${REDIRECT_URI}
&response_type=code

클라이언트에서 카카오 로그인 버튼을 누르면 (해당 주소로 요청을 보내면) 카카오 인증 서버로 요청이가고 Redirect URI에 code가 전달된다.

http://localhost:8080/kakao/callback?code={코드번호}

해당 코드번호를 서버로 넘겨주면 됨

2. Authorization Code를 통해 Access Token 받아오기 + Access Token을 통해 사용자 정보 가져오기

AuthController

@RequiredArgsConstructor
@RestController
@RequestMapping("/api/v1/auth")
@Tag(name = "Auth", description = "인증 API")
public class AuthController {

    private final KakaoAuthService kakaoAuthService;

    @Operation(summary = "카카오 로그인", description = "카카오 로그인을 진행합니다.")
    @GetMapping("/login/kakao")
    public ResponseEntity<ApiResponse<Object>> kakaoLogin(@RequestParam String code) {

        return ResponseEntity.status(HttpStatus.OK)
                .body(ApiResponse.from(kakaoAuthService.kakaoLogin(code)));
    }
}

kakaoAuthService

@RequiredArgsConstructor
@Service
@Slf4j
@Transactional(readOnly = true)
public class KakaoAuthService {

    private final KakaoApiClient kakaoApiClient;
    private final JwtTokenProvider jwtTokenProvider;
    private final UserService userService;

    @Transactional
    public String kakaoLogin(String code) {
        String accessToken =
                kakaoApiClient.getAccessToken(code); // 1. Authorization Code를 Access Token으로 교환

        Long userId = isSignedUp(accessToken); // 2. Access Token을 이용해 사용자 정보를 가져오고 없으면 회원가입

        HashMap<Long, String> map = new HashMap<>();
        map.put(userId, jwtTokenProvider.createToken(userId.toString())); // 3. JWT 토큰을 생성하여 반환한다.

        return map.get(userId);
    }

    @Transactional
    public Long isSignedUp(String token) {
        KakaoUserInfoResponse userInfo = kakaoApiClient.getUserInfo(token);
        return userService.findOrCreateUser(userInfo);
    }
}

KakaoApiClient

@RequiredArgsConstructor
@Slf4j
@Component
public class KakaoApiClient { // kakao API를 호출하기 위한 전용 class

    private final WebClient webClient;
    private static final String USER_INFO_URI = "https://kapi.kakao.com/v2/user/me";
    private static final String TOKEN_REQUEST_URI = "https://kauth.kakao.com/oauth/token";

    @Value("${KAKAO_API_KEY}")
    private String kakaoApiKey;

    @Value("${KAKAO_REDIRECT_URI}")
    private String kakaoRedirectUri;

    // 카카오 API 호출 : Authorization code -> Access Token
    public String getAccessToken(String code) {
        try {
            KakaoTokenResponse response =
                    webClient
                            .post()
                            .uri(TOKEN_REQUEST_URI)
                            .header("Content-Type", "application/x-www-form-urlencoded")
                            .bodyValue(
                                    "grant_type=authorization_code&client_id="
                                            + kakaoApiKey
                                            + "&redirect_uri="
                                            + kakaoRedirectUri
                                            + "&code="
                                            + code)
                            .retrieve()
                            .bodyToMono(KakaoTokenResponse.class)
                            .block();

            return response.accessToken();

        } catch (WebClientResponseException e) {
            throw new RuntimeException("Failed to fetch access token from Kakao.", e);
        }
    }

    // 카카오 API 호출 : Access Token -> 사용자 정보 조회
    public KakaoUserInfoResponse getUserInfo(String token) {
        try {
            return webClient
                    .get()
                    .uri(USER_INFO_URI)
                    .header("Authorization", "Bearer " + token)
                    .retrieve()
                    .bodyToMono(KakaoUserInfoResponse.class)
                    .block();
        } catch (WebClientResponseException e) {
            throw new RuntimeException("Failed to fetch access token from Kakao.", e);
        }
    }
}

여기가 카카오 api와 통신하는 전부라고 보면되는데 먼저 코드를 토큰으로 교환해주기 위해서 getAccessToken을 호출한다. oauth/token 으로 apikey, redirect uri, code를 보내고 토큰을 받으면 된다. 여기까지 하면 카카오 서버에 회원이 등록된 것이라고 보면된다.

토큰을 받으면 이 토큰을 통해 카카오 api에서 사용자 정보를 조회할 수 있다. getUserInfo 메소드를 통해 먼저 카카오 api에서 정보를 가져오고 이 정보가 데이터베이스에 저장되어있지 않은경우(신규 유저의 경우)에는 리포지토리에 저장해준다. 이부분은 userService에 자유롭게 작성하면된다.

이를 위해 작성해준 dto들이다.

public record KakaoAccount(
        Boolean profile_needs_agreement,
        Boolean email_needs_agreement,
        KakaoProfile profile,
        String email
) {}

public record KakaoProfile(
        String nickname,
        String profile_image_url // 프로필 이미지 URL
) {}

public record KakaoProperties(
        String profile_image, 
        String thumbnail_image
) {}

public record KakaoTokenResponse(
        @JsonProperty("access_token") String accessToken,
        @JsonProperty("token_type") String tokenType,
        @JsonProperty("expires_in") int expiresIn,
        @JsonProperty("refresh_token") String refreshToken,
        @JsonProperty("scope") String scope) {}

public record KakaoUserInfoResponse(
        Long id, 
        KakaoProperties properties,
        KakaoAccount kakao_account) {}

kakao developers 에서 설정했던 것들 토대로 필요한것들만 받아와주면 된다. https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api#req-user-info REST API > 사용자 정보 가져오기 에서 properties, profile에 대해 자세히 볼 수 있다.

JWT토큰을 생성해서 반환하기

@RequiredArgsConstructor
@Component
public class JwtTokenProvider {

    @Value("${spring.jwt.secret}")
    private String secretKey;

    @Value("${spring.jwt.access.token.expiration}")
    private long accessTokenExpiration;

    private final UserDetailsService userDetailsService;

    // 객체 초기화, secretKey를 Base64로 인코딩
    @PostConstruct
    protected void init() {
        secretKey = Base64.getEncoder().encodeToString(secretKey.getBytes());
    }

    // JWT 토큰 생성
    public String createToken(String userId) {

        Claims claims = Jwts.claims().setSubject(userId); // JWT payload 에 저장되는 정보단위
        Date now = new Date();
        return Jwts.builder()
                .setClaims(claims) // 정보 저장
                .setIssuedAt(now) // 토큰 발행 시간 정보
                .setExpiration(new Date(now.getTime() + accessTokenExpiration)) // 토큰 유효시간 설정 (5시간)
                .signWith(SignatureAlgorithm.HS512, secretKey) // 암호화 알고리즘, 시크릿 키 설정
                .compact();
    }

jwt secret key와 만료시간은 env 파일에 저장해주었다. jwt secret key는 아무거로나 해도 되는데 HS512 알고리즘 사용을 위해서는 최소 512비트 이상으로 설정해줘야한다.

여기까지하면 카카오 로그인 + jwt 토큰 완료! swagger를 통해 확인해보겠다코드를 넣고 excute를 하면 아래와 같은 jwt 토큰을 발급해준다이 토큰을 Authorize에 넣고 로그인해주면 인증완료

그러나 토큰을 제대로 사용하려면 모든 요청에 포함시켜야하고 유효성 검사하는 로직등이 필요하다. 다음에는 자동 필터링 과정과 컨트롤러에서 사용할수있는 예시에 대해 알아보자.

📌 고민되는것들

• 웹기준으로 작성했는데 안드로이드 환경에서도 잘 돌아갈까?
• code를 프론트에서 넘겨주는 절차가 잘 작동할지?

참고 블로그 🙇 https://velog.io/@win-luck/Springboot-카카오-소셜로그인-Jwt-토큰-발급-및-API-검증 https://velog.io/@jiwoow00/Spring-boot-JWT-이용한-백엔드-카카오-로그인

spring:
  config:
    activate:
      on-profile: local
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: 'jdbc:mysql://localhost:3306/name'
    username: ${SPRING_DATASOURCE_USERNAME} # ex) root
    password: ${SPRING_DATASOURCE_PASSWORD} # ex) 0000
  jpa:
  ...

yml 파일에서 ${} 이 부분에 각자 값을 넣어서 로컬 DB에 접근하는 방식이다. DB 접근은 잘되지만, 모르고 git에 푸시해버릴 수 있는 위험성이 있으므로 env파일을 통해 관리해보기로 했다.

Spring Boot 2.4 이상에서는 spring.config.import 기능을 사용하여 .env 파일을 쉽게 로드하고, 이를 application.properties에서 사용할 수 있다.

1. 루트 디렉토리에 .env 파일 생성

#로컬 DB
DB_USER= ex) root
DB_PASS= ex) 0000
DB_URL= ex) jdbc:mysql://localhost:3306/name

왼쪽에는 변수명 오른쪽에는 사용할 유저명, 비밀번호, URL등을 입력해주면 된다. "" 또는 '' 사용할 필요 X!!

2. gitignore에 추가 gitignore에 .env를 추가해준다. 추가가 제대로 되었다면 .env파일이 이렇게 노란색으로 보인다

3. 기존 yml파일 수정

  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: ${DB_URL}
    username: ${DB_USER}
    password: ${DB_PASS}

env파일에서 설정한 변수명을 ${변수명} 형식으로 yml파일에 넣어준다

4. yml파일에 .env import 3번까지 했는데 위와 같은 에러가 떴다. .env 파일에서 설정된 DB_URL 값이 Spring Boot의 application.properties에서 제대로 읽히지 않았다는 것... dotenv import, Config 작성 등등... 이것저것 다 시도해봤는데 결론은 이것

spring:
  config:
    import: optional:file:.env[.properties]  # .env import

yml파일에 이것만 추가해주면 끝!! 잘안되는 경우에는 env파일명이 제대로 설정되어있는지 검토하는 것을 추천한다...(나는 .env가 아니라 env로 해놔서 꽤 오래 찾음...;;)

1. ammend를 통해 PR 보낸 커밋을 수정하고 강제로 덮어쓰기

git add .
git commit --amend -m "메시지"
git push -f origin 메인브랜치

ammend 명령은 이전 커밋을 수정하여 새 커밋 메시지와 함께 덮어쓰는 명령어이다. 새 커밋을 생성하지 않고, 기존 커밋의 내용과 메시지를 변경한다. 장점은 PR에 불필요한 커밋 히스토리가 남지 않아 깔끔하다는 것 그러나 단점은 기존 커밋을 덮어쓰는 것이기 때문에 되돌리려면 귀찮아진다.

나는 원래 이 방법을 사용했었는데 수정을 여러번 해야할 경우에는 여러번 덮어쓰게 되다보니 제대로 반영이 안되는 상황이 많이 발생했었다.

ammend 명령어는 혼자 사용하는 리포지토리이거나, 또는 간단하고 적은 수정일때 사용하는 것을 권장한다!

2. PR에 새 커밋 추가 (권장 방법)

git add .
git commit -m "새로운 메시지"
git push origin 메인브랜치

현재는 ammend 없이 동일하게 add, commit, push 하는 방법으로 사용하고 있는데 위의 사진처럼 리뷰를 받은 후의 커밋 기록이 남는다. 이렇게 하면 기존 커밋을 보존 가능하고 변경 사항 확인이 쉽다는 장점이 있다!

PR 보낸 브랜치에 추가 작업을 할 때, 용도에 맞게 접근 방식을 선택해서 사용하도록 합시다~~

1. check out "메인 브랜치"
2. git pull
3. check out "작업할 브랜치"
4. git rebase "메인 브랜치"

나는 보통 위 순서대로 원격저장소에서 최신 반영사항을 가져오는데 이 중 4번 *rebase *에서 conflict가 발생한 상황이다.

rebase는 브랜치의 커밋을 다른 브랜치 위로 다시 정렬하여 깔끔한 커밋 히스토리를 만드는 데 사용한다.

hint를 보면 git rebase --continue, skip, abort가 있는데 각각 아래와 같은 용도로 사용한다

Continue Rebase 중 conflict가 발생하면 수동으로 해결한 후, Rebase를 계속 진행(continue로 계속 진행해주면 됨)

Skip conflict가 발생한 곳을 건너뛰고 rebase를 계속 진행 건너뛴 커밋 내용이 히스토리에서 사라질 수 있음

abort rebase를 중단하고 시작하기 전 상태로 되돌림 충돌이 너무 많은 경우에 사용할 수 있다

평범하게 conflict가 난 상황이라면 rebase --continue로 해결해주면서 진행하면 됨

그러나 답이 없는 경우.. rebase --abort : rebase 중단 git reset --hard origin/<branch-name> : 원격 브랜치를 강제로 덮어쓰기 위의 방법을 이용해서 강제로 해결?할 수 있다. 그러나 위의 경우 커밋하지 않은 내용, 로컬 커밋 등이 삭제되므로 신중하게 사용해야한다

첫째 줄에 50보다 작거나 같은 자연수 R과 C가 주어진다.

R개 줄에는 티떱숲의 지도가 주어지며, 문제에서 설명한 문자만 주어진다. 'D'와 'S'는 하나씩만 주어진다.

첫째 줄에 고슴도치가 비버의 굴로 이동할 수 있는 가장 빠른 시간을 출력한다. 만약, 안전하게 비버의 굴로 이동할 수 없다면, "KAKTUS"를 출력한다.

🔎 문제 정리

R행 C열의 지도 존재

• 고슴도치 (S)
  • 비버의 위치(D)까지 _최소 이동 횟수_로 이동해야함
  • 물과 돌 통과 불가
  • 물이 찰 예정인 칸으로도 이동 불가
  • 상하좌우로 이동
• * 물 ()**
  • 돌 통과 불가
  • 비버의 위치로 확장 불가
  • 상하좌우로 확장
• 빈곳 (.)
• 돌 (x)

🔎 문제 해결 순서

1. 고슴도치의 위치, 현재 맵 등 입력 정보를 받아준다

2. bfs() & flood()

3. 먼저 bfs()에서 flood() 호출

   물이 차오를 예정인 곳에 고슴도치가 방문 불가능 하므로 먼저 물이 차오를 곳을 검토해준다.

   check 배열에 못가는 곳은 -1로 체크

   • 동서남북으로 물 흐르도록
   • 이미 방문했거나 돌이 있는 곳으로는 X
   • 종료 노드로는 물이 흐를 수 X

4. 다시 bfs()로

   이때 BFS란? Breadth-First Search 그래프에서 탐색을 할때 깊게 탐색하는 것이 아니라 넓게 탐색하는 방법이다. 반대로 DFS는 깊게 그래프를 탐색하는 방식이다.

   BFS이므로 Queue를 사용한다. 반복문을 돌면서 check 배열에 이동횟수를 넣어준다.

   • 돌 or 물 있는곳 X
   • 이미 갔던곳 X
   • → 즉 0인 곳만 갈 수 있음

5. 종료노드에 도달못하면 false, 도달하면 true를 메인으로 넘겨준다

   • false : KAKTUS 출력
   • true : 이동 횟수를 출력

🔎 코드

package boj3055;

import java.io.*;
import java.util.*;

public class Main {
    static char[][] map;
    static int[][] check;
    static int[] DX = {1,-1,0,0};
    static int[] DY = {0,0,1,-1};
    static Queue<Node> water;
    static Node endNode;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        StringTokenizer st = new StringTokenizer(br.readLine());
        int R = Integer.parseInt(st.nextToken());
        int C = Integer.parseInt(st.nextToken());

        map = new char[R][C];
        check = new int[R][C];

        Node startNode = new Node(0,0); // 고슴도치 위치
        water = new LinkedList<>();

        // map 입력받기
        for(int i = 0; i < R; i++){
            String line = br.readLine();
            for(int j = 0; j < C; j++){
                map[i][j] = line.charAt(j);
                if (line.charAt(j)== 'S'){  // 시작
                    startNode = new Node(i,j);
                }else if(line.charAt(j) == '*'){    // 물
                    check[i][j] = -1;
                    water.offer(new Node(i,j));
                }else if(line.charAt(j) == 'X'){    // 돌
                    check[i][j] = -1;
                }else if(line.charAt(j) == 'D'){    // 종료
                    endNode = new Node(i,j);
                }
            }
        }

        boolean flag = bfs(R,C,startNode);
        if(!flag)   System.out.println("KAKTUS");
        else System.out.println(check[endNode.x][endNode.y]);
    }

     static boolean bfs(int r, int c, Node startNode){
        Queue<Node> queue = new LinkedList<>();
        queue.offer(startNode);

        int time = 0;

        while(!queue.isEmpty()) {
            time++;
            flood(r,c);    // 물 흐름

            int size = queue.size();
            while(size-->0) {    // 현재 큐에 있는 횟수만큼 반복
                Node node = queue.poll();
                int minTime = check[node.x][node.y];

                for (int i = 0; i < 4; i++) {
                    int dx = node.x + DX[i];
                    int dy = node.y + DY[i];

                    if (dx < 0 || dx >= r || dy < 0 || dy >= c) { // 범위
                        continue;
                    } else if (check[dx][dy] == 0) {
                        check[dx][dy] = time;
                        queue.offer(new Node(dx, dy));
                    }

                    if (dx == endNode.x && dy == endNode.y) // 종료노드 도달시 끝
                        return true;


                }
            }


        }
        return false;   // 종료노드에 도달 불가
    }

    static void flood(int r, int c) {
        int size = water.size();

        for (int i = 0; i < size; i++) {
            Node node = water.poll();

            for (int j = 0; j < 4; j++) {
                int dx = node.x + DX[j];
                int dy = node.y + DY[j];

                if (dx < 0 || dx >= r || dy < 0 || dy >= c) { // 범위 초과
                    continue;
                } else if (check[dx][dy] == -1) {   // 이미 방문 or 돌
                    continue;
                } else if (dx == endNode.x && dy == endNode.y) {
                    continue;
                } else {
                    check[dx][dy] = -1;
                    water.offer(new Node(dx, dy));
                }
            }
        }
    }
}
    class Node{
        int x, y;

        public Node(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }

먼저 시작하기에 앞서 클라이언트에서 서버로 요청 데이터를 전달할 때는 주로 다음 3가지 방법을 사용합니다.

• GET - 쿼리 파라미터
  • /...?username=hello&age=20
  • 메시지 바디 없이, URL의 쿼리 파라미터에 데이터를 포함해서 전달
  • 예) 검색, 필터, 페이징등에서 많이 사용하는 방식
• POST - HTML Form
  • content-type: application/x-www-form-urlencoded
  • 메시지 바디에 쿼리 파리미터 형식으로 전달 username=hello & age=20
  • 예) 회원 가입, 상품 주문, HTML Form 사용
• HTTP message body에 데이터를 직접 담아서 요청
  • HTTP API에서 주로 사용, JSON, XML, TEXT
  • 데이터 형식은 주로 JSON 사용
  • POST, PUT, PATCH

위의 두가지는 GET 쿼리 파라미터 전송 방식이든, POST HTML Form 전송 방식이든 형식이 같아 구분 없이 조회 가능하므로 요청 파라미터 조회 라고 합니다.

→ 즉 크게 2가지로 요청 파라미터 조회 방식, 메세지 바디 방식이 있습니다.

📌 @RequestParam

@RequestParam 애노테이션은 클라이언트가 전송하는 파라미터를 1:1로 받아서 바인딩할때 사용합니다.

@ResponseBody    
@RequestMapping("/request-param")
public String requestParam(
        @RequestParam("username") String memberName,
        @RequestParam("age") int memberAge) {

        log.info("username={} age={}", memberName, memberAge);
        return "ok";
    }

위의 예시 코드에서 /request-param?username=kim&age=20이라는 요청이 들어오면 → getParameter("username")을 통해 memberName에 값이 바인딩됩니다

• HTTP 파라미터 이름과 변수 이름이 같으면 (name=”xx”) 생략 가능 ex) @RequestParam String username
• String , int , Integer 등의 단순 타입이면 @RequestParam도 생략 가능 ex) String username
• 그러나 스프링 3.2부터 파라미터 이름 인식 문제가 발생하는 경우가 있으니 생략하지 않는 것을 추천합니다..(명시적으로도 생략하지 않는 것을 추천)

추가적으로 파라미터 필수여부(required), 기본값 적용(defaultValue)도 적용 가능합니다.

📌 @ModelAttribute

@ModelAttribute는 요청파라미터를 받아서 필요한 객체를 만들고 그 객체에 값을 넣어주는 과정 자동화시키는 애노테이션입니다.

@ResponseBody
@RequestMapping("/model-attribute")
public String modelAttribute(@ModelAttribute HelloData helloData) {
    log.info("username = {} age = {}", helloData.getUsername(), helloData.getAge());
    return "ok";
}

위의 코드 예시를 통해 과정을 살펴보겠습니다.

스프링 MVC는 @ModelAttribute가 있으면 생성자를 통해 HelloData를 객체 생성 → 요청 파라미터의 이름으로 HelloData 객체의 property를 찾음 (객체에 getxxx, setxxx 메서드가 있으면 xxx라는 프로퍼티를 갖고있는 것) → setter 호출해서 파라미터의 값을 바인딩

즉 해당 애노테이션을 사용하려면 생성자와 Setter함수가 필수적으로 있어야합니다

@ModelAttribute에서는 타입이 잘못들어가면 BindException이 발생합니다.

또한 @RequestParam과 동일하게 애노테이션 생략이 가능합니다.

• Stirng, int, Integer 등 단순 타입 : @RequestParam
• 나머지 : @ModelAttribute

📌 @RequestBody

@RequestBody는 Http 메시지 바디에 내용을 담아서 요청이 오면 이를 변환할 때 사용하는 애노테이션입니다. 메시지 바디로 들어온 메시지는 @RequestParam이나 @ModelAttribute로 당연히 읽을 수 없습니다.

@ResponseBody
@PostMapping("/request-body-string")
public String requestBodyString(@RequestBody String messageBody) throws IOException {
    log.info("messageBody = {}", messageBody);

    return "ok";
}

@ResponseBody
@PostMapping("/request-body-json")
public HelloData requestBodyJson(@RequestBody HelloData data) {
    log.info("username={}, age={}", data.getUsername(), data.getAge());
    return data;
}

String, JSON 타입 모두 @RequestBody 애노테이션을 통해 받을 수 있습니다. 받은 메시지 바디는 내부의 HttpMessageConverte가 알아서 String 또는 객체 타입으로 변환해줍니다.

이때 @ModelAttribute처럼 setter를 사용하는 것이 아니라 생성자를 통해 객체를 생성합니다.

주로 JSON -> 객체 타입 변환에 많이 사용됩니다.

응답의 경우에도 @ResponseBody를 사용하면 컨버터가 자동으로 변환해줍니다.

(컨버터에 관한 내용은 추후에 자세히 써보겠습니다..!)

✔️ 정리

🚗 산업공학과에서 컴퓨터학부로

사실 나는 21년도에 숭실대학교 산업정보시스템공학과(이하 산공)에 입학했었다. 고등학생 때는 하고 싶은 것을 잘 몰랐어서 이것저것 하다보니 결국 대부분 교과로 원서를 쓰게 되었다. 그래도 공대에 가고 싶다! 라는 막연한 생각은 있었기에 모두 공대로만 지원했었고 결과적으로 숭실대 산공과에 입학하게 되었다. 산공에 대해 간단하게 설명하자면 여기도 분야가 매우 넓어서 다양한 것들을 배우게 된다. 1학년때 들었던 것만 해도 경영 + 화학 + 프로그래밍 정도가 생각난다.

산공과의 프로그래밍 수업에서 처음 코딩을 접하게 되었는데 너무 너무 재미있었고 성적도 잘 나왔었다. 지금 생각해보면 함수 정도의 정말 간단한 수준이였는데 우매함의 봉우리에 빠졌었던 것 같다. 아무튼 이때 코딩에 흥미가 생겨서 개발자라는 진로를 처음으로 생각해보게 된 것 같다. 이를 위해 컴퓨터에 대해 더 자세히, 체계적으로 배워보고 싶어서 전과를 고려하게 되었다. 특별하게 한 활동이 없어서 여름방학 때 초등학교에서 진행했던 코딩교육과 프로그래밍 수업내용을 바탕으로 자소서를 제출했고 결과적으로는 전과에 성공했다.

💻 컴퓨터학부에서의 2, 3학년

전과 후 컴퓨터학부에서 들었던 2학년 수업들은 정말 어려웠었다... 객체지향, 자료구조, 알고리즘 등등 중요한 과목들이 2학년때 많은데 기초가 부족했었기에 따라가기 쉽지 않았고 하면서도 '이게 뭐지..?' 싶었던 때가 많았던 것 같다. 그렇게 2학년은 방황도 하고 이것저것 시도해보는 시간이였던 것 같다. 그러다보니 3학년때부터는 기초를 다시 쌓는 것과 전공 공부 열심히 하는 것이 자연스레 우선이 되었다. 어려웠던 내용도 여러번 다시보니까 이해가 되었고 이때 전공을 공부하는 방식도 나름대로 터득했던 것 같다.

🏃 앞으로 해야할일들

그러나... 아직 부족한 점이 너무 너무 많다. 그동안 너무 전공 과목들 공부하느라 여력이 없었던 것 같고 제대로 백엔드 공부를 해보고자 올해는 휴학을 하게되었다. 아래는 올해~내년 초까지 이루고 싶은 목표들이다.

1. 프로젝트 경험 쌓기 백엔드와 프론트 중에서 고민하다가 백엔드로 진로를 정하게 된지가 얼마 안되어서 프로젝트 경험이 부족하다. 디자이너, 프론트, PM등 여러 분야의 사람들과 협업하는 것에 대해 많이 배우고 싶다. 올해 목표는 시작하게 된 프로젝트들을 잘 완수하고 많이 배워가는 것이다!
2. 스프링과 자바 더 공부하기 단순히 사용하는 것이 아니라 제대로 알고, 이해하고 사용할 수 있었으면 좋겠다. 일단 스프링에 대해서는 듣고 있는 김영한님 스프링 강의를 꾸준히 듣고 적용해보면서 내것으로 만들고 싶다.
3. 블로그 꾸준히 & 잘 쓰기 현재 블로그에 있는 내용은 공부하면서 노션에 정리했던 내용을 백업하는 글이 대부분인 것 같다. 사람들에게 더 잘 읽힐 수 있고 의미 있는 글을 쓰기 위해 노력해봐야겠다.

💡 어떤 개발자가 되고 싶은가

당연히 자기할일은 잘해야한다고 생각한다. 그래서 먼저 깊이 있는 개발자가 되고싶다. (열심히 하자..!) 그리고 다음으로는 소통을 잘하는 개발자가 되어야한다고 생각한다. 프로젝트를 할때도 다양한 파트분들과 이야기하고 협력할 일이 많기에 소통의 중요성을 톡톡히 느끼고 있다. 마지막으로는 개발자가 되기를 선택한 이상 계속 발전해나가고 공부해야한다고 생각한다. 그래서 항상 나의 모토지만 느리더라도 꾸준한 개발자가 되고싶다!

이번 글을 쓰면서 지금까지의 시간을 되돌아보고 나의 생각을 정리해볼 수 있는 좋은 기회가 되었던 것 같다. 앞으로도 화이팅 ~❗️

5개의 집계함수 지원. 각 함수는 테이블의 속성에 지원가능하며, 하나의 value를 리턴

• avg
• min
• max
• sum
• count

select count(*) --()안에 key value가 들어가면 같은 결과
from student;

student 테이블에서 튜플의 개수를 리턴

null값이 있으면 세지 않는다

Select avg(salary), max(salary), min(salary)
from professor
where deptName= ’CS’;

: 컴퓨터학과의 교수들의 평균, 최대, 최소 연봉을 출력

Select count(distinct pID)
from teaches
where semester=’Fall’ and year=2014;

teaches 테이블

2014년 가을에 강의한 교수들의 아이디 반환

distinct를 사용했으므로 중복없이 : 한교수가 여러과목 했었어도 한개만 셈

ex) count(distinct gender) : 2 → (M/F니까)

Group By Clause

group by : 전체 테이블을 속성값으로 튜플을 분류하고, 나누어진 각 그룹에 대해 집계함수 적용

Select deptName, count(*)
from professor
group by deptName;

deptName 속성값으로 전체 튜플을 몇개의 그룹으로 나눈후에 각 그룹에 대해 count

Select deptName, avg(salary)
from professor
group by deptName;

professor 테이블에서 deptName 속성값으로 그룹을 분류한 후, 각 그룹에 대해 salary 속성의 평균값 구함

위의 두 예제에 대한 결과값

주의사항

Select deptName, pID, avg(salary)
from professor
group by deptName;

group by절에 나온 속성과 집계함수만이 select 절에 나올 수 있음

→ pID는 그룹수보다 많이 존재하므로 뭘 보여줘야하는지 선정불가

Select avg(salary)
from professor
group by deptName;

group by절에 나온 속성은 select절에 나오는 것이 좋으나 반드시 나와야하는 것은 아님

→ 위 예시의 경우 deptName 생략시 어떤 그룹에 대한 평균값인지 알 수 없음

Having Clause

group by절로 생성한 그룹에 대해 임의 조건을 명시하는데 사용

→ 반드시 group by가 먼저 나와야함! 없으면 잘못된 쿼리

Select deptName, avg(salary)
from professor
group by deptName
having avg(salary) > 6900;

deptName 기준으로 그룹 생성

→ 각 그룹에 대해 avg(salary) > 6900 조건 만족하는 절만 남김

→ 만족하는 절에 대해 select 뒤에 나오는거 출력

having : 각 그룹에 대해 적용하여 만족하는 그룹이 다음 단계로 이관됨

where : 각 튜플에 적용하여 조건을 만족하는 튜플이 grouping 등의 다음단계로 넘어가는 것

→ 둘이 동시에 존재하면 where절 조건이 먼저 적용되고 group by, having 순서로

employee(name, salary, dno) -- dno는 dnumber 참조하는 외래키
department(dnumber, dname, location)

다섯명 이상의 직원을 가진 부서에 대해, 부서의 이름과 $40,000이상을 버는 직원 수를 리턴

Select dname, count(*)                
from department, employee
where dnumber=dno and salary>40000
group by dname
having count(*)>5;

where 조건문이 가장먼저 실행되는데 여기서 salary > 40000이상인 직원튜플만 남게됨

→ 직원수를 먼저세고 salary를 비교해야함

Select dname, count(*) 
from department, employee
where dnumber=dno and salary>40000 and
dno in (select dno from employee             
                group by dno           
                having count(*)>5)
group by dname;

dno in (세트) : 세트안에 dno 존재시 참, 아닐시 거짓

→ 해당 문장 내부에서 직원수가 5명이상인 부서의 no 구할 수 있다

→ 하지만 이것도 문제 있다!

만약 관리처 부서의 직원이 10명인데 모두 40000불 이하의 연봉일때 : <관리처, 0> 튜플이 결과 테이블에 속해야하나 관리처 튜플이 결과에 전혀 속하지 않게됨

where절의 salary > 40000절에 의해 모든 직원 튜플이 사라져서 후에 dno in에 관리처가 속하게 되더라도 적용할 튜플이 없음

Null Values and Aggregates

count(*)을 제외한 집계 함수는 기본적으로 null값 무시

sum : 널값 무시하고 계산

만약 salary라는 속성의 모든 값이 널이라면?

→ count(salary) : 0리턴

→ 다른 모든 집계함수들 null 리턴

ex) sum(salary) : null리턴

Null Example

myTable 테이블

select count(hourWage) from myTable;
// 결과 2

count(*) 아니므로 null값 무시

Select count(distinct hourWage) from mytable;
// 결과 2

위에랑 같은 결과 나옴

마찬가지로 null은 무시

Select sum(hourWage) from mytable;

널값은 무시하고 연산 : (5000+6000)/2 = 5500 나옴

Select hourWage, count(*) from mytable group by hourWage;

group by hourWage하면 Null값을 하나의 값으로 취급

count(*)이므로 널값 무시하지 않는다

5.2 Joined Relations

join 연산은 2개의 relations을 받아 하나의 relation을 결과로 리턴한다

조인에 필요한거 2가지

• join type
  • inner : match하는것만 → inner 키워드 생략가능. join 연산은 inner join 의미
  • outer left : outer는 다 match 아닌것도
  • outer right
  • outer full
• join condition : match 기준 정함
  • nutural
  • on
  • using(A1,…An)

4*3 = 12가지의 join가능 + cartition product 3개

Outer Joins

외부 조인은 값 매치가 되지 않아 손실되는 정보를 유지하려고 하는 연산

일차적으로 조인연산을 수행하고, 조인 연산에서 제외된 튜플들을 널 값을 이용해 결과 테이블에 첨가

Join Conditions : 조인 조건

두 입력 테이블에서 어떤 조건으로 튜플이 매치되는지 결정하고, 어떤 속성이 결과 테이블에 나타나는지 결정

• natural

  공통되는 속성이 조인 속성

  공통되는 속성은 결과 테이블에 한번만 나온다

• on

• using(A1,…An)

  내추럴 조인과 비슷

  using(A1,…An) : A에 컬럼을 다 적으면 natural이랑 같은 셈

조인 연산 예시

myCourse inner join myPrereq 
on myCourse.cID = myPrereq.cID

내부 조인 : 매치가 되는 튜플만 결과 테이블에 나오게됨

매치조건 : on

→ on : pred 조건에 만족하는 것만 매치됨

myCourse left outer join myPrereq 
on myCourse.cID = myPrereq.cID

left outer join : 1차적으로 join한 후 left테이블인 myCourse의 튜플 다 살림

매치조건 위와 동일(하지만 매치안되는 것도 살아있다)

myCourse natural left outer join myPrereq
myCourse left outer join myPrereq using(cID)
-- 위 두개 동일한 쿼리

natural : 공통되는 속성이 조인속성이고, 속성 하나만 남김

left outer join

5.3 Nested Subqueries : 중첩 서브질의

SQL은 중첩되는 서브 질의에 대한 매커니즘 제공

서브쿼리는 다른 SQL 문장 안에 위치할 수 있는 select-from-where 문장임

set membership과 set comparison을 테스트할 때 자주 사용

Single-row Subquery = scalar subquery

단일 튜플을 반환하는 서브질의

Select name
from professor
where salary = (select salary from professor where pID=‘10’)           
            and pID <> ‘10’;
-- <>는 != 의미

괄호 안에 있는 서브질의는 1개의 튜플을 반환하므로 single row subquery = scalar subquery

= 기호는 반환값이 한개일때만 사용 가능

Select name
from professor
where salary =     (select max(salary)             
                                    from professor             
                                    where deptName=‘CS’);

max()값은 항상 단일값이므로 유효한 SQL 문장

IN Operator

in 연산자는 단일값이 다수값에 속하는지 검사

Select name, salary 
from professor
where pID in (10, 21, 22);

Select name, salary
from professor
where pID=10 or pID=21 or pID=22;

세명 다 있다면 다 리턴

속하는 것만 나온다고 보면됨

Comparison Operators

값 하나 간의 비교는 간단하나 값 하나와 여러값 간 비교는 간단하지 않음

SQL은 이를 위한 연산자(some, any, all, in)을 제공

(1 > 2) : false
(3 >all {2, 3}) : false // 모든조건이 만족해야하는데  아니므로
(3 >some {2, 3}) : true
(3 >any {2, 3}) : true     // any ≡ some

all : 모두 참이여야 참

some(또는 any) : 여러값 중 적어도 하나가 참이면 참

Some(any)절 정의

= some 은 속한다는 의미의 in 연산자와 동일

≠ some은 다수개중의 하나와도 같지 않으면 참인데 not in은 전체에 속하지 않아야 참이므로 동일하지 않음

(5 <some {0, 5, 6}) = true
(5 <some {0, 5}) = false // 모든 조건이 만족하지 않으므로
(5 =some {0, 5}) = true
(5 ≠some {0, 5}) = true (since 0 ≠ 5) // 하나만이라도 같지 않으므로 참

all절 정의

(5 <all {0, 5, 6}) = false // 모든조건이 만족해야하는데 아님
(5 <all {6, 7}) = true
(5 =all {4, 5}) = false
(5 ≠all {6, 7}) = true (since 5≠6 and 5≠7) // 모든조건이 !=를 만족

≠ all은 모든 원소와 동일하지 않아야 참이므로 not in과 동일의미

= all과 in은 동일하지 않음

Set Comparison Example

Select distinct T.name
from professor as T, professor as S
where T.salary > S.salary and S.deptName=’CS’; 

-- 위 아래 동일 

Select namefrom professor
where salary > some (select salary                  
                                            from professor                 
                                            where deptName=’CS’);

CS학과 교수 중 적어도 한명보다는 봉급이 많은 교수 이름 구하는 질의

Select name
from professor
where salary >all     (select salary             
                                            from professor             
                                            where deptName=’CS’);

-- 위아래 동일

Select name     
from professor     
where salary > (select max(salary)             
                                from professor             
                                where deptName=’CS’);

CS학과의 모든 교수보다 연봉이 높은 교수

*Correlated Subqueries * 중첩질의에서 외부 쿼리에서 사용되는 테이블과 내부 쿼리에서 사용되는 테이블은 서로 상관없어서, 내부 쿼리가 외부 쿼리에 상관없이 실행 가능

내부쿼리가 외부쿼리의 테이블을 참조하면 이를 상관서브질의(상관중첩질의)라고 함

• 서브쿼리는 외부 테이블에서 한 개의 튜플을 골라 이에대해 내부 중첩 질의 수행
• 시간 매우 많이 듦

exits Construct

exists : 인자 형태로 표현되는 서브질의의 결과과 존재하면 참을 반환함

→ 즉, 내부질의를 수행하여 결과 튜플이 반환되면 참

Select S.cID
from teaches as S
where S.semester = ’Fall’ and S.year= 2009 
            and exists (select *           
                                    from teaches as T         
                                    where T.semester = ’Fall’ and T.year= 2010               
                                                and S.cID = T.cID);

2009년 가을과 2010년 가을에 둘다 개설된 강의의 번호 구하는 쿼리

exits 표현을 사용하는 상관 중첩질의

외부 테이블을 S로 rename하고 이를 exits내부 절에서도 사용

exits without Correlation

상관 서브 질의를 사용하지 않는 exits 연산자 사용은 의미 없음

Select distinct sID        // nonsense query 
from student 
where exists (select cID // where절 다 빼도 의미 같음              
                            from course              
                            where deptName = ’CS’);

해당 쿼리는 중첩질의가 외부 질의문과 관련이 없음

for all 쿼리

for all 의미를 구현하는 연산자 SQL에서 제공 X → not exits 사용

Select S.sID, S.name
from student as S
where not exists ( (select cID               
                                        from course               
                                        where deptName = ’CS’)
                                        except (select T.cID            
                                                        from takes as T            
                                                        where S.sID = T.sID) );

X - Y = 공집합

→ X 가 Y에 속함을 의미

→ not exist (X except Y)로 구현

Unique Construct

unique 구성요소는 서브질의 결과에 중복성이 있는지 찾음

Select C.cID
from course as C
where unique (select T.cID                   
                            from teaches as T                   
                            where C.cID=T.cID and T.year=2009);

--위아래동일

Select C.cIDfrom course as C
where 1 >= (select count(T.cID)             
                        from teaches as T            
                        where C.cID=T.cID and T.year=2009);

2009년에 최대 1번 강의한 과목을 찾아라(1번 이하로 개설된 과목)

unique{<1,2>, <1,2>}        : false
unique{<1,2>, <1,3>}     : true
unique{<1,2>, <1,null>}     : true
unique{<1,null>, <1,null>}     : true

null값이 나오는 튜플은 중복으로 나와도 unique하다고 판단

unique(r)에서 만약 r이 공집합이면 unique(r)은 참

from절 서브질의

서브질의 from절 안에서 사용 가능

Select deptName, avgSalary
from (select deptName, avg(salary) as avgSalary         
            from professor         
            group by deptName)
where avgSalary > 6900;

Select deptName, avgSalary
from (select deptName, avg(salary)        
            from professor       
             group by deptName) as deptAvg(deptName, avgSalary)
where avgSalary > 6900;

Select deptName, avg(salary)
from professor
group by deptName
having avg(salary) > 6900;
-- 세개다동일 마지막은 from절 내 서브질의 안쓰고 having절 이용

평균연봉이 6900이상인 과 이름과 평균 연봉 구하기

Select max(totalSalary)
from (select deptName, sum(salary)          
            from professor          
            group by deptName) as deptTot(deptName, totalSalary);

-- 위아래 동일

Select sum(salary)
from professor     
group by deptName
having sum(salary) >= all (select sum(salary)
                                                  from professor
                                                  group by deptName);

총 연봉이 가장 높은 과의 총 연봉을 구하시오

lateral 절

from절에서 선행관계 또는 서브질의를 참조하게함

Select P1.name, P1.salary, avgSalary
from professor P1, lateral (select avg(P2.salary) as avgSalary                                  
                                                        from professor P2                                  
                                                        where P1.deptName= P2.deptName);

Select name, salary, avg(salary)         // syntax error
from professor
group by deptName;

name, salary, avg(salary)값 개수가 다 틀려서 틀린 쿼리

With 절

SQL 문장의 결과를 임시적으로 저장하는 효과

With     maxBudget(value) as         
            (select max(budget)        
            from department)
select deptName, budget
from department, maxBudget
where department.budget = maxBudget.value;

with deptTotal(deptName, value) as        
            (select deptName, sum(salary)        
                from professor        
                group by deptName),
            deptTotalAvg(value) as        
            (select avg(value)        
                from deptTotal)
select deptName
from deptTotal, deptTotalAvg
where deptTotal.value > deptTotalAvg.value;

deptTotal : deptName당 해당과에 속하는 교수의 봉급 합

deptTotalAvg : deptName당 교수봉급합의 평균값

*Scalar Subquery *

서브질의가 오직 한개의 속성을 반환하고 동시에 속성값으로 한개를 반환한다면, 서브질의가 연산식에서 값이 반환되는 어떤 곳이라도 나타날 수 있게함

→ 이런 서브질의를 scalar 서브질의라고함

Select deptName, (select count(*)             
                                    from professor p1            
                                    where d1.deptName = p1.deptName)
from department d1;

스칼라 서브질의 예시

5.4 Ranking

SQL 서버 : Select top(3) * from professor ordery by salary

// 상위 연봉 3인

MySQL : Select * from professor order by salary desc limit 3 offset 1;

// 상위 연봉 3인인데 최고 1명 제외

5.5 More Features

blob, clob : 대용량 객체 저장 관리

📖 데이터베이스 1: 이론과 실제, 이상호, 진샘미디어

📚 시험 준비 과정 & 후기

먼저 SQLD 노랭이 책을 전체적으로 한번 + 틀린것만 다시 -> 총 2회독 진행했습니다. 모르는 문제들은 데이터 전문가 포럼 카페에서 정말 많이 도움을 얻었습니다 👍

데이터 전문가 포럼 카페

풀면서 생소한 개념들이 꽤많길래 유선배 SQL 개발자 책도 뒤늦게 참고했습니다. (특히 ROLL UP 이런부분 설명 잘 되어있어서 요부분 헷갈리신다면 추천) 참고로 SQLD 시험이 2024에 개정이 된 것으로 알고있는데 22,23 책 참고해도 괜찮으니 아무거나 빌려 보시면 될 것 같습니다.

기출문제는 study with yuna 티스토리 참고했습니다. Study with yuna

54회 시험 난이도는 평이했던 것 같고 노랭이나 기출에서 한번쯤 본 문제들이 대부분이였던 것 같았습니다. 노랭이에 있는 엄청 복잡한 문제들 같은거는 전혀 안나온 것 같습니다.

📚 정리 요약 노트

https://cream-browser-e86.notion.site/SQLD-cb6c50a01ad84cf9a8c0bc50417cb9c0?pvs=4

공부하면서 정리한 내용입니다. 직접한거라서 빠진부분이 있을 수도 있지만 그래도 아까워서 올려봄..

암튼 끝!!

DBMS는 유저와의 의사소통을 위해 데이터베이스 언어를 제공해야하고, 사용자는 언어를 이용하여 요구사항을 표현

데이터베이스 언어 분류 - 기능적 관점

• DDL : Data Definition Language
• DML : Data Manipulation Language
• DCL : Data Control Language

데이터 언어 분류 - 표현 방식 관점

• Procedural : 절차적
• Non Procedural : 비절차적

Data Definition Language : DDL

데이터베이스 스키마에 대한 조작 담당하는 영역

스키마 생성, 삭제, 변경 등 담당

스키마에 관련되는 도메인, 데이터 제약 조건(ic)등을 표현할 수 있는 기능 제공

DDL 컴파일러는 데이터 사전에 저장되는 테이블을 생성함

ex)

Create table professor (        
        pID                char(5),            
        name               varchar(20),               
        deptName      varchar(20),                
        salary               numeric(8,2));

Data Manipulation Language : DML

데이터의 인스턴스를 조작하는 언어

데이터 갬색, 생성, 조회, 삭제, 변경 등 기능 제공

사용자는 DML을 이용하여 질의를 생성하여 DBMS에 전달처리하게 하는데, 이런 측면에서 query language라고도 함

Data Control Language : DCL

스키마와 인스턴스 제외한 다른 객체 조작

• 트랜잭션 시작/종료
• 세션 시작/종료
• 백업/복구
• 데이터 권한 부여 및 취소
• 사용자 계정 관리

Procedural vs Declarative : 절차적 vs 비절차적

Procedural 절차적 언어

무슨 데이터를 요구하고 어떻게 데이터를 얻을 것인지 명시함 → 처리 방법 및 절차 명시

대부분의 언어는 prodecural → ex) 관계대수, C, C++, java…

Non Procedural(Decalrative) 비절차적 언어

어떻게 얻을 건지에 대한 내용없이 무슨 데이터가 필요한지만 명시 → 방법 및 절차 X 원하는 데이터만 명시

ex) SQL, PRolog, Lisp

비절차적 언어가 절차적 언어보다 진보된 언어. 하지만 컴퓨터 관점에서는 어렵고 복잡하다.

Relational Database Languages : 관계형 데이터베이스 언어

순수 관계형 데이터베이스 언어

이론적으로 개발되어있으나 상용 시스템에 구현되지 않은 언어

• 관계 대수
• 튜플 관계 해석
• 도메인 관계 해석

→ 세개 모두 질의어 표현력이 동일하고 언어간 상호변환 가능

실제 시스템에서 구현되어 있는 언어

• SQL
• QUEL
• Query by Example
• LDL

SQL Overview

= Structed Query Language의 약어

관계형 데이터베이스 언어

DDL + DML + DCL을 모두 포함하는 언어

관계형 데이터 베이스에서 사실상의 공식적인 표준 언어

3.2 DDL SQL

SQL언어의 DDL부분은 다음과 같은 것들을 정의함

• 관계 스키마
• 속성의 도메인
• 무결성 제약(ic)
• 관계에 연관되는 인덱스
• 관계 저장을 위한 물리적 저장 구조

⇒ 테이블과 컬럼 정의하는 명령어. 생성, 수정, 삭제 등의 데이터 전체 골격 결정

⇒ 데이터베이스의 데이터를 정의하는 언어로, DB관리자가 주로 사용. 스키마, 도메인, 테이블, 뷰, 인덱스 등을 정의하거나 변경, 삭제

SQL 명칭은 대소문자 구분이 없다 → Name = NAME = name = nAmE

인용부호 내에서는 대소문자 구분

세미콜론은 문장의 끝을 표시

Domain Types in SQL

char(n) : 길이가 n인 고정 길이 문자 스트링

varchar(n) : 최대 길이가 n인 가변 길이 문자 스트링

int : integer

smallint : Small integer

numeric(p, d) : 소수점 이하 자릿수 지정. p는 유효숫자 개수이고 d는 소수점 뒤에 나오는 숫자개수

→ ex) numeric(5,2) : xxx.xx 형태

real, double precision

float(n) : 소수점이 n자리 이상 나타내는듯?

Create Table

create table 문장은 새로운 테이블 정의하여 생성함.

Create table R     
        (A1 D1,     
            ...,      
            An Dn,    
            (integrity-constraint1),     
            ...,     
            (integrity-constraintk));

R : relation 이름

각각의 A : relation에 있는 속성의 이름

D : 속성 A의 데이터타입 → 즉, 도메인

마지막에는 관련 데이터 무결성 제약이 나옴

Example)

Create table professor (      
        pID           char(5),        
        name         varchar(20) not null,       
        deptName      varchar(20),        
        salary           numeric(8,2));

- Insert into professor values (‘10’, ’Lee’, ’CS’, 7500);
- Insert into professor values (‘11’, ‘Choi’, ’CS’, 7000);

professor 테이블을 정의하며, 4개의 속성 가짐

각각 이름과 데이터 타입 정의함

두번째 name 속성은 널값을 허용하지 않는 not null 무결성 제약을 갖고 있음

→ Insert : professor 테이블에 튜플을 추가하는 명령어

위의 두개 insert 명령을 수행하면 두개의 튜플이 생성됨.

인용부호는 데이터타입이 문자형일때 사용. 기본적으로 single quote

Integrity Constraints : 무결성 제약

주로 세가지를 많이 사용

• not null : 널 값 허용 X
• primary key(A1, …, An) : 테이블의 주 키 선언
• foreign key(A1, …, An) references R : 외래 키 선언

Create table professor (    
        pID             char(5),       
        name         varchar(20) not null,         
        deptName    varchar(20),     salary         numeric(8,2),         
        primary key (pID),       
        foreign key (deptName) references department);

주키 : pID

외래키 : deptName → department 테이블을 참조하는 외래키

→ 속성을 명시적으로 언급하지 않아도됨. 외래키는 참조되는 테이블의 주키만 참조하므로

→ 언급한다면 foreign key (deptName) references department(department의 주키); 이런식으로

무결성 제약은 선언시 이름 명기 가능 : 후에 제약 삭제/변경 용이

→ ex) constraint myFirstForeignKey foreign key (deptName) references department;

University Database Creation

Create table department (    
        deptName    varchar(20) primary key, //주키가 한개일땐 이런식으로 가능
        chairman    char(5),    
        building        varchar(30),     
        budget        numeric(10,0)    
        foreign key (chairman) references professor);
        -- foreign key (chairman) references professor(pID);로 참조 속성 명시할 수도 있음

Create table professor (     
        pID               char(5) primary key,          
        name           varchar(20) not null,      
        deptName     varchar(20),    
        salary        numeric(10,2),         
        foreign key (deptName) references department); 

Create table student (     
        sID               char(5) 
        primary key,          name           varchar(20) not null,    
        gender        char(1),     
        deptName     varchar(20),    
        GPA        numeric(3,2),    
        totalCredit    integer,         
        foreign key (deptName) references department),     
        check (gender in (‘F’, ‘M’)));
        -- gender 속성은 'F' or 'M'만 가져야하는 제약

Create table course (    
        cID        char(5) primary key,    
        title        varchar(20),    
        deptName    varchar(20),    
        credit        integer,    
        foreign key     (deptName) references department);    

Create table teaches (         
        pID            char(5),        
        cID         char(5),        
        semester      char(10),         
        year           numeric(4,0),        
        classroom      char(5),    
        primary key     (pID, cID, semester, year), // 주키가 4개 속성의 조합       
        foreign key     (pID) references professor,    
        foreign key     (cID) references course,    
        foreign key     (classroom) references room);

Create table takes (         
        sID            char(5),        
        cID         char(5),        
        semester      char(10),         
        year           numeric(4,0),        
        grade           varchar(2),    
        primary key     (sID, cID, semester, year),        
        foreign key     (sID) references student,    
        foreign key     (cID) references course);

Create table room (    
        roomID     char(5) primary key,       
        building      varchar(30),         
        capacity    numeric(6,0));

Drop/Alter Table

Drop : 스키마 삭제

→ ex) Drop table student;

Alter : 스키마 변경

Alter table r add A D;
Alter table r drop A; 

Alter table student add constraint myConst foreign key (deptName) references DEPARTMENT on delete cascade;
-- 이런 예시도 있다

1. r 이라는 테이블에 A라는 속성을 추가. D는 A의 도메인
2. A는 r이라는 테이블의 속성을 제거

Drop vs Delete

Drop : 스키마 전체를 삭제하는 DDL 기능. 테이블전체를 날려버림. 그니까 당연히 내용도 날아감

→ ex) Drop table student; // student 테이블 전체 삭제

Delete : 테이블의 내용(즉, 튜플)을 삭제하는 DML 문장. 테이블 스키마는 남아있음

→ ex) Delete from student; // student 테이블의 내용 삭제

DDL에서 중요한 키워드 3개 : CREATE / ALTER / DROP

3.3 DML SQL

대표적인 키워드 4개

• Selecet : 검색
• Insert : 입력
• Delete : 삭제
• Update : 갱신

Insertion : 입력

insert 데이터베이스 튜플을 입력하는 연산

Insert into course values (’437’, ’Advanced Databases’, ’CS’, 4);
Insert into course (cID, title, deptName, credit)values (’437’, ’Advanced Databases’, ’CS’, 4);

위의 두가지 질의문 동일하다

Insert into course values (’777’, ’undecided’, ’CS’, null);

null이라고 명시하면 해당 속성에는 값이 들어가지 않음

Insert into professor select * from professor;

insert문장에 select from where 표현 사용가능

이렇게 할 시 select from where이 평가되기 전까지 튜플이 테이블에 입력되지 않음

해당 문장의 효과는 튜플개수가 2배되는 것

Deletion

Delete from professor;

professor 테이블에 있는 모든 튜플을 삭제함

튜플 삭제되어도 스키마는 존재

→ 스키마 삭제는 drop

Delete from professor where deptName=’EE’;

professor 테이블에서 과가 EE인 튜플 삭제

Delete from professor 
where deptName in (select deptName                
                                        from department                      
                                        where building = ’Vision Hall’);

중첩질의

Vision Hall에 있는 학과의 교수 튜플 제거

Delete from professor
where salary < (select avg(salary) from professor);

봉급이 교수 평균 봉급보다 작은 교수 삭제

1. 집계함수는 where절에 직접 나올 수 없으므로 중첩질의 사용

2. 교수가 삭제됨에 따라 평균 값도 변할 수 있는데, SQL에서는 처음에 평균값 계산하고 이를 근거로 연산 수행

Updates

Update ~ set ~ where

Increase salaries of professors whose salary is over 7000 by 3%, and all others receive a 5% raise을 SQL으로 표현

Update professor      
set salary = salary*1.03     
where salary > 7000;

Update professor        
set salary = salary*1.05    
where salary <= 7000;

교수 봉급을 인상하는 갱신 문장 : 봉급이 7000 이상이면 3% 나머지는 5% 인상한다.

update를 여러번 할 때는 순서가 중요함

→ 3%인상 후에 5% 인상하게되면 3%인상으로 7000 이상이 된 교수는 인상이 중복 적용됨

Update professorset salary = case            
                                                            when salary <= 7000 then salary*1.05            
                                                            else salary*1.03             
                                                        end;

case 사용하여 만든 동일한 갱신 문장

Update student S
set S.totalCredit =         
            (select sum(credit)            
            from takes natural join course         
            where S.sID=takes.sID and grade <> ’F’ and grade is not null);

student 테이블의 totalCredit 속성 값 갱신함.

grade 속성이 F가 아니고 grade가 널값이 아닌 과목의 credit 속성 값의 합을 구하여 totalCredit 값으로 갱신

set 절에서 scalar subquery가 사용됨

Update student
set totalCredit = 0
where totalCredit is null;

만약 어떤 학생이 과목을 하나도 이수하지 않았다면 sum(credit)은 널값이 나옴

→ 이를 0으로 갱신하고자 하면 위의 갱신문 사용하면됨

3.4 Select SQL Statements

select 절

select A1, A2, ..., An        -- 생략 불가 attribute list    
from R1, R2, ..., Rm        -- 생략 불가 relation list    
where P            -- selection predicate    
group by <grouping attributes>    
having <conditions>    
order by <ordering attributes>;

select 6개의 절 가질 수 있음

select와 from은 생략불가. 나머지는 생략가능하나 순서 지켜야함

having 절은 group by절이 나와야만 나올 수 있음

select 문의 결과는 relation

Select name  
from professor;
-- professor 테이블에서 교수 이름이 있는 name 속성 열만 출력

select 절은 질의 결과에서 사용자가 보고 싶은 속성 리스트를 가짐

→ 관계 대수의 project 연산과 대응됨

Select *        
from professor;
-- professor 테이블 출력

*는 ‘모든 속성’을 의미한다

Select pID, name, deptName, salary/12
from professor;
-- professor 테이블에서 해당속성들을 차례로 보여줌 
-- salary/2도 자동연산해서 보여줌 -> 당연하지만 값이 아예 바뀌는 것은 아님

select 절에 나오는 속성은 수식 표현도 가능하다

Select distinct deptName
from professor;
-- 중복제거하고 학과 이름 보여줌

SQL은 결과 테이블의 튜플의 중복 허용

→ 허용하지 않으려면 select 절에 위치하는 속성에 distinct 키워드

위의 예제처럼 하면 중복되는 학과의 이름은 제거

Select all deptName      
from professor;
-- 학과 이름만 보여줌
-- Select deptName from professor;과 동일

all 키워드는 중복 허용

디폴트이기때문에 생략해도 똑같음

where 절

where 절은 결과 튜플이 만족해야하는 조건을 명시함

→ 관계대수의 select 연산에 대응

from professor
where deptName = ‘CS' and salary > 8000;

CS과이면서 연봉이 8000 이상인 교수를 검색하는 질의

and, or, not 같은 논리연산자 사용 가능. 적용순위는 산술연산자보다 후 순위

from 절

from절에는 질의에 관련있는 테이블을 나열해야함

→ 관계 대수의 카티시안 곱 연산에 대응

Select *
from professor, teaches;

가능한 모든 professor, teacher의 쌍을 생성함. 카티시안곱 연산 결과를 리턴하는 질의

SQL Execution Model : 실행 과정

from절에 명시된 각 테이블에서 하나의 튜플을 가져온다

→ where절에 명시된 조건에 적용

→ 참이라면 튜플을 group by절로 보냄 : from절에 있는 모든 조합의 튜플에 대해 위의 과정 실행

→ group by절에 명시된 속성을 이용하여 서브그룹을 생성

→ 각 그룹에 대해 having 절의 조건을 적용하여, 조건을 참으로 만드는 서브그룹을 구함

→ 서브그룹에 대해 order by 절을 적용하여 디스플레이

Joins

조인은 where절에서 명시할 수 있음

Select name, cID
from professor, teaches
where professor.pID=teaches.pID;

where절의 =는 professor테이블의 pid속성과 teaches테이블의 pid 속성간의 equi조인 표현

→ equi조인 : 두 테이블의 중복되는 속성(여기선 Pid)가 같은것만 남김

⇒ 즉 pID를 기준으로 두 테이블을 합치는것

→ 여기서 pID 속성이 두번나오므로 하나를 제거하게되면 : natural join

pID속성이 두 테이블 모두에 존재하므로 속성이름만 사용하면 혼돈 발생 가능 → 테이블 이름도 명시

Select title, name
from teaches, course, professor
where teaches.cID=course.cID and teaches.pID=professor.pID 
and course.deptName=‘CS‘;

teaches, course, professor간에 equi조인이 필요한 질의

deptName은 course와 professor 모두에 존재하므로 course.deptName으로 표현

Natural Joins

natural join

자연조인은 두 테이블에서 동일한 이름을 가지는 속성간에 조인연산을 적용하며 결과 테이블에는 조인속성에 대한 중복이 제거하여 한번만 나옴

Select *     -- 8 attributes 
from professor natural join teaches;

professor 테이블과 teaches 테이블에는 pID 속성이 공통존재

→ 둘 중 하나는 제거됨 : 총 속성 8개 테이블 리턴

Select *    -- 9 attributes but semantically equivalent
from professor, teaches
where professor.pID=teaches.pID;

이렇게하면 professor.pID와 teaches.pID 두 속성 모두 테이블에 나오게되므로 총 9개의 속성 테이블을 리턴하게됨

동일한 이름을 가진 속성으로 인해 원하지 않은 조인 연산이 일어나지 않도록 주의해야함

교수 이름과 그 교수가 강의하는 과목명을 검색하는 질의어를 만들어보자

Select name, title
from professor natural join teaches natural join course;

위의 질의는 틀린것

deptName이 professor, course테이블에 공통 속성으로 존재 : 이 속성에 대해 Natural join

→ 교수가 소속학과에서 한 수업만 나오게됨

→ 교수가 다른학과에서 개설한 교과목 정보 포함안됨 : Wrong!

Select name, title
from professor natural join teaches, course
where teaches.cID= course.cID;

Select name, title
from (professor natural join teaches) join course using(cID);
-- using : 동일한 이름을 가진 모든 속성 X, 명시된 속성만을 조인 속성으로 하는 것

Select name, title
from teaches, course, professor
where teaches.cID=course.cID and teaches.pID=professor.pID;

Rename Operations

as 키워드를 통해 테이블과 속성 재명명 가능

→ old-name as new-name

Select pID, name, salary/12 as monthlySalary
from professor;

salary/12를 monthlySalary로 재명명 → 영구적으로 바뀌는건 아님. Select문은 다 그럼

Select sID, name myName, deptName
from student;         -- “name” is renamed
Select sID, name, myName, deptName
from student;         -- wrong attribute name, syntax error

키워드 as는 생략가능 : 생략하려면 as만 그냥 빼면됨

1. as를 생략하고 name을 myName으로 재명명한 것
2. 4개의 속성 테이블을 리턴하는 문장 → wrong!

Select distinct T.name -- T.name이라고 있어도 이렇게 출력되는것 아님. name이라고 나옴
from professor as T, professor as S
where T.salary > S.salary and S.deptName = ‘CS’;
-- 소프트웨어 학부의 최소 아무 1명보다 돈을 많이 받는 사람들의 목록
-- 최저가 6000이니 그 이상인 사람들(중복 없이)

두번 재명명도 가능

원래 from절에 명기된 모든 테이블에서 한개의 튜플을 가져와서 where절 조건 적용

→ from절에 동일 테이블 두번 재명명

→ professor 테이블에서 한번에 두개 튜플 가져오는 효과

→ 비교 연산할 때 사용

String Operations

like 연산자는 패턴을 활용하여 스트링에 대한 비교연산 제공

% : 길이에 무관한 임의 스트링 → 몇개의 문자가와도 상관없다는 의미

_ : 하나의 character

Select name
from professor
where name like '%da%‘;

da가 이름중에 아무곳이나 들어가있는 교수이름 검색

→ ex) dda(O) da(O) dan(O)

select name    
from professor
where name like '%n_';    

1개의 스트링이 와야함을 의미

→ ex) yang(O), han(X)

Select cID
from course
where title like ‘100\%'  escape  '\';

100%를 가지는 스트링을 검색하는 질의

%를 임의의 스트링을 의미하게하지말고 퍼센트 기호로 인식하게 하기위해 탈출 기호 사용

Tuples Ordering

order by : 결과 테이블의 튜플 정렬에 사용

Select distinct name
from professor
order by name;

기본값 오름차순 → a,b,…,c 순서로

내림차순으로 하려면 desc 키워드 추가 → ex) order by name desc

Order by deptName desc, name

한개 이상의 속성기준으로 정렬 가능

deptName값 기준 내림차순으로 1차정렬 후, 동일한 값 사이에서는 name 속성기준 오름차순 정렬

“Where” clause predicates : where 절 연산자

Select name
from professor
where salary between 5000 and 6000; -- 5000<= 이고 <=6000

between : 값 구간 의미함. 경계값 포함

Select name, cID
from professor, teaches
where (professor.pID, deptName) = (teaches.pID, ’CS’);
-- where professor.pID=teaches.pID and deptName='CS';과 동일

튜플 사이의 비교가능

괄호로 임시튜플 생성하여 비교하는 개념

Set Operations

union, intersect, except:차집합

자동으로 중복제거 → 안하려면 union all 이런식으로

// 튜플이 r 테이블에서 m번 나오고, s 테이블에서 n번 나올때
m+n times in “r union all s”
min(m, n) times in “r intersect all s”
max(0, m–n) times in “r except all s”

union : 두 입력 멀티셋을 중복 상관없이 더함

intersect : 튜플이 입력멀티셋 테이블에서 적게나오는 횟수만큼 결과 멀티셋 테이블에 나옴

Find course IDs that ran in Fall 2009 or in Fall 2010
(select cID from teaches where semester = ‘Fall’ and year = 2009) 
union
(select cID from teaches where semester = ‘Fall’ and year = 2010);

Find course IDs that ran in Fall 2009 and in Fall 2010
(select cID from teaches where semester = ‘Fall’ and year = 2009) 
intersect
(select cID from teaches where semester = ‘Fall’ and year = 2010);

Find course IDs that ran in Fall 2009 but not in Fall 2010
(select cID from teaches where semester = ‘Fall’ and year = 2009) 
except
(select cID from teaches where semester = ‘Fall’ and year = 2010);

2009 가을 or/and/but not 2010가을에 강의한 course IDs를 리턴

3.5 Null Values

튜플의 속성 값으로 널 값 가질 수 있음

Unknown : 값이 존재하는데 잘 모름

Not exist : 값 자체가 없음

널 값이 포함되는 산술연산의 결과는 널 값

→ ex) 5 + null = null

Select name
from professor
where salary is null;
-- where deptName=""; 이런건 틀린거

널값의 존재여부는 is null 사용

Three-valued Logic

널 값이 속한 비교연산자의 결과는 unknown

→ ex) 5 < null, null <> null 이런거 다 결과 unknown

따라서 비교연산자의 결과는 참, 거짓, unknown 3가지

OR:     
(unknown or true) = true           
(unknown or false) = unknown           
(unknown or unknown) = unknown

AND:     
(true and unknown) = unknown                 
(false and unknown) = false             
(unknown and unknown) = unknown

NOT:      
(not unknown) = unknown

where절에서 사용시 결과가 참인 경우만 사용자에게 반환

false, unknown은 둘다 반환X

true AND false -> take minimum of 1 and 0 -> 0 -> false
True OR unknown -> take maximum of 1 and 0.5 -> 1 -> true
Not false -> (1 – 0) -> 1 -> true
Not unknown -> (1 – 0.5) -> 0.5 -> unknown

true : 1, false : 0, unknown : 0.5

AND : 최소를 취함

OR : 최대를 취함

NOT : (1-value)를 취함

📖 데이터베이스 1: 이론과 실제, 이상호, 진샘미디어

m1맥 사용, gradle 기준 준비할 것 : 스프링 프로젝트, ec2 생성하고 프로젝트와 연결 -> 추후에 글쓰도록 하겠음 나중에 다시 볼 수 있도록 최대한 자세히 써보겠음

1. Dockerfile 생성

경로 참고

FROM amazoncorretto:17.0.7-alpine
COPY build/libs/*.jar shoppingmall.jar
ENV TZ Asia/Seoul
ENTRYPOINT ["java", "-jar","-Dspring.profiles.active=prod", "shoppingmall.jar"]

위의 내용을 Dockerfile에 넣어주도록 하자

jar파일 경로가 틀리면 에러 난다. 경로 잘 체크해서 넣어주도록 하자

스프링 3.x.x 버전은 자바 17버전

2. build.gradle 수정

bootJar {
    jar.enabled = true
}

jar {
    manifest {
        attributes 'Main-Class': 'com.testing.test.TestingApplication'
    }
    enabled = false
}

다음과 같은 내용을 추가해준다

3. jar 파일 빌드

./gradlew clean build -x test

3~5번 과정은 intelij ide console에서 입력

4. 도커 로그인 후 이미지 생성 이때 도커 계정이 필요하므로 없을시 회원가입 도커 허브를 켜놓은 상태라면 비밀번호 없이도 로그인 가능

docker login 
// 성공시 Login Succeeded가 뜰것임

로그인이 안되는 경우 (깃허브로 도커 회원가입) 도커 허브 > account setting > security > access token 발급 받기 $ docker login -u [사용자이름] 입력 후 password에 발급받은 토큰 넣어주면 로그인된다

로그인 후에 도커 이미지를 빌드해준다

docker build -t [유저이름]/[이미지명] --platform linux/amd64 .

m1 맥은 --platform 부분도 넣어줘야함

마지막에 .도 생략하면안된다

도커 데스크탑에서 images에 들어가면 생성된것 확인가능

docker images

명령어로도 확인 가능하다

5. 도커 이미지 push

docker push [사용자명]/[이미지명]

6. 터미널에서 ec2 인스턴스 접속 및 우분투 도커 설치

ssh -i [pem 키] ubuntu@[ip]

우분투에 도커 설치는 https://velog.io/@jbro321/Docker-Ubuntu-22.04.3에-docker-설치 해당 블로그 참고함

도커 잘 설치되었는지 확인하려면 docker -v 명령어 입력해보자

7. docker image pull & run

sudo docker pull [사용자명]/[이미지명]
sudo docker run -d -p 8080:8080 [사용자명]/[이미지명]

8. 사이트 접속해보기

접속할때는 public ip 주소:8080으로 접속해주면된다

*+) 참고사항들 *

Bind for 0.0.0.0:8080 failed: port is already allocated.에러 해결법 $ sudo lsof -i tcp:8080 위에서 실행중인 프로그램 pid로 종료시키기 $ sudo kill -9 [pid]

https://seulcode.tistory.com/557 위 블로그 참조하여 권한부여를 해줘야 재접속했을때도 제대로 작동한다

docker ps -a

를 통해서 콘테이너 목록들 확인한 후 안쓰는 컨테이너들 정리해주기

docker stop [id 또는 이름] docker rm [id 또는 이름]

컨테이너 실행 중지하고 지워주면됨

> 접속안될때 재접속 방법
똑같이 ec2 인스턴스 접속 후 

docker ps -a

위 명령어로 container id 혹은 콘테이너 이름을 확인한 후. 

sudo docker start [cotainer id 또는 이름]

``` 위 명령어를 통해 재접속

지금까지 우리는 스프링빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링이 종료될때까지 유지된다고 학습했다

→ 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문

→ 스코프 : 빈이 존재할 수 있는 범위

스프링은 다음과 같은 다양한 스코프 지원

• 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프
• 프로토타입 : 스프링컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프
• 웹 관련 스코프
  • request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프
  • session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
  • application : 웹의 서블릿 컨텐스와 같은 범위로 유지되는 스코프

빈 스코프는 다음과 같이 지정할 수 있다

@Scope("prototype")
@Component
public class HelloBean {...}

컴포넌트 스캔 자동 등록

@Scope("prototype")
@Bean
prototypeBean HelloBean() {
    return new HelloBean();
}

수동 등록

프로토타입 스코프

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈 반환

반면에, 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청
2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환
3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈 반환

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청
2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입
3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환
4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 생성해서 반환

정리

핵심은 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다는 것

클라이언트에 빈을 반환하고, 이후에는 스프링 컨테이너는 생성된 프로토타입 빈 관리 X

프로토타입 빈을 관리할 책임은 프로토타입 빈을 반환받은 클라이언트에 있다. 그래서 @PreDestory같은 종료 메서드가 호출되지 않는다

@Test
    void singletonBeanFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);

        SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
        SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);
        System.out.println("singletonBean1 = " + singletonBean1);
        System.out.println("singletonBean2 = " + singletonBean2);
        Assertions.assertThat(singletonBean1).isSameAs(singletonBean2);

        ac.close();
    }

    @Scope("singleton")
    static class SingletonBean{
        @PostConstruct
        public void init(){
            System.out.println("SingletonBean.init");
        }

        @PreDestroy
        public void destroy(){
            System.out.println("SingletonBean.destroy");
        }
    }

싱글톤 빈

@Test
    void prototypeBeanFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
        System.out.println("find prototypeBean1");
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        System.out.println("find prototypeBean2");
        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);

        System.out.println("prototypeBean1 = " + prototypeBean1);
        System.out.println("prototypeBean2 = " + prototypeBean2);

        Assertions.assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
    }

    @Scope("prototype")
    static class PrototypeBean{
        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init");
        }

        // 프로토타입빈은 close자체가 안됨
        @PreDestroy
        public void destroy(){
            System.out.println("PrototypeBean.destroy");
        }
    }

프로토타입 빈

싱글톤 빈 - 스프링 컨테이너 생성지점에 초기화 메서드 실행됨

프로토타입 빈 - 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화메서드도 실행됨

프로토타입 빈을 2번 조회했으므로 완전히 다른 스프링 빈이 2개 생성되고 초기화도 2번 실행됨

싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성, 의존관계 주입, 초기화까지만 관여하므로 종료메서드 실행안됨 → 빈.destroy()로 직접 종료해줄 수 있음

프로토타입 빈의 특징 정리

• 스프링 컨테이너에 요청할 때 마다 새로 생성
• 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여
• 종료메서드가 호출안됨
• 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야함. 종료 메서드에 대한 호출도 클라이언트가 직접 해야함

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

스프링 컨테이너에 프로토타입빈 요청시 항상 새로운 객체 인스턴스 생성해서 반환. 하지만 싱글톤빈과 함께 사용할때는 의도한대로 잘 동작하지 않으므로 주의해야한다

1. 클라이언트 A는 스프링 컨테이너에 프로토타입 빈 요청
2. 스프링 컨테이너는 프로토타입 빈을 새로생성해서 반환(”x01”). 해당 빈의 count 필드값 0
3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면 count 필드는 1이됨

결과적으로 프로토타입 빈(”x01”)의 count는 1

1. 클라이언트 B는 스프링 컨테이너에 프로토타입 빈 요청
2. 스프링 컨테이너는 빈 새로 생성해서 반환(”x02”). 해당 빈의 count 필드값 0
3. 클라이언트는 조회한 프로토타입 빈에 addCount()를 호출하면서 count필드 +1

프로토타입 빈(”x02”)의 count는 1

싱글톤 빈에서 프로토타입 빈 사용

이번에는 clientBean이라는 싱글톤 빈이 의존관계 주입을 통해 프로토타입 빈을 주입받아 사용하는 예를 보자

clientBean은 싱글톤이므로, 보통 스프링 컨테이너 생성 지점에 함께 생성되고, 의존관계 주입도 발생

1. clientBean은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다
2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean에 반환한다. 프로토타입 빈의 count 필드값은 0

이제 clientBean은 프로토타입 빈을 내부 필드에 보관

클라이언트 A는 clientBean을 스프링 컨테이너에 요청해서 받는다. 싱글톤이므로 항상 같은 clientBean이 반환됨

3. 클라이언트 A는 clientBean.logic() 호출
4. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가한다. count값이 1이됨

똑같이 클라이언트 B는 clientBean을 스프링 컨테이너에 요청해서 받는다. 싱글톤이므로 항상 같은 clientBean이 반환됨

여기서 중요한점 - clientBean이 내부에 가지고있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성된 것이지, 사용할 때마다 새로 생성되는 것이 아님!!

5. 클라이언트 B는 clientBean.logic() 호출
6. clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가한다. count값이 2가됨

public class SingletonWithPrototypeTest {

    @Test
    void prototypeFind(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        prototypeBean1.addCount();
        Assertions.assertThat(prototypeBean1.getCount()).isEqualTo(1);

        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
        prototypeBean2.addCount();
        Assertions.assertThat(prototypeBean2.getCount()).isEqualTo(1);
    }

    @Test
    void singletonClientUsePrototype(){
        AnnotationConfigApplicationContext ac =
                new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);
        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        Assertions.assertThat(count1).isEqualTo(1);

        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        Assertions.assertThat(count2).isEqualTo(2);
    }

    @Scope("singleton")
    static class ClientBean{
        private final PrototypeBean prototypeBean;  // 생성 시점에 주입

        @Autowired
        public ClientBean(PrototypeBean prototypeBean){
            this.prototypeBean = prototypeBean;
        }

        public int logic(){
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }

    }

    @Scope("prototype")
    static class PrototypeBean{
        private int count = 0;

        public void addCount(){
            count++;
        }

        public int getCount(){
            return count;
        }

        @PostConstruct
        public void init(){
            System.out.println("PrototypeBean.init "+this);
        }

        @PreDestroy
        public void destroy(){
            System.out.println("PrototypeBean.destroy");
        }

    }

}

스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다. 그런데 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것 이 문제다.

아마 원하는 것이 이런 것은 아닐 것이다. 프로토타입 빈을 주입 시점에만 새로 생성하는게 아니라, 사용할 때 마다 새로 생성해서 사용하는 것을 원할 것이다.

+) 참고 :

여러 빈에서 같은 프로토타입 빈을 주입 받으면, 주입 받는 시점에 각각 새로운 프로토타입 빈이 생성된다.

예를 들어서 clientA, clientB가 각각 의존관계 주입을 받으면 각각 다른 인스턴스의 프로토타입 빈을 주입 받는다. clientA prototypeBean@x01

clientB prototypeBean@x02

물론 사용할 때 마다 새로 생성되는 것은 아니다.

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할 때 마다 컨테이너에 새로 요청하는 것

 static class ClientBean {
     @Autowired
      private ApplicationContext ac;

    public int logic() {
             PrototypeBean prototypeBean = ac.getBean(PrototypeBean.class);
             prototypeBean.addCount();
             int count = prototypeBean.getCount();
             return count;
    } 
}

실행해보면 ac.getBean()을 통해 항상 새로운 프로토타입 빈이 생성되는 것을 확인 가능

→ 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup(DL) 의존관계 조회라고 함 (DI가 아니라)

그런데 이렇게 스프링 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워짐

지금 필요한 기능은 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 DL 정도의 기능만 제공하는 무언가가 있으면됨

ObjectFactory, ObjectProvider

지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 ObjectProvider → ObjectFactory에 편의기능을 추가한 것

@Scope("singleton")
static class ClientBean{
        @Autowired
        private ObjectProvider<PrototypeBean> prototypeBeanProvider;

        public int logic(){
                PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
                prototypeBean.addCount()
                int count = prototypeBean.getCount();
        return count;
    }
}

실행해보면 prototypeBeanProvider.getObject()를 통해 항상 새로운 프로토타입 빈이 생성되는 것 확인 가능

ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환 → DL

스프링이 제공하는 기능을 사용하지만, 기능이 단순하므로 단위테스트를 만들거나 mock코드 만들기 쉬워짐

ObjectProvider는 딱 필요한 DL 정도의 기능만 제공

특징

• ObjectFactory : 기능 단순, 별도의 라이브러리 필요 X, 스프링에 의존
• ObjectProvider : ObjectFactory 상속, 옵션/스트림 처리 등 편의 기능 많음, 별도의 라이브러리 필요 X, 스프링에 의존

JSR-330 Provider

javax.inject.Provider 라는 JSR-330 자바 표준을 사용하는 방법 → 스프링 부트 3.0 이상은 jakarta.inject.Provider사용한다.

먼저 gradle에 jakarta.inject:jakarta.inject-api:2.0.1 라이브러리를 추가해줘야함

@Scope("singleton")
static class ClientBean{
        @Autowired
        private Provider<PrototypeBean> provider;

        public int logic(){
                PrototypeBean prototypeBean = provider.get();
                prototypeBean.addCount()
                int count = prototypeBean.getCount();
        return count;
    }
}

수정코드

실행해보면 provider.get()을 통해 항상 새로운 프로토타입 빈 생성 확인가능

provider의 get() 호출 시 내부에서 스프링 컨테이너를 통해 해당 빈 찾아서 반환 → DL

자바 표준이고, 기능이 단순하므로 단위테스트 만들거나 mock 코드 만들기 쉬워짐

Provider는 딱 필요한 DL 정도의 기능만 제공

특징

• get() 메서드 하나로 기능 매우 단순
• 별도의 라이브러리 필요
• 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용 가능

정리

그러면 프로토타입 빈을 언제 사용할까?

→ 매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다. 그런데 실무에서 웹 애플리케이션을 개발해보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때 문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.

ObjectProvider , JSR330 Provider 등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용할 수 있다.

+) 스프링이 제공하는 메서드에 @Lookup 에노테이션 사용하는 방법도 있긴함

+) 실무에서 어떤것을 사용할 것인가? ObjectProvider vs JSR-300

→ 코드를 스프링이 아닌 다른 컨테이너에서도 사용할 수 있어야한다면 JSR-330

→ 다른 컨테이너 사용할 일이 없다면, 스프링의 ObjectProvider사용하면 될 것

웹 스코프

웹 스코프 특징

• 웹 환경에서만 동작
• 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리 → 즉, 종료 메서드 호출

웹 스코프 종류

• request : HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고 관리한다
• session : HTTP Session과 동일한 생명주기를 가지는 스코프
• application : 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
• websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프

클라이언트 A,B가 동시 요청하더라도 각각 다른 빈이 생성되고 관리됨

서비스 로직에서는 만들었던 빈을 사용함

응답이 나가면 destroy

request 스코프 예제 만들기

웹 환경이 동작하도록 라이브러리 추가

build.gradle에 implementation 'org.springframework.boot:spring-boot-starter-web’ 추가

→ 8080 포트로 웹 애플리케이션 실행됨

+) spring-boot-starter-web 라이브러리 추가시 스프링 부트는 내장 톰캣 서버 활용해서 웹 서버와 스프링 함께 실행시킴

+) 스프링 부트는 웹 라이브러리가 없으면 우리가 지금까지 학습한 AnnotationConfigApplicationContext 기반으로 애플리케이션 구동. 웹 라이브러리 추가되면 AnnotationConfigServletWebServerApplicationContext기반

동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다. 이럴때 사용하기 좋은 것이 바로 request 스코프

 [d06b992f...] request scope bean create
 [d06b992f...][http://localhost:8080/log-demo] controller test
 [d06b992f...][http://localhost:8080/log-demo] service id = testId
 [d06b992f...] request scope bean close

다음과 같이 로그가 남도록 request 스코프를 활용해서 추가기능 개발해보자

기대하는 공통 포맷 : [UUID][requestURL][message]

• UUID를 사용해서 HTTP 요청 구분
• requestURL 정보도 추가로 넣어서 어떤 URL을 요청해서 남은 로그인지 확인

package hello.core.common;

import jakarta.annotation.PostConstruct;
import jakarta.annotation.PreDestroy;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

import java.util.UUID;

@Component
@Scope(value = "request")
public class MyLogger {

    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message){
        System.out.println("["+uuid+"]["+requestURL+"]["+message+"]");
    }

    @PostConstruct
    public void init(){
        uuid = UUID.randomUUID().toString();    // 랜덤하게 UUID 생성
        System.out.println("["+uuid+"] request scope bean create:"+this);
    }

    @PreDestroy
    public void close(){
        System.out.println("["+uuid+"] request scope bean close:"+this);
    }
}

@Scope(value=”request”)를 사용해서 request 스코프로 지정 → HTTP 요청 당 하나씩 생성되고 HTTP 요청이 끝나는 시점에 소멸

빈 생성 시점에 자동으로 @PostConstruct 초기화메서드 사용해서 uuid 생성 및 저장. 빈은 요청 당 하나씩 생성되므로 uuid로 구별가능

빈 종료시점에 @PreDestroy로 종료

requestURL은 빈이 생성되는 시점에는 알 수 없으므로 외부에서 setter로 입력받는다

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request){
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);

        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

로거가 잘 작동하는지 확인하는 테스트용 컨트롤러

여기서 HttpServletRequest를 통해 요청 URL받음 → http://localhost:8080/log-demo

이렇게 받은 url값을 requestURL에 저장. myLogger는 HTTP 요청 당 각각 구분되므로 다른 HTTP 요청때문에 값이 섞을 걱정 X

컨트롤러에서는 controller test라는 로그 남김

+) MyLogger에 저장하는 부분은 컨트롤러 보다는 공통 처리가 가능한 스프링 인터셉터나 서블릿 필터 같은 곳을 활용하는 것이 좋음 → 여기서는 단순화하기 위해

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = "+id);
    }
}

비즈니스 로직이 있는 서비스 계층에서도 로그를 출력해보자

request scope를 사용하지 않고 파라미터로 모든 정보를 서비스 계층에 넘긴다면

→ 파라미터가 많아 지저분, 더 문제는 requestURL같은 웹과 관련된 정보과 관련없는 서비스 계층까지 넘어가게됨.

→ 서비스 계층은 웹 기술에 종속되지 않고 가급적 순수하게 유지하는 것이 유지보수 관점에 좋음

→ request scope의 MyLogger 덕분에 이런 부분을 파라미터로 넘기지 않고, MyLogger의 멤버변수에 저장해서 코드와 계층 깔끔하게 유지가능

 Error creating bean with name 'myLogger': Scope 'request' is not active for the
 current thread; consider defining a scoped proxy for this bean if you intend to
 refer to it from a singleton;

그러나 에러 발생…

request 스코프빈은 스프링 애플리케이션 실행 지점에 아직 생성되지 않음 → 고객의 요청이 와야 생성가능

스코프와 provider

public class LogDemoController {

    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request){
        String requestURL = request.getRequestURL().toString();
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);

        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

public class LogDemoService {
    private final ObjectProvider<MyLogger> myLoggerProvider;
    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = "+id);
    }
}

컨트롤러와 서비스 코드 약간만 수정해주면됨

ObjectProvider사용 → getObject()

순서 :

getObject하는 시점에 생성됨

→ 이때 init() 호출해서 uuid 생성

→ logDemo에서 url 받음

→ log찍고, logic찍고

→ close()

바로바로 로그가 찍히는데 이때 UUID가 요청마다 다르고, 요청끼리는 같게 유지되는 것을 볼 수 있음 → 유저 구분이 가능

ObjectProvider덕분에 getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다

getObject()를 호출하는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리된다

getObject()를 LogDemoController, LogDemoService에서 각각 따로 한번씩 호출해도 같은 HTTP 요청이면 같은 스프링빈 반환 → 직접 구분하려면 정말 힘들것

스코프와 프록시

@Component
 @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
 public class MyLogger {
}

proxyMode = ScopedProxyMode.TARGET_CLASS를 추가

나머지 코드도 Provider 없애고 다시 돌려놓기

• 적용 대상이 클래스면 TARGET_CLASS
• 적용 대상이 인터페이스면 INTERFACES

이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있다

웹 스코프와 프록시 동작 원리

System.out.println("myLogger = " + myLogger);

// 결과
myLogger = class hello.core.common.MyLogger$$SpringCGLIB$$0

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입

• @Scope의 proxymode = scopeProxyMode.TARGET_CLASS를 설정하면 스프링 컨테이너는 CGLIB이라는 바이트코드를 조작하는 라이브러리를 사용해서 MyLogger를 상속받은 가짜 프록시 객체를 생성
• 결과를 확인해보면 우리가 등록한 순수한 MyLogger클래스가 아닌 CGLIB이 붙은 클래스가 생성된 것 확인가능
• 그리고 스프링 컨테이너에 myLogger라는 이름으로 진짜 대신 이 가짜 프록시 객체를 등록
• ac.getBean(”myLogger”, MyLogger.class)로 주입해도 이 가짜 프록시 객체 조회됨
• 그래서 의존관계 주입도 이 가짜 프록시 객체가 주입됨

가짜프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음

• 가짜 프록시 객체는 내부에 진짜 myLogger를 찾는 방법을 알고 있음

• 클라이언트가 myLogger.logic()을 호출하면 사실 가짜 프록시 객체의 메서드를 호출한것

  → 가짜 프록시 객체는 request 스코프의 진짜 myLogger.logic()을 호출

• 객체 사용하는 클라이언트 입장에서는 원본인지 아닌지 모르게 동일하게 사용가능(다형성)

동작 정리

• CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
• 이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
• 가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다.

특징 정리

• 프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
• 사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
• 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
• 꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다

주의점

• 마치 싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
• 이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.

인프런 스프링 입문 - 김영한 강의를 듣고 정리한 내용입니다

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

public class BeanLifeCycleTest {

    @Test
    public void lifeCycleTest(){
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        NetworkClient client = ac.getBean(NetworkClient.class);
        ac.close();
    }

    @Configuration
    static class LifeCycleConfig{
        @Bean
        public NetworkClient networkClient(){
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello-spring.dev");
            return networkClient;
        }
    }
}

public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = "+url);
        connect();
        call("초기화 연결 메시지");
    }

    public void setUrl(String url) {
        this.url = url;
    }

    //서비스 시작시 호출
    public void connect(){
        System.out.println("connect: "+url);
    }

    public void call(String message){
        System.out.println("call: "+url+" message = "+message);
    }

    //서비스 종료시 호출
    public void disconnect(){
        System.out.println("close "+url);
    }

}

ApplicationContext ac 대신

ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class); 또는 AnnotationConfigApplicationContext

→ 기본 ApplicationContext에는 close기능이 없음

ConfigurableApplicationContext가 AnnotationConfigApplicationContext의 상위 인터페이스

실행결과

생성자 호출, url = null
connect: null
call: null message = 초기화 연결 메시지

생성자 부분을 보면 url 정보 없이 connect가 호출되는 것을 확인할 수 있음

객체를 생성하는 단계에는 url이 없고, 객체를 생성한 다음에 외부에서 수정자 주입을 통해서 setUrl() 이 호출되어야 url이 존재하게 된다

스프링 빈 라이프 사이클

객체 생성 → 의존관계 주입

스프링 빈은 객체를 생성하고 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료됨.

따라서 초기화 작업은 의존관계 주입 완료 후에 호출해야함 → 개발자가 어떻게 알 수 있을까?

→ 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능 제공

스프링 빈의 이벤트 라이프 사이클

스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸전 콜백 → 스프링 종료

초기화 콜백 : 빈 생성, 빈 의존관계 주입 완료 후 호출

소멸전 콜백 : 빈 소멸 직전에 호출

스프링은 다양한 방식으로 생명주기 콜백 지원

• 인터페이스(InitializaingBean, DesposableBean)
• 설정 정보에 초기화 메서드, 종료 메서드 지정
• @PostConstuct, @PreDestroy 애노테이션 지원

+) 객체의 생성과 초기화를 분리하자

생성자 : 필수정보(파라미터)를 받고 메모리를 할당해서 객체 생성하는 책임을 가짐

초기화 : 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작 수행

따라서 생성자 안에서 무거운 초기화 작업을 함께하는 것보다 분리하는 것이 유지보수 관점에서 좋음. 물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 처리하는 것이 나을 수 있다

인터페이스(InitializaingBean, DesposableBean)

public class NetworkClient implements InitializingBean, DisposableBean {

    // 위와 동일한 내용
    // 아래 오버라이딩만 추가

        @Override
          public void afterPropertiesSet() throws Exception{
           System.out.println("NetworkClient.afterPropertiesSet");
           connect();
           call("초기화 연결 메시지");
           }

      @Override
       public void destroy() throws Exception {
        System.out.println("NetworkClient.destroy");            
        disconnect();
       }
}

InitializingBean은 afterPropertiesSet() 메소드로 초기화 지원

DisposableBean은 destroy() 메소드로 소멸 지원

실행결과

생성자 호출, url = null
NetworkClient.afterPropertiesSet
connect: http://hello-spring.dev
call: http://hello-spring.dev message = 초기화 연결 메시지
16:12:08.592 [main] DEBUG o.s.c.a.AnnotationConfigApplicationContext --
                Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@738dc9b, started on Sun Apr 07 16:12:08 KST 2024
NetworkClient.destroy
close http://hello-spring.dev

생성 → 의존관계 주입 → 초기화 단계로 잘 진행됨

초기화, 소멸 인터페이스 단점

• 스프링 전용 인터페이스임. 해당 코드가 스프링 전용 인터페이스에 의존
• 초기화, 소멸메서드의 이름 변경 불가
• 내가 코드를 고칠 수 없는 외부 라이브러리에 적용 불가

인터페이스를 사용하는 초기화, 종료 방법은 최근에는 잘 사용 X

빈 등록 초기화, 소멸 메서드 지정

public class NetworkClient{

        // 아래만 변경
    public void init(){
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    public void close(){
        System.out.println("NetworkClient.close");
        disconnect();
    }

}

@Configuration
    static class LifeCycleConfig{
        @Bean(initMethod = "init", destroyMethod = "close")
        public NetworkClient networkClient(){
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello-spring.dev");
            return networkClient;
        }
    }

설정 정보에서 @Bean에다가 초기화, 소멸 메서드 지정

출력결과 동일하게 나옴

특징

• 메서드 이름을 자유롭게 줄 수 있음
• 스프링 빈이 스프링 코드에 의존 X
• 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있음

종료 메서드 추론

• @Bean의 destroyMethod 속성에는 아주 특별한 기능이 있다.
• 라이브러리는 대부분 close , shutdown 이라는 이름의 종료 메서드를 사용한다.
• @Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.
• 이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다.
• 따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다.
• 추론 기능을 사용하기 싫으면 destroyMethod="" 처럼 빈 공백을 지정하면 된다.

애노테이션 @PostConstuct, @PreDestroy

public class NetworkClient{

        // 아래만 변경

    @PostConstruct
    public void init(){
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    @PreDestroy
    public void close(){
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

@PostConstruct , @PreDestroy 이 두 애노테이션을 사용하면 가장 편리하게 초기화와 종료를 실행할 수 있다.

특징

• 최신 스프링에서 가장 권장하는 방법이다.
• 애노테이션 하나만 붙이면 되므로 매우 편리하다.
• 패키지를 잘 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.
• 컴포넌트 스캔과 잘 어울린다.
• 유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자.

정리

@PostConstruct, @PreDestroy 애노테이션을 사용하자

코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 initMethod, destroyMethod를 사용하자.

인프런 스프링 입문 - 김영한 강의를 듣고 정리한 내용입니다

의존관계 주입은 크게 4가지 방법이 있음

• 생성자 주입
• 수정자 주입(setter 주입)
• 필드 주입
• 일반 메서드 주입

생성자 주입

이름 그대로 생성자를 통해서 의존관계를 주입받는 방법

지금까지 진행했던 방법

컴포넌트 스캔시 → 스프링 빈 등록할때 생성자 호출 → 이때 @Autowired가 생성자에 붙어있으면 빈에서 의존관계 찾아서 주입

특징

• 생성자 호출시점에 딱 1번만 호출되는 것이 보장

• “불변, 필수” 의존관계에 사용

  → 불변 : ex) 공연중에 배우를 절대 바꾸지 않을경우. 처음부터 다 확정하고 시작하는 경우

  → 필수 : ex) final이 붙어있으므로 생성자에 값을 다 채워넣어야함. null값 X

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
  
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }

중요! 생성자가 딱 1개만 있으면 @Autowired 생략해도 괜찮음

수정자주입

setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

@Autowired
public void setMemberRepository(MemberRepository memberRepository){
    System.out.println("memberRepository = " + memberRepository);
    this.memberRepository = memberRepository;
}

@Autowired
public void setDiscountPolicy(DiscountPolicy discountPolicy){
    System.out.println("discountPolicy = " + discountPolicy);
    this.discountPolicy = discountPolicy;
}

생성자주입 : 생성자를 호출해야하므로 빈 등록하면서 의존관계 주입이 동시에 일어남

수정자주입 : 빈 등록이 다 끝난 후에 의존관계 주입

특징

• 선택, 변경 가능성이 있는 의존관계에 사용

  → 선택 : @Autowired(required = false)

• 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.

필드주입

필드에 바로 주입하는 방법

@Autowired
private MemberRepository memberRepository;

@Autowired
private DiscountPolicy discountPolicy;

특징

• 코드가 간결하다는 장점, 외부에서 변경 불가하다는 단점이 있다 → 결국 그러면 또 setter를 만들어야함
• DI 프레임워크가 없으면 아무것도 할 수 없다
• 사용하지 말자! 그러나 아래의 경우에는 사용해도 ㄱㅊ음
  • 애플리케이션의 실제 코드와 관계 없는 테스트 코드
  • 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

일반 메서드 주입

일반 메서드를 통해서 주입받을 수 있다

특징

• 한번에 여러 필드를 주입 받을 수 있다
• 일반적으로 잘 사용 X : 생성자 주입이나 수정자 주입으로 대체가능

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

@Autowired
public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy){
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

+) 당연한 이야기지만 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작 → ex) Member같은 클래스에서 @Autowired해도 아무 기능 X

옵션 처리

주입할 스프링 빈이 없어도 동작해야할 때가 있음

→ 그런데 @AutoWired만 사용하면 required 옵션의 기본값이 true로 되어있어서 자동 주입 대상이 없으면 오류 발생

자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다.

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.

    static class TestBean{

        // 1. Autowired(required = false)
        @Autowired(required = false)
        public void setNoBean1(Member noBean1){
            System.out.println("noBean1 = " + noBean1);
        }

                // 2. @Nullable
        @Autowired
        public void setNoBean2(@Nullable Member noBean2){
            System.out.println("noBean2 = " + noBean2);
        }

                // 3. Optional<>
        @Autowired
        public void setNoBean3(Optional<Member> noBean3){
            System.out.println("noBean3 = " + noBean3);
        }

Member는 스프링 빈이 아님!

noBean1은 아예 호출이 안됨

noBean2 = null

noBean3 = Optional.empty

+) @Nullable, Optional은 스프링 전반에 걸쳐서 지원됨. 생성자 자동 주입에서 특정 필드에만 사용해도됨

생성자 주입을 선택해라!

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장

→ 이유 1 : 불변

• 대부분의 의존관계 주입은 종료시점까지 변경할일이 없음. 오히려 대부분의 의존관계는 종료시점까지 변하면 안됨

• 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어둬야함

  → 누군가 실수로 변경할 수도 있고, 변경하면 안되는 메소드를 열어두는것은 좋은 설계 방법이 X

• 생성자 주입은 객체 생성시 딱 1번만 호출되므로 이후에 호출되는 일이 없음. 따라서 불변하게 설계 가능

→ 이유 2 : 누락

private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }

위와같이 수정자 의존관계인 경우

@Test
 void createOrder() {
     OrderServiceImpl orderService = new OrderServiceImpl();
     orderService.createOrder(1L, "itemA", 10000);
 }

이렇게 테스트 수행하면 실행은 되나 Null Point Exception 발생

OrderServiceImpl에 memberRepository, discountPolicy모두 의존관계 주입 누락

생성자 주입을 사용하면 위와같은 경우에서 컴파일 오류가 발생하여 어떤 값을 필수로 주입해야하는지 알 수 있음 → new OrderServiceImpl()여기에 빨간줄 뜸

→ 이유 3 : final 키워드

final 키워드를 포함시키면 실수로 값을 설정하지 않는 오류를 막을 수 있음 : 컴파일 오류 발생 → final은 값이 무조건 있어야하므로

생성자 주입이 아닌 다른 방식들은 모두 생성자 이후에 호출되므로 final 사용자체가 불가능

정리

생성자 주입 방식은 프레임워크에 의존하지 않고 순수한 자바 언어의 특징을 잘 살리는 방법

기본적으로 생성자 주입을 사용하고 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면됨 → 동시 사용 가능

항상 생성자 주입을 선택하고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 말자

롬복과 최신 트렌드

막상 개발을 해보면 대부분이 불변이고 그래서 생성자에 final 키워드 사용하게됨

→ 생성자도 만들고, 주입 받은 값을 대입하는 코드도 만들어야하고…

필드 주입처럼 편리하게 사용하는 방법이 없을까?!

먼저 lombok 라이브러리 gradle 수정하고 다운 받는등.. 기본 작업을 해준다!

 @Component
 public class OrderServiceImpl implements OrderService {
     private final MemberRepository memberRepository;
     private final DiscountPolicy discountPolicy;

        @Autowired
     public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
 discountPolicy) {
         this.memberRepository = memberRepository;
         this.discountPolicy = discountPolicy;
     }
}

이게 기본 코드 → 여기서 생성자가 1개인 상황이라면 @Autowired는 생략 가능

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService{

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

@RequiredArgsConstructor → final이 붙은 변수를 파라미터로하는 생성자 자동으로 만들어줌. 여기 보이지는 않지만 실제 호출 가능

완전히 동일한 기능을 하지만 코드가 아주 간결해짐!!!

정리

최근에는 생성자를 딱 1개 두고, @Autowired를 생략하는 방법 주로 사용. 여기에 롬복 라이브러리의 @RequiredArgsConstructor를 사용하면 기능은 다 제공하면서 코드는 깔끔하게 사용가능

조회 빈이 2개 이상 - 문제

@Autowired는 타입으로 조회하므로 선택된 빈이 2개 이상이면 문제 발생

@Autowired
private DiscountPolicy discountPolicy;

// 같은 동작 

ac.getBean(DiscountPolicy.class);

예를 들어, FixDiscountPolicy, RateDiscountPolicy 2개를 모두 @Component로 등록하면 둘다 같은

discountPolicy 타입이므로 NoUniqueBeanDefinitionException발생

→ expected single matching bean but found 2: fixDiscountPolicy, rateDiscountPolicy

아래는 해결방법 3가지에 대한 내용이다

@Autowired 필드 명, @Qualifier, @Primary

1. @Autowired 필드 명 매칭

   @Autowired는 타입 매칭을 시도하고, 이때 빈이 여러개 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭

    // 기존 코드
    @Autowired
    private DiscountPolicy discountPolicy
   
    // 필드 명을 빈 이름으로 변경
    @Autowired
    private Discount policy rateDiscountPolicy

   필드명이 rateDiscountPolicy이므로 정상주입됨

   필드명 매칭은 먼저 타입 매칭을 시도하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능이다.

   @Autowired 매칭 정리

   1. 타입 매칭
   2. 타입 매칭의 결과가 2개 이상일때 필드 명, 파라미터 명으로 빈 이름 매칭

2. @Qualifier → Qualifier끼리 매칭 → 빈 이름 매칭

   @Qualifier는 추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다.

    @Component
    @Qualifier("mainDiscountPolicy")
    public class RateDiscountPolicy implements DiscountPolicy{
        ...
    }

    @Component
    @Qualifier("fixDiscountPolicy")
    public class FixDiscountPolicy implements DiscountPolicy{
        ...
    }

   RateDiscountPolicy에는 “mainDiscountPolicy”

   fixDiscountPolicy에는 “fixDiscountPolicy”라는 구분자를 붙여준다

     @Autowired
        public OrderServiceImpl(MemberRepository memberRepository, @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy){
            this.memberRepository = memberRepository;
            this.discountPolicy = discountPolicy;
        }

   OrderServiceImpl에서 이런식으로 사용

   만약 “mainDiscountPolicy” Qualifier를 못찾으면 어떻게될까?

   → mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는다

   → Qualifier는 Qualifier를 찾는 용도로만 사용하는 것이 좋다!

   @Qualifier 매칭 정리

   1. @Qualifier끼리 매칭
   2. 빈 이름 매칭
   3. NoSuchBeanDefinitionException 예외 발생

3. @Primary 사용

   우선순위를 정하는 방법이다

   @Autowired시에 여러번 매칭되면 @Primary가 우선권을 가짐

    @Component
    @Primary
    public class RateDiscountPolicy implements DiscountPolicy{
        ...
    }

   @Primary만 붙여주면됨

   매우 간단 → @Qualifier보다 간단 : 모든 코드에 @Qualifier를 붙여줘야함

   메인과 보조 구현체가 있을때 메인에는 @Primary를 걸어놓는다던지 그러한 방식으로 사용

@Primary, @Qualifier 활용

코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고,

코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 생각해보자.

메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary 를 적용해서 조회하는 곳에서

@Qualifier 지정 없이 편리하게 조회하고,

서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier 를 지정해서 명시적으로 획득 하는 방식으로 사용

하면 코드를 깔끔하게 유지할 수 있다.

물론 이때 메인 데이터베이스의 스프링 빈을 등록할 때 @Qualifier 를 지정해주는 것은 상관없다.

우선순위

스프링은 자동보다는 수동이, 넓은 범위의 선택권보다는 좁은범위의 선택권이 우선순위가 높음

@Primary는 기본값처럼 동작

@Qualifier는 매우 상세하게 동작 → 우선권이 높음

애노테이션 직접 만들기

@Qualifier(”mainDiscountPolicy”) 이렇게 문자를 적으면 컴파일시 타입 체크가 안됨. 다음과 같은 애노테이션을 만들어서 문제 해결 가능

package hello.core.annotation;

import org.springframework.beans.factory.annotation.Qualifier;

import java.lang.annotation.*;

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {

}

위와같은 방식으로 애노테이션 생성가능

여기에 @Qualifier도 있는 것을 볼 수 있음

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy{
    ...
}

Qualifier와 같은 방법으로 사용

애노테이션에는 상속이라는 개념 X. 이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능. 다른 애노테이션들도 함께 조합하여 사용할 수 있지만 무분별하게 사용하진 말자

조회한 빈이 모두 필요할 때, List, Map

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있음

예를 들어 할인 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택할 수 있다고 가정 → 스프링을 사용하면 소위말하는 전략패턴을 매우 간단하게 구현 가능

public class AllBeanTest {

    @Test
    void findAllBean(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);

        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member,10000,"fixDiscountPolicy");

        Assertions.assertThat(discountService).isInstanceOf(DiscountService.class);
        Assertions.assertThat(discountPrice).isEqualTo(1000);

        int rateDiscountPolicy = discountService.discount(member, 20000, "rateDiscountPolicy");
        Assertions.assertThat(rateDiscountPolicy).isEqualTo(2000);
    }

    static class DiscountService{
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        @Autowired
        public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }

        public int discount(Member member, int price, String discountCode){
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member,price);
        }
    }
}

DiscountService는 Map으로 모든 DiscountPolicy를 주입받음

→ fixDiscountPolicy, rateDiscountPolicy가 주입됨

discount()메서드는 discountCode로 만약 rateDiscountPolicy가 넘어오면 map에서 rateDiscountPolicy 스프링빈을 찾아서 실행

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다. List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다

자동, 수동의 올바른 실무 운영 기준

편리한 자동 기능을 기본으로 사용하자

어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보를 통해 수동으로 빈을 등록하고, 의존관계도 수동으로 주입해야할까?

→ 스프링이 나오고 시간이 갈수록 점점 자동을 선호하는 추세

@Component뿐 아니라 @Controller, @Service, @Repository처럼 계층에 맞춰 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원

설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작 부분을 명확하게 나누는 것이 이상적이지만 개발자입장에서 스프링 빈을 하나 등록할 때 @Component만 넣어주면 끝나는일을 @Configuration 설정정보에 가서 @Bean을 적고 기타등등…매우 번거로움!

또 관리할 빈이 많아서 설정 정보가 커지면 관리자체가 부담이됨

결정적으로 자동 빈 등록을 사용해도 OCP, DIP 지킬 수 있음!

수동 빈 등록은 언제 사용하면 좋을까?

애플리케이션은 크게 업무 로직, 기술 지원 로직으로 나눌 수 있음

• 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
• 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.

업무 로직은 숫자도 매우 많고, 한번 개발해야하면 컨트롤러, 서비스, 리포지토리처럼 어느정도 유사한 패턴이 있다 → 자동 기능 적극 사용 권장 → 문제도 찾기 쉬움

기술 지원 로직은 업무 로직과 비교해서 수가 매우 적고 광범위하게 영향을 미침. 또한 문제가 어디서 발생했는지 적용은 잘 되고 있는지도 파악하기 어려움 → 수동 빈 등록을 통해 명확하게 들어내는 것이 좋다

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 딱! 설정 정보에 바로 나타나게 하는것이 유지보수 하기 좋다.

비즈니스 로직 중에서 다형성을 적극 활용할 때

의존관계 자동 주입 - 조회한 빈이 모두 필요할 때 → List, map

DiscountService 가 의존관계 자동 주입으로 Map<String,DiscountPolicy> 에 주입을 받는 상황같은 경우에는 수동등록이 낫다.

자동으로 할경우 특정 패키지에 같이묶어두는것이 좋다.

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외

스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 드러내는 것이 좋다.

정리

편리한 자동 기능을 기본으로 사용하자

직접 등록하는 기술 지원 객체는 수동 등록

다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

인프런 스프링 핵심 원리 기본편 - 김영한 강의를 듣고 정리한 내용입니다

지금까지는 스프링 빈 등록할 때 @Bean이나 <bean'> 등을 통해서 등록했음

→ 등록할게 수십, 수백개가되면 등록하기 귀찮고 설정정보도 커지고 누락 발생

→ 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능 제공

또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공

package hello.core;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

@Configuration
@ComponentScan(
        // 설정 정보는 컴포넌트 스캔 대상에서 제외
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {

}

@ComponentScan을 설정정보에 붙여주면됨

• 기존 AppConfig와 다르게 @Bean으로 등록한 클래스가 하나도 없다

excludeFilters를 이용해서 @Configuration이 붙은 설정정보들을 제외해줌 → 일반적으로 잘 사용하진 않지만, 현재는 기존 코드를 최대한 유지하기 위해서 이렇게

MemoryMemberRepository, MemberServiceImpl, RateDiscountPolicy, OrderServiceImple 클래스에 @Component를 추가해줌

클래스 안의 생성자에는 @Autowired를 붙여줌으로서 빈에서 자동으로 맞는 객체를 찾아등록하도록해줌

이전에 AppConfig에서는 @Bean 으로 직접 설정 정보를 작성했고, 의존관계도 직접 명시했다. 이제는 이런 설 정 정보 자체가 없기 때문에, 의존관계 주입도 이 클래스 안에서 해결해야 한다.

멤버서비스 -> 멤버서비스impl(멤버리포지토리) 오더서비스 -> 오더서비스impl(멤버리포지토리, 할인정책) 할인 정책 -> Rate할인정책 멤버리포지토리 -> 메모리멤버리포지토리

이 관계에서 뒤에것들에만 @Component

public class AutoAppConfigTest {

    @Test
    void basicScan(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class);

        MemberService memberService = ac.getBean(MemberService.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

위 테스트가 잘 동작하는 것을 알 수 있음

1. @ComponentScan

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈에 등록

이때 스프링 빈 이름은 클래스명을 사용하되 맨 앞글자만 소문자

이름을 지정하고 싶으면 @Component(”memberService2”)이런식으로 하면됨

2. @Autowired 의존관계 자동 주입

생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링빈을 찾아서 주입

이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입

• getBean(MemberRepository.class)와 동일하다고 이해하면됨

탐색 위치와 기본 스캔 대상

탐색할 패키지의 시작 위치 지정

package hello.core;

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;

@Configuration
@ComponentScan(
        // member패키지 하위 패키지 탐색
        basePackages = "hello.core.member",
        // 설정 정보는 컴포넌트 스캔 대상에서 제외
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {

}

basePackages : 탐색할 패키지의 시작 위치를 지정. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다

• basePackages = {”hello.core”, “hello.service”}로 여러개 지정도 가능

디폴트는 @ComponentScan이 붙은 설정 정보 클래스(AppConfig.class)의 패키지가 시작위치가됨 → 현재 경우 hello.core 패키지가 디폴트

권장 방식

패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것. 최근 스프링 부트도 이 방법을 기본으로 제공함.

ex) 프로젝트 구조

• com.hello
• com.hello.service
• com.hello.repository

com.hello → 프로젝트 시작루트, 여기에 AppConfig같은 메인 설정 정보를 두고 @ComponentScan 애노테이션을 붙이고 basePackages 지정 생략

스프링 부트 사용시 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 이 프로젝트 시작 루트 위치에 두는 것이 관례이다. 그리고 이 설정 안에 @ComponentScan이 들어있다. → 따로 @ComponentScan이 필요 X

@SpringBootApplication
public class CoreApplication {

    public static void main(String[] args) {
        SpringApplication.run(CoreApplication.class, args);
    }

}

컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component뿐만 아니라 다음 내용도 추가로 대상에 포함

• @Component : 컴포넌트 스캔에서 사용
• @Controller : 스프링 MVC 컨트롤러에서 사용
• @Service : 스프링 비즈니스 로직에서 사용
• @Repository : 스프링 데이터 접근 계층에서 사용
• @Configuration : 스프링 설정 정보에서 사용

 @Component
 public @interface Controller {
 }

 @Component
 public @interface Service {
 }

 @Component
 public @interface Configuration {
}

해당 클래스의 소스코드를 보면 @Component를 포함하고 있는 것을 알 수 있음

+) 사실 애노테이션에는 상속관계라는 것이 없다. 그래서 이렇게 애노테이션이 특정 애노테이션을 들고 있는 것을 인식할 수 있는 것은 자바 언어가 지원하는 기능은 아니고, 스프링이 지원하는 기능이다.

컴포넌트 스캔의 용도 뿐만 아니라 다음 애노테이션이 있으면 스프링은 부가기능을 수행

• @Controller : 스프링 MVC 컨트롤러로 인식
• @Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해줌
• @Configuration : 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 함
• @Service : 특별한 처리를 하진 않음. 개발자들이 핵심 비즈니스 로직이 여기 있겠구나라고 비즈니스 계층을 인식하는데 도움이됨

+) useDefaultFilters 옵션은 기본으로켜저있는데, 이 옵션을 끄면 기본 스캔 대상들이 제외된다.

필터

package hello.core.scan.filter;

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {
}

컴포넌트 스캔 대상에 추가할 애노테이션

추가하지 않을 애노테이션도 동일하게하고 MyExcludeComponent 인터페이스로 만들어준다

package hello.core.scan.filter;

@MyIncludeComponent
public class BeanA {
}

컴포넌트 스캔 대상에 추가할 클래스 → @MyIncludeComponent 적용

제외할 클래스 BeanB도 동일하게 만들고 → @MyExcludeComponent 적용

public class ComponentFilterAppConfigTest {

    @Test
    void filterScan(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
        BeanA beanA = ac.getBean("beanA", BeanA.class);
        Assertions.assertThat(beanA).isNotNull();

        //ac.getBean("beanB", BeanB.class);
        org.junit.jupiter.api.Assertions.assertThrows(
                NoSuchBeanDefinitionException.class,
                () -> ac.getBean("beanB", BeanB.class));
    }

    @Configuration
    @ComponentScan(
            includeFilters = @ComponentScan.Filter(type= FilterType.ANNOTATION,classes = MyIncludeComponent.class),
            excludeFilters = @ComponentScan.Filter(type= FilterType.ANNOTATION,classes = MyExcludeComponent.class))
    static class ComponentFilterAppConfig{

    }
}

BeanA가 스프링 빈에 등록되고, BeanB는 등록안된 것 확인 가능

FilterType 옵션 FilterType은 5가지 옵션이 있다.

ANNOTATION: 기본값, 애노테이션을 인식해서 동작한다.

• ex) org.example.SomeAnnotation

ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.

• ex) org.example.SomeClass

    @Filter(type = FilterType.ASSIGNABLE_TYPE, classes = BeanA.class)
       }

  이런식으로 A도 제외가능

ASPECTJ: AspectJ 패턴 사용

• ex) org.example..*Service+

REGEX: 정규 표현식

• ex) org\.example\.Default.*

CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리

• ex) org.example.MyTypeFilter

크게 많이 사용하진 않는다

중복 등록과 충돌

컴포넌트 스캔에서 같은 빈 이름을 등록하면 어떻게될까?

1. 자동 빈 등록 vs 자동 빈 등록

   스프링에서 오류 발생시킴 → ConflictingBeanDefinitionException 예외 발생

2. 수동 빈 등록 vs 자동 빈 등록

    @Configuration
    @ComponentScan(
            basePackages = "hello.core.member",
            excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
    )
    public class AutoAppConfig {
        @Bean(name = "memoryMemberRepository")
        public MemberRepository memberRepository() {
            return new MemoryMemberRepository();
        }
    }

   수동으로 등록한 빈

   이 경우 수동 빈 등록이 우선권을 가짐 → 수동 빈이 자동빈을 오버라이딩해버림

   개발자가 이런 결과를 의도했다면 수동이 우선권을 가지는 것이 좋지만 개발자가 의도하지 않은 경우가 대부분 → 이때 잡기 어려운 버그가 만들어짐!

   그래서 최근 스프링부트에서는 수동 빈 등록과 자동 빈 등록이 충돌나면 오류가 발생하도록 기본 값을 바꿈

   → @SpringBootApplication애노테이션이 있는 CoreApplication을 실행해보면 오류남

인프런 스프링 핵심 원리 기본편 - 김영한 강의를 듣고 정리한 내용입니다

스프링은 태생이 기업용 온라인 서비스 기술을 지원하기 위해 탄생

대부분의 스프링 애플리케이션은 웹 애플리케이션

웹 애플리케이션은 보통 여러 고객이 동시에 요청을 함

고객들이 요청할때마다 객체가 계속 새로 생성됨

@Test
    @DisplayName("스프링 없는 순수한 DI 컨테이너")
    void pureContainer(){
        AppConfig appConfig = new AppConfig();
        // 1. 조회 : 호출할 때 마다 객체를 생성
        MemberService memberService = appConfig.memberService();

        // 2. 조회 : 호출할 때 마다 객체를 생성
        MemberService memberService2 = appConfig.memberService();

        // 참조값이 다른 것을 확인
        System.out.println("memberService = " + memberService);
        System.out.println("memberService2 = " + memberService2);

        // memverService1 != memverService2
        Assertions.assertThat(memberService).isNotSameAs(memberService2);
    }

테스트 실행시 다른 객체가 생성된 것을 확인할 수 있음

스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청할 때마다 객체를 새로 생성

고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸됨 → 메모리 낭비 심하다

해결방안 : 해당 객체가 딱 1개만 생성되고 공유하도록 설계 → 싱글톤 패턴

싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴

→ 객체 인스턴스를 2개 이상 생성하지 못하도록 막아야함

→ private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아야함

package hello.core.singleton;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class SingletonService {

        // 1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();

    // 2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용
    public static SingletonService getInstance(){
        return instance;
    }

    // 3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성 못하게 막는다
    private SingletonService(){
    }

    public void logic(){
        System.out.println("싱글톤 객체 로직 호출");
    }
}

1. 자기자신을 내부의 private으로 가지고 있음. static이라서 class레벨에 올라가서 딱 하나만 생성

2. 인스턴스에 접근가능한 유일한 방법 : getInstance() 메서드

   이때 항상 같은 인스턴스를 반환함

3. 1개의 객체 인스턴스만 존재해야하므로, 혹시라도 외부에서 new로 생성하지 못하도록 막음

@Test
    @DisplayName("싱글톤 패턴을 적용한 객체 사용")
    void singletonServiceTest(){
        // new SingletonService(); private으로 생성자를 막아두었으므로 컴파일 오류 발생

        SingletonService singletonService1 = SingletonService.getInstance();
        SingletonService singletonService2 = SingletonService.getInstance();

        System.out.println("singletonService1 = " + singletonService1);
        System.out.println("singletonService2 = " + singletonService2);

        Assertions.assertThat(singletonService1).isSameAs(singletonService2);
    }

호출할 때마다 같은 객체 인스턴스를 반환하는것을 확인할 수 있음

isSameas → == 이걸 의미

isEqualto

싱글톤 패턴을 구현하는 방법은 여러가지가 있는데 여기서는 객체를 미리 생성해두는 가장 단순하고 안전한 방법을 선택한것

싱글톤 패턴을 적용하면 고객의 요청이 올때마다 객체를 생성하는 것이 아니라 만들어진 객체를 공유하여 효율적으로 사용가능

싱글톤 패턴 문제점

• 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
• 의존관계상 클라이언트가 구체 클래스에 의존한다 → DIP를 위반한다.
• 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
• 테스트하기 어렵다.
• 내부 속성을 변경하거나 초기화 하기 어렵다.
• private 생성자로 자식 클래스를 만들기 어렵다.
• 결론적으로 유연성이 떨어진다.
• 안티패턴으로 불리기도 한다.

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤(1개만 생성)으로 관리한다

지금까지 배운 스프링빈이 바로 싱글톤으로 관리되는 빈이다

싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도 객체 인스턴스를 싱글톤으로 관리 → 컨테이너는 객체를 하나만 생성해서 관리

스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.

스프링 컨테이너의 이런 기능 덕분에 싱글톤 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지가능

• 싱글톤 패턴을 위한 지저분한 코드가 들어가지 않아도됨
• DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용가능

@Test
    @DisplayName("스프링 컨테이너와 싱글톤")
    void springContainer(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberService memberService = ac.getBean("memberService",MemberService.class);
        MemberService memberService2 = ac.getBean("memberService",MemberService.class);

        // 참조값이 동일함
        System.out.println("memberService = " + memberService);
        System.out.println("memberService2 = " + memberService2);

        // memverService1 == memverService2
        Assertions.assertThat(memberService).isSameAs(memberService2);

    }

참조값이 동일하기때문에 테스트 성공

고객이 요청할때마다 객체를 생성하는 것이 아니라 이미 만들어져있는 객체를 공유하여 효율적으로 재사용

+) 스프링의 기본 빈 등록 방식은 싱글톤이지만 싱글톤 말고 요청할때마다 새로 객체 생성해서 반환하는 기능도 제공 → 빈 스코프

싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링같은 싱글톤 컨테이너를 사용하든 객체 인스턴스를 하나만 생성해서 공유하는 싱글톤 방식은 하나의 같은 객체 인스턴스를 공유하기때문에 싱글톤 객체는 상태를 유지(stateful)하게 설계하면안됨

→ 무상태 stateless로 설계해야함

• 특정 클라이언트에 의존적인 필드가 있으면 안됨
• 특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안됨
• 가급적 읽기만 가능해야함
• 필드 대신 자바에서 공유되지 않는 지역변수, 파라미터, ThreadLocal 등을 사용해야함

스프링 빈의 필드에 공유 값을 설정하면 정말 큰 장애가 발생할 수 있음!

public class StatefulService {

    private int price; // 상태를 유지하는 필드

    public void order(String name, int price){
        System.out.println("name = "+name + " price = "+price);
        this.price = price; //여기가 문제
    }

    public int getPrice(){
        return price;
    }

}

class StatefulServiceTest {

    @Test
    void statefulServiceSingleton(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
        StatefulService statefulService1 = ac.getBean(StatefulService.class);
        StatefulService statefulService2 = ac.getBean(StatefulService.class);

        //ThreadA : A사용자 10000원 주문
        statefulService1.order("userA",10000);
        //ThreadB : B사용자 20000원 주문
        statefulService2.order("userB",20000);

        //ThreadA : 사용자A 주문 금액 조회
        int price = statefulService1.getPrice();
        System.out.println("price = " + price);

        Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
    }

    static class TestConfig{
        @Bean
        public StatefulService statefulService(){
            return new StatefulService();
        }
    }

}

StatefulService의 price필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경해버리면 문제가 발생

사용자 A가 10000원을 주문하여 this.price에 10000원이 할당됨

→ 사용자 B가 20000원을 주문하여 20000원이 할당

→ 사용자 A가 자신의 객체를 이용하여 주문 조회를 해도 실체 객체 인스턴스가 하나기때문에 20000원이 찍힘 : 문제 발생!!

스프링빈은 항상 무상태로 설계해야함!

public int order(String name, int price){
        System.out.println("name = "+name + " price = "+price);
        return price;
    }

int userAPrice = statefulService1.order("userA",10000);
int userBPrice = statefulService2.order("userB",20000);

System.out.println("price = " + userAPrice);

이런식으로 지역변수를 할당해서 문제를 해결할 수 있음

@Configuration과 싱글톤

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService(){
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository(){
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService(){
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy(){
        return new RateDiscountPolicy();
    }
}

@Bean memberService() → MemoryMemberRepository()

@Bean orderService() → MemoryMemberRepository(), RateDiscountPolicy()

이렇게되면 MemoryMemberRepository가 2개 생성되면서 싱글톤이 깨지는 것 아닌가?라는 의문점이 들 수 있음

    @Test
    void configurationTest(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

        MemberServiceImpl memberService = ac.getBean("memberService",MemberServiceImpl.class);
        OrderServiceImpl orderService = ac.getBean("orderService",OrderServiceImpl.class);
        MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

        MemberRepository memberRepository1 = memberService.getMemberRepository();
        MemberRepository memberRepository2 = orderService.getMemberRepository();

        System.out.println("memberService -> memberRepository = " + memberRepository1);
        System.out.println("orderService -> memberRepository = " + memberRepository2);
        System.out.println("memberRepository = " + memberRepository);

        Assertions.assertThat(memberService.getMemberRepository()).isSameAs(memberRepository);
        Assertions.assertThat(orderService.getMemberRepository()).isSameAs(memberRepository);
    }

검증결과 memberRepository 인스턴스는 모두 같은 인스턴스가 공유하여 사용

스프링 컨테이너가 각각 @Bean을 호출해서 스프링 빈을 생성한다. 이때 memberRepository()는

1. 처음 등록 1번
2. memberService()에서 한번
3. orderService()에서 한번

총 세번 호출되는가? → 아님

실제로 각 한번씩만 호출된다

call AppConfig.memberService

call AppConfig.memberRepository

call AppConfig.orderService

@Configuration과 바이트코드 조작의 마법

@Test
    void configurationDeep(){
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
        AppConfig bean = ac.getBean(AppConfig.class);

        System.out.println("bean.getClass() = " + bean.getClass());
    }

AnnnotationConfigApplicationContext에 파라미터로 넘긴값은 스프링 빈에 등록되므로 Appconfig도 스프링빈이됨

Appconfig 스프링 빈을 조회해서 클래스 정보를 출력해본 결과

bean.getClass() = class hello.core.AppConfig$$SpringCGLIB$$0

위와같은 결과가 나옴

순수한 클래스라면 class hello.core.AppConfig 이런 결과가 나와야함스프링이 CGLIB이라는 바이트코드 조작 라이브러리를 사용해서 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링빈으로 등록한 것이다

이 임의의 다른 클래스가 싱글톤이 보장되도록 해줌

AppConfig@CGLIB 예상코드

@Bean
public MemberRepository memberRepository() {

    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) { 
        return 스프링 컨테이너에서 찾아서 반환;
    } else { //스프링 컨테이너에 없으면
        기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록 
        return 반환
    }
}

memberRepository는 바이트코드를 조작해서 다음과 같은 형식으로 다시 작성될 것

@Bean이 붙은 메소드마다 이미 등록되어있으면 존재하는 빈을 반환하고 없으면 생성해서 스프링빈에 등록하고 반환 → 싱글톤!

+) AppConfig@CGLIB은 AppConfig의 자식타입이므로, AppConfig 타입으로 조회가능

@Configuration을 적용하지 않고, @Bean만 적용하면 어떻게 될까?

AppConfig가 CGLIB 기술없이 순수한 AppConfig로 스프링빈에 등록됨

→ bean = class hello.core.AppConfig

호출결과도 MemberRepository가 총 3번 호출됨

→ 여기서 각각 인스턴스 또한 다 다름

즉, 싱글톤이 깨짐

@Bean만 사용해도 스프링빈으로 등록되지만 싱글톤 보장 X

스프링 설정 정보는 항상 @Configuration을 사용하도록 하자

인프런 스프링 핵심 원리 기본편 - 김영한 강의를 듣고 정리한 내용입니다

//스프링 컨테이너 생성
ApplicationContext applicationContext =new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext를 스프링 컨테이너라고함

ApplicationContext는 인터페이스임 → 다형성 O

new AnnotationConfigApplicationContext(AppConfig.class); 이부분이 구현체

1. 스프링 컨테이너 생성

`new AnnotationConfigApplicationContext(AppConfig.class);`

생성시 구성정보를 지정해주어야해서 AppConfig.class를 매개변수로 넣는것

2. 스프링 빈 등록

@Bean붙은 메소드를 다 호출해서 `메소드 이름을 빈 이름(키)`, `리턴하는 객체를 빈 객체(값)`으로 빈 저장소에 저장

빈이름은 메소드 이름을 사용하지 @Bean(name="memberService2")이런식으로 부여도 가능

빈 이름은 `항상 다른 이름`을 부여해야함

3. 스프링 빈 의존관계 설정 - 준비

4. 스프링 빈 의존관계 설정 - 완료

설정 정보를 참고해서 동적 `의존관계를 주입`

스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져있다

컨테이너에 등록된 모든 빈 조회

public class ApplicationContextInfoTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames(); // 모든 빈 이름 꺼내기
        // iter
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + "object = "+bean);
        }
    }

    @Test
    @DisplayName("애플리케이션 빈 출력하기")
    void findApplicationBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames(); // 모든 빈 이름 꺼내기
        // iter
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            // 역할은 3가지 존재
            // ROLE_APPLICAITON : 내가 등록한 빈만 고르는 조건
            if(beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION){
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName + "object = "+bean);
            }

        }
    }
}

getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름 조회 → String 빈 이름 리턴

getBean(빈이름) : 빈이름으로된 빈객체를 조회

beanDefinition.getRole

• ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈
• ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

스프링 빈 조회 - 기본

가장 기본적인 빈 조회 방법

• ac.getBean(빈이름, 타입)
• ac.getBean(타입)

조회대상 스프링 빈이 없으면 예외 발생NoSuchBeanDefinitionException: No bean named 'xxxxx' available

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName(){
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        System.out.println("memberService = " + memberService);
        System.out.println("memberService.getClass() = " + memberService.getClass());
        // MemberServiceImpl이 잘 출력됨
        Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름없이 타입으로만 조회")
    void findBeanByType(){
        MemberService memberService = ac.getBean(MemberService.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    // 인터페이스 아닌 구체타입도 가능하다. 그러나 아래는 추상이 아닌 구현에 의존한 코드이므로 좋은 코드는 아니긴함
    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2(){
        MemberService memberService = ac.getBean("memberService",MemberServiceImpl.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회X")
    void findBeanByNameX(){
        // MemberService xxxx = ac.getBean("xxxx", MemberService.class);
        assertThrows(NoSuchBeanDefinitionException.class, 
                ()->ac.getBean("xxxx", MemberService.class));
    }

}

빈 타입으로 조회, 빈이름+타입으로 조회, 구체타입으로 조회 모두 가능

Assertions의 isInstanceOf(MemberServiceImpl.class)로 테스트 가능하다

구체타입으로 조회는 추천 X 유연성이 떨어짐

없는 빈 이름으로 조회하면 예외가 터짐

assertThrow(..)은 예외가 발생해야지 테스트가 성공하는 테스트

스프링 빈 조회 - 동일한 타입이 둘 이상

조회 시 같은 타입의 스프링 빈이 두개 이상이면 오류 발생 : NoUniqueBeanDefinitionException

→ 빈 이름 지정해줘야함

ac.getBeansOfType()으로 타입의 모든 빈 조회가능

public class ApplicationContextSameBeanFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class);

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByTypeDuplicate(){
        //MemberRepository bean = ac.getBean(MemberRepository.class);
        assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(MemberRepository.class));
    }

    @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByName(){
        MemberRepository memberRepository = ac.getBean("memberRepository1",MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemberRepository.class);

    }

    @Test
    @DisplayName("특정 타입을 모두 조회하기")
    void findBeanByType(){
        Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key+"value = "+beansOfType.get(key));
        }
        System.out.println("beansOfType = " + beansOfType);
        assertThat(beansOfType.size()).isEqualTo(2);

    }

    // 중복 타입이 있는 config를 여기서만 사용할 수 있게 생성
    // static : 이 안에서만 쓰겠다
    @Configuration
    static class SameBeanConfig{
        @Bean
        public MemberRepository memberRepository1(){
            return new MemoryMemberRepository();
        }

        @Bean
        public MemberRepository memberRepository2(){
            return new MemoryMemberRepository();
        }

    }
}

동일 타입의 빈이 두개이상이라면 빈이름을 통해서 getBean해주면됨

getBeansOfType은 빈이름, 빈객체를 맵으로 리턴

스프링 빈 조회 - 상속 관계

부모타입으로 조회하면 자식타입도 함께 조회된다.

자바 객체의 최고 부모인 Object 타입으로 조회하면 모든 스프링빈 조회

public class ApplicationContextExtendsFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);

    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상있으면, 중복 오류가 발생한다")
    void findBeanByParentTypeDuplicate(){
        //DiscountPolicy bean = ac.getBean(DiscountPolicy.class);
        assertThrows(NoUniqueBeanDefinitionException.class,
                ()->ac.getBean(DiscountPolicy.class));
    }

    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상있으면, 빈 이름을 지정하면 된다")
    void findBeanByParentTypeBeanName(){
        DiscountPolicy rateDiscoutPolicy = ac.getBean("rateDiscountPolicy",DiscountPolicy.class);
        assertThat(rateDiscoutPolicy).isInstanceOf(DiscountPolicy.class);
    }

    @Test
    @DisplayName("특정 하위 타입으로 조회")
    void findBeanBySubType(){
        RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
        assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
    }

    @Test
    @DisplayName("부모 타입으로 모두 조회")
    void findAllBeanByParentType(){
        Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
        assertThat(beansOfType.size()).isEqualTo(2);
        for(String key:beansOfType.keySet()){
            System.out.println("key = "+key+"value = "+beansOfType.get(key));
        }
    }

    @Test
    @DisplayName("부모 타입으로 모두 조회하기 - Object")
    void findAllBeanByObjectType(){
        Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
        for(String key:beansOfType.keySet()){
            System.out.println("key = "+key+"value = "+beansOfType.get(key));
        }
    }

    @Configuration
    static class TestConfig{
        @Bean
        public DiscountPolicy rateDiscountPolicy(){
            return new RateDiscountPolicy();
        }

        @Bean
        public DiscountPolicy fixDiscountPolicy(){
            return new FixDiscountPolicy();
        }
    }
}

부모타입으로 조회 → 자식이 둘이상이면 오류 발생 → 빈 이름 지정해줘야함

특정 하위 타입으로도 조회가능 → 비추

부모타입으로 모두 조회 가능 getBeansOfType → 자바 최상위 클래스인 Object.class로도 조회 가능

BeanFactory와 ApplicationContext

BeanFactory

스프링 컨테이너의 최상위 인터페이스

스프링 빈 관리, 조회 역할

getBean()을 제공

ApplicationContext

BeanFactory기능을 모두 상속받아서 제공

→ 둘의 차이가 무엇일까? : 애플리케이션 개발에는 빈 관리, 조회 뿐만 아닌 많은 기능들이 추가로 필요함

MessageSource 메세지 소스를 활용한 국제화 기능 : 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력하는 기능

EnvironmentCapable 환경변수 : 로컬, 개발, 운영등을 구분해서 처리

• 로컬 : 내 컴퓨터에서 개발하는 환경
• 개발 : 테스트 서버에서 테스트하는 환경
• 운영 : 실제 프로덕션에 나가는 환경

ApplicationEventPublisher 애플리케이션 이벤트 : 이벤트를 발행하고 구독하는 모델 편리하게 지원

ResourceLoader 편리한 리소스 조회 : 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

정리하자면

ApplicationContext는 BeanFactory의 기능(관리, 조회) + 편리한 부가기능을 제공

BeanFactory를 직접 사용할일은 거의 없고, ApplicationContext만 쓴다고 보면됨 → 두개 모두 스프링 컨테이너라고 한다

다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어있음 → 자바 코드, XML, Groovy 등등…

annotation 기반 자바 코드 설정 사용

• 지금까지 했던것
• AnnotationConfigApplicationContext = new AnnotationConfigApplicationContext(AppConfig.class)

XML 설정 사용

• 최근에 잘 사용하진 않지만, 아직 많은 레거시 프로젝트들이 XML로 되어있고 컴파일이 필요없다는 장점이 있음

public class XmlAppContext {

    @Test
    void xmlAppContext(){
        ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        Assertions.assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

GenericXmlApplicationContext(”appConfig.xml”) 이것만 다름

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="memberService" class="hello.core.member.MemberServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository"/>
    </bean>

    <bean id="memberRepository" class="hello.core.member.MemoryMemberRepository"/>

    <bean id="orderService" class="hello.core.order.OrderServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository"/>
        <constructor-arg name="discountPolicy" ref="discountPolicy"/>
    </bean>

    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy"/>
</beans>

코드 형식만 다르지 기존 AppConfig와 다르지 않음

스프링 빈 설정 메타 정보 - BeanDefinition

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까

→ 이것도 역할과 구현을 개념적으로 나눈 것

→ 자바코드인지, XML인지 스프링 컨테이너는 몰라도됨. 그냥 읽어서 BeanDefinition을 만들면됨

BeanDefinition을 빈 설정 메타정보라고함 → @Bean, 당 각각 하나씩 메타정보가 생성됨

스프링 컨테이너는 이 메타정보를 기반으로 스프링빈 생성

BeanDefinition 자체가 인터페이스임

AnnotationConfigApplicationContext : AnnotatedBeanDefinitionReader를 통해서 Appconfig.class를 읽음

→ 설정 정보를 읽어서 BeanDefinition을 생성

GenericXmlApplicationContext : 동일하게 XmlBeanDefinitionReader를 통해 appConfig.xml을 읽고 BeanDefinition 생성

ublic class BeanDefinitionTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 설정 메타정보 확인")
    void findApplicationBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for(String beanDefinitionName : beanDefinitionNames){
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            if(beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION){
                System.out.println("beanDefinitionName = " + beanDefinitionName+" beanDefinition = "+beanDefinition);
            }
        }
    }
}

BeanDefinition 정보

BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음) factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig factoryMethodName: 빈을 생성할 팩토리 메서드 지정, 예) memberService Scope: 싱글톤(기본값) lazyInit: 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한 생성을 지연 처리 하는지 여부 InitMethodName: 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명 DestroyMethodName: 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명 Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정 처럼 팩토리 역할의 빈을 사용 하면 없음)

BeanDefinition을 직접 생성해서 스프링 컨테이너에 등록할수도 있다 → 그러나 쓸일은 잘 없음

인프런 스프링 핵심 원리 기본편 - 김영한 강의를 듣고 정리한 내용입니다