빌드하고 출시하는 첫 게임

게임을 만드는 일은 멋집니다. 하지만 진짜로 손이 떨리는 순간은 따로 있습니다. 빌드 버튼을 누르고, 남에게 보여줄 수 있는 형태로 세상에 내보내는 순간입니다.

지금까지 우리는 플레이어를 움직이고, 점프시키고, 적을 만들고, UI와 사운드까지 붙였습니다. 이제 남은 건 마지막 한 걸음입니다. 그런데 이상하게도 이 마지막 한 걸음이 가장 무섭습니다. 에디터에서는 잘 돌아가는데 빌드하면 안 켜지고, 웹에서는 화면이 잘리고, 휴대폰에서는 터치가 먹지 않기도 하니까요.

그래서 이 장의 목표는 단순히 "빌드 성공"이 아닙니다. Windows, WebGL, Android로 각각 빌드하고, 실제 배포 링크와 실제 기기에서 다시 확인하며, 최소한의 출시 자료까지 준비하는 것입니다. 한 번이라도 이 과정을 끝까지 해보면, 게임 개발은 더 이상 막연한 공부가 아니라 분명한 제작 경험으로 바뀝니다.

빌드는 버튼이 아니라 운영이다

처음 출시를 해보는 사람은 종종 이렇게 생각합니다. "플랫폼만 바꿔서 빌드하면 끝나는 거 아닌가요?" 아쉽게도 현실은 조금 더 복잡합니다. Windows는 실행 파일과 데이터 폴더를 함께 묶어야 하고, WebGL은 압축 방식과 브라우저 표시 크기까지 신경 써야 하며, Android는 패키지명과 서명 키스토어가 필요합니다.¹²

문제는 플랫폼 설정이 한곳에 뒤엉켜 있으면, 어제 WebGL용으로 바꿔 둔 값이 오늘 Android 빌드를 망치고, 모바일 세로 화면 설정이 PC 창 크기에 그대로 남아버리는 식의 사고가 자주 난다는 점입니다. 이런 실수를 줄이기 위해 Unity 6에서는 Build Profiles 중심으로 플랫폼별 설정을 분리해서 관리하는 습관이 아주 중요합니다.³

쉽게 말해 Build Profiles는 플랫폼별로 따로 보관하는 작업 가방입니다. Windows용 가방에는 PC 해상도와 실행 설정을 넣고, WebGL용 가방에는 웹 압축과 화면 비율을 넣고, Android용 가방에는 세로 방향과 앱 번들 설정을 넣는 식입니다. 한 가방의 내용물이 다른 가방을 어지럽히지 않게 만드는 것이 핵심입니다.

먼저 Build Profiles부터 정리하자

이번 장에서는 다음처럼 프로필을 나눠 두는 것을 권합니다.

• Windows Release: itch.io에 올릴 PC 버전

• WebGL Prototype: 브라우저로 바로 플레이할 공유 버전

• Android Internal Test: 휴대폰 설치 테스트용 버전

• Android Store Release: 스토어 제출 직전 최종 버전

이렇게 나눠 두면 같은 게임이라도 목적이 달라집니다. 예를 들어 WebGL Prototype은 용량과 로딩 속도를 우선으로 보고, Android Store Release는 앱 아이콘·패키지명·AAB·서명까지 챙깁니다.

프로필을 만들고 나면 가장 먼저 확인할 것은 씬 목록입니다. 에디터에서 열어 둔 테스트 씬이 그대로 들어가 버리면, 출시 빌드에서 이상한 디버그 화면이 먼저 뜰 수 있습니다. 그래서 출시용 프로필에서는 실제로 필요한 씬만 포함해야 합니다. 보통은 타이틀, 게임, 결과 화면 정도면 충분합니다.

그다음은 플랫폼별로 자주 바뀌는 항목을 프로필 기준으로 정리합니다.

• 씬 포함 여부

• 해상도와 화면 비율

• 화면 방향

• 압축 방식

• Player Settings의 플랫폼별 옵션

이 다섯 가지를 프로필 단위로 관리하면, 초보자가 가장 많이 하는 실수인 "지난 플랫폼 설정이 다음 빌드를 망치는 일"을 크게 줄일 수 있습니다.³

Windows 빌드: 가장 먼저 완주 경험을 만든다

가장 추천하는 첫 출시는 Windows 빌드입니다. 이유는 간단합니다. 디버깅이 쉽고, 친구에게 전달하기도 쉽고, 실행 환경이 비교적 안정적이기 때문입니다. 무엇보다 한 번 ZIP 파일로 묶어 전달해 보면, "내 게임이 진짜 설치형 프로그램이 되었구나"라는 감각이 확 옵니다.

Windows 프로필에서는 우선 Product Name과 Company Name이 이상하지 않은지 확인합니다. 아직 1인 개발자라도 괜찮습니다. Company Name은 본인 닉네임이나 스튜디오 가칭이면 충분합니다. 버전 번호도 함께 정리해 두세요. 0.1.0처럼 작은 숫자부터 시작하면 됩니다.

빌드를 하면 Unity는 실행 파일과 함께 _Data 폴더를 만듭니다. 이 폴더는 옵션이 아니라 필수입니다. 게임이 실제로 읽어야 하는 에셋과 라이브러리가 들어 있기 때문입니다. 실행 파일만 따로 보내면, 받는 사람 입장에서는 거의 확정적으로 실행 오류를 만나게 됩니다.⁴

여기서 중요한 건 "업로드"보다 "패키징"입니다. itch.io도 개별 DLL을 따로 올리는 방식이 아니라, 실행 파일과 _Data 폴더를 포함한 빌드 결과 전체를 하나의 ZIP으로 묶는 방식을 권장합니다.⁴

파일 이름도 습관을 들이면 좋습니다. 예를 들어 JumpFox_Windows_v0.1.0.zip처럼 게임 이름, 플랫폼, 버전을 넣어 두면 나중에 본인도 덜 헷갈립니다. 출시를 몇 번만 반복해도 final_final_realfinal.zip 같은 이름의 비극을 피하고 싶어질 겁니다.

Windows 패키징에서 꼭 지킬 것

• 실행 파일만 보내지 않는다.

• _Data 폴더를 반드시 함께 묶는다.

• 빌드 결과 전체를 압축한다.

• 압축 파일을 내려받아 다른 폴더에서 직접 풀어 다시 실행해 본다.

마지막 줄이 특히 중요합니다. 내 컴퓨터에서는 되는 이유가 사실은 원본 프로젝트 경로에 뭔가 남아 있어서일 때가 있습니다. 그래서 내가 방금 만든 ZIP을 다시 풀어서 새 폴더에서 테스트하는 절차가 필요합니다. 이 한 번의 확인이 출시 사고를 꽤 많이 막아줍니다.⁴

itch.io에 Windows 버전 올리기

itch.io는 인디 게임 개발자에게 거의 놀이터 같은 곳입니다. 회원가입이 쉽고, 배포가 빠르며, 테스트용 링크 공유에도 좋습니다. 처음 출시를 경험하기에는 정말 훌륭한 무대입니다.

Windows 버전을 올릴 때는 새 프로젝트를 만든 뒤, ZIP 파일 하나만 업로드하면 됩니다. 공개 범위는 처음엔 Draft나 Restricted로 두고, 친구 몇 명에게만 테스트를 부탁해도 좋습니다. 어느 정도 확인이 끝나면 Public으로 전환하면 됩니다.⁴

여기서 기억할 점은, 출시 페이지도 게임의 일부라는 것입니다. 파일만 올려 두고 설명이 없으면 플레이어는 조금 불안해합니다. 최소한 아래 내용은 적어 주세요.

• 어떤 게임인지 한 줄 설명

• 조작 방법

• 예상 플레이 시간

• 권장 플랫폼

• 알려진 문제 한 줄

짧아도 괜찮습니다. 오히려 짧고 정확한 설명이 더 신뢰를 줍니다.

WebGL 빌드: 가장 빠르게 보여주는 링크를 만든다

이제 가장 흥미로운 플랫폼으로 가보겠습니다. WebGL은 설치 없이 브라우저에서 바로 실행됩니다. 그래서 프로토타입 검증에 특히 강합니다. 링크 하나만 보내면 상대가 바로 플레이해 볼 수 있으니까요.

Unity에서 WebGL 빌드를 만들면 index.html, Build 폴더, 경우에 따라 TemplateData 같은 폴더가 함께 생성됩니다. 이 구조는 유지되어야 합니다. 특히 압축해서 올릴 때 index.html이 ZIP의 최상단에 있어야 하고, 그 아래에 Build 폴더가 제대로 따라와야 합니다.²⁴

이 구조가 한 번만 꼬여도 itch.io에서는 "브라우저에서 실행되는 것처럼 보이지만 실제로는 로딩 실패" 같은 일이 생깁니다. 그러니 WebGL은 빌드 성공보다 압축 품질이 더 중요하다고 생각해도 좋습니다.

WebGL용 Build Profile에서 먼저 확인할 것

WebGL은 특히 용량과 로딩 시간이 중요합니다. Unity 공식 문서도 모바일 웹용 WebGL에서는 개발 빌드를 끄고, 빌드 크기를 줄이는 방향으로 최적화하라고 권장합니다.⁵

프로필에서 먼저 확인할 항목은 다음과 같습니다.

• Development Build가 꺼져 있는가

• 코드 최적화가 릴리스용으로 맞춰져 있는가

• 압축 포맷이 배포 환경에 맞는가

• 세로형인지 가로형인지 해상도 기준이 정리되어 있는가

• 품질 설정이 과도하지 않은가

WebGL은 PC 네이티브 빌드보다 메모리와 성능 제약이 큽니다. 특히 모바일 브라우저에서는 초기 로딩이 느리거나 메모리 부족으로 종료될 수 있으니, "에디터에서 잘 돌아간다"를 절대 기준으로 삼으면 안 됩니다.⁵⁶

WebGL 압축과 로딩 시간을 이해하자

WebGL에서 압축은 단순한 체크박스가 아닙니다. 체감 품질에 직접 연결됩니다. 공식 문서에서는 Brotli가 더 작은 파일을 만들 수 있다고 설명하지만, 실제 배포 환경에서는 서버가 그 압축 형식을 제대로 제공해야 합니다.² 문제는 모든 호스팅 환경이 그 설정을 세밀하게 제어하게 해주지 않는다는 점입니다.

초보자 기준으로는 이렇게 기억하면 충분합니다.

브라우저 배포를 빨리 확인해야 할 때는 안정성 우선, 즉 로딩이 확실히 되는 설정을 먼저 고릅니다. 그다음에 파일 크기를 줄이는 최적화를 합니다. 처음부터 가장 작은 용량만 노리다 보면, 아예 실행이 안 되는 함정에 빠지기 쉽습니다.

서버 설정을 직접 만질 수 없는 환경이라면 Gzip 쪽이 더 편한 경우도 있고, 호환성이 애매하면 Decompression Fallback도 검토할 수 있습니다. 중요한 것은 "정답 설정 하나"를 외우는 것이 아니라, 내 배포 환경에서 실제로 열리는지 테스트하는 것입니다.

itch.io에 WebGL 올리기

itch.io에서 WebGL 프로젝트를 만들 때는 Kind of project를 HTML로 설정해야 하고, 업로드한 ZIP에 대해 This file will be played in the browser 옵션을 켜야 합니다.⁴ 이 두 가지를 놓치면 "웹에서 실행할 생각이 없는 파일"로 취급되어 버립니다.

그리고 정말 중요한 것이 임베드 크기와 비율입니다. 세로형 게임인데 가로형 뷰포트로 올려 두면, 게임은 멀쩡해도 첫인상이 망가집니다. 반대로 16:9 게임을 너무 좁게 넣어도 버튼이 답답해 보입니다. itch.io는 뷰포트 크기를 비교적 쉽게 조절할 수 있어서, MVP 공유와 피드백 수집에 특히 편리합니다.⁴

WebGL 업로드 직후 꼭 다시 볼 것

업로드가 끝났다고 끝난 것이 아닙니다. 진짜 테스트는 이제부터입니다. 로컬에서 Build and Run으로 확인한 결과와, 실제 배포 링크에서의 동작은 다를 수 있습니다.²

아래 항목은 실제 itch.io 링크에서 직접 확인하세요.

• 첫 로딩이 몇 초쯤 걸리는가

• 화면이 잘리거나 여백이 이상하지 않은가

• 키보드 입력이 지연되지 않는가

• 모바일 브라우저에서 아예 안 뜨지는 않는가

• 첫 사용자 입력 전까지 브라우저 정책 때문에 사운드가 막히지 않는가

Unity는 웹 런타임 경험을 꾸준히 개선하고 있습니다.⁶ 하지만 그 말이 곧 "모든 폰에서 네이티브 앱처럼 잘 돌아간다"는 뜻은 아닙니다. 실제 호환성과 체감 성능은 브라우저와 기기 조합에 따라 차이가 있으며, 간단한 게임일수록 성공 확률이 높습니다.

그래서 WebGL은 완성품 판매 채널이라기보다 가볍게 보여 주고 반응을 받는 채널로 이해하는 편이 좋습니다. 특히 이 책에서 만드는 첫 게임처럼 작은 2D 캐주얼 게임에는 아주 잘 어울립니다.

AI에게 묻자
"내 Unity WebGL 게임을 itch.io에 올렸는데, PC 크롬에서는 잘 되지만 모바일 사파리에서 화면이 잘립니다. 게임 비율은 9:16이고, itch.io 임베드 크기는 360x640입니다. 확인해야 할 원인을 우선순위 순서대로 정리해 줘. 해상도, Canvas Scaler, 브라우저 UI, 입력 지연, 압축 설정도 같이 봐 줘."

이렇게 물으면 AI가 훨씬 현실적인 체크리스트를 줍니다. 그냥 "왜 안 돼?"라고 묻는 것보다, 플랫폼·비율·증상·기대 결과를 함께 적는 편이 훨씬 좋습니다.

Android 빌드: 드디어 휴대폰에서 내 게임을 켠다

처음 휴대폰에 내 게임을 직접 설치해 실행하는 순간은 정말 묘합니다. 같은 게임인데도 "아, 이게 진짜 앱 같구나"라는 느낌이 듭니다. 그런데 Android는 Windows와 WebGL보다 챙길 것이 조금 더 많습니다.

우선 패키지명부터 정리해야 합니다. 보통 com.회사이름.게임이름 형식을 씁니다. 예를 들어 개인 프로젝트라면 com.wislan.jumpfox처럼 만들 수 있습니다. 이 값은 나중에 스토어 식별자 역할도 하므로, 너무 대충 정하지 않는 편이 좋습니다.¹

그다음은 버전, 아이콘, 화면 방향입니다. 세로 게임이라면 Portrait 중심으로, 가로 게임이라면 Landscape 중심으로 명확하게 결정하세요. 자동 회전을 대충 켜 두면 의도하지 않은 방향 전환 때문에 UI가 흔들릴 수 있습니다.

APK와 AAB는 어떻게 다를까

처음엔 둘 다 비슷해 보여서 헷갈립니다. 간단히 말하면 APK는 직접 설치 테스트용, AAB는 Google Play 제출용이라고 기억하면 됩니다. Unity 공식 문서도 Google Play를 목표로 할 때는 Android App Bundle, 즉 AAB 사용을 안내합니다.¹

Build Profiles에서 Android 프로필을 열고 Build App Bundle (Google Play) 옵션을 켜면 AAB로 빌드할 수 있습니다.¹ 반면 휴대폰에 바로 깔아 보며 테스트할 때는 APK가 더 편할 수 있습니다. 즉, 초반에는 APK로 빠르게 확인하고, 스토어 직전에는 AAB로 전환하는 흐름이 자연스럽습니다.

키스토어: 출시용 자물쇠를 만든다고 생각하자

Android 앱은 서명이 있어야 배포할 수 있습니다. Unity 문서에서도 디버그 서명과 커스텀 서명을 구분해서 설명합니다. 테스트용으로는 기본 디버그 서명으로 기기 실행이 가능하지만, 스토어에 올릴 때는 커스텀 키스토어가 사실상 필수입니다.¹

처음 들으면 무섭지만, 키스토어는 어렵다기보다 잃어버리면 곤란한 열쇠에 가깝습니다. 한 번 만든 뒤 안전한 곳에 백업해 두세요. 이 열쇠를 잃어버리면, 같은 앱의 다음 업데이트를 배포하는 과정이 아주 고통스러워질 수 있습니다.

기억해야 할 점은 두 가지입니다. 첫째, 비밀번호를 메모 없이 머리로만 기억하려고 하지 마세요. 둘째, 프로젝트 폴더 안에만 두지 마세요. 클라우드와 오프라인 백업을 함께 두는 편이 안전합니다.

Unity는 보안상 키스토어 비밀번호를 다시 요구할 수 있습니다. 이건 귀찮지만 정상입니다. 오히려 정상이라서 안심해도 됩니다.¹

에디터에서는 되는데 폰에서는 안 되는 이유

이 문장은 모바일 개발자의 고전입니다. 그리고 거의 항상 실제로 일어납니다. 에디터에서는 키보드 입력으로 테스트했는데, 폰에선 터치 UI가 너무 작을 수 있습니다. PC에선 부드럽던 애니메이션이, 폰에선 프레임이 뚝 떨어질 수도 있습니다. 저장 데이터 경로, 권한, 해상도, 안전 영역 처리도 기기에서만 문제가 드러나는 일이 많습니다.

그래서 Android 빌드는 빌드 자체보다 실기기 테스트 습관이 더 중요합니다. 최소한 아래는 실제 기기에서 확인해야 합니다.

• 설치가 정상적으로 되는가

• 첫 실행에서 멈추지 않는가

• 터치 입력이 정확히 먹는가

• 세로/가로 방향이 의도대로 유지되는가

• 사운드와 진동이 과하지 않은가

• 저사양 기기에서 프레임이 급격히 떨어지지 않는가

• 권한을 요청했다면 이유가 납득 가능한가

처음엔 본인 폰 한 대만 있어도 괜찮습니다. 그다음에는 가족 폰, 친구 폰, 예전 기종 한 대 정도만 추가해도 문제 발견률이 크게 올라갑니다.

Google Play 등록 자료는 작게, 그러나 정확하게

많은 초보자가 출시 직전 가장 당황하는 지점이 여기입니다. 게임은 만들었는데, 정작 스토어에 올릴 소개 문구와 이미지가 없는 것입니다. 그런데 다행히 첫 게임은 거창할 필요가 없습니다. 핵심은 짧고 명확한 자료를 갖추는 것입니다.

설명문에는 적어도 네 가지가 드러나야 합니다. 게임의 핵심 재미, 조작법, 플레이 시간, 필요한 권한 이유입니다. 예를 들어 이런 식이면 충분합니다.

"짧은 스테이지를 달리고 점프하며 코인을 모으는 2D 액션 게임입니다. 좌우 이동과 점프만으로 플레이할 수 있으며, 한 판은 2~3분 안에 끝납니다. 저장 기능이 있다면 기기 내부 저장소를 사용합니다."

이 정도 문장만 있어도 읽는 사람은 안심합니다. 반대로 화려한 말만 가득하고 정작 조작법이 없으면 신뢰가 떨어집니다.

아이콘과 스크린샷도 마찬가지입니다. AI에게 초안을 부탁하는 건 좋습니다. 하지만 플랫폼 가이드에 맞게 자르고, 오해를 부르는 표현을 빼고, 실제 게임과 다른 장면이 없도록 직접 다듬어야 합니다. AI는 초안을 빠르게 만들고, 사람은 신뢰를 만든다고 생각하면 됩니다.

AI에게 묻자
"내 모바일 게임 스토어 소개 문구 초안을 써 줘. 장르는 2D 점프 액션, 플레이 시간은 2~3분, 조작은 좌우 이동과 점프, 타깃은 초등 고학년부터 성인까지야. 과장 광고처럼 보이지 않게 80자 소개 3개와 본문 설명 2개 버전으로 작성해 줘. 권한 안내 문장도 함께 넣어 줘."

이런 요청은 잘 먹힙니다. 반대로 "멋진 소개 써 줘"라고만 하면 광고 냄새 나는 문장이 나올 확률이 높습니다.

출시 전 최종 점검은 감이 아니라 체크리스트로 한다

출시 직전에는 이상하게 마음이 급해집니다. 그리고 그때 가장 많이 빠뜨리는 것이 기본 점검입니다. 그래서 마지막 검수는 감으로 하지 말고, 체크리스트로 하세요.

출시 전 체크리스트

• 게임이 첫 실행에서 정상 시작되는가

• 게임오버 후 재시작이 문제없이 되는가

• 저장 데이터가 꺼졌다 켜도 유지되는가

• 해상도와 화면 방향이 플랫폼별로 자연스러운가

• 효과음과 배경음이 너무 크거나 작지 않은가

• 외부 링크가 있다면 잘 열리는가

• 로딩 시간이 첫인상을 망칠 정도로 길지 않은가

• 크래시가 난다면 재현 순서를 적어 둘 수 있는가

여기서 핵심은 마지막 항목입니다. "가끔 꺼져요"는 QA에 거의 도움이 되지 않습니다. 대신 어떤 기기에서, 어떤 순서로, 무엇을 눌렀을 때, 기대 결과와 실제 결과가 어떻게 달랐는지를 적어야 합니다. 이 정보가 있어야 본인도 다시 찾을 수 있고, AI에게 물었을 때도 제대로 된 도움을 받을 수 있습니다.

예를 들어 이렇게 적는 겁니다.

"Galaxy A34, Android 15. 앱 실행 후 타이틀에서 시작 버튼 탭. 2번째 스테이지에서 코인 3개를 먹고 바로 점프하면 1초 정도 멈춘 뒤 앱이 종료됨. 기대 결과는 점프 애니메이션 재생, 실제 결과는 프리즈 후 종료. 재현율은 5번 중 3번."

이 정도면 AI도 단순 위로가 아니라 버그 재현 시나리오 정리, 의심 지점 추론, 추가 로그 수집 포인트 제안을 해줄 수 있습니다.

AI에게 묻자
"다음은 Unity Android 버그 재현 기록이야. 원인 가설을 5개로 좁히고, 각 가설을 확인하기 위한 가장 빠른 테스트를 제안해 줘. 그리고 내가 추가로 남겨야 할 로그 항목도 알려 줘. [기기명] [OS] [재현 순서] [기대 결과] [실제 결과] [재현율]"

이 프롬프트는 단순히 답을 받기 위한 것이 아니라, QA 사고방식 자체를 배우는 도구가 됩니다.

작은 출시가 학습 속도를 바꾼다

첫 출시를 해보면 이상한 일이 벌어집니다. 갑자기 Unity가 더 잘 보이기 시작합니다. 왜냐하면 그전까지는 기능을 배웠지만, 이제부터는 흐름을 이해하게 되기 때문입니다. 씬을 어떻게 나눠야 하는지, UI를 왜 안전하게 짜야 하는지, 사운드를 왜 줄여야 하는지, 왜 Build Profiles가 중요한지가 전부 연결됩니다.

그리고 무엇보다 자신감이 생깁니다. 아직 완벽한 게임이 아니어도 괜찮습니다. 오늘 당신은 단순히 따라 만든 사람이 아니라, 실제로 배포해 본 개발자가 되었기 때문입니다.

이 경험은 생각보다 큽니다. 두 번째 게임부터는 목표가 달라집니다. "만들 수 있을까?"가 아니라, "이번엔 어디를 더 좋게 만들까?"가 되기 때문입니다.

이 장에서 배운 것

• Build Profiles로 Windows, WebGL, Android 설정을 분리해 관리하는 이유

• Windows 빌드는 실행 파일과 _Data 폴더를 함께 ZIP으로 묶어야 한다는 점

• WebGL은 빌드 성공보다 폴더 구조와 임베드 설정, 실제 링크 테스트가 더 중요하다는 점

• itch.io가 MVP 공유와 피드백 수집에 특히 유리하다는 점

• Android에서는 패키지명, 화면 방향, 키스토어, AAB/APK 구분이 핵심이라는 점

• 실기기 테스트와 체크리스트 기반 QA가 출시 품질을 좌우한다는 점

• AI에게 질문할 때는 기기, 재현 순서, 기대 결과, 실제 결과를 함께 적어야 한다는 점

다음 장에서 만들 것

이제 우리는 2D 게임을 세상에 내보내는 데 성공했습니다. 다음 장에서는 시야를 넓혀 3D 미니 게임으로 넘어갑니다. 좌표계가 달라지고, 카메라 감각이 달라지고, 공간을 다루는 재미가 훨씬 커집니다. 2D에서 익힌 자신감을 들고, 이제는 플레이어가 공간 안을 직접 걸어 다니는 게임으로 확장해 봅시다.

참고

¹Build your application for Android

²WebGL 애플리케이션 빌드

³Introduction to build profiles

⁴Packaging Your Unity Game for itch.io: A Step-by-Step Guide

⁵Optimize WebGL platform for mobile

⁶웹 런타임 업데이트를 통한 브라우저 지원 강화