GitLab 16.5 기능 리뷰와 GitLab AI기능 살펴보기, 오픈소스 Pulumi로 IaC 인프라 구
인포레터 33호 2023.11.01 |  지난 인포레터 구독 신청 
이 달의 Tech Article
  1. GitLab 16.5 Release
  2. GitLab Duo로 개발 생산성 높이기
  3. Pulumi로 인프라 구축하기
  4. 인포그랩의 DevOps 엔지니어는 어떻게 온보딩 할까? 
  5. DevOps News Clipping  

내년의 준비를 해야할 시기, 11월이 돌아왔습니다. 날씨도 많이 추워지기 시작했고요. 한 해동안 이뤄온 것을 돌아보고 내년의 성장을 생각해 봐야할 시기인데요. 인포그랩 구독자님들도 더 큰 도약을 위한 알찬 준비를 완료할 수 있길 기원하며 이번 달 인포레터를 시작하겠습니다. 😄


아티클이 도움이 되셨다면, 인포레터를 주변에 알려주세요! 구독과 소개는 편집진을 춤추게 합니다.😁

- 인포레터 편집진-   

 
  • 컴플라이언스 표준 준수 보고서
  • Merge Request(MR) 타깃 브랜치 규칙 
  • 이슈 스레드 해결하기
  • semi-linear기록이 있는 Fast-forward Merge Train
  • Jira 개발 패널에서 MR 리뷰어 정보 보기 
더 자세한 내용은 GitLab 릴리스 노트에서 확인해 보세요!

구독자님들께서 좀 더 쉽고 빠르게 GitLab 업데이트 정보를 보셨으면 하는 마음으로
제작하고 있습니다. "YouTube 구독과 좋아요"
인포레터 편집진을 춤추게 할지도 몰라요~😆
GitLab DUO와 Pulumi를 활용한
개발 생산성
향상하기
최근 소프트웨어 개발은 AI와 인프라 구축을 손쉽게 실행하고 편의를 높이도록 플랫폼 개발이 활발한데요. 

이번 Tech Article에서는 GitLab Duo와 Pulumi를 활용하여 개발 생산성을 향상시키는 방법을 살펴봅니다. GitLab Duo는 AI를 이용한 협업 및 코드작성 지원, Pulumi는 다양한 클라우드 플랫폼 지원의 IaC 도구입니다. 이들의 활용 방법을 설명하겠습니다.

GitLab Duo로 개발 생산성 높이기

Fabbro Park | Software Engineer

오늘날 소프트웨어 개발 업무는 AI의 영향을 받고 있습니다. GitLab은 이러한 긍정적인 방향으로 발전시키고자 다양한 AI 기능을 선보이는데요. 특히 여러 AI 기능을 한데 모아 GitLab Duo를 제공해 조직이 원활하게 협업하고, 코드를 신속하게 작성하며 리뷰하도록 지원합니다. 빠른 문제 정의, 협업을 지원하는 View Summary, 효율적인 코드 리뷰를 돕는 Suggested Reviewer, 코드 리뷰 요약과 테스트 코드 생성, 컨텍스트 스위칭을 최소화한 GitLab Duo Chat이라는 기능인데요. 이는 업무 생산성과 효율성을 높여 비즈니스 목표를 달성하는 데 도움이 될 수 있습니다. 이 글에서는 GitLab Duo를 활용해 소프트웨어 개발 업무 속도와 편의를 높이는 방법을 알아보겠습니다.

 

자세한 내용은 본문을 통해 확인해 보세요!

HashiCorp 'Pulumi'로 인프라 구축하기

John Noh | DevOps Engineer

오늘날 많은 팀이 인프라를 코드로 관리하기 위해 IaC 도구를 사용합니다. 이 가운데 Terraform과 AWS CloudFormation과 같은 도구는 강력하고 유용한 기능을 제공합니다. 그러나 특정 도구의 전용 언어로 인프라를 구성하는 과정은 다소 번거로울 수 있습니다. 최근에 나온 HashiCorp에서 개발한 오픈소스 프로젝트인 Pulumi라는 IaC 도구는 일반적인 프로그래밍 언어로 작성할 수 있으며, 다양한 클라우드 플랫폼과 서비스를 지원합니다. 또한 손쉬운 마이그레이션을 제공합니다. 이 글에서는 Pulumi의 특징을 알아보고, 이 도구로 AWS S3를 생성하는 방법을 알아보겠습니다.


자세한 내용은 본문을 통해 확인해 보세요!

조직에 적응하기
위한 온보딩에
대한 이야기
어느 누구나 새로운 조직에 처음 들어가면 적응이 어려울 수 있습니다.
새로운 인원이 능력을 발휘하게 하고 조직 문화에 스며들도록 하는 일은 어느 조직이든 중요한 일인데요. 인포그랩 DevOps 엔지니어의 온보딩에 대해 알아보고 조직 온보딩에 대한 인사이트를 얻어보세요.   

인포그랩의 DevOps 엔지니어는

어떻게 온보딩 할까?

Chad Lim | DevOps Engineer

새로운 조직에 적응하는 것은 신입과 경력자 모두에게 쉽지 않습니다. 조직에서는 새로운 직원이나 사용자가 조직 또는 서비스에 적응하고, 직원이 업무를 원활히 수행하도록 돕기 위해 온보딩 프로그램을 운영합니다. 인포그랩에서도 온보딩 프로그램을 진행하고 있습니다. 이번 글에서는 DevOps 엔지니어 Chad가 지난 3개월 동안 인포그랩 DevOps 엔지니어로서 온보딩하며 느낀 변화를 공유합니다.


자세한 내용은 본문을 통해 확인해 보세요!

기술팀이 자주 간과하는
DevOps 20가지 모범 사례
이 글에서는 Forbes Technology Council 멤버들이 꼽은 ‘기술팀이 자주 간과하는 DevOps 모범 사례 20가지’를 다뤘습니다.

첫째, 외부 변화에 적응하는 일이고요.
둘째, 기술 부채를 잘 관리하는 일입니다.
셋째, 변경 사항과 사고를 관리하는 일이고요.
넷째, 프로세스와 구성을 문서화하는 일이죠.
다섯째, 솔루션에 보안을 통합하는 일입니다.
여섯째, 출시 전 플레이북을 개발하고, 테스트하는 일이고요.
일곱째, 분산 추적 도구를 활용하는 일이죠.
여덟째, 지속적인 모니터링과 피드백을 통합하는 일입니다.
아홉째, 성공과 가치를 공유하는 환경을 구축하는 일이고요.
열째, 비난하지 않으며 사후 분석하는 일이죠.
열한째, 지식 자산을 만들고 유지 관리하는 일이고요.
열두째, 자동 보안 스캐닝을 실행하는 일입니다.
열셋째, DevOps를 회사 전체에 통합하는 일이고요.
열넷째, 구성 관리입니다.
열다섯째, 버전 관리고요.
열여섯째, 시스템을 사전에 모니터링하는 일이죠.
열일곱째, 카오스 엔지니어링이고요.
열여덟째, 파편화(사일로 관련)를 방지하는 일입니다.
열아홉째, 팀 구성을 주기적으로 개편하는 일이고요.
스무째, DevOps 관행을 따르지 말아야 할 때를 아는 일입니다.

이밖에 자세한 내용은 본문을 확인해 주세요.
보안을 위협하지 않고
앱을 더 빠르게 개발하는 3가지 방법
이 글에서는 DevOps 팀이 보안을 위협하지 않고 개발 속도를 극대화하는 3가지 방법을 다뤘습니다.

첫째, 권한이 부여된 액세스 관리를 간소화하는 건데요.
특히 소프트웨어 공급망에 위협이 늘어나면서 이 일은 DevOps 팀에서 사이버 보안을 강화하는 데 필수입니다. 이는 필요에 따라 허가되고, 취소되는 임시 액세스 권한을 포함해 엄격한 보안 관행을 채택하도록 요구하는데요. DevOps 워크플로에서 임시 서비스를 관리하는 데 이상적인 전략입니다.

둘째, 보안에 AI 솔루션을 활용하는 건데요.
최근 사이버 보안 위협이 DevOps 팀에 확대되면서 사이버 보안 AI 섹터가 떠오르고 있습니다. AI는 위험에 처한 애플리케이션을 빨리 확인하고 모니터링하고요. 이는 CI/CD로 DevOps 프로세스에 복원력을 높입니다. 그 결과, DevOps 팀이 사이버 보안 사고를 감지하고 예방하도록 지원하죠.

셋째, DevOps 팀에서 소통과 협업을 활성화하는 건데요.
DevOps 영역에서 성공은 적절한 도구와 기술을 구현하는 것뿐만 아니라 팀 멤버 간에 원활한 소통과 협업을 독려하는 적응 문화를 조성하는 데에도 달렸습니다. 팀이 효과적으로 협업하면, 문제를 더 빨리 확인하고 해결하며, 소프트웨어 품질을 개선하고 배포 시간을 가속할 수 있죠.

이밖에 자세한 내용은 본문을 확인해 주세요.  
인시던트로 더 잘 학습하기: 사후 분석 문서 가이드
이 글에서는 사후 분석 문서 개념과 책임자, 작성 시기 등을 다뤘습니다. 사후 분석 문서는 인시던트가 종료된 뒤, 관련 정보를 모은 문서인데요.

이 문서의 최종 목표는 인시던트 원인이 되는 요인, 주요 위험 요소를 더 잘 이해하고, 미래에 비슷한 위험 요소 영향을 예방하거나 줄이는 방법을 계획하는 거죠.

이 글에서는 사후 분석 문서 책임자로 이런 사람을 추천하는데요.
리더십 역할을 맡은 사람(예: 인시던트 리드), 인시던트를 해결하기 위해 구체적인 조치를 취한 사람, 인시던트가 영향을 미친 서비스를 위해 대기 중인 사람, 인시던트를 확인하고 수동으로 선언한 사람이 그 대상이죠. 사후 분석 문서는 인시던트가 마무리된 직후 바로 작성해야 하는데요.

그렇지 않으면 인시던트 원인이 되는 요인을 진단하는 데 도움이 되는 핵심 세부 사항이 왜곡되기 때문입니다. 그러나 모든 인시던트에 사후 분석이 필요한 건 아니고요.
인시던트가 반복되거나, 대응하기 어려운 인시던트가 일어나면 사후 분석 문서를 작성하는 게 좋습니다. 

이밖에 자세한 내용은 본문을 확인해 주세요.
🤔
DevOps 혹은 GitLab에 대한 고민이 있으신가요?  

온라인상에 많은 정보는 있으나,
내가 원하는 케이스와 동일한 케이스는 찾을 수 없고, 
비용을 떠나서 질문할 곳을 찾기 어렵진 않으신가요?  

인포그랩은 여러분의 고민을 함께할 준비가 되어있는 "DevOps 전문기업" 입니다.
인포그랩 유한회사 | 031-712-0929 | support@infograb.net
경기도 성남시 분당구 백현로 101번길 17, 초림프라자 511-512호 
구독신청 | 수신거부