BeyondJ2EE

최근 달라진 나의 아키텍쳐

Mon, 01 Apr 2013 12:08:35 -0400

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이제 정보도 공감이 필요 하다

Sun, 10 Mar 2013 11:50:41 -0400

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

개발자들의 고민들

Thu, 28 Feb 2013 12:37:26 -0500

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«고급편»

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

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

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

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

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

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

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

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

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

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

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

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

정말 자바가 위기 인가?

Sun, 24 Feb 2013 11:39:50 -0500

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

나의 존재에 대해서..

Tue, 29 Jan 2013 13:15:34 -0500

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

실수는 성공의 기회

Mon, 21 Jan 2013 11:07:04 -0500

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

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

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

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

개발자의 정치적 성향..

Sun, 20 Jan 2013 11:21:45 -0500

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

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

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

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

나이든 개발자 와 일하기 싫다..?

Tue, 15 May 2012 12:48:24 -0400

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

카카오톡 장애에 대한 생각

Sun, 29 Apr 2012 12:37:38 -0400

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

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

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

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

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

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

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

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

기술 비교 사이트.. 강추!!

Fri, 27 Apr 2012 05:03:26 -0400

우연히 검색을 하다가 괜찮은 사이트를 알게 되었습니다.
사이트 명은 “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 “갤럭시노트”
등 다양한 주제별 비교도 할수있습니다.

연동 과 연계의 차이점

Thu, 05 Apr 2012 13:08:13 -0400

가끔 프로젝트를 하다 보면 “연동” 과 “연계” 란 말을 들어 보셨을 겁니다.
저도 IT 경력 10년이 지나도 정확한 그 의미를 이해를 못했으며 또한 명확하게 설명 하는 분도 드물었습니다.
어떻게 보면 개념이 복잡 하다기 보다 무관심이 아니였나 싶습니다. 그래서 좀 나름 정리를 해봤습니다.

먼저 “연동”을 보면 영어로 System Link라고 할수 있습니다. 좀더 명확하게 설명 하자면 peer to peer 관계. 즉 단순 client 와 server 관계의 연결 할때를 말합니다.
예를 들면 “트위터랑 연동” 한다라고 하지 “연계” 한다라고는 하질 않습니다.
또는 WAS에서 MySQL를 “연동 한다” 라고 하지 “연계 한다” 라고 하지 않습니다.
특히 “연동”이란 말은 업무 도메인이 서비스업 또는 이통사에서 많이 사용 합니다.
제가 오랫동안 근무하고 있는 이통사 에서는 “연동” 이란 말을 많이 쓰고 “연계”란 말은 거의 쓰지 않습니다.

반면 “연계”는 영어로 System Integration 입니다. 어떻게 보면 “연동” 보다 더 크고 많은 걸 포함하는 의미 입니다.
구현체로 설명 하자면 내부 Gateway 서버 또는 EAI , ESB 를 일것 입니다.
“연계”는 Use Case에 가까운 표현을 사용 합니다.
예를 들면 “온라인 등본 조회” 라고 하면 클라이언트는 GW에 요청을 하고, 해당 동사무소에 등본 정보를 가져오고, 이력을 행장부에 저장한다 라고 가정 하면 각 시스템 간은 “연동” 이지만 전체 연동 flow를 처리 하는 걸 “연계”라 합니다.
이러한 aggregation 하는 시스템을 “연계 시스템” 이라고 합니다.
상용 ESB군을 많이 쓰는데 사실 뚜껑을 열면 단순 라우팅 정도만…
주로 이런 용어를 사용하는 업무 도메인은 “공공” , “쇼핑몰” 입니다.

앞으로 “연동” 과 “연계”를 동일하게 생각 하시지 말고 프로젝트시 구성원들 끼리 용어 통일이 필요 합니다.

프로젝트에서 제일 중요한 프로토콜은 구성원간의 커뮤니케이션 용어 입니다.

안드로이드 / 아이폰 앱 개발자 SI 시장 분위기

Thu, 29 Mar 2012 03:02:42 -0400

제가 이번주 업계 정보통인 IT 업계 파견 소싱 업체 및 몇몇 분과 얘기를 하면서
안드로이드, 아이폰 개발자 수요에 대해서 물어 봤습니다.
결론 부터 말하면 SI 시장에서 앱 개발자의 수요는 다소 어두운 편이 었습니다.

2년 전만 해도 안드로이드 개발자는 시장에서 부르는게 값일 정도로 “중급“임에도
불구하고 “특급” 대우를 받으면서 일을 했었습니다.

하지만 지금은 경력이 고급이더라도, 시장 자체의 수요가 중급 이상이 되지를 않기
때문에 고급 경력인 경우는 “다운 사이징“을 해서 일을 하는 분위기라고 하는 군요.

심지어는 프리랜서 시장에서는 “Waiting List” 에 등록해서 대기하는 정도로 상황은
그다지 좋지가 않네요.
그리고 프로젝트 기간도 단기성 1 ~ 2개월 정도라고 하는 군요….

아무래도 국내/외 앱 스토어에 이제는 왠만한 것들은 다 있고, 업체 입장에서도
앱 개발 시장 자체가 수입이 그다지 좋지 않아서 일것 같다는 생각이 듭니다.

하지만 “HTML5” 개발자에 대한 수요가 점점 증가 추세이고, 앞으로
기업에서 더 많은 수요가 예상되는 분위기라고 합니다.

다소 의외의 반전은 “플랫폼/서버 개발자”는 현재 인력 구하기가 너무 어렵다고
합니다. 즉 수요가 엄청 많다는 것입니다.

몇년전 안드로이드 한다고 떠났던 동료, 후배들을 보면서 씁쓸했던 기억이
나는 군요.

모든 IT 분야가 그렇지만, UI 같은 좀더 트렌디한 분야는 선점이 중요하며,
그 시기가 지나면 점점 수요가 둔화가 됩니다. 그렇기 때문에
지속적인 학습이 필요 할것 같고, 플랫폼/서버 파트도 요새는 공부를 안하면
안되지만 그래도 깊이 있는 학습 과 경험이 중요한 것 같습니다.

그렇다고 영원히 “플랫폼/HTML5” 개발자가 수요가 항상 장미빛일 거라곤
생각하지 않습니다. 시장은 유동적으로 변화기 때문입니다.
개발자는 개발도 잘하고, 최신 기술도 중요하지만, 때론 시장에서
나의 가치는 현재 어느 정도인지 인식하는 것도 중요하다고 생각이 드네요…

최근 하시는 SI 프로젝트의 성격은 어떠세요? 라고 @madvirus님께서 물어 보신것에 대한 답변

Wed, 28 Mar 2012 09:20:00 -0400

현재 근무 중이고, 이전에 했던 프로젝트에 대해서 말씀 드리는 것 자체가 개인적으로 다소 예민하고, 말씀 드리기가 조심 스럽긴 합니다.
그리고 제가 일하고 있는 환경이 꼭 국내 SI 환경이 같다는 귀납적 판단은 안했으면 합니다.
1. 기술적인 부분
제가 일하는 도메인이 서비스쪽 이어서 프로젝트자체가 차세대급은 아니지만 버금가는 규모를 합니다. 거기다가 연동 포인트도 많습니다. 최근 까지는 그냥 업체에서 만든 프레임웍이나 구글링 통한 구현을 하다보니 스파게티가 되고 일정리스크가 발생을 하고 있습니다.
그래서 조금씩 Application Architect(이하 AA)를 정식 role로 지정 하는 추세 입니다.

그리고 비용절감 과 다양한 서비스 지원을 위해서 큰 이슈가 없는 한 상용제품을 쓰지 않고 오픈 소스를 사용 합니다. 그래서 기술 선택 과 아키텍쳐링은 선정은 AA가 합니다. 하지만 주로 인프라쪽은 특히 OS, WAS, WebServer, DB는 운영팀에서 선정 하는 경우가 많습니다.

하지만 최종 확정에 대한 합의는 PMO 그룹 과 협의후 확정 합니다. 개발 언어는 역시 자바 입니다. 물론 대용량 처리 하는 백엔드 서버들은 C로 만든 서버들도 있고, 통계를 위한 Oracle DW군들 같은 상용툴도 많이 있습니다 자바를 사용하는 이유는 역시 인력 수급 과 운영 관리에 강하기 때문 이고, 무엇보다 다양한 오픈 소스의 지원이라고 할수 있습니다. 정말 특별한 경우가 아니면 PHP나, 루비, 스칼라, 그루비 같은 이기종 언어를 사용 하지도 않고, 사용 할수도 없습니다.
시스템 자체가 복잡 하기 때문에 최대한 자유도를 줄이고 표준 과 통합을 포커스로 합니다.
하지만 최근에 파일 업로드나, 채팅 같은 부분에서 NodeJS 같은 비자바계열도
많이 관심을 가지려고 합니다.

또한 최신 기술에 대한 이해또한 필요 합니다. 비유 하면 보수적 진보 주의자가 맞는 것 같습니다. 개발툴은 무조건 이클립스 입니다. 가끔 다른 툴을 고집 하는 분도 있습니다.

그래도 무조건 이클립스로 통일 시킵니다. 형상관리 같은 경우 최근 Git 바람이 불지만 SVN 으로 하고 있습니다. 가끔 버그가 있지만 참을만 합니다. 무엇보다 포지션이 적은 부분을 참여하는 개발자 러닝커브로 투자할 여력도 안되고, 그로인한 일정은 리스크로 다가 오기 때문 입니다. 심지어 제가 리딩한 플젝은 JDK, Maven, Tomcat 디렉토리까지 같습니다. 이유는 그 많은 사람 일일이 IDE 트러블슈팅 해줄 시간이 없기 때문 입니다.

주 프레임웍은 Spring 입니다, WebService, Batch, Scheduler, TcpServer, ESB 등 전부 사용을 하고 있고 버전은 3.1을 사용 합니다. MVC, REST도 스프링꺼를 사용 합니다. SpringMVC가 무겁다고 하지만 그렇다고 못쓸정도 아니기 때문 입니다.

대신 얻는 이점이 너무 많기 때문이고 성능 검수시 스프링 MVC가 문제 된적은 없습니다. ORM은 MyBatis로 사용을 하고 있습니다. JPA 사용 하고 싶지만 많은 리스크가 있습니다.

기술적 리스크는 아니구요. 다음에 기회되면 적용 검토 중입니다. UI는 역시 jQuery를 사용 합니다. 가끔 GWT를 사용 할때도 있습니다. 빌드는 Maven +Nexus+Jenkins+Puppet을 사용 중입니다. Ant도 쓰긴 하지만 다수의 프로젝트를 빌드 하려면 Maven 아니도는 엄두가 나질 않네요. DB는 요새는 거의 MySQL Sharding을 주 DB로 사용을 하고 있습니다.

NoSQL은 음… SI 입장에선 아직까지 Optional 중 Optional 이라서 사용을 하지 않고 있습니다. 개인적인 생각인데 SI에서 클라우드 기술에 대한 관심은 하둡이 많기 때문에 학습한다면 귀닫고 하둡만 하는게 어떨까 합니다.

현재 제가 있는 쪽은 마이그레이션 이라서 크리티컬 + 성능 두 가지를 고려해서 RabbitMQ + Apache Camel를 통한 Queue 로드 밸런싱을 고려중이고 Quartz쪽도 deep하게 구현을 할듯 합니다. 가끔 TCP 서버 또는 비동기 처리에 Netty를 사용 하기도 합니다.

또한 정해진 건 없지만 로그 수집을 위해서 Flume + Haddop을 고려 중인데… 많은 머신의 로그를 수집해야 하는 것 때문에 LogBack AMQP Appender + ZeroMQ + Hadoop 조합도 생각 중이긴 합니다. 레거시 시스템 로그는 FTP + Apache Camel Polling + Hadoop도 있구요..
또한 splunk 같은 상용 툴도 고려 중입니다.
중요한건 아직 정해진게 없다는 것… ㅠㅠ

모니터링쪽은 cacti, Nagios를 사용하고 있습니다.
이번 플젝은 Meta DB로 카산드라를 사용 하고 있습니다. 물론 위에 언급한 기술을 제가 다하는 건 아니구요 ^^
아 그리고 OS는 CentOS를 사용 하고, webserver/was는 Apache, Tomcat 입니다.

그밖에 많은 서브성 오픈 소스도 많이 사용 합니다. 버전 선정은 프로젝트가 중장기다 보니 현재 버전중 최근 것을 사용합니다. 때론 베타쓰고 정식으로 플젝중에 교체 하는 경우도 있습니다. 하지만 대다수 사이트는 Spring + MyBatis+X-Internet이 주류 입니다.

무엇보다 AA가 거의 선정 하지만 어떻게든 책임을 져야 하기 때문에 단순히 기술위주로 접근 하면 안되고 일정, 개발자 수준, 기술이슈등 전체적으로 고려 해야 하기 때문에 실무 경험이 많이 필요 하고, 핵심은 커뮤니케이션 이죠.. 아참 wiki는 전에는 confluence를 사용했고, 지금은 PBWorks를 사용하고 있습니다.

2. 근무 요건
이건 정말 장담하는데 국내 SI환경에서 근무 요건이 좋은데가 있을지 부터가 의문 이네요.
개발자는 많고, 임대 비용을 줄이기 위해서 모니터 두개놓으면 끝나는 좁은 공간에서 일하는 경우가 많습니다. 출근은 9시,9시30분 정도 합니다.
퇴근은 저 같은 경우 거의 6시에 퇴근 하지만 거의 집에서 일을 다 하죠. 하지만 일많을 때는 야근의 연속이고, 주말 때론 새볔에 이클립스 없이 터미널에서 컴파일 할때도 있습니다.

그리고 업무는 복잡해 지고, 기술은 많은데 일정은 턱없이 짧아 졌습니다. 최근에는 일정 자체가 산정이 되지 않아서 프로젝트가 지연 되는 건 더이상 큰 이슈도 아닙니다.

거기다가 아직도 전문 그룹 인식 부족으로 책임을 개발자들이 지고 있습니다.
특히나 제가 있는쪽은 일명 “헬” 이라고 불리는 도메인이죠… 솔루션에서 엔진 개발 하신분도 한번 하시고 바로 GG 칠 정도시니… 이건 저 뿐만 아니라 국내 SI의 총체적 난국 이라고 마무리 하고 싶네요.

3. 인력 구성원
최근 처럼 IT인력난이 심해지면서 자기 입맛에 맞는 팀원 셋팅은 포기 하는게 좋습니다.
특히나 SI처럼 각양각색의 많은 사람들이 모여서 할경우는 더더욱 그렇습니다.
그리고 특히 고급들도 개발만 하려고 합니다. SI에서 서버 플랫폼 기술력을 갖춘 사람은 정말 찾기 어렵습니다.
인력구성은 PMO를 중심으로 밑으로는 PL이 있고, PL은 회의하는라 정신 없어서 밑에 ML 이라고 Module Leader들이 실제 분석/설계를 합니다.
주로 고급 분들이죠. 그밑으로 중급 개발자들이 포진 하는데 업체들 마진 때문에 초급들이 많이 들어 오죠.
현재 저희는 고급이 더 많은 것 같습니다. 이렇게 응용 어플리케이션 팀이 꾸려 지고, 그 다음 전문 텍트 그룹이 있습니다. DA,TA,AA,SE 이렇게 구성 되죠.
저 같은 경우 리눅스를 안만진지 5년이 넘습니다. 그 정도로 어플리케이션 설계/구현 하는데도 턱없이 부족 하기 때문 입니다.
주로 TA,SE 그룹들이 서버 설정, 네트워크, 보안 패치등 업무를 합니다. 그리고 안드로이드, 아이폰 같은 앱 전문 팀도 들어 옵니다.
대부분 개발자는 정해진 개발가이드를 통해서 비즈니스 컴포넌트 와 UI를 개발합니다.
웹 디자인너, 퍼플리셔는 HTML 작업후 개발자에게 넘기죠. 업무 Flow는 “갑” -> PMO -> 기획팀 -> PL -> 개발자 이렇게 흘러 간다고 보시면 됩니다. 저의 얘기가 조금이나마 도움이 되길 바랍니다

트위터를 시작한지 벌써 1년 반 정도 된것 같습니다. 시작한 이유는 기술공유 와 막장 SI라도 적지 않은 경험을 조금이나마 알려 주기 위함 이었습니다. 그리고 SI를 하면서 어린...

Fri, 23 Mar 2012 13:59:08 -0400

트위터를 시작한지 벌써 1년 반 정도 된것 같습니다.
시작한 이유는 기술공유 와 막장 SI라도 적지 않은 경험을 조금이나마 알려 주기 위함 이었습니다.
그리고 SI를 하면서 어린 아들을 키우는 시간적 버거움 속에 트위터는 저에게 최적의 온라인 커뮤니티 입니다.
그런데 어떻게 트윗이 흘러가는지 최근에 알아 보시는 분들이 부쩍 많이 늘었습니다.
솔직히 많이 부담 스럽다는 생각이 듭니다.
전문 지식이 있는 것도 아니고 단지 SI 할때 적용 수준인데 거품이 많이 끼어 있는 것 같다는 생각이 들더군요.

그리고 대부분 안본 것들을 트윗 하게 되고, favorite은 쌓여만 가는 것을 보면서.. 한심하다는 생각이 듭니다.
또한 이제는 최신 기술이나 정보는 누구나 쉽게 얻을수 있습니다.
제 리스트중에서 “enterprise” 를 following 하면 자바 관련 최신 소식은 다알수 있습니다.

결정적으로 허무 한것은 그렇게 많은 정보들이 막상 실무에 사용하거나 도입되는건 거의 없다는 것입니다 (제 사이트 기준)

요새는 책 보다 기술 블로그나 트윗을 보면서 마치 해본냥 또는 모르면서 아는 척 할때 속으로 뜨끔 합니다.

예전 500페이지 넘는 in action 씨리즈를 한달 동안 보면서 만족해 하는 초심으로 다시 돌아 가야 할때가 아닌가 생각이 듭니다.

그리고 정보성 트윗은 자제하고, 자주는 아니지만 직접 작성한 글을 써야 겠다는 생각이 듭니다.

앞으로 좀더 깊이 있는 정보를 전달 하도록 노력 하겠습니다

RSS 검색 엔진 사용법

Fri, 09 Mar 2012 01:07:00 -0500

RSS 검색 엔진 사용법

Puppet 설치 하기

Thu, 08 Mar 2012 01:44:52 -0500

Puppet 설치 하기:

설치하면서 간단하게 정리해 봤습니다.

SI 개발자들도 충분히 기술 공유를 할수 있다.

Wed, 07 Mar 2012 13:04:47 -0500

SNS 또는 온오프라인 에서 활발하게 서로 공유하고, 커뮤니케이션을 많이 하는 분들은 대게 기술에 관련된 개발자 , 기술 에반 젤리스트, 아키텍트 그룹인 경우가 많습니다.
특히 포털, 게임, 솔루션, 요샌 클라우드에 근무 하신분들 특히 더 많이 활동하고 계시는 것 같습니다.
하지만 의외로 SI에 종사하는 분들은 많지 않은 것 같습니다.
더욱이 SNS에서는 거의 찾아 보기가 힘들 더군요.

그렇다고 커뮤니티나 스터디 모임은 더 드문것 같습니다.
간혹 개발자분들게 잘 활성화 되지 않는 이유를 물어 보면 가장 큰 이유가 “시간이 없다” 는 것일 겁니다.

저도 SI에 있기에 “너만 바쁘냐?” 라고 못할 정도로 바쁜건 사실 입니다.
두번째는 “기술적으로 많이 아는게 없고, 정보를 공유 할게 딱히 없다” 라는 이유 입니다.

그래서 두번째 이유에 대해서 의견을 말하고자 합니다.
SI도 이제는 기술집약적 입니다. 하지만 일부 아키텍트 팀이 있어서 대부분 개발자 분들은 정해진 가이드 되로 하기만 하면 됩니다.

스트럿츠, 스프링, REST 몰라도 템플릿 만든거 사용하기만 하면 되기 때문에 기술에 대한 필요성이 상대적으로 적습니다.
하지만 정말 다양한 비지니스 use case 와 복잡하고 , 정리 안되는 업무를 분석 하고, 설계하고, 구현 하는 건 어려운 기술을 다루는 개발자와 못지 않은 능력을 같고 있다고 생각 합니다.

그러면 SI 개발자분들은 어떤걸 공유해야 할까요? 제 생각에는 현재 근무 중인 사이트의 업무에 대해서 데이터, 어플리케이션 모델링에 대해서 공유하고, 정보를 나눌 필요가 있다고 봅니다.

즉 실무 레퍼런스는 정말 누구 보다 값진 정보 입니다.
보안상 세세하게는 못해도 일반적인 어플리케이션 설계 기법은 충분한 가치 입니다.

UML 기법, DDD, TDD, 리팩토링, 인터페이스 설계 등 .. 실무 기반으로 공유해 나간다면 최신 기술 못지 않은 엄청난 파급 효가 있는 기술 이라고 생각 합니다.
금융, 공공, 이통사, 제조, 유통, 쇼핑몰등…

최신 기술만이 개발자 능력은 아니라고 봅니다. 음악도 팝송 , 가요가 있으면 째즈, 클래식도 필요 한것 처럼 말이죠.

그리고 SI 개발자 분들도 상당히 많이 계시는 걸로 알고 있습니다.

그리고 생각 보다 많은 분들이 실무 Use Case를 듣고 싶은 분들이 많을 것 입니다.

그냥 저의 생각은 실무적 어플리케이션 아키텍쳐 그룹이 활성화 되고, 또 기술리더 그룹도 활성화 전체적인 밸런스가 맞는 멋진 한국 IT가 됐으면 하는 개인적 바램 입니다.

SI 개발자분들은 엄청난 SW자산을 가지고 있다는 걸 잘아시고, 프라이드를 가졌으면 좋겠습니다. 화이팅!!!

보이스 오브 코리아 올턴(All Turn) Voice

Sun, 04 Mar 2012 07:09:00 -0500

신델레라 - 배근석 -

미아 - 강미진 -

10 Minute - 유성은 -

내가 웃는게 웃는게 아니야 - 이소정 -

헤어지는 중입니다. - 이은아 -

애모. - 선지혜 -

유능하고 똑똑한 팀원을 이끄는 리더쉽

Thu, 01 Mar 2012 07:38:00 -0500

“필 잭슨” 감독은 평생 단 하나를 얻기도 힘들다는 미국 프로농구(NBA) 우승 반지를
무려 13개나 가진 사람 입니다.
잭슨 감독의 리더쉽은 “스티브 잡스“의 리더쉽 과는 좀 다른 면을 갖고 있습니다.
그의 리더쉽의 특징은 “마이클 조던”, “스코티 피펜”, “샤킬 오닐”, “코비 브라이언트” 등
자존심 강하고 콧대 높기로 유명한 슈퍼 스타 선수들을 현명하게 조련하고
이들에게 팀워크의 중요성을 주입해 누구보다 탁월한 성과를 얻어 냅니다.
즉 유능하고, 뛰어난 선수를 얼마나 잘 다스릴 줄 아느냐 중요함을 입증한 사람 입니다.

제가 4,5년차 시절 그때는 지금 처럼 정보도 없었으며, 고참 또는 팀장 같은 리더의
경험이 최고의 솔루션이면서 진리였습니다.
하지만 지금 이시대는 너무나도 많이 바뀌었습니다. 블로그, 트위터, 논문, 오프라인
등 다양한 채널로 고급 정보 뿐만 아니라 심지어 리더도 경험을 못한 레퍼런스까지
쉽게 얻을수 있는 시대 입니다.

그러다 보니 비록 경력이 많지 않더라도, 주위에서 보면 깜짝 놀랄 정도의 전문 지식과
논리를 갖고 있습니다. 심지어는 배우는 경우도 많습니다.
누가 팀원이고 , 팀장인지 구분이 모호해 지는 시대 입니다.

그러면 이러한 우수한 인재급 팀원들이 많으면 예전 보다 낫고, 부러워 할수도 있지
않냐라고 할수도 있지만 실상은 그렇게 녹녹치만은 아는것 같습니다.
리더들은 피곤한(?) 팀원을 이끄는데 있어서 많은 답답함을 호소하고, 피곤한 팀원들은
유연함이 없고, 전문지식이 본인보다 떨어지는 리더에 대해서 고민을 많이
하는 경우를 봅니다.

그래서 좀 지났지만 2007년 9월 2일자「LG주간경제」에 실린 박지원
선임연구원의 ‘나보다 똑똑한 부하 직원을 리드하는 방법’ 이란 글을
다시 한번 보면서 리더, 팀원 둘다 지혜를 얻었으면 합니다.

—————————————————————————————————————-———————
(나보다 똑똑한 부하 직원을 리드하는 방법)
똑똑한 구성원을 이끄는 5가지 방법

리더십 상황 모형을 제시한 허시와 블랜챠드(Heresy & Blanchard, 1980)는
구성원의 성숙도에 따라 각각의 구성원에게 다른 리더십을
적용할 필요가 있다고 말한 바 있습니다. 성숙도가 높은 구성원 즉,
전문적인 지식을 갖추고 있고 기술의 깊이도 뛰어나며 자신감이나
자부심이 강한 구성원에 대해서는 보다 차별화된 리더십을 발휘할
필요가 있다는 것입니다.
리더보다도 더 똑똑하고 우수 한 부하 직원을 리드하는 방법은
다음 5가지로 요약할 수 있습니다.

1. 건설적 논쟁을 활성화하자

우 수한 구성원들은 일방적 업무 지시보다는 리더와의 커뮤니케이션이
원활할 때, 이슈를 보다 명확하게 이해하고 효과적인 대안을 찾아냅니다.
이들은 리더와의 커뮤니케이션하면서 자신의 의견을 자유롭게 피력하는 과정에서,
자신이 리더로부터 존중 받고 있다고 느낄 뿐 만 아니라 신바람이
나서 업무에 몰입하게 됩니다. 따라서 리더는 이들과의 커뮤니케이션을
활성화시키고 건설적인 논쟁을 통해 성과 를 창출할 수 있도록
해야 합니다.
이를 잘 실천한 리더의 좋은 예로 인텔(Intel)의 앤디 그로브(Andy Grove)를
들 수 있습니다. 그는 자신의 아이디어에 도전하는 사람은 누구든 자신의
방으로 초대하여 건설적인 논쟁을 즐긴 것으로 유명합니다.
이때 앤디 그로브는 결코 그의 지식이나 지위로 상대방을
굴복시키지 않았으며, 논쟁을 통해 아이디어를 발전시키고 보다
현명한 의사결정을 하는데 많은 도움을 받았다고 합니다.

2. 단점은 덮어주고, 장점은 활용하자

리더 는 똑똑한 구성원들의 장점을 어떻게 하면 극대화시킬 수 있는지 고민하고,
성과에 크게 영향을 미치지 않는 단점은 덮어주는 현명함이 필요합니다.
‘리더의 비판을 받고 나서 일을 더 잘하거나 더 열심히 노력하는 사람을
본 적이 없다’
고 말한 찰스 슈왑 (Charles R. Schwab)의 말처럼, 리더의 비판만큼
의욕을 꺾는 일도 없습니다. 리더가 유능한 구성원의 장점을 인정하면,
구성원들의 동기가 제고되고, 리더로부터 인정받고 있다는 생각에 업무
만족도가 높아지게 됨을 간과해서는 안 됩니다.

3. 어떤 아이디어라도 칭찬하자

남들이 생각하지 못한 새로운 생각이 성공의 핵심이 됩니다.
그런데 이러한 아이디어는 똑똑하면서 창의적이며 톡톡 튀는 구성원들에게서
많이 나옵니다.
이들은 남들과 다른 시각에서 접근한 기발하거나 때로는 기이한 생각을
많이 하기 때문입니다.
이들에게 불쑥불 쑥 튀어나오는 다듬어지지 않은 아이디어를 가공하는 데는
리더의 역할이 매우 중요합니다.
‘새로운 아이디어는 연약해서 비웃음이나 하 품을 받으면 쉽게 죽어버린다‘고
말한 미국 작가 팔스 브라이어의 말처럼, 만약 리더가 우수한
부하 직원의 아이디어를 말도 안 된다 고 무시한다면 그 아이디어는
곧바로 사장되어 버립니다. 게다가 리더가 ‘지금 하는 일이나 잘해’라며
인정해주지 않을 경우, 부하 직원들은 더 이상 창의적인 아이디어를
떠올리지 않게 됩니다.

4. 구성원의 든든한 우산이 되자

조직은 우수한 인재들에게 새롭고 도전적인 업무를 맡깁니다.
특히 이러한 업무는 난이도도 높아, 누군가의 도움을 받기도 어렵고
실패 의 가능성도 매우 높습니다. 이 경우, 똑똑한 구성원들은
실패에 대한 두려움이 커지고, 도움을 받을 만한 사람이 없어
쉽게 외로움 에 빠질 수 있습니다.
고난이도의 업무를 맡기면서 실패에 대한 책임까지 지우게 된다면,
제 아무리 똑똑해도 창의적인 해결안을 찾 는 데는 소홀할 수밖에 없습니다.
실패가 두려워 새로운 도전을 시도조차 하지 않을 수 있습니다.
따라서 똑똑한 인재들이 성과를 창 출할 수 있도록 리더가 실패에
대한 질책을 막아줄 필요가 있습니다.
즉, 리더가 실패에 대한 책임을 스스로 지고,
실패를 장려하 는 문화를 구축해야 합니다.

5. 리더도 끊임없이 실력을 기르자

리더가 우수한 구성원들로부터 존경 을 받기 위해서는 리더 스스로도
실력이 있어야 합니다.
최고 수준의 실력을 요구하는 것은 아닙니다. 최소한 우수한 구성원과
커뮤니 케이션을 하고 아이디어를 줄 수 있을 정도의 지식수준을
갖출 필요가 있습니다. 이러한 최소한의 실력마저도 없다면,
우수한 구성원들 은 리더를 무시하게 되고, 이 경우 리더는 더 이상
구성원을 리드할 수 없게 됩니다.
또한 리더는 우수한 인재들에게 조언을 해 줄 수 있어야 합니다.
예를 들어 연구 역량이 상당히 우수한 연구원이 새로운 아이템을 제시할 경우,
리더는 그것이 사업화에 성공 할 수 있도록 관련된 다양한 아이디어와
의견을 제시할 수 있어야 합니다.
즉, 우수한 구성원들이 갖고 있지 못한 견해나 노하우 등 을 제공할 수 있어야 합니다.

ABB사의 전 CEO인 퍼시 바네빅(Percy Barnevik) 은 리더십이란, 리더가 자기보다 현명하고 유능한 인재를 모아서 그들의 잠재 능력을 100% 발휘하도록 하는 것이라고 정의했습니 다.

—————————————————————————————————————-———————

마지막으로 첨언 하면, 필 잭슨 감독이 “시카고 불스”, “LA 레이커스“를
우승으로 이끌었던 결정적인 이유는 “트라이앵글 오펜스” 공격 전술이 있었기 때문
입니다.

이 전술의 특징은 모든 공격자가 득점 지역 내에서 유기적으로 움직이고 모두가
패스와 득점이 가능한 전술 입니다.

이 전술의 핵심 포인트는 “이기심을 버려야” 만 가능한 전술 입니다.
시카고 불스에 정착 시키는데 3년이란 세월이 걸렸다고 합니다.

다른 것은 기억 못하시더라도 리더 와 팀원들이 이기심을 버리고, 서로
배려하며 희생 하는 것이 팀이 성공하는 길이 아닐까 합니다.

양수역 수재비 먹으로…

Thu, 01 Mar 2012 05:45:46 -0500

양수역 수재비 먹으로…