Continue reading »]]> 머릿속에서는 계속해서 강력한 이성을 요구하고 있었지만,
몸은 이미 너울대는 감정의 물살에 휘말려 걷잡을 수가 없었다.

마치 극심한 열병을 앓고 난 것 같다.

착각은 강력한 동기부여가 된다고 한다. 나에게 최면을 걸어본다.
나는 행복하다. 나는 만족한다. 나는 잘 할 수 있다.

아마도 세상을 살아가는 가장 현명한 방법은 바로 자기를 버리는 것이 아닐까 싶다.
자신을 사랑하는 만큼 더더욱 내면의 울림은 무시해버리는 것이 좋을지도 모른다.

실행할 수 없는 용기의 대안은 고작 회피인가?
다양성을 이해하기엔 아직 내 그릇이 너무도 작다.

대부분의 사람들이 그러하듯이,
대부분의 사람들처럼 살아가게 되지 않기를 바래왔지만,
결국 대부분의 사람들과 마찬가지로,
어제도 오늘도 세상과 타협하며 살아가고 있다.

그리고 내일도.

※ 이미지 출처: Galileo Galilei

Continue reading »]]>

보유하고 있던 도메인들과 웹호스팅 서비스의 만료일 앞두고 웹호스팅 업체 변경을 단행하였다.

유사한 조건의 타 업체 서비스에 비해 가격대비 품질이 떨어지는 것이 첫번째 이유이다. 그리고 PHP 5, MySQL 5 버전에 대한 환경을 제공하지 않고 앞으로도 제공할 계획이 없다는 것, 텔렛 접속을 위해 매번 요청을 해야하는 번거로움 등이 그나마 남아 있던 정을 가시게 만들었다.

어플리케이션의 시스템 요건은 한단계 업그레이드되었는데, 몇년째 기존 환경을 고수하고 트랜드에 무감각한 반응이다. 물론 항상 최신을 유지하기 어렵고 또한 특정 어플을 위해 시스템을 세팅할 수는 없다는 것을 잘 안다. 그래도 최소한 한 두 대의 서버는 상위 버전을 도입할 수도 있지않을까? 당췌, 향후 업그레이드 계획 조차 없다는 말이 너무 무성의하게 와닿았다.

또, 작년 말부터 올해들어 사이트가 죽거나 속도가 현저하게 떨어지는 케이스도 빈번하게 발생하였다. 고객 대응의 질도 갈 수록 맘에 들지 않아 더이상 굳이 비싼 돈 내면서 연장하고 싶지 않았다. 해서 수년간 사용하던 업체를 버리고 타 업체로 이전하게 되었다.

내게 필요한 웹호스팅 스펙을 필수와 옵션으로 구분하고 그것에 맞추어 구력이 짧지않고 인지도가 높은 업체들을 위주로 비교표를 작성해 보았다. 동일 업체 내에서도 상품이 다양하기 때문에 년간 비용이 2만원에서 5만원 사이에서 추렸다. 사실 수년전에도 비슷한 작업을 했지만 요금은 약간 비싸도 돈값은 하지 않을까 싶어 안정성을 념두에 두고 선택한 것이 기존 업체였다. 싼게 비지떡이라는 생각을 버렸다. 사실 현재 내 블로그는 수기가 대의 트래픽 대역폭을 필요로 하진 않는다. ^^

뭐든 사용기를 보면 100% 만족하는 사용자들은 별로 없다. 안티는 있기 마련이다. 대체적인 평들을 종합하여 업체와 상품을 선택하였다. 년 2만원 대 상품이지만 1주 정도 사용해본 현재로선 만족하고 있다. 아직 평가는 이르다.

업체 홍보라는 오해를 살까 싶어 선택한 업체를 밝히진 않겠지만 비교표의 주요 후보군 정도는 괜찮을 듯 싶다.

• 나야냐, 마루웹호스팅, 미리내닷컴, 비누넷, 이로긴, 카페24, 팀장닷컴, 팔공포트, 호스트먼트, J4F

※ 가나다 순, 링크는 생략.

웹호스팅을 이전하면서 사용하던 서비스 엔진들을 다음과 같이 업그레이드 하였다.

• BLOG: Textcube 1.8.3.1(Secondary Dominant)
  
• WIKI: dokuwiki 2009-12-25c(Lemming)
  
• CMS: XpressEngine(XE) Core 1.4.2.2

※ XE를 내멋대로 CMS(Content Management System)로 분류했는데, 적절한지는 모르겠다.

블로그는 백업을 복구하면서 기존의 스킨을 버리고 오픈 소스 디자인을 참고해 나름대로 수정한 것을 적용하였다. 아직 몇몇 부분이 미비해 조금 더 손을 봐야 한다. 그래도 시간을 투자해 내손으로 만든 스킨이 정이 간다. 처음 만들었던 스킨(KS_Simple)과 미완의 스킨을 포함한다면 이번이 세번째 스킨이 된다.


플러그인도 몇가지 추가하고 구글맵(Google Map)도 달았다. 좋다. ^^

정말 오래간만에 올려보는 포스트! ^^
이사도 하고 새옷도 입었으니, 이젠 내실을 다져야겠다! <- 항상 말만.

Continue reading »]]>

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

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

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

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


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


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

Continue reading »]]> 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에 작성했던 표를 캡쳐하여 붙인다.

참고 사이트

• TTW (“Through the Web”) WYSIWYG Web Editors – The List
• 다양한 WYSIWYG 에디터
• 위지윅 웹 에디터 비교
• FCKEditor
• TinyMCE
• Xinha
• Daum Open Editor
• SmartEditor

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


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

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

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

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

Continue reading »]]>

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

Continue reading »]]> 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 관련 참고 사이트

• http://martinfowler.com/eaaCatalog/dataTransferObject.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
• http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

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

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

Framework와 관련 용어

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

1. Framework vs Library

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

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

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

2. Framework vs Component

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

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

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

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

3. Framework vs Design Pattern

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

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

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

4. Framework와 Architecture

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

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

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

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

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

Structure? Architecture? Framework?

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

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