회사 동료가, 수백 개의 작은 그림 파일들을 엑셀을 써서 카탈로그처럼 일목요연한 표 모양으로 한데 정리해야 할 일이 있었습니다. 그 많은 그림들을 일일이 Alt+I, P, F로 삽입하는 건 사람이 할 짓이 못 되었기에 프로그래밍을 할 줄 아는 제가 좀 도와 줬습니다. 셀마다 각 파일들을 이미지로 담고 있는 HTML 표 코드를 생성하는 프로그램을 짠 후, 그 표를 엑셀에서 import하는 방법을 썼지요.

쉘 스크립트라든가 하다못해 엑셀의 매크로를 능숙하게 다루는 분이라면 더 쉬운 방법으로 이 문제를 해결했을지 모르나, 저는 그런 지식은 없었기 때문에 이런 일까지 비주얼 C++을 동원해서 해결했습니다.
그런데 문제는 다음부터였습니다. 이렇게 만든 엑셀 문서는 다른 컴퓨터에서는 그림이 보이지 않았습니다. 그림이 문서에 완전히 내장(embed; by value)되지 않고 링크만 저장되었던 것입니다(by reference).

저는 굉장히 당황하지 않을 수 없었습니다. 원래 MS 오피스의 제품에서 그림을 자체 기능으로 삽입하면, 그림은 기본적으로 문서에 완전히 내장됩니다. 링크라는 개념 자체가 사실상 없는 걸로 저는 알고 있었습니다.

그림을 주로 링크로 취급하던 대표적인 프로그램이 과거 아래아한글이었지요. 그래도 얘는 링크가 깨지면 그림이 있는 경로를 다시 묻기라도 했으며, 3.0부터는 그림을 문서 안에다 내장하는 기능도 추가되었습니다. 그림을 링크만 할지 문서에 내장시킬지를 얼마든지 쉽게 지정할 수 있으며, 한번 그렇게 한 후에도 한 상태로 된 그림을 다른 상태로 전환 역시 얼마든지 할 수 있습니다. 그렇기 때문에 전혀 어려울 게 없었습니다.

xlsx의 내부 구조를 들여다보고는 저는 기겁을 하고 말았습니다. 압축 파일 내부의 media 디렉터리에 아무 파일도 없는 걸로 보아 내장이 안 된 건 확실했는데, 이놈의 링크는 또 C:\로 시작하는 완전 절대 경로로 저장되더군요! 이런 이유로 인해, 상대방 컴퓨터에다가 그냥 그림 파일만 던져 준다고 해서 그림을 볼 수 있는 것도 아니며, 디렉터리 구조까지 완전히 일치해야 했습니다.

진짜로 문서 내부에 내장된 그림과, 이렇게 링크만 달랑 걸린 그림이 제각기 어떤 방식으로 저장되는지는 파악할 수 있었습니다만, 엑셀 프로그램 내부에서는, 아래아한글처럼 어떤 그림이 링크인지 내장인지 알려주거나 그 속성을 바꾸는 기능은 아무리 눈을 씻고 찾아 봐도 없었습니다! 이거 뭐 나더러 어쩌라고?

한국어 검색 엔진으로는 이런 문제에 대한 해결책도 거의 찾을 수 없어서 구글에게 영어 검색어로 의뢰를 해 봤지요. 통상 구글링을 해 보면 여러 해외 IT 분야 '지식인' 내지 포럼 사이트들이 검색되는 게 있습니다. 그런데 네이버 지식인 류와는 또 다른 게, 질문만 쏙 보여주고서 답변을 보려면 결제 내지 최소한 회원 가입은 해야 하는 형태인 게 많습니다. 딱 본인처럼, 그림이 들어간 HTM 표를 엑셀로 가져왔다가 나중에 낭패 본 케이스가 하나 있긴 했는데 답변을 보지는 못했습니다. 썅~

그래서 다음으로 생각해 본 방법은, xlsx의 내부 xml 코드를 고쳐서 문서 내부의 '링크 그림'을 '완전 삽입 그림'으로 인위적으로 수정하고 media 폴더에다 강제로 그림 파일도 추가한 후, 이를 다시 zip으로 압축하는 것이었습니다. 오랜만에 OpenXML 덕을 좀 보는가 싶었는데...

문제는 이 방법마저도 통하지 않았습니다. 압축을 푼 내부 구성 파일을 수정 없이 그대로 빵집 같은 유틸로 재압축만 했는데도, 엑셀은 오류가 있다면서 그 압축(=xlsx) 파일을 읽어들이길 거부한 것입니다. xlsx뿐만 아니라, 오피스 2007 SP2에서 추가된 OpenDocument (역시 xml+zip 기반) 방식 역시 마찬가지. 얘네들은 zip 압축이긴 하지만, 일반 압축 유틸리티가 생성하지 않는 메타 정보도 같이 집어넣는 것 같습니다. 이쯤 되니까 진짜 꽤 열받기 시작했죠. MS 제품이 이 정도로 개념 없는 줄은 몰랐는데.

또 한 30분을 삽질하다가 꽤 허무하게 문제를 해결은 했습니다.
htm 문서를 파일-열기로 열면 그림이 링크로 삽입되는 반면, 웹브라우저에서 이 htm을 연 것을 Ctrl+C로 복사하여 엑셀에다 붙여넣으면, 그 그림들은 완전히 내장으로 삽입된다는 것을 알게 되었기 때문입니다. 아놔~ ㅁㄴㅇㄹ

MS 제품과 아래아한글 사이의 넘사벽 이질감을 또 확인하는 계기였습니다. 이놈의 MS 제품들은 내가 문서라든가 프로그램의 내부를 확실하게 제어(under my control)한다는 느낌을 주질 않고 제멋대로 붕 뜬 상태로 알아서 하다가, 그걸 응용/변형해야 할 상황이 생길 때 사람 완전 낭패 보게 만듭니다. 좋게 말하면 당장 사용하고 결과물 만들기엔 편한 것이고, 나쁘게 말하면 사용자를 바보 만들고 일정 실력 이상은 오르는 게 거의 불가능하게 돼 있는, 좀 사악한(?) 기능 디자인이 아닐까 싶습니다.

MS 워드도 97 시절부터 10년을 넘게 써 왔지만 개요/스타일이라든가 특히 개체를 배치하는 방식에 대해, 저는 독학만으로는 절대 완전히 적응 못 하겠다는 결론을 내리고 포기했습니다. 그 반면 아래아한글은 97은 물론이고 워디안/2002 급 이후 버전도 손에 착 잘 맞는 편입니다. MS 워드에만 있던 고급 기능을 아래아한글 특유의 세밀한 스타일로 잘 배치했다는 점은 인정합니다. 지금도 아래아한글이 기술적으로 워드에게 뒤지는 면모는 있으나, 아래아한글에도 MS 워드가 절대로 흉내낼 수 없는 디자인 상의 안정성과 편안함이 있습니다. (민족주의에 호소하는 한글 표현 같은 것 말고요. 한글 표현마저도 엄밀히 말하면 오히려 MS 워드가 좀더 앞서 있습니다.)

사실 이런 비슷한 느낌은 프로그래밍 언어를 쓰면서도 받습니다. C/C++ 이외의 언어, 특히 type이 굉장히 느슨한 언어로 코딩하다 보면 이 개체가 과연 value로 전달되는지, reference로 전달되는지, new만 있고 delete가 없는 언어들은 도대체 언제 이 개체가 garbage collect되어 소멸되는지?
내가 짜는 건 한 줄이지만 이게 내부적으로 어떤 알고리즘으로 구현되며 데이터가 100개가 아니라 10만 개가 넘어가면 성능이 어떻게 될지?
이런 게 신경쓰여서 불안해서 코딩이 잘 되지 않는 경우가 있습니다. 나와 언어가 일심동체가 못 되고 붕 떠 있는 느낌.

그런 상위 계층 언어들이 how보다 what을 중시하게 하고, 익숙해질 경우 생산성은 더 뛰어난 것은 사실이나 저는 C/C++스러운 저수준 면모가 더 마음에 들고 편안하더군요.

Posted by 사무엘

2010/01/11 09:46 2010/01/11 09:46
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/68

Trackback URL : http://moogi.new21.org/tc/trackback/68

Leave a comment
« Previous : 1 : ... 1751 : 1752 : 1753 : 1754 : 1755 : 1756 : 1757 : 1758 : 1759 : ... 1813 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/10   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Site Stats

Total hits:
1674012
Today:
296
Yesterday:
833