이 분은 Object Mentor 의 리더이자,  Clean Code의 저자인 Bob 삼촌 (Uncle Bob – Robert C. Martin) 의 글이 “모든 프로그래머가 알아야할 97가지” 에 실려 있습니다.

저도 사실 뭔가 재미난 이야기를 해 줄거라고 했는데… 저희에게 너무나도 익숙한 객체지향의 중요한 원칙인   SOLID 의 S인 SRP를 이야기를 하셨네요.

익숙하지만 정말 중요한 원칙인 SRP 이야기를 다시 한번 들어보시길 바랍니다.

Single Responsibility Principle written by Uncle Bob

좋은 설계를 위한 가장 기본적인 원칙 중 하나는 다음과 같습니다.

동일한 이유로 변경되는 것들은 함께 모으고, 서로 다른 이유로 변경되는 것들은 분리시킨다.

이 원칙은 종종 단일 책임의 원칙(Single Responsibility Principle, SRP)이라고도 알려져 있습니다.   한마디로 말해서, 하나의 서브시스템, 모듈, 클래스, 또는 심지어 함수에 대해서도 한 가지 이상의 변경 이유가 있어서는 안 된다는 것을 의미합니다.

이를 설명하기 위한 전형적인 예제로, 비즈니스 룰, 결과 보고서 작성, 데이터베이스 연산을 다루는 메소드들을 함께 가진 클래스를 들 수 있습니다.

public class Employee
{
public Money calculatePay () …
public String reportHours () …
public void save() …
}

• calculatePay 함수는 급료를 계산하는 비즈니스 룰이 바뀔 때 매번 변경되어야 합니다.
• reportHours 함수는 누군가가 기존과 다른 보고서 포맷을 원할 때, 그리고
• save 함수는 데이터베이스 관리자가 데이터베이스 스키마를 바꿀 때마다 변경되어야 합니다.

이렇듯 세 가지 변경 원인이 있다는 사실은 Employee 클래스를 불안정하게 만드는데, 이는 세 가지 원인 중 한 가지만 발생하여도 클래스가 바뀌어야 하기 때문입니다. 더 중요한 것은, Employee 에 의존하고 있는 클래스들 역시 이 변경으로 영향을 받을 수 있다는 것입니다.

좋은 시스템 설계는 시스템을 독립적으로 배포될 수 있는 컴포넌트들로 분할하는 것입니다. 독립적 배포란 우리가 특정 컴포넌트를 변경하더라도 그 외 다른 컴포넌트들은 재 배포될 필요가 없다는 것을 의미합니다. 그러나 위 예제의 경우, 타 컴포넌트들에 있는 다수의 클래스에서 Employee 를 사용하고 있다면, Employee 가 변경될 때마다 그 컴포넌트들 또한 재 배포 되어야 합니다. 결국 이는 컴포넌트 기반 설계(혹은 서비스 지향 아키텍처 설계)의 주요 이점을 잃게 되는 결과를 초래하게 됩니다. 다음 코드는 간단하게 클래스 분할을 통해 이 이슈를 해결하였습니다.

public class Employee
{
public Money calculatePay() ...
}

public class EmployeeReporter
{
public String reportHours(Employee e) ...
}

public class EmployeeRepository
{
public void save(Employee e) ...
}

분리된 클래스들은 각각 자신의 컴포넌트에 위치할 수 있게 됩니다. 좀 더 정확히 말하면, 결과 보고를 담당하는 모든 클래스는 ‘보고’ 컴포넌트로, 데이터베이스와 관련된 모든 클래스는 ‘저장소’ 컴포넌트로, 그리고 모든 비즈니스 룰에 대한 클래스는 ‘비즈니스 룰’ 컴포넌트로 들어갈 수 있게 됩니다. 재빠른 독자라면 위의 해결책에도 여전히 의존관계가 존재한다는 것을 알 수 있을 겁니다.

Employee 는 여전히 다른 클래스들에 의해 참조되고 있기 때문에, Employee 가 수정되면 다른 클래스들도 재 컴파일되고 재 배포 되어야 할 것입니다. 따라서 우리는 Employee 를 수정하여 독립적으로 재 배포 할 수는 없습니다. 그러나 그 외 다른 클래스들은 수정 및 독립적인 재 배포가 가능해집니다. 그들 중 어떤 클래스가 변경되더라도, 그 외 다른 클래스들을 재 컴파일 하고 재 배포할 필요가 없게 되는 것이지요. 만약 우리가 의존관계 역전의 법칙(Dependency Inversion Principle, DIP)을 잘 사용한다면, Employee 역시 독립적으로 재 배포가 가능해 질 것입니다. 의존 관계 역전의 법칙은 다른 책*의 주제이므로 여기에서 다루지는 않겠습니다.

서로 다른 이유로 변경되는 것들을 잘 분리해야 한다는 단일 책임의 원칙을 잘 적용하는 것이 독립적으로 배포가 가능한 컴포넌트 구성을 만들 수 있는 중요한 비결 중 하나라는 것을 기억하시기 바랍니다.

*Agile Software Development, Principle, Patterns and Practices.  http://www.amazon.com/dp/0135974445/

특히 많은 사용자들을 위한 경우, API 설계는 어렵습니다. 만약 여러분이 수 백에서 수 천의 사용자들이 사용할  API 를 설계한다면, 미래에 이것이 얼마나 바뀔 것인지, 그리고 변경 사항이 클라이언트 코드를 손상시킬 수 있는지 여부를 고려해야 합니다. 그 이상으로, 여러분은 API 사용자가 여러분에게 어떻게 영향을 미칠지 생각해야 합니다.

만약에 여러분의 API 클래스 중 하나가 내부적으로 자신의 함수들 중에 하나를 사용한다면, 사용자가 여러분의 클래스의 서브클래스를 만들고 오버라이드override 할 수 있으며, 그리고 그것은 재앙이 될 수 있다는 것을 꼭 명심해야 합니다. 몇몇 사용자들이 그 메소드를 서로 다른 의미로 받아들였기 때문에 여러분은 그것을 바꿀 수 없을지도 모릅니다. 메소드 내부 구현에 대한 여러분의 향후 선택은 사용자들이 이를 얼마나 받아들여 줄 수 있느냐에 달려 있습니다.

API 개발자들은 다양한 방법으로 이러한 문제들을 해결하지만, 가장 쉬운 방법은 API 를 봉쇄하는 것입니다. 만약 여러분이 자바 환경에서 작업한다면, 대부분의 클래스와 메소드를 final 로 선언하는 유혹에 빠질 수도 있습니다. C# 환경에서는, 여러분의 클래스와 메소드들을 sealed 로 선언해 버릴 수도 있습니다. 여러분이 어떤 개발 언어를 사용하든 간에, 행위를 오버라이드하거나 이후에 여러분의 선택을 제약하도록 코딩하는 것을 막기 위해 싱글턴 패턴이나 정적 팩토리 메소드를 이용해 API를 제공하고자 할 것입니다. 이 모든 것들이 합리적으로 보입니다만, 진짜로 그렇습니까?

지난 십년 동안, 우리는 점차 단위 테스트가 실전에 매우 중요한 부분이라는 사실을 깨달았지만, 이런 교훈이 업계에 완벽하게 확산되지는 못했습니다. 그 증거는 우리 주위에 널려 있습니다. 타사의 API 를 사용하는 임의의 테스트 안된 클래스에 대한 단위 테스트를 하려고 하면, 여러분은 곤경에 빠질 것입니다. 여러분은 그 코드가 마치 접착체로 붙인 듯이 API 를 사용하고 있다는 것을 알게 될 것입니다. 그것이 API 클래스이고 그래서 여러분의 다른 코드와 API 가 상호작용 한다는 것을 알아챌 수 있도록 하는 방법도 없고, 그래서 테스트를 위한 반환값을 제공할 수 있는 방법도 없습니다.

우리가 API 설계를 할 때 테스트를 실제 유스케이스처럼 생각해야만 점차 나아질 것입니다. 불행히도, 그것은  자신의 코드를 테스트하는 것보다 더 복잡합니다. 바로 거기가 API 디자인의황 금률 이 적합한 곳 입니다 .  여러분이 개발하는 API 를 위한 테스트를 작성하는 것 만으로는 충분하지 않습니다.  여러분은 API를 사용하는 코드들을 위한 단위 테스트를 작성해야 합니다. 여러분이 그렇게 할때, 사용자들이 코드를 독립적으로 테스트하는데 있어서 이겨내야 할 어려움을 직접적으로 배우게 됩니다.

개발자들이 쉽게 여러분의 API를 사용하여 코드 테스트를 만드는 유일한 길은 없습니다. static, final, 그리고 sealed 키워드는 본질적으로 나쁜 구조가 아닙니다. 그들은 때때로 유용할 수 있습니다. 그러나 테스트 이슈에 대해 알고 있는 것이 중요합니다. 그렇게 하기 위해서 여러분 스스로가 경험해야 합니다. 한 번 그렇게하면, 여러분은 어떤 다른 디자인의 도전에도 접근할 수 있을 것 입니다.

Written By Michael Feathers   , 약력

Translated by 임병수  / Reviewed by 김수현, 최현미 / Final Reviewed by 손영수

현종님이 직접 조직에서 체험한 Fearless Change 이야기가 많은 도움이 되셨는지 모르겠습니다.

연차가 올라가면서 정치는 소프트웨어를 만드는데 아주 큰 영향을 미친다는 것을 다들 서서히 깨닫으시리라 믿습니다.

사람들의 성향을 파악하고, 그에 맞게 점진적으로 조직을 바꿔나갔던 현종님의 경험담이 잘 전달되었는지 모르겠네요.

이 자료의 권한은 김현종 님에게 있으니. 사용하실 분은 저에게 연락 주시면 현종님에게 전달해 드리겠습니다 .

질문을 남겨 주시면, 성심껏 현종님과 상담하여 답변을 남겨드리도록 하겠습니다.

그리고 발표가 마치고 다 같이 Outback EVA의 위엄을 보여주기 위해 거짓말 처럼 이날 저녁 아웃백에서 식사를 했습니다.  우분투 커뮤니티에서 몇몇 분들의 공격이 예상되지만, 올려보았습니다.

일전에 Meet the Architect라는 세미나를 진행해 주셨고, 정말 많은 가르침과 깨달음을 주셨던 박현철 이사님께서 Scrum 세미나를 진행해 주십니다.

산전 수전 다 겪으시고, 풍부한 컨설팅 경험을 가지신 이사님께서 Scrum 세미나라니. 단순히 스터디가 아니라,  현업의 목소리를 들려 주실 것 같습니다.

일전에 Meet the Architect 세미나로 감명을 받으신 분이라면, 한번 다시 찾아 뵙는 것이 어떨까요?

100명 선착순이니 서두르셔서 예약하셔야 될거 같습니다.

세미나  주제 : “Scrum 네~ 이놈!“

부제 : “도(道)를 닦기 위한 Scrum인가? 프로젝트 성공을 위한 Scrum인가?” , “기존 방법론은 방법론이 나빠서 실패하고, Scrum은 사람이 나빠서 실패한다?”

“당신이 Scrum을 진정 좋아한다면, Scrum의 잠재적인 문제를 얼마나 고민했고, 실제 상황에서 이들을 극복하기 위해 얼마나 시도했고 발전시켜왔는가? 당신이 Scrum을 진정 가치가 있다고 생각한다면, Scrum으로 무엇을 했고, 어떤 성과가 있었는가? 도대체… 당신이 진정 Scrum을 좋아한다고, 가치가 있다고 말할 수 있는가?”

<<세미나 등록하기>>

http://www.bitacademy.com/etc/semina_list.asp

세미나 개요:

제목: “Scrum 네~ 이놈!”

일시: 2011년 12월 15일 19:00 ~ 21:00

장소: 비트스쿨(별관) 멀티미디어관(강남역 7번 출구 5분 거리)

* 주차공간이 제공되지 않으므로 대중교통을 이용해 주십시오

비용: 무료(창업진흥원 후원)

접수: 100명 선착순(조기 마감될 수 있습니다. 서둘러 주세요)

주관: 중소기업청, 창업진흥원

주체: 비트스쿨, 앱 창작터

문의:

앱창작터 담당자: bitappcenter@gmail.com

강사: (이름보고 오는 사람… 없네? 이름보고 안오는 사람… 헉… 이름은 절대루 안알려주~지~)

Computer Science & Statistics 전공. Tester, Developer, Modeler, Project Manager, Implementation Consultant, Software Architect(가장 오래함), Auditor, Process Consultant, IT Advisory, IT Mentor 등 다양한 역할을 수행해왔고, MBA(무지 비쌈)도 했음. 현재, Software Framework을 만드는 2년 반짜리 프로젝트 총괄PM으로 UP/Scrum/TDD를 잘 비벼쓰고 있음. 무용, 판타지, 컴퓨터 게임(특히 Diablo-II), 당구에 인생의 1/2을 소진했음. CSM(Certified Scrum Master), CSPO(Certified Scrum Product Owner), CSD(Certified Scrum Developer)임”

주의사항: 세미나와서 공부할 사람 절대 오지 말 것. 원활한 강의를 위해 육포(안짠걸루…)나 적당한 스낵을 지참하고, 특히 강사에게 제공할 경우 아주 바람직한 강의가 된다고 함. (강사가 육포만 보면 환장한다는 소문이 있음…)

얼마전 이대엽님이 도메인 주도 설계 (Domain Driven Design) 라는 명서를 번역해 주셨습니다. 저 역시 구매를 했었고, DDD가 가져오는 철학이나 사상은 정말 훌룡합니다.

왜 이런 명서가 이제 번역될수 밖에 없는지 현실을 알고 있지만, 정말 슬픕니다.

POSA나 DDD와 같은 명서들은 번역을 한다는 것의 거의 희생에 가깝습니다.

사실 역자 입장 에서는 적절한 어휘 선정과, 국내 개발자의 시선에 맞게 레벨을 조정하기 위해 각주를 다는등 여러가지 노력이 필요합니다. 

또한 책이 많이 팔릴지도 의문이고, 이미 읽을만한 분은 다 읽었다고 생각이 들고, 나의 안티를 양성하지 않을까 고민이 됩니다.

실례로, 몇몇 출판사를 통해 “명서를 왜 이렇게 번역했느냐?”라며 여러가지 공격을 당한 사례들을 종종 들었기에 쉽게 움직이지 못하는 것도 사실입니다.

이러한 상황에서도 DDD가 이 세상에 나오게 해주신 이 대엽님과 여러  고생해 주신 분들에게 감사를 드립니다.

다시 본론으로 돌아와 DDD는 고객과 개발자/아키텍트 간에 대화를 나눌수 있는 좋은 도구입니다. 

 패턴 계의 철학을 생각해 보면, 모든 상황에 만능인 솔루션은 없다. 단지 상황에 맞는 해결책이 있다는 것을 생각해 볼 필요가 있습니다. 그러기에 해당 Context들이 대부분 도메인과 밀접한 연관이 있고, DDD의 초안이 PLoP 에서 첫 데뷔를 했기 때문에 역시 그 본류는 패턴의 철학과 맞 닿아 있는 방법입니다.

그럼 DDD를 프로젝트에 적용하기 이전에, 고려해야 할 것들 이야기 해보고자 합니다.  어떠헌 프로세스, 툴들에게도 동일하게 적용된느 철학입니다.  맹목적인 추종보다 결국 상황에 맞는 솔루션이라는 것을 기억해 주셔야 됩니다.

프로젝트의 범위나 개발자 스킬, 비용 문제..

2년전 Rebecca님이 정말 현실적인 아키텍트라고 생각이 든 발표가 있었습니다.

Domain 지향적인 설계 (줄여서 DDD)가 구축만 되면 재사용이 되기 쉽고 관리 비용도 낮아진다는 겁니다. 정말 Domain Logic이 복잡하고 재사용이요구될때 진가를 발휘하는게 Domain Model 인거 같습니다.

하지만 Domain Logic 자체가 복잡하지 않않는데 Domain Model을 사용한다는 거나, 기존의 Database, Transaction Script에 익숙한 DBA나 개발자들에게 Domain Model을 구축하게 만든다는 것은 정말 일종의 새로운 시도가 될수 있습니다.  그러니 주의깊게 사용해야  된다는 것이지요.

익숙하지 않는 툴과 프로세스는 좋은 지휘자가 없으면 정말 프로젝트가 산으로 갈수 있기 때문이지요. 이미 금융, 보험등과 같이 그쪽 도메인에 익숙한 분들도 계속되는 차세대에 허덕이고 있는 것이 현실입니다.

예측하지 못하는 금융, 보험 상품들의 탄생, FTA같은 변화들로 인해 결국 계속 바뀔수 밖에 없지만요..  결국 미래의 변화를 예측하지 못하는 본질적인 문제이지요. 

변화를 수렴할수 있는 구조를 만든다는 것은 정말 아키텍트의 크나큰 과제인거 같습니다.

DDD와 프레임워크간의 시각 차이 – Target User를 정확히 고려해라

정말 인기있는 프레임워크를 만드는게 목표인데, Domain 특화된 용어들을 잔뜩 적어 놓으면 그 분야의 전문가가 아닌 사람은 접근할 수 없는 성역을 만들게 된 것입니다.

사실 많은 프레임워크 설계자가 가지는 잘못된 생각입니다.  내가 그분야의 전문가이니 다들 이렇게 하면 알겠지…
.NET 프레임워크의 설계자인 Krzysztof Cwalina 의 실패 경험을 통해 나온 정말 값진 격언입니다.

여러분을 좋아하는 사용자들을 위해 설계하는 것은 쉽지만, 여러분을 좋아하지 않는 누군가를 위해 설계한다는 것은 매우 어렵다. 

도메인 전문가들(domain experts)이 설계한 매우 많은 Framework(API) 들이 있지만, 솔직히 얘기해서 그 Framework(API)들은 도메인 전문가에게만 좋다. 

대부분의 개발자들은 도메인의 전문가가 될 것도 아니며, 현재 어플리케이션(modern applications)에 적용되는 모든 기술의 전문가가 되려고 하는 것도 아니다.

프레임워크는 많은 사용자가 쓰기 위해 만든 것인데,  도메인 특화된 용어를 도배를 해버리면 굉장한 학습곡선을 요구하죠.

대안으로 일반적인 사용자를 위한 Low Level API 부터 고급 사용자를 위한 High Level API를 Wrapper Facade로 제공하는 경우도 있지만 구축 비용과 유지보수 비용도 상당히 상승하게 됩니다.

즉 무엇을 얻으면 무엇을 내줘야하는 Trade-Off의 현실과 직면하게 됩니다.

맺으며..

결국 설계란  다양한 이해당사자와  그들간의 정치, 시간, 비용들 간에 얼마나 적절한 균형을 맞추느냐에 있다는 것을 요즘 많이 깨닫고 있습니다.

맹목적인 추종보다는 상황에 맞는 해결책을 그리고 그 해결책을 관철보다는 이해당사자의 상황에 맞게 다듬는 것이 필요한데..

전 아직 갈길이 먼가 봅니다. ..

권한은 없고 책임만 가득한  IT의 현실에  묵묵히 일하고 있는 선배님, 후배님에게 격려를 표하며 저의 부족한 생각을 적어 보았습니다.

PLoP 2011의 의장인 Lise Hvatum 과 2일에 거쳐 패턴을 같이 다듬었습니다. 사실 이번 PLoP에는 저희가 바쁜 일정에 논문을 잘 쓰지 못해서 논문을 같이 다듬는 Writing Group으로 배정을 받았는데, 오히려 많은 것을 배운거 같습니다.

같이 논문을 써준 김 지원님이 같이 간 덕분에 외롭지 않고, 이래 저래 정리한 내용도 2배로 늘어났습니다.

결과적으로 좀더 Clear하게 그리고 Simple 하게 전체적으로 패턴을 바꾸었습니다. 첫째날 차 유리가 깨지고 지원이가 노트북을 읽어 버리는 바람에 사고 수습하느라 하루가 날라가 버리고, 남은 2일동안 강행군을 펼쳤고, 마지막날 새벽 4시에 겨우 마쳐서 최종본을 보냈슴니다.

지원가 맘고생도 많았지만, 이 잃어버린 노트북만 아니였어도.. 이렇게 고생을 하지않았을 텐데… 마지막날에 발표한 자료가 pdf 로 변환하면서 몇몇이 깨져버려 이래 저래 고생을 가장 많이한 PLoP 입니다.

Lise에게 보여주니, 새벽 4시에 온 메일을 보고 놀랐다고,정말 용감했다고 하더라구요! 좀더 명확하고 간결해졌다고 피드백을 받았습니다.

저자 워크샵
저자 워크샵이 무엇인지 모르시는 분은 제가 일전에 포스팅 한 저자 워크샵 데모 포스트를 보시고읽어보시면 좋을듯 합니다.

(중앙에 있는 분이 PLoP 11 Chair이자 , 저희 논문 Shepherd였던 Lise Hvatum , 그리고 오른쪽에 있는 분이 AsianPLoP의 리더이자, 와세대 대학의 조교수이신 Hironori Washizaki 입니다.)

 실제 저희 워크샵에서 받은 내용을, 지원이가 잘 정리해 주었습니다.  추후 mp3를 듣고 더 업데이트 할 생각입니다.

시작 :

저자가 일어나서 자신의 패턴을 잘 소개할 수있는 문장을 읽습니다. 지원이가 Introduction 에 있는 한 문단을 통째로 읽었습니다.

Fly on the wall :

이제 저자가 “벽위의 파리” 가 됩니다. 아무런 발언권도 없고 모여 있는 사람들이 패턴을 어떻게 이해하는지만 볼수 있습니다.

칭찬:

논문에 대한 긍정적인 점을 먼저 말합니다.

• 논문의 구조가 패턴 템플릿에 맞춰 아주 잘 잡혀 있다.
• 그림이 잘 들어가 있다.
• 학생들의 연구의 자료가 아닌, 업계에서 사용되는 기술을 공유해 줘서 가치가 있다.

하지만 나중에 그림이 혼돈스럽다고 피드백을 많이 받았습니다. ^^;;

개선 :

Design 그룹의 좌장이신 Bob Hanmer가 조정자가 되어 한 페이지씩 읽어가며 피드백을 받습니다.

• Introduction

인트로덕션에서는 실제 세계에서 쓰이나 너무 범위가 크다. 그건 실제로 받아들여지기 어렵다. 변경은 비즈니스 요구사항에서 올것이다.

리사: 키워드는 단지 용어에 가깝다. terminology. 한-영에 도움을 주기 위해서 필요.
pull, poll 은 같은것인지. 헷갈린다. concept에서..

앙드레 : 3인지 2패턴의 조합인지 헷갈린다. 그림 및 내용이 너무 크다. 레퍼런스로 밀어버릴 수 있다.

히로 : 어디에 이벤트가 발생하고, 저장되는가. 그림 1은 있으나, 그림 2에는 없다.
앙드레 : poll은 지가 알아서 체크하니 그런거 필요없다.

• context

핸머 : 일종의 예 섹션
앙드레 : 위치에 대한 것이 context이고 building은 예. 핸머 context result 섹션은 없다. / wired, wireless 는 중요하나? 왜 언급했나? 너무 자세한 부분으로 뛰어 들어 갔다.
리사 : 그냥 connected면 오케이,
앙드레 : 맞다
리사 : 근데 전략 선택에서는 중요 요소일 수 있고 ,하나의 조건거리로 생각할 수 있다.
앙드레 : 다양한 면을 보여주지만, 너무 커서 뭔가 재사용에 대한 것을 생각하기 힘들다.

• problem section

앙드레 : 분산은 좀더
A : consistency
B : …
요런식으로

알렉스 software updates? 어떻게 분산시킬래? 헷갈린다.
리사 백그라운드가 필요하다
히로 : 다중 클라이언트가 들어간다.
하나의 클라이언트? = 디바이스들의 모임?
디바이스가 뭔가?,
PC? 모바일? 타입?
뭐든지 생각해볼수 있다.

• forces

알렉스 : 이미 설치되고 있다는 거냐? 그냥 사용할 소프트웨어라는 거냐?
알렉스, 언어표현이 좀 그렇다.
리사: 번역하면 그렇더라
히로 : composing이 어떤 의미인가?
핸머 : 하이브리드다.
앙드레 : 컴포지팅이 헷갈린다. push, polling을 그냥 복합시킨다는게 애매하다.
이게 negative인지 모르겠다?

• solutions

Ticket 이 업그레이드를 표현하는 적합한가?
히로 : 누가 Ticket을 만드나?
아마도 정책이거나, 뭐 그런거 같은데. 내가 직접 하나?
앙드레 : 이름은 이 도메인에서 쓰이나?
리사 : 처음으로 쓴 용어다. 근데 도메인에서는 일반적이다.
히로 : 프로젝트 서비스 관리에서,
앙드레 : 좀더 큰 영역에서 사용될 수 있나?
핸머 : 여행 티켓팅 시스템을 생각해 볼 수 있지 않나?
리사 : 작업관리와도 같다.
앙드레 : 여전히 헷갈린다.
서비스 팩.
이해하는데 좀 시간이 걸린다.

• structure

히로 : 채널이 어디있는지 부정확하다.
다중 채널은 어떻게 되나?
앙드레 : uml인가? 아니면 custom인가?
알렉스 : 이게 얼마나 큰건지 모르겠고 역할도 잘 모르겠다. 특히 티켓 메니져는 뭐하나?
앙드레 : 이름과 설명이 없다.
알렉스 : 누가 채널 만드나?, 티켓을 만드나?

• dynamics

알렉스 : 왜 이게 필요한가?
채널이 하는게 어디갔나?
앙드레 : behavior가 더 낫지 않나?
히로 : 서버사이드만 있다. client사이드는 어디있나? 핸머 : 맞다
갭이 있다.

• known use and variations.

리사 : 레퍼런스로 가는게 좋지 않나? 실제 쓰는지 잘 모르겠다. 메인스트림에서 말이지.

• consequences

리사 : advantage는 좋다.
히로 : 제안 : 어떻게 이 패턴이 각각의 forces를 해결했는지. 매칭시키면 좋겠다.

핸머 : 글치

• related patterns

핸머 : 다른 패턴과 무슨 관련이 있는지 알겠다. 내 산업군에서는 이런걸 많이 해서, 쓰기에 좋다. 좀더 명확히 할 수 있겠다.

Welcome Back

피드백 주기가 마치면, 이제 저자가 다시 대화를 할수 있습니다.
먼저 감사의 말을 하고, 피드백중 궁금한 것이 있으면 물어볼 수 있습니다.

감사의 박수

그리고 마치면 나머지 저자들이 좋은 패턴을 만들어 준것에 감사하며, 박수를 치며 저자 워크샵을 마무리 합니다.

이번 Bootcamp 행사는,  Linda Rising이 개인적인 사정으로 참석을 못해 아쉬움이 컸습니다. 하지만 반사 이익으로 사상 최고의 맴버로 진행이 되었습니다 . Robert Hanmer, Joe Yoder, Rebecca Wirfs-Brock 님이 진행을 하셨습니다.  이전 2번의 워크샵과는 다르게 프리젠테이션이 많이 보강되었습니다.

작년에 있었던 Joshua Kerivsky 발표의 영향 때문인지, Christopher Alexander의 철학과 이야기들이 많이 보강되었고, Joe Yoder가 AsianPLoP에서 했던 패턴 라이팅까지 패턴을 가르키는데 종합 선물센트에 가까운 Bootcamp 였습니다.

거기다 일본 KEIO대학에서 대거 행사에 참여했는데, 다케시라는 분이 Learning Pattern Languages를 만들었다며 선물로 나누어 주었습니다. (같이 프로젝트를 한 토모라는 분이 “Learning Pattern”의 PDF 버전이 공유되어 있다고 하니, 추후 접수되는 대로 공유하겠습니다. 아마 지금 일본 분들은 고국으로 가느라  비행기에 있겠네요.)

패턴은 전문가의 조언이다.

Rebecca가 예롤 든 것은 바로 POSA1  (패턴 지향 소프트웨어 아키텍쳐) 1권에 나온 Window Place 였습니다.

바로 창문 주위에는 사람들이 뭔가 능동적인 활동을 하기 위한 곳이라는 거죠. 빛이라는 존재가 만물에게 긍정적인, 그리고 활동적인 에너지를 주는 존재이기 때문에, 사람은 자연스럽게 능동적인 활동을 할때, 대화나 공부등을 할때 빛이 필요합니다.

사실 위 그림을  보면 남들에게 방해를 받지않게 독립적인공간 (엘코드 – Alcove)를 구성하게 되어 있는데요. 이러한 활동적인 일, 또는 잠을 잘때도, 자신만의 독립적인 공간을 가지기 위해서죠. 외부로부터 보호를 받기 위해 독립적인 공간에서도 빛이라는 존재를 필요로 하는 생명체의 모습을 잘 보여주는 단면이라고 할수 있습니다.

이에 연장선상으로  Christopher Alexander의 패턴 언어에서는 LIGHT ON TWO SIDES OF EVERY ROOM 가 나오는데 많은 건물들이 사격형으로 되어 있을때 두 면은 빛을 받도록 되어 있고, 두 면은 빛을 받지 않게 되어 있답니다.   다행히 이번 Bootcamp장소는 두면이 빛이 들어오는 건물이라. 다들 흡족해 하더라구요.  지난 네버다에서는 빛이 들어오지 않아 우스개 소리로 빛이안들어온다고 투덜 거렸던 것이 기억납니다.

Pattern Languages = Proven Solution + Relationship

이어서 Bob Hanmer가 Fabric소재를 예를 들어, 이것들을 어떻게 짜는 법칙들이 바로  Pattern이다라고 말을 했습니다. 어떠한 문양을 내기 위해선이렇게 짜야 하고, 바지를 만들기 위해서는 이렇께 만들어야 된다라는 예를 들어 설명해 주었습니다.

그러면서 언급한 것이 Christoper Alexander의 Life of Building을 예를 들었습니다.

Pattern is Solution, Problem, Context라는 이야기를 하면서 이 3박자가 매우 중요하다고 말을 했습니다.  이 부분은 지난 Nevada에서 이었던 PLoP  Bootcamp 포스트를 보시면 이해가 될듯 합니다.   Problem/Solution 섹션부터 보시면 이해가 될듯 합니다.

Pattern Languages 적인 입장에서 보면, 패턴들은 독단적으로 사용되는 것이 아니라. 무수히 서로간에 영향을 미치면서 서로의 단점을 상쇄시키기 위해 연결되어 집니다. 바로 Relationship을 가지는데, 그걸 묘사해 놓은 것이 Context입니다.  Alexander는 패턴에서 이러한 연관성 (Relationship)을 매우 중요하게 설명합니다.

결국 Pattern Languages(패턴 언어)라는 것은  Proven Solution(입증된 해결책)이고 연관성 (Relationship)이 모인 것이라고 생각하시면 됩니다.

다른 것들과 패턴과의  차이점

패턴과 New Idea는 다른다. 패턴은 재사용되고, 여러사람들에 의해 인정받은 것입니다. 즉  It must be mature , proven solution이 패턴이라는 거죠.

또한 알고리즘과의 차이점은 패턴은 정형화와 자동화가 되어 있지 않습니다. 자동적으로 코드가 생성되지도 않고, 주위 상황  (Context)에 영향을 많이 받기 때문이죠. MVC 외에도 MVVM, MVP, PAC 등 수많은 변형을 만들어 내므로,  쉽게 정형화하기 힘듭니다.  기존의 컴포넌트 같이 라이브러리 같이  Drag&Drop (Turn the crank) 해서 쓰일수 없습니다.

또한 Recipe처럼 Step by Step으로 따라한다고 무조건 되는 것도 아니고, 간단한 룰(Simple Rule)도 아닙니다.

패턴의 구성요소 설명하기

그 다음 패턴의 구성요소들에 대해서 설명을 하고 있습니다. 이  내용은 그다지 변한 것이 없습니다.  아래 링크를 보시면 도움이 될듯 합니다.

• Linda Rising의 패턴 만드는 법
• Joe의 패턴 라이팅

이중 Forces를 통해서 이 패턴이 나타내는 중요성을 잘 언급하고, 긴장감을 형성해서 왜 우리가 다루는 Problem이 기존 해결책으로는 왜 해결하기 어려운지 들어내고, Force에서도 Positive, Negative를 잘 다루라고 설명했습니다.

그외의 패턴 구성요서에 대한 이런 저런 이야기들.

이미 이전 블로그 포스팅에 했던 이야기들과 중첩되지만, 제가긁적 긁적되었던 글도 다 적어봅니다.

패턴을 얼마큼 길게 적어야 하나? 라는 질문에 가능한 간결하게, 하지만 어떤 정보도 없을수 없게 짧지는 않게 작성해라.

패턴 이름을 만들때, 패턴이 무엇인지 명확하게 알수 있게 설명해라. 또한 기존 이름과 겹치지 않고 새로운 이름으로 작성해라.  Bob Hanmer가 처음 패턴 목자가 되어 패턴을 코칭할때 Buffalo Mountain 이라는 패턴이 있었다. 실제 의미는 “Look at the data”  였는데, 정말 난해해서 고치라고 했다.

또한 패턴 이름을 지을대 Problem/Solution중 어디에 초점을 맞추어야 하나? Solution에 초점을 맞추어라.  비슷한 문제도 다양한 해결책이 나올수 있으므로, 해결책에 맞추는 것이 맞다.

Force는 “패턴이 왜 이 문제가 어려운지를 설명해라?”. 그래서 우리의 해결책이 정말 가치있는 것이라는 것을 표현해야 된다. 또한 Force는 Context를 정리해 긴장을 유발 시키는 곳이다.

Rationale (이론적 해석) 을 추가해라. Sorting을 해야하는 문제가 발생했다고 하자. 그럼 왜 Bubble Sort보다 Quick Sort를 써야되는지에 대한 근거를 대야 된다.

다양한 패턴 포멧 맛보기

이번  Bootcamp는 위에서 언급한것처럼 Joseph Yoder 와 작년에 있었던  Joshua Kerivsky 의 영향을 받아서 인지 Alexanderian Format에 대해서 많은 언급이 이었습니다.

Christopher Alexander Form

A Pattern Language에 나온 Small Meeting Room으로 Christopher Alexander의 패턴을 설명하면서 패턴 포멧들의 차이점을 나열해 주었습니다.

불과 작년만해도  PatternLanguage.com이 무료였는데, 올해부터 한달에 $5, 1년에 총 $60달러를   내야만 맴버쉽이 될수있어서 볼수 있습니다. 저같이 책을 소장한 사람이 참 신청하기 그렇네요. 여튼 그래서 Google Books에 일부 공개한 내용이 있어 링크를 겁니다.

Alexandarian Form에 대한 이야기는 아마 작년 Joshua 때문에 대폭 보강이 된거 같습니다.  작년에 있었던 Joshua Kerievsky의 A Timeless way fo communicating을 보시면 될듯 합니다.   역시 몇년동안 꾸준히 참석하니 이제 포스팅이 줄어드는 군요

GOF Form

이 패턴을 설명하는 Rebecca가 GoF의 디자인 패턴이 번역된 나라에서 왔으면 손을 들어보라고 하더라구요.  정말 다 손을 들더라구요. 거기다 대학교 교재로 쓰인만큼 널리 퍼져서 인기가 좋은 책이라고 하네요. Creational / Behavior / Structural 한 분류에 대해서 이야기 했습니다.  많은 사람이 패턴을 만들때 GoF 포멧을 참조하는데, 자신이 쓸  패턴에 맞게 포멧을 결정하라고 충고했습니다.  사람과 연관된 문제를 다루는데 Sample code 섹션을 추가할수 없다고 말하더라구요.

Schmidth Form

POSA 폼이라고 불리는 Douglas C. Schmidth님의 패턴입니다. Strategized Locking, Thread-safe Interface, and Scoped Locking 을 가지고 설명을 했습니다.  POSA는 GoF와 다르게 특정 도메인을 상세히 기술한 패턴입니다. (1권 Architecture, 2권 Network, 3권 Resource.. )  그러니 여러분이 기술적인 도메인을 다룬다면 POSA (Schmidth) Form으로 가는것이 맞을듯 합니다.

또한 POSA하면 빠질 수 없는게 CRC 카드입니다. Class Responsibility Card인데요. CRC라는 것을 통해서 객체의 Responsibility를 잘 표현할수 있습니다.

Coplien / Hanmer Form

Architecture / Design / Idiom 으로 표현하는 방법입니다.  Coplien과  Bob Hanmer님은 패턴 언어로서 서로간의 패턴이 어떻게 연관성을 미치는 지를 표현하는 방법을 선호한다고 합니다.

전체적인 내용은 Martin Fowler님의 Writing Software Patterns를 참고하시면 도움이 될듯 합니다.

패턴 라이팅 실습

남은 시간에는 지원이가 제시한 “고객과 어떻게 하면 Communication을 할수 있는가?”를 패턴 으로 만들어보았습니다.  이 부분은 나중에 지원이가 공유해 줄겁니다.

위에서 언급한 Joe의 패턴 라이팅을 참고하시면 됩니다.

맺으며..

이번  Bootcamp는 지금까지 듣지 못한 가장 강력한 Bootcamp였습니다. Bob , Joe, Rebecca 이렇게 업계 최고의 아키텍트들 3명이 모여 지식을 전파한다는게 쉽지 않은데, 정말 멋있는 시간이었습니다.

또한 Bob Hanmer에게  Fault Tolerance 패턴을 번역할려다가 실패한 이야기를 전해드렸더니 많이 우울해 하시더라구요. Dummy시리즈로 새로운 책을 쓰시는거 같은데. 사전협의하여 EVA 식구들과 함께, 번역을 할수 있게 도움을 드리도록 할 생각입니다.  그럼 이것으로 Bootcamp 후기를 마치겠습니다.

PLoP 11 / SPLASH에 다녀오겠습니다.  갑자기 쌩뚱맞지만,  이제 저에게는 연례 행사가 되었답니다.  저의 성장에 큰 밑거름이 되준 PLoP에 다녀와서 많은 정보를 공유하겠습니다.

또한 이번 학회는 별로 외롭지 않은 것이 EVA팀의 김지원군 역시 회사 지원을 받아 같이 가게 되었습니다.   포스팅을 2배로 할수 있고, 곧 더 많은 정보를 전달해 드릴수 있어서  정말 기쁩니다. 전 아마 이 학회 다녀오면 몇일간은 잠을 못자며 정리하느라 보낼 수도 있습니다.

작년 2010년 PLoP에 다녀와서 남긴 포스트 입니다. 물론 더 있지만 굵직한 것 위주로 정리해 봤습니다.   (PLoP 에 대한 더 많은 정보를 아시고 싶으시면, http://arload.wordpress.com/tag/plop/를 보시면 될듯 합니다.)

• [PLoP] Joe의 패턴 라이팅
• [PLoP] Bootcamp in Nevada
• [PLoP] Rebecca Wirfs-Brock의 Nature of Order I.
• [PLoP] Rebecca Wirfs-Brock의 Nature of Order II.
• [PLoP] Joshua Kerievsky의 A Timeless Way Of Communicating

이번 PLoP / SPLASH 일정입니다.

그럼 후기를 기대하시구요!!.   포틀랜드가서 글을 남기겠습니다!!

Atmosphere (분위기) 편

스타벅스의 CEO Howrad Schultz는 그의 저서에서 편안한 만남의 장소의 중요성을 언급하면서 미국에서 사적인 교류의 시간이 줄어들고 있다고 지적했다. 1990년대 들어서 커피숍이 미국인의 사교의 장소로써 중요한 역할을 차지 하게 되었다. 이러한 장소는 집이나 회사의 일에 간섭 받지 않는 “제 3의 장소” 역할을 담당했기 때문이다.

이번 파트부터는 Atmosphere(분위기,장소)에 관한 이야기이다. 분위기나 장소의 선정도 스터디를 오래 이끄는 데 필수적인 요소이다. 큰 장소를 선정하고 그 장소내의 분위기 자리배열방법, 온라인 공간을 만드는 것에 대해 나누고자 한다.

6. 누구에게나 편안한 장소 (Common Ground)**

집이나 회사를 제외하고 모두가 편안함을 느끼는 장소를 어떻게 하면 찾을 수 있을까?

스터디를 진행하거나 주제를 정하는 것만큼 장소를 정하는 것 또한 중요하다. 모든 멤버들을 만족시킬 때 비로소 최적의 스터디 장소를 찾았다고 할 수 있다.

가장 좋은 스터디 장소는 각 개인들의 일에서 연관되지 않은 공공의 장소이다. 예를 들어 보통 조용한 카페 같은 곳이 될 수 있으며, 집이나 회사는 다른 사람의 영역이라는 생각을 들게 하기 때문에 좋지 못하다. 모든 멤버들이 가기에 멀지도 가깝지도 않은 위치에 편안하게 이야기를 나눌 수 있는 공간을 찾는 것이 좋다.

■ Diagram

7. 공공의 거실 (PUBLIC LIVING ROOM)*

앞서 최적의 장소를 찾았다면 그 공간의 분위기나 느낌에 대해 결정해야 한다. 그 내부에서 사람들이 편안함을 느낄 수 있고 이야기를 자유롭게 나눌 수 있을 수 있어야 한다.

만약 스터디 공간이 사무실과 같이 너무 칙칙하거나 썰렁하다면 혹은 조명이 지나치게 어둡다면 어떻게 될까? 아마도 편안한 마음을 갖고 대화하기는 많이 힘들 것이다. 이처럼 극단의 상황이 아니더라도 장소의 분위기는 스터디를 유지하는데 많은 연관성이 있기 때문에 주의해서 선정하여야 한다.

최적의 스터디 장소는 넓고 편안한 거실과 유사하다. 보통 거실에는 다양한 종류의 의자와 편안한 소파가 있으며 카펫이 깔려있다. 게다가 따뜻한 조명과 큰 창문도 있을 것이다. 이러한 편안한 분위기가 스터디에 활력을 불어 넣어줄 수 있다. 다양한 종류의 의자가 제공되며 자신이 앉고 싶은 편안한 자리를 제공하고 바꿔 앉을 수 있도록 한다면 스터디가 시작되기 전후에 사람들이 자연스럽게 섞일 수 있다. 또한 따뜻한 조명이 있고 약간의 먹을 거리와 음료가 제공된다면 더욱 금상첨화이다.

시작하면서 언급했던 패턴의 아버지인 Alexander의 1977년 출간된 A Pattern Language라는 책에 보면 좋은 장소에 관한 설명이 나와있다. 총 3가지를 언급하였는데첫 번째가 둥글게 둘러서 앉는 것이다. 사람들이 서로를 마주 보며 둘러 앉게 되면 그 분위기에 묻혀 자연스럽게 친밀한 관계가 된다. 두 번째는 많은 의자를 준비하라는 것이다. 크거나 작은, 부드럽거나 딱딱한, 팔 받침이 있거나 없는 등의 다양한 의자를 준비하면 자신의 취향에 따라서 자유롭게 앉을 수 있어서 활기찬 분위기로 이끌 수 있다. 또 다른 한가지는 “조명이 비추는 곳”으로 조명에 따라 분위기도 달라질 수 있다고 조언했다.

■ Diagram

8. 친밀한 자리배열 (INTIMATE CIRCLE)

장소와 공간 외에도 자리를 앉는 방법에 의해 스터디 분위기가 많이 달라진다.

최근 드라마를 보면 회장님이 빠지지 않고 등장한다. 회장님의 집무실에는 어김없이 회의 책상이 있다. 보통 일자형으로 되었으며 회장님이 회장석인 가운데에 앉게 된다. 이러한 형태는 회장님이 부하직원에게 지시하기에는 편하지만 모든 사람들이 소통하고 토론하기에는 힘들며 중간에 자신의 의견을 말하지 못하는 멤버가 생길 수 있다.

가장 효율적인 자리배치는 모든 구성원이 물리적으로 서로 가깝고 서로 소통하기에 편안해야 한다. 자리 배치로 가장 이상적인 것이 원형으로 둘러 앉는 것이다. 원형으로 둘러 앉으려면 충분한 공간이 확보되어 있어야 하고 많은 테이블과 의자가 준비되어 있어야 한다. 그리고 구성원들이 즉각적으로 자리를 옮기거나 재배치 하기 편안한 형태이면 더욱 좋다.

최근 강남이나 종로등 학원가 주변에 스터디룸을 대여해주는 곳이 많이 생겨났다. 이러한 곳의 자리배치를 보면 원형탁자이거나 자리배치를 마음대로 할 수 있도록 꾸며진 곳이 많다. 이처럼 자리배치는 분위기를 조성하는데 중요한 작용을 한다.

■ Diagram

9. 온라인 공간(VIRTUAL SPACE)

스터디를 더욱 효율적으로 끌어나가기 위해서는 오프라인뿐만 아니라 온라인의 활동도 병행되어야 한다.

스터디의 운영을 장기적으로 생각해서 운영하려면 홍보와 새로운 멤버 추가가 매우 중요하다. 하지만 온라인 공간 없이 오프라인으로만 스터디를 홍보하거나 새로운 멤버를 만나려고 한다면 비용도 많이 들며 비효율적이다. 웹이라는 도구를 사용하여 스터디 그룹을 보다 효율적으로 이용해야 한다.

오프라인으로만 스터디를 운영한다고 하여도 잘 운영될 수 있다. 하지만 온라인공간으로 확장하여 함께 운영한다면 온라인공간의 다양한 장점을 활용하여 더욱 발전할 수 있다. 온라인 공간은 스터디의 멤버들이 지속적으로 이야기를 공유할 수 있는 공간이다. 따라서 멤버들의 적극적인 참여를 더욱 높일 수 있다. 또한 연락처공유, 주제공유를 통해 미리 내용을 예습 하거나, 이메일이나 문자메시지, SNS를 이용해 공지를 쉽게 전파할 수 있는 장점도 있다. 정기적인 행사, 주제에 관련된 링크와 포스트를 공유한다면 더욱 좋다.

몇몇 멤버의 인터넷 접속환경이 느려서 빠르게 확인할 수 없는 상황에는 온라인으로 공지를 내린다면 오히려 문제가 발생할 수 가 있다. 따라서 모두가 쉽게 사용할 수 있다는 전제가 되어 있어야 한다.

■ Diagram

지금까지 우리는 스터디를 운영하는 정신(SPRIT)과 분위기(ATMOSPHERE)에 대해 알아보았다. 글의 서두에서 미리 밝혔던 것처럼 패턴의 경우 단일 패턴으로서의 의미보다는 ‘패턴 군’으로 있을 때 좀 더 효과를 발휘한다. 글을 읽으면서 이점에 유념하여 읽었다면 서로 연관되어 있는 패턴은 어떤 것들이 있으며 함께 사용하면 어떤 점이 더 유용한지를 알 수 있다. 따라서 주의 할 점은 앞의 9가지 패턴을 각각의 패턴으로 따로 놓고 보면 안 된다는 점이다. 각 패턴을 언급하면서 종종 연관된 패턴에 관해서 말했듯이 이 21개의 패턴들은 서로 연결되어 있다. 결국 9개의 패턴 뿐만 아니라 다음 회에서 언급할 12개의 패턴 모두가 모여 하나의 패턴 군을 이룬다.

다음 회 에서는 역할(ROLES)에 관련된

• 열정적인 리더(ENTHUSIASTIC LEADER),
• 의욕적인 사회자(MOTIVATED MODERATOR),
• 적극적인 참가자(ACTIVE PARTICIPANT),
• 준비된 참가자(PREPARED PARTICIPANT),
• 뛰어난 참가자(DISTINGUISHED PARTICIPANT)

에 대해서 알아보겠다.

삼성 소프트웨어 맴버십 후배이자, 지인의 소개로 만난 소마에 소속인  김민수, 장성환, 이원희, 채경훈님에게 정말 감사드립니다.  정말 이 4친구에게 감사의 메세지를 보내며, 지식 나눔에 정말 감사를 표합니다.  훗날  따로 이 친구들에 대해 포스팅을 하도록 하겠습니다.

또한 이 편역된 자료를 다듬어 준  EVA 식구 분들에게 감사드립니다. 아무런 댓가 없이 열심히 다듬어 주셔서 감사드립니다.

소프트웨어 설계가 아니라. 스터디를 성공적으로 이끄는 패턴이라 의아해 하시는 분이 있을지 모르지만, 모든 것들이 사람이 모여 만드는 결과 이므로 사내 동호회나 커뮤니티에서 스터디를 이끄시는 분에게는 도움이 될듯 합니다.

이글을 읽기 전  2010년 PLoP에서Joshua Kerievsky가 발표한 “A Timeless way of Communicating”을 보시면 여러므로 도움이 되실 듯 합니다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

Alexandarian 포멧이란?

오늘 살펴볼 스터디 패턴 언어 또한 이러한 Alexandrian 포맷을 지켜 작성되었다. 따라서 이러한 형식에 대한 기술 방법도 함께 생각하여 읽는다면 많은 도움이 되리라 확신한다. 추가적으로 매년 개최되는 PLoP학회에서 사용하는 패턴 템플릿 을 참고하기 바란다.

이 글에서는 지면의 제약으로 인해 Alexandrian 포맷을 설명하겠다.

1.  Pattern Number, Name(패턴 이름)은 패턴을 알아볼 수 있는 이름을 말한다.
2.  Archetypical Picture or Diagram(전형적인 그림)은 해당 패턴을 한눈에 이해할 수 있는 그림을 말한다.
3.  Headline(헤드라인)은 패턴이 나온 이유를 한 줄로 간략하게 설명한 부분이다.
4.  Body(본문)는 패턴이 나오게 된 배경 문제를 기술하는 부분이며,
5. 솔루션은 문제를 해결하는 방법을 말한다.
6.  Context(문맥) 부분은 결론 및 이 패턴을 사용하였을 때 발생할 수 있는 다른 이슈에 대해 말하는 부분이다.
7. Diagram of Solution(해결책의 다이어그램)은 지금까지 이해한 패턴을 다이어그램으로 한눈에 다시 확인할 수 있는 다이어그램 부분이다.
8. 참고로 패턴 이름 옆에 붙어있는 *표시는 패턴의 일반성을 나타내는 것이다. 별이 두 개 있다면 널리 사용되고 일반적으로 다른 분야에서도 사용이 가능하다는 것을 말한다.

스터디 그룹 패턴 언어를 시작하며.. 

그러면 지금부터 Joshua Kerievsky가 작성한 스터디 패턴 언어에 대해 알아보도록 하자. 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs)부분 이다.

‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 마무리를 하고 있다.

‘관습’ 부분에서는 15. 토론을 시작하기 전에 질문을 해서 자연스럽게 동기유발을 하도록 하자는 것과, 16. 이해하기 어려운 학문이나 문학은 발생한 시간 순으로 공부하자는 점, 17. 토론 주제를 정하고 그에 맞춰 진행하자는 것, 18. 인원이 많아질 경우 서브그룹(소모임)을 만들어 진행하자는 것, 19. 스터디의 주기를 어느 정도로 해야 할지, 20. 스터디 내용을 정리하기, 21. 스터디 후 모임을 갖자는 내용으로 마친다.

Sprit (정신편) 

누구나 한번쯤은 스터디를 해본 경험이 있다. C++에서부터 네트워크, 보안 등 소프트웨어에서 공부해야 하는 양은 방대하기 때문에 효율적으로 공부하기 위해서 스터디를 만들거나 기존의 스터디에 참여 하였을 것이다. 이번 장은 ‘SPRIT(정신)’ 부분인데, 스터디 그룹을 잘 유지하기 위해 해야 할 가장 기본적인 생각들을 정리해 놓은 것이다.

1. 지식의 원천 (KNOWLEDGE HYDRANT)에서는 스터디를 해야 하는 이유에 대해 설명하고 있으며, 그 안에서는 토론형태로 진행을 해야 한다는 것을

2. 통찰의 풀(POOL OF INSIGHT) 패턴에서 말하고 있다. 방법뿐만 아니라 분위기도 중요한데, 집중할 수 있는 편안한 분위기에 관해

3. 집중할 수 있는 분위기(SAFE PLACE) 패턴에서 설명하고 있으며, 무엇보다 꾸준히 하는 것이 좋다는 점을

4. 지속적인 에너지 (ENDURING ENERGY)에서 설명하고 있다.

마지막으로 5. 마음 맞는 사람들 (KINDRED COLLABORATORS)에서는 꾸준하게 함께 한 사람들은 좋은 인맥이 될 수 있으니 지금이라도 소모임이나 스터디에 참석 하라고 권유한다.

 1. 지식의 원천 (KNOWLEDGE HYDRANT)**

사람들은 지식의 범위를 넓히고 깊이를 더하고 싶어 하지만 어디서 어떻게 공부를 시작해야 할지 모른다.

세상에는 너무나 많은 정보가 쏟아지고 있고, 한번에 하나의 지식만을 습득하기 보다는 다양한 지식을 한꺼번에 얻는 경우가 더 많아지고 있다. 또한 최신서적 외에도 30년 이상 된 고서들이 더 유익한 경우도 있지만 사람들은 쉽게 펼쳐보려 하지 않는다. 이유는 무엇일까? 이러한 원인은 진정 공부하고 이해하는 것에 대한 두려움을 느끼기 때문이다.

지식을 효율적으로 공부하는 가장 좋은 방법은 스터디 그룹이다. 지식 습득의 좋은 방법은 자신이 배우고 싶어 하는 주제나 특정한 분야를 정하고 여러 사람과 함께 그룹을 만들어 토론하며 함께 공부하는 것이다. 혼자 하는 것보다 더 효율적이고 지속성 있게 공부할 수 있을 것이다. 스터디에서는 서로 생각하지 못했던 부분을 공유하고 잘 이해되지 않는 부분을 서로에게 피드백을 준다. 배우고자 하는 선의의 경쟁은 공부에 큰 도움이 된다는 면에서 토론을 하여 공부하는 것은 큰 도움이 된다.

특정 분야에 대한 책이나 발표자료, 기사, 기타 자료 등을 찾아보고 배움의 가치가 있다고 판단되면 여러 사람과 함께 스터디를 시작하자. 이 때 중요한 것이 토론이다. 대부분의 한국사람들은 함께 공부하는 것에 초점을 맞추지만 토론을 통해 얻을 수 있는 지식들이 더 많고 기억에 오래남는다.

■ Diagram (다이어그램)

2. 통찰의 풀 (POOL OF INSIGHT)**

혼자서 모든 지식과 정보를 이해하고 습득하는 것은 불가능하다.

사람마다 다양한 공부법과 독서 법이 존재한다. 앞서 깊이 있는 지식을 얻기 위해서는 스터디 그룹을 만들어야 한다고 하였다.

가장 중요한 방법은 토론이다. 대화를 통해 다른 사람들은 어떻게 생각하는지, 어떤 부분에서 혼란스러워 하는지를 알 수 있게 해준다. 또한 새로운 아이디어를 생각하면서 미처 알지 못했던 것을 다른 사람을 통해서 알 수 있게 해준다. David Bohm은 토론을 이용하면 주제에 대한 활력과 열정을 유지시키고 스터디 그룹의 정신을 지속시킬 수 있다고 말했다.

잘 이해가 되지 않는 부분은 토론을 진행하고, 도중에 다른 사람이 말하는 내용에 대해 잘 이해가 되지 않는 부분이 있다면 즉각적으로 말하고 이해하도록 하는 것이 좋다. 혹시 자신이 정확히 이해하지 못했다고 해서 부끄러워하지 말고 바로 공유하도록 하자. 다른 사람도 자신을 통해 미처 생각하지 못했던 것을 깨달을 수 있다. 토론에 대한 적극적인 자세가 유익한 스터디 그룹을 만들게 된다. 또한 한번 결석하기 시작하면 장기결석으로 이어질 가능성이 매우 높기 때문에 결석은 지양하도록 하자.

토론을 진행하고, 결석을 하지 않도록 하기 위해서는 집중할 수 있는 공간이 필요하고, 좋은 분위기가 마련되어야 한다. 이는 3번 패턴에서 소개한다. 또한 분위기는 6. 누구에게나 편안한 장소, 7. 공공의 거실 부분을 참고하면 도움이 될 것이다. 그 외에 의욕적인 사회자와(11), 준비된 참가자(13)가 구성원이라면 토론이 잘 이루어 질 것이다.

■ Diagram

3. 집중할 수 있는 분위기(SAFE PLACE)**

(6번, 7번 패턴을 만족하는)좋은 장소를 갖추더라도 집중을 하기 위해서는 분위기가 형성되어야 한다.

도서관이 커피전문점처럼 시끄럽다면 집중할 수 없어서 스터디가 제대로 진행되지 않을 것이다. 장소뿐만 아니라 토론을 진행함에 있어 구성원들의 태도나 분위기도 스터디를 원활하게 이끄는데 중요하다. 누군가 목소리를 높인다거나, 자기자랑만을 늘어놓으면서 거만한 태도를 보인다면 어떻게 될까? 아마 서로가 불쾌감을 느끼고 질문도 하지 않게 될 것이고, 집중력도 현저히 떨어질 것이다. 이런 상황은 주위 스터디에서 흔히 일어나며, 대부분이 한번쯤 경험해 보았을 것이다. 아무리 똑똑한 사람들이 모였다 하더라도 장소와 분위기가 적합하지 않다면 좋은 스터디 그룹이라 할 수 없을 것 이다.

따뜻하고 편안한, 집중을 할 수 있는 분위기를 조성해야 한다. 또한 질문을 장려하고 서로에게 편안한 마음으로 생각할 수 있는 분위기를 만드는 것도 중요하다. 만약 독자 여러분이 토론을 진행하는 사회자라면 아무리 바보 같은 질문이 나오더라도 친절하고 성의 있게 답해 편안한 분위기를 유도해가도록 해야 한다. 사람들 스스로가 꺼리낌 없이 오해했던 부분이나 모호한 이해해 대해 드러낼 수 있는 환경을 만들고, 따뜻한 목소리 톤과 예의 바른 어조를 유지한다면 훌륭한 스터디가 될 것이다.

사람들이 이해가 되지 않는 부분을 드러낼 수 있을 때 실제 학습의 효과가 나타난다.  단지 공부하기 위해 모였다면 혼자 공부하는 것이 더 도움이 될 것이다. 편안한 분위기를 만드는 것을 강조했지만 여러 사람이 있는 곳에는 갈등이 생겨나기 쉽다. 이런 문제를 방지하기 위해서는 스터디 후 모임(21) 패턴을 참고하여 편안한 분위기를 조성하도록 하자.

■ Diagram

4. 지속적인 에너지 (Enduring Energy)**

 스터디 그룹을 오래 지속하기 위해서는 어떻게 해야 할까?

스터디 그룹을 시작하는 것은 쉽지만 모든 사람들이 지속적인 열정을 가지고 활발히 토론 할 수 있는 분위기를 유지하는 것은 쉽지 않은 일이다. 만약 스터디 리더의 지식이 짧거나 개인적인 홍보에 중점을 두고 스터디를 진행한다면 그 모임의 수명은 짧아질 수 밖에 없다.

초기 스터디를 이끄는 힘은 창단멤버로부터 나온다. 열정적인 창시자가 없다면 열정적인 스터디도 없다. 창시자는 스터디를 번성하게 하겠다는 강력한 의지와 배우고자 하는 열정이 있어야 한다. 스터디를 한다는 것은 단지 공부만 하는 것이 아니라 언제, 어디서, 얼마나 자주, 몇 시간을 할 것인지, 등 고려해야 할 사항이 너무나 많다. 원문에서 제안하는 방법은 격주나 일주일에 2시간 정도씩 모든 사람이 좋아하는 장소에서 깊이 있는 주제를 갖고 진행하는 것이다.

이상적인 환경은 누구에게나 편안한 장소(6)와 공공의 거실(7)을 갖춘 장소이다. 서브그룹(18)과 스터디 사이클(19)을 그룹의 성향에 맞게 잘 조절하고, 기록을 충실히 한다면(20) 오래 지속할 수 있게 된다. 스터디 후 모임(21)을 통해 사람들과의 교류를 장려하는 것 또한 매우 중요하다.

스터디를 하며 구성원 들이 지쳐 하거나 집중력이 떨어진 기색을 보인다면 평소보다 일찍 끝내는 것이 좋다.

■ Diagram

5. 마음 맞는 사람들 (KINDRED COLLABORATORS)*

스터디가 꾸준히 진행된다면(4번 패턴) 함께한 사람들은 소중한 인맥이 될 수 있다.

한국에는 유달리 학연, 지연, 혈연 등 다양한 인맥이 존재한다. 대부분의 사람들이 인맥 때문에 자신들이 받는 피해에 대해서는 싫어하지만 인맥이 있다면 훌륭하게 성장할 수 있고, 도움이 된다는 점은 인정하고 있다. 그렇다면 올바른 인맥 형성은 어떻게 이루어 지는 것 일까?

만약 독자 여러분이 직장인이라면 대부분이 회사에서 자신이 성장하고 있다는 느낌을 받고 있지 않을 것이다. 그 이유는 정말로 자기가 하고 싶은 일보다는 (회사에서 시키는)맡은 일을 수행하다 보니 그 일에 관해서 혹은 자신이 공부하고 싶은 일에 관해서 함께 나누고 공부할 수 있는 기회를 얻지 못 하기 때문이다. 대부분의 시간을 보내는 회사에서 마음을 나눌 수 있는 인맥이 형성되지 못한다면 이를 해결하기 위한 방법을 생각해 보아야 할 것이다.

사무적인 관계에서 벗어나는 가장 좋은 방법이 스터디이다. 정기적으로 만나고 공부하는 스터디가 있다면 좋다. 스터디 그룹은 지식과 아이디어를 제공해 줄 뿐만 아니라 여러분의 커리어를 강화시키고 더욱 강력한 인적 네트워크를 형성할 수 있을 것이다.

예를 들어 모바일 어플리케이션을 만드는 회사라면 팀 내에 기획, 설계, 디자인, UI, 개발 등 다양한 분야의 사람들이 함께 일하고 있을 것 이다. 하지만 보통 서로의 분야에 대해 잘 모르기 때문에 서로 소통하기 힘들다. 이 때 공통의 목표를 갖고 스터디가 이루어 진다면 사무적인 관계를 벗어나 좀 더 친밀한 관계를 형성 할 수 있으며 서로의 발전에도 도움이 된다.

지나치게 큰 스터디는 사람들의 친밀도를 낮출 수 있다. 적당한 인원수의 스터디로 시작하는 것이 좋다. 단순히 지식만을 위하기 보다는 다른 사람들의 관심은 무엇인지, 주말에는 무엇을 하고 어디 가는 것을 좋아하는지를 공유하면 더욱 도움이 될 것이다.

 좋은 교류는 집중할 수 있는 분위기(3)와 다양한 성향을 가진 비슷한 연배의 사람들이 모이면 더 잘 이루어진다. 친해지기 좋은 시간은 스터디 전이나 이후(21) 시간이다.

 ■ Diagram

Sprit 파트를 맺으며..

마지막으로 맴버십 후배라는 이유만으로 묵묵히 이 길을 따라와준 4 후배에게 감사를 드리며, 감사의 의미로 장본인들의 사진을 올리고자 합니다.

왼쪽부터 채경훈, 장성환, 김민수, 이원희 입니다.  앞으로 남아있는 3카데고리 역시 이  이 친구들의 노력의 산물입니다. 물론 Joshua Kerivsky님이 없으면 이 자료는 없었지만요.  한국인들을 위해 공유해준 이 4친구도 충분히 칭찬 받아야 합니다.  저 역시 누군가에게 성장할 기회를 주고, 기쁨을 줄수 있어서 너무 행복합니다.

Filed under: Alexandar, News, Pattern, People, Software Engineering, Study Tagged: ENDURING ENERGY, 김민수, 이원희, 장성환, 채경훈, Joshua Kerievsky, KINDRED COLLABORATORS, KNOWLEDGE HYDRANT, POOL OF INSIGHT, SAFE PLACE, Sprit ]]> http://arload.wordpress.com/2011/10/12/studygroup-pattern-languages-sprit/feed/ 0 arload