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

---

 출처: http://genieker.tistory.com/123

---

Framework와 Library, Component, Design Pattern, Architecture 의 차이를 잘 설명한 사이트(링크)

1. 프레임워크 vs 라이브러리

2. 프레임워크 vs 컴포넌트

3. 프레임워크 vs 디자인패턴

4. 프레임워크 vs 아키텍쳐

아래부터 퍼온글로 현재(16.02.29) 페이지가 죽어있어서.. Internet Archive에서 검색해서 살려봤습니다.

문제되면 비공개처리 하겠습니다.

-----------------------------------------------------------------------------------------------------------

 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)이라고 한다. 클래스 라이브러리는 범용적으로 사용할 수 있는 기능을 제공하는 재사용할만한 연관된 클래스들의 묶음이다. 클래스 라이브러리와 프레임워크간의 가장 큰 차이는 제어 권한의 위치에 있다.

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

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

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