'이전글/2009'에 해당되는 글 15건

  1. 2009.04.25 (EA/ISP) 3. 정보 기술 동향 파악하기 (4)
  2. 2009.04.25 (EA/ISP) 2. 환경 분석 과정에서 고려해야 할 것들
  3. 2009.04.25 성냥불 제대로 땡겨주는 - 일본전산 이야기 (3)
  4. 2009.04.16 코드 검색기
  5. 2009.04.12 (배치 고도화) 1. 자바로 엔터프라이즈 배치를? (18)
환경 분석 단계에서 TA는 정보 기술 동향을 파악하는 작업을 합니다. (가끔 AA와 함께 진행하기도 합니다.) 정보 기술 동향 파악의 핵심은 단기간에 집중할 영역을 분명히 해서 작업하는 것입니다. 앞선 글에서 밝혔듯이 환경 분석 단계에서 고려해야 할 것들이 많을 뿐 아니라, 정보 기술 동향을 빠르게 마무리 짓고 보다 더 중요한 현황 분석 단계를 서둘러 진행하기 위해서입니다. 정보 기술 동향을 빠르게 파악하기 위해 제가 사용한 몇 가지 팁을 얘기해 보겠습니다.

1. 정보 기술 동향 분석 단계의 진행 절차
정보 기술 동향 분석은 일반적으로 4개의 세부 단계를 거쳐 진행됩니다. 
  1. 거시적 IT 동향 분석
    큰 관점에서 정보화 동향을 분석하는 단계입니다. 차세대 시스템 구축을 포함한 금융 정보화 동향을 분석하는 일과, Gartner의 HypeCycle이나 Forrester Wave등의 통계 자료를 이용해 기술 자체의 동향을 파악하는 일로 나눌 수 있습니다. Emerging Technology들은 어떤 것들이 있는지, 주요 기술 별로 어떤 것들이 성숙 단계에 있고, 어떤 것들이 아직 캐즘을 벗어나지 못하고 있는지, 어떤 업체의 어떤 솔루션이 시장을 선도하고 있는지 등을 정리한다고 보면 됩니다.
  2. 핵심 요소 기술 선정
    거시적 IT 동향 분석을 끝낼 때 쯤이면, 장표화되지는 못했더라도 다른 파트에서 진행하고 있는 내.외부 환경 분석 자료를 전해 들을 수 있습니다. 2가지 자료를 종합해서 영역 별로 깊이 조사할 필요가 있는 핵심 요소 기술을 선정합니다. 이때 선정될 요소 기술들은 해당 기업의 비전을 달성할 Enabler 역할을 수행해야 합니다.
  3. 핵심 요소 기술별 상세 동향 분석
    핵심 요소 기술을 선정했다면, 각 요소 기술 별로 개요/발전 방향/도입 배경/기대 효과 등을 정리합니다. 템플릿에 지나치게 의존하지 않고 실질적인 자료 중심으로 내용을 구성하고, 조사 대상이 지나치게 많지 않도록 20개 내외로 결정하는 것이 좋은 것 같습니다. 
  4. 적용 가능성 평가 및 종합
    기술의 성숙도나 적용 용이성, 도입 및 유지에 소요되는 비용, 전략적 중요도 등을 고려해 각 요소 기술을 평가하고, 향후 적용을 고려할 우선 순위를 판단합니다.

2. 평소에 준비하라
금융권에서 시스템을 운영하시는 분들은 자부심이 높고, 그만큼 크리티컬한 시스템을 십 여년간 운영해 오며 쌓인 특정 분야에 대한 노하우가 많기 때문에, 그 분들이 자신하는 특정 영역에서는 책에 나오는 뻔한 얘기 정도는 우습게 보는 구루들이 포진해 있습니다. 또한 아주 일부이긴 하나 제대로 실천하지 못했던 경험으로 인해 특정 기술이나 기법에 대한 지나친 불신을 갖고 계신 경우도 있구요. 특히 컨설팅을 많이 받아본 업체들은 컨설턴트에 대해 공격적인 경향을 보이는 경우도 많습니다. 프로젝트 초반에 그 분들로 부터 인정을 받지 못한다면, 프로젝트를 진행하는 내내 늑대들에 둘러 쌓인 불쌍한 양의 신세로 전락해 버릴 수도 있는 것이죠. 정보 기술 동향을 정리해서 제출하는 것은 말로만 떠들던 것을 실천해 낼 수 있다는 것을 보여줄 수 있는 기회임과 동시에, 거꾸로 어디서 줏어들은 몇 마디 말로 아는 척 떠드는 가짜 컨설턴트인지를 밝혀내려는 고객들 틈에서 무사히 살아남아야 하는 엄청난 위기이기도 합니다.

그런 일을 2주 정도의 기간 내에 신뢰를 얻을 수 있는 수준으로 해내기 위해서는 평소에 열심히 준비하는 수 밖에 다른 방법이 없습니다. 또한 모든 자료를 직접 처음부터 끝까지 직접 다 만들어야 직성이 풀린다는 엔지니어로서의 집착에서 벗어나야만 합니다. 사실, 다른 사람이 만든 자료를 활용할 수 있는 유일한 단계가 정도 기술 동향 뿐이긴 하지만요. 구체적인 준비 방법은 각자 다르겠지만 제 경우는 필요성을 느낀 뒤부터 2년 동안 특정 주기 별로 9개의 카테고리로 분류한 관련 자료를 찾아서 읽고, 쓸만한 자료들은 정리하는 일을 계속해오고 있습니다. 아래 그림은 제 하드디스크 속에 있는 기술자료 정리 폴더의 구성과 일부 내용입니다.

  • 세미나 : ITSM, BPM, KM_EDMS, SW산업전망, ERP, 아키텍처, 개발 등 주요 업체나 주제별 세미나 자료를 모아둡니다. 3~4개 정도는 직접 참석하구요, 직접 참석하지 못한 세미나는 기억해두고 있다가 홈페이지 등에 자료가 공개되는 시점에 자료를 수집해 읽어둡니다. 업체 홍보성 자료는 별 쓸모가 없으니 삭제하고, 대가들의 자료를 중심으로 다시 참조할 것들만 선별해 모아두는 것이 요령입니다.
  • 기술이슈 : 기술 이슈는 특별히 정해진 규칙 없이 관심있는 우수 자료들을 선별해 모아두고 있습니다. 처음에는 TRM 형식으로 세분화해서 관리했는데, 디렉토리가 너무 많으니 오히려 번거롭더군요. 그래서 그냥 제가 알아볼 수 있는 형태로 디렉토리를 단순화하고, 해당 주제 내에 자료량이 많아지면 서브 디렉토리를 두는 방식으로 관리하고 있습니다.
  • 금융정보화 디지털타임즈대한금융신문 등에서 금융 정보화와 관련된 기사를 수집해 정리합니다. 디지털타임즈를 효과적으로 이용하는 방법은 "금융 IT 혁신과 도전"이란 매년 발간되는 책을 이용해서 주요 주제를 파악하고, 해당 주제에 대해 주기적으로 몰아서 검색하는 방법입니다. 보험개발원이나 은행연합회, 증권업 협회 등에서 주기적으로 발간하는 금융정보화 동향 자료 등을 구독하시는 것도 도움이 됩니다.
     

  • TRM/SP : 자신만의 기술 참조 모델을 만들어 업데이트하고, 가상의 금융 그룹이 있다고 가정하고 자신이 CIO라면 어떤 표준 프로파일을 갖도록 하고 싶은지를 고민한 최상의 표준 프로파일을 만들어 보는 것도 좋습니다. 게으름과 능력 부족으로 이 폴더는 아직도 절반도 채 완성되지 못한채 진행 중인 상태입니다. 쩝..
  • 글로벌통계 : 전 포레스터와 가트너의 자료를 중심으로 보고 있습니다.


3. 집중할 영역을 찾고, 적용 가능성을 평가하라.
파레토의 법칙(80-20 Rule)은 정보 기술 동향 파악에 딱 들어 맞는 말입니다. 평소에 준비해둔 내용으로 대부분의 정보 동향에 대한 문서화 작업을 최대한 빠른 시간 안에 마무리 짓고, 고객이 특히 관심있어하는 특정 분야에 대해 진지한 고민을 해야 합니다. 어떤 기업은 차세대 전반에 걸쳐 SOA를 적용하는 것이 과연 현실적인가를 고민할 것이고, 어떤 기업은 잘못 도입된 채널 통합 솔루션을 걷어내고, 그 자리를 대체하는 새로운 MCI 제품과 ESB의 관계를 궁금해 할 수도 있습니다. 혹자는 상품 팩토리가 자통법으로 인해 우후죽순 늘어나는 파생 상품을 얼마만큼 커버할 수 있는 지를 궁금해할 수 있고, IFRS를 준비하는 기업에서는 공정가치평가 솔루션이나, 새로 도입될 연결회계시스템 등에 대해 지대한 관심이 있을 수 있겠죠. 그런 고객의 Needs를 파악해서 해당 영역에 대해 보다 구체적이고, 깊은 자료 조사와 동향 파악이 필요합니다. 

정보 동향 파악의 목적은 기술이 어떻게 발전해 가고 있고, 다른 회사들은 어떤 기술이나 솔루션을 이용해서 구축하고 있는지를 알아보기 위한 세미나를 하자는 것이 아닙니다. ISP에서 정보 동향을 파악하는 목적은 딱 한가지 입니다. 그 기술이 과연 현 시점에서 적용을 고려해야 할 가치가 있는 것인가? 가치가 있다면 어떤 것들이 제대로된 레퍼런스를 확보한 기술인가? 하는 것이죠. 이 시점에서는 해당 조직의 투자 성향을 이해하는 것도 중요합니다. 국내에 레퍼런스가 없더라도 해외 레퍼런스가 있고 기술의 성숙도가 높다면 경쟁력 강화를 위해 위험을 감수하는 조직인지, 아니면 반드시 동종 업계에 레퍼런스가 있어야 해당 기술을 받아들이는 안정성을 추구하는 조직인지와 같은 것들 말이죠. 선두에 선 업체 일수록, 기대 수준이 매우 높기 때문에 국내 레퍼런스가 없어도 기술 성숙도가 충분하다는 것만 인정되면, 조직 역량을 믿고 신기술을 수용하는 경우가 많습니다.

차세대 시스템 구축을 목적으로 ISP가 발주된 경우라면, 유사 업종의 시스템 구축 사례를 정리해 줄 필요도 있습니다. 이 때 주변의 인맥을 활용해서 Best Practice로 삼을 만한 사례를 정리해서, 향후 사례 연구 등으로 인터뷰할 대상을 미리 선정해 두는 것도 발표 시 고객의 질문에 쉽게 대응할 수 있는 요령입니다. 안좋은 일에 대해서는 잘 밝히려 들지 않지만, 자랑하고 싶은 내용을 궁금해 하면 의외로 쉽게 고급 정보를 얻을 수 있고 덤으로 시간 낭비를 줄일 수 있는 귀중한 주의 사항 등을 전해 들을 수도 있습니다.

그리고, On-time, On-budget, High-quality 중에서, On-time 즉 제때 마무리하겠다는 결심이 중요합니다. 중간에 기술적인 탐구 욕구가 지나쳐 시간을 어기는 일이 있어서는 안됩니다. 이어지는 현황 분석이 더욱 중요하기도 하거니와, 정말 중요한 영역에 대해서는 현황 분석 뿐 아니라, 목표 시스템 설계 단계에서도 몇 번이고 반복해서 더 깊이 조사할 필요가 흔히 발생하기 때문입니다.





저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

환경 분석은 중.장기 정보화 전략을 수립하기 위한 사전 이해 단계로써, 시장에서 어떤 변화 들이 일어나고 있는지를 분석하는 외부 환경 분석과, 고객사 내부에서 어떠한 변화 방향을 설계하고 있는지를 이해하는 내부 환경 분석, 정보 기술의 주요 변화 동향과 구체적인 기업들의 도입 현황을 파악하는 정보 기술 동향 분석 등을 수행합니다.

환경 분석 단계에서 고려되어야 하는 것
보통 4개월 동안 ISP가 진행된다고 했을 때 2~3주 정도 환경 분석을 진행하게 되는데요, 첫 단계이기 때문에, 환경 분석이라는 본래의 일 외에 동시에 고려되어야 하는 것들이 몇 가지 있습니다.

1. 프로젝트 범위와 방법론에 대한 합의
제안팀과 프로젝트 팀이 다른 경우가 많기 때문에, 전체 프로젝트에 대한 범위와 방법론, 구체적인 일정을 확정짓고, 고객과 합의할 필요가 있습니다. 가끔 제안 단계에서 불필요한 산출물을 잔뜩 써놓거나 정작 중요한 것들은 빼먹는 경우가 있기 때문입니다. 최대한 빨리 전체에 대한 밑그림을 그리고, 고객이 기대하는 것과 일치시키도록 각 파트 담당자들과 깊이 있게 소통해야 합니다.

2. 팀웍 다지기와 R&R 정의
ISP 팀은 다양한 전문 지식을 필요로 하기 때문에 여러 회사로 구성된 연합군일 때가 많고, 그렇지 않더라도 계속 함께 일해오던 사람들이 아니기 때문에 초반에 팀웍을 다질 필요가 있습니다. 보고서 양식을 통일하는 자잘한 것에서 부터, 그 사람의 업무 스타일을 파악하는 것까지 세심하게 서로를 이해하려 노력해야 합니다. 또한, EA 기반의 ISP에서는 특정 분석이 2개 이상의 영역에 묘하게 겹쳐 있는 경우가 자주 발생합니다. 이때 타인의 업무 영역을 무뢰하게 침범하지 않으면서도 시너지 효과를 내기 위해서는 본인의 역할을 분명히하고, 누구와 어떤 얘기들을 나눠야 할지를 미리 고민해둘 필요가 있습니다. 이 때 문맥도(Context Diagram)를 그려보는 것이 무척 효과적이었습니다. (Younghoe.info에서 문맥도 샘플을 가져와 올립니다.)


실수. 세심한 배려가 뒷받침 되지 않은 도움은 오히려 해가 된다. 
커뮤니케이션에서 특히 중요한 것이 상대방에 대한 진심어린 배려인 것 같습니다. 모 프로젝트에서 저는 거버넌스 체계를 설계하던 어떤 분과 다툰 적이 있는데요, 그 분이 설계하신 인력 활용 방안이 너무 현실과 맞지 않다고 판단해서 생긴 의견 충돌이였습니다. 그런 일은 프로젝트 기간 내에서 비일비재한데요, 문제는 함께 상주하던 TF 조직 앞에서 제 의견을 너무 강하게 내세운 것이 실수였습니다. TF 조직과 오래 함께 있다보니 너무 친해져서 그 분들이 같은 자리에 있다는 것을 잠시 의식하지 못했었는데, 해당 영역에 대한 고객의 신뢰가 흔들릴 수 있는 위험을 미처 생각하지 못한 것이죠. 그 분이 먼저 자신이 만든 방안에 대해 의견을 물어오셔서 시작된 토론이였지만, 정말 그 분의 작업을 도와주고 싶은 생각이였다면 고객이 없는 자리에 가서 제 의견을 전달하는 세심함이 필요했던 것입니다. 

느낌. 책임감도 등급이 있다.
함께 한 PM 중에서 팀과의 대화 때도 항상 고객을 "우리 회사"라고 표현하는 분이 계셨습니다. 모질고 터프하게 일하기로 유명한 분이셨는데요, 프로젝트가 끝나고 생각해보면 "상사가 귀신 같아야 부하가 움직인다"라는 책[각주:1]을 그대로 옮겨 놓은 듯한 분이였습니다. 전 처음 접하는 타입이였는데요, 전 영역의 산출물을 꼼꼼하게 다 읽어보고 논리의 오류를 짚어내고, 시너지 효과가 필요한 영역을 찾아서 협업을 요구하는 분이였죠. 처음에는 일 중독이신지 의심될 정도였는데, 돌이켜 생각하면 책임감이 크셨기 때문인 듯 합니다. 함께 들어온 인턴에게 마치 삼촌처럼 기초부터 하나 하나 자상하게 가르쳐주시는 모습을 보고, 그 분의 원래 성격이 그렇지 않다는 걸 알았죠. 그 책임감이 자연스럽게 고객을 우리 회사라고 말하도록 만드는 게 아닐까 하는 생각이 들었습니다. 4개월을 함께 있다보면, 그게 가식인지 아닌지 드러나쟎아요? 일하는 동안은 요구하시는 것이 많아 참 불편했지만, 끝나고 나서는 가장 기억에 남는 분이기도 합니다. 모 회사 CIO 분과의 회식 자리에서 들었던 말이 기억나네요. 그 분이 자주하는 면접 수법이 있는데, 조직도를 그려보라고 해서 맨 위에 CEO가 나오면 무조건 탈락시킨다는. 맨 위에 고객을 그리고, CEO를 맨 밑에 지원 조직으로 그리는 놈이 진짜라는.

  1. 개인적으로 느낀 바가 많았던 책인데, 의외로 인기가 없더라구요. 동료나 직원들에게 좋은게 좋은거지라는 심정으로 무책임하게 좋은 말만 늘어놓고 싶은 욕심이 생길 때 읽어보면 도움이 됩니다. [본문으로]
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
마징가, 철인, 물개.. 야근을 즐기고, 툭하면 밤을 새는 업무 스타일 때문에 붙여졌던 지난 별명들입니다. 그런 스타일 때문에 미련하게 일한다며 놀림도 많이 받았습니다. 그런 제 스타일에 딱 맞는 자기 계발서 하나를 읽고 있습니다. 일본전산 이야기라는 책입니다.

예전에 서점에서 얼핏 훑어봤을 때는 이런 책이 왜 베스트셀러에 올라와있지? 싶을 정도로 관심 밖이였습니다. 하필 훑어본 부분이 아끼는 직원일수록 호되게 나무란다라는 챕터였는데요, 예전에 읽었던 상사가 귀신같아야 부하가 움직인다라는 책과 별반 다른 내용이 없었기 때문입니다.

아침에 신문을 읽다가 감동깊게 읽었던 이기는 습관 2편이 나왔다고 해서 들른 서점에서, 옆 자리에 놓인 일본전산 이야기를 또 다시 보게 되었습니다. 자꾸 눈에 띄니 인연인가 보다하고 같이 사서 나왔는데요, 이 책을 읽느라 원래 읽으려고 샀던 책은 뒷전이 되고 말았습니다. 오랜만에 마음 한 켠에 있는 제 열정에 성냥불을 제대로 댕겨주는 책을 읽었습니다. 몇 가지 내용만 소개해 볼까요?

경계대상 1호

자신을 온전히 불태워 헌신하지 않고, 어떻게 하면 '날로 먹을 방법은 없을까?" 궁리하며 쉽게 얻으려 하는 것. 조금 더 시간과 노력을 투자하는 것이 힘드니까, '안되는 이유를 찾아 열심히 짜 맞추어 둘러대는 것' 그리고 그런 패턴이 회사 내에서 쉽게 통용되는 문화가 바로 '경계 대상 1호'다.

'되는'일에만 집중해도 모자랄 시간에, '안되는' 이유를 쓰느라 시간을 허비할 필요가 어디 있는가?

어느샌가 열정없이 그저 할 수 있는 것들만 하려는 고정 관념에 사로잡혀 있게 된 것은 아닌지 돌아보게 만드는 글입니다. 되는 방법을 찾기위해 진심으로 노력하기 보다 짧은 경험과 얕은 지식으로 "이것 봐, 안되쟎아.."라는 생각에 시간을 허비하지 않도록 노력해야겠다고 결심하게 되네요.

지적 하드워킹

진정한 프로가 된다는 것은 남들에게는 '보이지 않는 곳'까지 생각이 미치는 것이다. 똑똑한 것과는 다르다. 자신의 생각을 끊임없이 확장시키고, 문제가 생기면 책임지고 해결하려는 습관을 들인 사람만이 프로가 될 수 있다.

근무 시간 8시간을 '몸'으로 하는 노동이라고 가정한다면, 나머지 시간에는 '생각'으로 일을 한다는 말이다. 이렇게 '생각으로 일하는 시간'을 많이 내는 사람일수록, 조직에서 더 좋은 성과를 내는 것은 당연하다.

개발자의 학습과 자세에 관한 좋은 글들을 많이 올라오는 애자일 이야기에서 읽었던 학습의 복리 효과에 관한 글이 떠오릅니다. 사이트에 나가 있는 동안은 바쁘다는 핑계로 자기 계발을 멀리하는 것을 당연히 여긴 것을 반성하게 됩니다. 지적 하드워킹에서 한걸음 더 나아가, 업무를 최대한 집중해서 수행하고 지적 Capacity를 늘리는 방향으로 꾸진히 증진할 수 있도록 노력해야 겠다는 생각이 듭니다.

이 밖에 3부에서도 참 좋은 글들이 많았는데요, 안 읽어 보신 분들은 꼭 한번 읽어보시길 추천합니다. 금요일 퇴근 길에 영회가 소개해준 "전략사고 컴플리트북"의 서문이 떠오르네요. 베이비붐 세대가 지난 요즘의 직장은 더 이상 주어진 일만 잘 해내는 것으로는 미래를 보장할 수 없으며, 전략적 사고를 지닌 개인이 직장에 어떤 가치를 줄 수 있을지를 고민하는 경영자 형태로 발전했을 때만이 자신의 미래와 회사의 가치를 높일 수 있다는 내용이였는데요, 안정적인 직장으로의 이직을 생각하던 제게 토비가 해준 "너를 안정되게 하는 것은 안정된 직장이 아니라 네가 가진 실력이다"라는 말과도 중복되는 것 같습니다. 일본전산 이야기라는 책에서는 "임원을 꿈꾸지 않는 직원은 필요없다"는 말로 표현하고 있기도 하죠.

채찍을 아끼지 않는 상사분들 밑에서, 내가 타오를 때 주저 없이 함께 타올라 주는 동료들과, 너무나 가치있는 소중한 경험들을 쌓아나갈 수 있는 지금이 너무나 행복합니다. 이 글을 읽는 지인분들도 행복하시길 바랍니다.
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

코드 검색기

이전글/2009 2009.04.16 13:12
좀전에 후배 녀석이 전화로 안부를 묻다가 어떤 알고리즘을 구현하고 있는데 오랜만에 다뤄서 기억이 잘 안난다는 말을 하더군요. 급하게 만들어야 된다고 투덜대서 Krugle을 한번 뒤져보지 그래? 라고 했더니 그게 뭔지를 모르네요. 대중화된지 꽤 오래 되었는데도 의외로 코드 검색기를 사용해보지 않은 분들이 꽤 많은 것 같아, 철지난 이야기지만 소개해볼까 합니다.

많이 알려진 코드 검색기는 Koders, Google Code Search, Krugle 등이 있습니다.

1. Koders (http://koders.com)

Koders의 장점은 다양한 IDE 지원인 것 같습니다. 이클립스나 비쥬얼 스튜디오 등과 연계해서 동작하기 때문에, 개발 도중에 특정 코드를 검색해서 검색 결과를 바로 개발에 사용할 수 있는 장점이 있습니다. (Koders의 이클립스 플러그인 다운로드)

2. Google Code Search (http://www.google.com/codesearch)

구글 코드 검색기의 장점은 정규식(Regular Expression)을 지원해서, 보다 정교한 검색이 가능하다는 것입니다. 정규식이 어렵다면 고급 코드 검색 기능을 이용해도 좋겠네요. 숙련되면 사용하기 편할 것도 같지만, 저는 개인적으로 인터페이스가 편하게 느껴지진 않았습니다.

3. Krugle (http://krugle.org/)

Krugle은 가장 먼저 알았던 코드 검색긴데요, 3년전에 토비랑 TDD 수련을 할 때 남들은 그 문제를 어떻게 풀었는지 궁금해서 찾아보면서 사용했던 기억이 납니다. Krugle을 이용해 마방진을 검색해 들어가면 아래와 같은 결과 화면을 볼 수 있는데요, 전체적인 배치나 검색 결과 등에서 나름 만족하며 썼습니다.


코드 검색기는 자주 사용할 일은 없지만, 가끔은 아주 요긴하게 사용할 수 있는 툴인 것 같습니다. 요즘은 코드를 검색해 본 일이 없어서, 어떤 코드 검색기를 사람들이 선호하는지는 모르겠네요. 아직도 이런 것들을 사용하겠죠?
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

배치 고도화 컨설팅을 의뢰받아 수행한 경험이 있습니다. 처음은 소프트웨어 아키텍트로 고도화를 위한 방안을 수립하는 역할이였고, 그 다음은 배치 어플리케이션 개발 프레임워크 구축 프로젝트의 PM 역할이였습니다. 실미도에 들어갔다며 블로깅을 멈추게 한 주범이 그 프로젝트죠. 정말 쉽지 않은 프로젝트였고, 업계를 떠나고 싶다는 생각이 들만큼 모든 열정을 다 불사르고서 겨우 성공할 수 있었습니다. 개인적으로도 많은 것들을 배우고 경험하는 뜻깊은 기간이였습니다. 

되돌아보면 명확한 목표 설정(Visioning), 적절한 커뮤니케이션(Communication)과 변화 관리, 잘 계획된 반복(Iteration)의 실천, 도메인 특성을 반영한 설계, 터프함을 견뎌낼 수 있었던 팀웍이 프로젝트를 성공으로 이끈 핵심 요소입니다. 정리하고 보니 뻔한 얘기네요 :)

그 뻔한 얘기의 일부를 정리해서 올해 열린 자바 개발자 컨퍼런스에 "차세대 배치 시스템 구축 성공 전략"이란 이름으로 발표를 했습니다. 본사에서 한참 제안 작업을 하던 때라, 중간에 참석해서 잠깐 발표만 하고 와버렸죠. 아래 사진도 구글링을 통해 greenapple 님의 블로그에서 가져온 것입니다. (발표 자료는 JCO 홈페이지에서 내려 받을 수 있습니다.)


짧은 발표 시간과 참석하시는 분들의 관심사 등을 고려해서 Spring Batch 확장과 같은 기술적인 얘기들을 주로 해서 아쉬움도 많았습니다. 정작 그 프로젝트를 통해 느끼고, 전달하고 싶었던 내용들은 그런 게 아니였는데 말이죠.

굴곡이 많았던 프로젝트를 몇 장의 PT로 정리하기는 아쉬움이 남습니다. 다시 블로깅을 시작할 만큼 활력을 찾은 지금, 시간이 허락하는 대로 틈틈이 하고 싶은 얘기들을 정리해 나갈 겁니다. 뻔한 얘기들이지만, 제게는 전혀 뻔하지 않았던 그런 얘기들 말이죠.[각주:1]

  1. 깨달은 바를 실천하기 위해 일부 내용을 삭제했습니다. [본문으로]
저작자 표시 비영리 변경 금지
신고
Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.
1 2 3 

글 보관함

카운터

Total : 226,198 / Today : 42 / Yesterday : 57
get rsstistory!

티스토리 툴바