첫 팀 프로젝트를 시작하며 - 프레임워크, 디자인패턴, 아키텍쳐란?

5월 24일이다

아직 프로젝트명도, 뭘 만들지도, 어떻게 만들지도 정하지 않았다

일단은 사람만 구했다.

이번 프로젝트의 성패는 내가 팀장으로서 중심을 잘 잡고 진행하는데 달려있다.

 

5월 넷째주 회의록

1. 어떤 프로젝트를 만들것인가?

2. 디자이너 영입에 관해, 아는 인맥이 있는지

3. Flutter 로 개발을 진행하는것에 대해 어떻게 생각하는지

4. 각자의 개발 경험에 대하여

 

아마 내가 경험이 가장 많을듯 하니, 프레임워크, 디자인패턴, 아키텍쳐에 대해 공부와 적용하고, 플러그인 관련 버전 맞추는것까지 먼저 해둬야 할듯 싶다. 나도 경험이 많지는 않지만 인턴경험이 없었을때는 정말 아무것도 몰랐었으니까.. 

https://genieker.tistory.com/123

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

1. Framework vs Library

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

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

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

구분Library (Toolkit)Framework

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

 

2. Framework vs Component

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

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

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

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

구분ComponentFramework

성격

컨테이너라고 하는 기반 구조에서 작동하는 컴포넌트 모듈에 초점

어플리케이션 기반 구조에 초점

 

3. Framework vs Design Pattern

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

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

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

구분Design PatternFramework

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

 

4. Framework와 Architecture

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

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

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

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

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

구분ArchitectureFramework

성격

하나 이상의 프레임워크로 구성

어플리케이션의 구조를 결정

Structure? Architecture? Framework?

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

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

Framework = Design Pattern + Library
Architecture = Structure + Framework

 

일단은 이부분만 알아도 될것같다.