Offcanvas

��������������� ������

수십 년째 요지부동, 'C 언어'가 왕좌 지키는 이유

‘C 언어’는 지난 1972년 개발돼 지금까지 전 세계적으로 널리 사용되고 있으며, 소프트웨어 시대의 핵심적인 기본 구성요소로 군림하고 있다. 하지만 지난 수십 년 동안 새로운 언어가 많이 등장했다. 그중에는 노골적으로 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++ 파이썬 러스트 카본 자바 프로그래밍 언어 개발 언어 개발자 소프트웨어 개발

7일 전

‘C 언어’는 지난 1972년 개발돼 지금까지 전 세계적으로 널리 사용되고 있으며, 소프트웨어 시대의 핵심적인 기본 구성요소로 군림하고 있다. 하지만 지난 수십 년 동안 새로운 언어가 많이 등장했다. 그중에는 노골적으로 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++가 고수준 기능을 풍부히 갖추고 있는 이유는 분명하다. 하지만 현재와 미래의 프로젝트 및 프로젝트팀에 미니멀리즘이 더 적합하다면...

7일 전

“목표는 C++ 현대화”··· 실험적 컴파일러 ‘Cpp프론트’ 공개돼

‘Cpp프론트(Cppfront)’는 유서 깊은 프로그래밍 언어를 ‘10배 더 간단하고, 안전하며, 도구를 사용하기 쉽게’ 만드는 대체 C++ 구문용 실험적 컴파일러다.    C++ 언어가 ‘Cpp프론트’라는 제안에 따라 더 간단하고 안전해질 예정이다. 이는 유명 C++ 개발자 허브 셔터가 제안한 실험적인 C++ 프론트엔드다. 그는 ISO C++ 위원회 의장, C++ 기능 설계자, 마이크로소프트 소프트웨어 아키텍트 등을 맡고 있다.  셔터는 해당 프로젝트의 깃허브 리포지토리에서 이를 C++의 중요한 발전이라고 언급하면서, “Cpp프론트는 C++이 10배 더 간단하고, 안전하며, 쉽게 도구를 사용할 수 있게 진화할 수 있는지 탐구하도록 설계된 실험적인 컴파일러다”라고 설명했다.  그에 따르면 대체 C++ 구문은 ‘오늘날 존재하지 않는 새로운 코드의 거품’을 제공하여, C++ 언어 설계자가 기본값을 변경하거나, 안전하지 않은 파트를 제거하거나, 언어를 문맥에서 자유롭거나 순서 독립적으로 만드는 등 임의적인 개선을 할 수 있게 한다. 유형 및 메모리 안전은 기본으로 지원된다.  이어 셔터는 “또한 두 번째 구문을 통해 파서(parser), 리팩토링 및 기타 도구를 쉽게 작성할 수 있도록 한다. 아울러 구문이 현 C++보다 2배로 줄어들어 C++ 20 모듈과 C++ 23 import std를 기본값으로 만든다”라고 전했다.  Cpp프론트 컴파일러는 현재 진행 중인 프로젝트다. 이 프로젝트 자체는 지난 7년 동안 개발돼 왔지만 지난주 미국 콜로라도주 오로라시에서 열린 컨퍼런스(CppCon)에서 일종의 ‘데뷔 파티’가 있었다. Cpp프론트는 MSVG, GCC, Clang을 포함한 메이저 C++ 20 컴파일러로 빌드된다. 지침은 깃허브에서 확인할 수 있다.  한편 지난 7월 말 구글은 C++의 후계자를 목표로 개발 중인 카본(Carbon)을 공개한 바 있다. 카본을 통해 C++와의 원활한 양방향 상호...

C++ 프로그래밍 언어 개발 언어 컴파일러 Cpp프론트 소프트웨어 개발 개발 도구

2022.09.22

‘Cpp프론트(Cppfront)’는 유서 깊은 프로그래밍 언어를 ‘10배 더 간단하고, 안전하며, 도구를 사용하기 쉽게’ 만드는 대체 C++ 구문용 실험적 컴파일러다.    C++ 언어가 ‘Cpp프론트’라는 제안에 따라 더 간단하고 안전해질 예정이다. 이는 유명 C++ 개발자 허브 셔터가 제안한 실험적인 C++ 프론트엔드다. 그는 ISO C++ 위원회 의장, C++ 기능 설계자, 마이크로소프트 소프트웨어 아키텍트 등을 맡고 있다.  셔터는 해당 프로젝트의 깃허브 리포지토리에서 이를 C++의 중요한 발전이라고 언급하면서, “Cpp프론트는 C++이 10배 더 간단하고, 안전하며, 쉽게 도구를 사용할 수 있게 진화할 수 있는지 탐구하도록 설계된 실험적인 컴파일러다”라고 설명했다.  그에 따르면 대체 C++ 구문은 ‘오늘날 존재하지 않는 새로운 코드의 거품’을 제공하여, C++ 언어 설계자가 기본값을 변경하거나, 안전하지 않은 파트를 제거하거나, 언어를 문맥에서 자유롭거나 순서 독립적으로 만드는 등 임의적인 개선을 할 수 있게 한다. 유형 및 메모리 안전은 기본으로 지원된다.  이어 셔터는 “또한 두 번째 구문을 통해 파서(parser), 리팩토링 및 기타 도구를 쉽게 작성할 수 있도록 한다. 아울러 구문이 현 C++보다 2배로 줄어들어 C++ 20 모듈과 C++ 23 import std를 기본값으로 만든다”라고 전했다.  Cpp프론트 컴파일러는 현재 진행 중인 프로젝트다. 이 프로젝트 자체는 지난 7년 동안 개발돼 왔지만 지난주 미국 콜로라도주 오로라시에서 열린 컨퍼런스(CppCon)에서 일종의 ‘데뷔 파티’가 있었다. Cpp프론트는 MSVG, GCC, Clang을 포함한 메이저 C++ 20 컴파일러로 빌드된다. 지침은 깃허브에서 확인할 수 있다.  한편 지난 7월 말 구글은 C++의 후계자를 목표로 개발 중인 카본(Carbon)을 공개한 바 있다. 카본을 통해 C++와의 원활한 양방향 상호...

2022.09.22

딥러닝 프레임워크 ‘3파전’··· '텐서플로우 vs 파이토치 vs JAX' 비교

오늘날 딥러닝 연구 및 개발을 주도하는 3가지 프레임워크가 있다. 각각 (1) 사용 편의성, (2) 기능 및 성숙도, (3) 엄청난 확장성으로 유명하다. 어떤 프레임워크를 사용해야 할까?  음성에 반응하는 시리나 알렉사, 스마트폰의 실시간 번역 앱, 스마트 트랙터, 창고 로봇, 자율주행차 등에 들어가는 컴퓨터 비전 기술 등 ‘딥러닝’은 크고 작은 방식으로 삶을 매일 변화시키고 있다. 그리고 거의 모든 딥러닝 애플리케이션은 3가지 프레임워크 (1) 텐서플로우, (2) 파이토치, (3) JAM 중 하나로 작성된다. 그렇다면 이 중에서 어떤 딥러닝 프레임워크를 사용해야 할까?    ‘텐서플로우’를 사용해야 할까? 1970년대와 1980년대에는 ‘IBM 제품을 샀다고 해고된 사람은 아무도 없다(Nobody ever got fired forbuying an IBM)’라는 말이 진리로 통했다. 2010년대에는 이를 ‘딥러닝에 텐서플로우를 사용했다고 해고된 사람은 아무도 없다’라고 바꿔 말할 수 있겠다. 하지만 주지하다시피 IBM은 1990년대에 접어들면서 도태됐다. 그렇다면 텐서플로우는 2015년 처음 공개된 지 7년이 지난 지금에도 여전히 경쟁력이 있을까? 확실히 그렇다. 텐서플로우가 그동안 가만히 있지 않았다. 텐서플로우 1.x는 파이썬과 매우 다른 방식으로 정적 그래프를 작성하는 게 전부였지만 텐서플로우 2.x는 ‘즉시 실행’ 모드를 사용한 모델 빌드가 가능해지면서 좀 더 파이토치 같은 느낌이 났다. 아울러 하이 레벨(high level)에서 텐서플로우는 더 쉬운 개발을 위해 케라스(Keras)를 제공하고, 로우 레벨에서는 속도를 위해 컴파일러를 최적화하는 XLA(Accelerated Linear Algebra)를 제공한다. XLA는 GPU 성능을 향상시키며, 대규모 모델 학습에 뛰어난 성능을 제공하는 구글의 TPU(Tensor Processing Units)를 활용하는 방법이기도 하다. 그리고 텐서플로우가 수년간 잘해...

딥러닝 머신러닝 인공지능 개발 라이브러리 개발 프레임워크 소프트웨어 개발 파이썬 텐서플로우 파이토치 JAX 케라스 넘파이

2022.08.31

오늘날 딥러닝 연구 및 개발을 주도하는 3가지 프레임워크가 있다. 각각 (1) 사용 편의성, (2) 기능 및 성숙도, (3) 엄청난 확장성으로 유명하다. 어떤 프레임워크를 사용해야 할까?  음성에 반응하는 시리나 알렉사, 스마트폰의 실시간 번역 앱, 스마트 트랙터, 창고 로봇, 자율주행차 등에 들어가는 컴퓨터 비전 기술 등 ‘딥러닝’은 크고 작은 방식으로 삶을 매일 변화시키고 있다. 그리고 거의 모든 딥러닝 애플리케이션은 3가지 프레임워크 (1) 텐서플로우, (2) 파이토치, (3) JAM 중 하나로 작성된다. 그렇다면 이 중에서 어떤 딥러닝 프레임워크를 사용해야 할까?    ‘텐서플로우’를 사용해야 할까? 1970년대와 1980년대에는 ‘IBM 제품을 샀다고 해고된 사람은 아무도 없다(Nobody ever got fired forbuying an IBM)’라는 말이 진리로 통했다. 2010년대에는 이를 ‘딥러닝에 텐서플로우를 사용했다고 해고된 사람은 아무도 없다’라고 바꿔 말할 수 있겠다. 하지만 주지하다시피 IBM은 1990년대에 접어들면서 도태됐다. 그렇다면 텐서플로우는 2015년 처음 공개된 지 7년이 지난 지금에도 여전히 경쟁력이 있을까? 확실히 그렇다. 텐서플로우가 그동안 가만히 있지 않았다. 텐서플로우 1.x는 파이썬과 매우 다른 방식으로 정적 그래프를 작성하는 게 전부였지만 텐서플로우 2.x는 ‘즉시 실행’ 모드를 사용한 모델 빌드가 가능해지면서 좀 더 파이토치 같은 느낌이 났다. 아울러 하이 레벨(high level)에서 텐서플로우는 더 쉬운 개발을 위해 케라스(Keras)를 제공하고, 로우 레벨에서는 속도를 위해 컴파일러를 최적화하는 XLA(Accelerated Linear Algebra)를 제공한다. XLA는 GPU 성능을 향상시키며, 대규모 모델 학습에 뛰어난 성능을 제공하는 구글의 TPU(Tensor Processing Units)를 활용하는 방법이기도 하다. 그리고 텐서플로우가 수년간 잘해...

2022.08.31

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

깃허브(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

‘록키 리눅스 9.0’ GA 버전 출시··· “새 빌드 시스템 제공”

레드햇 엔터프라이즈 리눅스(RHEL; Red Hat Enterprise Linux)의 소스 코드를 사용해 만든 무료 리눅스 배포판이자 오픈소스 엔터프라이즈 OS ‘록키 리눅스(Rocky Linux)’의 최신 릴리즈가 GA 버전으로 출시됐다. 이번 업데이트에는 새로운 보안 및 네트워크 기능과 ‘페리도트(Peridot)’라는 새 오픈소스 빌드 시스템이 추가됐다.    지난 7월 14일(현지 시각) 공개된 ‘록키 리눅스 9.0’는 개발자가 커뮤니티 또는 업스트림 지원 조직과 독립적으로 무언가 하려는 경우, 록키 리눅스를 선택하거나 OS를 확장 혹은 재생산할 수 있는 모든 빌드 체인 인프라 도구를 제공한다. 새로운 클라우드 네이티브 빌드 시스템 개발의 목표는 새 RHEL 버전 출시 후 일주일 이내에 록키의 새 버전이 출시될 수 있도록 하는 것이라고 프로젝트 담당자는 밝혔다.  페리도트의 소스 코드는 깃허브에서 확인할 수 있으며, 머지않아 헬름(Helm) 차트를 통해 쉽게 설치할 수 있을 것이라고 회사 측은 전했다. 록키 리눅스는 이곳에서 다운로드할 수 있다. 록키 엔터프라이즈 소프트웨어 재단(RESF)에서 호스팅하는 록키 리눅스는 센트OS(CentOS) 공동 창시자이자 CIQ의 CEO 그레고리 커처가 센트OS의 (원래) 목표인 RHEL의 프로덕션 레디 다운스트림 버전을 제공하기 위해 개발했다.  CIQ에서 개발하고 RESF에서 제공하는 페리도트는 록키 리눅스를 구축 및 관리하기 위한 클라우드 네이티브 스택 역할을 한다. 이 스택은 오픈소스로 출시됐다. 록키 리눅스는 오픈소스 도구를 사용하여 센트OS 수명 종료 문제가 반복되지 않도록 ‘재생산 가능한(reproducible)’ 운영체제를 제공한다. 이 밖에 록키 리눅스 9.0의 새로운 기능 및 변경 사항은 다음과 같다.  • SE리눅스(SELinux) 성능, 메모리 오버헤드, 로드 시간이 개선됐다.  • 현재 버전 3.0.1인 오픈SSL(OpenSSL)은...

록키 리눅스 리눅스 리눅스 배포판 소프트웨어 개발 클라우드 컴퓨팅 오픈소스

2022.07.15

레드햇 엔터프라이즈 리눅스(RHEL; Red Hat Enterprise Linux)의 소스 코드를 사용해 만든 무료 리눅스 배포판이자 오픈소스 엔터프라이즈 OS ‘록키 리눅스(Rocky Linux)’의 최신 릴리즈가 GA 버전으로 출시됐다. 이번 업데이트에는 새로운 보안 및 네트워크 기능과 ‘페리도트(Peridot)’라는 새 오픈소스 빌드 시스템이 추가됐다.    지난 7월 14일(현지 시각) 공개된 ‘록키 리눅스 9.0’는 개발자가 커뮤니티 또는 업스트림 지원 조직과 독립적으로 무언가 하려는 경우, 록키 리눅스를 선택하거나 OS를 확장 혹은 재생산할 수 있는 모든 빌드 체인 인프라 도구를 제공한다. 새로운 클라우드 네이티브 빌드 시스템 개발의 목표는 새 RHEL 버전 출시 후 일주일 이내에 록키의 새 버전이 출시될 수 있도록 하는 것이라고 프로젝트 담당자는 밝혔다.  페리도트의 소스 코드는 깃허브에서 확인할 수 있으며, 머지않아 헬름(Helm) 차트를 통해 쉽게 설치할 수 있을 것이라고 회사 측은 전했다. 록키 리눅스는 이곳에서 다운로드할 수 있다. 록키 엔터프라이즈 소프트웨어 재단(RESF)에서 호스팅하는 록키 리눅스는 센트OS(CentOS) 공동 창시자이자 CIQ의 CEO 그레고리 커처가 센트OS의 (원래) 목표인 RHEL의 프로덕션 레디 다운스트림 버전을 제공하기 위해 개발했다.  CIQ에서 개발하고 RESF에서 제공하는 페리도트는 록키 리눅스를 구축 및 관리하기 위한 클라우드 네이티브 스택 역할을 한다. 이 스택은 오픈소스로 출시됐다. 록키 리눅스는 오픈소스 도구를 사용하여 센트OS 수명 종료 문제가 반복되지 않도록 ‘재생산 가능한(reproducible)’ 운영체제를 제공한다. 이 밖에 록키 리눅스 9.0의 새로운 기능 및 변경 사항은 다음과 같다.  • SE리눅스(SELinux) 성능, 메모리 오버헤드, 로드 시간이 개선됐다.  • 현재 버전 3.0.1인 오픈SSL(OpenSSL)은...

2022.07.15

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 소프트웨어 개발

2022.05.17

‘닷넷 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...

2022.05.17

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 플래그가 활성화...

마이크로소프트 닷넷 닷넷 7 소프트웨어 개발

2022.05.16

‘닷넷 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 플래그가 활성화...

2022.05.16

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

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

개발자 소프트웨어 개발 프로그래밍 언어 개발 언어 웹어셈블리 리액티브 클로저 니켈 코브라 바이셉 프링크 파우스트 멜로즈 글리콜 웨이스 자바

2022.05.11

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

2022.05.11

아파치 카프카, ‘주키퍼(ZooKeeper)’ 제거한다

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

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

디지털 경험에 데브옵스 녹였다··· ‘웹옵스’ 따라잡기

많은 기업이 전자상거래에 진출하고, 고객이 원하는 것을 제공해야 하는 상황에 놓이면서 ‘온라인 경험’이 더욱더 중요해졌다. 온라인 경험은 사람들이 원하는 바에 따라 빠르게 변화해야 한다. 그렇다면 ‘웹옵스(WebOps)’는 어디에서 도움이 될 수 있을까? 팬데믹 2년, 모든 기업은 운영 방식을 바꿔야 했다. 전자상거래로의 전환 속도도 빨라졌다. 맥킨지에 따르면 유럽의 디지털 채택률은 81%에서 95%로 증가했다. 팬데믹 이전이라면 약 2~3년이 걸렸을 변화다. 이로 인해 (기업들은) 고객을 위한 디지털 경험을 구축하고 운영하는 데 초점을 맞추게 됐다. 바로 ‘웹사이트’다.   고객이 원하는 것을 제공하는 온라인 서비스와 사이트를 만드는 건 어려운 일이다. 오픈소스 콘텐츠 관리 시스템(Open-source Content Management System; CMS)은 여러 기업이 이를 달성하는 데 도움을 줬다. 하지만 이러한 사이트의 건전성을 유지해야 할 책임은 여전하다. 여기에는 기술 측면(웹사이트 플랫폼과 구성요소(플러그인 등)의 보안 관리 및 디도스(DDoS) 공격 방어 등)과 마케팅 요구사항(콘텐츠 및 새로운 서비스 업데이트 등)이 포함된다.  문제는 다음과 같다. 일반적으로 보안 업데이트는 IT가 한다고 쳐도, 사이트 갱신 또는 새로운 캠페인 등의 (웹사이트) 운영은 어떻게 관리해야 할까? 책임 소재는 어디이며, 팀 간의 협업이 제대로 이뤄지고 있는가? ‘웹옵스’의 세계 이 상황은 IT 운영 및 소프트웨어 개발 세계와 유사하다. 과거에는 개발자가 코드를 작성한 후, 새 소프트웨어를 IT 운영팀에 전달하여 생산에 투입했다. 개발자는 짧은 스프린트와 비즈니스 요구사항에 따라 새로운 기능을 제공하는 데 중점을 뒀다. IT 운영팀은 비즈니스 요구사항에 따라 서비스 가용성과 안전성을 담당했다. 두 팀 모두 저마다 목표와 지표가 달랐다. 데브옵스로 가보자. 데브옵스데이(DevOpsDays) 행사가 처음 열린 2009년 이후로, 데브옵스는 ...

웹옵스 웹 개발 소프트웨어 개발 데브옵스 전자상거래 고객 경험 직원 경험 온라인 경험 디지털 경험 팬데믹 웹사이트 마케팅 개발자 마이크로사이트 CMS

2022.03.29

많은 기업이 전자상거래에 진출하고, 고객이 원하는 것을 제공해야 하는 상황에 놓이면서 ‘온라인 경험’이 더욱더 중요해졌다. 온라인 경험은 사람들이 원하는 바에 따라 빠르게 변화해야 한다. 그렇다면 ‘웹옵스(WebOps)’는 어디에서 도움이 될 수 있을까? 팬데믹 2년, 모든 기업은 운영 방식을 바꿔야 했다. 전자상거래로의 전환 속도도 빨라졌다. 맥킨지에 따르면 유럽의 디지털 채택률은 81%에서 95%로 증가했다. 팬데믹 이전이라면 약 2~3년이 걸렸을 변화다. 이로 인해 (기업들은) 고객을 위한 디지털 경험을 구축하고 운영하는 데 초점을 맞추게 됐다. 바로 ‘웹사이트’다.   고객이 원하는 것을 제공하는 온라인 서비스와 사이트를 만드는 건 어려운 일이다. 오픈소스 콘텐츠 관리 시스템(Open-source Content Management System; CMS)은 여러 기업이 이를 달성하는 데 도움을 줬다. 하지만 이러한 사이트의 건전성을 유지해야 할 책임은 여전하다. 여기에는 기술 측면(웹사이트 플랫폼과 구성요소(플러그인 등)의 보안 관리 및 디도스(DDoS) 공격 방어 등)과 마케팅 요구사항(콘텐츠 및 새로운 서비스 업데이트 등)이 포함된다.  문제는 다음과 같다. 일반적으로 보안 업데이트는 IT가 한다고 쳐도, 사이트 갱신 또는 새로운 캠페인 등의 (웹사이트) 운영은 어떻게 관리해야 할까? 책임 소재는 어디이며, 팀 간의 협업이 제대로 이뤄지고 있는가? ‘웹옵스’의 세계 이 상황은 IT 운영 및 소프트웨어 개발 세계와 유사하다. 과거에는 개발자가 코드를 작성한 후, 새 소프트웨어를 IT 운영팀에 전달하여 생산에 투입했다. 개발자는 짧은 스프린트와 비즈니스 요구사항에 따라 새로운 기능을 제공하는 데 중점을 뒀다. IT 운영팀은 비즈니스 요구사항에 따라 서비스 가용성과 안전성을 담당했다. 두 팀 모두 저마다 목표와 지표가 달랐다. 데브옵스로 가보자. 데브옵스데이(DevOpsDays) 행사가 처음 열린 2009년 이후로, 데브옵스는 ...

2022.03.29

블로그ㅣ개발자에게 듣는 '좋은 소프트웨어'의 조건

무엇이 ‘좋은’ 소프트웨어를 만드는가? 개발에 착수하고, 작업을 잘 해내며, 기계가 아니라 사람을 위해 (코드를) 작성한다는 사실을 유념해야 한다.  트위터는 잘못된 정보와 악의적 주장의 온상일 수 있다. 이는 동시에 마이크로소프트의 스콧 헨슬먼이 소프트웨어 분야에서 수십 년 동안 쌓은 지식을 공유하는 곳이기도 하다. 그가 어떻게 핵심 기술을 능숙하게 다룰 수 있었는지 궁금하지 않은가? 학교를 통해서? 오픈소스 프로젝트를 통해서? 아니면 업무를 통해서?  이에 헨슬먼은 다음과 같이 말했다. “실제 사이트를 운영하고 확장했다.” 요지는 더 많이 개발할수록 더 많이 배운다는 점이다. 그는 “이것이 팁이다. 튜토리얼이 아니다. 무언가 만들어라. 도메인을 등록하고, 인증서를 받는다. 보안 헤더에서 A를 얻는다. 스토어에 제출하고, SEO를 수정하며, 오픈 그래프(Open Graph) 및 기능을 추가한다. 또 PWA를 만든다. 24시간 연중무휴로 사이트를 운영한다. 이것이 방법이다”라고 설명했다.  하지만 허니콤의 메건 글리슨은 처음부터 소프트웨어를 너무 많이 구축하지 말라고 언급했다. 왜 그럴까?    적게 개발해야 더 많이 배운다 헨슬먼은 운영하면서 배우는 것을 옹호한다. 글리슨은 처음부터 새 소프트웨어를 작성하는 것에 반대한다. 물론 글리슨이 소프트웨어의 가치에 이의를 제기한 건 아니다. 그것과는 거리가 멀다. 대신 그는 “새 기능을 추가하는 데만 너무 집중하면 제품, 사용자, 팀이 망가질 것이다”라고 지적했다.  글리슨은 소프트웨어를 개발하는 대신 소프트웨어 유지관리를 더 많이 해야 한다고 전했다. 그는 “기능만이 제품 가치를 높이는 게 아니다”라면서, “실제로 품질은 새로운 기능에서 거의 나오지 않는다. 보통 무엇인가를 추가하면 한동안 상황이 나빠진다. 그 소프트웨어 품질은 어디에서 오는가? 정원을 가꾸는 일에서 비롯된다”라고 설명했다.  이어 “문제는 더 많은 (소프트웨어를) 구축하는...

개발자 소프트웨어 소프트웨어 개발 소프트웨어 위생 유지관리 유지보수

2022.03.29

무엇이 ‘좋은’ 소프트웨어를 만드는가? 개발에 착수하고, 작업을 잘 해내며, 기계가 아니라 사람을 위해 (코드를) 작성한다는 사실을 유념해야 한다.  트위터는 잘못된 정보와 악의적 주장의 온상일 수 있다. 이는 동시에 마이크로소프트의 스콧 헨슬먼이 소프트웨어 분야에서 수십 년 동안 쌓은 지식을 공유하는 곳이기도 하다. 그가 어떻게 핵심 기술을 능숙하게 다룰 수 있었는지 궁금하지 않은가? 학교를 통해서? 오픈소스 프로젝트를 통해서? 아니면 업무를 통해서?  이에 헨슬먼은 다음과 같이 말했다. “실제 사이트를 운영하고 확장했다.” 요지는 더 많이 개발할수록 더 많이 배운다는 점이다. 그는 “이것이 팁이다. 튜토리얼이 아니다. 무언가 만들어라. 도메인을 등록하고, 인증서를 받는다. 보안 헤더에서 A를 얻는다. 스토어에 제출하고, SEO를 수정하며, 오픈 그래프(Open Graph) 및 기능을 추가한다. 또 PWA를 만든다. 24시간 연중무휴로 사이트를 운영한다. 이것이 방법이다”라고 설명했다.  하지만 허니콤의 메건 글리슨은 처음부터 소프트웨어를 너무 많이 구축하지 말라고 언급했다. 왜 그럴까?    적게 개발해야 더 많이 배운다 헨슬먼은 운영하면서 배우는 것을 옹호한다. 글리슨은 처음부터 새 소프트웨어를 작성하는 것에 반대한다. 물론 글리슨이 소프트웨어의 가치에 이의를 제기한 건 아니다. 그것과는 거리가 멀다. 대신 그는 “새 기능을 추가하는 데만 너무 집중하면 제품, 사용자, 팀이 망가질 것이다”라고 지적했다.  글리슨은 소프트웨어를 개발하는 대신 소프트웨어 유지관리를 더 많이 해야 한다고 전했다. 그는 “기능만이 제품 가치를 높이는 게 아니다”라면서, “실제로 품질은 새로운 기능에서 거의 나오지 않는다. 보통 무엇인가를 추가하면 한동안 상황이 나빠진다. 그 소프트웨어 품질은 어디에서 오는가? 정원을 가꾸는 일에서 비롯된다”라고 설명했다.  이어 “문제는 더 많은 (소프트웨어를) 구축하는...

2022.03.29

파이썬, 표준 라이브러리에서 ‘사용하지 않는 배터리’ 제거한다

사용되지 않는 많은 모듈이 파이썬에서 삭제될 예정이다. 이는 표준 라이브러리를 더 깨끗하게 유지하기 위한 프로세스의 서막일 수 있다.    파이썬의 표준 라이브러리에서 오래되고 유지관리되지 않는 모듈을 제거하기 위한 이니셔티브가 ‘PEP(Python Enhancement Proposal) 594’로 승인됐다. 정리될 모듈은 모두 구식이거나, 유지관리되지 않거나, 다른 모듈로 대체된 것이다. 해당 변경으로 인해 파이썬 개발자가 기존 앱을 다시 작성하게 될 가능성은 거의 없다. 어쨌든, 제거될 예정인 모듈은 지금부터 2년이 지나야 완전히 삭제된다.  파이썬에는 ‘배터리 포함(batteries included)’이라는 기본 개념이 있다. 이는 일반적인 개발 작업에 사용할 수 있는 표준 라이브러리를 제공한다는 의미다. 하지만 이 표준 라이브러리의 ‘사용되지 않는 배터리(오래되고 유지관리하기 어려운 모듈)’가 더 이상 유용하지 않다는 점에서 제거돼야 한다는 지적이 제기돼 왔다.  파이썬 기여자 크리스찬 헤임스와 브렛 캐넌이 작성한 ‘PEP 594’는 지난 2019년 제출됐으나 2022년 3월 11일 파이썬 3.11(Python 3.11)에서 최종 승인됐다. 이 PEP를 통해 파이썬 3.11에서는 특정 모듈을 더 이상 사용하지 않는 것으로 표시하며, 파이썬 3.12(Python 3.12)는 이러한 모듈을 포함하는 마지막 버전이 된다. 파이썬 3.13에서 사용되지 않는 모듈은 완전히 제거될 예정이다. 즉, 이러한 모듈을 아직 사용 중인 모든 곳에서 (이를) 교체할 수 있는 2년의 기간이 제공된다.  더 이상 사용되지 않는 모듈 중에서 오늘날 파이썬 개발자가 들어본 적 있는 모듈은 많지 않을 것이다. 이를테면 uu 모듈은 원래 이메일에서 바이너리를 인코딩하는 데 사용되는 uuencode 형식에 인코딩 메커니즘을 제공한다. Uuencode는 오늘날 거의 사용되지 않는다. 동일한 기능의 코덱이 파이썬의 다른 표준 라이브러리에...

파이썬 표준 라이브러리 모듈 개발 언어 프로그래밍 언어 소프트웨어 개발

2022.03.15

사용되지 않는 많은 모듈이 파이썬에서 삭제될 예정이다. 이는 표준 라이브러리를 더 깨끗하게 유지하기 위한 프로세스의 서막일 수 있다.    파이썬의 표준 라이브러리에서 오래되고 유지관리되지 않는 모듈을 제거하기 위한 이니셔티브가 ‘PEP(Python Enhancement Proposal) 594’로 승인됐다. 정리될 모듈은 모두 구식이거나, 유지관리되지 않거나, 다른 모듈로 대체된 것이다. 해당 변경으로 인해 파이썬 개발자가 기존 앱을 다시 작성하게 될 가능성은 거의 없다. 어쨌든, 제거될 예정인 모듈은 지금부터 2년이 지나야 완전히 삭제된다.  파이썬에는 ‘배터리 포함(batteries included)’이라는 기본 개념이 있다. 이는 일반적인 개발 작업에 사용할 수 있는 표준 라이브러리를 제공한다는 의미다. 하지만 이 표준 라이브러리의 ‘사용되지 않는 배터리(오래되고 유지관리하기 어려운 모듈)’가 더 이상 유용하지 않다는 점에서 제거돼야 한다는 지적이 제기돼 왔다.  파이썬 기여자 크리스찬 헤임스와 브렛 캐넌이 작성한 ‘PEP 594’는 지난 2019년 제출됐으나 2022년 3월 11일 파이썬 3.11(Python 3.11)에서 최종 승인됐다. 이 PEP를 통해 파이썬 3.11에서는 특정 모듈을 더 이상 사용하지 않는 것으로 표시하며, 파이썬 3.12(Python 3.12)는 이러한 모듈을 포함하는 마지막 버전이 된다. 파이썬 3.13에서 사용되지 않는 모듈은 완전히 제거될 예정이다. 즉, 이러한 모듈을 아직 사용 중인 모든 곳에서 (이를) 교체할 수 있는 2년의 기간이 제공된다.  더 이상 사용되지 않는 모듈 중에서 오늘날 파이썬 개발자가 들어본 적 있는 모듈은 많지 않을 것이다. 이를테면 uu 모듈은 원래 이메일에서 바이너리를 인코딩하는 데 사용되는 uuencode 형식에 인코딩 메커니즘을 제공한다. Uuencode는 오늘날 거의 사용되지 않는다. 동일한 기능의 코덱이 파이썬의 다른 표준 라이브러리에...

2022.03.15

모두에게 유익? 망상에 불과?··· ‘웹3’의 두 얼굴 살펴보기

‘웹3(Web3)’는 암호화폐 세계에서 가장 좋은 아이디어를 웹에 가져온다고 말한다. 좋아하지 않을 이유가 있을까?  처음에는 모두가 인터넷에서 소통하는 것만으로 행복해했다. 데이터 패킷이 오류 없이 전송되면 기뻐했다. 그로부터 수십 년이 지난 현재, (데이터) 덩어리가 계속 커지면서 (이를 전달하는) 더 좋은 방법이 없을까 고민하는 사람들이 생겨나고 있다. 데이터를 이동시키는 것만으로는 부족하지 않을까? 일정 수준의 보증이 있어야 하지 않을까? 어쩌면 이 경험을 더 쉽게 신뢰할 수 있는 방법이 있지 않을까?  몇몇 사람들에게 그 대답은 바로 ‘웹3(Web3)’다. 공식적인 위원회가 있는 건 아니기 때문에 ‘웹3’의 의미에 관해 저마다 조금씩 다른 생각을 갖고 있다. 하지만 기본적인 전제는 동일하다. 암호화폐 세계의 가장 좋은 아이디어를 가져와서 (이 아이디어의) 확실성과 보안을 웹에 제공할 방법을 찾는 것이다.     어떤 면에서 앞으로 나아갈 길은 명확하다. 디지털 화폐 알고리즘은 이전 세기로 거슬러 올라간다. 가장 유명한 ‘비트코인’과 ‘이더리움’은 세상에 나온 지 10년이 넘었다. 게다가 이 소프트웨어는 실전에서 입증됐고, 수십억 달러의 부를 가진 사람들이 신뢰한다. 사람들은 여러 해 동안 블록체인을 비금전적인 목적으로 활용하는 것에 관해 이야기해왔고, 가장 크고 가장 신뢰받는 데이터베이스 가운데 일부(예: 오라클 등)는 이를 이미 지원한다.  그러나 온갖 성공 스토리에도 불구하고 의심은 여전하다. 암호화폐가 웹에서 사기를 근절하지 못했기 때문이다. 몇몇 마니아가 구석진 곳에서 가지고 노는 것과 알고리즘이 모든 사람의 일상으로 자리 잡는 것은 차원이 다른 문제다. 여기서는 ‘웹3’를 기뻐해야 할 이유 7가지 그리고 반대로 회의적이어야 할 이유 7가지를 살펴본다.  탈중앙화는 모두에게 유익하다  비트코인 발명의 가장 큰 목표는 책임을 분산하는 것이었다. 실제로 인터넷의 초기 목표 중...

웹3 웹 개발 소프트웨어 개발 암호화폐 디지털 화폐 블록체인 비트코인 이더리움 탈중앙화

2022.03.10

‘웹3(Web3)’는 암호화폐 세계에서 가장 좋은 아이디어를 웹에 가져온다고 말한다. 좋아하지 않을 이유가 있을까?  처음에는 모두가 인터넷에서 소통하는 것만으로 행복해했다. 데이터 패킷이 오류 없이 전송되면 기뻐했다. 그로부터 수십 년이 지난 현재, (데이터) 덩어리가 계속 커지면서 (이를 전달하는) 더 좋은 방법이 없을까 고민하는 사람들이 생겨나고 있다. 데이터를 이동시키는 것만으로는 부족하지 않을까? 일정 수준의 보증이 있어야 하지 않을까? 어쩌면 이 경험을 더 쉽게 신뢰할 수 있는 방법이 있지 않을까?  몇몇 사람들에게 그 대답은 바로 ‘웹3(Web3)’다. 공식적인 위원회가 있는 건 아니기 때문에 ‘웹3’의 의미에 관해 저마다 조금씩 다른 생각을 갖고 있다. 하지만 기본적인 전제는 동일하다. 암호화폐 세계의 가장 좋은 아이디어를 가져와서 (이 아이디어의) 확실성과 보안을 웹에 제공할 방법을 찾는 것이다.     어떤 면에서 앞으로 나아갈 길은 명확하다. 디지털 화폐 알고리즘은 이전 세기로 거슬러 올라간다. 가장 유명한 ‘비트코인’과 ‘이더리움’은 세상에 나온 지 10년이 넘었다. 게다가 이 소프트웨어는 실전에서 입증됐고, 수십억 달러의 부를 가진 사람들이 신뢰한다. 사람들은 여러 해 동안 블록체인을 비금전적인 목적으로 활용하는 것에 관해 이야기해왔고, 가장 크고 가장 신뢰받는 데이터베이스 가운데 일부(예: 오라클 등)는 이를 이미 지원한다.  그러나 온갖 성공 스토리에도 불구하고 의심은 여전하다. 암호화폐가 웹에서 사기를 근절하지 못했기 때문이다. 몇몇 마니아가 구석진 곳에서 가지고 노는 것과 알고리즘이 모든 사람의 일상으로 자리 잡는 것은 차원이 다른 문제다. 여기서는 ‘웹3’를 기뻐해야 할 이유 7가지 그리고 반대로 회의적이어야 할 이유 7가지를 살펴본다.  탈중앙화는 모두에게 유익하다  비트코인 발명의 가장 큰 목표는 책임을 분산하는 것이었다. 실제로 인터넷의 초기 목표 중...

2022.03.10

“‘자바 8’이 여전히 우세하지만 ‘자바 17’의 물결이 오고 있다”

제이레벨(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)은 퍼포스에서 만든 자바 개발 도구다. 이 밖에 다...

소프트웨어 개발 자바 오라클 JDK 자바 8 자바 17 프로그래밍 언어 개발 언어

2022.03.04

제이레벨(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

‘아파치 카프카’, 개념부터 사용례까지

2011년 링크드인(LinkedIn)에서 개발된 ‘아파치 카프카(Apache Kafka)’는 이벤트 스트리밍에서 널리 쓰이는 플랫폼 중 하나다. 카프카는 고성능 데이터 파이프라인, 스트리밍 애널리틱스, 데이터 통합, 미션 크리티컬 애플리케이션에 사용된다.  모든 데이터를 데이터 웨어하우스에 저장하고 야간 배치 처리를 사용하여 분석하는 것만으로는 더 이상 비즈니스 또는 프로세스를 적시에 모니터링 및 관리하기가 충분하지 않다. 대신에 이후의 심층 분석을 위해 데이터 저장 외에 간단한 데이터 스트림 실시간 분석을 수행해야 한다.    카프카의 부속물에는 아파치 플링크(Apache Flink), 아파치 삼자(Apache Samza), 아파치 스파크(Apache Spark), 아파치 스톰(Apache Storm), 데이터브릭스(Databricks), 버베리카(Ververica) 등이 있다. 카프카의 대안으로는 아마존 키네시스(Amazon Kinesis), 아파치 펄사(Apache Pulsar), 애저 스트림 애널리틱스(Azure Stream Analytics), 컨플루언트(Confluent), 구글 클라우드 데이터플로(Google Cloud Dataflow) 등이 있다. 단, 카프카의 단점은 대규모 카프카 클러스터 구성이 까다로울 수 있다는 것이다. 컨플루언트 클라우드(Confluent Cloud)와 아파치 카프카용 아마존 관리형 스트리밍(Amazon Managed Streaming) 등 카프카의 상용 클라우드 버전을 사용하면 이 문제와 다른 문제를 해결할 수 있다(유료). 아파치 카프카란? 아파치 카프카는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션을 위한 오픈소스, 자바/스칼라, 분산 이벤트 스트리밍 플랫폼이다. 카프카 이벤트는 토픽별로 구성되고 저장된다. 카프카의 핵심 API는 5개이며, 다음과 같다.  • Admin API: 토픽, 브로커, 기타 카프카 객체를 관리하고 검사한다...

아파치 카프카 이벤트 스트리밍 데이터 데이터 파이프라인 데이터 웨어하우스 링크드인 컨플루언트 애널리틱스 소프트웨어 개발

2022.03.02

2011년 링크드인(LinkedIn)에서 개발된 ‘아파치 카프카(Apache Kafka)’는 이벤트 스트리밍에서 널리 쓰이는 플랫폼 중 하나다. 카프카는 고성능 데이터 파이프라인, 스트리밍 애널리틱스, 데이터 통합, 미션 크리티컬 애플리케이션에 사용된다.  모든 데이터를 데이터 웨어하우스에 저장하고 야간 배치 처리를 사용하여 분석하는 것만으로는 더 이상 비즈니스 또는 프로세스를 적시에 모니터링 및 관리하기가 충분하지 않다. 대신에 이후의 심층 분석을 위해 데이터 저장 외에 간단한 데이터 스트림 실시간 분석을 수행해야 한다.    카프카의 부속물에는 아파치 플링크(Apache Flink), 아파치 삼자(Apache Samza), 아파치 스파크(Apache Spark), 아파치 스톰(Apache Storm), 데이터브릭스(Databricks), 버베리카(Ververica) 등이 있다. 카프카의 대안으로는 아마존 키네시스(Amazon Kinesis), 아파치 펄사(Apache Pulsar), 애저 스트림 애널리틱스(Azure Stream Analytics), 컨플루언트(Confluent), 구글 클라우드 데이터플로(Google Cloud Dataflow) 등이 있다. 단, 카프카의 단점은 대규모 카프카 클러스터 구성이 까다로울 수 있다는 것이다. 컨플루언트 클라우드(Confluent Cloud)와 아파치 카프카용 아마존 관리형 스트리밍(Amazon Managed Streaming) 등 카프카의 상용 클라우드 버전을 사용하면 이 문제와 다른 문제를 해결할 수 있다(유료). 아파치 카프카란? 아파치 카프카는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합, 미션 크리티컬 애플리케이션을 위한 오픈소스, 자바/스칼라, 분산 이벤트 스트리밍 플랫폼이다. 카프카 이벤트는 토픽별로 구성되고 저장된다. 카프카의 핵심 API는 5개이며, 다음과 같다.  • Admin API: 토픽, 브로커, 기타 카프카 객체를 관리하고 검사한다...

2022.03.02

20살 된 ‘닷넷’ ··· “이번 주 닷넷 7 프리뷰 1도 출시” 

‘닷넷(.NET)’이 20주년을 맞았다. 이와 함께 마이크로소프트는 다음 버전의 첫 번째 프리뷰도 공개할 예정이다.  마이크로소프트가 닷넷 소프트웨어 개발 플랫폼의 출시 20주년을 축하하면서 이번 주 ‘닷넷 7’의 첫 번째 프리뷰를 선보일 계획이라고 밝혔다.    지난 2월 13일(현지 시각) 공식 블로그 게시글에서 마이크로소프트는 ‘닷넷 7 프리뷰 1’이 이번 주 출시될 것이라고 전했다. 하지만 새로운 버전에 관한 자세한 내용은 언급하지 않았다. 닷넷 7의 프로덕션 릴리즈는 (닷넷 6가 공개된 지 1년 만인) 11월에 나올 예정이며, 이는 지금까지 나온 것 중에 가장 빠르게 도입되는 닷넷 버전이라고 회사 측은 덧붙였다.  ‘닷넷 6’는 통합된 기본 라이브러리 세트, SDK, 간소화된 개발 환경과 함께 C# 10 및 최소 API 개선사항을 제공했다. 아울러 마이크로소프트의 ‘닷넷 마우이(.NET MAUI(Multi-Platform App UI))’ 개발 프레임워크가 조만간 공개될 예정이라고 회사 측은 말했다. 개발자는 마우이를 통해 단일 코드베이스를 사용하여 윈도우, 맥OS, iOS 및 안드로이드용 네이티브 앱을 빌드할 수 있다.  한편 2월 13일은 비주얼 스튜디오 닷넷(Visual Studio .NET)이 공개되고, 닷넷의 첫 버전이 출시된 지 20주년을 맞는 날이었다. 마이크로소프트는 이 플랫폼의 20주년을 축하하면서 현재 500만 명의 개발자가 닷넷을 사용하고 있다고 밝혔다. 또한 스택 오버플로우(Stack Overflow)의 개발자 설문조사에서 3년 연속(2019, 2020, 2021년) 가장 사랑받는 프레임워크로 꼽혔다고 덧붙였다. 닷넷은 웹 앱, iOS 및 안드로이드용 모바일 앱, 윈도우·맥OS·리눅스 컴퓨터용 데스크톱 애플리케이션 빌드를 위한 무료 오픈소스 소프트웨어 개발 플랫폼이다. ciokr@idg.co.kr

마이크로소프트 닷넷 닷넷 7 소프트웨어 개발 닷넷 마우이 스택 오버플로우

2022.02.16

‘닷넷(.NET)’이 20주년을 맞았다. 이와 함께 마이크로소프트는 다음 버전의 첫 번째 프리뷰도 공개할 예정이다.  마이크로소프트가 닷넷 소프트웨어 개발 플랫폼의 출시 20주년을 축하하면서 이번 주 ‘닷넷 7’의 첫 번째 프리뷰를 선보일 계획이라고 밝혔다.    지난 2월 13일(현지 시각) 공식 블로그 게시글에서 마이크로소프트는 ‘닷넷 7 프리뷰 1’이 이번 주 출시될 것이라고 전했다. 하지만 새로운 버전에 관한 자세한 내용은 언급하지 않았다. 닷넷 7의 프로덕션 릴리즈는 (닷넷 6가 공개된 지 1년 만인) 11월에 나올 예정이며, 이는 지금까지 나온 것 중에 가장 빠르게 도입되는 닷넷 버전이라고 회사 측은 덧붙였다.  ‘닷넷 6’는 통합된 기본 라이브러리 세트, SDK, 간소화된 개발 환경과 함께 C# 10 및 최소 API 개선사항을 제공했다. 아울러 마이크로소프트의 ‘닷넷 마우이(.NET MAUI(Multi-Platform App UI))’ 개발 프레임워크가 조만간 공개될 예정이라고 회사 측은 말했다. 개발자는 마우이를 통해 단일 코드베이스를 사용하여 윈도우, 맥OS, iOS 및 안드로이드용 네이티브 앱을 빌드할 수 있다.  한편 2월 13일은 비주얼 스튜디오 닷넷(Visual Studio .NET)이 공개되고, 닷넷의 첫 버전이 출시된 지 20주년을 맞는 날이었다. 마이크로소프트는 이 플랫폼의 20주년을 축하하면서 현재 500만 명의 개발자가 닷넷을 사용하고 있다고 밝혔다. 또한 스택 오버플로우(Stack Overflow)의 개발자 설문조사에서 3년 연속(2019, 2020, 2021년) 가장 사랑받는 프레임워크로 꼽혔다고 덧붙였다. 닷넷은 웹 앱, iOS 및 안드로이드용 모바일 앱, 윈도우·맥OS·리눅스 컴퓨터용 데스크톱 애플리케이션 빌드를 위한 무료 오픈소스 소프트웨어 개발 플랫폼이다. ciokr@idg.co.kr

2022.02.16

노코드에 드리운 그림자, 곳곳의 ‘락인’ 피하려면?

기업들이 ‘노코드(No-code)’ 소프트웨어 도구를 점점 더 많이 사용하게 되면서 락인(lock-in)될 가능성도 커질 것이다. 그렇다면 이러한 종속을 어떻게 피할 수 있을까? 기술 기업들은 항상 ‘자유’를 이야기한다. 자사의 핵심 시장 내 위치가 고객의 선택, 자사의(또는 다른 벤더의) 도구를 선택 및 사용하는 자유, 서비스 및 기능, 원하는 구축 파트너에 관한 자유방임적 태도, 플랫폼에 구애받지 않아 선택의 폭, 유연성, 제어를 극대화할 수 있는 오픈소스 기술에 관한 신뢰를 기반으로 한다고 말하는 것을 선호한다. 사실상 이는 단순한 겉치레일 때가 많다. 상호운용성을 지원하기로 하고 실제로 플랫폼 DNA를 명확하고 투명하게 개발 및 정렬한다 하더라도 대부분의 기술 기업은 가능하면 고객들이 올인하는 것을 선호하기 때문에 ‘우리가 더 잘한다(we do it better)’라는 요소는 항상 존재하기 마련이다.  좋게 보면 승리하고자 하는 자연스러운 욕망일 뿐이며 잘못됐다고 말할 순 없다. 나쁘게 보자면 이는 벤더 락인의 요소 및 사례에 해당되며, 여기서 고객들은 특정 벤더-고객 관계와 관련된 계약, 조항, 관례로 제한된 IT 도구를 사용할 수밖에 없게 된다.  아직 숙련되지 않은 소프트웨어 또는 데이터 엔지니어에 물어보면 이미 이러한 문제를 겪었을 가능성이 크다. 일각에서는 로우코드 및 노코드 소프트웨어 플랫폼의 부상으로 이러한 문제가 더욱더 흔해지리라 보고 있다.    4가지 노코드 락인 노코드 락인은 어떻게 나타나며, 어떻게 확인하고 피할 수 있을까? 이는 다음의 4가지 형태로 발생한다. • 노코드 벤더의 전문 서비스에 대한 락인 • 벤더의 커스텀 기능에 대한 락인 • 상업적 수준에서의 락인 • 데이터 및 코드 소유권을 중심으로 한 락인 강력한 내부 전문가 조직(CoE)을 구축하는 것이 광범위한 수준에서 이러한 문제 중 일부를 완화하는 해결책일 순 있다. 여기서는 위의 4가지 문제를 살펴보고 이를 해결하는 방...

노코드 로우코드 소프트웨어 개발 벤더 락인 데이터 관리

2022.02.14

기업들이 ‘노코드(No-code)’ 소프트웨어 도구를 점점 더 많이 사용하게 되면서 락인(lock-in)될 가능성도 커질 것이다. 그렇다면 이러한 종속을 어떻게 피할 수 있을까? 기술 기업들은 항상 ‘자유’를 이야기한다. 자사의 핵심 시장 내 위치가 고객의 선택, 자사의(또는 다른 벤더의) 도구를 선택 및 사용하는 자유, 서비스 및 기능, 원하는 구축 파트너에 관한 자유방임적 태도, 플랫폼에 구애받지 않아 선택의 폭, 유연성, 제어를 극대화할 수 있는 오픈소스 기술에 관한 신뢰를 기반으로 한다고 말하는 것을 선호한다. 사실상 이는 단순한 겉치레일 때가 많다. 상호운용성을 지원하기로 하고 실제로 플랫폼 DNA를 명확하고 투명하게 개발 및 정렬한다 하더라도 대부분의 기술 기업은 가능하면 고객들이 올인하는 것을 선호하기 때문에 ‘우리가 더 잘한다(we do it better)’라는 요소는 항상 존재하기 마련이다.  좋게 보면 승리하고자 하는 자연스러운 욕망일 뿐이며 잘못됐다고 말할 순 없다. 나쁘게 보자면 이는 벤더 락인의 요소 및 사례에 해당되며, 여기서 고객들은 특정 벤더-고객 관계와 관련된 계약, 조항, 관례로 제한된 IT 도구를 사용할 수밖에 없게 된다.  아직 숙련되지 않은 소프트웨어 또는 데이터 엔지니어에 물어보면 이미 이러한 문제를 겪었을 가능성이 크다. 일각에서는 로우코드 및 노코드 소프트웨어 플랫폼의 부상으로 이러한 문제가 더욱더 흔해지리라 보고 있다.    4가지 노코드 락인 노코드 락인은 어떻게 나타나며, 어떻게 확인하고 피할 수 있을까? 이는 다음의 4가지 형태로 발생한다. • 노코드 벤더의 전문 서비스에 대한 락인 • 벤더의 커스텀 기능에 대한 락인 • 상업적 수준에서의 락인 • 데이터 및 코드 소유권을 중심으로 한 락인 강력한 내부 전문가 조직(CoE)을 구축하는 것이 광범위한 수준에서 이러한 문제 중 일부를 완화하는 해결책일 순 있다. 여기서는 위의 4가지 문제를 살펴보고 이를 해결하는 방...

2022.02.14

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