개발자 인생의 최대 미스터리: "내 캐릭터는 왜 자꾸 벽을 뚫고 사라질까?"
반갑습니다. 15년 차 게임 클라이언트 개발자이자, 여러분과 똑같은 고민으로 수많은 밤을 지새웠던 선배 개발자입니다. 게임 개발을 시작하고 처음 캐릭터를 움직이게 만들었을 때의 그 짜릿함, 기억하시나요? 화면 속 작은 생명체가 내 키보드 입력에 반응할 때의 희열은 이루 말할 수 없습니다. 하지만 그 기쁨도 잠시, 본격적인 테스트 플레이를 시작하면 악몽이 찾아옵니다. 캐릭터가 벽을 뚫고 지나가거나, 바닥 아래로 쑥 꺼져버리는 순간, 우리는 깊은 절망에 빠지게 됩니다. 마치 양자 역학의 터널링 효과처럼, 물리 법칙을 무시하고 벽을 통과해버리는 이 현상은 유니티 2D 개발 입문자들이 겪는 가장 흔하면서도 가장 해결하기 까다로운 난제 중 하나입니다.
저 역시 주니어 시절, 출시가 코앞인 2D 하드코어 플랫포머 게임 프로젝트에서 이 문제로 곤욕을 치른 적이 있습니다. 최종 보스 몬스터가 공격 모션을 취할 때마다 벽에 끼어 움직이지 못하거나, 플레이어가 비밀 벽을 뚫고 맵 밖으로 떨어져 무한 낙하하는 버그가 발생했습니다. 당시 팀장님께 "충돌체(Collider)를 더 크게 만들면 되지 않을까?"라고 안일하게 보고했다가 크게 혼났던 기억이 납니다. 단순히 크기를 키운다고 해결될 문제가 아니었기 때문입니다. 이는 물리 엔진의 연산 방식, 프레임 레이트(FPS), 그리고 우리가 작성한 이동 로직 간의 미묘하고 복잡한 불협화음 때문입니다.
오늘 이 글에서는 유니티의 물리 엔진(Box2D 기반)이 어떻게 작동하는지 그 근본적인 원리부터 시작해서, 실무 현장에서만 알 수 있는 디테일한 Rigidbody2D 설정법, 코드로 해결하는 이동 로직, 그리고 성능을 잡아먹지 않으면서도 완벽한 충돌 처리를 구현하는 최적화 기법까지 낱낱이 파헤쳐 드리겠습니다. 단순히 "이 버튼을 체크하세요"가 아닌, "왜 이 현상이 발생하며, 어떻게 근본적으로 차단하는지"를 데이터와 경험을 바탕으로 깊이 있게 다룰 것입니다. 커피 한 잔 진하게 타 오세요. 이 글을 다 읽고 나면, 여러분의 캐릭터는 더 이상 벽을 뚫지 않을 것입니다.
1. 왜 뚫리는가? 유니티 물리 엔진의 '눈깜빡임' 현상 완벽 해부
캐릭터가 벽을 뚫는 현상을 근본적으로 해결하려면, 먼저 유니티가 세상을 어떻게 바라보는지 이해해야 합니다. 인간은 시간이 연속적으로 흐른다고 느끼지만, 게임 엔진에게 시간은 '프레임(Frame)'이라는 단위로 뚝뚝 끊겨서 흐르는 불연속적인 사진들의 나열입니다. 이것이 모든 문제의 시작점입니다.
이산적(Discrete) 충돌 감지의 치명적 한계
유니티의 기본 물리 설정은 Discrete(이산적) 충돌 감지 방식을 사용합니다. 아주 쉽게 비유해 보겠습니다. 여러분이 1초에 60번 눈을 깜빡이는 사람이라고 가정해 봅시다. 눈을 떴을 때 캐릭터가 A 지점에 있었고, 다시 눈을 감았다가 떴을 때(다음 프레임) 캐릭터가 C 지점으로 이동했습니다. 그런데 A와 C 사이에 아주 얇은 벽(B)이 있었다면 어떻게 될까요? 여러분의 눈(물리 엔진)은 캐릭터가 벽을 지나가는 과정을 보지 못했습니다. 그저 A에 있다가 C로 순간 이동한 것으로 인식합니다. 물리 엔진은 "어? 이동 경로에 아무것도 없었네?"라고 판단하고 충돌 처리를 생략합니다. 이것이 바로 캐릭터가 벽을 뚫고 지나가는 터널링(Tunneling) 효과입니다.
실제 프로젝트에서 제가 겪었던 사례를 구체적인 수치로 말씀드리겠습니다. 총알 속도가 초당 100유닛인 슈팅 게임을 개발 중이었습니다. 게임이 30FPS로 떨어지는 상황이 발생하자, 한 프레임당 총알은 약 3.3유닛을 이동하게 되었습니다(100 / 30). 그런데 맵에 배치된 벽의 두께는 고작 0.5유닛이었습니다. 총알의 한 보폭(3.3)이 벽의 두께(0.5)보다 훨씬 컸기 때문에, 총알은 벽을 투명 인간처럼 통과해버렸습니다. 수학적으로 계산했을 때, 충돌을 감지하지 못할 확률이 80% 이상이었습니다.
FixedUpdate와 Update의 위험한 엇박자
또 하나의 중요한 원인은 Update와 FixedUpdate의 주기 차이입니다. 초보 개발자분들이 가장 많이 하는 치명적인 실수가 물리 연산과 관련된 이동 코드를 `Update` 함수에 넣고 `transform.position`을 직접 수정하는 것입니다. `Update`는 기기의 그래픽 성능에 따라 호출 주기가 달라집니다(가변 프레임). 반면, 유니티의 물리 엔진은 `FixedUpdate`라는 고정된 주기(기본값 0.02초, 즉 50FPS)로 계산됩니다.
만약 여러분이 고성능 게이밍 PC에서 게임을 돌려서 200 FPS가 나온다면, `Update`는 `FixedUpdate`보다 4배나 더 자주 호출됩니다. 이때 `transform.position`을 강제로 변경하는 코드를 `Update`에 넣으면, 물리 엔진이 충돌을 계산하기도 전에 캐릭터의 위치가 강제로 벽 너머로 텔레포트됩니다. 이는 마치 축구 심판이 호루라기를 불기도 전에 선수가 골대 안으로 공을 손으로 던져 넣는 것과 같습니다. 물리 엔진은 뒤늦게 확인하지만, 이미 캐릭터는 벽 속에 파묻혀 있거나 벽을 통과한 뒤입니다.
💡 핵심 원리: 물리 엔진은 연속적인 움직임을 완벽하게 추적하지 않습니다. 띄엄띄엄 위치를 확인하기 때문에, 그 사이의 간격(이동 거리)이 벽의 두께보다 크면 벽은 존재하지 않는 것처럼 통과해버립니다. 이를 해결하는 것이 오늘 강의의 핵심입니다.
2. Rigidbody2D 설정 마스터하기: 엔진 튜닝의 기술
캐릭터의 움직임을 담당하는 심장, 바로 Rigidbody2D 컴포넌트입니다. 많은 분들이 이 컴포넌트를 추가만 해놓고 기본값(Default) 상태로 방치합니다. 하지만 이 설정값 하나하나가 충돌 정확도와 성능에 결정적인 영향을 미칩니다. 15년 동안 수많은 프로젝트를 거치며 검증된 '황금 세팅'을 알려드리겠습니다.
Collision Detection: 성능과 정확도의 트레이드오프
Rigidbody2D 컴포넌트에서 가장 중요한 옵션은 Collision Detection(충돌 감지)입니다. 기본값인 Discrete는 빠르지만 부정확합니다. 캐릭터가 자꾸 벽을 뚫는다면, 상황에 맞춰 이 옵션을 변경해야 합니다.
Continuous 모드는 물리 엔진에게 이렇게 명령하는 것과 같습니다. "이 물체가 A에서 C로 이동할 때, 그 경로 사이에 무엇이 있었는지 과거를 역추적해서 계산해줘." 이렇게 하면 캐릭터가 한 프레임에 벽을 뚫고 지나갈 만큼 빠르게 이동하더라도, 물리 엔진이 이동 경로상의 충돌을 감지하여 벽 앞에서 멈추게 합니다. 특히 Continuous Dynamic은 매우 빠른 물체끼리의 충돌까지 계산합니다.
하지만 주의할 점이 있습니다. Continuous 모드는 Discrete보다 CPU 연산량을 2~3배 이상 더 사용합니다. 따라서 맵에 있는 모든 나무 상자나 돌멩이 같은 오브젝트에 이것을 적용하면 모바일 기기에서 프레임 드랍이 발생합니다. 플레이어 캐릭터나 빠른 투사체(총알, 화살) 같은 중요한 객체에만 선별적으로 적용해야 합니다. 제 경험상, 전체 물리 오브젝트의 5% 미만에만 적용하는 것이 성능상 안전합니다.
Interpolate: 부드러운 움직임의 비밀
충돌 문제는 아니지만, 캐릭터가 움직일 때 미세하게 떨리는(Jittering) 현상을 겪어보셨을 겁니다. 이는 물리 연산 주기(FixedUpdate)와 화면 렌더링 주기(Update)가 일치하지 않아서 생기는 현상입니다. 이때 Interpolate 옵션을 사용해야 합니다.
- None: 보정 없음. 리소스를 가장 적게 먹지만 움직임이 뚝뚝 끊겨 보일 수 있습니다. 배경 사물에 적합합니다.
- Interpolate: 이전 프레임과 현재 프레임 사이를 부드럽게 보간합니다. 캐릭터의 움직임이 훨씬 매끄러워 보입니다. 플레이어 캐릭터와 카메라 추적 대상에 필수입니다.
- Extrapolate: 현재 속도를 바탕으로 다음 프레임의 위치를 예측합니다. 네트워크 게임이나 반응속도가 0.01초가 급한 경우에 쓰지만, 예측이 틀리면 벽을 뚫었다가 다시 튀어나오는 현상이 발생할 수 있어 주의가 필요합니다.
Sleeping Mode: 잠자는 물리 엔진 깨우기
유니티는 최적화를 위해 움직이지 않는 물체의 물리 연산을 중단하고 '수
댓글
댓글 쓰기