[GPG 1 글 1.1] [s1.1] 설계 패턴 이야기 #1

GPG 시리즈 관련 질답, 논의 공간.

Moderator: 류광

류광
Posts: 3805
Joined: 2001-07-25 09:00
Location: GPGstudy
Contact:

Post by 류광 »

이 글은 예전 GPG 스터디 포럼에 gryu 님이 올리신 주제와 그에 대한 답글들입니다. 원본(Ezboard)은 "<a href="http://pub32.ezboard.com/fgpgstudyfrm2. ... D=36.topic" target="_blank">[s1.1] 설계 패턴 이야기 #1</a>"입니다.
<div class="imported">
<div class="sep"><span class="cfs">제목: [s1.1] 설계 패턴 이야기 #1
</span></div>
<div class="r">글쓴이: gryu , 글쓴때: 1/24/01 12:09:34 pm</div>

설계 패턴(디자인 패턴)에 대해 주워들은&요즘 생각한 이야기들...

우선... 설계 패턴의 '패턴'은 특별한 용어가 아닙니다. 게임 공략집에서 흔히 볼 수 있는 "몇 번 죽다 보면 보스의 공격 패턴에 익숙해 질겁니다..." 같은 문장 속의 패턴과 다를 바가 없습니다. 즉 패턴은 일상에서 쓰이는 바로 그 의미.. 반복적으로 나타나는 어떠한 유형을 뜻합니다. 소프트웨어 공학 용어들에는 설계 패턴뿐만 아니라 분석 패턴, 코딩 패턴 같은 용어들도 존재하죠.. 반복적인 것(따라서 재사용할 수 있는 것)이면 어떤 것이라도 '패턴'을 붙일 수 있다는 이야기.. 예를 들어서 스토리 패턴 같은 것도 존재할 수 있겠죠(과거를 숨긴 아버지를 가진 소년이 위기에 빠진 소녀를 구한다.. 그 소녀는 고대에 봉인된 어떤 힘을 가지고 있고.. 아버지는 사실 왕실의 기사였고 등등등)

어쨌든 설계 상에서 반복적으로 만나게 되는 어떤 것이 있을 때, 그걸 정리하면 설계 패턴이 됩니다...

그렇다면 설계 패턴이라는 개념이 왜 제기되었는가... 그것은 '기법'이나 '알고리즘'이 아니라 '경험'을 전수할 정형화된 틀이 필요했기 때문인 것 같습니다.

기법이나 알고리즘은 실제 프로그래밍 언어 또는 의사 코드 같은 형태로 서술할 수 있죠. 알고리즘 책들 보면 파스칼 비슷한 의사 코드를 많이 사용하고, GPG에도 실제 C++ 코드가 아니라 의사 코드가 나오는 부분이 있습니다. 의사코드는 한 사람이 다른 사람에게 기법을 전수할 때 '공통적인 언어'로 쓰이는 거죠.

설계 패턴은 설계 상의 경험을 효율적으로 정리, 수집, 전달하기 위한 '공통적인 언어(또는 숙어집)' 같은 것입니다. GPG 섹션 1.1 50페이지 중간의 '...무의식적이고 개별적인 참조/연상 과정을 좀 더 범용적인 참조의 틀로 정규화하는 것에 관련..'이라는 문장의 의미가 바로 그것입니다.

예를 들어서, 설계 패턴이라는 개념이 없을 때...

Q : "비슷비슷한 클래스 종류가 엄청 많은데... 객체들을 생성하고 소멸하는 코드가 너무 지저분해서리.. 해결방법이 없을까요"

A: "그럼 객체들의 생성과 소멸을 처리하는 관리자 클래스를 만드세요.. "

Q: "??? 좀 더 자세히 설명을.."

A: "그러니까 개별 객체를 직접 생성하지 말고 그 클래스들의 기반 클래스에.. 으윽.. 말로 설명하려니 힘들군.."

질문자와 답변자가 설계 패턴이라는 것을 알고 있을 때..

Q : "비슷비슷한 클래스 종류가 엄청 많은데... 객체들을 생성하고 소멸하는 코드가 너무 지저분해서리.. 해결방법이 없을까요"

A : "팩토리 패턴을 참고하세요"

Q : "넵!"

이런 겁니다... 네...

객체 지향의 중요한 목표들 중 하나는 '재사용'인데... 함수나 클래스 라이브러리는 소스 코드를 재사용하기 위한 것이고, 컴포넌트는 이진 코드를 재사용하기 위한 것이라고 한다면, 설계 패턴은 설계 자체를 재사용하기 위한 것이라고 할 수 있겠죠.. 따라서 설계 패턴은 코딩 차원에서 참조하는 것이 아니라 설계 차원에서 참조해야 하는 것이고, 그래서 설계 패턴들을 보면 자세한 예제 코드가 없는 경우도 많습니다(gamedev.net의 GD Design Patterns 섹션 참고...).

결론적으로, 설계 패턴은 코더가 아니라 소프트웨어 엔지니어의 입장에서 봐야 한다는 것... 또한 선배 개발자들의 경험을 최대한 자기 것으로 받아들이려는 입장에 서야 한다는 것..

또 한가지 추가하고 싶은 것은...

사실 게임 개발자들만큼 일을 많이 하고 많은 양의 코드를 짜는 개발자들은 없을 겁니다. 그많큼 엄청난 경험이 축적되어 있다고 볼 수 있죠(게임 개발자 공동체 전체의 차원에서). 그런 반면 객체 지향적 방법론에 기반한 '재사용' 부분은 다른 분야에 비해 대단히 미약한 것 같습니다(게임 만들 때마다 매번 툴을 다시 만드는 경우도 많고 등등). 그도 그럴 것이.. 게임이라는 것이 하드웨어나 기술의 발전에 매우 민감한 분야라서, 작년에 짠 코드는 이미 낡은 코드가 되어 버린 경우가 많죠... 재사용이고 뭐고 없는 거죠.

그런 차원에서 설계 패턴은 게임 개발자들에게 매우 중요한 수단이 될 것 같습니다. 설계 부분은 그리 변화가 심하지 않으며, 또한 많은 개발자들이 충분한 설계 경험들을 축적하고 있으니까요.. 그것을 정리하고 전달, 공유할 수 있는 강력한 수단이 바로 설계 패턴입니다.

이미 해외 개발자들은 자신의 경험을 패턴으로 만들어서 공유하고자 하는 노력을 시작하고 있습니다. 대표적인 곳이 GameDev.net의 Game Design Patterns 섹션인데.. 현재는 몇몇 사람들의 패턴들만 올라와 있지만, 시간이 지날 수록 많은 개발자들이 '공유' 정신에 기반해서 자신만의 패턴들을 공개할 것이라고 생각합니다. 국내 개발자들도 그런 흐름에 적극 동참해서...(영어가 안 된다면 여기 스터디 포럼에라도 올려 주시길...)

그럼 자신의 경험 속에서 어떻게 패턴을 식별하고 서술하느냐... 이것에 대해서는 기존 설계 패턴들을 공부하면서 방법론을 찾아야 할 것 같습니다. 여기 저기 돌아다니면서 정형화된 방법론이 있는지 찾아보고 있는 중인데... 찾게 되면 다시 글을 올릴께요...

다음 글은 RPG 멀티 클래스 캐릭터(전투 마법사 등등)의 구현과 다중 상속의 문제에 관련된 패턴에 대해서.. 기대해 주세요..
<p><center>
/*************************
as simple as possible,
but not simpler
*************************/
</center>

<br></p></div>