1. 프로그래머 생존 가이드
게임회사 프로그래머들을 위한 약간은 뻔한 이야기들
Smilegate 임태현

2. 목차
 시작하며
 좋은 프로그래머
 회사에서 일하기
 내일을 준비하기

3. 시작하며
2015년 조사에 따르면 전문가 집단의 유망 직업 전망은 다음과 같다.
결과에 따르면 프로그래머는 매우 좋은 직업이다… 진짜?

4. 프로그래머 직업의 진실
• 3D 업종
– 대부분의 프로그래머는 허리나 목에 문제가 있다
– 잦은 야근으로 만성 두통이나 우울증에 시달린다
• 의외로 박봉
– 게임 회사가 그나마 많이 주는 편인데 … 말 다했지
• 미래가 불투명하다
– 내가 은퇴할 때까지 프로그래머로 일 할 수 있을까?

5. 일을 그만 둘 수 없는 이유

6. 그렇다면 조금이라도 행복하게 일하고 싶어!!
야근
이다!
야식으론
피자 콜?
신난다~
콜라 추가
잊지마

7. 목차
 시작하며
 좋은 프로그래머
 회사에서 일하기
 내일의 나

8. 프로그래머는?
코드를 작성한다
소프트웨어를 만든다

9. 좋은 프로그래머는
좋은 코드를 작성한다
그럼 …
좋은 코드는?

10. 좋은 코드의 기준

11. 좋은 코드란 무엇인가
모든 기능이
테스트되었다
기능이 명확하다
다른사람들이 읽기 좋다
변경과 기능추가가 쉽다
From “Clean Code”

12. 좋은 코드의 최우선 조건
내가 생각하는
가독성
한가지만 기억해

13. 클린 코드는
단순하고 직설적이다.
클린 코드는 마치
잘 쓰여진 글처럼 읽힌다

14. 코드와 글쓰기
프로그래밍은 책을 쓰는 것과
같다.
… 단지 53페이지에서 콤마를
하나 빼먹었을 때 책 전체를
읽을 수 없을 뿐이다.

15. 코드와 글쓰기
좋은 글을 쓰는 방법중 하나는 직접 써보고 다른 사람의
것을 읽어보면서 자신의 생각을 효과적으로 전달하도록 훈
련하는 것이다.
코드도 마찬가지다!
오픈 소스 프로젝트를 적극적으로 활용

16. 이름짓기
한글자 변수는 사용하지 않는다
너무 일반적인 이름을 선점하지 않는다

17. 주석 달기
불필요한 주석은 달지 않는다
술에 취해 쓴 듯한 문장은 다듬어라
완료되지 않은 작업은 반드시 기록한다

18. 복사 금지
코드 복사가 일어나면 리팩토링을 해야 한다
코드 수정의
용이함은 덤!

19. 스태틱 사용 제한
스태틱 함수/클래스는
작업 속도를 빠르게 하고,
나머지 전부 나쁘게 한다.

20. 회사에서 일하기

21. 리팩토링 왜 하는가?
 성능 향상
 더 나은 디자인 패턴 적용
 할 때가 되었으니까

22. 리팩토링 왜 하는가?
 유지 관리 비용을 줄이기 위해서!
이번달은
야근이
필요없군

23. 리팩토링은 어떻게 진행하는가?
 리팩토링으로 얻을 이득을 분명히 한다
 작은 작업으로 분할 한다
 최대한 자주, 짧게 진행한다
 업무의 포함시킨다

24. 기존코드수정 vs 재작성
대부분의 프로그래머는
기존 코드를 고치기 보다는,
코드를 새로 만들고 싶어한다.

25. 프로그래머의 슬픈 습성
깨끗하고
단단한 땅이야.
이번에는
제대로 지어봐야지
맙소사
또다시 같은 것을
만들어 버렸잖아!

26. 나쁜 코드의 함정
누구도 나쁜 코드를 일부러 만들지 않는다.
일반적으로 두가지가 나쁜 코드를 강요한다
• 바쁜일정
• 계획 변경
그렇다면 이번에는 일정과 문서가 충분한가?

27. 목차
 시작하며
 좋은 프로그래머
 회사에서 일하기
 내일의 나

28. 첫 출근
옆자리 동료
말도없이일만한다 멘토
첫날 이후에는
만나기 힘들다
신입사원

29. 입사 1년
기한은 오늘
까지입니다
팀장

30. 입사 3년
남은 휴가 10일
오늘은 12월 29일
…..

31. 입사 10년

32. 죽음의 고리

33. 버그 야근 버그 야근 버그 ...
I. 계속되는 야근, 주말 출근
II. 체력 저하 및 몸에 이상증상
III. 우울증
IV. 가정 파괴
V. 국가의 몰락
VI. 세계 멸망

34. 아무도 가르쳐 주지 않는 진실
시키는 대로 해,
회사에서
잘리고 싶어?
…

35. 프로그래머의 본분
관리자들이 강하게 밀어붙이는 이유는 그것이 그들의 본분이기 때문이다.
프로그래머들의 본분은 좋은 코드로 양질의 소프트웨어를 만드는 것이다.
다행히도 많은 관리자들은 좋은 코드가 필요하다는 것에 동의한다.
설사 관리자가 나쁜 코드를 요구하더라도 그대로 따른다면
그것은 프로그래머답지 못한 행동이다

36. 나쁜 코드는 빚을 지는 것이다
잘생각해
너한테
돌아온다고
지르고
퇴사?

37. 열심히 보다는 똑똑하게
나는 어려운 일을 게으른 사
람에게 맡깁니다.
왜냐하면 그들은 쉽게 해결
할 수 있는 방법을 찾으려고
하기 때문입니다.

38. 똑똑하게 일하기
 개발 프로세스
 버젼 컨트롤

39. 개발 프로세스
• 폭포수
• 스파이럴
• 익스트림 프로그래밍
• 스크럼
절차 기반 프로세스
애자일 프로세스

40. 폭포수 모델
• 작업의 진척 사항을 파악하기 용이하다
• 결과에 이르는 최적의 방법을 찾을 수
있다.
• 초기 디자인이 잘못 되었을 경우 프로젝
트가 잘 못될 가능성이 크다.

41. 스파이럴 모델
• 프로토타이핑을 반복하면
서 프로젝트의 위험도를
관리한다
• 각 이터레이션은 폭포수모
델로 빠르게 진행하는 것
이 일반적이다

42. 전통적인 모델들의 실패
• 불확실성
• 요구사항의 변경
• 개발자 이탈
• 소프트웨어 개발의 특이성
• 잘못된 일정 관리

43. 난 애자일의 마법사
없어져라 야근!
XP
스크럼

44. 애자일의 탄생
스크럼 개발 방법

45. 애자일 선언문
 절차와 도구를넘어선 개성과 화합
 종합적인 문서화를 넘어선 동작하는 소프트웨어
 계약과 협상을 넘어선 고객과의 협력
 계획 준수를 넘어서 변화에의 대응

46. 수많은 애자일의 실패
대부분의 애자일은 크런치 상태를 풀어 쓴 것이다.
애자일의 짧은 주기와 요구사항 변경은 코드를 더 난잡하
게 만들고 무능력한 프로그래머를 애자일 뒤로 숨게 하는
효과가 있다.

47. 그럼에도 불구하고
소프트웨어 개발이 불확실하고 이를 유연하게 받아들임으
로써 위험도를 낮출 수 있다는 것에 동의하고 개선된 애자
일 방법론을 계속 연구중

48. 진행상황 파악이 쉽다
결과물에 대해서 신뢰도가 높다
작업 진행 속도가 빠르다
변화에 대응하기 유리하다
제품의 개발 방향 공유가 잘 된다
팀간의 소통이 활발해진다
상황 변화에 취약하다
문제가 마지막에 가서 발견되기 쉽다
최종일정을 도무지 알 수 없다
팀원 모두가 핵심 인력이어야 한다
프로젝트 기여도 측정이 어렵다
폭포수 모델 개발 애자일 개발

49. 애자일 활용 방법
• 예상치 못한 야근이 계속 이어질 때
• 데모 시연 일정이 짧을 때
• 팀원들이 프로젝트 관심도가 너무 낮을 때
게임회사에서는
일반적으로
폭포수 모델이
잘 맞지…

50. 버전 컨트롤
아직도
안쓰고 있냐?!

51. 소스코드 관리의 어려움
 개별 작업물 통합
 경영진 데모
 게임쇼 출품
 해외 출시

52. 버전 컨트롤
버전 컨트롤이 없다면 엄청난 기억력과 인내심이 필요하다.

53. 버전 컨트롤 소프트웨어
• CVS
– 가장 오래된 버전 컨트롤 시스템
– 체크인/체크아웃을 통해 동시성 관리
• Subversion (SVN)
– CVS 시스템의 개량 모델
– 버전을 도입해서 파일의 변화를 추적
• Git
– 소스코드 관리에 특화된 버전 컨트롤 시스템
– 전통적인 모델과는 달리 서버에 접속을 유지할 필요가 없다
– 최근 트렌드. 뭔가 있어 보인다
• Mercurial
– Git 의 형제 (둘다 리눅스 커널 소스 관리를 위해 시작)
– 페이스북이 소스코드 관리에 사용하면서 알려지기 시작

54. 목차
 시작하며
 좋은 프로그래머
 회사에서 일하기
 내일을 준비하기

55. 자신의 무기를 만들어라
• 모든 분야를 다 공부하는 것은 불가능하다
• 특정 분야를 정하자
– 그래픽스
– 네트워크/서버
– 인공지능
– 데이터베이스
• 스터디 모임이나 개인 프로젝트를 해보자

56. 프로그래머
테크니컬
리드
매니져
테스터
빌드/통합
게임 디렉터
창업
치킨집사장
그래픽스
시스템
웹
아키텍트

57. 프로그래머의 진로
• 아키텍트 : 시스템 설계를 전문으로 하며 객체화나 패턴 적용
등을 주로 담당한다.
• 테스터 : 유닛테스트나 오토매틱 테스트를 전문으로 하는 직
업. 한국에는 그다지 유명하지 않지만 미국같은 곳에서는 유
망 직업으로 소개되기도 한다.
• 빌드/통합 : 빌드 마스터라고도 하며, 소스코드 커밋관리와 자
동 빌드 시스템, 브랜치 관리를 하게 된다. 넓은 의미로 오픈
소스 프로젝트에서 기여자 관리로 이에 해당한다고 할 수 있
다.

58. 프로그래머의 진로
• 테크니컬 리드 : 프로젝트에 필요한 원천 기술과 문제 해결기법에 대해서
가이드 해준다. 결과물에 대한 이해가 높아야 하고 이를 완성하는데 기여하
여야 한다.
• 매니져 : 테크니컬 리드가 작업이 진행되게 하는직책이라면, 매니져는 작업
자체를 설정하는 직책이다. 일정과 퀄리티에 대한 가이드를 해주어야 하며
리더쉽이 필요한 직책이다. 오래 일한 사람에게 매니져를 주는 경우가 많은
데, 매니징 스킬에 대한 이해도 없이 실패하는 경우가 많다.
• PM : 제품을 생산해서 실제 클라이언트(사용자) 손에 들어갈 때 까지의 과
정을 종합적으로 관리한다. 개발 프로세스에 대한 지식을 필요로 하기 때문
에 개발자가 PM 으로 직책을 이동하는 것이 유리하지만, 현실적으로 마켓
팅이나 사업 담당이 개발 프로세스를 공부해서 오는 경우가 대부분이다.
지쳐서 정리가
안된다.

59. 리더쉽도 훈련이다
일을 시킨다
권위를 이용한다
일이 잘못되면
책임을 묻는다.
방법을 알고 있다
명령을 한다
“Go”
일을 가르친다
의도를 알려준다
일이 잘못되면
문제를 해결한다
방법을 보여준다
요청을 한다
“Let’s go”

60. 티내면서 일하기
• 매니져는 프로그래머가 무엇을 했는지 잘 모른다
• 자신의 작업이 창의적이고 높은 밸류를 가지고 있다면
적극적으로 설명해본다.
• 자신의 작업을 다른 사람에게 명쾌하게 설명하는 것은
의외로 어렵다.
– 이것을 훈련하면 이직 할 때 큰 도움이 …

61. 업무 외 활동
• 커뮤니티 활동
– 개발자 커뮤니티
– 스터디 모임
• 오픈 소스 프로젝트 기여
• 컨퍼런스/워크샵 참여
– http://www.slideshare.net/devcatpublications/ndc2013-19986939

62. 퇴근 후 수입 활동은 주의
대부분의 회사에서 아르바이트를
비롯한 “투잡” 에 대해서 금지하고
있다.
사규에 어긋나지 않도록 주의!

63. 건강 관리
• 개인적인 경험으로 건강에 무리가 갈정도의 야근이나 폭음 등
은 조심하자
• 야근으로 인한 건강악화가 생겨도 업무상 관계 인정이 매우
힘들다
– 거기다가 환자가 직접 증명해야 한다.
• 때로는 과감한 휴식도 장기전을 위해 필요하다고 조언한다.
– 돈과 건강을 바꿀 수 있는 것은 건강했을 때 단 한번 뿐이다.

64. 마치며
너무 지쳐서 .. 질문은 생략