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

개발자

데브옵스에 애자일과 ITSM 도구가 통합되어야 하는 3가지 이유

데브옵스 원칙을 따르고 데브옵스 문화로 전환하려는 조직이 점차 늘어나고 있다. 데브옵스의 주 실행법에는 버전 제어, 지속적 통합 및 배포(CI/CD), 코드형 인프라(IaC), 머신러닝을 운영에 적용하기(AI옵스), 지속적 테스트 등이 포함된다. 더 발전 팀은 지속적 계획, 클라우드 네이티브 애플리케이션 설계, 마이크로서비스 개발, 기능 플래그를 사용한 코드 제어, 보안의 시프트 레프트 촉진, 서비스 수준 목표 설정, 오류 예산 관리, 데이터 지향성 강화 등에도 초점을 둔다.   위의 각 실행방법은 데브옵스 조직의 두 가지 주요 IT 기능인 개발(새 애플리케이션 구축하기, 품질 향상 자주 릴리스하기)과 운영(비즈니스 시스템, 데이터베이스, 애플리케이션의 안정성과 성능 보장하기)을 바꾸는 데 도움이 된다.   데브옵스를 데브섹옵스(DevSecOps)로까지 확장하고, 보안을 다른 요소와 동등한 지위에 올려두는 조직도 늘고 있다. 데브섹옵스의 주요 IT 실행방법에 필요한 요소로는 경쟁에 필요한 속도와 민첩성, 비즈니스 운영에 필요한 혁신, 안정성, 보안, 성능간의 균형을 들 수 있을 것이다.   데브옵스 협업에는 애자일 및 ITSM 도구 통합이 필요하다 데브섹옵스 실행방법 하나만 가지고는 개발과 운영, 보안 기능을 결합해 목표 달성에 필요한 협업을 완성할 수 없다. 각 기능을 포괄하는 워크플로우를 구현, 추적하고 측정해야 한다.   많은 조직에서 이런 워크플로우는 스크럼, 칸반 등 개발 팀에 사용되는 애자일 방법론과 요청 관리, 사고 관리, 문제 관리, 변경 관리, 구성 관리 데이터베이스(CMDB) 유지보수, 그리고 운영 팀이 관리하는 IT 서비스 관리(ITSM) 실행방법을 결합해 실행된다.   그러나 애자일과 ITSM 도구를 통합하는 조직은 많지 않다.   개발 팀은 애저 데브옵스, Digital.ai, 지라 소프트웨어, 기타 애자일 도구로 개발 프로세스에서 사용자 스토리, 스프린트, 릴리스의 백로그를 관...

데브옵스 애자일 ITSM 2021.11.17

SAP, 개발자 위한 내장형 AI 및 무료 학습 프로그램 공개

SAP가 11월 16일부터 18일까지 온라인으로 진행된 글로벌 개발자 컨퍼런스 ‘SAP 테크에드(www.sap.com/korea/index.html)’에서 일반인 개발자 및 전문 개발자를 지원하는 새로운 제품과 서비스를 발표했다.  SAP는 전문 개발자 및 일반인 개발자 모두가 새로운 애플리케이션을 만들고, 기존 애플리케이션을 개선하며 복잡한 작업을 자동화할 수 있도록 SAP 비즈니스 테크놀로지 플랫폼(SAP Business Technology Platform, 이하 SAP BTP)에 대한 통합 로우코드(Low-Code)/노코드(No-Code) 개발 환경을 공개했다.  SAP는 SAP 앱가이버(SAP AppGyver) 개발 환경에 노코드 개발 및 자동화 기능을 추가하고, SAP 비즈니스 애플리케이션 스튜디오(SAP Business Application Studio)를 통해 로우코드 개발을 향상하며, 전문가를 위한 SAP 프로세스 자동화(SAP Process Automation) 프리뷰를 제공함으로써 고객이 조직 전체에 걸쳐 기술 인재를 활용해 더 많은 영역에서 성과를 낼 수 있는 새로운 방법을 제공한다. SAP는 전문 개발자를 위해 SAP HANA 클라우드(SAP HANA Cloud) 및 SAP 통합 스위트(SAP Integration Suite)를 포함한 SAP BTP의 프리 티어(Free tier)와 SAP 설계 언어인 SAP 피오리(SAP Fiori)를 위한 ‘호라이즌(Horizon)’의 새로운 시각적 테마 프리뷰를 제공한다. SAP는 기업별 맞춤 과제를 해결하는 모듈식의 애자일 솔루션을 통해 고객이 비즈니스를 통합 및 확장할 수 있도록 지원하는 몇 가지 업데이트를 공개했다. SAP BTP의 통합 계층인 SAP 통합 스위트의 최신 업데이트는 SAP API 비즈니스 허브(SAP API Business Hub)에서 사용할 수 있는 새로운 통합 콘텐츠 및 사전 패키지 통합 콘텐츠를 포함해 SAP 및 비(非) SAP 애플리케이션을 통합할...

SAP 2021.11.17

마이크로서비스 아키텍처를 사용해야 하는 이유

현재 운영 중인 애플리케이션은 크다. 고객은 많고, 이들 고객은 애플리케이션의 여러 기능을 적절히 사용한다. 제품 카탈로그는 다채롭고, 스토어는 큰 규모에 기능도 풍부하다. 여기까지 보면 잘 되고 있다.  단, 문제가 있다.    애플리케이션이 너무 자주 멈춘다. 장애가 발생하면 항상 개발자가 투입되어 매우 빠르게 사이트를 수정하지만, 그 과정에서 시간과 에너지가 소비된다. 매달 한 번 이상 다운되고 일단 다운되면 몇 시간은 지속된다. 여기서 손실된 비즈니스를 상상해 보라.  개발팀도 문제를 해결하고 싶어한다. 사실 개발자는 원래 많은 것을 하고 싶어한다. 구현하려고 생각 중인 훌륭한 새 기능에 대해 항상 이야기는 하는데, 정작 만들 수는 없다. 버그 수정과 급한 불을 끄는 일에 온통 매달리고 있기 때문이다.  추가 인력 채용에 대해 논의했지만, 예산이 한정돼 있다. 게다가 퇴사하는 사람을 대신할 인력을 충원하기에도 급급하다. 더 큰 기술 회사로 이직하는 사람도 있고 너무 많은 야간 긴급 호출에 질려 퇴사하는 사람도 있다. 기술 문제는 회사와 IT팀에 무거운 짐이지만, 해결할 방법이 보이지 않는다. 회사와 IT 책임자 모두 덫에 걸린 것 같다. 많은 소프트웨어 업체, 그리고 비 소프트웨어 회사의 많은 IT 부서가 이 덫에 걸렸다. 모든 일을 처리할 수 있을 것 같은 대규모 모놀리식 애플리케이션을 만들었지만, 이 애플리케이션은 통제 불능이 될 정도로 너무 커지고 복잡해졌다. 아무도 애플리케이션에서 일어나는 모든 일을 파악하지는 못할 정도가 됐다. 여기저기에서 고장이 나고, 고치는 데는 하염없이 긴 시간이 걸린다. 새롭거나 개선된 기능을 추가하고자 하지만 변경 작업이 너무 뒤얽혀 빠르게 할 수가 없고, 완료된 다음에는 버그투성이다. 개발 속도는 느리고 갈수록 더 느려진다. 개발자 수를 늘리려고 노력하지만 그렇게 해도 개발 속도는 더 빨라지지 않는 것 같다. 또한 신규 개발자가 애플리케이션에 대해 배우기가 터...

마이크로서비스 아키텍처 컨테이너 2021.11.16

파워 앱스 리뷰 | 확장성 뛰어난 클라우드 기반 노코드 빌더

파워 앱스(Power Apps)는 일련의 앱, 서비스, 커넥터, 데이터 플랫폼으로 구성된다(비-프로그래머를 위한 툴 포함). 이를 이용하면 파워 앱스의 하부 데이터 플랫폼(마이크로소프트 데이터버스), 또는 다른 데이터 출처(온-프레미스 또는 클라우드), 예를 들어 셰어포인트, 엑셀, 오피스365, 다이내믹스365, SQL 서버 등에 저장된 데이터에 연결하는 커스텀 비즈니스 앱을 신속하게 개발할 수 있다. 다시 말해 파워 앱스는 웹 및 모바일 앱 애플리케이션을 제작하는 로우-코드, 웹-기반 및 클라우드-기반 플랫폼이고, 비즈니스 데이터와 쉽게 연결할 수 있다. 프로그래머는 파워 앱스를 확장해 데이터 및 메타 데이터와 프로그램적으로 상호작용할 수 있고, 비즈니스 로직을 적용할 수 있고, 커스텀 커넥터를 생성할 수 있고, 외부 데이터와 통합할 수 있다.  필자가 2016년에 리뷰했던 파워앱스 버전과 달리 (단어 사이를 띄어 쓰지 않은 것에 주의) 최신 파워 앱스는 윈도우 스토어 기반의 설계 환경이 필요하지 않고, 노-코드 빌더와 차원이 다르게 발전했다. 이는 마이크로소프트가 당시 약속했던 클라우드 기반 ‘파워앱스’ 설계 환경을 마침내 구현할 것이기도 하다. 참고로, 현재 시장에는 아마존 허니코드(Amazon Honeycode), 구글 클라우드 앱시트(Google Cloud AppSheet) 등 약 400개에 이르는 로우-코드 및 노-코드 앱 빌더가 나와 있다.   파워 앱스 구성 요소  일반적으로 파워 앱스 홈페이지에서 파워 앱스 구축을 시작한 후 파워 앱스 스튜디오 페이지에서 이를 추가적으로 개발한다. 개발자는 마이크로소프트 파워 앱스 모바일 앱을 이용해 윈도우, iOS, 안드로이드 기기에서 앱을 볼 수 있어야 한다. 이는 연관 앱 스토어로부터 다운로드할 수 있다. 관리자 권한이 있으면 기업의 환경, 데이터 연결, 역할, 정책을 관리 센터 페이지에서 제어할 수 있다.    파워 앱스 홈페이지  앱을 제작하...

파워앱스 PowerAppls 노코드 2021.11.15

SaaS와 로우코드 애플리케이션 QA 테스트를 자동화하는 방법

품질 보증 자동화 엔지니어는 레거시 모노리식 애플리케이션부터 마이크로서비스를 활용하는 클라우드 네이티브 애플리케이션에 이르기까지 기업 내부에서 개발된 애플리케이션을 테스트한다. 일반적인 미션 크리티컬 애플리케이션에는 코드 수준에서의 단위 테스트와 코드 리뷰, API 테스트, 자동화된 사용자 경험 테스트, 보안 테스트, 성능 테스트 등이 필요하다. 가장 모범적인 데브옵스 사례는 이런 테스트 실행을 자동화한 다음 CI/CD(지속적 통합 및 제공) 파이프라인 내에서의 지속적인 테스트를 위한 최적의 하위 집합을 선택하는 것이다.   그런데 서비스형 소프트웨어(SaaS) 플랫폼이나 시민 개발자에게 개발 권한을 주는 로우코드 개발 툴 또는 노코드 플랫폼으로 구성된 애플리케이션과 워크플로우, 통합, 데이터 시각화, 사용자 경험에는 어떻게 대처해야 할까? 과연 코드가 적게 혹은 아예 사용되지 않는다고 해서 필요에 따라 워크플로우가 기능하고 데이터 처리가 기업 요구사항에 따라 이뤄지며, 보안 구성이 회사 정책에 부합하고 성능이 사용자의 기대에 부응할까? 이 질문은 필자의 고등학교 시절 미적분학 선생님의 말씀을 떠올리게 한다. 선생님은 “단순히 추정만 하는 것은 나와 너희를 웃음거리로 만드는 일이다”라고 말했다. 이 말을 SaaS와 로우코드, 노코드의 경우에 대입하면, 테스트 계획 없이 막연히 앱이 요청한 대로 작동할 것이라고 상정할 경우 다음과 같은 문제로 이어질 수 있다. •    이해관계자는 예상하지 못한 결과로 당혹스러운 상황 발생 •    데이터를 대중 혹은 액세스 권한이 없는 직원에게 노출시키는 보안 허점 발생 •    다른 통합 워크플로우와 고객 경험에 전파될 수 있는 데이터 문제 발생 •    애플리케이션을 많은 사용자와 더 큰 데이터 집합으로 확장할 때 성능 문제 발생 •    애플리케이션 재구축 및 해결책 개발 ...

SaaS 로우코드 애플리케이션 2021.11.12

'폴리리포주의자'가 모노리포를 반대하는 3가지 이유

모노리포(monorepo)와 폴리리포(polyrepo)가 무엇이냐는 질문에 답하려면 먼저 일반적인 애플리케이션을 구성하는 모듈을 살펴보아야 한다. 하나의 애플리케이션에는 여러 가지 구성요소가 있다. 즉, 몇 가지 모바일 클라이언트 앱, 웹 애플리케이션 프론트엔드, 하나 이상의 백엔드 서비스, 데이터베이스 및 데이터 관리 계층, (보고 및 관리와 같은)전문 서비스 등이다.  각 구성 요소에 연결된 소스 코드도 있다. 구성 요소를 담당하는 모든 개발자가 액세스하는 소스 코드는 코드 리포지토리에 저장된다. 코드 리포지토리와 저장소 관리 방법은 매우 다양하다. 리포지토리 대다수는 깃(Git)이라고 알려진 오픈소스 시스템에 기반한다.   각 구성 요소에는 코드 리포지토리가 있다. 자, 여기서 문제가 생긴다. 애플리케이션의 모든 구성 요소에 대한 모든 코드를 회사 전체나 애플리케이션 전체의 코드 리포지토리에 저장해야 하는가? 아니면 각 구성 요소마다 고유한 개별 코드 리포지토리가 있어야 하는가? 최근까지 애플리케이션 각 구성 요소에는 일반적으로 고유한 리포지토리가 있었다. 이 모델은 여러 개의 독립적인 코드 리포지토리를 가진 애플리케이션과 관련이 있으므로 폴리리포라고 한다.  그러나 최근 몇 년 동안, 특히 구글을 비롯한 일부 업체는 모든 애플리케이션 구성 요소의 모든 코드를 하나의 큰 리포지토리에 집어넣는 쪽에 찬성했다. 이러한 코드 관리 모델을 모노리포라고 한다.  폴리리포와 모노리포 방법론은 각기 장단점이 있으며, 분석 기사도 많았다. 과연 둘 중 어떤 방식을 사용해야 하는 것일까? 개인적으로는 전통적인 폴리리포 모델이 훨씬 우수하다고 생각한다. 모노리포 모델은 잘못된 습관이나 건전하지 않은 프로세스를 조장하고, 개발 조직의 확장 가능성과 애플리케이션 자체의 복잡성 등으로 애플리케이션 확장이 실질적으로 더 어려워진다. 이 주장을 뒷받침하는 3가지 이유를 면밀히 살펴보자.   이유 #1 : 모노리포는 단일 팀 소...

모노리포 폴리리포 리포지토리 2021.11.10

파이어폭스, 마이크로소프트 스토어에 공식 등록…윈도우 S 모드 등에 유용

화요일, 모질라 파이어폭스가 마이크로소프트 스토어에 등록됐다. 주류 브라우저로서는 처음으로 스토어에 추가됐는데, 윈도우 10과 11 환경에서 스토어 앱 형태의 다양한 브라우저를 만나고 싶었던 사용자에게는 무척 반가운 일이다. 모질라에 따르면, 최근 마이크로소프트가 서드파티 브라우저 지원을 허용하는 방향으로 정책을 바꾼 것이 주요 이유가 됐다. 최근까지 모든 웹 브라우저는 마이크로소프트가 자사 플랫폼에 사용한 엔진을 탑재할 것이 마이크로소프트 스토어 정책의 요구 조건이었기 때문이다. 정책 변경 후 모질라는 블로그를 통해 윈도우 스토어에도 우수한 게코(Gecko) 엔진을 탑재한 파이어폭스를 등록할 수 있게 됐다고 밝혔다.   스토어 앱에도 브라우저가 없었던 것은 아니다. 그러나 일반 사용자가 들어본 적이 없는 군소 브라우저 위주로 등록돼 있었고 이제 파이어폭스는 마이크로소프트 스토어에서 가장 유명한 브라우저 위치를 차지한다. 특히 윈도우 10과 11 홈 에디션 S 모드에서는 스토어 앱만 사용할 수 있고 웹 다운로드 방식으로 앱을 설치할 수 없기 때문에 중요한 변화다. 브레이브 브라우저 개발사는 아예 마이크로소프트 스토어를 포기하고 에픽 스토어로 옮겨갔다. 모질라는 과거에도 서드파티 브라우저 접근 폭을 넓혀야 한다는 목소리를 냈다. 2015년 윈도우 10 기본 앱 설정 기능이 바뀌었을 때는 마이크로소프트 CEO 사티야 나델라에게 공개 서한을 보내기도 했다. 파이어폭스 버전 91부터는 윈도우 11 기본 브라우저 앱으로 등록될 수 있게 설치 과정을 약간 변경했고, 기본 브라우저 앱을 설정하는 메뉴에서 .html, .htm, .pdf, .xht 같은 각 파일 형식마다 브라우저를 일일이 선택해야 하기 때문이다. 형식이나 확장자가 각기 다른데, ‘전체 파일’을 선택할 수 있는 옵션이 없어서 더욱 불편하다.    그러나 마이크로소프트 스토어에 파이어폭스가 추가돼도 기본 브라우저 앱을 등록할 때의 고충은 여전하다. 스토어로 파이어폭스를 다...

파이어폭스 마이크로소프트스토어 2021.11.10

'실전 예제로 보는' 자바 개발에서의 도커 사용법

개발 중 도커(Docker)를 사용할 때 얻는 이점은 개발 기기와 다양한 환경(QA, 프로덕션 등)에 걸쳐 일관적인 테스트 환경을 제공할 수 있다는 것이다. 반면 어려운 점도 있다. 도커 컨테이너로 인해 개발자가 코딩 중 관리해야 하는 부가적인 추상화 계층이 발생한다.  도커를 이용하면 애플리케이션 코드를 시스템 요구사항 정의와 함께 여러 플랫폼에서 실행 가능한 패키지로 묶을 수 있다. 소프트웨어 런타임 배포와 관리에서 근본적으로 필요한 부분을 해결하는 효과적인 추상화지만, 대신 프로그래머가 대처해야 하는 부가적인 간접성 계층이 발생해 소프트웨어와 그 종속 항목의 내부 구조를 반복적으로 수정하고 테스트해야 한다. 이러한 개발 속도 저하는 개발자가 가장 피하고 싶어하는 일이다. 이를 둘러싼 다양한 찬반 양론이 있다.   개발 기기 전반에서 본격적으로 도커를 사용하지 않는다고 해도 컨테이너 내에서 실행되는 코드를 수정, 디버깅하는 다양한 사례가 있다. 예를 들어 개발자는 도커를 사용해 프로덕션 환경을 똑같이 만들어 오류 또는 기타 조건을 재현할 수 있다. 또한 도커화된 앱을 실행하는 호스트에 대한 원격 디버깅 기능은 QA와 같이 실행 중인 환경에 대한 직접적인 문제 해결을 가능하게 해준다.  여기서는 구글 클라우드 플랫폼(GCP)에서 VM에 간단한 자바 앱을 만들어서 도커화한 다음 원격으로 디버깅하고, 로컬 호스트의 비주얼 스튜디오 코드에서 앱 코드를 수정하는 과정을 살펴보자. 실행할 2가지 중요한 작업은 컨테이너를 재시작하지 않고 실행 중인 코드베이스 업데이트하기, 그리고 실행 중인 컨테이너화된 앱 디버깅하기다. 또한 이 프로세스를 원격으로 실행되는 컨테이너에서 수행한다. 즉, 로컬 개발 호스트 외에 QA 서버와 같은 서비스를 원격으로 디버깅하는 방법도 살펴본다.   자바와 스프링 부트 설정하기 시작 지점은 GCP 콘솔이다(계정이 없다면 무료 계정 가입). 컴퓨트 엔진(Compute Engine) 링크로 이동하면 VM...

자바 도커 docker 2021.11.10

기업 내 개방 원칙 '이너 소스', 드디어 모멘텀을 형성하다

팀 오라일리가 처음 만든 개념인 이너 소스(Inner source)는 독자적인 사설 소프트웨어를 만들 때 조직 내부에 오픈소스 방식을 도입하는 것이 목적인 엔지니어링 원칙이다. 오픈소스의 ‘개방성’을 여러 조직의 여러 기여자들이 아닌 조직 내 모든 팀으로 확대한다. 오픈소스 공동체는 이너 소스 원칙을 통해 공통된 기법과 도구를 이용하게 된다. 각자의 1차적 책임은 아니지만 많은 기여자들이 서로 협력해 코드를 개발하는 방식이다. 일반적으로 공유 코드 리포지토리, 풀 요청, 코멘트, 기타 광범위한 도큐멘테이션을 사용한다. 소프트웨어 개발 방식을 현대화하고, 코드를 팀 책임 하에서 기밀로 유지해야 하는 지적 재산이 아닌, 협력적이고 재사용이 가능한 자산으로 보기 시작한 기존 기업 사이에서 갈수록 인기가 높아지고 있는 방법론이다. 또한 이너 소스 방식은 안전하고 투명한 방법으로 개발자가 풀 요청을 통해 변화를 추진할 수 있도록 도우므로 업스트림의 장애물도 없앤다.   이너 소스를 도입하려면 조직 문화를 크게 바꿔야 하지만, 코드의 품질, 신뢰도, 보안 향상이라는 장점이 따라온다. 또 오랜 사일로를 없애 협업 수준과 개발 속도를 높인다. 특히 팬데믹 기간에 그 중요성이 더욱 커진 분야다. 이너소스 커먼스 파운데이션(InnerSource Commons Foundation)의 다네스 쿠퍼는 Infoworld에 “이너 소스가 입증한 한 가지는 이질적인 팀 전반에 걸친 광범위한 피어(동료) 기반의 협업은 같은 공간과 시간대에 위치한 통제된 팀만큼 효과적이라는 점”이라고 말했다. 이너 소스로 이루어진 협업은 코로나19 기간 업무 추진에 중요한 역할을 했으며, 효과성을 증명하고 도입 촉진에도 영향을 미치고 있다. 이너 소스 기법을 도입한 3개 업체에서 이너 소스가 적합한 이유와 개발자의 성과에 어떤 긍정적 영향을 미쳤는지 들어보자.   블룸버그(Bloomberg) : 엔지니어가 원하는 변화를 실현하는 역량 이너 소스가 정착한 산업 분야 중 하...

이너소스 2021.11.05

“클라우드를 위한 카오스 엔지니어링” 애저 카오스 스튜디오 공개 프리뷰

마이크로소프트 애저(Azure) CTO 마크 루시노비치는 2021년 초 애저 아키텍처에 관한 정기적인 이그나이트(Ignite) 행사를 통해 애저 플랫폼의 결함 주입 툴인 카오스 스튜디오(Chaos Studio)를 공개했다. 넷플릭스가 도입한 카오스 몽키 개념을 기반으로 확산되고 있는 카오스 엔지니어링은 클라우드 규모의 애플리케이션이 실패할 때 정확히 어떤 일이 일어나는지를 개발자가 이해하는 데 도움이 된다.    이제 마이크로소프트는 더 탄력적이고 더 나은 클라우드 애플리케이션을 제공하는 것을 목표로 이번 2021년 2차 이그나이트 행사에서 카오스 스튜디오의 첫 공개 프리뷰 버전을 공개한다. 필자는 프리뷰 공개에 앞서 마크 루시노비치와 만나 카오스 엔지니어링에 대한 애저의 접근 방법과 개발자가 이런 기술을 활용하는 방법에 관해 이야기를 나눴다.    애저 클라우드에 혼돈 더하기  애저의 카오스 엔지니어링은 새로운 것은 아니다. 루시노비치는 “거의 시작부터 애저에서 자체적인 카오스 엔지니어링을 해왔다”고 말했다. 그러나 서비스가 성장하면서 한때 특정 팀에서만 사용하던 툴이 애저를 개발하는 모든 사람들에게 필요한 툴이 됐다. 루시노비치는 “지난 몇 년 동안 카오스 엔지니어링에 투입되는 노력을 서비스 전반에 적용할 수 있는 하나의 공통된 툴, 공통 프레임워크 서비스로 통합해야 한다는 것을 알고 있었다”고 말했다.  그 공통 툴이 카오스 스튜디오의 기반이 됐다. 루시노비치는 카오스 스튜디오가 시작은 내부 툴이었지만, 항상 고객 대면 애플리케이션이 될 것이라는 점을 염두에 뒀다고 강조했다. 고객에게 필요한 것과 마이크로소프트에 필요한 것은 다를 수 있지만, 마이크로소프트가 얻은 교훈은 스스로든 고객이든 모든 사용자 관점에서 애저를 더 개선하는 데 도움이 될 수 있다. 루시노비치는 “고객을 위해 운영되는 서비스의 혜택을 누리는 것 외에, 이를 기반으로 고객과 함께 생태계를 구축할 수 있다. 이 확장성을 통해 생태...

카오스엔지니어링 카오스스튜디오 애저 2021.11.04

소프트웨어 신뢰성 확보는 보안 강화의 지름길

지난 몇 년 간 소프트웨어 보안과 신뢰성은 비교 및 대조 대상이었다. 소프트웨어 보안과 신뢰성의 핵심 목표는 모두 기업 및 최종 사용자를 보호하는 것이다. 하지만 데브섹옵스(DevSecOps) 및 SRE(Site Reliability Engineering) 도입이 지속되고 성숙하면서 소프트웨어 보안과 신뢰성의 공통분모는 점차 커지고 있다. 그리고 기업은 데브섹옵스와 SRE를 적절히 수행했을 때 가치를 극대화할 수 있다.   사이버보안 부문에 종사했던 사람은 CIA(Confidentiality, Integrity, Availability)에 익숙하다. 특히 가용성(Availability) 관련 지표는 데브옵스와 이후 등장한 데브섹옵스로의 변화에서 중요한 요소다. DORA(Devops Research and Assessments)와 MTTR(Meantime to Recover), CFR(Change Failure Rate)이 대표적인 지표다. 제안된 변경사항이 실패해 가용성이 낮아지고 결과적으로 회복에 오랜 시간이 투입되면, 보안과 신뢰성 모두 위태로워진다.  기업은 데브옵스를 안전하게 도입해야 한다. 데브옵스 실태 보고서에 따르면, 데브옵스 도입 담당자는 가용성을 확보하기 위해 도입 속도를 늦추지는 않는다. 점차 많은 기업이 SRE 원칙을 도입하고 있으며, 고장 나거나 작동을 멈춘 시스템에서 배울 점을 찾아 취약한 시스템의 보안과 신뢰성을 높이고자 한다.  짧은 리드 타임이 보안을 강화한다 MTTR과 CFR의 관계는 명확하지만, 보안 관점에서 영향력이 높은 또 다른 DORA 지표가 존재한다. 바로 변화 지표를 위한 리드 타임으로, 작성한 코드를 프로덕션 단계에서 성공적으로 구현하는 데 걸리는 시간과 관련된 지표다. 일반적으로 기업 또는 최종 사용자에게 가치를 신속하게 전달하는 맥락에서 논의된다.  시스템 보안 업데이트를 신속하게 배치하는 것도 일종의 가치 제공이다. 프로덕션 시스템에서 안전하지 못한 구성요소나 취약점을...

데브옵스 데브섹옵스 보안 2021.11.03

기능 플래그로 개발하는 데브옵스 사례 5가지

오래 전 개발자로 일할 당시, 필자는 코드를 쓰고 애플리케이션을 빌드해 환경에 배포할 수 있게 해주는 플랫폼과 툴, 라이브러리를 최적화하는 일을 항상 즐겼다. 버전 제어에 컨커런트 버전 시스템(Concurrent Versions System)과 서브버전(SubVersion)을 사용하고 C++ 앱을 위한 makefile을 쓰고 아파치 앤트(Apache Ant) 스크립트를 개발해서 자바 앱을 패키징하고 온갖 유닉스 스크립트를 만들어 배포를 자동화했다. 지금은 깃과 젠킨스 등의 툴 덕분에 여러 필수적인 데브옵스 작업이 간편해졌고 많은 조직이 이와 같은 툴을 필수적인 소프트웨어 개발 툴로 간주한다.   당시 개발했던 몇 가지 뼈대가 지금은 상용 플랫폼이 되어 있다. 기능 플래그도 그중 하나인데, 아마 많은 조직이 이 기능을 거의 모르거나, 기초적인 방식으로만 사용 중일 것이다. 특히 마이크로서비스를 개발하고 고객 경험을 혁신하거나 레거시 애플리케이션을 현대화하는 기업에서 이는 큰 기회의 손실일 수 있다.   필자는 2020년 기능 플래그를 사용한 애자일 실험 방법에 대한 글에서 데브옵스 부서가 기능 플래그를 사용해 사용자 경험 실험을 관리하거나 배포된 기능을 런타임에 제어하는 방법에 초점을 두고 설명했다. 버전 제어 툴에 분기 전략을 구현하는 대신 기능 플래그를 사용해서 프로덕션 기능을 켜거나 끄는 편이 확장성과 관리 편의성 면에서 더 유리할 수 있다.   빌드와 A/B 테스트 기능에 무엇을 넣을지를 제어하는 것은 기능 플래그의 극히 일부에 불과하다. 런치다클리(LaunchDarky)의 공동 창업자이자 CTO인 존 코두멀과 이야기를 나눈 후, 기능 플래그가 애자일 개발 부서와 데브옵스 작업 방식, 소프트웨어 개발 역량을 어디로 이끄는지를 정리해야겠다고 생각했다.   코두멀은 기능 플래그가 데브옵스에 중요한 이유에 대해 “기능 플래그를 사용할 이유는 수없이 많지만, 가장 중요한 혜택은 큰 규모에서 속도 희생 없이 위험을 낮추는 데...

데브옵스 기능플래그 2021.11.03

프로그래밍 언어의 간단한 역사

프로그래밍 언어 개발은 컴퓨터의 기계어와 밀접하게 연관된다. 기계어는 이름에서 알 수 있듯이 기계가 실행할 수 있는 명령으로 된 언어다. 여기서 기계는 컴퓨터에 내장된 마이크로프로세서를 의미한다(CPU, 하드 디스크 컨트롤러 등). 프로세서는 특수한 기계 명령어에 따라 동작한다. 이와 같은 명령어가 결합되어 컴퓨터가 하나씩 명령을 실행할 수 있는 이진 기계 프로그램을 구성한다. 사람이 알아보기 어렵고, 개발하기는 더욱 어렵다.    어려운 개발을 용이하게 하기 위해 프로그래밍 언어와 텍스트 편집기, 변환 프로그램이 고안됐다. 첫 걸음은 1948년에 등장한 어셈블리(Assembly)이다. 프로그래머는 텍스트 편집기 안에서 어셈블리어 프로그램을 작성해서 텍스트 파일로 저장한다. 이 파일을 컴퓨터가 직접 실행할 수는 없으므로 중간에 어셈블러라는 보조 프로그램이 필요하다. 어셈블러는 이 파일, 즉 소스 코드를 기계 프로그램으로 변환한다(다음 그림 참조). 컴퓨터는 이렇게 해서 나온 이진수 기계 프로그램만 실행할 수 있다.  어셈블러 소스 코드는 기계어에 비해 이해하기 쉽다. 일련의 세부적인 명령으로 구성되기 때문에 명령의 수가 많고 장황하다. 따라서 간단한 hello world 프로그램도 파스칼과 같은 고수준 언어에 비하면 상당히 길다(다음 그림 참조). 큰 어셈블리어 프로그램을 작성하는 데는 오랜 시간이 걸린다. 또한 어셈블리어는 특정 프로세서에 연계되고 파스칼과 같은 고수준 언어에 비해 읽기가 어렵다. 장점은 잘 프로그램된 어셈블러 프로그램의 경우 실행 속도가 빠르고 메모리 및 하드 디스크 공간 사용량이 적다는 것이다.  이와 같은 확실한 장점이 있긴 하지만 열악한 가독성 및 유지보수 편의성, 낮은 개발자 생산성, 무엇보다 특정 하드웨어(마이크로프로세서)에 대한 의존성과 같은 단점이 너무 커서 불과 몇 년 후에 2세대 언어가 개발됐다. 가장 먼저 나온 고수준 언어는 포트란(Fortran)과 코볼(COBOL)이다. 포트란은...

프로그래밍 어셈블리 포트란 2021.11.02

앵귤러, Ng모듈 옵션화 검토…“개발자 경험에 부정적”

타입스크립트 기반 웹 애플리케이션 프레임워크 앵귤러(Angular) 개발팀이 앵귤러의 기본 메커니즘인 Ng모듈(NgModules)을 옵션으로 전환하는 방안을 검토하고 있다. 앵귤러를 간편한 재사용 모델로 개선해 개발자 경험 품질을 높이기 위해서다.   이번 RFC 제안은 ‘독립형 컴포넌트, 디렉티브 및 파이프 - Ng모듈 옵션으로 만들기(Standalone components, directives and pipes - making Angular’s NGModules optional)’라는 제목으로 깃허브에 게재됐다. 현재 앵귤러는 사용자 커뮤니티와 함께 설계 타당성을 검토하고 의견을 취합하고 있으며, 비 프로덕션 레디 프로토타입(non-production-ready prototype)으로 테스트할 수 있다. 의견 취합은 오는 8일까지 진행된다. Ng모듈은 기능을 하나로 묶어 프레임워크 종속성을 관리하는 앵귤러의 핵심 개념이다. 예컨대 하나의 컴포넌트가 다른 컴포넌트, 디렉티브, 파이프, 혹은 서비스를 활용해야 할 때, 종속성을 직접 참조하는 대신 필요한 요소가 포함된 Ng모듈을 불러온다. 때문에 개발자는 “Hello World”를 모니터에 띄우는 가장 간단한 프로그래밍을 할 때도 반드시 Ng모듈을 생성해야 한다. RFC 제안자는 Ng모듈이 개념적으로 앵귤러의 중심이 되면 개발자 경험에 부정적인 영향을 미친다고 주장했다. 이유는 다음과 같다.   컴포넌트 작성은 클래스나 템플릿 코딩보다 어렵다. 로딩이나 렌더링과 관련된 API가 불필요하게 복잡하며 오용하기 쉽다. 컴포넌트 코드 읽기로는 컴포넌트 행동을 충분히 이해하기 어렵다. 앵귤러 도구는 Ng모듈 문맥에 ‘내재된’ 컴포넌트 종속성을 반드시 다뤄야 한다. RFC가 제안하는 것은 컴포넌트, 디렉티브, 파이프가 앵귤러에서 핵심적인 역할을 하도록 독립성을 부여하고, 안전하게 직접 사용할 수 있는 방향으로 개선하는 방법이다. 앵귤러의 ‘멘털 모델(mental model)’을 간소화...

앵귤러 ng모듈 2021.11.01

"마이크로서비스 기반의 앱을 위한 데브섹옵스 구현" NIST 새 가이드

미국 연방정부도 민간 기업과 마찬가지로 클라우드, 데브섹옵스(Devsecops), 그리고 클라우드 네이티브 애플리케이션을 위한 마이크로서비스 기반 아키텍처로 전환하는 중이다. 미국표준기술연구원(NIST)은 업계가 모범사례를 채택할 수 있도록 표준과 가이드를 제공한다.    이를 위해 NIST는 지난 9월 서비스 메시(Service Mesh)를 사용한 마이크로서비스 기반 애플리케이션을 위한 데브섹옵스 구현을 발표했다(800-204C). 이 문서는 데브섹옵스 구현, 그리고 마이크로서비스 아키텍처에 클라우드 네이티브 애플리케이션을 호스팅하기 위한 서비스 메시를 사용한 참조 플랫폼 사용에 관한 포괄적인 가이드다. 이는 현재 초안 형식이며, 전 미공군 최고 소프트웨어 책임자인 니콜라스 챌라인과 서비스 메시 분야 선두업체인 테트레이트(Tetrate)의 협업으로 작성됐다. 이 가이드는 성공적인 데브섹옵스 구현을 위한 구성 요소라고 할 수 있는 프리미티브(primitive) 개념을 사용했다. 데브섹옵스 프리미티브는 민첩한 개발을 위한 마이크로서비스 기반 애플리케이션에 가장 적합하다. 또한 데브섹옵스가 클라우드 네이티브 애플리케이션에 필요한 비즈니스 민첩성 요구사항을 촉진한다는 개념도 지원한다. 다음은 NIST 가이드의 각 세션의 내용을 분석했다.   데브섹옵스 프리미티브 구현을 위한 참조 플랫폼 이 가이드는 컨테이너 오케스트레이션과 관리 플랫폼 맥락에서 참조 플랫폼을 다룬다. 예를 들어 분류된 또는 연결이 끊긴 엄격한 환경(물리적) 또는 AWS, 애저와 같은 클라우드 서비스 제공업체(CSP) 환경과 같은 가상화된 환경 등 물리적 또는 가상 기반 인프라 위에 구축하는 방식이다. 가이드는 컨테이너 오케스트레이션 및 리소스 관리 플랫폼 사용을 권장한다. 가장 인기 있는 오픈소스 컨테이너 오케스트레이션 플랫폼인 쿠버네티스(Kubernetes)가 대표적이다. 쿠버네티스는 컨테이너화된 애플리케이션을 호스팅하는 팟(pod)을 기반으로 물리적 ...

데브섹옵스 NIST Devsecops 2021.10.29

리눅스와 맥에서 홈브루를 이용해 패키지를 설치하는 방법

홈브루(Homebrew)에 대해 들어본 적이 있는가? 독특한 기능을 가진 패키지 매니저다. 이를 이용하면 일반 사용자가 sudo를 사용하지 않고도 패키지를 설치할 수 있다. 맥과 리눅스 모두에서 사용할 수 있는 것은 물론이다. 맥 버전은 홈브루라고 부르고, 리눅스 버전은 리눅스브루(linuxbrew)로 설치된다.   일단 설치하면 사용자가 홈브루의 브루 명령어를 이용해 패키지를 매우 쉽게 설치할 수 있다. 그러나 홈브루 자체를 설치하는 것은 보통 sudo 권한이 필요하며 /home/linuxbrew 위치에 설치된다.   홈브루의 장점 홈브루는 다음과 같은 장점이 있다.   사용하기 매우 쉽고, 편리하고 유연하게 리눅스 툴을 설치할 수 있다. sudo 없이도 패키지를 설치한다. 맥OS와 리눅스에서 쓸 수 있다. 시스템을 업데이트하거나 설치를 준비하려면 다음 명령어를 실행하면 된다.   $ sudo dnf update $ sudo dnf groupinstall ‘Development Tools’ && sudo dnf install curl file git $ sudo dnf install libxcrypt-compat 이들 작업을 마치려면 잠시 시간이 걸린다. 특히 최근 업데이트하지 않았지만 더 그렇다. 이제 홈브루를 /home/linuxbrew/.linuxbrew에 설치하기 위해 다음 명령을 실행한다.   $ /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)” 이 명령을 실행하면 암호를 입력하도록 한다. 테스트해보려면 다음과 같은 명령으로 툴을 설치할 수 있다.   $ brew install fortune Updating Homebrew... ==> Homebrew is run entirely by unpaid volunteers. Please consi...

홈브루 homebrew 2021.10.29

'차세대 LAMP 스택 노린다' 개츠비의 멈출 수 없는 기세

웹사이트가 다시 과거 시대로 돌아간 것 같다. 여기서 과거는 멋진 과거다. 웹사이트의 시작은 간단한 정적 사이트 생성기(SSG)였지만 데이터 기반 접근 방식이 도입되면서 점점 더 동적인 웹사이트가 만들어졌다. 이후 워드프레스(WordPress), 드루팔(Drupal), 어도비 익스피리언스 매니저(Adobe Experience Manager)와 같은 콘텐츠 관리 시스템(CMS)이 등장해 간단한 블로그부터 온라인 카탈로그까지 기업 사이트 구축을 위해 필요한 모든 기능을 제공했다. SSG는 이제 퇴장하는 것만 남은 듯했다.   실제로 SSG는 거의 사라지다시피 했다. 어느 날 솜씨 좋은 개발자가 개츠비JS(GatsbyJS)와 같은 시스템에서 비약적인 성능 개선 방법을 찾아내기 전까지 말이다. 이에 따라 느린 빌드 시간이라는 SSG의 아킬레스건이 사라졌고, 결과적으로 SSG는 크고 작은 웹사이트를 위한 기술로 재부상했다. 이것이 최근 나온 개츠비JS 4 릴리스에서 서버 측 렌더링이 가능해진 점과 더불어 2가지 핵심적인 변화다. 개츠비는 차세대 LAMP 스택(리눅스, 아파치, 마이SQL, PHP)의 도래로 이어질 수 있다. 잼스택(Jamstack: 자바스크립트, API, 마크업)으로 불리는 이 아키텍처는 개발자에게 가볍고 접근성이 높은 웹 빌드 방법을 제공한다. 물론 쉽게 만든다고 해서 무조건 유용한 것은 아닌데, 개츠비의 역할이 여기에 있다. 이것은 개츠비의 CEO 잭 얼로커가 가장 크게 기대하는 부분이기도 하다.   무거운 CMS에서 탈출 다음 LAMP 스택 물결에 LAMP 시대의 핵심 인물이 관여한다는 사실은 어떻게 보면 자연스럽다. 잭 얼로커는 LAMP에서 ‘M’에 해당하는 마이SQL용 제품으로 처음 이름을 알렸다. 최근 개츠비 CEO로 선임됐지만 사실 꽤 오래전부터 그 역할을 해오고 있었다. 얼로커는 젊은 개발자가 잼스택으로의 빠른 전환을 이끌고 있음을 강조했다. 이유가 무엇일까? 이들은 CMS의 프론트엔드와 백엔드 데이터베이스 등을 채...

개츠비 잼스택 2021.10.28

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

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

Copyright © 2022 International Data Group. All rights reserved.