• 파일 로 마이그레이션• 5.2. 메이븐봄을 그레이들봄으로 변경 5.3. 스프링이 관리하는 의존성 라이브러리의 버전 명시 제거 5.4. 블록을 블록으로 대체 5.5. 코틀린이 관리하는 아티팩트( ) 제거• 6.1. 마커 없는 아티팩트 블록에서 사용안녕하세요. 쏘카 서비스 엔지니어링본부 에셋(Asset)팀 백엔드 개발자 원스톤입니다. 저는 쏘카 존과 차량 도메인을 개발하고 있습니다.구성 코드를 적절히 관리해야만 지속 성장하는 소프트웨어를 만들 수 있습니다. 그레이들 빌드 스크립트 또한 지속 성장 가능한 소프트웨어 코드의 일부입니다. 지금부터 레거시 빌드 스크립트를 개선한 사례를 소개하겠습니다.개선 작업이 필요했던 이유를 먼저 소개하고, 의 현황 분석과 마이그레이션 및 리펙토링, 전체 그레이들 멀티모듈 프로젝트에 대한 마이그레이션 순으로 소개하겠습니다. 쏘카는 코틀린 스프링을 표준 기술로 채택하여 신규 프로젝트는 그레이들 코틀린 DSL을 사용합니다. 하지만 오래전 그루비 스크립트 언어로 개발되어 복잡하고 관리되지 않고 방치된 DSL 스크립트도 존재 합니다. 프로젝트마다 괸리 방식이 다르고 표준화 되지 않아 신규 개발자가 상황을 파악하고 개발하는데 어려움을 겪었습니다. 이에 그레이들 빌드를 활용해 코틀린 DSL와 그루비 DSL을 구성하고 작은 단위로 점진적 개선을 결정했습니다. 그레이들 8.x 버전부터 코틀린 DSL이 기본 언어로 채택 되었고 스크립트 코드의 자동완성을 지원 합니다. 더불어 코틀린 DSL은 컴파일 시점에 오류 확인이 가능해, 런타임 시점에 오류를 발견해야 하는 그루비 DSL에 비해 문법 오류를 명확하게 발견할 수 있는 장점이 있습니다. 모든 개발자가 겪는 어려움이지만 쏘카도 빠르게 성장하는 비즈니스의 요구사항을 충족하기 위해 기술 부채 청산에 시간을 할애 하기 어렵습니다. 비즈니스 요구사항 개발 속도에 영향이 없도록 개선 작업은 작은 단위로 분할하여 점진적으로 진행했습니다. 명령어로 확인해 보니 그레이들 프로젝트는 복잡한 멀티모듈 프로젝트로 구성되어 있습니다.루트 프로젝트(Root project)에 과 , 파일로 구성 되어 있으며, 하위 프로젝트(Project)에 단일 파일이 있습니다. 우선 루트 프로젝트의 파일부터 마이그레이션 하기로 결정 했습니다. 레거시 파일은 아래와 같습니다.• 블록에 루트 프로젝트 및 하위 프로젝트에서 사용할 ext 프로퍼티를 선언하고, 메이븐 센트럴 혹은 프라이빗 메이븐 레포지터리의 아티팩트(jar 파일)의 의존성을 선언합니다.• 블록에 루트 프로젝트 및 하위 프로젝트 전체에서 사용할 리포지터리를 선언합니다.• 블록에 각 서브프로젝트에서 사용할 의존성을 선언합니다.• 확장 블록에 mavenBom을 이용해 하위 프로젝트에서 루트 프로젝트의 스프링 버전과 호환되는 서드 파티 의존성 라이브러리들의 버전을 자동 구성합니다. 하위 블록으로 스프링의 의존성 봄을 가져오고 블록에서는 스프링이 관리하는 의존성 버전을 오버라이딩하여 버전을 직접 관리합니다.* , , 는 그레이들 예약어로 블록이라 부르며, 의 경우

소개안녕하세요 빅데이터플랫폼파트1셀에서 근무하고 있는 koodin입니다. 어느덧 카카오와 함께한 지 2년이 훨씬 지났는데요, 그동안 상용 하둡 플랫폼에서 카카오 하둡 플랫폼(KHP)으로의 전환 프로젝트를 진행하게 되었습니다. 여기에서는 대규모 데이터 이관을 더 쉽고 빠르게 하기 위해 개발하게 된 Pojang24에 대한 소개와 어떤 요구사항이 있었는지, 또 이를 만족하기 위해 어떠한 고민을 했고 어떻게 풀어갔는지에 대해 이야기해보려 합니다.데이터를 옮겨야 합니다카카오의 많은 부서들이 사용 중인 카카오 공용 하둡에는 수많은 파일과 디렉터리가 있습니다. 그리고 일정 주기마다 오래된 데이터를 콜드 스토리지(Cold storage)로 이관하는 아카이빙 잡(Job)들이 있습니다. KHP 프로젝트를 성공적으로 마무리하기 위해서는, 파일 이관과 더불어, 아카이빙 잡들을 신규 클러스터로 옮기는 작업이 반드시 필요했고, 때마침 신규로 입사하게 된 제가 담당하게 되었습니다.먼저, 수십 페타바이트 수준의 데이터를 옮겨야 하는 목표를 듣고 어떤 것들을 할 수 있는지 생각했습니다. 수동으로 처리하기에는 너무나 많은 데이터가 존재했기 때문에, 이관을 관리해주는 시스템이 있으면 좋겠다는 생각이 들었습니다. 또한 공용 하둡의 데이터 관리자들이 모두 개발자는 아니기에 하둡을 잘 모르더라도 손쉽게 데이터를 이관할 수 있는 시스템을 만들어야 되겠다는 생각을 했습니다.Oozie 기반의 카카오의 기존 아카이빙 시스템은 하둡 관리자가 잡과 인프라를 관리하는 구조로 되어 있었습니다. 만약 새로운 아카이빙 요청이 들어오면, 관리자는 수동으로 스크립트를 작성하여 새로운 아카이빙 잡이 실행되도록 했죠. 그래서 여러 부서의 테이블 구조를 알고, 작업이 실패했을 경우 확인하는 작업까지도 하둡 관리자가 관리하고 있었습니다.아파치 우지(Apache Oozie) 하둡의 잡을 관리하기 위한 워크플로 스케줄링 시스템(https://oozie.apache.org/)이러한 상황에서 기획 중인 사내 시스템은 데이터 이관 외에도 기존 아카이빙 시스템을 개선하자는 목표를 세웠습니다. 이를 위해 첫째, 하둡 관리자가 직접 모든 데이터 아카이빙 작업을 관리하는 게 아닌 사용자가 직접 데이터 플로우를 관리할 수 있도록 하고, 둘째, 기존 아카이빙 시스템을 보완하고 아키텍처의 변경을 통해 하둡 관리자가 아카이빙 작업을 운영하는 비용을 줄이고 싶었습니다.정리하자면 사내 시스템은 아래 주요 목표를 달성하기 위해 기획되었습니다.데이터 이관을 쉽게 한다.아카이빙 시스템을 개선한다.그리고, 위 두 가지 요구사항을 만족시키는 시스템을 개발하면서 클러스터 간 데이터 이사를 24시간 쉽게 해주는 시스템이란 뜻으로 “Pojang24(포장이사)”라고 이름을 지었습니다.기존 아카이빙 시스템을 개선합시다기존 아카이빙 시스템은 여러 가지 불편한 점이 있었습니다. 첫째로 재처리에 대한 자동화가 되어있지 않았죠.아카이빙이 어떤 문제로 인하여 실패했을 경우 위와 같은 알람 메시지를 받게 되고 관리자는 실패된 건에 대해서 수작업으로 재처리했습

안녕하세요, 디어코퍼레이션 물류팀 개발리드 김명재입니다. 2022년 5월에 이 회사에 입사한 이후에 조직의 제품 개발 생산성을 높이기 위해 고군분투하고 있습니다. 5개월이라는 길지 않은 시간이었지만 개발 프로세스를 정비하고 효율을 높이기 위해 도입했던 절차와 아이디어들을 공유하고 싶습니다.Shape Up“… 생각할 시간이 부족해요.”디어 물류팀의 첫 번째 필드테스트(개발한 제품을 물류 주선사의 직원분들에게 제공해서 사용자 반응을 관찰)와 지금까지의 개발 방식을 회고하면서 개발자들이 모두 동의했던 문장입니다. 개발 방식에 어떤 변화가 필요할지 고민하던 중에 은성이(물류팀 개발자)가 Shape Up이라는 개발 방법론을 들고 왔습니다.첫 인상Shape Up은 개발 방법론이면서 책 이름이기도 합니다. 이 책은 웹에 무료로 공개되어 있고 pdf로 받아볼 수도 있습니다. 저는 Introduction을 읽으면서부터 강렬한 인상을 받았습니다.Ruby on Rails첫 번째 강렬한 인상은 Ruby on Rails가 Basecamp라는 프로덕트를 만들면서 탄생한 부산물이라는 것입니다. Ruby on Rails의 핵심 철학인 ‘Convention over Configuration’은 Spring Boot가 탄생하는 데 큰 기여를 했습니다.- Convention Over Configuration: Rails has opinions about the best way to do many things in a web application, and defaults to this set of conventions, rather than require that you specify minutiae through endless configuration files.- https://guides.rubyonrails.org/getting_started.htmlBasecamp는 회사 이름인 동시에 프로덕트 이름입니다. 2003년에 Basecamp(회사)는 웹사이트 디자인을 하는 컨설팅 회사였습니다(At the time we were a consultancy designing websites for clients).일을 하면서 고객, 디자이너, 프로젝트 매니저 간의 의사소통에서 발생하는 정보 파편화와 문제를 겪었고, Basecamp는 이 문제를 해결하기 위해 정보를 한곳에 모을 수 있는 제품을 만들었습니다. 많은 회사가 동일한 문제를 겪고 있었고 오늘날에는 수백만 명의 사람들이 다양한 업종에서 Basecamp를 사용하고 있습니다.Basecamp의 첫 번째 버전은 Basecamp 설립자인 Jason Fried, 공동 설립자이자 프로그래머인 David Heinemeier Hansson, 그리고 디자이너인 Ryan Singer가 만들었습니다. David는 당시 Basecamp에 주당 10시간밖에 할애할 수밖에 없는 상황이었기 때문에 Basecamp는 코딩할 수 있는 10시간을 최대한 생산적으로 사용해야만 했습니다.10시간의 제약조건을 극복하기 위해 Basecamp는 해야 할 일의 범

안녕하세요, 29CM Android 개발자 오유원입니다.이번 글이 저희 Android 팀의 첫 글이 될 예정인데요, 이번 글에서는 Github Actions 를 도입하여 저희 Android 팀의 기존 배포 파이프라인을 개선해 Continuous Delivery 를 구축한 내용을 소개해 드리고자 합니다.전환 배경19년도 초까지는 Android 팀에 배포 파이프라인 자체가 존재하지 않았습니다. 그래서 매 릴리즈 마다 각 팀원들의 머신에서 앱을 직접 아카이브 해 팀에 공유 하고 있었는데요, 그러다 보니 바이너리 배포를 위해 빌드를 돌리는 동안 다른 작업을 하지 못하고 기다리는 시간이 주기적으로 발생했습니다.위 상황을 개선하기 위해 2020년 초 팀에 익숙했던 Jenkins 를 사용해 사내 빌드를 팀에 배포할 수 있도록 하는 체제를 구축했었는데요, 다만 Jenkins 를 사용하면서도 팀에서는 여러 불편함을 느끼게 되었고 지속적 배포를 하는 환경까지는 완성하지 못했던 상태였기에 팀에서는 추가적인 시스템 개선을 고민하는 상태였습니다. 이후 여러 도구를 조사하면서 Github Actions 를 알게 되었고 결과적으로 이 도구를 도입해 생산성을 많이 끌어올릴 수 있었습니다.그래서 이번 글에서는 GitHub Actions 에 대한 소개를 시작으로 팀이 기존에 겪고 있던 문제들이 무엇인지 살펴보고, 이를 어떤 식으로 개선해 나갔는지 말씀드리겠습니다.기존의 앱 배포 파이프라인 — Jenkins개선 작업을 하기 전 저희 팀은 많이 사용되는 도구 중 하나인 Jenkins 를 기반으로 파이프라인을 구성하고 있었습니다.사내 내부 서버에 아래와 같이 구성을 해두었는데 이를 팀에서 사용하는데 몇 가지 불편함이 있었습니다.Jenkins 시스템 구성도Jenkins 인스턴스가 내부 서버에 떠있다 보니 VPN 을 통해야만 접속해야 했는데요, 사내 배포는 일상적으로 많이 일어나는 활동이나 보니 재택이 일상화된 환경이 되고 나서는 생각보다 불편함을 주는 요소였습니다. 그래서 VPN을 사용하지 않고도 파이프라인을 구성할 수 있는 방향을 먼저 고려하게 되었습니다.또한 저희가 기존에 구축한 환경에서는 앱을 배포할 때마다 Jenkins 콘솔에 접속하여 정보를 입력해야만 하는 형태로 구성되어 있었고, 아래처럼 정보 입력 후 버튼을 눌러야지만 빌드를 시작할 수 있었습니다. 즉 Continuous Delivery 가 구축된 상태는 아니었습니다. 사소한 부분이지만 이런 요소들이 모여 팀의 생산성을 조금씩 낮추고 있다는 생각이 들었습니다.Jenkins 콘솔 화면저희 팀 구성원들은 프로덕트팀 내 여러 스쿼드에 각각 소속되어 일을 하고 있는데요, 그러다 보니 각 스쿼드의 피쳐 중간 개발물이나 개발 후 QA 반영사항을 적용한 빌드를 사내에 지속적으로 배포하고 있어서 매번 Jenkins 에서 위 작업을 반복해야만 하는 번거로움이 발생할 수밖에 없었습니다.또한, 저희가 구축한 환경에선 Jenkins 에서 아카이브를 시작할 때 레포의 브랜치 정보가 동기화되어있지 않아 아래와 같이 오타가 있을 때는 프로세