웹과 게임에서 다르게 사용되는 캐시

성능 향상을 위해 다양하게 이용되는 캐시

이 캐시마저, 게임과 웹에선 다르게 적용되는데, 이에 대한 질문을 꽤 여러번 받았다. 그 과정에서 설명했던 내용을 글로 정리해보고자 한다.

    • 사용자에게 보낼 HTML 캐시
    • API 파라미터에 대한 동일한 응답을 위한 캐시
    • DB 처리 전의 중간 저장소로의 활용.
    • 동일한 URL의 정적 데이터 (이미지, js, css 파일 등)에 대한 캐시
    • 메모리에 임시 데이터를 저장하는 경우가 매우 드뭄.
      • Ehcache 등을 통한 캐시가 그런 방식 아니냐라고 물어볼 수도 있지만, 게임에서의 메모리 활용과는 궤를 달리하는 측면이 큼.
    • 서버의 스케일 인/아웃의 유연함을 위해, API 호출이 특정 서버로만 전달되게 구성하는 경우가 적다.
      • 이는 메모리에 캐싱 해둔 데이터가 과거 데이터 일수 있음을 감안해야 할 수 있거나, 이를 동기화 하는 별도의 추가 작업이 필요함을 의미한다.
      • 또한 session의 경우 만료 시점에 캐싱 해둔 데이터를 DB에 반영한다거나 이에 대한 대비를 하는 작업은 웹 관점에서도 데이터 유실의 리스크가 있기때문에 쉽게 선택하기 어려운 측면이 있다.
      • Session 만료 체크를 polling 하기도 껄끄러울 뿐더러, 캐싱하던 session 데이터를 서버 종료 시점에 push 해주어야 하고, 서버 크래시라도 발생한다면 게임 쪽에서 종종 발생하는 백섭 같은 데이터 유실로 이루어 질 수 있기 때문이다.
    • 분산 캐시는 어떠한가?
      • 특정 서버에서의 변경된 내용으로 인해 캐싱 내용이 변경 될 경우, 이를 연관 서버들에게 전파해, 캐시 데이터를 다시 동기화함을 말한다.
      • 조금은 늦게 캐시가 동기화 되어도 문제 없을 법한 것들 위주로 캐싱한다.
      • 조금의 오차도 용납되지 않을 중요 데이터일 경우 어차피 웹에서도 캐시를 쓰기 어렵다.
  1. 게임
    • 웹 서버를 이용하지 않는 경우를 전제함.
    • 이미 메모리에만 들고 있는 임시 데이터가 존재하는 경우가 대 다수.
      • 주로 소켓과 물려있는 메타 정보를 저장하는 세션에 저장.
      • 세션끼리 공유하는 데이터들을 메모리에 보유.
        • 필드 (=Zone)
        • 채널
    • 동일한 요청이라고해도, 이미 바뀌었을 가능성이 매우 높기에 동일한 요청 파라미터라해도 캐싱하는 것이 무의미하다.
      • 가능한 컨텐츠는 일부 존재 할 수 있을 듯.
      • 우편함이라거나, 인벤토리 같은 진입점을 제어하고, 진입점 변경시 캐시 클리어 방식으로 웹과 비슷하게 사용 가능할 것 같다.
    • 게임은 브로드 캐스트를 자주 사용하는 편인데, 이벤트가 발생하면 새로운 요청을 클라이언트가 보내는 것이 아니라, 서버가 적합한 대상자에게 브로드 캐스트함으로써 실시간 동기화해야 하기 때문이다.
      • 특히 이동, 전투 등의 과정에서 ms 단위의 동기화가 어긋나도 버그라고 느끼는 게임에서는 캐싱할 수 있는 정보고 극도로 한정되어있다.
    • 그렇다면 과연 게임에서의 캐싱의 주 사용처는?
      • 메모리에 들고 있는 내용은 언젠가 DB에 반영되어야 할 데이터기 때문에, DB 저장 전의 중간 저장소로 사용하는 경우가 많다.
        • DB 처리 속도는 게임의 데이터 변화량보다 느릴 때도 많기 때문에, 메모리 연산을 통한 응답을 주어야만 반응성을 유지시킬 수 있기 때문이다.
      • 캐싱 용도로 저장된 데이터를 공유하는 용도로도 쓰인다.
        • DB 억세스를 직접하면, Read IO만으로도 DB에 부담을 줄 수 있다.
        • 적절한 키로 분배해놓은 캐시 서버로부터 데이터를 얻어옴으로써, DB에 부담을 줄이는 선택을 한다.
      • 심지어는 중국이나 국내 일부 업체는 DB의 트랜잭션 같은 처리를 전혀 사용하지 않고, 캐시 서버, 어플리케이션 서버 등에서 철저히 제어함으로써의 성능 극대화마저 노릴 정도니 접근 자체가 완전히 다르다고 해도 무방하겠다.

이상 웹과 게임에서의 캐시 처리에 대해 비교를 해보았다.

사실 게임에서는 캐시 서버 마저도, 범용 레디스 같은 캐시 디비를 쓰지 않고, 커스텀하게 짜는 경우가 많았다. 이는 게임 개발자들이 오픈 소스를 응용또는 학습의 부족이라고 치부 하는 사람들도 있을 수 있으나, 그렇진 않다.

응답성 극대화라거나, 국지적 쓰루풋의 극대화, 비동기 프로그래밍 도구 부족으로 인한 문제, 레디스의 메모리 기반 처리량, 제약에 대한 해결 등의 다양한 이유가 있었음을 한번쯤은 언급하고 싶었다.

개발자로서의 똑똑하다는 의미

종종 논란이 되고 토론의 주제가 되는 개발자로서 똑똑하다는 의미는 무엇일까?

대게는 논리력이 뛰어나거나, 문제 해결 능력이 좋거나, 기본기가 좋거나 같은 의미로 쓰인다. 추가적으로 남들이 못하는 일을 하는 사람, 깊이가 있는 (숙련도나, 재능이 필요한) 업무를 할 수 있는 사람, 확연이 다른 사람들보다 많이 아는 사람, 경험이 많은 사람, 학습 속도가 빠른 사람등의 의미도 있는 것 같다.

개인적으로 위 의견들에도 동의한다.

하지만, 나는 좀 더 명확한 정의가 필요하지 않나 싶은 고민이 들었다.


나는 운이 좋게도 꽤나 많은 똑똑한 프로그래머를 많이 만났다.

그런데 그 중에서 극 소수만이 내가 존경할만했고, 자극이 됐다.

왜 나머지 똑똑한 프로그래머들에게선 그런 생각이 들지 않았던 걸까?

내가 느끼는 똑똑함에는 합리적인 판단, 효율적인 판단이 포함되어 있었어야 했다.

꽤나 많은 프로그래머가 순수하고, 특정한 부분에서만 똑똑했다.

그래서, 본질적인 복잡도, 정복 가능한 복잡도를 분리하지 못하고, 또 효율적이지 못한 접근을 파고든다. 그래서 본인의 코스트를 비효율적인 작업에 낭비한다.

그래서 그 똑똑함을 제대로 발휘하지 못한채, 아쉬운 결과를 낸다.

이렇게 되는 데에 있어서는 분명히 조직 문화나 관리자의 문제가 자주 작용한다. 즉 멍청하게 일하게끔 종용하고, 이 문제를 자각할 기회 마저 잃어버리는 상황을 꽤나 자주 봤다.

그래서 자신의 재능, 자신의 똑똑함을 발휘할 생각은 전혀 하지 못한채, 그저 단순한 업무를 수행하는 직업 프로그래머가 되어버린다.

시야가 좁아지니 여지껏 해온대로, 상급자가 요구하는 방법대로 기계적인 업무를 수행하게 되는데, 여기서 나오는 비효율이 얼마나 낭비로 이어지는지 계산하지 못한채, 반복된다.

결국 이어지는 경쟁력저하는 장기적인 손해로 이어진다. 결국 기술 부채와 개인 역량 발전, 늘지 않는 인사이트로 똑똑함은 차츰 흐릿해져간다.

이게 내가 느낀 똑똑한 친구들이 총명함을 잃어가는 과정이었다.


반대로 똑똑함을 유지하는 친구들은, 어떤 상황에서도 개선에 대한 노력, 왜 인지에 대한 의문, 불편함에 대한 의구심을 끊임없이 가졌다. 또한 점령 가능한 복잡도와 그렇지 않은 것을 분별하려 노력하고, 그에 대한 끊임없는 의구심을 통해 도메인 디펜던시 안에서도 효율과 합리성에 대한 끊임없는 고민, 노력을 쉬지 않고 해왔다.

학습 방법에서도 맹목적인 신뢰가 아닌, 자신의 경험과의 비교를 통해 확고한 철하고가 접근을 해내는 친구들이 결국 성장하고, 더 훌륭한 프로그래머가 됐다.

게임계도 그랬고, 웹쪽도 그렇듯 기술적 대격변 속에서 유연하고, 효율적인 판단을 내릴 수 있는 프로그래머가 적응했으며, 살아남았다고 볼 수 있다.

물론 편협한 생각과 아쉬운 판단력임에도 불구하고, 여러가지 이유로 잘 살아남은 분들도 있으나, 이런 케이스의 대부분은 운이 좋게 위기가 안왔을 뿐이다. 또한 이런 케이스는 자신이 성장기에 익혔거나, 동료나 상사에게서 배운 방식에서 벗어나지 못한채 비효율의 굴레에 머무는 경우도 아주 많다. 점점더 자신이 없어지니 새로운 시도는 멀어지고, 차츰 더 뒤쳐진다.

그렇게 되지 않으려면, 잠깐씩이라도 시간을 내 자신이 어떻게 일하는지, 좀 더 개선할 요소는 없는지, 어떠한 준비가 필요했었는지, 어떤 물음표들을 느낌표로 바꿔야 될지를 고민하고, 판단해야 한다.

그런 반복 과정 속에서, 개선이 가장 중요한데, 자신이 느낀 물음표를 느낌표로 바꾸는 과정은 개선없인 이뤄지지 않는다. 책속에 있는 이야기들이 진리가 아니듯, 자신의 상황에서의 적절한 해결책과, 고찰, 결론을 내는 과정을 끊임없이 가다듬어야 똑똑함을 유지 할 수 있다.

앞으로 잘 성장 할 것 같은 사람에서, 항상 성장할 사람, 어떤 상황에서 자기 몫을 해낼 사람이 되기 위해선 이런 노력이 필요하다.

.NET CORE 3.0 릴리즈

Announcing .NET Core 3.0

이와 동시에 ASP NET CORE 3.0, EF CORE 3.0도 함께 릴리즈 되었다.

이미 2.X 버전 대에 와서는 쓸만한 상태가 됐었지만, 부족한 부분들을 채워주겠다는 포부를 들고 왔다.

몇가지 신규 기능 나열하자면 다음과 같다.

  1. Winform, WPF 지원.
    • 윈도우에서만 가능하다.
  2. 새 JSON API 추가
    • JSON을 다루기 좀 더 편리하고, 성능도 훌륭하다.
  3. ARM64 지원.
    • 즉 모바일 기기나, SBC 등에서 유용하다는 뜻이다.
  4. C# 8.0 지원
  5. 비동기 스트림 지원
    • C#은 이미 async/await를 아주 유연하게 지원하므로, 스트림 처리에서도 비동기 처리를 아주 손쉽게 녹여낼 수 있다.
  6. Build/Publish 옵션들의 추가
  7. LINQ 확장 추가
    • DataTable등과 같은 기본 자료형에 다양한 API 추가로 데이터를 다루는 편의성 강화.
  8. 성능 개선
    • 새 버전이 나올수록 느려지는 모 언어도 있으니…장점 맞는걸로…
  9. 가비지 컬렉터 메모리 사용량 개선
  10. Docker 지원 강화
    • 진짜 아주 편해졌다.
    • 6번 항목과 어우러져서, 어떻게든 배포 스트레스를 줄여주겠다는 의지의 표명으로 보여짐.
    • Docker-Compose도 기본 지원
    • Visual Studio 사용시 Docker Desktop과 아주 밀접하게 연동 된 것을 알 수 있는데, 이는 궁극적으로 Kubernetis와의 연동에서도 장점을 가지고 있음을 말한다.

.NET 5를 통한 .NET CORE와 .NET Framework의 대통합을 노리는 MS의 마지막 .NET Core 메이저 버전인 만큼 어떠한 형태로 통합 될 것인지를 미리 볼 수 있는 버전이었다.

Introducing .NET 5

실제로 .NET CORE 2.X 에서도 충분히 좋았지만, 3.0으로 오면서 그 만족도는 조금 지쳐 있던 개발이 즐거워질 정도였다. 리눅스 환경에서의 매끄러운 동작은 2.X에서도 충분했는데, Docker 지원의 강화는 더 말할 것 없는 편안함을 가져다 주었다.

나 처럼 1.X 버전의 .NET CORE로 고통 받았던 사람이나, 아직도 리눅스에서 C#은 Mono로 구동해야 된다고 생각하는 분들이 있다면 조금 시간을 내어 간단한 프로젝트를 구동/배포 해본다면 C#의 매력에, .NET의 매력에 빠질 수 있지 않을까 생각한다. 특히 리눅스 서버를 써야 하는 선택지만 있는 분들일 수록 더욱 추천하고 싶다.

조직 문화가 중요한 이유

  1. 실수는 필연적인 요소다.
    • 실수를 두려워하지 않되, 실수를 반복하지 않는 습관을 가지려 해야 한다.
    • 도전하지 않는다고, 변화를 기피한다고 해서 장애가 제로가 되지 않는다.
    • 개인의 실수를 질책하는 것은 의미가 없다.
      • 시스템으로 해결 할 수 있는지, 그럴 수 없다면 주변의 도움을 통해서라도 줄이는 접근을 해야 한다.
  2. 멍청하게 일하지 않으려 노력해야 한다.
    • 프로그래머가 존재하는 필연적 이유.
      • 아이디어를 실체화 할 수 있는 능력이 필요해서
      • 자동화가 필요해서
    • 멍청하게 일하는 방법
      • 동일한 일을 반복한다.
      • 사람이 개입하게 만든다.
      • 기능을 수정하기 어렵게 만든다.
      • 문제의 근본보다, 쉬운 길만 선택해서, 기술 부채를 쌓는다.
    • 논쟁의 핵심에는 해결 방법, 개선 방법이 있어야 한다.
  3. 개인에게 중요한 것은 동기부여
    • 애사심, 동료애는 강제로 가질 수 없는 것.
      • 회사에서 추구하는 방향이 개인이 추구하는 방향과 같거나
      • 성장에 대한 노력을 기울여주거나
      • 다른 조직에서 얻을 수 없는 것을 얻을 수 있을 때 애사심이 생긴다.
      • 중요한 것은 회사가 개인에게 기대하는 요소와, 배려는 엄격히 구분 지어야 한다는 점이다.
        • 모든 일에는 악용하는 사람이 존재하므로, 악용하는 사람들에게 페널티를 적용할 필요도 있더라.
    • 퀄리티냐, 워라밸이냐 마저 개인마다 다르다.
      • 회사에서 얻고 싶은 것이 나쁘지 않은 결과물과, 개인의 삶에 대한 밸런스인 것이 사회 흐름이긴하다.
      • 하지만 내가 일하는 팀이, 내가 만드는 제품이 기대이하면 고용에 위기가 올 수도 있고, 업무 스트레스로 이어지는 상황이 벌어질 수도 있다.
      • 워라밸을 추구하는 사람도 일정 수준 이상의 산출물을 내야하고, 업무 퀄리티에 치중하는 사람은 다른 사람들의 퀄리티 있는 제품 개발을 도울 수 있는 작업이나, 다른 사람들이 하기 어려운 고효율, 고퀄리티의 작업을 낼 수 있는 환경을 마련해주는 것이 필요하다.
  4. 다양성을 존중하느냐, 하나의 가치관을 강요 하느냐의 선택.
    • 다양성 존중은 참 어려운 주제다.
    • 나는 이 중요성을 여러 번 강조해왔으나, 이 다양성 존중으로 인한 폐해도 작지 않았다.
    • 다양한 방향으로 가다보니, 배가 산으로 가기 쉽상이고, 근거에 대한 기준도 판단이 명확할 수 없기에 불분명한 근거임에도 추진되기도하고, 근거가 명확함에도 추진되지 못하기도 하더라.
    • 다양한 목소리에 퀄리티를 가지기 위해선, 흔히 말하는 잡음을 만들어내는 트러블 메이커나, 근거를 미약하게 내세우는 사람, 근거의 기준이 이상한 사람, 실현력 없는 비현실적 목표를 내세우는 사람등 다양한 노이즈를 걸러내야만 한다.
      • 헌데 이 과정을 잘하기는 너무 어렵고, 기준을 모두가 납득하기 어렵기에 이는 애초에 비현실적인 목표가 아닌가 하는 의구심을 갖고 있다.
    • 그래서 지금의 결론은, 개발의 속도를 위해선 다양성보다는 하나의 가치관과 방향성을 공유하는 것이 좋을 수 있다고 본다.

조직 문화란 것은 개인이 만들기 참 어렵단 생각이 든다. 실제로 노력한다고 그렇게 흘러가지 않는 경우도 많다.

하지만 좋은 인재를 보유해야, 좋은 문화를 만들 수 있고, 좋은 문화를 유지해야 더 좋은 인재를 모을 수 있고, 더 나은 프로덕트를 만들 수 있다는 것을 한번쯤 고민해보면 좋겠다.

자신이 조직의 문화에 영향을 줄 수 있는 사람이라면 더더욱 말이다.

게임 개발로 복귀 하는 이야기

길었다면 길었고, 짧았다면 짧았던 도전을 마치고, 본업이었던 게임 개발로 복귀한다.

2년여간의 경험은 꽤나 의미가 있었다.

내가 웹&플랫폼 개발을 해보고 싶었던 계기는, 이전 글에서 언급했던 대로, 기술적으로, 문화적으로 궁금한 것이 컸다.

여기에 더해서, 게임 개발을 오래하다보니 매너리즘에 빠진 문제도 있었다.

비슷 비슷한 업무에 지치기도 했고, 중견 회사나 소규모 회사를 주로 다녔다보니 매번 출시하거나, 출시했던 게임을 서비스 하던 내가, 짧은 기간에 여러 번의 프로젝트 드랍을 경험하기도 했다.

또 당시 NHN Entertainment(현 NHN)에 입사하게 되면서 플랫폼이나 웹 개발 비중이 높은 회사로 왔다보니, 보는거 듣는게 많아지면서 궁금해지기도 했다.

게다가 개인적인 호기심으로 ruby on rails, python django 등을 사용해봤던 내가, (반강요로 인한) 자바와 스프링을 사용하게 됐다.

언어나 경험적으로 너무 큰 장벽이 있어, 쉽사리 도전하기 어려웠던 상태에서 어느정도는 도전 가능한 범주로 경험적 차이를 좁혀가다보니, 지적 호기심이 더 커졌다. 이제와서 밝히자면, 내가 과연 게임 개발이 아닌 다른 분야에서도 잘 할 수 있는지, 프로그래머로만 구성된 조직, 팀에서 내가 어떤 부분에서 장단점을 내비칠 수 있는지, 또 플랫폼 개발자나 웹 개발자들 사이에서 어떤 자극, 어떠한 인사이트, 어떠한 성장 계기를 가질 수 있는지 너무 궁금했다.

어쩌면 잠깐의 도전이, 내 인생의 많은 부분을 차지하는 일이라는 측면을 송두리째 바꿀 수 있음에도 궁금했다.

C++ 게임 개발자로 시작했고, 자연스레 만들어 쓰는 것에 익숙하던 나는, 만들어서, 써보고, 적용하고 나서야 결과를 알 수 있는 방식으로는 기술적 성장이 생각만큼 속도가 붙지 못함에 아쉬움을 느꼈다.

또한 상태 기반의 서버의 스케일아웃에 대한 경험과, 판단은 할 수 있었지만, 내가 떠올린 방식 다수가 공수가 많이 든다거나, 많은 규칙을 가지고 코딩해야 하는 강제성, 그 규칙을 유지하기 위한 높은 유지보수 비용이 필요한 방식이었다.

물론 웹/플랫폼이 다른 방식으로 스케일 아웃하고, 트래픽을 처리한다는 것은 알 수 있었으나, 분명 게임 개발에서 웹 개발의 장점을 녹일 수 있다면, 생각을 좀 더 다양한 측면에서 고려하고, 다양한 방식으로 생각 할 수 있다면 좋지 않을까 하는 기대감을 가졌다.


이렇게 도전을 나선 나에게 2년여의 경험은 큰 도움이 됐다. 그들이 왜 저렇게 생각하는지, 왜 저렇게 말하는지, 왜 저런 것들이 중요하다고 말하는지 알아들을 수 있게 됐다.

또 웹 백엔드, 프론트엔드도 개발 할 수 있을 만큼의 학습도 했고, 그들이 일하는 방식에서의 장단점도 배웠다. 플랫폼 개발자는 그래도 조금이라도 더 게임 개발자와 가까운 측면이 있었다. 모듈을 직접 구현해야 되는 경우가 많았고, 대신 오픈소스를 잘 활용하는 데에 게임 개발자들 보다 능숙했다.

실제로 웹 개발자 성향과 플랫폼 개발자들 사이에서의 차이도 꽤 컸는데, 이는 나중에 다시 얘기해보도록 하겠다.

결론적으로 게임 개발자들은 직접 만드는 데에 익숙하고, 웹이나 플랫폼 개발자들은 가져다 쓰는 데에 익숙한데, 이 과정에서 인사이트에 대한 갭도 흥미로웠다.

게임 개발자들은 직접 만들어 쓰다보니 원리에 대해 파고드는 접근을 보이는 반면, 웹이나 플랫폼 개발자들은 가져다 쓴 모듈을 검증하고, 사용하는 방식에 대해 검증하려는 접근을 보였다.

애초에 검증을 하는 방식도 테스트를 통한 검증이 많았는데, 테스트 방식으로 검증할 수 없는 부분은 결국 커버리지에 아쉬움을 보일 수 밖에 없었다.

반면 직접 만들어 쓰는 게임 개발자들은 시간이 부족하거나, 원리 이해를 잘못했을 때의 리스크를 가졌고, 테스트에 대한 리스크도 똑같이 짊어지는, 즉 고강도 노동에 시달리는 슬픈 현실을 마주하기도 했다.

그런 과정을 나도 겪었다보니, 이런 부분에 대한 해결책이 궁금해 웹/플랫폼 개발은 어떻게 하는지 알고 싶었다.


아무래도 모바일로 넘어오면서 웹 서버로 컨텐츠를 개발하기 시작한 게임은 웹 호출을 이용해서 connectionless 특성을 가져갔을 뿐, 실질적인 개발과 운용에서의 접근은 웹의 장점을 많이 못 가져왔다.

여전히 결합도를 만드는 접근, 잘 가져다 조립하지 못하는 구현, 확장성 낮은 구조는 아쉬움이 많았다.

결과 저장소와, DB 대행정도로만 구현 가능한 라이트한 게임들이라면 모를까, 조금만이라도 인터랙티브한 요소가 들어가서 소켓 프로그래밍이 필요한 경우엔 또 과거로의 회귀가 이어졌다.

상태를 들고 있는 서버는 크래시에 치명적이다. 그렇다고 서버를 잘게 쪼개 놓으면, 구현도 어렵고, 예외 처리도 어렵다.

격리할 수 있는 요소를 많이 쪼개고, MQ를 적정 지점에 배치해서 서비스 간의 통신에서 사용해, 순서와 이벤트 유실을 막는 것이 필요하다.

규칙은 최소한 프로젝트 단위에선 일관되게 만들고, 단순화 시켜서 실수를 줄이고 관리 코스트를 낮춰야 한다.

협업이 필요한 파트별로, 자신들이 만든 결과물을 자체적으로 검증하는 툴을 만들거나, 가져다 쓸 수 있어야 한다. 그래야 파트간 소통에 들어가는 코스트를 최소화 할 수 있고, 유연하게 변화를 줄 수 있으며, 조립하는 과정 즉 연동하는 과정에서의 문제를 최소화할 수 있다.

검증과 테스트 도구를 파트별로 보유 했을 때의 또다른 장점은, 새로운 시도도하기 쉽다는 거다. 아무래도 협업하는 사람이 많아질 수록, 확정적인 것 들로만 진행해야 하는데, 이는 잦은 변화로 인한 코스트 낭비를 줄이기 위해서라도 필요하다. 하지만, 파트 자체적으로 시도해볼 수 있는 환경이 갖춰진다면 다양한 시도도 할 수 있고, 완성도도 높일 수 있다.


아마도 더 오랜 기간을 웹/플랫폼 개발을 했다면 생산성 높은 환경에서 얻을 수 있는 다양한 인사이트를 얻었을 거라고 생각한다.

특히 개인적으로는 리눅스 환경이 익숙해지고, 거부감이 사라지는 데에선 플랫폼 개발 했던 기간이 큰 영향이 있었다. 또한 부서가 부서였다보니, 클라우드 환경이나 인프라에 대한 이해도도 함께 높아졌다.

그리고 오픈 소스 도구에 대한 접근, 이해도도 아주 아주 큰 도움이 됐다고 생각한다. git flow와 같은 브랜치 관리라거나, 온라인 코드리뷰 문화도 좋았다.

그럼에도 나는 한명의 게이머이고, 게임이 좋아서 게임 개발자가 됐던 내가 게임 개발을 떠나서 행복할 수 없었다는 걸 알게 됐다.

그리고 웹/플랫폼 개발에서의 경험을 게임 개발에서 녹여내고자 한다.

가장 중요한 것은 내가 언제까지 개발자를 할 수 있을지 모르지만, 내가 재밌는 일, 하고 싶은 일을 해야 겠다라는 생각이 들었다.

짧은 시간이었지만, 발을 담그게 됐던 환경에서, 나에게 자극이 되어주고, 가르침을 주시고, 배울 수 있게, 성장할 수 있게, 경험할 수 있게 해주신 분들께 감사한다.

또 다시금 게임 개발 전선에 뛰어들 수 있게 도와준 분들께도 감사한다.

내년에는, 또 후년에는 하고자 했던 것들을 이뤄내서, 나의 게임 개발 복귀가 의미 있게, 가치 있었다고 말할 수 있게 된다면 좋겠다.