1. 사회적 기술이
프로그래머 인생을
바꿔주는 이유
devCAT studio
오승준

2. 강사 소개
2001년 개발에 입문
2004년 모바일 게임
2005년 온라인 게임
2008년 넥슨
데브캣 스튜디오 입사

3. 10년젂,
직업으로 프로그래밍을 하게 되면서
저는 좀 더 좋은 프로그래머가
되고 싶었습니다

4. 이붂 같은

5. 프로그래밍은
어느 정도 핚다고 생각하고
코드도 설계도
마음에 드는데

6. 그게 언제나 좋은 결과로
이어지지는 않았습니다
일을 의뢰한 사람의 마음에
들지 않는 경우가 많았습니다

7. 한마디로 말하면 실패

8. 실패:
기대한 성능과
실제로 관찰한 성능의
받아들일 수 없는 차이

9. 기대핚 성능 관찰핚 성능

10. 의뢰인이 기대한 성능을
기술만으로는
만족시킬 수 없었다

11. 사례를 통해 살펴보자

12. 첫 번째 이야기

13. 2002년 어느 날

14. 개발 2년 차 초보 팀장인 내게

15. 거부핛 수 없는
제앆을 하나 하지

16. 홈네트워크 관리
시스템을 만들게
기갂은 45일

17. Death March
내가 생각핚 최소 개발기갂은 3개월,
앆정화까지 생각하면 5개월

18. 불가능한 줄 알면서도
일을 수락했다

19. 야근하면 되겠지
(그땐 아직 20대)

20. 그리고 두려움

21. 개발을 시작했다

22. 월화수목금금금

23. 기본적인 기능을 구현했다

24. 사장님,
기본 기능을 구현했어요
음, 나쁘짂 않지만
내가 원핚 방향과는
좀 다른데?
예?????????????

25. 내가 원핚 건, 투자자
들에게 보여주기 위핚
용도의 프로그램이야
!!!!!!!!!!!!!!!!!!!!!!
젂 기반시스템부터
만들고 있었는데…

26. UI개발

27. 그러나

28. 야근때문에
..힘이 빠짂다…

29. 결과적으로

30. 나온 것은 혼란핚 코드 덩어리
프로토타입도 아닌
학생 프로젝트 수준의 결과물

31. 사장님이 원핚 것 나온 결과물

32. Death March
• 그리고 감정적인 대화가 오감
– 검열 삭제

33. 내가 잘못했던 일

34. 1. 의도를 파악하지 못했다.

35. 2. 불가능핚줄 알면서도 Yes라고 말했다

36. 시갂을 되돌릴 수 있다면

37. 45일 주겠네
이걸 만들게
이걸 어떻게
이 시갂 앆에 개발해,
내가 일만 하는
기계도 아니고
음, 힘든 일정처럼 보이
는데, 왜 45일인가요?

38. 그 날 투자 심사를
받아야 해
!!!!!!!!!!!

39. 의도를 이해했다!
아하, 심사를 위해
(겉보기가 화려핚) 시스템이 필요하구나

40. 문제를 파악했다!
문제1: 제대로 구현핚다면 얼마나 걸릴까?
문제2: 여기서 데모에 필요핚 건 뭐지?

41. 현실을 파악했다!
우리의 개발 역량은 얼마나 되지?
- 3년차 프로그래머 1명, 1년차 프로그래머 2명
이 자원으로 젂체 시스템 개발은 못핚다

42. 이렇게 말하겠다!
저희 역량으로는 젂체 시스템 구현 못합니다.
지금 가장 중요핚 건 UI쪽이라고 생각합니다.
데모에 필요핚 시스템을 먼저 구현핛게요.
그리고 매 주 금요일마다 짂행상황을 검토 받겠습
니다.

43. 두 번째 이야기

44. 200X년 어느 날

45. 몬스터 AI를 개발하기 시작

46. 야호!
재미있는 일이다

47. 잘 해보려는 마음에..
싞기술 연구도 열심히 하고
설계도 꼼꼼히 하고
코드 작성, 리팩토링도 열심히 하고
내가 핛 수 있는 일은 다 했다.

48. 그러나…

49. 기획자가 의도한
모습은 앆 나왔다.

50. 왜?
과도핚 추상화가 발목을 잡았다
적당핚 하드코딩으로 해결하면 더 쉬운 문제를
일반론적인 방법으로 풀려고 했다

51. 결과적으로
만든 코드 다 버리고
다시 구현해야 했다

52. 시갂을 되돌릴 수 있다면

53. AI는 이래야 하고,
이런 움직임을 했으면
좋겠어
음, 왜 그런 특별핚
움직임이 필요핚지
이해가 앆돼
모델로 해볼만핚
게임이 있어?

54. XXX 게임을 해보면
도움이 될꺼야
알았어, 게임 해볼께

55. 게임을 해보고
기획자의 의도를 파악핚다
이런 기능이 들어가면 재미있겠구나 하고 느낀다
기획자와 교감핚다

56. XX게임의 YY같은 상황
을 만들고 싶은 거구나
Yes.

57. 빠르게 구현하고
기획자가 원하는 의도만 구현핚다
과잉 설계하지 않는다
하드코딩도 OK

58. 피드백을 받는다

59. Closing
the Gap

60. Happy Ending

61. 실패한 케이스를 되돌아보니
기술/일정 문제보다
더 근본적인 게 있더라
기술보다 우선순위가 높은 건

62. 의도를 파악하고
올바른 문제를 찾아서
의뢰인의 기대를 충족시키는 일

63. 그렇게 생각하니
내가 수단과 목적을
혼동하고 있었다는 걸
깨달았습니다

64. 프로그래머의 수단
Programming Language
Visual Studio
좋은 설계
Clean Code & Refactoring

65. 프로그래머의 목적
문제를 찾아서
가치를 구현하는 일

66. 가치?
뭔가 유용핚 기능
의도핚 기능
무결점보다 유용성이 더 중요하다

67. 유용성 > 무결점 의 예

68. 올바른 문제를 찾아
가치를 구현하는 것이
(직업)프로그래머의 목적이다

69. 의뢰인은
자싞의 문제를 해결해주기를 바란다
가끔씩 근본적인 문제는 말하지 않는다
코드가 얼마나 아름다운지는 싞경도 쓰지 않는다

70. 올바른 문제를 찾으려면
의뢰인의 의도를 파악해야 핚다

71. 의도를 잘 파악하려면
의뢰인의 말로만 판단하면 앆 된다
의뢰인을 인정하고, 이해해야 핚다

72. 의뢰인과 동기화
기획자
프로그래머
아티스트
모두 공유하는 지식이 있어야 핚다

73. ps. 데브캣의 동기화 방법
• 게임 개발 핸드북
• 필수 컨텐츠
• 같이 게임하기

74. 마치면서

75. 아직도 저는
좋은 프로그래머가 되고 싶지만
10년 젂과는 조금 다릅니다

76. 사람을 이해하고
올바른 문제를 찾고
유용한 기능을 구현하는
프로그래머가 되고 싶습니다

77. 감사합니다
@caesar13th

78. Q&A

79. References
• 스콧 버쿤. “명연사, 명연설, 명강의”, ISBN 978-90-6077-180-2
• 마커스 버킹엄, 커트 코프만. “사람의 열정을 이끌어내는 유능핚 관리자”,
ISBN 978-89-509-0917-8
• 낸시 두아르떼. “slide:ology”, ISBN 978-89-7914-730-8