일반적으로 자바에서는 C++와 마찬하지로 try catch 구문을 사용하여 예외 처리(exception handling)을 하게 되어 있다. 하지만, 개발자들이 잘 알지 못하고 사용한다면, 양날의 검처럼 작용할 수 도 있고, 유익하지 않을 수도 있다.

작년과 올 상반기까지 회의 연구소 인력들과 같이 협업하는 프로젝트가 있어서, 설계와 구현을 이들과 일정 부분 코드를 나누어서 진행하였다.
일반적으로 인도쪽 개발자들은 인건비가 싸고, 개인적인 개발 능력이 뛰어 나다고 알려져 있는데, 근 1년 이상 협업을 하면서 느낀점은 사실은 그렇지 않을 수도 있다는 것이다. 일반적으로 인도는 Windows 애플리케이션 개발과 C/C++ 을 잘사용하는 개발자들은 많기 때문에 쉽게 구할수 있기 때문에 그 중에는 능력있는 개발자들이 많이 있을수 있다. 하지만 Java라는 언어를 알고 있는 개발자는 적고, 그 중에서 웹과 J2EE의 영역들을 이해할 수 있는 개발자는 지극히 드물다. 따라서 실력있는 개발자를 Java쪽에서는 찾기가 매우 힘들다.

이야기가 길어졌는데, 인도 개발자들이 작성한 코드를 우리쪽에서 Prevent라는 툴을 이용하여 정적분석을 시켰는데, 몇가지 Critical한 내용들이 보고되었다. 그래서 이를 인도 개발자에게 코드 리뷰를 하고 수정하도록 했는데, 정적분석 수행시 마다, 동일한 위험요인에 대해 지속적으로 검출되었다. 개발자는 매번 확인하고 수정했고 코드에는 예외처리가 다 되어 있어서, 문제가 있을 수 없다고 했는데도 툴은 지속적으로 문제점을 검출하고 있었다. 그래서 결국은 내가 그들이 작성한 코드를 분석하고 리뷰를 하였는데, 여러 면에서 놀라야만 했다.
이들은 자바 프로그래밍에 대한 초보자들이었다. 거의 C/C++ 방식의 코딩과 Excepion 처리를 통한 회피에만 집중하고 있었다. 너무나도 복잡하고 다중적인 예외처리 문을 사용하는 것에 대해서 혀를 내둘러야 했다. 일단 좋은 코드는 보기도 좋아야 하는데, 무슨일을 하고 무엇을 말하려고 하는지 알수 없을 정도록 예외 처리문을 반복적으로 사용하였다. 어떤 식으로든 예외를 처리하고 나오도록 코드는 되어 있지만, 몇가지 간과한 점들이 있었는데, 그 중에 중요한 점은 예외 처리에도 순서가 있다는 것이다.

예외 처리(exception handling)시에도 지켜주어야할 순서거 있고, 이를 잘못하면 원하는 결과를 얻을 수 없을 뿐더러, 코드가 복잡해 진다.

일반적으로 예외를 처리한다는 것은 어떤 메소드를 호출하고 실행할 때, 그 메소드가 어떤식으로 동작할지 아로 있어야 한다. 이는 메소드가 결과값을 반환할 뿐만 아니라, 어떠한 경우에 예외를 호출할지를 정확히 알고 있어야 한다. 

예를 들어 "java.lang.ClassLoader"라는 클래스를 사용하려고 한다면, 이 API는 아래와 같이 정의된다.

위처럼 정의되는 API는 실행해서 결과값을 정상적으로 반환하고, 만약 실행 중에 문제가 될 경우, 이를 어떤식으로 호출하는 메소드에 알려 줄지를 정의하고 있는 경우이다. 위의 예제는 ClassLoder 클래스를 실행시 클래스가 발견되지 않는 경우에 "ClassNotFoundException"이 호출된다.
따라서 위와 같은 명세를 정확히 개발자가 알고 있어야 메소드 호출시에 어떻게 동작할지를 예측하고 코드를 작성할 수 있다.

try-catch 구문을 사용하는 것은 호출할 메소드에서 예외를 발생시킬수 있다는 것을 알고, 이를 컴파일러에 알려주는 역할을 하는 것이다. 그리고 이때 호출되는 exception도 객체로 정의되어 사용되어 진다.
그렇다면, Exception 객체는 어디에서 정의 되는 것일까? 이 객체는 개발자가 사용하고자 하는 메소드에서 정의되게 되는데, 메소드에서 "throws"구문을 찾으면 된다. 이렇게 정의된 예외는 예외가 정의된 메소드를 를 호출하는 곳으로 던져지게 된다.

자바 개발자들이 많이 사용하는 Eclipse와 같은 IDE에서는 어떤 메소드를 호출할 때 자동으로 try-catch문으로 호출하는 메소드를 감싸주는 기능을 자주 사용하게 된다. 이는 내부적으로 호출되는 메소드 내부에 "throw"구문이 호출된다는 것을 IDE툴이 알고 있기 때문이다.

한가지 더 나아가서, 자동으로 생성하는 예외코드는 보통 아래의 예외 같은 형태로 IDE상에 추가된다.

한가지 주위해야 하는 것은 위와 같이 "e.pringStackTrace()"를 툴에서 자동으로 생성해 주었다고, 예외 처리가 모두 끝나는 것이 아니다. 

요즘은 생각만큼 바쁘게 사는 것인지, 틈틈히 영화를 보고 그 때의 감흥을 되새기면서 글을 쓰는 것을 잊고 있다. 아니 실제로는 바쁜 것보다 마음의 여유가 없어서 일지도 모른다. 그동안 몇개의 영화를 보았는데, 하나도 손을 대지 않고 지나쳐 버렸다. 지나고 보니 아쉬움만이 남는데, 약간의 변화를 주기 위해서 다시 글을 쓴다.

이 영화는 약 2주전에 내가 본 영화이다.
한국인 배우가 나온다고, 개봉전부터 사람들의 관심을 끌기 시작하였는데, 말을 안해도 이미 누가 나오는지는 잘 알거라 생각한다. 맞다 우리가 월드스타의 반열을 올랐다고 생각하는 배우가 몇명 있는데, 그 중의 한명인 "이병현"씨이다.

내가 이 영화를 보게 된 것은 "국가 대표"와 "해운대"가 흥행을 하는 시점에서, 지금 보지 않으면, 곧 상영관에서 내려올지도 모른다는 불안감에서 보게 되었는데, 그래도 주된 이유는 한국인 배우가 나온다는 것이었다.

영화는 블록 버스터를 좋아하는 나에게는 어떤 면에서는 맞을 지도 모르지만, 정체 불명의 단체와 시대에 맞지 않는 과학기술과 테크날로지는 영화를 보는데, 반감 또는 어색함을 주었지만, 영화를 즐기는데는 큰 어려움이 없다.

영화의 구성과 시나리오를 볼때는 몇가지 반전 사항들이 있었지만, 이는 왠만큼 영화를 즐겼던 사람들에게는 식상할 만큼 반전요소들이다.

영화는 다양하고 특이한 캐릭터들을 선보이는데, "이병헌"씨의 캐릭터는 누구보다도 눈에 잘 들어온다. 이 영화는 잘 알려진 배우들이 등장하지는 않지만, 그가 우리에게 잘 알려진 배우이기 때문일 수도 있다. 그러나 무엇보다도 그의 연기력 때문이라고 생각한다.그의 정제된 연기는 극에서 분위기와 인물을 잘 살려주고 있다.

영화 속에서 나오는 한국어는 역시 어색하다. 그러나 영화나 미국 드라마에서 한국어의 사용이 늘어나는 것운 어느 정도 우리나라의 위상이 올라가고 알려지기 때문인듯하다.

영화속에서 동양은 한국, 일본 그리고 중국이 혼재되어 있는 것으로 표현되어 졌는데, 인물들의 한국어를 사용하지만, 일본풍의 건축물과 중국의 주방과 음식물들이 보이고, 소림사를 연상케하는 연무장의 풍경등은 나에게는 이질적이다. 그러나 외국인(서양인)의 눈으로 보면 다 똑같아 보일런 지도 모른다. 

영화는 스토리와 전체적인 진행으로 보면 적당한 흠도 있고, 무리한 측면도 있지만, 만화적이고 공상과학적인 측면으로 접근한다면, 2시간 내내 볼만한 흥미거리들이 가득차 있다.

아마도, 차기 작품을 예고하는듯한 앤딩장면은 2편이 계획되고 있음을 말해주고 있다.
블록버스터를 즐기는 방법은 깊게 생각하지 않고 장면 장면을 즐기는 것이다. 더불어 감동을 줄 수 있는 영화라면 더할 나위 없겠지만, 너무 많은 것을 바란다면 재미가 반감된다.

언제 나올지 모르는 속편이지만, 좀더 군더거기 없고 말끔한 스토리 전개로 이어졌으면 좋겠다.

작년말 올해초에 걸쳐서, 여러 인터넷 매체와 블로그들을 통해서 "웹 브라우져 시장의 뜨거운 경쟁"에 대해서 이야기되고 논의되어 왔다.

이와 더블어 한국에서는 절대로 빼어 놓고 이야기 할 수 없는 부분이 있는데, 이는 "Active X의 지원"에 대한 이야기이다. 웹 표준은 계속해서 발전 또는 변화하고 있기 때문에, 과거와 현재의 브라우져가 동일한 결과들을 사용자에게 제공하지 못한다. (여기서 내가 변화라는 단어를 사용한  이유는 완벽한 호환성을 제공할수 없기 때문이다. 어떠한 이유에서 인지, 기존에 제공되었던 기능들이 사라지거나 제거 되고 있다.)

10년전에도 비슷한 상황들이 있었지만, 그때만 해도 Microsoft의 IE와 Netscape의 Nevigator 브라우져의 싸움이었다. 이당시에는 브라우져가 지원하려는 기능들이 지금의 것보다 제한되어 있고, 지금만큼 네트워크 망이 안정적이고, 빠르게 구성되어져 있지 않기 때문에, "표준화된 스펙을 따르기 보다는, 조금도 많은 기능들을 추가하고 좀더 빠르게 사용자에게 제공할 수 있을까?"가 경쟁의 주요 포인트 였었다.
이러한 관점에서 마이크로소프트는 자신들의 모든 역량을 브라우져 개발에 집중하였었고, 브라우져의 기능적인면과 속도의 향상적인 측면에서 넷스케이프를 압도할 수 있었다.

당시에는 두 회사의 기술적인 차이는 늦게 웹부라우져 시장에 진입한 마이크로소프트사의 주도면밀한 기능의 추가와 전략들을 선보였다. 이중에도 HTML4를 IE4에서 지원하기 시작한 것이 가장 이상적인 것이었고, 웹 브라우져를 ActiveX 컨트롤(OLE)의 컨테이너로 사용하는 것이 두번째로 인상적인 것이었다. 세번째는 브라우져와 OS가 하나의 시스템을 구성하고 있기 때문에 절대로 분리할 수 없다는 것으로, 지금도 나는 믿지 않고 있지만, 같은 시스템의 리소스를 사용하고 있다는 것이다.

이때에 벌어지기 시작한 기술적인 변화와 차이들은 두 브라우져의 간극을 더 크게 벌리기 시작하였다. (이 외에도 제품의 시장성에 대한 부분도 있지만, 이야기가 길어져서 논하지 않으련다. 당시만 해도 넷스케이프는 돈을 받고 파는 제품이었다.)
왜냐하면, 이때는 과도기였기 때문에 개발자와 사용자들이 표준화보다는, 자신이 원하는 기능들을 쉽게 개발해서 제공하 수 있었기 때문이다. 사용자들은 새로운 환경으로 적응하는 단계였기에, 기존에 PC 애플리케이션 만큼의 기능들을 웹에서 구현해서 사용하기를 원했다. (제한된 네트워크 속도와 사용성 측면에서 웹이 독립 애플리케에션을 따라가기는 쉽지 않았다.)

일례로, 1998년경에 PC통신 서비스를 웹 기반의 서비스로 만들 회사들이 있다. LG에서 만든 채널아이와 SK에서 만든 넷츠고 라는 회사였는데, 이 회사들은 웹 기반이라고 하지만, 내부는 PC 애플리케이션에서만 볼수 있는 "데이타 그리드"를 사용하여 사용자로 하여금 쉽게 사용할 수 있도록 만들어 주었다.
아마도 그때 이들 프로그램을 사용했던 사용자들은 쉽게 기억할 수 있을 것이다. 

최근의 웹 브라우져 시장에서의 경쟁은 Firefox로 부터 비롯되었다고 해도 과언이 아니다. Firefox는 첫 번째 버전부터, 사람들에게 많은 관심을 끌기 시작하였는데, 이는 몇가지 눈에 띄는 개선 사항들 때문이다.
기존 넷스케이프코드의 속도는 항상 관심사하이었지만 관심 밖이었다. 너무 브라우징 속도가 늦다는 것을 알고는 있었지만, 변경한다는 것이 쉽운 일이 아니었다. 이를 가감히 버리고 새로 브라우징 엔진을 제작한 것이 Firefox였고, 이 결정은 성공적인 결과물들을 만들어 내고 있다. 그리고, Addon 애플리케이션의 지원이 또한 이전과 차별화된 개선 사항이다. 오픈소스 개발자들이 만들어진, 질 좋은 Application들을 쉽게 찾고 사용할 수 있도록, Echo System을 갖추어 놓았다는 것이 사용자와 개발자들을 머무르고 지속적으로 사용하도록 만든다. 

Apple의 사파리 브라우져 역시 빠른 브라우징 속도와 사용자 경험을 무기로 내세워서 조금씩 사용자들에게 알려지기 시작하고 쓰이고 있는 중이다. 최근에 속도를 내면서 버전업을 하고 있는 구글 크롬 브라우져 역시 애플과 비슷한 전략을 취하고 있지요.

중요한 점은 이들 새로운 브라우져들이 특징으로 HTML5를 지원하려 한다는 것이다. 따라서 앞으로 새로운 웹 표준을 지원하기 원한다면, HTML5의 지원이 선행되어져야 하는데, 이를 사용한다는 것은 호환성을 보장 받지 못한다는 의미가 될수도 있다. 앞서도 이야기 되었지만, 기존에 지원되던 기능들이 여러 이유들로 인해서 삭제되고, 사용할 수 없는 것들이 있기 때문이다. 반대로 생각하면, 좀더 쉽게 개발할 수 있는 기능들도 같이 새로 들어 가기 때문에 좀도 쉽게 개발할 수 있다는 의미로 받아 들일 수도 있다.
아래 링크를 보면, HTML5의 신규 기능들을 볼 수 있다.

최근에 아는 지인과 이야기 하다가, PNG 파일의 변환 이야기가 나왔다. 하고 있는 일이 있는데, 몇가지 풀리지 않는 이미징 프로세싱상의 문제점이었는데, 나의 호기심을 자극하였다.

내가 그동안 알고 있는 PNG파일에 대한 내용은