Offcanvas

���������

"도구, 통합, 거버넌스, 인사이트" AWS 리인벤트 2022, 데이터 관리 및 분석 서비스에 주안점

올해 아마존 리인벤트(re:Invent) 행사의 주안점은 단연 데이터였다. 아마존은 ETL 프로세스 간소화를 위한 일련의 통합 기능을 발표했다. 이에 더해 데이터를 쉽게 카탈로그화하고 검색할 수 있도록 돕는 새 서비스와 기능을 여럿 공개했다.    AWS CEO 아담 셀립스키는 데이터 관리에는 알맞은 도구(Right Tools), 통합(Integration), 거버넌스(Governance), 그리고 인사이트(Insights) 4가지 영역이 가장 중요하다고 말했다.  그는 제일 먼저 알맞은 도구와 매끄러운 통합의 중요성에 대해 말하며 이제 ETL 작업 없이(zero-ETL) 아마존 레드시프트(Amazon RedShift)를 사용해 아마존 오로라(Amazon Aurora) 데이터를 거의 실시간으로 분석할 수 있다고 밝혔다.  이에 더해 AWS는 이제 아마존 레드시프트 데이터로 아파치 스파크(Apache Spark) 애플리케이션을 쉽게 실행할 수 있다고 발표했다.  ETL이란 데이터를 데이터베이스에서 데이터웨어하우스로 옮기기 위해 해야 하는 작업인데, 많은 엔지니어가 번거롭게 여긴다. 미가공 데이터(raw data)를 일일이 클렌징해야 함은 물론 필터링하고, 재정렬하고, 축약해야 하기 때문이다.  AWS는 많은 기업이 데이터를 분석하기 위해 데이터 파이프라인을 준비하는 팀을 별도로 유지해야 하기에 여기에 들어가는 추가 비용도 큰 문제라고 지적했다.    ETL 없는 시대를 향해  AWS는 아마존 오로라와 레드시프트의 제로 ETL 통합으로 오로라에 기록되는 트랜잭션 데이터가 거의 즉시 레드시프트에 복제돼 분석될 수 있다고 설명했다.  셀립스키는 “기업 고객은 여러 아마존 오로라 데이터베이스 클러스터의 데이터를 하나의 아마존 레드시프트 인스턴스로 복제해 여러 애플리케이션에서 인사이트를 손쉽게 얻을 수 있다”라고 말했다. 이 통합 기능은 현재 프리뷰 형태로 제공된다....

아마존 AWS AWS 오로라 아마존오로라 레드시프트 아마존 레드시프트 데이터웨어하우스 서비스 퀵사이트 아마존퀵사이트 아마존데이터존 아마존클린룸

2일 전

올해 아마존 리인벤트(re:Invent) 행사의 주안점은 단연 데이터였다. 아마존은 ETL 프로세스 간소화를 위한 일련의 통합 기능을 발표했다. 이에 더해 데이터를 쉽게 카탈로그화하고 검색할 수 있도록 돕는 새 서비스와 기능을 여럿 공개했다.    AWS CEO 아담 셀립스키는 데이터 관리에는 알맞은 도구(Right Tools), 통합(Integration), 거버넌스(Governance), 그리고 인사이트(Insights) 4가지 영역이 가장 중요하다고 말했다.  그는 제일 먼저 알맞은 도구와 매끄러운 통합의 중요성에 대해 말하며 이제 ETL 작업 없이(zero-ETL) 아마존 레드시프트(Amazon RedShift)를 사용해 아마존 오로라(Amazon Aurora) 데이터를 거의 실시간으로 분석할 수 있다고 밝혔다.  이에 더해 AWS는 이제 아마존 레드시프트 데이터로 아파치 스파크(Apache Spark) 애플리케이션을 쉽게 실행할 수 있다고 발표했다.  ETL이란 데이터를 데이터베이스에서 데이터웨어하우스로 옮기기 위해 해야 하는 작업인데, 많은 엔지니어가 번거롭게 여긴다. 미가공 데이터(raw data)를 일일이 클렌징해야 함은 물론 필터링하고, 재정렬하고, 축약해야 하기 때문이다.  AWS는 많은 기업이 데이터를 분석하기 위해 데이터 파이프라인을 준비하는 팀을 별도로 유지해야 하기에 여기에 들어가는 추가 비용도 큰 문제라고 지적했다.    ETL 없는 시대를 향해  AWS는 아마존 오로라와 레드시프트의 제로 ETL 통합으로 오로라에 기록되는 트랜잭션 데이터가 거의 즉시 레드시프트에 복제돼 분석될 수 있다고 설명했다.  셀립스키는 “기업 고객은 여러 아마존 오로라 데이터베이스 클러스터의 데이터를 하나의 아마존 레드시프트 인스턴스로 복제해 여러 애플리케이션에서 인사이트를 손쉽게 얻을 수 있다”라고 말했다. 이 통합 기능은 현재 프리뷰 형태로 제공된다....

2일 전

블로그ㅣ지능형 자동화가 CI/CD를 어떻게 변화시키는가?

오늘날 ‘모든 기업이 소프트웨어 회사다’라고 말하곤 한다. 이는 지난 10년 동안 규모와 상관없이 수많은 기업이 디지털 트랜스포메이션 이니셔티브를 수행했으며, 이러한 이니셔티브가 비즈니스 가치를 제공하기 위해 소프트웨어를 개발하고 배포하는 방식에 엄청난 영향을 미쳤기 때문이다.  과거에는 애플리케이션이 모놀리식이었고, 온프레미스에 배포됐으며, 업데이트가 거의 없었다. 오늘날 새로운 애플리케이션 모델은 마이크로서비스, 컨테이너화, 지속적 전달(Continuous delivery; CD)을 활용하여 쿠버네티스, VM, 멀티클라우드 환경에 대량의 소규모 릴리즈를 제공한다. 이러한 ‘진화’는 모든 서비스형(-as a service)부터 옴니채널 360도 고객 참여, 실시간 IoT 데이터 기반 비즈니스까지 새로운 유형의 비즈니스 프로세스와 모델을 가능하게 했다.    클라우드 네이티브 세계에서 이러한 새로운 소프트웨어 딜리버리 전략을 성공적으로 실행하려면 소프트웨어 개발에서 또 다른 혁신이 필요하다. 기업들은 소프트웨어 보안을 희생하거나 규정 및 비즈니스 컴플라이언스를 무시하지 않고 빠른 속도와 빈도 그리고 정확성으로 더 많은 소프트웨어 릴리즈를 제공해야 한다. 하지만 이는 복잡성을 증가시키기 마련이다.  게다가 지리적으로 분산된 팀이라면(개발, 운영, 데브옵스, 보안, 컴플라이언스) 더 빠르고, 더 정확하며, 더 높은 수준의 조정을 통해 작업해야 한다. 마찬가지로 복잡하고 분산된 워크플로우를 고도로 조정해 오류와 지연을 방지하는 한편 소프트웨어 딜리버리 팀 구성원의 생산성을 향상시켜야 한다. 이런 ‘진화’는 다양한 CI/CD 툴체인, 증가하는 보안 문제, 까다로워지는 프라이버시 규정, 적합한 기술 인력의 부족으로 더욱더 복잡해진다.  이 가운데 기업들이 소프트웨어 딜리버리 팀의 생산성을 높이고, 아울러 (소프트웨어) 릴리즈의 비즈니스 가치를 극대화하려면 어떻게 해야 할까? 첫째, 기업들은 시간 경과에 따라 도구와 ...

지능형 자동화 CI CD 지속적 전달 지속적 통합 데브옵스 소프트웨어 개발 소프트웨어 릴리즈

3일 전

오늘날 ‘모든 기업이 소프트웨어 회사다’라고 말하곤 한다. 이는 지난 10년 동안 규모와 상관없이 수많은 기업이 디지털 트랜스포메이션 이니셔티브를 수행했으며, 이러한 이니셔티브가 비즈니스 가치를 제공하기 위해 소프트웨어를 개발하고 배포하는 방식에 엄청난 영향을 미쳤기 때문이다.  과거에는 애플리케이션이 모놀리식이었고, 온프레미스에 배포됐으며, 업데이트가 거의 없었다. 오늘날 새로운 애플리케이션 모델은 마이크로서비스, 컨테이너화, 지속적 전달(Continuous delivery; CD)을 활용하여 쿠버네티스, VM, 멀티클라우드 환경에 대량의 소규모 릴리즈를 제공한다. 이러한 ‘진화’는 모든 서비스형(-as a service)부터 옴니채널 360도 고객 참여, 실시간 IoT 데이터 기반 비즈니스까지 새로운 유형의 비즈니스 프로세스와 모델을 가능하게 했다.    클라우드 네이티브 세계에서 이러한 새로운 소프트웨어 딜리버리 전략을 성공적으로 실행하려면 소프트웨어 개발에서 또 다른 혁신이 필요하다. 기업들은 소프트웨어 보안을 희생하거나 규정 및 비즈니스 컴플라이언스를 무시하지 않고 빠른 속도와 빈도 그리고 정확성으로 더 많은 소프트웨어 릴리즈를 제공해야 한다. 하지만 이는 복잡성을 증가시키기 마련이다.  게다가 지리적으로 분산된 팀이라면(개발, 운영, 데브옵스, 보안, 컴플라이언스) 더 빠르고, 더 정확하며, 더 높은 수준의 조정을 통해 작업해야 한다. 마찬가지로 복잡하고 분산된 워크플로우를 고도로 조정해 오류와 지연을 방지하는 한편 소프트웨어 딜리버리 팀 구성원의 생산성을 향상시켜야 한다. 이런 ‘진화’는 다양한 CI/CD 툴체인, 증가하는 보안 문제, 까다로워지는 프라이버시 규정, 적합한 기술 인력의 부족으로 더욱더 복잡해진다.  이 가운데 기업들이 소프트웨어 딜리버리 팀의 생산성을 높이고, 아울러 (소프트웨어) 릴리즈의 비즈니스 가치를 극대화하려면 어떻게 해야 할까? 첫째, 기업들은 시간 경과에 따라 도구와 ...

3일 전

웹3 커뮤니티 커머스 빌더 CAN, 오픈마켓형 마켓플레이스 플랫폼 운영기능 업데이트

웹3 커뮤니티 커머스 빌더 ‘CAN’(https://kr.canD.xyz)이 오픈마켓/마켓플레이스 플랫폼 신규기능을 업데이트했다고 29일 밝혔다.    오픈마켓은 자사 상품만 판매하는 일반쇼핑몰과 달리, 쿠팡/지마켓처럼 다양한 판매자를 모집해 그들이 직접 상품을 등록하고 판매할 수 있게 하는 플랫폼 방식의 서비스다. 일반쇼핑몰 운영을 지원하는 서비스는 많지만, SaaS 방식의 노코드 서비스로 오픈마켓/마켓플레이스 플랫폼 운영기능과 커뮤니티 기능까지 제공하는 곳은 CAN이 처음이라고 업체 측은 설명했다.  CAN 관계자는 “이번 오픈마켓/마켓플레이스 신규기능 업데이트로, 개발자 없이 창업한 스타트업들도 강력한 커머스 플랫폼을 구축할 수 있게 되었다”며, “특히 오픈마켓은 CAN의 커뮤니티 기능과 시너지가 큰 방식으로, 각 판매자별로 커뮤니티 더 나아가 팬덤을 형성해 탄탄한 성장을 도모할 수 있을 것으로 기대된다”고 말했다.  CAN은 개발자 없이도 커뮤니티 커머스 서비스를 만들고 웹3 서비스로 진화시킬 수 있는 노코드 빌더 기업이다. 다양한 커뮤니티 기능과 아이폰/안드로이드 네이티브 앱 출시 기능이 특징으로 꼽히며, 중앙일보 온라인 쿠킹클래스 지글지글, 어부 직거래 수산물 쇼핑몰 파도상자 등이 사용하고 있다. ciokr@idg.co.kr

웹3 CAN

4일 전

웹3 커뮤니티 커머스 빌더 ‘CAN’(https://kr.canD.xyz)이 오픈마켓/마켓플레이스 플랫폼 신규기능을 업데이트했다고 29일 밝혔다.    오픈마켓은 자사 상품만 판매하는 일반쇼핑몰과 달리, 쿠팡/지마켓처럼 다양한 판매자를 모집해 그들이 직접 상품을 등록하고 판매할 수 있게 하는 플랫폼 방식의 서비스다. 일반쇼핑몰 운영을 지원하는 서비스는 많지만, SaaS 방식의 노코드 서비스로 오픈마켓/마켓플레이스 플랫폼 운영기능과 커뮤니티 기능까지 제공하는 곳은 CAN이 처음이라고 업체 측은 설명했다.  CAN 관계자는 “이번 오픈마켓/마켓플레이스 신규기능 업데이트로, 개발자 없이 창업한 스타트업들도 강력한 커머스 플랫폼을 구축할 수 있게 되었다”며, “특히 오픈마켓은 CAN의 커뮤니티 기능과 시너지가 큰 방식으로, 각 판매자별로 커뮤니티 더 나아가 팬덤을 형성해 탄탄한 성장을 도모할 수 있을 것으로 기대된다”고 말했다.  CAN은 개발자 없이도 커뮤니티 커머스 서비스를 만들고 웹3 서비스로 진화시킬 수 있는 노코드 빌더 기업이다. 다양한 커뮤니티 기능과 아이폰/안드로이드 네이티브 앱 출시 기능이 특징으로 꼽히며, 중앙일보 온라인 쿠킹클래스 지글지글, 어부 직거래 수산물 쇼핑몰 파도상자 등이 사용하고 있다. ciokr@idg.co.kr

4일 전

블로그ㅣ오픈소스·멀티클라우드·서버리스로 보는 AWS 이모저모

이번 주, 특히 화요일 (새로운 제품 및 솔루션 출시) 뉴스를 발표하는 기술 기업이 있다면 유감이다. ‘AWS 리인벤트(AWS re:Invent)’가 시작됐다. 이 클라우드 거물이 선보일 출시와 업데이트 세례를 고려할 때, 해당 컨퍼런스 기간 동안 AWS와 경쟁하려고 하는 건 소용없는 일이다. 필자가 과거에 했던 것처럼 AWS가 무엇을 발표할지 예측할 가치조차 없다. 왜? AWS가 거의 모든 것을 내놓기 때문이다.  하지만 장담할 수 있는 게 있다. 누군가는 AWS의 발표에 격분할 것이란 점이다. AWS는 고객 집착을 위한 탐구(리더십 원칙 #1)에서 오픈소스, 멀티클라우드, 심지어 서버리스를 간과하는 경향이 있다.    계속 그 단어를 쓰다니… 서버리스부터 시작하겠다. 서버리스(Serverless)의 서버리스 클라우드 부문 前 총괄 책임자였고 현재는 Ampt의 CEO 겸 AWS 서버리스 히어로를 맡고 있는 제레미 데일리는 서버리스를 잘 안다. 따라서 ‘서버리스’로 (무언가) 잘못 명명한 AWS를 비난하는 그의 주장은 살펴볼 가치가 있다.   데일리에 따르면 “원래 AWS는 서버리스의 4가지 핵심 이점으로 ‘(1) 서버 관리 없음(no server management), (2) 유연한 확장(flexible scaling), (3) 고가용성(high availability), (4) 유휴 용량 없음(no idle capacity)’을 강조했다.” 마지막 이점은 매우 중요했다. 아니 필수적이었다. 앱이 실행되지 않는 한, 고객에게 비용이 청구되지 않는다는 것을 의미하기 때문이다.   불과 1년 후 AWS는 ‘유휴 용량 없음(no idle capacity)’ 기준을 폐기했다. 2018년 리인벤트에서 이 회사는 ‘가치에 따른 비용 지불(pay for value)’이라는 일종의 새로운 유휴 용량 없음 기준을 도입했다. 이는 “서버 단위가 아닌 일관된 처리량 또는 실행 기간에 대한 지불”을 의미한다. 그리고 데일리에 ...

아마존 웹 서비스 AWS 리인벤트 오픈소스 멀티클라우드 하이브리드 클라우드 서버리스

4일 전

이번 주, 특히 화요일 (새로운 제품 및 솔루션 출시) 뉴스를 발표하는 기술 기업이 있다면 유감이다. ‘AWS 리인벤트(AWS re:Invent)’가 시작됐다. 이 클라우드 거물이 선보일 출시와 업데이트 세례를 고려할 때, 해당 컨퍼런스 기간 동안 AWS와 경쟁하려고 하는 건 소용없는 일이다. 필자가 과거에 했던 것처럼 AWS가 무엇을 발표할지 예측할 가치조차 없다. 왜? AWS가 거의 모든 것을 내놓기 때문이다.  하지만 장담할 수 있는 게 있다. 누군가는 AWS의 발표에 격분할 것이란 점이다. AWS는 고객 집착을 위한 탐구(리더십 원칙 #1)에서 오픈소스, 멀티클라우드, 심지어 서버리스를 간과하는 경향이 있다.    계속 그 단어를 쓰다니… 서버리스부터 시작하겠다. 서버리스(Serverless)의 서버리스 클라우드 부문 前 총괄 책임자였고 현재는 Ampt의 CEO 겸 AWS 서버리스 히어로를 맡고 있는 제레미 데일리는 서버리스를 잘 안다. 따라서 ‘서버리스’로 (무언가) 잘못 명명한 AWS를 비난하는 그의 주장은 살펴볼 가치가 있다.   데일리에 따르면 “원래 AWS는 서버리스의 4가지 핵심 이점으로 ‘(1) 서버 관리 없음(no server management), (2) 유연한 확장(flexible scaling), (3) 고가용성(high availability), (4) 유휴 용량 없음(no idle capacity)’을 강조했다.” 마지막 이점은 매우 중요했다. 아니 필수적이었다. 앱이 실행되지 않는 한, 고객에게 비용이 청구되지 않는다는 것을 의미하기 때문이다.   불과 1년 후 AWS는 ‘유휴 용량 없음(no idle capacity)’ 기준을 폐기했다. 2018년 리인벤트에서 이 회사는 ‘가치에 따른 비용 지불(pay for value)’이라는 일종의 새로운 유휴 용량 없음 기준을 도입했다. 이는 “서버 단위가 아닌 일관된 처리량 또는 실행 기간에 대한 지불”을 의미한다. 그리고 데일리에 ...

4일 전

‘디지털 격차에 특효약’ 로우코드·노코드 보급에 앞장선 아프리카 기업들

로우코드·노코드(LCNC) 도구가 아프리카 몇몇 기업에서 활발히 활용되고 있다. 아직 CIO 커뮤니티에서 널리 논의될 만큼 많이 쓰이지는 않지만, 여러 선구자가 그 장점을 알리고자 노력 중이다.    코딩은 아프리카에서 수년 동안 교육 트렌드로 화제를 모았다. 디지털 시대에 대응하고자 많은 교육 시설을 비롯해 다양한 이니셔티브가 나타났다. 최근 들어 아프리카의 스타트업과 기업이 특히 관심을 두는 분야는 코딩 없이도 애플리케이션을 만들 수 있는 도구, 로우코드·노코드(LCNC) 플랫폼이다. 아프리카에서 LCNC 사업에 뛰어든 이들은 아직 디지털 기술이 널리 퍼지지 않은 지역에서 디지털 격차를 해소하고자 LCNC의 잠재력에 기대를 건다.  아프리카의 디지털 격차 문제는 여러 ICT 전문가들이 지적하는 대로 심각하다. 따라서 새로운 스타트업이 LCNC 도구를 발판 삼아 단번에 격차를 크게 줄이려 한다.  미국의 클라우드 컴퓨팅 업체 랙스페이스 테크놀로지(Rackspace Technology)는 2021년 전 세계 LCNC 도입 및 활용 현황 조사를 시행했다. EMEA(유럽, 중동, 아프리카) 지역의 사용량이 특히 낮다는 점이 드러났다.  보고서는 EMEA 지역의 LCNC 도입율이 낮은 이유는 그 이점을 잘 모르기 때문이라고 설명했다. 기술 트렌드를 묻는 조사의 질문에서 EMEA가 LCNC를 핵심 트렌드로 꼽은 비율이 가장 낮았다는 사실이 이러한 설명을 뒷받침한다. 또한 다른 지역과 달리 EMEA는 유일하게 LCNC 도구를 도입하지 않은 이유를 물어보는 질문에 ‘왜 좋은지 몰라서’라는 답변을 1위로 꼽았다.  보고서는 “EMEA 지역의 기업은 LCNC에 대한 롤모델이 없다. 도입한 기업이 있긴 있지만 아직 그 장점을 십분 활용하지 못하고 있기 때문이다”라고 기술했다. 연구진은 “EMEA 지역의 기업 중 LCNC 플랫폼의 장점으로 ‘애플리케이션 및 소프트웨어 구현 속도를 크게 높인다’라는 항목을 꼽은 ...

로우코드 앱 개발 도구 노코드 로우코드 LCNC 디지털격차

5일 전

로우코드·노코드(LCNC) 도구가 아프리카 몇몇 기업에서 활발히 활용되고 있다. 아직 CIO 커뮤니티에서 널리 논의될 만큼 많이 쓰이지는 않지만, 여러 선구자가 그 장점을 알리고자 노력 중이다.    코딩은 아프리카에서 수년 동안 교육 트렌드로 화제를 모았다. 디지털 시대에 대응하고자 많은 교육 시설을 비롯해 다양한 이니셔티브가 나타났다. 최근 들어 아프리카의 스타트업과 기업이 특히 관심을 두는 분야는 코딩 없이도 애플리케이션을 만들 수 있는 도구, 로우코드·노코드(LCNC) 플랫폼이다. 아프리카에서 LCNC 사업에 뛰어든 이들은 아직 디지털 기술이 널리 퍼지지 않은 지역에서 디지털 격차를 해소하고자 LCNC의 잠재력에 기대를 건다.  아프리카의 디지털 격차 문제는 여러 ICT 전문가들이 지적하는 대로 심각하다. 따라서 새로운 스타트업이 LCNC 도구를 발판 삼아 단번에 격차를 크게 줄이려 한다.  미국의 클라우드 컴퓨팅 업체 랙스페이스 테크놀로지(Rackspace Technology)는 2021년 전 세계 LCNC 도입 및 활용 현황 조사를 시행했다. EMEA(유럽, 중동, 아프리카) 지역의 사용량이 특히 낮다는 점이 드러났다.  보고서는 EMEA 지역의 LCNC 도입율이 낮은 이유는 그 이점을 잘 모르기 때문이라고 설명했다. 기술 트렌드를 묻는 조사의 질문에서 EMEA가 LCNC를 핵심 트렌드로 꼽은 비율이 가장 낮았다는 사실이 이러한 설명을 뒷받침한다. 또한 다른 지역과 달리 EMEA는 유일하게 LCNC 도구를 도입하지 않은 이유를 물어보는 질문에 ‘왜 좋은지 몰라서’라는 답변을 1위로 꼽았다.  보고서는 “EMEA 지역의 기업은 LCNC에 대한 롤모델이 없다. 도입한 기업이 있긴 있지만 아직 그 장점을 십분 활용하지 못하고 있기 때문이다”라고 기술했다. 연구진은 “EMEA 지역의 기업 중 LCNC 플랫폼의 장점으로 ‘애플리케이션 및 소프트웨어 구현 속도를 크게 높인다’라는 항목을 꼽은 ...

5일 전

기고ㅣ대세로 뜬다, CIO들이 지금 주목해야 할 ‘플러터’

현재 앱 스토어가 2개 기업에 독점돼 있긴 하지만 (그렇다고) 기업들은 2개의 개발팀을 유지해서는 안 된다. 미래는 '플러터 및 크로스 플랫폼 앱이다.  오늘날 CIO들은 전례 없는 압박에 직면해 있다. 고객과 개발자를 둔 경쟁이 치열하다. 사용자 니즈와 기술 변화 속도가 그 어느 때보다 빨라졌다. 그 결과 기본 소프트웨어 스택을 유지관리하는 비용이 급증하고 있다. 오늘날 CIO들은 이러한 추세를 이해해야 하고, 아울러 생산적인 팀 그리고 확장 가능하고 효율적인 고성능 애플리케이션을 구축하기 위해 내려야 하는 중요한 기술 결정도 파악해야 한다.    동시에 CIO들은 사용자 니즈가 바뀌는 위험을 제거하고, 사용자가 요구하는 속도에 맞춰 기능을 제공해야 한다. 하지만 직면하게 될 3가지 장애물이 있다.   • 치열한 고객 경쟁: 기업들은 오늘날 고객 경험이 가격과 제품만큼이나 (중요한) 차별화 요소라는 사실을 깨닫고 있다. 기능 속도(Feature velocity)는 좋은 고객 경험의 핵심이다. 고객은 고품질의 사용자 경험과 빠른 성능을 요구한다. 앱은 플랫폼과 기기 간에 일관성을 유지해야 하며, 같은 수준의 만족도로 끝나는 동일하고 원활하며 직관적인 여정을 제공해야 한다. 오늘날 평균적인 가정에는 16개의 커넥티드 기기가 있다. 사용자는 한 기기의 경험이 다른 기기에 비해 부족하다는 점을 알아차릴 것이다.  • 인재 부족: 하지만 개발자를 찾거나 유지하는 일이 쉽지 않다. 한 조사 결과에 따르면 무려 4,000만 개의 기술직이 인재 부족으로 인해 채워지지 않았다. 기업들은 2030년까지 개발자, 애널리스트, 테스터 채용을 약 1/4로 확대하리라 예측됐다.  • 비용 상승: 사용자는 더 빠른 속도로 점점 더 많은 기능을 요구한다. 기업들이 사용자를 만족시키려고 하면서 엔지니어링 인재 수요가 더욱더 커지고 있다. 따라서 기업들은 인재를 확보하고 기능을 더 빠르게 제공하기 위해 더 많은 비용을 지불한다...

플러터 앱 스토어 애플리케이션 애플리케이션 개발 크로스 플랫폼 개발 구글

5일 전

현재 앱 스토어가 2개 기업에 독점돼 있긴 하지만 (그렇다고) 기업들은 2개의 개발팀을 유지해서는 안 된다. 미래는 '플러터 및 크로스 플랫폼 앱이다.  오늘날 CIO들은 전례 없는 압박에 직면해 있다. 고객과 개발자를 둔 경쟁이 치열하다. 사용자 니즈와 기술 변화 속도가 그 어느 때보다 빨라졌다. 그 결과 기본 소프트웨어 스택을 유지관리하는 비용이 급증하고 있다. 오늘날 CIO들은 이러한 추세를 이해해야 하고, 아울러 생산적인 팀 그리고 확장 가능하고 효율적인 고성능 애플리케이션을 구축하기 위해 내려야 하는 중요한 기술 결정도 파악해야 한다.    동시에 CIO들은 사용자 니즈가 바뀌는 위험을 제거하고, 사용자가 요구하는 속도에 맞춰 기능을 제공해야 한다. 하지만 직면하게 될 3가지 장애물이 있다.   • 치열한 고객 경쟁: 기업들은 오늘날 고객 경험이 가격과 제품만큼이나 (중요한) 차별화 요소라는 사실을 깨닫고 있다. 기능 속도(Feature velocity)는 좋은 고객 경험의 핵심이다. 고객은 고품질의 사용자 경험과 빠른 성능을 요구한다. 앱은 플랫폼과 기기 간에 일관성을 유지해야 하며, 같은 수준의 만족도로 끝나는 동일하고 원활하며 직관적인 여정을 제공해야 한다. 오늘날 평균적인 가정에는 16개의 커넥티드 기기가 있다. 사용자는 한 기기의 경험이 다른 기기에 비해 부족하다는 점을 알아차릴 것이다.  • 인재 부족: 하지만 개발자를 찾거나 유지하는 일이 쉽지 않다. 한 조사 결과에 따르면 무려 4,000만 개의 기술직이 인재 부족으로 인해 채워지지 않았다. 기업들은 2030년까지 개발자, 애널리스트, 테스터 채용을 약 1/4로 확대하리라 예측됐다.  • 비용 상승: 사용자는 더 빠른 속도로 점점 더 많은 기능을 요구한다. 기업들이 사용자를 만족시키려고 하면서 엔지니어링 인재 수요가 더욱더 커지고 있다. 따라서 기업들은 인재를 확보하고 기능을 더 빠르게 제공하기 위해 더 많은 비용을 지불한다...

5일 전

'애저 데브옵스에 웹3를 통합'··· 마이크로소프트의 블록체인 실험

‘웹3’가 소위 대세 기술이라고 하지만, 아직 지난 30년간 활용됐던 인프라 및 소프트웨어를 완전히 대체할 정도는 아니다. 그럼에도 웹3가 해결하려는 문제는 한번 살펴보면 좋다. 블록체인 기술의 방향성을 예측하는 데 도움을 받을 수 있기 때문이다.   웹3 지지자는 웹3를 거대한 소비자 기술의 집합으로 보며, 본질적으로 웹의 트랜잭션 기반을 대체할 수 있다고 말한다. 필자가 해석한 바로는 웹3는 다소 제한적이긴 하지만 데이터 교환(Electronic Data Interchange, EDI)에 중점을 둔 엔터프라이즈 애플리케이션의 하위집합을 지원한다. 이런 기술은 블록체인 기술로 구축할 수 있는데, 신뢰할 수 있는 방식으로 약속된 당사자끼리 불변성을 가진 데이터를 교환할 수 있기 때문이다. 따라서 디지털 문서 및 계약서 형태로 쓰기 매우 유용하다.  현재 마이크로소프트가 만드는 블록체인은 매우 흥미롭다. 이들이 만드는 기술은 신뢰할 수 없는 조직으로 이루어진 연합체가 운영하고, 작업 증명 및 지분 증명 시스템에 대한 빠르고 영향력을 적게 주는 대안을 제공한다. 동시에 최근 출시된 SQL 서버(SQL Server)는 현재 각기 다른 엔티티간 배포할 필요 없는 애플리케이션에 대한 불변 원장을 제공한다.  해당 기술의 예로 선박 화물 관리에 사용되는 디지털 선하 증권(운송인 또는 선박소유자가 발행하는 증권)을 들 수 있다. 선하 증권 계약상에 명시된 각 당사자 제조업체, 해운 회사, 창고 관리자, 화물선 운영자, 관세사, 세관 등이 될 수 있다. 각 당사자는 문서 및 계약을 서로 주고받으면서, 직접적으로 연결된 당사자의 정보만 알 수 있는데, 모두 문서에 대한 액세스 권한이 필요하며, 다수는 복잡한 다자간 승인 프로세스의 일부로 자신의 서명을 추가해야 한다.  이런 구조는 얼핏 보면 엔터프라이즈 블록체인으로 구축할 수 있지만, 현대 개발 환경을 한 번 더 고려해봐야 한다. 우리는 이미 데브옵스 및 CI/CD 플랫폼을 사용해...

애저 블록체인 웹3.0

5일 전

‘웹3’가 소위 대세 기술이라고 하지만, 아직 지난 30년간 활용됐던 인프라 및 소프트웨어를 완전히 대체할 정도는 아니다. 그럼에도 웹3가 해결하려는 문제는 한번 살펴보면 좋다. 블록체인 기술의 방향성을 예측하는 데 도움을 받을 수 있기 때문이다.   웹3 지지자는 웹3를 거대한 소비자 기술의 집합으로 보며, 본질적으로 웹의 트랜잭션 기반을 대체할 수 있다고 말한다. 필자가 해석한 바로는 웹3는 다소 제한적이긴 하지만 데이터 교환(Electronic Data Interchange, EDI)에 중점을 둔 엔터프라이즈 애플리케이션의 하위집합을 지원한다. 이런 기술은 블록체인 기술로 구축할 수 있는데, 신뢰할 수 있는 방식으로 약속된 당사자끼리 불변성을 가진 데이터를 교환할 수 있기 때문이다. 따라서 디지털 문서 및 계약서 형태로 쓰기 매우 유용하다.  현재 마이크로소프트가 만드는 블록체인은 매우 흥미롭다. 이들이 만드는 기술은 신뢰할 수 없는 조직으로 이루어진 연합체가 운영하고, 작업 증명 및 지분 증명 시스템에 대한 빠르고 영향력을 적게 주는 대안을 제공한다. 동시에 최근 출시된 SQL 서버(SQL Server)는 현재 각기 다른 엔티티간 배포할 필요 없는 애플리케이션에 대한 불변 원장을 제공한다.  해당 기술의 예로 선박 화물 관리에 사용되는 디지털 선하 증권(운송인 또는 선박소유자가 발행하는 증권)을 들 수 있다. 선하 증권 계약상에 명시된 각 당사자 제조업체, 해운 회사, 창고 관리자, 화물선 운영자, 관세사, 세관 등이 될 수 있다. 각 당사자는 문서 및 계약을 서로 주고받으면서, 직접적으로 연결된 당사자의 정보만 알 수 있는데, 모두 문서에 대한 액세스 권한이 필요하며, 다수는 복잡한 다자간 승인 프로세스의 일부로 자신의 서명을 추가해야 한다.  이런 구조는 얼핏 보면 엔터프라이즈 블록체인으로 구축할 수 있지만, 현대 개발 환경을 한 번 더 고려해봐야 한다. 우리는 이미 데브옵스 및 CI/CD 플랫폼을 사용해...

5일 전

MS, ‘ML닷넷 2.0’ 출시··· “텍스트 분류 개선”

마이크로소프트가 닷넷용 오픈소스 크로스-플랫폼 머신러닝 프레임워크의 새 버전 ‘ML닷넷 2.0(ML.NET 2.0)’을 출시했다. 텍스트 분류를 위한 모델 빌드가 개선되고, 문장 유사성 API가 도입됐으며, 더 많은 오토ML(AutoML) 기능이 추가됐다.    아울러 ML닷넷 2.0와 함께 닷넷 애플리케이션용 머신러닝 모델을 빌드하기 위한 시각적 개발자 도구 ‘ML닷넷 모델 빌더(MLNET Model Builder)’도 공개됐다. 해당 모델 빌더는 ML닷넷 텍스트 분류 API(ML.NET Text Classification API)를 기반으로 하는 텍스트 분류 시나리오를 제공한다.  개발팀에 따르면 지난 6월 프리뷰로 릴리즈됐던 텍스트 분류 API를 통해 개발자는 원시 텍스트 데이터를 분류하도록 사용자 정의 모델을 학습시킬 수 있다. 텍스트 분류 API는 오픈소스 ML닷넷 머신러닝 프레임워크를 기반으로 사용자 정의 텍스트 분류 모델의 학습을 간소화하는 API다.  텍스트 분류 API는 마이크로소프트 리서치(Microsoft Research)의 사전 학습된 TorchSharp NAS-BERT 모델과 개발자의 자체 데이터를 활용하여 모델을 미세 조정한다. 모델 빌더 시나리오는 CPU 또는 CUDA 호환 CPU에서 로컬 학습을 지원한다.  이 밖에 ML닷넷 2.0의 새로운 기능 및 개선 사항은 다음과 같다.    • 사전 구성된 자동화 머신러닝 파이프라인을 쓰는 이진 분류, 멀티클래스 분류, 회귀 모델을 통해 머신러닝을 더욱더 쉽게 시작할 수 있다.  • 오토ML 피처라이저(AutoML Featurizer)를 사용하여 데이터 전처리를 자동화할 수 있다.  • 개발자는 학습 과정의 일부로 쓸 트레이너를 선택할 수 있다. 또 최적의 하이퍼파라미터를 찾는 데 사용되는 튜닝 알고리즘을 선택할 수 있다.  • 트레이너를 선...

마이크로소프트 닷넷 ML닷넷 머신러닝 프레임워크 텍스트 분류

2022.11.24

마이크로소프트가 닷넷용 오픈소스 크로스-플랫폼 머신러닝 프레임워크의 새 버전 ‘ML닷넷 2.0(ML.NET 2.0)’을 출시했다. 텍스트 분류를 위한 모델 빌드가 개선되고, 문장 유사성 API가 도입됐으며, 더 많은 오토ML(AutoML) 기능이 추가됐다.    아울러 ML닷넷 2.0와 함께 닷넷 애플리케이션용 머신러닝 모델을 빌드하기 위한 시각적 개발자 도구 ‘ML닷넷 모델 빌더(MLNET Model Builder)’도 공개됐다. 해당 모델 빌더는 ML닷넷 텍스트 분류 API(ML.NET Text Classification API)를 기반으로 하는 텍스트 분류 시나리오를 제공한다.  개발팀에 따르면 지난 6월 프리뷰로 릴리즈됐던 텍스트 분류 API를 통해 개발자는 원시 텍스트 데이터를 분류하도록 사용자 정의 모델을 학습시킬 수 있다. 텍스트 분류 API는 오픈소스 ML닷넷 머신러닝 프레임워크를 기반으로 사용자 정의 텍스트 분류 모델의 학습을 간소화하는 API다.  텍스트 분류 API는 마이크로소프트 리서치(Microsoft Research)의 사전 학습된 TorchSharp NAS-BERT 모델과 개발자의 자체 데이터를 활용하여 모델을 미세 조정한다. 모델 빌더 시나리오는 CPU 또는 CUDA 호환 CPU에서 로컬 학습을 지원한다.  이 밖에 ML닷넷 2.0의 새로운 기능 및 개선 사항은 다음과 같다.    • 사전 구성된 자동화 머신러닝 파이프라인을 쓰는 이진 분류, 멀티클래스 분류, 회귀 모델을 통해 머신러닝을 더욱더 쉽게 시작할 수 있다.  • 오토ML 피처라이저(AutoML Featurizer)를 사용하여 데이터 전처리를 자동화할 수 있다.  • 개발자는 학습 과정의 일부로 쓸 트레이너를 선택할 수 있다. 또 최적의 하이퍼파라미터를 찾는 데 사용되는 튜닝 알고리즘을 선택할 수 있다.  • 트레이너를 선...

2022.11.24

칼럼 | 오픈소스계의 트위터 ‘마스토돈’에 대한 착각

트위터를 마스토돈(Mastodon)으로 대체하자고 설득하는 모습을 보고 있으면, 오픈소스 업계에서 오랫동안 자주 빠지는 함정에 다시 걸려들고 있다는 인상을 받는다. 이런 사람들은 대부분 더 많은 기술, 특히 더 많은 오픈소스 기술로 뭐든지 해결해보려는 태도를 가지고 있다.       오픈소스 소셜 네트워크 ‘마스토돈’의 문제점  필자는 오픈소스에 거의 20년 동안 몸담았다. 오픈소스는 나에게 집이자 국가와 같은 곳이다. 그러나 우리 오픈소스인들은 편리함보다 선택의 특권을 더 중시하는 불행한 성향을 갖고 있다. 마스토돈 사례가 대표적이다. 마스토돈은 스스로 ‘판매하지 않는 소셜 네트워킹’을 표방한다. 오픈소스이며 탈중앙화된 소셜 네트워크로서 사용자들에게 “원하는 대로 복사하고 연구하고 변경하라”고 한다. 또한 “각 마스토돈 서버는 완전히 독립적인 개체”라고 한다. 그냥 트윗(마스토돈 용어로는 ‘툿(toot)’)을 올리고자 하는 소셜 네트워크 이용자들에게 이런 기술 구조는 전혀 중요하지 않다. 거기다 마스토돈에는 일반 사용자가 싫어할 만한 요소가 다음과 같이 두 가지 있다. 오픈소스 코어 그룹을 제외한 거의 모든 사람들은 거부감을 가질 수 있는 부분이다.    마스토돈은 사용자 자신의 인프라에 구축되어 온라인상의 다른 마스토돈 서버와 상호 팔로우할 수 있으며 사용자 이외의 누구의 통제도 받지 않는다. 각 서버는 자체적인 규칙과 규정을 생성하며, 이러한 규칙 및 규정은 기업형 소셜 미디어와 같은 하향식이 아니라 로컬에서 강제된다. 마스토돈에 가입할 때는 서버를 선택해야 한다. 그런데 서버 선택 기능을 이해하는 과정은 트위터를 쭉 사용해온 사용자나 기술 전문가에게도 어려울 수 있다. 마스토돈에는 ‘어떤 서버를 선택하든 괜찮다’는 안내 메시지와 함께 서버 선택을 통해 자신의 관심사에 맞는 커뮤니티를 선택하는 방법에 관한 장황한 사용 안내가 나온다. 여기서 말하는 ‘관심사’의 범위는 꽤 좁다. ...

마스토돈 오픈소스 트위터

2022.11.24

트위터를 마스토돈(Mastodon)으로 대체하자고 설득하는 모습을 보고 있으면, 오픈소스 업계에서 오랫동안 자주 빠지는 함정에 다시 걸려들고 있다는 인상을 받는다. 이런 사람들은 대부분 더 많은 기술, 특히 더 많은 오픈소스 기술로 뭐든지 해결해보려는 태도를 가지고 있다.       오픈소스 소셜 네트워크 ‘마스토돈’의 문제점  필자는 오픈소스에 거의 20년 동안 몸담았다. 오픈소스는 나에게 집이자 국가와 같은 곳이다. 그러나 우리 오픈소스인들은 편리함보다 선택의 특권을 더 중시하는 불행한 성향을 갖고 있다. 마스토돈 사례가 대표적이다. 마스토돈은 스스로 ‘판매하지 않는 소셜 네트워킹’을 표방한다. 오픈소스이며 탈중앙화된 소셜 네트워크로서 사용자들에게 “원하는 대로 복사하고 연구하고 변경하라”고 한다. 또한 “각 마스토돈 서버는 완전히 독립적인 개체”라고 한다. 그냥 트윗(마스토돈 용어로는 ‘툿(toot)’)을 올리고자 하는 소셜 네트워크 이용자들에게 이런 기술 구조는 전혀 중요하지 않다. 거기다 마스토돈에는 일반 사용자가 싫어할 만한 요소가 다음과 같이 두 가지 있다. 오픈소스 코어 그룹을 제외한 거의 모든 사람들은 거부감을 가질 수 있는 부분이다.    마스토돈은 사용자 자신의 인프라에 구축되어 온라인상의 다른 마스토돈 서버와 상호 팔로우할 수 있으며 사용자 이외의 누구의 통제도 받지 않는다. 각 서버는 자체적인 규칙과 규정을 생성하며, 이러한 규칙 및 규정은 기업형 소셜 미디어와 같은 하향식이 아니라 로컬에서 강제된다. 마스토돈에 가입할 때는 서버를 선택해야 한다. 그런데 서버 선택 기능을 이해하는 과정은 트위터를 쭉 사용해온 사용자나 기술 전문가에게도 어려울 수 있다. 마스토돈에는 ‘어떤 서버를 선택하든 괜찮다’는 안내 메시지와 함께 서버 선택을 통해 자신의 관심사에 맞는 커뮤니티를 선택하는 방법에 관한 장황한 사용 안내가 나온다. 여기서 말하는 ‘관심사’의 범위는 꽤 좁다. ...

2022.11.24

애플 스위프트, 2023년 로드맵 공개··· “동시성 및 제네릭 개선”

스위프트의 2023년 로드맵이 지난 11월 18일(현지 시각) 공식 블로그에 게시됐다.  새로 구성된 스위프트 워킹 그룹은 샌더블(Sendable)과 액터(Actor)가 제공하는 엄격한 데이터 격리 지원을 위해 동시성을 개선하겠다고 밝혔다. 여기에는 전역 변수 및 특정 교차 행위자 호출 등 스레드 안전 결함을 제거하는 것도 포함된다.    또한 스위프트 워킹 그룹은 가변 제네릭 언어 기능을 제공할 예정이며, 처음에는 핵심 언어 모델을 설계하고 이를 지원하기 위한 컴파일러 및 런타임 인프라를 구축하는 데 중점을 둘 것이라고 전했다. 초기 이정표 중 하나는 튜플 유형이 조건부로 Equatable과 같은 프로토콜을 준수하도록 허용하는 것이다.  아울러 소유권과 관련해 개발자가 메모리에 있는 값의 소유권을 제어할 수 있는 기능, 복사할 수 없는 유형에 대한 기본 지원을 추가해 성능을 향상시키는 기능도 작업 중이다.  C++ 상호운용성을 위해서는 소유된 값 유형, 사소한 값 유형, 외부 참초 유형 및 반복자 등의 API 패턴을 포함해 스위프트에서 C++를 사용하기 위한 상호운용성 기능(현재 프로토타입 상태)을 안정화할 계획이라고 워킹 그룹은 전했다. 또 스위프트 값 유형, 참조 유형, 함수가 C++에 노출되는 방식도 안정화할 예정이다.  한편 컴파일러 개발팀은 빌드 시스템과의 컴파일러 상호작용을 개선하고 있다고 밝혔다. 패키지 레지스트리에서도 스위프트 패키지 관리자 개발은 커뮤니티와의 협력을 통해 오픈소스 패키지 레지스트리 서버를 구축 중이다.  이 밖에 스위프트의 2023년 로드맵에 포함된 내용은 다음과 같다.  • 순수한 스위프트로 작성되고 현재 C++ 구현으로 완전한 기능을 갖춘 파서 개발(C++ 파서는 대체될 예정) • 유형 검사 성능 및 코드 완성 안정성 개선 • Differentiable Swift를 사용하여 컴파일된 코드 성능을 향상시키는 것을 포함해 견고성과 성능을 처리...

애플 스위프트 개발 언어 프로그래밍 언어

2022.11.23

스위프트의 2023년 로드맵이 지난 11월 18일(현지 시각) 공식 블로그에 게시됐다.  새로 구성된 스위프트 워킹 그룹은 샌더블(Sendable)과 액터(Actor)가 제공하는 엄격한 데이터 격리 지원을 위해 동시성을 개선하겠다고 밝혔다. 여기에는 전역 변수 및 특정 교차 행위자 호출 등 스레드 안전 결함을 제거하는 것도 포함된다.    또한 스위프트 워킹 그룹은 가변 제네릭 언어 기능을 제공할 예정이며, 처음에는 핵심 언어 모델을 설계하고 이를 지원하기 위한 컴파일러 및 런타임 인프라를 구축하는 데 중점을 둘 것이라고 전했다. 초기 이정표 중 하나는 튜플 유형이 조건부로 Equatable과 같은 프로토콜을 준수하도록 허용하는 것이다.  아울러 소유권과 관련해 개발자가 메모리에 있는 값의 소유권을 제어할 수 있는 기능, 복사할 수 없는 유형에 대한 기본 지원을 추가해 성능을 향상시키는 기능도 작업 중이다.  C++ 상호운용성을 위해서는 소유된 값 유형, 사소한 값 유형, 외부 참초 유형 및 반복자 등의 API 패턴을 포함해 스위프트에서 C++를 사용하기 위한 상호운용성 기능(현재 프로토타입 상태)을 안정화할 계획이라고 워킹 그룹은 전했다. 또 스위프트 값 유형, 참조 유형, 함수가 C++에 노출되는 방식도 안정화할 예정이다.  한편 컴파일러 개발팀은 빌드 시스템과의 컴파일러 상호작용을 개선하고 있다고 밝혔다. 패키지 레지스트리에서도 스위프트 패키지 관리자 개발은 커뮤니티와의 협력을 통해 오픈소스 패키지 레지스트리 서버를 구축 중이다.  이 밖에 스위프트의 2023년 로드맵에 포함된 내용은 다음과 같다.  • 순수한 스위프트로 작성되고 현재 C++ 구현으로 완전한 기능을 갖춘 파서 개발(C++ 파서는 대체될 예정) • 유형 검사 성능 및 코드 완성 안정성 개선 • Differentiable Swift를 사용하여 컴파일된 코드 성능을 향상시키는 것을 포함해 견고성과 성능을 처리...

2022.11.23

기고ㅣ있는지조차 모른다, ‘웹 스케일’ 문제 파악하고 해결하는 법

여기서는 웹 스케일(Web Scale) 문제의 기원과 진화, 웹 스케일 문제가 있는지 확인하는 방법, 컨테이너 오케스트레이션이 이러한 문제를 해결하는 가장 우아한 방법인 이유를 살펴본다.    필자는 축하 카드(Greeting card) 산업에서 웹 스케일 문제의 첫 번째 전조를 봤다. 약 100년 동안 미국의 축하 카드 회사들은 ‘선물과 함께 전달될, 우편으로 보내질 또는 냉장고에 붙여질’ 카드를 제작해 판매하면서 번창했다. 그러다가 1990년대 중반 모든 것이 바뀌었다. 월드 와이드 웹(World Wide Web)이 등장한 것이다. 이에 1996년 블루 마운틴(Blue Mountain), 아메리칸 그리팅스(American Greetings), 홀마크(Hallmark) 등은 모두 전자카드를 제공하기 위해 닷컴(Dot-com) 사이트를 개설했고, 디지털 전쟁이 뒤따랐다.  필자는 축하 카드 산업에서 일했던 적이 있다. 밸렌타인데이, 어버이날, 크리스마스는 축하 카드 회사들의 대목이었고, 비즈니스가 온라인으로 이동했을 때도 이러한 기념일은 전자카드 시장의 전쟁터였다. 최신 웹 인프라를 구축하고 새로운 디지털 비즈니스를 성사시켜야 했다(오늘날 이를 디지털 트랜스포메이션이라 부른다). 처음에는 전자카드가 무료였다. 목표는 돈을 버는 게 아니라 사용자를 유인하는 것이었다. 닷컴에서는 수백만 명의 사용자가 기업 평가 측면에서 수백만 달러의 가치가 있었다. 한동안은 상황이 좋았다. 모두가 새로운 사용자를 유인했다. 하지만 머지않아 닷컴들은 실제로 돈을 벌어야 했다. 이로 인해 문제와 기회가 생겼다. 아메리칸그리팅스닷컴(AmericanGreetings.com)이 전자카드에 비용을 청구하기 시작하자 사용자들은 돈을 내고 싶지 않았기 때문에 홀마크닷컴(Hallmark.com)으로 몰려갔다. 홀마크는 증가한 트래픽을 감당하지 못하고 다운됐다. 사람들은 여전히 전자카드를 보내고 싶었기 때문에 아메리칸그리팅스닷컴으로 돌아가 요금을 지불하고 (전자...

웹 스케일 쿠버네티스 트래픽 클러스터

2022.11.18

여기서는 웹 스케일(Web Scale) 문제의 기원과 진화, 웹 스케일 문제가 있는지 확인하는 방법, 컨테이너 오케스트레이션이 이러한 문제를 해결하는 가장 우아한 방법인 이유를 살펴본다.    필자는 축하 카드(Greeting card) 산업에서 웹 스케일 문제의 첫 번째 전조를 봤다. 약 100년 동안 미국의 축하 카드 회사들은 ‘선물과 함께 전달될, 우편으로 보내질 또는 냉장고에 붙여질’ 카드를 제작해 판매하면서 번창했다. 그러다가 1990년대 중반 모든 것이 바뀌었다. 월드 와이드 웹(World Wide Web)이 등장한 것이다. 이에 1996년 블루 마운틴(Blue Mountain), 아메리칸 그리팅스(American Greetings), 홀마크(Hallmark) 등은 모두 전자카드를 제공하기 위해 닷컴(Dot-com) 사이트를 개설했고, 디지털 전쟁이 뒤따랐다.  필자는 축하 카드 산업에서 일했던 적이 있다. 밸렌타인데이, 어버이날, 크리스마스는 축하 카드 회사들의 대목이었고, 비즈니스가 온라인으로 이동했을 때도 이러한 기념일은 전자카드 시장의 전쟁터였다. 최신 웹 인프라를 구축하고 새로운 디지털 비즈니스를 성사시켜야 했다(오늘날 이를 디지털 트랜스포메이션이라 부른다). 처음에는 전자카드가 무료였다. 목표는 돈을 버는 게 아니라 사용자를 유인하는 것이었다. 닷컴에서는 수백만 명의 사용자가 기업 평가 측면에서 수백만 달러의 가치가 있었다. 한동안은 상황이 좋았다. 모두가 새로운 사용자를 유인했다. 하지만 머지않아 닷컴들은 실제로 돈을 벌어야 했다. 이로 인해 문제와 기회가 생겼다. 아메리칸그리팅스닷컴(AmericanGreetings.com)이 전자카드에 비용을 청구하기 시작하자 사용자들은 돈을 내고 싶지 않았기 때문에 홀마크닷컴(Hallmark.com)으로 몰려갔다. 홀마크는 증가한 트래픽을 감당하지 못하고 다운됐다. 사람들은 여전히 전자카드를 보내고 싶었기 때문에 아메리칸그리팅스닷컴으로 돌아가 요금을 지불하고 (전자...

2022.11.18

‘구성원 경험이 곧 문화이자 비즈니스 전략이다’ 서비스나우가 제시하는 순간과 접점 중심의 통합 디지털 워크스페이스

“미래의 좋은 워크스페이스란 단지 언제, 어디서든 일하기 쾌적한 공간을 넘어 구성원 스스로 중요한 일을 하고 있다고 느낄 수 있는 공간이어야 한다. 즉 구성원 그 자체가 워크플레이스이어야 한다."   11월 10일 한국 IDG가 주최한 ‘퓨처 오브 워크 2022(Future of Work 2022)’ 컨퍼런스에서 서비스나우의 장기훈 전무가 구성원 경험(Employee Experience, EX)의 중요성에 관해 발표했다. 장기훈 전무가 인용한 한 포브스 설문조사에 따르면 92%의 HR 리더들이 구성원 경험을 가장 중요한 우선순위로 꼽았다. 그는 팬데믹의 여파와 새로운 세대의 유입이 맞물리며 업무환경에 대한 요구가 디지털 워크스페이스라는 개념으로 변화했다고 말했다.  워크스페이스라는 개념의 변화 하지만 물리적으로 일하는 곳을 뜻하는 기존 워크스페이스의 개념으로는 더 이상 생산성을 증진하고 구성원을 유지하기 어려워졌다. 장기훈 전무는 구성원 경험을 효과적으로 설계한 회사는 구성원의 이탈을 방지하고 참여시킬 가능성이 5배 더 높다고 강조했다.  이에 더해 이미 몇 년 전부터 수많은 기업이 디지털 전환에 박차를 가하고 있다. 시장에 빠르게 응대하는 과정에서 현재의 문제를 해결하기 위한 포인트 솔루션에 집중하게 되고, 이것은 미래의 복잡성과 매몰 비용을 담보로 하는 기술 부채를 떠안게 된다고 장기훈 전무는 진단했다. 따라서 워크스페이스와 구성원 경험을 단순한 인사 부서 업무가 아닌 기업의 경영활동 측면에서 총체적으로 혁신할 필요가 더 크다는 주장이다.  'Nice to Have'에서 'Must-Have'로 일반적으로 기업에 중요한 대외 접점은 크게 고객과 파트너다. 기업은 파트너와 가치를 생산하고 고객의 접점을 통해서 가치를 전달하게 된다. 그 가치를 생산하고 전달하는 것은 구성원이며, IT가 마치 디지털 엔진 같이 이들을 떠받치고 있다. 물론 가장 중요한 핵심 시스템인 디지털 기술 스택이 고객 서비스, 세일즈, 마...

서비스나우 직원경험 구성원 고객 접점 HCM 사용자경험

2022.11.18

“미래의 좋은 워크스페이스란 단지 언제, 어디서든 일하기 쾌적한 공간을 넘어 구성원 스스로 중요한 일을 하고 있다고 느낄 수 있는 공간이어야 한다. 즉 구성원 그 자체가 워크플레이스이어야 한다."   11월 10일 한국 IDG가 주최한 ‘퓨처 오브 워크 2022(Future of Work 2022)’ 컨퍼런스에서 서비스나우의 장기훈 전무가 구성원 경험(Employee Experience, EX)의 중요성에 관해 발표했다. 장기훈 전무가 인용한 한 포브스 설문조사에 따르면 92%의 HR 리더들이 구성원 경험을 가장 중요한 우선순위로 꼽았다. 그는 팬데믹의 여파와 새로운 세대의 유입이 맞물리며 업무환경에 대한 요구가 디지털 워크스페이스라는 개념으로 변화했다고 말했다.  워크스페이스라는 개념의 변화 하지만 물리적으로 일하는 곳을 뜻하는 기존 워크스페이스의 개념으로는 더 이상 생산성을 증진하고 구성원을 유지하기 어려워졌다. 장기훈 전무는 구성원 경험을 효과적으로 설계한 회사는 구성원의 이탈을 방지하고 참여시킬 가능성이 5배 더 높다고 강조했다.  이에 더해 이미 몇 년 전부터 수많은 기업이 디지털 전환에 박차를 가하고 있다. 시장에 빠르게 응대하는 과정에서 현재의 문제를 해결하기 위한 포인트 솔루션에 집중하게 되고, 이것은 미래의 복잡성과 매몰 비용을 담보로 하는 기술 부채를 떠안게 된다고 장기훈 전무는 진단했다. 따라서 워크스페이스와 구성원 경험을 단순한 인사 부서 업무가 아닌 기업의 경영활동 측면에서 총체적으로 혁신할 필요가 더 크다는 주장이다.  'Nice to Have'에서 'Must-Have'로 일반적으로 기업에 중요한 대외 접점은 크게 고객과 파트너다. 기업은 파트너와 가치를 생산하고 고객의 접점을 통해서 가치를 전달하게 된다. 그 가치를 생산하고 전달하는 것은 구성원이며, IT가 마치 디지털 엔진 같이 이들을 떠받치고 있다. 물론 가장 중요한 핵심 시스템인 디지털 기술 스택이 고객 서비스, 세일즈, 마...

2022.11.18

2023년 효율성·성능 개선된 M2 시리즈 나올까?

2023년 M2 칩보다 효율성과 성능이 함께 개선된 M2 프로(Pro), 맥스(Max), 울트라(Ultra), 익스트림(Extreme) 칩이 출시될까? 이에 대한 여러 주장과 루머가 혼재하고 있다.    애플이 지난 28일(현지 시각) 발표한 4분기(7월~9월) 실적에 따르면, 맥(Mac) 제품군의 매출은 지난해 같은 기간보다 25%나 상승했다. M2 칩을 탑재한 맥북에어는 올해 7월 등장했다.  <맥월드> 기자 제이슨 크로스는 M2 맥북에어가 M1 맥북에어의 성공을 이을만한 제품이며 “대부분 사용자가 마음에 들어 할 일상적인 컴퓨터”라고 평가했다.  하지만 M2 맥북 에어에 대한 칭찬은 곧 스로틀링(throttling)에 대한 보도로 뒤덮였다. 여러 기사에서 성능 단점과 "심각한" 스로틀링 문제, "열을 감당할 수 없다"라고 지적했고, 신형 맥북 에어의 발열 문제를 보여주는 동영상도 잇달아 나왔다.    독일 하드웨어 전문매체 노트북체크(Notebookcheck)는 M2의 공정 노드가 M1과 같이 5nm에 머물러 있다는 점이 발열의 원인이라고 지적했다. 애플은 공식 발표에서 M2의 CPU가 M1보다 약 18% 더 빠르다고 주장했는 데, 노트북체크가 분석한 결과 M2가 성능을 18% 끌어올린 방식은 오로지 클럭스피드를 높여서다. 시험 결과에 따르면 M2 칩은 18% 더 높은 CPU 성능을 내기 위해 평균 40% 더 많은 전력을 소비한다. 결과적으로 M1에 비해 효율성이 떨어지며, 고성능 작업을 할 때 발열이 더 많이 생길 수밖에 없다고 노트북체크는 설명했다.   이러한 가운데 개선된 공정의 M2 후속칩에 관심이 집중되는 양상이다. M2 후속칩은 M1의 5nm 대신 3nm 공정으로 설계될 것으로 예상된다. TSMC에 따르면 3nm 공정은 5nm에 비해 15% 더 빠르며, 같은 성능을 내기 위해 전력을 30% 더 적게 쓴다.  애...

애플실리콘 맥북에어 맥북프로 M1칩 M2칩 M2프로 M2맥스 M2익스트림 맥프로

2022.11.18

2023년 M2 칩보다 효율성과 성능이 함께 개선된 M2 프로(Pro), 맥스(Max), 울트라(Ultra), 익스트림(Extreme) 칩이 출시될까? 이에 대한 여러 주장과 루머가 혼재하고 있다.    애플이 지난 28일(현지 시각) 발표한 4분기(7월~9월) 실적에 따르면, 맥(Mac) 제품군의 매출은 지난해 같은 기간보다 25%나 상승했다. M2 칩을 탑재한 맥북에어는 올해 7월 등장했다.  <맥월드> 기자 제이슨 크로스는 M2 맥북에어가 M1 맥북에어의 성공을 이을만한 제품이며 “대부분 사용자가 마음에 들어 할 일상적인 컴퓨터”라고 평가했다.  하지만 M2 맥북 에어에 대한 칭찬은 곧 스로틀링(throttling)에 대한 보도로 뒤덮였다. 여러 기사에서 성능 단점과 "심각한" 스로틀링 문제, "열을 감당할 수 없다"라고 지적했고, 신형 맥북 에어의 발열 문제를 보여주는 동영상도 잇달아 나왔다.    독일 하드웨어 전문매체 노트북체크(Notebookcheck)는 M2의 공정 노드가 M1과 같이 5nm에 머물러 있다는 점이 발열의 원인이라고 지적했다. 애플은 공식 발표에서 M2의 CPU가 M1보다 약 18% 더 빠르다고 주장했는 데, 노트북체크가 분석한 결과 M2가 성능을 18% 끌어올린 방식은 오로지 클럭스피드를 높여서다. 시험 결과에 따르면 M2 칩은 18% 더 높은 CPU 성능을 내기 위해 평균 40% 더 많은 전력을 소비한다. 결과적으로 M1에 비해 효율성이 떨어지며, 고성능 작업을 할 때 발열이 더 많이 생길 수밖에 없다고 노트북체크는 설명했다.   이러한 가운데 개선된 공정의 M2 후속칩에 관심이 집중되는 양상이다. M2 후속칩은 M1의 5nm 대신 3nm 공정으로 설계될 것으로 예상된다. TSMC에 따르면 3nm 공정은 5nm에 비해 15% 더 빠르며, 같은 성능을 내기 위해 전력을 30% 더 적게 쓴다.  애...

2022.11.18

시스코가 소프트웨어 개발 과정에서 API 보안성을 확보한 방법

시간 낭비를 줄일 줄 아는 소프트웨어 개발자는 재사용할 수 있는 마이크로서비스와 그에 부합하는 API를 애플리케이션 구성요소의 기본 재료로 활용한다. 시스코의 개발자 관계/전략/경험 담당 VP 그레이스 프란시스코는 “개발자들은 이미 훌륭한 솔루션이 나와 있는 것을 재구축하는 것보다 직접 제공할 수 있는 부가 가치에 집중하고 싶어 한다. 이런 작업을 쉽게 만드는 API는 그만큼 개발자들이 소비하기 쉽다”라고 말했다.   말 그대로 개발자들은 API를 소비하고 있다. 2020년 슬래시데이터(SlashData) 설문 조사에 따르면, 거의 90%의 개발자들이 API를 어느 정도 사용하는 것으로 나타났다.  혼돈의 API 환경 API를 활용한 소프트웨어 개발 방식은 효율성이 높지만, CISO의 밤잠을 설치게 하는 보안 취약점으로 이어지기도 한다. 상호 의존적인 SaaS, 마이크로서비스, 내외부 API가 도입되면서 기업 입장에서는 이용되는 API를 파악하고 통제하는 것에 더욱 어려움을 겪고 있다. 서로 어지럽게 연결된 클라우드 네이티브 아키텍처는 “이 난장판은 너무 크고 너무 깊고 너무 높다”라고 한 닥터 수스의 말을 연상케 한다. 이런 난장판은 확장되기도 한다. API는 온프레미스 또는 클라우드에 있는 다수의 플랫폼에 걸쳐 자주 분산된다. 클라우드 네이티브 아키텍처는 강력한 보안 경계가 있는 하나의 깔끔한 단위로 몰아넣을 수 없다. 더 심한 문제는 API 자체의 보안 수준이 일정하지 않다는 점이다. 내부 및 외부 API 모두 취약하며, 코드가 취약한 API에 간접적인 의존성을 가지는 경우도 있다. API 취약성이 발생할 수 있는 계층은 클라우드 보안 태세부터 애플리케이션이 구축된 이미지, 클라우드 네이티브 애플리케이션의 구성, 애플리케이션 자체를 구성하는 소프트웨어, 클라우드 네이티브 애플리케이션의 내외부 통신을 가능하게 하는 API 구현에 이르기까지 다양하다. CI/CD 파이프라인을 중심으로 한 오늘날의 애자일 개발 문화에서는 ...

시스코 API 데브섹옵스 CSO50어워드

2022.11.18

시간 낭비를 줄일 줄 아는 소프트웨어 개발자는 재사용할 수 있는 마이크로서비스와 그에 부합하는 API를 애플리케이션 구성요소의 기본 재료로 활용한다. 시스코의 개발자 관계/전략/경험 담당 VP 그레이스 프란시스코는 “개발자들은 이미 훌륭한 솔루션이 나와 있는 것을 재구축하는 것보다 직접 제공할 수 있는 부가 가치에 집중하고 싶어 한다. 이런 작업을 쉽게 만드는 API는 그만큼 개발자들이 소비하기 쉽다”라고 말했다.   말 그대로 개발자들은 API를 소비하고 있다. 2020년 슬래시데이터(SlashData) 설문 조사에 따르면, 거의 90%의 개발자들이 API를 어느 정도 사용하는 것으로 나타났다.  혼돈의 API 환경 API를 활용한 소프트웨어 개발 방식은 효율성이 높지만, CISO의 밤잠을 설치게 하는 보안 취약점으로 이어지기도 한다. 상호 의존적인 SaaS, 마이크로서비스, 내외부 API가 도입되면서 기업 입장에서는 이용되는 API를 파악하고 통제하는 것에 더욱 어려움을 겪고 있다. 서로 어지럽게 연결된 클라우드 네이티브 아키텍처는 “이 난장판은 너무 크고 너무 깊고 너무 높다”라고 한 닥터 수스의 말을 연상케 한다. 이런 난장판은 확장되기도 한다. API는 온프레미스 또는 클라우드에 있는 다수의 플랫폼에 걸쳐 자주 분산된다. 클라우드 네이티브 아키텍처는 강력한 보안 경계가 있는 하나의 깔끔한 단위로 몰아넣을 수 없다. 더 심한 문제는 API 자체의 보안 수준이 일정하지 않다는 점이다. 내부 및 외부 API 모두 취약하며, 코드가 취약한 API에 간접적인 의존성을 가지는 경우도 있다. API 취약성이 발생할 수 있는 계층은 클라우드 보안 태세부터 애플리케이션이 구축된 이미지, 클라우드 네이티브 애플리케이션의 구성, 애플리케이션 자체를 구성하는 소프트웨어, 클라우드 네이티브 애플리케이션의 내외부 통신을 가능하게 하는 API 구현에 이르기까지 다양하다. CI/CD 파이프라인을 중심으로 한 오늘날의 애자일 개발 문화에서는 ...

2022.11.18

IDG 설문조사

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