STL vs OBJ vs 3MF: 3D 파일 형식 차이와 선택법

STL은 1987년 3D Systems의 첫 광조형(스테레오리소그래피) 장비를 위해 만들어졌고, 그 출신이 설계에 그대로 드러납니다. 파일은 삼각형을 나열한 단순한 목록이며, 각 삼각형은 면 노멀 하나와 꼭짓점 세 개로 표현됩니다. 공유 정점 테이블이 없어서 삼각형 여섯 개가 만나는 꼭짓점은 여섯 번 기록됩니다. 단위 필드도 없습니다. 좌표 25가 밀리미터인지 인치인지 미터인지 알 수 없고, 거의 모든 슬라이서는 밀리미터로 가정합니다. 색상, 텍스처, 파트 이름은 기본 형식에 들어갈 자리가 없는데, 바로 그 덕분에 모든 슬라이서와 CAD 프로그램, 출력 서비스가 지금도 STL을 읽습니다.

STL에는 두 가지 인코딩이 있습니다. ASCII STL은 facet normal, outer loop, vertex 12.5 0 3.2 같은 줄로 모든 것을 텍스트로 풀어 쓰기 때문에 텍스트 편집기로 열어 숫자를 읽을 수 있습니다. 바이너리 STL은 80바이트 헤더와 4바이트 삼각형 개수로 시작하고, 이후 삼각형 하나를 4바이트 부동소수점 12개와 2바이트 속성 필드로 저장합니다. 정확히 삼각형당 50바이트입니다. 이 규칙 덕분에 용량을 쉽게 예측할 수 있습니다. 삼각형 100만 개짜리 모델은 바이너리로 약 50 MB이고, 같은 메시의 ASCII 버전은 숫자 하나하나가 문자로 바뀌기 때문에 보통 4~6배 더 큽니다.

이 단순함은 장점이자 함정입니다. STL은 원래 파트 하나였는지 세 개였는지, 인치로 내보냈는지, 삼각형들이 실제로 닫힌 입체를 이루는지 알려 주지 못합니다. 슬라이서는 날것의 좌표만 보고 이를 추측하고, 추측이 틀리면 25.4배 작은 파트나 벽이 빠진 파트가 나옵니다. 직접 설계해 밀리미터로 내보낸 단색 파트라면 이런 문제는 상관이 없고, STL은 여전히 거부당할 가능성이 가장 낮은 형식입니다.

OBJ는 Wavefront Technologies에서 나온 형식으로, 1980년대 후반 이 회사의 Advanced Visualizer 소프트웨어가 사용했고, 1990년대를 거치며 거의 모든 3D 프로그램이 주고받을 수 있는 일반 텍스트 형식으로 퍼졌습니다. STL과 달리 정점 목록을 따로 두고 인덱스로 면을 구성하므로 공유 꼭짓점은 한 번만 저장되며, 면은 삼각형, 사각형 또는 더 큰 폴리곤일 수 있습니다. v로 시작하는 줄은 위치, vt는 텍스처 좌표(UV), vn은 노멀, f는 면을 담습니다. 그룹(g)과 개체(o)가 파트에 이름을 붙이기 때문에 OBJ는 Blender, Maya, ZBrush를 오가도 구조가 그대로 유지됩니다.

모양새(색과 질감) 정보는 .obj 파일 바깥에 있습니다. mtllib 줄이 짝이 되는 .mtl 파일을 지정하고, usemtl 줄이 면에 재질을 할당합니다. .mtl 파일은 Kd(확산색) 같은 색상을 저장하고, map_Kd wood.png 같은 항목으로 텍스처 이미지를 가리킵니다. 그래서 텍스처가 있는 OBJ는 최소 세 개의 파일, 즉 지오메트리, 재질 라이브러리, 하나 이상의 이미지로 이루어지며 모두 상대 경로로 연결됩니다. .obj만 보내면 받는 사람에게는 회색 모델만 보입니다. 이렇게 분리된 구조는 아티스트가 지오메트리를 건드리지 않고 텍스처만 바꾸는 게임·VFX 파이프라인에서 유용하지만, 내려받은 모델이 이상하게 보이는 가장 흔한 원인이기도 합니다.

OBJ는 스케일에 관해 STL과 같은 약점이 있습니다. 단위 없이 숫자만 저장합니다. 대부분의 모델링 도구는 미터나 센티미터로 쓰고 슬라이서는 밀리미터로 읽기 때문에, 게임 에셋 스토어에서 받은 OBJ는 10배나 1,000배 어긋난 크기로 들어올 수 있습니다. 출력 관점에서 OBJ는 일부 도구의 정점별 색상을 빼면 슬라이서가 쓰는 정보를 더해 주지 않습니다. 그래서 아트 에셋을 출력해야 한다면 텍스처는 렌더링용으로 남겨 두고 슬라이서에는 깨끗한 메시를 보내는 편이 대개 가장 간단합니다. 반대 방향으로는 STL을 OBJ로 변환하는 것이 출력용 모델을 렌더링이나 게임 작업으로 가져가는 가장 빠른 길입니다.

3MF는 2015년 3MF Consortium이 발표했습니다. Microsoft가 출력·CAD 업계 기업들과 함께 만든 단체입니다. .3mf 파일은 ZIP 압축 파일로, ZIP vs RAR vs 7z에서 다룬 것과 같은 컨테이너 형식입니다. 확장자를 .zip으로 바꿔 열어 보면 메시가 들어 있는 3D/3dmodel.model XML 파일, 콘텐츠 유형 파일, 관계(relationship) 파일, 그리고 흔히 썸네일과 슬라이서 설정이 들어 있습니다. 모든 모델은 단위(마이크론, 밀리미터, 센티미터, 인치, 피트, 미터)를 선언하므로 STL과 OBJ를 괴롭히는 스케일 문제가 아예 생기지 않습니다. 색상, 기본 재질, 여러 개체와 빌드 플레이트 위의 배치도 모두 사양에 포함됩니다.

사양은 또한 메시가 매니폴드이고 방향이 일관되어야 한다고 규정합니다. 모든 모서리는 정확히 두 삼각형이 공유해야 하고, 모든 삼각형은 바깥을 향해야 합니다. 규칙을 지키는 내보내기 도구는 STL이 아무렇지 않게 담는 열린 지오메트리나 자기 교차 지오메트리를 쓸 수 없습니다. 현재 도구들은 대부분 지원합니다. PrusaSlicer, Bambu Studio, OrcaSlicer, UltiMaker Cura가 3MF를 읽고, PrusaSlicer와 Bambu Studio는 출력 설정과 칠한 색상을 포함한 프로젝트 전체를 .3mf로 저장하며, Windows의 Microsoft 3D Builder 앱은 3MF를 바로 엽니다. 약점은 아직 STL을 기대하는 구형 펌웨어, 출력 대행 포털, CAD 가져오기 기능입니다. 이런 곳에는 3MF를 STL로 변환하되, 부가 정보는 남겨진다는 점을 감수해야 합니다.

알맞은 형식은 어느 쪽이 더 새로운지가 아니라 파일이 다음에 어디로 가는지에 달려 있습니다. 다음 목적지가 슬라이서이고 단색 파트라면 STL로 충분하며, STL은 여전히 모든 커뮤니티, 모델 라이브러리, 출력 서비스가 알아듣는 형식입니다. 다음 목적지가 렌더러, 게임 엔진, 다른 아티스트의 모델링 도구라면 OBJ가 STL이 버리는 UV, 노멀, 이름 붙은 그룹을 지켜 주고, 텍스트 형식이라 문제를 들여다보기도 쉽습니다.

3MF는 파일에 지오메트리 이상의 정보가 담길 때 진가를 발휘합니다. Bambu Studio에서 색을 칠한 다색 출력물, 한 번에 출력하려고 배치한 파트 12개짜리 플레이트, 인치로 설계한 파트, 같은 레이어 높이와 내부 채움으로 다시 열고 싶은 프로젝트에는 모두 3MF가 필요합니다. 여기서 다룬 형식 중 그 정보를 담을 수 있는 것은 3MF뿐이기 때문입니다. 여러 곳에 보내야 한다면 가장 정보가 많은 버전을 원본으로 보관하고, 변환을 연달아 거치지 말고 3D 모델 변환기로 그 원본에서 단순한 버전을 내보내세요.

형식 탓으로 돌리는 출력 실패와 가져오기 오류는 대부분 사실 메시 자체의 문제이거나, 받는 프로그램이 메시에 대해 잘못 가정한 결과입니다. STL은 실수를 잡아 줄 메타데이터가 없어서 가장 취약하고, OBJ는 스케일 문제와 파일 누락 문제를 함께 안고 있습니다. 3MF는 설계상 대부분을 피하지만, 부주의한 내보내기 도구라면 여전히 잘못된 메시를 쓸 수 있습니다. 아래 항목을 펼치면 각 문제가 어떻게 나타나고 주로 어디서 생기는지 볼 수 있습니다.

용량은 구조에서 나옵니다. 바이너리 STL은 삼각형당 50바이트로 고정이라 내보내기 전에 계산할 수 있습니다. ASCII STL은 꼭짓점마다 텍스트로 반복해 쓰기 때문에 보통 바이너리의 4~6배가 됩니다. OBJ는 공유 정점을 한 번만 저장하고 인덱스로 참조하므로, 일반적인 닫힌 메시라면 ASCII STL보다 작고 바이너리 STL과 비슷한 수준이며, UV와 노멀까지 담으면 더 커집니다. 3MF는 인덱스 방식의 XML을 ZIP 안에서 압축하므로 같은 지오메트리라면 대개 셋 중 가장 작습니다.

아래 수치는 정밀한 피규어처럼 삼각형이 약 50만 개인 닫힌 메시의 일반적인 값입니다. 실제 파일은 좌표 정밀도와 내보내기 도구에 따라 달라지므로 대략적인 규모로만 보세요. 출력 서비스에 업로드 용량 제한이 있거나, 3MF에서 내보낸 STL이 몇 배나 커졌을 때 참고하기 좋습니다.

변환은 한 컨테이너에서 삼각형을 읽어 다른 컨테이너에 쓰는 작업입니다. 대상 형식이 표현할 수 있는 것은 함께 옮겨지고, 표현할 수 없는 것은 버려집니다. 그래서 STL을 OBJ로 바꾸면 지오메트리 손실이 없고, 3MF를 STL로 바꾸면 색상, 단위, 플레이트 배치가 사라지며, OBJ를 STL로 바꾸면 텍스처와 파트 이름이 사라집니다. UltKit의 3D 도구는 이런 추가 결정을 명시적으로 묻습니다. 모델 단위는 원본이 어떤 스케일을 쓰는지 변환기에 알려 주고, 위쪽 축은 게임 엔진과 슬라이서 사이의 Y-up과 Z-up 차이를 처리하며, 메시 하나로 합치기는 따로 떨어진 파트를 분리된 채로 둘지 정합니다.

어떤 변환도 메시를 고쳐 주지는 않습니다. STL에 구멍이 있으면 그것으로 만든 OBJ에도 같은 구멍이 있고, 3MF 내보내기 도구는 이를 거부하거나 그대로 기록합니다. 복구는 메시 편집 도구나 슬라이서 내장 복구 기능에서 하는 별도의 단계이며, 다른 형식으로 내보내기 전에 원본 파일에서 한 번만 하는 것이 가장 좋습니다. 스케일도 마찬가지입니다. 파트가 원래 인치 단위였다는 사실은 직접 알려 주지 않으면 변환기가 알 수 없습니다. 디테일도 같습니다. 폴리곤이 적은 STL은 폴리곤이 적은 OBJ나 3MF가 될 뿐이므로, 품질이 중요하다면 원본 모델에서 다시 내보내세요.

이 질문이 나올 때마다 함께 언급되는 형식이 두 가지 더 있습니다. STEP(ISO 10303)은 삼각형이 아니라 정확한 솔리드와 곡면을 저장하므로, 파트를 Fusion 360, SolidWorks, FreeCAD로 다시 가져가 편집해야 할 때 쓰는 형식입니다. Khronos Group의 glTF 2.0 바이너리 형태인 GLB는 메시와 재질, 텍스처를 미터 단위의 파일 하나에 담으며, 웹이나 Android AR에서 모델을 보여 줄 때 쓰는 형식입니다.

이 글에서 다룬 세 형식에 대해서는 아래 표가 목적지별 선택을 정리합니다. 두 줄이 모두 해당한다면 정보를 더 많이 담는 형식을 고르고 단순한 형식은 나중에 내보내세요. 3MF에서 STL로 가는 것은 쉽지만, 잃어버린 색상이나 단위를 되살리는 것은 손으로 해야 하는 일입니다.