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

6일 전

깃허브가 ‘2단계 인증(2FA)’ 도입을 대대적으로 추진하고 있다. (이에 따라) 깃허브 호스팅 저장소에 코드를 업로드하는 모든 사용자는 2023년 말까지 1개 이상의 2FA 형식을 활성화해야 한다. 이는 가장 최근 집계로 약 8,300만 명의 개발자에게 영향을 미칠 것으로 보인다.    회사에 따르면 대부분의 보안 침해는 특이한 제로데이 공격의 산물이 아니라 소셜 엔지니어링, 자격증명 도난 또는 유출 등과 관련돼 있다. “손상된 계정은 개인 코드를 훔치거나 악의적인 코드 변경 사항을 푸시하는 데 악용돼 애플리케이션 사용자에게 영향을 미칠 수 있다. 즉, 광범위한 소프트웨어 생태계 및 공급망에 미치는 영향이 상당하다. 최선의 방어는 암호 기반 인증을 넘어서는 것이다”라고 깃허브는 말했다.  깃허브는 이미 깃 오퍼레이션과 깃허브 REST API의 기본 인증을 중단하고, (사용자 이름과 암호 외에) 이메일 기반 기기 확인을 통해 이러한 방향으로 나아가고 있다고 밝혔다. “2FA는 강력한 다음 방어선이다. 하지만 소프트웨어 생태계 전반에서 2FA 채택 현황은 낮은 수준이다. 현재 현재 깃허브 활성 사용자의 약 16.5%, NPM 사용자의 약 6.44%만이 1개 이상의 2FA 형식을 쓰고 있다”라고 지적했다.   한편 이 회사는 최근 iOS와 안드로이드에서 깃허브 모바일용 2FA를 출시했다. 깃허브 모바일 2FA를 구성하는 방법은 2022년 1월 업로드된 깃허브 블로그 게시물을 통해 확인할 수 있다.  아울러 깃허브는 지난 2월 NPM 레지스트리 상위 100개 패키지의 모든 유지관리자를 대상으로 2FA를 의무화했으며, 이어 3월에는 모든 NPM 계정을 강화된 로그인 인증에 등록했다. 5월 31일까지는 상위 500개 패키지의 모든 유지관리자까지 2FA 의무화를 확대할 계획이라고 덧붙였다. ciokr@idg.co.kr  

2022.05.06

대퇴직으로 인해 숙련된 개발자가 부족해지면서 많은 기업이 로우코드 소프트웨어 개발로 눈을 돌리고 있다. 이를 활용하면 코딩 경험이 거의 없는 엔터프라이즈 사용자도 비즈니스 앱을 구축할 수 있다. 물론 결과가 항상 고품질인 것은 아니다.  코로나19 팬데믹 발발과 직원들이 대거 직장을 떠난 대퇴직(Great Resignation)의 부상 이후 ‘로우코드’ 개발 플랫폼 사용이 크게 증가했다. 이러한 인력 부족에는 소프트웨어 개발자가 포함된다. 이에 따라 기업들은 비즈니스 프로세스 트랜스포메이션을 지원할 수 있는 숙련된 소프트웨어 전문가를 찾기 위해 고군분투하고 있다. 지난 1월 IDC가 380곳의 기업을 대상으로 실시한 설문조사 결과에 따르면 전체 응답자의 48.6%는 사내에서 혁신을 추진하기 위해 로우코드 또는 노코드 플랫폼을 구매했다고 밝혔다. 소프트웨어 도구를 구매한 두 번째 이유는 ‘팬데믹과 관련된 필요성(39.3%)’이었다. “기업들은 팬데믹으로 인한 요구사항을 충족하는 데 있어 신속하게 움직일 수 있도록 지원하는 로우코드 및 노코드 플랫폼의 가치를 발견했다”라고 IDC는 설명했다.   가트너에 의하면 로우코드 소프트웨어 개발 플랫폼의 도입률은 연간 20% 이상 증가하고 있다. 지난 2021년 전 세계 로우코드 개발 기술 시장의 매출은 미화 138억 달러를 기록했다. 그리고 오는 2023년까지 중대형 기업의 50% 이상이 로우코드 개발을 채택하리라 예측됐다.   가트너의 리서치 부문 부사장 파브리지오 비스코티는 “코로나19 팬데믹의 경제적 여파로 인해 로우코드의 가치 제안이 검증됐다. 원격 작업을 지원하는 로우코드 기능(예: 디지털 양식과 워크플로우 자동화 등)은 지속적인 비즈니스 운영을 위해 필요하기 때문에 향후 더욱더 탄력적인 가격 모델로 제공되리라 예상된다”라고 말했다.  모건 스탠리는 소프트웨어 엔지니어가 전 세계적으로 부족한 상황이라고 언급했다. 2024년까지 약 3,800만 명의 개발자가 필요할 ...

2022.05.02

지금 대한민국은 2019년 시작된 글로벌 팬데믹 상황을 세계 최초로 벗어나고 있는 상황이다. 거리두기가 전면 해제되었으며 조만간 외부에서 마스크 착용 의무도 사라질 것으로 전망된다. 그러나 산업계는 다방면에서 팬데믹 후유증에 시달리고 있다. 반도체의 공급 부족으로 시작된 공급망 불안정 상황은 지금 다른 여러 자원 및 농산물로까지 확대될 조짐이다. 이로 인해 자동차는 물론 IT 관련 주요 제조업체의 제품 생산에 차질이 빚어지고 있으며 고객의 수요가 있음에도 길게는 1년 이상 기다려야 납품이 가능한 상황이 벌어지고 있다. 이는 본격적인 경제 회복에 부정적인 영향을 주고 있다. 그런데 공급망 문제로 어려움을 겪고 있는 영역이 또 있다. 바로 IT 분야 개발자의 수요와 공급이다. 최근 대부분의 IT 기업들이 소프트웨어 개발자를 구하는데 애를 먹고 있다. 이로 인해 개발자의 몸값도 치솟고 있다. 한동안 소프트웨어 개발 분야가 4D업종으로 인식되며 젊은 인력이 진입을 꺼려하던 시절이 있었다는 점을 상기한다면 현재의 상황은 긍정적이고 좋은 신호라고 생각할 수 있다. 드디어 개발자의 중요성을 인식하고 처우에 대한 개선이 이루어지고 있다고 볼 수 있으니까 말이다.   현재의 개발자 부족은 왜 발생한 것일까? 가장 먼저 1990년대 말 닷컴 붐 이후 IT 분야는 침체를 거듭하며 근무조건은 열악해지고 40대만 되어도 자리를 유지하기 어려운 직종으로 인식되면서 젊은 인력의 신규 진입이 현저히 줄어든 것이 이유다. 그래서인지 최근 IT 업계에 허리에 해당하는 30대후반~40대 중반 인력이 가장 부족하다. 그나마 구할 수 있는 인력은 40대 후반에서 50대 중반, 그러니까 닷컴 붐 무렵에 IT 분야에 뛰어든 인력들이다. 또한 출산율의 저하에 따른 자연적인 인구의 감소에 따른 젊은 층의 부족도 신규 인력의 공급에 영향을 주고 있다.  그리고 최근 수년간 소위 ‘네카라쿠배당토’로 일컬어지는 플랫폼 기업의 무서운 성장과 이로 인한 대규모 개발자 모집에 따른 인력 블...

2022.05.02

지구상에 필요한 모든 것을 만들 수 있는 개발자가 충분하지 않은 상황에서 빅테크 기업이 무엇을 할 수 있을까?  개발자가 충분하지 않을 때, 애플을 비롯한 빅테크 기업이 (이러한 문제를 해결하기 위해) 무엇을 할 수 있을까? 2가지가 있다. 첫째, 글로벌 코딩 기술 교육에 투자하고, 둘째, 기존 환경을 사용하기 쉽게 만드는 것이다.   애플은 ‘노코드’라는 미래를... 오는 6월 6일부터 10일까지 온라인으로 진행될 ‘WWDC 2022’는 메인 슬로건으로 (‘call to no code’가 아니라) ‘Call to code’을 내걸었다. 애플은 노코드라는 미래가 아니라 계속해서 개발자 환경을 구축하여 코딩 지식이 부족한 사람도 복잡한 앱을 빌드할 수 있도록 하고자 한다. 그렇게 하는 데는 확실한 경제적 이유가 있다.  오늘날 거의 모든 회사가 디지털 기업으로 거듭나면서 코딩 인재 수요가 기하급수적으로 증가하고 있다(2021년에는 그 수요가 2배로 증가했다). 이에 따라 유능한 개발자를 데려오려면 중소기업(SMB)은 감당할 수 없는 수준의 비용을 지불해야 한다. (반면에) 애플을 포함한 빅테크 기업은 전 세계 각지에서 유능한 개발자를 찾아 개발 허브를 구축하는 호사를 누리고 있다.  이러한 스킬 부족으로 인해 많은 회사가 대체적인 프로젝트 수행 방법을 모색하고 있다. 가트너에 따르면 2025년까지 기업에서 개발한 새로운 애플리케이션의 70%가 로우코드 또는 노코드 기술을 사용할 전망이다. 또한 멘딕스(Mendix)는 기업의 77%가 이미 가능한 곳에서 로우코드를 사용하고 있다고 말했다. 이는 비용이 많이 드는 개발팀의 필요성을 줄이고, 기업의 변화 대응과 애플리케이션 딜리버리를 가속화한다. 노코드 솔루션은 유지관리 비용도 저렴하다. 즉, 더 빠르고 더 낮은 위험으로 좋은 결과를 얻을 수 있다.  접근성이 핵심 코드 개발의 접근성을 높여야 할 필요성이 커지고 있다. 이러한 필요성으로 인해 애플을 비롯한 빅테크...

2022.04.08

최근 소프트웨어의 비중이 점점 커지면서 개발자와 이들의 생산성을 높이는 것이 모든 기업의 성공을 위한 핵심 요소로 자리잡았다. 그래서 아이러니하게도, 개발자의 자유를 통제하는 것이 개발자를 자유롭게 하는 가장 좋은 방법이 될 수 있다. 2013년 레드몽크(RedMonk) 애널리스트 스티븐 오그래디가 저술한 ‘새로운 킹메이커들(The New Kingmakers)’이라는 책은 개발자가 중요하다는 시대적 정신을 일부 담아냈지만, 새로운 사고 방식을 고취하는 내용이 대부분이었다. 적어도 기업 관점에서는 새롭다. 당시 개발자는 이미 오픈소스와 클라우드로 점점 더 많은 권한을 누리고 있었지만, 개발자의 생산성이 있으면 좋은 것을 넘어 필수라는 인식이 아직 자리잡지 못한 상태였다.   2017년 말 다행히 이런 인식은 대중화됐지만, 이로 인해 예기치 않은 상황이 발생했다. 개발자의 중요성이 커질수록 너도 나도 새로운 소프트웨어 툴과 오픈소스 프로젝트, 클라우드 서비스로 요구사항을 충족하려는 경향이 커졌다. 이런 현상은 개발자의 선택권은 물론, 자유도 많아졌다는 것을 의미하기도 하지만, 결코 긍정적이지 만은 않다. 오그래디가 말한 것처럼, 이런 개발자 주도의 세분화로 환상적인 오픈소스 소프트웨어가 탄생한 것은 반가운 사실이지만, 세분화를 관리하는 일은 개발자에게도 어렵다는 것이 문제이다. 또한, 개발자의 선택권이 너무 많아도 문제가 될 수 있다. 예를 들어, 소매 분야의 정설에 따르면 선택지가 지나치게 많을 때 소비자는 구매를 아예 하지 않을 가능성이 높고, 구매를 하더라도 선택에 대한 만족도가 떨어진다. 이처럼 많은 선택지로 인한 문제는 시리얼이나 의류에만 국한되지 않고 기업 소프트웨어를 구축하는 개발자에게도 적용된다. InfoWorld 기자 스콧 캐리가 지적한 것처럼, 복잡성이 소프트웨어 개발자를 죽이고 있는 것이 맞다. 그렇다면 이런 문제를 해결하기 위한 대책은 무엇일까?   약간의 통제가 필요하다 캐리는 위브웍스(Weaveworks) CEO ...

2022.04.07

젯브레인이 지난 4월 4일(현지 시각) ‘코틀린 1.6.20’을 출시했다. 이 최신 업데이트는 제네릭 자바 클래스와의 호환성 개선, 빌드 시간 단축 등을 특징으로 한다.    회사에 따르면 이번 릴리즈에서는 제네릭 자바 클래스 및 인터페이스를 확장할 때 호환성을 향상하고자 ‘non-nullable인 유형(Definitely non-nullable types)’을 지원한다. 단, 이는 현재 베타 단계다. 개발자는 새로운 구문(T & Any)을 사용하여 제네릭 유형 매개변수를 non-nullable인 유형으로 표시할 수 있다.  빌드 시간을 단축하기 위한 ‘JVM IR 백엔드 모드(JVM IR back-end mode)’는 모듈의 모든 파일을 병렬로 컴파일한다. 현재 실험적 기능인 상태다. 이렇게 하면 컴파일 시간을 최대 15%까지 줄일 수 있다고 회사 측은 밝혔다. 하지만 이 병렬 컴파일에는 몇 가지 제약 조건이 있다. 설계상 더 많은 JVM 힙(heap)이 필요하고(힙의 양은 스레드 수에 비례한다), kapt는 IR 백엔드를 비활성화하기 때문에 해당 기능은 kapt에선 작동하지 않는다. 또 IR 컴파일러를 사용한 코틀린/JS 개발의 효율성을 높이기 위해 새로운 증분 컴파일 모드가 도입됐다.  한편 코틀린 1.6.20의 설치 가이드라인은 공식 웹사이트에서 확인할 수 있다. 다른 개선사항 및 새로운 기능은 아래와 같다.  • 코틀린에서 생성된 LLVM IR 업데이트 및 버그 수정을 통해 코틀린/네이티브(Kotlin/Native) 성능이 향상됐다.  • 멀티플랫폼 프로젝트의 계층 구조 지원이 기본적으로 활성화됐다. 지난 2020년 8월 코틀린 1.4.0에서 제공됐던 이 기능은 프로젝트의 코드 공유를 개선한다.  • 코틀린/JVM용 컨텍스트 수신기의 프로토타입이 컨텍스트 종속 선언 정의를 위한 새로운 지원을 제공한다.  ciork@idg.co.kr

2022.04.06

많은 기업이 전자상거래에 진출하고, 고객이 원하는 것을 제공해야 하는 상황에 놓이면서 ‘온라인 경험’이 더욱더 중요해졌다. 온라인 경험은 사람들이 원하는 바에 따라 빠르게 변화해야 한다. 그렇다면 ‘웹옵스(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

깃허브 코파일럿, 탭나인 등의 AI 기반 도구는 개발자가 코드를 더 빠르게 작성하도록 돕는 자동완성 제안을 지원한다. 하지만 이렇게 생성된 코드가 안전하다고 어떻게 믿을 수 있을까?  2021년 6월, 깃허브가 코드 자동완성 도구 ‘코파일럿’을 출시했을 때 많은 개발자는 이 도구가 ‘내 마음을 읽고 코드를 더 빨리 쓸 수 있도록 도와준다’라며 놀라움을 감추지 못했다. 코파일럿은 누군가가 쓴 변수 이름과 주석을 기반으로 다음에 무엇이 올지 제안한다. 이는 코드 줄 또는 개발자가 작성 방법을 모를 수도 있는 전체 함수를 제공한다.    하지만 개발자가 확인하지 않고 이러한 제안을 사용하면 보안 취약점이 발생할 수 있다. 美 뉴욕대학교의 탠던 공대 연구진에 따르면 코파일럿을 테스트한 결과 이 도구가 생성한 코드의 40%에서 취약점이 발견됐다. 연구진은 알려진 취약점을 자동으로 찾아내는 깃허브의 코드QL(CodeQL)을 사용하여 (코파일럿이 생성한) 코드를 확인했고, ‘2021년 CWE 가장 위험한 소프트웨어 취약점 25개(2021 Top 25 Most Dangerous Software Weakness)’ 목록에 포함된 SQL 주입 취약점 또는 결함을 발견했다. 또 베리로그(Verilog) 등의 도메인 특정 언어의 경우 구문적으로 정확하고 의미 있는 코드를 생성하는 데 어려움을 겪었다고 언급했다.  이러한 문제의 대부분은 코파일럿이 구축된 방식에서 비롯된다. 첫째, 이 모델은 깃허브에 게시된 코드를 학습했는데, 이러한 코드의 상당 부분은 검증되지 않았다. 둘째, 오픈소스 리포지토리에는 충분한 경계를 구축하지 않고 입력 및 동작을 검사하는 많은 반복 코드 패턴이 포함될 수 있다. 코파일럿은 패턴이 빈번할수록 더 널리 사용되고, 따라서 안전하다는 가정하에 이러한 패턴을 제안한다. 셋째, 생성된 코드는 컴파일되지 않고, 잠재적인 보안 문제가 없는지 확인되지도 않는다. 아울러 연구진은 누군가의 리포지토리에 실수로 남겨진 일부 기밀...

2022.03.23

필자는 최근 ‘하이브리드 근무 체제 속 전문 개발자 채용 및 고용 유지를 위한 최선의 방법 4가지’에서 의사소통 개선, 다양성 추구, 워라밸 지원과 같은 다양한 조언을 했다. 조직의 리더는 팀과의 소통을 늘리면서 개인이 최선을 다할 수 있도록 권한을 부여하고, 신뢰해야 한다.    이런 방법은 중요한 리더십 목표이지만, 소프트웨어 개발자와 딜리버리 담당자, 그리고 애자일팀 사이의 일상적인 상호작용에서는 적용하기 어려울 수 있다. 필자는 여러 전문가에게 개발 관리자, 팀 책임자, 데브옵스(DevOps) 책임자, 데이터 사이언티스트 매니저를 위한 조언을 구했다. 마이크로매니지먼트(micromanagement) 없이 소통과 생산성을 높일 수 있는 방법을 7가지로 정리했다. 목표를 전달하고 공감을 얻어라 소프트웨어 개발업체 업레벨(Uplevel) CTO 라브스 카우르는 개발 관리자가 항상 릴리즈나 스프린트마다 더 많은 기능을 제공해야 한다는 압박을 받고 있음을 인지했다. 카우르는 “동기 부여와 동감의 균형을 맞추고 인간적인 유대감을 형성하라. 엔지니어링 관리자는 목표를 설정하고 개방적인 의사소통을 하는 것처럼 다양한 방식으로 팀원을 지원할 수 있지만, 무엇보다 가장 영향력 있는 행동은 ‘공감’이다”라고 말했다. 공감하는 리더십은 코로나19 팬데믹으로 인해 주목받고 있다. 카우르는 “지난 2년 동안 우리의 개인적인 삶과 직장 생활이 얽히게 됐고, 팀원 모두에게 공감이 필요한 문제가 있음을 이해하는 것이 관리자로서 중요하다. 인간적인 유대감이 없으면 팀원은 고립감과 불만을 느끼고 결국 회사를 떠난다”라고 조언했다. 스트레스로 인한 개발자의 번아웃을 방지하라 공감에서 한 걸음 더 나아가기 위해서는 소프트웨어 개발 관리자가 팀원의 ‘번아웃’ 증상을 인지해야 한다. 생산성 저하나 동료에 대한 냉소적인 반응 증가, 회사와의 거리감이 대표적인 번아웃 징후다. 기능 플래그 관리 솔루션 업체 런치다클리(LaunchDarkly)의 개발 마케팅 관리자 던 파...

2022.03.07

프라이스라인(Priceline)은 실시간 애널리틱스와 클라우드 네이티브 기술을 최대한 활용하기 위해 멀티클라우드 마이그레이션을 진행 중이다. 하지만 그 과정에서 문제가 없는 건 아니다. 미국에서 코로나19 확산이 수그러들자 여행 업계가 속도를 내고 있다. 온라인 여행 서비스 기업 ‘프라이스라인(Priceline)’의 클라우드 트랜스포메이션도 마찬가지다. 트래블로시티(Travelocity), 익스피디아(Expedia), 호퍼(Hopper) 등과 경쟁하는 이 회사는 구글 클라우드 플랫폼(GCP)을 중심으로 한 멀티클라우드 마이그레이션의 중간 단계를 지나가고 있다.    프라이스라인의 CTO 마틴 브로드벡은 “디지털 트랜스포메이션을 추진하고 있다. 올해 자사 제품 플랫폼을 구글 클라우드와 연동되는 쿠버네티스로 현대화하는 작업을 마무리할 예정이다”라고 말했다. 오픈소스 컨테이너 관리 시스템인 쿠버네티스는 (프라이스라인의) 하드웨어 및 소프트웨어 프로비저닝을 최소화할 수 있도록 효율적인 수평 확장을 제공한다. 이는 고객 트래픽에 대응하는 데 있어 엄청난 유연성을 필요로 하는 이 비즈니스의 중요한 요소라고 그는 설명했다.  브로드벡에 따르면 쿠버네티스를 통해 프라이스라인 개발자는 프로덕션 환경에서 기능을 테스트하고 배포할 수 있게 됐다. 하지만 클라우드 네이티브 방법론 및 기술로의 전환은 특히 개발자 생산성 극대화와 관련해 완전히 순조롭지는 않았다고 그는 전했다.  클라우드에서의 실시간 애널리틱스 프라이스라인 비즈니스의 핵심이라고 할 수 있는 독점적인 가격 책정 엔진은 실시간 데이터 인프라와 애널리틱스를 활용한다. 이를 위해 프라이스라인은 테라바이트 단위의 데이터를 몇 초 만에 분석할 수 있는 구글 빅쿼리(Google BigQuery)와 카프카(Kafka)를 쓴다. 아울러 데이터스택스(DataStax)의 고속 쿼리 엔진과 스타버스터(Startbust)의 데이터 메시용 실시간 애널리틱스 플랫폼도 사용한다.  클라우드에...

2022.02.25

'고객과 마지막으로 대화한 때가 언제인가?', '엔지니어링 팀원이 고객과 마지막으로 대화한 시점은 언제인가?' 조직의 엔지니어들에게 이 질문을 물어보면 “내 일은 고객과 대화하는 것이 아니라 코드를 작성하는 것이다”고 말할 가능성이 높다. 그래서 도어대시(DoorDash)가 직원들에게 식품 배달을 요구할 때 반발이 있었다. “나는 식품을 배달하는 것이 아니라 코드를 작성하기 위해 일한다”라는 응답이 나오곤 했다. 하지만 엔지니어는 스스로에게 “내가 코드를 작성하는 이유는 무엇인가?”라고 질문해야 한다. 이 질문과 답변은 조직의 성공에 중요하다. 왜냐하면 코드는 코딩의 결과를 경험하는 고객을 위한 것이기 때문이다. 그들이 만족하고 있는가? 그들의 문제가 잘 해결되었는가? 식품 배달은 도어대시 직원들이 고객의 앱 경험을 체험하는데 도움이 된다. 인튜잇(Intuit)에서도 직원들이 ‘FMH(Follow Me Homes)’를 통해 고객들이 제품을 사용하는 방식을 관찰하면서 이를 경험하고 있다. 엔지니어로서 또는 직원으로서 자신의 생각과 고객의 경험 사이에 대한 혼란스러운 현실 사이의 격차를 인지할 때 겸손을 배우게 된다. 스타트업은 고객과 긴밀한 관계가 있을 수밖에 없다. 고객을 확보할 수 없다면 폐업해야 한다. 경영진은 고객 공감을 형성해야 하고 이를 위해서는 고객들의 협조를 얻어내야 한다. 애석하게도 기업들이 성공하면서 DNA가 바뀌곤 한다. 고객 지원 부서가 고객 문제를 처리한다. 영업 조직은 새로운 고객을 확보하기 위해 구성된다. 그리고 어디엔가 격리된 엔지니어는 자신의 큐비클 안에서 코드가 어떻게 사용될지에 대한 어렴풋한 아이디어로 코드를 작성한다. 전화 게임을 기억하는가? 옆사람의 귀에 무엇인가를 속삭이면서 몇 사람을 거치면 마지막 사람은 처음에 한 말과 완전히 다른 말을 하게 된다. 우리는 직장에서도 전화 놀이를 하고 있다. 고객이 무엇인가에 대해 불평한다. 고객 지원 에이전트가 개선 요청서를 작성한다. 제품 관리자가 이것을 로드맵에 통합한다. ...

2022.02.07

유능한 개발자와 엔지니어, 데이터 과학자를 비롯한 전문 기술자 채용 및 고용 유지는 늘 쉽지 않았다. 하지만 2020년 원격 근무가 도입되고 작년에는 하이브리드 근무로 전환되면서 IT 기업의 경영자에 새로운 과제와 기회가 생겼다. 경영진과 관리자, 팀장은 소프트웨어 배포와 머신러닝 구축, 클라우드 전환, 기타 비즈니스 우선순위 제공 등의 역할을 수행하는 동시에 생산적이고 우수한 개발자를 모색해야 한다.   기업이 유연한 근무 환경을 지원하는 추세는 올 한 해 동안 지속될 것으로 보인다. 필자는 업계 선구자에게 전문 기술자를 채용하고 유지하는 최선의 방법에 관해 자문을 구했다. 블라인드닷컴(Blinds.com) 전임 CEO인 제이 스타인펠드는 최근 필자와의 인터뷰에서 블라인드닷컴 재직 당시 이기는 문화를 조성하는데 활용한 원칙을 소개했다. 스타인펠드는 “많은 사용자가 새로운 동력이 있다고 생각하는데, 있기는 하다. 사용자는 선택권이 있고 어디든 쉽게 갈 수 있기 때문이다. 하지만 사실 비즈니스는 그렇게 많이 바뀌지 않았다. 비즈니스의 핵심은 여전히 사람 존중, 개인의 발전 및 성장 기회 제공, 가치 고양 교육, 솔직한 소통이다.   개발자 고용 유지의 필수 조건은 소통과 신뢰 오늘날 경영진은 유능한 직원을 채용하고 유지하는 것이 중요한 전략이라는 사실을 잘 알고 있다. 이들 중 58%는 직원 간 기술 격차 해소의 우선순위가 팬데믹 이후 높아졌다고 밝혔다. 링크드인 생산성 엔지니어링 부사장 사브리 토진은 많은 기업에 유능한 전문 기술자가 필요하기는 하지만, 계획 및 전략은 팀과 개인의 요구에 적합해야 한다고 강조했다. 토진은 “정확한 공식은 없다. 기업은 단순히 서로를 표방해서는 안 된다. 개인과 팀마다 작업 방식이 다르기 때문이다. 경영진은 다양한 전략을 테스트하고 직원이 최대한 업무를 훌륭하게 해낼 것이라고 믿어야 하며, 직원의 피드백을 열린 마음으로 수용해 반복적으로 수정 및 개선해 나갈 자세를 갖춰야 한다”라고 말했다. 토진의 동...

2022.02.07

개발팀에 따르면 공격자는 이 취약점을 통해 권한 있는 프로그램을 속여 액세스하거나, 삭제할 수 없는 파일 및 디렉토리를 제거할 수 있다.    러스트 1.58에 이어 지난 1월 20일 공개된 이 포인트 릴리즈는 std::fs::remove_dir_all 표준 라이브러리 함수의 경합 조건(race condition)을 수정했다. 개발팀은 해당 취약점이 CVE-2022-21658로 지정됐다고 밝히면서 권고사항을 게시했다.  이 보안 문제를 통해 공격자는 권한 있는 프로그램을 속여 액세스하거나, 삭제할 수 없는 파일 및 디렉토리를 제거할 수 있다. 러스트 버전 1.0.0~1.58.0은 이 취약점의 영향을 받는다. 사용자는 툴체인을 업데이트하고, 업데이트된 컴파일러로 프로그램을 빌드하는 게 좋다고 개발팀은 권장했다.  또한 러스트 1.58.1은 러스트 1.58에서 도입된 진단 및 도구의 여러 회귀를 해결한다.  • non_send_fields_in_send_ty 클리피 린트(Clippy lint)는 오탐(false positives)이 너무 많은 것으로 확인돼 ‘nursery’라는 실험적 린트 그룹으로 이동됐다.  • useless_format 클리피 린트가 러스트 1.58에 도입된 형식 문자열에서 캡처된 식별자를 처리하도록 업데이트됐다.  • 표준 입력을 통해 전달될 때 생성된 파일이 형식화되는 것을 방지하는 Rustfmt의 회귀가 수정됐다.  • 경우에 따라 rustc에서 잘못된 오류 메시지가 표시되는 문제가 수정됐다.  ciokr@idg.co.kr

2022.01.24

‘아이파이썬(IPython)’의 버전 8이 출시됐다. 이번 업데이트에서는 코드 포맷팅, 자동 제안, 역추적 기능 등이 개선됐다.     지난 1월 12일(현지 시각) 7.0 릴리즈 이후 3년 만에 ‘아이파이썬 8(IPython 8)’이 공개됐다. 개발팀에 따르면 이번 업데이트의 주요 기능 중 하나는 CLI에서 black으로 자동 재포맷하는 것이다. black이 아이파이썬과 동일한 환경에 설치된 경우 터미널 아이파이썬은 가능하다면 CLI에서 기본적으로 코드를 다시 포맷한다.  또한 버전 8에서는 오류가 발생한 셀 번호를 표시해 오류 역추적 기능의 형식을 적절하게 지정한다. 이전에는 코드 셀에서 발생하는 오류 역추적에 파이썬 AST(Abstract Syntax Tree)를 완료하는 데 사용되는 해시를 표시했었다고 개발팀은 설명했다. 아울러 아이파이썬 8에서는 Ctrl-E, Ctrl-F 또는 오른쪽 화살표를 사용하여 자동 제안을 수락할 수 있다.  이는 fish 및 zsh 셸과 프롬프트-툴킷에서 사용할 수 있다.  아이파이썬 설치 지침은 이곳(IPython.org)에서 확인할 수 있다. 해당 문서에 의하면 이번 릴리즈는 아이파이썬 버전 1.0과 5.0 사이에서 더 이상 사용되지 않는 거의 모든 기능 및 모듈을 제거했다.  한편 아이파이썬의 목표는 대화형 및 탐색적 컴퓨팅을 위한 포괄적인 환경을 제공하는 것이다. 이 파이썬 REPL은 ipykernel을 통해 주피터 커널(Jupyter Kernel)에 전원을 공급하고, 탭 완성, 향상된 역추적, 여러 줄 편집, 순수한 파이썬 스크립트 위에 몇 가지 유용한 기능 등을 제공한다. ciokr@idg.co.kr

2022.01.14

개발자들에게 선택되는 기술이 엔터프라이즈 소프트웨어 시장을 어떻게 변화시켰는지에 관한 내용을 담은 스테판 오그래디의 저서 ‘새로운 킹메이커(The New Kingmakers)’가 나온 지 9년이 됐다. 당시 개발자들은 오픈소스와 클라우드를 선택했고, 컨테이너 오케스트레이션의 주인공으로 쿠버네티스를 캐스팅했으며, 서버리스로 전환했다.   이 접근 방식들은 개발자의 삶을 더 편리하게 만들었기 때문에 인기를 얻었다. 이를테면 개발자들이 애플리케이션을 원활하게 작동시키고, 확장할 수 있도록 했다. 하지만 서비스 및 애플리케이션을 클라우드로 이전할 수 없거나 (또는) 옮기려 하지 않거나 아니면 온프레미스로 실행하는 게 좋다고 보는 기업들도 있다.  개발자들의 싸움은 계속되고 있다. 2022년에는 어떤 일이 일어날까?   #1. ‘플랫폼 엔지니어링’이 데브옵스 및 SRE을 대신할 것이다 개발자들은 애플리케이션을 빠르고 효율적으로 배포하길 원한다. 이는 데브옵스 프로세스와 배포 프로세스를 거쳐 프로덕션 환경까지의 더 많은 협업으로 이어졌다. 이후 구글의 SRE(Site Reliability Engineering) 접근 방식이 인기를 얻으면서, 인프라 관리에 소프트웨어 엔지니어링 원칙을 적용하고 이를 가용성 및 안정성을 개선하는 데 활용했다.  다음 단계는 ‘플랫폼 엔지니어링’이다. 플랫폼 엔지니어링은 티켓을 접수하거나 팀 간에 핸드오프를 수행하는 전통적인 접근 방식이 아니라, 셀프서비스 인터페이스의 형태로 팀 간에 명확한 ‘계약’을 만드는 것이다. 퍼블릭 클라우드를 사용하는 것이 플랫폼 엔지니어링 접근 방식의 예다.  내부 플랫폼 팀은 기존 솔루션과의 통합, 전체 환경의 맥락 인식, 문서화 및 교육을 통한 지원을 제공한다. 기본 플랫폼 팀은 워크플로우, 자동화, 소스 제어 및 셀프서비스를 기반으로 자체 애플리케이션 및 인프라를 만들고 실행하는 방법을 정의한다.  각 팀이 애플리케이션에 기본 기능을 제공하기 ...

2022.01.03