hoon DevLog

유튜브 프리미엄 싸게 할인 가족계정 공유하는 방법

개발한기발자 — Wed, 15 Jan 2025 17:30:02 +0900

본 포스팅은

파트너스 활동을 통해

일정액의 수수료를

제공받을 수 있습니다.

2025년이 되면서 점점 주머니 사정이 쉽지 않다.

유튜브 프리미엄이 아니더라도,

넷플릭스를 비롯한 OTT 종류도,

볼 것도 너무 많다.

이것도 모자라 안드로이드는 14,900원, iOS는 19,500원으로

사용하는 기기에 따라 금액도 천차만별이다.

앞으로 환율도 오르고, 유튜브 정책에 따라

요금도 인상된다면 월 15,000원에서 20,000원은

우습게 올라갈 것으로 예측되는데...

그래서 필자가 몇 년째 사용하는

공유 스트리밍 플랫폼인 Goingbus!!

월 10,000원이 넘는 금액대에서

월 4,000원 대로 사용하는 방법을

공유해 보고자 한다!

Goingbus 공식 홈페이지다.

화면에서 볼 수 있듯 유튜브 프리미엄뿐만 아니라

넷플릭스, 스포티파이, 챗지피티 등

서비스별로 합리적인 금액으로 이용할 수 있다!

구독공유 플랫폼을 이용하지 않는 분들은 다소 생소하게 느껴질 수 있지만,
글로벌 결제를 통해 100개 이상의 국가에서 안전한 결제가 가능하고,

결제 즉시 해당 OTT를 이용할 수 있고,

원치 않을 경우 24시간 내에 빠른 환불도 가능하기 때문에

믿고 이용해 볼 수 있다.

GoingBus 바로가기

위의 링크로 들어가 공식 홈페이지에 들어가 구글이나 라인으로

간단한 회원가입을 진행한다.

'지금 구매하기'를 클릭하면 위와 같이 1년 치 한 번에 결제로 진행된다.

1년에 39.99 달러는 58,465원으로(2025.01.15 환율 1,462원 기준)

한 달에 약 4,800원 돈으로 이용할 수 있다!

그런데 여기서 프로모션 코드까지 입력한다면?!

'프로모션 코드 입력'을 클릭해서

프로모션 코드에 'hoon'을 입력하면

4달러를 추가로 할인해 준다!

단, 계정당 최초 1회만 적용되니

잘 생각하고 본인이 가장 많이 사용하고,

가장 할인을 높게 받을 플랫폼을 선택해서

가능한 많은 할인을 받기 바란다!

결제는 위와 같이 신용카드, 카카오페이, 네이버페이 등등

다양한 결제수단으로 결제 가능하다!

결제를 완료하면 위처럼 이메일 입력란이 보이는데,

여기에 내가 유튜브 프리미엄 혜택을 받을 메일 주소를 입력하면 된다.

메일을 입력하면 내가 입력한 메일 주소로

고잉버스 초대링크가 오게 된다!

이어서 링크를 받고 '시작하기'를 누르고

'가족가입'을 누르면 끝!

엄청 간단하지 않은가?!?!

이어서 웹이든 모바일이든 해당 계정으로

유튜브를 들어가면 프리미엄 상태임을

확인할 수 있다!

간혹 유튜브 프리미엄 사용 중에 광고가 나타나거나,

혹은 "가족 그룹에 문제가 있습니다."라는 메일 알림을 받는 경우가 있다.

이런 경우 발생한 시점에 바로 챗봇 고객문의를 통해 2~3일에서

길게는 5일 안에 조치가 되고 사용하지 못한 만큼 만료 기간을 연장해 준다.

그러니 문제가 발생하면, 반드시!!! 고객센터에 먼저 문의해서

조치받기 바란다!

곧 있으면 설 연휴인데,

돈 걱정 없이 모두 재밌는 OTT 즐기기를 바라며

오늘 포스팅은 끝!

Kotlin array 코틀린 배열 참조 및 사용 emptyArray arrayOf

개발한기발자 — Wed, 7 Aug 2024 11:14:33 +0900

배열 정의하기, arrayOf()

코틀린에서도 역시 배열 구조를 구현하는 타입은 Array
배열 크기를 미리 안다면 표준 함수 중 하나를 사용해 배열을 생성 가능

배열 정의

val a = 배열명<배열타입>
val b = arrayOf("배열원소1", "배열원소2", ...)

예제

fun main(){
    val a = emptyArray<String>()        // Array<String> (원소 0개)
    val b = arrayOf("Hello", "World")   // Array<String> (원소 2개)
    val c = arrayOf(1, 4, 9)            // Array<Int> (원소 3개)

    // 방법 1: contentToString 사용
    println(a.contentToString())
    println(b.contentToString())
    println(c.contentToString())

    // 방법 2: for 루프 사용
    for (item in a) {
        println(item)
    }

    for (item in b) {
        println(item)
    }

    for (item in c) {
        println(item)
    }

    // 방법 3: joinToString 사용
    println(a.joinToString(", "))
    println(b.joinToString(", "))
    println(c.joinToString(", "))

    // 방법 4: forEach 사용
    a.forEach { println(it) }
    b.forEach { println(it) }
    c.forEach { println(it) }
}

결과

필요에 맞게 contentToString(), jointoString("구분자"), for, forEach문을 이용해서 출력

람다식과 Array()

다음은 사용자가 입력한 값에 이르는 정수의 제곱으로 이뤄진 배열을 만든다.

val size = readLine()!!.toInt()
val squares = Array(size) { (it + 1)*(it + 1) }

println(squares.contentToString())  // [1, 4, 9, 16, 25]

size에 배열의 크기를 입력받음.
!!는 null 안전성 연산자로 readLine()이 null을 반환할 수 있기 때문에 !!를 사용하여 null이 아닌 값을 보장한다.
{ (it + 1) * (it + 1) } : 배열의 각 요소를 초기화하는 람다 함수
it는 배열의 인덱스를 표현하는 변수로 자동 선언되며, 0부터 시작!

원시타입(primitive type), 박싱타입(boxing type)

원시타입(primitive type) : 실제 값이 스택 메모리에 저장되는 타입
ex). Int, Long, Short, Byte, Float, Double, Char, Boolean
- 원시 타입은 박싱 되지 않은 상태로 메모리에 직접 저장
- 즉, 이러한 타입의 변수는 실제 값 자체를 저장하고 있어 성능이 우수하고 메모리 사용이 효율적이다.
박싱타입(boxing type) : 원시 타입을 객체로 감싸는 래퍼 클래스
ex). Integer, Long, Float, Double 등
- 객체로 감싸져 힙 메모리에 저장되고, 추가적인 메모리 오버헤드가 발생한다

fun main() {
    // 원시 타입
    val primitiveInt: Int = 100
    println(primitiveInt)  // 출력: 100

    // 박싱 타입
    val boxedInt: Int? = primitiveInt
    println(boxedInt)  // 출력: 100

    // 박싱된 타입의 null 처리
    val nullInt: Int? = null
    println(nullInt)  // 출력: null

    // 박싱 타입을 사용하는 리스트
    val intList: List<Int?> = listOf(1, 2, null, 4)
    println(intList)  // 출력: [1, 2, null, 4]
}

원시 타입은 메모리와 성능 면에서 더 효율적이며, null 값을 가질 수 없음.
박싱 타입은 객체로 감싸져 힙 메모리에 저장되며, null 값을 가질 수 있음.

배열 사용하기

배열타입

배열 타입은 문자열 타입과 꽤 비슷하여, size와 lastIndex 프로퍼티가 있고,. 과 인덱스 연산으로 원소에 접근하는 점이 비슷하다.
잘못 인덱스를 사용하면 런타임에 IndexOutOfBoundsException이 발생

val squares = arrayOf( 1, 4, 9, 16 )  
squares.size 	 // 4 
squares.lastIndex // 3
squares[3]       // 16
squares[1]       // 4

배열 원소 변경

위 코드에 이어서 배열의 원소를 변경해 보겠다.

squares[2] = 100 // squares : 1, 4, 100, 16
squares[3] += 9  // squares : 1, 4, 100, 25
squares[0]--     // squares : 0, 4, 100, 16

코틀린에서는 배열의 원소에 직접 연산을 하여, 원본 배열을 변경할 수 있다!

참조형 데이터

자바처럼 배열 타입의 변수 자체에는 실제 데이터에 대한 참조를 저장한다.
이로 인해 배열 변수에 다른 배열을 대입하면 같은 데이터 집합을 공유한다.

val numbers = squares // numbers에 squares 배열을 대입하며 [0, 4, 9, 16]
numbers[0] = 1000     // 바뀐 데이터가 squares와 numbers에 공유됨 [1000, 4, 9, 16]
println(squares[0])   // 1000

배열 복제

원본과 별도의 배열을 만들고 싶다면 copyOf() 함수를 사용해야 한다.
copyOf()는 필요시 다른 크기의 배열을 만들어 내기도 한다.

val numbers = squares.copyOf()
numbers[0] = 1000 // squares에는 영향이 없다.
squares.copyOf(2) // 뒤가 잘림 [1, 4]
squares.copyOf(5) // 부족한 부분에 0이 채워짐 [1, 4, 9, 16, 0]

다른 타입의 배열은 대입 X

배열 타입 변수에 타입이 다른 배열 대입 X

val a = arrayOf(1, 4, 9, 16)
a = arrayOf("one", "two") // Error : can't assign Array<String> to Array<Int>

자바는 상위 타입의 배열에서 하위 타입 배열을 대입할 수 있었다.
코틀린에서는 배열이 가변 데이터 구조 이므로 이런 대입은 런타임시 문제가 될 수 있다.

배열 원소 추가

배열을 생성하면 길이를 바꿀 수 없지만 + 연산자로 원소를 추가한 새로운 배열을 만들 수 있다.

val b = intArrayOf(1, 2, 3) + 4                // 원소를 하나만 추가 : 1, 2, 3, 4
val c = intArrayOf(1, 2, 3) + intArrayOf(5, 6) // 다른 배열을 추가 : 1, 2, 3, 5, 6

배열 비교

문자열과 달리 배열에 대한 ==, != 연산자는 원소자체를 비교하지 않고 참조를 비교한다.
배열 내용을 비교하려면 contentEquals() 함수를 사용하자.

intArrayOf(1, 2, 3) == intArrayOf(1, 2, 3)             // false
intArrayOf(1, 2, 3).contentEquals(intArrayOf(1, 2, 3)) // true

배열 표준 함수

함수	설명	메서드	결과
isEmpty	배열이 비었는지 검사	intArrayOf(1, 2).isEmpty()	false
isNotEmpty	배열에 원소가 있는지 검사	intArrayOf(1, 2).isNotEmpty()	true
indexOf	인자와 일치하는 최초의 배열 아이템의 인덱스를 반환 (일치하는 원소가 없으면 -1)	intArrayOf(1, 2, 3).indexOf(2) intArrayOf(1, 2, 3).indexOf(4)	1 -1

언제나 새로운 정보 공유와 잘못된 정보

비판/지적/태클은 환영입니다!

도움이 되셨다면 공감♥️, 댓글 부탁드려요:)

끝.

Kotlin 코틀린 문자열 템플릿 및 기본 문자열 연산

개발한기발자 — Wed, 31 Jul 2024 08:58:20 +0900

문자열 리터럴 정의

문자열 리터럴의 정의는 큰따옴표(")로 문자를 감싸는 것

val test = "Hello, world!"

문자열에 특수 문자가 들어가면 백슬래시(\) 뒤에 한 문자나 숫자 조합이 오는 문자 조합을 이루는

이스케이프 시퀀스(Escape Sequence)를 사용해야 함!

val text = "Hello, world!\nThis is \"multiline\" string"
// Hello, world!
// This is "multiline" string
println("\u03C0 \u2248 3.14") // π ≈ 3.14

문자열 템플릿

기본적으로 자바에서 사용하는 문자열과 비슷하나,
코틀린은 여러 식에서 문자열을 합성해 내는 훨씬 강력한 방법을 지원한다.

아래 코드는 이름을 입력받아, 개행 후 오늘 날짜를 출력한다.

import java.util.Date

fun main() {
    val name = readLine()
    println("Hello, ${name}!\nToday is {Date()}")
}

기본적으로 ${} 의 중괄호 사이에 넣기만 하면 어떤 코틀린 식이든 문자열에 넣을 수 있다.
간단한 변수 참조인 경우 $name 같이 중괄호를 생략하고 달러($) 기호만 붙여도 된다.
이런 기능을 문자열 템플릿이라고 한다.

로우 문자열(raw string)

로우 문자열을 사용하면 이스케이프 시퀀스를 사용하지 않고도 문자열을 작성할 수 있다.
이런 리터럴은 큰 따옴표 세 개로 둘러 싸여 있고, 새 줄 문자를 포함한 사용자가 입력한 문자를 포함할 수 있다.

import java.util.Date

fun main() {
    val name = readLine()
    val message = """ Hello, $name,
    Today is${Date() } """.trimIndent()
    println(message)
}

trimIndent()는 여러줄에 공통된 최소 들여 쓰기를 제거해 주는 표준 코틀린 함수이다.
로우 문자열에 특수문자를 추가하고 싶은 경우 ${} 안에 특수문자를 넣으면 된다.
JVM으로 컴파일 되는 애플리케이션에서 문자열은 JVM의 String클래스로 표현된다.

fun main() {
    val message = """This is triple quote : ' ${"\"\"\""} '""".trimIndent()
    // This is triple quote : ' """ '
}

length, lastIndex 프로퍼티

length : 모든 String 인스턴스는 문자열에 든 문자 수를 표현
lastIndex : 문자열의 마지막 문자 인덱스를 표현하는 프로퍼티를 제공

"Hello!".length     // 6
"Hello!".lastIndex  // 5 (첫번째 문자의 인덱스가 0 이므로)

[] 연산자로 개별문자 접근

[] 연산자에 인덱스를 넣어 개별문자에 접근하고, 인덱스는 0부터 시작!
잘못된 인덱스를 넘기면 자바와 마찬가지로 StringIndexOutOfBoundsException 예외가 발생

 val s = "Hello! "
 println(s[0])  // H
 println(s[1])  // e
 println(s[5])  // !
 println(s[10]) // 잘못된 인덱스

필자는 Java의 char 배열(char [])과 비슷한 맥락으로 이해했다!

두 문자 연결

+ 연산자로 두 문자를 연결 가능

 val s = "The sum is : " + sum // "The sum is $sum" 으로 대체 가능

두 문자열 비교

문자열은 == 와 != 를 사용해서 동등성 비교 가능
이들 연산은 문자열의 내용을 비교하므로 문자의 순서와 같이 길이가 같으면 다른 객체의 인스턴스를 같은 문자열로 간주한다!!

 val s1 = "Hello!"
 val s2 = "Hel" + "lo!"
 println(s1 == s2) // ture

참조동등성을 비교하려면 === 와 !== 연산자를 사용하면 된다.
<, >, <=, >= 같은 연산자를 사용해 문자열을 비교할 수 있다.

 println("abc" < "cba") // true
 println("123" > "34") // false

문자열은 사전식 순서(오름차순)로 정렬되므로 정렬된 순서대로 커진다고 생각하면 된다!
숫자 비교가 아닌 문자열 숫자("숫자")를 비교하는 것이므로 "34"가 더 나중에 정렬되므로 false

타입 변환 함수

말 그대로 기존의 타입을 바꿔주는 함수로 to변환할 타입()으로 명명된다!
toByte(), toShort(), toInt(), toLong(), toFloat(), toDouble(), toBoolean()

기타 문자열 함수

isEmpty : 문자열이 비어있는지 검사
isNotEmpty : 문자열이 비어있지 않은지 검사
substring : 부분 문자열 추출
startsWith : 접두사(prefix) 검사
endsWith : 접미사(suffix) 검사
indexOf : 인자로 받은 문자나 문자열이 수신 객체인 문자열에 나타나는 첫번째 인덱스를 반환

println("Hello".isEmpty())         // "Hello" 문자열이 비어있는지 확인 (false 반환)
println("".isEmpty())              // 빈 문자열이 비어있는지 확인 (true 반환)
println("Hello".substring(2))      // "Hello" 문자열의 인덱스 2부터 끝까지 부분 문자열 반환 ("llo")
println("Hello".substring(1, 3))   // "Hello" 문자열의 인덱스 1부터 3 전까지 부분 문자열 반환 ("el")
println("Hello".startsWith("Hel")) // "Hello" 문자열이 "Hel"로 시작하는지 확인 (true 반환)
println("Hello".endsWith("lo"))    // "Hello" 문자열이 "lo"로 끝나는지 확인 (true 반환)
println("abcabc".indexOf('b'))     // "abcabc" 문자열에서 문자 'b'의 첫 번째 인덱스 반환 (1)
println("abcabc".indexOf("ca"))    // "abcabc" 문자열에서 문자열 "ca"의 첫 번째 인덱스 반환 (2)
println("abcabc".indexOf("cd"))    // "abcabc" 문자열에서 문자열 "cd"를 찾을 수 없으므로 -1 반환
println("abcabc".indexOf('b', 2))  // "abcabc" 문자열에서 인덱스 2부터 문자 'b'를 검색하여 첫 번째 인덱스 반환 (4)
println("abcabc".indexOf("ab", 2)) // "abcabc" 문자열에서 인덱스 2부터 문자열 "ab"를 검색하여 첫 번째 인덱스 반환 (3)

결과

뭔가 문법적으로 정확하게 딱딱 들어맞는 Java와 달리,

비교적 자유도가 높은 코틀린이 좀 더 편해 보이는 듯하다.

물론 아직 익숙지 않아 계속해서 코딩을 직접 하면서 익혀 나가야겠다!

언제나 새로운 정보 공유와 잘못된 정보

비판/지적/태클은 환영입니다!

도움이 되셨다면 공감♥️, 댓글 부탁드려요:)

끝.

YouTube Premium 유튜브 프리미엄 싸게 월 4000원대 저렴한 겜스고 사용법

개발한기발자 — Thu, 18 Jul 2024 08:31:54 +0900

유튜브 프리미엄 가입 화면

유튜브 프리미엄 구독 금액이

어마어마하다.

월 19,500원이면

1년에 234,000원 정도가

지불된다.

이에 몇몇 사용자들은

우회 VPN을 사용하는데,

필자는 방법을 보고

몇 시간 따라 해봤는데,

막히고 안돼서 너무 답답했다.

금액도 고정되지 않고 계속 인상되며,
터키가 최근 막혀, 이집트 등

내가 가본 적 없는 나라들로

계속 이주해야 한다고 한다.

심지어 어떤 VPN은

결제수단으로 비자카드만 가능하거나,

우회 사용 시 계정정지 및 막힘으로
내가 서비스를 사용하는 데 있어

어려움이 생긴다.

이에 따라 요즘 수많은

쉐어 플랫폼이 나오고 있고,

소비자인 우리의 입장에서는

결국 요금과 신뢰도에 따라

선택하게 되는데,

바로 Gamsgo!!

각종 수많은 OTT 서비스를 제공하며,

메인 화면에서도 보시다시피

기존 OTT들 금액의 절반도 안 되는

저렴한 금액으로 OTT를 사용할 수 있다.

너무 저렴하니 사기 아닌가?!?!

라고 생각할 수도 있겠지만,

필자를 포함한 많은 사람들의

각종 사용후기들도 많고,

자체적으로 운영하는 챗봇도 있어

애로사항을 조치받을 수 있다.

[회원가입]

겜스고 바로가기

먼저 위의 겜스고 링크로 들어가

구글 or 페이스북 or 카카오톡을 통해

회원가입을 한다.

[서비스 선택]

그렇게 홈페이지에 들어가서 유튜브를

선택하면 아래와 같은 모달창이 뜬다.

오잉 82.99 달러??

그것도 24개월에??

요즘 환율 1380원으로
계산하면 114,526원.

아무 할인이 없어도

유튜브 공식 홈페이지 요금과 비교하면

2년을 1년 요금보다 더 싸게 하는 격!

근데 거기에 프로모션 코드를 입력하면??

[ 요금 선택]

안 그래도 저렴한 요금이

더 할인이 적용되는 걸 볼 수 있다.

더욱더 할인이 된다면

추가 할인 프로모션 코드를

입력하지 않을 이유가 없다.

(단, 1인 1회 한정!)

프로모션 코드 : PHR6X

꼭 입력해서 할인 놓치지 말자!!!

프로모션 코드나 쿠폰이 있나요?를

클릭하여 위의 프로모션 코드를 입력하면

할인이 적용되는 것을 볼 수 있다.

참고로 자동갱신 활성화를 누르면

추가 할인이 들어가니 참고하기 바란다!!

[결제 수단]

이후 결제 방식을 선택한다.

카카오페이, 네이버페이, 삼성페이 등

우리가 자주 사용하는 결제 수단으로

더욱 신뢰를 가지고 결제할 수 있다.

[결제 완료]

그렇게 필자는 6개월

유튜브 프리미엄 구독 완료!!

우측 상단 구독 탭에서

본인의 구독 및 결제 내역을 확인할 수 있다.

이제 여기서 이메일 인증을 통해

유튜브 계정과 연결해 준다.

화면에 보이는 로그인 이메일,

혹은 유튜브를 연결할 계정을 입력하면,

해당 주소로 초대 메일이 발송된다.

[초대 메일 수신 확인]

겜스고에서 발송한 초대 메일이다.

이 초대 메일의 주황색 버튼을 클릭해

다음 단계로 넘어간다.

[가족 그룹 참여]

화면에 나오는 내용을 숙지하고,

순서대로 가족 가입을 진행하면,

유튜브 프리미엄을 즐길 수 있다!

이렇게 겜스고를 이용해서

유튜브 프리미엄

사용법을 알아봤는데,

위의 가이드 순서대로만 따라온다면

어려움 없이 유튜브 프리미엄을

저렴한 금액에, 싸게 즐길 수 있다.

프로모션 코드까지 적절히 사용해

추가 할인 혜택까지 받아서

부담 없는 금액으로 유튜브를

이용하는 독자들 되시기 바란다.

끝.

본 포스팅은 파트너스 활동을 통해
일정액의 수수료를 제공받을 수 있음.

ChatGPT 챗지피티처럼 질문수 제한 없는 MT GPT 저렴한 사용법

개발한기발자 — Sat, 6 Jul 2024 17:36:24 +0900

필자가 ChatGPT에게 챗지피티를 물어본 결과

챗지피티를 사용하면 알겠지만, 질문을 하다 보면 꼬리에 꼬리를 물게 된다.

결국 질문은 또 다른 질문을 하게 되며 많은 질문을 하게 되어

챗지피티 질문 개수 한도에 다다르게 된다.

때문에 오늘은 한도 없이 질문하는 법에 대해 알아볼 텐데,

바로 GoingBus의 MT-GPT에 대해 알아보겠다!

ChatGPT와 MT-GPT의 차이점

둘 다 동일하게 최신 버전인 1.0, 4o 모두 사용 가능하다.

단지 MT-GPT의 경우 고잉버스 자체 솔루션인 MTLogin 웹 브라우저를

별도로 사용하여 챗지피티를 쓰는 방식이다.

뭔가 더 복잡해 보이는 듯 하지만, 그럼에도 불구하고 사용하는 이유는 질문수 제한이 없다.

아, 그리고 이 MT-GPT는 Window에서만 사용 가능하므로, Mac 유저는 뒤로가기.....ㅠㅠ

그렇다면 고잉버스에서 이 MT-GPT를 사용하는 방법을 알아보자.

GoingBus 공식 페이지로 이동

[회원가입]

회원가입은 기본이다!

사용을 위해선 결제를 해야 하고, 결제를 위해선 회원가입은 필수다!

[MT-GPT 선택]

MT-GPT 한 달은 12.99 달러, 1년은 129.99 달러.

1년을 결제하면 자체적으로 할인이 더 들어가는데,

이렇게 프로모션 코드(hoon)를 입력하면,

아래와 같이 또 추가 할인을 받을 수 있다.

할인은 똑같이 13 달러로 동일하다.

본인 사용량에 맞게 결제하면 되겠다.

필자는 GPT사용량이 최근에 많아지며 1년 치를 결제했다.

[결제]

결제는 삼성페이나 카카오페이, 쓱페이 등 우리가 주로 많이 사용하는 매체를 사용해 결제를 하면 된다!

고잉버스 경험이 많은 필자는 카카오페이를 즐겨 사용한다.

2024년 6월 1일 결제 기준 환율은 약 1400원 정도인 듯하다.

결제가 완료되면, 페이지 우측상단 구독 페이지에서 내가 구독한 고잉버스 서비스들을 확인할 수 있다.

벌써 5개나 구독한 필자는 OTT중독이 아닐까 싶다....ㅎㅎㅎ

그래도 고잉버스의 저렴한 운영정책에 경제적 부담이 많이 줄었다.

알아서 주머니 형편에 맞게 이용하길!

[MT-GPT 사용]

이후, MT-GPT 항목 우측상단에 사용 방법은? 링크를 클릭하면 상세하게 이용가이드가 나와있다.

추후 이 가이드를 한번 정리 및 실제로 필자가 사용하는 방법을 포스팅하겠다.

순서를 잘 따라가며 먼저 웹브라우저를 윈도우버전으로 설치한다.

이렇게 MT-GPT는 고잉버스에서 별도로 관리하는 웹 브라우저를 통해 ChatGPT를 더욱 원활하게 사용할 수 있다.

기존에 ChatGPT도 사용하고 있었는데, 확실히 질문수 제한이 없다 보니, 사용 시 편의성이 확 올라감을 느꼈다.

역시 돈을 써야 하는가 싶지만, 요즘 같은 세상은 정보의 유무로 정말 천지 차이인 것 같다 ㅎㅎ

아무튼 오늘은 이렇게 MT-GPT에 대해서 알아봤는데,

더 이상 ChatGPT의 질문수 제한의 고통을 받지 않고,

자유롭게 원 없이 질문하며 작업해 보자!

끝.

본 포스팅은 파트너스 활동을 통해
일정액의 수수료를 제공받을 수 있음.

Spring gradle project 스프링 핵심 원리 기본편 | Bean Scope 빈 스코프

개발한기발자 — Thu, 13 Jun 2024 11:14:04 +0900

본 포스팅은 인프런에 있는 인터넷 강좌인,

김영한 강사님의 스프링 핵심 원리 기본편을 공부하며,

개인적으로 공부하고, 정리하는 용도로 포스팅을 해보겠다.

Spring gradle project 환경설정 및 회원 가입 서비스 예제 만들기
Spring gradle project 주문/할인 도메인 설계

Spring gradle project 객체 지향 원리 적용

Spring gradle project AppConfig 리팩토링 OCP 위반 해결 및 중복 제거

Spring gradle project 좋은 객체 지향 설계 5가지 원칙 적용 및 스프링 전환

Spring gradle project 스프링 컨테이너와 스프링 빈

Spring gradle project BeanFactory, ApplicationContext 이해 및 차이

Spring gradle project XML 설정 사용, BeanDefinition, 스프링 빈 설정 메타 정보

Spring gradle project 웹 애플리케이션과 싱글톤, WebApplication and Singleton

Spring gradle project 싱글톤 컨테이너, @Configuration

Spring gradle project 컴포넌트 스캔 의존관계, @Autowired, @ComponentScan

Spring gradle project Java Bean Lifecycle and Callback

Bean Scope

Spring에서 지원하는 스코프

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

컴포넌트 스캔 자동 등록 방법

지금까지는 싱글톤 스코프를 사용 했었고, 지금은 프로토타입 스코프를 예제를 통해 알아보자

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

컴포넌트 스캔 자동 등록 방법

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.
프로토타입 스코프는 스프링 컨테이너에서 조회하면 항상 새로운 인스턴스를 생성해서 반환한다.

위 그림에서와 같이 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.
스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다.
이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링을 반환한다.

프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.

스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다
이후에 스프링 컨테이너에 같은 요청이 오면, 항상 새로운 프로토타입 빈을 생성해서 반환한다.
핵심은 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다는 것이다.
클라이 언트에 빈을 반환하고, 이후 스프링 컨테이너는 생성된 프로토타입 빈을 관리하지 않는다.
프로토타입 빈 관리 책임은 프로토타입 빈을 받은 클라이언트에 있기 때문에, @PreDestroy 같은 종료 메서드가 호출되지 않는다.

싱글톤 스코프 빈 테스트

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.assertThat;

public class SingletonTest {
    @Test
    public 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);
        
        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");
        }
    }
}

// 결과
// SingletonBean.init
// singletonBean1 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
// singletonBean2 = hello.core.scope.PrototypeTest$SingletonBean@54504ecd
// org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing SingletonBean.destroy

결과를 보면 빈 초기화 메서드를 실행하고, 같은 인스턴스의 빈을 조회해서, 종료 메서드까지 정상 호출 된 것을 확인할 수 있다.

프로토타입 스코프 빈 테스트

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;

public class PrototypeTest {
    @Test
    public 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);
        
        assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
        
        ac.close(); // 종료
    }

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

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

// 결과
// find prototypeBean1
// PrototypeBean.init
// find prototypeBean2
// PrototypeBean.init
// prototypeBean1 = hello.core.scope.PrototypeTest$PrototypeBean@13d4992d
// prototypeBean2 = hello.core.scope.PrototypeTest$PrototypeBean@302f7971
// org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing

싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행되지만, 프로토타입 스코프의 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화 메서드도 실행된다.
프로토타입 빈을 2번 조회했으므로 완전히 다른 스프링 빈이 생성되고, 초기화도 2번 실행된 것을 확인할 수 있다.
싱글톤 빈은 스프링 컨테이너가 관리하기 때문에 스프링 컨테이너가 종료될 때 빈의 종료 메서드가 실행되지만, 프로토타입 빈은 스프링 컨테이너가 생성과 의존관계 주입 그리고 초기화까지만 관여하고, 더는 관리하지 않는다.
프로토타입 빈은 스프링 컨테이너가 종료될 때 @PreDestroy 같은 종료 메서드가 전혀 실행되지 않는다.

프로토타입 빈의 특징 정리

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

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

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

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

위의 그림을 코드로 확인해 보면 아래와 같다.

import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.assertThat;

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

    @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");
        }
    }
}

PrototypeBean 클래스를 설정으로 사용해서, 프로토타입 빈이 요청 시마다 새로운 인스턴스를 생성하고, 각 인스턴스가 독립적인 상태를 유지하는 것을 테스트한다.
프로토타입 빈 조회 및 테스트
- prototypeBean1을 조회하고, addCount() 메서드를 호출하여 카운트를 1 증가시키고, getCount()를 통해 값이 1인지 확인
- prototypeBean2를 조회하고, 마찬가지로 addCount() 메서드를 호출하여 카운트를 1 증가 후, getCount()를 통해 값이 1인지 확인한다.
- 프로토타입 스코프는 매번 새로운 인스턴스를 생성하므로, 두 빈의 카운트 값이 독립적으로 유지된다.
@Scope("prototype") 어노테이션을 사용하여 프로토타입 스코프 빈을 정의한다.

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

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

clientBean은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.
clientBean은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.
스프링 컨테이너는 프로토타입 빈을 생성해서 `clientBean` 에 반환한다. 프로토타입 빈의 count 필드 값은 0
clientBean은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관)

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

클라이언트 A는 clientBean을 스프링 컨테이너에 요청해서 받는다.(싱글톤이므로 항상 같은 clientBean 반환)
클라이언트 A는 `clientBean.logic()` 을 호출한다.
clientBean은 prototypeBean의 addCount()를 호출해서 프로토타입 빈의 count를 증가한다. count값은 1

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

클라이언트 B는 clientBean을 스프링 컨테이너에 요청해서 받는다.(싱글톤이므로 항상 같은 clientBean 반환)
clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다
주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용할 때마다 새로 생성되는 것이 아니다!
클라이언트 B는 `clientBean.logic()` 을 호출한다.
clientBean` 은 prototypeBean의 `addCount()` 를 호출해서 프로토타입 빈의 count를 증가해서, 원래 count 값이 1이었으므로 2가 된다.

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;

public class SingletonWithPrototypeTest1 {

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

    static class ClientBean {
        private final PrototypeBean prototypeBean;

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

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

    @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");
        }
    }
}

싱글톤 빈이 프로토타입 빈을 사용할 때, 매번 새로운 프로토타입 빈 인스턴스를 주입받도록 설계된 동작을 확인한다.
clientBean1.logic() 호출 시, 주입된 프로토타입 빈의 count가 1로 설정된다.
clientBean2.logic() 호출 시, 새로 주입된 프로토타입 빈의 count가 다시 1로 설정
각각의 ClientBean 인스턴스는 서로 다른 프로토타입 빈 인스턴스를 주입받으므로, count는 독립적으로 유지 된다.
여러 빈에서 같은 프로토타입 빈을 주입 받으면, 주입 받는 시점에 각각 새로운 프로토타입 빈이 생성
예를 들어서 clientA, clientB가 각각 의존관계 주입을 받으면 각각 다른 인스턴스의 프로토타입 빈을 주입 받는다.

그렇다면 이렇게 새로 생성된 프로토타입 빈과 함께 유지되는 싱글톤 빈에 대한 문제를 해결하려면??

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

바로 스프링 컨테이너에 요청하는 것이다.

싱글톤 빈이 프로토 타입을 사용할 때 마다 스프링 컨테이너에 새로 요청하는 것이다.

package hello.core.scope;

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.assertThat;

public class PrototypeProviderTest {
    
    @Test
    void providerTest() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);
        
        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        assertThat(count1).isEqualTo(1);
        
        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        assertThat(count2).isEqualTo(1);
        
        ac.close();
    }

    static class ClientBean {
        @Autowired
        private ApplicationContext ac;

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

    @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");
        }
    }
}

ApplicationContext를 사용하여 프로토타입 빈을 동적으로 요청하는 방법이다.
providerTest() 메서드에서 clientBean1과 clientBean2는 각각 logic() 메서드를 호출
logic() 메서드 내부에서 ApplicationContext를 사용하여 PrototypeBean 인스턴스를 매번 새롭게 요청
각 ClientBean 인스턴스는 독립적으로 새로운 PrototypeBean 인스턴스를 주입받으므로, 두 PrototypeBean 인스턴스는 서로 다른 상태를 유지
assertThat(count1).isEqualTo(1)과 assertThat(count2).isEqualTo(1)을 통해, 두 프로토타입 빈의 카운트 값이 각각 1임을 확인한다.
핵심코드는 ClientBean이다.
- 실행해보면 ac.getBean()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.
- 의존관계를 외부에서 주입(DI) 받는게 아니라 이렇게 직접 필요한 의존관계를 찾는 것을 Dependency Lookup (DL) 의존관계 조회(탐색)라고 한다.
- 그런데 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워진다.

ObjectFactory, ObjectProvider

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

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;

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

스프링에서 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것이 바로 ObjectProvider이다.
(참고로 과거에는 ObjectFactory가 있었는데, 여기에 편의 기능을 추가해서 ObjectProvider가 만들어졌다.)
실행해보면 prototypeBeanProvider.getObject()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다
ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환 한다. (DL)
스프링이 제공하는 기능을 사용하지만, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

스프링을 사용하다 보면 이 기능뿐만 아니라 다른 기능들도 자바 표준과 스프링이 제공하는 기능이 겹칠 때가 있다.

하지만 결국 스프링이 더 다양하고 편리한 기능을 제공해주기 때문에, 스프링이 제공하는 기능을 잘 사용하면 되겠다.

그러려면....계속해서 꾸준히 공부하자!

끝.

Spring gradle project 스프링 핵심 원리 기본편 | Java Bean Lifecycle and Callback 생명 주기 콜백

개발한기발자 — Tue, 11 Jun 2024 14:04:12 +0900

본 포스팅은 인프런에 있는 인터넷 강좌인,

김영한 강사님의 스프링 핵심 원리 기본편을 공부하며,

개인적으로 공부하고, 정리하는 용도로 포스팅을 해보겠다.

Spring gradle project 환경설정 및 회원 가입 서비스 예제 만들기
Spring gradle project 주문/할인 도메인 설계

Spring gradle project 객체 지향 원리 적용

Spring gradle project AppConfig 리팩토링 OCP 위반 해결 및 중복 제거

Spring gradle project 좋은 객체 지향 설계 5가지 원칙 적용 및 스프링 전환

Spring gradle project 스프링 컨테이너와 스프링 빈

Spring gradle project BeanFactory, ApplicationContext 이해 및 차이

Spring gradle project XML 설정 사용, BeanDefinition, 스프링 빈 설정 메타 정보

Spring gradle project 웹 애플리케이션과 싱글톤, WebApplication and Singleton

Spring gradle project 싱글톤 컨테이너, @Configuration

Spring gradle project 컴포넌트 스캔 의존관계, @Autowired, @ComponentScan

빈 생명주기 콜백 시작

이번 포스팅에서는 스프링을 통해, 이러한 초기화 작업과 종료 작업을 어떻게 진행하는지 예제로 알아보자.

데이터베이스 Connection Pool이나, 네트워크 소켓처럼, 애플리케이션 시작 시점에 필요한 연결을 미리 해두고,

애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다.

간단하게 외부 네트워크에 미리 연결하는 객체를 하나 생성한다고 가정해 보자.

실제로 네트워크에 연결하는 것은 아니 고, 단순히 문자만 출력하도록 했다.

아래 NetworkClient는 애플리케이션 시작 시점에 connect()를 호출해서 연결을 맺어두어야 하고,

애플리케이션이 종료되면 `disConnect()` 를 호출해서 연결을 끊어야 한다.

테스트 하위에 생성한 예제코드

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);
    }
}

Spring 환경설정과 실행

import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
public class BeanLifeCycleTest {
    @Test
    public void lifeCycleTest() {
        
        ConfigurableApplicationContext ac = new AnnotationConfigApplicationContext(LifeCycleConfig.class);
        
        NetworkClient client = ac.getBean(NetworkClient.class); ac.close(); //스프링 컨테이너를 종료, ConfigurableApplicationContext 필요
    }
    
    @Configuration
    static class LifeCycleConfig {
        @Bean
        public NetworkClient networkClient() {
            NetworkClient networkClient = new NetworkClient();
            networkClient.setUrl("http://hello-spring.dev");
            return networkClient;
        }
    }
}

Spring 애플리케이션 컨텍스트를 생성하고 LifeCycleConfig 설정 클래스를 로드하여 NetworkClient Bean을 등록하고 초기화
NetworkClient Bean의 초기화와 소멸 과정을 확인하기 위해 ac.close()로 컨테이너를 종료하여 소멸 Callback을 실행

실행 결과는 다음과 같다.

생성자 호출, url = null
connect: null
call: null message = 초기화 연결 메시지

url 정보 없이 connect가 호출되는 것을 확인할 수 있다
객체를 생성하는 단계에는 url이 없고, 객체를 생성한 다음에 외부에서 수정자 주입을 통해서 setUrl()이 호출되어야 url이 존재!

SpringBean의 Lifecycle

스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 →소멸 전 콜백 → 스프링 종료
초기화 콜백 : 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
소멸전 콜백 : 빈이 소멸되기 직전에 호출
SpringBean은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료
따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다!
Spring은 의존관계 주입이 완료되면 Spring Bean에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다.
또한 Spring은 Spring Container가 종료되기 직전에 소멸 콜백을 주면서, 안전하게 종료 작업을 진행할 수 있다.

객체의 생성과 초기화 분리

생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다.
반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.
따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것보다는 객체를 생성하는 부분과 초기화하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다. (초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우)
싱글톤 빈들은 스프링 컨테이너가 종료될 때 싱글톤 빈들도 함께 종료되기 때문에 스프링 컨테이너가 종료되기 직전에 소멸 전 콜백이 일어난다.

Spring의 빈 생명주기 콜백 지원 3가지

인터페이스(InitializingBean, DisposableBean)
설정 정보에 초기화 메서드, 종료 메서드 지정
@PostConstruct, @PreDestroy

InitializingBean, DisposableBean 인터페이스

package hello.core.lifecycle;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class NetworkClient implements InitializingBean, DisposableBean {
    
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    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);
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        connect();
        call("초기화 연결 메시지");
    }

    @Override
    public void destroy() throws Exception {
        disConnect();
    }
}

// 결과
// 생성자 호출, url = null
// NetworkClient.afterPropertiesSet
// connect: http://hello-spring.dev
// call: http://hello-spring.dev message = 초기화 연결 메시지
// 13:48:49.043 [main] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing NetworkClient.destroy
// close + http://hello-spring.dev

InitializingBean은 afterPropertiesSet() 메서드로 초기화를 지원한다.
DisposableBean은 destroy() 메서드로 소멸을 지원한다.
출력 결과를 보면 초기화 메서드가 주입 완료 후에 적절하게 호출된 것을 확인할 수 있다.
스프링 컨테이너의 종료가 호출되자 소멸 메서드가 호출 된 것도 확인할 수 있다.

초기화, 소멸 인터페이스 단점

이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
초기화, 소멸 메서드의 이름을 변경할 수 없다.
내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

빈 등록 초기화, 소멸 메서드 지정

위의 예제 코드에 초기화와 소멸 메서드를 추가한다.

package hello.core.lifecycle;

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    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);
    }

    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;
    }
}

// 결과
// 생성자 호출, url = null
// NetworkClient.init
// connect: http://hello-spring.dev
// call: http://hello-spring.dev message = 초기화 연결 메시지
// 13:58:47.215 [main] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing NetworkClient.close
// close + http://hello-spring.dev

설정 정보 사용 특징

메서드 이름을 자유롭게 줄 수 있다.
스프링 빈이 스프링 코드에 의존하지 않는다.
코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다

@PostConstruct, @PreDestroy

package hello.core.lifecycle;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class NetworkClient {
    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }

    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);
    }

    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }

    @PreDestroy
    public void close() {
        System.out.println("NetworkClient.close");
        disConnect();
    }
}

@Configuration
static class LifeCycleConfig {
    @Bean
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    }
}

// 결과
// 생성자 호출, url = null
// NetworkClient.init
// connect: http://hello-spring.dev
// call: http://hello-spring.dev message = 초기화 연결 메시지
// 13:58:47.215 [main] DEBUG org.springframework.context.annotation.AnnotationConfigApplicationContext - Closing NetworkClient.close
// close + http://hello-spring.dev

@PostConstruct, @PreDestroy 애노테이션은 최신 스프링에서 가장 권장하는 방법이다.
가장 편리한 방법으로 초기화와 종료를 실행할 수 있다.
패키지를 잘 보면 javax.annotation.PostConstruct이다.
(스프링에 종속적인 기술이 아니라 JSR-250라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.)
컴포넌트 스캔과 잘 어울린다.
유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료해야 하면 @Bean의 기능을 사용하자.

이제 거의 끝이 보인다.

인강을 다 듣는다고 다 알아지는 게 아니니, 계속해서 반복 또 반복, 실행하는 수밖에 없다.

그간 실무 코드에서 적용하지 못하고, 잘 알지 못했던 부분을 인강과 개인 공부를 통해서나마, 좀 더 깊게 알아가야겠다.

끝.

Spotify 스포티파이 싸게 저렴하게 월 2000원대 요금 및 사용법

개발한기발자 — Wed, 29 May 2024 16:08:02 +0900

음원 스트리밍 서비스는 다양하다.

대표적으로 국내에서는 멜론, 지니 바이브, FLO 등이 있고,

해외는 스포티파이, 유튜브뮤직, 타이들 등이 있다.

근데 음원 스트리밍 서비스를 갈아탈 일이 있을까?

Spotify 공식 홈페이지에 공시한 요금

결국 요금이다.

UI야 내가 익숙해지기만 하면,

음원스트리밍 UI는 비슷비슷하다.

스포티파이 요금 또한

가장 저렴한 게 월 7,900원으로

만만치가 않다.

그래서 이러한 요금 문제를 극복할 수 있는

공유플랫폼,

Goingbus, 고잉버스!

다양한 OTT 서비스를 제공하는 고잉버스는

이렇게 스포티파이와 같은 음원 스트리밍 서비스도

공유하는 방식으로 저렴하게 서비스를 제공하고 있다.

GoingBus 공식 페이지로 이동

[회원가입]

위의 링크를 통해 고잉버스를 접속하여, 로그인 화면으로 간다!

결제를 위해 반드시 가입은 필수.
구글이나 네이버 로그인으로 간편하게 가입할 수 있다.

[스포티파이 선택]

스포티파이를 클릭하면 아래와 같이 창이 뜬다.

프로모션 코드 입력을 클릭해서

아래 프로모션 코드를 입력하면 할인이 적용된다.

프로모션 코드 : hoon

왼쪽이 할인 전, 오른쪽이 할인 후의 금액이다.

스포티파이 공식 홈페이지에서 베이직으로 결제 시 월 7,900원으로,

1년이면 9만 원에 육박하는 금액인데,

고잉버스를 이용한다면 약 29,000원인데,

월 2,500원도 안 되는 요금으로 사용할 수 있는 셈이다!

프로모션 코드 입력 시 약 10프로 가까이 할인되니,

안 할 이유가 없다!

1년은 좀 많은 것 같아,

3개월만 결제한다.

금액대비 할인율만 다를 뿐,

총 할인 금액인 2.38 달러는 똑같다.

[결제]

결제는 신용카드뿐만 아니라,

삼성페이, 카카오페이, 페이코, 쓱 페이까지

국내에서 믿고 쓸 수 있는,

결제 수단으로 사용 가능하다!

필자는 카카오페이로 결제하겠다!

결제하기를 클릭하면 이런 창이 뜨는데,

아래 약관 동의를 하면,

카카오페이머니나 카드 결제를

선택할 수 있다.

그러고 결제 진행하면 끝!

[결제완료]

결제되면 우측 상단에 구독 버튼을 클릭하면,

화면과 같이 내가 사용하는 서비스를 확인할 수 있다.

위의 순서를 잘 따라왔다면,

스포티파이가 정상적으로 구독이 되어있다!

[주의할 점]

스포티파이 같은 경우

고잉버스에서 지급한 아이디 / 비밀번호를 사용하면 되니,

굳이 새로운 계정을 만들어 가입할 필요 없다.

기타 발생하는 이슈 사항 대처법은

아래 필자의 포스팅 링크를 확인하기 바란다!

넷플릭스 유튜브 프리미엄 우회 싸게, 저렴하게, 고잉버스 GoingBus 사용법

[스포티파이 사용법]

웹이나 앱 모두 사용 가능하다.

필자는 앱을 자주 사용하므로 앱을 다운로드한다.

로그인 화면에서 맨 밑에 로그인하기를 클릭한다.

그리고 아까 고잉버스 홈페이지에서 확인한,

스포티파이 사용자와 비밀번호 내용을 잘 입력한다.

로그인이 정상적으로 되었다면,

어떤 음악을 좋아하는지 묻는다.

아마 선택한 언어 및 가수로,

비슷한 취향의 노래를 추천해 주는 것 같다.

필자는 예시로 걸그룹을 선택하고 완료 버튼 클릭!

이러면 디폴트 세팅이 끝나고

자유롭게 음악 스트리밍 서비스를 이용하면 된다.

사실 걸그룹 노래도 좋지만,

알고리즘이 갑자기 데이식스와 같은

인디밴드 노래도 추천해 준 바람에

듣게 됐다 ㅎㅎㅎ

확실히 뭔가 다른 음악 스트리밍 서비스 앱들에 비해

노래도 방대하고, 음질도 좋은 느낌이다.

고잉버스가 요금을 절약해 준 만큼,

내 귀도 스포티파이를 통해 호강한다.

이 글을 읽고 보시는 분들도

보다 저렴하게 다양한 구독 서비스를 이용하고 싶다면,

고잉버스를 이용하기를 추천한다~

끝.

본 포스팅은 파트너스 활동을 통해
일정액의 수수료를 제공받을 수 있음.

AWS IAM 루트 계정 및 사용자 그룹 정책 사용

개발한기발자 — Tue, 28 May 2024 16:52:20 +0900

이번 시간에는 AWS에서 사용자 및 사용자 그룹 정책과 관련이 있는

IAM 기능에 대해서 알아보도록 하겠다.

IAM 이란?

IAM은 Identity and Access Management의 약자로 IAM에서는 사용자를 생성하고 그룹에 배치한다.
가장 기본적인 기능으로 Region 상관없이 글로벌 서비스에 해당한다.
계정을 생성할 때 루트 계정을 만들었는데, 이는 기본으로 생성되는 것이다.
IAM을 통해, 사용자와 그룹을 만들 수 있다.
사용자(user)는 복수 그룹에 속할 수 있고, 그룹 안에 그룹을 넣을 수 없다.
또한 아무 그룹에 속하지 않은 사용자가 있을 수 있다.
그룹을 지정하는 이유는 권한(permissions)부여 때문이다

쉽게 말해 사용자 접근, 권한 설정인데,

개발자는 백문이 불여일타,

직접 해보면서 알아보도록 하자.

우측 상단에 내 계정정보가 있다.

이는 처음에 회원가입시, 디폴트로 만들어진 루트 계정이다.

[IAM]

먼저 상단 검색에서 IAM을 검색해서 클릭한다.

아직 생성한 특별한 사용자가 없기 때문에, 표시할 리소스가 없다고 나온다.

우측에 사용자 생성을 클릭한다.

[사용자 세부 정보 설정]

사용자 생성을 클릭하면, 아래와 같은 화면이 나온다.

AWS Management Consol에 대한 사용자 액세스 권한 제공을 체크하고사용자 유형에 IAM 사용자를 생성하고 싶음을 클릭한 뒤,사용자 이름과 사용자 암호를 입력한다.

만약 실무에서 한다면,

새롭게 생성된 사용자의 보안을 위해

사용자는 다음 로그인 시 새 암호를 생성해야 합니다를 체크해 준다.

지금은 번거로움을 생략하기 위해 체크를 하지 않고 진행한다.

해당 정보를 모두 입력했으면 다음을 누른다.

[사용자 그룹 생성]

기존에 만들어진 사용자 그룹이 없기 때문에 사용자 그룹을 생성한다.

사용자 그룹이름을 입력한다.

정책은 아무거나 선택해 주고 사용자 그룹 생성을 눌러준다.

[권한설정]

그룹에 사용자 추가를 체크하고,

방금 만든 그룹 이름을 체크하고 다음 클릭!

[검토 및 생성]

내가 입력한 정보를 확인한다.

태그는 키-값 형태로 입력하여 추가할 수 있다.

입력한 정보를 확인하고 태그 값을 입력했으면 사용자 생성을 클릭한다.

[사용자 생성 완료]

사용자 생성을 클릭하면 아래와 같은 화면이 보인다.

이제 루트 계정이 아닌 계정으로 로그인을 할 수 있다.

나중에 이 계정으로 로그인 하기 위해, 콘솔 로그인 URL을 복사해 놓는다.

그리고 우선 사용자 목록으로 돌아가기를 클릭한다.

정상적으로 사용자가 생성되었고,

IAM 목록에도 아래와 같이 보인다.

사용자 그룹도 정상적으로 등록 되어있고,

아래 사용자 또한 위의 설정을 통해 admin 그룹에 포함되어 있다.

사용자 이름에 있는 사용자를 클릭한다.

사용자가 속한 그룹 및 정책을 볼 수 있다.

이외에 그룹, 태그, 보안자격 증명 등의 내용도 확인할 수 있다.

[IAM 대시보드]

이제 IAM을 검색해서 들어가면 아래와 같이 보인다.

내가 만든 사용자, 사용자 그룹이 생겼기 때문에 해당 정보가 보이고,

AWS 계정 접속을 위한 ID와 URL도 우측에 보인다.

우측 ID 정보 밑에 계정 별칭을 생성해 준다.

[계정 별칭 생성]

아래 사진과 같이 별칭을 생성해 준다.

별칭을 생성하면 아래와 같이 계정 ID+URL이 아닌,

이제 별칭+URL로 AWS 콘솔 로그인이 가능하다.

[계정별칭과 사용자 이름으로 로그인]

위에서 등록한 정보로 로그인을 시도한다.

로그인이 잘 되었으면 아래와 같은 정보가 정상적으로 잘 보이게 된다.

[루트계정과 IAM 사용자 로그인]

어느 한쪽이 로그인 상태일 때,

루트계정 혹은 IAM 사용자로 로그인 시, 다른 쪽 세션이 종료되어 로그아웃된다.

이때 양쪽 모두 로그인하여 정보를 확인해야 할 경우,

Chrome, Edge, Safari 등의 웹 브라우저에서 새 시크릿 창 or 새 프라이빗 창으로 로그인하면,

아래와 같이 루트계정과 IAM 사용자가 동시에 로그인 가능하다.

가장 기본적인 기능이면서,

보안적으로 가장 중요한 기능이니,

절차 하나하나 유의하여 잘 사용해 보도록 하자!

IAM 정리

끝!

Spring gradle project 스프링 핵심 원리 기본편 | 컴포넌트 스캔 의존관계 자동 주입, @Autowired, @ComponentScan

개발한기발자 — Mon, 27 May 2024 08:52:46 +0900

본 포스팅은 인프런에 있는 인터넷 강좌인,

김영한 강사님의 스프링 핵심 원리 기본편을 공부하며,

개인적으로 공부하고, 정리하는 용도로 포스팅을 해보겠다.

Spring gradle project 환경설정 및 회원 가입 서비스 예제 만들기
Spring gradle project 주문/할인 도메인 설계

Spring gradle project 객체 지향 원리 적용

Spring gradle project AppConfig 리팩토링 OCP 위반 해결 및 중복 제거

Spring gradle project 좋은 객체 지향 설계 5가지 원칙 적용 및 스프링 전환

Spring gradle project 스프링 컨테이너와 스프링 빈

Spring gradle project BeanFactory, ApplicationContext 이해 및 차이

Spring gradle project XML 설정 사용, BeanDefinition, 스프링 빈 설정 메타 정보

Spring gradle project 웹 애플리케이션과 싱글톤, WebApplication and Singleton

Spring gradle project 싱글톤 컨테이너, @Configuration

컴포넌트 스캔

컴포넌트 스캔과 의존관계 자동 주입 시작하기

지금까지 스프링 빈을 등록할 때, 자바 코드의 @Bean이나 XML의 <bean> 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다.
이렇게 등록해야 할 스프링 빈이 수십, 수백 개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다.
그래서 스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.
의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다.

SpringBootAutoAppConfig.java

import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import static org.springframework.context.annotation.ComponentScan.*;

@Configuration
@ComponentScan(excludeFilters = @Filter(type=FilterType.ANNOTATION, classes=Configuration.class))
public class AutoAppConfig {

}

@ComponentScan 어노테이션은 Spring이 어노테이션이 붙은 클래스를 스캔하고 빈으로 등록할 패키지를 지정한다.
excludeFilters 속성은 스캔 대상에서 특정 유형의 컴포넌트를 제외한다.
여기서는 @Filter 어노테이션을 사용하여 type을 FilterType.ANNOTATION으로 설정하고, classes를 Configuration.class로 설정해서, @Configuration 어노테이션이 붙은 클래스는 컴포넌트 스캔 과정에서 제외된다.
컴포넌트 스캔을 사용하면 @Configuration이 붙은 설정 정보도 자동으로 등록되기 때문에, AppConfig, TestConfig 등 앞서 만들어두었던 설정 정보도 함께 등록되고, 실행되어 버린다.
그래서 excludeFilters를 이용해서 설정정보는 컴포넌트 스캔 대상에서 제외했다.

MemoryMemberRepository @Component 추가

@Component
public class MemoryMemberRepository implements MemberRepository {}

RateDiscountPolicy @Component 추가

 @Component
 public class RateDiscountPolicy implements DiscountPolicy {}

MemberServiceImpl @Component, @Autowired 추가

@Component
public class MemberServiceImpl implements MemberService {
    
    private final MemberRepository memberRepository;
    
    @Autowired
    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

}

이전에 AppConfig에서는 @Bean으로 직접 설정 정보를 작성했고, 의존관계도 직접 명시했다.
이제는 이런 설정 정보 자체가 없기 때문에, 의존관계 주입도 이 클래스 안에서 해결해야 한다.
@Autowired는 의존관계를 자동으로 주입해 준다
@Autowired를 사용하면, 아래와 같이 생성자에서 여러 의존관계도 한 번에 주입받을 수 있다.

OrderServiceImpl @Component, @Autowired 추가

@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;
    }
    
}

AutoAppConfigTest.java

import hello.core.AutoAppConfig;
import hello.core.member.MemberService;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import static org.assertj.core.api.Assertions.*;

public class AutoAppConfigTest {

    @Test
    void basicScan() {
        ApplicationContext ac = new
        
        AnnotationConfigApplicationContext(AutoAppConfig.class);
        
        MemberService memberService = ac.getBean(MemberService.class);
        
        assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

AnnotationConfigApplicationContext를 사용하는 것은 기존과 동일하다.
설정 정보로 AutoAppConfig 클래스를 넘겨준다

위의 코드를 실행하면, 로그를 통해 컴포넌트 스캔이 잘 동작하는지 확인할 수 있다.

그렇다면 이제 컴포넌트 스캔과 자동 의존관계 주입이 어떻게 동작하는지 그림으로 알아보자.

@ComponentScan

위에서 설명했듯, @ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.
이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.
빈 이름 기본 전략 : MemberServiceImpl 클래스 → memberServiceImpl
빈 이름 직접 지정 : 만약 스프링 빈의 이름을 직접 지정하고 싶으면 @Component("memberService2") 이런 식으로 이름을 부여하면 된다.

@Autowired 의존관계 자동 주입

생성자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.
(getBean(MemberRepository.class)` 와 동일하다고 이해하면 된다.)

생성자에 파라미터가 많아도 다 찾아서 자동으로 주입한다.

탐색할 패키지의 시작 위치 지정

모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 탐색하도록 시작 위치를 지정할 수 있다.

 @ComponentScan(basePackages={"hello.core", "hello.service"})

basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.
위 코드와 같이 여러 시작 위치를 지정할 수 있다.
basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
만약 지정하지 않으면 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다
권장하는 방법으로는 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것이다. 최근 스프링 부트도 이 방법을 기본으로 제공한다.

예를 들어서 프로젝트가 다음과 같이 구조가 되어 있다고 가정하자.

com.hello
com.hello.serivce
com.hello.repository

com.hello → 프로젝트 시작 루트, 여기에 AppConfig 같은 메인 설정 정보를 두고, @ComponentScan 어노테이션을 붙이고, basePackages 지정은 생략한다.

이렇게 하면 com.hello를 포함한 하위는 모두 자동으로 컴포넌트 스캔의 대상이 된다.
그리고 프로젝트 메인 설정 정보는 프로젝트를 대표하는 정보이기 때문에 프로젝트 시작 루트 위치에 두는 것이 좋다 생각한다.

** 참고로 스프링 부트를 사용하면 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 이 프로젝트 시작 루트 위치에 두는 것이 관례이다. (그리고 이 설정 안에 바로 @ComponentScan이 들어있다!)

컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component 뿐만 아니라 다음과 내용도 추가로 대상에 포함한다.

@Component : 컴포넌트 스캔에서 사용
@Controller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용
@Configuration : 스프링 설정 정보에서 사용

사실 어노테이션에는 상속관계라는 것이 없다.

그래서 이렇게 어노테이션이 특정 어노테이션을 들고 있는 것을 인식할 수 있는 것은

자바 언어가 지원하는 기능은 아니고, 스프링이 지원하는 기능이다.

컴포넌트 스캔의 용도뿐만 아니라 다음 어노테이션이 있으면 스프링은 부가 기능을 수행한다.

@Controller : 스프링 MVC 컨트롤러로 인식
@Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해 준다.
@Configuration : 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.
@Service : 사실 @Service는 특별한 처리를 하지 않는다. 대신 개발자들이 '핵심 비즈니스 로직이 여기에 있겠구나' 정도로 비즈니스 계층을 인식하는데 도움이 된다.

또한 필터를 이용하여 컴포넌트 스캔대상을 추가/제외 지정할 수 있다.

includeFilters : 컴포넌트 스캔에서 추가 대상 지정
excludeFilters : 컴포넌트 스캔에서 제외 대상 지정

컴포넌트 스캔 대상에 추가할 어노테이션

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyIncludeComponent {
}

컴포넌트 스캔 대상에 제외할 어노테이션

import java.lang.annotation.*;

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface MyExcludeComponent {
}

컴포넌트 스캔 대상에 추가할 클래스

@MyIncludeComponent
public class BeanA {
}

컴포넌트 스캔 대상에 제외할 클래스

@MyExcludeComponent
public class BeanB {
}

설정 정보와 전체 테스트 코드

import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import static org.assertj.core.api.Assertions.assertThat;
import static org.springframework.context.annotation.ComponentScan.Filter;

public class ComponentFilterAppConfigTest {

    @Test
    void filterScan() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(ComponentFilterAppConfig.class);
        BeanA beanA = ac.getBean("beanA", BeanA.class);
        assertThat(beanA).isNotNull();
        Assertions.assertThrows(NoSuchBeanDefinitionException.class, () -> ac.getBean("beanB", BeanB.class));
    }
                 
    @Configuration
    @ComponentScan(includeFilters=@Filter(type=FilterType.ANNOTATION, classes=MyIncludeComponent.class),
                   excludeFilters=@Filter(type=FilterType.ANNOTATION, classes=MyExcludeComponent.class))
    static class ComponentFilterAppConfig {
    }
    
}

includeFilters에 MyIncludeComponent 어노테이션을 추가해서 BeanA가 스프링 빈에 등록된다.
excludeFilter에 MyExcludeComponent 어노테이션을 추가해서 BeanB는 스프링 빈에 등록되지 않는다.

FilterType 옵션

FilterType은 5가지 옵션이 있다.

ANNOTATION : 기본값, 애노테이션을 인식해서 동작한다. ex) org.example.SomeAnnotation
ASSIGNABLE_TYPE : 지정한 타입과 자식 타입을 인식해서 동작한다. ex) org.example.SomeClass
ASPECTJ : AspectJ 패턴 사용 ex) org.example..*Service+
REGEX : 정규 표현식 ex) org\.example\.Default.*
CUSTOM : TypeFilter이라는 인터페이스를 구현해서 처리 ex) org.example.MyTypeFilter

최근 스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데,

개인적으로는 옵션을 변경하면서 사용하기보다,

스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장하고, 선호하는 편이다.

말 그대로 사용하기 좋게 만든 프레임워크이기 때문에

스프링 개발자의 의도를 따라 기본 설정에 맞춰 사용하는 것이,

가장 안전하고 유지 보수에도 좋을 것이다.

아무튼 오늘은 이렇게 ComponentScan에 대해서 알아봤다.

끝.