IT 기업의 기술 블로그는 단순히 기술 지식과 정보를 나누는 통로에만 그치지 않습니다. 이는 기업의 기술력과 개발 문화를 대외로 드러내는 창구이기도 한데요.

프로젝트 관리와 개발 업무가 압도적으로 복잡할 때가 있습니다. 이슈가 산적한 가운데 우선순위를 분류하고, 여러 요청 사항을 관리하는 일이 거대한 벽처럼 느껴질 때도 있죠.

최근 조사 결과, 소프트웨어 라이프사이클의 배포 단계에 속하는 GitLab Environments 기능의 채택률은 낮고 이는 일부 유용성 문제에 직면한 것으로 나타났습니다.

여러분은 릴리즈 노트를 어떻게 작성하고 계신가요? 릴리즈 노트에 그저 ‘버그 수정’ 또는 ‘기능 개선’이라고만 쓰지는 않으신가요? 제품을 정기적으로 업데이트하다 보면 릴리즈 노트를 자칫 소홀히 작성할 우려가 있는데요. 릴리즈 노트를 관성에 기대어 성의 없이 쓰는 건 바람직하지 않습니다. 이는 릴리즈 노트가 소프트웨어 릴리즈 프로세스에서 중요한 역할을 하기 때문인데요. 릴리즈 노트는 제품 성과를 대내외에 공유하고, 사용자 또는 기업 내 구성원이 제품을 잘 이해하고 활용하도록 지원하며, 기업과 고객이 원활하게 소통하도록 돕습니다.

정리하면, 릴리즈 노트는 API 문서나 가이드처럼 독자(사용자, 기업 내 구성원 등)를 대상에 두고 작성하는 콘텐츠고요. 이에 독자 관점에서도 릴리즈 노트를 이해하기 쉽게, 도움이 되도록 써야 합니다. 엔지니어는 일상 업무로 릴리즈 노트를 종종 작성하는데요. 그렇다 보니 엔지니어 스스로 ‘난 릴리즈 노트 작성 방법을 잘 안다’라고 생각할 수도 있습니다. 이러한 생각은 자칫 독자, 그중에서도 사용자 입장을 더 고려하지 않고 엔지니어 관점에서만 릴리즈 노트를 쓰도록 이끌 수도 있는데요. 우리가 바람직한 릴리즈 노트 작성 방법을 꾸준히 공부하고, 관련 지식을 업데이트해야 할 이유입니다.

이 글에서는 릴리즈 노트를 효과적으로, 명확하게 써서 독자와 원활하게 소통하는 방법을 알아보려고 합니다. 먼저 릴리즈 노트의 개념과 중요성, 효과적인 릴리즈 노트 작성 방법을 살펴보고요. 아울러 인포그랩 프로덕트 팀의 릴리즈 노트 작성 방법을 소개하겠습니다.

지난 포스팅에서는 ‘커밋 메시지가 무엇이며 인포그랩은 어떤 커밋 컨벤션을 사용하는지’ 알아보았습니다. 이모지를 쓰고 이슈 번호도 넣은 커밋 메시지는 추적하기 쉽고, 보기에 좋습니다. 하지만 커밋 메시지가 길고 복잡할수록 매번 불편하고 실수도 잦아집니다.

GitLab 및 여러 기업은 페어 프로그래밍(짝 프로그래밍)을 통해 혼자 해결하기 어려운 과제들을 해결해 나가고 있습니다. 이 글에서는 페어 프로그래밍이 무엇이고, 어떤 장점이 있는지 확인해보고, 또 원격 페어 프로그래밍의 장점 및 적절한 활용을 위한 4가지 팁을 알아보겠습니다.

git 커밋 메시지가 모든 소프트웨어 엔지니어에게 중요하다는 것은 이미 알고 계실 거라 생각합니다. 잘 만든 커밋 메시지는 다른 개발자에게 변경 사항을 전달하는 가장 쉽고 간편한 방법이기 때문입니다. 그래서 기업의 대규모 프로젝트는 당연하고 협력의 비중이 낮은 소규모의 사이드 프로젝트에서도 커밋 컨벤션을 따로 만들어서 규칙을 지키기도 합니다.

이번 포스팅에서는 좋은 커밋 메시지의 중요성과 커밋 메시지 잘 쓰는 법을 알아봅니다. 더불어 인포그랩 프로덕트 팀의 커밋 컨벤션을 소개합니다.

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

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

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

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