Does Java need Checked Exceptions?

자바만이 예외를 반드시 잡도록 표시할 수 있는 기능을 갖고 있습니다. 하지만 이런 기능이 소프트웨어의 모든 reliability를 검증할 수 있을까요. 타입이라는 것이 모든 것을 검증할 수 있을까요. 정답은 당연하지만 ‘아니요’라는 것입니다.

루비같은 언어는 심지어 변수의 타입마저도 없애는데, 역시나 이로 인한 오타 문제 (예를들어 abc = 3이라고 해놓고 puts abb라고 찍는 문제)를 해결하기 위해 TDD를 강조하는 듯 합니다. 사실은 perl처럼 -w 옵션이 있어서 paranoia mode 로 변수의 잘못된 사용을 검증해내도록 할 수 있으나 완전하지 않습니다.

그런데 문제는 TDD의 테스트 케이스로 커버되지 않는 경우이고, 그걸 해결하기 위해서는 Test Case의 Coverage가 얼만큼인가하는 평가 문제가 등장하는 듯 합니다. 그럼, 모든 경우를 다 테스트 하기위해서는 분명히 모든 분기마다 테스트가 다 있어야하고 만약 분기문의 수가 n이라면 2^n개의 테스트 케이스가 필요할 테고, 당연히 이는 지수적으로 증가합니다. (만약 누군가 SE를 전공한다면 이 지수 증가의 문제를 어떻게 해결하는지 답해주세요.)

반면, code inspection을 통한 코드의 질 검사 역시 디버깅이나 테스트 만큼 좋은 효과가 있다고 이야기됩니다. 그렇다면, pair programming, TDD, code inspection phase의 세가지 조합이 좋은 소프트웨어를 위한 발걸음이 되겠죠.

그러나 이들도 모든 문제를 해결하지는 못합니다. 만약 모든 문제를 해결하는 방법론이 있다면 지금 우리가 이처럼 버그 많은 세상에 살지도, 보안 버그에 시달리지도 않을 것입니다. 대부분의 치명적인 버그가 stack smashing이나 integer overflow같은 것임을 감안한다면 말이죠..

TDD를 제대로 공부해 본적이 없었지만, 만약 정말 동적인 언어가 다음 세상의 대안으로 떠오르려면 다음과 같은 문제가 해결되야 할 듯합니다.

1) 동적 언어의 변수 타입을 컴파일 타임에 검사하는 기능
2) 동적 언어의 code completion을 코드 저장중간에 해내는 기능
3) TDD 테스트 케이스 개발을 위한 체계적인 방법론

1과 2는 대충 어떻게든 특정 정도까지 해낸다고 하더라도, 3번은 결코 풀기 쉽지 않은 문제가 될 것입니다. 이런 것들도 흥미로운 연구 주제라고 생각이 듭니다.

한편, 요즘은 사실 개발이라는 것은 알고리즘과의 싸움이 아닌가, 특히 21세기형 소프트웨어 개발자의 연구주제는 한정된 메모리를 가지고 무지막지한 사이즈의 데이터를 디스크에 저장한 상태로 빠르게 해결하는 것이 아닌가 하는 생각이 듭니다. 특히 이 부분에서는 storage보다는 speed가 주요 관건이 되겠죠.

또 다른 한편으로 지금까지의 디스크 기반 검색기법들은 지나치게 비 알고리즘적이라는 생각이 듭니다. 원래 CS와 Business Management의 사람들이 다르듯, network하는 사람/db하는 사람/알고리즘 하는 사람/인공지능 하는 사람의 성격이 서로 다르다고 하죠. 그것처럼 디스크에 저장한 뒤 알고리즘적으로 뭔가를 찾거나 저장하는 연구는 대부분 db에서 해왔는데, 지금까지의 방법은 메모리상의 알고리즘과는 매우 다르다는 생각이 듭니다.

이부분에 대해서는 확실히 말하기는 힘들지만, 예를 들어 algorithm을 하는 사람은 트리에서 검색을 한다고 하면 부모 a에서 자식 b로 가고 b에서 c로 가고, 그러니까 검색의 경로는 tree의 path length인데 이것이 O(logN)이다는 식으로 생각하죠. 하지만 디스크 기반 다차원 인덱스 구조인 R* tree같은 것을 생각해보면, 이러저러하게 구조를 만들고 몇개를 묶어 하나의 블록으로 놓고 그것을 다시 상위에서 또 묶어 또 블록으로 묶어주고.. 뭐 이런식으로 문제를 풀기위한 구조를 생각해내려는 것이 아닌가 하는 생각이 듭니다. 아 말로 하기 참 힘들군요 ㅎㅎ

또 다른 예를 생각해보면, 음.. 예를들어 fibonacci를 recusion으로 짰다면 T(N) = T(N-1) + T(N-2)인데 T(1)=1이니까 이를 시그마해서 어쩌구라고 생각하면 알고리즘 연구하는 사람들의 방식이고, 이것을 만약 내가 버퍼를 잡고 이것안에 T(0..N/r)까지의 결과를 저장해두고 이것을 디스크에 저장하고/부르는데, 캐시가 어쩌구 하는 식으로 생각한다면 디비를 연구하는 사람들의 방식이 아닌가 생각이 됩니다. 만약 그냥 정말 수학문제 풀듯이 디스크 상에서 돌아가는 알고리즘을 연구한다면 분명 전혀 다른 해결방법이 도출되지 않을까.. 라고 매우 추상적으로 요즘 생각하고 있습니다.

너무 추상적이군요;; 흐흐. 그러나 어쨌든 말로는 쉽게 하지 못하겠지만 경영부전공을 하다 한과목 앞에서 포기한 저로서는 분명히 경영전공자와 CS전공자의 차이는 있었고, 마찬가지로 CS내에서도 분야마다 사람들의 사고방식에 차이가 있다고 느껴집니다. 그리고 그 간극을 메꾸는 식으로 사고할 수 있다면 좋을텐데라고 생각하고요.