유니티 6.4~6.7 로드맵 총정리
by VR하는소년유니티 6.4, 벌써 “다운로드 가능”이라고 알려져 있어요 — 유니티 6.4~6.7 로드맵 총정리를 시작해 볼게요.
근데 진짜 중요한 건 버전 숫자가 아니라, 유니티 6.x 로드맵이 어디로 꺾였냐예요.
특히 유니티 6.4에서 ECS 영향력이 커지고, 이후 6.7 쪽에선 CoreCLR 전환 같은 큰 흐름이 예고되어 있어 체감이 꽤 클 수 있다고 알려져 있어요.
- 공식 공지 기준, 6.4는 다운로드 가능하다는 안내가 포럼과 릴리스 페이지에 올라온 것으로 알려져 있어요.
- 6.4의 핵심은 ECS 관련 변화와 Windows DirectStorage 도입 논의 쪽으로 정리되는 편이에요.
- 6.4→6.7 흐름은 URP 우선화와 런타임(스크립팅) 전환을 중심 축으로 보고 있어요.
- 일부 공지에서는 요금제·저장공간 정책 변화가 언급되는데, 정확한 수치와 기간은 공식 공지를 확인하는 쪽이 안전해요.
- Built‑In 관련 지원 표기나 LTS 표기는 문서마다 차이가 있어, Support 페이지의 EOS/EOL 표를 최종 기준으로 삼으세요.
유니티 6.4~6.7 로드맵 총정리 — 한 줄 요약
유니티 6을 “새 버전”이라고만 보면 타이밍을 놓치기 쉬워요. 핵심은 흐름의 전환 여부예요.
공식 발표 흐름을 보면 이 라인을 Unity 6로 정리하면서, 표준화 쪽에 더 무게가 실리고 있다는 인상이에요.
이미지: Unity Technologies / Public domain · Wikimedia Commons
포럼과 릴리스 안내를 기반으로 보면 6.4는 “사용 가능”으로 공지된 상태라는 설명이 나옵니다만, 정확한 날짜와 배포 범위는 릴리스 페이지를 기준으로 확인해야 해요.
즉, 로드맵이 ‘예고’에서 ‘실전’ 쪽으로 무게 중심을 옮긴 시점인 셈이죠. 이제 구체적으로 어떤 목표를 갖고 있는지 살펴볼게요.
Unity 6의 큰 목표: ‘파편화 줄이기’
유니티는 기능이 늘수록 선택지가 많아지는 대신, 프로젝트별로 구성이 갈라지는 문제가 늘었어요.
Unity 6 라인에서 자주 보이는 키워드는 성능, 일관성, 그리고 프로덕션 안정성이에요. 즉, 표준 경로를 굵게 만드는 쪽으로 무게를 옮긴 셈이죠.
📌 핵심 포인트
유니티 6.x는 새로운 기능을 무작정 더하기보다 표준 경로를 정리하는 데 집중하는 흐름이에요. 특히 URP와 런타임 전환 쪽으로 기울고 있다는 해석이 많아요.
여기까지가 큰 방향성이라면, 다음은 6.3→6.4에서 실제로 무엇이 달라졌는지 보면 감이 더 잡히실 거예요.
6.3→6.4, 딱 ‘여기’가 갈림길
포럼과 릴리스 노트 요약에서 공통으로 짚이는 변화는 ECS 관련 포지셔닝의 강화예요.
6.3까지는 ECS를 선택적으로 쓰는 프로젝트가 많았는데, 6.4에서부터는 엔진 쪽 의존성·통합 지점이 바뀌는 느낌이 더 강해졌다는 설명이 나오고 있어요.
Windows 플랫폼에서는 DirectStorage 관련 언급이 더해지면서 로딩·스트리밍 설계에 영향을 줄 것으로 보입니다.
다음엔 표로 차이를 정리해서, 팀 회의에서 빠르게 참고할 수 있게 할게요.
| 항목 | Unity 6.3(요약) | Unity 6.4(요약) |
|---|---|---|
| ECS 포지션 | 선택 패키지 성격이 강함 | 엔진 통합 관점에서 영향력 강화 |
| Windows I/O | 일반 파일 I/O 중심 | DirectStorage 도입 논의 포함 |
| 로드맵 체감 | 계획·예고 중심 | 실제 적용·마이그레이션 이슈 증가 가능성 |
이제 지원(=LTS/EOS) 표기 문제와 문서 불일치 이야기를 짚고 넘어갈게요. 다음 섹션에서 바로 연결됩니다.
지원(LTS) 표기, 문서끼리 미묘하게 다르다
“LTS는 그냥 오래 지원해주겠지”라는 생각은 위험할 수 있어요.
실제로 Unity 6 관련 문서들 사이에서 지원 표기 방식이나 기간이 다르게 보이는 구간이 있어서, 프로젝트 일정이 걸려 있다면 Support 페이지의 EOS/EOL 표를 최종 기준으로 삼는 편이 안전하거든요.
⚠️ 주의
지원 종료 시점을 ‘카더라’ 기준으로 판단하면 위험해요. 프로젝트 일정이 걸려 있으면 Support 페이지를 직접 확인하세요.
지원 표기 이야기를 마무리했으니, 다음은 6.4부터 6.7까지 어떤 축이 바뀌는지 정리해 드릴게요.
6.4에서 6.7까지, ‘바뀌는 축’만 뽑으면
앞에서 말한 대로 6.4는 '문턱을 넘은' 릴리스로 받아들여지는 분위기예요.
그다음 버전들은 기능 추가보다도 표준화와 호환성 정리가 더 큰 이슈로 자리 잡는 느낌이에요.
Photo by Sean Do on Unsplash
6.4 핵심: ECS 영향력 강화 + 플랫폼 툴링
6.4 관련 요약에서 반복되는 포인트는 ECS 관련 의존성 정리와 플랫폼별 툴링 강화예요.
여기서 중요한 점은 “지금 당장 모든 게임을 ECS로 바꿔라”가 아니라, 엔진의 기본 구조가 ECS 친화적으로 정렬되는 쪽으로 이동한다는 점이에요.
💡 팁 지금 ECS를 쓰지 않더라도, 패키지 의존성 그래프를 한 번 뽑아 두면 좋아요. 6.4에서 의존성이 바뀌면 원인 찾는 시간이 크게 줄거든요.
Windows 쪽에서 DirectStorage 언급은, 대용량 에셋 스트리밍 설계에 영향을 줄 가능성이 큽니다. 이어서 URP·HDRP 쪽 전략을 보면 이 흐름이 더 선명해져요.
6.5·6.6: ‘URP 우선’ 흐름이 더 뚜렷해진다
여기서 흔한 오해 하나는 “URP는 그냥 라이트 버전”이라는 인식이에요.
로드맵 문맥에서는 URP가 우선 투자 경로로 자주 언급됩니다. 즉, 신규 기능·수정이 URP에 먼저 모이는 경향이 있다는 뜻이죠.
Built‑In은 6.5 이후 deprecated 표기가 예고된다는 언급이 있는데, 즉시 삭제되는 식의 급작스러운 변화는 아니고 점진적 전환 쪽으로 읽는 편이 안전합니다.
6.7: CoreCLR 전환과 호환성 재정의
6.7에서 가장 민감한 축은 스크립팅 런타임(런타임 엔진)과 직렬화 쪽이에요.
공식 포럼과 로드맵 요약에선 CoreCLR 전환이 언급되면서, 그에 따른 호환성(플러그인·직렬화) 이슈가 중심이 된다고 설명하고 있어요.
로드맵 체감 포인트
6.7: breaking changes 범위는 런타임·직렬화 쪽
따라서 업데이트는 ‘단순 패치’가 아니라 호환성 점검 프로젝트로 보는 편이 편하거든요.
버전별 핵심 항목을 표로 정리하면, 회의할 때 훨씬 빠르게 판단할 수 있어요.
| 기능/이슈 | 6.4(반영) | 6.5~6.6(흐름) | 6.7(예상 영향) |
|---|---|---|---|
| ECS | 엔진 차원 영향력 증가 | 표준 경로 강화 | 호환성·패키지 정리 영향 |
| Windows I/O | DirectStorage 도입 논의 | 툴체인 최적화 흐름 | 플랫폼별 검증 중요도 증가 |
| Render Pipeline | URP 쪽 투자 강화 | Built‑In 전환 경고 증가 | URP 우선 전제가 강해짐 |
| 스크립팅 런타임 | 현행 체계 유지 | 전환 준비 공지 확대 | CoreCLR 전환 영향권 |
| 직렬화/플러그인 | 대체로 현상 유지 | 권고·가이드 증가 | breaking changes 영향권 |
표를 보고 나면 “우리 프로젝트는 어디에 걸리는가?”가 훨씬 현실적으로 보이죠. 다음은 렌더 파이프라인 전략이에요.
출처는 글 맨 끝에 모아뒀습니다.
URP·HDRP·Built‑In, 이제 선택이 아니라 ‘전략’
버전 기능을 파악했다면, 이제는 “어느 레일로 달릴 것인가”를 전략적으로 결정해야 해요.
여러 문서에서 반복되는 어휘는 URP 우선 쪽이 많습니다. 즉, URP는 유니티가 먼저 길을 닦는 곳이라는 뜻이에요.
Photo by Fotis Fotopoulos on Unsplash
URP 우선화: ‘도달 범위’가 핵심
URP를 단순히 ‘가벼운 파이프라인’으로만 보면 반이 맞아요.
공식 흐름상 URP는 멀티 플랫폼 기본값에 가까운 포지션이라, 팀 규모가 작을수록 운영이 편한 경우가 많아요.
📌 실무 번역
URP 우선화는 “URP가 최고”라는 말이 아니라, 유니티가 먼저 기능을 모으는 축이 URP라는 의미에요. 신규 기능·수정이 먼저 모입니다.
HDRP는 유지되지만 투자 우선순위는 다를 수 있어요
HDRP는 당장 없어지지 않고 유지된다고 안내되는 경우가 많아요.
다만 “투자 우선순위”는 URP에 더 실리는 흐름이라, HDRP 기반 프로젝트는 업데이트 속도와 유지 비용을 면밀히 가늠해야 해요.
Built‑In: deprecated 경고, 준비는 필요해요
“deprecated = 당장 삭제”로 공포를 느낄 필요는 없어요. 문맥상 점진적 전환이란 표시가 더 맞습니다.
다만 Built‑In 기반 프로젝트는 전환 시 셰이더·포스트프로세스 관련 작업량이 커질 수 있으니 미리 목록화해 두는 게 좋겠죠.
| 항목 | URP | HDRP | Built‑In |
|---|---|---|---|
| 공식 방향(요약) | 우선 투자 | 유지 | 점진적 전환 권고 |
| 타깃 | 멀티 플랫폼 | 하이엔드 | 레거시 자산 |
| 전환 난이도 | 기준선 역할 | 설정 복잡 | 전환 시 작업량 커짐 |
렌더 파이프라인 전략을 정리했으니, 이제 6.7에서 특히 민감한 CoreCLR·직렬화 문제로 넘어가 보겠습니다.
관련 출처는 글 끝쪽에 모았습니다.
CoreCLR 전환, 진짜 영향은 ‘직렬화’에서 터진다
겉으로는 “런타임 바뀐다”인데, 실무에서 가장 골치 아픈 건 대개 직렬화와 플러그인 호환이에요.
런타임 전환은 코드가 돌아가는 엔진 내부를 바꾸는 문제라, 직렬화 포맷·리플렉션 의존 코드가 영향을 크게 받을 수 있어요.
CoreCLR이 뭐길래: 쉽게 말해 ‘엔진 속 언어 엔진’
CoreCLR은 관리형 런타임 전환 얘기예요. 쉽게 말하면 C# 코드를 실행하는 엔진(런타임)이 바뀌는 거죠.
공식 포럼 업데이트에서는 CoreCLR 쪽 스크립팅·직렬화 관련 공지가 올라왔고, 일부 실험적 플레이어 언급이 보입니다. 다만 범위와 시점은 공식 문서를 기준으로 확인하세요.
변화의 중심
CoreCLR/Serialization 관련 공지(요약)
따라서 6.7은 기능 추가보다 호환성 재정의가 핵심 이벤트로 보이는 편이에요.
breaking changes는 ‘몇 줄 수정’이 아니라 ‘검증 방식의 전환’
사람들이 흔히 “breaking changes면 에러 몇 개 고치면 끝”이라고 생각하잖아요.
하지만 이번 예고 범위는 프로젝트에 따라 빌드·검증 파이프라인 자체를 다시 설계해야 할 수도 있다는 수준이에요. 그러니 테스트 전략을 먼저 세우는 편이 안전합니다.
💡 팁 6.7 대비는 “코드 수정”보다 회귀 테스트 항목 정의를 먼저 하세요. 어떤 씬·플랫폼이 깨지면 치명적인지 목록화하면 대응 속도가 달라집니다.
실무에서 많이 걸리는 포인트 3개
✅ CoreCLR 대비 체크리스트
- 네이티브 플러그인 — 플랫폼별 로딩/ABI 이슈 조기 확인
- 직렬화 의존 — 커스텀 직렬화·리플렉션 사용 코드 목록화
- 에셋 파이프라인 — 임포트 설정·빌드 스트립 규칙 문서화
이 체크리스트를 미리 정리해 두면, 6.7 도입 전에 우리 리스크가 무엇인지 잊지 않게 됩니다. 이어서 마이그레이션 실무 순서를 정리할게요.
관련 출처는 마지막에 정리해 두었습니다.
마이그레이션, ‘업데이트 버튼’ 누르기 전에 해야 할 일
여기부터는 진짜 실무자 구간이에요. 같은 6.4 업그레이드라도 프로젝트 특성에 따라 결과가 확 달라집니다.
Photo by Annie Spratt on Unsplash
리스크를 ‘높음/중간/낮음’으로 먼저 칠하자
업그레이드가 어려운 이유는 일이 많아서가 아니라 “어디가 터질지 몰라서”예요.
그래서 먼저 리스크를 색칠해두면 일정이 더 현실적으로 잡힙니다. 이게 바로 프로젝트 관리의 기본이거든요.
📌 리스크 빠른 분류
URP 전환 필요 + 커스텀 셰이더 다수 = 높음. 패키지 의존이 낮고 표준 기능 위주 = 낮음. 네이티브 플러그인 다수/멀티플랫폼 = 중간~높음.
Before/After로 ‘해야 할 일’을 못 박아두기
마이그레이션을 ‘업무’로 바꾸는 장치가 바로 이 표예요.
회의에서 이 표를 체크하면 감정적 논쟁 대신 작업으로 전환됩니다.
| 항목 | 마이그레이션 전 | 마이그레이션 후 |
|---|---|---|
| 백업/롤백 | 태그/브랜치 기준점 생성 | 즉시 롤백 가능한 릴리스 브랜치 유지 |
| 패키지 의존성 | 패키지 버전 목록화 | 호환 버전 고정 + 업데이트 창구 단일화 |
| 렌더 파이프라인 | Built‑In/URP/HDRP 확정 | URP 전환 시 셰이더·후처리 작업량 산정 |
| CI/자동화 | 수동 빌드 위주 | 빌드/테스트 자동화로 회귀 버그 조기 발견 |
| 플랫폼 검증 | 주력 플랫폼만 확인 | 최소 2개 플랫폼 스모크 테스트 고정 |
특히 CI/자동화는 중요해요. 큰 런타임 변화는 사람 눈으로 놓치기 쉬운 케이스가 늘어나거든요.
권장 순서: 테스트 → 스테이징 → 배포 (중간에 ‘중지 버튼’ 포함)
절차는 단순할수록 잘 지켜집니다. 아래 순서만 지켜도 한밤중 롤백 확률을 꽤 줄일 수 있어요.
- 테스트 브랜치에서 6.4 업그레이드 후 에디터/플레이 모드 스모크 테스트
- 스테이징에서 CI 자동화 적용, 주요 씬·로딩·세이브 같은 핵심 플로우 회귀 테스트
- 배포는 릴리스 후보(RC)로 묶어 진행하고, 문제 시 롤백 기준을 미리 문서화
💡 팁 “업그레이드 성공” 기준을 ‘에러 0개’로 잡지 말고, 핵심 KPI 플로우 통과로 잡아보세요. 로그인·전투·저장 같은 핵심만 통과해도 판단이 빨라집니다.
여기까지가 ‘안전하게 올리는 법’이라면, 다음은 6.4로 올렸을 때 얻을 수 있는 이득과 비용 쪽을 같이 정리할게요.
관련 출처는 문장 맨 끝의 참고 링크에서 확인하세요.
성능·비용, 결국 남는 건 ‘운영 체력’이더라
업그레이드 절차를 잡았다면, 이제는 “6.4로 가면 실제로 뭐가 남나”를 구체적으로 따져볼 차례예요.
DirectStorage: 포인트는 ‘로딩’이 아니라 ‘스트리밍 설계’
DirectStorage 언급이 중요한 이유는 대규모 에셋를 다루는 상황에서 플레이 중 스트리밍 병목을 줄이는 데 도움이 되기 때문이에요.
하지만 DirectStorage만 켠다고 문제가 다 해결되진 않아요. 먼저 병목 위치부터 정확히 구분하는 작업이 필요합니다.
- 병목 위치 고정 — Unity Profiler/Frame Debugger로 CPU인지 I/O인지 먼저 가르세요
- 에셋 번들·어드레서블 전략 — 묶는 단위가 크면 I/O 최적화가 체감되지 않을 수도 있어요
- Windows 타깃이면 드라이버·OS 요구조건을 미리 체크해두는 편이 안전해요
ECS: ‘전면 도입’보다 ‘핫스팟부터’가 이득이에요
“ECS 들어왔으니 다 바꿔야 하나요?”라는 질문이 가장 많아요.
현실적으로는 프레임을 잡아먹는 핫스팟부터 바꾸는 팀이 속도와 안정성을 모두 잡습니다.
| 구분 | 전통 GameObject 중심 | ECS/데이터 지향(핫스팟) |
|---|---|---|
| 도입 난이도 | 낮음 | 중간~높음 |
| 기대 효과 | 개발 속도 중심 | 특정 구간 성능 개선에 유리 |
| 권장 전략 | 기존 유지 | 핫스팟만 부분 적용 |
비용 정책(요약): 인상과 저장공간 변화가 함께 언급됐다
일부 공지에서는 Pro/Enterprise 요금제 인상과 저장공간 확대가 언급됐습니다. 다만 정확한 숫자·시점은 공지별로 다를 수 있으니 공식 공지를 기준으로 확인하세요.
예비 검토 차원에서 보면 저장공간 확대는 단기적으로 외부 스토리지 비용 부담을 줄여줄 수 있지만, 좌석 수·장기 계약에 따른 비용 변화는 별도로 계산해야 해요.
| 항목 | 변경 전(요약) | 변경 후(요약) |
|---|---|---|
| 요금제 | 현행 | 일부 공지에서 인상 언급 |
| 무료 저장공간 | 현행 공지 기준 | 확대 언급(공식 문서 확인 권장) |
| 이그레스 | 정책별 상이 | 일부 공지에서 면제 언급(기간 확인 필요) |
결국 계산은 팀별로 달라집니다. 단기 완충책이 되는 경우도, 장기 계약 영향이 더 큰 경우도 있으니 케이스 바이 케이스로 봐야 해요.
다음은 실제로 자주 묻는 질문들을 모아 짧게 답해 드릴게요.
자주 묻는 질문(FAQ)
댓글에서 자주 싸우는(농담) 지점들을 골라서 답해볼게요. 답은 짧고, 공식 확인 링크는 맨 끝에 정리했습니다.
Unity 6.4 공식 릴리스 시점은 언제로 보면 되나요?
포럼 공지와 릴리스 페이지에 “available” 표기가 올라온 것으로 알려져 있습니다. 다만 정확한 배포 시점과 범위는 Unity 릴리스 페이지의 공지 날짜를 내부 기준으로 삼으세요.
유니티 6.4에서 제일 큰 변화 하나만 꼽으면?
ECS 관련 영향력 강화이 가장 눈에 띕니다. 엔진의 기본 경로가 데이터 지향 구조 쪽으로 정렬되는 효과가 크거든요.
6.7 breaking changes, 누가 가장 큰 영향을 받나요?
네이티브 플러그인 다수 보유팀과, 커스텀 직렬화·리플렉션을 깊게 쓰는 팀이 가장 큰 영향을 받을 가능성이 큽니다. 표준 기능 위주면 테스트로 흡수되는 경우가 많아요.
CoreCLR 전환은 무조건 6.7에서 바로 써야 하나요?
공식 문맥상 실험적 플레이어로 먼저 도입되는 흐름이 언급되는 경우가 있어요. 즉시 전면 도입보다는 스테이징 단계에서 호환성 측정을 먼저 해보는 편이 안전합니다.
URP 전환 시 가장 먼저 확인할 것?
가장 먼저는 커스텀 셰이더 목록입니다. 그다음 포스트프로세스와 라이트/라이트맵 설정을 점검하면 전환 작업량을 예측하기 훨씬 쉬워져요.
요금 인상·저장공간 확대, 저는 어떤 쪽이 이득인가요?
좌석 비용이 큰 팀은 인상 영향이 크고, 외부 스토리지를 많이 쓰던 팀은 저장공간 확대가 단기 완충 역할을 할 수 있어요. 정확한 계산은 계약 조건과 사용 패턴을 대입해 보세요.
LTS 지원 종료(EOS/EOL)는 어디에서 최종 확인하나요?
Unity Support의 Unity 6 지원 페이지에 버전별 표가 있으니, 최종 의사결정은 그 페이지의 표를 기준으로 삼으세요.
FAQ를 정리하면 선택지는 대체로 셋으로 좁혀집니다: “지금 6.4로 간다 / 6.7을 대비해 관찰한다 / 비용까지 같이 재정리한다”. 다음은 상황별 액션 플랜입니다.
정리 및 권장 액션 플랜 — 한눈에
선택을 딱 정리하면, 지금 1차 결정은 유니티 6.4를 기준 버전으로 삼을지예요.
포럼과 릴리스 안내에서 6.4 사용 가능 안내가 나온 것으로 전해지지만, CoreCLR/직렬화 쪽 공지까지 감안하면 흐름은 분명해졌습니다. 그래서 역할별 권장을 드려요.
인디·1인 개발자라면: 6.4로 올리되 패키지 버전 고정과 핵심 씬만 스모크 테스트하는 방식이 실용적이에요.
중소 스튜디오라면: 6.4로 올리고 6.5~6.6 흐름을 보면서 6.7 대비를 병행하세요. CI 자동화를 먼저 도입해 회귀 비용을 줄이는 편이 이득이에요.
엔터프라이즈라면: 요금제·저장공간 변화와 계약을 함께 봐야 합니다. 보안·아티팩트 정책까지 한 번에 정리하세요.
지금 당장 해야 할 3가지는 이거예요: 백업, CI 테스트, Support(EOS/EOL) 확인.
공식 문서는 릴리스 페이지·로드맵·지원 페이지에서 시작하면 가장 확실합니다. 다음은 참고 링크입니다.
참고 링크: Unity Releases (Unity 6), Unity Roadmap, Unity Support (Unity 6 지원), Unity Pricing Updates, Unity Discussions(6.4/6.7/CoreCLR 관련)
블로그의 정보
진우의 혼잣말하는 블로그
VR하는소년