[은고] 게임 프로그래밍

좋은 글이 있어서 새겨두기위해 남겨둔다.

※ 출처 : 최영식님의 블로그

1. 프로는 불을 피우고, 아마추어는 불을 쬔다.
2. 프로는 자신이 한 일에 대해 책임을 지지만, 아마추어는 책임을 회피하려고 급급 한다.
3. 프로는 기회가 오면 우선 잡고 보지만, 아마추어는 생각만 하다 기회를 놓친다.
4. 프로는 돌다리도 두드리고 건너지만, 아마추어는 두드리고도 안 건넌다.
5. 프로는 자신의 일에 목숨을 걸지만 아마추어는 자신 일에 변명을 건다
6. 프로는 여행가이고, 아마추어는 관광객이다.
7. 프로는 남의 말을 잘 들어주고, 아마추어는 자기 이야기만 한다.
8. 프로의 하루는 25시간이지만, 아마추어의 하루는 24시간뿐이다
9. 프로는 뚜렷한 목표가 있지만, 아마추어는 목표가 없다.
10. 프로는 행동을 보여 주고, 아마추어는 말로 보여준다
11. 프로는 너도 살고 나도 살자고 하지만, 아마추어는 너 죽고 나 죽자고 한다.
12. 프로는 자신에게는 엄하고 남에게는 후하지만, 아마추어는 자신에게 후하고 남에게 엄하다.
13. 프로는 놀 때 최고로 놀지만, 아마추어는 놀 줄 모른다.
14. 프로는 리더(Leader)고, 아마추어는 관리자(Manager)다
15. 프로는 평생 공부를 하지만, 아마추어는 한 때 공부를 한다.
16. 프로는 결과보다 과정을 중시하지만, 아마추어는 결과에 집착한다.
17. 프로는 독서량을 자랑하지만, 아마추어는 주량을 자랑한다,
18. 프로는 강자에게 강하고, 아마추어는 약자에게 강하다.
19. 프로는 사람을 소중히 하고, 아마추어는 돈을 소중히 한다.
20. 프로는 사람이 우선이고, 아마추어는 일이 우선이다.
21. 프로는 길게 내다보고, 아마추어는 눈앞의 것만 본다.
22. 프로는 해보겠다고 하지만, 아마추어는 안 된다고 한다.
23. 프로는 시간을 관리하고, 아마추어는 시간에 끌려 다닌다.
24. 프로는 구름 위에 뜬 태양을 보고, 아마추어는 구름 위의 비를 본다
25. 프로는 지는 것을 두려워하지 않고, 아마추어는 이기는 것도 걱정한다.
26. 프로는 번영 의식이 있지만, 아마추어는 편한 의식이 있다.
27. 프로는 “난 꼭 할 꺼야” 라고 말하지만, 아마추어는 “난 하고 싶었어” 라고 말한다
28. 프로는 메모를 하고, 아마추어는 듣기만 한다.
29. 프로는 “지금 당장”을 좋아하지만, 아마추어는 “나중에”를 좋아한다.
30. 프로는 꿈을 먹고 살지만, 아마추어는 꿈을 잃고 산다.
31. 프로는 “요령껏, 재주껏” 하지만 아마추어는 “무조건 열심히” 만 한다.
32. 프로는 “Me”를 생각하지만, 아마추어는 “Me Too”를 생각한다.
33. 프로는 Only One를 추구하지만, 아마추어는 Number One을 추구한다.
34. 프로는 다면 사고를 하지만, 아마추어는 단면 사고를 한다
35. 프로는 KnowWhere를 생각하고, 아마추어는 KnowHow를 생각한다.
36. 프로는 밸류을 추구하지만 아마추어는 볼륨을 생각한다.
37. 프로는 질을 생각하고, 아마추어는 양을 생각한다.
38. 프로는 디지털형이고, 아마추어는 아나로그형이다.
39. 프로는 플로우를 좋아하고, 아마추어는 스톡을 좋아한다.
40. 프로는 뛰면서 생각하지만 아마추어는 생각한 뒤 뛴다.
41. 프로의 무대는 그라운드지만, 아마추어의 무대는 관중석이다.
42. 프로는 창조적 괴짜형이고, 아마추어는 노예형이다.
43. 프로는 미래 중심적이고, 아마추어는 과거 중심적이다.
44. 프로는 창조를 하고, 아마추어는 모방을 한다.
45. 프로는 발전시키지만, 아마추어는 현상을 유지한다.
46. 프로는 사람에 초점을 두지만, 아마추어는 시스템과 구조에 둔다.
47. 프로는 신뢰를 쌓지만, 아마추어는 통제에 의존한다.
48. 프로는 장기적 관점을 갖지만, 아마추어는 단기적인 전망을 갖는다.
49. 프로는 “왜, 무엇”을 묻지만, 아마추어는 “어떻게, 언제”를 묻는다.
50. 프로는 먼 수평선에 두지만, 아마추어는 시야를 말끝에 둔다.
51. 프로는 자기의 의지에 따라 움직이지만, 아마추어는 현상을 그대로 받아들인다.
52. 프로는 “올바른 일”만 하지만, 아마추어는 “일을 올바르게” 한다.
53. 프로는 위험을 감수하지만, 아마추어는 위험을 회피한다.
54. 프로는 이끌기 위해 솔선 수범하지만, 아마추어는 주어진 직책에 안주한다.
55. 프로는 삶으로서 영향력을 발휘하지만, 아마추어는 직책으로 영향력을 행사한다.
56. 프로는 사람을 고무시키지만, 아마추어는 기준을 따르라고 한다.
57. 프로는 변화를 추구하지만, 아마추어는 예측과 질서를 추구한다.
58. 프로는 현상에 도전하지만, 아마추어는 현상을 유지한다.
59. 프로는 비전과 전략에 관심을 두지만, 아마추어는 세부적인 계획, 시간표에 관심을 둔다.
60. 프로는 혁신가지만, 아마추어는 행정가이다.
61. 프로는 실질적인 성과에 관심이 있다. 아마추어는 능률에 관심을 둔다.
62. 프로는 철학, 핵심 가치, 공동 목표를 강조하지만, 아마추어는 전술,시스템, 구조를 강조한다.
63. 프로는 책임부터 생각하고, 아마추어는 권한만을 생각한다.
64. 프로는 공유하려 하고, 아마추어는 독점하려 한다.
65. 프로는 실수를 하고, 아마추어는 실패를 한다.
66. 프로는 놀지만, 아마추어는 까분다.
67. 프로는 웃지만, 아마추어는 비웃는다.
68. 프로는 알면서도 모르는 척 해주지만, 아마추어는 모르면서도 아는 척 한다.
69. 프로는 힘들어하지만, 아마추어는 힘들다고 소리친다.
70. 프로는 함께 일하고.아마추어는 혼자 일한다.
71. 프로는 비판하지만, 아마추어는 비난한다.
72. 프로는 얘기하지만, 아마추어는 떠든다.
73. 프로는 묵묵히 걸어다니지만, 아마추어는 싸돌아다닌다.
74. 프로는 남에게 감사하지만, 아마추어는 남을 감시한다.
75. 그리고, Pro는 (영락없이) Amateur처럼 생겼지만,Amateur는 (마치) Pro처럼 행세한다.

흔히들 대학과제로든 시험으로든 면접에서든

C++과 Java의 차이점에 대해서 기술해보라는 문제가 자주 등장한다.

최근 김포프님의 포프tv를 보면서 C++이 Java보다 어떤 점들이 다른지에 대해서

이야기를 들은 적이 있었는데, 궁금해서 구글에 뒤져보다보니

위키에 비교가 잘 정리되어 있어서 블로그에 옮겨적게 되었다.

1. 두 언어는 일단 설계 목표부터가 다르다.

 - 역사적으로 C++은 C를 확장하여 파생 된 언어이다. 절차적 프로그래밍 언어에 효율적인 실행을 목표로 설계 되었고, 정적 자료형 검사, 객체 지향 프로그래밍, 예외처리, RAII, 제너릭 프로그래밍을 지원한다. 범용 컨테이너와 알고리즘을 포함한 C++ 표준 라이브러리가 추가 되어있다.

 - JAVA는 임베디드 제품(가전 제품 등)에 탑재 되어 네트워크 컴퓨팅을 지원하기 위해서 만들어졌다. 항시 Java는 가상 머신 위에서 실행 된다는 특징이 있으며 안전성과 이식성이 높은 것이 장점이다. 하위 플랫폼을 완벽히 추가시켜주는 광대한 분량의 라이브러리를 가지고 있고, JAVA는 C와 비슷한 문법을 사용하나 직접적인 호환성은 없다.

2. 비교 표

그 외에도 방대한 내용을 적을 수 있을 정도로 차이가 있으나...

기본적으로는 위 사항 정도만 숙지하고 있어도 어느정도 큰 차이점들은 알 수 있을 것으로 생각한다.

더 자세한 차이 점에 대해서는 아래 위키에서 참조!!

위키백과 - 자바와 C++의 비교

최근 제작하고 있는 자체엔진 기반의 맵툴(Maptool) 입니다.

WinAPI와 DirectX를 조합하여만들고 있는 자체 2D엔진을 기반으로 하여 제작하고 있습니다.

아이소매트릭 기반 타일시스템을 주로 사용하며

일반적인 Rectangle이나 다각형도 가능하도록 만들고 있습니다.

(다각형은 아직 미지원)

제가 만든 엔진의 파일 시스템을 이용해서

타일 이미지를 쉽게 넣고 뺄 수 있도록 제작되어있고, 아틀란타같은 타일 세트를 딱히 만들지 않아도 알아서 타일 이미지 정보를 가져오도록 되어있습니다.

(지정 된 리소스 폴더에 넣어두기만 하면 알아서 불러와요!!)

엔진 디버그를 이용해서 메모리 사용량이나 CPU 사용량에 대한 부분은 엔진차원에서 확인 할 수 있는 시스템을 만드는 중이라 좌측 위 cpu정보는 출력 되지 않고 있습니다.

그외에 월드 타임을 이용하거나 애니메이션 타일을 위한 tickstep을 지원하는 맵툴입니다.

주요 UI(필자는 Viewer로 부르는 중)는 

1. StatsViewer : 엔진과 기타 카메라/마우스 좌표 정보들을 출력

2. ControlViewer : 각종 버튼 아이콘

3. MinimapViewer : 미니맵

4. LogViewer : 각종 실행 정보를 담고있는 Log 박스

5. TileMapViewer : 엔진을 통해 불러온 타일 목록 출력

6. ObjectControlViewer : 레이어나 오브젝트에 대한 정보를 셋업하는 컨트롤 뷰어

가 있습니다.

이렇게 적고나니 몇개 안되긴하는데...

실제 코드로는 몇천줄을 짰던거 같은데 뭔가 블로그에 이렇게 적으면서 보니 허무하다는 생각도 조금 드네요.

현재 위 맵툴 프로젝트는 4명이서 제작중인 2D RTS 전략게임의 전투맵을 위한 맵툴입니다.

제 PC 기준으로(적당적당한 사양....?) 128x128(16384개) 타일을 만들 때 60Fps 정도의 퍼포먼스가 나오고 격자 정보를 미 출력시에는 퍼포먼스가 더 올라가는 것을 확인했습니다.

아마 최적화만 좀 더 하면서 코드를 개선하면 256x256(65536개) 타일도 충분히 지원할 것 같군요.

기본적인 세이브/로드/리셋/디버그 모드(격자 미출력)/종료 기능이 제공되고있고

그 외...맵을 만들기 위한 레이어나 타일 선택기능들은 다 구현이 되어있습니다.

하루 빨리 이걸로 제작한 맵에서 전투가 벌어지는 걸 보고싶네요.

빨간색 박스(우측 상단 타일 그림 리스트) 가 타일 목록들이 보여지는 컨트롤러 입니다.

그 아래에 있는 타일 정보에 대한 오브젝트 컨트롤러는 타일의 레이어나 프리 포지션(자율 위치)로 지정할 수 있게 해주는 컨트롤 내용들이 담겨 있습니다.

제작 중인 게임에 대한 프로젝트는 아래 github - 링크에서 코드를 확인할 수 있습니다.

https://github.com/redforce01/SephyEngine/tree/Jaejun-Kim

의욕 상실로 코딩이 손에 안잡힐 땐

역시 음악을 들으면서 다시 마음을 가다듬는게 최고인 것 같군요.

몇 주간 정말 코딩하기 귀찮다~ 하면서 

그래도 까먹기전에 다시 키보드를 두둘겨패보자

는 심정으로 키보드를 잡다가 비쥬얼스튜디오 킨지 5분만에 다시 의욕 상실했다가

에라..유투브에서 음악이나 듣자하면서 우연히 들은 아래 음악이

저에게 다시 코딩할 의욕이 생기게 해줬네요.

음악은 그냥저냥...취향탈 수도 있고.....애니 음악들이라 사람에 따라 그럴 수도 있습니다..하핫;;

암튼 저는 그냥 듣기 좋았어요.

CROWSCLAW Music Compilation ~ Blue Essence Guitar

프로그래밍 과외 준비중 심심해서 나무위키를 탐험하고 있었는데,

병렬 프로그래밍 키워드가 보이길래 클릭했더니.

으잌..문서 내용은 어디가고 저 캐릭터가 덩그러니 나왔다.

읭?머징?머징!!? 위키에 자료가 없는게 있어!! 라고 놀란 것도 잠시

저 캐릭터는 무엇인고...?

하고 알아보니 나무위키 공식 마스코트 캐릭터 "세피로트" 였다.

(평소 나무위키를 이용해왔지만 저런 캐릭터를 본건 이번에 처음이었음...)

해서 좀 더 알아보자~! 하고 나무위키 캐릭터 라고 검색했더니

이렇게 나무위키 캐릭터가 몇개 나왔다...

(호오...?) 필자가 매니악한 오덕은 아니지만 2D 캐릭터를 싫어하진 않으므로 궁금해서 한번 들어가봤다. (난 절대 오타쿠가 압아...아...아닙니다..)

아무튼 나무위키에 이런 캐릭터가 있었다니!!!

결국 최근 블로그를 하면서 짤방도 모으고 있었기에

위키 캐릭터 팬아트나 짤방들을 전부다 수집했다.

마지막은 나무위키에서 404 not found 나 문서 없을때 나오는 세피로트로 마무리!

(아래 두 캐릭터 그림 말고도 실제로 나무위키에 가보면 이것저것 많이 있다)

4. ㅁㅁ을 하자.

시작부터 강렬한 짤방을 올려보았습니다.

다소 여성분들에겐 푸핰! 하고 난 여기서 빠져나가겠어!!!!!!

하실 수도 있겠지만...

(뒤 늦게나마 = _=죄송합니다...)

아무튼..

네 번째로 언급할 내용은 

4. 설계를 하자. 

입니다.

만약 이 글을 보시는 분이 프로그래머 분이라면, 혹 프로젝트를 진행하기 앞서

어떤 클래스가 어떤 메소드(함수)들을 내포하고 수행할 것인지

설계 해보신 적이 있으실 겁니다.

팀 프로젝트를 진행하는데 있어서도 위와 같은 생각을 하는 것은 똑같다고 생각합니다.

제가 "설계를 하자" 라고 언급하였는데, 왜 그랬을까요~?

이유는 팀 프로젝트에서 각 팀원들이 맡은 역할을 잘 분배하고 잘 수행하기 위해서 입니다.

제가 몸담고 있는 '게임' 이라고 하는 분야를 포커스로 이야기를 진행하도록 하겠습니다.

'게임' 이라고 하는 분야는 옛날엔 오락이었을 뿐이었지만,

현재는 '예술' 이라고도 칭하는 경지에 이르렀습니다.

디자인/개발/음악/기획/시나리오 등 많은 분야의 사람들이 모여서 같이 어떤 창작 활동을 하기 때문에 저는 예술 그 이상의 분야라 생각합니다.

그런데, 왜 팀 프로젝트에서 설계를 할까요?

간단한 상황을 들어보도록 하겠습니다.

어떤 미소녀 캐릭터가 있고 사운드 효과들이 포함되어 있으며 스토리가 포함된 액션 게임을 만든다고 칩시다.

시나리오 작가 : 열심히 미소녀 캐릭 액션 게임 스토리를 상상했습니다.

디자이너A : 주인공을 만들기 위해 피카츄를 그렸습니다.

디자이너B : 배경을 그렸습니다.

음원 제작가 : BGM과 이펙트 소리들을 만들었습니다.

프로그래머A : 대선 준비를 했습니다.

프로그래머B : 치킨만 먹었습니다.

자...우리는 여기서 무엇을 알수있는가? 하면.

네 안됩니다!!

안되요!! 뭘 해달라는거야!!

어떤 미소녀 캐릭터가 있는건 알겠는데, 스토리는 작가가 알아서 한다치고

디자이너와 프로그래머 및 음원 제작가는 대체 무엇을 만들었을까요...

알 수가 없습니다.

그냥 프로그래머 B가 치킨먹을때 같이 먹었을거 같아요.

여러분. 팀 프로젝트를 할 때는 항상 기본적인 육하 원칙을 지켜서 진행해야합니다.

1. 언제

2. 어디서

3. 어떻게

4. 무엇을

5. 누가

6. 왜

기본적으로 위 사항을 딱 한번만이라도 생각해본다면 여러분은 팀프로젝트를 진행할 수 있습니다.

일일이 모든 사항을 언급해서 적진 않겠습니다만, 간단히 요약해서 정리하자면

팀 프로젝트를 진행 하실 땐, 항상 누가 무엇을 한다. 라는 것을 지적해서 정해야 합니다.

따라서, 팀 프로젝트를 진행할 땐 항상 설계를 해야하는데,

어떤 설계를 해야하는가? 에 대해서 설명하겠습니다.

1. 일주일 간 진행할 목표를 정하자.

2. 다다음 회의 내용을 생각하자.  (다음이 아닙니다! 다다음 이에요!)

3. 스케줄을 만들자.

입니다.

첫 번째 항목부터 보도록 할까요.

1. 일주일 간 진행할 목표를 정하자.

프로젝트를 진행할 때 최종 목표는 이미 무엇을 만들자! 라는 식으로 정해져 있습니다.

그러면 마지막 최종 목표에 도달하기 위해 무엇들이 필요한지를 살펴봐야합니다.

제가 겪었던 한 예를 들어서 설명하겠습니다.

어떤 프레임워크를 만들기 위해 여러가지 어떤 내용들이 있는지 기능 별로 나눠서 포스트잇으로 적어보던 중 생각보다 많은 내용들이 등장한다는 것을 알게 되었던 적이 있습니다.

이 기능들이 모여서 결과적으론 최종 목표에 도달한다는 것도 다시 한번 눈으로 확인할 수도 있었지요.

그리고 이렇게 나눠놓은 리스트중에서 우선순위를 잡습니다.

우선순위 별로 포스트잇을 정렬시켜보니 위 그림처럼 나왔었습니다.

우선순위의 가중치는 여러 요인이 될 수 있습니다.

내가 지금 할 수 있는 것? 지금 당장해야 하는 것?

A 기능을 만들기 위해 B와 C가 미리 구현이 되어야한다는 점? 등등..

어쨋든 중요한 점은 이렇게 나눠본 프로젝트의 내부 항목들 중에서

이번 주에는 1~2번 기능을 구현하자. 라고 정하고 한 주 동안 개발을 시작하는 것 입니다.

만약 다음주까지 이 기능을 구현하지 못했다면 이 기능을 만드는데는 

"시간이 좀 더 필요하다" 라는 점을 경험할 수 있게 됩니다.

그리고 다음에 또 이와 같이 비슷한 기능을 만들 때 어느정도의 시간이 필요하겠구나

라는 것을 가늠할 수 있게 될 수 있습니다.

이런식으로 1~2 주 정도 진행하다보면 프로젝트를 진행하는데 감이 많이 잡히게 됩니다.

팀 프로젝트 단위에서도 마찬가지로 각자 맡은 개발분야에서 이런식으로 약속한 기간에 맞춰 회의 할 때마다 중간 점검을 하는식으로 진행을 하는 것이 좋습니다.

2. 다다음 회의 내용을 생각하자

왜 다음 회의 내용이 아닌 다다음 회의 내용을 생각하자 라고 했을까요.

사실 다음 회의 내용은 이번 주에 자신이 맡은 개발 파트가 어떻게 진행되냐에 따라

다음 개발 계획으로 진행이 될 것인지 말 것인지 의논하게 됩니다.

그래서 다다음 회의 내용을 생각하자 라고 한 것 입니다.

그러면 어짜피 다음 회의 내용을 생각한거랑 같은거 아닌가?

라고 생각이 드실텐데, 또 그것은 아닙니다.

그럼 대체 뭘 생각하란거야? 라고 느끼실텐데요.

한가지 상황을 통해 예를 들어보겠습니다.

1 주(진행중) - 어떻게 될지 모른다...다 만들수 있을지 없을지...(A 기능을 구현 중)

2 주 - B 기능에 대해서 생각해봐야한다.

그럼. 3 주 - ?????

무엇을 준비해야할까?

바로. 피드백 입니다.

다다음 회의 내용을 위해 생각할 것은 프로젝트에 대한 개발 내용보다는 

(1)이전에 했던 작업물에 대한 다른사람들을 위한 피드백 또는

(2)내가 하고있는 작업물에 대한 내용 정리입니다.

왜 이것을 해야할까요?

팀 프로젝트의 목적 상. 본래 어떤 목표를 위해 개발을 하는 것이지만.

결과만 바라보고 개발 과정을 정리하지 않으면

뒤에는 큰 후회만 남습니다.

왜 냐구요?

그 프로젝트가 끝까지 완수 될지 안될지 누가알아요!!!

만약 프로젝트가 중간에 파토가 나버리면 쏟아 부었던 노력에 대한 보상은 누가해주나요!?

아무도 안해줍니다. 없어요. 누가 해줄까요. 사장님? 팀장님?

물론 회사 라면 월급받고 일할테니 나의 경력과 돈이 생기겠지요.

하지만, 상업적이거나 회사에서 일하는 팀 프로젝트가 아니라면, 그 누구도 프로젝트가 파토났을 때 보상을 해줄 사람이 없습니다.

따라서, 다다음 회의 내용을 위해 피드백을 준비하라 라고 한 이유는

 (1) 팀 프로젝트가 계속 활발히 개발되어지고 있으며, 우리는 할 수 있을 거야 라는 확인하는 점

 (2) 중간 중간 내용을 정리하고 점검하며 내 실력을 쌓고 

 (3) 다른 사람이 만들었던 내용을 저장해야한다는 점

때문 입니다.

이런 내용들은 추후에 여러분에게 어떠한 것으로든 지적 재산이 될 수 있습니다.

3. 스케줄을 만들자

마지막으로 강조할 내용은 스케줄입니다.

Q. 왜 스케줄을 만들어야할까요?

A. 가장 큰 이유는 팀원들 스스로에게 책임감을 부여하기 위함 입니다.

시간 제한이 있다는 점은 항상 맡은 이에게 언제까지 끝내야 한다라는 책임을 느끼게합니다.

그리고 압박감을 느끼게 되지요. 물론 시간적으로 여유가 있다면 압박감은 덜하겠지만

언제까지 만들어야 한다는 점은 바뀌지 않습니다.

때문에, 팀 프로젝트를 진행 할 때는 꼭 스케줄을 만들어서 언제까지 무엇을 만들겠다 라는 규칙을 정해서 진행해야합니다.

적다보니 주관적인 내용들이 들어가면서 조금 글이 길어진 것 같습니다.

그래도 여기까지 읽어주셨다면 정말 감사드리고, 한줄 요약으로 마치겠습니다.

한줄 요약

 - 주 단위로, 작은 목표를 정해서 진행하고, 스케줄을 잘 관리하자!

3. ㅁㅁ을 자주 가져라.

팀 프로젝트를 어떻게 진행해야하는가? 하는 문제를

'보상', '참여 유도' 를 통해 이전 글에서 이야기 했었는데요.

세 번째로 언급할 사항은 "만남을 제때 가져라" 입니다.

응?? 왜 결론을 먼저 바로 얘기해주냐구요?

(숨겨봤자...뻔히 보이기 때문에...)

이미 첫번째 글에서 언급 된 

'3. 정기적인 회의 여부' 라는 항목에서 추론할 수 있기 때문에 결론을 바로 언급했습니다.

이 사항은 온라인/오프라인 작업에서도 똑같이 중요한 대목입니다.

정기 회의가 있는 회사라면 기본적인 내용이라 별로 유심히 보시지 않을 수도 있는데요.

혹, 대학 생활을 하시고 계시거나 별도의 온라인 활동을 통한 팀 프로젝트를 진행하고 계신 분들이 있으시다면 도움이 되실 수 있을까 해서 설명해보도록 하겠습니다.

앞서, 팀 프로젝트가 파토가 나는 경우의 절반은 팀원 참여의 부재로 인해 발생하는 예가 많다고 얘기한 적이 있습니다.

왜 그럴까요? 그냥 팀원 한명 자체가 삐꾸- 라서?

뭐...그렇다면 애시당초 사람 문제니 여기서 다룰 내용은 아닙니다.

그러나..참여를 하다가 중간에 파토가 나는 경우라면?

여러 요인이 있을 수 있으나, 여기서 다루고자 하는 것은 "팀 프로젝트가 잘 되다 파토가 나는가?" 라는 문제를 수면위로 끌어올리고자 합니다.

우리나라 IT기업들을 보면 흔히 회의를 엄청나게 많이하는 것을 볼 수 있습니다.

(아주 사람 귀찮게 하네 라고 느껴질 정도?)

또는 엄청 적게 하는 경우도 있지요.

(이건 뭐 하자는 건지 말자는건지...?)

잠시 '회의' 라는 말의 사전적 의미를 적어보겠습니다.

뭔가 '회의' 라는 단어 자체에도 많은 뜻이 내포되어 있군요.

여기서 다루고자 하는 회의는 가장 첫번째 회의(回議) 와 가장 마지막 회의(會議) 입니다.

왜 제가 "만남을 제때 가져라" 라고 했을까요?

먼저 제가 여기서 언급하는 회의가 필요한 이유는 3가지로 정리 됩니다.

(일반적인 회의의 이유에 대해서는 언급하지 않겠습니다. 당연히 필요하니까 회의하잖아= _=)

1. 팀 프로젝트의 진행(Progress)를 확인하기 위해

2. 팀원들의 책임감을 고양시키기 위해

3. 팀 프로젝트의 개발 효율성을 증대시키기 위해

이렇게 3가지 이유 입니다.

왜 이렇게 나왔는지 각 이유를 따라 적어보도록 하겠습니다.

1. 팀 프로젝트의 진행(Progress)를 확인하기 위해

왜 팀 프로젝트의 진행도를 확인해야 할까요? 

음...그냥 관리차원에서? 서로 맡은 파트가 얼마나 진행 됐는지 감독하려고?

윗 사람이 아랫사람을 관리하는 것이라면 그럴지도 모르겠네요.

하지만 동일 선상의 관계를 가진 팀원들이라면 누가 누구를 관리/감독 할 일이 있을까요.

ㅁㅁ

제 대답은...

진행도를 확인하는 것은 모두가 다같이 책임져야하고 알아야하는 내용이기 때문이라는 것.

입니다.

(아마 2. 팀원들의 책임감을 고양시키기 위해. 라는 말이랑 겹쳐 보일 수도 있겠네요.

하지만 2번에서 언급할 근거는 다른 내용이니 걱정안하셔도 됩니다)

본론으로 들어가도록 하조~

흔히 IT기업에서 프로젝트 매니저 라고 하는 직군을 볼 수 있었을 겁니다.

이 사람들 대체 왜 있을까요? 저도 모르겠어요...

근데 뭔가 하는거 같긴해요..

위 말은 농담으로 적은 내용입니다만, 뭔가 필요하고 하는 일이 있으니까 있는 직군입니다.

(그 분들이 몸 담고 있는 직군의 정체성을 부인하고 싶은건 아니에..!)

(공격 하...지말..주..주세요..으어..)

그런데 소규모 팀 프로젝트 단위에서 프로젝트 매니저가 있을까요? 없겠지요~

하물며 회사도 아닌, 초급자/인디/동아리 등등...

이런곳에서 진행하는 팀 프로젝트라면? 더더욱 없습니다.

그래서 우리가 진행하는 팀 프로젝트가 어느 정도 진행되고 있고, 어디까지 왔는지를 서로서로가 확인할 필요가 있습니다.

그럼, 이렇게 해서 얻는 이점이 뭘까요?

바로 프로젝트 개발 계획의 조정이 가능하다는 점!

(개발 속도를 올린다 / 어떤 기능에 좀 더 주안을 두자. 등등)

더욱이 권위있는 리더가 이런 것들을 관리해주는 것이 아닌 팀 프로젝트라면 회의에서 즉석으로 얘기가 가능하기 때문에 회의의 필요성을 자주 느껴지실 겁니다.

물론 몇몇 분들은 회의 시간 자체도 아까워...라고 생각하실 수도 있으실텐데요.

다른 파트의 사람들과의 시간이나 협업 관계를 맺다보면 아마 저절로 필요성을 느끼실 수 있으

리라 생각듭니다.

그렇다고 너무 귀찮을 정도로 많은 회의는 가끔 짜증나긴하지요..

2. 팀원들의 책임감을 고양시키기 위해

회의를 한다는 것이 어째서 팀원들의 책임감을 고양시키는 게 될까요?

사실...책임감을 고양시킨다기 보다는 현실적으로 얘기하자면

회의에 참여해서 보여주기 위해 팀 프로젝트에서 맡은 부분을 반 강제적으로라도 참여하게 된다는 것 때문에 그렇습니다.

저는 자주 팀 프로젝트를 진행하는 사람들이 어떻게 진행해야할지 모르겠어...

라고 이야기하면 딱 한마디만 합니다.

"맨날 모여서 회의해 = _=)..그럼 뭔가 될꺼야"

(속으로)그리고 도주하는 너의 팀원을 보겠지...

회의라는 것은 어찌보면 사람을 귀찮게 하지만, 돌려 말하면 귀찮아지게 한다는 것은 뭔가 준비를 하게 만들기 때문에 귀찮게 한다는 것 입니다.

만약 회의가 귀찮지 않다면, 그건 회의를 좀 덜해보신듯...?은 아니고

이미 "즐기는 자"의 반열에 들어가신 것 일수도 있겠군요.

아무튼. 회의를 정기적/지속적으로 하면 각 팀원들의 참여를 유도할 수 있고, 회의에서 할 내용을 준비하게 만듬으로 팀 프로젝트를 지속 유지/개발 할 수 있습니다.

그래서 두 번째 이유를 팀원들의 책임감을 고양시키기 위해 라고 언급을 하였습니다.

3. 팀 프로젝트의 개발 효율성을 증대시키기 위해

음..회의 라는 건 사실 양날의 검 입니다.

작업할 시간에 영향을 끼칠 정도로 너무 많으면 오히려 방해 요소이고, 스트레스만 줄 수 있습니다.

그렇다고 너무 회의를 줄이게 되면, 현자 모드가 와버리는 경우가 있지요.

그래서 적당한 타이밍과 적당한 회의 시간이 중요합니다.

만약 같은 파트의 사람들끼리 모여있는 거라면 시간 제한 또는 스케줄을 만드는것이 좋습니다.

타임리미트 또는 due date(마감일)를 잡는다는 것은 현업에서도 흔히 발생하는 사건이며

일반적으로 그렇게 흘러갑니다.

개개인의 역량 및 스킬을 쌓기 위해 어떤 제한된 환경으로 국한 시키고 작업하는 습관은 나쁘지 않다 생각합니다.

(제 생각에는 개인 프로젝트에서도 적용시켜서 훈련할 필요가 있다 봅니다)

물론 상업적으로 진행하는 금전적인 목적의 팀 프로젝트라면 위 내용을 꼭 지킬 필요는 없습니다. (실력 쌓는것 보다도 일단은 돈버는게 중요하니까...만약 회사라면 이야기가 조금 다릅니당!!)

그리고 팀 프로젝트를 진행하는데 있어서 스케줄은 각 팀원들의 반 강제적 참여를 유도하게 됩니다. 만약 타임리미트가 없는 일이 주어졌다면, 그게 언제 끝날지 알 수가 없기 때문에 마냥 그 팀원이 해결해주기만을 기다리고 있어야하지요. 

(이런 점은 제가 뭐 따로 언급하지 않아도 다들 몸소 느껴보셨거나 느껴보실거라 생각듭니다)

따라서, 이런 스케줄이나 타임리미트들은 회의에서 정해지고 회의에서 결과가 다뤄지기 때문에 세 번째 이유로 언급하였습니다.

그럼 마지막으로.

대체 언제? 어떻게? 얼마나 길게? 자주? 회의를 해야할까요?

이 문제는 어떤 스타일이냐에 따라 개개인마다 그리고 팀마다 다르겠지만.

개인적으로는 주 1회 (2시간 동안)이 마지노선이라 생각합니다.

만약 일주일 동안 진척된 내용이 많지 않아서 회의할 내용이 마땅히 없더라도

위 이유중 1, 2번의 이유에 근거하여 회의를 진행할 필요가 있다고 보고 있습니다.

한줄 요약.

 - 정기적으로 회의를 진행해서 서로 무언가를 하고있고 진척되고 있어! 라는 걸 확인합시다.

2. ㅁㅁ를 유도하라.

일반적으로 팀 프로젝트는 서로 얼굴을 알고 있는 사람들끼리 진행 되는 경우.

오프라인으로 프로젝트가 진행되어, 서로 가까운 자리에서 진행되는 작업이

매우 능률이 좋고 작업 속도가 온라인에 비해 잘나오는게 사실입니다.

그런데...위와 같은 경우는 회사를 제외하고선 한 자리에 모여서 진행하기 어렵다는게 안타까운 현실입니다.

마땅한 사무실이나 작업실이 있지 않는 한, 공동 작업을 펼치기 어렵기 때문이조.

해서 결과적으로 "조별과제" 라고 하는 패러디 같은 것이 우르르 나오고

한 명이 개고생을 한다? 라는 상황들이 자주 연출되거나 팀 프로젝트가 파토나는 경우가 허다합니다.

그럼 팀 프로젝트는 무조건 오프라인으로 진행해야 되는가?

만약 그럴 수 있다면 정말 좋지만!! 현실이 그렇게 허락하지 않으니 문제입니다.

그리고 한 자리에서 같이 작업하는 것을 기피하는 사람들도 있을 수 있습니다.

(저 또한, 개인적으로 혼자 작업하는 것을 좋아하는 스타일)

이런 작업 스타일은 서로 존중해줘야 하며 그렇지 않는다면 

팀 프로젝트에 참여하고자 하는 동기가 깨질 수 있습니다.

만약 여러분이 

"온라인/오프라인 진행이 그럼 무슨 상관이냐. 그냥 팀 프로젝트 잘 진행하기만 하면 되지."

라고 결과만을 쫓아간다면, 

팀 프로젝트가 파토나거나 자신이 버스기사로 운전을 하고 있는 경험을 하게 될 것 입니다.

사실 위 생각대로 온라인/오프라인 진행은 중요하지 않습니다. 네. 그럼 왜 적었는가?

온라인/오프라인 작업이란 것은 이 글을 보시는 분들께 키워드를 던지기 위함입니다.

여기서 중요한 점은 온라인으로 작업을 같이하건, 오프라인으로 같이 작업을 하건.

중간 단계의 결과물을 도출하고 참여를 유도하라. 입니다.

사실 팀 프로젝트가 파토가 나는 경우의 절반은 팀원의 참여 부재로 인해 발생하는 사례가 많습니다. 글쓴이 본인도 많이 겪었고 글쓴이 본인도 그렇게 행동했던 적이 있어서 많이 반성하고 있습니다.

그럼..어떻게 참여를 유도할까요?

중요한 점은 내가 팀 프로젝트에 기여하고 있다 -> 참여에 따른 뿌듯함을 느낀다.

라는 것을 만들어야 합니다.

예를 들어서, 개발자들끼리 팀 프로젝트를 진행 할 때.

나의 코드가 다른 사람에게 어떤 기능을 제공해주거나 다른 사람이 내 코드를 통해 어떤 편리함을 제공 받았다면, 내 작업물이 도움이 되는지 피드백을 받는 것도 좋은 방법 입니다.

그러나 꼭 같은 분야의 사람끼리 팀 프로젝트를 진행하란 법은 없지요.

그럼 다른 파트의 사람들끼리 있을 땐 어떻게 해야 하는가?

가장 좋은 방법은 내가 당신을 통해 일하고 있어요~ 라는 점을 보여지게 하면 됩니다.

가령, 프로그래머 ↔ 디자이너 관계에서

디자이너가 캐릭터를 그리면 그것을 움직이게 만들어 주는 것이 개발자의 몫 입니다.

캐릭터가 만약 움직이게 된다면 디자이너는 자신이 그린 캐릭터가 움직이는 데에서 뿌듯함을 느낄 것이고, 프로그래머 또한 거기서 뿌듯함을 느끼겠지요.

이처럼 팀 프로젝트의 중간 개발단계의 결과물들을 통한 기여에 따른 결과에 대한 성취감을 얻는 것이 중요합니다.

그러나...말처럼 이런 경우가 쉽게 나오지 않는 예도 있습니다.

글쓴이 본인이 겪었던 한 예를 들어보겠습니다.

두 프로그래머 친구가 같이 팀 프로젝트로 게임을 하나 개발하기로 했습니다.

여러가지 내용을 개발하던 중..

A 친구가 플레이어를 만들고 싶다고 했습니다.

그러나 B 친구도 플레이어를 만들고 싶었습니다.

그래서 두 친구는 서로 플레이어의 개발 내용을 서로 나누기로 결정합니다.

A친구가 플레이어의 스테이트를 만들기로 하고

B친구가 플레이어의 액션과 인벤토리를 만들기로 결정했습니다.

A, B 두 친구가 만든 플레이어는 어떻게 됐을까요?

개판입니다. 

말 그대로 개판이에요. 난리가 아닙니다. 

플레이어 캐릭터에서 어떤 버그가 발생해서 B친구에게 고쳐달라고 했더니 이건 A 친구가 만든 거라 내가 못건들어. 라고합니다.

.....(뭐 어쩌라고...)

솔직히 어떤 거대한 프로젝트라면 큰 틀에서 내용을 나눠 역할에 따라 분담하는 것이 맞지만 너무 디테일하게 들어가서 어떤 역할과 의미를 가진 객체를 쪼개버리면 추후에 위와 같은 문제가 발생 하는 경우가 있습니다.

이런 경우 팀 프로젝트의 진행 자체에 자원적으로 많은 영향을 끼치게 됩니다.

(시간, 돈, 기분, 관계 등등...)

위 내용에 대해서는 추후 기회가 된다면 다시 언급하도록 하고...

다시 본론으로 돌아오겠습니다.

제가 위 사례에서 말하고 싶은 것은. 성취감을 얻을 수 있는 항목을 너무 분할하지 말아 달라는 뜻 입니다.

팀 프로젝트의 참여를 유도하기 위해 서로의 피드백이나 결과를 통해 기여에 따른 성취도를 얻는 것은 중요하다 말했습니다. 그러나 위 사례처럼 그 성취감을 얻을 수 있는 내용을 다른 사람과 나눠 버리게 되면 그 만큼 참여를 유도할 수 있는 능률 자체도 나뉘게 된다는 뜻 입니다.

그렇다고해서 나누지 말라는 뜻은 아닙니다.

어떤 거대한 프로젝트나 많은 기능을 가진 객체를 분담하여 개발하는 것은 좋은 방법이조.

다만, 프로젝트 스케일이 어떤가에 따라서 팀 프로젝트 참여를 유도함에 악영향을 끼칠 수 있다는 뜻 입니다.

마지막으로 정리하자면,

팀 프로젝트를 진행 할 때는 자신이 어떤 것을 맡고 있고,

맡은 분야에서 성취감을 얻을 수 있는지를 확인하시는 게 중요합니다.

(성취감을 얻을 수 있다? 라는 걸 매번 미리 알 순 없겠지만, 그것을 얻을 수 있을거야~ 라는 기대를 갖는 것 만으로도 충분합니다)

한줄 요약.

 - 팀 프로젝트에 자신이 기여하고 있고 성취감을 얻기 위해 지속적으로 참여하도록 유도하라.

많은 분들이 팀 프로젝트를 진행하다가 좌절하거나 파토나는 경험을 많이 하실텐데요.

글쓴이 본인도 수 많은 팀 프로젝트 경험을 쌓은 것은 아니지만

여러 프로젝트를 진행하며 겪었던 경험을 바탕으로

이런 관점으로 팀 프로젝트를 진행하는 것은 어떤가? 라는 제시를 하고자 적어보게 되었습니다.

먼저 어떻게 팀 프로젝트를 진행해야 하는가 고민하기 전에!

자신의 팀 프로젝트가 어떤 속성을 갖고 있는지 먼저 파악해야합니다.

프로젝트의 목적 및 동기와 의도에 따라 팀 프로젝트를 진행하는 방향과 방식이 매우 달라집니다.

위의 3가지(목적/동기/의도) 항목에 따라 팀 프로젝트의 성향을 분류해보면 다음과 같은 요소들이 팀 프로젝트의 성향 및 방향을 결정하게 됩니다.

1. 상업적 / 비상업적

2. 온라인 작업 / 오프라인 작업

3. 정기적인 회의 여부

4. 개발 기간의 제한

5. 리더의 존재 여부

위 5가지 내용이 팀 프로젝트의 성향과 방향을 구분 짓는 주 요인입니다.

그 외 다양한 요인으로 인해 팀 프로젝트의 성향에 영향을 끼칠 수 있으나, 개인적으로 위 내용이 지대한 영향을 끼치는 항목들이라 생각하고, 아마 다들 같은 생각을 하시리라 믿습니다.

그럼 팀 프로젝트를 어떻게 진행해야하는가? 를 살펴보겠습니다.

1. ㅁㅁ을 확인하자.

팀 프로젝트를 진행함에 있어서 상업적인가 비상업적인가 하는 목적이 팀 프로젝트에서 가장 우선시 되는 중요한 요인입니다.

딱히 위 말의 의도가 비상업적인 것은 뭐가 다르나? 라는 뜻은 절대 아닙니다.

그저, 상업적인 목적의 프로젝트는 팀 프로젝트 참여도에 많은 영향을 끼치기 때문에 이 글에서 우선순위가 높게 잡혀있습니다.

이미 여러분은 일상에서 "조별과제" 라는 키워드의 패러디가 많이 나와있던 것을 많이 보셨을텐데요. 이 문제는 직·간접적으로 금전적인 것에 문제와 연관됩니다.

만약 어떤 금전적인 이익이 있거나 금전적인 것을 목표로 한다면

참여도와 개개인의 책임감이 높은것이 사실이고, 반대의 경우 참여도와 책임감을 고양시키기 어려운 게 현실입니다.

상업적인 프로젝트는 금전을 통해 프로젝트를 활발히 참여 시킬 수 있지만

비상업적인 프로젝트는 대체 어떻게 해야할까요?

원초적으로 상업적이고 금전적인 목표가 아니기 때문에 해결할 방안이 없을까요?

이 질문에 대한 답을 먼저 해드리자면

해결 방안이 없는 것은 아닙니다.

그럼 어떻게??

한번 사고를 전환해서 생각해보겠습니다.

비상업적인 팀 프로젝트의 경우. 그 목적이 상업화가 아닌 다른데에 있다는 것을 주안점으로 둬야합니다.

예를 들면, 난 이 프로젝트를 포트폴리오로 쓰겠어! 라든가.

난 이 프로젝트를 진행하면서 여러 사람들과 사귀고 싶어! 라든지..

금전적인 것이 아니더라도 다른 목표는 많이 나올 수 있습니다.

그리고 이 목표는 개개인마다 다를 수 있지요.

결과적으로 이 말에 대한 의미를 풀어보면 

1. 상업적 / 비상업적 -> 내가 얻을 수 있는 보상은 무엇인가?

라는 문제로 직결됩니다.

이 보상이라는 부분이 나의 목표와 부합하고 만족스러운 결과를 낼 수 있다면

참여도와 책임감을 올릴 수 있고, 그렇지 않다면 좋은 결과를 내기 어렵습니다.

따라서, 먼저 팀 프로젝트를 진행하기전에 

개개인이 원하는 보상을 팀 프로젝트를 통해 얻을 수 있는지를 먼저 확실히 확인해야 합니다.

반대로 팀 프로젝트의 관리자 또는 리더의 입장이라면 팀원들에게 위 보상을 적절히 챙겨줄 수 있는지를 꼭 확인해야 합니다.

결과로 따라올 보상이 팀 프로젝트를 진행함에 있어 모두에게 적절하다면

그 프로젝트는 어떤식으로든 모두 보상을 위해 참여하게 될 것 입니다.

한 줄 요약. 

 - 팀 프로젝트에서 얻을 수 있는 보상을 확인하자.

아는 웹툰 그리는 지인에게 커미션을 요청했었는데, 어제 밤 완성 된 개인 캐릭터가 도착했다.

요청한 내용은 저자 본인을 뜻하는 컨셉의 캐릭터를 그려달라는 커미션이었다.

완성 된 그림은 아래 3개.

추후에 계속 틈틈이 여러가지 모션을 더 요청해서 그려달라고 할 계획이다.

캐릭터 컨셉에 대한 내용은 

1. 캐릭터 : 늑대 귀/꼬리/후드/안경/프로그래밍 작업중인 모습

2. 구도 : 정면

3. 의상 : 면바지 / 후드

로 요청했었다.

만든이 : 김낑