작년 11월 14일 KGC 2008에서 발표했던 강연의 문서입니다



신고
by 흥배 2009.03.21 13:09

DB 툴의 보안 문제

 

제 강연에서 소개한 DB 툴과 비슷한 것을 만들어 본 분들이라면 이 툴의 가장 큰 문제점을 알고 있으리라 생각합니다. 가장 큰 문제는 바로 보안입니다.

 

온라인 게임에서 아주 중요한 것이 DB에 있는 데이터인데 DB툴은 이 데이터를 손쉽게 변경할 수 있기 때문에 누군가 악의적으로 사용하면 큰 재앙이 일어납니다.

 

사례 소개에서 C#으로 만든 것에 대한 소개를 집중적으로 할 생각이 아니라서 큰 부분 단위로 설명을 했습니다. 사실 DB 툴은 처음 강연 문서에는 없던 것이었습니다.

제가 처음 KGC에 강연 신청을 할 때는 강연 제목에 ‘DB 이라는 단어가 있었지만 이후 강연 확정을 할 때는 뺐습니다. 그런데 11 5일에 했던 예비 강연회를 앞두고 KGC 홈페이지에 보니 제 강연 제목에 ‘DB 이 들어가 있더군요. 제목에는 DB 툴 이라는 단어가 있는데 강연에 관련 내용이 나오지 않으면 청중들이 좋지 않게 생각할 것 같아서 예비 강연회 이틀 전에 추가 했습니다.

 

예비 강연회를 한 후에 황제펭귄님이 이 DB 툴의 문제점을 그분의 경험을 토대로 이야기 해 주셨습니다. 그때 그분께 답장을 드릴 때 저도 그 부분은 알고 있으며 제 강연 주제가 ‘DB 은 아니므로 일부러 언급하지 않았다고 이야기 드렸고 본 강연회도 할 계획이 없다고 이야기 했습니다.

그런데 지금 생각해보니 강연을 할 때 간단하게라도 이야기를 하는 것이 더 좋았을 것이라고 생각이 됩니다.

 

 

강연에서는 나오지 않았지만 제가 만든 DB 툴은 실행을 하면 로그 인을 해야 됩니다. 그리고 유저마다 레벨이 부여 되어 있는데 레벨에 따라서 DB 툴을 조작할 수 있는 권한이 다 다릅니다.

일단 이것으로 개발할 때의 보안을 갖추었습니다.

 

실제 서비스 단계에 들어갈 때는 보안을 더욱 더 견고하게 합니다.

DB 툴을 만질 수 있는 사람을 제한하고., 실행 할 수 있는 PC의 제한도 생각 중입니다.

DB툴을 조작하는 행동에 대한 로그를 남겨야 됩니다.

또 보안을 더 강하게 할 때는 중간에 미들웨어를 넣어서 DB 를 조작하게 하려고 합니다.

어떤 방법까지 할 것인지는 아직은 생각에 머물러 있습니다.

 

강연 후 어떤 분이 DB 툴을 운영 툴과 연계 하는 것에 대해서 질문 하셨는데 이럴 때는 로그인 한 유저의 등급에 따라서 메뉴가 다르게 되도록 해야 됩니다(즉 운영자는 운영과 관련된 메뉴와 기능만을 사용하도록 해야 됩니다).

 

저는 현재 운영 툴을 만든다면 DB 툴과는 별도로 따로 만들 생각입니다( 실버라이트로 만들어 보려고 합니다 ).

 

 

윈도우 비스타를 보면 보안을 올린 대신 사용에 불편한 점이 있습니다. RIA들도 보안이 높은만큼 기능에 제한이 있습니다. DB 툴도 보안과 사용성은 양날의 칼입니다.

 

 

ps : 참고로 DB 툴에서 게임 테스트에서 사용할만한 기능을 넣은 이유는 [A/S 1]에 적어 놓았습니다.

신고
by 흥배 2009.03.21 12:41

C#으로 툴 개발에 사용하는 경우 개발할 때 사용한 C# API(정확하게는 .NET Framework API 겠죠) 사용법을 잘 정리해 놓으면 좋습니다.

 

아직은 C++이 메인 프로그래밍 언어로 사용하고 있으면 이것을 사용하는 시간이 훨씬 많고 C#은 툴을 만들던가, 이미 만들었던 것에 기능을 추가하던가 버그를 수정할 때만 사용하게 됩니다. 그래서 한번 사용한 API도 잊어버리기 쉽습니다.

 

물론 잊어버리면 MSDN이나 관련 책을 보면 됩니다. 그러나 이렇게 하면 쓸데 없는 시간을 낭비하게 됩니다. 보통 C#의 모든 API를 사용하기 보다는 자주 사용하는 것이 거의 정해져 있습니다. 그러니 그것만 잘 정리하면 이후에는 MSDN이나 책을 볼 일도 줄어듭니다.

 

저의 경우는 100%까지는 아니지만 대부분 새로운 C# API를 사용할 때마다 스프링노트에 분류를 한 후 기록합니다. 이렇게 하면 저의 경험을 정리하는 것도 되어서 좋고 다음에 프로그래밍 할 때도 사용법을 잊어버려 찾는 시간이 많이 절약 되더군요.

 

또 이렇게 정리해 놓으면 다음에 다른 사람이 툴 제작을 물려 받게 될 때 쉽게 기술 이전을 할 수 있습니다. 새로운 사람이 C#을 잘 모르더라도 C#의 기본적인 것을 안 후 툴 제작에 사용했던 API 사용 법만 보면 물려 받은 툴을 어떻게 만들었는지 빠르게 알 수 있습니다.

 

자신이 프로그래밍에 사용했던 기술 정리는 꼭 C# 사용 법만이 아닌 게임 제작에 사용했던 것도 정리하면 좋습니다. 이렇게 해 놓으면 예전에 사용했던 기술을 다시 보기 위해 소스코드를 뒤지지 않아도 되니까요.



사용자 삽입 이미지

스프링노트에 기록하고 있는 화면입니다.



신고
by 흥배 2009.03.21 12:40

14일 강연을 했을 때 질문을 했던 분이 계셨는데 그날 강연 시간을 이미 넘겨 버려 사람들이 다른 강연을 들으러 나가는 상황이라서 질문을 제대로 받지 못했습니다. 그래서 질문 했던 분이 저한테 와서 질문을 하셨는데 그때 제 생각을 제대로 전달하지 못한 것 같아서 블로그를 통해서 이야기 하려고 합니다.

 

질문 중 회사의 다른 프로그래머들이 C#으로 툴을 만들면 유지보수가 힘들어지므로 반대하고 있는 어떻게 해야 되나 에 대한 제 의견입니다.

 

반대를 하는 사람이 팀에서 어떤 위치에 있느냐가 가장 문제가 될 것입니다. 거의 대부분 팀에서 리드 급의 경력이 많은 프로그래머들이 반대를 하는 경우가 많고 C#을 사용하려고 하는 프로그래머가 경력이 낮은 경우 이것이 가장 C#을 사용하는데 가장 큰 벽이 됩니다.

제 경우는 C#으로 툴을 만들려고 할 때 팀의 팀장님이 C# 사용을 추천해 주었고 그때의 저의 나이나 경력이 낮지 않았기 때문에 반대가 없었습니다.

 

강연을 할 때 이야기 했듯이 경력이 많고 실력이 좋은 분들일수록 지금 사용하고 있는 C++, MFC에 익숙해져 있기 때문에 이제는 단점에 대해 별로 고민을 하지 않고 있습니다. 그래서 오히려 새로운 언어를 배워야 되는 것이 훨씬 더 이분들은 불편하게 생각하고 있을 것입니다.

전부는 아니지만 C#을 싫어하는 이유는 기술적인 이유보다는 감성적인 이유로 싫어하고 있습니다.

그래서 반대를 하고 싶은데 반대 이유 중 가장 설득력 있다고 생각하여 말하는 것이 “C#으로 툴을 만들면 새로운 언어를 배워야 되니 유지 보수하기가 어려워진다라는 것을 이야기 합니다.

 

정말 C# 때문에 유지보수가 힘들어질까요? 저는 아니라고 생각합니다.

C# 때문에 C#을 모르는 사람은 이것을 배워야 되는 시간이 필요한 것은 확실합니다.

그러나 이것 때문에 소비하는 시간 보다 C#을 사용하여 만들 때 이득을 본 시간, 앞으로 툴을 유지보수(기능 추가 구현 등) 하면서 이득을 볼 시간을 계산하면 전체적으로 훨씬 더 이득을 봅니다.

 

C++을 알고 있는 사람을 기준으로 본다면(게임쪽 프로그래머는 거의 100% C++을 알고 있으니) C#을 학습하는 시간은 아주 짧습니다. 만약 학습에 시간이 많이 걸렸다면 그것은 MS에서 C#을 정말 개떡같이 만들었던가, 배우는 사람이 C++을 제대로 배우지 못한 사람이라고 생각합니다.

 

C#도 깊숙하게 자세하게 공부한다면 꽤 많은 시간이 걸릴 것이라고 생각합니다. 그러나 툴을 만드는데 사용하는 정도는 꼭 깊게 공부할 필요가 없습니다. 딱 툴을 만드는데 필요한 정도만 일단 학습을 한 뒤 이후 틈틈이 시간을 내서 공부를 하면 됩니다.

 

C#으로 툴을 만들 때 아주 이상하게 프로그래밍하지 않는다면 코드 복잡도 면에서 훨씬 더 C++로 만든 것보다 단순하기 때문에 코드 분석도 더 쉽습니다.

 

우리 프로그래머들은 언제나 공부를 하고 기술을 배운다고 다른 사람들에게 이야기 하는데 C# 이라는 새로운 언어를 배우는 것은 왜 그렇게 인색한지 모르겠습니다. C#이 아주 마이너하고 배우기 어렵고 비 실용적인 언어가 아닌데 말이죠.

 

 

앞에 한 질문에 대한 제 답은 ‘C#으로 툴 만드는 것에 대하여 반대하는 이유가 확실하게 기술적으로 보여주는 객관적인 것이 아니라면 거의 주관적인 감성에 의한 반대이므로 설득하기가 쉽지 않다고 생각합니다. 만약 기술적인 부분이라면 그것에 대해 기술적으로 해결책을 보여주면 되지만 감성적으로 반대를 하고 있으면 설득할 답이 마땅히 없습니다. 그래서 저도 반대 하는 사람들을 설득할 수 있는 방법을 확실하게 제시 할 수는 없고 아래에 몇 가지 의견을 이야기 하겠습니다.



1. 반대하는 사람들에게 명확하게 기술적으로 어떤 부분이 문제인지 물어보세요

2. 기술적인 문제를 이야기 해주면 그것에 대한 해결책을 정리해서 이야기 해주세요

3. 이미 여러 곳에서 C#으로 툴을 만들어 사용하고 있음을 이야기 해주세요. 적지 않은 게임 회사에서 사용 중이고, 언리얼 엔진, 게임 브리오 엔진의 툴의 일부는 C#으로 만들어져 있습니다.

4. 개인적으로 만들어 사용할 툴을 C#으로 만들어서 사용해 보세요.

5. (좀 과격한 것 같지만) 새로운 것을 싫어하지 않는 회사()에 가서 일하세요.

 

 

물론 모든 툴을 만드는데 C#이 최고라고는 절대 생각하지 않습니다. 어떤 경우에는(특히 자주 코드 변화가 생기는 C++ 코드를 사용하는 경우) C++를 사용하는 것이 더 좋을 수도 있습니다.

그러나 대부분 C#을 사용하는 것이 훨씬 더 좋습니다.

 

ps : C# 이라는 것은 .NET Framework에서 프로그래밍 하는 것을 통칭하기도 하는 말입니다. 그러니 VB.NET 이나 C++/CLI를 사용해도 좋습니다.


신고
by 흥배 2009.03.21 12:38

Monaca님의 블로그에 제 강연에 대한 글이 있어서 트랙백으로 저의 답변을 남깁니다.

http://monac.egloos.com/2137361


궁금해 하는 부분에 대해서 답변을 적었는데 꽤나 길어졌습니다. 이런 것은 강연에서 말로 이야기 했으면 쉽게 끝나고 전달도 더 쉬운데 시간 관리 실패로 그런 시간을 가지지 못한 제 잘못이 크다고 느껴지네요.

 

 

 

[질문] 도구들을 쓰고, C#이 좋다는 점도 좋지만, 그것을 개발하면서 팀에서나 회사에서 구성원에게 어떤 변화 ?

 

본인 : C#을 사용하면서 예전에 Rapid 툴에서 선전 문구로 나오는 생산성에 대해서 몸으로 느끼게 되었습니다. 그전에는 머리로만 이해하고 있었다는 정도입니다. C#을 사용 해보니 프로그래밍 하기가 너무 편합니다. 그래서 예전에는 인 하우스 개발 툴이 필요하다고 생각은 하지만 정작 만들지는 않고 있었는데(만들려니 일이 까다롭고 시간이 걸릴 것 같아서) C#을 사용한 이후부터는 생각에서 그치지 않고 만들 수 있는 것은 만듭니다.

C#으로 이득을 보니 왠진 또 다른 언어를 사용하면 또 다른 이득을 얻지는 않을까라는 생각을 하게 되어서 다른 언어 공부 및 활용이 이전보다 훨씬 더 적극적이게 되었습니다.

 

툴 개발에 대한 부담이 없어져서 기획자나 그래픽 디자이너 분들에게 저는 틈틈이 이야기 합니다. 툴이 있으면 일이 편해지고 더 빨라 질 수 있다면 이야기 해 달라고 합니다. 예전 같으면 툴 만들어 달라고 하면 귀찮아질 테니 그분들이 힘들어하더라도 모른척하지 않았을까 생각합니다.

그러나 지금은 제가 적극적으로 필요하면 요청해 달라고 합니다.

 

 

동료 프로그래머 : 저는 C#을 게임 개발에 사용하면서 강력하게 다른 프로그래머에게 권하지는 않았습니다. 이유는 C#을 배우지 않는 이유는 기술적인 문제보다 감성적인 문제이기 때문에 제가 권해봤자 별로 먹히지 않으리라 생각하기 때문입니다. 그래서 팀의 다른 프로그래머에게 준 영향은 거의 없다고 봐도 될 것 같습니다.

 

 

기획자 : 제가 이분들과 툴에 대해서 많은 이야기를 나누지 않아서 잘 모르겠지만 제가 만든 툴을 사용하여 저의 도움 없이 서버, DB의 게임 데이터를 조작 할 수 있으니 눈치 보지 않고 일하셨다고 생각합니다.

눈치를 본다는 말은 개발을 할 때 밸런스를 잡기 위해 게임 데이터(아이템이나 스킬 등)을 변경 해야 되는데 툴이 없으면 언제나 저에게 와서 이야기를 한 후 제가 관련 일을 해야 적용 되는데 이렇게 되면 저를 너무 귀찮게 하는 것 같아서 그분들이 자제를 하려고 합니다. 이렇게 되면 하루에 10 ~ 100 번 데이터 변경을 해서 가장 좋은 밸런스를 잡을 수 있는데 저를 배려하여 2 ~ 3번만하고 끝내버려서 더 좋은 결과를 얻을 수 없게 됩니다.

제가 C#을 사용하여 원하는 기능을 최대한 빨리 제공하여 그분들이 프로그래머의 도움 없이 프로그램(게임)을 변경할 수 있는 자유를 주었다고 생각합니다.

 

 

게임을 만들 때 프로그래머는 기획자가 요청한 대로 버그 없이 돌아가는지에 중점을 두지 아이템 데이터 값이 어떻게 될지, 스킬 데이터 값이 어떻게 되는지는 큰 관심이 없습니다. 이유는 이것을 할 사람들은 일반적으로 기획자들이 하기 때문입니다. 그런데 툴 같은 것이 없으면 데이터의 값은 기획자가 입력을 하지만 그것의 적용은 프로그래머를 걸쳐야 되기 때문에 프로그래머는 자꾸 기획에서 뭘 해달라고 하면 지금 하는 일에 방해가 되어 요청 횟수가 많아질수록 짜증이 나기 시작하고, 기획자는 개인적인 부탁이 아니고 공적인 부탁인데 본의 아니게 프로그래머를 귀찮게 하게 되니 어중간한 선에서 일을 끝내버립니다(특히 일이 바쁠 때).

툴이 있어서 기획자에게 자유를 주면 일을 어중간하게 끝내지 않고 그들이 할 수 있는 가장 최선의 결과를 만들어냅니다.



비 프로그래머 게임 개발자의 경우 게임 개발 경력이 많을수록 타 파트 개발자가 고생하지 않도록 배려를 하려고 합니다. 그런데 이것이 오히려 문제가 될 때가 있습니다. 어떤 일에는 정말 툴을 사용하면 쉽게 끝나는데 툴 제작 요청을 하면 바쁜 프로그래머에게 피해를 줄까 봐 조용히 혼자서 노가다 짓을 합니다.

모든 툴들이 개발 기간이 긴 것이 아니기 때문에 때로는 저희가 금방 만들어서 주면 쉽고 빠르게 일할 수 있는데 선의의 배려 때문에 당사자는 노가다로 쌩 고생하고, 이것 때문에 결과물이 늦게 나오면 마지막 작업을 하는 프로그래머는 대기를 해야 되기 때문에 실 작업 시간이 짧아져버리는 문제가 발생하여 서로 고생을 하는 경우가 있습니다.

 

저는 툴 개발에 대한 껄끄러움이 없어졌기 때문에 이 분들에게 적극적으로 요청을 하라고 이야기 하기 때문에 최고한 저한테 툴 요청을 하는 것에 대해서는 부담 없이 적극적으로 말 할 수 있지 않을까 생각합니다.

 

 

 

[질문] DB Tool에서도 DB Tool을 쓰니 테스트가 편해졌다고 하지만, 테스트 셋을 만들고, 이를 자동으로 모두 테스트하는 기능을 만들면 결국 그게 TDD가 되는 게 아닐까하는 생각도 들었습니다. dbUnit을 써도 되겠다는 생각도 들지만, 한편으론 QA가 각 단계별 테스트에 필요한 조작이라 좀 다르기도 할테고, 스크립트가 내장된 더미 클라이언트가 더 좋지 않을까요. 5개 연퀘라면...
더미 클라이언트 스크립트에서 1번 퀘스트 NPC로 이동하는 패킷 쏴 주고, 스크립트로 퀘스트도 받게 해주고(accept qno 130 이런 식이면 되겠죠. 단축어는 괜찮아요. 어차피 인하우스니까 questno 이렇게 길게 안 해도 된다 이거죠. 물론, 신참은 나중에 학습이 필요하겠지만, QA는 명령어 덜 치고, 스크립트 할때 키보드 덜치는 게 좋아요
.
그리고 몹 5마리 잡는 퀘라면 완료 상태로 만들어주는 거죠.(kill monster 100 5, 100번 몬스터 5마리 죽였음이라고 명령하면 패킷쏴서 그렇게 인식하게 하면 되지 않을까요?)

이런 식의 더미 클라이언트와 스크립트가 있다면 DB Tool에 의한 테스트는 덜 해도 되지 않을까,
어쩌면 아직 중간 단계가 아닐까하는 생각이 들었습니다. 이건, 1일차에 들은 리니지2 프로덕션 시스템의 더미 클라이언트가 거의 그런 식이기 때문이죠. 그게 더 편해 보이구요. 자세한 것을 모르니 더 얘기하는 건 폐만 될테니... ^^

 

먼저 제가 이야기한 테스트 부분은(특히 강연에서 예로 든 퀘스트) 다른 사람의 요청에 의해서 만든 것이 아니고 제가 필요해서 틈틈이 만든 것입니다. 제가 구현 후 테스트를 하려니(QA에 넘기기 전에 제가 최대한 테스트 하여 버그를 잡아야 되니까요) 그냥은 너무 힘들어서 만들었고, 그것을 기획자나 QA에게 가르쳐 주니 잘 사용 하였습니다.

 

테스트를 하기 위해 필요한 기능을 따로 작업 시간을 만들어서 한 것이 아니라서(즉 정식적인 요청에 의해서 한 것이 아니라) 저 혼자서 해야 되기 때문에 DB 툴에 기능을 넣었습니다. 만약 클라이언트에 넣으려면 정식적인 요청을 해야 되고, 요청을 하면 클라이언트 프로그래머가 작업을 해주기 전에는 구현이 불가능하고 또 이후에 어떤 변경이 있다면 같이 작업을 해야 되기 때문에 좀 까다로워집니다. 그러나 DB 툴에 구현해 놓으면 저 혼자서라도 구현할 수 있으니 제 입장에서는 이것이 더 편했습니다.

강연에서도 이야기 했지만 개발이 중반 이후를 넘어가면 정말 바빠집니다. 특히 프로그래머 파트에서는 클라이언트 파트가 해야 될 것이 많아서 서버보다 작업 속도가 뒤쳐져 있는 경우가 많습니다. 이런 상황에서 클라이언트 플머에게 게임 자체의 일이 아닌 것을 부탁하기가 참 힘들어집니다.

 

게임 클라이언트에서도 이야기 한 것과 비슷한 치트 기능을 당연히 가지고 있습니다. 캐릭터 레벨, 돈 등의 변경을 클라이언트에서도 할 수 있게 만듭니다. DB툴은 클라이언트에서 할 수 있는 치트 기능도 가지고 있으면서 그 이상의 치트 기능을 가지고 있는 것이죠.



치트 기능에 대해서 이야기 하자면 일반적으로 가장 빠르게 구현하는 방법은 글자 조합을 사용하는 것입니다. 예를 들면 돈을 1000으로 만들기는 ‘cheat money 1000’라는 글자를 채팅 창에 적으면 적용되도록 하는 것이죠. 그런데 모든 것을 이렇게 할 수는 없고 때로는 GUI 기능이 들어가야 됩니다. 문제는 비 프로그래머들은 쉽게 구현 될 것이라는 GUI 작업이 생각 이외로 시간을 잡아 먹을 때가 있습니다. 그렇다고 GUI를 넣지 않으면 치트 기능을 구현 할 수 없는 경우도 있습니다.

이럴 때 DB 툴에 해당 기능을 넣는다면 사용하는 부분에서 조금은 불편해질 수도 있지만 빠르게 구현하여 제공할 수 있게 됩니다.

또 미약하지만 DB 툴에 게임 외적인 부분이 구현되니 게임 프로그램에는 최대한 실제로 구현 해야 될 것만 구현 되어 있어서 유지보수 적으로 좋기도 합니다.

 

개인적인 경험으로는 치트 기능도 GUI 기능이 있는 것이 좋았습니다. 텍스트 기반의 치트는 문제점이 명령어를 외워야 되는 것입니다. 이런 경우 치트 기능을 자주 사용하는 사람은 기억을 하지만 가끔씩 사용하는 경우는 치트 명령어를 잊어버려서 사용하기가 까다로워지더군요.

그래서 이전 회사에서 치트 기능을 만들 때는 처음에는 텍스트 기반으로 빨리 만든 후 이후에는 GUI 기반으로 메뉴 선택으로 치트 기능을 사용하도록 하였습니다.

 

 

ps : 다른 분들도 궁금한 부분은 의견을 남겨 주셨으면 합니다.^^


신고
by 흥배 2009.03.21 12:36
| 1 |

티스토리 툴바