UG NX 리눅스 Siemens License Server (lmgrd·SALT) 설치와 라이센스 설정

UG NX 리눅스 Siemens License Server(SPLM) 구성과 라이센스 설정 완전 정리

지멘스 UG NX는 제품 설계부터 해석, 제조까지 한 번에 다루는 통합 3D CAD/CAM/CAE 툴이라, 회사에서 리눅스 기반 인프라를 운영하고 있다면 Linux 서버에 Siemens License Server를 올려서 NX 라이센스를 중앙에서 관리하는 구성이 자연스럽게 따라옵니다. NX 자체는 최신 버전 기준으로 주로 Windows에서 쓰이지만, 라이센스 서버는 여전히 리눅스에서도 공식적으로 지원되기 때문에 서버용 OS로 Linux를 선호하는 환경이라면 이 구성이 꽤 안정적입니다.

UG NX 리눅스 Splm Licenser Sever Lmtools 설치 및 라이센스

리눅스 서버 위에서 동작하는 UG NX Linux SPLM License Server 구성 개념을 한눈에 보여주는 이미지

여기서는 리눅스 환경에서 Siemens PLM License Server를 올리고, lmgrd / lmutil 명령어로 라이센스를 관리하는 기본 구조를 정리해 보려고 합니다.

Windows에서 자주 사용하는 Lmtools GUI는 리눅스에 없기 때문에, CLI 기반 명령과 설정 파일에 익숙해지는 게 중요합니다. 2024년 이후부터 본격적으로 쓰이기 시작한 SALT(Siemens Advanced Licensing Technology) 계열 라이센스도 Linux License Server 위에서 돌아가기 때문에, 최신 NX 환경을 준비하려는 분들에게도 공통으로 필요한 내용입니다.

1. 리눅스용 Siemens NX License Server 필수 파일 준비

리눅스 Splm.Zip

16.24MB

리눅스에서 NX 라이센스를 운영하려면 크게 세 가지를 확보해야 합니다. NX 설치 이미지, Siemens License Server(예전 이름 SPLM License Server), 그리고 정품 라이센스 파일(.lic)입니다. 정품 사용자는 Siemens Support Center에 Webkey 계정으로 접속해 제품 다운로드와 라이센스 파일을 받을 수 있고, 기존 버전에서 새 버전으로 갱신했다면 라이센스도 함께 갱신된 파일을 내려받아야 합니다.

Windows에서 쓰는 Lmtools는 리눅스에 제공되지 않기 때문에, 여기서는 lmgrd, lmutil, 그리고 벤더 데몬(splm 또는 saltd) 조합으로 라이센스 서버를 관리하게 됩니다. Siemens License Server 패키지 안에 이 바이너리들이 포함되어 있고, 최근 릴리즈에서는 systemd 서비스(saltd)와 함께 제공되는 구조가 많습니다.

2. Linux Siemens PLM License Server 설치 및 디렉토리 구성

Siemens License Server는 대부분 .tar.gz 형태로 제공되고, 보통 /opt 아래에 전용 디렉토리를 만들어 설치하는 구성이 많이 쓰입니다. 예시는 아래와 같이 둘 수 있습니다.

tar -zxvf plm_license_server.tar.gz -C /opt/plm_license_server

위처럼 압축을 풀어 두면 /opt/plm_license_server 아래에 lmgrd, lmutil, 벤더 데몬 실행 파일, 예제 라이센스 파일, 스크립트 등이 함께 들어가게 됩니다. 보안과 운영 편의를 위해 루트 계정이 아닌 전용 계정(예: nxlic)을 만들어 이 디렉토리 소유권을 넘겨두면 관리가 한결 수월합니다.

3. 지멘스 NX 라이센스 파일 배치와 포트 설정

정품으로 받은 라이센스 파일에는 SERVER, VENDOR, USE_SERVER, INCREMENT/FEATURE와 같은 FlexNet 형식의 행이 들어 있습니다.

이 중에서 가장 먼저 눈에 들어오는 부분이 서버 이름과 포트, 그리고 HostID(CID, MAC 주소 등)입니다. 라이센스 서버가 실제로 설치된 리눅스 머신의 호스트명·MAC 주소·Composite ID와 반드시 일치해야 정상 동작합니다.

일반적으로 Siemens NX 계열 라이센스는 TCP 28000 포트를 많이 사용하고, 환경에 따라 다른 포트를 지정하기도 합니다. 기존 Windows 크랙 환경에서 익숙한 27800@호스트이름 조합과 정품 라이센스의 28000@호스트이름 조합을 혼동하면 연결 오류가 나기 쉬우니, 리눅스에서도 실제 .lic 파일 안에 선언된 포트 번호를 기준으로 생각하는 게 깔끔합니다.

실제 운용에서는 라이센스 파일을 다음과 같이 두는 경우가 많습니다.

구분	예시 경로	설명
실행 바이너리	/opt/plm_license_server	lmgrd, lmutil, 벤더 데몬(splm/saltd) 위치
라이센스 파일	/opt/plm_license_server/license_file.lic	SERVER/VENDOR/FEATURE 정의 포함
로그 파일	/opt/plm_license_server/log_file.log	라이센스 체크인/체크아웃 및 에러 기록

4. 리눅스에서 lmgrd로 라이센스 서버 시작하기

• 라이센스 관리 데몬을 직접 실행해서 동작 여부를 확인할 수 있습니다.

cd /opt/plm_license_server
./lmgrd -c license_file.lic -l log_file.log

위처럼 라이센스 파일(-c)과 로그 파일(-l) 경로를 지정해 실행하면 백그라운드에서 lmgrd + 벤더 데몬이 함께 기동되고, log_file.log에 서버 시작 시점의 정보와 각종 메시지가 쌓입니다. 처음 구축할 때는 이 방식으로 눈으로 로그를 확인해 보고, 안정화가 되면 systemd 서비스 유닛을 작성해 부팅 시 자동으로 뜨도록 구성하는 경우가 많습니다.

5. lmutil로 Siemens License Server 상태 확인

• lmutil lmstat 명령을 활용하면 라이센스 서버가 정상적으로 응답하는지 간단히 확인할 수 있습니다.

./lmutil lmstat -a -c license_file.lic

여기서 -a는 전체 정보를 보여 주는 옵션이고, -c 뒤에 적은 라이센스 파일 경로를 통해 어느 서버를 확인할지 지정합니다. 서버가 제대로 떠 있다면 사용 가능한 피처 목록과 현재 체크아웃된 수량이 함께 표시되고, 서버가 죽어 있거나 방화벽·포트 설정이 꼬인 경우에는 연결 실패 메시지가 출력됩니다.

6. 리눅스용 Siemens NX 설치와 디렉토리 구조

NX 클라이언트는 최근 릴리즈 기준으로는 Windows에서 주로 사용되지만, 해석 모듈이나 특정 환경에서는 리눅스용 NX 바이너리를 함께 쓰는 경우도 있습니다. 설치 이미지가 준비되어 있다면 마찬가지로 /opt 아래에 전용 디렉토리를 만들어 압축을 풀어두는 구성이 깔끔합니다.

tar -zxvf siemens_nx_linux.tar.gz -C /opt/siemens_nx

압축 해제 후 제공되는 설치 스크립트를 실행해 NX를 배치합니다.

cd /opt/siemens_nx
./install

설치가 끝나면 NX 실행 바이너리, 라이브러리, 도움말 등이 각각의 하위 폴더에 자리 잡게 되고, 이후에는 라이센스 서버 정보와 환경 변수 설정만 맞춰주면 바로 NX를 띄울 수 있습니다.

7. NX 리눅스 클라이언트에서 라이센스 서버 연결 설정

NX를 처음 실행하면 라이센스 서버 위치를 묻는 화면이 나오는 경우가 많습니다. 이때 Siemens License Server가 돌아가고 있는 리눅스 서버의 IP 또는 호스트 이름, 그리고 라이센스 포트를 포트@호스트 형식으로 입력하면 됩니다.

예를 들어 라이센스 서버 호스트명이 nxlic-srv이고 라이센스 포트가 28000이라면 아래와 같이 입력합니다.

28000@nxlic-srv

이 값은 환경변수 SPLM_LICENSE_SERVER와도 연결됩니다. NX가 설치된 리눅스 워크스테이션에서는 이 환경변수를 설정해 두면, NX가 실행될 때마다 자동으로 해당 라이센스 서버로 접속합니다.

8. NX 리눅스 환경 변수 설정과 실행 경로 등록

리눅스에서 NX와 라이센스를 조금 더 편하게 쓰려면, 사용자 쉘 설정 파일에 NX 관련 환경 변수를 적어 두는 편이 좋습니다. 보통 ~/.bashrc나 ~/.bash_profile에 아래와 같이 추가합니다.

export PATH=$PATH:/opt/siemens_nx/bin

여기에 더해 다음과 같은 환경 변수를 함께 지정해 두는 경우가 많습니다.

• SPLM_LICENSE_SERVER : 28000@nxlic-srv 처럼 라이센스 서버 주소를 기록
• UGII_LANG : NX 인터페이스 언어(ko_KR, en_US 등)
• UGII_BASE_DIR : NX 설치 루트 디렉토리

설정 후에는 새 터미널을 열거나 로그아웃·로그인을 한 번 해주면 환경 변수 변경이 반영되고, 어디에서나 nx, ugraf 같은 실행 파일을 직접 타이핑해 NX를 열 수 있게 됩니다.

여기까지가 기존에 많이 쓰이던 FlexNet(lmgrd 기반) Siemens PLM License Server 방식의 구성이었다면, 최근 NX 릴리즈에서는 SALT 라이센스와 saltd 서비스가 함께 언급되는 경우가 늘었습니다. 아래에서 최신 구조를 조금 더 묶어서 정리해 보겠습니다.

리눅스 Siemens License Server 최신 구조와 SALT 라이센스 이해

2020년대 중반 이후 Siemens는 전통적인 SPLM License Server + lmgrd 구조 위에 Siemens Advanced Licensing Technology (SALT)를 도입해 라이센스 관리 방식을 점점 개편하고 있습니다.

NX 2206, NX 2212 이후 환경에서는 라이센스 파일과 서버 구성이 SALT 계열과 함께 언급되는 경우가 많은데, 리눅스 서버 입장에서는 새로운 벤더 데몬과 서비스(saltd)가 추가된 것이라고 보면 이해하기 편합니다.

전통적인 FlexNet 방식과 SALT 방식의 차이를 간단히 비교해 보면 아래와 비슷한 그림이 나옵니다.

항목	기존 SPLM License Server	SALT 기반 Siemens License Server
핵심 구성	lmgrd + splm 벤더 데몬	lmgrd + saltd 벤더 데몬
운영 방식	수동 스크립트, rc.local 등으로 기동	systemd 서비스(예: saltd) 중심 운영
관리 도구	lmutil, 텍스트 로그	lmutil + Siemens Licensing Tool, 확장된 로그
라이센스 파일	전통적인 FLEXnet 포맷	기존 포맷 기반이지만 SALT용 키워드와 기능 추가
지원 플랫폼	Windows, Linux 서버	동일하게 Windows, Linux 서버 지원

SALT 환경에서도 결국 기본 구조는 FlexNet 위에 Siemens 레이어가 얹힌 형태라서, 여기까지 정리한 lmgrd, lmutil, 라이센스 파일 관리 개념이 그대로 적용됩니다. 다만 최신 Siemens License Server 설치 프로그램을 사용하면 리눅스에서 systemctl start saltd / systemctl stop saltd 같은 명령으로 라이센스 서버를 제어할 수 있도록 준비해 주기 때문에 운영 편의성이 좋아진다는 정도를 기억해 두면 충분합니다.

UG NX 리눅스 라이센스 서버 운영 팁과 오류 예방 포인트

실제 현장에서 리눅스 라이센스 서버를 오래 돌리다 보면, 설치 과정보다도 장기간 안정 운용이 훨씬 중요해집니다. 로그를 어떻게 쌓고, 백업은 어떻게 가져가며, 방화벽과 네트워크는 어떻게 구성하느냐에 따라 NX 설계팀 전체의 업무가 좌우되기도 합니다.

먼저 방화벽에서는 라이센스 파일에 선언된 포트(예: 28000)를 인바운드·아웃바운드 모두 허용해 두어야 합니다. 사내망이 여러 구간으로 나뉘어 있거나, VPN을 통해 접속하는 워크스테이션이 있다면 방화벽 정책을 세밀하게 나눠서 NX 워크스테이션에서 라이센스 서버까지의 경로가 항상 열려 있도록 관리해야 합니다.

또 하나 중요한 것은 라이센스 파일 백업입니다. 라이센스 서버를 새 버전으로 올리거나, SALT 라이센스 파일을 추가로 병합하는 과정에서 기존 파일을 덮어쓰면 되돌리기 어려운 상황이 생길 수 있습니다. 그래서 원본 .lic 파일과 로그 파일을 별도의 백업 경로에 보관해 두고, 변경 전·후 파일을 따로 관리하는 습관을 들이면 나중에 문제 해결이 훨씬 쉬워집니다.

마지막으로, 가상 머신이나 클라우드 환경에서 라이센스 서버를 운영할 때는 HostID(CID, MAC)가 바뀌지 않도록 주의해야 합니다. 스냅샷 복원이나 VM 복제 과정에서 하드웨어 정보가 변하면, 라이센스 파일에 기록된 HostID와 맞지 않아 갑자기 라이센스가 모두 만료된 것처럼 보이는 상황이 생길 수 있기 때문입니다. 이런 환경에서는 VM 레벨에서 MAC 주소를 고정해 두거나, 서버를 물리 머신으로 분리하는 전략을 함께 고려해 두는 것이 안전합니다.

UG NX 다운로드 및 설치 라이센스 오류 - Lmtools License

NX 초기화 오류 - NX lICENSE Error Splm 라이센스 서버 Port@host [-15]

여기까지 정리한 내용을 토대로 리눅스에서 NX 라이센스 서버를 한 번 안정적으로 구축해 두면, 이후에는 NX 버전을 올리거나 라이센스 파일을 갱신할 때도 구조를 쉽게 파악하면서 수정할 수 있습니다. 이제 자주 나오는 질문들을 따로 모아 보겠습니다.

UG NX 리눅스 라이센스 서버 관련 FAQ

리눅스에서 NX 라이센스 서버만 운영하고, NX는 전부 Windows에서 써도 되나요?

그렇게 사용하는 환경이 오히려 더 많습니다. Siemens License Server는 리눅스, NX 클라이언트는 Windows에만 설치해 두고, Windows 워크스테이션에서 28000@nxlic-srv처럼 리눅스 서버를 바라보도록 설정하는 방식입니다. FlexNet 기반 라이센스 서버는 TCP/IP만 정상적으로 열려 있다면 OS가 섞여 있어도 문제 없이 동작합니다.

NX 버전을 올릴 때마다 라이센스 서버를 매번 새로 설치해야 하나요?

꼭 그렇지는 않지만, 라이센스 파일(.lic)의 버전과 License Server 버전이 너무 오래되면 호환성 이슈가 생길 수 있습니다.

Siemens에서는 정기적으로 새로운 Siemens License Server 버전을 내놓고 있기 때문에, NX 메이저 버전을 크게 올리는 시점(예: NX2007 → NX2206, NX2306 등)에는 라이센스 서버도 한 번씩 갱신해 주는 편이 안전합니다. 이때 기존 .lic를 완전히 덮어쓰지 말고, 백업을 먼저 만들어 둔 뒤에 새 라이센스를 병합하는 습관을 들이면 좋습니다.

lmgrd 말고 systemctl만으로 Siemens License Server를 관리할 수 있나요?

최신 Siemens License Server 설치 프로그램을 사용하면 리눅스에 systemd 서비스(saltd)가 함께 등록되는 경우가 많아 sudo systemctl start saltd, sudo systemctl stop saltd처럼 제어할 수 있습니다. 다만 내부적으로는 여전히 lmgrd + 벤더 데몬 구조를 사용하기 때문에, 문제가 생겼을 때를 대비해 lmgrd와 lmutil 명령에도 익숙해 두는 편이 좋습니다.

라이센스 서버 로그 파일은 어느 정도 주기로 관리하는 게 좋을까요?

NX 사용자가 많고 프로젝트가 길게 이어지는 환경이라면 로그 파일이 생각보다 빠르게 커집니다. 일반적으로는 월 단위 또는 분기 단위로 로그 파일을 회전시키고(새 파일로 교체), 이전 로그는 압축해서 보관하는 방식이 무난합니다. 문제가 생겼을 때는 이 로그를 기준으로 어느 시점에 어떤 오류가 났는지 추적할 수 있기 때문에, 삭제보다는 보관에 가깝게 가져가는 편이 좋습니다.

[-15], [-96], [-97] 같은 FlexNet 오류 코드는 어디에서 의미를 확인할 수 있나요?

FlexNet 계열 오류 코드는 FLEXnet License Administration Guide와 Siemens PLM Licensing Manual에 정리되어 있습니다.

Siemens 문서에는 NX·Teamcenter 등 Siemens 제품에서 자주 등장하는 코드 위주로 풀이가 되어 있고, FlexNet 원본 문서에는 보다 일반적인 의미가 설명되어 있습니다. 실제로는 에러 팝업에 적힌 메시지 + 로그 파일 메시지를 함께 보면서 해석하는 쪽이 훨씬 빠릅니다.

리눅스 라이센스 서버를 가상 머신 위에 올려도 Siemens에서 지원하나요?

지원 여부는 버전과 계약 조건에 따라 조금씩 달라지지만, 실제로는 VM 위에 Siemens License Server를 올려서 운영하는 사례가 많이 있습니다.

다만 앞에서 언급한 것처럼 HostID(Composite ID, MAC 주소)가 바뀌지 않도록 VM 설정을 안정적으로 고정해 두는 것이 중요하고, 리소스가 부족해지면 라이센스 서버 응답이 느려지면서 NX 쪽에서 타임아웃이 발생할 수 있으니 CPU·메모리·디스크 여유도 함께 신경 써야 합니다.

NX를 외부에서 VPN으로 접속해 쓸 때 라이센스 서버 구성은 어떻게 하는 게 좋을까요?

이 경우에는 사내망에 있는 리눅스 라이센스 서버는 그대로 두고, 외부에서 접속하는 사용자가 VPN으로 사내망에 들어온 뒤 SPLM_LICENSE_SERVER를 사내 라이센스 서버로 지정하는 식으로 사용하는 구성이 일반적입니다.

VPN 터널 품질이 좋지 않으면 라이센스 체크아웃·체크인 타이밍에 NX가 멈춘 것처럼 느껴질 수 있으니, 장시간 외부에서 작업해야 한다면 Siemens에서 제공하는 라이센스 Borrowing(임시 대여) 기능을 함께 검토해 보는 것도 방법입니다.

NX 버전이 여러 개 섞여 있을 때 라이센스 파일은 어떻게 관리하는 게 편할까요?

NX2007, NX2206, NX2306처럼 다양한 버전을 한꺼번에 운용하는 환경에서는, 보통 단일 라이센스 서버에 통합된 .lic 파일 하나를 두고 각 버전의 기능을 모두 담도록 요청하는 경우가 많습니다.

라이센스가 세분화되어 있다면 서버별로 .lic를 쪼개지 말고 한 파일로 병합해 관리하는 쪽이 운영과 백업 측면에서 훨씬 단순합니다. 다만 라이센스 계약 조건에 따라 구성 방식이 달라질 수 있으니, 최종적으로는 Siemens 담당자와 상의해서 구조를 정리하는 것이 안전합니다.

리눅스 NX 라이센스 서버 구축 시 꼭 체크해야 할 요약 포인트가 있다면?

정리해 보면, (1) 라이센스 파일의 HostID와 포트가 실제 서버와 일치하는지, (2) 방화벽에서 해당 포트가 열려 있는지, (3) lmgrd와 벤더 데몬이 정상 기동했는지 로그로 확인했는지, (4) 클라이언트의 SPLM_LICENSE_SERVER 값이 올바른지 이 네 가지를 항상 먼저 보게 됩니다. 이 네 가지만 확실히 맞춰져 있으면, 나머지 자잘한 문제는 로그 메시지를 보면서 천천히 풀어도 충분히 해결 가능합니다.