calmglow (최진호)

헌책방에 가서 한국관련 귀중한 책들을 수집하다보면 70년대부터 80년대 사이의 우리 전통에 관련된 사진들 중에 많은 것들이 Edward B. Adams라는 분에 의한 것임을 알게된다. 더구나 이분은 사진만 찍었던 분이 아니라 그 시절 외국에서 한국에 대한 정확하고 자세한 정보를 얻기 어려웠을 때 이미 'Korea guide'라는 책을 써서 한국 문화를 알리는 데에도 많은 역할을 하였다. 이 책 뿐만 아니라 90년대 초반까지도 다양한 한국소개 책을 집필하였던, 그야말로 한국 문화를 알리는데 많은 역할을 한 분인데 도통 이 분의 정보를 알 길이 없다. 이런 많은 노력을 한 분이 정작 한국에서는 그다지 알려져 있지 않은 아쉬움에 글을 쓰게 되었다. 혹시 그분에 대한 자세한 정보를 아시는 분은 댓글을 달아주시면 감사하겠다.

봄이다. 주말이고.
참았던 술한잔 목줄에 시원허게 걸칠 것이고.
하늘 한번 의미없이 바라볼 짬도 챙길 것이고.
주말이고. 봄이고.

IBM에서 WAS 전문가로 활동하던 시절, 나는 한 때 WAS 성능 튜닝분야에서라면 국내에서 열 손가락 안에 들지 않겠냐는 자부심과 자존심이 있었다. 물론 말도 안되는 자뻑이었으나 그만큼 그 때는 성능튜닝이라면 누구보다 자신이 있었다. 때문에 성능 평가 및 튜닝에 대해 책을 내려고도 했었는데, 언제나처럼 흐지부지 되버렸다.
그때 만약 책을 냈다면 아마도 이 책의 내용과 크게 다르지 않았을 것 같다. 거의 모든 WAS전문가라면 기본적으로 알고 있어야 할 내용을 그대로 담았다. '자바 개발자와 시스템 운영자'를 위한다고는 했지만 진짜 이 책은 그런 대상을 목적으로 했다기 보다는 그런 대상을 대상으로 WAS 운영 지원하는 운영자를 위한 책이 맞다. 일반 개발자들은 굳이 이 책에 나오는 트러블 슈팅의 모든 것을 알려고도 하지 않으며 알 수도 없다. 왜냐하면 결국 수없이 많은 WAS운영 환경에서의 문제상황을 겪어야만 가질 수 있는 내공이기 때문이다.

아무튼 잘 쓰여진 책이지만 이 책만 가지고 트러블 슈팅을 하기는 어렵다. 왜냐하면 WAS운영 환경은 저마다 제각각이다. WAS의 종류도 다르고 JVM의 종류도 다르고 OS의 종류도 다르며 운영 환경 역시 천차만별이기 때문이다.

JVM의 구조나 특성에 대해 좀 더 설명을 하고 WAS의 기본 흐름에 대해, WAS를 비롯한 운영환경에 대하여 설명이 들어갔다면 좀 더 독자의 이해가 빨랐을 것 같고 WAS성능을 위한 성능 자체의 기본기를 다루는 내용이 있었다면 좋았을 것 같다.

성공한 서비스나 비즈니스 모델의 초기 사업계획은 실패한 것과 비교할때 훌륭할까? 아마 대부분 그렇게 생각할지도 모르겠다. 훌륭하고 환타스틱한 아이디어가 서비스를 성공에 이르게할지도 모른다.
하지만 요 며칠 신규 사업을 구상하면서 이전에 회사에서 성공했던 사업들의 계획서를 운 좋게 구해서 읽어보면 모호하고 엉뚱하고 무의미했던 내용이 적잖고 여타 다른 계획과 큰 차이를 느낄수가 없다.
사업은 결국 디테일과 끈기, 팀웍이 성공으로 이끄는 것이 아닌가 싶기도 하고.. 물론 전혀 엉뚱하고도 건질것 없는,시장 분석 엉터리로 된 계획에 의한 망할게 뻔한 사업도 있지만,
사업이 바라보는 시장의 방향만 어느 정도 맞다면 계획단계에선 조금 어설프고 엉성하다고 비웃을 일은 아닌것 같다.

만약 IT업종 중에 가장 재미있는 직업이 뭐냐고 물어본다면 나는 개발자라고 답할 것이다. 하지만 가장 되고 싶은 직업을 물어본다면 나는 아키텍트라고 답할 것이다.
하지만 나는 그동안 내 자신을 아키텍트라고 감히 말하기 부끄러워했다. 처음 개발을 시작할 때부터 나는 12년 전부터 JSTORM이라는 자바 학술모임을 통해 Software Engineering과 디자인 패턴등에 일찍이 관심을 가졌고 그 이후로도 줄곧 여러 프로젝트에 참여해오면서 산출물의 아키텍처에 일정 부분 영향을 끼쳐왔지만 그것만 가지고 IT아키텍트라고 할 수는 없지 않은가?

비록 10년이 넘는 IT경력의 기간이었지만 IT 아키텍처를 심도깊게 고민하고 그것을 위해 많은 stakeholder들과 대화하여 중지를 모으고 결국은 완성품을 만들어내는 아키텍트의 본질적인 업무를 한 것은 아니었는데, 사실 그동안 아키텍트로의 길은 언제나 열려있었다. 그럼에도 불구하고 선뜻 아키텍트의 길을 가지 않았던 이유는, 우리나라에서 제대로 된 아키텍트의 업무를 할 수 있는 자리가 많지 않았으며 개발이나 기술영업과 지원 등 다양한 실무 경험이 바탕이 되지 않는 뿌리가 약한 아키텍트가 되고 싶지 않았기 때문이었다.

시간은 흘러 어느덧 IT바닥에, 그것도 엔터프라이즈 IT 바닥에 12년 넘게 개발자로, Java EE 전문가로 지내다가 얼마 전부터 OO텔레콤에서 아키텍트의 역할을 수행하게 되었다. 이제는 스스로를 아키텍트라고 부를 수 있는가 자문해보면, 경험은 많아졌는데 기본과 기초는 다 잊어버린, 뿌리 한쪽이 영 부실한 아키텍트가 아닌가 싶다.

IT 아키텍트는 많은 IT 경험과 IT 지식, 그리고 인간에 대한 이해를 기본 소양으로 하고 있다. 과연 나를 아키텍트라고 자랑스럽게 부를 날이 언제 오게될런지 모르겠으나 나는 즐겁게 그 날을 위해 조금씩 준비하겠다.
나는.. (언젠가는) 아키텍트이다.

출처, 한겨레21 903호

스마트폰 열풍과 함께 개인들뿐만 아니라 기업들도 내부직원과 고객을 위한 스마트폰/태블릿용 앱을 유행처럼 만들고 있다. 그러나 예전 웹기반 서비스를 구축할 때처럼의 품질 검증 절차만을 갖고 출시하다가는 아주 아주 큰코 다치기 쉽다.