황금색 삼성 로고 그냥...

올해부터 삼성그룹의 금융계열사들은 황금색 계열의 로고 색으로 바뀌었다.

나름 신선한 맛도 있고, 뭔가 있어보이는것도 있는데...

실제로 보면.. 뭔가 좀 허전하다는 느낌과,
명함인식기(스마트폰의 스마트리더로 명함 인식을 하는것과 같은것들..)에서
인색이 잘 안된다는 단점도 있다.


앞으로 뭘 해야 할지... 그냥...

천상 엔지니어라고 생각했다.
프로그램을 개발하는게 좋았고,
개발이 아니더라도 개발과 밀접한 일을 하는게 좋았다.

근데.. 요 근래 가만히 생각하니,
취직을 하고 나서, 하는일이 개발과는 많이 떨어져 버렸다.
내 역활은 분명 Technical Architect 이지만,
주로 구매 관련된 부분과 신기술 관련된 일이 내 일이 되어버렸다.

물론 기술적인 지식기반이라고도 할 수 있으나,
개발을 한다기 보다는 좀 더 기획적이고, 관리적인 역활로 바뀌고 있는 것 같다.

더군다나, 요즘 다른 팀에서 오라고 유혹한다.

가만히 생각해 보면,
차라리 회사내에서 성공하려면 그 팀으로 옮기는게 맞을 지도 모르나,
한번 빠지면 좀 처럼 나오기 힘든일이기도 하다.

그렇다고 이대로 남아 있는다고, 기술적인 일만할 수 있는것도 아니고,
기술적인일로 성공하기도 쉽지 않은것 같은데...

슬슬 변화를 주기는 해야할듯 한데.
이번 변화는 왠만해서는 돌이킬 수 없을것 같아, 고민이 많이 된다.
뭘하든 하긴 할 수 있을것 같은데..

요즘 가장 많이 헷갈리는건..
내가 정말 하고 싶은 일이 뭔질 모르겠다는거다..
그게 정말 고민이다...
내가 진정 원하는게 뭔지를 알면... 그 어떤일이든 한번 도전이라도
하고 싶은데.. 

... 이런게 권태기라는걸까? ....

스마트폰.. 그리고 낚시질.. 그냥...

어쩌다 보니,
본의아니게, 요즘 스마트폰 관련된 테스트를 하고 있다.
정확히 말하면 FMC관련된 부분이긴 하지만,
워낙 사용자 입장에서 밀접하고 말들이 많다 보니,
그냥 FMC만 테스트하는게 아니라, 스마트폰에 대한 여러가지 방면에서 확인하고,
테스트를 하고 있는것인데..

그러다 보니,
왠만하면 만날리 없는, SKT나 KT와도 자주 만나고
여러가지 협의도 하게 된다.

그런데.. 가끔 자료를 만드느라, 웹을 뒤지다 보면,
별 근거없는 소문들이 상당히 많다.
곧 모바일 6.5로 바꿔준다는둥, 이런저런 얘기들...

어짜피 각통신회사들에 직접 연락을 해보면, 바로 알 수 있는 사실이기에..
거의 대부분 카더라 통신이나 낚시질 정도..

회사에 입사하고 나서 가끔 메스컴들을 보면..
아... 이런거였구나.. 가끔 느꼈지만..
그래도 좀 그렇다.. 그냥 흥미를 끌만한 글 말고.. 정말 영양가 있는 글들을
보는게.. 이리 힘든건가?

이제 왠만하면 소문은 잘 안믿게된다... 계속 속다 보면.. 말이지..

글구.. 스마트폰 테스트는.. 열라 짱나는일이다.. 하면 할 수록..

세미나 발표 그냥...

오랜만에 세미나 발표를 했다.

몸이 별로 안좋아서 그리 많은 시간 설명하진 못했지만,
다는 아니래도 어느정도 하고 싶은 말은 한것 같다.

근데.. 제목이 별로 마음에 안든다..
해답이라.. 난 그런 의미는 아니었는데.. 어쨋든..

디지털데일리

[BW 2009]“금융 경쟁환경 변화에 대한 대처 방법, 해답은 FMC
디지털데일리
[
디지털데일리 이상일기자] 최근 기업들이 FMC 도입을 적극 고민하고 있지만 성공적 구축을 위해선 명확한 구축목적과 경영진의 절대적인 지원이 필요하다는 주장이 ...


아키텍트 이야기... 1 그냥...

아키텍트를 한지 2년이 지나간다.

처음 아키텍트가 되면서 생각했던 것을 돌이켜서
지금 생각과 비교해 보면, 상당히 현실적이 되어 가는 느낌이다.

난 금융권의 기업에서 TA의 업무를 하고 있고,
보통 생각하는 SI나 컨설팅 또는 벤더에서 활동하는 아키텍트들과는
분명 다른 방향으로 아키텍트 업무를 수행하고 있는 듯 하다.

아키텍트가 전체 시스템에 대한 이해를 바탕으로
표준을 만들고, 검증을 하며, 프로젝트마다 검토하는 등의 업무를 수행하는데,
(그밖에도 많은 일들이 있고...)

물론 가장 필요한 지식은 폭넓은 IT적인 지식이겠지만.
실제로 아키텍트로써 전체 시스템의 윤곽을 잡는 것은

IT적인 기술보다는 우리 회사의 중장기적인 비지니스 방향성이 가장 중요한 부분이 되고,
현재 시스템에 대한 이해 그리고 IT조직 구성과 특성의 파악이 밑바탕이 되어야 한다.

요즘 들어 느끼는것인데 아키텍트가 IT적인 지식을 가장 많이 필요로 하는때는
의외인지 당연한 것인지 모르겠지만, 견적을 받을때다...

나름 좋은 말들만 뽑아서 적은감이 없지 않은데..
좀 더 현실적으로 들어 가면,
상당히 정치적인 부분도 있고, 조직에 순응해야 하는 부분...
특정인의 관심사나 생각들에 결정되어지는 부분도 의외로 많다.

나도 참 많은 영업들을 만나고, 컨설턴트, 엔지니어, 개발자들을 만나지만.
내가 예전에 프리렌서를 하면서 소위 말하는 갑들을 바라보는 눈빛을
가끔 그들에게서 보고 있다.

많은 현업들이 모르는게 많고, 답답한 부분이 많은것도 사실이지만..
막상 그런일을 하다 보면 그렇게 밖에 할 수 없는 속터짐도 조금은 있음을...
이제는 나도 어느정도는 알 수 있을것 같다.
(물론 다는 아닐것이다. 정말 답답한 인간들도 분명 있다...)

아키텍쳐의 영속성에 대해서. 그냥...

조대협님의 글을 읽고, 
항상 나도 생각했던 문제이고 보면.. 예전같으면 너무나 당연한 얘기겠지만..

사실 지금은 조금은 다른 의견이다.

회사에 입사해서 아키텍트 업무를 수행한지 이제 2년이 지나가는데,
보통 SI 나 컨설팅 업체 또는 벤더에 있는 아키텍트들과 
실제 자사내에서의 아키텍트는 업무의 범위와 역활히 확연히 다를 수 있다.

이것이 사실 전문성을 갖고, 전체 시스템을 이해하기 쉽지 않은 이유다.
하지만 뭐.. IT적인 전문성이 전체 시스템을 이해하는 절대적인 지식근거가 되지 않는것을
보면, 핑계일수도 있으나,
어느정도 규모 이상의 회사들은 그 시스템의 종류나 수준들이 참으로 다양하다.

나같은 경우도 대외적인 업무역활은 TA (Technical Architect)이나, 
시스템 (Unix , Window ...) ,  네트웍 , EAI 등의 특정 업무 및 신기술 도입과
하다못해 PC나 주변기기까지, 회사에 관련된 IT가 들어갈만한 모든것이
업무범위가 되어 버렸다. (요즘은 스마트폰같은것도 하는구나.. 참)

아직까지는 내 역활을 제대로 수행하지 못하다보니, 핑계만을 대고 있는것 같은
느낌이 스스로 드는데,

좀 더 생각해 볼 문제지만, 
업무의 범위를 어느정도 확정짓고, 전체 그림을 바라보면 여러가지 일들을 할 수 있도록.
나 나름대로 부단한 노력을 해야 겠다.

대부분의 회사에서 전체 시스템을 보면 이해할 수 있는 사람이 없는건 사실이지만.
왜 그런 사람들이 없는건인지 요즘은 조금씩 이해가 되는건...
나 스스로 너무나 우울할 일이다.

그렇게 전체 시스템을 이해할지라도,
바람직한 방향으로 무언가를 진행하는 것이 회사내에서 얼마나 힘든지 알게 되는건
더 우울한 일이다.

얼마전에 했던 닭볶음탕 그냥...

주말에는 요리를 할때가 많다.

아무래도 주중에 별로 할 수 있는게 없다 보니,
주말에 가족을 위해서 하는 내 나름대로의 서비스인데..

얼마전에 닭볶음탕을 했었다.
핸드폰으로 찍은거라 잘 나오진 않았지만.

나름 맛있게 먹었다... ^^


공부하는 둘째

어제는 지점방문을 하고, 좀 일찍 퇴근해서
오랜만에 둘째를 봤는데...
(맞벌이라.. 주중에는 애들이 처가집 있다.)

이넘이 떡하니 책상에 앉아서 책을 보고 있었다.
지금 보고 있는 책은 첫째가 공부하는 영어책인데..

도통 장난감이나 인형같은건 좋아하지 않는다고 하는데,
하루종일 책을 읽어달라고 졸라댄다고 한다.

그래서 책을 사달라고 하는데..
근데.. 책 좋아하면 좋아할일이긴 한데.. 분명..

이놈의 책값이 장난이 아니다.. 첫째 책만해도 천권이 넘는것 같은데.. 이젠 둘째것 까지..
에고.. 

PoC와 BMT 프로젝트 관련

예전에는 제안서작업이나, PoC , BMT에 참석을 해서
실제로 코딩을 하거나 오퍼레이팅을 할일이 많았는데,

이제는 평가하고 결과보고하는 일이 주가 되버렸다.

양쪽입장이 되고 보니,
왜 제안서 제출은 항상 휴일 다음날 인지,
잘돌아가던 것들도 시연할려면 안되는지.. 
뭐.. 그런것들이 대충은 이해가 간다.

그런데.. 양쪽 입장에서 가만히 생각하다 보니..

PoC야 그렇다 치고,
BMT는 좀더 생각해 봐야 하는것이 아닌가 하는 생각이 든다.

만일 내가 10의 성능을 내는 제품이 필요한데.
어떤 제품은 8의 성능을 내지만 저렴하고,
어떤 제품은 20의 성능을 내지만 너무 비싸다면,
과연 어떤것을 선택하는게 맞는것인지 고민하게 된다.

물론 항상 평가에는 성능과 가격에 대한 비중이 정해져 있지만,
그 비중도 수시로 바뀌는 경우가 많고, 어떤것이 적정한 값인지를
아는 경우는 거의 없다고 해도 될듯..

그래서 난...
일단 꼭 필요한 기능을 나열하고, 해당 기능에 대한 점검을 수행한다.
  ==> 만일 꼭 필요한 기능이 없는 경우에는 해당 제품은 제외가 된다.
여기서 중요한것은 꼭 필요한 기능인지를 정확히 이해해야 한다는 것이다.
내가 PoC또는 BMT하는 제품에 대해 전체적으로 이해할 수 있어야 하고,
어떤것들이 중요한지를 사용하고 관리하는 입장에서 분별할 수 있어야 한다.

성능이 필요한 항목에 대해서 각각 우리가 필요로 하는 성능이 어느정도인지를 알아야 한다.
마냥 좋다고 좋은것은 없다. 분명 좋은게 있으면 나쁜것들이 따라오게 마련이다.
때문에 어느정도가 성능이 필요한것인지에 대해 각 부분별로 정의를 할 필요가 있다.
해당 성능을 상회한다면.. 그 상회정도가 어느정도인지는 중요하지 않은 경우가 많다.

최대한 공정하도록 해야 한다.
상당히 어려운 부분중에 하나인데, 공정하기 위해서는 그만큼 많이 알아야 한다.
성능을 위해 특정 기능을 뺀다거나, 별도 구매가 필요한 요소를 포함시킨다거나,
정당하지 않은 방법으로 수정을 가한다거나 하는 경우가 많다.
이런 부분이 있는지를 아는것은 정말 쉽지 않은 일이다.
하지만, 전체는 아니더라도 이런 것들을 어떻게 방지할것인지 반드시 고민이 필요하다.

너무나 당연한것들은 문서로 대체한다.
할 수 있는걸 다 한다면 좋겠지만, 항상 제한적인 것들이 많다.
그렇다면 기본적인 것들은 문서로 대체하고,
시나리에중 중복되는 부분은 최대한 제거하는것이 중요하다.
그것이 하는 사람도 보는 사람도 정말 해야할 일에 집중할 수 있는 방법이다.

너무 많은 것들을 하려고 하면, 정작 중요한것을 하지 못한다.
어떤 것이 중요한지를 아는것은 쉽지 않지만, 
어짜피 우리가 하는일이 쉽지 않은것이다.

크게 생각하고 작게 시작하기 그냥...

요 근래에 참 많이 듣고 또한 많이 공감하는 말이다.

어느정도 이상의 규모의 프로젝트들은 투입되는 돈과 사람들 때문에
그만큼 기대도 크고, 기대가 크다 보면 너무 많은 것을 한꺼번에 하려는 경향이 생긴다.

너무 많은것들이 바뀌다 보면,
기존에 것에 대비 바뀌는것들에, 바뀌는것 때문에 따라 바뀌는것까지 상당히 영향이 많게 된다.
그만큼 성공하기 어렵다는 것이 되기도 한다.

이제는 전체적으로 크게 생각하고, 시작은 작고 빠르게 해야할 때라는것은
그 누구라도 공감할것이다.

이번에 경영계획을 준비하고 심의하면서 느낀것중에 하나가 그것인데,
또한 이것이 실제 적용하기 어려운 부분들이 많다는게 참 문제다.

그 첫번째로, 어떤 표준을 정한다는 것은 그만큼 그것에 대해 고민하고, 큰 그림을 그리는것이
되는데, 그렇게 정해 진것들은 어떤 방식으로든 지켜나가야 의미가 생기는 것들이다.
하지만, 환경이든 사람이든 무엇이든 간에 항상 변하고 있는 환경에서 그런 표준이 언제까지나
의미가 있을지는 또한 의문이다.

내가 하는 일이 주로 그런 표준을 정하고 그것을 지켜나가도록 꾸준이 관리하는 것이다.
나 스스로 지켜나가는 것에 대한 회의가 들때가 많다.

그렇다면 수시로 그런 표준을 변화에 따라 맞춰가야 하는 것인데.
그럴려면 지금 환경에 대한 분석이 철저하게 필요하겠고.. (사실 요즘 이걸 하고 있다.. 에고..)
그렇게 분석된 자료를 바탕으로 중장기적인 계획 및 표준을 만들어 가야하고..
마지막으로 꾸준히 관리하며 지켜지도록 해야 하는것인데..

음.. 어떻게 하는건지는 알겠는데..
왜 한숨은 나는것인지..
사람일이 생각대로 되면 얼마나 좋겠는가....?


1 2 3 4 5 6 7 8 9 10 다음



W 위젯