[Kotlin] 모든 클래스가 정의해야 하는 메서드 toString, equals, hashCode

Kotlin

[Kotlin] 모든 클래스가 정의해야 하는 메서드 toString, equals, hashCode

sh1mj1 2024. 1. 9. 20:11

Kotlin in Action 을 공부하고 Effective kotlin 의 내용을 조금 참조하여 정리한 글입니다.

이미지 출처            https://commons.wikimedia.org/wiki/File:Kotlin_Icon.svg

자바와 마찬가지로 코틀린 클래스도 `toString`, `equlas`, `hashCode` 등을 오버라이드 할 수 있다.

이런 메서드들을 알아보면서 아래 `Client` 라는 클래스를 만들어서 예제에 사용하자.

class Client(val name: String, val postalCode: Int)

toString(): 문자열 표현

자바처럼 코틀린의 모든 클래스도 인스턴스의 문자열 표현을 얻을 방법을 제공한다.

주로 디버깅과 로깅 시 이 메서드를 사용한다.

기본 제공되는 객체의 문자열 표현은 `Client@5e9f23b4` 같은 방식이다.

이는 디버깅, 로깅 시 유용하지 않으며, `toString()` 메서드를 오버라이드해서 구현을 바꿀 수 있다.

class Client(val name: String, val postalCode: Int){
    override fun toString(): String = "Client(name='$name', postalCode=$postalCode)"
}

@Test
fun testToString() {
    val client = Client("sh1mj1", 4122)
    assert(client.toString() == "Client(name='sh1mj1', postalCode=4122)")
}

`toString` 에 대해 더 알아보자.

oracle 문서 에서 java 의 `toString` 에 대한 설명이다.

`클래스명@16진수_hashCode`를 반환한다. 그래서 기본 구현된 `toString` 을 호출하면 `Client@5e9f23b4` 와 같은 형태가 나오는 것이다.

`toString` 메서드는 오브젝트를 텍스트로 나타내고, 사람이 읽기 좋은 좋은 결과를 반환해야 한다.

모든 클래스가 이 메서드를 오버라이딩 하는 것을 권장하고 있다.

JVM 호출에서 stable 하게 유지될 필요도 없는 메시지이기 때문에, 실제로 로직에 사용하는 게 아닌 개발자가 읽기 위한 용도라는 것이다.

예를 들어 어떤 프로그램이 간단한 MVC 패턴으로 구현되어 있다면, View 에서 Model 의 출력을 위해 Model 에 해당하는 클래스의 `toString` 을 호출하는 방법이 권장되지 않는다.

이에 대해서는 우테코 `toString` 이라는 키워드로 구글링하면 많은 자료가 나온다.

hashCode 는 더 아래에서 설명하겠다.

equals(): 객체의 동등성

만약 `Client` 의 두 인스턴스를 아래처럼 두 개 만들었다고 하자.

@Test
fun testEquals() {
    val client1 = Client("sh1mj1", 4122)
    val client2 = Client("sh1mj1", 4122)
    assert(client1 != client2)
}

`client1` 와 `client2` 는 서로 다른 객체이다.

그래서 당연히 두 객체가 동일하지 않다.

그런데 `name` 과 `postalCode` 는 동일하다.

우리가 `name` 과 `postalCode` 가 동일하다면, 같은 객체라고 판단하고 싶다면?

우리는 `equals` 를 오버라이드하여 이를 구현할 수 있다.

코틀린과 자바의 동등성 연산

먼저 `equals` 를 새로 구현해보기 전에 코틀린과 자바의 동등성 연산에 대해 간단한 표를 통해 알아보고 넘어가자.

참조 타입(원시 타입이 아닌)을 비교할 때	Java	Kotlin
equality(동등성) 비교 두 객체의 동등성을 비교한다 structural equality(구조적 동등성)이라고도 함	`equals`	`==` 내부적으로 equals 를 호출해서 객체를 비교 `equals` 를 `override` 하지 않으면 기본은 참조 비교임!
reference comparision (참조 비교) 두 피연산자의 주소가 같은지 비교한다. referential equality(래퍼런스적 동등성) 이라고도 함	`==`	`===`

client 에 equals() 구현

class Client(val name: String, val postalCode: Int) {
    override fun equals(other: Any?): Boolean {
        if (other == null || other !is Client) {
            return false
        }
        return name == other.name && postalCode == other.postalCode
    }
    override fun toString(): String = "Client(name='$name', postalCode=$postalCode)"
}

`Any` 는 java 의 `Object` 에 대응하는 클래스로, 모든 클래스의 최상위 클래스이다.

위에서 `(other == null || other !is Client)` 는 `(other !is Client)` 로 간단히 써도 된다. 이는 나중에 다른 글에서 설명하겠다.

이제 다른 `Client` 객체와 비교할 때 프로퍼티의 값이 서로 (`name` 과 `postalCode` 의 값이) 같으면 같다고 판단한다.

물론 일부 프로퍼티만 서로 같을 때 같다고 판단하도록 구현할 수도 있다.

이렇게 구현해주면 이제 테스트 코드에서 `client1 == client2` 가 된다.

@Test
fun testEquals() {
    val client1 = Client("sh1mj1", 4122)
    val client2 = Client("sh1mj1", 4122)
    assert(client1 == client2)
}

참고로, `equals` 는 기본적으로 `Any` 에 구현되어 있다.

그래서 모든 객체에서 사용할 수 있다.

하지만 연산자를 사용해서 다른 타입의 두 객체를 비교하는 것은 할 수 없다.

물론 두 타입이 상속 관계를 갖는 경우에는 비교할 수 있다.

@Test
fun `equals 사용과 == 사용`() {
    assertFalse { Animal().equals(Book()) } // 가능
    assertFalse { Animal() == Cat() } // 가능
//  assertFalse { Animal() == (Book()) } // ERROR Operator '==' cannot be applied to 'Animal' and 'Book'
}

그런데 `Client` 클래스로 더 복잡한 작업을 하다보면 제대로 동작하지 않는 경우가 생긴다.

왜 그럴까? 바로 `hashCode` 가 없기 때문이다.

`hachCode` 를 알아보기 전에 먼저 `equals` 컨벤션에 대해 더 자세히 알아보자.

equals 의 컨벤션

`equals` 에는 위처럼 주석이 달려있다.

어떤 다른 객체가 이 객체와 같은지(equal to) 확인할 때 사용한다. 구현은 아래 요구사항을 충족해야 한다.
- Reflexive(반사적) 동작: `x` 가 non-null 이면 `x.equals(x)` 는 `true` 이다.
- Symmetric(대칭적) 동작: `x`, `y` 가 non-null 이면, `x.equals(y)` 와 `y.equals(x)` 는 같다.
- Transitive(연속적) 동작: `x`, `y`, `z` 가 non-null 이고, `x.equals(y)` 와 `y.equals(z)` 가 `true` 이면, `x.equals(z)` 도 `true` 이다.
- Consistent(일관적): `x`, `y` 가 non-null 이면, `x.equals(y)` 는 항상 같은 결과를 리턴한다.
- null 과 다름: `x` 가 non-null 이면 `x.equals(null)` 은 `false` 이다.'

위 요구사항은 자바에서부터 정의된 내용이다.

Reflexive(반사성) 컨벤션 위반

/**
 * Reflexive 하지 않은 equals 구현의 예
 */
class Time(
    val millisArg: Long = -1,
    val isNow: Boolean = false,
) {
    val milis: Long
        get() =
            if (isNow) System.currentTimeMillis()
            else millisArg

    override fun equals(other: Any?): Boolean =
        other is Time && milis == other.milis
}

@RepeatedTest(10000)
fun `Time 의 equals 를 10000 번 테스트`() {
    val now = Time(isNow = true)
    assertTrue { now == now } // 가끔 false 일 때도 있음.
}

위 코드에서는 `now == now` 즉, `now.equals(now)` 이 `true` 가 아닐 때도 생긴다.

그렇다면 `Time` 을 어떻게 수정해야 할까?

'객체가 현재 시간을 나타내는가?' 를 확인하고, 그렇지 않다면, '같은 타임스탬프를 갖고 있는가?' 로 동등성을 확인하면 된다.

위는 태그 클래스의 고전적인 예이므로 태그 클래스보다는 클래스 계층 구조를 사용해서 해결하는 것이 좋다.

`sealed class FixedTime` 를 상속하는 `TimePoint` 와 `FixedTime`

sealed class FixedTime
class TimePoint(val millis: Long) : FixedTime() {
    override fun equals(other: Any?): Boolean {
        if (other !is TimePoint) {
            return false
        }
        return millis == other.millis
    }
}

class Now : FixedTime() {
    val millis = System.currentTimeMillis()
    override fun equals(other: Any?): Boolean {
        if (other !is Now) {
            return false
        }
        return millis == other.millis
    }
}

@RepeatedTest(100_000) 
fun `FixedTime 의 equals 를 100_000 번 테스트`() { // 항상 통과: Reflexive 하다.
    val now1 = TimePoint(1300)
    assertTrue { now1 == now1 }

    val now2 = Now()
    assertTrue { now2 == now2 }
}

Symmetric(대칭성) 컨벤션 위반

class Complex(val real: Double, val imaginary: Double) {
    override fun equals(other: Any?): Boolean {
        if (other is Double) {
            return imaginary == 0.0 && real == other
        }
        return other is Complex &&
                real == other.real &&
                imaginary == other.imaginary
    }
}

@Test
fun testComplex() {
    val complex = Complex(1.0, 0.0)
    assertTrue(complex.equals(1.0))
    assertTrue((1.0).equals(complex)) // FAIL
}

위 코드대로라면 `Double` 은 `Complex` 와 비교할 수 없다.

그래서 `equals` 에 대해 순서에 따라서 결과가 달라진다.

다른 클래스는 아예 동등하지 않게 만들어버리는 것이 좋다.

Transitive(연속성) 컨벤션 위반

open class Date(val year: Int, val month: Int, val day: Int) {
    override fun equals(other: Any?): Boolean = when (other) {
        is DateTime -> this == other.date
        is Date -> other.year == year && other.month == month && other.day == day
        else -> false
    }
    // ...
}

class DateTime(val date: Date, val hour: Int, val minute: Int, val second: Int) :
    Date(date.year, date.month, date.day) {
    override fun equals(other: Any?): Boolean = when (other) {
        is DateTime -> other.date == date && other.hour == hour && other.minute == minute && other.second == second
        is Date -> date == other
        else -> false
    }
    // ...
}

@Test
fun testDateAndDateTime() {
    val o1 = DateTime(Date(1992, 10, 20), 12, 30, 0)
    val o2 = Date(1992, 10, 20)
    val o3 = DateTime(Date(1992, 10, 20), 14, 45, 30)

    assertTrue { o1 == o2 }
    assertTrue { o2 == o3 }
    assertFalse { o1 == o3 } // transitive(연속적으로) 동작하지 않음
}

`DateTime` 과 `Date` 를 비교할 때 보다 `DateTime` 과 `DateTime` 을 비교할 때 더 많은 프로퍼티를 확인한다는 문제점이 있다.

그래서 날짜가 같지만 시간이 다른 두 `DateTime` 객체를 비교하면 `false` 이지만, 이것들을 날짜가 같은 `Date` 객체를 비교하면 `true` 가 나온다.

위 코드에서는 `DateTime` 이 `Date` 를 상속하고 있다.

처음부터 상속 대신 합성을 사용하고, 두 객체를 아예 비교하지 못하게 만드는 것이 좋다.

상속 대신 합성을 사용하는 `FixedDate`, `FixedDateTime`

class FixedDate(val year: Int, val month: Int, val day: Int) {
    override fun equals(other: Any?): Boolean {
        if (other !is FixedDate) {
            return false
        }
        return year == other.year && month == other.month && day == other.day

    }
}

class FixedDateTime(val date: FixedDate, val hour: Int, val minute: Int, val second: Int) {
    override fun equals(other: Any?): Boolean {
        if (other !is FixedDateTime) {
            return false
        }
        return date == other.date && hour == other.hour && minute == other.minute
    }
}

@Test
fun testFixedDate() {
    val o1 = FixedDateTime(FixedDate(1992, 10, 20), 12, 30, 0)
    val o2 = FixedDate(1992, 10, 20)
    val o3 = FixedDateTime(FixedDate(1992, 10, 20), 14, 45, 30)

    assertTrue { o1.date == o2 }
    assertTrue { o2 == o3.date }
    assertFalse { o1 == o3 }
    assertTrue { o1.date == o3.date }
}

Consistent(일관성) 컨벤션 위반

원칙을 위반하는 대표적인 예로 `java.net.URL.equals()` 가 있다.

`java.net.URL` 객체 2개를 비교하면 동일한 IP 주소로 해석될 때는 `true`, 아닐 때는 `false` 가 나온다.

이 결과는 네트워크 상태에 따라서 달라진다는 것이 문제이다.

@Test
fun testUrl() {
    val enWiki = URL("https://en.wikipedia.org/")
    val wiki = URL("https://wikipedia.org/")
    assertTrue { enWiki == wiki }
}

위의 `enWiki` 와 `wiki` 는 두 주소가 같은 IP 주소를 나타내므로 테스트가 통과된다.

하지만 인터넷 연결이 끊겨 있으면 테스트에 실패한다.

동등성이 네트워크 상태에 의존한다는 것은 잘못된 것이다.

설계의 문제점
- 동작이 일관되지 않음. 네트워크 상태에 따라 결과가 달라짐.
- 일반적으로 `equals` 는 빠를 것이라 예상하지만, 네트워크 처리는 굉장히 느림.
- 동작 자체에 문제가 있음. 동일한 IP 주소를 갖는다고 동일한 컨텐츠를 나타내는 것은 아님.
  virtual hosting(가상 호스팅)을 한다면, 관련 없는 사이트가 같은 IP 주소를 공유할 수도 있음.
  이러한 경우에도 `java.net.URL` 의 `equals` 는 `true` 를 리턴함.

코틀린/JVM 또는 다른 플랫폼을 사용할 때는 `java.net.URL` 이 아닌 `java.net.URI` 를 사용해서 이런 문제를 해결한다.

특별한 이유가 없는 이상, 직접 `equals` 를 구현하는 것은 좋지 않다.

만약 직접 구현해야 한다면, Relexitive(반사적), Symmentric(대칭적), Transtive(연속적), Consistent(일관적) 인 동작을 하는지 확인하자.

이러한 클래스는 `final`(not `open`) 로 만들어서 사용하는 것이 좋으며, 만약 `final` 로 하지 않고 상속을 한다면, 그 하위 클래스에서 `equals` 가 동작하는 방식을 `override` 하면 안된다!

equals 를 직접 구현해야 하는 경우
- 기본적으로 제공되는 동작과 다른 동작을 해야 할 때
- 일부 프로퍼티만으로 비교해야 할 때
- `data` 키워드를 붙이고 싶지 않거나, 비교해야 할는 프로퍼티가 기본 생성자에 없을 때 (data class 에 대한 설명 참고)

hashCode(): 해시 컨테이너

이제 `hashCode` 에 대해 살펴보자.

자바에서는 `equals` 를 오버라이드 할 때 반드시 `hashCode` 도 오버라이드 해야 한다.

실제로 위에서 만들었던 `Client` 코드를 보면 컴파일러가 아래와 같은 warning 을 표시해준다.

Class has 'equals()' defined but does not define 'hashCode()'
클래스가 equals 를 정의했는데 hashCode 는 정의하지 않아요..

먼저 아래와 같은 테스트를 돌려보자.

@Test
fun testContains() {
    val set = hashSetOf(Client("sh1mj1", 4122))
    assertTrue { set.contains(Client("sh1mj1", 4122)) } // FAIL
}

이상하게 테스트가 실패한다.

이는 `Client` 클래스가 `hashCode` 메서드를 정의하지 않았기 때문이다.

JVM 언어에서는 "`equals()` 가 `true` 를 리턴하는 두 객체는 반드시 같은 `hashCode()` 를 리턴해야 한다." 라는 제약이 있다.

위에서 `set` 은 `HashSet` 이며, 이는 원소를 비교할 때 비용을 줄이기 위해 먼저 객체의 hash code 를 비교하고, 만약 같다면 실제 값을 비교한다.

위에서는 hash code 가 서로 다르기 때문에 집합에 들어있지 않다고 판단한 것이다.

Hash Table(해시 테이블)

`hashCode` 함수는 수많은 컬렉션과 알고리즘에 사용되는 자료 구조인 hash table(해시 테이블)을 구축할 때 사용된다.

어떤 컬렉션에 요소를 빠르게 추가, 탐색해야 한다고 하자.

이 때 `Set` 과 `Map` 을 사용할 수 있다.

이 둘은 중복을 허용하지 않기 때문에 동일한 원소가 이미 들어있는지 확인해야 한다.

배열이나 `LinkedList` 를 기반으로 만들어진 컬렉션은 탐색 성능이 나쁘다.

원소가 포함되어 있는지 확인할 때마다 모든 원소와 비교해야 하기 때문이다.

해시 테이블을 사용한다면 성능이 더 좋아질 수 있다.

해시 테이블은 각 원소에 숫자를 할당하는 해시 함수를 사용하며 이 함수는 같은 원소라면 항상 같은 숫자를 리턴한다.

이미지 출처: dEpayse 님의 meduim 글 https://medium.com/depayse/kotlin-data-structure-hashtable-ebb9f949e936

해시 함수는 각 요소에 특정한 숫자를 할당하고, 이를 기반으로 요소를 다른 bucket(버킷, 통) 에 넣는다.

같은 요소는 항상 동일한 버킷에 넣는다.

버킷은 버킷 수와 같은 크기의 배열인 해시 테이블에 보관된다.

즉, 요소를 추가할 때는, 해시 함수로 버킷을 계산하고, 이 버킷 안에 요소를 추가한다. (버킷은 배열처럼 구현됨)

요소 탐색 시에는, 해시 함수로 만들어지는 숫자를 사용하여 버킷을 찾고, 버킷 내부에서 원하는 요소를 찾는다.

이 때 다른 버킷을 확인할 필요가 없어 탐색이 빨라진다.

코틀린/JVM 의 기본 `Set` 인 `LinkedHashSet` 와 기본 `Map` 인 `LinkedHashMap` 도 이를 사용한다.

코틀린은 hash code 를 만들 때 `hashCode` 함수를 사용한다.

해시 테이블 개념은 컴퓨터 과학에서 매우 많이 사용된다.

이 자료 구조에 대해서도 내용이 많기 때문에 나중에 따로 정리하겠다.

더 자세히는 dEpayse 님, 망나니개발자님의 글을 참조하면 좋을 것이다.

Hash Code 와 가변성

hash code 는 요소가 추가될 때만 계산되고, 요소가 변경되어도 hash code 를 새로 계산하지 않으며, 버킷도 재배치되지 않는다.

그래서 `LinkedHashSet` 과 `LinkedHashMap` 의 키는 한 번 추가한 요소에 대해 그 요소 객체를 수정하면, 해시 컨테이너가 제대로 동작하지 않게 된다.

따라서 `Set` 의 요소나, `Map` 의 키로 mutable 요소를 사용하면 안되며, 사용하더라도 요소를 변경하면 안된다.

그래서 immutable 한 객체를 많이 사용한다.

hashCode 의 컨벤션

코틀린 1.3.11 기준으로 `hashCode` 의 공식 컨벤션을 정리해보면

어떤 객체를 변경하지 않았다면 `hashCode` 는 여러 번 호출해도 그 결과가 항상 같아야 한다.
- 일관성 유지를 위해 `hashCode` 가 필요함
`equals` 메서드의 실행 결과로 두 객체가 같다고 나온다면, `hashCode` 메서드의 호출 결과도 같다고 나와야 한다.
- `hashCode` 는 `equals` 와 같이 일관성 있는 동작을 해야 한다.
  즉, 같은 원소는 반드시 같은 해시 코드를 가져야 한다.

그래서 코틀린은 `equals` 구현을 오버라이드할 때 `hashCode` 도 함께 오바리이드 하는 것을 추천한다.

필수 요구사항은 아니지만 제대로 사용하려면 지켜야 하는 요구사항도 있다.

`hashCode` 는 최대한 원소를 넓게 퍼뜨려야 한다.

만약 많은 원소가 같은 버킷에 배치된다면 해시 테이블을 사용하는 이유 자체가 없어진다.

아래와 같은 극단적인 예를 살펴보자.

`Proper` 과 `Terrible`

class Proper(val name: String) {
    override fun equals(other: Any?): Boolean {
        equalsCounter++
        return other is Proper && name == other.name
    }
    override fun hashCode(): Int {
        return name.hashCode()
    }
    companion object {
        var equalsCounter = 0 // equals 가 호출되는 횟수 확인하기
    }
}

class Terrible(val name: String) {
    override fun equals(other: Any?): Boolean {
        equalsCounter++
        return other is Terrible && name == other.name
    }
    override fun hashCode(): Int = 0 // BAD CODE
    companion object {
        var equalsCounter = 0 // equals 가 호출되는 횟수 확인하기
    }
}

테스트 코드

@Test
fun testProper() {
    val properSet = List(10000) { Proper("$it") }.toSet()
    println(Proper.equalsCounter) // 0. 
    // 모두 다른 bucket 에 들어가서 equals 를 호출할 필요가 없었다.
    
    val terribleSet = List(10000) { Terrible("$it") }.toSet()
    println(Terrible.equalsCounter) // 50116443.
    // 모두 같은 bucket 에 들어가서 equals 를 많이 호출한다.
    
    println()

    Proper.equalsCounter = 0
    println(Proper("9999") in properSet) // true
    println(Proper.equalsCounter) // 1 // 9999 로 만들어진 해시코드에 매칭되는 bucket 을 찾고, equals 를 호출
    println()

    Proper.equalsCounter = 0
    println(Proper("A") in properSet) // false // "A" 로 만들어진 해시코드가 없기 때문에 equals 호출하지 않아도 false 임을 안다
    println(Proper.equalsCounter) // 0
    println()

    Terrible.equalsCounter = 0
    println(Terrible("9999") in terribleSet) // true
    println(Terrible.equalsCounter) // 7535 // 모든 해시코드가 같아 모든 데이터가 한 bucket 에 있어서 equals 를 많이 호출
    println()

    Terrible.equalsCounter = 0
    println(Terrible("A") in terribleSet) // false
    println(Terrible.equalsCounter) // 10001
}

위 테스트에서 각 `equalsCounter` 를 비교해보면 굉장히 큰 차이가 난다.

버킷 충돌 등의 문제로 `Terrible` 의 `equalsCounter` 에는 굉장히 큰 값이 된다.

hashCode 구현하기

이렇게 간단히 `hashCode` 와 hash table 을 알아보았다.

그렇다면 `hashCode` 를 어떻게 구현해야 할까?

기본적으로 `equals` 에서 비교에 사용되는 프로퍼티를 기반으로 hash code 를 만들어야 한다.

일반적으로 모든 해시 코드의 값을 더하며, 더하는 과정마다 이전까지의 결과에 31을 곱한 뒤에 더해준다. (관례적으로 31을 자주 사용. 꼭 31 일 필요는 없음)

class Client(val name: String, val postalCode: Int) {
    // ...
    override fun hashCode(): Int {
        var result = name.hashCode()
        result = result * 31 + postalCode.hashCode()
        return result
    }
}

이렇게 되면 `testContains` 테스트가 예상대로 통과된다.

이렇게 클래스에 정의해야 하는 메서드 `toString`, `equals`, `hashCode` 를 알아보았다.

그런데 이렇게 하나하나 직접 메서드를 만들어주는 것은 꽤 피곤한 것 같다.

다음 글에서 이를 해결할 수 있는 코틀린의 좋은 기능을 알아본다.

참조

https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#toString--

https://yeonyeon.tistory.com/188

https://be-student.tistory.com/42

https://medium.com/depayse/kotlin-data-structure-hashtable-ebb9f949e936

https://mangkyu.tistory.com/102

'Kotlin' 카테고리의 다른 글

[Kotlin] 클래스 위임과 by, Decorator(데코레이터) 패턴 (1)	2024.01.10
[Kotlin] data class: toString, equals, hashCode, copy, componentN (0)	2024.01.10
[Kotlin] 인터페이스의 프로퍼티 & 접근자에서 backing field 에 접근, 접근자의 가시성 (1)	2024.01.09
[Kotlin] 주 생성자 & 부 생성자 & 초기화 블록 (1)	2024.01.06
[Kotlin] sealed 로 클래스 계층 확장을 제한하기 + 태그 클래스 VS 상태 패턴 (1)	2024.01.06

현재글[Kotlin] 모든 클래스가 정의해야 하는 메서드 toString, equals, hashCode

공부하고 작업한 내용을 정리하고 기록하는 블로그

boj, 오브젝트, Android, MVC, 코틀린, 자바, 자바 스프링, 백준, db, 코테, 타임리프, 예외, 데이터베이스, Java, 알고리즘, kotlin, 안드로이드, 트랜잭션, 서블릿, 스프링,

Today :
Yesterday :

sh1mj1_log