지금도 유효한 10가지 고전적 IT 원칙
OSS
게시글 작성 시각 2013-10-25 15:13:28
2013년 10월 23일 (수)
ⓒ ITWorld, Bob Lewis | InfoWorld
“많은 것들이 똑같을수록 더욱 많은 것들이 변한다.”
원래 속담과는 앞뒤가 바뀐 문구지만 IT를 향하는 모든 문에 새겨 넣어야 할 말이다. “이곳에 들어서는 자는 절망을 맛보게 될지어다”라는 말보다는 훨씬 더 듣기 좋다. 모든 것이 변했다는 사실을 제외하면, IT가 EDP였고 프로그래머가 대사제였던 초창기와 비교할 때 변한 것은 별로 없다.
다행히 IT 초창기의 원칙과 지혜는 여전히 유효하다. 다만 다른, 더 현대화된 형태로 적용될 뿐이다. 이제부터 차세대 IT를 구현하는 데 길잡이가 되는 10가지 고전적인 원칙과 이러한 원칙의 적용 방법에서 변한 부분들을 살펴보자.
1. 관건은 기술이 얼마나 훌륭한지가 아니다
여러분이 구입하는 기술은 여러분 입장에서 장기적인 책무다. 따라서 공급자도 장기적인 책무로 여겨주기를 바란다. 안전을 위해 과거 IT는 큰 업체들에게서 기술을 구입했다. IBM 제품을 구매해서 해고당하는 경우는 없다는 말이 있을 정도였다. 그렇다면, 지금은? 오픈소스도 그만큼 안전할 수 있고, 경우에 따라서는 IBM이나 기타 큰 기업들에게서 오픈소스를 구할 수도 있다.
오픈소스 기술의 경우 모두는 아니지만 대부분 폭넓은 지원 기반이 있다. 예를 들어 PHP로 필요한 일을 다 할 수 있다면 보안 취약점으로 악명 높은 자바를 거들떠나 보겠는가? 그러나 자바는 세계에서 가장 큰 소프트웨어 기업 중 하나인 오라클이 지원한다(지원보다는 “제공한다”는 말이 더 정확하겠지만).
이런 경우가 새로운 것은 아니다. 오픈소스와 유사한 SHARE 라이브러리는 1970년대로 거슬러 올라간다.
2. 강력한 정보 보안의 시작은 강력한 물리적 보안
우리는 항상 하드웨어를 안전하게 보관하고, 소수의 직원에게만 데이터센터 접근 권한을 주고 누가 언제 데이터센터에 들어왔는지에 대한 자동화된 로그를 운영했다. 하지만 지금은 서버 룸 자체가 타인의 소유인 경우가 많다. 특히 중소기업의 경우 코로케이션 설비부터 순수 클라우드에 이르는 대안들이 있다.
그러나 자체 데이터센터를 증축하지 않음으로써 절약된 비용을 모두 저축하지는 말고, 그 중 일부를 오프사이트 공급업체로 연결되는 저지연, 고대역폭 네트워크 연결에 투자하라.
더 좋은 방법이자 또 다른 오래 된 원칙은 무엇이든 하나만 두지 말라는 것이다. 연결을 두 개 만들고, 건물의 양쪽에 접속 지점을 만들어 공사장 굴착기가 구멍을 파다가 비즈니스를 중단시키는 경우가 없도록 해야 한다.
3. 위협을 파악하라
과거에는 보안 위협을 물리치는 일이란 대부분 해커가 전화 접속을 통해 접속하지 못하도록 CICS 세션을 타임아웃시키는 것이었다. 이후 PC, 분산 시스템, 인터넷, 그리고 다양한 위협이 등장했다. 이에 대한 대처로 데스크톱을 봉쇄하고 정교한 방화벽으로 경계를 보호하게 됐다.
많은 이들이 여전히 최고의 대책은 모든 부분을 봉쇄하고 창의적인 사고를 완전히 막는 것이라고 생각한다. 그러나 기업은 혁신에 살고 죽고, 혁신은 단순한 신제품 이상을 의미한다. 혁신이란 창의적으로 사고하고 비즈니스의 모든 부분에 이 사고를 구현하는 것을 뜻한다.
요즘에는 경계보다 자산을 강화하는 데 더 많은 시간을 소비하고 사용자를 지원하는 데 그것보다 더 많은 시간을 소비한다. 기업에게 가장 큰 위협이란 혁신할 수 없는 인력이기 때문이다.
4. 소프트웨어 테스트는 단순히 코드를 프로덕션으로 밀어 넣고 결과를 보는 것이 아니다
회귀 및 스트레스 테스트는 프로와 아마추어를 구분한다. 과거에도 그랬고 앞으로도 그럴 것이다. 회귀 테스트는 새로운 것이 과거의 것을 망가뜨리지 않는지 확인한다. 스트레스 테스트는 사용량이 최대화될 때 모든 부분이 제대로 작동하는지 확인한다.
전문적인 IT 부서는 개발, 테스트, 프로덕션의 최소 세 가지 환경을 유지 관리했다. 이는 모든 것을 3개씩 구입하고, 더불어 그것을 유지 관리하는 것을 의미했다.
지금은 자체 데이터센터를 유지 관리하는 경우에도 클라우드에 테스트 환경을 마련하는 편이 더 나은 경우가 많은데, 이는 필요할 때만 비용을 지불하면 되기 때문이다. 프로덕션 환경에 따라서는 회귀 테스트에도 이 방법이 통할 수 있다.
하지만 스트레스 테스트는 아직 안 된다. 적어도 현재로서는 변수가 너무 많다.
5. 프로덕션 환경에 대한 변화를 통제하라
오래 전에는 개발자가 새 코드를 프로덕션에 던져 넣을 수 있었다. 여기에는 거쳐야 할 프로세스가 있다. 이 프로세스를 좋아하는 사람은 아무도 없지만 프로세스를 좋아하느냐 아니냐는 중요한 게 아니다. 핵심은 변화가 프로덕션을 중단시키지 않도록 하는 것이며, 변화가 프로덕션을 중단시킬 경우를 대비한 철수 계획을 수립하는 것이다.
클라우드가 변화를 일으킨다고 생각하는가? 사실이다. 지금은 클라우드 공급업체 관리에 주의를 기울이지 않으면 이들 업체가 프로세스를 무시한 채 프로덕션에 변화를 가할 수 있기 때문에, 클라우드는 변화 통제를 더욱 어렵게 만든다.
클라우드는 결국 그들의 인프라인 것이다.
6. 폭포수 방법론이 통해야 하지만 실제로는 애자일이 통한다
딱딱한 개발 방법론들이 IT에서 재미라는 요소를 걷어내기 오래 전, 비즈니스 관리자들은 종종 “컴퓨터로 이 일을 할 수 있나요?”라고 묻곤 했다. 프로그래머는 뭔가를 시도해서 결과를 비즈니스 사용자에게 보여주고, 적당한 결과가 나올 때까지 그 과정을 반복했다.
당시 개발자들은 그 방법을 딱히 ‘애자일’이라고 하지는 않았다. 그저 “컴퓨터가 무엇을 해야 하는지에 대해 대화하는 것”이라고 표현했다. 어쨌든 그것은 ‘애자일’이었다.
이후 폭포수 방법론이 등장했는데, 이 방법론이 통하려면 비즈니스 관리자가 완전한 작업 시스템을 구상하고 이를 정확하게 기술할 수 있어야 한다는 전제 조건이 필요했다. 그러나 그것은 불가능했으므로 우리는 30년 동안 생산성을 잃었다.
그리고 반복과 상호작용을 취하는 스크럼이 등장해서는 다른 형태의 애자일 방법론들이 되돌려놓은 IT의 재미를 대부분 없애버렸다...
7. 관계가 프로세스에 우선하고, 관계가 트랜잭션보다 오래 간다
원래 비즈니스는 관계의 집합이다. 관계가 좋으면 모든 부분이 원활하게 움직이지만 관계가 좋지 않으면 아무것도 되지 않는다.
기업이 엄격한 계층으로 구성되고 CIO가 다른 임원들과의 관계를 관리했던 과거에는 그것으로 충분했다. 다른 임원이 CIO를 신뢰하지 않으면 IT는 성공할 수 없었다. 그렇게 단순했다.
그러나 IT 부서의 누군가가 비즈니스 부서의 누군가와 접촉할 때마다 이는 비즈니스/IT 관계에 영향을 미친다. 단순히 CIO와 다른 임원과의 관계가 아니다. 비즈니스의 나머지 사람들이 IT를 신뢰하지 않으면 IT는 성공할 수 없다. IT를 신뢰하면 IT의 모든 부분이 더 쉬워진다(쉬운 것이 아니라 좀 더 쉬워지는 것이다).
8. 통합하라. ‘자동화의 섬’을 서로 연결하면 비즈니스 프로세스의 어리석음을 다수 제거할 수 있다.
인간이 컴퓨터가 생성한 보고서로부터 정보를 데이터 입력 창에 다시 입력하던 시절에 IT는 자신의 가장 중요한 책임 중 하나가 분리된 시스템을 통합해 데이터 동기화를 유지하는 것이라는 것을 알았다. 그래서 IT는 인터페이스를 구축했고, 이들 중 대다수는 모두 맞춤형으로 만든 배치 ETL이었다.
이제는 이런 인터페이스가 너무 많아서 유지하기 힘들 정도가 됐다. 그래서 똑똑한 IT는 서비스 버스와 같은 것에 투자를 한다. 그리고 그 인터페이스도 만들어 낸다. 왜냐하면 다른 요소 위에 뭔가 하나를 만들어내는 것은 빛나는 새 기술로 기존과 똑 같은 혼란을 재창조하는 것일 뿐이기 때문이다.
오늘날 많은 IT가 IT 부서 바깥에서 일어나고 있으며, 대부분 비즈니스 책임자에 의해 SaaS의 형태로 새로운 ‘자동화의 섬’이 만들어진다. 이들은 결국에 직원들이 데이터를 다시 입력하는 것에 지치게 될 것이다. 이에 대해 대비해야 한다.
9. IT는 비즈니스를 지원하기 위해 존재한다
기술을 위한 기술은 당연히 나쁘다. 하지만 IT가 주문서를 처리하는 것으로 자신의 역할을 제한해야 한다는 것은 아니다. 이를 넘어서 기술 리더십을 제공해야만 한다.
어떤 IT 부서라도 기술 리더십 제공에 실패하면, 다시 말해 단지 수용하고 전달하는 것인 아니라 제안하고 논의하는 데 실패하면 기본적으로 실패하고 있는 것이다.
기술 리더십은 또한 스스로 기술을 구매하거나 구축할 준비가 되어 있는 비즈니스 책임자와 사용자를 지원한다는 것을 의미한다. 이제 이른바 ‘그림자 IT(Shadow IT)’가 IT의 범위를 넓여준다는 점에서 좋은 것이라고 인식해야 할 때이다.
물론 위험은 있지만, 모든 가치 있는 일은 위험이 따르기 마련이다. IT는 현업의 모든 사람이 자신들의 기술로 성공할 수 있도록 지원해야만 한다. “여기서 만들어진 것”이 아니라고 배척해서는 안 된다.
10. 모든 것은 비즈니스 변화에 대한 것이다
컴퓨터가 새롭고 빛나는 것일 때, 임원들은 비즈니스 프로세스를 더 빠르고 저렴하게 만들면서 수작업 오류를 없애는 방식으로 모든 곳에 변화를 이끌어내기 위해 컴퓨터에 의지했다.
이런 원칙은 IT가 새로운 것을 하려면 시간이 많이 들고 비싸고 위험한, 상호 연결된 수없이 많은 시스템을 지원하기 전까지 유효했다. 폭포수 방법론에 대한 신뢰 역시 더 이상 도움이 되지 않는다.
IT는 다시 느슨하게 흩어지기 시작했다. 애자일 방법론과 더 나은 통합 툴, 비 IT의 IT 사이에서 IT는 이전 원칙을 따르는 대신 다시 한 번 변화를 주도하기 시작했다.
원래 속담과는 앞뒤가 바뀐 문구지만 IT를 향하는 모든 문에 새겨 넣어야 할 말이다. “이곳에 들어서는 자는 절망을 맛보게 될지어다”라는 말보다는 훨씬 더 듣기 좋다. 모든 것이 변했다는 사실을 제외하면, IT가 EDP였고 프로그래머가 대사제였던 초창기와 비교할 때 변한 것은 별로 없다.
다행히 IT 초창기의 원칙과 지혜는 여전히 유효하다. 다만 다른, 더 현대화된 형태로 적용될 뿐이다. 이제부터 차세대 IT를 구현하는 데 길잡이가 되는 10가지 고전적인 원칙과 이러한 원칙의 적용 방법에서 변한 부분들을 살펴보자.
1. 관건은 기술이 얼마나 훌륭한지가 아니다
여러분이 구입하는 기술은 여러분 입장에서 장기적인 책무다. 따라서 공급자도 장기적인 책무로 여겨주기를 바란다. 안전을 위해 과거 IT는 큰 업체들에게서 기술을 구입했다. IBM 제품을 구매해서 해고당하는 경우는 없다는 말이 있을 정도였다. 그렇다면, 지금은? 오픈소스도 그만큼 안전할 수 있고, 경우에 따라서는 IBM이나 기타 큰 기업들에게서 오픈소스를 구할 수도 있다.
오픈소스 기술의 경우 모두는 아니지만 대부분 폭넓은 지원 기반이 있다. 예를 들어 PHP로 필요한 일을 다 할 수 있다면 보안 취약점으로 악명 높은 자바를 거들떠나 보겠는가? 그러나 자바는 세계에서 가장 큰 소프트웨어 기업 중 하나인 오라클이 지원한다(지원보다는 “제공한다”는 말이 더 정확하겠지만).
이런 경우가 새로운 것은 아니다. 오픈소스와 유사한 SHARE 라이브러리는 1970년대로 거슬러 올라간다.
2. 강력한 정보 보안의 시작은 강력한 물리적 보안
우리는 항상 하드웨어를 안전하게 보관하고, 소수의 직원에게만 데이터센터 접근 권한을 주고 누가 언제 데이터센터에 들어왔는지에 대한 자동화된 로그를 운영했다. 하지만 지금은 서버 룸 자체가 타인의 소유인 경우가 많다. 특히 중소기업의 경우 코로케이션 설비부터 순수 클라우드에 이르는 대안들이 있다.
그러나 자체 데이터센터를 증축하지 않음으로써 절약된 비용을 모두 저축하지는 말고, 그 중 일부를 오프사이트 공급업체로 연결되는 저지연, 고대역폭 네트워크 연결에 투자하라.
더 좋은 방법이자 또 다른 오래 된 원칙은 무엇이든 하나만 두지 말라는 것이다. 연결을 두 개 만들고, 건물의 양쪽에 접속 지점을 만들어 공사장 굴착기가 구멍을 파다가 비즈니스를 중단시키는 경우가 없도록 해야 한다.
3. 위협을 파악하라
과거에는 보안 위협을 물리치는 일이란 대부분 해커가 전화 접속을 통해 접속하지 못하도록 CICS 세션을 타임아웃시키는 것이었다. 이후 PC, 분산 시스템, 인터넷, 그리고 다양한 위협이 등장했다. 이에 대한 대처로 데스크톱을 봉쇄하고 정교한 방화벽으로 경계를 보호하게 됐다.
많은 이들이 여전히 최고의 대책은 모든 부분을 봉쇄하고 창의적인 사고를 완전히 막는 것이라고 생각한다. 그러나 기업은 혁신에 살고 죽고, 혁신은 단순한 신제품 이상을 의미한다. 혁신이란 창의적으로 사고하고 비즈니스의 모든 부분에 이 사고를 구현하는 것을 뜻한다.
요즘에는 경계보다 자산을 강화하는 데 더 많은 시간을 소비하고 사용자를 지원하는 데 그것보다 더 많은 시간을 소비한다. 기업에게 가장 큰 위협이란 혁신할 수 없는 인력이기 때문이다.
4. 소프트웨어 테스트는 단순히 코드를 프로덕션으로 밀어 넣고 결과를 보는 것이 아니다
회귀 및 스트레스 테스트는 프로와 아마추어를 구분한다. 과거에도 그랬고 앞으로도 그럴 것이다. 회귀 테스트는 새로운 것이 과거의 것을 망가뜨리지 않는지 확인한다. 스트레스 테스트는 사용량이 최대화될 때 모든 부분이 제대로 작동하는지 확인한다.
전문적인 IT 부서는 개발, 테스트, 프로덕션의 최소 세 가지 환경을 유지 관리했다. 이는 모든 것을 3개씩 구입하고, 더불어 그것을 유지 관리하는 것을 의미했다.
지금은 자체 데이터센터를 유지 관리하는 경우에도 클라우드에 테스트 환경을 마련하는 편이 더 나은 경우가 많은데, 이는 필요할 때만 비용을 지불하면 되기 때문이다. 프로덕션 환경에 따라서는 회귀 테스트에도 이 방법이 통할 수 있다.
하지만 스트레스 테스트는 아직 안 된다. 적어도 현재로서는 변수가 너무 많다.
5. 프로덕션 환경에 대한 변화를 통제하라
오래 전에는 개발자가 새 코드를 프로덕션에 던져 넣을 수 있었다. 여기에는 거쳐야 할 프로세스가 있다. 이 프로세스를 좋아하는 사람은 아무도 없지만 프로세스를 좋아하느냐 아니냐는 중요한 게 아니다. 핵심은 변화가 프로덕션을 중단시키지 않도록 하는 것이며, 변화가 프로덕션을 중단시킬 경우를 대비한 철수 계획을 수립하는 것이다.
클라우드가 변화를 일으킨다고 생각하는가? 사실이다. 지금은 클라우드 공급업체 관리에 주의를 기울이지 않으면 이들 업체가 프로세스를 무시한 채 프로덕션에 변화를 가할 수 있기 때문에, 클라우드는 변화 통제를 더욱 어렵게 만든다.
클라우드는 결국 그들의 인프라인 것이다.
6. 폭포수 방법론이 통해야 하지만 실제로는 애자일이 통한다
딱딱한 개발 방법론들이 IT에서 재미라는 요소를 걷어내기 오래 전, 비즈니스 관리자들은 종종 “컴퓨터로 이 일을 할 수 있나요?”라고 묻곤 했다. 프로그래머는 뭔가를 시도해서 결과를 비즈니스 사용자에게 보여주고, 적당한 결과가 나올 때까지 그 과정을 반복했다.
당시 개발자들은 그 방법을 딱히 ‘애자일’이라고 하지는 않았다. 그저 “컴퓨터가 무엇을 해야 하는지에 대해 대화하는 것”이라고 표현했다. 어쨌든 그것은 ‘애자일’이었다.
이후 폭포수 방법론이 등장했는데, 이 방법론이 통하려면 비즈니스 관리자가 완전한 작업 시스템을 구상하고 이를 정확하게 기술할 수 있어야 한다는 전제 조건이 필요했다. 그러나 그것은 불가능했으므로 우리는 30년 동안 생산성을 잃었다.
그리고 반복과 상호작용을 취하는 스크럼이 등장해서는 다른 형태의 애자일 방법론들이 되돌려놓은 IT의 재미를 대부분 없애버렸다...
7. 관계가 프로세스에 우선하고, 관계가 트랜잭션보다 오래 간다
원래 비즈니스는 관계의 집합이다. 관계가 좋으면 모든 부분이 원활하게 움직이지만 관계가 좋지 않으면 아무것도 되지 않는다.
기업이 엄격한 계층으로 구성되고 CIO가 다른 임원들과의 관계를 관리했던 과거에는 그것으로 충분했다. 다른 임원이 CIO를 신뢰하지 않으면 IT는 성공할 수 없었다. 그렇게 단순했다.
그러나 IT 부서의 누군가가 비즈니스 부서의 누군가와 접촉할 때마다 이는 비즈니스/IT 관계에 영향을 미친다. 단순히 CIO와 다른 임원과의 관계가 아니다. 비즈니스의 나머지 사람들이 IT를 신뢰하지 않으면 IT는 성공할 수 없다. IT를 신뢰하면 IT의 모든 부분이 더 쉬워진다(쉬운 것이 아니라 좀 더 쉬워지는 것이다).
8. 통합하라. ‘자동화의 섬’을 서로 연결하면 비즈니스 프로세스의 어리석음을 다수 제거할 수 있다.
인간이 컴퓨터가 생성한 보고서로부터 정보를 데이터 입력 창에 다시 입력하던 시절에 IT는 자신의 가장 중요한 책임 중 하나가 분리된 시스템을 통합해 데이터 동기화를 유지하는 것이라는 것을 알았다. 그래서 IT는 인터페이스를 구축했고, 이들 중 대다수는 모두 맞춤형으로 만든 배치 ETL이었다.
이제는 이런 인터페이스가 너무 많아서 유지하기 힘들 정도가 됐다. 그래서 똑똑한 IT는 서비스 버스와 같은 것에 투자를 한다. 그리고 그 인터페이스도 만들어 낸다. 왜냐하면 다른 요소 위에 뭔가 하나를 만들어내는 것은 빛나는 새 기술로 기존과 똑 같은 혼란을 재창조하는 것일 뿐이기 때문이다.
오늘날 많은 IT가 IT 부서 바깥에서 일어나고 있으며, 대부분 비즈니스 책임자에 의해 SaaS의 형태로 새로운 ‘자동화의 섬’이 만들어진다. 이들은 결국에 직원들이 데이터를 다시 입력하는 것에 지치게 될 것이다. 이에 대해 대비해야 한다.
9. IT는 비즈니스를 지원하기 위해 존재한다
기술을 위한 기술은 당연히 나쁘다. 하지만 IT가 주문서를 처리하는 것으로 자신의 역할을 제한해야 한다는 것은 아니다. 이를 넘어서 기술 리더십을 제공해야만 한다.
어떤 IT 부서라도 기술 리더십 제공에 실패하면, 다시 말해 단지 수용하고 전달하는 것인 아니라 제안하고 논의하는 데 실패하면 기본적으로 실패하고 있는 것이다.
기술 리더십은 또한 스스로 기술을 구매하거나 구축할 준비가 되어 있는 비즈니스 책임자와 사용자를 지원한다는 것을 의미한다. 이제 이른바 ‘그림자 IT(Shadow IT)’가 IT의 범위를 넓여준다는 점에서 좋은 것이라고 인식해야 할 때이다.
물론 위험은 있지만, 모든 가치 있는 일은 위험이 따르기 마련이다. IT는 현업의 모든 사람이 자신들의 기술로 성공할 수 있도록 지원해야만 한다. “여기서 만들어진 것”이 아니라고 배척해서는 안 된다.
10. 모든 것은 비즈니스 변화에 대한 것이다
컴퓨터가 새롭고 빛나는 것일 때, 임원들은 비즈니스 프로세스를 더 빠르고 저렴하게 만들면서 수작업 오류를 없애는 방식으로 모든 곳에 변화를 이끌어내기 위해 컴퓨터에 의지했다.
이런 원칙은 IT가 새로운 것을 하려면 시간이 많이 들고 비싸고 위험한, 상호 연결된 수없이 많은 시스템을 지원하기 전까지 유효했다. 폭포수 방법론에 대한 신뢰 역시 더 이상 도움이 되지 않는다.
IT는 다시 느슨하게 흩어지기 시작했다. 애자일 방법론과 더 나은 통합 툴, 비 IT의 IT 사이에서 IT는 이전 원칙을 따르는 대신 다시 한 번 변화를 주도하기 시작했다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/84270]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 364995 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 354773 | 2020-10-27 |
2200 | ETRI, 상용수준 SDN 컨트롤러 개발…오픈소스로 공개 | 3765 | 2013-10-28 |
2199 | 빅데이터 보안 분석 솔루션이 갖춰야 할 4대 핵심 요소...알고리즘, 시각화, 컨텍스트, 자동화 | 4024 | 2013-10-28 |
2198 | 다음, 개발자 컨퍼런스 '디브온2013' 개최 | 4133 | 2013-10-25 |
2197 | 보안강화된 HTML5, 활용도는 아직 | 3622 | 2013-10-25 |
2196 | SAS 하둡 끌어안고 빅데이터 접근성 높인다 | 3826 | 2013-10-25 |
2195 | 日 개발자용 10인치 '타이젠태블릿' 출시 | 3976 | 2013-10-25 |
2194 | "2017년 클라우드 트래픽, 데이터센터 트래픽의 2/3 차지할 것" 시스코 | 4113 | 2013-10-25 |
2193 | 호튼웍스, 다목적 하둡 배포판 HDP 2.0 만들다 | 4366 | 2013-10-25 |
2192 | 중국의 애플 샤오미, "안드로이드를 떠날 이유도, 가치도 없다" | 4035 | 2013-10-25 |
2191 | 지금도 유효한 10가지 고전적 IT 원칙 | 3803 | 2013-10-25 |
0개 댓글