[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발...

70명이 커밋하는 라이브 개발하기 해외 진출 라이브 프로젝트의 개발 관리

Neople

송창규

“70 commiters in a single project?”

“ㅇㅇ” http://bit.ly/dnfcommits

2013/4/16 단 하루 커밋

소개

송창규 Dungeon & Fighter Technical Director

게임개발 13년차 3개 게임 처음부터 라이브까지 개발 (Dizzy Pang, Big Shot, Bubble Fighter)

1999, Gabriel Knight 3 한글화, 출시

2001, Worms World Party 한글화, 출시

2002, Crazy Arcade 참여

2002-2003, Dizzy Pang 개발 리드, 출시

2004-2006, Big Shot 제안, 기획, 개발 리드, 출시

2006-2010, Bubble Fighter 개발 리드, 출시

2010-2011, Project W @ devCAT 참여

2011-, Dungeon & Fighter 테크니컬 디렉팅

대상

해외 라이브 개발에 참여하고있는 (혹은 병렬 개발 파이프라인에 관심이 있는)

시니어 프로그래머 / 관리자 / 프로듀서

Production / Programming Track

순서

라이브 게임개발 시나리오

던파 머지 지옥 개선 사례

병렬/라이브 개발 – 팁 & 단상

마치며

“MERGE HELL”

라이브 게임개발 시나리오

Live Game Development Scenario

흔한 초기 해외진출 시나리오

한국 서비스 성공적으로 런칭 완료!

“중국 서비스를 위해 중국 버전 만들자!”

그리고 1년 후…

해외 작업자는 머지옥 (MERGE HELL) 을 경험

MERGE HELL Case #1

중국 진출하자!

MERGE HELL Case #1

중국 진출하자!

따라가야할 양이 너무 많다

갈수록 머지가 힘겨워진다 부분만 반영되어 다른 소스 순서가 다르게 적용되어 반영이 될 수 없는 소스

Technical Debt (기술채무)

Code Debt(코드빚) 이라고도 함

일반적인 발생요인

비즈니스 압력이나

하드코딩/커플링,

원활한 협업이나 이해부족,

리팩토링 지연 등

쌓여가는 머지 부담도 Technical Debt 의 하나

아예 개발된 대규모 컨텐츠를 다 가져오면..

중국 진출!

로컬라이징, 중국용 이벤트/컨텐츠를 개발

추가된 한국 컨텐츠를 한번에 가져오자

중국에 맞는 이벤트/컨텐츠를 개발하자

중국에 넣었던 컨텐츠 다시 머지

MERGE HELL Case #2

중국 진출! 인증, 빌링 등 초기 셋업 작업 진행


한국 대규모 컨텐츠 도입


작업했던것 다시 머지해넣음

불어나는 빚: 처음부터 다시 머지해넣는다



OB수준의 대량 테스트/문제해결



다른 게임들은?

게임M

진출시부터 나라별 분리된 소스

머지 헬을 겪고 원소스로 합침

서비스별 개발조직 분리로 소스분리

게임K

옆 프로젝트의 머지 헬을 반면교사삼아

해외진출 초기부터 원소스 유지

서비스별 조직분리로 국가별 소스 분리 (x2)

다시 원소스로 합침 (x2)

반복되는 역사. 정답은?

원소스

“합치자”

브랜치

“갈라서”

합치려는 포스 보통 개발쪽의 의지

따로 브랜치 따면 당장은 편하지

나중에 결국 머지 다 해야해요

지금 당장 편하자고 갈라서면

나중에 개고생해요 나중에 합칠때 서로 안맞는건 어떡하려고

갈라지려는 포스 보통 서비스쪽의 의지

지표가 떨어지고 있어 빨리 패치해야해

지금 못한다고? 우리 작업이 늦춰지잖아

우리 서버가 죽은 이유가 저쪽에서 로그 심다가 그런거라고?

이 나라에 맞는 컨텐츠를 직접 개발하고싶어

경험자들이 흔히 하는 말

“나중에 개발에서 퍼져요

결국 해외 구조 고려해서

원소스 가야죠”

모범사례격인 매이저 게임들은

어떻게 하고 있을까?

WoW

동일한 패치내용이

거의 동시에 릴리즈

심지어 웹페이지도 동일

LoL

마찬가지로

패치내용 거의동일 국가간 패치 시점 1주일 이내

PvP 특성상

컨텐츠 추가보다는

밸런스 조정 위주

웹페이지는 한국 특성에 맞게 바꿨군…

확실히 오른쪽이 괜찮아 보인다

과연 정답일까?

이쯤되면 저게 맞는것 같은데…

(가급적) 동일한 내용으로 동일한 시기에

모든 나라에 릴리즈하는게 정답일까?

문화/성향이 다름

“국가별 게이머 종족특성” by onesound

나라별 상황도, 공략 포인트도 다르다

중고등학생 중심

PvP 비활성

게임머니 현금결제 불가

…

일본

소수의 마니아층 위주

PvP 비활성

뽑기와 조합맞추기

싱글플레이 선호

중국

대중적인 국민게임

PvP 활성화

게임머니 현금결제

창모드, 채팅창 분리 선호

상황에 따라 우선순위, 전략도 제각기

한국에서는 이탈이 진행되어 귀환과 정착에 집중

중국에서는 대부분 만렙이라 컨텐츠가 고갈된 상황

시즌 특수 타이밍도 다르다

크리스마스, 설날, 추석, ..

할로윈은 별로..

일본

골든위크, ..

중국

춘절, 국경절, 노동절, ..

크리스마스는 별로..

유저/매출 비중도 다르다

매출

일본

한국

중국

기타

동접

일본

한국

중국

기타

이해를 돕기위해 대강 느낌상 차이를 표현한 다이어그램입니다

돌아보기: WoW

3개만 내려가도

시차 1년 이상

약 3~4개월마다

대규모 패치 릴리즈

라이브 패치라기보단 타이틀을 하나 팔고

확장팩을 릴리즈하는 것에 가까운 느낌

아마도 아직 패키지 시장 패러다임에서

벗어나지 못했기 때문이 아닐까

돌아보기: LoL

게임은 거의 동일했지만

웹페이지는 다름

한국 유저들에게는

확실히 오른쪽이 익숙하고 접근성이 좋을것 같다

게임도 마찬가지 아닐까?

문화, 익숙함, ..

던파 장미칼 패키지 출시! 국가별로 같은 내용만 출시해야한다면 이런 컨텐츠 활용이 힘들 것

어제 막 나온 화제의 장미칼 패키지

http://bit.ly/roseknife

다른 게임들은? #2

게임C

한국을 메인으로 개발하다가

중국에서의 선전으로

중국을 메인으로 개발

이후 모든 국가가

개발브랜치로 정기적인 통합

통합과정에서의 불안정성이 아직 과제

게임 C’

해외 진출을 고려한 구조

릴리즈용 stable branch가 있고

그 외의 것은 메인 개발 브랜치에서 개발

국가별 차이를 Feature Switch 로 구현

테스트와 안정성을 위해

릴리즈/브랜치 구조 개선

(프로세스 개선에 약 1년 소요)

던파 머지 지옥 개선 사례

Case Study of ‘Merge Hell’ Improvement

기존 던파의 해외 개발 앞서 보았던 두번째 케이스

중국 진출! 인증, 빌링 등 초기 셋업 작업 진행




작업했던것 다시 머지해넣음

불어나는 빚: 처음부터 다시 머지해넣는다






대규모 업데이트 하려면

국내 대규모 소스를 가져온 후

2년~5년간 개발한 것을

전부 다시 수동 머지!

“매번 오픈베타하는것 같아요”

작업기간 4개월 (추가 개발+테스트+릴리즈까지)

머지+컴파일+기동에만 한달 이상 소요

이대로면 계속 증가

나중에는?

지속 불가능한 개발 프로세스

지금이라도 원소스?

바로앞만 보지말고

멀리보고 지금이라도 원소스 가야하나?

갈데까지 가버린 느낌이지만…

“그런데, 원소스가 무슨뜻이지?”

국가별 서비스개발이 한 소스에서 컴파일? #ifdef 가 모두 제각기 다르게 적용되고 있다면?

local copy 나 branch 없이 여러 국가의 freeze & test & release 가 가능한가?

브랜치를 사용 안하는것? QA테스트와 릴리즈시에 브랜치 사용하면 원소스 아닌가?

피처 브랜치 사용하면 원소스 아닌가?

패치를 위해 커밋한 내용이 다른나라서비스에 영향을 주는지? 한국에 커밋된 내용은 다른나라에 영향을 주지만,

중국에 커밋된 내용은 한국에 영향을 안준다면?

혹은 영향을 주지만, 6개월 후에 영향을 준다면?

사실, 차이가 크게 나는 브랜치의 반대 형태를 막연하게 지칭하는 말

브랜치를 사용하지 않으면.. 개발규모에 Scalable 하지 않다

1. 패치전 FREEZE 하면 70명 대기?


2. 서비스/패치가 많으면?

2011년 10월 실제 던파 서비스 패치 일정


100번 커밋중 한번 정도 빌드를 깨먹는 (컴파일이 안되거나 실행이 안되거나)

신중한 개발자들이 개발팀을 꾸렸다.

만약 한 브랜치에서 작업한다면:

7명 일때 어느 하루 빌드가 깨질 확률은 약 20%

70명 일때 어느 하루 빌드가 깨질 확률은 약 90%

지나치게 단순화시키긴 했지만 작업자에 따라 급격하게 떨어지는

안정성을 설명 가능


개발자가 늘어날수록

n 과 downtime 이 같이 늘어난다 ( 안깨먹을 확률은 기하급수적으로 떨어짐 )

Loss of Resource = downtime * n (no. of developers)

경험상 같은 영역의 개발조직에 개발자 10명이 넘어가면 병목이 심해지기 시작

Side-effect Downtime Bottleneck

어쨌든 이 차이는 줄여야한다!

브랜치의 차이가 곧 머지 비용,

되갚아야 하는 빚(기술채무)이기 때문

하지만 아궁이의 불을 꺼뜨릴 수는 없고...

한번에 줄일 수 없으면, 한단계씩 가보자

초대형 레거시 프로젝트

.cpp + .h 파일수 4319+5680 = 9999파일 (2012년말 당시)

전체 라인수: 40만줄 (빈칸/코멘트 제외 30만줄)

프로그래머 70 명

독립적으로 돌아가는 개발조직: 당시 7개 서비스, QA, SE 등 포함하면 훨씬 많음..

국내개발

서버개발

라이브 클라개발

컨텐츠 클라개발

해외개발

중국개발

일본개발

인프라개발

보안

개발

한달 공식 패치 횟수: 19회

한국 1주일 2회 (테섭/실섭)

일본 2주일 1회

미국 2주일 1회

중국 2주일 1~2회

미칠듯한 커밋속도!!

1~2분에 한번 꼴로 커밋

리비전 10만 돌파

대통합 도전!

달리는 자동차의 바퀴를 갈아끼우기

일단 머지 도구사용부터 전파

Ctrl+C, Ctrl+V, 더 이상은 naver...

기존 해외 대규모 개발

메인 브랜치를 따와서

예전 개발된 내용들을

모두 다시 머지

실섭은 별도로 운영하다가

나중에 따로 추가 머지

머지해야할 내용이 점점 증식

기존 해외 대규모 개발

2개 국가의 경우

전부 trunk 로 머지?

가령 이렇게?

“이러면 한번만 머지해도 될거야..”

“처음부터 전부 다시 머지는

더 이상은.. naver..”

생각처럼 쉽지 않다

문제1

한국 서비스 불안정 유발

문제2

해외 대규모 버전의 베이스 버전 선택 문제 한국 서비스가 해외의 사이드 이펙트로 불안정해지지 않아야 하듯, 해외 서비스도 한국 서비스로 불안정해지지 않아야함

리소스 파일 작업 동기화

역머지 브랜치를 하나 생성 사이드 이펙트로 인한 국내 불안정 방지

해외 서비스도

안정 버전을 선택후

이후 개발로부터의

사이드 이펙트 격리

trunk 로 머지하면

대망의 전국가 통합이?!

문제1: more conflicts

코드 거리가 그새 또 벌어짐

이미 2개월도 안되어

conflict 다량 발생

거리가 이미 많이 벌어져있다 시간차: 4개월

작업량: 4개월*약40명

문제2: stability

대량 conflict 를 한꺼번에

resolve / commit 하는 부담

모두 resolve 후

컴파일이 되었더라도

실행이 깨진 상태이기 쉽다

문제2: R&R

국내 개발 조직과

해외 개발 조직은 별도의 조직

“이거 왜 실행안돼?”

“해외쪽에서 커밋했더니..”

“@#$@#$!!”

Integration Branch

“따라가는 브랜치” 양쪽에서 머지해 들어오기

장점 1:

양쪽 내용이 전부 통합되지만

작업 브랜치에 사이드이펙트가 없다

SVN reintegrate

Integration Branch


장점 2:

conflict & merge 가

한번에 발생하지 않고 분산된다

( 리스크 분산, 머지 부담 감소 )

Integration Branch


장점 3:

시점을 마음대로 선택할 수 있다

국내의 패치에 지장을 덜 주면서

QA 테스트 일정과 연계할 수 있도록

trunk 반영 시점을 선택할 수 있다:

“conflict 걱정없이 atomic 하게 reintegrate”

안정성 등의 이유로 중간에 계획이 바뀌더라도

global (work) 의 베이스 시점을 나중에 바꿀 수도 있음

Integration Branch e.g) 선택했던 베이스 버전을, 나중에 변경하는 경우

Integration Branch


장점 4:

역할과 책임을 분리할 수 있다

오렌지색 작업영역은 국내개발팀에서

하늘색 작업영역은 해외개발팀에서 담당하면

“우리 영역의 코드만을 머지한다”

“우리 영역의 코드에 머지한다” 가 명확해진다

우리영역 너네영역이 어딨겠냐만은..

인원이 많고 조직이 크고 라이브 서비스에 영향을 주면 때론 R&R 영역구분이 중요하다

다른 속도로 따라가며 integration 가능

적당한 단위로 뭉치고

바쁘면 다음에

각자의 사정에 따라

경우에 따라 따라가는 속도의 적절한 조절만으로 대량 컨플릭트의 대부분을 줄일수도 있다

새 프로세스의 변화: 작업

새 프로세스의 변화: 브랜치

새 프로세스의 변화: 리팩토링

코드가 갈라져있을때는 전반적 리팩토링을 못하거나, 문제가 많았다 리팩토링한것이 코드빚이 되어 대규모 머지할때 이자까지 쳐서 고스란히 돌아옴

정확히 말하면 대량 수정이 거의 불가

달리는 자동차의 바퀴를 갈아끼우기

http://bit.ly/chgtire

“되는데요”

앞으로의 숙제

리소스 머지 사실 여태까지의 이야기에 리소스 이야기는 빠졌다

리소스파일의 SVN 머지도 조금씩 도입중

같은 영역에 함께 작업했을때 conflict 이 나지 않고 merge 되는 구조가 중요

테스트 안정성 통합 시점에 엔트로피가 급증하고 안정성이 떨어지는 시기를 수반

리소스, DB 등 다른 시스템과의 정합성을 맞추고,

중간 통합을 초기부터 바로바로 하고,

머지 누락을 자동화하여 체크하는 등 개선을 시도

병렬/라이브 개발 – 팁 & 단상

Parallel / Live Development Wisdom

안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수 온라인화되고, 게임 수명과 컨텐츠 고갈이 대두되는 모바일 개발에서도 브랜치/병렬 개발이 중요해질것

브랜치 없이는

서비스가 하나라도

개발규모를 일정 이상 키울수 없다 Side-effect Downtime Bottleneck

적절한 브랜치 사용 예시

• 개발용 unstable branch

• 소, 중, 대 규모로 구분되는 feature branch

• 개발QA테스팅과 함께가는 stable branch

• stable branch를 기반으로 한 패치날짜별 staging branch, release branch

staging 브랜치는 패치 전 테스트용

release 브랜치는 실섭 버그픽스/장애 대응용 hotfix 개발

역할의 분리일뿐 같은 브랜치 사용이 편리

“Guild Wars 2는 20개의 feature branch team 를 운영하지요”

- “Guild Wars 2: Scaling from One to Millions, GDC2013

통합 주기는 언제가 적절할까?

서비스브랜치로의 통합주기는 한달 정도가 적절 시간적으로는 자주할수록 유리

동시에 작업이 쏟아져들어오면 엔트로피가 급격히 증가하고 안정성이 떨어질 수 있다

둘 사이에서 적절한 균형을 잡아야

QA/테스트 프로세스에 맞춘 불안정/안정 관리가 주기 선정에 있어 중요

Integration Branch 를 활용하면 좀더 선택의 폭이 넓어짐 side-effect 제어

시점 제어

길어야 6개월 이내가 되도록 안그러면 영영 멀어질수도 있다

몇가지 머지 팁

feature branch 활용 라이브에서 여러명이 동시에 작업할 경우나

기존 동작에 영향주는 리팩토링에 특히 유용

integration branch 활용 사이드 이펙트/컨플릭트 폭탄 없는 다국가 통합시 활용

feature branch 를 장기간으로 진행시에도 유용하게 활용 가능

버블파이터 개발당시 feature branch


브랜치 작업/통합시 side-effect, 브랜치 크기(브랜치 기간)에 따라 적절한 형태를 활용


- 3가지 브랜치 형태 1 2 3


svn:mergeinfo 활용 SVN merge 를 통해 머지된 내용들에 대한 metadata (svn property)

머지된 리비전 관리비용과 중복 머지로 인한 컨플릭트를 줄여준다

알아두면 종종 mergeinfo 수작업을 통한 활용으로 시간을 많이 아낄 수 있다

svn reintegrate 시에는 모든 내용이 머지되어있어야 하므로 직접 채워줘야할 수 있음

대규모 리팩토링/Find & Replace All in Files 같이 컨플릭트를 많이 유발하는 작업의 경우

의미적으로 같은 작업을 모든 브랜치에 적용하고 서브 브랜치에 mergeinfo 를 넣어줌으로서

독립 브랜치를 유지하면서 컨플릭트를 드라마틱하게 낮출 수 있다


테크닉보다 중요한것

조직차원의 지속 가능한 작업이 되어야 한다

브랜치 작업방식과 머지, 정기적인 통합이 프로세스화 되어야 한다

통합에 대해 영역별로 통합을 진행하는 integration 전담자가 있어야 한다

던파 사례의 경우 조직별 머지 담당자가 없었으면 통합이 불가능했을것

테크닉보다 중요한것

규모가 크면 혼자서는 할 수 없다. “함께” 해야함 앞선 사례도 수많은 사람들의 협조와 도움, 특히 “머지마스터”들의 도움으로 달성

이해관계가 다른 조직간의 조율, 커뮤니케이션, 설득

여러 조직의 alignment: 반복적인 방향 공유

프로토타이핑 기반 개발 양산형 개발 라이브 초기 해외 진출 라이브 후기

게임 개발 단계 전환시기가 기회

각 단계 전환을 앞두고 채무점검 & 다음 스테이지에 필요한 구조를 준비

이자율 할인의 기회 초반 구조를 어떻게 잡느냐에 따라 이후 개발에서 큰 차이가 나타날때가 많다

초반에 잡지 않은 구조를 라이브 단계에서 다잡는것은 매우 힘겨운일

너무 이른 시점에 너무 후반을 위해 많은 리소스를 들이는것도 현명하지는 않음

많이 알려져있지 않으면서

라이브 중반 이후 중요한 기술 구조

Feature Switching

#ifdef 를 최소화하고 국가별 차이에

일원화된 Feature Switching 구조를 사용

개념적으로 Feature Matrix 형태를 형성 그렇다고 국가별 파일을 가르지 않고 전체 매트릭스를 하나의 파일로 관리하면 재앙이 올것이야..

ON/OFF 뿐 아니라 피처 버전이나 실장날짜가 들어가면 유용



국가별 애셋/리소스 관리/머지 도구

최대한 머지가 가능한 리소스 포맷과 툴을 사용

국가별 사용/패키징 여부를 Feature Matrix 형태로

중앙관리할 수 있는 기반이나 도구를 장만

버전 차이로 인해 어려운 완전 자동화를 노리기보다는 머지가 쉬운 포맷과

국가별 사용/패키지 여부를 관리하는 도구를 장만하는 쪽이 현명

관련자료 GDC 2013, “Working Together”



점검툴 for SE, DBA

퍼블리셔의 DB, 장비에 일반적으로 접근권한이 없고

커뮤니케이션 장벽의 퍼블리셔의 SE 를 통해야한다

적지않은 해외 서비스 불안정은 점검시

SE 커뮤니케이션/작업실수에서 비롯

ex) DB schema 버저닝, 원클릭 설정, 상태 체크 등..



보안 운영툴

보안은 개발과 운영의 영역이 겹쳐있음

개발만으로 운영의 영역을 커버하지 못한다

퍼블리셔측에서 GM운영 뿐 아니라 보안 운영 또한 가능하도록

자동 제재 리얼타임 반영이 가능한 운영툴 필요



로그/통계 수집 구조 (Telemetry)

라이브 서비스를 시작하면 늘 통계적인 분석을 필요

매번 반복되는 로그/수집을 일원화하면 큰 도움이 된다

부하를 신경쓰지 않아도 되는 수집 인터페이스

정규화되고 대칭적인 로그/포맷

공통 필드를 정해놓고 tab 으로 구분하기만 해도 큰 도움이 된다



컨텐츠를 뺄 수 있는 구조 라이브 개발이 지속되면 개발 내용은 쌓이지만

정작 무거워진 로딩시간이나 메모리 부족 현상에 봉착했을 때

정작 원하는 내용이나 사용하지 않는 내용을 지우기는 굉장히 힘들다

컨텐츠단위로 소스/리소스를 선택하거나 뺄 수 있는것이 중요

리소스/애셋관리 하부에 공통 weak referencing 기능이 있으면 유용

조직구성의 고민과 함께 가야한다

해외 라이브를 진행하면 조직 R&R 이 겹치기 시작 ex) 개발부서에서도 기획, 서비스부서에서도 기획에서도 제안하거나 기획

중국 서비스에 나가는 내용은 개발팀도 개발하고 중국개발에서도 개발

조직구성의 고민과 함께 가야한다

서비스 응집성 vs 개발팀 응집성? 서비스 중심으로 조직을 구성 긴밀한 개발 커뮤니케이션으로 부족한 개발 응집성을 높이고,

개발 중심으로 조직을 구성하면 긴밀한 서비스 커뮤니케이션으로 부족한 서비스 응집성을 높여야한다

마치며

Conclusion

일명 “원소스” 논쟁

합치려는 포스 보통 개발쪽의 의지

따로 브랜치 따면 당장은 편하지

나중에 결국 머지 다 해야해요

지금 당장 편하자고 갈라서면

나중에 개고생해요 나중에 합칠때 서로 안맞는건 어떡하려고

갈라지려는 포스 보통 서비스쪽의 의지

지표가 떨어지고 있어 빨리 패치해야해

지금 못한다고? 우리 작업이 늦춰지잖아 우리 서버가 죽은 이유가 저쪽에서 로그 심다가 그런거라고?

이 나라에 맞는 컨텐츠를 직접 개발하고싶어

1. 대규모 개발에 브랜치는 필수

안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수

2. 정답은 없다 - 개발기조 하지만 현명한 선택은 중간 어디엔가 있다

모든 국가에 똑같이 서비스

개발응집성이 늘어나

Technical Debt 을 줄일 수 있다

컨텐츠가 따로놀지 않고 일관성을 갖는다

여러 국가별로 다양한 이슈 대응이

기민하고 유연하지 못하기 쉽다

국가별 상황과 특징에 맞춰 개발

국가별로 상황/이슈 대응이 유연하지만

활발한 개발직군 커뮤니케이션 등을 통해

개발 응집성을 충분히 갖추지 못하면

이자와 함께 빚이 눈덩이처럼 불어날 수 있음

던파의 경우 Technical Debt 부담이 크지만, 한편 중국 서비스 성공 요소에는 기민하고 유연한 서비스 대응과

중국서비스-중국개발의 긴밀함이 기반되었다고도 볼 수 있다

3. 정답은 없다 - 조직구성 하지만 현명한 선택은 중간 어디엔가 있다

1개의 개발조직 vs 서비스조직 개발팀 응집성을 늘려 Technical Debt 을 줄일 수 있고

컨텐츠가 따로놀지 않고 일관성을 갖지만

국가별 상황/이슈 대응이 기민하고 유연하지 못하고

조직 R&R 이 모호해진다

서비스별 개발조직 분리 국가별로 상황/이슈 대응이 유연하지만

활발한 개발직군 커뮤니케이션 등을 통해

개발 응집성을 충분히 갖추지 못하면

이자와 함께 빚이 눈덩이처럼 불어날 수 있음

라이브 서비스 메타포

아궁이 불때기

소방관 불끄기

빚 빚갚기

아궁이

라이브 서비스는 아궁이 지키기

관심 아궁이

재미 아궁이

컨텐츠 아궁이

한번 꺼지면 다시 붙이기 힘들다

꺼지지 않게 잘 지켜줘야한다

땔감 공급해주고

비바람에 꺼지지 않게

“갈망의 아궁이” by 김동건

소방관

주변에 불이 붙으면

홀랑 태워먹고 망할 수 있다

무적핵, 각종 핵툴

복사버그

계정해킹

악성여론

서비스 vs 개발

서비스조직은 불을 지키고 개발조직은 땔감을 마련

나무 하고 장작 패고 물도 길어와서 불도 끄고 빚낸거 이자쳐서 갚아나가고

서로 다른 아궁이(서비스)의 불을 지키기 위해서는..

땔감을 구하는것도 좋지만

아궁이에 불이 꺼지지 않게,

화재시엔 빠르게 불끄는게 중요 서비스팀이 개발팀에 설득.강조해야하는 부분

아무리 좋은 땔감(컨텐츠, 기술)을 마련해도

불이 꺼지면(유저가 떠나면) 모든건 끝이다

당장 필요한 것들에 치중해서

구조를 개선하고 빚갚는데 소홀하면

늘어나는 이자로 빚더미에 앉고 파산할 수 있다 개발팀이 다른 직군에게 설득.강조해야하는 부분

빚내고 이자가 늘어나는 개념으로 설명하면

비개발 사람들에게 쉽게 전달.설득 가능

감사합니다

다른곳에서는 경험할 수 없는

거대한 스케일의 유저, 코드, 개발을 경험하고싶다면

그리고 그것을 개선시키고 더 좋은 서비스로 만들어 높은 부가가치를 창출하고싶다면

시니어들을 위한 크나큰 도전과 경험의 땅 네오플로!

[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발...

Documents

Transcript of [NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발...