교육팀에서 프로필을 어떻게 저렇게 적을 수 있는지 어이가 없어 한 번 웃고 쪽팔려서 한 번 웃었습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

내 스윙은 의심한 적 있어도 내 클럽을 의심한 적은 한 번도 없다

골프를 좋아하는 놀새~가 항상 새기는 잭 니클러스의 명언입니다.

대체 우리 회사 제품이 왜 이래~라는 의심을 갖기 전에 내가 가진 실력을 먼저 의심해 보는 것도 좋을 것 같습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

갑자기 weblogic이지만 주변에 물어온 사람이 있어 혹시나 해서 남깁니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

끊임없는 연습이 가장 중요한 모든 것들이 그러하듯이 개발도 비슷한 일면이 있지 않을까 합니다.

아무리 많은 연습을 해도 실력이 늘지 않는 개발자가 있었다. 그 반대로 단기간에 실력이 느는 개발자도 있다. 이러한 차이는 어디서 생기는 것일까?

원래 가지고 있는 재능을 제외하면 그것은 연습방법의 차이에 의한 경우가 많다. 일반적으로 연습이라는 행위를 잘 못하는 사람에게서 많이 볼 수 있는 점은, 자신이 코딩할 수 있는 패턴만 계속 코딩하고서 연습했다고 만족에 빠지는 것이다.

빌리시언은 '연습이란 자신이 할 수 없는 플레이를 하는 것이다"라고 말했다. 이 말이 정답이라고 생각한다. 객관적으로 자신을 돌아보고 약한 부분을 이해하는 것이 중요하다. 그 다음 단계로 약한 부분을 단련함으로써 뛰어난 개발자로 확실하게 성장할 수 있을 것이다.

"지옥의 메커니컬 기타 트레이닝 서문"

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

PoC 중에 SAX 파서를 사용하여 파싱하는 ETL 모듈을 만들고 있는데 IBM MQ의 CCSID 819(ISO-8859-1) 데이터를 받습니다. 이 때 ParserHandler의 chararcters 메소드에 들어오는 character data를 다음과 같이 하면 문자가 가끔 깨져버릴 수 있습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

달콤한 인생의 이병헌의 처음 나레이션에 이러한 말이 나옵니다.

스승님, 저 나무의 가지가 움직이는 건 바람이 움직이는 것입니까? 가지가 움
직이는 것입니까?"

스승은 그곳을 바라보지 않은 채

아무것도 움직이지 않는다. 다만 너의 마음이 움직이는 것이다"

내 스스로 한가지를 놓고 바로보는 관점이 시시각각 달라진다는 것, 그렇지 않아야 함을 알면서도 그러하지 못하다는 것입니다. 반성해야 할 일입니다.

스티븐 코비의 "성공하는 사람들의 7가지 습관"에서도 모든 사고방식이 자기 중식적인 곳에서 나온다고 설명합니다. 본인 스스로 객관적이라고들 이야기하지만 자신이 지금까지 살아왔던 원칙이라는 틀아래 결국 주관적이라고 밖에는 할 수 없는 결론에 도달하기 때문입니다.

정말 내스스로 "이건 객관적으로 판단한거야"라고 했을때 질문을 던져보세요..

정말 객관적입니까?, 본인스스로 그게 완벽하다고 말할 수 있습니까?

제 대답은 "No"입니다.
언제쯤 선안을 가질 수 있을까요..

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

서블릿도 필터를 이용하여 각 프레임웍에 대한 매핑작업을 통해 꼭 필요한 일을 하게 됩니다. 정수기도 필터를 이용하여 우리가 깨끗한 물을 마실 수 있도록 합니다.

사람도 마찬가지여서 머리, 입, 눈에 필터가 필요할 것 같습니다. 가끔 여과없이 나오는 말에 다른 사람들이 더러워지기 때문이 아닐까 합니다.

특히나 중요한 것은 입에 다는 필터가 아닐까 합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

어제 아주 어처구니없는 광경을 목격하고 말았습니다.
심하게 말해 사용자들 혹은 개발자들이 완전 병신 취급 당했다 해도 될 것 같습니다.

어제 그랜드 인터컨에서 열린 발표회의 풍경이었습니다.
남의 것을 가져다 자기 것인것 마냥 둘러대고 알맹이도 없는 프리젠테이션을 하는 걸 보고 역시 기대를 져버리지 않았구나 하는 생각입니다. 유명 가수들 데려다 놓고 어마어마한 홍보비(일간지, 삼성동 일대 플래그 등)를 차라리 개발자들 휴식하는 데 쓰는게 나을 것 같습니다.

직원이 OS만들다 이혼을 했네 월화수목금금금이네를 자랑스럽게 말하는 것을 보면서 저런 생각을 가진 악덕 소프트웨어 업체에서 일하고 있는(월급도 계속 제때 나오지 않는 것으로 압니다) 개발자들이 한없이 불쌍한 뿐입니다. 인터넷을 뒤져보면 어느 한군데라도 우호적인 글을 발견할 수가 없는 것도 결국 쇼(좋게 말해.. 나쁘게 말해 사기극)가 되지 않았나 합니다.

우리나라에 저런 소프트웨어 기업이 있었으면 좋겠다는 애국적인 생각은 갖지 말았으면 합니다. 최소한 그렇게 되려면 원천기술 운운하며 오픈 소스 발라놓은 OS나 자체 개발했다며 복제한 비즈니스 애플리케이션이 없어야 합니다. 때로는 작은 실수가 인간적으로 보일 수도 있는 부분이지만 이건 실수 자체가 아니라 의도된 조작에 가까우니 fact(사실)를 바라는 관중의 목소리는 전혀 그렇지 않다는 반증이 될 수 있습니다.

그렇게 해서는 안되는 것이었습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

말그대로 상대하면 가장 힘든 고객 중의 한 부류의 기술을 잘 알고 프로젝트 생리 및 바닥에 대해 경험을 가진 갑입니다. 세일즈 교육에서 들은 가장 쉬운 갑은 "돈을 요구하는" 고객입니다. 그들은 단순하게도 "돈만 주면 해결"되기 때문입니다.

왜 하필 그런 부류일까요?

만약 JEE(Java Enterprise Edition) 속성을 정말 잘 알고 있는 한 고객이 있다고 가정을 해보면 접촉시 진부한 솔루션 슬라이드 같은 거 가지고 오지도 말라고 하는 게 일반적입니다. 비교 자료도 필요없다고 보통 이야기합니다. 보여줄 수 있는 "특화된" 것을 가지고 오라고 항상 이야기합니다. 게다가 갑 끼리의 정보는 대부분 공유를 하시기 때문에 동종 업계의 무슨 벤더 제품을 썼더니 이런 문제가 있더라라는 내용도 아주 꿰뚫고 있습니다. 한 마디로 너무 잘 아는 고객이기 때문이지요.

때문에 공격할 창이 무뎌지는 느낌을 받을 뿐더러 우리가 막아야 할 방패가 부족한 경우도 허다합니다. 주변의 선배 중 L통신사의 AA(Application Architect)로 가신 분이 한 분 계십니다. Sun에서 교육할 때 자바를 같이 교육하던 동료이자 선배님이셨는데 당연히 자바라는 내용에 대하여 워낙에 꿰뚫고 있는데다가 이후 프로젝트시 거의 대부분의 WAS(Web Application Server)를 다뤄보고 ESB(Enterprise Service Bus)를 사용한 SOA까지 하부의 기술부터 상위 아키텍처까지 줄줄이 꿰고 계시기 때문이지요. 이 분 앞에서 벤더는 거짓말을 못합니다. 했다가는 오히려 "괘씸죄"에 걸려 대상에서 탈락하기 십상이니까요.

공략법?

방도 없습니다. 국내에서 또 실무라고해서 윗선을 통해 꺼꾸로 찍어눌렀다간 뼈도 못추릴 수도 있습니다. 그저 솔직하게 우리가 가진 장점을 그대로 이야기해주고 단점이 있을 경우 변명하기 말고 시인한 후 차우 어떻게 지원이 될거다라는 내용을 이야기해드리면 됩니다. 전반적인 눈높이를 맞추는 것도 상당히 좋은 방법일 것으로 판단됩니다.

사실 말은 쉬운데 실제로 만나면 잘 안되는 게 현실입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

전에도 글을 많이 썼었지만 놀새~의 경우 상당히 많은 BMT를 진행해왔고, 지금도 진행하고 있습니다. 가장 최근에 한 것이 4월말 5월초였으니 아직 감각은 조금 남아 있는 것 같기도 합니다.

회사 내 솔루션으로 얼마전에 BMT가 하나 진행된 것은 안 것이 BMT를 하던 날, 당일이었습니다. 인프라 스트럭처 관련된 솔루션과 미들웨어 관련 솔루션이 같이 있다보니 당연히 모를 수도 있을 수도 있다고 하겠지만 담배 커뮤니케이션의 부재(? - 담배를 안피우다 보니)가 아니었나 하는 의구심이 듭니다. BMT 사실을 알았고 결과에 대한 내용을 엔지니어에게 물었을 때 "몇 가지 문제가 있지만 잘 끝냈습니다"라는 이야기를 들어서 제가 "잘 끝냈으면 이긴거네?"라고 물어봤는데 대답이 없어 조금 의아해했습니다. 결과는 "So, so"?

사실 그렇지가 않습니다. 모든 것에 등수 매기기를 좋아하는 한국 사람의 입장에서 1등이 아니면 꼴찌라는 공식이 성립합니다. 2등은 아무리 용써봐야 알아주지 않습니다. CA라는 회사는 15,000 개의 솔루션을 가지고 있지만 그 1등 제품이 몇 개되지 않아 대부분의 개발자들에게 솔루션 제품을 이야기해도 잘 모르는 경우가 허다합니다. 2등이 아무 의미가 없다는 게 바로 그런 이유에서죠. 결국 무엇을 하건 무조건 1등을 해야 한다는 결론이 나옵니다.

BMT는 그저 우리만을 테스트하기 위한 것이 아니다.

1등을 가려야 합니다. 그러려면 우리를 잘 알고 있는 것 뿐만이 아닌 BMT에 참여하는 대상을 명확하게 파악하고 있어야 합니다. 가장 좋은 방법은 고객을 구워삶아 BMT 테스트 항목에 우리 것이 유리한 항목이 포함시키는 것이겠지만 그렇지 않다면 경쟁사의 강점이 우리의 약점이 될 수 있는 항목을 찾아 그 약점을 최대한 메울 수 있는 방법을 생각해봐야 합니다.

산악인 엄홍길씨를 아실 겁니다. 에베레스트 16좌 최초 등정의 자랑스런 한국인입니다. 세계에서 가장 높은 산을 정복한 그 분도 몇 백미터 안되는 산을 올라갈 때 그 산이 가진 특성에 대하여 미리 알아보고 복장, 신발 등의 채비를 완벽하게 갖추고 오르기전 체크 리스트를 통한 점검 후 산에 오른다고 했습니다. 1등이라는 자만심이 아닌 낮추는 방법을 다음과 같이 표현하고 있습니다.

"산은 끊임없이 자신을 낮추고 들어가면 그 정성을 외면하지 않고 기적으로 화답하는 것을 몸소 체험할 수 있다"

뜬금없는 이야기라고 하실지 모르지만 이 이야기를 꺼낸 주된 목적은 앞서 언급한 "몇 백미터 안되는 산을 올라갈 때 그 산이 가진 특성에 대하여 미리 알아보고 복장, 신발 등의 채비를 완벽하게 갖추고"입니다. 1등이지만 항상 부족할 수 있다는 것과 잘못 채비했을 때 죽는다라는 마음을 가진다면 사전에 필요한 체크리스트가 점점 꼼꼼해지고 명확하게 나타나게 됩니다. 얇잡아봐서는 항상 다칠지도 모른다는 생각을 가지고 접근하는 자세가 필요합니다.

그러면 어떻게?

BMT도 사람이 하기 때문에 가끔 BMT같은 것을 가르켜 "솔루션 테스트"가 아닌 "벤더 엔지니어 테스트"라고 말하기도 합니다. 즉 어떤 선수가 들어오느냐에 따라 성능을 최대한 내는게 틀려질 수도 있으니까요.

사람에 대한 내용을 떠나 실제로는 상대에 대한 기술을 알고 그 기술을 직접 써보고, 그 직접 경험에 의한 문제점이 무엇인지를 먼저 파악한 후 겨루는 것이 가장 중요합니다. 잘 할 수 있는 것들, 나타날 수 있는 문제, 잠재적인 문제, 사람에 관련된 모든 문제를 먼저 파악하고 해당 문제가 발생했을 때 즉시 해결하는 능력 또한 중요합니다.

즉 나, 또는 우리 스스로를 테스트함과 동시에 대상에 철저한 분석만이 정상에 이를 수 있는 가장 최선의 길이 되지 않을까 합니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.