'거미줄세상' 카테고리의 글 목록

'거미줄세상'에 해당되는 글 12건

2008.10.24 '커뮤니케이션 비전 2008' 구글의 존 래거링 오픈인터뷰
2008.10.23 웹애플리케이션 컨퍼런스
2008.08.07 역겨운 역기능
2008.06.03 REST(REpresentational State Transfer)
2008.05.31 구글 어스
2008.03.15 블로그 코리아, 블로거 간담회에 다녀왔어요. 4
2008.02.20 URI? URL? URN?
2008.02.03 제9회 한국 자바 개발자 컨퍼런스
2007.12.22 [담아온글] 자바 웹 프로그래머의 기본
2007.12.20 창조경영!! 기업블로그로 무장하라 - (주) 네트빌

'커뮤니케이션 비전 2008' 구글의 존 래거링 오픈인터뷰

거미줄세상 l 2008. 10. 24. 23:21

웹애플리케이션 컨퍼런스

웹 사이트 성능 튜닝 - 박경훈
HTTP 요청줄이기 - 10x10보다 100x1 이 더 낫다.
캐시의 활용 - 만료기간 설정
CSS와 스크립트의 위치 - CSS는 위에 스크립트는 아래에..
멀티커넥션 - 여러개의 도메인 사용
Gzip활용(텍스트파일에만, 큰 파일에만 적용)
스크립트 최소화 - JSMIN 이용
Etag(Entity Tag) 관련..
리다이렉트 줄이기
http://developer.yahoo.com/performance/rules.html
http://hoons.kr/Lecture/LectureMain.aspx?idx=42

리치웹을 이용한 매쉬업 웹 애플리케이션 개발 - 오창훈

웹 애플리케이션 디자인 방법론 - 황리건

웹 접근성 테스트 기반 개발 방법 - 조훈
장애인 차별금지 법 통과로 웹 접근성 표준이 이슈화 되고있음.

대형 웹 서비스를 위한 아키텍처 관점에서의 과제 - 함종민
StoryBlender 해외 도전기 - 고진영
향후 10년간 인터넷 서비스 전망 - 손경완
위젯, 웹 개발자의 신천지 인가? - 표철민,조만영,김유진
지도 서비스의 현황과 미래 - 김민오
Blue-Chip Products - 조엘 스폴스키
오픈 API 해커문화 - 정진호

론치패드 신규 웹 서비스
terebe.com - 동영상 인터렉션 서비스
vlaah.com - 감성 인터렉션 서비스
makegamenow.com - rpg 게임 제작 서비스
tokplay.com - 안드로이드 영상 메세지 서비스
sealtale.com - 블로그 분류/연결 서비스?

거미줄세상 l 2008. 10. 23. 22:41

역겨운 역기능

나는 웹에대한 신봉자는 아니더라도,

웹에 반해서 웹을 위해 일을 하는 사람으로서

이런 일들을 볼때마다

정말 짜증나고 가슴이 아프다.

http://www.kukinews.com/news/article/view.asp?page=1&gCode=all&arcid=0920993928&code=41121111&cp=nv1

무엇이든 동전의 양면처럼

역기능이 존재할 수 밖에 없는 건가.

그런데 저런건

정말 역겹고.. 슬프다.

거미줄세상 l 2008. 8. 7. 11:49

REST(REpresentational State Transfer)

http://blog.naver.com/ggomaterran?Redirect=Log&logNo=150010426915

http://blog.naver.com/ecogeo?Redirect=Log&logNo=100022935682

http://blog.naver.com/kangsebo?Redirect=Log&logNo=41876713

http://en.wikipedia.org/wiki/Representational_State_Transfer

이거 뭐야 도대체..

http://javaora.tistory.com/16

음.. 이게 그나마 간단 명료...

거미줄세상 l 2008. 6. 3. 01:15

구글 어스

예술이란 이런것? ㅎ

http://code.google.com/apis/earth/

지대 멋지삼

거미줄세상 l 2008. 5. 31. 12:44

블로그 코리아, 블로거 간담회에 다녀왔어요.

지난 목요일 13일이죠, 비가 오는건지 안오는 건지 헷갈리던 날 강남 토즈를 향해 지하철을 타고 달려갔죠, 늦을 줄 알았는데 다행히 늦지 않고 7시에 딱 맞춰서 도착했습니다.

저는 이런 간담회에 가는게 처음이라 어떤 분위기일까 궁금했습니다. 마치 기자회견 같은 분위기더군요. 노트북을 가져오신 분도 많았고 다들 고성능 디카 및 캠코더? 를 들고 오셨더라구요. 저는 머... 노트북도 아직 장만 못했고, 후질건한 디카하나 들고 갔는데 기가 팍 죽었습니다.ㅎ

(블코 사장님 블로그에서 퍼온건데 제가 안나와서 아쉽..ㅠ)

많은 말씀을 해주셨지만, 그중에서도 블로거 뉴스룸 과 블로그 잇 에 대한 설명이 기억에 남네요.

블로거 뉴스룸은 블로거가 다양한 분야의 다양한 업체들로부터 자료를 제공받고 그 자료를 바탕으로 쓰여진 블로그들을 취합하여 보여주는 방식입니다. 저같이 게으른 사람한테는 정말 좋은 소스가 될것 같습니다. 근데 너무 포스트가 상업적으로 흐르지는 않을까 하는 걱정인데, 뭐 글쓰는건 블로거 마음이니까요. 홍보를 원하는 업체는 블로거 구미에 맞는 자료를 내놓게 되겠죠. 활성화가 된다면 말이죠.^^ 그리고 이사님도 말씀하셨지만 대기업들은 조중동에 보도자료를 내면 바로바로 홍보가 되기때문에 이러한 방식에 회의적일테고, 중소기업들을 타겟으로 잡자면, 돈없는 중소기업들이 과연 이런 홍보방식을 가질지 의문이 들었습니다. 그럴려면 블로거뉴스룸이 그만큼의 파급효과를 낼 정도로 활성화 되야겠지요. 일단은 지금은 기업들에게 돈을 안받고 있다고 합니다. 다양한 소스를 끌어들여와야 되기때문이겠지요. 좀 더 활성화 되서 좋은 수익 모델로 정착했으면 하는 바램이네요.

블로그 잇은.. 태그를 바탕으로 한 커뮤니케이션 도구라고 설명이 나와있네요. 블로그 잇을 설치하게 되면 포스트 작성시 등록한 태그와 일치하는 단어가 해당 포스트에 있으면 그 단어에 자동으로 링크를 걸어 준다는 겁니다. 그 링크를 클릭하면 포스트잇 모양의 블로그 잇이 튀어나오고 그 블로그잇에는 관련 글들과 키워드에 맞는 광고가 담겨있는거죠(이거는 옵션) 블로그잇의 전체적인 모양새는 올블로그의 올블릿과 흡사하지만, 블로그 잇은 태그 중심의 모델이라는 게 다르고 단어를 클릭해야 나오기 때문에 저처럼 광고를 덕지덕지 지저분하게 붙일 필요가 없게 되서 좋은 것 같습니다. 사용해보려고 하니 준비중이라고 나오네요, 얼른 오픈해주시길 기대합니다.
(아.. 제가 소개한건 '블로그 잇 링크' 입니다. 그냥 블로그 잇과 차이가 있음..;)

그외에 '블업'이라는 추천제도를 올해부터 도입한다고 합니다. 다른 메타블로그의 추천시스템과 비슷하고요, 한가지 특징은 자신의 글을 추천해준 블로그를 '업드린 블로거'라고 해서 확인할 수 있다고 하네요.'이제 좋은 글을 만나면 UP드려 주세요' 라는 캐치 프라이즈가 재미있었습니다.

저는 사실 블로그코리아를 사용하지 않고 있었는데요, 상당히 노력하는 곳이구나 라는 생각이 들었습니다. 블로그 코리아가 지향하는 바는 업체에 종속적이지 않은 블로거 간의 소통, 그리고 기업이다 보니 이를 이용한 비즈니스 모델 개발 이었던거 같습니다. 블로그가 많은 발전이 있었지만, 앞으로 나아가야할 길이 더 많이 남아있다고 생각하는데 블로그 코리아가 앞장설 수 있길 응원합니다.

여담..
사진을 몇장 안찍었습니다. 워낙 뒤에 앉은 데다가 디카도 꼬져서 줌인도 잘 안되고ㅎ 건질 만한 사진은 이거 하나.. ;

토즈에서 가져온거 같아요. 저녁으로 때웠는데 먹을만 했습니다. 배가 안차서 집앞에서 순대를 또 사먹긴 했지만..;

그날 나눠준 티셔츠.. 이쁜 듯ㅎ 나눠주신 분도 이쁘셨고, 미디어 유(블코 서비스하는 회사)에는 미인이 많은 것 같았습니다.^^

2차 모임도 가진다고 했었는데 재미있었는지 모르겠네요, 저는 그날 무지 피곤했던 관계로 '다음기회에..Zzz'

거미줄세상 l 2008. 3. 15. 13:40

URI? URL? URN?

URI(Uniform Resource Identifier)은 자원을 참조할 때 각 자원의 식별을 나타내기 위한 일종의 규약이다.

URL(Uniform Resoruce Locator)과 URN(Uniform Resoruce Name)은 URI를 표현하기 위한 한 방법이다.

URL은 자원의 위치정보를 이용해서 표현하는 방식이고(일반 인터넷 주소를 생각하면 됨),

URN은 고유의 이름으로 식별하는 방법이다(온라인 서점에서 책살때 볼수 있는 ISBN같은 것).

아주 약간더 자세한 설명은 아래 포스트 참조.

http://blog.naver.com/wikiware?Redirect=Log&logNo=100019145703

http://ez2web.com/blog/read.asp?seqPost=87

이 글은 스프링노트에서 작성되었습니다.

거미줄세상 l 2008. 2. 20. 13:24

제9회 한국 자바 개발자 컨퍼런스

거미줄세상 l 2008. 2. 3. 15:18

[담아온글] 자바 웹 프로그래머의 기본

정말 자바 웹 프로그래머가 알고있어야 할 기본입니다.

굉장히 방대한 분량이 간략히 정리되어있습니다.

=================================================================

마소 2005년 1월호 기고

1 제목

2 발문

3 필자 소개

4 본문

4.1 서론, 어떻게 공부할 것인가

4.2 본론

4.2.1 web.xml
4.2.2 예외 처리
4.2.3 로깅
4.2.4 예외 추적
4.2.5 한글 문제
4.2.6 URL 인코드
4.2.7 클래스패스의 리소스 사용법
4.2.8 서블릿/액션 멤버 변수 공유 문제

4.3 결론, 생각하기

4.4 참조

1 제목 #

자바 웹 프로그래머의 기본

2 발문 #

프로그래밍 초보자가 능히 한 사람 몫을 할 정도로, 혼자 코딩하도록 내버려둬도 다른 사람들이 불안에 떨지 않을 만큼 성장하는 가장 빠른 방법은 무엇일까? 디자인 패턴을 공부하고 최신 기술을 익히고 실전 프로그래밍을 많이 해보는 것? 그것도 물론 중요하다. 그러나, 이보다 훨씬 더 중요한 것은 기초를 다지는 것이다. 슬램덩크에서 강백호는 농구부 입단 후 2주일 간 드리블 연습만 했고 이것이 그가 빠른 시간 안에 한 사람 몫을 해내는데 밑거름이 되었다. 잠시 더블 클러치 연습은 멈추고 드리블을 해보자. 복잡한 이론, 어려운 신기술은 잠시 접어두고 프로그래머로서의 기본을 재점검해보자.

3 필자 소개 #

박영록 refactorer@naver.com code for human, not for programmer. 인간다운 프로그래머, 게으른 프로그래머를 지향한다. 현재 NHN에서 프레임웍 개발과 서버 관리를 담당하고 있다.

4 본문 #

4.1 서론, 어떻게 공부할 것인가 #

4년 전, 학교에서 어느 벤처 경영인의 강연을 들은 적이 있다. 미국에서 벤처를 시작해서 어느 정도의 성공을 거둔 기업가였다. 그는 강연 내내 기본을 강조했다. 미국과 한국의 기업 문화의 차이를 비교하면서 미국의 벤처들은 대체로 경영인으로서의 기본적으로 지켜야할 것들을 잘 지키는 반면 한국의 벤처는 기본적인 것들을 제대로 지키지 못하고 그로 인해 실패하는 경우가 많다고 했다. 벤처 붐이 일 때 수많은 학생 벤처가 경영에 대한 무지로 가진 기술을 펼쳐보지도 못하고 망한 현상에 대해 벤처는 경영이며 경영을 하려면 경영에 대해 배워야하는 것은 기본인데 그 기본이 지켜지지 않았기 때문이라고 했다. 당시 부도덕한 벤처 기업가들의 행태가 사회적으로 논란이 되고 있었는데 이에 대해서는 사회인으로서의 기본적인 소양이 갖추어져 있지 않기 때문이라고 했다. 그는 모든 것을 기본이란 말 하나로 설명했다. 기본이 물론 성공의 충분조건은 아니다. 그러나, 기본을 지키지 않고는 성공할 수 없다. 어떤 분야든 이것은 예외가 없을 것이다.

그렇다면 프로그래머, 그 중에서도 자바 웹 프로그래머의 기본은 무엇일까? 당연히 자바 언어에 대해서 잘 아는 것이다. 웹 프로그래밍이라는 것도 결국 사용하는 API가 다른 것 뿐, 좋은 자바 웹 프로그래머가 되려면 먼저 좋은 자바 프로그래머가 되어야한다. 너무도 당연한 말 같지만 현실은 그렇지 않다. 여러 자바 커뮤니티에 가보면 자바에 대한 정말 기본적인 질문들이 수도 없이 올라오며, 현업 프로그래머 중에도 기초가 부족한 사람이 너무나도 많다. 자바 프로그래머라면 자바에 관한 기본서 하나 정도는 마스터하고 시작하도록 하자. 자바 기본서들은 대체로 내용이 충실하므로 아무 거나 사도 나쁜 선택은 아닐 것이다. 그래도 추천이 필요하다면 Thinking in Java를 추천한다. 프로그래밍에 처음 입문하는 거라면 예제들을 직접 따라해보는 것도 좋을 것이다.

자바에 익숙해졌다면 다음 단계는 웹 기술이다. 웹 프로그래밍의 기본은 웹과 관련된 스펙(Specification)에 대한 지식, 구체적으로 Servlet/JSP 스펙, HTTP 스펙(RFC 2068), HTML ?W3C 스펙 등이다. 이 스펙들에 대해 상세히 다 알 필요는 없지만 웹 프로그래밍에서 사용하는 API들이 어떤 스펙에 기반하고 있는지, 자세히 알고 싶으면 무엇을 찾아야하는지는 알아야한다. 공대생이 공학수학의 내용을 전부 알고 있을 필요는 없지만 미분방정식을 풀고 싶으면 어느 페이지를 찾아봐야하는지는 알고 있어야하는 것처럼 어떤 요구사항이 발생했을 때 그 요구사항을 구현하려면 어떤 스펙을 찾아봐야하는지 정도는 알고 있어야한다. 그리고 의외로 많은 웹 프로그래머들이 HTML, CSS에 익숙지 않은데 이 때문에 웹사이트의 브라우저 호환성이 떨어질 뿐만 아니라 지저분한 코드를 양산하게 된다. HTML 코드 역시 유지보수 대상이 되는 코드이며 자바 코드 못지 않게 깔끔하게 유지할 수 있어야함을 기억하자. 이를 위해서는 HTML과 CSS에 대해 상세히 알아둘 필요가 있다. XML은 이제 프로그래머의 기본이니 언급할 필요도 없을 것이다. XML 파일을 이용하는 것이 편하게 느껴질 정도가 되면 코드의 유연성을 높일 좋은 방법들을 많이 생각해낼 수 있을 것이다.

스펙을 실제로 활용하는 것은 API(Application Programming Interface)를 통해서이다. Servlet/JSP API는 스펙과는 달리 실제로 API를 통해서 무엇을 할 수 있는지를 상세하게 알고 있어야한다. 이것은 비단 Servlet/JSP API 뿐 아니라 Java 기본 API, 각종 라이브러리의 API도 마찬가지다. 필자가 이제껏 자바에 관해 받아본 질문 중 대부분은 API 문서만 잘 들여다보면 해결되는 것이었다. API 문서를 자주 찾아보는 습관을 들이자. 리눅서들은 매뉴얼을 읽지 않고 질문하는 사람에게 RTFM(Read The Fucking Manual)이라는 대답을 해준다. 자바 역시 RTFM이 필요하다. ?J2EE 기본서를 하나 사서 보는 것도 좋을 것이다. ?J2EE 기본서에는 웹 관련 스펙 중 중요한 부분들, Servlet/JSP 스펙 및 API들이 잘 정리되어 있다. Java Server Programming, ?J2EE Edition 정도면 훌륭한 참고서가 될 것이다.

이제부터 이런 기본적인 지식 중에 중요하지만 간과하기 쉬운 것들, 간단하지만 알면 도움이 되는 정보들, 자주 부딪히게 되는 고민들 등 몇 가지 작은 문제들을 짚어볼 것이다. 모두 기본 학습 과정을 잘 거쳤다면 자연스럽게 알 수 있는 내용들이다. 이런 하나하나의 지식들을 통해 자신에게 부족한 점을 되짚어볼 수 있는 계기를 마련할 수 있기를 바란다.

4.2 본론 #

4.2.1 web.xml #

배치 서술자(deployment descriptor)라고 부르는 web.xml은 웹 프로젝트를 구성하는데 있어 필수적이면서 웹 애플리케이션의 동작을 여러 가지로 조정하는 역할을 한다. 스트러츠를 사용하는 경우도 스트러츠를 사용하기 위한 설정은 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을 특정 서블릿으로 매핑시킬 수 있다. 위의 설정은 호출된 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를 호출하게 만들 수 있다.

<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만으로도 충분한 권한 설정을 해줄 수 있다.

<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>

위의 예는 서블릿 스펙 문서에 있는 예다. 이것의 의미는 GET이나 POST로 /retail/*와 같은 요청은 CONTRACTOR와 HOMEOWNER라는 role을 가진 사용자에게만 허락하겠다는 뜻이다. 이외의 사용자는 권한이 없다는 401 에러 페이지를 보게 된다. 이런 접근 제한 뿐 아니라 로그인 처리도 login-config 설정을 이용하면 가능하다. 실제 톰캣의 admin과 manager 애플리케이션은 이 설정을 이용해서 인증과 권한 처리를 한다. 자세한 스펙은 서블릿 스펙 문서에 정의되어 있으나 실제 활용하기엔 다소 부족한 감이 있고 톰캣의 실제 활용 예를 보는 것이 도움이 될 것이다. 이외에도 서블릿 필터 설정, 세션 설정, 리소스 설정 등 여러 가지 유용한 설정을 해줄 수 있고 공통적인 에외 처리를 위한 에러 페이지 설정도 가능하다. 에러 페이지 설정 부분은 이후 예외 처리에서 자세히 다룰 것이다.

4.2.2 예외 처리 #

자바의 강점 중 하나가 편리한 예외 처리 방식이다. C 언어 등 예외 처리 문법이 없는 언어를 먼저 접한 프로그래머에게는 생소한 개념일 수 있겠지만 알면 알수록 편리한 것이 자바의 예외 처리이다. 하지만 의외로 많은 자바 프로그래머들이 예외 처리를 어려워하고 예외 처리를 제대로 하지 않아 여러 가지 문제를 발생시킨다. 기본이라고 할 수도 있는 부분이긴 하나 사실 이것은 자바의 예외 처리 문법만 배운다고 되는 문제는 아니며 예외 처리에 대한 많은 고민이 필요하다. 특히 웹 애플리케이션의 예외 처리는 프로그래머를 위한 부분과 웹사이트 방문객을 위한 부분 두 가지를 모두 고려해야한다.

먼저 프로그래머의 입장을 살펴보자. 예외가 발생하면 어디까지는 그냥 던지고 어디서 캐치하는 것이 좋을까? 자바의 예외는 자바 코드의 모든 영역에서 발생할 수 있다. 이 모든 영역에 다 try-catch를 걸고 예외를 잡을 수는 없는 일이다. 대부분의 예외는 일단 그냥 던지는 것이 좋다. 자바의 예외가 좋은 것은 꼭 예외가 발생한 그 지점에서 처리를 하지 않아도 된다는 것 때문이다. 예외를 던짐으로서 예외를 처리하기에 적절한 위치에서 처리하게 만들 수 있다. 어떻게 처리해야할지 잘 모르겠다면 그냥 그대로 던지도록 하는 것이 좋다. 예외를 잡아서 처리해야하는 곳은 일반적으로 사용자에게 화면을 보여주기 직전이며 이것은 웹 애플리케이션이 MVC(Model-View-Controller) 패턴으로 작성되어 있다면 컨트롤러에서 이 역할을 하게 된다. 컨트롤러에서 예외를 보고 판단을 해서 사용자에게 보여줄 화면을 결정하는 것이다. 쇼핑몰에서 마일리지 적립액으로 상품을 구매하는 과정을 예로 들어보자. 만약 고객이 자신의 마일리지보다 더 많은 금액의 상품을 구매하려한다면 구매를 수행하는 모델 객체에서 예외가 발생할 것이다. 그러면 이 모델 클래스에서 예외를 바로 잡지 말고 던져서 구매 프로세스의 컨트롤러 객체에서 이를 잡아서 예외 페이지로 포워드를 시켜서 예외 메시지를 보여주는 식으로 코딩하면 된다.

웹사이트 방문객을 위해 중요한 것은 자바 예외가 발생했을 때 이해할 수 없는 시스템 에러 메시지나 스택트레이스 등의 황당한 화면이 아닌 친절한 에러 메시지를 표시해주는 것이다. 이를 위해서는 컨트롤러에서도 처리하지 못하고 던져진, 정말 예상 밖의 예외를 모두 끌어모아서 처리하는 부분이 필요하다. Servlet/JSP에서는 이런 부분의 처리를 위한 기능을 여러 가지로 제공하고 있고 스트러츠 등의 프레임웍에서도 다양한 방법을 제공하고 있다. JSP의 에러 페이지 설정이 그 한 예다. 그러나, JSP의 에러 페이지 설정 방식은 모든 JSP 페이지에 설정해야 작동한다는 단점이 있다. 만약 에러 페이지 지정을 빠뜨린 페이지에서 예외가 발생한다면 서블릿 엔진의 에러 메시지가 그대로 웹사이트 방문객에게 전달되고 만다. 이런 부분을 쉽게 처리하기 위한 방법이 있다. 이것은 위에서 설명했던 web.xml의 에러 페이지 설정을 이용하는 것이다. 우선 다음의 예를 보자.

<error-page>
  <exception-type>java.lang.Exception</exception-type>
  <location>/common/error.jsp</location>
</error-page>

<error-page>
  <error-code>404</error-code>
  <location>/common/error.jsp</location>
</error-page>

이렇게 설정해두면 웹 애플리케이션 전반에서 발생하는 예외 중 java.lang.Exception을 상속한 예외는 모두 잡혀서 /common/error.jsp 페이지에서 처리하게 된다. 예외가 발생하면 request 객체에 예외 상황에 대한 정보가 attribute로 저장된 후 /common/error.jsp로 포워딩되어 이곳에서 request에 담긴 정보들을 바탕으로 에외 처리를 해줄 수 있다. 이 곳에서는 일반적인 에러 메시지를 사용자에게 보여주면 된다. 자바 예외 뿐 아니라 HTTP 에러 코드도 잡아낼 수 있다. 이를테면 없는 페이지를 호출해서 404 에러가 나는 경우 이를 잡아서 페이지가 없다는 에러 메시지를 좀더 친절한 메시지로 보여줄 수 있다. 덧붙여, 이 에러 처리 페이지는 가급적 순수한 서블릿으로 만드는 것이 좋다. 스트러츠의 Action으로 에러 페이지를 구성해본 적이 있었는데 설정 상의 문제로 스트러츠의 ?ActionServlet 로딩이 실패할 경우 예외를 제대로 표시하지 못한다. JSP로 만드는 것도 나쁘진 않으나 복잡한 로직이 들어갈수록 서블릿이 더 코딩하기 더 편할 수 있다. 만약 이 에러페이지 자체에서 또다시 예외가 발생하면 찾기 힘든 경우가 많기 때문에 주의를 많이 기울여야한다.

4.2.3 로깅 #

에러 페이지에서 해야할 또 하나 중요한 일은 예외 상황에 대한 로그를 남기는 것이다. 에러 페이지까지 왔다는 것은 이미 개발자의 예상을 벗어난 동작을 하고 있다는 것이므로 이 사실은 개발자에게 빨리 전달되어야한다. 때문에 로그를 제대로 남겨서 조회하기 편한 시스템을 구축해야한다. 로깅 API는 여러 가지가 있고 JDK 자체에도 포함되어 있지만 log4j가 가장 널리 사용되고 성능, 기능, 안정성 등 여러 가지 면에서 다른 것들보다 낫다. 여러 가지 로깅 API를 바꿔가면서 사용할 수 있게 해주는 자카르타의 commons-logging 프로젝트도 쓸만하다. 로거 객체는 일반적으로 클래스 당 하나를 클래스의 전체 이름으로 생성해서 사용한다. 다음은 commons-logging을 사용하는 예다.

package com.hangame.avatar;

import ...

public class Avatar {
    private static Log log = LogFactory.getLog(Avatar.class);

    public void changeBackgroud() {
        log.debug("avatar changing..");
    }
}

이러면 로그 객체는 Avatar 클래스의 전체 이름, com.hangame.avatar.Avatar로 생긴다. 만약 여기에 log4j를 붙여서 사용한다면 다음과 같은 log4j 설정을 사용할 수 있다.

<?xml version="1.0" encoding="UTF-8" ?>

<log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'>
  <appender name="normal" class="org.apache.log4j.ConsoleAppender">
    <param name="Threshold" value="DEBUG"/>
    <layout class="org.apache.log4j.PatternLayout">
     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p] %m%n"/>
    </layout>
  </appender>
  <appender name="memory" class="com.nhn.logging.MemoryAppender" >
    <param name="Threshold" value="ERROR"/>
     <layout class="org.apache.log4j.PatternLayout">
     <param name="ConversionPattern" value="%d{yyyy-MM-dd HH:mm:ss} [%-5p](%F:%L) %m%n"/>
     </layout>
  </appender>

  <logger name="com.hangame" additivity="false">
    <level value="DEBUG"/>
    <appender-ref ref="normal"/>
    <appender-ref ref="memory"/>
  </logger>
  <logger name="org.apache" additivity="false">
    <level value="INFO"/>
    <appender-ref ref="normal"/>
  </logger>

  <root>
    <level value="WARN"/>
    <appender-ref ref="STDOUT"/>
  </root>
</log4j:configuration>

위의 설정은 com.hangame와 org.apache라는 이름의 로거를 두 개 생성하고 있다. 로거의 특성은 이름으로 상속된다. com.hangame.avatar.Avatar라는 이름의 로거는 com.hangame의 속성을 모두 상속 받게 된다. 그러면 com.hangame이 normal과 memory라는 두 개의 appender를 갖고 있기 때문에 com.hangame.avatar.Avatar 로거가 찍은 로그는 표준 출력으로도 나가고 메모리에도 남게 된다. log4j의 이런 특성을 이용하면 다양한 방식으로 로그를 남길 수 있고 로그를 선택적으로 켜고 끄는 것이 가능하다. 이런 기능들을 잘 활용하면 로그를 조회하기 쉽게 구성할 수 있다. 위에서 예를 든 것처럼 메모리에 최근 로그를 남겨두고 이를 조회할 수 있는 페이지를 만든다거나 데이터베이스에 로그를 쌓을 수도 있다. 그리고 주기적으로 이런 로그 조회 페이지를 모니터링하면서 로그 리포트를 개발자에게 메일 등으로 자동 발송해주는 시스템도 구상해 볼 수 있을 것이다.

4.2.4 예외 추적 #

예외 처리 시스템을 구축하고 예외 로그를 남겼으면 다음은 이 정보를 바탕으로 문제점을 찾아들어가는 것이다. 예외 추적의 출발점은 당연히 예외 스택 정보이다. 대부분의 문제는 예외 스택 정보만 가지고도 찾아낼 수 있다. 하지만 의외로 많은 프로그래머들이 예외가 발생했을 때 스택 정보를 보지 않고 자신의 경험에 의지해서 문제점을 예측하려 하곤 한다. 이런 실제 상황에 기반하지 않은 예측은 운 좋게 문제를 바로 짚어내는 경우도 있겠지만 대개의 경우 시간만 낭비하게 된다. 예외가 발생하면 반드시 스택 정보에 찍힌 소스의 라인부터 살펴보는 습관을 기르는 것이 좋다. 스택 정보는 가끔 수백 라인에 이를 정도로 길어지는 경우도 간혹 있다. 이 모든 정보를 다 찾아볼 필요는 없다. 스택 정보는 메쏘드가 호출된 역순으로 찍히므로 위에 있는 정보가 예외가 발생한 위치와 가까운 정보다. 그렇다고 늘 제일 위의 정보를 봐야하는 것은 아니다. 웹 애플리케이션의 경우 스택 정보는 자신이 작성한 클래스 뿐 아니라 서블릿 엔진을 포함한 여러 가지 클래스의 정보들이 같이 담겨 있다. 이런 정보들은 보통 볼 필요가 없고 스택 정보에서 자신이 작성한 클래스 중 제일 위에 있는 것, 이것이 예외가 발생한 지점이며 이곳을 찾아보면 대부분의 문제점은 정확하게 추적 가능하다.

또 한 가지 자바 초보자를 괴롭히는 문제는 ?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 값이 들어왔을 때 다른 부분에 버그가 있기 때문이라는 사실을 감지할 수 있다. 상황에 따라 위와 같은 코드를 써도 되는지를 신중히 검토한 후 사용해야한다. 예외 발생이 두려워서 버그를 은폐할 수 있는 코드를 만들지 말자.

4.2.5 한글 문제 #

웹 프로그래머들을 괴롭게 하는 문제를 꼽을 때 빠지지 않는 것이 한글 문제다. 한글 문제가 지금처럼 골치아프게 된 데는 역사적으로 복잡한 원인들이 얽혀 있는데 이런 문제는 접어두고 자바 웹 프로그래머로서 한글 문제를 해결하기 위해 알아야하는 것들을 살펴보자.

자바는 문자열과 바이트 스트림을 다르게 취급한다. 자바의 스트링은 유니코드의 문자셋을 사용하며 문자열을 파일에 쓰거나 네트워크로 전송하는 등 실제 입출력이 일어날 때는 문자열을 바이트 스트림으로 변환하게 된다. 이 때 바이트 스트림으로 변환하는 규칙이 인코딩이다. 따라서 바이트 스트림으로 전달된 것을 문자열로 바꾸거나 문자열을 바이트 스트림으로 전달할 때는 반드시 인코딩을 지정해야한다. 이런 인코딩 중 한글을 표현할 수 있는 인코딩은 자바에서 사용하는 이름을 기준으로 하면 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을 사용할 필요가 있다.

자바에서의 한글 문제는 문자열과 바이트스트림의 변환에 인코딩이 주어져야한다는 사실만 생각하면 다 쉽게 해결가능하다. 역시 기본이 잘 갖춰져 있으면 한글 문제도 쉽게 해결할 수 있는 것이다.

4.2.6 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 인코딩, 디코딩과 유사한 작업을 수행할 수 있다.

4.2.7 클래스패스의 리소스 사용법 #

웹 애플리케이션은 보통 애플리케이션의 설정을 담고 있는 파일이 필요하다. web.xml, struts-config.xml 등의 설정 파일들은 보통 웹 애플리케이션의 /WEB-INF/에 위치하게 되는데 그 외에 애플리케이션에서 사용하는 파일들은 어디에 놓고 사용하는 것이 편리할까? 가장 관리하기 쉽고 부가적인 작업이 적은 방법은 클래스패스에 두는 것이다. /WEB-INF/classes에 두면 자바의 클래스로더를 이용해서 이런 파일들에 접근할 수 있다. log4j 등 많은 라이브러리들이 자신의 설정 파일을 클래스패스에서 가장 먼저 찾게 된다. 다음의 예제를 보자

    public File getFile(String name) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        return new File(loader.getResource(name).getFile());
    }

    public void doSomeProcess() {
        File file = getFile("config.xml");
    }

위의 코드는 클래스패스에서 config.xml을 읽는다. 웹 애플리케이션의 기본 클래스패스는 /WEB-INF/classes이므로 기본적으로 여기서 찾게 된다. 이것으로 jar 파일 안의 내용도 읽을 수 있다. 이 경우는 ?ClassLoader.getResourceAsStream을 통해서 스트림으로 파일 내용을 읽을 수 있다. 대부분의 IDE나 maven 등의 빌드 툴에서는 소스 경로에 있는 파일들 중 자바 소스가 아닌 파일들을 자동으로 클래스패스로 복사해주므로 이용하기도 편리하다. 자카르타의 commons-discovery 프로젝트는 이런 기능들을 모아서 편리하게 이용할 수 있게 제공하고 있다.

4.2.8 서블릿/액션 멤버 변수 공유 문제 #

JSP가 보급되기 시작하던 초기에 많이 발생하던 문제로 웹사이트의 이용자가 접속했을 때 자신의 정보가 아닌 다른 사람의 정보가 나타나면서 엉키는 경우가 있었다. 이것의 원인은 서블릿에 대한 이해가 부족해서 발생한 것이었다. 다음의 예제를 보자.

public class BadServlet extends HttpServlet {

    Map userInfo;

    protected void service(HttpServletRequest req, HttpServletResponse res)
            throws ServletException, IOException {

        String username = req.getParameter("name");
        Map userInfo = UserManager.getUserInfo(username);
        req.setAttribute("userInfo", username);
    }
}

얼핏 별 문제가 없어보이지만 이 코드는 심각한 문제가 있다. 서블릿은 보통 서블릿 엔진에서 하나만 생성되고 한 번 생성된 서블릿 객체가 계속 재활용된다. 때문에 A와 B라는 두 사용자가 동시에 이 서블릿을 호출하게 되면 A의 호출을 수행하는 중에 B의 호출이 userInfo의 값을 바꿔버릴 수 있다. 그러면 A는 B의 정보를 보거나 그 반대의 경우가 생길 수 있는 것이다. 혼자서 테스트할 때는 한 번에 한 쓰레드만 service 메쏘드를 호출하기 때문에 이런 문제가 잘 드러나지 않기 때문에 별 문제 없는 줄 알고 있다가 서비스를 오픈하고 나면 문제가 되는 경우가 있으므로 조심해야한다. JSP에서 <%! %>를 통해서 선언하는 내용도 마찬가지 문제가 발생하므로 주의하자. 이런 내용 역시 자바 클래스와 멤버 변수의 기본 개념을 이해하고 서블릿 스펙만 한 번 읽어본다면 금방 알 수 있는 내용이다.

4.3 결론, 생각하기 #

이 내용들을 읽으면서 모르는 내용이 하나도 없었다면 자바 웹 프로그래머로서 어느 정도 기본은 되어 있다고 할 수 있다. 이런 내용들은 그 하나하나에 대한 지식을 쌓는 것도 중요하지만 더 중요한 것은 이런 내용을 알아야한다는 사실을 아는 것이다. 무엇을 알아야하는가를 가르쳐주는 것은 스펙이다. 스펙 문서들은 대부분 영어이고 그다지 친절하게 되어 있진 않지만 해당 분야에 대해 가장 정확한 정보를 담고 있다. 자세한 내용을 다 알진 못하더라도 스펙에 어떤 내용이 있는가 정도는 알아야 그 내용 중 자신에게 필요한 내용을 찾아서 공부할 수가 있는 것이다. 이런 정보를 어디서 찾을 수 있는가를 알고 있는 것도 중요하다. 기본적으로 www.ietf.org, jcp.org, java.sun.com, www.w3.org 정도의 사이트에는 익숙해지는 게 좋을 것이다.

많은 프로그래머들이 실제로 자기 손으로 프로그래밍해보는 게 실력이 느는 제일 좋은 방법이라고 말하지만 필자는 여기에 동의하지 않는다. 물론, 실제 경험을 쌓는 것이 필수적인 과정이긴 하다. 그러나, 기본 지식을 등한시한 상태에서 코딩만 해보는 것으로는 실력이 잘 늘지 않는다. 코딩 기술은 늘 수 있겠지만 정말 실제 서비스를 해야하는 프로그래밍에서 중대한 실수를 저지르게 되거나 남들이 쉽게 쉽게 하고 있는 일들을 어렵게 빙 둘러가면서 하게될 수 있다. 그래서 기본기를 갖추는 것이 중요한 것이다.

거듭해서 기본의 중요성을 강조했는데 한 가지 덧붙이고 싶은 말은 이런 기본 지식 뿐 아니라 기본을 활용하는 능력을 키우는 것도 잊지 말아야한다는 것이다. 앞서 언급한 예외 처리 같은 내용은 기본이긴 하나 자바 문법만 잘 안다고 알 수 있는 내용들은 아니며 기본을 바탕으로 좋은 판단을 내릴 수 있는 능력이 있어야한다. 결국 좋은 프로그래머가 되려면 먼저 좋은 사고 능력을 가지고 있어야하는 것이다. 글짓기를 잘하는 방법으로 흔히 다독(多讀), 다작(多作), 다상량(多商量)을 이야기한다. 많이 읽고 많이 쓰고 많이 생각하라는 것이다. 프로그래밍도 이와 비슷하다. 각종 스펙들과 좋은 코드들을 많이 읽어보고 직접 코딩도 많이 해보면 분명 실력이 늘지만 이것으로는 충분치 않다. 프로그래밍을 하면서 끊임없이 생각해야한다. 지금 작성한 코드는 좋은 코드인가, 이렇게 코딩하면 불편한데 개선할 방법은 없을까, 이 API들로 무엇을 할 수 있을까, 좀더 개발 속도를 향상시키려면 어떻게 해야할까 등등 생각을 많이 해야 진짜 발전을 이룰 수 있다. 만일 손가락이 아플 정도로 하루 종일 키보드를 두드리고 있다면 좋은 프로그래머라고 할 수 없다. 생각하는데 좀더 많은 시간을 써야한다. 모니터를 구부정하게 들여다보면서 키보드를 두드리는 것은 것보다는 의자에 편안히 기대서 생각하는 시간을 늘리자. 복잡한 문제가 있으면 바깥 공기를 쐬면서 산책을 하면서 생각을 하는 것도 좋다. 굳이 건강을 생각하지 않더라도 걷는 것은 두뇌를 활성화시키기 때문에 해결책을 더 빨리 찾을 수 있게 해 준다. 남들이 보기에는 게을러보일 수 있지만 놀고 있는 게 아니라는 것은 결과로 충분히 보여줄 수 있다. 물론 이런 생각을 잘 이어나가기 위해서는 생각의 재료가 되는 기본에 충실해야함은 물론이다. 어둠침침한 구석에 앉아 키보드만 두드리는 geek가 아닌 보다 인간다운 프로그래머가 되자.

4.4 참조 #

http://java.sun.com/products/servlet/download.html 서블릿
http://jcp.org/aboutJava/communityprocess/final/jsr152/index.html JSP 2.0
http://www.ietf.org/rfc.html RFC 홈페이지
http://www.ietf.org/rfc/rfc2068.txt?number=2068 RFC 2068, HTTP 프로토콜
http://www.ietf.org/rfc/rfc1738.txt?number=1738 RFC 1738, URL
http://www.w3.org/ World Wide Web Consortium
http://www.w3.org/TR/html4/ HTML 4.01
http://www.w3.org/TR/xhtml1/ XHTML 1.0
http://www.w3.org/TR/2004/REC-xml11-20040204/ XML 1.1
http://www.w3.org/Style/CSS/ CSS
http://trio.co.kr HTML, XHTML, CSS의 한글 번역 문서
http://jakarta.apache.org/commons/ 자카르타 commons 프로젝트
http://www.javaservice.net/~java/bbs/read.cgi?m=devtip&b=servlet&c=r_p&n=968185187 서블릿 인스턴스 변수 공유 문제에 대한 글

Posted by 어부님

거미줄세상 l 2007. 12. 22. 14:16

창조경영!! 기업블로그로 무장하라 - (주) 네트빌

제목 : 창조경영!! 기업블로그로 무장하라

이 글은 언제나 한발 앞서가는 웹2.0 솔루션 업체인 네트빌(www.netville.co.kr)의 전략마케팅팀 내부 보고서를 옮긴 것임을 밝혀둡니다.

<출처 : ㈜네트빌 전략마케팅팀 “기업형 블로그에 대한 소고” 내부 보고서>

목 차

(１) 혁신할 것인가! 창조할 것인가!
(２) 프로세스보다 더 무서운 것은 자율이다.
(３) 인터넷, 웹2.0에 도도히 흐르는 사상은 자유와 자율이다.
(４) 창조경영! 기업형 블로그로 무장하라!

(１) 혁신할 것인가! 창조할 것인가 ?

올해 2007년의 벽두에 삼성전자는 창조경영이라는 화두를 던졌다. 그동안 삼성은 쫓가가서 추월하는 능력은 어느정도의 성과에 도달해있지만, 새로운 시장을 만들어 나갈 새로운 아이템을 창조하는 능력은 부족하기에, 삼성이 한단계 더 도약하기 위해서는 창조를 통한 신시장개척이 필요한 시기임을 나타낸 것이라 본다.
창조경영이라는 단어는 많은 것을 담고 있는 듯하다. 이의 구체적인 서술에 앞서 기존에 우리에게 너무도 익숙해져 있는 혁신이라는 단어는, 세계시장에서는 한계가 있음을 먼저 언급하고 싶다. 기존 것을 계속 보완하고, 새롭게 고치는 등 효율성의 달성에 목표를 두고 있는 혁신은 세계로 뻗어나가기에는 역부족이다. 허지만, 우리 사회를 움직이는 핵심세대들은 이에 너무도 익숙해져 있는 것이 사실이며, 우리의 교육, 우리의 기업문화도 크게는 이를 벗어나지 못하고 있다. 그러나 창조는 사고의 변화를 요구하는 단순한 과제가 아니다. 보기에 따라서는 세대의 교체를 요구하는 것이며, 교육의 변화, 문화의 변화를 동시에 요구하는 것이기도 하다.
그렇다면, 세계에서 더욱더 도약하기 위해서는 즉 창조경영을 하기위해서는 무엇이 필요한가 ? 창조경영의 기본이 되는 것이 무엇인가 ? 이 질문에 대답할 수 있어야만 창조경영의 본질에 접근할 수 있을 것이다.
창조경영을 하기 위해서 필요한 것 ? 누구나 쉽게 생각할 수 있는 것은 창조적인 아이디어를 생산해 낼 수 있는 사람이라고 생각할 것이다. 그래서 창조에 익숙한 문화에서 자란 인재들의 영입이 첫번째 답이 될 수 있을 것이다. 이에 따라 삼성이 사력을 다해 추구하고 있는 것도 인재영입에 초점이 맞추어져 있다고 할 수 있을 것이다. 그러나 필자의 생각은 조금은 다르다. 귤이 하수를 건너면 탱자가 된다고 하듯이, 창조경영의 문화적 토대가 갖추어져 있지 않은 곳에 그러한 인재가 온다고 해서 창조경영이 이루어지는 것은 아니다. 문제의 핵심은 창조경영에 어울리는 기업문화란 무엇인가에 초점을 두어야 한다고 본다.
여하튼 이제 대한민국에 새롭게 대두되는 화두는 기존의 혁신의 과제에서 창조의 과제로 발전해야 함은 명백한 것 같다. 왜냐하면 새로운 도약을 위해서는 창조가 없이는 항상 2등이기 때문이다.

(２) 프로세스보다 더 무서운 것은 자율이다.
창조가 자연스럽게 탄생할 수 있는 환경, 기업문화란 어떤 것일까 ?
유감스럽게는 우리는 어릴적부터 창조보다는 주어진 길에서의 최선의 노력을 다하는 것이 자연스럽게 몸에 밴 풍토에서 자라왔다. 또한 이런 풍토에서 자란 사람들이 엘리트로서 성장하여 현 사회의 주축을 이루고 있다. 따라서, 이러한 몸에 밴 풍습, 습관들의 개선이 선행되지 않고서는 창조경영으로 나가기가 쉽지 않은 과제 일 것이다. 그러나, 교육이 바뀌어지기만을 기다리기에는 너무도 요원하기에, 한 기업의 문화속에서라도 창조가 조금이나마 싹틀 수 있도록 하는 문화적 환경의 변화가 지금은 필요한 시기이다. 다행히도 다양한 개성을 표현함에 주저함이 없는 최근의 젊은세대들도 잉태되고 있기에 조금은 더 희망적일 것 같다. 기업에서 창조가 싹틀 수 있는 문화는 어디에서 오는가 ? 필자는 단언하건데 이러한 창조는 자율에서 온다고 본다. 우리 기업들은 다년간, 프로세스중심의 체계를 만들어왔고, 이 프로세스를 어떻게 개선하느냐의 문제가 혁신의 중차대한 문제였다고 볼 수 있다. 즉 프로세스를 더욱 효율적으로 하는 방법이 핵심과제였던 기업문화속에서 살아왔다. 프로세스 중심의 업무시스템에 대비하여 볼 수 있는 것은 필자는 자율의 업무시스템이라고 말하고 싶다. 자율이라고 하니, 왠지 기업에는 어울리지 않는 단어인 것 같다. 자율은 언제나 위험을 내포하기 때문이다. 그렇다. 직원들에 대한 신뢰와 믿음이 없이는 절대로 할 수 없는 것이 자율이다. 필자가 볼 때 자율이 올바르게 성립되기 위해서는 정보의 공개가 필수적이다. 자율의 선행조건이 정보의 공개인 것이다. 정보의 공개없이 자율을 기대하는 것은 또다른 과욕에 불과하다. 정보의 공개와 이를 통한 자율의 문화의 정착 이것이 창조경영을 위한 밑바탕이다. 프로세스를 폐기해야 할 필요는 없다. 혁신의 과제가 없어진 것이 아니기 때문이다. 다만 자율의 문화가 필요한 곳, 그리하여 창조가 잉태되기를 바라는 곳에는 프로세스중심의 문화로는 불가능함을 말하고자 한다.
자율의 문화라고 하니, 마치 직원들에게 많은 것을 새롭게 고쳐야 한다고 생각하고 지레 겁을 집어 먹을 것 같다. 허지만 앞서 말했듯이 정보의 공개만 이루어진다면 자율의 문화의 반은 이루어진 것이다. 나머지 반은 신뢰와 믿음을 가지고 지위고하를 막론하고 언제나 열려있는 문을 만드는 것이 중요한 것 같다. 그리고 이러한 문화를 만드는 곳에 웹2.0이라는 훌륭한 파트너가 있다. 다음장을 보기로 하자.

(３) 인터넷, 웹2.0에 도도히 흐르는 사상은 자유와 자율이다.
웹2.0 !! 가슴설레게 하는 단어이다. 인터넷이 우리 삶의방식에 대변혁을 불러왔다면, 웹2.0은 이에 상응하는 문화의 변화를 표현하는 단어라고 생각한다. 흔히들 웹2.0은 참여, 개방, 공유라고 하는 3개의 단어로 나타낸다. 너무도 적절한 표현이라고 여겨진다. 허지만 이와 더불어 웹2.0이 우리기업에게 던지는 시사점은 자유와 자율이다. 기업에서는 받아들이기 어려운 이 단어가 왜 중요한가 ? 웹2.0이 광의의 인터넷에서 언급이 될 경우에는 자유와 자율은 너무도 기본적인 것이기에 언급할 필요조차 없다. 집에서 내가 자유롭게, 자발적인 의지로 인터넷에 접근하는 것을 통제할 사람은 아무도 없기에, 자유와 자율은 기본이었었다. 허지만 기업이라는 테두리속에서는 달라진다. 자유롭게 ? 왠지 쉽지않은 단어로 변해버린다. 자율 ? 이 또한 어색해 보이는 단어이다. 웹2.0의 문화적 조류를 창조와 연결하여 말하고자 하는 것은 이 때문이다. 창조는 다시금 말하거니와 문화적 토대위에서만 의미가 있는 것이지, 문화적 토대를 이루지 못한 상태에서의 창조는 설령 한 두건의 창조는 있을 수 있을지 모르나, 영속적으로 자리잡지 못한다. 이러한 문화적 토대는 자유와 자율이며, 이는 웹2.0이라는 거대한 조류와 직결되기에 웹2.0이 기업인에게는 가슴뛰게 만드는 단어라는 것이다.
자유와 자율위에서, 참여와 공유가 발생할 수 있기 때문이다. 이러한 참여와 공유가 어우러져 웹2.0의 거대한 결과를 초래하는 것을 우리는 구글에서, 아마존에서 보아오지 않았는가 ? 참여와 공유를 통해 만들어내는 결과는 절대로 단편적이지 않다. 영속적이다. 이러한 문화를 어떻게 만들어내고, 이러한 문화속에서 이를 어떻게 이끌어내는 가를 창조경영을 추구하는 기업은 고민해야 한다.

(４) 창조경영! 기업형 블로그로 무장하라!
자유와 자율의 바탕 위에서 참여와 공유를 만들어내는 웹2.0 !
그 웹2.0의 대표적인 도구가 블로그라고 생각한다. 블로그의 특징은 인간의 본성적인 표현욕구를 자연스럽게, 강요하지 않은 자신만의 글로 남기는 도구이다. 어쩌면 기업이라는 문화와는 어울리지 않지만 창조라고 하는 단어와는 좀 더 친숙해진다.
기업이 고민해야 할 것은 어떻게 개인의 자발적인 글들이 블로그에 풍성하게 올라올 수 있도록 할 것인가 ? 또한 좀더 업무와 관련한 자신만의 생각들이 자연스럽게 표출되게 할 것인가 (물론 강요해서는 안 된다)를 고민해야 한다. 이는 블로그를 기업의 소유로 생각하지 말고, 개인의 소유라는 사고에서 출발해야 한다. 개인의 소유이기에 어떠한 글이 올라오더라도 기업이 관여해서는 안 된다. 기업의 관여가 들어가기 시작하면 자발성은 무너지게 된다. 그리고 블로그가 스스로 진화해 나갈 것이라는 것을 믿어라. 신뢰와 믿음! 자율의 문화가 형성되는 곳에서 창조의 싹이 튼다는 믿음을 가져야만 한다.
블로그에 올라오는 글의 수준에 대한 고민은 일단 하지 말자. 블로그의 진화에 대한 믿음만 가지면 된다. 허지만 고민하지 않을 수 없는 것은 보안의 문제이다. 기업비밀에 해당하는 사항들이 블로그에 올라오면 어떻게 하나? 필자의 생각은 이 또한 직원들의 자율적인 힘에 맡기는 것이 좋아 보이나, 때론 심각한 문제를 유발할 수 있기에 이 부분에 대한 대책은 기업내의 블로그 관리자들의 주된 고민이 되지 않을까 판단된다. 허지만, 기업내 블로그가 미치는 영역은 기업내이기에, 직원들의 자율과 자발적인 보안의 정화과정을 믿고 싶다. 기업내의 직원들의 블로그는 기업 내에서 철저히 개방하고, 비관여를 원칙으로 삼고 가야 한다고 본다.
이러한 문화가 정착이 되면 블로그속에서 옥석을 가려내어 이를 창조와 연결하는 것은 모두의 몫 특히 관리자의 몫이 되리라 본다.
블로그 문화가 성숙해지면, 블로그를 통한 협력작업이 가능한 팀블로그 등도 고려해 볼 수 있을 것이다.

창조경영, 웹2.0, 블로그, 앞으로의 기업의 변신에 가슴이 띈다. 자율이 가지는 힘, 직원들의 자발적인 표현수단의 제공, 이러한 문화적인 변신 속에서 새로운 창조의 희망이 보이지 않을까 ?

거미줄세상 l 2007. 12. 20. 09:26

1 2

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

카테고리

분류 전체보기 (117)

작업노트 (98)

거미줄세상 (12)

쌓기 (1)

책읽기 (0)

Reviews (4)

달력

링크

거미줄 치는 프로그래머