BeyondJ2EE

최근 변화된 나의 프로젝트 환경을 보면 “웹 어플리케이션 프로젝트” 보다 “데몬형태의 프로젝트”를 더 많이
생성하고 있다.

이러한 이유는 기존에는 “비즈니스 Flow”가 웹 어플리케이션의 컴포넌트로써 존재를 했지만

최근에는 “비지니스 Flow” 가 서버 to 서버로써 구성이 되어 가고 있다.

“웹 어플”은 단지 노출용으로 사용 되어지는 느낌.. 그러다 보니
light 하게 구성을 하는 것 같다.

개인적으로 이런 성향의 프로젝트들을 해서 그렇긴 해서 일반화 하긴
힘들지만.. 모든 서버를 다
“웹 어플리케이션”으로 구성해야
하는지 곰곰히 생각할 필요가 있을듯
싶다..

또한 얼마전 “최진호”님 과 얘기 했듯이 “앞으로 플랫폼 사이즈”의 플젝이
많이 나오지 않을 것에 대해서 공감한다.

예전엔 작게는 몇십억에서 크게는 몇백억을 투자해서 많은 개발자,
많은 어플리케이션, 일정이 긴 프로젝트들을 많이 했었다..

소위 “플랫폼” 프로젝트들…
크게 만들어서 크게 먹을수 있었기
때문에..

때론 수익성이 떨어져도 마이너스는
아니기 때문에 그래도 “플랫폼” 이었다..

하지만 지금 상황이 많이 달라졌다..
크게 만들어서 성공을 장담 할수가
없다..

엄청난 물량(개발자, 일정, 비용,마케딩)를 쏟아도 과연 성공을 할수 있을까…?

이건 마치 공중파 시청률 하락과
매우 흡사하다..

더 이상 고객은 “브렌드”, “마켓팅”에
흔들리지 않고, 좋으면 좋은거다..
케이블 TV라도..

그러다보니 예전 보다
작게, 빨리 고객에게 먼저 보여주고,
추후 잘 되면 크게 고도화 방향으로
가려는 것 같다.

그러다 보니 “스타트업”을 하는 느낌이 든다.

그래서 나의 아키텍쳐링도 시대의
흐름에 조금씩 바뀌고 있다.

예전에는 견고함, 표준화, 획일화등
오와열이 정확한 각진 엔터프라이즈
모델을 준수 했다.

이것이 오버 엔지니어링이라고 생각
하지 않는다. 나름 괜찮다고 생각한다. 큰 플랫폼에서는 쿨한것 보다
규범이 더 중요하기 때문에..

하지만 작은 사이즈에서는 이런 모델이 정작 배보다 배꼽이 더 클수 있다.

그래서 최근에는 상당히 군살을 빼고, Rapid 하게 아키텍쳐링을 한다.

예를 들어서 예전에는 5개 프로젝트를 만들었다면 지금은 한개의 프로젝트로 환경변수에 따라 5개의 프로젝트로 변화할수 있도록..

또한 개발 레퍼런스 문서도 정말 필요한 것들만 기술 하도록..

이런것들이 더 쉬울수 있다고 하지만
사실 추후 고도화를 고려하면서 rapid한 아키텍쳐링은 쉽지 않다.
많은 경험이 필요하고, 틈틈히
테스트도 많이 해야 한다.

또한 요새는 업무 설계보다 기술에 대한 요구 사항이 늘어 나고 있다.

정책서, 요구사항 정의 보다 기술관련 자료를 보고, 근무시간에 틈틈히
스터디를 할정도니..

목소리는 좋지만 “올드한 보이스”는
시장에서 외면 당하니..
“항상 현 시대를 반영하는 보이스”를
갖는 노력하는 개발자가 되어야 할것
같다.

항상 2~3년 주기로 아키텍쳐의
큰 변화를 겪는데.. 지금이 그 시기가 아닌가 곰곰히 생각 한다.

평소 트위터 와 페이스북을 통해서 기술, 트렌드, 아키텍쳐, 경험 등을
공유 하고 있다.

내가 전달한 정보가 얼마나 사람들이 보는지 정기적으로 트위터, 페이스북을
모니터링 한다.

이렇게 하는 이유는 어떤 정보에 관심을 갖고 있는지 알고 싶어서다.
왜 알고싶은가?
음…정보에 공감한다는 건 현재 또는 가까운 미래에 사용을 할 것이란
의미 이다.(물론 개인적으로 좋아서 공감 하는 경우도 많다)

그럼 어떤 정보가 “공감” 을 얻을 수 있을까?
그 전엔 말하고 싶은 건 이제 사람들 (특히 개발자) 들은
정보에 대한 변별력이 있으며, 수준 또한 높아 졌다.
이 얘기는 더 이상 “정보 충동 구매”를 하지 않는 것이다.

예전에는 정보가 없다보니 컨퍼런스나 또는 세미나/교육을
통해서 정보를 얻었다.

그 정보가 상업화의 거품 인지, 알짜 정보인지 알수가 없었다.
평가할 자료도 없거니와 경험자가 어디에 있는지도 몰랐다.
그냥 앞으로 대세라고 하니 취업준비생들 처럼 그냥
스펙을 쌓는 것이다.

하지만 지금은 “절대 구글링신” 과 “SNS 신”이 있다.
이들 신은 초급도 아키텍쳐링을 할수 있게 해준다.

이제 정보는 누군가의 전유물이 더 이상 아니다.
정보가 넘치다 보니 이제는 직관적이고, 쉽게 설명 하지
않으면 정보측에도 못낀다.

내가 나름 몇시간씩을 투자해서 잔득 멋부린 글이나,
또는 이정도 정보는 퍼블리싱 해야 “다른 사람이
볼때 잘한다고 생각하겠지”한 것들은
그 다지 큰 반응이 없다.

반면 “그냥 아무 생각 없이 필요 하지 않을까”
하면서 가볍게 퍼블리싱 하는 정보는 엄청난 반응을 보인다.

전통적으로 보면 “공감”을 얻은 것들은 점차 커져서 대세가
된다. (물론 환경변화로 사라지는 것도 있다)

결국 현재까지 존재하는 기술들을 보면 대부분은 공감을 하는 것들이
살아 남아 있다.

그렇다면 무조건 쉬운 것만 공감 하는 정보냐?
물론 틀린 얘기는 아니지만 맞는 얘기도 아니다.

내가 나름 정의하는 공감이 있는 정보는

첫째 “현재 필요한 정보 보다 2보 정도 앞선 것”을 말한다.

2보 정도란 말은 무책임 할정도로
추상적이다. 하지만 어쩔수 없이 사람들과 소통해야만
알수 있는 2보 이다.

이제 사람들은 정보에 치여서 “내게 일어나지 않을것” 같은 정보는
무시 한다.

예를 들어 A라는 최신 기술이 HOT하다고 하면, 예전엔 와~~~~
하지만 요샌 뜬구름 잡는다고 생각 할수 있다.

두 번째는 “무조건 쉬워야 한다는 것이다”
“엘리트들은 그들만의 언어”를 사용 한다.
그래야 대중들에게 인정받고, 경쟁자를 없에기 위함이다.

온갖 용어와 복잡한 내용을 얘기하고, 결국 이해하면..
이말 할려고 저렇게 설명 했어야 했나 싶은 경우가 많다.

꼭 어렵게 써야 있어 보이는 것인가…
사람들은 잘난척(?)하는 정보는 관심 없다.
이유는 시간이 없기 때문…
그거 이해할 시간에 더 잘 정리되고, 쉬운 정보를 찾는게
낫다라고 판단한다.

물론 전문적인 정보도 필요하다. 내가 말하는건 다수가
보는 정보를 의미 한다.

이제 사람들은 똑똑한 것에 관심이 없다.
또한 의미도 없다..

지금 사람들은 서로 어떻게 생각하고, 어떻게 사용해야
하는지 공감을 하고 싶은 것이다.

비단 정보 뿐만 아니라 모든 분야가 사람들과
공감하느냐가 핵심 키워드가 아닐까…?

SNS를 통해서 점점 개발자들을 알게 되면서 많은 얘기들을 한다.

내코가 석자임에도 불구 하고 상담 아닌 상담을 한다.

또한 시대가 갑자기 변해서 더욱더 혼돈이
오고, 불안 해서가 아닐까 한다.

상담에 대상은 초급부터 고급까지 경력, 연령, 주제도 다양하다.

초급 같은 경우는 어떤 기술, 책, 학습 테크 트리 등 개발자로서 어떻게 입문을 하고,
경력 관리를 하는지에 대한 내용이 주를 이룬다,

중급 같은 경우는 이직 과 진로가 가장 높고
그 다음은 조직의 갈등, 윗 사람과의 관계,
실무기술에 대한 내용이 주를 이룬다.

반면 고급분들은 업계동향,관리자냐 개발자냐의 고민, 능력에 대비 롤에 대한 부담감,
팀원 과의 갈등, 아키텍쳐에 대한 고민이
주를 이룬다.

연령별, 경력별 주제가 다양하지만
사실 개발자로 살면서 한번씩 넘어야 할
산이다.

남들 보기에는 부러운 회사에서, 멋지고 , 재미있는 일을 하는 개발자들은 행복할거라
생각하지만 사실은 그들도 고민이 많다.

대기업에 다니던, 중소기업에 다니던,
스타트업에 다니던 말이다..

내 스스로가 성공한 개발자가 아니기 때문에
어떤 말을 해야할지 조심 스럽고, 부담 스럽다.

그냥 한국에서 14년간 개발자의 한 사람이
느꼈던 회고록이라고 생각하고 각자 필터링
하기를 바란다.

먼저 개발자로써 초급은 정말 매우 매우
중요한 시기이다.
또한 기초체력을 확실히 다져야 할 시기다.
다시 돌아 오지 않으며, 개발자로써 가장
시간이 많이 확보 되는 시기다.

이유는 결혼을 아직 하지 않았기 때문 이다.
즉, 처녀/총각은 최소한 주말 Full Time
이 가능한 사람들이다.

하지만 많은 수의 개발자들은 이시간을
그냥 의미 없이 소모를 한다.

«초급편»
기초체력을 쌓을때 되도록 최신 오픈소스,
프레임 웍 보다 코어를 공부 해야 한다.
예를 들어 jquery 보다는 자바스크립트, CSS,
HTML5 같은..

자바 개발자는 스프링 보다, 코어자바, 디자인
패턴, 리팩토링, UML 같은..

공통은 네트워크, I/O, 쓰레드, 자료구조, 알고리즘 같은 것들..

중국영화 보면 사부가 권법 안 갈켜주고, 엄한
힘들일 시키는 이유는 기초 체력 없이 권법을
소화를 못하기 때문이다.

주위에 간혹 중,고급 따라서 최신기술만 한 친구들 보면 거의 껍데기고 허상이다.
Getting Start 가 끝이다.. 기초 체력이 없으니
응용, 트러블 슈팅 불가..

영원히 초급이면 모르겠지만 어느새 중급을 맞이 하는 시기가 금방 온다.

그리고 수단/방법 가리지 말고 “좋은 멘토, 성장할수 있는 팀, 온오프 인맥”을 확보 해야 한다. 스스로 자립이 어렵고 배워야 하는 시기에는 스승은 매우 중요하며, 몇년 후 실력 차이가
천지 차이가 될수 있다.

되도록 대기업, 중소기업 할것 없이 수소문 해서 좋은 사수가 있는 곳으로 가라

만약 현재 조직이 맨날 술, 담배, 여자, 정치
얘기만 하는 팀에서는 하루 빨리 나오길 바란다.

또한 고졸, 전졸은 학사를 반드시 취득하도록 해야 한다. (이건 다음에 포스팅 할 예정이다.)
OS 만들 레베루가 아니면 적어도 최소한의
학력이 필요하다.. 적어도 한국 사회는..
마지막으로 영어에 대한 장기플랜을 세워
꾸준히 이행을 해야 한다.
개발자 관둘때 까지…

«중급편»
중급이 되면 스킬이 급성장 한다. 그 동안 책으로만 이해했던 것들을 몸으로 느끼면서
“아.. 이런거였구나” 하면서 급 성장을 하게 된다. 마치 스폰지 처럼 다 빨아 드리면서

개발이 정말 재미있구나 하는 걸 경험하면서,
최신 기술을 쭉쭉 빨아 드리고, 코딩 소리는
“다다다다” 분당 500타 이상의 경지까지 간다.

또한 무엇을 공부해라 할 필요 없이 스스로
내가 이걸 공부 할지를 알게 된다.

But 이 시기에 핵심은 “어떤 것을 경험 할것이냐?” 이다.

이 경험이 결국 진로를 결정하며, 몸값을 쭈욱 올릴수 있고, 장기적 개발자의 삶의 발판이
돤다.

중급의 5년은 그 사람의 스킬 셋을 보는게
아니라 “5년간 무엇을 경험 했니?” 가
키포인트 이다.

멘토, 팀, 동료 보다 중요한게 “엄청난 레퍼런스가 될수 있는 프로젝트 또는 운영을
할수 있는 환경이다.

즉, 너 뭘 할줄 알어가 아니라, 뭘 경험 해봤니가 제일 중요하다.

물론 때론 미치도록 힘들다.. 하지만 더 나이들면 하드웨어가 딸려서 경험하는게 부담 스럽다.
즉 본인의 한계를 경험할 시기 이다.

블록버스터도 나이가 들면 찍기 어렵다..
마지막으로 돈 보다 “성장할수 있는 현장”을 최우선으로 고려 해야 한다.
그리고 지속적으로 외국계 회사던 한국이든
좋은 회사라면 아님 말구 정신으로 이직 try를 계속 해야 한다.

«고급편»

현재 나의 상황과 비슷하다.
일단 체력 관리를 슬슬 시작해야 할것 같다.
요샌 밤새면 휴유증이 일주일 간다.

그리고 정기적인 “힐링”을 할수 있는 것을
만들어야 할것 같다.

그리고 온오프라인 인맥에 많은 노력이 필요
할것 같다. 특히 요새는 최신 트렌드는
젊은 친구들을 못따라가기 때문에
“가호”는 버리고, 자존심 버리고 나이 불문
배울건 배워야 할것 같다.

롤에 대한 부담감은 생각할수록 더 안좋아
지는 것 같다. 그냥 짤리면 뭐 짤리면
프리랜서 하지뭐 하는 심정으로
마음 편하면서 과감하게 행동할 필요가 있다.

능력이 안되는 걸.. 걍 인정하고 내려 놓으면
엄청 많은 걸 얻게 되는 것 같다.

마지막으로 개발자를 언제까지 할수 있을까에 대한 질문은 솔직히 신이 아닌 이상 어떻게
알수가 있을까?

하지만 최근 일하면서 나이 운운 하는 것은
못 본것 같다.

프로젝트를 성공 시킨다면, 기업이 원하는 솔루션을 개발 할수 있다면, 내가 원하는
서비스를 만들수 있다면, 대규모 서버를 운영 할수 있다면..

내가 CEO라면 나이는 상관하지 않을것 같다
이유는 돈을 벌어줄수 있는 개발자 이기 때문에..

마지막으로 평생 행복한 개발자로 살고 싶고,
다 같이 오래 일하고 싶은 마음은 누구보다
간절하다.

입에 바른 소리를 하고 싶지만, 어느날 갑자기
멘붕이 오는게 너무 싫다.

현실은 냉혹한 경쟁사회다 살아 남아야 한다.
하지만 인생이란 큰 프레임으로 볼때
결국 정답은 자기주도의 개발자 삶이 아닐까
한다.

최근 “보안적 이슈” 때문에 “자바”에 대한 인식이 많이 안 좋아 졌다.
또한 예전 부터 웹 서비스는 자바만이 할수 있는 것 처럼 보였다.

하지만 지금은 다른 언어들 또는 프레임웍들의 발전 으로 “웹 서비스는 더 이상 자바만의 전유물”이 아닌 시대가 도래 했다.

때론 자바 보다 훨씬 실용적이고, 뛰어난 부분도 있다.

사실 최근 자바가 너무 비대하다는 생각이
드는 건 사실이다. 특히나 오라클로 넘어
가면서 특허로 돈 벌기 수단으로 쓰고,
트렌드에 맞지 않은 비대한 스펙화..

또한 스프링도 예전의 심플 하면서, 실용적인
부분 보다 점점 하나의 표준 처럼 비대해
지는 느낌..

그리고 자바 개발자가 아닌 사람이 웹 개발을
하려면 이클립스, 메이븐, 스프링, 기타 오픈소스를 익혀야만 하는 부담감…

그리고 프레임 웍크는 왜이리도 많은지..

자바를 밥벌이로 먹고 살고, 지속적으로 학습하는 나조차 버거운데..
자바를 잘 모르는 개발자는 어떨까…

자바가 이렇게 비대해지고, 복잡한 이유는
개인적으로 “자바 만큼 돈 냄새가 나는 언어가
또 있을까?” 이다.

물론 순수한 목적으로 오픈소스를 만드는 것도
맞지만 결국은 상업적 목적이 없다면 거짓말..

어찌 보면 국내에서 자바를 싫어 하는 사람은
많으면서도 자바를 할수 밖에 없는게 오늘의 현실..

최근 SNS 또는 주변 반응을 보면 자바 보다는
다른 언어, 기술에 더 관심이 많아 보인다.

개인적으로 상당히 바람직한 현상이라고 생각한다. 다양한 언어가 공존하고, 서로 보완이
돠어야 한다.

자바가 시들해 졌다기 보다 너무 독점해서
이제 조금씩 밸러스가 맞춰 나가는 것이지..

자바가 사양길로 접어드는 것은 아니라고 본다.

모든 걸 자바로 하는 시대 보다 더 잘한 것도 쓸수 있는 시대..

자바는 이제 정말 어떤것을 취하고, 버려야 하는지 “강한 다이어트”가 필요한 시대 인것 같다.
즉, 반성이 필요한 시기..

하지만 그렇다고 “자바가 구리다 거나”, “자바는 곧 끝날 것이다”, “자바는 한물 갔다”
라는 자극적 표현을 가끔 들을 때 마다
인정 하기가 어렵다..

나는 그런 개발자에게 묻고 싶다. 자바를 얼마나 깊게 실무에 적용 해봤으며, 엔터프라이즈
영역에서 프로젝트 할때 다른 언어로 국내에서
가능 한지에 대한 방안을 ..
그것도 말로 말고, 직접 프로젝트를 리드 하면서 말이다..

모든 도메인이 “초고속 개발” 만 있는 것은 아니다.
만약 “초고속 개발” 후 시스템이 커지면 어쩔 것인가?

기술/아키텍쳐에서 절대 공식이란 있을수가 없다. 이유는 각자 일하는 요구사항, 도메인이
틀리기 때문이다.

모든게 “trade-off” 와의 싸움이고.. “적절한” 이란 형용사를 만족 하기 위해서 끝도 없는
학습을 하는 것이다.

단지 본인이 일하는 도메인 기준에서 모든 IT 업계가 그럴 것이라는 우를 범하지 않았으면
한다.

이제는 언어의 시대는 아키텍쳐의 세계, 융합의 세계이다.
하둡을 “자바”라고 퉁칠수 있으면, jQuery를 “자바 스크립트”로 퉁칠수가 있는가?

이제는 언어 그 자체가 어려운 것이 아닌
그것들로 구현된 레벨이 높은 구현체들이
부담 스럽고, 어려운 것이다.

여기서는 자바가 필요하면 자바를 공부 해야하며, 파이썬이 필요하면 파이썬을 하고,
루비가 필요하면 루비를 공부 해야 하는 시기
이다.

물론 당장은 힘들겠지만, 조금씩 서서히 준비
해야 하는 시기가 아닌가 싶다.

“자바를 떠난다”라는 편협적이고, 극단적 표현은 엔지니어로써의 모습이 아니다.

앞으로 세상은 더 우리에게 많은 걸 요구한다.
그래서 “고급 개발자가 많아 지고, 개발자
수명이 길어 진다면”

나는 즐겁게 맞을 준비가 되어 있다.

옛날 과 다르게 스마트 폰 과 SNS를 통해서 대외적으로 개인을 알리기가 쉬워졌다.

특히나 IT 바닥은 너무 좁기 때문에 조금만 수소문 하면 “저 사람이 어떤 사람인지”에 대한 신상을
알수 있다.

업계에 자기 자신이 알려지는 건 “양날의 검”이다. 유명해 질수도 있고, 반면 한방에 훅 갈수도 있다..

최근 개인적으로 많은 부담감을 가진다.
처음 나의 취지는 “나 처럼 삽질 하는 사람” 이 혹시나 있을까봐 정보도 전달하고,
포스팅도 프로젝트 중에도 나름 열심히
했다.

그렇게 시작을 했는데 나의 생각 과 무관하게 너무 많이 알려진것 같다.
특히 출판사에서 “내 트위터 아이디”만
얘기해도 안다는 말에 많이 놀랬다.

모든건 우연히 시작을 하나보다..
착각일수 있지만 너무들 좋게 봐주시는 것 같다.

SI는 고리스크한 프로젝트 이기 때문에 개인적으로 쫓겨날수가 있다.
즉 실패 확률이 50이상이다..

항상 플젝하면서 긴장하고, 살얼음 판을 걷는 느낌이다.

원래 사람들은 대외적 이미지를 과대포장 해서 해석한다.

나는 뛰어난 엔진을 만드는 사람도 아니고 책을 출판할 글 실력도 없고, 멋지게 아키텍쳐링 하는 사람도 아니고 리눅스, 네트워크 같은 시스템 엔지니어도 아니다.
또한 컨퍼런스에 나가서 멋지게 PT할 수준도 아니다.

아마도 나에 대해서 누군가 물어보면 아무도 모를 것이다.

커뮤니티에 가입한적도 없고, 좋은 대학을 나와서 인맥이 있는 것도 아니고 그렇다고 대기업 출신도 아니다.

아마도 나의 존재는
오직 나와 프로젝트를 같이한 사람들만이 나를 알것이다.

주위에는 생각 할수도 없는 일명 “슈퍼 개발자”들이 엄청 많다.

나는 그들에 비하면 정말 그냥 SI 개발자다.
막장 개발자…
내가 할수 있는 건 그냥 개발자 도망나오고
, 쓸어져 갈것 같은 프로젝트 몸빵 하고 나오는게 나의 삶이다.
진짜 흔한 주변에 볼수 있는 SI 개발자다.
아키텍트도 아니고 그런 역량도 안된다.

정말로 난 사람들이 그렇게 봤으면 좋겠고,
혹시나 대외적인 이미지에 대한 환상을 지웠으면 좋겠다.

만약 지금 처럼 간다면 점점더 알려 질것 같다.

그래서 SNS를 접어야 하나 고민도 많이 했다.
하지만 한편으로 내가 무언가 누군가에 도움을 주기 때문에 알려지는게 아닌가 싶다.

SI하면서 너무 상처를 받아서 SNS를 통해서 아는 분들께는 기술적이든, 인간적이든 진실만 말하고 싶다.

만약 조금 이라도 영향력이 생겨서 IT 환경에 도움이 된다면 많이 알려 졌으면 좋겠다.

솔직히 프로젝트를 망치고, 생각보다 허접함이 들통나서 한방에 훅 가도 상관없다.

“나 처럼 잃을게 없는 사람만이 할수 있기 때문 이다”

최근 영어 리딩을 위해서 하루에 조금씩 보고 있는데.. 오늘 읽은 것중에 인상 깊은 내용 소개.
오늘날 비누, 샴프 등 세정제로 유명한 P&G 회사의 일화.
원래 이 회사는 “양초”를 만드는 회사였는데 19세기 후반에 전구에 발명으로 한 순간에 망할 위기가 찾아 온다.
그렇게 희망없는 나날을 보내다가 “큰 변화의 기회가” 우연히 찾아 온다.

직원들이 점심 먹으로 가면서 기계를 Off 하지 않고 갔다. 갔다 와서 보니 양초가 아닌
전혀 이상한 물질이 만들어 져있었다.
그걸 보고 직원들은 어떻게 하면 사람들이 새로운 물질을 사용할수 있을까 고민하다가 결국 “비누”로 발전 시켰고, 그 유명한 “아이보리 비누”를 만들면서 초대박이 터졌다.

실수를 두려워 해서도 안되고, 위기 다음엔 역시 기회가 찾아 온다는 믿음.

마지막 문구가 인상적 이다.
“a mistake can be a chance for success”

다수의 개발자들과 플젝을 해보면 개발에 대한 정치적 성향을 알수가 있다.
1. 오랫동안 검증된 것만 사용하자 (보수)

2. 다양한 기능을 제공하는 신기술을 도입해 보자. (진보)

3. 검증, 기술 보다 막내부터 고참까지 다 알수 있는 것을 쓰자 (사회주의)

하지만 진정한 개발자, 아키텍트는 이런 개발 이데홀로기에 치우치지 않고, 모든걸 고려한 합리적 사고가 필요 하지 않을까..

저는 정기적으로 SI 인력 소싱 업체 이사님들을 만납니다.
만나는 이유는 개인적 친분도 있지만, 또 하나 큰 이유는 SI 분위기를 파악 하기 위해서 입니다.
이분들은 개발자들의 소리도 듣고, 고객의 소리도 듣기 때문입니다. 그리고 다양한 사이트의 정보 또한 알기 때문에 가장 리얼한 정보들을 갖고 계십니다.

이런 저런 얘기를 하던중 고객 (여기서는 PM 또는 PL 입니다) 들이 예전 보다 더 나이든 개발자 와 일하는 것을 꺼려 한다고 합니다.

일반적으로 PM들은 대부분 35세 ~ 42세 정도가 가장 많습니다.
그래서 “왜 나이든 개발자를 꺼려하는가?” 에 대한 질문을 했더니 이렇게 말씀 했습니다.

“나이든 개발자들은 요새 중급들 보다 개발을 못하더라고.. 그리고 자기 보다 어린 사람이 뭐라고 하면 자존심 엄청 내세우고, 열심히 하지도 않어.. 그럼에도 불구 하고 급여는 경력대비 많이 달라고 하니 누가 쓰겠어..”

사실 이 부분에 많은 공감을 합니다. 저도 프로젝트를 리딩해 보면 많은 수의 고급 개발자 분들
중에서 이클립스 사용법도 잘 모르고, REST/Json 개념도 모르시는 분도 많습니다.

프레임웍 교육을 하면 초,중급 개발자들은 엄청
배우려는 의지가 강하고, 서점 가서 책을 사서
공부 하는 데.. 고급 분들은 끝까지 책도 안사고,
매번 똑같은 질문을 반복해서 물어보고,
심지어는 초,중급 개발자가 고급 개발자에게 알려주는 현상은 더 이상 플젝에서 흔한 일이 아닙니다.

여기서 말씀 드린 나이든 개발자의 기준은 30대 후반 부터 ~ 40대 를 말합니다.

저도 나이가 39세이기 때문에 약간의 변호를 하자면 저희 세대는 4GL -> ASP 시대의 개발자
입니다.
그때는 지금 처럼 구글 검색 버튼 하나로 아키텍쳐 튕겨나오는 시대도 아니었고, 지금 처럼 쉽게 설명한 책도 없었죠…
거기다가 아키텍쳐 개념도 없이 개발자라면 밤새고 IDC 에서 서버 소리 들으면서 자는게
개발자의 실력인냥 하는 시대 였습니다.

그리고 어차피 40에 손 털거 그냥 그때까지
버티고, 못 버티면 닭집 사장 하자는 마인드
였습니다.

어떻게 보면 스마트한 후배 와 닷컴 1세대에 낀
과도기 개발자 세대라고 생각 합니다.

하지만 변호는 여기 까지 입니다.
현실로 다시 돌아오면 솔직히 그다지 내세울 것도 없는데 왜 “민폐고급”, “진상고급” 이미지를
주어야 하는 것일까요?

평생 개발자의 삶은 생각보다 쉽지 않습니다.
뛰어난 기술만으로 평생 개발할수 없다고 생각
합니다.

“자존심, 고집을 버리고 후배들 과
어울릴수 있는
노장의 여유로움 과 오랜 경험에서의 안정감이
더 중요하다고 생각 합니다.
그리고 체크 포인트를 해주지만, 후배들에게
기술적, 아키텍쳐적으로 기회를 많이 줄수 있는
너그러움도 필요 합니다.”

그리고 실력이 뛰어나거나 롤이 크면 거기에 상응 하는 금전적 예우를 받아야 하지만
그렇지 않은 경우는 적정선에서 욕심 없이
합의 하는 것도 좋습니다.

저 같은 경우도 몇몇분들이 롤 대비 경력이 많다는 이유로 큰 금액을 요구 하니 좋은 일이 있어도 연락을 못드리게 되더군요..

마지막으로 꾸준한 자기 관리 와 학습 입니다.
요즘 시대에 “내가 해봐서 아는데..”라는 말을
쉽게 하는 사람이 있을까요?
쉽게 말한다면 대부분 “립코더” 라고 봐야죠..

고급의 가장 큰 무기인 “내가 해봐서…”
는 오히려 old한 이미지만 심어 줍니다.

이러한 고급의 이미지가 선행되지 않으면
아무리 IT 환경이 개선 된다 하더라도 평생
개발자는 힘들 것입니다.

지금까지 얘기는 고급 개발자분들 전체를 말씀
하는게 아니고 .. 저를 포함해서 다시 한번
현실을 되돌아 보는 기회가 되었으면 하는 바램
입니다.

제 주위에 보면 자비로 웹호스팅 서비스 신청해서 프로젝트 와 무관한 “하둡” 공부하는 30대
후반 개발자, 프로젝트 자동화의 중요성을 인식
시켜서 jenkis + maven 도입을 강하게 주장
하는 42세 개발자.. 정말 열정 과 인성을
갖고 있는 분들이 더 많습니다.

마지막으로 후배들은 최신 트렌드, 기술 모른
다고 무시하지 말고, 귀찮더라도 잘 알려주고
대신 값진 경험을 전수 받길 바랍니다.
선배들이 롱런해야 본인들도 롱런 할수 있습니다.

아무쪼록 오랫동안 얼굴 보면서 IT에서 다 같이 일했으면 합니다.

주말(28 일)에 친구 모임이 있어서 가는 중에 와이프가 “자기야 큰일났어 카톡 장애 났나봐” 하면서 마치 국가 전산망이 마비 된냥 호들갑을 떨었습니다.
그래서 한마디 했습니다.
“글면 문자로 보내.. 그리고 무료로 쓰면서 장애 나면 기다릴줄도 알아야지..”
그날 실시간 검색이 “카톡장애”, “카톡대란”, “카톡속보” 등 핫이슈 였습니다.
그도 그럴것이 가입자가 4천만이 넘고, Active 사용자가 2천만이 넘으니.. 단순 메신져 수준이 아닌 국민 대표 메세지 서비스란걸 새삼 느꼈습니다.

저는 카카오 직원도 아니고, 따로 친분도 없지만 같은 IT하는 사람으로써 약간의 억울함도 있을듯 합니다.
기부금을 보내준것도 아니고, 건당 돈을 받는 것도 아닌 무료 서비스인데 장애나면 그럴수도 있지…잠깐 장애 났다고 떠드는 언론이나 고객들이 좀 야박하다는 생각이 들수도 있다고 생각이 듭니다.
(물론 유료 서비스도 하기때문에 장애 대한 책임은 있습니다.)

그리고 아직은 대기업 수준의 물량의 인프라를 갖기 어려울 것입니다. 그럼에도 불구 하고 4천만 가입자을 처리 할수 있다는건 카카오 엔지니어분들의 내공 과 열정과 정성이 대단하다고 생각 합니다.

하지만 약간 아쉬움도 있습니다. 개인적으로 해외 사례를 비교하는 걸 좀 싫어 하지만 Facebook 초창기때 갑자기 User가 늘어 났었습니다. 그때 돈이 없어서 서버 확장을 못했습니다. 안절부절 못하다가 결국 선택한 것이 서버 확장이 가능 할때까지 사용자 가입을 하지 않는 것이 었습니다.

또한 초창기 핀터레스트는 누구나 가입이 됐지만 최근 폭발적인 증가로 가입 신청을 한후 검토후 하루 또는 이틀 후에 연락이 옵니다.

즉, “현재 내가 최적의 상태를 유지 가능한 범위에서 솔직히 고객에게 양해를 구하면서 확장할 필요가 있다는 것입니다”

오히려 이런한 것은 좋은 효과를 볼수 있습니다. 서비스를 받는 것에 대한 특권 같은 느낌과 고객으로 하여금 더욱 관심을 갖을수도 있습니다.
아이패드가 물량이 적다고 애플에 욕하는 사람은 많지 않습니다. 한계를 말하기 때문에 고객들이 이해 하는 것이죠.
그러다 보니 줄까지 서고, 그게 또 이슈화가 되서 마켓팅 효과도 볼수 있구요.

스타트업을 준비 하시거나 또는 진행 중인 곳이 있다면 길게 보면서 진솔한 모습을 보여 준다면 고객이 더 신뢰 하지 않을까 생각 합니다.
(카카오가 진솔하지 않다는 것은 아닙니다. 오해 하시지 말았으면 합니다)

우연히 검색을 하다가 괜찮은 사이트를 알게 되었습니다.
사이트 명은 “vschart.com” 입니다.
간략하게 설명을 드리자면 최신 IT기술, 트렌드의 feature들을
한눈에 비교를 해주는 외국 서비스 입니다.
비슷한 기술들이 많아서 일일이 그들의 feature를 분석하기가
어려운데.. 막상 사용해 보니 많은 도움을 받을수 있습니다.

각설하고 사용법에 대해서 설명 드리겠습니다.
Play Framework 과 Ruby on Railse를 비교해 보도록 하겠습니다.

1. 먼저 접속을 한후, 상단 검색 입력창에 “play” 라고 입력 합니다. 검색 결과에서
   “Play Framework“을 선택 합니다.

2. 조회를 하면, feature에 대한 기능 지원 여부를 확인 할수 있겠습니다.
  “Ruby on Rails” 와 비교하기 위에서 오른쪽에 “Ruby on Rails“를 선택 합니다.

3. 조회를 하게 되면 feature에 대한 지원 여부를 비교하면서 쉽게 알수있습니다.

4. 이번에는 “Ruby on Rails” 와 “Spring”을 비교해 보겠습니다.
   주제를 바꾸려면 상단 검색어를 사용할수도 있고, 상단에
   바뀌려는 텍스트 링크를 선택합니다.
 

5. 오른쪽 카테고리에서 “Spring“을 선택 합니다.

6. 조회를 하면 “Ruby on Rails” 와 “Spring” 비교 화면을 확인 할수있습니다.

이외에도 “MongoDB” vs “Cassandra” 또는 “아이패드2” vs “갤럭시노트”
등 다양한 주제별 비교도 할수있습니다.