Skip to content

Desuq Cafe

홍보가 아니라 실측

성능, 근거와 함께

이것은 Weft 솔버의, 측정하고 하드웨어를 공개한 수치이며 마케팅 주장이 아닙니다. 모든 값은 특정 머신 한 대에서 출시 코드를 상대로 실제 Stopwatch를 돌려 얻은 것이며, 그 내용을 여기에 그대로 실었습니다. 저희가 조사한 범위에서 이처럼 하드웨어를 공개하고 플랫폼별로 나눈 벤치마크를 내는 경쟁 제품은 없습니다. 그러니 수치뿐 아니라 공개한다는 사실 자체도 요점의 하나로 받아들여 주세요.

측정한 머신. Intel Core i9-14900KF, 물리 코어 24, 논리 프로세서 32, RAM 64 GB, Windows 11 Pro (build 26200), Unity 6000.3.9f1, Burst 1.8.29. 측정일 2026-07-12.

Weft의 비용, 쉽게 말하면

구매자가 실제로 묻는 네 가지 장면을, 위에서 공개한 머신에서의 비용과 90 fps VR 프레임(11.11 ms)에서 차지하는 비율로 보여드립니다. 이는 출시 빌드(IL2CPP) 수치로, 장면을 계획할 때 기준으로 삼아야 할 정직한 숫자입니다.

장면 Weft 솔버 비용 90 fps VR 프레임 대비 비율
히어로 아바타 하나(헤어와 의상) ~0.6 ms ~5%
아바타 8체의 방, 모두 쉬는 중 ~2.8 ms ~25%
아바타 8체의 방, 한 명에게 손이 닿은 상태 ~4 ms (p95) ~35%, 0 dropped frames measured
1만 정점 의상이 생성되는 순간 ~4.5 ms one-time (with Bake Topology) budget once per avatar join, not per frame

알아 둘 만한 정직한 주의점 몇 가지입니다. 이는 공개된 데스크톱 머신 한 대에서 측정한 것으로, 여러분의 머신은 다를 수 있습니다. 온디바이스(Quest, 모바일) 성능은 아직 측정하지 않았습니다. "손이 닿은 방" 행은 "쉬는 방" 행보다 더 가벼운 측정 방식을 거치므로, 프레임 단위로 직접 비교할 수 없습니다. 전체 공개 표와 측정 방법은 이 페이지 하단에 있으며, 이 표는 그 위에 얹은 쉬운 요약입니다.

바라던 대로 확장됩니다

각 아바타는 저마다 독립된 월드를 스텝하므로, 아바타를 늘려도 비용은 거의 선형으로만 늘어납니다. 갑작스러운 절벽은 없습니다. 출시 릴리스 빌드(바이올렛)는 모든 지점에서 에디터 상한선(핑크) 아래로 들어옵니다.

에디터 상한선 출시 빌드
0 1 2 3 4 5 6 7 ms 1 2 4 8 아바타(리그) ~6.5 ms ~5.1 ms

위 수치는 각 아바타를 하나씩 차례로 푼 것으로, 정직한 최악의 경우입니다. Weft는 대신 이들을 겹쳐 풀 수 있습니다. 쉬고 있는 여덟의 무리는 약 두 배 빠르게 돌고, 누군가 닿아 있는 아바타조차 이제 나머지와 겹쳐 돕니다. 자세한 수치는 아래에 있습니다.

쉬는 무리를 한꺼번에 풀기

쉬고 있는 8체의 방을 하나씩이 아니라 한꺼번에 풀면 비용이 대략 절반이 됩니다.

이 사다리의 각 리그는 헤어 그룹 하나(35 스트랜드, 210 파티클)와 3,000 정점 의상 하나로, 아바타 하나당 약 3,210개의 시뮬레이션 점을, 8리그 전체에서 25,680개를 이룹니다.

Weft는 아무도 닿지 않는다면 여러 아바타를 하나씩이 아니라 동시에 풀 수 있습니다. 아래 표는 이 페이지의 다른 부분과 같은 머신, 같은 일상적인 환경에서 바로 그것을 측정한 것입니다.

측정일 2026-07-12 / 2026-07-13.

이 표의 수치는 모두 아무도 닿지 않은 쉬는 무리의 것입니다. 누군가 아바타를 잡거나 찌르더라도 Weft는 그 때문에 처리를 멈추지 않고 무리와 함께 풀게 되었으므로, 아바타에 닿아도 프레임이 막히지 않습니다(드문 한 가지 경우는 예외). 닿아 있을 때의 수치는 다음 절에 있고 다른 방식으로 측정했으니, 이 표와 칸끼리 비교하지 마세요.

리그 Sequential ms 동시 ms, 배치 off 동시 ms, 배치 on 가속, 배치 off 가속, 배치 on
1 0.7027 0.5866 0.5986 1.1979x 1.1739x
2 1.4632 0.9016 0.8819 1.6229x 1.6592x
4 2.9021 1.6309 1.6059 1.7794x 1.8072x
8 5.7515 2.8688 2.8261 2.0049x 2.0351x

쉽게 말해, 쉬는 무리는 한 아바타에서 약 1.2배, 여덟에서 두 배를 조금 넘게 빨라지고, 배치를 켜든 끄든 실질적인 차이는 없습니다. 쉬는 무리가 클수록 겹쳐 푸는 이점이 커집니다.

Sequential 열은 같은 무리를 하나씩 푼 것으로, 같은 방식으로 측정했기에 가속 비교는 같은 조건끼리입니다. 이는 페이지 앞쪽의 단순한 멀티 아바타 수치와는 다른 것으로, 그쪽은 조금 다르게 측정했으니 둘을 같게 보지 마세요.

두 가속 열(배치 켬과 끔)은 서로 측정 잡음 범위 안에 들어오므로 같은 결과로 보시면 됩니다.

실제 휴대폰과 헤드셋에서의 수치는 아직 여기 없습니다. 기다리던 작업은 끝났고 두 기기도 손에 있지만, 아직 측정하지 않았을 뿐입니다. 측정이 이뤄지는 대로 올리겠습니다.

실제로 아바타에 손이 닿아 있을 때

방 안의 모든 아바타가 동시에 잡히고 찔리고 눌려도, 대략 4 ms입니다.

이 사다리의 모든 월드는 의상과 헤어 둘 다에 걸린 그랩이 있고, 첫 프레임부터 실제로 교차하는 콜라이더가 모든 아바타에 진짜 찌름 충격을 주고 있습니다.

지금까지의 표는 쉬는 무리였습니다. 이 표는 그 반대로, 모든 아바타가 첫 프레임부터 잡히고 찔리고 눌립니다. 플레이어의 손이 실제로 아바타에 닿아 있을 때 장면이 실제로 얼마나 드는지 보여줍니다.

측정일 2026-07-13.

아바타 표준 ms p95 ms p99 ms 90 fps 초과 프레임
1 0.8043 1.4329 1.6742 0
2 1.1817 1.4355 1.4836 0
4 2.0224 2.5007 2.6737 0
8 3.5850 3.9533 4.0940 0

여덟 아바타를 동시에 닿아도 예산을 넘긴 프레임은 하나도 없었습니다. 이는 평균이 아니라 한 머신에서의 한 번 측정이므로, 약속이 아니라 좋은 신호로 받아들이세요. 더 바쁜 장면은 더 듭니다.

p95와 p99는 평균이 아니라 최악의 경우 값입니다. 스무 번에 한 번, 백 번에 한 번만 이보다 느린 프레임이 나온다는 뜻입니다. 마지막 열은 "히치"의 수, 즉 90 fps 헤드셋이 주는 11.11 ms보다 느려서 눈에 띄게 프레임을 떨어뜨릴 만큼 느렸던 프레임의 수입니다.

한 가지 유의점: 이것은 위의 쉬는 표와 조금 다른 방식으로 측정했습니다(같은 솔버 작업을, 주위 렌더링 없이). 그러니 두 표를 수치끼리 비교하지 마세요.

아바타가 합류할 때의 일회성 비용과, 그 해결책

아래 각 단계는 아바타 생성 시 한 번 측정한 "처음부터 다시 짓는" World Build이며, 프레임당 비용이 아닙니다.

위의 모든 것은 매 프레임 드는 비용입니다. 이것은 아바타가 나타나는 순간 한 번 만드는 일회성 비용으로, 세션 도중 플레이어가 장면에 걸어 들어오는 것과 같은 경우입니다. 매 프레임이 아니라 한 번만 일어나며, 여기서는 정직한 끊김과 Weft가 출시한 해결책을 함께 보여드립니다.

측정일 2026-07-13.

스트랜드 빌드 ms
35 0.0956
70 0.1847
140 0.3708
200 0.5938

헤어

정점 빌드 ms
3,000 23.0921
4,875 47.2207
7,200 95.5325
10,000 193.8801

메시 의상

리그 빌드 ms
1 23.0552
2 46.0327
4 92.5230
8 189.2070

멀티 아바타

헤어는 만들기 저렴합니다. 비용이 드는 것은 의상 메시로, 현실적인 1만 정점 의상은 처음부터 지으면 약 194 ms가 걸리며, 아바타가 나타나는 바로 그 순간에 전부 몰리면 몇 프레임짜리 진짜 끊김이 됩니다. 이는 베이크 없는 정직한 수치입니다. 해결책은 아래를 참고하세요.

토폴로지 베이크, 출시된 해결책

클릭 한 번으로 1만 정점 단계의 처음부터 다시 짓는 빌드가 ~198 ms에서 ~4.5 ms로 줄어듭니다. roughly 44x 더 빠릅니다.

의상 인스펙터의 "Bake Topology" 버튼은 의상을 짓는 과정에서 비용이 큰 부분(어느 정점이 어떻게 연결되는지)을 한 번만 저장된 애셋으로 구워 둡니다. 아바타가 합류할 때마다 처음부터 다시 유도하는 대신 이를 불러옵니다. 힌지가 없는 메시 사다리는 1만 정점 단계에서 ~198 ms에서 ~4.5 ms로, roughly 44x 줄어듭니다. 힌지가 활성화된 의상도 같은 단계에서 ~500 ms에서 ~55 ms로, roughly 9 to 10x라는 큰 효과를 보입니다. 포즈, 스케일, 튜닝 변경은 베이크를 무효화하지 않으며, 메시 자체나 토폴로지 설정에 대한 진짜 변경만 무효화합니다. 그 결과는 베이크하지 않은 빌드와 바이트 단위로 동일함이 증명되어 있습니다.

오래되었거나 일치하지 않는 베이크는 절대 사용되지 않습니다. Weft는 조용히 처음부터 다시 짓는 방식으로 대체하므로, 베이크가 잘못되거나 손상된 결과를 출시하는 일은 결코 없습니다.

0

할당은 0, 게다가 게이트입니다

Weft의 해법은 정상 상태에서 헤어, 메시 천, 멀티 아바타 어느 쪽에서든 프레임당 관리 바이트를 0만 할당합니다. 이는 바람이 아니라, 허용 오차 없이 정확히 0바이트 차이를 요구하는 엄격한 테스트 게이트입니다. 차이가 0이 아니면 빌드가 큰 소리로 실패합니다. 조용히 넘어가는 일은 결코 없습니다.

전체 사다리

모든 단계, 두 열 모두, 그리고 정확한 메모리 사용량. 솔버 스텝 시간의 중앙값을 밀리초로 표시합니다. 백분율은 90 fps 기준입니다.

헤어 스트랜드 무리, 스트랜드당 파티클 여섯.

200 스트랜드에서도 저렴하며, 0.5 밀리초 미만입니다.

스트랜드 파티클 에디터 ms 빌드 ms 90 fps 메모리
35 210 0.1262 0.1078 1.14% 9,520 B
70 420 0.2652 0.2388 2.39% 19,040 B
140 840 0.4644 0.3746 4.18% 38,080 B
200 1,200 0.4922 0.3792 4.43% 54,400 B

파티클당 바이트는 사다리 전체에서 일정합니다. 단계별 추가 비용이 없는 고정 파티클 단위 구조체라면 마땅히 이렇게 됩니다.

메시 의상 평평한 격자, 쿼드당 삼각형 둘.

현실적인 1만 정점 의상도 약 1.3 밀리초입니다.

정점 파티클 에디터 ms 빌드 ms 90 fps 메모리
3,000 3,000 0.6794 0.5186 6.12% 373,536 B
4,875 4,875 0.8379 0.6218 7.54% 610,656 B
7,200 7,200 1.0314 0.7760 9.28% 905,376 B
10,000 10,000 1.2947 0.9183 11.65% 1,260,896 B

파티클당 바이트는 사다리를 오를수록 아주 조금 올라갑니다. 이는 단계별 고정 비용이 아니라, 격자가 커질수록 정점당 벤드(힌지) 제약 밀도가 조금씩 늘기 때문입니다.

멀티 아바타 리그 하나는 헤어 그룹 하나와 의상 하나입니다.

8체의 풀 아바타를 하나씩 풀면 약 6.5 밀리초로, 이는 쉬는 무리나 손이 닿은 무리가 실제로는 전부 치르지 않는 정직한 최악의 경우입니다.

리그 파티클 에디터 ms 빌드 ms 90 fps 메모리
1 3,210 0.8076 0.6086 7.27% 383,056 B
2 6,420 1.5975 1.2395 14.38% 766,112 B
4 12,840 3.2479 2.4832 29.23% 1,532,224 B
8 25,680 6.4776 5.0928 58.30% 3,064,448 B

비용은 리그 수에 거의 선형으로 확장됩니다. 각 리그가 리그 간 공유 없이 독립된 월드를 스텝하기 때문입니다. 리그 하나는 위의 모든 버짓 줄에서 10% 아래에 넉넉히 들어옵니다.

참고 프레임 버짓: 60 fps 16.67 ms, 72 fps 13.89 ms, 90 fps 11.11 ms, 120 fps 8.33 ms. 90 fps 기준이 주요 PCVR 버짓입니다.

어떻게 측정했나

측정 방법이야말로 차별점이라 무엇 하나 숨기지 않았습니다. 읽어 보고 위 수치를 얼마나 신뢰할지는 직접 판단하세요.

진짜 Stopwatch, 그것뿐

모든 값은 Unity EditMode 배치 모드 실행에서 솔버 자신의 Step 호출을 Stopwatch로 감싸 얻은 것입니다. 렌더링도 입력도 씬 로드도 없습니다. 순수한 솔버 스텝만이며, 이는 코스트 테스트 모음이 이미 쓰는 방식과 같습니다.

중앙값의 중앙값

각 단계는 버리는 워밍업 5스텝, 이어서 측정 20스텝을 돌리고, 공개하는 수치는 그 구간을 독립적으로 5회 돌린 중앙값입니다. 중앙값은 스케줄러의 한 번짜리 느린 틱을 평균값보다 잘 흘려보냅니다.

메모리는 측정이 아니라 계산

메모리 열은 컴파일된 구조체 크기에 실제 파티클 수와 제약 수를 곱해 그대로 냅니다. 그래서 실행마다의 잡음이 없고 구성상 정확합니다. IL2CPP 빌드는 열두 단계 모두에서 에디터와 바이트 단위로 동일한 메모리를 냈습니다.

일부러, 평범한 머신에서

이 값들은 평범한 백그라운드 앱(녹화 또는 방송, 브라우저, 채팅 또는 보이스)을 띄운 일상 작업용 머신에서 측정했습니다. 밀폐된 실험실 장비가 아닙니다. 이는 의도한 것입니다. 실제 구매자의 머신이 바로 그렇기 때문입니다. 백그라운드 CPU 부하는 구간 전체에서 평균 약 4~5퍼센트였고, 이전의 유휴 실행은 비교용으로 보관해 두었습니다.

더 느린 수치를 공개합니다

에디터 열은 Mono 아래에서 관리 연결 코드를 돌리며 컬렉션 안전성 검사를 켠 채입니다. 이는 릴리스 빌드가 걷어 내는 오버헤드입니다. 빌드 열은 같은 구간에서 실제로 돌린 Windows x64 IL2CPP 릴리스 플레이어이며, 열두 단계 어느 것도 에디터 대조보다 단지 같은 게 아니라 더 빨랐습니다. 프레임 버짓 백분율은 일부러 더 느린 에디터 열을 씁니다. 그래서 그것은 출시 빌드가 넘어설 뿐인 보수적인 상한선입니다.

DOTS의 속도, Entities 세금 없이

Weft는 Burst, C# Job System, Collections, Mathematics라는 DOTS 토대 위에 지었지만 ECS를 쓰지 않고 Entities 의존성도 없습니다. Entities 프로젝트 구성을 들이지 않고도 DOTS급 솔버 성능을 얻습니다.

성능-품질 및 기기 등급 프리셋

Weft는 시뮬레이션 속도, 서브스텝 수, 반복 횟수, 그리고 위의 스케줄러 설정을 하나의 이름 붙은 등급으로 묶는 구매자용 프리셋 메뉴를 제공합니다. 등급을 고르는 것은 그 항목들을 직접 손으로 설정하는 것과 정확히 같으며, 그 외에는 아무것도 바뀌지 않습니다.

두 메뉴 모두 Unity 메뉴 바의 Weft / Performance Profile에 있습니다.

성능-품질 등급

등급 시뮬레이션 속도 서브스텝 반복 횟수 스케줄링 배치 스케줄
Performance 60 Hz 2 2 Concurrent On
Balanced 60 Hz 4 4 Auto Off
Cinematic 60 Hz 6 6 Auto Off
Crowd 60 Hz 4 4 Auto Off

기기 등급

등급 시뮬레이션 속도 서브스텝 반복 횟수 스케줄링 배치 스케줄
Desktop 60 Hz 4 4 Auto Off
Quest-class mobile XR 45 Hz 3 3 Concurrent On

두 표의 모든 값은 잠정적입니다. 특히 Quest급 모바일 XR 행은 실기기 측정을 기다리는 정직한 출발점이며, 눈대중으로 다듬은 최종값이 아닙니다.

Crowd는 슬립을 켜는 유일한 등급입니다. 안정된 의상은 완전히 유휴 상태가 되어 프레임당 비용이 거의 0이 되지만, 그 대신 출시 기본값보다 깨어나는 속도가 조금 느려집니다.

어떤 프리셋도 자기 충돌에는 절대 손대지 않습니다. 이를 끄면 시각적 동작이 바뀌므로, 컴포넌트마다 직접 의도적으로 설정하는 수동 손잡이로 남아 있습니다.

Weft가 도는 곳

Weft는 여러분 자신의 Unity 애플리케이션이나 게임을 위한 Unity 패키지입니다. 가져와서 여러분 자신의 빌드(PC, PC VR, 또는 여러분 프로젝트가 이미 출시하는 스탠드얼론 플랫폼)를 대상으로 하면 네이티브 패키지처럼 그대로 들어갑니다. 이것이 지원 범위 전부이며, 의도해서 그렇게 했습니다.

라이브 소셜 및 아바타 샌드박스는 사용자 업로드를 입구에서 커스텀 솔버 코드를 걷어 내는 방식으로 불러옵니다. 신뢰할 수 없는 업로드를 남의 클라이언트에서 안전하게 돌리려고 그렇게 하는 것이며, 이는 이런 식으로 만든 모든 네이티브 솔버에 적용됩니다. Weft도 마찬가지입니다. 그러니 그 플랫폼들은 여기의 결함이 아니라 그 작동 방식의 성질로서 범위 밖입니다.

스탠드얼론 Quest급 XR

Weft를 스탠드얼론 헤드셋에서 아직 측정하지 않았습니다. 코드는 해당 칩에서 돌아가므로 가능성은 있지만, 가능성과 측정은 다릅니다. 헤드셋과 휴대폰이 지금 손에 있고, 실제로 측정하는 대로 수치를 여기 올리겠습니다. 그때까지는 실제로 재지 않은 수치는 공개하지 않습니다.

결정성

Weft의 리플레이가 정확히 일치하는 것은 같은 빌드를 같은 플랫폼에서 돌릴 때뿐입니다. 서로 다른 플랫폼 사이에서 비트 단위까지 맞추는 일은 지금은 하지 않습니다.

그 약속은 "같은 빌드, 같은 플랫폼, 그리고 같은 설정"입니다. 기록 이후에 시뮬레이션 속도, 서브스텝 수, 반복 횟수, 또는 강성을 바꾸면 그 기록의 비트 단위 리플레이가 깨집니다. 다른 빌드나 플랫폼의 세부 사항을 바꾼 경우와 마찬가지입니다.

시뮬레이션 속도는 정직한 처리량 손잡이이기도 합니다. 출시 기본값인 60 Hz 대신 절반의 빈도인 30 Hz로 돌리면, 솔버가 스텝하는 횟수가 절반이 되는 만큼 실제 1초당 솔버 처리 시간도 대략 절반이 됩니다.