패턴으로 가는 길 (Road to Pattern)
“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.
패턴은 올바른 아키텍팅을 위한 전술 (Tactics).
2007년 10월 “Software Architecture in Practice”의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였다. 세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는 질문을 했고 그에 대한 대답으로 아키텍트가 가져야 하는 덕목 중 전술로써의 패턴의 가치를 설명했다.
“전술이란, 전략에 비해 단기적인 의미를 가지는 것으로 소프트웨어의 큰 구성요소들을 나누고, 구성 요소 내에서 어떻게 구현, 실행해 나갈지 계획을 세워나가는 것을 의미합니다. 이러한 전술을 많이 알고 있어야, 내실이 튼튼한 소프트웨어가 나올 수 있죠. 전술을 많이 알기 위해서는 경험 못지않게, 간접 경험 즉 패턴을 익히는 것도 중요합니다.”
간략히 패턴에서 전술의 예를 든다면 분산 객체의 마샬링(marshaling) 정책을 들 수가 있다. Loosely Coupling하게 마샬링하기 위해 Protocol 기반의 설계를 사용함으로써 확정성이나 관리의 용이성을 획득하지만, 응답 속도나 처리량을 포기해야 된다. 반면에 Tightly Coupling하게 마샬링하기 위해서는 Simple Object를 만들어서 사용하는 방법이 있는데, System에 종속적이고 변화에 유연하지 못한 단점이 있는 반면 위 방법에 비해 응답속도나 처리량이 더 뛰어나다. 흔히 Web Service(전자인 경우 – SOAP에 의한 Protocol 전송 방식)과 COM+ (후자인 경우 – Simple Object) 의 데이터를 주고 받는 경우라고 할 수 있다. 만약 여러분이 패턴을 통해 이러한 전략을 습득하고 있다면, 아키텍팅을 수립하는데 겪는 많은 시행 착오를 줄일 수 있을 것이다.
패턴의 시작은 GoF부터?
GoF 책이 명서이며, 패턴계에 큰 영향을 끼친 서적임은 틀림없다. 하지만 독자 여러분이 처음 패턴을 접한다면 GoF의 Design Pattern이라는 서적은 난해할 수도 있다. 필자는 GoF 책이 처음 패턴을 접하기에는 난해하다고 말하는 개발자를 보았다. 필자 역시 GoF 책을 이해하기 위해서 3번을 읽었고 읽을 때마다 새로운 느낌을 주는 서적이었다. 마치 성경을 읽는 느낌이라고 할까? 그 만큼 깊이가 있는 책이다.
GoF 책은 1990년대 후반부에 쓰여있다 보니, 1990년 중반부에 사용되는 Application을 예로 들어 설명하였고, C++ 의 이해를 수반으로 하고 있기 때문에 현재 우리가 관심을 가지고 있는 Application과는 약간 범위가 다르고, Java나 C#에 익숙한 초보 개발자에게는 난해할 수 있다. 그래서 2000년대에 이슈인 Database 프로그래밍과 같이 누구나 쉽게 이해할 수 있는 수준으로 설명한 책이 Design Pattern Explained 였고 국내에서는 “알기 쉬운 디자인 패턴” 이라고 번역이 되어있다. 불과 4년 전 만해도 초보자를 위한 디자인 패턴 책은 이것 밖에 없었다. 하지만 현재는 뇌 공학을 연계로 해서 쉽게 개념을 파악할 수 있는 좋은 서적이 나왔다. 바로 한빛미디어에서 출간한 “Head First Design Patterns” 이다. 국내 패턴 서적에서는 계속 1위를 고수하고 있으므로 보길 권한다. 하지만 현란한 사진으로 집중이 되지 않는다며 고충을 토론하는 분도 있다. 그런 분들은 피어슨 에듀케이션 코리아의 “알기 쉬운 디자인 패턴”을 읽길 권한다.
다음 단계 서적으로는, 구체적으로 하나의 언어를 정해서 언어별 특성을 파악하며 패턴을 살펴볼 필요가 있다. 여러분이 Java에 관심이 많다면 “Java 언어로 배우는 디자인 패턴 입문” 을 추천 드리며, C++에 관심 있는 개발자라면 장세찬씨의 “GoF 디자인 패턴! 이렇게 활용한다.”를 보시길 권한다. 그 다음 GoF 서적을 보시면 한결 수월하게 읽을 수 있을 것이다.
GoF 패턴을 충분히 이해했지만, 여러분에 프로그래밍에 바로 적용하시는 분은 매우 많지 않을 것이다. 왜 일까? GoF 패턴은 패턴의 가장 기본이 되는 Micro Pattern일 뿐이다. GoF는 단지 패턴의 시작일 뿐이다.
패턴은 섬이 아니다. 같이 가족을 이루는 패턴 군을 파악해라!
GoF 패턴을 읽은 다음 POSA 시리즈로 불리는 서적들이 있다. GoF와 어깨를 나란히 하는 패턴 계의 명서 중에 명서이며, GoF를 읽은 분이라면 패턴에 좀더 깊은 세계를 맛보기 위한 좋은 서적이다. GoF(1995년)가 나온 1년 뒤에 볼륨 1권이 출간(1996년)되었지만, 국내에는 2008년도에 역서가 나왔기 때문에 패턴 초보자들에게는 그리 알려져 있지 않은 서적이라고 할 수 있다. GoF가 가벼운 Micro Pattern 이었다면, POSA는 좀더 세부적인 도메인을 다루고 있다.
- Vol 1: Architectural Pattern (소프트웨어 구조를 잘 설계하기 위한 패턴)
- Vol 2: Concurrent and Networked Object Pattern (분산객체를 위한 패턴)
- Vol 3: Resource Management Pattern (자원을 잘 관리하기 위한 패턴)
이 책을 탐독하면 자연스럽게 패턴 군 (Compound Pattern)들이 눈에 보이게 된다. (물론 GoF 패턴이 밑단에 전체적으로 깔려 있다.) 즉 패턴 하나가 혼자 쓰이지 않고 같이 잘 엮어서 사용되는 패턴들이 보이기 시작할 것이다. 바로 이러한 패턴 군을 많이 습득하는 것이 패턴을 습득하는 올바른 방법이다.
소프트웨어 기본 구조에서 볼 수 있는 간략한 사례를 들어 패턴 군을 설명하고자 한다.
그림 1. 소프트웨어 구성부로 보는 Compound Pattern
소프트웨어는 그림 1처럼 크게 3가지 요소로 구성된다. 공용부, 가변부, 설정부이다.
공용부는 소프트웨어의 많은 Feature에서 공통적으로 사용하는 부분으로, log, transaction, security와 같은 모듈을 말하며, 요즘 Aspect와 같은 기술들로 구성하는 것이 추세다. 우리가 눈 여겨 보아야 할 것은 설정부와 가변부이다. 그럼 하나 하나씩 살펴보도록 하자.
Component Configurator Pattern
아키텍처 패턴(Architectural Pattern)을 다룬 『POSA1』 서적을 통해 알려진 패턴으로, 런타임 시 사용하는 컴포넌트들을 제어하고, 시스템을 중지 없이 컴포넌트를 추가, 제거, 교체할 수 있는 패턴이다.
그림 2. Component Configurator
<리스트 1> Component Configurator 설정 파일
<xml version ="1.0"> <Components> <!– Protocol 정보 선택 --> <Protocol> HTTP </Protocol> <!– Log 정보 선택 --> <Log> XML </Log> <!– 보안 알고리즘 선택 --> <SecuAlgorithm> DES </SecuAltorithm> </Components>
<리스트 2> Component Configurator를 적용한 샘플 코드
static void main()
{
Message message = new Message();
if (GetComponentInfo("Protocol") == HTTP)
{
message.Protocol = HTTP;
}
else
{
message.Protocol = FTP;
}
if (GetComponentInfo("Log") == XML)
{
message.Log = XML;
}
else
{
message.Log = TEXT;
}
message.Send("Hello");
}
<리스트 1>과 <리스트 2>는 Component Configurator 패턴의 간단한 샘플이다. 설정 파일(<리스트 1>)의 Protocol이 HTTP면 그 정보를 읽어 HTTP 프로토콜로 메시지를 전송하고 FTP 프로토콜로 설정되어 있다면 FTP 프로토콜로 메시지를 전송할 수 있다. 이렇게 함으로써 런타임 시에 객체의 속성을 정의함으로써 변화에 유연하게 대처할 수 있다.
하지만. 새로운 프로토콜이나 로깅 정책이 추가되어야 한다면 <리스트 2>의 소스코드도 변경될 수밖에 없다. 이러한 문제를 해결하기 위해 Component Configurator 패턴은 Reflection 패턴과 병행해서 사용해야 한다. Reflection은 Runtime시에 객체를 생성하는 패턴으로, 이미 .NET 과 Java 플랫폼에서 지원하고 있다. 여기서 Component Configuration 통해 객체 정보를 읽어와 생성하는 Factory를 만들면, 객체를 생성하는 클라이언트 입장에는 별 걱정 없이 객체를 생성할 수 있다.
Template Method Pattern
그림 3. Template Method
<리스트 3. Template Method 패턴의 예>
class QueryTemplate
{ public void doQuery()
{
string dbCommand;
dbCommand = FormatConnect();
dbCommand = FormantSelect(sql);
} ...
}
void main()
{ //pQT라는 인터페이스를 선언한다
QueryTemplate *pQT;
Sql sql = "select * from AA";
if (GetDBProductInfo() = Oracle)
pQT = new OracleQT();
else
pQT = new SqlSvrQT();
pQt.doQuery(sql);
}
Template Method 패턴의 가장 대표적인 예가 xDBC(ODBC, JDBC)이다. 댜양한 제품의 DB에 상관없이 xDBC에 동작하는 쿼리만 알면 언제든지 DB 제품을 쉽게 교체해서 쓸 수 있다. Template Method패턴은 다른 패턴이 가지고 있지 않는 전체적인 흐름을 제어하는 Template Method (위 예에서는 doQuery)를 가지고 있는데, 리스트 3의 doQuery를 보면 DB에 연결을 맺고 쿼리를 얻어오는 흐름이 슈퍼 클래스(superclass)에 있는 것을 볼 수 있다. 서브 클래스(subclass)들은 슈퍼클래스의 계약에 따라 움직여야 하는 강력한 제약상황에 놓여 있게 된다. 이로서 DB 제품을 별 걱정 없이 교체할 수 있는 큰 장점을 얻을 수 있다. 특히 Framework들은 일괄적인 제어 흐름과 상황에 맞게 서브클래스를 교체하기 위해, 필수적으로 Template Method를 사용한다.
자 그림 1을 다시 한번 보도록 하자. 이제 전체적인 그림이 이해가 갈 것이다. 설정부에 객체의 속성을 Component Configurator를 통해 정의해 놓는다. 그 후 객체가 생성되는 시점에서 Factory가 현재의 상황을 고려해 적합한 객체를 선택한 후, 메모리에 로딩한다. 단 가변부에 있는 객체는 쉽게 교체가 가능해야 하므로, Template Method나 Strategy와 같이 동일한 계약 상황(인터페이스를 구현 하거나 Abstract를 상속하는 형태)을 유지해야 된다.
눈치 있는 독자는 이 구조를 어디서 많이 보았다고 생각할 것이다. 바로 Spring과 같은 Dependency Injection Container를 설명한 것이다. 좀더 자세한 설명을 듣고 싶은 분은 필자의 블로그(종속성을 관리하는 방법 – https://arload.wordpress.com/2008/12/07/dependency_managment/)를 방문하길 바란다.
아키텍팅의 핵심 SoC 그리고 문제 중심으로 바라보기
소프트웨어 공학에 관심이 있는 분이라면, 누구나 걱정거리의 분리, 관심거리의 분리라고 말하는 SoC를 들어본 적이 있을 것이다. 필자는 얼마 전 SoC와 복잡성에 대해 논쟁을 주고 받은 적이 있다. 필자는 이 논쟁을 통해 SoC와 소프트웨어 아키텍팅의 가치/패턴의 연관성에 대해서 다시 생각할 수 있는 좋은 기회였다.
SoC라는 단어를 세상에 처음 발표한 Edsger W. Dijkstra의 정의는 다음과 같다.
“focusing one’s attention upon some aspect”
여러 가지를 측면들을 동시에 생각하기는 힘드니, 잘 나누어 각각의 요소에 한가지 관점만을 바라보겠다는 것이다. 흔히 분할 후 정복 (Divide and Conquer)과 일맥상통하는 말이라고 할 수 있다. 다양한 이해 당사자의 요구, 프로젝트의 특수한 상황, 잘못 설계된 아키텍처로 인해, 하나가 바뀌면 연쇄적으로 다른 곳에 변화가 발생하는 파문 효과(Ripple Effect)를 종종 만나게 된다. 이때 우리가 특히 중점을 두어 관리해야 하는 것이 종속성 (Dependency인데, 이러한 종속성이 유발 시키는 강 결합을 무너뜨리는 좋은 가이드라인을 제시하는 것이 바로 패턴이다. SoC를 얼마나 잘하느냐가 아키텍팅의 성공과 실패를 결정하므로, 패턴 기반의 좋은 참조 아키텍쳐 (Reference Architecture), 특히 패턴 기반으로 구축된 시스템을 패턴 시스템들을 평소에 틈틈이 공부할 필요가 있다. 그 이유는 패턴은 군을 이루어 사용되기 때문이다. 특히 도메인에 한정될수록, 사용되는 패턴 군들은 더 제한적이다.
갑자기 여러분의 상사가, 모든 환경에서도 좋은 성능을 보이는 웹 서버를 설계(SoC)하라고 한다면 어떻게 해야 될까? 먼저 비슷한 선례, 즉 참조할만한 아키텍쳐가 있는지 찾아볼 것이다.
그림 4. 환경에 맞게 전략을 바꾸는 JAWS 웹서버
유명한 TAO/ACE의 창시자인 Douglas C. Schmidt 박사는 이에 대한 대답으로 주고 받는 파일이 사이즈, 클라이언트의 다양한 요청 속성 (예를 든다면 요청 빈도, 요청 시 얼마나 오랫동안 세션을 맺고 있는지 등), 고객의 웹사이트 접근 경로 등을 고려하여 환경에 맞게 적절한 전략을 변경할 수 있는 웹 서버 JAWS의 소스코드와 아키텍쳐 공유했다. (필자가 한 JAWS 아키텍쳐 동영상 강의- http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=11를 참조하길 바란다.)
이렇게, 괜찮은 참조 아키텍쳐를 발견했다고 하더라도, 왜 이렇게 아키텍쳐가 구축되었는지에 대한 문제 상황에 깊은 이해를 필요로 한다. 어떤 부분에는 유연성을 중심으로 설계했고, 또 다른 부분은 유연성 보다는 성능을 중심적으로 설계를 했네. 왜 이렇게 결정 했을까? 결국 이렇게 구축한 시스템의 의도를 잘 파악하기 위해서는, 패턴을 하나의 해결책으로 바라보는 것보다, 패턴의 의도와 다루는 문제들을 중심적으로 바라볼 필요가 있다. 특히 아키텍쳐가 거대해 질수록 이러한 접근법은 더 효율적이다.
좋은 패턴 서적들을 소개하기.
현재 발표된 다양한 패턴 서적들을 소개하여, 여러분의 프로젝트나 관심분야 서적들을 읽어보길 바란다.
PLoPD 시리즈
매년마다 다양한 곳에서 여러 종류의 PLoP라는 유명한 패턴 학회가 열린다. 그야 말로 패턴의 보고이며, 시중에 나온 새로운 도메인의 패턴 서적들은 거의 다 이 학회를 한번 거쳤다고 해도 과언이 아닐 정도로 영향력 있는 학회이다. 다양한 도메인을 폭 넓게 다루고 있을 뿐만 아니라, 소프트웨어 계의 거장들을 만날 수 있는 좋은 학회이다. 이 학회에서 발표된 패턴 중에 괜찮은 패턴들을 묶어 PLoPD (Program Language of Program Design) 라는 서적으로 출간되는데 바로 PLoPD 이다. .
POAD (Pattern Oriented Analysis Design)
그야 말로 Pattern Drvien Design이라고 불러도 좋을 만큼, 패턴을 활용해 분석및 적합한 전략/전술을 선택하는 가이드라인을 제공하는 서적이다. 아마존에서는 별 5개이지만, 국내에서는 잘 소개되지 않는 서적이다.. 거기다 폭발적인 인기로 절판까지 되었다. 많은 분에게 도움이 되는 서적이다. 학교 도서관이나 주위에 있는 분이 가지고 있다면 꼭 읽어 보길 권한다.
Holub on Patterns (실전 코드로 배우는 실용주의 디자인 패턴)
응용 프로그램 2개를 기반으로 GoF 패턴 23개를 다 다루고 있는 서적이다. GoF 패턴의 가치를 느낄 수 있는 서적이며, 특히 패턴 군,Compound Pattern,들에 대한 좋은 시선을 제공하는 서적이다. 거기다 패턴을 만드는 5원칙을 역자가 직접 추가해서 넣어주었기 때문에 패턴을 학습한 분에게도 좋은 서적이다. 거기다 역자와 감수자가 국내에서 오랫동안 패턴 시스템을 설파한 분이니 꼭 읽어보길 권해드린다.
Remoting Patterns
POSA2가 Open Source CORBA인 TAO, ACE에 사용된 패턴을 소개한다면, 조금 더 최신 기술인 .NET Remoting, EJB, Web Service, CORBA 에 사용된 분산 패턴들을 소개하는 책이다. 겉보기에는 POSA2와 다른 패턴을 소개하고 있는 것 같지만 다시 한번 되짚어보면 POSA2에 소개된 패턴과는 내부 맥락이 같다. 이 서적을 통해서 최신 분산 기술에 정리된 내용을 체계적으로 정리할 수 있어서 무척 도움이 될 것이며, 다양한 분산 객체들의 아키텍쳐를 비교, 평가할 수 있는 좋은 서적이다.
xUnit Test Patterns
TDD가 이슈가 되면서 Testing에 대한 관심이 요즘 매우 급증한 상태다. VS.NET 과 Eclipse 역시 이러한 흐름이 발 맞춰 다양한 Testing 관련 기능을 제공하고 있다. 그 중 여러분이 가장 자주 사용하시는 것이 xUnit (JUnit, NUnit, CUnit…) 일 것다. 이 책은 Unit Testing을 하기 위해서 어떻게 Testing Code를 작성하고 Refactoring하는지 정수를 보여주는 서적이다. 막대한 분량으로 인해 많은 분이 좌절하지만, 꼭 도움이 될 서적이다.
Patterns For Fault Tolerant Software (내(耐)고장성 소프트웨어를 위한 패턴)
Quality 검증의 TDD 와 방어적인 프로그래밍을 넘어서, 내부적인 고장에도 스스로 복구 및 조치를 취할 수 있는 신뢰성 있는 소프트웨어를 개발하기 위해 지침이 되는 서적이다. Error Handling, Mitigation, Fault를 Detection하는 다양한 패턴들을 소개된다.
PEAA (Patterns for Enterprise Application Architecture)
Refactoring의 창시자인 Martin Fowler가 쓴 책으로, 출판 당시 굉장한 센세이션을 일으킨 서적이다. Enterprise Application을 설계하기 위한 다양한 패턴이 소개되어 있다. 물론 POSA나 PLOP에 나온 패턴을 현대적으로 바뀐 것이 대부분이지만, Martin Fowler의 과거의 기술, 용어, 개념들을 현대에 맞게 변형, 확장하는 능력을 다시 한번 느낄 수 있는 서적이다. SI를 하시는 분이라면 역서라도 꼭 읽어보길 권한다.
Enterprise Integration Patterns
EAI를 위한 Messaging 처리에 중점을 둔 서적이다. 어떻게 Messaging 시스템을 만드는지 자세히 설명이 되어 있고, BPM/EAI/Enterprise SOA에 관심이 있는 분이라면 읽어볼 필요가 있다.
Real-Time Design Patterns
Real-Time 시스템을 구축할 때 가장 고려해야 할 것이 예측 성이다. 우선 순위를 고려하고 주어진 Deadline안에 Job이 Schedulable 하냐를 판단하는 것이 가장 핵심이다. 만약 현재의 요청한 Job이 제한 시간 안에 답변을 줄 수 없을 것 같다면, 차선책을 선택하는 형태로 설계되어야 할 것이다. 이러한 우선순위와 스케줄링에 싸우고 있는 개발자라면 도움이 될 서적이다.
Refactoring to Patterns
Pattern을 활용하여 Refactoring을 하는 방법을 소개하는 서적이다. Martin Fowler의 Refactoring 읽으신 분이라면 그 다음 이 서적을 읽어 보길 권한다. “패턴을 활용한 리펙토링” 이라는 제목으로 역서가 출간되었습니다.
Architecting Enterprise Solutions
고성능과 인터넷 기반의 시스템을 구축할 때 사용하기 유용한 패턴 서적으로, 실제 실무에 Infra를 구축하시는 개발자에게는 좋은 동반자가 되는 서적입니다. 시스템을 제어, 성능 측정, 적절한 서버 수 산정과 같은 유용한 가이드라인이 제공되는 서적이다.
끝나지 않은 패턴 이야기!
아직 지구상에서는 무수한 패턴들이 계속 발표되고 있습니다. 그 중 가장 여러분에게 소개 시키고 드리고 싶은 것은 매년 열리는 PLOP 학회에서 발표된 논문이다.
- PLoP (미국에서 열리는 기반 학회) – https://arload.wordpress.com/2008/04/02/plopfestival/
- EuroPLoP (유럽에서 열리는 패턴학회 자료) – https://arload.wordpress.com/2008/08/11/euro_plop_paper/
관심 있는 분은 지난 10년간 발표된 무수한 패턴들을, 끊임없이 학습하시길 권해드리며, 글을 맺습니다. 그 이외에도 다양한 패턴 학회가 존재하지만, 언어의 제약이나 자료를 찾기 어려워 적지는 않았지만 참고하길 바란다.
- ChiliPLoP (Hot Topic을 위주로 다루는 패턴 학회)
- KoalaPLoP (오스트렐리아인을 위한 패턴 학회)
- MensorePLoP (일본에서 열리는 패턴 학회)
- SugarLoafPLoP (라틴 아메리카인들을 위한 패턴 학회)
- VikingPLoP (북 유럽 사람들을 위한 패턴 학회)
참고 자료
Rick Kazman, 소프트웨어 아키텍쳐 이론과 실제, 에어콘 출판사
Rick Kazman, 아키텍트가 되기 위해 갖추어야 할 덕목
- https://arload.wordpress.com/2008/06/13/rickkazman/
- http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=11
Edsger W. Dijkstra, “On the role of scientific thought”
손영수, 미워도 다시 보는 패턴 이야기, 마이크로 소프트웨어 2007년 8월호
Architecture 101 
안녕하세요 여러분 🙂
컴백했습니다. 🙂 이제 좋은 글로 찾아 뵙죠 🙂
마소 5월호에 기고한 내용입니다.
어서오시죠~.
기다렸습니다! ㅋ.
부족한 사람인지만, 기다려 주셨다니 송구하네요 .. 🙂
도움이 될수 있도록 더욱 노력하겠습니다. 감사합니다. 꾸벅~~~
추카추카~~~ 컴백홈~~~
사실 읽고는 싶은데 너무 두꺼워서 기피하게 되는
Enterprise Integration Patterns책에 대해 검색하는데
영수형 블러그로 ㅋㅋㅋ 와버렸네
와서 글 잘 보고 갑니다.
더 많은 대화는 구글 쳇으로 ㅋㅋ 화이팅~~!!!!
번역 홧팅!!!
아 영수형 이 글 좀 퍼가겠 사옵니다 꾸벅~~~