반응형
[지디넷코리아]프로그래밍 초보자가 능히 한 사람 몫을 할 정도, 혹은 혼자 코딩하도록 내버려둬도 다른 사람들이 불안에 떨지 않을 만큼 성장하는 가장 빠른 방법은 무엇일까요? 디자인 패턴을 공부하고 최신 기술을 익히고 실전 프로그래밍을 많이 해보는 것?
물론 중요합니다. 그러나 이보다 훨씬 더 중요한 것은 기초를 다지는 것입니다. 슬램덩크에서 강백호는 농구부 입단 후 2주일 간 드리블 연습만 했고 이것이 그가 빠른 시간 안에 한 사람 몫을 해내는 데 밑거름이 됐지요. 복잡한 이론, 어려운 신기술은 잠시 접어두고 프로그래머로서의 기본을 재점검해보겠습니다.
4년 전 학교에서 어느 벤처 경영인의 강연을 들은 적이 있습니다. 미국에서 벤처를 시작해 어느 정도 성공을 거둔 기업가였는데, 그는 강연 내내 기본을 강조했습니다. 미국과 한국의 기업 문화의 차이를 비교하면서 미국의 벤처들은 대체로 경영인으로서의 기본적으로 지켜야 할 것들을 잘 지키는 반면 한국의 벤처는 기본적인 것들을 제대로 지키지 못하고 그로 인해 실패하는 경우가 많다고 하더군요.
그는 모든 것을 기본이란 말 하나로 설명했습니다. 기본이 물론 성공의 충분조건은 아닙니다. 그러나 기본을 지키지 않고는 성공할 수 없습니다. 어떤 분야든 이것은 예외가 없을 것입니다.
그렇다면 프로그래머, 그 중에서도 자바 웹 프로그래머의 기본은 무엇일까요? 당연히 자바 언어에 대해 잘 아는 것입니다. 웹 프로그래밍이라는 것도 결국 사용하는 API가 다른 것 뿐, 좋은 자바 웹 프로그래머가 되려면 먼저 좋은 자바 프로그래머가 되어야 합니다.
너무도 당연한 말 같지만 현실은 그렇지 않습니다. 여러 자바 커뮤니티에 가보면 자바에 대한 기본적인 질문이 수없이 올라오며, 현업 프로그래머 중에도 기초가 부족한 사람이 너무나도 많습니다. 자바 프로그래머라면 자바에 관한 기본서 하나 정도는 마스터하고 시작하도록 합시다.
자바 기본서들은 대체로 내용이 충실하므로 아무거나 사도 나쁜 선택은 아닐 것입니다. 그래도 추천이 필요하다면 『Thinking in Java』를 추천합니다. 프로그래밍에 처음 입문한다면 예제들을 직접 따라해 보는 것도 좋을 것입니다.
자바에 익숙해졌다면 다음 단계는 웹 기술입니다. 웹 프로그래밍의 기본은 웹과 관련된 스펙(specification)에 대한 지식, 구체적으로 서블릿/JSP 스펙, HTTP 스펙(RFC 2068), HTML W3C 스펙 등입니다. 이 스펙들에 대해 상세히 다 알 필요는 없지만 웹 프로그래밍에서 사용하는 API들이 어떤 스펙에 기반을 두고 있는지, 자세히 알고 싶으면 무엇을 찾아야 하는지는 알아야 합니다.
공대생이 공학 수학의 내용을 전부 알고 있을 필요는 없지만 미분방정식을 풀고 싶으면 어느 페이지를 찾아봐야 하는지는 알고 있어야 하는 것처럼 어떤 요구사항이 발생했을 때 그 요구사항을 구현하려면 어떤 스펙을 찾아봐야 하는지 정도는 알고 있어야 하는 것이죠. 그리고 의외로 많은 웹 프로그래머들이 HTML, CSS에 익숙지 않은데, 이 때문에 웹사이트의 브라우저 호환성이 떨어질 뿐만 아니라 지저분한 코드를 양산하게 됩니다.
HTML 코드 역시 유지보수 대상이 되는 코드이며 자바 코드 못지않게 깔끔하게 유지할 수 있어야 함을 기억해야 합니다. 이를 위해서는 HTML과 CSS에 대해 상세히 알아둘 필요가 있습니다. XML은 이제 프로그래머의 기본이니 언급할 필요도 없을 것입니다. XML 파일을 이용하는 것이 편하게 느껴질 정도가 되면 코드의 유연성을 높일 좋은 방법을 많이 생각해낼 수 있을 것입니다.
스펙을 실제로 활용하는 것은 API를 통해서입니다. 서블릿/JSP API는 스펙과는 달리 실제로 API를 통해 무엇을 할 수 있는지를 상세하게 알고 있어야 합니다. 이것은 비단 서블릿/JSP API뿐 아니라 자바 기본 API, 각종 라이브러리의 API도 마찬가지입니다. 필자가 이제껏 자바에 관해 받아본 질문 중 대부분은 API 문서만 잘 들여다 보면 해결되는 것이었습니다.
API 문서를 자주 찾아보는 습관을 들입시다. 리눅서들은 매뉴얼을 읽지 않고 질문하는 사람에게 RTFM(Read The Fucking Manual)이라는 대답을 해줍니다. 자바 역시 RTFM이 필요합니다. J2EE 기본서를 하나 사서 보는 것도 좋을 것입니다. J2EE 기본서에는 웹 관련 스펙 중 중요한 부분들, 서블릿/JSP 스펙 및 API들이 잘 정리되어 있습니다. 『Java Server Programming, J2EE Edition』 정도면 훌륭한 참고서가 될 것입니다.
이제부터 이런 기본적인 지식 중에 중요하지만 간과하기 쉬운 것들, 간단하지만 알면 도움이 되는 정보, 자주 부딪히게 되는 고민 등 몇 가지 작은 문제들을 짚어볼 것입니다. 모두 기본 학습 과정을 잘 거쳤다면 자연스럽게 알 수 있는 내용입니다. 이런 하나하나의 지식을 통해 자신에게 부족한 점을 되짚어볼 수 있는 계기를 마련할 수 있기를 바랍니다.
web.xml
배치 서술자(deployment descriptor)라고 부르는 web.xml은 웹 프로젝트를 구성하는 데 있어 필수적이면서 웹 애플리케이션의 동작을 여러 가지로 조정하는 기능을 합니다. 스트러츠를 사용하는 경우도 스트러츠를 사용하기 위한 설정은 web.xml에 하게 되는데 그 설정들이 무슨 의미를 가지고 있는지 정도는 상식으로 알아두는 것이 좋을 것입니다. <리스트 1>의 실제 스트러츠 설정 예제를 봅시다.
PHP, ASP 등의 다른 서버 사이드 스크립트나 JSP 페이지는 페이지를 호출하는 경로에 실제 스크립트 파일이 존재해야 하지만 서블릿은 이와 달리 web.xml의 설정을 이용해 URL을 특정 서블릿으로 맵핑할 수 있습니다. <리스트 1>의 설정은 호출된 URL을 스트러츠의 Action으로 맵핑하기 위한 설정입니다.
servlet 설정에서 action이라는 이름의 서블릿을 org.apache.struts.action.ActionServlet 클래스로 등록하고 다음 servlet-mapping 설정에서 *.do라는 URL로 호출된 페이지들을 action이라는 이름의 서블릿으로 맵핑합니다. url-pattern 값을 *.nhn으로 바꾼다면 *.nhn으로 호출된 요청들이 ActionServlet으로 맵핑될 것입니다. 스트러츠는 이 ActionServlet에서 요청을 각 Action으로 분기시켜 줍니다. init-param은 서블릿을 초기화할 때 사용할 파라미터 값이며 getInitParameter 메쏘드를 통해 읽어올 수 있습니다. load-on-startup은 서블릿 엔진이 시작될 때 로드될 우선순위를 지정하는 값입니다.
인덱스 페이지를 지정하는 것도 web.xml에서 할 수 있습니다. 많은 웹 사이트들이 구체적인 경로 지정 없이 도메인명까지만 써줘도 페이지를 표시합니다. 이를테면 http://www.hangame.com으로 호출할 경우 다음과 같이 설정해두면 www.hangame.com의 /index.jsp를 호출하게 만들 수 있습니다.
태그명에서 짐작할 수 있듯이 인덱스 페이지는 여러 개를 둬서 순서대로 검색하게 할 수 있습니다. 예를 들어 index.html과 index.jsp가 순서대로 지정된다면 서블릿 엔진은 index.html이 있으면 index.html을 보여주고 없으면 index.jsp를 호출합니다. 이것도 없으면 404 에러가 나거나 디렉토리 목록이 보이게 됩니다. 이 인덱스 페이지는 모든 경로에 대해 동작합니다.
이와 같은 설정의 경우 http://www.hangame.com/login/을 호출한다면 http://www.hangame.com/login/index.jsp를 찾게 되는 것입니다. 이 설정은 사실 아파치 등의 웹서버에서도 해줄 수 있으나 보통 웹 서버에서는 인덱스 페이지가 실제 파일로 존재해야 보여줄 수 있는데, 서블릿 엔진에서는 실제 파일로 존재하지 않고 서블릿 맵핑으로 지정만 되어 있어도 보여줄 수 있다는 장점이 있습니다.
접근 권한도 설정할 수 있습니다. 권한 체계가 간단한 웹 애플리케이션이라면 web.xml만으로도 충분한 권한 설정을 해줄 수 있습니다.
<리스트 3>의 예는 서블릿 스펙 문서에 있는 예입니다. 이것의 의미는 GET이나 POST로 /retail/*과 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻입니다. 이외의 사용자는 권한이 없다는 401 에러 페이지를 보게 됩니다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능합니다. 실제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 합니다.
자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고, 톰캣의 실제 활용 예를 보는 것이 도움이 될 것입니다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공통적인 에외 처리를 위한 에러 페이지 설정도 가능합니다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것입니다.
예외 처리
자바의 강점 중 하나가 편리한 예외 처리 방식입니다. C 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리입니다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킵니다.
기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요합니다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹 사이트 방문객을 위한 부분 두 가지를 모두 고려해야 합니다.
먼저 프로그래머의 입장을 살펴봅시다. 예외가 발생하면 어디까지는 그냥 던지고 어디서 캐치하는 것이 좋을까요? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있습니다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일입니다. 대부분의 예외는 일단 그냥 던지는 것이 좋습니다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하지 않아도 된다는 것 때문입니다. 예외를 던짐으로써 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있습니다. 어떻게 처리해야 할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋습니다.
예외를 잡아서 처리해야 하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC(Model-View-Controller) 패턴으로 작성되어 있다면 컨트롤러에서 이 일을 하게 됩니다. 컨트롤러에서 예외를 보고 판단해 사용자에게 보여줄 화면을 결정하는 것입니다.
쇼핑몰에서 마일리지 적립액으로 상품을 구매하는 과정을 예로 들어보겠습니다. 만약 고객이 자신의 마일리지보다 더 많은 금액의 상품을 구매하려 한다면 구매를 수행하는 모델 객체에서 예외가 발생할 것입니다. 그러면 이 모델 클래스에서 예외를 바로 잡지 말고 던져서 구매 프로세스의 컨트롤러 객체에서 이를 잡아서 예외 페이지로 포워드시켜 예외 메시지를 보여주는 식으로 코딩하면 됩니다.
웹사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택 정보 등의 황당한 화면이 아닌 친절한 에러 메시지를 표시해 주는 것입니다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던져진, 정말 예상 밖의 예외를 모두 끌어 모아 처리하는 부분이 필요합니다.
서블릿/JSP에서는 이런 부분의 처리를 위한 기능을 여러 가지로 제공하고 있고 스트러츠 등의 프레임워크에서도 다양한 방법을 제공합니다. JSP의 에러 페이지 설정이 그 한 예입니다. 그러나 JSP의 에러 페이지 설정 방식은 모든 JSP 페이지에 설정해야 작동한다는 단점이 있습니다. 만약 에러 페이지 지정을 빠뜨린 페이지에서 예외가 발생한다면 서블릿 엔진의 에러 메시지가 그대로 웹사이트 방문객에게 전달되고 맙니다.
이런 부분을 쉽게 처리하기 위한 방법이 있습니다. 이것은 앞에서 설명했던 web.xml의 에러 페이지 설정을 이용하는 것입니다. 우선 다음의 예를 볼까요.
이렇게 설정해 두면 웹 애플리케이션 전반에서 발생하는 예외 중 java.lang.Exception을 상속한 예외는 모두 잡혀서 /common/error.jsp 페이지에서 처리하게 됩니다. 예외가 발생하면 request 객체에 예외 상황에 대한 정보가 attribute로 저장된 후 /common/error.jsp로 포워드되어 이 곳에서 request에 담긴 정보를 바탕으로 예외 처리를 해줄 수 있습니다. 이 곳에서는 일반적인 에러 메시지를 사용자에게 보여주면 됩니다. 자바 예외 뿐 아니라 HTTP 에러 코드도 잡아낼 수 있습니다.
이를테면 없는 페이지를 호출해서 404 에러가 나는 경우 이를 잡아서 페이지가 없다는 에러 메시지를 좀더 친절한 메시지로 보여줄 수 있습니다. 덧붙여, 이 에러 처리 페이지는 가급적 순수한 서블릿으로 만드는 것이 좋습니다. 스트러츠의 Action으로 에러 페이지를 구성해본 적이 있었는데 설정 상의 문제로 스트러츠의 ActionServlet 로딩이 실패할 경우 예외를 제대로 표시하지 못합니다. JSP로 만드는 것도 나쁘진 않으나 복잡한 로직이 들어갈수록 서블릿이 코딩하기 더 편할 수 있습니다. 만약 이 에러 페이지 자체에서 또다시 예외가 발생하면 찾기 힘든 경우가 많기 때문에 주의를 많이 기울여야 합니다.
로깅
에러 페이지에서 해야 할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것입니다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야 합니다. 이 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야 합니다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫습니다.
여러가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만합니다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해 사용합니다. <리스트 5>는 commons-logging을 사용하는 예입니다.
이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생깁니다. 만약 여기에 log4j를 붙여서 사용한다면 <리스트 6>과 같은 log4j 설정을 사용할 수 있습니다.
이 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있습니다. 로거의 특성은 이름으로 상속됩니다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 됩니다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 됩니다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끌 수 있습니다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있습니다.
앞에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있습니다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송하는 시스템도 구상해 볼 수 있을 것입니다.
예외 추적
예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것입니다. 예외 추적의 출발점은 당연히 예외 스택 정보입니다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있습니다.
하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해 문제점을 예측하려 하곤 합니다. 이런 실제 상황에 기반을 두지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 됩니다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋습니다.
스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있습니다. 이 모든 정보를 다 찾아볼 필요는 없습니다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보입니다.
그렇다고 늘 제일 위의 정보를 봐야 하는 것은 아닙니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보가 같이 담겨 있습니다. 이런 정보는 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이 곳을 찾아보면 대부분의 문제점은 정확하게 추적할 수 있습니다.
또 한 가지 자바 초보자를 괴롭히는 문제는 NullPointerException입니다. 사실 이것은 초보자에게는 아주 까다로운 문제지만 조금만 알면 가장 찾기 쉬운 문제 중 하나가 NullPointerException입니다. NullPointerException은 객체의 멤버 변수나 메쏘드를 이용하려고 할 때 그 객체가 null인 경우에 발생합니다. 따라서 NullPointerException이 발생하면 앞의 방법대로 예외가 발생한 라인을 찾아들어간 다음 그 라인에서 멤버 지정 연산자(.) 앞에 있는 객체를 보면 됩니다. 이 사실만 알고 있어도 NullPointerException이 발생했을 때 어떤 객체가 null인지를 쉽게 찾아낼 수 있을 것입니다.
간혹 NullPointerException이 싫어서 다음과 같은 코드를 작성하는 경우가 있습니다.
if ("Y".equals(param)) doSomthing();
else doOther();
이런 코드는 조심해서 써야 합니다. param의 null 체크가 귀찮아서 이런 식의 코드를 쓰곤 하는데 만약 param의 값이 Y인 경우는 doSomething()을 실행하고, N이나 null이면 doOther()를 실행해야 하는 경우라면 이 코드는 문제가 없습니다. 그러나 만약 param은 null이면 안 되는 상황이라면 어떻게 될까요? 다른 부분의 버그로 param에 null이 들어와도 프로그래머는 이것을 알아차리지 못하고 넘어가게 됩니다. 즉, 버그를 은폐하는 코드가 됩니다.
당장의 문제를 발생하지 않더라도 이런 코드는 나중에 찾기 힘든 문제를 유발할 수 있습니다. 이런 경우는 그냥 NullPointerException이 발생하도록 내버려 두면 param에 null 값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있습니다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야 합니다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 맙시다.
한글 문제
웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제입니다. 한글 문제가 지금처럼 골치 아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야 하는 것들을 살펴보겠습니다.
자바는 문자열과 바이트 스트림을 다르게 취급합니다. 자바의 스트링은 유니코드의 문자셋을 사용하며 문자열을 파일에 쓰거나 네트워크로 전송하는 등 실제 입출력이 일어날 때는 문자열을 바이트 스트림으로 변환하게 됩니다. 이 때 바이트 스트림으로 변환하는 규칙이 인코딩입니다. 따라서 바이트 스트림으로 전달된 것을 문자열로 바꾸거나 문자열을 바이트 스트림으로 전달할 때는 반드시 인코딩을 지정해야 합니다.
이런 인코딩 중 한글을 표현할 수 있는 인코딩은 자바에서 사용하는 이름을 기준으로 하면 EUC-KR, MS949, UTF-8, UTF-16 정도가 있습니다. EUC-KR은 KSC5601-1987 기반 인코딩으로 한글의 모든 문자를 다 표현할 수 없습니다. MS949는 EUC-KR을 확장해 모든 한글을 표현할 수 있지만 비표준이고 코드 자체에 기술적인 결함이 많습니다. UTF-8과 UTF-16은 유니코드의 인코딩들이며 모든 한글을 표현할 수 있고 표준이며 한글 이외의 다른 언어와 함께 표현이 가능합니다.
보통 많이 쓰이는 EUC-KR은 RFC 표준 인코딩이긴 하나 한글의 확장 문자들을 제대로 표시하지 못합니다. 그래서 자바 웹 프로그래밍에서는 MS949를 많이 쓰게 됩니다. 자바에서 스트링 객체를 생성할 때는 이 중에 하나로 인코딩을 줘서 생성해야 한글을 표현할 수 있게 인코딩됩니다.
웹서버로 전달되는 요청은 클라이언트의 웹브라우저가 문자열을 바이트 스트림으로 인코딩하는데 이 때 사용하는 인코딩은 일반적으로 한글 윈도우의 기본 인코딩인 MS949입니다. 그런데 서블릿 엔진에서 요청을 처리하는 데 사용하는 기본 인코딩이 ISO-8859-1이기 때문에 아무 것도 지정하지 않으면 MS949로 인코딩된 바이트들을 ISO-8859-1 인코딩의 스트링 객체로 만들기 때문에 한글이 깨져보이게 됩니다. 따라서 기본 인코딩을 MS949로 지정하면 인코딩이 보존된 상태로 한글이 깨지지 않게 됩니다. HttpServletRequest.setCharacterEncoding() 메쏘드에서 이것을 지정할 수 있습니다.
그러나 이것에도 약간 문제가 있습니다. 서블릿 스펙상 이 메쏘드는 POST 요청에만 적용됩니다. 즉, POST 요청의 파라미터는 setCharacterEncdoing에서 지정한 인코딩으로 스트링 객체가 생성되기 때문에 한글을 보존할 수 있으나 GET 요청은 setCharacterEncoding의 적용을 받지 않기 때문에 GET으로 받은 파라미터는 인코딩 변환을 다시 해주어야 합니다. 다만, 이것은 서블릿 엔진에 따라 다릅니다. 톰캣의 경우도 4.1 버전과 5.0 버전이 다르게 동작하니 주의가 필요합니다.
웹서버에서 다시 클라이언트로 응답할 때는 반대의 과정입니다. 자바의 스트링 객체가 바이트 스트림으로 변환되며 이 때 역시 인코딩을 지정해야 합니다. 이 인코딩은 JSP 페이지에서 페이지 지시자의 pageEncoding 속성을 통해 지정할 수 있고, 서블릿 2.4 스펙에서는 HttpServletResponse.setCharacterEncoding을 사용할 수 있습니다. HTTP 요청을 읽는 과정과 역순이라고 생각하면 됩니다.
그리고 웹 서버에서 요청을 읽을 때 MS949를 지정해 주듯이 클라이언트의 웹 브라우저도 웹 서버에서 생성한 응답을 정확하게 읽으려면 어떤 인코딩을 사용해야 하는지 알아야 합니다. 이것을 지정해주는 것이 HTML의 Content-Type입니다. 다음과 같이 지정할 수 있습니다.
<meta http-equiv="Content-Type" content="text/html;charset=euc-kr" />
여기서 지정하는 charset은 원칙적으로는 당연히 웹 서버에서 응답 객체를 생성할 때 지정한 인코딩 값과 같아야 한글로 제대로 읽을 수 있습니다. 그러나 여기 지정하는 charset이 RFC 표준 문자셋이 아닐 경우 브라우저에 따라 인식하지 못할 수도 있습니다. 따라서 MS949로 인코딩했다면 MS949를 지정해야 정상이지만 MS949가 RFC 표준이 아니기 때문에 문제가 생길 수 있습니다.
그렇다고 응답의 인코딩을 EUC-KR로 지정하게 되면 확장 한글을 표시할 수 없기 때문에 문제가 됩니다. 그래서 페이지 인코딩은 MS949로 하지만 Content-Type에는 euc-kr을 지정해 주게 되는 것입니다. 물론 이렇게 되면 경우에 따라 확장 한글이 깨질 수 있지만 다행스럽게도 대부분의 브라우저에서 이렇게 지정하면 잘 동작합니다.
사실 이 부분은 응답 스트림에 적용되는 인코딩과 HTML Content-Type에 지정하는 인코딩이 같기만 하면 되기 때문에 굳이 MS949를 사용할 필요는 없고 UTF-8 등의 인코딩을 사용해도 무방합니다. 따라서 응답 스트림의 인코딩도 UTF-8로 하고 Content-Type도 UTF-8로 지정하는 것이 가장 확실한 방법일 수 있습니다. 또한, HTML의 Content-Type에 UTF-8이 지정되어 있으면 이 페이지에서 폼을 전송할 경우에도 UTF-8로 인코딩되어 요청을 파싱하는 쪽에서도 UTF-8을 사용할 수 있습니다.
유니코드의 인코딩들인 UTF-8, UTF-16은 한 인코딩으로 다국어를 처리할 수 있기 때문에 다국어 지원이 필요한 웹 애플리케이션은 실제로 UTF-8로 작성된 것이 많습니다. 다국어 지원이 필요 없다고 해도 UTF-8을 사용하는 것이 오히려 한글 문제를 더 쉽게 해결하는 방법이 될 수 있습니다.
웹 뿐 아니라 데이터베이스나 파일에 입출력을 할 때도 마찬가지의 원리가 적용됩니다. 사용하는 인코딩이 다르면 변환 과정을 거쳐야 합니다. 이것은 리눅스나 유닉스에서 문제가 될 수 있습니다. 리눅스는 MS949를 지원하지 않고 EUC-KR만 지원하기 때문입니다. 따라서 윈도우에서 개발하고 리눅스에서 돌리는 경우 문제가 되는 경우가 간혹 있습니다.
MS949가 또 하나 문제가 되는 영역은 XML 파서입니다. 현재 가장 널리 사용되는 XML 파서는 Xerces인데 이 파서는 RFC 표준 문자셋 외에는 지원하지 않기 때문에 MS949 인코딩은 파싱 에러가 납니다. 그런 반면 JDK 1.4에 포함된 파서인 Crimson은 네임스페이스 파싱에 버그가 있습니다. MS949를 XML 인코딩으로 쓸 경우 XML 파서 선택이 문제가 될 수 있는 것입니다.
다행스럽게도 JDK 5.0에 포함된 파서는 Xerces를 썬에서 패치한 것인데 이것은 아무 문제가 없습니다. 하지만 여전히 많은 오픈소스 라이브러리들이 Xerces를 사용하고 있기 때문에 문제가 되는 경우는 계속 나타날 수 있을 것입니다. 이것 때문에라도 UTF-8을 사용할 필요가 있습니다.
자바에서의 한글 문제는 문자열과 바이트 스트림의 변환에 인코딩이 주어져야 한다는 사실만 생각하면 다 쉽게 해결할 수 있습니다. 역시 기본이 잘 갖춰져 있으면 한글 문제도 쉽게 해결할 수 있는 것입니다.
URL 인코드
URL 인코딩이 필요한 것은 URL에 사용 가능한 문자가 제한되어 있기 때문입니다. URL 스펙(RFC 1738)에 정의된 바로는 URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수문자뿐입니다. 따라서 다양한 문자를 URL로 전달하려면 URL에서 허용하는 문자로 변환해 전달해야 합니다. 이것은 GET 요청의 파라미터로 값을 전달하려할 때 문제가 됩니다.
예를 들어 http://website.com/process.jsp에 로그인되지 않은 상태에서 접근하면 자동으로 로그인 페이지인 http://website.com/login.jsp로 리다이렉트된 후 로그인을 하면 원래 요청했던 페이지로 다시 리다이렉트되도록 해야 한다고 합시다.
그러면 /process.jsp에서는 로그인 페이지로 리다이렉트시키면서 파라미터로 현재 요청한 URL, 즉 /process.jsp를 넘겨주고 login.jsp에서는 로그인 처리가 끝난 후 이 URL로 다시 리다이렉트시키면 됩니다. 여기서 /process.jsp에서는 http://website.com/login.jsp?redirect=http://website.com/process.jsp와 같은 형식으로 리다이렉트를 해주면 될 것입니다.
여기서 문제는 redirect 파라미터의 값이 URL이기 때문에 URL 안에 URL이 들어간 형태가 되어 제대로 파싱되지 않는다는 것입니다. 그래서 파라미터로 넘겨야 하는 URL 부분을 URLEncoder로 인코딩해 http://website.com/login.jsp?redirect=http%3A%2F%2Fwebsite.com%2Fprocess.jsp와 같은 형태로 넘겨야 합니다. 이 값을 받는 부분에서는 다시 디코딩을 해줄 필요가 없습니다.
URL은 자동으로 웹 서버에서 파싱할 때 디코딩을 해주기 때문입니다. URL을 통해 GET 요청의 파라미터로 보내야 하는 값은 반드시 URL 인코딩을 거쳐야 한다는 사실만 기억하세요. 참고로 자바스크립트에서도 escape, unescape 함수를 통해 URL 인코딩, 디코딩과 유사한 작업을 수행할 수 있습니다.
클래스패스의 리소스 사용법
웹 애플리케이션은 보통 애플리케이션의 설정을 담고 있는 파일이 필요합니다. web.xml, struts-config.xml 등의 설정 파일들은 보통 웹 애플리케이션의 /WEB-INF/에 위치하는데 그 외에 애플리케이션에서 사용하는 파일들은 어디에 놓고 사용하는 것이 편리할까요? 가장 관리하기 쉽고 부가적인 작업이 적은 방법은 클래스 패스에 두는 것입니다. /WEB-INF/classes에 두면 자바의 클래스 로더를 이용해 이런 파일들에 접근할 수 있습니다. log4j 등 많은 라이브러리들이 자신의 설정 파일을 클래스 패스에서 가장 먼저 찾게 됩니다. <리스트 7>의 예제를 볼까요.
이 코드는 클래스 패스에서 config.xml을 읽습니다. 웹 애플리케이션의 기본 클래스 패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 됩니다. 이것으로 jar 파일 안의 내용도 읽을 수 있습니다. 이 경우는 ClassLoader.getResourceAsStream을 통해 스트림으로 파일 내용을 읽을 수 있습니다.
대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일 중 자바 소스가 아닌 파일들을 자동으로 클래스 패스로 복사해주므로 이용하기도 편리합니다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있습니다.
서블릿/액션 멤버 변수 공유 문제
JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹 사이트 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었습니다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었습니다. <리스트 8>을 봅시다.
얼핏 별 문제가 없어 보이지만 이 코드는 심각한 문제가 있습니다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용됩니다. 때문에 A와 B라는 두 사용자가 동시에 이 서블릿을 호출하게 되면 A의 호출을 수행하는 중에 B의 호출이 userInfo의 값을 바꿔버릴 수 있습니다. 그러면 A는 B의 정보를 보거나 그 반대의 경우가 생길 수 있는 것입니다.
혼자서 테스트할 때는 한 번에 한 쓰레드만 service 메쏘드를 호출하기 때문에 이런 문제가 잘 드러나지 않기 때문에 별 문제 없는 줄 알고 있다가 서비스를 오픈하고 나면 문제가 되는 경우가 있으므로 조심해야 합니다. JSP에서 <%! %>를 통해 선언하는 내용도 마찬가지 문제가 발생하므로 주의해야 합니다. 이런 내용 역시 자바 클래스와 멤버 변수의 기본 개념을 이해하고 서블릿 스펙만 한 번 읽어본다면 금방 알 수 있는 내용입니다.
생각하기
이 내용을 읽으면서 모르는 내용이 하나도 없었다면 자바 웹 프로그래머로서 어느 정도 기본은 되어 있다고 할 수 있습니다. 이런 내용은 그 하나하나에 대한 지식을 쌓는 것도 중요하지만 더 중요한 것은 이런 내용을 알아야 한다는 사실을 아는 것입니다.
무엇을 알아야 하는가를 가르쳐주는 것은 스펙입니다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있진 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있습니다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는지 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수 있는 것입니다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요합니다. 기본적으로 www.ietf.org,jcp.org,java.sun.com, www.w3.org 정도의 사이트에는 익숙해지는 게 좋을 것입니다.
많은 프로그래머들이 실제로 자기 손으로 프로그래밍해보는 게 실력이 느는 제일 좋은 방법이라고 말하지만 필자는 여기에 동의하지 않습니다. 물론, 실제 경험을 쌓는 것이 필수적인 과정이긴 합니다. 그러나 기본 지식을 등한시한 상태에서 코딩만 해보는 것으로는 실력이 잘 늘지 않습니다.
코딩 기술은 늘 수 있겠지만 정말 실제 서비스를 해야 하는 프로그래밍에서 중대한 실수를 저지르게 되거나 남들이 쉽게 하는 일들을 어렵게 빙 둘러가면서 하게 될 수 있습니다. 그래서 기본기를 갖추는 것이 중요한 것입니다.
거듭해서 기본의 중요성을 강조했는데 한 가지 덧붙이고 싶은 말은 이런 기본 지식 뿐 아니라 기본을 활용하는 능력을 키우는 것도 잊지 말아야 한다는 것입니다. 앞서 언급한 예외 처리 같은 내용은 기본이긴 하나 자바 문법만 잘 안다고 알 수 있는 내용은 아니며 기본을 바탕으로 좋은 판단을 내릴 수 있는 능력이 있어야 합니다.
결국 좋은 프로그래머가 되려면 먼저 좋은 사고 능력을 가지고 있어야 하는 것입니다. 글짓기를 잘하는 방법으로 흔히 다독(多讀), 다작(多作), 다상량(多商量)을 이야기합니다. 많이 읽고 많이 쓰고 많이 생각하라는 것입니다. 프로그래밍도 이와 비슷합니다. 각종 스펙과 좋은 코드를 많이 읽어보고 직접 코딩도 많이 해보면 분명 실력이 늘지만 이것으로는 충분치 않습니다.
프로그래밍을 하면서 끊임없이 생각해야 합니다. 지금 작성한 코드는 좋은 코드인가, 이렇게 코딩하면 불편한데 개선할 방법은 없을까, 이 API들로 무엇을 할 수 있을까, 개발 속도를 향상시키려면 어떻게 해야 할까 등 생각을 많이 해야 진짜 발전을 이룰 수 있습니다.
만일 손가락이 아플 정도로 하루 종일 키보드를 두드리고 있다면 좋은 프로그래머라고 할 수 없습니다. 생각하는 데 좀 더 많은 시간을 써야 합니다. 모니터를 구부정하게 들여다보면서 키보드를 두드리는 것은 것보다는 의자에 편안히 기대서 생각하는 시간을 늘려보세요. 복잡한 문제가 있으면 바깥 공기를 쐬면서 산책을 하면서 생각을 하는 것도 좋습니다. 굳이 건강을 생각하지 않더라도 걷는 것은 두뇌를 활성화하기 때문에 해결책을 더 빨리 찾을 수 있게 합니다.
남들이 보기에는 게을러 보일 수 있지만 놀고 있는 게 아니라는 것은 결과로 충분히 보여줄 수 있습니다. 물론 이런 생각을 잘 이어나가기 위해서는 생각의 재료가 되는 기본에 충실해야 함은 물론입니다. 어둠침침한 구석에 앉아 키보드만 두드리는 긱(geek)이 아닌 보다 인간다운 프로그래머가 됩시다.@
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다
.
물론 중요합니다. 그러나 이보다 훨씬 더 중요한 것은 기초를 다지는 것입니다. 슬램덩크에서 강백호는 농구부 입단 후 2주일 간 드리블 연습만 했고 이것이 그가 빠른 시간 안에 한 사람 몫을 해내는 데 밑거름이 됐지요. 복잡한 이론, 어려운 신기술은 잠시 접어두고 프로그래머로서의 기본을 재점검해보겠습니다.
4년 전 학교에서 어느 벤처 경영인의 강연을 들은 적이 있습니다. 미국에서 벤처를 시작해 어느 정도 성공을 거둔 기업가였는데, 그는 강연 내내 기본을 강조했습니다. 미국과 한국의 기업 문화의 차이를 비교하면서 미국의 벤처들은 대체로 경영인으로서의 기본적으로 지켜야 할 것들을 잘 지키는 반면 한국의 벤처는 기본적인 것들을 제대로 지키지 못하고 그로 인해 실패하는 경우가 많다고 하더군요.
그는 모든 것을 기본이란 말 하나로 설명했습니다. 기본이 물론 성공의 충분조건은 아닙니다. 그러나 기본을 지키지 않고는 성공할 수 없습니다. 어떤 분야든 이것은 예외가 없을 것입니다.
그렇다면 프로그래머, 그 중에서도 자바 웹 프로그래머의 기본은 무엇일까요? 당연히 자바 언어에 대해 잘 아는 것입니다. 웹 프로그래밍이라는 것도 결국 사용하는 API가 다른 것 뿐, 좋은 자바 웹 프로그래머가 되려면 먼저 좋은 자바 프로그래머가 되어야 합니다.
너무도 당연한 말 같지만 현실은 그렇지 않습니다. 여러 자바 커뮤니티에 가보면 자바에 대한 기본적인 질문이 수없이 올라오며, 현업 프로그래머 중에도 기초가 부족한 사람이 너무나도 많습니다. 자바 프로그래머라면 자바에 관한 기본서 하나 정도는 마스터하고 시작하도록 합시다.
자바 기본서들은 대체로 내용이 충실하므로 아무거나 사도 나쁜 선택은 아닐 것입니다. 그래도 추천이 필요하다면 『Thinking in Java』를 추천합니다. 프로그래밍에 처음 입문한다면 예제들을 직접 따라해 보는 것도 좋을 것입니다.
자바에 익숙해졌다면 다음 단계는 웹 기술입니다. 웹 프로그래밍의 기본은 웹과 관련된 스펙(specification)에 대한 지식, 구체적으로 서블릿/JSP 스펙, HTTP 스펙(RFC 2068), HTML W3C 스펙 등입니다. 이 스펙들에 대해 상세히 다 알 필요는 없지만 웹 프로그래밍에서 사용하는 API들이 어떤 스펙에 기반을 두고 있는지, 자세히 알고 싶으면 무엇을 찾아야 하는지는 알아야 합니다.
공대생이 공학 수학의 내용을 전부 알고 있을 필요는 없지만 미분방정식을 풀고 싶으면 어느 페이지를 찾아봐야 하는지는 알고 있어야 하는 것처럼 어떤 요구사항이 발생했을 때 그 요구사항을 구현하려면 어떤 스펙을 찾아봐야 하는지 정도는 알고 있어야 하는 것이죠. 그리고 의외로 많은 웹 프로그래머들이 HTML, CSS에 익숙지 않은데, 이 때문에 웹사이트의 브라우저 호환성이 떨어질 뿐만 아니라 지저분한 코드를 양산하게 됩니다.
HTML 코드 역시 유지보수 대상이 되는 코드이며 자바 코드 못지않게 깔끔하게 유지할 수 있어야 함을 기억해야 합니다. 이를 위해서는 HTML과 CSS에 대해 상세히 알아둘 필요가 있습니다. XML은 이제 프로그래머의 기본이니 언급할 필요도 없을 것입니다. XML 파일을 이용하는 것이 편하게 느껴질 정도가 되면 코드의 유연성을 높일 좋은 방법을 많이 생각해낼 수 있을 것입니다.
스펙을 실제로 활용하는 것은 API를 통해서입니다. 서블릿/JSP API는 스펙과는 달리 실제로 API를 통해 무엇을 할 수 있는지를 상세하게 알고 있어야 합니다. 이것은 비단 서블릿/JSP API뿐 아니라 자바 기본 API, 각종 라이브러리의 API도 마찬가지입니다. 필자가 이제껏 자바에 관해 받아본 질문 중 대부분은 API 문서만 잘 들여다 보면 해결되는 것이었습니다.
API 문서를 자주 찾아보는 습관을 들입시다. 리눅서들은 매뉴얼을 읽지 않고 질문하는 사람에게 RTFM(Read The Fucking Manual)이라는 대답을 해줍니다. 자바 역시 RTFM이 필요합니다. J2EE 기본서를 하나 사서 보는 것도 좋을 것입니다. J2EE 기본서에는 웹 관련 스펙 중 중요한 부분들, 서블릿/JSP 스펙 및 API들이 잘 정리되어 있습니다. 『Java Server Programming, J2EE Edition』 정도면 훌륭한 참고서가 될 것입니다.
이제부터 이런 기본적인 지식 중에 중요하지만 간과하기 쉬운 것들, 간단하지만 알면 도움이 되는 정보, 자주 부딪히게 되는 고민 등 몇 가지 작은 문제들을 짚어볼 것입니다. 모두 기본 학습 과정을 잘 거쳤다면 자연스럽게 알 수 있는 내용입니다. 이런 하나하나의 지식을 통해 자신에게 부족한 점을 되짚어볼 수 있는 계기를 마련할 수 있기를 바랍니다.
web.xml
배치 서술자(deployment descriptor)라고 부르는 web.xml은 웹 프로젝트를 구성하는 데 있어 필수적이면서 웹 애플리케이션의 동작을 여러 가지로 조정하는 기능을 합니다. 스트러츠를 사용하는 경우도 스트러츠를 사용하기 위한 설정은 web.xml에 하게 되는데 그 설정들이 무슨 의미를 가지고 있는지 정도는 상식으로 알아두는 것이 좋을 것입니다. <리스트 1>의 실제 스트러츠 설정 예제를 봅시다.
| ||||
PHP, ASP 등의 다른 서버 사이드 스크립트나 JSP 페이지는 페이지를 호출하는 경로에 실제 스크립트 파일이 존재해야 하지만 서블릿은 이와 달리 web.xml의 설정을 이용해 URL을 특정 서블릿으로 맵핑할 수 있습니다. <리스트 1>의 설정은 호출된 URL을 스트러츠의 Action으로 맵핑하기 위한 설정입니다.
servlet 설정에서 action이라는 이름의 서블릿을 org.apache.struts.action.ActionServlet 클래스로 등록하고 다음 servlet-mapping 설정에서 *.do라는 URL로 호출된 페이지들을 action이라는 이름의 서블릿으로 맵핑합니다. url-pattern 값을 *.nhn으로 바꾼다면 *.nhn으로 호출된 요청들이 ActionServlet으로 맵핑될 것입니다. 스트러츠는 이 ActionServlet에서 요청을 각 Action으로 분기시켜 줍니다. init-param은 서블릿을 초기화할 때 사용할 파라미터 값이며 getInitParameter 메쏘드를 통해 읽어올 수 있습니다. load-on-startup은 서블릿 엔진이 시작될 때 로드될 우선순위를 지정하는 값입니다.
인덱스 페이지를 지정하는 것도 web.xml에서 할 수 있습니다. 많은 웹 사이트들이 구체적인 경로 지정 없이 도메인명까지만 써줘도 페이지를 표시합니다. 이를테면 http://www.hangame.com으로 호출할 경우 다음과 같이 설정해두면 www.hangame.com의 /index.jsp를 호출하게 만들 수 있습니다.
| ||||
태그명에서 짐작할 수 있듯이 인덱스 페이지는 여러 개를 둬서 순서대로 검색하게 할 수 있습니다. 예를 들어 index.html과 index.jsp가 순서대로 지정된다면 서블릿 엔진은 index.html이 있으면 index.html을 보여주고 없으면 index.jsp를 호출합니다. 이것도 없으면 404 에러가 나거나 디렉토리 목록이 보이게 됩니다. 이 인덱스 페이지는 모든 경로에 대해 동작합니다.
이와 같은 설정의 경우 http://www.hangame.com/login/을 호출한다면 http://www.hangame.com/login/index.jsp를 찾게 되는 것입니다. 이 설정은 사실 아파치 등의 웹서버에서도 해줄 수 있으나 보통 웹 서버에서는 인덱스 페이지가 실제 파일로 존재해야 보여줄 수 있는데, 서블릿 엔진에서는 실제 파일로 존재하지 않고 서블릿 맵핑으로 지정만 되어 있어도 보여줄 수 있다는 장점이 있습니다.
접근 권한도 설정할 수 있습니다. 권한 체계가 간단한 웹 애플리케이션이라면 web.xml만으로도 충분한 권한 설정을 해줄 수 있습니다.
| ||||
<리스트 3>의 예는 서블릿 스펙 문서에 있는 예입니다. 이것의 의미는 GET이나 POST로 /retail/*과 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻입니다. 이외의 사용자는 권한이 없다는 401 에러 페이지를 보게 됩니다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능합니다. 실제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 합니다.
자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고, 톰캣의 실제 활용 예를 보는 것이 도움이 될 것입니다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공통적인 에외 처리를 위한 에러 페이지 설정도 가능합니다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것입니다.
예외 처리
자바의 강점 중 하나가 편리한 예외 처리 방식입니다. C 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리입니다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킵니다.
기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요합니다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹 사이트 방문객을 위한 부분 두 가지를 모두 고려해야 합니다.
먼저 프로그래머의 입장을 살펴봅시다. 예외가 발생하면 어디까지는 그냥 던지고 어디서 캐치하는 것이 좋을까요? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있습니다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일입니다. 대부분의 예외는 일단 그냥 던지는 것이 좋습니다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하지 않아도 된다는 것 때문입니다. 예외를 던짐으로써 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있습니다. 어떻게 처리해야 할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋습니다.
예외를 잡아서 처리해야 하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC(Model-View-Controller) 패턴으로 작성되어 있다면 컨트롤러에서 이 일을 하게 됩니다. 컨트롤러에서 예외를 보고 판단해 사용자에게 보여줄 화면을 결정하는 것입니다.
쇼핑몰에서 마일리지 적립액으로 상품을 구매하는 과정을 예로 들어보겠습니다. 만약 고객이 자신의 마일리지보다 더 많은 금액의 상품을 구매하려 한다면 구매를 수행하는 모델 객체에서 예외가 발생할 것입니다. 그러면 이 모델 클래스에서 예외를 바로 잡지 말고 던져서 구매 프로세스의 컨트롤러 객체에서 이를 잡아서 예외 페이지로 포워드시켜 예외 메시지를 보여주는 식으로 코딩하면 됩니다.
웹사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택 정보 등의 황당한 화면이 아닌 친절한 에러 메시지를 표시해 주는 것입니다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던져진, 정말 예상 밖의 예외를 모두 끌어 모아 처리하는 부분이 필요합니다.
서블릿/JSP에서는 이런 부분의 처리를 위한 기능을 여러 가지로 제공하고 있고 스트러츠 등의 프레임워크에서도 다양한 방법을 제공합니다. JSP의 에러 페이지 설정이 그 한 예입니다. 그러나 JSP의 에러 페이지 설정 방식은 모든 JSP 페이지에 설정해야 작동한다는 단점이 있습니다. 만약 에러 페이지 지정을 빠뜨린 페이지에서 예외가 발생한다면 서블릿 엔진의 에러 메시지가 그대로 웹사이트 방문객에게 전달되고 맙니다.
이런 부분을 쉽게 처리하기 위한 방법이 있습니다. 이것은 앞에서 설명했던 web.xml의 에러 페이지 설정을 이용하는 것입니다. 우선 다음의 예를 볼까요.
| ||||
이렇게 설정해 두면 웹 애플리케이션 전반에서 발생하는 예외 중 java.lang.Exception을 상속한 예외는 모두 잡혀서 /common/error.jsp 페이지에서 처리하게 됩니다. 예외가 발생하면 request 객체에 예외 상황에 대한 정보가 attribute로 저장된 후 /common/error.jsp로 포워드되어 이 곳에서 request에 담긴 정보를 바탕으로 예외 처리를 해줄 수 있습니다. 이 곳에서는 일반적인 에러 메시지를 사용자에게 보여주면 됩니다. 자바 예외 뿐 아니라 HTTP 에러 코드도 잡아낼 수 있습니다.
이를테면 없는 페이지를 호출해서 404 에러가 나는 경우 이를 잡아서 페이지가 없다는 에러 메시지를 좀더 친절한 메시지로 보여줄 수 있습니다. 덧붙여, 이 에러 처리 페이지는 가급적 순수한 서블릿으로 만드는 것이 좋습니다. 스트러츠의 Action으로 에러 페이지를 구성해본 적이 있었는데 설정 상의 문제로 스트러츠의 ActionServlet 로딩이 실패할 경우 예외를 제대로 표시하지 못합니다. JSP로 만드는 것도 나쁘진 않으나 복잡한 로직이 들어갈수록 서블릿이 코딩하기 더 편할 수 있습니다. 만약 이 에러 페이지 자체에서 또다시 예외가 발생하면 찾기 힘든 경우가 많기 때문에 주의를 많이 기울여야 합니다.
로깅
에러 페이지에서 해야 할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것입니다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야 합니다. 이 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야 합니다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫습니다.
여러가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만합니다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해 사용합니다. <리스트 5>는 commons-logging을 사용하는 예입니다.
| ||||
이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생깁니다. 만약 여기에 log4j를 붙여서 사용한다면 <리스트 6>과 같은 log4j 설정을 사용할 수 있습니다.
| ||||
이 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있습니다. 로거의 특성은 이름으로 상속됩니다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 됩니다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 됩니다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끌 수 있습니다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있습니다.
앞에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있습니다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송하는 시스템도 구상해 볼 수 있을 것입니다.
예외 추적
예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것입니다. 예외 추적의 출발점은 당연히 예외 스택 정보입니다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있습니다.
하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해 문제점을 예측하려 하곤 합니다. 이런 실제 상황에 기반을 두지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 됩니다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋습니다.
스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있습니다. 이 모든 정보를 다 찾아볼 필요는 없습니다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보입니다.
그렇다고 늘 제일 위의 정보를 봐야 하는 것은 아닙니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보가 같이 담겨 있습니다. 이런 정보는 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이 곳을 찾아보면 대부분의 문제점은 정확하게 추적할 수 있습니다.
또 한 가지 자바 초보자를 괴롭히는 문제는 NullPointerException입니다. 사실 이것은 초보자에게는 아주 까다로운 문제지만 조금만 알면 가장 찾기 쉬운 문제 중 하나가 NullPointerException입니다. NullPointerException은 객체의 멤버 변수나 메쏘드를 이용하려고 할 때 그 객체가 null인 경우에 발생합니다. 따라서 NullPointerException이 발생하면 앞의 방법대로 예외가 발생한 라인을 찾아들어간 다음 그 라인에서 멤버 지정 연산자(.) 앞에 있는 객체를 보면 됩니다. 이 사실만 알고 있어도 NullPointerException이 발생했을 때 어떤 객체가 null인지를 쉽게 찾아낼 수 있을 것입니다.
간혹 NullPointerException이 싫어서 다음과 같은 코드를 작성하는 경우가 있습니다.
if ("Y".equals(param)) doSomthing();
else doOther();
이런 코드는 조심해서 써야 합니다. param의 null 체크가 귀찮아서 이런 식의 코드를 쓰곤 하는데 만약 param의 값이 Y인 경우는 doSomething()을 실행하고, N이나 null이면 doOther()를 실행해야 하는 경우라면 이 코드는 문제가 없습니다. 그러나 만약 param은 null이면 안 되는 상황이라면 어떻게 될까요? 다른 부분의 버그로 param에 null이 들어와도 프로그래머는 이것을 알아차리지 못하고 넘어가게 됩니다. 즉, 버그를 은폐하는 코드가 됩니다.
당장의 문제를 발생하지 않더라도 이런 코드는 나중에 찾기 힘든 문제를 유발할 수 있습니다. 이런 경우는 그냥 NullPointerException이 발생하도록 내버려 두면 param에 null 값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있습니다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야 합니다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 맙시다.
한글 문제
웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제입니다. 한글 문제가 지금처럼 골치 아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야 하는 것들을 살펴보겠습니다.
자바는 문자열과 바이트 스트림을 다르게 취급합니다. 자바의 스트링은 유니코드의 문자셋을 사용하며 문자열을 파일에 쓰거나 네트워크로 전송하는 등 실제 입출력이 일어날 때는 문자열을 바이트 스트림으로 변환하게 됩니다. 이 때 바이트 스트림으로 변환하는 규칙이 인코딩입니다. 따라서 바이트 스트림으로 전달된 것을 문자열로 바꾸거나 문자열을 바이트 스트림으로 전달할 때는 반드시 인코딩을 지정해야 합니다.
이런 인코딩 중 한글을 표현할 수 있는 인코딩은 자바에서 사용하는 이름을 기준으로 하면 EUC-KR, MS949, UTF-8, UTF-16 정도가 있습니다. EUC-KR은 KSC5601-1987 기반 인코딩으로 한글의 모든 문자를 다 표현할 수 없습니다. MS949는 EUC-KR을 확장해 모든 한글을 표현할 수 있지만 비표준이고 코드 자체에 기술적인 결함이 많습니다. UTF-8과 UTF-16은 유니코드의 인코딩들이며 모든 한글을 표현할 수 있고 표준이며 한글 이외의 다른 언어와 함께 표현이 가능합니다.
보통 많이 쓰이는 EUC-KR은 RFC 표준 인코딩이긴 하나 한글의 확장 문자들을 제대로 표시하지 못합니다. 그래서 자바 웹 프로그래밍에서는 MS949를 많이 쓰게 됩니다. 자바에서 스트링 객체를 생성할 때는 이 중에 하나로 인코딩을 줘서 생성해야 한글을 표현할 수 있게 인코딩됩니다.
웹서버로 전달되는 요청은 클라이언트의 웹브라우저가 문자열을 바이트 스트림으로 인코딩하는데 이 때 사용하는 인코딩은 일반적으로 한글 윈도우의 기본 인코딩인 MS949입니다. 그런데 서블릿 엔진에서 요청을 처리하는 데 사용하는 기본 인코딩이 ISO-8859-1이기 때문에 아무 것도 지정하지 않으면 MS949로 인코딩된 바이트들을 ISO-8859-1 인코딩의 스트링 객체로 만들기 때문에 한글이 깨져보이게 됩니다. 따라서 기본 인코딩을 MS949로 지정하면 인코딩이 보존된 상태로 한글이 깨지지 않게 됩니다. HttpServletRequest.setCharacterEncoding() 메쏘드에서 이것을 지정할 수 있습니다.
그러나 이것에도 약간 문제가 있습니다. 서블릿 스펙상 이 메쏘드는 POST 요청에만 적용됩니다. 즉, POST 요청의 파라미터는 setCharacterEncdoing에서 지정한 인코딩으로 스트링 객체가 생성되기 때문에 한글을 보존할 수 있으나 GET 요청은 setCharacterEncoding의 적용을 받지 않기 때문에 GET으로 받은 파라미터는 인코딩 변환을 다시 해주어야 합니다. 다만, 이것은 서블릿 엔진에 따라 다릅니다. 톰캣의 경우도 4.1 버전과 5.0 버전이 다르게 동작하니 주의가 필요합니다.
웹서버에서 다시 클라이언트로 응답할 때는 반대의 과정입니다. 자바의 스트링 객체가 바이트 스트림으로 변환되며 이 때 역시 인코딩을 지정해야 합니다. 이 인코딩은 JSP 페이지에서 페이지 지시자의 pageEncoding 속성을 통해 지정할 수 있고, 서블릿 2.4 스펙에서는 HttpServletResponse.setCharacterEncoding을 사용할 수 있습니다. HTTP 요청을 읽는 과정과 역순이라고 생각하면 됩니다.
그리고 웹 서버에서 요청을 읽을 때 MS949를 지정해 주듯이 클라이언트의 웹 브라우저도 웹 서버에서 생성한 응답을 정확하게 읽으려면 어떤 인코딩을 사용해야 하는지 알아야 합니다. 이것을 지정해주는 것이 HTML의 Content-Type입니다. 다음과 같이 지정할 수 있습니다.
<meta http-equiv="Content-Type" content="text/html;charset=euc-kr" />
여기서 지정하는 charset은 원칙적으로는 당연히 웹 서버에서 응답 객체를 생성할 때 지정한 인코딩 값과 같아야 한글로 제대로 읽을 수 있습니다. 그러나 여기 지정하는 charset이 RFC 표준 문자셋이 아닐 경우 브라우저에 따라 인식하지 못할 수도 있습니다. 따라서 MS949로 인코딩했다면 MS949를 지정해야 정상이지만 MS949가 RFC 표준이 아니기 때문에 문제가 생길 수 있습니다.
그렇다고 응답의 인코딩을 EUC-KR로 지정하게 되면 확장 한글을 표시할 수 없기 때문에 문제가 됩니다. 그래서 페이지 인코딩은 MS949로 하지만 Content-Type에는 euc-kr을 지정해 주게 되는 것입니다. 물론 이렇게 되면 경우에 따라 확장 한글이 깨질 수 있지만 다행스럽게도 대부분의 브라우저에서 이렇게 지정하면 잘 동작합니다.
사실 이 부분은 응답 스트림에 적용되는 인코딩과 HTML Content-Type에 지정하는 인코딩이 같기만 하면 되기 때문에 굳이 MS949를 사용할 필요는 없고 UTF-8 등의 인코딩을 사용해도 무방합니다. 따라서 응답 스트림의 인코딩도 UTF-8로 하고 Content-Type도 UTF-8로 지정하는 것이 가장 확실한 방법일 수 있습니다. 또한, HTML의 Content-Type에 UTF-8이 지정되어 있으면 이 페이지에서 폼을 전송할 경우에도 UTF-8로 인코딩되어 요청을 파싱하는 쪽에서도 UTF-8을 사용할 수 있습니다.
유니코드의 인코딩들인 UTF-8, UTF-16은 한 인코딩으로 다국어를 처리할 수 있기 때문에 다국어 지원이 필요한 웹 애플리케이션은 실제로 UTF-8로 작성된 것이 많습니다. 다국어 지원이 필요 없다고 해도 UTF-8을 사용하는 것이 오히려 한글 문제를 더 쉽게 해결하는 방법이 될 수 있습니다.
웹 뿐 아니라 데이터베이스나 파일에 입출력을 할 때도 마찬가지의 원리가 적용됩니다. 사용하는 인코딩이 다르면 변환 과정을 거쳐야 합니다. 이것은 리눅스나 유닉스에서 문제가 될 수 있습니다. 리눅스는 MS949를 지원하지 않고 EUC-KR만 지원하기 때문입니다. 따라서 윈도우에서 개발하고 리눅스에서 돌리는 경우 문제가 되는 경우가 간혹 있습니다.
MS949가 또 하나 문제가 되는 영역은 XML 파서입니다. 현재 가장 널리 사용되는 XML 파서는 Xerces인데 이 파서는 RFC 표준 문자셋 외에는 지원하지 않기 때문에 MS949 인코딩은 파싱 에러가 납니다. 그런 반면 JDK 1.4에 포함된 파서인 Crimson은 네임스페이스 파싱에 버그가 있습니다. MS949를 XML 인코딩으로 쓸 경우 XML 파서 선택이 문제가 될 수 있는 것입니다.
다행스럽게도 JDK 5.0에 포함된 파서는 Xerces를 썬에서 패치한 것인데 이것은 아무 문제가 없습니다. 하지만 여전히 많은 오픈소스 라이브러리들이 Xerces를 사용하고 있기 때문에 문제가 되는 경우는 계속 나타날 수 있을 것입니다. 이것 때문에라도 UTF-8을 사용할 필요가 있습니다.
자바에서의 한글 문제는 문자열과 바이트 스트림의 변환에 인코딩이 주어져야 한다는 사실만 생각하면 다 쉽게 해결할 수 있습니다. 역시 기본이 잘 갖춰져 있으면 한글 문제도 쉽게 해결할 수 있는 것입니다.
URL 인코드
URL 인코딩이 필요한 것은 URL에 사용 가능한 문자가 제한되어 있기 때문입니다. URL 스펙(RFC 1738)에 정의된 바로는 URL에 사용할 수 있는 문자는 알파벳, 숫자와 몇 가지의 특수문자뿐입니다. 따라서 다양한 문자를 URL로 전달하려면 URL에서 허용하는 문자로 변환해 전달해야 합니다. 이것은 GET 요청의 파라미터로 값을 전달하려할 때 문제가 됩니다.
예를 들어 http://website.com/process.jsp에 로그인되지 않은 상태에서 접근하면 자동으로 로그인 페이지인 http://website.com/login.jsp로 리다이렉트된 후 로그인을 하면 원래 요청했던 페이지로 다시 리다이렉트되도록 해야 한다고 합시다.
그러면 /process.jsp에서는 로그인 페이지로 리다이렉트시키면서 파라미터로 현재 요청한 URL, 즉 /process.jsp를 넘겨주고 login.jsp에서는 로그인 처리가 끝난 후 이 URL로 다시 리다이렉트시키면 됩니다. 여기서 /process.jsp에서는 http://website.com/login.jsp?redirect=http://website.com/process.jsp와 같은 형식으로 리다이렉트를 해주면 될 것입니다.
여기서 문제는 redirect 파라미터의 값이 URL이기 때문에 URL 안에 URL이 들어간 형태가 되어 제대로 파싱되지 않는다는 것입니다. 그래서 파라미터로 넘겨야 하는 URL 부분을 URLEncoder로 인코딩해 http://website.com/login.jsp?redirect=http%3A%2F%2Fwebsite.com%2Fprocess.jsp와 같은 형태로 넘겨야 합니다. 이 값을 받는 부분에서는 다시 디코딩을 해줄 필요가 없습니다.
URL은 자동으로 웹 서버에서 파싱할 때 디코딩을 해주기 때문입니다. URL을 통해 GET 요청의 파라미터로 보내야 하는 값은 반드시 URL 인코딩을 거쳐야 한다는 사실만 기억하세요. 참고로 자바스크립트에서도 escape, unescape 함수를 통해 URL 인코딩, 디코딩과 유사한 작업을 수행할 수 있습니다.
클래스패스의 리소스 사용법
웹 애플리케이션은 보통 애플리케이션의 설정을 담고 있는 파일이 필요합니다. web.xml, struts-config.xml 등의 설정 파일들은 보통 웹 애플리케이션의 /WEB-INF/에 위치하는데 그 외에 애플리케이션에서 사용하는 파일들은 어디에 놓고 사용하는 것이 편리할까요? 가장 관리하기 쉽고 부가적인 작업이 적은 방법은 클래스 패스에 두는 것입니다. /WEB-INF/classes에 두면 자바의 클래스 로더를 이용해 이런 파일들에 접근할 수 있습니다. log4j 등 많은 라이브러리들이 자신의 설정 파일을 클래스 패스에서 가장 먼저 찾게 됩니다. <리스트 7>의 예제를 볼까요.
| ||||
이 코드는 클래스 패스에서 config.xml을 읽습니다. 웹 애플리케이션의 기본 클래스 패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 됩니다. 이것으로 jar 파일 안의 내용도 읽을 수 있습니다. 이 경우는 ClassLoader.getResourceAsStream을 통해 스트림으로 파일 내용을 읽을 수 있습니다.
대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일 중 자바 소스가 아닌 파일들을 자동으로 클래스 패스로 복사해주므로 이용하기도 편리합니다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있습니다.
서블릿/액션 멤버 변수 공유 문제
JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹 사이트 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었습니다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었습니다. <리스트 8>을 봅시다.
| ||||
얼핏 별 문제가 없어 보이지만 이 코드는 심각한 문제가 있습니다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용됩니다. 때문에 A와 B라는 두 사용자가 동시에 이 서블릿을 호출하게 되면 A의 호출을 수행하는 중에 B의 호출이 userInfo의 값을 바꿔버릴 수 있습니다. 그러면 A는 B의 정보를 보거나 그 반대의 경우가 생길 수 있는 것입니다.
혼자서 테스트할 때는 한 번에 한 쓰레드만 service 메쏘드를 호출하기 때문에 이런 문제가 잘 드러나지 않기 때문에 별 문제 없는 줄 알고 있다가 서비스를 오픈하고 나면 문제가 되는 경우가 있으므로 조심해야 합니다. JSP에서 <%! %>를 통해 선언하는 내용도 마찬가지 문제가 발생하므로 주의해야 합니다. 이런 내용 역시 자바 클래스와 멤버 변수의 기본 개념을 이해하고 서블릿 스펙만 한 번 읽어본다면 금방 알 수 있는 내용입니다.
생각하기
이 내용을 읽으면서 모르는 내용이 하나도 없었다면 자바 웹 프로그래머로서 어느 정도 기본은 되어 있다고 할 수 있습니다. 이런 내용은 그 하나하나에 대한 지식을 쌓는 것도 중요하지만 더 중요한 것은 이런 내용을 알아야 한다는 사실을 아는 것입니다.
무엇을 알아야 하는가를 가르쳐주는 것은 스펙입니다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있진 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있습니다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는지 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수 있는 것입니다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요합니다. 기본적으로 www.ietf.org,jcp.org,java.sun.com, www.w3.org 정도의 사이트에는 익숙해지는 게 좋을 것입니다.
많은 프로그래머들이 실제로 자기 손으로 프로그래밍해보는 게 실력이 느는 제일 좋은 방법이라고 말하지만 필자는 여기에 동의하지 않습니다. 물론, 실제 경험을 쌓는 것이 필수적인 과정이긴 합니다. 그러나 기본 지식을 등한시한 상태에서 코딩만 해보는 것으로는 실력이 잘 늘지 않습니다.
코딩 기술은 늘 수 있겠지만 정말 실제 서비스를 해야 하는 프로그래밍에서 중대한 실수를 저지르게 되거나 남들이 쉽게 하는 일들을 어렵게 빙 둘러가면서 하게 될 수 있습니다. 그래서 기본기를 갖추는 것이 중요한 것입니다.
거듭해서 기본의 중요성을 강조했는데 한 가지 덧붙이고 싶은 말은 이런 기본 지식 뿐 아니라 기본을 활용하는 능력을 키우는 것도 잊지 말아야 한다는 것입니다. 앞서 언급한 예외 처리 같은 내용은 기본이긴 하나 자바 문법만 잘 안다고 알 수 있는 내용은 아니며 기본을 바탕으로 좋은 판단을 내릴 수 있는 능력이 있어야 합니다.
결국 좋은 프로그래머가 되려면 먼저 좋은 사고 능력을 가지고 있어야 하는 것입니다. 글짓기를 잘하는 방법으로 흔히 다독(多讀), 다작(多作), 다상량(多商量)을 이야기합니다. 많이 읽고 많이 쓰고 많이 생각하라는 것입니다. 프로그래밍도 이와 비슷합니다. 각종 스펙과 좋은 코드를 많이 읽어보고 직접 코딩도 많이 해보면 분명 실력이 늘지만 이것으로는 충분치 않습니다.
프로그래밍을 하면서 끊임없이 생각해야 합니다. 지금 작성한 코드는 좋은 코드인가, 이렇게 코딩하면 불편한데 개선할 방법은 없을까, 이 API들로 무엇을 할 수 있을까, 개발 속도를 향상시키려면 어떻게 해야 할까 등 생각을 많이 해야 진짜 발전을 이룰 수 있습니다.
만일 손가락이 아플 정도로 하루 종일 키보드를 두드리고 있다면 좋은 프로그래머라고 할 수 없습니다. 생각하는 데 좀 더 많은 시간을 써야 합니다. 모니터를 구부정하게 들여다보면서 키보드를 두드리는 것은 것보다는 의자에 편안히 기대서 생각하는 시간을 늘려보세요. 복잡한 문제가 있으면 바깥 공기를 쐬면서 산책을 하면서 생각을 하는 것도 좋습니다. 굳이 건강을 생각하지 않더라도 걷는 것은 두뇌를 활성화하기 때문에 해결책을 더 빨리 찾을 수 있게 합니다.
남들이 보기에는 게을러 보일 수 있지만 놀고 있는 게 아니라는 것은 결과로 충분히 보여줄 수 있습니다. 물론 이런 생각을 잘 이어나가기 위해서는 생각의 재료가 되는 기본에 충실해야 함은 물론입니다. 어둠침침한 구석에 앉아 키보드만 두드리는 긱(geek)이 아닌 보다 인간다운 프로그래머가 됩시다.@
* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다
.
반응형
'정보 > IT 관련 기사' 카테고리의 다른 글
| [세련된 자바 웹 프로그래머 되기] ③ 패턴·프레임워크·XP (0) | 2012.02.18 |
|---|---|
| [세련된 자바 웹 프로그래머 되기] ② 웹 프로젝트 개발 환경 갖추기 (0) | 2012.02.18 |
| ‘HTML5’ 활성화에 전문가 그룹 뭉쳤다 (0) | 2012.01.31 |
| 제12회 한국자바개발자(JCO) 컨퍼런스 2월 18일 토요일 (0) | 2012.01.30 |
| 다음 코딩대회, 매시업의 진수를 보여라 (0) | 2012.01.30 |