Offcanvas

������

키사이트, ‘패스웨이브 디자인 2021 소프트웨어’ 출시

키사이트테크놀로지스가 개방형 5G 및 mmWave 소프트웨어 솔루션 ‘패스웨이브 디자인 2021(PathWave Design 2021)’을 출시한다고 발표했다.  회사에 따르면 이 솔루션을 사용해 설계 및 검증 엔지니어는 디바이스, 회로, 시스템 설계에 향상된 성능과 정확도를 더해 칩, 보드 및 시스템 제품 출시를 가속화할 수 있다. 키사이트 패스웨이브 소프트웨어 솔루션사업부의 총괄 관리자인 톰 릴릭은 “4G 및 초기 표준에 대한 현재의 설계 방법론은 설계가 빠르게 시장에 선보일 수 있도록 대략적인 성능 지수를 사용한다”라며, “5G 광대역 변조 구조 때문에 통합 요건이 증가하게 되는 현대 설계에서 이러한 기존 접근 방식은 충분치 않으며, 이전 세대의 설계와 함께 개발된 설계 기술은 5G 표준을 충족하기에 충분하지 않다”라고 말했다.  패스웨이브 5G는 시뮬레이션부터 검증까지 그리고 테스트와 제조를 포함해 모든 설계 단계에서 새로운 기능으로 높은 주파수와 복잡성 문제를 해소한다고 회사 측은 설명했다. 엔지니어들은 무선 주파수/마이크로웨이브(RF/MW) 워크플로에 모범 사례를 적용하여 제품 일정을 상당 부분 단축할 수 있다. 키사이트의 패스웨이브 디자인 2021 소프트웨어 제품군을 통해 SI 업체는 RF 회로와 안테나 및 변조 신호로 시스템 성능을 예측할 수 있으며, 시스템 설계업체는 디지털, RF 및 안테나 시스템 시뮬레이션에서 결합 플랫폼으로 RF 모델링을 수행할 수 있다. 키사이트의 패스웨이브 설계 소프트웨어 제품군에는 ▲패스웨이브 ADS(PathWave Advanced Design System),▲패스웨이브 RFIC 디자인(GoldenGate) ▲패스웨이브 시스템 디자인(SystemVue) ▲패스웨이브 EM 디자인(EMPro) 및 패스웨이브 디바이스 모델링(IC-CAP)이 있다. 이러한 소프트웨어는 무선 주파수/마이크로웨이브(RF/MW) 시뮬레이션과 검증, ESL(Electronic System-Level) 시뮬레이션, 설계 ...

키사이트 설계 검증 엔지니어 시뮬레이션개방형 5G mmWave

2020.08.19

키사이트테크놀로지스가 개방형 5G 및 mmWave 소프트웨어 솔루션 ‘패스웨이브 디자인 2021(PathWave Design 2021)’을 출시한다고 발표했다.  회사에 따르면 이 솔루션을 사용해 설계 및 검증 엔지니어는 디바이스, 회로, 시스템 설계에 향상된 성능과 정확도를 더해 칩, 보드 및 시스템 제품 출시를 가속화할 수 있다. 키사이트 패스웨이브 소프트웨어 솔루션사업부의 총괄 관리자인 톰 릴릭은 “4G 및 초기 표준에 대한 현재의 설계 방법론은 설계가 빠르게 시장에 선보일 수 있도록 대략적인 성능 지수를 사용한다”라며, “5G 광대역 변조 구조 때문에 통합 요건이 증가하게 되는 현대 설계에서 이러한 기존 접근 방식은 충분치 않으며, 이전 세대의 설계와 함께 개발된 설계 기술은 5G 표준을 충족하기에 충분하지 않다”라고 말했다.  패스웨이브 5G는 시뮬레이션부터 검증까지 그리고 테스트와 제조를 포함해 모든 설계 단계에서 새로운 기능으로 높은 주파수와 복잡성 문제를 해소한다고 회사 측은 설명했다. 엔지니어들은 무선 주파수/마이크로웨이브(RF/MW) 워크플로에 모범 사례를 적용하여 제품 일정을 상당 부분 단축할 수 있다. 키사이트의 패스웨이브 디자인 2021 소프트웨어 제품군을 통해 SI 업체는 RF 회로와 안테나 및 변조 신호로 시스템 성능을 예측할 수 있으며, 시스템 설계업체는 디지털, RF 및 안테나 시스템 시뮬레이션에서 결합 플랫폼으로 RF 모델링을 수행할 수 있다. 키사이트의 패스웨이브 설계 소프트웨어 제품군에는 ▲패스웨이브 ADS(PathWave Advanced Design System),▲패스웨이브 RFIC 디자인(GoldenGate) ▲패스웨이브 시스템 디자인(SystemVue) ▲패스웨이브 EM 디자인(EMPro) 및 패스웨이브 디바이스 모델링(IC-CAP)이 있다. 이러한 소프트웨어는 무선 주파수/마이크로웨이브(RF/MW) 시뮬레이션과 검증, ESL(Electronic System-Level) 시뮬레이션, 설계 ...

2020.08.19

블로그 | 서버리스 시스템도 설계가 중요한 이유

어딘가에서는 개발자가 계획이나 설계없이 즉석에서 서버리스 애플리케이션을 구축하기로 한다. 좋지 않은 생각이다. 참 재미있는 일이다. 일단 우리는 애플리케이션 개발에서 일부 핵심 과정을 제거했다. 스토리지나 컴퓨트 같은 자원을 프로비저닝하는 일이 대표적인 예다. 그런데 개발자들은 여기서 얻은 자유를 비논리적이고 아직도 이해하기 힘든 결정에 갖다 바친다.   계획과 설계가 안중에 없을 때도 있다. 서버리스 컴퓨팅이 셀프 프로비저닝 방식이고, 애플리케이션은 즉석에서 동적으로 설계하고 디자인할 수 있기 때문이다. 인프라 계획을 세우지 않아도 된다면, 안될 것도 없는 일이다. 하지만 다시 생각해야 봐야 할 세 가지가 있다. 우선, 우리는 여전히 애플리케이션의 효율성에 중점을 두어야 한다. 서버리스라도 마찬가지다. 자원은 서버리스 애플리케이션의 프로파일을 기반으로 자동으로 할당되거나 서버리스 시스템이 필요하다고 생각하는 대로 할당된다. 만약 애플리케이션의 자원 요청이 언제 어떻게 이루어질지를 엉망진창으로 설계한다면, 서버리스 시스템은 자원을 과잉 할당할 가능성이 크고, 결국 비용은 커지고 효율은 나빠질 것이다. 애플리케이션의 상태에 반응하는 시스템은 설계 패턴을 기반으로 가정을 세워야 한다. 4세대 언어의 세상과 마찬가지로개발 플랫폼의 강력함은 개발자가 너무나 쉽게 자기 발등을 찍을 수 있다는 것을 의미한다. 서버리스도 마찬가지다. 둘째, 애플리케이션은 관리가 필요하기 때문에 여전히 관리 지점을 구축해야 한다. 이는 애플리케이션 안으로 향하는 API를 설계해야 하고, 모니터링을 위한 외부 관리 툴로의 데이터도 설계해야 한다는 의미이다. 이런 인터페이스 없이도 애플리케이션을 관리할 수는 있겠지만, 장기적으로 잘 관리하기는 어렵다. 이를 위해서는 서버리스 시스템과 클라우드옵스의 프로세스 및 툴셋을 함께 동작하도록 할 설계와 접근법이 필요하다. 셋째, 설계 단계부터 보안이 필요하다. 설계와 계획이 없는 애플리케이션은 덜 안전한 애플리케이션이 된다. 기초...

설계 프로비저닝 서버리스

2019.10.24

어딘가에서는 개발자가 계획이나 설계없이 즉석에서 서버리스 애플리케이션을 구축하기로 한다. 좋지 않은 생각이다. 참 재미있는 일이다. 일단 우리는 애플리케이션 개발에서 일부 핵심 과정을 제거했다. 스토리지나 컴퓨트 같은 자원을 프로비저닝하는 일이 대표적인 예다. 그런데 개발자들은 여기서 얻은 자유를 비논리적이고 아직도 이해하기 힘든 결정에 갖다 바친다.   계획과 설계가 안중에 없을 때도 있다. 서버리스 컴퓨팅이 셀프 프로비저닝 방식이고, 애플리케이션은 즉석에서 동적으로 설계하고 디자인할 수 있기 때문이다. 인프라 계획을 세우지 않아도 된다면, 안될 것도 없는 일이다. 하지만 다시 생각해야 봐야 할 세 가지가 있다. 우선, 우리는 여전히 애플리케이션의 효율성에 중점을 두어야 한다. 서버리스라도 마찬가지다. 자원은 서버리스 애플리케이션의 프로파일을 기반으로 자동으로 할당되거나 서버리스 시스템이 필요하다고 생각하는 대로 할당된다. 만약 애플리케이션의 자원 요청이 언제 어떻게 이루어질지를 엉망진창으로 설계한다면, 서버리스 시스템은 자원을 과잉 할당할 가능성이 크고, 결국 비용은 커지고 효율은 나빠질 것이다. 애플리케이션의 상태에 반응하는 시스템은 설계 패턴을 기반으로 가정을 세워야 한다. 4세대 언어의 세상과 마찬가지로개발 플랫폼의 강력함은 개발자가 너무나 쉽게 자기 발등을 찍을 수 있다는 것을 의미한다. 서버리스도 마찬가지다. 둘째, 애플리케이션은 관리가 필요하기 때문에 여전히 관리 지점을 구축해야 한다. 이는 애플리케이션 안으로 향하는 API를 설계해야 하고, 모니터링을 위한 외부 관리 툴로의 데이터도 설계해야 한다는 의미이다. 이런 인터페이스 없이도 애플리케이션을 관리할 수는 있겠지만, 장기적으로 잘 관리하기는 어렵다. 이를 위해서는 서버리스 시스템과 클라우드옵스의 프로세스 및 툴셋을 함께 동작하도록 할 설계와 접근법이 필요하다. 셋째, 설계 단계부터 보안이 필요하다. 설계와 계획이 없는 애플리케이션은 덜 안전한 애플리케이션이 된다. 기초...

2019.10.24

"인터넷 혁명 놓쳤지만, 디지털 변혁은 신속하게" 美 건설사 CIO 이야기

새로운 기술이 건설산업에 혁명을 가져오고 있다. 건설회사인 스트럭처 톤은 경영진이 이 새로운 기술로 디지털 혁신 계획을 신속하게 추진할 수 있도록 CIO가 나섰다. 스트럭처 톤의 CIO 테리 로빈스는 6단계 전략을 세워 경영진의 디지털 혁신을 돕고 있다.   미국, 캐나다, 영국, 아일랜드에서 활동하는 건설회사인 스트럭처 톤(Structure Tone)은 40년 동안 가족이 소유한 회사였다. 그러나 2016년 가족은 직원과 외부 투자자 컨소시엄으로 소유권을 이전했다. 그 후 회사는 3개 회사를 합병하였다. 2019년 초 이 회사는 40억 달러에서 60억 달러로 성장했고, 사명을 STO 빌딩 그룹(STO Building Group)으로 변경하였다. 새롭게 구성된 이사회와 경영진은 합병을 완수하고, 더 크고 더 다각적인 회사가 되기 위한 3년 전략을 수립해야 했다.  이사회는 몇 가지 고민이 있었다. 그것은 바로 ‘협업, 데이터, 보안에 대한 고객의 요구가 한층 정교해지고 있는데 어떻게 이에 대응할 것인가’와 ‘고객 앞에서 우리가 혁신적이고 개방적임을 어떻게 증명할 것인가’였다.    STO 빌딩 그룹 CIO인 테리 로빈스는 “기술이 차별화를 이끌어낼 것이고, 고객이 매일 일하는 방식을 반영해 협력적으로 일해야 한다는 것이 분명해졌다”라고 말했다. STO의 고객은 금융 서비스, 교육, 의료, 미션-크리티컬 서비스 사업자 등 다양한 업종에 있으며 이들은 여러 해에 걸쳐 제휴 업체와 무결하게 협력하는 능력에서 혁신을 이루었다. 이제 이들은 정교하고 무결한 협업 능력을 건설 관리 협력사에도 주문하고 있다.  건설 업종, 디지털 혁명에 참여 STO에게 있어 기술 혁신의 목적은 진화에 머무는 것이 아니라 파격적인 혁명을 불러일으키는 것이다. 설계, 엔지니어링, 건설(Architecture, Engineering, and Construction, AEC) 업종은 신기술 도입에서 전반적으로 느린 편이었기 때문이다. ...

협업 벤처캐피탈 엔지니어링 드론 사물인터넷 디지털 변혁 3D 모델링 AEC 메타프롭 오토데스크 건설 혁신 CIO M&A 마이크로소프트 가상현실 이사회 CAD 설계 전문가 패널

2019.08.12

새로운 기술이 건설산업에 혁명을 가져오고 있다. 건설회사인 스트럭처 톤은 경영진이 이 새로운 기술로 디지털 혁신 계획을 신속하게 추진할 수 있도록 CIO가 나섰다. 스트럭처 톤의 CIO 테리 로빈스는 6단계 전략을 세워 경영진의 디지털 혁신을 돕고 있다.   미국, 캐나다, 영국, 아일랜드에서 활동하는 건설회사인 스트럭처 톤(Structure Tone)은 40년 동안 가족이 소유한 회사였다. 그러나 2016년 가족은 직원과 외부 투자자 컨소시엄으로 소유권을 이전했다. 그 후 회사는 3개 회사를 합병하였다. 2019년 초 이 회사는 40억 달러에서 60억 달러로 성장했고, 사명을 STO 빌딩 그룹(STO Building Group)으로 변경하였다. 새롭게 구성된 이사회와 경영진은 합병을 완수하고, 더 크고 더 다각적인 회사가 되기 위한 3년 전략을 수립해야 했다.  이사회는 몇 가지 고민이 있었다. 그것은 바로 ‘협업, 데이터, 보안에 대한 고객의 요구가 한층 정교해지고 있는데 어떻게 이에 대응할 것인가’와 ‘고객 앞에서 우리가 혁신적이고 개방적임을 어떻게 증명할 것인가’였다.    STO 빌딩 그룹 CIO인 테리 로빈스는 “기술이 차별화를 이끌어낼 것이고, 고객이 매일 일하는 방식을 반영해 협력적으로 일해야 한다는 것이 분명해졌다”라고 말했다. STO의 고객은 금융 서비스, 교육, 의료, 미션-크리티컬 서비스 사업자 등 다양한 업종에 있으며 이들은 여러 해에 걸쳐 제휴 업체와 무결하게 협력하는 능력에서 혁신을 이루었다. 이제 이들은 정교하고 무결한 협업 능력을 건설 관리 협력사에도 주문하고 있다.  건설 업종, 디지털 혁명에 참여 STO에게 있어 기술 혁신의 목적은 진화에 머무는 것이 아니라 파격적인 혁명을 불러일으키는 것이다. 설계, 엔지니어링, 건설(Architecture, Engineering, and Construction, AEC) 업종은 신기술 도입에서 전반적으로 느린 편이었기 때문이다. ...

2019.08.12

AR과 VR, 협업을 바꿀 새로운 변수

교육부터 빠른 프로토타이핑, 마케팅 자료 강화에 이르기까지 기업용 증강 현실과 가상 현실 툴을 위한 다양한 애플리케이션이 나오고 있다. 엔터테인먼트, 게임, 소매 전시 등을 위한 기술로서 소비자 시장의 관심도 크다. 전체 AR 및 VR 헤드셋 시장이 2018년 890만 대에서 2022년까지 6,590만 대 규모로 증가할 것이라는 IDC의 예측도 놀랍지 않다. IDC의 디바이스 및 AR/VR 담당 부사장 톰 메이넬리는 “최근 미국 IT 의사 결정자를 대상으로 한 IDC 설문에 따르면 상당수 기업이 두 기술을 모두 테스트하고 있으며, 앞으로 관심이 더욱 증폭될 것으로 예상한다”고 말했다. 기업의 흥미를 돋우는 대표적인 사용 사례는 협업과 커뮤니케이션이다. VR은 화상 통화에서 한 걸음 더 나아가 참가자들이 공유 사무실이나 유명 여행지 등 가상의 공간에 모일 수 있게 해준다. AR은 실제 세계와 가상 세계를 혼합해서 각자 다른 나라에 있는 팀원, 또는 같은 시설의 다른 건물에 있는 팀원들이 똑 같은 장비를 보고 그 위에 주석을 달거나 그림을 그리며 서로의 지식을 공유할 수 있는 수단을 제공한다.   협업 설계를 위한 공유 공간 건물 설계 시 진행되는 작업 중 하나는 기계, 전기, 배관(MEP) 시스템이 상호, 또는 건물 자체의 골격이나 구조와 충돌하지 않는지 확인하는 것이다. 설계 및 디자인 회사 퍼킨스+윌(Perkins+Will)은 몇 개월 전까지만 해도 각 부문의 팀이 만든 축소판 3D 시스템 모델을 가지고 와서 하나의 “연합” 모델로 결합하는 방법을 사용했다. 그러면 각 팀이 네메첵 솔리브리(Nemetschek Solibri) 또는 오토데스크(Autodesk)의 나비스웍스(Navisworks)와 같은 표준 건물 정보 모델링 툴을 사용해서 결합된 모델을 점검했다. 퍼킨스+윌 런던 사무실의 디자인 애플리케이션 관리자인 데이비드 시웰은 “이러한 툴을 살펴보면서 문제 위치를 찾기는 간단한 일이 아...

의료 가상현실 증강현실 설계 제조

2019.01.08

교육부터 빠른 프로토타이핑, 마케팅 자료 강화에 이르기까지 기업용 증강 현실과 가상 현실 툴을 위한 다양한 애플리케이션이 나오고 있다. 엔터테인먼트, 게임, 소매 전시 등을 위한 기술로서 소비자 시장의 관심도 크다. 전체 AR 및 VR 헤드셋 시장이 2018년 890만 대에서 2022년까지 6,590만 대 규모로 증가할 것이라는 IDC의 예측도 놀랍지 않다. IDC의 디바이스 및 AR/VR 담당 부사장 톰 메이넬리는 “최근 미국 IT 의사 결정자를 대상으로 한 IDC 설문에 따르면 상당수 기업이 두 기술을 모두 테스트하고 있으며, 앞으로 관심이 더욱 증폭될 것으로 예상한다”고 말했다. 기업의 흥미를 돋우는 대표적인 사용 사례는 협업과 커뮤니케이션이다. VR은 화상 통화에서 한 걸음 더 나아가 참가자들이 공유 사무실이나 유명 여행지 등 가상의 공간에 모일 수 있게 해준다. AR은 실제 세계와 가상 세계를 혼합해서 각자 다른 나라에 있는 팀원, 또는 같은 시설의 다른 건물에 있는 팀원들이 똑 같은 장비를 보고 그 위에 주석을 달거나 그림을 그리며 서로의 지식을 공유할 수 있는 수단을 제공한다.   협업 설계를 위한 공유 공간 건물 설계 시 진행되는 작업 중 하나는 기계, 전기, 배관(MEP) 시스템이 상호, 또는 건물 자체의 골격이나 구조와 충돌하지 않는지 확인하는 것이다. 설계 및 디자인 회사 퍼킨스+윌(Perkins+Will)은 몇 개월 전까지만 해도 각 부문의 팀이 만든 축소판 3D 시스템 모델을 가지고 와서 하나의 “연합” 모델로 결합하는 방법을 사용했다. 그러면 각 팀이 네메첵 솔리브리(Nemetschek Solibri) 또는 오토데스크(Autodesk)의 나비스웍스(Navisworks)와 같은 표준 건물 정보 모델링 툴을 사용해서 결합된 모델을 점검했다. 퍼킨스+윌 런던 사무실의 디자인 애플리케이션 관리자인 데이비드 시웰은 “이러한 툴을 살펴보면서 문제 위치를 찾기는 간단한 일이 아...

2019.01.08

인텔, AMD 전임 젠 최고 책임자 짐 켈러 영입

인텔이 AMD 젠 아키텍처의 실질적인 책임자였던 짐 켈러를 칩 엔지니어링 책임자로 영입했다. 켈러는 테슬라의 오토파일럿 엔지니어링 최고 책임자로 합류하기 위해 AMD를 떠났는데, AMD 동기인 라자 코두리와 합류해 인텔 아키텍처 그룹의 핵심 칩 설계자로 참여한다. 켈러는 반도체 업계, 특히 PC 마이크로프로세서 분야에서는 유명한 인물로, AMD에서 K7과 K8 아키텍처를 맡아 애슬론 64 칩을 만들었다. 애슬론 64가 AMD의 64비트 시대를 열었을 뿐 아니라 당시는 AMD 역사에서 인텔과 제대로 경쟁한 몇 안되는 기간이기도 했다. AMD 라이젠 칩의 기반인 젠 아키텍처 역시 AMD의 수익과 매출을 되살리고 있다. 인텔은 켈러의 정확한 직책을 밝히지 않았다. 하지만 코두리와 켈러의 조합은 인텔이 제조 역량에 집중하는 대신 칩 설계를 심각하고 재고하고 있다는 증거이다. 켈러의 합류로 당장 인텔 프로세서에 변화가 나타나지는 않을 것이다. 칩 설계가 제품으로 나타나는 데는 최소한 1~2년이 걸리기 때문이다. 실제로 켈러는 AMD에 2012년에 참여했다가 2015년에 떠났다. 하지만 인텔이 자랑하는 무어의 법칙과 틱톡 주기가 흔들리기 시작한 이상, 인텔은 성공을 위한 새로운 전략을 마련해야 할 것이다.  editor@itworld.co.kr

인텔 AMD 설계 영입 짐켈러

2018.04.30

인텔이 AMD 젠 아키텍처의 실질적인 책임자였던 짐 켈러를 칩 엔지니어링 책임자로 영입했다. 켈러는 테슬라의 오토파일럿 엔지니어링 최고 책임자로 합류하기 위해 AMD를 떠났는데, AMD 동기인 라자 코두리와 합류해 인텔 아키텍처 그룹의 핵심 칩 설계자로 참여한다. 켈러는 반도체 업계, 특히 PC 마이크로프로세서 분야에서는 유명한 인물로, AMD에서 K7과 K8 아키텍처를 맡아 애슬론 64 칩을 만들었다. 애슬론 64가 AMD의 64비트 시대를 열었을 뿐 아니라 당시는 AMD 역사에서 인텔과 제대로 경쟁한 몇 안되는 기간이기도 했다. AMD 라이젠 칩의 기반인 젠 아키텍처 역시 AMD의 수익과 매출을 되살리고 있다. 인텔은 켈러의 정확한 직책을 밝히지 않았다. 하지만 코두리와 켈러의 조합은 인텔이 제조 역량에 집중하는 대신 칩 설계를 심각하고 재고하고 있다는 증거이다. 켈러의 합류로 당장 인텔 프로세서에 변화가 나타나지는 않을 것이다. 칩 설계가 제품으로 나타나는 데는 최소한 1~2년이 걸리기 때문이다. 실제로 켈러는 AMD에 2012년에 참여했다가 2015년에 떠났다. 하지만 인텔이 자랑하는 무어의 법칙과 틱톡 주기가 흔들리기 시작한 이상, 인텔은 성공을 위한 새로운 전략을 마련해야 할 것이다.  editor@itworld.co.kr

2018.04.30

설계·개발·테스트에 유용한 14가지 API 관리 툴

소프트웨어 구성 요소가 기능을 수행하거나 데이터를 공유하기 위해 다른 구성 요소에 접근하도록 개발된 API는 지난 10년 동안 기술이 입증됐다. 이후 API는 트윌로(Twilio)와 스트라이프(Stripe) 같은 업체가 단일 핵심 API를 지원해 수십억 달러의 가치를 인정받았으며 매일 사용하는 많은 앱과 서비스의 중추를 형성하도록 하면서 애플리케이션을 설계하고 배포하는 방식을 바꿔놓았다. 여기 인기 있는 상용 소프트웨어의 무료 버전과 무료 오픈소스 대안 등 현재 시장에 나와 있는 유용한 API 관리 툴을 소개한다. 1. AWS API 게이트웨이 클라우드 컴퓨팅의 거물 AWS는 API 게이트웨이 서비스에 무료 티어를 제공한다. 무료 서비스는 월 100만 API 호출의 사용 할당량으로 제한되지만, 이 정도면 쓸 만하다. 풀팻(full-fat) 버전을 사용하면 개발자가 EC2, 람다 또는 다른 웹 애플리케이션과 같이 널리 쓰이는 AWS 서비스에서 실행되는 애플리케이션용 API를 작성할 수 있다. 이 서비스에는 버전 제어, 모니터링, 트래픽 관리 기능이 포함돼 있다. 물론 이것은 AWS 클라우드 인프라에서 애플리케이션을 실행하는 개발자에게 가장 적합하다. 2. IBM API 커넥트 IBM은 상용 API 관리 툴 이외에 무료 티어 옵션도 제공한다. API 커넥트를 사용하면 개발자가 API를 만들고 이를 라이브 코드에 연결할 수 있다. 또한 리포지토리로 사용할 수 있고 정책을 설정하고 소비 분석을 완료할 수 있는 API 관리 콘솔이 있다. 무료 티어는 AWS보다 덜 관대하며 한 달에 API 호출 수가 5만 건이다. 3. 아피지 이 분야에서 가장 큰 성공 사례 중 하나는 아피지(Apigee)다. 아피지 라즈 싱과 라비 찬드라가 2004년에 산타클라라에 설립한 업체로 2016년에 구글이 6억 2,500만 달러에 인수했다. 아피지는 신속한 설계부터 배포까지의 파이프라인은 ...

구글 IBM API 커넥트 Apigee Kong 포스트맨 런스코프 API메트릭스 모커블.io 로더.io 스웨거 델 부미 제이슨스텁 AWS API 게이트웨이 뮬소프트 오라클 IBM AWS 테스트 모니터링 설계 무료 API 상용 아피지 아피아리 JsonStub

2018.02.02

소프트웨어 구성 요소가 기능을 수행하거나 데이터를 공유하기 위해 다른 구성 요소에 접근하도록 개발된 API는 지난 10년 동안 기술이 입증됐다. 이후 API는 트윌로(Twilio)와 스트라이프(Stripe) 같은 업체가 단일 핵심 API를 지원해 수십억 달러의 가치를 인정받았으며 매일 사용하는 많은 앱과 서비스의 중추를 형성하도록 하면서 애플리케이션을 설계하고 배포하는 방식을 바꿔놓았다. 여기 인기 있는 상용 소프트웨어의 무료 버전과 무료 오픈소스 대안 등 현재 시장에 나와 있는 유용한 API 관리 툴을 소개한다. 1. AWS API 게이트웨이 클라우드 컴퓨팅의 거물 AWS는 API 게이트웨이 서비스에 무료 티어를 제공한다. 무료 서비스는 월 100만 API 호출의 사용 할당량으로 제한되지만, 이 정도면 쓸 만하다. 풀팻(full-fat) 버전을 사용하면 개발자가 EC2, 람다 또는 다른 웹 애플리케이션과 같이 널리 쓰이는 AWS 서비스에서 실행되는 애플리케이션용 API를 작성할 수 있다. 이 서비스에는 버전 제어, 모니터링, 트래픽 관리 기능이 포함돼 있다. 물론 이것은 AWS 클라우드 인프라에서 애플리케이션을 실행하는 개발자에게 가장 적합하다. 2. IBM API 커넥트 IBM은 상용 API 관리 툴 이외에 무료 티어 옵션도 제공한다. API 커넥트를 사용하면 개발자가 API를 만들고 이를 라이브 코드에 연결할 수 있다. 또한 리포지토리로 사용할 수 있고 정책을 설정하고 소비 분석을 완료할 수 있는 API 관리 콘솔이 있다. 무료 티어는 AWS보다 덜 관대하며 한 달에 API 호출 수가 5만 건이다. 3. 아피지 이 분야에서 가장 큰 성공 사례 중 하나는 아피지(Apigee)다. 아피지 라즈 싱과 라비 찬드라가 2004년에 산타클라라에 설립한 업체로 2016년에 구글이 6억 2,500만 달러에 인수했다. 아피지는 신속한 설계부터 배포까지의 파이프라인은 ...

2018.02.02

칼럼 | '아키텍처가 위험하다' IT 붕괴를 경고하는 9가지 신호

좋은 IT 아키텍처는 기업의 기술 전략을 활기차게 만든다. 반면 클루지, 수동 리키잉(Re-Keying), 중복된 앱 등은 IT 환경이 붕괴 위기에 있음을 알려주는 신호다. 누군가 무수한 생각 끝에 조직의 IT 아키텍처를 설계한 후 다른 사람에게 이를 구현하도록 넘길 것이다. 그리고 컴퓨팅 환경이 커지면서 다른 누군가가 이를 유지 관리하는 책임을 맡을 것이다. 처음에는 더할 나위 없었던 의도와 계획이 '편의주의', '부서 간 정치', '잘못된 관리' 때문에 퇴색이 될 것이다. 이때쯤되면 한때는 일관됐던 아키텍처 관리 전략이 모호해진다. 결국 각 기술 구성 요소를 분리해 사안 별로 의사 결정을 내리게 된다. 이렇게 조직이 '갈 길을 잃어버리는 것'을 미리 알 수 있는 방법은 없을까? 여기 나쁜 IT 아키텍처가 기업의 발목을 붙잡고 있음을 알려주는 9가지 경고 신호를 소개한다. 수동 리키잉(Re-Keying) 수동 리키잉은 나쁜 아키텍처가 초래하는 가장 큰 대가는 아닐지 모른다. 그러나 가장 확실한 대가인 것은 분명하다. 서로 호환되지 않는 애플리케이션을 연결하는 인터페이스 엔진 역할을 '사람'이 하면 큰 비용이 발생한다. 뿐만 아니라 비인간적이기도 하다. - 아키텍처 영향: 키잉 오류는 일치되지 않는 데이터 문제를 초래한다. - 비즈니스 영향: 수동 리키잉은 가치 창조 활동에 집중해야 할 기업의 소중한 자원을 앗아간다. '포인트' 솔루션 모음 누구나 '동급 최강(best of breed)' 솔루션을 자신의 업무에 사용하고 싶어 한다. 문제는 '자신의 업무'를 너무 좁게 정의하는 것이다. 그 결과, 모든 사람이 여러 애플리케이션을 이용해야 업무를 처리할 수 있고 복잡한 애플리케이션 때문에 업무 처리 시간이 부족해 진다. IT도 힘들기는 마찬가지다. 이 모든 '포인트' 솔루션을 연결할 인터페이스를 구...

프로젝트 아키텍처 설계 경고

2017.08.11

좋은 IT 아키텍처는 기업의 기술 전략을 활기차게 만든다. 반면 클루지, 수동 리키잉(Re-Keying), 중복된 앱 등은 IT 환경이 붕괴 위기에 있음을 알려주는 신호다. 누군가 무수한 생각 끝에 조직의 IT 아키텍처를 설계한 후 다른 사람에게 이를 구현하도록 넘길 것이다. 그리고 컴퓨팅 환경이 커지면서 다른 누군가가 이를 유지 관리하는 책임을 맡을 것이다. 처음에는 더할 나위 없었던 의도와 계획이 '편의주의', '부서 간 정치', '잘못된 관리' 때문에 퇴색이 될 것이다. 이때쯤되면 한때는 일관됐던 아키텍처 관리 전략이 모호해진다. 결국 각 기술 구성 요소를 분리해 사안 별로 의사 결정을 내리게 된다. 이렇게 조직이 '갈 길을 잃어버리는 것'을 미리 알 수 있는 방법은 없을까? 여기 나쁜 IT 아키텍처가 기업의 발목을 붙잡고 있음을 알려주는 9가지 경고 신호를 소개한다. 수동 리키잉(Re-Keying) 수동 리키잉은 나쁜 아키텍처가 초래하는 가장 큰 대가는 아닐지 모른다. 그러나 가장 확실한 대가인 것은 분명하다. 서로 호환되지 않는 애플리케이션을 연결하는 인터페이스 엔진 역할을 '사람'이 하면 큰 비용이 발생한다. 뿐만 아니라 비인간적이기도 하다. - 아키텍처 영향: 키잉 오류는 일치되지 않는 데이터 문제를 초래한다. - 비즈니스 영향: 수동 리키잉은 가치 창조 활동에 집중해야 할 기업의 소중한 자원을 앗아간다. '포인트' 솔루션 모음 누구나 '동급 최강(best of breed)' 솔루션을 자신의 업무에 사용하고 싶어 한다. 문제는 '자신의 업무'를 너무 좁게 정의하는 것이다. 그 결과, 모든 사람이 여러 애플리케이션을 이용해야 업무를 처리할 수 있고 복잡한 애플리케이션 때문에 업무 처리 시간이 부족해 진다. IT도 힘들기는 마찬가지다. 이 모든 '포인트' 솔루션을 연결할 인터페이스를 구...

2017.08.11

'함정에 빠지지 마라' 확장형 시스템의 성능 문제 9가지

복잡한 시스템을 기어 다니게 만드는 방법은 무궁무진하다. 그래서 다음의 9가지 문제를 해결하고 나면, 10번째 문제가 바로 등장하게 될 것이다. 규모가 있는 시스템을 조금이라도 구현해 본 경험이 있다면, 몇 가지 설계 문제가 다른 것들에 비해 훨씬 더 고약하다는 것을 알 것이다. 잘 짜인 코드를 작성하는 것과 시스템에 성능을 저하하는 설계 오류가 끼어들지 못하게 하는 것은 전혀 별개의 일이다. 다음은 시스템을 헛수고하게 만들거나, 등을 돌리게 만드는 9가지 흔한 문제, 실제로는 잘못된 설계 상의 선택이다. 하지만 다른 잘못된 의사결정들과는 달리, 이런 문제들은 되돌릴 수 있다. N+1 쿼리 하나의 쿼리에서 어떤 고객의 모든 주문을 선택(SELECT)한다는 것은 주문에 대한 매 쿼리에서 개개 주문의 라인 항목(Line Item)을 선택하는 과정을 반복한다는 것으로, 이는 데이터베이스에 대한 n+1회의 방문을 의미한다. 외부 조인(Outer Join)을 사용한 단 한 번의 빅쿼리(Big Query)가 더 효율적일 것이다. 한 번에 더 적은 수를 끌어와야 한다면, 페이징의 한 형태를 사용할 수 있다. 자동으로 채워지는 캐시를 사용하는 개발자들은 실수로 n+1 문제를 작성하곤 한다. OEM(Oracle Enterprise Monitor) 같은 데이터베이스 감시 도구나 와일리 인트로스코프 같은 APM 도구를 사용하거나 단순한 쿼리 로그 작성으로 이런 상황을 알아낼 수 있다. CTE를 사용하는 대신에 플랫 테이블(Flat Table)에 저장된 트리를 탐색(Crawl)하려는 사람처럼 이 문제에 대한 더욱 악화된 버전도 있다. NoSQL 데이터베이스에서도 이 문제에 상응하는 버전이 있기 때문에 누구도 안전하지 않다. 페이지 또는 레코드 잠금 필자는 DB2와 SQL 서버를 싫어했다. 지금도 이들의 기본 잠금 모델을 혐오한다. 플랫폼에 따라서, DB2는 업데이트를 위해 한 “페이지” 분의 레코드를 잠그는데, 본의 아니게...

성능 아키텍트 설계 확장 쿼리

2017.08.01

복잡한 시스템을 기어 다니게 만드는 방법은 무궁무진하다. 그래서 다음의 9가지 문제를 해결하고 나면, 10번째 문제가 바로 등장하게 될 것이다. 규모가 있는 시스템을 조금이라도 구현해 본 경험이 있다면, 몇 가지 설계 문제가 다른 것들에 비해 훨씬 더 고약하다는 것을 알 것이다. 잘 짜인 코드를 작성하는 것과 시스템에 성능을 저하하는 설계 오류가 끼어들지 못하게 하는 것은 전혀 별개의 일이다. 다음은 시스템을 헛수고하게 만들거나, 등을 돌리게 만드는 9가지 흔한 문제, 실제로는 잘못된 설계 상의 선택이다. 하지만 다른 잘못된 의사결정들과는 달리, 이런 문제들은 되돌릴 수 있다. N+1 쿼리 하나의 쿼리에서 어떤 고객의 모든 주문을 선택(SELECT)한다는 것은 주문에 대한 매 쿼리에서 개개 주문의 라인 항목(Line Item)을 선택하는 과정을 반복한다는 것으로, 이는 데이터베이스에 대한 n+1회의 방문을 의미한다. 외부 조인(Outer Join)을 사용한 단 한 번의 빅쿼리(Big Query)가 더 효율적일 것이다. 한 번에 더 적은 수를 끌어와야 한다면, 페이징의 한 형태를 사용할 수 있다. 자동으로 채워지는 캐시를 사용하는 개발자들은 실수로 n+1 문제를 작성하곤 한다. OEM(Oracle Enterprise Monitor) 같은 데이터베이스 감시 도구나 와일리 인트로스코프 같은 APM 도구를 사용하거나 단순한 쿼리 로그 작성으로 이런 상황을 알아낼 수 있다. CTE를 사용하는 대신에 플랫 테이블(Flat Table)에 저장된 트리를 탐색(Crawl)하려는 사람처럼 이 문제에 대한 더욱 악화된 버전도 있다. NoSQL 데이터베이스에서도 이 문제에 상응하는 버전이 있기 때문에 누구도 안전하지 않다. 페이지 또는 레코드 잠금 필자는 DB2와 SQL 서버를 싫어했다. 지금도 이들의 기본 잠금 모델을 혐오한다. 플랫폼에 따라서, DB2는 업데이트를 위해 한 “페이지” 분의 레코드를 잠그는데, 본의 아니게...

2017.08.01

블로그 | 클라우드 애플리케이션이 느린 이유는 클라우드 때문이 아니다

아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다. 이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가? 사실은 그렇지 않다. 필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다. 하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자. “엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.” 퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다. 현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다. 이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케...

마이그레이션 설계 리팩터링

2017.07.25

아침 7시. 사무실에 일찍 도착했다. 이렇게 이른 시간에는 아무도 회사가 사용하는 퍼블릭 클라우드에 액세스하지 않을 것이란 생각에서다. 이제 재고 애플리케이션은 수정 작업을 원활하게 수행할 것이란 기대를 가졌다. 하지만 이른 아침, 겨우 몇 명의 사용자가 클라우드에 있는데도, 성능은 여전히 엉망진창이다. 이때 즉각적인 반응은 클라우드 서비스 업체를 욕하는 것이다. 물론 서비스 업체는 애플리케이션과 데이터를 호스팅하기 때문에 어떤 성능 문제에 대한 책임도 져야 한다. 그렇지 않은가? 사실은 그렇지 않다. 필자가 본 성능 문제 중 열에 아홉은 클라우드 인프라에 문제가 있기보다는 애플리케이션 설계나 기술 선택의 문제였다. 이것만 생각하자. 퍼블릭 클라우드에서 용량은 그냥 추가하면 된다. 용량은 필요할 때 필요한 만큼 확장할 수 있다. 하지만 느린 재고 관리 애플리케이션 문제라면, 용량을 추가하는 식으로는 문제를 해결할 수 없다. 이제 필자가 수도 없이 이야기한 규칙을 다시 생각해 보자. “엉성한 온프레미스 애플리케이션을 퍼블릭 클라우드로 이전하면, 엉성한 퍼블릭 클라우드 애플리케이션이 된다.” 퍼블릭 클라우드로 이전하면서 흔히 일어나는 일이다. 애플리케이션을 퍼블릭 클라우드로 보내기 전에 애플리케이션 설계나 데이터베이스나 미드웨어 사용, 또는 다른 기반 기술을 점검하지 않는 것이다. 현실은 이런 애플리케이션이 단지 성능이 엉망인 것에 그치지 않는다. 제대로 설계되지 않은 애플리케이션을 처리하기 위해 퍼블릭 클라우드가 씨름을 하면서 클라우드 요금이 50~60% 더 나오기 십상이다. 일반적으로 비효율적인 I/O, 인터랙션이 너무 많은 애플리케이션, 최적화하지 않은 데이터베이스 쿼리 등이 문제의 원인인 경우가 많으며, 이외에도 잘못될 수 있는 것은 너무나 많다. 이 문제의 해법은 대부분 기업 IT 부서가 듣고 싶지 않은 이야기다. 애플리케이션을 리팩터링하는 것이다. 여기에는 애플리케이션 설계 조정과 애플리케...

2017.07.25

트림블, 홀로렌즈용 스케치업 뷰어 앱 출시··· 건축가 시장 '노크'

건축가가 마이크로소프트 홀로렌즈를 마련해야 할 이유가 하나 더 늘었다. 빌딩 3D 모델을 만들어 확인할 수 있게 해주는 전용 앱이 등장했다. 트림블(Trimble)이 7일 출시한 홀로렌즈 헤드셋용 스케치업 뷰어(SketchUp Viewer for Microsoft HoloLens)를 이용하면, 스케치업으로 생성한 건물 모형을 증강현실 기능성을 통해 확인할 수 있다. 이 앱에는 2가지 모드가 있다. 하나는 모형 축소 버전을 보도록 하는 모드이며, 다른 하나는 모형 내부를 탐색할 수 있게 하는 모드다. 가격은 그리 만만치 않다. 앱 가격이 미화 1,500달러다. 홀로렌즈의 3,000달러 가격표까지 감안해야 한다. 결국은 예전에는 없었던 모델 시각화 방안이 이에 상응하는 가치를 지니냐의 문제다. 이번 스케치업 뷰어 애플리케이션이 홀로렌즈 시장에 미칠 영향은 향후 지켜볼 만한 요소다. 지금까지는 홀로렌즈용 소프트웨어 시장이 경쟁 플랫폼과 비교해 그리 풍부한 상태가 아니다. 만약 트림블의 스케치업 뷰어가 기업 시장에 반향을 일으킨다면 홀로렌즈 기기 뿐 아니라 홀로렌즈 소프트웨어 생태계에도 영향을 불러일으킬 수 있다. 한편 마이크로소프트는 3D 모델링 분야에서 오토데스크와도 협력하고 있다. 회사의 퓨전 360 모델링 소프트웨어와 관련해서다. 홀로렌즈 앱을 묘사한 마이크로소프트 렌더링. Credit: Microsoft ciokr@idg.co.kr 

증강현실 설계 건축 트림블 홀로렌즈 스케치업

2016.11.08

건축가가 마이크로소프트 홀로렌즈를 마련해야 할 이유가 하나 더 늘었다. 빌딩 3D 모델을 만들어 확인할 수 있게 해주는 전용 앱이 등장했다. 트림블(Trimble)이 7일 출시한 홀로렌즈 헤드셋용 스케치업 뷰어(SketchUp Viewer for Microsoft HoloLens)를 이용하면, 스케치업으로 생성한 건물 모형을 증강현실 기능성을 통해 확인할 수 있다. 이 앱에는 2가지 모드가 있다. 하나는 모형 축소 버전을 보도록 하는 모드이며, 다른 하나는 모형 내부를 탐색할 수 있게 하는 모드다. 가격은 그리 만만치 않다. 앱 가격이 미화 1,500달러다. 홀로렌즈의 3,000달러 가격표까지 감안해야 한다. 결국은 예전에는 없었던 모델 시각화 방안이 이에 상응하는 가치를 지니냐의 문제다. 이번 스케치업 뷰어 애플리케이션이 홀로렌즈 시장에 미칠 영향은 향후 지켜볼 만한 요소다. 지금까지는 홀로렌즈용 소프트웨어 시장이 경쟁 플랫폼과 비교해 그리 풍부한 상태가 아니다. 만약 트림블의 스케치업 뷰어가 기업 시장에 반향을 일으킨다면 홀로렌즈 기기 뿐 아니라 홀로렌즈 소프트웨어 생태계에도 영향을 불러일으킬 수 있다. 한편 마이크로소프트는 3D 모델링 분야에서 오토데스크와도 협력하고 있다. 회사의 퓨전 360 모델링 소프트웨어와 관련해서다. 홀로렌즈 앱을 묘사한 마이크로소프트 렌더링. Credit: Microsoft ciokr@idg.co.kr 

2016.11.08

기고 | ‘클라우드 설계 협업’ 문서화 방법은?

클라우드 시스템을 개발하고 통합하는 데 있어 공용 인터페이스(public interfaces)와 해당 서비스를 이용하는 '외부 개발자들(external "contracts")'과의 협업은, 설계와 아키텍처를 빠르게 그리고 동시에 진척시킬 수 있음을 시사한다. 하지만 이 경우 특히 개발자들이 서로 다른 공간에서 파일을 동시에 관리함에 따라, 갑작스런 변화로 인한 업무적 혼란을 초래할 수도 있다. 예를 들어 (서비스 제공자와 서비스 소비자라는) 두 팀이 인터페이스를 마주보고 작업한다면, 변수와 방법을 일치시키기가 힘들어진다. 물론 서비스를 제공하는 당사자가 문서를 업데이트 한 후, 상대 팀에게 새 필드 값이나 서비스 행동의 새로운 의미에 대해 통보할 수는 있다. 그러나 현실적으로 바로 바로 실천에 옮겨지는 경우는 드물다. 이 경우 변경된 문서 버전을 팀별로 분산해 관리하면서, 최종본이 무엇인지를 두고 비롯되는 통상적인 문제들이 대두된다. 클라우드 설계와 아키텍처 협업과 관련해 몇 가지 현실부터 살펴보자. 1. 해당 팀들은 규칙과 프로세스에 우선해 속도와 현명함에 가치를 부여한다. 2. 반복 개발을 강조하는 애자일(Agile) 프로세스를 사용하고, 지속적으로 통합하고 테스트한다. 3. 방법론에 무게를 두지 않고, 높은 수준의 실용성을 추구한다. 특히 ULM, 기타 특정 모델링이나 인터페이스 정의 툴을 고집하지 않는다. 4. 중앙에서 관리되지 않는 여러 조직에 팀들이 산개해 있기 쉽다. 5. 팀원들이 서로 떨어져 위치해 있다. 그렇다면 이것들이 시사하는 바는 뭘까? 일반적으로, 설계 협력에 있어 공통 분모로 사용되는 툴이 없을 확률이 높다는 것이다. (그렇다. 애자일 툴들이 있다. 그러나 기껏해야 고르지 않게 사용되고 있을 뿐이다.) 따라서 마이크로소프트 워드, 액셀, 비지오, 파워포인트가 출발점이 되기 쉽다. 불행히도, 이들 툴 대부분은 변경 관리 기능이 미흡하다. 만약 많은 사람...

클라우드 협업 문서화 설계 변경 관리

2012.02.01

클라우드 시스템을 개발하고 통합하는 데 있어 공용 인터페이스(public interfaces)와 해당 서비스를 이용하는 '외부 개발자들(external "contracts")'과의 협업은, 설계와 아키텍처를 빠르게 그리고 동시에 진척시킬 수 있음을 시사한다. 하지만 이 경우 특히 개발자들이 서로 다른 공간에서 파일을 동시에 관리함에 따라, 갑작스런 변화로 인한 업무적 혼란을 초래할 수도 있다. 예를 들어 (서비스 제공자와 서비스 소비자라는) 두 팀이 인터페이스를 마주보고 작업한다면, 변수와 방법을 일치시키기가 힘들어진다. 물론 서비스를 제공하는 당사자가 문서를 업데이트 한 후, 상대 팀에게 새 필드 값이나 서비스 행동의 새로운 의미에 대해 통보할 수는 있다. 그러나 현실적으로 바로 바로 실천에 옮겨지는 경우는 드물다. 이 경우 변경된 문서 버전을 팀별로 분산해 관리하면서, 최종본이 무엇인지를 두고 비롯되는 통상적인 문제들이 대두된다. 클라우드 설계와 아키텍처 협업과 관련해 몇 가지 현실부터 살펴보자. 1. 해당 팀들은 규칙과 프로세스에 우선해 속도와 현명함에 가치를 부여한다. 2. 반복 개발을 강조하는 애자일(Agile) 프로세스를 사용하고, 지속적으로 통합하고 테스트한다. 3. 방법론에 무게를 두지 않고, 높은 수준의 실용성을 추구한다. 특히 ULM, 기타 특정 모델링이나 인터페이스 정의 툴을 고집하지 않는다. 4. 중앙에서 관리되지 않는 여러 조직에 팀들이 산개해 있기 쉽다. 5. 팀원들이 서로 떨어져 위치해 있다. 그렇다면 이것들이 시사하는 바는 뭘까? 일반적으로, 설계 협력에 있어 공통 분모로 사용되는 툴이 없을 확률이 높다는 것이다. (그렇다. 애자일 툴들이 있다. 그러나 기껏해야 고르지 않게 사용되고 있을 뿐이다.) 따라서 마이크로소프트 워드, 액셀, 비지오, 파워포인트가 출발점이 되기 쉽다. 불행히도, 이들 툴 대부분은 변경 관리 기능이 미흡하다. 만약 많은 사람...

2012.02.01

기고 | 클라우드컴퓨팅, 데이터센터 설계와 비용을 바꾸다

클라우드 컴퓨팅이 엄청난 규모와 효율에 가져다 줄 것이라는 주장은 독자 여러분들이 이미 많이 들었을 것이다. 이러한 주장은 데이터센터 전체 비용과 설계 구조가 바뀌고 있다는 것을 의미한다.   이 블로그를 오래 읽어온 사람들이라면, 클라우드 컴퓨팅으로 IT비용을 파격적으로 줄일 수 있다는 필자의 확신에 찬 주장에 대해 잘 알고 있을 것이다. 많은 사람들이 자원 풀링과 빠른 탄력성을 통해 활용도를 개선함으로써 비롯되는 클라우드 컴퓨팅의 비용 우위에 대해 이야기하고 있다. 하지만 데이터센터들이 규모와 효율성에 초점을 두고 상품 요소로 이동하는 방향으로 재설계 되면서 한층 기본적인 변화가 일어날 전망이다. 다른 말로 설명하면, 기존의 비용 우위(활용도 등)는 기존 데이터센터 설계 패턴을 보다 효율적으로 사용하는데 의존하고 있다. 반면 후자는 새 설계 패턴을 만듦으로써 데이터센터의 비용 요소를 바꾸는데 중점을 두고 있다. 필자는 몇 개월 전 ‘데이터센터 다이내믹스 참관기 : 클라우드 친화형 데이터센터 부상’이라는 제목으로 이 주제와 관련된 포스트를 올린 적이 있다. 그리고 지난 몇 주 동안 데이터센터가 대규모 컴퓨팅 환경으로 빠르게 발전하고 있다는 관점을 강화하는 몇몇 발전이 있었다. 지난 10년 동안 데이터센터 설계는 표준 컴포넌트를 한데 묶는 방식으로 표준화됐었다. 가장 최적화된 효율성을 가질 수 있도록 각 컴포넌트를 설계했다. 그렇게 하면 전체적으로 최적화된 효율성을 달성할 수 있을 것으로 기대했기 때문이다. 그러나 이런 관점이 바뀌고 있다. 전체 데이터센터를 최대한의 효율성 수준으로 운용되도록 설계된 통합 요소들로 바라보며, 이를 위해서는 맞춤형으로 설계된 하위 컴포넌트를 이용해 전반적인 효율성 목표를 달성할 수 있어야 한다는 관점이다. 필자는 앞서 포스트에서 이 관점을 규정지었다. 치킨 쿠프(닭장) 데이터센터는 긴 사각형 모양으로 가장 긴 면이 바람이 부는 방향으로 되어 있어...

데이터센터 클라우드 컴퓨팅 비용 설계

2011.09.21

클라우드 컴퓨팅이 엄청난 규모와 효율에 가져다 줄 것이라는 주장은 독자 여러분들이 이미 많이 들었을 것이다. 이러한 주장은 데이터센터 전체 비용과 설계 구조가 바뀌고 있다는 것을 의미한다.   이 블로그를 오래 읽어온 사람들이라면, 클라우드 컴퓨팅으로 IT비용을 파격적으로 줄일 수 있다는 필자의 확신에 찬 주장에 대해 잘 알고 있을 것이다. 많은 사람들이 자원 풀링과 빠른 탄력성을 통해 활용도를 개선함으로써 비롯되는 클라우드 컴퓨팅의 비용 우위에 대해 이야기하고 있다. 하지만 데이터센터들이 규모와 효율성에 초점을 두고 상품 요소로 이동하는 방향으로 재설계 되면서 한층 기본적인 변화가 일어날 전망이다. 다른 말로 설명하면, 기존의 비용 우위(활용도 등)는 기존 데이터센터 설계 패턴을 보다 효율적으로 사용하는데 의존하고 있다. 반면 후자는 새 설계 패턴을 만듦으로써 데이터센터의 비용 요소를 바꾸는데 중점을 두고 있다. 필자는 몇 개월 전 ‘데이터센터 다이내믹스 참관기 : 클라우드 친화형 데이터센터 부상’이라는 제목으로 이 주제와 관련된 포스트를 올린 적이 있다. 그리고 지난 몇 주 동안 데이터센터가 대규모 컴퓨팅 환경으로 빠르게 발전하고 있다는 관점을 강화하는 몇몇 발전이 있었다. 지난 10년 동안 데이터센터 설계는 표준 컴포넌트를 한데 묶는 방식으로 표준화됐었다. 가장 최적화된 효율성을 가질 수 있도록 각 컴포넌트를 설계했다. 그렇게 하면 전체적으로 최적화된 효율성을 달성할 수 있을 것으로 기대했기 때문이다. 그러나 이런 관점이 바뀌고 있다. 전체 데이터센터를 최대한의 효율성 수준으로 운용되도록 설계된 통합 요소들로 바라보며, 이를 위해서는 맞춤형으로 설계된 하위 컴포넌트를 이용해 전반적인 효율성 목표를 달성할 수 있어야 한다는 관점이다. 필자는 앞서 포스트에서 이 관점을 규정지었다. 치킨 쿠프(닭장) 데이터센터는 긴 사각형 모양으로 가장 긴 면이 바람이 부는 방향으로 되어 있어...

2011.09.21

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31