Offcanvas

������������

블로그 | 새로운 최적화 렌즈로 보는 클라우드 아키텍처

이제 클라우드 컴퓨팅 아키텍처의 성공을 정의하는 방법도 한층 성숙해져야 한다. 클라우드 아키텍처에는 걸려있는 것이 너무 많다. 제대로 최적화되지 않고 비용이 많이 드는 클라우드 아키텍처는 동작하기는 하겠지만, 기업은 매주 수백만 달러의 손해를 볼 수도 있다. 12가지 기술이면 더 잘 동작할 수 있는데, 30가지 기술이 사용되고, 변화를 염두에 두지 않은 설계로 비즈니스 민첩성이 손상된다.    클라우드 아키텍처가 좀처럼 최적화되지 않는 이유는 무엇일까? 클라우드 아키텍트가 계획과 설계 단계에서 클라우드 아키텍처 교육 과정에서 배운 대로 하거나 다수의 레퍼런스에서 읽은 것을 적용한다. 이전 클라우드 아키텍처 프로젝트나 선임자에게 배운 팁을 적용하기도 한다. 이 모든 가이드는 아키텍트를 일련의 범용적인 레퍼런스 모델과 프로세스, 기술 스택 등으로 이끄는데, 이들은 모두 기업의 특정 비즈니스 요구사항을 해결할 수 있도록 수정해야만 한다. 이런 접근법이 필요 이상의 비용을 지출하도록 하는 최적화되지 않은 아키텍처를 낳는 것이다. 왜 이렇게 된 것일까? 이 질문에 답하기 위해 우리 자신을 되돌아볼 필요가 있다. 최적화된 클라우드 아키텍처는 실제로 어떤 의미일까? 필자는 ‘IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기’란 글을 통해 클라우드 아키텍처 최적화 프로세스를 정의한 바 있다. 그리고 이용하기 좋은 높은 수준의 모델도 제시했다. 필자의 클라우드 아키텍처 교육 과정도 이런 개념을 포함하도록 보강했다.  다음으로는 과거에는 모든 요소가 함께 동작하는 데 중점을 두었다는 것을 알아야 한다. 당시에는 얼마나 잘 동작하고 솔루션이 얼마나 복잡해지는가에는 큰 비중을 두지 않았다. 성공의 척도는 “동작하는가?”였지 “얼마나 잘 동작하는가?”는 아니었다. 개발 과정에서 클라우드팀은 클라우드 아키텍처와 마이그레이션, 새로운 개발에 대한 접근법에 온전히 집중했다. 메타 클라우드 아키텍처 같은 넓은 관점과 마이크로 클라우드 아키텍처 같은...

클라우드 아키텍처 최적화

2022.01.18

이제 클라우드 컴퓨팅 아키텍처의 성공을 정의하는 방법도 한층 성숙해져야 한다. 클라우드 아키텍처에는 걸려있는 것이 너무 많다. 제대로 최적화되지 않고 비용이 많이 드는 클라우드 아키텍처는 동작하기는 하겠지만, 기업은 매주 수백만 달러의 손해를 볼 수도 있다. 12가지 기술이면 더 잘 동작할 수 있는데, 30가지 기술이 사용되고, 변화를 염두에 두지 않은 설계로 비즈니스 민첩성이 손상된다.    클라우드 아키텍처가 좀처럼 최적화되지 않는 이유는 무엇일까? 클라우드 아키텍트가 계획과 설계 단계에서 클라우드 아키텍처 교육 과정에서 배운 대로 하거나 다수의 레퍼런스에서 읽은 것을 적용한다. 이전 클라우드 아키텍처 프로젝트나 선임자에게 배운 팁을 적용하기도 한다. 이 모든 가이드는 아키텍트를 일련의 범용적인 레퍼런스 모델과 프로세스, 기술 스택 등으로 이끄는데, 이들은 모두 기업의 특정 비즈니스 요구사항을 해결할 수 있도록 수정해야만 한다. 이런 접근법이 필요 이상의 비용을 지출하도록 하는 최적화되지 않은 아키텍처를 낳는 것이다. 왜 이렇게 된 것일까? 이 질문에 답하기 위해 우리 자신을 되돌아볼 필요가 있다. 최적화된 클라우드 아키텍처는 실제로 어떤 의미일까? 필자는 ‘IDG 블로그 | 클라우드 아키텍처 최적화 쉽게 이해하기’란 글을 통해 클라우드 아키텍처 최적화 프로세스를 정의한 바 있다. 그리고 이용하기 좋은 높은 수준의 모델도 제시했다. 필자의 클라우드 아키텍처 교육 과정도 이런 개념을 포함하도록 보강했다.  다음으로는 과거에는 모든 요소가 함께 동작하는 데 중점을 두었다는 것을 알아야 한다. 당시에는 얼마나 잘 동작하고 솔루션이 얼마나 복잡해지는가에는 큰 비중을 두지 않았다. 성공의 척도는 “동작하는가?”였지 “얼마나 잘 동작하는가?”는 아니었다. 개발 과정에서 클라우드팀은 클라우드 아키텍처와 마이그레이션, 새로운 개발에 대한 접근법에 온전히 집중했다. 메타 클라우드 아키텍처 같은 넓은 관점과 마이크로 클라우드 아키텍처 같은...

2022.01.18

일문일답 | "소유에의 자부심을 버려라"··· 에어 프로덕츠 CIO가 말하는 IT-비즈니스 관계

콜린스 에어로스페이스에서 디지털 부사장 겸 CIO를 역임한 브라이언 갈로비치는, 작년 12월 수석 부사장(SVP) 겸 CIO로서 에어 프로덕츠에 합류했다. CIO닷컴은 최근에 갈로비치를 만나 에어 프로덕츠에서 진행 중인 비즈니스 변혁, IT 조직이 변혁을 주도하기 위해 변화하는 방법, 그 과정에서 그가 배운 교훈 등에 대해 알아봤다. 다음은 그 대화의 편집본이다.  Q. 에어 프로덕츠에서 진행 중인 변혁은 어떤 것인가? A. 세이피 가세미가 7년 전 에어 프로덕츠 이사장 겸 사장 겸 CEO가 되었을 때 그는 화학 사업을 정리하고 산업용 가스라는 핵심 사업에 주력하기 시작했다. 이러한 핵심 사업의 강점에 기반하여 우리는 보다 깨끗하고 지속 가능한 에너지 및 환경 솔루션을 생산하도록 설계된 대규모 가스화, 탄소 포집 및 수소 분야의 여러 프로젝트를 구축하고 운영하고 있다. 우리는 이러한 이니셔티브를 ‘메가 프로젝트’라고 부른다. 지난 몇 년 동안 에어 프로덕츠 역사상 가장 크고 복잡한 규모로 진행되기 때문이다. 과거에 우리의 초점은 더 작고 더욱 표준화된 플랜트를 생산하는 것이었는데, 이는 우리가 생산에 대해서 더 예측 가능하고 일관된 접근방식을 취할 수 있는 비즈니스였다. 그러나 (예컨대, 버스, 트럭 및 중장비용) 운송 시장을 지원하기 위한 청정 수소 및 탈탄소라는 이들 각각의 메가 프로젝트는 서로 다르거니와 규모로 훨씬 크다. 그렇기 때문에 그러한 복잡성을 지원할 수 있는 확장 가능한 엔드 투 엔드 엔지니어링, 조달 및 건설 프로세스를 갖추는 것이 매우 중요하다. 이러한 변혁을 추동 하는데 IT가 어떻게 도움이 되는가? 많은 회사와 마찬가지로 에어 프로덕츠도 비즈니스 전반에 걸쳐 각종 포인트 솔루션을 배치했었다. 이로 인해 IT가 먼저 해야 할 일은 엔드 투 엔드 프로세스를 가능하게 만들기 위해 가치 흐름을 총체적으로 살펴보는 것이었다.  현재 고객에게 솔루션을 제공하기 위해서는 초기 입찰 과정부터 조달을 거쳐 구성 및 운영에...

IT 관리 QMFKDLDJS RKFFHQLCL 에어 프로덕츠 현업 정렬 이네이블러 아키텍처

2021.11.29

콜린스 에어로스페이스에서 디지털 부사장 겸 CIO를 역임한 브라이언 갈로비치는, 작년 12월 수석 부사장(SVP) 겸 CIO로서 에어 프로덕츠에 합류했다. CIO닷컴은 최근에 갈로비치를 만나 에어 프로덕츠에서 진행 중인 비즈니스 변혁, IT 조직이 변혁을 주도하기 위해 변화하는 방법, 그 과정에서 그가 배운 교훈 등에 대해 알아봤다. 다음은 그 대화의 편집본이다.  Q. 에어 프로덕츠에서 진행 중인 변혁은 어떤 것인가? A. 세이피 가세미가 7년 전 에어 프로덕츠 이사장 겸 사장 겸 CEO가 되었을 때 그는 화학 사업을 정리하고 산업용 가스라는 핵심 사업에 주력하기 시작했다. 이러한 핵심 사업의 강점에 기반하여 우리는 보다 깨끗하고 지속 가능한 에너지 및 환경 솔루션을 생산하도록 설계된 대규모 가스화, 탄소 포집 및 수소 분야의 여러 프로젝트를 구축하고 운영하고 있다. 우리는 이러한 이니셔티브를 ‘메가 프로젝트’라고 부른다. 지난 몇 년 동안 에어 프로덕츠 역사상 가장 크고 복잡한 규모로 진행되기 때문이다. 과거에 우리의 초점은 더 작고 더욱 표준화된 플랜트를 생산하는 것이었는데, 이는 우리가 생산에 대해서 더 예측 가능하고 일관된 접근방식을 취할 수 있는 비즈니스였다. 그러나 (예컨대, 버스, 트럭 및 중장비용) 운송 시장을 지원하기 위한 청정 수소 및 탈탄소라는 이들 각각의 메가 프로젝트는 서로 다르거니와 규모로 훨씬 크다. 그렇기 때문에 그러한 복잡성을 지원할 수 있는 확장 가능한 엔드 투 엔드 엔지니어링, 조달 및 건설 프로세스를 갖추는 것이 매우 중요하다. 이러한 변혁을 추동 하는데 IT가 어떻게 도움이 되는가? 많은 회사와 마찬가지로 에어 프로덕츠도 비즈니스 전반에 걸쳐 각종 포인트 솔루션을 배치했었다. 이로 인해 IT가 먼저 해야 할 일은 엔드 투 엔드 프로세스를 가능하게 만들기 위해 가치 흐름을 총체적으로 살펴보는 것이었다.  현재 고객에게 솔루션을 제공하기 위해서는 초기 입찰 과정부터 조달을 거쳐 구성 및 운영에...

2021.11.29

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션이 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너

2021.11.17

현재 운영 중인 애플리케이션이 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

2021.11.17

인터뷰ㅣ"기술 회사도 IT 현대화해야 한다" 키사이트 테크놀로지스 CIO

‘구성 가능한 아키텍처’와 ‘애자일 프로세스’ 못지않게 ‘성장형 사고방식’도 중요하다. 이와 관련해 키사이트 테크놀로지스(KeysightTechnologies)의 CIO 댄 크랜츠와 이야기를 나눠봤다.  지난 1999년 휴렛 팩커드(Hewlett-Packard)는 테스트 및 측정 사업을 분사하여 애질런트 테크놀로지스(Agilent Technologies)를 설립했다. 이는 당시 실리콘밸리 역사상 최대 규모의 기업 공개(IPO)였다.  그 이후 10년 동안 애질런트는 1) 생명과학 기술 및 화학분석 솔루션, 2) 전자 기기라는 2가지 사업 부문을 운영했다. 그리고 2014년 생명과학 사업부가 크게 성장하면서 애질런트는 전자 사업부를 분사해 키사이트 테크놀로지(Keysight Technologies)를 출범했다. 당시 IT 분리를 이끌었던 댄 크랜츠는 2017년 키사이트의 CIO로 취임했다.    키사이트는 ▲제품 판매에서 산업 솔루션 판매로의 전환, ▲R&D 투자 확대, ▲신규 회사 인수라는 3가지 전략을 추진해 연간 매출을 28억 달러에서 56억 달러로 증가시켰다.  크랜츠는 (이러한 성장을 뒷받침하기 위해) IT에도 일련의 새로운 비즈니스 역량이 요구됐다고 밝혔다. 이를테면 디지털 인게이지먼트 기술, 역동적인 공급망, 보증 기반 하드웨어에서 서브스크립션 기반 소프트웨어로 전환하는 제품군 지원 역량 등이다.  그는 IT 환경 안정화는 기본이었다고 말하면서, 새로운 비즈니스 역량을 제공하고 앞으로의 성장을 지원하기 위해서는 IT를 변혁해야 했다고 언급했다.  ‘클라우드 퍼스트’ 그리고 ‘구성 가능한’ 아키텍처  크랜츠는 “기술 회사라면 당연히 현대화된 IT를 기반으로 운영되리라 생각할 수 있다”라며, “하지만 기술회사 역시 (다른 모든 기업과 마찬가지로) IT를 현대화해야 한다. 이를테면 시장에선 선도적인 양자 컴퓨팅 기능을 제공하지만 기저에서는 15년된 IT 인프라를 사...

디지털 트랜스포메이션 IT 트랜스포메이션 빅 데이터 데이터 활용 클라우드 아키텍처 성장형 사고방식 현대화 애자일

2021.07.30

‘구성 가능한 아키텍처’와 ‘애자일 프로세스’ 못지않게 ‘성장형 사고방식’도 중요하다. 이와 관련해 키사이트 테크놀로지스(KeysightTechnologies)의 CIO 댄 크랜츠와 이야기를 나눠봤다.  지난 1999년 휴렛 팩커드(Hewlett-Packard)는 테스트 및 측정 사업을 분사하여 애질런트 테크놀로지스(Agilent Technologies)를 설립했다. 이는 당시 실리콘밸리 역사상 최대 규모의 기업 공개(IPO)였다.  그 이후 10년 동안 애질런트는 1) 생명과학 기술 및 화학분석 솔루션, 2) 전자 기기라는 2가지 사업 부문을 운영했다. 그리고 2014년 생명과학 사업부가 크게 성장하면서 애질런트는 전자 사업부를 분사해 키사이트 테크놀로지(Keysight Technologies)를 출범했다. 당시 IT 분리를 이끌었던 댄 크랜츠는 2017년 키사이트의 CIO로 취임했다.    키사이트는 ▲제품 판매에서 산업 솔루션 판매로의 전환, ▲R&D 투자 확대, ▲신규 회사 인수라는 3가지 전략을 추진해 연간 매출을 28억 달러에서 56억 달러로 증가시켰다.  크랜츠는 (이러한 성장을 뒷받침하기 위해) IT에도 일련의 새로운 비즈니스 역량이 요구됐다고 밝혔다. 이를테면 디지털 인게이지먼트 기술, 역동적인 공급망, 보증 기반 하드웨어에서 서브스크립션 기반 소프트웨어로 전환하는 제품군 지원 역량 등이다.  그는 IT 환경 안정화는 기본이었다고 말하면서, 새로운 비즈니스 역량을 제공하고 앞으로의 성장을 지원하기 위해서는 IT를 변혁해야 했다고 언급했다.  ‘클라우드 퍼스트’ 그리고 ‘구성 가능한’ 아키텍처  크랜츠는 “기술 회사라면 당연히 현대화된 IT를 기반으로 운영되리라 생각할 수 있다”라며, “하지만 기술회사 역시 (다른 모든 기업과 마찬가지로) IT를 현대화해야 한다. 이를테면 시장에선 선도적인 양자 컴퓨팅 기능을 제공하지만 기저에서는 15년된 IT 인프라를 사...

2021.07.30

칼럼|컨테이너에는 그에 적합한 아키텍처가 필요하다

컨테이너는 간단해 보인다. 하지만 컨테이너의 장점을 활용하려면 그에 적합한 아키텍처를 새롭게 설계해야 한다.  가트너는 기업 내 컨테이너 도입율이 2023년까지는 계속 증가할 것으로 예측하고 있다. 가트너가 발표한 자료에 따르면 애플리케이션(과 데이터)은 빠른 속도로 컨테이너화되고 있다. 앱의 절반 이상을 컨테이너 기반으로 운영하는 조직은 23%에서 29%로 증가했으며, 앱을 컨테이너화한 비율이 10% 미만인 조직은 32%에서 21%로 감소했다.     컨테이너는 점점 클라우드 기반 애플리케이션의 기본 시스템으로 자리매김하고 있다. 컨테이너가 클라우드 네이티브를 달성하는 데 있어서 인기있는 방법이라는 걸 이해하기 위해서는 가트너의 자료를 참고해도 좋겠지만, 클라우드 개발팀과 만나보면 실감할 수 있을 것이다. 또 컨테이너 오케스트레이션 도구를 사용하여 이식성과 확장성을 극대화해보면 왜 컨테이너가 인기 있는지 이해할 수 있다. 컨테이너와 관련된 문제점 중 하나는 컨테이너 자체 혹은 컨테이너 오케스트레이션에 있는 게 아니라, 컨테이너를 어떻게 활용할지 설계하는 일에 있다. 컨테이너는 기본적으로 복잡하면서 층이 나뉘어 있는 분산 애플리케이션이다. 컨테이너를 플랫폼 삼아 특정 애플리케이션을 리프트 앤 시프트 방식으로 옮기는 건 그다지 어렵지 않다. 하지만 대부분의 경우 컨테이너를 그렇게 사용하면 별로 보탬이 되지 않는다. 컨테이너를 플랫폼이자 일종의 아키텍처로 설계하지 않는 한 컨테이너의 장점을 십분 활용할 수 없다. 몇 가지 팁은 다음과 같다.  첫째, 컨테이너에 담긴 애플리케이션들을 기능에 입각해 그룹으로 묶는 법이 있다. 새로운 것이든 기존에 있었던 것이든 모두 그룹화하는 것이다. 그렇게 하는 이유가 있다. 데이터베이스 액세스를 비롯한 목표를 수행하는 데 최적화된 코드를 특정 도메인에 삽입함으로써 문제 해결과 운영 개선을 도모할 수 있기 때문이다. 또 컨테이너를 최적의 클러스터에 배치할 수 있으므로 컨테이너가 ...

컨테이너 쿠버네티스 아키텍처 오케스트레이션

2021.01.14

컨테이너는 간단해 보인다. 하지만 컨테이너의 장점을 활용하려면 그에 적합한 아키텍처를 새롭게 설계해야 한다.  가트너는 기업 내 컨테이너 도입율이 2023년까지는 계속 증가할 것으로 예측하고 있다. 가트너가 발표한 자료에 따르면 애플리케이션(과 데이터)은 빠른 속도로 컨테이너화되고 있다. 앱의 절반 이상을 컨테이너 기반으로 운영하는 조직은 23%에서 29%로 증가했으며, 앱을 컨테이너화한 비율이 10% 미만인 조직은 32%에서 21%로 감소했다.     컨테이너는 점점 클라우드 기반 애플리케이션의 기본 시스템으로 자리매김하고 있다. 컨테이너가 클라우드 네이티브를 달성하는 데 있어서 인기있는 방법이라는 걸 이해하기 위해서는 가트너의 자료를 참고해도 좋겠지만, 클라우드 개발팀과 만나보면 실감할 수 있을 것이다. 또 컨테이너 오케스트레이션 도구를 사용하여 이식성과 확장성을 극대화해보면 왜 컨테이너가 인기 있는지 이해할 수 있다. 컨테이너와 관련된 문제점 중 하나는 컨테이너 자체 혹은 컨테이너 오케스트레이션에 있는 게 아니라, 컨테이너를 어떻게 활용할지 설계하는 일에 있다. 컨테이너는 기본적으로 복잡하면서 층이 나뉘어 있는 분산 애플리케이션이다. 컨테이너를 플랫폼 삼아 특정 애플리케이션을 리프트 앤 시프트 방식으로 옮기는 건 그다지 어렵지 않다. 하지만 대부분의 경우 컨테이너를 그렇게 사용하면 별로 보탬이 되지 않는다. 컨테이너를 플랫폼이자 일종의 아키텍처로 설계하지 않는 한 컨테이너의 장점을 십분 활용할 수 없다. 몇 가지 팁은 다음과 같다.  첫째, 컨테이너에 담긴 애플리케이션들을 기능에 입각해 그룹으로 묶는 법이 있다. 새로운 것이든 기존에 있었던 것이든 모두 그룹화하는 것이다. 그렇게 하는 이유가 있다. 데이터베이스 액세스를 비롯한 목표를 수행하는 데 최적화된 코드를 특정 도메인에 삽입함으로써 문제 해결과 운영 개선을 도모할 수 있기 때문이다. 또 컨테이너를 최적의 클러스터에 배치할 수 있으므로 컨테이너가 ...

2021.01.14

칼럼ㅣ아키텍처는 애자일 프로젝트의 성공에 어떻게 도움이 되는가

비즈니스 엔터프라이즈 아키텍처는 목표 성과에 도달할 확률을 높이며, 애자일 프로젝트 및 프로그램을 성공시키는 데 큰 도움이 될 수 있다.  전통적인 기업에서 시작된 프로젝트 가운데 대다수가 타당한 기간 내에 유의미한 성과를 내지 못한다. 가트너의 2018년 설문조사에 따르면 90% 이상의 기업 리더가 디지털을 최우선 과제로 두고 있지만 이들 중 83%는 디지털 트랜스포메이션에서 의미 있는 진전을 이끌어 내는 데 어려움을 겪고 있다.    혁신적인 변화가 빠르면서도 지속적으로 이뤄지고 있다. 고객들은 그 어느 때보다 정보에 능통하다. 기업은 더 유연한 비즈니스 전략을 수립해야 하는 상황이다. 다시 말해, 변화에 신속하게 대응할 수 있도록 ‘애자일’ 그리고 ‘사일로화된 조직 구조로부터의 탈피’가 요구되고 있다.  보스턴컨설팅그룹(BCG)이 꼽은 대규모 비즈니스 트랜스포메이션 이니셔티브의 실패 원인은 다음과 같다.  1. 투명성(transparency) 부족: 비즈니스 트랜스포메이션 이니셔티브를 이끄는 리더가 기업 전략을 폭넓게 파악하지 못하며, 실제로 중요한 프로그램들을 우선시하지 못하고 있다. 결국, 투입한 리소스에 비해 프로젝트가 너무 많아지는 문제에 직면하게 된다.  2. 너무 긴 사이클: 전통적인 트랜스포메이션 관리 방법은 프로그램 사이클을 길게 만든다. 프로그램 초기 단계에서 결정되는, 유연하지 못한 마일스톤은 애자일한 기업에 적합하지 않다. 고객 중심적인, 애자일한 기업이라면 디지털 트랜스포메이션 이니셔티브의 결과물이 주기적으로 달라질 것이다.  3. 미흡한 관리: 최고경영진이 기획, 정렬, 문제 해결을 책임져야 한다. 계속 변화하는 기업 전략을 깊이 있게 이해하지 못하는 프로젝트 관리자에게 이러한 책임들을 위임해선 안 된다.  ‘엔터프라이즈 아키텍트(EA)’를 애자일 프로젝트에 참여시켜라 대규모 디지털 트랜스포메이션 이니셔티브를 ‘애자일하게’ 관리하려면 두 가지 요소...

아키텍처 엔터프라이즈 아키텍트 애자일 디지털 트랜스포메이션 디지털 변혁 사일로 확장형 애자일 프레임워크

2020.09.07

비즈니스 엔터프라이즈 아키텍처는 목표 성과에 도달할 확률을 높이며, 애자일 프로젝트 및 프로그램을 성공시키는 데 큰 도움이 될 수 있다.  전통적인 기업에서 시작된 프로젝트 가운데 대다수가 타당한 기간 내에 유의미한 성과를 내지 못한다. 가트너의 2018년 설문조사에 따르면 90% 이상의 기업 리더가 디지털을 최우선 과제로 두고 있지만 이들 중 83%는 디지털 트랜스포메이션에서 의미 있는 진전을 이끌어 내는 데 어려움을 겪고 있다.    혁신적인 변화가 빠르면서도 지속적으로 이뤄지고 있다. 고객들은 그 어느 때보다 정보에 능통하다. 기업은 더 유연한 비즈니스 전략을 수립해야 하는 상황이다. 다시 말해, 변화에 신속하게 대응할 수 있도록 ‘애자일’ 그리고 ‘사일로화된 조직 구조로부터의 탈피’가 요구되고 있다.  보스턴컨설팅그룹(BCG)이 꼽은 대규모 비즈니스 트랜스포메이션 이니셔티브의 실패 원인은 다음과 같다.  1. 투명성(transparency) 부족: 비즈니스 트랜스포메이션 이니셔티브를 이끄는 리더가 기업 전략을 폭넓게 파악하지 못하며, 실제로 중요한 프로그램들을 우선시하지 못하고 있다. 결국, 투입한 리소스에 비해 프로젝트가 너무 많아지는 문제에 직면하게 된다.  2. 너무 긴 사이클: 전통적인 트랜스포메이션 관리 방법은 프로그램 사이클을 길게 만든다. 프로그램 초기 단계에서 결정되는, 유연하지 못한 마일스톤은 애자일한 기업에 적합하지 않다. 고객 중심적인, 애자일한 기업이라면 디지털 트랜스포메이션 이니셔티브의 결과물이 주기적으로 달라질 것이다.  3. 미흡한 관리: 최고경영진이 기획, 정렬, 문제 해결을 책임져야 한다. 계속 변화하는 기업 전략을 깊이 있게 이해하지 못하는 프로젝트 관리자에게 이러한 책임들을 위임해선 안 된다.  ‘엔터프라이즈 아키텍트(EA)’를 애자일 프로젝트에 참여시켜라 대규모 디지털 트랜스포메이션 이니셔티브를 ‘애자일하게’ 관리하려면 두 가지 요소...

2020.09.07

블로그 | 클라우드 전문가라면 알아야 할 3가지 멀티클라우드 아키텍처 패턴

멀티클라우드는 이미 대부분 기업이 사용하고 있는 클라우드 배치 모델이지만, 목적을 가지고 멀티클라우드 환경으로 이전하려고 의도한 기업은 없다. 다시 말해, 멀티클라우드 아키텍처를 우연히 배치한 것이다.   필자는 최근 의도적인 멀티클라우드 사용과 관련해 몇 가지 패턴이 부상하고 있으며, 나름의 이점을 가지고 있다는 것을 발견했다. 이들 아키텍처는 멀티클라우드가 제공하는 비즈니스 가치에서 시작된 것이지 임의적인 결정에 의해 우연히 멀티클라우드로 귀결된 것은 아니다. 여기에 큰 차이가 있다. 주목해야 할 멀티클라우드 아키텍처와 그 특징을 소개한다. 데이터 지향 멀티클라우드 아키텍처. 멀티클라우드는 보통 데이터가 애플리케이션을 구동하는 클라우드 서비스 업체와 연결되어 있다. 그래서 SQL 서버는 애저 기반 애플리케이션에 묶여 있고, MySQL은 AWS 기반 애플리케이션에 묶여 있는 것인지 모른다. 이상적인 구조는 아니다. 멀티클라우드 아키텍처에서 데이터가 다른 퍼블릭 클라우드에 있는 다른 데이터베이스나 애플리케이션에서 제대로 돌아가지 않는다면, 퍼블릭 클라우드가 스스로 고립된 섬이 되고 만다.  데이터 지향 멀티클라우드는 서로 다른 여러 퍼블릭 클라우드가 공유하는 하나의 공통된 데이터 소스에 중점을 둔다. 고객 데이터나 영업 데이터 같은 핵심 데이터용으로 단 하나의 신뢰할 수 있는 데이터 소스가 된다. 데이터 시각화 툴이나 데이터 통합 툴, 메타데이터 관리 툴은 이런 데이터 지향 멀티클라우드 배치의 핵심 성공 요소이다. 본질적으로 보면, 이기종 클라우드를 데이터 수준에서 함께 묶는 아키텍처이다. 서비스 지향 멀티클라우드 아키텍처. 데이터 지향적인 동시에, 표준 서비스와 마이크로서비스를 포함한 클라우드 서비스 업체의 공유 서비스에 중점을 둔다. 한 클라우드에서 구축한 서비스를 다른 퍼블릭 클라우드에서도 재사용할 수 있다는 개념이다. 이 아키텍처에는 중앙집중화된 서비스/API 거버넌스가 필요한데, 단일 퍼블릭 클라우드에는 없다. 경우에...

멀티클라우드 아키텍처 패턴

2020.07.09

멀티클라우드는 이미 대부분 기업이 사용하고 있는 클라우드 배치 모델이지만, 목적을 가지고 멀티클라우드 환경으로 이전하려고 의도한 기업은 없다. 다시 말해, 멀티클라우드 아키텍처를 우연히 배치한 것이다.   필자는 최근 의도적인 멀티클라우드 사용과 관련해 몇 가지 패턴이 부상하고 있으며, 나름의 이점을 가지고 있다는 것을 발견했다. 이들 아키텍처는 멀티클라우드가 제공하는 비즈니스 가치에서 시작된 것이지 임의적인 결정에 의해 우연히 멀티클라우드로 귀결된 것은 아니다. 여기에 큰 차이가 있다. 주목해야 할 멀티클라우드 아키텍처와 그 특징을 소개한다. 데이터 지향 멀티클라우드 아키텍처. 멀티클라우드는 보통 데이터가 애플리케이션을 구동하는 클라우드 서비스 업체와 연결되어 있다. 그래서 SQL 서버는 애저 기반 애플리케이션에 묶여 있고, MySQL은 AWS 기반 애플리케이션에 묶여 있는 것인지 모른다. 이상적인 구조는 아니다. 멀티클라우드 아키텍처에서 데이터가 다른 퍼블릭 클라우드에 있는 다른 데이터베이스나 애플리케이션에서 제대로 돌아가지 않는다면, 퍼블릭 클라우드가 스스로 고립된 섬이 되고 만다.  데이터 지향 멀티클라우드는 서로 다른 여러 퍼블릭 클라우드가 공유하는 하나의 공통된 데이터 소스에 중점을 둔다. 고객 데이터나 영업 데이터 같은 핵심 데이터용으로 단 하나의 신뢰할 수 있는 데이터 소스가 된다. 데이터 시각화 툴이나 데이터 통합 툴, 메타데이터 관리 툴은 이런 데이터 지향 멀티클라우드 배치의 핵심 성공 요소이다. 본질적으로 보면, 이기종 클라우드를 데이터 수준에서 함께 묶는 아키텍처이다. 서비스 지향 멀티클라우드 아키텍처. 데이터 지향적인 동시에, 표준 서비스와 마이크로서비스를 포함한 클라우드 서비스 업체의 공유 서비스에 중점을 둔다. 한 클라우드에서 구축한 서비스를 다른 퍼블릭 클라우드에서도 재사용할 수 있다는 개념이다. 이 아키텍처에는 중앙집중화된 서비스/API 거버넌스가 필요한데, 단일 퍼블릭 클라우드에는 없다. 경우에...

2020.07.09

기고 | SW 프로젝트 속도를 높이는 11가지 방법

전략적 의사결정은 소프트웨어 프로젝트 속도에 박차를 가해 비즈니스 기회를 활용하는 데 도움이 될 수 있다. 하지만 IT리더는 서둘러서 프로젝트를 끝내는 것만이 능사가 아님을 인지하고 주의해야 한다.   IT리더와 고객은 소프트웨어 프로젝트가 신속히 마무리되기를 원한다. 그러나 속성 개발은 오류 코드, 부실한 테스팅, 불완전한 솔루션, 심지어 보안되지 않은 소프트웨어로 이어지기 쉽다. 소프트웨어 프로젝트가 실패하기를 원하는 사람은 없겠지만 때에 따라 특정 상황, 예를 들어 시장 환경, 비즈니스 요구, 기회의 여지로 속도를 우선시하는 선택이 정당화될 수 있다.  소프트웨어 개발은 단순히 합리적 노력에 그치지 않는다. 이는 요령이기도 하고 여러 조직에서 비즈니스 전략의 불가결한 부분이기도 하다. 이들 요소가 서로 접하는 지점에서 개발 프로세스를 좀더 효율적으로 조정할 가능성이 존재한다. 물론, 이는 효과적이고 적절하며 단순하고 안전해야 한다. 완전한 소프트웨어를 개발한다는 꿈을 접고, 그 대신 취사선택이 필요함을 인지하고 프로젝트를 간소화하는 결정을 내려야 할 것이다.   IT리더가 소프트웨어 프로젝트에 속도를 내고자 할 때 고려할 수 있는 11가지 전략적 결정을 소개한다.  이해관계자의 희망 사항을 조율하라  모두가 의견을 제시하고 싶어 한다. 마케팅팀, 출하 부서, 회계팀의 이해 관계자는 커다란 희망을 안고 회의실로 들어선다. 요령은 성취하기 가장 쉬운 희망을 찾는 것이다. 언젠가 필자의 소프트웨어팀은 회의를 거듭하면서 단순히 한 양식 필드에 미리 채워진 기본값들을 추가함으로써 데이터 작성자의 부담을 크게 덜 수 있음을 발견했다. 하루에도 수없이 처음부터 양식을 작성하는 판매 직원이 수없이 많았다. HTML에 문자를 몇 개 더 집어넣는 것만으로 우리 팀은 마치 천재처럼 대우받았다.   이해관계자가 현실을 직시하도록 하는 것은 프로젝트의 범위를 제어하는 데 유용하다. 이해관계자가 소소하면서도 매우 ...

CIO 프로젝트 마이크로서비스 서버리스 코딩 단순화 아키텍처 테스트 테스팅 드루팔 Drupal 구글 폼즈 Google Forms 서베이 몽키 Survey Monkey

2020.06.22

전략적 의사결정은 소프트웨어 프로젝트 속도에 박차를 가해 비즈니스 기회를 활용하는 데 도움이 될 수 있다. 하지만 IT리더는 서둘러서 프로젝트를 끝내는 것만이 능사가 아님을 인지하고 주의해야 한다.   IT리더와 고객은 소프트웨어 프로젝트가 신속히 마무리되기를 원한다. 그러나 속성 개발은 오류 코드, 부실한 테스팅, 불완전한 솔루션, 심지어 보안되지 않은 소프트웨어로 이어지기 쉽다. 소프트웨어 프로젝트가 실패하기를 원하는 사람은 없겠지만 때에 따라 특정 상황, 예를 들어 시장 환경, 비즈니스 요구, 기회의 여지로 속도를 우선시하는 선택이 정당화될 수 있다.  소프트웨어 개발은 단순히 합리적 노력에 그치지 않는다. 이는 요령이기도 하고 여러 조직에서 비즈니스 전략의 불가결한 부분이기도 하다. 이들 요소가 서로 접하는 지점에서 개발 프로세스를 좀더 효율적으로 조정할 가능성이 존재한다. 물론, 이는 효과적이고 적절하며 단순하고 안전해야 한다. 완전한 소프트웨어를 개발한다는 꿈을 접고, 그 대신 취사선택이 필요함을 인지하고 프로젝트를 간소화하는 결정을 내려야 할 것이다.   IT리더가 소프트웨어 프로젝트에 속도를 내고자 할 때 고려할 수 있는 11가지 전략적 결정을 소개한다.  이해관계자의 희망 사항을 조율하라  모두가 의견을 제시하고 싶어 한다. 마케팅팀, 출하 부서, 회계팀의 이해 관계자는 커다란 희망을 안고 회의실로 들어선다. 요령은 성취하기 가장 쉬운 희망을 찾는 것이다. 언젠가 필자의 소프트웨어팀은 회의를 거듭하면서 단순히 한 양식 필드에 미리 채워진 기본값들을 추가함으로써 데이터 작성자의 부담을 크게 덜 수 있음을 발견했다. 하루에도 수없이 처음부터 양식을 작성하는 판매 직원이 수없이 많았다. HTML에 문자를 몇 개 더 집어넣는 것만으로 우리 팀은 마치 천재처럼 대우받았다.   이해관계자가 현실을 직시하도록 하는 것은 프로젝트의 범위를 제어하는 데 유용하다. 이해관계자가 소소하면서도 매우 ...

2020.06.22

마이크로프로세서 분야의 구루 ‘짐 켈러’, 인텔 떠난다

여러 쟁쟁한 프로세서 개발 작업에 기여했던 짐 켈러 인텔 수석 부사장이 개인적인 이유로 인텔을 떠난다. 단 향후 6개월 동안 자문 역할을 지속할 예정이라고 11일 인텔은 밝혔다.  인텔은 자사 블로그를 통해 “지난 2 년 동안 인텔의 제품 리더십을 계속 발전시키는 데 도움을 준 켈러의 노력에 감사한다. 그와 그의 가족의 미래에 안녕을 기원한다”라고 밝혔다.  켈러가 개발에 참여한 프로세서 면면은 화려하다. 인텔 K7 아키텍처의 출범에 기여했으며, AMD에서는 애슬론 64의 디자인을 주도했었다. 이후에는 AMD의 젠 아키텍처 및 라이젠 칩의 개발을 이끌었으며, AMD를 떠나 2018년 인텔에 합류하기 전에는 테슬라에서 잠시 근무하기도 했다.    -> 인텔, AMD 전임 젠 최고 책임자 짐 켈러 영입 / 2018.04.30 한편 인텔은 켈러의 퇴임에 더해 TSCG (Technology, Systems Architecture and Client Group)에 대한 여러 변화를 발표했다.  - 넷스피드 시스템의 창립자이자 전 CEO이며, 인텔의 CIPCG(Configurable Intellectual Property and Chassis Group) 리더인 순다리 미트라가 IP 엔지니어링 그룹을 이끈다.  - 지니 스쿠터리는 제온 앤 네트워킹 엔지니어링 그룹을 이끈다. - 다만 헤즈마디는 클라이언트 엔지니어링 그룹을 이끈다. 이 그룹은 SoC (system-on-chip) 실행 및 차세대 클라이언트, 장치 및 칩셋 제품 설계에 중점을 둔 조직이다.  - 나비드 사리아리는 고품질의 대량 제조를위한 포괄적 인 사전 프로덕션 테스트 스위트 및 구성 요소 디버그 기능을 제공하는 데 중점을 둔 제조 및 제품 엔지니어링 그룹을 계속 이끈다.  이 밖에 WCCFTech는 인텔 내부 메모를 입수했다면서, 이에 따르면 인텔의 라자 코두리 아키텍처, 그래픽 소프트...

짐 켈러 마이크로프로세서 CPU 아키텍처 인텔

2020.06.12

여러 쟁쟁한 프로세서 개발 작업에 기여했던 짐 켈러 인텔 수석 부사장이 개인적인 이유로 인텔을 떠난다. 단 향후 6개월 동안 자문 역할을 지속할 예정이라고 11일 인텔은 밝혔다.  인텔은 자사 블로그를 통해 “지난 2 년 동안 인텔의 제품 리더십을 계속 발전시키는 데 도움을 준 켈러의 노력에 감사한다. 그와 그의 가족의 미래에 안녕을 기원한다”라고 밝혔다.  켈러가 개발에 참여한 프로세서 면면은 화려하다. 인텔 K7 아키텍처의 출범에 기여했으며, AMD에서는 애슬론 64의 디자인을 주도했었다. 이후에는 AMD의 젠 아키텍처 및 라이젠 칩의 개발을 이끌었으며, AMD를 떠나 2018년 인텔에 합류하기 전에는 테슬라에서 잠시 근무하기도 했다.    -> 인텔, AMD 전임 젠 최고 책임자 짐 켈러 영입 / 2018.04.30 한편 인텔은 켈러의 퇴임에 더해 TSCG (Technology, Systems Architecture and Client Group)에 대한 여러 변화를 발표했다.  - 넷스피드 시스템의 창립자이자 전 CEO이며, 인텔의 CIPCG(Configurable Intellectual Property and Chassis Group) 리더인 순다리 미트라가 IP 엔지니어링 그룹을 이끈다.  - 지니 스쿠터리는 제온 앤 네트워킹 엔지니어링 그룹을 이끈다. - 다만 헤즈마디는 클라이언트 엔지니어링 그룹을 이끈다. 이 그룹은 SoC (system-on-chip) 실행 및 차세대 클라이언트, 장치 및 칩셋 제품 설계에 중점을 둔 조직이다.  - 나비드 사리아리는 고품질의 대량 제조를위한 포괄적 인 사전 프로덕션 테스트 스위트 및 구성 요소 디버그 기능을 제공하는 데 중점을 둔 제조 및 제품 엔지니어링 그룹을 계속 이끈다.  이 밖에 WCCFTech는 인텔 내부 메모를 입수했다면서, 이에 따르면 인텔의 라자 코두리 아키텍처, 그래픽 소프트...

2020.06.12

블로그 | 성공적인 클라우드 아키텍처로 가는 3단계

클라우드 아키텍트라면 클라우드 기술과 각 기술 조각을 어떻게 하나로 맞추는지를 알아야 한다. 또한 전통적인 프로세스도 이해할 필요가 있다.   클라우드 아키텍처가 다시 뜨거운 주제로 떠올랐다. 클라우드 아키텍트 구하기가 어려워지고 연봉은 올라가면서 많은 사람이 클라우드 아키텍처 관련 교육을 찾고 있다. 대부분 클라우드 아키텍트는 실제로 퍼블릭 클라우드 서비스 업체 한 곳에 관한 전문가에 불과하다. 다른 클라우드 서비스 업체를 알지 못하며, 이들이 함께 동작하는 방식도 알지 못한다. 아키텍트가 너무 근시안적으로 접근하며 맞든 안맞든 같은 기술만을 사용하는 바람에 클라우드 프로젝트가 실패하기도 한다. 필자는 20년 전에 사용하던 전통적인 아키텍처 프로세스로 돌아가는 것이 2020년의 클라우드 컴퓨팅에 더 잘 맞을 수도 있다는 것을 알게 됐다. 물론 이 프로세스는 오늘날 솔루션을 구축하는 방식과 우리가 사용하는 기술로 현대화해야 한다. “장고 끝에 악수”는 항상 위험하다. 게다가 전통적인 순차적 아키텍처 프로세스(워퍼폴 방식)은 애자일 방법론의 세계와 공공연히 충돌한다. 클라우드 아키텍트는 다음 두 가지 극단을 조심해야 한다. 첫째는 클라우드 아키텍처 성공으로 가는 길을 반복할 수 있다는 생각이다. 애플리케이션 개발 모델은 애플리케이션 개발을 최적화하고 비즈니스 요구사항의 변화에 즉각적으로 대응하는 프로세스이다. 하지만 완전히 최적화된 아키텍처를 얻기 위해 수백만 달러를 불필요하게 허비할 계획이 아니라면, 똑같은 접근방법이 먹혀들지는 않는다. 엄청난 비용과 위험성을 지지 않고는 값비싼 기술이나 클라우드 서비스를 그런 식으로 도입할 수는 없다. 둘째, 클라우드 아키텍처를 기반 클라우드 기술을 선택하는 데 1년 이상이 걸리는 과정으로 생각한다면, 세상이 따라잡기 힘든 속도로 빠르게 바뀐다는 것을 알게 될 것이다. 이렇게 설계한 아키텍처를 프로덕션에 적용한다면, 구식 아키텍처를 배치하는 것이다. 그렇다면 성공적인 클라우드 아키텍처로 가는 가장 좋...

아키텍처 아키텍트 매크로아키텍처 마이크로아키텍처

2020.06.09

클라우드 아키텍트라면 클라우드 기술과 각 기술 조각을 어떻게 하나로 맞추는지를 알아야 한다. 또한 전통적인 프로세스도 이해할 필요가 있다.   클라우드 아키텍처가 다시 뜨거운 주제로 떠올랐다. 클라우드 아키텍트 구하기가 어려워지고 연봉은 올라가면서 많은 사람이 클라우드 아키텍처 관련 교육을 찾고 있다. 대부분 클라우드 아키텍트는 실제로 퍼블릭 클라우드 서비스 업체 한 곳에 관한 전문가에 불과하다. 다른 클라우드 서비스 업체를 알지 못하며, 이들이 함께 동작하는 방식도 알지 못한다. 아키텍트가 너무 근시안적으로 접근하며 맞든 안맞든 같은 기술만을 사용하는 바람에 클라우드 프로젝트가 실패하기도 한다. 필자는 20년 전에 사용하던 전통적인 아키텍처 프로세스로 돌아가는 것이 2020년의 클라우드 컴퓨팅에 더 잘 맞을 수도 있다는 것을 알게 됐다. 물론 이 프로세스는 오늘날 솔루션을 구축하는 방식과 우리가 사용하는 기술로 현대화해야 한다. “장고 끝에 악수”는 항상 위험하다. 게다가 전통적인 순차적 아키텍처 프로세스(워퍼폴 방식)은 애자일 방법론의 세계와 공공연히 충돌한다. 클라우드 아키텍트는 다음 두 가지 극단을 조심해야 한다. 첫째는 클라우드 아키텍처 성공으로 가는 길을 반복할 수 있다는 생각이다. 애플리케이션 개발 모델은 애플리케이션 개발을 최적화하고 비즈니스 요구사항의 변화에 즉각적으로 대응하는 프로세스이다. 하지만 완전히 최적화된 아키텍처를 얻기 위해 수백만 달러를 불필요하게 허비할 계획이 아니라면, 똑같은 접근방법이 먹혀들지는 않는다. 엄청난 비용과 위험성을 지지 않고는 값비싼 기술이나 클라우드 서비스를 그런 식으로 도입할 수는 없다. 둘째, 클라우드 아키텍처를 기반 클라우드 기술을 선택하는 데 1년 이상이 걸리는 과정으로 생각한다면, 세상이 따라잡기 힘든 속도로 빠르게 바뀐다는 것을 알게 될 것이다. 이렇게 설계한 아키텍처를 프로덕션에 적용한다면, 구식 아키텍처를 배치하는 것이다. 그렇다면 성공적인 클라우드 아키텍처로 가는 가장 좋...

2020.06.09

칼럼 | 엣지 컴퓨팅 아키텍처가 더 유연해져야 하는 이유

많은 엣지 컴퓨팅 환경은 매우 구체적인 필요성에 의해 운용되지만 시간이 지나면서 새로운 필요나 다른 엣지 요구 사항이 생길 수 있으므로 IT 리더는 유연성과 적응성을 염두에 두고 엣지 컴퓨팅 아키텍처를 도입해야 한다. 모든 엣지 컴퓨팅 시스템에는 하드웨어, 애플리케이션, 인프라 소프트웨어 및 네트워킹의 복잡한 조합이라는 공통점이 있지만 그렇다고 설계가 똑같은 것은 아니다.   모든 새로운 프로젝트에는 산업용 제어, 자율 수송, 의료 서비스, 공공 안전 및 에너지 관리와 같은 다양한 응용 분야에 걸쳐 프로젝트 목표를 달성하기 위해 고도로 전문화된 소프트웨어와 통합된 맞춤형 네트워킹이 필요하다. 요구 사항은 성능, 응답 시간, 수집 및 처리되는 데이터의 양, 비용 측면에서 각 사용 사례마다 다르다. 이러한 시스템에 대한 투자 수익률을 예측하기란 여전히 어려우므로 미래의 엣지 요구 사항을 충족하는 데 드는 비용을 최소화하기 위해서는 즉시 맞춤 설정이 가능한 아키텍처를 선택하는 것이 최선이다. 엣지 컴퓨팅 시스템을 구축하려면 서버와 애플리케이션, 인프라 소프트웨어, 네트워킹의 복잡한 조합이 필요하다. 서버는 소프트웨어 제어 시스템과 분석을 실행하는데, 예를 들어 대량의 IoT 데이터를 실용적인 정보로 변환한다. 소프트웨어와 네트워킹 시스템에 개방형 API를 사용해 트래픽 흐름을 맞춤 설정할 수 있다. 네트워크는 비용 한도 내에서 필요한 지연 성능 및 안정성을 제공하도록 설계된다. 디바이스, 로컬 네트워크, 게이트웨이, 컴퓨팅 등 엣지 시스템의 각 요소와 관련한 변수를 고려하면 필수 사양을 충족하기 위해서는 시스템 통합 기술이 필요할 수 있다. 엣지 컴퓨팅의 각 요소를 간략히 살펴보면 다음과 같다.   엣지 디바이스 네트워크 엣지에서 데이터를 수집하는 디바이스의 종류는 매우 다양하다. 센서, 산업용 기기, 의료 장비, 비디오카메라, 액추에이터, RFID 장비, 자산 모니터, 자율 주문 키오스크, PC, 태블릿, 폰을 비롯해 온도조절기와 냉장고,...

엣지 엣지컴퓨팅 아키텍처 클라우드 데이터 엣지디바이스 네트워크엣지 사물인터넷

2020.05.22

많은 엣지 컴퓨팅 환경은 매우 구체적인 필요성에 의해 운용되지만 시간이 지나면서 새로운 필요나 다른 엣지 요구 사항이 생길 수 있으므로 IT 리더는 유연성과 적응성을 염두에 두고 엣지 컴퓨팅 아키텍처를 도입해야 한다. 모든 엣지 컴퓨팅 시스템에는 하드웨어, 애플리케이션, 인프라 소프트웨어 및 네트워킹의 복잡한 조합이라는 공통점이 있지만 그렇다고 설계가 똑같은 것은 아니다.   모든 새로운 프로젝트에는 산업용 제어, 자율 수송, 의료 서비스, 공공 안전 및 에너지 관리와 같은 다양한 응용 분야에 걸쳐 프로젝트 목표를 달성하기 위해 고도로 전문화된 소프트웨어와 통합된 맞춤형 네트워킹이 필요하다. 요구 사항은 성능, 응답 시간, 수집 및 처리되는 데이터의 양, 비용 측면에서 각 사용 사례마다 다르다. 이러한 시스템에 대한 투자 수익률을 예측하기란 여전히 어려우므로 미래의 엣지 요구 사항을 충족하는 데 드는 비용을 최소화하기 위해서는 즉시 맞춤 설정이 가능한 아키텍처를 선택하는 것이 최선이다. 엣지 컴퓨팅 시스템을 구축하려면 서버와 애플리케이션, 인프라 소프트웨어, 네트워킹의 복잡한 조합이 필요하다. 서버는 소프트웨어 제어 시스템과 분석을 실행하는데, 예를 들어 대량의 IoT 데이터를 실용적인 정보로 변환한다. 소프트웨어와 네트워킹 시스템에 개방형 API를 사용해 트래픽 흐름을 맞춤 설정할 수 있다. 네트워크는 비용 한도 내에서 필요한 지연 성능 및 안정성을 제공하도록 설계된다. 디바이스, 로컬 네트워크, 게이트웨이, 컴퓨팅 등 엣지 시스템의 각 요소와 관련한 변수를 고려하면 필수 사양을 충족하기 위해서는 시스템 통합 기술이 필요할 수 있다. 엣지 컴퓨팅의 각 요소를 간략히 살펴보면 다음과 같다.   엣지 디바이스 네트워크 엣지에서 데이터를 수집하는 디바이스의 종류는 매우 다양하다. 센서, 산업용 기기, 의료 장비, 비디오카메라, 액추에이터, RFID 장비, 자산 모니터, 자율 주문 키오스크, PC, 태블릿, 폰을 비롯해 온도조절기와 냉장고,...

2020.05.22

기고ㅣ멀티클라우드 데이터 관리의 적절한 균형 찾기

오늘날 IT 리더들은 리소스를 효율적으로 운용하고 비용을 절감하는 것보다 클라우드 및 데이터 기반 인프라 구축에 더 신경써야 할 필요가 있다. 멀티클라우드 환경이 하이퍼스케일 인프라 구축의 새로운 기준으로 빠르게 자리 잡고 있다. 하이퍼스케일 인프라는 수요에 맞춰 인프라 규모를 조정할 수 있어 불확실성이 높은 시장 환경에도 대응할 수 있다는 이점이 있다. 대부분의 기업이 가까운 시일 내에 여러 클라우드를 활용하는 아키텍처를 도입할 것이다. 이는 데이터센터의 탄소발자국을 최소화하고 비용 효율성 관점에서 IT 자원을 탄력적으로 관리할 수 있다.   이러한 아키텍처를 도입하는 기업은 또한 비즈니스 프로세스에 하이퍼 자동화 기술을 적용하는 데 상당한 노력과 시간을 투자할 것이다. 인간 중심의 협업 시스템을 강화할 뿐만 아니라 데이터 주도 혁신을 달성하는 데 필수적인 AI 및 머신러닝 기술을 활용하기 위해서다. 하지만 멀티클라우드와 경계 없는(Borderless) 인프라를 관리하려면 IT 리더는 다양한 리소스를 체계적으로 조직해야 한다. 또한 레거시 애플리케이션을 활용하고 보안 및 컴플라이언스를 확보하며 인프라 비용을 절감할 수 있는 역량도 갖춰야 한다. 즉 오늘날의 IT 리더들은 인프라 구축 이상으로 고려해야 할 것들이 많다. 성공적인 멀티클라우드 인프라 구축에 필수적인 아키텍처 관련 고려사항이 있다. ▲데이터 신뢰성, ▲데이터 접근성, ▲비즈니스 연속성이다. 간혹 퍼블릭 클라우드 벤더가 제공하는 데이터 보호 기능에 한계가 있다는 것을 알아차리지 못하는 경우가 있다. 멀티클라우드 워크로드 프로비저닝, 관리 및 디-프로비저닝을 위한 종합적이고 끊김 없는 데이터 관리 전략이 없다면, 귀중한 데이터를 제대로 활용하지 못하거나 손실할 위험이 있다. 새로운 멀티클라우드 세계에서 중요한 것은 IT 아키텍트가 이 세 가지 고려사항을 적용하고, 종합적인 데이터 관리를 아키텍처의 필수 기본 요소로 포함시키는 것이다. 고도로 분산된 환경에서 멀티클라우드 이해하...

클라우드 하이퍼오토메이션 데이터접근성 데이터신뢰성 멀티클라우드 하이퍼스케일 머신러닝 비즈니스연속성 인공지능 IT인프라 아키텍처 데이터센터 하이퍼자동화

2020.04.03

오늘날 IT 리더들은 리소스를 효율적으로 운용하고 비용을 절감하는 것보다 클라우드 및 데이터 기반 인프라 구축에 더 신경써야 할 필요가 있다. 멀티클라우드 환경이 하이퍼스케일 인프라 구축의 새로운 기준으로 빠르게 자리 잡고 있다. 하이퍼스케일 인프라는 수요에 맞춰 인프라 규모를 조정할 수 있어 불확실성이 높은 시장 환경에도 대응할 수 있다는 이점이 있다. 대부분의 기업이 가까운 시일 내에 여러 클라우드를 활용하는 아키텍처를 도입할 것이다. 이는 데이터센터의 탄소발자국을 최소화하고 비용 효율성 관점에서 IT 자원을 탄력적으로 관리할 수 있다.   이러한 아키텍처를 도입하는 기업은 또한 비즈니스 프로세스에 하이퍼 자동화 기술을 적용하는 데 상당한 노력과 시간을 투자할 것이다. 인간 중심의 협업 시스템을 강화할 뿐만 아니라 데이터 주도 혁신을 달성하는 데 필수적인 AI 및 머신러닝 기술을 활용하기 위해서다. 하지만 멀티클라우드와 경계 없는(Borderless) 인프라를 관리하려면 IT 리더는 다양한 리소스를 체계적으로 조직해야 한다. 또한 레거시 애플리케이션을 활용하고 보안 및 컴플라이언스를 확보하며 인프라 비용을 절감할 수 있는 역량도 갖춰야 한다. 즉 오늘날의 IT 리더들은 인프라 구축 이상으로 고려해야 할 것들이 많다. 성공적인 멀티클라우드 인프라 구축에 필수적인 아키텍처 관련 고려사항이 있다. ▲데이터 신뢰성, ▲데이터 접근성, ▲비즈니스 연속성이다. 간혹 퍼블릭 클라우드 벤더가 제공하는 데이터 보호 기능에 한계가 있다는 것을 알아차리지 못하는 경우가 있다. 멀티클라우드 워크로드 프로비저닝, 관리 및 디-프로비저닝을 위한 종합적이고 끊김 없는 데이터 관리 전략이 없다면, 귀중한 데이터를 제대로 활용하지 못하거나 손실할 위험이 있다. 새로운 멀티클라우드 세계에서 중요한 것은 IT 아키텍트가 이 세 가지 고려사항을 적용하고, 종합적인 데이터 관리를 아키텍처의 필수 기본 요소로 포함시키는 것이다. 고도로 분산된 환경에서 멀티클라우드 이해하...

2020.04.03

블로그 | 최고의 클라우드 마이그레이션 방법론은?

클라우드 마이그레이션 프로젝트는 두 가지 측면이 있다. 첫째는 단기 전력질주이다. 프로젝트팀은 몇 가지 애플리케이션 워크로드와 데이터를 하나 또는 여러 클라우드로 이전한다. 이 프로젝트는 독립적으로 움직이며, 아키텍처 측면의 규제나 통제도 적고 기간도 2~6개월 정도이다. 둘째는 보안, 거버넌스, 관리, 모니터링을 포괄하는 장기적인 아키텍처이다. 클라우드 사업부와 CTO 또는 클라우드 아키텍트가 방향을 잡으며, 이 과정은 지속된다.   문제는 여기에 있다. 전자가 후자를 덮어버리는 것이다. 즉 무작위적이고 개별적인 전력질주 방식을 사용해 클라우드로 마이그레이션하고, 공통된 보안이나 거버넌스, 관리나 모니터링에 대한 고려는 별로 없다는 것이다. 그 결과는 복잡성으로 나타난다. 뭔가 동작하는 것처럼 보이는 것을 만들었지만, 애플리케이션은 한 플랫폼에서 다른 플랫폼으로 옮겨지고, 다른 기술 스택을 이용해 배치된다. 이렇게 구축한 애플리케이션은 실제 운영 단계에 들어서면서 현재의 자원으로 운영하기에는 너무 복잡하다는 것이 드러난다. 실수는 이미 저질러졌고, 시스템은 금방 침해되고 서비스 중단은 일상화된다. 이 모든 것은 전력질주식 마이그레이션 프로젝트 때문이다. 그렇다고 이런 민첩한 방식이 잘못됐다는 것은 아니다. 대신 일종의 중앙통제센터가 필요하다. 예를 들어, 견고한 레퍼런스의 공통 아키텍처로 보안이나 거버넌스, 데이터, 관리, 그리고 애플리케이션에 적용되는 모든 시스템의 기초를 갖추는 것이다. 베스트 오브 브리드 방식이나 멀티클라우드 솔루션을 추구할 때 자칫 목표 클라우드 솔루션을 제대로 최적화해야 한다는 것을 놓칠 수 있다. 개별 프로젝트는 온전히 최적화된 클라우드 시스템에 집중할 수 있지만, 공통성이 별로 없는 수많은 다른 시스템의 맥락에서 이상적인 시스템을 만들어내지는 못한다. 따라서 제대로 된 접근방법은 두 방식을 모두 추구하는 것이다. 프로젝트의 길과 공통 아키텍처와 솔루션의 길이다. 이 두 가지는 충분히 연결되어 공통 기술 솔루...

마이그레이션 아키텍처 방법론

2019.12.12

클라우드 마이그레이션 프로젝트는 두 가지 측면이 있다. 첫째는 단기 전력질주이다. 프로젝트팀은 몇 가지 애플리케이션 워크로드와 데이터를 하나 또는 여러 클라우드로 이전한다. 이 프로젝트는 독립적으로 움직이며, 아키텍처 측면의 규제나 통제도 적고 기간도 2~6개월 정도이다. 둘째는 보안, 거버넌스, 관리, 모니터링을 포괄하는 장기적인 아키텍처이다. 클라우드 사업부와 CTO 또는 클라우드 아키텍트가 방향을 잡으며, 이 과정은 지속된다.   문제는 여기에 있다. 전자가 후자를 덮어버리는 것이다. 즉 무작위적이고 개별적인 전력질주 방식을 사용해 클라우드로 마이그레이션하고, 공통된 보안이나 거버넌스, 관리나 모니터링에 대한 고려는 별로 없다는 것이다. 그 결과는 복잡성으로 나타난다. 뭔가 동작하는 것처럼 보이는 것을 만들었지만, 애플리케이션은 한 플랫폼에서 다른 플랫폼으로 옮겨지고, 다른 기술 스택을 이용해 배치된다. 이렇게 구축한 애플리케이션은 실제 운영 단계에 들어서면서 현재의 자원으로 운영하기에는 너무 복잡하다는 것이 드러난다. 실수는 이미 저질러졌고, 시스템은 금방 침해되고 서비스 중단은 일상화된다. 이 모든 것은 전력질주식 마이그레이션 프로젝트 때문이다. 그렇다고 이런 민첩한 방식이 잘못됐다는 것은 아니다. 대신 일종의 중앙통제센터가 필요하다. 예를 들어, 견고한 레퍼런스의 공통 아키텍처로 보안이나 거버넌스, 데이터, 관리, 그리고 애플리케이션에 적용되는 모든 시스템의 기초를 갖추는 것이다. 베스트 오브 브리드 방식이나 멀티클라우드 솔루션을 추구할 때 자칫 목표 클라우드 솔루션을 제대로 최적화해야 한다는 것을 놓칠 수 있다. 개별 프로젝트는 온전히 최적화된 클라우드 시스템에 집중할 수 있지만, 공통성이 별로 없는 수많은 다른 시스템의 맥락에서 이상적인 시스템을 만들어내지는 못한다. 따라서 제대로 된 접근방법은 두 방식을 모두 추구하는 것이다. 프로젝트의 길과 공통 아키텍처와 솔루션의 길이다. 이 두 가지는 충분히 연결되어 공통 기술 솔루...

2019.12.12

블로그 | 나쁜 클라우드 아키텍처를 유발하는 ‘사람’을 막는 방법

필자는 기술의 사용과 환경 구성 양쪽에 걸쳐 일종의 소모전을 치르고 있다. 한쪽에서는 어떤 기술을 어떻게 사용해야 하는지에 대해 전혀 다른 생각을 하는 사람이 있다. 다른 쪽에는 어떤 것이 옳은 선택인지 아는 사람이 있다.   요즘 이런 전투는 주로 어떤 클라우드 서비스 업체를 선택할 것인지, 어떤 데이터베이스를 사용할 것인지, 어떤 데브옵스 툴 체인을 이용할 것인지를 두고 벌어진다. 너무나 많은 새로운 것이 매일매일 등장하기 때문에 너무나 많은 선택이 이미 판단이 내려진 결론과 충돌한다. 필자를 당황스럽게 만드는 것은 한 문제에 대한 옳은 해답은 보통 한 가지라는 것이다. 즉 한 가지 기술과 환경 구성이 가장 효율적이라는 말이다. 다른 솔루션은 보통 완전히 실패하지는 않지만, 효율성은 상당히 떨어진다. “내가 전에 말했잖아”라고 할 수 있는 순간은 오지 않는다. 앞으로 몇 년 동안 수백만 달러의 투자 가능한 비용을 잃어버릴 것이기 때문이다. 필자는 이를 “바보 세금”이라고 부른다. 가장 정치에 뛰어난 사람들이 보통 아키텍처를 선택한다. 옳건 그르건. 하지만 이들은 보통 논리가 아니라 감정에 의해 움직인다. 아마 이들이 좋아하는 한 솔루션 업체의 영업팀이 있다면, 이 업체의 기술이 다른 업체보다 더 높은 점수를 받을 것이다. 이들은 성공이나 실패 외에 선택한 기술이 비즈니스 요구 사항을 얼마나 잘 만족할 것인지는 고려하지 않는다.  기업의 클라우드 아키텍처 결정할 때 이런 사람들의 부정적인 영향을 배제하는 방법을 소개한다. 우선, 어떤 기술이나 그 기술의 환경 구성을 선택하는 데 필요한 프레임워크에 대해 모두가 동의하는 가이드라인을 사전에 결정한다. 논리적인 프로세스에 합의하면 보통 옳은 결정을 내릴 수 있다. 이렇게 되면 합의한 경로에서 동떨어진 것을 제안하는 것이 매우 힘들어진다. 본질적으로 이들의 정치적인 상식을 역이용하는 것이다. 자신들도 동의한 규칙을 깨는 것은 정치적으로 절대 보기 좋지 않기 때문이다. 또 다른 방안...

프로세스 아키텍처 의사결정 문화

2019.08.22

필자는 기술의 사용과 환경 구성 양쪽에 걸쳐 일종의 소모전을 치르고 있다. 한쪽에서는 어떤 기술을 어떻게 사용해야 하는지에 대해 전혀 다른 생각을 하는 사람이 있다. 다른 쪽에는 어떤 것이 옳은 선택인지 아는 사람이 있다.   요즘 이런 전투는 주로 어떤 클라우드 서비스 업체를 선택할 것인지, 어떤 데이터베이스를 사용할 것인지, 어떤 데브옵스 툴 체인을 이용할 것인지를 두고 벌어진다. 너무나 많은 새로운 것이 매일매일 등장하기 때문에 너무나 많은 선택이 이미 판단이 내려진 결론과 충돌한다. 필자를 당황스럽게 만드는 것은 한 문제에 대한 옳은 해답은 보통 한 가지라는 것이다. 즉 한 가지 기술과 환경 구성이 가장 효율적이라는 말이다. 다른 솔루션은 보통 완전히 실패하지는 않지만, 효율성은 상당히 떨어진다. “내가 전에 말했잖아”라고 할 수 있는 순간은 오지 않는다. 앞으로 몇 년 동안 수백만 달러의 투자 가능한 비용을 잃어버릴 것이기 때문이다. 필자는 이를 “바보 세금”이라고 부른다. 가장 정치에 뛰어난 사람들이 보통 아키텍처를 선택한다. 옳건 그르건. 하지만 이들은 보통 논리가 아니라 감정에 의해 움직인다. 아마 이들이 좋아하는 한 솔루션 업체의 영업팀이 있다면, 이 업체의 기술이 다른 업체보다 더 높은 점수를 받을 것이다. 이들은 성공이나 실패 외에 선택한 기술이 비즈니스 요구 사항을 얼마나 잘 만족할 것인지는 고려하지 않는다.  기업의 클라우드 아키텍처 결정할 때 이런 사람들의 부정적인 영향을 배제하는 방법을 소개한다. 우선, 어떤 기술이나 그 기술의 환경 구성을 선택하는 데 필요한 프레임워크에 대해 모두가 동의하는 가이드라인을 사전에 결정한다. 논리적인 프로세스에 합의하면 보통 옳은 결정을 내릴 수 있다. 이렇게 되면 합의한 경로에서 동떨어진 것을 제안하는 것이 매우 힘들어진다. 본질적으로 이들의 정치적인 상식을 역이용하는 것이다. 자신들도 동의한 규칙을 깨는 것은 정치적으로 절대 보기 좋지 않기 때문이다. 또 다른 방안...

2019.08.22

기고 | '아키텍처' 작업이 유의미할 때

기업이나 시스템에 대한 이야기를 할 때 ‘아키텍처’(architecture)라는 것을 이야기하곤 한다. 이 때 모델, 다이어그램, 스프레드시트 등 해당 기업이나 시스템을 설명하는 일종의 산출물을 말하는 경우가 대부분이다. 그 산출물은 사용 중인 아키텍처 프레임워크에 의해 정의된다.  그러나 아키텍처가 무엇인지 가장 기본적이고 근본적인 수준에서 곰곰이 생각해 본 적이 있는가? 아키텍처는 산출물 자체가 아니다. 산출물은 아키텍처에 대한 문서 작성 수단일 뿐이다. 복잡한 아키텍처를 이해 가능한 수준으로 만들어 활용하려면, 산출물을 만드는 진정한 목적에 집중해야 한다. 그래야만 아키텍처 활동을 통해 뭔가 가치 있는 것을 만들어 낼 수 있다.   아키텍처의 복잡성 특정한 아키텍처 프레임워크에 의해 정의된 공정이나 산출물 자체는 아키텍처가 아니다. 아키텍처를 충분히 검토하고 문서화하기 위한 수단일 뿐이다. 대부분의 아키텍처 프레임워크는 비교적 복잡하다. 설계자가 고려해야 할 측면도 많고 개발 과정 동안에 만들어야 할 산출물도 많다.  예컨대, 자크만 프레임워크(Zachman Framework)에는 행과 열이 있고, 오픈 그룹 아키텍처 프레임워크(The Open Group Architecture Framework)에는 필라(pillar)가 있으며, 미국 국방부 아키텍처 프레임워크에는 뷰(view)가 있다. 어떤 프레임워크를 선택하든 해당 프레임워크의 확립된 방법론을 따른다면 상호 관련된 산출물을 십 수개 이상 생산해야 하는 상황에 놓이게 된다. 이 과정의 결과가 바로 산출물이고 산출물 간의 연결고리인데 프로젝트에 새로 온 사람에게는 이해하기 어려울 수 있다. 적절한 크기의 시스템이라도 세부적인 아키텍처는 복잡하다. 이러한 복잡함의 결과가 아키텍처 ‘사제단’(priesthood)이다. 설계자들은 담당 작업 영역에서 산출물과 그 관계들을 만들어 내지만 결과물은 심한 경우 질려버리거나 아니면 아예 이해를 못할 정도로 복잡하다.  결...

아키텍처

2019.06.26

기업이나 시스템에 대한 이야기를 할 때 ‘아키텍처’(architecture)라는 것을 이야기하곤 한다. 이 때 모델, 다이어그램, 스프레드시트 등 해당 기업이나 시스템을 설명하는 일종의 산출물을 말하는 경우가 대부분이다. 그 산출물은 사용 중인 아키텍처 프레임워크에 의해 정의된다.  그러나 아키텍처가 무엇인지 가장 기본적이고 근본적인 수준에서 곰곰이 생각해 본 적이 있는가? 아키텍처는 산출물 자체가 아니다. 산출물은 아키텍처에 대한 문서 작성 수단일 뿐이다. 복잡한 아키텍처를 이해 가능한 수준으로 만들어 활용하려면, 산출물을 만드는 진정한 목적에 집중해야 한다. 그래야만 아키텍처 활동을 통해 뭔가 가치 있는 것을 만들어 낼 수 있다.   아키텍처의 복잡성 특정한 아키텍처 프레임워크에 의해 정의된 공정이나 산출물 자체는 아키텍처가 아니다. 아키텍처를 충분히 검토하고 문서화하기 위한 수단일 뿐이다. 대부분의 아키텍처 프레임워크는 비교적 복잡하다. 설계자가 고려해야 할 측면도 많고 개발 과정 동안에 만들어야 할 산출물도 많다.  예컨대, 자크만 프레임워크(Zachman Framework)에는 행과 열이 있고, 오픈 그룹 아키텍처 프레임워크(The Open Group Architecture Framework)에는 필라(pillar)가 있으며, 미국 국방부 아키텍처 프레임워크에는 뷰(view)가 있다. 어떤 프레임워크를 선택하든 해당 프레임워크의 확립된 방법론을 따른다면 상호 관련된 산출물을 십 수개 이상 생산해야 하는 상황에 놓이게 된다. 이 과정의 결과가 바로 산출물이고 산출물 간의 연결고리인데 프로젝트에 새로 온 사람에게는 이해하기 어려울 수 있다. 적절한 크기의 시스템이라도 세부적인 아키텍처는 복잡하다. 이러한 복잡함의 결과가 아키텍처 ‘사제단’(priesthood)이다. 설계자들은 담당 작업 영역에서 산출물과 그 관계들을 만들어 내지만 결과물은 심한 경우 질려버리거나 아니면 아예 이해를 못할 정도로 복잡하다.  결...

2019.06.26

블로그 | 서버리스 성공을 위한 3분 가이드

시장 분석회사 마켓앤마켓(Markets and Markets)에 따르면, 2018년 서버리스 아키텍처 시장은 약 42억 5,000만 달러 규모로 추정된다. 그리고 2023년에는 시장 규모가 149억 달러에 이를 것으로 예상했다. 서버리스 사용이 이처럼 확산하는 이유는 무엇일까? 빠른 배치와 클라우드옵스의 단순화 및 자동화, 데브옵스 프로세스와의 통합, 그리고 비용 측면의 장점 등을 들 수 있다.   그렇긴 하지만, 서버리스를 사용하고자 하는 사람 대부분이 어떻게 해야 하는지를 잘 모른다. 많은 사람이 전통적인 온프레미스 애플리케이션을 가져다 마우스 드래그로 서버리스에 보낼 수 있다고 생각한다. 하지만 현실은 훨씬 더 복잡하다. 실제로 서버리스 애플리케이션 개발은 전혀 새로운 애플리케이션을 맞추는 것과 비슷하다. 여러 가지 요소를 고려해야 하지만, 주된 작업은 서버리스에 맞춰 애플리케이션을 새로 설계하는 것이다. 특정 설계 패턴에 최적화되어 있는 컨테이너나 다른 실행 아키텍처에 맞춰 설계해야 하는 것처럼, 서버리스도 예외가 아니다. 가장 흔한 실수는 제대로 최적화되지 않은 애플리케이션을 강제로 서버리스에 맞추는 것이다.   개발자가 서버리스를 반기는 이유 서버리스 컴퓨팅의 3대 문제점과 해결 방법 IDG 블로그 | 서버리스 컴퓨팅을 시작하기 전에 알아야 할 것 서버리스 설계를 위한 몇 가지 팁은 다음과 같다. -    애플리케이션을 독립적이고 수명이 짧은 서비스로 분해해야 한다. 서버리스 시스템은 애플리케이션의 구성요소를 별도의 기능으로 실행한다. 많은 경우, 이는 자연스럽지 않은 동작이다. -    결로넞긍로 서버리스 애플리케이션 역시 스테이트리스(Stateless)라야 한다. 이는 API 관리와 같은 서비스를 지원하는데, 서버리스 애플리케이션의 성공에 핵심적인 요소이다. -&...

아키텍처 가이드 서버리스컴퓨팅

2019.06.14

시장 분석회사 마켓앤마켓(Markets and Markets)에 따르면, 2018년 서버리스 아키텍처 시장은 약 42억 5,000만 달러 규모로 추정된다. 그리고 2023년에는 시장 규모가 149억 달러에 이를 것으로 예상했다. 서버리스 사용이 이처럼 확산하는 이유는 무엇일까? 빠른 배치와 클라우드옵스의 단순화 및 자동화, 데브옵스 프로세스와의 통합, 그리고 비용 측면의 장점 등을 들 수 있다.   그렇긴 하지만, 서버리스를 사용하고자 하는 사람 대부분이 어떻게 해야 하는지를 잘 모른다. 많은 사람이 전통적인 온프레미스 애플리케이션을 가져다 마우스 드래그로 서버리스에 보낼 수 있다고 생각한다. 하지만 현실은 훨씬 더 복잡하다. 실제로 서버리스 애플리케이션 개발은 전혀 새로운 애플리케이션을 맞추는 것과 비슷하다. 여러 가지 요소를 고려해야 하지만, 주된 작업은 서버리스에 맞춰 애플리케이션을 새로 설계하는 것이다. 특정 설계 패턴에 최적화되어 있는 컨테이너나 다른 실행 아키텍처에 맞춰 설계해야 하는 것처럼, 서버리스도 예외가 아니다. 가장 흔한 실수는 제대로 최적화되지 않은 애플리케이션을 강제로 서버리스에 맞추는 것이다.   개발자가 서버리스를 반기는 이유 서버리스 컴퓨팅의 3대 문제점과 해결 방법 IDG 블로그 | 서버리스 컴퓨팅을 시작하기 전에 알아야 할 것 서버리스 설계를 위한 몇 가지 팁은 다음과 같다. -    애플리케이션을 독립적이고 수명이 짧은 서비스로 분해해야 한다. 서버리스 시스템은 애플리케이션의 구성요소를 별도의 기능으로 실행한다. 많은 경우, 이는 자연스럽지 않은 동작이다. -    결로넞긍로 서버리스 애플리케이션 역시 스테이트리스(Stateless)라야 한다. 이는 API 관리와 같은 서비스를 지원하는데, 서버리스 애플리케이션의 성공에 핵심적인 요소이다. -&...

2019.06.14

칼럼 | 시스템 아키텍처의 미래

우리가 인식하든, 인식하지 못하든 시스템 아키텍처의 진화가 이뤄지고 있다. 지난 수십 년 간 시스템 아키텍처는 건물 건축 양식과 비슷했다. 시스템이 해야 할 일을 결정하고, 필요한 주요 하부 시스템과 이들의 연결 방식을 파악하고, 계속 분해해 나가면서 상세 내용을 알게 되면 이를 이용해 개발 팀이 각 하부 시스템을 확장하고 이들을 통합해 원하는 시스템을 만들어낸다. 그러나 이러한 패턴이 최근 몇 년간 변화하고 있고 그 속도도 빨라지고 있다.   네트워크의 영향 1990년대 들어 네트워크 시스템이 일반화되면서 시스템 아키텍처 작업이 달라지기 시작했다. 클라이언트-서버 아키텍처가 지배적인 설계 패턴으로 등장함에 따라 네트워크 인터페이스가 포함되어야 했다. 시스템은 이제 더 이상 한 장소에 배치되어 정해진 터미널들로부터 사용하는 단일 개체가 아니었다.  이후 시스템 아키텍처의 진화에 중대한 영향을 미친 것은 시스템 통합 니즈였다. 똑같은 데이터를 다른 여러 시스템에 입력하려면 시간이 많이 걸리고 오류가 생기기 쉽다는 것이 금방 드러나자, 데이터를 공유할 수 있도록 시스템 통합이 시도되기 시작했다.  이는 서비스 지향 아키텍처(SOA)의 개발로 이어졌다. SOA의 기본 개념은 네트워크 상의 어떤 애플리케이션으로든 호출 가능한 서비스로 기능을 제공하자는 것이다. ‘서비스’란 원하는 기능에 대해 잘 정의된 인터페이스에 불과하다. SOA는 유동적으로 작성할 수 있는 애플리케이션의 시대를 약속했다. 새로운 업무적 필요가 생길 때마다 이를 충족하기 위해 애플리케이션의 코딩을 새로 하지 않아도 된다는 뜻이다.  서비스의 부상 대대적인 홍보 속에 등장한 신기술들이 대개 그러하듯 SOA 역시 최초의 약속에 부응하지 못했다. 그러나 기대가 꺼진 지 10년이 지나서야 비로소 SOA 철학의 실질적인 장점이 빛을 발하고 있다.  많은 기능들이 서비스로 이용 가능하게 되었고 이를 사용하는 기업들이 늘어났다. 일례...

아키텍처 SOA API SDN

2019.05.27

우리가 인식하든, 인식하지 못하든 시스템 아키텍처의 진화가 이뤄지고 있다. 지난 수십 년 간 시스템 아키텍처는 건물 건축 양식과 비슷했다. 시스템이 해야 할 일을 결정하고, 필요한 주요 하부 시스템과 이들의 연결 방식을 파악하고, 계속 분해해 나가면서 상세 내용을 알게 되면 이를 이용해 개발 팀이 각 하부 시스템을 확장하고 이들을 통합해 원하는 시스템을 만들어낸다. 그러나 이러한 패턴이 최근 몇 년간 변화하고 있고 그 속도도 빨라지고 있다.   네트워크의 영향 1990년대 들어 네트워크 시스템이 일반화되면서 시스템 아키텍처 작업이 달라지기 시작했다. 클라이언트-서버 아키텍처가 지배적인 설계 패턴으로 등장함에 따라 네트워크 인터페이스가 포함되어야 했다. 시스템은 이제 더 이상 한 장소에 배치되어 정해진 터미널들로부터 사용하는 단일 개체가 아니었다.  이후 시스템 아키텍처의 진화에 중대한 영향을 미친 것은 시스템 통합 니즈였다. 똑같은 데이터를 다른 여러 시스템에 입력하려면 시간이 많이 걸리고 오류가 생기기 쉽다는 것이 금방 드러나자, 데이터를 공유할 수 있도록 시스템 통합이 시도되기 시작했다.  이는 서비스 지향 아키텍처(SOA)의 개발로 이어졌다. SOA의 기본 개념은 네트워크 상의 어떤 애플리케이션으로든 호출 가능한 서비스로 기능을 제공하자는 것이다. ‘서비스’란 원하는 기능에 대해 잘 정의된 인터페이스에 불과하다. SOA는 유동적으로 작성할 수 있는 애플리케이션의 시대를 약속했다. 새로운 업무적 필요가 생길 때마다 이를 충족하기 위해 애플리케이션의 코딩을 새로 하지 않아도 된다는 뜻이다.  서비스의 부상 대대적인 홍보 속에 등장한 신기술들이 대개 그러하듯 SOA 역시 최초의 약속에 부응하지 못했다. 그러나 기대가 꺼진 지 10년이 지나서야 비로소 SOA 철학의 실질적인 장점이 빛을 발하고 있다.  많은 기능들이 서비스로 이용 가능하게 되었고 이를 사용하는 기업들이 늘어났다. 일례...

2019.05.27

회사명:한국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.5.0.5