코딩하는 경제학도

[Kotlin] 범위지정함수 let, run, with, apply, also를 공식 문서를 통해 알아보자!

Ssoco — Tue, 19 Nov 2024 04:45:24 +0900

한동안 안드로이드와 코틀린을 업무에 있어서 사용하면서 코틀린 내부 구현이나 동작을 자세하게 공부할 기회가 없었습니다.

그러다보니 제대로 공부하지 않고 감으로 사용하던 코드들이 많아졌고, 이 메서드를 왜 이렇게 사용한걸까 싶은 경우들이 많아졌습니다.

그래서!! 이번 포스팅에서는 정말 많이 사용하지만, 자세하게 공부하지는 않았었던 범위지정함수에 대해서 공식 문서를 번역해 보면서 알아보려고 합니다!

(의역 혹은 원문에는 없는 추가 코멘트들이 다수 포함될 수 있으니 참고 바랍니다!!)

더 원활한 이해를 위해 원문을 읽고 싶으신 분들을 위해 하단에 공식문서 링크도 함께 첨부드립니다~~

Scope functions | Kotlin

kotlinlang.org

0. 범위지정함수가 뭔데?

코틀린에서의 범위지정함수는 람다 표현식을 통해 임시 스코프를 만들고 그 안에서 이름 없이 객체에 접근할 수 있도록 도와주는 함수를 말합니다.

let, run, with, apply, also 총 5종류가 존재하고, 모두 동일하게 내부 블록(람다 표현식)을 실행하도록 동작합니다.

각각은 블록 내에서 어떻게 객체를 이용할 수 있는지와 전체 표현식의 반환값이 무엇인지에 따라 구분됩니다.

이 부분은 가장 중요한 설명 부분이므로 단순히 의역하기보다는 보다 명확하게 설명하는게 좋을 것 같아서, 특별히 코틀린 공식 홈페이지의 원문을 가져왔습니다. (이 문단 뒤부터 원문은 생략합니다 ㅋㅋㅋ)

The Kotlin standard library contains several functions whose sole purpose is to execute a block of code within the context of an object. When you call such a function on an object with a lambda expression provided, it forms a temporary scope. In this scope, you can access the object without its name. Such functions are called scope functions. There are five of them: let, run, with, apply, and also.

Basically, these functions all perform the same action: execute a block of code on an object. What's different is how this object becomes available inside the block and what the result of the whole expression is.

아래 예시는 let이라는 범위지정함수를 사용한 예입니다.

물론 범위지정함수를 쓰지 않더라도 동일하게 동작하는 코드를 만들 수도 있기 때문에, 해당 케이스도 예시에 같이 포함시켰습니다.

// 범위지정함수 let 사용
Person("Alice", 20, "Amsterdam").let {
    println(it)
    it.moveTo("London")
    it.incrementAge()
    println(it)
}

// 범위지정함수 미사용
val alice = Person("Alice", 20, "Amsterdam")
println(alice)
alice.moveTo("London")
alice.incrementAge()
println(alice)

위 예시를 봤을 때 큰 차이가 느껴지지 않을 수도 있습니다.

하지만 let이 없는 아래 코드의 경우 alice라는 변수를 선언하고 이것을 반복해서 사용해야 한다는 것을 볼 수 있습니다.

즉 let을 사용함으로써 코드가 비교적 짧아지거나 가독성이 높아질 수 있다는 것을 확인할 수 있습니다.

5개의 범위지정함수 중에서 어떤 것을 써야하는 지는 딱히 정답이 정해져있는 것은 아닙니다. 개발자가 직접 판단해서 이 곳에는 이걸 쓰는게 더 좋은 것 같으면 쓰면 되는 것이죠.

이걸 위해서 범위지정함수가 어떤 차이가 있는지, 각각 어떤 방식으로 동작하는지에 대해서 보다 자세히 알아볼 필요가 있습니다!

1. 먼저 간단히 요약좀..

각각의 범위지정함수에 대해서 자세하게 알아보기 전에, 먼저 표를 통해 간단하게 차이점부터 알아보고 갑시다!

아래에서 더 자세히 다룰 예정이니, 여기서 짧게 다룬다고 너무 걱정하지 않으셔도 됩니다~

함수	객체 참조	반환값	확장함수 여부
let	it	람다 결과값	O
run	this	람다 결과값	O
run	-	람다 결과값	X (단독으로 사용 가능)
with	this	람다 결과값	X (매개변수로 객체를 받음)
apply	this	컨텍스트 객체	O
also	it	컨텍스트 객체	O

공식 문서에서는 일반적으로 사용되는 케이스에 대해서도 짧게 알려주고 있습니다.

let : non-nullable한 객체에 대해서 람다 표현식을 실행하고 싶을 때 / 지역 스코프에서 표현식을 변수 형태로 사용하고 싶을 때
apply : 객체를 정의할 때
run : 객체를 정의하고 결과값을 연산해야할 때 / 표현식이 필요한 명령문을 실행할 때 (단독 사용 시)
also : 추가적인 effect가 존재할 때 (side-effect의 그 effect입니다)
with : 객체에서 함수 호출을 묶고싶을 때

반드시 위 상황에서만 써야하는 것은 아니고, 팀 내에 특정 컨벤션이 존재하거나 한다면 거기에 따라가도 좋습니다.

하지만 범위지정함수를 남발하게 되면 오히려 코드의 가독성을 해치거나 잘못 사용하게 되어 에러가 발생할 수도 있습니다.

그리고 중첩해서 범위지정함수를 사용하는 것도 코드의 이해도를 낮추거나, 범위지정함수가 대상으로 하는 객체, 혹은 스코프 내부에서 사용하는 this, it과 같은 객체 참조 요소에 대한 혼동을 줄 수 있으니 주의해야 합니다.

2. 대충 알았으니까 무슨 차이가 있는건데?

범위지정함수는 일반적으로 비슷하게 보이지만, 크게 객체 참조 방식과 반환값 두 가지 형태로 나눌 수 있습니다.

사진으로 미리 정리해보면 아래와 같습니다!

2.0. 객체 참조 방식: this / it

객체 참조 방식에 있어서 this를 쓰는 범위지정함수와 it을 쓰는 범위지정함수로 나뉩니다.

this의 경우 람다 수신자(객체 참조자), it은 람다 인수(람다 매개변수)라고 부릅니다.

아래에서 두 케이스에 대한 사용법과 장단점 등을 알아봅시다.

fun main() {
    val str = "Hello"
    // this를 사용하는 run
    str.run {
        println("The string's length: $length")
        //println("The string's length: ${this.length}") // 이렇게도 가능!!
    }

    // it을 사용하는 let
    str.let {
        println("The string's length is ${it.length}")
    }
}

2.0.0. this

this를 사용하는 케이스는 run, with, apply가 있습니다.

세 가지 케이스에서는 람다 표현식 내부에서 일반적인 클래스 함수들처럼 객체를 사용할 수 있습니다.

val adam = Person("Adam").apply { 
    age = 20  // this.age = 20와 동일!!
    city = "London"
}
println(adam)

2.0.1. it

it을 사용하는 케이스는 let과 also가 있습니다.

두 케이스에서는 인수(매개변수) 형태로 객체를 참조할 수 있고, 그렇기 때문에 명시적으로 이름도 설정할 수 있습니다.

만약 명시적으로 이름을 설정하지 않으면 it 이라는 기본 이름으로 참조할 수 있습니다.

// 암시적(it)으로 인수를 설정했을 경우
fun getRandomInt(): Int {
    return Random.nextInt(100).also {
        writeToLog("getRandomInt() generated value $it")
    }
}

val i = getRandomInt()
println(i)

// 명시적(value)으로 인수를 설정했을 경우
fun getRandomInt(): Int {
    return Random.nextInt(100).also { value ->
        writeToLog("getRandomInt() generated value $value")
    }
}

val i = getRandomInt()
println(i)

it은 this보다 짧고, 가독성이 좋습니다.

하지만 this의 경우 객체의 함수나 속성값(property)를 사용할 때는 아예 생략해버릴 수 있다는 장점이 있습니다.

그러므로 함수의 인자로 들어가야 한다거나, 코드블럭 내에서 여러 변수를 사용해야 한다거나하는 케이스에서 it이 더 좋습니다.

2.1. 반환값: 객체 / 람다 표현식

반환값의 유무로도 범위지정함수를 구분할 수 있습니다.

apply와 also는 객체를 그대로 반환하고 let, run, with은 람다 표현식의 결과값을 반환합니다.

즉 let, run, with은 반환값이 없을 수도 있습니다.

그렇기 때문에 다음에 이 결과값으로 무엇을 할 지에 따라 사용하는 범위지정함수를 잘 결정해야 합니다.

2.1.0. 객체 반환

apply와 also는 객체를 반환하기 때문에 chain 함수를 사용할 수도 있습니다.

아래 예시처럼 람다 표현식을 마치고 정렬을 한다거나.. 할 수 있는 거죠.

val numberList = mutableListOf<Double>()
numberList.also { println("Populating the list") }
    .apply {
        add(2.71)
        add(3.14)
        add(1.0)
    }
    .also { println("Sorting the list") }
    .sort()

아니면 object의 함수 반환문 형태로도 사용할 수 있습니다. (반환할 때 어떠한 동작을 추가한 다음 반환할 수 있습니다!!)

fun getRandomInt(): Int {
    return Random.nextInt(100).also {
        writeToLog("getRandomInt() generated value $it")
    }
}

val i = getRandomInt()

2.1.1. 람다 표현식 반환

let, run, with은 람다 표현식을 반환하기 때문에 따로 변수에 결과값을 할당해 주어야만 결과값을 이어서 사용할 수 있습니다.

val numbers = mutableListOf("one", "two", "three")
val countEndsWithE = numbers.run { 
    add("four")
    add("five")
    count { it.endsWith("e") }
}
println("There are $countEndsWithE elements that end with e.")

아예 반환을 하지 않고 임시 스코프 형태로 사용할 수도 있습니다.

val numbers = mutableListOf("one", "two", "three")
with(numbers) {
    val firstItem = first()
    val lastItem = last()        
    println("First item: $firstItem, last item: $lastItem")
}

3. 각각의 함수들에 대해서 자세히 알려줘!

이제 5가지의 범위지정함수에 대해서 좀 더 디테일하게 뜯어봅시다.

3.0. let

let은 객체 참조는 it으로 가능하고, 람다 표현식을 반환합니다.

보통 하나 혹은 여러 함수들이 연속해서 동작할 때 사용합니다.

예를 들면 두 collections가 존재하고, 결과값을 출력해야 한다고 가정해보겠습니다.

val numbers = mutableListOf("one", "two", "three", "four", "five")
val resultList = numbers.map { it.length }.filter { it > 3 }
println(resultList)

let을 사용하면 resultList를 변수에 할당하지 않고도 똑같이 동작하는 코드를 만들 수 있습니다.

val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let { 
    println(it)
    // 필요하면 여기에서 함수를 더 호출할 수도 있다!
}

만약 let 안에 하나의 함수만 들어가는 경우, 메서드 참조(::)를 사용해서 더 간단히 표현할 수도 있습니다.

val numbers = mutableListOf("one", "two", "three", "four", "five")
numbers.map { it.length }.filter { it > 3 }.let(::println)

그리고 let은 non-null값들을 담은 코드블럭을 실행할 때도 자주 사용됩니다.

non-null object에서만 실행되게 하기 위해 safe call operator(?.)를 사용할 수 있습니다.

val str: String? = "Hello"

// str은 String? 타입으로 null이 올 수 있어서 compilation error가 발생!!
// processNonNullString(str) 

// 'it' 은 '?.let { }' 블럭 내에서 not-null을 보장받을 수 있다!!
val length = str?.let { 
    println("let() called on $it")        
    processNonNullString(it) 
    it.length
}

또한 제한된 스코프 안에서 변수를 선언해서 코드의 가독성을 높이는 데에 let을 사용할 수도 있습니다.

객체에 새로운 변수를 정의하기 위해서 람다 표현식의 인수(매개변수)에 이름을 부여하여 it 대신 그 이름으로 대신 사용할 수도 있습니다.

val numbers = listOf("one", "two", "three", "four")
val modifiedFirstItem = numbers.first().let { firstItem ->
    println("The first item of the list is '$firstItem'")
    if (firstItem.length >= 5) firstItem else "!" + firstItem + "!"
}.uppercase()
println("First item after modifications: '$modifiedFirstItem'")

3.1. with

with은 객체 참조는 this로 가능하고, 람다 표현식을 반환합니다.

특이한 점이라면, 확장함수 형태로 사용하지 않습니다. 대신 객체를 인수(매개변수) 형태로 전달합니다.

with은 객체의 메서드를 사용하면서 반환값을 반환하지 않는 경우 사용하는 것을 추천합니다.

with은 코드상에서 "매개변수로 받은 객체와 함께, 람다 표현식을 실행합니다!" 로도 읽힐 수 있습니다.

val numbers = mutableListOf("one", "two", "three")
with(numbers) {
    println("'with' is called with argument $this")
    println("It contains $size elements")
}

with은 값을 연산하는데 사용되는 속성이나 함수를 가진 helper 객체를 선언하기 위해서도 사용됩니다.

val numbers = mutableListOf("one", "two", "three")
val firstAndLast = with(numbers) {
    "The first element is ${first()}," +
    " the last element is ${last()}"
}
println(firstAndLast)

3.2. run

run은 객체 참조는 this로 가능하고, 람다 표현식을 반환합니다.

그럼 with이랑 똑같은 게 아니냐?? 라고 생각할 수도 있겠지만, run은 확장함수 형태로 사용합니다.

그래서 let처럼 객체 뒤에 .run { } 과 같은 형태로 사용할 수 있습니다.

run은 람다 표현식 내에서 객체를 초기화하고 반환값을 연산해야 하는 경우 유용하게 사용될 수 있습니다.

val service = MultiportService("https://example.kotlinlang.org", 80)

val result = service.run {
    port = 8080
    query(prepareRequest() + " to port $port")
}

// let으로 똑같이 동작하도록 만들 수도 있습니다
val letResult = service.let {
    it.port = 8080
    it.query(it.prepareRequest() + " to port ${it.port}")
}

또 특이한 점이라면, run은 확장함수가 아닌 형태로도 사용할 수 있습니다.

확장함수가 아닌 형태의 run은 부모 객체가 없지만, 람다 표현식의 반환값은 존재합니다.

그래서 표현식이 필요한 곳에서 여러 선언문을 포함한 블록을 실행할 수 있게 도와줍니다.

확장함수가 아닌 형태의 run은 코드 상에서 "코드 블럭을 run 하고 결과를 도출합니다!"로 읽힐 수 있습니다.

val hexNumberRegex = run {
    val digits = "0-9"
    val hexDigits = "A-Fa-f"
    val sign = "+-"

    Regex("[$sign]?[$digits$hexDigits]+")
}

for (match in hexNumberRegex.findAll("+123 -FFFF !%*& 88 XYZ")) {
    println(match.value)
}

3.3. apply

apply는 객체 참조는 this로 가능하고, 객체를 반환합니다.

객체를 그대로 반환하기 때문에, 객체의 멤버 변수를 주로 실행하면서 값을 반환하지 않는 케이스에 사용하는 것을 권장합니다.

가장 대표적으로 많이 쓰이는 케이스가 객체 구성(설정)입니다.

이러한 동작은 "객체에 다음과 같은 할당을 적용합니다!"로 읽힐 수 있습니다.

val adam = Person("Adam").apply {
    age = 32
    city = "London"        
}
println(adam)

또 다른 사용 예시의 경우 복잡한 처리 과정을 위해 여러번 체이닝을 하는 것입니다.

(이건 원문에 따로 예시가 없어서 직접 만들었습니다!)

val adam = Person("Adam").plusAge().celebrate().apply {
    status = "adult"        
}
println(adam)

3.4. also

also는 객체 참조는 it으로 가능하고, 객체를 반환합니다.

also는 객체를 인수로 사용하는 일부 작업을 수행하는 데 유용합니다.

객체의 속성이나 함수가 아닌 객체 자체에 대한 참조가 필요하거나, 외부 스코프의 this 참조를 가리지 않으려는 경우 also를 사용하는 것을 권장합니다.

이러한 동작은 "그 객체로 다음의 작업을 수행합니다!"로 읽힐 수 있습니다.

val numbers = mutableListOf("one", "two", "three")
numbers
    .also { println("The list elements before adding new one: $it") }
    .add("four")

4. 번외로 알아보는 takeIf와 takeUnless

위에서 공부한 범위지정함수 외에도 표준 라이브러리에는 takeIf와 takeUnless라는 함수가 포함되어 있습니다.

이 두 함수를 통해 객체 상태를 검사할 수 있습니다.

takeIf는 객체의 확장함수 형태로 조건식과 함께 호출되었을 때 해당 조건을 만족하면 해당 객체를 반환하고, 만족하지 못하면 null을 반환합니다.

그래서 takeIf는 단일 객체를 위한 필터링 함수입니다.

takeUnless는 takeIf와 반대의 로직으로 동작합니다.

조건을 만족하면 null, 만족하지 않으면 객체를 반환합니다.

두 케이스 모두에서 객체는 람다 표현식 내에서 it으로 접근할 수 있습니다.

val number = Random.nextInt(100)

val evenOrNull = number.takeIf { it % 2 == 0 }
val oddOrNull = number.takeUnless { it % 2 == 0 }
println("even: $evenOrNull, odd: $oddOrNull")

❗ 여기서 한 가지 주의해야 하는 점이라면, takeIf나 takeUnless 뒤에 다른 함수를 체이닝할 때는
safe call operator(?.)을 사용하거나 null 체크를 하는 것을 잊지 마세요!!
(takeIf랑 takeUnless는 nullable한 반환값을 주니까!!!)

val str = "Hello"
val caps = str.takeIf { it.isNotEmpty() }?.uppercase()

// str이 empty면 null에 대해 .uppercase()를 할 수 없어서 compilation 에러가 발생한다!!
// val caps = str.takeIf { it.isNotEmpty() }.uppercase() 

println(caps)

takeIf와 takeUnless는 범위지정함수와 결합할 때 굉장히 유용합니다.

예를 들어 takeIf, takeUnless와 let을 체이닝하면 특정 조건에 만족하는 객체에 대해서만 코드 블럭을 실행할 수 있습니다.

이걸 위해 takeIf를 호출한 이후 safe call operator(?.)와 함께 let을 호출하면 됩니다.

조건에 만족하지 않는 객체에 대해서는 takeIf가 null을 반환하게 되고 let이라는 범위지정함수의 람다 표현식은 실행되지 않겠죠?

fun displaySubstringPosition(input: String, sub: String) {
    input.indexOf(sub).takeIf { it >= 0 }?.let {
        println("The substring $sub is found in $input.")
        println("Its start position is $it.")
    }
}

displaySubstringPosition("010000011", "11")
displaySubstringPosition("010000011", "12")

비교를 위해서 아래 예시는 takeIf와 범위지정함수를 사용하지 않으면 어떻게 되는지를 보여줍니다.

fun displaySubstringPosition(input: String, sub: String) {
    val index = input.indexOf(sub)
    if (index >= 0) {
        println("The substring $sub is found in $input.")
        println("Its start position is $index.")
    }
}

displaySubstringPosition("010000011", "11")
displaySubstringPosition("010000011", "12")

[Android] 안드로이드 개발의 기초, Activity의 생명주기 톺아보기!

Ssoco — Tue, 2 Apr 2024 03:06:45 +0900

인턴 생활을 자발적으로 그만두고(!) 새로운 회사에 들어가고 단 한번도 생각해보지 않았던 앱 개발을 맡게 되어서 어떻게든 살아남기 위해서 발버둥치다보니 어느새 입사하고 1년이라는 시간이 지나버렸네요

그동안 이런저런 일들을 하며 정신없이 시간을 보내다보니 정말 오랜만에 글을 쓰게 되는 것 같습니다!

앞으로는 이전처럼 FE 관련 글도 올라오겠지만, 현업에서 사용하고 있는 Kotlin과 Android에 대한 글들도 많이 올라가게 될 것 같습니다!

아무래도 Android 앱 개발팀에서 일을 하다보니, 기존과는 다르게 Kotlin과 Android에 대한 지식들이 필요해졌습니다. (심지어 현재 회사에 들어올 때도 FE로 면접을 보고 들어왔다보니 앱 개발 취준생이 가진 기본적인 면접 지식들도 부족합니다 ㅠㅠ)

게다가 이와 관련된 다양한 업무들을 처리하기 위해서는 그때그때마다 산발적으로 공부해야 했는데, 이 때 부분적으로 익혔던 내용들을 보다 깔끔하게 정리하며 복습하는 용도로 블로그를 운영해 보려고 합니다 ㅎㅎㅎ

그렇다면 오늘은, 안드로이드 개발에서 가장 핵심이 되는 Activity의 생명주기에 대해서 알아보도록 하겠습니다!

0. Activity가 뭘까

우리가 사용하는 애플리케이션은 각각의 화면들로 이루어져있습니다.

어떤 앱에서는 로그인 화면이 있을거고, 메인 화면이 있을거고, 결제 화면이 있을 수 있겠죠?!

이런 화면들 하나하나가 Activity라고 볼 수 있게 됩니다.

이러한 Activity는 UI를 작성하는 하나의 도화지라고 볼 수 있습니다.

Activity라는 도화지에 우리가 볼 수 있는 다양한 요소들이 들어가게 되고, 사용자와 상호작용할 수 있게 되는 것이죠.

그리고 각 도화지들이 서로 분리되어 있어서 언제든지 꺼내서 보거나 쓸 수 있는 것처럼,

Activity 역시 분리되어 있기 때문에 서로 다른 진입점을 가지고 있습니다.

메인 화면 Activity에서 어떤 버튼을 클릭해서 결제 화면 Activity로 넘어갈 수도 있고, 아예 다른 웹 환경에서 버튼을 클릭했을 때 바로 결제 화면 Activity로 넘어갈 수도 있습니다.

이처럼 각각의 Activity는 기본적으로 언제든지 분리해서 사용할 수 있는 독립적인 존재입니다.

출처:https://dinfree.com/lecture/android/android_3.1.html

아래 링크는 액티비티에 대해 잘 설명이 되어있는 Android Developers에 작성된 글입니다. (영어 주의!)

Activity | Android Developers

developer.android.com

Activity에 대해서 계속 공부하다보면 볼 수 있는 다른 개념들이 꽤 많이 존재합니다.

가장 대표적으로 Activity 사이에서 데이터를 전달하기 위한 용도로 사용되는 Intent,

복잡해지는 Activity를 보다 단순화하고 재사용이 용이하도록 모듈화 하는 용도로 사용되는 Fragment 정도가 있겠네요!

이런 요소들은 오늘의 주제에서 약간 벗어나기 때문에 해당 포스팅에서는 이정도로만 알아보고 넘어가겠습니다

1. Activity의 생명주기가 뭘까

이제 오늘 포스팅의 핵심 주제인 생명주기에 대해서 보다 자세히 알아보도록 하겠습니다.

아래 그림은 우리가 오늘 공부해야 할 내용의 알파이자 오메가, 사실상의 전부입니다.

안드로이드 개발을 하신다면 아래 Activity의 생명주기 그림,

조금 더 자세하게 말하면 생명주기함수를 기반으로 한 다이어그램은 확실하게 공부하고 넘어가셔야 될 겁니다.

(안그러면 저처럼 코드리뷰 받다가 호되게 혼날 수 있습니다 )

출처 : https://developer.android.com/reference/android/app/Activity

위 그림을 확실하게 파악했다면, 아래와 같이 Activity의 상태 중심으로 그려진 그림도 쉽게 이해할 수 있게 되겠죠?

이 포스팅을 모두 읽었을 때 쯤이라면 두 그림이 의미하는 바를 단번에 파악하실 수 있게 될 겁니다!

출처:https://developer.android.com/codelabs/basic-android-kotlin-compose-activity-lifecycle#2

안드로이드 환경에서는 각각의 Activity들이 위와 같은 생명주기를 예외 없이 따라가게 됩니다.

각 단계들에서 동작이 필요한 부분이 있다면 콜백 형태의 메서드(생명주기함수) 내부에 구현되어야 합니다.

간단한 예시를 들어보겠습니다.

유튜브에서 어떤 영상을 보고 있는데, 갑자기 친구한테 전화가 왔습니다.

이 때 유튜브 재생 화면 대신 전화 화면이 보이게 되겠죠?

그런데 전화를 하면서 동시에 영상이 재생이 되어버리면 전화 소리와 영상 소리가 섞여 난감한 상황이 발생할 수 있습니다.
이걸 막기 위해서는 전화가 왔을 때 잠시 영상을 멈추는 동작을 어느 순간에 해야겠다는 생각이 들죠?!!

바로 위와 같은 상황을 처리하기 위해서 특정 생명주기함수(onStop) 안에 원하는 동작(영상 멈추기)을 넣음으로써 우리가 원하는 대로 애플리케이션을 동작하게 만들 수 있습니다.

만약 Activity의 생명주기를 모르는 상태에서 위와 같은 상황을 마주한다면 생각대로 애플리케이션이 동작하게 만들기 위해서 한참을 삽질해야 할 지도 모릅니다.

이제 왜 생명주기를 꼭 알고 있어야 하는지 아시겠죠?!!

그렇다면 Activity의 탄생과 소멸까지의 과정중에 발생할 수 있는 5가지의 상태와 7가지의 생명주기함수에 대해서 더 자세하게 알아봅시다.

2. Activity의 5가지 상태

Activity에 생명주기가 있다는 말은, 특정한 상태에 따라 생성과 소멸을 하게 된다는 말과 동일합니다.

기본적으로 생성(Initialized)과 소멸(Destroyed)이라는 상태를 가지고 있고, 그 사이에 보여지는지 여부와 포커스 가능 여부에 따라 3가지의 상태(Created, Started, Resumed)가 추가됩니다.

상태 자체는 크게 어렵지 않죠?각각의 개념은 아래에서 추가로 설명하겠습니다.

아, 개념을 설명하기 전에 Android 내에서 Activity의 상태가 어떻게 사용되는지에 대해서 간단하게 설명하고 넘어가겠습니다. 어떤 방식으로 쓰이는 지는 알아야 하니까요!

기본적으로 Android의 운영체제는 Activity들을 Stack형태로 관리합니다.

그리고 이 Stack을 Back Stack이라고 부릅니다.

Stack의 개념에 대해서 잘 모르신다면.. 자료구조 카테고리의 stack 글을.. ㅋㅋㅋㅋ

[자료구조] 스택(stack), 큐(queue)

오늘은 자료구조의 가장 기본이 되는 스택과 큐에 대해서 알아보도록 하겠습니다! 목차 0. 스택 스택(Stack)이란 이름 그대로 순서대로 쌓인 무언가를 의미합니다. 우리가 뭘 쌓을 때 아래 요소를

ssocoit.tistory.com

아무튼!! Stack방식을 사용해서 Activity를 관리한다는 말은,

Activity가 새롭게 띄워질 때마다 Stack의 top 위치에 새로운 Activity가 올라가는 방식이라는 말과 동일합니다.

반대로 뒤로가기 버튼을 누르게 되면 Stack에서 pop되어서 이전 Activity가 Stack의 top에 위치하게 됩니다.

top 위치에 있는 Activity를 Foreground Activity라고 부르고, 포커스를 가질 수 있는 Resumed 상태가 됩니다.

나머지 Activity들은 화면에 보여지는지 여부에 따라 Created 상태이거나 Started 상태인 것이죠.

아래 사진을 보면 이해하기 쉽습니다.

출처:https://developer.android.com/guide/components/activities/tasks-and-back-stack?hl=ko

만약 동일한 Activity가 두번 뜨게 되면 어떻게 될까요?

기본적으로는 Stack이 새롭게 정렬되는 것이 아니라, Activity의 새로운 인스턴스가 생성되어서 Back Stack에 추가됩니다.

같은 Activity의 다른 인스턴스가 Back Stack에 들어가게 되는 것이고, 서로 다른 인스턴스인 만큼 UI도 각각 관리됩니다.

(엄밀히 말하면 Back Stack에는 Activity 자체가 들어가는게 아닌 Activity로부터 생성된 인스턴스가 들어가는 것이죠. 하지만 편의상 Activity로 말하는 경우가 많습니다 ^^;;)

그래서 아래 사진처럼 중복된 Activity가 2개 들어갈 수도 있습니다.

출처 : https://developer.android.com/guide/components/activities/tasks-and-back-stack?hl=ko

물론 Activity의 속성값이나 Intent 플래그를 통해서 하나의 Activity로부터 생성된 인스턴스는 반드시 하나만 존재하는 상태로 Back Stack에 들어가도록 조절하거나 할 수 있는데, 이 부분도 오늘 포스팅의 범위를 넘어가므로 관련 링크로 간단하게 넘어가도록 하겠습니다.

작업 및 백 스택 | Android 개발자 | Android Developers

작업은 사용자가 앱에서 어떤 작업을 하려고 할 때 상호작용하는 활동의 모음입니다. 이러한 활동은 스택(백 스택)에 각 활동이 열린 순서대로 정렬됩니다.

developer.android.com

Activity의 상태를 설명하려다가 경로이탈을 엄청나게 해버렸네요 ^^;;;

이왕 이렇게 된거 상태에 대해서 하나하나 알아보기 전에

실제로 잘 구현이 되어있는지 여부도 코드로 직접 보고 넘어갑시다!!

Androidx.lifecycle 패키지를 뜯어보면 아래와 같은 State 클래스를 볼 수 있습니다.

DESTROYED, INITIALIZED, CREATED, STARTED, RESUMED 이렇게 총 5개의 상태가 존재함을 알 수 있습니다.

~~사실 아래 사진만 봐도 쉽게 이해 가능할 수도 있습니다 ^^;;~~

2.0. Initialized

LifecycleOwner에 의해서 처음으로 Activity가 만들어졌을 때의 상태입니다.

메모리에 Actvitiy의 인스턴스가 올라가있는 최초의 상태이자, onCreate() 라는 생명주기함수가 동작하기 전의 상태입니다.

해당 상태는 처음 Activity가 생성되었을 때만 존재하는, 즉 굉장히 짧은 시간만 존재하는 상태라고 볼 수 있습니다.

2.1. Created

onCreate() 혹은 onStop() 이 동작한 직후의 상태입니다.

Activity에 UI가 그려져서 화면에 보여질 준비가 된 상태를 의미합니다.

준비만 됐다 뿐이지 화면에는 아직 보여지지 않는 상태입니다.

따라서 메모리가 꽉 찬 경우 Created된 Activity는 다른 상태들보다 메모리에서 우선 제거 대상이 됩니다.

게임 등 메모리를 많이 사용하는 작업을 하다가 다른 작업으로 넘어갔다가 다시 돌아가는 경우 게임과 같은 메모리를 많이 사용하는 작업이 강제로 재시작되는 경우가 있는데, 이 케이스가 바로 운영체제가 onStop() 생명주기함수에 의해 Created 상태가 된 Activity를 메모리에서 제거한 케이스입니다.

2.2. Started

onStart() 혹은 onRestart() 가 동작한 직후의 상태입니다.

또는 onPause()가 동작한 직후의 상태이기도 합니다.

사용자가 Activity를 볼 수는 있으나 포커스를 가지지 않아서 입력할 수 없는 상태를 의미합니다.

사용자가 Activity를 더이상 볼 수 없게 된 경우에도 반드시 Started 상태를 거쳐서 Created 상태로 가게 됩니다.

(onPause()와 onStop()이 모두 실행된다는 말과 동일합니다)

2.3. Resumed

onResume() 이 동작한 직후의 상태입니다.

사용자가 Activity와 상호작용할 수 있는 상태를 의미합니다.

즉 사용자가 볼 수 있으며, 포커스되어 있어서 입력을 받을 수 있는 상태를 말합니다.

2.4. Destroyed

onDestroy() 이 동작한 직후의 상태로, Activity가 종료된 경우를 의미합니다.

Created 상태의 Activity가 운영체제에 의해 메모리에서 제거된 경우 역시 Destroyed 상태가 된다고 볼 수 있습니다.

다시 사용하기 위해서는 재시작해야하는 것이죠.

이 상태 역시 매우 짧은 시간만 존재하는 상태입니다.

3. Activity의 생명주기함수

이번에는 생명주기함수(생명주기메서드)입니다.

Activity의 상태 변화에 따라 자동으로 실행되는 함수라고 보시면 됩니다.

이번에도 구현된 코드를 보고 개념으로 넘어가도록 하죠.

아래 사진은 androidx.lifecycle의 Event 클래스를 가져온 사진입니다.

아까 분명히 onRestart()라는 생명주기함수가 있었는데..?

여기서는 onRestart가 없어서 의아할 수 있지만!!

Activity 클래스 내부 구현 코드에는 아래와 같은 함수들이 정의되어있습니다.

여기에는 onRestart가 존재하죠.

이렇게 나눠진 이유는 아래에서 더 자세하게 알아보겠습니다!

3.0. onCreate()

Activity가 생성되었을 때 가장 먼저 호출되는 함수입니다.

onDestroy()와 함께 전체 생명주기에서 단 한번만 수행되는 함수입니다.

보통은 Layout을 정의하거나, View를 생성하고 DataBinding하는 부분들이 여기에 들어가게 됩니다.

매개변수에 savedInstanceState가 들어가는데, 만약 상태가 보관되어 있는 경우 이 번들 객체를 가져와서 사용할 수도 있습니다.

이 생명주기함수가 동작한 이후에는 반드시 onStart()가 따라나옵니다.

3.1. onStart()

Activity가 사용자에게 보여지기 직전, Started 상태로 가기 직전에 호출됩니다.

만약 바로 Foreground로 표시되어서 포커스를 가져가는 경우에는 onResume() 생명주기함수가 뒤따라 동작하게 됩니다.혹은 모종의 이유로 사용자에게 더이상 보여지지 않는 경우 onStop() 생명주기함수가 뒤따라 동작하게 됩니다.

3.2. onRestart()

Activity가 사용자에게 보여지기 직전, Started 상태로 가기 직전에 호출되는 것은 onStart()와 동일합니다.

하지만 onRestart()는 최초에 onCreate()에 뒤따라서 Started 상태로 가는 경우에는 호출되지 않고,

onStop()이 된 이후에 새롭게 Started 상태로 가는 경우에만 동작합니다.

그리고 onStart()보다 항상 먼저 동작하고, 함께 동작합니다.

(onRestart만 동작되는 경우는 없습니다!)

아래 onRestart()의 주석을 보면 확인할 수 있죠.

(It will be followed by onStart~)

onStop()의 구현을 봐도 다시 Activity가 Started 상태로 돌아가는 경우 onStart()가 아닌 onRestart()를 부른다는 것을 확인할 수 있습니다.

어짜피 onRestart()가 동작하는 것은 항상 onStart()와 함께하기 때문에,

onRestart()의 동작은 ON_START라는 이벤트로 함께 처리해도 무방하다고 볼수 있어서 위에서 확인한 Event 클래스에서는 ON_RESTART라는 이벤트를 만들지 않았다고 추측할 수 있습니다.

3.3. onResume()

Activity가 사용자의 포커스를 받을 수 있는 Resumed 상태가 되기 직전에 호출됩니다.

Resumed 상태에서 이어서 동작할 수 있는 생명주기함수는 onPause() 뿐입니다.

3.4. onPause()

다른 Activity가 포커스를 받을 수 있는 Resumed 상태가 되었을 때 호출됩니다.

만약 다른 Activity에 의해서 화면에 보이지 않는 상태가 되었을 경우 onStop()이 이어서 호출됩니다.

물론 이 상태에서 다시 Activity가 활성화되어 포커스를 받을 수 있게 되는 경우 onResume()이 호출됩니다.

3.5. onStop()

Activity가 사용자에게 더이상 보이지 않게 되는 경우 호출됩니다.

이렇게 Created 상태로 되돌아간 Activity가 사용자에게 화면을 보여주기 위해 Started 상태, 혹은 Resumed 상태로 가는 경우 onRestart() -> onStart() -> *onResumed() 순서대로 생명주기함수가 실행됩니다.

(onResumed()는 Resumed 상태가 되는 경우에만 실행됩니다!)

아니면 앗싸리 onDestroy()로 Activity가 삭제될 수도 있겠죠?!

3.6. onDestroy()

Activity가 메모리에서 사라지기 직전에 호출됩니다.

모종의 이유로 Activity가 finish() 처리 되었거나, 운영체제에 의해 강제로 메모리에서 할당해제되었을 경우 동작합니다.

(이 두 케이스의 경우 isFinishing() 메서드를 통해서 구분할 수 있다고 합니다)

Activity | Android Developers

developer.android.com

그리고 onCreate()와 함께 전체 생명주기에서 단 한번만 수행되는 함수입니다.

4. 정리

지금까지 Activity의 생명주기에 대해서 알아보았습니다.

위에서 이야기했듯이, 생명주기를 모르는 상태에서 개발을 한다면 애플리케이션의 정상 동작을 보증하기 어렵고, 추후에 문제가 발생한다고 했을 때 문제 파악에 있어서 어려운 부분들이 발생할 여지가 굉장히 많습니다.

그러므로 조금이라도 헷갈리는 부분이 있다면 확실하게 알고 넘어가는 것이 훌륭한 애플리케이션을 만드는 데에 있어서 튼튼한 기반이 될 것이라고 생각합니다.

(괜히 빈출 면접 질문이 아니겠죠? )

추가로 코드를 작성하면서 직접 Lifecycle에 대해서 이해해보고 싶은 분들이 있다면 아래 코드랩을 진행하시면 도움이 되실겁니다 ㅎㅎ

Android 기초 02.2: Activity 수명 주기 및 상태 | Android Developers

이 Codelab에서는 TwoActivities 앱에 로깅 문을 추가하고 활동 수명 주기 변경사항을 확인합니다. 이러한 변경사항을 사용하여 이러한 조건에서 사용자 입력을 처리하는 방법을 살펴봅니다.

developer.android.com

5. 참고자료

Activity | Android Developers

developer.android.com

안드로이드 기초

안드로이드 액티비티의 라이프사이클을 알아보고 시스템에서 액티비티가 관리되는 방식과 라이프사이클 변화에 따라 개발자가 처리해 주어야 할 작업들을 배웁니다.

dinfree.com

작업 및 백 스택 | Android 개발자 | Android Developers

developer.android.com

활동 수명 주기 단계 | Android Developers

이 Codelab에서는 활동 수명 주기와 로깅을 알아봅니다.

developer.android.com

[CSS] 모르면 평생 안쓸 미치도록 유용한 CSS 형제 결합자

Ssoco — Wed, 15 Feb 2023 00:57:40 +0900

HTML과 CSS를 이용해서 연속된 요소들을 순서대로 나열할 때 정해진 수치만큼 padding이나 margin을 주는 경우가 아주아주 빈번하게 발생합니다.

이 과정에서 보통 첫 요소에는 padding이나 margin이 필요하지 않을 수 있는데, 이런 경우 전체에 padding 혹은 margin을 먹이고 덮어 씌우는 방법을 많이 사용하곤 합니다.

하지만 우리가 별로 신경써서 공부하지 않았던 요소를 사용한다면 이걸 훨씬 더 편하게, 그리고 효율적으로 구현할 수 있습니다.

바로 오늘 설명할 형제 결합자를 사용하는 방법입니다.

0. 결합자가 뭐지?

결합자가 뭔지 이해하기 전에, 선택자에 대해서 알 필요가 있습니다.

선택자는 CSS 규칙을 적용할 요소를 정의하는 데에 쓰이는 요소입니다.

조금 더 자세하게 말하면, CSS 속성값을 적용하기 위해 어떤 HTML 요소를 선택해야 할 지 브라우저에게 알려주는 패턴을 의미합니다.

본 글은 선택자의 기초부터 설명하기 위한 글은 아니기 때문에 어느 정도는 이미 알고 있고 사용했다는 가정하에 설명합니다.

보통 *를 사용해서 모든 요소를 선택하거나, class(".")나 id("#")를 통해 선택하곤 합니다.

/* 전체 선택자 */
* {
  color: brown;
}

/* 클래스 선택자 */
.ssoco_class {
  color: red;
}

/* 아이디 선택자 */
#ssoco_id {
  color: blue;
}

몇몇 CSS에 조예가 깊으신 분들은 가상 클래스(":"), 혹은 가상 요소("::")를 사용하기도 합니다.

특정 조건에 스타일을 입힐 때 사용하는 가상 클래스의 대표적인 예시로는 :hover,

실제로 존재하지 않는 가상의 요소를 만들 때 사용하는 가상 요소의 대표적인 예시로는 ::after가 있습니다.

여기서 조금 더 나아가면 결합자라는 것을 쓸 수 있는데, 여러 선택자들을 결합하여 사용할 수 있는 방법을 말합니다.

대표적으로 자손 결합자 (" "), 자식 결합자 ("<")를 많이 사용합니다.

자손 결합자는 첫 번째 요소의 자손인 요소를 모두 선택합니다.

자식 결합자는 첫 번째 요소의 바로 아래인 요소를 선택합니다.

/* 자손 결합자 */
.ssoco_class .ssoco_inside_class {
  color: green;
}

/* 자식 결합자 */
.ssoco_class > span {
  color: yellow;
}

더 자세한 내용은 MDN 문서를 참조하시길 바랍니다!

CSS 선택자 - Web 개발 학습하기 | MDN

CSS 에서, 선택자는 스타일을 지정할 웹 페이지의 HTML 요소를 대상으로 하는 데 사용됩니다. 사용 가능한 다양한 CSS 선택자가 있으며, 스타일을 지정할 요소를 선택할 때 세밀한 정밀도를 허용합

developer.mozilla.org

위 문서를 참고하면, 우리가 안쓴다고 생각하고 간단하게 존재 여부만 파악하고 넘어가기 쉬운 형제 결합자들이 맨 마지막 쯤에 등장합니다.

이것들이 뭔지에 대해서 간단하게 알아보고 본론으로 넘어가겠습니다.

0.0. 인접 형제 결합자

인접 형제 결합자("+")는 앞에서 지정한 요소의 바로 다음에 위치하는 형제 요소만 선택하는 결합자입니다.

<div>
  <h1 class="ssoco_class">ㅎㅇㅎㅇ</h1>
  <h2 class="next">hihi</h2>
  <h2 class="next">하이하이</h2>
</div>

.ssoco_class + .next {
  color: red;
}

0.1. 일반 형제 결합자

일반 형제 결합자("~")는 서로 형제인 요소 중에서 앞 요소 뒤에 뒤 요소가 존재하는 경우 전부 선택하는 결합자입니다.

.ssoco_class ~ .next {
  color: red;
}

1. 인생은 실전

이제 형제 결합자에 대해서 알아봤으니, 실제로 어떻게 유용하게 써먹는 지에 대해서 알아보도록 하겠습니다.

어떤 하나의 컨테이너 안에 요소들이 순차적으로 여러 개 나열되는 경우가 굉장히 많겠죠?

이런 경우 나열은 하되, 첫 번째 요소에는 마진과 같은 효과를 넣지 않고 싶은 경우가 발생할 수 있습니다.

이 포스팅의 도입부에서 이야기한 바로 그런 상황인 것이죠.

<div class="container">
  <span class="box"></span>
  <span class="box"></span>
  <span class="box"></span>
  <span class="box"></span>
</div>

위 HTML 코드를 CSS로 사진처럼 만드려면 어떻게 할 수 있을까요?

물론 HTML코드를 수정할 수도 있습니다.

(inline-block으로 인해 발생하는 공백은 해당 포스팅의 내용과 관련이 없으니 무시하고 넘어가겠습니다!)

<div class="container">
  <span class="box first"></span>
  <span class="box"></span>
  <span class="box"></span>
  <span class="box"></span>
</div>

.container {
  background-color: salmon;
  height: 150px;
  margin-top: 50px;
}

.box {
  display: inline-block;
  width: 150px;
  height: 150px;
  background-color: brown;
  margin-left: 30px;
}

.box.first {
  margin-left: 0;
}

하지만 코드의 크기가 커지고 이와 비슷한 로직이 반복되면 매번 HTML 코드를 새롭게 수정해야 할 것이기에 굉장히 비효율적일 것입니다.

또는 HTML을 변경시키면 안되는 상황이라면 사용할 수 없을 것입니다.

한 단계 더 나아가서 가상 클래스를 사용한다면 아래와 같은 코드를 만들 수 있습니다.

.container {
  background-color: salmon;
  height: 150px;
  margin-top: 50px;
}

.box {
  display: inline-block;
  width: 150px;
  height: 150px;
  background-color: brown;
  margin-left: 30px;
}

.box:first-child {
  margin-left: 0;
}

이렇게 전체에 마진을 먹이고 first-child에만 마진을 0으로 덮어씌우는 방법도 나쁘지 않지만, 아예 처음부터 첫 요소를 제외한 나머지 요소에 편하게 CSS 규칙을 적용할 수 있는 방법은 없을까요?

이럴 때 형제 결합자, 그 중에서도 인접 형제 결합자를 사용할 수 있습니다.

아래와 같이 .box + .box 형태를 사용하면 box 클래스 뒤에 box 클래스가 있는 경우에 CSS 규칙이 적용되기에 보다 명확하고 깔끔하게 CSS를 적용할 수 있습니다.

.container {
  background-color: salmon;
  height: 150px;
  margin-top: 50px;
}

.box {
  display: inline-block;
  width: 150px;
  height: 150px;
  background-color: brown;
}

/* 인접 형제 결합자 사용 */
.box + .box {
  margin-left: 30px;
}

해당 케이스에서 일반 형제 결합자를 사용할 수도 있지만, 매번 뒤에 있는 모든 box 클래스 요소들을 중복해서 체크하는 불필요한 과정이 발생하기 때문에 일반적으로 인접 형제 결합자를 사용합니다.

이제는 냅다 덮어씌우지 말고 보다 스마트하게 반복되는 CSS 규칙들을 처리해봅시다!!

2. 참고자료

Adjacent sibling combinator - CSS: Cascading Style Sheets | MDN

The adjacent sibling combinator (+) separates two selectors and matches the second element only if it immediately follows the first element, and both are children of the same parent element.

developer.mozilla.org

The Adjacent-Sibling Selector

The Adjacent-Sibling Selector Web Review July 2000 As previous articles in this series have shown, CSS has some interesting new selectors. Between the universal selector and the child selector, it's possible to construct selectors which would be next to im

meyerweb.com

[Git] 이게 머지? Merge를 하는 세 가지 방식!

Ssoco — Thu, 5 Jan 2023 03:13:29 +0900

이번 소재거리는 친구들과 함께 Git에 대한 면접 질문으로 뭐가 나올 수 있을까에 대해서 고민을 하다가 우연히 등장했습니다.

~~딱 봐도 드립치기 좋아보이네요~~

협업할 때 대부분의 케이스에서 기본 Merge만 사용해왔던 저는

기본 Merge로도 충분한데, 다른 건 나중에 공부하자~

라고 안일하게 생각했었기에 이 질문에 대해서 제대로 된 답변을 할 수 없었죠.

그래서 이번 기회에 자세하게 알아보았습니다!

0. 머지에도 전략이 있다?

GitHub에서 Pull Request를 날릴 때 유심히 살펴봤다면, 아래와 같은 Merge 전략을 확인하실 수 있었을 것입니다.

~~저는 알았음에도 바꾸지 않았지만~~

아래 사진으로 확인할 수 있듯이, 머지 전략에는 대표적으로 일반적인 Merge commit을 남기는 방법, Squash and merge, Rebase and merge 세 가지 방법이 있습니다.

각 전략들이 어떤 기능을 하고 어떻게 동작하는 지를 알아야 해당 기능을 잘 쓸 수 있겠죠?

1. 전략이 왜 필요한건데?

여기서 잠깐, 대표적인 세 가지 전략을 살펴보기 전에 왜 저런 다양한 전략들을 사용해야 하는지부터 알아봅시다.

Merge가 뭔지 제대로 이해하기 위해서는 Commit에 대한 이해가 필요합니다.

Commit이란 파일이나 폴더의 추가, 변경 사항을 저장소에 기록하는 행위입니다.

그리고 이러한 Commit들이 쌓여서 커밋 히스토리를 만들게 되는데, 이 커밋 히스토리를 통해 저장소 내에서 도대체 무슨 일이 벌어졌는지에 대해서 알 수 있게 됩니다.

최근 진행한 사이드프로젝트인 십이장기의 깃 그래프

만약 개발을 하다가 휴가를 떠났습니다.

그리고 오랜만에 돌아왔더니 내가 그동안 뭘 했는지 기억이 안날 수 있겠죠?

이럴 때 커밋 내역을 보고 이런 일들을 했구나 쉽게 파악할 수 있게 됩니다.

또한 협업할 때 다른 사람들이 남겨놓은 코드의 변경사항을 쉽게 파악하는 데에도 쓰입니다.

시간 순서대로 나와있고, 해당 커밋에서 변경된 내용만 쉽게 파악할 수 있기 때문에 잘 이해가 안가거나 문제가 발생하더라도 해당 부분만 찾아서 확인할 수 있다는 어마어마한 효율성을 보여줄 수 있습니다.

하지만 이렇게 유용하게 쓸 수 있는 커밋 히스토리의 커밋 메시지를 대충 쓴다면 어떻게 될까요?

커밋 히스토리를 열심히 쌓아봐야 유지보수에도 아무 도움이 안되고 내가 무슨 내용을 했는지도 모르게 됩니다.

이러면 커밋 히스토리를 쌓을 필요가 전혀 없어지게 되는 것이죠.

그렇기 때문에 우리는 의미있는 단위의 커밋을 하고 의미 있는 커밋 메시지를 작성해야 합니다.

이렇게 하시면 안돼요!

약간 이야기가 샜는데, 이렇게 중요한 커밋메시지를 잘 작성했음에도 브랜치가 너무 중구난방이라 알아보기 어려운 경우가 있을 수 있습니다.

아래 예시는 제가 Sooltreaming 개발을 하면서 만들어냈던 지하철 노선도(?) 입니다.

해당 시점에 개발을 할 때는 기본 Merge 전략만 사용했기 때문에 저런 그래프가 등장하게 되었습니다.

아래 화려한 깃 그래프가 알아보기 엄청나게 어려운건 아니지만 조금 더 깔끔하게 정리할 수도 있었을 텐데 하는 아쉬움도 약간 드네요!

으악

이제 이것들을 가독성 있게 만들기 위한 용도로 만들어진 머지 전략에 대해서 배워봅시다!

2. 세 가지 머지 전략

2.0. Create a merge commit

기본 Merge라고도 불리는 Create a merge commit의 경우 각각의 브랜치에 남은 커밋을 히스토리에 그대로 남깁니다.

그래서 어떤 브랜치에서 어떻게 만들어져서 이렇게 머지가 되었구나를 아주아주아주 상세하게 파악할 수 있죠.

사용법은 아주 단순합니다.

git merge {머지할 브랜치}

출처:https://meetup.nhncloud.com/posts/122

다만 해당 방식의 경우 지하철 노선도마냥 굉장히 자세하게 히스토리가 남아서 다소 보기 어려울 수 있다는 단점이 있습니다.

별다른 HEAD 조작을 하지 않았다면 develop 혹은 main 브랜치가 맨 왼쪽에 위치해서 어찌어찌 따라갈 수 있을 지도 모르지만, 만약 HEAD가 밀려버리는 상황이 발생하게 되면 그래프의 순서가 꼬여버릴 수도 있게 됩니다.

그러면 이제 develop 혹은 main 브랜치가 어디서부터 어디까지인지 눈알 빠지게 찾아버려야 하는 상황이 발생할 수도 있습니다...!

사실 얘도 출발은 하나였지만..

2.1. Squash and merge

Squash and merge는 개발용 브랜치에 있던 내용들을 하나로 합쳐서 중앙 브랜치에 하나의 커밋으로 저장하는 전략입니다.

새롭게 발생하는 머지 커밋은 개발용 브랜치에서의 변경사항들을 하나도 뭉쳐놓은 커밋이 되는 것이죠.

기존 변경사항들이 어떻게 변했는가보다 머지가 되었다에 좀 더 집중한 전략이라고 보시면 되겠습니다.

Create a merge commit에 비해서 남아있는 정보량이 비교적 적기 때문에, 개발용 브랜치에서 언제 어떤 코드를 바꿨는지에 대한 정보를 잃을 수 있다는 단점도 가지고 있습니다.

(필요 없는 간단한 console.log 수정이나 버그 수정같은 것들을 뭉뚱그려서 합치는 데에 쓰일 수 있겠죠?)

출처:https://meetup.nhncloud.com/posts/122

Squash and merge를 아까 만든 커밋메시지 테스트용 브랜치에 적용해보도록 하겠습니다.

~~커밋 메시지는 따라하면 안됩니다~~

이 상태에서 testBranch에서의 변경사항 3개를 하나로 뭉뚱그려서 처리할 수 있습니다.

git merge --squash {머지할 브랜치}

명령어를 쳤더니 staging area에 변경사항이 올라갔습니다. (아직 commit이 안된 상태)

이제 저장소에 새롭게 뭉뚱그린 커밋을 등록하기 위해 git commit -m "커밋메시지"만 하면 되겠네요!

깔끔하게 하나로 처리되었습니다!

Squash and merge는 이게 끝입니다. 간단하죠?!

2.2. Rebase and merge

Rebase and merge는 말 그대로 이미 존재하는 Rebase라는 기능을 이용해서 브랜치를 머지하는 것입니다.

히스토리의 Base를 직접 옮겨서 처리하는 방식이기 때문에 개발용 브랜치에서 변경한 내용을 중앙 브랜치에서 변경한 것처럼 바꿔버릴 수 있습니다.

위에서 본 Create a merge commit에서 만들어진 지하철을 한 줄로 예쁘게 만들 수 있다는 것이죠!

이 방식도 단점이 있는데, 바로 기본적으로 Merge commit이 없기 때문에 어느 시점에 Merge가 되었는지 나중에 판단하기 어렵다는 것입니다.

이걸 보완하기 위해서 어디서 Merge가 되었는지 태그를 남겨놓기도 합니다.

출처:https://meetup.nhncloud.com/posts/122

Rebase and merge도 실제로 테스트 해 보죠!

다시 초기 상태로 돌아왔고, testBranch2에 커밋을 더 쌓아보았습니다.

testBranch의 base를 testBranch2로 바꿔버렸습니다.

그러면 아래와 같이 한줄로 쭉 이어지게 됩니다.

(base가 testBranch2와 같기 때문에 2줄일 필요가 없어진 것이죠!)

이제 testBranch2로 넘어가서 testBranch와 merge를 하게 되면?

단순히 해당 Branch의 HEAD의 위치만 바꾸는 Fast-forward가 수행되어 머지가 마무리됩니다.

한 줄로 쭉 이어졌지만, 머지했다는 커밋이 없죠?

아주아주아주 깔끔해졌습니다!

실제 개발 상황에서 머지한 위치를 기록으로 남겨야 하는 상황이라면,

git rebase -i HEAD~<n>

명령어를 통해 rebase의 기능을 활용해서 커밋 메시지를 변경시키는 방법을 사용하셔도 좋습니다.

(위 코드는 HEAD로부터 n번째 커밋까지 불러와서 대화형 명령(-i)을 통해 커밋을 이리저리 바꾸겠다는 말입니다)

3. 3-way merge와 Fast-forward merge

위에서 세 가지 머지 전략에 대해서 살펴봤는데, 조금 더 깊게 생각했다면 병합을 도대체 어떻게 처리할까? 라는 고민까지 충분히 하셨을 것이라고 생각합니다.

그래서 위에서 살짝 언급한 Fast-forward merge와 함께 브랜치를 합치는 로직인 3-way merge를 간단하게 알아보고 넘어가려고 합니다!

3.0. Fast-forward merge

위에서 간단하게 언급했지만, 서로 다른 상태를 병합하는 것이 아니라 단순히 HEAD만 이동시키면 Merge가 처리될 수 있는 환경에서는 Fast-forward merge가 수행됩니다.

아래 상황에서는 단순히 testBranch2의 HEAD를 testBranch로 옮기기만 하면 되는 것이죠.

위에서 사용한 사진 2개를 모아 보면 간단히 파악할 수 있습니다.

Fast-forward와 관련해서 특별하게 처리할 수 있는 명령어가 두 가지 있습니다.

병합 대상 브랜치와 현재 브랜치와의 관계가 Fast-forward라고 하더라도 머지 커밋을 남기고 싶다면 아래 명령어를 사용합니다. (Rebase and merge를 할 때 머지했다는 커밋 메시지를 남기고 싶다면 이걸 쓰면 됩니다!)

git merge --no-ff {머지할 브랜치}

반대로 Fast-forward가 아니면 머지를 하지 않고 싶다면 아래 명령어를 사용하면 됩니다.

git merge --ff-only {머지할 브랜치}

3.1. 3-way merge

하지만 세상은 이렇게 단순하지 않습니다.

매우 높은 확률로 두 명의 개발자는 서로 다른 내용을 바꿨을 것이고, 지금처럼 HEAD만 옮겨서는 제대로 머지가 되지 않는 상황이 발생하게 됩니다.

이 때 사용하는 비교 방식이 바로 3-way merge입니다.

만약 1번 브랜치와 2번 브랜치가 병합을 한다고 하면, 총 세 가지 커밋을 서로 비교하게 됩니다.

1번 브랜치 커밋
2번 브랜치 커밋
1번 브랜치와 2번 브랜치의 공통 조상 커밋

만약 단순하게 1번 브랜치와 2번 브랜치의 현재 상태만 비교(2-way merge)한다면, 어떤 요소가 어떻게 변했는 지, 혹은 두 브랜치가 충돌해서 병합할 수 없는 상태인 지 알 방법이 없습니다.

b와 b'를 비교했을 때 b가 원본임을 증명할 수 있는 방법이 없는 것이죠.

이걸 증명하기 위해서 공통 조상을 가져와보겠습니다.

이제 공통 조상을 기준으로 변동사항을 파악한다면 충돌 여부를 명확하게 알 수 있게 됩니다.

a의 경우 변동사항이 없었으니 그대로 a가 됩니다.

그리고 b의 경우 원본에서 변경된 내용이 2번 브랜치한테만 있으니 2번 브랜치의 b'가 결과값이 됩니다.

하지만 c의 경우 두 브랜치에서 모두 변경되었기 때문에 결과를 c'로 해야할 지, c''로 해야할 지 알 수 없기 때문에 충돌이 난다는 것을 확실하게 알 수 있는 것이죠.

이렇게 보다 명확하게 두 브랜치의 충돌 여부를 파악하기 위해서 세 개의 커밋을 비교해서 머지를 진행한다는 뜻을 가진 용어가 바로 3-way merge입니다.

4. 참고자료

[Git] Merge(3-way merge) 이해하기 - SW Developer

다른 형상 관리툴들과는 달리 git은 branch를 생성할 때 파일을 복사하는 것이 아니라 파일의 스냅샷만 가지고 생성하기 때문에 자원의 부담없이 branch를 만들어 사용할 수 있다. 이러한 장점 때문

wonyong-jang.github.io

커밋 히스토리를 이쁘게 단장하자

이번 포스팅에서는 Git의 머지 전략 중 대표적인 3가지인 , , 의 차이에 대해서 한번 이야기해보려고 한다. 이 3가지 머지 전략 모두 브랜치를 머지한다는 목적은 같지만, 어떤 방식을 선택하냐에

evan-moon.github.io

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기 : NHN Cloud Meetup

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기

meetup.nhncloud.com

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)

회사에서 Git을 사용해서 형상 관리를 하고 있다. 그 동안 내가 개인 repository branch에 commit, push등을 해본 적은 많지만 다른 사람과 협업을 하면서 branch를 생성하고 master에 merge를 해본 적은 없어서

im-developer.tistory.com

Git Merge에서 Fast Forward 관계 이해하기 - Jay's Blog

Git Merge에서 항상 헷갈리는 Fast Forward 관계에 대해 정리해보았습니다. 들어가며 Git을 사용하다보면 브랜치를 분기하여 다시 병합하는 일이 빈번하게 일어납니다. 최근 Git 커밋 히스토리 관리

otzslayer.github.io

[뻘] CI/CD 입문! 자율 프로젝트 꽃바다 회고

Ssoco — Tue, 13 Dec 2022 01:12:35 +0900

이번 자율 프로젝트에서는 이미 알고있던 팀원들과 함께 뭉쳤습니다!

2022년, 1년 간의 추억을 되돌아보며 실물 롤링페이퍼 및 꽃배달 서비스를 기획하고 개발하게 되었습니다.

(현재는 프로젝트 기간이 종료되어 공식적으로 제공되는 AWS 서버가 회수되었지만, 비공식적으로 팀원들끼리 AWS 서버를 한대 구매해서 이것저것 시도해보고 있습니다 ㅎㅎ)

이번 프로젝트에서는 어떤 걸 했고 무엇을 배웠으며 어떤 부분에 대해 보충해야 할 지에 대해서 간단하게 정리해보았습니다.

0. 팀 컬쳐

이번에도 역시 Notion을 주로 사용했습니다.

기록해야 하는 것들이 있으면 Notion에 전부 기록했고, 기타 알림이나 실시간으로 전달해야 하는 부분들은 Mattermost를 연결해서 사용하거나 카톡방, 혹은 Jira를 사용했습니다.

0.0. 팀 규칙

이전 프로젝트에서 사용했던 팀 규칙을 현재 프로젝트에 맞게 살짝 수정한 형태로 사용했습니다.

특별히 다른 부분이 있다면 이번에는 MR(Merge Request)를 날리고 나서 2명 이상의 동의가 있을 때만 적용하도록 자체적인 규칙을 설정해서 끝까지 지켰습니다.

(GitLab 무료버전은 몇 명 이상이 Approved를 해야 MR 적용이 되는 기능이 유료.. 입니다 ㅠ)

0.1. 갤러리

이전 2번의 프로젝트에서도 그랬듯이 이번에도 갤러리를 운영했습니다.

특히 이번 프로젝트는 대부분이 오프라인으로 진행되었기에 사진 관리가 다소 어려운 부분이 있었으나, 제가 하겠다고 선언한 이상 시간을 투자해서 철저하게 관리했습니다.

0.2. 회의록

스크럼때 이야기를 나누기에는 시간이 부족하다고 느낀 경우 아예 시간을 길게 잡고 회의를 진행했습니다.

회의를 진행한 내용은 서기 혹은 대체자가 직접 Notion에 정리해두었습니다.

0.3. 고민한 내용들 게시판

이전 프로젝트에서의 삽질 게시판이 고민한 내용들 게시판으로 이름이 변경되었습니다.

이전보다 조금더 자유로운 형식으로 자신이 고민한 내용들을 정리해두었습니다.

0.4. 개선사항

개발 초반부에 MR의 단위를 상세하게 나누지 않아서 누구는 양이 엄청 많아지고 누구는 양이 적은 등 차이가 나는 문제가 발생했습니다.

Git 담당자로서 Commit 컨벤션이나 폴더구조와 같은 것들 뿐만 아니라 MR도 많이 신경을 썼어야 했는데 그런 부분에 있어서 조금 아쉬웠기에 다음번에는 MR컨벤션도 자세하게 나눠서 처리해볼 생각입니다.

또한 이전 ImTeller 프로젝트에서 진행했던 다른 팀과의 코드리뷰 혹은 개인 공부 내용 발표와 같은 것들을 진행하지 못한 부분이 다소 아쉬웠습니다.

이 부분은 팀원들이 여유있게 개발을 진행하고 싶다는 의견을 받아서 없앤 부분이었기 때문에 개선을 해야할 내용이라고 보기에는 어려울 수 있지만, 개인적으로 다소 아쉬웠던 부분중에 하나입니다.

제 나름대로 지친 부분도 있겠지만, 꾸준하게 공부하는 것이 중요하기에 주기적으로 기술블로그를 작성함으로써 이러한 기술 부채, 혹은 기술 습득 욕망을 해결해나갈 예정입니다.

1. 기획단계

구현 내용이 양 보다는 새로운 기술의 시도쪽에 가까웠기 때문에 생각보다 빠르게 기획 내용이 정리되었습니다.

덕분에 개발 시간을 넉넉하게 확보할 수 있었고, 예상보다는 조금 늦었지만 정해진 기한 안에 서비스 배포와 이벤트 진행까지 마무리할 수 있었습니다.

1.0. 디자인

이번에도 디자인 협업에 Figma가 사용되었습니다.

이것저것 기능들이 추가되면서 지저분하게 늘어난 감이 있지만, 피그마로 작성한 내용들은 모두 실제로 구현했습니다.

1.1. ERD

ERDCloud를 사용했습니다.

처음에는 롤링페이퍼가 주 서비스 내용이었기 때문에 기본적인 CRUD를 기반으로 몇 가지 테이블만 추가하면 될 거라고 생각했는데, 꽃과 꽃다발, 배송, 신고 등등 다양한 기능들이 추가되면서 연관관계가 점차 증가하여 다소 복잡한 ERD가 완성되었습니다.

카카오페이를 이용한 가상결제시스템을 도입할 때 최대한 컬럼의 수를 줄이고자 노력해서 배송 테이블에 들어가는 내용이 비교적 적은 편이었지만, 실제로 결제 시스템과 배송 시스템을 구현한다고 하면 이것보다 훨씬 더 많은 컬럼이 필요했을 것 같습니다. (예를 들자면 할인률과 같은 컬럼들이 존재할 수 있겠죠?!)

1.2. API 문서

API와 관련된 내용 역시 Notion에 자세히 기록하려고 노력했습니다.

기능별로 API의 첫 주소를 나누고, 각 주소에 맞는 API의 URI와 설명, 그리고 현재 작업 진행 정도를 나타내는 페이지를 만들어서 관리했습니다.

해당 페이지로 개발을 진행하던 중 롤링페이퍼와 메시지간의 역할이 비슷한 부분 때문에 어디에 특정 API를 넣어야 할까에 대해 많은 고민을 했던 기억이 나네요 ㅎㅎ

(처음에는 롤링페이퍼 조회 안에 모든 메시지를 가져오는 방식을 사용하려고 했으나, 최종적으로는 롤링페이퍼 조회와 메시지 조회를 각각 나누어서 관리했습니다!)

1.3. Git

이전 프로젝트의 GitHub-Flow 전략을 버리고 다시 Git-Flow로 돌아왔습니다.

실제 큰 프로젝트에서 진행하는 것과 비슷하게 Git 전략을 사용해보고 싶다는 팀원들의 의견을 받아들였습니다.

그 외에도 Commit 컨벤션의 경우 Gitmoji를 사용했습니다.

그리고 편의상 커밋 메시지는 한글로 작성하였습니다.

gitmoji

:truck: Move or rename resources (e.g.: files, paths, routes).

gitmoji.dev

2. 개발단계

2.0. 기술 스택

세 번의 프로젝트를 진행하면서, 매번 같은 기술 스택만 사용하는 것이 굉장히 마음에 걸렸습니다.

그렇다고 해서 프론트엔드에 익숙하지 않은 팀원들이 있는데 새로운 기술 스택을 마구 도입하는 것 역시 이기적인 선택일 수 있겠다는 생각을 했습니다.

그래서 팀원들과 많은 이야기를 나누었고, 문제가 발생한다고 해도 제가 커버해낼 수 있다고 생각한 한도 내에서 새로운 기술 스택을 선정하였습니다.

대표적으로 새롭게 도입하게 된 기술 스택은 바로 Recoil이었습니다.

이전 프로젝트에서 여러 차례 사용해봤고, 익숙한 Redux와 Redux-Toolkit을 버리고 Recoil을 선택한 이유는 Redux 계열 상태관리 라이브러리에 비해서 간단하게 쓸 수 있고, React와 동일하게 Meta에서 만든 상태관리 라이브러리였기 때문입니다.

언젠가 한 번 사용해보고 싶었던 기술 스택이었는데, 시간적 여유가 있고 리액트에 익숙한 팀원들이 많은 이번 기회에 사용해보자는 마음을 먹었고 모두가 동의해줘서 사용하게 되었습니다.

그리고 드디어 CRA를 버리고 Vite를 사용하였습니다.

로컬에서 프론트엔드 서버를 켜면 웹팩에 의해 빌드하는데 걸리는 시간이 오래 걸려 개선하고 싶다는 생각을 한 것이 한두번이 아닙니다.

이걸 해결하기 위해서는 모듈 번들러 차원의 개선이 필요했는데, Webpack이 아닌 ESBuild를 사용하는 Vite를 사용하면 속도면에서 엄청난 개선을 얻을 수 있다는 것을 이미 이전에 Vite를 사용해봤기 때문에 알고 있었습니다. 그래서 Vite를 사용함으로써 겪어야 하는 다양한 불편함 (정보의 부족, 특정 라이브러리의 미지원)을 감수하고 도입하게 되었습니다.

실제로 Vite를 도입하고 배포하는 과정에서 도커 컨테이너로 요청이 제대로 전달이 안되는 과정이 발생했는데, 해당 오류를 고치기 위해서 꽤 오랜 시간을 고민했던 경험이 있습니다.

제가 겪었던 문제에 대한 Vite 공식문서의 내용을 추가로 첨부합니다.

Vite

Vite, 차세대 프런트엔드 개발 툴

vitejs-kr.github.io

하지만 이런 어려움에도 불구하고 프로그램 동작과 관련해서 Vite가 문제를 일으키는 부분들을 모두 제거할 수 있었고, 속도의 장점만을 얻어낼 수 있었습니다!

이렇게 새롭게 도입한 두 가지 요소를 제외하면 나머지는 익숙한 기술스택들을 사용했습니다.

프론트엔드는 TypeScript와 React를 사용하였으며, CSS 처리를 위해 Emotion을 사용했습니다.

백엔드는 Spring Boot와 MySQL를 사용했습니다. ORM으로 JPA를 사용했으며, QueryDSL을 사용하려고 했으나 실제로 적용하지는 못했습니다. (코드가 간단해서 Native로 모두 처리했습니다.)

추가로 로그인 과정에서 액세스 토큰을 사용하기에 이걸 따로 저장해두어 로그아웃 시 해당 액세스 토큰을 사용하지 못하도록 하기 위해서, 그리고 리프레시 토큰을 이용한 유효성 검사를 하기 위해서 Redis를 사용했습니다.

CI/CD로는 Docker와 Jenkins를 사용했습니다.

2.1. 실제 개발 과정

아이디어 회의부터 기획이 약 1주 반만에 끝났기 때문에 개발 기간을 2주 반, 최대 3주 반까지 잡았고 나머지 1주일은 이벤트 진행 및 QA를 진행하려고 계획했고, 실제로 개발 기간은 약 3주 정도가 걸렸습니다.

특히 프로젝트는 9-6를 거의 완벽하게 지켜냈다는 점에서 매우 만족했습니다.

그래도 개발 막바지의 커밋을 보면 새벽에 진행된 몇 커밋이 존재하긴 합니다 ㅎㅎ

프로젝트 막판에 출력부분과 iOS 지원 관련 문제때문에 조금 고생했습니다...

개발과는 무관할 수도 있지만,, 개발이 종료되고 QA를 진행하면서 동시에 이벤트를 2차례 진행했고, 모두 성황리에 종료되어서 당첨자들에게 꽃다발과 실물 롤링페이퍼까지 전달할 수 있었습니다!

2.2. 폴더 구조

프론트엔드 폴더 구조는 크게 특별한 요소가 존재하지 않습니다.

pages 폴더에는 각각의 페이지가 들어있고, 페이지를 구성하는 요소들은 components에서 관리합니다.

api 폴더에는 api 요청을 편리하게 사용하기 위해 객체 형태로 함수들을 정리해놓은 파일들을 모아놓았습니다.

assets 폴더에는 애플리케이션에 필요한 다양한 사진 자료들이 들어있고, kakao 폴더에는 카카오 로그인과 관련된 파일들이 들어있습니다.

recoil 폴더에는 전역에서 관리해야 하는 다양한 상태값들이 들어있고, utils에는 dateFormatters 함수와 액세스 토큰과 리프레쉬 토큰을 업데이트하기 위한 updateTokens가 들어있습니다.

백엔드 폴더 구조 역시 단순합니다.

Controller에서 사용자의 요청을 받고, Service에서 비즈니스 로직을 처리합니다.

Converter 폴더에는 DB에서 데이터를 가져온 후에 그대로 사용하지 않고 DTO형태로 변경해서 사용하기 위한 용도의 파일들이 들어있고, DTO 폴더에는 입력값과 반환값에 대한 정보가 들어있습니다.

Entity 폴더에는 DB의 테이블에 해당하는 정보가 들어있고, Repository 폴더에는 JPA를 사용하기 위한 파일들이 들어있습니다.

마지막으로 util 폴더에는 S3와 관련된 내용들이 들어있습니다.

추가로 resources의 env.yml에는 Kakao Developer에서 생성한 꽃바다 애플리케이션의 adminKey가 들어있습니다.

해당 내용은 중요한 정보이므로 Git에 올라가지 않습니다.

2.3. 담당 개발 기능

이번 프로젝트에서 저에게 주어진 가장 큰 임무는 서버 배포를 처음부터 끝까지 하는 것이었습니다.

이전 프로젝트들에서 Docker와 Jenkins를 사용하는 모습들을 여러 차례 봐오기도 했고, 그러한 배포 작업들에 관심도 있었고 실제로 작은 부분에서는 관여하기도 했었기 때문에 크게 무리 없이 자동 배포까지 완료했습니다.

사실 배포 과정에서 여러 작은 문제들이 발생하기도 했습니다만...

(대표적으로 위에서 언급한 Vite 관련 문제가 있겠네요...)

몇 가지 예시를 들자면 백엔드 도커파일을 잘못 이해해서 이상하게 작성한다거나 (jar파일의 이름을 잘못 적었습니다 ㅠㅠ)

Vite의 기본 포트를 EC2 서버가 허락하지 않아서 3000으로 접속한 이후 포트포워딩 해야했다거나

와 같은 다양한 시행착오들이 있었습니다.

특히 가장 기억에 남는 실수는 방화벽을 켜면서 22번 포트를 열지 않고 서버를 종료한 것이었습니다...

분명히 젠킨스에서 자동 빌드도 성공적으로 이루어졌고, 서버도 잘 돌아가는데 ssh가 접속이 안됐습니다.

하필 전날 방화벽을 설정하고 집으로 갔던 탓에 문제가 무엇인지 정확히 파악하는데 시간이 오래 걸렸습니다..

(아니 어제 집가기 전까지는 잘되던게 오늘 아침에 왜 안되는거지? 라고 생각했습니다 ㅠ)

도대체 뭐가 문제일까.. 한참을 고민했는데

포팅매뉴얼에 적기 위해 찍어둔 포트상태를 확인해보니...

22번 포트가 닫혀버려서 접근할 수 없는 상황....

어쩔 수 없이 서버를 초기화 하고 세팅을 다시 했습니다 ㅋㅋㅋㅋㅋ

절대 잊지 않을 것 같습니다 22번 포트 ㅠ

한번 실수하고 나니 포트 만지는게 살짝 겁이 났지만..

두 번째 시도에는 무사히 세팅을 마칠 수 있었습니다.

CI/CD 작업을 마치고 진행한 개발은 카카오페이를 연동하여 결제 시스템을 적용하는 부분이었습니다.

저희가 만드는 애플리케이션으로는 사업자 등록을 할 수 없는 상황이었기 때문에 어쩔 수 없이 테스트 결제로 구현해야했습니다.

결제 시스템 초기 구현

결제 시스템 구현까지는 크게 어려운 일은 아니었습니다.

필요한 데이터를 서버에 넘겨주고, 서버에서 카카오페이 테스트 API를 요청하는 동시에 결제 및 배송 관련 데이터를 MySQL에 저장합니다.

그리고 카카오페이 테스트 API의 결과로 돌아오는 정보들을 다시 화면에 띄워주기만 하면 쉽게 완료되는 구조였습니다.

하지만 테스트 과정에서 예상치 못한 문제가 하나 발생했는데, 분명 코드가 작동을 잘 하는데 아주 가끔씩 결제가 정상적으로 되지 않는 현상이 발생했습니다.

코드적으로 무언가 문제가 있나 싶어서 하루종일 찾아봤는데, 아무리 생각해도 코드에는 문제가 없었습니다.

그래서 카카오페이 API에서 F1002에러에 대해서 정말 많이 찾아봤고, 공식 답변들도 찾아보았지만 답변을 얻지 못했는데..

카카오 DevTalk 게시판에 아래 질문들을 남겨주신 분이 있어서 원인을 파악할 수 있었습니다.

하지만 공식 답변이 달려있지 않아서.. 원인파악은 했지만 궁극적인 해결은 할 수 없었던 부분이 조금 아쉬웠습니다.

(우선은 천천히 결제하는 수밖에.. ㅠ)

결제 관련 UI를 모두 만들고 난 이후에는 다른 팀원들의 일 중에서 도움이 필요하거나 미흡한 부분을 고쳐주었습니다.

그리고 개발 막바지에 제가 중심이 되어서 진행했던 일이 프론트엔드 최적화였는데요,

최적화와 관련해서 가장 먼저 적용했던 부분이 바로 코드 스플리팅이었습니다.

워낙 그림 데이터가 많다보니, 과도하게 그림 데이터를 요구하는 페이지는 해당 페이지를 실제로 사용해야 할 때 그 그림 데이터를 가져오는 방식으로 구조를 변경하면 초기 로딩속도가 향상될 것이라고 생각했고, 실제로 맞아떨어졌습니다.

어떻게 보면 결국 모든 서비스를 이용하기 위해서는 같은 시간이 들겠지만, 과도한 초기 로딩을 잡음으로써 유저들이 처음부터 답답해서 빠져나가지 않도록 막는 하나의 장치를 마련했다고 생각합니다.

그럼에도 불구하고 분명 성능 부분에서 부족한 부분이 많았고, LightHouse를 돌려보면서 문제점들을 조금 더 자세하게 파악할 수 있었습니다.

그 중에서도 가장 예상 로딩 절감치가 높았던 텍스트 압축 사용에 대해서 찾아보게 되었고, GZip 최적화에 대해서 알게 되었습니다.

데이터를 그대로 넘겨주는 것이 아니라 서버에서 압축해서 처리하는 방식을 사용하는 것인데, 압축률을 높이면 클라이언트에서의 로딩속도는 줄겠지만 압축에 따른 서버의 부하가 늘어난다는 Trade-off가 있는 방식이었습니다.

지금 당장은 서버에 여유가 있고, 유저가 직접 경험하는 로딩속도를 줄이는 것이 우선이었기 때문에 nginx.conf의 gzip 관련 옵션들의 주석을 풀었고, 이를 통해 로딩시간을 상당히 많이 줄일 수 있었습니다.

기본적으로 만들어져있는 nginx.conf에는 gzip 옵션이 주석처리 되어있는데, 이걸 풀어줬습니다!

절감치가 드라마틱하게 줄어듦을 확인할 수 있었습니다!

3. 종합

서버를 다루고 Docker와 Jenkins로 자동배포를 구현해본다는 것은 정말로 색다른 경험이었습니다.

제 손짓 하나로 서버가 닫혀버려서 초기화가 강제되는 위험천만한 상황도 겪어보았고, 로컬에선 잘 되는 코드가 서버에 올라갔을 때 문제가 발생해서 nano에디터를 이용해서 shell 환경에서 하나하나 고치는 경험도 해볼 수 있었습니다.

프론트엔드, 그리고 백엔드를 담당했을 때는 분명 실수를 만회할 수 있는 기회가 어느정도 주어지는 느낌이었는데 Shell을 직접 다루고 CI/CD를 구축하고 배포환경을 구성하는 일은 정말 꼼꼼하게 공부해서 처리하지 않으면 다른 팀원들의 시간까지 상당수 뺏어버릴 수 있다는 것을 깨달았습니다.

이번 기회를 통해 개발에 있어 더욱 꼼꼼해야 할 필요가 있다는 것을 몸소 체감할 수 있었습니다.

특히 메모에 대한 중요성을 더더욱 많이 느꼈던 프로젝트였습니다.

CI/CD를 전담했지만, 다른 팀원들 역시 CI/CD에 대해 관심이 굉장히 많았고, 한번 쯤은 경험해보고 싶다는 의견이 많았습니다.

그래서 다른 팀원들도 제가 배포를 성공적으로 마친 후에 쉽게 따라할 수 있도록 최대한 자세하게 포팅매뉴얼을 작성하였고, 현재 새로운 배포 서버에서 다른 팀원이 배포과정을 겪으면서 제가 작성한 포팅매뉴얼을 수정하기도 하고 다양하게 의견을 나누기도 하면서 학습하고 있습니다.

이러한 문서화 과정을 통해서 제가 실제로 공부하고 적용했던 부분들에 대해 쉽게 되돌아볼 수 있고 다른 팀원들의 피드백을 받을 수 있다는 점에서 문서화의 소중함을 깨달았고, 앞으로도 제가 새롭게 공부해서 적용한 부분에 대한 내용, 적용에 대한 근거와 같은 것들을 적어놓으면 미래의 제가 훨씬 편하게 개발을 할 수 있을 거라는 확신을 얻을 수 있었습니다.

새로운 도전이 꽤 있었음에도 이전의 프로젝트들에 비해 확실히 여유있는 개발이었고, 팀원들간의 캐미도 좋은 편이었고 서로에 대해 알아가는 시간도 그다지 필요하지 않았기 때문에 정말 편하게 개발할 수 있었던 것 같습니다.

정말 감사하게도 운영진 측에서 노력을 인정해주셨는지 최우수상을 수여해주셨고, 별개로 UCC상까지 2관왕을 거머쥘 수 있었습니다.

1년 간의 여정을 행복하게 마칠 수 있어서 정말로 기분 좋은 프로젝트였습니다!

4. 애플리케이션 화면 사진

꽃다발 생성 1

꽃다발 생성 2 (개봉일 전에는 봉오리 상태)

새 메시지 작성

개봉일 이후 메시지 확인 및 신고 기능

꽃다발 결제 1

꽃다발 결제 2

꽃다발 프린트

그린하우스 (롤링페이퍼 목록)

꽃가게 (꽃다발 및 꽃 구매)

마이페이지

5. 참고자료 및 기술 스택 관련 자료

Vite

Vite, 차세대 프런트엔드 개발 툴

vitejs-kr.github.io

Recoil

A state management library for React.

recoiljs.org

Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker

redis.io

Kakao Developers

카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.

developers.kakao.com

Code-Splitting – React

A JavaScript library for building user interfaces

reactjs.org

nginx 에 gzip 으로 컨텐츠 압축 설정하기

www.lesstif.com

[Java] Java의 메모리 관리와 가비지컬렉션에 대하여

Ssoco — Mon, 28 Nov 2022 16:31:12 +0900

이전 포스팅에서 Java의 컴파일 과정 및 JVM에 대해서 알아보았습니다.

[Java] Java의 컴파일 과정을 최대한 쉽게 이해해보자

도대체 .java 확장자 파일은 어떻게 우리가 원하는 대로 실행될 수 있을까요? 이것에 대한 궁금증을 갖고 Java의 컴파일 과정에 대해서 공부하게 되었습니다. 틀린 부분이 있다면 지체없이 댓글을

ssocoit.tistory.com

이것저것 다룬다고 직접 그림까지 그려가며 작성했는데, 각각의 메모리의 역할(특히 Heap과 Stack 영역)과 실행 엔진의 가비지컬렉션에 대한 부분은 간단하게 언급만 하고 넘어갔었죠?

이 부분에 대해 보다 자세히 알아보기 위해서 다시 한번 포스팅을 작성합니다.

0. 가비지컬렉션이란?

특정한 인스턴스가 생성되어 메모리 공간을 차지한 상태에서 해당 인스턴스가 더이상 사용되지 않는 상황이 되었다면 그 인스턴스는 Garbage가 됩니다.

C와 C++의 경우 이렇게 불필요하게 메모리를 잡아먹고 있는 인스턴스를 직접 제거해줘야 하지만, Java의 경우 JVM이 알아서 불필요한 메모리를 정리해줍니다.

이것을 바로 가비지컬렉션(이하 GC)이라고 부릅니다.

기본적으로 JVM이 알아서 정리해주지만,

System.gc();

혹은

Runtime.getRuntime().gc();

를 호출하여 명시적으로 GC를 발생시킬 수 있습니다.

System (Java Platform SE 8 )

Sets the system property indicated by the specified key. First, if a security manager exists, its SecurityManager.checkPermission method is called with a PropertyPermission(key, "write") permission. This may result in a SecurityException being thrown. If n

docs.oracle.com

출처:https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#gc--

하지만 이 방식의 경우 개발자가 GC를 컨트롤하는 것이기 때문에 휴먼 에러가 발생할 확률이 높기 때문에 권장하지 않는 방식입니다.

GC 한번에.. 약 20000배의 속도차이를 보여주는 모습...

JVM을 믿읍시다 (?)

public class GCTimeCheck {
    public static void main(String[] args) {
        long startTime = System.nanoTime();
        long endTime = System.nanoTime();
        System.out.println(endTime - startTime + "ns"); // 약 300ns
    }
}

public class GCTimeCheck2 {
    public static void main(String[] args) {
        long startTime = System.nanoTime();
        System.gc();
        long endTime = System.nanoTime();
        System.out.println(endTime - startTime + "ns"); // 약 7000000ns
    }
}

1. Java의 메모리 관리

이전 포스팅에서 Heap 영역에 대해서 간단하게 인스턴스나 객체가 생성되는 경우에 Heap영역에 저장된다고 했습니다.

그리고 Heap 영역에 할당되었던 메모리는 사용이 되지 않는다고 하더라도 자동으로 사라지지 않습니다.

반면 Stack 영역의 경우 메서드가 생성될 때 스택 프레임이 생성됐다가 메서드가 종료되면 해당 스택 프레임이 자동으로 pop되기 때문에 GC가 필요하지 않습니다.

(TMI : Java 메모리의 Heap 영역과 자료구조에서의 Heap은 다른 Heap이니 조심!!)

1.0. Heap 영역과 Stack 영역을 활용한 관리 예시

이해를 돕기 위해 아래 예시를 하나 들고왔습니다.

public class HeapTest {
    public static void main(String[] args) {
        String t = null; // Integer 타입의 객체 t 선언 및 Stack 영역에 공간 할당
        System.out.println(t); // null
        t = "ㅎㅇ"; // Heap 영역에 "ㅎㅇ"를 할당하고, 객체 t에 "ㅎㅇ"가 저장된 주소를 할당
        System.out.println(t); // @32ab41b2
        t = "ㅂㅇ"; // Heap 영역에 "ㅂㅇ"를 할당하고, 객체 t에 "ㅎㅇ"의 주소가 아닌 "ㅂㅇ"가 저장된 주소를 할당
        System.out.println(t); // @32abd256
    }
}

t라는 지역변수의 경우 Stack 영역에 할당되고

null, "ㅎㅇ", "ㅂㅇ" 와 같은 데이터들은 Heap 영역에 할당됩니다.

간단히 말해서, 모든 Object 타입(Integer, String, ArrayList) 등은 Heap 영역에 생성되고, Heap 영역에 있는 오브젝트를 가리키는 레퍼런스 변수들이 Stack 영역에 할당되는 것이죠,

(String의 상위 객체는 Object라는 것을 생각하면 쉽게 이해할 수 있습니다!)

위 예시와 같은 상황에서 "ㅎㅇ"는 더이상 참조되지 않기 때문에 GC의 대상이 됩니다.

출처:https://dzone.com/articles/java-memory-management

2. Heap 영역의 구조

GC의 등장 배경과 예시를 살펴보았으니, Heap 영역의 구조에 대해 조금 더 심도있게 살펴봅시다.

JVM은 이런 Heap 영역에 저장되는 데이터 및 메모리를 효율적으로 최적화하기 위해서 여러 공간을 나눠서 사용하고 있습니다.

Heap 영역의 경우 크게 Young Generation(이하 Young 영역)과 Old Generation(이하 Old 영역)으로 나뉘어집니다.

2.0. Young Generation

인스턴스를 처음 생성하면 Young 영역의 메모리가 배정됩니다.

특히 그 중에서도 맨 처음에는 Eden 영역에 할당이 됩니다.

그러다가 Eden 영역이 꽉 차서 더이상 메모리를 할당할 수 없는 상황이 되면,

Minor GC(Minor Garbage Collection)에 의해서 Eden 영역에 있는 요소의 참조 여부를 살피고 GC를 진행합니다.

이렇게 Young 영역에서 발생하는 GC를 Minor GC라고 부릅니다.

그리고 한번 GC가 되어서 정리된 데이터들은 Survivor Space로 이동됩니다.

그럼 여기서 궁금증이 하나 생깁니다.

Survivor Space가 2개가 있는데, 어떤걸 쓰냐는 의문점이 생길 수 있죠.

Minor GC가 끝난 데이터들은 먼저 S0 영역으로 이동합니다.

그리고 Eden 영역과 S1 영역이 Clear됩니다.

(S1영역에 뭐가 없는데 왜 Clear하는 지 궁금하시다면, S1영역도 Minor GC가 일어나긴 했는데 아직 안에 내용물이 없기 때문에 생략한 것입니다!)

다시 Eden 영역을 채웁니다.

그리고 Eden 영역이 다시 꽉 찹니다.

이번엔 Eden 영역과 S0 영역에 대해서 Minor GC가 발생합니다.

여기서도 살아남은 친구들은 S1 영역으로 복사되고, Eden 영역과 S0 영역이 Clear됩니다.

정리하면 S0, S1 영역중에서 하나의 영역에만 데이터가 존재하게 됩니다.

Eden 영역과 S0, S1 영역중 하나에 대한 Minor GC의 결과물을 Minor GC가 진행되지 않은 Survivor Space에 옮겨놓고 기존 영역들을 정리하는 방식인 것이죠!

2.1. Old Generation

반복되는 과정 속에서 S0 영역과 S1 영역을 반복적으로 이동하는 데이터가 있을 수 있습니다.

이런 친구들은 age값이 증가하게 되는데, 특정 값 이상이 되면 Old Generation으로 데이터가 옮겨지게 됩니다.

이렇게 Young 영역에서 Old 영역으로 데이터가 옮겨지는 것을 Promotion이라고 부릅니다.

Promotion이 반복되면 Old 영역에 데이터가 쌓이게 되고, Eden 영역과 같은 방식으로 Old 영역 역시 GC를 통해 메모리에서 필요없어진 요소들을 제거하게 됩니다.

이렇게 Old 영역에서 발생하는 GC를 Major GC라고 부릅니다.

그리고 Heap 전체에 대해서 GC가 동작하는 것, Major GC와 Minor GC가 동시에 일어나는 것을 Full GC라고 부릅니다.

아주 드문 경우지만, Old 영역에서 Young 영역을 참조하는 경우가 있을 수 있습니다.

이런 경우를 대비해서 Old 영역에는 참조 확인 용도의 카드 테이블이 존재해서, Young 영역의 Minor GC가 동작할 때 모든 Old 영역의 요소를 확인하는 것이 아닌 해당 카드 테이블만 확인하는 방식을 사용할 수 있습니다.

3. Garbage Collection의 동작방식

그렇다면 JVM은 어떤 방식으로 GC 대상을 파악하는 걸까요?

적용 알고리즘의 경우 Serial GC, Parallel GC, CMS GC, G1 GC 등등 다양하지만, 기본적으로 Stop The World와 Mark & Sweep에 기초를 두고 있습니다.

먼저 GC를 하기 위해 Stop The World를 진행합니다.

Marking 작업을 위해서 모든 스레드를 중단시키는데, 이것을 Stop The World라고 부릅니다.

(GC를 튜닝하는 과정은 이 Stop The World 시간을 줄이는 것이라고 보시면 됩니다!)

모든 스레드를 멈추고, 스택 내의 모든 지역 변수를 스캔하면서 각각 어떤 오브젝트를 참조하고 있는지를 찾는 과정이 바로 Marking 작업이고, 참조가 되어있지 않은 오브젝트들을 Heap에서 제거(Sweep)하게 됩니다.

이 방식을 Mark & Sweep이라고 부릅니다.

각각의 GC 알고리즘에 대해 더 자세하게 알고 싶다면 아래 사이트들을 확인하시면 됩니다!

Java Garbage Collection Basics

Java Overview Java is a programming language and computing platform first released by Sun Microsystems in 1995. It is the underlying technology that powers Java programs including utilities, games, and business applications. Java runs on more than 850 mill

www.oracle.com

Garbage Collection (GC) : 가비지 컬렉션

Garbage Collection java에서는 개발자가 코드로 메모리를 명시적으로 해제하지 않기 때문에 Garbage Collector가 더이상 필요없는 객체를 찾아 지우는 작업을 한다. stop-the-world GC를 실행하기 위해 JVM이 애

seungahyoo.tistory.com

NAVER D2 - Java Garbage Collection

https://d2.naver.com/helloworld/1329

4. 정리

가비지컬렉션(GC)는 Heap 영역에 있는 데이터들 중에서 불필요해진 데이터들을 자동으로 정리해주는 작업입니다.

일반적으로 JVM이 알아서 해주지만, 개발자가 임의로 진행할 수도 있습니다.

하지만 개발자가 직접 GC에 관여하는 방식은 권장하지 않습니다.

동작 방식의 경우 Stop The World를 통해 스레드를 멈추고 Mark & Sweep 방식으로 더이상 참조되지 않는 요소들을 걸러내서 메모리에서 할당 해제를 진행하게 됩니다.

그리고 효율적인 Heap 메모리 사용을 위해 Young 영역과 Old 영역으로 나눠서 데이터를 관리하고, 각 영역의 GC를 Minor GC, Major GC라고 부르고 두 GC를 합쳐서 Full GC라고 부릅니다.

또한, JavaScript의 가비지컬렉션 동작 방식과도 굉장히 유사합니다.

Java가 Stack 영역의 지역변수를 기준으로 marking 과정을 진행하고 참조 여부를 판단한다면, JavaScript는 root부터 root가 참조하는 모든 객체를 방문하고 mark 하는 방식으로 참조를 판단한다는 차이를 가지고 있습니다.

5. 참고자료

Java Garbage Collection Basics

www.oracle.com

자바 메모리 관리 - 가비지 컬렉션

개요 Java 가비지 컬렉션에 대해서 공부한 내용을 정리해본다. Java 에서 메모리 관리는 어떻게 이루어지는지 이해하고 있으면 좋다. 자바 메모리 관리 - 스택 & 힙 를 먼저 읽는 것을 추천한다. 모

yaboong.github.io

[자바 기초] 3. 자바의 동작원리 : Garbage Collection

1. Garbage Collection(GC) 개념 기본 개념은 쉽다. 어떤 인스턴스가 생성되어 메모리 공간을 차지한 상태에서 해당 인스턴스가 프로그램에서 사용되지 않게 되었다면(null 처리 되었거나 해당 인스턴스

whitepro.tistory.com

Java Platform SE 8

docs.oracle.com

JAVA의 GC의 종류 및 특징

GC(Garbage Collector) 란? JAVA 개발을 하면서 Out Of Memory Error는 접할 수 밖에 없으며, 해당 에러가 운영환경에서 발생하게 되었을 때 서비스 장애로 까지 이어 질 수 있다. 때문에 메모리를 괸리해주는

blog.ycpark.net

[JAVA/자바] 메모리 구조(static, stack, heap)

이번 글은 자바(JAVA)를 사용하는 입장에서 알아야 할 메모리 구조 및 특징에 대해서 알아...

blog.naver.com

[Java] Java의 컴파일 과정을 최대한 쉽게 이해해보자

Ssoco — Sun, 27 Nov 2022 04:05:09 +0900

도대체 .java 확장자 파일은 어떻게 우리가 원하는 대로 실행될 수 있을까요?

이것에 대한 궁금증을 갖고 Java의 컴파일 과정에 대해서 공부하게 되었습니다.

틀린 부분이 있다면 지체없이 댓글을 남겨주시면 최대한 빠르게 수정하도록 하겠습니다!!

0. 전체 실행 과정

아래 사진은 전반적인 실행 과정을 간략하게 표시해놓은 그림입니다.

굉장히 복잡한 단어들이 나열되어있는 것 같지만, 하나하나 뜯어보면 처음 자바를 익히는 사람들도 충분히 이해할 수 있는 구조로 되어있습니다.

이제 하나하나 뜯어가며 살펴보도록 하죠!

1. JVM이란?

Java 이전 C와 C++의 경우 컴파일 플랫폼과 타겟 플랫폼이 다른 경우 프로그램이 동작하지 않는 경우가 있었습니다.

(이유는 운영체제, CPU 하드웨어 등 다양...)

출처 : 무민의 JVM Stack & Heap 영상

이런 상황에서 타겟 플랫폼에 맞춰서 컴파일하는 것을 크로스컴파일이라고 부릅니다.

출처 : 무민의 JVM Stack & Heap 영상

이렇게 복잡하게 타겟 플랫폼에 맞춰서 컴파일해야한다는 단점을 보완하기 위해서, Java의 바이트코드는 JVM(Java Virtual Machine)이라는 자바를 실행하기 위한 가상 기계 위에서 돌아감으로써 문제를 어느정도 해결할 수 있었습니다.

JVM이 설치된 플랫폼이라면 OS가 무엇이든 플랫폼이 뭐든 똑같이 바이트코드가 동작할 수 있는 것이죠!

(물론 JVM은 각 타겟 플랫폼에서 동작할 수 있는 버전이 설치되어있어야 합니다)

출처 : 무민의 JVM Stack & Heap 영상

그렇다면 Java가 크로스컴파일이 아닌 JVM방식을 선택한 이유는 무엇일까요?

Java가 등장하던 시기는 새로운 운영체제 및 디바이스가 마구마구 출시되기 시작하던 시절이었고, 모든 운영체제 및 기종들에 대해서 컴파일을 고려하는 것은 굉장히 어려운 일이었습니다.

단순히 JVM위에서 돌아갈 수 있게 해놓고, 각 운영체제 및 디바이스별로 JVM만 설치할 수 있다면 조금 더 편하게 모든 곳에서 동일하게 동작할 수 있는 시스템을 구축할 수 있을 것이라고 생각했기에 이런 방식을 선택했다고 보시면 되겠습니다!

(자바의 야심이라고 볼 수 있겠네요!)

2. 바이트코드 변환

이제 JVM에 대해서도 어느 정도 이해했으니, 맨 윗 부분에 있던 자바 컴파일러에 의한 바이트코드 변환부터 차근차근 살펴봅시다.

개발자들이 .java 파일을 생성하고 Build를 하게 되면,

자바 컴파일러의 javac라는 명령어를 사용하여 자바 바이트코드로 구성된 .class파일을 생성하게 됩니다.

해당 클래스 파일을 통해서 어떤 환경에서든 같은 코드 결과를 얻을 수 있게 된겁니다!

(이 부분은 JVM의 클래스 로더를 설명하는 과정에서 다시 한 번 이해할 수 있습니다!!)

아래 첨부한 사진을 보시면, 실제로 .java파일을 javac를 이용하여 빌드한 후에 추출된 .class파일을 확인해보았습니다.

(왼쪽이 .java 파일, 오른쪽이 .class 바이트코드입니다)

ICONST는 이미 저장되어있는 정수변수값을 가져올 때 사용하고, ISTORE는 사용하는 메모리단을 보여줍니다.

또한 IMUL과 ISUB는 각각 곱셈과 뺄셈을 담당한다는 것도 어렴풋이 알 수 있습니다.

이렇게 우리가 어느 정도 알아들을 수 있게 컴파일됐다는 것은, .class파일이 완벽한 기계어가 아니라는 것의 한 가지 증거가 됩니다!

추가로, 바이트코드는 JVM과 같은 가상머신이 이해할 수 있는 언어이고, 바이너리 코드는 CPU가 이해할 수 있는 언어입니다.

자바의 경우 자바 컴파일러가 JVM이 이해할 수 있도록 소스 파일을 .class 파일로 변환하는 것이고, C의 경우 한번에 바이너리코드로 변환하는 것이죠.

여기까지 이해했다면, JVM이 바이트코드를 읽어와야 한다는 필요성을 느낄 수 있을 것입니다!

3. 클래스 로더와 실행 엔진

이렇게 추출해낸 .class파일은 클래스 로더에 의해서 JVM의 영역으로 들어가게 됩니다.

클래스 로더가 불러오는 과정을 간략하게 설명하면, 로딩 과정에서 메서드 영역에 클래스를 저장하고, 링크 과정에서 구성 요소를 검증하고 메모리를 할당한 후에, 초기화 과정에서 클래스 변수들을 적절한 값으로 초기화합니다.

또한 클래스 로더는 하나만 존재하는 것이 아니라 계층적으로 존재해서, 상위 클래스 로더가 가져온 내용을 먼저 확인하고 찾지 못한 경우 그때 하위 클래스 로더가 클래스를 로드하게 됩니다.

하단 그림이 바로 클래스 로더 위임 모델인데, Bootstrap Class Loader이 JVM을 기동할 때 생성되는 가장 기본적인 자바 API를 로드하는 클래스로더입니다.

Extension Class Loader는 기본 자바 API를 제외한 나머지 확장 클래스를 로드하고, System Class Loader는 애플리케이션의 클래스들을 로드합니다.

그 하위의 User-Defined Class Loader는 사용자가 직접 생성해서 사용하는 클래스 로더입니다.

이렇게 어찌어찌 JVM에 들어온 바이트코드는 실행 엔진에 의해 기계어로 해석되어 메모리에 배치되고 실행됩니다.

여기서 인터프리터 방식과 JIT 컴파일러 방식으로 나눠집니다.

인터프리터 방식의 경우 바이트 코드를 한 줄씩 읽고, JIT 컴파일러 방식은 바이트 코드를 한번에 컴파일하고 캐싱하는 방식입니다.

JVM은 기본적으로 인터프리터 방식을 사용하고, 내부적으로 특정 메서드가 얼마나 자주 수행되는지 체크하고 일정 정도를 넘을 때만 JIT 컴파일러 방식을 사용합니다.

다만 실행 엔진이 어떻게 동작하는 지는 JVM 명세에 규정되어있지 않기 때문에 JVM을 만들어내는 곳에서는 다양한 방식으로 실행 엔진을 최적화하고 있다고 합니다.

4. 런타임 데이터 영역

이제 자바 컴파일 과정을 나타낸 그림의 최하단에 위치해있던 런타임 데이터 영역에 대해서 조금 더 자세하게 알아보겠습니다.

클래스 로더의 로딩 과정을 통해 불러온 클래스는 메서드 영역에 저장됩니다.

메서드 영역에는 클래스와 인터페이스에 대한 필드 및 메서드 정보, Static 변수, 메서드의 바이트코드 등등이 저장됩니다.

메서드 영역은 JVM을 어떻게 만드냐에 따라 다양한 형태로 구현할 수 있습니다.

특히 이 메서드 영역 안에는 런타임 상수 풀(Runtime Constant Pool)이라는 영역도 존재하는데, 각 클래스와 인터페이스의 상수, 그리고 메서드의 모든 정보를 담고 있는 테이블을 의미합니다.

JVM은 런타임 상수 풀에서 특정 메서드나 필드의 실제 메모리상의 주소를 찾아서 참조하게 됩니다.

인스턴스나 객체를 생성하는 경우에는 힙 영역에 저장됩니다.

TMI 하나 방출하자면, 실행엔진의 가비지컬렉터는 보통 힙 영역의 메모리가 부족할 때 작동합니다.

메서드 영역과 힙 영역은 모든 스레드가 공유한다는 특징을 가지고 있습니다.

스택 영역의 경우 메서드가 수행될 때마다 하나의 스택 프레임이 생성되는 방식입니다.

당연히 메서드가 종료되면 스택 프레임이 제거되고, 컴파일 시에 스택의 크기가 결정되는 특징을 갖고 있습니다.

PC 레지스터 영역의 경우 현재 스레드가 수행중인 JVM 명령의 주소값이 담깁니다.

멀티스레드 프로그래밍 환경에서 한 스레드가 작업하다가 다른 스레드로 잠시 CPU 점유를 넘겨주고 돌아왔을 때 어떤 일을 하고 있었는지 기억해야 거기서부터 다시 할 수 있겠죠?

이럴 때 사용되는 영역입니다.

네이티브 메서드 스택의 경우에는 Java의 바이트코드가 아닌 다른 언어(C, C++ 등..)로 작성된 메서드를 담아두는 공간입니다.

스택 영역, PC 레지스터 영역, 네이티브 메서드 스택은 하나의 스레드가 생성될 때마다 같이 생성이 되고, 서로 다른 스레드가 침범할 수 없습니다.

5. 정리

지금까지 Java의 컴파일 과정이 어떻게 진행되는지에 대해서 알아본 내용을 간단하게 정리해봅시다.

먼저 JVM을 사용하는 이유에 대해서 알아봤습니다.

Java는 어디에서나 같은 결과물을 내기 위해서 JVM을 사용합니다.

그 다음에는 Java 컴파일 과정에 대해 하나하나 살펴보았습니다.

먼저 개발자가 만든 .java 파일을 자바 컴파일러의 javac에 의해 JVM이 읽을 수 있는 바이트코드로 바꿉니다.

이 바이트코드는 계층적으로 존재하는 JVM의 클래스 로더에 의해 JVM의 메모리에 할당되고 실행 엔진에 의해 기계어로 변환되고, 최종적으로 실행됩니다.

실행 엔진은 크게 두 가지로 나눌 수 있는데, 한줄씩 읽는 인터프리터 방식과 한번에 읽는 JIT 컴파일러 방식이 있습니다.

또한 런타임 데이터 영역에서 읽어들인 데이터를 저장하게 되는데, 메서드 영역과 힙 영역의 경우 모든 스레드가 공유하고, 스택 영역과 PC 레지스터 영역, 네이티브 메서드 영역은 하나의 스레드가 각각의 영역을 보유합니다.

엄청나게 어려워보였던 Java의 컴파일 과정이 어느 정도 요약이 되었을까요?!

가비지컬렉터가 동작하는 방식, 생성된 바이트 코드가 의미하는 것 등등 핵심 내용에서 살짝 벗어나기 때문에 다루지 않은 내용들도 존재하지만, Java의 컴파일 과정에 대해 궁금증을 품었던 것처럼 하나하나 찾아보면서 익히면 Java에 대한 이해도가 훨씬 높아질 수 있을 것이라고 확신합니다!!

(저도 해당 포스팅을 작성하면서 Java의 동작 방식에 대해 더 깊은 정보까지 공부해보고 싶어졌습니다 ㅎㅎ)

다음에는 더 자세하고 깊이있고 유익한 포스팅으로 돌아오겠습니다 :)

6. 참고자료

[JAVA] JVM 동작원리 및 기본개념

JAVA라는 언어를 통해 코딩을 하고 있는 사람으로서 JAVA의 간단한 탄생배경 그리고 JAVA의 시작과 끝이라고 할 수 있는 JVM을 한 번 짚고넘어가려고 해요 우선 JAVA의 탄생배경을 좀 알고가면 이해하

steady-snail.tistory.com

알기쉽게 정리한 JAVA의 컴파일과정 및 JVM 메모리 구조, JVM GC

알기쉽게 정리한 JAVA의 컴파일과정 및 JVM 메모리 구조, JVM GC 자바 개발자들이 간과 하기 쉬운 JAVA의 메모리 구조에 대해 포스팅 해보려고 합니다. 이와 관련하여 JAVA의 컴파일 과정과 Garbage Collect

aljjabaegi.tistory.com

[Java] 자바의 동작과정 Java Compiler와 JVM

이클립스에서 *.java를 단축키 눌러서 실행시킬 줄만 알았지 *.java 파일이 어떠한 과정을 거쳐 실행이 되는지는 알지 못했습니다. 따라서 자바 컴파일러는 어떤 역할을 수행하며, 어디서 많이 들

kingofbackend.tistory.com

[Java] JVM의 클래스 로더란?

java-study에서 스터디를 진행하고 있습니다. 클래스 로더란? 자바는 동적 로드, 즉 컴파일 타임이 아니라 런타임(바이트 코드를 실행할 때)에 클래스 로드하고 링크하는 특징이 있다. 이 동적 로드

steady-coding.tistory.com

The Java® Virtual Machine Specification

Tim Lindholm Frank Yellin Gilad Bracha Alex Buckley

docs.oracle.com

NAVER D2 JVM Internal

https://d2.naver.com/helloworld/1230

[JS] 자바스크립트는 왜 멀티스레드가 아니라 싱글스레드로 동작하는걸까?

Ssoco — Sat, 5 Nov 2022 16:36:08 +0900

자바스크립트를 공부하다보면 정말 많이 들을 수 있는 말이 바로

자바스크립트는 싱글스레드로 동작한다

입니다.

여기서 드는 의문점 하나는, 왜 굳이 멀티스레드를 놔두고 싱글스레드로 동작할까 입니다.

누구나 멀티스레드가 싱글스레드보다 좋지 않냐고 쉽게 생각할 수 있는데, 왜 자바스크립트 개발자들은 여전히 싱글스레드를 고집하는 것일까에 대한 고민이 해당 포스팅으로 이어지게 되었습니다.

0. 싱글스레드인데 어떻게 여러 작업을 동시에 처리하지?

멀티스레드를 놔두고 싱글스레드로 동작하는 이유를 알아보기 전에, 진짜 자바스크립트가 싱글스레드인지, 또 어떻게 자바스크립트가 우리의 눈을 속이고 있을까에 대해서 먼저 알아보겠습니다.

0.0. 자바스크립트, 싱글스레드 맞아?

먼저 자바스크립트가 싱글스레드임을 확인하기 위해서 간단한 코드 하나를 가져왔습니다.

setTimeout(() => {console.log("코딩하는"}, 0); // 1
while(1) console.log("경제학도"); // 2
console.log("쏘코입니다."); // 3

해당 코드는 자바스크립트의 Run-To-Completion 특성에 의해서 "경제학도" 만 출력되고 나머지는 영원히 출력되지 않습니다.

Run-To-Completion을 간단히 설명하면 하나의 함수의 실행이 끝날 때 까지 다른 작업은 수행되지 않는다는 것이죠.

싱글스레드이기 때문에 가지는 특성이기도 합니다.

조금 더 자세하게 설명하면 해당 코드의 실행 순서는 2 3 1 입니다. (동작 순서에 대한 자세한 설명은 후술할 이벤트루프와 연관되어있습니다.)

하지만 2번 동작이 영원히 끝나지 않기 때문에 3과 1은 동작하지 않습니다.

0.1. 자바스크립트의 동시성 치트키 이벤트루프

이제 자바스크립트가 싱글스레드임을 확인했으니, 눈을 속이는 방법에 대해서 알아보겠습니다.

웹 브라우저가 어떻게 자바스크립트 코드를 실행시키는지에 대한 자세한 내용을 알지 못한다고 하더라도 일반적으로 사람들은 웹 페이지에서 자연스럽게 여러 동작이 동시에 일어난다고 인식합니다.

(싱글스레드임을 체감할 정도로 민감하다면.. 당신의 반응속도는.. 세계에서 손꼽을 정도일 지 모릅니다)

출처:https://blog.sessionstack.com/how-does-javascript-actually-work-part-1-b0bacc073cf

위 사진은 이벤트루프가 어떻게 동작하는지에 대해서 간략하게 도식화한 사진입니다.

JavaScript 코드 내에서 비동기로 처리해야 하는 요소가 생긴다면 (callback이라든지, Promise라든지, async await이라든지, setTimeout이라든지...) JS는 자신이 그 요소를 처리하지 않고 Web API라는 친구에게 위임합니다.

그리고 나서 바로 다음 코드로 이동해서 작업을 수행하게 되는 것이죠.

Web API에서 처리된 내용은 Callback Queue(Task Queue)로 들어갑니다.

Callback Queue는 또 일반 Callback Queue와 Animation Frames, Microtask Queue로 나뉘게 됩니다.

뒤로 갈수록 빠져나가는 우선순위가 더 높습니다.

어떻게 큐에서 요소들이 빠져나갈 수 있을까요?

여기서 바로 이벤트루프가 등장합니다!

이벤트루프는 JS엔진의 Call Stack을 지속적으로 바라보고 있다가, Call Stack이 비면 우선순위에 따라 각각의 Queue들에서 대기중인 요소들을 Call Stack으로 넣어줍니다.

출처:https://dev.to/lydiahallie/javascript-visualized-promises-async-await-5gke

여기서 한 가지 더 알고 가야 할 부분이, JavaScript가 싱글 스레드라는 것은 하나의 Call Stack을 가졌다는 의미와도 일맥상통합니다.

따라서 단 하나 존재하는 그 Call Stack이 비지 않았다면 Callback Queue에서 동작이 무한히 대기하게 되는 것이고, 그래서 위에서 두 번째 요소를 제외한 나머지 요소들이 동작하지 않은 것입니다!

이렇게 오래 걸릴 수 있는 동작들을 이벤트루프를 통해서 동시에 처리되는 것처럼 보이게 한다는 사실을 이제 잘 알 수 있겠죠?

1. 이벤트루프가 짱이네. 근데 멀티스레드 쓰면 되는거 아니야?

맞습니다.

멀티스레드를 쓰면 자바스크립트의 동작을 WebAPI에게 굳이 위임하지 않아도 되고, 이벤트루프나 Callback Queue들도 필요가 없어지게 되겠죠.

하지만, 자바스크립트가 싱글스레드를 사용함으로써 얻는 이점은 바로 동시성 문제를 신경쓰지 않아도 된다는 것입니다.

그 예시로 iOS나 Android같이 멀티스레드 환경을 제공함에도 항상 주의사항이 따라붙는데, UI 스레드(메인 스레드) 이외의 다른 Worker 스레드에서는 UI 작업을 하지 말아야 한다는 것입니다.

사용자에게 있어서 화면이라는 자원에 여러 스레드가 동시에 접근하게 된다면 문제가 발생할 여지가 생기게 됩니다.

만약 같은 부분에 대해서 서로 다른 수정을 요구한다면, 우리가 생각한 대로 수정이 될 것이라는 보장을 하기 어려워지겠죠?!

이런 위험성을 차단하기 위한 목적과 함께, 멀티스레드로 얻을 수 있는 이득이 싱글스레드를 유지하는 것보다 크지 않기 때문에 JavaScript는 싱글스레드를 사용한다고 추측할 수 있겠습니다.

1.0. 주의!

그럼에도 자바스크립트에서 멀티스레드를 사용하기 위한 다양한 노력은 계속되고 있고, ES2017(ES8)에서 SharedArrayBuffer, 그리고 atomics 객체를 사용해서 메모리를 동시에 접근할 수 있게 하는 새로운 방법을 제시했습니다.

다만 해당 내용의 경우 2018년 초에 발생한 Intel CPU의 이슈문제 때문에 사용이 중단되기도 했고, 지금 시점에서 자유자재로 사용하기엔 어려운 부분이 있으니 꼭 필요한 경우에만 확인하고 사용하시는 것을 추천드립니다!

메모리 특강 ★ Mozilla 웹 기술 블로그

이 글은 3부작 시리즈의 첫번째 글입니다. 메모리 특강 만화로 소개하는 ArrayBuffer 와 SharedArrayBuffer Atomics 를 이용해서 SharedArrayBuffer 레이스 컨디션 피하기 ArrayBuffer 와 SharedArrayBuffer 가 JavaScript 에

hacks.mozilla.or.kr

A crash course in memory management – Mozilla Hacks - the Web developer blog

This is the first article in a 3-part series of code cartoons that explore SharedArrayBuffers in JavaScript and how they are used. To understand why ArrayBuffer and SharedArrayBuffer were added ...

hacks.mozilla.org

ES proposal: Shared memory and atomics

ES proposal: Shared memory and atomics (Ad, please don’t block) The ECMAScript proposal “Shared memory and atomics” by Lars T. Hansen has reached stage 4 this week and will be part of ECMAScript 2017. It introduces a new constructor SharedArrayBuffer

2ality.com

2. 참고자료

How JavaScript works: an overview of the engine, the runtime, and the call stack

As JavaScript is getting more and more popular, teams are leveraging its support on many levels in their stack - front-end, back-end…

blog.sessionstack.com

⭐️ JavaScript Visualized: Promises & Async/Await

Ever had to deal with JS code that just... didn't run the way you expected it to? Maybe it seemed lik...

dev.to

[ 번역 ] 자바스크립트 시각화 : 비동기 처리

원문 : ⭐️ JavaScript Visualized: Promises & Async/Await

velog.io

Event Loop (이벤트 루프)

이번 글은 Event Loop (이벤트 루프) 에 대해 정리해보려고 한다. Event Loop? Event Loop 출처 How JavaScript works: an overview of the engine, the runtime, and the call stack Event Loop는 MDN 문서로 검색하면 "큐의 다음 메시

velog.io

[JavaScript] setTimeout과 setInterval은 정확한 시간을 보장하지 않는다!

이번에도 스톱워치를 만들다가.. 말로만 듣던 setTimeout과 setInterval의 시간보장문제를 직접 맞닥뜨리게 되었습니다. 말로만 듣던걸 간단한 프로그램을 만들면서 직접 겪으니까 참 오묘하네요 ㅎ

ssocoit.tistory.com

자바스크립트 호출 스택(Call Stack) 이해하기

시작하기에 앞서자바스크립트를 심도 있게 이해하기 위해 "모든 자바스크립트 개발자가 알아야할 33가지 개념(https://github.com/yjs03057/33-js-concepts)"의 항목들과 링크되어있는 블로그 글들을 정리하

new93helloworld.tistory.com

코드스피츠85 2회-(1) 자바스크립트의 동시성

코드스피츠 85에서는 none blocking에 대한 이야기와자바스크립트를 짜는 근본적인 방법에 대한 고찰을 이야기해본다. TL;DR 자바스크립트의 동시성 모델에 대해서 알아본다. 동시성이라는

feel5ny.github.io

자바스크립트는 왜 싱글 쓰레드일까? :: chanyeong

자바스크립트라는 언어는 싱글 쓰레드 언어라고 알려져있다. 보통 싱글 쓰레드라고 하면 한 번에 하나의 작업만 수행할 수 있다고 생각한다. 그렇다면 자바스크립트를 주로 사용하는 웹 사이트

chanyeong.com

네이버 D2 - 2018과 이후 JavaScript의 동향 - JavaScript(ECMAScript)

https://d2.naver.com/helloworld/7495331

[뻘] 첫 백엔드 도전, 아임텔러 회고

Ssoco — Sat, 22 Oct 2022 15:03:47 +0900

이번에는 프로젝트에 NFT를 끼얹어 버렸습니다 ㅋㅋ

특화 프로젝트에서는 하나의 특화 아이템을 선택해야 했는데, 그게 바로 NFT였습니다.

나름 최근에 핫한 주제이기도 하고, 이전부터 한번 공부해봐야지~ 라고 생각했던 소재였기에 주저없이 NFT를 선택했습니다.

심지어.. 거기에 게임까지 더해버렸습니다!!

그리고!!!

이전부터 소원이었던 백엔드를 이번 기회에 꼭 한번 담당해보고 싶어서 팀원들에게 부탁을 했습니다.

그래서 팀원들의 배려와 도움으로 개발기간 중 대부분의 시간을 백엔드에 할애할 수 있었습니다.

Team Classic 팀원들에게 무한한 감사 ㅎㅎ

0. 팀 컬쳐

0.0. 그라운드 룰

이전의 팀 규칙을 이번에는 Ground Rule로 표현해 보았습니다!

코어타임과 코드리뷰, 주간테크톡 등 이전 공통프로젝트에서 해보지 못했던 것과 관련된 내용들을 정리해 두었습니다.

0.1. 갤러리

이번 프로젝트에서도 저번 프로젝트에서 긍정적인 반응을 이끌어냈던 갤러리 작업을 진행했습니다.

사실 사진 찍고 관리하는 것이 쉬운 일은 아니지만, 하다보니까 재밌어서 벌써 세 번째 갤러리 운영을 하게 됐네요 ㅎㅎ

0.2. 바로가기

이번에는 다른 팀원이 사용하던 양식을 사용해보았습니다!

메인에 달력을 띄워놓는게 가장 큰 차이였는데, 접근성 측면에 있어서 좋았습니다!

앞에 꺼내둘 요소들이 많이 없다면 앞으로도 달력을 계속 꺼내놓지 않을까.. 생각해봅니다!!

0.3. 삽질게시판

이번에도 삽질게시판을 운영했습니다!

하지만 대부분 저만 사용해서 아주 쪼금 아쉬웠습니다 ㅎㅎ

다들 무난하게 프로젝트를 진행했기 때문에 그런게 아닐까~

0.4. 주간 Tech Talk

이전 프로젝트에서 못해서 아쉬웠다고 했던 바로 그 주간테크톡을 이번 프로젝트에서는 진행했습니다!

매주 한번씩 자신이 공부한 내용이나 삽질한 내용에 대해서 딥하게 팀원들에게 설명하는 시간을 가졌습니다.

팀원들과 함께 서로가 알게되거나 새로 습득하게 된 지식을 나눌 수 있어서 정말 좋은 경험이었다고 생각합니다!

첫 주는 온라인, 두 번째 주부터는 오프라인으로 진행했는데, 오프라인으로 진행했을 때의 호응도가 더 높았기 때문에 앞으로도 이렇게 스터디를 진행하게 된다면 오프라인으로 추진하게 될 것 같습니다 ㅎㅎ

0.5. 리뷰투게더

리뷰투게더 역시 저번 프로젝트에서 제대로 진행하지 못했던 코드리뷰를 보다 적극적으로 진행하기 위해서 도입했습니다!

단순히 팀 내에서 리뷰를 진행하는 것 이외에도 다른 프로젝트 팀원들과 코드를 공유하고 리뷰를 주고받을 수 있었습니다.

리뷰를 작성하면서 내가 알고 있는 지식이 맞는 지식인가를 다시 한 번 확인하게 되고, 더 열심히 공부해야겠다는 생각을 했습니다...

다만 다들 프로젝트에 몰두하느라 이전 부스트캠프에서 진행했던 것 만큼의 참여도는 나오지 않아서 다소 아쉬웠습니다.

같은 주제로 프로젝트를 진행하는 다른 반 팀을 섭외하는 데에 굉장한 어려움을 겪었습니다.

총 4팀에게 컨택했지만, 딱 1팀에서 긍정적으로 답변해주셔서 정말로 다행히 리뷰투게더가 폐지되지 않고 운영될 수 있었습니다! 이렇게라도 감사인사를 드립니다 ㅎㅎ

아무래도 수상이 걸려있다보니 다들 학습적인 요소보다는 프로젝트에 조금 더 몰두한 것이 아닌가 생각합니다.

0.6. 개선사항

팀 내 문화는 정말로 좋았고, 개발 자체도 잘 진행되었습니다.

다만 백엔드 학습시간때문에 개발에 많은 시간을 할애하지 못한 점은 다소 아쉽습니다. (백엔드 실력이슈 ㅠ)

그리고 빠르게 백엔드를 마치고 프론트엔드를 돕고 싶었으나, 게임 개발 특성상 백엔드에서 다뤄야 하는 데이터와 로직이 굉장히 많았고, 이것들을 프로젝트 마지막까지 계속해서 붙잡아야 했다보니 처음에 예상했던 것보다 프론트엔드와 스마트 컨트랙트에 힘을 별로 못 쏟은 것 같아서 그 부분 역시 조금 아쉬웠습니다.

그래도 이런 부분들은 프로젝트가 거듭되고 백엔드에 대한 지식을 늘려나가면서 충분히 해결할 수 있을 것이라고 생각합니다!

1. 기획단계

이번 NFT 특화 프로젝트에서는 기획을 많이 뒤엎기도 했고, 디자인 작업 및 팀원 변동 이슈때문에 다소 시간이 오래 걸렸습니다!

NFT 프로젝트라는게 참 어렵더라구요..

1.0. 디자인

이번에도 디자인 협업에는 Figma가 사용되었습니다!

한창 디자인작업을 하던 중 Adobe에 Figma가 인수되었다는 무시무시한 소식도 들려왔지만.. ㅋㅋㅋ

피그마에 메모를 남기는 기능을 알게 되어서 알차게 사용할 수 있었습니다!

1.1. ERD

ERDCloud를 사용하여 간단하게 작성했습니다.

핑퐁클래스 프로젝트에 비해 훨씬 단순해진 백엔드의 모습을 볼 수 있습니다.

그럼에도 불구하고 예상보다 훨씬 많은 양의 테이블과 컬럼들이 생성되었습니다.

이 부분 이외에도 게임 처리에 대한 데이터스키마가 존재했기 때문에 어떻게 보면 핑퐁클래스보다 훨씬 더 대규모의 데이터셋을 다룬게 아닐까라고 생각할 수 있을 것 같습니다!

1.2. API문서

일반 API, Socket, SmartContract 세 가지로 나누어서 문서를 작성하였습니다.

익숙하지 않은 부분이 있어서 계속해서 변경되는 부분들이 있었지만, 이런 식으로 스프레드시트에 잘 정리해두다보니 나중에 개발할 때에는 서로간에 의사소통에 있어서 훌륭한 매개체가 될 수 있었습니다.

1.3. Git

이번에는 Git 전략으로 GitHub-Flow를 사용했습니다!

기존에 사용했던 Git-Flow의 경우 프로젝트 규모에 비해서 다소 많은 절차가 있다고 판단되어, Develop Branch를 없애고 FE와 BE, SC(Smart Contract)에서 각각 Feature Branch를 파고 바로 master에 합치는 방식을 사용하였습니다.

이런 방식을 사용하다보니 잘못된 내용이 Master Branch에 올라가는 위험성이 증가한다는 단점이 있었지만, 기존보다 훨씬 빠르고 간결하게 Branch Merge를 진행할 수 있다는 장점이 그러한 단점을 충분히 덮을 수 있었습니다.

2. 개발단계

2.0. 기술 스택

개발 진행 중에도 사소하게 많은 변화를 겪었습니다.

Spring Boot와 MySQL 및 JPA를 사용한다는 기본 골자는 변하지 않았지만, Redis를 사용하려다가 사용하지 않게 되었습니다. (이 내용에 대해서는 후술합니다!)

그 외에 NginX, Docker, Jenkins의 사용은 이전과 동일했고, 백엔드 서버는 Amazon EC2, 그림 및 사진 데이터 저장은 Amazon S3에서 이루어졌습니다.

블록체인 코드의 경우 Solidity를 기반으로 진행하였고, 테스트는 편의상 Remix환경에서 진행하고 실제 프로젝트 안에서는 Truffle을 사용했습니다.

이것도 기술 스택이라고 봐야하는 지는 잘 모르겠지만, 블록체인 토큰 및 NFT 저장용 지갑으로는 MetaMask를 사용했습니다. (실제 서비스 내에서의 재화 사용 및 그림의 NFT화도 MetaMask 로그인을 해야 가능합니다)

프로젝트 진행 막판에 블록체인 네트워크 관련 문제들이 많이 발생해서, 프로젝트 후반부에는 제공된 네트워크 서버 대신 Goerli 테스트 네트워크를 사용했습니다.

이 부분은 다행히 추후에 어느정도 개선이 되었지만, 개발과는 깊은 연관성이 없기 때문에 짧게만 이야기하고 넘어가겠습니다!

프론트엔드는 공통프로젝트에서 사용했던 기술스택과 거의 동일하게 TypeScript 기반의 React와 Redux-Toolkit, 그리고 Emotion을 사용했습니다.

2.1. 실제 개발 과정

실제 개발은 약 3주간 진행되었고, 마지막 1주 정도는 수면 시간을 거의 5시간 이내로 줄여가면서 개발했습니다.

게임 개발 특성상 실시간성이 강한 요소들이 많다보니 다양한 오류들이 발생하였고, 기존보다 훨씬 적은 인원이 백엔드를 담당하기도 했고 무엇보다 제가 Java를 이용한 백엔드 개발이 사실상 처음이었기 때문에 시행착오가 굉장히 많았습니다.

그래도 개발 초기에 Java와 Spring Boot를 이용한 백엔드 경험이 있는 다른 팀원들에게 많은 도움을 받았고, 개발 막판에 잠을 줄여가면서까지 개발을 진행했기 때문에 정해둔 일정에 크게 벗어나지 않게 개발을 진행할 수 있었습니다.

돌아버린 개발시간?

이번 프로젝트에서는 Discord를 이용하여 화면공유 및 작업 내용을 공유하였고, 모르는 부분이 있으면 실시간 Live, 혹은 VSCode의 LiveShare를 사용하여 질문하거나 오류를 해결했습니다.

2.2. 폴더 구조

백엔드는 크게 api, config, exception, util로 폴더를 구성했습니다.

api 폴더 내에는 controller, dto, repository, service가 존재합니다.

controller에는 프론트엔드로부터 받아온 요청들을 처리하는 컨트롤러들을 담아두었습니다.

dto에는 사용자로부터 받는 요청의 양식, 사용자에게 전달하는 반환값의 양식들을 담아두었습니다.

repository에는 백엔드단에서 사용하는 Entity와 JPA를 사용하기 위한 repository가 담겨있습니다. (두 요소를 따로 분리할 수도 있었지만, 팀원들과의 협의 하에 하나의 폴더로 뭉쳐두었습니다.)

service에는 백엔드단에서 사용하는 각종 서비스 로직을 담아두었습니다.

가장 큰 특징이라고 한다면, 백엔드에서 게임 데이터와 관련된 요소를 관리하는데, 관리를 위한 각종 로직들을 RoomRepository에서 처리했습니다. DB를 대신한다는 측면에서 이 곳에 두는 것으로 결정하였는데, 맞는 결정인지는 잘 모르겠으나 개발 과정 중 의사소통에 있어서 크게 문제는 없었기에 변경 없이 그대로 진행하였습니다!

프론트엔드는 pages 폴더에 우리 눈에 보이는 화면들을 정리해두고, components 폴더에 실제 내부에서 사용하는 커다란 기능들을 만들었습니다.

그리고 layout에는 Modal, Header, Footer와 같은 화면 구성 요소들에 대한 내용들을 담았고, Store에는 상태관리를 위한 내용들, Style에는 공통 스타일 요소들을 담았습니다.

추가로 actions에는 API 관련 내용들, assets에는 사진, 음성 및 영상 관련 소스들, contract에는 블록체인 관련 API와 소스들을 담아두었습니다.

2.3. 담당 개발 기능

제가 맡아서 진행했던 부분은 유저와 관련된 백엔드 로직과 게임과 관련된 백엔드 로직이었습니다.

유저 처리의 경우 일반적인 회원가입 로직과 크게 차이가 없었기 때문에 Spring Boot와 JPA를 공부하고 경험한다는 측면에서 편하게 진행할 수 있었습니다.

한 가지 특별한 점이라고 한다면 MetaMask 정보를 연결하는 부분일텐데, 이 부분도 API 처리가 잘 되어있어서 받아오는 대로 DB에 연결만 해주면 됐기 때문에 크게 무리 없이 진행할 수 있었습니다.

가장 문제가 되는 부분이라고 하면 바로 게임 제작이었겠죠..?!

이 부분에서는 우여곡절이 정말로 많았습니다.

게임 내 모든 데이터를 관리해야 하는 것은 아주 당연한 것이었는데, 어떻게 관리할까에 대한 고민을 계속해서 하게 되었습니다.

MongoDB를 도입해서 게임 데이터를 별도로 관리하는 방법, Redis에다가 게임 데이터를 저장하는 방법, 백엔드 서버 자체에 게임 데이터를 저장하는 방법이 존재했습니다.

이 중에서 MongoDB를 도입하는 것은 다소 과하다고 생각되어 Redis를 도입하고자 마음먹고 레퍼런스를 찾아보고 실제로 도입까지 성공했습니다.

하지만 또 하나 발생한 문제는, Redis에 모든 데이터를 다 넣기에는 너무나도 복잡한 자료구조였습니다.

Redis에 자료를 넣게 된다면 매번 꺼내서 파싱을 해야하는 문제가 있는데, 파싱을 하기에는 너무나도 거대한 양의 데이터여서 부담이 됐습니다.

(Redis를 어떻게든 써보려고 공부하면서 채팅 서비스에서 Redis를 사용하면 지금 개발하고 있는 게임 서비스보다 훨씬 효율적으로 Text 데이터를 저장할 수 있겠다는 생각도 할 수 있었습니다 ㅋㅋㅋㅋ;;)

그래서 선택한 것이 백엔드 서버에 직접 저장하는 것이었습니다.

백엔드의 특정 위치에 자료를 저장해놓고, 내부에 메서드를 만들어서 접근했습니다.

굳이 static 형태로 선언해서 처리한 이유는 해당 RoomRepository가 아닌 다른 곳에서도 new를 통해 객체를 생성하는 행위를 하지 않고도 바로 접근할 수 있게 만들기 위해서였습니다.

이제 RoomRepository 안에 각각의 게임 데이터를 변경할 수 있는 다양한 로직을 메서드 형태로 넣어두었습니다.

마치 Service단에서 요청을 처리하듯이 비슷한 방식으로 Room이 담긴 HashMap의 자료를 조회하고 변경하는 형태입니다.

아래는 대표적인 예시로 가져온 방에 접속하는 joinRoom 메서드입니다.

이런 로직을 설계한 대로 만들기만 하면 데이터의 저장은 완료가 됩니다.

하지만 또 다른 어려움이 생겼는데, 그것은 바로 소켓 연결이었습니다.

이전 Sooltreaming 프로젝트에서 node.js와 client간의 socket통신을 socket.io를 이용해서 구현한 적이 있었는데, 이번에는 백엔드 서버가 Java로 구성되었기 때문에 socket.io를 사용할 수 없었습니다.

그래서 어쩔 수 없이 Stomp와 Sock.js를 사용해야했죠.

어찌어찌 연결은 끝냈으나, 각각이 어떻게 동작하는지에 대해서 알아내는 데에는 꽤나 많은 시간이 걸렸습니다.

지금 와서 보면 그렇게 어렵지 않은 내용들인데, 아무것도 모르는 상태에서 잘 정리된 한국어 자료도 찾기 쉽지 않았기 때문에 시간이 오래 걸렸던 것 같습니다.

백엔드서버에서 socket요청을 받으면, 그 요청에 맞는 roomRepository 내의 메서드가 작동하여 잘 동작하게 만드는 것이 프로그램의 핵심이었기 때문에 사용자로부터 요청을 받기 위한 SocketController를 만들었습니다.

아래 사진은 MessageMapping 과정을 통해 게임방에 입장할 때 작동하는 코드입니다.

소켓 기초 url + /room/{sessionId}/join

로 socket 요청이 들어오면 joinRoom 메서드가 작동하고, sendingOperation.convertAndSend 메서드에 의해서 적절한 데이터가 다시 연결된 socket(방에 있는 모든 사람들)으로 전달되는 방식입니다.

여기서 Stomp를 이용한 소켓 연결 방식과 구조에 대해서 모두 설명하기에는 "프로젝트 리뷰" 라는 포스팅의 핵심에서 많이 벗어날 것 같아서, 보다 자세한 내용은 나중에 Stomp의 작동방식에 대해서 설명할 기회가 있다면 그 때 작성해보도록 하겠습니다!

그리고 이렇게 작성한 내용들을 프론트 연결 없이 테스트하기 위해서 크롬 확장프로그램 중에서 Apic이라는 애플리케이션을 사용했습니다.

매번 새로운 창을 켜고 문자형태로 테스트해야한다는 불편함이 있었으나, 브라우저를 다르게 할 필요가 없었다는 점에서 나쁘지 않게 사용했습니다.

혹시나 Stomp로 연결한 socket을 브라우저 상에서 프론트엔드 도움 없이 테스트해보고 싶다면 크롬 웹스토어에서 Apic을 사용해보는 것도 좋은 경험이 될 것이라고 생각합니다!!

Apic - Complete API solution

The only tool you will ever need for all you API Design, Documentation and Testing needs.

chrome.google.com

여기까지 마치고 테스트를 돌렸을 때 프로그램은 정상적으로 잘 동작했습니다.

하지만 한 가지 난관이 더 있었는데, 바로 타이머였습니다.

30초, 혹은 10초가 지나면 턴이 종료되는 부분은 게임 정보이고, 게임 정보는 모두 백엔드에서 관리하고 있어야 한다는 의견에 모두가 동의했기 때문에 현재 남은 시간을 처리하기 위해서 Timer를 사용해야 했습니다.

그래서 하나의 방에는 타이머 변수를 담은 무언가가 필요했고, Room Entity 안에 Timer객체를 넣어서 사용하는 방식을 채택하게 되었습니다.

이 요소는 프론트엔드에서의 setTimeout과 비슷하게 동작했기 때문에 이해 자체는 크게 어렵지 않았습니다.

(Redis를 사용했다면 Timer 객체를 별도로 관리해야 할 것 같아서 더욱 어려웠을 것이라고 생각합니다!!)

이제 이 타이머변수에다가 게임 내 Phase가 지날 때마다 변경시키고, 현재 Phase 자체를 변경시키는 부분을 담아두었습니다.

제가 짠 코드가 완벽하지 않은 부분 중 하나인데, 여기서 특정 시간 이후에 작동하도록 만들어놓은 함수가 간혹 오류가 발생하여 제대로 초기화가 되지 않는 경우가 발생했습니다.

이 부분은 아마도 프론트엔드의 비동기 문제와 동일한 맥락에서 발생한 문제라고 생각됩니다.

SocketController

RoomRepository 내 startTimer 메서드

타이머 처리까지 완료가 되고 나서는 백엔드에서 제가 맡은 임무가 종료되어서 프론트엔드로 넘어갔습니다.

(물론 QA과정에서 발생하는 백엔드 에러 수정은 프로젝트 종료시까지 계속되었습니다!)

프론트엔드에서는 메인 페이지, 랭킹 페이지, 게임 내 일부 기능(채팅 등), FAQ 페이지를 맡아서 진행했습니다.

사용해보고 싶었던 grid도 직접 적용해보았고, 스크롤 처리 문제도 직접 해결할 수 있었습니다.

특히나 인상깊었던 부분이 예전 프로젝트에서도 똑같이 겪었던

"너비가 넓으면 가운데 정렬하되 맨 앞부터 보이게 하는 문제"

를 해결한 것이었습니다.

랭킹의 오늘의 NFT 거래 파트에서는 flex를 사용했는데, 어떤 속성을 만져야할 지에 대해서 고민을 많이 했었습니다.

한참을 고민하고 검색하던 중 StackOverflow에서 같은 고민을 하다가 해결한 분의 메시지를 보고 원하는 대로 구현을 할 수 있었습니다.

Safe center라는 조건을 처음 알았습니다.. 정말로...

Can't scroll to top of flex item that is overflowing container

In attempting to make a useful modal using flexbox, I found what seems to be a browser issue and am wondering if there is a known fix or workaround -- or ideas on how to resolve it. The thing I'm t...

stackoverflow.com

Normal Center일 때 모습

Safe Center일 때 모습

3. 종합

처음으로 맡는 백엔드 작업이었기 때문에 설레기도 했고, 어렵기도 했습니다만 정말로 재미있게 프로젝트를 진행할 수 있었습니다!

프로젝트 초반부에 팀원의 수가 줄어들었고, 사정상 프로젝트에 많은 시간을 할애할 수 없는 팀원이 있었기에 팀 내 유일한 풀타임 백엔드 개발자로서 부담감이 다소 늘어났지만, 오히려 '내가 할 부분이 많아졌다는 점에서 재미있겠다' 라고 느낄정도로 열정적으로 프로젝트에 임할 수 있었습니다.

다만 쪼오금 아쉬웠던 점은 위에서 언급한 대로 같이 Backend를 맡게 된 팀원들 중 1명은 온전히 시간을 쏟을 수 없었던 상황이었고, 1명은 프로젝트 사정상 Smart Contract로 할당되어야 했기 때문에 대부분의 문제에 있어서 혼자서 난관을 헤쳐나가야 했던 부분입니다.

사수의 중요성을 뼈저리게 느낄 수 있었습니다 ㅠㅠ

그래도 Java, Spring Boot, MySQL, JPA 등 프론트엔드 개발자가 쉽게 접하기 힘든 백엔드적인 요소들에 대해서 정말로 많이 부딪히면서 배우게 되었다는 것입니다.

이번 도전이 아니었다면 또 언제 Spring Boot를 이용해서 이정도 규모의 프로젝트에서 백엔드 부분을 맡아서 진행할 수 있을까요 ㅎㅎ

아쉽게도 본상 수상에는 실패했지만 NFT에 대해서 많이 알게 되었고, 백엔드 개발자가 고민할 수 있는 부분에 대해서도 많이 고민할 수 있었고, 코드리뷰와 주간테크톡을 통해서 학습적인 부분도 충분히 챙겨갈 수 있었기에 정말로 만족스러운 프로젝트였습니다!!

4. 애플리케이션 화면 사진

게임 내 카드 제출

게임 내 카드 선택

게임 결과

내 카드 확인

그림 생성

NFT 카드 거래소

이달의 그림 투표

랭킹페이지

FAQ 페이지

5. 참고 자료 및 기술 스택 관련 자료

GitHub Flow

Git/GitHub 안내서 - GitHub Flow

subicura.com

Spring Data JPA

Spring Data JPA, part of the larger Spring Data family, makes it easy to easily implement JPA based repositories. This module deals with enhanced support for JPA based data access layers. It makes it easier to build Spring-powered applications that use dat

spring.io

Redis

Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache, and message broker

redis.io

Timer (Java Platform SE 7 )

Schedules the specified task for repeated fixed-rate execution, beginning at the specified time. Subsequent executions take place at approximately regular intervals, separated by the specified period. In fixed-rate execution, each execution is scheduled re

docs.oracle.com

STOMP

STOMP is a very simple and easy to implement protocol, coming from the HTTP school of design; the server side may be hard to implement well, but it is very easy to write a client to get yourself connected. For example you can use Telnet to login to any STO

stomp.github.io

sockjs

SockJS-node is a server counterpart of SockJS-client a JavaScript library that provides a WebSocket-like object in the browser. SockJS gives you a coherent, cross-browser, Javascript API which creates a low latency, full duplex, cross-domain communication.

www.npmjs.com

[SSH] MobaXterm으로 편하게 SSH 원격 접속하기

Ssoco — Wed, 14 Sep 2022 15:17:29 +0900

저번 프로젝트동안 알차게 썼던 MobaXterm이었는데, 이번에는 아예 백엔드 및 서버 파트를 담당하게 되었기 때문에 서버에 접속하게 될 일이 훨씬 많아질 것 같아서, 사용법에 대해서 간단하게 정리해보려고 합니다.

Windows 환경에서 설명하는 점 참고 부탁드리겠습니다 :)

0. MobaXtrem 다운로드 받기

기존에는 서버에 접속하기 위해서 PuTTY만 사용했었습니다.

몇 년 전에도, 지금도 PuTTY가 업계 1위인건 맞는 것 같습니다만.. ㅋㅋㅋㅋㅋ

Download PuTTY - a free SSH and telnet client for Windows

Is Bitvise affiliated with PuTTY? Bitvise is not affiliated with PuTTY. We develop our SSH Server for Windows, which is compatible with PuTTY. Many PuTTY users are therefore our users as well. From time to time, they need to find the PuTTY download link. W

www.putty.org

하지만 저번 프로젝트를 통해서 MobaXterm이라는 새로운 친구를 만나게 되었고, 보다 편리하게 서버에 접속할 수 있게 되었습니다.

(아무것도 안하고 있으면 나오는 귀여운 펭귄은 덤)

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing - includes X server, enhanced SSH client and much more!

mobaxterm.mobatek.net

위 페이지에 접속해서 Home Edition을 받으면 무료로 사용할 수 있습니다.

(필요하시다면 Professional Edition도 69달러..)

간단하게 다운로드 받은 후에 압축을 풀고 msi 확장자를 가진 프로그램을 실행해서 깔아줍니다.

다 설치하고 켜면?

짜잔~ MobaXterm 화면이 등장했습니다!

제가 기존에 사용하던 PuTTY 세션들도 자동으로 등록된 모습도 확인이 가능하네요!

1. SSH로 접속하기

왼쪽 위의 Session 버튼을 클릭해줍시다!

그러면 다양한 세션 세팅 화면이 나오는데, 우리는 SSH를 통해 연결할 것이므로 SSH를 눌러줍시다!

그렇다면 아래 SSH 화면이 뜨게 됩니다.

우리가 만져야 하는 부분은 Remote host부분인데, 이 부분에는 접속하려는 서버의 Public IP 혹은 도메인 이름을 입력하면 됩니다.

만약 서버에 접속해서 바로 특정 유저로 로그인하는 경우 Remote host에 아이디@ip(혹은 도메인) 형식을 입력해주시면 되겠습니다!

(자주 사용하는 유저네임이라면 오른쪽에 있는 Specify username을 체크하고 따로 입력해줄 수 있습니다. 비밀번호가 있는 경우 오른쪽 사람+열쇠버튼을 눌러서 등록해둘 수 있습니다!!)

만약 키 파일이 따로 있는 경우에는 아래에 Use private key 박스가 있습니다.

이걸 체크하고 해당하는 .pem파일을 등록해주시면 되겠습니다!

여기까지 마치고 OK버튼을 누르면?

바로 접속이 되는 모습을 보실 수 있습니다!

저는 Ubuntu 20.04 서버를 사용하고 있기 때문에 해당 서버에 잘 접속이 된 모습을 볼 수 있습니다.

PuTTY를 사용하던 시절보다 뭔가 설정하기도 편하고 접속하기도 쉬워진 것 같아요 ㅎㅎ

2. 참고자료

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing - includes X server, enhanced SSH client and much more!

mobaxterm.mobatek.net

[Linux] SSH 원격 접속 툴 - MobaXterm 설치 방법&사용법

안녕하세요. 오늘은 SSH 원격 접속 툴 - MobaXterm 설치 방법&사용법에 대해 알아보도록 하겠습니다. 해당 툴은 PuTTY와 FileZilla를 한꺼번에 사용할 수 있는 툴이고 PuTTY보다 가독성이 좋습니다. 사용법

jeeu147.tistory.com

[터미널] MobaXterm 설치법, 사용법

서버에 접속할 때 많이 쓰는 프로그램에는 'Putty'가 있다. 여러 파일들을 vi에디터로 수정/관리해야하는 경우 'Putty'만으로는 한계가 있기 때문에 'MobaXterm'을 추천한다. 'MobaXterm'은 'Putty', Xwindows환

whiteramen.tistory.com