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.

네이티브

M1 맥에서 유니버셜 앱을 인텔 버전으로 실행하는 방법

애플은 M1 프로세서(애플 실리콘 1세대)를 사용하는 첫 맥을 내놓으면서 맥에서 앱을 실행하는 완전히 새로운 아키텍처를 함께 공개했다. 이 새로운 칩 속도를 최대한 활용하려면 인텔 소프트웨어를 이 아키텍처에 맞춰 M1 프로세서에 맞게 수정해야 한다. 그러나 개발자가 '네이티브' 코드로 앱을 수정하는 데는 시간이 걸리기 때문에 애플은 로제타 2(Rosetta 2)라고 불리는 전환 툴을 만들었다. 이를 이용하면 기존 인텔 맥에서 작동하도록 개발한 인텔 기반 소프트웨어를 애플 실리콘에서도 실행할 수 있다. 현재 M1 맥을 갖고 있다면 (사용자가 알든 알지 못하든) 이미 로제타를 사용하고 있을 것이다. 로제타가 필요한 앱을 처음 실행하면 로제타가 필요하다는 경고창이 나타나고 로제타 설치 승인을 요청한다. 한번 로제타를 설치하면 로제타가 필요한 앱이 있을 때 자동으로 실행된다. M1 앱도 마찬가지다. 네이티브 앱이 있으면 맥이 자동으로 이 버전을 실행한다. 하지만 문제가 되는 경우가 있다. 인텔 맥과 애플 실리콘 맥 모두에서 사용할 수 있도록 설계된 유니버설 앱을 가지고 있는데, M1 버전 대신 인텔 버전 앱을 실행해야 할 때다. M1 앱에서 아직 필요로 하는 기능을 지원하지 않거나, 서드파티 플러그인이나 확장기능을 사용하고 있는데 인텔 맥에서만 작동하는 경우가 대표적이다. 이럴 때는 유니버설 앱을 로제타를 이용해 실행하도록 강제해야 한다. 필요에 따라 자연스럽게 전환하는 것도 가능할 것이다. 방법은 다음과 같다.   애플리케이션 폴더에서 필요한 앱을 찾는다. 앱을 선택한 후 Command-I 또는 마우스 오른쪽 클릭한 후 '정보 가져오기'를 선택한다. 앱에 대한 자세한 정보가 표시된 창이 나타날 것이다. 이 정보 창에서 '로제타를 이용해 열기' 체크박스를 찾아 체크한다. 정보 창을 닫는다. 이미 앱을 실행하고 있었다면 종료한 후 다시 실행한다.   이제 앱을 실행할 때마다 맥이 인텔 버전 소프트웨어를 실행하게  된다...

유니버셜 네이티브 M1 2021.03.12

IDG 블로그 | 서비스 업체가 알려주지 않는 클라우드 아키텍처의 비밀 3가지

클라우드 컴퓨팅 솔루션의 적절한 구성에 관해 모든 것을 안다고 생각할지 모르지만, 클라우드 서비스 업체는 자신들을 위해 몇 가지는 숨겨놓고 있다. 클라우드 아키텍처를 최적화했는가? 이는 클라우드 솔루션의 효율을 극대화하고 비용은 최소화했다는 의미이다. 최상의 스토리지 시스템과 데이터베이스, 컴퓨트 플랫폼을 구성하기 위해 가장 잘 맞는 클라우드 자원을 선택했을 것이다. 최소한 자신이 생각하기에는 그럴 것이다.   하지만 필자는 잘못된 이유로 잘못된 클라우드 자원을 선택한 사례를 여전히 보고 있다. 그리고 클라우드 서비스 업체는 기업 사용자에게 잘 맞는 것보다는 자사의 매출을 극대화하고자 한다.  여기서 소개하는 3가지 클라우드 아키텍처의 비밀은 클라우드 서비스 업체에서는 절대 들을 수 없는 것이다. 비밀 1. 가끔은 비 네이티브 자원이 네이티브 자원보다 좋다. 네이티브 데이터베이스와 클라우드옵스 시스템, 보안 시스템을 단일 퍼블릭 클라우드 서비스의 일부로 이용하는 것이 좋다는 말을 들었을 것이다. 그러나 지금은 대부분 멀티클라우드 세계로 이전하고 있어서 반드시 그렇지는 않다.  한 퍼블릭 클라우드에서만 좋은 네이티브 솔루션 대신 여러 퍼블릭 클라우드에서 사용할 수 있는 범용 이기종 솔루션을 고르는 것이 더 좋다. 퍼블릭 클라우드 서비스 업체가 제시하는 아키텍처 가이드에서는 본 적이 없을 것이다. 비 네이티브 자원도 매번, 그리고 항상 고려해야 한다. 비밀 2. 데이터를 클라우드에 저장하라. 데이터의 이입과 반출이 잦은 클라우드 솔루션은 대부분 좋은 생각이 아니다. 어렵게 생각할 것도 없이, 데이터가 퍼블릭 클라우드 서비스 업체로 들어가고 나오는 것이 월 클라우드 사용료에 그대로 반영되며, 결코 싸지 않다. 하지만 코어 아키텍처를 고려할 때 이런 점을 흔히 간과한다.  일부 데이터를 온프레미스에 저장하고자 하는 IT 부서 때문에 생기는 문제로, 보통은 컴플라이언스와 보안에 대한 철 지난 우려가 그 이유이다. 서비스...

멀티클라우드 비밀 복잡성 2020.10.06

IDG 블로그 | 클라우드 서비스 업체는 잘 알려주지 않는 클라우드 보안의 비밀

클라우드 보안은 클라우드 서비스 업체에 특화된 무엇처럼 보인다. 하지만 새로이 부상하는 접근법과 기술은 게임의 판도를 바꾸고 있다. 클라우드 보안 솔루션 설계를 맡은 대부분 클라우드 보안 아키텍트가 제일 먼저 묻는 것은 사용하는 클라우드이다. 그리고는 IAM이나 암호화 같은 몇 가지 기술을 선택하는데, 보통 특정 클라우드 브랜드의 네이티브 솔루션이다.   몇 년 전만 해도 건전한 접근법이었다. 하지만 지금 우리는 보안이 위험뿐만 아니라 복잡성도 제거해야 하는 멀티클라우드 세상에 살고 있다. 퍼블릭 클라우드 서비스 업체가 말해주지 않는 세 가지 클라우드 보안의 비밀을 소개한다. 대형 서비스 업체가 제공하는 클라우드 네이티브 보안 솔루션은 이기종 멀티클라우드 솔루션에는 도움이 되지 않는다. 이들 보안 기술은 특정 클라우드 서비스 업체의 자체 서비스에서는 대단히 잘 동작할지 몰라도 다른 퍼블릭 클라우드, 그리고 우리 대부분이 사용하는 멀티클라우드는 지원하지 않거나 제한적으로 지원한다. 두 가지 중 하나를 선택할 수 있다. 각 퍼블릭 클라우드의 네이티브 시스템을 이용한다면, 두 가지 이상의 보안 시스템을 관리해야 한다. 아니면 공통 보안 솔루션을 이용해야 한다. 공통 보안 솔루션은 각 클라우드 서비스 업체의 서로 다른 보안 문제를 다룰 수 있고, 그것 자체로 위험이 될 수 있는 복잡성으로부터 사용자를 구제해 준다. 필자라면 두 번째를 선택할 것이고, 대부분 기업에서 매우 잘 동작한다. 보안은 애플리케이션과 데이터 스토리지에 제대로 구현하지 않으면 성능에 장애가 되고 매월 더 많은 비용이 들 수 있다. 클라우드 서비스 업체는 컴퓨트와 스토리지 서비스를 판매해 수익을 얻다. 만약 보안 솔루션이 필요 이상으로 많은 CPU 자원을 먹어 치운다면, 보안 솔루션 자체와 애플리케이션이 보안 솔루션을 사용하는 방법을 다시 설계해야 한다. 필자는 보안과 애플리케이션 튜닝으로 한 달 사용료를 80%까지 절감한 사례도 알고 있다. 이들 애플리케이션의 성능도 4배나 ...

네이티브 클라우드보안 멀티클라우드 2020.04.20

IDG 블로그 | 우리가 몰랐던 멀티클라우드 보안의 3가지 복병

보안은 보안일 뿐이라고 생각할지 모른다. 하지만 멀티클라우드는 온프레미스나 네이티브 퍼블릭 클라우드와는 다른 접근법과 메커니즘을 배워야 한다.   불과 몇 년 전에 한 퍼블릭 클라우드 서비스 업체에 맞춰 보안 계획을 세우고 물리 보안 기술을 구축한 사람이라면, 같은 방식을 수많은 클라우드, 즉 멀티클라우드에 그대로 적용할 수 있다고 생각하지 않기를 바란다. 그렇게 동작하지 않는다. 최근 멀티클라우드 배치와 운영에서 흔히 보는 보안 실책은 보안 아키텍처와 구현 기술을 선택하고 배치하는 과정에서 발생한다. 필자는 이들 실책으로부터 3조각으로 이루어진 멀티클라우드 보안 배치에 관한 조언을 편집해 냈다. 우선 보안에 대한 전통적인 접근법은 먹히지 않는다. 역할 기반의 전통적인 보안 접근법으로 기업 환경에서 성공했다 해도 멀티클라우드에서는 같은 결과를 얻을 수 없다. 멀티클라우드가 가져오는 복잡성을 처리해야만 하고, 보안 역시 이런 복잡성을 고려해 구성해야만 한다. 유휴 및 작업 중 암호화를 모두 지원하는 좋은 암호화 시스템과 결합한 IAM(Identity Access Management)이 훨씬 더 좋은 선택이 될 것이다. 둘째, 클라우드 네이티브 보안은 사용할 수 없다. AWS나 애저, GCP가 제공하는 보안이 네이티브 플랫폼에서는 정말 괜찮지만, 경쟁업체의 플랫폼도 보호하도록 만들어진 것이 아니다. 필자는 여전히 클라우드 네이티브 보안 플랫폼을 중앙집중화된 보안 관리자로 사용하고는 바로 실패하는 기업 사용자를 만나곤 한다. 멀티클라우드의 과제는 수많은 공통 서비스(보안, 거버넌스, 관리, 모니터링 등)를 멀티클라우드 배치 내에서 모든 클라우드 브랜드에 걸쳐 공통 서비스로 관리해야 한다는 것이다. 이를 위해서는 서로 다른 퍼블릭 클라우드 브랜드를 아우를 수 있으면서, IAM 같은 현대적인 기능을 제공하는 서드파티 보안 시스템이 필요하다. 마지막으로, 생각보다 책임져야 할 것이 많다. 퍼블릭 클라우드 환경에서도 서비스 업체는 일부 기본적인 보안을...

암호화 IAM 네이티브 2020.03.23

IDG 블로그 | “네이티브 vs. 연합” 멀티클라우드 아키텍처 논쟁

여러 가지 이유로 멀티클라우드가 새로운 표준이 된 사실을 눈치채지 못하는 사람도 있겠지만, 현실은 록인을 피하고 동급 최강의 클라우드 서비스를 고르는 방식을 놓고 논쟁이 일어나고 있다. 자주 언급했듯이 멀티클라우드는 복잡성을 가져오고 복잡한 아키텍처를 운영해야 하는 과제를 안게 된다. 많은 기업이 이들 배치 환경을 운영, 즉 클라우드옵스로 이전할 수 있으며, 일종의 클라우드 컴퓨팅 중간 지대에 갇혀 있는 기업도 있다.   하기 좋은 대답은 처음부터 계획을 잘 세웠어야 한다는 것이지만, 기업이 듣고 싶은 대답도 아닐 뿐만 아니라 온당한 평가도 아니다. 무엇보다 생산적인 대답이 아니다. 이들 기업은 멀티클라우드 아키텍처와 함께 앞으로 나아가야 하고, 주된 비즈니스 문제를 해결하는 것은 물론, 운영을 무너뜨리지 않을 최적화된 멀티클라우드 아키텍처로 가는 길을 찾아야 한다. 후보 아키텍처를 살펴보자. 이기종 클라우드 네이티브(Heterogeneous Cloud Native) 아키텍처. 동급 최강의 개별 클라우드 컴퓨팅 배치라는 임무에서 IT 책임자는 자신의 느낌과 관계없이 그 분야 최고의 기술을 고른다. 이 아키텍처는 수많은 클라우드 네이티브 서비스를 서로 다른 퍼블릭 클라우드 서비스로부터 사용하는 것으로 구성되며, 이런 식으로는 정말로 문제가 생긴다. 클라우드 네이티브 환경이 바람직하지 않다는 말은 아니다. 클라우드 네이티브를 잘못된 방식으로 구현하고 있다는 것이다. 문제는 네이티브 클라우드 서비스를 넘어서는 공통의 서비스가 거의 또는 전혀 없다는 데 있다. 10가지 서로 다른 보안 솔루션, 여러 가지 거버넌스 툴, 그리고 10가지가 넘는 관리 및 모니터링 솔루션을 사용해야 한다. 이 모두를 한꺼번에 실행하고 어떤 일이 생기는지 보라. 이기종 페더레이션(Heterogeneous Federated) 아키텍처. 클라우드 컴퓨팅용으로는 오래된 재탕 아키텍처 패턴처럼 보이지만, 사실은 꽤 새로운 방식이다. 이 아키텍처는 컨테이너와 컨테이너 클러스터를 ...

아키텍처 페더레이션 네이티브 2020.03.02

클라우드 시대의 애플리케이션 현대화 3대 원칙

클라우드 기술 도입은 비즈니스 디지털 혁신을 뒷받침하는 핵심 원동력 중 하나입니다. 그러나 안타깝게도 통합 전략이 부재한 상태에서 클라우드를 도입하는 기업들이 점점 많아지고 있습니다. 또한 비즈니스 부서가 IT 부서와 상의없이 퍼블릭 클라우드 서비스를 독자적으로 배치하는 "섀도 IT "의 그림자에 시달리는 기업도 많이 있습니다. 두 경우 모두 기존 인프라와 신규 인프라의 밀접한 통합 부족과 무계획적인 보안 준비 태세라는 결과를 초래합니다. 또한 기업이 특정 공급업체에 종속되어 지속적으로 재무 비효율성이 발생할 수 있습니다.  이러한 위험에서 벗어나기 위해, 기업은 클라우드 패러다임의 모든 이점을 제공하는 애플리케이션 현대화를 위해 3대원칙을 수립해야 합니다. <7p> 주요 내용 - 클라우드 소프트웨어 현대화를 뒷받침하는 원칙 - 클라우드 친화적인 기존 애플리케이션 및 신규 애플리케이션 - 기업 내부를 넘어서는 통합 확대 - 변화하는 비즈니스 요구사항 충족을 위한 적응성 및 확장성 - 첨단 클라우드 아키텍처를 위한 종합 플랫폼

애플리케이션 확장성 네이티브 2020.02.13

IDG 블로그 | 데이터 통합, 네이티브냐 아니냐 그것이 문제로다

데이터 통합 솔루션은 세 가지 범주로 나눌 수 있다.  첫째, 구식 데이터 통합 솔루션으로, 1990년대 EAI(Enterprise Application Integration) 운동에서 탄생한 것이다. 현재는 퍼블릭 클라우드 컴퓨팅 영역을 포함하도록 확장되어 있다.    둘째, 좀 더 새로운 클라우드 기반 iPaaS((integration Platforms as a Service) 솔루션이다. 개방된 인터넷 상에서 호스팅되는 온디맨드 통합 서버로 새로 개발된 것이지만, 클라우드 서비스 업체 영역 밖에 존재한다.  셋째, 퍼블릭 클라우드 내에 존재하는 데이터 통합 솔루션으로, 보통은 좀 더 원시적이다. 하지만 이들은 네이티브 서비스라는 장점이 있어 퍼블릭 클라우드 서비스 업체 내에서 쉽게 배치할 수 있다. 어떤 것을 사용해야 할까? 구식 데이터 통합 솔루션은 보통 클라우드 컴퓨팅용으로는 바람직하지 않다. 클라우드 기반 통합이 후순위인 경우가 많기 때문이다. 다시 말해 이들 솔루션 중 많은 수가 이미 설치되어 있는 상태이고, 엄청난 비용과 위험을 감수하지 않고는 밀어내기 어렵다. 필자의 일반적인 조언은 이들 솔루션은 예상대로 동작하는 한 원래대로 두는 것이다. 온프레미스 환경에 초점을 맞추고 있기 때문에 퍼블릭 클라우드 기반 애플리케이션이나 데이터 저장소와의 통합용으로는 바람직하지 않지만, iPaaS나 클라우드 네이티브 데이터 통합 솔루션으로 교체하는 것은 비용 효율적이지 않다. iPaaS 솔루션은 퍼블릭 클라우드의 데이터 통합을 염두에 두고 만들어진 것이다. 하지만 온프레미스와 전통적인 데이터 통합도 다룰 수 있다. 등장한 지 10년 정도된 솔루션으로, 온프레미스 시스템을 포함하는 하이브리드 또는 멀티클라우드용으로 만들어졌다. 이 솔루션의 대부분 요소는 클라우드이건 아니건 데이터 통합용으로는 안성맞춤이다. 온디맨드 방식이라는 것은 하드웨어나 소프트웨어 환경 구성을 하지 않아도 되고, 소프트웨어는 자동으로 업데이...

데이터통합 네이티브 iPaaS 2019.11.13

IDG 블로그 | 엔터프라이즈 데이터베이스를 클라우드로 옮기기

데이터베이스는 자동차와 비슷하다. 모두가 뒤돌아볼 만한 빈티지 자동차를 몰고 다닌다고 생각해 보자. 아마도 처음 이 자동차가 만들어진 1970년대와 비교해 유지 비용이 20배는 더 들 것이다. 물론 새로운 자동차도 있을 것이다. 이 자동차는 엄청나게 매력적이지는 않지만, 30년 된 자동차보다는 더 빠르고 주행거리도 길고 최신 기술도 적용되어 있다.   많은 데이터 세트가 클라우드로 재배치되고 있다. 그리고 이제는 이렇게 워크로드와 데이터를 이전하는 것으로 비용을 물어야 하는 데이터베이스는 적절한 옵션을 고려해야 한다. 첫 번째 옵션은 자체 엔터프라이즈 데이터베이스 라이선스를 퍼블릭 클라우드 서비스 업체로 옮기는 것이다. 이른바 BYOL(Bring Your Own License)이다. 가장 저항이 적은 방안으로, 기업이 해야 할 것은 A 데이터베이스의 데이터를 다른 플랫폼에서 호스팅하는 A 데이터베이스로 옮기는 것뿐이다. 단지 새 플랫폼이 퍼블릭 클라우드일 뿐이다. 가장 간단한 방법이지만, 가장 저렴하지는 않다. 매년 라이선스비를 지불해야 하지만, 이 데이터베이스에는 클라우드 네이티브 데이터베이스가 제공하는 기능이나 성능을 제공하지 않을 것이다.  기업의 요구사항에 따라 다르겠지만, 일반적으로 클라우드 네이티브 데이터베이스는 클라우드에 데이터를 재배치하는 더 나은 방법으로 평가된다. 단점이라면, 데이터를 새로운 네이티브 스토리지 모델에 맞춰 재구성해야 한다는 것. 물론 이 데이터베이스에 액세스하는 애플리케이션도 수정해야 한다. 물론 필자라면 어떤 식으로든 클라우드 네이티브 서비스를 이용할 수 있도록 애플리케이션을 리팩터링하는 것이다. 새 클라우드 네이티브 데이터베이스에 맞춰 리팩터링해야 할지도 모른다. 이 방식은 일부 기업에는 너무 높은 진입 장벽이 될 수 있지만, 최종적으로 더 성능이 좋고 더 많은 기능을 제공하고 사용하는 데 드는 비용도 더 저렴한, 그리고 무엇보다도 기업의 특별한 사용례에 맞춰 구축한 애플리케이션과 데이터베이스를...

데이터베이스 마이그레이션 라이선스 2019.08.14

IDG 블로그 | 서버리스 컴퓨팅의 어두운 뒷면 : 제한적인 이식성

라이트스케일(Rightscale)의 2018년 클라우드 현황 보고서에 따르면, 서버리스 컴퓨팅은 가장 급성장한 클라우드 서비스로, 약 75%의 성장률을 기록했다. 이는 많은 기업이 서버리스 시스템을 사용하는 편리함을 선호한다는 것을 의미한다. 하지만 단점은 퍼블릭 클라우드의 서버리스 시스템에 구축한 애플리케이션은 쉽게 다른 클라우드로 옮길 수 없다는 것이다. 왜 이럴까? 서버리스 개발 플랫폼이 기업의 서버리스 코드를 호출하는 방식은 다양할 수 있다. 그리고 이 방식은 퍼블릭 클라우드마다 다르다. 클라우드 기반 서버리스 시스템에서 애플리케이션을 개발하는 대부분 개발자는 자신이 작성한 코드를 퍼블릭 클라우드 서비스 업체의 네이티브 API와 밀접하게 연동한다. 이런 작업 방식은 한 번 사용한 코드를 다른 플랫폼으로 이전하는 것을 어렵게, 혹은 불가능하게 만든다. 요점은 클라우드 네이티브 서버리스 시스템 상에 애플리케이션을 구축하면, 다른 클라우드 서비스 업체나 다시 온프레미스 시스템으로 옮기는 것은 모두 어렵다. 서버리스 시스템 사용이 어렵다는 말이 아니다. 서버리스 시스템은 매우 편하다. 하지만 점점 더 많은 기업이 클라우드 서비스 업체와 애플리케이션 개발 및 배치 플랫폼을 고를 때 가장 빠르고 저렴하고 편리한 곳을 선호하면서 이식성을 요구한다. 이 경우 이식성은 저주받을 것이 된다. 물론 컨테이너 활용이 폭증하고 있고, 컨테이너의 이점 중 하나는 이식성이다. 하지만 여기에는 추가 작업이 필요하며, 효율성을 염두에 둔 컨테이너 아키텍처를 이용해 구축해야 한다. 다시 말해, 대부분 개발자가 이식성이라는 이점을 보고 컨테이너를 선택하지만, 실제로는 원래 플랫폼 외에 다른 어떤 곳으로도 절대 옮기지 않는다. 이 모든 것이 의미하는 것은 다음과 같이 정리할 수 있다. - 대부분 기업에서 편의성과 속도, 즉 더 빠른 배치 사이클과 더 낮은 비용이 이식성을 이겼다. 새로울 것 없는 일이다. 과거 시장을 선도했던 모든 독점 데이터베이스와 프로그래밍 언어, 플랫폼...

컨테이너 네이티브 서버리스 2019.01.30

클라우드 마이그레이션에서 절대 피해야 할 실수 3가지

요즘 대부분 기업 IT 부서가 워크로드를 퍼블릭 클라우드로 이전하느라 바쁜 시간을 보내고 있다. 비록 애널리스트들의 전망에 차이는 있지만, PaaS와 IaaS, SaaS를 모두 포함해 글로벌 2000대 기업 중에 약 20%가 마이그레이션을 한 것으로 본다. 이런 클라우드 마이그레이션 과정에서 공통된 실수가 나타나기 시작한다. 여기 필자가 본 가장 많은 실수 세 가지를 소개한다. 사실 이런 실수는 무엇을 조심해야 하는지만 알면 쉽게 피할 수 있다. 클라우드 마이그레이션 실수 1. 순수한 ‘들어 옮기기’ 실행 이른바 리프트 앤 시프트(Lift and Shift) 방식은 코드와 데이터를 퍼블릭 클라우드의 유사한 플랫폼으로 단순히 옮기는 방법으로, 보통 수정을 거의 또는 전혀 하지 않는다. 이런 접근법은 처음에는 시간과 돈을 절약해 주지만, 기업이 가야 할 곳에 도달하지 못할 수 있다. 클라우드 기반 애플리케이션은 일부 클라우드 네이티브화 작업이 필요하기 때문이다. 이런 클라우드화는 퍼블릭 클라우드 플랫폼을 최적의 방식으로 사용하는 데 필수적이다. 클라우드화해야만 클라우드 네이티브 기능의 이점을 이용해 운영 비용을 절감하고 성능을 높일 수 있다. 이런 방식의 마이그레이션이 어떻게 전개되는지는 쉽게 예측할 수 있다. 기업은 리프트 앤 시프트 방식으로 워크로드를 클라우드로 옮긴다. 그리고 1년 또는 2년 후에 이렇게 그냥 옮긴 애플리케이션의 호스팅 비용을 보고는 클라우드 네이티브 기능을 사용할 수 있도록 애플리케이션을 다시 수정한다. 그저 ‘들어다 옮기기’보다는 문전에서 적절한 작업을 하는 것이 훨씬 좋다. 클라우드 마이그레이션 실수 2. 데이터를 다루지 않는다 리프트 앤 시프트만큼이나 많이 저지르는 비슷한 실수는 마이그레이션 후 데이터베이스 관련 문제를 제대로 처리하지 않는 것이다. 비용과 관계없이 온프레미스 환경에서 사용하던 것과 동일한 데이터베이스를 선택하는 경향이 강하다. 그 결과 클...

데이터베이스 네이티브 데브옵스 2018.06.19

세력 넓혀가는 프로그레시브 웹 앱, 모바일 앱에 도전장

리프트나 트위터 같은 웹 업체는 웹 애플리케이션을 모바일 앱처럼 보기 좋고 네트워크 독립적으로 만드는 기술을 도입하고 있다. 모바일 앱은 일반적으로 사용자 경험 측면에서 웹 기반 앱을 능가하는 강점을 가지고 있다. 하지만 프로그레시브 웹 앱(Progressive Web Apps)의 등장으로 판도가 바뀌고 있다. 이 기술은 구글과 모질라가 선봉에 서 이끌고 있는데, 주요 웹 업체들로부터 인기를 얻으며 개발자 툴도 확산되고 있다. 구글 크롬 팀의 엔지니어링 관리자 애디 오스마니는 “많은 대형 업체가 웹으로 돌아오고 있는데, 마찰이 적기 때문이다”라고 말했다. 트위터의 프로그레시브 웹 앱인 트위트 라이트(Twitter Lite)는 1MB 미만의 메모리를 사용하는데, iOS 앱의 100MB나 안드로이드 앱의 23MB와 비교해 현저히 적은 용량이다. 오스마니는 클라이언트 측의 자바스크립트 앱은 데이터를 적게 사용하고 푸시 알림과 오프라인 사용을 지원한다고 설명했다. 이들 앱의 핵심은 자바스크립트 기반의 클라이언트 측 프록시인 ‘서비스 작업자(Service Worker)’로, 네트워크 상태에 관계없이 앱을 즉각 로드한다. 서비스 작업자는 브라우저에서 백그라운드 스크립트로 실행되며, 핵심 자원을 사전 캐싱하기 때문에 네트워크 의존도를 줄일 수 있다. 오스마니는 이 기술이 아직은 발전 중이라는 사실을 인정했다. 예를 들어, 애플의 사파리 브라우저는 서비스 작업자를 사용할 수 없다. 웹 개발자가 프로그레시브 웹 앱을 개발할 수 있도록 지원하는 툴도 늘어나고 있는데, 성능 감사용 오픈소스 툴인 라이트하우스(Lighthouse)가 대표적이다. 프로그레시브 웹 앱 개발용으로 사용할 수 있는 리액트(React) 자바스크립트 UI 라이브러리의 경량화된 대안인 프리액트(Preact)도 주목할만하다. HNPWA(Hacker News readers as Progressive Web Apps) 프로젝트는 관련 레...

네이티브 모바일앱 프로그레시브웹앱 2017.06.27

네이티브, HTML5, 하이브리드 모바일 앱: 장단점 분석하기

다음은 모바일 앱을 개발하는 세 가지 주요 방법이다. 각각의 스냅샷에는 간략한 설명, 가장 적합한 분야, 장단점, 관련 개발 도구가 포함되어 있다. 네이티브 앱 개발 네이티브 앱 개발에서 모바일 앱은 iOS, 안드로이드, 윈도우 폰을 비롯한 특정 모바일 플랫폼에 맞게 작성된다. 모바일 기기에 상주하며 일반적으로 플랫폼 제작사의 개발 도구를 사용해 만들어진다. 다른 플랫폼에서 코드를 재사용할 수 없다. 가장 적합한 분야… - 소비자용 앱 - 게임 - 그래픽 및 멀티미디어 집약적인 앱 장점 - 특히 게임의 경우 웹 기반 앱 또는 하이브리드 앱에 비해 일반적으로 높은 성능 - 기기의 모든 센서, 하드웨어, 연락처, 알림에 접근 가능 - 애플 앱 스토어, 구글 플레이, 윈도우 스토어와 같은 공개 앱 스토어를 통해 배포 - 설치 시 즉시 기기의 홈 스크린에 아이콘 표시 단점 - 개발자 부족 - 플랫폼별로 따로 앱을 만드는 데 따르는 비용 소비 - 플랫폼별로 별도의 코드 베이스를 관리하는 데 따르는 비용과 시간 소비 - 긴 개발 시간 - 상이한 개발 시간으로 인해 플랫폼 간 버전이 일치하지 않을 수 있음 - 각 앱 스토어의 승인 절차를 거쳐야 하므로 앱 배포 속도가 느려질 수 있음 개발 도구 - 애플 iOS: 엑스코드(XCode) - 안드로이드 : 구글 안드로이드 스튜디오(Google Angoid Studio) - 윈도우 폰: 비주얼 스튜디오(Visual Studio)HTML 5, CSS, 자바스크립트로 만들어지는 웹 앱 웹 앱은 HTML 5, CSS, 자바스크립트로 만들어진다. 모바일 기기의 브라우저를 통해 접근할 수 있고 인터랙티브한 특성을 갖는다. 연락처 목록이나 센서와 같은 모바일 기기의 기능에 접근하는 데 제약이 있다. 한 번만 만들어 웹 서버에 배포하면 된다. 가장 적합한 분야… - B2B 및 B2E 앱, 내부 회사 서비스 및 리소스 장점 - 웹 표준을 사용하여 ...

모바일 하이브리드 네이티브 2015.10.01

세일즈포스닷컴, 모바일 앱 개발 관련 신규 서비스 출시

세일즈포스닷컴이 자사 클라우드 플랫폼에서 모바일 앱을 개발할 수 있는 새로운 툴을 내놓고 파트너사와 개발자를 위한 대규모 교육행사를 개최한다. 세일즈포스닷컴은 현재 고객와 협력사에 자사 클라우드를 기반으로 모바일 앱을 개발할 수 있는 새로운 툴들과 서비스를 제공하고 있다.   대부분의 기업용 소프트웨어 업체가 그렇듯 세일즈포스닷컴 역시 사용자들이 사무실내 데스크톱 대신 세계 어느 곳에서든 스마트폰과 태블릿 혹은 다른 모바일 기기에서 업무를 처리할 수 있는 환경을 지원하기 위해 노력하고 있다. 이른바 'IT의 컨슈머라이제이션'(consumerization of IT)이라고 불리는 이러한 트렌드는 사용자들이 개인적인 용도로 사용하는 것과 비슷한 기술 경험을 직장에서도 사용하려고 하는 요구가 늘어나면서 본격화되고 있다.   반면 모바일 앱 개발은 소프트웨어 업체와 사용자 양쪽 모두에게 몇가지 문제를 안고 있었다. iOS와 안드로이드, 그리고 다른 OS 전용으로 개발하는 네이티브 앱은 HTML5 대비 강력한 성능을 제공하지만 OS 별로 각각 개발해야 하고, 반면 HTML5로 개발하면 시간과 비용을 줄일 수 있지만 성능은 상대적으로 떨어진다.   세일즈포스닷컴의 전략도 이러한 어려움을 해소하는데 맞춰져 있다. 세일즈포스닷컴의 플랫폼 마케팅 부사장 스콧 홀덴은 "세일즈포스닷컴은 모바일 앱을 빠르고 쉽게 개발하면서도 기업들이 기존의 개발 방식을 유지할 수 있도록 지원하려고 한다"고 말했다.   이를 위해 세일즈포스닷컴은 오는 6월 세일즈포스닷컴 모바일 SDK 2.0을 발표한다. 이기에는 개발자들이 HTML5, 네이티브, 하이브리드 등 어떤 형태로 개발하든 앱과 세일즈포스닷컴 CRM 시스템 같은 기업 시스템 데이터를 연동할 수 있는 기능이 추가됐다. HTML5 앱은 카메라와 같은 디바이스 자체 기능을 사용할 수 있고 보안 온라인 스토...

세일즈포스닷컴 네이티브 HTML5 2013.04.10

글로벌 컬럼 | '네이티브 vs. HTML5' 앱 개발 논란 : 두 가지 다 하면 된다

현재 모바일 애플리케이션 개발 관련해서 가장 뜨거운 이슈 중의 하나는 최적의 방법이 네이티브 개발이냐, 아니면 모바일 웹 애플리케이션이냐에 대한 것이다. 각 방법마다 장단점이 있기 때문이다.   개발자 입장에서 볼 때 개별적인 두 방법은 물론 두 가지를 섞은 혼합 애플리케이션도 장점이 있다. 어떤 애플리케이션 빌더는 앱셀러레이터 티타늄(Appcelerator Titanium) 등 자바스크립트와 같은 웹 기반 메커니즘을 네이티브 코드로 컴파일하는 개발 도구를 사용한다. 웹 기반 또는 HTML5 개발 방식을 사용하면 애플리케이션을 여러 종류의 기기용으로 신속하게 개발할 수 있다고 개발자들은 말한다. 그러나 애플 iOS용 오브젝티브-C, 구글 안드로이드 기기용 자바와 같은 네이티브 개발은 특정 기기의 기능을 세세하게 활용할 수 있게 해주고 이는 개별 플랫폼마다 독립적으로 코드를 개발해야 하는(기반 로직은 아니지만) 비용을 상쇄할 만한 가치를 제공하는 경우가 많다.   네이티브 환경이 가장 앞선다 홈즈닷컴(Homes.com)의 모바일 개발 관리자인 제시 뉴커머는 “웹과 HTML5도 많이 발전했지만 UI, 멀티 터치, 애플리케이션에서 사용자가 기대하는 요소라는 측면에서 아직 네이티브 환경 수준에는 이르지 못했다”고 말한다. 개인 개발자인 케탄 마지무다르도 네이티브 애플리케이션과 비교할 때 모바일 웹 애플리케이션의 문제는 오프라인 관련 특성이라고 말한다. 애플리케이션은 온라인 웹 서비스와 통신해 데이터를 가져오거나 그게 아니라면 데이터 저장소가 앱과 함께 지원해야 한다. 마지무다르는 “기술로서 HTML5는 아직 성숙한 단계가 아니다"며 "거의 그 수준에 이르긴 했지만 데이터 다운로드와 같이 풀어야 할 문제가 많다”고 말했다. 반면 네이티브 애플리케이션은 다운로드할 때 이미 데이터가 안에 포함되어 있다. 즉, 필요한 데이터의...

자바스크립트 네이티브 HTML5 2012.11.06

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

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

Copyright © 2022 International Data Group. All rights reserved.