게임개발자 지망생님들, 질문에 답해드리겠습니다

안녕하세요. 이젠 하도 들어서 꽃미남이란 별명이 좀 질릴까 하다가도 여전히 부정할 수 없는 현실임이 안타까운 여전히 꽃미남 게임 프로그래머 포프입니다. (제가 태어나서 써 본 것 중 가장 긴 문장입니다. 뿌듯합니다.... -_-)

이제 본문 입니다... -_-

요즘 나름 바빠졌습니다

개인 블로그에 북미취업 가이드와 쉐이더 입문 강좌를 연재하고, 게임개발포에버를 시작한 후로 한국에서 이런저런 문의를 해오시는 분들이 상당히 많으십니다. 현직 게임개발자분들도 계시고 게임개발자 지망생분들도 계시지요. 저도 답변해드리면서 배우는 점도 많고 새로 깨닫는 것도 많아서 여태까지 모든 분께 열심히 답을 해드렸습니다만...

하지만 가끔 당혹스러운 질문이....

사실 가끔 너무나 광범위한 질문을 해오시는 분들에게는 답을 해드리기가 참 어렵습니다. 보통 현직 개발자분들 보다는 지망생 분들이 좀 이런 경항이 강하지요. 예를 들어..

"게임개발자가 되는게 제 인생의 꿈입니다. 어떻게 해야 게임개발자가 될 수 있죠?"

이런 질문을 볼 때마다 솔직히 당혹스럽습니다. 제가 영미권에서도 학생들의 질문도 많이 받는 편인데 이런 질문을 해오는 사람들이 거의 없었거든요. 그래서 첨엔 정말 많이 당혹스러웠죠. (물론 아직도 많이 당혹스럽습니다.) 뭐든간에 이렇게 질문이 시작되면보통 8~90프로는 다음과 같이 마무리 됩니다.

포프: "게임을 만들어는 보셨어요?"
지망생: "아뇨. 아직 만드는 법을 안배웠어요. 아직 대학을 안가서요.(아니면 그와 유사한 이유들...)"
포프: "학교에서 배운다고 게임개발자 되는거 아니에요. 일단 게임부터 만드세요. (그리고 이런저런 리소스들을 알려준다)"

현직 개발자분이시라면 다들 한번 쯤은 지망생들과 이런 대화를 해보셨을거고, 그리고 실력이 너무나 출중하신 많은 분들이 더 이상 이런 질문에 답변을 해주지 않으십니다. 왜 그럴까요? 이런 질문 하시는 분들 중의 상당히 대다수가 결국 게임개발자가 안되고 현직 개발자 분들은 이런 분들의 개인비서가 되서 게임제작 자료나 찾아주는 일을 해주는데 질렸기 때문이지요. 한마디로 더이상 이용당하고 싶지 않으신 겁니다.

게임개발자가 되려면 게임을 만드세요

저도 한 때 게임개발자가 되고 싶어하던 어린이었던 때가 있고, 잠시 게임개발하다가 법대생이 되서 외도한뒤에 다시 게임계로 돌아오려고 나름 고생한 놈으로써 제 경험담을 말하자면.....

제가 "난 게임을 만들꺼야"라고 꿈을 꾸고 살던 때에 만났던 친구들이 꽤 있습니다. 저랑 비슷한 꿈을 가진 친구들이었지요. 하지만 정작 말만하고 이런저런 핑계 실제 허접한 거 하나라도 만들지 않은 친구들, 또는 그냥 관련학과만 가서 졸업한 친구들 중에 게임개발자 된 친구들이 없습니다. 다들 게임을 만드는게 인생의 꿈이라고 했던 친구들인데.... 네... 없습니다.

이건 사실 매우 당연한 이친데 왜 이해를 못하시는 분들이 있으신지 모르겠습니다. 소설가가 되는게 인생의 꿈인데 어릴 때부터 글을 한번도 안써본 학생이 있을까요? 단 남의 소설은 많이 읽었지요. 춤추고 노래하는 가수가 되고 싶은데 어릴 때부터 춤 안추고 노래 안해본 학생이 있을까요? 물론 TV에서 가수들 노래하고 춤추는건 많이 봤지요. 야구선수가 되고 싶은데 어릴 때부터 한번도 농구를 안해본 학생이 있을까요? 물론 프로 야구선수들이 경기하는건 많이 봤지요.

이쯤되면 대충 제가 하려는 말이 무엇인지 아실겁니다. 정말 게임을 만드는 게 인생의 꿈이고 정말 이걸 안하면 죽는다고 믿고 계신데 아직 만들어본 게임(또는 그와 유사한게) 없다면 한 95프로는 그냥 세뇌당하셨거나 자기최면 거신겁니다. (물론 정말 사정이 있어서 못하신 분들이 한 5프로 있다고 해드리지요. 근데 다들 본인이 5프로 안에 든다고 우기시면.... 못써요.....) 뭐가되었든 간에 전 이런 분들에게도 답변을 최대한 한다고 해왔는데 사실 마음이 무거웠습니다.

"이렇게 이렇게.. 게임을 우선 만들어보세요.(또는 그림을 그려보세요. 또는 게임 아이디어를 정리해보세요 등등)"

라고 제가 드리는 답변은 말은 사실...

"그렇게라도 안하시면 가망성이 좀 많이 없어보여요."

라는 뜻이거든요. 물론 제 판단도 가끔 틀립니다. 틀릴땐 틀렸다고 인정도 하고요. 근데 거의 십중팔구는 제 판단이 맞습니다.

위에서 영미권 학생들로부터도 질문을 많이 받는다고 말씀을 드렸었습니다. 근데 한가지 다른 점은 영미권 학생들의 질문이 매우 구체적이라는 겁니다. 보통 자기 스스로 뭔가 만들어보려고 깨작여봤고 거기서 막히는 것들에 대한 질문.. 혹은 더 나은 방법이 없는지 조언을 구하는 질문 등이 대부분입니다. (물론 게임업계의 근무여건이 대해 묻는 사람들도 있긴 합니다.) 이런 질문에 대답을 할 때는 정말 그 학생에게 뭔가 큰 힘이 되는거 같아 제 마음도 뿌듯합니다. 한국분들 중에도 이렇게 뿌듯한 질문을 해오시는 분들이 있는데 안그런 분들이 좀 너무 많습니다. 현재론....

게임개발자 지망생님들... 질문하시려면요...

언제나 그렇듯이 또 주저리 주저리 말만 많이 썼습니다. 제가 사실 하고픈 말은 이겁니다.

1. 전 아직도 게임개발자가 될 꿈을 꾸시는 분들에게 힘이 되고 싶습니다. 그리고 저도 이런 분들하고 대화하면서 얻는 게 많습니다.
2. 하지만 꿈만 꾸시는 분들에게 일일이 답해드리느라, 정말 뭔가 열심히 하시는 분들에게 소홀해지는 게 아쉽습니다.
3. 따라서 앞으로는 직접 만드신 게임(또는 유사한것.. 예: 그림, 프로그래밍, 게임 아이디어 등등)을 먼저 보여주시지 않는한 진로에 관한 질문에는 답변을 드리지 않겠습니다.
4. 그리고 혹시나 해서 하는 말인데.... 어떻게든 제 허접한 답변 받아보시겠다고... 남의 작품을 훔쳐서 본인이 만든 것인척 하시는 분들이 계시면 게임업계에 이름을 널리 퍼뜨려 드리겠습니다.
5. 그리고 질문하시기전에 충분히 리서치(구글에서라도)도 해보시기 바랍니다. 구글에서 쉽게 나오는 질문에도 답변 해드리지 않겠습니다.
6. 이렇게 하면 질문자 분들께서도 알아서 포트폴리오를 만드는 겪이 되니 본인 인생에도 도움이 되는 거라고 믿습니다.

마지막으로 한마디

제가 한 악담(?)이 틀렸다는걸 보여주기 위해 이 악물고 열심히 해서 멋진 게임개발자 되신 분들이 있다면 디스 쏴주세요. 진심으로 축하해 드리겠습니다.


p.s. 사실 요번엔 게개포 연재 거를려고 했는데 게임개발자지망생 진우님이 글 쓸 거리를 주셨습니다. 감사합니다. 올해 대학들어가신 새내기인데 학교에서 가르쳐 주지도 않는 C/C++을 독학하며 나름 간단한 게임부터 만들어보고 있으십니다. 이런 자세 본받으시길 바랍니다.

컴파일 경고하나당 3 대씩 맞습니다

컴파일 경고(warning) 얼마나 신경쓰세요? 현재 작업중인 코드베이스를 컴파일하면 경고가 몇개나 나오나요? 하나라도 있다면 반드시 다 고치세요. 구차한 변명따윈 필요없습니다. 하나도 안나오게 다 고치세요. 왜인지는 얼마전에 있던 제 경험담을 통해 아주 짧게 주저리주저리 설명드립니다.

며칠 전에 발견한 컴파일 경고 하나
현재 마무리를 도와주고 있는 콘솔게임을 PS3용으로 컴파일하다(즉 g++을 사용하면) 운좋게(왜 운좋은건지는 나중에 설명) 다음과 같은 컴파일 경고를 봤습니다.

1>..\..\src\monster.cpp(2814): warning : unused variable 'temp'

보통 때 같으면 무시하겠는데(왜 무시하는지도 나중에 설명.. 원래는 절대 무시하면 안됨) 그날 따라 무슨 신내림을 받았던지...

'응? 이놈이 뭐지? 궁금한걸?'

이란 생각이 더블클릭을 해서 소스코드를 봤지요.


bool swapped = false;
if( dist1 > dist2 )
{
  swapped = true;
  float temp = dist1;
  dist1 = dist2;
  dist2 = dist1;
}

어라... 버그가 보이는군요. 무슨 버그일까요.... 잠시 여백을 두어 생각하실 기회를 드리겠습니다... 한 눈 팔지 말고 코드 분석하세요...

한 눈 팔지 말랬잖아요.. 이 이미지를 보시면 이미 한눈 파신 겁니다. (그래도 출처는 http://curiousanimals.net)

자, 문제점을 찾으셨나요? 찾으셨을거라 믿습니다... 아니시라면.... 당신은 프로그래머가 아니야~ 버럭!

그래도 또 설명하는 친절한 포프씨 -_-
위 코드가 하려는 일은 두 거리(dist1, dist2) 중에 dist2가 언제나 dist1보다 크도록 변수값을 교환해주는 거군요. 매우 간단하죠. 근데... 뭔가 이상하죠? temp 변수가 안쓰였다니... 프로그래머가 아니신 분들을 위해 친절하게 예를 들어 한 단계씩 보여드리죠..


1. 일단 대충 변수값을 제맘대로 대입
다음과 같이 변수값을 정해서 이게 왜 버그인제 예를 보여드리겠습니다.

• dist1 = 20
• dist2 = 10

2. float temp = dist1;이 라인을 실행하면 변수값이 다음과 같이 됩니다. 별문제는 없죠 아직.

• temp = 20
• dist1 = 20
• dist2 = 10

3. dist1 = dist2; 
이 놈 이후엔 변수값이 이리 됩니다. 역시 괜찮습니다.

• temp = 20
• dist1 = 10
• dist2 = 10

4. dist2 = dist1;  

이게 마지막 라인이군요. 드디어 버그가 보이는군요. 이걸 실행하면 최종 변수값이 이따위가(?) 됩니다.

• temp = 20
• dist1 = 10
• dist2 = 10

temp에 저장해눴던 값을 dist2에 대입하는 대신 dist1을 대입함으로 해서... 버그가 생긴거지요...  그럼, 이 버그로 인해서 생기는 문제는 뭐였을까요?

전.모.릅.니.다.

정말 몰라요....(출처: http://knowyourmeme.com)

대충 코드를 훑어봤는데... 파일 이름은 monster.cpp이고 함수이름은 updateTail() 이었습니다. 사실 정확히 어떤 버그가 생기는지는 제대로 살펴보지 않았습니다. 그냥 대충 생각해보니 몬스터들이 팔을 휘두르거나 그럴 때 자취를 보여주기 위해 띄를 하나 그려 주거든요? 가끔, 그 띄가 뒤로 역류해서 겹쳐보이는 경우가 있었습니다. 그게 바로 이 버그 때문일지도 모릅니다. 하지만... 귀찮아서 더 자세히 보진 않았습니다. 그냥

'이 버그 발견했으니 고쳐주세요.'

라고 이메일만 보냈습니다.

버그는 어느 프로그래머나 만든다.
뭐 이정도 버그야 어느 프로그래머도 만들 수 있는 버그입니다. 그 부분에 대해선 프로그래머를 탓하지 않겠습니다. 저같은 꽃미남 프로그래머도 만드는 버그입니다.

뭐, 위의 예는 약간의 비주얼적인 하자.... 별 큰 문제는 아니었죠... 근데... 이게 뭔가 더 중요한 코드였다면 엄청난 하자가 될수도 있죠. 특히나 이처럼 특정조건에서만 생기는 문제였다면 디버깅도 쉽지 않습니다.

하지만 버그를 안만들기 위해 노력은 해야할거 아닌가?
따라서 제가 탓하고 싶은 건 컴파일 경고가 떡하니

"너 뭔가 잘못하고 있을지도 몰라. temp변수가 안쓰였잖아"

라고 말해주는데 그걸 무시한 만행(?)입니다.

컴파일러 경고를 고치는 것만으로도 상당히 많은 수의 버그를 미리 잡아낼 수 있습니다. 이 코드가 들어가있는 게임... 수백만장 팔립니다... 개발비도 수백만불 됩니다. 이런 프로젝트에서 가장 쉽게 코드품질을 보장할 수 있는 법을 무시하는 프로그래머의 자세 좋지 못하죠. -_-

보통 이따위로 깔끔하지 못하게 프로그래머하시는 분들... 전 타박해 드립니다... 하지만, 이번에는 그러지 못하는 이유가 있었습니다. 그것은....

너도 범인이다.
사실 문제는 이 코드를 작성한 프로그래머에게만 있는 건 아니었습니다. 이 회사의 모든 프로그래머 또는 제대로 된 정책을 만들지 않은 리드급 프로그래머에게도 문제가 있었습니다.

왜냐면..... 이 코드베이스를 컴파일하면 컴파일 경고가 1019개 나오기 때문입니다. -_- 1019개나 되는 경고속에 파묻힌 경고 하나를 찾으라고 하는게 어불성설이지요.....

자네...나보고 어쩌라는 겐가....?

보통 때 같으면 전 이런 경고 다 고쳐버리고,

"앞으로 경고 나오면 경고 하나당 저에게 3대씩 맞습니다."

라고 통보를 해드립니다. 하지만 그럴 수 없었던 이유가 이미 너무 늦었다는거죠.  -_-.... 게임 마무리 단계에서는 아무리 사소한 거라도 안건드립니다. (이건 전에 '게임 출시전 개발자가 갖춰야할 마음가짐'이란 글에서 말씀 드렸었습니다.) 딱히 발견된 버그가 있지 않는한 절대 안고칩니다. 코드를 바꿀 때마다 새로운 버그가 나올 위험이 있거든요. 그래서.... 안고칩니다.... 무조건 안고칩니다.

게임 출시하고 나서 고치죠. 근데 이 프로젝트 이후에 제가 이 팀을 도와줄 일이 없을거 같으니....

아마 평생 안고칠지도.... -_-

컴파일 경고를 방지하는 무대뽀 실용적인 방법
자, 그럼 저희처럼 너무 늦기전에 이런 일이 발생하는 것을 방지합시다. 당장 오늘부터라도 시작합시다.

컴파일러 경고를 오류로 처리한다.
가장 실용적인 방법은 컴파일러 경고가 나는 경우 이걸 아에 오류(error)로 처리해서 실행파일 조차 안만들어지게 하는겁니다. 아주 무대뽀 실용적이지요. 간단히 Visual Studio에서 컴파일 옵션만 켜주면 됩니다.

아주 실용적(?)인 방법

이러면 경고가 날 때마다 아예 실행파일이 안만들어지니 테스트를 못하지요! 그래서 프로그래머는 반드시 이 경고를 고쳐야만 합니다. 그래야 제대로 도는지 테스트라도 하니.... 근데 문제는.... 임시적으로 뭐 테스트하고 지우기 위해 대충 코드짜놨는데 경고가 나면...... 짜증나지요... 프로그래머들의 반란(?)을 부추기는 계기가 됩니다.... -_-

그래서 이 옵션은 release 빌드용으로만 켜주는게 좋습니다. debug 빌드에서는 프로그래머가 뭔짓을 해도 냅두는게 장수의 비결입니다. 문제는 프로그래머가 debug 빌드에서만 테스트하고 경고있는 코드를 그대로 check-in 했을 때인데요.

뭐, 이럴 때는 자동빌드머쉰(automatic build machine)이 release 빌드에 실패한뒤 그 프로그래머에

"당장 경고를 고치지 않으면 구워먹겠다!"

라는 협박 이메일을 보낼 거라고 믿습니다. 자동빌드머쉰이 없다면 만드세요. 이것도 없이 어떻게 게임 개발하지...? -_-;;;

정말 말도 안되는 경고는 꺼준다
가끔 정말 말도 안되는 경고도 있습니다. 별 의미가 없는 경고도 있고요. 이런 건 꺼주시면 됩니다. 단, 자기 맘대로 끄지 마시고 다른 프로그래머들과 상의한 뒤 동의를 얻어 꺼주세요. 자기 맘대로 끄는 것을 허용하면 경고 고치기 싫어서 그냥 꺼버리는 몰상식한 프로그래머들 꼭 나옵니다. 이런 분들 발견하시면 퇴사처리 해버리셔도 됩니다. -_-

끄는 법에는 2가지가 있습니다. 프로젝트 전체로 꺼주는 법도 있고, 각 파일별로 (또는 그보다 작은 단위로) 꺼주는 법도 있습니다. 원하는 대로 골라서 쓰시면 됩니다.

프로젝트 전체에서 경고 꺼주기
아래처럼 프로젝트 속성에서 꺼주면 됩니다. 아래 예는 프로젝트 전체에서 경고 #4507을 다 꺼주는 겁니다.

파일별로 꺼주기
그냥 아래처럼 #pragma warning()을 써주시면 그 뒤부터는 경고가 안나옵니다.

#pragma warning( disable : 4507 )

이걸 나중에 다시 켜줄려면

#pragma warning( default: 4507 )

을 해주면 됩니다.


대충 정리
뭐... 결국 할 말은.... '경고를 반드시 고쳐주세요.'였으나 역시나 너무나 주저리주저리 써서 대충 정리.

• 컴파일 경고만 살펴봐도 정말 명백한 버그들을 고칠 수 있다.
• 릴리즈 빌드에서는 컴파일 경고를 컴파일 오류로 처리해서 프로그래머들이 언제나 경고없는 소스코드를 유지할 수 있게 돕는다.
• 필요없는 경고는 프로젝트 속성에서 전역적으로 꺼주거나 파일별로 #pragma warning()을 이용해서 꺼준다.

p.s. 앞으로도 대충 어이없는 경험을 바탕으로 '제발 이러지 맙시다.'라는 글을 종종 올리겠습니다. 은근 좋아하는 분들이 많으신듯..... -_-

코딩스탠다드, 정말 이리 빡셀 필요있나?

이젠 피할 수 없는 진실이 되고 말았습니다. 사실 실력도 좋은데... 워낙 꽃미남이 되어놓으니... 비주얼로 자꾸 기억해주시는군요.... 뭐 사실은 사실 겸허하게 받아들이겠습니다... -_-

거부할 수 없는 진실은 힘들다.. 어쩌지 이제 잡지 표지모델 제의도 들어오는데...

왠만한 게임 회사에는 프로그래머가 준수해야하는 코딩스탠다드(코딩 스타일이라고도 하죠)가 있는 것 같습니다. 제가 여태까지 프로그래밍을 해오면서도 상당히 많은 코딩 스탠다드들을 봤는데요  (수백만장씩 팔린 패키지 게임에 사용한 엔진만도 5~6개 만져봤으니 뭐 온갖 꼴은 다 봤죠) 요즘들어 코딩스탠다드가 정말 이렇게 빡셀 필요가 있나 하는 의문이 들고 있답니다. (잡생각이 많죠.. 때로...)

우선, 대충 배경지식..... 코딩스타일에서 정의하는 것은 대충 다음과 같습니다.

• 인덴테이션/줄바꿈
• 빈칸의 사용
• 변수이름 짓는 법
• 함수이름 짓는 법
• 주석다는 규칙
• 등등...

코딩스타일의 존재이유?

결국 코딩스타일을 강제함으로 인해 회사에서 얻으려고 하는 건 가독성입니다. 코드 스타일을 통일시키면 다른 프로그래머의 코드를 읽을 때 쉽게 이해할 수 있고, 따라서 생산성을 높일 수 있다는 미신적인 믿음이 존재하죠.

이렇게 하면 프로그래머의 생산성이 높아진다는 부두교의 미신이 있다..... (믿거나 말거나)

코딩 스타일에서 정의하는 것들의 예
우선 코딩 스타일의 예부터.....

인덴테이션/줄바꿈

다음 형태 중에 어떤 놈을 이용할까? 하는 고민...

a)

for ( int i = 0; i < 10; ++i ) {

  sum += i;

}

b)

for ( int i = 0; i < 10; ++i )

{

    sum += i;

}

c)

for ( int i = 0; i < 10; ++i )    sum += i;

등등

빈칸(white space)의 사용

대충 이런 것들 중에 어떤 놈을 써야하는지...

a)

int a = c * ( d + e );

b)

int a=c*(d+e);

등등

변수이름 짓는 법

단어별 대소문자, 멤버변수앞에 m 접두어를 붙이는지 등등...

a)

mMemberVariable = temp_variable * 2.0f;

b)

MemberVariable = tempVariable * 2.0f;

등등

함수이름 짓는 법

단어별 대소문자, private, public 대소문자 등등

a)

int MyClass::getNumPrivate();

int MyClass:GetNumPublic();

int do_something();

b)

int MyClass::_getNumPrivate();

int MyClass:getNumPublic();

int doSomething();

등등

주석다는 규칙

• 클래스 선언 마다 주석을 달아야 하는가?
• 함수 선언마다 주석을 달아야 하는가? 변수명 설명? 반환값 설명?
• 그 외 어떤 코드에 주석을 달아야하는가?
• 주석 달때 스타일은 어떤걸로? /* ... */,  //, ///, /**...**/ 등등
• 기타 잡다한 것들...

하지만 의문이 들다

저도 좀 뭔가 깔끔하게 정리되어 있는 걸 좋아하는 놈이라 한동안 이런 미신에 푹 빠져살았습니다. 그런데 최근 몇 년 동안에 '정말정형화된 코딩스타일이 생산성을 향상시키나?'하는 의문이 들더군요. (물론 게임업계에 한정된 이야기입니다. 의료업계에서는 계속 빡세게 해주세요... 수술대 올라갔다가 버그 때문에 뻗은 기계 대문에 죽긴 싫습니다... -_-)

사실 코딩 스타일이란게 종교와도 같은 것이어서 이렇다 할 정답이 없습니다. 프로그래머 10명 잡고 물어보면 다들 선호하는 코딩 스타일이 다릅니다. 일례로 함수이름만 들어도 어떤 프로그래머는 private함수는 getNum() 이란식으로 작성하고 public 함수는 GetNum()이라고 작성하자고 하는 반면 다른 프로그래머는 get_num()과 GetNum()이라고 하자고도 할 겁니다.

어차피 회사란 집단체니까 그냥 일률적으로 정해놓고 프로그래머들을 다 강요하면 된다고 생각하는 건데... 정작 문제는 이 스타일로 개종해야하는 사람들에게는 이게 오히려 생산성 저하의 요소가 됩니다.

중요한건 프로그래머의 상식/배려/역량

그리고 참 웃겼던건.. 제가 지금까지 함께 작업했던 프로그래머만 해도 수백명인데... 그리고 이 엔진 저 엔진 옮겨다니면서 거친 코딩 스탠다드만도 대여섯은 될텐데..... 코딩 스탠다드하고 가독성은 정말 별 상관이 없었단 겁니다. 그보다는 오히려 어떤 코딩 스타일을 사용하던 간에 깨끗한 코드를 작성할 수 있는 프로그래머의 역량이 더 중요하더군요. 이런 분들이 대부분 이었습니다. 즉 굳이 코딩 스탠다드가 필요없는 인간들이 대부분...

회사에서 아무리 철저한 코딩 스탠다드를 만들어 놓아도 코드 드럽게 쓰는 애들(소수에 그칩니다)은 여전히 코드 이해 안되게 쓰더군요. 그래서 이런 애들을 좀 더 잘 관리하려고 코딩 스탠다드에 규칙을 더 추가합니다. 이러면 얘네들이 좀 나아질까요? 아닙니다. 얘네들이 코드가 드러운 이유가 있습니다. 남생각을 별로 안하거든요. 규칙이 얼마나 철저하던 간에 어떻게든 빠져나갑니다. 그 덕에 오히려 원래부터 깔끔한 코드 쓰던 사람들만 고생하죠. 이 사람들은 악법도 법이라고 존중하고, 다른 프로그래머들도 배려할 줄 아는 분들이므로 새로 생긴 규칙에 맞게 또 열심히 코드를 작성합니다. 이 규칙 없어도 원래부터 이해잘되는 깔끔한 코드를 작성하던 사람들인데 따라야 할 규칙만 늘어버렸죠. 

이게 배려라는 거다....  밥그릇 까지도 깔끔하게... (이미지 출처: http://garul.tistory.com)

결국 제값주고 산 놈들만 손해란 건가?

이렇게 생각을 하다보니.... 꼭 게임에 DRM 입히는거와 마찬가지란 생각이 들더라구요. DRM을 아무리 빡세게 입혀도 해적질 할 애들은 다 해적질하고 쓰니 아무 상관없는데, 정가내고 산 사람들만 그 DRM에 얽매여서 온갖 귀찮은 일을 다 당해야 하는....

해석은 귀찮으니 생략..... 그림만 봐도 대충 뭔 귀찮은 일을 당하는 지 알거다...

차라리 개별적으로 갈구자. 짜르던가. 칼부림도 가끔?

결국 제가 내린 결론은 저희가 너무도 당연하게 여기며 쓰던 코딩 스탠다드가 생각보다 별로 효과적이지 않단 겁니다.

물론 코딩스탠다드를 싸그리 없애자는 건 아닙니다. 좀 최소한으로 줄이자는 거죠. 그리고 코드 드럽게 쓰는 애들을 개별적으로 갈궈서 좀 고치게 하던가... (인간이 직접 갈구는게 문서 던져주고 따라하라는 것보다 훨씬 효율적입니다... 칼부림이 가끔 날 뿐이지... -_-)...... 안되면 그냥 짜르던가....

이런 생각을 하게 된 또 다른 계기는 게임업계가 엄격한 코딩스타일이 필요한 분야가 아니란 겁니다. 어차피 코드작성한 건 다 내부적으로 쓰는거고, 문제 있으면 소스코드가 다 떡하니 있으니 아무나 가서 고칠 수 있으니까요. 게임업계가 아니라 미들웨어를 만들어서 판매하는 회사라던가 군사업체 및 의료장비에 들어가는 소프트웨어를 만드는 회사에서는 이게 좀 더 엄격해야겠죠. 미들웨어 회사는 라이브러리만 던져주는 경우가 많으니 그렇고, 군사업체 및 의료장비는 사람 생명이 걸린 일이라서 어쩌다 뭔 짓을 하더라도 버그를 아예 처음부터 만들지 않는게 중요하니까요. 어차피 게임이 엔터테인먼트 산업이고, 게임의 요구사항은 하루가 멀다하고 바뀌므로 차라리 유연하게 재빨리 코드를 작성할 수 있는게 게임 품질 향상에 더 기여한다고 봅니다. 게임의 품질이란건 사실 게이머가 느끼는 품질일 뿐이거든요. 인간의 목숨이 걸린 의료소프트웨어에서의 품질하고는 전혀 다르죠.

그냥 이정도면 하면 안될까요?

그래서 과연 '코딩스탠다드를 어디까지 줄일 수 있을까?' 하는 걸 좀 생각해봤죠. 이게 좀 간단해야 정작 남 배려할 줄 아는 프로그래머의 인생도 편해지지 않을까 해서....

나도 좀 단순히 편하게 살고 싶다... 물론 패리스 힐튼과 함께.... 근데 토토샵 질이 좀 심한데? -_-

위에서 들었던 목록을 한번씩 살펴보면서 이야기하죠.

인덴테이션

코드의 가독성을 위해서는 여전히 중요하다고 생각합니다. 특히나 코드의 scope를 보여주는데 도움이 되니까요. 근데 이제 Visual Studio 가 이런 인덴테이션을 직접 알아서 해주므로 크게 걱정할 필요가 없습니다. 20년 전에 이런 게 자동으로 안될때나 문제였지...

빈칸사용

뭐 이건 사실 int k = a * ( b + c );로 해주냐 int k=a*(b+c);로 해주냐 차인데... 어떻게 쓰던 코드 이해하는데 별 차이가 없습니다.... 굳이 목숨 걸 필요 없지 않나요? -_-

변수명/함수명

일단 멤버변수 이름앞에 m을 붙이니 public 함수는 대문자로 시작하니 마니 하는 건 이젠 별 의미가 없는거 같습니다. 어차피 IDE가 워낙 좋아져서 그냥 마우스만 올려도 나오는 경우가 많고 아니면 F12키 한번 누르면 곧바로 선언된데로 이동하니까요. 그리고 다시 돌아올땐 Ctrl + -키 누르면 끝이고... Visual Studio의 인텔리센스가 잘 작동안하면 Visual Assist 를 깔아도.....

단, 가독성을 위해 변수명이나 함수명을 잘 작성해주는 건 찬성입니다. 즉 int a = 1; 이라기보단 int numLoop = 1; 이란 식으로 변수명을 작성해주는거죠.. 딱 보면 이해가 되게... 함수명도 마찬가지고요.

주석다는 규칙

사실 주석달아야 할 곳에 안달아서 헷갈리는 경우도 많고, 달지 않아도 될 곳에 달아서 오히려 코드만 지저분해지는 경우 허다하죠... 이건 사실 어떻게 정의해도 코드 드러운 애들은 여전히 드럽고 코드 깔끔한 분들은 여전히 깔끔한.. 그런 부분...

저 개인적으로는

1. 클래스 이름만 잘 정하면 굳이 클래스마다 주석을 달 필요가 없다. 이름보고 이해안될때만 기재.
2. 함수/변수 이름만 잘 정하면 굳이 함수/변수마다 주석을 달 필요가 없다. 이름보고 이해 안되거나 변수의 반환값이 기묘할 떄만 기재.
3. 코드에서 곧바로 이해되면 주석은 필요없다.
4. 옆에 앉은 놈이 코드만 보고 곧바로 이해가 안되면 코드블럭 별로 그 위에 주석으로 기재

정도가 젤 난거 같습니다.

대충 정리

이렇게 써보고 보니 결국 제가 괜찮다고 생각하는 법은 코딩 스타일의 통일성을 유지하려고 괜히 쓸데없는 규칙을 만드는 대신에 개발자들의 상식을 믿으란 쪽이 되어버린듯...

어쨌든 제가 좋다고 생각하는 코딩스타일은 이것 정도입니다.

• 변수명/함수명에 의미를 담을것
• 코드의 스코프를 보여주기 위해 인덴테이션을 잘 할 것
• 동료 프로그래머가 코드에서 곧바로 이해못할 만한 내용이면 코드 블럭 위해 간단히 주석을 달 것

개종 안하셔도 되요~

뭐, 다들 이러세요~ 라는 걸로 쓴 글은 아니고.... 그냥 한 번 생각해보시라고... 그리고 토론 좀 해보잔 의도로... (어차피 종교적인 토론이라... 난장판이 될 가능성이 높지만...-_-)