Overview jwkim2

목표 설정하기

항상 일을 시작하기에 앞서서 목표를 명확하게 설정하는 것이 중요합니다.

저희의 추상적인 1차 목표는 재미있고 돈을 많이 버는 게임을 만드는 것입니다.
이 추상적인 목표를 조금씩 구체화해 나가도록 하겠습니다.

재미와 돈이라는 추상적인 목표는 누구도 명확하게 정의할 수가 없습니다. 재미라는 것이 주관적인 요소이고 그 주관적인 요소를 가지고 불특정 다수를 만족시키면서 돈을 버는 방법을 찾는 다는 것은 쉬운 일이 아닙니다. 재미있는 게임, 돈을 버는 게임이라는 것을 정의하고 기획할 수 있다면 그 사람의 연봉과 기업 가치는 수천억을 상회할 것 같습니다. ^^;;

그럼에도 불구하고 게임은 계속 쏟아져 나오고 성공을 하고 실패를 반복합니다. 매일 앱스토어에 등록되는 수천, 수만의 게임들을 보면 수만 번의 실패 끝에 한번의 성공으로 바도 무방할 것 같습니다.

게임은 수만번의 시도 끝에 창의적이고 다양한 아이디어를 가지고 유저를 만족시키고 그에 상응하는 수익을 번다고 볼 수 있습니다. 그 시도는 기획자의 머리 속에서 일어날 수도 있고, 사내 알파/베타 테스트를 통해 판단하거나, 시장에서 직접 유저에게 판단을 받을 수도 있습니다. 물론 좋은 게임을 만들기 위해서는 게임의 방향성, 타케팅, 마케팅, 기획 능력, 그래픽 등 다양한 요소들이 갖춰줘야 하지만 본 블로그는 개발자들(특히 프로그래머)들을 위한 내용으로써 개발 외적인 부분들은 같이 일하는 회사와 팀원을 믿고 최선을 다하고 있다고 생각합시다.(^^;)

요즘 게임 트렌드는 3개월에 마다 한번씩 바뀐다고 합니다. 3개월도 안돼서 새로운 게임이 트렌드로 자리 잡고 또 3개월이 지나면 다른 장르와 다른 형태의 게임이 트랜드로 자리 잡습니다. 이와 같은 빠른 트렌드의 변화는 개발의 생산성이 매우 중요합니다.

이를 바탕으로 비즈니스 측면에서 보면 동일한 게임을 만드는데,
1달간 500만원을 들여서 게임을 만드는 것과
2주일간 1000만원 들여서 게임을 만드는 것
당연히 후자를 택하게 됩니다. 돈을 두배로 쓰더라도 빨리 만들면 기회 비용이 더 커집니다. 좋은 게임이라도 트렌드를 못 따라가면 망하기가 쉽습니다.

트렌드가 된 기술들은 왜 트렌드가 되었을까?

글 쓰는 시점 프론트엔드의 트렌드 기술은 Angular, React, Vue 3가지 정도입니다. 3가지 프레임워크를 비교해 보면 각자 장단점이 있지만 대부분 지원하는 기능은 동일합니다. 최근 들어서는 Github 에서 Vue 가 Angular, React 를 제치고 1위를 하였습니다. 그럼 비슷함에도 불구하고 vue가 약진을 한 이유는 바로 생산성 때문입니다. 여기서 말하는 생산성이란 단순히 코드를 짜서 나오는 아웃풋 뿐만 아니라 Vue를 시작하는데 처음 공부를 하는 러닝 커브까지 포함입니다. vue는 다른 프레임워크에 비해서 빨리 배워서 빨리 쓸수 있게 만들어져 있습니다. 요즘은 아무리 좋은 프레임워크라도 러닝 커브를 포함한 생산성이 떨어지면 트렌드 기술이 되기 쉽지 않습니다.

결론은 생산성

게임의 성공을 위해서 우리가 해야 하는 2차적인 목표는 기술력과 빠른 생산성입니다.
기술력을 통해 창의적인 기획을 바로 개발이 가능하고 생산성을 통해 다양한 시도를 하고 빠른 결과를 낼 수 있게끔 하는 것입니다. 안타깝게도 기술력이라는 것은 기술에서 나오는 것이 아니고 경험에서 나오는 것이라 기술력이 없는 회사 입장에서 기술력을 키워 나가기 보다는 그냥 기술력을 가진 사람을 뽑는 것이 수월하고 효율적입니다. (개인적인 의견입니다. 물론 기술력 좋은 사람이 온다고 다 해결되지는 않습니다. 또한 회사 차원에서 사내 인재에 투자하고 기술을 쌓아 가는 편이 장기적으로 더 건전하지만 왠만한 자금력과 수뇌부의 인내심이 있지 않고서는 현실적으로 힘듭니다.) 안정성, 운영 능력등은 다 기본적으로 수반되야 하는 것임으로 논의하지 않습니다.

장황하게 설명했지만, 사실 모든 한국 IT 업계의 요구 사항도 빠른 개발입니다. 그냥 매일 빨리빨리 개발해 달라고 하고 무리하게 일정 잡고 그거 맞추려고 야근하는 것이 한국 IT의 현실이기도 합니다. (저희 회사가 그렇다는 것은 아닙니다. ^^;)

기술 선정하기

좋은 기술이란 무엇일가?

트렌드 기술? 생산성이 높은 기술? 러닝 커브 낮은 기술? 관리 코스트가 낮은 기술?

콘웨이의 법칙

Conway's Law
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

1968년 멜빈 콘웨이는 “모듈 프로그래밍 국제 심포지움”에 가서 논문을 하나 발표합니다. 그 핵심 내용이 이렇습니다. 직역하면 "소프트웨어 구조는 해당 소프트웨어를 개발한 조직의 커뮤니케이션 구조를 닮게 된다." 라는 뜻인데 제 방식대로 해석하자면 "기술이 조직구조에 종속되게 된다"는 뜻입니다.

기술이 조직구조에 종속된다고? 이게 말이야? 말밥이야? 하실 수 있는데 더 풀어서 설명을 하겠습니다.

A라는 조직이 서버팀/웹팀/디비팀 으로 운영을 한다고 하면,
각 팀은 자기 팀에 맞는 최적화된 기술을 찾고 개발하게 됩니다. 서버는 백엔드 기술을, 웹팀은 프론트엔드 기술을, 디비팀은 디비에 집중 할 수 있는 기술을 사용합니다. 사람을 뽑을 때도 각 팀에 맞는 기술에 해당하는 사람을 채용하게 됩니다.

B라는 조직은 프로그램팀을 하나로 운영합니다.
B조직에서는 서버/웹/디비의 경계선이 없이 Full Stack 기반의 개발을 합니다. 당연히 사용하는 기술은 Full Stack 기반의 프레임워크를 사용하며 사람을 채용할 때도 프론트엔드와 백엔드를 같이 할 수 있는 사람을 채용합니다.

그냥 얼핏봐서는 그냥 무조건 다 할 줄 아는 사람 뽑아서 하나로 운영하면 되는게 아니냐 할 수도 있는데, 조직의 구조는 개인이 결정할 수 있는 부분이 아니기 때문에 쉬운 문제가 아닙니다. 이미 조직이 3 Tear 방식으로 운영하고 있다고 하면 기존 개발자들을 다 재교육을 시켜야 하기 때문에 Full Stack 으로의 전환은 더 힘들게 됩니다. 게임 개발에 있어서도 서버/클라이언트팀을 딱 나누어져 있는 경우가 많은데, 생산성을 올리기 위해서 Full Stack 처럼 Data driven 개발 방식을 적용하고 싶어도 서버는 서버만, 클라이언트는 앱만 처다 보게 됩니다. 이는 CTO 가 회사의 방향과 역량, 인재 수급 능력 등을 고려하여 조직 설계와 기술 방향성을 지속적으로 리드해야 하는 중요한 이유입니다.

간단히 정리하면 좋은 기술이 있다고 쓰는 것이 아니고 조직에 맞는 기술을 맞춰서 쓸 수밖에 없게 되기 때문에 기술을 선정함에 있어서도 조직 구조와 역량을 잘 파악해야 하고 팀에서 잘 활용할 수 있는 기술을 선정해야 합니다.

우리 기술 선정 기준

저희 팀은 중기 프로젝트 1개와 단기 프로젝트 여러 개를 동시에 개발을 하며 개발 사이클이 짧은 편입니다. 작은 규모 팀이라 한 사람이 여러 프로젝트를 담당해야 함으로 운영 및 관리 코스트도 낮아야 합니다. 이와 같은 상황에서 기술 선정을 위해 다음과 같은 키워드로 정리됩니다.

Serverless: 빠른 생산성과 서버 비용, 운영 및 관리 코스트의 절감
Modularize: 모듈 단위 재활용성과 동시 유지 보수
Micro Service: 서비스 단위 재활용성과 확장성
Data Driven: 데이터/클라이언트 주도의 개발 생산성
협업: 웹 기반의 통합 허브를 활용한 개발 생산성 향상 및 관리 코스트 절감

DevOps나 Agile 등은 필수 사항입니다.

Serverless

요즘 서버 사이드의 화두는 Serverless 입니다. 여기저기서 Serverless, Serverless 하는데 정확히 왜 Serverless를 사용하는지, 그래서 얻는 이득이 무엇인지를 살펴보아야 합니다.
보통 Serverless 하면 비용 절감 얘기가 많이 나옵니다. 기존의 AWS에서 EC2, GCP의 Compute Engine, Azure의 VM들과 같은 인스턴스 기반의 구조는, 제가 주로 하는 표현으로 "숨만 쉬어도 돈이 나간다"라고는 합니다. 내가 인스턴스를 사용하든 안 하든 무조건 시간당 비용을 내야 하지만 Serverless 방식은 기본적으로 콜당 비용이 발생하기 때문에 콜이 없으면 비용 발생이 전혀 없습니다. Serverless 방식은 숨 쉬는데 돈이 발생하지는 않습니다. 물론 인스턴스 방식도 비용 절감을 위해서 Scale Up, Scale Out 등이 존재하고 Auto Scale 등을 통해서 최대한 관리 부하도 줄이려는 노력을 하고 있지만 매번 서비스에 따라서 해당 설정을 해줘야 하고 모니터링을 하고 설정을 바꿔주고 하는 등 운영/관리 부하가 존재하고 콜이 없으면 비용이 전혀 없는 Serverless 방식과는 비교할 수가 없습니다.

하지만 중요한 사실은 비용 때문에 사람들이 Serverless 를 선택한다고 생각하면 큰 오산입니다.
만약 Serverless 방식이 비용이 인스턴스 방식보다 절반의 가격이라고 가정하고 설치 구축, 운영 및 관리에 드는 시간이 인스턴스 방식에 보다 두배가 된다고 하면 지금처럼 트렌드 기술이 되지 않았을 것입니다. 위에도 설명했듯이 특히나 빠르게 변하는 게임 분야에서 개발 및 운영 코스트가 증가되는 기술은 비용이 절감이 되더라도 트렌드 기술이 되기 힘듭니다.

Serverless 방식이 왜 트렌드가 되었을까?

이를 제대로 이해하기 위해서는 Serverless 방식에 대한 더 깊은 이해가 필요합니다.
단순하게 생각하면, '인스턴스 방식은 서버를 구축하면서 OS를 설치 또는 설정하고 앱을 설치하기 위한 환경 구축 및 운영/관리 등 다양한 작업이 수반되나 Serverless 는 서버가 없기 때문에 그냥 앱만 배포하면 된다' 입니다. 하지만 요즘 DevOps 와 더불어 CI/CD, Docker 를 통해 앱과 환경 배포가 같이 이루어지기 때문에 이 또한 주요 이유가 되지 않습니다. (DevOps에 대하여는 차후 별도 연재하겠습니다.)
깊게 들어가면 우리는 서버가 왜 필요한가부터 생각해 보아야 합니다. 궁극적으로 우리는 어플리케이션(이하 앱)이 필요한 것이지 서버 자체가 필요한 것이 아닙니다. 만약 서버가 없이 앱이 구동이 된다면 서버가 필요가 없습니다. 앱은 Web이 될 수도 있고 백엔드 API 가 될 수도 있고 DB등 다양한 형태가 될 수 있습니다. 앱을 구동하기 위해서 OS가 필요하고 OS가 구동하기 위해서 가상이든 물리적이든 서버가 필요하기 때문에 서버를 사용하는 것이지 서버가 필요해서 서버를 사용하는 것이 아닙니다. 이 글을 보시는 분들 정도면 Serverless 가 정말 서버가 없다고 생각하시지는 않을 것이고, "서버라는 자원을 추상화시켜 뒤로 숨기고 앱이 구동하는 환경만 갖춰줘서 서버를 직접 관리/운영하는 비용을 감소시키고 앱의 비즈니스 로직에 집중할 수 있게끔 해준다" 라고 알고 계신 분들이 많을 텐데, 여기까지도 Serverless 가 왜 트렌드가 되었는가에 대한 설명으로는 좀 많이 부족하다고 생각합니다.

제가 생각하는 Serverless 방식이 트렌드가 된 이유는 크게 2가지입니다.

첫째, 아키텍처 때문입니다.

정확히 말하면 Serverless 방식을 사용함으로써 수반되는 아키텍처가 현실에서 요구하는 사항과 부합이 되기 때문입니다. 좀 풀어서 설명하면, Serverless 는 기본적으로 Function Base 입니다. Function 단위로 제작하고 Function 단위로 배포합니다. 이와 같은 환경은 로직을 컴팩트하고 기민하게 만들 수밖에 없습니다. 하나의 Function 에서 모든 일을 다 처리할 수는 없기에 로직이 작은 단위로 나뉘고 로직끼리의 긴밀한 관계를 가지게 됩니다. 이는 코드가 간결해지고 단위 로직당 이해를 쉽게 만들어서 유지보수/관리의 비용이 줄어 들게 됩니다. 단순히 Function 하나만으로도 작동 할 수 있고, 덩치가 작음으로서 빠르게 변하고 빠르게 움직일 수 있습니다. 이러한 개발 방식은 빠른 생산성을 요구하는 현재 IT 시장에 부합합니다. 더 크게 보면, Agile(한국어로 '기민한') 방식의 개발과도 맞물리게 됩니다.(차후 마이크로서비스하고도 연계됩니다.) Agile 을 하게 되면 Water Fall 방식으로 큰 서비스를 한번에 구축하기 보다는 작은 기능부터 하나씩 붙여 덩치를 키워 나갑니다. Serverless 의 Function Base의 개발 방식은 전체 설계에 집중하기 보다는 부분적인 Feature 에 집중하는 Agile 개발 방식과 잘 맞아 떨어집니다.
제가 위에서 언급한 기술이 조직 구조에 종속이 된다는 말을 기억하시나요? 개발 환경과 개발 방식에 아키텍처도 종속이 됩니다.(정확히 말하면 종속이라는 표현보다는 Dependency(의존성)이라는 표현이 맞지만 한국어로 좀 강하게 의미를 표현하다보니...)

둘째, Vendor들 때문입니다.

글 쓰는 시점에서 주요 클라우드 서비스 Vendor 는 AWS의 AWS, Google 의 Firebase, GCP(Google Cloud Platform), Microsoft 의 Azure 정도입니다. 각 클라우드의 주된 Coumpute 계열 Serverless 서비스는 Lambda(AWS), Functions(Firebase, GCP), Functions(Azure) 입니다.(Compute 계열이란 로직을 담당하는 부분이고 Database등과 관련된 Serverless 서비스도 있습니다.) 공교롭게도 Lambda 를 제외하고는 이름도 동일하게 Functions 라는 서비스입니다. 아까 말씀드렸듯이 Serverless 는 Function 을 기본으로 하기 때문입니다.

몇 년 전부터 갑자기 Serverless 라는 것이 화두가 되었고 각 Vendor 들이 Serverless 관련 기술을 발표하고 온갖 세미나에서 해당 기술을 밀기 시작했습니다. 상식적이지만 우리는 클라우드 서비스를 사용하고 있고 클라우드 서비스 Vendor 에서 미는 기술이 아니면 활성화되기 힘듭니다. 그럼 "왜 각 Vendor 들에서 Serverless 기술을 밀게 되었을가?"를 생각해 보겠습니다.

Vendor 입장에서 생각해보면 기존의 서버 인스턴스 방식을 운영하기 위해서는 고객이 사용하는 사용량보다 보다 훨씬 큰 가용성을 확보하고 있어야 합니다. 물리적으로 훨씬 큰 가용성을 갖춰 놓지 않으면 수용량이 바닥이 낮을 때 고객에게 "잠시만요. 저희가 IDC 에서 서버 몇대 더 넣고 알려드릴게요. 조금만 기다리세요."라고 할 수는 없으니까 최소한 수십, 수백배 이상의 가용성을 갖춰 놓게 됩니다. 결국은 항상 남는 서버들이 생기게 되고, Vendor 들은 해당 부분을 어떻게 활용하고 수익화 할가를 고민하다가 예약 인스턴스를 통해서 쭉 사용하는 사람들에게 할인 혜택을 준다던 지, 스팟 인스턴스등을 통해 남는 자원을 싼 값에 짧게 사용할 수 있게 합니다. 하지만 여전히 물리적 자원은 남아 돌고 이 것을 활용하기 위한 방법으로 Function 이라는 것을 고안해 냅니다. Function 이라는 것을 더 잘 이해하기 위해서는 기존 인프라 운영 방식에 대해서 약간의 설명이 필요합니다.

인프라 운영을 해보신 분들은 알겠지만 서버 운영에서 큰 번거로운 부분이 HA(high availability)와 DR(Disaster Recovery)입니다. 이는 서버가 가상이든 물리적이든 상시 켜져 있어야 하고 고정이 되어 있는데도 불구하고 장애 발생시에도 문제없이 돌아가야 하기 때문입니다. 인프라팀 입장에서는 서버를 많이 사용하는 것보다 계속 켜져 있는 것이 더 골치가 아픕니다. 운영체제 업데이트도 해야 하고, 보안 패치도 해야 하고, 서비스단의 Rolling Update 도 대응하고 간혹 물리적인 장애에 대해서도 대응을 해야 하는데 서버는 계속 켜져 있어야 하기 때문입니다. (인프라 운영에 대해서 하고 싶은 얘기도 많고 설명할 부분이 많으나 지면과 논지상 다른 연재로 미루고 좀 단순화시켰습니다.) 인프라팀 입장에서는 이 계속 켜져 있다라는 전제 조건만 지우면 "땡큐!" 를 울부 짖으며 엄청나게 쌍수를 들고 환영 할 만한 내용입니다. HA를 하던 DR을 하던 간에 들어오는 콜에 대해서는 네트워크 단에서 라우팅하고 물리적이든 가상이든 지역이든을 떠나서 어디로든 앱을 쉽게 포워딩 시킬 수 있기 때문입니다. (Docker와 Orchestration 등의 기본 지식이 없이는 제대로 이해하기가 힘들 수도 있을 것 같습니다. 차후 DevOps 편에서 연재하고 여기서는 이해를 돕기 위해서 추상적으로 설명했습니다.) HA와 DR을 예로 들었지만, 실상 앱을 어디로든 포워딩(설치 및 배포)가 가능하다면 물리적으로 남는 자원을 얼마든지 활용할 수가 있게 됩니다. 여기서 전제 조건은 앱 자체가 State 를 갖지 않고 앱의 실행시간이 짧아야 된다는 것입니다. 이것이 바로 클라우드 서비스에서 제공하는 Function 입니다. (혹시나 앱이 어떻게 State 를 갖지 않을 수 있지? 라고 반문하신다면 Restful API 에 대해서 찾아보시면 좋을 것 같습니다. 기본적으로 Restful API 는 State 를 가지지 않습니다. 그리고 보통 Consistent한 State가 필요한 경우 DB를 활용합니다.)

클라우드 서비스들의 Function은 기본적으로 상태를 가지지 아니하고, 짧은 Runtime(15분 미만)정도만 사용할 수 있습니다. (15분 이상의 Job은 Job을 분할하여 동시에 parallel로 진행이 가능합니다.) 이러한 전제 조건으로 인해 클라우드 서비스 Vendor 들은 가지고 있는 남는 자원들을 거의 무한정 활용할 수 있게 됩니다. 여기서 거의 무한정이라는 말은 어차피 인스턴스 기반의 서비스는 사람들이 사용하고 앞으로도 사용 예정이라 중지할 수가 없고, 가용성은 확보해논 상태에서 분단위 이하의 Function 들은 그 남는 자원 한도내에서 충분히 운영을 하고도 남기 때문입니다. 내부적인 아키텍처를 조금 설명 드리면 클라우드 서비스의 Function 들은 대부분 남는 인스턴스 위에 Docker 기반으로 배포되고 Function 작동이 끝나면 Docker 와 함께 종료되어 버립니다. Vendor 들 입장에서는 현실적이지는 않지만 모든 유저가 Function 을 사용하는 것이 가용성을 컨트롤 하기가 훨씬 수월해지고 가용성 확보양을 기존의 인스턴스 방식보다 훨씬 줄일 수 있습니다.

정리하면, Serverless 라는 기술이 트렌드가 된 이유에는 빠른 대응 및 생산성을 요구하는 현재 IT 시장의 요구 사항을 시작으로 Agile, Micro Service 아키텍처의 등의 개발 방식, 서버 비용 절감, 관리 및 유지보수 비용을 낮추기 위한 인프라팀의 노력 또는 DevOps 개발 환경과 더불어 클라우드 Vendor 들의 남는 자원의 활용 및 수익화 및 마케팅 등이 박자가 잘 맞아서 이루어진 산물입니다. 개발자 입장에서 현재 개발 환경과 맞으며 비용 절감까지 되니 마다 할 이유가 없습니다. 모든 일이나 현상이 그렇지만 한 두가지 이유로 트렌드가 되거나 기술 자체가 주가 될 수는 없습니다. 언급한 내용 말고도 Node 및 생태계의 확장등 "닌텐도의 경쟁 상태는 나이키다" 같이 전혀 연관성 없어 보이지만 연관이 있는 다양한 이유가 더 많이 있기는 하나 이 정도로 줄이고, 대부분 세미나에서 Serverless 라는 것을 설명 할 때 인스턴스 방식과의 비용 비교 차트 및 도표 등만을 내세워 단순히 싸고 관리 용이 방식으로 설명하는데 아마도 짧은 시간 동안 이런 내면적인 구조를 다 설명하기 힘들어서 그런 것 같습니다. 항상 기술을 먼저 볼 것이 아니고 생태계를 봐야 합니다. 기술은 그 다음입니다.

TIP

제가 보통 검색을 할 때, Fact 를 보려면 Reference 를 보고 견해를 보고 싶으면 블로그를 봅니다. 이 블로그를 보시는 분들은 정확한 사실 보다는 그 사람의 견해를 듣고 싶어서라고 생각하고 있습니다. 사실만 원한다면 해당 회사의 발표 자료만 보면 됩니다.(머 그마져도 사실이 아닐 수도 있지만요.) 불특정 다수를 대상으로 하는 블로그의 특성상 구독자의 범위를 가늠하기 쉽지 않습니다. 이러한 연유로 본 블로그는 최대한 이해를 돕기 위해서 추상화하고 사실이 아닌 얘기도 그냥 적시하고 있습니다. 실질적인 예로 위에서 언급한 Function 은 한번만 실행이 되고 종료하거나 하지 않고, 내부적인 Orchestration 및 최초 시작시 Cold Booting 및 재활용등 복잡한 내용들이 많으나 해당 내용만 설명하기에도 지면이 부족하여 본문에서는 그냥 한번씩만 실행되고 종료된다라고 표현했습니다. 또한 Vendor들이 꼭 남는 자원을 활용하려고만 Function 을 고안한 것은 아닙니다. 중간중간 사실을 전부 적시하고 설명하기에는 논지가 흐려져서 서술이 힘듭니다. 전체적인 맥락과 견해로 보시고 정말 자세한 내용을 알고 싶으신 분들은 Reference 찾아보시기를 권장 드립니다.

결국 저희가 Serverless 라는 기술을 선택하는 이유는 계속 언급했듯이 생산성 때문입니다. 단순히 Serverless 를 쓴다고 생산성이 높이지지는 않습니다. 해당 기술을 활용하면서 생산성을 높이는 환경 구축이 같이 이루어져야 합니다. 아무리 좋은 도구도 잘못 사용하면 독이 되고, 밥 먹는데 숟가락을 써야지 포크레인을 쓸 수는 없습니다. 저희가 앞으로 개발하려는 내용이 사이클이 짧고 Feature 기반에 유지보수/관리 코스트 절감을 해야 하며 이후에 설명할 Modularize, Micro Service, Data Driven 방식에 적합한 도구 이기 때문에 해당 기술을 택하게 되었습니다.

Modularize

옛날 우리 속담에, "바쁠수록 모듈화하라" 라는 말이 있습니다.(아재 개그, 죄송합니다. ㅠㅠ)
하지만 바쁠수록 돌아가서 모듈화 하지 않으면 나중에 더 돌아가게 됩니다. 보통 개발 사이클이 짧은 팀일 수록 모듈화 보다는 빠르게 만들고 빠르게 버리고 빠르게 다시 만드는 경향이 있습니다. 하지만 빠르게 x 3 = 느리게입니다.(또, 죄송 ㅠㅠ) 모듈화를 하지 않으면 당장은 빨라 보일지 몰라도 장기적으로는 유지관리 포인트가 늘어나게 되고 일일이 각 서비스/프로젝트 별로 업데이트를 해야 합니다. 이는 장기적으로 심각한 생산성 저하를 불러오게 됩니다. 사실 머 대부분의 개발자들이 알고 있는 내용이고 보통 개발 시간이 허락되지 않는 다는 핑계 하에 모듈화가 잘 이루어 지지 않습니다. 하지만 이 또한 핑계이고 실상은 모듈화를 제대로 해 본 경험이 많지 않은 경우가 많습니다. 모듈화라는 것이 꼭 모듈화가 다 끝나고 개발이 들어가야 하는 것이 아니고 개발 중에도 모듈화를 해내 갈수 있기 때문에 완벽히 끝나서 외부에 모듈을 배포하는 공용팀을 제외하고는 프로젝트팀의 내부적인 개발 방식은 모듈화를 택하는 것이 맞습니다. 물론 모듈의 수직확장, 수평확장 및 모듈관의 관계 설정등 그냥 만드는 것보다 시간이 더 걸리기는 합니다만 하루이틀 장사하고 말 개발팀이 아니라면 모듈화는 필수라고 생각합니다. 그래서 저희는 시작시부터 모듈을 베이스로 개발 예정이고 공용 모듈 및 특정 프로젝트에서만 사용하는 모듈도 차후 재활용성을 위해 가급적 다 모듈화를 할 예정입니다.

모듈화는 기능 하나당 서버, 디비, 클라이언트, 웹까지 패키지로써 주로 npm과 Unity Package 형태가 될 예정입니다. 프로젝트는 모듈에 의존성을 가지고 프로젝트 특수화를 위해서는 모듈의 수평 확장을 사용하며, 프로젝트 전반의 확장을 위해서는 모듈의 수직 확장을 사용할 것입니다. 여기서 수평 확장은 해당 모듈에서 특정한 기능을 추가 처리하기 위해서 별도의 필드나 로직을 두는 것이고 모듈의 수직 확장은 모듈의 버전이 올라가서 새로운 기능을 전반적으로 삽입함을 말합니다. 쉽게 설명하면 SemVer 에서 수평 확장의 경우 minor 버전이 올라가고 수직 확장의 경우 major 가 올라 간다고도 볼 수 있습니다.

개발중 모듈화를 위해서 npm 로컬 개발 환경을 갖추고 현재 개발되는 프로젝트랑 연결하여 동시 개발하고, 다양하나 모듈을 한번에 관리하기 위해서 monorepo 방식을 택하고, 버전 관리 및 Change log 를 위해서 git과 lerna 를 활용 할 예정입니다. 구체적으로 어떤 부분이 모듈화가 될지에 대해서는 향후 아키텍처에서 확인할 수 있고, 회사의 허락 하에 대부분의 모듈은 오픈 소스로 공유될 예정입니다만 자사에 특화되어 있어 직접 활용 보다는 아키텍처시 참고 용도로 활용하시면 좋을 것 같습니다.

Micro Service

모듈화라는 것이 하나의 기능적인 측면에 초점이 되어 있다고 하면 Micro Service 는 작지만 하나의 완전한 서비스입니다. 큰 차이는 모듈은 보통 로직을 짜기 위한 도구로 활용되지만 서비스는 그 자체로서 서비스에 부합하는 모든 기능을 제공하게 됩니다. 모듈화로써 로직단의 재활용성 및 유지보수에 대한 생산성을 올린다고 하면 마이크로 서비스로써 서비스 단위의 생산성 올릴 수 있습니다.

Micro Service 로 제작될 수 있는 컨텐츠는 게임에서 대부분 공통적인 메타 컨텐츠입니다. 구글 플레이나 애플 게임센터에서 제공하는 리더보드 같은 것이 될 수 있고 친구 및 클랜 관리, 데일리 보상, 미션등이 될 수도 있습니다. 프로젝트와의 의존성이 없이도 리더보드를 활용하여 순위를 표기할 수 있지만 저희가 만드는 서비스는 프로젝트의 의존성을 부여하면서 확장이 가능한 형태를 고려하고 있습니다. 상당히 다양한 형태의 서비스를 제작 예정이고 향후 아키텍처에서 공개 예정입니다.

Data Driven

Serverless 와 더불어 요즘은 숨은(?) 화두는 Data Driven 개발 방식입니다.

용어정리

통계나 분석 분야에서 말하는 Data Driven 보통 빅데이터 분석과 예측을 통한 서비스를 만들어가는 방식을 말하는 것이고, 지금 여기서 말하는 Data Driven 이란 GraphQL 과 같이 기술적인 Data Driven 개발 방식을 의미합니다. (물론 자사에서 통계 및 분석을 통한 Data Driven 방식의 개발을 많이 활용하기는 합니다.)

Data Driven 개발 방식이란

기존에 클래식한 개발 방식은 기획서가 나오고 해당 내용을 서버가 구현하고 API 를 배포하고 클라이언트가 연결하고 테스트하여 마무리해가는 개발 방식입니다. 그러다가 기획에서 추가적인 정보가 필요하거나 클라이언트에서 변경 사항이 필요하면 서버에게 다시 요청하고 서버가 수정된 API 를 다시 배포하고 다시 클라이언트와 기획이 테스트해가며 일을 진행합니다. 문제는 이런 방식이 프로젝트 개발동안 수백, 수천번이 일어난다는 것입니다.(아직 이런 방식으로 밖에 개발을 안해본 분들은 이게 당연하거나 큰 문제가 되지 않는다고 생각 할 수도 있습니다.)

Data Driven 개발 방식이란 기존에 서버를 통해서만 데이터를 정의하고 받고 하던 일련의 과정을 클라이언트가 직접 할 수 있게 함으로써, 필요한 정보나 수정 사항을 클라이언트에서 즉각적으로 반영하고 수정해 나갈 수 있게 되면서 유연성과 생산성이 향상됩니다. 서버는 꼭 서버단에서 처리해야 하는 결제, 결과, 보상등의 코어 로직에만 집중합니다. 대부분의 데이터를 클라이언트 주도적으로 읽고 쓰되, 서버측에서 데이터 검증 및 클라이언트의 Cliam 에 따른 데이터 접근 제어 범위만을 지정합니다. 실상 본 단락에서 설명한 모든 내용이 GraphQL 의 핵심 중 하나입니다.

Data Driven 개발 방식의 필요 조건

GraphQL: 클라이언트 주도 API
NoSQL: 유연한 데이터 스키마
Full Stack 개발 숙련도: 실제 개발을 위한 숙련도

GraphQL 을 통해 클라이언트 주도적으로 API 를 호출하고 NoSQL 의 장점을 활용하여 원하는 데이터를 원하는 형태로 읽고 쓸 수 있습니다. 보안은 Cliam 기반의 인증을 통해 서버에서 제어하되 해당 내용은 GraphQL 의 포함 내용임으로 따로 언급하지 않겠습니다. 클래식한 방식 개발에만 익숙해져 있다면 초반에 클라이언트가 Full Stack 방식에 개발에 익숙해져야 할 필요성이 있고 이는 서버 사이드에서 도와줄 수 있는 부분입니다. 물론 조직 구조 자체가 경계가 없다면 더 유연하게 진행이 가능합니다. 제가 생각하는 최상의 조건이지 RDB를 쓰더라도 Data Driven 이 불가능한 것은 아니지만 시너지가 나지 않습니다.

서버가 코어 로직에만 집중하고 CRUD 를 클라이언트에게 넘겨주는 순간 프로젝트 생산성이 엄청나게 올라갑니다. 안 써본 사람은 있어도 한번만 써본 사람은 없다는게 GraphQL 인데, GraphQL 설명은 내용이 많아 여기 설명을 못하고 별도 연재하겠습니다. (남자한테 참 좋은데, 이거 뭐라 설명할 수도 없고... - 광고 패러디 입니다. 특정 성을 옹호나는 것이 아닙니다 ㅠㅠ) Data Driven 방식을 실제로 어떻게 구축하고 활용하는지에 대해서는 차후 기술 스택편에서 소개 하도록 하겠습니다.

협업

팀 단위의 개발에서 협업은 매우 중요한 사항입니다. Agile 등의 개발론과 원론적인 협업에 대한 내용은 차후로 미루고 실제 개발에서 생산성을 향상시키기 위한 내용만 언급하겠습니다. 아직도 많은 개발팀이 기획서 나오고 서버가 개발이 끝나고 클라이언트가 개발하고 차후 어드민툴을 붙이는 방식이나, 저희는 시작부터 어드민툴을 통한 스팩정의 및 데이터 컨트롤을 지원하여 개발 초기부터 어드민툴을 통한 개발을 Driven 하게끔 유도하고 있습니다. 또한 자동화된 문서화 시스템을 통하여 API, Change log등을 지원하여 불필요한 커뮤니케이션 시간을 줄이고 있습니다.

모든 정보가 통합 어드민툴을 통해 집약이 되고, 모든 프로젝트를 어드민툴에서 기획자가 직접 개발을 Driven 할 수 있게 지원하는 것을 목표로 하고 있으며. 빠른 웹툴 개발을 위해 Vue 기반의 Quasar Framwork를 활용하고 있습니다. 어드민툴을 통해서 어느 정도 개발을 Driven 하냐에 따라서 생산성의 차이가 클 수 있습니다.


다음 포스트는 개발팀에서 채택한 구체적인 기술과 이유들에 대한 기술 스택 설명입니다.

Last Updated: 3/20/2019, 9:12:15 AM