Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

아키텍트

IDG 블로그 | 너무 복잡한 클라우드, 사람 구하기만 더 어려워진다

클라우드 아키텍트와 채용 책임자는 클라우드 솔루션을 너무 복잡하게 설계하곤 한다. 도끼로 제 발등 찍기가 아닐 수 없다. 클라우드 솔루션팀에는 목표 클라우드 솔루션을 설계하는 아키텍트가 있다. 서로 다른 종류의 클라우드 기술을 고르고 구성하는 일도 한다. 물론 비즈니스 요구사항을 항상 마음에 두고 있을 것이다. 하지만 많은 경우, 이들이 설계한 솔루션은 과대 포장된 기술 중에서 가장 눈에 띄는 기술을 모아 놓은 것처럼 보인다. 모든 것을 서버리스로 하고 디지털 트윈을 사용하는 엣지 컴퓨팅에다 도처에 컨테이너와 컨테이너 클러스터를 배치한다. 그리고 정말로 재미있는 일은 이 모든 기술을 구인을 위한 직무기술서로 바꿀 때, 그리고 내외부의 채용 담당자가 이들 역할을 채우려고 할 때 시작된다.   이런 기술력을 갖춘 인력을 찾는 채용 담당자는 단 한 명의 검증된 후보자를 20건의 일자리가 따라다니고 있다는 것을 알아야 한다. 어떤 경우에는 한 명에 50 대 1인 경우도 있고, 더 많은 일자리가 공석이 되고, 결과적으로 클라우드 프로젝트는 지연되거나 심한 경우 취소된다. 가트너가 437곳의 글로벌 기업을 대상으로 실시한 조사에 따르면, IT 임원은 기술 인력 부족을 신기술 배치의 최대 장애물이라고 본다. 신기술은 서버리스, 머신러닝, 컨테이너, 첨단 스토리지, 분석 등 주로 클라우드 기반의 기술이다. 새삼스러운 일은 아니지만, 이런 기술 인력의 부족으로 인해 복잡한 클라우드 설계가 자해 행위가 될 수 있다는 것은 분명하다. 클라우드로 이전하려는 많은 기업 IT 부서가 정말로 필요한 기술의 종류를 너무 복잡하게 만들고 있다. 기업은 초대형 클라우드 서비스 업체가 연례 행사에서 발표하는 50~100가지를 배치해야 할 기술 목록으로 사용한다. 대부분 기업에는 이렇게 더 새롭고 엄청난 기술까지 필요없을지 모르며, 더 복잡한 클라우드 솔루션은 필요한 인력의 채용을 거의 불가능하게 만들 뿐이다. 컨테이너를 예로 들어보자. 많은 경우 컨테이너는 특정 애플리케이션...

아키텍트 복잡성 구인구직 2021.12.08

IDG 블로그 | 클라우드 아키텍처 제너럴리스트가 되는 방법

필자가 최근에 쓴 글 “좋은 클라우드 아키텍트는 스페셜리스트가 아니라 제너널리스트”가 몇몇 사람의 신경을 건드린 모양이다. 사실 필자는 오랫동안 클라우드 아키텍트는 클라우드 기반 기술만이 아니라 모든 기술을 알고 있어야 한다고 주장해 왔다.   클라우드 아키텍트는 전통적인 엔터프라이즈 시스템 및 네트워킹, 보안, 거버넌스와 클라우드 기반 솔루션을 혼합해야 한다. 또한 이 모든 조각을 최적화된 방식으로 짜맞춰 비즈니스에 최고의 솔루션을 제공하는 방법을 알아야 한다. 많은 이들이 이 모든 기술을 제대로 이해할 수 있는 방법을 문의했다. 여기 간단한 조언과 시도해 볼 만한 접근법 몇 가지를 소개한다. 우선 제너럴리스트 아키텍트에는 두 종류가 있다. 첫 번째 그룹은 여러 단계를 거쳐 성장한 전문가로, 네트워크 엔지니어, 보안 전문가, 데이터베이스 어드민 등의 여러 직책을 가지고 있다. 이들은 클라우드 아키텍트가 정기적으로 다루어야 하는 많은 구성요소에 관해 넓고 다양한 경험과 지식을 보유하고 있다. 얻기 힘든 클라우드 제너럴리스트 지식을 가지고 있는 것이다. 두 번째 그룹은 처음부터 클라우드 일자리를 찾고 있으며, 클라우드 아키텍트가 되고자 한다. 보통은 수십 년이 아니라 몇 년 내에 원하는 목표에 도달하고자 한다. 과연 이들이 관련 기술의 모든 측면을 이해하는 뛰어난 클라우드 아키텍트가 되는 데 필요한 폭넓은 기술력을 빠르게 습득할 수 있을까? 가능하지만 훨씬 더 어려운 방법이다. 물론, 다음과 같은 몇 가지 지름길이 있다. 편안한 영역을 벗어나 새로운 것을 배운다. 필자는 경력 초기에 보안과 관련된 것은 모두 피했다. 그러다 좋은 보안은 모든 것, 데이터부터 애플리케이션, 컴퓨트, AI, 네트워킹 등등에 체계적이라는 것을 갑자기 깨달았다. 이후 필자는 더 나은 아키텍트가 되기 위해 보안과 그 개념, 그 기술을 이해하는 데 중점을 뒀다. 보안 공부를 업무 시간에 한 것은 아니었고, 이런 지식을 얻는 시간에 보수를 받은 것도 아니었다. 다른 신...

아키텍트 제너럴리스트 2021.10.18

IDG 블로그 | 좋은 클라우드 아키텍트는 스페셜리스트가 아니라 제너널리스트

90년대 초 필자는 일자리를 구하면서 아키텍트의 역할을 어떻게 정의하는지를 기반으로 구인 광고를 걸러냈다. 많은 기업이 특정 플랫폼 기술에 중점을 두었고, 더 나은 선택이 되곤 하는 총체적인 솔루션에 대한 이해를 강조하지 않았다.   만약 어떤 기업이 아키텍트를 채용하면서 유닉스나 윈도우, 메인프레임 같은 특정 플랫폼에 관한 지식을 핵심 자격으로 제시한다면, 이 기업은 아키텍트를 채용하려는 것이 아니라 해당 플랫폼에 특화된 주제 전문가(Subject Matter Expert, SME)를 찾는 것이다. 많은 구인 광고의 제목이 ‘아키텍트’였지만, 사실은 아니었다. 게다가 이런 잘못된 구인 광고는 상당한 기회 상실 비용을 유발할 수 있다. 아키텍트는 해법을 찾는 임무는 맡는다. 하지만 아키텍트가 더 큰 가능성과 모든 기술에 중점을 두지 않으면, 아주 큰 기회를 놓치기 쉽다. 2021년 현재, 똑같은 문제가 클라우드 아키텍트에게 일어나고 있다. 자격 인증과 관련된 혼란은 있지만, 보통은 특정 클라우드 서비스 업체의 이름을 붙인 아키텍트가 등장한 것이다. 예를 들어, AWS 아키텍트, 구글 아키텍트 같은 식이다. 이런 자격 인증은 온라인 교육을 20시간만 받으면 딸 수 있다. 오해는 말기 바란다. 기업은 특정 클라우드에 중점을 둔 SME도 필요하다. 하지만 더 큰 그림을 생각하고 이용할 수 있는 모든 기술을 검토하는 누군가도 필요하다. 그런데, 특정 클라우드 서비스 업체의 자격 인증을 가진 아키텍트라면, 해당 클라우드 서비스 업체를 정답으로 보는 사람이 아니겠는가? 필자는 줄곧 클라우드 아키텍트라면 클라우드 기반 솔루션이 아닌 기술도 알고 있어야 한다고 이야기했다. 클라우드 아키텍트는 전통적인 시스템과 네트워킹, 보안, 거버넌스, 그리고 클라우드 기반 솔루션의 혼합체가 필요하며, 이 모든 조각이 기업에 가장 알맞은 최적화된 방식으로 맞아 떨어지도록 하는 방법을 알고 있어야 한다. 필자는 종종 자신이 아는 것만 보고 더 나은, 그리고 더 최적화된 ...

아키텍트 제너럴리스트 주제전문가 2021.10.06

IDG 블로그 | 설계보다 중요한 멀티클라우드의 운영 지속성

좋은 멀티클라우드 아키텍트를 만나기 어려운 시절이다. 스스로 멀티클라우드 아키텍트라 부르는 사람 대부분은 실제로 단일 퍼블릭 클라우드 전문가일 뿐이다. 멀티클라우드로 급격하게 쏠리는 시장의 관심을 따라온 사람들이다. 이런 현상을 “멀티클라우드 워싱(Multicloud Washing)”이라고 부른다.   거의 완벽하게 최적화된 멀티클라우드 솔루션을 만들기 위해서는 각각의 퍼블릭 클라우드가 가지고 있는 것보다는 퍼블릭 클라우드 사이에 무엇이 있는지에 더 집중해야 한다. 또한 대부분 클라우드 아키텍트에게는 아직 없는 새로운 수준의 이해가 필요하다. 이런 변화는 향후 몇 년 동안 빠르게 진행될 것이다. 멀티클라우드 아키텍처의 구성과 구축, 배치와 관련된 몇 가지 원칙이 부상하고 있다. 핵심은 최종 운영에 대한 초점을 잃어버리지 않는 것이다. 운영은 대부분 멀티클라우드 설계가 어려움을 겪는 부분이다. 멀티클라우드를 정의하는 한 가지는 기술의 복잡한 조합이다. 여기에는 보안이나 거버넌스, 모니터링, 데이터 관리 등등의 공통 서비스도 포함된다. 멀티클라우드를 정의하는 또 하나는 이 모든 것을 장기적으로 운영하는 방법이다. 여기에는 자원과 비용이 든다. 많은 경우, 멀티클라우드 구성을 운영할 수 있도록 만드는 비용은 멀티클라우드가 비즈니스에 가져오는 가치보다 비싸다. 이유는 여러 가지겠지만, 대부분은 복잡성 때문이다. 너무 많은 종류의 기술과 업체, 접근방식은 과도하게 복잡한 멀티클라우드 솔루션이 되고, 곧 비현실적인 운영 방식과 자원 요구사항으로 이어진다. 필자는 멀티클라우드 접근법을 운영 가능하도록 만드는 비용이 기존 상태보다 5배나 더 들어간 사례도 알 고 있다. 이런 문제는 실제 배치가 완료되기 전까지는 아무도 몰랐으며, 황급하게 좀 더 합리적인 수준의 운영이 가능하도록 만들기 위해 멀티클라우드에 사용된 기술을 평범하게 만들어야만 했다. 좀 더 민첩한 기술을 보유할 기회를 놓친 것은 물론, 수백만 달러의 추가 손실을 피할 수 없었다. 이제 멀티클...

멀티클라우드 설계 운영 2021.08.25

IDG 블로그 | “대화가 필요한” 클라우드 데이터베이스와 클라우드 인프라

개발팀과 배치팀 대부분은 이전보다는 클라우드 컴퓨팅 관련 작업을 잘한다. 또한 애자일과 데브옵스/데브섹옵스의 부상으로 운영팀과 개발팀이 좀 더 밀접하게 일할 수 있는 기반이 마련됐다. 이제 개발팀은 운영팀과 함께 일하는 데 부담을 느끼지 않는다.   하지만 이런 체계에도 빈틈은 있다. 말하자면, 클라우드 데이터베이스 설계 담당자는 인프라 아키텍트와 제대로 동기화되지 않은 것으로 보인다. 스토리지와 컴퓨트 등 클라우드 데이터베이스에 중요한 자원을 제공하는 사람인데 말이다. 이런 관계는 결국 나쁜 결과물로 이어진다. 핵심 비즈니스를 처리하는 데이터베이스가 자원이 부족해지고, 누군가의 모니터링 콘솔에 경고 메시지가 나타난 후에나 고쳐진다. 하지만 그러는 동안 데이터베이스를 제 기능을 못하고 중요한 비즈니스 트랜잭션은 타격을 받는다. 확실한 서비스 중단이 발생할 수도 있다. 트랜잭션을 처리 중에 자원이 떨어진 데이터베이스가 아무런 경고도 없이 동작을 멈추는 것이다. 이 사태는 데이터베이스 자체를 붕괴시킬 수 있기 때문에 마지막 백업만이 살 길이 된다. 문제는 클라우드 기반 데이터베이스가 모두 똑같지 않은데, 클라우드 인프라 엔지니어는 똑같다고 생각한다는 것이다. 물론 일부 서버리스 방식 데이터베이스는 필요한 자원을 자동으로 할당하고 담당자는 월말에 사용한 만큼의 비용만 내면 된다. 하지만 대부분 클라우드 데이터베이스는 인프라 담당자가 데이터베이스에 대한 상당한 지식을 갖출 것을 요구한다. 데이터베이스의 수는 물론, 용량, 필요한 스토리지의 종류, 데이터베이스 성장 속도, 데이터 캐시 사용, CPU 종류와 규모 등을 파악해야 한다. 온프레미스 데이터베이스를 구성하고 서버 규모를 잡는 것과 너무 비슷하게 느껴질 것이다. 사실이 그렇다. 인기있는 전통 데이터베이스 중 다수가 여전히 온프레미스와 퍼블릭 클라우드를 구분하지 않는다. 그래서 특정 데이터베이스를 위한 시스템 규모를 설정하고 사용량을 가정하는 과정은 거의 같다. 해법은 모두가 알고 있다. 진짜 ...

데이터베이스 아키텍트 데브옵스 2021.08.04

IDG 블로그 | 클라우드에 대한 복잡성 편향이 야기하는 위험

대부분 클라우드 아키텍트가 단순한 것보다는 좀 더 복잡한 솔루션을 좋아한다. 이유와 더 나은 방법을 고민해 본다. 필자가 애청하는 팟캐스트 중 하나인 클라우드캐스트(CloudCast)의 이번 주제는 오늘날 IT 미디어에서는 좀처럼 다루지 않는 심오한 것이었다. “클라우드가 컴퓨팅을 더 쉽게 만든 것 같지만, 지금 클라우드는 레거시 데이터센터와 애플리케이션만큼, 혹은 그보다 더 복잡하다. 앞으로 더 단순한 클라우드가 등장할 수 있을까?”   필자는 오랫동안 클라우드 아키텍처를 복잡하게 만드는 것과 최적화하고 효율화하는 것 사이의 균형을 파악하려 애써왔다. 이 영역을 파고들면 들수록, 복잡성과 단순성의 장단점을 잘 이해해야만 한다는 것을 느끼게 된다. 문제의 핵심은 기술이 아니라 사람일지도 모른다. 대부분 아키텍트는 종종 너무 복잡하고 너무 비싼 클라우드 솔루션을 구축하고 배치한다. 이들 아키텍트는 여러 가지 의식적인 또는 무의식적인 편견에 영향을 받는다. 복잡성 편향(Complexity Bias)은 드물지 않은 일이다. 두 가지 경쟁하는 가설에 직면했을 때, 사람들은 가장 복잡한 것을 선택하는 경향이 있다. 보통은 가장 많은 가정과 회귀 분석을 갖춘 선택지이다. 이 때문에 문제를 해결해야 할 때 단순한 해법을 간과하는 경우가 생긴다. 그런 단순한 방법으로는 해결할 수 없다고 생각하고는 더 복잡한 해법을 고르는 것이다. 필자는 이런 심리학 문제에 의견을 낼 만한 전문가는 아니다. 하지만 구동부가 가장 적은 더 단순한 솔루션이 모든 종류의 기술을 욱여넣은 것보다 훨씬 좋다는 점에서 흥미로운 일이 아닐 수 없다. 두 가지 종류의 스토리지 서비스로 해결할 수 있는데, 네 가지 스토리지를 선택하면 안된다. 앞으로 어딘가에 필요할 수도 있는 기능을 갖추고 있다고, 10가지 서로 다른 클라우드 네이티브 데이터베이스를 선택한다면? 글쎄. 더 큰 문제는 복잡한 아키텍처가 처음에는 그런대로 동작한다는 것이다. 하지만 단순한 해법보다 구축하고 배치하고 운영하는...

복잡성 편향 아키텍트 2021.04.07

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

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

아키텍처 아키텍트 매크로아키텍처 2020.06.08

IDG 블로그 | 좋은 클라우드 아키텍트, “연봉 2억도 너무 싸다”

데이즈인포(DazeInfo)는 최근 클라우드 분야에서 가장 인기 있는 경력에 대한 기사에서 “클라우드 아키텍트는 1년에 14만~15만 달러를 번다. 하지만 적합한 경험과 증명된 성공 기록을 가진 좋은 클라우드 아키텍트는 25만 달러 이상을 만들어낸다”고 평가했다. 많은 사람이 “증명된 성공 기록” 대목에서 기침이 나올 것이다. 클라우드 기반 자원은 비교적 새로운 것이라 이런 자원을 구성해 최적의 해법을 만들어내는 것은 아직도 진화하고 있는 기술이기 때문이다. 어쨌든 클라우드 아키텍처 전문가는 현재 최고의 직업으로 부상하고 있다. 대부분 경우 알짜배기 인력이 확보하면 클라우드 및 IT 투자를 잘못하는 것을 방지해 1년에 10만~100만 달러를 절감할 수 있다. IT 관련 학위를 취득하려는 사람에게 이 메시지는 예비 의사에게 하는 충고와 비슷하다. 돈을 많이 버는 방법은 전문화하는 것이다. 대형 퍼블릭 클라우드 관련 인증을 가진 클라우드 아키텍트가 많이 보이는 것도 같은 이유이다. 이들은 보통 특정 퍼블릭 클라우드에 중점을 두고 있다. 이들 클라우드 아키텍트는 AWS나 구글, 애저를 통해 기업의 문제를 해결하는 데는 뛰어날지 모른다. 하지만 이들이 제시한 해법이 최적이자 동종 최강일 가능성은 크지 않다. 참고로 말하자면, 필자는 이들 솔루션을 조각조각 해체해 기업의 기대를 만족하지 못한 이유를 찾아내는 것을 생업으로 삼고 있다. 이는 보통 클라우드 여부와 관계없이 모든 베스트 프랙티스와 베스트 솔루션의 문제를 지적하는 일이다. 가시성 부족은 제안된 수많은 대상 솔루션이 필요한 것보다 더 많은 비용이 들고, 그러면서도 기업의 문제를 해결하지 못하게 하는 주된 이유이다. 필자나 혹은 필자와 같은 기술을 가진 사람이 제안된 솔루션을 검토하지 않으면, 해당 계획은 프로덕션에 적용될 것이고, 문제는 기하급수적으로 증가해 실패로 기록될 가능성이 크다. 결론적으로, 클라우드를 도입하려는 기업은 현재 상당히 위험한 상황에 있다. 쓸만한 클라우드 아키텍트 인력이 부족하기 ...

연봉 아키텍트 채용 2019.10.16

IDG 블로그 | 클라우드 아키텍트의 책임은 클라우드옵스까지

아키텍트가 화려한 직업이라고 생각하는가? 아키텍트는 운영까지도 책임져야 한다. 필자의 본업은 클라우드 컴퓨팅 아키텍트이다. 인상적인 다이어그램을 그리고 클라우드 서비스 업체를 만나고 적절한 보안 접근방법과 기술을 선택하고 거버넌스를 처리한다. 그리고 이 모든 것을 실제로 일할 사람에게 넘겨준다. 이렇게만 된다면 괜찮은 일이다.   많은 클라우드 아키텍트가 파워포인트를 전달하는 것으로 일이 끝났다고 생각한다. 하지만 운영 역시 파고들어야만 한다는 것이 필자가 하고 싶은 말이다. 다시 말해, 클라우드가 어떤 모습일지 뿐만 아니라 장기적으로 어떻게 운영될지도 설계해야 한다. 운영이 중요한 이유는 많다. 우선, 솔루션을 만든 사람이 솔루션 자체가 무엇이고 어떻게 왜 만들었는지를 알려주지 않으면, 아무도 클라우드 솔루션을 가장 잘 운영하는 방법을 알 수 없다. 예를 들어, 클라우드옵스는 왜 이런 종류의 클라우드 스토리지를 선택했는지, 앞으로 어떤 식으로 클라우드 스토리지를 운영할 계획인지를 알아야 한다. 세세한 정보가 빠져 있으면, 이 부분을 운영자들이 채워 넣어야 하고, 일이 잘못될 위험도 커진다. 둘째, 아키텍트가 실수할 수도 있다. 드물지 않은 일이다. 클라우드옵스 인력은 일상적인 운영을 맡으며, 아키텍트의 실수는 고스란히 이들에게 맡겨진다. 클라우드 솔루션이 지속적으로 개선되고 발전하는 것을 확실히 하기 위해서는 아키텍트가 클라우드옵스와 함께 일해야 한다. 다음 클라우드 프로젝트를 맡아야 하는 아키텍트는 어떻게 해야 하는가? 아키텍처의 일부로 운영 플레이북을 함께 제공해야 한다. 클라우드옵스 팀에게 장기적으로 클라우드 아키텍처를 어떻게 운영하기를 기대하는지, 성능이나 보안, 거버넌스 같은 문제를 어떻게 처리할 것인지, 모니터링과 관리 솔루션은 어떻게 사용할 것인지를 이야기해야 한다. 만약 이런 것들이 자신의 기술 역량과 맞지 않는다면, 교육 훈련으로 관련 역량을 갖춰야 한다는 것이 필자의 생각이다. 물론 대부분 사람은 아키텍처와 운영 간의...

아키텍트 플레이북 클라우드옵스 2019.07.01

IDG 블로그 | “너무 넓어도 좁아도 곤란” 클라우드 컴퓨팅 경력 관리의 함정

필자에게는 자신의 IT 경력을 클라우드 컴퓨팅으로 갈아엎고 싶은 사람이 많이 찾아온다. 보통은 좋은 시도이지만, 클라우드 컴퓨팅 세상이 점점 복잡해지면서 더 높은 연봉의 클라우드 일자리를 찾는 사람들이 잘못 짚기도 한다. 가장 보편적인 것 두 가지를 살펴보자.    실수 1. 너무 넓게 간다 필자는 종종 만능 플레이어의 이점을 설명하고는 했다. 그리고 클라우드 컴퓨팅 아키텍트가 되기 위해 일부를 마스터하는 것도 좋다고 했다. 이들이 클라우드 기술을 이해하고 최적의 솔루션을 선택해 기초적인 클라우드 아키텍처를 세우는 사람이다. 문제는 대부분 사람이 모든 것의 일부를 이해할 수 있지만, 이들을 어리석은 실수로부터 구해 줄 더 깊은 지식은 부족할 때이다. 예를 들어, 잘못된 아키텍처 때문에 지연 문제가 생겼을 때, 원인을 추적해 들어가면 네트워킹을 알지 못하는 클라우드 아키텍트일 때가 있다. 아니면 보안 지식이 부족해 클라우드 아키텍처가 보안을 침해하거나 데이터 통합과 관련한 잘못된 선택이 원인일 때도 있다. 많은 아키텍트가 자신의 역량을 과장해 내세우며 모든 것을 충분히 심도 있는 수준으로 고려하는 것처럼 이야기한다. 이들은 보통 시간이 지나면서 확보한 기술일 뿐이다. 게다가 이들은 클라우드 아키텍처가 여전히 레거시 시스템과 데이터센터, 심지어 하드웨어까지 다뤄야 한다는 것을 잊어버린다. 생산성이 있을 만큼 충분한 수준으로 전체를 이해하지 못한다면, 이 일을 잘할 가능성은 크지 않다.   실수 2. 너무 좁게 간다 IT에서 전문성은 많은 것의 핵심이며, 클라우드 일자리 시장도 예외는 아니다. 대학에서 이수한 일부 IaaS 강좌는 AWS 자격증만큼의 가치는 없다. 하지만 어떤 사람은 이런 전문성을 너무 극한으로 밀고가 특정 클라우드 서비스 업체의 특정 서비스에 전념하기도 한다. 이들의 성공은 바로 그 서비스 하나의 성공이나 실패에 의해 좌우된다. 그렇지 않을 것 같지만, 이런 서비스 역시 라이프사이클이 있다. 초기 단계에서 확장...

경력 일자리 아키텍트 2019.04.19

알아 두면 좋은 비주류 자바스크립트 툴 6가지

JS 파운데이션(JS Foundation)은 오픈소스 자바스크립트 프로젝트의 본거지로 무엇보다 제이쿼리(jQuery)와 자바스크립트 라이브러리로 유명하다. 그러나 클라우드 프로비저닝, 사물 인터넷(IoT), 결제, Node.js 프로그래밍과 같은 다양한 용도로 개발자에게 도움이 되는 잘 알려지지 않은 다른 툴도 많다. 알아 두어야 할 6가지 비주류 툴을 소개한다. 아키텍트(Architect, .arc) .arc로도 알려진 아키텍트 프로젝트는 클라우드 인프라를 위한 일반 텍스트 매니페스트를 제공하여 개발자가 아마존 웹 서비스의 비즈니스 로직에 집중할 수 있게 해준다. 개발자는 아키텍트를 사용해서 AWS 람다(Lambda) 클라우드 서비스에서 실행할 애플리케이션을 설정할 수 있다. 아키텍트의 목적은 개발자가 신속하게 서버리스 컴퓨팅을 준비하고 프로비저닝할 수 있도록 하는 것이다. 아키텍트 매니페스트에서 로컬 코드를 생성하고 클라우드 인프라를 구성해 프로비저닝하기 위해 아키텍트와 함께 NPX 패키지 러너가 사용된다. 현재 자바스크립트 프로그램에서 작동하지만 향후 파이썬 및 고 프로그램과도 호환될 가능성이 있으며, 마이크로소프트 애저와 같은 다른 클라우드에서도 사용 가능하도록 확장될 여지도 있다. 아키텍트는 NPM을 통해 다운로드할 수 있다. npm I @architect/workflows Interledger.js Interledger.js는 디지털 지갑과 국가 결제 시스템, 블록체인에 이르기까지 모든 유형의 원장(ledger) 간 대금 송금을 위한 W3C 인터레저(Interledger) 프로토콜 스택의 자바스크립트 레퍼런스 구현물이다. 목적은 위치 또는 통화와 관계없이 비즈니스 거래를 용이하게 하는 데 있다. 인터레저와 함께 원장 간 대금을 보내기 위해 커넥터가 사용된다. 해시 시간 잠금 계약(HTLC) 조건부 전송을 사용하는 조건부 전송이 멀티홉 송금을 보호해서 대금 손실 또는 도난을 방지한다. Interledge...

결제 자바스크립트 아키텍트 2018.10.10

전통 IT에서 클라우드로 경력을 전환하는 방법

엔터프라이즈 아키텍트, 개발자, 네트워크 엔지니어 등 전통적인 IT 기술을 보유한 인력 사이에서 클라우드 컴퓨팅 분야로의 방향 전환에 대한 관심이 뜨겁다. 고용도 안정적이고 연봉도 더 높기 때문이다. 그러나 이 중에서는 고급 클라우드 컴퓨팅 인력이 되는 방법을 정확히 모르는 사람이 많다. 반가운 소식은 많은 IT 전문가에게 클라우드를 향한 길이 존재한다는 것이다. 엔터프라이즈 아키텍트, 데이터베이스 관리자, 애플리케이션 개발자, 시스템 관리자, 테스트 엔지니어 또는 네트워크 엔지니어라면, 여기서 현재 직업에서 클라우드 분야로 진출하는 방법을 알아볼 수 있을 것이다. 엔터프라이즈 아키텍트 엔터프라이즈 아키텍트의 역할은 기술 및 플랫폼 측면에서 상당히 포괄적이지만 클라우드로의 전환을 모색하는 기업이 채용하는 인재는 구체적인, 특정 기술을 갖춘 인재다. 아래 경력 지도를 살펴보자. 두 가지 아주 좋은 길이 있다. 퍼블릭 클라우드 솔루션 아키텍트와 클라우드 보안 아키텍트이다. 다양한 유형의 기술을 신속하게 익히는 데 능숙한 실력 있는 엔터프라이즈 아키텍트라면 아주 약간의 교육만으로 이 두 가지 역할로 전환이 가능하다. 다만 이러한 아키텍처 기술은 대체로 클라우드 기반 IT 기업이 요구하는 구체성 측면에서 부족한 면이 있다. 이들 기업은 대부분 아마존 웹 서비스, 구글, 마이크로소프트와 같은 특정 클라우드 브랜드에 익숙한 주제 전문가(SME)를 찾는다. 따라서 현재 IT 아키텍처나 보안 분야에서 상당히 포괄적인 역할을 맡고 있다면 지금부터 보안 서비스를 포함한 특정 클라우드 서비스의 솔루션 기반 사용을 집중적으로 익혀야 한다. 엔터프라이즈 아키텍트에게 다소 부자연스럽게 느껴지는 일이지만 더 높은 연봉과 고용 안정성을 원한다면 필요한 일이다. 데이터베이스 관리자 데이터베이스 관리자를 위한 길은 명료하다. 기본적으로 클라우드 기반 워크로드에 많이 사용되는 데이터베이스를 파악한 다음 자신의 기술을 그 특정 데이터베이스에 맞추면...

경력 엔지니어 전환 2017.08.17

확장형 시스템에서 성능을 저하시키는 9가지 문제

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

성능 설계 쿼리 2017.07.31

IDG 블로그 | 2017년에 가장 인기높은 클라우드 일자리

클라우드 일자리는 IT 업계에서도 가장 수요가 많고 높은 보수를 받으며 안정적이다.  필자가 최근 가장 많이 받는 질문은 바로 '올해 최고의 클라우드 직업은 무엇인가'다. 그 다음 질문이 어떤 클라우드 일자리가 연봉이 가장 높은가다. 질문은 다르지만 대답은 하나로 끝낼 수 있다. 다음과 같은 3개의 일자리가 있는데, 수요, 연봉, 고용 안정성 면에서 가장 좋다고 말할 수 있다. 1. 클라우드 아키텍트(Cloud architect) 항상 수요가 넘치는 이 일자리는 기존 애플리케이션들과 데이터 셋을 포함한 기업 요구 사항을 충족시키고 기업의 요구사항에 적합한 퍼블릭, 또는 프라이빗 클라우드 기술을 찾는 직업이다. 이 직업을 수행하려면 우선 클라우드 기술에 대해 많이 알아야 하며 클라우드 기술이 호스팅되는 워크로드 요구를 충족하도록 클라우드 기술을 구성하는 방법에 대해서도 많이 알아야 한다. 이런 일을 할 수 있는 전문가는 많지 않기 때문에 수요는 항상 넘치며 연봉은 높다. 2. 클라우드 빅데이터 스페셜리스트(Cloud big data specialist) 클라우드 아키텍트가 많은 기술을 알고 있는 것이라면 클라우드 빅데이터 스페셜리스트는 특정 기술에 대해 많은 것을 알고 있는 사람이다. 이들은 빅데이터에 대해 많이 알고 있는데, 특히 클라우드에서 빅데이터를 구현하는 방법에 대해 많이 알고 있는 이들이다. 이들은 구글과 마이크로소프트 애저에서 사용되는 빅데이터 기술과 같은 AWS 레드시프트(AWS RedShift)와 AWS EMR(Elastic MapReduce)에 대해 알고 있다. 이 일자리의 핵심 기준은 빅데이터의 기본 사항을 이해하는 것뿐만 아니라 올바른 정보와 기술을 보유하고 있는 것이다. 3. 클라우드 데이터 통합 스페셜리스트(Cloud data-integration specialist) 클라우드 데이터 통합 스페셜리스트는 클라우드 데이터와 온프레미스 데이터를 통합하는 방법뿐만 아니라 클라우드와...

데이터통합 일자리 아키텍트 2017.01.18

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

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

Copyright © 2022 International Data Group. All rights reserved.