Canstruction 2012

어제 다운타운을 걸어다니다가 HSBC 빌딩 안에 독수리가 한마리가 있는것을 포착.. 뭔가 해서 재빨리 들어가서 보니... Canstruction 2012이란걸 하고 있었다. 그래서 사진 몇장 찍은김에 올림.. 후다닥~

I'm pretty sure it's humping

참고로 이놈은 전세계적으로 열리는 컨테스트란다....

손가락이 안굽혀지는 문제를 고쳐보자

한 15년쯤에 농구하다가 왼손 새끼 손가락으로 공을 받아서(?) 한참 붓고 그런 뒤부터 이놈이 쉽게 굽혀지지가 않았다. 굽히면 중간에 잠시 걸렸다가 아주 힘을 쌔게 주면 갑자기 탁 꺽이면서 굽혀지는 느낌이랄까? 그래서 기타를 칠때도 많이 불편했고(사실 이게 기타 잘 못치는 거의 핑계였지만..) 요즘엔 피아노 칠 때도 불편하고 그랬는데...

어차피 캐나다는 병원가도 땡전 한푼 안내니.. 큰맘을 먹고 의사에게 문제를 이야기하니... 이걸 trigger finger라고 보통 부른단다... 치료법은 일단 magnesium citrate를 자기전에 3~4알씩 한 달간 먹어보란다.. 많이 나아지는 경우가 있다고... 그래서 이게 해결되면 죽을 때까지 계속 그리 먹고.. 아니면 그 때가서 수술을 생각해보자고...

어디 고쳐지나 보자. 고쳐지만 최고의 기타리스트로 거듭나 주리라.....

p.s. 부작용에는 설사가 있단다... 쿨럭쿨럭 -_-

쉐이더 입문강좌 책 계약했습니다

생각해보니 트위터에만 올리고 여기엔 글을 안남겼었군요. 사실 쉐이더 강좌 보시는 분들은 블로그로 더 많이 오실텐데 말이지요..... ㅎㅎ 며칠전에 계약서에 출판 서명했습니다. 여태까지 한빛 출판사에서 편집은 하고 있었는데 멀리 살다보니 이제서야 계약서를 작성했네요.

가장 궁금해 하시는 출판예정일은 5월정도랍니다.

콘솔게임에는 미래가 없다? (방명록 답변)

뭐, 최근에 한국의 모 게임회사 사장님이 '콘솔게임에는 미래가 없다'라는 발언을 해서 이런저런 토론이 일어나고 있는 모양이네요. 이런 발언들이 보통 회사의 이익과 관련된 경우가 많아서 전 보통 대충 뉴스의 헤드라인만 읽어보고 넘어가는게 보통이고 이번에도 그랬는데... (그리고 제가 별로 기여를 할 수 있는 주제가 아니라고 생각해서 대충 넘어간 것도 있음)... 방명록에 '미고'님이 제 의견을 물어보셔서 거기에 답글을 단 김에 그대로 긁어서 블로그 포스트로도 올립니다.

우선 이게 미고님이 던져주신 질문:

북미관련을 비롯해 다양한 게시물을 정독하며 많음 도움 얻고 있는 게임쪽 취업준비생입니다.
일단 게임계의 선구자(?)역할을 해주시는 pope님게 감사드리며..

한가지 궁금한게 있습니다. 게임의 스킬이나 방법적인 질문은 아니고
어떻게 보면 게임계의 동향의 관한 질문이 될수도 있겠는데요. 최근의 한국에서
"게임 매니아 다 모여라!" 라는 공개 토론회가 서강대학교에서 열렸습니다. 전문가 패널로는
아키에이지를 제작중이신 XL games의 대표이사 송재경님이 참여하셨습니다. 그외에도 몇분의
패널이 계셨습니다만 논외로 하겠습니다~

근데 이 토론장에서 마지막 질의응답시간이 주어졌는데 한 학생이 이렇게 대표님께 물었습니다. "저는 온라인게임보다는 콘솔게임을 만들고 싶은데 어떻게 해야되죠? 어떻게 생각하시나요?" 대충 질문의 요지는 이랬습니다. 하지만 전 현장이 있지 않았으니 정확한 질문의 요지까지는 모르겠습니다.

이에 대한 답변이 좀 우리나라 게임계의 파장이 일어날 정도였는데.. 대답은
"콘솔게임에는 희망이 없다" 라는 말이었죠. 비록 한국에 국한댄 얘기였겠지만 이 이후로도
게임사이트나 게임종사자 들간에는 찬반여론이나 토론분위기가 형성이 되었습니다.

저도 지극히 한국이란 나라에서 콘솔쪽은 힘들다고 생각합니다만.. 콘솔쪽 종사하고 싶으면
북미로 가야되는게 현실이기도 하죠.. 비록 아이폰/아이패드 게임들이 나오고 있긴 하지만
콘솔시장에 비해서 혹은 퀄리티에 비해서 많이 개인적으로 딸린다고 생각합니다.

제가 말한 내용을 정리해서 올려논 게시글을 첨부 했습니다

http://www.thisisgame.com/board/view.php?id=1123473&category=102

pope 님께서는 송재경 대표님의 발언과 관련해서 어떤 생각을 하시는지..
동감하시는지.. 아니면 대표로써 경솔한 발언이었는지..

아 그리고 링크따라서 읽으시다보면 게임계의 단합과 관한 내용도 추가적으로 있습니다.
저는 저 발언에 대해서는 오히려 위의 내용보다 더 경솔한 발언이라고 생각하는데요.

창의적인 게임도 중요하지만 더 크게보면 게임계의 산업을 이끌어갈 대표들이 모여서
게임제작 얘기만 하는게 아니라 전반적인 사업계의 흐름을 읽고 앞으로의 방향성에 대해서
제시를 해야되는데..
대표들이 모이는 것에 대해서 꺼려하는 분위기 더군요

이에대해서도 어떻게 생각하시는지 궁금합니다.

내용이 많이 길어졌군요-_-...
간단 명료한 대답도 좋습니다~
감사합니다 항상 도움이 되고 있습니다!

이게 제 대답:
아니, 이리 어려운 질문을... 송재경님이 누군지조차 몰라서 검색을 해봤어야 했어요 ㅎㅎ 어쨌든 대충 제 답변입니다....

송재경님이 이 발언 하셨던 주(week)에 epic games의 팀 아저씨가 인터뷰를 한게 있지요. 그 분의 입장은 '콘솔게임은 아직도 미래가 있다'였습니다. 일단 아이패드나 이런놈들이 "현재" 콘솔게임의 파워를 따라잡는데에는 최소 5~6년이 걸릴것이고 게임을 하는 최적의 환경은 역시 대형 TV를 앞에 두고 하는 것이니까요... 대형 TV가 게임을 하기에 최적의 환경이라는 것은 저도 예전부터 생각해오고 있던거라 팀 아저씨의 말에는 일단 공감하죠.

하지만 송재경님이 한 말이 경솔하다거나 생각하지는 않습니다. 본인의 의견을 강력히 피력하는 건 좋은 것이고, '공인이라면 이런 말은 하지 말아야한다'라는 시각도 옳지 않다고 보니까요. 그리고 회사를 이끄는 입장에서 이미 상당히 기술투자를 한 본인회사에게 유리한 방향으로 업계동향을 몰아가는게 도움이 될테니까요. 아니면 본인이 업계동향을 이미 그렇게 보고 있어서 그쪽으로 투자하고 계신걸수도 있고요. 뭐든간에 나쁘다고 생각하진 않습니다.

그보다 제가 문제삼고 싶은건 송재경님이 콘솔의 미래가 없다는 주장의 근거로 드신 내용이죠. 이 분이 근거로 삼은게 다음 2개 같은데....

1) 아이패드의 발매주기: 1년
2) 앱스토어 가격: 1 ~ 20달라

1)은 이미 콘솔시장이 뜨기전부터 PC 쪽에서 있어왔던 일이죠. PC쪽은 매년, 혹은 매달이 멀다하고 계속 발전을 하지요. 그럼에도 불구하고 콘솔게임쪽은 여전히 발전해 왔습니다. 따라서 콘솔기계가 주기적으로 노후되는게 콘솔시장이 죽어야 하는 이유는 아니라고 봅니다.

2)은 콘솔게임의 가격이 비싸다고 하는건데... 요즘은 콘솔에서도 5~20불짜리 게임은 많습니다. 보통 digital download로요. 그리고 사실 다달이 내는 MMO가 결과적으로 가격은 더 비싸지 않나요? 그 가격에 소비자가 뭘 원하는지가 중요한거지... 실제 가격이 중요한건 아닙니다.

그럼 지금부터는 제 의견:
게임개발하는 사람으로서 제가 필요한 근거는 '소비자가 무얼 원하느냐?'일 뿐입니다.

한국에서 콘솔게임이 뜨지 않은 이유는 사실 애들이 밖으로 나돌아서라고 생각해요. 콘솔은 사실 거실에 있는 TV에 연결해서 하는 맛에 하는거죠. 컴터로 또는 핸폰으로 TV 프로 볼 수 있는데 굳이 많이 분들이 거실에 앉아서 보는 이유가 뭐겠어요? 똑같은 이치입니다. TV가 멀리있어서 눈에도 편하고, 화면도 크죠. 여러명이 같이 볼수도 있고요.

게임도 마찬가지입니다. TV에 연결하는 콘솔게임이 정말 쾌적해요. 근데 TV에 연결해놓고 콘솔게임을 하기엔 부모님 눈치가 너무 보이니까.. 학생들이 밖으로 나갑니다. 공부하러 간다고 하고 나가는거죠.. 그러고 가는 게 PC방... -_- 부모님들은 애들이 공부하러 간다고 했으니까... '저놈이 분명 저러고 놀거야~'라는 의심이 들면서도 그냥 모른척 하는 경우도 많죠... '내 눈에 안보이면 내 책임이 아니다.'란 주의.... 게임셧다운제니 뭐니 하는 개소리법도 그래서 생긴거구요. 부모들이 애들을 제대로 키울 책임을 지기 싫어서 회피해서 생긴... 뭐, 이렇게 중고등학교 시절을 거쳐 대학생이 된 애들 역시 집보다는 밖에 나도는걸 좋아하구요..

그래서 결론은.. 한국에서는 게임의 주 소비자가 결국... 콘솔 게임보다는 PC게임을 원한다는 거죠. (요즘은 모바일도 많이).. 그래서 MMO쪽 수요도 큰거였고 등등... 이게 고쳐지려면 일단 부모님들 의식이 애들은 '놀 땐 놀고 공부할땐 공부해야한다'로 바뀌어야 하고, 집에서 부모님 감독(?)하에 오락을 할 수 있게 허락해줘야 하는거죠.

미국/캐나다의 소비자는 조금 다릅니다. 여기는 PC방이 거의 없습니다. 그 이유가 부모들님들이 집에서 오락하는 걸 허락하니까요.. 차라리 '내 눈 앞에서 그러는게 적당히 감독도 할 수 있어서 좋다.'라는 개념이요. 흔히들 하루 몇시간 이상 오락을 하지 못하게 하거나 그런제한을 가하더라구요. 한마디로 부모가 자기 책임을 지고... 애들은 오락하기 가장 쾌적한 환경인 콘솔게임기 + TV를 즐길 수 있고... 그러다보니 소비자도 콘솔게임쪽을 더 원하고...

대표들이 모이는 것에 대해서 꺼리는 거에 대해서는 잘 모르겠어요. 아마 한국이라는 좁은 공간에서 서로 치열하게 경쟁해야 하니까 꺼리는게 아닐까요? 참고로 NC소프트 같은 경우는 직원들이 컨퍼런스에서 강연하는것도 못하게 한다는군요... 저 개인적으로는 적당히 퍼주는걸 좋아하는지라 좀 아쉬운 면이죠...

업데이트(2012/03/29): ParkPD님에 따르면 NC소프트에서 강연 못하게 한다는건 사실이 아니랍니다. 정정해주셔서 고맙습니다~

질문이 기니 대답도 길어지는군요.. 대충 대답이 되었기를 바라며... 이 글 차라리 제 블로그에 올려야겠어요.. (길게 쓴게 아까워요~!)


확실한 입장 표명?
생각해보니 방명록 답변에는 제 확실한 입장을 표명하지 않은 것 같아서...

1. 소비자가 원하는걸 만들면 된다....
2. 한국: 콘솔게임의 현재가 없다. 미래가 생길려면 문화가 변해야 한다. (고로 힘들것 같다고 생각)
3. 외국: 여전히 콘솔게임의 미래가 있다. (최소한 한 5년정도는... 그 이상을 예측하는게 의미가 있나? 언젠가는 다른 고성능 기기에서 게임을 하되 영상 및 음향은 무선으로 TV에 HD품질로 쏴줄 수 있는 날이 올거다. 물론 실시간으로.... 그러면 콘솔이라는 개념이 좀 바뀔지도...)
4. 업계 대표끼리 연락을 하거나 지식울 공유하는 것은 좋다고 생각한다. (빌 게이츠와 스티브 잡스도 연락을 종종 했다고 하며, 구글의 CEO도 페이스북의 보드멤버이지 않나?)

p.s. 위에 '게임계의 선구자 역할을 하시는 pope님'이란 문구에 밑줄 긋고, 폰트 크게 하고, 볼드체로 처리하고 싶었으나... 참았음 -_-;

컴파일 경고하나당 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. 옆에 앉은 놈이 코드만 보고 곧바로 이해가 안되면 코드블럭 별로 그 위에 주석으로 기재

정도가 젤 난거 같습니다.

대충 정리

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

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

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

개종 안하셔도 되요~

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