Offcanvas

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

백엔드 개발자 경험을 위한 솔루션 열전

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

개발자경험 백엔드 오픈소스 YAML 코드형인프라. IaC 클라우드네이티브 데브옵스

2022.05.11

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

2022.05.11

'CI/CD란?' 알기 쉽게 설명한 지속적 통합과 지속적 전달

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

CI/CD 지속적통합 지속적제공 데브옵스 애자일

2022.04.21

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

2022.04.21

벤더 기고ㅣ비즈니스를 위한 IT의 새로운 역할, 지원 부서에서 비즈니스 혁신을 위한 핵심 조직으로

비즈니스의 핵심은 고객가치의 이해에 있다. 어떤 기업이든 비즈니스에 있어서 고객이 혁신적인 아이디어를 발굴하고 제품화하여 경쟁 제품과 차별화할 수 있는 솔루션을 제공할 수 있는 전략이 필요하다. 이러한 전략은 고객이 진정으로 원하는 바를 이해하는 것에서부터 출발한다. 또한 기업이 제공하고자 하는 제품과 서비스를 고객의 니즈와 일치시킬수 있어야 한다. 이러한 과정은 결국 기업이 제공하고자 하는 제품이나 서비스의 특징 보다는 고객이 원하는 가치를 이해 하는 데에 더 많은 노력을 기울여야 함을 의미한다.  고객이 중시하는 가치와 IT 역할의 상관관계는 꽤 오랜 시간 이야기돼 왔다. 오늘날 비즈니스 가치 창출과도 직결되는 IT의 역할은 어떠해야 할까? 이 글을 통해 IT 리더십의 역할과 민첩성을 바탕으로 기업과 IT 조직의 관계를 재정의하여 이러한 가치를 극대화 할 수 있는 방법에 대해 이야기해보고자 한다.     고객 가치는 현업과 IT가 함께 생각해야 한다 대부분의 기업의 이해 관계자가 가지고 있는 가장 큰 오해 중 하나는 이미 고객을 잘 알고 있다고 생각하는 것이다. 현업 부서는 자신의 생각이 고객의 생각과 일치하고 있다는 착각을 바탕으로 현업 부서의 요구사항 또는 비즈니스의 요구사항(Business Requirement)을 다른 협업 부서에 전달하게 된다. 보통 기업내에서 IT 조직을 바라볼 때, 이런 비즈니스의 요구사항(Business Requirement)을 충족 시키기 위한 내부의 “고객-공급업체” 관계 모델, 즉 본질적으로 요구사항을 충족해주는 조직으로만 생각하는 경향이 많다. 그러나 이는 심각한 문제의 시작이 될 수 있다.  이러한 관점에서는 IT 기능을 아웃소싱하는 것이 너무나 당연해 보인다. IT는 이미 정해져 있는 비즈니스의 요구 사항에 대한 기능 구현이므로 정해진 시간과 비용으로 만들어 내야 하는 업무임은 물론, 핵심 비즈니스(core business) 활동으로도 인식되지 않기 때문에 아웃소싱이 효과적...

클라우드 AWS 혁신 IT 리더십 데브옵스

2022.04.01

비즈니스의 핵심은 고객가치의 이해에 있다. 어떤 기업이든 비즈니스에 있어서 고객이 혁신적인 아이디어를 발굴하고 제품화하여 경쟁 제품과 차별화할 수 있는 솔루션을 제공할 수 있는 전략이 필요하다. 이러한 전략은 고객이 진정으로 원하는 바를 이해하는 것에서부터 출발한다. 또한 기업이 제공하고자 하는 제품과 서비스를 고객의 니즈와 일치시킬수 있어야 한다. 이러한 과정은 결국 기업이 제공하고자 하는 제품이나 서비스의 특징 보다는 고객이 원하는 가치를 이해 하는 데에 더 많은 노력을 기울여야 함을 의미한다.  고객이 중시하는 가치와 IT 역할의 상관관계는 꽤 오랜 시간 이야기돼 왔다. 오늘날 비즈니스 가치 창출과도 직결되는 IT의 역할은 어떠해야 할까? 이 글을 통해 IT 리더십의 역할과 민첩성을 바탕으로 기업과 IT 조직의 관계를 재정의하여 이러한 가치를 극대화 할 수 있는 방법에 대해 이야기해보고자 한다.     고객 가치는 현업과 IT가 함께 생각해야 한다 대부분의 기업의 이해 관계자가 가지고 있는 가장 큰 오해 중 하나는 이미 고객을 잘 알고 있다고 생각하는 것이다. 현업 부서는 자신의 생각이 고객의 생각과 일치하고 있다는 착각을 바탕으로 현업 부서의 요구사항 또는 비즈니스의 요구사항(Business Requirement)을 다른 협업 부서에 전달하게 된다. 보통 기업내에서 IT 조직을 바라볼 때, 이런 비즈니스의 요구사항(Business Requirement)을 충족 시키기 위한 내부의 “고객-공급업체” 관계 모델, 즉 본질적으로 요구사항을 충족해주는 조직으로만 생각하는 경향이 많다. 그러나 이는 심각한 문제의 시작이 될 수 있다.  이러한 관점에서는 IT 기능을 아웃소싱하는 것이 너무나 당연해 보인다. IT는 이미 정해져 있는 비즈니스의 요구 사항에 대한 기능 구현이므로 정해진 시간과 비용으로 만들어 내야 하는 업무임은 물론, 핵심 비즈니스(core business) 활동으로도 인식되지 않기 때문에 아웃소싱이 효과적...

2022.04.01

도커 공동창업자가 만든 데브옵스 플랫폼 ‘대거’··· 공개 베타 시작

지난 2008년 컨테이너 소프트웨어 회사 ‘도커(Docker)’를 설립해 2018년 퇴사했던 공동창업자 솔로몬 하이크가 오랜 준비 기간을 걸쳐 마침내 ‘대거(Dagger)’를 공개적으로 출시했다.    도커 공동창업자 솔로몬 하이크, 전 도커 엔지니어링 부사장 샘 알바, 전 도커 수석 아키텍트 안드레아 루자디가 약 3년 전 만든 스타트업 ‘대거’는 엔지니어가 (어디서나 실행할 수 있는) 사전 정의된 구성요소 카탈로그에서 자체 CI/CD 파이프라인을 구축할 수 있게 하여 개발자가 다양한 배포 작업을 자동화할 수 있도록 지원하는 것을 목표로 한다.  공개 베타 버전 출시와 동시에 대거는 레드포인트 벤처스(Redpoint Ventures)가 주도하고 와이 콤비네이터(Y Combinator), 전 깃허브 CEO 냇 프리드먼, 전 구글 클라우드 CTO 브라이언 스티븐스, 전 레딧 CEO 엘렌 파오, 솔로닷아이오 창업자 이디트 레빈, 비트나미(Bitnami) 공동창업자 대니얼 로파즈, 프로메테우스 창시자 줄리어스 볼츠 등 업계 거물급 인사들이 참여한 2,000만 달러의 시리즈 A 라운드 투자를 유치했다.  대거는 이 투자금을 팀을 성장시키고, 오픈소스 커뮤니티 개발자의 관심을 높이는 데 활용할 계획이라고 밝혔다. 이 회사는 이전에 프리시드 및 시드펀딩을 합쳐 1,000만 달러를 모금한 바 있다.  하이크는 “거의 모든 컴퓨팅이 클라우드로 이동하면서 소프트웨어 공급망이 너무 크고 복잡해져서 심각한 병목 현상이 발생했다”라며, “이렇게 증가하는 복잡성으로 인해 다양한 전문 도구를 활용할 수 있는 데브옵스 엔지니어가 (자체) 파이프라인 연결에 시간을 낭비하고 있다. 이를 해결하는 것이 데브옵스의 성배이며, 대거가 이 문제를 해결했다고 믿는다”라고 말했다. ciokr@idg.co.kr

도커 데브옵스 대거 컨테이너 CI/CD

2022.03.31

지난 2008년 컨테이너 소프트웨어 회사 ‘도커(Docker)’를 설립해 2018년 퇴사했던 공동창업자 솔로몬 하이크가 오랜 준비 기간을 걸쳐 마침내 ‘대거(Dagger)’를 공개적으로 출시했다.    도커 공동창업자 솔로몬 하이크, 전 도커 엔지니어링 부사장 샘 알바, 전 도커 수석 아키텍트 안드레아 루자디가 약 3년 전 만든 스타트업 ‘대거’는 엔지니어가 (어디서나 실행할 수 있는) 사전 정의된 구성요소 카탈로그에서 자체 CI/CD 파이프라인을 구축할 수 있게 하여 개발자가 다양한 배포 작업을 자동화할 수 있도록 지원하는 것을 목표로 한다.  공개 베타 버전 출시와 동시에 대거는 레드포인트 벤처스(Redpoint Ventures)가 주도하고 와이 콤비네이터(Y Combinator), 전 깃허브 CEO 냇 프리드먼, 전 구글 클라우드 CTO 브라이언 스티븐스, 전 레딧 CEO 엘렌 파오, 솔로닷아이오 창업자 이디트 레빈, 비트나미(Bitnami) 공동창업자 대니얼 로파즈, 프로메테우스 창시자 줄리어스 볼츠 등 업계 거물급 인사들이 참여한 2,000만 달러의 시리즈 A 라운드 투자를 유치했다.  대거는 이 투자금을 팀을 성장시키고, 오픈소스 커뮤니티 개발자의 관심을 높이는 데 활용할 계획이라고 밝혔다. 이 회사는 이전에 프리시드 및 시드펀딩을 합쳐 1,000만 달러를 모금한 바 있다.  하이크는 “거의 모든 컴퓨팅이 클라우드로 이동하면서 소프트웨어 공급망이 너무 크고 복잡해져서 심각한 병목 현상이 발생했다”라며, “이렇게 증가하는 복잡성으로 인해 다양한 전문 도구를 활용할 수 있는 데브옵스 엔지니어가 (자체) 파이프라인 연결에 시간을 낭비하고 있다. 이를 해결하는 것이 데브옵스의 성배이며, 대거가 이 문제를 해결했다고 믿는다”라고 말했다. ciokr@idg.co.kr

2022.03.31

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

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

기고 | '대규모 마이크로서비스 구축 및 실행은...' 프라이스라인의 앱 현대화

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

마이크로서비스 데브옵스 컨테이너 쿠버네티스 12요소 모노리포 종속성 프라이스라인

2022.02.28

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

2022.02.28

‘마이크로 매니징은 해법 아니다’ 개발자 관리 방안 7가지

우수한 개발자들은 조직의 미세 관리(Micro management)를 못 견뎌 하는 경향을 가진다. 여기 개발자의 반발을 사지 않고도 개발팀의 성과와 비즈니스 목표를 정렬할 수 있도록 해주는 7가지 방안을 정리했다.    올해 들어 유독 자주 받은 질문이 있다. 하이브리드 근무 모델을 도입할 때 소프트웨어 개발자의 생산성, 품질, 성과를 어떻게 측정할 지와 관련된 것들이었다. 경영진이라면 해야 할 고민이기는 하다. 그러나 유능한 소프트웨어 개발자를 고용해 유지하기가 쉽지 않은 현실을 직시할 필요가 있다. 유능한 소프트웨어 개발자는 미시적 관리를 달가워하지 않을 것이며, 마이크로 매니지먼트 문화가 없는 곳으로 떠날 가능성이 크다. 개발 경험이 전무한 관리자에게 보고하도록 개발자에게 주문한다면 업무 관료주의에 대한 공포가 촉발된다. 자율성 원리를 옹호하는 소프트웨어 개발자는 전적인 자율을 원하고 경영진이 생산성, 품질, 여타 성과 고려사항을 측정하려 드는 어떤 징후에든 반발할 것이다. 소프트웨어 개발자들은 으레 마이크로 매니지먼트를 혐오한다. 또 다수의 소프트웨어 개발자가 연간 성과 리뷰를 경멸한다. 개발자 대부분은 실시간 성과 목표를 추구하고, 속도, 코드 개발 빈도, 순환 시간, 여타 핵심 성과 지표를 개선하려고 노력한다. 스크럼 팀은 스프린트가 종결될 때마다 성과를 논의하기 때문에 연간 및 분기 성과 리뷰 작업이 불필요하거나 무의미해 보이기 쉽다. 그러나 조직으로서는 가만히 맡겨둘 수 없다. 애자일 팀 및 소프트웨어 개발자가 성과, 개발, 사업 목표를 충족했거나 초과했는지를 인식할 방법이 있어야 한다는 실체적 현실 역시 존재한다. 매니저는 어떻게 하면 개발자를 괴롭히지 않으면서 자신이 필요한 것을 얻어낼 수 있을까?  아래에서는 애자일, 스크럼, 데브옵스 원리, 그리고 소프트웨어 개발 수명주기에 합치하고, 아울러 소프트웨어 개발자를 평가할 때 적용할 수 있는 7가지 권장 관행을 살펴본다. 필자가 이를 SMART 목표로...

마이크로 매니저 미세 관리 개발자 성과 개발팀 관리 애자일 데브옵스 관료주의

2022.02.16

우수한 개발자들은 조직의 미세 관리(Micro management)를 못 견뎌 하는 경향을 가진다. 여기 개발자의 반발을 사지 않고도 개발팀의 성과와 비즈니스 목표를 정렬할 수 있도록 해주는 7가지 방안을 정리했다.    올해 들어 유독 자주 받은 질문이 있다. 하이브리드 근무 모델을 도입할 때 소프트웨어 개발자의 생산성, 품질, 성과를 어떻게 측정할 지와 관련된 것들이었다. 경영진이라면 해야 할 고민이기는 하다. 그러나 유능한 소프트웨어 개발자를 고용해 유지하기가 쉽지 않은 현실을 직시할 필요가 있다. 유능한 소프트웨어 개발자는 미시적 관리를 달가워하지 않을 것이며, 마이크로 매니지먼트 문화가 없는 곳으로 떠날 가능성이 크다. 개발 경험이 전무한 관리자에게 보고하도록 개발자에게 주문한다면 업무 관료주의에 대한 공포가 촉발된다. 자율성 원리를 옹호하는 소프트웨어 개발자는 전적인 자율을 원하고 경영진이 생산성, 품질, 여타 성과 고려사항을 측정하려 드는 어떤 징후에든 반발할 것이다. 소프트웨어 개발자들은 으레 마이크로 매니지먼트를 혐오한다. 또 다수의 소프트웨어 개발자가 연간 성과 리뷰를 경멸한다. 개발자 대부분은 실시간 성과 목표를 추구하고, 속도, 코드 개발 빈도, 순환 시간, 여타 핵심 성과 지표를 개선하려고 노력한다. 스크럼 팀은 스프린트가 종결될 때마다 성과를 논의하기 때문에 연간 및 분기 성과 리뷰 작업이 불필요하거나 무의미해 보이기 쉽다. 그러나 조직으로서는 가만히 맡겨둘 수 없다. 애자일 팀 및 소프트웨어 개발자가 성과, 개발, 사업 목표를 충족했거나 초과했는지를 인식할 방법이 있어야 한다는 실체적 현실 역시 존재한다. 매니저는 어떻게 하면 개발자를 괴롭히지 않으면서 자신이 필요한 것을 얻어낼 수 있을까?  아래에서는 애자일, 스크럼, 데브옵스 원리, 그리고 소프트웨어 개발 수명주기에 합치하고, 아울러 소프트웨어 개발자를 평가할 때 적용할 수 있는 7가지 권장 관행을 살펴본다. 필자가 이를 SMART 목표로...

2022.02.16

때로는 혼란이 보약··· 데브섹옵스팀에 '카오스 엔지니어링'이 필요한 이유

‘카오스(chaos)’와 ‘엔지니어링’이라는 단어는 보통 잘 어울리지 않는다. 훌륭한 엔지니어는 결과적으로 혼란(chaos)스러운 상황을 멀리하기 때문이다. 그러나 최근에는 여러 소프트웨어 개발자가 숨겨진 결함을 드러냄으로써 컴퓨터 시스템을 강화하기 위해 적당한 수준의 ‘카오스’를 사용한다. 카오스 특성상 결과가 보장되지는 않으므로 완벽한 방법은 아니지만, 의외로 효과적인 경우가 많다.   카오스 엔지니어링은 문서화되지 않고 예측할 수 없는 백도어를 찾아야 하는 보안 애널리스트에게 특히 유용하다. 카오스 테스트로 모든 보안 문제를 찾을 수는 없지만, 개발자가 생각하지 못한 패치하지 않은 위험한 취약점을 발견할 수 있다. 좋은 카오스 엔지니어링은 데브섹옵스팀과 데브옵스팀에 모두 도움이 된다. 안정성 또는 탄력성 문제가 곧 보안 문제로 이어지는 경우도 있고, 동일한 코딩 실수가 전체 시스템 중단이나 사이버 공격자의 침입으로 이어질 수 있어서다. 카오스 엔지니어링이란? ‘카오스 엔지니어링’은 성공적인 결과가 입증된 여러 기법을 통칭하는 신조어다. 컴퓨터 시스템을 비틀어 균형을 무너뜨리고 멈추게 만들기도 하므로 ‘퍼징(fuzzing)’이나 ‘글리칭(glitching)’이라는 용어를 사용하기도 한다. 카오스 엔지니어링은 소프트웨어에 스트레스를 가하는 무작위 행동을 주입한 후 오작동이나 버그가 나타나는지 주의 깊게 관찰하는 방법이다. 정상적인 사용 환경에서는 발견까지 몇 년이 걸리는 문제를 카오스 엔지니어링으로 비교적 짧은 시간 안에 발견하는 경우가 많다.  EFF(Electronic Freedom Foundation) 공동 설립자 존 길모어는 “코딩은 지속적인 개선 과정이며 카오스 엔지니어링은 가능한 모든 실행 경로를 찾는 속도를 높이는 대표적인 방법이다. 오랜 기간 실행되는 코드는 해당 코드를 처음 실행하는 1,000만 명의 사용자, 코드를 처음 컴파일하는 20개의 컴파일러, 그리고 코드를 처음 실행하는 5개의 운영체제를 통해 대부분의 버그...

카오스엔지니어링 취약점발견 개발 데브섹옵스 데브옵스

2022.01.25

‘카오스(chaos)’와 ‘엔지니어링’이라는 단어는 보통 잘 어울리지 않는다. 훌륭한 엔지니어는 결과적으로 혼란(chaos)스러운 상황을 멀리하기 때문이다. 그러나 최근에는 여러 소프트웨어 개발자가 숨겨진 결함을 드러냄으로써 컴퓨터 시스템을 강화하기 위해 적당한 수준의 ‘카오스’를 사용한다. 카오스 특성상 결과가 보장되지는 않으므로 완벽한 방법은 아니지만, 의외로 효과적인 경우가 많다.   카오스 엔지니어링은 문서화되지 않고 예측할 수 없는 백도어를 찾아야 하는 보안 애널리스트에게 특히 유용하다. 카오스 테스트로 모든 보안 문제를 찾을 수는 없지만, 개발자가 생각하지 못한 패치하지 않은 위험한 취약점을 발견할 수 있다. 좋은 카오스 엔지니어링은 데브섹옵스팀과 데브옵스팀에 모두 도움이 된다. 안정성 또는 탄력성 문제가 곧 보안 문제로 이어지는 경우도 있고, 동일한 코딩 실수가 전체 시스템 중단이나 사이버 공격자의 침입으로 이어질 수 있어서다. 카오스 엔지니어링이란? ‘카오스 엔지니어링’은 성공적인 결과가 입증된 여러 기법을 통칭하는 신조어다. 컴퓨터 시스템을 비틀어 균형을 무너뜨리고 멈추게 만들기도 하므로 ‘퍼징(fuzzing)’이나 ‘글리칭(glitching)’이라는 용어를 사용하기도 한다. 카오스 엔지니어링은 소프트웨어에 스트레스를 가하는 무작위 행동을 주입한 후 오작동이나 버그가 나타나는지 주의 깊게 관찰하는 방법이다. 정상적인 사용 환경에서는 발견까지 몇 년이 걸리는 문제를 카오스 엔지니어링으로 비교적 짧은 시간 안에 발견하는 경우가 많다.  EFF(Electronic Freedom Foundation) 공동 설립자 존 길모어는 “코딩은 지속적인 개선 과정이며 카오스 엔지니어링은 가능한 모든 실행 경로를 찾는 속도를 높이는 대표적인 방법이다. 오랜 기간 실행되는 코드는 해당 코드를 처음 실행하는 1,000만 명의 사용자, 코드를 처음 컴파일하는 20개의 컴파일러, 그리고 코드를 처음 실행하는 5개의 운영체제를 통해 대부분의 버그...

2022.01.25

깃랩, 데브옵스 플랫폼 확장한다… 오픈소스 관측 솔루션 ‘옵스트레이스’ 인수

깃랩이 1월 11일 오픈소스 관측(Observability) 솔루션 업체 ‘옵스트레이스’를 인수했다고 밝혔다.  깃랩은 옵스트레이스 인수를 통해 전체 데브옵스 라이프사이클을 위한 단일 사용자 인터페이스와 통합 데이터 저장소 및 보안 기능을 갖춘 단일 애플리케이션 내에 오픈소스 관측 솔루션을 통합할 계획이라고 설명했다.  깃랩은 모니터링 및 관측 기능을 확장함으로써 기업들에게 새로운 선택권을 제공할 수 있을 것으로 기대하고 있다. 이를 통해 기업들은 더 이상 조직의 목표에 부합하지 않는 고가의 SaaS 서비스나 오픈소스 구성요소를 이용해 연결해야 하는 DIY(Do-It-Yourself) 관측 솔루션 중 하나를 선택할 필요가 없게 되었다. 깃랩은 이번 인수를 통해 깃랩 데브옵스 플랫폼 내에 구축된 즉시 사용 가능한 신뢰할 수 있는 통합 관측 플랫폼을 제공할 예정이다. 이번 인수를 통해 깃랩은 기업들이 사고율을 낮추고 개발자의 생산성을 높이는 것은 물론, MTTR(Mean-Time-to-Resolution)을 단축할 수 있도록 깃랩 데브옵스 플랫폼에 구성이 필요 없는 관측 솔루션을 구현함으로써 개발자 경험에 중점을 둔 강력한 모니터링 및 관측 기능을 제공하는데 주력할 방침이다.  깃랩은 옵스트레이스 기능을 모니터링 단계에 통합함으로써 코드 계측 유도 및 최근 성능 저하에 대한 통찰력은 물론, 병합요청 검토 환경의 성능 피드백과 성능 개선, 자동 구축 롤백, 사고 발생 시 신속한 탐색 및 분류를 가능하게 하는 예측 기능을 제공해 더 나은 개발자 경험을 창출하고, 긍정적인 비즈니스 결과를 도출할 수 있을 것으로 기대하고 있다. 깃랩의 최고제품책임자(CPO)인 스캇 윌리엄슨은 “더 많은 개발자들이 배포에 대한 안전성을 확보하고, 운영 중단을 신속하게 완화할 수 있는 통합 오픈소스 플랫폼에 액세스할 수 있도록 지속적으로 개발자 및 운영자 커뮤니티를 육성해 관측 경험을 개선시켜 나갈 것”이라고 밝혔다. 옵스트레이스 공동 설립이자 현재...

깃랩 옵스트레이스 데브옵스

2022.01.11

깃랩이 1월 11일 오픈소스 관측(Observability) 솔루션 업체 ‘옵스트레이스’를 인수했다고 밝혔다.  깃랩은 옵스트레이스 인수를 통해 전체 데브옵스 라이프사이클을 위한 단일 사용자 인터페이스와 통합 데이터 저장소 및 보안 기능을 갖춘 단일 애플리케이션 내에 오픈소스 관측 솔루션을 통합할 계획이라고 설명했다.  깃랩은 모니터링 및 관측 기능을 확장함으로써 기업들에게 새로운 선택권을 제공할 수 있을 것으로 기대하고 있다. 이를 통해 기업들은 더 이상 조직의 목표에 부합하지 않는 고가의 SaaS 서비스나 오픈소스 구성요소를 이용해 연결해야 하는 DIY(Do-It-Yourself) 관측 솔루션 중 하나를 선택할 필요가 없게 되었다. 깃랩은 이번 인수를 통해 깃랩 데브옵스 플랫폼 내에 구축된 즉시 사용 가능한 신뢰할 수 있는 통합 관측 플랫폼을 제공할 예정이다. 이번 인수를 통해 깃랩은 기업들이 사고율을 낮추고 개발자의 생산성을 높이는 것은 물론, MTTR(Mean-Time-to-Resolution)을 단축할 수 있도록 깃랩 데브옵스 플랫폼에 구성이 필요 없는 관측 솔루션을 구현함으로써 개발자 경험에 중점을 둔 강력한 모니터링 및 관측 기능을 제공하는데 주력할 방침이다.  깃랩은 옵스트레이스 기능을 모니터링 단계에 통합함으로써 코드 계측 유도 및 최근 성능 저하에 대한 통찰력은 물론, 병합요청 검토 환경의 성능 피드백과 성능 개선, 자동 구축 롤백, 사고 발생 시 신속한 탐색 및 분류를 가능하게 하는 예측 기능을 제공해 더 나은 개발자 경험을 창출하고, 긍정적인 비즈니스 결과를 도출할 수 있을 것으로 기대하고 있다. 깃랩의 최고제품책임자(CPO)인 스캇 윌리엄슨은 “더 많은 개발자들이 배포에 대한 안전성을 확보하고, 운영 중단을 신속하게 완화할 수 있는 통합 오픈소스 플랫폼에 액세스할 수 있도록 지속적으로 개발자 및 운영자 커뮤니티를 육성해 관측 경험을 개선시켜 나갈 것”이라고 밝혔다. 옵스트레이스 공동 설립이자 현재...

2022.01.11

블로그ㅣ‘개발자 경험’이 2022년에 가져올 변화

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

개발자 개발자 경험 소프트웨어 개발 쿠버네티스 데브옵스 플랫폼 엔지니어링 SRE

2022.01.03

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

2022.01.03

지속적 배포의 핵심 전략··· ‘카나리 릴리즈’ 살펴보기

소규모 사용자 그룹이 새로운 기능 및 서비스를 사용할 수 있도록 하는 것은 위험을 줄이는 좋은 개발 전략이다.  클라우드와 마이크로서비스 이전 시대의 ‘개발, 테스트, 프로덕션, 재해 복구(DR)’ 배포 패러다임을 기억하는가? 당시에는 인프라를 구매하고, 구성하며, 유지관리하는 비용이 많이 들고 복잡했기 때문에 데이터센터 운영팀은 더 많은 환경과 배포 유연성을 확보하는 데 거의 동의하지 않았다.  오늘날 데브옵스 조직은 지속적 통합/지속적 제공(CI/CD)을 사용하여 딜리버리를 자동화하고, 코드형 인프라(Infrastructure as Code; IaC)를 활용해 인프라를 구성하며, 쿠버네티스를 통해 환경을 컨테이너화한다. 또 지속적인 테스트로 품질을 높이고, AI옵스(AIops)를 사용하여 모니터링 및 관찰 가능성을 중앙집중화한다. 이러한 관행 덕분에 배포 빈도를 높이는 동시에 변경으로 인한 보안, 성능, 안정성 위험을 최소화할 수 있다. 하지만 변경 사항과 액세스 권한에 따라 위험을 줄이고 릴리즈를 제어하고자 한다면 애플리케이션 또는 배포를 구성하고 관리하는 추가적인 기법이 필요하다.    릴리즈 파이프라인에는 유연한 관리 및 배포 옵션이 필요하다 배포를 제어하는 한 가지 방법은 기능 플래그를 활용하여 사용자별로 기능 액세스를 전환, A/B 테스트, 세분화하는 것이다. 데브옵스 팀은 기능 플래그를 사용하여 앱을 클라우드로 이동하거나, 단일 애플리케이션을 마이크로서비스에 리팩토링할 때 새롭게 개발한 기능을 검증할 수 있다. 기능 플래그는 앱 또는 마이크로서비스의 기능을 확인할 수 있는 사람을 통제하려는 개발팀과 제품 관리자에 유용하다. 하지만 때때로 데브옵스 또는 IT 운영팀은 배포를 관리하고 프로덕션 환경에 투입된 애플리케이션의 여러 버전을 관리할 수 있는 유연성이 필요하다. 몇 가지 예는 다음과 같다.  • 운영체제, 데이터베이스, 미들웨어 등의 중요한 시스템 구성 요소를 패치하거나 업그레이드할 때...

지속적 제공 지속적 배포 카나리 배포 카나리 릴리즈 소프트웨어 배포 애플리케이션 마이크로서비스 데브옵스 블루-그린 배포 애자일

2021.12.30

소규모 사용자 그룹이 새로운 기능 및 서비스를 사용할 수 있도록 하는 것은 위험을 줄이는 좋은 개발 전략이다.  클라우드와 마이크로서비스 이전 시대의 ‘개발, 테스트, 프로덕션, 재해 복구(DR)’ 배포 패러다임을 기억하는가? 당시에는 인프라를 구매하고, 구성하며, 유지관리하는 비용이 많이 들고 복잡했기 때문에 데이터센터 운영팀은 더 많은 환경과 배포 유연성을 확보하는 데 거의 동의하지 않았다.  오늘날 데브옵스 조직은 지속적 통합/지속적 제공(CI/CD)을 사용하여 딜리버리를 자동화하고, 코드형 인프라(Infrastructure as Code; IaC)를 활용해 인프라를 구성하며, 쿠버네티스를 통해 환경을 컨테이너화한다. 또 지속적인 테스트로 품질을 높이고, AI옵스(AIops)를 사용하여 모니터링 및 관찰 가능성을 중앙집중화한다. 이러한 관행 덕분에 배포 빈도를 높이는 동시에 변경으로 인한 보안, 성능, 안정성 위험을 최소화할 수 있다. 하지만 변경 사항과 액세스 권한에 따라 위험을 줄이고 릴리즈를 제어하고자 한다면 애플리케이션 또는 배포를 구성하고 관리하는 추가적인 기법이 필요하다.    릴리즈 파이프라인에는 유연한 관리 및 배포 옵션이 필요하다 배포를 제어하는 한 가지 방법은 기능 플래그를 활용하여 사용자별로 기능 액세스를 전환, A/B 테스트, 세분화하는 것이다. 데브옵스 팀은 기능 플래그를 사용하여 앱을 클라우드로 이동하거나, 단일 애플리케이션을 마이크로서비스에 리팩토링할 때 새롭게 개발한 기능을 검증할 수 있다. 기능 플래그는 앱 또는 마이크로서비스의 기능을 확인할 수 있는 사람을 통제하려는 개발팀과 제품 관리자에 유용하다. 하지만 때때로 데브옵스 또는 IT 운영팀은 배포를 관리하고 프로덕션 환경에 투입된 애플리케이션의 여러 버전을 관리할 수 있는 유연성이 필요하다. 몇 가지 예는 다음과 같다.  • 운영체제, 데이터베이스, 미들웨어 등의 중요한 시스템 구성 요소를 패치하거나 업그레이드할 때...

2021.12.30

“분산 배포 개선 外”··· 깃랩 14.6 출시

깃랩 소프트웨어 딜리버리 플랫폼의 최신 릴리즈가 출시됐다. 회사에 따르면 ‘깃랩 14.6(GitLab 14.6)’에서는 지리적으로 분산된 애플리케이션 배포 기능이 개선됐다. 마이크로소프트의 닷넷 6(.NET6) 소프트웨어 개발 플랫폼을 대상으로 하는 취약점 스캔 기능도 추가됐다.    지난 12월 22일(현지 시각) 공개된 버전 14.6에서는 ‘깃랩 지오(GitLab Geo)’의 구성이 단순화됐다. 이를 통해 깃랩 인스턴스의 읽기 전용 미러와 쓰기 가능 미러를 모두 사용할 수 있게 됐다고 회사 측은 전했다. ‘지오’는 전 세계에 분산돼 있는 팀이 가장 가까운 지오 사이트를 자동으로 사용하여 깃 풀 명령을 가속화할 수 있도록 지원한다.  깃랩 14.6 이전 버전에서는 사용자가 모든 깃 작업에 단일 통합 URL을 사용하여 깃랩 지오를 설정할 수 있었다. 하지만 지오 복제본에는 웹 UI 및 API 액세스를 위한 자체 URL이 있어야 했다. 또 지오 복제본의 웹 UI는 읽기 전용이어서 사용자가 페이지를 보는 것을 제한하고 전체 사이트에서 변경을 수행해야 했다.  깃랩 14.6을 사용하면 지오 보조 사이트가 대부분의 읽기 요청을 가속화하는 동시에 기본 사이트로 쓰기 요청을 프록시한다. 아울러 관리자는 조직 전체의 깃랩 사용자에게 가장 가까운 지오 사이트를 자동으로 사용하는 단일 URL을 제공할 수 있다고 회사 측은 말했다. 이제 분산된 팀이 가속화된 git clone 또는 git pull 명령과 원활한 전 세계 환경의 이점을 누릴 수 있다는 설명이다.  한편 깃랩은 얼티메이트(Ultimate) 기능을 대부분 사용할 수 있는 30일 무료 평가판을 제공한다. 얼티메이트 계층은 보안, 컴플라이언스, 포트폴리오 관리 기능을 추가한다. 이 밖에 깃랩 14.6의 개선사항은 다음과 같다.  • 지난 11월 프로덕션 릴리즈로 출시된 마이크로소프트 닷넷 6(.NET 6)가 깃랩 SAST(Static Application...

깃랩 CI/CD 데브옵스 소프트웨어 개발

2021.12.27

깃랩 소프트웨어 딜리버리 플랫폼의 최신 릴리즈가 출시됐다. 회사에 따르면 ‘깃랩 14.6(GitLab 14.6)’에서는 지리적으로 분산된 애플리케이션 배포 기능이 개선됐다. 마이크로소프트의 닷넷 6(.NET6) 소프트웨어 개발 플랫폼을 대상으로 하는 취약점 스캔 기능도 추가됐다.    지난 12월 22일(현지 시각) 공개된 버전 14.6에서는 ‘깃랩 지오(GitLab Geo)’의 구성이 단순화됐다. 이를 통해 깃랩 인스턴스의 읽기 전용 미러와 쓰기 가능 미러를 모두 사용할 수 있게 됐다고 회사 측은 전했다. ‘지오’는 전 세계에 분산돼 있는 팀이 가장 가까운 지오 사이트를 자동으로 사용하여 깃 풀 명령을 가속화할 수 있도록 지원한다.  깃랩 14.6 이전 버전에서는 사용자가 모든 깃 작업에 단일 통합 URL을 사용하여 깃랩 지오를 설정할 수 있었다. 하지만 지오 복제본에는 웹 UI 및 API 액세스를 위한 자체 URL이 있어야 했다. 또 지오 복제본의 웹 UI는 읽기 전용이어서 사용자가 페이지를 보는 것을 제한하고 전체 사이트에서 변경을 수행해야 했다.  깃랩 14.6을 사용하면 지오 보조 사이트가 대부분의 읽기 요청을 가속화하는 동시에 기본 사이트로 쓰기 요청을 프록시한다. 아울러 관리자는 조직 전체의 깃랩 사용자에게 가장 가까운 지오 사이트를 자동으로 사용하는 단일 URL을 제공할 수 있다고 회사 측은 말했다. 이제 분산된 팀이 가속화된 git clone 또는 git pull 명령과 원활한 전 세계 환경의 이점을 누릴 수 있다는 설명이다.  한편 깃랩은 얼티메이트(Ultimate) 기능을 대부분 사용할 수 있는 30일 무료 평가판을 제공한다. 얼티메이트 계층은 보안, 컴플라이언스, 포트폴리오 관리 기능을 추가한다. 이 밖에 깃랩 14.6의 개선사항은 다음과 같다.  • 지난 11월 프로덕션 릴리즈로 출시된 마이크로소프트 닷넷 6(.NET 6)가 깃랩 SAST(Static Application...

2021.12.27

인프라 자동화 접근법··· ‘코드형 인프라(IaC)’란?

컴퓨팅 인프라를 코드로 취급하는 것은 클라우드에서 소프트웨어를 프로비저닝하는 스마트하고 현대적인 방법이다. 여기서는 ‘코드형 인프라(IaC)’란 무엇인지 그리고 이것이 왜 좋은지를 살펴본다.  점점 더 많은 기업이 클라우드로 이동하면서, 물리적 서버를 프로비저닝하고 구성하는 방법은 최신 소프트웨어를 구축하고 구현하는 방법과 관련성이 적어지고 있다.  컴퓨팅 인프라가 보이지도 들리지도 않는 오늘날의 복잡한 소프트웨어 중심 세계에서 웹의 규모에 맞게 애플리케이션을 실행하려면 수동 구성이나 스크립트보다는 선언적 코드를 사용하여 인프라를 프로비저닝하고 관리할 수 있어야 한다.   코드형 인프라(IaC)의 역사  시스템 관리자들은 1990년대부터 스크립트를 사용하여 인프라를 관리해 왔지만 IaC 관행은 2000년대 말까지 완전히 통합되지 않았다. 그리고 이때부터 데브옵스의 선구자 앤드류 클레이 세퍼, 셰프(Chef)의 공동 창업자 아담 제이콥, 퍼펫(Puppet)의 설립자 루크 케이니스 등이 이 용어를 사용하기 시작했다. 분산 애플리케이션의 세계에서는 수동으로 조정되는 서버는 확장이 불가능했고, 스크립팅 자체로는 한계가 있었다. 따라서 클라우드 초기에는 인프라 프로비저닝을 자동화하는 것이 많은 선발 주자(first mover)의 핵심 니즈였다.  오늘날에는 기본 인프라가 코드로 프로비저닝되는 일이 흔하다. 셰프, 퍼펫, 솔트스택, 앤서블 등 오늘날 이 분야에서 널리 사용되는 도구들 덕분이다. 하지만 기술은 빠르게 움직이고, 그 이후로 모든 것이 발전했다. 여기서는 IaC의 정의와 이것이 오늘날 최신 소프트웨어 개발 관행의 기반을 이루는 이유를 소개한다. 코드형 인프라(IaC)의 정의 ‘코드형 인프라: 클라우드 시대의 역동적인 시스템(Infrastructure as Code: Dynamic Systems for the Cloud Age)’이라는 책에서 저자 키에프 모리스는 코드형 인프라가 3가지 핵심 관행으로 요...

데브옵스 클라우드 관리 코드형 인프라 소프트웨어 개발 클라우드 시스템 관리

2021.12.16

컴퓨팅 인프라를 코드로 취급하는 것은 클라우드에서 소프트웨어를 프로비저닝하는 스마트하고 현대적인 방법이다. 여기서는 ‘코드형 인프라(IaC)’란 무엇인지 그리고 이것이 왜 좋은지를 살펴본다.  점점 더 많은 기업이 클라우드로 이동하면서, 물리적 서버를 프로비저닝하고 구성하는 방법은 최신 소프트웨어를 구축하고 구현하는 방법과 관련성이 적어지고 있다.  컴퓨팅 인프라가 보이지도 들리지도 않는 오늘날의 복잡한 소프트웨어 중심 세계에서 웹의 규모에 맞게 애플리케이션을 실행하려면 수동 구성이나 스크립트보다는 선언적 코드를 사용하여 인프라를 프로비저닝하고 관리할 수 있어야 한다.   코드형 인프라(IaC)의 역사  시스템 관리자들은 1990년대부터 스크립트를 사용하여 인프라를 관리해 왔지만 IaC 관행은 2000년대 말까지 완전히 통합되지 않았다. 그리고 이때부터 데브옵스의 선구자 앤드류 클레이 세퍼, 셰프(Chef)의 공동 창업자 아담 제이콥, 퍼펫(Puppet)의 설립자 루크 케이니스 등이 이 용어를 사용하기 시작했다. 분산 애플리케이션의 세계에서는 수동으로 조정되는 서버는 확장이 불가능했고, 스크립팅 자체로는 한계가 있었다. 따라서 클라우드 초기에는 인프라 프로비저닝을 자동화하는 것이 많은 선발 주자(first mover)의 핵심 니즈였다.  오늘날에는 기본 인프라가 코드로 프로비저닝되는 일이 흔하다. 셰프, 퍼펫, 솔트스택, 앤서블 등 오늘날 이 분야에서 널리 사용되는 도구들 덕분이다. 하지만 기술은 빠르게 움직이고, 그 이후로 모든 것이 발전했다. 여기서는 IaC의 정의와 이것이 오늘날 최신 소프트웨어 개발 관행의 기반을 이루는 이유를 소개한다. 코드형 인프라(IaC)의 정의 ‘코드형 인프라: 클라우드 시대의 역동적인 시스템(Infrastructure as Code: Dynamic Systems for the Cloud Age)’이라는 책에서 저자 키에프 모리스는 코드형 인프라가 3가지 핵심 관행으로 요...

2021.12.16

‘IT-현업 정렬 촉진하려면...’ 최신 조언 7가지

기업 내 부문 간 협력이 부실한가? 이로 인한 증상으로는 부서 간 알력, 통제 불능 상황의 지속적 발생, 생산성 및 성과 저하 등이 있다. IT와 여러 현업 팀의 정렬이 원활하지 않으면 모든 당사자가 험난한 길을 걷게 된다. 캡제미니 아메리카의 부사장 겸 애플리케이션 관리 서비스 전문가 조직 책임자 사미에르 바그와트는 “조직이 고객에게 가치를 제공하는 방식에 근본적인 변화가 나타나고 있다. 디지털 트랜스포메이션이라고 불린다”라고 말했다. 현재 비즈니스 생태계 전체가 상호 연결된 상태에서 기업들은 변화무쌍한 비즈니스 요구와 시장 요건을 신속하게 해결해야 하는 상황이다. 바그와트는 “IT와 비즈니스가 적절히 협력하고 있다면 리더는 목표를 더욱 효과적으로 달성할 수 있다”라고 말했다. IT와 비즈니스를 더욱 잘 협력하기 위한 다음의 7가지 조언을 살펴본다.   비즈니스를 파악하라 CIO는 더 이상 단순한 기술 전문가가 아니다. 오늘날의 생태계에서는 CIO도 비즈니스 의사결정자라고 퍼블릭 클라우드 관리형 서비스 및 데이터 분석 제공기업 시에프(Siepe)의 CEO 겸 설립자 마이클 푸사테리가 말했다. CIO는 비즈니스 전체뿐 아니라 기존 또는 잠재적인 기술 불편사항을 파악해야 한다. 현재의 비즈니스 문제에 집중함으로써 CIO는 경영진이 단순히 기술적 관전에서 조언을 제공하는 대신에 문제에 대한 다차원적 솔루션을 구성하도록 도울 수 있다. “이를 통해 CIO는 현재 단계에서 비즈니스의 요구를 해결하지 못할 수 있는 최신 기술을 선택하는 것과는 달리 비즈니스에 적합한 솔루션을 개발하거나 선택할 수 있다”라고 푸사테리가 말했다. 특히 CIO와 CEO 사이의 원활한 의사소통은 기업이 발전할 방식에 대한 더 나은 투명성과 더욱 정확한 전망을 확보해 준다고 푸사테리가 말했다. 그는 “기업 전략 위원회에서 주요한 역할을 수행함으로써 CIO가 CEO의 비전을 실행하는 최고의 기술 솔루션을 구성할 수 있는 권한을 확보해야 한다”라고 설명했다.  경영진...

현업 비즈니스 정렬 IT 관리 데브옵스 풀 스택 가시성 결합성 KPI

2021.11.24

기업 내 부문 간 협력이 부실한가? 이로 인한 증상으로는 부서 간 알력, 통제 불능 상황의 지속적 발생, 생산성 및 성과 저하 등이 있다. IT와 여러 현업 팀의 정렬이 원활하지 않으면 모든 당사자가 험난한 길을 걷게 된다. 캡제미니 아메리카의 부사장 겸 애플리케이션 관리 서비스 전문가 조직 책임자 사미에르 바그와트는 “조직이 고객에게 가치를 제공하는 방식에 근본적인 변화가 나타나고 있다. 디지털 트랜스포메이션이라고 불린다”라고 말했다. 현재 비즈니스 생태계 전체가 상호 연결된 상태에서 기업들은 변화무쌍한 비즈니스 요구와 시장 요건을 신속하게 해결해야 하는 상황이다. 바그와트는 “IT와 비즈니스가 적절히 협력하고 있다면 리더는 목표를 더욱 효과적으로 달성할 수 있다”라고 말했다. IT와 비즈니스를 더욱 잘 협력하기 위한 다음의 7가지 조언을 살펴본다.   비즈니스를 파악하라 CIO는 더 이상 단순한 기술 전문가가 아니다. 오늘날의 생태계에서는 CIO도 비즈니스 의사결정자라고 퍼블릭 클라우드 관리형 서비스 및 데이터 분석 제공기업 시에프(Siepe)의 CEO 겸 설립자 마이클 푸사테리가 말했다. CIO는 비즈니스 전체뿐 아니라 기존 또는 잠재적인 기술 불편사항을 파악해야 한다. 현재의 비즈니스 문제에 집중함으로써 CIO는 경영진이 단순히 기술적 관전에서 조언을 제공하는 대신에 문제에 대한 다차원적 솔루션을 구성하도록 도울 수 있다. “이를 통해 CIO는 현재 단계에서 비즈니스의 요구를 해결하지 못할 수 있는 최신 기술을 선택하는 것과는 달리 비즈니스에 적합한 솔루션을 개발하거나 선택할 수 있다”라고 푸사테리가 말했다. 특히 CIO와 CEO 사이의 원활한 의사소통은 기업이 발전할 방식에 대한 더 나은 투명성과 더욱 정확한 전망을 확보해 준다고 푸사테리가 말했다. 그는 “기업 전략 위원회에서 주요한 역할을 수행함으로써 CIO가 CEO의 비전을 실행하는 최고의 기술 솔루션을 구성할 수 있는 권한을 확보해야 한다”라고 설명했다.  경영진...

2021.11.24

'데브옵스에 애자일·ITSM 도구가 통합되어야 한다' 3가지 이유

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

데브옵스 애자일 ITSM CI/CD

2021.11.18

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

2021.11.18

마이크로포커스, ‘디폴로이먼트 오토메이션’ 솔루션 통해 배포 자동화 시장 공략

마이크로포커스는 ‘디폴로이먼트 오토메이션(Deployment Automation)’ 솔루션을 통해 배포 자동화 시장을 공략하겠다고 11일 발표했다.  이 제품은 배포 속도를 향상시키는 동시에 소프트웨어 개발 생산성을 향상시키고, 지속적인 빌드와 배포 관리를 통해 제품의 품질을 향상시켜 데브옵스 실현에 가장 적합하다고 업체 측은 설명했다.  마이크로포커스 코리아는 디폴로이먼트 오토메이션을 통해 ▲배포 자동화로 운영배포 적용시간 최대 90% 단축 ▲복잡한 프로세스를 단순화하여 프로젝트 진행도 및 생산성 증가 ▲환경 게이트 및 버전 상태관리로 릴리즈 결함 최대 75% 감소 ▲롤백, 배포 정합성, 규정감사로 장애 리스크 감소 및 운영 안정성 증가 ▲파이프라인으로 가시성 확보 및 부서간에 협업 항상 및 FTE 감소 ▲SDLC 단축 및 관리시간 감소로 개발비용 절감 등과 같은 도입 효과를 기대할 수 있다고 밝혔다. 디플로이먼트 오토메이션의 기능은 ▲사용하기 쉬운 그래픽 에디터 ▲배포 관리 가능한 모바일 애플리케이션 지원 ▲애플리케이션 스냅샷으로 모델 기반의 배포 ▲안전한 보관과 추적기능을 제공하는 배포 저장소 ▲중요 애플리케이션 환경을 지원하는 플러그인 아키텍처 ▲서드 파티 도구와 원활한 연계 ▲소스관리, 빌드 및 테스트 자동화, 배포, 품질, 헬프 데스크, 티켓 시스템 ▲내부 표준 및 규정 준수를 위한 감사(Audit) 및 컴플라이언스 리포트 ▲역할 기반의 보안, 승인 및 알림 지원 ▲배포 건수 및 결과에 대한 리포트 기능을 제공 등이다.   마이크로포커스 코리아 제품 기술 영업 담당인 오상현 이사는 “디플로이먼트 오토메이션은 기업에 복잡한 배포를 조정하는 프로세스 자동화를 제공함으로써 개발 배포 및 프로덕션 환경으로의 릴리즈를 위한 반복 가능하고 안정적인 프로세스를 만들 수 있다”라고 말했다. 투데이시스템의 강길호 대표는 "배포 자동화는 DA의 그래픽 에디터를 통해 종단간 배포 프로세스를 손쉽게 만들고 시각화한다. 이에 따...

마이크로포커스 소프트웨어 개발 데브옵스

2021.11.11

마이크로포커스는 ‘디폴로이먼트 오토메이션(Deployment Automation)’ 솔루션을 통해 배포 자동화 시장을 공략하겠다고 11일 발표했다.  이 제품은 배포 속도를 향상시키는 동시에 소프트웨어 개발 생산성을 향상시키고, 지속적인 빌드와 배포 관리를 통해 제품의 품질을 향상시켜 데브옵스 실현에 가장 적합하다고 업체 측은 설명했다.  마이크로포커스 코리아는 디폴로이먼트 오토메이션을 통해 ▲배포 자동화로 운영배포 적용시간 최대 90% 단축 ▲복잡한 프로세스를 단순화하여 프로젝트 진행도 및 생산성 증가 ▲환경 게이트 및 버전 상태관리로 릴리즈 결함 최대 75% 감소 ▲롤백, 배포 정합성, 규정감사로 장애 리스크 감소 및 운영 안정성 증가 ▲파이프라인으로 가시성 확보 및 부서간에 협업 항상 및 FTE 감소 ▲SDLC 단축 및 관리시간 감소로 개발비용 절감 등과 같은 도입 효과를 기대할 수 있다고 밝혔다. 디플로이먼트 오토메이션의 기능은 ▲사용하기 쉬운 그래픽 에디터 ▲배포 관리 가능한 모바일 애플리케이션 지원 ▲애플리케이션 스냅샷으로 모델 기반의 배포 ▲안전한 보관과 추적기능을 제공하는 배포 저장소 ▲중요 애플리케이션 환경을 지원하는 플러그인 아키텍처 ▲서드 파티 도구와 원활한 연계 ▲소스관리, 빌드 및 테스트 자동화, 배포, 품질, 헬프 데스크, 티켓 시스템 ▲내부 표준 및 규정 준수를 위한 감사(Audit) 및 컴플라이언스 리포트 ▲역할 기반의 보안, 승인 및 알림 지원 ▲배포 건수 및 결과에 대한 리포트 기능을 제공 등이다.   마이크로포커스 코리아 제품 기술 영업 담당인 오상현 이사는 “디플로이먼트 오토메이션은 기업에 복잡한 배포를 조정하는 프로세스 자동화를 제공함으로써 개발 배포 및 프로덕션 환경으로의 릴리즈를 위한 반복 가능하고 안정적인 프로세스를 만들 수 있다”라고 말했다. 투데이시스템의 강길호 대표는 "배포 자동화는 DA의 그래픽 에디터를 통해 종단간 배포 프로세스를 손쉽게 만들고 시각화한다. 이에 따...

2021.11.11

마이크로서비스 모니터링 전략··· 'RED'의 개념과 장단점

요청 수(Rate), 오류율(Error), 소요 시간(Duration)에 중점을 두는 모니터링 기법 ‘RED’를 활용하면 최종 사용자를 대상으로 서비스가 어떻게 작동하는지 파악할 수 있다.  사용자에게 양질의 제품과 경험을 제공하는 데 있어 애플리케이션 모니터링은 필수적이다. 하지만 단순하게 수많은 애플리케이션 지표를 수집하는 것만으로는 실질적인 문제를 해결할 수 없다.  소프트웨어 회사는 사용자가 겪고 있는 문제를 신속하게 해결할 수 있도록 지표에서 실행 가능한 인사이트를 확보해야 한다. 여기서는 RED 기법을 살펴본다.   RED 기법이란? RED 기법은 톰 윌키가 구글에서 일하면서 터득한 것을 토대로 만든 모니터링 방법론이다. 구글의 SRE(Site Reliability Engineering) 팀에서 개발한 ‘4가지 황금 신호(Four Golden Signals)’에서 파생됐다. RED는 이전의 모니터링 철학과 기법(예: USE 기법(사용률, 포화도, 오류율 확인) 등)이 소프트웨어 회사 및 최신 소프트웨어 아키텍처의 목표와 완전히 일치하지 않았다는 것에 초점을 맞춘다.  USE가 하드웨어와 인프라에 더 많이 적용되는 반면 RED는 애플리케이션 사용자의 경험에 중점을 둔다. 다시 말해, RED 기법의 목표는 소프트웨어 애플리케이션이 무엇보다 최종 사용자를 위해 제대로 작동하는지 확인하는 것이다.  마이크로서비스 아키텍처, 컨테이너, 클라우드 인프라의 시대에서 하드웨어와 관련된 메트릭은 서비스 수준 목표(Service Level Objectives; SLO)가 충족되는 한 그다지 중요하지 않다.  RED는 요청 수(Rate), 오류율(Errors), 소요 시간(Duration)을 나타낸다. 이는 아키텍처의 각 서비스에서 모니터링해야 할 3가지 핵심 지표다. • 요청 수(Rate) - 서비스가 초당 처리하는 요청 수 • 오류율(Error) - 초당 실패한 요청 수 • 소요 시간(Durati...

마이크로서비스 애플리케이션 모니터링 RED 데브옵스 소프트웨어 개발 클라우드 컴퓨팅

2021.11.08

요청 수(Rate), 오류율(Error), 소요 시간(Duration)에 중점을 두는 모니터링 기법 ‘RED’를 활용하면 최종 사용자를 대상으로 서비스가 어떻게 작동하는지 파악할 수 있다.  사용자에게 양질의 제품과 경험을 제공하는 데 있어 애플리케이션 모니터링은 필수적이다. 하지만 단순하게 수많은 애플리케이션 지표를 수집하는 것만으로는 실질적인 문제를 해결할 수 없다.  소프트웨어 회사는 사용자가 겪고 있는 문제를 신속하게 해결할 수 있도록 지표에서 실행 가능한 인사이트를 확보해야 한다. 여기서는 RED 기법을 살펴본다.   RED 기법이란? RED 기법은 톰 윌키가 구글에서 일하면서 터득한 것을 토대로 만든 모니터링 방법론이다. 구글의 SRE(Site Reliability Engineering) 팀에서 개발한 ‘4가지 황금 신호(Four Golden Signals)’에서 파생됐다. RED는 이전의 모니터링 철학과 기법(예: USE 기법(사용률, 포화도, 오류율 확인) 등)이 소프트웨어 회사 및 최신 소프트웨어 아키텍처의 목표와 완전히 일치하지 않았다는 것에 초점을 맞춘다.  USE가 하드웨어와 인프라에 더 많이 적용되는 반면 RED는 애플리케이션 사용자의 경험에 중점을 둔다. 다시 말해, RED 기법의 목표는 소프트웨어 애플리케이션이 무엇보다 최종 사용자를 위해 제대로 작동하는지 확인하는 것이다.  마이크로서비스 아키텍처, 컨테이너, 클라우드 인프라의 시대에서 하드웨어와 관련된 메트릭은 서비스 수준 목표(Service Level Objectives; SLO)가 충족되는 한 그다지 중요하지 않다.  RED는 요청 수(Rate), 오류율(Errors), 소요 시간(Duration)을 나타낸다. 이는 아키텍처의 각 서비스에서 모니터링해야 할 3가지 핵심 지표다. • 요청 수(Rate) - 서비스가 초당 처리하는 요청 수 • 오류율(Error) - 초당 실패한 요청 수 • 소요 시간(Durati...

2021.11.08

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