Binary Coder's Weblog: Dev. Note Archives Dev. Note|Early Adopter|Life Style|Monolog|News|Software|Blog Home Search this site: Binary Coder's Weblog It's just sometimes, it's always me. How dark can these hallways be? May 31, 2005 세련된 자바 웹 프로그래머 되기 | 기본기 갈고닦기 View: 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 문서만 잘 들여다 보면 해결되는 것이었습니다. http://crowe.wowdns.com:8000/archives/dev_note/ (1 of 158)2005-07-05 오전 11:32:43 Binary Coder's Weblog: Dev. Note Archives 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>의 실제 스트러츠 설정 예제를 봅시다. <리스트 1> web.xml 서블릿 맵핑 <servlet> <servlet-name>action</servlet-name> <servlet-class> org.apache.struts.action.ActionServlet </servlet-class> <init-param> <param-name>config</param-name> <param-value> /WEB-INF/struts-config.xml </param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> 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은 서블릿을 초기화할 때 사용할 파라미터 값이며 http://crowe.wowdns.com:8000/archives/dev_note/ (2 of 158)2005-07-05 오전 11:32:43 Binary Coder's Weblog: Dev. Note Archives getInitParameter 메쏘드를 통해 읽어올 수 있습니다. load-on-startup은 서블릿 엔진이 시작될 때 로드될 우선순위를 지 정하는 값입니다. 인덱스 페이지를 지정하는 것도 web.xml에서 할 수 있습니다. 많은 웹 사이트들이 구체적인 경로 지정 없이 도메인명까지 만 써줘도 페이지를 표시합니다. 이를테면 http://www.hangame.com으로 호출할 경우 다음과 같이 설정해두면 www. hangame.com의 /index.jsp를 호출하게 만들 수 있습니다. <리스트 2> web.xml 인덱스 페이지 설정 <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> 태그명에서 짐작할 수 있듯이 인덱스 페이지는 여러 개를 둬서 순서대로 검색하게 할 수 있습니다. 예를 들어 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> web.xml 접근 제한 설정 <security-constraint> <web-resource-collection> <web-resource-name>retail</web-resource-name> <url-pattern>/acme/retail/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>CONTRACTOR</role-name> <role-name>HOMEOWNER</role-name> </auth-constraint> </security-constraint> <리스트 3>의 예는 서블릿 스펙 문서에 있는 예입니다. 이것의 의미는 GET이나 POST로 /retail/*과 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻입니다. 이외의 사용자는 권한이 없다는 http://crowe.wowdns.com:8000/archives/dev_note/ (3 of 158)2005-07-05 오전 11:32:43 Binary Coder's Weblog: Dev. Note Archives 401 에러 페이지를 보게 됩니다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능합니다. 실 제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 합니다. 자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고, 톰캣의 실제 활용 예를 보는 것이 도움이 될 것입니다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공 통적인 에외 처리를 위한 에러 페이지 설정도 가능합니다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것입니 다. 예외 처리 자바의 강점 중 하나가 편리한 예외 처리 방식입니다. C 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소 한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리입니다. 하지만 의외로 많은 자바 프로그래머들이 예외 처 리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킵니다. 기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대 한 많은 고민이 필요합니다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹 사이트 방문객을 위한 부분 두 가지를 모두 고려해야 합니다. 먼저 프로그래머의 입장을 살펴봅시다. 예외가 발생하면 어디까지는 그냥 던지고 어디서 캐치하는 것이 좋을까요? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있습니다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일입니 다. 대부분의 예외는 일단 그냥 던지는 것이 좋습니다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하 지 않아도 된다는 것 때문입니다. 예외를 던짐으로써 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있습니다. 어떻 게 처리해야 할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋습니다. 예외를 잡아서 처리해야 하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC (Model-View-Controller) 패턴으로 작성되어 있다면 컨트롤러에서 이 일을 하게 됩니다. 컨트롤러에서 예외를 보고 판단 해 사용자에게 보여줄 화면을 결정하는 것입니다. 쇼핑몰에서 마일리지 적립액으로 상품을 구매하는 과정을 예로 들어보겠습니다. 만약 고객이 자신의 마일리지보다 더 많은 금액의 상품을 구매하려 한다면 구매를 수행하는 모델 객체에서 예외가 발생할 것입니다. 그러면 이 모델 클래스에서 예외 를 바로 잡지 말고 던져서 구매 프로세스의 컨트롤러 객체에서 이를 잡아서 예외 페이지로 포워드시켜 예외 메시지를 보여 주는 식으로 코딩하면 됩니다. 웹사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택 정보 등의 황당 한 화면이 아닌 친절한 에러 메시지를 표시해 주는 것입니다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던져진, 정말 예상 밖의 예외를 모두 끌어 모아 처리하는 부분이 필요합니다.