Scent of Life

신년의 시작은 폭설!

2010-01-04T23:13:18+09:00

신년 첫 출근길은 대혼란이었다. 오늘 하루 고생하지 않은 사람은 드물리라.

새벽의 가는 눈발을 보고 잠든터라 아침에 눈뜨면서 바로 창문 커텐부터 걷어젖혔다. 예사롭지 눈발로 이미 골목길은 하얀 함박눈이 두툼하게도 쌓여있었다. 인천가는 길이 험란하리라 예상하고 차는 일찌감치 포기. 본사 시무식에 참석한 고참들과 공항철도 검암역에서 만나기로 약속하고 전철로 향해야했다. 프로젝트룸은 검암역에서 17km 정도는 더 가야한다. 택시로. -_-

집에서 나서자마자 도로로 합류하는 얕은 경사로에서 헛바퀴를 돌리며 미끄러지는 차량 한대를 목격하고는 바깥 도로 사정은 쉽게 예상할 수 있었다.

오늘 서울에 내린 기록적 폭설의 공식 기록은 25.8cm 사상최대로 예전 최고 강설 기록인 1969년 1월 28일의 25.6cm를 갱신하였다. 9시 저녁 뉴스에서는 눈으로 마비된 도로와 주차장으로 변한 고속도로, 눈길 사고로 아수라장이 된 현장, 대대적인 제설 작업, 등등의 폭설 관련 소식만으로 30분 분량을 넘어섰다.

퇴근 후 기록적인 날을 사진 한장 없이 지나가는 것이 아쉬워 주변 골목길에서 몇컷 찍어보았다.

이번주 내내 강추위를 예고하고 있다. 햇볕이 잘 들지않는 골목길이라 저 눈들이 사라지려면 꽤나 많은 날이 지나야할 것 같다. 내일부터 당분간은 셔틀 버스를 이용해야하겠다. 프로젝트 초반이라 다행(?!)이다.

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

트위터(twitter)를 시작하다.

2009-12-18T16:38:43+09:00

미투데이(me2DAY)도 트위터(twitter)도 가입만한 상태로 방치해두고 있었다. 그러다 오늘, 문득 트위터 하고 싶다는 생각이 들어 트위터에 첫글을 올려보았다. 내 트위터 ID는 "kyungseo"다.

2009년 12월 18일. 나도 짹짹거리며 수다 좀 떨어보기로 작심하다! -_-)v
가벼운 일상이나 끄적여볼까나... ^^
뒤늦은 twitter, 그 첫발을 디뎌본다.

블로그에 TwitterCounter도 붙여놓고 twitter 클라이언트로 데스크탑에 twhirl도 깔아보고 Mixero도 깔아보았다. Mixero가 twhirl에 비해 많이 무겁다고하는데 일단 인터페이스는 Mixero가 더 맘에 든다.

일단은 Mixero를 사용해보려 한다.

일전에 구입한 옴니아의 경우 일정관리 용도외에는 스마트폰의 잇점을 제대로 활용하지 못하고 있었는데, 이 기회에 옴니아에서 트위터나 해볼까싶다. 기본적으로 오페라로 접속하면 되겠지만 포켓트윗(pocketwit) 이라는 것이 있는 것 같다. 조금 더 알아봐야 할듯...

그나저나 날이 장난이 아니다. 겨울답긴한데 너무너무 완전 춥다! 오는 주말엔 간만에 애들 데리고 야외에서 바람이나 쐴까 했는데 걱정이다. -_-

음... 이런(↑) 얘기는 이제 트위터에 올려야 할까나? ^^

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

WYSIWYG Web Editors

2009-12-16T15:14:57+09:00

Web-Based Html Editor 비교

오픈 소스 라이선스 하에 배포되고 있는 주요한 웹기반 위지윅(WYSIWYG) 웹에디터들을 간략하게 비교해본다.

주요 에디터들의 특징 요약

FCKEditor or CKEditor

웹기반의 위지윅 에디터 중 가장 많이 사용되는 에디터가 아닐까 싶다. 호환성이 높아 대부분의 브라우저를 지원하며 에디터의 인터페이스나 동작을 쉽게 커스터마이징할 수 있다.

공식 사이트, 데모 사이트
크로스 브라우징 가능. 기본 영어(한글 가능)
오픈 소스 라이선스(LGPL) 및 상업용 라이선스(듀얼 라이선스 정책)

TinyMCE

FCKEditor와 함께 많이 사용되고 있는 에디터이다. Theme과 Plugin을 지원하여 커스터마이징하기 쉽다. Language Pack을 사용하여 다양한 언어를 지원하고 있다.

공식 사이트, 데모 사이트
AJAX Compatible. 크로스 브라우징 가능. 기본 영어(한글 가능).
오픈 소스 라이선스(LGPL)

Xinha

Xinha 에디터 컴포넌트 역시 대부분의 현존하는 브라우저를 지원하며 플러그인도 사용 가능하다. 하지만 한글이 지원되지 않는 단점이 있다.

공식 사이트, 데모 사이트
크로스 브라우징 가능. 기본 영어.
오픈 소스 라이선스(BSD License)

Daum Open Editor

Daum Open Editor 는 Daum 에서 개발된 WYSIWYG기반의 웹 에디터인 Daum Editor를 기반으로 한 Semantic Web Information Editor 이다. Daum Open Editor는 OpenAPI, Micro format, RDF 등을 지원하여 시멘틱 콘텐츠 생산을 돕고 웹 데이터의 상호 연결성을 높여준다고 한다. 아직 버그들이 존재하는 것 같지만 프로젝트가 활발하다.

공식 사이트, 데모 사이트
국내 포탈 사이트 중 하나인 다음에서 공개한 오픈 에디터. 초보자가 사용하기 용이함. 기본 한글.
오픈 소스 라이선스(LGPL)

SmartEditor

네이버에서 공개한 위지윅 에디터로 웹폰트를 지원하는 것이 특징이다. 아직 완성도가 높지 않아 보이며, 웹표준 및 브라우저 접근성에서 떨어져 보인다.

공식 사이트, 데모 사이트
네이버 개발자 센터에서 오픈프로젝트로 진행중이다. 웹폰트 사용가능(IE전용). 기본 한글.
오픈 소스 라이선스(LGPL)

기타

TTW ("Through the Web") WYSIWYG Web Editors - The List 문서에서 다양한 오픈 소스 및 상용 컴포넌트를 찾을 수 있다.

주요 에디터들의 특징 비교

Textcube 에디터에서 테이블 작성이 용이치 않아 PPT에 작성했던 표를 캡쳐하여 붙인다.

FCKeditor VS TinyMCE

가장 많이 사용되고 있는 FCKeditor와 TinyMCE의 비교표이다.
테이블 작성이 용이치 않아 PPT에 작성했던 표를 캡쳐하여 붙인다.

참고 사이트

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18

2012, 그럭저럭 볼만하다.

2009-11-23T17:39:16+09:00

비교적 지척이라 할만한 홍대입구에 롯데시네마가 생긴지도 벌써 꽤 되었건만 이제서야 첫번째 영화 한편을 관람했다. '백야행'을 볼까 잠깐 고민하다가 '2012'를 선택했다. 어차피 혼자였고 아무 생각없이 흐르는 영상에 눈을 맞기고 싶었다.

팝콘과 콜라를 하나씩 사들고, 운좋게 2관 중앙의 명당 자리를 차지하고 앉았다. 몇개 줏어먹은 팝콘이 달콤하다고 생각하고 있을 때 바로 영화가 시작했다.

헐리웃 재난 블록버스트에 대한 선입견일까? 스토리는 어차피 기대하지 않았다. 하지만 스펙터클한 볼거리와 거대한 스케일, 그리고 완성도 높은 CG로 내내 눈이 즐거웠다. 그럭저럭 볼만한 영화였다.

영화를 보면서 동시에 일전에 봤던 '그것이 알고 싶다'의 장면들이 머리에 떠올랐다. 2012년 지구 종말론에 대한 허구를 고발하는 내용이었다. 2012의 대재앙에 대비하는 집단들이 있던데, 영화대로라면야 다 부질없는 짓이다. 허허.

팝콘으로 모자랐는지 돌아오는 길에선 군밤을 한봉다리 사들었다. 요즘 왜 이렇게 입이 심심한지 모르겠다. 혹, 나 역시 2012의 대재앙을 무의식적으로 두려워하고 있음은 아닐까? 먹고 죽은 귀신이 때깔도 좋다고... ^^

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

90mm 무반동총

2009-11-13T17:32:37+09:00

웹서핑 하다가 어떻게 삼천포로 빠졌는지 모르겠지만서도 우연히 발견한 90mm 무반동총.

군 시절 주특기가 '106-9', 바로 90mm 무반동총이었다.

유격 행군할 때 K2를 걸쳐 매고 완전 군장에 17Kg 정도의 무반동총을 올려놓고 힘겹게 걸었던 기억이 새록새록 떠오른다.

사수로서 처음 고폭탄 사격하던 날, 엎드려쏴 자세에서 숨죽이고 목표를 조준하던 기억도 새삼스럽다.

"명중하면 휴가다!"

속으로 몇번을 되뇌며 호흡을 멈추고 신중하게 방아쇠를 당겼다. "펑"하는 소리와 함께 발사. 잠깐의 짧은 정적 후에 고폭탄은 보기좋게 과녁을 빗나갔다. 그리고 엄한 맨땅에서 다시 "펑"하는 시원한 소리를 내며 터져버렸다. -_-

방아쇠를 당김과 동시에 강한 후폭풍과 함께 튀어오른 흙먼지가 하이바며 전투복 위로 후두둑 떨어졌을 때의 실감나는 느낌은 아직도 생생하다.

그때만 해도 90mm는 도태장비라 곧 사라질 거라 했는데, 찾아보니 10여년이 지난 아직까지도 그저 도태장비 이름을 단 현역장비인가보다.

그냥 추억 한소절이다.

"Distant Memories" 카테고리의 다른 글

90mm 무반동총 (댓글 4개 / 트랙백 0개) 2009/11/13
내가 작사한 노래 - 시(詩) 속의 사랑 (댓글 2개 / 트랙백 0개) 2008/11/20
인류 구원을 위한 20년 묵은 설계도 (댓글 9개 / 트랙백 0개) 2008/11/05
오래된 소극장 회원권 한장에 담긴 추억 (댓글 2개 / 트랙백 0개) 2008/07/16

미시령 터널 - 위험한 사진?!

2009-10-28T21:16:34+09:00

속초 다녀오는 길.
미시령 터널을 질주하며
달리는 차 안에서...

무슨 생각에 홀렸을까...
갑자기 머릿 속을 스치는 멋진 패닝샷들...

한 손은 운전대,
한 손은 카메라...

시선은... 뷰 파인더?
아니고,
물론 전방을 뚫어져라 주시! ^^

최대한 안전에 유의(?!)한 이유로
다행히 위험한 상황은 없었지만서도...

아무튼, 이런 용기있는 사진은 처음이자 마지막! :)

사진의 교훈: 혼자 달리는 차 안에서는 카메라를 멀리 두라. ㅋ~

P.S. 사진은 생각했던 멋진 패닝샷과는 거리가 멀었다. -_-

"Photo Essays" 카테고리의 다른 글

미시령 터널 - 위험한 사진?! (댓글 6개 / 트랙백 0개) 2009/10/28
북악산자락에 걸린 무지개 (댓글 4개 / 트랙백 1개) 2009/05/14
성북동의 봄 (댓글 4개 / 트랙백 0개) 2009/04/16
아이나비SE - 배경은 밤! 확대도는 대낮? (댓글 2개 / 트랙백 0개) 2008/12/18
내 가슴 속의 무지개 한 쌍은... (댓글 2개 / 트랙백 0개) 2008/11/18

개발자들도 헷갈리는 몇가지 용어들

2009-10-27T16:13:07+09:00

KSUG(Korea Spring User Group)에 게시된 "VO vs DTO"와 관련한 글타래를 보던 중 한가지 떠오른 것이 있었다.

2004년 경에 ASP.Net 환경의 웹 어플리케이션 개발을 위해 C# 기반의 "AdvDotNet"이란 프레임워크를 개발했었다. 이 프레임워크의 기능 중 하나로, 페이지의 Form으로부터 데이터를 전송받거나 또는 Database에서 조회한 데이터를 페이지의 DataGrid에 바인딩하는 일련의 작업 효율을 높이기 위해 Attribute와 Reflection을 사용하여 어느정도 자동화된 기반 구조를 구현하여 지원했다. BaseEntity라는 클래스와 이들의 Collection을 처리하는 일련의 코드들이었는데, 닷넷 개발자들에게 이러한 구조를 설명하기 위해 정리한 내용 중 "DataTransferObject"라는 타이틀의 문서가 있었다.

...
이러한 n-tier 환경에서 각 계층 간에 데이타를 교환하기 위해서는 데이터 전송용 객체(Data Transfer Object, 이하 DTO)를 사용하기 마련인데, 사실 DTO는 어느 정도의 규모가 되는 시스템이라면 개발자들이 부담을 가질 정도로 수가 많아지고 코딩량이 증가하고 번거로워지기 일수이다.
...
DTO는 VO(Value Object)라는 이름으로 불려지기도 한다. 엄밀한 의미로는 DTO와 VO는 차이가 있지만 일반적으로 동일한 개념으로 받아들인다. DTO와 달리 VO는 일반적으로 read only 속성을 갖는다.
...

문서에서 나는 DTO를 위와 같이 설명했다(Reflection을 사용함으로써 발생하는 퍼포먼스의 저하는 향상된 코딩 효율과 개발 용이성으로 상쇄될 수 있는 부분임을 강조하기 위해 DTO를 사용할 때 코딩의 번거로움을 먼저 화두를 꺼내고 있다).

내가 프레임워크에 대한 개념을 정립하는데는 2000년 당시에 보았던 javaservice.net의 JDF 관련 문서들이 큰 도움이 되었었는데, 이때에는 현재의 DTO를 "Entity Class"라고 표현했던 기억이 난다. 후에는 상황에 따라 DTO, VO, Model, Entity, JavaBean 등 다양하게 표현하고 또 들을 수 있었다. 여기서 "Model"이란 용어도 다소 헷갈리는 부분인데, 주로 Domain Model로서 DTO를 표현할 때에는 "로직을 갖고 있지 않은 객체로 속성(member)과 그 속성에 접근하기 위한 getter/setter 메서드를 갖는 JavaBean 클래스"를 나타내는 것이었지만, 사실 MVC 패턴의 관점에서 보면 Model은 비즈니스 구현부도 포함하기 때문이다.

※ DTO와 VO 관련 참고 사이트

개발자들의 주변에는 항상 신기술과 함께 IT, 개발 관련 용어들이 범람하고 있다. 사람인지라 모든 것을 이해하기는 불가능하기 때문에 간혹 용어의 의미가 혼동되는 경우 또한 적지 않은데, 오용하지 않기 위해서라도 그때그때 제대로 된 개념을 정립할 필요가 있을 것 같다.

얘기 나온 김에 예전에 세미나 자료로 작성했던 내용인데, Framework와 관련 용어들 중 의미와 경계가 불명확한 개념들에 대해 정리했던 부분을 옮겨본다. 미리 얘기하지만 이것들이 정답은 아니다. ^^

Framework와 관련 용어

혼동되는 개념들과 비교하여 Framework를 정의해본다. 프레임워크와 관련된 주요 개념들이다. 이들은 프레임워크로 실현되기도 하고, 상호 포함관계를 갖기도 하고, 이용관계를 갖기도 한다.

1. Framework vs Library

어플리케이션은 여러 클래스들이 상호작용하면서 그 기능을 수행하는데, 특정 기능을 수행하는 클래스들을 클래스 라이브러리(Class Library) 혹은 툴킷(Toolkit)이라고 한다. 클래스 라이브러리는 범용적으로 사용할 수 있는 기능을 제공하는 재사용할만한 연관된 클래스들의 묶음이다. 클래스 라이브러리와 프레임워크간의 가장 큰 차이는 제어 권한의 위치에 있다.

라이브러리는 사용자 코드에서 활용하는 것이다.
프레임워크는 사용자 코드가 준수해야하는 것이다.

(※ 사용자 코드: 개발자가 직접 비즈니스 로직을 구현한 코드)

구분	Library (Toolkit)	Framework
성격	재사용 가능한 하나 이상의 서브루틴(함수)들이 저장된 파일들의 모음	서로 관련이 있는 많은 수의 문제를 풀기 위한 추상적 설계를 구체화한 클래스 집합
사용자 코드의 작성	독립적으로 작성	프레임워크 클래스를 상속하거나 참조하여 코드를 작성
호출 흐름 및 제어 권한	사용자 코드가 라이브러리 코드를 호출하고, 또한 제어하는 구조	프레임워크 코드가 유저 코드를 호출하고, 제어하는 구조(IoC, Inversion of Control)
특징	프로그램(사용자 코드)이 활용하는 대상	프로그램(사용자 코드)이 준수하는 대상

2. Framework vs Component

컴포넌트는 표준으로 정의된 컨테이너 규약 하에서 독립적으로 사용할 수 있는 소프트웨어 모듈이다. 컴포넌트의 기능은 인터페이스로 정의되며 그 내부 구현은 감추어져 있다. 프레임워크가 어플리케이션 기반 구조에 더 초점을 맞춘 개념인 반면, 컴포넌트는 컨테이너라고 하는 기반 구조에서 작동하는 모듈에 초점을 맞춘 개념이라는 점에서 차이가 있다.

컴포넌트와 프레임워크를 혼동시키는 점들

프레임워크와 컴포넌트의 컨테이너는 애플리케이션을 이루는 기반 구조라는 점에서 매우 유사하다.
프레임워크에 등록하는 사용자정의 확장 모듈은 같은 종류의 프레임워크에서 재사용 가능하기 때문에 컴포넌트의 경우와 그 형태가 유사하다. 이런 관계 때문에 컴포넌트와 프레임워크를 혼용하게 되거나 분류가 어려워진다.
컴포넌트는 컨테이너-컴포넌트간의 관계 구조나 컨테이너, 컴포넌트 각각의 내부 구조를 구현하는 데 있어 프레임워크를 사용하기도 한다. 프레임워크는 핫 스팟(Hot Spot)과 콜드 스팟(Cold Spot) 구현 단위나 핫 스팟 인터페이스 설정에 있어 컴포넌트의 개념을 사용하기도 한다.

이런 관계로 일반적으로 프레임워크가 오래 사용되어서 기반 구조가 안정화되고 그 프레임워크를 확장해서 구현한 모듈이 많아지게 되면 그 자체가 바로 컴포넌트와 컨테이너가 된다.

구분	Component	Framework
성격	컨테이너라고 하는 기반 구조에서 작동하는 컴포넌트 모듈에 초점	어플리케이션 기반 구조에 초점

3. Framework vs Design Pattern

디자인 패턴과 프레임워크는 이미 성공한 솔루션에서 유래했다는 점과 다른 유사한 사례에서 재사용될 수 있다는 점에서 공통점을 갖는다.

디자인 패턴과 프레임워크의 공통적 특징

어플리케이션의 구조와 디자인을 결정한다.
반복적으로 발견되는 문제를 해결하기 위한 특화된 솔루션이다.

구분	Design Pattern	Framework
성격	'추상적인 무엇'으로 일반화	'실제적인 어떤 것'으로 특정 애플리케이션 도메인 영역에 특화
기능	어플리케이션 설계 시 구조적인 가이드 라인을 제공	프레임워크는 하나 이상의 디자인 패턴을 지원
구현부의 제공 여부	구체적으로 구현된 기반 코드가 없다(샘플 코드 정도를 포함).	기반 코드를 제공해서, 자연스럽게 패턴을 유도한다.
예시	MVC(Model-View-Controller) Pattern	Spring-MVC 프레임워크, Struts 프레임워크

4. Framework와 Architecture

프레임워크와 아키텍처는 한마디로 밀접한 관계이다. 최종적으로 완성되는 아키텍처는 사용하는 프레임워크의 종류와 그 사용 전략이 결합되어 결정된다.

아키텍처에 따라 프레임워크의 선택이 제약될 수 있다.

리치 클라이언트(Rich Client) 아키텍처라면 AJAX 프레임워크 또는 X-Internet 도입을 고려
3계층(N-Tier) 기반의 분산형 아키텍처라면 C/S를 위한 프레임워크는 사용할 수 없다.

선택된 프레임워크에 따라 아키텍처가 달라질 수 있다.

MVC 기반의 웹 프레임워크를 사용하려고 한다면 그에 맞게 Model2 아키텍처를 사용해야 한다.
프레임워크가 지원하는 패턴에 따라 아키텍처 관점에서 매우 제한적인 프레임워크가 있는 반면에 다양한 아키텍처를 지원하는 유연한 프레임워크도 있다.

구분	Architecture	Framework
성격	하나 이상의 프레임워크로 구성	어플리케이션의 구조를 결정

Structure? Architecture? Framework?

스트럭처는 트리(Tree)와 같은 계층적(Hierarchical)인 기반 구조를 말한다.
프레임워크는 다소 수평적인 의미를 갖는 하부 구조(Infra Structure)를 나타낸다.
아키텍처는 더 포괄적인 개념으로 스트럭처와 프레임워크 모두를 포함하는 체계적인 기반 구조를 의미한다.

따라서 프레임워크와 아키텍처는 다음과 같이 표현할 수 있다.

Framework = Design Pattern + Library
Architecture = Structure + Framework

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18

Maven 설치 요약 (Windows)

2009-10-27T10:25:02+09:00

1. 설치

- Maven 2.2.1(zip) 다운로드
- apache-maven-2.2.1-bin.zip를 원하는 디렉토리에 압축을 푼다.

e.g. C:\Dev\apache-maven-2.2.1

2. 설정

- 시스템 등록정보(WinKey + Pause)를 열고 고급탭으로 이동한다.
- 다음 각각의 환경변수를 등록한다.

M2_HOME: C:\Dev\apache-maven-2.2.1
M2: %M2_HOME%\bin
JAVA_HOME: C:\Program Files\Java\jdk1.5.0_20\

- PATH 환경변수에 다음 항목들을 추가(확인)한다.

%JAVA_HOME%\bin
%M2%

3. 확인

- 새로운 명령 프롬프트(Winkey + R, cmd)를 열고 다음 명령을 수행하여 설치를 확인한다.

mvn --version

4. 참고

- Apache Maven Project: http://maven.apache.org/
- Maven Download: http://maven.apache.org/download.html
- Settings reference: http://maven.apache.org/settings.html

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18

WinKey+R을 대체하는 Application Launcher

2009-10-27T09:24:13+09:00

Windows 환경에서 빠르게 특정 어플리케이션(프로그램)을 실행시키기 위해서, 대부분 "시작 > 실행" 메뉴를 클릭하거나 "WinKey+R" 단축키를 주로 사용한다. 이때 실행되는 기본 론처(Launcher)가 "windows run"인데, 이와 유사한 프로그램으로 어플리케이션 론처의 기본 기능에 충실하면서 여러가지 부가기능을 추가하여 편의성을 높이고 보다 유려한 GUI를 표현하는 유용한 프리웨어가 몇개 있다. Launchy, Executor, Enso, RocketDock 등의 유틸리티(Utility)가 이들 프로그램이다.

1. Launchy

Launchy는 Windows나 Linux 환경에서 돌아가는 유틸리티 프로그램이다. 몇개의 키만을 타이핑하여 시스템에 등록되어 있는 프로그램을 실행하거나 폴더를 열수 있다. 심지어 URL을 입력하면 기본 브라우저에 해당 페이지를 로드해준다.

Launchy는 백그라운드로 실행되는데, ALT+SPACE를 사용해 숨겨진 Launchy 입력창을 나타나게 할 수 있다. 작업을 취소하려면 ESC(escape) 키를 누른다.

2. Executor

Executor는 Launchy와 유사하지만 조금 더 다양한 옵션을 갖고 있다. Executor은 스킨을 지원한다. WinKey+Z 키로 프로그램을 실행한다. 자세한 내용은 홈페이지를 참고한다.

3. Enso Launcher

Enso 역시 Launchy, executor 등과 유사한 프로그램인데 보다 간결한 인터페이스가 특징이다. Aza Raskin이란 사람과 그의 동료들이 만들었다고 하는데 Aza Raskin는 매킨토시 UI의 창시자, 고(故) 제프 래스킨의 아들이라고 한다. 위의 프로그램들과 다른 것은 Caps Lock 키를 누른 상태에서 Enso command를 추가로 타이핑해야한다는 것이다.

4. RocketDock

RocketDock은 위에 소개한 프로그램들과는 다르게 독킹 바(Docking Bar)에 바로가기(shortcut)을 등록하여 마우스로 작동하는 론처이다. 마우스를 올리면 아이콘들이 부드럽게 움직인다. 다음은 유투브에 올려진 RocketDock 소개 동영상이다.

동영상의 버전은 1.3.0 Final 이지만 현재 최신 버전은 작년(?)에 출시된 1.3.5 버전이다.

"Useful Tools" 카테고리의 다른 글

WinKey+R을 대체하는 Application Launcher (댓글 2개 / 트랙백 1개) 2009/10/26
공짜로 나눠주는 폰트 - 공개 글꼴(무료 서체) (댓글 2개 / 트랙백 1개) 2008/12/16
무료 EXIF 정보 뷰어 - 오판다(Opanda IExif) (댓글 2개 / 트랙백 1개) 2008/12/05
Planner, 프로젝트 관리 툴 소개 (댓글 2개 / 트랙백 0개) 2008/11/05
Google Chrome - 오픈소스 브라우저인 구글 크롬 (댓글 8개 / 트랙백 2개) 2008/09/03

재미있는 사진을 만들어주는 사이트

2009-10-16T12:39:10+09:00

예전에 재미있는 사이트 - 사진 자동 합성 포스트에서 PhotoFunia를 소개한 적이 있다. 오늘 비슷한 사이트를 하나 더 발견했는데, PicJoke.com이다.

사이트의 몇가지 효과(?)를 적용해본 샘플 사진들이다. 모델은 물론 나. ^^;
각종 효과들이 월별로 계속 업데이트되는 것 같다.

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

포토프린터 CANON PIXMA iP4680

2009-10-07T14:06:26+09:00

집에서 사용하던 기존 프린터는 CANON의 포토프린터, PIXMA iP4200이었다. 사진을 좋아하고, 가끔씩 마음에 드는 사진을 집에서 간편하게 출력할 요령으로 2006년에 구입한 제품이었다. 정품 잉크가 비싸 유지비가 일반 잉크젯에 비해 많이 들어가는 것이 단점이었지만, 빼어난 사진 인쇄 품질 때문에 나름 만족하며 사용해왔다.

그런데 이넘이 얼마전부터 가끔씩 오류를 내뱉으며 출력을 거부하곤 했다. 왜그런가 하고 이것저것 만지작거리다보니, 결론은 관리소홀. 프린터의 상판이 조금 내려앉은 것이 문제가 되었다. 상판 위에다 무거운 책자들을 그렇게 올려놓고 있었으니... -_-

어쨌던 그럭저럭 그런대로 사용하던 와중에 잉크가 바닥났다. 그래서 잉크 세트를 하나 구입하려고 하다가 8만원돈을 주고 삐걱거리는 프린터의 잉크를 사서 쓰느니, 새로 하나 사는게 낫겠다는 생각이 들었다.

처음엔 유지비를 고려해서 복합기(복사기+프린터+스캐너+팩스)인 캐논 MX-328로 마음이 기울었지만, 아무래도 사진 품질이 포토프린터만 하겠는가 하는 미련을 차마 떨쳐낼 수 없었다. 결국 iP4200의 상위 모델인 CANON PIXMA iP4680으로 낙찰. 정품잉크 포함 14만원 정도에 구입했다.

두 개 제품의 이미지를 합쳐서 편집해보았다. 외양이 약간 다르고 색상도 다르지만 전체적인 구조는 유사하다.

캐논코리아에 소개된 iP4680의 특징이다.

최대 9,600dpi 고해상도 출력
흑백 7.3ipm, 컬러 6ipm, A6포토출력 20초 출력속도
CD/DVD 프린팅 기능
인테리어 감각의 컴팩트한 디자인
Hybrid시스템으로 선명한 출력물
FINE카트리지로 고품질 고속 포토 출력
ChromaLife100+잉크 시스템 적용
유지비가 저렴한5색 분리형 잉크 탱크 채용
자동 양면 출력 및 양방향 300매 대용량 용지 급지
강화된 이미지 편집 소프트웨어
자동 사진 보정 기능
카메라 다이렉트 출력

iP4680의 제원은 다음과 같다.

iP4200에 비해 전체적인 성능이 업그레이드되었고, 특히나 CD/DVD 라벨(Label) 프린팅 기능이 포함된 것이 맘에 들었다. 가끔 애들 영화를 공CD나 공DVD에 구을 일이 있는데, 악필로 적어놓은 글씨로는 영 관리가 안되었다. 프린트를 받자마자 우선 사진 인쇄를 테스트해보고, 바로 DVD 레이블 인쇄를 해보았는데, 역시 일반 DVD라서 그런지 표면에 잉크가 잘 먹질 않았다. 인쇄를 지원하는 CD나 DVD를 구입한 후 다시 테스트해봐야겠다. 아무튼 사진 인쇄를 위해 구입했지만 멀티미디어에 관심이 많다면, 체계적인 CD, DVD 미디어를 정리할 용도로도 구입을 고려해 볼 수도 있는 제품이다.

참고로 정들었던 IP4200의 스펙이다.

그나저나 앞으로도 정품 잉크를 계속 사용하게될 것 같긴 한데, 유지비를 생각하면 무한 잉크에 대한 유혹도 떨쳐버릴 수는 없다. 한번 써볼까? ^^;

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

리퀴몰리 엔진오일(합성유) - LIQUI MOLY 10w-40 MoS2

2009-10-07T04:49:41+09:00

얼마전에 큐서비스에 들러 엔진 오일을 교환했다. 캐스트롤 마그네틱(Castrol Magnatec) 5W40(차량정비)을 넣어왔었는데, 가는날이 장날이라 제품이 없었다. 대신 정비사가 추천해준 것이 리퀴몰리 엔진오일(LIQUI MOLY 10w-40 MoS2)이었는데 처음 보는데다 고가라 조금 망설여졌다. 순정으로 갈까 하다가 얼마나 좋은가 하는 궁금증을 이기지 못해 그걸로 넣어달라고 했다.

진열된 제품을 옴니아(SCH-M490)로 찍었다. 옴니아, 이럴 때 편하군... ^^

후에 알아보니 리퀴몰리(LIQUI MOLY)는 케미컬 제품으로 상당히 브랜드 인지도가 있는 회사였다. MoS2(고형 몰리브덴 이황화물)는 리퀴몰리가 개발하여 세계 특허권과 상표권을 보유한 금속 성분의 마찰력 감소제로 후 엔진의 치료와 소음감소에 탁월한 효과를 발휘하며 대폭적인 엔진성능 회복을 위해 특별히 개발된 엔진오일이란다. 일명 '흑연오일'이라나.

리퀴몰리 MoS2의 특징이다.

손상엔진 치료용 합성 엔진오일
MoS2 함유 내마모성, Limp home특성
높은 연료절약성능, 매연감소효과
뛰어난 고, 저온 윤활안정성
촉매 변환장치, 터보 테스트 통과

이런! '손상엔진 치료용' 이라니! 좋은 차는 아니지만 아직은 쓸만한 차인데, 낚였나하는 생각이 든다. -_-

엔진오일을 교체할 때 보니 특이한 점이 있었는데, 오일의 색상이 일반적인 구리빛과는 다르게 회색빛이 났다. 색이 이상하네요? 했더니, 이건 원래 그렇단다. 오일 교환 후 몇주 정도 차를 타면서 느낀건데, 캐스트롤 마그네틱과는 조금 다르게 엔진 회전이 비교적 묵직하고 부드러워진 느낌이 났다. 모, 그래도 값은 하는구나 싶었다.

오래전부터 쎄라토클럽에서 가끔 눈팅하면서 보건데, 큐서비스가 상대적으로 비싼 경향이 있다. 실제 제품가를 검색해봐도 평균가 이상이다(공임비 제외). 리퀴몰리의 경우 1만에서 1만5천 정도까지는 탈 수 있다고 한다. 아무튼 다음번엔 직접 구입한 오일을 들고 가서 공임만 주고 교체해볼까 한다.

그나저나 차량 배터리가 위태위태하다. 배터리 액이 흘러나와 단자 주위를 허옇게 덮은 것을 청소한 적이 있는데, 가끔 시동이 한번에 안걸린다는... 올 겨울 오기 전에 필히 갈아야지싶다. -_-

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

프로젝트 후기

2009-10-05T11:49:29+09:00

난항의 프로젝트

앞선 포스트에서도 몇차례 언급했었지만 지난 프로젝트는 이런저런 요인들로 난항의 연속이었다. SI에 몸담고 개발자로서의 첫발을 디딘 후로 꽤나 많은 시간들을 보내면서 그동안 적지않은 프로젝트를 경험했지만, 스트레스의 강도로 따지자면 손가락 안에 꼽을 정도로 힘든 프로젝트가 진행되었다.

그래도 PM을 비롯하여 말단 개발자까지 합심하여, 프로젝트 기간내내 대부분의 주말도 반납하고 하루하루 밤늦도록 열성을 다하여 전력질주한 끝에 다소 불안정한 상태였지만 그럭저럭 서비스를 오픈할 수 있었다. 덕분에 지난 7월 오픈을 전후하여 나를 포함해 대부분의 투입 인력이 철수하였다. 하지만 아직까지도 몇몇 SM 인력들이 주어진 숙제를 안은채 서비스를 안정화하고 품질을 높이기 위해 불철주야 노력하고 있다.

난항을 겪는 프로젝트가 흔히 그렇듯이 상대적으로 할 일은 많은데 절대적인 시간이 부족했다. 어느정도의 리스크를 이미 전제조건으로 떠안고 시작한 프로젝트. 끊임없는 강행군으로 심신은 지쳐가고 다가오는 데드라인에 중압감은 쌓일대로 쌓여 프로젝트룸의 공기가 어느덧 숨이 턱턱 막힐 정도로 무거워진 무렵의 어는날엔, 말그대로 드라마에서 나올법한 "드라마틱한 사건"이 벌어지기도 했다. 돌이켜보건데, 다 사람 사는 일이라 벌이진 해프닝으로 치부할 수도 있으련만 프로젝트가 중후반에 이르면서 그만큼 다들 극도의 스트레스를 받고 있었다는 반증이 아닐 수 없다.

어려웠던 프로젝트는 이유가 있기 마련이다. 하지만 현재 시점에서 업무며 설계며, 커뮤니케이션니 협업이니 기타등등의 원초적인 부분에 대해 언급하고 싶지는 않다. 또 이들의 비중이 막대하지만 프로젝트의 성패를 좌우하는 전부가 되지는 못한다. 실제로 보다 복잡한 요인과 설명하기 어려운 요소들이 얼기설기 얽혀있기 마련이다.

단편적 회고

다만 기술적인 관점에 있어서 하나의 단편적인 부분을 언급해보고자 한다. 그러기 전에 먼저 프로젝트의 개발 환경에 대해 짧게 소개하자면, 시스템은 크게 Spring2.5을 기반으로 하여 Struts2와 iBATIS의 오픈소스 프레임워크의 조합과 기타 라이브러리들을 사용하여 구축되었다. 그리고 AJAX(Prototype 기반)와 DWR(Direct Web Remoting)을 사용하여 UI에서 발생하는 사용자 액션(이벤트)들을 처리하였다.

대강의 환경과 툴, 주요한 라이브러리를 정리해보았다.

Environments

JAVA: JSDK 1.5, J2EE 1.4+(Servlet 2.4, JavaServer Pages 2.0 JSTL 1.0 이상 지원 환경)
WAS: JEUS 6.0 (개발: Tomcat 6.0.18)
WEB: WebtoB 4.1
DB: Oracle 10g

IDE & Tools

IDE: Eclipse Ganymede 3.4.1
Reporting Tool: Report Designer
Version Control: Subversion 1.5.5
Code Generator: 단위업무에 필요한 JSPs(코드 템플릿), Java(Action/DAO/Model), 설정(Struts/iBATIS) 등의 파일 목록 자동 생성.

Open Source - Framework & Library

Java Libraries
- Spring 2.5.6 (Base)
- Spring Security 2.0.4 (Security)
- Struts 2 (MVC)
- iBATIS 2.3.4.726 (SQL Mapper)
- Direct Web Remoting 2.0.5 (DWR)
- SiteMesh 2.4 (Layout)
- Quartz 1.6.4 (Scheduler)
- JExcelApi 2.6.9 (MS Excel)
- Log4J 1.2.15 + Jakarta Commons Logging(JCL) 1.1.1 (Logging)
- Apache Commons - DBCP, BeanUtils, Collections, etc…
- FCKeditor 2.4.1 (Rich Text Editor)
AJAX & Javascript Libs
- Prototype JavaScript framework, version 1.6.0.2
- The Yahoo! User Interface Library (YUI)

라이브러리와 여타 종속성이 있는 라이브러리들을 포함하다 보니, lib 디렉토리가 적잖게 비대해진 면이 있다.

이슈

라이브러리의 조합은 무척 일반적인데 비해, 구현 일정에 있어서 개개인의 노력도와 투자한 시간에 반하여 전반적으로 개발 퍼포먼스가 나지않는 것이 큰 이슈가 되었다. 표준과 개발 가이드가 미비하고 공통 관련 구현체 및 개발 구조의 완성도가 미흡한 상태에서 급하게 개발에 착수한 것이 역시 독이 되었다. 여기서 비롯된 구조적인 결함과 취약점들이 원인이 되어 개발자들에게 혼란을 초래하고 기술적인 진입장벽을 형성하였고 결국 개발 생산성과 효율이 극도로 저하되었다.

주목할 만한 것은 Spring 기반 위에서 Struts의 Action, 비즈니스를 수행하는 Service, DAO 및 iBATIS SqlMap, 그리고 Model을 아우르는 구현부와 설정들에 있어서는 비교적 손쉽고 안정적으로 개발이 진행된 반면, 상대적으로 UI 단을 개발함에 있어서 단연 부하가 심했다는 사실이다. 계층화된 아키텍처로 Presentation(UI) Layer, Service(Business Logic) Layer, Persistence(Data Access) Layer 등 크게 세 계층으로 구분할 때 개인적으로 판단해보건데, P/T Layer을 개발하는데 60% 이상의 공수가 걸리지 않았을까 싶을 정도다. 웹 개발의 특성상 UI에 잔손이 많이 가는 것은 어쩔 수 없는 부분이지만 이클립스에 업무 핵심인 비즈니스 로직과 관련 쿼리를 작성하기 위해 자바 소스나 XML 파일을 열어놓기 보다는 UI 코드를 작성하기 위해 JSP나 JS 파일을 띄워놓는 시간이 단연 많았다.

대부분의 UI 이벤트를 처리하기 위해서 Ajax 및 DWR이 사용되어 javascript에 대한 의존도가 높아진 반면, 개발자 대부분이 상대적으로 Ajax 및 객체지향적인 스크립트에 대한 경험이 취약한 상태였다. 게다가 개발 템플릿으로 만들어진 개별 페이지의 구조가 다소 일반적이지 않은 모양새였는데, 페이지 구조에 일관성을 부여하고 페이지에서 발생할 수 있는 대부분의 기능(script)를 공통화하여 개발 편의를 증대하고자 한 것이 결과적으로 득보다는 실을 가져다 준 셈이었다.

페이지의 구조에 대해서 좀더 자세히 얘기를 하자면 먼저 구현한 페이지의 형태에 대한 이해가 필요하다.

충분히 응용될 수 있지만 일반적이지는 않은 페이지 구조이다. Main이 되는 JSP에는 검색, 목록, 상세, 등록, 수정, 삭제 등과 관련한 각각의 UI 요소 및 Form들을 포함하기 위한 영역으로 정의된 Place Holder(DIV)들이 위치한다. 각 영역에는 목록, 상세, 등록, 수정 등의 JSP Fragment(*.jspf)들이 템플릿화 되어 삽입(include)되어진다. 이 형태를 기본 페이지 레이아웃으로 하여 각각의 단위업무 기능에 따라 첨삭이 가해졌다.

쉽게 얘기해서 목록 페이지 따로, 등록(수정) 페이지 따로가 아니라 메인 페이지가 검색, 목록, 상세, 등록, 수정, 삭제 등 각 기능별 템플릿들을 모두 미리 포함(로드)한 상태에서 사용자 액션(이벤트)에 따라 Place Holder 들에 대한 visible 속성 및 필요한 제어 로직을 갖는 구조이다. 사용자 액션에 의해 Request가 발생하면 비동기 방식으로 서비스를 호출(Ajax call)하게 되고, 서비스(Struts Action 및 비즈니스 수행부, DAO 등을 포괄)를 수행 후 result에 따라 XML 형태의 뷰(view) 페이지를 Ajax의 callback method에서 전달받아 jspf 템플릿에 데이터를 주입(치환)하는 방식이다. 완전히 일치하지는 않지만 기본적인 흐름은 다음 그림과 유사하다.

어쨌든 이러한 페이지 구조는 정형화되고 일반적인 패턴의 화면은 아주 쉽고 빠르게 구현할 수 있었지만, 화면의 복잡도가 증가하고 예외적인(다소 일반적이지 못한) UI 유형을 포함하게 될 때에는 처리가 복잡해지고 더불어 몇가지 제약사항을 야기시켰다. 결과적으로 개발자들은 주로 UI의 요소를 컨트롤하고 이벤트를 처리하기 위한 script block과 씨름하는 것에 대부분의 시간을 할애하게 되었다. 또한 Ajax 결과로 Struts에서 View로 넘어온 XML 데이터를 UI 템플릿의 대응하는 위치에 치환하는 작업도 개발자들이 어려워한 부분이었다. 특히 단건의 데이터가 아닌 복합적인 Collection의 형태로 넘어온 목록 데이터를 반복하여 보여주는 처리를 난감해 하였다. 이것은 XML 데이터를 템플릿상의 동일 ID항목으로 치환해주는 공통 script가 갖는 한계점도 있었고, Service, Action, Dao 등의 Base class들과 기타 관련 class 들의 구조, 그리고 Struts Value Stack에 대한 개발자들의 이해가 부족했던 것이 주요한 원인으로 작용하였다.

정리

최근 몇년간의 프로젝트에서는 직접 제반 개발 환경을 세팅하고, 프레임워크를 구현하고, 개발 구조를 정의하고, 개발을 가이드하는 등의 역할을 수행해왔다(프레임워크는 주로 오픈소스를 조합하여 구성). 그런데 이 프로젝트의 경우, 구현 일정이 워낙 촉박한 데다 업무의 특성을 고려하다보니 해당 업무를 전문으로 하는 업체에서 노하우가 녹아있는 완성도 있는 컴포넌트와 솔루션을 들고 들어와서 함께 구축하는 방향으로 급선회하게되었다.

그런데 이것이 애초의 기대한 바와는 다른 부분이 적지 않았다. 개발 사상적인 시각에서도 협력사의 개발자와 약간의 차이가 있었다. 이러한 부분을 극복하기 위해 개발과 병행하여 기본이 되는 코드와 구조를 꾸준히 리뷰하면서 개선할 점을 논의하고 반영해 나갔다. 그렇지만 근본 틀을 바꿀 수는 없는 상황이라 여전히 한계가 있었다. 문제가 된 페이지의 구조와 Ajax 위주의 개발 패턴 역시, 이미 많은 것들이 이들을 기반으로 맞물려 돌아가는 상황이라 들어낼 수는 없는지라 대안으로 복잡한 화면 처리를 위한 유형을 하나 더 패턴화시키는 정도로 처리하였다.

정리하자면, 필요에 따라 응용할 수 있는 페이지의 구조를 오히려 전체 페이지에 대한 표준으로 일반화시킨 것과 지나치게 Ajax 기반으로 처리하는 개발 패턴이 구현상의 가장 큰 오류가 아니었나 싶다. 프로젝트에서 철수하고 더더욱 확신이 드는 생각이 두가지 있다. 하나는 "일반적인 것이 좋은 개발 구조"라는 것이다. "일반적"이라는 것에 대한 정의가 모호해질 수 있겠지만, 어떤 개발자들이 붙더라도 쉽게 적응하고 응용할 수 있도록 진입장벽을 낮추고 잘 구조화 시켜야한다. 덧붙여 일반적이라는 것이 품질 또한 일반적일 것을 보장할 것이라 생각하지는 않는다. 확신의 또다른 한가지는 "과유불급". 지나친 것은 좋지 않다는 것이다. 이를테면 Ajax가 UI의 가능성과 유연성을 높이는데 도움이 되는 것은 사실이지만 이것이 전체 이벤트를 제어하는 메인 기술이 되어서는 안된다는 생각이 든다. 필요한 부분에 적절히 사용되어야 한다.

대강 정리를 해보았지만 한편으로는 프레임워크와 스트럭처를 조금더 보완하고, 개발 전에 아키텍처의 컨셉과 개발 절차 및 응용 단계에 대해서 개발자들과 충분히 공유할 수 있었다면, 몇가지 단점들을 충분히 상쇄(trade-off)할 수 있는 장점도 있지 않을까 싶기도 하다(이를 설명하자면 전체 개발 구조에 대해서 좀더 이해해야 할 내용들이 많아진다). 협력사의 인력들도 중고급 이상으로 구성된 상당한 고수들이었고, 고심해서 작업한 흔적이 전체적으로 역력했다. 적용한 프레임워크와 개발 구조에 대해서는 쉽게 평가하기 전에 좀더 고민해볼 부분 많을 것으로 생각한다. 다만 한가지 확실한 것은 시도는 좋았지만, 실험정신을 발휘하기엔 시기가 적절하지 않았다는 것이다.

P.S.

지난 프로젝트의 성패를 떠나서 여러가지 관점에서 시사하는 바가 적지않다. 경험이 쌓여가는 것과는 무관하게 여전히 배워야할 것도, 공부해야할 것들도 많다. 반성해야할 것도 많고 인간적으로도 좀더 성숙해야 되지 않을까 싶기도 하다. 개인적으로 그동안 개발 방법론적인 부분에 있어서도 부족함이 많았는데, Agile 개발 프로세스나 XP(Extreme Programming), TDD 등 연구하고 적용해볼 분야가 많음을 새삼 느껴본다.

뜨거운 청춘들과 가정이 있는 사람들이 개인사와 가족을 뒤로 하고 했던 고생들이 그저 고생으로 끝나고 남는것이 없지 않기를 바란다. 문제점이 없진 않았지만, 시행착오를 통해 나를 비롯해 다들 조금더 성숙한 개발자가 될 수 있는 계기가 될 수 있기를 진심으로 바란다.

후기랄 것도 없이 종료한 프로젝트에 대한 간단한 감상이나 적어보려고 했는데, 쓸데없이 글이 길어졌다. -_-

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18

예천에 다녀왔다.

2009-09-23T10:06:14+09:00

민족의 명절 추석을 앞두고 지난 주말, 벌초와 성묘를 겸해 고향 예천을 미리 다녀왔다. 작년 이맘때에도 성묘를 다녀온 후에 포스트 "성묘 다녀오는 길, 내 고향은 예천이다." 하나를 올렸었다. ^^

예천이 고향이다 보니, 지난주인가 우연히 보게된 "1박 2일"에 등장한 예천과 회룡포의 모습이 유난히 반가웠다. 지난해 가을에는 회사 사진 동호회 멤버들과 회룡포로 가을 출사를 다녀온 후에 "육지 속의 섬마을, 회룡포엔 가을빛이 내리고 있었다."라는 포스트를 작성하기도 했었다. 1박 2일 멤버들의 뒷편으로 보이는 배경이 새삼스레 정겨웠다.

그때 회룡포를 찍은 전경 사진이다. 클릭하면 큰 그림을 볼 수 있다.

지난 주말에는 짧은 추석으로 성묘가는 차들이 많을까 싶어 새벽 5시부터 부지런을 떨었다. 긴 여정 끝에 저녁 9시가 넘어서야 녹초가 되어 집으로 돌아왔지만, 누렇게 익어가는 벼들과 곧 다가올 가을을 알리듯 맑고 높은 하늘은 피곤함을 말끔이 씻어주었다.

올 가을에도 어디론가 가긴가야하는데...
동호회 멤버들에게 운을 한번 띄워볼 참이다. ^^

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

마트료시카 보드카와 발렌타인

2009-09-23T23:45:32+09:00

이전에 "오늘 밤엔 '루스키 스탄다르트' 한 잔을! ^^"이란 포스트를 올린적이 있다. 동생이 러시아에서 가져온 보드카가 거의 바닥을 드러낼 무렵, 동생이 또다시 인도로 출장길에 오르게 되었다. 벌써 3개월 전 일이다. 그 기회를 놓칠새라 나는 맛좋은 술 한병을 부탁하게 되었는데...

무색, 무미, 무취의 묘한 매력에 매료되어 이왕이면 루스키 스탄다르트를 한번 더 부탁하고 싶었지만 러시아에서만 판매되는 보드카이다. 아쉬운대로 위스키(Whiskey)쪽으로 방향을 잡았다. 다음 기회엔 브랜디(Brandy)를?! ^^

6월 중순 즈음 출장을 다녀온 동생이 이사를 가서 집들이를 하게 되었고, 그 자리에서 부탁했던 양주 한병을 수중에 넣을 수 있었다. ^^

한국에서 위스키 하면 유독 떠오르는 것은? "발렌타인(Ballantine)"이 아닐까 싶다. 바로 그 발렌타인하고도 21년산이다.

예전에 바(Bar)에서 마셔봤던 것도, 면세점에서 직접 사왔던 것도 모두 17년 산 이하의 것들이었다. 21년은 어떨까하는 궁금증에 바로 그날 밤, 자기 전에 뚜껑을 열었었다. 따를 때 꼴록꼴록하며 기분 좋은 소리를 내었고, 한 모금 천천히 마셨을 때 목구멍을 부드럽게 타고 넘어가는 것이 느껴졌던 기억이 난다. ^^

그렇게 가끔 한잔씩 하던 것이 3개월이 지난 지금 반 조금 넘게 남은 것 같다.

사실 동생 집들이 때 입수한 술로 발렌타인 외에 하나가 더 있었다. 우연히 진열장에 장식되어 있던 예쁜 술병 하나에 눈이 꽃혔는데, 물어보니 러시아 출장 때 현지인들이 선물로 준 것이라나. "술은 마실 줄 아는 사람이 마셔야 한다"며 너스레를 떠니 의외로 순순히 건네 주었다. 기특한 놈.

바로 "마트료시카 보드카"다. ^^

마트료시카, 러시아어로 'Матрёшка'이고 '마트료시카' 혹은 '마뜨료쉬까' 또는 '마뜨료슈까'라고 읽는다. 영어로는 'Matryoshka'이다.

마트료시카(러시아어: Матрёшка)는 러시아의 나무로 만든 인형이다. '마트료시카'는 러시아어 여자 이름 마트료나(Матрёна)의 애칭형이다.
몸체 속에는 조금 작은 인형이 들어가 있다. 몇회를 반복하는 상자구조로 되어 있다. 6중 이상인 경우가 많다.
각각의 인형은 여인이 그려져 있는 것이 기본이지만, 대통령 등 유명인이 그려진 변형도 있다.
러시아에서 처음 만들어진 것은 1890년으로 알려져 있다. 일본에서 나온 기념품에서 착안하였다고 한다. 1900년에 러시아 각지에서 여러가지 마트료시카가 만들어지게 되고, 러시아 민예품, 선물로 알려지게 되었다.

위키백과에서 인용하였다. 이 페이지에 보면 재미난 사진도 함께 있는데, 러시아 지도자들 모양의 마트료시카이다. 왼쪽부터 보리스 옐친, 미하일 고르바초프, 레오니트 브레즈네프, 니키타 흐루쇼프, 이오시프 스탈린, 블라디미르 레닌, 니콜라이 2세란다.

아마 러시아 여행에서 돌아오는 길에 가장 많이 사오는 기념품 중의 하나가 마트료시카가 아닐까 싶다. 보드카와 함께. ^^

'마트료시카 보드카'. 첨엔 이 술이 어떤 술인지 어떻게 불러야 하는지 몰랐다(동생도 몰랐었다). 컴퓨터를 켜고 무작정 보드카 이미지를 검색했었는데, 수십 페이지를 지나서야 가지고 온 병과 비슷한 모양의 이미지를 찾을 수 있었다. 그것을 기초로 다시 검색에 검색. "마트료시카 보드카"의 정체를 알아내었다. 근데, 이게 또 생각보다 괜찮은 보드카일지도 모르겠다. "Matrioshka vodka — Best vodka 2008!" 이란 페이지가 보였다. 페이지의 그림을 보면 내가 찍은 사진의 술병 모양과 거의 똑같지 않은가?! ^^

참고로 "마트료시카 보드카 웹사이트"란 곳도 있는데, 여기가 공식 사이트일지도 모르겠다.

아무튼 이 마트료시카 보드카는 아직 미개봉 상태이다. 왠지 아쉬운 생각에 술병에 손이 잘 가지 않았는데, 오늘 이 포스트를 작성하면서 문득 한잔 해볼까 하는 생각이 든다. 저런!

오늘 밤에도 잠은 잘 올 것 같다. ^^

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

난 스마트폰, 옴니아(T*Omnia) 유저다.

2009-09-22T08:52:15+09:00

요즘 IT 관련 뉴스를 보다보면 스마트폰 관력 소식이 끊이질 않고 있다. 곧 삼성의 옴니아2가 출시되고, 애플 아이폰 출시도 초읽기에 들어갔다. 아직 루머 수준이지만 MS도 베일속에 가려진 스마트폰(핑크폰)을 준비중이란다. 모토로라를 비롯해 LG에서는 구글 안드로이드 폰을 내놨다. 블랙베리, 노키아에서도 고성능 스마트폰을 잇따라 출시하고 있다. 최근 스마트폰 시장은 그야말로 뜨겁게 달아오르고 있다.

최근까지 줄곧 공짜폰을 써오다가 사용하던 기기에 이상이 있어 쓸만한 공짜폰 하나 더 건져보려 세티즌을 들락날락하고 있었다. 그러다가 눈에 띈 것이 옴니아(T*Omnia)이다. 원래 SKT를 사용중이라 옴니아를 구입하려면, 보상 기변밖에 안되어 결코 적지 않은 금액을 지불해야했다. 평소 같으면 "오~ 부럽삼!" 한마디 남기도 돌아섰을 나인데 툭툭 튀어나오는 스마트폰 소식들에 세뇌를 당한 탓인지, 귀신에 홀렸는지 지난 8월 7일 기어코 100만원이나 하는 옴니아를 덥썩 구입하고야 말았다. 물론 보상기변에 24개월 노예 계약으로. ^^;

구입할 당시 옴니아2나 아이폰을 기다릴까 하는 맘도 있었지만, 이내 포기하고 번호이동이 가능해 비교적 저렴한 소니에릭슨의 엑스페리아 X1과 옴니아를 저울질하기를 2주(머리에 쥐나는지 알았다). 결국 쿼티(QWERTY) 자판의 뽐뿌를 물리치고 전지전능한 옴니아를 선택했다(옴니아는 'Everything' 이라는 모든 것을 의미하는 뜻의 라틴어이다)! ^^

옴니아는 SCH-M490, SCH-M495의 두가지 모델이 있는데, 내가 구입한 것은 4G 내장메모리의 SCH-M490이다(SCH-M495은 내장메모리가 16G이다).

SCH-M490의 스펙이다. (출처: 세티즌 SCH-M490 전문가 리뷰)

형 태	바
크 기	115.2(L) x 58.1(W) x 13.65(H)mm
무 게	131g
색 상	모던 블랙
LCD 사양	3.3 Inch WVGA 65K TFT Touch LCD
카메라	500만 화소 CMOS (AF 및 플래쉬 지원) + 전면 VGA CMOS 카메라
CPU	Marvall Monahans PXA 312 806MHz LV
메모리	Internal 160MB
운영체제	Microsoft Windows Mobile 6.1 Professional
GPS	S-GPS
Internet Browser	Opera Browser, Wep Viewer, Internet Explorer
Wi-Fi	지원함(802.11 b/g)
충전/통신단자	표준 통합 20핀
멜로디	MP3
배터리	구분	표준형(1440mAh)
	연속통화시간	약 270 분
	연속대기시간	약 510 시간
기본 구성품	본체, 표준형 배터리 2개, 배터리 충전 거치대, 스트랩 어댑터, 데이터 통신 케이블, 폰 거리형 스타일러스, 가죽 케이스, 스테레오 이어폰, 마이크 케이블, Companion CD, Application CD, 사용설명서
DMB	지원함(위성)
영상통화	지원함(T)
멀티태스킹	지원함
외장 메모리	지원함 (Max : Micro SDHC 8G)
블루투스	지원함 (Ver 2.0)
통신 규격	WCDMA HSDPA

삼성전자는 세계 1위를 넘보는 휴대폰 제조사이지만 스마트폰 시장에서의 위상은 아직 미미한 편인데, 스마트폰 라인업인 옴니아 시리즈를 통해 스마트폰 시장에서도 일반폰에 버금가는 위상제고에 나서고 있다. 다음 두 기사를 통해 옴니아 라인업을 참고해볼 수 있다.

옴니아를 구입하고 사은품으로 받은 실리콘 케이스를 임시로 사용하다가 SGP 케이스를 구입하여 장착하고, 슈타인하일 크리스탈 액정보호필름을 붙였다.

아직 옴니아 활용처가 불분명하여 그저 무제한 무료인 Melon으로 음악을 다운로드 하여 듣거나 와이파이(WI-FI)로 집이나 사무실 AP에 붙어 (굳이 편한 노트북 냅두고) 인터넷 뱅킹 정도를 해보는 수준이다. TU로 DMB 시청 몇차례 해보고, 괜한 카메라 셔터를 눌러 보는 정도?! 아직까지는 별로 스마트하지 못한 유저이다.

비싼 돈 주고 산 만큼 본전 뽑아야 하는데 말이다. 카페들 기웃거리며 하나씩 이것저것 건드려볼 참이다. 사실, 조만간 Windows Mobile 기반의 간단한 어플리케이션을 만들어볼까 하는 조금은 거창한 의욕도 갖고 있다. 책도 한 권 샀다는... ㅋ~ 원래 닷넷 개발을 해봤던 터이고 Windows Form을 활용하여 스마트클라이언트를 개발한 경험이 있으니, 스마트폰? 까이꺼! 하는 매우 거만한 생각도 든다. 과연!? ^^;

어쨌거나 개발자니만큼 이쪽으로 취미 붙여보는 것도 나쁘지는 않을것 같다. 헙!

옴니아 사진을 하나 더 붙여본다. 모델은 나의 사랑하는 귀여운 찬영군. 지난 주에 만 두살이 되었다. ^^

따식~! :)

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

Programming Fonts - 나눔고딕코딩 글꼴 등

2009-09-18T15:13:58+09:00

일전에 "공짜로 나눠주는 폰트 - 공개 글꼴(무료 서체)"란 제목의 포스트를 올린적이 있다. 이 글에서 소개를 했던 네이버 나눔글꼴 을 소개했었는데, 이번에는 개발자를 위한 글꼴 하나를 더 소개해볼까 한다.

개발자용 나눔고딕코딩체는 나눔고딕을 개선하여 개발자 여러분들이 개발 작업을 좀더 편리하게 하실 수 있도록 최적화된 글꼴입니다. 고정폭 형식으로서 소스코드 편집을 위한 각종 편집기나 터미널에서 가독성을 높였고, 알파벳 대문자 아이(I)와 알파벳 소문자 엘(l), 숫자 1, 숫자 0과 알파벳 대문자 오(O) 혹은 알파벳 소문자 오(o) 등등 혼동되기 쉬운 문자들을 명확하게 구별될 수 있게 하여 원치 않는 코딩 오류를 최소화할 수 있습니다.

나눔고딕 코딩글꼴 에서 인용한 문구이다. 어느 정도의 코딩 경력이 있는 사람이라면 한번쯤 유사한 문자로 혼동되었던 경험이 있을 텐데, 그러다보니 오류를 줄이기고 가독성을 높이기 위해 나름 프로그래밍에 최적화된 폰트를 설정해서 사용하는 개발자들도 적지 않다. 위 인용문에서 보다시피 지난 2008년 10월 9일 발표된 나눔고딕코딩체 역시 그러한 목적으로 개발된 폰트이다. 나눔고딕코딩체는 OFL(Open Font License) 라이센스를 채택하고 있어 누구나 사용할 수 있는 폰트이다.

나눔고딕코딩 글꼴을 소개하는 김에 코딩할 때 주로 많이 사용하고 있는 폰트들을 뽑아보았다. 선정 기준은 "내멋대로!"라기 보다, 그동안 웹서핑하면서 많이 회자된다고 판단되는 폰트들을 위주로 하였다. ^^

Bitstream Vera Sans Mono
consolas
Fixedsys
Monaco
Courier New
나눔고딕코딩

비교를 위해 코드 예제를 해당 폰트로 설정한 편집기(Eclipse)를 스샷한 이미지를 첨부해 보았다. 참고로 폰트 설정시 모든 폰트의 사이즈는 "9"로 동일하게 맞추었다.

Courier New

윈도우 기본 폰트이자 대부분의 텍스트 에디터의 기본 폰트이다. 기본을 좋아하는 나로서는 현재까지 가장 즐겨쓰는 폰트이다. ^^

Bitstream Vera Sans Mono

개인적으로 코딩하기에 상당히 괜찮아 보이는 폰트이다. 처음 에디터에 적용했을 때는 다소 어색한 느낌이 없지 않았는데, 자꾸 보다보니 마음에 드는 폰트 중 하나이다. GNOME Project에서 관리되며 "이곳"을 통해 다운로드 할 수 있다.

consolas

Consolas Font Pack for Microsoft Visual Studio 2005 or 2008 페이지에서 다운로드 할 수 있다. 이 폰트 역시 썩 괜찮아 보인다.

Monaco

"이곳"에서 다운로드할 수 있다. Monaco 폰트도 나쁘지 않다. ^^

Fixedsys

윈도우 기본 글꼴 중 하나이다. 역슬래쉬 나오는 FixedSys 글꼴에 참고할만한 내용이 있다.

나눔고딕코딩

마지막으로 이번 포스트의 메인인 나눔고딕코딩. 설치 방법 참고. 위의 폰트들과 비교해 동일한 해상도에 상대적으로 많은 코드가 표현된다. 이것은 장점도 될 수 있지만 단점일 수도 있다. ^^;

어떤 폰트를 사용하느냐는 개인의 선택이지만, 한가지 중요한 것이 있다. 나는 개인적으로 팀에 소속되어 공통의 프로젝트를 수행하고 있다면 모든 팀원의 폰트를 한가지로 통일하는 것이 좋다고 생각한다. 물론 강제할 사항은 아니지만, 원활한 소통과 표준을 위해서 소심하게 권장한다. ^^;

더 중요한 것! 이런 폰트들이 더 많이 개발되고 배포되어 개발자들의 시뻘개진 눈에 안약 같은 존재가 되었으면 하는 소망이 있다. ^^

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18

미완의 스킨과 분위기 전환

2009-09-17T22:56:53+09:00

올초에 포스팅한 "己丑年 새해 벽두부터 대박의 조짐"이란 예감은 아쉽게도 적중하였다. 년초부터 지난 8월, 프로젝트에서 철수하는 순간까지 월화수목금금금의 퍼레이드는 지겹도록 계속되었다. 프로젝트 말미 즈음에는 나를 포함해 다들 여러가지 상황들과 사건들로 스트레스가 극에 달하고 심신은 지칠대로 지쳐 있었다.

그리고 블로깅... 너무 오래 쉬었다. -_-

프로젝트 종료 후 바로 투입된 사이트... 아직은 여유가 좀 있는지라 숨고르기를 하며 한숨 돌리고 있다. 그러다 보니 소홀했던 블로깅에 대한 욕구도 조금씩 살아나고 뭔가 분위기를 전환해서 새롭게 시작하고 싶은 생각이 들었다. 블로그의 분위기 전환에 가장 적합한 작업은? 스킨 교체! ^^

작년에 허접하지만 KS_Simple - Textcube 1.7용 2단 스킨을 직접 만들어서 사용했었는데, 이왕이면 자작한 스킨으로 교체하는 것이 또한 좋지아니할까 싶어 작업을 시작했다.

그 결과.

KS_Autumn이란 이름을 붙여 다소 미완의 상태에서 블로그에 스킨을 입혀보았다. 예상했던 대로 역시나... 허접하다. -_- 분위기를 살리기는 커녕, 아니한만 못하다. OTL 좌절모드... ㅜ.ㅡ
3단으로 구성해보았는데 색감도 그렇고 애초의 생각과는 많이 다른 모습이다. 좀 더 손을 보고 마무리 해야겠다는 의욕과 동시에, 가슴 한켠에 문득 귀차니즘이 발동하였다. 갈등은 오래가지 않았다. 귀차니즘의 압승!

결국.

몇개의 스킨을 다운로드 하여 적용해보던 중, 가장 깔끔해보이는 WhiteBoard 2.0을 선택하였다. 코드를 약간 수정하여 바꾼 것이 현재 블로그의 모습이다.

스킨 작업이 미완으로 끝나는 바람에 조금 아쉽기는 하지만, 산뜻하고 시원시원한 스킨으로 교체하고 나니 나름 분위기 전환엔 성공한 것 같다. ^^

이제 다시 시작이다.

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

KOSA 소프트웨어 기술자신고 시스템

2009-06-10T23:30:56+09:00

요즘 주변에서 한국소프트웨어산업협회(KOSA)와 소프트웨어 기술자 신고제에 대한 얘기가 솔찮게 들린다.

7월 31일 이전까지 등록을 하라는데, 아무리 봐도 헛점이 많은 시스템이라 이슈가 될만하다. 보철이가 알려준 사이트인데 올 초에 "소프트웨어 기술자 신고제 시행에 관한 논의"도 진행되었고 "등록 신고 반대 운동(서명)" 기미도 있었나 보다.

위 사이트에 보면 몇몇 관련 토론 사이트 목록이 보인다. 대충 개발자들의 반응을 엿볼 수 있다.

아래 그림은 올초에 성구가 올린 것을 봤었는데, 다시봐도 얼척이없다. -_-

KOSA 소프트웨어 기술자신고 시스템에 들어가면 제도에 대한 내용을 확인할고 경력을 등록할 수 있다.

그림 출처: Thinkin - 소프트웨어 기술자 (S/W기술자) 신고제

"Scent of Life" 카테고리의 다른 글

신년의 시작은 폭설! (댓글 0개 / 트랙백 0개) 2010/01/04
트위터(twitter)를 시작하다. (댓글 4개 / 트랙백 0개) 2009/12/18
2012, 그럭저럭 볼만하다. (댓글 6개 / 트랙백 0개) 2009/11/23
재미있는 사진을 만들어주는 사이트 (댓글 5개 / 트랙백 0개) 2009/10/16
포토프린터 CANON PIXMA iP4680 (댓글 4개 / 트랙백 0개) 2009/10/07

Internet Explorer 8 (IE8) 의 등장과 웹 표준 고려사항

2009-06-09T10:55:27+09:00

현재 웹어플리케이션을 개발하기 위해 한창 프로젝트를 진행하고 있거나, 기존 웹사이트를 유지보수 하고 있는 개발자들에게 Internet Explorer 8(이하 IE8)의 등장은 부담이 아닐 수 없다.

현재 수행중인 프로젝트의 경우에도 초기에 웹 표준 준수를 목표 잡고 Internet Explorer, Firefox 등 다양한 브라우저와 버전들에서 테스트를 병행하여 개발을 진행해왔다. 그럼에도 불구하고 새롭게 등장한 IE8 버전에서 테스트한 결과, 페이지 레이아웃이 다소 깨지거나 동작에 문제가 발생하는 부분들이 발생하였다. 프로젝트 시작하던 올 초 IE8 출시를 예고되던 시점부터 우려하던 내용이 현실이 되고말았다.

지난주 IE8에서 사이트의 레이아웃이 깨지는 것이 크게 이슈화되었고, 이를 처리하기 위한 방법을 고민하던 중 다행히 간단한 코드를 통하여 전체 페이지의 레이아웃을 바로잡을 수 있었다.

다음은 meta.jspf 의 일부인데, 내가 한 작업이라고는 첫번째 메타(META) 태그를 추가한 것이 전부이다.

<%@ page pageEncoding="utf-8" %> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/> <meta http-equiv="Cache-Control" content="no-store"/> <meta http-equiv="Pragma" content="no-cache"/> <meta http-equiv="Expires" content="0"/> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

아래 IE8에서 테스트한 화면을 보면 Poll 설문조사 부분이 완전히 어긋나 있다.

meta 태그를 적용후 다음과 같이 바로잡혔다.

한가지 더 예를 들면, 다음과 같이 테이블 형태가 깨지던 화면이

정상의 모습으로 돌아왔다.

간단하게 meta 태그를 추가함으로써 대부분의 문제는 바로잡혔지만, 전체 문제가 해결된 것은 아니다. 바로 윗 그림을 보면 검색 버튼의 우측에 우리가 의도하지 않았던 파이프 형태의 라인이 들어간 것이 보인다. 소소한 부분들에 대해서는 확인하고 처리할 수 밖에 없을 것 같다.

개발하는 입장에선 부담이 되지만 IE8은 기존의 IE6, IE7에 비해 월등히 향상된 렌더링 성능을 보여주고 있다고 한다. 실제로 웹서핑을 해보면 체감할 수 있을 수준이다. 그리고 한가지, IE8은 자체에 괜찮은 개발자 툴을 제공하고 있다.

웹표준 적용을 위해 기존 웹사이트에 대한 IE8 브라우저에 대한 호환성을 제공하기 위한 방안 중, 가장 권장되는 수준은 웹어플리케이션을 웹 표준에 맞도록 다시 검증하고 HTML과 CSS, Javascript 등을 수정하는 방법이다. 여건에 따라 이것이 용이하지 않다면 위의 예와 같이 <META> 태그를 이용하는 방안을 권장한다. 단, 전체 페이지가 잘 설계되고 구조화되어 있어야 적용이 쉽다는 것과 <META> 태그가 모든 것을 해결해주지는 않는다는 점을 염두에 두어야 한다.

메타(META) 태그를 적용하는 방법은 두가지이다.

- 페이지 헤더에 메타 태그(X-UA-Compatible)를 추가한다. 이 메타 태그는 여타 태그들 보다 상단에 기술되어야 한다.
- 서비스단의 자바 코드를 사용해 응답 헤더에 덧씌운다.

메타 태그 외에도 몇가지 방법들이 있는데, 내 위키에 간략히 정리한 것을 다시 붙여본다(내용은 마소의 지난 기사 중 "Internet Explorer 8 스페셜 리포트"에서 참고, 인용했음을 밝힌다).

DTD가 없는 웹 사이트 대응 방법

Quirks Mode란 DTD를 표준에 따라 인식하지 못했던 과거의 IE5 브라우저의 렌더링을 그대로 흉내 내는 모드다.

DTD가 있는 웹 사이트 대응 방법

DTD가 있고 IE5에 최적화 된 페이지 대응 방법

DTD가 있고 IE5에 최적화된 웹 페이지는 HTML 소스 코드 <head>…</head> 안쪽에 다음과 같은 코드 한 줄을 포함시키면 된다.

<meta http-equiv="X-UA-Compatible" content="IE=5"/>

IE8은 이 명령을“나는 IE5에 최적화된 페이지 입니다. Quirks Mode로 렌더링 해 주십시오”로 받아들여진다.

DTD가 있고 IE6에 최적화 된 페이지 대응 방법

IE6에 최적화 된 페이지는 IE7에 최적화 작업 후 다음 코드로 대응한다.

<meta http-equiv="X-UA-Compatible" content="IE=7"/>

IE8은 이 명령을“나는 IE7에 최적화된 페이지 입니다. IE7 표준 모드로 렌더링 해 주십시오”라고 받아들인다.

DTD가 혼재되어 있는 웹 사이트 대응법

DTD가 없는 페이지는 IE8이 Quirks Mode로 렌더링 하기 때문에 아무런 대응을 하지 않아도 페이지는 깨지지 않는다. DTD가 있는 페이지에 한하여 IE7에 최적화 시킨 후 다음 코드를 적용 하면 된다.

<meta http-equiv="X-UA-Compatible" content="IE=7"/>

만약 이런 호환 유도 코드를 DTD가 있는 페이지에만 별도로 적용하는 것이 어렵다면 모든 페이지에 호환 유도 코드를 추가하는 방법도 있다. DTD가 있는 페이지만 IE7에 최적화 시킨 후 모든 페이지에 다음 코드를 적용한다.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

DTD가 없는 페이지는 여전히 Quirks Mode로, DTD가 있는 페이지는 IE7 표준 모드로 렌더링 할 것이다. 따라서 DTD가 있는지 없는지 여부에 관계없이 무조건 IE7 표준 모드로 렌더링 하는‘IE=7’보다 DTD가 있고 없음에 따라 자동으로 렌더링 모드를 전환해 주는‘IE=EmulateIE7’코드를 더욱 권장 한다.

호환 유도 코드를 서버측 응답 헤더에 적용하는 방법

모든 페이지에 일일이 호환 유도 코드를 추가하는 것은 아무리 봐도 효율적이라고 생각할 수 없다. 따라서 서버 사이드 개발자는 서버측 응답 헤더에 다음과 같이 적용할 수 있다. 이 코드는 웹 사이트에 전체적으로 호환 유도 코드를 삽입하는 것과 같은 효과를 거둘 수 있다.

* IIS에 적용할 코드

<?xml version="1.0" encoding="utf-8"?> <configuration> <system.webServer> <httpProtocol> <customHeaders> <clear /> <add name="X-UA-Compatible" value="IE=EmulateIE7"/> </customHeaders> </httpProtocol> </system.webServer> </configuration>

* Apache에 적용할 코드

X-UA-Compatible:IE=EmulateIE7

IE8은 DTD가 없거나 표준 DTD가 아닌 페이지를 만났을 때 Quirks Mode로 렌더링 하고, 표준 DTD를 만났을 때 IE7 표준 모드로 렌더링 할 것이다.

웹 표준 사이트와 낡은 브라우저의 호환성 문제

웹 표준 사이트는 IE8에 별도로 대응할 필요가 없다. IE8이 웹 표준을 잘 지원하고 있기 때문이다. 그러나 웹 표준을 잘 지킨 사이트는 낡은 브라우저에서 깨질 것이다. 낡은 브라우저는 웹 표준을 완전히 지원하지 않기 때문이다. 또한, 낡은 브라우저라고 해서 다 같은 브라우저가 아니다. IE7, IE6, IE5 세 가지 버전의 브라우저 엔진은 지원하는 표준의 범위가 다르기 때문에 렌더링도 각각 다르다. 렌더링 엔진이 제각기 다르기 때문에 각각의 버전에 대응하는 CSS 코드도 달라야 한다. CSS 코드를 적용함에 있어 버전 타깃팅 기법이 필요하다. 다행히도 IE는 조건부 주석이라는 또 다른 호환 유도 코드를 제공하고 있다.

<link rel="stylesheet" type="text/css" href="default.css"/> <!?[if IE7]> <link rel="stylesheet" type="text/css" href="ie7.css"/> <[endif]?> <!?[if IE6]> <link rel="stylesheet" type="text/css" href="ie6.css"/> <[endif]?> <!?[if IE5]> <link rel="stylesheet" type="text/css" href="ie5.css"/> <[endif]?>

ie7.css 파일은 IE7 버전에만 작용한다. ie6.css 파일은 IE6 버전에만 작용한다. ie5.css 파일은 IE5 버전에만 작용한다. 나머지 브라우저들은 default.css 파일만 파싱하며 ie7.css, ie6.css, ie5.css 파일에 대한 링크를 주석으로 처리한다.

CSS Hack 활용하기

권장하지는 않지만 CSS Hack을 사용하는 방법도 있다. CSS Hack은 브라우저의 버그를 이용하여 문제를 해결하는 방법이다. 버전별로 CSS 파일을 각각 작성하지 않아도 간편하게 낡은 브라우저에 대응할 수 있지만 CSS 문법 규격에 맞지 않는 것이 흠이다. 앞쪽에 선언된 property:value 값은 표준 계열 브라우저(IE8, 파이어폭스, 오페라, 사파리, 크롬)에서 작용하고 뒤에 선언된 property:value 값은 IE 버전에 대응하며 앞에 선언된 속성과 값을 덮어 쓴다.

IE5 ~ IE7 대응‘*’Hack

#selector { property:value; *property:value; } /* 문서의 DTD와 무관하게 작용함 */

IE5 ~ IE6 대응‘_’Hack

#selector { property:value; _property:value; } /* DTD가 없는 문서는 IE7에도 작용함 */

IE5 대응‘_ & /**/ ’Hack

#selector { property:value; _property /**/:value; } /* DTD가 표준모드인 경우에만 작용함 */

IE5 대응 Hack의 경우 /**/ 주석 앞에 한 칸의 공백이 있음에 유의한다.

참고로 아직도 여전히,

한국의 IE 버전별 점유율(2009년 2월 Internet Trend 보고서 기준)에 따르면 10년 전에 출시된 IE6 브라우저의 점유율이 59.42%로 가장 높고 IE7이 38.81% 대의 점유율을 보이고 있다. 또한 기타 브라우저들의 점유율도 큰 차이를 보인다. 파이어폭스와 사파리, 오페라, 크롬 브라우저의 지구촌 점유율이 통틀어 32.58%나 되는데 비하여 한국에서는 고작 1.4%에 그치고 있다.

고 한다. 파폭을 쓰는 사람은 개발자들이 다인 것 같다.

"Development Story" 카테고리의 다른 글

WYSIWYG Web Editors (댓글 2개 / 트랙백 0개) 2009/12/16
개발자들도 헷갈리는 몇가지 용어들 (댓글 5개 / 트랙백 0개) 2009/10/27
Maven 설치 요약 (Windows) (댓글 2개 / 트랙백 0개) 2009/10/27
프로젝트 후기 (댓글 2개 / 트랙백 0개) 2009/10/05
Programming Fonts - 나눔고딕코딩 글꼴 등 (댓글 7개 / 트랙백 0개) 2009/09/18