Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
TOPIC

개발자

"개발 언어 지배자는 여전히 자바스크립트와 파이썬"

개발자의 언어 선호도에서 자바스크립트와 파이썬의 강세가 계속되고 있다. 러스트의 상승세도 만만치 않은 것으로 나타났다. 이는 지난 4일 공개된 '개발자 현황 22번째 에디션(State of the Developer Nation, 22nd Edition)'의 주요 내용이다. 이 보고서는 시장조사업체 슬래시데이터(SlashData)가 2021년 12월부터 올해 2월까지 전 세계 166개국 2만 명 이상의 개발자를 설문한 결과다.   보고서를 보면, 자바스크립트는 가장 선호하는 언어로 선정됐다. 슬래시데이터는 이 조사를 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는 웹 ...

자바스크립트 파이썬 러스트 3일 전

‘코틀린 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() 콜렉션 함수가 원래 함수 ...

젯브레인 코틀린 프로그래밍 언어 3일 전

"멀티 클라우드의 ID 정책을 통합한다" 오픈소스 프로젝트 '헥사' 공개

18일(현지시간) ID 오케스트레이션 업체 스트라타 아이덴티티(Strata Identity)가 새로운 오픈소스 프로젝트를 공개했다. 애저, AWS 및 구글처럼 호환되지 않는 클라우드의 ID 시스템을 통합해 사용자가 멀티 클라우드 플랫폼에서 ID 및 액세스 정책을 일관적으로 적용하는 기능을 제공한다.  스트라타 아이덴티티에 따르면, 해당 프로젝트는 오픈소스 기술인 헥사(Hexa)와 ID 액세스 정책을 정의하는 새로운 공통 정책 형식인 IDQL로 구성되며 멀티 클라우드와 온프레미스 시스템 및 공급업체의 솔루션을 결합한다. 이는 과잉 권한이 부여되고 소홀하게 관리되는 클라우드 계정이 사이버 공격자에게 공격 경로를 열어주는 격이라는 내용의 최근 연구에 따른 결과다.  다중 클라우드 ID 관리의 사일로 해결 스트라타 아이덴티티는 현재 인기 있는 클라우드 플랫폼이 서로 호환되지 않는 개별 정책 언어와 독점 ID 시스템을 사용한다고 말했다. 각 애플리케이션은 특정 ID 시스템과 함께 작동하도록 하드코딩되어야 한다. 헥사는 IDQL을 사용해 여러 ID 시스템이 시스템이나 애플리케이션을 변경하지 않고도 통합된 상태로 함께 작동할 수 있도록 설계됐다. 클라우드 플랫폼과 권한 부여 시스템, 데이터 리소스 및 제로 트러스트 네트워크에서 ID 및 액세스 정책을 추상화해 존재하는 정책을 찾고, 네이티브 구문에서 제네릭 IDQL 선언적 정책으로 변환한다. 그런 다음 클라우드 기반 아키텍처를 통해 대상 시스템의 기본적인 필수 정책으로 다시 변환하고, 클라우드 시스템과 앱, 데이터 리소스, 플랫폼 및 네트워크 전반에 걸쳐 ID 및 액세스 정책을 오케스트레이션한다.  IDQL 작업 그룹 구성원이자 글로벌 ID 및 액세스 관리 책임자인 톰 몰타는 “처음으로 모든 CSP(Cloud Service Provider) 또는 솔루션 아키텍처의 사실상 모든 엔드포인트에서 동서(east-weat) 및 남북(north-south) 간 정책을 모두 통합하고 중...

스트라타 아이덴티티 IDQL 헥사 4일 전

블로그 | 당신의 클라우드옵스 계획은 너무 늦었다

필자는 종종 워터폴 소프트웨어 개발 라이프 사이클 시대를 떠올린다. 당시엔 각 작업이 개별적으로 시작해 종료됐다. 한 작업이 끝난 결과물이 다른 문서화나 코드의 시작점이었다. 시간이 오래 걸리는 개발 방식이었고 방향을 바꾸기가 사실상 불가능했지만, 관련된 다른 계획을 세우기에는 훨씬 수월했다.   하지만 그런 시절은 끝났다. 오늘날 클라우드 개발 혹은 동시 개발 방식에서는 반복적이고 민첩하게 작업이 진행되고 언제든 방향을 바꿀 수 있다. 매우 강력한 데브옵스 툴 체인을 통해 자동화되면서 유동적인 개발 방식이 만들어졌다. 이런 변화는 올바른 방향이라고 생각한다. 하지만 동시에 일부 악화한 부분이 있다. 운영 계획이 대표적이다. 개발이 끝날 때까지 마치지 못하는 경우가 비일비재하고 아예 시작하지 못하기도 한다. 개발자는 코드와 데이터 구조를 운영팀에 넘기고 운영팀은 이를 장기적으로 잘 운영할 방법을 빠르게 찾아야 한다. 그런데 현실적으로 많은 운영 혹은 클라우드옵스 담당자가 현재 공석이다. 이 자리가 점점 기피 IT 업종이 되고 있기 때문이다. 그러나 운영 계획은 반드시 개발 과정의 초기, 최소한 설계 단계에서 시작돼야 한다(보안과 거버넌스 계획 역시 이 단계에서 함께 고민해야 하지만 여기서는 이 부분은 논외로 한다). 운영 계획을 개발 초기에 세워야 건강한 운영 관행이 시스템에 녹아들어 갈 수 있다. 새로 만든 시스템이든 클라우드로 이전한 시스템이든 마찬가지다. 이렇게 해야 프로세스와 스토리지 시스템이 장애나 성능, 사용성 등 일반적인 운영 문제를 겪을 수 있는 가능성을 줄일 수 있다. 운영 계획이 부실하거나 아예 없으면 문제에 직면할 가능성이 커지는 정도가 아니다. 개발팀에 다시 코드와 데이터 구조를 돌려보내기 전에 상당히 많은 문제에 고통받는다. 필자가 개발자와 애플리케이션 디자이너, 아키텍트 등에게 코드를 작성하거나 전환하기 전에 운영 계획을 먼저 마련하라고 하면 그들은 마치 필자가 에베레스트산을 오르라고 한 것 같은 표정으로 쳐다본다....

클라우드옵스 데브옵스 ops 5일 전

MS, ‘닷넷 7’ 프리뷰 4 공개…“정규식 개선ㆍ캐시 메트릭 지원”

‘닷넷 7(.NET 7)’의 네 번째 프리뷰가 지난 5월 10일(현지 시각) 공개됐다. 정규표현식 라이브러리에서의 스팬(span) 지원과 아이메모리캐시(IMemoryCache)의 적중률 및 실패율 통계 등이 추가됐다.  마이크로소프트 닷넷 웹사이트에서 다운로드할 수 있다. 닷넷 7의 프로덕션 릴리즈 출시는 11월로 예정돼 있다.   닷넷 7 프리뷰 4는 스팬 유형 지원을 추가하는 나머지 계획된 API를 정규표현식 라이브러리에 제공한다. 변경 사항은 ReadOnlySpan<char> 입력과의 매칭 지원을 추가하고, RegexOptions.IgnoreCase 처리를 정밀 검사한다. 프리뷰 4에서 지원되는 새로운 스팬 기반 API는 다음과 같다.    Regex.IsMatch(ReadOnlySpan<char> input) – 정규표현식이 입력 범위에서 일치하는 항목을 찾는지 여부를 나타낸다. Regex.Count(ReadOnlySpan<char> input) – 정규표현식의 모든 항목에서 입력 문자열을 검색하고 일치하는 항목 수를 반환한다.  Regex.EnumerateMatches(ReadOnlySpan<char> input) – 정규표현식 발생의 입력 범위를 검색하고 ValueMatchEnumerator를 반환하여 일치 항목을 천천히 반복한다.  또한 정규표현식 소스 생성기에서 생성된 코드를 더 읽기 쉽고, 더 디버깅하기 쉬우며, 여러 소스에서 생성된 정규표현식 패턴을 가진 프로젝트가 공통 코드를 공유할 수 있도록 했다고 업체 측은 밝혔다. 아울러 프리뷰 4에서는 아이메모리캐시의 메트릭 지원도 제공된다. 추가되는 주요 API는 ▲아이메모리캐시의 캐시 적중률, 실패율, 예상 크기 등을 보여주는 MemoryCacheStatistics, ▲MemoryCacheStatistics의 인스턴스 또는 TrackStatistics 플래그가 활성화되지 않은 경우 nul...

마이크로소프트 닷넷 닷넷 7 6일 전

구글이 포스트그레SQL 시장에서 AWS, 애저와 어깨를 겨룰 수 있는 이유

레거시에서 클라우드의 오픈소스 데이터베이스로 데이터를 옮기는 기업이 증가하는 가운데 구글 클라우드 플랫폼(GCP)이 포스트그레SQL(PostgreSQL)과 호환되는 완전 관리 서비스형 데이터베이스(DBaaS)를 알로이DB(AlloyDB)라는 이름으로 제공하고 있다. 알로이DB는 현재 공개 프리뷰 단계이며 아마존 오로라(Aurora), 마이크로소프트 애저의 포스트그레SQL용 데이터베이스 등과는 경쟁 관계에 있다.   가트너에 따르면 2022년까지 모든 데이터베이스의 75%가 클라우드 플랫폼에 구축되거나 마이그레이션될 전망이다. 또한 온프레미스 시스템으로의 복귀를 한 번이라도 고려한 적이 있는 기업은 5%에 불과하다. 가트너는 이 추세를 견인하는 원동력은 분석 용도의 데이터베이스 사용이라고 말했다.   또한 가트너는 레거시 데이터베이스의 50% 이상이 오픈소스로 전환되는 과정에 있으며 새로운 애플리케이션 개발의 70% 이상이 오픈소스 데이터베이스를 기반으로 이뤄지고 있다고 전했다. 데이터베이스 관리 시스템으로 포스트그레SQL을 선택하는 기업도 느는 추세다.   포스트그레SQL을 도입하는 이유는? 애널리스트는 구글 클라우드와 AWS, 마이크로소프트가 포스트그레SQL로 초점을 옮긴 이유는 데이터베이스 중에서 포스트그레SQL의 인기가 상승 중인 데 있다고 말한다.   레드몽크(RedMonk)의 수석 애널리스트 스티븐 오그래디는 “포스트그레SQL에 대한 관심과 사용이 다시 증가한 것은 확실하다. 가장 큰 이유는 잠재적인 제공업체가 많은 오픈소스 데이터베이스라는 점, 그리고 다용도 데이터베이스로서 모든 종류의 워크로드에 맞게 조정이 가능하다는 점에 있다”라고 말했다.   db인사이트(dbInsight)의 대표이자 창업자인 토니 베어는 핵심 기술과 스킬을 활용하는 포스트그레SQL 기반의 거대한 데이터베이스 생태계를 바탕으로 표준 엔터프라이즈급 오픈소스 데이터베이스로의 입지를 갖추고 있다고 말했다.   다른 전문가는 포...

오픈소스데이터베이스 포스트그레SQL 알로이DB 2022.05.13

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

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

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

“C#의 무서운 상승세" 5월 개발언어 인기 순위

티오베 인덱스(Tiobe Index)에 따르면 마이크로소프트의 프로그래밍 언어 ‘C#’의 인기가 심상치 않다. 2022년 5월 C#의 순위는 작년 5월과 동일하게 5위(6.39%)를 기록했지만 이를 지목한 비율은 1년 전(4.41%)에 비해 2%P 가까이 증가했다.    소프트웨어 품질 서비스 기업 티오베는 C#을 “현존하는 가장 성숙한 언어이며, 많은 현대 프로그래밍 패러다임을 지원한다”라고 설명하면서, 더 많은 고객이 지난 2년 동안 리눅스에서 C#을 실행하기 시작했다고 평가했다. 이어 C#이 티오베 인덱스의 상위 3개 언어 중 C를 대체할 수 있는 가능성이 크다고 내다봤다. 아울러 C#과 마찬가지로 상승세를 보이고 있는 ‘C++’은 작년 대비 1.01%P 증가했다. 전년 동기 대비 2위에서 1위로 올라선 파이썬은 0.86%P 증가했으며, 1위에서 2위로 내려간 C는 1.80%P 감소했다. 3위를 지킨 자바도 0.74% 감소했다.  티오베 인덱스는 구글, 빙, 야후, 위키피디아 등의 검색 엔진에서 검색된 수치를 기반으로 하며, 전 세계에서 해당 언어를 사용하는 소프트웨어 엔지니어, 교육과정, 소프트웨어 개발업체 수도 순위 산정에 반영한다. 2022년 5월 티오베 인덱스 톱 10은 다음과 같다. 1. 파이썬(12.74%) 2. C(11.59%) 3. 자바(10.99%) 4. C++(8.83%) 5. C#(6.39%) 6. 비주얼 베이직(5.86%) 7. 자바스크립트(2.12%) 8. 어셈블리(1.92%) 9. SQL(1.87%) 10. PHP(1.52%) 한편 구글에서 특정 프로그래밍 언어 튜토리얼이 얼마나 많이 검색됐는지를 기준으로 하는 PYPL(Popularity of Programming Language) 인덱스의 톱 10은 다음과 같다. C#은 해당 인덱스에서도 상위 5위 안에 들었다.  1. 파이선(27.85%) 2. 자바(17.86%) 3. 자바스크립트(9.17%) 4. C#(7.62%) 5...

프로그래밍 언어 개발 언어 티오베 인덱스 2022.05.12

"주피터부터 R스튜디오까지" 데이터 과학자의 필수 아이템 8선

데이터 과학의 열기가 식을 줄 모른다. 한때 데이터를 수집하고 분석하는 일은 연구소에 있는 소수의 과학자만 할 수 있다고 여겨졌다. 하지만 이제는 모든 기업이 데이터 과학을 활용해 조직을 간소화하고 고객을 만족시키고 싶어 하며, 데이터 과학 관련 툴 시장은 이런 수요를 충족시키기 위해 빠르게 성장 중이다. 불과 몇 년 전만 해도 데이터 과학자는 명령줄 그리고 몇 안 되는 오픈소스 패키지를 사용했다. 이제는 데이터 과학의 많은 허드렛일(예: 데이터 클렌징 등)을 처리하는 전문 툴이 속속 개발되고 있다.  규모도 변하고 있다. 원래 데이터 과학은 과학자가 열심히 실험한 후 행하는 숫자 작업에 불과했다. 이제 데이터 과학은 워크플로우의 가장 중요한 부분이다. 오늘날 기업은 현황을 신속하게 파악하기 위해 비즈니스 보고에 수학적 분석을 통합하고 대시보드를 구축한다. 아울러 속도도 빨라지고 있다. 한때 연간 또는 분기로 이뤄졌던 분석 작업은 이제 실시간으로 실행된다. 기업들은 관리자와 직원이 현명한 결정을 내릴 뿐만 아니라 데이터 과학이 제공하는 모든 것을 활용할 수 있도록 현재 무슨 일이 일어나고 있는지 파악하고 싶어 한다.  여기서는 끝없는 데이터 흐름 분석에 정확성과 과학을 더하는 주요 툴을 소개한다.    주피터 노트북(Jupyter Notebooks) 단어, 코드, 데이터 묶음은 ‘공통어(lingua franca)’가 됐다. 변하지 않는 분석과 콘텐츠로 채워진 정적 PDF는 영구적 기록을 생성하기 때문에 여전히 가치 있지만, 데이터 과학자는 하부의 메커니즘을 이리저리 손보고 싶어 한다. 주피터 노트북을 사용하면 단순히 정보를 확인하는 것 이상의 일을 할 수 있다. 주피터 노트북은 매스매티카(Mathermatica; 계산용 소프트웨어)의 유연성을 차용하고자 했던 파이썬 사용자에 의해 처음 개발됐다. 오늘날 표준 주피터 노트북은 40개 이상의 프로그래밍 언어를 지원한다(R, 줄리아(Julia), 자바, C 언어가 주를 이...

데이터 과학 데이터 애널리틱스 애널리틱스 도구 2022.05.11

글로벌 칼럼 | 로우코드와 애플리케이션 복잡성 간의 상관관계

여전히 로우코드에 대한 관심과 논란이 지속되고 있다. 많은 소프트웨어 개발자가 로우코드를 사용하면 애플리케이션의 개발 프로세스가 개선되는지, 아니면 애플리케이션 품질이 떨어지는지 잘 알지 못한다. 어떤 개발자는 로우코드가 보안에 미치는 영향을 우려하기도 한다. 만약 로우코드로 인해 애플리케이션의 복잡성이 증가한다면, 로우코드는 보안 문제를 더 난해하게 만드는 셈이다. 하지만 과연 로우코드가 애플리케이션을 더 복잡하게 만들까? 로우코드 사용과 애플리케이션 복잡성 간의 상관관계를 자세히 살펴보자.     복잡성은 접근법과 별개 로우코드가 반드시 애플리케이션의 복잡성을 야기하는 것은 아니다. 전통적인 애플리케이션 개발과 마찬가지로, 복잡성은 주로 제품 코드 베이스의 라이프사이클과 관련이 있다. 애플리케이션이 어떻게 만들어졌는지에 관계없이 복잡성을 완화하는 여러 방법이 있으며, 이들 접근법을 통해 성능과 확장성, 가용성, 혁신 속도를 개선할 수 있다. 물론 로우코드 애플리케이션에 대해서도 다른 제품 개발 프로세스처럼 복잡성을 낮추는 간소화 기법을 사용해야 한다.   ‘알 수 없는 것’과 복잡성 로우코드를 사용하면 애플리케이션에 개발팀이 직접 사용하지 않은 코드 수가 증가한다. 로우코드 플랫폼에 의해 더 많은 코드가 자동으로 생성되거나, 애플리케이션 작동에 필요하지만 개발자가 만든 것은 아닌 라이브러리에 포함된 코드가 늘어나는 것이다. 따라서 로우코드를 사용하면, 애플리케이션에 ‘알 수 없는 코드’가 더 많아진다. 하지만 ‘알 수 없는 것’과 복잡성은 다르다. 알 수 없는 코드 자체는 애플리케이션의 복잡성을 가중시키지 않는다. 반대로 그런 경우도 있지만 말이다.   복잡성을 낮추는 로우코드 로우코드를 사용하면 애플리케이션의 복잡성을 낮출 수 있다. 로우코드 플랫폼은 애플리케이션 개발자의 인지 부하와 시간 압박을 완화한다. 따라서 개발자는 세부 작업보다 비즈니스 논리에 더 집중할 수 있다. 세부 작업은 로우코드 환경에서 처리된...

로우코드 애플리케이션 개발 2022.05.11

"GPU 기반 파이썬 머신러닝" 파이토치(PyTorch)의 이해

파이토치(PyTorch)는 오픈소스 머신러닝 프레임워크로, 연구용 프로토타이핑과 프로덕션 환경에 모두 사용한다. 소스 코드 리포지토리에 따르면 파이토치의 가장 큰 특징은 다음 2가지다.   강력한 GPU 가속을 활용해 텐서 계산(넘파이(NumPy)와 유사) 테이프 기반 오토그라드(autograd) 시스템 위에 구축된 심층 신경망 아이디업 연구소(Idiap Research Institute), NYU, NEC 실험실, 페이스북, 딥마인드 테크놀로지(Deepmind Technologies)와 토치(Torch) 및 카페2(Caffe2) 프로젝트가 함께 처음 개발한 파이토치는 활발한 오픈소스 커뮤니티로 발전했다. 2021년 10월 출시된 파이토치 1.10은 426명의 기여자가 커밋했고 현재 리포지토리의 별 수는 5만 4,000개다. 여기서는 파이토치를 개괄적으로 살펴본다. 파이토치 1.10의 새로운 기능과 파이토치를 시작하기 위한 간단한 가이드도 제시한다.   파이토치의 발전 초기 학계와 연구원은 그래픽 처리 장치(GPU)를 사용한 모델 개발에서 파이토치가 텐서플로우에 비해 사용하기 쉽다는 점에 끌렸다. 파이토치는 기본적으로 즉시 실행(eager execution) 모드로 동작한다. 즉, 파이토치의 API 호출은 그래프에 추가돼 나중에 실행되는 것이 아니라 호출될 때 실행된다. 이후 텐서플로우도 즉시 실행 모드를 지원하도록 개선됐지만 학계와 연구 커뮤니티에서는 파이토치의 인기가 여전히 높다. 현재 파이토치는 프로덕션에 사용할 수 있는 단계이며 TorchScript를 사용해 즉시 실행과 그래프 모드 사이를 손쉽게 전환하고 TorchServe로 프로덕션까지의 경로를 가속화할 수 있다. torch.distributed 백엔드는 연구 및 프로덕션에서 확장할 수 있는 분산 교육과 성능 최적화를 가능하게 해주며, 풍부한 툴과 라이브러리 생태계는 파이토치를 확장해 컴퓨터 비전, 자연어 처리 등의 개발을 지원한다. 마지막으로, 파이토치는 알리바바, 아마...

파이토치 PyTorch 2022.05.11

블로그 | “휴식이 필요해” 번아웃 위험에 처한 개발자

올해 초 스택 오버플로우(Stack Overflow)가 소프트웨어 개발자 800명을 대상으로 직장에서 행복감을 느끼는지, 건강 유지와 개선을 위해 무엇을 하고 있는지에 관해 설문조사를 실시했다. 신체적 및 정신적 건강 개선을 원한다고 답한 응답자는 각각 88%, 83%였다. 스택 오버플로우는 개발자가 프로그래밍과 관련해 질의응답을 하는 사이트이다.   건강과 행복을 위해 무엇을 하는지 묻는 질문에 대해 ‘충분한 수분 섭취(57%)’, ‘건강한 식생활 유지(56%)’, ‘운동(47%)’이라고 답한 개발자의 비율이 가장 높았다. 25%는 근무 시간을 줄이고 있다고 답했다. 또한, 대다수 응답자가 일에서 잠시 벗어나 쉴 때 주로 ‘소셜 미디어 활동(37%)’, ‘동영상 시청(36%)’, ‘게임(27%)’ 등 디지털 기기를 사용한다고 답했다. 반면, 응답자의 절반은 산책이나 운동을 하는 것으로 나타났다. 더 나아가, 재직 중인 기업이 신체적 및 정신적 건강을 장려한다고 답한 응답자의 비율은 75%인반면, 60%는 회사에 다니면서 정신적으로 건강했던 날이 단 한 번도 없었다고 답했다. 이 조사 결과는 IT 웰빙 플랫폼 여보(Yerbo)가 발표한 ‘2022년 기술 부문 번아웃 상황(State of Burnout in Tech)’ 보고서의 내용을 뒷받침한다. 이 보고서에 따르면, IT 직원 5명 중 2명꼴로 번아웃을 경험할 위험이 높은 것으로 나타났으며, 업계는 직원의 복지 개선에 힘쓰지 않을 경우 잠재적인 위기에 직면해 있다. 실제로 세계보건기구(World Health Organization)는 번아웃을 에너지 손실과 부정적인 성향, 무가치감을 초래하는 합법적인 진단명으로 분류했다. 스택 오버플로우의 수석 애널리스트 데이비드 깁슨은 빠른 속도로 발전하는 산업에서 개발자의 번아웃을 막는 것은 앞으로도 쉽지 않을 것이라고 말했다. 하지만 업계는 규칙적인 휴식을 장려하는 등 개발자의 건강과 행복을 개선하기 위한 조치를 취할 필요가 있다.  edit...

개발자 번아웃 스택오버플로우 2022.05.11

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

분산 이벤트 스트리밍 플랫폼 ‘아파치 카프카(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

“여기 백엔드 개발자가 있다” 백엔드 개발자 경험을 위한 솔루션 열전

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

개발자경험 백엔드 오픈소스 2022.05.10

"왜 안 되는 걸까?" 파이썬에서 기대할 수 없는 4가지 기능 개선

파이썬에는 높은 편의성과 다양하고 강력한 라이브러리, 친절한 사용자 커뮤니티 등 좋은 점이 많지만 몇 가지 부족한 부분도 여전히 있다. 파이썬 작업을 수월하게 해줄 수 있는, 다른 언어에 있는 여러 기능을 적어도 당분간은 파이썬에서 기대할 수 없다. 개발자가 자주 요청하지만 현재 파이썬의 계획표에는 없는 4가지 기능을 소개한다. 이중 적어도 2개는 추가될 가능성이 없고, 다른 2개는 최소 몇 년 동안 계획이 없다. 이와 같은 기능이 왜 추가되지 않는지, 또는 미래의 파이썬에 추가되기 위해 무엇이 필요한지 살펴보자.     가능성 없음 : 정적 형식의 컴파일된 파이썬 버전 정적 형식 지정을 사용해 네이티브 기계 코드로 컴파일되는 파이썬을 꿈꾸는 개발자가 있다. 따지고 보면 유연한 형식 지정은 파이썬이 가진 느린 속도의 원인 중 큰 부분을 차지하는데, 정적 형식 지정을 사용하면 그 문제에 마침표를 찍을 수 있다. 또한 정적 형식 지정은 프로그래머에게 코드의 동작에 관한 강한 보장을 제공한다. 파이썬에는 형식 힌트가 있지만 형식 힌트의 용도는 린팅 툴을 통해 편집 시 정적 분석의 편의성을 높이는 데 있다. 런타임에 형식 힌트를 사용하는 것은 서드파티 프로젝트(예를 들어 pydantic)뿐이다. 파이썬 런타임 자체는 형식 힌트를 사용하지 않는다. 형식 힌트에 대한 PEP(파이썬 향상 제안) 484의 명확한 목표 중 하나는 형식 힌트를 영구적으로 옵션화하는 것이다. “파이썬은 앞으로도 동적 형식 지정 언어로 남을 것이며 파이썬 저작자는 형식 힌트를 (관례상으로도) 의무화할 생각이 전혀 없다.” 꼭 정적 형식 지정 파이썬을 원하는 개발자라면 사이썬(Cython) 또는 마이픽(mypyc)을 선택할 수 있지만 이 두 프로젝트에도 타협점은 있다. 사이썬의 경우 가장 큰 성능 향상은 순수 C 형식과 구조를 사용하고 파이썬 런타임 사용을 줄이는 데서 온다. 간단히 말해 파이썬의 동적 특성을 희생하지 않으면서 파이썬 컴파일 속도를 더 빠르게 하기는 어렵다....

파이썬 개발자 2022.05.10

자바스크립트 컨테이너, 리눅스 컨테이너의 대안 될까

디노 자바스크립트 및 타입스크립트 런타임을 개발한 라이언 달이 리눅스 컨테이너의 대안으로 ‘자바스크립트 컨테이너’와 ‘자바스크립트 샌드박스’의 가능성을 연구하고 있다고 밝혔다.    지난 5월 4일(현지 시각) 블로그에서 그는 자바스크립트를 “범용 스크립팅 언어(The Universal Scripting Language)”라고 언급했다. 달은 “자바스크립트의 보편성은 새로운 독립형 서버 컨테이너 등의 추상화를 촉발하고 있다. 자바스크립트 컨테이너는 많은 웹 서비스를 간소화할 수 있다”라고 말했다.   이어 “도커는 서버 소프트웨어 배포용 운영체제 수준 가상화를 통해 리눅스 컨테이너 사용을 대중화했다. 각 컨테이너 이미지는 종속성이 없고 즉시 실행할 수 있는 소프트웨어 패키지다. 하지만 브라우저 자바스크립트는 더 높은 수준의 추상화에서 유사한 밀폐 환경을 제공한다. 디노, 특히 ‘디노 디플로이(Deno Deploy)’에서 자바스크립트 컨테이너 기술을 검토하고 있으며, 현재 이를 추진할 엔지니어를 채용 중이다"라고 덧붙였다.  달에 따르면 스크립팅 언어는 많은 서버 문제를 해결하고, 비즈니스 로직을 더 저렴하고 빠르게 작성하는 데 도움을 줄 수 있다. 자바스크립트는 가장 미래 지향적인 스크립팅 언어이며, 아울러 자바스크립트 샌드박스는 서버 소프트웨어의 상위 수준 컨테이너로 부상하고 있다. 리눅스 컨테이너와 달리 자바스크립트 샌드박스는 웹어셈블리 바이너리 명령어 형식을 호출할 수 있다. ciokr@idg.co.kr  

자바스크립트 컨테이너 리눅스 컨테이너 컨테이너 2022.05.09

하이브리드 업무 환경에서 애자일 스프린트 리뷰ㆍ회고를 개선하는 방법

애자일 방법론을 이용하면 자기조직화 팀이 고객에게 집중하고 증분 형식으로 결과물을 배포하면서 피드백을 활용해 우선순위를 조절할 수 있다. 가장 보편적인 애자일 방법론은 소규모 팀이 1~4주 단위의 스프린트로 작업하는 스크럼(scrum)이다. 이 방법론에 따라 팀은 스프린트에 대해 정해진 양의 작업을 완료하는 데 목표를 둔다.   스크럼의 기본은 단순하다. 우선순위화된 사용자 스토리의 백로그를 리뷰하고 스프린트 중 확실히 완료할 수 있는 작업을 찾아 사용자 스토리에 문서화된 “완료의 정의” 상태를 목표로 둔다. 스크럼 세레모니는 팀 협업에 도움이 되며 보통 제품 소유자, 기술 리드 또는 스크럼 마스터가 정한 스케줄에 따라 반복되는 회의 형식으로 진행된다.   다양한 작업 환경에 맞춰 스크럼 조정하기 팬데믹 봉쇄 중에 스크럼 팀은 줌, 마이크로소프트 팀즈와 같은 툴을 사용해 가상으로 이와 같은 세레모니를 진행했다. 이에 따라 회의 구조도 변화해 가상 참가를 지원하고 유연한 작업 시간을 반영하게 됐다. 오늘날 많은 기업의 숙제는 하이브리드 업무 환경으로 영구적으로 전환하도록 스크럼 세레모니를 조정할 방법을 찾는 것이다. 팀원 중 일부는 사무실에서, 일부는 원격으로 작업한다. 이 같은 하이브리드 작업은 조직과 팀이 애자일 사고방식을 되돌아볼 새로운 기회이기도 하다. 애자일 팀이 하이브리드 작업을 성공적으로 수행해야 할 이유는 명확하다. 최근 실시된 한 설문조사에서 응답자의 40%는 직원의 절반이 매주 3일 이상 원격 근무를 지속할 것으로 예상했다. 또 다른 설문에서는 엔지니어의 75%가 대부분 시간 동안 원격 작업을 선호한다고 답했다. 이제 하이브리드 작업 지원은 개발자를 채용하고 근속시키는 핵심 요소가 됐음을 알 수 있다. 애자일 팀내 영구적인 하이브리드 작업을 원하는 엔지니어도 기업이 스크럼 세레모니를 재편성하고 부가적인 하이브리드팀 데브옵스 권장사항을 검토하도록 적극 협력해야 한다.   시작은 '스프린트 리뷰' 대부분 팀이 도입...

애자일 스프린트 하이브리드워크 2022.05.06

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

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

Copyright © 2022 International Data Group. All rights reserved.