핵심요약
비개발자가 AI와 협업하여 9일 만에 자체 생산성 측정 도구를 개발한 과정을 담고 있습니다. Jira, GitHub API 연동, 서버 구축, 스케줄러 설정 등 기술적 난관을 AI와 사내 가이드 문서를 활용해 극복하며, 데이터 민주주의와 AI 시대 인프라의 중요성을 역설합니다.
비개발자의 AI 협업을 통한 생산성 측정 도구 개발기
비개발자의 생산성 측정 고민과 AI 활용 결정
- 기술 PM으로서 조직 및 프로젝트 생산성 측정의 어려움을 겪던 중, 사내 가이드 문서와 AI를 활용해 9일 만에 자체 측정 도구 개발에 도전했습니다.
- 기존 Jira 대시보드 및 DORA 지표만으로는 부족하여, 팀 상황에 맞는 맞춤형 데이터 구성을 위해 AI의 도움을 받기로 결정했습니다.
1단계: HTML 기반 가설 검증 및 요구사항 구체화
- 브라우저에서 Jira changelog CSV를 파싱하여 리드타임을 시각화하는 HTML 파일로 첫 검증을 진행했습니다.
- AI와의 대화를 통해 이슈 상태 전환(
In Progress→Done)의 리드타임 계산 방식, 재오픈 케이스 등 예외 상황을 정의하고 요구사항을 구체화했습니다. - 타임스탬프 변환(UTC → KST), 이슈 타입 필드명 가변성 등 실제 데이터 관련 문제 해결을 위해 AI에게 CSV 헤더와 샘플 데이터를 제공하여 협업했습니다.
2단계: DORA 지표를 통한 기준 마련 및 데이터 확장
- 측정된 리드타임의 의미를 파악하기 위해 DORA 지표(배포 빈도, 변경 리드타임, 변경 실패율, 서비스 복구 시간)를 참고했습니다.
- Jira 데이터만으로는 딜리버리 흐름의 절반만 파악 가능함을 인지하고, 배포 이벤트 로그(GitHub) 데이터 연동의 필요성을 확인했습니다.
3단계: AI와 사내 가이드 문서를 활용한 서버 구축
- Jira와 GitHub API 연동 및 데이터 취합을 위해 별도 서버가 필요했으나, 비개발자로서 컨테이너 기반 배포에 대한 확신이 부족했습니다.
- 사내 컨테이너 플랫폼(
N3R) 가이드 문서를 AI에게 전달하고 함께 해석하며,Dockerfile작성 및 서버 구축을 성공적으로 수행했습니다. - 핵심: 가이드 문서와 AI의 상호 보완적 활용으로 사내 환경 특수성을 반영한 구현이 가능했습니다.
4단계: 스케줄러 설정, API 페이지네이션 문제 해결
- Jira, GitHub API 주기적 호출을 위한 Self-Hosted Runner 환경 설정 및 스케줄러 구성에 많은 시간을 할애했습니다.
- API 페이지네이션(1,000개 초과 시 데이터 누락) 문제를 발견하고 해결하며, AI와의 질의 방식을 '무엇'에서 '어떻게'로 발전시켜 정확도를 높였습니다.
- 배운 점: AI는 '올바른 질문'을 할 때 가장 효과적이며, 데이터 정합성 검증은 필수적입니다.
5단계: 사내 스토리지 연동 및 사람의 역할 재확인
- Redis 기반 사내 스토리지(
nBase-ARC) 연동 시, AI는 보편적 Redis 사용법을 제공했으나 사내 특수 네트워크 정책, TTL 설정 등은 가이드 문서와 사내 문의 채널(ASK)을 통해 해결했습니다. - 핵심: AI는 보편적 기술에는 능숙하지만, 사내 특화 환경, 내부 정책, 조직 고유 관행은 사람이 보완해야 합니다.
완성된 대시보드의 효과 및 시사점
- 효과: 조직 및 프로젝트의 딜리버리 흐름을 한눈에 파악하고, 막연했던 '개발 속도 저하' 등의 문제를 데이터 기반으로 설명 가능해졌습니다.
- 데이터 민주주의: AI 시대의 인프라는 '접근 가능한 데이터', '안전한 인프라', '친절한 가이드 문서'가 필수적이며, AI는 이를 돕는 조력자입니다.
- AI 활용: AI는 정밀한 조각가와 같으므로, 명확한 요구사항 정의와 구체적인 지시가 결과물의 품질을 결정합니다. '반드시 AI가 처리해야 하는가?'를 자문하고 역할 분담하는 것이 효율적입니다.