* 괜찮은 오픈 API 제공하기 + VLAAH API 소개 - 홍민희
* 봄싹 싸이트(http://springsprout.org) 개발 협업 방법 및 사용 기술 - 백기선
* 코드 품질 포탈 SONAR 적용기 - 고경철
* 흑백무성영화한편! (HTTP) - 이동욱
* 자바스크립트 삽질(실수?) 베스트 10 - 장동수
* (Startup기업 CEO의 관점에서 본) 기술의 경제학 - 정지웅
* Realtime Web 간보기 - 김석준
* Spring Framework with JavaFX - 이승철
* 추상 계층의 딜레마 - 황대산
* timelog 업무 적용 실험기 - 송승렬
Pecha Kucha 형식이 상당히 흥미로워서 도전해보려던 때가 있었다. 기회비용에 의해(생업 탓에) 실행에 옮기지는 못했다. 개발자들의 수다에 참석했을 때 경험이 Pecha Kucha 에 관심을 갖게 된 계기다. 못갔던 행사 후기에 실린 사진만 봐도 대강의 분위기를 알 수 있지 않을까?
다이어그램 바탕색 지정 Tools > Options... (Ctrl+F9) 한 후에 Standard Colors 그룹에서 Paper 색상을 바꾼다.
상속받은 속성 표시하기
클래스 선택후 오른쪽 마우스 > Feature Visibility
대화창이 뜨면 Show Attributes 옵션을 선택한다.
소스코드에 링크 걸린 클래스 가져오기
타이틀이 어색하다. 로즈에서 relocate였던가. 하는 기능인데 context menu에서 Advanced > Convert Linked Element to Local Copy 명령으로 접근할 수 있다. 리버스 하여 얻은 클래스와 외부 소스 사이의 연계를 끊는 것이다. 아쉬운 점은 여러 클래스를 동시에 선택하고 실행할 수 없다는 점과, hot keys를 지정하려고 해도 메뉴가 나타나지 않는다는 점이다. @@
시퀀스 다이어그램 기능
EA에서 시퀀스 다이어그램을 작성하다가 놀라운 기능을 발견했다.
시퀀스를 작성하다 보면 중첩 호출을 표현할 때 섬세한 마우스질을 요구했다. 그런데, EA에는 activation level을 높였다 내렸다 할 수 있는 버튼이 만들어졌다. 호~
(4/22 22:00 추가)
UML 2.1의 Interaction Use지원 > Interaction Occurence 요소
스펙에서는 InteractionUse는 상호작용(interaction)에 대한 참조를 의미한다.
EA에서는 Interaction Occurence로 표시한다. 사용법은 기존의 상호작용도(Interaction diagram)를 D&D 하면 된다.
Rose에서는 노트를 만들고, 그 위에 다이어그램을 떨어뜨려서 링크를 만들었는데. 다이어그램에서 중복을 제거하고 가독성을 높이는데 용이하다. 프로그램에서 공통 함수 빼내는 것과 같다.
노트 연결 제약 사항
노트 링크가 걸리는 UML 요소가 제약이 있어 불편하다. 시퀀스 작성할 때 메시지에 연결이 불가능해 노트와 메시지의 색을 맞춰주거나 하는 방법을 동원해야 한다.
UML2 Nesting connector
선 그릴 때 헷갈리기 쉬운 것이 방향성. UML2에서 포함관계를 표현하는 nesting connector는 포함하는 애가 뭔가(?) 쥐고 있다.
그림 출처: http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_packagediagram.html
프레임없는 이미지 복사
EA에서 그림 복사하거나 이미지 저장할 때 다이어그램 이름 앞에 cd와 같은 접두어가 붙어 보기 싫었는데... 옵션을 발견했다.
패키지와 다이어그램 위치 이동 Hack
EA에서는 Project Browser에 나타나는 순서를 변경할 수 있는 것이 매우 편리하다. 그런데 버그인지 패키지와 다이어그램 사이의 순서 이동이 안되는 경우가 있다.
그림과 같은 경우 모니터링 패키지 아래 구성요소라는 패키지를 다이어그램 아래로 보내고 싶다. EA 7.1(Build 729)을 기준으로 패키지를 아래로, 인접한 다이어그램을 위로 하는 것이 안된다. 이 때, 인접한 다이어그램이 아닌 그 아래 다이어그램을 위로 올리면 다이어그램 전체가 패키지 위로 이동하는 핵(?)을 찾았다. 그렇다면, 다이어그램이 하나면 어떻게 할까? 구성요소 패키지를 다른 곳으로 옮겼다가 가져오면 된다. :)
파워포인트 2007로 작업한 것을 2003 호환으로 저장을 해도 이미지가 회색 음영만으로 보인다. 모든 이미지가 그런 것은 아니다. 이유가 무얼까? 차이를 확인해보니 클립보드에 올린 것을 붙여넣은 경우에 한해서 이런 문제가 생겼다. 해결책은? 번거롭지만 서식복사를 통해 해결할 수 있다.
파워포인트2007을 기준으로 하면, (1) 원하는 서식을 적용한 도형을 선택하고 아래 그림과 같이 (2)서식 복사 아이콘을 클릭합니다. 커서 모양이 바뀌는데 이 때 (3) 서식을 바꾸고 싶은 도형을 찍어주면 됩니다. 서식 아이콘 클릭할 때 여러 도형에 적용하려면 두 번 클릭해야 합니다.
대식가 홍일동이라는 범상치 않은(?) 일화로 시작하는 이 책은, 화보같은 만화책이다. 이두호씨는 이 만화에서 다양한 재료와 기법이 주는 맛을 표현하고자 했다고 한다.[각주:1] 만화는 짧막한 일화의 모음인데, 아크릴 물감, 수채 물감, 색연필, 컴퓨터(페인터), 파스텔 등을 사용해서 표현했다. 같은 도구를 쓰는 경우에도 켄트지, 캔버스, 화선지, 만화용지를 비롯해 이름도 생소한 와트만지, 드래프트지를 조합하여 단편 모두가 만화 내용뿐 아니라 그림에 있어서도 새로운 맛을 전해준다.
처음 책을 잡고서는 흥미로운 이야기에 끌렸고, 그림의 맛을 보기 시작하면서 장인정신[각주:2]이 떠올라 숙연함을 느꼈다. 이렇게 정성들여 만들어진 책을 너무 빨리 읽어버리려는게 아닌가 하고 내용 보기를 멈추고 붓 터치나 색감, 질감을 잠시 감상하기도 했다. 하지만, 그림보는 눈이 확 높아지지는 않는다. 두고두고 읽을꺼리가 없어 다시 펼쳐보지는 않겠지만, 드물게 소장하고 싶은 마음이 드는 명작feel의 만화다.
1. 모델 형상관리 베스트 프랙티스 EA의 버전 관리 지원은 수준급이라고 하지만 모델링 도구 안에서 형상관리 기능을 연계하는 것은 별도의 svn 클라이언트를 쓰는 것보다 편하지 않다. 가령 한 작업자가 EA로 작업후 해당 모델을 Check-in 하지 않고 퇴근했다면 다른 사람을 lock으로 작업을 할 수 없다. [각주:1] 단순히 UML 모델만 관리한다면 EA 툴에서 형상관리하는 것도 큰 문제는 없다. 그러나, 대개의 경우 오피스 문서 등과 혼용해서 모델을 쓰는 것이 효과를 발휘한다. 또는 소스코드나 이미지에 링크를 걸어 보기도 한다. 이러한 경우라면, svn 클라이언트 프로그램을 사용하고 EA 내부의 패키지 단위가 아닌 윈도 파일 단위로 관리하는 것이 더 좋다.
2. lock 풀기(TortoiseSVN)
쉘 화면에서 TortoiseSVN > Check for modifications 명령을 선택한다. lock 걸린 파일을 선택하고, Break lock 명령을 실행한다.
3. 형상관리 제약사항/모델 이동
Rose 이후의 주류 모델링 도구들이 너무나 불편해서, 90년대 후반에 나온 Rose에 대략은 기능 보강을 한 정도인 EA에 대해서 지나치게 호평만 했다. 특히, EA의 버전 관리 지원은 수준급에서는 RSA의 형상관리 문제에 비교해 훌륭하다고 한 것인데 실전에서는 역시 문제가 발생했다.
XML로 저장하는 일반 모델 파일의 형상관리는 OK이다. 마지막 작업자가 체크인(Check in)을 안하면 다음 작업자가
모델링을 못하는 File-lock 방식에 불평을 하는 팀원도 있었지만, 모델링은 Optimistic lock보다는 File
lock(Pessimitic lock) 방식이 좋다. CVS/SVN에 익숙한 개발자가 File lock기반의 VSS가 불편하다고
하는 것처럼, VSS에 익숙한 개발자들만 있는 곳에서 CVS의 Optimistic lock을 심하게 불평하는 경우도
있다.(CVS를 실제 프로젝트에서는 못쓴다고..ㅡㅡ;)
EA로 형상관리할 때 진짜 문제는 코드와 모델을 싱크한 경우에 발생했다. EA에서는 XML 단위로 모델만 형상관리하지만, 코드
전체가 XML로 저장할 이유는 없다. 확실치 않지만 참조 형태로 연결하는 것 같은데, 이를 CI/CO할 때 시스템 자원을 많이
썼고, SVN에 이를 넣다가 한 PC가 죽어 버리자 Integrity가 깨져서... 스프링 내부 메커니즘 교육용으로 이틀에 걸쳐
수 시간을 쏟은 그림이 사실상 백지로 변했다.
이렇게... 젠장.. 노트만 남았다. 결론, 리버스 하여 코드와 연결시킨 모델의 경우는 윈도우에서 SVN/CVS/VSS 등을 이용해서 형상관리 하거나 형상관리를 끊은 상태에서 백업을 잘 해두자. ㅡㅡ;
코드와 모델을 동기화 하는 것은 대규모 프로젝트에서는 권장할 수 없는 방식이다. 메커니즘 분석을 위해서나 솔루션 개발팀에서 고려할만한 일이다. 보편적인 SI 환경에서는 모델과 코드를 동기화 하는 것이 득보다 실이 많다.
또 하나 EA의 불편함은 CI/CO만 있고, Update를 못한다는 사실이다. 모델과 코드 사이의 싱크를 유지하지 않는다면 형상관리 불편함은 크게 준다. 모델-코드 동기화는 팀 작업시 생산성 관점에서는 악의 축이 되는 일이 비근하다. 규모가 있는 프로젝트면 장점보다 단점이 많다.
리버스를 이용해서 다이어그램을 작성하고 난 이후에 객체를 로컬화 하는 방법으로 모델에 포함시킬 수 있다. Advanced > Convert Linked Element to Local Copy 명령이다. Rose의 Relocate와 유사한데.. 아쉽게도 단축키가 없고, 여러 객체 혹은 심볼에 동시 적용할 수가 없다.
어떻게 엔터프라이즈 소프트웨어에 맞는 Spring (재사용 컴포넌트와 강력한 설정을 지향)와 Groovy/Grails 습성
(단순함, CoC와 플러그인)이 상호작용할 수 있는가? 확실히 있지만, 과연 두 접근방식에서 배출점 그리고 서로 통합하는 최선안은 무얼까?
Grails에서 널리 쓰이는 CoC(convention over configuration)의 한계는?
자바 개발자를 위한 친절한 소개자료가 있는가? Java/Spring/Hibernate 세계에서 Groovy/Grails 세계로 인도할 트랙이 있다면 무척 흥미로울 것이다. 기존 애플리케이션에 GSP 같은 것을 추가하고, groovy Controllers 와 URL 매핑을 기존 Spring Services와 혼용하고 일부 Spring-based Groovy beans 와 GORM을 쓰는 식일까? 프레임워크 전체를 변경하는 것보다 일부만 바꿀 수 있다면 훨씬 좋을 것이다.
Spring 3.0 - 나는 REST 지원을 비롯해서 3.0 출시 이후 가지고 놀 수 있는 빛나는 장난감 모두를 다룰 필요가 있다.
JDK 1.4 제거라는 것이 Spring API를 의미하는 가? 아니면 설마 내 API까지?
WebFlow가 단순해졌고, "어떠한 마법사 형태 애플리케이션에서도 사용이 가능하다." Spring Source는 Spring Web MVC, WebFlow,
Spring JS를 통합했다.
Rod: "예산에 대한 제약은 복잡도 감소로 발생하는 생산성 강화를 요구할 것이다... Spring 과 Tomcat이 쓰이지 않는 이유는 벤더와 CIO가 골프를 즐기기 때문이다."
Rod Johnson 생산성 증명을 위해 Spring Pet Clinic 예제의 코드량 감소(Spring 2.0 에서 애노테이션을 사용한 2.5 로 변경)를 보여줬다.
기본적으로 Open Source Software는 어려운 시기에도 역할을 잘 해낼 것이다. OSS가 비단 무료라서가 아니라 더 높은 생산성을 제공하기 때문이다.
내가 궁긍한 것은 새롭고 단순해진 EJB 표준과 Spring's approach 비교다. 공정한 코드량 비교가 하나의 방법이 될 것이다.
벤더로 자리매김한 SpringSource에 대해
내 생각에 Spring TC 는 SpringSource와 Tomcat 을 엄청나게 개선할 것 같다. 나는 이 사실이 무척이나 즐겁다. 바라건데 고객들이 기존 WAS 대신 Spring TC + AMS 선택하는 것을 심각하게 고려해주면 좋겠다.
SpringSource은 자사 툴이 경쟁제품보다 났다는 점을 입증해야 한다. 내가 보기엔 스프링 프레임웍을 다른 상업용 툴과 연계하려고 하려고 시도 하는 것처럼 보이는데 - 충분히 말이 된다고 생각한다 -
이는 "스프링 프레임웍이 시장에서 잘 해나가고 있고 그에 따라 스프링 프레임웍 기반의 벤더들 상품도 잘 해나가고 있다" 라는
말의 의미를 희석시킬지도 모른다. 나는 계속해서 지켜볼 생각이다. 하지만 큰 문제가 될 것 같지는 않다.
Spring Source TC 서버 - 더 나은 운영 지원과 mission critical support를 추가한 Tomcat. Tomcat의 가장 큰 이슈는 클러스터링과 관리인데 SpringSource가 이를 바꿔가고 있다.
놀라운 일이다. 진심으로 기존 WAS 대치가 일어났으면 한다. WAS가 좀 더 싸고 사용하기 편해져야 한다. J2EE WorkManagers 등이 제공하는 기능 들도 유용하지만, 기존 WAS 최대 장점은 운영(기술)지원팀이다.
오랜만에 블로그 유입 경로를 보다가 그다지 흥미롭지 않은 사실을 발견했다. 먼저 한 가지는 DNA lens에서 내 글을 완전히 지워버렸다는 사실.. 아래 순위에서 보듯이 유입 경로 7위가 DNA 였는데...
Daum DNA에서 lens 라는 RSS 모음 페이지를 보니, 내 RSS가 사라진 것 뿐만이 아니라 기존 링크까지 DB에서 모두 제거했다. 애초부터 허락을 구하고 링크한 것도 아니니 마음대로 거둘 수 있은 일이지만, 왠지 찜찜한 마음이 들었다.
그리고, 또 얼마전 일민형 글에 토를 달았던 사람이 내 글에 대해서 악담을 퍼부었다. 순간 짜증이 나긴 했지만, 글의 수준이 사춘기때 방황을 담은 것 같아 대응은 않기로 했다.
이런 사실들이 고맙게도 지나간 내 과오를 돌아보게했다. 그리고 물의를 일으켰던 글에 대해 관계된 사람들에게 사과를 하고 글을 내렸다. 돌아보면 올해도 참 나쁜 짓을 많이 했다. 잠깐 이런 마음을 품었다가도 내년에 또 나쁜 짓을 하겠지만... 한 번 반성할꺼 두 번 하면 언젠가는 더 나아지겠지.
개인의 생산성 향상을 위해 IDE를 잘 쓰는 것은 매우 중요한 일이다. 그런 면에서 아직도 이클립스에 익숙하지 않은 분이라면 좋을 기사일 수 있다. 나 역시 이클립스 2.x 까지는 대충 직관적으로 사용했다. 그런데 리팩토링 기능이 대폭 강화된 3.x 버전에서는 매번 새 버전이 나올 때마다 시간을 내서 새로운 기능들을 배우곤 한다.
위 글에선 단지 v3.4 에 추가된 것 뿐 아니라 종합적으로 가이드하고 있다. 기본 기능을 학습한 이후에는 단연 단축키에 눈이 간다. 3.3 이후에 추가된 단축키 중에 최고는 Ctrl+3이다. 기사에서 소개한 단축키 바꾸기를 잘 활용하면 이클립스에서 기본적으로는 지원하는 나만의 단축키를 얼마든지 정의할 수 있다.
금융권 시스템에서는 필수적인 기능이라 우리팀에서도 유사하 기능을 구현했다. 슬쩍 살펴보니 공수 차이가 있는 만큼 기능면에서야 차이가 있지만, 기본적으로 하는 역할을 유사하다. 그럼에도 불구하고 사용하는 용어, 기반 UI 플랫폼, 세부적인 메커니즘에서 차이가 있었다. 시간을 내서 우리 팀 개발자와 함께 살펴볼만한 가치가 있는 좋은 글이다. 앞으로도 Open dW 에 이러한 실무적인 글이 자주 올라오길 기대해본다. 아니 무작정 기다리기 보단 우리 팀원들에게도 실무적인 글을 쓰게 하고 기고를 하게 해야겠다. :)
만일 여러분이 복잡한 절차를 간략히 요약하여 2페이지 남짓의 워드로 만들었다고 해보자. 작업의 순서와 판단에 따른 분기 등의 정보를 집약해서 표현하거나 추상화/개념화 하기 위해 도식화를 한다. 그런데 만약 다음과 같은 그림을 그렸다면...
나는 이 그림을 보고 '전용면적이 좁은 아파트' 혹은 '터무니 없이 큰 베란다' 같은 것이 떠올랐다. 차라리 도식화를 하지 않고, 행위를 표현한 글이 폰트를 7, 8 배 키운 후 앞에 순번을 다는 것이 같은 공간을 쓰면서 훨씬 더 정보를 잘 표현하는 방법일 것이다. 그림의 50%를 넘는 여백은 ... 무언가 채워지기 전까지 주차장으로 써야 할까 :)
SpringSource의 CEO인 Rod Johnson의 첫 번째 keynote는 자사의 태그라인인 ‘Weapons for the War on Java Complexity TM’전략에 기반한 SpringSource의 2008년 성과와 2009년에 대한 전망을 발표하였고, 이를 실현할 주요 기술 현황과 발전 방향에 대해 설명했고, 핵심 기술에 대해서는 데모 시연을 했다. 개략의 내용은 다음과 같이 요약할 수 있다.
- SpringSource의 2008년 성과
Spring Web Flow 2.0 출시(flow가 있는 업무 화면 개발 지원 프레임워크)
Spring Batch 출시(Accenture 주도의 대용량 배치 runtime 솔루션)
Spring Integration 프로젝트 개시(Message 기반 채널 연계 솔루션)
Spring 3.0 개발 (2009년 1/4 분기 출시 예정)
SpringSource dm Server 출시(OSGi 기반 차세대 서버 제품)
Covalent Technologies 인수(Apache 웹 서버 및 Tomcat 개발 및 기술 지원 업체)
G2One 인수(오픈소스 프로젝트Groovy/Grails 개발 및 기술 지원 업체)
상용 제품 출시: SpringSource Tool Suite, SpringSource Application Management Suite, SpringSource Advanced Pack for Oracle.
- Rod Johnson은 2008년 불어 닥친 세계 경기 악화가 IT 예산에 대한 압박으로 라이선스 비용에 대해서는 보다 엄격해질 것이고, 복잡도에서 유발하는 비용을 줄이기 위한 투자는 늘어날 것으로 전망했다. ‘Weapons for the War on Java Complexity TM’를 태그라인으로 건 SpringSource의 대응책에 대해서는 Spring 관련 오픈소스 및 상용 제품에 대한 소개로 대신했다.
- 복잡도를 줄이겠다는 SprngSource의 전략을 실현한 제품으로 G2One 인수를 통해 Grails 개발속도가 빨라진다는 점과 함께 Spring 3.0의 성과에 대해 소개했다. Spring 3.0의 주요 내용은 다음과 같다.
XML 설정에 EL(Expression Language) 지원(XML 설정 가변성 반영)
Spring Web MVC 에서 RESTful Web services 지원(SOAP 기반 web services 복잡도 제거)
Annotations를 수용하여 Spring Web MVC가 제공하는 Controller 계층을 POJO로 대치하고, XML 설정 필요성 제거(Presentation Layer 코드 량 감소)
Flow 제어가 필요한 웹 화면 용도로만 쓰이던 Spring Web Flow 기능 보강으로 ‘back 버튼’, ‘새로 고침’, ‘마법사’, ‘포탈 스타일 UI’ 구현 등의 복잡도 줄임
Spring Web MVC를 기반으로 하여 Spring JavaScript, Spring Web Flow와 함께 Spring Faces 등을 통해 웹 개발의 복잡도를 혁신적으로 개선할 것임을 시사
- 10년간 Apache 서버 제품을 개발하고 지원해온 Covalent 인수 이후 SpringSource는 SpringSource dm Server를 출시했고, Rod Johnson의 keynote를 통해 최초로 두 개 제품을 소개했다.
tc Sever: Tomcat 서버를 엔터프라이즈 환경의 데이터센터에서 쓸 수 있도록 모니터링, 진달, 관리 기능을 강화한 제품을 내년 1월 중순 출시한다. 리서치 업체 Evans Data의 조사에 따르면 전세계 자바 개발의 70%는 Tomcat 기반으로 이뤄지며, SpringSource 직원들이 지난 2년간 Tomcat 버그 수정의 95%, 기능 추가의 83%를 담당했다고 한다.
SpringSource Application Platform Configurator: war 파일, Spring batch 기반 애플리케이션, Grails 애플리케이션에 대해 주요 OS 및 WAS 등에 웹 기반으로 쉽게 배포할 수 있는 도구이며, 프로토타입 시연이 있었지만 출시 계획은 발표하지 않았다.
InfoQ에 요약성격의 글이 있어서 나도 따라 정리 좀 해본다. Scott Delap의 글을 앵커로 출발해보자면 모든 것을 포괄하기에는 다소 부족하다.무엇보다 Grails에 대한 감동이 없다는 것이 아쉽다. :) tc 서버에 대해서는 이미 KSUG에 글을 쓴 바 있어 넘어가려다가 eWeek의 보도나 SpringSource의 기사에서 다음 내용은 눈에 띄어 정리해본다.
우선 tc 서버의 기능 목록이다.
Application management
List applications running in a distributed collection of server instances
Target, deploy and undeploy applications to distributed server instance
Start, stop and reload applications running for distributed server instances
Control web application parameters like caching, JSP behavior, and serving of static content
Server management
Remote configuration control for server instances:
Configure JDBC Data Sources and connection pools
Define virtual hosts, access logs and integration with web servers
Configure JVM server start parameters like Java heap size and garbage collection characteristics
Define server groups (tc Server or Tomcat instances)
Advanced server diagnostics
Application
thread lock detection provides warnings when threads compete for
restricted resources in a way that would compromise application
integrity
Configurable automatic and on-demand thread and heap dumping for failure and exception analysis
Thread to URL association for faster diagnosis when analyzing problems with request processing
Enterprise support
To minimize downtime, SpringSource provides mission critical enterprise support.
More
than 400 of the world’s largest organizations count on SpringSource to
support their mission-critical tc Server and Tomcat infrastructure.
Over
80% of Tomcat commits in the last two years were made by SpringSource
employees and with our leading Tomcat committers, SpringSource can
rapidly address support incidents and commit bug fixes to Tomcat
1월에 tc Server가 출시되면 각각의 기능(Feature)이 실제로 어떻게 구현되었고, 어떠한 UI나 품질을 갖는지 확인하는데 체크리스트로 쓸만하다.
그리고 Evans Data의 연구에 따르면 조사에 응한 사람의 70%가 Tomcat을 사용하며, SpringSource의 직원이 톰캣 개발(commits)의 83%를 담당하며, 96%의 버그 픽스를 담당했고, 그 결과 톰캣 지원을 받는 고객의 97%는 계약을 갱신했다고 한다. 아래는 인증 샷.
SpringSource의 놀라운 톰캣 개발/지원 능력은 지난 2008년 1월의 Covalent 인수에서 기인한다. Covalent 가 어떤 기업이냐? 아래 간단한 요약이 있다.
Covalent Technologies, founded in 1998, provides services and support
for Apache Software Foundation (ASF) projects, namely the Apache Tomcat
Application Server, Apache Geronimo Application Server, Apache Axis Web
Services Framework, Apache Roller Blog Server, Apache ActiveMQ Message
Broker, and Apache HTTP. Covalent CEO Mark Brewer joins the
SpringSource management team as vice president and general manager of
SpringSource's new Covalent business unit. The financial details of the
transaction are not being disclosed by either company.
* Poor English version (In spite of my lack of English-skills, I write this post to share my inspiration triggered by Adrian's keynote. This is my first English post ever.)
As Toby expected, Adrian's keynote is very impressive and beyond my expectations. It is beginning with a comedy for Spring guys. Very interesting, but it's not the reason why I'm fascinated by Adrian's keynote. After the funny time, Adrian is explaining the Spring Integration sample application which was not much referred at Rod Johnson's keynote. He is illustrating a sample in the Spring Integration project esay. And then he demonstrates Grails application development. At first I can't see the reason why he show the demo-I showed the better demo at the Grails sesseion before. However, as he is finishing the web application to order coffee, I am realizing what I see and supprised at that. In the end of the demo I understand why my friend Toby expected the show, since I see the deploy process to the dm server. And, I know the phrase, "Grails is Spring" means beyond that Grails give the spring user another choice in terms of programming model. In the demo, not only the boundary between Spring and Grails is faint but also the discrimination is trivial. Grails is really Spring! Rod johnson make Adrian explain the differentating benefits of Grails,reusing the assets made by Java and Spring without efforts, against JRuby on Rails by asking a question.
Later on, he explains the vision, current status and future roadmap about dm server with Rob Harrop. Because it's their company's key area, they describe from the meaning of OSGi to issues on dm server in details. A final announcement is the partnership with VMWare. Wow~ I am full of admiration by the plot. If the company will succeed, dm Server and VMWare resolve the problems of deploying and administraing the enterprise systems.
After the keynote, I think that the picture behind the keynote remind me of Sun's BluePrint in the early EJB era. Now, SpringSource make a blue print for the enterprise computing instead of the former forces, such as Sun. I think "the Spring Way" will be likely to succeed better. In the Spring way, they collect the best-of-breed solution and make them valuable rather make somthing new whether is an oepn source or not. This is my earning for big money to invest to attend at this conference.
토비형 예상처럼 애드리안의 키노트는 매우 인상적이었고, 기대 이상이었다. 시작은 예상대로 스프링 사용자들을 위한 한편의 코메디를 보여줬다. 무척 흥미로운 도입부였지만 이것 때문에 애드리안의 키노트에 반한 것은 아니다. 한바탕 웃고난 후에 의외로 로드 존슨의 키노트에 크게 언급한 바 없는 Spring Integration으로 만든 예제를 열심히 설명했다. 이미 Spring Integration에 있는 예제를 쉽게 설명했다. 그리고는 Grails 데모가 이어졌다. 처음에는 이 데모가 무엇을 의미하는지 한 눈에 알아보지는 못했다. 그런데 커피를 주문하는 웹 애플리케이션이 완성될수록 슬슬 무엇을 보여주고자 하는지 눈치 채고 놀라지 않을 수 없었다. 마지막에 dm server에 간편하게 배포하는 모습을 보면 왜 토비형이 애드리안의 키노트를 기대했는지 공감하게 되었다. 또한, 단순히 사용자에게 프로그래밍 모델에 대한 또 하나의 선택을 준다는 의미에서 "Grails is Spring"이라는 줄만 알았는데 데모를 보니 Grails이 Spring 경계가 모호했고, 사실상 구분이 큰 의미가 없어 보였다. 정말 Grails는 Spring이었다! 로드 존슨이 순발력있게 JRuby on Rails에서도 그것들이 가능한지를 물었다. 자바와 스프링의 자산을 그대로 쓸 수 있는 Grails의 차별성을 단박에 집고 넘어가게 하는 질문이었다.
뒤이어 스프링소스의 핵심적인 사업 영역인 dm Server에 대한 비전, 현재 상황과 로드맵에 대해서 리드 개발자인 롭 해롭과 함께 설명했다. OSGi의 의미부터 시작해서 dm Server에 대한 기술적인 이슈를 차분히 모두 설명해주었지만 세션이 길어져 나가는 이들이 생겼다. 마지막 내용은 스프링소스와 VMWare의 제휴에 대한 공지였다. 와우~ 치밀한 발표 구성에 감탄사가 절로 나온다. 스프링소스의 전략이 성공한다면 VMWare는 dm Server와 역할을 분담하여 엔터프라이즈 환경의 배포와 운영에 대한 문제를 해결해줄 것이다.
세션을 마치고 키노트를 반추해보는데 오늘 애드리안이 보여준 그림은 EJB 초기에 Sun이 보여준 BluePrint와 비슷했다. 복잡함과의 전쟁을 선포한 스프링소스는 이제 Sun으로 대표되는 지난 세력을 대신해 새로운 청사진을 그려가고 있다. 인류가 시행착오를 통해 발전하듯 스프링소스의 방식은 훨씬 더 성공 가능성이 높아보인다. 그들은 새로 시작하려고 하는 것이 아니라, 이미 존재하는 검증된 자산에 기반해서 가치를 키워가고 있다. 그것이 스펙이든, 오픈소스든, 상용제품이든 유용한 것이라면 모두 활용해서. 이것이야 말로 내가 비싼 돈을 들여 이곳에 와서 배워가는 최고의 지혜가 아닌가 싶다.
스프링 진영이 내놓았으니만큼 단순히 새로운 JSF 프레임워크는 아니었다. Spring Faces는 복잡함으로 명성(?)을 쌓아가고 있는 JSF를 보다 가볍게 하기 위해 등장했다. 이를 위해 Spring faces가 해결하려한 내용은
JSF의 복잡한 XML 설정
성능 문제
URL 매핑 제약
Back 버튼 문제
등이다. 한편, 스프링소스의 세션답게 본격적으로 Spring Faces를 다루기 전에 JSF 중심의 접근과 Spring 중심의 접근 차이에 대해 설명했다. JSF 중심 접근은 FacesServlet을 사용하는 방법으로 Spring을 JSF managed bean provider로 사용하는 방법이다. 반면에 스프링 중심의 접근은 FacesServlet을 쓰는 것이 아니라 Spring MVC와 Web Flow를 쓰면서 View 구현체로써 Spring Faces를 사용한다.
여기서 Spring Faces의 장단점이 확연히 보였다. 먼저 스프링 사용자라면 MVC/SWF는 물론 Spring 자바스크립트(주로 dojo 래핑)까지 그대로 사용할 수가 있다. 3.0 까지 고려하면 Spring MVC가 제공하는 RESTful URL을 사용할 수 있고, SWF의 flow 관리 기능을 그대로 사용할 수 있다. Spring JS를 쓰기 때문에 web.xml에 ResourceServlet 설정만으로 정적인 리소스는 보다 효율적으로 쓸 수 있다. 물론 이 기능은 Spring Faces를 쓰지 않아도 사용할 수 있다. Spring faces 고유의 설정은 FaceletViewHandler와 ViewRefreshmentListener 정도다. Keith Donarld가 SWF 발표를 할 때, 실수 연발했던 예제를 데모에 이용했지만 다행히 Jeremy Grelle의 데모는 원활했다. :)
장점만 이야기했는데 단점은 웹쪽에 대해서 즉, 스프링 MVC나 SWF 등을 쓰지 않는 경우에는 학습 비용을 들 수 있다. 발표자가 제공한 자료에서 Spring Faces를 사용했을 때 얻을 수 있는 이점을 잘 정리해서 보여줬다.
[COR(Chain of Responsibility) 패턴은 언제 쓸까? - 난 내일만 해, 나머지는 난 몰라.]
COR(ChainOfResponsibility)이란 몬스터로부터 마법 공격을 받으면, 마법 내성과
방호구 상황에 따라 캐릭터의 HP도 깍이고, 옷, 신발 등 여러 아이템으로 충격이 전달된다. 즉 이벤트 하나가 여러곳으로
전파되어 이벤트에 대해 각 객체들이 반응하게 된다. 이때 아이템 특성에 따라 어떤 아이템은 전혀 반응하지
않는가 하면, 어떤 아이템은 일부 손상되거나 아예 망가져버릴 수도 있다.
게임 진행을 생각해보자. 미션해결을 위해 주위 사람들에게 열심히 물어보다보면 한 곳에서 모든 답을 얻지 못할 때가 많다. 조금 이야기를 한 후 누구에게 더 물어봐라라는 말을 많이 들을 것이다. 게임
속과 마찬가지로 객체 지향 세계에서는 동일한 이벤트 또는 함수 호출에 대해 책임의 범위를 다른 놈에게 계속 전가(?)시키는
상황을 볼 수 있다. 이것을 COR이라 말한다. 판타지 소설에 많이 나오는 장면 중 하나는 주인공이 정보길드와 같은 곳에서 정보를 요구하면, 뒤에 있는 놈들과 수군거리기도 하고, 그들 권한을 넘는 경우에는
관리자들에게 통보된다.
이처럼 화면이나 서버 내의 많은 복합 구성체들에
어떤 이벤트를 던졌을 때 그 각 요소들의 역할만을 수행하고, 역할 범위를 넘은 것은 계속 책임을 전가(COR)시켜가는 것을 COR 패턴이라한다.
[Command 패턴은 언제 쓸까? - 난
여러 마법을 마구 날리는게 째미써, 머씨써...]
게임을 하다보면 멋있는 장면들이 많다. 특히 다수의 적들에게 화려한 마법을 계속 난사하는 것은 마법사만의 짜릿한 특권이기도 하다. 몬스터와의 1:1 대전이라면 객체지향에서 어떤 식으로 구현할지 눈에
선하지만, 다대다의 경우라면 쉽게 감이 안온다.
진짜 객체지향으로 생각할 때가 되었다. 만약 마법공격이라는 객체를 두고, 마법 범위에 들어와있는 여러 몬스터들을
대상으로 지정한다고 하자. 마법공격도 성격이나 범위 등이 다양하기 때문에 하기 때문에 여러 마법을 돌아가면서
난사한다면(이뮨Immune 몬스터때문이라도, 여러 마법을 난사하고 싶은 순간이 있다.) 각 마법 범주에 들어오는
몬스터들을 대상으로 하는 마법공격이라는 객체를 계속 만든다고 하자. 마법이 펼처지는 시간(속도)와 몬스터와의 거리에 따라 순차적으로 마법이 적용되기 시작해야한다. 이런 것을 포함한 복잡한 로직은 마법공격이라는 객체에게 맡기고, 중요한
것은, 마법을 난사한다는 것을 마법공격이라는 명령(Command)을
계속 생성하는 것으로 생각한다는 것이다. 이경우 몬스터도 범위 공격을 할 수 있기 때문에 캐릭터나 몬스터는
상대방에게 직접적인 가해를 가하는 전투방식을 사용할 수도 있지만, 공격을 명령에 담아 날리는 스타일의
전투방식을 사용할 수도 있다.
물론
Command를 어떻게 처리할 것인지도 쉬운 문제는 아니지만, 일단 범위 공격의 난사를
어떤식으로 해결할지를 생각해보았다.
미래의 게임은
Agent를 키우는 것이 재미의 한 몫을 단단히 한다. 잘 키운 에이전트...^^ 이때 Command를 통해
Agent의 움직임을 제어할 수 있다. 허드렛일 모드부터,
가벼운 전투 모드, 낙시질 모드. 이런 것들은 CommandForAgent라는 특별한 Command로 만들어 날리면
된다. Command에 차곡이 쌓인 명령들을 Agent는
착실히 수행해갈 것이다. 물론 위험한 것을 시키면 죽을 확률도 그만큼 클 수밖에 없기 때문에, 제자를 키우는 생각으로 일정 이상으로 크기 전에 하산시켜서는 절대 안된다.
이처럼
Command는 행위를 객체화하고 싶을 때 매우 중요하게 활용할 수 있는 패턴이다.
[Interpreter 패턴은 언제 쓸까? - 난
게임속에서 제자를 키워.]
앞에서 Agent에게
행위를 예약할 때 Command 패턴을 사용하는 것을 보았다. 하지만
구체적으로 들여다보면, 조금 더 상황이 복잡하다는 것을 알게된다.
Agent에게 행위를 예약할 때 쓰는 것은 AGML의 일부인 MLA(Mark-up Language for Agent)이다. 이
것을 활용하면 Agent가 있어야 할 시점(Time), 장소(Place), 행위(Behavior) 등을 지정할 수 있다. 특히 행위를 지정할 때 나타날 상대방 몬스터 종류와 공격력 등을 바탕으로 공격할지, 피해갈지, 아예 도망갈지 등의 로직을 부여할 수 있다. 물론 게이머는 프로그래밍을 한다는 생각 없이, 멋진 화면들을 보면서, 마치 스승이 제자에게 당부하며 일을 시키는 심정으로 마우스를 몇번 클릭하면 된다.
이때 MLA는
매우 간단한 형태이기 때문에 이에 대한 처리는 Interpreter에 의해 해석되고 실행된다. 이처럼 동적인 상황에서 발생되는 규칙(Rule)에 대한 처리는 일반적으로 Interpreter 패턴을 써서 처리할 수 있다.
[Iterator 패턴은 언제 쓸까? - 뺑뺑이는
기본 훈련.]
앞의 모든 경우에 전부 있을 수 있다.
객체지향의 특성 중 하나는 위임이다. 예전에는 관련된 데이터 구조를 주~욱 정의해놓고, 서비스를 수행하기 위한 함수들을 주~욱 정의해놓고 그 함수들은 앞에
정의한 데이터 구조들을 활용해서 프로그래밍을 하였다. 하지만 기본적인 데이터 구조의 변화 또는 데이터구조체의
추가가 발생하면, 관련된 함수들은 모조리 바뀌어야하는 불편함이 있었다.
이 경우 코드 사이즈가 매우 크면 통제하기 힘든 상황이 될 수 밖에 없다. 객체지향은 이런
상황을 근본적으로 해결하기 위해 데이터 구조체와 관련된 함수들은 모두 중복해서 구조체 안에 넣고 클래스라는 단위로 모듈화하였다. 따라서 메인 함수는 상황에 따라 여러 함수를 부르는 것이 아닌, 여러
객체들에 일을 시키는 형태로 바뀐다. 이때 순차적으로 일을 시키는 경우라면 일반적으로 Iterator를 활용한다.
예를 들어 앞에서
COR 패턴에서 필요한 역할들을 순차적으로 처리하거나, 커맨드 패턴에서 마법을 커맨드화한
것들을 순차적으로 처리하거나, 인터프리터 패턴에서 에이전트에 예약해놓았던 명령을 순차적으로 처리할 때
이터레이터 패턴을 사용할 수 있다.
이처럼 이터레이터 패턴은 다른 패턴과는 독립적으로
작용할 수도 있지만, 다른 패턴들과 함께 활용될 때도 많다.
Iterator 패턴만의 활용에 대한 예를 들자. "모든
장비들의 방어능력치를 +1 Upgrade시켜주는 Scroll을
얻어서 이를 사용했다. Iterator는 현재 내가 착용한 모든 장비들을 순차적으로 불러줄 것이고, Scroll은 각 장비들의 방어능력치를 +1 Upgrade 시켜준다."
[Mediator 패턴은 언제 쓸까? - 지역적으로는
떨어져있어도, 우리는 하나.]
팀(파티) 구성의 경우 기본적으로 쌍방향 Sync가 필요하다. 이때 팀당 1개의 Mediator가
있을 수 있다.
Mediator - "집단(마라톤, 자동차
경주, MMORPG의 팀 등)에서 나의 이야기를 다른 사람에게, 다른 사람의 이야기를 나에게 보여줄 때. 나의 모습과 함께 게임하는
상대 모습이 동시에 계속 바뀌어야하는 상황에 각 캐릭터/자동차들을
Colleage로, 경기장을 Mediator로
하면됨." 특히 팀(파티) 구성이 되어있는 경우 쌍방향 Sync가 필요함. 즉 파티당 1개의 Mediator가
각자로부터 보내지는 이벤트(공격, 피해,...)들을 다른 파티 멤버들에게 모두 보냄.
[Memento 패턴은 언제 쓸까? - 죽었던
장소로 죽어라 달려갔던 바바의 기억...]
죽으면 마을 또는 특별히 지정된 장소에서 죽기전의
상태로 부활하는 형태(패널티 유/무)도 있지만, 죽을 때 아이템 등을 찾기 위해서는, 죽었던 장소로 다시 달려가야하는 형태도 있다. 아이템 많았을 때도
죽었는데, 없는 맨몸으로 가면서 또 죽고 죽고... 아 아픈
기억.
예를 들어보자. "게임의
난이도 조절에 따라 Easy Mode에는 강력한 몬스터와 싸울 경우,
경험치는 70%만 얻지만, 죽어도 경험치를 잃지
않는 "DoNotLessonExMode"가 제공된다.
또한 죽기전 갖고 있었던 모든 아이템은 다시 소유한다. 이 모드로 세팅하고 전투하다 죽으면, 죽을 때 상태를 Memento 패턴을 활용해서 저장하고, 다시 부활할 때 미멘토를 활용해서 죽기전 상태를 복원한다." 만약
전투가 어려울 경우 현상태를 기억하고, 죽었을 때 기억을 시킨 상태부터 다시 출발할 수 있는 모드가
있다면, 이 경우에도 Memento를 통해 상태를 관리한다.
사실, 대부분의
게임들이 저장을 지원한다. 새로 게임을 시작한다면 저장해놓은 여러 게임중 원하는 상태에서 다시 시작할
수 있다. 이처럼 저장해놓은 게임을 다시 시작할 수 있는 것도 넓은 의미의 미멘토 패턴이라고 할 수
있다. 다만 이경우에는 단순한 하나의 객체 상태만을 포함한 것이 아니라, 여러 객체 상태를 저장한 미멘토가 존재할 것이다.
[Observer 패턴은 언제 쓸까? - 선택적인
통지, 관리, 제어 등을 하고 싶다면.]
정상적으로 로그인해서 게임 중에 있는 게이머에게
일방적인 통지를 할 수도 있지만, 일방적인 통지 외에 선택적인 통지 형태를 몇 가지 만들어놓고, 게이머가 선택한 통지 형태에 관련된 이벤트가 발생하면 통지를 받게한다면? 이런
상황은 주위에서 많이 볼 수 있다. 내가 원하는 조건의 부동산 매물이 나타났다면? 증권 등 금융상품이 나타났다면? SMS로 끊임없이 광고가 올 수도
있지만, 카드를 사용하거나 어떤 조건이 되었을 때만 문자 서비스를 받고 싶다면? 상황은 많다.
예를 들어, 밤새
게임을 즐기는 바람직한 게이머를 위해 아침에 학교갈 시간이 되었다는 것을 알려주는 알람 서비스가 있다면, 안심하고(?) 마음껏 게임하다가, 학교갈 시간이라는 알람을 듣고 즐거운 등교를
할 수 있도록 해준다면 어떨까. 이럴때 사용할 수 있는 패턴이
Observer 패턴이다.
[State 패턴은 언제 쓸까? - 나는
천의 얼굴?]
일반적으로 마을에 있을 때 NPC에 대한 공격은 불가능하다. 어떻게 공격을 하지 못하도록 구현할
수 있을까? 몬스터에게 아이템을 바꾸자고 말을 하거나 아이템을 팔라고 말을 하고 싶지만 그럴 수 없다. 왜일까? 매우 당연하지만 어떻게 그런 상황을 구현할까? 캐릭터는 동일한데... 이러한 상황을 구현하는 방법은 여러가지가
있을 것이다. 하지만, State 패턴을 사용해서 구현할
수도 있다. 즉 캐릭터는 여러 역할을 갖는다. 마을에 있을
때는 뜨내기 사냥꾼이고, 전투장에 있을 때는 전사/마법사의
역할을 갖게 하고, 파티 동료들에게는 지원군이라는 역할을 갖도록 한다.
캐릭터들은 전투 등 습득한 상태 값들을 갖지만 그
외에 레벨에 대한 공통된 특성치들을 갖는다. 공통 특성치들 미리 정의해놓고 레벨이 올라갈 때마다, 상위 상태로 변경시킨다면, 여기에도 State 패턴을 적용할 수 있다. 이 경우 레벨이 높아지거나 레벨이
낮아지는 상황이 발생한다면, 미멘토 패턴 대신 State 패턴을
써서 하위 또는 상위 상태로 변경시킬 수 있을 것이다.
[Strategy 패턴은 언제 쓸까? - 나는
천의 얼굴?]
Agent를 학습시킬 때 "대전 형태를 정하고 이에
대한 전략"을 Strategy 패턴을 사용해서 정의할
수 있다. 특히 초반에 치루어지는, 단순 훈련이나 레벨이
낮은 몬스터들을 상대로 하는 경험쌓기라면 매우 효과적일 것이다.
무기판매상으로부터 무기 구매방식이 다양하다. 내부적으로 Gamble을 할수도 있을 것이다. 또한 특정 Event 기간에는 구매시 10% 확률로 Unique Item을 떨구어준다던가, "생일" 전후
1주일간은 모든 전투에서 Unique Item 획득 확률을 10% 올려준다던가... 이처럼 어떤 로직을 수행하는 Algorithm을 클라이언트에 영향을 주지 않고, 바꾸어주고 싶다면 Strategy 패턴이 매우 유용하다.
만약 엄청나게 많은 수의 몬스터들이 있고, 매우 강력한 얼음화살 마법을 사용했고 그 마법이 계속 몬스터들을 통과할 수 있다면, 불화살의 궤도에 있는 몬스터들에게 특별한 효과를 주고 싶고(Stun 효과, 정지 효과, 또는 어떤) 향후라도
새로운 효과를 넣고 싶다면. 이런 효과들을 Strategy로
묶어두거나 새로이 Strategy를 정의하면, 기존 프로그램에
영향을 주지 않고 새로운 효과를 활용할 수 있을 것이다.
[Template Method 패턴은 언제 쓸까? - 나는
천의 얼굴?]
Template Method
- Agent는 매우 다양하며, 캐릭터가
스스로 정의할 수 있는 부분이 있다. 이때 공통적인 부분은
Template Method로 정의해놓지만, 캐릭터가 스스로 정의하지 않으면 Default, 정의하면 해당 기능을 Overriding시킨다.
무기들이 갖고 있는 효과 등이 다양할 수도 있고, 공통적일 수도 있다. 공통적인 부분은 makeEffect()라는 상위 함수에서 정의하고, 각 특성별/레벨별 별도 사항이 있다면 doLevelEffec(), doPlayerEffec()와 같은 사항을 각 Player들의 Level에 따라 정하면 된다.
기본적으로
Template Method의 형태는 Factory Method의 형태와 동일하다. 다만, 생성이라는 특정 목적이아닌,
일반적 형태의 함수를 유연하게 표한하고자 할 뿐이다.
[Template Method 패턴은 언제 쓸까? - 나는
천의 얼굴?]
Visitor - 게임 속의 지형/건물 등은 변화를 줄 수 없고, 거의 고정되어있다. 이런 경우에는 지형/건물 등에서 일어나는 이벤트등을 지속적으로 추가해서 게임의 신선함을 유지해야한다. 이 경우 Visitor 패턴이 짱이다.
전투장(지형, 건물,...)에는 몬스터/아이템
들이 있는데, 동일한 위치에 동일한 몬스터가 나오게 할 수도 있지만,
시간/계절 등에 따라 조금씩 다른 형태의 게임을 즐기게 할 수도 있다. 뿐만 아니라 전체적인 분위기를 바꿀 수도 있다. UI를 바꾸는 작업은
조금 별개의 작업이 되겠지만, 실제 전투 환경에 대한 내부 정보는
Visitor등을 통해 바꾸면되며, 어떤 형태로 바꿀 것인가에 대한 패턴을 하나의 Visitor로 만들면된다.
[이제는 패턴들을 엮거나, 기존 패턴의 틀을 벗어나보자.]
예를 들면, 게임
캐릭터를 생성할때 초기 세팅은 거의 비슷하다면, Basic Character라는 것을 만들고, Prototype으로 기본을 복사한 후 기존의 생성 패턴을 사용해서, Personal
Character라는 것만 세팅하도록 한다.
특히 캐릭터들은 여러 아이템, 의상, 무기 등을 장착하는데 이 경우 Meta-Composite 패턴이 활용된다.
세트 아이템을 모두 모으면 캐릭터에 변화를 주는
경우를 앞에서 생각해보았다. 뿐만 아니라, 세트 아이템을
두개 갖추게 되면, 두개의 세트 아이템이 통합되거나, 새로운
아이템이 제공되거나, 캐릭터에 전혀 다른 기능을 부여하게 할 수도 있다. 즉 Meta-Composite 패턴과 함께 Decorator 패턴들을 중첩시킬 수 있고, 이들 구조체들이 Bridge 패턴을 통해 구현되었으므로 클라이언트에 영향주지 않고, 서버쪽의
캐릭터 기능을 Upgrade시켜버릴 수도 있다. 즉 아이템들을
통해 Dynamic Typing을 통해 캐릭터의 타입을 진화시킬 수도 있는 것이다.
게임의 장소는 그대로... 랜덤한 적들 또는 신규 이벤트를 벌이는 식은 이제 그만. 장소
자체도 바꿀 수 있도록하자. 마치 도시들도 계속 변하는 것처럼... 즉
모든 것이 변화하는 실세계를 그대로 게임세계에 반영하는 것이다.
따라서 변화의 주체/원칙 및 변화가 일어나는 형태(계획/랜덤)를 규정짓고, 건물의 변화된 룰을 사용하자. 즉 개인마다 다른 화면이 뜨는 것이다. Tople의 CBT라는 것 처럼.
즉, 당신
한사람만의 모든 게임이 연출되는 것이며, "이것은 매우 비싼 이용료를 지불해야한다." 물론, 호환된다.
이제는 게임의
Personl & Ubiq...인 것이다.
또한 유전자 알고리즘에 의해 학습한다. 이것은 프로그램에 대한 패턴이 아니라, 프로그램을 만드는 패턴에
대한 이야기이다.
...아... 시간이 없어 대강 끝을 내야 할 것 같다. 배고프다...
[소프트웨어 아키텍처 패턴]
소프트웨어 아키텍처는 단순한 개념은 아니지만, 단순하게 표현한다면, 소프트웨어의 구성요소 및 그들간 관계에 대한
규칙이다.
게임 제작을 하면서 앞에서 설명한 분석 패턴과 설계
패턴을 적용했고, 많은 부분을 C++를 이용해서 구현했다면, 전체 소프트웨어는 "객체"라는
것이 중요한 구성 요소이고, 그들간 관계는 객체들간 메시지 교환을 통한 상호작용일 것이다. 이는 집을 지을 때 초가집, 벽돌집, ... 등의 표현처럼, 구성요소와 그들간 결합을 중심으로 바라본
소프트웨어 아키텍처이다.
게임이 분산환경에서 이루어진다면, 많은 클라이언트는 게임서버와는 지역적으로 떨어져있을 것이며, 기본적으로
클라이언트-서버 구조를 갖는다. 이때 클라이언트와 서버 사이에는
다양한 프로토콜이 존재할 수 있으며, 서버에는 애플리케이션 서버와 대용량 데이터를 다루기 위한 데이터베이스
서버가 있을 수 있다. 따라서 이들은 3Tier 또는 그
이상의 멀티 티어로 구성된 시스템이다. 이런 형태는 네트워크를 중심으로 분산 형태를 고려한 측면의 소프트웨어
아키텍처이다.
게임을 작성할 때,
많은 기본 라이브러리, 프레임워크, 룰, 엔진 등이 사용되었을 것이고, 이들을 기반으로한 게임 애플리케이션을
작성한다. 이런 측면에서 소프트웨어를 보면 하드웨어와 이들을 제어하는
DD(Device Driver), OS, 프레임워크, 룰,
애플리케이션 등 다양한 레이어 구성을 갖는다. 이는 소프트웨어를 일종의 층(Layer)으로 모듈화하고, 이들간 관계를 체계화한 것으로 볼 수
있다.
리파지토리
함수, 데이터, 컴포넌트, 라이브러리, 프레임워크, 서비스, 패키지, 솔루션
등 다양한 소프트웨어 구성 체계 등은 "객체"를
포함한 "서비스 또는 기능을 제공하는 크기/단위)"에 관한 소프트웨어 아키텍처 이슈이다.
일반적으로 분산환경 기반의 게임에 대한 소프트웨어
아키텍처는 단순하지 않다. 이 안에는 동기/비동기, 동시성 제어, 보안, 트랜잭션, 사용성, 성능,... 등
매우 중요한 이슈들이 포함되어있으며, 이들을 어떤 목적으로 어떻게 시스템으로 구현할 것인가는 단순한
문제가 아니다. 이는 Stakeholder와 "게임 제작 목적"과 게이머들을 위한 근본적인 문제부터
출발하는 긴 여정이 될 수도 있다...
내가 없어도 예약해 둔 포스트가 잘 올라가고 있다. 내가 없어도 블로그가 잘 운영된다. 드디어 마이애미에 와서 스프링 가이들을 만나고 있다. 오늘은, 벌써 어제가 되었군. 어제는 키노트와 파티를 했고, 내일 아침 8시부터 밤 10시까지 강행군이 시작된다. 잠자리에 들기 전에 염장샷 몇 장 남긴다.
사진 설명: 첫 번째 사진은 대부분 알아보겠지만, 스프링의 아버지 로드 존슨이다. 두번째 잘생긴 친구는 유겐 할러. 대부분의 스프링 코드를 만들고 있는 스프링의 어머니 같은 존재고, 마지막 개구쟁이 같은 개발자가 dm Server 개발을 주도하는 롭 해롭이다.
Spring Night Seoul에서 공언한대로 로드 존슨 나이를 물어봤다.
이제 캐릭터와 같은 주요 객체들이 만들어졌으니, 본격적으로 게임을 즐길 수 있다. 패만 돌리면 된다.^^ 캐릭터를 만들거나 기존 캐릭터를 선택해, 온라인으로 접속해서
게임을 시작하면, 많은 상황들이 기다리고 있다. 쉼터, 마을, 전장(참고적으로
젠장은 없다.),...
[Adapter 패턴은 언제 쓸까? - 느그꺼
그냥 쓰고 싶은데...]
(가칭) AnyGameLand 속에서는 다양한 게임이
생겨나고, 기존 게임도 계속 변경되기 때문에 관련된 자회사나 협력사가 많다. AnyGameLand Inc.에 통합된 게임이 1000개가 넘은
시점이 2021년이니까...
예를 들어보자.
"게임은 뭐니뭐니해도 뿅뿅 스타일의 아케이드 게임이야."와 같은 사람들을
위해 다양한 뿅뿅 게임을 준비했다고 하자. 보통의 클라이언트에는 WindowsHeaven이
사용되고 있었고, AnyGameLand는 WindowsHeavenBissanServer
환경하에 운영되고 있었다. 그런데 어떤 작은 아케이트 게임 전문 회사(NJGC)에서, WindowsHeaven 커널에서 지원되는 허스키
음성 API를 활용한, 폭탄 성능에 따라 다양한 음향효과를
줄 수 있는 게임을 발표했다. 나름대로 좋은 호응을 얻었고, 이
회사와 AnyGameLand사와 적절한 합의가 이루어졌다. 다만
NJGC의 게임 인터페이스는 AnyGameLand의 표준인
AGML(AnyGame Mark-up Language)을 지원하지 못하는 상황이었다. 하지만 AnyGameLand측에서는 단순히 Adapter 패턴을 적용해줄 것을 요구했고, 비교적 쉽게 통합 작업이
이루어졌다. 양사의 인터페이스는 변화가 없지만, AnyGameLand에서
사용하고 있는 인터페이에 따라 NJGC사의 API를 불러
사용하는 Delegation을 활용한 Adapter를 제작하였다. 이에 따라 기존 클라이언트들은 새로운 음향효과를 맛볼 수 있었고,
AnyGameLand의 기존 프로그램도 별다른 영향을 받지 않았다. 사실 이런 사항들에
대한 선례가 너무 많았고, Adapter 패턴을 적용하는 것은 당연한 작업일 뿐이었다.
이처럼 다양한 객체, 라이브러리, 컴포넌트, 프레임워크들을
통합하는 과정에 있어 어댑터 패턴은 이들을 효과적으로 결합시키고, 기존 시스템에 변화를 주지 않으면서
새로운 서비스를 제공할 수 있는 바탕을 제공한다.
[Bridge 패턴은 언제 쓸까? - 야, 따로 놀자 따로 놀아.]
AnyGameLand에는 다양한 클라이언트들이 있고, 서버에는 다양한
게임들이 포함되어 있으며 실시간으로 개선(Upgrade)되고 있다. 클라이언트가
서버 측의 다양한 Upgrade에 영향을 받지 않기 위한 전략이 필요하다.
또한 무기, 아이템과 이들을 활용하는 캐릭터, 마을과 캐릭터, 전투장과 몬스터 등 각각의 단위 구조들이 복잡하기 때문에 이들간 상호관계는 복잡한 관계가 다양한 형태로 영향을
줄 수 밖에 없다. 하지만 아이템이나 마을 등이 바뀔 때마다 캐릭터를 바꿀 수는 없다. 따라서 각 단위 구조들은 그 구조들을 사용하는 모듈들에 대한 정교한 인터페이스를 정의하고, 구현을 분리시킨다. 이를 위해 대부분 모델들은 기본적으로 인터페이스를
구조화하며, Bridge 패턴을 활용해서 변화에 대한 다른 프로그램의 변경을 최소화한다. 예를 들어 무기는 그대로라 해도, 레벨이 올라갔다면 칼을 휘두를
때의 소리나 빛의 효과 등이 달라질 수 있다.(마나의 운용 능력이 올라갔으니 당연한 것이다.) 하지만 소리나 빛의 효과에 대한 기술이 Update될 때마다 기존
캐릭터들을 바꾸는 것은 불가능하다. 또한 새로운 무기 체계를 도입함으로써 지속적으로 사용자들을 현혹(?)시켜야하기 때문에 음향, 그래픽은 지속적으로 개선할 수 밖에 없다.
Bridge 패턴은 이런 경우에 기본적이면서도 중요한 기술을 제공한다. 인터페이스에
해당하는 클래스 구조만을 클라이언트에 알려주고, 그에 대한 대응 구조를 구현하는 체제로 가는 것이다. 이처럼 Bridge 패턴은 게임의 단위별 구조 설계에 기본적으로
적용할 수 있는 모델링 기법이며, 클라이언트/서버 형태의
프로그램 구조에 확장성을 주는 패턴이다.
* Adapter 패턴이 게임들간 통합을 위한 기본 전략이라면, Bridge 패턴은
게임 내의 주요 구조체들의 유연한 활용을 위한 기본 전략이고, 다음에 볼 Composite 패턴은 구조체들의 복잡한 구성 자체를 체계적으로 관리하기 위한 패턴이다. 앞의 생성 패턴을 구조 패턴이 적절히 적용된 구조체에 적용할 경우, 훨씬
효율적인 생성 패턴으로 활용할 수 있다.
[Composite 패턴은 언제 쓸까? - 봄이
왔네, 봄(BOM)이 와.]
Composite 패턴은 복잡한 구조체가 많이 필요한 곳에서는 가장 기본이면서,
많이 나타나는 패턴이 될 수 있다. 다양한 무기, 다양한
의상, 다양한 몬스터 등 게임 속에는 다양성을 가진 구조체들이 많으며,
이러한 다양성을 효과적으로 구성하고 관리하는 방법에 Composite 패턴이 딱이기 때문이다. 예를 들어 캐릭터의 자세한 안면 구조가 필요한 게임을 만든다고 가정하자. 눈, 코, 입, 귀, 피부, 머리, 수염, 여드름, 흉터 등 다양한 단위 요소들이 있고, 그들 단위 요소들이 모여 얼굴과 같은 복합체를 이루고, 얼굴, 몸통, 팔, 다리 등이
모여 캐릭터를 이루게 된다. 몬스터의 경우는 훨씬 다양한 요소와 결합 규칙이 적용된다. 눈 없는 놈, 해골만 있는 놈, 형태가
부정형인 놈... 신발과 같은 작은 아이템도 굽, 앞부분, 발 목부분, 다양한 재질 형태 부착물 등이 있으며, 그 외 의상, 무기 등도 나름대로의 구조체계를 갖고 있다. 이처럼 게임 내의 많은 구조들은 제작과정 또는 관리 상의 많은 어려움을 제공한다. 일반적으로 이와 같은 어려움을 트리 형태의 관리를 통해 복잡도를 제어하는 것이 일반적이며, Composite은 이때 활용하기 좋은 패턴이다.
디렉토리와 파일들을 생각해보면, 디렉토리는 디렉토리와 파일을 포함할 수 있는 복합체이고, 파일은
마지막 구성 요소에 해당한다. Composite 패턴은 이런 형태를 모델로 표현한 것에 불과하다. 마치 클래스 하나를 재귀관계로 표현했을 때 클래스의 유형을 두가지로(Leaf,
Node)로 분류하면서 재귀관계를 Node쪽에 살려놓은 형태이다.
BOM(Bill of
Materials)은 제조 뿐만 아니라,
다양한 도메인에서 활용할 수 있는 개념으로 어떤 구성체계를 가졌는지를 BOM을 통해 효과적으로
전달할 수 있다. Composite 패턴은 BOM을 표현하기
적당한 유연성을 갖고 있다.
구조체의 종류와 구성이 복잡한가? 일단 Composite 패턴을 적용할 것을 검토하라. 트리는 복잡도를 lognM으로 줄여줄 수 있는
효과적인 수단이다. (가지를 10개로 뻗을 수 있는 트리라면 1000개라해도 3번의 가지만 통과하면 찾아낼 수 있다. log101000 = 3^^;)
[Decorator 패턴은 언제 쓸까? - 야! 팀장 말이 전에 만든거 건들지 말고 기능을 추가하래...]
게임속의 구조체들에 기본적으로 Composite 패턴을 적용한다고 했다. 그런데 이런 구조체를 만들고
한참 쓰다보면 확장해야 할 이슈들이 등장한다. 기존 구조체는 건드리지 않고, 어떻게 확장할 수 있을까? 기본적으로 생각할 수 있는 것은 상속이다. 즉 Composite 패턴에서 복합체에 해당하는 클래스를 확장하고
싶은 타입으로 상속하면, 기존 구조들에 대해 확장된 기능을 제공할 수 있다. 즉 단위요소들을 포함하는 클래스를 확장함으로 해서, 그들 조합으로
나타나는 기능들에 변화를 부여시킬 수 있다.
예를 들어 Set
Item의 경우, 아이템들이 추가될 때마다, 기존
아이템들의 특성 및 기능이 Upgrade되며, 색의 변화
또는 반투명이나 골드코팅 효과 등을 함께 부여하고 싶다. 특히 Set
Item이 전체적으로 완성되는 경우, 캐릭터의 레벨에까지 영향을 주게 할 수도 있다. 이 경우에는 단순한 Decorator 패턴의 범주를 넘어선 것이지만, 얼마든지 응용할 수 있는 패턴으로, 기존 구조체 자체를 바꾸는 것이
어려운 경우에 활용할 수 있는 구세주와 같은 패턴이다. 이는 동적인 상황을 Decorator로 풀어서 설명한 것이며, 일반적으로, 클래스 수준에서 기존 구조체의 기능을 재정의하는 경우에 사용하면 좋다.
아이템 중에는 취득에 따라 기존 아이템까지도 새로운
기능이 부여될 수 있는 Set Items, Synergy Items, Grace Items 등을 만들고
싶을 때, Decorator가 딱이다.
[Facade 패턴은 언제 쓸까? - 난
복잡한거 싫어. 딱 한놈만 두들기면 다나와.]
많은 객체들이 상호작용하여 어떤 서비스를 제공한다고
할 때, 클라이언트 프로그램 입장에서 모든 객체를 제어하는 것은 불편할 뿐만 아니라, 레이어를 분리시킨다는 모듈 관점에서도 레이어간 상호작용/인터페이스를
간편하게 유지시키는 것이 좋은 모델링 기법이다. 네트워크를 타는 경우 리모트콜(remote call)을 줄일 수 있으며, 다른 레이어의 복잡도를
숨겨줄 수 있기 때문이다.
이때 여러 객체들간 상호작용을 클라이언트에 노출시키지
않도록 중간에서 인터페이스 역할을 해주는 클래스를 두면 좋은데 이런 것이 Facade 패턴을 활용한
예이다. 분산환경에서 리모트콜의 횟수를 줄이는 것은 기본적인 에티켓,
아니 반드시 적용해야 하는 모델링 전략이다.
이런 패턴을 응용해보자. 게임 중에 마을을 돌아다니면서 내가 필요한 것을 사기 위해 돌아다닐 수도 있지만, 여관에서 쉬면서 심부름꾼에게 부탁할 수 있다면, 신부름꾼은 캐릭터의
옷, 물품 등을 수거하고, 물약같은 필수 물품들은 사고, 그동안 사냥해온 것은 팔고, 무기는 적당히 고쳐준다. 물론 약간의 웃돈은 필요하겠지만. 소프트웨어 내의 심부름꾼을 Facade라 한다.
게임 진행상에 보면 여러 안내인 또는 가이드들이
게임속 상황에 대한 정보를 준다. 이 경우도 실제 내부 정보를 모으기 위해 동분서주할 필요없이, Facade에 해당하는 NPC들을 통해 필요한 정보를 모두 제공받을
수 있다.
[Flyweight 패턴은 언제 쓸까? - 야... 개떼처럼 많네. 이걸 다 메모리에 어떻게 올려?]
클라이언트 화면을 보면 주인공 하나에 수많은 적들이
몰려있는 상황을 많이 볼 수 있다. 이때 주인공 하나에 대한 그래픽 이미지는 별 문제 아니지만, 화면에 나타난 많은 적들 모두가 앞모습, 옆모습 등의 다양한 비트맵을
모두 갖게한다면, 적이 많아지면 클라이언트 화면은 물속의 움직임처럼 부드러워(?)질 것이다. 이 경우 각 적들은 자신의 위치와 현재 상태 같은
최소의 정보만을 갖고 비트맵 등은 공유할 필요가 있다. 이때 공유할 대상들은 작지만 공유를 통해 효율적인
시스템을 만들 수 있는데 이들을 Flyweight라 한다.
다양한 게임들이 있겧지만, 그 안에는 화면에 보여지는 많은 몬스터, 아이템 등이 있다. 기본적으로 이들은 모두 Flyweight로 구성/관리할 수 있다.
[Proxy 패턴은 언제 쓸까? - 난
운전할때는 운전수, 회사에서는 일꾼, 그거 빼고는 게이머.]
기본적으로 기능과 상관없이, 통신이 개입된 환경에서는 proxy 패턴을 쓰기 적당한 상황이다. 중간에 네트워크 채널이 있기 때문에 클라이언트가 원하는 서비스를 바로 받을 수 없고, 클라이언트가 원하는 서비스를 네트워크 넘어 다른 환경에 있는 서버에 대신 요청해줄 수 있는 객체가 필요한 것이다. 실체는 아닐지라도 클라이언트와 상호작용하는 객체를 proxy(stub,
skeleton 등 비슷한 말들이 많다.)라 한다.
또한 여러 역할을 가진 객체가 있다면, 역할별로 proxy를 두고, 각
클라이언트 프로그램들은 필요한 기능을 proxy를 통해 얻을 수 있다.
클라이언트 프로그램이 자기에게 배포된 proxy에게 어떤 요청을 하면, proxy는 메인 객체에게 그 요청을 전달해주면 될 것이다.
자... 게임
시작 장면을 생각해보자. 여러 캐릭터를 보여주고 주인공을 선택하게하는데, 이때 캐릭터 종류가 얼마 안되고, 특성 변화가 그리 없고, 확장 계획도 없다면 "패턴"에 대한 필요성은 거의 없다.
하지만, 캐릭터가
많고(종족, 타입,...),
특성(성별, 직업, 피부색, 털색, 키, 체형,...)도 많고, 캐릭터의
진화/변경도 예상되고, 새로운 캐릭터 특성 등이 계속 확장될
수 있다면(게임업계를 평정하려면 해야된다. 전세계 게임 시장을
내 손안에...^^), 어떻게 하면될까?
주인공 생성시 인간을 선택하고 남성을 선택하고, 구릿빛 얼굴과 커다란 덩치 흐트러진 머리... 를 선택한다고 가정해보자. 이렇게 여러 과정을 거처 만들어지는 주인공도 있지만, 미리 만들어
놓는 수많은 몬스터들, 마을 내의 NPC(Non-Playable
Character)들도 있고, 군데군데 떨구어 놓는 아이템들, 수많은 무기들, 건물, 산, 동굴, 기타 배경 등 다양한 것들을 게임 속에서 접하게 된다. 게임을 위해 생성할 것은 주인공만이 아닌 게임 전체 속에 있는 모든 요소들이며, 이들을 순차적으로, 때에 따라서는 한꺼번에 뭉탱이로, 또는 랜덤하게 생성하기도 한다. 몬스터가 죽으면 간혹 좋은 아이템을
남기는데(호랭이는 가죽을 남기고, 몬스터는 아이템을 남긴다...) 수천/수만의 아이템을 어떻게 유지할까? 그 많은 정보를 유지하기 쉽지도 않을 뿐더러, 계속 추가되기도 할텐데. 그때마다 관련된 프로그램이 바뀌어야한다면? 생각만해도 끔찍한 일이다. 새로운 것이 안나타나는 시간이 길어지면, 접속 사용자 수는 점차
줄어만 갈 것이고,..
결국, 무엇을
어떻게, 언제 생성할지에 대한 유연성을 부여하는 것이 사용자를 확보하는 것이고 돈버는 길이다. 자 그렇다면 "게임 제작자"라는 관점에서 어떻게 하면 사용자들을 현혹할 수 있는 복잡도를 잘 견뎌내면서도, 조금만 일해도 되는 프로그램을 만들 수 있을까...
여기서 잠깐 모델링의 원칙을 살펴보자. 똥막대기 원칙 1 : 모든 모델링의 기본은 "찾고, 관계 짓고, 상세 넣고, 정제하는
것"이다. 이 원칙에 입각해서 모델링을 시작하자.
우선 캐릭터 모델링부터 시작다면, 먼저 해야 할 일은 "관리가 필요한 Character 요소"를 찾는 것이다. 그리고 그들의 관계를 설정하는 것이며, 필요한 속성, 오퍼레이션을 정의하는 것이다. 그리고는 지속적 정제. 끝... 캐릭터라면 얼굴, 몸통, 팔, 다리, ... 등의
요소와 그들의 결합을 통해 캐릭터를 조합하는데, 종족/성별/.../장신구/의상/무기/... 에 따라 다양한 캐릭터를 만들어 낼 수 있다.
요소들을 파악했다면, 그들간 많은 관계들을 볼 수 있다. 얼굴과 눈은 Composition(무조건 있다.), 머리카락/비듬/머리핀 등은
Aggregation(있다가도 없어질 수도 있고, 중간에 만들어질 수도 있다), 종족/성별 등은 Inheritance.
하지만 대부분은 결국 Is-A, Has-A 안으로 귀결되며, 이들의 조합을 통해 매우 복잡한 모델도 만들 수 있다.
마을의 경우 NPC,
울타리, 집, 동물, 나무, 잔디, 집기, 상품/도구/..., 등의
요소와 그들의 결합을 통해 다양한 마을들을 만들어낼 수 있다. 세부적으로 보면 매우 복잡할 것이다. 예를 들어 집이라면... 방이 많은 경우, 여러 층인 경우,...복도, 광장, 기둥, 창문, 문,... 형태도 탑, 목조, 콘크리트, 폐가, 신축, 고대/중세/현대,... 등... 하지만, 이 것도 Is-A,
Has-A로 대부분 귀결된다. (흐흐흐... 사실은 UI에 보여지는 대부분을 객체화해서 만들 필요는 없다.)
전투장을 만든다면?
역시 요소들이 달라지고 그들의 결합에 따라 다양한 전투장이 만들어질 수 있을 것이다. 여기에도
다양한 타입들에 대한 Is-A, 다양한 포함관계의 Has-A가
나타날 것이다.
물론, 캐릭터와
몬스터들간의 "전투"처럼 다양한 상호작용이
있을 것이고, 이들 상호작용들은, 앞의 요소들에 나타나는
관계와는 달리, 주로 Association, Dependency에
의해 표현된다. 조금 저질스런 예를 들어보자. "코딱지를
판다." 이 경우, 코딱지, 손가락, 콧구멍(개념적인
것조차 모델링할 수 있다.^^), 코들간 Association이
표현될 것이다. 코를 후비는 것을 조금 확대해서 칼로 찌르기, 화살
날리기, 얼음창(마법) 던지기
등을 했다고 생각해보자. 관계된 객체들은 다르지만 상호작용 표현에는 유사성이 있다. 이런 형태의 상호작용은 생성 패턴에서 보다는 구조/행위 패턴에서
많이 볼 것이다.
참고로, 여기에
앞에서 살펴본 모델링 이면에는 다양한 프로그래밍이 전제가 된다. 예를 들면, Dynamic Binding과 상속을 통해 다형성(Polymorphism)을
구현하는 것이 있다. 이때 구닥다리 객체지향 언어인 C++인
경우 pure virtual function 또는 virtual
function이 필요하고, Java/C# 등을 사용한다면, 못들은 것으로 하자. 그냥 인터페이스를 쓰면된다. C는? 구조체 내에 함수 포인터를 쓰면된다. 그 외 무지하게 많은 재미있는 것들 static, this, ... 에
대해 재미있는 것들이 객체지향 프로그래밍에는 많다.
* 책 속의 특이한 특징 - 독자들의 생각/말도 함께 들어있다...
"아따... 징하다 징혀... 증말 말 많네... 증말...
경마장도 아니고... 생성패턴이라는 제목을 한참 전에서 본...적 있나? 가물가물하네...?"
여러분이 캐릭터를 만들 때 종족/특성/... 등을 선택했다면, 게임
내부에는 겉으로 보이는 화려한 캐릭터가 아닌, 메모리 내에 객체 특성값(상태)가 존재한다. 화면에
보여주는 것과는 아주 다른 이야기이다. 겉 모습에 대한 것도 있을 수는 있지만, 대부분 메모리 내의 객체 만들기에 대한 이야기들을 생성 패턴에서 다룬다.
GameStartScreen라는 놈이 있고, 이놈이 객체를 만든다고 하자. 이때 Brute Force 패턴을 적용해서 사용자가 선택한 캐릭터
구성 요소들을 생성자를 이용해서 직접 만들 수 있으며, If then else, 또는 switch를 사용해서 만들 수도 있다. 하지만 난 싫다. 차라리 빨리 만들고 남는 시간 게임을 더하는 것이 남는 일이기 때문이다. 어떻게
빨리 만들까? 궁금. 답:
남 시키면 된다??? 어떻게 남에게 시킬까? 어떤
좋은 방법(패턴)은 없을까?
[다양한 생성 패턴]
CharacterFactoryAtGameStartScreen라는 것을 만들고, 만들어야 할 요소들에 대해 생성자
호출 대신 가상함수를 호출하도록 구현한다면, Factory Method 패턴에 해당하고, 선택한 사항들을 모두 파라메터로 넘겨 캐릭터를 생성한다면 Abstract
Factory 패턴이고, 선택할 때마다 부분적 캐릭터를 만들어 통합한다면 Builder 패턴이고, 미리 대표적인 캐릭터를 몇개(얼마나 만들어놓을까?) 만들어놓고 이를 복사하고, 특성들이 다른 것들만 조금 변경하면 Prototype 패턴이다. 다만 캐릭터가 아닌 안내인 등의 NPC 등은 캐릭터 수 만큼 만들어
대응할 필요가 없다. 따라서 이 경우 동시 접속 상황을 고려해
Singleton으로(한명 또는 몇명 정도) 만들어
놓으면 된다. (뭔 말인지 이해되었으면, 이 책 절대 읽지
마라! 평생 안볼 곳에다 던져버려라. 불쏘시개도 좋다.)
[Factory Method 패턴은 언제 쓸까? - 몬스터는
죽어서 아이템을 남긴다.]
게임 중에 매우 다양한 아이템들을 얻을 수 있다. 길바닥에서 그냥 줏거나 전투를 통해 얻을 수도 있고, 남의 것을
빼앗거나, 구걸하거나(구걸신공 Skill! 이 기술만 마스터하면, 아무리 좋은 아이템을 갖고 있는
놈이라도, 구걸신공을 통해 뺏을 수 있다.ㅎㅎㅎ), 마을에서 사거나 도박을 해서 얻을 수도 있고, 일을 부탁 받고
보상으로 얻는 경우도(공짜로 일하지 마라.) 많다. 이처럼 아이템을 얻기 위해서는 누군가가 아이템을 생성하여야한다. 이때
길바닥에 버려진 경우를 제외하면, 캐릭터가 누군가에게 아이템을 요청(전투, 대화, 도박, 구매, 도움)한 것이고, 아이템을
요청 받은 대상은 아이템을 만들어 준 것이다. 따라서 이런 상황은 아이템을 생성하는 객체가 itemFactoryMethod()를 갖고 있고, 캐릭터는 이 함수를
내부적으로 호출하는 함수(combat(), beg(), talk(), buy(), help(),...)를
호출하면된다. 이때 itemFactoryMethod() 내부에는 "return new UniqueGnomSwordItem();"처럼 전달해줄 아이템을 생성하는
로직을 정하면된다. 이러한 형태를 Factory Method라한다. 다만, 추상 함수, 추상
클래스의 역할, overriding 의미 등을 명확하게 알지 못하는 사람들에게는 itemFactoryMethod()를 abstract로 만든 이유에
대해 조금 어려움을 느낄 수는 있다. 디자인 패턴이 좋은 또 다른 이유는 객체지향적 사고를 훈련하기
아주 좋다는 점이다.^^
즉 별도의
Factory 클래스를 만들 필요까지는 없이 기존 객체가 Factory 역할을 하면서 다른
객체에게 무언가를 주는(create) 상황이라면 Factory
Method 패턴을 사용하면 된다.
[Abstract Factory 패턴은 언제 쓸까? - 내
맘에 쏙 드는 종족/스타일을 만든다.]
복잡한 과정을 통해 게임 캐릭터를 만드는 경우, 화면에 보여지는 것과 실제 캐릭터가 만들어지는 것은 조금 다르다. 캐릭터
생성에 대한 과정이 모두 종료된 후, 한번의 요청으로 캐릭터를 만드는 것이 효율적이고, 화면에는 선택한 옵션에 따라 그때그때 모습만을 달리 보여주면된다. 캐릭터
생성 요청시 게이머가 선택한 사항들이 AbstractCharacterFactory로 전달된다. 이때 전달된 정보를 기반으로 다양한 캐릭터들이 만들어진다.
게임 초기에 캐릭터를 생성할 수도 있지만, 기존에 만들어놓은 캐릭터를 선택해서 게임을 할 수도 있다. 이처럼
기존 캐릭터를 선택한 경우에도 상태정보를 기준으로 Abstract Factory를 통해 캐릭터 객체를
만들 수 있다.
예를 들어, 각
종족별로 Factory를 만들고, 각 Factory는 얼굴 유형, 몸 유형, 의상 유형, 무기 유형 등 다양성을 내포하고 있는 각 클래스들을
기반으로 객체를 생성한다.
이처럼 별도의
Factory 클래스들을 정의하고, 캐릭터는 그들에 대한
Abstract Factory를 참조하도록 하면 매우 유연한 캐릭터 생성 패턴을 사용할 수 있다.
[Builder 패턴은 언제 쓸까? - 열심히
두들겨 패니까 나오네?]
객체지향적 사고라는 것은 어떤 것일까? 게임에는 부서지지 않는 벽도 있지만, 벽을 부수고 들어가 다음 전투를
수행할 수도 있다. 이때 벽을 부순다는 것은 벽에 break(this.getStrikePower())라는
메시지를 계속 던지는 것이고, 벽은 break(this.getStrikePower())라는
메시지를 받으면, 조금씩 스스로를 부서뜨리면서 새로운 입구를 조금씩 드러낸다. 다 부서지고 나면 벽은 허물어지면서 nextHidedAmaigingGate라는
객체를 캐릭터에게 넘겨준다. 캐릭터는
getIntoNextGate(this.getMissionHistory())라는 메시지를 nextHidedAmaigingGate
객체에게 전달하면, 객체는 캐릭터의 미션 수행상태를 점검하고, 필수적인 미션을 끝냈다면 통과를 허락한다. 몬스터와 상호작용하는
것은 자연스러워보일지는 몰라도, 벽하고 상호작용하고, 문하고
상호작용하는 것이 익숙하지 않을 수는 있다. 실제 벽이나 문은 스스로의 강도가 있고, 외부에서 가해지는 충격량이 견딜수 있는 강도보다 센 경우, 부서진다. 이런 상황을 유사하게 재현한 것 뿐이다. 객체지향적 사고라는 것이
이상해보여도 익숙해지면, 코딩을 모듈화하기 위한 술수(?)가
듬뿍 담겨있다는 것을 알게 될 것이다.
앞의 예를 잘 들여다보면, 비밀문을 통과하기 위해 여러번 벽을 두들겼다. 이처럼 여러번에 걸쳐
어떤 결과를 얻어내는 경우에 사용하는 패턴이 Builder이다.
시점이 연결되는 경우도 있겠지만, 시점이 떨어진 경우라도 Builder 패턴을 적용할 수 있다. 예를 들면, 미션을 완수할 때마다 무기 부품을 얻을 수 있는데, 이들 부품을 조립해서 새롭게 "LaserBOMGun 또는 LaserSword"와 같은 강력한 무기가 만들어진다면, 이
것도 Builder 패턴이라 할 수 있다. 이경우 숨겨진
미션 또는 비밀 미션 등을 통과한 후 찾아낸 특별한 부품 등을 함께 조립하면 새로운 옵션(지속적원기충전, 마법가속, 장비무게감소, 골드외장, 몬스터유혹파장, 방어파장,...)이
추가되는 부품이 만들어질 수도 있다.
이처럼 빌드 패턴은 최종 목표를 만들기까지 여러번의
과정을 통해 점증적으로 만들 때 활용하는 패턴이다. 아바타식 캐릭터를 만드는 경우도 Builder 패턴에 해당한다.
[Prototyping 패턴은 언제 쓸까? - 아저씨
칼 한자루 주세요.]
게임 속을 들여다보면 매우 많은 복제들이 일어난다. 마치 실세계에서 클로닝(cloning)이 중요한 이슈인 것처럼, 게임에서 자기 복제를 하는 것은 매우 중요한 기법이며 클로닝이라고도 한다.
캐릭터나 몬스터들의 기술 유형을 보면, 자기복제류의 기술들이 많다. 복제를 할 경우, 기본적으로 복제할 시점의 객체 상태와 동일한 상태를 갖는 프로토타이핑이 만들어진다. 무기 상점에서 물건을 구입할 경우에도 진열된 상품이 유일한 것이 아니라면, 기본적으로
복사를 해서(팔고 난 후에도 무기는 여전히 있어야하니까) 넘겨준다. 데리고 다니는 조무래기들을 생성하거나, 마법지뢰를 매설하는 경우처럼, 동일한 것을 지속적으로 만들어내지만, 각자가 상태를 갖거나 독자적인
생명이 있는 경우라면 프로토타이핑 패턴을 사용하면 된다.
스타크래프트라는 게임의 경우에 툴바를 사용해서 유닛을
생성한다. 이 경우에도 툴바에는 프로토타이핑이 존재하고, 이를
사용하는 경우 클로닝을 통해 새로운 유닛을 생성한다. 프로토타이핑의 대표적인 사례이다.
[Singleton 패턴은 언제 쓸까? - 여기는
겜마스터, 다 나와라 오버.]
Singleton은 가장 오랜 역사와 전통을 자랑하는 패턴이며 지금도 영업적으로 절대적 추앙을 받는 패턴이다. 서로 도와가며 살아가는 "우리"라는 말에 담긴 정감과는 거리가 먼, 오로지 돈이 얼마가
들어오는가에 따라 소프트웨어 사용에 대한 허가권을 내주는 서양식 발상에서 출발한 패턴이다. 모든 리소스는
돈이며 리소스 사용당 돈을 내야 한다. (원래 이런 쫀쫀함이 기술적 발전에 기여해온 것은 사실이다.) 씁쓸한 이야기는 그만 두고 게임으로 돌아가자.
가슴에 기대를 안고, 마을로 진입한다. 거기서 처음 나를 맞이해주는 것은 안내인이다. 가만보니 그 안내인은 나처럼 처음오는 초짜들을 계속 상대하고 있는 것처럼 보인다. 이처럼 많은 사용자들 수만큼 안내인이 필요하지는 않을 것이다. 그렇다면
안내인 1명 또는 제한된 인원으로 새로운 초짜들을 상대하는 것은 매우 효율적인 일이다.
"고운말 씁시다."라고 혼자서 여러 사람들을
상대하는 게임 관리자(Game Master, Manager)도 게임 내에 한명만 있으면 된다.
이처럼 사용자가 많아도, 잠깐씩 시간을 할애해서 여러 사용자를 상대하게 하거나, 방송을 통해
한꺼번에 통지할 수 있는 역할을 수행하는 객체를 사용자 수만큼 만드는 것은 엄청난 낭비일 것이다. 싱글톤
패턴은 스스로가 팩토리이면서 생성자(constructor) 접근을 제한하는 매우 특이한 취향을 가졌지만, 리소스의 효율성과 접근성의 제한이라는 강력함을 제공해주는 패턴이다.
SpringOneAmericas2008Summary.pps
SpringOneAmericas2008Summary.pdf
