앞선 리뷰 "혁신적인 아키텍처와 창발적 설계: 재사용 가능한 코드 활용하기, Part 1"에서 살짝 이어지는 내용입니다.
위 글에서 흥미를 끄는 단어가 하나 있는데, 안티 오브젝트(Antiobject)라는 표현입니다. 그 예로 패크맨 이야기가 나오는데, 이전에 어디선가도 들어본 적이 있는 내용이었습니다.
(본문이 굉장히 어렵게 쓰여져 있지만) 사실 글에서 이야기는 하려는 바는 객체 지향적인 사고가 너무 일반화되면, 오히려 문제가 더 어렵게 풀릴수도 있다는 이야기입니다. 그 예로 든 것이 패크맨 게임입니다. 언급된 내용은 오리저널 논문의 제목은 "협력적인 확산 : 안티오브젝트와 협력적인 확산(Collaborative Diffusion: Programming Antiobjects)"으로 되어 있습니다.
패크맨 게임은 미리 만들어진 미로내에서 고스트(ghost)가 사용자가 조정하는 패크맨을 뒤쫓는 게임입니다. 대학원생들에게 해당 게임을 구현하도록 숙제를 내줬더니 고스트를 어떻게 프로그래밍할 것인가에 대해 여러가지 방안이 나왔다고 합니다. 학생들의 기본적인 접근 전략은 크게 다음과 같았다고 합니다.
위 세 가지 기본 접근방법들 기반으로 조합해서 좀 더 나은 방법들을 사용하기도 합니다. 그런데, 고스트들을 하나의 객체로 잡고 일종의 인공지능스러운 알고리즘을 부여하려고 하니, 객체가 복잡해지고 메소드도 많아지고, 그러면서도 명쾌한 방법이 잘 나오지 않았다고 합니다. 게다가 이런식의 접근은 CPU도 상당히 사용하게 되는 방식이고요. (그러면서 최근 게임들의 인공지능에 대한 이야기도 나오는데, 재밌습니다. 게임쪽에서 일하시는 분들은 한 번쯤 읽어볼 만한 내용들이 많습니다.)
닐 포드는 기사에서 원본 패크맨시스템은 열악한 시스템 조건속에서 해당 문제를 어떻게 유연하게 풀었는지에 대해 이야기합니다. 고스트를 객체로 삼는 것이 아닌, 배경타일에 속성을 부여한 방법입니다. 고스트들이 아무렇게나 움직이다가 게이머가 조종한 패크맨의 흔적냄새를 맡으면 뒤따라 갑니다. 제가 읽었던 예전 내용(아.. 어디였는지 왜 기억이 안날까요? 괴롭..)에 따르면 패크맨이 지나가는 순간 매 타일은 숫자를 가집니다. 예를 들면 현재 패크맨이 있는 자리는 10이고 오른쪽으로 한 칸 움직이면 이전 타일은 9를 가지고 현재 타일은 다시 10을 가지는 식으로 매 타일이 패크맨 이동의 흔적 냄새를 가지는 거죠. 고스트는 숫자가 높은 쪽으로 움직이는거고요.
일반적인 "객체"지향 사고를 벗어나니까 좀 더 문제가 우아하게 풀리는 겁니다. 물론 여기서 말하는 객체지향 사고란 우리의 심리적인 접근을 말합니다. 흔히 "능동적으로 움직이는 것 처럼 보이는 것이 객체다"라는 선입관을 말합니다.
여튼 이런식의 접근을 안티오브젝트라고 부릅니다. 흔히 객체라고 생각하는 것이 객체가 아니고 오히려 다른 것이 객체이거나 논리 모델이 될 수 있다는 접근입니다. 단어 자체는 무슨 "반-객체지향 사상"처럼 들립니다만, 딱히 그런뜻은 아닙니다.
그리고 조금더 들어가서 이야기 하자만, 해당 논문에는 좀더 나은 모델을 제시합니다. 바로 "협력적인 확산(Collaborative Diffusion)" 모델입니다.
고스트들 하나만을 기준으로는 위에서 말한 냄새쫓아가기가 효과적이지만, 여러개의 고스트가 있을때는 한 길만 쫓아오는 바보 고스트들이 생길 수 있습니다. 그건 확산방정식을 이용해서 풀어내는 이야기를 설명 하고 있습니다. 효율적으로 접근하려면 기본적으로 패크맨의 현 위치가 산꼭대기에 해당하고 나머지 고스트들은 정상을 향해 다가가는 식으로 접근합니다. 그리고 각각의 고스트들이 서로 협력을 해서 효과적으로 접근하는 방법을 이야기합니다.
위 글에서 흥미를 끄는 단어가 하나 있는데, 안티 오브젝트(Antiobject)라는 표현입니다. 그 예로 패크맨 이야기가 나오는데, 이전에 어디선가도 들어본 적이 있는 내용이었습니다.
(본문이 굉장히 어렵게 쓰여져 있지만) 사실 글에서 이야기는 하려는 바는 객체 지향적인 사고가 너무 일반화되면, 오히려 문제가 더 어렵게 풀릴수도 있다는 이야기입니다. 그 예로 든 것이 패크맨 게임입니다. 언급된 내용은 오리저널 논문의 제목은 "협력적인 확산 : 안티오브젝트와 협력적인 확산(Collaborative Diffusion: Programming Antiobjects)"으로 되어 있습니다.
패크맨 게임은 미리 만들어진 미로내에서 고스트(ghost)가 사용자가 조정하는 패크맨을 뒤쫓는 게임입니다. 대학원생들에게 해당 게임을 구현하도록 숙제를 내줬더니 고스트를 어떻게 프로그래밍할 것인가에 대해 여러가지 방안이 나왔다고 합니다. 학생들의 기본적인 접근 전략은 크게 다음과 같았다고 합니다.
1. 브라운 운동 (Brownian Motion: 유체 미립자의 불규칙한 운동)
- 매 순간 갈 길을 랜덤하게 결정. 돌아다니다보면 어쨌든 만난다. 단점: 고스트들이 무뇌로 보임
2. 조준사격(Point and Shoot)
- 방향을 정해서 장애물이 나타나거나 갈림길이 올때까지 꾸준히 움직인다. 단점: 패턴이 보이면 역시 멍청해 보임
3. 증분식 접근(Incremental Approach)
- 매 순간 패크맨에게 가까운 쪽으로 움직인다. 유클리드 기하학과 방정식을 이용한다. 단점: 장애물처리라던가 막다른 골목에 쳐박혀 버둥대고 있을 수 있다.
- 매 순간 갈 길을 랜덤하게 결정. 돌아다니다보면 어쨌든 만난다. 단점: 고스트들이 무뇌로 보임
2. 조준사격(Point and Shoot)
- 방향을 정해서 장애물이 나타나거나 갈림길이 올때까지 꾸준히 움직인다. 단점: 패턴이 보이면 역시 멍청해 보임
3. 증분식 접근(Incremental Approach)
- 매 순간 패크맨에게 가까운 쪽으로 움직인다. 유클리드 기하학과 방정식을 이용한다. 단점: 장애물처리라던가 막다른 골목에 쳐박혀 버둥대고 있을 수 있다.
위 세 가지 기본 접근방법들 기반으로 조합해서 좀 더 나은 방법들을 사용하기도 합니다. 그런데, 고스트들을 하나의 객체로 잡고 일종의 인공지능스러운 알고리즘을 부여하려고 하니, 객체가 복잡해지고 메소드도 많아지고, 그러면서도 명쾌한 방법이 잘 나오지 않았다고 합니다. 게다가 이런식의 접근은 CPU도 상당히 사용하게 되는 방식이고요. (그러면서 최근 게임들의 인공지능에 대한 이야기도 나오는데, 재밌습니다. 게임쪽에서 일하시는 분들은 한 번쯤 읽어볼 만한 내용들이 많습니다.)
[ㅎㅎㅎ 바보들~ 나잡아 봐라~~]
닐 포드는 기사에서 원본 패크맨시스템은 열악한 시스템 조건속에서 해당 문제를 어떻게 유연하게 풀었는지에 대해 이야기합니다. 고스트를 객체로 삼는 것이 아닌, 배경타일에 속성을 부여한 방법입니다. 고스트들이 아무렇게나 움직이다가 게이머가 조종한 패크맨의 흔적냄새를 맡으면 뒤따라 갑니다. 제가 읽었던 예전 내용(아.. 어디였는지 왜 기억이 안날까요? 괴롭..)에 따르면 패크맨이 지나가는 순간 매 타일은 숫자를 가집니다. 예를 들면 현재 패크맨이 있는 자리는 10이고 오른쪽으로 한 칸 움직이면 이전 타일은 9를 가지고 현재 타일은 다시 10을 가지는 식으로 매 타일이 패크맨 이동의 흔적 냄새를 가지는 거죠. 고스트는 숫자가 높은 쪽으로 움직이는거고요.
일반적인 "객체"지향 사고를 벗어나니까 좀 더 문제가 우아하게 풀리는 겁니다. 물론 여기서 말하는 객체지향 사고란 우리의 심리적인 접근을 말합니다. 흔히 "능동적으로 움직이는 것 처럼 보이는 것이 객체다"라는 선입관을 말합니다.
여튼 이런식의 접근을 안티오브젝트라고 부릅니다. 흔히 객체라고 생각하는 것이 객체가 아니고 오히려 다른 것이 객체이거나 논리 모델이 될 수 있다는 접근입니다. 단어 자체는 무슨 "반-객체지향 사상"처럼 들립니다만, 딱히 그런뜻은 아닙니다.
그리고 조금더 들어가서 이야기 하자만, 해당 논문에는 좀더 나은 모델을 제시합니다. 바로 "협력적인 확산(Collaborative Diffusion)" 모델입니다.
고스트들 하나만을 기준으로는 위에서 말한 냄새쫓아가기가 효과적이지만, 여러개의 고스트가 있을때는 한 길만 쫓아오는 바보 고스트들이 생길 수 있습니다. 그건 확산방정식을 이용해서 풀어내는 이야기를 설명 하고 있습니다. 효율적으로 접근하려면 기본적으로 패크맨의 현 위치가 산꼭대기에 해당하고 나머지 고스트들은 정상을 향해 다가가는 식으로 접근합니다. 그리고 각각의 고스트들이 서로 협력을 해서 효과적으로 접근하는 방법을 이야기합니다.
패크맨 뿐 아니라 축구게임에서 공과 선수들의 움직임에 대해서는 좀 더 응용된 형태로 설명을 하고는 있는데, 논문자체의 방정식 같은건 어려우니까 넘어가겠습니다.
결과적으로 말하고 싶은 건, "추상적인 설계를 하는데 있어서 이런 선입관을 버리고 무엇을 추상화 할 것인지에 대해 다양한 사고를 해야 한다" 정도로 받아 들이면 되겠습니다.
아. 그리고, 이번에도 사족한가지 더.
IBM dW의 기사 "혁신적인 아키텍처와 창발적 설계"시리즈는 좋은 기사이긴 한데 참 여러가지로 어려운 내용이 거듭되는 것 같습니다. 번역기사도 참 어렵네요.
'Better SW Development' 카테고리의 다른 글
| [dW Review] node.js (0) | 2011.08.30 |
|---|---|
| [dW Review] Java 개발자를 위한 Javascript (0) | 2011.07.31 |
| [dW Review] LAMP 애플리케이션을 조정하는 다섯 가지의 간단한 방법 (6) | 2011.06.30 |
| [dW Review] MongoDB + Morphia Project (5) | 2011.06.30 |
| [dW Review] 닐포드의 "혁신적인 아키텍처와 창발적 설계" (0) | 2011.06.28 |
