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

홍성우, 게임 프로그래머는 어떻게 가르치나요?, NDC2018

  • 1.
    게임 프로그래머는 어떻게가르치나요? 넥슨코리아 데브캣스튜디오 홍성우
  • 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. 결과물을 확인해서 피드백 이 과정을 반복!
  • 20.
    1. 자신의 일을잘라서 나눠주고 • 실무여야 한다 • 뭘 하는 건지, 어떻게 하는 건지, 내가 충분히 알고 있는 일을 시킴 좋아 피카츄 너로 정했다! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  • 21.
    2. 방법을 자세히알려주고 • 처음에는 아주 세세하게 • 개발 도구 셋팅, 사용법 • 코드의 어디를 봐야 하는지 • 어떤 구조로 문제를 풀면 되는지 • 어떤 스타일을 참고하면 되는지 • 충분한 정보를 제공, 질문에도 잘 답변 • 테스트가 아님 쉬운 일부터 완수하도록 돕는 것 꼬리를 잡아! © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  • 22.
    3. 결과물을 확인해서피드백 • 내가 했다면 어떤 점에서 다를지 알려줌 • 직접 한 것과 비슷해지도록 수 차례 피드백 = 이걸 코드 리뷰 라고 불러요 피카츄, 한번 더 한다 © 1995-2011 Nintendo, Creatures, GAME FREAK © 2002-2011 Pokemon https://m.blog.naver.com/tjrdl552/130154678972
  • 23.
    피드백 • 피드백은 일관성있어야 하고 지시, 지적 사항의 근거도 명확히 설명해야 • 한번에 모든 규칙을 숙지할 수 없기 때문에 정리된 문서가 필요 ©예림당
  • 24.
  • 25.
  • 26.
    시간이 지날수록.. • 하다보면 점점 비슷해짐 • 작업 결과를 예상할 수 있기 때문에 신뢰의 근거가 됨 • 세부 지시가 없는 부분도 응용해서 판단 • 더 크고 어려운 일을 할당할 수 있음
  • 27.
    코드 리뷰를 통해배우는 것 1) 팀의 규칙과 정책 2) 규칙의 근거가 되는 원칙들 3) (언어의 어두운 면에 다가가지 않기 위한) 언어 사용 노하우 4) 코드 작성시의 함정 회피 5) 추상화 6) 좋은 코드를 위한 습관들 나이트런 © NAVER WEBTOON CORP.
  • 28.
    목차 1. 어떤 발표인가요? 2.왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  • 29.
    프로그래밍 업무 교육 저는이런 방법을 사용합니다 1. 자신의 일을 잘라서 나눠주고 2. 방법을 자세히 알려주고 3. 결과물을 확인해서 피드백 -> 스스로 고민하는 폭을 점점 넓혀 가기!!
  • 30.
    모든 걸 자세히알려주는 대신 • 요구 사항과 제약 사항을 알려주고 작업을 직접 설계하도록 해서 검토, 피드백 “사용자 수를 얼마로 가정했나요?” “XXXX 를 고려했나요?” “이 인터페이스는 왜 이렇게 정했나요?”
  • 31.
    결정의 근거를 확인하기 •결정의 근거를 확인하고, 타당성을 검토하고, 예상되는 문제를 찾아내고, 다른 의견을 제시해 봄 • “나라면 이렇게 했을 거예요. 왜냐하면…” = 이걸 설계 리뷰 라고 불러요
  • 32.
  • 33.
  • 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.
    교육 목표: 업무능력을 복제하자 • 나의 업무 능력을 복제하는게 목표! • 회의 들어가서 자리 비워도 업무 진행 잘됨 • 채용 할 때 편함 • 업무 의견 핑퐁 할 수 있는 사람 많아짐 • 자기들끼리 가르치면서 증식함 • 배우는 사람은 성장감 을 느끼면서 일함
  • 48.
    신입용 과제 • 책읽기? • 샘플 게임 구현?
  • 49.
    신입용 과제 • 따로하지 않음 = 업무의 프로토콜을 익히는게 더 중요!
  • 50.
  • 51.
    목차 1. 어떤 발표인가요? 2.왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  • 52.
    코드 리뷰, 설계리뷰, 아침 회의 이제 더 이상 신입이 아닌데 교육 목적이 아니어도 계속 필요할까요?
  • 53.
    업무 리뷰의 원래목적 설계와 구현 품질을 • 개인의 책임이 아닌 • 조직이 관리하는 것으로 업무 환경과 작업 결과물의 품질을 보증하기 위한 것!
  • 54.
    코드 리뷰, 설계리뷰, 아침 회의 • “혼자 일하지 말고, 팀과 같이, 동료와 같이 일하는 것” 을 의미 • 회사는 개인이 아니라 조직 전체를 통해 성과를 내야 함 -> 엔지니어링 조직이 가장 효과적으로 일하는 방식 구성원 간의 시너지를 최대한 끌어내는 조직문화 ⓒ 1997 EIICHIRO ODA.
  • 55.
    문화를 정착시키려면 • 관리자,TD : 프로세스와 문화를 리드하고, 구성원을 교육 • 구성원 : 조직 문화의 기반에서 일하고, 조직 문화를 다른 구성원에 전달하고, 조직 문화에 기여하면서 조직 내에서 입지를 만듬 • 관리자, TD 의 역할을 구성원에 분산함으로써 조직의 다음 관리자 후보들을 키움
  • 56.
    그래서 예전 발표에선 •하지만 발표는 하나
  • 57.
    목차 1. 어떤 발표인가요? 2.왜 가르쳐야 하나요? 3. 이렇게 해봅시다 • 코드 리뷰 • 설계 리뷰 • 아침 회의 4. 조직 문화 5. 나의 경험 사례 6. 적용 해보기 마무리
  • 58.
    도움이 될까? • 제경험을 소개
  • 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. 코드 리뷰를잘 받는 요령 • 동작 확인 (필수) • 구현 전 설계 리뷰 • 구체적인 리뷰 요청 • 커밋 분리
  • 67.
    3. 교육은 관심에서시작 • 관심 갖기 (= 눈치 보기?) • 유대감 쌓아 나가기 • 직장에서의 가장 긴밀한 상호작용 • 좋은 관계가 필수 ©에디터
  • 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.
    마무리 “한 아이를 키우려면온 마을이 필요하다” 좋은 프로그래머도 그렇습니다. 서로를 위한 마을이 되어주세요. 감사합니다!