요약
"조직이 잘하고 있는지 어떻게 알 수 있을까?" 이 질문에서 출발해 사내 가이드 문서와 AI를 붙들고 직접 측정 도구를 완성하기까지 9일이 걸렸습니다. 그 과정을 기록으로 남깁니다.
사내 생산성 측정에 관한 고민
기술 PM으로 일하면서 조직과 프로젝트의 생산성을 어떻게 측정할지는 늘 풀리지 않는 과제였습니다. 스프린트를 원활하게 진행하는 것 같아도 막상 이를 수치로 보여달라고 하면 난감했습니다. 속도가 빨라지는지, 병목이 어디서 발생하는지, 지난 분기보다 나아지고 있는지 감각적으로는 알 수 있었지만 데이터로 명확히 설명하기는 어려웠습니다.
사내에는 이미 'DevOps board'라는 시스템이 있어 배포 빈도와 리드타임을 포함한 DORA 지표를 제공하고 있습니다. 소프트웨어 딜리버리 흐름을 측정한다는 점에서 제가 찾던 도구에 가까웠습니다. 다만 저는 분석 지표와 상황에 맞추어 조금 더 세분화된 데이터를 들여다보고 싶었습니다.
그래서 먼저 Jira 대시보드를 만들어 리치 필터(rich filter)로 데이터를 추출해 보았습니다. 이슈 완료 수, 스프린트 완료율, 컴포넌트별 작업량 등 여러 수치가 모였지만, 수집한 숫자만으로는 조직의 작업 속도를 한눈에 파악하기 어려웠습니다. 작업이 어디서 얼마나 걸리는지도 보이지 않았습니다. Jira는 업무를 관리하는 도구일 뿐 소프트웨어 딜리버리 흐름 전체를 측정하는 도구는 아니기 때문입니다.
결국 특정 컴포넌트 기준의 분류, 팀 고유의 이슈 타입 정의, 팀 내 업무 흐름을 세밀하게 들여다볼 수 있는 맞춤형 도구가 필요했습니다. 기존 DevOps board를 대체하려는 것이 아니라, 팀의 상황에 맞추어 데이터를 직접 구성해 보고 싶었습니다.
문제는 제가 이를 직접 구현할 기술적 역량이 부족하다는 점이었습니다. 개발자에게 부탁하기에는 작업 규모가 작았고, 백로그에 등록하더라도 언제 진행될지 기약할 수 없었습니다. 그래서 AI의 도움을 받아 직접 만들어 보기로 했습니다.
1단계: HTML 파일 하나로 가설 검증
처음에는 배포, 서버, 인증 과정을 모두 생략하고 HTML 파일 하나로 가볍게 시작했습니다. 브라우저에서 Jira 변경 기록(changelog) CSV 파일을 파싱해 바로 시각화하는 구조였습니다.
AI에게 전달한 첫 프롬프트에는 현재 상황과 맥락을 최대한 자세히 담았습니다.
Jira 이슈별 changelog CSV에는 'Issue Key', 'Status', 'Created' 칼럼이 있어.
각 이슈가 'In Progress'로 처음 전환된 시각과 'Done'으로 전환된 시각의 차이를 일(day) 단위로 계산하고 싶어. 팀별, 이슈 타입별로 집계해서 주차별 트렌드를 보여주는 웹 대시보드를 만들고 싶은데,
구조는 이해하지만 직접 구현은 못 해.
이 프롬프트에는 데이터 형식, 원하는 결과물, 그리고 저의 기술적 한계가 모두 들어가 있습니다.
AI는 곧바로 코드를 작성하는 대신 발생할 수 있는 예외 상황(edge case)을 먼저 짚어 주었습니다.
이슈가 In Progress → Backlog → In Progress로 다시 이동했다가 Done이 되는 경우, 리드타임 기산점을 첫 번째 In Progress로 할지 마지막으로 할지 정의가 필요해요. Done 이후 재오픈 케이스는요?
이 질문을 받기 전까지는 저 역시 이러한 예외 상황을 생각하지 못했습니다. 실제로 확인해 보니 데이터에 해당 사례가 적지 않게 포함되어 있었습니다. 결국 AI와 대화하는 과정 자체가 요구사항 정의 세션이 된 셈입니다.
물론 초기에는 버그도 있었습니다. Jira CSV의 타임스탬프가 UTC 기준이라 KST로 변환해 날짜를 계산해야 했고, 내보내기 설정에 따라 이슈 타입 필드명이 달라지는 문제도 있었습니다. 이럴 때는 문제를 말로 설명하기보다 실제 CSV 헤더와 샘플 데이터 일부를 AI에게 그대로 보여주는 편이 훨씬 효과적이었습니다.
이렇게 해서 대시보드 화면에 리드타임 수치가 나타났습니다. 하지만 그 숫자를 보면서 새로운 의문이 생겼습니다. 이 수치가 좋은 편인지 나쁜 편인지는 어떻게 알 수 있을까요?
2단계: DORA 지표를 통한 기준 마련
리드타임을 측정하는 것과 그 수치의 의미를 파악하는 것은 별개의 문제였습니다. 그래서 소프트웨어 딜리버리 성과를 측정하는 프레임워크인 DORA 지표를 참고했습니다. DORA 지표는 수많은 팀과 프로젝트의 데이터를 분석해 도출한 네 가지 핵심 지표로 구성됩니다.
- 배포 빈도
- 변경 리드타임
- 변경 실패율
- 서비스 복구 시간
여러 연구를 통해 이 네 가지 지표가 팀의 딜리버리 역량을 가장 잘 설명한다는 사실이 검증되었습니다.
제가 측정한 Jira 리드타임은 이 중 '변경 리드타임'에 해당했습니다. 작업 시작부터 실제 배포까지 걸리는 시간입니다. 나머지 지표를 확인하려면 추가 데이터가 필요했습니다. 배포 빈도는 배포 이벤트 로그에서, 변경 실패율과 복구 시간은 PR(Pull Request) 및 이슈 데이터에서 얻을 수 있었습니다.
결국 Jira 데이터만으로는 전체 딜리버리 흐름의 절반만 볼 수 있었습니다. 나머지 절반을 채우려면 사내 GitHub 데이터를 연동해야 했습니다.
3단계: AI를 활용한 서버 구축과 가이드 문서
GitHub API를 주기적으로 호출하고 이를 Jira 데이터와 결합하려면 단순한 브라우저용 HTML 환경으로는 부족했습니다. 별도의 서버가 필요해진 것입니다.
사실 이 시점에서 진행을 포기할까 고민도 했습니다. Dockerfile을 한 번도 작성해 본 적 없는 비개발자가 컨테이너 기반 배포를 직접 해낼 수 있을지 확신이 서지 않았기 때문입니다.
일단 사내 공통 컨테이너 플랫폼인 'N3R'의 가이드 문서부터 찾아보았습니다. 하지만 낯선 용어가 많아 문서 첫 페이지부터 막막했습니다. 그래서 접근 방식을 바꿨습니다. 가이드 문서를 혼자 끙끙대며 읽는 대신, 그 내용을 AI에게 전달하고 함께 해석해 나가기 시작한 것입니다.
이 가이드에 이렇게 나와 있는데, 파이썬 FastAPI 앱에 적용하면 Dockerfile을 어떻게 써야 해? [가이드 해당 섹션 붙여넣기]
가이드 문서에는 사내 환경과 표준 규칙이 담겨 있습니다. AI는 그 내용을 제 상황에 맞게 구체화해 주었습니다. 둘 중 어느 한쪽만으로는 해결이 어려웠지만, 가이드 문서와 AI를 교차로 활용함으로써 무사히 서버를 띄울 수 있었습니다.
4단계: 스케줄러 설정과 데이터 누락 문제 해결
서버를 구축했다고 해서 데이터가 저절로 모이는 것은 아닙니다. Jira와 GitHub API를 주기적으로 호출해 줄 스케줄러가 필요했습니다. 다행히 사내에는 이미 Self-Hosted Runner 환경과 관련 설정 가이드 문서가 마련되어 있었습니다.
돌이켜보면 9일 중 가장 많은 시간을 이 구간에서 소요했습니다. Runner 환경 변수 설정, 인증 토큰 발급, API 페이지네이션(pagination) 처리 등 예상치 못한 문제가 꼬리를 물고 나타났기 때문입니다.
그중에서도 가장 애를 먹었던 부분은 API 페이지네이션이었습니다. 조회할 이슈가 1,000개를 넘어가면 API 응답이 중간에 잘리는데, 초기에 AI가 작성한 코드에는 이 예외 처리가 누락되어 있었습니다. 오류 메시지조차 없이 데이터만 조용히 누락되고 있었고, 나중에 직접 숫자를 대조하며 검증하다가 우연히 발견했습니다.
이 과정을 거치며 제가 AI에게 질문하는 방식도 달라졌습니다. 초반에는 "이거 어떻게 해요?"에 가까웠다면, 나중에는 가이드 내용, 현재 설정 파일, 오류 메시지를 함께 붙여 "이 값을 내 상황에 어떻게 적용하면 돼?"라고 물었습니다. 상황과 맥락을 자세히 전달할수록 AI의 답변은 훨씬 정확해졌습니다.
5단계: 사내 스토리지 연동과 사람의 역할
수집한 데이터를 저장하고 필요할 때 화면에 제공하려면 스토리지가 필요했습니다. 사내에서 제공하는 Redis 기반 스토리지인 nBase-ARC를 활용하기로 하고 관련 가이드 문서를 참고했습니다.
AI는 보편적인 Redis 사용법은 훌륭하게 알려 주었습니다. 하지만 사내의 특수한 네트워크 정책, 고유한 TTL 설정 방식, 접근 권한 신청 프로세스 같은 내부 정보는 알지 못했습니다. 이런 부분에서는 사내 가이드 문서와 사내 AI 기반 문의 채널 ASK가 도움이 되었습니다.
널리 공개된 기술 스택을 다룰 때 AI는 탁월한 조력자입니다. 하지만 사내 특화 환경, 내부 정책, 조직 고유의 관행은 AI가 파악할 수 없는 영역입니다. 이 영역은 결국 사람이, 문서가, 동료가 채워야 합니다.
완성된 대시보드의 효과
이제 Jira와 GitHub 데이터는 매일 자동으로 수집됩니다. 대시보드에 접속하면 조직과 프로젝트의 전반적인 딜리버리 흐름을 한눈에 확인하고 다음과 같은 것들을 쉽게 파악할 수 있습니다.
- 리드타임이 유독 길어지는 구간
- 특정 이슈 타입에서 반복되는 병목 현상
- 스프린트 후반부에 배포 이벤트가 몰리는 패턴
'요즘 왠지 개발 속도가 느려진 것 같다'는 막연한 느낌을 이제는 데이터를 근거로 설명할 수 있게 되었습니다.
물론 이 대시보드가 완벽한 측정 도구는 아닙니다. DORA 지표를 온전히 구현한 것도 아닙니다. 하지만 측정 도구가 아예 없었을 때와 비교하면 확실한 차이가 있습니다. 가장 큰 변화는 조직 회고 시간의 논의 수준이 달라졌다는 점입니다. 막연한 감이 아니라 실제 데이터를 보면서 이야기하게 되었습니다.
프로젝트를 진행하며 배운 점
기획의 재발견: AI는 마법사가 아니라 정밀한 조각가다
AI는 사용자가 원하는 바를 구현하는 데 탁월한 능력을 보여줍니다. 하지만 그 전제는 사용자 스스로 '무엇을 원하는지'를 명확히 알고 있어야 한다는 것입니다.
작업을 하면서 특히 효과적이라고 느낀 소통 방식은 다음 세 가지였습니다.
- 실제 데이터를 예시로 보여주기
- 발생 가능한 예외 상황을 미리 정의하기
- 기대한 결과와 실제 결과의 차이를 명확히 짚어 주기
이 세 가지 요건이 충족될 때 AI는 가장 정확한 결과물을 내놓았습니다. 결국 기획이란 필요한 기능을 나열하는 작업이 아니라, AI가 올바르게 이해하고 작업할 수 있도록 꼼꼼한 설계도를 그리는 과정이었습니다. 얼마나 명확하고 구체적으로 지시하느냐가 최종 결과물의 품질을 결정했습니다.
인프라의 벽: 가이드와 AI, 둘 다 필요했다
서버를 구축하는 과정에서는 사내 가이드 문서와 AI를 함께 활용해야 했습니다. 가이드 문서는 사내 환경을 정확히 설명해 주었지만 제 프로젝트 상황에 딱 맞는 답을 주지는 못했습니다. 반대로 AI는 기술적 원리를 잘 설명해 주었지만 사내 환경의 특수성은 알지 못했습니다.
따라서 이 둘을 교차해서 쓰는 것이 가장 효율적이었습니다. 가이드 문서의 내용을 AI에게 알려 주고 그 의미를 함께 해석하는 방식입니다. 가이드 문서가 '무엇을' 해야 하는지 알려주면, AI가 '어떻게' 해야 하는지 구체화했습니다.
새로운 아이디어의 실현은 도구의 발전에서 비롯되지만, 그것이 지속 가능하게 유지하는 힘은 안정적인 인프라에서 나옵니다. 그리고 비개발자조차 그 인프라에 접근해 활용할 수 있도록 길을 열어 주는 것은 결국 잘 작성된 가이드 문서입니다.
토큰의 무게: AI는 공짜가 아니다
AI를 활용하면서 토큰(비용)이 유독 많이 소모되는 구간이 있었습니다. 대체로 다음과 같은 상황이었습니다.
- AI가 매번 코드 전체를 새로 읽게 했던 초반
- 대화 맥락을 정리하지 않고 질문을 무분별하게 이어 갔던 중반
- 분석 탭에서 AI API를 3번 순차 호출하던 구조
해법은 '역할 분리'였습니다. 데이터 파싱이나 집계 같은 단순 계산은 JavaScript 코드가 직접 처리하도록 하고, AI에게는 최종적으로 요약된 수치만 전달해 의미 해석을 맡기는 구조로 바꿨습니다. 그러자 토큰 사용량이 눈에 띄게 줄었고 응답 속도도 훨씬 빨라졌습니다.
어떤 기능을 구현하기 전에는 "이 작업을 반드시 AI가 처리해야 하는가?"를 먼저 자문해 볼 필요가 있습니다. 명확한 규칙으로 처리할 수 있는 작업은 코드로 해결하고, AI는 문맥 판단이나 해석이 필요한 영역에만 제한적으로 활용하는 편이 효율적입니다.
AI의 한계: 오류가 없다고 올바른 것은 아니다
가장 많은 시간을 낭비하게 만든 것은 역설적이게도 AI가 확신에 차서 작성해 준 코드였습니다. 앞서 언급한 API 페이지네이션 코드는 겉보기에는 아무런 오류 없이 매끄럽게 동작했습니다. 하지만 이슈가 1,000개를 넘어가는 순간부터 데이터가 시스템 내부에서 조용히 누락되고 있었습니다. 출력된 수치를 꼼꼼히 검증해 보지 않았다면 끝까지 몰랐을 문제였습니다.
따라서 AI가 만들어 준 코드는 오류 없이 실행되는지 확인하는 선에서 그쳐서는 안 됩니다. 도출된 결과가 실제로 정확한지 정합성을 검증하는 단계가 반드시 필요합니다. 샘플 데이터로 직접 계산한 값과 AI의 결과물을 대조해 보는 과정은 번거롭지만 생략할 수 없습니다.
생태계의 제언: '데이터 민주주의'를 위한 조건
비개발자인 제가 이 프로젝트를 무사히 마칠 수 있었던 것은 AI의 능력 덕분만은 아니었습니다. 든든한 사내 가이드 문서가 뒷받침되었기에 가능한 일이었습니다. 가이드 문서가 없었다면 아무리 훌륭한 AI라도 사내 환경에 맞는 결과물을 만들어내기 어려웠을 것입니다.
회사에는 방대한 데이터와 훌륭한 인프라가 있습니다. 하지만 권한은 열려 있어도 이를 실제로 활용할 수 있는 사람은 극소수인, 이른바 '접근은 가능하지만 접근할 수 있는 사람은 없는' 상태에 머무는 경우가 많습니다.
API 사용 가이드를 조금 더 체계적으로 다듬고, 자주 쓰이는 템플릿 코드를 사내에 공유하고, 보안 가이드라인을 명확히 제시해 주는 것만으로도 수많은 사내 맞춤형 도구가 새롭게 만들어질 수 있습니다. 비개발자가 AI와 협업해 가치 있는 무언가를 만들어 내는 진정한 전제 조건은 결국 '친절하고 정확한 가이드 문서'입니다. AI는 사용자가 그 가이드를 조금 더 쉽게 소화하고 자기 상황에 적용할 수 있도록 돕는 훌륭한 조력자일 뿐입니다.
마치며
불과 9일 전의 저는 스스로 서버를 구축할 수 있을 거라고는 생각도 못 했습니다. 그런데 결국 Dockerfile을 작성하고, 컨테이너를 빌드해 배포하고, API를 주기적으로 호출하는 스케줄러를 구성했으며, Redis에 데이터를 읽고 쓰는 경험까지 했습니다. 코드는 대부분 AI가 작성해 주었지만, '무엇을 만들 것인지', '어떤 구조로 설계할 것인지', '최종 결과물이 올바른지'를 판단하는 몫은 온전히 제게 있었습니다.
대시보드의 숫자를 보며 종종 생각합니다. '우리 조직과 프로젝트는 잘 나아가고 있나?' 예전에는 막연했던 그 질문에, 이제는 데이터를 근거로 조금은 명확한 답을 할 수 있게 되었습니다.
동료에게서 "이거 어떻게 만드셨어요?"라는 질문을 받을 때마다 저는 이렇게 답하곤 합니다.
"AI한테 말로 시켰어요. 그런데 뭘 시킬지는 제가 알아야 했어요."
이 글을 통해 전하고 싶은 메시지는 단 하나입니다. AI를 잘 활용하는 조직은 성능 좋은 AI 도구를 선별하는 데 그치지 않고, AI가 역량을 제대로 발휘할 수 있는 밑바탕 환경을 먼저 탄탄하게 갖춘 조직입니다.
- 데이터를 같은 기준으로 관리하려는 조직적 합의
- 누구나 안전하게 접근하여 실험할 수 있는 열린 인프라
- 비개발자도 천천히 따라갈 수 있도록 작성된 가이드 문서
이 세 가지가 바로 AI 시대에 필요한 인프라입니다.