현장에서 LMTOOLS 이야기가 나오면 많은 분들이 UG NX 전용 도구처럼 받아들이는 경우가 많습니다. 그런데 실제로는 반대에 가깝습니다. LMTOOLS는 지멘스만의 도구가 아니라 FlexNet/FLEXlm 계열 라이센스 서버를 윈도우에서 관리할 때 많이 쓰는 관리 화면이고, NX·Solid Edge·Femap 같은 지멘스 계열뿐 아니라 Autodesk, MATLAB, ArcGIS, IBM Rational 같은 제품군에서도 비슷한 구조를 볼 수 있습니다.
최근에는 여기서 한 번 더 헷갈리는게 이번에 지멘스 NX 2406를 설치했는데 예전처럼 서비스에 Siemens License Server가 보이지 않거나, SPLM License Server를 따로 설치하지 않았는데도 프로그램이 실행되는 경우가 있기 때문입니다.
우선 이 부분은 단순히 설치가 잘못된 게 아니라 라이센스 방식 자체가 달라졌거나, 서버형이 아닌 로컬/클라우드 기반 방식을 쓰는 경우가 많아서 생기는 차이입니다.
먼저 결론부터 정리하면
LMTOOLS가 보인다고 해서 무조건 정품 서버형 라이센스이고, 안 보인다고 해서 바로 비정상 설치라고 단정할 수는 없습니다. NX X 같은 named-user 방식은 로그인 기반으로 동작할 수 있고, node-locked non-served 방식은 서버 서비스 자체가 필요하지 않을 수 있습니다. 반대로 서버형 정품이라면 서비스, 라이센스 파일, 포트, 환경변수, 로그가 서로 맞아야 정상입니다.
LMTOOLS가 하는 일
LMTOOLS는 쉽게 말해 라이센스 서버 상태판입니다.
화면만 보고 있으면 단순한 유틸리티처럼 보이지만 실제로는 뒤에서 돌아가는 lmgrd, 각 소프트웨어 제조사의 vendor daemon, 그리고 license file 또는 trusted storage를 연결해 확인하는 역할을 합니다.
| 구성요소 | 역할 | 실무에서 보는 위치 |
|---|---|---|
| 클라이언트 프로그램 | NX, MATLAB, Autodesk 제품처럼 실제로 라이센스를 요청하는 프로그램 | 사용자 PC에서 실행 |
| lmgrd | 최초 접속을 받고 적절한 vendor daemon으로 요청을 넘김 | 서버 서비스 또는 백그라운드 프로세스 |
| vendor daemon | 각 벤더 라이센스 정책을 실제로 집행 | ugslmd, saltd, adskflex, mlm 등 |
| license file / trusted storage | 사용 권한, 버전 범위, 수량, 호스트 정보, 바인딩 정보 보관 | .lic/.dat 또는 내부 저장소 |
| LMTOOLS | 상태 조회, 서비스 등록, 시작/중지, 로그 확인 | 주로 Windows 관리자 PC |
작동 순서는 생각보다 단순합니다. 사용자가 NX를 실행하면 NX가 라이센스를 직접 계산하는 것이 아니라 설정된 라이센스 소스를 먼저 찾습니다.
서버형이면 port@host로 지정된 서버에 요청을 보내고, 그 요청을 lmgrd가 받은 뒤 알맞은 vendor daemon으로 넘깁니다. 그 다음 vendor daemon이 라이센스 파일 또는 trusted storage를 확인해 사용 가능한 좌석인지, 해당 버전을 쓸 수 있는지, 토큰이나 번들이 맞는지를 판단해 체크아웃을 승인하는 구조입니다.
LMTOOLS 라이센스 서버를 사용하는 대표 프로그램
제목을 “모든 프로그램”으로 잡고 검색하는 분들이 많지만, 엄밀히 말하면 LMTOOLS를 쓰는 프로그램 목록은 닫힌 목록이 아닙니다.
특정 소프트웨어 이름이 아니라 FlexNet/FLEXlm 기반으로 배포되는 제품군이라는 점입니다. 아래 제품군은 실제로 현장에서 가장 자주 부딪히는 대표 범주로 보면 됩니다.
| 분야 | 대표 제품 키워드 | 주요 특징 |
|---|---|---|
| 지멘스 CAD/CAE/PLM | NX, Solid Edge, Femap, Simcenter, Fibersim, Tecnomatix 일부 구성 | 예전 ugslmd 계열에서 saltd 기반 Siemens License Server로 점차 통합 |
| Autodesk | AutoCAD, Inventor, Revit 등 네트워크 라이센스 구성 | Autodesk Network License Manager와 LMTOOLS 사용 사례가 많음 |
| 공학 계산 | MATLAB, Simulink | Windows에서는 LMTOOLS로 상태 조회와 서비스 등록 가능 |
| GIS | ArcGIS Desktop Concurrent Use, ArcGIS Pro Concurrent Use | FlexNet 기반 License Manager 사용 |
| 개발/ALM | IBM Rational 계열, UrbanCode 계열 일부 | Rational License Key Server가 FLEXlm 기반 |
여기서 중요한 점은 LMTOOLS가 보인다고 해서 전부 동일한 라이센스 구조가 아니라는 점입니다.
제품마다 vendor daemon 이름이 다르고, 라이센스 파일 구조도 조금씩 다르며, 최신 제품은 license file보다 trusted storage나 named-user를 함께 쓰는 경우도 많습니다.
윈도우 자동실행과 서비스 등록 방식
실무에서 서버가 재부팅될 때마다 라이센스가 내려오면 가장 먼저 보는 항목이 이 부분입니다.
LMTOOLS에서 Configuration using Services로 등록한 뒤 Config Services에서 lmgrd.exe 경로, license file 경로, debug log 경로를 저장하고 서비스로 시작하는 구성이 가장 흔합니다.
윈도우 자동실행 점검 순서
- LMTOOLS를 관리자 권한으로 실행
- Service/License File에서 Configuration using Services 선택
- Config Services에서 lmgrd.exe, license file, debug log 경로 지정
- Use Services, 필요 시 Start Server at Power Up 체크
- Save Service 후 Start/Stop/Reread에서 시작 여부 확인
이 과정에서 자주 놓치는 부분이 로그 경로 권한입니다.
로그를 Program Files 안에 두면 권한 문제로 서비스가 시작되지 않는 경우가 있고, 이런 이유로 실제 매뉴얼도 ProgramData 쪽 로그 저장을 권장하는 편입니다.
저는 서버를 만질 때 서비스가 떴는지보다 먼저 로그가 실제로 기록되는지부터 보는 편입니다.
서비스 이름이 보여도 로그가 비어 있으면 거의 항상 경로, 권한, 라이센스 파일 중 하나가 어긋나 있습니다.
윈도우에서 바로 확인할 명령
sc query type= service state= all | findstr /I "license lmgrd siemens"
netstat -ano | findstr :28000
netstat -ano | findstr :29000
set SPLM
powershell -command "Get-Service | Where-Object {$_.DisplayName -match 'License|lmgrd|Siemens'}"
NX 계열에서는 서버 또는 클라이언트에서 lmutil lmstat -a -c port@host로 현재 라이센스 상태를 보는 방법도 많이 씁니다. 관리 화면이 애매하게 보일 때는 결국 이 방식이 제일 확실합니다.
NX 2406에서 Siemens License Server가 안 보이는 이유
이 부분은 한 줄로 정리하면 이렇습니다. NX 2406를 쓴다고 해서 항상 로컬 PC에 Siemens License Server 서비스가 생기는 것은 아닙니다. 무엇을 샀는지, 어떤 라이센스 형태인지에 따라 완전히 달라집니다.
1. NX X named-user 방식인 경우
최근 지멘스는 NX X처럼 Siemens 계정 로그인 기반의 named-user 라이센스를 적극적으로 쓰고 있습니다. 이 경우 사용자는 소프트웨어에 로그인해서 권한을 받기 때문에, 예전처럼 내 PC의 서비스 목록에 Siemens License Server가 따로 없을 수 있습니다. 이런 방식은 설치 후 Siemens Software Center 또는 NX 실행 시 로그인 흔적이 보이는 경우가 많습니다.
2. node-locked non-served 방식인 경우
서버형이 아니라 비서버형 노드락이면 로컬 파일만으로 라이센스를 읽기 때문에 Siemens License Server를 아예 설치하지 않아도 되는 경우가 있습니다. 이 경우 라이센스 파일 안에 서버 라인이 없거나, 특정 호스트에 묶여 있는 형태로 보일 수 있습니다. 쉽게 말해 한 대에서만 쓰는 로컬 자물쇠에 가깝습니다.
3. 서버는 따로 있고 클라이언트만 설치한 경우
회사에서 흔한 구조입니다. 실제 라이센스 서버는 서버실 PC에만 있고, 사용자 PC에는 NX 클라이언트와 환경변수만 잡아 둡니다.
그래서 사용자 PC에서 services.msc를 열어도 라이센스 서비스가 없는 것이 정상입니다. 대신 SPLM_LICENSE_SERVER=포트@서버명만 맞게 잡혀 있으면 라이센스를 받아옵니다.
4. 예전 ugslmd가 아니라 saltd 기반으로 바뀐 경우
여기서 더 헷갈리는 부분이 있습니다. 최근 Siemens License Server는 예전 ugslmd만 따로 보는 구조에서 점차 saltd 중심으로 통합되는 흐름을 보입니다.
그래서 예전 문서만 보고 ugslmd 서비스가 안 보인다고 해서 바로 이상하다고 보시면 안 됩니다. 실제로는 saltd가 ugslmd 계열 라이센스까지 함께 처리하는 환경이 섞여 있습니다.
| 상황 | services.msc | LMTOOLS | 판별 기준 |
|---|---|---|---|
| NX X named-user | 보이지 않을 수 있음 | 로컬에 없을 수 있음 | Siemens 계정 로그인 기반 |
| node-locked non-served | 보통 없음 | 없을 수 있음 | 서버 없이 로컬 라이센스 파일 사용 |
| floating / node-locked served | 서버 PC에 존재 | 서버 PC에서 확인 가능 | port@host, 로그, 라이센스 파일, 서비스가 맞물림 |
| SALT 통합 환경 | Siemens License Server로 표시될 수 있음 | saltd 중심으로 확인 | 예전 ugslmd 흔적과 현재 saltd가 섞여 보일 수 있음 |
NX 2406에서 바로 체크할 항목
- Siemens 계정 로그인 화면이 보이는지 확인
- 환경변수에 SPLM_LICENSE_SERVER가 있는지 확인
- 서버 PC에 Siemens License Server 또는 관련 로그가 있는지 확인
- ActiveLicense/ActiveLicenses 폴더에 .lic 파일이 있는지 확인
- 라이센스 파일을 열어 SERVER 줄이 있는지 확인
- 정상 서버라면 lmutil lmstat로 응답이 나오는지 확인
개인적으로는 이럴 때 서비스 창만 보지 말고 라이센스 파일 구조부터 확인하는 편입니다. 서비스는 숨을 수 있어도, 정품 서버형이면 결국 서버 주소, 파일, 로그, 버전 호환이 반드시 남습니다.
정품 서버형과 비정상 설치를 구분할 때 보는 항목
이 부분은 선을 분명히 그어야 합니다. 우회 방법이나 회피 방법을 다루는 것이 아니라, 정상적인 관리 관점에서 무엇을 보면 판별이 쉬운지 정리해 보겠습니다.
중요
정품 여부를 가장 정확하게 가르는 기준은 서비스 유무 하나가 아니라 공식 entitlement, 라이센스 파일 일치, 로그, 버전 호환, 계정 권한입니다. 실행된다는 이유만으로 정상이라고 보시면 안 됩니다.
정상 환경에서 흔히 보이는 흔적
- 공식 포털에서 발급된 라이센스 파일 또는 계정 권한이 있음
- 버전에 맞는 라이센스 서버가 설치되어 있음
- 로그 파일에 서버 시작, 체크아웃, 체크인 기록이 자연스럽게 남음
- named-user라면 Siemens 계정 로그인 흐름이 일관됨
- floating이라면 port@host, SERVER 줄, vendor daemon, 서비스 상태가 서로 맞음
비정상 설치가 의심되는 신호
- 공식 entitlement나 발급 이력이 없는데 특정 버전이 계속 열림
- 서비스나 포트 구조가 설명되지 않는데도 로컬에서만 이상하게 동작
- 원래 필요한 로그인 또는 서버 체크가 사라져 있음
- 라이센스 파일 서명 오류, trusted storage 손상, 버전 불일치 메시지가 반복됨
- 정상 설치 경로가 아닌 곳에 수정된 DLL, 실행파일, 의심스러운 가짜 데몬이 섞여 있음
요즘 라이센스 플랫폼은 예전보다 훨씬 촘촘합니다. license file만 보는 시대가 아니라 trusted storage, machine fingerprint, 계정 권한, usage/compliance 모니터링까지 함께 보는 구조라서, 단순히 서비스 이름을 숨기거나 파일 하나 바꿨다고 끝나는 방식이 아닙니다. 특히 FlexNet 계열은 tampering, license cloning, clock wind-back 같은 비정상 행위를 탐지하는 기능을 계속 강화해 왔습니다.
NX 2406에서 정품 여부를 실무적으로 확인하는 방법
저라면 아래 순서로 봅니다. 이 순서대로 보면 괜히 서비스 창만 뒤져 보다가 시간을 버리는 일이 줄어듭니다.
- 구매한 라이센스 형태를 먼저 확인합니다. NX X인지, floating인지, node-locked인지부터 다릅니다.
- Siemens 계정 로그인이 필요한 타입인지 확인합니다. 필요하면 서비스가 없어도 이상하지 않습니다.
- SPLM_LICENSE_SERVER 또는 제품별 라이센스 설정값을 확인합니다.
- 라이센스 파일의 SERVER 줄과 버전 범위를 확인합니다.
- 서버 버전이 해당 NX 릴리스와 맞는지 확인합니다. 새 NX 릴리스는 서버 업그레이드가 필요한 경우가 많습니다.
- lmutil lmstat 또는 LMTOOLS 상태 조회로 실제 체크아웃이 되는지 확인합니다.
- debug log와 Windows 서비스 시작 로그를 확인합니다.
lmutil lmstat -a -c 29000@서버이름 lmutil lmdiag -c 29000@서버이름 echo %SPLM_LICENSE_SERVER%
여기서 응답이 정상이면 서버형 정품 환경일 가능성이 높고, 반대로 공식 라이센스 정보가 없는데도 설명되지 않는 방식으로만 실행된다면 그때는 설치 경로와 바이너리 무결성까지 포함해서 다시 보는 게 맞습니다.
자주 헷갈리는 질문
서비스에 Siemens License Server가 없으면 무조건 크랙인가요
아닙니다. NX X named-user, node-locked non-served, 클라이언트 전용 설치라면 로컬 PC 서비스가 없어도 정상일 수 있습니다. 대신 공식 계정, 라이센스 파일, 환경변수, 서버 응답 중 적어도 하나는 정식 구조로 설명이 되어야 합니다.
NX 2406부터 SPLM License Server를 안 쓰는 건가요
완전히 안 쓴다고 보기보다는 라이센스 방식이 더 다양해졌고, 서버형은 Siemens License Server와 saltd 중심으로 정리되는 방향으로 보는 게 맞습니다. 제품과 계약 방식에 따라 로그인 기반, served, non-served가 나뉘기 때문에 예전 한 가지 방식으로만 보면 계속 헷갈립니다.
서비스는 있는데 NX가 라이센스를 못 받는 경우는 왜 생기나요
실제 현장에서는 포트 불일치, 서버 버전 부족, 환경변수 오타, 버전 지원 범위가 다른 라이센스 파일, 방화벽, 번들 선택 오류가 가장 흔합니다. 서비스가 떠 있다는 사실만으로 체크아웃 성공이 보장되지는 않습니다.
한 번에 정리하면
LMTOOLS는 지멘스 전용 툴이 아니라 FlexNet 계열 라이센스 서버를 관리하는 Windows 도구로 보는 게 정확합니다. 그래서 NX만의 문제가 아니라 Autodesk, MATLAB, ArcGIS, IBM Rational처럼 여러 제품군에서 비슷한 개념이 반복됩니다.
그리고 NX 2406에서 서비스가 안 보이는 문제는 대개 설치가 이상해서가 아니라 라이센스 방식이 예전과 다르기 때문입니다. named-user인지, floating인지, non-served인지부터 먼저 보면 답이 빨리 나옵니다.
정품 여부를 볼 때도 서비스 유무 하나만으로 판단하지 말고, 공식 entitlement, license file, 환경변수, 로그, 서버 응답을 같이 맞춰보는 쪽이 훨씬 정확합니다.
※ 본문은 라이센스 서버 구조와 정상 판별 기준을 정리한 내용입니다. 우회나 회피 방법은 다루지 않았습니다.
댓글
댓글 쓰기