무료 프로그램인데 '먼저 다른 걸 설치하세요'라고 했다 — 177KB 도면이 600초 걸린 이유

오늘 배울 것 부품의 능력은 설명이 아니라 제가 실제로 열 파일로 잽니다.

결과부터 — 600초를 기다려도 안 열리던 도면이 0.01초에 읽혔어요

저는 무료 도면 프로그램을 만들고 있어요. 도면은 집이나 기계를 그린 설계도예요. 정확히는 CAD(캐드, 컴퓨터로 그리는 설계) 프로그램이 만든 그림 파일입니다.

그 프로그램에 오래된 흠이 있었어요. 작은 도면 하나가 안 열렸습니다. 용량은 177KB예요. 사진 한 장보다 작습니다. 그런데 600초를 기다려도 안 열렸어요.

원인은 용량이 아니었습니다. 제 프로그램이 쓰던 부품 하나가 요즘 기본 저장 형식을 아예 못 읽었어요. 남이 만들어 둔 부품(라이브러리)입니다. 그 부품을 다른 것으로 바꿔 끼웠습니다. 바꾼 부품은 같은 파일을 0.01초에 읽어 냈어요.

큰 파일도 같이 좋아졌습니다. 21.5MB에 도형 수십만 개가 든 실제 도면이에요. 전체 열기가 31.2초에서 7.3초로 줄었습니다.

그런데 가장 큰 변화는 속도가 아니었어요. 보통 쓰는 파일에서는 "다른 프로그램을 먼저 설치하세요"라는 안내가 뜨지 않게 된 겁니다.

그전까지 제 프로그램은 큰 도면을 만나면 남이 만든 변환 프로그램을 불렀어요. 그 프로그램은 제 설치본에 같이 넣을 수 없습니다. 따로 설치한 사람만 도면을 열 수 있었던 거예요. 무료라고 적어 놓고 "먼저 다른 걸 설치하세요"라고 말하는 상태였습니다.

이제 보통 쓰는 파일은 다른 프로그램 설치 없이 열립니다. 제 프로그램 하나만 깔면 되고, 그 설치본이 4.2MB예요. 다만 "완전히 없앴다"고는 못 씁니다. 내장 부품이 못 읽는 파일을 위한 비상 경로는 코드에 아직 남아 있어요.

왜 "파일이 크다"고 믿었나

8월 말에 제가 이렇게 말했어요. "아직도 변환중이라 강제 종료." 그래서 안전장치를 세웠습니다.

1. 파일 용량으로 길을 갈랐어요. 큰 파일은 다른 경로로 보냈습니다.

2. 변환에 시간 제한을 뒀어요.

3. 제한을 넘기면 외부 변환 프로그램으로 자동 전환했습니다.

셋 다 "파일이 크니까 느리다"는 짐작 위에 서 있었어요. 짐작은 그럴듯했습니다. 큰 파일은 실제로 느렸으니까요.

문제는 안전장치가 증상을 덮어 줬다는 점이에요. 자동 전환이 돌면 파일이 열리는 때가 있었습니다. 열리는 날에는 더 캐묻지 않았어요. 그 상태로 3주가 넘게 지났습니다.

축이 바뀐 건 제 질문 한 줄이었어요. "내장 엔진이 있다고 하지 않았어?" 내장 부품이 있다고 들었는데 왜 매번 남의 프로그램을 부르나 싶었습니다.

그래서 형식별로 다시 쟀어요. 결과는 분명했습니다. 옛 부품은 2000년식 저장 형식은 읽었어요. 그런데 2018년식에서 멈췄습니다. 2018년식은 널리 쓰이는 설계 프로그램 하나의 요즘 기본 저장 형식이에요. 실무 파일 대부분을 못 읽는 부품이었던 겁니다.

용량 축으로만 보면 끝까지 안 보이는 결론이었어요. 177KB도 못 읽었으니까요. 부품을 바꾸고 나니 용량으로 길을 가르던 장치는 쓸 이유가 없어졌습니다.

따라 하기 — 남의 부품을 내 파일로 재 보는 5단계

1. 내가 진짜 열 파일 한 개를 고릅니다. 남이 올려 둔 예제 파일이 아니라, 제 일에 실제로 쓰는 파일이어야 해요. 이렇게 보이면 성공 — 파일 이름과 용량을 적어 뒀다.

2. 그 파일의 판 번호를 봅니다. 확장자(파일 이름 끝의 꼬리표)가 같아도 저장 형식의 세대가 달라요. 같은 그림 파일에도 옛 형식과 새 형식이 있는 것과 비슷합니다. 이렇게 보이면 성공 — "2018년식"처럼 세대를 말로 적을 수 있다.

3. 부품만 따로 돌려 시간을 잽니다. 단계를 하나씩 끊어서 재요. 읽기·변환·화면 그리기를 한 번에 재면 어디가 느린지 모릅니다. 이렇게 보이면 성공 — 단계마다 숫자가 따로 나온다.

4. 안 끝나면 "느리다"가 아니라 "못 읽는다"로 적습니다. 그리고 같은 내용을 옛 형식으로 저장해 다시 재요. 옛 형식만 열리면 범인은 용량이 아니라 형식입니다. 이렇게 보이면 성공 — 형식을 바꾼 것만으로 결과가 갈린다.

5. 대안 부품을 같은 파일·같은 방법으로 잽니다. 배포 조건(라이선스)도 같이 봐요. 저는 부품을 바꾸면서 배포 조건도 느슨한 쪽으로 바뀌었습니다. 이렇게 보이면 성공 — 같은 파일의 숫자를 나란히 적은 표가 생긴다.

순서는 단순해요. 그런데 저는 이 순서를 3주 뒤에야 밟았습니다.

막히면 — 저는 두 번 잘못 쟀어요

제 실수를 그대로 적어 둡니다. 측정은 생각보다 쉽게 틀려요.

첫째, 비교 기준이 서로 달랐어요. "읽기만 하는 단계"와 "읽고 보완까지 하는 단계"를 맞대 놓고 봤습니다. 숫자가 안 맞으니 "환경 탓"이라고 결론 냈어요. 그 바람에 세 번의 작업 동안 숫자를 잘못 읽은 채로 갔습니다.

둘째, 명령을 한 줄에 이어 붙였어요. 명령 세 개를 세미콜론으로 붙여 한꺼번에 돌렸습니다. 출력이 섞여서 어느 단계의 숫자인지 알 수 없었어요. 느린 쪽은 두 번째 단계였는데 첫 단계 탓으로 봤습니다. 그래서 "안 끝난다"고 적었어요. 단계를 나눠 다시 재니 그 단계는 1초도 걸리지 않았습니다.

# 이렇게 한 줄에 붙여 재면 숫자가 섞인다 (모양만 보여 주는 예시)
단계1; 단계2; 단계3

# 하나씩 끊어 재면 느린 단계가 드러난다
단계1
단계2
단계3

두 실수의 모양은 같아요. 한 번에 뭉쳐서 쟀다는 것입니다.

부품의 능력은 "지원합니다"라는 설명이 아니라 제가 실제로 열 파일 한 개로 잽니다. 증상이 "크다·느리다"로 보일 때도 형식 축을 갈라 보세요. 그럴듯한 오진 위에 세운 안전장치가 다음 진단까지 가립니다.