솔루션 개발자 호™의 블로그

숫자형 Data Type. 그리고 변수와 상수

Joyakdol (조약돌) — Sun, 20 Feb 2022 00:13:59 +0900

Kotlin은 매우 실용적인 프로그래밍 언어이다. 현대의 프로그래밍 언어가 지향하는 방향성은 크게 4가지 정도가 있다. 첫번째가 실용성이다. 프로그래머에게 친숙하고 편리한 언어를 만드는 것을 가장 큰 목적으로 삼는다. 두번째는 엄격성이다. 어찌보면 실용주의적 프로그래밍 언어와 정 반대의 위치를 고수한다고도 볼 수 있다. 모든 것을 가능한 엄격하게 준수해야만 컴파일이 가능하도록 제하하는 언어이다. 이 엄격함 때문에 프로그램이 가져오는 잠재적 오류를 방지할 수 있다는 입장을 표명하는 언어이다. Scala 같은 언어가 대표적으로 엄격성을 지향하고 있다. 세번째는 특정 목적을 위한 언어이다. R과 같은 언어가 대표적이다. 마지막으로 쉬움 그 자체를 지향하는 언어들이 등장하고 있다. 주로 로우코드 개발 프레임워크들이 지향하고 있다.

Kotlin은 실용주의를 표방하고 있다. 보통 실용주의 언어들이 많은 것을 생략하고 복잡한 문법을 단순화하는 것에 많은 노력을 기울이고 있다. 그래서 자칫 잘못하면 무언가 엉성해 보이거나 비합리적인 부분이 갑자기 튀어나오는 경우가 종종 있다. 하지만 Kotlin은 의외로 정교하다고 느껴지는 부분들이 많다. 데이터 타입에서도 그런 부분이 눈에 들어온다.

Kotlin은 크게 총 5 가지로 데이터 타입을 분류할 수 있다. 숫자(numbers), 불리언(boolean), 글자(character), 문자열(string), 배열(array)의 5가지이다.

이번에는 Kotlin의 숫자형 데이터 타입에 대해 알아보자.

1. 정수 Integer Type

Kotlin에서 정수는 정확히 8의 배수로 구분 가능하다. Byte는 8 bit, Short는 16 bit, Int는 32 bit, Long은 64 bit이다. 명확하고 깔끔한 구성이다.

변수의 선언은 매우 단순한다. kotlin에서는 보통 변수 이름 앞에 ‘var’을 붙이는 것으로 변수를 선언한다. 변수를 선언하며 숫자 값을 지정하면 데이터 타입은 기본적으로 Int가 된다. 하지만 값의 크기에 따라서 자동으로 Long을 사용하기도 하며, 명시적으로 숫자 뒤에 ‘L’을 붙여 주면 Long이 된다.

var one = 1 // Int
var threeBillion = 3000000000 // Long
var oneLong = 1L // Long

Byte나 Short를 사용하기 위해서는 명시적으로 지정해주면 된다.

var oneByte: Byte = 1 // Byte

위 예제에서 볼 수 있는 것 처럼 Kotlin은 Java와 다르게 데이터 타입을 변수명 뒤에 콜론(’:’)과 함께 기술한다.

2. 실수 Floating-point Type

실수형은 Java와 다르지 않다. Float은 32 bit, Double은 64bit의 실수형 데이터 타입이다. 변수 초기화 때에 소수점이 포함된 숫자를 지정하면 기본적으로 Double을 사용한다. 초기화 시 Float을 지정하려면 숫자 뒤에 ‘f’나 ‘F’를 붙이면 된다.

var pi = 3.14 // Double
var e = 2.7182818284f // Float

실수는 물론 지수형으로 표기 가능하다. 지수형으로 표기할 경우 Double을 사용한다.

var doubleNumber = 123.4e10 // Double

3. 변수와 상수

Java는 명시적으로 상수를 정의할 수 있는 문법을 제공하지 않는다. 물론 ‘final’ 키워드를 추가하여 상수로 사용할 수 있지만, final은 사실 상수를 정의하는 문법이 아니다. 상속 관계에서 더 이상 Override 할 수 없다는 의미이다. 어렵게 표현한다면(=객체지향 개념으로 표현한다면) 다형적 사용을 금지하는 수정자(modifier)이다.

변수는 앞에서 본 것 처럼 영어로 변수인 Variable에서 앞의 3 글자(’var’)를 사용하여 선언한다. 상수는 아쉽게도 Constant가 아닌 Value의 약자인 ‘val’을 사용하여 선언한다.

val pi = 3.14 // PI 값을 변수가 아닌 상수로 선언

4. 그 외 숫자 표기법

Kotlin은 실용적 언어이기 때문에 역시 다양한 방식의 숫자 표기법을 제공한다.

var oneMillion = 1_000_000 // Int
var creditCarNumber = 1111_2222_3333_4444L // Long
var hexBytes = 0xFF_EC_DE_5E // Int
var bytes = 0b11010010_01101001_10010100_10010010 // Int

16진수는 숫자 앞에 0x를 붙이면 표기 가능하며, 2진수는 0b를 붙여서 가능하다. 또한, 숫자 중간에 언더스코어(’_’) 문자를 추가하여 가독성을 높일 수 있다. 위의 예제에서처럼 2진수를 표기할 때 8글자 마다 언더스코어를 추가하여 1 Byte 씩 구분하여 표기할 수 있다.

5. Null 처리 방식의 개선 Nullable

Kotlin에서 숫자형 변수는 기본적으로 null 값을 가질 수 없다. 이는 Java에서 int나 double과 같은 Primitive 데이터 타입이 null 값을 가질 수 없는 것과 동일하다. 하지만, Kotlin에서는 모든 변수는 Class이다. 그렇기 때문에 논리적으로 null 값을 지정할 수 있어야 한다. 하지만, 숫자의 경우 일반적으로 null 값이 지정되는 것이 일반적인 경우가 아니기 때문에, 오류를 예방하기 위해 기본적으로 null을 허용하지 않는다. null을 허용해야만 하는 경우라면 변수를 선언할 때 명시적으로 null을 사용하겠다고 지정해야만 한다. 지정 방법은 간단하다. 변수 명 뒤에 물음표(’?’)를 붙이면 된다.

var a: Int = 100
var nullableA: Int? = null

6. 명시적 형변환

동일한 숫자를 저장한 변수라고 해도 데이터 타입이 다르면 kotlin은 동일하다고 판단하지 않는다.

var a: Int? = 1
var b: Long? = 1
print(b == a) // 결과는 ‘false’이다.

이와 마찬가지로 Kotlin은 보다 더 작은 데이터 타입을 자동으로 더 큰 데이터 타입으로 변환하지 않는다.

var a: Byte = 1
var b: Int = a // 컴파일 불가

Kotlin은 명시적 형변환이 필요하다. 앞에서 이야기한 것 처럼 Kotlin은 모든 변수가 Class이다. 따라서, 숫자형 변수에도 함수가 존재한다. 바로 숫자형 변수에서 제공하는 함수를 통해 명시적 형변환이 가능하다. 모든 숫자형 변수에서 동일하게 형변환 함수를 제공한다.

var a: Long = 1L
var b: Int = a.toInt()
var c: Byte = b.toByte()
var d: Byte = c.toByte()
var e: Int = b.toInt()

Kotlin은 수식을 처리(컴파일)할 때 왠만해선 명시적 형변환 없이 가능하다. 예를 들어 Long과 Int를 더하면 결과는 Long이 된다.

var a = 1L + 3 // Long + Int => Long

7. 정수 나눗셈

Kotln에서 정수와 정수의 나눗셈 결과는 항상 정수이다. 논리적으로 연산의 결과가 실수인 경우라 해도 Kotlin은 소수 이하를 버리고 정수만 결과로 남긴다.

var x = 5 / 2 // x의 값은 Int 2
var y = 5L / 2 // y의 값은 Long 2
실수 값을 얻기 위해서는 피연산자(operend) 중 최소한 하나 이상이 실수이어야 한다.
var x = 5.0 / 2 // x의 값은 Double 2.5
var y = 5 / 2.toDouble() // x의 값은 Double 2.5

8. 비트 연산(bitwise operation)

Kotlin은 다른 언어들에서 보통 >>나 <<와 같은 연산자를 이용하여 bit 연산을 하는 것과 다르게 비트 연산 전용의 함수를 제공한다.

var x = 1.shl(2).and(0x000FF000)

위의 예제는 숫자 Int 1을 왼쪽으로 2 번(= 2 bit) 쉬프트한 다음 16진수 00 0F F0 00 과 And 연산을 수행한다. 앞에서 이야기했듯이 Kotlin에서 모든 변수는 Class이기 때문에 가능하며, 심지어 숫자도 Class로 다루어지기 때문에 가능해진다.

Kotlin은 또한 비트 연산 함수를 연산자와 같은 형태로 사용할 수도 있다.

var x = (1 shl 2) and 0x00_0F_F0_00 // 위의 예제와 동일하다

9. Unsigned 정수 데이터 타입

Kotlin은 C언어와 같이 Unsigned 정수형을 제공한다. 간단히 각 정수형 데이터 타입 앞에 대문자 ‘U’를 붙이면 된다. 일반적인 경우에는 Unsigned 데이터 타입이 필요가 없지만, 다른 언어로 개발된 시스템과 데이터 교환 시 Unsigned 데이터 타입이 필요한 경우가 종종 발생한다.

var a: UInt = -1 // 컴파일 불가

데이터 타입을 명시적으로 지정하지 않고 단순히 숫자 뒤에 ‘u’나 ‘U’를 붙여서 Unsigned 데이터 타입을 만들 수 있다.

var a = 123u // Unsigned Int
var b = 123UL // Unsigned Long

Package와 Import

Joyakdol (조약돌) — Mon, 14 Feb 2022 23:15:36 +0900

Java에서 소스 파일(*.java)의 첫 줄은 보통 package라는 단어로 시작한다. (사실 소스 파일의 첫 줄은 주석이어야 한다)

Kotlin도 Java와 동일하게 첫 줄은 보통 package로 시작한다. 사용법도 동일해 보인다. 그렇다면 Package 정의 방법은 Java와 동일하다고 언급하고 다음으로 넘어가면 되겠다.

하지만, 다행스럽게도 Java와 다르다. Package가 다르면 얼마나 다르겠냐 싶지만 생각보다 꽤 많이 다르다. 아니 사실 다른 점이 그리 크지는 않다. 하지만, 그 크지 않은 차이점이 생각보다 많은 차이를 만들어낸다.

기본적인 정의 방법은 Java와 완전히 동일하다. ‘org.momo’라는 package를 선언해보자.

package org.momo

숙련된 Java 개발자라면 이 짧은 package 선언문을 보고도 많이 허전해야 한다. 부자연스러움을 느끼지 못했다면 반성해야 한다.

문장 끝에 세미콜론(’;’)이 없다. Kotlin은 세미콜론을 붙여도 되고 안 붙여도 된다. 이것을 좀 더 있어 보이는 말로 바꿔보면 ‘kotlin에서는 세미콜론을 생략 가능하다’ 정도가 된다.

Package 선언에서 Java와 Kotlin이 다른 점은 바로 무엇을 담을 수 있는가이다. Java는 Pakcage에 Class를 담을 수 있다. 물론 Package 속에 Package를 담을 수도 있으며, Class 외에 Interface도 담을 수 있다. 하지만, 결국 Class를 담는 꾸러미가 Package이다.

하지만, Kotlin은 Package에 함수도 담을 수 있다. Java나 C 언어 등에 익숙한 사람은 Package에 함수를 담는다는 것이 도대체 무슨 소리냐고 반문할 수도 있을 것이다.

하지만 Package에 함수를 담다는 다는 것은 사실 매우 단순하다. 빈 소스파일에 Class 정의 같은 것은 필요 없이 그냥 달랑 함수 하나만 작성해도 된다. 다르게 말하면 Kotlin에서는 Class 없는 함수가 존재할 수 있다고 말할 수 있다. ‘이게 왜 필요할까? 굳이 Class 없는 함수를 만들어야 할 이유가 있을까?’라고 머리 속에 물음표 몇 개를 떠올리고 있을 것이다.

Class를 사용하려면 import 해야 한다. 물론 import 하지 않고 전체 Package를 친절하게 모두 적어주면 사용할 수 있지만, 그런 친절함은 당연히 사양해주자. 예를 들어 StringUtil 이라는 Class가 'org.momo.util' 이라는 package에 숨어있다고 가정해보자. 이 녀석을 사용하려면

import org.momo.util.StringUtil

이라고 적어주면 된다. 이렇게 적어주면 우리는 StringUtil 이라는 클래스가 품고 있는 함수를 사용할 수 있다. 만약 ‘org.momo.util’ Package에 여러 개의 아주 자주 사용하는 유틸리티 Class가 담겨 있다면 우리는 보통

import org.momo.util.*

과 같이 한 번에 import 하여 사용할 수 있다.

StringUtil에 'convertA()'라는 함수가 있다면 StringUtil.convertA() 와 같은 형태로 사용 가능하다. 그런데, convertA()라는 함수가 매우 심하게 빈번하게 사용되는 녀석이라면 우리는

import static org.momo.util.StringUtil

과 같이 static import 하여 println() 사용하듯이 (= ‘StringUtil’ 이라는 Class 없이) convertA() 함수를 사용할 수 있다.

그런데, 만약 이와 같은 유틸리티 함수를 Class 속에 집이 넣는 것이 아니고 소스 파일에 그냥 작성할 수 있다면 사용성이 매우 개선된다.

package org.momo.util
fun convert(A) { ... }

와 같이 작성된 Kotlin 소스 파일이 있다면 우리는

import org.momo.util.convertA

하고, Class 없이 convertA() 라고 직접 함수를 호출할 수 있다. 심지어

import org.momo.util.*

와 같이 사용한다면 convertA() 함수와 동일한 소스 파일이 있는 모든 함수를 Class 없이 println() 사용하듯이 사용할 수 있다.

게다가 kotlin은 import할 때 별명을 붙여줄 수도 있다.

import org.momo.util.StringUtil as SU

라고 선언하면 SU.convertA() 와 같이 축약된 형태로 사용할 수 있다.

Kotlin에서는 Class와 함수 외에도 properties, object, enum 상수를 import 할 수 있다. 여기서 주의할 것은 object가 Class로 만든 object가 아니고 object 선언한 것을 지칭한다는 점이다. (좀 헷갈릴 수도 있지만 object도 class의 일종이다. 해당 내용은 추 후 언젠가 다룰 예정이다)

Java 따위는 버리고 Kotlin

Joyakdol (조약돌) — Wed, 5 Jan 2022 00:25:01 +0900

Kotlin 로고

1999년에 Java 개발을 시작했다. 막연히 Java를 사용해온지 오래 되었다고 생각하고 있었는데, 정확한 시간을 떠올려 보니 20년이 훌쩍 넘어선다. 이번에 들어온 풋풋함이 넘치는 신입사원이 20대 중반이다. 그 친구의 평생이라는 시간과 얼추 비슷한 시간만큼 Java와 지내왔다.

여러가지 상황과 유행으로 Java를 사용해왔지만, 나는 자신 있게 이야기할 수 있다. Java는 좋지 못하다. 나와 어느정도 같이 일을 해온 사람들은 잘 알겄이다. 내가 Java에 대해서 좀 과격한 표현으로 성토해왔다는 것을. Java는 한국의 SI 환경에서는 지금도 매우 확고한 위치를 차지하고 있다. 솔직히 그 강력한 영향력을 가지고 있다는 것 때문에 더 마음에 들지 않는 것 같다. 내가 더 Java를 싫어하게 된 가장 큰 이유는 Kotlin 언어 그 자체이다. Kotlin을 접하게 된 후로는 싫어하는 정도가 보통에서 적극적인 싫어함으로 바뀌었다. Java와 비교를 한다고 말하면 Kotlin에게 매우 실례가 되는 것 같다. 아니 확실한 실례이다.

물론 Java가 무조건 좋지 못하고 나쁜 것은 아니다. 20년 이전의 Java는 매우 도전적이고 선구자 적인 언어였다. 그 당시 라이벌이 전혀 없이 독주하던 C와 C++ 언어에 도전하여 당당히 왕좌를 차지한 언어이다.

그렇지만 이를 다른 관점으로 바라본다면 Java는 이미 너무 늙어버린 언어이다. 젊어지기 위해서 지속적으로 노력하여 Closer와 같은 새로운 특성들도 가지게 되었고, 매년 새로운 특성들이 추가된다. 하지만 근간이 되는 특성들은 어쩔 수 없이 그대로 유지될 수 밖에 없었고 그로 인해 신생 언어들과 비교당하고 늙은 취급을 당하는 언어가 되었다. 마치 한 사람의 인생과도 같지 않은가? 젊은 시절엔 누구보다 폐기 있고 모험심 강한 청년이고, 경력이 쌓이고 경륜이 쌓이며 강력한 영향력을 행사하는 위치에 앉게 된다. 하지만 점점 나이가 들어가며 새로 올라오는 젊은이들에게 세대차이를 느끼고 구세대의 표상으로 회자되는 그런 흔하디 흔한 한 사람의 인생 이야기와 같다.

Java가 지금까지 쌓아놓은 업적과 위상은 충분히 칭찬하고 인정하자. 그것이 당연한 예우이다. 하지만, 아닌 것은 분명히 아니라고 말해야 한다. Kotlin도 앞으로 20년이 지난 뒤에는 늙은 언어가 되어있겠지만, 그 것은 20년 뒤에 말해야 할 이야기이다. 지금은 Kotlin이다. 누가 무엇이라고 말하던 나는 분명히 Kotlin에 매료되었다. 그렇다고 당장 내 업무에 Kotlin을 사용할 수 있는 것은 아니다. 애석하게도 거의 대부분의 경우에 언어는 이미 결정되어 있고 앞으로도 그럴 것이다. 거기다 적지 않은 사람들이 새로운 언어를 두려워한다. 보다 정확하게 말한다면 사실 새로운 언어를 두려워한다기 보다 자신이 경험해 보지 못한 새로운 것을 배우고 익혀서 업무에 활용해야 한다는 사실을 두려워한다. 그 외에도 찾아 볼려면 매우 많은 이유들을 댈 수 있겠지만, 어쨌든 당장 내가 해야할 업무에 Kotlin을 사용하는 것은 99.99999999% 확률로 불가능하다.

그래서 개인적으로 프로젝트를 진행하려 계획하였다. 목표는 일종의 개발 플랫폼Platform(혹은 프레임워크Framework)의 창조다. 예전에 만들었던 개발 프레임워크(DynaMOAD)도 시간과 인력의 부족으로 생각했던 수준의 10%도 구현하지 못했었다. 하지만 지금은 혼자서도 천천히 상상했던 녀석을 만들 수 있으리라 생각된다. 그 당시에는 기반 기술들을 거의 직접 만들어야만 했었지만, 지금은 많은 사람들이 그러한 기반 기술들을 매우 훌륭하고 아름답게 만들어서 오픈 소스라는 이름으로 공유하고 있다.

사실 그 ‘계획’을 한지는 수 년이 지났지만 시작을 못하고 있었다. 이제서야 한 발자국을 내딛으려 한다. 그 시작으로 우선 Kotlin을 선택하였다. Kotlin을 공부하고 익히며 정리하여 블로그에 남기려 한다. 만약 기회가 된다면 동영상으로 제작하여 유튜브에도 올려보려 한다. 블로그에서는 가급적이면 인터넷 여기저기에서 쉽게 검색해볼 수 있는 이야기들은 하지 않으려 한다. 내가 이해하고 느낀점을 내 방식대로 풀어가려 한다.

블로그에 정리하고 게시하면 공부하는 속도가 그만큼 늦어지겠지만, 그래야만 하겠다는 생각이다. 20년이 넘게 IT라는 벌판에서 살아왔고 이런 저런 것들을 배우고 익혀왔지만, 다른 이들에게 나눈 것이 별로 없었다. 내가 앞으로 정리해 나갈 것들이 필요한 이들에게 도움이 될 수 있기를 바란다.1999년에 Java 개발을 시작했다. 막연히 Java를 사용해온지 오래 되었다고 생각하고 있었는데, 정확한 시간을 떠올려 보니 20년이 훌쩍 넘어선다. 이번에 들어온 풋풋함이 넘치는 신입사원이 20대 중반이다. 그 친구의 평생이라는 시간과 얼추 비슷한 시간만큼 Java와 지내왔다.

사실 그 ‘계획’을 한지는 수년이 지났지만 시작을 못 하고 있었다. 이제서야 한 발자국을 내딛으려 한다. 그 시작으로 우선 Kotlin을 선택하였다. Kotlin을 공부하고 익히며 정리하여 블로그에 남기려 한다. 만약 기회가 된다면 동영상으로 제작하여 유튜브에도 올려보려 한다. 블로그에서는 되도록 인터넷 여기저기에서 쉽게 검색해볼 수 있는 이야기들은 하지 않으려 한다. 내가 이해하고 느낀 점을 내 방식대로 풀어가려 한다.

블로그에 정리하고 게시하면 공부하는 속도가 그만큼 늦어지겠지만, 그래야만 하겠다는 생각이다. 20년이 넘게 IT라는 벌판에서 살아왔고 이런저런 것들을 배우고 익혀왔지만, 다른 이들에게 나눈 것이 별로 없었다. 내가 앞으로 정리해 나갈 것들이 필요한 이들에게 도움이 될 수 있기를 바란다.

Grails 3 RESTFull Client 설정

Joyakdol (조약돌) — Fri, 22 Jul 2016 16:10:31 +0900

Grails 3에서 RESTfull client를 사용하기 위한 설정 방법.

build.gradle의 dependencies 에 runtime 추가

dependencies {
...
runtime "org.grails.plugins:grails-http-builder-helper:1.0.0"
...
}

API 사용법 : https://github.com/jgritman/httpbuilder/wiki/RESTClient

Plugin Home Page : http://grails.org/plugin/rest

Grails 3 hsql datasource 설정

Joyakdol (조약돌) — Thu, 21 Jul 2016 12:30:46 +0900

Grails 3 에서 hsqldb 를 사용하기 위한 설정 방법.

1. build.gradle의 dependencies 에 runtime 추가

dependencies {
...
runtime "org.hsqldb:hsqldb"
...
}

2. application.yml 에 jdbc 설정 변경

dataSource:
...
driverClassName: org.hsqldb.jdbc.JDBCDriver
dialect: org.hibernate.dialect.HSQLDialect
username: sa
password:
environments:
development:
dataSource:
dbCreate: ...
url: jdbc:hsqldb:file:파일명

jdbc url 은 hsqldb 의 online guide 문서에서 connection url 부분을 참조하여 작성한다.

인터넷으로부터의 공격 - 해킹시도?

Joyakdol (조약돌) — Mon, 20 Aug 2007 15:18:04 +0900

얼마전에 Hacking 시도로 의심되는 무수한 Network 접근 시도가 사무실에서 사용 중인 Linux 장비에 포착되었다.

사실, 별 생각 없이. 그리고 별 탈 없이 잘 사용하고 있던 장비였는데, 어느날 문득 역시 별 생각 없이 Firewall의 Log를 살펴보았다.

이 때 부터 갑작스럽게 머리 회전이 빨라지기 시작하였다. Log에는 상당히 생뚱맞은 Network 접근 시도들이 무수히 기록되어 있었다. 생각하는 속도가 빨라짐과 거의 동시에 손가락을 움직이는 속도도 빨라지기 시작하였다. ("드르륵"은 마우스 휠을 굴리는 소리이다.)

타다다다닥. 타다다다닥. 타다다닥. 드르륵. 드르륵. 타다다닥. 타다다다닥...

이 Linux 장비는 공용(Public) IP Address 영역에 놓여있기 때문에 피부로 느껴지는 심각성은 적지 않았다.

접근 시도를 Port 별로 구분해 본 결과 아래와 같은 표를 얻을 수 있었다.

Port 번호	일반적인 프로토콜
21	FTP
22	SSH
25	SMTP
53	DNS
80	HTTP
137	SMB (Samba)
443	HTTPS
3306	MySQL
1433	MS SQL
4899	R-Admin
5900	VNC
8000	SHOUTcast
8080	Servlet container
10000	WebAdmin
33435	Traceroute

그 중에서도 특히 많은 접근 시도가 있던 것이 MS-SQL과 MySQL 두 가지였다. 이 결과를 보면서 수 개월전에 회사의 MS SQL 서버가 해킹 당했었다는 사실이 떠올랐다.

하루 평균 접근 시도 횟수를 산정해 보니 MS-SQL의 경우 거의 10회에 육박한다. 접근 시도한 시간대를 살펴 보니 상당히 규칙적인 시간 간격을 가지고 접근 시도가 진행된 것으로 보여진다.

whois 명령어를 이용해서 접근해온 지역을 확인해 보았다. 가장 많은 것은 바로 사무실이 위치한 건물 내에서였다. 그 다음은 중국 베이징과 상하이. 간혹 프랑스, 호주나 미국 등지에서부터의 접근 시도가 있었다.

이 건물 내부 IP 주소에서의 접근은 생각보다 심각할 수 있다는 생각이 들었다. 이 건물 내부에 Hacking 공격용 거점으로 사용되는 장비가 몇 대 이상 존재할 가능성이 다분이 높았기 때문이다. 솔직히 다른것 보다 이 건물 Network 속도의 전체적 저하의 원인 제공자가 될 수도 있다는 생각이 들어서 별로 기분지 좋질 못했다.

그래 저 녀석들이 내가 사용하는 네트웍 대역폭(Network Bandwidth)을 잡아먹고 있을 수 있다는 거쥐이~

곧바로 이 건물의 Internet Service 업체에 연락을 했다. 이런 저런 내용을 설명해주니 다른 전화 번호 한 개를 알려준다. '어라? 이거 핑퐁인가?'라는 생각이 들긴 했지만, 딱 한번까지는 노력을 해 주지라는 생각으로 다시 전화기를 들었다.

이번에 받은 사람도 자신이 담당자는 아니란다. 하지만, 자신이 봐 줄 수 있는데 까지는 봐준다고 한다. 내 연락처를 적고나서 살펴본 후 연락을 주겠다고 하고 통화를 끊었다.

얼마 간의 시간이 지난 후 통화했던 사람이 전화를 주었다. '그래도 일을 열심히 하는군'이라는 생각을 하고 있었는데 내 귀로 파고들어오는 목소리는 이런 생각을 여지 없이 무너뜨렸다.

자신의 권한으로는 알 수가 없고 아무런 조치도 할 수가 없으니, 정 문제가 되면 경찰청 사이버 수사대에 신고하란다.

이 때 부터 귀찮아지기 시작했다. 결국 대강 이런 저런 불만사항을 잠깐 이야기 한 후 통화를 끊었다.

하지만, 여기서 끊나면 재미 없지 않겠는가? 마음 속에서 호기심이라는 녀석이 계속 꿈틀대는게 느껴졌다. Linux 장비로 접근해 온 녀석들이 어떤 녀석들인지 간단히만 한번 알아보자라고 생각이 바뀌었다.

일단, Firewall 설정부터 보다 강력하게 바꿔버렸다. 내가 주로 작업하는 다른 장비에서 접근하는 IP 주소만 열고 나머지 모든 IP에서의 접근은 다 막아버렸다. 거기에 더해서 ICMP 접근 까지도 모두 막아버렸다.

그리고 나서 nmap 명령어를 이용하여 이 건물에서 접근한 IP 주소들을 하나씩 확인하기 시작했다. 2 대는 Windows 장비였고 Firewall도 설정되어있지 않았다. 1 대는 Unix 계열로 보였지만 정확한 O/S를 추정하기에는 열려 있는 service가 부족하였다. 그리고 마지막 1 대는 재미 있게도 nmap에서 아무것도 걸리지가 않았다.

어허~ 이 녀석 봐라~ 너가 해보자는거지?

기대했던 것과는 달리 너무 어이 없게도 쉽게 접근이 가능했다. 먼저 80번 포트에 웹서버가 떠 있는지 수작업으로 확인해 보았다. 웹서버가 응답을 하지는 않았지만, 뭔가 낌새가 이상했다. 그래서 curl 명령어로 return 되는 내용을 살펴 보았더니 spam 메일 중계용으로 사용되는 프로그램 하나가 떡 하니 모습을 드러낸다.

이런... 이런 녀석이 이 건물 내에 있으면 네트웍 다 잡아 먹을 텐데...

이 장비는 생각보다 의도가 불순해 보인다. 다른 모든 Port들은 모두 막혀있다. 반응을 보았을 때 해당 Service가 안 떠 있는 것이 아니고 Firewall로 막혀 있다. 그런데, 유일하게 열려 있는 80번 포트에는 전혀 생뚱맞은 녀석이 보금자를 마련해 놓고 있는 것이다. 이 장비가 해킹 당한 것인지, 아니면 의도적으로 스팸 메일 발송(혹은 중계)를 위해 설치된 것인지 판단하기가 모호하다. 그렇다고 내가 역으로 해킹을 하기는 너무나도 귀찮고...

지금 아주 조금 갈등이 생기고 있다. 신고를 해야 하나 말아야 하나...

JDK 6 update 2 (Java 1.6.0_02) 발표 내용 정리

Joyakdol (조약돌) — Tue, 24 Jul 2007 21:20:45 +0900

몇 주 전에 JDK 6 (Java 1.6.0) 의 수정 버전인 update 2 가 발표 되었다. 사실, 발표 된 당일에 간단하게라도 내용을 정리하려고 마음을 먹었었지만, 이런 저런 핑계거리와 게으름에 발목을 잡혀 지금에서야 끄적거린다.

Release note를 살펴보면 기대에 부합되게도 새롭게 추가 된 기능은 단 한 개도 찾아 볼 수 없다.

솔직히 이야기 하면 Release note의 상당히 앞 쪽에 위치한 "Java DB"에 대한 부분에서 이번 update에 새로 추가된 것인 줄로 착각을 했었다. 사실 여부를 확인하기 위해 싸이트를 여기 저기 뒤적거리다 JDK 6의 초기 버전에 Early access 버전의 Java DB가 포함되어 있다는 것을 발견했다. 머리가 나쁘면 손발이 고생한다는 말이 떠오른다.

(참고로 JDK 6에 포함된 Java DB의 정체는 Apache Derby이다.)

메모리 누수 현상 해결

수정된 내용을 면밀히 살펴보면, 우선 가장 먼저 눈에 띄는 것은 메모리 누수(leak) 현상에 대한 부분이다. 단지, 특정 경우에 메모리 누수 현상이 발생했었다고 하지만, 메모리 누수로 문제가 터졌을 경우 해결하기가 매우 까다로운 현상이기 때문에 가장 반가운 내용 중 하나이다.

메모리 누수에 대한 내용은 총 4 개 이며, 독특한 것은 세마포어(Semaphore) 관련 메모리 누수 현상이다. 만약, 세마포어를 사용하여 작성한 code가 있다면 매우 치명적인 메모리 누수 현상을 보였을 것으로 추측된다. 더욱이 이 문제가 눈에 띄는 점은 update 1 에서 이미 해결 되었다고 발표 했었음에도 불구하고 실제로는 문제가 남아있었다는 것이다.

JAVA 다운 문제 (Crash) 해결

역시 매우 치명적인 문제의 하나로 JVM이 아무런 이유 없이 다운 (Crash) 되는 현상이다. 이러한 Crash 문제에 대한 수정 사항은 모두 9 개 이다. 이 중 5 개가 Graphic 관련이라는 점이 주목해 볼만 하다. 이것은 Java2D나 AWT, JFC/Swing을 사용하는 프로그램일 경우 확률적으로 Crash 될 가능성이 더 높았다는 것을 시사해 준다.

성능 개선

애석하게도 성능 개선과 관련된 항목은 단 2 개뿐이다. 그나마 아쉬움을 조금 달랠 수 있는 것은 System.arraycopy () 함수의 성능 개선에 대한 내용이다. 서버 측 Code에는 System.arraycopy () 함수가 성능에 중요한 영향을 끼치는 부분에 종종 사용되는 것을 보게 되는데, 이 함수의 성능이 개선 되었다는 것은 은근히 기대를 해보게 만든다. 하지만, 실제 내용을 살펴보면 성능 개선이라기 보다는 기존에 비 정상적으로 성능이 떨어지는 현상을 해결한 것이라는 사실을 알 수 있다. 어찌 되었든 성능 개선은 반가운 소식임에 틀림이 없다.

Java Plug-in 관련 수정

항목 수를 보면 비중이 그리 크지는 않지만, 내용을 살펴보면 Java Plug-in (혹은 Applet)과 관련되어 상당히 치명적인 문제들이 적지 않게 해결 되었다는 것을 알 수 있다. 결국, update 1에서는 Java Plug-in (혹은 Applet)을 구동 시키는데 많은 어려움이 있었다는 결론이다.

그 외의 내용들

그 외의 내용들의 분포 비율을 보면 유난히도 Java2D, JFC/Swing과 관련된 항목의 비중이 높다. 또한 한 가지 특이한 것은 한국어와 관련되어 잘못된 것이 한 가지 고쳐졌다는 내용이 보인다. 이는 한국어가 자국어인 사람으로서 단 1 건의 내용인데도 왠지 모르게 뿌듯함이 느껴지게 한다. 또, 설치 관련 항목들과 컴파일러 관련 항목들도 비중이 높은 편이며 다국어 관련 부분도 눈에 띄는 편이다.

결론 및 사족

JDK 6가 나온지 그리 오래 된 것 같지도 않은데 벌써 2 번째 update가 발표 되었다. Update 숫자가 올라갈수록 점점 더 안정성이 높아진다는 의미이며, 동시에 이제 JDK 6를 실제 업무에 적용해볼 만해진다는 의미를 가진다. 또한, 차기 버전인 JDK 7가 발표될 날이 점점 다가온다는 의미 또한 내포하게 된다. JDK 5가 나올 때 까지만 해도 새로운 기능들에 대해서 상당히 공격적인 관심을 가지고 바라 보았었지만, JDK 6의 경우는 솔직히 어떤 기능들이 새롭게 추가 된 것인지도 머리 속에 별로 남아 있는 것이 없다. 개인적으로 보면 이제 Java에서 점점 손을 멀리 해야 할 시점이 다가 오는 것 같다는 느낌이다. (지금 까지 7년이 넘게 열심히 밥벌이 꺼리를 제공해준 녀석인데도 말이다) 이런 저런 잡설은 집어치우고, 실제 결론은 어차피 하나다. JDK 6를 사용하고 있다면 update 2로 업그레이드 하는 것이 건강(?)에 유익하다라는 것이다.