개발팀 리빌딩 경험 공유 개발 규약과 소통 그리고 협업에 관한 이야기

1. © 2020 NHN FORWARD. All rights reserved.
표지
팀원 절반이 탈주한 문제의 개발팀 리빌딩한 썰
NHN 게임서버엔진팀
전만철
안녕하세요. NHN 게임서버엔진팀 전만철 입니다.
저희 팀은 현재 GameAnvil이라는 게임서버엔진을 개발하며 바쁜 나날을 보내
고 있는데요.
이런 팀이 한 때 여러가지 문제로 큰 위기에 빠진 적이 있었습니다.
오늘은 그 문제들을 어떻게 극복하면서 팀을 리빌딩 했는지, 그래서 어떤 면에
서 더 나아졌는지를 한 번 이야기해 보도록 하겠습니다.
1

2. 목차
다룰 내용
1. 개요
2. 엉망진창 until 2019 – 무엇이 문제인가?
3. Convention
4. Co-Op
5. 선순환을 위한 노력 – 더 단단해지기
6. 결론
순서는 이렇습니다.
우선 간단하게 저희 팀의 과거와 현재 상태에 대해 살펴보고 이 팀이 2019년
까지 어떤 문제를 갖고 있었는지 한 번 살펴봅니다.
그 다음, 이 문제를 극복하기 위해서 도입한 팀 내 규약에 대해 이야기를 해
보겠습니다.
그리고 이러한 규약을 기반으로 팀은 어떤 방식으로 협업 문화를 만들었는지
이야기한 후에
이 모든 것들이 선순환이 될 수 있도록 노력한 부분을 살펴보고 마무리 하도
록 하겠습니다.
2

3. 장 표지
개요
그럼, 한 번 시작해보도록 하겠습니다.
3

4. 본문 기본 – 최소 글자 크기 18pt 이상
현재 팀은 GameAnvil 클라우드 상품화를 진행 중
우선 오늘의 주제인 저희 “게임서버엔진팀”은 Java 게임 서버 엔진인
GameAnvil을 개발하는 조직입니다.
대표적으로 닌텐도 닥터마리오 월드, 디즈니 쯔무쯔무 스태디움 그리고 한게
임 포커와 섯다, 애프터 라이프 등의 게임에서 저희 GameAnvil을 사용하고 있
구요.
현재는 NHN 클라우드 플랫폼 상품화(PaaS)를 한창 진행 중입니다.
이런 개발팀이…
4

5. 본문 기본 – 최소 글자 크기 18pt 이상
2019년 찍힌(?) 팀이 되다.
팀, 찍히다
• 2019년 당시 버전의 엔진에서 많은 결함이 발견
• 그로 인해 엔진을 사용한 게임 프로젝트에서 문제 발생
• 그에 대한 미흡한 기술 지원
• 결과적으로 (팀과 엔진에 대해) 나빠진 평판
• 모호한 성과 관리와 평가
2019년에 소위 “찍힌 팀” 이 되었는데요.
그 이유로는, 우선 당시의 초기 버전 엔진이 너무나도 불안정했고, 결함이 많
았습니다. 그러다 보니 이를 사용한 일부 게임에서 문제가 발생했구요.
그런 문제에 대해 엉망으로 기술 지원을 하다 보니 팀과 엔진에 대한 평판도
매우 나빠졌습니다.
또한 업무 진행과 팀 운영에 있어 체계가 없다 보니, 각 구성원들의 성과 측정
이나 평가에 대한 객관성이 떨어졌습니다.
특히, 나중에 팀을 리빌딩하고 나서 많이 느낀 부분인데요.
당시 팀에서는 본의 아니게 제 역량을 발휘하지 못했던 구성원들도 있었습니
다.
예를 들어 100의 성과를 낼 수 있는 구성원이 한 50 밖에 역량을 발휘하지 못
했던 거죠.
5

6. 본문 기본 – 최소 글자 크기 18pt 이상
2021년 현재 팀은 성과를 지향하며, 성과로 증명하고 있습니다.
팀, 나아가다
• 현재는 엔진의 성능과 안정성 대폭 향상
• NHN 사내 게임 프로젝트는 물론이고 대외적으로 판매하기 위해 상품화 진행 중
• 빠르고 친절한 기술 지원이 최우선
• 회복한 평판
• 팀과 그 구성원 모두가 명확한 성과를 지향하며 투명하게 공유
하지만 현재는, 이처럼 2년 사이에 팀은 극명하게 달라졌습니다.
앞서 살펴본 2년 전의 문제들을 모두 극복한 것은 물론이고, 항상 최고의 성과
를 지향하는 개발팀이 되었습니다.
즉, 찍혔던 팀이 신뢰받는 팀이 되었습니다.
그럼, 지금부터 당시의 문제가 무엇이었고, 엔진팀에 어떤 일이 있었는지 한
번 살펴보도록 하겠습니다.
6

7. 장 표지
엉망진창 until 2019 - 무엇이 문제인가?
과연, 2019년까지 대체 어떤 문제들이 있었기에 당시의 엔진은 결함과 문제가
많았을까요?
무엇 때문에 팀은 위기에 빠지게 된 걸까요?
한 번 살펴보겠습니다.
7

8. 본문 기본 – 최소 글자 크기 18pt 이상
뒤죽박죽
관리가 안되는 Git 저장소
당시의 Git 개발 브랜치입니다.
지금 그림에서 브랜치의 용도가 잘 나타나지는 않는데요.
요약하자면 develop 브랜치와 master 브랜치가 관리되지 않고 각종 기능 브
랜치와 뒤섞여 있습니다.
즉, 저장소 관리 체계가 없다 보니, 개인이 개발하던 내용이 검증없이 즉흥적
으로 develop에 merge되기 일수였고, 심지어 각 개인이 개발중인 브랜치끼리
도 서로 merge가 이루어지는 요상한 형태입니다.
한 마디로 코드 형상 관리가 엉망진창입니다.
8

9. 본문 기본 – 최소 글자 크기 18pt 이상
본인만 이해 가능한 커밋
관리가 안되는 Git 저장소
그리고 이런 커밋이 있습니다.
이게 어떤 내용을 개발한 것인지 알 수 있을까요?
심지어 2개로 나뉘어져 있네요.
테스트도 안해보고 커밋해서 push까지 하고 보니, 뭔가 오동작 하니까 추가로
수정해서 또 커밋하고 push 한거죠.
그리고 이런 커밋들을 정리하지도 않고 그대로 develop 브랜치에 적용합니다.
9

10. 본문 기본 – 최소 글자 크기 18pt 이상
비직관적인 네이밍
가독성이 떨어지는 코드
class SpaceNode
class ServiceNode
class CommunicationNode
package console
package sonic
package companion
package cmd
이 클래스와 패키지들의 용도 과연 무엇일까?
(뒤에서 다시 설명)
다음으로는 공감할 수 없는 네이밍입니다.
소스 코드는 개인의 관심 분야를 어필하는 공간이 아니죠.
그럼에도 불구하고 일부 작명은 특정한 미드에서 따온 건데요. 이 미드를 모르
는 사람은 이 작명의 의미와 용도를 전혀 파악할 수 없는 문제가 생깁니다.
뒤에서 자세히 다시 한 번 더 살펴보도록 하겠습니다.
10

11. 본문 기본 – 최소 글자 크기 18pt 이상
관계가 보이지 않는 모호한 네이밍
가독성이 떨어지는 코드
class Node
class BaseNode
class NetworkNode
이 클래스들의 관계는?
이런 네이밍은 클래스 사이의 관계를 나타낼 때 특히 중요한데요.
지금 보시는 저 3개의 클래스들은 서로 어떤 관계일까요?
지금 각자 한 번씩 상상해 보시겠습니까?
11

12. 본문 기본 – 최소 글자 크기 18pt 이상
관계가 보이지 않는 모호한 네이밍
가독성이 떨어지는 코드
class Node
class BaseNode
class NetworkNode
class Node extends BaseNode
class NetworkNode extends BaseNode
코드를 처음 보는 사람은 Node 의 관계에서 큰 혼란
이 클래스들의 관계는?
▪ Node는 BaseNode 이다.
▪ NetworkNode는 BaseNode 이다.
▪ BaseNode가 항상 Node는 아니다.
▪ NetworkNode는 Node가 아니다.
이렇습니다. 이 상속 관계를 말로 풀어보면…
우선 Node는 BaseNode 입니다.
그리고 NetworkNode도 BaseNode입니다.
하지만 BaseNode는 항상 Node가 아닙니다. 이름은 Base”Node”인데, Node
가 아니예요.
그리고 Network”Node”도 Node가 아닙니다.
뭔가 이상하죠?
이게 실제로 코드를 보다 보면 끊임없이 혼란에 빠지게 되는 네이밍입니다. 끔
찍하죠.
12

13. 본문 기본 – 최소 글자 크기 18pt 이상
체계없이 비대한 패키지
가독성이 떨어지는 코드
또한 코드의 가독성을 떨어뜨리는 범인 중 하나는 바로
이러한 체계없이 비대한 패키지 구조입니다.
보시면 space라는 패키지와 그 하부 패키지 2개에 모든 클래스들을 몰아서 넣
어뒀습니다.
좀 나눌 필요가 있어 보이죠.
13

14. 본문 기본 – 최소 글자 크기 18pt 이상
불필요한 (도움이 되지 않는) 주석
가독성이 떨어지는 코드
//--------------------------------------------------------------------------------------
// constructor
private RpsConfig() {
}
//--------------------------------------------------------------------------------------
// singleton
private static RpsConfig instance;
public static RpsConfig getInstance() {…}
//--------------------------------------------------------------------------------------
// member variables
private static final Logger logger = getLogger(RpsConfig.class);
자, 이건 어떨까요?
학부생이 처음 언어나 코딩을 배울 때에는 이런 주석을 쓸 만도 합니다.
그런데, 과연 실무에서 생성자와 싱글톤 혹은 멤버 변수인걸 모르는 사람이 있
을까요?
물론, 소스 코드를 주석선으로 구획을 나눠서 멤버 변수끼리 모아두거나 하기
위한 용도일 수도 있습니다만, 이러한 주석들이 쌓이면 결과적으로 코드에 대
한 가독성을 떨어뜨리게 됩니다.
즉, 한정된 한 화면에 들어올 코드의 양은 정해져 있는데, 저 주석선과 주석들
이 그걸 차지해 버림으로써
코드를 보는 과정에서 불필요한 정보가 자꾸 눈에 들어오는 거죠.
14

15. 본문 기본 – 최소 글자 크기 18pt 이상
아래의 로그에서 16과 0이 의미하는 것은?
개발자 조차도 이해할 수 없는 로그
send to LOCATION@30120@HostName@0,com.nhnent.tardiscore.protocol.FakeName,16,0,,,,REQ_NODE
자, 이건 실제 당시 버전의 엔진에서 출력되던 로그입니다.
혹시 무슨 내용인지 이해가 가시나요?
저도 모릅니다. 개발자도 이해할 수 없는 로그를 남기는게 무슨 의미가 있을까
요?
물론 저 각 값들이 의미하는 것이 궁금하다면 개발자는 소스 코드를 뒤져서
저 로그 라인을 찾아보면 됩니다만, 그게 정말 로그의 역할이 맞을까요?
엔진 사용자는 저 로그를 어떻게 이해하면 될까요?
15

16. 본문 기본 – 최소 글자 크기 18pt 이상
아래의 로그에서 16과 0이 의미하는 것은?
개발자 조차도 이해할 수 없는 로그
send to LOCATION@30120@HostName@0,com.nhnent.tardiscore.protocol.FakeName,16,0,,,,REQ_NODE
logger.debug("{} send to {},{},{},{},{},{},{},{}", …
logger.info("create node {},{},{}", getId(), serviceId, startTime);
실제 로그 코드를 한 번 살펴보면,
바로 이처럼 무성의하게 로그를 남기고 있었습니다.
그냥, 단순히 값만 나열하고 있죠. 그 값이 무엇인지 알려주지 않아요.
굉장히 불친절한 로그입니다.
16

17. 본문 기본 – 최소 글자 크기 18pt 이상
낮은 성능과 안정성
관심 받지 못한 코드
public class TimeLoad {
private final ArrayList<TimerObject> timers = new ArrayList<>();
...
public void removeTimer(ITimerObject timerObject) {
timers.remove(timerObject);
}
}
다음으로는 코드 자체의 성능과 안정성에 관계된 부분인데요.
이 코드를 보시면, ArrayList에 대해 오브젝트 자체를 가지고 remove를 하고
있습니다.
느낌 오시죠? 최악의 코드입니다.
이런 말도 안되는 코드가 실제로 존재했습니다. 제대로 코드 리뷰를 하지 않았
기에 필터링도 되지 못했죠.
17

18. 본문 기본 – 최소 글자 크기 18pt 이상
낮은 성능과 안정성
관심 받지 못한 코드
private Queue<Packet> queue = new ConcurrentLinkedQueue<>();
while (!isShutdown) {
if (!queue.isEmpty()) {
Packet packet = queue.poll();
...
}
}
이 또한 마찬가지로 성능을 갉아먹는 코드입니다.
아마 이 코드만 보시면 잘 이해가 안되실 수 있습니다.
18

19. 본문 기본 – 최소 글자 크기 18pt 이상
낮은 성능과 안정성
관심 받지 못한 코드
private Queue<Packet> queue = new ConcurrentLinkedQueue<>();
while (!isShutdown) {
if (!queue.isEmpty()) {
Packet packet = queue.poll();
...
}
}
사실 이 성능과 안정성에 관련된 주제는 그 자체로 꽤 내용이 많고 재미있는
주제라서
제가 작년 NHN포워드에서 따로 정리하여 발표한 자료가 있습니다.
혹시라도 자세한 내용이 궁금하신 분은 이 자료를 참고하시면 좋을 것 같습니
다.
참고로 오늘의 발표 주제는 이러한 코드의 성능이나 최적화 관련해서는 다루
지 않습니다.
19

20. 본문 기본 – 최소 글자 크기 18pt 이상
서로의 업무에 별 관심 없음
N빵 업무 & 그 빵은 계속 내 빵
자, 다시 돌아와서 앞서 우리는 코드 차원에서의 문제들을 좀 살펴 보았는데요.
실제 문제의 원인은 코드나 코드 관리 뿐만 아니라 업무 프로세스 자체에도
있었습니다.
지금 보시는 바와 같이 두 명의 업무를 분장해야 하는데요.
20

21. 본문 기본 – 최소 글자 크기 18pt 이상
서로의 업무에 별 관심 없음
N빵 업무 & 그 빵은 계속 내 빵
A 기능 구현
A 기능 유지보수
A 기능 고도화
B 기능 구현
B 기능 유지보수
B 기능 고도화
이렇게 기능(feature) 단위로 나눠서 분장하는 방식이 있습니다.
소위 N빵 업무 분장이라고 할 수 있는데요. 이게 절대 나쁘다는 것은 아닙니
다.
다만, 저희 팀 입장에서는 좋은 경험보다는 좋지 않은 경험을 더 했다고 생각
이 되는데요.
이렇게 업무를 분장해서 진행할 경우에는, 당연하게도,
해당 기능에 대한 개발 뿐만 아니라 유지보수와 기술 지원까지 모두 동일인이
진행하게 됩니다.
이 말을 달리 해보면 내가 만들고 유지 보수하는 코드에만 관심을 가지면 된
다는 거죠.
둘의 업무 사이에 보이지 않는 벽이 생기는 겁니다.
21

22. 본문 기본 – 최소 글자 크기 18pt 이상
코드 리뷰도 안함
서로의 업무에 관심 없음
내 코드는 내가 알아서 네 코드는 네가 알아서
이 때, 엔진 사용자로부터 이슈가 발생하면 서로 자신이 개발한 부분만 알기
때문에 각각의 개발자들은 딱 자신들이 아는 만큼만 보이게 됩니다.
그래서 복합적인 이슈가 발생할 경우, 두 이슈에 대해 복합적으로 이해하고 해
결할 수 있는 능력이 상대적으로 떨어질 수 있습니다.
또한 서로의 업무에 접점이 없다 보니 다른 팀원의 업무에 별 관심이 없어지
구요.
그렇다 보니 앞서 살펴본 저런 Git 커밋이 가능해지는 겁니다. 왜냐하면 나만
알아보면 되니까요.
더 나아가 코드 리뷰도 안 했습니다. 서로의 코드에 별 관심이 없으니까요.
여기까지 느낌 오시죠?
22

23. 본문 기본 – 최소 글자 크기 18pt 이상
떨어진 사용자 신뢰도와 그 여파
혼돈의 카오스
불신
책임
위기
“저 팀과 엔진에 문제 많다던데?”
조직 이동
a.k.a. 유배
팀의 존재 가치를 증명하지 못하면 OUT
지금까지 살펴본 이러한 문제들이 쌓이고 쌓이다가, 어느 한 순간의 계기로
2019년에 큰 이슈가 됐었습니다.
어떤 프로젝트에서 지속적으로 복합적인 문제들이 발생했고, 팀은 이에 대해
제대로 기술 지원을 하지 못하는 사태가 벌어졌습니다.
이는 엄밀히 따지자면, 그 동안 근본적인 문제에 대한 관심 부족과 미온적인
대응이 부른 참사라고 할 수 있는데요.
결국, 팀은 이에 대해서 일부 책임을 져야할 상황에 직면했고, 그 일환으로 팀
은 조직 이동을 합니다. 저희끼리는 종종 농담반 진담반으로 유배 갔다고 표현
을 하는데요.
당연하게도 이러한 주위 분위기로 인해 당시의 팀은 상당히 위축된 분위기였
습니다. 그 말인즉슨 팀은 어떻게 해서든 존재가치를 증명하지 못하면 내일을
기약할 수 없는 최악의 상황이 된 거죠.
23

24. 본문 기본 – 최소 글자 크기 18pt 이상
설상가상
혼돈의 카오스
ㅌㅌㅌ
“우린 같이 스타트업 ㄱㄱ”
설상 가상으로 팀이 이런 상황에 처하자, 당시 팀장이었던 사람이 2명의 팀원
을 데리고 퇴사를 합니다.
엔진은 제대로 돌아가지 않아 문제 투성이에다 팀은 찍혔고 팀의 일부는 도망
갔습니다.
그야말로 한숨이 나오는 상황이죠.
이 때부터 제가 바통을 넘겨받아 팀을 리빌딩하기 시작했습니다.
24

25. 본문 기본 – 최소 글자 크기 18pt 이상
설상가상
혼돈의 카오스
그럼 지금부터 이렇게 남은 4명이 어떻게 위기를 극복하고, 지금의 안정적이
고 성과 지향적인 팀으로 거듭날 수 있었는지 한 번 이야기 해보겠습니다.
참고로 현재는 성과를 인정받아 TO를 지속적으로 늘려 가고 있고, 저 때보다
당연히 팀의 규모는 더 커졌습니다.
제가 지금부터 들려 드릴 이야기는 뭔가 엄청나게 대단한 그런 건 아닙니다.
어떻게 보면 매우 당연한 것들이 대부분임에도 불구하고 많은 조직에서 놓치
고 있는 것들일 수 있습니다.
그런 의미에서 편하게 시청자 여러분이 속한 각자의 개발 조직을 투영해가면
서 들어봐 주시면 감사하겠습니다.
25

26. 장 표지
Convention
혼돈에 빠진 개발팀에 가장 시급하게 필요한 것이 무엇이었을까요?
바로 규약입니다.
우리끼리 업무 과정에서 반드시 지켜야할 최소한의 약속이죠.
이전까지는 이러한 규약이 전혀 존재하지 않았습니다.
26

27. 본문 기본 – 최소 글자 크기 18pt 이상
▪ 현실적인 규약
▪ 도구 중심
▪ 실제 사용법 중심
▪ 명문화
▪ 접근성
▪ 웹 (두레이)
현실성, 명문화 그리고 접근성이 중요!
Convention에 정답은 없다
규약은 바로 적용할 수 있어야 의미가 있습니다.
그러기 위해서는 반드시 쉽게 접근할 수 있는 곳에 명문화 해 둬야 합니다.
또한 추상적이거나 이상적인 내용보다는 도구 중심의, 실제 사용법을 중심으
로 한, 현실적인 규약이어야 합니다.
이런 측면에서 엔진팀은 모든 개발자들의 모든 개발용 도구를 통일하고, 그 도
구들을 중심으로 규약을 만들기 시작했습니다. IDE는 물론이고 Git 클라이언
트까지 모두 같은 종류의 도구로 통일 했습니다.
그럼, 저희 팀이 어떤 현실적인 규약을 만들어서 명문화를 하고 시행했는지 한
번 살펴보겠습니다.
27

28. 본문 기본 – 최소 글자 크기 18pt 이상
▪ https://github.com/google/styleguide
▪ intellij-java-google-style.xml 를 팀에 맞게 수정 (e.g.들여쓰기 4칸)
▪ IntelliJ 매크로 이용
▪ ;(semi-colon)과 Reformat Code 단축키(Ctrl + Alt + F) 매핑
Google Style Guide (팀에 맞춰 일부 수정) + IntelliJ 매크로
Coding Convention
먼저 코딩 컨벤션입니다. 가장 기본적인거죠.
저희는 구글 스타일 가이드를 저희 팀에 맞게 살짝 수정한 버전을 사용하는데
요.
단순히 “이 규약을 따르자.”만으로는 부족한 것이, 개발자가 의식적으로 지키
지 않으면 일부 코드에서 규약에 어긋난 코드를 작성할 여지가 있습니다.
물론 후처리로 Reformat하는 솔루션들도 있습니다만, 이보다는 실제 개발 과
정에서 바로 적용되길 원했습니다.
그래서 저희는 IntelliJ의 매크로 기능을 사용해서, 세미콜론(;)을 누를 때마다
현재 작성 중인 코드를 규약에 맞춰 Reformat 하도록 단축키 설정을 합니다.
이렇게 하면 각 개발자들은 지속적으로 코드 작성 단계에서 세미콜론(;)을 입
력할 때마다 규약이 적용되는 것을 경험하면서 익숙해지는 거죠.
즉, 본인의 코드가 규약에 맞춰 Reformat 되는 과정을 직접 보는 것이 가장 좋
은 방법인 거죠.
28

29. 본문 기본 – 최소 글자 크기 18pt 이상
Git 도구 통일, 가능한 모든 상황에 대한 규약 작성
Git Convention
다음은 Git 규약입니다.
Git은 앞서 살펴보았듯이 명확한 규약이 없을 경우에는 저장소가 엉망진창이
될 수 있습니다.
그래서 저희는 세부적인 규약까지도 모두 명문화를 해 두었는데요.
그 중 중요한 몇 가지를 한 번 살펴보겠습니다.
참고로 지금 그림에서 보시는 것은 커밋 메시지를 작성하는 규칙입니다.
29

30. 본문 기본 – 최소 글자 크기 18pt 이상
GitFlow / 단위 기능 당 1 커밋 / Rebase
Git Convention
우선 저희는 GitFlow 기반으로 브랜치 관리를 하구요.
이 그림은 develop 브랜치를 보여주는데요.
보시는 바와 같이 develop 브랜치에 기능(feature)마다 단 하나의 커밋으로 합
쳐서 Rebase를 합니다.
즉, 이 그림에서 보이는 각각의 커밋은 모두 각각의 기능 혹은 수정(fix)을 독립
적으로 작업한 것입니다.
물론 개발 과정에서는 feature 브랜치에 자유롭게 커밋해가며 개발하구요. 최
종 Rebase 단계에서만 하나의 커밋으로 합치는(squash) 겁니다.
그리고 Rebase 기반으로 develop 브랜치를 관리하기 때문에 보시는 바와 같
이 하나의 직선 형태로 모든 기능 히스토리가 관리되고 있습니다.
30

31. 본문 기본 – 최소 글자 크기 18pt 이상
규칙적으로 잘 작성된 Commit 설명
Git Convention
자, 이런 커밋들 중 하나를 열어봤을 때, 보이는 설명입니다.
어떠세요? 규약에서 정해 둔 규칙에 맞춰 작성한 제목과 내용입니다.
협업을 하는 동료라면 이 정도 내용으로 충분히 해당 커밋이 어떤 작업을 반
영한 것인지 알 수 있겠죠?
설사, 코드를 다 살펴보지 않더라도 말이죠.
코드를 살펴본다면 이 설명이 코드를 이해하는데 도움이 되겠죠.
31

32. 본문 기본 – 최소 글자 크기 18pt 이상
Before vs After
Git Convention
Before After
자, 이제 앞서 살펴보았던 2019년의 Git 상태와 현재의 상태를 한 번 비교해
보겠습니다.
왼쪽은 이전 상태이고, 오른쪽은 현재 상태입니다.
규칙적인 커밋의 제목부터 브랜치 관리까지 확연히 달라진게 보이시죠?
32

33. 본문 기본 – 최소 글자 크기 18pt 이상
Before vs After
Git Convention
Before After
커밋의 제목과 내용입니다.
완전히 달라졌습니다.
33

34. 본문 기본 – 최소 글자 크기 18pt 이상
코드 리뷰
Git Convention
도구 중심으로 코드 리뷰 방법을 명문화
그와 더불어 저희는 Git 규약에 코드 리뷰 프로세스도 포함되어 있는데요.
이 화면은 실제 규약의 내용 중 일부를 캡쳐 한 것입니다.
저희는 IntelliJ를 사용하기 때문에, 도구 중심 즉, IntelliJ 기반으로 코드 리뷰하
는 방법까지 모두 정리해 두었습니다.
팀원들은 모두 이대로 따라하기만 하면 되는 거죠.
34

35. 본문 기본 – 최소 글자 크기 18pt 이상
Git Convention
코드 리뷰
그 자체로 성과: 반기마다 동료들이 평
가
이러한 코드 리뷰는 남는 시간에 하는 자투리 업무가 되어서는 안됩니다.
해당 캡쳐는 저희 팀의 “성과 공유 툴＂의 일부인데요. 자세한 건 뒤에서 따로
한 번 이야기를 하겠습니다만, 여기서 하고 싶은 말은 코드 리뷰 자체만으로도
중요한 성과로 인정해야 한다는 것입니다.
그렇지 않으면 리뷰어(reviewer)도 리뷰이(reviewee)도 전혀 동기부여가 되지
않습니다. 엄연한 업무의 일부이고 리뷰를 한 시간은 당연히 업무 시간으로 인
정되어야 하죠.
그래서 저희는 이런 부분까지 모두 잘 보장하기 위해서 끊임없이 팀 규약이나
시스템을 지속적으로 신경 쓰고 있습니다.
35

36. 본문 기본 – 최소 글자 크기 18pt 이상
Logback 통일, 로그 작성법 통일
Logging Convention
이번에는 좀 특이하게도 로깅 규약입니다.
사실 대부분의 개발자들이 로그 문구나 문장 포맷 등을 임의로 작성하는 경우
가 많습니다.
하지만 앞서 살펴보았듯이 명확한 규약이 없으면, 불친절한 혹은 무의미한 로
그를 남기게 될 수도 있습니다.
우선, 좋은 로그를 잘 작성하기 위해서는 모든 구성원이 동일한 형태의 로그를
보아야 합니다.
그렇기 때문에 당연하게도 Logback을 통일하고 난 다음 로그 작성 규칙을 적
용해야 됩니다.
저희 로깅 규약에는 화면과 같이 미리 작성해둔 logback 파일이 첨부되어 있
구요. 모든 구성원은 이것을 다운로드 받아서 사용합니다.
36

37. 본문 기본 – 최소 글자 크기 18pt 이상
Live Template
&
명확한 예외 TAG
Logging Convention
그리고 IntelliJ의 라이브 템플릿 기능을 사용해서 기본적인 로깅 구문을 자동
생성할 있도록 만들어 두었습니다.
예를 들어, 저희 같은 경우는 화면처럼 설정해 두는데요.
에디터에 “logee”를 입력하면 “Log for Exception Error”에 대한 기본 구문이
자동 입력되는 거죠.
37

38. 본문 기본 – 최소 글자 크기 18pt 이상
모든 구성원이 동일한 형태의 예외 로그를 작성
Logging Convention
. . .
} catch (Exception e) {
logger.error("_MatchRoomReqRelay::execute() : 예외 원인을 알 수 있는 메시지 : ", e);
try {
...
} catch (Exception ex) {
logger.error("_MatchRoomReqRelay::execute() : failed to reply, exeption=", ex);
}
예를 들어 이런 겁니다.
모든 구성원은 앞서 살펴본 라이브 템플릿을 적용했을 경우, logee를 입력하
면 저 노란색 구문이 자동으로 입력되는 겁니다.
저희 팀의 경우는 보시는 바와 같이 반드시 예외가 발생한 지점의 클래스와
메소드 명을 명시한 후 예외 콜 스택을 출력하고 있습니다.
그와 더불어서 해당 예외의 원인을 알 수 있는 메시지를 반드시 입력합니다.
저 오렌지색 로그처럼 말이죠.
그래서 팀의 누가 됐든, 모두 동일한 형태의 로그를 남기게 되는 거죠.
38

39. 본문 기본 – 최소 글자 크기 18pt 이상
값은 반드시 의미와 함께 출력한다
Logging Convention
logger.debug("{} send to {},{},{},{},{},{},{},{}", …
logger.warn("A user({}) doesn't respond. It's set to disconnected. (IsDisconnected:{},
LastCommand:{}, canLogout:{})", …
Before
After
그리고 앞서 살펴봤던 문제의 로그 기억하시죠?
저렇게 값만 나열하던 로그를 모두 아래의 그림처럼 각 값이 의미하는 바를
각 값 앞에 반드시 명시하도록 했습니다.
이제 개발자 뿐만 아니라, 엔진 사용자도 저런 경고 로그가 떴을 때, 그 의미를
직관적으로 이해할 수 있게 되는 거죠.
39

40. 본문 기본 – 최소 글자 크기 18pt 이상
JavaDoc 적극 도입
Comment Convention
/**
* {@link CompletionStage}에 대한 .get()을 스레드 블러킹 대신 파이버 블러킹으로 전환해준다.
* <p>
* 그러므로 해당 future 에 대한 .get()은 반드시 이 메서드를 통해 처리해야 한다.
* <p>
* 이 때, 해당 블러킹 호출이 완료될 때까지 GameAnvilConfig 에 설정한 DefaultAsyncAwaitTimeout 만큼 대기한다.
*
* @param completableFuture 대기할 future 전달.
* @param timeout get() 호출에 대한 결과를 얼마동안 대기할지 timeout 값을 전달.
* @param unit timeout 매개변수의 시간 단위 전달.
* @param <V> CompletionStage 구현한 형태로 전달.
* @return 해당 future 의 결과 값 반환.
* @throws SuspendExecution 이 메서드는 파이버가 suspend 될 수 있다.
* @throws TimeoutException 해당 블러킹 호출에 대해 timeout 이 발생.
*/
@Suspendable
public static <V> V awaitFuture(final CompletionStage<V> completableFuture, final int timeout, final TimeUnit
unit) throws SuspendExecution, TimeoutException;
자, 이번에는 주석 규약입니다.
저희는 이처럼 엔진 API에 모두 JavaDoc 기반의 주석을 작성합니다.
이런 부분은 어찌 보면 너무나도 당연한 것인데, 그 동안 못 한 거였죠.
40

41. 본문 기본 – 최소 글자 크기 18pt 이상
불필요한 주석은 지양. 특히, 불필요한 코드의 주석 지양
Comment Convention
그리고 이처럼 불필요한 주석은 지양합니다.
여기에는 앞 서 살펴봤던 줄긋기 주석이나 무의미한 주석을 모두 포함합니다.
이미 Git을 통해 코드 형상 관리를 하고 있음에도 불구하고, “언젠간 이 코드를
다시 사용할 수도 있어”라는 막연한 가능성 때문에 이처럼 코드 블록 일부를
주석처리 해 둔 경험은 한 두 번씩 있으실 것 같은데요.
이는 코드 가독성을 많이 떨어뜨립니다.
특히, 전체 코드에서 무언가를 검색했을 때, 쓸데없이 노출되기 때문에 생산성
도 함께 떨어뜨릴 수 있습니다.
41

42. 본문 기본 – 최소 글자 크기 18pt 이상
JavaDoc with UML API 레퍼런스 사이트 오픈
Comment Convention
https://gameplatform.toast.com/docs/api/
앞서 살펴봤던 JavaDoc은 단순히 주석으로 끝내는 것이 아니라,
이처럼 저희는 JavaDoc 사이트를 추출해서 별도의 URL 상에서 운영하고 있는
데요.
JavaDoc 사이트를 추출할 때, 각 클래스들의 UML 다이어그램도 함께 포함하
고 있습니다.
엔진 사용자가 참고할 수 있는 최대한의 정보를 제공하고 싶어서죠.
여기까지가 주석 규약이구요.
42

43. 본문 기본 – 최소 글자 크기 18pt 이상
패키지 구조를
체계적이고 직관적으로
RE 패키지
Before
After
규약이라고 하기에는 다소 애매하지만, 클래스 구조와 네이밍을 정리하기 위
해서 선행되어야 할 것은 패키지 구조를 정리하는 것이었습니다.
그림에서 보시는 바와 같이 하나의 패키지 안에 비대하게 많은 클래스들을 배
치하면 그 구조나 용도가 명확하게 파악되지 않습니다.
그래서 저희는 가능한 최소한의 계층 구조를 적용하여, 각 클래스들을 용도에
맞게끔 재배치 하였습니다.
또한 당연하게도 모든 패키지명은 그 용도가 명확하게 드러날 수 있는 이름을
사용합니다.
그림에서 빨간색 사각형을 친 저 두 부분이 동일한 패키지의 변경 전/후라고
보시면 됩니다. 우측의 경우 하위 패키지로 구조화해서 더욱 깔끔한 형태가 되
었죠.
43

44. 본문 기본 – 최소 글자 크기 18pt 이상
Naming Convention
class SpaceNode
class ServiceNode
class CommunicationNode
package console
package sonic
package companion
package cmd
용도와 목적이 보이는 직관적 네이밍 (Before)
Before
자, 이번에는 네이밍 규약입니다.
아마 많은 분들이 네이밍 때문에 고민해본 경험이 있으실 겁니다.
코드를 작성하는 과정에서 가장 어려운 부분 중 하나가 네이밍이 아닐까 싶은
데요.
사실 이건 “특정한 이름만 사용해＂와 같은 형태의 명확한 규약이 될 수는 없
습니다.
단, 명확한 방식으로 네이밍을 하도록 약속은 할 수 있는데요.
지금 보시는 이 문제의 네이밍은 앞서 한번 보여드렸죠?
저 각 클래스와 패키지들이 어떤 용도로 보이세요? 참고로 우주, 공간, 콘솔,
소닉, 컴패니언 이런 단어들은 특정 미드(미국 드라마)에서 차용한 단어입니다.
44

45. 본문 기본 – 최소 글자 크기 18pt 이상
Naming Convention
class GameNode
class SupportNode
class IpcNode
package gameanvil
package assit
package extend
package handler
class SpaceNode
class ServiceNode
class CommunicationNode
package console
package sonic
package companion
package cmd
용도와 목적이 보이는 직관적 네이밍 (Before vs After)
Before After
이렇습니다.
우주 혹은 공간 노드는 GameNode이구요.
Service와 Communication은 너무 막연한 단어이기 때문에 좀 더 구체적인 지
원(Support)형 노드와 Ipc(Inter-Process Communication) 노드로 이름을 변경
했습니다.
그리고 console은 gameanvil에서 제공하는 API 그 자체이구요. 그런 의미에서
우주선의 콘솔을 사용했나 봅니다.
sonic은 보조적인 역할을 해주는 API들의 묶음이므로 assist로 변경했습니다.
companion은 확장 기능의 묶음이므로 extend로 변경했고 마지막으로 cmd는
handler라는 직관적인 이름으로 변경했습니다.
여기에서 보여드린 클래스와 패키지는 극히 일부인데요. 사실 이 모든 네이밍
을 리팩토링 하는데 정말 많은 사람들의 에너지와 시간이 투입되었습니다.
45

46. 개발 초기부터 제대로 된 규칙을 가지고 네이밍을 하는 것이 얼마나 중요한지
꼭 말씀드리고 싶습니다.
45

47. 본문 기본 – 최소 글자 크기 18pt 이상
(Remind) 관계가 보이지 않는 모호한 네이밍
Naming Convention
class Node
class BaseNode
class NetworkNode
이들의 관계는?
class Node extends BaseNode
class NetworkNode extends BaseNode
코드를 처음 보는 사람은 Node 의 관계에서 큰 혼란
Node 와 NetworkNode가 Sibling ?
Before 이 클래스들의 관계는?
▪ Node는 BaseNode 이다.
▪ NetworkNode는 BaseNode 이다.
▪ BaseNode가 항상 Node는 아니다.
▪ NetworkNode는 Node가 아니다.
그리고 아까 앞에서 보여드렸던 이 클래스들의 관계 기억하시죠?
NetworkNode는 Node가 아니라니… 혼란스럽습니다.
46

48. 본문 기본 – 최소 글자 크기 18pt 이상
관계가 보이도록 네이밍
Naming Convention
class Node
class NonNetworkNode
class NetworkNode
이들의 관계는?
class NonNetworkNode extends Node
class NetworkNode extends Node
기본 클래스는 BaseNode → Node 로 이름 변경
NonNetworkNode와 NetworkNode의 관계 그리고
NetworkNode와 Node의 관계가 보인다.
class Node
class BaseNode
class NetworkNode
이들의 관계는?
class Node extends BaseNode
class NetworkNode extends BaseNode
코드를 처음 보는 사람은 Node 의 관계에서 큰 혼란
Node 와 NetworkNode가 Sibling ?
Before After
그래서 이렇게 변경했습니다. 저 노란색 화살선처럼 클래스 2개의 이름을 바
꿨는데요.
이제, NonNetworkNode는 Node입니다.
그리고 NetworkNode는 Node입니다.
하지만 NetworkNode는 NonNetworkNode가 아닙니다.
어떠세요? 직관적인게 느껴지십니까?
47

49. 본문 기본 – 최소 글자 크기 18pt 이상
관계가 보이도록 네이밍
Naming Convention
class Node
class NonNetworkNode
class NetworkNode
이들의 관계는?
class NonNetworkNode extends Node
class NetworkNode extends Node
기본 클래스는 BaseNode → Node 로 이름 변경
NonNetworkNode와 NetworkNode의 관계 그리고
NetworkNode와 Node의 관계가 보인다.
After
이 클래스들의 관계는?
▪ NonNetworkNode는 Node 이다.
▪ NetworkNode는 Node 이다.
▪ NetworkNode는 NonNetworkNode가 아니
다.
이처럼 클래스의 상속이나 포함 구조는 특히나 네이밍이 중요합니다.
잘못된 클래스 네이밍은 코드 가독성을 떨어뜨리고, 지속적으로 혼란스럽게
만들 수 있으므로 정말 신중하게 결정해야 합니다.
48

50. 본문 기본 – 최소 글자 크기 18pt 이상
엔진팀에서 관리하는 Convention 목록
Convention
지금까지 저희 엔진팀에서 관리하는 규약 몇 가지를 살펴보았는데요.
앞서 살펴본 규약들 외에도 업무 진행 과정에서 필요성이 대두되는 경우에는
바로 새로운 규약을 만들고 팀에 적용합니다.
그 중 하나가 “GameAnvil 문서화 단어 규약” 인데요.
엔진 사용자를 위해 가이드 문서를 작성하다 보니 각자 단어 선택이 다르다는
것을 발견했어요.
예를 들어, GameRoom에 대한 글에서 누군가는 “룸＂이라고 쓰고 또 다른 누
군가는 ＂방”이라고 쓰는 겁니다.
이처럼 문서화를 위해서는 필수적인 단어들에 대한 규약이 필요함을 느꼈고,
문서의 양이 더 늘어나기 전에 바로 해당 규약을 만든 것이죠.
이처럼 규약은 팀이 같은 방향을 바라보도록 하기 위한 가장 필수 요소입니다.
만일, 지금 이 영상을 보고 계시는 분들 중 팀에 규약이 없다면 지금 바로 만
49

51. 드실 것을 조언 드리고 싶습니다.
49

52. 장 표지
Co-Op
자, 이렇게 규약을 명문화하여 기반을 다졌으니, 이번에는 팀의 협업에 관해
이야기 해보겠습니다.
여러분들은 각자 팀에서 어떤 방식으로 협업을 하시나요?
여러 분의 팀은 소통 비용이 비싼 편인가요? 아니면 언제 어디서나 쉽게 소통
할 수 있는 구조인가요?
그럼, 지금부터 저희 팀의 가장 큰 장점 중 하나인 협업 문화를 한 번 살펴보
겠습니다.
50

53. 본문 기본 – 최소 글자 크기 18pt 이상
소통 비용과 소통의 허들
소통
이거 설명 좀
너무나도 당연한 이야기지만, 팀은 언제 어디서든 수단과 방법을 가리지 않고
소통할 수 있어야 합니다.
이것이 팀웍의 가장 기본이고 시너지를 만들기 위한 필수 요소라고 생각합니
다.
하지만 의외로, 그렇지 못한 조직이 매우 많다는 걸 경험 상 알고 있습니다.
그 동안 주위에서 소통의 중요성을 망각하고 있거나, 혹은 잘못된 방식으로 소
통하는 경우를 제법 많이 보았습니다.
51

54. 본문 기본 – 최소 글자 크기 18pt 이상
“그걸 왜 나한테 물어요?”
“코드 안보셨어요?”
“저도 모르겠는데요. OO한테 물어보세요.”
“그것도 몰라요?”
“제가 지금 바빠서 시간이 없네요.”
소통 비용과 소통의 허들: 높음
소통
이거 설명 좀
예를 들어 이런 건 데요.
혹시 여러분들이 속한 팀에서 누군가 이렇게 말하고 있지는 않습니까?
이런 소통은 최악이라고 생각합니다. 결국 물어봤던 사람은 위축되어서 다음
부터 질문 자체를 피하게 될 것이고, 누군가 자신에게 질문할 때 똑같이 대답
할 가능성이 높아집니다.
악순환이죠.
그래서 처음부터 팀의 문화를 잘 만들고 자리잡는 것이 가장 중요합니다.
당연히 팀의 리더가 이런 것들을 세심하게 챙기고 잘 전파될 수 있도록 해야
겠죠.
52

55. 본문 기본 – 최소 글자 크기 18pt 이상
소통 비용과 소통의 허들: 낮음
소통
▪ 팀 구성원은 일 처리를 함에 있어 외롭지 않아야 한다.
이거 설명 좀
설명을 들을 권리
이해시켜야 할 의무
그럼, 이제 저희 팀 이야기를 좀 해보겠습니다. 저희 팀의 모토는 누군가에게
어떤 업무가 주어졌을 때, “해결하는 과정이 외롭지 않아야 한다.” 입니다.
이를 위한 가장 기본은 “물어볼 권리＂와 “답 해야할 의무＂의 관계인데요.
즉, 궁금한게 있는 사람은 언제든 쉽게 물어볼 수 있는 권리를 누리는 것 이구
요. 질문을 받은 사람은 반드시 답 해 줘야할 의무를 가지는 겁니다.
특히, 새로 합류한 팀원의 경우에는 코드를 분석하는 과정에서 혹은 이슈를 해
결하는 과정에서 “잘 모르는“ 경우를 자주 만나게 되는데요. 저희는 이럴 때
무조건 가장 만만한 팀 구성원을 붙잡고 물으라고 합니다. 설명을 들어도 잘
모르겠으면 이해될 때까지 묻습니다. 이건 그가 팀 내에서 누리는 가장 기본적
인 권리입니다.
그 대답을 해야 할 의무를 가진 팀원도 이미 누군가에게 질문할 권리를 누렸
던 혹은 누리고 있는 사람이기에 이 의무에 충실합니다.
53

56. 본문 기본 – 최소 글자 크기 18pt 이상
화이트보드
소통 비용과 소통의 허들: 낮음
소통
▪ 팀 구성원은 일 처리를 함에 있어 외롭지 않아야 한다.
이거 설명 좀
아 그거…
OO님 잠시만 같이
얘기 좀 해요
만일 질문을 받은 사람이 이해시키는데 어려움이 있을 경우에는 다른 팀원에
게로 전파가 되기도 합니다.
이런 소통 방식은 처음 팀을 리빌딩 할 때부터 만들어온 저희 팀의 가장 소중
한 문화이고, 매우 강력한 암묵적 규칙입니다.
저희 팀은 그 누구도 이런 소통에 대해 귀찮아 하거나 소극적으로 대처하지
않습니다.
특히, 저희는 서로 아이디어를 교환하거나 설명을 할 때, 개방된 공간에 비치
된 화이트 보드를 적극적으로 활용하는데요.
54

57. 본문 기본 – 최소 글자 크기 18pt 이상
화이트보드
소통 비용과 허들을 낮췄더니
소통
▪ 집단지성으로 문제 해결을 하기 시작
이런 문화가 잘 자리 잡으면,
밥 먹고 산책을 하다 가도 자연스럽게 아이디어 얘기를 하게 됩니다.
“아! 그 아이디어 좋네요. 까먹지 않도록 들어가자 마자 두레이에 업무 등록 합시다.＂
이런 문화는 결과적으로 이런 광경을 만들어 냈습니다.
처음에는 두 명이 대화를 하다가, 어느 샌 가 주위에서 듣고 있던 팀원들이 하
나,둘 모여서 4명, 6명이 같이 화이트 보드 앞에 서서 소통의 장이 열리는 거죠.
이런 것들이 결국 “집단지성”을 매우 중요시하는 팀 문화가 자리잡는 바탕이
되었는데요. 늘 문제 해결을 함에 있어 한 사람의 생각보다는 팀 전체의 생각
을 맞추고 조율하는 과정을 거치는 겁니다.
주제가 정해져 있을 때도 있지만, 기술 지원 이슈나 코드 상의 의문점 등에 대
해 즉흥적으로 이야기가 시작되기도 합니다.
물론 이런 부분들이 업무 시간의 일부를 소비해야하기 때문에 본인의 업무 처
리에는 추가 시간이 필요한 경우도 종종 생기긴 합니다만, 팀은 이런 소통의
중요성과 효용성을 매우 잘 알기 때문에 이런 소통 자체에 큰 의미를 부여하
는 편입니다.
뒤에서 설명하겠지만 이를 위해서 업무 분장도 신경을 써야 합니다.
55

58. 본문 기본 – 최소 글자 크기 18pt 이상
화상 회의
소통 비용과 허들 낮추기
소통
▪ 팀 구성원은 일 처리를 함에 있어 외롭지 않아야 한다.
▪ 집단지성으로 문제를 해결한다.
화상 회의
화상 회의
화상 회의
이런 팀의 색깔은 특히 재택 근무 시기에 빛을 발했습니다.
이미 소통 비용과 허들이 매우 낮아져 있기 때문에 소통 방식이 바뀐다고 달
라질 게 하나도 없는 거죠.
즉, 대면 소통 뿐만 아니라 메신져와 두레이를 화이트보드 삼아 매우 적극적인
소통을 이어 갔는데요.
재미있게도 저희 팀의 주요 성과들 대부분이 재택 근무 기간에 만들어졌다는
것입니다.
출퇴근 시간이 줄어든 만큼 더욱 집중적으로 그리고 연속적으로 소통하며 업
무를 처리할 수 있었기 때문이죠.
56

59. 본문 기본 – 최소 글자 크기 18pt 이상
소통 비용과 허들 낮추기
소통
참고로 저희는 화상 회의도 모두 얼굴을 보면서 하는 편인데요. 딱히, 강요를
한 것이 아님에도 모두 카메라를 켜서 서로 얼굴 보면서 이야기 하는 것을 좋
아합니다.
그리고 메신저 상에서 글로 설명하기 복잡하거나 내용이 많을 경우에는 적극
적으로 전화 통화를 합니다.
각 상황마다 더 쉽고 편한 소통 방식을 선택해서 소통 효율을 높이는 거죠.
저희 팀 채널에서 “통화＂나 “전화＂로 검색해보면 저런 내용이 엄청 많습니
다.
팀웍에 있어서 소통의 중요성은 100번을 말해도 부족하겠지만, 의외로 그 비
용과 허들이 높은 조직들이 있습니다. 저희는 이렇게 확 낮춘 소통 비용을 기
반으로 시너지를 만들기 위해 노력을 했는데요.
57

60. 본문 기본 – 최소 글자 크기 18pt 이상
시너지
업무 분장 방식
A의 업무
C의 업무
B의 업무
여기 A,B,C 세명의 팀원들이 있습니다. 어떻게 하면 구성원들 사이에 시너지를
만들 수 있을까요?
만일 A의 업무와 B의 업무가 독립적으로 칼같이 분리된다면 시너지가 발생 할
까요?
우리는 조금 돌아서 가더라도 시너지를 낼 수 있는 방법을 지향합니다.
또한 앞서 말씀드렸듯이, 팀은 누군가에게 어떤 업무가 주어졌을 때, 해결하는
과정이 외롭지 않게 하려고 매우 많이 신경을 쓰고 있습니다.
58

61. 본문 기본 – 최소 글자 크기 18pt 이상
시너지
업무 분장 방식
A의 업무
C의 업무
B의 업무
Q1. 매치메이킹을 개발한 A가 있습니다. 만일,
이 매치메이킹에 새로운 스펙을 추가해야 한다면
누가 개발하는게 좋을까?
이런 경우가 있습니다.
A가 기존에 개발한 기능이 하나 있습니다. 여기서는 매치메이킹이라고 할께요.
그런데 이 기능에 새로운 스펙을 추가해야 합니다. 이 때, 누가 개발하면 좋을
까요?
물론, 정답은 없습니다.
59

62. 본문 기본 – 최소 글자 크기 18pt 이상
시너지
업무 분장 방식
A의 업무
C의 업무
B의 업무
매치메이킹
Q1. 매치메이킹을 개발한 A가 있습니다. 만일,
이 매치메이킹에 새로운 스펙을 추가해야 한다면
누가 개발하는게 좋을까?
하지만 저희 팀이라면 A가 아닌 B 혹은 C가 진행합니다.
이 때, 당연히 질문할 권리와 대답할 의무를 기반으로 A의 서포트를 받습니다.
앞서 설명 드렸듯이 저희는 A,B,C 사이의 소통 비용이 매우 낮아져 있기 때문
에 한결 수월합니다.
물론 전체적인 업무 속도를 따진다면 A가 바로 진행할 경우 더 짧은 기간 내
에 빠르게 완료할 수 있을 거예요.
하지만, 이런 방식에는 폐단이 있습니다. B와 C는 앞으로도 계속 매치메이킹
에 관해 잘 알지 못할 것이고 더 나아가 관심 조차 갖지 않을 것이라는 거죠.
사실 이게 예전의 팀 업무 분장 방식이었습니다. 이 경우, 사이드 잡을 하기 시
작한 구성원은 지속적으로 사이드 잡만 맡게 되는 구조이다 보니 동기부여도
되지 않죠.
장기적인 관점에서 모든 구성원이 프로젝트 전체적인 코드를 파악하고 제어
할 수 있는 능력을 기르기 위해서는 이러한 겹치는 업무 분장 방식이 충분히
60

63. 의미를 가질 수 있습니다.
만일 팀에서 내 일과 네 일을 구분했다면 현재의 성과가 나올 수 없었다고 생
각합니다.
60

64. 본문 기본 – 최소 글자 크기 18pt 이상
시너지
업무 분장 방식
Q2. 매치메이킹의 새로운 스펙을 개발하기 위해서는 필
연적으로 유저 전송 기능에도 새로운 스펙이 추가되어야
합니다. 이 때 유저 전송은 누가 개발하는게 좋을까?
A의 업무
C의 업무
B의 업무
매치메이킹
자, 이런 경우도 있습니다.
앞서 말한 매치메이킹 기능을 개발하려고 보니, 제3의 다른 기능에도 새로운
스펙이 추가되어야 하는 상황입니다.
이 때, 누가 개발하면 좋을까요?
어차피 매치메이킹을 개발해야 하니, B가 함께 처리 하는게 좋을까요?
이 또한 정답이 없습니다.
61

65. 본문 기본 – 최소 글자 크기 18pt 이상
시너지
업무 분장 방식
A의 업무
C의 업무
B의 업무
매치메이킹
유저 전송
Q2. 매치메이킹의 새로운 스펙을 개발하기 위해서는 필
연적으로 유저 전송 기능에도 새로운 스펙이 추가되어야
합니다. 이 때 유저 전송은 누가 개발하는게 좋을까?
매치메이킹
매치메이킹
하지만, 저희 팀의 경우는 만일 매치메이킹을 B가 개발하기로 했다면 이 경우
유저 전송은 C가 함께 개발합니다.
이렇게 되면 B는 새로운 매치메이킹 스펙을 개발하면서 지속적으로 C와 소통
해야 합니다. 그 과정에서 C의 업무 교집합을 추가로 살펴보게 되죠.
A 또한 자연스럽게 C의 업무 내용에 대해 관심을 가지게 됩니다.
이게 저희 업무 분장의 기본 방침입니다. 즉, 가능한 교집합을 만들고 그 사이
에서 구성원들이 가능한 많은 소통을 하고 정보 교환을 하길 바라는 거죠.
결과적으로는 이 부분이 꽤 성공적이라고 자평하고 있습니다.
62

66. 본문 기본 – 최소 글자 크기 18pt 이상
즉시성을 가진 업무는?
업무 분장 방식
▪ 예를 들어 서비스 중인 게임에서 “급한 기술 지원” 이슈 발생
“갑자기 매칭메이킹이 잘 안됩니다＂
앞서 살펴본 것처럼 명확하게 분장한 업무 외에도 “긴급하게 발생하는 기술
지원” 같은 즉시성을 띄는 업무도 있습니다.
예를 들어, 하던 업무를 일시 중단하고, 긴급한 기술 지원을 해야 하는 경우 등
이죠.
A,B,C 모두 지금 바쁘게 본인의 개발 업무를 진행하고 있어요.
그 때, 엔진 사용 조직으로부터 매치메이킹이 잘 안된다는 기술 문의가 왔습니
다.
누가 지원하면 좋을까요?
63

67. 본문 기본 – 최소 글자 크기 18pt 이상
즉시성을 가진 업무는?
업무 분장 방식
A가 담당
B가 담당
C가 담당
▪ 예를 들어 서비스 중인 게임에서 “급한 기술 지원” 이슈 발생
이런 방식은 어떨까요?
일반적으로 가장 쉽게 선택할 수 있는 방법이죠. 각자 담당 조직을 미리 나눠
두는 겁니다.
실제 예전의 팀은 이런 방식으로 기술 지원을 했습니다.
그런데, 앞서 살펴봤던 업무 분장과 마찬가지로 이렇게 나눠 두면 A, B, C는
서로 자신이 맡은 지원 조직 외에는 관심조차 두지 않더라는 거죠.
B가 맡은 개발 조직에서 긴급 이슈가 터져서 해결이 잘 안되고 있을지라도, A
와 C는 별 관심이 없어요.
64

68. 본문 기본 – 최소 글자 크기 18pt 이상
즉시성을 가진 업무는 최우선으로 “할 수 있는 사람”이 한다
업무 분장 방식
▪ 개개인이 최대한의 역량을 발휘하고 그것을 객관적으로 평가
우리 담당
우리 담당
우리 담당
그래서 저희는 기술 지원을 팀에서 “할 수 있는 사람”이 합니다.
뭔가 살짝 모호하게 들릴 수 있는데요. 좀 더 설명을 드리자면…
팀을 처음 리빌딩 할 때, 기존에 나눴던 담당 조직을 다 없애 버렸고, 기술 지
원의 우선 순위를 업무 중 최우선으로 올렸습니다. 즉, 누군가 그 순간에 지원
을 할 수 있다면 반드시 최우선으로 하자는 거죠.
앞서 봤던 담당 조직을 정했던 시기에 기술 지원이 미흡한 것들이 많이 누적
되어 있었고, 팀의 평판 또한 나빠져 있었기 때문에 이게 최선이었습니다.
엔진 수정, 리팩토링 등등 급한 개발 업무 또한 매우 많았지만, 엔진을 사용하
는 고객에 대한 기술 지원보다 급하지 않다고 선을 그은 거죠.
다만, 한 가지 정말 중요한 것은 이런 기술 지원에 대한 성과가 모두 객관적이
고 투명하게 관리되어야 한다는 겁니다. 이 부분은 바로 뒤에서 한 번 살펴보
도록 하겠습니다.
65

69. 본문 기본 – 최소 글자 크기 18pt 이상
객관적이고 공정한 평가
성과 관리
이제 협업에 관한 마지막 주제인데요. 바로 성과 관리입니다.
저희 NHN은 반기마다 Open-Review라는 다면 평가를 통해 모든 구성원들이 서로 평
가를 진행합니다.
이런 다면 평가를 해보면
“팀의 모든 구성원들이 과연 같은 기준을 가지고 같은 맥락에서 서로를 평가하고 있을
까?”
혹은 “팀장은 과연 모든 팀원들에 대해 같은 잣대로 객관적으로 평가하고 있을까?” 라는
생각을 한 번 쯤은 해보게 됩니다.
66

70. 본문 기본 – 최소 글자 크기 18pt 이상
객관적이고 공정한 평가
성과 관리
“언택트 시대에 피드백 하기” 교육
저도 마찬가지로 이런 평가가 항상 어렵게 느껴졌습니다.
‘과연 우리 팀은 객관적이고 투명하게 성과를 평가하고 있는가?’라는 막연한 생각을 가
지고 있었구요.
저 또한 사람이다 보니, “인간적으로 더 끌리는 누군가에게 더 좋은 평가를 주고 있지는
않나?”라는 자문을 하기도 했습니다.
그러던 차에, 작년 이 맘 때 쯤인데요. 회사에서 외부 강사님들을 초빙하여 “언택트 시대
에 피드백 하기＂라는 교육을 진행해 주셨습니다.
이게 내용이 정말 알차서, 교육의 일부 내용을 차용해서 바로 저희 팀 평가 시스템으로
녹여낼 수 있었습니다. 그럼, 이 부분을 한 번 얘기해보겠습니다.
67

71. 본문 기본 – 최소 글자 크기 18pt 이상
성과를 객관적으로 비교하자
성과 관리
HOW?
먼저, 본인과 타인의 성과를 과연 객관적으로 비교를 할 수 있을까요?
다면 평가를 해보면, 우선 본인의 성과를 먼저 정리를 하게 됩니다.
그리고 다른 팀원들을 평가하죠.
이 때, 과연 우리는 객관적이 될 수 있을까요?
누군가는 본인의 성과를 가급적 있어 보이게 부풀릴 수도 있구요. 상대적으로
다른 팀원에 대한 평가를 낮게 할 수도 있겠죠.
그런데 문제는 과연 본인의 성과와 저 다른 팀원들의 성과를 객관적으로 비교
해보았는가? 입니다.
그 보다 먼저 과연 성과의 비교가 가능한지가 문제겠죠.
객관적이려면 적어도 나의 성과와 팀원들의 성과를 모두 비교할 수 있어야 하
지 않을까요?
68

72. 본문 기본 – 최소 글자 크기 18pt 이상
인지 편향: 저성과자 일수록 자신의 역량을 과대평가
성과 관리
그림 출처: 나무위키
특히, 이 부분이 꽤 인상적이었는데요. 이 그래프는 더닝 크루거 효과를 보여
주는 것입니다.
말로 풀어보자면 “저성과자일 수록 자신의 성과를 과대 평가한다.”는 겁니다.
이게 악의가 있어서 그렇다기 보다는 경험이 부족해서 자신이 저성과자임을
인지하지 못하는 것이죠.
사실, 당시 팀원 중 여기에 해당되는 케이스가 있었기 때문에 팀 내에서도 나
름 정말 고민이 많던 시기였습니다.
이 친구는 본인이 매우 고성과자라고 인식하고 있어요. 근데 실제 성과와 평가
결과를 보면 정반대 거든요. 그러다 보니 고집을 피우면서 동료들과도 자주 다
투는 겁니다.
과연, 이런 경우에는 어떻게 하면 될까요? 과연 이 저성과자는 객관적인 평가
를 할 수 있을까요?
더 나아가 만일 본인에 대한 평가가 낮다면, 이를 수긍할 수 있을까요?
69

73. 안타깝게도 당시에는 현재의 팀 평가 시스템을 도입하기 전이었기 때문에 쉽
지 않았는데요.
69

74. 본문 기본 – 최소 글자 크기 18pt 이상
성과 공유 Tool
성과 관리
그럼, 이제 저희 팀에서 성과를 객관적이고 투명하게 상호 평가하기 위해 도입
한 “성과 공유 툴＂에 대해 이야기해 보겠습니다.
모든 팀 구성원들은 반기 단위로 성과 공유 툴을 작성하게 됩니다.
이 그림처럼 반기동안 자신이 수행한 업무 내역을 우선순위 혹은 중요도 별로
정리합니다.
참고로 저 각각의 업무는 두레이 프로젝트로 관리하고 있는데요. 링크를 타고
들어가보면 업무 진행 내용이 모두 정리되어 있습니다.
70

75. 본문 기본 – 최소 글자 크기 18pt 이상
성과 공유 Tool
성과 관리
그리고 앞서 규약에서 코드 리뷰를 이야기할 때, 코드 리뷰 또한 성과로 인정
이 되어야 한다고 말씀드렸습니다.
저희는 이처럼 코드 리뷰 내역 또한 모두 성과 공유 툴에 정리합니다.
71

76. 본문 기본 – 최소 글자 크기 18pt 이상
성과 공유 Tool
성과 관리
“이번 반기 동안 당신의 가장 자랑스러운 성과 두 가지는 무엇인가요?”
마지막으로 자기 평가를 진행하는데요.
여기에는 정해진 몇 가지 질문이 있습니다. 저희 팀 특성에 맞는 질문이라 여
기에서 공개하지는 않지만,
예를 들어, “이번 반기 동안 당신의 가장 자랑스러운 성과 두 가지는 무엇인가
요?” 같은 질문입니다.
이렇게 각자 성과 공유 툴을 작성한 후에는
72

77. 본문 기본 – 최소 글자 크기 18pt 이상
성과 공유 Tool을 서로 공유
성과 관리
거품 빠진 성과
모든 팀원들의 성과 공유 Tool을 서로 공유합니다.
눈치 채셨겠지만, 성과 내용은 공유될 것이므로 거품이 낄 여지가 없습니다.
내가 10을 해놓고 30을 했다고 거짓말을 하면 바로 들통이 나니까요.
그리고 팀장과 개별 면담을 진행하게 되는데요.
이 때, 면담자의 성과에 관한 부분 뿐만 아니라 다른 팀원들 그리고 팀장 더
나아가 팀이나 업무 프로세스 등에 관한 여러가지 질문이 준비되어 있습니다.
73

78. 본문 기본 – 최소 글자 크기 18pt 이상
성과 평가 진행
성과 관리
1. 본인을 제외한 팀원들 중 (직급 상관없이) 누구의 (절대적인) 성과가 가장 높다고 생각하세요? (2명)
2. 본인은 팀에 어느 정도의 기여를 했다고 생각하세요? (상/중/하)
3. 팀 내에서 협업할 때 가장 시너지가 좋은 사람은 누구인가요?
4. 누구의 코드 리뷰가 가장 도움이 되었나요?
5. 본인을 제외한 팀원들 중 (절대적인) 성과가 부족한 사람이 있나요?
예를 들면, 지금 보시는 이 질문은 전체 많은 질문 중 “성과＂에 관련한 것들
입니다.
본인을 제외한 팀원들 중 누구의 성과가 가장 높다고 생각하는지 물어봅니다.
그리고 본인의 성과도 평가하구요.
당연히 누구의 코드 리뷰가 가장 도움이 되었는지도 묻습니다.
이미 성과 공유 툴을 서로 공유했기 때문에, 이 면담에서는 본인 성과에 대한
거품은 최대한 빠져 있고, 팀원들에 대한 평가는 최대한 객관화 되어 있습니다.
또한 이 면담은 Open-review 직전에 진행하므로, 이 과정에서 평가한 내용들
은 결국 Open-review에 고스란히 적용됩니다.
74

79. 본문 기본 – 최소 글자 크기 18pt 이상
즉시성을 가진 업무는 최우선으로 “할 수 있는 사람”이 한다 = 성과 지향
REMIND: 업무 분장 방식
▪ 개개인이 최대한의 역량을 발휘하고 그것을 객관적으로 평가
우리 담당
우리 담당
우리 담당
다시 앞에서 살펴보았던, 즉시성을 가진 업무에 대한 이 방식.
어떻게 가능한지 이제 좀 이해가 되실 것 같습니다.
즉, “할 수 있는 사람이 한다”는 것은 곧 “성과를 가져갈 수 있는 사람이 가져
간다”는 것이죠.
그리고 그 성과는 당연히 객관적으로 평가를 받겠죠.
자, 여기까지가 저희 팀의 협업에 관한 몇 가지 이야기 였구요.
75

80. 장 표지
선순환을 위한 노력 – 더 단단해지기
이제 마지막으로 저희 팀이 좀 더 단단해 지기 위해 어떤 노력을 했는지 말씀
드린 후에 마무리를 하도록 하겠습니다.
저희는 게임 서버 엔진, 즉, 플랫폼을 개발하는 조직입니다. 그렇다 보니 플랫
폼 사용자들과 소통하며 기술 지원하는 업무도 비중이 꽤 높습니다.
플랫폼 사용자들과 소통하고 기술 지원하는 것 또한 팀이 성장하고 제품에 대
한 신뢰도를 높일 수 있는 방향으로 최대한 고민하고 노력했습니다.
또한 우리 엔진이 막연하게 “잘 돌아가겠지”가 아닌, 매번 새로운 버전에 대해
항상 의심하고 테스트를 통해 검증하는 프로세스를 만들었는데요.
이번에는 그 내용을 간략하게 한 번 살펴보도록 하겠습니다.
76

81. 본문 기본 – 최소 글자 크기 18pt 이상
“누구를 위한 배포 노트인가 ?”
변경 사항은 쉽게 그리고 솔직하게
이런 배포 노트 어떠신가요?
여러분이 플랫폼 사용자라면 어떤 부분이 수정된 것인지 이해가 되실까요?
이전에는 이렇게 저희 엔진에 대한 가장 기본적인 정보도 불친절하게 전달하
고 있었습니다.
그 누구도 해당 내용을 쉽게 이해할 수 없었죠.
77

82. 본문 기본 – 최소 글자 크기 18pt 이상
“배포 노트는 쉽고 친절하게… 잘못된 부분은 솔직하게…＂
변경 사항은 쉽게 그리고 솔직하게
그래서 저희는 새로운 버전이 출시될 때 마다 배포 노트를 꼼꼼히 작성해서
메일로 발송하는데요.
지금 보시는게 배포 노트의 일부입니다.
이 배포노트는 비개발자들도 받을 수 있으므로, 가능한 쉽게 이해할 수 있도록
많이 풀어서 쓸려고 노력을 하고 있습니다.
그리고 이런 배포노트를 쓰다 보면 문제에 대한 수정사항(Fix)들이 꼭 포함이
되는데요.
이전 버전의 문제를 쉬쉬하며 넘기는 것이 아니라, 솔직하게 공유하고 어떻게
고쳤는지 까지 알려드리는 거죠.
이전 버전 사용자 입장에서는 문제가 발견된 것에 대해 손가락질을 할 수도
있겠으나, 그게 두려워서 혹은 귀찮아서 공유하지 않으면 결과적으로 팀이나
플랫폼에 대한 신뢰도를 떨어뜨리게 됩니다.
78

83. 본문 기본 – 최소 글자 크기 18pt 이상
Test 결과는 투명하게 공유
체계적이고 반복적인 Test
그리고 저희는 매번 새로운 버전이 출시될 때마다 기능 테스트는 물론이고 수
십대의 VM을 이용해서 대규모 성능 테스트를 진행합니다.
예전에는 이런 테스트 없이 즉흥적으로 배포를 했기 때문에, 그 배포 버전에서
또 다른 문제가 발생하곤 했습니다. 하루에도 몇 번씩 배포하는 웃지 못할 사
태도 벌어지는 거죠.
모든 버전은 동일한 테스트 환경에서 다양한 구성으로 장시간 동안 검증합니
다.
그리고 테스트 결과가 기대 값과 다를 경우에는 그 원인이 명확해질 때까지
의심하며 계속 추적하고 검증합니다.
즉, 테스트 결과에 대해서 그냥 ＂잘 돌아가네＂가 아니라 계속해서 ＂잘 돌아
가는게 맞는가?” 라는 의심을 반복 하는거죠.
그 반복 확인 결과를 우리가 믿을 수 있게 되었을 때, 배포하는 겁니다.
그리고 이러한 테스트 과정과 결과는 모두 그림에서 보시는 것과 같은 별도의
79

84. “테스트 보고서”를 작성해서 사용자들에게 투명하게 공유합니다.
이런 것들 하나하나가 모두 팀과 플랫폼에 대한 신뢰도를 올리기 위한 노력의
일환인 거죠.
79

85. 본문 기본 – 최소 글자 크기 18pt 이상
잘 정리된 가이드 문서
선순환을 위한 노력의 마지막은 가이드 문서입니다.
이전에는 엔진 사용법에 관한 문서가 잘 정리되어 있지 않았습니다.
존재하던 문서들 조차도 내용이 많이 부족했고 업데이트 내용이 잘 반영되어
있지 않았어요. 그 마저도 파편화 되어서 여러 곳에 나뉘어져 있었기 때문에
접근성이 매우 떨어졌습니다.
그래서 저희는 그림에서 보시는 바와 같이 NHN 클라우드 상에 가이드 문서를
제공하기 시작했는데요.
저희 엔진의 하나부터 열까지 중요한 내용은 물론이고 현재는 튜토리얼도 제
공하고 있기 때문에 엔진을 처음 사용하더라도 이전보다 한결 학습하기 수월
해 졌습니다.
이러한 가이드 문서 작성 또한 팀과 플랫폼의 신뢰도를 높이기 위해 필수임을
잘 알기 때문에,
팀은 정말 많은 에너지와 시간을 투자 했습니다.
80

86. 장 표지
결론
지금까지 저희 엔진팀이 2년 동안 팀과 플랫폼에 대한 신뢰도를 높이고 성과
를 지향하기 위해 노력한 내용들을 말씀드려 보았습니다.
팀마다 고유한 문화를 가졌기에 당연히 정답이 없는 이야기들입니다만, 분명
일부 조직은 앞 서 저희가 경험했던 문제들을 똑같이 겪으며 고민하고 있을
수도 있다는 생각이 듭니다.
그런 경우라면 오늘 제가 말씀드린 내용들을 한 번쯤 고민해 보시는 것도 좋
을 것 같습니다.
저희는 이런 위기를 잘 극복하고, 현재는 더할 나위 없이 체계적이고 끈끈한
팀이 되었습니다.
81

87. 본문 기본 – 최소 글자 크기 18pt 이상
성능 10배 넘게 올렸어요
체계적이고 끈끈한 팀은 상상 이상으로 큰 힘을 발휘합니다. 또한 한 번 맛본
성과의 맛은 달기 때문에 계속해서 성과를 쫓게 되죠.
이런 막강한 팀 파워를 기반으로 저희는 이렇게 지속적으로 엔진의 성능과 안
정성을 극대화하고 있구요.
그 결과, 현재의 GameAnvil은 더 이상 2년 전의 그 문제가 많던 엔진이 아닙
니다.
현재 성능은 14배 이상이 올랐고, 안정성과 상품성 또한 비교 불가능한 수준
이 되었습니다.
참고로 이런 성능 최적화 및 안정화 작업의 내용은 작년 NHN 포워드에서 공
유하였으니, 혹시라도 관심 있는 분들은 한 번 참고 해보시기 바랍니다.
82

88. 본문 기본 – 최소 글자 크기 18pt 이상
클라우드 상품화
그리고 이렇게 잘 돌아가는 엔진을 NHN 사내에서만 이용하는 것은 아깝다고
생각했습니다.
그래서 NHN 클라우드 상품화를 한창 진행 중 이구요. 현재는 그림과 같이 알
파 상품으로 등록되어 있어서 문의를 주신 외부 고객들에게만 공개를 하고 있
습니다.
그 다음 스텝으로 당연히 가능한 빠르게 정식 상품화를 하기 위해 저희는 오
늘도 열심히 달리고 있습니다.
이렇게 보니, 그야말로 팀은 2년 사이에 극과 극을 오갔네요.
83

89. 본문 기본 – 최소 글자 크기 18pt 이상
이런 팀에서
이렇게 성과를 지향하며 끊임없이 달리는 팀의 분위기는 그야말로 현재 최고
입니다.
지금 보시는 이런 대화는 절대 제가 강요한 것도 아니고, 연출도 아님을 말씀
드립니다.
워낙 소통 비용이 낮다 보니 평소에도 이런 스몰토크부터 업무 이야기까지 다
양하게 주고 받습니다.
어떠세요?
꽤 괜찮은 개발팀이지 않습니까?
84

90. 본문 기본 – 최소 글자 크기 18pt 이상
이런 팀에서 함께 할 열정 넘치는 동료를 찾고 있습니다.
https://recruit.nhn.com/ent/recruitings/20002158
mc.jeon@nhn.com
깨알 홍보
이런 꽤 괜찮은 개발팀에서 함께 할 동료를 찾고 있습니다.
저희 NHN의 게임서버엔진팀에서 GameAnvil을 함께 개발하며, 글로벌 상품
화까지 진행할 열정 넘치는 개발자님들은
NHN 채용 페이지를 통해 언제든 지원 부탁드립니다!
혹시라도 저희 팀과 GameAnvil에 관해 궁금한 사항이 있으실 경우에는 아래
의 제 e-mail 주소로 편하게 연락 주셔도 됩니다.
85

91. © 2020 NHN FORWARD. All rights reserved.
끝
이상으로 오늘의 발표를 마치도록 하겠습니다.
긴 시간 시청해 주셔서 고맙습니다.
좋은 하루 되세요!
86