README 파일은 코드 프로젝트의 첫인상을 결정짓는 중요한 콘텐츠입니다. 이는 코드의 존재 이유와 코드가 해결하는 문제, 코드의 중요성을 이해하도록 돕는데요. 훌륭한 README는 프로젝트의 성공에도 큰 영향을 미칠 수 있죠.

IT 업계에 종사하는 개발자와 DevOps 엔지니어라면 README를 올바르게 작성하는 방법을 당연히 숙지해야 하는데요. 이 글에서는 README의 중요성과 기능, 위치, 그리고 포함해야 할 내용 등을 다루고자 합니다. 아울러 README를 작성할 때 지켜야 할 기본 원칙과 요건도 살펴보겠습니다.

이 글에서는 GitLab의 ‘Project Import’ 기능을 활용해 GitHub에서 GitLab으로 프로젝트를 마이그레이션 하는 방법을 소개합니다. 아울러 GitHub Actions에서 GitLab 파이프라인으로 수동 마이그레이션 하는 방법도 알아봅니다. A 플랫폼에서 B 플랫폼으로 마이그레이션 하는 과정을 복잡하고 어렵게 느끼는 분들도 있을 텐데요. GitLab에서는 마우스 클릭 몇 번으로 쉽고 간단하게 마이그레이션을 진행할 수 있습니다.

현대 소프트웨어 개발 환경에서는 빠른 속도와 높은 품질을 동시에 달성하는 것이 매우 중요합니다. 이를 위해 DevOps 문화와 CI/CD(Continuous Integration/Continuous Deployment) 접근 방식이 강조되고 있고요. 오늘날 개발 속도를 높여 고품질 소프트웨어를 만드는 데 도움이 되는 다양한 도구가 개발되고 있습니다. 그중에서도 GitLab CI/CD와 Jenkins는 CI/CD 파이프라인을 구축하고 관리하는 데 널리 사용되는 도구인데요. 이는 개발팀과 운영팀의 협업 프로세스를 자동화하여 생산성을 높입니다.

6월 26일, GitLab 코리아에서 16번째 밋업을 진행하였습니다. 이날은 평소보다 많은 분이 밋업에 참가해 주었는데요. 아마도 밋업 주제가 상당한 흥미를 불러온 것으로 생각합니다. 이날의 밋업 주제는 ‘GitLab + AI로 생산성 **높이기, 코드 리뷰 자동화’**였습니다.

밋업은 세션 1, 2로 나눠 진행됐습니다. **세션 1에서는 유인철 GitLab 코리아 이사가 ‘GitLab AI Assisted 주요 기능 알아보기’**를 주제로 발표했고요. 주요 내용으로 Code Suggestions, Suggested Reviewers 등 업무에 강력한 도움을 주는 AI 기능을 모은 GitLab Duo를 설명했습니다.

**세션 2에서는 신철호(Dexter) 인포그랩 이사가 ‘GitLab MR에서 코드 리뷰하기 - GPT & Plumber를 활용한 코드 리뷰 자동화’**를 주제로 발표를 진행했습니다. 주요 내용으로 리뷰의 중요성 및 다른 IT 회사의 모범사례, 코드 리뷰 자동화 방안을 설명해 주었고요. 코드 리뷰에 사용하는 도구로 ‘Plumber’도 소개했습니다. Plumber는 CI/CD 파이프라인을 손쉽게 구축하도록 도와주는 제품으로, 인포그랩이 개발했습니다.

최근 AI를 활용한 업무 자동화로 생산성을 높이는 것이 큰 화두인데요. 두 세션 모두 공통적으로 AI를 활용하여 업무를 효율적으로 수행하는 기능 및 방법을 알아보는 시간이었습니다. 이 글에서는 이번 밋업의 주요 발표 내용을 살펴보겠습니다.

빠르게 변화하는 소프트웨어 개발 세계에서 시간은 귀중한 자원입니다. 개발자는 워크플로의 생산성과 효율성을 개선하기 위해 끊임없이 노력합니다. 이 글에서는 일상적인 개발자 경험을 혁신하는 대규모 언어 모델(LLM) 기반 기술인 ‘코드 제안’을 소개합니다.

다음은 코드 제안의 사용 사례입니다:

• 작업 간소화
• 신규 개발자의 언어 탐색 지원
• 숙련된 개발자의 잦은 웹 검색 필요성 제거

이 모든 사례는 코드 제안이 어떻게 일상적인 개발자 경험을 향상하는지 보여주는 예시입니다. 이러한 사용 사례의 구체적인 예를 살펴보겠습니다.

지난달 27일 GitLab 코리아 15번째 밋업이 온라인으로 진행됐습니다. 이날 밋업 주제는 **‘GitLab이 옵저버빌리티(Observability)를 만드는 방식’**이었는데요. Observability는 ‘외부 데이터에서 시스템 내부 상태를 얼마나 잘 유추할 수 있는지’ 나타내는 척도이죠.

밋업은 세션 1, 2로 나눠 진행됐습니다. 세션 1에서는 유인철 GitLab 코리아 이사가 ‘Observability를 향한 GitLab의 새로운 여정’을 주제로 발표했고요. Observability 개념과 GitLab의 Observability 전략, 원칙, 올해 출시할 기능을 공유했습니다.

세션 2에서는 신철호(Dexter) 인포그랩 이사가 ‘오픈 소스로 시작하는 Observability’를 주제로 발표했고요. Observability를 바라보는 엔지니어 관점과 Observability 필요성, 발전 과정을 소개했습니다. 또 Observabilit 도구인 Open Telemetry, SigNoz를 알아보고, SigNoz 데모도 선보였죠. 이 글에서는 지난 밋업의 주요 발표내용을 살펴보겠습니다.

GitLab의 중요한 기능 중 하나는 코드 빌드, 테스트 및 배포 과정을 자동화할 수 있는 CI/CD 파이프라인입니다. 그러나 프로젝트가 커지면 Job 수, 단계 수, 스크립트 및 의존성 수 등 많은 요소로 인해 파이프라인이 느려질 수 있습니다. 느린 파이프라인은 개발 프로세스에 부정적인 영향을 미칠 수 있으며, 시장 진입 시간이 증가하고 귀중한 자원을 낭비할 수 있습니다.

React는 사용자 인터페이스를 구축하기 위해 널리 사용되는 JavaScript 라이브러리입니다. 이 튜토리얼에서는 새로운 리액트 어플리케이션을 만들고 GitLab에서 CI 프로세스의 일부로 유닛 테스트를 실행하고 테스트 결과와 코드를 파이프라인에 출력하는 방법을 배울 수 있습니다.

오늘날 모든 회사는 소프트웨어 회사이므로 혁신 및 제공 수준이 수익 창출에 직접적인 영향을 미칩니다. 성공하기 위해 기업은 놀라운 디지털 경험을 제공하고, 최신 기술을 따라잡고, 고객이 요구하는 속도로 가치를 제공하고, 중단이나 보안 위반에 대해 무관용으로 모든 작업을 수행해야 합니다. 여기서 Value Stream Management(VSM)이 시작됩니다.

지난 MergeRequest로 개발 협업하기를 끝으로 디자이너, 개발자, PM이 서로 커뮤니케이션하고 협업하는 과정을 배워봤습니다.

하지만 구체적으로 뭐가 좋은지 아직 감이 안 잡히는 분들도 계실 겁니다.
그래서 역할별로 MR(Merge Request)의 장점을 총정리하는 시간을 가져 보겠습니다.

지난 MergeRequest 만들기 포스트에서는 PM(Project Manager)이 이슈를 생성하고 디자이너와 협업하며 MR를 생성하는 부분까지 진행하였습니다.

이번엔 MR(MergeRequest)로 개발자와 협업하는 방법에 대해 자세히 알아보겠습니다.

DevOps를 적용한다고 하면, CI/CD를 포함하는 자동화를 제일 먼저 생각하게 됩니다. CI/CD를 완료성있게 구축하고 운영하는 일은 간단하지 않습니다. GitLab과 같이 단일 도구를 사용하면 조금 더 간단해질 수 있습니다. GitLab은 CI/CD 스크립트를 레파지토리에 .gitlab-ci.yml 파일로 소스 코드 관리하는 방식으로 이용됩니다. 소스 코드가 업데이트 되면, 파이프라인 결과를 확인할 수 있습니다. Merge Request 화면에서도 변경에 대한 파이프라인 결과를 확인하면서 자동화 테스트, 보안 테스트, 배포 결과를 확인할 수 있는 피드백을 주고 받을 수 있습니다. 이 과정을 단순화시키고 활용할 수 있는 방법을 DevOps 실무자들이 만들어갑니다. 인포그랩은 GitLab을 사용하는 실무자들이 CI/CD 파이프라인을 쉽게 운영관리할 수 있는 밀키트를 만들기 시작했습니다. 프로젝트마다 CI 스크립트를 복사 & 붙여넣기 하지 않고 템플릿으로 쉽게 관리할 수 있습니다.

지난 'MergeRequest 왜 사용해야 할까?'에서는 협업을 하면서 발생하는 문제점과 MR(MergeRequest)의 이점을 살펴보고 MR을 사용해야하는 이유를 알아보았습니다.

오늘은 본격적으로 MR 사용법을 배워보도록 하겠습니다.

프로젝트 협업 어떻게 하는게 좋을까요?

우리의 삶에서 인터넷을 떼어 놓을 수 없듯이 어떤 서비스를 하든 소프트웨어가 빠지는 곳이 없습니다. 소프트웨어의 사이즈는 거대해졌고, 기술과 사회는 빠르게 변화하고 있습니다. 그래서 보다 빠르게 개발하고 배포하는 것이 중요해졌습니다. 이를 위해 다수의 사람들이 협업하여 개발을 진행하고 있습니다. 그런데 수많은 사람들이 협업을 하는데 문제가 발생하지 않을까요? 여러 사람들과 협업을 하다보면 다양한 문제를 마주치게 됩니다.

구축형 GitLab을 설치해보셨거나 설치하실 계획이 있으신가요? 구축형 GitLab을 사용하기 위해 고려해야 하는 상황은 다양합니다. 사용하는 유저의 수, 가용성, 클라우드 네이티브 환경 여부 등 이러한 환경에 대해 전부는 아니지만, 구축에 참고할 수 있는 레퍼런스 아키텍처를 오늘 소개해 드리려 합니다.

• 일반적인 환경에서 1,000명의 사용자를 기준으로 작성된 아키텍처
• 클라우드 네이티브 환경에서 사용가능한 2,000명의 사용자를 기준으로 작성된 아키텍처

더 다양한 레퍼런스 아키텍처가 필요하신 경우에는 GitLab 공식 Docs를 참고하시기 바랍니다.