한글 도면 환경에서 AutoLISP 도구를 만들 때 마지막까지 발목을 잡는 것은 로직이 아니라 인코딩입니다. 코드가 완벽해도 파일을 잘못된 문자 인코딩으로 저장하면 명령창의 한글 프롬프트가 깨지고 입력창의 한글 라벨이 뭉개지고 심하면 파일이 로드조차 되지 않습니다. 한글 CAD용 도구를 만들며 겪은 인코딩 함정과 그 해법을 정리합니다.
LISP과 DCL은 옛날 방식으로 글자를 읽는다
요즘 대부분의 개발 도구는 UTF-8을 기본으로 씁니다. 그런데 AutoLISP과 DCL은 사정이 다릅니다. 이들은 전통적으로 시스템의 코드 페이지에 의존해 글자를 해석합니다. 한글 윈도우 환경의 코드 페이지는 CP949, 즉 확장 완성형(EUC-KR 계열)입니다. 그래서 한글 주석이나 프롬프트, 텍스트가 들어간 LISP과 DCL 파일은 CP949로 저장해야 CAD가 한글을 제대로 읽습니다.
파일을 UTF-8로 저장하면 CAD는 그 바이트를 CP949로 해석하려다 한글을 엉뚱한 문자로 표시합니다. 특히 UTF-8 파일 맨 앞에 붙는 BOM이라는 표식은 더 위험합니다. LISP 로더가 이 표식을 코드의 일부로 오해해 파일 첫 줄부터 오류를 내거나 로드에 실패하기도 합니다. 그래서 이런 파일에는 UTF-8, 그중에서도 BOM이 붙은 UTF-8을 절대 쓰지 않는다는 규칙이 필요했습니다.
개발은 UTF-8, 배포는 CP949
그렇다고 개발 내내 CP949로 작업하는 것도 불편합니다. 요즘 편집기와 버전 관리 도구는 UTF-8을 전제로 돌아가서 소스를 CP949로 두면 도구 곳곳에서 마찰이 생깁니다. 그래서 둘을 분리했습니다. 개발은 UTF-8로 편하게 하고 배포용 파일을 만들 때 빌드 단계에서 CP949로 변환합니다.
빌드 과정은 여러 모듈로 나눠 짠 소스를 하나의 LISP 파일로 합치면서 그 결과물을 CP949 인코딩으로 출력합니다. 개발자는 평소처럼 UTF-8로 코드를 쓰고 형상별 로직을 여러 파일로 나눠 관리하지만 실무자에게 전달되는 최종 파일은 한글이 깨지지 않는 CP949 단일 파일이 됩니다. 인코딩 규칙을 사람이 매번 신경 쓰는 대신 빌드가 강제하도록 만들었습니다.
CSV 인코딩도 같은 함정을 판다
일괄 작도에 쓰는 CSV 파일에도 같은 문제가 따라옵니다. 재질이나 표제에 한글이 들어간 CSV를 엑셀에서 저장할 때 UTF-8로 내보내면, 도구가 파일을 CP949로 읽으면서 한글 셀이 깨집니다. 그래서 CSV도 CP949 계열로 저장하도록 안내하고 엑셀에서 저장할 때 어떤 형식을 골라야 하는지 문서에 구체적으로 적었습니다.
다만 재질 코드나 주문 번호처럼 값이 전부 영문과 숫자로만 이뤄진 경우에는 인코딩과 무관하게 정상 동작합니다. 그래서 함께 제공하는 예시 표는 한글 셀을 피하고 영문·숫자 값만 담아 사용자가 어떤 인코딩으로 저장하든 바로 돌아가게 했습니다. 인코딩을 이해하지 못하는 사용자도 예시를 그대로 채워 쓰면 문제가 없도록 한 배려입니다.
인코딩은 문서에 적어야 완성된다
인코딩 문제의 성가신 점은 눈에 잘 띄지 않는다는 것입니다. 개발자 컴퓨터에서는 멀쩡하던 한글이 고객 환경에서 깨지는 일이 흔하고 그 원인이 인코딩이라는 걸 짚기까지 시간이 걸립니다. 그래서 코드로 강제할 수 있는 부분은 빌드로 강제하고 사용자가 만지는 CSV처럼 강제할 수 없는 부분은 문서에 명확히 안내했습니다.
한글 환경을 지원한다는 것은 결국 이런 보이지 않는 디테일을 끝까지 챙긴다는 뜻입니다. 로직이 아무리 훌륭해도 한글 프롬프트가 깨지면 실무자에게는 그냥 고장 난 도구입니다. 인코딩을 마지막까지 신경 쓴 덕에 이 도구는 한글 도면 환경에서 깨짐 없이 자리 잡을 수 있었습니다.
배포 파일을 하나로 합치는 빌드는 DCL 못 찾음을 없앤 내장 DCL에서, 한글 셀이 섞인 CSV의 일괄 처리는 견고한 CSV 일괄 작도에서 이어집니다. 이 도구의 전체 사례는 AutoCAD 도면 작도 자동화 도구에서 볼 수 있습니다.
자주 묻는 질문
왜 LISP과 DCL을 CP949로 저장해야 하나요?
AutoLISP과 DCL은 UTF-8이 아니라 시스템 코드 페이지에 의존해 글자를 해석하는데, 한글 윈도우의 코드 페이지가 CP949입니다. 그래서 한글이 들어간 이 파일들을 CP949로 저장해야 명령창 프롬프트와 입력창 라벨의 한글이 깨지지 않습니다. 특히 BOM이 붙은 UTF-8은 로드 오류까지 낼 수 있어 피해야 합니다.
개발도 CP949로 해야 하나요?
그럴 필요는 없습니다. 요즘 편집기와 버전 관리 도구는 UTF-8을 전제로 하므로, 개발은 UTF-8로 편하게 하고 배포용 파일을 만드는 빌드 단계에서만 CP949로 변환하는 방식을 권합니다. 인코딩 규칙을 사람이 매번 챙기는 대신 빌드가 강제하게 하면 실수가 줄어듭니다.
CSV 파일은 어떤 인코딩으로 저장하나요?
한글 셀이 들어간 CSV는 CP949 계열로 저장해야 도구가 읽을 때 깨지지 않습니다. 다만 재질 코드나 주문 번호처럼 값이 영문과 숫자로만 이뤄졌다면 인코딩과 무관하게 정상 동작합니다. 그래서 예시 표는 영문·숫자 값만 담아 어떤 인코딩으로 저장하든 바로 쓸 수 있게 했습니다.