Django분류없음 2008/04/29 16:14 길게 쓸것도 없다.
Django 문서를 보다가 Mozilla Firefox 뒤의 MS Visual Studio 2003 .net 에 열려있는 C++ 소스코드를 보자 화가났다.이게 내 Django 감상의 전부다. CSV 사용에 대한 회의IT 2008/04/28 11:42도대체 어디에 쓰길래?나는 -실력, 적성이 어쨌던- 게임 프로그래머다. 게임 데이터는 작업자의 편의를 위해, 추가로 툴 프로그램을 작성하지 않기 위해 주로 엑셀로 작성하고, CSV로 저장된다. 툴 전담팀을 별도로 두지 않는 한 엑셀 이상의 기능은 커녕 동등한 수준으로 만들기도 어렵기 때문이다. 그래서 뭐가 문제인가?문제를 설명하기 이전에 먼저 CSV의 구조부터 설명할 필요가 있다 CSV의 구조CSV(Comma seperated values)는 이름 답게 필드는 , 로 구분하며 구조는 일종의 행렬에 가깝다. , 대신 탭을 쓰는 변종 포맷을 쓰기도 한다. 견고함견고한 행렬 구조 때문에 엑셀에서 편하게 편집할 수 있고, 비교가 수월하다는 장점이 있지만 어떨때는 독으로 작용한다. 구조상 2번째 필드는 xx, 3번째 필드는 oo… 이런식으로 강제될 수 밖에 없고, 코드의 수정 없이 열(필드)가 하나 추가/삭제 되면 데이터를 제대로 읽지 못하는일이 발생한다. 물론 한 국가에만 서비스하고, 릴리즈 이전에 프리징하는 회사라면 모르겠으나 그딴 회사가 한국에 존재할리도 없을정도로 한국 온라인게임은 한탕치기에 물들었다. 무슨 주식 작전하나? 해결책XML, YAML, JSON요지는 행과 열로 이루어지는 구조의 데이터를 사용하지 않는것이다. 열 하나만 추가되면 삐끗하는 데이터를 사용하기엔 데이터 관리가 너무 허술하니까. XML, YAML, JSON은 행과 열로 이루어지지 않는다. 각 마크업 언어에 대한것은 Just f***ing google it. 예한번 같은 데이터를 XML과 CSV로 작성해보자 뭐 비슷비슷하다. 오히려 한줄에 들어가는 CSV가 더 좋아보이기도 한다. 그러나 기획이 변경되어 속성이 하나 더 추가되었다고 해보자. 비록 코드 수정이 없으면 데이터가 제대로 읽히지 않는 일이 발생하지만 뭐 이래도 간단해 보이긴 하겠지. 하지만 Emerald Sword 에만 들어가는 속성을 하나 더 넣는다고 하자. 자 그럼 CSV를 사용할때는 필드를 하나 더 추가… 어라? 아이템 하나 때문에 필드를 새로 추가해야 한다고? 그래서 괜히 머리를 쓴답시고 Variant 따위의 필드를 추가하는 경우가 있다. 크하하하하! 그럼 나중엔 Variant2, Variant3 를 추가할 셈인가? XML은 간단하다, 필요한 곳에만 엘리먼트나 프로퍼티를 추가하면 된다. 와! 마치 마법같아요 젠장! 필요하지 않은 필드는 애초에 기입할 필요가 없어Yo. SAX로 읽어서 데이터를 짱박아두면 그저 OK? 개인적으로는 C/C++의 변경이 불가능한 struct/class와 python, lua 등 동적언어의 class 내지는 table을 보는듯 하다. python 이나 lua로 게임을 짠다면 프로그램 내부에서도 저런식의 동적인 데이터 관리가 손쉽게 가능할것이다. 이 글은 스프링노트에서 작성되었습니다. Shift분류없음 2008/02/18 03:20한국의 오타쿠는 왜 까이는가?
해답은 까이는 오타쿠들에게 있다. 아, 내가 말하고자 하는건 오타쿠들이 현실을 직시하지 못하고 자신들만의 세계에 빠져 살기때문이라는 입발린 소리가 아니다. 본론으로 들어가기 전에 한국의 오타쿠의 정의부터 제대로 하고 넘어가자. 위키백과의 오타쿠 페이지에 따르면 오타쿠의 사전적 정의는 다음과 같다.
네이버 백과사전의 오타쿠 페이지도 별반 다르지 않다. 그런데, 한국에서 오타쿠란 단어는 사전적 정의대로 쓰이고 있는가? 천만에! 애니메이션을 한번 본 것만으로 당신은 오타쿠의 경지에 이를 수 있다. 혹은 만화책을 빌리거나, 불법 스캔본을 다운받는 행위를 하지 않고 돈을 주고 구입하는 행위 역시 마찬가지다. 한국에서 오타쿠란 말은 그저 구실에 불과하다. (사실 오타쿠의 종주국 옆나라 열도도 별반 다를거 없다만.) 단도직입적으로 말해 오타쿠를 까는 주체의 대부분은 전, 혹은 현역 오타쿠 자신들이다. 아니라고 울고 불고 짜도 소용없다. 그럼 왜 오타쿠들은 동족상잔의 비극을 저지를까? 대의명분 따위는 없다. 질렸기 때문이다. 초대의 1~2세대 오타쿠들은 뒷 세대들의 수가 많아지면서 자신들의 마이너리티를 지키지 못하게 되자 질려버렸다. 물론 먹고 살기위해 바쁜것도 한몫하겠지. 이사람들은 현재 3~40대일테니. 급속도로 양산된 그 뒷세대들은 자신들의 취미생활이 비주류가 되기 시작하자 질려버렸다. 아, 참고로 몇년전까지만 해도 J-ROCK 이나 애니메이션을 구해서 보는건 나름 입지를 구축하던 시절이 있었다. 그 선두에 더 이상 깔것도 없는 에반게리온과 X-JAPAN 등이 있었다는건 공공연한 비밀 수준이다. 킥킥. 그들은 마이너리티를, 메이저리티를 획득하지 못해서 새로운 즐길거리를 찾아 떠났다. 스스로는 한걸음 내딛었다고, 진보했다고 생각하는 옆걸음을 했다. 이제 진일보 했다고 생각했으니 전에 하던건 형편없어 보이겠지? 그럼 이제 좀 까야지. 바야흐로 과거의 자신을 파묻어버릴 때가 아닌가. 이처럼 한국에서 오타쿠가 까이는건 특별한 이유가 없다. 메이저리티를 원했건 마이너리티를 원했건 다 제 잘났다고 주장하기 위함이다. 소위 오덕까들은 과거의 자신을, 자신이 즐겼던 문화를 매도하면서 새로운 아이덴티티를 구축하고자 한다. 덕후질에만 빠져 인생을 낭비한다거나, 취향이 이상하다거나 하는건 모두 핑계에 불과하다. 제대로 된 인식이 있는 사람이라면 굳이 설명하지 않아도 되겠지? 요새 솔직해지는게 유행인 모양인데, 말투를 거칠게 하는게 솔직한게 아니다. 좀 더 자신에게 솔직해져라. 당신의 하드 디스크에는 아직 애니메이션이 저장되고 있지 않은가. 달라진다고 해서 그것이 모두 진보라거나 진화인것은 아니다. 단지 옆으로 한발짝 움직였을 뿐. 이 글은 스프링노트에서 작성되었습니다. TDD 체험기IT 2008/02/09 00:02원래 설 연휴, 그저께부터 오늘까지 3일에 걸쳐서 TDD도 해보고 일지도 3부작으로 쓸 계획이었으나. 게으름과 몇가지 이유때문에 오늘 하루만 TDD 체험을 하게되었다. 오늘 하루, TDD를 하며 다음과 같은 점을 느꼈다.
뭐든 쉽게 질리는 내가 키보드를 비교적 오래 잡고 있을수 있었던건 짧은 테스트 주기와 코드 수정덕분이었다. 평소에는 완벽주의에 찌들어 실컷 생각만하다 지쳐 키보드에서 손을 떼어버렸는데, 테스트 주기와 코드 수정을 짧게 유지하라는 것과 테스트를 만족시키려 할때는 테스트를 빠르게 통과할지도 모르는 가장 간단한 방법을 쓰라는 것이 큰 도움이 되었다. 간혹 테스트보다 먼저 코딩하려는 스스로에게 어짜피 고칠 코드라면 너무 완벽하게 짤 필요는 없다며 손가락을 멈추게 하기도 했다. 완벽한 설계에 대한 걱정은 단순히 기우일 뿐이다. 여러 TDD 관련 글에서도 볼수있다시피 TDD에서 테스트란 일반적으로 말하는 테스트가 아니라, 행동 명세다. 내가 생각하는 행동 양식을 테스트 코드로 표현하고, 거기에 맞추어 구현하면 된다. 물론 행동 명세가 자세할수록 자신이 원하는 구현에 근접하게 될터이니 테스트를 잘 작성하는것이 중요하다. 간혹 몇몇사람들은 TDD를 하면 막무가내 디자인이 나오는게 아니냐고 하지만, 그건 틀린말이다. 코드는 한번 짜고나면 건드리지 않는 존재가 아니다. 코드는 끊임없이 리팩토링 해야한다. 좋지 않은 냄새가 나던 디자인도 테스트가 추가되고, 리팩토링을 하면서 훨씬 좋아진다. 에러가 발생될까 하지 못하던 리팩토링도 테스트코드가 있기 때문에 부담이 확 줄어든다. 이런 과정을 통해 코드는 훨씬 나은 디자인으로 수렴해간다. 그러나 양이 있으면 음도 있는법. TDD 체험을 진행하며 나에게 Alt+Tab을 누르게 한 요인들은 다음과 같다.
내가 원하는 명세를 생각하는것도 문제였지만 제일 큰 문제는 원하는것을 테스트로 어떻게 나타내야할지 모를때였다. 개체 내부에 있는 배열에 값을 복사할때, 할당한 메모리 영역을 넘는지 안넘는지 알게 뭔가! 그래서 버퍼에 값을 넣을때 얼마만큼 소스에서 복사했는지 리턴하도록 추가하고, 새로운 테스트를 작성했다. 문제는 해결했지만 영 찝찝한것이, 이게 TDD에서 말하는 테스트가 용이한 디자인인지 아닌지 헷갈리거니와 테스트간에 의존성이 생긴다는 것이 영 맘에들지 않았다. 이처럼 테스트와 디자인 모두 TDD에 내맡길수 있는것이 아닌, TDD는 그저 보조 도구라는것을 실감하게 되었다. 처음 TDD를 시도하는 나에겐 좀 버거운감이 있었다. 이러니 저러니 말은 했지만 처음 해보는 TDD는 꽤 괜찮은 느낌이다. 이런 느낌으로 코딩해본게 얼마만인지 모르겠다. 지금 하고있는 IRC 데몬 프로젝트는 앞으로도 계속 TDD로 진행해 나갈것 같다. 이 글은 스프링노트에서 작성되었습니다. 게임 기획이라는 이름의 잡탕분류없음 2008/02/05 13:32회사에서 열심히 땡땡이치며 HanRSS 새 글을 보던 중, 써니님의 포스팅이 눈에 들어와서 읽어보았다. 써니님은 조직의 리더에 대해 얘기하셨지만, 나는 우리나라의 게임 디자인 -보통 기획이라고 잘못 쓰이는- 에도 같은 문제가 존재한다고 생각한다. 비록 게임 디자이너가 사람을 다루는 직업은 아니나, 열정만 가득한 누군가들이 주어진 뭔가를 망쳐놓을 가능성은 매우 크다. 게임 디자인도 별반 다르지 않다. 우리나라 게임 업계의 게임 디자인 수준은 바닥에 가깝다. 기획자의 존재가 자리잡은것도 얼마 안될뿐더러, 구현하는것도 빠듯했기에 퀄리티를 논할 환경이 갖추어지지 않았으니까. 자본이 유입되고 시장이 커진 지금은 학문적인 접근과 연구를 통해 정신을 차려나가고 있다. 그러나 개인적으론 게임 디자인의 수준이란게 그닥 올라가진 않고있다 생각한다. 그게 뭔 소리냐고? 힘의 총 합 과거 패키지, 싱글게임과는 달리 우리나라 시장의 대부분을 차지하는 온라인 게임은 서비스 기간에도 개발이 계속 진행된다. 그러다보니 게임 디자이너가 중간에 몇번씩이나 바뀌게되고, 그때마다 게임의 방향이 바뀌게된다. 중학교 시절에 물리 부분을 졸지 않고 들은사람이라면 각기 다른 방향의, 엇비슷한 힘들의 총합이 어떻게 되는지 잘 알터이다. 한명의 항해사가 계속 키를 잡는게 불가능 하다면, 적어도 후임 항해사는 기존의 항해도대로 키를 놀려야 할게 아닌가. 물론 어긋나는 부분을 다듬지 말라는 소리는 아니다. 적어도 미국으로 갈 배가 중국으로 가지는 말아야지. 열정이라는 미명하에 각자 자신의 획기적인 디자인을 들이대봤자, 남는건 프로그래머들의 조소뿐이다. 자신들의 구현체가 UO, 디아블로, 아바타 채팅게임으로 변검술하듯 바뀌는 탓에 그들은 게임에 대한 애착을 잃었다. 리차드 개리엇이 떠난 후 울온블로라고 불리는 울티마 온라인 내 시야가 좁은탓도 있겠지만, 국내 웹을 돌아다니며 기존 게임을 살리는 기획에 대해서는 글을 본적이 없는듯 하다. 적어도 꽤나 유명한 블로그들이나 사이트에서 그런 주제가 보이지 않으니, 그런 논의가 있어도 메이저한 주제는 아닌게 아닐까. 프로그래머들이 리팩토링이네 유지보수네 하며 사후처리에 꽤나 공을 들이려하는 모습과는 사뭇 다르다. 이제, 게임 디자인에도 리팩토링이 필요하다. p.s. 그럼에도 불구하고 대부분의 국내 온라인 게임들이 업데이트를 해도 나아지거나 달라지는 점이 없는건 애초에 방향이 없기 때문이다. |
|
이올린에 북마크하기
이올린에 추천하기
