A serverless, data-driven Git metrics dashboard using Amazon Quick Sight

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

GitHub·GitLab 활동을 서버리스 파이프라인으로 자동 수집하고 Amazon Quick Sight로 시각화해 개발 활동과 AI 코딩 도구 도입 전후의 변화를 측정하는 구성을 소개한다.

📌 핵심 요약

• 원문은 AWS AI-Driven Development Lifecycle(AI-DLC)에 따라 AI 코딩 도구 도입 전 기준선을 설정하고, 도입 후 개발 속도와 품질 변화를 지속적으로 측정해야 한다고 강조한다.
• GitHub·GitLab API에서 변경을 감지해 관련 활동이 없으면 수집을 건너뛰고, 최초 실행과 이후 24시간마다 전체 수집을 수행하며 나머지 실행에는 증분 수집을 적용한다.
• Amazon EventBridge Scheduler와 AWS Step Functions가 수집을 조율하고 AWS Lambda가 실행한다. 기본 임계값인 20개를 초과하는 저장소는 병렬 처리하며, 수집 주기는 AWS CloudFormation의 rate()·cron() 표현식으로 설정한다.
• Git 토큰은 AWS Secrets Manager에서 실행 시 조회하고, 수집 결과는 버전 관리와 서버 측 암호화를 적용한 Amazon S3에 JSON·CSV로 저장한다. Amazon Quick Sight는 S3 또는 Amazon Athena를 통해 데이터를 읽고 SPICE에 적재해 시각화한다.
• 배포에는 AWS 계정과 권한, AWS CLI v2, GitHub 또는 GitLab 토큰, Amazon Quick Sight 구독이 필요하다. 비운영 환경에 CloudFormation 스택을 만든 뒤 두 Lambda 함수의 임시 코드를 deployment/lambda-package.zip으로 교체해야 하며, 제공된 원문은 실행·검증 단계의 도입부에서 끝난다.

🧩 주요 포인트

1. AI-DLC의 기준선·지속 측정 원칙 → 커밋 수 증가만으로 AI 코딩 도구의 효과를 판단하지 않고 개발 속도와 품질 변화를 함께 살필 필요가 있다.
2. 변경 감지·증분 수집·20개 초과 저장소 병렬 처리 → 불필요한 실행과 API 호출을 줄이면서 다수 저장소를 처리하도록 설계했으며, 24시간마다 전체 갱신해 데이터 정확성을 유지하려 한다.
3. CloudFormation 배포와 Lambda 코드 교체가 별도 단계 → 스택 생성만으로 실제 수집 로직 배포가 완료되지 않으며, 원문이 실행·검증 도입부에서 끝나므로 전체 동작 검증 결과는 확인할 수 없다.

🧠 상세 정리

1. Git 활동 관측과 AI 도구 효과 측정

원문은 Git 활동을 개발 분석에 지속적인 관측 가능성을 제공하는 풍부한 신호로 소개하면서, 이를 대규모로 추출하려면 전통적으로 직접 만든 ETL 작업과 전용 인프라, 지속적인 유지보수가 필요했다고 설명한다. 개발 도구가 확산되는 상황에서는 도구가 개발자를 실제로 빠르게 만드는지, 투자 효과가 없는지를 판단할 명확한 측정 방식도 요구된다. AWS AI-Driven Development Lifecycle(AI-DLC)은 AI 코딩 도구 사용에 앞서 기준선을 설정하고, 도입 과정의 변화를 추적하며, 이후에도 관측을 이어가야 한다는 원칙을 제시한다. 이러한 측정이 없으면 AI가 개발 속도를 높이는지, 커밋 수만 늘리는지, 예상하지 못한 품질 문제를 유발하는지 알기 어렵다는 것이 원문의 문제의식이다.

2. 서버리스 수집 파이프라인의 목표

제안된 솔루션은 GitHub와 GitLab API에서 저장소 지표를 정해진 일정에 따라 자동 수집하고, 서버리스 워크플로로 처리한 결과를 Amazon S3에 보관하는 구조다. Amazon Quick Sight의 대화형 대시보드는 이 데이터를 시각화해 스프린트 속도, 릴리스 준비 상태, 팀 활동 패턴을 살펴볼 수 있도록 한다. 원문은 이를 Git 플랫폼 활동에 대한 준실시간 통찰을 제공하는 방식으로 설명하며, 서버리스 설계가 인프라 관리 부담을 추상화하고 규모가 커져도 낮은 비용을 유지한다고 주장한다. 또한 AI 도구 도입 전 개발 속도의 기준선을 만들고, 도입 중 변화를 추적하며, 시간에 따른 개선을 수치화한다는 점에서 AI-DLC의 관측 가능성 원칙과 연결한다.

3. 변경 감지와 전체·증분 수집

전용 변경 감지 함수는 GitHub 이벤트 API와 GitLab 활동 피드를 조회해 직전 확인 이후 수집할 만한 변화가 있었는지 판단하며, 관련 이벤트가 없으면 워크플로를 조기에 종료한다. 감시 대상은 푸시 이벤트, 풀 리퀘스트, 이슈 생성과 갱신, 저장소 생성, 저장소 삭제, 기여자 변화의 여섯 범주다. 최초 실행에서는 모든 저장소 메타데이터를 전체 수집하고, 이후에는 변경된 데이터만 가져오는 증분 수집을 적용해 API 호출과 실행 시간을 줄인다. 데이터 정확성을 유지하기 위해 24시간마다 전체 갱신을 자동 수행하며, 수집 간격 자체는 CloudFormation 매개변수에서 rate() 또는 cron() 표현식으로 사용 목적에 맞게 설정한다.

4. 워크플로 조율과 병렬 처리

Amazon EventBridge Scheduler는 설정한 간격에 따라 수집 사이클을 시작하고, AWS Step Functions 상태 머신은 변경 감지와 수집 유형 결정부터 저장소 처리까지 전체 흐름을 조율한다. 활성 저장소 수가 기본 청크 분할 임계값인 20개를 초과하면 저장소를 같은 크기의 묶음으로 나누고 Map 상태를 이용해 병렬 처리하며, 각 묶음은 별도의 AWS Lambda 호출이 담당한다. 소규모 저장소 집합은 단일 호출로 직접 수집하고, 일시적인 API 실패에 대응하기 위해 지수 백오프를 포함한 재시도 로직을 둔다. github-metrics-collector 함수는 전체 직접 처리용 collect_all, 일부 저장소 처리용 collect_chunk, 묶음별 결과 통합용 aggregate의 세 가지 모드로 동작한다.

5. 자격 증명과 수집 데이터 보관

Git 토큰은 AWS Secrets Manager에 저장되며, github-change-detector와 github-metrics-collector 두 Lambda 함수가 실행 시점에 이를 조회하므로 자격 증명을 코드에 고정하거나 환경 변수로 전달하지 않는 구조다. 수집 결과를 보관하는 Amazon S3에는 버전 관리와 서버 측 암호화를 적용하고, 전체 API 응답과 중첩된 저장소 상세 정보를 담은 구조화된 JSON 파일을 출력한다. 분석용으로 평탄화한 CSV 파일도 함께 만들며, 두 파일에는 저장소 이름, 전체 커밋 수, 열린·닫힌 풀 리퀘스트와 이슈 수, 기여자 수 등의 필드가 포함된다. 주 언어, 마지막 활동 시각, 저장소 생성일도 기록하며, 원문은 S3를 과거 지표를 지속적으로 보관하는 내구성 있고 비용 효율적인 저장소로 설명한다.

6. 시각화 방식과 배포 준비 요건

Amazon Quick Sight는 S3에 저장된 CSV를 직접 읽거나 Amazon Athena를 통한 SQL 기반 조회로 데이터를 가져오고, 빠른 메모리 내 계산 계층인 SPICE에 적재해 대화형 대시보드를 구성한다. 시각화 대상으로는 요약 지표, 풀 리퀘스트 추세, 시간에 따른 개발 활동, 저장소별 상세 탐색, 기여자 분석이 제시된다. 배포를 따라 하려면 관련 리소스를 생성할 권한이 있는 활성 AWS 계정과 AWS CLI v2, 모니터링할 저장소 및 Personal Access Token을 생성할 수 있는 GitHub 또는 GitLab 계정이 필요하다. 대시보드 생성에는 Standard 또는 Enterprise 에디션의 활성 Amazon Quick Sight 구독이 필요하며, 솔루션 GitHub 저장소를 복제한 뒤 해당 루트를 기준으로 안내된 파일 경로를 사용한다.

7. 토큰 생성과 CloudFormation 배포

배포 절차는 사용할 Git 플랫폼의 API 토큰을 만드는 것부터 시작하며, GitHub에서는 Tokens (classic)을 선택하고 원문이 필요한 권한으로 제시한 repo와 read:org 범위를 지정한다. GitLab에서도 액세스 토큰을 생성하도록 안내하지만, 제공된 본문에는 선택할 구체적인 범위가 명시되지 않았으며 생성한 토큰은 각각 AWS Secrets Manager의 비밀 값으로 저장한다. 이후 샘플 CloudFormation 템플릿을 비운영 환경에 배포하면서 계정 ID, 리전, 토큰 비밀 ARN을 실제 값으로 바꾸고, 예시에서는 수집 주기를 rate(10 minutes), 분할 임계값을 20, 활성 플랫폼을 github,gitlab으로 설정한다. AWS CLI 또는 AWS Management Console로 배포할 수 있으며, 원문은 스택이 3~5분 내 CREATE_COMPLETE 상태에 도달하고 S3 버킷, Python 3.13 기반 Lambda 함수 두 개, Step Functions 상태 머신, 일정 규칙과 IAM 역할 등을 생성한다고 설명한다.

8. 실제 Lambda 코드 배포와 본문 범위

CloudFormation 템플릿은 Lambda 함수에 임시 코드를 배포하므로, 스택 생성 이후 복제한 저장소의 사전 빌드 패키지로 실제 수집 로직을 넣는 별도 단계가 필요하다. 원문은 deployment/ 디렉터리의 lambda-package.zip을 생성된 S3 버킷의 lambda/lambda-package.zip 경로로 올린 뒤, AWS CLI의 update-function-code로 두 함수를 갱신하는 절차를 제시한다. 갱신 대상은 github-change-detector와 github-metrics-collector이며, 명령에 들어가는 버킷 이름은 CloudFormation 스택이 만든 실제 이름으로 바꿔야 한다. 다음 단계는 실행 및 검증으로 이어지지만 제공된 본문은 워크플로를 시작하라는 도입 문구에서 끝나므로, 구체적인 검증 명령이나 실행 결과, 이후 대시보드 구성 절차는 이 자료에서 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Git 활동 지표는 AI 도구 도입 전후를 비교할 관측 기반을 제공하지만, 원문은 커밋 수 증가만으로 개발 속도 개선이나 품질 유지를 판단할 수 있다고 주장하지 않는다.
• 변경이 없을 때 실행을 생략하는 방식과 주기적인 전체 갱신을 결합해 수집 효율과 데이터 정확성을 함께 추구하는 설계다.
• 원문은 저비용과 준실시간 분석을 장점으로 제시하지만, 제공된 본문에는 실제 비용 수치나 지연 측정값, 배포 후 검증 결과가 없다.

✅ 액션 아이템

• AI-DLC에 따라 AI 코딩 도구 도입 전 기준선을 설정하고 개발 속도와 품질 변화를 지속 측정.
• 저장소 수와 수집 요구에 맞춰 20개 기본 임계값 및 rate()·cron() 수집 주기를 검토.
• 비운영 환경의 CloudFormation 배포 후 deployment/lambda-package.zip으로 두 Lambda 함수의 임시 코드를 교체하고, 실행·검증 절차의 미제공 범위를 확인.

❓ 열린 질문

• AI-DLC에 따른 도입 전 기준선에서 개발 속도와 품질 변화를 각각 어떤 지표로 판단할 것인가?
• 대상 저장소 수와 수집 요구에 적합한 rate()·cron() 주기 및 20개 기본 임계값은 무엇인가?
• CloudFormation 배포와 Lambda 코드 교체 이후 전체 동작을 확인하려면 어떤 실행·검증 절차가 추가로 필요한가?