Bell
Tuesday, June 24th, 2008…
…
[[비디오는 짤리고 유튜브에서 저작권 경고메일이...]] orz
멋지지 ;ㅂ;?
세라복을 입은 이즈미는 기관총을 들고 다니고, 핫팬츠를 입은 로즈 맥고완은 절단된 다리에 기관총을 박았더랬다. 2008년 B급 영화의 천국 일본에서는 또 하나의 걸작을 배출했으니, 바로 머신걸.
미리 경고하자면, 남들이 재미있다라고 하는 영화를 보는 걸로 만족하는 분이거나 앞서 말한 영화를 모르는 사람이라면 바로 Back 버튼 누질르시라. 굳이 설득하고 싶지도 않고 자신도 없다 -ㅅ-
회전하지 않는 싼티 나는 소품의 개틀링 건… (개틀링건이 회전을 안하다니…. orz) 적색의 닌자들은 빨간 체육복(저지)를 입고 있…… 을 지경으로 저예산 B급 영화이다.
강철 드릴 뽕브라, 손가락 초밥 & 손목 튀김, 사지절단, 머리에 못 박기 등등 기본적으로 충실한 스플래터물에, 대게의 B급 영화가 그러하듯 적절히 섹시하고 귀여운 여주인공의 성장, 복수극을 베이스 스토리로 한다. 각종 특수효과는 안쓰러울 정도로 “싼티”가 나지만, 생각보다는 정성들여 만들어져 있다는 느낌을 받을 수 있고 배우들도, 혼신의 (하지만 어색한) 연기를 보여줘서 “영화 외적”인 감동이 솔솔 피어난다. 제법 일본 B급 영화를 탐독해 보는 편인 나도 아는 배우가 안나왔다. orz.
초반부의 복수의 이유를 다루는 부분은 상당히 지겹지만, 일단 복수가 시작되면 +ㅂ+ 즐거운 피칠갑 씬들이 온 화면을 장악해 주시니, 초반부의 지겨움을 잘 견뎌내는 것이 관건이다! 엔딩에 대해서도 뭔가를 기대해서는 안된다.
B급 영화의 계보로 보자면, 이 영화는 상당한 다중 상속 체계를 가지고 있다. 무기의 측면에서는 앞서 말한대로 기관총을 채택하여, 세라복과 기관총(이즈미) 플래닛 테러(로즈 맥고완)의 맥락을 이어나가고 있고, 초반부에는 킬빌에서 철퇴 여고생으로 출연하신 치아키 쿠리야님이 배틀로얄에서 즐겨 쓰시던 무기인 낫으로 목 날리기 스킬도 좀 보여준다.
당시 “전신전령으로 널 부정해 주겠어!” 라던 그 분의 상콤한 대사는 수많은 M남들의 가슴에 깊은 자국을 남기셨더랬다.
피투성이 여고생의 계보로 보자면 스테이시, 자살 클럽…. (생각해 보니 이쪽은 너무 많다)등등이 있다.
여하튼 이 영화는 B급 영화에서 주로 요구되는 모든 것을 담으려고 상당히 애쓴 흔적이 역력하다. 그렇다고 상속에만 신경쓴 것은 아니고, 나름의 신선한 새로은 스플래터 물의 마일스톤이 될만한 새로운 요소도 제법 있으니 -ㅅ- 매니아라면 반드시 체크해야 할 영화이다.
원래 기본적으로 아무도 자막을 만들어 주지 않는 독립 영화나 Yuki 와 Judy and Mary 이외의 가수에 대해서는 일절 자막/번역 작업을 하지 않지만…… 이번은 예외로 자막을 만들었습니다. 그것도 저보다도 나이가 훨씬 많은 노래를 말이죠. 시기적으로 제가 본격적으로 (연구소에 취직했어요) 도시 생활을 시작하는 시점이기도 하고, 이상하게 마음을 움직이는 노래라서 후다닥 작업했습니다.
노래 자체도 솔직하고 순수한 코드 전개가 참… 일본의 버블 경제가 시작되던 무렵의 이촌 향도 현상. 그로 인한 한 연인의 애절한 사연을 다룬 노래, 우리 정서와도 크게 다르지 않군요. 그런데 사실 요즘에야 바닷속에 잠자는 진주나 별같은 다이아가 솔직히 말해… 먹힌다는게 문제 아닌가요. 칫.
프로그래밍에서 고전적으로 발생하는 문제점 중 하는 서비스가 인스턴스화 될 때, 부가적인 다른 서비스들을 필요로 한다면, 서비스의 생성 순서에는 의존트리가 발생하게 되어, 생성규칙이 까다로워 지거나, 단순히 생성 순서를 변경하는 것 만으로도 Null 익셉션을 발생시켜버리게 된다는 점이다. (여기서 서비스라는 것은 기능 제공 집합을 의미하고자 씌여졌으며 일반적으로 객체라고 생각해도 무방하다)
결국 서비스 생성을 감독하는 모듈은 정확한 모든 사전지식을 이해한 사람이 작성해야만 하는 제약이 생기게 된다. 자체 솔루션이나 개인 프로젝트라면 이것은 크게 문제가 되지 않을지도 모르지만, 이클립스등과 같은 불특정 다수가 참여하는 약설계 협력 시스템에서는 그것이 사실상 불가능하다.
예를 들어, 노트 패드가 있다고 가정하자. 이때, 사용자가 내용을 변경시킬 때 마다 UndoManager가 문서를 추적하고 UndoHistory를 만들 것이다. 이 서비스를 UndoService라고 하자. UndoService는 노트패드의 TextArea를 Listen해야 하므로 반드시 TextArea가 먼저 만들어 져야지만, UndoService가 시작될 수 있을 것이다. 이 제약은 별 것이 아닌 것 같지만, 거시적인 프로그래밍에 제약을 주게 되므로 가장 Clear해야할 감독 모듈의 가독성과 변화 적응성을 떨어뜨려 버리고 만다.
또 SelectAll 이라는 Action은 노트패드의 전체 내용을 선택상태로 만들어주는 액션이라고 할 때, 이 액션이 제대로 수행되기 위해서는 TextArea에 대한 참조를 가지고 있어야 한다. 하지만 UI가 생성되는 시점에서 SelctAll 액션은 메뉴 또는 버튼으로 기여하게 될텐데, 이 시점에 TextArea가 이미 구성이 되었는지 그렇지 않은지를 명확하게 판단하기란 어렵다. JFace냐 Swing Application Framework를 이용했느냐에 따라 구성 순서는 달라지게 되고, 이 모든 스펙을 이해하고 코드를 디자인 하는 것은 낭비적인 돌파 방법이다. 프레임 워크를 직접 개발하는 것 역시 매우 낭비적인 일이다. (이미 존재하는 훌륭한 프레임워크들은 다 존재하는 이유가 있다.) 어차피 그렇게 한다 하더라도, 소스를 변경하고 버전업함으로써 발생하는 복잡성과 결과 비예측성은 쉽게 통제할 수 없게 되어버린다.
자원이 준비되었을때 특정한 작업을 수행하도록 작업을 예약하도록 만든다.
Platform.scheduleTaskOnService(String serviceId, Task task);
Platform.registService(String serviceId, Object serviceObject);
이때 Platform은 특정 서비스가 등록되면 거기에 예약된 작업들을 찾아내어 서비스의 인스턴스를 참조 시켜 실행되도록 하는 책임을 진다.
위와 같은 방법을 이용하면 특정 서비스가 준비되면 어떠한 작업(task)을 수행하라와 같은 명령을 줌으로써, 코드의 처리순서를 플랫폼이 자동적으로 처리하게 만들 수 있다. 이제 SelectAll 액션은 손쉽게 그냥 생성된 후에, 만약 플랫폼에 TextArea라는 서비스가 준비되면 자동적으로 TextArea를 참조하게 될 것이다. 이러면 순수히 구현의 문제 때문에 발생하는 객체 생성 순서의 제약을 벗을수 있게 되고, 좀더 유연하고 설계 개념에 근접한 안전한 코딩을 할 수 있다.