티스토리 뷰
안녕하세요 Data Platform Engineer 조광진입니다.
2019년에 지마켓 Data Platform 팀에 합류하여 데이터 플랫폼에 관련된 다양한 업무를 진행하고 있습니다.
저희 팀에서 하는 업무에 대해 간단하게 설명드리면 글 전반적인 내용에 도움이 될 것 같아 먼저 소개하도록 하겠습니다.
Hadoop 기반의 빅데이터 플랫폼인 Data Lake 활용을 통해 전사에서 활용되는 데이터의 수집, 적재, 분석에 대해 직 간접적으로 도움을 드리고 있으며, 비정형 데이터를 다양하게 활용하기 위한 Redis, Elastic Search, MongoDB 데이터 플랫폼도 운영하고 있습니다.
Data Platform 팀이 사용하는 기술 스택은 아래와 같습니다.
팀 목표는 사용자들에게 안정적이고 편리한 데이터 플랫폼을 제공하는 것입니다.
신규 기술 도입의 필요성
팀 내에서 2019년 도입한 Hadoop 환경이 전체적으로 노후화됨에 따라 물리 장비 및 디스크 교체 작업, OS 버전 업그레이드, 보안 업데이트 등 전반적인 운영 리소스 비용이 많이 발생하게 되었습니다.
또한, 2019년 Hadoop Cluster의 리소스 요청 건에 비해 2022년 두 배 이상으로 리소스 요청이 늘어나게 되자 사용자들이 쿼리 혹은 Job을 통해 데이터를 분석, ETL 하는 데 있어 시간을 많이 소요하게 되고, 작업 실패도 빈번하게 발생하는 등의 불편함을 초래하게 되었습니다.
이에 따라 팀 운영 리소스를 줄이면서 안정적이고 빠른 데이터 분석을 위해 Cloud Native Platform 도입의 필요성이 팀 내에서 대두되었습니다.
저희 팀은 리서치를 통해 Spark 기반의 Data LakeHouse 플랫폼인 Databricks 가 가장 적합하다고 판단하여 Databricks 도입을 위한 신규 프로젝트를 진행하게 되었습니다.
JIRA를 통한 Databricks 프로젝트 관리
위 글에서 팀 운영 환경과 Databricks 도입이 필요한 이유에 대해 설명드렸습니다. Databricks 관련된 상세 내용은 저의 다음 글에서 작성하도록 하고, 본 글에서는 Databricks에 대한 주된 내용보다는 신규 프로젝트를 효과적으로 관리하기 위해 애자일 도구인 JIRA를 사용한 경험에 대해 소개하고자 합니다.
지마켓에서는 이미 대부분의 팀이 JIRA를 기반으로 프로젝트를 운영 및 관리를 하고 있습니다.
팀 내에서도 신규 프로젝트 관리를 위한 사용뿐만 아니라 기존 플랫폼에 대한 유지보수를 위해 JIRA를 사용하고 있으며, 플랫폼 사용 혹은 장애 문의에 대해서 JIRA로 요청을 받고 이슈를 해결하는 용도로도 사용하고 있습니다.
애자일 도구인 JIRA에 대해 이야기하기 전에, 모든 개발자분들이 잘 알고 있는 내용이겠지만 먼저 애자일에 대해 간단하게 용어 정리를 하고 넘어가 보도록 하겠습니다.
애자일이란?
Agile 이란 단어자체가 '기민한', '민첩한'이라는 의미를 가지고 있으며, 단어 의미에서 유추할 수 있듯 애자일은 시장 변화에 대해 유연하게 대처하는 개발 방법론입니다. 애자일의 대표적인 방법론 중 하나인 스크럼을 통해 신규 프로젝트 관리를 진행하려고 합니다.
스크럼이란?
스크럼은 반복적이고 점진적인 개발 방법을 말하며, 비즈니스 요구를 충족시키는데 초점을 맞춥니다.
'스프린트'라고 불리는 작업 단위를 사용하여 세분화된 항목에 초점을 맞추고 평균 2주 정도의 기간을 목표로 설정합니다.
스크럼 보드란?
스크럼 보드는 스프린트 백로그 항목을 볼 수 있도록 하기 위해 사용하는 프로젝트 관리 툴입니다.
현재 스프린트에서 완료해야 하는 모든 항목을 보여줍니다.
이제 저희 팀에서 JIRA를 통해서 진행되고 있는 Databricks 도입 프로젝트를 이야기해보겠습니다.
스크럼 단계
스크럼은 아래 명시된 단계로 진행하게 됩니다.
- 백 로그 만들기
- 스프린트 계획 및 시작
- 일일 스크럼 미팅
- 로드맵 활용하기
- 애자일 보고서 활용 및 반복
1. 백로그 만들기
프로젝트 백로그를 작성하는 단계입니다. 크게 프로젝트에 대한 요구사항과 그 요구사항을 만족시키기 위한 작업들을 구분하여 백로그를 작성합니다.
백로그를 만들 때, Issue Type을 설정할 수 있습니다. Issue Type은 아래 3가지로 구분됩니다.
- Epic: 완료하기까지 긴 시간이 필요하거나 몇 번의 스프린트가 요구되는 큰 업무 덩어리입니다. Epic은 여러 개의 Story 혹은 Task로 쪼개질 수 있습니다.
- Story: 유저 스토리로 불리며, 엔드 유저 관점에서 쓰인 간단한 요구 사항입니다. 하나의 심플한 이야기라고 할 수 있으며, 연관된 Story들이 모여 하나의 에픽을 형성합니다.
- Task: 스토리를 완료하기 위해 개발자가 작업하는 단위입니다.
진행하고 있는 Databricks 신규 프로젝트의 내용을 Issue Type으로 정의해보겠습니다.
- Epic: Data Lake House 플랫폼인 Databricks를 도입한다.
- Story:
- 클라우드 인프라 및 플랫폼 확보
- 플랫폼 보안 모델 개선
- Raw Data Pipeline 개발
- 플랫폼 운영 및 개발 가이드 작성
이 중 'Raw Data Pipeline'의 Story를 기준으로 Task를 작성하면 아래처럼 작성할 수 있습니다.
- Task:
- Kafka to Delta Lake Consumer 설계
- RDB to Delta Lake 설계
- NAS to Delta Lake 설계
- Delta File Optimizer 조사
- Delta Vacuum 조사
만약 Kafka to Delta Lake Consumer 설계 항목을 좀 더 디테일한 작업 내역을 나누고 싶다면 Sub-Task로 할당하도록 합니다.
- Kafka to Spark Streaming Data Flow 설계
- Delta Bronze to Silver 설계
- Auto Loader 및 Delta Live Table 검토
다만 제 경우에 'Epic', 'Story', 'Task'의 Issue Type을 설정하여 백로그를 작성하기보다는 Epic 전체 프로젝트의 이름, Story는 하나의 스프린트, Story 아래의 작업들은 Task로 등록하기로 했습니다. 이 부분에 대해서는 유연하게 가져가도 좋을 것 같습니다.
2. 스프린트 계획 및 시작
백로그를 만든 후에는 첫 스프린트에서 진행할 작업 항목을 지정하도록 합니다.
관련 있는 백로그들을 묶어서 'Create Sprint' 버튼을 누르게 되면 스프린트 설정이 나오는데, 위에서 언급한 것처럼 Story 인 'Raw Data Pipeline 개발'을 스프린트의 이름으로 명시하였습니다.
기간은 2주로 명시하고 Start, End Date를 지정하였습니다.
2-1. 스크럼 보드
'Active Sprint'가 되면 스크럼 보드를 통해서 스프린트의 작업을 시각화할 수 있습니다.
'To do', 'In progress', 'Done'으로 구분되지만 팀의 고유 방식을 반영하도록 워크 플로우도 설정이 가능합니다.
3. 일일 스크럼 미팅
어제 했던 일과 오늘 할 일 수행 중 문제점이나 장애요인 등을 공유하여 문제가 있을 경우 미팅하여 해결하며, 프로젝트 변화에 대해 유연하게 대처할 수 있습니다. 저희 팀은 정해진 시간을 두고 스크럼 미팅을 진행하는 것보다는 그때 상황에 맞게 일정을 조율하여 스크럼 미팅을 진행합니다. 모든 팀원이 하나의 프로젝트만 담당하고 있는 게 아니라 여러 프로젝트들을 동시에 진행하기 때문입니다.
4. 로드맵 활용하기
진행 중인 프로젝트를 큰 그림으로 확인하고 종속성을 추적하며 우선순위를 쉽게 조정할 수 있는 기능입니다. 특히 이해 관계자분들에게 업무 진행 내역을 쉽게 전달할 수 있는 수단입니다.
저희 JIRA에서는 상단 메뉴에 'Plans'라는 항목이 있습니다. 해당 버튼을 선택하여 Plan 생성을 진행하면 기존에 등록되어 있는 JIRA Project 기반으로 RoadMap을 손쉽게 작성할 수 있습니다.
Roadmap 화면에서 버튼 몇 번과 드래그로 손쉽게 담당자와 Target Start와 Target End 날짜를 명시할 수 있습니다.
Export 기능을 통해 Spreadsheet(.csv) 파일로도 변환이 가능하여 손쉽게 공유가 가능합니다.
5. 애자일 보고서 활용 및 반복
JIRA에서는 애자일 보고서를 위한 다양한 차트를 제공하고 있습니다. 아직 저는 이 부분에 대해서 제대로 활용해보진 못했지만 추후 더 나은 프로젝트 관리를 위해 필요하다고 생각되어 공부하고 있습니다.
마치며
JIRA는 꼭 개발자들만을 위한 툴은 아니라고 생각합니다. 프로젝트를 효과적으로 운영하고 싶으신 PM, 엔지니어, 디자이너 등 모든 구성원들이 활용할 수 있기 때문입니다.
이번 글은 애자일 도구인 JIRA를 사용한 경험에 대해 작성해 보았습니다.
다음 글에는 앞서 본문에 언급되었던 Databricks 프로젝트에 대한 자세한 내용을 작성하도록 하겠습니다.
부족한 점이 많은 글이지만, 시간 내어 읽어주셔서 감사합니다.
출처
'Infra' 카테고리의 다른 글
| 지마켓 대기열 시스템 파헤치기 (0) | 2022.09.30 |
|---|---|
| 레거시 시스템의 성능과 정합성 두 마리 토끼 잡기 (0) | 2022.09.21 |
| 짧고 굵게 지마켓 API Gateway 사용하기 (0) | 2022.09.14 |
| 가볍게 시작하는 Databricks Community Edition 환경설정 for Spark (1) | 2022.09.07 |
| MySQL만 써봤는데... MongoDB 프로젝트에 투입됐다🤯 (3) | 2022.08.05 |