안녕하세요! 그로스로그 입니다!😊 🌱
기본 개념부터 다시 정리한 사람, Redux 때문에 밤을 샌 사람, 설치 화면을 하나하나 남긴 사람. 1기 3회차 세 편입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 이번 글은 1기를 다시 읽는 세 번째 큐레이션입니다.
3회차는 2024년 6월 29일이었습니다. 방학이 시작되고 각자 프로젝트가 굴러가기 시작한 시점이에요. 그래서인지 이 회차에는 "만드는 중"인 글이 모였습니다.
01
🎮 인디게임 제작기 2 : 캐릭터, 폰, 충돌, 피직스
허해수 님
언리얼 엔진 5.4.2로 5명이 3개월간 인디게임을 만드는 팀 프로젝트의 3주차 기록입니다. 기획자·캐릭터 모델러·배경 모델러가 각자 작업을 시작했고, 글쓴이는 프로그래머를 맡았어요.
그런데 진행상황을 적다 말고 방향을 틉니다. "제로베이스부터 만들려 하니 기본 개념이 헷갈리는 게 많아서 다시 정리해보았다"고요.
그래서 이 글의 대부분은 Pawn과 Character의 차이, Mesh·Collision·Physics Simulation이 각각 무엇을 책임지는지, 그리고 Set Location과 Move Forward를 언제 쓰는지에 대한 정리입니다.
3주차에 진행상황이 네 줄로 정리돼 있습니다.
2. 캐릭터 모델러가 플레이어 캐릭터를 제작하였다.
3. 배경 모델러가 프랍들을 제작하였다.
4. 프로그래머가 시스템 요소를 구현하였다. <-ME
역할이 이미 나뉘어 있습니다. 그리고 자기 몫에 들어가면서, 먼저 개념부터 정리하고 시작해요.
조금 더 들어가 보면
🧍 Pawn과 Character는 왜 나뉘어 있나
글이 가장 먼저 정리한 것이 이 둘의 차이입니다.
반면에 Character는 Pawn을 상속받은 사람형태의 클래스 액터로 (…) 기본적으로 CapsuleComponent 충돌 콜리전을 갖고 있으며, 기본적인 걷기, 뛰기, 점프를 할 수 있는 CharacterMovementComponent를 가지고 있으며, Mesh는 스켈레탈 메시이고 AnimInstance를 가지고 있다.
Character는 Pawn에 네 가지를 미리 붙여둔 것입니다. 캡슐 모양 충돌체, 이동 처리 장치, 뼈대가 있는 3D 모델, 그리고 애니메이션 관리자요.
왜 이렇게 나눴을까요. 게임에 등장하는 조작 가능한 물체가 전부 사람 모양은 아니기 때문입니다. 탱크도 있고, 우주선도 있고, 카메라만 떠다니는 관전 모드도 있어요. 이런 것들에 걷기·점프 기능이나 사람 뼈대를 붙여두면 쓰지도 않을 무게만 늘어납니다.
반대로 사람형 캐릭터를 만들 때마다 캡슐 충돌체를 붙이고 이동 로직을 짜고 애니메이션을 연결하는 것도 낭비고요.
그래서 일반적인 것은 Pawn에 두고, 사람형에 필요한 묶음은 Character로 따로 뺐습니다. 만들려는 게 사람 모양이면 Character를 상속받아 바로 시작하고, 아니면 Pawn에서 필요한 것만 붙이는 겁니다.
글의 요약이 이 판단을 정확히 담고 있습니다.
Pawn : 더 일반적인 액터로, 기본적인 이동 로직을 직접 구현해야 하며, 다양한 형태로 커스터마이즈 가능.
"직접 구현해야 하며"와 "용이"가 대비를 이룹니다. 자유로운 대신 손이 많이 가고, 편한 대신 정해진 틀 안에 있다는 것. 프레임워크를 고를 때 늘 하는 그 판단과 같습니다.
🧱 누가 무엇을 책임지는가
게임 엔진을 처음 다루면 가장 헷갈리는 게 "이건 누가 하는 일인가"입니다. 화면에 캐릭터가 보이고 벽에 부딪히고 중력을 받아 떨어지는 게, 겉보기엔 하나의 일처럼 보이거든요.
이 글은 그걸 셋으로 나눕니다.
· Mesh(메시) — 3D 모델입니다. 보이는 것만 담당해요.
· Collision(콜리전) — 물체끼리 어떻게 상호작용할지 정합니다. 부딪히는 것을 담당합니다.
· Physics Simulation — 중력과 힘을 받아 실제로 어떻게 움직일지 계산합니다. 움직이는 것을 담당해요.
셋이 왜 분리돼 있는지에 대한 설명이 특히 좋습니다. 충돌은 메시와 별도로 설정하는데, 그 이유가 최적화라는 거예요.
캐릭터의 실제 3D 모양은 삼각형 수만 개로 이루어져 있습니다. 그 모양 그대로 충돌을 계산하면 프레임마다 어마어마한 연산이 필요해요. 그래서 실제로는 캡슐 하나로 대신합니다. 눈에 보이는 것과 물리적으로 부딪히는 것을 일부러 다르게 두는 겁니다.
이 구분이 실제로 어떻게 쓰이는지도 예시로 정리해뒀습니다. 콜리전은 있는데 물리 시뮬레이션은 꺼둔 경우가 두 가지예요.
2: 트리거 영역 — 물리적 상호작용 없이 단순히 영역 내에 들어오는 물체를 감지
게임에서 특정 지점을 밟으면 이벤트가 발생하는 것, 그게 두 번째입니다. 부딪히긴 하는데 밀리진 않는 거죠. 세 시스템을 나눠뒀기 때문에 이런 조합이 가능합니다.
📝 원문에서는 이렇게 짚습니다
마지막 항목이 실전에서 자주 걸리는 함정입니다. 물체를 움직이는 두 가지 방법의 차이예요.
그리고 여기서 한 층 더 내려갑니다.
델타 타임 보정은 게임 개발을 처음 하면 반드시 한 번 데는 지점입니다. 매 프레임마다 캐릭터를 5씩 움직이게 짜면, 60프레임 컴퓨터에서는 초당 300만큼 가고 144프레임 컴퓨터에서는 초당 720만큼 갑니다. 같은 코드인데 컴퓨터 성능에 따라 게임 속도가 달라져요. 그래서 "프레임당 5"가 아니라 "초당 300"으로 계산하도록, 이전 프레임과의 시간 간격(델타 타임)을 곱해줍니다.
Move Forward 같은 엔진 제공 함수는 이걸 알아서 해주지만, Set Location으로 직접 짜면 본인이 해야 합니다. 그 사실을 3주차에 정리해둔 거예요.
👥 다섯 명이 나눠 가진 것
글 앞머리의 진행상황 네 줄을 다시 보면, 이 프로젝트가 어떻게 굴러가는지가 보입니다.
2. 캐릭터 모델러가 플레이어 캐릭터를 제작하였다.
3. 배경 모델러가 프랍들을 제작하였다.
4. 프로그래머가 시스템 요소를 구현하였다. <-ME
게임 개발이 웹 개발과 크게 다른 지점이 여기 있습니다. 웹 프로젝트는 대개 개발자들끼리 앞뒤를 나눠 맡습니다. 그런데 게임은 만드는 사람의 직군 자체가 다릅니다. 기획자는 문서를 쓰고, 모델러는 3D 툴로 형태를 만들고, 프로그래머는 코드를 씁니다. 쓰는 프로그램도, 결과물의 형식도 다릅니다.
그래서 합치는 지점이 곧 위험한 지점이 됩니다. 모델러가 만든 캐릭터에 프로그래머가 이동 로직을 붙이려면, 그 모델에 뼈대가 제대로 들어 있어야 하고 크기와 방향이 약속대로여야 해요. 하나라도 어긋나면 캐릭터가 땅에 파묻히거나 옆으로 누워서 걷습니다.
3주차에 개념부터 정리한 게 그래서 타당합니다. "메시는 모델러의 결과물, 콜리전은 내가 붙이는 것, 피직스는 엔진이 계산하는 것"을 구분해두지 않으면, 문제가 생겼을 때 누구에게 물어봐야 하는지도 모르게 되거든요.
"제로베이스부터 만들려 하니 기본 개념이 헷갈리는 게 많아서"라는 이유가, 혼자 하는 프로젝트였다면 나오지 않았을 문장인 이유입니다.
큐레이터 노트
이 글을 고른 이유는 정리하는 순서 때문입니다.
5명이 3개월짜리 프로젝트를 시작했고, 3주차면 한창 뭐라도 만들어야 할 때입니다. 그런데 이분은 진행상황 네 줄을 적고 나서 개념 정리로 들어갑니다. "제로베이스부터 만들려 하니 기본 개념이 헷갈리는 게 많아서"라는 이유를 달고요.
헷갈린 채로 계속 만들 수도 있었습니다. 대부분 그렇게 합니다. 일단 돌아가게 만들고, 안 되면 검색하고, 또 안 되면 다른 방법을 시도하죠. 그러다 보면 왜 되는지 모르는 코드가 쌓입니다.
그리고 언리얼 엔진은 한국어 자료가 드문 영역입니다. 공식 문서에 번역은 있지만, 개념들이 서로 어떤 관계인지를 이렇게 묶어서 정리해준 글은 찾기 어려워요. 대개 "이렇게 하면 됩니다"까지만 있고 "왜 셋이 나뉘어 있는가"는 없습니다.
5회차와 7회차 큐레이션에서 다시 만나실 겁니다. 이 연작은 7편까지 이어집니다.
02
🔄 Redux (1)
이지은 님
부트캠프 마지막 프로젝트로 "과외 찾기 플랫폼"을 React로 만들다가 겪은 일을 정리한 글입니다. 발표를 앞두고 웹 화면에 로그인한 사용자와 다른 사람의 정보가 간헐적으로 나타나는 문제가 터졌어요.
"오류도 맥락이 있어야 원인을 파악할 수 있는데" 일관성 없이 발생해서 원인을 찾을 수 없었고, 왕초보 셋이 콘솔에 값을 찍어가며 밤을 샜습니다.
그런데 결론이 예상 밖입니다. 문제는 Redux를 잘못 써서가 아니라, 무엇을 전역으로 공유할지 팀이 합의하지 않고 시작했기 때문이었어요.
글의 첫 문장이 이렇습니다.
"바로 그 라이브러리"라는 표현에 감정이 남아 있습니다.
조금 더 들어가 보면
React로 화면을 만들면 페이지 하나가 여러 조각(컴포넌트)의 조합이 됩니다. 헤더에 로그인한 사람 이름이 뜨고, 본문에 그 사람이 신청한 강의가 뜨고, 사이드바에 설정이 뜨는 식이죠.
문제는 이 조각들이 각자 따로 존재한다는 겁니다. 헤더와 본문은 서로를 모릅니다. 그래서 "지금 로그인한 사람이 누구인가" 같은 정보를 조각들이 함께 알고 있어야 하는데, 이걸 어떻게 나눠 가질지가 상태 관리의 문제예요.
Redux는 그 답 중 하나입니다. 정보를 조각마다 두지 말고 한곳에 모아두고 다 같이 그걸 본다는 방식이에요. 그러면 헤더와 본문이 서로 몰라도 같은 값을 보게 됩니다.
그런데 이 팀에서는 그렇게 되지 않았습니다.
Redux를 썼는데 전역 관리는 안 한 상태입니다. 도구는 도입했지만 각자 자기 칸에 자기 값을 채우고 있었어요. 이러면 조각 하나하나는 멀쩡하게 동작합니다. 자기 안에서는 값이 일관되니까요.
어긋나는 건 조각과 조각이 만나는 자리입니다. 헤더는 A라는 토큰으로 받아온 정보를, 본문은 B라는 토큰으로 받아온 정보를 보여주면, 화면 하나에 두 사람이 섞여 나옵니다.
🗝️ 토큰이 여러 개 있었다는 것
원인 중 하나로 글이 짚은 대목이 결정적입니다.
로그인 토큰이 브라우저에 여러 개 남아 있었다는 뜻입니다.
토큰은 "이 사람이 로그인했다"를 증명하는 표예요. 정상이라면 로그인할 때 하나 발급받아 저장하고, 로그아웃할 때 지웁니다. 하나만 있어야 합니다.
그런데 조각마다 각자 서버와 통신하면서 각자 저장하면, 저장하는 이름(키)이 조금씩 달라집니다. 누구는 token, 누구는 accessToken, 누구는 user_token으로요. 그러면 로그아웃 코드가 자기가 아는 이름 하나만 지우고 나머지는 남깁니다.
결과가 고약합니다. 로그아웃했는데 어떤 화면은 여전히 로그인 상태로 보이고, 다른 계정으로 로그인하면 옛 토큰과 새 토큰이 섞입니다. 화면 하나에 두 사람의 정보가 나오는 게 정확히 이 상황이에요.
이건 Redux를 잘못 써서 생긴 문제가 아닙니다. "토큰은 어디에 어떤 이름으로 하나만 둔다"를 팀이 정하지 않아서 생긴 문제죠.
🕵️ 간헐적 버그가 어려운 이유
그리고 이 문제가 일관되게 나타나지 않았다는 게 상황을 더 어렵게 만들었습니다.
괄호 안의 말이 정확합니다. 오류도 맥락이 있어야 원인을 파악할 수 있습니다.
버그를 잡는 첫 단계는 재현입니다. "이렇게 하면 반드시 이렇게 된다"를 찾아야 원인을 좁힐 수 있어요. 그런데 열 번 중 세 번만 나면 그 단계에서 막힙니다. 고쳤는지 아닌지도 확인이 안 돼요. 세 번 눌러서 안 났다고 고쳐진 게 아니니까요.
왜 간헐적이었을까요. 어느 조각이 먼저 서버 응답을 받느냐가 매번 다르기 때문입니다. 조각마다 따로 요청을 보내니 돌아오는 순서가 네트워크 상태에 따라 바뀝니다. 늦게 온 응답이 먼저 온 값을 덮어쓰면 어긋나고, 순서가 맞으면 멀쩡해요.
타이밍에 좌우되는 문제는 개발자 컴퓨터에서 잘 안 납니다. 로컬 서버는 응답이 빨라서 순서가 거의 안 뒤집히거든요. 그래서 발표를 앞둔 환경 같은 데서 갑자기 터집니다.
왕초보 셋이 콘솔에 값을 찍어가며 밤을 새운 게 그래서였습니다. 로그를 찍어야 순서가 보이니까요. 그리고 실제로 그렇게 해서 "컴포넌트에 연결된 사용자 id가 로그인된 사용자 id와 다르다"는 걸 발견했습니다. 값을 하나씩 찍어보는 원시적인 방법이었지만, 간헐적 버그에는 그게 정답일 때가 많습니다.
📝 원문에서는 이렇게 결론냅니다
원인 분석이 기술이 아니라 절차로 향합니다.
그리고 Redux를 고른 과정도 솔직하게 적었습니다.
CSS는 일관성을 맞추고 시작했는데 상태 관리는 안 했다. 이 한 문장이 많은 걸 설명합니다. 눈에 보이는 것은 안 맞으면 바로 티가 나니까 미리 맞춥니다. 상태는 안 보이니까 미룹니다. 그리고 안 보이는 게 어긋나면, 그때는 밤을 새워야 찾습니다.
그리고 도구를 고른 이유도 정직하게 적혀 있습니다.
"압박감"이라는 단어가 정확합니다. 포트폴리오가 될 프로젝트라면 좋은 기술 스택을 써야 할 것 같고, 남들이 많이 쓰는 걸 골라야 할 것 같거든요.
그런데 도구의 난이도와 팀의 준비도가 안 맞으면 그 선택이 비용으로 돌아옵니다. Redux는 미리 정할 게 많은 도구입니다. 무엇을 바꿀 수 있는지(action), 어떻게 바뀌는지(reducer)를 앞에서 다 정해두는 구조라, 그 정하는 과정을 건너뛰면 도구만 무거워지고 이득이 없어요.
이 팀이 정확히 그 상태였습니다. Redux를 도입했지만 Redux가 요구하는 사전 합의는 하지 않은 상태요. 그러면 각자 자기 Slice에 자기 값을 넣게 되고, 결국 도구를 안 쓴 것과 같아집니다. 오히려 설정만 늘어난 셈이죠.
도구가 잘못된 게 아니라 순서가 뒤바뀐 것입니다. 상태를 어떻게 나눌지 정하고 나서 도구를 고르면 Redux는 잘 맞습니다. 도구를 먼저 고르고 나눔은 나중에 하면, 어떤 도구를 골랐든 같은 문제가 생기고요.
큐레이터 노트
이 글이 좋은 건 자기 코드에는 문제가 없었다고 분명히 적었다는 점입니다.
여기서 끝냈다면 "내 잘못 아님"으로 읽힐 수 있습니다. 그런데 이어지는 문장이 팀 전체의 절차를 짚어요. 내 코드가 멀쩡한데도 프로젝트가 실패할 수 있다는 걸, 그리고 그건 개인의 실력 문제가 아니라 합의의 문제라는 걸 분명히 합니다.
부트캠프나 학교 팀 프로젝트에서 가장 자주 나오는 실패가 정확히 이겁니다. 각자 자기 몫을 열심히 했는데 합치니까 안 돌아가는 것. 이 글은 그 경험을 다음번에 무엇을 먼저 할지로 바꿔놨습니다.
그리고 마지막 문장. "다음 편에는.. 이론과..실전을.." — 4회차 큐레이션에서 그 다음 편을 만나실 수 있습니다.
03
🛒 스프링부트 쇼핑몰 프로젝트 1
진한솔 님
교재를 따라 스프링부트로 쇼핑몰을 만드는 연재의 첫 편입니다. 이번 편에서 하는 일은 딱 두 가지예요. 프로젝트를 인텔리제이로 열고, MariaDB를 설치해서 연결하는 것.
압축을 어디에 풀고, 어떤 버튼을 누르고, 어떤 체크박스를 켜야 하는지가 번호를 붙여 순서대로 적혀 있습니다. 화면 캡처도 단계마다 붙어 있어요.
중간에 MariaDB가 무엇인지, MySQL과 비교해 무엇이 낫고 무엇이 부족한지도 정리했습니다.
1회차 큐레이션에서 진한솔 님의 426자짜리 다짐을 소개해드렸습니다. "원래 하나를 시작해도 끝까지 마치지 못하고 중간에 포기했었는데 이번엔 완주하겠다"는 글이었죠.
이 글이 그 연재의 첫 편입니다.
조금 더 들어가 보면
🐬 왜 MySQL이 아니라 MariaDB인가
설치 안내 중간에 데이터베이스 설명이 들어갑니다. 교재가 MariaDB를 쓰라고 해서인데, 그냥 따르지 않고 이게 뭔지부터 정리했어요.
포크(Fork)는 기존 오픈소스 프로젝트의 코드를 그대로 가져다 별도 프로젝트로 갈라져 나온 것을 말합니다. 같은 뿌리에서 출발했으니 초기에는 거의 똑같고, 시간이 지나면서 조금씩 달라집니다.
MariaDB가 MySQL에서 갈라져 나온 이유를 알면 이 구분이 더 선명해집니다. MySQL이 상업 회사에 인수되면서, 오픈소스로 남을지 불확실해진 상황을 걱정한 원 개발진이 코드를 복사해 새 프로젝트를 시작한 것이 MariaDB예요.
그래서 글이 정리한 장단점이 그 배경과 정확히 맞물립니다.
오픈소스 — 오픈 소스를 무료로 사용 가능하며, 비용 절감과 라이선스 문제에 대한 걱정이 없다.
호환성은 같은 코드에서 출발했으니 당연하고, 라이선스 걱정 없음은 애초에 그것 때문에 갈라져 나왔으니 당연합니다.
단점도 같은 논리로 설명됩니다.
MySQL은 Oracle Corporation이 후훤하고 있으며, 상용 라이선스와 기술 지원을 제공한다. 하지만 마리아DB는 오픈 소스 프로젝트이기 때문에 공식적인 기술 지원이 상대적으로 제한적일 수 있다.
갈라진 뒤에 각자 발전했으니 한쪽에만 있는 기능이 생기고, 회사가 뒤에 없으니 돈 주고 살 수 있는 기술 지원도 없습니다.
교재를 따라가는 글에서 여기까지 적는 경우는 흔치 않습니다. 대개 "MariaDB를 설치합니다"로 넘어가요. 그런데 이렇게 적어두면 나중에 회사에서 MySQL을 쓸 때 당황하지 않습니다. 거의 같지만 완전히 같지는 않다는 걸 알고 있으니까요.
🧭 교재의 목적과 수단을 구분하기
내용 자체는 화려하지 않습니다. 설치와 설정이니까요. 그런데 중간에 판단이 하나 들어 있습니다.
교재는 MariaDB를 쓰라고 하고, 설치하면 HeidiSQL이라는 관리 도구가 같이 깔립니다. 보통은 그대로 씁니다. 그런데 이분은 다른 걸 씁니다.
작은 대목인데, 교재를 그대로 따라가는 것과 다릅니다. 교재의 목적(데이터베이스에 접속한다)과 수단(HeidiSQL을 쓴다)을 구분하고, 수단은 자기 것으로 바꾼 겁니다.
📸 단계마다 화면을 붙인다는 것
이 글은 설치 과정이 번호로 쪼개져 있고, 단계마다 화면 캡처가 붙어 있습니다.
1-2. 인텔리제이 Projects 탭의 Open을 클릭합니다.
1-3. 프로젝트의 경로를 선택하고 OK를 클릭합니다.
1-4. 컨펌창이 열리면 Trust Project를 클릭합니다.
"컨펌창이 열리면 Trust Project를 클릭"까지 적혀 있는 게 포인트입니다.
이런 창은 글로 쓰기엔 사소해 보입니다. 그냥 누르면 되니까요. 그런데 처음 하는 사람에게는 처음 보는 창이 곧 멈추는 지점입니다. 이게 눌러도 되는 건지, 무슨 뜻인지 몰라서 검색하다가 흐름이 끊깁니다.
MariaDB 설치 부분에도 같은 배려가 있습니다.
UTF8 체크박스를 짚어둔 게 중요합니다. 기본값 그대로 넘어가면 한글 데이터를 넣을 때 글자가 깨집니다. 그리고 그 증상은 설치할 때가 아니라 한참 뒤 상품명에 한글을 넣는 순간 나타나요. 그때는 원인이 설치 옵션이라는 걸 떠올리기 어렵습니다.
물론 이 방식에는 약점도 있습니다. 버전이 올라가면 화면이 바뀝니다. 지금 보면 인텔리제이나 MariaDB 설치 화면이 글과 다를 수 있어요. 그래서 설치 글은 수명이 짧습니다.
그런데 짧은 수명이 쓸모없음을 뜻하진 않습니다. 같은 교재로 같은 시기에 공부하는 사람에게는 그대로 맞고, 시간이 지나도 "어떤 옵션을 신경 써야 하는지"는 남거든요. UTF8 체크는 버전이 바뀌어도 여전히 챙겨야 하는 항목입니다.
MariaDB 설명도 균형이 있습니다. 장점 네 가지(호환성·성능·보안·오픈소스)만 적고 끝내지 않고 단점 두 가지를 함께 적었어요.
교재를 따라가는 글에서 단점까지 찾아 적는 경우는 흔치 않습니다. 그렇게 적어야 읽는 사람이 자기 상황에서 쓸지 말지 판단할 수 있게 되고요.
📝 원문에서는 이렇게 마무리합니다
마지막 두 줄이 이 연재의 성격을 보여줍니다.
다음 시간에는 생성한 프로젝트를 본격적으로 한걸음씩 진행해보는 시간을 가지도록 하겠습니다.
어디까지 했고 다음에 어디부터 할지를 매 편 끝에 적어둡니다. 연재를 이어가는 사람의 습관이에요. 이렇게 적어두면 2주 뒤에 다시 앉았을 때 "내가 어디까지 했더라"로 시간을 쓰지 않게 됩니다.
큐레이터 노트
설치 과정을 큐레이션에 넣은 이유는 이게 연재의 1편이기 때문입니다.
기술 블로그에서 가장 안 써지는 글이 설치와 설정입니다. 재미없고, 검색하면 나오고, 버전이 바뀌면 금방 낡거든요. 그래서 대부분 건너뛰고 "본론"부터 씁니다. 그리고 그 본론은 자주 시작되지 않습니다. 1편이 없으면 2편도 없어요.
이분은 1편을 썼습니다. 압축 푸는 경로부터요. 그리고 그 뒤에 2·3·4·5편이 붙었습니다. 프로젝트 설정 다음에는 쿼리 메소드, 그다음엔 @Query 어노테이션, 마지막엔 타임리프까지 갔어요.
7회차 큐레이션에서 이 연재의 마지막 편을 소개해드리겠습니다. 5개월 뒤에 같은 사람이 무엇을 쓰고 있는지 보시면 좋겠습니다.
💡 세 편을 겹쳐 읽으며
세 글은 만드는 것이 다릅니다. 게임, 웹 서비스, 쇼핑몰. 쓰는 도구도 언리얼, React, 스프링부트로 겹치는 게 없어요.
그런데 세 글이 같은 것을 말합니다. 경계를 먼저 그어두었느냐.
허해수 님은 3주차에 멈춰서 경계를 그었습니다. 메시는 보이는 것, 콜리전은 부딪히는 것, 피직스는 움직이는 것. 셋이 무엇을 책임지는지 정리하고 나서 자기 몫으로 들어갔어요.
이지은 님은 그 정리를 하지 않고 시작했습니다. 정확히 말하면, CSS는 맞추고 상태는 안 맞췄습니다. 무엇을 전역으로 공유할지 협의하지 않은 채 각자 자기 칸을 채웠고, 조각들이 만나는 자리에서 어긋났습니다. 그리고 그 어긋남을 발표 전날 밤에 셋이서 콘솔을 찍어가며 찾았어요.
진한솔 님은 혼자 하는 프로젝트라 남과 맞출 일이 없습니다. 대신 시간과 맞춥니다. 매 편 끝에 어디까지 했고 다음에 어디부터 할지를 적어두는 것 — 2주 뒤의 자기와 긋는 경계입니다.
어긋남은 조각 안에서 생기지 않고 조각과 조각 사이에서 생깁니다. 각자 열심히 했는데 안 되는 팀 프로젝트가 그렇고, 프레임 레이트가 다른 컴퓨터에서 속도가 달라지는 게임이 그렇고, 2주 만에 다시 열었더니 어디까지 했는지 모르겠는 개인 프로젝트가 그렇습니다.
이번 회차에서 가져갈 것
1. 안 보이는 것부터 맞추기.
이지은 님 팀은 CSS는 일관성을 맞추고 시작했는데 상태 관리는 못 했습니다. 눈에 보이는 건 안 맞으면 바로 티가 나서 자연히 맞추게 되고, 안 보이는 건 미루게 되거든요. 그런데 문제는 늘 안 보이는 쪽에서 터집니다. 팀 프로젝트를 시작한다면 "무엇을 공유하고 누가 소유할지"를 CSS보다 먼저 정하세요.
2. 헷갈리면 만들기를 멈추고 정리하기.
허해수 님은 3주차에 진도를 나가는 대신 개념을 정리했습니다. 헷갈리는 채로 만들면 돌아가긴 하는데 왜 되는지 모르는 코드가 쌓입니다. 한 번 멈추는 비용이 나중에 헤매는 비용보다 쌉니다.
3. 1편을 쓰기.
설치와 설정은 재미없어서 다들 건너뜁니다. 그런데 1편이 없으면 2편도 안 나옵니다. 진한솔 님은 압축 푸는 경로부터 적었고, 그 뒤에 네 편이 더 붙었어요.
4. 매 편 끝에 다음 자리를 적어두기.
"여기까지 했고 다음엔 여기부터"를 한 줄 남기면, 다시 앉았을 때 기억을 되살리는 시간이 사라집니다. 2주에 한 번 쓰는 기록이라면 특히요.
1기는 2024년 5월에 시작해 8월에 마무리된 그로스로그의 첫 기수였습니다. 3회차쯤 되면 각자 무엇을 쓸지가 자리를 잡습니다. 이 회차에 소개해드린 세 분은 여기서부터 마지막 회차까지 같은 주제를 끌고 갔어요.
혼자 겪은 시행착오는 그냥 지나간 밤이지만, 적어두면 누군가의 지름길이 됩니다.
좋은 글 남겨주신 허해수 님, 이지은 님, 진한솔 님께 감사드립니다. 그리고 아무 전례도 없던 첫 기수에서 묵묵히 기록을 이어가주신 모든 1기 멤버분들께도요! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.
'성장일지' 카테고리의 다른 글
| [GL 1기 5회차] 본체를 열지 않고 기능을 더하는 법 — Spring AOP, Visitor 패턴, 레벨 시퀀스 🌱 (0) | 2026.08.09 |
|---|---|
| [GL 1기 4회차] 맡긴 만큼 안 보인다 — 영속성 컨텍스트, Spring Data JPA, 상태관리 도구 🌱 (0) | 2026.08.09 |
| [GL 1기 2회차] 학교에서 배운 것과 현업 사이 — 과목 별점 후기, 워크북 족보론, 강의 밖의 스프링 🌱 (0) | 2026.08.09 |
| [GL 1기 1회차] 접었던 블로그를 다시 연 세 사람 — 사진 3요소, 깃허브 학생 인증, 완주 다짐 🌱 (0) | 2026.08.09 |
| [GL 3기 8회차 ①] 같은 약자 다른 뜻 — CSR 렌더링과 인증서, 그리고 타입스크립트 🌱 (0) | 2026.08.07 |