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.

세상의 모든 IT 리서치 자료 - 넘버스 Numbers

검색 결과 약 24(0.08ms)
자료 출처 :
Stack Overflow
원본자료 다운로드
발행 날짜 :
2022년 06월 23일
주요 내용 :
스택 오버플로우(Stack Overflow)의 ‘2022 개발자 설문조사(2022 Developer Survey)’ 결과에 따르면 대부분의 개발자가 원격에서 작업하고 있으며, 좋아하는 기술을 쓸 수 있는 유연한 환경을 선호하는 것으로 나타났다.  대부분의 소프트웨어 개발자는 현재 적어도 일정 시간 원격근무를 하고 있으며, 작업 환경의 유연성이 그 어느 때보다 중요하게 여겨지고 있다. 한편 2022년 5월 스택 오버플로우 개발자 설문조사에는 전 세계 180개국 총 7만 3,268명이 참여했다.    ⓒ Getty Images Bank 개발자 채용 및 유지의 새로운 법칙 지난 2020년, 완전히 원격근무로 전환해야 했던 개발자 팀이 많았다. 이번 보고서에 의하면 약 85%의 개발자는 소속 조직이 완전(42.98%) 또는 최소한 부분적으로(42.44%) 원격근무를 하고 있다고 답했다. 대기업일수록 완전 원격근무보다는 하이브리드 근무를 하는 경향이 컸다. 스택 오버플로우의 CEO 프라샨트 찬드라세카는 인포월드와의 인터뷰에서 “전 세계가 하이브리드 및 원격근무로 가고 있다. 이번 데이터는 기차는 이미 떠났다는 사실을 보여준다. 작업 환경의 유연성 그리고 개발자가 쓰게 될 기술 스택은 직장 만족도에 가장 큰 영향을 미치는 요소인 것으로 조사됐다. 많은 개발자가 작업하게 될 기술 스택 때문에 채용 과정에서 중도 하차한다”라고 말했다. 한편 프리랜서 또는 개인 비즈니스를 하는 개발자가 작년보다 5%P 증가한 17%를 기록했다. 이 밖에 조직 문화도 변화하고 있으며, 클라우드 네이티브 기술이 인기를 끌었다. 대부분의 개발자의 현재 CI/CD(69.79%)를, 데브옵스 기능(59.35%), 자동화된 테스트(58.09%)를 사용하고 있다고 밝혔다. 하지만 필요한 도구 및 서비스를 쉽게 찾을 수 있는 내부 개발자 포털을 가지고 있다고 말한 개발자는 전체 응답자의 38%에 그쳤다. 아울러 내부 리소스 기술을 사용하여 코드와 지식을 공유한다고 답한 개발자도 16%에 불과했다.   개발자가 좋아하고 싫어하는 기술  이번 스택 오버플로우 설문조사에 따르면 ‘자바스크립트(JavaScript)’가 10년 연속 ‘가장 인기 있는(Most popular)’ 프로그래밍 언어로 선정됐다. ‘지난 1년 동안 어떤 프로그래밍 언어로 개발했는가?’라는 질문에 답한 7만 1,547명의 개발자 중 65.36%가 자바스크립트를 사용한다고 밝혔다. 하지만 자바스크립트가 ‘가장 사랑받는(Most loved)’ 언어는 아니다. 그 영예는 7년 연속 ‘러스트(Rust)’에 돌아갔다. 전체 응답자의 약 87%가 이를 계속 사용하고 싶다고 말했다.  자바스크립트 프레임워크 노드(Node)와 리액트(React)는 가장 많이 사용되는 웹 프레임워크로 자리를 지켰다. 노드와 리액트를 쓴다고 밝힌 개발자는 무려 90%에 달했다. 이 밖에 가장 사랑받는 웹 프레임워크로 피닉스(Pheonix)가 스벨트(Svelte)를 제치고 1위에 올랐으며, 앵귤러.js(Angular.js)는 꼴지를 차지했다. 한편 리액트.js(React.js)는 개발자들이 가장 원하는(Most wanted) 웹 프레임워크로 꼽혔다. 멀티클라우드 세상이다 이번 설문조사 결과에 따르면 AWS는 여전히 가장 많이 사용되는 클라우드 플랫폼이다. 전체 응답자의 51%가 AWS를 지목했다. 마이크로소프트 애저(28%), 구글 클라우드 플랫폼(26%)이 그 뒤를 이었다. 찬드라세카는 “멀티클라우드 세상이다. 많은 AWS 개발자가 GCP 또는 애저를 배우고 있으며, 이러한 플랫폼에 관해 많은 질문을 하고 있다”라고 말했다.  도커(Docker) 사용이 꾸준히 증가하고 있다 도커가 부활할 것으로 보인다. 도커를 사용한다고 답한 개발자의 비율이 지난해 55%에서 올해 69%로 급증했다. 아울러 개발자의 약 77%가 도커를 계속 사용하고 싶다고 답했을 정도로 가장 사랑받는 도구 1위에 꼽히기도 했다. 2위는 유비쿼터스 패키지 관리자 npm이었고, 이어 얀(Yarn), 홈브루(Homebrew), 쿠버네티스(Kubernetes) 순이었다.  마지막으로 웹3(Web3)와 관련해 소프트웨어 개발자들은 여전히 갈팡질팡하는 모습을 보였다. 전체 응답자의 32%는 (웹3에) 긍정적, 31%는 부정적, 26%는 관심 없다고 답했다. 웹3는 데이터와 콘텐츠가 블록체인에 등록되고 토큰화되거나 P2P 분산 네트워크에서 관리 및 액세스되는 분산형 웹의 새로운 개념을 말한다. ciokr@idg.co.kr
관련 자료 :
자료 출처 :
Scott Logic
원본자료 다운로드
발행 날짜 :
2022년 06월 20일
주요 내용 :
웹어셈블리 앱을 개발할 때 가장 자주 사용하는 프로그래밍 언어는 러스트(Rust)인 것으로 나타났다. 전반적인 웹어셈블리 사용도 점점 늘고 있는 것으로 조사됐다. 지난 6월 20일 소프트웨어 컨설팅 업체 스콧 로직(Scott Logic)이 공개한 '웹어셈블리 현황 2022(State of WebAssembly 2022)' 보고서의 내용이다. 이 조사는 애플리케이션 개발 299명을 대상으로 웹어셈블리 개발에 어떤 언어를 사용하는지 물었다. 그 결과 45%가 러스트를 자주 혹은 가끔 사용한다고 답해 1위를 기록했다. 러스트는 지난해 조사에 이어 올해도 1위였다. 보고서는 이런 인기의 이유로 대부분 웹어셈블리 런타임이 러스트로 작성되는 점을 꼽았다. 러스트에 이어 2위는 자바스크립트였다. 자바스크립트 엔진을 웹어셈블리로 컴파일할 수 있다는 점이 주요했던 것으로 보인다. 이번 조사에서 가장 순위가 크게 오른 언어는 블래이저(Blazor)와 파이썬(Python)이었고 반대로 어셈블리스크립트(AssemblyScript)는 순위가 가장 크게 하락했다. 또한 응답자의 67%가 웹어셈블리를 자주 사용한다고 답해 지난해 47%에서 크게 오른 것으로 나타났다. 이밖에 이번 조사의 주요 결과는 다음과 같다.   웹어셈블리를 사용하는 영역으로는 웹 개발이 70%로 1위를 기록했다. 이어 서버리스(35%), 컨테이너화(25%), 플러그인 환경(23%), IoT(10%) 순이었다. 가장 널리 사용하는 웹어셈블리 런타임은 와슴타임(Wasmtime), 와스머(Wasmer), 와슴3(Wasm3)이었다. 웹어셈블리가 더 발전하기 위해 가장 필요한 기능으로는 비 브라우저 API, 강화된 디버깅 지원, 제작 툴 개선 등이 꼽혔다. WASI(WebAssembly System Interface) 중에서 응답자가 가장 흥미롭다고 꼽은 것은 I/O, 소켓, 파일시스템, 네이티브 스레드, HTTP 순이었다. editor@itworld.co.kr
자료 출처 :
Datadog
원본자료 다운로드
발행 날짜 :
2022년 06월 02일
주요 내용 :
서버리스 컴퓨팅이 클라우드 업계의 핵심 서비스로 자리 잡고 있다. 클라우드 모니터링 서비스 업체 데이터도그(DataDog)가 6월에 공개한 보고서에 따르면, 기업 절반 이상이 아마존, 마이크로소프트, 구글 중 한 곳에서 서버리스 컴퓨팅을 사용하고 있는 걸로 나타났다.    ⓒ Ian Noble; Modified by IDG Comm. 불과 2년 전만 해도 서버리스 컴퓨팅 수요는 특정 클라우드 서비스 업체에 몰려 있었는데, 이제 주류 클라우드 업체 3곳 모두 폭발적으로 늘어나는 서버리스 기술 수요에 적극 대응하고 있다. 덕분에 사용자는 선택할 수 있는 기술이 많아졌고, 특정 업체에 종속되는 부담 없이 서버리스 기술을 도입 중이다. 과거 컨테이너 기술이 기업에 확산됐던 것처럼, 서버리스 컴퓨팅도 기업의 핵심 인프라로 여겨지고 있는 셈이다.  데이터도그의 자료를 보면 기업 대부분이 서버리스 컴퓨팅을 컨테이너와 함께 이용하고 있다는 것을 알 수 있다. 가령 2022년 1월 기준 AWS의 서버리스 서비스 람다(Lambda)를 이용하는 고객 중 20%는 AWS의 컨테이너 서비스인 ECS 파게이트(ECS Fargate)를 동시에 사용하고 있었다. 2018년도에 람다와 ECS 파게이트를 함께 이용하는 경우가 거의 0%였다는 점을 고려하면, 수치가 눈에 띄게 증가했다.  두 기술이 함께 쓰이는 이유는 보완할 수 있는 요소가 많기 때문이다. 특히 서버리스는 자동으로 리소스를 관리해주기 때문에 사용자가 직접 프로비저닝할 때 겪는 문제점을 대부분 해소해준다.  예를 들어 컨테이너를 이용할 때는 스토리지나 컴퓨팅 자원의 양을 구체적으로 생각해두지 않는다. 반면에 서버리스에서는 리소스 양을 자동으로 할당하고 관리할 수 있다. 따라서 클라우드 및 컨테이너 기반 시스템을 운영하는 과정에서 자원이 너무 많이 배치되지 않게 어느 정도 도움받을 수 있다.  서버리스와 컨테이너를 동시에 이용할 경우, 장단점은 모두 존재한다.  먼저 장점부터 보자. 컨테이너는 애플리케이션 개발 과정에 필요한 강력한 개발 및 배포 플랫폼을 만들어준다. 사용자는 궁극적으로 이전보다 한층 더 복잡한 작업을 처리할 수 있다. 문제는 추가 비용(필자는 이것을 ‘컨네이너 세금’이라고 표현해왔다)이 발생한다는 것이다. 컨테이너를 이용해 솔루션을 구축할 경우, 전통적인 방식과 비교했을 때 비용이나 시간이 최소 20% 증가한다. 서버리스 컴퓨팅은 이런 비용을 조금 낮춰준다. 리소스를 배포하고 관리할 때 직접 처리하지 않고 자동화하는 경우가 많기 때문이다. 이런 환경 덕에 컨테이너 개발의 효율성은 점점 높아지고 있다.  단점을 이야기하자면, 사용자는 리소스 관리 부분에서 서버리스 자동화에 지나치게 의존할 수도 있다. 서버리스 시스템은 리소스를 알아서 추가하고 제거하는데, 그 과정은 사람이 따라갈 수 없을 정도로 자동화가 잘 돼있다. 동적 애플리케이션을 비롯해 어떤 애플리케이션은 리소스 사용량과 관련해서 예측이 불가능하므로 서버리스 기술의 혜택을 제대로 누릴 수 있다.  하지만 애플리케이션 대부분은 예측할 수 있는 범위 내에서 운영되며 사용할 리소스 양도 미리 정해져 있다. 따라서 인스턴스 수를 미리 지정하는 등 가격을 낮출 방안을 고민하지 않고 서버리스 기술을 도입하면, 많은 돈을 지불해야할 수도 있다. 클라우드 사용량과 비용이 폭발적으로 늘어나고 있기에 한달에 비용 20%만 줄여도 일 년엔 수십만 달러까지 절약할 수 있다는 점을 고려해야 한다.  요약하자면, 컨테이너와 서버리스 컴퓨팅이 서로 보완적인 역할을 하기에 앞으로 두 기술은 점점 더 많이 쓰일 것이다.  editor@itworld.co.kr 
자료 출처 :
SlashData
원본자료 다운로드
발행 날짜 :
2022년 05월 04일
주요 내용 :
개발자의 언어 선호도에서 자바스크립트와 파이썬의 강세가 계속되고 있다. 러스트의 상승세도 만만치 않은 것으로 나타났다. 이는 지난 4일 공개된 '개발자 현황 22번째 에디션(State of the Developer Nation, 22nd Edition)'의 주요 내용이다. 이 보고서는 시장조사업체 슬래시데이터(SlashData)가 2021년 12월부터 올해 2월까지 전 세계 166개국 2만 명 이상의 개발자를 설문한 결과다.   ⓒ Getty Images Bank 보고서를 보면, 자바스크립트는 가장 선호하는 언어로 선정됐다. 슬래시데이터는 이 조사를 1년에 2~3번 정도 진행하는데, 자바스크립트는 최근 12번의 조사에서 연속으로 1위를 차지했다. 전 세계적으로 약 1,750만 명이 사용하고 있고, 자바스크립트 커뮤니티 역시 수년간 지속해서 성장하고 있다. 2위는 파이썬이었다. 2년 전 자바를 앞지른 이후 선두권을 계속 유지하고 있다. 전 세계 사용자 수는 1,570만 명으로, 불과 6개월 사이에 330만 명이나 늘어났다.   상승세를 보면 러스트가 눈에 띈다. 지난 2년 사이 사용자 수가 거의 4배 늘었다. 2020년 1분기 60만 명이었는데, 2022년 1분기에는 220만 명이 됐다. 러스트 파운데이션의 상임이사 레베카 럼블은 "보안과 메모리 안전성 등의 장점 때문에 러스트 사용자가 크게 늘었다. 메인터이너와 컨트리뷰터 커뮤니티가 포괄적이고 협력적인 것도 장점이다. 또한 러스트 개발자에 대한 수요가 계속해서 늘고 있으므로 직업적 전망에서도 좋은 언어다"라고 말했다. 보고서는 러스트가 주로 IoT 프로젝트는 물론 증강, 가상현실 개발에서도 널리 사용되고 있다고 분석했다.   이밖에 보고서의 주요 내용은 다음과 같다.   자바는 강력하고 안정적으로 성장하고 있다. 2021년 이후 거의 500만 명의 개발자가 자바 커뮤니티에 합류했다. PHP는 지난 6개월간 꾸준히 성장해 2021년 3분기에서 2022년 1분기 사이에 60만 명이 증가했다. PHP는 웹 애플리케이션 언어로는 자바스크립트 다음으로 널리 사용된다. 고(Go)와 루비는 백엔드 개발에서 매우 중요하다. 특히 고는 지난해 루비보다 2배 더 빠르게 성장했다. 현재 고 커뮤니티는 330만 명에 달한다. 코틀린 커뮤니티는 2021년 1분기 240만 명에서 2022년 1분기 500만 명으로 성장했다. 가장 큰 이유는 구글이 안드로이드 개발 언어로 코틀린을 주로 사용하기 때문이다. 개발자 46%는 업무에서 일정 부분 로우코드/노코드 툴을 사용한다. 숙련된 개발자, 특히 10년 이상 개발자는 이런 툴을 가장 적게 사용하는 것으로 나타났다. 북미 개발자의 19%는 코딩 업무의 절반 이상에서 로우코드/노코드 툴을 사용하는 것으로 조사됐는데, 이는 전 세계 평균치 10%의 거의 2배에 달하는 것이다. editor@itworld.co.kr
자료 출처 :
New Relic
원본자료 다운로드
발행 날짜 :
2022년 04월 26일
주요 내용 :
뉴 렐릭(New Relic)의 ‘2022 자바 생태계 현황 보고서(2022 State of the Java Ecosystem)’에 따르면 오라클 자바(Oracle JDK) 사용률이 34%로 떨어졌고, 아마존은 22%로 증가했다.    ⓒGetty Images 미국의 애플리케이션 모니터링 업체 뉴 렐릭의 최신 보고서는 자바 시장에서 오라클의 점유율이 여전히 지배적이긴 하지만 오라클 자바의 인기가 불과 2년 전보다 절반 수준으로 떨어졌다고 밝혔다. 4월 26일(현지 시각) 공개된 이 보고서는 뉴 렐릭에 성능 데이터를 제공하는 수백만 개의 애플리케이션에서 수집한 데이터를 분석한 결과다.  2020년 오라클은 자바 시장의 약 75%를 차지하는 가장 인기 있는 공급업체였다. 물론 2022년에도 34.48%의 시장 점유율로 1위 자리를 지키긴 했지만 2년 전과 비교하면 (사용률이) 절반 수준으로 쪼그라들었다. 반면 아마존은 2020년 2.18%에서 올해 22.04%로 크게 성장해 오라클의 뒤를 쫓고 있다.  오라클이 2021년 9월 릴리즈된 JDK 17을 통해 개방적인 자세로 복귀하기 전, 오라클JDK 11 버전부터 ‘제한적인 라이선스’를 적용한다고 발표한 이후 오라클 바이너리의 인기가 떨어지고 있는 추세라고 보고서는 설명했다. 이클립스 어댑티움(11.48%), 아줄 시스템(8.17%), 레드햇(6.05%), 아이스티(5.38%), 우분투(2.91%), 벨소프트(2.5%)가 그 뒤를 이었다.  이 밖에 2022 자바 생태계 현황 보고서의 다른 결과는 아래와 같다.    ‘자바 11’이 가장 일반적으로 사용되는 자바 버전이 됐다. 2018년 출시된 LTS 릴리즈인 자바 11은 현재 프로덕션 환경에 있는 애플리케이션의 48% 이상에서 사용되고 있다. 2020년의 11.11%에서 증가한 수치다. 자바 8은 46.45%로 2위를 차지했다. 자바 8은 2020년 84.48%의 시장 점유율을 기록한 바 있다.   프로덕션 환경에 있는 애플리케이션 가운데 비-LTS 자바 버전을 사용하는 비율은 2.7%였다. 그중에서 자바 14는 2020년부터 가장 인기 있는 비-LTS 릴리즈로 꼽혔다(0.95%).    보고서에 의하면 뉴 렐릭에 보고하는 자바 애플리케이션의 70% 이상이 컨테이너에서 실행된다.    G1은 자바 8 이상 버전을 쓰는 사용자들이 가장 선호하는 가비지 수집기인 것으로 드러났다.  한편 뉴 렐릭의 보고서 데이터는 전적으로 2022년 1월 뉴 렐릭에 보고한 애플리케이션에서 수집한 것이며, 글로벌 자바 사용 현황을 나타내진 않는다고 업체 측은 전했다. 아울러 뉴 렐릭은 적절한 데이터를 익명화하고 분류했으며, 공격자 및 기타 악의적인 행위자에게 악용될 수 있는 모든 세부 정보는 보고서에서 제외했다고 덧붙였다. ciokr@idg.co.kr   
자료 출처 :
Go
원본자료 다운로드
발행 날짜 :
2022년 04월 19일
주요 내용 :
‘고(Go) 언어 개발자 설문조사 2021(Go Developer Survey 2021)’에 따르면 10명 중 9명 이상의 개발자가 고 언어에 만족하는 것으로 나타났다. 기능 및 라이브러리 부족은 여전한 단점으로 지적됐다.    ⓒGetty Images 고 언어 개발자 설문조사 2021(Go Developer Survey 2021) 결과가 발표됐다. 구글에서 개발한 고 언어의 개발자 만족도는 매우 높은 수준을 유지하고 있지만 주요 라이브러리, 기능, 인프라 부족 등의 사용 장벽도 여전했다.  전체 응답자의 92%는 고 언어를 사용하는 것이 매우 또는 다소 만족스럽다고 밝혔다. 2021년 설문조사 결과와 동일한 수치다. 반면에 특정 프로젝트에서 이 언어를 쓰지 않는다고 답한 개발자의 39%는 그 이유로 필요한 기능 부족을 꼽았다. 라이브러리 부족(34%)이 그 뒤를 이었다. 물론 가장 많이 언급됐던 기능은 제네릭이었으나, 이는 설문조사 종료 이후(3월) 고 1.18에서 공식적으로 도입됐다.   이번 고 언어 개발자 설문조사는 2021년 10월 26일부터 11월 16일까지 3주 동안 진행됐으며, 총 참여 인원은 1만 1,840명으로 역대 최대 규모였다. 이 밖에 살펴볼 만한 다른 설문조사 결과는 다음과 같다.    모듈 사용 시 가장 큰 문제는 버전 관리, 개인 저장소 및 다중모듈 워크플로우 사용인 것으로 조사됐다. 하지만 고 1.18은 워크스페이스를 도입하면서 많은 문제를 해결했다고 고 언어 개발팀은 전했다.  고 언어의 주요 사용 사례에는 API/RPC 서비스(49%), 데이터 처리(10%), 웹 서비스(10%), CLI(8%) 등이 있었다.  전체 응답자의 절반은 고 언어 성능 최적화 및 프로젝트 디렉터리 구조의 베스트 프랙티스에 관한 추가 가이드라인을 원한다고 밝혔다.  리눅스에서 고 언어를 주로 사용하여 개발한다고 답한 비율이 2019년, 2020년, 2021년에 각각 66%, 63%, 59%로 감소하는 추세를 보였다. 윈도우에서 고 언어를 주로 사용한다고 답한 비율은 지난해 19%에서 올해 24%로 증가했다. 하지만 전체 응답자의 92%는 여전히 고 애플리케이션을 구축하기 위해 리눅스를 타깃 플랫폼으로 삼고 있다고 밝혔다.  고 언어 개발자에게 가장 인기 있는 클라우드 플랫폼은 AWS(43%), GCP(25%), 마이크로소프트 애저(12%)인 것으로 조사됐다.  ciokr@idg.co.kr
자료 출처 :
Hired
원본자료 다운로드
발행 날짜 :
2022년 03월 22일
주요 내용 :
2021년 소프트웨어 엔지니어에 대한 면접 요청이 두 배 증가했다. 또 원격 직무 비율이 증가하고 있다. 기술 채용 분야 전문 기업 하이어드(Hired)의 최신 보고서에 담긴 내용이다.  하이어드의 ‘소프트웨어 엔지니어 현황’ 보고서에 따르면 소프트웨어 엔지니어에 대한 면접 요청 건수는 2021년 22만 4,367회였다. 2020년의 10만 6,101회에서 크게 늘어난 수치다. 하이어드는 소프트웨어 엔지니어 수요 증가의 배경으로 팬데믹이 초래한 인재 부족 현상을 지목했다.  이번 보고서는 인력을 찾는 기업과 소프트웨어 엔지니어가 하이어드 플랫폼 상에서 나눈 상호 작용 및 2년 동안 이뤄진 2,000건의 설문 조사 응답에 기반해 작성됐다.  하이어드의 조쉬 브레너 CEO는 “기술 인력 부족이 지속되고 있다. 공석을 채우려는 기업들의 수요가 기록적으로 높다. 하이어드 플랫폼에서 활용하는 소프트웨어 엔지니어가 2021년 받은 면접 요청은 전년의 두 배 이상이었다”라고 밝혔다.  그는 이어 “경쟁적인 환경이 펼쳐지면서 소프트웨어 엔지니어를 대상으로 매력적인 급여와 혜택을 제공하는 동향이 나타나고 있다. 또 원격지의 소프트웨어 엔지니어를 찾기 위해 인재 검색 범위를 전 세계로 확장해야 할 필요성이 나타나고 있다”라고 덧붙였다.  소프트웨어 엔지니어에 대한 원격 채용 증가는 수치로 드러난다. 회사 플랫폼의 소프트웨어 엔지니어들이 2021년 원격 업무에 대해 받은 총 면접 수는 9만 8,846회였다. 2020년의 로컬 업무에 대한 면접 제안 수(9만 2,383회)를 넘어서는 수치다. 또 원격 근무가 가능하다고 표기한 개발자는 20% 더 많은 면접 요청을 받았다고 회사 측은 밝혔다.  개발자들이 매력을 느끼는 일터 요인으로는 업무 유연제가 가장 많이 지목됐다. 이후로는 제한적인 회의, 홀륭한 동료와 관리자 등이 뒤를 이었다.  하이어드 플랫폼에서 가장 인기 있는 직종은 풀 스택 개발자였다. 보고서는 "기업들이 2021에 풀 스택 엔지니어를 더 적극적으로 고용하고 있었다. 우리 데이터에 따르면 풀 스택 엔지니어는 다른 소프트웨어 엔지니어링 역할에 비해 면접 요청 측면에서 2.1%(2021년과 2020년을 비교할 때)라는 가장 높은 증가율을 보였다"라고 밝혔다. 엔지니어링 팀 효율성을 높이고 팀 인력 변동에 좀더 잘 대처하기 위해서일 것이라는 추정이다.  한편 평균 급여는 지속적으로 상승추세다. 2021년 미국 내 소프트웨어 엔지니어 급여는 0.8% 증가해 평균 15만 6,000달러를 기록했다. 원격 직무의 평균 연봉은 15만 7,000달러였는데, 이는 전년보다 3% 증가한 수치다.  하이어드 보고서에는 기업들이 찾는 소프트웨어 개발 역량에 대한 내용도 담고 있다. ‘고’ 프로그래밍 언어가 2년 연속 수요 기술 목록에서 1위를 차지했다. 고 언어에 능숙한 엔지니어는 평균보다 1.8배 더 많은 면접 요청을 받았다. 고 이후로는 루비 온 레일즈, 스칼라, 루비, 리액트 네이티브가 뒤를 이었다. 이 밖에 쿠버네티스, AWS, 구글 클라우드 플랫폼과 같은 클라우드 역량을 보유한 엔지니어는 평균보다 약 1.3배 더 많은 면접 요청을 받았다고 보고서는 전했다. ciokr@idg.co.kr  
자료 출처 :
MarketsandMarkets
원본자료 다운로드
발행 날짜 :
2022년 03월 21일
주요 내용 :
크라우드소싱 테스트 시장 규모가 2027년까지 연간 9.4% 성장할 전망이다. 2022년 16억 달러로 예상되는 시장 규모는 2027년에 25억 달러로 성장할 것으로 추정된다. 비용 효율적인 소프트웨어 개발, 고객 경험 향상이 중요한 소프트웨어의 QA(Quality Assurance) 확대, 팬데믹 기간 동안 사내 기술과 크라우드소싱 테스터와의 격차 해소 등이 시장 성장을 이끄는 요인으로 지목됐다. 마켓앤마켓(MarketsandMarket)이 '2027년까지 전 세계 크라우드소싱 테스트 시장(Crowdsourced Testing Market by Testing Type - Global Forecast to 2027)' 보고서를 발표했다. 보고서는 크라우드소싱 테스트 시장을 테스트 유형(성능, 기능, 사용성, 현지화, 보안), 플랫폼, 조직 규모, 배포 모드, 업종과 지역으로 구분해 조사와 분석을 진행했다. 마켓앤마켓이 2027년까지 전 세계 크라우드소싱 시장 보고서를 발표하고, 2027년까지 연간 9.4% 성장하며 25억 달러의 시장으로 성장할 것으로 전망했다. (자료 : MarketsandMarkests) 크라우드소싱 테스트는 소프트웨어 성능, 기능, 오류 발견 등의 목적으로 수 백 또는 수 천명 이상의 테스터를 대상으로 진행하는 아웃소싱 형태의 테스트 방식이다. 소프트웨어 개발 업체가 크라우드소싱 테스트 업체에 평가를 의뢰하면 테스트 대상, 기간, 인력 규모 등을 협의해 테스트를 진행한다. 이를 통해 다양한 환경과 인원이 참여하는 실제적인 테스트가 가능하다. 기업의 업무 환경부터 개인의 일상생활까지 디지털 시대로 전환되면서, 다양한 디지털 장치와 소프트웨어 사용이 갈수록 증가하고 있다. 결국 그만큼 기업 또는 고객들이 사용해야 하는 소프트웨어가 증가한다는 것으로, 고객 경험 향상을 위한 품질 관리가 중요해지면서 크라우드소싱 테스트 시장도 꾸준하게 성장을 계속하고 있다. 인모비(InMobi)에 따르면 2021년 4월부터 6월 사이에 출하된 태블릿과 스마트폰만 해도 3억 1,300만 대에 달한다. 에릭슨 모빌리티 리포트(Ericsson Mobility Report)는 2027년까지 셀룰러 IoT 연결이 전체의 51%를 차지할 것이라고 전망했다. 이렇게 다양한 분야에서 디지털 장치와 그것을 활용하기 위한 소프트웨어가 급증하면서, 정확하고 효율적인 소프트웨어 테스트 수요도 함께 증가하고 있다. 특히 크라우드소싱 테스트 시장이 IoT 성장으로 기회를 맞이하고 있다고 보고서는 전망헀다. IoT 솔루션에 크라우드소싱 테스트를 적용함으로써 효율적으로 시스템을 테스트할 수 있고, 다른 수많은 IoT 연결과 관련된 문제를 해결할 수 있기 때문이다. 하지만 대규모 테스터 그룹을 효율적으로 관리하며 테스터의 일관된 참여를 보장하면서, 테스트 과정에서 개인 정보 보호 및 보안 규정 준수가 중요한 과제라고 분석했다. 테스트 유형 중에서는 '기능 테스트', 플랫폼 부문에서는 '모바일 애플리케이션', 기업 규모에서는 '중소기업'이 예측 기간 동안 시장 성장을 주도하거나 빠른 성장을 보일 것으로 예상했다. 기능 테스트는 대규모의 숙련된 테스터를 모집한 후 소프트웨어를 공개해도 좋을지 기능을 테스트하면서, 사용자 인터페이스, 오류, 텍스트 처리, 누락된 기능 등을 확인하게 된다. 구글의 안드로이드와 애플의 iOS를 탑재한 스마트폰이나 모바일 또는 스마트 장치들이 증가하면서, 이와 관련된 응용프로그램도 계속해서 증가하고 있다. 따라서 다양한 종류의 장치에서 정상적인 동작과 성능 등을 확인하는 애플리케이션 테스트는 필수 사항이다. 모바일 애플리케이션 테스트는 기본적인 소프트웨어 완성도부터 동작 중 멈춤 현상, 배터리 과소비 등 사용 중 발생할 수 있는 다양한 항목을 점검한다. 크라우드소싱 테스트는 중소기업의 비용 절감과 비즈니스 효율성 향상으로 이어질 수 있을 것으로 보고서는 진단했다. 안정성, 확장성, 효율성이 향상되면서 중소기업이 빠른 속도로 크라우드소싱 테스트를 채택하도록 권장하는 핵심 요소가 될 것이라는 분석이다. 지역으로는 북미 시장 규모가 가장 클 것으로 예상했으며, 2022년 북미 시장은 스마트 빌딩 분야에서 가장 높은 시장 점유율을 차지할 것으로 예측했다. 글로벌 크라우드소싱 테스트 시장의 주요 공급업체로는 퀄리테스트(Qualitest), 노무라연구소(Nomura Research Institute), 인포시스(Infosys Limited), 시그니티 테크놀로지스(Cigniti Technologies) , EPAM 시스템(EPAM Systems), 플랫월드 솔루션(Flatworld Solution), 테스트 얀트라 소프트웨어 솔루션(Test Yantra Software Solutions), 코발트 랩스(Cobalt Labs), 버그크라우드(Bugcrowd), 글로벌 앱 테스팅(Global App Testing) 등이 있다. ciokr@idg.co.kr
자료 출처 :
GitGuardian
원본자료 다운로드
발행 날짜 :
2022년 03월 02일
주요 내용 :
데브섹옵스(DevSecOps) 도입이 활발히 이뤄지면서 많은 기업이 클라우드 네이티브 아키텍처를 활용해 안전한 소프트웨어 결과물을 확보하는 동시에 개발, 보안, 운영 부서 간의 사일로를 허물 방안을 모색하고 있다. 하지만 데브섹옵스 여정 전반에서 해결해야 문제가 여전히 존재한다. 바로 비밀 관리다.   ⓒ Getty Images Bank 비밀은 기업이 비공개로 유지하고자 하는 정보로 구성된다. 로그인 인증 정보, 액세스 키, 인증서가 대표적이다. IBM의 데이터 침해 보고서에서 드러난 바와 같이 인증 정보와 비밀은 각종 사이버 공격과 데이터 침해의 단골 표적으로, 유출 시 악의적 행위자에게 초기 또는 횡적 액세스 권한을 제공하는 역할을 한다. 코드코브(Codecov), 트위치(Twitch)를 포함한 여러 데이터 침해 사건에서 허술한 보안 관리 관행이 주요한 원인으로 작용했다. 최근 삼성의 소스 코드 일부분이 노출된 삼성 데이터 침해 사건에서는 6,000개 이상의 비밀 키가 노출 정보에 포함됐다. 비밀 관리 문제의 심각성은 지난 몇 년 동안 계속해서 증가했다. 최근 깃가디언(GitGuardian)이 발행한 2022년 비밀 노출 현황 보고서(State of Secrets Sprawl 2022)에 따르면, 2021년 공개 깃허브 리포지토리를 스캔한 결과 600만 개 이상의 비밀이 감지됐다. 2020년에 비해 2배 증가한 수치다. 기업의 비밀 관리가 성숙하지 못하다는 점 자체도 문제이지만, 데브섹옵스를 지향하는 클라우드 네이티브 환경이 특히 이런 부분에 취약하다. 구체적으로 비밀 보관, 중앙 집중식 접근 방법, 액세스 제어, 비밀 사고 발생 시 대응 준비 등이 취약하다. 오픈소스 솔루션 및 관련 리포지토리의 인기가 높아지는 점도 비밀 노출을 악화시키는 요소다. 소스 코드와 이미지, 코드형 인프라(Infrastructure-as-Code, IaC) 매니페스트도 우발적으로 또는 부주의하게 비밀이 커밋되어 노출될 수 있는 영역이다. 기업은 오픈소스 기술 컨테이너 이미지와 IaC 템플릿화된 매니페스트를 폭넓게 사용해서 많은 시간을 절약하고 혁신의 속도를 높일 수 있지만, 이런 관행은 특히 공개 리포지토리의 커뮤니티로 커밋될 때 비밀 노출의 주된 경로가 되기도 한다. 문제는 공개 리포지토리뿐만이 아니다. 기업의 내부 비공개 리포지토리와 심지어 CI/CD(Continuous Integration/Continuous Delivery) 빌드 시스템 및 파이프라인에까지 손을 뻗는 데이터 침해가 발생하면서 여기서도 비밀이 악의적 행위자에게 노출될 수 있다. 애플리케이션 보안팀은 비밀 관리 방식 구축과 성숙도 측면에서 개발팀 및 다른 부서의 활동에 보조를 맞추는 데 어려움을 겪고 있다. 비밀 관리를 위한 권장 사항 기업은 비밀 관리 방식의 성숙도를 높여야 한다. 그렇지 않으면 소프트웨어 벤더 또는 클라우드/관리형 서비스 제공업체에 속한 노출된 비밀이 노출됐을 때 그 여파는 한 기업만이 아니라 공급망과 생태계를 따라 퍼지게 된다. 여기서 난관은 비밀이 우발적으로 공유, 저장 또는 노출될 수 있는 위치와 방식이 다양하다는 점이다. 현대의 기술 환경이라면 소스코드 리포지토리, CI/CD 파이프라인, 컨테이너 이미지, IaC 템플릿, 심지어 개발자의 로컬 워크스테이션까지 포함된다. 이 같은 문제를 일부 완화하는 방법을 살펴보자. 오픈소스와 상용 툴 리포지토리와 CI/CD 파이프라인의 경우 선택할 수 있는 오픈소스와 사유 솔루션이 다양하다. 가장 인기 있는 오픈소스 선택지는 깃리크스(GitLeaks)와 트러플호그(Trufflehog)로, 모두 깃 리포지토리에서 저장된 비밀을 스캔하는 기능을 지원한다. 깃허브(GitHub), 깃랩(GitLab)과 같은 인기 있는 CI 플랫폼에 통합되어 파이프라인을 타고 흐르는 비밀이 리포지토리 또는 런타임 환경에 도달하기 전에 포착할 수 있다. 암호, API 키, 개인 액세스 토큰과 같은 비밀을 검색할 수도 있다. 악의적 행위자가 이런 비밀을 악용할 경우 문제의 기업뿐 아니라 고객과 비즈니스 파트너를 비롯해 해당 기업과 디지털 방식으로 상호작용하는 다른 사람까지 피해를 입을 수 있다. 이들 오픈소스 솔루션은 예컨대 실제 커밋에 앞서 실행할 수 있는 프리 커밋 후크(pre-commit hook)도 지원한다. 2가지 옵션 모두 내장된 규칙 사용을 지원하지만, 맞춤형 비밀 탐지 규칙을 생성할 수도 있다. 이 기능은 기업이 보호해야 하는 데이터의 유형에 따라 유용하게 활용할 수 있다. 이런 툴은 잠재적으로 노출된 비밀을 찾는 데에는 매우 유용하지만, 쏟아지는 경보를 살펴보면서 오탐지와 실제 문제를 구분해야 하는 개발팀 입장에서는 매우 번거로울 수 있다. 따라서 툴을 튜닝하는 것이 무엇보다 중요하다. 벤더 영역에서 부상 중인 업체는 이 기사의 앞부분에서 인용된 비밀 노출에 관한 연구 자료를 발표한 깃가디언이 대표적이다. 깃가디언은 버전 제어 시스템, 데브옵스 툴 및 IaC 구성과 통합해서 비밀 노출을 방지하는 코드 보안 정책 엔진을 제공한다. 또한 현재 활성 사용자 수가 7,000만 명이 넘는 모든 공개 깃허브 커밋을 적극적으로 모니터링 및 스캔한다. 물론 이들 모두가 공개 리포지토리를 사용하는 것은 아니지만, 공개 리포지토리를 대상으로 한 깃가디언의 모니터링 활동은 비밀 노출 현황과 관련하여 관련 지표와 문제의 심각성을 알리는 데 도움이 된다.  개발자 교육 또 다른 권장 사항은 앱 보안팀이 주도하는 개발자 교육이다. 툴도 효과가 좋고 비밀 노출 방지에 필수적이지만, 시프트-레프트(shift-left) 관점에서 보면 개발자부터 시작하는 것이 좋다. 유출된 비밀의 위험성, 그리고 유출이 기업뿐 아니라 고객 또는 파트너에까지 미치는 영향에 대해 개발자를 교육하는 것 역시 중요하다. 사고 대응 계획에 비밀 유출 시나리오 포함하기 사이버보안 사고 대부분이 그렇듯이 비밀 침해 역시 발생은 기정사실이며 결국 시간의 문제다. 사고 대응 계획 및 관련 플레이북에 비밀 유출 시나리오를 포함해야 하는 이유다. 비밀이 노출됐을 때 기업은 어떻게 대처해야 하는가? 누가 작업에 참여하는가? 영향을 최소화하기 위해 유출된 비밀을 무효화할 방법이 있는가? 영향을 받은 고객과 파트너에게 어떻게 소식을 전할 것인가? 비밀 노출 및 이와 연관된 보안 사고에서 중요하게 고려해야 할 질문들이다. 툴과 프로세스, 사람을 통한 다면적 접근 방식을 취하면 비밀 유출 및 그 여파와 관련된 위험을 완화하는 데 도움이 된다. 개발자, 앱 보안 엔지니어, 클라우드 네이티브 기업이 비밀 관련 위험을 완화하기 위해서는 앞서 설명한 항목을 구현하는 것이 중요하다. 클라우드와 데브섹옵스의 시대에 비밀 유지란 결코 쉬운 일이 아니다. editor@itworld.co.kr
자료 출처 :
TEKsystems
원본자료 다운로드
발행 날짜 :
2022년 03월 01일
주요 내용 :
애자일 방법론을 이용하면 자기조직화 팀이 고객에게 집중하고 증분 형식으로 결과물을 배포하면서 피드백을 활용해 우선순위를 조절할 수 있다. 가장 보편적인 애자일 방법론은 소규모 팀이 1~4주 단위의 스프린트로 작업하는 스크럼(scrum)이다. 이 방법론에 따라 팀은 스프린트에 대해 정해진 양의 작업을 완료하는 데 목표를 둔다.   ⓒ Getty Images Bank 스크럼의 기본은 단순하다. 우선순위화된 사용자 스토리의 백로그를 리뷰하고 스프린트 중 확실히 완료할 수 있는 작업을 찾아 사용자 스토리에 문서화된 “완료의 정의” 상태를 목표로 둔다. 스크럼 세레모니는 팀 협업에 도움이 되며 보통 제품 소유자, 기술 리드 또는 스크럼 마스터가 정한 스케줄에 따라 반복되는 회의 형식으로 진행된다.   다양한 작업 환경에 맞춰 스크럼 조정하기 팬데믹 봉쇄 중에 스크럼 팀은 줌, 마이크로소프트 팀즈와 같은 툴을 사용해 가상으로 이와 같은 세레모니를 진행했다. 이에 따라 회의 구조도 변화해 가상 참가를 지원하고 유연한 작업 시간을 반영하게 됐다. 오늘날 많은 기업의 숙제는 하이브리드 업무 환경으로 영구적으로 전환하도록 스크럼 세레모니를 조정할 방법을 찾는 것이다. 팀원 중 일부는 사무실에서, 일부는 원격으로 작업한다. 이 같은 하이브리드 작업은 조직과 팀이 애자일 사고방식을 되돌아볼 새로운 기회이기도 하다. 애자일 팀이 하이브리드 작업을 성공적으로 수행해야 할 이유는 명확하다. 최근 실시된 한 설문조사에서 응답자의 40%는 직원의 절반이 매주 3일 이상 원격 근무를 지속할 것으로 예상했다. 또 다른 설문에서는 엔지니어의 75%가 대부분 시간 동안 원격 작업을 선호한다고 답했다. 이제 하이브리드 작업 지원은 개발자를 채용하고 근속시키는 핵심 요소가 됐음을 알 수 있다. 애자일 팀내 영구적인 하이브리드 작업을 원하는 엔지니어도 기업이 스크럼 세레모니를 재편성하고 부가적인 하이브리드팀 데브옵스 권장사항을 검토하도록 적극 협력해야 한다.   시작은 '스프린트 리뷰' 대부분 팀이 도입하는 4가지 주 스크럼 세레모니는 다음과 같다.   스프린트 계획. 사용자 스토리 백로그를 리뷰하고 요구사항을 파악하고 스프린트 중에 완료할 작업을 찾아 합의한다. 일일 스탠드업. 짧은 모임을 통해 사용자 스토리를 완료하기 위한 작업 현황을 리뷰하고 장애물, 의문점 또는 기타 작업 완료에 지장을 제목 2초래하는 요소를 확인한다. 스프린트 리뷰. 스프린트가 끝나면 팀은 제품 소유자, 배포 관리자 및 이해관계자에게 성과를 공유하고 시연한다. 스프린트 회고. 스프린트 중에 잘된 부분과 개선할 부분을 리뷰한다. 스프린트 리뷰는 특히 애자일 팀이 이해관계자를 초대해 완료된 작업을 시연하고 피드백을 받을 때 대부분 사람에게 영향을 미친다. 보통 다수의 사람이 관여하는 데다 스크럼 팀과 제품 소유자, 이해관계자 간의 대화를 효율적으로 관리해야 하므로 하이브리드 작업을 위해 스프린트 리뷰 회의를 최적화하는 것이 중요하다. 나인투쓰리 디지털 벤처스(NineTwoThree Digital Ventures)의 CEO 앤드루 아만은 "애자일 팀이 이해관계자의 피드백에 초점을 맞추고 우선순위를 조정해야 한다. 하이브리드 작업 스프린트 리뷰의 가장 중요한 측면은 모든 의사 결정자가 관여하도록 하는 것이다”라고 말했다. 아만은 하이브리드 스프린트 리뷰를 위한 팁도 제시했다. 그는 “카메라를 켜고 메모를 준비하라. 우리는 스프린트 리뷰를 다음 스프린트 계획과 혼합한다. 팀은 지난 스프린트에서 무엇을 완료했는지, 그리고 다음 스프린트에서 무엇을 할지 설명한다. 시간 내에 리뷰에서 계획으로 전환하는 것이 핵심이다”라고 말했다.   하이브리드 스프린트 리뷰를 위한 팁 하이브리드팀에서 스프린트 리뷰를 개선할 수 있는 다른 방법은 다음과 같다.   고객 또는 사용자 관점에서 사용자 스토리를 문서화하고 시연할 요소를 정한다. 합의된 업무 중 팀원에게 사용자 스토리를 할당하고 스토리 시연의 책임을 맡긴다. 특히 팀의 경험이 부족하고 기능이 시연하기 복잡하거나 많은 이해관계자 피드백이 예상되는 경우에는 예행연습을 고려한다. 시연할 사용자 스토리 순서와 각 순서에 소비할 시간은 제품 소유자가 결정하도록 한다. 회의실에서 발표자 전환 시 중단을 최소화하면서 시연을 보여주고 가상으로 공유할 최선의 방법을 결정한다. 피드백을 수집할 방법을 정한다. 예를 들어 백로그에 지라 소프트웨어(Jira Software)를 사용하는 기업은 이해관계자에게 완료된 이슈에 대한 투표를 요청할 수 있다. 줌 사용 팀은 채팅 기능을 사용해 질문을 할 수 있고, 제품 소유자는 추가 논의 필요시 시연이 끝난 후 브레이크아웃 룸을 열 수 있다. 또한 팀은 소소한 피드백을 위해 사용자 스토리에 댓글을 달도록 이해관계자에게 요청하거나, 슬랙 채널을 사용해 전반적인 피드백을 수집할 수도 있다. 정해진 시간에 스프린트 리뷰를 끝낸다. 이 부분이 중요하다. 리뷰가 길게 늘어지는 경우 회의를 종료하고 시연의 남은 부분을 녹화해 각자 시간이 될 때 볼 수 있도록 한다. 팀원과 이해관계자가 나중에 볼 수 있도록 항상 회의를 녹화한다. 목표는 모든 참가자가 스프린트 리뷰에 참여하는 데서 가치를 얻도록 하는 것이다. 이를 위해서는 효율적인 하이브리드 회의 방법을 찾아야 한다.   스프린트 회고에서 개선 논의하기 하이브리드 스프린트 리뷰의 형식에 대한 협의가 도출되면 팀은 회고(retrospective)를 사용해 개선 사항을 논의해야 한다. 회고는 대규모 기업에 극히 중요하다. 대규모 기업은 한 가지 정답을 획일적으로 적용하는 방식, 또는 모범 사례 학습을 전적으로 스크럼 팀에 맡기는 방식은 비효율적일 가능성이 높기 때문이다. 이런 리뷰가 너무 길어졌거나 스토리의 시연이 원활하지 않았다면 이를 개선해 다음에 더 좋은 시연이 되려면 어떻게 해야 할지 자문해야 한다. 이해관계자가 충분한 피드백을 제공하지 않는다면 커뮤니케이션, 프로세스 또는 툴의 어떤 점을 수정해야 할지도 함께 논의해야 한다. 또한 회고는 하이브리드 작업 방식을 개선하고 팀원의 만족도를 높이고 일과 삶의 균형 문제를 논의하는 중요한 기회이기도 하다. 업레벨(Uplevel) CTO인 라브스 카우어는 "스크럼 팀은 회고에서의 토론 범위를 확대해야 한다. 일반적으로 대부분의 스프린트 회고에서는 프로젝트 상태와 기술적 업적을 살펴보는 데 주력하지만 제품의 성공이 전부가 아니다. 장기적인 성공을 위해서는 소프트웨어를 만드는 사람도 건강해야 한다. 예를 들면 스프린트 중 팀이 번아웃되었는가? 지속할 수 없는 정도의 문맥 교환(context switching)이 있었는가? 스프린트의 성공 여부를 판단할 때는 생산성의 인적 비용을 중요하게 다뤄야 한다. 스프린트 목표 달성과는 별개로 팀의 만족도에도 신경을 써야 한다”라고 말했다. 이런 질문은 특히 하이브리드 작업을 모델로 채택하려는 기업의 애자일 리더가 생각해야 할 중요한 질문이다. editor@itworld.co.kr
자료 출처 :
JRebel
원본자료 다운로드
발행 날짜 :
2022년 02월 22일
주요 내용 :
제이레벨(JRebel)의 설문조사 결과에 따르면 전문 자바 개발자의 3분의 1 이상이 메인 애플리케이션에 8년 된 자바 버전을 사용하고 있는 것으로 나타났다.  8년 전 출시된 자바 8이 여전히 가장 많이 사용되는 자바 버전인 것으로 조사됐다. 하지만 설문 조사 결과 자바 17로 업그레이드할 계획인 기업도 많은 것으로 드러났다.     ⓒGetty Images ‘메인 애플리케이션에 어떤 JDK(Java Development Kit) 프로그래밍 언어를 사용하는가?’라는 질문에 전체 응답자의 37%가 자바 8이라고 밝혔다. 2위는 자바 11(29%)이었다. 그다음으로는 자바 12 이상(12%), 코틀린(8%), 그루비(6%), 자바 7 이상(5%), 스칼라(3%) 순이었다.  ‘2022 자바 개발자 생산성 보고서(2022 Java Developer Productivity Report)’는 지난 2012년 10월부터 2022년 1월까지 전문 자바 개발자 876명을 대상으로 실시한 설문조사 결과를 담았다.  자바 8(2014년 3월 출시)과 자바 11(2018년 9월 출시)은 모두 수년간 오라클의 지원을 받는 LTS(Long-Term Support) 릴리즈다. 비 LTS 릴리즈(자바 9, 자바 10, 자바 12, 자바 15 등)는 6개월 동안만 지원을 받는다.  한편 소속 기업의 업그레이드 계획을 알고 있다고 밝힌 응답자 가운데 37%는 향후 6개월 안에 작년 9월 출시된 LTS 릴리즈인 ‘JDK 17’로 업데이트할 계획이라고 언급했다. 아울러 향후 6개월에서 12개월 안에 JDK 17로 업그레이드할 예정이라고 지목한 비율도 25%에 달했다. ‘JDK 18’은 비 LTS 릴리즈이며, 오는 3월 22일 공개된다.  회사에 따르면 ‘2022 자바 개발자 생산성 보고서’는 자바 기술과 자바 애플리케이션 개발에 관한 현 접근 방식에 초점을 맞추고 있다. 제이레벨(JRebel)은 퍼포스에서 만든 자바 개발 도구다. 이 밖에 다른 설문조사 결과는 아래와 같다.  • JDK 버전 업그레이드를 결정하는 데 가장 큰 영향을 미치는 요인으로 ‘LTS 릴리즈(25%)’가 꼽혔다. 보안(23%), 성능(20%)이 그 뒤를 이었다.  • 오라클의 자바 버전(36%)이 가장 인기 있었으며, 27%는 일반 오픈JDK(OpenJDK) 자바를 사용한다고 답했다.    • 전체 응답자의 33%가 마이크로서비스를 사용한다고 밝혀 이는 사용자의 자바 애플리케이션을 지원하는 가장 일반적인 아키텍처로 선정됐다. 그 뒤를 이어 22%는 단일 애플리케이션을 활용한다고 언급했다.  • 도커(41%)는 자바 애플리케이션과 함께 사용하는 가장 일반적인 가상머신 플랫폼으로 꼽혔다. 그다음으로 쿠버네티스(26%), VM웨어(16%) 순이었다.  • 아마존 웹 서비스(AWS)는 가장 일반적으로 사용되는 PaaS 플랫폼(31%)이었다. 전체 응답자의 24%는 PaaS 업체를 사용하지 않는다고 밝혔다. 마이크로소프트 애저는 14%를 기록했다.  • 아파치 톰캣(Apache Tomcat)은 지금까지 가장 많이 사용된 자바 애플리케이션 서버로, 48%가 이를 활용한다고 답했다. 제이보스/와일드플라이(JBoss/Wildfly)는 15%였다.  • 젯브레인 인텔리제이(JetBrains IntelliJ)가 48%를 차지해 가장 인기 있는 자바 IDE로 꼽혔다. 그 뒤를 이어 이클립스(Eclipse), 비주얼 스튜디오 코드(Visual Studio Code)가 각각 24%, 18%를 기록했다.  ciokr@idg.co.kr
자료 출처 :
Gartner
원본자료 다운로드
발행 날짜 :
2022년 02월 09일
주요 내용 :
전 세계적으로 사회의 양상을 근본적으로 바꿔버린 바이러스 대유행 사태가 잦아든 지금 우리는 2022년 중반에 와 있다. 지난 2년의 변화 중에서 가장 주목할 만한 것은 디지털 인프라의 필요성이 높아지고 이에 크게 의존했다는 점이다. 시스템 관리자가 새로운 작업 방식을 만들어 내느라 고전하는 와중에도 시스템 자체는 훌륭하게 견뎌 주었다.   ⓒ Getty Images Bank 우리는 웹이 PPE(Personal Protective Equipment)에서 가상 결혼식까지 모든 것을 제공할 수 있음을 알게 되었다. 달리 위안을 주는 것이 없을 때면 많은 사람이 디지털 보호막 속으로 더 침잠해 들어갔다. 이처럼 웹 사용량이 급증하면서 새로운 문제와 개선할 부분이 발견됐다. 이제 온라인 경험을 기반으로 이를 업그레이드할 새로운 기술의 물결이 떠오르고 있다. 기존의 인터넷을 새로 구축하려는 노력이 진행 중인 가운데 이와 관련된 여러 가지 트렌드를 정리했다.   재미와 수익을 위한 코딩 소프트웨어 개발자라면 방금 개발한 프로그램도 "충분히 좋으냐"고 물으면 "개선의 여지가 있다"고 답하는 경우가 대부분이다. 뮤지션이 아직 미완성 상태라고 생각하는 데도 결국 앨범을 그냥 발표하는 것과 비슷하다. 존 레넌은 비틀즈의 명반을 두고 “재녹음하고 싶지 않은 것은 하나도 없다”라고 말하기도 했다. 이를 통해 우리는 지속적인 개선을 이끄는 중요한 동기부여 요소를 이해할 수 있다. 소프트웨어 엔지니어는 예술혼 비슷한 것에 이끌린다. 뭔가 멋진 것을 개발하지 않고는 못 배기는 것이다. 그렇게 개발된 최첨단 기술을 ‘예술’의 경지라고 표현한다. 코드 가독성과 유지 가능성이 제일 중요하다고 하지만 내재적으로 가치 있는 무언가를 만들고자 하는 타고난 갈망이 동기를 부여하는 경우도 많다. 물론 우수성만이 아니라 수익도 동기부여 요소다. 혁신이 성공할 확률은 벼락에 맞을 확률만큼이나 낮지만 일단 성공하면 금전적 이익이 엄청나다. (합치기 어려운 것으로 악명 높지만) 코더의 사고방식과 사업적 감각을 한데 모은다면 번개를 병 안에 가두듯 성공 확률을 높일 수 있다.   소프트웨어 개발 트렌드의 융합 이런 강력한 동기부여 요소가 근면성과 어울려 효과를 발휘하면서 개발 환경이 빠르게 변하고 있다. 소프트웨어 개발 분야에서 가장 영향력이 큰 트렌드를 알아보고 개별 트렌드가 현재 어떻게 융합되고 있는지 살펴보자.   2022년 소프트웨어 개발 트렌드의 융합 © IDG   클라우드 채택과 고차원 인프라 클라우드 투자가 늘고 있음은 이론의 여지가 없다. 실제로 클라우드 투자는 최근 IT 투자 중 절반을 넘어섰다. 이유는 간단하다. 가상화된 인프라와 툴은 수요가 높은 고도의 애자일 솔루션을 제공하기 때문이다. 흥미로운 것은 클라우드 사용 방식도 진화하고 있다는 점이다. 클라우드에 호스팅 된 역동적인 가상 머신(일명 서비스형 인프라(IaaS))의 개념은 강력하지만 진화하는 화폭 상에 그린 첫 스케치에 불과했다. PaaS와 서버리스 함수가 다음 수순이다. 솔루션의 다양화와 전문화도 나타나고 있다. 수평 방향으로는 물론 수직 방향으로의 진화다. 혁신가는 가상화된 인프라로 고차원 솔루션을 개발할 수 있다. 이 분야의 참가자는 크게 API 호스터 진영과 API 제공자 진영으로 나뉜다.   서버리스 배포와 API 제공자 베르셀(Vercel)과 네트리파이(Netlify)같은 서비스가 대표적인 최첨단 API 호스터다. 이들은 IaaS 및 PaaS 계층 위에 있는 일종의 서버리스 인프라를 대표한다. 그뿐만 아니라 특정 상황을 맞춤 지원하는 전문화를 잘 보여주기도 한다. 베르셀의 대시보드 앞에 앉아 복잡한 프론트엔드 애플리케이션을 버튼 하나를 눌러 배포해 봤다면 이 말의 의미를 잘 알 것이다. 베르셀은 ‘서버리스 플러스’이다. 즉, 특정 요건을 충족하기 위해 개선, 수정된 서버리스다.   대표적인 최신 API 제공자는 몽고DB 아틀라스(MongoDB Atlas)다. 이 API는 주로 데이터 지속성을 제공한다. 몽고DB 아틀라스는 본질적으로 원격 이용 가능한 서비스형 API다. 센트리아이오(Sentry.io)와 오스0(Auth0)같은 서비스도 비슷하다. 이들 솔루션은 호스팅용 베르셀과 마찬가지로 특정 수요에 맞춰 고도의 추상화(일은 적게 들고 파워는 많음)를 제공한다는 점이 핵심이다. 데이터 저장소를 가상 인프라 내에 배포하는 것은 전통적인 모델이다. 단지 장소만 클라우드로 옮겼을 뿐이다. 기존의 보유 자산을 필요한 것과 쉽게 통합시켜주는 전문 데이터저장소 협력업체를 두는 것에 가까운 효과를 보려면 몽고DB 아틀라스 같은 것을 사용해야 한다. 이 분야에서 성공적인 툴의 공통점 3가지가 애플리케이션이 연결하는 API, 인코드 통합 지원, 웹 기반 관리 콘솔이라는 점도 흥미롭다.   API 빌더 클라우드 플랫폼의 시대 덕분에 뭔가 새로운 것이 탄생할 길이 열린 것은 분명하지만 그 새로운 것이 정확히 무엇인지는 예측하기 어렵다. 새로운 툴에 내재된 기능과 (사용자 자신도 모를 때가 많은) 사용자의 수요가 새로운 방식으로 만나는 곳이 어디인지 찾아내는 과정이다. 흥미롭게도 실제로 API를 개발하는 세계는 비교적 변화가 없다. 그동안 점진적인 개선은 있었지만 호스팅과 제공 분야에서 일어난 것과 같은 파괴적인 변화는 아니었다. API 구성 활동을 호스터 및 제공자가 이룩한 것과 통합하는 움직임은 기회로 가득 찬 격변을 상징한다. 다음으로 소프트웨어 구성이 활발하게 진화하고 있는 몇몇 분야를 살펴보자.   프론트엔드 툴과 프레임워크 프론트엔드는 백엔드 로직과 서드파티 API의 마법이 인간-기계 표현방식을 찾는 영역이며 이곳에서 자바스크립트(JavaScript) 언어는 계속 진화한다. 한편, 자바스크립트 위에 구축된 프레임워크는 치열한 경쟁을 통한 자연도태를 겪고 있다. 솔리드(Solid),?스벨트(Svelte), 퀵(Qwik)과 같은 프로젝트는 다양한 방향으로 한계를 초월하고 있고, 리액트(React), 뷰(Vue)와 같은 기성 리액티브 프레임워크도 계속 성장하고 있다. 이처럼 반복 개선과 교류가 소프트웨어 한 분야에서 일어나는 것은 보기 드물다.   커스텀 미들웨어 클라우드 내 작업은 기존 툴을 통합하고 API를 통일하는 일이 많다. 이를 위해서는 항상 사람이 미들웨어 수준에서 일정 분량의 커스텀 작업을 해야 한다. 모든 자동화의 궁극적인 목적은 변하는 사람의 수요를 맞추는 것이기 때문이다. 러스트(Rust)같은 서버측 언어와 제이힙스터(JHipster)같은 프레임워크의 등장은 흥미롭지만 전체적으로 이 분야는 유동적이다. 프론트엔드처럼 백엔드도 더 전면적인 진화를 기다리고 있다. 자바(Java), 노드제이에스(Node.js), 파이썬(Python)같은 기존 솔루션(관련 프레임워크 포함)은 이 환경에 매우 적합하며 현실 세계의 요구에 맞춰 끊임없이 진화하고 있다. 이들 솔루션은 변함없이 중요한 활동 영역이 될 것이다. IaaS가 계속해서 서버리스의 필수 계층인 것처럼 미들웨어 코드는 머지않아 더 중요해질 것이다. 로우 코드와 머신러닝이 인간 개발자와 경쟁할 조짐도 보이지만 궁극적으로는 개발자가 추가로 활용할 수 있는 툴에 불과할 것이다. 혁신적인 로우 코드의 대표적인 예는 빌더(Builder)이다. 머신러닝이 코딩에 어떻게 도움을 줄 수 있는지는 깃허브 코파일럿(GitHub Copilot)에서 확인할 수 있다.   분리 아키텍처(일명 마이크로서비스) 다음으로, 원격 분리 아키텍처(일명 마이크로서비스)를 향한 움직임이 계속 활발하고 더 확산할 것이다. 전통적인 모놀리식 아키텍처 패러다임은 클라우드에 내재된 잠재력을 충분히 활용할 수 없다. 대안인 마이크로서비스 아키텍처는 데브옵스 부담을 덜어주겠지만, 이는 프로세스 확장을 가능하게 하는 동시에 복잡성을 심화시킨다. 서비스형 API, 프론트엔드 진화, 커스텀 미들웨어 등 기술의 새로운 방향을 아우르고자 하는 혁신이라면 마이크로서비스 아키텍처의 복잡성을 해결해야 할 것이다.   프로세스 자동화 모범 사례를 패키지화해 제공하려면 프로세스 자동화, 즉, 각 팀이 소프트웨어를 개발하고 제공하기 위해 사용하는 프로세스를 조율하는 일이 중요해진다. 이 분야에서는 사용자화 솔루션에 집중되는 현상이 관찰된다. 모든 기업은 상황이 다르다. 따라서, 구글과 마이크로소프트 같은 대기업에서 구현한 잘 통하는 것을 규모와 종류를 막론한 모든 팀에 통하는 솔루션으로 담아내는 것은 충분한 가치가 있다. 많은 CI/CD 솔루션, 빌드 및 의존성 관리 툴, 그리고 테스트 프레임워크는 프로세스 자동화 툴이 개발자 활동에 초점을 맞추고 있는 사례다. 버전 통제와 깃허브같은 관련 서비스가 이 범주에 속한다. 프로세스 자동화는 소프트웨어의 미래에 일익을 담당할 또 하나의 핵심 분야다.   새로운 종류의 개발자 경험 앞서 제시한 융합 다이어그램처럼 이번에 살펴본 소프트웨어 개발 트렌드는 각각 변화의 원동력이다. 전체적으로 이들 트렌드가 가리키고 있는 것은 매력적이지만 아직 나타나지는 않은 새로운 종류의 개발자 경험이다. 현재 영향을 미치고 있는 세력과 움직임은 눈에 보이지만, 구체적인 미래는 아직 불투명하다. 그렇기에 지금이야말로 소프트웨어 개발자가 되기에 흥미진진한 시기다. editor@itworld.co.kr
자료 출처 :
Electric Capital
원본자료 다운로드
발행 날짜 :
2022년 01월 06일
주요 내용 :
웹3(Web3)에 대해 열광이 고조되고 있는 가운데, 이를 바라보는 엔지니어들의 시각이 점차 나뉘는 양상이다. 웹 개발에 대한 흥미로운 새로운 패러다임으로 보는 시각이 있는 한편, 이를 통해 빠르게 돈을 벌 수 있을 것으로 기대하는 시각이다.   Image Credit : Getty Images Bank 정의에 따르면 웹3는 데이터 및 콘텐츠가 블록체인에 등록되거나 토큰화되거나 P2P(Peer to Peer) 분산형 네트워크에서 관리 및 액세스되는 공공 인터넷에 대한 비전이다. 암호화폐, NFT(Nonfungible Token), 새로운 유형의 분산형 애플리케이션(댑스 ; Dapps))을 지원하는 분산형 인터넷이다. 분산형 블록체인을 기반으로 소프트웨어를 개발하는 이 새로운 모델은 분명 전통적인 3-계층 아키텍처와 매우 다다. 그리고 관점에 따라서는 최신 기술 트렌드에 편승하고 싶어하는 개발자에게는 의미있는 기회일 수 있다. 암호화 전문 벤처 캐피탈 기업 일렉트릭 캐피탈(Electric Capital)에 따르면, 웹3 개발자 커뮤니티는 아직 소규모다. 현재 1만 8,000명의 개발자들이 현재 오픈소스 웹3 및 암호화 프로젝트에 참여하고 있다. 그러나 2021년 초 이후로 75%나 성장했다. 기술 고용 플랫폼 하이어드(Hired)의 CTO 데이브 월터스는 “최근 하이어드의 플랫폼에서 웹3 전문가를 채용하려는 움직임이 증가하고 있다. 웹3 후보자에 대한 상대적인 수요가 2021년 초 이후로 약 67% 증가했다”라고 밝혔다. 웹3 개발이란? 웹3 개발자 도구 기업 디센톨로지(Decentology)의 설립자 닉 칼리아니는 웹3를 프론트엔드와 백엔드 스킬을 더욱 명확하게 정의하고 구분함으로써 소프트웨어 개발을 극적으로 간소화할 기회로 보고 있다. 그는 “개발자 관점에서 필요 역량과 성공 가능성에 대한 구분이 명확해진다”라고 말했다. 백엔드와 관련해 그는 “블록체인을 선택하고 단일 언어로 작업하며 아키텍처 변화를 파악하면 효율성에 대해 더욱 심도 깊게 생각할 수 있고 스토리지를 위해 최적화할 수 있다. 이 모든 것들을 통해 경쟁력 있는 스마트 컨트랙트 개발자가 될 수 있다”라고 말했다. 한편 프론 엔드 개발자 또는 디자이너들도 기존의 스킬을 직접 웹3 애플리케이션에 적용할 수 있다. 웹3 진입 방법 전 AWS 수석 개발자 지지자 나데르 대빗은 지난해 블록체인 데이터를 위한 그래프 인덱싱 프로토콜에 집중하는 기업 E&N(Edge & Node)에 입사하면서 웹3 직종으로 전환했다. 그는 전통적인 웹 2.0 개발 스킬이 웹3 영역으로 이동될 수 있다고 낙관하고 있다. 대빗은 우선 이더리움(Ethereum)과 솔리디티(Solidity) 문서부터 시작하는 것이 좋다고 말했다. 이것들을 읽으면 인기 있는 블록체인 생태계와 스마트 컨트랙트를 작성하는 방법을 기본적으로 파악할 수 있다는 설명이다. 대부분의 개발자에게는 솔리디티의 학습 곡선이 그리 부담스럽지 않을 가능성이 높다. C++ 및 자바와 유사하기 때문이다. 이미 범용적인 러스트(Rust) 프로그래밍 언어로 스마트 컨트랙트를 작성하기 시작한 개발자들도 있다. 대빗에 따르면 또 웹3 분야에 진입하려는 개발자라면 리믹스(Remix) 등의 새로운 개발 환경에 익숙해져야 하며 선택한 블록체인을 위해 이더리움 VM(Virtual Machine) 또는 유사한 실행 메커니즘을 배치하는 방법을 배워야 한다. 그리고 블록체인에 트랜잭션을 ‘서명’하는 메커니즘과 이 프로세를 위한 초기 산업 표준으로 등장한 신기술 메타마스크(MetaMask)를 이해해야 한다. 쉽게 말해, 현재 웹3 애플리케이션을 구축하거나 사용하기 위해서는 새로운 용어 세계에 익숙해져야 한다. 아울러 암호 지갑을 설정하며 이더리움 블록체인에서 활동을 수행하기 위해 필요한 변덕스러운 ‘연료비’(gas fees)를 지불해야 한다.  이 모든 것들은 초보자들을 어리둥절하게 만들 수 있다. 칼리아니는 “사람들이 이더리움에 진입할 때 연료비를 보고 겁을 먹게 된다. 즉, 많은 개발자들이 어설픈 단계에 머무르는 경향이 있다”라고 말했다. 하지만 낮은 연료비에 대한 약속 덕분에 코스모스(Cosmos), 솔라나(Solana), 카다노(Cardano) 등 다른 블록체인 플랫폼의 인기가 높아지면서 상황이 달라지고 있다. 또한 사용할 수 있는 테스트넷이 증가하고 있어 개발자들이 연료비를 지불하지 않고 스마트 컨트랙트를 테스트할 수 있다. 웹3 스택의 상태 웹3 개발자 스택은 분명 미숙하고 다소 불투명하며 파편화되어 있다. 코인베이스(Coinbase) 개발자 출신의 프리티 카사이어디는 한 블로그 게시물에서 “모든 사람들이 이 모든 것 때문에 어리둥절해 하고 있다. 이 모든 도구를 대충 꿰 맞추는 것이 복잡하며 고통스러운 개발자 경험으로 이어질 수 있다”라고 밝혔다. 하지만 상황이 달라질 수 있다. 하드햇(Hardhat) 같은 개발자 프레임워크는 이미 이더리움에서 스마트 컨트랙트를 더 쉽게 구축, 배치, 테스트할 수 있으며, 폴리곤(Polygon) 등의 프레임워크는 개발자들에게 블록체인 네트워크에 대한 원클릭 배치를 약속하고 있다. 그리고 이 영역에 대한 관심과 투자가 증가하면서 웹3 프레임워크와 SDK의 수가 증가하고 있다. 인터체인 파운데이션(Interchain Foundation)의 소프트웨어 개발자 오너 아크폴랏은 “모든 개발자가 (웹 2.0에서 웹3로) 전환하기에 충분한 자원이 마련되어가고 있다. 티핑 포인트에 도달했다”라고 밝혔다. 암호화폐 거래소 코인베이스의 수석 엔지니어이자 AWS의 솔루션 아키텍트 출신 루크 영블러드는 “기술 전문가로서 가상화부터 클라우드까지 최신 트렌드를 따르는 것이 중요하며, 지금의 트렌드는 웹3다”라고 밝혔다. 다행히도 이 생태계에 대한 관심이 증가하면서 웹3 튜토리얼이 증가하고 개발자 커뮤니티가 생겨나고 있다. 그리고 유데미(Udemy)와 코세라(Coursera)에서 과정이 생겨나고 있고, 웹3 유니버시티(웹3 University), ETH글로벌(ETHGlobal), 빌드스페이스(Buildspace) 등의 온라인 학습 커뮤니티도 증가하고 있다. 많은 엔지니어들과 마찬가지로 영블러드는 비트코인을 채굴하면서 웹3 여정을 시작했다. 2017년, 그는 여가 시간에 이더리움과 스마트 컨트랙트에 관해 알게 되었고, AWS에서 근무하면서 블록체인과 분산형 시스템 디자인에 빠져들게 되었다.  오래지 않아 그는 웹3를 잠재적인 커리어 경로로 보게 되었다. 그는 “이제 나는 콘텐츠의 소유권에 대해 생각하고 페이스북이나 구글의 분산형 데이터베이스에서 소유하고 있지 않다는 점도 생각하게 되었다”라고 말했다. 왜 웹3냐고? 돈이 될 수 있다 기본적인 내용을 학습한 후에도 주말에 웹3를 어설프게 만지는 단계에서, 상당한 시간과 에너지를 쏟는 단계로의 이동은 상당히 큰 변화이다. 하지만 웹3 영역에 진입할 때 중대한 유인책이 있다. 바로 돈이다. 풀타임 웹3 개발자 급여는 기업들이 이 새로운 영역에 주목하면서 6자리 범위에서 시작되는 경향이 있다. 하이어드에 따르면 웹3 후보자는 이미 미국에서 16만 달러의 평균 기본 급여를 받고 있다. 또 새로운 토큰 발행 시 보상으로 제공되는 웹3 개발의 추가적인 혜택이 있을 수 있다.  프로젝트 성공 시 그 가치가 크게 증가할 수 있는 혜택이다. 웹3 생태계의 이런 요소는 “돈을 목적으로 진입하는 사람들에게 매력적이다”라고 E&N의 대빗이 말했다. 블룸버그(Bloomberg)의 칼럼니스트 매트 레빈은 “웹3의 기본 전제 중 하나는 모든 제품에 투자 기회가 있다는 것이다... 페이스북 또는 우버(Uber)의 초기 사용자가 페이스북 또는 우버의 주주가 되는 것과 같다. 즉 이런 서비스가 커지면 나도 부자가 된다”라고 밝혔다. 시그널(Signal) 제작자 목시 말린스파이브가 제시한 예를 살펴본다. 그는 오토노머스 아트(Autonomous Art)라는 프로토타입 댑을 구축한 경험을 ‘웹3의 첫인상(My first impressions of 웹3)’이라는 제목의 블로그 게시물에서 밝혔다. 오토노머스 아트 댑은 사용자가 공동 예술 작품에 기여할 때 NFT에 대한 새로운 토큰을 만들 수 있다. 그는 이에 대해 “시각적인 기여의 비용은 시간이 지남에 따라 증가하며, 기여자가 토큰을 만들기 위해 지불하는 재정이 이전의 모든 예술가에게 분배된다(이 금융 구조를 시각화 하면 피라미드 모양처럼 된다)”라고 설명했다. 마다반 말로란은 개발자들이 웹3 프로젝트에 기여하여 돈을 벌 수 있도록 돕는 것이 목적인 스타트업 퀘스트북(Questbook)의 설립자다. 그는 웹3 개발이 오픈소스 프로젝트에 기여하는 것과 비슷하지만 기여도에 대해 실질적인 보상을 받는다는 차이점이 있다고 표현했다. 그는 “이것은 엄청난 차이이다. 왜냐하면 많은 개발자들이 이런 재무적 보상을 누릴 것이다.  이것은 하나의 증폭기제일 것이다”라고 말했다. 그러나 재무적인 이익만을 위해 웹3 프로젝트를 구축하거나 개발하는 사람들이 문제가 되고 있기도 하다. 셰프(Chef) 공동 설립자 아담 제이콥은 “더 나을 수는 있지만 나같은 사람은 공통 요소와 서로를 위해 무엇인가 더 나은 행위를 하는 것에 대한 생각을 잃게 되면 무엇인가 아름다운 것을 잃게 된다고 생각한다. 그 유인을 돈과 바꾼다? 격이 떨어지는 것 같은 느낌이다”라고 밝혔다. 팀 오라일리는 최근 블로그 게시물에서 “암호 자산에 투기하여 쉽게 번 돈 때문에 개발자와 투자자들은 유용한 실질적인 서비스를 구축하는 것에는 안중에도 없는 것 같다”라고 말하기도 했다. 이 모든 것들 때문에 소설가이자 취미가인 로빈 슬로언은 이런 질문을 던졌다. “이런 화폐가 쓸모 없어진다 하더라도 여전히 웹3에 대한 관심이 유지될까? 어떤 사람들은 기본적인 ‘절대적으로 그렇다’고 답할 것이다. ‘전혀 아니다’라고 솔직하게 답하는 사람들도 있을 것이다.” 웹3 : 기술적 도전이 존재하는 용감한 신세계 그렇다고 해서 웹3에 엔지니어들이 씨름할 흥미로운 기술적인 문제가 없다는 뜻은 아니다. 무엇이 그들에게 동기를 부여하는지에 대한 질문을 있을 뿐이다. 이더리움의 공동 설립자 바이탈릭 뷰테린에게는 돈이 아니라 진정으로 다른 무엇인가를 개발할 수 있는 기회가 중요하다. 그는 “많은 개발자들이 정말로 분산화와 불신에 대해 관심을 갖고 있다”라고 말린스파이크의 블로그 게시물에 대해 레딧(Reddit)에서 자신의 의견을 피력했다. 그러면서도 말린스파이크는 “초기 인터넷 시절을 연상시키는 창의성/모험을 위한 공간이 만들어지고 있다”라고 평했다. 소프트웨어 엔지니어이자 강경한 웹3 비판론자인 스티븐 디엘은 웹3가 주목하지 않을 수 없는 컴퓨터 공학 문제를 해결하는 데 도움이 될 것이라 생각한다. 그는 “하지만 실제로 그 기술을 적용해야 하는 엔지니어링 관점에서 비즈니스 세계에서 유용한 애플리케이션을 찾아보기 어렵다”라고 밝혔다. 이런 비판이 존재함에도 불구하고 많은 개발자들이 진정으로 새로운 것이라는 관심을 갖게 될 것이다. 웹3 지지자이자 개발자인 비토리오 리바벨라는 “많은 이들이 웹3를 통해 혁신적인 것을 만들 수 있다고 생각한다. 그들은 웹3에서 새로운 유니콘이 탄생할 수 있다고 생각한다. 선구적인 느낌 때문에 이 영역에서 많은 독립적인 프로젝트가 진행되고 있다”라고 밝혔다. NFT 마켓플레이스 슈퍼레어(SupreRare)의 수석 커뮤니티 관리자 애슐리 ‘아슈니크리스트’ 크리스텐슨은 “상대적으로 작은 커뮤니티이며, 많은 투자가 이루어지고 있다. 나는 이런 느낌을 찾고 있었다. 나의 닷컴 순간처럼 느껴졌다”라고 밝혔다. 웹3는 살아남을까? 주목해야할 동향일 수 있지만 위험성에 대해 주의할 필요가 있다. 허브스팟(Hubspot) 소프트웨어 개발자 롤리 화이트처럼 웹3 세계를 깊이 탐구하는 많은 엔지니어들 일부는 분산화와 불역성이라는 근본적인 주요 원칙에 의구심을 갖고 있다. 그녀는 블로그 게시물을 통해 “블록체인 데이터가 이동하는 상대적으로 몇 안 되는 플랫폼에 대한 과도한 의존이 존재한다. 블록체인의 분산화의 많은 이점이 무효화되고 있다”라고 밝혔다. 그녀는 최근 매우 인기가 있었던 보어드 에이프(Bored Apes) NFT 도난을 예로 들면서 “‘코드가 법’이고 중앙 당국이 간섭할 수 없는 불가역적인 분산된 세계의 허점”을 언급했다. 해당 도난 사건에서는 중앙의 거래소(여기에서는 오픈시(OpenSea) 마켓플레이스)가 개입하여 자산을 동결하고 도둑에게 쓸모가 없게 만들 수 있었다. 그녀는 “블록체인 기술은 어떤 영문인지 분산되어 있지만 실제로는 그렇지 않을 수 있다. 불가역적이지만 실제로는 그렇지 않은 최악의 상태에 도달할 수 있었다”라고 결론지었다. 멀린스파이크 역시 웹3가 개발자들에게 약속하는 것의 상당 부분이 여전히 웹 2.0 시대를 정의했단 특정 중앙 플랫폼에 대한 의존성과 많이 닮아 있다고 결론지었다. 그는 “이런 기술을 활용할 수 있도록 하기 위해 이 영역은 플랫폼들을 중심으로 통합하고 있다. 이번에도 그렇다”고 말하면서 그는 인퓨라(Infura), 알케미(Alchemy), 메타마스크를 이미 정립된 개발자 병목으로 언급했다. UC버클리의 컴퓨터공학 교수 니콜라스 위버는 더욱 맹렬하게 비판했다. 그는 유즈닉스(Usenix) 블로그 게시물을 통해 “기술적 토대가 너무 끔찍하다. 암호화폐를 홍보하기 위한 목적으로만 존재한”라고 밝혔다. 웹3의 주요 주창자 중 한 사람인 코인베이스의 CEO 브라이언 암스트롱도 최근 트위터에서 “분산된 방식으로 개발하는 것은 여전히 어렵기 때문에(초기 도구) 여러 앱/기업들이 어려운 기술 문제에 직면할 때 더욱 중앙 집중적인 웹2 기법으로 되돌아가고 있다”라고 말했다. 하지만 더 젊고 새로운 미래를 위해 직업 생활을 준비하고 있는 많은 개발자들이 이것을 진입 장벽이 아니라 도전과제나 기회로 볼 가능성이 높다. 이더리움의 공동 설립자 뷰테린은 현재의 웹3의 한계가 결국 ‘제한적인 기술적 리소스와 재정’이며, 더 많은 개발자들이 이 영역에 진입하면 이것들이 사라질 것이라고 생각한다.  그는 레딧에서 “다행히도, 의존성을 하나씩 공격하여 해결하고 있으며, 이미 많은 진척이 있었다. 몇 개의 전담팀이 다목적의 어려운 일을 처리하면, 신뢰할 수 없는 애플리케이션을 개발하는 것이 모든 개발팀에 더욱 실현 가능해질 것이며, 단지 라이브러리만 연결하면 될 것이다”라고 밝혔다. ciokr@idg.co.kr
자료 출처 :
Github
원본자료 다운로드
발행 날짜 :
2021년 11월 18일
주요 내용 :
“개발자 생산성이 팬데믹 이전으로 회복됐다. 하지만 개발자들이 사무실로 복귀한 것은 아니다.” 깃허브의 ‘2021 옥토버스 현황’ 보고서에 따르면, 올해 풀 리퀘스트(pull requests) 병합 속도는 직장에서 가장 빨랐다. 오픈소스 프로젝트보다 거의 두 대 빨랐다고 깃허브는 전했다. 단 직장에서의 풀 리퀘스트 병합 속도는 작년보다 25% 더 느렸다. 보고서는 그러나 지난 2년을 살펴볼 때 작업 리듬이 팬데믹 이전으로 회복된 수준이었다고 기술했다. 깃허브는 또 공동 작업을 진행한 개발자의 46%가 이제 완전히 원격으로 또는 하이브리드 환경에서 작업하는 것으로 예상하고 있었다고 밝혔다.  지난 16일 게시된 이번 보고서는 400만 개 이상의 저장소에서 수집한 데이터와 1만 2,000만 이상의 개발자를 대상으로 한 설문조사에 기반하고 있다. 깃허브 측은 이러한 접근법으로 인해 “예측적” 결과를 제시할 수 있다고 주장했다.  깃허브의 2021 옥토버스 현황 보고서에는 이 밖에도 다양한 현황 정보가 담겨 있다. 코드를 재사용할 때 개발 팀 성과가 최대 87%, 자동화를 사용할 때 최대 43% 증가할 수 있다는 진단이 대표적이다. 다른 결과로는 다음과 같은 것들이 있다. • 자바스크립트와 파이썬이 상위 언어로 남아 있고 자바와 타입스크립트가 뒤를 이었다. • 깃허브에 올해 새롭게 합류한 오픈소스 기여자는 140만 명에 이른다. • 개발자가 쉽게 검색할 수 있는 팀 리포지토리가 있으면 생산성이 11% 증가한다. • 오픈소스 및 엔터프라이즈 프로젝트 모두에서 문서가 최신 상태일 때 생산성이 50% 증가한다. • 멘토링은 오픈소스 프로젝트와 회사 모두에서 귀중한 자산이다. ciokr@idg.co.kr

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

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

Copyright © 2022 International Data Group. All rights reserved.