1.
엑셀에는 셀 안에다 긴 텍스트를 집어넣은 후, ‘자동 줄 바꿈(wrap text)’을 적용하여 내용이 여러 줄에 걸쳐서 출력되게 하는 기능이 있다.

그런데 이 기능은 굉장히 괴상하게 구현되어 있다. 엑셀이 제공하는 ‘자동 줄 바꿈’ 기능은 위지윅이 전혀 보장되지 않는다. 문서의 확대 배율만 바꿔도(셀이나 문서의 폭, 심지어 프로그램 창 크기도 아니고) wrap 결과가 뒤죽박죽으로 바뀌고, 화면으로 보는 결과와 인쇄 결과도 당연히 일치하지 않는다.

이런 이유로 인해 화면상으로는 3줄로 wrapping이 됐는데 인쇄해 보니 문장이 2줄에 다 들어가서 마지막 한 줄은 텅 비기도 하고, 화면상으로는 딱 맞는 크기였는데 인쇄하니까 칸이 부족하여 숫자가 ####로 바뀌어 출력되기도 한다. 엑셀을 직업적으로 다루는 분이라면 이런 특성에 대해 이미 잘 알고 있을 것이다.
이건 워드 프로세서라면 상상도 못 할 현상일 텐데, 왜 이런 것일까?

엑셀은 잘 알다시피 표 형태의 데이터를 전문적으로 다루는 프로그램이다. 워드 프로세서처럼 소숫점 단위로 위지윅을 보장하면서 정확한 페이지 정돈과 문단 정렬에 최적화되지는 않은 듯하다. 성능상의 이유로 인해 그냥 정수 픽셀 단위로 줄을 wrap하니, 화면 배율만 바꿔도 문단 정렬 결과가 확 달라지는 것이다. 글자 크기뿐만 아니라 셀의 크기까지 동일한 비율로 바뀌는데도 말이다.


2.
플래시 메모리 스틱으로 전파/감염되는 악성 코드는 정말 심각한 수준에 도달한 것 같다.
(카드는 아니고.. 플래시 메모리는 말이 좀 길고, 그렇다고 USB라고 부르는 건 너무 심했고-_-.. 적당한 말이 없어서 고민인데, 이 글에서는 편의상 그냥 스틱이라고 부르겠다.)

내 스틱을 남 컴퓨터에다 꽂았다가 다시 갖고 오니 루트 디렉터리에 지저분한 dll, bat-_- 파일이 묻어 있다거나, 남의 스틱을 내 컴에다 꽂아서 파일을 보니 역시 괴파일이 숨김 속성으로 들어있다.
당연히, 내 스틱을 내 컴퓨터들끼리만 쓰면 그런 현상 없다. 그런데 지금까지 저런 경우를 한두 번 본 게 아니어서.. 도대체 악성 코드에 감염된 컴퓨터가 얼마나 되는지 감을 못 잡겠다.

저게 어떻게 기술적으로 가능한지 궁금할 따름이다. 어떻게 나의 동의도 없이, 악성 코드에 감염된 컴에다 내 스틱을 꽂았다는 이유만으로 루트 디렉터리에 저런 파일들이 복사될 수 있을까?
옛날에도 글로 썼지만 본인은 컴퓨터 보안에 관한 한, 굉장한 안전 불감증의 소유자이다. 지금까지 단 한 번도 사고가 안 났지만, 사고가 났을 때의 대처 능력 역시 검증된 적이 없는 일본 신칸센과 같은 상태이다. 이러다가 소 잃고 외양간 고치려나..;;

구글이라든가 크롬 웹브라우저가 특히 국내 포털 사이트 내부에 대해서 "이 사이트는 안전하지 않습니다" 경고 내는 것도 굉장히 귀찮아하고 싫어한다. 잘만 드나들고 지냈으며, 그러고 나서도 아무 일도 없었는데 양치기 소년 같은 인상을 받기 때문이다. 첨부 파일, ActiveX 설치 절대 안 하는 사람에게 도대체 뭐가 안전하지 않다는 건지 모르겠다.

요즘도 하는지 모르겠는데, 생활 안전을 소재로 무슨 '에듀테인먼트' TV 프로가 있다.
헬멧을 썼을 때와 안 썼을 때 사람이 다치는 정도의 차이를 비롯해, 음식을 태운 냄비를 물로 식혀서는 안 되는 이유 등을 생생한 실험으로 보여주는데,
그것처럼 보안/업데이트를 전혀 하지 않은 컴퓨터가 어떻게 뚫리고 어떻게 악성 코드에 감염되는지 그런 실험 결과를 보여주는 TV 프로가 좀 있었으면 좋겠다. 나는 도무지 실감이 안 간다.

Posted by 사무엘

2010/03/23 10:15 2010/03/23 10:15
, ,
Response
No Trackback , 8 Comments
RSS :
http://moogi.new21.org/tc/rss/response/220

회사 동료가, 수백 개의 작은 그림 파일들을 엑셀을 써서 카탈로그처럼 일목요연한 표 모양으로 한데 정리해야 할 일이 있었습니다. 그 많은 그림들을 일일이 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


블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/09   »
    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      

Site Stats

Total hits:
1445356
Today:
99
Yesterday:
535