Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
70명이 커밋하는 라이브 개발하기해외 진출 라이브 프로젝트의 개발 관리Neople송창규
“70 commiters in a single project?”“ㅇㅇ”http://bit.ly/dnfcommits2013/4/16단 하루 커밋
소개송창규Dungeon & Fighter Technical Director게임개발 13년차3개 게임 처음부터 라이브까지 개발 (Dizzy Pang, Big Shot, Bubble Fighter)1999, Gabriel ...
대상해외 라이브 개발에 참여하고있는(혹은 병렬 개발 파이프라인에 관심이 있는)시니어 프로그래머 / 관리자 / 프로듀서Production / Programming Track
순서라이브 게임개발 시나리오던파 머지 지옥 개선 사례병렬/라이브 개발 – 팁 & 단상마치며
“MERGE HELL”
라이브 게임개발 시나리오Live Game Development Scenario
흔한 초기 해외진출 시나리오한국 서비스 성공적으로 런칭 완료!“중국 서비스를 위해 중국 버전 만들자!”
그리고 1년 후…해외 작업자는 머지옥 (MERGE HELL) 을 경험
MERGE HELLCase #1중국 진출하자!
MERGE HELLCase #1중국 진출하자!따라가야할 양이 너무 많다갈수록 머지가 힘겨워진다부분만 반영되어 다른 소스순서가 다르게 적용되어 반영이 될 수 없는 소스
Technical Debt (기술채무)Code Debt(코드빚) 이라고도 함일반적인 발생요인비즈니스 압력이나하드코딩/커플링,원활한 협업이나 이해부족,리팩토링 지연 등쌓여가는 머지 부담도 Technical Debt 의 하나
아예 개발된 대규모 컨텐츠를 다 가져오면..중국 진출!로컬라이징, 중국용 이벤트/컨텐츠를 개발추가된 한국 컨텐츠를 한번에 가져오자중국에 맞는이벤트/컨텐츠를 개발하자중국에 넣었던 컨텐츠 다시 머지
MERGE HELLCase #2중국 진출! 인증, 빌링 등 초기 셋업 작업 진행중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입중국에 맞는이벤트/컨텐츠를 개발하자작업했던것 다시 머지해넣음불어나는 빚: 처음부터 ...
다른 게임들은?게임M진출시부터 나라별 분리된 소스머지 헬을 겪고 원소스로 합침서비스별 개발조직 분리로 소스분리게임K옆 프로젝트의 머지 헬을반면교사삼아해외진출 초기부터 원소스 유지서비스별 조직분리로국가별 소스 분리 (x2...
반복되는 역사. 정답은?원소스“합치자”브랜치“갈라서”
합치려는 포스보통 개발쪽의 의지따로 브랜치 따면 당장은 편하지나중에 결국 머지 다 해야해요지금 당장 편하자고 갈라서면나중에 개고생해요나중에 합칠때 서로 안맞는건 어떡하려고
갈라지려는 포스보통 서비스쪽의 의지지표가 떨어지고 있어 빨리 패치해야해지금 못한다고? 우리 작업이 늦춰지잖아우리 서버가 죽은 이유가 저쪽에서 로그 심다가 그런거라고?이 나라에 맞는 컨텐츠를 직접 개발하고싶어
경험자들이 흔히 하는 말“나중에 개발에서 퍼져요결국 해외 구조 고려해서원소스가야죠”
모범사례격인 매이저 게임들은어떻게 하고 있을까?
WoW동일한 패치내용이거의 동시에 릴리즈심지어 웹페이지도 동일
LoL마찬가지로패치내용 거의동일국가간 패치 시점 1주일 이내PvP 특성상컨텐츠 추가보다는밸런스 조정 위주웹페이지는 한국 특성에 맞게 바꿨군…
확실히 오른쪽이 괜찮아 보인다
과연 정답일까?이쯤되면 저게 맞는것 같은데…(가급적) 동일한 내용으로 동일한 시기에모든 나라에 릴리즈하는게 정답일까?
문화/성향이 다름“국가별 게이머 종족특성” by onesound
나라별 상황도, 공략 포인트도 다르다중고등학생 중심PvP 비활성게임머니 현금결제 불가…일본소수의 마니아층 위주PvP 비활성뽑기와 조합맞추기싱글플레이 선호중국대중적인 국민게임PvP 활성화게임머니 현금결제창모드, 채팅창 분...
상황에 따라 우선순위, 전략도 제각기한국에서는 이탈이 진행되어 귀환과 정착에 집중중국에서는 대부분 만렙이라 컨텐츠가 고갈된 상황
시즌 특수 타이밍도 다르다크리스마스, 설날, 추석, ..할로윈은 별로..일본골든위크, ..중국춘절, 국경절, 노동절, ..크리스마스는 별로..
유저/매출 비중도 다르다매출일본한국중국기타동접일본한국중국기타이해를 돕기위해 대강 느낌상 차이를 표현한 다이어그램입니다
돌아보기: WoW3개만 내려가도시차 1년 이상약 3~4개월마다대규모 패치 릴리즈라이브 패치라기보단 타이틀을 하나 팔고확장팩을 릴리즈하는 것에 가까운 느낌아마도 아직패키지 시장 패러다임에서벗어나지 못했기 때문이 아닐까
돌아보기: LoL게임은 거의 동일했지만웹페이지는 다름한국 유저들에게는확실히 오른쪽이 익숙하고접근성이 좋을것 같다게임도 마찬가지 아닐까?문화, 익숙함, ..
던파 장미칼 패키지 출시!국가별로 같은 내용만 출시해야한다면 이런 컨텐츠 활용이 힘들 것어제 막 나온화제의 장미칼 패키지http://bit.ly/roseknife
다른 게임들은? #2게임C한국을 메인으로 개발하다가중국에서의 선전으로중국을 메인으로 개발이후 모든 국가가개발브랜치로 정기적인 통합통합과정에서의 불안정성이 아직 과제게임 C’해외 진출을 고려한 구조릴리즈용 stable b...
던파 머지 지옥 개선 사례Case Study of ‘Merge Hell’ Improvement
기존 던파의 해외 개발앞서 보았던 두번째 케이스중국 진출! 인증, 빌링 등 초기 셋업 작업 진행중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입중국에 맞는이벤트/컨텐츠를 개발하자작업했던것 다시 머지해넣음불어나는...
대규모 업데이트 하려면국내 대규모 소스를 가져온 후2년~5년간 개발한 것을전부 다시 수동 머지!
“매번 오픈베타하는것 같아요”작업기간 4개월(추가 개발+테스트+릴리즈까지)머지+컴파일+기동에만 한달 이상 소요이대로면 계속 증가나중에는?지속 불가능한 개발 프로세스
지금이라도 원소스?바로앞만 보지말고멀리보고 지금이라도 원소스 가야하나?갈데까지 가버린 느낌이지만…
“그런데, 원소스가 무슨뜻이지?”국가별 서비스개발이 한 소스에서 컴파일?#ifdef 가 모두 제각기 다르게 적용되고 있다면?local copy 나 branch 없이 여러 국가의 freeze & test & release...
브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다1. 패치전 FREEZE 하면 70명 대기?
브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다2. 서비스/패치가 많으면?2011년 10월 실제 던파 서비스 패치 일정
브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다100번 커밋중 한번 정도 빌드를 깨먹는 (컴파일이 안되거나 실행이 안되거나)신중한 개발자들이 개발팀을 꾸렸다.만약 한 브랜치에서 작업한다면:7명 일때 어느...
브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다개발자가 늘어날수록n 과 downtime 이 같이 늘어난다( 안깨먹을 확률은 기하급수적으로 떨어짐 )Loss of Resource = downtime * n...
어쨌든 이 차이는 줄여야한다!브랜치의 차이가 곧 머지 비용,되갚아야 하는 빚(기술채무)이기 때문하지만 아궁이의 불을 꺼뜨릴 수는 없고...한번에 줄일 수 없으면, 한단계씩 가보자
초대형 레거시 프로젝트.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 반영 시점을 선택할 수 있다:...
Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 3:시점을 마음대로 선택할 수 있다국내의 패치에 지장을 덜 주면서QA 테스트 일정과 연계할 수 있도록trunk 반영 시점을 선택할 수 있다:...
Integration Branche.g) 선택했던 베이스 버전을, 나중에 변경하는 경우
Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 4:역할과 책임을 분리할 수 있다오렌지색 작업영역은 국내개발팀에서하늘색 작업영역은 해외개발팀에서 담당하면“우리 영역의 코드만을 머지한다”“우...
다른 속도로 따라가며 integration 가능적당한 단위로 뭉치고바쁘면 다음에각자의 사정에 따라경우에 따라 따라가는 속도의 적절한 조절만으로대량 컨플릭트의 대부분을 줄일수도 있다
새 프로세스의 변화: 작업
새 프로세스의 변화: 브랜치
새 프로세스의 변화: 리팩토링코드가 갈라져있을때는 전반적 리팩토링을 못하거나, 문제가 많았다리팩토링한것이 코드빚이 되어 대규모 머지할때 이자까지 쳐서 고스란히 돌아옴정확히 말하면 대량 수정이 거의 불가
달리는 자동차의 바퀴를 갈아끼우기http://bit.ly/chgtire
“되는데요”
앞으로의 숙제리소스 머지사실 여태까지의 이야기에 리소스 이야기는 빠졌다리소스파일의 SVN 머지도 조금씩 도입중같은 영역에 함께 작업했을때 conflict 이 나지 않고 merge 되는 구조가 중요테스트 안정성통합 시점에...
병렬/라이브 개발 – 팁 & 단상Parallel / Live Development Wisdom
안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수온라인화되고, 게임 수명과 컨텐츠 고갈이 대두되는 모바일 개발에서도 브랜치/병렬 개발이 중요해질것브랜치 없이는서비스가 하나라도개발규모를 일정 이상 키울수 없다 Sid...
적절한 브랜치 사용 예시• 개발용 unstable branch• 소, 중, 대 규모로 구분되는 feature branch• 개발QA테스팅과 함께가는 stable branch• stable branch를 기반으로 한패치날...
통합 주기는 언제가 적절할까?서비스브랜치로의 통합주기는 한달 정도가 적절시간적으로는 자주할수록 유리동시에 작업이 쏟아져들어오면 엔트로피가 급격히 증가하고 안정성이 떨어질 수 있다둘 사이에서 적절한 균형을 잡아야QA/테스...
몇가지 머지 팁feature branch 활용라이브에서 여러명이 동시에 작업할 경우나기존 동작에 영향주는 리팩토링에 특히 유용integration branch 활용사이드 이펙트/컨플릭트 폭탄 없는 다국가 통합시 활용fe...
몇가지 머지 팁브랜치 작업/통합시 side-effect, 브랜치 크기(브랜치 기간)에 따라 적절한 형태를 활용버블파이터 개발당시 feature branch- 3가지 브랜치 형태1 2 3
몇가지 머지 팁svn:mergeinfo 활용SVN merge 를 통해 머지된 내용들에 대한 metadata (svn property)머지된 리비전 관리비용과 중복 머지로 인한 컨플릭트를 줄여준다알아두면 종종 mergei...
테크닉보다 중요한것조직차원의 지속 가능한 작업이 되어야 한다브랜치 작업방식과 머지, 정기적인 통합이 프로세스화 되어야 한다통합에 대해 영역별로 통합을 진행하는 integration 전담자가 있어야 한다던파 사례의 경우 ...
테크닉보다 중요한것규모가 크면 혼자서는 할 수 없다. “함께” 해야함앞선 사례도 수많은 사람들의 협조와 도움, 특히 “머지마스터”들의 도움으로 달성이해관계가 다른 조직간의 조율, 커뮤니케이션, 설득여러 조직의 align...
프로토타이핑 기반 개발 양산형 개발 라이브 초기 해외 진출 라이브 후기게임 개발 단계 전환시기가 기회각 단계 전환을 앞두고 채무점검 & 다음 스테이지에 필요한 구조를 준비이자율 할인의 기회초반 구조를 어떻게 잡느냐에 따...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조Feature Switching#ifdef 를 최소화하고 국가별 차이에일원화된 Feature Switching 구조를 사용개념적으로 Feature Matrix 형...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조국가별 애셋/리소스 관리/머지 도구최대한 머지가 가능한 리소스 포맷과 툴을 사용국가별 사용/패키징 여부를 Feature Matrix 형태로중앙관리할 수 있는 기반...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조점검툴 for SE, DBA퍼블리셔의 DB, 장비에 일반적으로 접근권한이 없고커뮤니케이션 장벽의 퍼블리셔의 SE 를 통해야한다적지않은 해외 서비스 불안정은 점검시...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조보안 운영툴보안은 개발과 운영의 영역이 겹쳐있음개발만으로 운영의 영역을 커버하지 못한다퍼블리셔측에서 GM운영 뿐 아니라 보안 운영 또한 가능하도록자동 제재 리얼타...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조로그/통계 수집 구조(Telemetry)라이브 서비스를 시작하면 늘 통계적인 분석을 필요매번 반복되는 로그/수집을 일원화하면 큰 도움이 된다부하를 신경쓰지 않아도...
많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조컨텐츠를 뺄 수 있는 구조라이브 개발이 지속되면 개발 내용은 쌓이지만정작 무거워진 로딩시간이나 메모리 부족 현상에 봉착했을 때정작 원하는 내용이나 사용하지 않는 ...
조직구성의 고민과 함께 가야한다해외 라이브를 진행하면 조직 R&R 이 겹치기 시작ex) 개발부서에서도 기획, 서비스부서에서도 기획에서도 제안하거나 기획중국 서비스에 나가는 내용은 개발팀도 개발하고 중국개발에서도 개발
조직구성의 고민과 함께 가야한다서비스 응집성 vs 개발팀 응집성?서비스 중심으로 조직을 구성 긴밀한 개발 커뮤니케이션으로 부족한 개발 응집성을 높이고,개발 중심으로 조직을 구성하면 긴밀한 서비스 커뮤니케이션으로 부족한 ...
마치며Conclusion
일명 “원소스” 논쟁합치려는 포스보통 개발쪽의 의지따로 브랜치 따면 당장은 편하지나중에 결국 머지 다 해야해요지금 당장 편하자고 갈라서면나중에 개고생해요나중에 합칠때 서로 안맞는건 어떡하려고갈라지려는 포스보통 서비스쪽의...
1. 대규모 개발에 브랜치는 필수안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수
2. 정답은 없다 - 개발기조하지만 현명한 선택은 중간 어디엔가 있다모든 국가에 똑같이 서비스개발응집성이 늘어나Technical Debt 을 줄일 수 있다컨텐츠가 따로놀지 않고 일관성을 갖는다여러 국가별로 다양한 이슈 ...
3. 정답은 없다 - 조직구성하지만 현명한 선택은 중간 어디엔가 있다1개의 개발조직 vs 서비스조직개발팀 응집성을 늘려 Technical Debt 을 줄일 수 있고컨텐츠가 따로놀지 않고 일관성을 갖지만국가별 상황/이슈 ...
라이브 서비스 메타포아궁이불때기소방관불끄기빚빚갚기
아궁이라이브 서비스는 아궁이 지키기관심 아궁이재미 아궁이컨텐츠 아궁이한번 꺼지면 다시 붙이기 힘들다꺼지지 않게 잘 지켜줘야한다땔감 공급해주고비바람에 꺼지지 않게“갈망의 아궁이” by 김동건
소방관주변에 불이 붙으면홀랑 태워먹고 망할 수 있다무적핵, 각종 핵툴복사버그계정해킹악성여론
서비스 vs 개발서비스조직은 불을 지키고 개발조직은 땔감을 마련나무 하고 장작 패고물도 길어와서 불도 끄고빚낸거 이자쳐서 갚아나가고
서로 다른 아궁이(서비스)의 불을 지키기 위해서는..땔감을 구하는것도 좋지만아궁이에 불이 꺼지지 않게,화재시엔 빠르게 불끄는게 중요서비스팀이 개발팀에 설득.강조해야하는 부분아무리 좋은 땔감(컨텐츠, 기술)을 마련해도불이...
감사합니다다른곳에서는 경험할 수 없는거대한 스케일의 유저, 코드, 개발을 경험하고싶다면그리고 그것을 개선시키고 더 좋은 서비스로 만들어 높은 부가가치를 창출하고싶다면시니어들을 위한 크나큰 도전과 경험의 땅 네오플로!
[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발 관리) - 송창규
[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발 관리) - 송창규
[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발 관리) - 송창규
Upcoming SlideShare
Loading in …5
×

[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발 관리) - 송창규

스피커덱에서 좀더 좋은 화질의 버전을 보실 수 있습니다:
http://bit.ly/gamelivedev2

  • Be the first to comment

[NDC13] 70명이 커밋하는 라이브 개발하기 (해외 진출 라이브 프로젝트의 개발 관리) - 송창규

  1. 1. 70명이 커밋하는 라이브 개발하기해외 진출 라이브 프로젝트의 개발 관리Neople송창규
  2. 2. “70 commiters in a single project?”“ㅇㅇ”http://bit.ly/dnfcommits2013/4/16단 하루 커밋
  3. 3. 소개송창규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 테크니컬 디렉팅
  4. 4. 대상해외 라이브 개발에 참여하고있는(혹은 병렬 개발 파이프라인에 관심이 있는)시니어 프로그래머 / 관리자 / 프로듀서Production / Programming Track
  5. 5. 순서라이브 게임개발 시나리오던파 머지 지옥 개선 사례병렬/라이브 개발 – 팁 & 단상마치며
  6. 6. “MERGE HELL”
  7. 7. 라이브 게임개발 시나리오Live Game Development Scenario
  8. 8. 흔한 초기 해외진출 시나리오한국 서비스 성공적으로 런칭 완료!“중국 서비스를 위해 중국 버전 만들자!”
  9. 9. 그리고 1년 후…해외 작업자는 머지옥 (MERGE HELL) 을 경험
  10. 10. MERGE HELLCase #1중국 진출하자!
  11. 11. MERGE HELLCase #1중국 진출하자!따라가야할 양이 너무 많다갈수록 머지가 힘겨워진다부분만 반영되어 다른 소스순서가 다르게 적용되어 반영이 될 수 없는 소스
  12. 12. Technical Debt (기술채무)Code Debt(코드빚) 이라고도 함일반적인 발생요인비즈니스 압력이나하드코딩/커플링,원활한 협업이나 이해부족,리팩토링 지연 등쌓여가는 머지 부담도 Technical Debt 의 하나
  13. 13. 아예 개발된 대규모 컨텐츠를 다 가져오면..중국 진출!로컬라이징, 중국용 이벤트/컨텐츠를 개발추가된 한국 컨텐츠를 한번에 가져오자중국에 맞는이벤트/컨텐츠를 개발하자중국에 넣었던 컨텐츠 다시 머지
  14. 14. MERGE HELLCase #2중국 진출! 인증, 빌링 등 초기 셋업 작업 진행중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입중국에 맞는이벤트/컨텐츠를 개발하자작업했던것 다시 머지해넣음불어나는 빚: 처음부터 다시 머지해넣는다중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입OB수준의 대량 테스트/문제해결OB수준의 대량 테스트/문제해결OB수준의 대량 테스트/문제해결
  15. 15. 다른 게임들은?게임M진출시부터 나라별 분리된 소스머지 헬을 겪고 원소스로 합침서비스별 개발조직 분리로 소스분리게임K옆 프로젝트의 머지 헬을반면교사삼아해외진출 초기부터 원소스 유지서비스별 조직분리로국가별 소스 분리 (x2)다시 원소스로 합침 (x2)
  16. 16. 반복되는 역사. 정답은?원소스“합치자”브랜치“갈라서”
  17. 17. 합치려는 포스보통 개발쪽의 의지따로 브랜치 따면 당장은 편하지나중에 결국 머지 다 해야해요지금 당장 편하자고 갈라서면나중에 개고생해요나중에 합칠때 서로 안맞는건 어떡하려고
  18. 18. 갈라지려는 포스보통 서비스쪽의 의지지표가 떨어지고 있어 빨리 패치해야해지금 못한다고? 우리 작업이 늦춰지잖아우리 서버가 죽은 이유가 저쪽에서 로그 심다가 그런거라고?이 나라에 맞는 컨텐츠를 직접 개발하고싶어
  19. 19. 경험자들이 흔히 하는 말“나중에 개발에서 퍼져요결국 해외 구조 고려해서원소스가야죠”
  20. 20. 모범사례격인 매이저 게임들은어떻게 하고 있을까?
  21. 21. WoW동일한 패치내용이거의 동시에 릴리즈심지어 웹페이지도 동일
  22. 22. LoL마찬가지로패치내용 거의동일국가간 패치 시점 1주일 이내PvP 특성상컨텐츠 추가보다는밸런스 조정 위주웹페이지는 한국 특성에 맞게 바꿨군…
  23. 23. 확실히 오른쪽이 괜찮아 보인다
  24. 24. 과연 정답일까?이쯤되면 저게 맞는것 같은데…(가급적) 동일한 내용으로 동일한 시기에모든 나라에 릴리즈하는게 정답일까?
  25. 25. 문화/성향이 다름“국가별 게이머 종족특성” by onesound
  26. 26. 나라별 상황도, 공략 포인트도 다르다중고등학생 중심PvP 비활성게임머니 현금결제 불가…일본소수의 마니아층 위주PvP 비활성뽑기와 조합맞추기싱글플레이 선호중국대중적인 국민게임PvP 활성화게임머니 현금결제창모드, 채팅창 분리 선호
  27. 27. 상황에 따라 우선순위, 전략도 제각기한국에서는 이탈이 진행되어 귀환과 정착에 집중중국에서는 대부분 만렙이라 컨텐츠가 고갈된 상황
  28. 28. 시즌 특수 타이밍도 다르다크리스마스, 설날, 추석, ..할로윈은 별로..일본골든위크, ..중국춘절, 국경절, 노동절, ..크리스마스는 별로..
  29. 29. 유저/매출 비중도 다르다매출일본한국중국기타동접일본한국중국기타이해를 돕기위해 대강 느낌상 차이를 표현한 다이어그램입니다
  30. 30. 돌아보기: WoW3개만 내려가도시차 1년 이상약 3~4개월마다대규모 패치 릴리즈라이브 패치라기보단 타이틀을 하나 팔고확장팩을 릴리즈하는 것에 가까운 느낌아마도 아직패키지 시장 패러다임에서벗어나지 못했기 때문이 아닐까
  31. 31. 돌아보기: LoL게임은 거의 동일했지만웹페이지는 다름한국 유저들에게는확실히 오른쪽이 익숙하고접근성이 좋을것 같다게임도 마찬가지 아닐까?문화, 익숙함, ..
  32. 32. 던파 장미칼 패키지 출시!국가별로 같은 내용만 출시해야한다면 이런 컨텐츠 활용이 힘들 것어제 막 나온화제의 장미칼 패키지http://bit.ly/roseknife
  33. 33. 다른 게임들은? #2게임C한국을 메인으로 개발하다가중국에서의 선전으로중국을 메인으로 개발이후 모든 국가가개발브랜치로 정기적인 통합통합과정에서의 불안정성이 아직 과제게임 C’해외 진출을 고려한 구조릴리즈용 stable branch가 있고그 외의 것은 메인 개발 브랜치에서 개발국가별 차이를 Feature Switch 로 구현테스트와 안정성을 위해릴리즈/브랜치 구조 개선(프로세스 개선에 약 1년 소요)
  34. 34. 던파 머지 지옥 개선 사례Case Study of ‘Merge Hell’ Improvement
  35. 35. 기존 던파의 해외 개발앞서 보았던 두번째 케이스중국 진출! 인증, 빌링 등 초기 셋업 작업 진행중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입중국에 맞는이벤트/컨텐츠를 개발하자작업했던것 다시 머지해넣음불어나는 빚: 처음부터 다시 머지해넣는다중국에 맞는이벤트/컨텐츠를 개발하자한국 대규모 컨텐츠 도입OB수준의 대량 테스트/문제해결OB수준의 대량 테스트/문제해결OB수준의 대량 테스트/문제해결
  36. 36. 대규모 업데이트 하려면국내 대규모 소스를 가져온 후2년~5년간 개발한 것을전부 다시 수동 머지!
  37. 37. “매번 오픈베타하는것 같아요”작업기간 4개월(추가 개발+테스트+릴리즈까지)머지+컴파일+기동에만 한달 이상 소요이대로면 계속 증가나중에는?지속 불가능한 개발 프로세스
  38. 38. 지금이라도 원소스?바로앞만 보지말고멀리보고 지금이라도 원소스 가야하나?갈데까지 가버린 느낌이지만…
  39. 39. “그런데, 원소스가 무슨뜻이지?”국가별 서비스개발이 한 소스에서 컴파일?#ifdef 가 모두 제각기 다르게 적용되고 있다면?local copy 나 branch 없이 여러 국가의 freeze & test & release 가 가능한가?브랜치를 사용 안하는것?QA테스트와 릴리즈시에 브랜치 사용하면 원소스 아닌가?피처 브랜치 사용하면 원소스 아닌가?패치를 위해 커밋한 내용이 다른나라서비스에 영향을 주는지?한국에 커밋된 내용은 다른나라에 영향을 주지만,중국에 커밋된 내용은 한국에 영향을 안준다면?혹은 영향을 주지만, 6개월 후에 영향을 준다면?사실, 차이가 크게 나는 브랜치의 반대 형태를 막연하게 지칭하는 말
  40. 40. 브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다1. 패치전 FREEZE 하면 70명 대기?
  41. 41. 브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다2. 서비스/패치가 많으면?2011년 10월 실제 던파 서비스 패치 일정
  42. 42. 브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다100번 커밋중 한번 정도 빌드를 깨먹는 (컴파일이 안되거나 실행이 안되거나)신중한 개발자들이 개발팀을 꾸렸다.만약 한 브랜치에서 작업한다면:7명 일때 어느 하루 빌드가 깨질 확률은 약 20%70명 일때 어느 하루 빌드가 깨질 확률은 약 90%지나치게 단순화시키긴 했지만작업자에 따라 급격하게 떨어지는안정성을 설명 가능
  43. 43. 브랜치를 사용하지 않으면..개발규모에 Scalable 하지 않다개발자가 늘어날수록n 과 downtime 이 같이 늘어난다( 안깨먹을 확률은 기하급수적으로 떨어짐 )Loss of Resource = downtime * n (no. of developers)경험상 같은 영역의 개발조직에 개발자 10명이 넘어가면 병목이 심해지기 시작Side-effect Downtime Bottleneck
  44. 44. 어쨌든 이 차이는 줄여야한다!브랜치의 차이가 곧 머지 비용,되갚아야 하는 빚(기술채무)이기 때문하지만 아궁이의 불을 꺼뜨릴 수는 없고...한번에 줄일 수 없으면, 한단계씩 가보자
  45. 45. 초대형 레거시 프로젝트.cpp + .h 파일수 4319+5680 = 9999파일 (2012년말 당시)전체 라인수: 40만줄 (빈칸/코멘트 제외 30만줄)
  46. 46. 프로그래머 70 명
  47. 47. 독립적으로 돌아가는 개발조직: 당시 7개서비스, QA, SE 등 포함하면 훨씬 많음..국내개발서버개발라이브 클라개발컨텐츠 클라개발해외개발중국개발일본개발인프라개발보안개발
  48. 48. 한달 공식 패치 횟수: 19회한국 1주일 2회 (테섭/실섭)일본 2주일 1회미국 2주일 1회중국 2주일 1~2회
  49. 49. 미칠듯한 커밋속도!!1~2분에 한번 꼴로 커밋리비전 10만 돌파
  50. 50. 대통합 도전!달리는 자동차의 바퀴를 갈아끼우기
  51. 51. 일단 머지 도구사용부터 전파Ctrl+C, Ctrl+V, 더 이상은 naver...
  52. 52. 기존 해외 대규모 개발메인 브랜치를 따와서예전 개발된 내용들을모두 다시 머지실섭은 별도로 운영하다가나중에 따로 추가 머지머지해야할 내용이 점점 증식
  53. 53. 기존 해외 대규모 개발2개 국가의 경우
  54. 54. 전부 trunk 로 머지?가령 이렇게?“이러면 한번만 머지해도 될거야..”“처음부터 전부 다시 머지는더 이상은.. naver..”
  55. 55. 생각처럼 쉽지 않다문제1한국 서비스 불안정 유발문제2해외 대규모 버전의 베이스 버전 선택 문제한국 서비스가 해외의 사이드 이펙트로 불안정해지지 않아야하듯, 해외 서비스도 한국 서비스로 불안정해지지 않아야함리소스 파일 작업 동기화
  56. 56. 역머지 브랜치를 하나 생성사이드 이펙트로 인한 국내 불안정 방지해외 서비스도안정 버전을 선택후이후 개발로부터의사이드 이펙트 격리
  57. 57. trunk 로 머지하면대망의 전국가 통합이?!
  58. 58. 문제1: more conflicts코드 거리가 그새 또 벌어짐이미 2개월도 안되어conflict 다량 발생거리가 이미 많이 벌어져있다시간차: 4개월작업량: 4개월*약40명
  59. 59. 문제2: stability대량 conflict 를 한꺼번에resolve / commit 하는 부담모두 resolve 후컴파일이 되었더라도실행이 깨진 상태이기 쉽다
  60. 60. 문제2: R&R국내 개발 조직과해외 개발 조직은 별도의 조직“이거 왜 실행안돼?”“해외쪽에서 커밋했더니..”“@#$@#$!!”
  61. 61. Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 1:양쪽 내용이 전부 통합되지만작업 브랜치에 사이드이펙트가 없다SVN reintegrate
  62. 62. Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 2:conflict & merge 가한번에 발생하지 않고 분산된다( 리스크 분산, 머지 부담 감소 )
  63. 63. Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 3:시점을 마음대로 선택할 수 있다국내의 패치에 지장을 덜 주면서QA 테스트 일정과 연계할 수 있도록trunk 반영 시점을 선택할 수 있다:“conflict 걱정없이 atomic 하게 reintegrate”안정성 등의 이유로 중간에 계획이 바뀌더라도global (work) 의 베이스 시점을 나중에 바꿀 수도 있음
  64. 64. Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 3:시점을 마음대로 선택할 수 있다국내의 패치에 지장을 덜 주면서QA 테스트 일정과 연계할 수 있도록trunk 반영 시점을 선택할 수 있다:“conflict 걱정없이 atomic 하게 reintegrate”안정성 등의 이유로 중간에 계획이 바뀌더라도global (work) 의 베이스 시점을 나중에 바꿀 수도 있음
  65. 65. Integration Branche.g) 선택했던 베이스 버전을, 나중에 변경하는 경우
  66. 66. Integration Branch“따라가는 브랜치”양쪽에서 머지해 들어오기장점 4:역할과 책임을 분리할 수 있다오렌지색 작업영역은 국내개발팀에서하늘색 작업영역은 해외개발팀에서 담당하면“우리 영역의 코드만을 머지한다”“우리 영역의 코드에 머지한다” 가 명확해진다우리영역 너네영역이 어딨겠냐만은..인원이 많고 조직이 크고 라이브 서비스에 영향을 주면 때론 R&R 영역구분이 중요하다
  67. 67. 다른 속도로 따라가며 integration 가능적당한 단위로 뭉치고바쁘면 다음에각자의 사정에 따라경우에 따라 따라가는 속도의 적절한 조절만으로대량 컨플릭트의 대부분을 줄일수도 있다
  68. 68. 새 프로세스의 변화: 작업
  69. 69. 새 프로세스의 변화: 브랜치
  70. 70. 새 프로세스의 변화: 리팩토링코드가 갈라져있을때는 전반적 리팩토링을 못하거나, 문제가 많았다리팩토링한것이 코드빚이 되어 대규모 머지할때 이자까지 쳐서 고스란히 돌아옴정확히 말하면 대량 수정이 거의 불가
  71. 71. 달리는 자동차의 바퀴를 갈아끼우기http://bit.ly/chgtire
  72. 72. “되는데요”
  73. 73. 앞으로의 숙제리소스 머지사실 여태까지의 이야기에 리소스 이야기는 빠졌다리소스파일의 SVN 머지도 조금씩 도입중같은 영역에 함께 작업했을때 conflict 이 나지 않고 merge 되는 구조가 중요테스트 안정성통합 시점에 엔트로피가 급증하고 안정성이 떨어지는 시기를 수반리소스, DB 등 다른 시스템과의 정합성을 맞추고,중간 통합을 초기부터 바로바로 하고,머지 누락을 자동화하여 체크하는 등 개선을 시도
  74. 74. 병렬/라이브 개발 – 팁 & 단상Parallel / Live Development Wisdom
  75. 75. 안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수온라인화되고, 게임 수명과 컨텐츠 고갈이 대두되는 모바일 개발에서도 브랜치/병렬 개발이 중요해질것브랜치 없이는서비스가 하나라도개발규모를 일정 이상 키울수 없다 Side-effect Downtime Bottleneck
  76. 76. 적절한 브랜치 사용 예시• 개발용 unstable branch• 소, 중, 대 규모로 구분되는 feature branch• 개발QA테스팅과 함께가는 stable branch• stable branch를 기반으로 한패치날짜별 staging branch, release branchstaging 브랜치는 패치 전 테스트용release 브랜치는 실섭 버그픽스/장애 대응용 hotfix 개발역할의 분리일뿐 같은 브랜치 사용이 편리“Guild Wars 2는20개의 feature branch team 를 운영하지요”- “Guild Wars 2: Scaling from One to Millions, GDC2013
  77. 77. 통합 주기는 언제가 적절할까?서비스브랜치로의 통합주기는 한달 정도가 적절시간적으로는 자주할수록 유리동시에 작업이 쏟아져들어오면 엔트로피가 급격히 증가하고 안정성이 떨어질 수 있다둘 사이에서 적절한 균형을 잡아야QA/테스트 프로세스에 맞춘 불안정/안정 관리가 주기 선정에 있어 중요Integration Branch 를 활용하면 좀더 선택의 폭이 넓어짐side-effect 제어시점 제어길어야 6개월 이내가 되도록안그러면 영영 멀어질수도 있다
  78. 78. 몇가지 머지 팁feature branch 활용라이브에서 여러명이 동시에 작업할 경우나기존 동작에 영향주는 리팩토링에 특히 유용integration branch 활용사이드 이펙트/컨플릭트 폭탄 없는 다국가 통합시 활용feature branch 를 장기간으로 진행시에도 유용하게 활용 가능버블파이터 개발당시 feature branch
  79. 79. 몇가지 머지 팁브랜치 작업/통합시 side-effect, 브랜치 크기(브랜치 기간)에 따라 적절한 형태를 활용버블파이터 개발당시 feature branch- 3가지 브랜치 형태1 2 3
  80. 80. 몇가지 머지 팁svn:mergeinfo 활용SVN merge 를 통해 머지된 내용들에 대한 metadata (svn property)머지된 리비전 관리비용과 중복 머지로 인한 컨플릭트를 줄여준다알아두면 종종 mergeinfo 수작업을 통한 활용으로 시간을 많이 아낄 수 있다svn reintegrate 시에는 모든 내용이 머지되어있어야 하므로 직접 채워줘야할 수 있음대규모 리팩토링/Find & Replace All in Files 같이 컨플릭트를 많이 유발하는 작업의 경우의미적으로 같은 작업을 모든 브랜치에 적용하고 서브 브랜치에 mergeinfo 를 넣어줌으로서독립 브랜치를 유지하면서 컨플릭트를 드라마틱하게 낮출 수 있다버블파이터 개발당시 feature branch
  81. 81. 테크닉보다 중요한것조직차원의 지속 가능한 작업이 되어야 한다브랜치 작업방식과 머지, 정기적인 통합이 프로세스화 되어야 한다통합에 대해 영역별로 통합을 진행하는 integration 전담자가 있어야 한다던파 사례의 경우 조직별 머지 담당자가 없었으면 통합이 불가능했을것
  82. 82. 테크닉보다 중요한것규모가 크면 혼자서는 할 수 없다. “함께” 해야함앞선 사례도 수많은 사람들의 협조와 도움, 특히 “머지마스터”들의 도움으로 달성이해관계가 다른 조직간의 조율, 커뮤니케이션, 설득여러 조직의 alignment: 반복적인 방향 공유
  83. 83. 프로토타이핑 기반 개발 양산형 개발 라이브 초기 해외 진출 라이브 후기게임 개발 단계 전환시기가 기회각 단계 전환을 앞두고 채무점검 & 다음 스테이지에 필요한 구조를 준비이자율 할인의 기회초반 구조를 어떻게 잡느냐에 따라 이후 개발에서 큰 차이가 나타날때가 많다초반에 잡지 않은 구조를 라이브 단계에서 다잡는것은 매우 힘겨운일너무 이른 시점에 너무 후반을 위해 많은 리소스를 들이는것도 현명하지는 않음
  84. 84. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조Feature Switching#ifdef 를 최소화하고 국가별 차이에일원화된 Feature Switching 구조를 사용개념적으로 Feature Matrix 형태를 형성그렇다고 국가별 파일을 가르지 않고 전체 매트릭스를 하나의 파일로 관리하면 재앙이 올것이야..ON/OFF 뿐 아니라 피처 버전이나 실장날짜가 들어가면 유용
  85. 85. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조국가별 애셋/리소스 관리/머지 도구최대한 머지가 가능한 리소스 포맷과 툴을 사용국가별 사용/패키징 여부를 Feature Matrix 형태로중앙관리할 수 있는 기반이나 도구를 장만버전 차이로 인해 어려운 완전 자동화를 노리기보다는 머지가 쉬운 포맷과국가별 사용/패키지 여부를 관리하는 도구를 장만하는 쪽이 현명관련자료 GDC 2013,“Working Together”
  86. 86. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조점검툴 for SE, DBA퍼블리셔의 DB, 장비에 일반적으로 접근권한이 없고커뮤니케이션 장벽의 퍼블리셔의 SE 를 통해야한다적지않은 해외 서비스 불안정은 점검시SE 커뮤니케이션/작업실수에서 비롯ex) DB schema 버저닝, 원클릭 설정, 상태 체크 등..
  87. 87. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조보안 운영툴보안은 개발과 운영의 영역이 겹쳐있음개발만으로 운영의 영역을 커버하지 못한다퍼블리셔측에서 GM운영 뿐 아니라 보안 운영 또한 가능하도록자동 제재 리얼타임 반영이 가능한 운영툴 필요
  88. 88. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조로그/통계 수집 구조(Telemetry)라이브 서비스를 시작하면 늘 통계적인 분석을 필요매번 반복되는 로그/수집을 일원화하면 큰 도움이 된다부하를 신경쓰지 않아도 되는 수집 인터페이스정규화되고 대칭적인 로그/포맷공통 필드를 정해놓고 tab 으로 구분하기만 해도 큰 도움이 된다
  89. 89. 많이 알려져있지 않으면서라이브 중반 이후 중요한 기술 구조컨텐츠를 뺄 수 있는 구조라이브 개발이 지속되면 개발 내용은 쌓이지만정작 무거워진 로딩시간이나 메모리 부족 현상에 봉착했을 때정작 원하는 내용이나 사용하지 않는 내용을 지우기는 굉장히 힘들다컨텐츠단위로 소스/리소스를 선택하거나 뺄 수 있는것이 중요리소스/애셋관리 하부에 공통 weak referencing 기능이 있으면 유용
  90. 90. 조직구성의 고민과 함께 가야한다해외 라이브를 진행하면 조직 R&R 이 겹치기 시작ex) 개발부서에서도 기획, 서비스부서에서도 기획에서도 제안하거나 기획중국 서비스에 나가는 내용은 개발팀도 개발하고 중국개발에서도 개발
  91. 91. 조직구성의 고민과 함께 가야한다서비스 응집성 vs 개발팀 응집성?서비스 중심으로 조직을 구성 긴밀한 개발 커뮤니케이션으로 부족한 개발 응집성을 높이고,개발 중심으로 조직을 구성하면 긴밀한 서비스 커뮤니케이션으로 부족한 서비스 응집성을 높여야한다
  92. 92. 마치며Conclusion
  93. 93. 일명 “원소스” 논쟁합치려는 포스보통 개발쪽의 의지따로 브랜치 따면 당장은 편하지나중에 결국 머지 다 해야해요지금 당장 편하자고 갈라서면나중에 개고생해요나중에 합칠때 서로 안맞는건 어떡하려고갈라지려는 포스보통 서비스쪽의 의지지표가 떨어지고 있어 빨리 패치해야해지금 못한다고? 우리 작업이 늦춰지잖아우리 서버가 죽은 이유가 저쪽에서 로그 심다가 그런거라고?이 나라에 맞는 컨텐츠를 직접 개발하고싶어
  94. 94. 1. 대규모 개발에 브랜치는 필수안정성 확보와 병렬개발 극대화를 위해서는 브랜치가 필수
  95. 95. 2. 정답은 없다 - 개발기조하지만 현명한 선택은 중간 어디엔가 있다모든 국가에 똑같이 서비스개발응집성이 늘어나Technical Debt 을 줄일 수 있다컨텐츠가 따로놀지 않고 일관성을 갖는다여러 국가별로 다양한 이슈 대응이기민하고 유연하지 못하기 쉽다국가별 상황과 특징에 맞춰 개발국가별로 상황/이슈 대응이 유연하지만활발한 개발직군 커뮤니케이션 등을 통해개발 응집성을 충분히 갖추지 못하면이자와 함께 빚이 눈덩이처럼 불어날 수 있음던파의 경우 Technical Debt 부담이 크지만,한편 중국 서비스 성공 요소에는기민하고 유연한 서비스 대응과중국서비스-중국개발의 긴밀함이 기반되었다고도 볼 수 있다
  96. 96. 3. 정답은 없다 - 조직구성하지만 현명한 선택은 중간 어디엔가 있다1개의 개발조직 vs 서비스조직개발팀 응집성을 늘려 Technical Debt 을 줄일 수 있고컨텐츠가 따로놀지 않고 일관성을 갖지만국가별 상황/이슈 대응이 기민하고 유연하지 못하고조직 R&R 이 모호해진다서비스별 개발조직 분리국가별로 상황/이슈 대응이 유연하지만활발한 개발직군 커뮤니케이션 등을 통해개발 응집성을 충분히 갖추지 못하면이자와 함께 빚이 눈덩이처럼 불어날 수 있음
  97. 97. 라이브 서비스 메타포아궁이불때기소방관불끄기빚빚갚기
  98. 98. 아궁이라이브 서비스는 아궁이 지키기관심 아궁이재미 아궁이컨텐츠 아궁이한번 꺼지면 다시 붙이기 힘들다꺼지지 않게 잘 지켜줘야한다땔감 공급해주고비바람에 꺼지지 않게“갈망의 아궁이” by 김동건
  99. 99. 소방관주변에 불이 붙으면홀랑 태워먹고 망할 수 있다무적핵, 각종 핵툴복사버그계정해킹악성여론
  100. 100. 서비스 vs 개발서비스조직은 불을 지키고 개발조직은 땔감을 마련나무 하고 장작 패고물도 길어와서 불도 끄고빚낸거 이자쳐서 갚아나가고
  101. 101. 서로 다른 아궁이(서비스)의 불을 지키기 위해서는..땔감을 구하는것도 좋지만아궁이에 불이 꺼지지 않게,화재시엔 빠르게 불끄는게 중요서비스팀이 개발팀에 설득.강조해야하는 부분아무리 좋은 땔감(컨텐츠, 기술)을 마련해도불이 꺼지면(유저가 떠나면) 모든건 끝이다당장 필요한 것들에 치중해서구조를 개선하고 빚갚는데 소홀하면늘어나는 이자로 빚더미에 앉고 파산할 수 있다개발팀이 다른 직군에게 설득.강조해야하는 부분빚내고 이자가 늘어나는 개념으로 설명하면비개발 사람들에게 쉽게 전달.설득 가능
  102. 102. 감사합니다다른곳에서는 경험할 수 없는거대한 스케일의 유저, 코드, 개발을 경험하고싶다면그리고 그것을 개선시키고 더 좋은 서비스로 만들어 높은 부가가치를 창출하고싶다면시니어들을 위한 크나큰 도전과 경험의 땅 네오플로!

    Be the first to comment

    Login to see the comments

  • jungsuksong9

    Jun. 25, 2015
  • zelonion

    Jun. 26, 2015
  • cyberhoon

    Jul. 21, 2015
  • jeeyunlee54

    Aug. 15, 2015
  • joobn

    Sep. 10, 2015
  • ssuser65f1b01

    Dec. 28, 2015
  • paemato

    Jan. 2, 2016
  • dfdgsdfg

    Jan. 18, 2016
  • Stride9

    Mar. 15, 2016
  • jeongrokoh14

    Apr. 4, 2016
  • savage69kk

    Jul. 21, 2016
  • seokhyunchoi75

    Oct. 6, 2016
  • nermes

    Oct. 26, 2016
  • mwing58

    Feb. 26, 2017
  • skfhddlg

    Apr. 20, 2018
  • ssusercf7829

    Jun. 25, 2018
  • SeungHoJang1

    Nov. 9, 2018
  • ssuser7bca2e

    Apr. 25, 2019
  • paxvobis1

    Jun. 2, 2019
  • ssusera0dfae

    Nov. 11, 2019

스피커덱에서 좀더 좋은 화질의 버전을 보실 수 있습니다: http://bit.ly/gamelivedev2

Views

Total views

9,123

On Slideshare

0

From embeds

0

Number of embeds

67

Actions

Downloads

123

Shares

0

Comments

0

Likes

46

×