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.

자바

"기업 수요가 가장 많은 프로그래밍 언어는 자바"

기업이 가장 원하는 프로그래밍 언어 기술은 자바, 파이썬, SQL인 것으로 나타났다. 고, 타입스크립트에 대한 수요가 커지고 있지만 아직 상위 3개 언어에는 크게 미치지 못했다. 이는 지난 10일 공개된 '해커랭크 2023 개발자 스킬 리포트(2023 HackerRank Developer Skills Report)'의 주요 내용이다. 기업과 개발자를 위한 기술 문제 해결 플랫폼인 '해커랭크 워크(HackerRank Work)'를 통해 수집한 정보를 분석해, 기업과 개발자에게 가장 수요가 많은 소프트웨어 엔지니어링 스킬과 프로그램 언어 순위를 매겼다.  상위 5개 언어는 자바, 파이썬, SQL, C++, 자바스크립트 순이었다. 배시(Bash), C#, 고, 타입스크립트, R이 뒤를 이었지만 상위 5개 언어와는 차이가 컸다. 이중 수요가 가장 빠르게 증가하는 언어는 타입스크립트와 고였다. 고는 2021년 대비 2022년에 301% 수요가 늘었고, 타입스크립트는 392%였다. 스위프트와 루비에 대한 수요는 다소 줄어든 것으로 나타났다. 스위프트는 2021년 대비 80%에 그쳤고 루비는 66%였다. 특정 언어에 대한 기업의 수요를 수치화하기 위해 해커랭크는 해커랭크 워크 테스트 결과를 분석했다. 기술 수요는 특정 라이브러리 문제를 이용한 해커랭크 워크 테스트의 수를 기반으로 측정했다. 개발자 선호도는 여러 언어 중 해커랭크 워크에 제출한 언어와 그 숙련도를 기준으로 삼았다. 해커랭크 커뮤니티 데이터 역시 참고했다. 그밖에 이번 보고서의 주요 내용은 다음과 같다.   2022년에 R과 스칼라는 개발자층이 오히려 줄었다. 2021~2022년에 성장세를 보인 기술은 2023년에도 계속 성장할 전망이다. 자바, 파이썬, SQL 등이 여기에 해당한다. REST API 기술에 대한 수요가 179% 늘었다. 쿠버네티스 컨테이너 오케스트레이션 기술에 대한 수요가 늘면서 도커 스킬에 대한 수요는 줄었다. 기업과 개발자 모두 머신러닝과 데이터 과학 ...

자바 파이썬 SQL 2022.11.15

그랄VM, 자바 커뮤니티에 코드 기여 확대

오라클이 그랄VM(GraalVM) 코드를 오픈JDK에 제공하겠다고 밝혔다. 자바 개발과 그랄VM 개발의 속도를 맞추겠다는 전략이다.    그랄VM은 자바 개발 키트(Java Development Kit, JDK)에 고성능 처리 기능을 더한 자바VM이다. 그랄VM은 그동안 자바와 다른 별개의 개발 주기 및 프로세스와 기능을 가지면서, 자바 기술 통합에 어려움이 있었다. 오라클은 이번 발표 이후 그랄VM JIT(Just-In-Time) 컴파일러와 네이티브 이미지와 관련된 코드를 기여하는 것을 시작으로 두 기술이 함께 논의될 수 있는 기반을 만들 계획이다. 해당 업데이트 덕에 자바 코드를 독립 실행형 파일로 미리 컴파일하는 과정이 더 편해질 것으로 보인다. 그랄VM 코드가 커뮤니티와 함께 공유되면 그랄VM에 대한 투명성이 높아지고 기술에 대한 예측도 보다 쉬워질 예정이다. 오라클은 현재 개발 중인 그랄VM를 주로 커뮤니티에 기여하고, 이전 버전은 깃허브에 저장해 놓겠다고 밝혔다. 또한 기존에 나온 그랄VM CE(커뮤니티 에디션) 버전이나 그랄VM EE(엔터프라이즈 에디션) 버전 업데이트는 계속 지원될 것으로 보인다. 궁극적으로 그랄VM 출시 일정은 내년 자바 출시 일정에 맞춰 조정된다.  그랄VM은 더 적은 리소스를 사용하면서 자바 애플리케이션 성능을 높이는데 최적화된 기술이다. 또한 하나의 응용 프로그램에서 여러 프로그래밍 언어를 사용할 수 있으며, 이런 특징 덕에 자바 외 언어를 호출하는 데 드는 비용을 줄일 수 있다. 앞으로 그랄VM 개발 과정에는 다음과 같은 정책이 적용된다.    릴리스당 하나의 자바 SE 플랫폼 사양 지원 연 2회 기능 출시 매년 4회 분기별 중요 패치 업데이트 2년마다 장기적 관점의 지원 사항 지원 그랄VM 기술 기여 확대 오라클은 한 개 이상 오픈JDK 프로젝트에 그랄VM을 기여할 예정이며, 오픈JDK 커뮤니티와 관련 기술 프로세스를 공유할 예정이다. 또한 새로운 그랄V...

그랄VM 자바 오라클 2022.10.31

“누구나 자바 버전 및 오래된 앱 감지 쉽게” 자바 관리 서비스의 탐색 기능 공개

오라클이 클라우드 기반 자바 관리 서비스(Java Management Service, JMS)에서 제공하는 탐색 기능을 누구나 이용할 수 있게 열어 두었다고 발표했다. 이전에는 오라클 자바 SE 구독자 또는 오라클 클라우드 인프라스트럭처(Oracle Cloud Infrastructure, OCI) 사용자만 이용할 수 있었지만, 이번 발표 이후 누구나 해당 탐색 기능을 활용할 수 있게 됐다.    JMS는 OCI 안에서 제공하는 네이티브 기능이다. OCI 혹은 고객의 자체 데이터 센터에서 운영되는 자바 개발 요소를 모니터링할 때 쓸 수 있다. 탐색 기능은 자바 런타임 설치나 버전을 확인하고, 어떤 응용 프로그램이 어떤 런타임에 사용되는지 검토한다. 오래된 앱을 감지하는 데 특히 유용하다.  JMS에서 제공하는 탐색 기능은 누구나 이용할 수 있으나, 자바 런타임 설치 및 삭제 같은 고급 기능은 여전히 자바 SE 구독자나 OCI 고객만 활용할 수 있다. 또한 암호화나 서드파티 라이브러리 사용 여부를 확인하는 기능 역시 유료 사용자만 접근할 수 있다. 처음 탐색 기능을 이용하는 사용자는 일부 비용을 지원받을 수 있지만, 추가적인 이용 시 OCI 데이터 모니터링 비용이 부과될 수 있다는 점을 주의하자.  editor@itworld.co.kr

자바 JMS OCI 2022.10.24

"수십 년째 굳건하게" C 언어가 왕좌 지키는 이유

‘C 언어’는 지난 1972년 개발된 이후 지금까지 전 세계에서 널리 사용되고 있으며, 소프트웨어 시대의 핵심적인 기본 구성요소로 군림하고 있다. 하지만 지난 수십 년 동안 새로운 언어가 많이 등장했다. 그중에는 노골적으로 C 언어의 아성에 도전한 언어도 있었고, 인기를 끌면서 C 언어를 조금씩 갉아먹은 언어도 있었다. C 언어와 C++, 자바, C#, 러스트, 파이썬 그리고 ‘쌩신입’인 카본과 C 언어를 비교해 살펴본다.   C vs. C++ C 언어의 가장 흔한 비교 대상은 C++다. 이름에서 알 수 있는 것처럼 C++는 C 언어의 확장판으로 개발됐다. C++의 구문 및 접근 방식은 C와 유사하지만 이는 네임 스페이스, 템플릿, 예외 처리, 자동 메모리 관리 등 C에서는 기본 제공하지 않는 매우 유용한 기능을 지원한다. 데이터베이스나 머신러닝 시스템 등 최상급 성능을 요하는 프로젝트는 C++의 이러한 기능을 사용해 작성되는 경우가 많다. 또한 C++는 C보다 훨씬 더 적극적인 확장 중이다. 곧 출시될 C++ 23은 모듈, 코루틴, 더 빠른 컴파일, 모듈화된 표준 라이브러리 등 많은 기능을 제공할 예정이다. 반면에 C 표준의 최신 버전(C2x)은 추가 기능이 거의 없으며, 하위 호환성 유지에 주안점을 두고 있다.  문제는 C++의 모든 장점이 동시에 단점으로 작용하기도 한다는 것인데, 이 단점이 크다. C++의 기능을 많이 사용할수록 복잡성이 증가하며, 결과를 통제하기가 어려워진다. C++의 특정 부분만 제한적으로 사용하면 최악의 문제는 대부분 피할 수 있다. 이러한 복잡성을 원천적으로 차단하기도 한다. 예를 들면 리눅스 커널(Linux Kernel) 개발팀은 C++를 기피하며, 대부분의 리눅스는 여전히 C로 작성된다(현재 러스트를 향후 커널 추가를 위한 언어로 보고 있긴 하다).  물론 C++가 고수준 기능을 풍부히 갖추고 있는 이유는 분명하다. 하지만 현재와 미래의 프로젝트 및 프로젝트팀에 미니멀리즘이 더 적합하다면 C...

C 언어 C++ 파이썬 2022.10.04

오라클, 7월 말 '자바 7' 확장 지원 중단한다

11년 된 표준 자바 릴리즈 ‘자바 7’의 끝이 다가왔다. 오라클은 이 릴리즈의 확장 지원을 2022년 7월 말 중단할 예정이라고 밝혔다.    공식적인 확장 지원(Extended Support)이 중단되기 때문에 ‘자바 7’은 오라클 평생 지원 정책(Oracle Lifetime Support Policy)에 따라 오라클 라이선스가 종료되는 시점까지 제공되는 지원 모드(Sustaining Support)로 전환된다. 추가 패치 업데이트, 버그 또는 보안 수정, 기능 배포는 지원되지 않으며, 제한된 지원만 제공된다.  2011년 7월 28일 출시된 ‘자바 7’은 오라클이 2010년 자바를 개발한 썬 마이크로시스템즈(Sun Microsystems) 인수 이후 5년 만에 처음으로 선보인 메이저 자바 릴리즈였다. 확장 지원 종료는 오라클 퓨전 미들웨어(Oracle Fusion Middleware)의 특정 이전 버전에서 (인증된) 자바 개발 키트(Java Development Kit)를 더 이상 사용할 수 없다는 의미다.  7월 22일 마지막으로 업데이트된 오라클 지원 게시판에 의하면 자바 SE 7을 사용하는 지원 고객은 자바 SE 버전 8 또는 11 등 지원되는 표준 자바 버전으로 업그레이드해야 한다.  뉴렐릭(New Relic)이 지난 4월 발표한 자바 생태계 보고서에서 애플리케이션의 1.71%가 프로덕션 환경에서 여전히 자바 7을 사용하고 있는 것으로 조사됐다. 자바 7 또는 자바 6을 사용하는 애플리케이션의 대부분은 업그레이드되지 않은 레거시 애플리케이션이었다고 회사 측은 전했다.  최신 자바 릴리즈인 버전 18은 필수 소프트웨어 업데이트 및 연중무휴 서비스를 포함한 프리미어 지원(Premier Support)이 9월까지 제공될 예정이다. 이전 버전인 자바 17은 LTS 릴리즈이기 때문에 몇 년간 프리미어 지원이 제공된다. 오라클의 표준 자바 지원 로드맵은 이곳에서 확인할 수 있다. ciokr@id...

오라클 자바 자바 7 2022.07.28

자바가 여전히 위대한 개발 언어인 7가지 이유

소프트웨어 분야에서 가장 흥미로운 현상 중 하나는 자바의 끈질긴 생명력이다. 언어이자 플랫폼으로써 자바는 기술 세계의 급격한 변화를 거치면서도 생존했고 자바 내부 구조도 그에 맞춰 변화됐다. 자바는 어떻게 해서 20년 이상 엔터프라이즈와 오픈소스에서 모두 중심을 유지하고 있을까? 가장 중요한 몇 가지 요소를 살펴보자.     자바 커뮤니티 프로세스 자바는 여러 가지 작업을 더 편리하게 하기 위한 대안으로 탄생했다. 지금은 그동안 반복된 도전에도 불구하고 모두가 인정하는 엔터프라이즈 소프트웨어의 기둥이다. 급격한 변화를 겪으면서도 자바가 그 생명력을 유지하는 이유는 무엇일까? 한 가지 중요한 요소는 개발자의 참여를 이끌어 자바의 활발하고 동적인 힘을 유지하는 거버넌스 구조와 이를 통해 촉진되는 커뮤니티의 열정이다. 자바의 거버넌스는 매끄럽고 기계적인 운영과는 거리가 멀어서, 서로 경쟁하는 이해와 조직의 혼란스러운 조합이다. 이들은 자바 커뮤니티 프로세스(JCP)와 자바 사양 요청(JSR)을 통해 저마다 목소리를 낸다. JCP는 자바 기술에 대해 깊은 관심을 두고 있는 사람들의 기여와 충돌 해결을 위한 창구다. 관료주의와 정치, 창의성의 독특한 조합이다. 현실의 민주주의와 비슷하다고 할 수 있다. 자바가 성공적으로 람다와 클로저를 포용한 것은 오랜 자바 프로그래머에게는 정말 놀라운 사건이었다. 객체 지향 프로그래밍 언어에 함수 구조를 추가한다는 것은 많은 논란을 일으킨 과감한 결단이었다. 하이버네이트, 스프링(각각 JSR 317, JSR 330)과 같은 기술에 의해 도입된 개념도 공식 플랫폼에 흡수됐다. 자바처럼 광범위하게 사용되는 기술이 여전히 새로운 아이디어를 통합한다는 것은 고무적인 일이다. 커뮤니티에 대한 자바의 기민한 대응은 유용한 개선을 도입하도록 이끈다. 개발자는 자신이 속한 시스템이 변화하는 세계에서 성공하기 위해 끊임없이 개선되는, 살아있는 시스템이라고 느끼게 된다. 자바의 동시성 모델을 재설계하기 위한 대대적인 작업인 ...

자바 언어 개발자 2022.07.21

‘IT 브랜드의 전설’··· 자바의 이름이 자바인 사연

타임 매거진이 자바(Java)를 1995년의 최고의 제품 10종 가운데 하나로 지정한 이후, 자바는 미국 IT 마케팅 분야에 새로운 전설로 자리매김했다. 썬 마이크로시스템즈(Sun Microsystems)의 이 탁월한 기술이 원래대로 오크(Oak)나 그린토크(Greentalk)라는 이름을 유지했다면 어땠을까? 이처럼 성공했을까? 모를 일이다. 멋진 오픈소스 프로그래밍 환경을 배포하면 당연히 인기가 있다. 이를 무엇으로 부를 것인지는 중요하지 않다. 그러나 차세대 애플리케이션 개발자를 위해 새 프로그래밍 언어를 만들던 썬(Sun)에게는 브랜드 정체성이 중요했다. 그 일을 맡았던 담당자는 결국 커피 이름인 '자바'를 상표로 확정했으나 구체적인 과정은 정확히 알려지지 않았다.  다음은 1996년 자바월드(JavaWorld)에 의해 출간된 내용을 정리한 것으로, 미스터리한 ‘자바’라는 이름의 탄생 배경을 어느 정도 알 수 있다.    자바는 어떻게 자바가 되었나  썬의 수석 엔지니어였던 프랭크 옐린은 “변호사들이 ‘오크(OAK)’라는 이름을 사용할 수 없다고 했다. 오크 테크놀로지(Oak Technologies)라는 회사가 이미 상표로 등록했기 때문”이라고 전했다.  옐린은 “새 이름에 대한 아이디어를 찾기 위해 회의가 열렸다. 당시 라이브 오크(Live Oak)라고 불린 집단의 모든 구성원이 참석했다. 괜찮아 보이는 10개 이름을 최종적으로 선택하고 법무지원 부서로 보냈는데, 3개의 이름이 통과됐다. 자바(Java), DNA, 실크(Silk) 였다. ‘자바’라는 이름을 누가 처음 제안했는지는 아무도 기억하지 못했다. 어떤 한 인물이 그 이름을 창안했다는 정도만 추측할 수 있다”라고 말했다.  당시 오크 제품 매니저였던 킴 폴레스(Kim Polese)는 기억이 다르다. 폴레스는 “내가 자바라고 이름을 지었다”라고 말했다.  폴레스는 “자바라는 이름을 짓는데 많은 시간과 에너지를 소비...

자바 역사 썬 마이크로시스템즈 2022.07.20

"클라우드 네이티브로 한 걸음 더 가까이" 다가간 자바 프레임워크 8종

자바 프로그래밍 언어는 처음 등장한 후 30년 가까운 시간 동안 임베디드 칩부터 대규모 서버 팜에 이르기까지 도처에서 활발히 사용되고 있다. 자바가 가진 견고한 가상머신과 방대한 라이브러리의 조합은 어디에서나 실행되는 코드를 쓰기 위한 풍성한 생태계를 구축했다.   그러나 자바는 수천에서 수백만 명에 이르는 사용자 간 연결을 다뤄야 하는 서버에서는 유독 고전했다. 초기 자바 툴은 모든 사용자를 대상으로 비즈니스 로직을 실행하는 서버 측 애플리케이션을 만드는 최적의 툴이었다. J2EE, 하이버네이트(Hibernate), 스프링(Spring)과 같은 자바 프레임워크와 기본적인 자바 서블릿 모델은 강력한 웹 애플리케이션을 비교적 쉽게 만들 수 있게 해주는 요소였다.   이 기술은 자바스크립트와 Node.js가 등장하기 전까지 번성했다. Node.js는 많은 관심을 끌었고 개발자는 자바스크립트 런타임 환경으로 이동하기 시작했다. 이유는 두 가지다. 첫째, 서버와 브라우저 클라이언트에서 동일한 코드를 실행할 수 있다는 점이 개발자의 마음을 샀고, 둘째, Node.js 서버가 리액티브 모델 덕분에 대체로 처리량이 훨씬 더 빨랐다.   자바 생태계도 경쟁하기 위해 환경에 적응했다. 처음 일부 개발자는 자바를 자바스크립트로 변환하는 구글 웹 툴킷과 같은 툴을 채택했다. 이후에는 서버에서 자바의 속도를 높이기 위해 노력했다. 초기 서버용 자바 프레임워크에는 수신되는 각 요청에 자체 쓰레드가 부여된다는 제약이 하나 있었다. 들어오고 나가는 데이터를 확실히 정리하기 위한 방법이었지만 부하가 컸다. 하나의 쓰레드를 만드는 데 수천 바이트의 오버헤드가 발생하고, 그 때문에 각 서버가 처리할 수 있는 사용자 수가 제한될 수 있었다. Node.js는 다른 모델로 이 오버헤드 없이 훨씬 더 많은 사용자를 처리하다.   더 최근에는 자바 개발자가 Node.js 의 혁신을 자바 스택, 특히 클라우드 네이티브 자바 프레임워크로 가져오기도 했다. 이러한 프...

자바 구글클라우드플랫폼 JSON 2022.06.30

“자바가 더 좋아지는 방법” JDK 개선 제안 프로세스와 최신 JEP

자바는 널리 사용되며 많은 요소가 자바에 의존하는 만큼 소프트웨어 인프라의 중요한 한 부분이다. 이 때문에 자바 플랫폼은 안정성을 중시하지만, 한편으로는 변화하는 환경에 적극적으로 대응하고 있다. 자바를 사용하는 사람들의 창의성도 이런 변화에 한몫한다. 이때문에 자바에는 높은 수준의 안정성을 달성하면서 변화를 수용하기 위해 공식적인 프로세스가 있다. 여기서는 자바 플랫폼이 어떤 방식으로 향상되는지를 대략적으로 알아보고, 앞으로 적용될 가장 중요한 새로운 기능에 대해서도 살펴본다.      자바 커뮤니티 프로세스  오랜 경력의 자바 개발자라 해도 자바 플랫폼이 개발, 유지되는 방식에 대해서는 잘 모를 수 있다. 큰 그림으로 들어가기 전에 자바 프로세스가 어떻게 동작하는지부터 알아보자. 핵심은 자바가 실질적으로 오픈소스라는 데 있다. 즉, 마음만 먹으면 자바에 기여할 수 있다. 기여자에게 말하고 그룹에 가입하고 제안을 제출하고 버그를 수정하면 된다.  자바 개발의 뿌리는 자바 커뮤니티 프로세스(Java Community Process, JCP)다. JCP는 수정 사항을 자바 플랫폼에 적용하는 방법을 정의하고, 이 프로세스 자체의 수정도 허용하는 일종의 자기인식적 문서라고 할 수 있다. JCP 최신 버전은 2019년에 채택된 2.11이다.  JCP는 사람들이 맡을 수 있는 다양한 역할에 대한 정의를 포함해서 자바의 새로운 기능과 변경(즉, 기술 사양)을 제안, 검토, 승인하는 방식을 공식화한다. 이와 같은 역할은 자바 사용자 커뮤니티가 플랫폼 관리에 참여할 수 있는 환경을 제공하는 데 도움이 된다.    자바 사양 요청  JCP는 새로운 기능과 변경 제안을 위해 자바 사양 요청(Java Specification Request, JSR)을 사용한다. JSR은 표준화된 양식을 통해 만들 수 있으며, 양식을 사용하려면 무료 JCP 계정을 만들어야 한다.  짐작할 수 있겠지...

자바 JDK 오픈소스 2022.06.08

자바19에 추가될 핵심 기능 7가지

올 9월 출시될 자바 개발 키트(JDK) 19 버전의 7번째 기능으로 구조적 동시성이 추가됐다. 멀티쓰레드 프로그래밍을 간편하게 지원하기 위한 요소다. 구조적 동시성 외에 미리 공개된 6가지 핵심 기능에는 레코드 패턴, 외부 함수와 메모리API(프리뷰), 오픈소스 기반의 리눅스/RISC-V 명령어 집합 구조(ISA) 지원 등이 있다.  자바 공식 개발 계획에 따르면 JDK19(‘자바19’라고도 표현)에는 확장된 제네릭스나 밸류 오브젝트(VO) 등 향후 더 많은 기능이 제공될 것으로 보인다.    오픈JDK 커뮤니티가 발표한 JDK19 공식 일정을 살펴보면 6월 9일부터 21일까지는 자바 기술에 대한 조정 기간을 갖는다. 최종 기술 후보는 8월 11일과 25일 사이 공개되며, 9월 20일에는 최종 버전이 배포된다.  JDK19를 미리 이용하고 싶은 경우 jdk.java.net/19에서 다운로드 가능하다.  JDK19에 추가된 기능은 다음과 같다.  구조적 동시성(인큐베이터) : 아직 인큐베이터 단계로 구조를 갖춘 동시성 라이브러리를 이용해 멀티쓰레드 프로그래밍을 제공한다. 동시성이라는 기능 덕에 여러 태스크를 서로 다른 쓰레드 안에 운영하고 동시에 단일한 유닛 형태로 관리할 수 있다. 따라서 사용자는 에러 관리나 취소 관련 작업을 효율적으로 운영할 수 있다. 안정성이 높아지고 문제의 탐지나 조사도 더 쉬워진다.  레코드 패턴(프리뷰) : 레코드 값을 분석하기 위해 개발됐다. 레코드 패턴이나 타입 패턴은 중첩 사용돼 선언적이면서 강력하고 조합 가능한 데이터 형태를 만들 수 있다. 데이터 탐색이나 처리 과정에도 쓰인다. 레코드 패턴의 핵심 목표는 타입 패턴의 신텍스나 시멘틱 요소를 바꾸지 않으면서도 패턴 매칭을 확장하고 정교하게 분리해서 사용할 수 있는 데이터 쿼리를 표현하는 것이다.  이 기능은 2021년 3월 자바16에서 지원됐던 instanceof 패턴 매칭...

자바 자바19 java 2022.06.03

“로그4j 그 이후를 말한다" 오픈소스 보안의 중요성 강조…베라코드 CTO

美 애플리케이션 보안 전문 기업 베라코드(Veracode)의 CTO가 로그4j 취약점의 여파, 오픈소스 보안 문제 인식을 높이는 방법 등을 조언했다. 지난 2021년 12월 초 수백만 개의 애플리케이션에서 사용되는 오픈소스 자바 구성요소 ‘로그4j’에서 일련의 취약점이 발견되면서 전 세계의 기업 보안 부서는 비상 경계 태세에 돌입해야 했다.    로그4j는 미국 사이버 보안 및 인프라 보안국(CISA; Cybersecurity and Infrastructure Security Agency)을 비롯해 다른 국가의 CERT(Computer Emergency Response Team)에서도 경고했을 만큼 큰 사건이었으며, 아울러 보안 및 오픈소스 소프트웨어 생태계, 개발자가 오픈소스 구성요소를 사용하고 추적하는 방법에 관한 새로운 논의를 촉발했다.  애플리케이션 보안 업체인 베라코드의 설립자 겸 CTO이자 애플리케이션 보안 및 취약점 분야에서 20년 이상의 경력을 갖춘 보안 업계 베테랑인 크리스 위소팔과 ‘로그4j 취약점의 여파와 오픈소스 보안의 미래’를 주제로 나눈 대화를 정리했다. ‘로그4j’의 중요성과 여파 “로그4j는 ‘광범위하게 사용돼 거의 모든 서버에 영향을 미칠 수 있다는 점에서’ 개발팀이 일상적으로 다루는 것과는 확실히 다른 유형의 취약점이었다. 거의 모든 기업에 영향을 미쳤고, 모든 기업의 여러 개발 부서, 즉 회사를 위해 새로운 일을 하는 부서와 1년에 한 번 정도 코드를 변경하는 유지관리 모드로 운영되던 부서를 강타했다.”  “베라코드는 SaaS 업체이기 때문에 모든 고객을 살펴볼 수 있다. 작년에 스캔한 수십만 개의 애플리케이션 중에서 특히 기업 고객을 관심 있게 살펴봤다. 95%의 기업 고객이 자바를 쓰고 있어 자바의 인기를 알 수 있다. 만약 자바에 이와 같은 취약점이 또 있다면 그 역시 널리 퍼질 것이다.” “아울러 88%는 로그4j를 사용하고, 58%는 취약한 버전을 쓴다고 답했다. 그래서...

오픈소스 로그4j 보안 취약점 2022.05.27

“자바 동시성, 더 쉬워진다” 새 오픈JDK 제안 

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘구조화된 동시성(JEP 428: Structured Concurrency)’은 서로 다른 자바 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리한다.  현재 오픈JDK 커뮤니티에서 인큐베이팅하고 있는 계획으로 멀티스레드 프로그래밍이 더 쉬워질 예정이다. ‘구조화된 동시성’ 제안은 서로 다른 스레드에서 실행되는 여러 작업을 단일 작업 단위로 처리하는 라이브러리를 도입한다. 해당 제안에 따르면 새 라이브러리는 오류 처리 및 취소를 간소화하고, 안정성을 개선하며, 관찰 가능성을 향상시킨다.    이 제안의 목표는 멀티스레드 코드의 안정성과 관찰 가능성을 개선하는 것, 그리고 취소 및 종료로 발생하는 일반적인 위험(예: 스레드 유출 및 취소 지연 등)을 제거할 수 있는 동시 프로그래밍 스타일을 촉진하는 것이다. 현시점에서 구조화된 동시성 제안은 특정 버전의 자바를 대상으로 하지는 않는다.  제안에 따르면, 구조화된 동시성은 단일 스레드 코드 개발자가 다뤄야 하는 가독성 및 유지관리를 위한 멀티스레드 프로그래밍 접근 방식이다. 이는 작업이 동시 하위 작업으로 분할되면 모두 같은 위치, 즉 작업의 코드 블록으로 돌아간다는 원칙을 따른다. 동일한 코드 블록으로 돌아가면 동시 하위 작업의 수명은 구문 블록으로 제한된다. 형제 하위 작업이 동일한 블록에 국한되기 때문에 하나의 단위로 추론하고 관리할 수 있다. 하위 작업은 결과를 기다리고 실패를 모니터링하는 작업(외부 블록의 코드)을 대신하여 작동한다.  단일 스레드 코드를 지원하는 구조화된 프로그래밍 기술과 마찬가지로 멀티스레드를 지원하는 구조화된 동시성은 2가지 아이디어에서 비롯된다. (1) 코드 블록을 통한 실행 흐름에서 잘 정의된 진입점 및 종료점 그리고 (2) 코드 중첩을 미러링하는 방식으로 작업 수명을 엄격하게 중첩하는 것이다. 또한 런타임에서 구조화된 동시성은 동일한 상위 작업이 가지고 ...

자바 오픈JDK JEP 2022.05.23

‘코틀린 1.7.0’ 베타 출시…“빌더 타입 추론 변경”

젯브레인(JetBrains)에서 만든 크로스 플랫폼 오픈소스 프로그래밍 언어의 최신 버전 ‘코틀린 1.7.0’이 베타 릴리즈 단계에 도달했다. 이번 업데이트는 빌더 타입 추론 변경사항과 새로운 메모리 관리자 등이 특징이다.   업체에 따르면 빌더 추론은 일반 빌더 함수를 호출할 때 유용한 타입 추론이다. 이는 컴파일러가 람다 인수 내 다른 호출의 타입 정보를 사용해 해당 호출의 타입 인수를 추론하는 데 도움이 된다. 1.7.0 베타에서는 -Xenable-builder-inference 컴파일러 옵션을 지정하지 않고 일반 타입 추론이 충분한 타입 정보를 얻을 수 없을 때 빌더 추론이 자동으로 활성화된다. 즉, 이제 개발자는 추가 주석이나 옵션을 적용하지 않고 빌더 타입 추론을 사용하는 빌더를 작성할 수 있다. 이번 변경사항으로 빌더 추론 안정화에 가까워졌다고 젯브레인은 밝혔다.  또 베타 릴리즈에는 새로운 코틀린/네이티브 메모리 관리자 알파 버전이 제공된다. 이 관리자는 JVM과 네이티브 플랫폼 간의 차이를 줄인다. 업체에 의하면 개발자는 안드로이드와 iOS 모두에서 작동하는 크로스 플랫폼 모바일 애플리케이션을 더 쉽게 구축할 수 있다. 아울러 스레드 간 객체 공유 제한이 풀리고, 특정한 관리나 주석이 필요하지 않은 ‘누수 없는(leak-free)’ 동시 프로그래밍 기본 요소를 지원한다. 새 메모리 관리자는 향후 버전에서 디폴트로 제공될 예정이다.  코틀린 1.7.0 베타 설치 지침은 이곳에서 확인할 수 있다. 이 밖에 베타의 다른 기능은 아래와 같다.    ‘확실히 nullable이 아닌(definitely non-nullable types)’ 타입이 안정화됐다. 이는 지난달 공개된 코틀린 1.6.20에서 도입됐으며, 현재 디폴트로 활성화된다. 일반 자바 클래스 및 인터페이스를 확장할 때 개발자에게 향상된 상호운용성을 지원하는 타입을 제공한다.  min()와 max() 콜렉션 함수가 원래 함수 ...

젯브레인 코틀린 프로그래밍 언어 2022.05.20

"틈새를 파고든다" 새로운 프로그래밍 언어 11선

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

개발자 소프트웨어 개발 프로그래밍 언어 2022.05.12

아파치 카프카에서 ‘주키퍼’ 빠진다…"내부 메타데이터 프로토콜로 대체"

분산 이벤트 스트리밍 플랫폼 ‘아파치 카프카(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가 지원된다. 운영자는 몇 가지 학습해야 할 것이 있을 수 있다. 새로운 관리자가 이를 더 쉽게 찾을 수 있고, 기존...

아파치 카프카 데이터 관리 소프트웨어 개발 2022.05.11

"오라클 시들, 아마존 상승세" 2022 자바 생태계 현황 보고서

뉴 렐릭(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%의 시장 점유율을 기록한 바 있다.   프로덕...

자바 오픈JDK 오라클 2022.05.02

'finalize 메소드 퇴역 이후' 자바 오류를 처리하고 클린업하는 방법

몇 년 간의 무성한 소문 끝에 마침내 자바가 JDK 18에서 finalize 메서드를 퇴역시킬 준비를 하고 있다. JDK 향상 제안(Enhancement Proposal) 421은 finalize를 사용 중단되는 요소로 명시하고, 테스트를 위해 이 메서드를 비활성화하는 것을 허용한다. 기본적으로는 계속 활성화된 상태로 유지되다가 이후 릴리스에서 완전히 제거된다. finalize의 끝이 무엇을 의미하는지, 이제부터는 오류와 리소스 클린업을 어떻게 처리해야 하는지 알아보자.     finalize란 무엇인가 finalize가 왜 사라지는지, 그 대신 무엇을 사용해야 하는지를 이해하기 전에 finalize가 무엇인지부터 살펴보자. finalize의 기본적인 개념은 객체가 가비지 수집 대상이 될 때 실행되는 메소드를 객체에 정의할 수 있도록 하는 것이다. 기술적으로 객체는 팬텀 도달 가능(phantom reachable) 상태가 될 때, 즉 JVM에 강하거나 약한 참조가 남아 있지 않을 때 가비지 수집 대상이 된다. 이 시점에서 JVM이 object.finalize() 메서드를 실행하고 애플리케이션별 코드가 I/O 스트림이나 데이터스토어에 대한 핸들과 같은 리소스를 클린업한다는 개념이다.  자바의 루트 Object 클래스에는 equals(), hashCode() 등 다른 메소드와 함께 finalize() 메소드가 있다. 이 메소드의 용도는 모든 자바 프로그램이 만든 모든 단일 객체가 리소스 누출을 방지하기 위한 이 단순한 메커니즘에 참여할 수 있도록 하는 것이다. 예외가 발생하고 다른 클린업 코드가 누락된 경우에도 해당된다. 즉, 객체는 여전히 가비지 수집 대상으로 표시되고 최종적으로는 해당 객체의 finalize 메소드가 호출된다. 문제가 해결된 것이다. 그렇지 않은가? 리소스를 소비하는 객체에서 finalize() 메소드를 오버라이드하기만 하면 된다.    finalize 메소드의 문제 거기까지는 개념이다...

finalize 자바 java 2022.02.08

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.