웹어셈블리를 훨씬 더 쉽게 작성하는 법부터 머신러닝을 지원하는 시각적 언어까지 새로운 프로그래밍 도구 11가지를 살펴본다. 이는 어쩌면 소프트웨어 작성 방식을 재정의할지도 모른다.  영국의 시인 알렉산더 포프는 “희망은 인간의 가슴에서 영원히 샘솟는다(Hope springs eternal in the human breast)”라고 말했으니 해커가 아닌 시인이라 할지라도 새로운 프로그래밍 언어 발견에 대한 희망을 이해할 것이라 본다. 소프트웨어 개발자들은 유니코드 문자의 독특한 조합으로 만들어진 언어가 마침내 모든 문제를 해결하여 몇 번의 클릭만으로 쉽게 코딩할 수 있길 영원히 희망하고 있다.  포프는 분명 답을 상상하기만 하면 될 정도로 직관적인 구문에 대한 희망을 이해할 것이다. 또한 그는 올림픽에서 볼 수 있는 트리플 악셀 혹은 대회전 활강처럼 (사실은 그렇지 않지만) 힘들지 않고 우아해 보이는 새로운 코드를 손에 넣으려는 열망을 높이 평가할 것이다.    하지만 오늘날의 언어 대부분은 기발함이나 코딩 역량을 보여주기 위해 만들어지진 않았다. 이는 개발자(창작자)가 간절하게 해결하고자 했던 문제에 해결책을 내놓으면서 만들어졌다. 대다수의 개발자가 하나 이상의 오래된 기성 언어로 코딩을 계속하겠지만 코딩 문제를 해결하는 데 도움이 되는 새로운 도구도 ‘영원히’ 찾고 있다. 특히, 도메인별 언어(DSL)의 부상에서 이러한 경향을 볼 수 있다. 이러한 언어는 특정 도메인에 초점을 맞추고 있으며, 범용적으로 사용하진 못한다. 하지만 바로 그런 이유로 도구 상자에서 특별한 위치를 차지할 수 있다.  여기서는 틈새시장을 찾은 11개의 새로운 언어를 살펴본다. 비록 지금 당장 필요한 것은 아니지만 이 모두는 현재 하는 일을 개선할 무언가를 갖고 있다. 리액티브 클로저(Reactive Clojure) 이는 클로저(Clojure)와 리액트(React)를 결합한 결과다. 즉, 리액티브 프론트엔드의 모든 가능성과 클로저의...

6일 전

분산 이벤트 스트리밍 플랫폼 ‘아파치 카프카(Apache Kafka)’의 메타데이터 관리 도구 ‘주키퍼(ZooKeeper)’가 단계적으로 제거될 예정이다.    아파치 카프카 프로젝트 관리 위원회(Apache Kafka project Management Committee)의 멤버이자 컨플루언트(Confluent)의 엔지니어 콜린 맥케이브는 “주키퍼를 사용하면 클러스터 메타데이터를 저장하고 동적 구성, 토픽, 토픽 내 파티션을 관리할 수 있지만 관리 계층을 추가하는 문제점이 있다”라면서, “하지만 카프카 내부에 메타데이터를 저장하면 더 쉽게 관리할 수 있고, 버전 관리 등의 문제를 해결할 수 있다”라고 말했다.  주키퍼는 내부적으로 관리되는 메타데이터용 프토로콜인 ‘카프카 라프트(Kafka Raft) 또는 크라프트(KRaft)’로 대체된다. 크라프트 모드에서 카프카 메타데이터는 분산 로그에 저장된다. 맥케이브는 “확장성이 주된 이점이다. 아울러 관리도 개선될 것”이라고 밝혔다. 카프카 사용자는 카프카 클러스터를 관리하기 위해 별도의 시스템을 구축할 필요가 없다고 그는 덧붙였다.  주키퍼 지원이 정확히 언제 중단될지는 발표되지 않았다. 현재는 카프카 3.3 릴리즈에서 크라프트를 GA 버전으로 제공하고, 카프카 4.0에서 주키퍼를 제거할 계획이다. 오는 8월에 출시될 카프카 3.3에는 주키퍼와 크라프트 옵션이 모두 포함된다. 맥케이브는 “크라프트 모드가 곧 프로덕션으로 전환될 예정이다. 이는 해당 프로젝트의 큰 발전일 것”이라고 전했다.  크라프트 모드는 지난 2021년 4월 릴리즈된 카프카 2.8부터 사용할 수 있었지만 프로덕션 준비 상태는 아니었다. 이는 카프카 3.3에서 프로덕션 준비 릴리즈로 제공될 예정이다. 맥케이브는 “주키퍼를 사용해왔던 개발자의 학습 곡선이 가파르지는 않을 것”이라면서, “개발자를 위해 동일한 API가 지원된다. 운영자는 몇 가지 학습해야 할 것이 있을 수 있다. 새로운 관리자가 이를...

7일 전

뉴 렐릭(New Relic)의 ‘2022 자바 생태계 현황 보고서(2022 State of the Java Ecosystem)’에 따르면 오라클 자바(Oracle JDK) 사용률이 34%로 떨어졌고, 아마존은 22%로 증가했다.    미국의 애플리케이션 모니터링 회사 뉴 렐릭의 최신 보고서는 자바 시장에서 오라클의 점유율이 여전히 지배적이긴 하지만 오라클 자바의 인기가 불과 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%의 시장 점유율을 기록한 바 있다. • 프로덕션 환경에 있는 애플리...

2022.04.29

오라클이 프로그래밍 언어이자 개발 플랫폼인 자바의 최신 버전 ‘자바 18(Java 18)’을 출시했다. 최신 버전에는 안전성과 보안성이 더욱 향상된 수 천 가지 기능과 함께 개발자의 생산성을 더욱 향상시켜 줄 9가지 플랫폼 업데이트 사항이 포함되었다고 업체 측은 설명했다. 회사에 따르면 특히 이번에 업데이트된 9개의 JEP(JDK Enhancement Proposal, JDK 개선 제안) 중 JEP 413은 자바 API 설명서에 코드 스니펫(Code Snippets)을 추가하는 기능으로, API 설명서에 샘플 소스코드를 추가하거나, 프로토타입 생성 또는 테스트용 간이 웹 서버(JEP 408)를 추가하는 작업이 대폭 간소화됐다. 또한 개발자들은 벡터 API(JEP 417)와 외부 함수 및 API(JEP 419) 등 두 가지 인큐베이팅 모듈과 스위치(Switch) 문 패턴 매칭(JEP 420) 등 미리보기 기능도 활용할 수 있다. 오라클 자바 플랫폼 그룹 소프트웨어 개발 부사장인 조지 사브는 “자바 18은 오라클이 6개월마다 기업 및 개발자들에게 더욱 개선된 기능을 신속하게 제공하겠다는 약속을 지속적으로 지켜 나가고 있음을 여실히 입증하고 있다”라며, “우리는 지속적인 기술 투자를 통해 자바 개발 키트뿐만 아니라 자바 SE 플랫폼의 성능과 안정성, 보안성을 끊임없이 향상시키고 있다”라고 말했다. 오라클은 최근 온프레미스 환경 또는 모든 클라우드 환경에서의 자바 런타임 및 애플리케이션 관리를 돕기 위해 오라클 클라우드 인프라스트럭처(OCI)의 새로운 네이티브 서비스인 자바 매니지먼트 서비스(JMS)도 공개했다. JMS는 전사적인 자바 배포 관리에 필요한 정보를 제공하며 OCI 워크로드 및 자바 SE 구독자들은 해당 서비스를 함께 사용할 수 있다. 자바 18은 오픈JDK 프로젝트 및 자바 커뮤니티 프로세스(JCP)를 통한 오라클 엔지니어들과 전 세계 자바 개발자 공동체 일원들의 폭넓은 협업을 바탕으로 탄생했다. 이를 통해 지속적인 혁신이 제공...

2022.03.29

룸(Loom)은 (오픈JDK에 의해 호스팅되는) 자바/JVM 생태계에서 비교적 새로운 프로젝트다., 전통적인 동시성 모델(concurrency models)이 가진 한계를 극복하려는 시도다. 특히 룸은 자바 스레드(Java threads)를 대체할 경량의 대안이고, 이들을 관리할 새 언어 구조를 가지고 있다. 이와 관련해 앞으로 일어날 중요한 변화를 개략적으로 살펴본다. 파이버: 자바 가상 스레드  리스팅 1에서 볼 수 있듯이 전통적인 자바 동시성은 스레드(Thread) 및 러너블(Runnable) 클래스에 의해 관리된다 (새 명칭의 스레드를 시작하고 해당 명칭을 출력).  리스팅 1. 전통적인 자바로 스레드를 시작하기 이 모델은 꽤 이해하기 쉽다. 그리고 자바는 이를 처리함에 있어 여러 풍부한 지원을 제공하고 있다. 단점은 자바 스레드가 운영체제 내의 스레드에 직접 매핑 된다는 점이다. 이러한 매핑은 동시 실행되는 자바 앱의 확장성을 심하게 제한한다. 이는 앱 스레드와 운영체제 스레드 사이의 1대1 관계를 의미할 뿐 아니라 스레드를 최적으로 정돈할 메커니즘이 전혀 없음을 의미하기도 한다. 예를 들어 서로 밀접하게 연계된 스레드들이 상이한 프로세스를 공유할 수 있고, 그렇다면 동일 프로세스 상에서 힙 메모리를 공유하는 데 따른 혜택이 없어진다. 룸이 얼마나 야심적인 변화를 지향하는 지를 쉽게 시사하는 숫자가 있다. 현재의 자바 스레딩은 심지어 육중한 서버에서조차 스레드 수가 많아 봐야 수천 개이다. 룸은 이 한계를 수백만 개로 확대하려 한다. 이게 자바 서버 확장성에 있어서 갖는 함의는 지극히 파격적이다. 표준적인 요청 처리는 스레드 수와 연계되기 때문이다.  해법은 일종의 가상 스레딩을 도입하는 것이다. 여기서는 자바 스레드가 기저의 OS 스레드로부터 분리되고, JVM(Java Virtual Machine)은 두 스레드의 관계를 한층 효과적으로 관리할 수 있다. 프로젝트 룸은 애당초 파이버(fiber)라는 새로운 가상...

2022.03.14

표준 자바(Java)의 다음 버전에는 외부 함수 및 메모리 API, 벡터 API, 스위치 표현식 패턴 매칭, 범용 제네릭 등이 포함되리라 예상된다.   2주 후 ‘자바 18(Java 18)’이 프로덕션 릴리즈로 출시됨에 따라 ‘자바 19(Java 19)’가 형태를 갖추기 시작했다. 표준 자바의 다음 릴리즈는 자바 런타임 외부 코드와 상호 운용하는 API와 함께 추진될 예정이다. 이는 범용 제네릭, RISC-V 포트 등을 포함하는 잠재적인 제안 가운데 첫 번째다.    현재 오픈JDK(OpenJDK) 커뮤니티에 올라와 있는 자바 19 제안은 자바 프로그램이 자바 런타임 외부의 코드 및 데이터와 상호 운용할 수 있는 외부 함수 및 메모리 API다. 이 기능은 오는 9월 공개될 JDK(Java Development Kit) 19에서 미리 볼 수 있다.  ‘JEP(JDK Enhancement Proposal) 424’로 식별되는 외부 함수 및 메모리 API는 외부 메모리에 액세스하여 JVM 외부의 코드를 호출한다. 이 API는 JDK 17의 인큐베이터 단계에 포함됐었으며, 3월 22일 릴리즈될 JDK 18에서 다시 인큐베이팅될 예정이다. JDK 19에서 이 API는 피드백에 따라 개선 사항을 통합하는 프리뷰 단계로 이동한다. JDK 19는 6개월 동안 지원되는 자바의 단기 릴리즈다.  이 밖에 JDK 19에서 지원할 가능성이 큰 기능은 벡터 API다. 이는 JDK 18에서 세 번째로 인큐베이팅되고 있으며, 네 번째 인큐베이팅이 제안됐다. 이 API는 최적의 벡터 명령어로 런타임에 컴파일하는 벡터 계산을 표현한다. JDK 18에서 두 번째 프리뷰를 진행 중인 스위치 표현식 및 문의 패턴 매칭도 제공할 가능성이 높은 또 다른 기능이다.  오라클은 올해 자바에서 4가지 이니셔티브를 계속 발전시켜 나갈 것이라고 밝혔다. 여기에는 ▲고급 JVM 및 언어 기능을 인큐베이팅하기 위한 프로젝트 발할라(Project V...

2022.03.11

제이레벨(JRebel)의 설문조사 결과에 따르면 전문 자바 개발자의 3분의 1 이상이 메인 애플리케이션에 8년 된 자바 버전을 사용하고 있는 것으로 나타났다.  8년 전 출시된 자바 8이 여전히 가장 많이 사용되는 자바 버전인 것으로 조사됐다. 하지만 설문 조사 결과 자바 17로 업그레이드할 계획인 기업도 많은 것으로 드러났다.     ‘메인 애플리케이션에 어떤 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)은 퍼포스에서 만든 자바 개발 도구다. 이 밖에 다...

2022.03.04

자바스크립트 개발자를 대상으로 실시한 ‘2021년 JS 현황(2021 State of JS)’ 설문조사에서 마이크로소프트의 자바스크립트 기반 프로그래밍 언어 ‘타입스크립트(TypeScript)’ 사용이 6년 전에 비해 급증한 것으로 나타났다. 아울러 웹어셈블리 및 프로그레시브 웹 앱 사용도 크게 증가했다.    지난 2월 15일(현지 시각) 발표된 2021 JS 현황 보고서에 따르면 어떤 ‘자바스크립트 기반 언어(JavaScript flavors)’를 사용하는지 묻는 질문에 전체 설문조사 응답자의 69%가 타입스크립트를 쓰고 있다고 밝혔다. 6년 전에는 21%에 불과했다. 여기서 ‘자바스크립트 기반 언어(JavaScript flavors)’는 자바스크립트로 컴파일하는 언어를 의미한다. 그 뒤를 이어 엘름(Elm), 플로우(Flow), 커피스크립트(CoffeScript)가 각각 2.4%, 1.7%, 1.5%로 큰 차이를 보였다.  한편 타입스크립트는 2012년 오픈소스로 공개됐다. 최신 버전은 타입스크립트 4.5.5이며, 타입스크립트 4.6은 릴리즈 캔디데이트 상태다. 이번 설문조사는 2022년 1월 13일부터 2월까지 진행됐으며, 총 1만 6,085명이 참여했다.  이 밖에 ‘2021 JS 현황’ 보고서의 내용은 다음과 같다.  • 오늘날 자바스크립트는 지난 2016년보다 훨씬 더 나은 상태에 있다고 보고서는 언급했다. 이어서 첫 JS 현황 설문조사가 이뤄졌을 당시에는 타입스크립트를 사용하는 비율이 21%에 불과했지만 현재는 69%에 달한다고 설명했다.  • 전체 응답자의 15.6%가 웹어셈블리(WebAssembly)를 사용하고 있다고 말했다. 2020년과 2019년에 각각 10.5%, 7.2%에서 증가한 수치다.  • 올해 설문조사에서 프로그레시브 웹 앱(Progressive Web Apps)을 사용하고 있다고 밝힌 응답자는 62.2%에 달했다. 작년과 재작년은 각각 55.9%, 48...

2022.02.22

기술 업계는 작년 말 오픈소스 아파치 로그4j 소프트웨어에서 발견된 심각한 취약점이 미칠 장기적 영향을 계속해서 파악하고 있으며, 美 상원도 마찬가지다.  사이버 스테이트크래프트 이니셔티브(Cyber Statecraft Initiative)의 책임자 트레이 허 박사는 이번 주 개최된 美 상원 국토 안보 및 정부위(US Senate Committee on Homeland Security&Government Affairs)의 청문회에서 “오픈소스는 문제가 아니다”라고 밝혔다. 그는 “소프트웨어 공급망 보안 문제는 수년 동안 사이버 정책 커뮤니티를 괴롭혀왔다”라고 말했다.  업계 전문가들은 로그4j 결함과 그 영향을 해결하기 위해서는 장기적인 투쟁을 해야 할 것으로 예측해왔다. 이를테면 시스코 탈로스(Cisco Talos)의 보안 연구진은 앞으로 로그4j가 널리 악용될 것이며, 사용자는 영향을 받는 제품을 패치하고 가능한 한 빨리 완화 솔루션을 구현해야 한다고 권고했다.    자바 로그 소프트웨어는 클라이언트/서버 애플리케이션 개발을 지원하는 사용하기 쉬운 공통 유틸리티로, 기업 및 소비자 서비스, 웹 사이트 및 애플리케이션에서 널리 사용된다. 이것이 악용되면 로그4j 취약점을 통해 인증되지 않은 원격 행위자가 영향을 받는 서버 시스템을 제어하고 회사 정보에 액세스하거나 DoS 공격을 발생시킬 수 있다. 상원 패널은 업계의 대응과 향후 소프트웨어 위험 노출을 막기 위한 방법을 모색하고자 전문가들을 호출했다. 로그4j는 오픈소스 소프트웨어에서 발견됐기 때문에 전문가들은 중요한 플랫폼에서 오픈소스 소프트웨어의 사용을 검토하는 데 많은 시간을 할애했다.  위원회 의장이자 민주당 상원의원인 개리 피터스는 “12자만 입력하면 악용될 수 있는 로그4j 취약점은 오픈소스 코드, 즉 개인에 의해 개발되고 자유롭게 사용 가능한 코드에서 발견되는 취약점을 포함하여 소프트웨어 취약점이 얼마나 널리 퍼져 있는지 보여주는 한 가...

2022.02.10

마이크로소프트가 비주얼 스튜디오 코드에 도입할 예정인 새로운 자바 관련 기능을 담은 2022년 로드맵을 공개했다. 이 로드맵의 목표 중 하나는 다른 자바 IDE에서 VS 코드로 쉽게 마이그레이션할 수 있도록 하는 것이다.  회사에 따르면 현재 비주얼 스튜디오 코드를 사용하는 자바 개발자가 150만 명을 넘는다. 이러한 사용자를 지원하기 위해 2022 로드맵에서는 ‘내부 루프’ 개발 경험, 클라우드 네이티브 개발, 빌드 도구, 성능 및 안정성, 기타 사용자 경험 측면을 포함해 여러 투자 영역이 설정됐다.    먼저, 내부 루프 개발을 위해 코드 완성 인텔리전스를 개선하고, 관련성 높은 코드 조각 생성 및 사용자 선호도에 따른 다양한 단축키를 제공할 예정이다. 디버깅 개선 사항에는 가상 스레드 지원, 컴파일된 클래스 디버그 허용, 변수 보기에서의 더 빠른 평가 및 람다 표현식 평가 등이 포함된다.  2022년 로드맵에는 자바 18 지원도 포함돼 있다(한편 자바 18은 3월에 릴리즈될 예정이다). 클라우드 네이티브 개발의 경우 쿠버네티스 그리고 애저 스프링 클라우드(Azure Spring Cloud) 등 다양한 클라우드 서비스와의 통합을 강화할 계획이다. 이 밖에 로드맵에 언급된 목표는 다음과 같다.  • 성능 및 안정성: 자바 언어 서버(Java Language Server)의 안정성을 개선하고, 프로젝트 가져오기 시간을 단축한다.  • 사용자 경험: 기능을 더 쉽게 검색하고 사용할 수 있도록 사용자 경험을 개선한다. 또한 제이유닛(Junit) 테스트, 스윙/자바FX(Swing/JavaFX) 애플리케이션과 관련된 패키지 가져오기/프로젝트 생성 경험을 개선하고, VS 코드 자바에서 실시간 공유(Live Share)를 지원한다.  • 빌드 도구: 메이븐(Maven) 및 그래들(Gradle) 확장 기능을 개선한다.  • 스프링 부트(Spring Boot) 엔드투엔드 지원: 스프링 부트...

2022.01.27

이미 위험에 처했을지도 모르는 이유, 로그4j 취약점을 탐지 및 완화하는 방법, 앞으로 코드 보안을 개선하는 방법을 자세하게 살펴본다.  이달 초 보안 연구진은 수만 개의 웹 애플리케이션에서 사용되는 ‘로그4j’ 자바 소프트웨어에서 취약점을 발견했다. 이 코드는 마인크래프트(Minecraft)부터 스팀(Steam), 아이클라우드(iCloud), 포티넷(Fortinet), 레드햇(Red Hat)까지 모든 소비자 및 기업 시스템에서 널리 사용되고 있다. 한 전문가는 수백만 개의 엔드포인트가 위험에 처할 수 있다고 추정했다.   로그4j는 솔라윈즈와 카세야 등 일련의 소프트웨어 공급망 공격 중 가장 최근에 발생한 일이다. 로그4j 취약점이 밝혀진 이후 많은 보안업체 및 애널리스트가 무엇을 해야 하는지 여러 정보를 공개했다. 이를테면 거진 최후의 날에 가까운 시나리오를 게시한 사람도 있었고, 덜 심각하게 전망하는 사람도 있었다.  체크포인트 소프트웨어 테크놀로지스(Check Point Software Technologies)에 따르면 고객층의 절반가량에서 취약점 공격이 발견됐다. 콘트라스트 시큐리티(Contrast Security)는 자바 애플리케이션의 58%에 취약한 버전이 존재하지만 실제로 로그4j를 사용하는 경우는 37%에 불과한 것으로 조사됐다고 전했다.  4가지 문제는 CVE-2021-44228, CVE-2021-45046, CVE-2021-4104, CVE-2021-45105다. 美 사이버보안 및 인프라 보안국(Cybersecurity and Infrastructure Security Agency; CISA)은 영향을 받은 애플리케이션 목록과 다양한 벤더 블로그 링크를 포함한 웹 페이지를 공개하고 지속적으로 업데이트하고 있다.  이 문제는 원격 코드 실행을 허용하는 JDNI(Java Naming and Directory Interface) 및 JM어펜더(JMSAppender) 이벤트 메시지와 같은 로깅...

2021.12.31

지난 주말, 많은 개발자와 유지관리자가 앞다퉈 ‘로그4j(Log4j)’ 취약점에 대응하기 위해 나섰지만 이 문제를 바로잡기 위해 해야 할 일은 여전히 많다.  지난 주말 인터넷에 불이 났다. 긴급구조요원들은 곧장 현장으로 달려갔다. 대부분 무급 유지관리자 또는 개발자가 여가 시간에 취약점을 패치했고, 지침을 발행했으며, 혼란 속에서 절실하게 필요했던 명확성을 제공했다.    12월 9일 아파치 재단(Apache Foundation)은 거의 모든 자바 애플리케이션에 사용되는 오픈소스 로깅 프레임워크 ‘로그4j(Log4j)’에서 발견된 치명적인 제로데이 취약점 ‘로그4셸(Log4Shell)’에 관한 긴급 업데이트를 발표했다.  CVE-2021-44228로 식별된 이 버그를 통해 공격자는 로그4j 라이브러리를 사용하여 로그 메시지를 작성하는 모든 시스템에서 임의의 코드를 실행할 수 있다. 이는 CVSS 점수에서 가장 높은 심각도를 일컫는 10점을 받았다.  클라우드플레어(Cloudflare)의 CTO 존 그레이엄은 “허트블리드(Heartbleed)와 쉘쇼크(ShellShock) 이후로 인터넷에서 가장 심각한 취약점일 가능성이 크다”라고 말했다. 심지어 마인크래프트(Minecraft)도 안전하지 않았다. 최초 대응자 여러 개발자와 유지관리자가 주말 동안 최대한 많은 자바 애플리케이션을 패치하기 위해 즉시 출동했다. 첫 번째 방어선은 비영리 아파치 소프트웨어 재단의 로깅 서비스팀에서 유지관리하는 로그4j 자체였다. 아파치의 로깅 서비스팀은 전 세계의 거의 모든 시간대에 분산된 16명의 자원봉사자로 구성돼 있다. 소프트웨어 엔지니어 겸 아파치 로깅 서비스 프로젝트 관리 위원회(Project Management Committee; PMC)의 회원인 개리 그레고리는 “여가 시간에 소프트웨어를 작성하고 퍼즐을 푸는 것을 좋아하기 때문에 이 일을 한다”라고 언급했다.  PMC의 주된 의사소통 채널은 이메일이며,...

2021.12.20

‘클라우드 네이티브 컴파일러(Cloud Native Compiler)’ 서비스는 JVM 전체에서 이전에 최적화된 컴파일을 재사용하여 자바 애플리케이션 성능을 향상시킨다.    자바 소프트웨어 업체 아줄(Azul)이 JVM의 성능 및 시작 속도를 높이는 클라우드 기반 컴파일 서비스 ‘클라우드 네이티브 컴파일러’를 출시했다. 이를 통해 자바(Java), 스칼라(Scala), 코틀린(Kotlin), 클로저(Clojure), 그루비(Groovy), 제이루비(JRuby) 등 JVM 기반 언어의 성능이 향상됐다고 회사 측은 밝혔다.  회사에 따르면 아줄 인텔리전스 클라우드(Azul Intelligence Cloud) 플랫폼의 제품으로 공개된 클라우드 네이티브 컴파일러는 연결되는 모든 JVM의 성능 및 시작 속도를 강화하기 위해 JVM 전체에서 이전에 최적화된 컴파일을 탄력적으로 확장 및 축소하고 재사용한다. 또한 모든 자바 애플리케이션과 호환되는 클라우드 네이티브 컴파일러는 JVM(Java Virtual Machine)에서 JIT(Just-in-tim) 컴파일을 분리하며, 징(Zing)이라고 알려진 아줄의 고성능 자바 런타임 ‘플랫폼 프라임(Platform Prime Java)’과 함께 작동한다고 회사 측은 설명했다.    클라우드 네이티브 컴파일러는 전체 쿠버네티스 환경에서 클라우드 네이티브 애플리케이션으로 실행된다. 모든 클라우드에서 사용할 수 있다. 이 밖에 클라우드 네이티브 컴파일러로 얻을 수 있는 이점은 다음과 같다.  • JIT 컴파일을 클라우드 리소스로 전환해 운영 비용을 절감할 수 있다.  • 프론트엔드, 백엔드, API 게이트웨이, 컨테이너화된 애플리케이션, 마이크로서비스를 포함한 여러 애플리케이션의 처리량 및 응답성을 향상시켜 애플리케이션 성능을 개선한다.  • 아파치(Apache)의 카산드라(Cassandra) 데이터베이스, 솔라(Solr) 검색엔진, 카프카(Kaf...

2021.12.16

널리 사용되는 ‘Log4j’ 라이브러리에 버그가 있으면 공격자는 Log4j를 사용하여 로그를 작성하는 모든 시스템에서 임의의 코드를 실행할 수 있다.  아파치 재단이 거의 모든 자바 애플리케이션에 포함된 로깅 도구 Log4j의 치명적인 제로데이 취약점에 관한 긴급 업데이트를 발표했다. 이는 ‘Log4Shell’로 명명됐으며, 식별자는 CVE-2021-44228이다.  이 취약점은 Log4j 라이브러리의 버그를 통해 발생하는데, 이를 통해 공격자는 Log4j를 사용하여 로그 메시지를 작성하는 시스템에서 임의의 코드를 실행할 수 있다. 따라서 Log4j를 포함하는 애플리케이션 사용자라면 누구나 즉시 주의를 기울여야 한다.    Log4Shell을 해결해야 하는 이유 Log4j는 많은 자바 애플리케이션에서 사용되는 라이브러리다. 현재 가장 널리 쓰이는 자바 라이브러리이기도 하다. 대부분의 자바 애플리케이션은 데이터를 기록하며, Log4j가 주로 활용된다.   여기서 문제는 Log4j를 찾는 것이다. 자바 패키징의 작동 방식 때문에 Log4j가 애플리케이션의 어딘가 숨어 있을 수 있고, 심지어는 그 사실을 모르고 있을 가능성이 크다.  자바 생태계에서 종속성은 자바 라이브러리로 사용할 수 있는 패키지인 JAR(Java archive) 파일로 배포된다. 메이븐(Maven), 그래들(Gradle) 등 일반적으로 사용되는 도구는 자바 애플리케이션을 빌드할 때 JAR 파일을 자동으로 추가할 수 있다. JAR이 종속성을 충족하기 위해 다른 JAR을 포함할 수도 있다.  즉, 취약점이 애플리케이션에서 여러 수준 아래에 숨겨질 수 있다. 어떤 경우에는 하나의 종속성이 수백 개의 다른 종속성을 가져와 (이를) 찾기 훨씬 더 어려울 수 있다.  기본적으로 자바 세계에서는 JAR에 중첩된 JAR에 JAR이 중첩될 수 있다. 이는 모든 것을 조사해야 하는 수많은 계층을 만든다. 이에 따라 Log4j가 ...

2021.12.14

젯브레인이 지난 11월 29일(현지 시각) ‘플릿(Fleet)’의 초기 프리뷰를 공개했다. 회사에 따르면 플릿은 소프트웨어 개발 경험을 재창조하는 차세대 범용 IDE다. 이어서 플릿은 단순하며, 가볍고, 유연할 뿐만 아니라 추가 구성없이 사용할 수 있다고 젯브레인은 전했다.    자사의 자바 개발용 ‘인텔리제이 아이디어 IDE(IntelliJ Idea IDE)’도 계속해서 개선할 예정이라고 회사 측은 밝혔다. 플릿은 IDE 구성에 또 다른 뷰를 제공하는 한편, 경량 코드 편집기 역할을 한다. 이는 기존 도구를 대체하지 않고 더 많은 선택지를 제시한다는 게 젯브레인의 설명이다.  젯브레인 마케팅 부사장 유진 토포로프는 “인텔리제이 기반 제품군과 플릿은 상당 기간 공존(co-exist)할 것으로 예상한다. 고객에게 선택권을 열어 둘 것”이라고 말했다.  젯브레인은 간단한 작업이라면 플릿은 순식간에 준비된다고 언급했다. 즉, 개발자는 프로젝트 및 컨텍스트-인식 코드 완성, 정의 및 사용 탐색, 리팩토링, 빠른 수정, 즉석 코드 검사 등 IDE에서 사용했던 기능을 클릭 한 번으로 쓸 수 있다. 플릿의 모든 스마트 기술은 인텔리제이 코드 처리 엔진을 활용한다.  플릿은 특정 프로젝트를 기반으로, 필요할 때 즉시 사용할 수 있는 전용 기능을 제공하도록 설계됐다. 협업 및 원격 개발도 가능하다. 플릿은 현재 자바, 코틀린, 고, 파이썬, 러스트 프로그래밍 언어를 지원하며, 앞으로 더 다양한 언어를 지원할 계획이다.  젯브레인 개발팀은 다양한 아케틱처, 기술, UX 접근법을 실험하면서 몇 년 동안 플릿을 개발해 왔다. 해당 IDE는 개발자가 어디에서 코딩하는지, 어떤 프로그래밍 언어를 사용하는지, 어떤 개발 워크플로우를 따르는지 관계없이 생산적일 수 있도록 지원한다. ‘플릿’에 관심 있는 개발자는 이곳을 통해 프리뷰 프로그램에 등록하면 된다. ciokr@idg.co.kr  

2021.11.30

젯브레인에서 만든 JVM, 웹, 모바일 개발용 언어의 최신 업데이트 ‘코틀린 1.6.0’이 공식 출시됐다. 이번 릴리즈에서는 네이티브 개발을 위한 새로운 메모리 관리자가 안정화 버전으로 제공된다.    회사에 따르면 코드를 네이티브 바이너리로 컴파일하는 코틀린/네이티브용 메모리 관리자는 (코틀린에서) 일관된 개발 경험을 제공할 수 있도록 지원한다. 메모리 관리자는 스레드 간의 객체 공유 제한을 해제한다. 또한 누수 없는 동시 프로그래밍 기본 요소를 제공한다. 이는 안전하며, 별도의 관리나 주석이 필요 없다고 젯브레인은 덧붙였다.  지난 11월 16일 공개된 코틀린 1.6.0을 설치하면 새로운 메모리 관리자를 디폴트로 사용할 수 있다. 최신 릴리즈 설치 지침은 공식 블로그에서 확인할 수 있다. 젯브레인 인텔리J 아이디어(JetBrains IntelliJ Idea) 또는 안드로이드 스튜디오 IDE(Android Studio IDE) 사용자는 자동으로 업데이트할 수 있다.  이 밖에 코틀린 1.6.0의 새로운 기능 및 개선사항은 다음과 같다.  • 코틀린/네이티브에서 LLVM 종속성이 개선됐다. LLVM 버전이 11.1.0으로 업데이트됐으며, 종속성 크기 감소 등의 이점을 지원한다.  • 이제 when 문이 완전하지 않으면 봉인된 when 문에서 컴파일러 경고를 생성한다. 코틀린 1.5.30에서 프리뷰로 지원됐던 해당 기능은 (최신 릴리즈에서) 안정화 버전으로 제공된다.  • suspend 함수 유형을 슈퍼 인터페이스로 구현하기 위한 지원이 안정화됐다. 이는 코틀린 코루틴 디자인에서는 누락된 부분 중 하나였다. 아울러 일반 함수 유형에서 일시중단 함수 유형으로의 변환이 안정화됐다. 이제 개발자는 일시중단이 매개변수로 예상되는 일반 함수 유형의 표현식을 전달할 수 있다. 컴파일러는 자동으로 변환을 수행한다. 이 기능은 코틀린에서 일반 함수와 일시중단 함수 간의 불일치를 수정한다.  ...

2021.11.22

하드웨어 자원을 효율적으로 사용하는 한편, 동시 프로그래밍을 훨씬 더 쉽게 만드는 것을 목표로 하는 새로운 개발 제안이 오픈JDK 커뮤니티에 제출됐다.  처리량이 많은 동시 애플리케이션을 작성, 유지관리, 모니터링하는 데 필요한 리소스를 ‘크게’ 줄이기 위한 자바용 가상 스레드가 제안됐다.    지난 11월 15일 게시된 오라클의 JEP 초안은 자바 표준 버전의 일부로 가상 스레드를 제안했다(프리뷰). 가상 스레드는 운영체제(OS) 스레드를 나타내는 자바의 플랫폼 스레드를 경량의 사용자-모드 스레드 구현으로 보완하여, 하드웨어를 효율적으로 사용하고 비용을 대폭 절감하고자 한다.  해당 제안서에 따르면 스레드는 트랜잭션 등의 동시성 단위를 나타내는 데 유용하다. 하지만 현재 자바의 스레드 구현은 각 자바 스레드에 OS 스레드를 사용하는데, OS 스레드는 (소켓보다) 희소하고, 비용도 많이 든다. 이는 최신 서버가 OS 스레드보다 훨씬 더 많은 동시 트랜잭션을 처리할 수 있다는 의미라고 개발팀은 설명했다.  처리량이 많은 서버 소프트웨어를 작성하는 개발자는 하드웨어를 (낭비하지 않고) 효율적으로 사용해야 했고, 따라서 트랜잭션 간에 스레드를 공유해야 했다.  이 작업은 각 트랜잭션에서 새 스레드 생성 비용을 절감하기 위해 다른 트랜잭션에 스레드를 대여하는 스레드 풀을 사용하여 수행됐다. 이것으로 충분하지 않다면  개발자는 I/O를 대기하는 트랜잭션 중간에도 스레드를 풀에 반환했다.  그 결과, 별도의 호환되지 않는 API 집합을 필요로 하는 비동기식 프로그래밍 방식이 생성되고, 문제 해결, 디버깅, 모니터링 및 프로파일링도 어려워진다. 가상 스레드는 OS 스레드를 차단하지 않는 java.lang.Thread의 사용자-모드 구현으로, 최적에 가까운 하드웨어 활용을 지원한다. 또한 이는 높은 처리량과 높은 수준의 동시성을 허용하며, 해당 프로그램은 자바 플랫폼 및 도구의 스레드 기반...

2021.11.18