IDL/General

외부 라이브러리의 사용 및 관리에 대하여

이상우_IDL 2018. 3. 2. 16:54
728x90

오늘은 IDL에서 외부 라이브러리를 사용하고 관리하는데 있어서 필요할만한 내용들을 다뤄보고자 합니다. 사실 이 부분에 있어서 어떤 절대적인 규칙이 존재하는 것은 아니지만, 그냥 제 경험을 토대로 바람직하다고 생각하는 방향에 대해서 언급을 해보겠습니다. 따라서 참고 정도로만 받아들이시면 될 것 같습니다.


IDL에서 사용 가능한 기능들은 각각 이름이 다 있습니다. PRINT, PLOT, HELP, MEAN, FLTARR 등등 수많은 기능들이 존재하는데, 사실 이런 기능들은 각각 하나의 프로그램입니다. 프로그램이란 얘기는 뭔가 특정한 컴퓨터 언어로 작성된 것이라는 뜻도 됩니다. IDL에서지원되는 각 기능을 수행하는 프로그램들은 C++ 또는 IDL로 만들어져 있습니다. 제가 예전에 올렸던 한 게시물(아래 링크)에서 이와 연관된 언급을 했던 적이 있으므로 한번 참조해보시면 좋을 것 같습니다.


링크 누르기


그런데 C++로 제작된 프로그램은 일반 유저는 볼 수 없는 반면, IDL로 제작된 프로그램은 일반 유저도 볼 수 있습니다. 즉 IDL에서 사용 가능한 기본 기능인데 IDL로 제작된 프로그램인 경우, 이 프로그램들을 일반 유저들도 직접 볼 수 있다는 얘기입니다. 이러한 프로그램들은 IDL이 설치된 디렉토리 내에서 lib라는 디렉토리 내에 존재합니다. 이 디렉토리를 실제로 한번 확인해보면, 수많은 .pro 파일들이 모여있는 것을 볼 수 있습니다. 물론 이 안에도 graphics와 같은 하위 디렉토리도 있는데, 이 안에도 여러 종류의 .pro 파일들이 존재합니다. 어쨌든 이 모든 .pro 파일의 이름들이 바로 IDL에서 즉시 사용 가능한 명령들입니다.


실제로 IDL이 실행되면 이 lib 디렉토리에 존재하는 모든 .pro 파일들을 무조건 다 컴파일합니다. 즉 IDL에서 이 명령들이 즉시 사용 가능하도록 준비를 시켜둔다는 의미입니다. 당연한 얘기지만 이 lib 디렉토리를 지우면 안되겠죠. 만약에 그렇게 할 경우에는 lib 안에 있는 기능들을 통째로 못쓰게 됩니다. 그런 일이 벌어져서는 안되겠지요. 그런데 또 다른 측면을 본다면, 유저가 직접 만든 IDL 프로그램 또는 다른 곳에서 받은 IDL 프로그램을 이lib 디렉토리에 카피해두게 되면, 그 프로그램은 IDL이 시작될 때마다 항상 바로바로 사용이 가능하게 됩니다. 즉 커스텀 프로그램을 마치 IDL의 기본 기능인 것처럼 사용하는 것도 가능하단 얘기입니다. 사실 이러한 편의성(?) 때문에 이와 같이 lib 디렉토리 내에 여러가지 커스텀 프로그램들을 넣어두고 IDL을 사용하는 유저들도 꽤 있는 것으로 알고 있습니다.


그런데 이 부분에 관해서 저는 개인적으로, IDL의 lib 디렉토리는 가급적 건드리지 않는 것이 바람직하다는 말씀을 드리고 싶습니다. 몇가지 이유가 있습니다. 첫번째는 lib 디렉토리 안에 커스텀 프로그램들을 넣어두는 일이 잦아져서 그 갯수가 늘어가게 될 경우, 기본 기능과 커스텀 기능 사이의 구분이 힘들어지게 될 위험성이 크다는 것입니다. 이러한 부분은 다른 유저들과 프로그램을 공유하고자 할 경우 특히 문제가 될 수 있습니다. 예를 들어, 내가 만든 a.pro라는 프로그램이 내부적으로 b.pro, c.pro, d.pro라는 서브루틴들을 사용하는데, b.pro, c.pro는 IDL 기본 라이브러리에 있지만 d.pro는 외부에서 가져온 커스텀 프로그램일 경우를 생각해 봅시다. 이 경우 다른 유저에게 a.pro만 전달할 경우 그 유저는 이 프로그램을 제대로 사용할 수 없습니다. 당연히 d.pro도 함께 줘야 합니다. 그런데 많은 일을 하고 많은 프로그램들을 만들어 넣어두다보면, 이러한 관계를 항상 기억해두는 것이 힘들 수도 있습니다. 물론 lib 디렉토리 안에 별도의 하위 디렉토리를 만들어서 이 안에 커스텀 프로그램들을 모아두면, 이러한 혼란을 어느 정도는 방지할 수 있습니다.


두번째 이유는 이름의 중복 또는 대체로 인한 혼란의 위험성입니다. 기존에 lib 디렉토리 안에 있던 프로그램을 동일한 이름의 커스텀 프로그램으로 대체해버릴 경우, 기존의 프로그램이 수행해야 할 기능을 제대로 사용할 수 없게 됩니다. 예를 들어 평균값을 계산하는 역할을 하는 MEAN 함수에 대응되는 mean.pro라는 프로그램 파일이 lib 디렉토리 안에 원래 있는데, 전혀 다른 기능을 수행하지만 이름은 똑같은 파일로 대체해버릴 경우, 원래의 mean.pro의 기능이 작동되지 않고 따라서 IDL에서 MEAN 함수를 더 이상 제대로 사용할 수 없게 됩니다. 사실 이런 경우가 잘 없을 것 같아 보이지만 실제로 존재합니다. 사람의 심리라는 것이 다 비슷해서, 어떤 프로그램을 새로 만들 때 이름을 짓는데 있어서 직관적이고 일반적인 방향으로 가다보면 의도치않게 유사한 이름의 프로그램을 만들게 되는 경우가 있습니다. 여기까지는 좋은데, 이런 프로그램을 기존 프로그램과 바꿔버리면 안되겠지요. 물론 이러한 상황은 누가 먼저 또는 누가 우선이냐의 문제도 있습니다.


좋은 예가 바로 colorbar입니다. 올드 유저들께서는 이 뒷얘기를 아실 수도 있겠지만 모르시는 분들도 많을 것 같아서 그 히스토리를 좀 말씀드려 보겠습니다. 예전(정확히는 2010년도 이전)의 IDL에서는 colorbar라는 기능이 기본 라이브러리에 없었습니다. 따라서 컬러바의 표출을 위한 colorbar.pro라는 프로그램을 David Fanning이 만들어서 Coyote 라이브러리에 넣어서 배포를 했었고, 많은 IDL 유저들이 이 프로그램을 받아서 편리하게 사용을 했었습니다. 그런데 2010년도 IDL 8.0이 나오면서부터 갑자기 이 colorbar 기능이 정상적으로 작동하지 않는 문제가 발생하기 시작했습니다. 그 이유는 바로 IDL 8.0의 New Graphics 체계에서 컬러바 표출 기능을 지원하는 프로그램이 colorbar.pro라는 이름으로 lib 디렉토리 내에 존재하기 시작했기 때문입니다. 따라서 기존에 Coyote 라이브러리 프로그램들을 받아서 그 디렉토리를 추가 경로로 설정한 상태에서, colorbar.pro라는 동명의 프로그램이 충돌하게 되는데, 이러한 경우 IDL은 무조건 lib 디렉토리에 있는 파일에 우선권을 주게 됩니다. 따라서 IDL 8.0부터는 Coyote 라이브러리의 colorbar 기능을 정상적으로 사용할 수 없게 되었습니다. 실제로 그 당시 이러한 문제에 대한 문의가 국내외적으로 많이 있었습니다. 바람직한 해결책은 결국 외부 라이브러리인 Coyote 라이브러리의 colorbar.pro의 이름을 변경해서 사용하는 것이겠지요. 기본 라이브러리를 훼손하지 않는 선에서 커스텀 기능도 정상적으로 사용하려면 이렇게 하는 것이 가장 바람직한 해결책입니다. 실제로 이러한 혼란 이후 David Fanning이 선택한 방법이 바로 주요 프로그램들의 이름을 모두 "cg"로 시작되도록 하는 것이었습니다. 특히 그래픽 관련된 프로그램들은 모두 이런 식으로 이름이 바뀌게 됩니다. 이렇게 해서 CG 라이브러리로 새롭게 대체되었습니다.


중간에 잡설이 들어가긴 했지만 어쨌든 위에서 언급한 두가지 이유 모두 기본적인 전제는, 기본 라이브러리의 기능을 온전하게 사용하면서 추가 커스텀 라이브러리의 기능도 온전하게 사용할 수 있어야 한다는 것입니다. 따라서 외부 라이브러리는 아예 별도의 디렉토리에 넣어둔 다음 경로 설정을 하는 방식으로 운용을 하는 것이 좋습니다. 이 방법 역시 제가 예전에 올린 관련 게시물(아래 링크)의 내용을 참조하시면 좋을 것 같습니다.


링크 누르기


물론 이렇게 별도 디렉토리로 관리하면서도, 혹시나 중복된 이름으로 인한 충돌은 없는지에 대한 확인 및 관리도 필요합니다. 만약 이름이 중복된 프로그램들이 존재할 경우에는 어느 하나가 무조건 우선 순위를 갖게 됩니다. 그 우선 순위의 기준은 경로에서 설정된 디렉토리들의 순서를 따릅니다. 이것은 IDL 프롬프트에서 !path라는 시스템 변수를 출력해보면 확인이 가능합니다. 다음과 같은 명령으로 출력된 디렉토리 목록에서 가장 먼저 등장하는 디렉토리에 있는 .pro 프로그램들이 우선 순위가 앞서게 됩니다.


IDL> print, !path


또는 다음과 같이 .edit 명령을 사용할 때 에디터 창에 뜨는 IDL 프로그램을 직접 확인하는 방법도 있습니다.


IDL> .edit mean.pro


따라서 기본 라이브러리 외에 외부 라이브러리를 많이 사용하는 유저들은, 위와 같은 방법들을 사용하여 기본 라이브러리 및 추가 라이브러리 프로그램들이 저장된 디렉토리들 사이의 우선 순위 관계를 파악해두는 것이 좋습니다. 그래야 혹시라도 발생할 수 있는 혼란에 대한 체계적인 진단이 가능합니다. 어차피 외부 라이브러리를 많이 사용하게 될 경우, 그 환경 자체가 다른 유저들 또는 다른 PC와는 다를 가능성이 큽니다. 따라서 내가 만든 프로그램이 외부 라이브러리 기능들을 많이 사용하는데, 이 프로그램을 나는 잘 쓰고 있는데 다른 컴퓨터에 설치된 IDL에서 실행하면 작동이 잘 안되는 경우들이 흔히 있습니다. 이럴 때에는 각 PC마다 외부 라이브러리 설치 및 사용 환경에 있어서 어떤 차이가 있는지를 확인하는 것이 필수입니다.


지금까지 설명해드린 내용들이 사실 좀 귀찮은 측면이 강한 것은 사실입니다. 하지만, 외부 라이브러리를 많이 사용해서 작업을 해야 할 경우에는 분명히 신경써야 할 부분들입니다. 그리고 이러한 부분에 대한 책임은 IDL 프로그래머 자신에게 있음을 염두에 두는 것도 필요하다고 봅니다.

LIST