# A-RMS Business ## 핵심 한 줄 정의 > ALM의 이슈 데이터를 요구사항 관점에서 재해석해서 프로젝트 품질을 측정하는 시스템 **A-RMS = AI + ALM + RMS + PMS** --- ## 문제 인식: 왜 지금 Alm만으로는 부족한가 현장 팀들은 Jira, Redmine 같은 ALM 도구를 열심히 씁니다. 이슈를 만들고, 상태를 바꾸고, 댓글을 달고, 스프린트를 닫습니다. 그런데 한 가지 질문에 답하지 못합니다. > **"이 이슈는 어떤 요구사항 때문에 만들어졌는가?"** 이슈는 넘쳐나지만 요구사항은 어디에도 연결되어 있지 않습니다. 그 결과, 아무리 이슈를 열심히 처리해도 프로젝트가 올바른 방향으로 가고 있는지 알 수 없습니다. --- ## 왜 이게 비싼 문제인가 요구사항을 초기에 잘못 잡으면 단계가 늦어질수록 수정 비용이 기하급수적으로 증가합니다. | 단계 | 상대 비용 | |------|----------| | 요구분석 | 1배 | | 설계 | 5배 | | 코딩 | 10배 | | 테스트 | 50배 | | 유지보수 | 200배 | 문제를 가장 싸게 잡을 수 있는 시점은 **요구분석 단계**입니다. 그리고 그 시점에 문제를 잡으려면, 요구사항이 이슈와 연결되어 실시간으로 추적되어야 합니다. --- ## Pain Point: 현장에서 실제로 벌어지는 일 - **문서 ↔ 시스템 단절**: 기획서는 Confluence에, 이슈는 Jira에, 둘은 연결되지 않음 - **요구사항 반영 지연**: 기획 변경이 개발 이슈에 전파되는 데 며칠씩 걸림 - **추적 불가**: 이 기능이 어느 요구사항에서 왔는지 아무도 모름 - **통계 왜곡**: 이슈 완료율은 100%인데 실제 요구사항 달성률은 불명확 - **재작업 반복**: 오해한 요구사항 → 구현 → 검수 실패 → 재작업 사이클 --- ## 해결 방향: 측정 → 관리 → 개선 A-RMS가 제시하는 방향은 단순합니다. 1. **측정**: 요구사항과 이슈를 연결해서 현재 상태를 숫자로 만든다 2. **관리**: Time / Scope / Resource / Cost 4개 축으로 프로젝트를 모니터링한다 3. **개선**: 데이터에 기반한 의사결정으로 다음 프로젝트는 더 잘 한다 --- ## Solution: A-RMS가 하는 일 ### 핵심 전략: 기존 ALM 위에 레이어를 얹는다 Jira나 Redmine을 교체하지 않습니다. 팀이 익숙하게 쓰던 ALM은 그대로 두고, A-RMS가 그 위에서 요구사항 연결 레이어와 분석 레이어를 추가합니다. 이 방식의 장점은 **도입 저항이 낮다**는 것입니다. 개발팀은 Jira를 계속 쓰면서, PM은 A-RMS 대시보드에서 요구사항 달성 현황을 봅니다. --- ### 주요 기능 #### 요구사항 관리 - 요구사항 등록 및 버전 관리 - 요구사항 → ALM 이슈 자동 생성 및 연결 - 요구사항 변경 이력 추적 #### ALM 연동 - Jira (Cloud / On-premise), Redmine, GitLab 지원 - 이슈 데이터 자동 수집 (Kafka 기반 실시간 스트리밍) - 기존 이슈에 요구사항 역매핑 지원 #### 분석 대시보드 | 영역 | 측정 내용 | 실무 질문 | |------|----------|----------| | Time | 일정 준수율, 지연 이슈 현황 | 언제 끝나는가? | | Scope | 요구사항 달성률, 범위 변경 추이 | 무엇을 만들고 있는가? | | Resource | 담당자별 이슈 부하, 미배정 이슈 | 누가 과부하인가? | | Cost | 요구사항당 투입 공수, ROI | 이게 본전인가? | --- ## 시스템 구조 @/docs/image/architecture.png를 분석한다. **engine-fire (이 모듈)** 는 Elasticsearch를 통해 ALM 이슈 데이터를 수집하고, 요구사항 기준으로 집계해서 분석 데이터를 만드는 역할을 합니다. --- ## 도입 프로세스 ### Step 1: 연결 - 제품/서비스 등록 - Jira / Redmine ALM 서버 연결 - 요구사항 등록 (또는 기존 문서에서 임포트) ### Step 2: 운영 - 요구사항 기반으로 ALM 이슈 생성 - 개발팀은 기존대로 ALM에서 작업 ### Step 3: 측정 - 이슈 데이터 자동 수집 및 집계 - 요구사항 달성 현황 대시보드 확인 - 리스크 감지 및 의사결정 --- ## 도입 대상 및 기대 효과 ### 적합한 조직 - Jira/Redmine을 쓰지만 요구사항 추적이 안 되는 팀 - SI / 외주 프로젝트에서 검수 기준이 불명확한 조직 - R&D 조직에서 과제 성과를 정량화해야 하는 경우 ### 기대 효과 - 요구사항 가시성 확보 → 검수 분쟁 감소 - 리스크 조기 감지 → 재작업 비용 절감 - 데이터 기반 일정 예측 → 출시 지연 방지 - ROI 정량화 → 의사결정 근거 확보 --- ## 경쟁 비교 | 항목 | A-RMS | 기존 ALM (Jira 단독) | |------|-------|---------------------| | 요구사항 추적 | 이슈와 전체 연결 | 수동 라벨링, 제한적 | | 분석 | 자동 집계 대시보드 | 수동 필터/쿼리 | | AI 예측 | 일정/리스크 예측 | 없음 | | 기존 도구 교체 | 불필요 (레이어 추가) | - | --- ## 설치 환경 - CPU: 4 Core 이상 - Memory: 32GB 이상 - Docker 기반 배포 --- ## 주의: 기술보다 어려운 것 A-RMS가 효과를 내려면 한 가지 전제조건이 있습니다. > **팀이 요구사항을 실제로 등록하고, 이슈와 연결하는 습관을 만들어야 합니다.** 시스템이 자동화할 수 있는 건 데이터 수집과 분석입니다. 하지만 **요구사항을 명확히 정의하는 행위** 자체는 사람이 해야 합니다. 도구 도입보다 팀의 워크플로우 변화가 성공의 핵심 변수입니다.