소셜 게임이나 웹 게임 만드시는 분이 많은 것 같습니다. 기술적인 고민 중 하나는 Flash 기반으로 갈 것인가, HTML 기반으로 갈 것인가 일텐데요 이게 좀 민감한 문제일 수 있죠. (대부분의 소셜 게임/웹 게임은 전통적인 2D 스프라이트 애니메이션에 간단한 스크롤 등으로 구현되므로 Unity3D 같은건 일단 뺍시다)

최근 Apple와 Adobe의 신경전, Google의 기묘한 행보(한편으로는 HTML5 미는가 싶으면서 또 한편으로는 Chrome에 Flash 류 지원 강화하고. 아마도... "난 그런거 몰라, 인터넷에 광고할거니까 광고판만 키워줘염" 이런 느낌), Adobe의 6월 반격설 등등.

기업 간 이권 다툼은 그렇다 치고, 당장 현실적인 문제를 따져보면:

  • Flash를 고르면 iPhone/iPad 대응 따로 해야하는데 상당히 귀찮을 수 있음.
  • HTML를 고르면 뭔가 느릴 것 같음. 게다가 iPhone 용은 인터페이스 등이 다를텐데 어차피 따로 만들어야 하는 것 아닌가?
요런 상황이죠. 대체로 Flash를 택하고 iPhone/iPad 용은 따로 개발한다는 식으로 방향을 잡는 것 같습니다.

만약 저한테 고르라고 한다면 두 개(잠시 후 설명하겠지만 정확히는 세 개)를 다 개발하는 방향을 고르겠습니다. Lean Software Development에서 말하는 Set-based development 전략입니다:

엔터프라이즈 애플리케이션을 개발하는 회사에 다니는 친구가 중요한 의사결정을 내렸던 일에 대해 이야기해주었습니다:

"시스템에 쓸 기술 플랫폼을 골라야했지. 근데 당시에 존재하던 세 개의 선택권 중 어떤 게 우리에게 가장 잘 맞는지 확실치 않았어. 그래서 세 가지 모두 개발하기 시작했지. 그러느라 시스템의 하단부가 조금 더 일반적인 방식으로 개발될 필요가 있었는데, 결국은 그 덕분에 시스템이 매우 견고해졌지. 프로젝트 종료 직전에서야 어떤 플랫폼을 선택해야 하는지가 명확해졌는데, 그 전까지는 플랫폼을 확정할 필요가 전혀 없었어. 막상 우리가 선택한 플랫폼은 프로젝트 초기에는 고려 대상이 아니었다네."

A friend from a company that does enterprise applications told us how he made a critical decision:

"We had to choose a technical platform for a system. However, it was not clear which of the three available options was going to be the winner, let alone meet our needs. So we started developing on all three. This required the underlying development to be a bit more general than otherwise, but it turned out to be quite robust because of that. It was really not necessary to decide on a platform until quite near to the end of the project, and by that time, the correct choice was pretty obvious, but it was not the one we would have made in the beginning."

--p43, Lean Software Development - An Agile Toolkit

세 개 플랫폼 모두에 대응해서 개발하다가 프로젝트 종료 시점에 하나를 선택하고 나머지 두 개를 버리라니, 실무라고는 하나도 모르는 이론쟁이의 정신나간 헛소리같죠. 게다가, 위 사례처럼 프로젝트 종료 전에 하라는 선택하는 것도 아니라 세 개를 계속 유지하면서 가라니.


1. 세 개의 플랫폼

보통은 Flash와 HTML 두 가지 플랫폼이라고 생각하기 쉽지만 현실적으로는 세 가지라고 봅니다:

  • Flash: IE 등 느린 브라우저를 위해.
  • Webkit: Safari CSS Visual Effects를 지원하는 Safari, iPhone, iPad.
  • Canvas: 현재 버전의 Chrome과 Firefox
  • (3D 배제한다고 했으므로 Canvas 3D + WebGL이나 Unity3D 등은 일단 KIN)
따라서 IE 버전, Webkit류 버전, Canvas 버전으로 랜더링 부분을 개발하고, 이 위에 iPhone 버전, iPad 버전, 브라우저 버전으로 UI 부분을 개발하는거죠.

어떻게? 자바스크립트와 좋은 설계로.

자바스크립트에서 호스트환경(브라우저, Flash Player 등)에 의존하는 코드를 몽땅 제거하면 해당 코드는 위 세 개 플랫폼에서 모두 사용할 수 있습니다. 80~90% 이상의 코드가 한 글자도 수정없이 모든 플랫폼에서 쓰일 수 있습니다.

대충 다음과 같이 분해하면 됩니다:
  • 입출력 담당 및 호스트환경에 대한 wrapper 코드 세 벌(Flash, Webkit, Canvas)
  • 입력을 해석하고 플랫폼에 맞게 출력을 배치하는 코드 세 벌(브라우저, iPhone, iPad)
  • 나머지 몽땅
작업을 진행하면서 풀어야할 문제들은:
  • Flash와 Webkit과 Canvas의 서로 다른 작동 방식을 어떻게 잘 추상화할 것인가 (성능에 미치는 영향이 최소화되는 방식으로)
  • "나머지 몽땅" 부분에 얼마나 많은 코드를 넣을 수 있을 것인가
등이 있겠습니다만 이것들은 대체로 mystery라기 보다 problem 수준이죠.

Flash/Webkit/Canvas를 추상화하는 문제는 생각보다 삽질이 필요할 수 있습니다. 한가지만 예를 들면, 스프라이트 애니메이션 관련 API를 다음과 같이 한다고 칩시다:
  • 스프라이트를 특정 좌표에 그려주는 API
  • 스프라이트를 원하는 위치로 이동시켜주는 API
이렇게 하고 부드러운 이동에 필요한 이징 함수 등은 직접 구현해서 "나머지 몽땅" 부분에서 처리한다 치면 Canvas와 Flash에선 괜찮을지 모르나 iPhone에선 성능이 느릴 수 있습니다. Webkit에서 이징은 CSS를 이용해 선언적으로 처리해야 iPhone에서도 빠른 속도로 구현됩니다.

이런 식의 문제(어느 정도 수준에서 추상화를 할 것인지)를 잘 해결하려면 각 기술(Flash, Webkit, Canvas)의 API를 어느 정도 이해하고 실제로 삽질도 좀 해봐야하지 않을까 싶어요.

2. 부가적인 이득

위에서 인용한 글귀에도 나오지만 부가적인 이점이 있습니다. "나머지 몽땅" 부분이 플랫폼 중립적인 방식으로 설계/구현된다는 점이죠. 이게 뭔 소리인고 하니:

  • 비교적 아름다운 API
  • 완전한 테스트 가능성 (실제 커버리지가 높냐 낮냐는 개발자가 얼마나 열심히 테스트 코드를 작성하느냐의 문제)
  • 이에 따라 견고하고 유지보수 비용이 낮은 코드 확보
소셜 게임이나 웹 게임 류는 런치 이후의 운영이 매우 중요한데 여러가지를 빠르게 테스트하고자 할 때(A/B Test가 됐건 아니건), 게임 내 여러 시스템(경제가 됐건 전투가 됐건)에 대해 다수 사용자의 인터랙션을 미리 시뮬레이션해보고자 할 때 등 온갖 지점에서 엄청난 이득으로 돌아올 것이라고 확신합니다.

에.. 이건 짐작인데요, 언젠가 "나머지 몽땅" 부분에 들어있는 로직 중 상당수를 서버에서 돌려야할 일이 (여러가지 이유로) 생길 가능성이 있는데, 이 때엔 서버측 코드 새로 짜지 말고 "SSJS (server-side javascript)"를 구글링해보세요. 짐작이기는 하지만, (현재 진행중인 프로젝트라면) 서버측과 클라이언트측에 같은 일을 하는 코드가 이미 상당히 쌓여 있을 것이다에 이 돈 몽땅과 제 손모가지를...


3. 발빼기

어... 전 소셜 게임 개발 안할겁니다.

ㅌㅌ


4. 예상 FAQ

Q1: JS로 짜면 플래시 버전도 꼬진 AVM에서 실행되니까 느리잖아요?
A: 소셜 게임으로 WoW 만들거 아니니까 괜찮습니다. FarmVille 정도는 가뿐하죠.

Q2: JS로 짜면 type checking은?
A: 유닛테스트 잘 만드세요. 피가 되고 살이 됩니다.

Q3: 안해보고 이런 글 써도 되나요?
A: 믿느냐 마느냐는 님의 선택. 진실은 저 너머에...

Q4: 개발도 안할거면서 이런 글 왜 쓰나요?
A: 개버릇 남 못줘서.

Q5: Webkit CSS랑 Canvas가 정말 쓸만한가요?
A: 구글링 plz. 참고로 아이폰에서 HTML/CSS/JS로 요런짓도 가능합니다.

Q6: "나머지 몽땅" 부분에 8~90% 코드를 넣으려면 어떻게 설계를 해야?
A: 소프트웨어 설계에 대한 책들을 참고하세요. 이를테면 패턴 책이나.


...


PS: 행여나 이 글에 낚여서 삽질을 하시다가 프로젝트가 산으로 가면 제가 밥 한끼 정도 사드리는 것으로 보상을.



저작자 표시
신고

오늘의 잡생각 – 프로그래머를 읽고 씁니다:

까놓고 말해서 블로그에서 진정한 OOP가 어쩌니, SOLID가 저쩌니, 패턴이 어떠니, Separation of Concern이 저떠니하고 추상적인 썰이나 풀고 놀면서, 용어가 중요하니, 책을 쓰니마니 하는 선수들을 보면 싹수가 노란것처럼 보이는데…

딱히 저를 두고 하신 말씀이야 아니겠지만(저는 듣보잡이니깐) 제가 마침 요즘 블로그에 위와 같은 얘기들을 자주 쓰던 참이라 좀 찔리지 말입니다. 그래서 나름의 변명해명을 해보려고 합니다.

프로그래밍을 배웠으면 일단 소프트웨어를 만들어 보기는 해야겠죠. 혹은 다른 누군가에게 프로그래밍 언어를 가르칠 수도 있겠습니다. 하지만 프로그래밍 언어를 다른 재미난 용도로 쓸 수도 있습니다. 프로그래밍 언어로 사고(thinking)도 합니다.

프로그래밍 언어를 사고의 도구로 쓰겠다는 생각은 물론 제 창작물이 아닙니다. 이를테면, SICP(Structure and Interpretation of Computer Programms)는 이러한 생각을 염두에 두고 쓰여졌습니다. 이 책의 저자들은 프로그래밍을 절차적 인식론(procedural epistemology)으로 취급합니다. 자세한 인용은 Programming language as a tool of thought 페이지를 참고하세요. 김창준님도 예전에 비슷한 생각을 잠깐 언급한 적이 있죠.

남 얘기 말고 제 얘기를 해보자면, 저는 최근 1년 가까이 프로그래밍을 안하고 있습니다. 그 대신 기획을 하고 있는데, 프로그래밍을 하면서 몸에 익힌 다양한 사고 방식으로부터 많은 도움을 받고 있고, 이러한 지식을 기획에 활용하기 위해 의도적으로 연결점을 찾는 노력을 하고 있는데 (자기가 한 일을 자기가 판단하는게 좀 웃기긴 하지만) 여러가지 성과가 있다고 생각합니다. 일하면서 느끼는 바를 조금씩 정리하고 있는데, 언젠가 기회가 되면 하나씩 정리해서 블로그에 올릴 생각입니다. (항상 하는 말이지만, 누군가에게는 도움이 되겠죠)

정리하자면 이렇습니다.

프로그래밍 혹은 프로그래밍 언어를 보는 입장은 사람마다 다양할 수 있습니다. 각자의 입장에 따라 무엇을 중요한 성과로 볼 것인지가 달라지겠죠. 아주 거대한 소프트웨어를 만들어서 돈을 많이 버는 것을 중요한 성과로 생각할 수도 있는 것이고, 기술적으로 별 볼일 없는 아주 작은 소프트웨어(이를테면 Perl로 몇 줄 끄적거린 오리지널 위키)이더라도 이를 통해 사회에 지대한 공헌을 했으면(이를테면 위키피디아의 탄생) 이를 중요한 성과로 생각할 수도 있는 것이죠.

다양한 입장을 서로 존중해주면 좋겠습니다.

PS: 요즘은 Masterminds of Programming이라는 책을 읽고 있습니다. 다양한 언어의 설계자들과 인터뷰한 내용을 모아놓은 책인데, 그야말로 프로그래밍 언어를 보는 엄청나게 다양한 입장들의 향연입니다 :-) 매 페이지마다 떡밥이 주렁주렁.

신고
얼마전에 짧게 독후감을 올렸던 "Designing for the Social Web"의 번역서가 나왔네요.


(원서 표지)


(번역서 표지)

항상 하는 생각이지만, 인사이트에서 나온 책은 표지가 원서보다 알흠답습니다. 아직 책을 읽어보지는 못해서 번역이 얼마나 잘 되었을지 알 수 없지만, 기본적으로 출판사에 대한 신뢰가 있습니다.

SNS를 기획한다면 한번 쯤 봐둘만한 책이라고 생각합니다. 이 책을 보고 나서 "AOF 기법(AOF methods)"이라는 것에 관심이 생긴다면 이참에 아예 시스템 분석/설계 쪽을 조금 공부해보는 것도 좋지 않을까 하는 생각이.

전에도 잠깐 얘기했지만, 기획자는 개발쪽을 조금 공부해보고 개발자는 기획쪽을 조금 공부해보면 참 좋겠습니다.

신고
새로운 분야(기획/디자인)를 공부한다는 것은 참 흥미진진한 일입니다.

전에 Designing for the Social Web 독후감에서 AOF 방법론을 소개하면서, 개발과 기획/디자인 사이에 유사한 점이 많다고 쓴 적이 있는데요, 오늘도 옆 자리 동료와 Windows 7 UI 시연 동영상을 보며 대화하다가 재미난 생각이 떠올랐어요.

바로 캐싱입니다. 성능이나 응답속도를 높이기 위해서 다양한 레이어에서 다양한 알고리즘으로 캐싱을 하는데, 캐싱에서 가장 중요한 수치 중 하나는 hit ratio 입니다. 즉, 또 쓰일 것 같아서 캐싱을 해 놓았는데, 또 안쓰이면 안된다는 것이죠(hit ratio가 낮다고 말합니다).

이게 디자인이랑 뭔 상관인가? 다양한 UI shortcut들(단축키, 툴바 아이콘 등)을 일종의 캐시라고 볼 수 있을 것 같아요. 자주 쓰일 것 같아서, 좀 더 빨리 접근할 수 있도록 여분의 자리를 할당해두는 것이죠.

So what?

다양한 캐싱 전략을 파보고, 캐싱과 유사한 다른 개념들(버퍼렁, 배치 프로세싱 등)에 해당하는 UI적 요소들은 무엇일지도 생각해보고 하면서 재미난 아이디어들을 끄집어내는겁니다.

신고
퇴근 전 3시간 동안 작업한 코드를 revert 했습니다. 하지만 3시간 동안 쌓인 spec은 지우지 않고 남겨뒀어요.

남은(혹은 얻은) 것은?
  • 새 IE 버그에 대한 지식
  • 설계 인사이트
  • 각종 상황에 대한 예제들(spec)

잃은(혹은 버린) 것은?
  • 버그를 피하기 위해 adhoc하게 넣었던 지저분한 코드 몇 Kbytes
신고
< Newer     Older >

티스토리 툴바