AutoLISP으로 수치 입력창을 만들면 화면 정의는 보통 별도의 DCL 파일에 둡니다. 그런데 이 구조에는 오래된 골칫거리가 하나 있습니다. 명령을 실행할 때마다 도구가 그 DCL 파일을 못 찾아 "파일을 찾을 수 없습니다"를 내뱉습니다. 도면 작도 도구를 만들며 이 문제가 여러 버전에 걸쳐 재발했고 결국 DCL 파일 자체를 없애는 방향으로 풀었습니다. 그 과정을 정리합니다.
findfile은 검색 경로에 매여 있다
문제의 뿌리는 파일을 찾는 방식에 있습니다. 보통 DCL은 findfile로 찾는데, 이 함수는 CAD에 등록된 지원 파일 검색 경로 안에서만 파일을 뒤집니다. 사용자가 APPLOAD로 LISP을 로드할 때 전체 경로를 직접 지정해 아무 폴더에서나 불러오면, 그 폴더는 검색 경로에 없습니다. 결과적으로 LISP은 로드됐지만 옆에 있는 DCL은 찾지 못합니다.
그때마다 도구는 사용자에게 파일을 직접 고르라고 파일 선택창을 띄워야 했습니다. 명령 한 번 쓰려는데 매번 DCL 파일을 손으로 골라야 한다면 자동화라고 부르기 민망합니다. 검색 경로에 폴더를 추가하라고 안내하는 방법도 있지만 실무자에게 CAD 설정을 바꾸라고 요구하는 것 자체가 도구의 문턱을 높입니다.
파일을 찾지 못하게 하는 대신 파일을 없앤다
이런저런 우회를 시도하다 발상을 바꿨습니다. 파일을 더 잘 찾게 만드는 대신, 찾을 파일이 아예 없게 만들기로 했습니다. DCL 정의를 별도 파일로 두지 않고 LISP 코드 안에 문자열로 심었습니다. 그리고 명령을 실행하는 순간, 심어 둔 DCL 내용을 쓰기 가능한 임시 폴더에 파일로 추출한 뒤 그 경로를 입력창 로더에 넘깁니다.
이렇게 하면 배포하는 파일에 DCL이 따로 존재하지 않습니다. 찾을 파일이 없으니 못 찾을 일도 없습니다. 사용자가 LISP을 어느 폴더에서 로드하든, 검색 경로에 무엇이 등록돼 있든 상관없이 입력창이 매번 같은 방식으로 열립니다. "파일을 찾을 수 없습니다"라는 안내가 구조적으로 나올 수 없게 됐습니다.
임시 폴더 찾기도 만만치 않다
추출 방식에도 함정이 있었습니다. DCL을 추출할 쓰기 가능한 폴더를 확보해야 하는데, 임시 폴더 경로를 얻는 표준 방법이 CAD 환경에 따라 동작하지 않을 수 있습니다. 그래서 폴더를 얻는 경로도 여러 후보를 순서대로 시도하도록 했습니다. 한 방법이 실패하면 다음 방법으로 넘어가고 그래도 안 되면 마지막 기본 경로로 떨어집니다.
파일을 쓰고 읽는 모든 과정도 실패를 감지하는 방어막으로 감쌌습니다. 추출이 어떤 이유로 막히면 크래시로 이어지는 대신, 예전의 파일 탐색 방식으로 조용히 물러서게 했습니다. 개발 환경처럼 DCL 파일이 실제로 있는 경우에는 굳이 추출하지 않고 그 파일을 그대로 쓰도록 분기해 배포 형태와 개발 형태가 같은 코드로 돌아가게 했습니다.
하나의 파일로 배포하다
내장 방식은 배포 형태와도 맞물립니다. 여러 모듈로 나눠 개발한 소스를 빌드 단계에서 하나의 LISP 파일로 합치는데, DCL까지 그 안에 심으니 최종 납품물이 파일 하나로 정리됩니다. 실무자는 파일 하나만 APPLOAD로 로드하면 되고 함께 둬야 할 부속 파일이 없으니 "어느 파일을 어디에 둬야 하나요" 같은 질문도 사라집니다.
작은 결정 같지만 체감은 컸습니다. 도구를 처음 받은 사람이 설정이나 파일 배치로 헤매지 않고 바로 쓰기 시작한다는 것은, 자동화 도구가 실무에 안착하는 첫 관문을 통과했다는 뜻입니다. 여러 CAD 환경에서 파일 하나로 예측 가능하게 도는 것은 이 도구 설계의 일관된 지향이었습니다.
두 CAD 환경 차이를 흡수하는 전체 설계는 AutoCAD와 CADian 양립 설계에서, 한글 환경의 파일 인코딩 처리는 한글 CAD 환경의 인코딩 함정에서 이어집니다. 이 도구의 전체 사례는 AutoCAD 도면 작도 자동화 도구에서 볼 수 있습니다.
자주 묻는 질문
DCL 파일을 왜 자주 못 찾나요?
DCL을 찾는 findfile은 CAD에 등록된 지원 파일 검색 경로 안에서만 파일을 찾습니다. 사용자가 APPLOAD로 임의 폴더의 LISP을 전체 경로로 로드하면 그 폴더가 검색 경로에 없어 LISP은 로드돼도 옆의 DCL은 찾지 못합니다. 검색 경로에 의존하는 구조 자체가 문제의 원인입니다.
내장 DCL 방식은 어떻게 동작하나요?
DCL 정의를 별도 파일 대신 LISP 코드 안에 문자열로 심어 두고 명령 실행 시 그 내용을 쓰기 가능한 임시 폴더에 파일로 추출한 뒤 그 경로로 입력창을 엽니다. 배포 파일에 찾을 DCL이 없으니 "파일을 찾을 수 없습니다"가 구조적으로 발생하지 않습니다.
추출이 실패하면 어떻게 되나요?
임시 폴더 경로 확보와 파일 입출력을 모두 실패 감지 방어막으로 감쌌습니다. 추출이 어떤 이유로 막히면 크래시 대신 예전의 파일 탐색 방식으로 조용히 물러섭니다. DCL 파일이 실제로 존재하는 개발 환경에서는 추출 없이 그 파일을 그대로 사용하도록 분기했습니다.