2. 발표자
• 데브캣스튜디오 서버엔진팀
• 2006년부터 게임 개발
• 카바티나 스토리, 버디러시, 마비노기듀얼
• 현재 프로젝트 MV 서버 담당
• NDC 2017
<내가 만든 언어로 게임 만들기> 발표
• ds5ttk@gmail.com @pb_isb
3. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
4. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
5. 이런 내용을 이야기 합니다
• 개발 조직이 신입 프로그래머를 교육하는 법
• 조직의 프로그래머를 관리자로 성장시키기
• 좋은 엔지니어링 문화 만들기
표지, 목차 포함 총 75 페이지. 발표 시간 50분
6. 이런 내용을 다루지 않습니다
• 게임을 만들 때 어떤 기술이 필요한가?
• 뭘 공부하면 게임 프로그래머 지망에 도움 되는가?
-> 이런 기술적인 내용은 다루지 않을 것
스튜디오 전체를 대상으로 발표했던 내용이어서
아무나 들어도 쉬워요 😃
7. 이런 분들에게 도움이 될 거예요
• 교육을 담당할 시니어 프로그래머
• 무엇을 배우고 어떻게 적응할지 궁금한 신입
• 조직 관리에 관심 있는 관리자
• 학교와 회사가 어떻게 다른지 궁금한 예비개발자들 (?)
8. 저는 게임 프로그래머가 아닌데요
• ‘게임’ 프로그래머가 아니어도 이런 방법 쓸 수 있고
• 게임 ‘프로그래머’가 아니어도 힌트가 될 듯
(내부 발표 때 다른 직군 분들이 많이 공감해 주셨어요)
9. 본론을 미리 살짝
• 이 발표의 원래 제목
여기에 관한 얘기를 할거
1. 무엇인지 2. 왜 하는지 3. 어떻게 하는지
10. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
11. 영화에 비유해보면
• 영화 감독의 중요한 일 중 하나가 배우들의 연기 지도
• 감독의 의도를 배우들의 연기를 통해 스크린에 표현하기 때문
• 배우들의 연기를 관리하지 못하면 영화의 완성도가 떨어질 것
12. 게임에서라면?
• 프로그래머는 게임의 기획과 아트 어셋을 꿰어
제품으로 완성하는 최종 관문
• 프로그래머의 역량, 기술 수준이 낮다면
게임 전체의 구현과 서비스 품질이 떨어진다
• 프로그래머의 역량을 관리해야 한다
13. 학교에서 배우는 거 아닌가요?
“공부는 학교 다닐 때 해야지 왜 회사에서?”
• (관련 전공이라면) 공유하는 지식 기반은 비슷
• 언어, 자료구조, 알고리즘, 네트워크, DB, OS, …
• 품질 기준이나 업무를 보는 관점이 크게 다름
• 구현 품질, 유지 보수 기간, 협업, …
• 평가 기준이 달라짐
14. 경력이라면 괜찮을까?
“여태까지 잘 일해왔는데 교육이 필요하다구요?”
• 조직마다 문화와 기준이 다름
- 팀의 규칙, 정책 학습 필요
- 메인 언어가 바뀌기도 함 (C++ -> Python 처럼)
- 낮은 품질 기준에 익숙할 수 있음 (코드리뷰 경험자가 적음)
• 조직 문화에 동화시키기 위한 재교육이 필요
15. 실력 있는 동료의 중요성
• 회사에서 가장 큰 복지는 똑똑하고 실력 있는 동료
• 조직의 코드 품질은 프로그래머의 업무 환경
• 팀의 코드 품질이 나쁘면 깨진 기능을 복구하거나
문제를 추적하는데 시간을 많이 쓴다
• 동료들이 잘 해줘야, 내가 좀더 의미 있는 일에 시간을 쓸 수 있음
• 동료들의 실력 ∝ 나의 생산성
16. 무엇을 가르치고 싶나요?
나의 교육 목표
1. 커뮤니케이션 하는 법
2. (동료들과 자신이 만족하는) 좋은 코드 작성
3. 조직의 노하우와 가치를 반영하는 설계
+. 조직마다 각자의 목표
17. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
18. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
19. 프로그래밍 업무 교육
저는 이런 방법을 사용합니다
1. 자신의 일을 잘라서 나눠주고
2. 방법을 자세히 알려주고
3. 결과물을 확인해서 피드백
이 과정을 반복!
34. 설계 리뷰를 통해 배우는 것
1) 문제를 볼 때 사고의 흐름, 체크 리스트
2) 가치들 간의 우선 순위 (타협할 수 있는 것과 할 수 없는 것)
3) 성능, 품질 기준의 설정과 비용 분석
(계속)
35. 설계 리뷰를 통해 배우는 것
4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계
5) 미래의 스펙, 환경 변화에 대비하는 설계
36. 설계 리뷰를 통해 배우는 것
4) 참고할 만한 기존 또는 과거의 (좋은 / 나쁜) 설계
5) 미래의 스펙, 환경 변화에 대비하는 설계
6) 설계 핑퐁을 통해 설계를 완성해 가는 과정
37. 커뮤니케이션
• 프로그래머는 생각보다 말을 많이 한다
• (통념과 달리) 기계와 일하는 직업이 아님
• 코드 리뷰, 설계 리뷰 모두 말이나 글로 하는 것
http://news.jtbc.joins.com/article/article.aspx?news_id=NB10294996
38. 커뮤니케이션
"프로그래밍은 보이지 않는 기계의 동작을 말로 설명하는 행위"
• 커뮤니케이션이 단순히 사교적인 활동을 의미하지 않음
• 문제와 해결책을 말로 주고받는 것은 전문적인 기술
• 가르치고 훈련할 수 있을까?
제가 낸 버그 아닙니다
39. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
40. 커뮤니케이션
• 문제를 공유하고 커뮤니케이션 하는 건
(엔지니어링) 업무의 기본
• 아침회의 : 커뮤니케이션을 훈련시키고
조직 문화의 공감대를 만드는 도구
41. 아침 회의
• 회의 매일 하는거 시간 낭비 아닌가요?
• 이슈 트래커 쓰면 되지 않나요?
42. 아침 회의
• 한일, 할일, 이슈를 돌아가면서 이야기
• 한 사람당 1~2분씩 짧게
• 전체 시간은 10분, 길어지면 20분
43. 아침 회의를 통해 연습하는 것
1) 중요 내용을 사실 중심으로 건조하게 요약, 보고하기
2) 모르는 걸 모른다고 이야기하기
3) 원하는 대답을 얻기 위한 질문 방법
4) 논쟁하거나 조율하는 대화의 톤, 적절한 표현
= 사교적인 대화보다 기술적인 대화를 훈련
44. 아침 회의를 통해 얻는 것
1) 동료들이 문제를 바라보는 관점과 접근 방식 이해
2) 동료의 업무를 조망하고 업무의 큰 그림을 이해
3) 내가 부딪힌 문제에 대한 실마리, 설계 검증
4) 각자 다른 일을 맡더라도 함께 협력한다는 연대감
“우리가 단지 돌을 자를지라도
언제나 대성당을 마음속에 그려야 한다.”
ⓒ 1997 EIICHIRO ODA.
45. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
+ 정리
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
46. 공통 패턴
• 역할과 롤 모델이 주어진다
• 모방을 통해 롤 모델에 가까워지려는 시도
• 피드백을 통해 개선을 확인하고 방향을 제시
• 난이도와 영역을 점진적으로 올려서, 사수의 업무를 대체 한다
47. 교육 목표: 업무 능력을 복제하자
• 나의 업무 능력을 복제하는게 목표!
• 회의 들어가서 자리 비워도 업무 진행 잘됨
• 채용 할 때 편함
• 업무 의견 핑퐁 할 수 있는 사람 많아짐
• 자기들끼리 가르치면서 증식함
• 배우는 사람은 성장감 을 느끼면서 일함
51. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
52. 코드 리뷰, 설계 리뷰, 아침 회의
이제 더 이상 신입이 아닌데
교육 목적이 아니어도 계속 필요할까요?
53. 업무 리뷰의 원래 목적
설계와 구현 품질을
• 개인의 책임이 아닌
• 조직이 관리하는 것으로
업무 환경과 작업 결과물의 품질을 보증하기 위한 것!
54. 코드 리뷰, 설계 리뷰, 아침 회의
• “혼자 일하지 말고, 팀과 같이, 동료와 같이 일하는 것” 을 의미
• 회사는 개인이 아니라 조직 전체를 통해 성과를 내야 함
-> 엔지니어링 조직이 가장 효과적으로 일하는 방식
구성원 간의 시너지를 최대한 끌어내는 조직문화
ⓒ 1997 EIICHIRO ODA.
55. 문화를 정착시키려면
• 관리자, TD : 프로세스와 문화를 리드하고, 구성원을 교육
• 구성원 : 조직 문화의 기반에서 일하고,
조직 문화를 다른 구성원에 전달하고,
조직 문화에 기여하면서 조직 내에서 입지를 만듬
• 관리자, TD 의 역할을 구성원에 분산함으로써
조직의 다음 관리자 후보들을 키움
59. 배움
• 넥슨 카바티나 팀
• 온라인 MMORPG. 게임 개발 관련 지식 배움
• 첫 3개월 교육 ≫ 다른 회사 2년 6개월 경력 (교육의 중요성)
• 컴퍼니100 도로시 팀
• 웹 브라우저 개발 업무
• 코드 작성 & 리뷰, 교육, 공부하는 법 배움
60. 가르침
• 컴퍼니100 버디러시 팀
• 모바일 캐주얼 RPG, 글로벌 원빌드 서비스
• 도로시, 카바티나에서 배운 걸로 신입 가르침
• 가르치는 경험, 라이브 서비스를 통해 성장
• 관리 경험을 쌓음
ⓒ Sollmo
61. 배움 + 가르침
• 데브캣 듀얼팀 서버
• 버디러시 라이브 경험이 도움
• 서버 업무 배움
• 코드 리뷰, 서비스 안정화
• 데브캣 서버엔진팀
• 듀얼팀 서버 경험 활용
• MV 서버, 실버바인 서버엔진 개발
• 코드 리뷰, 신입 교육
62. 커리어를 통해 배운 것
• 교육의 효과는 일회성이 아니라 지속성
• 이전 조직에서의 경험이 이후 프로젝트에서 지속적으로 활용됨
• 업무와 교육이 뚜렷이 분리되지 않음
• 교육을 통해 개인의 역량이 조직 전체로 전파되고
• 조직의 업무 퍼포먼스를 끌어올려야 업무가 궤도에 오름
• 그 경험을 통해 참여한 구성원들이 성장
63. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
64. 1. 코드 리뷰에서는 무엇을 보나요?
1) 컨벤션, 네이밍
2) 합의된 규칙
3) 좋은 코드
65. (부록) 좋은 코드?
• 클래스나 함수 설계는 충분히 추상화 되어있고, 의도를 잘 설명하는지
• 인터페이스는 충분히 정규화 되고, 직교적인지
• 해당 구현으로 의도하지 않은 사이드 이펙트가 없는지
• 로직 코드는 단순하고 불필요한 수행이 없는지
• 로직에 코너 케이스가 없는지
• 실행 성능에 복잡도 이슈가 없는지
• DB 접근이나 네트워크 접근 등에 성능 문제나 데드락을 일으키지는 않는지
• 프로그래밍 언어, 플랫폼을 잘 이해하고 효과적으로 활용하고 있는지
• 유닛테스트는 충분한 커버리지를 갖고, 지나치게 바이어스 되어있지 않은지
66. 2. 코드 리뷰를 잘 받는 요령
• 동작 확인 (필수)
• 구현 전 설계 리뷰
• 구체적인 리뷰 요청
• 커밋 분리
68. 4. 일방적인 도움이 아님
• 나의 지식을 점검하고 체계화 하는 효과
• 나도 가르치는 법, 업무를 지시하는 법을 익히는 것
• 시행 착오를 인정하고 서로 맞춰 가기
69. 5. 피드백 받는 어려움을 이해하기
• 지적은 업무상, 칭찬은 의식적으로
• 적절한 교습법에 개인 차가 있음
• 신입 버프가 도움될 수도
70. 6. ‘센스’, ‘상식’ 을 조심
• 교육자가 스스로 정의할 수 없거나, 일관성이 없을 때
• 학습과 교정에 노력을 투자하지 않아도
알아서 잘 해주기를 바라는 마음
• 내가 잘 가르치기 힘든 걸 상대방의 탓으로 생각하는 것은
관계를 건강하게 만들지 않음
• 감각의 영역이라면 시간이 필요
71. 7. 충분한가?
• 일상 업무를 잘 커버하지만
• 재난 상황의 감각을 학습시키기는 어려움 (경험이 중요)
• 사건 사고 기록이 도움
72. 목차
1. 어떤 발표인가요?
2. 왜 가르쳐야 하나요?
3. 이렇게 해봅시다
• 코드 리뷰
• 설계 리뷰
• 아침 회의
4. 조직 문화
5. 나의 경험 사례
6. 적용 해보기
마무리
73. 모두들 채용 얘기만…
• 밸브도 똑같아!
• 우수한 인재를 잘 뽑는 것도 중요하지만
유입되는 인재풀은 한정적
• 새 동료를 좋은 인재로 성장시키는 것이
조직 뿐만 아니라 업계의 성장에 필요
• 밸브도 똑같아!
• 우수한 인재를 잘 뽑는 것도 중요하지만
유입되는 인재풀은 한정적
• 새 동료를 좋은 인재로 성장시키는 것이
조직 뿐만 아니라 업계의 성장에 필요
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
74. 발표만으로 이해하기는 어렵죠
경험을 통해 익히는게 가장 좋아요
저도 회사 다니면서, 일하면서 배웠어요!
<채용 진행중>
• 서버엔진팀 MV 서버 파트
• 넥슨 채용 사이트에서 ‘서버 엔진’을 검색하세요
• 신입/경력 무관. 클라에서 전직도 환영
75. 마무리
“한 아이를 키우려면 온 마을이 필요하다”
좋은 프로그래머도 그렇습니다.
서로를 위한 마을이 되어주세요.
감사합니다!
