한빛출판네트워크

By 한빛리포터 2기, 이아스님 옛날에 만들었던 조립식 장난감은 본드도 필요했고, 색칠을 안하면 실제적인 멋도 안났다. 하지만 지금의 프라모델은 본드도 필요없이 부품들이 딱딱맞고, 거의 색칠이 필요없을 정도로 부품자체의 착색이 구분되어 있고 뛰어나다. 그때의 꿈이었던 관절과 손가락의 움직임은 이제 고무 관절 부품(일명 패킹)과 섬세한 설계을 통해 현실로 다가왔고, 겉뿐만 아니라 내부도 그럴듯하기를 바랬던 것도 이제는 생각한 그대로 구조에 반영되어 있다. 건담은 총과 바추카포, 칼 등의 무기와 방패가 있는데, 모두 탈착이 가능하고 매우 리얼리틱하게 구성되어 있다. 무엇보다도 로보트 신체 각 부분의 비율이 탁월하다. 발쪽이 넓어서 어떠한 포즈를 취해도 대체로 안정적이다. 만들면서 느낀 점 조립 설명서의 자세함이 정말로 경탄할 만하다. 주의가 필요한 부분은 반드시 명시하여 환기시키고 있다. 또한 내장 부품부터 차례대로 만들도록 안내하고 있고, 좌우 한쌍도 반드시 맞는 번호를 바로 표기하여 헛갈림을 방지하고 있다. 부품간의 연결은 신비로울 정도이다. 처음 만들 때에는 "이부품이 왜 여기 들어가지..."했었는데 나중에 다 만들고나서 맞춰보면 어찌나 그렇게 딱딱 맞아들어가는지. 게다가 부드럽게 움직이기까지 할 수 있으니, 선택적으로 탈착까지 가능하여 거의 완벽하다는 느낌을 받았다. 설명서는 또한 단순히 조립뿐만 아니라 건담의 유래와 역사도 자세히 서술하고 있다. 다양한 포즈와 도장례를 보여주어 풍부한 내용을 자랑한다. 이러고도 우리나라 돈으로 15000원정도. 돈이 아깝지 않다는 생각이 절로 들었다. 다음에는 건담의 숙적, 쟈크를 만들어보았다. 건담과는 사뭇 달랐는데, 가격은 쟈크가 더 비싸면서도(20000원정도) 상자는 더 작고 부품도 더 적었다. 색감도 건담보다 화려하지 않다. 의외로 조립중에도 난항이 많았다. 잘 안맞는 부품도 조금 있었고, 합쳤다가 다시 뜯는 사태도 벌어졌다. 아마도 건담을 조립하며 나름대로 조립술을 익혔다는 생각이 쟈크를 조립하면서 역효과를 낸 것 같다. 또한 처음 조립했던 건담과는 달리 긴장감도 떨어져서 성급하게 조작했던 것도 문제. 깔끔하게 다듬지도 않고 거의 손톱깍기로 끊어내는 정도가 다였다. 결과적으로 조립 시간은 단축했지만. 빨리 다 만들고 싶다는 생각이 앞선던 것일까? 초심으로 돌아가야 한다. 쟈크는 내부도 건담만큼 화려하지 않았다. 건담의 내장이 세심한 설계로 만드는 이를 감동케했다면, 쟈크는 간단하면서도 실용성을 체감하게 하는 묘한 매력이 있었다. 쟈크의 묘미는 다양한 무기와 파이프로 연결된 동력선에 있다. 고무파이프와 스프링으로 재현한 쟈크의 외부 동력선은 무척 맛깔스럽다. 건담이 역시나 멋쟁이 사관이라면 쟈크는 어쩐지 음지에서 부단히 고생하는 병사같다. 자바와의 오버랩 가장 근본적인 차이는 조립식에서는 버그가 없다는 것이다. 설명서에 시키는대로 따라하기만 하면 15세 이상의 지력으로 누구든지 똑같은 결과를 만들어낼 수 있다. 이는 부품과 설명서의 환상적인 만남이 빚어낸 결과이다. 과연 자바에서 언제쯤 이런 것이 가능할까? 환상의 설계자가 그려낸 설계도(UML이건 뭐건)에 따라 환상의 컴포넌트(EJB건 JSP 태그 라이브러리건)로 딱딱 논리에 맞게 맞추어나가기만 하면 웹 애플리케이션 완성. 프라모델의 설계도는 비주얼하다. 몹시 알아보기 편하다. 하지만 자바의 설계도들은 그렇지 않다. 설계도 자체가 없는 경우도 허다하다. DB구조, 로직 흐름, 화면 구성 등 다 따로 놀면서 개발자는 그것들을 하나로 아우르는 오케스트라를 지휘해야한다. 인간은 보이지 않는 것에 약하다. 더 비주얼하고 더 알아보기 편하고, 그리고 무엇보다도 통합적이어야한다. 그것만으로 코드를 짤 수 있는 뭔가 선명한 가이드라인이 제시되어야한다. 프라모델은 테스트가 필요없다. 왜? 만들면 알기 때문이다. 사람들은 건담과 쟈크의 이미지를 머리속에 가지고 있다. TV와 애니메이션으로 본 건담의 모습과 움직임을 감동스럽게 받아들인 사람들이기에 팔 한마디, 다리 한 짝도 만드는 즉시 머리속에서 테스트가 되어나온다. 잘 만들어졌는지 못만들어졌는지는 바로 느낌이 온다. 그리고 결정적으로 잘못될 가능성조차 아주 희박하게 설계와 부품이 잘 짜여져있다. 사이트의 전체적인 조망을 하지 못하는 개발자에게 기능 단위 테스트와 통합 테스트는 모두 의미가 없다. 무엇이 "제대로"인가에 대한 관념이 없다면 테스트 자체가 허송세월일 뿐이다. 개발하면서 사이트의 의미를 깨닫는다면 그것은 너무 늦은 것이다. 이미 많은 코드들이 개념없이 짜여진 후이다. 그럼 시간이 지나서 깨달았다고 다시 짤 것인가? 그렇게 개발 기간에 여유가 있었다면 오늘날과 같은 날림의 현장은 존재하지도 않았을 것이다. 부품과 부품을 연결하는 부드러운 고무 연결 부품의 고안은 너무도 탁월하다. 아직도 많은 개발 현장에서 인터페이스의 활용은 "자바의 장점"이라고 부르기가 무색할 정도로 전무하다. 개발자들은 자기 나름대로의 기능을 구현한다. 뭔가 공통적이며 기여할 수 있는 부분을 만들어도, 공개와 공유에 모두들 어색하다. 남이 짠 것은 이해하기도 어렵고, 마음대로 고치지도 못한다고 생각한다. 공유는 참여로 향상된다. 일방적인 제공과 헌납은 결코 오래 전체 시스템을 지속시키지 못한다. 대화와 토론, 존경과 비평의 문화가 정착되어야 한다. 아주 필요한 부분, 상징적인 부분에만 스티커를 붙이는 프라모델, 이는 자바의 주석과 비슷하다. 주석은 다다익선이 아니다. 다는 데도 시간과 정성이 걸리고, 무엇보다도 남이 쓴 것은 절대 바로 이해되는 법이 없다. 시간의 흐름에 따른 복잡한 구조화를 이룬 산물에 대한 설명이다. 의미는 시간에 따라 퇴색과 희색을 반복하고, 복잡도는 지속적으로 상승한다. 글은 죽은 것이다. 함께 따라가주지 않는다. 필요한 부분이란, 있는 것과 없는 것의 차이가 큰 곳이다. 상징적인 부분이란, 변함없이 심오한 의미를 담을 수 있는 곳을 말한다. 프라모델의 설명서에는 무기들의 다양한 탈착 방식을 보여준다. 이는 컴포넌트의 활용례와 비슷하다. 어떻게 쓰는지 알아야 달던가 말던가 할 것이 아닌가. 프라모델의 완성품이 다양한 포즈와 상황을 연출할 수 있듯이, 애플리케이션도 다양한 모습을 갖추고 더 다양한 상황에 대처할 수 있어야한다. 그때마다 다시 짤 것인가? 플러긴은 무기와 비슷하다. 문제는 아직까지 플러긴의 구조와 얼개가 너무도 불투명하다는 것이다. 프라모델에 색칠을 하는, 도장(coloring)은 어떤 의미가 있을까? 더욱 리얼리틱하고 예술의 수준까지 끌어올리는 작업이니까, 마치 최적화나 퍼포먼스 튜닝과 얼추 맞아들어간다. 그러나 『Effective Java』라는 책에 보면 이런 말이 나온다. 최적화는 절대 하지 마라. 만약 죽어도 해야한다면, 죽는 한이 있더라도 하지 마라. 과연 에어 컴프레셔와 색료로 그 어려운 도색을 할 일반 프라모델 애호가가 얼마나 있을까? 물론 취미 잡지에는 나온다. 포장 박스에도 나온다. 하지만 그것은 어디까지나 선전용이고 아주 극단적으로 프로페셔널한 경우이다. 내가 어렸을 적 프라모델은 도색없이는 별로 봐줄만하지 않았지만 지금은 상황이 다르다. 부품 자체에 색깔이 도장 수준으로 잘 입혀져 있다. 자바 환경도 마찬가지다. 처음에 느렸었기 때문에 아직까지도 "느리다"는 편견에 사로잡혀 최적화에 집착한다. 그러나 수년이 흐른 후 많은 변화가 있었다. 핫스팟을 비롯한 여러 가속 기술과 자바 API 자체의 설계 향상으로 이제 기본적인 기능에서 자바는 절대 딸리지 않는다. 오히려 선무당이 사람잡듯이 함부로 도색하려 했다가 원래 색깔마저 망친다면 되돌이킬수 없는 결과를 초래한다. 착색은 쉽지만 탈색은 어렵다. 최적화도 마찬가지다. 분명히 처음에 그렇게 짠 데에는 다 나름대로 이유와 사연이 있었던 것이다. 최적화는 결국 구조 변경이다. 소탐대실, 벼룩잡으려 초가삼간 다 태우는 일은 없어야한다. 건담과 쟈크의 차이는? 개발자의 입장에서 초보와 경력은 모두 장단점이 있다. 무조건 경력이 나은 것이 아니다. 잘 보면, 처음 건담을 만들었을 때는 무척 생소하기 때문에 다소 만드는 시간이 많이 걸렸었는데, 대신 굉장히 세심하게 설명서를 보고 칼로 말끔하게 다듬을 정도로 성의를 다했다. 그러나 다음 쟈크를 만들 때에는 어느정도 알기 때문에 빨랑빨랑 만들었지만, 오히려 설명서에 의존하기 보다는 부품과 완성도를 보고 감에 따라 끼워맞추다가 잘못해서 고생하는 경우도 종종 있었다. 또한 다듬는 일은 귀찮게 느껴졌고, 대강 맞아도 의심없이 다음 단계로 넘어가다가 몇 단계 나가서야 잘못을 깨닫고 되돌아오는 경우도 있었다. (건담때에는 이런 일은 없었다.) 자바 개발때도 마찬가지이다. 초보 개발자는 기술 자체에는 익숙하지 않지만, 긴장한 상태이고 회사에 잘보여야하기 때문에 열심히 하고 신경을 많이 쓴다. 반면 경력 개발자는 기술 자체는 뛰어나고 빠를지 모르지만, 매너리즘에 빠지게 되고 회사에 연연하지 않기 때문에 어느정도까지만 신경을 쓴다. 가끔 오히려 초보보다도 생산성이 떨어질 때가 있는 것은 바로 앞서 쟈크를 만들 때의 착각과 비슷한 "자신에 대한 과신" 덕분이다. 설계의 관점에서 보면, 건담은 화려하며 대중적인 포탈 사이트(프론트엔드)같고 쟈크는 뒷단에서 묵묵히 돌아가고 있는 트랜잭션(백엔드)과 같다. 건담은 내장을 들여다볼 수 있도록 커버의 개폐와 탈착이 아주 용이한데, 이는 프론트엔드쪽이 JSP-서블릿 식으로 이분화되어 더욱 프레젠테이션 레이어와 로직 레이어를 구분하려는 요사이 경향과 흡사하다. 껍데기는 언제든 겉어치울 수 있다. 언제고 알맹이가 잘 돌아가는지 확인할 수 있어야 한다. 건담 구조의 진가는 여기서 더욱 빛난다. 쟈크는 건담에 비해서 복잡다단함은 적지만, 단단하고 야무지며 동시에 실용적이다. 내부는 간략화된 대신 훨씬 강건한 느낌을 준다. 백엔드쪽 애플리케이션의 특성과 유사하다. 그러면서도 다양한 무기와의 결합(심지어 로케트 발칸포까지)은 최근 J2EE의 다양한 기술 융합과 매우 흐름이 비슷하다. 그리고 재밌게도 건담보다도 훨씬 빨리 만들 수 있었다. 백엔드쪽의 작성은 신속해야한다. 비즈니스는 계속 변하기 때문이다. 쟈크는 양산형이었기때문에 부품의 규격화와 모듈화도 뛰어났다. EJB를 비롯한 자바 컴포넌트도 어서 확실한 컴포넌트웨어로서 자라잡기를 바랄 뿐이다. 순전히 개인적인 계산으로, 현재 프라모델의 전체적인 완성도가 100이라면 자바는 10쯤 되어보인다. 아직 멀었다. 그러나 시간은 충분하다. 희망이 이미 열리기 시작했다. 10년뒤의 자바가 지금의 프라모델보다도 더 만들기 편해지기를 바란다.