2주 쯤 전, 경개 교수님께서 스페셜 프로젝트 파티를 준비한 그룹원에게 수고했다고 저녁을 사주셨다. 무려 일식집에서 회를 사주셨는데, 메뉴는 주땡이가 그냥 질러버린 것 같다. 애들과 저녁을 맛있게 먹고 다음으로는 와인바로 이동해서 교수님과 함께 이런 저런 이야기를 나누었는데,


뜬금 애들이 갑자기 교수님께 "식장산에서 야경을 보고 싶어요." 라고 말을 한다. 교수님 당황해 하신다. 교수님도 우리도 모두 9시에 수업이 있었기 때문에. 그리고 이 말이 나온 시각은 밤 11시. 식장산을 가기에는 늦은 시각이지만 애들이 너무 강력하게 조르는 바람에 교수님께서도 분위기에 떠밀려서 식장산에 가기로 결정하셨다.


그때까지만 해도 진짜로 갈 줄은 몰랐다. 아침 9시에 수업이 있는데 출발 할 때의 시각은 자정을 훨 넘었기 때문이다. 이럴 때 사진 한 번 안 찍으면 서운하다. 식장산으로 출발하기 전 길거리에서 기념 샷. 그리고 교수님 차로 이동.


무려 진짜로 식장산을 향해 출발 했다. 이미 자정을 넘긴 시각, 교수님도 우리도 오전 수업이 기다리고 있었지만 누구도 그것을 지금 상황에서 중요하게 생각하지는 않았다. 단지 이것도 '추억'이라는 강력한 합리화 작용으로 일단 계속 가는 것.


이렇게 식장산에 도착하니 시계는 벌써 한 시를 가리키고 있었다. 식장산에서 야경을 보고 별도 보면서 한 시간 정도 있다가 내려왔는데, 집에 도착하니 약 세시. 물론 다음날 아침에 교수님을 비롯 같이 갔던 학생들은 좀 힘들어 했다. 하지만, 이런 것이 또 대학생활의 소소한 재미가 아닐까 싶다. 교수님과 함께 이렇게 분위기를 타면서 지를 수 있다는 것도 재미있고.

살면서 여태껏 단 한 번도 오페라를 보러 간 적이 없었습니다. 일단 오페라는 매우 비싸다는 인식하나 때문에라도 감히 보러 갈 엄두조차 내기 어려웠다고 할까요? 그래서 오페라 자체는 가끔 DVD나 음악으로만 접했던 것이 전부입니다. 그러던 중 예술의 전당에서 '카르멘'을 한다는 소식을 들었습니다. 꼭 보고 싶었던 오페라인데다가 간만에 '10,000원'이라는 파격적인 가격에 모시고 있고 같이 보러 가자는 친구도 있어서 다녀왔습니다.

1845년 메리메라는 사람이 지은 장편 소설을 바탕으로 1865년 비제라는 작곡가에 의해 초연된 카르멘. 아주 시니컬하게 대충 한 문장으로 줄거리를 요약하자면 '한 남자가 여자에게 잘못 홀려서 인생 말아먹는다.'라는 내용입니다. 탈영이라든가 밀수 등을 다룬 카르멘의 내용은 당시 프랑스의 배경을 생각하면 아주 파격적이었다고 하지요. 비제라는 작곡가는 37살의 나이에(1875년) 사망했다고 하는데, 참 젊은 나이에 천재적인 결과를 내고 또 일찍 죽어서 안타깝기도 합니다.

카르멘 3번 간주곡은 제가 아주 좋아하는 곡이기도 합니다만(폴모리아 버전으로), 특히 투우사의 노래는 모르는 사람이 없을 만큼 유명한 곡이기도 하지요. 그 곡을 오케스트라의 웅장함과 함께 들었으면 좋았겠지만, 10,000원 오페라의 특성상 '일렉트릭'으로 들었던 것이 좀 아쉽긴 했습니다. 그러나 카르멘의 내용이며 배우의 연기와 노래가 상대적으로 빈약했던 구석을 채워줘서 다행이더군요. 이걸 진짜 제대로 볼 기회가 꼭 다시 한 번 있었으면 좋겠다는 생각을 했습니다.

그나저나 원래 내용으로는 카르멘에게 버림당한 돈 호세가 카르멘을 죽이고, 자기도 죽은 카르멘 옆에서 같이 죽는 것이 결말이라고 하던데, 제가 본 카르멘 오페라에서는 호세가 카르멘을 죽이고도 자기는 죽지 않았습니다. '왜 그랬을까?' 싶네요.

부활절. 인간의 죄를 사하시려고 세상에 직접 오셔서 죽임당하시고 부활하신 예수님을 기념하고 그 의미를 되새기는 날입니다. '부활'이라는 의미를 '부화'에 담아서 계란을 나누어 주는 것이 하나의 풍습이 되었지요. 오늘 계란 하나쯤은 받으셨죠?

요즘에는 계란을 이렇게 래핑해서 나눠 주더군요. 어릴 때는 계란에 색칠도 하고 만들기도 했는데 요즘에는 그러지 못하는 것이 아쉽더군요. 그러고 보면 요즘엔 삶은 계란을 받는 것도 그다지 반가운 일은 아닌 것 같습니다. 예전에는 예수님을 믿지 않는 사람도 계란 받으러 부활절에 교회에 갔었다던데. ... 요즘엔 아이템 준다고 하면 오려나?

어쨌거나, 부활에서 다른 무엇보다 예수님의 '사랑'과 '영광'을 생각하고 또 그 의미를 새길 수 있었으면 합니다. Happy easter~!!

daum 만화를 즐기시는 분이라면 대부분 알 만한 강풀의 '바보'.
영화로 나왔다고 하기에 '절대로 안 봐야겠다.'라고 생각 했지요.
'강풀의 만화를 원작으로 하면 아무리 잘 만들어도 별로겠다.' 싶은게
극장을 지나가면서도 '사람들이 보기는 할까?'라는 생각이 들더군요.

주연인 차태현의 이미지가 코믹영화를 주로 했던 배우라 그런지
'바보를 연기한다기 보다는 푼수를 연기하지는 않을까?'라는 마음도 있었고
스토리 자체가 영화로 만들기에는 좀 복잡한 면도 있을 것 같았죠.
그랬었는데, 주변에 '바보'를 보고 싶어하는 분이 있더군요. (남자 ㄱ-)
영화표까지 친히 끊어주면서 같이 영화를 보자고 하길래 덥썩.

네... 강풀은 정말 만화를 참 잘 만드는 것 같습니다.

올림픽 여자 핸드볼 대표팀 이야기를 바탕으로 만들었다는 '우리 생애 최고의 순간'.
영화의 많은 이야기와 등장하는 인물들이 실제의 그것과는 다르다고는 하지만
그렇다고 모든 것이 허구와 과장이 없는 실제의 이야기일 필요는 없는 거지요.

'와이키키 브라더스'로 유명한 임순례 감독의 영화라 관심을 가지고 있었고,
또 우리나라 최고의 여배우라고 하는 문소리, 김정은의 출연은 더욱 기대 되더군요.
그런차에 주말에 우연찮게 영화를 볼 기회가 생겨서 이 영화를 보았습니다.
물론 제가 영화를 선택하지는 않았습니다. 저는 별로 힘이 없어서~

세세한 내용과 평가야 제 블로그가 아니라도 많은 곳에 있으니 생략하고
간단한 평만 하자면 '약간의 오버센스가 아쉬운 잘 만든 영화' 같습니다.
전체적으로는 잔잔한 전개에 적절한 재미가 섞어 구조도 나쁘지 않았구요.
역시 임순례 감독의 영화 답게 약간의 메시지도 담긴 했더군요.

하지만 욕심이 과했을까요?
너무 극적 요소를 많이 넣어서 그런지 관객을 좀 지치게 만드는 것 같긴 합니다.
영화 주제가 말해주듯 영화 자체가 너무 감동을 강조하다 보니
처음 볼 때는 '그렇구나..'하면서 넘어갈 수 있겠지만
두 번 정도 보면 허풍이 드러나서 보기 힘들 것 같은 영화라 해얄까요..

하지만 아테네 올림픽 은메달에 그친 그 아쉬움 때문에 해피엔딩이 될 수 없는 상황을
(스포일이 있어서 내용은 언급하지 않겠습니다) 자연스럽고 강하게 마무리 지어서
전체적인 영화가 어색해지지 않도록 한 것은 정말 센스있다는 생각이 들었습니다.

좀 늦긴 했지만 '우리 생애 최고의 순간'을 보러 가실 분은
가벼운 마음으로 팝콘하나 들고 가면 딱 좋겠다 싶더군요.

그나저나 우리의 복길이 누님은 영화에서 보면
완전 악바리 아줌마가 다 되었어요. ㅠ_ㅠ

(사실 왜 모자이크를 했는지 저도 모르겠습니다) 늦은 밤 마트에서 요구르트를 샀더랬죠. 위에 있는 사진을 잘 보면 '치아를 위한 성분 함유', '자일리톨 함유' 라고 되어있습니다. 아무래도 요구르트안에 있는 자일리톨을 치아를 위한 성분이라고 하는 것이겠지요? 어쨌든 한번 뒤로 돌려서 또 잘 들여다 봅시다.


엄머나~! 제품 성분에 포도당과 액상과당이 있네요. 그럼 자일리톨은 왜 넣었을까요? 아무리 생각을 해봐도 잘 모르겠네요. 요새 자일리톨 생산량이 늘었나. '치아를 위한 성분은 들었으나 치아에 도움이 될지는 모르겠습니다' 라고 말해주고 싶군요.

보안솔루션... 기업을 포함한 조직의 자산들을 외부인 뿐만 아니라 내부인으로 부터 그 유출을 방지하기 위해 만드는 솔루션이라고들 말한다. 물리적으로는 CCTV 도 하나의 방법이 될 수 있겠고, 카드키 인증 시스템 역시 이런것중의 하나라고 생각 한다. 하지만 요즘에는 거의 모든 업무가 전산화 되어있고, Internet 의 발전으로 007, Mission Impossible 과 같은 영화처럼 엄청난 스릴을 요구하지 않고도, 간단히 FTP 등의 Web Service 를 통해 전송하면 그만인 정보들도 많다.

PC 에서 일어나는 정보유출 혹은 악의적인 Cracking 을 방지하기 위해서는 각 개인의 컴퓨터에 필요에 따른 프로그램을 설치하게 되는데, 왠지 이 프로그램은 무고한 일반 회사원들에게는 참으로 기분나쁘고 귀찮은 소프트웨어이다. '이 회사는 구성원들을 죄다 도둑놈으로 아나...' 라는 생각은 물론이고 어떻게든 그런 프로그램은 시스템 자원을 차지하게 되므로 정말 '지우고 싶은 프로그램 1순위'에 오를 수 있는것이다.

내가 게임 관련 보안 소프트웨어 제작을 책임 했을때에도 똑같은 절차를 밟았던 것으로 기억한다. 유저들이 가드캣을 반가워 하리라는 생각은 전혀 하지 않았긴 했지만 예상보다 많은 반발과 항의가 있었던 것인데 자잘한 버그의 문제도 있겠지만 어쨌든 자신이 잘 사용하고 있는 Third Party Tool 들이 잘 동작하지 않았기 때문에 더더욱 그랬었던것 같다. 사실 이런 소프트웨어도 어떤 의미에서 보면 '유저들로 부터 타 유저의 비매너 행위를 차단하는' 것이기 때문에 결국 그 수혜자는 자신이 되는것이지만 유저들은 그렇게 까지 생각해 줄 어떠한 이유도 없다. 요즘 나름 보안 솔루션 하나를 제작하면서 적지않은 고민을 한다. 내부보안솔루션은 어떻게든 아래와 같은사항을 필수로 하고 있기 때문이다.

1. 설치 되었다는것을 떠 벌리듯 노출 안시키는 간단한 인터페이스.
2. 최대한 분산시키고 동적으로 로딩하라. 그래서 리소스를 보호하라.
3. 모든 기능에 대해 투명화 작업을 거쳐라. 숨은 기능을 넣지 말고
4. 적절한 모니터를 만들어서 현재 어떤 기능이 동작중인지 알린다.
5. 오류를 그 어떤 프로그램보다 치밀하게 분석하여 최대한으로 줄인다.
6. 핫픽스를 비롯한 신속한 사후관리를 위한 업데이트 기능은 필수.

이것들은 또 무엇을 뜻하는가. 개발 기간의 장기화를 뜻한다. 한가지 기능을 투입하는데 있어서 다른때 보다 더 치밀한 QA 과정을 통과해야 한다는 것도 있다. 특히 짜임새 없는 QA 는 개발자와 사용자에게 모두 좋지 않은 추억으로 남게 된다. 나는 보안 소프트웨어의 제작에 있어서 발견되는 버그에 대해서는 개발자의 책임보다는 검수자 혹은 테스터에게 조금 더 많은 책임을 묻는편이다. 보안 소프트웨어 관련쪽을 개발해 본 사람은 공감하리라. 짜여진 일정 내에서 버그를 내지 않는것은 정말 어려운일이기 때문이다. (물론, 일정을 제대로 짜야하는 매니저의 잘못도 무시 못하지만 매니저가 생각하는데로 일정을 짜게 된다면 그 시간에 QA 보다는 CA 를 더 하게 될지도 모른다...)

예전에 어떤 소프트웨어 개발에 간접적으로 참여한적이 있었다. 조직에서 일정에 쫓기고 있을때 였는데, 내부 데모시 특정한 기능이 동작하지 않았을 때에(개발자는 다 만들었다고 했으나) 조직의 리더가 개발쪽 인원에게 모멸감 까지 들게 하는 행동을 보인적이 있다. 그 광경을 보고 그 상황을 직접 체험하면서 그 집단에 대해 모든 애착이 다 떠나가는것을 느꼈다. 경험이 있지 않은 작은조직에서 그런일이 일어났다는것은 앞으로의 모든일에서 나에게는 사망선고를 한것과 다름이 없기 때문에. 뒤돌아보면 적은 예산으로 노하우가 없었던 개발자를 키워가며 개발을 진행한것이 근본적인 문제이긴 했지만 이러한 답답함도 개발에서는 무시 못하는것 같다.

또 하나는 기능이 막강해야 한다는 것이다. 일반적인 응용 소프트웨어 개발 집단들은 최신 기술이 나오면 매우 행복해 한다. 특히 예전과 같이 한글조차도 표현해내기 상당히 어려웠던 시절에 비하면 지금은 아무런 제약없이 한글을 마음껏 표현해 낼 수 있는것도 OS 에서 선보인 최신기술 때문일 것이다. (그런 의미에서 GDI+ 에게 만세 한방을 보내어 본다) 하지만, 이런 기술들도 보안소프트웨어에 있어서는 그림의 떡이나 다름없다. 쉬운길을 놔두고 어려운길로 돌아가야 한다는 것이다. 하다못해 File 하나를 여는것도 마찬가지다. CreateFile 이라는 간단한 것을 쓸수 있으나 쓰지 말아야 할 때도 있다는 것. 가끔은 최신기술이 나와서 그쪽에서 보안이슈가 떠오르게 된다면 더욱 좌절하는 경우도 생긴다. 본인의 기억에는 NTFS 가 그것이다. 나를 비롯하여 많은 보안 개발자들과 해커까지 좌절로 몰고간 아주 좋은 케이스이다.

보안솔루션만큼 특정 기능을 신나게 만들어서 추가했지만 그리 티가 잘 안나는 소프트웨어도 드물것이라고 생각한다. 예를 들어 Layer 3 까지 Block 시키는 보안 소프트웨어와 Layer 2 까지 Block 시키는 보안 소프트웨어를 유저들이 비교할때는 그리 차이를 못느낄 것이다. 어쩌면 Layer 2 까지 Block 하는 소프트웨어가 퍼포먼스면에서는 더욱 빠를 수 있으므로 그것을 선호할지도 모른다. 하지만 문제는 '보안사고'가 터질때이다. 해커가 Layer 2 의 틈을 발견할수 있었고 그것을 Crack 할 수 있었다면 Layer 3 까지 Block 이 되는 소프트웨어를 선택 하지 않은것을 후회 했을 것이다.

이와 같은 과정을 통해 검증되는것이 보안 소프트웨어이기에 그 성능이 검증받고 인정받기 까지는 매우 긴 시간이 필요한것이다. 그러면, 한단계 우수한 소프트웨어는 간단히 만들어지는가? 다른 소프트웨어에 비해 한단계 더 우수한 성능을 내기 위해서는 Research 가 필요하다만 그 기간 역시 납득하기 어려울 정도로 길다. 그렇기 때문에 그것을 Management 하는데는 전문적인 지식이 없이는 어려울 것이라고 생각한다. 과연 그런 긴 시간을 Research 해서 수익면과 기능면에서 얼마나 큰 향상이 될지 시장을 놓치지는 않을지 등을 결정 할 수 있을만한...?

어떠한 소프트웨어라도 한가지 기능을 더 넣는다는것은 그렇게 어렵지는 않겠지만 그것이 어디에 갖다 놓아도 Reliable 하다는 판정을 받는것은 어려운데다가, 보안 소프트웨어가 어디 기능 여러개 쭉쭉쭉 집어넣는다고 막강해 지던가? 그 기본이 되는 엔진자체의 성능에 바탕을 두기 때문에 처음 엔진 설계 자체를 제대로 해야 한다는 것.

글을 쓰다보니 쓸데없는 말들로 많이 길어진것 같다. 다른 편의성 소프트웨어보다 보안솔루션 하나를 제작한다는것은 정말 부담스러운 일같다. 이것을 제작 할 때마다 느끼는것이지만, 잘 만들면 아무 소리가 없는데 그것이 개발자에게는 최고의 영광이라는 것. 하지만 못만들면 완전히 S.T.F.U 소리 다듣는 개발자가 되는것이고 실력이 없니 뭐하니라는 소리를 듣는... 역시나 그래서 노하우가 중요한것이 이 계열이라는 생각이 든다. 개발에 대한 노하우도 노하우이겠지만 주변의 소리를 잘 흘리는 노하우. 그리고 개인적인 소망으로는 빨리 보안계열에서도 이런 상황을 잘 이해하고 Management 를 해 줄 수 있는 구세주들이 나타났으면 하는 바람이다. 나는 그런 의미에서 이런것 개발하기 무지 싫은데 해온일이 이쪽일이라 지금도 이쪽 개발을 하고 있다. 끄륵~