Scent of Life

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은 비즈니스 구현부도 포함하기 때문이다.

• 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)를 나타낸다.
• 아키텍처는 더 포괄적인 개념으로 스트럭처와 프레임워크 모두를 포함하는 체계적인 기반 구조를 의미한다.

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

난항의 프로젝트

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

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

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

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

단편적 회고

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

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

Environments

IDE & Tools

Open Source - Framework & Library

라이브러리와 여타 종속성이 있는 라이브러리들을 포함하다 보니, 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)를 공통화하여 개발 편의를 증대하고자 한 것이 결과적으로 득보다는 실을 가져다 준 셈이었다.

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

정리

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

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

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

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

P.S.

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

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

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

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

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

• 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 글꼴에 참고할만한 내용이 있다.

나눔고딕코딩

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

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

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

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

• phpschool 토론
• devpia 토론
• 다음 아고라

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

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

현재 웹어플리케이션을 개발하기 위해 한창 프로젝트를 진행하고 있거나, 기존 웹사이트를 유지보수 하고 있는 개발자들에게 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 설문조사 부분이 완전히 어긋나 있다.

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

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

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

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

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

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

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

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

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

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

X-UA-Compatible:IE=EmulateIE7

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

CSS Hack 활용하기