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.
TOPIC

개발자

라즈베리 파이 4 가격 인상…"반도체 부족난 여파"

전 세계를 강타한 하드웨어 공급난의 기세가 여전히 사납다. 반도체 부족으로 그래픽 카드부터 자동차에 이르기까지 거의 모든 제품의 생산량이 영향을 받고 있다. 초소형 독립형 칩인 라즈베리 파이도 예외가 아니다. 라즈베리 파이는 최신 모델의 가격 인상을 예고했다. 라즈베리 파이가 판매 중인 제품의 가격을 인상한 것은 처음 있는 일이다.   라즈베리 파이 CEO 이벤 업튼은 블로그를 통해 가격 인상의 원인으로 반도체 부족을 지목했다. 가장 최신 모델인 라즈베리 파이 4 2GB 버전의 정가는 1년 반 전 출시 당시보다 10달러 오른 45달러가 되었다. 2020년 2GB 모델이 대체한 1GB 버전이 원래 가격인 35달러에 판매될 예정이다. 업튼은 부품 재고가 한정되어 있어 컴퓨트 모듈 3과 3+ 생산에 집중하겠다고 발표했다. 컴퓨트 모듈 3 제품군은 파이 보드에 노트북용 DDR 2 RAM을 추가해 기업에서 좋은 반응을 얻었다. 라즈베리 파이 3B+가 생산 우선순위에서 밀려났기 때문에 이베이 등 중고 유통업체를 통해 구입해야 할 가능성이 크다. 다만 업튼은 가격 인상과 수급난이 일시적인 현상이라고 일축했다. 향후 더 이상의 가격 인상 가능성을 배제하지는 않았지만, 상황이 정상화되면 원래 가격으로 인하할 예정이라고도 밝혔다. 또한, 향후 12개월 안에 28나노 공정 칩 수급이 원활해지고 공급망 상황이 완화될 것이라는 신호가 있다고도 언급했다. editor@itworld.co.kr 

라즈베리파이 라즈베리파이4 2021.10.21

테스트 자동화에서 데이터, 분석, 머신러닝을 사용하는 3가지 방법

불과 10년 전만 해도 대부분의 애플리케이션 개발 테스트 전략은 비즈니스 로직을 검증하기 위한 단위 테스트, 사용자 경험을 확인하기 위한 수동 테스트 케이스, 그리고 성능과 확장성을 검사하기 위한 별도의 부하 테스트 스크립트를 중심으로 이뤄졌다. 클라우드 인프라와 마이크로서비스 아키텍처, 지속적 통합 및 지속적 제공(CI/CD) 자동화, 지속적 테스트 기능을 기반으로 하는 지금의 개발 방식에 비하면 기능 개발과 릴리스 속도는 느릴 수밖에 없었다.    또한 지금은 많은 애플리케이션이 SaaS로 제공되거나 로우코드 및 노코드 애플리케이션을 구축하는 방법으로 개발된다. 이 경우에도 기반 비즈니스 흐름과 프로세스에 대한 테스트는 필요하다.  데브옵스 조직의 애자일 개발팀은 기능 개발 주기를 단축하고 제공 빈도를 높이고 고품질 사용자 경험을 보장하는 것을 목표로 한다. 관건은 새로운 테스트 복잡성과 배포 병목, 보안 틈새나 상당한 비용 증가를 수반하지 않으면서 위험성과 시프트 레프트(shift-left) 테스트를 줄이는 방법이다. 코파도(Copado)의 제품군 관리자인 에스코 하눌라는 증가하는 테스트 규모에 대처하기 위한 열쇠는 머신러닝이라면서 “디지털 비즈니스의 품질은 곧 코드와 코드를 실행하는 테스트의 품질이다. 테스트할 코드가 많을수록 머신러닝을 사용한 테스트 자동화의 중요성도 커진다. QA 인력과 기계의 지능이 서로를 지원해 단순한 직감이 아닌 데이터에 근거해 더 현명한 의사 결정을 내릴 수 있다”고 말했다.  필자는 마이크로서비스를 구축하거나 다수의 서드파티 API와 접속할 때 서비스 가상화를 사용해 더 견고한 웹 서비스 테스트를 개발하는 방법을 소개한 바 있다. 여기서 한 걸음 더 나아가 개발팀과 QA 테스트 자동화 엔지니어가 더 견고한 테스트를 개발하고 지원하기 위해 활용할 수 있는 데이터, 분석, 머신러닝 기반의 테스트 기능을 소개한다. 이와 같은 기능은 새로운 영역이고 테스트 플랫폼에 따라 이미 견실한 기...

테스트자동화 AI옵스 시프트레프트 2021.10.20

애자일 부서 설득하기 "기술 부채 인식이 최우선"

지난 몇 년 동안 클라우드 네이티브 마이크로서비스 아키텍처를 다룬 전도유망한 신생업체가 아니라면, 나머지 애자일 개발 부서는 아마 기술 부채 해결에 끙끙 앓고 있을 것이다. 기술 부채는 애플리케이션 및 서비스, 데이터베이스, 인프라 등에 골고루 엮여 있고 규모와 위험, 복잡성, 그리고 비즈니스에 미치는 영향도 다양하다. 기술 부채는 신기능 개발, 고객 경험 향상, 보안 문제 해결, 신뢰성 개선, 성과 증진, 워크플로 자동화, 기타 비즈니스 우선순위 해결 등 다양한 부서의 과업을 가로막는 과제로 작용하고 있다.     기술 부채란 무엇인가? 기술 부채의 정의와 의미는 다양하다. 간단하게 보면 리팩터링이 필요한 코드의 일부분이나 업그레이드가 필요한 라이브러리, 수정이 필요한 유닛 테스트 등이다. 더욱 고차원적인 기술 부채에는 복잡한 일체형 애플리케이션 재설계, 구식 웹 서비스 프로토콜 복사, 단일 표준에 통합된 복수의 플랫폼, 데이터 부채 문제 정리, 인프라 현대화, 관찰 가능성 방식 도입, 밀려 있는 수동 테스트 사례 자동화 등이 속한다. 이중 최악의 유형은 회사에 영향을 미치는 사건과 가동 중단이 반복되는 플랫폼이다. 필자가 간단히 정의하는 기술 부채란 전략적 비즈니스 요건을 구현하기 전이나 구현 단계 중에 프로덕션 단계에서 실행되는 기술에 수정, 리팩터링, 현대화, 업그레이드, 재설계, 또는 교체가 필요한 것을 말한다.   기술 부채가 애자일 개발 부서에 영향을 미치는 방식 기술 부채를 해결해야 하는 애자일 부서와 스크럼 부서가 직면한 난제는 다음과 같다. 조직마다 애자일 채택 방식이 많지만, 대부분의 애자일 방법론에서는 고객과 이해관계자의 필요에 따라 밀린 일의 우선순위를 설정할 책임을 제품 소유자에게 부여한다. 최상의 경우라면 제품 소유자가 경청하고 학습하고 질문하면서 기술 부서와 협력하여 기술 부채를 해결할 것이다. 기술 부채를 우선시하려면 제품 관리 그룹(제품 관리자 및 소유자 포함)은 밀린 일의 우선순위를 확립할 ...

기술부채 클라우드네이티브 마이크로서비스아키텍처 2021.10.18

히포를 이용한 웹어셈블리 입문

웹어셈블리(WebAssembly, WASM)는 마이크로소프트의 클라우드 네이티브 컴퓨팅팀, 구체적으로는 (마이크로소프트가 인수한) 다이스 랩(Deis Labs)과 애저 모두에서 크게 주목하고 있는 매우 유망한 신기술이다. 새로운 웹어셈블리 툴이 속속 출시됨에 따라 이 툴을 사용할 수 있는 환경에 대한 요구도 커지고 있다.   다이스 랩의 새로운 히포 웹어셈블리(Hippo WebAssembly) 플랫폼 출시가 중요한 것도 바로 이 지점이다. 다이스의 많은 툴처럼 내부 팀의 필요에 의해 만들어졌기 때문에, 브라우저 호스트든 독립 실행형 웹어셈블리 시스템 인터페이스(WASI)든 관계없이 WASM 코드를 신속하게 설치, 관리, 실행할 수 있다. 깃 서버와 함께 빌트인 채널을 사용해 한 환경에서 서로 다른 릴리스를 만들고 배포할 수 있으며, 프로덕션, 스테이징 및 개발 빌드를 별도로 유지하면서 히포 서버를 하나만 운영하는 것도 가능하다. 히포를 이용하면 여러 애플리케이션을 호스팅할 수 있다. 단, 웹어셈블리는 기본적으로 샌드박스가 적용되므로 호스트 시스템 또는 외부 장치에 액세스할 수 있는 명시적 권한이 필요하다. 코드도 다른 플랫폼으로 이식할 수 있다. 일단 웹어셈블리용으로 컴파일하면 윈도우, 리눅스, 맥OS는 물론 인텔, RISC-V, ARM에 상관없이 모든 웹어셈블리 시스템에서 실행할 수 있다. 즉, 히포는 코드를 한번 작성해 테스트하면 어디서든 실행할 수 있는 방법을 제공한다.   개발 PC에서 히포 설정하기 히포와 같은 툴은 클라우드 네이티브로 운영하는 것이 이상적이지만, 현재 개발자 릴리스는 데스크톱 시스템에서만 사용할 수 있다. 여기서는 우분투를 호스팅하는 WSL2의 최신 빌드를 실행하는 윈도우 PC를 기준으로 진행한다. 다이스는 히포를 로컬에서 실행하는 방법에 대한 설명과 맥OS 및 리눅스 시스템에서의 사용법에 대한 자세한 정보를 제공한다. 반면 필자가 WSL2 우분투 20.04 LTS 시스템에서 히포를 실행할 때는 몇 가지 문제...

히포 웹어셈블리 Hippo 2021.10.18

IDG 블로그 | “사이드로딩은 보안과 개인정보보호에 취약” 애플 백서 발표

애플이 사이드로딩(sideloading)을 허용하라는 압박에 강경히 맞서고 있다. 13일(현지시간) 애플은 28쪽 분량의 백서 ‘수백만 앱을 위한 신뢰할 만한 생태계 구축하기-사이드로딩 위협 분석’을 발표해 사이드로딩이 보안과 개인정보를 위험에 빠뜨릴 것이라고 경고했다.   사이드로딩의 위험성 백서에 따르면, 아이폰 및 기타 애플 기기는 사용자의 개인정보를 보유하고 있기 때문에 보안과 프라이버시를 보호하는 것이 매우 중요하다. 애플은 “외부 사이트나 서드파티 앱스토어에서 사이드로딩을 허용하면 아이폰의 안정성을 유지하는 보안 및 개인정보보호 기능이 제 역할을 하지 못할 것이다. 사용자가 심각한 보안 위협에 노출될 수 있다”라고 우려했다. 이에 앞서 유럽과 미국 의회는 애플이 사이드로딩을 허용해야 한다고 주장했다. 특히 유럽위원회는 디지털 시장법 초안을 발표하며 압박을 넣는 중이다. 반면 애플은 사용자와 플랫폼에 피해가 생길 것을 우려해 사이드로딩을 거부하고 있다.  애플은 지난 6월에도 비슷한 내용의 보고서를 발행한 바 있다. 이 보고서에서 애플은 검증된 앱스토어의 장점을 나열하며 검증 부족에 따른 중대한 위험성을 경고했다. 사이드로딩 비판론자들은 앱스토어의 검증이 완벽하지는 않지만, 없는 것보다는 낫다고 주장한다. 이번에 공개한 백서에서 애플은 안드로이드가 아이폰보다 악성코드 공격을 47배 많이 받고 있다는 내용의 노키아 연구 결과를 인용했다. 또 하루에 23만 건의 모바일 악성코드 감염 사례가 발생한다는 유럽 규제 기관의 통계도 언급했다. 애플에 특화된 사이버 범죄의 출현 가능성 모바일 악성코드는 안드로이드 스마트폰을 주된 공격 대상으로 삼는다. 최근에는 안드로이드 스마트폰이 악의적인 소프트웨어에 감염된 횟수가 아이폰보다 15~47배 많았다. 한 연구에 따르면 모바일 악성코드 공격 대상의 98%는 안드로이드 기기라고 한다. 애플은 “안드로이드가 악성코드에 자주 노출되는 이유는 사이드로딩과 밀접한 관련이 있다. 예컨대 지난 20...

애플 사이드로딩 사이드로드 2021.10.14

리눅스 재단, 비전문가∙초급자용 쿠버네티스 공인 자격증 개설 예고

리눅스 재단과 클라우드 네이티브 컴퓨팅 재단이 네 번째 쿠버네티스 공인 자격 시험 프로그램을 시작한다. 초급 공인 자격증에 대한 엄청난 수요를 반영해 내린 결정이다.   쿠버네티스 및 클라우드 네이티브 어소시에이트(KCNA) 자격증 시험은 올해 말 베타 테스트를 거쳐 초급 개발자, 또는 기술 마케팅 전문가나 제품 관리자처럼 개발 관련 직업 종사자가 아니지만 오픈소스 컨테이너 오케스트레이션 기술에 관심이 있는 사람을 대상으로 시행될 예정이다. 새 자격 시험은 CNCF와 리눅스 재단이 실시하는 기존의 공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD), 공인 쿠버네티스 관리자(Certified Kubernetes Administrator, CKA)와 공인 쿠버네티스 보안 전문가(Certified Kubernetes Security Specialist, CKS)에 추가되나 전문 지식을 활용할 숙련된 경험자를 대상으로 하지 않는다는 점에서 차이가 있다. 자격 시험은 컨테이너부터 팟, 노드, 클러스터에 이르기까지 다양한 쿠버네티스 용어와 기본 구조, 명령어를 활용한 소프트웨어 애플리케이션 배포와 제반 지식을 묻는 여러 종류의 테스트로 구성될 예정이다. 보안적 고려 사항을 포함해 클라우드 네이티브 전반적인 이해도 필요하다. 리눅스 재단의 교육 및 인증 담당자 클라이드 시퍼새드는 KCNA 자격증은 클라우드 기술을 다루는 직업을 고려하는 사용자에게 명확한 진입로를 제공하고, 클라우드 관리, 엔지니어링, 애플리케이션 개발과 보안 등 다양한 분야에서 경력을 시작할 수 있는 첫 번째 단계가 될 것이라고 밝혔다. editor@itworld.co.kr 

쿠버네티스 리눅스재단 교육 2021.10.14

파이썬, 10월 티오베 지수·PyPL 모두 1위

파이썬이 10월 티오베 지수에서 선정한 프로그래밍 언어 인기 순위(Programming Language PopularitY)에서 1위를 차지했다. 20년 넘는 기간 동안 티오베 지수 1위를 차지한 언어는 파이썬을 포함해도 3개뿐이다. 지난주 발표된 10월 지수에서 파이썬은 2001년 이후 티오베 지수에서 줄곧 선두를 양분한 C와 자바에 이어 1위에 올랐다. 프로그래밍 언어 인기 순위는 구글, 빙, 야우, 위키피디아 등의 검색 엔진의 프로그래밍 언어 관련 검색 결과를 바탕으로 결정된다.   최근 파이썬의 상승세는 꾸준했다. 소프트웨어 품질 서비스 업체이기도 한 티오베는 파이썬 생태계가 건전하고, 사용하기 쉬우며 라이브러리가 풍부하고 편집-실행 주기가 빠르다고 평가했다. 동시에 “C와 자바가 양분하던 프로그래밍 언어 쌍두마차 시대는 끝났다”고 언급했다. 티오베는 향후 몇 개월간 C와 엎치락 뒤치락할 수는 있겠지만 결국 파이썬이 최고의 자리를 한동안 유지할 것이라고 내다봤다. 파이썬은 구글의 언어 자습서 검색 결과를 바탕으로 산출하는 PYPL(PopularitY of Programming Language) 지수에서도 1위를 차지했다. 2021년 10월 티오베 지수 선정 상위 10위 언어는 다음과 같다. 1. 파이썬 (11.27%) 2. C (11.16%) 3. 자바 (10.46%) 4. C++ (7.5%) 5. C# (5.26%) 6. 비주얼 베이직 (5.24%) 7. 자바스크립트 (2.19%) 8. SQL (2.17%) 9. PHP (2.1%) 10. 어셈블리 (2.06%) 또한, 2021년 10월 PYPL 지수 상위 10위 결과는 다음과 같다. 1. 파이썬 (29.66%) 2. 자바 (17.18%) 3. 자바스크립트 (8.81%) 4. C# (7.3%) 5. C/C++ (6.48%) 6. PHP (5.92%) 7. R (4.09%) 8. 오브젝티브-C (2.24%) 9. 타입스크립트 (1.91%) 10. 코틀린 (1.9%) editor@...

파이썬 프로그래밍언어 티오베 2021.10.13

“애플도 항소” 애플 vs. 에픽 소송 재점화

지난 9월 에픽과의 소송 결과에 대해 ‘완승’이라고 자평하던 애플이 8일(현지시간) 항소를 결정했다. 에픽도 항소 절차를 밟고 있는 가운데, 그간의 법적 공방이 다시 한번 반복될 예정이다. 따라서 앱스토어 정책에 근본적인 변화가 생기려면 아직 시간이 더 필요할 것으로 보인다.   애플이 항소를 결정한 가장 큰 이유는 애플이 캘리포니아 독점규제법에 따라 관련 시장에서 반경쟁 활동을 벌인다고 본 미국 법원의 판결이다. 담당 판사 이본 곤잘레스 로저스는 법규를 어긴 애플에 ‘개발사가 자사 앱과 메타데이터 버튼, 외부 링크, 고객을 구매 메커니즘으로 유도하는 행동을 포함하는 것을 제한하는 행위’를 중단할 것을 명령했다. 즉, 애플은 오는 12월 9일까지 개발자가 자체 구매 서비스, 혹은 외부 스토어로 연결되는 링크를 삽입하는 것을 허용해야 한다. 인앱 결제 제한은 애초에 애플과 에픽 간 소송이 시작된 이유이기도 하다.   더불어 법원은 ‘연방 또는 주 독점 금지법’에 따라 애플은 독점 기업이 아니며, 애플이 앱스토어 수수료로 30%를 받는 사업 모델은 합법적이라고 판단했다. 결과적으로 에픽은 벌금 600만 달러를 애플에 지불했다. 에픽이 앱스토어 이용약관을 먼저 위반하지 않고, 지난 2020년 8월 앱스토어에서 퇴출당하지 않았을 경우 지급했어야 할 수수료다. 에픽은 사실상 애플에 승리를 안겨준 법원 판결에 항소했다. 에픽 CEO 팀 스위니는 지난해부터 이어진 법적 공방에서 강경한 의견을 밝혔으며, 애플 측에 포트나이트 앱스토어 재승인을 요구했으나 거부당했다. 스위니는 자신의 트위터에 애플의 항소를 비꼬는 게시물을 올렸다. 아울러 애플은 “법원 명령을 이행하면 고객과 전체 플랫폼에 의도치 않은 파급효과가 발생할 수 있다”라며 항소가 종료될 때까지 외부 결제 링크 허용 조치를 유보해달라고 요청했다. 법원이 양측의 항소를 인정함에 따라 인앱 결제를 둘러싼 애플과 에픽의 소송은 사실상 원점으로 돌아왔다. 판결이 확정될 때까지 한동안 공방이 계속될 ...

애플소송 애플 에픽 2021.10.12

IDG 블로그 | 데브옵스로 성과를 올리는 조직의 특징

구글이 최신 데브옵스 보고서 ““Accelerate State of DevOps 2021”을 발표했다. 보고서는 하이브리드 또는 멀티클라우드를 사용하는 응답자가 성과 목표를 1.6배 초과 달성할 가능성이 크다고 밝혔다. 이들 “우수 성과자”는 성과가 낮은 기업보다 애플리케이션을 워크로드 배치 작업을 무려 973배 더 자주 수행했다. 배치에 걸리는 시간도 6,570배 더 빠르고 작업이 실패할 확률도 세 배나 낮은 것으로 나타났다. 또한 실패가 발생했을 때 복구하는 시간도 6,570배 더 짧았다.   보고서에 따르면, 지속적인 테스트와 지속적인 통합 두 가지 모두가 성공의 핵심 요소이며, 이외에 또 하나의 성공 요소는 트렁크 기반 개발(trunk-based development)이다.  트렁크 기반 개발은 개발 소스 제어 모델의 하나로, 개발자가 ‘트렁크’라는 단일 브랜치의 코드 상에서 협업하고, 해당 트렁크 내로의 작업을 제한한다. 코드의 결합과 통합 단계를 최적화하기 위한 방법론이다. 이 개발 프로세스는 CI/CD 서비스의 최적화를 강화해 결과적으로 소프트웨어 전달의 효율성을 높여준다. 보고서는 또한 우수 성과자는 데이터베이스 변경 관리를 3.4배 더 많이 했다고 밝혔다. 데이터베이스 관리 역시 핵심 성공 요소 중 하나라고 볼 수 있다. 관찰 가능성은 우수 성과자를 정의하는 또 하나의 지표이다. AI옵스 같은 관찰 가능성 툴을 이용하는 조직은 솔루션에 이런 개념과 기술을 통합할 가능성이 4.1배 더 높다. 이제 이 모든 성공 요소의 의미를 짚어보자. 가장 먼저, 그리고 확실하게 눈에 띄는 것이 있다. 하이브리드 클라우드 또는 멀티클라우드를 사용하는 조직은 데브옵스 베스트 프랙티스와 툴체인을 배치할 가능성이 훨씬 더 크다. 이런 시나리오에서는 위험성 역시 커지는데, 클라우드 기반 데브옵스 툴이나 데이터베이스, 관찰 가능성 툴 등 새로 등장한 기술을 시험하는 데는 비용이 들기 때문이다. 신기술을 이용할 수 있는 역량은 조직이 미래를 위...

데브옵스 트렁크기반개발 멀티클라우드 2021.10.12

클라우드 네이티브 앱과 마이크로서비스가 개발 프로세스에 미치는 영향

필자는 객체 지향 프로그래밍, 3계층 웹 플랫폼, 서비스 지향 아키텍처(SOA), 그리고 데이터센터에 가상 서버를 호스팅하던 시절에 실무 개발자와 최고 기술 책임자로 종사했다.   그 시절 이후 너무 많은 것이 변했다.   앞서가는 소프트웨어 개발 부서는 마이크로서비스를 개발하고 클라이언트 측 자바스크립트를 사용해서 풍부한 프런트 엔드 사용자 경험을 실현한다. 호스팅 옵션은 대폭 증가해서 이제 서비스형 플랫폼(PaaS), 서비스형 컨테이너(CaaS), 서버리스 함수를 비롯한 다양한 아키텍처를 포함한다. 개발자들이 만드는 애플리케이션은 실시간 데이터 스트림을 활용하고 머신러닝 모델과 연결되고 SaaS 및 엔터프라이즈 시스템과 접속한다.     개발 툴도 많이 발전했다. 툴은 전 세계 곳곳에 분산된 개발 부서가 독립적으로 작업하고 빈번하게 변경 사항을 릴리스하고 신속하게 문제에 대응할 수 있게 해준다. 지속적 통합과 지속적 배포(CI/CD), 지속적 테스트, 코드형 인프라(IaC), AI옵스(AIops)를 통해 통합, 배포, 인프라 구성, 모니터링을 자동화할 수 있다.   이 변화에는 애자일의 지속적 계획 도입, 시프트-레프트 테스트 구현, 보안 위험에 대한 선제적 대처, 사이트 안정성 엔지니어링 등 문화적, 실무적 변화도 포함된다.   한층 더 깊게 들어가서 클라우드 네이티브 애플리케이션과 마이크로서비스를 구축하고 배포할 때 개발 프로세스를 어떻게 변경해야 하는지에 관한 최선의 방법을 알아보기 위해 여러 전문가들의 의견을 구했다.   빠른 속도에 필요한 것은 조율과 운영 인식 다수의 작고 원자적인, 또는 자주 배포되는 마이크로서비스 구축을 목표로 하는 개발 부서에 대한 필자의 첫 번째 우려는 이들의 배포 속도가 협업과 안전 가드레일을 감안하지 않는 경우다.   빅판다(BigPanda) CTO 제이슨 워커에게 마이크로서비스를 성공적으로 구축, 배포, 강화하는 개발 부서에 관한 경험을 들어봤다...

클라우드네이티브애플리케이션 마이크로서비스 서비스지향 2021.10.06

IT 인력 공백 메우는 '디지털 기술의 힘'

최근 맥킨지(McKinsey)의 설문조사에서 임원 중 약 90%가 현재 기술 공백을 경험하고 있으며 이 현상이 향후 몇 년 동안 지속될 것으로 예상된다고 밝혔다. 게다가 더욱 걱정스러운 것은 설문조사에서 임원 중 절반 이하가 이 문제를 해결할 방법을 명확히 모르고 있다는 점이다. 높은 수준의 디지털 기술을 가진 인재에 대한 수요는 적절한 자격을 갖춘 직원의 공급보다 크며, 그 격차는 점점 커지고 있다. WEF(World Economic Forum)는 2022년까지 혁신 기술을 통해 1억 3,300만 개의 새로운 일자리가 생겨나고 7,500만 개가 사라질 것으로 전망했다. 전 세계적가 기술 인재 부족 현상을 경험하고 있으며 이 문제를 해결할 조치를 취하지 않으면 비즈니스에도 큰 영향을 미칠 수 있다. 적절한 인재가 없는 기업은 혁신, 발전, 성장에 어려움을 겪을 것이다   임박한 디지털 기술 공백 코로나19로 인한 팬데믹 후 은행, 의료기업, 소매기업 등 모든 조직이 디지털화를 추진하고 있다. 디지털 기술은 더 이상 한 부서에만 필요한 것이 아니며, 몇 년 후에는 전 세계 거의 모든 일자리에서 필수요소가 될 것이다. 특히, 코딩, AI, 사용자 경험 디자인, 클라우드 컴퓨팅 등의 분야에서 IT 전문가 기술에 대한 수요가 크게 증가했다. 기업은 재능뿐 아니라 문화적으로 적합하고 기술을 활용해 문제를 해결하고 솔루션을 구축하기 위해 필요한 추가적인 협업적이며 혁신적인 기술을 가진 사람을 찾는 데 어려움을 겪고 있다. WEF는 또한 설문조사 후 비판적 사고 및 분석, 탄력성과 스트레스 회복, 유연성, 기술 디자인, 프로그래밍, 기술 사용 등  직업에 필요한 상위 10개 기술 목록을 공개했다. 인력의 기술 확보를 위해 응답자들은 근로자 중 40% 이상이 새로운 기술 교육이 필요하고 소요 기간은 6개월 이상으로 추정했다. 팬데믹으로 인해 신입 직원 중 과반수가 6개월 안에 퇴사하고 근로자 중 40%가 내년에 퇴사 또는 이직을 고려하는 상황에...

기술공백 포스트팬데믹 HR 2021.10.01

MS, 서피스 듀오 앱 강화 위해 개발 도구와 지침 공개

마이크로소프트가 지난 22일 서피스 듀오 2를 출시한 데 이어, 현재 베타 단계에 있는 ‘젯팩 윈도우 관리자(Jetpack Window Manager)’를 사용해 듀얼 스크린과 폴더블, 대형 스크린 기기에 맞게 애플리케이션을 조정하도록 권고했다. 특히, 기업용 서피스 듀오 시스템 구축 및 강화를 요청했다.   젯팩 윈도우 관리자는 폴더블 기기에 표준 API를 제공하며, 2가지 중요한 클래스를 포함한다. 연속적인 평면 스크린의 힌지나 접힘 등 표면상 균열을 찾아내는 ‘DisplayFeature’와 기기가 접힌 상태의 정보를 제공하는 ‘FoldingFeature’가 바로 그것이다. FoldingFeature 클래스는 단일 코드 기반으로 각기 다른 듀얼 스크린 및 폴더블 기기에 적용되도록 앱에 기기별 정보를 준다. 여기에는 모든 서피스 듀오 모델이 포함된다. 서피스 듀오 2는 이전 모델과 비교해 5G를 지원하고, CPU 속도와 3가지 후면 카메라, 화면 크기와 밝기가 개선됐다. 서피스 듀오 디자인 키트(Surface Duo Design Kit)는 듀오 2 시스템에서 각각 다른 크기의 화면을 지원하도록 업데이트됐다. 화면 해상도 변경 사항은 로드, 레이아웃, 리소스에 사용되는 리소스 한정자에 반영됐다. 서피스 듀오 2 안드로이드 에뮬레이터(Surface 2 Android emulator)도 발표했다. 이 기능은 안드로이드 11을 실행하는 듀얼 스크린 환경을 제공하고 ‘3D 모드’ 보기에서 힌지를 시뮬레이션하며, 멀티 터치 및 펜 감도를 지원한다. 에뮬레이터는 윈도우와 리눅스, 맥OS에서 사용할 수 있으며, 안드로이드 스튜디오, 비주얼 스튜디오, 비주얼 스튜디오 코드, 안드로이드 개발에 사용되는 기타 IDE와 함께 작동한다. 한편, 마이크로소프트는 서피스 듀오 2 개발사에 젯팩 윈도우 관리자 사용 샘플, 윈도우 관리자와 젯팩 컴포즈(Jetpack Compose) 통합 가이드, 서피스 랩탑 스튜디오(Surface Laptop Studio) 개발 도구를 ...

마이크로소프트 서피스듀오 젯팩윈도우관리자 2021.09.30

글로벌 칼럼 | 유지보수를 위한 다운타임, '유지보수 윈도우'는 정당화할 수 없다

몇 년 전에 집에서 사용할 디지털 '스마트' 온도조절기를 구입했다. 집에 없을 때 원격으로 온도를 설정하고 확인하기 위해서였다. 제품을 설정하고 제조업체 클라우드 백엔드에 연결하는 과정 모두 문제없이 원활했다. 잘 샀다고 생각했다.   몇 주 뒤에 해당 제조업체로부터 서비스 업그레이드 예정에 관한 이메일 한 통을 받았다. 업그레이드하는 몇 개월 동안에는 '한 번에 몇 시간 동안' 애플리케이션을 중단시킬 수 있으며 이는 '하루 중 다양한 시간대에 발생할 수 있다'는 내용이었다(시간은 명시되지 않음). 물론 이 업체는 불편함에 대해 미리 사과했다. 언제든 갑자기 몇 시간 동안 온도조절기 작동이 멈출 수 있고, 그런 상황이 몇 개월 동안 지속된다는 이야기다. 필자는 다음 날 바로 온도조절기를 다른 회사 제품으로 교체했다. 그런 수준의 형편없는 서비스를 감내할 수는 없었기 때문이다. 가용성은 중요하다 필자의 아들은 미국 정부에 의무적으로 수입을 신고해야 한다. 아들은 이를 위해 휴대폰 애플리케이션을 사용한다. 한 달에 한 번 애플리케이션에 로그인해서 이전 달 수입을 신고한다. 그런데 이 아이폰 애플리케이션에는 중대한 문제가 있다. 앱이 작동하지 않는 시간이 있고 그 시간에 실행하면 '이 애플리케이션은 미동부표준시 월~금요일 오전 8시부터 오후 5시까지 작동한다'는 메시지가 표시된다. 이게 무슨 소리인가? 말 그대로다. 이 온라인 SaaS 기반 애플리케이션은 '일반 영업 시간'동안에만 작동한다. 결과적으로 애플리케이션을 사용하기가 매우 어렵다. 애플리케이션 사용 시간을 이렇게 제한하는 이유가 무엇일까? 정부 기관이니만큼 애플리케이션을 지원할 사람이 사무실에 없는 시간에는 동작하지 않도록 했을 것이다. 뭔가 잘못되더라도 사무실에 아무도 없으니 고칠 수 없지 않은가? 계획된 다운타임도 다운타임이다 앞서 설명한 두 가지 사례는 극단적이지만 많은 온라인 애플리케이션의 공통적인 문제를 보여준다. 애플리케이션을 운영하는 기업이 유지보수와 업그레이드를 위해 '유...

유지보수윈도우 Maintenance windows 2021.09.29

유무료 API 보안 테스트 도구 10선

API(Application Programming Interfaces)는 대부분의 현대적인 프로그램과 애플리케이션에서 핵심적인 요소다. 클라우드 환경과 모바일 애플리케이션 모두 이제 API에 대한 의존도가 높아져, 구성요소를 관리하는 API의 개입은 필수적이다. 많은 대기업, 특히 대형 온라인 기업의 인프라에는 수천 개의 API가 내장돼 있다. API는 앞으로도 계속 증가할 수밖에 없다.   API의 특징은 많은 API가 아주 소량의 코드로 구성되며, 네트워크 리소스 요구사항 측면에서 두드러지지 않도록 작게 설계된다는 점이다. 이와 동시에 API는 유연하고, 상호작용하거나 제어하는 프로그램이 패치 등으로 변경되는 경우에도 계속 동작하면서 맡은 역할을 수행할 수 있다. API는 이렇게 유용하지만 나름의 문제점도 있다. 한 가지 기능을 반복 실행하는 것부터 다양한 프로그램이나 플랫폼의 여러 측면을 현명하게 제어하는 것까지, API는 설계하기에 따라 거의 모든 일이 가능하다. 따라서 API 생성을 관리하는 표준이 사실상 없다. 대부분의 API가 고유하며, 많은 기업은 필요에 따라 무심코 새로운 API를 만든다. 보안 팀에는 API가 악몽이 될 수 있다. 공격자에 있어 API가 과도한 권한이 부여된 경우가 많다는 점이 매력적인 부분이다. 몇 가지 소수의 기능만 수행하는 API도 관리자에 준하는 특권을 가진 경우가 많다. 크기도 작은 API가 큰 피해를 끼칠 일은 없다고 무심히 생각하는 탓이다. 공격자는 API를 해킹한 다음 그 자격 증명을 데이터 유출이나 더 깊은 네트워크 침투와 같은 용도로 사용한다. 아카마이(Akamai)의 보안 연구에 따르면, 자격 증명 공격의 약 75%가 취약한 API를 겨냥했다.  문제는 갈수록 악화되고 있다. 가트너에 따르면, 2022년에는 API와 관련된 취약점이 모든 사이버보안 범주에 걸쳐 가장 빈번한 공격 벡터가 될 전망이다. 해답은 API 테스트 도구 핵심적인 네트워킹 및 프로그램 구성요소를 공격자들이 항...

API API보안 APIsec 2021.09.29

'살아 움직이는 언어' 자바에 추가된 6가지 새로운 기능

자바는 2018년 새로운 릴리즈 주기를 도입하면서 개발 측면에서 가장 큰 변화를 단행했다. 이 과감한 새로운 계획의 결과로 자바 개발자들은 6개월마다 새로운 기능 릴리즈를 받고 있다.   자바를 신선하고 현 시점에 맞는 언어로 유지하는 데는 분명 좋지만, 대신 새로운 기능을 놓치기도 쉽다. 새로이 추가된  유용한 기능 6가지를 대략적으로 살펴본다.     Optional 클래스 널 포인터 예외는 가장 전통적인 오류 가운데 하나다. 익숙한 문제지만 방지하기가 쉽지 않기도 하다. 그러나 자바 8에서 처음 소개되어 자바 10에서 더 개선된 Optional 클래스를 사용하면 더 이상 골칫거리가 아니다. 기본적으로 Optional 클래스는 변수를 래핑한 다음 래퍼의 메서드를 사용해서 널을 더 간편히 다룰 수 있게 해준다.   예시 1에는 흔한 널 포인터 오류의 예가 나와 있다. 클래스 레퍼런스인 foo가 널이고, 여기서 메서드인 foo.getName()이 액세스된다. 예시 1. Optional이 없는 널 포인터 public class MyClass {     public static void main(String args[]) {       InnerClass foo = null;       System.out.println("foo = " + foo.getName());     } } class InnerClass {   String name = "";   public String getName(){       return this.name;   } } ...

자바 JAVA 2021.09.28

마이크로소프트, 아태지역 9개국서 ‘장벽 없는 코딩’ 공개…“여성 기업가 육성”

마이크로소프트가 클라우드, 인공지능(AI), 디지털 기술 등 IT 산업의 인재 다양성 개선을 위해 13개 기업과 협력, 한국을 포함 아시아 태평양 9개 시장에 기술 인재 지원 프로그램 ‘장벽 없는 코딩(Code; Without Barriers)’을 선보인다고 밝혔다. 마이크로소프트 안드레아 델라 마테아 아시아 태평양 지역 사장은 “우리는 데이터 및 인공지능 전문가 가운데 오직 26%만이 여성이며 클라우드 컴퓨팅 전문가 부문에서는 여성 비율이 12%에 불과하다는 사실로부터 아태지역에서 긴급히 기술 인재의 다양성을 높여야 할 필요성을 발견했다”며, “이를 변화시키고 아태 시장이 진정으로 포괄적인 국가 디지털 의제를 갖게 하기 위해서는 장벽을 허물고 조직과 산업에서 개발자의 다양성을 강화하는 것으로부터 시작해야 한다”라고 말했다. ‘장벽 없는 코딩’ 프로그램은 커리어 박람회, 해커톤, 멘토링, 비즈니스 리더 지원 등으로 아태지역 여성 기업가를 육성할 예정이다. 이 프로그램은 여성 개발자, 코더 및 기타 기술 인재가 포괄적인 경제 성장에 기여할 수 있는 플랫폼을 제공한다. 이 프로그램은 한국, 싱가포르, 말레이시아, 인도네시아, 베트남, 태국, 필리핀, 스리랑카, 방글라데시에서 교육, 에너지, 금융 서비스, 공공 기관 및 기술 산업 등의 영역에서 운영된다. ‘장벽 없는 코딩’에는 액센츄어, 에이브포인트, HCL 테크놀로지 등 13개 조직이 파트너로 참여했으며, 이 조직들은 조직 내의 다양성을 개선하고 여성 크리에이터와 개발자에게 고용 기회를 제공하기 위해 최선을 다하기로 약속했다. 마이크로소프트는 클라우드 및 인공지능 분야에서 기술 교육 및 인증을 제공함으로써 각국의 기술 인재 풀을 늘릴 예정이다. 이 프로그램으로 아태지역 21개 이상의 개발자 커뮤니티와 협력해 데이터, 인공지능, 데브옵스, 자바, 자바스크립트, 파이썬, 위민 인 테크(Women in Tech)에 걸쳐 40만 7,000명 이상의 개발자를 지원한다. 이 프로그램은 이미 파일럿을 통해 8개...

마이크로소프트 2021.09.24

비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유

SQL 데이터베이스에서 데이터를 꺼내야 하는데, 이 데이터를 꺼내기 위해 여러 테이블 조인과 여러 필터 조건, 세밀한 WHERE 절이 포함된 복잡한 쿼리가 필요한 상황. 개발자라면 흔하게 부닥치는 장면이다. 물론 방법은 많다. 마이SQL, 포스트그레SQL과 같은 SQL 데이터베이스는 필요한 데이터를 쿼리로 정확히 끄집어내는 복잡한 조인과 필터링, 정렬 기능이 탁월하다. 원래 데이터베이스의 용도가 그것이기도 하다. 애플리케이션 코드에 로직을 집어넣는 방법보다 '훨씬' 쉽다. 하지만 이 방법은 틀렸다. 데이터베이스 내에서 이와 같은 작업을 수행하면 사실상 애플리케이션 비즈니스 로직을 데이터베이스 안에 밀어 넣게 된다. 애플리케이션 코드에서 비즈니스 로직을 꺼내 데이터베이스 로직으로 옮기는 것이다. 그 결과는? 원하는 데이터 결과를 추출하기 위해 사용하는 데이터베이스 리소스는 많아지고 애플리케이션 서버 리소스는 적어진다. 데이터 삽입 요구사항을 구현할 때도 마찬가지다. 보통 데이터베이스에 데이터를 넣을 때는 그 데이터가 유효하고 충돌하지 않으며 정확한지를 애플리케이션이 아닌 데이터베이스에서 수행한다. 충돌 조건을 데이터베이스 스키마 요구사항에 넣고, 삽입 중인 데이터에서 오류가 탐지되면 데이터베이스가 오류를 던지도록 한다. 예를 들어 UNIQUE 한정 조건과 인덱스를 사용하는 경우가 그렇다.   애플리케이션 리소스가 더 확장하기 쉽다 이런 문제를 제기하면 많은 데이터베이스 엔지니어가 반문하다. “원래 그렇게 사용하라고 있는 기능이다!”라거나 “그런 방식으로 처리해야 하는 것도 있다”고 주장한다. 분명히 말하지만, 필자 역시 데이터베이스에서 이와 같은 확인 및 검증을 수행해야 하는 경우도 있다는 것은 잘 알고 있다. 그래서 필자는 데이터베이스에서 애플리케이션 로직을 완전히 배제해야 한다고 말하는 것이 아니다. 데이터베이스가 애플리케이션 비즈니스 로직을 떠맡는 경우를 최소화하고, 할 수 있는 최대한 애플리케이션 코드 자체에서 애플리케이션 비즈니스 로직을...

비즈니스로직 2021.09.23

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

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

Copyright © 2022 International Data Group. All rights reserved.