[NDC 2017] 아이펀팩토리 문대경 CEO 강연 현장공개!

안녕하세요, 아이펀팩토리 사업팀 남자같은 여자 1호 입니다.

이 곳 판교에서는 지난 25일부터 27일까지 NDC 2017가 성황리에 개최되었습니다!
다양한 주제의 강연부터 전시, 거리공연 그리고 이벤트까지! 게임산업 종사자들 및 지망생들의 축제라고 할 수 있죠?

저희 아이펀팩토리도 작년에 이어 올해에도 NDC와 함께 했는데요,
문대경 CEO의 강연은 둘째날인 26일, GBI타워 지하 1층 대강당에서
‘아이펀 엔진 개발 노트; 범용 게임 서버 엔진 개발 포스트모템’ 이라는 주제로 진행되었답니다.

거기에 하나 더! 문대경 CEO 강연과 함께 아이펀팩토리가 준비한 3일간의 든든한 선착순 이벤트까지!!

뜨거웠던 열기의 현장을 생생하게 전해드릴게요~! 고고고!

☞ NDC 강연자료 보러가기

☞ NDCP 강연자료 보러가기

IMG_2773.JPG▲ 넥슨 GBI타워 지하 1층 대강당 강연장 가는길

1▲ 모두가 강연에 집중!

3▲ 아이펀팩토리 문대경 CEO

2▲ 아이펀 엔진 개발 프로젝트에 대하여

4▲ 무엇이든 물어보세요~ 강연 후 질의응답 시간!

실시간 게임 서버 엔진인 아이펀 엔진이 개발되어온 순서와 거기서 얻은 레슨들을 공유하는 알찬 시간이었습니다.

강연에 집중하고나니 출출하시다구요?!
짜잔~ 그런 분들을 위해 아이펀팩토리가 준비한 선착순 이벤트!
아이펀팩토리 전단지에 있는 교환권을 작성하여 제출하면 푸짐한 간식이 들어있는 배불러 팩을 받을 수 있었어요.

5▲ 아이펀팩토리 이벤트 부스가 위치한 넥슨 GBI타워 1층 EVENT ZONE

6▲ 3일간 매일 진행된 배불러 팩 선착순 이벤트!

7▲ 자, 줄 서세요~ 아이펀팩토리 배불러 팩 인기 폭발 현장

화창한 봄날, NDC 2017 그리고 아이펀팩토리와 즐거운 시간 되셨나요?
다음엔 더욱 알찬 강연과 다양한 이벤트로 만나요~!

IMG_2772IMG_2766

개발 환경, 테스트 환경, 그리고 라이브

서버 개발자에게 컴퓨팅 자원은 곧 비용이다. 대충 한 열 명의 동접마다 한대씩 서버를 할당한다면 누구나 더 편하게 서버를 개발할 수 있을지도 모르겠지만, 현대의 기술은 아직 우리에게 이런 여유(혹은 낭비)를 허용하지 않고 있다. 게다가 열 명당 하나씩 서버를 둘 수 있다손 치더라도, 이로 인해 엄청나게 늘어나는 서버의 수를 관리하는 서버에 몰리는 부하를 처리해야하는 골치아픈 문제는 결국 그대로 남아있게 된다. 그러므로 결국 서버를 최대한 최적화하고 적당한 하드웨어를 찾아서 배포하는 방법론은 당분간 어쩔 수 없는 서버 개발자의 숙명이다.

클라이언트 개발자가 여러 대의 단말에서 테스트 한다면, 서버 개발자는 다양한 환경에서 서버 환경을 구축하고 테스트하게 된다. 끝없이 수정한 코드를 다시 실행해볼 개발 서버, 개발팀, 기획팀, 사내, QA팀을 위한 테스트 서버, FGT나 CBT등을 위한 일정 규모의 라이브에 준하는 서버, 그리고 실제로 서비스하는 라이브 서버, 마지막으로 게임이 성공해서 새로운 서버를 열어야하는 경우까지.. 안드로이드와 iOS라는 꽤나 다른 OS에서 동일한 어플리케이션을 동시에 준비하는 클라이언트 개발자들의 노력도 대단하지만, 상황에 따라 소규모부터 대규모까지 동시에 서버 환경을 만들어내야하는 서버 개발자의 고생도 더하면 더하지 덜하진 않다.

그렇다면 각각의 상황에 맞춰 필요한 하드웨어의 미덕과 준비 방법은 어떻게 될까. 이번 칼럼에서는 이를 이야기해보려고 한다.

1. 개발 환경

의외로 많은 개발자들이 개발 환경 하드웨어의 중요성을 무시하곤한다. 개발 환경의 서버는 최적화되기 전의 코드를 수행한다. 또한 끝없이 코드를 컴파일해야 한다. 그러므로 개발 생산성과 테스트 용이성을 위하여, 개발 환경의 하드웨어는 그 어떤 환경보다도 빠르고 많은 CPU 코어, 이래도 될까 싶을 정도로 많은 메모리와 디스크 용량, 가능한 예산 내에서 무조건 최대한 빠른 형태의 IO를 지원하는 디스크를 확보해야한다.
강력한 하드웨어는 개발과 동시에 빠른 피드백이 이루어지는 팀 테스트와 수정을 동시에 진행하는 경우에도 도움이 된다. 예를들어 스크럼 같은 개발 방법론을 활용하여 빠르게 개발해보고 포스트모템을 진행하는 경우, 강력한 개발 환경에서 단시간 안에 코드를 바꾸고 컴파일해서 테스트 해볼 수 있을 때 가장 효율이 좋다.

2. 테스트 환경

테스트 환경은 다양한 파트의 요청사항에 따라 끝도 없이 늘어날 수 있다는 것이 특징이다. 동일한 환경을 쉽고 간편하게, 그리고 필요에 따라 적절한 수준의 하드웨어에 배포할 수 있도록 배려하는 것이 중요하다. 스트레스 테스트를 위해서는 가능한 분리된 인스턴스에서 각각의 로그와 프로파일링 정보를 얻어내는게 중요하다면, 펀테스트를 위해서는 소수의 인원이 즐겁게 즐길 수 있도록 유도하는 환경이 되어야 한다.

보통 테스트 환경에서 코드를 컴파일할 일은 거의 없다. 즉, 새로 만든 패키지를 빠르게 배포하는 것이 중요하고, 사용자의 수나 컨텐츠의 양에 따른 하드웨어 능력의 분배가 중요하다. 또한 쉽게 배포하는 만큼이나 만들어진 서버 환경을 쉽게 회수할 수 있는 것 역시 중요하다.
그러므로 내부에서 사용할 때에는 vm으로 여러 개의 인스턴스를 관리할 수 있도록 하거나, 클라우드 등에서 저렴한 하드웨어를 필요할 때마다 만들어서 사용하는 것이 좋다.

3. 라이브 환경

라이브 환경을 결정하는 것은 보통 서버 개발자가 아니라 퍼블리셔인 경우가 많다. 물론 그렇긴해도 일반적으로 대형 퍼블리셔가 관리하는 IDC거나, 클라우드로 서버를 배포하는 경우가 가장 흔하다.
이 경우 서버 개발자가 준비해야하는 것은 동접자에 따른 전체적인 서버의 수와 구성 방식이다. 그리고 이를 위해서는 잘 구성된 스트레스 테스트 환경과 성능 프로파일링 방법이 필요하다. 그러므로 라이브 환경 설정은 테스트 환경의 연장선에 있다고 할 수 있다. 라이브 서버에 새로운 서버를 추가하는 경우에도 이는 마찬가지이다. 이 때 사용자의 분산과 추가 작업의 양을 결정하는 것은 비슷한 환경에서 얼마나 테스트를 해보았느냐에 달려있다.
또한 라이브 환경 서버 설정은 비용과 밀접한 관련을 가지게 되므로, 예상 동접은 소화할 수 있되, 노는 서버가 없도록 조율할 필요가 있다. 동시에 넉넉한 서버를 확보하기위하여 서버 개발자는 프로젝트의 책임자에게 잘 설명하여 퍼블리셔를 설득할 수 있는 이론적 기반을 마련해줄 수 있다면 금상첨화일 것이다.

지금까지 서버의 환경에 따른 구성과 이를 위해 중요한 부분은 무엇인지, 어떻게 준비해야하는지를 간단히 살펴보았다. 실제로 어떤 서버를 얼마나 준비해야하는지는 서비스 별로 가이드를 하기에 녹록치 않은 것이 사실이다. 게임마다 로직이 다르고, 장르마다 필요한 서비스가 다르다. 또한 어떤 기능을 어떻게 최적화했느냐에 따라 필요한 하드웨어의 사양은 천차만별이다. 그렇다보니 물고기를 주기보다는 물고기를 잡는 방법을 알려주라는 탈무드의 말과 같이, 주로 원론적인 내용 위주로 정리하게 되었다. 이번에도 미약하나마 서버 개발자들의 고민을 조금이라도 해결해주기를 바라며 이 칼럼을 마친다.

아이펀팩토리 박근환 TD

[NDC 2017] 아이펀팩토리 문대경 CEO 강연을 놓치지 마세요!

안녕하세요, 아이펀팩토리 사업팀입니다!

NDC 2017에 아이펀팩토리가 참여 합니다.

26일(수) 13시 ‘아이펀팩토리 문대경 CEO의 강연’과
행사 3일간 매일 진행되는 선착순 이벤트까지!

아이펀팩토리와 함께 NDC를 두 배로 즐기세요!

020304

개발자를 위한 기술 공유의 장, ‘2017 아이펀팩토리 Dev Day’ 성황리 개최!

개발자들과의 소통과 기술 공유를 위한 ‘2017 아이펀팩토리 Dev Day’가 지난 29일 수요일, 판교 엔씨소프트 R&D센터 2층 종합게임시연실에서 개최되었습니다.

지난 2015년부터 매년 개최되어 올해로 3회째를 맞이한 이번 행사는 ‘최고의 게임을 만들기 위한 최고의 기술(Great Technology for Great Games)’이라는 주제로 총 5개 강연이 진행되었으며, 아이펀팩토리 내부 개발자의 강연 이외에도 유니티 테크놀러지스코리아의 오지현 에반젤리스트가 외부 연사로 함께 하였습니다.

강연장을 가득 메운 뜨거웠던 열기의 현장으로 함께 가보실까요?

1
▲ 판교 엔씨소프트 1층에 마련된 등록데스크! 줄이 어마어마 하죠잉?

입장 1시간 전부터 줄이 길게 늘어선 판교 엔씨소프트 1층 등록데스크의 전경입니다. 줄이 어마어마 하죠? 2015년부터 매년 개최된 Dev day 중 사전등록 신청률이 가장 높았던 행사였던 만큼 게임관련학과 학생부터 현직 개발자에 이르기까지 다양한 소속의 분들의 참석하셨답니다.

2▲ 엔씨소프트 R&D센터 2층 강연장 앞

짜잔~ 2층 강연장 앞에서는 이번 행사에 참석해주신 분들을 위해 아이펀팩토리가 성심 성의껏 준비한 점심식사와 선착순 기념품이 준비되어 있었습니다. 안타깝게도 선착순 기념품을 받지 못하신 분들! 너무 아쉬워 마세요~ 다음 데브데이가 있으니까요!

자, 이제 강연장 안으로 들어가볼까요?

3▲ 아이펀팩토리 문대경 CEO의 인사말

엔씨소프트 2층 R&D센터 강연장을 가득 채운 뜨거운 열기! 느껴지시나요?
금일 행사에 강연자로서 직접 참여한 아이펀팩토리 문대경 CEO는 본격적인 행사에 앞서 “데브데이의 취지는 상업적인 내용을 배제하고 기술적인 내용을 공유하는 것”이라며, “이번 행사를 통해 개발자들이 서로 가깝게 이야기할 수 있는 소통의 채널이 되길 바란다”고 행사의 개최 의의를 말씀하셨습니다.

문대경 CEO의 인사말에 이어 본격적인 개발자 토크콘서트, 시작합니다!

5▲ 강연1. 아이펀팩토리 박근환 TD의 ‘혼자서 만드는 MMO 서버’

6▲ 강연2. 아이펀팩토리 민영기 TD의 ‘Python 과 AWS 를 이용하여 게임 테스트환경 구축하기’

7▲ 강연3. 아이펀팩토리 김진욱 CTO의 ‘게임 서버 성능 분석하기’

8▲ 강연4. 유니티테크놀로지스 오지현 에반젤리스트의 ‘유니티 쉐이더 단기 속성’ (출처: 인벤)

9▲ 강연5. 아이펀팩토리 문대경 CEO의 ‘게임 서버 구축 방법 비교: GBaaS vs. Self-hosting’

지금까지 알찬 강연으로 진행된 2017 아이펀팩토리 Dev Day 현장을 함께 보셨습니다.

게임 서비스에 있어 서버 개발과 운영이 중요한 만큼, 거시적인 관점에서 개발자에게 실질적으로 필요한 것들을 공유할 수 있는 값진 시간이었답니다.

이번 데브데이에 함께하지 못해 아쉬우시다구요? 그런 분들을 위해 저희 아이펀팩토리는 강연 자료를 공개합니다. 아래 링크를 꾸욱~ 누르시면 데브데이 강연 자료를 보실 수 있어요! 지금 바로 고고고!

강연1. 아이펀팩토리 박근환 TD의 ‘혼자서 만드는 MMO 서버’

강연2. 아이펀팩토리 민영기 TD의 ‘Python 과 AWS 를 이용하여 게임 테스트환경 구축하기’

강연3. 아이펀팩토리 김진욱 CTO의 ‘게임 서버 성능 분석하기’

강연4. 유니티테크놀로지스 오지현 에반젤리스트의 ‘유니티 쉐이더 단기 속성’

강연5. 아이펀팩토리 문대경 CEO의 ‘게임서버 구축 방법비교: GBaaS vs. Self-hosting’

[오피스N_굿피플] 아이펀팩토리 민영기 CTO인터뷰

굿피플 직무의 시작

Intro
하나의 직무를 선택한다. 그리고 거기에 맞는 회사를 선택해서 지원한다. 이는 취업 준비생의 취업 과정이다. (물론 회사를 먼저 선택하는 경우도 있다.) 그렇게 입사하면, 해당 직무에 대한 역량을 쌓는다. 그리고 2~3년 차를 맞이하면, 두 분류로 나뉜다. 담당 분야에 계속 집중하거나 다방면으로 경험을 시도한다. 얼마 전 만난 아이펀팩토리의 민영기 개발자는 후자에 속한다. 클라이언트 개발자로 시작했지만, 서버 플랫폼 개발자, 서버 개발자로 직무를 변경해가며 자신만의 역량을 쌓았다. 그는 이런 경험이 있었기에 개발자로서의 시야를 넓혔다고 한다. 이제는 또 다른 환경에서 게임 운영에 집중 중인 그의 이야기를 지금 시작한다. By 굿피플 헌터.

ff705b76-f95b-42eb-9424-8adbc87ad4ec.jpg

나는 어릴 적부터 게임을 좋아했어. 그래서 게임을 만들 수 있는 직종 중에 프로그래머를 택했지. 그 시작은 NHN에서 이뤄졌어. 게임 클라이언트 개발을 담당했는데, 개발의 핵심 로직을 서버로 이관하는 작업을 진행하는 분야야. 그렇게 3년간 일했어. 그리고 다른 분야에서 경력을 쌓고 싶어서 내부에서 서버 개발자로 직무를 변경했어.

서버 개발자는 게임 개발도 중요하지만, 게임 운영 지원에도 신경을 많이 써야 해. 게임 개발에 집중하면 될 거라는 내 생각과는 달랐지. 그때 깨달았어. 어느 분야든 부딪히는 문제점은 발생하고, 나는 다방면으로 일하고 싶은 성향이라는 점을 말이야. (웃음) 그래서 네오위즈게임즈로 이직하여 서버 플랫폼 작업을, AINA에서는 RPG와 보드게임의 개발을 했어. 개발자로서 여러 환경에서 일하면서 나만의 역량을 쌓았어.

게임 서버 개발자로 일하면서 게임 운영에 대한 고민을 많이 했어. 그때 아이펀팩토리가 게임 운영을 지원하기 위한 제품을 만든다는 말을 듣고 지원했어.

굿피플 인터뷰 본문 더보기>

SQL 의 CAP 이론과 NoSQL 의 BASE

CAP 이론

분산 시스템 설계에 많이 인용되는 CAP 이론은 UC Berkeley 의 Eric Brewer 교수님이 제안한 개념이다. 분산 시스템 설계니 당연히 한 대의 서버로 이루어진 시스템이 아니라 여러 서버로 이루어진 시스템을 가정하는데, Consistency, Availability, Partition Tolerance 라는 세 가지 속성의 약자를 따서 CAP 라고 이름이지어진 이 개념은 Partition tolerance 한 시스템을 구현하기 위해서는 Consistency 나 Availability 둘 다를 얻을 수 없음을 의미한다. 좀 더 쉽게 말하면 C, A, P 이 세 속성 중에 기껏해야 두 개 밖에 취할 수 없다는 뜻이다.

여기서 Consistency 는 다른 서버에서도 가장 최근에 쓰여진 데이터가 읽혀야 됨을 의미한다. 예를 들어 A 와 B 라는 서버가 분산 시스템을 구성하고 있다면, A 라는 서버에 데이터를 쓰면 그 바로 뒤에 B 서버에서 누군가 그 데이터를 읽어들일 때 가장 최근의 데이터를 읽을 수 있어야 됨을 뜻한다.

Availability 는 보낸 요청에 대해서는 응답을 줄 수 있어야 됨을 의미한다. 그 응답이 가장 최근의 응답이 되었든, 아니면 살짝 이전의 데이터가 되었든말이다. 이 자체로는 너무 쉽고 당연한 것 같지만, 시스템이 “가장 최근의 데이터만을 줘야된다” 라는 제약이 붙게 되면, 가장 최근인지 아닌지 판단을 할 수 없는 경우 응답을 보내지 못할 수도 있게 된다는 점을 기억하자.

Partition tolerance 는 서버간의 통신에서 설령 네트워크가 끊긴 수준의 오류가 있더라도 시스템이 동작해야됨을 의미한다.

.

RDBMS 와 ACID 속성

RDBMS 는 Relational Database Management System 의 약자이다. 우리가 보통 DB 라고 말하는 것은 원칙적으로 DBMS 를 의미한다. 그러니 RDBMS 도 보통 RDB 라는 이름으로 부르기도 한다. R에 해당하는 Relation(al) 은 “데이터를 테이블 형태” 로 관리함을 의미한다. SQL 서버들이 테이블을 만들고 그 안에 데이터를 저장하는 것을 기억하는가? SQL 쿼리 문도 “CREATE TABLE …” 로 시작한다. 바로 SQL 이 RDB 이기 때문이다. 우리가 일반적으로 사용하는 DB 들은 이 RDB 형태들이다.

전통적인 RDB 에서는 Network Partition 을 크게 고려하지 않았다. DB 는 같은 데이터센터 안에, 심지어 같은 랙에 존재하고 있고 그 때문에 서버간 통신은 굉장히 잘 관리가 되는 안정적인 상황이었기 때문이다.

대신 RDB 에서는 ACID 라는 속성을 중요하게 생각해왔다. Atomicity, Consistency, Isolation, Durability 의 약자를 모아서 단어를 만든 것이다.

Atomicity 는 관련된 작업들은 전부 반영되거나 아니면 하나도 반영이 안되거나 해야된다는 것을 의미한다. “All or nothing” 인데, 쉽게 생각해서 우리가 SQL 에 transaction 을 만들면 그 안의 작업들이 모두 다같이 반영되어야 되는 것을 생각해보면 이해가 쉬울 것이다.

Consistency 는 CAP 의 consistency 와는 약간 다르다. CAP 에서는 서로 다른 서버라 하더라도 가장 최근 데이터를 반환함을 의미하지만, 여기서 consistency 는 DB 의 상태가 늘 일관된 상태를 유지해야됨을 의미한다. 예를 들어 DB 데이터의 속성이나 테이블 내 제약 등이 지정되어있는 경우 이를 준수하는 상황이 계속 일관되게 이어져야 된다는 것이다.

Isolation 은 여러 작업이 실행되더라도 그것이 순차적으로 실행된 것과 같은 결과를 내야됨을 의미한다. 만일 두 작업이 겹치는 것이 아예 없다면 이는 전혀 상관없이 동시에 실행될 수 있어야 되고, 만일 겹치는 부분이 있으면 순서대로 처리가 되어야지 겹쳐서 처리되어 데이터가 이상한 상태가 되어서는 안된다는 것을 뜻한다.

Durability 는 일단 작업이 완료 되었다고 리포팅이 되었다면 그게 DB 에 영구적으로 반영이 되어야 함을 의미한다. 설령 DB 가 크래쉬 하더라도 말이다.

.

NoSQL 등장의 배경

앞서 언급한 것처럼 DB 에서는 Partition 의 상황보다는 ACID 를 훨씬 중요한 가치로 생각을 하고 그쪽으로 많은 연구들이 이루어졌다. 그러나 구글이나 아마존, 페이스북 등 인터넷 회사들의 경우 데이터 센터가 여러곳에 분산되는 것이 일반적이다. 그런데 DB 는 한 곳에서만 가져다가 써야된다고 하면 이는 성능상의 큰 병목이 될 것이다. 그때문에 DB 역시 여러곳에 분산을 해야되는 상황이 되었고, 이 때문에 partition tolerance 를 중요한 가치로 인식하게 되었다.

앞에서 Partition tolerance 를 취하면 consistency 나 availability 둘 중 하나 밖에 취할 수 없다고 말을 했다. 그런데 실제 상황에서 consistency 가 그렇게까지 강하게 요구되지 않는 경우들이 많다는 것을 알게 됐다. 구글 검색을 했는데, 방금 crawler 가 긁어온 최신의 데이터를 꼭 보여줘야될 필요는 없지 않은가. 친구가 facebook 에 글을 쓰고 1-2초 지나서 내 화면에 뜬다고 문제가 될 건 없는 경우 등도 마찬가지다.

그래서 consistency 를 좀 약하게 보장하고 대신 시스템의  availability 를 좀 더 보장하는 방법들이 소개 되기 시작했다. 이 때 나온 개념이 eventual consistency 이다. 어느 한쪽이 데이터를 쓰더라도 다른쪽이 가장 최근의 데이터가 아니라 그 전의 데이터를 볼 수 있음을 의미한다. 이렇게 되면 “요청에 응답을 보내야 한다” 라는 availability 기준이 “이전 데이터라도” 보낼 수 있게 되니 크게 향상될 수 있다.

기존에 데이터를 쓰면 다음에 데이터를 읽는 쪽에서는 가장 최근의 데이터를 받아야 된다는 것은 이와 대비해서 strong consistency 라는 표현을 쓴다.  그리고 이런 속성의 DB 는 strong consistency 의 RDB 와는 사뭇 다르다. 그래서 기존의 SQL 과 다른 DB 로 NoSQL 이라는 이름을 얻게 되었다.

이런 속성으로 SQL 의 ACID 에 대응하는 NoSQL 의 주요 속성으로 BASE 를 이야기 한다. Basically Available, Soft-state, Eventual consistency 의 약자를 딴 것이다.

.

게임에서의 SQL 과 NoSQL 의 적용

NoSQL 이 처음 소개되었을 때에는 그것이 새로운 개념이다보니 기존 SQL 을 대체하는 우월한 개념처럼 잘못 인식되곤 했다. 하지만 SQL 과 NoSQL 은 가정하는 상황이 완전히 다른 별개의 솔루션들이다. 풀어야 되는 문제가 다르면 다른 솔루션을 적용해야되는 것처럼, SQL 과 NoSQL 역시 필요에 따라 다르게 사용하는 것이 바람직하다.

앞서 설명한 것처럼 SQL 은 strong consistency 를 보장한다. 그 때문에 consistency 가 중요한 상황에서는 SQL 이 더 적합하다. 그 때문에 많은 경우에 유저 데이터를 SQL 에 저장하는 것이다.

NoSQL 은 partition tolerance 와 availability 가 중요한 상황에서 유용하다. 디비가 먼 지역에 분산되어있고, 반드시 최신 데이터를 보여주지 않아도 되는 경우에 유용할 수 있다. 아니면 적어도 몇초 나 몇분 단위로 싱크만 맞아도 되는 경우라면 적합하다. 이런 이유로 많은 경우에 로그데이터를 NoSQL 에 저장하기도 한다.

이번 컬럼에서는 SQL 과 NoSQL 이 어떤 이유로 나오게 되었고 각각 어떤 것을 중요하게 생각하는지를 설명했다. 어떤 경우도 만능의 솔루션은 없다. 한 선택에 의한 트레이드 오프는 필연적이라고 할 수 있다. 각 솔루션의 배경에 맞게 적절하게 사용하는 것이 무엇보다 중요하다.

아이펀팩토리 문대경 대표

[이벤트] 아이펀 엔진 캐릭터의 이름을 공개합니다!

안녕하세요! 아이펀팩토리 사업팀입니다.
많은 분들의 참여로 ‘아이펀 엔진 캐릭터’의 멋진 이름을 선정할 수 있었습니다.
서버개발에 대한 소원지기 ‘엔지니’를 소개합니다!!
서버에 대한 당신의 소원, 고민! 엔지니가 해결해 드릴게요!

멋진 이름으로 이벤트에 참여해 주신 모든분들 감사합니다!!

엔지니 이름발표-4.jpg