SmartEditor 팀은 항상 높은 수준의 코드 품질을 유지하기 위해 노력하고 있습니다. 그런 모습이 코드 리뷰에서도 드러납니다.하지만 열심히 노력하는 팀임에도 불구하고 몇몇 부분에서 개선의 여지가 있었습니다. 코드 품질을 엄격하게 관리하다 보니 가끔은 리뷰가 길어지고 그로 인해 pull request(이하 PR) merge까지 긴 시간이 소요되기도 했습니다. 또한 바쁜 일정 속 우선순위에서 밀려 리뷰에 적극적으로 참여하지 못할 때도 있었습니다.이에 팀의 코드 리뷰 문화 개선에 관심이 있는 소수 인원이 모여 개선 활동을 시작했습니다.문제점먼저 저희를 제외한 팀원들의 의견을 파악하고자 했습니다. 다른 팀원들도 이 문제에 대해 같은 생각을 가지고 있는지 궁금했습니다. 그래서 다음을 포함한 몇 가지 문항을 구성하여 설문을 진행했습니다.리뷰하기 어려웠던 경험을 알려주세요.요청받은 리뷰를 늦게 확인/승인하게 된 이유는 무엇일까요?코드 변경 라인 수는 몇 라인이 적당할까요?설문 결과, 팀원들도 문제에 대해 저희와 비슷하게 인식하고 있었습니다. 주요 응답은 다음과 같았습니다.코드 변경 사항이 많아서 리뷰가 어려웠다.이해도가 부족하여 리뷰가 어려웠다.나중에 리뷰하려다가 놓쳤다.리뷰어의 코멘트 응답이 늦어서 불편했다.정리해 보면 개선이 필요한 핵심 문제는 다음 두 가지였습니다.PR merge까지의 긴 소요 시간 낮은 리뷰 참여율이를 해결하기 위해 GitHub Actions를 활용해 데이터를 수집하고 분석하여 개선 방향을 찾고자 했습니다.데이터에서 인사이트 얻기pr-statsPR 데이터에 대한 통계를 산출하는 pr-stats 액션을 만들었습니다. 각 PR에 대한 통계, 전체 PR 통계, 사용자별 통계 정보를 제공하는 액션입니다.이 액션을 실행하여 CSV 파일이나 콘솔로 통계 결과를 얻을 수 있습니다. 다음은 콘솔로 통계 결과를 출력한 화면입니다. 각각 PR에 대한 통계, 전체 PR 통계, 사용자별 통계 결과입니다.각 PR에 대한 통계에서는 제목, PR 생성 시점, merge 시점, 변경된 라인 및 파일 수 등의 정보를 얻을 수 있고, 전체 PR 통계에서는 대상 PR의 평균 데이터를 얻을 수 있습니다. 마지막으로 사용자별 통계에서 개인별 리뷰 참여 수, 참여율, 평균 응답 시간 등을 확인할 수 있습니다.액션에 대한 더 자세한 내용은 GitHub - naver/pr-stats를 확인 바랍니다.데이터 수집 결과pr-stats 액션을 이용해 최근 2년의 데이터를 수집해 봤습니다.수집 결과 merge까지 평균 약 4일의 시간이 소요되었고, 평균 리뷰 참여율은 67%임을 확인할 수 있었습니다. 예상했던 것처럼 merge까지 긴 시간이 소요되고 리뷰 참여율도 그다지 높지 않았습니다.해결 과정앞서 언급한 두 가지 문제를 각각 어떻게 해결했는지 알아보겠습니다.1. PR merge까지 소요되는 시간 단축상관관계 분석먼저 어떤 데이터가 PR merge까지 소요된 시간과 관련이 있는지 알아보고자 했습니다.이에 생성형 AI를 활용하여, pr-stats 액션으로 얻은 데이터로

Homebrew는 macOS를 위한 오픈 소스 패키지 관리자로, 개발자들 사이에서 필수 도구로 자리 잡았습니다.CLI 인터페이스를 통해 다양한 소프트웨어를 쉽게 설치, 업데이트, 관리할 수 있게 해주며, 의존성 문제도 자동으로 해결됩니다.이러한 편의성 덕분에 Homebrew는 macOS 사용자들, 특히 개발자들에게 없어서는 안 될 도구가 되었습니다.이번 글에서는 이전에 소개한 ALN(Amazing Lucky Numbers) 라이브러리를 macOS용 Homebrew 패키지로 만들고, TAP을 통해 bottle로 배포하는 과정을 상세히 다루겠습니다.Formula 작성, bottle 빌드, TAP 저장소 설정, 그리고 최종적으로 사용자들이 쉽게 설치할 수 있도록 패키지를 배포하는 방법까지 단계별로 설명하겠습니다.Homebrew는 맥주 양조에서 영감을 받아 이름이 지어졌으며, 많은 용어들이 맥주 제조 과정과 관련이 있습니다.실제로 명령으로 패키지를 설치할 때 터미널에 맥주 아이콘이 표시됩니다.각 용어에 대해 Homebrew에서의 의미와 맥주 양조에서의 의미를 함께 설명하면 다음과 같습니다.• None• None 가정에서 직접 만드는 수제 맥주• None Brew: 패키지를 설치하거나 관리하는 주요 명령어• None 맥주를 만드는 과정 자체• None• None 맥주 제조를 위한 재료와 방법을 기술한 레시피• None Cellar: Homebrew가 패키지를 설치하는 디렉토리 (기본 위치: Intel mac - /usr/local/Cellar, Apple Silicon Mac - /opt/homebrew/Cellar)• None 맥주를 저장하고 숙성시키는 공간• None• None 맥주를 저장하고 서빙하는 데 사용되는 통• None Tap: 공식 저장소 외에 사용자가 추가하여 사용할 수 있는 Formula 저장소• None 맥주를 따르는 데 사용되는 밸브나 꼭지• None Cask: GUI 애플리케이션을 관리하기 위한 Homebrew의 확장 기능• None 대량의 맥주를 저장하고 운반하는 데 사용되는 큰 통• None Bottle: 미리 컴파일된 패키지 버전으로, 설치 시간을 크게 단축시킴• None 맥주를 담아 판매하거나 보관하는 유리병Homebrew 기반의 패키지를 만들어서 배포하는 과정을 맥주 용어로 다시 설명하면 아래와 같습니다.• None• None 맥주 제조를 위한 재료와 방법을 기술한 레시피(Formula) 작성• None• None 맥주를 제조한 후 유리병(Bottle)에 담아 준비• None Github 저장소를 이용해 Tap 추가 및 패키지 설치• None 맥주 양조장을 통해 맥주를 받아옴(Tap). 병으로 바로 받거나(Bottle) 레시피(Formula)로 직접 제조Apple Silicon Mac 기준으로 Homebrew는 디렉토리를 사용하는데, 세부 디렉토리는 아래와 같습니다.• None (Git 저장소): 이 디렉토리는 Homebrew의 루트 디렉토리이며, 동시에 Git 저장소입니다. 이를 통해 Homebrew 자체의 업데

Fedora는 Red Hat이 후원하는 커뮤니티 기반의 오픈소스 운영 체제로, 6개월마다 새로운 버전을 출시하여 최신 소프트웨어와 혁신적인 기능을 빠르게 도입하는 것을 목표로 합니다.RPM(Red Hat Package Manager)은 이러한 소프트웨어를 관리하기 위해 사용되는 패키지 관리 시스템으로, 패키지의 설치, 업그레이드, 제거, 확인 등을 쉽게 수행할 수 있습니다.또한, RPM 패키지를 네트워크를 통해 사용할 수 있도록 YUM(Yellowdog Updater, Modified)과 DNF(Dandified YUM) 도구도 함께 사용됩니다.이번 글에서는 이전에 소개한 ALN(Amazing Lucky Numbers) 라이브러리를 Fedora Linux용 RPM 패키지로 만드는 과정을 다루겠습니다.패키지 생성에 필요한 파일 구조, 제어 파일 작성, 빌드 과정, 그리고 최종적으로 패키지를 생성하고 배포하는 방법에 대해 설명하겠습니다.Fedora에서 패키지 설치 시 사용되는 파일은 확장자를 사용합니다. 아래에서 이 파일의 형식과 구성에 대해 자세히 알아보겠습니다.파일은 아카이브 형식으로 되어 있으며, 와 도구를 통해 내부의 데이터를 추출할 수 있습니다.패키지 파일은 바이너리 패키지인 파일과 소스 패키지(SRPM)인 파일이 있습니다.바이너리 패키지는 시스템에 설치할 파일들을 담고 있고, 소스 패키지는 소스 아카이브와 스펙 파일( ), 패치 등을 담고 있습니다.참고로, 스펙 파일은 패키지의 빌드와 설치를 정의하는 파일로, 패키지명, 버전, 릴리즈, 설명, 라이선스, 소스 URL, 빌드 의존성, 설치 파일 목록 등을 포함하고 있습니다.네트워크 설치를 지원하는 도구를 이용해 패키지 설치, 삭제 뿐만 아니라 RPM 파일을 직접 다운로드 받을 수도 있습니다.명령이 이 때 사용되는데, 먼저 패키지를 설치해야 사용 가능합니다.아래와 같이 패키지를 설치하고 임의로 glib2 패키지를 다운로드 받습니다.바이너리 패키지 외에도 옵션을 추가하면 소스 패키지를 받을 수 있습니다.( , ) 명령을 통해 다운로드 받은 파일의 정보를 조회할 수 있습니다.파일을 추출하고 싶을 경우 아래와 같이 와 명령을 조합해서 사용할 수 있습니다.명령에 사용된 옵션은 아래와 같습니다.• None : 아카이브에서 파일을 추출RPM 패키지 이름은 일반적으로 다음과 같은 형식을 따릅니다.위의 glib2 패키지명( ) 기준으로 확인해 보겠습니다.이전 글에서 설명한 Debian의 deb 패키지와 비교해보면 아래와 같은 차이점이 있습니다.• None 아키텍쳐 이름: DEB는 를 사용하고 RPM은 를 사용합니다.• None 구분자: 이름과 버전, 아키텍쳐를 구분할 때 DEB는 와 를 사용하는데, RPM은 와 을 사용합니다.• None 개발용 패키지 이름: deb의 경우 이름 뒤에 를 사용하는데, RPM은 을 일반적으로 사용합니다.RPM 패키지를 정의하고 빌드하기 위해서는 스펙( ) 파일이 필요합니다.스펙 파일은 패키지의 메타데이터, 빌드 및 설치 지침을 포함하는 파일로, RPM 패키지를 구성하는 핵심 요소입니다스펙 파일은 여러 섹션으로 구성됩니다. 각 섹션은 패키지를 빌드하고 설치하는 데 필요한 정보를 제공합니다.주요 섹션은 다음과 같습니다:• None Header: 패키지의 기본 정보를 포함합니다.• None Description: 패키지에 대한 상세 설명을 제공합니다.• None Package: 단일 스펙 파일에서 여러 개의 패키지를 정의할 때 사용합니다.• None Prep: 소스를 준비하는 단계입니다.• None Build: 소프트웨어를 컴파일하는 단계입니다.• None Install: 소프트웨어를 설치하는 단계입니다.• None Check: 빌드 후 테스트를 실행하는 단계입니다.• None Files: 패키지에 포함될 파일 목록을 지정합니다.• None Changelog: 패키지의 변경 내역을 기록합니다.ALN 기준으로 실제로 작성해 보겠습니다.ALN에 대한 패키지 이름, 버전과 같은 기본 정보와 라이센스, 빌드 의존성 등을 명시합니다.Release 항목에 와 같은 값이 사용되었는데, 배포판 태그에 대한 매크로를 같이 사용한 표현입니다.최종적으로 과 같은 값이 반영됩니다. 쉘에서 아래와 같이 직접 값을 확인해 볼 수 있습니다.소스 파일에 대해 지정할 때 가 아닌 이 사용되었는데, 이 둘은 동일합니다.만약 소스가 여러개라면 등의 형식으로 추가 소스 파일을 지정합니다.또한, 에는 URL 기반 주소를 사용할 수 있습니다. 이 경우 패키징 과정에서 소스가 자동으로 다운로드됩니다.ALN의 경우 여러가지 패키징 방법에 대해 설명하기 위해 소스와 패키지 파일들이 같이 존재하므로 URL 없이 로컬 파일을 사용하도록 설정했습니다.패키지에 대한 상세 설명을 제공합니다. 이 섹션은 %description 키워드로 시작하며, 패키지의 기능과 용도를 자세히 기술합니다:단일 SPEC 파일에서 여러 개의 패키지를 정의할 때 사용되는데, 라이브러리, 실행 파일, 개발 파일 등을 별도의 패키지로 분리하여 관리할 때 유용합니다.위의 예제처럼 형태로 지정할 수 있으며, 서브 패키지 이름에 기본 패키지 이름이 접두사로 추가됩니다.이와 같이 설정할 경우, 기본 패키지 외에도 와 두개의 패키지가 추가로 생성됩니다.각 패키지에 포함할 파일들은 Files 섹션( )에서 정의할 수 있습니다.패키지를 빌드하기 위한 준비 작업을 수행합니다. 이 단계에서는 미리 정의된 과 매크로를 사용할 수 있고 필요에 따라 직접 쉘 명령어를 사용할 수도 있습니다.매크로는 소스 파일을 추출하고, 작업 디렉토리를 설정하는 데 사용하는데, 다음과 같은 옵션을 같이 사용할 수 있습니다.• None : 빌드 디렉토리 이름을 지정. 소스 압축을 해제했을 때 기대되는 디렉토리 이름( )과 실제 이름이 다를 경우 설정합니다.보다 자세한 설명은 https://rpm-packaging-guide.github.io/#setup에서 확인할 수 있습니다.빌드 단계를 정의합니다. Debian의 파일에서 다양한 빌드 시스템을 지원했던 것과 마찬가지로 RPM도 CMake, meson과 같은 빌드 툴을 지원합니

오픈 소스 세계에서 Ubuntu는 가장 인기 있는 Linux 배포판 중 하나입니다.CI/CD에 많이 사용되는 Github Action runner에서도 기본 Linux 이미지로 Ubuntu를 사용하고 있습니다.따라서 우리가 만든 라이브러리를 Ubuntu 사용자들이 쉽게 설치하고 사용할 수 있게 하는 것은 중요하며, 이를 위한 가장 효과적인 방법 중 하나가 바로 deb 패키지를 통한 배포입니다.deb 패키지는 Debian 계열 Linux 배포판(Ubuntu 포함)에서 사용되는 소프트웨어 패키지 형식입니다.이 형식을 사용하면 사용자들이 또는 명령어를 통해 쉽게 소프트웨어를 설치, 업그레이드, 제거할 수 있습니다.또한 의존성 관리, 설치 후 스크립트 실행 등 다양한 기능을 제공하여 소프트웨어 배포를 더욱 효율적으로 만들어줍니다.이번 글에서는 이전에 소개한 ALN(Amazing Lucky Numbers) 라이브러리를 Ubuntu Linux용 deb 패키지로 만드는 과정을 다루겠습니다.패키지 생성에 필요한 파일 구조, 제어 파일 작성, 빌드 과정, 그리고 최종적으로 패키지를 생성하고 배포하는 방법에 대해 설명하겠습니다.Ubuntu에서 패키지 설치 시 사용되는 파일은 확장자를 사용합니다. 아래에서 이 파일의 형식과 구성에 대해 자세히 알아보겠습니다.파일은 기본적으로 아카이브 포맷을 사용하는 압축 파일입니다. 압축을 해제하면 다음과 같은 파일들이 생성됩니다:• None• None 패키지 형식의 버전을 나타내는 텍스트 파일입니다. 현재 대부분 경우 버전은 입니다.• None• None 패키지의 메타데이터를 포함하는 압축 파일• None• None 실제 설치될 파일들을 포함하는 압축 파일입니다. 이 파일에는 실제로 시스템에 설치될 파일들이 들어 있습니다. 파일 구조는 실제 설치될 디렉토리 구조를 그대로 반영합니다.압축 파일에 포함된 메타데이터의 주요 파일들은 다음과 같습니다:• None : 패키지 이름, 버전, 의존성 등의 정보먼저 도구를 이용해 임의의 패키지를 하나 다운로드 받습니다. 명령으로 deb 패키지 파일을 직접 다운로드 받을 수 있습니다.이제 명령을 통해 압축을 해제합니다. 위에서 설명했던 것처럼 , 그리고 파일이 생성되었습니다.메타데이터를 확인하기 위해 패키지에 대한 정보가 들어있는 파일의 압축을 해제합니다.압축 해제 후 생성된 파일들 중 파일의 내용을 확인해보면 이 패키지에 대한 이름, 설명, 버전, 메인테이너 및 의존성 정보를 모두 알 수 있습니다.이제 실제 설치될 파일들을 담고 있는 파일도 압축을 해제합니다.이렇게 해서 패키지가 포함하고 있는 모든 파일들을 확인할 수 있었습니다.패키지를 만들 때 이름과 버전을 정해야 하는데, deb 패키지에서 일반적으로 사용하는 규칙이 있습니다.• None• None 라이브러리의 경우 일반적으로 앞에 를 붙입니다.• None 라이브러리의 major 버전 번호를 뒤에 붙입니다. 예: ,• None 라이브러리의 헤더 파일등을 포함하고 있는 개발(빌드)용 패키지의 경우 일반적으로 뒤에 를 붙입니다.• Non