Offcanvas

개발자

고(Go) 1.19 출시 ··· “제네릭 코드 성능 최대 20% 향상”

구글이 ‘고(Go)’ 프로그래밍 언어의 최신 버전을 선보였다. 이번 업데이트는 최근 추가된 제네릭을 개선하고, 향상된 메모리 모델을 선보였다.  지난 8월 2일(현지 시각) ‘고 1.19’이 공개됐다. 개발팀에 따르면 제네릭 개발은 해당 커뮤니티에서 제기된 몇 가지 문제 그리고 성능 개선(일부 제네릭 프로그램에서 최대 20% 성능 향상)을 해결하는 데 초점을 맞췄다. 제네릭 기능들은 지난 3월 출시된 고 버전 1.18에서 도입됐다.    아울러 고 메모리 모델은 동기화/원자 패키지 동작을 명시적으로 정의한다. 동기화 알고리즘을 구축하기 위한 저수준 원자 메모리 기본 요소도 제공한다. 발생 이전(happens-before) 관계의 공식 정의는 C, C++, 자바, 자바스크립트, 러스트, 스위프트에서 사용되는 메모리 모델에 맞게 수정됐다. 기존 프로그램을 영향을 받지 않는다고 개발팀은 전했다.  메모리 모델 업데이트 외에도 atomic.int64 및 atomic.Pointer(T) 등 새로운 유형이 동기화/원자 패키지에 지원돼 원자 값을 더 쉽게 사용할 수 있다. 고 1.19는 이곳(go.dev)에서 다운로드할 수 있다. 고 1.19의 기타 개선사항 및 새로운 기능은 다음과 같다.  • 가비지 수집기에 소프트 메모리 제한이 추가됐다. 이 제한을 통해 고 프로그램을 최적화해 메모리 양이 할당된 컨테이너에서 가능한 한 효율적으로 실행되도록 할 수 있다. • 스택 카피라이팅을 줄이기 위한 코루틴 스택의 동적 크기 조정, 유닉스 시스템에서의 자동 추가 파일 설명자 사용, x86-64 및 Arm 64 상에서의 스위치 스테이트먼트용 점프 테이블, Arm64에서의 디버거 주입 함수 호출 지원이 지원된다.  • 메소드 선언의 형식 매개변수가 수정됐다. 기존 프로그램은 영향을 받지 않는다. • 이제 문서 주석에서 링크, 목록, 제목 구문을 지원한다. 특히 대규모 API를 갖춘 패키지에서 명확한 문서 주석을 작성할...

고 언어 고랭 구글 개발 언어 프로그래밍 언어 제네릭

6일 전

구글이 ‘고(Go)’ 프로그래밍 언어의 최신 버전을 선보였다. 이번 업데이트는 최근 추가된 제네릭을 개선하고, 향상된 메모리 모델을 선보였다.  지난 8월 2일(현지 시각) ‘고 1.19’이 공개됐다. 개발팀에 따르면 제네릭 개발은 해당 커뮤니티에서 제기된 몇 가지 문제 그리고 성능 개선(일부 제네릭 프로그램에서 최대 20% 성능 향상)을 해결하는 데 초점을 맞췄다. 제네릭 기능들은 지난 3월 출시된 고 버전 1.18에서 도입됐다.    아울러 고 메모리 모델은 동기화/원자 패키지 동작을 명시적으로 정의한다. 동기화 알고리즘을 구축하기 위한 저수준 원자 메모리 기본 요소도 제공한다. 발생 이전(happens-before) 관계의 공식 정의는 C, C++, 자바, 자바스크립트, 러스트, 스위프트에서 사용되는 메모리 모델에 맞게 수정됐다. 기존 프로그램을 영향을 받지 않는다고 개발팀은 전했다.  메모리 모델 업데이트 외에도 atomic.int64 및 atomic.Pointer(T) 등 새로운 유형이 동기화/원자 패키지에 지원돼 원자 값을 더 쉽게 사용할 수 있다. 고 1.19는 이곳(go.dev)에서 다운로드할 수 있다. 고 1.19의 기타 개선사항 및 새로운 기능은 다음과 같다.  • 가비지 수집기에 소프트 메모리 제한이 추가됐다. 이 제한을 통해 고 프로그램을 최적화해 메모리 양이 할당된 컨테이너에서 가능한 한 효율적으로 실행되도록 할 수 있다. • 스택 카피라이팅을 줄이기 위한 코루틴 스택의 동적 크기 조정, 유닉스 시스템에서의 자동 추가 파일 설명자 사용, x86-64 및 Arm 64 상에서의 스위치 스테이트먼트용 점프 테이블, Arm64에서의 디버거 주입 함수 호출 지원이 지원된다.  • 메소드 선언의 형식 매개변수가 수정됐다. 기존 프로그램은 영향을 받지 않는다. • 이제 문서 주석에서 링크, 목록, 제목 구문을 지원한다. 특히 대규모 API를 갖춘 패키지에서 명확한 문서 주석을 작성할...

6일 전

블로그 | 클라우드 네이티브의 진정한 의미

제조업에서 운송업, 소매업에 이르기까지 사실상 모든 업종에서 클라우드 기반 인프라로 전환하여 디지털 트랜스포메이션을 지원하고 있다. 사내 소프트웨어에서 클라우드 서비스로의 전환은 애플리케이션 개발 및 배포 프로세스, 특히, SaaS 애플리케이션으로 혁신적으로 변화했다. 하지만 클라우드를 자주 사용하는 것만으로는 충분하지 않다. 클라우드 네이티브 애플리케이션을 활용하여 향상된 민첩성, 가용성, 확장성 및 전체 성능을 활용할 수 있어야 한다. 클라우드 네이티브 아키텍처는 현대 소프트웨어 개발의 표준이 되었다. 그러나 그 인기와 함께 불확실성도 나타났다. 애플리케이션이 클라우드 네이티브라는 것이 정확히 어떤 의미일까? ‘클라우드 네이티브’에 대한 정의는 오늘날 운영되는 클라우드 네이티브 애플리케이션의 수만큼 다양하다. 그러나 클라우드 네이티브 애플리케이션을 구축하고자 할 때 유용한 몇 가지 표준적이고 이해하기 쉬운 원칙이 있다.     클라우드 네이티브의 의미 클라우드 네이티브 애플리케이션은 클라우드의 동적이면서 확장적이고 매우 가용적인 속성을 지도 원칙으로 하여 구축된 소프트웨어 시스템이다. 클라우드 네이티브 애플리케이션 아키텍처는 소프트웨어 개발자가 기존 접근 방식을 사용할 때 직면하는 과제에 대한 대응이다. 특히 클라우드 네이티브 애플리케이션은 다음과 같다.    클라우드의 역동적인 리소스 할당을 활용. 즉, 애플리케이션의 설치 공간은 현재 애플리케이션에 주어진 수요에 따라 크기가 달라지며, 소비된 리소스는 현재 시점에 필요한 리소스에 맞게 조정될 것이다. 서비스 또는 마이크로서비스 아키텍처 활용. 마이크로 서비스를 사용하면 애플리케이션 크기와 복잡성을 관리하기 쉬운 방법으로 쉽게 확장할 수 있다. 컨테이너화. 컨테이너를 사용하면 복잡한 종속성 관리에 대한 우려없이 서로 다른 환경에서 빠르고 쉽게 서비스를 배치할 수 있다. 쿠버네티스를 사용하여 서비스를 조율. 컨테이너 오케스트레이션 및 관리를 위한 사실상의 표...

6일 전

제조업에서 운송업, 소매업에 이르기까지 사실상 모든 업종에서 클라우드 기반 인프라로 전환하여 디지털 트랜스포메이션을 지원하고 있다. 사내 소프트웨어에서 클라우드 서비스로의 전환은 애플리케이션 개발 및 배포 프로세스, 특히, SaaS 애플리케이션으로 혁신적으로 변화했다. 하지만 클라우드를 자주 사용하는 것만으로는 충분하지 않다. 클라우드 네이티브 애플리케이션을 활용하여 향상된 민첩성, 가용성, 확장성 및 전체 성능을 활용할 수 있어야 한다. 클라우드 네이티브 아키텍처는 현대 소프트웨어 개발의 표준이 되었다. 그러나 그 인기와 함께 불확실성도 나타났다. 애플리케이션이 클라우드 네이티브라는 것이 정확히 어떤 의미일까? ‘클라우드 네이티브’에 대한 정의는 오늘날 운영되는 클라우드 네이티브 애플리케이션의 수만큼 다양하다. 그러나 클라우드 네이티브 애플리케이션을 구축하고자 할 때 유용한 몇 가지 표준적이고 이해하기 쉬운 원칙이 있다.     클라우드 네이티브의 의미 클라우드 네이티브 애플리케이션은 클라우드의 동적이면서 확장적이고 매우 가용적인 속성을 지도 원칙으로 하여 구축된 소프트웨어 시스템이다. 클라우드 네이티브 애플리케이션 아키텍처는 소프트웨어 개발자가 기존 접근 방식을 사용할 때 직면하는 과제에 대한 대응이다. 특히 클라우드 네이티브 애플리케이션은 다음과 같다.    클라우드의 역동적인 리소스 할당을 활용. 즉, 애플리케이션의 설치 공간은 현재 애플리케이션에 주어진 수요에 따라 크기가 달라지며, 소비된 리소스는 현재 시점에 필요한 리소스에 맞게 조정될 것이다. 서비스 또는 마이크로서비스 아키텍처 활용. 마이크로 서비스를 사용하면 애플리케이션 크기와 복잡성을 관리하기 쉬운 방법으로 쉽게 확장할 수 있다. 컨테이너화. 컨테이너를 사용하면 복잡한 종속성 관리에 대한 우려없이 서로 다른 환경에서 빠르고 쉽게 서비스를 배치할 수 있다. 쿠버네티스를 사용하여 서비스를 조율. 컨테이너 오케스트레이션 및 관리를 위한 사실상의 표...

6일 전

“쉽고 빠른 마이크로서비스 개발 지원” C++용 비동기 프레임워크 베타 출시

현재 베타 상태인 ‘유저버(Userver)’의 개발팀은 효율적인 I/O 인터랙션 문제를 투명하게 해결할 계획이라고 밝혔다.  C++ 개발자라면 효율적인 I/O 인터랙션 문제를 해결하는 새 오픈소스 프레임워크 ‘유저버’를 통해 비동기식 마이크로서비스를 쉽고 빠르게 구축할 수 있다.    해당 프로젝트의 깃허브 리포지토리에 따르면 유저버라고 하는 비동기 프레임워크는 C++ 마이크로서비스, 서비스, 유틸리티의 ‘빠르고 편안한’ 생성을 위하여 일련의 추상화를 제공한다. 현재 이 프로젝트는 베타 상태다.  이어 개발팀은 효율적인 I/O 트랜잭션 문제를 투명하게 해결할 계획이라고 말했다. 아울러 C++의 속도, 파이썬의 단순함, 고랭의 코루틴(Coroutine) 모델도 제공한다고 덧붙였다.  유저버를 사용하면 일반적으로 실행 스레드를 일시 중단하는 작업이 수행되지 않는다. 대신, 스레드는 다른 작업을 처리하고 즉시 실행이 보장될 때만 작업 처리로 돌아간다. 개발자는 간단한 소스 코드를 얻고 OS에서 CPU를 많이 소비하는 컨텍스트 전환을 피하면서 적은 수의 실행 스레드를 통해 CPU를 효율적으로 활용할 수 있다고 개발팀은 설명했다. 유저버 프레임워크의 다른 기능은 아래와 같다.  • 캐시, 분산 잠금, JSON/YAML/BSON, 로깅, 메트릭, 통계, 작업에 관한 고급 구성요소 집합  • 즉각적인 서비스 구성 변경을 수행하는 기능  • 포괄적인 비동기와 저수준 동기화 기본 요소 및 OS 추상화 집합  • 몽고DB, 포스트그레, 레디스 및 기타 데이터베이스용 비동기 드라이버 • HTTP, GRPC 및 TCP를 포함한 데이터 전송 프로토콜 그리고 구성 및 취소를 포함한 작업용 비동기 드라이버 지난 7월 29일(현지 시각) 개발팀은 유저버의 베타 버전을 발표하면서, (이를 사용하면) 인턴과 학생도 일주일 만에 새 마이크로서비스를 작성하고 프로덕션에 배포할 수 있다며 유저버 개...

C++ 비동기 프레임워크 유저버 마이크로서비스

7일 전

현재 베타 상태인 ‘유저버(Userver)’의 개발팀은 효율적인 I/O 인터랙션 문제를 투명하게 해결할 계획이라고 밝혔다.  C++ 개발자라면 효율적인 I/O 인터랙션 문제를 해결하는 새 오픈소스 프레임워크 ‘유저버’를 통해 비동기식 마이크로서비스를 쉽고 빠르게 구축할 수 있다.    해당 프로젝트의 깃허브 리포지토리에 따르면 유저버라고 하는 비동기 프레임워크는 C++ 마이크로서비스, 서비스, 유틸리티의 ‘빠르고 편안한’ 생성을 위하여 일련의 추상화를 제공한다. 현재 이 프로젝트는 베타 상태다.  이어 개발팀은 효율적인 I/O 트랜잭션 문제를 투명하게 해결할 계획이라고 말했다. 아울러 C++의 속도, 파이썬의 단순함, 고랭의 코루틴(Coroutine) 모델도 제공한다고 덧붙였다.  유저버를 사용하면 일반적으로 실행 스레드를 일시 중단하는 작업이 수행되지 않는다. 대신, 스레드는 다른 작업을 처리하고 즉시 실행이 보장될 때만 작업 처리로 돌아간다. 개발자는 간단한 소스 코드를 얻고 OS에서 CPU를 많이 소비하는 컨텍스트 전환을 피하면서 적은 수의 실행 스레드를 통해 CPU를 효율적으로 활용할 수 있다고 개발팀은 설명했다. 유저버 프레임워크의 다른 기능은 아래와 같다.  • 캐시, 분산 잠금, JSON/YAML/BSON, 로깅, 메트릭, 통계, 작업에 관한 고급 구성요소 집합  • 즉각적인 서비스 구성 변경을 수행하는 기능  • 포괄적인 비동기와 저수준 동기화 기본 요소 및 OS 추상화 집합  • 몽고DB, 포스트그레, 레디스 및 기타 데이터베이스용 비동기 드라이버 • HTTP, GRPC 및 TCP를 포함한 데이터 전송 프로토콜 그리고 구성 및 취소를 포함한 작업용 비동기 드라이버 지난 7월 29일(현지 시각) 개발팀은 유저버의 베타 버전을 발표하면서, (이를 사용하면) 인턴과 학생도 일주일 만에 새 마이크로서비스를 작성하고 프로덕션에 배포할 수 있다며 유저버 개...

7일 전

칼럼 | 로우 코드 플랫폼이 갖추어야 할 조건

개발자 구인난은 좀처럼 해 될 기미가 보이지 않고 있다. 오히려 시간이 갈수록 점점 더 심해지는 상황처럼 느껴 지기도 한다. 이러한 영향으로 공공 또는 민간 부문이 SI 프로젝트 발주가 개발자 구인 이슈로 지연되거나 심지어 보류되는 경우도 발생하고 있다.  하지만 일정 수준 이상의 생산성을 가진 개발자를 확보할 묘수는 없다. 그래서 대안으로 제안되고 있는 방법이 개발자에게 요구되는 스킬을 최소화할 수 있는 손쉬운 프로그램 개발환경의 적용을 통한 시스템 개발, 즉 로우 코드(low-code) 개발 플랫폼을 도입하는 것이다. 그런데 이러한 오늘날의 상황이 낯설지는 않다. 1990년대 초반 IT 업계는 새로운 시스템 패러다임으로 들썩였다. 기존의 중앙 집중 방식의 시스템인 메인프레임 기반의 정보시스템에서 새롭게 등장한 개인용 컴퓨터(PC)와 마이크로소프트 윈도우를 활용한 클라이언트-서버(client-server) 아키텍처로의 전환을 시작한 것이다. 단순한 텍스트 기반의 화면에서 다양한 윈도우의 위젯과 툴을 사용한 GUI화면은 사용자들에게 많은 호응을 얻었으며 클라이언트-서버 기반의 차세대 시스템 구축 프로젝트 봇물 터지듯 시작됐다. 당시 기업의 프로그래머는 단말기에서 코볼(COBOL) 언어나 또는 유사한 언어를 이용하여 프로그램을 작성하는 경우가 대부분이었다. 그런데 클라이언트-서버 환경에서는 윈도우라는 그래픽 운영체제 환경하에서 SDK(software development kit)라는 라이브러리를 이용하여 C언어를 사용하여야 했으며 서버와의 통신을 위해 SQL*Net과 같은 데이터베이스 연결 드라이버를 활용해야 했다. 이는 전혀 새로운 환경에서의 개발을 의미했다. 윈도우의 멀티태스킹 로직으로 인해 시스템 개발 난이도는 메인 프레임에서의 단순한 비즈니스 로직 개발과는 차원이 달랐다. 따라서 시장에서 필요한 능력을 갖춘 개발자의 공급이 매우 부족한 상황에 처하게 된다. 이때 등장한 개념이 4세대 프로그래밍 언어(4th generation program...

로우코드 로우 코드 정철환 개발자 구인난 록인 종속 파워빌더

2022.08.01

개발자 구인난은 좀처럼 해 될 기미가 보이지 않고 있다. 오히려 시간이 갈수록 점점 더 심해지는 상황처럼 느껴 지기도 한다. 이러한 영향으로 공공 또는 민간 부문이 SI 프로젝트 발주가 개발자 구인 이슈로 지연되거나 심지어 보류되는 경우도 발생하고 있다.  하지만 일정 수준 이상의 생산성을 가진 개발자를 확보할 묘수는 없다. 그래서 대안으로 제안되고 있는 방법이 개발자에게 요구되는 스킬을 최소화할 수 있는 손쉬운 프로그램 개발환경의 적용을 통한 시스템 개발, 즉 로우 코드(low-code) 개발 플랫폼을 도입하는 것이다. 그런데 이러한 오늘날의 상황이 낯설지는 않다. 1990년대 초반 IT 업계는 새로운 시스템 패러다임으로 들썩였다. 기존의 중앙 집중 방식의 시스템인 메인프레임 기반의 정보시스템에서 새롭게 등장한 개인용 컴퓨터(PC)와 마이크로소프트 윈도우를 활용한 클라이언트-서버(client-server) 아키텍처로의 전환을 시작한 것이다. 단순한 텍스트 기반의 화면에서 다양한 윈도우의 위젯과 툴을 사용한 GUI화면은 사용자들에게 많은 호응을 얻었으며 클라이언트-서버 기반의 차세대 시스템 구축 프로젝트 봇물 터지듯 시작됐다. 당시 기업의 프로그래머는 단말기에서 코볼(COBOL) 언어나 또는 유사한 언어를 이용하여 프로그램을 작성하는 경우가 대부분이었다. 그런데 클라이언트-서버 환경에서는 윈도우라는 그래픽 운영체제 환경하에서 SDK(software development kit)라는 라이브러리를 이용하여 C언어를 사용하여야 했으며 서버와의 통신을 위해 SQL*Net과 같은 데이터베이스 연결 드라이버를 활용해야 했다. 이는 전혀 새로운 환경에서의 개발을 의미했다. 윈도우의 멀티태스킹 로직으로 인해 시스템 개발 난이도는 메인 프레임에서의 단순한 비즈니스 로직 개발과는 차원이 달랐다. 따라서 시장에서 필요한 능력을 갖춘 개발자의 공급이 매우 부족한 상황에 처하게 된다. 이때 등장한 개념이 4세대 프로그래밍 언어(4th generation program...

2022.08.01

멋쟁이사자처럼, iOS 앱 개발자 양성하는 ‘앱 스쿨 1기’ 오픈

글로벌 프로그래밍 교육 브랜드 ‘멋쟁이사자처럼(likelion)’은 2022년 9월 앱 스쿨 1기를 시작한다고 밝혔다.    앱 스쿨 1기(https://projectlion.io/)는 iOS 앱 개발자 양성 부트 캠프로, Swift를 주로 다루며 iOS 앱 개발의 기초부터 실습까지 탄탄한 커리큘럼으로 구성됐다. 모집은 7월 29일부터 8월 23일까지이며 지원 링크를 통해 지원할 수 있다. 앱 스쿨 1기의 커리큘럼은 주기적으로 프로젝트를 구현하며, 점진적으로 프로덕트 구축 역량을 키워가는 이론과 실습의 순환 시스템을 갖추고 있다. 기본 이론, 생활형 앱 서비스 제작, 심화 이론, 서비스형 앱 서비스를 순서로 후에는 해커톤과 최종 프로젝트로 마무리한다.  멋쟁이사자처럼의 앱 스쿨 1기는 국민내일배움카드를 통해 배울 수 있는 전액 국비지원 프로그램이다. iOS 앱 개발 경력 14년의 CTO가 강의를 맡았으며 총 개발 경력 20년의 현직자이기 때문에 앱(iOS) 개발에 대한 기본기를 탄탄히 다지고, 실무적인 기술을 습득할 수 있을 것으로 예상된다. 그리고 주기적인 스프린트 회고를 통해 개발자들의 문화를 미리 경험하며 테크니컬 스킬에서의 성장 뿐만 아니라 소프트 스킬 면에서도 실력이 쌓이는 주니어 개발자가 될 것이라고 업체 측은 기대하고 있다. 멋쟁이사자처럼 마케팅 담당자는 “앞으로도 시장에 맞는 개발자 양성을 위한 클래스를 만들 수 있도록 노력해 나가겠다”고 밝혔다. ciokr@idg.co.kr

멋쟁이사자처럼 iOS

2022.08.01

글로벌 프로그래밍 교육 브랜드 ‘멋쟁이사자처럼(likelion)’은 2022년 9월 앱 스쿨 1기를 시작한다고 밝혔다.    앱 스쿨 1기(https://projectlion.io/)는 iOS 앱 개발자 양성 부트 캠프로, Swift를 주로 다루며 iOS 앱 개발의 기초부터 실습까지 탄탄한 커리큘럼으로 구성됐다. 모집은 7월 29일부터 8월 23일까지이며 지원 링크를 통해 지원할 수 있다. 앱 스쿨 1기의 커리큘럼은 주기적으로 프로젝트를 구현하며, 점진적으로 프로덕트 구축 역량을 키워가는 이론과 실습의 순환 시스템을 갖추고 있다. 기본 이론, 생활형 앱 서비스 제작, 심화 이론, 서비스형 앱 서비스를 순서로 후에는 해커톤과 최종 프로젝트로 마무리한다.  멋쟁이사자처럼의 앱 스쿨 1기는 국민내일배움카드를 통해 배울 수 있는 전액 국비지원 프로그램이다. iOS 앱 개발 경력 14년의 CTO가 강의를 맡았으며 총 개발 경력 20년의 현직자이기 때문에 앱(iOS) 개발에 대한 기본기를 탄탄히 다지고, 실무적인 기술을 습득할 수 있을 것으로 예상된다. 그리고 주기적인 스프린트 회고를 통해 개발자들의 문화를 미리 경험하며 테크니컬 스킬에서의 성장 뿐만 아니라 소프트 스킬 면에서도 실력이 쌓이는 주니어 개발자가 될 것이라고 업체 측은 기대하고 있다. 멋쟁이사자처럼 마케팅 담당자는 “앞으로도 시장에 맞는 개발자 양성을 위한 클래스를 만들 수 있도록 노력해 나가겠다”고 밝혔다. ciokr@idg.co.kr

2022.08.01

'클라우드 쓸지라도' DB 설계가 여전히 개발자에 중요한 이유

오늘날 소프트웨어 개발자에게는 많은 선택지가 존재한다. 다양한 툴과 서비스를 활용해 새로운 애플리케이션을 빠르게 만들어 전 세계 고객에게 서비스를 출시하고 이후 확장해서 늘어난 수요에 대응할 수 있다. 마이크로서비스 아키텍처와 애자일 개발은 고객 요구와 비즈니스 요구를 충족해야 할 때 기민하게 움직이면서 새로운 서비스를 가동할 수 있도록 한다.   데이터도 마찬가지다. 개발자는 자신의 애플리케이션에서 생성하는 데이터를 지원해야 하는데, 이는 곧 데이터베이스 구현을 의미한다. 데이터베이스 설계를 적절히 선택하느냐가 애플리케이션에서 큰 차이로 이어질 수 있다. 적절한 설계는 장기적으로 애플리케이션이 가용성과 성능, 확장성을 갖추도록 하는 데 도움이 된다. 그러나 개발자는 데이터베이스를 직접 구현하고 관리하기를 원하지는 않는다. 대다수 기업이 (IDC에 따르면 90%) 현재 데이터베이스와 데이터 워크로드를 클라우드로 옮기는 것도 이 때문이다. 이때 기업은 여러 옵션 중에서 선택할 수 있다. 관리형 서비스, 클라우드 기반 데이터베이스 설치, 서비스형 데이터베이스(DBaaS) 등이 포함된다. 이들 서비스를 제공하는 업체들은 하나 같이 데이터 관리 부담을 덜어주고 새로운 애플리케이션과 업데이트를 더 빠르게 제공해 개발자가 원하는 것을 누릴 수 있다고 주장한다. “스키마리스”, “완전 관리형”과 같은 홍보 문구를 보면 데이터베이스를 그냥 넘겨주면 될 것처럼 안일함에 빠질 정도다. 그러나 클라우드 기반 데이터베이스의 설계와 구현 방법의 선택 측면에서도 개발자의 책임은 전통적인 온프레미스 시스템에 대한 것과 다르지 않다. DBaaS 제품의 기본 설정이 자신의 애플리케이션에 맞을 것이라고 무작정 단정하지 말아야 할 책임도 포함된다.   적절한 데이터베이스 선택하기 따라서 개발자와 애플리케이션 설계자는 애플리케이션 프로젝트의 장기적인 미래를 내다보고 이러한 프로젝트가 갖게 될 기본적인 요구사항을 확실히 파악해야 한다. 가장 먼저 판단해야 할 것은 프로젝...

데이터베이스

2022.08.01

오늘날 소프트웨어 개발자에게는 많은 선택지가 존재한다. 다양한 툴과 서비스를 활용해 새로운 애플리케이션을 빠르게 만들어 전 세계 고객에게 서비스를 출시하고 이후 확장해서 늘어난 수요에 대응할 수 있다. 마이크로서비스 아키텍처와 애자일 개발은 고객 요구와 비즈니스 요구를 충족해야 할 때 기민하게 움직이면서 새로운 서비스를 가동할 수 있도록 한다.   데이터도 마찬가지다. 개발자는 자신의 애플리케이션에서 생성하는 데이터를 지원해야 하는데, 이는 곧 데이터베이스 구현을 의미한다. 데이터베이스 설계를 적절히 선택하느냐가 애플리케이션에서 큰 차이로 이어질 수 있다. 적절한 설계는 장기적으로 애플리케이션이 가용성과 성능, 확장성을 갖추도록 하는 데 도움이 된다. 그러나 개발자는 데이터베이스를 직접 구현하고 관리하기를 원하지는 않는다. 대다수 기업이 (IDC에 따르면 90%) 현재 데이터베이스와 데이터 워크로드를 클라우드로 옮기는 것도 이 때문이다. 이때 기업은 여러 옵션 중에서 선택할 수 있다. 관리형 서비스, 클라우드 기반 데이터베이스 설치, 서비스형 데이터베이스(DBaaS) 등이 포함된다. 이들 서비스를 제공하는 업체들은 하나 같이 데이터 관리 부담을 덜어주고 새로운 애플리케이션과 업데이트를 더 빠르게 제공해 개발자가 원하는 것을 누릴 수 있다고 주장한다. “스키마리스”, “완전 관리형”과 같은 홍보 문구를 보면 데이터베이스를 그냥 넘겨주면 될 것처럼 안일함에 빠질 정도다. 그러나 클라우드 기반 데이터베이스의 설계와 구현 방법의 선택 측면에서도 개발자의 책임은 전통적인 온프레미스 시스템에 대한 것과 다르지 않다. DBaaS 제품의 기본 설정이 자신의 애플리케이션에 맞을 것이라고 무작정 단정하지 말아야 할 책임도 포함된다.   적절한 데이터베이스 선택하기 따라서 개발자와 애플리케이션 설계자는 애플리케이션 프로젝트의 장기적인 미래를 내다보고 이러한 프로젝트가 갖게 될 기본적인 요구사항을 확실히 파악해야 한다. 가장 먼저 판단해야 할 것은 프로젝...

2022.08.01

블로그 | SW 개발과 관리, '관찰 가능성 도구'를 눈여겨볼 이유

혹시 레거시 소프트웨어를 떠올리면 메인프레임 같은 구식 기기에서 쓰이는 구닥다리 코드가 생각나는가? 다시 생각해보라. 몇 달 전에 쓴 코드도 개발자의 발목을 잡는 레거시 코드가 될 수 있다. 결국 코드의 관찰 가능성을 높이고 상세한 설명서를 남겨야 진짜 좋은 코드를 유지할 수 있다.    만약 레거시 소프트웨어가 자신과 무관한 다른 세계의 이야기라고 생각한다면, 다시 생각해보라. 아키타 소프트웨어(Akita Software) 창립자 겸 CEO 진 양은 “모든 코드는 쓰이는(ship의 뉘앙스와 크게 달라요) 순간 레거시 코드가 된다. 새로 짜는 모든 코드는 관리해야 하는 짐이 되며, 이는 불가피하다. 나도 지난주에 어떤 코드를 작성했는지 기억 못 한다. 대다수 개발자가 그럴 것이다”라고 말했다.  보통 어떤 소프트웨어를 레거시라고 부르려면 코볼(COBOL) 정도로 오래된 언어로 작성하거나, 메인프레임에서 구동되는 애플리케이션쯤 돼야 한다고 생각한다.  하지만 바로 이런 사고방식이 개발자가 코드를 근시안적으로 개발하는 원인이 된다. 나중에 그 코드를 이해해야 할 사람을 고려하지 않는 것이다. 양이 지적한 것처럼 개발자 스스로도 코드를 다시 이해해야 하는 상황이 올 수 있다.  그럼 어떻게 해야 레거시 코드를 잘 관리할 수 있을까?  코드가 네트워크를 만나면  코드의 까다로운 특성 중 하나는 바로 역동성이다. 코드는 절대 불변의 상태로 남지 않는다. 허니콤(Honeycomb) 창립자 겸 CTO 차리티 메이저스(Charity Majors)는 양과의 인터뷰에서 “코드가 네트워크에 들어서는 순간 신비의 세계에(mystery land)에 들어간다. 개발자의 통제권을 벗어나게 되는 것이다”라고 말했다.  이런 비유를 해볼 수도 있다. 개발자가 처음 개발한 애플리케이션은 마치 원시 상태의 에덴 동산에 있는 것과 같다. 그러나 유용한 애플리케이션 대부분은 대게 인터넷에 연결되는 데,...

레거시 시스템 레거시 소프트웨어 관찰가능성 디버깅

2022.07.29

혹시 레거시 소프트웨어를 떠올리면 메인프레임 같은 구식 기기에서 쓰이는 구닥다리 코드가 생각나는가? 다시 생각해보라. 몇 달 전에 쓴 코드도 개발자의 발목을 잡는 레거시 코드가 될 수 있다. 결국 코드의 관찰 가능성을 높이고 상세한 설명서를 남겨야 진짜 좋은 코드를 유지할 수 있다.    만약 레거시 소프트웨어가 자신과 무관한 다른 세계의 이야기라고 생각한다면, 다시 생각해보라. 아키타 소프트웨어(Akita Software) 창립자 겸 CEO 진 양은 “모든 코드는 쓰이는(ship의 뉘앙스와 크게 달라요) 순간 레거시 코드가 된다. 새로 짜는 모든 코드는 관리해야 하는 짐이 되며, 이는 불가피하다. 나도 지난주에 어떤 코드를 작성했는지 기억 못 한다. 대다수 개발자가 그럴 것이다”라고 말했다.  보통 어떤 소프트웨어를 레거시라고 부르려면 코볼(COBOL) 정도로 오래된 언어로 작성하거나, 메인프레임에서 구동되는 애플리케이션쯤 돼야 한다고 생각한다.  하지만 바로 이런 사고방식이 개발자가 코드를 근시안적으로 개발하는 원인이 된다. 나중에 그 코드를 이해해야 할 사람을 고려하지 않는 것이다. 양이 지적한 것처럼 개발자 스스로도 코드를 다시 이해해야 하는 상황이 올 수 있다.  그럼 어떻게 해야 레거시 코드를 잘 관리할 수 있을까?  코드가 네트워크를 만나면  코드의 까다로운 특성 중 하나는 바로 역동성이다. 코드는 절대 불변의 상태로 남지 않는다. 허니콤(Honeycomb) 창립자 겸 CTO 차리티 메이저스(Charity Majors)는 양과의 인터뷰에서 “코드가 네트워크에 들어서는 순간 신비의 세계에(mystery land)에 들어간다. 개발자의 통제권을 벗어나게 되는 것이다”라고 말했다.  이런 비유를 해볼 수도 있다. 개발자가 처음 개발한 애플리케이션은 마치 원시 상태의 에덴 동산에 있는 것과 같다. 그러나 유용한 애플리케이션 대부분은 대게 인터넷에 연결되는 데,...

2022.07.29

“C++의 후계자가 목표”··· 구글, ‘카본’ 공개

‘C++’을 대체하기 위해 개발 중인 오픈소스 프로그래밍 언어 ‘카본(Carbon)’은 C++과 동일한 수준의 성능 그리고 호환성을 지원하는 한편, 기술적 부채와 고질적인 문제를 해결할 계획이다.  전 세계에서 가장 많이 쓰이는 프로그래밍 언어 중 하나인 ‘C++’의 후계자가 필요한 시점이라고 생각하는가? 구글의 개발자 그룹은 그렇다고 보고 있다.     해당 그룹은 C++과의 상호 운용성을 제공하는 동시에, 이 레거시 언어를 개선하는 데 있어 알려진 문제를 해결하는 실험적 프로그래밍 언어 ‘카본’을 개발하고 있다. 개발팀에 따르면 카본은 C 또는 C++이 수십 년간 쌓아온 기술적 부채를 상속하지 않으면서 최신 제네릭 시스템, 간단한 구문, 모듈식 코드 구성 등의 기반으로 시작하여 앞서 언급한 장애물을 극복하려고 시도 중이다.  현재 카본은 사용 가능한 상태는 아니다. 카본 개발팀은 C++이 퍼포먼스 크리티컬 소프트웨어 구축에 지배적인 프로그래밍 언어이며, 방대한 코드 기반이 있다고 말했다. 이에 카본은 ‘진화’보다는 ‘후속 접근 방식’을 제시하며, 기존 C++ 코드 기반 및 C++ 개발자를 위한 마이그레이션을 지원할 것이라고 전했다.  카본은 지난주 캐나다 토론토에서 열린 개발자 컨퍼런스 ‘C++노스(CPP North)’에서 공개됐다. 카본의 리소스는 해당 프로젝트의 깃허브 리포지토리에서 액세스할 수 있다. 개발팀은 C++ 후계자로써의 요건을 다음과 같이 언급하면서, 카본의 접근 방식이 C++ 생태계 위에 구축될 수 있다고 밝혔다.  • C++과 동일한 수준의 성능  • C++과의 원활한 상호 운용성 • 완만한 학습 곡선 • 비슷한 표현식 • 확장 가능한 마이그레이션  카본은 타입스크립트가 자바스크립트, 코틀린이 자바와 비슷한 것처럼 C++과 유사하게 설계됐다. 개발팀은 카본이 퍼포먼스 크리티컬 소프트웨어, 소프트웨어 및 언어 발전을 지원하고, 안전하며 읽기 및 쓰기가 쉬운 ...

C++ 카본 구글 프로그래밍 언어 개발 언어 오픈소스

2022.07.29

‘C++’을 대체하기 위해 개발 중인 오픈소스 프로그래밍 언어 ‘카본(Carbon)’은 C++과 동일한 수준의 성능 그리고 호환성을 지원하는 한편, 기술적 부채와 고질적인 문제를 해결할 계획이다.  전 세계에서 가장 많이 쓰이는 프로그래밍 언어 중 하나인 ‘C++’의 후계자가 필요한 시점이라고 생각하는가? 구글의 개발자 그룹은 그렇다고 보고 있다.     해당 그룹은 C++과의 상호 운용성을 제공하는 동시에, 이 레거시 언어를 개선하는 데 있어 알려진 문제를 해결하는 실험적 프로그래밍 언어 ‘카본’을 개발하고 있다. 개발팀에 따르면 카본은 C 또는 C++이 수십 년간 쌓아온 기술적 부채를 상속하지 않으면서 최신 제네릭 시스템, 간단한 구문, 모듈식 코드 구성 등의 기반으로 시작하여 앞서 언급한 장애물을 극복하려고 시도 중이다.  현재 카본은 사용 가능한 상태는 아니다. 카본 개발팀은 C++이 퍼포먼스 크리티컬 소프트웨어 구축에 지배적인 프로그래밍 언어이며, 방대한 코드 기반이 있다고 말했다. 이에 카본은 ‘진화’보다는 ‘후속 접근 방식’을 제시하며, 기존 C++ 코드 기반 및 C++ 개발자를 위한 마이그레이션을 지원할 것이라고 전했다.  카본은 지난주 캐나다 토론토에서 열린 개발자 컨퍼런스 ‘C++노스(CPP North)’에서 공개됐다. 카본의 리소스는 해당 프로젝트의 깃허브 리포지토리에서 액세스할 수 있다. 개발팀은 C++ 후계자로써의 요건을 다음과 같이 언급하면서, 카본의 접근 방식이 C++ 생태계 위에 구축될 수 있다고 밝혔다.  • C++과 동일한 수준의 성능  • C++과의 원활한 상호 운용성 • 완만한 학습 곡선 • 비슷한 표현식 • 확장 가능한 마이그레이션  카본은 타입스크립트가 자바스크립트, 코틀린이 자바와 비슷한 것처럼 C++과 유사하게 설계됐다. 개발팀은 카본이 퍼포먼스 크리티컬 소프트웨어, 소프트웨어 및 언어 발전을 지원하고, 안전하며 읽기 및 쓰기가 쉬운 ...

2022.07.29

R스튜디오, 포싯(Posit)으로 사명 바꾼다

R스튜디오가 회사 이름을 ‘포싯(Posit)’으로 변경한다. 27일(현지 시각) 美 워싱턴 D.C.에서 열린 연례 사용자 컨퍼런스에서 이 회사는 R을 넘어 파이썬 및 비주얼 스튜디오 코드 사용자까지 포함하기 위해 사명을 바꾼다고 발표했다.  이 회사는 지난 몇 년 동안 자사의 상용 제품이 R과 파이썬 모두를 지원하는 ‘이중 언어’라고 강조해 왔다. 하지만 ‘R스튜디오’라는 브랜드로 인해 파이썬 사용자가 자사 제품을 고려하도록 설득하는 게 어려웠다는 설명이다. R스튜디오의 수석 과학자 해들리 위컴은 “그 이름이 제한적이라고 느꼈다”라고 말했다.    R스튜디오 설립자 겸 CEO J.J. 알레르는 “하지만 이름 변경이 소셜 미디어 등에서 주장하는 것처럼 R에서 벗어나거나, 파이썬이 데이터 과학에서 R을 대체하고 있다는 믿음을 의미하진 않는다”라고 언급했다. 위컴은 “R에서 파이썬으로 전환하는 게 아니다”라면서, “R 코드 작성을 멈추지 않을 것”이라고 전했다.  알레르는 그 대신 관련 상용 제품의 수익을 통해 오픈소스 소프트웨어에 안정적으로 자금을 조달할 수 있는 모델을 찾았다고 밝혔다. 그는 “데이터 과학 관행에 폭넓게 영향을 미칠 기회가 있다고 생각한다”라고 덧붙였다.  알레르에 따르면 내부 엔지니어의 약 40%가 풀타임으로 오픈소스 소프트웨어에 전념하고 있다. 오픈소스 개발 작업에 참여하지만 풀타임으론 일하지 않는 직원들을 제외하면 총 43명이다. 2020년 R스튜디오는 공익법인으로 개편했다고 발표했다. 이를 통해 의사결정을 내릴 때 주주 가치 극대화에 초점을 맞추는 대신, 광범위한 사용자 커뮤니티의 요구를 고려할 수 있게 됐다.  현재 내부 엔지니어의 90%가 R을 다루고 있지만 알레르는 약 3년 후에는 (그 비율이) 약 75% 수준일 것이라고 추정했다. 하지만 단기적으로는 R과 관련한 개발 작업의 대부분을 유지할 예정이다. 단, 더 이상 첫 번째 제품인 ‘R스튜디오 IDE’라는 이름으로 알려...

R스튜디오 포싯 데이터 과학 R 파이썬 VS 코드 통합개발환경 IDE

2022.07.28

R스튜디오가 회사 이름을 ‘포싯(Posit)’으로 변경한다. 27일(현지 시각) 美 워싱턴 D.C.에서 열린 연례 사용자 컨퍼런스에서 이 회사는 R을 넘어 파이썬 및 비주얼 스튜디오 코드 사용자까지 포함하기 위해 사명을 바꾼다고 발표했다.  이 회사는 지난 몇 년 동안 자사의 상용 제품이 R과 파이썬 모두를 지원하는 ‘이중 언어’라고 강조해 왔다. 하지만 ‘R스튜디오’라는 브랜드로 인해 파이썬 사용자가 자사 제품을 고려하도록 설득하는 게 어려웠다는 설명이다. R스튜디오의 수석 과학자 해들리 위컴은 “그 이름이 제한적이라고 느꼈다”라고 말했다.    R스튜디오 설립자 겸 CEO J.J. 알레르는 “하지만 이름 변경이 소셜 미디어 등에서 주장하는 것처럼 R에서 벗어나거나, 파이썬이 데이터 과학에서 R을 대체하고 있다는 믿음을 의미하진 않는다”라고 언급했다. 위컴은 “R에서 파이썬으로 전환하는 게 아니다”라면서, “R 코드 작성을 멈추지 않을 것”이라고 전했다.  알레르는 그 대신 관련 상용 제품의 수익을 통해 오픈소스 소프트웨어에 안정적으로 자금을 조달할 수 있는 모델을 찾았다고 밝혔다. 그는 “데이터 과학 관행에 폭넓게 영향을 미칠 기회가 있다고 생각한다”라고 덧붙였다.  알레르에 따르면 내부 엔지니어의 약 40%가 풀타임으로 오픈소스 소프트웨어에 전념하고 있다. 오픈소스 개발 작업에 참여하지만 풀타임으론 일하지 않는 직원들을 제외하면 총 43명이다. 2020년 R스튜디오는 공익법인으로 개편했다고 발표했다. 이를 통해 의사결정을 내릴 때 주주 가치 극대화에 초점을 맞추는 대신, 광범위한 사용자 커뮤니티의 요구를 고려할 수 있게 됐다.  현재 내부 엔지니어의 90%가 R을 다루고 있지만 알레르는 약 3년 후에는 (그 비율이) 약 75% 수준일 것이라고 추정했다. 하지만 단기적으로는 R과 관련한 개발 작업의 대부분을 유지할 예정이다. 단, 더 이상 첫 번째 제품인 ‘R스튜디오 IDE’라는 이름으로 알려...

2022.07.28

11년 된 ‘자바 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.27

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

2022.07.27

끈질긴 생명력... '자바'가 여전히 위대한 이유 7가지

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

자바 언어 개발자 프로그래밍 객체지향

2022.07.22

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

2022.07.22

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

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

자바 역사 읽을꺼리 썬 마이크로시스템즈 브랜딩 브랜드

2022.07.19

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

2022.07.19

“개발자들, 코파일럿 많이 쓸수록 생산성 향상됐다 느껴” 깃허브

깃허브(GitHub)의 연구 결과에 따르면 ‘깃허브 코파일럿(GitHub Copilot)’이 제안한 코드를 더 많이 수락하는 개발자가 적어도 더 생산적이라고 느끼는 것으로 나타났다(이에 따른 실제 개발자 생산성은 측정되지 않았다).    깃허브는 이 회사의 AI 기반 코딩 비서 깃퍼브 코파일럿을 사용해 ‘생산성이 크게 향상됐다’고 답한 개발자일수록 코파일럿의 코드 제안을 더 많이 수락하는 것으로 조사됐다고 밝혔다. 해당 보고서는 사용자의 지각된 생산성 설문조사와 코파일럿 사용 분석 결과를 담았다.  지난 7월 14일(현지 시각) 깃허브가 수십억 줄의 오픈소스 코드를 학습한 AI 모델을 기반으로 코드를 제안하는 깃허브 코파일럿 사용자 2,000명 이상을 대상으로 한 설문조사 결과를 공개했다. ‘큰(huge)’ 생산성 향상이 있었다고 답한 코파일럿 사용자는 이 AI 코딩 비서가 제안한 코드의 30%가량을 쓴다고 말했다.  ‘비교적(modest)’ 생산성이 향상됐다고 지목한 사용자는 코파일럿 제안의 약 23%를 수락한다고 밝혔다. 이어 ‘중간(medium)’ 그리고 ‘높은(high)’ 생산성 개선을 보고한 사용자는 각각 27%, 28%가량을 쓴다고 전했다.    아울러 깃허브는 코파일럿이 적절한 시작점을 제공하는 한, 개발자들은 이 AI 코딩 비서의 제안을 수정해야 하는지 신경 쓰지 않는다는 사실을 발견했다고 언급했다. “코파일럿은 소프트웨어를 빌드하도록 설계되진 않았지만 개발자가 플로우를 쉽게 따라갈 수 있도록 유용한 제안을 제공하도록 설계됐다. 개발자에게 부품을 제공하는 셈이다. 완제품을 설계하고 구축하는 것은 개발자의 몫이다”라고 회사 측은 덧붙였다.  이와 함께 깃허브는 ‘뉴럴 코드 완성도의 생산성 평가(Productivity Assessment of Neural Code Completion)’라는 학술 연구 논문을 발표했으며, 코파일럿 사용과 관련한 더 많은 연구를 계획하고 있다...

소프트웨어 개발 깃허브 코파일럿 AI 코딩 비서

2022.07.18

깃허브(GitHub)의 연구 결과에 따르면 ‘깃허브 코파일럿(GitHub Copilot)’이 제안한 코드를 더 많이 수락하는 개발자가 적어도 더 생산적이라고 느끼는 것으로 나타났다(이에 따른 실제 개발자 생산성은 측정되지 않았다).    깃허브는 이 회사의 AI 기반 코딩 비서 깃퍼브 코파일럿을 사용해 ‘생산성이 크게 향상됐다’고 답한 개발자일수록 코파일럿의 코드 제안을 더 많이 수락하는 것으로 조사됐다고 밝혔다. 해당 보고서는 사용자의 지각된 생산성 설문조사와 코파일럿 사용 분석 결과를 담았다.  지난 7월 14일(현지 시각) 깃허브가 수십억 줄의 오픈소스 코드를 학습한 AI 모델을 기반으로 코드를 제안하는 깃허브 코파일럿 사용자 2,000명 이상을 대상으로 한 설문조사 결과를 공개했다. ‘큰(huge)’ 생산성 향상이 있었다고 답한 코파일럿 사용자는 이 AI 코딩 비서가 제안한 코드의 30%가량을 쓴다고 말했다.  ‘비교적(modest)’ 생산성이 향상됐다고 지목한 사용자는 코파일럿 제안의 약 23%를 수락한다고 밝혔다. 이어 ‘중간(medium)’ 그리고 ‘높은(high)’ 생산성 개선을 보고한 사용자는 각각 27%, 28%가량을 쓴다고 전했다.    아울러 깃허브는 코파일럿이 적절한 시작점을 제공하는 한, 개발자들은 이 AI 코딩 비서의 제안을 수정해야 하는지 신경 쓰지 않는다는 사실을 발견했다고 언급했다. “코파일럿은 소프트웨어를 빌드하도록 설계되진 않았지만 개발자가 플로우를 쉽게 따라갈 수 있도록 유용한 제안을 제공하도록 설계됐다. 개발자에게 부품을 제공하는 셈이다. 완제품을 설계하고 구축하는 것은 개발자의 몫이다”라고 회사 측은 덧붙였다.  이와 함께 깃허브는 ‘뉴럴 코드 완성도의 생산성 평가(Productivity Assessment of Neural Code Completion)’라는 학술 연구 논문을 발표했으며, 코파일럿 사용과 관련한 더 많은 연구를 계획하고 있다...

2022.07.18

"성공적인 API 전략의 핵심은..." 전문가들이 지목한 5가지

디지털 재정비를 원하는 기업들에게 API(Application programing interface)가 전환의 주요 조력자로 각광받고 있다. 특히, 데이터와 애플리케이션을 클라우드로 점차 이동하는 조직에게 더욱 그렇다. 한 때 목적을 위한 하나의 수단으로 비쳐졌던 API는 이제 고수준 전략 요소로 부상한 상태다. IT 리더에게 API의 개발과 관리, 유지보수, 보안이 주요 고려사항이자 큰 문제가 되었다. 이제 API는 애플리케이션과 서비스 사이의 통신을 제공함으로써 자동화를 지원하는 필수 구성요소라는 존재를 넘어서고 있다. 일련의 기업들에게는 수익 창출이라는 비즈니스 가치도 제공하고 있다. 노네임 시큐리티(Noname Security)가 후원한 451 리서치(451 Research)의 2022년 4월 연구(정보 입력 필요)에 따르면 디지털 전환 물결에 뒤이어 웹 API는 ‘통합형 웹 및 모바일 기반 제공물을 위해 제품 간 더 많은 데이터 공유가 필요하게 되면서 기하급수적인 성장’을 기록했다. 다양한 산업 부문의 350개 글로벌 기업에 근무하는 IT 전문가를 대상으로 실시한 2022년 1월 조사에 기초한 이 조사에서, 일반적인 조직의 경우 평균 1만 5,564개의 API를 사용하고 있었다. 이는 지난 12개월 대비 201% 증가한 수치다. 컨설팅 기업 BAH(Booz Allen Hamilton)의 수석 부사장 스콧 하나웨이트는 “API 전략 측면에서 ‘만능’ 해법은 없다. API 디자인은 쉽지 않으며, 각 프로젝트는 고유한 요건, 이해관계자, 역량과 원하는 결과가 있기 마련이다. 특정 기술, 아키텍처 스타일, 특정 API 유형에 대한 지원이 성공을 보장하지는 않는다”라고 말했다. 성공적인 API 전략을 구성하고 유지하기 위한 핵심에 대해 전문가들이 조언한 내용을 살펴본다.   데이터 소유권을 성문화하라 API는 1940년대에 개념이 정립된 이후로 광범위한 혁신을 거쳤다고 비영리 단체 DCA(Data Collaboration Allianc...

API 전략 데이터 접근 데이터 활용 데이터 거버넌스 데이터 사일로

2022.07.15

디지털 재정비를 원하는 기업들에게 API(Application programing interface)가 전환의 주요 조력자로 각광받고 있다. 특히, 데이터와 애플리케이션을 클라우드로 점차 이동하는 조직에게 더욱 그렇다. 한 때 목적을 위한 하나의 수단으로 비쳐졌던 API는 이제 고수준 전략 요소로 부상한 상태다. IT 리더에게 API의 개발과 관리, 유지보수, 보안이 주요 고려사항이자 큰 문제가 되었다. 이제 API는 애플리케이션과 서비스 사이의 통신을 제공함으로써 자동화를 지원하는 필수 구성요소라는 존재를 넘어서고 있다. 일련의 기업들에게는 수익 창출이라는 비즈니스 가치도 제공하고 있다. 노네임 시큐리티(Noname Security)가 후원한 451 리서치(451 Research)의 2022년 4월 연구(정보 입력 필요)에 따르면 디지털 전환 물결에 뒤이어 웹 API는 ‘통합형 웹 및 모바일 기반 제공물을 위해 제품 간 더 많은 데이터 공유가 필요하게 되면서 기하급수적인 성장’을 기록했다. 다양한 산업 부문의 350개 글로벌 기업에 근무하는 IT 전문가를 대상으로 실시한 2022년 1월 조사에 기초한 이 조사에서, 일반적인 조직의 경우 평균 1만 5,564개의 API를 사용하고 있었다. 이는 지난 12개월 대비 201% 증가한 수치다. 컨설팅 기업 BAH(Booz Allen Hamilton)의 수석 부사장 스콧 하나웨이트는 “API 전략 측면에서 ‘만능’ 해법은 없다. API 디자인은 쉽지 않으며, 각 프로젝트는 고유한 요건, 이해관계자, 역량과 원하는 결과가 있기 마련이다. 특정 기술, 아키텍처 스타일, 특정 API 유형에 대한 지원이 성공을 보장하지는 않는다”라고 말했다. 성공적인 API 전략을 구성하고 유지하기 위한 핵심에 대해 전문가들이 조언한 내용을 살펴본다.   데이터 소유권을 성문화하라 API는 1940년대에 개념이 정립된 이후로 광범위한 혁신을 거쳤다고 비영리 단체 DCA(Data Collaboration Allianc...

2022.07.15

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