크레온 플러스 API 연동 IsConnect 확인 후 강제종료

크레온 플러스 API 연동시 IsConnect를 통해 연결상태를 확인하고 나면 잠시 후 실행한 파이썬 어플리케이션이 종료되는 현상이 있습니다. 크레온 플러스 API 연동시 강제종료되는 현상의 원인과 해결 방법을 알아보도록 하겠습니다.

크레온 플러스 API IsConnect 확인 후 강제종료되는 현상

VULTR 가상머신에서 크레온 플러스 API를 연동해서 사용하기 위해서 호스팅을 신청하고 이용했습니다. 그런데 분명 과거에는 아무 문제 없이 잘 실행했었는데, 지금은 실행한 파이썬 어플리케이션이 죽어버립니다. 그것도 아무런 오류도 발생시키지 않고 그냥 종료됩니다. 크레온 홈페이지에서 검색을 하고 문의를 해도 명확한 해답을 알 수 없었습니다.

집에 있는 PC에서는 vultr 인스턴스와 동일한 python 버전과 동일한 버전의 pywin32 라이브러리를 사용했는데, 집에 있는 PC에서는 문제 없이 크레온 플러스 API 연동이 잘 되고 있었습니다.

크레온 플러스 API Q&A 게시판 검색을 통해 관련 문제 확인

Creon Plus API Q&A 게시판에서 관련 게시물들을 검색하다가, “Re : 비주얼 스튜디오 닫힘 현상“이라는 게시물을 확인했습니다. 디버깅 하는 경우에는 “메모리 보안 프로그램 사용”을 끄고 사용해야 한다는 이야기가 있었습니다.

그래서 문제가 발생했던 VULTR 인스턴스에서 “메모리 보안 프로그램 사용”의 체크를 해제하고 크레온 플러스를 실행하니, 정상 작동이 됐습니다. 그러면 보안 프로그램 끄고 쓰면 되겠다고 생각할 수 있겠지만, 보안 프로그램을 끄는 것이 최선의 해결책은 아니라고 생각했습니다.

그리고 제가 사용하는 다른 피씨에서는 보안 프로그램을 끄지 않고도 잘 작동하고 있었습니다. 보안 프로그램을 쓸 수 있는 PC와 쓸 수 없는 PC에는 어떤 차이가 있어서 그런 것일까 의문을 갖게 되었습니다.

문제 지점 확인을 위한 코드 제작

제가 작성한 파이썬 코드에서 IsConnect 값을 확인하는 과정에서 문제가 생기는 것을 확인했지만, 더 정확하게 문제가 발생하는 부분만을 확인하기 위해서 아래의 코드를 작성했습니다. 그리고 VULTR 인스턴스에서 구동했습니다.

import win32com.client
import time

print("START")
cp_cybos = win32com.client.Dispatch('CpUtil.CpCybos')
print("LOADED")
a = time.time()
is_connected = cp_cybos.IsConnect
b = time.time()
d = b - a
print("%.8f" % d)
for i in range(10):
  print(i)
  time.sleep(1)
print("END")

Python

실행한 결과는 아래와 같았습니다. for loop의 2번째 루프까지 돌고 그냥 종료되어 버렸습니다. 그래서 나머지 2~9까지의 값과 END가 출력되는 것을 볼 수 없었습니다. 너무도 당황스러웠습니다. 상식적인 코드의 동작이 아니었으니까요.

START
LOADED
5.55898523
0
1

흥미로운 것은 IsConnect 값을 얻어오는 과정에서 문제가 생기지 않는 머신에서는 1초 미만의 시간만 걸리는 한 편, 문제가 생기는 머신에서는 5초 이상의 시간이 걸리다가 파이썬으로 실행한 어플리케이션이 강제로 종료됐습니다.

아무리 봐도 명백하게 cp_cybos.IsConnect 값을 가져오고난 후 임의의 시간 후에 종료됐습니다. 원인은 IsConnect값을 가져오는 부분이겠다고 생각하게 되었습니다.

문제가 발생했던 머신은 Vultr 가상 머신으로 1 CPU, 2G RAM, python 3.9.6, pywin32 302 버전이었습니다.

동일한 문제가 다른 가상머신에서 발생하는지 확인

VULTR 인스턴스 새로 생성해서 테스트

1차적으로는 OS 버전이 달랐기 때문에, 혹시나 하는 마음으로 집에서 사용하는 PC의 운영체제와 같은 버전의 윈도우를 Vultr의 동일 사양의 인스턴스에 설치해보았습니다. 하지만 결과는 같았습니다. 동일한 문제가 생기고 있었죠. OS 버전의 차이가 영향을 주는 게 아니라는 것을 확인했습니다.

Gnome Boxes VM을 통해 테스트

Gnome Boxes를 이용해서 문제 상황이 재현되는지 확인했습니다. 만약 똑같이 재현이 된다면 단순히 VULTR 서비스의 문제라고 할 수 없다는 걸 확인하게 되니까요.

제가 사용하는 Ubuntu 20.04에 Gnome Boxes를 설치했습니다. Gnome Boxes에서 가상머신을 위한 운영체제로 Windows 10을 설치했습니다. 그리고, 파이썬과 크레온 API를 설치한 후, VULTR의 인스턴스에서 실행했던 동일한 위의 테스트 코드를 실행해 보았습니다.

동일한 문제가 발생하지 않았습니다. 문제가 없이 잘 실행됐습니다.

VUTLR 인스턴스 CPU 2개짜리로 테스트

그렇게 AhnLAB의 AOS가 무슨 문제를 일으키는 것일까 고민하고 있었는데, 해당 코드가 문제 없이 작동한 컴퓨터들은 모두 CPU를 2개 이상 사용하고 있다는 것이 떠올랐습니다.

그렇다면 Vultr 서비스에 어떤 문제가 있어서 그런 것 아닐까 싶었습니다. 그런데 지난 번에 사용했던 $20 짜리 인스턴스는 문제가 생기지 않았었는데, 왜일까 싶은 생각이 들었다. 현재 테스트한 Vultr의 인스턴스는 CPU 1개짜리, 잘 되던 인스턴스는 CPU 2개짜리 였습니다. 잽싸게 떠놓은 Snapshot으로 CPU 2개짜리 인스턴스를 만들어서 테스트 해 봤고, 잘 작동하는 것을 확인했습니다.

그림 2. 크레온 플러스 API 연동을 위해 테스트해서 문제가 생기지 않은 머신

그렇다면 Gnome Boxes에서 CPU 개수를 1개로 바꾸면 문제가 재현될 수도 있겠다는 생각으로 테스트에 들어갔습니다.

Gnome Boxes의 VM CPU 개수를 1개로 변경해서 테스트

Gnome Boxes에서 CPU를 1개로 변경하고, 재부팅 한 후 동일한 코드를 실행했습니다.

VULTR 인스턴스에서와 동일한 문제가 재현됐습니다. 확인 차 다시 CPU를 2개로 변경하자, 아무 문제를 일으키지 않고 코드가 정상 작동했습니다.

결론

결론을 정리해 보겠습니다.

문제의 원인: AOS

Creon Plus에서 사용하는 AhnLAB의 AOS는 CPU 개수가 1개인 머신에서 크레온 플러스의 IsConnect 값을 얻어오는 과정에서 문제를 일으킵니다.

가상머신이나 클라우드 서비스와 Creon Plus API를 실행하는 것 간에 IsConnect 값 얻는데 문제가 생기는 상관관계가 있는 게 아닙니다.

해결 방법: CPU 개수

CREON PLUS API를 이용하는 머신은 실제머신이든 가상머신이든 간에 반드시 CPU 2개 이상이어야 AOS 작동에 문제가 생기지 않습니다.