작년 Software Engieering에 낑낑되게 만들었던 C.A.R Hoare가 1969년에 쓴 자신의 논문 An axiomatic basis for computer programming을 되돌아 보는 Essay가 이번달 Communication ACM에 실렸다. 아름하여 "Retrospective: An Axiomatic Basis for Computer Programming". Software Engineering이란 단어를 탄생케 한 그 유명한 1969년 NATO Software Enigneering Techniques Conference에 참석했던 인물이었기에 벌써 세상을 등지지 않았나 하고 생각하고 페이지를 들춰 보니 본인 직접 회고한 Essay였다. 1934년생이니 올해 벌써 75세.
그가 살아 생전에 한번 만나 볼 수 있으려나...
그가 1969년에 쓴 그의 논문을 되돌아 보면서, 그 당시 그가 예측한 일들이 생각보다는 빨리Computer Programming에 반영되었지만 어떤 것은 그가 의도한데 반영된 것도 있고 어떤 것은 그가 의도한 바와 전혀 다른 측면에서 반영되었다고 한다.
그의 Essay에서는 콕 꼬집어 Computer Programming의 Trend를 언급하지 않았지만, 그가 예를 든 Microsoft의 사례나 Hacker들이 Program의 Vulnerable한 구조를 Attack에서 사례를 보면서 앞으로의 Computer Program Trend를 어렴풋이 짐작할 수 있는 좋은 기회였다.
2012년 4월 20일 금요일
2012년 1월 13일 금요일
Steve Jobs가 남긴 유산들..(The Steve Jobs Economy)
2011년 11월달 Forbes에 Steve Jobs가 개발한 제품들을 연대별로 정리하여 보여준다. 가장 최초의 작품인 Apple II부터 시작하여 iPad까지... Steve Jobs가 만든 이 제품들 총 판매 금액이 360빌리언 달러라하니 실로 놀랍다.
2011년 3월 19일 토요일
Software Reuse Maturity Level
Reuse Maturity Level에 대한 연구가 꽤 있지만, 내가 본 것들은 대개 SEI의 CMM/CMMI Model을 따라 정의하고 있다. 개인적으로 선호하는 Model은 UML의 3 Amigo 중의 한 사람인 Ivar Jacobson이 쓴 Software reuse: architecture, process and organization for business success 이라는 책에 나오는 Software Reuse의 발전 단계를 표시한 것이다. 다른 Model보다는 이 모델이 마음에 드는 것은 각 발전 단계가 기업에서 실제로 Software Reuse를 전략적으로 수행할 때 필연적으로 발생할 수 있는 단계들로 정리하여 도식화했기 때문이다. 특히나, 공동 저자인 M. Grisis의 경우에는 Hewlett-Packard에서 Software Reuse에 관련하여 수년동안 Research와 Practice를 함께해 온 인물이기 때문이기도 할 것이다.
아래 그림에서와 같이 Software Reuse의 가장 초보적인 단계는 Software 개발 단계의 Artifacts를 중구난방으로 Copy-And-Paste하는 단계인 Informal Code Reuse. Artifact Clone에 따른 Maintenance Issue들이 있지만 나름 Software Reuse의 한 방식.. 개인적으로 Software Reuse의 가장 어려운 단계가 바로 2번째 단계인 Blackbox Code Reuse가 아닌가 한다. 단어가 의미하듯이 Blackbox Code Reuse는 개발된 Code를 적절히 Packaging하고 Packaging된 내용물을 잘 Specification하여 사용자들이 그 Specification만을 보고 재사용 여부와 방식를 결정하게 되는 것이다. 언뜻보면 별로 어려울 것 같지 않지만, 다른 단계에 비해가장 많은 노력, 시간, 그리고 비용이 들어가는 단계가 아닐까 생각한다.
먼저 기술적인 측면에서, 첫째, 어떤 부분을 Packaging 할 것인가? 즉, Package의 Scope을 정하는 것이다. Packaging의 단위를 Module 또는 Component라고 불러도 좋다. 어떤 단어를 쓰더라도 근본적으로 바뀌지 않는 것은 Packaging된 내용물이 제공하는 기능의 범위가 무엇인가 일것이다. 어떤 사람은 10개의 기능을, 또 다른 사람의 5개의 기능을 Packaging하자고 할 수 있을 것이다. Package Scope를 결정하는 원칙이나 룰이 정해진 것이 없으니 누구의 의견이 맞고 틀리다고 단정지을 수 없는 것이 항상 논쟁을 불러일으키게 된다. 내가 생각하기에는 제일 처음으로 Package의 Scope를 정의할 때엔 공리주의자들의 기본적인 이론으로 알려진 최대 다수의 최대 행복의 원칙에 입각해서 Scope을 정의하는 것이 좋을 것 같다. 일단 Scope이 정해지고 Reuse되면서 문제점이나 개선점이 들어나면 점진적으로 Scope를 재조정하는 것도 필요한 Activity일 것이다.
두번째로, 어떤 내용을 Specification에 넣을 것인가? Software Specification에 대한 연구가 효율적인 Reuse Library 개발/유지를 통해 나름 이루어지긴 하였지만, 전자부품과 같은 Hardware처럼 표준 Specification이라고 불리만한 것이 없다. 그래서, 나름 많은 것을 Reusable Package에 대한 Meta 정보들을 정의하고 그에 따라 Reusable Package를 관리하지만, 항상 Reuse를 위해 Meta 정보를 검색하는 입장에서는 원하는 정보가 제공되지 않는 경우가 종종 발생할 것이다. 예를 들어, Reusable Package의 Code Size, Complexity 등과 같은 Static Metrics는 비교적 쉽게 제공될 수 있으나, Run-time Performance과 같은 정보들은 쉽게 제공할 수 없는 것이다. 왜냐하면, Execution Environment에 따라 Performance가 달라지고 모든 사용 가능한 Execution Environment에 대해 확인하는 것이 현실적으로 불가능하기 때문이다.
세번째로, 기술 지원 측면도 고려되어야 할 것이다. Software 역시 인간이 만드는 것이다보니 아무리 문제를 최소화한다고해도 완벽하게 문제를 제거할 수는 없는 것이다. 더군다나, 요즘과 같이 급변하는 IT 시대에 짧은 시간에 Bug-free인 Software를 구현한다는 것은 거의 불가능한 일이다. Release되는 Software에 내제된 Bug 수와 발생 빈도라도 관리된다면 감지덕지할 일인 것이다. Reusable Package의 재사용을 가로막는 일 중에 하나가 바로 문제가 발생하였을 경우 해결 방안을 찾기에 힘들다는 것이다. 더군다나, Source Code없이 Binary만 제공되는 경우... 따라서, 위에서 언급한 문제와 더불어 Reusable Package에 문제가 발생하였을 경우, 얼마나 빨리 대응하고 문제를 해결할 수 있는가 역시 Blackbox Code Reuse의 중요한 숙제라고 할 수 있을 것이다.
반면, 문화적인 측면에서 Not Invented Here 이라는 Mind를 극복하여야 할 것이다. 요즘은 Open Source내 뭐내해서 많이 희석된 것 같기도 하지만, 아직도 많은 Software Engineer들은 자신들이 개발한 Source에 대해 더 많은 애착을 느끼고, 타인이 개발한 Code에 대해서는 부정적인 시각을 가지고 있다. 앞서 언급한 것처럼 Software가 사람이 개발하는 것이다 보니, 각 개인별로 수준차가 날 수 밖에없고 그 차이가 Software 품질에 영향을 주게된다. Reuse로 인해 문제가 발생하면 일차적으로 본인이 자신의 문제가 아님을 보여야하니 남의 것으로 자신이 피해를 보는 것 같은 피해 의식도 들기도 하고... 따라서, 이러한 문제는 Reusable Package를 공급하는 입장이나 그것을 Reuse하는 입장을 중재하는 조직을 운영면서 점진적으로 이런 문제를 해결해 나가는 것이 좋을 것이다.
일단 Blackbox Code Reuse 단계에서 많은 시행 착오를 거치고 성공적으로 Reuse에 대한 기술적/문화적 Background가 생긴다면 다음 단계로의 발전은 용이하게 진행될 것이다.
특히, 최근 몇 년동안 마지막 두단계인 Architected Reuse와 Domain-Specific Reuse-Driven Orgamization은 Software Product Line Engineering이란 분야에 대응되는 것 같고, 많은 기업들이 자신들의 Business Domain에 맞는 Architecture (or Platform)을 개발하고 Business Domain에 따라 Component와 Development Process를 Tailor하여 Reuse를 극대화한 성공 사례들을 보여주고 있다. 이에 대한 것은 다음에 Software Product Line Engineering 편에서 다루어 보기로 함.
마지막으로, 가로축에서 알 수 있듯이 Software Reuse는 그냥 얻어지는 지는 것이 아니다. 시간, 비용, 그리고, 기술적/문화적 경험이 축적되어야지만 성공적인 Software Reuse가 달성되는 것이다.
Excerpted from the following reference.
Jacobson. I., Griss, M., & Jonsson, P. 1997. Software reuse: architecture, process and organization for business success. ACM Press/Addison-Wesley Publishing Co., New York, NY.
아래 그림에서와 같이 Software Reuse의 가장 초보적인 단계는 Software 개발 단계의 Artifacts를 중구난방으로 Copy-And-Paste하는 단계인 Informal Code Reuse. Artifact Clone에 따른 Maintenance Issue들이 있지만 나름 Software Reuse의 한 방식.. 개인적으로 Software Reuse의 가장 어려운 단계가 바로 2번째 단계인 Blackbox Code Reuse가 아닌가 한다. 단어가 의미하듯이 Blackbox Code Reuse는 개발된 Code를 적절히 Packaging하고 Packaging된 내용물을 잘 Specification하여 사용자들이 그 Specification만을 보고 재사용 여부와 방식를 결정하게 되는 것이다. 언뜻보면 별로 어려울 것 같지 않지만, 다른 단계에 비해가장 많은 노력, 시간, 그리고 비용이 들어가는 단계가 아닐까 생각한다.
먼저 기술적인 측면에서, 첫째, 어떤 부분을 Packaging 할 것인가? 즉, Package의 Scope을 정하는 것이다. Packaging의 단위를 Module 또는 Component라고 불러도 좋다. 어떤 단어를 쓰더라도 근본적으로 바뀌지 않는 것은 Packaging된 내용물이 제공하는 기능의 범위가 무엇인가 일것이다. 어떤 사람은 10개의 기능을, 또 다른 사람의 5개의 기능을 Packaging하자고 할 수 있을 것이다. Package Scope를 결정하는 원칙이나 룰이 정해진 것이 없으니 누구의 의견이 맞고 틀리다고 단정지을 수 없는 것이 항상 논쟁을 불러일으키게 된다. 내가 생각하기에는 제일 처음으로 Package의 Scope를 정의할 때엔 공리주의자들의 기본적인 이론으로 알려진 최대 다수의 최대 행복의 원칙에 입각해서 Scope을 정의하는 것이 좋을 것 같다. 일단 Scope이 정해지고 Reuse되면서 문제점이나 개선점이 들어나면 점진적으로 Scope를 재조정하는 것도 필요한 Activity일 것이다.
두번째로, 어떤 내용을 Specification에 넣을 것인가? Software Specification에 대한 연구가 효율적인 Reuse Library 개발/유지를 통해 나름 이루어지긴 하였지만, 전자부품과 같은 Hardware처럼 표준 Specification이라고 불리만한 것이 없다. 그래서, 나름 많은 것을 Reusable Package에 대한 Meta 정보들을 정의하고 그에 따라 Reusable Package를 관리하지만, 항상 Reuse를 위해 Meta 정보를 검색하는 입장에서는 원하는 정보가 제공되지 않는 경우가 종종 발생할 것이다. 예를 들어, Reusable Package의 Code Size, Complexity 등과 같은 Static Metrics는 비교적 쉽게 제공될 수 있으나, Run-time Performance과 같은 정보들은 쉽게 제공할 수 없는 것이다. 왜냐하면, Execution Environment에 따라 Performance가 달라지고 모든 사용 가능한 Execution Environment에 대해 확인하는 것이 현실적으로 불가능하기 때문이다.
세번째로, 기술 지원 측면도 고려되어야 할 것이다. Software 역시 인간이 만드는 것이다보니 아무리 문제를 최소화한다고해도 완벽하게 문제를 제거할 수는 없는 것이다. 더군다나, 요즘과 같이 급변하는 IT 시대에 짧은 시간에 Bug-free인 Software를 구현한다는 것은 거의 불가능한 일이다. Release되는 Software에 내제된 Bug 수와 발생 빈도라도 관리된다면 감지덕지할 일인 것이다. Reusable Package의 재사용을 가로막는 일 중에 하나가 바로 문제가 발생하였을 경우 해결 방안을 찾기에 힘들다는 것이다. 더군다나, Source Code없이 Binary만 제공되는 경우... 따라서, 위에서 언급한 문제와 더불어 Reusable Package에 문제가 발생하였을 경우, 얼마나 빨리 대응하고 문제를 해결할 수 있는가 역시 Blackbox Code Reuse의 중요한 숙제라고 할 수 있을 것이다.
반면, 문화적인 측면에서 Not Invented Here 이라는 Mind를 극복하여야 할 것이다. 요즘은 Open Source내 뭐내해서 많이 희석된 것 같기도 하지만, 아직도 많은 Software Engineer들은 자신들이 개발한 Source에 대해 더 많은 애착을 느끼고, 타인이 개발한 Code에 대해서는 부정적인 시각을 가지고 있다. 앞서 언급한 것처럼 Software가 사람이 개발하는 것이다 보니, 각 개인별로 수준차가 날 수 밖에없고 그 차이가 Software 품질에 영향을 주게된다. Reuse로 인해 문제가 발생하면 일차적으로 본인이 자신의 문제가 아님을 보여야하니 남의 것으로 자신이 피해를 보는 것 같은 피해 의식도 들기도 하고... 따라서, 이러한 문제는 Reusable Package를 공급하는 입장이나 그것을 Reuse하는 입장을 중재하는 조직을 운영면서 점진적으로 이런 문제를 해결해 나가는 것이 좋을 것이다.
일단 Blackbox Code Reuse 단계에서 많은 시행 착오를 거치고 성공적으로 Reuse에 대한 기술적/문화적 Background가 생긴다면 다음 단계로의 발전은 용이하게 진행될 것이다.
특히, 최근 몇 년동안 마지막 두단계인 Architected Reuse와 Domain-Specific Reuse-Driven Orgamization은 Software Product Line Engineering이란 분야에 대응되는 것 같고, 많은 기업들이 자신들의 Business Domain에 맞는 Architecture (or Platform)을 개발하고 Business Domain에 따라 Component와 Development Process를 Tailor하여 Reuse를 극대화한 성공 사례들을 보여주고 있다. 이에 대한 것은 다음에 Software Product Line Engineering 편에서 다루어 보기로 함.
마지막으로, 가로축에서 알 수 있듯이 Software Reuse는 그냥 얻어지는 지는 것이 아니다. 시간, 비용, 그리고, 기술적/문화적 경험이 축적되어야지만 성공적인 Software Reuse가 달성되는 것이다.
Excerpted from the following reference.
Jacobson. I., Griss, M., & Jonsson, P. 1997. Software reuse: architecture, process and organization for business success. ACM Press/Addison-Wesley Publishing Co., New York, NY.
2010년 10월 29일 금요일
미국 이민 개혁안 어디로 가니?
인터넷판 Newworkworld에 따르면 지금 미 국회에 이민 개혁안, 특히 H-1B와 L-1에 관련된 8개의 법안이 계류중에 있지만 법안 통과가 더디게 진행되고 있단다. H-1B와 L-1에 관련된 주요 법안을 보면,
H.R. 5397과 S. 887오 명명된 법안은 회사에서 직원들을 해고할 때, H-1B과 L-1 비자를 가진 사람을 보호하기 위해 미국 노동자를 먼저 해고하는 전례를 금지하고, 200여개의 직종을 추가적으로 확대하여 H-1B와 L-1 비자 남용을 조사하도록 하고 있고,
H.R. 4321은 공항이나 국경에서 근무하는 이민국 직원과 세관원을 더 증원하여 이민 심사를 강화하는 안을 포함한 전반적인 이민법 개혁을 담고 있으며,
H.R. 4259는 투자 이민인 EB-의 지원 자격을 완화하고 Application Fee를 $2,500으로 인상토록하는 법안을 담고 있으며,
S. 2804는 지난 12개월 내에 직원을 대량 해고한 회사가 직원을 채용할 때, 외국인 채용을 제한토록하고 있으며,
S. 3029 and H.R. 5193는 새로운 비자를 제정하여 외국 기업인이 Venture capital 회사의 지원으로 자본금 $250,000의 회사를 설립하고 5명 이상의 미국인을 고용토록 장려하는 법안을 담고 있다.
H.R. 1791은 외국인이 미국에서 Science, Technology, Engineering, 또는 Math에 관련된 학과에서 박사학위를 취득한 경우 영구적으로 살 수 있도록하고 H-1B 비자의 쿼터 적용을 받지 않게(?) 하는 법안을 담고 있으면,
H.R. 5658은 H-1B 비자의 Cap을 20% 늘리는 방안을 담고 있다.
소개된 절반의 법안은 미국민의 취업 여건을 개선하고자 외국인 취업을 제한하고자 하고, 나머지 절반을 미국에서 필요한 고급 외국인 인재를 보호하려는 법안이다. 특히나, 미국에서 공부하고 지속적으로 미국내에서 살기를 희망하는 한국 유학생들의 경우에는 H.R. 1791 법안이 통과되면 별 문제없이 미국내에서 영구히 영주할 수 있게될 것 같다. 하지만, H-1B나 L-1 비자를 통행 미국내 영주를 희망하는 사람들은 앞으로 미국 경제가 살아나더라도 미국 회사의 비자 스폰서 비용 증가로 취업 기회가 줄어들 것 같다.
하지만, 아직 이들 법안이 Committee내애서만 논의 중이고, 이들 법안을 제안한 의원들 대부분이 2010 미국 국회의원 선거에 재출마하지 않아 법안이 본회에 상정도 되지 못하고 폐기되거나 더 느리게 진행될 것 같기도 하다.
자세한 내용은 Networkworld.com의 기사를 참조하세요.
Congress mulls multiple bills to reform H-1B visa program (http://www.networkworld.com/community/node/67789)
H.R. 5397과 S. 887오 명명된 법안은 회사에서 직원들을 해고할 때, H-1B과 L-1 비자를 가진 사람을 보호하기 위해 미국 노동자를 먼저 해고하는 전례를 금지하고, 200여개의 직종을 추가적으로 확대하여 H-1B와 L-1 비자 남용을 조사하도록 하고 있고,
H.R. 4321은 공항이나 국경에서 근무하는 이민국 직원과 세관원을 더 증원하여 이민 심사를 강화하는 안을 포함한 전반적인 이민법 개혁을 담고 있으며,
H.R. 4259는 투자 이민인 EB-의 지원 자격을 완화하고 Application Fee를 $2,500으로 인상토록하는 법안을 담고 있으며,
S. 2804는 지난 12개월 내에 직원을 대량 해고한 회사가 직원을 채용할 때, 외국인 채용을 제한토록하고 있으며,
S. 3029 and H.R. 5193는 새로운 비자를 제정하여 외국 기업인이 Venture capital 회사의 지원으로 자본금 $250,000의 회사를 설립하고 5명 이상의 미국인을 고용토록 장려하는 법안을 담고 있다.
H.R. 1791은 외국인이 미국에서 Science, Technology, Engineering, 또는 Math에 관련된 학과에서 박사학위를 취득한 경우 영구적으로 살 수 있도록하고 H-1B 비자의 쿼터 적용을 받지 않게(?) 하는 법안을 담고 있으면,
H.R. 5658은 H-1B 비자의 Cap을 20% 늘리는 방안을 담고 있다.
소개된 절반의 법안은 미국민의 취업 여건을 개선하고자 외국인 취업을 제한하고자 하고, 나머지 절반을 미국에서 필요한 고급 외국인 인재를 보호하려는 법안이다. 특히나, 미국에서 공부하고 지속적으로 미국내에서 살기를 희망하는 한국 유학생들의 경우에는 H.R. 1791 법안이 통과되면 별 문제없이 미국내에서 영구히 영주할 수 있게될 것 같다. 하지만, H-1B나 L-1 비자를 통행 미국내 영주를 희망하는 사람들은 앞으로 미국 경제가 살아나더라도 미국 회사의 비자 스폰서 비용 증가로 취업 기회가 줄어들 것 같다.
하지만, 아직 이들 법안이 Committee내애서만 논의 중이고, 이들 법안을 제안한 의원들 대부분이 2010 미국 국회의원 선거에 재출마하지 않아 법안이 본회에 상정도 되지 못하고 폐기되거나 더 느리게 진행될 것 같기도 하다.
자세한 내용은 Networkworld.com의 기사를 참조하세요.
Congress mulls multiple bills to reform H-1B visa program (http://www.networkworld.com/community/node/67789)
2010년 10월 21일 목요일
천지인 특허 기부를 보면서
중극이 한글 입력 방식을 표준화한다고 하자 우리나라 정부는 부랴부랴 표준화 작업에 나섰다. 그리고, 천지인을 비롯한 방식의 휴대폰 한글 입력 특허들이 속속 정부에 특허를 기부하기 시작한다. 15년전인 지난 1995년에 시작한 한글 입력 표준화이 이들 특허 때문에 별반 진전이 없다가 중국의 끙하는 신음소리 한번에 정부와 특허권자들이 반응을 보인 것이다. 왜 진작에 천지인에 관련된 특허를 기부하지 않았을까 하는 궁금증이 든다. 휴대폰으로 대변되는 모바일기기의 한글 입력 방법이 회사마다 달라 불편하다는 것이 대한민국인이라면 모르는 사람들이 없는데, 진작에 자신들의 특허를 국가에 기부하였다면 모든 국민들이 표준화된 방법으로 한글을 입력할 수 있었을터인데..
특허라는 것이 특허권자의 정신적 노동의 대가요 창의성에 대한 보상이라는 점에서 쉽게 그 권리르 무상으로 공개하기는 어려운 것이다. 특히나, 천지인 같이 필수적으로 제품에 채택되지 않고는 제품이 생산될 수 없는 경우에는 더욱더 무료로 공개하기는 힘들 것이다. 그야말로 가만히 앉아 있으면 돈이 쌓이는 황금 거위이니까!!!
나라도 쉽게 그 권리를 포기 힘들 것이다.
그런데, 문제는 지금부터라고 생각된다. 한글 입력 특허를 웬만한 회사들이 너도나도 특허권을 정부에 기부하였다. 그 중 어느 것을 기준으로 표준으로 만들지 아니면 전혀 새로운 표준을 만들지 정부에서 결정을 해야한다. 전혀 새로운 표준은 정부나 기업에서 원하지 않는 선택일 것이고 남은 선택은 기존 입력 방식 중 하나를 기준으로 입력 방식을 해야 할 것인데, 기준으로 채택된 입력 방식을 사용하는 회사는 문제 없을 것이나 그렇지 않은 회사들은 그 동안 만들어 왔던 제품에서 입력 방식을 새로 교체하는 작업을 진행해야 할 것이다. 말이 쉬어 교체지 소프트웨어가 하드웨어처럼 바꿔끼기만 하면 되는 것이 아니다 보니, 특허 기부를 한 회사들이 서로 자기네들이 사용하던 방식을 표준으로 채택되게 하려고 많은 노력을 할 것 이다.
이제까지는 특허료때문에 표준화가 어려웠다면, 이제는 기업들의 로비때문에 표준화가 어려워 질 것 같다. 만략, 어떤 기업에서 제안한 특허 방식이 표준화로 채택되면 한동안 마케팅 포인트로 잘 활용될 것 같기도 하다.
모쪼록, 이해 관계자들의 의견에 휘둘리지 말고, 국민들의 편의와 향후 기술 발전을 예측하여 지속적으로 사용할 수 있는 한글 입력 방식이 제정되었으면 한다.
특허라는 것이 특허권자의 정신적 노동의 대가요 창의성에 대한 보상이라는 점에서 쉽게 그 권리르 무상으로 공개하기는 어려운 것이다. 특히나, 천지인 같이 필수적으로 제품에 채택되지 않고는 제품이 생산될 수 없는 경우에는 더욱더 무료로 공개하기는 힘들 것이다. 그야말로 가만히 앉아 있으면 돈이 쌓이는 황금 거위이니까!!!
나라도 쉽게 그 권리를 포기 힘들 것이다.
그런데, 문제는 지금부터라고 생각된다. 한글 입력 특허를 웬만한 회사들이 너도나도 특허권을 정부에 기부하였다. 그 중 어느 것을 기준으로 표준으로 만들지 아니면 전혀 새로운 표준을 만들지 정부에서 결정을 해야한다. 전혀 새로운 표준은 정부나 기업에서 원하지 않는 선택일 것이고 남은 선택은 기존 입력 방식 중 하나를 기준으로 입력 방식을 해야 할 것인데, 기준으로 채택된 입력 방식을 사용하는 회사는 문제 없을 것이나 그렇지 않은 회사들은 그 동안 만들어 왔던 제품에서 입력 방식을 새로 교체하는 작업을 진행해야 할 것이다. 말이 쉬어 교체지 소프트웨어가 하드웨어처럼 바꿔끼기만 하면 되는 것이 아니다 보니, 특허 기부를 한 회사들이 서로 자기네들이 사용하던 방식을 표준으로 채택되게 하려고 많은 노력을 할 것 이다.
이제까지는 특허료때문에 표준화가 어려웠다면, 이제는 기업들의 로비때문에 표준화가 어려워 질 것 같다. 만략, 어떤 기업에서 제안한 특허 방식이 표준화로 채택되면 한동안 마케팅 포인트로 잘 활용될 것 같기도 하다.
모쪼록, 이해 관계자들의 의견에 휘둘리지 말고, 국민들의 편의와 향후 기술 발전을 예측하여 지속적으로 사용할 수 있는 한글 입력 방식이 제정되었으면 한다.
New MacBook Air 그리고 Flash Storage
어제 Jobs 아저씨까 또 새로운 물건을 들고 나왔다. 이름하여 New MacBook Air. 가격도 참하고 성능도 꽤 괜찮아 보인다.
그 중 가장 맘에 드는 부분이 Storage로 Flash Memory를 이용한다는 것이다. Flash Memory를 이용하는 Solid State Drive(SSD)의 가격을 보면 64G가 $150정도, 120G가 $300 정도하는데, 64G를 채택한 MacBook Air 11인치가 $999이고 128G 채택한 것은 $1,199이다. Flash memory를 Onboard에 부착하여 불필요한 부분을 없앴다고 하더라도 참 참한 가격이다. 아마 Flash 제조사와 엄청난 딜이 있지 않았을까? 아님 SSD가 폭리를 취하던가?
Flash Memory의 장점은 하드디스크와 달리 충격에 대한 데이터 파손을 걱정할 필요도 없고 전력도 덜 소비한다. 또, Data Access 속도도 무지하게 빠르다. 그런데, 용량 대비 비싼 것이 흠이라서 대중화가 이루어지지 않고 있는 것이다.
이번 MacBook Air에 Flash Storage 탑재를 기점으로하여 Flash Memory 기반의 Storage 더욱 활성화되어 내 Windows Laptop에도 SSD를 달 수 있었으면 좋겠다.
그 중 가장 맘에 드는 부분이 Storage로 Flash Memory를 이용한다는 것이다. Flash Memory를 이용하는 Solid State Drive(SSD)의 가격을 보면 64G가 $150정도, 120G가 $300 정도하는데, 64G를 채택한 MacBook Air 11인치가 $999이고 128G 채택한 것은 $1,199이다. Flash memory를 Onboard에 부착하여 불필요한 부분을 없앴다고 하더라도 참 참한 가격이다. 아마 Flash 제조사와 엄청난 딜이 있지 않았을까? 아님 SSD가 폭리를 취하던가?
Flash Memory의 장점은 하드디스크와 달리 충격에 대한 데이터 파손을 걱정할 필요도 없고 전력도 덜 소비한다. 또, Data Access 속도도 무지하게 빠르다. 그런데, 용량 대비 비싼 것이 흠이라서 대중화가 이루어지지 않고 있는 것이다.
이번 MacBook Air에 Flash Storage 탑재를 기점으로하여 Flash Memory 기반의 Storage 더욱 활성화되어 내 Windows Laptop에도 SSD를 달 수 있었으면 좋겠다.
2010년 10월 20일 수요일
프랙탈의 대부, 베르누트 만델브로트(Benoît B. Mandelbrot) 잠들다
프랙탈, 쉬운 것 같기도 하고 어려운 것 같기도 하면서 나름 재미있었던 프랙탈 수업. 그 프랙탈의 대부 베르누트 만델브로트(Benoît B. Mandelbrot)가 지난 2010년 10월 16일에 췌장암으로 운명을 달리하였다. 향연 85세.
인공 지능과 컴퓨터 그래픽 수업 시간에 배우면서 배우면서 별난 것을 다 만들어내었네 하였는데, 그의 인생 자체가 별났다는 것을 이번 사망 기사를 통해 알게되었다. 그의 취미는 비주류 분야의 논문들을 보는 것. 프랙탈 이론도 그의 취미 생활 과정에서 나온 것이라 한다.
주로 인공 지능과 컴퓨터 그래픽 수업 시간에 그의 이론이 나왔길레 컴퓨터 사이언티스트인가 했더니 수학자라고 한다. 다시 한번 수학과 기초 학문의 위대함을 깨닫고, 삼가 고인의 명복을 빕니다.
자세한 기사는
New York Times http://www.nytimes.com/2010/10/17/us/17mandelbrot.html?_r=1
동아사이언스 http://news.dongascience.com/HTML/News/2010/10/19/20101019200002209420/201010192000022094200113220000.html
그런데, 동안사이언스 기사는 New York Times 기사를 빼긴 냄새가 난다.
인공 지능과 컴퓨터 그래픽 수업 시간에 배우면서 배우면서 별난 것을 다 만들어내었네 하였는데, 그의 인생 자체가 별났다는 것을 이번 사망 기사를 통해 알게되었다. 그의 취미는 비주류 분야의 논문들을 보는 것. 프랙탈 이론도 그의 취미 생활 과정에서 나온 것이라 한다.
주로 인공 지능과 컴퓨터 그래픽 수업 시간에 그의 이론이 나왔길레 컴퓨터 사이언티스트인가 했더니 수학자라고 한다. 다시 한번 수학과 기초 학문의 위대함을 깨닫고, 삼가 고인의 명복을 빕니다.
자세한 기사는
New York Times http://www.nytimes.com/2010/10/17/us/17mandelbrot.html?_r=1
동아사이언스 http://news.dongascience.com/HTML/News/2010/10/19/20101019200002209420/201010192000022094200113220000.html
그런데, 동안사이언스 기사는 New York Times 기사를 빼긴 냄새가 난다.
2010년 10월 18일 월요일
LG 전자의 반격, SW통합센터 성공할까?
오늘 인터넷에0 LG 전자가 소프트웨어 통합센터를 구축한다는 것이 주요 IT 기사로 올라왔다. 경기도 평택에 수천명의 소프트웨어 연구개발 인력을 모아서 사업본부별로 소프트웨어 개발 지원하는 것을 통합 운영한다는 것이다. 이에 걸맞게 대대적으로 소프트웨어 조직을 새롭게 신설하거나 정비하여 소프트웨어 경쟁력을 극대화하겠다고 한다. LG 전자는 확정되지 않았다고 하지만, 아니 땐 굴뚝에 연기나지 않는 법. 그리고, 뭐 그다지 새로운 내용도 없는 상투적인 기사다.
고위층이 바뀌면서 상당 부분 예측된 부분이지만 이런 접근 방식은 논란을 일으킬 소지가 다분히 있을 것 같다.
첫째, 근무 위치. 아직 정해지지 않았다고 하지만, 평택이라는 지리적 위치가 아마 기존 인력의 이탈을 불러 올 것이고 새로운 인력을 수급하는데 문제가 있을 것이다. 직장인들의 우선적으로 고려하는 것이 아마 근무처가 아닐까? 대체로 강남에서 1시간 내외의 거리에 있는 곳에 사무실이 있기를 바랄 것이다. 대체로 삼성 계열사가 수원 또는 기흥이 마지노선이 아닐까? 그런데, 더 먼 평택이라니? LG라는 Brand로 커버하기에는 물리적으로 다소 먼 거리가 아닐까 한다.
둘째, 서울 접근성. 근무 위치와 비슷한 의미이지만 협업 차원에서의 문제점이다. 소프트웨어는 한 회사에서 모든 것을 개발할 수 있는 것이 아니다. 개발에 필요한 툴도 사야되고, 자체 내에서 없는 기술을 수급하기 위해서는 외부에 용역을 줘야하고... 또, 새로운 기술을 파악하기 위해 서울에서 열리는 각종 컨퍼런스도 참가 해야하고.. 회사가 강남에 있다는 이 모든 것이 쉬워진다. 지하철타고 1~20분이면 서로 만나 합의점을 찾을 수 있고, 컨퍼런스 갔다가 오후에 들어와 잔무를 처리하고.. 한때 벤쳐들이 테헤란로에 몰려있었던 것이 다 이런 장점을 십분활용하기 위함이 아니었던다.
세째, 어떻게 통합할 것인가? 소프트웨어 개발팀이 사업본부별로 있던 것은 다 이유가 있지 않았을까?
각 사업본부별로 도메인이 다르고, 필요한 소프트웨어 기술이 다르니까 통합할 수 없었던 것이 아니었을까? 물론 요즘은 DTV나 휴대폰의 하드웨어 성능을 따져보면 소위말하는 스펙이 별반차이 나지 않는다. 그리고, 많은 전자 기기들이 더 많은 기능들을 담고 있어 기기간의 소프트웨어의 유사성이 점점 많아지고 있는 것은 사실이다. 하지만, 어떤 부분을 전사적으로 통합해서 개발 관리하고, 어떤 부분을 사업본부별로 특화시킬 것인지에 대해 피 터지는 고민이 실행된다면 별 효과가 없을 것이다.
네째, 어떻게 성과를 측정할 것인가? 소프트웨어 개발팀이 사업본부에서 떨어져 나올 수 없는 이유 중에 하나가 바로 소프트웨어 개발 성과를 공정하게 평가하고 보상할 방법이 없다는 것이다. 많은 기업이 소프트웨어의 중요성을 역설하지만, 아무도 얼마나 중요한지를 구체적으로 설명하지 못한다. Microsoft나 Google과 같은 회사의 그들이 판매하는 소프트웨어 매출로 소프트웨어 개발의 중요성을 설명할 수 있다. 그러나, 대부분의 하드웨어 개발에서 출발한 회사들은 소프트웨어는 아직도 공짜라고 생각한다. 예를 들어, 기존 리모컨 의 기능은 그대로 두고 버튼 10개를 줄이면 제품당 단가를 100원 절약할 수 있고 리모컨이 들어가는 제품이 연간 100만대 판매된다고 하자. 그러면, 연간 1억원을 절약할 수 있으니 버튼을 줄이자고 한다. 그러면, 어떻게 줄일 것이냐? 소프트웨어로 처리하면되지 라는 말이 서슴없이 나온다. 그러나, 잘 따져보면 소프트웨로로 그 기능을 구현하는 것 역시 1억 가까운 돈이 들어 갈 것이다. 기존 소프트웨어 바꿔야지 바꾼 소프트웨어 테스트해야지.. 버튼 있는 버젼과 없는 버젼 나누어서 관리해야지.. 3명이서 3개월동안 이 일에 매달린다고 하면, 거의 1억쓰는 것과 별반 다름 없는 것이다.
아직도 같은 회사에서 소프트웨어 개발팀이 을의 위치이고, 적절한 평가 방법이 없는 상황에서 통합 소프트웨어 조직은 일은 다른 조직과 같이 죽어라고하고 보상은 제대로 받지 못하게 될 것이고, 이는 조직의 사기 저하와 직결될 것이다.
한국 전자 산업의 양대 산맥인 삼성전자와 LG 전자가 효과적이고 품질에서 인정받는 소프트웨어 개발을 위해 많이 고심하고 선도주자로써 노력을 많이하고 있지만, 좀 더 소프트웨어에 의한, 소프트웨어를 위한 사고로 전향해야 할 것이다.
고위층이 바뀌면서 상당 부분 예측된 부분이지만 이런 접근 방식은 논란을 일으킬 소지가 다분히 있을 것 같다.
첫째, 근무 위치. 아직 정해지지 않았다고 하지만, 평택이라는 지리적 위치가 아마 기존 인력의 이탈을 불러 올 것이고 새로운 인력을 수급하는데 문제가 있을 것이다. 직장인들의 우선적으로 고려하는 것이 아마 근무처가 아닐까? 대체로 강남에서 1시간 내외의 거리에 있는 곳에 사무실이 있기를 바랄 것이다. 대체로 삼성 계열사가 수원 또는 기흥이 마지노선이 아닐까? 그런데, 더 먼 평택이라니? LG라는 Brand로 커버하기에는 물리적으로 다소 먼 거리가 아닐까 한다.
둘째, 서울 접근성. 근무 위치와 비슷한 의미이지만 협업 차원에서의 문제점이다. 소프트웨어는 한 회사에서 모든 것을 개발할 수 있는 것이 아니다. 개발에 필요한 툴도 사야되고, 자체 내에서 없는 기술을 수급하기 위해서는 외부에 용역을 줘야하고... 또, 새로운 기술을 파악하기 위해 서울에서 열리는 각종 컨퍼런스도 참가 해야하고.. 회사가 강남에 있다는 이 모든 것이 쉬워진다. 지하철타고 1~20분이면 서로 만나 합의점을 찾을 수 있고, 컨퍼런스 갔다가 오후에 들어와 잔무를 처리하고.. 한때 벤쳐들이 테헤란로에 몰려있었던 것이 다 이런 장점을 십분활용하기 위함이 아니었던다.
세째, 어떻게 통합할 것인가? 소프트웨어 개발팀이 사업본부별로 있던 것은 다 이유가 있지 않았을까?
각 사업본부별로 도메인이 다르고, 필요한 소프트웨어 기술이 다르니까 통합할 수 없었던 것이 아니었을까? 물론 요즘은 DTV나 휴대폰의 하드웨어 성능을 따져보면 소위말하는 스펙이 별반차이 나지 않는다. 그리고, 많은 전자 기기들이 더 많은 기능들을 담고 있어 기기간의 소프트웨어의 유사성이 점점 많아지고 있는 것은 사실이다. 하지만, 어떤 부분을 전사적으로 통합해서 개발 관리하고, 어떤 부분을 사업본부별로 특화시킬 것인지에 대해 피 터지는 고민이 실행된다면 별 효과가 없을 것이다.
네째, 어떻게 성과를 측정할 것인가? 소프트웨어 개발팀이 사업본부에서 떨어져 나올 수 없는 이유 중에 하나가 바로 소프트웨어 개발 성과를 공정하게 평가하고 보상할 방법이 없다는 것이다. 많은 기업이 소프트웨어의 중요성을 역설하지만, 아무도 얼마나 중요한지를 구체적으로 설명하지 못한다. Microsoft나 Google과 같은 회사의 그들이 판매하는 소프트웨어 매출로 소프트웨어 개발의 중요성을 설명할 수 있다. 그러나, 대부분의 하드웨어 개발에서 출발한 회사들은 소프트웨어는 아직도 공짜라고 생각한다. 예를 들어, 기존 리모컨 의 기능은 그대로 두고 버튼 10개를 줄이면 제품당 단가를 100원 절약할 수 있고 리모컨이 들어가는 제품이 연간 100만대 판매된다고 하자. 그러면, 연간 1억원을 절약할 수 있으니 버튼을 줄이자고 한다. 그러면, 어떻게 줄일 것이냐? 소프트웨어로 처리하면되지 라는 말이 서슴없이 나온다. 그러나, 잘 따져보면 소프트웨로로 그 기능을 구현하는 것 역시 1억 가까운 돈이 들어 갈 것이다. 기존 소프트웨어 바꿔야지 바꾼 소프트웨어 테스트해야지.. 버튼 있는 버젼과 없는 버젼 나누어서 관리해야지.. 3명이서 3개월동안 이 일에 매달린다고 하면, 거의 1억쓰는 것과 별반 다름 없는 것이다.
아직도 같은 회사에서 소프트웨어 개발팀이 을의 위치이고, 적절한 평가 방법이 없는 상황에서 통합 소프트웨어 조직은 일은 다른 조직과 같이 죽어라고하고 보상은 제대로 받지 못하게 될 것이고, 이는 조직의 사기 저하와 직결될 것이다.
한국 전자 산업의 양대 산맥인 삼성전자와 LG 전자가 효과적이고 품질에서 인정받는 소프트웨어 개발을 위해 많이 고심하고 선도주자로써 노력을 많이하고 있지만, 좀 더 소프트웨어에 의한, 소프트웨어를 위한 사고로 전향해야 할 것이다.
2010년 10월 4일 월요일
삼성전자 PLM 1차 개발 완료
작년 이맘때 삼성전자가 PLM을 자체 개발한다는 뉴스가 나왔다. 일년이 지나 어떻게 되었나 궁금해서 검색을해 보니 지난 2010년 7월 2일자 아이뉴스 인터넷판에 삼성전자 PLM 1차 개발 완료와 전면 적용이라는 기사가 올라왔다. 물론 3개월의 안정화 기간이 필요하다는 조건과 함께.. 이렇거나 저렇거나 거의 1년도 안되어 PLM 시스템개발이 완료된 것이다.
대단한 삼성전자인 것 같다. 쉽지 않은 PLM 개발을 1년만에 1차 개발을 완료하고 전면 적용을하다니...
삼성전자의 무궁한 발전을 빌며... 더 나은 PLM 시스템을 개발 운영하시기를...
대단한 삼성전자인 것 같다. 쉽지 않은 PLM 개발을 1년만에 1차 개발을 완료하고 전면 적용을하다니...
삼성전자의 무궁한 발전을 빌며... 더 나은 PLM 시스템을 개발 운영하시기를...
2010년 8월 31일 화요일
SyncToy 2.1
비싼 RAID로 구성된 Storage가 있다면 모를까 나 같은 Hungry 일반 유저들은 중요한 데이타가 혹시나 날려버릴까 외장형 하드디스크 여러군데 중복하여 데이타를 저장한다. 그래서, 손 가는데로 한번에 여기에 한번에 저기에 파일을 저장하거나 지우게 된다. 그러다 보면 여러군데 복사해둔 것 중에 어느 곳에 있는 것이 최신버젼인지 아리까리 해지고, 폴더 전체를 복사하다보니 시간도 많이 소비된다. 특히나 Network으로 연결된 Remote Storage인 경우에는 특히나 시간을 엄청나게 잡아 먹는다.
그래서, File 이나 Folder Synchronization하는 툴을 하나 만들까 하다 혹시나 Google 검색을 했더니, 나 같은 생각을 가진 누군가가 벌써 만들어 무료로 배포하고 있다. 이름하여 SyncToy. http://www.microsoft.com/downloads/details.aspx?familyid=C26EFA36-98E0-4EE9-A7C5-98D0592D8C52&displaylang=en#filelist에서 Download 받을 수 있다. UI도 간단하여 사용하기도 쉽다.
오늘의 생각
필요는 발명의 어머니, 내가 필요한 것은 벌써 누군가가 만들어 두었을지도 모르니 검색을 잘하자.
그래서, File 이나 Folder Synchronization하는 툴을 하나 만들까 하다 혹시나 Google 검색을 했더니, 나 같은 생각을 가진 누군가가 벌써 만들어 무료로 배포하고 있다. 이름하여 SyncToy. http://www.microsoft.com/downloads/details.aspx?familyid=C26EFA36-98E0-4EE9-A7C5-98D0592D8C52&displaylang=en#filelist에서 Download 받을 수 있다. UI도 간단하여 사용하기도 쉽다.
오늘의 생각
필요는 발명의 어머니, 내가 필요한 것은 벌써 누군가가 만들어 두었을지도 모르니 검색을 잘하자.
2010년 8월 29일 일요일
Free from wired
마침내 내가 원하는 물건을 찾았다. 이름하여 Iomega® iConnect Wireless Data Station
유선으로 연결된 프린터와 3개나 되는 외장형 하드디스크를 무선으로 접근하여 사용하게 할 수 있는 장비다. 판매가는 $99이고 아마존에서 $87에 살 수 있다. 무선의 편리함을 알면 알수록 하나쯤 사고 싶은 물건이다.
2010년 3월 5일 금요일
Trac & SVN
하루 종일 Trac/SVN Integration한다고 고생했다. Trac (http://trac.edgewall.org/)은 Change Management를 위한 Open Source Tool이고 SVN (http://subversion.tigris.org/)은 Configuration Management를 위한 Open Source Tool이다.
Apache 2.2가 Python 2.6 Module을 지원하지 않은 바람에 Python 2.5로 Downgrade하고 모든 소프트웨로를 재설치하였다. Windows 환경이라도 많은 이들이 인터넷 상에 설치 가이드를 올려두어 설치는 그리 어렵지 않다. 그러나 Trac에서 Ticket를 생성하는 방법을 찾기 위해 한참 헤메고, SVN의 Version 정보와 Trac Ticket를 연동시키는 방법을 찾는데 한참이 걸렸다.
먼저, Trac에서 Ticket 생성은 Login을 하면 New Ticket 메뉴가 나타난다. 문제는 로그인 방법인데, Apapche를 설치하고 난 다음 설치 폴더 밑의 Bin 폴더의 htpasswd.exe를 이용하여 User ID와 Password를 설정하면 Trac에 Login할 수 있다.
두번재, SVN과 Trac Ticket 연동하기 위해서는 SVN hooks 폴더에 post-commit.bat를 생성하고
c:\Python25\python.exe %1\hooks\post-commit.py %1 %2와 같이 script를 정의한다.
같은 폴더에 post-commit.py를 생성한 뒤 다음의 Perl Script를 입력한다.
#!/bin/sh
# POST-COMMIT HOOK
#
# This hook calls the trac post commit hook with the required variables
#
import sys,os
import commands
import time
ERRORFILE = "C:\\tracProject\\testProject\\post-commit.log"
f = open( ERRORFILE, "a" )
try:
repos = sys.argv[1]
rev = sys.argv[2]
log = os.popen( "C:\\Progra~1\\Subversion\\bin\\svnlook.exe log " +
repos + " -r " + rev ).read().strip()
author = os.popen( "C:\\Progra~1\\Subversion\bin\\svnlook.exe log "
+ repos + " -r " + rev ).read().strip()
trac_env = 'C:\\tracProject\\testProject'
result = os.popen( "c:\\Python25\\python c:\\Python25\\Scripts\\trac-post-commit-hook.py \
-p \"" + trac_env +"\" \
-r \"" + rev +"\" \
-u \"" + author +"\" \
-m \"" + log +"\"" \
).read().strip()
print >> f, time.strftime( "%a, %d %b %Y %H:%M:%S +0000",
time.localtime())
print >> f, "repos:" + repos
print >> f, "rev:" + rev
print >> f, "author:" + author
print >> f, "log:" + log
print >> f, "trac_env:" + trac_env
print >> f, "result:" + result
except:
import traceback
type, value, tb = sys.exc_info()
stack = traceback.extract_tb( tb )
print >> f, time.strftime( "%a, %d %b %Y %H:%M:%S +0000",
time.localtime())
#print >> f, rev
print >> f, "\n".join( traceback.format_list( stack ) )
print >> f, "Type: %s
" % type
print >> f, "Value: %s
" % value
raise
마지막으로 trac-post-commit-hook.py를 생성하여
#!/usr/bin/env python
# trac-post-commit-hook
# ----------------------------------------------------------------------------
# Copyright (c) 2004 Stephen Hansen
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to
# deal in the Software without restriction, including without limitation the
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
# sell copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
# ----------------------------------------------------------------------------
# This Subversion post-commit hook script is meant to interface to the
# Trac (http://www.edgewall.com/products/trac/) issue tracking/wiki/etc
# system.
#
# It should be called from the 'post-commit' script in Subversion, such as
# via:
#
# REPOS="$1"
# REV="$2"
# LOG=`/usr/bin/svnlook log -r $REV $REPOS`
# AUTHOR=`/usr/bin/svnlook author -r $REV $REPOS`
# TRAC_ENV='/somewhere/trac/project/'
# TRAC_URL='http://trac.mysite.com/project/'
#
# /usr/bin/python /usr/local/src/trac/contrib/trac-post-commit-hook \
# -p "$TRAC_ENV" \
# -r "$REV" \
# -u "$AUTHOR" \
# -m "$LOG" \
# -s "$TRAC_URL"
#
# It searches commit messages for text in the form of:
# command #1
# command #1, #2
# command #1 & #2
# command #1 and #2
#
# You can have more then one command in a message. The following commands
# are supported. There is more then one spelling for each command, to make
# this as user-friendly as possible.
#
# closes, fixes
# The specified issue numbers are closed with the contents of this
# commit message being added to it.
# references, refs, addresses, re
# The specified issue numbers are left in their current status, but
# the contents of this commit message are added to their notes.
#
# A fairly complicated example of what you can do is with a commit message
# of:
#
# Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
#
# This will close #10 and #12, and add a note to #12.
import re
import os
import sys
import time
from trac.env import open_environment
from trac.ticket.notification import TicketNotifyEmail
from trac.ticket import Ticket
from trac.ticket.web_ui import TicketModule
# TODO: move grouped_changelog_entries to model.py
from trac.util.text import to_unicode
from trac.web.href import Href
from trac.versioncontrol.api import NoSuchChangeset
try:
from optparse import OptionParser
except ImportError:
try:
from optik import OptionParser
except ImportError:
raise ImportError, 'Requires Python 2.3 or the Optik option parsing library.'
parser = OptionParser()
depr = '(not used anymore)'
parser.add_option('-e', '--require-envelope', dest='env', default='',
help="""
Require commands to be enclosed in an envelope.
If -e[], then commands must be in the form of [closes #4].
Must be two characters.""")
parser.add_option('-p', '--project', dest='project',
help='Path to the Trac project.')
parser.add_option('-r', '--revision', dest='rev',
help='Repository revision number.')
parser.add_option('-u', '--user', dest='user',
help='The user who is responsible for this action '+depr)
parser.add_option('-m', '--msg', dest='msg',
help='The log message to search '+depr)
parser.add_option('-c', '--encoding', dest='encoding',
help='The encoding used by the log message '+depr)
parser.add_option('-s', '--siteurl', dest='url',
help='The base URL to the project\'s trac website (to which '
'/ticket/## is appended). If this is not specified, '
'the project URL from trac.ini will be used.')
(options, args) = parser.parse_args(sys.argv[1:])
if options.env:
leftEnv = '\\' + options.env[0]
rghtEnv = '\\' + options.env[1]
else:
leftEnv = ''
rghtEnv = ''
commandPattern = re.compile(leftEnv + r'(?P[A-Za-z]*).?(?P#[0-9]+(?:(?:[, &]*|[ ]?and[ ]?)#[0-9]+)*)' + rghtEnv)
ticketPattern = re.compile(r'#([0-9]*)')
class CommitHook:
_supported_cmds = {'close': '_cmdClose',
'closed': '_cmdClose',
'closes': '_cmdClose',
'fix': '_cmdClose',
'fixed': '_cmdClose',
'fixes': '_cmdClose',
'addresses': '_cmdRefs',
're': '_cmdRefs',
'references': '_cmdRefs',
'refs': '_cmdRefs',
'ticket': '_cmdRefs',
'Ticket': '_cmdRefs',
'see': '_cmdRefs'}
def __init__(self, project=options.project, author=options.user,
rev=options.rev, url=options.url):
self.env = open_environment(project)
repos = self.env.get_repository()
repos.sync()
# Instead of bothering with the encoding, we'll use unicode data
# as provided by the Trac versioncontrol API (#1310).
try:
chgset = repos.get_changeset(rev)
except NoSuchChangeset:
return # out of scope changesets are not cached
self.author = chgset.author
self.rev = rev
self.msg = "(In [%s]) %s" % (rev, chgset.message)
self.now = int(time.time())
if url is None:
url = self.env.config.get('trac', 'base_url')
self.env.href = Href(url)
self.env.abs_href = Href(url)
cmdGroups = commandPattern.findall(self.msg)
tickets = {}
for cmd, tkts in cmdGroups:
funcname = CommitHook._supported_cmds.get(cmd.lower(), '')
if funcname:
for tkt_id in ticketPattern.findall(tkts):
func = getattr(self, funcname)
tickets.setdefault(tkt_id, []).append(func)
for tkt_id, cmds in tickets.iteritems():
try:
db = self.env.get_db_cnx()
ticket = Ticket(self.env, int(tkt_id), db)
for cmd in cmds:
cmd(ticket)
# determine sequence number...
cnum = 0
tm = TicketModule(self.env)
for change in tm.grouped_changelog_entries(ticket, db):
if change['permanent']:
cnum += 1
ticket.save_changes(self.author, self.msg, self.now, db, cnum+1)
db.commit()
tn = TicketNotifyEmail(self.env)
tn.notify(ticket, newticket=0, modtime=self.now)
except Exception, e:
# import traceback
# traceback.print_exc(file=sys.stderr)
print>>sys.stderr, 'Unexpected error while processing ticket ' \
'ID %s: %s' % (tkt_id, e)
def _cmdClose(self, ticket):
ticket['status'] = 'closed'
ticket['resolution'] = 'fixed'
def _cmdRefs(self, ticket):
pass
if __name__ == "__main__":
if len(sys.argv) < 5:
print "For usage: %s --help" % (sys.argv[0])
print
print "Note that the deprecated options will be removed in Trac 0.12."
else:
CommitHook()
를 입력한다.
trac-post-commit-hook.py 중간에 보면 SVN에 Commit할 때 사용가능한 Command가 정의 되어있다. 예를 들어 close, fix, addresses 등등등...
Apache 2.2가 Python 2.6 Module을 지원하지 않은 바람에 Python 2.5로 Downgrade하고 모든 소프트웨로를 재설치하였다. Windows 환경이라도 많은 이들이 인터넷 상에 설치 가이드를 올려두어 설치는 그리 어렵지 않다. 그러나 Trac에서 Ticket를 생성하는 방법을 찾기 위해 한참 헤메고, SVN의 Version 정보와 Trac Ticket를 연동시키는 방법을 찾는데 한참이 걸렸다.
먼저, Trac에서 Ticket 생성은 Login을 하면 New Ticket 메뉴가 나타난다. 문제는 로그인 방법인데, Apapche를 설치하고 난 다음 설치 폴더 밑의 Bin 폴더의 htpasswd.exe를 이용하여 User ID와 Password를 설정하면 Trac에 Login할 수 있다.
두번재, SVN과 Trac Ticket 연동하기 위해서는 SVN hooks 폴더에 post-commit.bat를 생성하고
c:\Python25\python.exe %1\hooks\post-commit.py %1 %2와 같이 script를 정의한다.
같은 폴더에 post-commit.py를 생성한 뒤 다음의 Perl Script를 입력한다.
#!/bin/sh
# POST-COMMIT HOOK
#
# This hook calls the trac post commit hook with the required variables
#
import sys,os
import commands
import time
ERRORFILE = "C:\\tracProject\\testProject\\post-commit.log"
f = open( ERRORFILE, "a" )
try:
repos = sys.argv[1]
rev = sys.argv[2]
log = os.popen( "C:\\Progra~1\\Subversion\\bin\\svnlook.exe log " +
repos + " -r " + rev ).read().strip()
author = os.popen( "C:\\Progra~1\\Subversion\bin\\svnlook.exe log "
+ repos + " -r " + rev ).read().strip()
trac_env = 'C:\\tracProject\\testProject'
result = os.popen( "c:\\Python25\\python c:\\Python25\\Scripts\\trac-post-commit-hook.py \
-p \"" + trac_env +"\" \
-r \"" + rev +"\" \
-u \"" + author +"\" \
-m \"" + log +"\"" \
).read().strip()
print >> f, time.strftime( "%a, %d %b %Y %H:%M:%S +0000",
time.localtime())
print >> f, "repos:" + repos
print >> f, "rev:" + rev
print >> f, "author:" + author
print >> f, "log:" + log
print >> f, "trac_env:" + trac_env
print >> f, "result:" + result
except:
import traceback
type, value, tb = sys.exc_info()
stack = traceback.extract_tb( tb )
print >> f, time.strftime( "%a, %d %b %Y %H:%M:%S +0000",
time.localtime())
#print >> f, rev
print >> f, "\n".join( traceback.format_list( stack ) )
print >> f, "Type: %s
" % type
print >> f, "Value: %s
" % value
raise
마지막으로 trac-post-commit-hook.py를 생성하여
#!/usr/bin/env python
# trac-post-commit-hook
# ----------------------------------------------------------------------------
# Copyright (c) 2004 Stephen Hansen
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to
# deal in the Software without restriction, including without limitation the
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
# sell copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
# ----------------------------------------------------------------------------
# This Subversion post-commit hook script is meant to interface to the
# Trac (http://www.edgewall.com/products/trac/) issue tracking/wiki/etc
# system.
#
# It should be called from the 'post-commit' script in Subversion, such as
# via:
#
# REPOS="$1"
# REV="$2"
# LOG=`/usr/bin/svnlook log -r $REV $REPOS`
# AUTHOR=`/usr/bin/svnlook author -r $REV $REPOS`
# TRAC_ENV='/somewhere/trac/project/'
# TRAC_URL='http://trac.mysite.com/project/'
#
# /usr/bin/python /usr/local/src/trac/contrib/trac-post-commit-hook \
# -p "$TRAC_ENV" \
# -r "$REV" \
# -u "$AUTHOR" \
# -m "$LOG" \
# -s "$TRAC_URL"
#
# It searches commit messages for text in the form of:
# command #1
# command #1, #2
# command #1 & #2
# command #1 and #2
#
# You can have more then one command in a message. The following commands
# are supported. There is more then one spelling for each command, to make
# this as user-friendly as possible.
#
# closes, fixes
# The specified issue numbers are closed with the contents of this
# commit message being added to it.
# references, refs, addresses, re
# The specified issue numbers are left in their current status, but
# the contents of this commit message are added to their notes.
#
# A fairly complicated example of what you can do is with a commit message
# of:
#
# Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
#
# This will close #10 and #12, and add a note to #12.
import re
import os
import sys
import time
from trac.env import open_environment
from trac.ticket.notification import TicketNotifyEmail
from trac.ticket import Ticket
from trac.ticket.web_ui import TicketModule
# TODO: move grouped_changelog_entries to model.py
from trac.util.text import to_unicode
from trac.web.href import Href
from trac.versioncontrol.api import NoSuchChangeset
try:
from optparse import OptionParser
except ImportError:
try:
from optik import OptionParser
except ImportError:
raise ImportError, 'Requires Python 2.3 or the Optik option parsing library.'
parser = OptionParser()
depr = '(not used anymore)'
parser.add_option('-e', '--require-envelope', dest='env', default='',
help="""
Require commands to be enclosed in an envelope.
If -e[], then commands must be in the form of [closes #4].
Must be two characters.""")
parser.add_option('-p', '--project', dest='project',
help='Path to the Trac project.')
parser.add_option('-r', '--revision', dest='rev',
help='Repository revision number.')
parser.add_option('-u', '--user', dest='user',
help='The user who is responsible for this action '+depr)
parser.add_option('-m', '--msg', dest='msg',
help='The log message to search '+depr)
parser.add_option('-c', '--encoding', dest='encoding',
help='The encoding used by the log message '+depr)
parser.add_option('-s', '--siteurl', dest='url',
help='The base URL to the project\'s trac website (to which '
'/ticket/## is appended). If this is not specified, '
'the project URL from trac.ini will be used.')
(options, args) = parser.parse_args(sys.argv[1:])
if options.env:
leftEnv = '\\' + options.env[0]
rghtEnv = '\\' + options.env[1]
else:
leftEnv = ''
rghtEnv = ''
commandPattern = re.compile(leftEnv + r'(?P
ticketPattern = re.compile(r'#([0-9]*)')
class CommitHook:
_supported_cmds = {'close': '_cmdClose',
'closed': '_cmdClose',
'closes': '_cmdClose',
'fix': '_cmdClose',
'fixed': '_cmdClose',
'fixes': '_cmdClose',
'addresses': '_cmdRefs',
're': '_cmdRefs',
'references': '_cmdRefs',
'refs': '_cmdRefs',
'ticket': '_cmdRefs',
'Ticket': '_cmdRefs',
'see': '_cmdRefs'}
def __init__(self, project=options.project, author=options.user,
rev=options.rev, url=options.url):
self.env = open_environment(project)
repos = self.env.get_repository()
repos.sync()
# Instead of bothering with the encoding, we'll use unicode data
# as provided by the Trac versioncontrol API (#1310).
try:
chgset = repos.get_changeset(rev)
except NoSuchChangeset:
return # out of scope changesets are not cached
self.author = chgset.author
self.rev = rev
self.msg = "(In [%s]) %s" % (rev, chgset.message)
self.now = int(time.time())
if url is None:
url = self.env.config.get('trac', 'base_url')
self.env.href = Href(url)
self.env.abs_href = Href(url)
cmdGroups = commandPattern.findall(self.msg)
tickets = {}
for cmd, tkts in cmdGroups:
funcname = CommitHook._supported_cmds.get(cmd.lower(), '')
if funcname:
for tkt_id in ticketPattern.findall(tkts):
func = getattr(self, funcname)
tickets.setdefault(tkt_id, []).append(func)
for tkt_id, cmds in tickets.iteritems():
try:
db = self.env.get_db_cnx()
ticket = Ticket(self.env, int(tkt_id), db)
for cmd in cmds:
cmd(ticket)
# determine sequence number...
cnum = 0
tm = TicketModule(self.env)
for change in tm.grouped_changelog_entries(ticket, db):
if change['permanent']:
cnum += 1
ticket.save_changes(self.author, self.msg, self.now, db, cnum+1)
db.commit()
tn = TicketNotifyEmail(self.env)
tn.notify(ticket, newticket=0, modtime=self.now)
except Exception, e:
# import traceback
# traceback.print_exc(file=sys.stderr)
print>>sys.stderr, 'Unexpected error while processing ticket ' \
'ID %s: %s' % (tkt_id, e)
def _cmdClose(self, ticket):
ticket['status'] = 'closed'
ticket['resolution'] = 'fixed'
def _cmdRefs(self, ticket):
pass
if __name__ == "__main__":
if len(sys.argv) < 5:
print "For usage: %s --help" % (sys.argv[0])
print "Note that the deprecated options will be removed in Trac 0.12."
else:
CommitHook()
를 입력한다.
trac-post-commit-hook.py 중간에 보면 SVN에 Commit할 때 사용가능한 Command가 정의 되어있다. 예를 들어 close, fix, addresses 등등등...
2010년 1월 28일 목요일
iPad Release
아침부터 iPad 발표에 미국 방송들이 난리가 아니다. Tablet PC가 iPad가 최초가 아닐진데 Apple과 Steve Jobs라는 Brand Power가 미국인들뿐만아니라 전세계인들을 열광케하는가 보다...
아직 사용해 보지 않았고 사용 후기도 없지만 Apple.com에 나온 정보를 바탕으로 볼 때, 기존 Tablet PC에 비해 iPad는 많은 기능을 과감하게 반영하지 않고 범용적인 PC보다는 Web Browsing과 Entertainment를 타겟으로 한 것 같다.
그 첫번째 이유로는 Keyboard. Tablet PC Category에 들어간다고 하니 먼저 떠오르는 것이 Key입력은 어떻게 할까 궁금하였다. 기존 Tablet에서는 한 면은 Screen이 차지하고 다른 한 면은 Keyboard가 위지하도록하여 PC의 기능을 불편한지만 나름 만족하게 제공하려고 하였지만, iPad는 Virtual Keyboard라하여 Touch기반의 Keyboard를 이용하여 Scrren상에서 문자를 입력하도록 되어있는 것 같다. 이는 Programming이나 문서작성 같이 입력이 많은 작업을 고려하지 않는다는 것이 아닐까 한다. 물론 Accessory로 Keyboard Dock을 팔기도 하지만...
두번째로는 MacOS보다는 iPod나 iPhone과 유사는 User Interface. 이는 Mac 사용자 보다는 더 많은 사용자(?)들이 있는 iPod나 iPhone 사용자들이 iPad를 구입하였을 때 새로운 뭔가를 학습하지 않고 그 들이 기존에 알고 있는 지식과 무의무식 중에 행하던 사용 습관을 그대로 이어가도록하여 제품의 사용성을 극대화하기 위함이 아닐까 한다.
세번째는 가격. 미국 최저 판매 가격으로 $499로 책정되었다. Amazon Kindle보다는 많이 비싸고 ASUS난 HP 등에서 출시하고 있는 NetPC(?)에 비해 Apple이라는 자존심을 조금 보탠 가격인 것같다. Web Surfing, eBook Reading, 동영상 감상을 주로 하는 그룹을 위한 조금 Luxuray한 것 같으면서도 구매 충돌을 유발시키는 제품이 아닐까 한다.
학생이나 전문직에서 일하는 사람들, 그리고 기존 iPhone과 Laptop 또는 Net PC를 가진 사람들이 iPad를 추가로 구입하기에는 조금 적절하지 않은 것 같으며, 구형 Labtop의 대치품으로 Entertainment를 위한 Laptop이 필요한 사람들에게는 Appeal할 수 있지 않을까 한다.
아직 사용해 보지 않았고 사용 후기도 없지만 Apple.com에 나온 정보를 바탕으로 볼 때, 기존 Tablet PC에 비해 iPad는 많은 기능을 과감하게 반영하지 않고 범용적인 PC보다는 Web Browsing과 Entertainment를 타겟으로 한 것 같다.
그 첫번째 이유로는 Keyboard. Tablet PC Category에 들어간다고 하니 먼저 떠오르는 것이 Key입력은 어떻게 할까 궁금하였다. 기존 Tablet에서는 한 면은 Screen이 차지하고 다른 한 면은 Keyboard가 위지하도록하여 PC의 기능을 불편한지만 나름 만족하게 제공하려고 하였지만, iPad는 Virtual Keyboard라하여 Touch기반의 Keyboard를 이용하여 Scrren상에서 문자를 입력하도록 되어있는 것 같다. 이는 Programming이나 문서작성 같이 입력이 많은 작업을 고려하지 않는다는 것이 아닐까 한다. 물론 Accessory로 Keyboard Dock을 팔기도 하지만...
두번째로는 MacOS보다는 iPod나 iPhone과 유사는 User Interface. 이는 Mac 사용자 보다는 더 많은 사용자(?)들이 있는 iPod나 iPhone 사용자들이 iPad를 구입하였을 때 새로운 뭔가를 학습하지 않고 그 들이 기존에 알고 있는 지식과 무의무식 중에 행하던 사용 습관을 그대로 이어가도록하여 제품의 사용성을 극대화하기 위함이 아닐까 한다.
세번째는 가격. 미국 최저 판매 가격으로 $499로 책정되었다. Amazon Kindle보다는 많이 비싸고 ASUS난 HP 등에서 출시하고 있는 NetPC(?)에 비해 Apple이라는 자존심을 조금 보탠 가격인 것같다. Web Surfing, eBook Reading, 동영상 감상을 주로 하는 그룹을 위한 조금 Luxuray한 것 같으면서도 구매 충돌을 유발시키는 제품이 아닐까 한다.
학생이나 전문직에서 일하는 사람들, 그리고 기존 iPhone과 Laptop 또는 Net PC를 가진 사람들이 iPad를 추가로 구입하기에는 조금 적절하지 않은 것 같으며, 구형 Labtop의 대치품으로 Entertainment를 위한 Laptop이 필요한 사람들에게는 Appeal할 수 있지 않을까 한다.
2009년 10월 10일 토요일
삼성전자, PLM 자체 개발
오늘 전사신문 인테넷판을 보니 삼성전자가 외산 솔루션 도입을 도입하여 총 600억원 규모로 개발하려던 전사 차세대 제품수명주기관리(PLM, Product LifeCycle Management) 시스템 구축 프로젝트를 철회하고, 자체 개발로 전격 선회하였다고 한다. 자체 개발 방법으로는 삼성SDS와 공동 개발하고 개발 인력은 200여명, 개발 기간은 약 3년간 3단계로 나뉘어 진행할 예정이라고 한다. 개발 언어는 Java를 이용한다고 한다. 삼성전자가 자체 개발 방침을 결정하게 된 이유를 보니 상용 PLM 솔루션으로는 신제품 사양이 결정되기 전인 기획 단계 및 시뮬레이션 단계를 효율적인 관리하기 어렵다는 것이다.
대단한 뉴스이고 이 프로젝트가 성공적으로 끝난다면 삼성전자는 제조업과 더불어 소프트웨어 산업, 그 중에서도 PLM 분야에서 새로운 위치를 확보할 수 있는 획기적인 사건이 될 것이다. 왜냐하면, 삼성전자는 일반 전자회사와는 달리 뚜렷한 색깔이 없는 회사이다. 예를 들어, Intel하면 반도체, Sony하면 가전제품과 게임기, Nokia하면 휴대폰, HP하면 Computer와 Printer 등등 각 회사를 대표하는 뚜렷한 색깔을 가지고 있다. 그런데, Samsung하고 물으면 어떤 사람은 반도체, 어떤 사람은 휴대폰, 어떤 사람은 Digital TV 등등 삼성에 대한 통일된 이미지가 없다. 기업 브랜드 강화 측면에서는 많은 어려움이 있겠지만 이런 다양한 사업군을 가졌기 때문에 삼성전자가 이런 불황기에도 견고한 성장을 할 수 있는 원동력이 될 수 있을 것이다. 그런데, 갑자기 왜 PLM 이야기를 하다가 사업군에 대한 이야기를 한 것인가?
PLM이라는 것이 한 제품의 탄생과 퇴출까지를 관리하는 어마어마한 시스템이다. 여기에는 탄생을 위한 사전 작업에 관련된 정보, 제품 기획 및 시뮬레이션뿐만 아니라 개발에 관련된 모든 활동과 개발 이후의 사후 활동까지 관리를 총 망라하는 시스템인 것이다. 따라서 한 제품을 생산하는 기업에서 PLM을 구축하는데 최소 1년이 소요되는데, 삼성전자의 경우에는 그렇게 다양한 제품군을 소화하는 PLM을 3년동안 자체 구축하겠다고 하는 것이니 이 어찌 어마어마한 사건이 아니겠는가?
부디 삼성전자의 이런 행보가 성공적으로 끝나기를 기원하면서 Software Engineering입장에서 바라볼 때 어떠한 문제가 있을 수 있을지 생각해 보자.
1. 개발 범위와 개발 기간
위에서 잠시 언급했지만, 삼성전자의 경우 Major 사업군만 보더라도 반도체, 휴대폰, Digital TV, 그리고 가전과 최소 4개의 사업부분으로 나눌 수 있다. 전사 차세대 제품수명주기관리라는 사업 명칭으로만 보더라도 이 사업은 전 사업군에서 생상되는 모든 제품을 커버할 수 있어야 하고 차세대라는 점에서 기존에 사용하던 상용 시스템의 문제점을 개선하고 미래를 준비하기 위한 새로운 요구 사항을 반영하여 개발되어야 한다는 것이다.
그런데, 문제는 상용 시스템을 사용하지 않기 때문에 전사의 전 제품을 커버할 수 있는 Lifecycle Management의 Core인 PLM Engine과 이 PLM Engine을 기반한 제품별로 Application을 아무것도 없는 백지에서 설계하고 구현해야한다는 것이다. 물론 기존 시스템운영과 유지보수 경험이 도움이 되겠지만 PLM Engine의 경우 최소한 3년이상을 투자하고 개발하여야만 제품화할 정도의 성능과 기능을 갖출 수 있다고 본다면 이 PLM Engine과 Engine을 기반으로한 사업 부분별 Application을 3년내에 개발한다는 것은 굉장히 공격적인 목표가 아닌가 생각된다.
2. 요구 사항 규모
요구 사항 도출 측면에서는 내부 상황을 알 수 없으니 생략하고, 요구 사항 규모를 한번 예상 해 보자.
한국경제 8월 29일자 인터넷판을 보면 삼성전자의 전체 임직원 수가 16만4600명이고 이 가운데 외국인 인력은 8만136명라고 한다. 그러면, 국내 인력은 역시 8만여명이 된다. 이 중 1%인 800명 이 시스템을 사용하고, PLM Wiki에 소개된 4단계, Conceive, Design, Realize, 그리고, Service로 Lifecycle을 관리한다고 가정하자. 그리고 800명이 각 단계별로 중복되지 않는 요구 사항을 10개씩만 제출하였하면 요구 사항만 32,000개가 된다. 말이 요구 사항이 32,000개이지 이 요구 사항을 1줄로 요약해서 적는다하더라도 요구 사항만 A4용지로 1,000 페이지 가량된다. 시간가는 줄 모르고 읽을 수 있는 750 페이지 분량의 Harry Potter를 쉬지 않고 읽더라도 3시간 정도 소요되는데 재미없고 딱딱한 1,000 페이지 분량의 요구 사항을 읽는다는 것은 어마어마한 인내의 시간를 요구 할 것이다. 실제로 이 요구 사항을 시스템화 될 경우에는 이 것의 2배정도의 디자인과 구현에 관련된 요구 사항이 도출될 것이지만 일부만 문서화되고 관리되어 질 것이다.
따라서 이 방대하고 복잡할 시스템 요구 사항을 잘 관리하여 성공적인 프로젝트로 이끌어 내기 위해서는 철저한 요구 사항 관리와 더불어 탁월한 프로젝트 관리 능력이 필요할 것이다.
3. 개발 인력
전사 차세대 제품수명주기관리 구축을 위해 200여명을 3년간 투입한다고 한다. 200명이라고 하면 왠만한 중소기업의 총임직원 수준이다. 그런데 이 만큼의 인원으로 충분히 개발할 수 있을까?
일단 200명 중 개발 관리 및 시스템 디자인 인력, 테스트 인력, 그리고, PLM 공통 부분 개발 인력을 각각 10%로 선배정하면 남는 인원은 140명. 이 140명을 4개 Major 제품별로 배정하면 1개 제품에 35명이 배정된다. Major 제품군 내에 세부 제품까지 고려하다보면 이 35명도 그리 많다고 볼 수 없을 것이다.
4. 개발 비용
전사 차세대 제품수명주기관리 시스템 구축을 위해 600억을 책정한 것 같다. Customization 비용까지 포함된 것인지 모르지만 여하튼 엄청난 비용임은 틀림이 없다. 그런데, 자체 개발로 전환할 경우에는 이 보다 더 싸게 개발할 수 있을까?
신문에 난 기사만으로 보더라도 아니다는 것을 알 수 있다.
200명을 3년동안 투입한다고 하였으니 총 600명이 이 시스템을 구축하기 위해 투입되는 것이다. 일반적으로 대기업에서 정규직 1인을 1년 고용하는데 직간접 비용 포함하여 평균 1억이 든다고 하니 3년동안 600명을 투입하니 기본적으로 600억이 들어가는 셈이다. 순수하게 인건비만 600억이 투자되는 것이다. Hardware 구입 비용과 간접 비용 등을 고려하면 아마 최소 800억은 들어가지 않을까 한다.
삼성전자 내부에서도 이러한 문제점을 충분히 파악하고 3년내에 자체 개발 완료(?)라는 무리수를 두는 것은 아마 겉으로 발표 못하는 내부적인 문제가 있으리라 생각된다. 하지만 기왕 자체 개발이라는 어마어마한 도전을 하는 이상 성공적으로 이 프로젝트를 끝내기 위해
1. 충분한 요구 사항 수집과 관리
2. 실천 가능한 개발 프로세스 수립 및 준수
3. 현실적으로 달성 가능한 목표와 일정
4. 예측 가능한 위험 관리
등과 같은 측면에서 충분한 논의와 통일된 공감대가 형성되어야 할 것이다.
더불어 ROI (Return On Investment)극대화하기 위한 방안으로 개발에 투자한 과정에서 얻은 Know-How를 이용하여 어떻게 이익을 창출할 것인지와 개발된 PLM 시스템의 상용화 방안을 고려하면서 프로젝트를 진행한다면 전사 차세대 제품수명주기관리 구축 프로젝트가 종료될 때 삼성전자 역시 올해 도입을 검토한 Siemens와 같이 PLM Solution을 판매하는 Software 회사가 될 수 있을 것이다.
삼성전자의 또 하나의 무한 도전, 전사 차세대 제품수명주기관리 구축 프로젝트의 건투를 기원하며
대단한 뉴스이고 이 프로젝트가 성공적으로 끝난다면 삼성전자는 제조업과 더불어 소프트웨어 산업, 그 중에서도 PLM 분야에서 새로운 위치를 확보할 수 있는 획기적인 사건이 될 것이다. 왜냐하면, 삼성전자는 일반 전자회사와는 달리 뚜렷한 색깔이 없는 회사이다. 예를 들어, Intel하면 반도체, Sony하면 가전제품과 게임기, Nokia하면 휴대폰, HP하면 Computer와 Printer 등등 각 회사를 대표하는 뚜렷한 색깔을 가지고 있다. 그런데, Samsung하고 물으면 어떤 사람은 반도체, 어떤 사람은 휴대폰, 어떤 사람은 Digital TV 등등 삼성에 대한 통일된 이미지가 없다. 기업 브랜드 강화 측면에서는 많은 어려움이 있겠지만 이런 다양한 사업군을 가졌기 때문에 삼성전자가 이런 불황기에도 견고한 성장을 할 수 있는 원동력이 될 수 있을 것이다. 그런데, 갑자기 왜 PLM 이야기를 하다가 사업군에 대한 이야기를 한 것인가?
PLM이라는 것이 한 제품의 탄생과 퇴출까지를 관리하는 어마어마한 시스템이다. 여기에는 탄생을 위한 사전 작업에 관련된 정보, 제품 기획 및 시뮬레이션뿐만 아니라 개발에 관련된 모든 활동과 개발 이후의 사후 활동까지 관리를 총 망라하는 시스템인 것이다. 따라서 한 제품을 생산하는 기업에서 PLM을 구축하는데 최소 1년이 소요되는데, 삼성전자의 경우에는 그렇게 다양한 제품군을 소화하는 PLM을 3년동안 자체 구축하겠다고 하는 것이니 이 어찌 어마어마한 사건이 아니겠는가?
부디 삼성전자의 이런 행보가 성공적으로 끝나기를 기원하면서 Software Engineering입장에서 바라볼 때 어떠한 문제가 있을 수 있을지 생각해 보자.
1. 개발 범위와 개발 기간
위에서 잠시 언급했지만, 삼성전자의 경우 Major 사업군만 보더라도 반도체, 휴대폰, Digital TV, 그리고 가전과 최소 4개의 사업부분으로 나눌 수 있다. 전사 차세대 제품수명주기관리라는 사업 명칭으로만 보더라도 이 사업은 전 사업군에서 생상되는 모든 제품을 커버할 수 있어야 하고 차세대라는 점에서 기존에 사용하던 상용 시스템의 문제점을 개선하고 미래를 준비하기 위한 새로운 요구 사항을 반영하여 개발되어야 한다는 것이다.
그런데, 문제는 상용 시스템을 사용하지 않기 때문에 전사의 전 제품을 커버할 수 있는 Lifecycle Management의 Core인 PLM Engine과 이 PLM Engine을 기반한 제품별로 Application을 아무것도 없는 백지에서 설계하고 구현해야한다는 것이다. 물론 기존 시스템운영과 유지보수 경험이 도움이 되겠지만 PLM Engine의 경우 최소한 3년이상을 투자하고 개발하여야만 제품화할 정도의 성능과 기능을 갖출 수 있다고 본다면 이 PLM Engine과 Engine을 기반으로한 사업 부분별 Application을 3년내에 개발한다는 것은 굉장히 공격적인 목표가 아닌가 생각된다.
2. 요구 사항 규모
요구 사항 도출 측면에서는 내부 상황을 알 수 없으니 생략하고, 요구 사항 규모를 한번 예상 해 보자.
한국경제 8월 29일자 인터넷판을 보면 삼성전자의 전체 임직원 수가 16만4600명이고 이 가운데 외국인 인력은 8만136명라고 한다. 그러면, 국내 인력은 역시 8만여명이 된다. 이 중 1%인 800명 이 시스템을 사용하고, PLM Wiki에 소개된 4단계, Conceive, Design, Realize, 그리고, Service로 Lifecycle을 관리한다고 가정하자. 그리고 800명이 각 단계별로 중복되지 않는 요구 사항을 10개씩만 제출하였하면 요구 사항만 32,000개가 된다. 말이 요구 사항이 32,000개이지 이 요구 사항을 1줄로 요약해서 적는다하더라도 요구 사항만 A4용지로 1,000 페이지 가량된다. 시간가는 줄 모르고 읽을 수 있는 750 페이지 분량의 Harry Potter를 쉬지 않고 읽더라도 3시간 정도 소요되는데 재미없고 딱딱한 1,000 페이지 분량의 요구 사항을 읽는다는 것은 어마어마한 인내의 시간를 요구 할 것이다. 실제로 이 요구 사항을 시스템화 될 경우에는 이 것의 2배정도의 디자인과 구현에 관련된 요구 사항이 도출될 것이지만 일부만 문서화되고 관리되어 질 것이다.
따라서 이 방대하고 복잡할 시스템 요구 사항을 잘 관리하여 성공적인 프로젝트로 이끌어 내기 위해서는 철저한 요구 사항 관리와 더불어 탁월한 프로젝트 관리 능력이 필요할 것이다.
3. 개발 인력
전사 차세대 제품수명주기관리 구축을 위해 200여명을 3년간 투입한다고 한다. 200명이라고 하면 왠만한 중소기업의 총임직원 수준이다. 그런데 이 만큼의 인원으로 충분히 개발할 수 있을까?
일단 200명 중 개발 관리 및 시스템 디자인 인력, 테스트 인력, 그리고, PLM 공통 부분 개발 인력을 각각 10%로 선배정하면 남는 인원은 140명. 이 140명을 4개 Major 제품별로 배정하면 1개 제품에 35명이 배정된다. Major 제품군 내에 세부 제품까지 고려하다보면 이 35명도 그리 많다고 볼 수 없을 것이다.
4. 개발 비용
전사 차세대 제품수명주기관리 시스템 구축을 위해 600억을 책정한 것 같다. Customization 비용까지 포함된 것인지 모르지만 여하튼 엄청난 비용임은 틀림이 없다. 그런데, 자체 개발로 전환할 경우에는 이 보다 더 싸게 개발할 수 있을까?
신문에 난 기사만으로 보더라도 아니다는 것을 알 수 있다.
200명을 3년동안 투입한다고 하였으니 총 600명이 이 시스템을 구축하기 위해 투입되는 것이다. 일반적으로 대기업에서 정규직 1인을 1년 고용하는데 직간접 비용 포함하여 평균 1억이 든다고 하니 3년동안 600명을 투입하니 기본적으로 600억이 들어가는 셈이다. 순수하게 인건비만 600억이 투자되는 것이다. Hardware 구입 비용과 간접 비용 등을 고려하면 아마 최소 800억은 들어가지 않을까 한다.
삼성전자 내부에서도 이러한 문제점을 충분히 파악하고 3년내에 자체 개발 완료(?)라는 무리수를 두는 것은 아마 겉으로 발표 못하는 내부적인 문제가 있으리라 생각된다. 하지만 기왕 자체 개발이라는 어마어마한 도전을 하는 이상 성공적으로 이 프로젝트를 끝내기 위해
1. 충분한 요구 사항 수집과 관리
2. 실천 가능한 개발 프로세스 수립 및 준수
3. 현실적으로 달성 가능한 목표와 일정
4. 예측 가능한 위험 관리
등과 같은 측면에서 충분한 논의와 통일된 공감대가 형성되어야 할 것이다.
더불어 ROI (Return On Investment)극대화하기 위한 방안으로 개발에 투자한 과정에서 얻은 Know-How를 이용하여 어떻게 이익을 창출할 것인지와 개발된 PLM 시스템의 상용화 방안을 고려하면서 프로젝트를 진행한다면 전사 차세대 제품수명주기관리 구축 프로젝트가 종료될 때 삼성전자 역시 올해 도입을 검토한 Siemens와 같이 PLM Solution을 판매하는 Software 회사가 될 수 있을 것이다.
삼성전자의 또 하나의 무한 도전, 전사 차세대 제품수명주기관리 구축 프로젝트의 건투를 기원하며
2009년 10월 9일 금요일
Blogger에 AdSense를 달다
방문자도 별로 없고 크게 알리고 싶지 않은 Blog를 관리하는지라 AdSense를 달아도 별 소득도 없을 것이라 예상되지만 어떻게 운영되는지 궁금해서 한번 달아 봤다.
2009년 10월 6일 화요일
미국에서 Computer AS 받기
언제 AS망이 잘 같추어진 브랜드 컴퓨터를 사겠냐만 미국에서 계속 산다면 언젠가는 한번 사지 않을까??
한국에서야 Computer가 고장나면 들고 가던가 AS 출장서비스를 부르면 휙하고와서 후다닥하고 고쳐주고 가지만, 미국에서는 가까운 AS 센터가 없으면 우편으로 부쳐서 수리를 받는다. 이 정도는 다 짐작할 수 있을 것이고 구체적으로 어떻게 하는가에 대해선 당해보지 않으니 몰랐는데 며칠 전 옆 집 컴퓨터가 고장나는 바람에 미국 HP Computer의 AS 절차에 대해 대충 알게 되었다.
내 Desktop도 HDD가 고장나서 새로사서 교환한 날 저녁먹고 이것 저것 설치하고 있는데 옆집에서 전화가 왔다. 갑자기 삐 소리만 나고 모니터에 화면이 안 나온다는 것이다. 케이블이 빠져 그럴 수도 있으니 일단 잘 꽂혀 있는지 확인하라고 전화를 끊은 뒤에 가서 한번 보는 것이 좋을 것 같아 옆집에 갔다. 설명하는 여러가지 정황과 HDD로 가는 전원을 차단해도 같은 Beep음이 들리는 것으로 보아 과도한 HDD 사용으로 인한 HDD 불량인 것 같았다.
Warranty가 남아있으면 AS 보내고 아니면 HDD 사면 내가 갈아 주겠다는 말을 남기도 집으로 왔다.
며칠 뒤에 연락이 없길레 물어보니 Warranty가 남아서 AS 받기로 했다며 Box 오기를 기다리고 있단다. 무슨 Box? AS 받는다고 하니 AS 센터에서 Box을 보내줄테니 그 Box에 넣어 파손되지 않게 보내라고 해서 Box 오기를 기다리고 있단다. Box를 공짜로 흠.
Box를 보내준다고 하는 것 보니 AS 보낼 때 택배비는 수취인 부담으로 하는 것 같았다.
그냥 저냥 한 두어달이 지난 뒤에 Computer 어떻게 되었냐고 하니, 그 동안 AS 센터를 두ㅡ번 왔다갔다 했는데 처음에 고쳤다고 보내왔을때는 고친 것 확인도 안했는지 고쳐지지 않았고, 두번째 보냈을 때는 Beep음은 안 나는데 부팅 안되는 것은 마찬가지라고 한다. HDD에 문제가 있는 것 같은데 확인해 봤나고 물어봤더니 그건 대답도 안하고 우리는 우리 절차에 따라 정확하게 확인하고 수리했다고 한다. 적반하장으로 이제 소리 안 나지 않느냐하고 짧은 영어와 Computer 지식으로 대꾸도 못하고 있으니 이젠 AS 센터에서 200불 내고 Warranty 연장할 것인지 아닌지를 물어 본다고 한다.
두어달 동안 Computer는 Computer대로 못 쓰고 고장난 것은 수리도 안 되고...답답하단다.
한국 같으면 1주일만에 못 고쳐내면 화~악 뒤집어 엎고 새 Computer 받아 올 수 있으련만(?)...그런데 200불 주고 Warranty를 연장하는 것이 좋을까 새 것을 하나 사는 것이 좋을까? 고장은 Warranty가 남았있는 동안 나야지, 그 기간이 지나면 새로 사나 고쳐쓰나 기회 비용까지 포함하면 비용상 별반 차이가 없을 것 같다.
2009년 10월 9일..
Office Depot와 BestBuy에 컴퓨터 AS를 해준다고 한다. 흠...
한국에서야 Computer가 고장나면 들고 가던가 AS 출장서비스를 부르면 휙하고와서 후다닥하고 고쳐주고 가지만, 미국에서는 가까운 AS 센터가 없으면 우편으로 부쳐서 수리를 받는다. 이 정도는 다 짐작할 수 있을 것이고 구체적으로 어떻게 하는가에 대해선 당해보지 않으니 몰랐는데 며칠 전 옆 집 컴퓨터가 고장나는 바람에 미국 HP Computer의 AS 절차에 대해 대충 알게 되었다.
내 Desktop도 HDD가 고장나서 새로사서 교환한 날 저녁먹고 이것 저것 설치하고 있는데 옆집에서 전화가 왔다. 갑자기 삐 소리만 나고 모니터에 화면이 안 나온다는 것이다. 케이블이 빠져 그럴 수도 있으니 일단 잘 꽂혀 있는지 확인하라고 전화를 끊은 뒤에 가서 한번 보는 것이 좋을 것 같아 옆집에 갔다. 설명하는 여러가지 정황과 HDD로 가는 전원을 차단해도 같은 Beep음이 들리는 것으로 보아 과도한 HDD 사용으로 인한 HDD 불량인 것 같았다.
Warranty가 남아있으면 AS 보내고 아니면 HDD 사면 내가 갈아 주겠다는 말을 남기도 집으로 왔다.
며칠 뒤에 연락이 없길레 물어보니 Warranty가 남아서 AS 받기로 했다며 Box 오기를 기다리고 있단다. 무슨 Box? AS 받는다고 하니 AS 센터에서 Box을 보내줄테니 그 Box에 넣어 파손되지 않게 보내라고 해서 Box 오기를 기다리고 있단다. Box를 공짜로 흠.
Box를 보내준다고 하는 것 보니 AS 보낼 때 택배비는 수취인 부담으로 하는 것 같았다.
그냥 저냥 한 두어달이 지난 뒤에 Computer 어떻게 되었냐고 하니, 그 동안 AS 센터를 두ㅡ번 왔다갔다 했는데 처음에 고쳤다고 보내왔을때는 고친 것 확인도 안했는지 고쳐지지 않았고, 두번째 보냈을 때는 Beep음은 안 나는데 부팅 안되는 것은 마찬가지라고 한다. HDD에 문제가 있는 것 같은데 확인해 봤나고 물어봤더니 그건 대답도 안하고 우리는 우리 절차에 따라 정확하게 확인하고 수리했다고 한다. 적반하장으로 이제 소리 안 나지 않느냐하고 짧은 영어와 Computer 지식으로 대꾸도 못하고 있으니 이젠 AS 센터에서 200불 내고 Warranty 연장할 것인지 아닌지를 물어 본다고 한다.
두어달 동안 Computer는 Computer대로 못 쓰고 고장난 것은 수리도 안 되고...답답하단다.
한국 같으면 1주일만에 못 고쳐내면 화~악 뒤집어 엎고 새 Computer 받아 올 수 있으련만(?)...그런데 200불 주고 Warranty를 연장하는 것이 좋을까 새 것을 하나 사는 것이 좋을까? 고장은 Warranty가 남았있는 동안 나야지, 그 기간이 지나면 새로 사나 고쳐쓰나 기회 비용까지 포함하면 비용상 별반 차이가 없을 것 같다.
2009년 10월 9일..
Office Depot와 BestBuy에 컴퓨터 AS를 해준다고 한다. 흠...
2009년 7월 1일 수요일
I joined Facebook.com and sent several messages to my ex-coworker. They already use the site intensively. The joining to facebook.com gave me another insight to communication. It seems good to share one's ideas or thoughts even a flash thoughts. This makes us to understand our friends more and better. However, sometimes, it is nothing better the spam mail. One of my friends posted over 10 messages in half an hour. My screen was full of his messages. I digging his posts to see what's useful. But there were nothing. One of spams for me.
It's our own sake how to use facebook.com and how the internet communication should be.
It's our own sake how to use facebook.com and how the internet communication should be.
피드 구독하기:
글 (Atom)