FLEXnet error -15,10 해결 방법 LMTOOLS 라이선스 서버 연결 오류 점검

플렉스LM(FLEXlm) 또는 현재 명칭으로 많이 불리는 FlexNet Publisher 기반 라이선스 시스템을 쓰는 소프트웨어에서 FLEXnet error -15,10 또는 Cannot connect to license server 메시지가 뜨면, 대부분은 프로그램 자체 고장보다 라이선스 서버 접속 경로가 막혔거나 잘못 지정된 경우가 많습니다.

저도 이런 오류를 보면 무조건 재설치부터 하지 않고, 먼저 license.dat 경로, SERVER 라인 호스트명, lmgrd 서비스 실행 여부, 벤더 데몬 상태, 방화벽과 포트부터 확인합니다.

FLEXnet 오류는 겉으로는 비슷하게 보여도 실제 원인이 한두 가지가 아니어서, 순서를 잘 잡는 게 훨씬 중요합니다.

특히 System Error 10061 WinSock: Connection refused가 함께 뜬다면, 클라이언트가 지정된 서버와 포트까지 갔는데 거기서 연결을 받아주지 못하고 있다는 뜻에 가깝습니다.

쉽게 말해 서버가 안 떠 있거나, 포트가 틀렸거나, 벤더 데몬이 죽어 있거나, 보안 정책에 막힌 상황으로 보는 게 현실적입니다.

% LICENSE MANAGER: Cannot connect to license server
The server (lmgrd) has not been started yet, or
the wrong port@host or license file is being used, or the
port or hostname in the license file has been changed.
Feature: idl
Server name: myserver
License path: C:Program FilesITTlicenselicense.dat;C:Program FilesITTlicense*.lic
FLEXnet error: -15,10. System Error: 10061 "WinSock: Connection refused"

이 메시지는 응용 프로그램이 라이선스 파일에 적힌 서버명과 포트 정보로 TCP 연결을 시도했지만 실패했다는 의미입니다. 그래서 해결도 프로그램 옵션보다 서버 설정과 네트워크 통신 쪽에서 풀리는 경우가 많습니다.

FLEXnet error -15,10 오류 의미

FLEXnet error -15,10은 클라이언트가 라이선스 서버에 접속하지 못할 때 대표적으로 보이는 오류로 아직 lmgrd가 시작되지 않았거나, 잘못된 port@host를 보고 있거나, 라이선스 파일이 틀렸거나, 호스트명이나 포트가 바뀐 상황에서 자주 발생합니다.

결국 이 오류는 “프로그램이 라이선스를 못 찾는다”보다는 클라이언트가 지정된 라이선스 서버와 정상적인 대화를 못 하고 있다는 쪽으로 이해하는 편이 맞습니다.

잘못된 라이선스 파일 참조

가장 먼저 확인할 것은 프로그램이 실제로 어떤 license.dat 또는 *.lic 파일을 보고 있는지입니다.

오류 메시지에 표시된 License path를 보면 현재 참조 경로가 나옵니다. 여기서 오타가 있거나, 예전 서버 주소가 남아 있거나, 다른 제품용 라이선스 파일이 섞여 있으면 바로 -15,10 오류로 이어질 수 있습니다.

특히 폴더 안에 여러 라이선스 파일이 함께 있는 환경에서는, 예전 설정이 남아 잘못된 파일을 먼저 읽는 경우도 적지 않습니다. 이럴 때는 관련 경로를 정리하고, 현재 사용하는 제품 기준의 라이선스 파일만 남겨놓는 편이 깔끔합니다.

라이선스 서버 서비스 미실행

다음으로 많이 막히는 부분이 라이선스 서버 서비스 자체가 실행되지 않은 경우입니다.

Windows에서는 LMTOOLS에서 서비스로 등록해 쓰는 경우가 많은데, 여기서 서비스가 제대로 저장되지 않았거나 재부팅 후 자동 시작이 꺼져 있으면 클라이언트는 당연히 서버를 못 찾게 됩니다.

Revenera 가이드에서도 LMTOOLS를 관리자 권한으로 실행하고, Use Services와 Start Server at Power Up를 설정해 Windows 서비스로 운영하는 구성을 안내합니다.

서버를 계속 쓰는 환경이라면 이 설정은 사실상 기본으로 보는 편이 낫습니다.

Vendor Daemon 미실행

실무에서는 lmgrd는 살아 있는데 벤더 데몬만 죽어 있는 경우도 아주 흔합니다.

예를 들어 IDL이면 idl_lmgrd.exe 같은 벤더 데몬이 같이 떠야 실제 라이선스 체크아웃이 됩니다. 그래서 단순히 서비스 목록에 “실행 중”이라고 떠 있다고 끝난 게 아닙니다.

이럴 때는 디버그 로그와 lmstat -a 결과를 같이 보는 게 좋습니다. Revenera 문서도 디버그 로그를 통해 lmgrd와 각 벤더 데몬의 상태, 시작 포트, 재시작 여부, 옵션 파일, 서비스 실행 환경 등을 확인할 수 있다고 안내합니다.

a.) 벤더 데몬이 실제로 시작됐는지 디버그 로그를 먼저 확인합니다.

b.) 로그 안에 벤더 데몬 종료, 충돌, 포트 바인딩 실패 같은 문구가 있는지 확인합니다.

c.) 서버에서 lmstat -a를 실행해 라이선스 매니저와 벤더 데몬 상태를 같이 점검합니다.

참고 : UG NX 라이센스 에러 Lmtools 설정 방법

SERVER 라인 호스트명 불일치

license.dat의 SERVER 라인에 적힌 호스트 이름이 현재 서버 이름과 다르거나, DNS에서 해당 이름을 못 찾는 경우도 흔한 원인입니다. 이 부분은 생각보다 사소해 보여도 자주 발목을 잡습니다.

Revenera 문서에는 서버 이름 또는 호스트 이름이 대소문자까지 민감할 수 있으므로 라이선스 파일에 제공된 이름과 동일하게 사용하라고 적혀 있습니다.

서버 이름을 바꿨거나, 도메인 정책으로 호스트명이 달라졌다면 이 부분부터 다시 확인하는 편이 좋습니다.

클라이언트와 서버 네트워크 문제

클라이언트와 서버 사이의 네트워크가 끊겼거나, 특정 구간에서 포트가 막혀도 같은 오류가 납니다. 특히 사내망, VPN, 원격근무, 다른 서브넷, 보안장비가 섞인 환경에서는 “서버는 살아 있는데 내 PC만 안 붙는” 괴상한 상황이 자주 생깁니다.

이럴 때는 서버에서만 보지 말고 문제가 나는 클라이언트 PC에서 직접 점검해야 합니다. lmstat -a, lmdiag, 그리고 해당 포트로의 연결 테스트를 같이 보는 편이 정확합니다.

포트 테스트와 연결 확인

예전 문서에는 telnet 테스트가 많이 나오지만, 요즘 Windows 환경에서는 PowerShell의 Test-NetConnection이 더 편한 경우가 많습니다. 다만 telnet이 설치돼 있다면 테스트 자체는 여전히 가능합니다.

예를 들어 라이선스 파일의 SERVER 라인이 myserver 1700을 가리킨다면, 클라이언트에서 해당 포트가 열리는지 먼저 확인해볼 수 있습니다.

telnet myserver 1700

또는 PowerShell에서 아래처럼 테스트할 수 있습니다.

Test-NetConnection myserver -Port 1700

여기서 연결이 안 되면 라이선스 서비스가 안 떠 있거나, 포트가 틀렸거나, 방화벽 또는 네트워크 정책에 막힌 가능성이 큽니다. 반대로 포트 연결은 되는데 프로그램은 여전히 실패한다면, 그다음은 벤더 데몬과 내부 로그를 봐야 합니다. 포트가 열렸다는 것만으로 라이선스 체크아웃이 정상이라는 뜻은 아니기 때문입니다.

방화벽과 보안 프로그램 차단

Windows Defender나 서드파티 보안 솔루션이 lmgrd.exe 또는 벤더 데몬의 포트 통신을 막아도 -15,10 오류가 납니다. 특히 서버에서는 서비스가 떠 있는데, 외부 연결만 거부되는 형태로 보일 수 있어서 처음 보면 헷갈립니다.

Revenera와 NV5 계열 문서에서도 서버 포트와 관련 실행 파일에 대한 방화벽 허용 구성이 필요하다고 안내합니다. 결국 클라이언트에서 보이는 “Connection refused”는 프로그램 문제라기보다 네트워크 쪽 문지기가 문을 안 열어주는 상황일 때가 많습니다. :contentReference[oaicite:4]{index=4}

license.dat 포맷과 인코딩 문제

license.dat 파일에 오타가 있거나, 줄바꿈 형식이 꼬였거나, 복사 과정에서 보이지 않는 문자가 들어간 경우도 의외로 많습니다. 메일 본문에서 복사해 붙여넣다 줄 끝 공백이 들어가거나, 편집기에서 인코딩이 달라져 문제가 나는 경우가 꽤 있습니다.

그래서 라이선스 파일은 가능하면 일반 메모장보다 Notepad++나 Visual Studio Code 같은 편집기로 열어 줄 단위와 공백을 확인하는 편이 낫습니다. 특히 SERVER, VENDOR 또는 DAEMON 라인에 오타가 있으면 서버는 떠도 클라이언트가 접속을 못 할 수 있습니다.

포트 충돌 문제

라이선스 서버가 사용하는 포트를 이미 다른 프로그램이 점유하고 있는 경우에도 접속이 실패할 수 있습니다. 이런 경우 LMTOOLS에서 서비스 시작은 된 것처럼 보여도 실제로는 원하는 포트에 정상 바인딩하지 못했을 가능성이 있습니다.

이럴 때는 사용 중인 포트를 확인하고, 필요하면 다른 포트로 바꾼 뒤 license.dat와 클라이언트 설정을 함께 맞춰야 합니다. 한쪽만 바꾸고 մյուս은 그대로 두면 바로 -15,10 늪으로 다시 돌아갑니다. 참 사소한데 아주 사람 약 올리는 구간입니다.

서버 재부팅 후 자동 시작 설정

서버를 재부팅한 뒤 갑자기 라이선스가 안 붙는다면, 의외로 원인은 단순합니다.

라이선스 서비스가 자동 시작으로 등록되지 않았기 때문입니다. LMTOOLS의 Start Server at Power Up 설정을 해두지 않으면 재부팅 후 수동으로 다시 시작해야 하는 경우가 생깁니다.

Revenera 가이드도 이 체크박스를 통해 부팅 시 자동으로 Windows 서비스가 시작되도록 구성하라고 안내합니다. 서버를 늘 켜두는 환경이라면 빼먹지 않는 편이 좋습니다. x=5}

디버그 로그 저장 위치 점검

LMTOOLS 설정에서 디버그 로그 경로가 잘못 잡혀 있으면 서비스가 애매하게 동작하거나, 로그가 남지 않아 원인 파악이 더 어려워질 수 있습니다.

Revenera는 Windows 서비스로 돌릴 때 로그 경로를 ProgramData 하위 폴더에 두는 것을 권장합니다. 서비스 계정 권한과 충돌이 덜하기 때문입니다.

즉, 로그가 안 남는다고 “서버가 정상이다”라고 보면 안 됩니다. 오히려 로그가 안 남는 설정 문제일 수도 있으니, Path to the debug log file도 같이 확인해야 합니다.

가상 머신 환경 주의사항

라이선스 서버가 가상 머신에 있을 때는 네트워크 어댑터 변경, MAC 주소 변경, 스냅샷 복원 같은 변수 때문에 문제가 더 잘 생깁니다. 일부 환경에서는 호스트 ID가 달라져 라이선스와 실제 서버 정보가 어긋나기도 합니다.

가상 환경 자체가 무조건 안 되는 건 아니지만, MAC 주소 고정, 호스트명 고정, IP 변경 여부 확인, 재부팅 후 서비스 자동 시작은 꼭 같이 보는 편이 좋습니다.

127.0.0.1 변경 테스트 주의점

예전 자료를 보면 SERVER 라인의 호스트명을 127.0.0.1로 바꿔 테스트하는 방법이 자주 소개됩니다.

이 방법은 서버와 클라이언트가 같은 PC인 로컬 테스트에서는 확인용으로 쓸 수 있지만, 플로팅 라이선스를 여러 PC에서 쓰는 환경에서는 일반 해법으로 보면 안 됩니다.

즉, 이 값은 “내 PC 안에서 서비스가 뜨는지”를 잠깐 확인하는 용도에 가깝고, 실제 운영 서버 주소를 대체하는 정답으로 받아들이면 오히려 더 꼬일 수 있습니다.

SERVER servername 0000123abcd 1700

로컬 테스트 상황에서만 아래처럼 바꿔볼 수 있습니다.

SERVER 127.0.0.1 0000123abcd 1700

다만 운영 환경에서는 실제 서버명 또는 고정 IP와 일치하도록 맞추는 편이 맞습니다.

참고 : 오토캐드 라이센스 오류 – FlexNet License Finder

FLEXnet error -15,10 빠른 해결 순서

• License path에 표시된 현재 라이선스 파일 경로를 먼저 확인합니다.
• license.dat의 SERVER, VENDOR 또는 DAEMON 라인 오타를 확인합니다.
• LMTOOLS에서 Use Services, Start Server at Power Up, 서비스 저장 상태를 확인합니다.
• Start/Stop/Reread에서 서버를 다시 시작하고 Server Status를 확인합니다.
• lmstat -a로 lmgrd와 vendor daemon 상태를 함께 확인합니다.
• 클라이언트 PC에서 포트 테스트를 실행합니다.
• 방화벽과 보안 프로그램 예외를 확인합니다.
• 디버그 로그를 열어 포트 바인딩, 데몬 종료, 경로 오류를 확인합니다.

플로팅 라이선스 문제는 한 번에 큰 작업을 하기보다, 이렇게 경로 → 서비스 → 데몬 → 포트 → 로그 순서로 좁혀가면 훨씬 빨리 잡힙니다. 괜히 프로그램을 먼저 지웠다 다시 깔아도, 서버가 안 떠 있으면 결국 같은 메시지만 다시 보게 됩니다.

FLEXnet error -15,10은 단순히 “라이선스가 없다”는 뜻이 아니라, 클라이언트가 라이선스 서버와 정상 통신하지 못하는 상태라고 보는 편이 맞습니다. 실제로는 잘못된 license.dat, 서버 미실행, vendor daemon 장애, 포트 충돌, 방화벽, 서버명 불일치가 가장 흔한 원인입니다.

저라면 이 오류가 뜰 때 무조건 license.dat부터 열고, LMTOOLS에서 서비스와 로그부터 확인합니다. FLEXnet 계열은 겉보기에 복잡해 보여도, 로그와 포트만 제대로 보면 생각보다 빨리 실마리가 나오는 편입니다.