[GL 2기] import 정렬 자동화부터 언리얼 이동 동기화까지 (성장일지 1회차 큐레이션) 🌱

안녕하세요! 그로스로그 입니다!😊 🌱

바로 복붙해 쓸 수 있는 팀 컨벤션 설정, 기존 앱에 Flutter를 조금씩 들이는 법, 그리고 게임 엔진 내부 파헤치기. 2기 첫 회차입니다.

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.

2기는 2024년 9월에 시작됐습니다. 1기보다 인원이 늘면서 다루는 분야도 넓어졌어요. 첫 회차부터 프론트엔드·앱·게임엔진이 한자리에 모였습니다.

 

01

📐 ESLint로 import 순서 규칙 만들기

이종경 님

이종경 님 원문에 실린 이미지

이런 내용이에요
프로젝트마다 제각각인 import 문 순서를 ESLint 규칙으로 강제하는 방법을 정리했습니다.
React를 맨 위에, 외부 라이브러리를 그다음에, 내부 모듈과 상대경로를 아래에 두는 식의 순서를 사람이 지키는 게 아니라 도구가 강제하게 만드는 설정이에요.
무엇보다 완성된 설정을 그대로 복사해 쓸 수 있게 정리해뒀습니다. 팀 컨벤션 문서에 붙여넣기만 해도 바로 적용되는 형태라, 읽고 나서 할 일이 명확한 글입니다.

기술적으로 아주 깊은 글은 아닙니다. 그런데 실무 적용도가 이번 회차에서 가장 높았어요.

import 순서는 사소해 보입니다. 그런데 팀원마다 다르면 코드 리뷰에서 계속 신경 쓰이고, 무엇보다 의미 없는 diff가 쌓입니다. 같은 파일을 두 사람이 만졌는데 import 순서만 달라져서 충돌이 나는 상황, 겪어보신 분이라면 아실 거예요.

조금 더 들어가 보면

이 글이 다루는 건 사실 "규칙을 문서가 아니라 도구에 넣는 일"입니다.

팀 컨벤션을 정하는 흔한 방식은 위키에 적어두는 겁니다. "import는 이 순서로 씁시다"라고요. 그런데 이 방식은 잘 작동하지 않습니다. 새로 온 사람은 위키를 안 읽고, 읽은 사람도 바쁘면 잊어버려요. 그러면 결국 코드 리뷰에서 "여기 import 순서가…"라는 코멘트를 사람이 달게 됩니다. 리뷰어의 시간이 기계가 할 수 있는 일에 쓰이는 거죠.

ESLint의 import/order 규칙은 이걸 자동화합니다. 그룹을 정의해두면 — 내장 모듈, 외부 패키지, 내부 별칭 경로, 부모 상대경로, 형제 상대경로 — 그 순서대로 정렬되지 않은 코드를 에러로 잡아냅니다. --fix 옵션을 붙이면 알아서 고쳐주고요.

여기서 한 단계 더 나아가면 저장할 때마다 자동 정렬되게 만들 수 있습니다. 에디터 설정에 formatOnSave를 켜두고, CI에서도 lint를 돌리면 규칙을 어긴 코드가 아예 저장소에 들어오지 못해요.

이게 왜 중요하냐면, 컨벤션의 목적이 통일 그 자체가 아니라 인지 부하를 줄이는 것이기 때문입니다. 모든 파일의 import가 같은 구조면, 파일을 열었을 때 "이 파일이 무엇에 의존하는가"를 훑는 데 걸리는 시간이 짧아집니다. 외부 라이브러리는 위쪽, 우리 코드는 아래쪽에 있다는 걸 눈이 알고 있으니까요.

작은 규칙 하나지만, 팀 전체가 매일 여는 모든 파일에 적용된다는 점에서 효과가 누적됩니다.

큐레이터 노트

바로 쓸 수 있는 형태로 정리했다는 점에서 뽑았습니다.

깊이로 따지면 이번 회차에서 가장 얕은 글일 수 있습니다. 그런데 큐레이션 기준이 깊이 하나는 아니에요. 이 글은 읽고 나서 5분 안에 적용할 수 있습니다. 완성 설정이 통째로 있으니 팀 컨벤션에 그대로 넣으면 되거든요.

기술 글에는 두 종류가 있다고 생각합니다. 이해를 넓혀주는 글과, 오늘 당장 문제를 없애주는 글이요. 둘 다 필요하고, 이 글은 후자로서 아주 잘 만들어졌습니다.

원문 읽으러 가기  ↗velog.io/@jong-kyung/ESLint%EB%A1%9C-import-%EC%88%9C%EC%8…

 

02

📱 [Flutter] Android Project에 Flutter Module 사용하기

박예승 님

이런 내용이에요
이미 운영 중인 안드로이드 앱에 Flutter를 전체 교체가 아니라 모듈 단위로 조금씩 넣는 방법을 다룹니다.
기존 앱을 통째로 다시 만들 수는 없는 현실적인 상황에서, 새 화면부터 Flutter로 만들어 붙여나가는 시나리오예요.
핵심은 FlutterEngine 캐싱입니다. 캐싱을 안 하면 Flutter 화면을 열 때마다 엔진이 새로 뜨면서 눈에 띄게 느려집니다. 글은 이 함정을 GIF로 직접 비교해서 보여줍니다. 캐싱 전후의 체감 차이가 화면으로 증명돼 있어요.

새 기술을 도입할 때 가장 현실적인 방식은 점진적 도입입니다. 기존 앱을 멈추고 처음부터 다시 만들 수 있는 팀은 거의 없으니까요.

이 글은 그 방법을 다룹니다. 안드로이드 네이티브 앱에 Flutter 모듈을 붙여서, 새로 만드는 화면부터 Flutter로 가는 구조요.

조금 더 들어가 보면

Flutter를 기존 앱에 붙일 때 가장 먼저 부딪히는 게 엔진 초기화 비용입니다.

Flutter는 자체 렌더링 엔진을 갖고 있습니다. Dart 코드를 실행할 런타임도 필요하고요. 그래서 Flutter 화면을 띄우려면 FlutterEngine이라는 걸 먼저 준비해야 하는데, 이게 공짜가 아닙니다. 엔진을 띄우고 Dart VM을 시작하고 필요한 리소스를 로드하는 데 시간이 걸려요.

순진하게 구현하면 이렇게 됩니다. 사용자가 Flutter 화면으로 진입할 때마다 엔진을 새로 만들고, 화면을 나가면 버립니다. 동작은 하죠. 그런데 화면을 열 때마다 하얀 화면이 잠깐 보이거나 눈에 띄게 버벅입니다. 네이티브 화면 사이를 오갈 때는 없던 현상이니 사용자는 "이 화면만 이상하다"고 느끼게 되고요.

엔진 캐싱이 해법입니다. 앱이 시작할 때 미리 FlutterEngine을 하나 만들어 메모리에 들고 있다가, Flutter 화면이 필요할 때 그 엔진을 재사용하는 방식이에요. 준비 비용을 앱 시작 시점으로 옮겨두는 셈입니다.

트레이드오프도 분명합니다. 엔진을 계속 들고 있으니 메모리를 상시 점유해요. Flutter 화면을 자주 쓰는 앱이라면 남는 장사지만, 어쩌다 한 번 들어가는 화면 하나 때문에 엔진을 항상 띄워두는 건 낭비일 수 있습니다. 그래서 실무에서는 엔진을 언제 만들고 언제 버릴지를 앱의 사용 패턴에 맞춰 정합니다.

이 글이 좋은 건 그 차이를 GIF로 증명했다는 점입니다. "캐싱하면 빨라집니다"라는 문장과, 캐싱 전후 화면 전환을 나란히 놓은 영상은 설득력이 다릅니다.

큐레이터 노트

시나리오가 명확하고 함정을 실제로 밟아봤다는 점에서 뽑았습니다.

하이브리드 도입은 말은 쉽지만 실제로 해보면 붙이는 지점마다 문제가 생깁니다. 이 글은 그중 가장 먼저 만나는 성능 함정을 정확히 짚었어요. 그리고 GIF로 증명한 게 결정적이었습니다. 성능 이야기는 숫자나 화면 없이 하면 주장이 되는데, 보여주면 사실이 되니까요.

참고로 이 글을 쓰신 박예승 님은 2기 1·2·3회차에 연속으로 큐레이션되셨고, 현재 그로스로그 5기에서 성장일지 큐레이션을 담당하고 계십니다. 멤버로 뽑히던 분이 이제 고르는 자리에 계신 셈이에요.

원문 읽으러 가기  ↗velog.io/@martin_0610/Android-Project에-Flutter-Module-사용하기

 

03

🎮 [언리얼] CharacterMovementComponent 파이프라인 -1-

허해수 님

허해수 님 원문에 실린 이미지

이런 내용이에요
언리얼 엔진의 CharacterMovementComponent 내부가 어떻게 동작하는지를 직접 테스트하며 파헤친 글입니다.
주제는 멀티플레이 이동 동기화예요. 여러 명이 같은 공간에서 움직일 때, 각자의 화면에서 캐릭터가 자연스럽게 보이도록 만드는 일이 생각보다 훨씬 복잡합니다.
엔진 문서를 읽는 데서 그치지 않고 실제로 값을 바꿔가며 동작을 확인한 과정이 담겨 있어, 이번 회차에서 기술 깊이가 가장 높은 글이었습니다.

게임 엔진 내부를 다룬 글이 성장일지에 올라온 건 이때가 처음이었습니다.

CharacterMovementComponent는 언리얼에서 캐릭터의 걷기·달리기·점프를 담당하는 핵심 컴포넌트인데, 특히 네트워크 환경에서의 동작이 까다롭기로 유명합니다.

조금 더 들어가 보면

멀티플레이 게임에서 캐릭터 이동이 어려운 이유는 빛의 속도 때문입니다. 조금 과장 같지만 진짜예요.

서울에 있는 플레이어가 앞으로 걷는 입력을 넣으면, 그 정보가 서버까지 가는 데 시간이 걸립니다. 서버가 처리해서 다른 플레이어에게 전달하는 데도 또 걸리고요. 왕복 100ms라고 하면, 내가 본 화면과 상대가 본 화면 사이에는 항상 시차가 있습니다.

여기서 선택지가 갈립니다.

서버가 모든 걸 결정하게 하면 정확하지만 답답합니다. 키를 눌러도 내 캐릭터가 100ms 뒤에 움직이거든요. 게임이 즉시 반응하지 않으면 사람은 금방 이상함을 느낍니다.

그래서 대부분의 게임은 클라이언트 예측(Client-side Prediction)을 씁니다. 내 입력은 일단 내 화면에서 즉시 반영해버려요. 동시에 서버에도 보내고요. 그러면 조작감은 살아납니다.

문제는 서버 판정이 내 예측과 다를 때입니다. 나는 벽을 통과했다고 생각했는데 서버는 막혔다고 판단했다면요? 이때 캐릭터를 서버가 말하는 위치로 되돌려야 하는데, 그냥 순간이동시키면 화면이 튑니다. 이걸 부드럽게 처리하는 게 서버 보정(Server Reconciliation)이에요.

여기에 다른 플레이어의 캐릭터를 어떻게 보여줄지도 문제입니다. 내가 받는 상대의 위치 정보는 이미 과거의 것이거든요. 그래서 마지막 두 위치를 이어 그리거나(보간), 속도를 보고 다음 위치를 추측해서(외삽) 그립니다.

언리얼의 CharacterMovementComponent는 이 전부를 내장하고 있습니다. 편리하지만, 동작 방식을 모르면 문제가 생겼을 때 손을 못 댑니다. 캐릭터가 미끄러지거나 순간이동하는 현상을 만나도 어디서부터 봐야 할지 모르게 되죠.

이 글이 엔진 내부를 직접 테스트한 게 그래서 의미가 있습니다. 블랙박스를 열어본 기록이니까요.

큐레이터 노트

이번 회차에서 기술 깊이가 가장 높은 글이었습니다.

엔진이 제공하는 컴포넌트를 가져다 쓰는 것과, 그 안에서 무슨 일이 일어나는지 확인해보는 건 다른 일입니다. 후자는 시간이 훨씬 많이 들고 당장 눈에 보이는 성과도 없어요. 그런데 그 시간이 나중에 아무도 못 고치는 버그를 고치는 사람을 만듭니다.

멀티플레이 이동 동기화라는 주제 자체도 흥미로웠습니다. 웹이나 앱을 하는 멤버들에게는 낯선 영역인데, 읽어보면 "실시간으로 여러 클라이언트의 상태를 맞춘다"는 문제는 협업 도구나 채팅에서도 똑같이 나옵니다. 분야가 달라도 배울 게 있는 글이었어요.

원문 읽으러 가기  ↗imresearcher.tistory.com/m/40

💡 세 편을 겹쳐 읽으며

프론트엔드 설정, 앱 아키텍처, 게임 엔진 내부. 2기 첫 회차부터 분야가 이렇게 벌어졌습니다.

그런데 세 글을 나란히 놓으면 깊이의 스펙트럼이 보입니다.

이종경 님의 글은 오늘 당장 적용 가능한 층위에 있습니다. 복사해서 붙이면 끝이에요. 박예승 님의 글은 선택의 트레이드오프를 다룹니다. 캐싱을 할지 말지, 메모리를 쓸지 속도를 얻을지 판단해야 하죠. 허해수 님의 글은 도구 안쪽으로 들어갑니다. 당장 쓸 일은 없어도, 문제가 생겼을 때 손댈 수 있게 해주는 지식이고요.

셋 다 필요합니다. 그리고 한 커뮤니티 안에 이 세 층위가 동시에 존재한다는 게, 서로에게 배울 게 있다는 뜻이기도 해요.

이번 회차에서 가져갈 것

1. 규칙은 문서가 아니라 도구에 넣기. 위키에 적은 컨벤션은 지켜지지 않습니다. lint 규칙으로 만들면 지켜져요. 사람이 기억해야 하는 규칙이 있다면, 그중 자동화할 수 있는 건 없는지 한 번 살펴볼 만합니다.

2. 새 기술은 통째로 말고 조각으로. 기존 시스템을 멈추고 갈아엎을 수 있는 팀은 드뭅니다. 어디부터 붙일 수 있는지를 찾는 게 실제 도입의 시작이고, 그때 만나는 성능 함정을 미리 아는 게 절반입니다.

3. 편리한 추상화일수록 한 번은 열어보기. 프레임워크가 알아서 해주는 부분은 평소엔 축복이지만, 문제가 생기면 벽이 됩니다. 자주 쓰는 것 중 하나는 내부를 들여다본 경험을 만들어두면 언젠가 반드시 쓰입니다.

---

2기가 시작됐습니다. 1기가 7회차로 짧게 마무리됐다면, 2기는 12회차 전체를 완주한 첫 기수예요. 인원도 늘고 분야도 넓어지면서, 성장일지에 올라오는 글의 스펙트럼이 눈에 띄게 벌어진 시기이기도 합니다.

좋은 글 남겨주신 이종경 님, 박예승 님, 허해수 님께 감사드립니다! 😊

다음 큐레이션으로 다시 찾아오겠습니다! 🌱

- 에디터 · 성장일지 큐레이터 -

---

※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.