SideFX의 Main Changelog를 보면 2026년 7월 2일 Houdini 21.0.765 항목에 아주 짧은 문장이 들어왔습니다. Added support for Unity 6.5. 기능 소개처럼 크게 포장된 뉴스는 아니지만, Unity 안에서 Houdini Digital Asset을 쓰는 팀에게는 꽤 실질적인 신호입니다. 레벨 생성기, 지형 툴, 프롭 배치기, 머티리얼 변형 툴, VFX 보조 데이터 생성기를 HDA로 굴리는 팀이라면 이제 Unity 6.5 업그레이드를 Houdini Engine까지 포함해서 검토할 수 있기 때문입니다.
Unity 6.5도 단순한 번호 변경은 아닙니다. Unity Manual은 Unity 6.5, 버전 6000.5가 2D, 애니메이션, 에디터 워크플로, 그래픽, 최적화, 패키지 관리, 플랫폼, UI, XR 등 여러 영역의 기능과 개선을 담고 있다고 정리합니다. Unity Discussions의 2026년 6월 15일 릴리스 글도 EntityID 전환, Editor Lifecycle API, Profiler AI Assistant, Project Auditor 업데이트, 2D Profiler와 RenderSprite API 같은 변화를 함께 소개했습니다.
그래서 이 글은 “Unity 6.5로 바로 올리자”는 이야기가 아닙니다. 오히려 반대에 가깝습니다. 호환성 문구를 봤을 때 어디까지 믿고, 어디부터 직접 확인해야 하는지 정리하는 글입니다. 게임 개발자, 테크니컬 아티스트, 레벨 디자이너, VFX 아티스트, 툴 프로그래머가 같은 업그레이드 브랜치를 볼 때 필요한 검증 레인을 나눠 보겠습니다.
1. 이번 뉴스는 새 기능보다 동시 업그레이드의 출발점입니다
Houdini Engine for Unity 지원 항목은 화려하지 않습니다. 새 노드가 생겼다거나, 새 렌더링 기능이 열렸다거나, Unity 안에서 완전히 다른 제작 방식이 생겼다는 발표도 아닙니다. 하지만 연동 플러그인에서 “새 Unity 버전 지원”은 기능 발표보다 더 현실적인 뉴스일 때가 많습니다. 팀이 엔진 업그레이드와 DCC 연동 업그레이드를 같은 일정 안에서 테스트할 수 있다는 뜻이기 때문입니다.
프로시저럴 툴은 보통 엔진 안팎의 경계에 걸쳐 있습니다. Houdini에서는 노드 네트워크로 규칙을 만들고, Unity에서는 HDA 파라미터를 조절하고, 결과물은 메시, 프리팹, terrain, 머티리얼, collider, 인스턴스, VFX용 마스크나 스폰 표면으로 들어갑니다. 겉으로는 “Unity 에디터에서 버튼 하나 누르는 툴”처럼 보여도, 실제로는 Houdini 설치, Houdini Engine 세션, Unity 플러그인, 에셋 데이터베이스, 소스 관리, 빌드 규칙이 함께 움직입니다.
이 구조에서는 Unity 프로젝트가 켜지는지 확인하는 것만으로 충분하지 않습니다. HDA가 다시 cook되는지, 입력 메시와 spline이 제대로 넘어가는지, 파라미터 기본값이 유지되는지, 출력 hierarchy와 머티리얼 연결이 바뀌지 않는지, 소스 관리 diff가 감당 가능한지 확인해야 합니다. 특히 테크니컬 아트 툴은 한 번 깨지면 “툴 제작자만 불편한 문제”로 끝나지 않습니다. 디자이너의 반복 횟수, 아티스트의 표현 선택, QA의 재현 속도, 결국 플레이어가 보는 레벨 밀도까지 영향을 받습니다.
이 뉴스의 가치는 바로 여기에 있습니다. SideFX changelog 한 줄은 “이제 최신 Unity와 Houdini Engine 조합을 검증할 시작점이 생겼다”는 신호로 읽는 편이 좋습니다. 단, 시작점과 승인점은 다릅니다. 프로덕션 프로젝트라면 이 문구 하나로 메인 브랜치를 올리는 것이 아니라, 테스트 브랜치와 대표 검증 씬을 만들어 확인해야 합니다.
2. 첫 번째 레인: 우리 프로젝트가 HDA에 얼마나 기대는지 분류합니다
업그레이드 테스트를 시작하기 전에 먼저 해야 할 일은 Unity 6.5 설치가 아닙니다. 현재 프로젝트가 Houdini Engine에 얼마나 기대고 있는지 분류해야 합니다. 많은 팀이 “우리는 Houdini를 조금만 쓴다”고 말하지만, 그 조금이 레벨 제작의 핵심일 수도 있고, 출시 직전 베이킹 단계의 핵심일 수도 있습니다.
가장 낮은 리스크는 결과물만 쓰는 프로젝트입니다. Houdini에서 만든 메시나 프리팹, terrain 결과를 Unity에 가져온 뒤 프로젝트 안에서는 더 이상 HDA cook을 하지 않는 방식입니다. 이 경우 Unity 6.5와 Houdini Engine 조합은 당장 런타임을 흔들기보다, 다음 제작 사이클에서 같은 원본으로 같은 결과를 만들 수 있는지 확인하는 문제에 가깝습니다.
두 번째는 에디터 단계에서 HDA를 계속 조절하는 프로젝트입니다. 레벨 디자이너가 Unity 안에서 도로, 벽, 방, 장애물, 식생, 던전 구조, spline 기반 프롭을 조정하고, Houdini Engine이 계속 결과를 cook하는 방식입니다. 이 경우에는 menu가 뜨는지, 세션이 열리는지, 입력과 출력이 유지되는지, 쿡 시간이 이전과 비슷한지, 디자이너가 같은 감각으로 작업할 수 있는지까지 확인해야 합니다.
세 번째는 커스텀 C# 에디터 툴이나 자동화가 붙은 프로젝트입니다. HDA 기본 UI만 쓰지 않고 custom inspector, batch cook, 검증 스크립트, CI 베이킹, 소스 관리 hook이 연결되어 있다면 더 조심해야 합니다. Unity의 Editor Lifecycle API, EntityID 전환, Android Gradle/AGP 업데이트, Render Graph 관련 변경처럼 Unity 6.5 주변 변화는 직접 Houdini 기능이 아니더라도 프로젝트 툴 코드의 가정을 흔들 수 있습니다.
이 분류표에는 HDA 이름, 담당자, 사용 직군, 쿡 빈도, 출력 유형, 빌드 포함 여부, 실패 시 영향도를 적어 두는 것이 좋습니다. 테크니컬 아티스트가 중요하다고 보는 지점과 레벨 디자이너가 실제로 고통받는 지점은 다를 수 있습니다. VFX 아티스트에게는 충돌 표면이나 마스크 데이터가 더 중요할 수도 있습니다. 검증 책임을 실제 사용자 기준으로 나누면 “내 PC에서는 열립니다” 수준의 확인에서 벗어날 수 있습니다.
3. 두 번째 레인: Unity 6.5 변화가 HDA 출력과 만나는 지점을 봅니다
Houdini Engine이 Unity 6.5를 지원한다고 해서 출력물이 그대로라는 뜻은 아닙니다. Unity 6.5는 그래픽, 에디터 워크플로, 최적화, 패키지, 플랫폼을 넓게 건드립니다. HDA가 만든 결과물도 결국 Unity의 씬, 머티리얼, 프리팹, 에셋 데이터베이스 위에 놓이기 때문에 접점이 생깁니다.
먼저 머티리얼과 shader 연결을 봐야 합니다. Houdini Engine for Unity는 HDA 결과를 Unity 쪽 메시와 머티리얼로 내보내는 흐름을 제공합니다. 프로젝트가 URP, Shader Graph, 커스텀 shader, vertex color, terrain material, decal을 섞어 쓰고 있다면 unity_material 같은 attribute convention이나 경로 매핑이 유지되는지 확인해야 합니다. 화면이 비슷해 보여도 머티리얼 슬롯 순서나 fallback shader가 바뀌면 나중에 VFX와 조명 작업에서 문제가 커질 수 있습니다.
두 번째는 hierarchy와 프리팹 reference입니다. 단순 메시 하나를 내보내는 HDA라면 리스크가 작지만, modular building, scatter, terrain patch, destruction proxy처럼 child object가 많은 툴은 다릅니다. 출력 오브젝트 이름, transform, layer, tag, static flag, collider, LOD group, prefab override가 유지되는지 비교해야 합니다. 사람이 눈으로 훑는 것보다 작은 validation script가 더 믿을 만합니다.
세 번째는 에디터 반응성입니다. Unity 6.5 릴리스 글은 Profiler AI Assistant와 Project Auditor 업데이트, performance metric signals를 언급합니다. 이런 도구는 런타임 최적화뿐 아니라 업그레이드 검증에도 쓸 수 있습니다. HDA cook이 느려지거나, 에셋 import가 반복되거나, 씬 refresh가 길어지면 디자이너는 자연스럽게 실험 횟수를 줄입니다. 결과물이 같아도 interaction이 무거워지면 제작 속도는 떨어집니다.
좋은 방법은 골든 씬을 만드는 것입니다. 실제 대형 프로덕션 씬을 바로 여는 대신, 팀이 자주 쓰는 HDA를 대표하는 작은 검증 씬을 따로 둡니다. 기존 Unity 버전에서 screenshot, hierarchy export, 파일 diff, cook time, 에디터 체감 메모를 남기고, Unity 6.5와 새 Houdini Engine 조합에서 같은 입력으로 다시 cook합니다. 비교 기준은 “모든 파일 diff가 없어야 한다”가 아니라 “플레이와 제작 의도에 영향을 주는 차이가 설명되어야 한다”에 가깝습니다.
4. 세 번째 레인: 디자이너와 아티스트의 파라미터 경험을 확인합니다
프로시저럴 툴은 결과물만으로 평가하면 절반만 보는 것입니다. 실제 사용자는 HDA 내부 노드를 보지 않습니다. Unity 에디터 안에서 파라미터 이름, slider 범위, folder 구조, preset, button, handle, input slot을 만집니다. SideFX의 Unity 플러그인 페이지도 HDA를 Unity 에디터에 불러와 procedural control을 아티스트에게 제공하고, 파라미터 변경 때 Houdini Engine이 cook해 Unity로 결과를 publish하는 흐름을 설명합니다.
업그레이드 테스트에서도 이 사용자 경험을 봐야 합니다. 툴 제작자 입장에서는 결과가 정상 출력되면 성공처럼 보일 수 있습니다. 하지만 레벨 디자이너가 매일 쓰는 handle이 어색해졌거나, default 값이 달라졌거나, folder가 한 단계 더 깊어졌거나, 쿡 결과를 보기 위해 눌러야 하는 버튼이 늘어났다면 제작 속도는 떨어집니다. 자동 테스트가 잡지 못하는 영역입니다.
여기에는 짧은 작업 테스트가 효과적입니다. 예를 들어 레벨 디자이너에게 “골목 폭을 줄이고, 장애물 밀도를 낮추고, collider 출력을 다시 만들기” 같은 10분짜리 task를 줍니다. 기존 버전과 Unity 6.5 테스트 브랜치에서 각각 수행하게 하고, 걸린 시간보다 헷갈린 지점과 불안했던 지점을 기록합니다. VFX 아티스트에게는 collision proxy, decal guide, spawn surface, material mask 같은 보조 데이터를 다시 뽑게 해 보면 좋습니다.
피드백도 구체적으로 쪼개야 합니다. “느려졌다”는 말은 cook 시간이 길어진 것인지, 씬 갱신 동안 에디터가 멈춘 것인지, 결과를 확인하기 위한 클릭 수가 늘어난 것인지 다릅니다. “헷갈린다”는 말도 파라미터 이름 문제인지, 폴더 구조 문제인지, 로그 메시지 문제인지, 기본값 문제인지 분리해야 합니다. 이렇게 해야 툴 제작자가 실제로 고칠 수 있고, 업그레이드 승인 여부도 감이 아니라 증거 위에서 결정할 수 있습니다.
5. 네 번째 레인: 빌드에는 무엇을 넣고 에디터에는 무엇을 남길지 정합니다
Houdini Engine을 Unity 프로젝트에 붙였다고 해서 런타임 빌드에 Houdini Engine이 항상 필요한 것은 아닙니다. 많은 게임에서는 에디터에서 HDA를 cook하고, 결과 메시와 프리팹, terrain, texture, 머티리얼을 베이크해서 빌드에 넣습니다. SideFX 플러그인 페이지도 게임 content는 publish 때 baked out된다고 설명합니다. 이 구분은 Unity 6.5 업그레이드 때 특히 중요합니다.
먼저 generated output의 ownership을 정해야 합니다. HDA가 만든 결과를 소스 관리에 커밋할 것인지, CI에서 재생성할 것인지, artist workstation에서 생성한 뒤 review할 것인지 결정해야 합니다. 커밋 방식은 리뷰와 롤백이 쉽지만 저장소가 무거워질 수 있습니다. CI 재생성은 깔끔하지만 Houdini 설치, 라이선스, 플러그인 버전, headless cook, 결정적인 출력 관리가 필요합니다.
두 번째는 version pinning입니다. 이번 지원 항목은 SideFX changelog 기준 Houdini 21.0.765에 표시되어 있습니다. 팀이 이 조합을 검토한다면 Unity 6.5 버전, Houdini 빌드, Houdini Engine 플러그인 상태, OS, 패키지 lock, 라이선스 모드를 문서에 적어야 합니다. “최신 Houdini”라고만 남기면 나중에 결과가 달라졌을 때 원인을 찾기 어렵습니다.
세 번째는 실패 정책입니다. HDA cook이 실패했을 때 빌드를 멈출 것인지, 마지막 성공 베이크 결과를 쓸 것인지, 경고만 남길 것인지 정해야 합니다. 단순 장식 프롭이라면 경고로 넘어갈 수 있지만, 네비게이션, collision, 퀘스트 진행, 보스전 지형, VFX spawn mask와 연결된 출력이라면 빌드를 멈추는 편이 맞습니다. 플레이어는 내부 툴을 보지 않지만, 보이지 않는 벽, 어긋난 충돌, 누락된 hit effect는 바로 느낍니다.
6. 다섯 번째 레인: 업그레이드 기록을 포트폴리오와 교육 자료로 남깁니다
이런 호환성 뉴스는 처음 보면 건조합니다. 하지만 테크니컬 아티스트와 게임 개발 아티스트에게는 좋은 학습 소재입니다. “Houdini로 멋진 레벨 생성기를 만들었다”보다 “그 생성기를 Unity 6.5로 올리며 어떤 항목을 검증했고, 어디서 차이가 났고, 어떻게 팀 기준을 정했는가”가 더 현장형 포트폴리오가 됩니다.
포트폴리오로 남길 때는 기존 Unity 버전의 결과와 Unity 6.5 브랜치의 결과를 나란히 보여주는 편이 좋습니다. 머티리얼 매핑, 프리팹 hierarchy, 쿡 시간, source control diff, 디자이너 task, VFX support data, 빌드 포함 여부를 짧게 표시하면 단순 툴 데모보다 훨씬 설득력이 있습니다. 채용 담당자나 팀 리드는 이 사람이 결과물만 만드는 사람이 아니라 툴 owner로 생각한다는 것을 볼 수 있습니다.
교육 콘텐츠로도 구조가 좋습니다. 첫 글은 “왜 HDA도 엔진 업그레이드 테스트 대상인가”를 설명하고, 다음 글은 골든 씬 만들기, 그 다음은 자동 비교 script와 사용자 task test, 마지막은 빌드 pipeline과 소스 관리 정책으로 이어갈 수 있습니다. Unity에 한정된 이야기도 아닙니다. Unreal의 Houdini Engine, PCG, Editor Utility, Niagara 보조 데이터, 자체 엔진의 DCC 생성 툴도 비슷한 문제를 만납니다.
단, 과장하면 안 됩니다. SideFX changelog는 Unity 6.5 지원을 말했을 뿐, 모든 프로젝트의 안전한 업그레이드를 보장하지 않습니다. Unity 6.5는 Supported release이지만, 출시 직전 프로젝트라면 LTS 유지가 더 나을 수도 있습니다. 결론은 “올리자”가 아니라 “검증할 수 있게 만들자”입니다.
7. 팀에서 바로 쓸 수 있는 짧은 검증 순서
정리하면 다음 순서가 현실적입니다.
1. 대표 HDA를 5개 안팎으로 고릅니다. 레벨 구조, scatter, terrain, 머티리얼 variation, VFX support data처럼 출력 유형이 다른 것들을 섞습니다.
2. 기존 프로덕션 Unity 버전에서 골든 씬을 만들고 screenshot, hierarchy, 파일 diff, cook time, 사용자 메모를 저장합니다.
3. Unity 6.5 테스트 브랜치를 따로 만들고 Houdini 21.0.765 또는 팀이 검토할 정확한 빌드를 기록합니다.
4. 플러그인 스모크 테스트를 합니다. Unity가 열리고, Houdini Engine menu가 보이고, 세션이 시작되고, 아주 작은 HDA가 cook되는지 확인합니다.
5. 골든 씬을 다시 cook하고 머티리얼, 프리팹, collider, layer, tag, 생성 에셋 경로, source control diff를 비교합니다.
6. 실제 사용자 task를 돌립니다. 디자이너와 아티스트가 같은 툴을 만져 보고 헷갈린 지점을 남깁니다.
7. 빌드 boundary를 확인합니다. 빌드에는 베이크 결과만 들어가는지, 에디터 전용 플러그인이나 불필요한 생성물이 섞이지 않는지 봅니다.
이 순서가 길어 보일 수 있지만, 한 번 만들어 두면 다음 Unity 버전, 다음 Houdini 빌드, 다음 render pipeline 전환 때 계속 쓸 수 있습니다. 좋은 pipeline은 빠르게 만드는 능력만이 아니라, 다음 업데이트에서도 같은 의도로 다시 만들 수 있는 능력입니다.
Houdini Engine이 Unity 6.5를 지원할 때: 프로시저럴 툴 체인 업그레이드는 작업 메모
SideFX의 2026년 7월 2일 Houdini 21.0.765 changelog에 들어온 Unity 6.5 지원은 작은 문장입니다. 하지만 Houdini Engine을 Unity 제작 파이프라인에 붙여 쓰는 팀에게는 업그레이드 검증을 시작할 수 있는 명확한 신호입니다. Unity 6.5의 에디터, 그래픽, 최적화, 프로젝트 감사 도구 변화까지 함께 보면, 이 주제는 단순 플러그인 호환성이 아니라 툴 체인 유지보수 이야기로 바뀝니다.
게임 제작에서 프로시저럴 툴은 작업을 빠르게 만드는 동시에, 실패했을 때 영향 범위가 넓은 시스템입니다. 그래서 호환성 뉴스는 “잘 되겠지”로 넘기기보다 “어디까지 확인하면 팀이 믿고 쓸 수 있을까”로 읽는 편이 좋습니다. HDA 의존도 분류, 골든 씬, 출력 비교, 사용자 task, 빌드 boundary 문서화까지 해두면 이번 업데이트뿐 아니라 다음 업데이트에서도 팀의 판단 속도가 빨라집니다.
작은 changelog 한 줄이 좋은 제작 습관을 점검하게 만든다면, 그 자체로 충분히 볼 만한 뉴스입니다.
참고 출처
- SideFX Main Changelog: https://www.sidefx.com/changelog/
- Unity Manual, New in Unity 6.5: https://docs.unity3d.com/6000.5/Documentation/Manual/WhatsNewUnity65.html
- Unity Discussions, Unity 6.5 is now available: https://discussions.unity.com/t/unity-6-5-is-now-available/1723176
- Unity Discussions, Planned breaking changes in Unity 6.5: https://discussions.unity.com/t/planned-breaking-changes-in-unity-6-5-updated-2026-03-27/1694205
- SideFX Houdini Engine for Unity documentation: https://www.sidefx.com/docs/houdini/unity/
- SideFX Unity Plug-In page: https://www.sidefx.com/products/houdini-engine/plug-ins/unity-plug-in/