SlideShare a Scribd company logo
1 of 77
개발사는 모르는 퍼블리셔의 뒷 이야기
프로그래머의 시선으로 바라본다.
Nexon America
김영현 David Kim
웹 프로그래머
네트워크 프로그래머
클라이언트 프로그래머
김영현(David Kim)
소개
프로그램 팀장
웹 팀장
기술 팀장 소싱 매니져
프로젝트 매니져
프로듀서
Senior Technical Operations Engineer
(약 15년간…)
Nexon America
(출처 : https://zapier.com/blog/aral-balkan-design-talk/)
플러그를 꽂을 수
있게 바꿔주세요.
테이블 다 뜯어야
하고, 어렵습니다.
사용자가 요청이
많습니다. 왜 그런걸 쓴답니까..
맞는 걸 쓰라고 하세요.
소리없이 사용자 감소
매출 감소
서비스 중단
원인분석의 난항
왜… 이런일이 벌어질까?
(출처 : http://www.gettingagile.com/2012/03/04/the-stability-index-focusing-on-release-stabilization/)
(假定)연 120억 매출 게임 (5hrs maint. bi-weekly)
연 1억 7천 8백만원 패치로 인한 매출 손실
연봉 5천만원 개발자 3명 + 치맥
비용 : 돈+사람의 노력+스트레스
20번의 점검
74시간
서비스를 위한 개발 요청
컨텐츠 개발 지연
안정성 감소
완성도/생산성 감소
(출처 : http://www.dongabiz.com/ASP/SKENO/article_view.php?atno=1102027101&chap_no=1&category_group=/)
자극적인 업데이트
개발사 스트레스
유저 스트레스
퍼블리셔 스트레스
(출처 : http://blog.skenergy.com/752, http://www.workingschool.net/21, http://jjalm.tistory.com/98,
http://anotherstep.ruzuku.com/your-online-course-business-needs-focus/)
하고 싶은 이야기들…
추려낸 할 이야기들…
가입 인스톨 로그인 플레이
게임을
접하고 접속하는 유저를 따라가 봅시다.
(출처 : http://www.australiangeographic.com.au/outdoor/guides/2010/05/guide-to-insurance-for-adventure-travel/)
(출처 : http://www.ohmynews.com/NWS_Web/view/at_pg.aspx?CNTN_CD=A0001310307)
(출처 : http://www.lotteimall.com/goods/viewGoodsDetail.lotte?goods_no=9387707
http://m.ppomppu.co.kr/new/bbs_view.php?id=oversea&no=428600)
가입
클라이언트 인스톨
다운로드
클라이언트 패치
게임 로그인
게임 서버 접속
크래시 발생
이벤트
파일 구성은 간결하게!
Keep It Short and Simple
(출처 : http://threestory.tistory.com/14)
인스톨 하다가 포기
패치 하다가 문제 발생
용량 많아서 포기
하드디스크 느려서 포기
(출처 : http://geoffblades.com/most-people-should-give-up-on-what-they-want/)
(참고 : http://www.slideshare.net/slideshow/embed_code/key/lOtZPsSUBtfbVp)
클라 데이터 파일을 서버 데이터 파일로 그대로 사용?
 서버 배포시간 증가 + 서버 로딩 시간 증가
 점검 시간 증가
(출처 : http://m.blog.daum.net/dw0179/486)
가입
클라이언트 인스톨
다운로드
게임 로그인
게임 서버 접속
크래시 발생
이벤트
클라이언트 패치
패치는 유저의 편의를 위해서
(출처 : http://elvg.ch/entspannung/entwicklung.php)
버전만 검사
패치서버
1016to1021
1017to1021
1018to1021
1019to1021
1020to1021
PatchFile1018to1021
Version. 1018
Version. 1021
버전확인
다운로드 및 패치
문제점 1
버전이 오래 되었을 경우 : 풀버전 재설치
문제점 2.
버전은 같으나 파일이 손상되었을 경우 : 재설치
문제점 3.
패치 클라이언트 만드는 데에 많은 시간 소요
패치서버
1021파일(압축)
Monster.pak
SoundA.pak
Game.exe
Version. 1018
Version. 1021
버전 및 파일리스트 확인
다른 파일만 다운로드 및 패치
버전 검사 + 파일 검사 (다르면 다른 파일만 패치)
파일리스트
파일리스트 파일명
생성일자/시간(UTC)
파일사이즈
(option : Checksum)
가벼운 사이즈
Monster.pkg 2014.03.02 15:00:06
Character.pkg 2014.03.01 09:00:06
…
Monster.pkg 2014.03.02 14:00:06
Character.pkg 2014.03.01 08:00:06
…
Monster.pkg 2014.03.02 15:00:06
Character.pkg 2014.03.01 09:00:06
…
패치 서버 유저 PC
Download ALL files
장점 :
파일 손상이더라도 해당 파일만 복구가능
오래된 버전도 다른 파일만 패치
패치 클라이언트 제작 시간 축소
DIFF patch
DIFF01
DIFF02
v. 141v. 140
DIFF01
DIFF02
Patch set
v. 140
DIFF01
DIFF02
v. 141
가입
클라이언트 인스톨
다운로드
게임 서버 접속
크래시 발생
이벤트
게임 로그인
클라이언트 패치
광고 가입 로그인 플레이
끊어진 유저의 흐름 이을 수 있게 해주세요
(출처 :http://blog.daum.net/sonnaa40)
수동
비교
… … AdCode
Player001 … FB020
Player002 … GG321
퍼블리셔
인증서버
로그인 서버인증요청
인증요청
게임계정DB
동
기
화
인증응답
쉽지만, 구조변경이 필요
개발사의 이해가 있으면…
(출처 : http://www.slideshare.net/LukeStapley/introduction-to-business-english-day-12)
가입
클라이언트 인스톨
다운로드
크래시 발생
이벤트
클라이언트 패치
게임서버 접속
그러나.. 문제발생!
게임 로그인
서버가 다운되었을 때에..
(출처 : http://cliparts.co/tombstone-clipart)
(출처 : http://www.whimsys-menagerie.com/bloat.htm,
http://pinoria.com/entry-level-engineers-earn-phds/)
(출처 : https://manandthegoose.wordpress.com/)
서버는 죽으면 살아나야 하고,
(출처 : Planet vs Zombie)
서버는 살아나면 (다시/스스로)연결도 되어하고,
서버는 스스로 죽을 줄도 알아야 합니다.
(출처 : http://blog.daum.net/_blog/BlogTypeView.do?blogid=04oGj&articleno=13844419)
스스로 재시작 하는 서버의 사례
서버 기본 : 120 MB 사용
200 MB
재
시
작
조
건
(출처 : http://moviesnewdownload.blogspot.kr/2013/03/download-die-hard-6-good-day-to-die.html)
가입
클라이언트 인스톨
다운로드
크래시 발생
이벤트
클라이언트 패치
게임서버 접속
게임 로그인
프로그래머의 영원한 적 : 크래시
(출처 : http://dynamicy.github.io/blog/2014/11/08/use-lldb-to-check-coredump/)
(환경 : http://www.tutorialspoint.com/compile_c_online.php)
크래시를 대하는 난감한 자세
크래시가 많이 난답니다!!
많이 심각해요 게임 내에서요게시판에서요
어떻게 알았나요? 심각하나요? 어디에서요?
(출처 : http://blissyoga.us/guru/
http://www.strategicdc.com/the-chiropractic-audit-compliance-staff-bomb-you-dont-want-to-explode-part-1/)
어디서
얼마나
(假定)
유저의 모든 이동을
인덱스로 서버에 기록
(출처 : http://en.wikipedia.org/wiki/Bomb_Jack)
크래시 정보 수집의 일반
크래시 수집
서버
Disconnection
크래시 정보 전송
(출처 : http://jezebel.com/that-50-percent-divorce-statistic-hasnt-been-true-for-a-1665833364)
CRASH!!!
개선된 크래시 정보 수집
로그인 서버인증요청
크래시 수집
서버
크래시 정보가 있으면 전송, 삭제
(출처 : http://www.crossover.org.au/how-to-get-a-90-success-rate-in-church-planting/)
이벤트!!
가입
클라이언트 인스톨
다운로드
크래시 발생
클라이언트 패치
게임서버 접속
게임 로그인
이벤트의 종류
(출처 : http://www.nexon.net
http://www.eqn-rp.com/forum/m/15888517/viewthread/16522982-illusion-progression-in-mmorpgs-leveling-obsolete/post/last)
실시간은 경쟁력 !
(출처 : https://davidjcarr.wordpress.com/tag/real-time/)
시스템 스케줄러 활용
실시간 이벤트의 장점
(출처 : https://www.propellerheads.se/blog/game-night-at-propellerhq)
아이템 지급을 위해 서버다운?
점검필요: 인벤토리에 바로 insert/update
대안 : 우편함으로 insert/update
( 우편함이 max 가 되는 경우만 예외처리 )
목표 : 3일짜리 아이템 지급. 14일 안에 소진.
대상 : 특정 조건의 추출된 유저
인벤토리 update
문제 : 사용 못할 유저발생. ( 지급 3일이후 접속 )
우편함 update
문제 : 14일안에 소진 불가. ( 늦게 가져가는 유저 )
추천 : 로그인 할때 받아가면 좋음.
실시간 로그인 이벤트?  특정 조건의 유저를 맞추지 못함.
지급테이블에 insert  로그인시 select
로그인 실시간 이벤트 + 대상자 테이블
점검 없이 지급 가능
대규모 지급에도 서비스에 영향이 적음
아이템 판매/종료를 위해 서버다운?
오프라인 마트도
온라인 쇼핑몰도
상품판매를 위해서
점검을 하지 않습니다.
게임 샵서버퍼블리셔 샵 서버
아이템 정보
게임 서버
아이템 정보
이벤트 발생  데이타 수집
재미 있는 게임 만들어 주십시오.
야근 많이 하지 마시고..
좋은 파트너 !
(출처 : http://www.vitalvoiceanddata.com/partnership/)
Queue & A*
감사합니다.
Thanks to :
큐로드(Qroad) (前 웹젠, 크라이텍 ) 진석준 님
플레이파이 게임즈 (前 액토즈 소프트) 손정이 님
넥슨아메리카 임현규님, 김태현님, 윤지선님, 강병탁님
그리고 소중한 경험을 하게 해주신 모든 개발자분들…

More Related Content

What's hot

[1A4]자바스크립트 라이브러리 개발 운영 경험기
[1A4]자바스크립트 라이브러리 개발 운영 경험기[1A4]자바스크립트 라이브러리 개발 운영 경험기
[1A4]자바스크립트 라이브러리 개발 운영 경험기NAVER D2
 
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트Ji-Woong Choi
 
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석NAVER D2
 
Nginx basic configurations
Nginx basic configurationsNginx basic configurations
Nginx basic configurationsJohn Kim
 
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라NAVER D2
 
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211Ji-Woong Choi
 
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현NAVER Engineering
 
웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화NAVER D2
 
[오픈소스컨설팅]Zabbix Installation and Configuration Guide
[오픈소스컨설팅]Zabbix Installation and Configuration Guide[오픈소스컨설팅]Zabbix Installation and Configuration Guide
[오픈소스컨설팅]Zabbix Installation and Configuration GuideJi-Woong Choi
 
Envoy 를 이용한 코드 배포 자동화
Envoy 를 이용한 코드 배포 자동화Envoy 를 이용한 코드 배포 자동화
Envoy 를 이용한 코드 배포 자동화Juwon Kim
 
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6Ji-Woong Choi
 
[PHPFest 2013] PHP 성능 향상 방법
[PHPFest 2013] PHP 성능 향상 방법[PHPFest 2013] PHP 성능 향상 방법
[PHPFest 2013] PHP 성능 향상 방법phpkorea
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQLI Goo Lee
 
PHP 와 MySQL을 이용한 게임 랭킹 구축하기
PHP 와 MySQL을 이용한 게임 랭킹 구축하기PHP 와 MySQL을 이용한 게임 랭킹 구축하기
PHP 와 MySQL을 이용한 게임 랭킹 구축하기Yo-Chang Song
 
500.JBoss Troubleshooting Essential
500.JBoss Troubleshooting Essential500.JBoss Troubleshooting Essential
500.JBoss Troubleshooting EssentialOpennaru, inc.
 
처음 시작하는 라라벨
처음 시작하는 라라벨처음 시작하는 라라벨
처음 시작하는 라라벨KwangSeob Jeong
 
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안[오픈소스컨설팅]클라우드자동화 및 운영효율화방안
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안Ji-Woong Choi
 
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트iFunFactory Inc.
 
[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술NAVER D2
 
Nginx Testing in NAVER
Nginx Testing in NAVERNginx Testing in NAVER
Nginx Testing in NAVER형근 송
 

What's hot (20)

[1A4]자바스크립트 라이브러리 개발 운영 경험기
[1A4]자바스크립트 라이브러리 개발 운영 경험기[1A4]자바스크립트 라이브러리 개발 운영 경험기
[1A4]자바스크립트 라이브러리 개발 운영 경험기
 
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
[오픈소스컨설팅] Docker를 활용한 Gitlab CI/CD 구성 테스트
 
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석
[2017 Incognito] Code Clone 기법을 통한 모바일 브라우저 취약점 분석
 
Nginx basic configurations
Nginx basic configurationsNginx basic configurations
Nginx basic configurations
 
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라
[141] 오픈소스를 쓰려는 자, 리베이스의 무게를 견뎌라
 
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211
[오픈소스컨설팅]애플리케이션 빌드 및_배포가이드_v1.0_20140211
 
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현
[네이버오픈소스세미나] Next Generation Spring Security OAuth2.0 - 이명현
 
웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화
 
[오픈소스컨설팅]Zabbix Installation and Configuration Guide
[오픈소스컨설팅]Zabbix Installation and Configuration Guide[오픈소스컨설팅]Zabbix Installation and Configuration Guide
[오픈소스컨설팅]Zabbix Installation and Configuration Guide
 
Envoy 를 이용한 코드 배포 자동화
Envoy 를 이용한 코드 배포 자동화Envoy 를 이용한 코드 배포 자동화
Envoy 를 이용한 코드 배포 자동화
 
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6
[오픈소스컨설팅]Data Source Password Encryption on JBoss EAP 6
 
[PHPFest 2013] PHP 성능 향상 방법
[PHPFest 2013] PHP 성능 향상 방법[PHPFest 2013] PHP 성능 향상 방법
[PHPFest 2013] PHP 성능 향상 방법
 
Fluentd with MySQL
Fluentd with MySQLFluentd with MySQL
Fluentd with MySQL
 
PHP 와 MySQL을 이용한 게임 랭킹 구축하기
PHP 와 MySQL을 이용한 게임 랭킹 구축하기PHP 와 MySQL을 이용한 게임 랭킹 구축하기
PHP 와 MySQL을 이용한 게임 랭킹 구축하기
 
500.JBoss Troubleshooting Essential
500.JBoss Troubleshooting Essential500.JBoss Troubleshooting Essential
500.JBoss Troubleshooting Essential
 
처음 시작하는 라라벨
처음 시작하는 라라벨처음 시작하는 라라벨
처음 시작하는 라라벨
 
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안[오픈소스컨설팅]클라우드자동화 및 운영효율화방안
[오픈소스컨설팅]클라우드자동화 및 운영효율화방안
 
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트
[아이펀팩토리]2017 NDC 강연 자료_아이펀 엔진 개발 노트
 
[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술
 
Nginx Testing in NAVER
Nginx Testing in NAVERNginx Testing in NAVER
Nginx Testing in NAVER
 

Viewers also liked

페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference
페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference
페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conferenceWalter Yang
 
마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유Woo Sanghun
 
프로세스 방어
프로세스 방어프로세스 방어
프로세스 방어주항 박
 
이사, 참 쉽다 이사모아
이사, 참 쉽다 이사모아이사, 참 쉽다 이사모아
이사, 참 쉽다 이사모아재욱 정
 
뉴스페이스 회사소개
뉴스페이스 회사소개뉴스페이스 회사소개
뉴스페이스 회사소개koreari
 
[한국핀테크포럼] 회원사소개 Ktb솔루션
[한국핀테크포럼] 회원사소개 Ktb솔루션 [한국핀테크포럼] 회원사소개 Ktb솔루션
[한국핀테크포럼] 회원사소개 Ktb솔루션 성태 박
 
퍼블리셔, 디자인을 퍼블리싱하다
퍼블리셔, 디자인을 퍼블리싱하다퍼블리셔, 디자인을 퍼블리싱하다
퍼블리셔, 디자인을 퍼블리싱하다jeong seok yang
 
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템 메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템 ByungTak Kang
 
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기clearboth
 
의료관광상품 개발로 세계인 유혹
의료관광상품 개발로 세계인 유혹의료관광상품 개발로 세계인 유혹
의료관광상품 개발로 세계인 유혹chunbyunghoon
 
저스트고 제안서 20120106
저스트고 제안서 20120106저스트고 제안서 20120106
저스트고 제안서 20120106lemonmail
 
개미블로그 리뷰 제안서
개미블로그 리뷰 제안서개미블로그 리뷰 제안서
개미블로그 리뷰 제안서gaemiblog
 
Active ad 광고라이브러리 소개
Active ad 광고라이브러리 소개Active ad 광고라이브러리 소개
Active ad 광고라이브러리 소개logeo
 
인천농수산물시장 제안서
인천농수산물시장 제안서인천농수산물시장 제안서
인천농수산물시장 제안서태환 김
 
적립의 기술 Ver 0.3
적립의 기술 Ver 0.3적립의 기술 Ver 0.3
적립의 기술 Ver 0.3Hyun Sang Lee
 
3 Keys To Ace Your Next Design Competition
3 Keys To Ace Your Next Design Competition3 Keys To Ace Your Next Design Competition
3 Keys To Ace Your Next Design CompetitionJoseph Louis Tan
 

Viewers also liked (20)

페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference
페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference
페이스북 광고마케팅의 성공법칙 양윤직 201102_fb_conference
 
마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유
 
프로세스 방어
프로세스 방어프로세스 방어
프로세스 방어
 
이사, 참 쉽다 이사모아
이사, 참 쉽다 이사모아이사, 참 쉽다 이사모아
이사, 참 쉽다 이사모아
 
뉴스페이스 회사소개
뉴스페이스 회사소개뉴스페이스 회사소개
뉴스페이스 회사소개
 
[한국핀테크포럼] 회원사소개 Ktb솔루션
[한국핀테크포럼] 회원사소개 Ktb솔루션 [한국핀테크포럼] 회원사소개 Ktb솔루션
[한국핀테크포럼] 회원사소개 Ktb솔루션
 
퍼블리셔, 디자인을 퍼블리싱하다
퍼블리셔, 디자인을 퍼블리싱하다퍼블리셔, 디자인을 퍼블리싱하다
퍼블리셔, 디자인을 퍼블리싱하다
 
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템 메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템
메이플스토리 사례를 통해 살펴보는 서버사이드 봇/핵 탐지 시스템
 
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기
평범한 에이전시 팀장의 일반적인 퍼블리싱 이야기
 
의료관광상품 개발로 세계인 유혹
의료관광상품 개발로 세계인 유혹의료관광상품 개발로 세계인 유혹
의료관광상품 개발로 세계인 유혹
 
저스트고 제안서 20120106
저스트고 제안서 20120106저스트고 제안서 20120106
저스트고 제안서 20120106
 
개미블로그 리뷰 제안서
개미블로그 리뷰 제안서개미블로그 리뷰 제안서
개미블로그 리뷰 제안서
 
Active ad 광고라이브러리 소개
Active ad 광고라이브러리 소개Active ad 광고라이브러리 소개
Active ad 광고라이브러리 소개
 
인천농수산물시장 제안서
인천농수산물시장 제안서인천농수산물시장 제안서
인천농수산물시장 제안서
 
두부는 반드시 먹어야 하는가_순창 두부워크샵
두부는 반드시 먹어야 하는가_순창 두부워크샵두부는 반드시 먹어야 하는가_순창 두부워크샵
두부는 반드시 먹어야 하는가_순창 두부워크샵
 
Scamper
ScamperScamper
Scamper
 
Mt3500as Menual
Mt3500as MenualMt3500as Menual
Mt3500as Menual
 
적립의 기술 Ver 0.3
적립의 기술 Ver 0.3적립의 기술 Ver 0.3
적립의 기술 Ver 0.3
 
3 Keys To Ace Your Next Design Competition
3 Keys To Ace Your Next Design Competition3 Keys To Ace Your Next Design Competition
3 Keys To Ace Your Next Design Competition
 
4.1.4엄윤정
4.1.4엄윤정4.1.4엄윤정
4.1.4엄윤정
 

Similar to 개발사는 모르는 퍼블리셔의 뒷 이야기

클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다Dae Kim
 
[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅NAVER D2
 
Meetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsMeetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsminseok kim
 
NAVER의 웹/HTML5환경 대응 현황
NAVER의 웹/HTML5환경 대응 현황NAVER의 웹/HTML5환경 대응 현황
NAVER의 웹/HTML5환경 대응 현황NAVER Engineering
 
Opensource apm scouter in practice
Opensource apm scouter in practiceOpensource apm scouter in practice
Opensource apm scouter in practicedonghoonlee18659041
 
Rhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea Strike
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceGunHee Lee
 
PCF Installation Guide
PCF Installation GuidePCF Installation Guide
PCF Installation Guideseungdon Choi
 
Sharepoint2010을 활용한 개발환경 구축
Sharepoint2010을 활용한 개발환경 구축Sharepoint2010을 활용한 개발환경 구축
Sharepoint2010을 활용한 개발환경 구축minjin00
 
MS SharePoint를 활용한 개발환경 구축
MS SharePoint를 활용한 개발환경 구축MS SharePoint를 활용한 개발환경 구축
MS SharePoint를 활용한 개발환경 구축Heo Seungwook
 
빌드관리 및 디버깅 (2010년 자료)
빌드관리 및 디버깅 (2010년 자료)빌드관리 및 디버깅 (2010년 자료)
빌드관리 및 디버깅 (2010년 자료)YEONG-CHEON YOU
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기YoungSu Son
 
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기Jaeseung Ha
 
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁Yi-kwon Hwang
 
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템tcaesvk
 
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...Tae-Seong Park
 
(130511) #fitalk utilization of ioc, ioaf and sig base
(130511) #fitalk   utilization of ioc, ioaf and sig base(130511) #fitalk   utilization of ioc, ioaf and sig base
(130511) #fitalk utilization of ioc, ioaf and sig baseINSIGHT FORENSIC
 
JVM_트러블슈팅.pdf
JVM_트러블슈팅.pdfJVM_트러블슈팅.pdf
JVM_트러블슈팅.pdfkwbak
 
20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debuggingJongwon Han
 

Similar to 개발사는 모르는 퍼블리셔의 뒷 이야기 (20)

클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
클라우드 기반 Unity 게임 서버 구축, 60분이면 충분하다
 
[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅[232] 성능어디까지쥐어짜봤니 송태웅
[232] 성능어디까지쥐어짜봤니 송태웅
 
Meetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vsMeetup tools for-cloud_native_apps_meetup20180510-vs
Meetup tools for-cloud_native_apps_meetup20180510-vs
 
NAVER의 웹/HTML5환경 대응 현황
NAVER의 웹/HTML5환경 대응 현황NAVER의 웹/HTML5환경 대응 현황
NAVER의 웹/HTML5환경 대응 현황
 
Opensource apm scouter in practice
Opensource apm scouter in practiceOpensource apm scouter in practice
Opensource apm scouter in practice
 
Opensource apm scouter in practice
Opensource apm scouter in practiceOpensource apm scouter in practice
Opensource apm scouter in practice
 
Rhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_ArchitectureRhea_MMO_SNG_Convergence_Server_Architecture
Rhea_MMO_SNG_Convergence_Server_Architecture
 
Opensource APM SCOUTER in practice
Opensource APM SCOUTER in practiceOpensource APM SCOUTER in practice
Opensource APM SCOUTER in practice
 
PCF Installation Guide
PCF Installation GuidePCF Installation Guide
PCF Installation Guide
 
Sharepoint2010을 활용한 개발환경 구축
Sharepoint2010을 활용한 개발환경 구축Sharepoint2010을 활용한 개발환경 구축
Sharepoint2010을 활용한 개발환경 구축
 
MS SharePoint를 활용한 개발환경 구축
MS SharePoint를 활용한 개발환경 구축MS SharePoint를 활용한 개발환경 구축
MS SharePoint를 활용한 개발환경 구축
 
빌드관리 및 디버깅 (2010년 자료)
빌드관리 및 디버깅 (2010년 자료)빌드관리 및 디버깅 (2010년 자료)
빌드관리 및 디버깅 (2010년 자료)
 
클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기클라우드 환경에서 알아야할 성능 이야기
클라우드 환경에서 알아야할 성능 이야기
 
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
[NDC2015] 언제 어디서나 프로파일링 가능한 코드네임 JYP 작성기 - 라이브 게임 배포 후에도 프로파일링 하기
 
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
NDC15 - 사례로 살펴보는 MSVC 빌드 최적화 팁
 
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템
NDC 2013, 마비노기 영웅전 개발 테크니컬 포스트-모템
 
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...
혼자서 커뮤니티 귀동냥하며 만든 Next.js & Amplify & serverless framework 웹 플랫폼 서비스 구현(삽질) 후...
 
(130511) #fitalk utilization of ioc, ioaf and sig base
(130511) #fitalk   utilization of ioc, ioaf and sig base(130511) #fitalk   utilization of ioc, ioaf and sig base
(130511) #fitalk utilization of ioc, ioaf and sig base
 
JVM_트러블슈팅.pdf
JVM_트러블슈팅.pdfJVM_트러블슈팅.pdf
JVM_트러블슈팅.pdf
 
20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging20170813 django api server unit test and remote debugging
20170813 django api server unit test and remote debugging
 

개발사는 모르는 퍼블리셔의 뒷 이야기

Editor's Notes

  1. 저의 작은 경험들을 이렇게 공유할 수 있게 해주신 NDC관계자분들께 감사하고요, 귀한시간 내주셔서 와주신 여러분께도 감사드립니다. 
  2. 먼저 제 소개를…
  3. 흔희 볼 수 있는 콘센트. 맞지않은 충전기  공급자는 변경 요청  제작자는 난감… 이것이 게임서비스와 다른 얘기는 아닌듯….
  4. 이 얘기가 과연 게임 서비스와 다른 얘기일까요..게임에서도 이런 일들이 비일비재합니다. 좀 부정적인 시나리오를 쓰면 이러한 사용자의 욕구가 충족되지 않는 엔터테인먼트는 당연히 사용량이, 사용자가 감소합니다.. 따라서 매출도 감소하고요.. 퍼블리셔와 개발사는 원인을 찾기 시작합니다만, 계속 다른 것만 찾고 있습니다. 방학때문일까? 알수없는 크래시때문일까? 어디서 유저들이 빠져나가는 걸까?... 할 수 있는 시스템도 없습니다. 알수 없습니다. .. 그러다가.. 서비스를 종료합니다
  5. 여러가지 이유가 있지만, 저는 두가지를 큰 이유로 뽑았습니다. 한가지는 돈이죠. 그리고 어떤 이유에서인지 처음 만든 게임의 기반들이 계속 무너져 내려간다는 것입니다. 안정성이 떨어지고, 처음 게임 만들었을때와 점점 달라진다는 것입니다.
  6. 한달에 매출 10억인 게임을 가정해보죠. .. 그럼 연간 120억입니다. 이게임의 하루매출은 약 3300만원(3287만원), 그리고 시간당 약 140만원(139)을 기회비용으로 지불합니다. 이 게임이.. 2주마다 5시간씩 점검을 한다고 하면…26*5=130시간 점검.. 입니다. 2주에 한번 점검을 하고, 한번할때마다 다섯시간을 점검한다면, 연간 26회.. 1억 7천 8백만원이라는 큰돈의 기회비용을 매출에서만 지출하게 됩니다. (1.4%) 그 외에도 서버비용, 패치 준비하는 개발사/퍼블리셔 인력의 비용… 등이 추가로 지출이 됩니다.
  7. 현실은 더 잔인..하죠. 최근 두달동안 점검 시간. 20번 : 74시간. 일주일에 약 9시간을 점검한셈. 130시간점검에.. 1억7천이었는데, 이녀석은.. 이미 두달만에 그 절반이상을 까먹은겁니다…
  8. 게임의 기반이 어떻게 무너지는지 한번 볼까요? .. 게임은 재미 없는데 관리는 엉망이라고 유저들은 얘기합니다. 사실 게임이 재미없어서 접는 유저들은.. 그냥 초반에 느낌이 자기의 스타일과 다르면 접습니다. 개발사는 다들 충분히 테스트하고 재미요소 넣어서 서비스 합니다. 결국 서비스/관리 문제인데…퍼블리셔는 여러가지 관리하는 요소들을 생각하고, 게임 내에 개발이 필요한 부분들을 개발사에 요청을 합니다. 그러면, 컨텐츠 개발이 지연이 되고, 급하게 요청과 개발이 오가다 보면 당연히 안정성은 감소합니다. 그러면 전반적으로 완성도와 생산성은 감소하게 되죠.
  9. 여기 바람직한 매출곡선이 있습니다. MUJI 라는 의류업체의 실적. 전반적으로 상승하면서 물결을 만드는 모양. 바람직한 상승곡선.
  10. 서비스 하는 퍼블리셔는 이런 매출곡선을 만들기 위해서 노력합니다. 매출곡선에만 집중을 하다보면 패치를 자주하게 됩니다. 패치를 자주하게 되면 그럼 매출은 상대적으로 오르는 듯 하지만.. 아주 짧은 곡선을 그리면서 물결을 칩니다. Base line 을 만들기 위해서 퍼블리셔는 자극적인 패치, 쥐어짜내기 패치, 밸런스 붕괴가 오고, 유저들은 스트레스를 받고, 퍼블리셔도 스트레스, 개발사도 스트레스를 받게 됩니다. .. 패치를 하지 않을 수는 없죠. 컨텐츠 업데이트도 해야하고 긴급 버그 패치도 해야하고.. 하지만, 이런 악순환이 계속 되면..
  11. 퍼블리셔에서는 게임에 대해서 어떤 부분들을 얘기하고- 엔지니어의 관점에서 .. 줄일 수 있는 패치가 어떤 것이 있는지.. 그리고 서로간에 역할-퍼블리셔는 퍼블리싱에 좀 더 집중하고, 개발사는 좀 더 개발에 집중할 수 있는 방법에 대해서 얘기를 해보려고 합니다. 재미도 있고 서비스도 좋은 그런 게임을 같이 만들어보자는 취지에서 마련했습니다.
  12. 사실 하고 싶은 얘기는 많다. .. 퍼블리셔의 엔지니어 입장에서, 또는 프로덕션 포지션의 입장에서…
  13. 하지만, 시간 관계상.. 이정도만 얘기하려고 한다. 오늘 강연의 목적은 퍼블리셔에서 필요한 부분들이 어떤것인지 이해하고, 왜 그런 요청이 오는지, 그리고 어떻게 하면 개발 초기부터 이러한 것들을 고려해서 추후에 게임의 기반이 흔들리는.. 컨텐츠 개발에 큰 지장이 없이 할 수 있는 방법에 대해서 공유하려고 합니다. 따라서, 한가지 주제에 대해서 많이 깊이 들어가지는 못하는 점 양해 부탁드립니다.
  14. 게임을 서비스하는 퍼블리셔에서는 이런 고민들을 가장 많이 합니다. 어떻게 하면 많은 유저를 가입 시키고, 계속 유지해 나갈까… 게임서비스의 처음부터 한번 생각을 해보죠… 가입인스톨로그인플레이 유저가 로그인을 하고 처음 게임에 접할때까지 무지 많이 떨어집니다. 게임을 접하고 나서도 보통 1렙에서 반이상 떨어져 나가고.. 몇달뒤에는 10% 도 안남는 경우가 많죠. 그래서 퍼블리셔에서는 이 떨어지는 유저들을 막기 위해서 노력을 합니다. 그럼 이 떨어져 나가는 유저들을 한번 따라가면서.. 무엇이 문제인지.. 하나씩 얘기를 해보죠.
  15. 실제 유저가 게임을 접속하는 흐름을 따라가면서 어떤 얘기들이 있는지 알아보죠. 대부분이 실제 사례를 바탕으로 재구성한것입니다.
  16. 가장 먼저 얘기하고 싶은 것은.. 파일입니다. 이 폴더명이.. 친숙하신 분들도 아마.. 계실겁니다. 
  17. 유저에게 파일을 전달하는 것은 택배와도 비슷합니다. 제품을 전달하는 과정으로 딜리버리라고도 부르죠. 택배 물건이 손상이 되었거나, 배달이 너무 늦으면 .. 화가 납니다. 보시는건 중국춘절의 택배물건 쌓인것이죠. 이렇게 택배가 많고, 배송과정이 그만큼 순탄하지 않으면 늦어지고, 고객들은 화가나고, 그다음 물건을 구매할것인지, 그 배송업체를 다시 쓸건지 고민하게 됩니다. 역시나 유저가 필요한 파일을 전달받는 과정과 설치하는 과정에서 불편하면 안된다는 것입니다.
  18. WII 에서 쓰는 제 아바타입니다. 이제 이 데이빗이라는 유저가 어떤 게임을 알게 되고 가입하고, 다운로드 하고 그다음 인스톨을 하게 됩니다 파일들에 대해서 얘기를 좀 해보죠 퍼블리셔의 엔지니어들이 하는 얘기들입니다.
  19. 퍼블리셔의 엔지니어 입장에서 얘기를 많이 합니다. 전달되는 파일에 대해서.. 이미 많은 게임들이 간결하게 구성되어서 출시되고 있습니다. 그런데.. 아직도.. 그렇지 않는 아닌 게임들이 많습니다… 안타깝게도… 적용되는 원칙중에 하나를 KISS 원칙이라고 하죠
  20. 실제 서비스 하고 있는 게임의 파일 구성입니다. 11만개의 파일에 약 7천개의 폴더. 사이즈도 15기가 이지만, 이것보다도 파일갯수가 너무 많다는 것입니다. 아시다시피 file I/O 가 많아지죠.. 그러면…(다음)
  21. <포기, 문제, 포기..포기.. > 저도 직접 경험한 문제이고, 여러분들도 한두번쯤은 .. 인스톨 단계에서.. 그 게임을 접은 경험들이 한두번씩 있을겁니다. 실컷 마케팅해서 유저들 모아왔는데, 인스톨하는데에서 떨어져나간다면.. 안타깝겠죠..
  22. 따라서.. 당연히 압축을 해야죠. Zlib, FastLZ, LZO, LZF 같은 라이브러리를 이용하고요 요즘은 더 좋은 압축 라이브러리도 많이 나왔죠? Snappy 같은 것고 있고요.. 물론 여기에는 클라 로딩시간을 감안해야합니다. 그에 맞춰서 최적화를 해야하고요.. Zlib 으로 묶인 거대한 파일들의 그 다음 이슈인 로딩최적화에 대해서는 작년NDC에 좋은 발표가 있어서 소개를 드립니다. 많은 참고가 되시리라 생각합니다.
  23. 그리고 파일 관련해서 한가지 더 얘기하고 싶은것이… 클라데이타=서버데이타.. 물론, 관리상 편리하다는 장점이 있지만, 이렇게 되면.. 부작용은 배포시간 증가, 로딩시간증가.. 따라서 점검시간 증가가 있습니다. 안그래도 점검 많고, 버그때문에 점검시간 길어지는데.. 한번 배포하고 로딩하는데 30분-1시간씩 걸린다면.. 자연적으로.. 점검시간은 길어질수밖에 …없습니다.
  24. 파일관련된 얘기가 하나 더 있습니다. 패치를 받네요..
  25. 관리보다는 유저편의에 목적을 두어야 합니다. 간과하기 쉽습니다. 패치는.. 패쳐를 개발사, 퍼블리셔… 각각 다르게 독립적으로 개발되는 경우도 있는데.. 개발사에서 개발하는 경우가 아직 많이 있다. 패치메이커, 패쳐를 다 개발사에서 만드는데.. 사실 그냥 퍼블리셔에 맡겨도 된다. 다 준비되어 있다..(물론 아닌 퍼블리셔도 있지만..)
  26. 제가 경험했던 패치 방법중 두가지를 비교해보죠.. 하나는 버전만 검사합니다. <방법> 관리하기 편하죠. 그리고 2-3버전의 클라를 갖고 있는 유저가.. 타겟버전에 여러번 받는 것을 한번에 묶어서 패치한다는 유저편의가 있지만.. 여기에는 몇가지 맹점이 있죠.
  27. 지원하는 버전보다 더 오래된 버전을 갖고 있으면..
  28. 관리적인 이슈이지만.. 점검시간에 급하게 클라를 패킹해야하는 경우에는 이것 또한 유저불편으로 영향이 갑니다.
  29. 아직도 많은 게임이 사용하고 있는 방법이죠. <방법> 파일갯수가 10만개쯤 되면 이방법은 오히려 부작용이 심할겁니다…그러니 파일갯수를 줄이는 것이 좋죠.
  30. 파일리스트의 내용은 간단합니다. 파일명, 시간, 사이즈, 옵션으로 첵섬을 두면 됩니다. 여기서 한가지, 한가지 시간을 기준시간으로 해서 기록/비교를 해주세요. 아니면 UTC 기준으로 서버시간/유저시간의 타임존이 바뀌더라도 지장 없도록… 패치 파일 비교에서 시간변경 관련된 에피소드 하나를 소개해드릴께요.
  31. 북미나 유럽에는 섬머타임이 있는 것 아시는 분 있을겁니다. 섬머타임이면 시간이 한시간이 밀리거나 땡겨져서 서버시간이 달라지는데.. 서버시간이 변경되니까.. 서버가 들고있는 시간까지 변경이 된겁니다. 그 시간과 유저의 시간을 비교하니 전부 다르죠.. 그래서.. 모든 파일들을 다 받은 사건이 있었습니다… 패치뿐만 아니라, 서버/클라의 처리가 시간이 변경되더라도 타임존을 기준으로 처리될 수 있도록 부탁드릴께요….
  32. 이런식으로 버전과 파일검사를 같이 한다면.. 앞서 보여드린 사례의 단점들을 모두 극복하게 되었네요 버전만 확인, 또는 버전/파일 같이 하는 게임들이 많습니다. 소개해드린 방법을 적절하게 섞은 게임들도 있고요 아시다시피 버전초기화만 하는 게임도 있고요, 파일검사를 유저가 선택해서 하는 게임도 있습니다.
  33. 이외에도.. 현재 저희가 서버 배포에 사용하기 위해서 만들고 있는 솔루션입니다만.. 용량이 큰 파일들을 배포하는데 유용한 방법입니다. 실제로 조사한바에 의하면 서버의 경우 2-30%...정도만다르고, 클라는 8-90%가 동일했습니다. 하지만, 그 파일 자체를 다 패치/배포하게 되는거죠.. <방법> 소개해드린 세가지 방법을 적절하게 사용한다면 유저들이 편하게 업데이트를 전달받을 수 있을겁니다.
  34. 우여곡절끝에 유저는 설치하고 패치하고 게임에 접속합니다 이 얘기는 퍼블리셔의 프로덕션 입장에서 얘기를 해볼까요? ..
  35. 퍼블리셔에서는 유저들을 많이 유치하고, 그들이 꾸준히 게임을 즐길 수 있도록 고민하고, 시스템을 만듭니다. 광고를 보고, 와서 가입을 합니다… - 퍼블리셔에서 트래킹을 할 수 있죠.. 유저가 로그임을 하고 플레이를 합니다. – 게임내에서 트래킹이 가능합니다. 근데.. 이 둘사이는 어떻게 연결을 할 수 있을까요?
  36. 주로 광고를 많이 합니다. 입소문으로도 많이 들어오죠. 어떤 광고를 본 유저가 어떤 게임을 하는지.. 저 두 다리가 이어지지가 않으니까.. 트래킹이 안되고.. 트래킹이 안되니까..광고 전략을 좀 더 자세히 세울수가 없는 것입니다.
  37. 그리고 특정일에 게임에 처음 들어와서 캐릭을 만든 유저들을 뽑습니다… 광고타고 들어온 유저디비 값이랑 비교해서.. 게임의 유저 하나하나.. 또는 특정 그룹을 묶어서 .. 비교를 했습니다. .. 이미 이 작업자체가 작지 않은 작업이었습니다. 2-3주마다 광고전략을 바꿔야 했으니.. .. 한번할때마다 수동으로 뽑고.. 비교하고.. 그리고, 가입은 계정기반이고, 게임은 캐릭터기반의 정보가 남기 때문에.. 이 둘을 수동으로 비교하는 것은 힘든일이였습니다.
  38. 거기다가.. 그다음 빌링까지 못가는 겁니다. 왜냐면 빌링디비는 또 다른 디비이고.. 계정단위인데, 게임디비는 캐릭단위인겁니다. 이걸 또 뽑아서 또 비교…. 흠…. 수동으로.. 물롬 … 꼭 필요할때 한번씩 뽑아서 했죠. 근데.. 이렇게 하면 너무 비효율적인겁니다. 그리고 정기적으로 이 수치를 보면서 전략을 새워야 하는데.. 그러면.. 게임계정/캐릭터가 어떤 정보를 한두개만 더 들고 있을 수 있으면 다 해결이 되는 답이 있는 문제였습니다.
  39. 결국 목적은 어떤 광고의 유저가 게임을 계속 플레이 하는지, 과금 유저가 되는지… 어떤 플레이를 얼마만큼 하는지 트래킹 해서.. 그 다음 광고를 효과적으로 하기 위한 자료를 만들려는 것입니다.
  40. 그래서 요청을 한것이.. 유저가 로긴 인증 요청을 하고, 퍼블리셔 계정DB에서 인증 응답을 받을때에.. 광고코드를 하나 넣어달라고 했습니다… 대부분 받아들여지지 않았고… 몇몇 게임만.. 넣어서 트래킹을 했었습니다…
  41. 개발초기에 이런 부분이 고려가 된다면.. 구조변경을 하지 않고도 해결할 수 있고..
  42. 초기에 고려가 되지 않더라도.. 개발사의 이해가 있으면 이런 제안-역제안-동의-확정 이라는 커뮤니케이션 흐름으로 좋은 게임이 나올 수 있을 것입니다.
  43. 유저가 플레이를 합니다. 서버에서 즐기죠. 이서버에서 저서버로 옮겨다니면서.. 그런데 서버가 버그때문에 또는 다른 이유 때문에 죽었습니다. 퍼블리셔에서 운영하는 입장에서 얘기를 해볼까요?
  44. 서버가 죽었습니다. … 유저들은…후두두둑..떨어져 나가죠…
  45. 1. 죽었다고 메일이 .. 요즘은 많이 오죠.. 2. 엔지니어에게 연락합니다. 3. 엔지니어는 가서 살립니다. 그다음 별 문제 없습니다…..  알고보니 아주 가끔 죽는 원인이 있었던겁니다…. 요거 살리기만 하면.. 다시 할 수 잇는데…이 기능이 없어서 운영담당PM엔지니어 .. 이런 과정을 거치는거죠…
  46. 이렇게 한번 대응하고 나면.. 엔지니어는 녹초가 되고.. 다른 일은 못하게 되는 상황이 되는거죠.. 대부분 서버는 살아나면 다시 서비스가 제개되고, 큰 문제 없이 돌아가는 경우가 많습니다.
  47. 그리고 살아나면… -- 서버띄우는데 보통 순서가 있죠. 순서를 어기면 서버가 정상적으로 뜨지 않습니다. 그 순서는 연결과 연관이 가장 깊습니다. 리스타트를 할때에는 연결을 시켜줬으면 좋겠네요…
  48. 유저들이 빈번히 들락날락하는 서버에서 많이 발생하는 문제중에 하나죠. 주로발생하는 버그중에 하나가 메모리 누수입니다. 메모리 누수가 생기면 서버호스트에 메모리를 많이 잡아먹게 되고, 그러면 정상적인 서비스가 불가능한 상황이 됩니다. 이럴 경우에는 스스로 죽는 로직도 필요합니다.
  49. 실제로 120메가 정도되는 게임 서버를 메모리 누수가 있어서.. 수정하기 난해하고, 누수되는 양이 많아서 급히 만들었던 기능이 200메가(물론 설정가능)가 넘어가면 .. 리스타트 하는 방식을 했습니다. 그러면 개발자는 일단 여유를 가지고 문제 해결을 할 수 있고, 퍼블리셔는 죽더라도 일단 서비스를 계속 할 수 있어서 상황을 심각하게 만들지는 않았었죠. 물론 리스타트는 그냥 퍽~! 하면 안됩니다. 저희가 했던 게임은 FPS 였고, 메모리 누수가 있어서 일정량이 넘어가면.. 플레이하는 유저가 다 나가면 리스타트를 하는 방식으로 햇었습니다. RPG의 경우 유저들이 계속 상주하는 서버이기 때문에, .. 유저들에게 양해를 구하는 메세지를 자동으로 뿌려주고 몇분있다가 리스타트를 하는 방법을 할 수 있겠죠.. . 메모리누수-즉, 메모리가 계속 증가하는 것은 Zabbix 같은 모니터링 툴로 얼럿을 만들고, 추후 조사를 하지만, 그것보다는 일단 서비스를 계속 해야하므로 서버를 리스타트 시키는 것이 좋습니다.
  50. 결론은 서버는 계속 살아있어야 한다는 것입니다. 다이하드…
  51. 그리고.. 서비스를 하다보면.. 플레이를 하다보면.. 심심치 않게 겪는 일이 있죠. 바로 크래시입니다
  52. 새로 오픈을 앞둔 게임들, 또는 대규모 패치를 하고 나서 참 자주 등장하는 적이 크래시죠. 코드를 예로 든건 아닙니다. 코드 얘기 안한다고 했으니 안합니다. 근데.. 이코드는.. 어이없죠? 뭐가 잘못되었을까요?...스트링… 리턴값… 그리고.. 널포인터 할당… 쉽지만, 코드가 복잡해지면 우리는 이런 실수 많이 합니다. 근데.. 이런실수 많이 합니다. 진짜 많이 합니다. .. ㅎㅎㅎ ;;….
  53. 클라이언트 뿐만 아니라 서버도 자주 크래시가 일어나죠. 크래시에 대한 잘못된 접근의 예를 들어볼까요 모든 유저가 발생한다면 알아내기 쉽지만, 분명.. 있는데,
  54. 뭐가 얼마나 있는지, 어디에서 나는지 모릅니다. 그런 시스템도 잘 없고요.. QA 투입되고.. 개발자도 디버거도 띄워보고… 하지만..개발자 환경에서는 크래시가 나지 않습니다. ㅎㅎ;;
  55. 크래시는 두가지가 분명해야합니다. 어디서 나는지 알아야 하고, 얼마나 나는지 알아야 합니다. 어디서는 해결하기 위해서이고, 얼마나는 많은 크래시중에 많이 발생하는 녀석을 먼저 해결하기 위해서입니다.
  56. 첫번째는 유저들이 로그인하고 진행되는 단계마다 정보를 수집합니다. 정상 로그아웃까지 모두 수집합니다. 그사이 빠진 유저들은 네트워크 이슈이거나 크래시이거나 이지만 대부분 크래시인경우죠. 네트워크도RST 패킷이 들어오면 정상이든 비정상이든 끊긴 처리가 되니까 크래시로 보면 됩니다. 여기서 익셉션을 발생시킬때에도 정보에 기록을 합니다. 인덱스만 남기는 거죠. 그러면 유저들이 어디에 많이 가는지도 알고, 어디로 많이 안가는지도 알고, 어디서 사라지는지-크래시가 나든 뭐든.. 알 수 있습니다. 여러가지 용도로 쓰이죠. 그러면 이러한 수치가 나옵니다. 이 수치는 유저가 어디서 많이 빠지는지도 알 수 있고, 크래시를 해결하고 나서도 실제로 해결이 되었는지 아닌지 알 수 있습니다.
  57. 그다음은.. 폭탄수집을 해야죠. 어떤 폭탄이 터졌는지 .. 그 폭탄들을 수집해야합니다. 서버 크래시 정보는 수집하기 쉬운데, 클라는 애매한 경우가 많습니다 가정 : 실제로 코드와 게임플레이와 1:1 매칭이 안되는 경우가 있다. 아이템에 크래시가 숨어있는데.. 이 코드는 던전에서, 상점에서, 유저간 거래에서 다 불린다고 가정하면.. 재현하는 것도.. 정말 어렵죠….
  58. 실제로.. 크래시가 나면 정보를 전송해야하는데.. 클라가 행이 걸리는 경우가 많습니다. 그럼 똑똑한 우리 유저들은 작업관리자를 열어서.. 프로세스를 죽이죠.. 그럼 전송이 안됩니다… 전송해야하는데 디스가 됩니다. 그떄도 전송이 안나죠.. 그래서 50%정도..
  59. 크래시 나면 덤프 파일 그대로 전송할것을 생각하는데.. 그러지 마세요.. 그 큰덤프 다 어디다 쌓아두시려구요. 터진 주소, 콜스텍, 버전, 그리고 간단한 시스템 정보 그러면 어떤 버전에서 많이 났는지, 해결이 잘 되었는지.. 알 수 있습니다. 가끔..자연치유된 케이스도 있습니다.
  60. 다시 게임으로 들어가볼까요? .. 그렇게 서버가 문제가 많고, 크래시가 나도.. 우리 유저들은 우리 게임을 즐깁니다. 고맙게도.. 감사하게도.. 그래서.. 기본 게임 컨텐츠 외에 유저들에게 재미와 할거리를 주고, 게임을 계속 즐겨달라고 진행하는 것이 있습니다. 바로 이벤트죠
  61. 요즘은 실시간 많죠..
  62. 이벤트는 기본적으로 실시간 on/off 가 가능하도록 설계를 해주세요. 트리거 하는건 쉽잖아요. 아래 보이는 xml 은 실제로 사용했떤 것인데, 리눅스의 crontab을 활용하고, 리워드 아이템 셋을 지원했습니다. 위에 보이는것은 데일리죠. 밑에는 실제 스케줄을 쓴것입니다. 1/29~31 시행했던 부스터 이벤트이죠. 이 외에도 미션이벤트, PC방 이벤트등.. 실시간으로 진행했었죠.
  63. 장점은 다 잘 아실겁니다. 비용절감과, 유저의 행복이죠. 실시간 이벤트의 방법에 대해서는 잘 알고 계시리라 생각합니다. 나중에 실시간으로 넣으려고 하면 상당히 많은 비용이 들어갑니다. 그래서 이벤트를 만들때에는 최대한 실시간으로 가능하게 하는 것이 추후에 여러 요청을 받지 않고..좋습니다.
  64. 대안추천 예: 목표 : 3일짜리 아이템을 지급해서 14일 안에 다 소진하게 하는 것이 목표. 좋은 방법 : 로그인할때에 받아가면 가장 좋음. 인벤토리에 점검을 걸어서 하자니.. 사용못할 유저가 있고… 3일.. 줬다 뺏자니.. 혼날 것 같고… 로그인이벤트로 처리하자니 대상유저 처리가 모호함. 대안 : 지급테이블 생성 + 로그인시 select 하여 인벤토리로 지급. 목표 : 20만명에게 아이템을 지급. 그런데, 예상으로는 약 3만명 정도만 실제로 접속할 것으로 예상. 하지만, 지급은 다 해야함. 우편함에 넣자니 부하가 심하게 걸릴 것 같음. 부하가 적고 락이 안걸리는 테이블이 필요  지급테이블 생성
  65. 대안 : 지급테이블 생성 + 로그인시 select 하여 인벤토리로 지급. 목표 : 20만명에게 아이템을 지급. 그런데, 예상으로는 약 3만명 정도만 실제로 접속할 것으로 예상. 하지만, 지급은 다 해야함. 우편함에 넣자니 부하가 심하게 걸릴 것 같음. 부하가 적고 락이 안걸리는 테이블이 필요  지급테이블 생성
  66. 퍼블리셔 샵 서버 <연동은 실시간> 게임 샵서버 – 샵서버 업데이트 될때에는 아주 잠깐의 critical section… 샵서버는 업데이트 되면 게임서버의 데이터도 업데이트 해줌. 유저는 게임서버에 접속을 할때 샵정보를 가져옴… 서버들간에는 이벤트를 순차적으로 발생해서 데이터 수집중에 트랜젝션이 일어나지 않도록 처리를 했습니다. 샵서버만 5분 미만으로 점검하면 된다. 여기까지가 오늘 준비한 내용입니다…