잡담

2024년 한 해를 되돌아보며

메피카타츠 2025. 1. 1. 19:45

어느덧 2024년도 다 지나가고 2025년이 되었다. 오늘도 1년 전처럼 한 해를 되돌아보는 시간을 가져볼까 한다.

 

개발

1. 스피드핵 안티 치트 개발

 

스피드핵 안티 치트는 2023년에도 개발을 했었는데, 2023년 한 해를 되돌아보며에서 누락되었다.

 

근데 2023년에 만든 안티 치트에는 미흡한 부분이 다소 있었고, 작업 이후 기록된 실제 게임 데이터들을 바탕으로 2024년에 2~3차례 개선해서 상당히 괜찮아졌다. 지금도 1~2차례 더 개선할 계획이 있다. 만들면서 제일 골치아픈 점은 네트워크가 불안정해지는 경우에 대한 고려인데... 처음엔 불안정할 때 어떻게 되는지 전혀 몰라서 어려웠는데, 지금은 대강 어떻게 되는지 알아서 이전보단 많이 나아진 것 같다. 일반 유저들에게 불편을 주지 않으면서 비정상적인 플레이를 하는 유저를 잡아내는 게 참으로 어려웠던 것 같다.

 

작업한 내용을 간략히 요약해보자면...

 

1차적으로는 서버에서 클라이언트 요청에 대한 검증을 추가해서 정상적인지 비정상적인지를 감지해 비정상인 경우 로그를 남겼었다. (패킷의 지연 시간까지는 고려되었으나 네트워크 불안정한 경우 패킷이 몰려오는 상황에 대해서는 당시 인지를 못했기에 추후에 개선하였음)

 

2차적으로는 뚫릴 수는 있지만 걸리면 무조건 핵 사용이라고 단정지을 수 있는 검사를 추가했었다.

 

3차적으로는 누적을 활용한 아이디어를 통해 처리 상한선을 추가했다. (이건 2025년 1월 중에 작업했다.)

 

2. 성능 최적화

2-1. 테이블 로딩 속도 개선: 멀티스레드로 테이블 로딩 속도를 개선했는데, 대략 70%정도 줄어들었다. 원래 동료가 해놨다가 문제가 있어서 빼놨는데, 살펴보면서 문제 있어보이는 부분을 개선해서 다시 넣어놨다. 이후에 에디터쪽에도 적용해서 빨라지게 하는 등의 작업도 했었다.

 

2-2. 코드 최적화: Update에서 성능을 많이 먹고 있는 코드들을 최적화해 전체의 10% 가량 (0.1ms 정도?) 성능 향상을 했고, 매 프레임 발생하던 가비지 대부분을 줄이는 등 작업을 했다.

 

2-3. 에디터 로딩 속도 개선: 패키지 등으로 받은 코드들의 InitializeOnLoad 라든가 등등 필요없는 코드들이 컴파일 때마다 돌아가서 컴파일 시간이 총 30초 정도 걸렸는데, 이것저것 정리해서 18초로 40% 정도 줄였다. 더 줄일 수는 있었는데 시간 너무 쓰긴 좀 그래서 적당히 줄였다.

 

2-4. 그래픽 관련 최적화: 그래픽 관련해서 성능 많이 먹는 부분들을 최적화했는데, 일단 가장 영향이 컸던 부분은 그림자였던 것 같다. 그림자 Cascade Count를 줄이고 Resolution을 높게, 그리고 카메라 각도/거리에 따라 그림자 거리를 조절해주는 등 처리로 미관은 더 좋게하면서 성능은 개선했다. 이외에 Font Atlas, Reflection Probe 등에서 배치 깨진 것들 줄여서 Setpass call을 줄이거나 이펙트 LOD를 약간 작업하여 전체 batch를 줄이기도 했다.

 

2-5. 서버 관련 최적화: CS 처리를 위해 게임 플레이 중에 로그를 찍는데, 중요도가 낮은 로그를 너무 많이 찍고 있어서 묶어서 처리해주도록 작업하여 42% 정도 줄어들 것으로 예상하고 있다. ( * 이후 적용 전, 후 비교한 바로는 주말 이틀 총 48시간동안 로그인 로그는 2.03% 증가한 동안 총 로그 수는 42.11% 감소했다.)

 

3. 용량 최적화

1. 폰트 용량 최적화

 

메모리 관리에 대한 탐구 (10) - Unity에서 Font 관련 용량 줄이기 :: 메피카타츠의 블로그

 

메모리 관리에 대한 탐구 (10) - Unity에서 Font 관련 용량 줄이기

Unity로 모바일 게임을 개발하다보면 메모리가 부족해지는 경우가 생긴다. 메모리 관리에 대한 탐구 (5) - 메모리 프로파일러를 통한 메모리 사용량 분석 :: 메피카타츠의 블로그 (tistory.com) 메모

mepkatatsu.tistory.com

 

참여 중인 라이브 프로젝트에서 폰트 용량 절감으로 얻은 효과

 

apk 용량: Mono 빌드 기준 120.5MB -> 84.5MB 로 30% 감소

메모리 내 폰트 용량: 피크 기준 714MB -> 53.2MB로 92.5% 감소 (Objects And Allocations 기준)

전체 메모리 사용량: 피크 기준 1.06GB -> 0.62GB 로 41.5% 감소 (프로파일러 좌측에 나타나는 기기 전체 사용량 기준)

 

메모리 내 폰트 용량 감소와 전체 메모리 사용량 감소에 다소의 차이가 있는데 아마 줄어든 만큼 완전히 줄어드는 게 아니라 어느정도 메모리를 확보해놓는 것 때문에 그런 것 같기도 하다. (전체 메모리 사용량이 0.62GB인데 이중 200MB는 여유 공간이라든가 등)

 

2. 각종 리소스 최적화

 

메모리 관리에 대한 탐구 (11) - Unity의 Asset 압축/최적화로 메모리/디스크/다운로드 용량 줄이기 :: 메피카타츠의 블로그

 

메모리 관리에 대한 탐구 (11) - Unity의 Asset 압축/최적화로 메모리/디스크/다운로드 용량 줄이기

유니티로 모바일 게임을 개발하다보면 메모리 용량을 확보해야 하는 상황이 온다. (여기서 말하는 메모리는 RAM이다) 이뿐만 아니라, 디스크 용량 확보도 중요한 요소이다. 게임의 용량이 작은

mepkatatsu.tistory.com

 

참여 중인 신규 프로젝트에서 에셋 최적화/압축을 통해 아래와 같은 효과를 볼 수 있었다.

 

초기 다운로드 용량: 2.0GB -> 750MB (63.4% 감소)

전체 번들 용량: 2.54GB -> 1.50GB (41% 감소)

 

 

4. 빌드 관련

빌드할 때 젠킨스를 활용하는데, 이것저것 문제가 있거나 추가가 필요하다든가 해서 빌드 파이프라인을 수정하면서 Groovy도 조금 써볼 수 있었고, iOS쪽 빌드에 문제가 있어서 맥에서 XCode로 디버깅도 해보고, CocoaPods 관련해서도 수정을 조금 해봤다. 다 갖춰져있는 상태에서 약간씩 수정만 해본 거지만 좋은 경험이었던 것 같다.

 

5. 워크플로우 관련

5-1. 프로젝트 분리: 라이브 프로젝트와 신규 프로젝트를 같이 진행하면서 라이브 프로젝트에서 한 작업을 신규 프로젝트에도 적용하고 싶은 경우가 있었다. 신규 프로젝트가 라이브 프로젝트에서 포크해온 후 작업이 된 거라 어느정도는 포크로 이게 처리가 되었는데... 문제는 시간이 지날수록 서로 다른 부분도 엄청나게 많고, 작업한 내용이 많을수록 Conflict도 많이 발생하여 포크에 시간이 엄청 걸리고... 앞으로 만약 프로젝트가 늘어난다면 감당 못 하겠다 싶어서 공통으로 사용할 코어 부분을 따로 프로젝트로 분리하였다. 처음엔 패키지로 사용했는데, 여러모로 불편한 점들이 많아서 SubModule로 분리하였다.

 

어느정도는 미리 분리되어 작업이 있었지만, 꽤나 중요한 것들이 분리가 안 되어 있는 경우가 많아서 의존성을 떼어놓는 작업을 하느라고 애를 많이 먹었다. 그래도 이 작업을 하면서 의존성을 분리하는 방법을 이것저것 많이 적용해볼 수 있었던 것 같고, 인터페이스 사용에도 좀 익숙해진 것 같다. 작업하면서 클린 아키텍처 책을 읽기도 하였는데, 객체 지향에 대해서 조금 더 깊게 생각해볼 수 있었던 계기가 된 것 같다.

 

5-2. 신입 서포트: 올해 6월, 그러니까 입사한 지 1년 정도 지났을 때 신입 프로그래머가 2명 들어왔다. 그 중 1명의 사수 역할을 맡았다. 처음에는 과제를 피드백하며 검사했었고, 이후에는 적당한 업무를 배정해주고 작업한 내용을 확인하여 수정이 필요한 내용은 피드백을 주며 검사하여 메인 브랜치로 머지하는 작업을 했다.

 

5-3. 풀 리퀘스트 활용: 신입 프로그래머가 작업한 내용을 머지하면서 든 생각이 있었다. 원래 업무 방식이 메인 브랜치에 아무나 직접 올릴 수 있었기 때문에 이런저런 문제들이 발생하곤 했다. 자잘하게는 컴파일 에러가 발생한다든가, 크게는 잠재적인 버그가 발생할 수 있는데 그걸 간과하고 작업한다든가하여 나중에 다시 작업을 해야 한다든가 등... 이런 일들이 주기적으로 발생해서 풀 리퀘스트를 해보면 어떻겠냐는 제안을 했다. 안 그래도 염두에 두셨는지 이야기가 착착 진행되어 금새 풀 리퀘스트를 적용하게 되었다. 이제 적용한지 1달정도 된 것 같은데, 아직까진 자잘한 문제들이 계속 튀어나와서 조금씩 적응해가는 중이다. 특히 SubModule과 같이 사용하면서 여러모로 불편한 점이 많은 것 같다. -0-. 업무 속도도 꽤 더뎌진 것 같은 등 단점들도 있지만 확실한 장점으로는 전체적으로 코드의 퀄리티가 올라가지 않았나 싶다. 풀 리퀘스트를 안 했으면 이 코드가 그대로 올라갈 뻔 했군... 같은? 생각이 들기도 하고 말이다. 아무튼 이것도 좋은 경험인 것 같다.

 

작곡

회사에서 사운드 담당하시는 분의 도움을 받아서 피드백도 약간 받기도 하고, Splice 및 Serum도 사용해보고, Kontakt도 월정액 버전으로 사용해보기도 했다. 확실히 이전에 비해서는 많이 발전한 것 같은데, 여전히 만족스럽지는 못한 것 같다. 특히나 만들면서 계속 정체가 발생하는데 뚫고 나가기가 힘들어 정체되고, 힘들어서 게임 등 다른 걸 하다보면 "아 그래도 계속 만들어야 하는데..." 와 같은 생각이 들고, 그렇다고 계속 해봤자 뾰족한 방법은 없고... 그래서 "해야 하는데"와 "해봤자 안 되는데" 2개로 인해 계속 스트레스를 받은 것 같다. -0-... 아무래도 기초적인 부분이 아직도 많이 모자라지 않나 싶다. 악기 다루는 법 등에 대해서 배우면 도움이 많이 될 것 같은데 그러자니 비용/시간 등이 또 문제이기도 하고 말이다. 아무튼 그래서 시간이 생각보다 많이 필요하겠구나 라는 생각이 들었고, 그만한 시간과 비용을 투자해도 좋겠다는 생각까지는 들지 않았다. 그래서 지금은, 나는 내가 잘하는 프로그래밍이나 하고... 노래를 노래 잘 하시는 분들에게 맡기자는 생각이다. 근데 또 미련이 남아서인지 자꾸자꾸 생각나긴 한다. ㅡ.,ㅡ;;

기타

 

1. 서브컬쳐 행사 방문

 

2024. 05. 19. 블루 아카이브 2.5주년 페스티벌 행사 방문

2024. 08. 04. 승리의 니케 여름 팝업 스토어 방문

2024. 08. 11. 하츠네 미쿠 팝업 스토어 방문

2024. 08. 30. 시구레 우이 개인전 방문

2024. 08. 31. 메가 니케 스토어(아키하바라) 방문

2024. 08. 31. 2024 매지컬 미라이 방문 (2024 매지컬 미라이(Magical Mirai) 후기 :: 메피카타츠의 블로그)

2024. 12. 07. AGF 2024 방문

 

이게 전부인지는 모르겠지만 휴대폰 갤러리 토대로 작성해봤다. 사운드 아카이브도 가고 싶었는데 폰으로 예매한다고 놓쳐버렸다. ㅡㅡ. 담부턴 무조건 컴퓨터로 해야지.

 

2. 리니지

 

리니지에 대한 악명이 하도 자자해서 딱히 해보려는 생각은 없었는데 김실장이라는 유튜버 영상을 보다보니 뭔가 궁금해져서 시작해봤다. 돈은 거의 안 썼는데 (거래소에 누가 잘못 올린 게 있어서 3,300원 짜리 하나 사서 낼름했다) 성장하는 재미나 템먹는 재미가 있어서 최근에 꽤 재밌게 플레이하고 있다. 그렇게 욕먹는데도 많이들 하는 이유가 있는 것 같다. ㅋㅋ

 

 

올해는 글쎄, 일단 산업기능요원을 무탈하게 마무리 하는 것이 먼저일 것 같다. 그 외에는... 지금 맡고 있는 프로젝트가 잘 되면 좋을 것 같다. ㅎㅎ.