데이터가 보여주는 엔지니어링의 민낯: 개발 생산성 분석 도구를 바라보는 관점

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발 조직의 리더로서 가장 자주, 그리고 깊게 고민하는 주제는 결국 '가시성(Visibility)'입니다. 우리 팀이 어디서 병목을 겪고 있는지, 코드 리뷰는 건강하게 이루어지고 있는지, 혹은 단순 반복 작업에 에너지를 낭비하고 있지는 않은지 파악하는 일이죠.

최근 흥미로운 소식을 하나 접했습니다. GitHub, GitLab, Bitbucket 등 파편화된 저장소들의 데이터를 한곳에 모아 분석해 주는 'Gitmore'라는 도구가 해커뉴스(Hacker News)에 소개되었더군요. AI가 커밋과 PR(Pull Request) 활동을 분석해 주간 리포트를 써주고, 슬랙에서 봇에게 질문하면 프로젝트 현황을 답해주는 기능이 핵심이었습니다.

하지만 제가 주목한 건 이 도구의 기능 자체가 아니라, 그 게시글에 달린 날카로운 댓글 하나였습니다.

"많은 사람들이 대충 코드 하나 짜놓고는 읽기, 쓰기, 실행 권한을 요구하는 중요한 인프라에 꽂으라고 제안하는 게 놀랍다."

이 짧은 문장은 기술 리더들이 '생산성 도구'를 도입할 때 마주하는 딜레마와 본질을 정확히 꿰뚫고 있습니다. 오늘은 이 이야기를 좀 해보려 합니다.

측정하고 싶은 욕망과 보안이라는 벽

우리는 모두 측정하고 싶어 합니다. 경영진은 ROI를 보고 싶어 하고, CTO는 엔지니어링 효율성을 보고 싶어 하며, 개발자 본인도 자신의 기여도를 확인하고 싶어 하죠. 그래서 DORA metrics(배포 빈도, 리드 타임 등)를 측정하려고 하거나, Jira와 GitHub을 연동해 온갖 차트를 그려보곤 합니다.

Gitmore와 같은 도구가 등장하는 배경은 명확합니다. 플랫폼이 파편화되어 있기 때문입니다. 어떤 팀은 레거시 때문에 Bitbucket을 쓰고, 신규 프로젝트는 GitHub을 씁니다. 혹은 외주사와의 협업 때문에 GitLab을 쓰기도 하죠. 이 데이터를 한 통에 담아 '인사이트'라는 이름으로 정제하고 싶은 욕구는 자연스럽습니다. 특히 AI가 그 데이터들 사이의 맥락을 읽어준다면 금상첨화겠죠.

하지만 앞서 언급한 댓글처럼, '권한(Permission)'의 문제는 결코 가볍지 않습니다. 소스 코드는 IT 기업의 가장 중요한 자산입니다. 아무리 기능이 화려해도, 검증되지 않은 서드파티 도구에 우리 저장소의 '읽기/쓰기' 권한을 내주는 것은 마치 집 열쇠를 모르는 사람에게 맡기는 것과 같습니다. 보안은 기능보다 언제나 우선순위가 높아야 합니다.

데이터 분석, '무엇'보다 '왜'가 먼저입니다

저는 풀링포레스트에서 엔지니어링 문화를 만들어갈 때, 도구 도입에 앞서 항상 '왜(Why)'를 먼저 묻습니다.

"우리는 왜 Git 분석 데이터가 필요한가?"

많은 조직이 단순히 '관리'를 위해 데이터를 봅니다. 누가 커밋을 많이 했는지, 누가 PR을 빨리 닫았는지를 감시하는 용도로 쓰죠. 이런 목적이라면 굳이 AI까지 동원된 화려한 대시보드는 필요 없습니다. 오히려 독이 됩니다. 개발자들은 숫자를 채우기 위해 무의미한 커밋을 늘리거나, 코드 퀄리티보다 PR 개수에 집착하게 될 테니까요.

진정한 의미의 Git 분석은 '건강함'을 체크하는 용도여야 합니다.

• PR 리뷰가 특정 시니어에게만 몰려 병목이 생기고 있지는 않은가?

• 배포 직전에 급하게 수정되는 코드가 너무 많지 않은가?

• 특정 모듈에서 버그 픽스 커밋이 비정상적으로 반복되지 않는가?

이런 질문에 답하기 위해 우리는 데이터를 봐야 합니다. 외부 도구를 쓰든, 자체적으로 GitHub API를 찔러 간단한 스크립트를 짜든, 도구는 그 질문을 해결해 주는 수단일 뿐입니다.

AI 시대, 개발 생산성 도구의 미래

최근 저희 팀에서도 생성형 AI를 활용한 업무 프로세스 혁신을 시도하고 있습니다. Gitmore가 시도하려는 방향성, 즉 'AI가 활동을 요약하고 질문에 답해주는 것'은 분명히 유효한 트렌드입니다.

과거에는 팀장이 일일이 커밋 로그를 뒤져가며 주간 보고서를 썼다면, 이제는 AI 에이전트가 "지난주 결제 모듈 관련 변경 사항 요약해 줘"라는 질문에 답할 수 있어야 합니다. 이는 단순한 자동화가 아니라, 개발자가 '맥락(Context)'을 파악하는 시간을 획기적으로 줄여주기 때문입니다.

다만, 이것을 외부 SaaS에 전적으로 의존할 것인지, 아니면 내부망에 구축된 안전한 LLM과 API를 활용해 자체 파이프라인을 만들 것인지는 선택의 영역입니다. 보안이 생명인 기업이라면 후자를 택해야겠죠.

맺으며: 도구는 거들 뿐, 핵심은 문화

CTO로서 도구 도입을 검토할 때 저는 두 가지를 봅니다. 첫째는 보안과 신뢰성이고, 둘째는 그 도구가 우리 팀의 자율성을 해치지 않는지입니다.

해커뉴스에 올라온 Gitmore 같은 시도들은 반가운 일입니다. 우리에게 새로운 가능성을 보여주니까요. 하지만 그 도구를 덜컥 도입하기 전에, 먼저 우리 팀의 상태를 돌아보셨으면 좋겠습니다. 우리가 진짜로 궁금한 것이 '개발자의 활동량'인지, 아니면 '제품의 건전성'인지 말이죠.

기술은 항상 문제를 해결하기 위해 존재해야 합니다. 문제를 정의하지 않은 채 도구부터 쥐어주는 것은, 답안지도 없이 문제만 잔뜩 푸는 것과 다를 바 없습니다.

오늘도 수많은 커밋과 PR 속에서 팀의 성장을 고민하는 리더분들께, 이 글이 작은 환기가 되었기를 바랍니다. 감사합니다.