AI 대시보드가 녹색이라도 실제 배포가 그렇지 않을 수 있습니다

SDM 및 디렉터를 위한 DORA 및 DX 지표 진단 도우미

Faros AI는 약 10,000명의 개발자로부터 전송 데이터를 분석한 결과, AI를 많이 도입한 팀은 이전보다 98% 더 많은 풀 리퀘스트(PR)를 병합했지만, 그들의 배포 지표는 변함이 없다는 것을 발견했습니다. 별도로 METR는 숙련된 오픈 소스 개발자를 대상으로 통제된 실험을 진행했습니다. 이들은 AI 도구를 사용했을 때 작업을 완료하는 데 19% 더 오랜 시간이 걸렸습니다. 나중에 질문하자, 그들은 AI가 자신들을 20% 더 빠르게 만들었다고 추정했습니다.

이 모든 것이 AI가 쓸모없다는 것을 의미하지는 않습니다. 많은 팀들이 AI로부터 실제 가치를 얻습니다. 이것이 의미하는 바는 일반적인 대시보드가 누군가가 그것이 성공인지 아닌지 알기도 전에 AI를 성공처럼 보이게 할 수 있다는 것입니다. PR 건수의 증가는 질문을 시작해야 하는 이유입니다.

이 가이드는 지표 검토 회의 때 인쇄하여 테이블 위에 두고 볼 수 있도록 작성되었습니다. 회의 전에 체크리스트를 확인하세요. 화면에서 숫자가 움직일 때, 치트 시트(cheat sheet)에서 그것을 찾아 어떤 진단에 해당하는지 보고 거기에 나열된 질문들을 사용하세요. 마지막에는 후속 조치를 위한 추적기가 있습니다.

만약 한 가지만 기억한다면: PR 건수와 다른 활동 수치는 AI에 반응하여 몇 주 안에 변하고 부풀리기 쉽습니다. 배포 및 품질 수치는 움직이는 데 시간이 더 오래 걸리며, 이것들이 실제로 개선되었는지 알려주는 지표입니다. 항상 이들을 함께 읽으세요.

회의 전

다섯 가지 점검 사항. 만약 그 중 어느 하나에 대한 답이 '아니요'라면, 아무도 결론을 내리기 전에 누락된 부분을 요청하세요.

• 각 팀은 다른 팀들과 비교되는 것이 아니라 AI 도입 이전의 자체 수치와 비교되고 있습니까?
• 데이터가 최소 8주를 다루고 있습니까? 단일 스프린트는 너무 잡음이 많아 읽기 어렵습니다.
• 조직 개편(reorgs), 마이그레이션, 채용 물결, 큰 사고(big incidents) 및 휴일이 타임라인에 표시되어 있습니까?
• 새로운 기능, 유지보수 작업, 레거시 작업이 분리하여 표시되고 있습니까?
• PR 건수와 같은 모든 활동 지표 옆에 품질 또는 배포 지표가 함께 있습니까?

치트 시트

지표당 한 행. 마지막 열은 해당 지표가 언급될 때 물어봐야 할 질문입니다.

용어 (Terms)

이러한 용어들을 방의 모든 사람이 동일하게 사용하는 것이 시간을 절약해 줍니다.

• 재작업 (Rework): 병합된 후 약 3주 이내에 다시 작성되거나 되돌려지는 코드.
• 리뷰 참여도 (Review participation): 저자(author)가 아닌 다른 사람에 의해 최소 한 번 리뷰된 PR의 비율.
• 누출 결함 (Escaped defects): 검토나 테스트 과정이 아니라, 사용자나 운영 환경에서 발견되는 버그.
• 배포 용이성 (Ease of delivery): 개발자들이 변경 사항을 운영 환경에 반영하는 것이 얼마나 쉽다고 말하는지. 이는 코드를 작성하기 쉬운 정도와는 다릅니다.
• AI 지원 PR (AI-assisted PR): 코드의 의미 있는 부분이 AI 도구에서 나온 PR로, 사용 중인 툴링(tooling)에 의해 태그되거나 저자에 의해 선언된 경우.
• 가드레일 지표 (Guardrail metric): 추가적인 활동이 다른 곳에서 비용을 발생시키는지 보여주는 품질 또는 배포 지표.

예상되는 점 (What to expect)

숫자들이 나오기 전에 몇 가지 말해둘 가치가 있는 것들이 있습니다. 왜냐하면 이것들이 전체 검토의 분위기를 조성하기 때문입니다.

대부분의 팀은 AI를 사용한다고 해서 처음부터 좋은 상태가 아닙니다. 일반적인 초기 상황은 활동량은 늘어나지만 배포는 정체되어 있거나, 활동량은 늘어나지만 품질이 약간 떨어지는 경우입니다. 이것은 정상적인 단계이며 실패로 간주해서는 안 됩니다.

어떤 이득도 있기 전에 보통 하락기(dip)가 있습니다. 팀들은 AI가 어디에 유용한지 파악하고, 어떻게 리뷰하고 배포할지 조정하는 시간이 필요합니다. 만약 배포 지표가 개선된다면, 종종 2분기 이상이 걸립니다.

혼합된 신호를 예상해야 합니다. 한 지표는 좋아지고 다른 지표는 나빠지는 것이 일반적인 상황입니다. 여러분의 임무는 그 팀에게 어떤 지표가 더 중요한지 알아내는 것입니다.

같은 도구라도 한 팀에는 도움이 되고 다른 팀에는 해로울 수 있습니다. AI는 새롭고 독립적인 작업에서는 잘 작동하는 경향이 있지만, 크고 오래되었으며 강하게 결합된 코드베이스(tightly coupled codebases)에서는 성능이 떨어지는 경향이 있습니다.

만약 어떤 팀의 AI 보고서가 1분기에 걸쳐 모두 좋은 소식이라면, 그것은 더 깊이 들여다볼 이유가 됩니다.

어떤 진단이 적절할까요?

1. AI가 도움을 주고 있다 |
   | ... |

1. AI가 도움을 주고 있다

보이는 것. PR이 늘어나고 PR 크기는 거의 같은 수준을 유지합니다. 검토 시간과 검토 참여도는 변동이 없습니다. 빌드는 건강하게 유지되고 리워크(rework)는 평탄합니다. 한두 분기 후, 리드 타임은 떨어지고 배포 빈도(deployment frequency)가 높아지며, 실패율(failure rate)과 복구 시간(time to restore)은 안정적으로 유지됩니다. 설문조사에서 개발자들은 변경 사항을 내보내는 것이 더 쉬워졌다고 말하며, 이는 단순히 코드를 작성하는 것(typing)이 아니라 배포(shipping)를 의미합니다.

실제 상황. 팀은 이미 작은 변경, 빠른 CI(Continuous Integration), 적절한 테스트, 그리고 충분한 검토 인력을 갖춘 기본기를 가지고 있었습니다. AI가 속도를 더해주었고, 팀의 프로세스가 이를 받아들일 수 있었던 것입니다.

믿기 전에 물어보세요.

• 같은 기간 동안 다른 변화는 없었나요? 강력한 신규 채용자, 마침내 완료된 마이그레이션(migration), 조용한 분기 같은 것들은요?
• 얻은 성과가 새로운 서비스와 같은 특정 종류의 작업에만 집중되어 있고, 유지보수 작업은 변함이 없지는 않나요?
• 검토 시간이 안정적인 것이 검토자들이 따라잡고 있기 때문인가요, 아니면 이제는 훑어보는(skimming) 방식으로 바뀌었기 때문인가요?
• 2분기 동안도 지속될까요?

후속 조치할 것. 이 팀이 다르게 하는 것이 무엇인지 알아내서 기록하세요. 인접한 다른 팀 하나에 적용해 보고 같은 패턴이 나타나는지 확인해 보세요. 리워크와 탈출 결함(escaped defects)을 주시하세요. 왜냐하면 한 팀은 지금 건강해 보여도 나중에 흐트러질 수 있기 때문입니다.

2. 바쁘지만 더 빠르지는 않다

보이는 것. PR이 늘어납니다. 리드 타임과 배포 빈도는 움직이지 않습니다. 실패율, 리워크, 빌드 건강 상태 모두 양호해 보입니다. 개발자들은 코드를 작성하는 것이 더 빨라졌다고 말하지만, 릴리스를 내보내는 것은 이전과 똑같다고 느낍니다.

실제 상황. 코드를 작성하는 것 자체가 이 팀을 늦추는 요인이 아니었습니다. 변경 사항들은 지금 다른 곳 어딘가에 대기하고 있으며, 보통은 검토 과정(review), 테스트 환경(test environments), 릴리스 승인(release approvals) 단계나 다른 팀에 있습니다. AI가 병목 현상(bottleneck)이 아닌 단계를 더 빠르게 만들었을 뿐입니다.

질문해 보세요.

• 일반적으로 변경 사항은 커밋부터 프로덕션까지 어느 단계에서 가장 많은 시간을 보낼까요?
• PR(Pull Request)은 검토되기까지 얼마나 오래 기다리나요?
• 릴리스에는 몇 번의 승인과 수동 단계가 필요한가요?
• AI가 절약한 시간은 어디에 사용되었나요?

후속 조치할 사항. 최근 변경 사항 3~5개를 선택하여 첫 커밋부터 프로덕션까지 각 항목을 추적하고, 기다렸던 모든 지점을 기록하세요. AI 도구에 더 많은 투자를 하기 전에 가장 긴 대기 시간을 먼저 해결하세요. 절약된 시간이 무엇에 사용되어야 할지 목적을 정해야 합니다. 아무도 결정하지 않으면, 이는 진행 중인 작업(work in progress)이 늘어나는 것으로 변하고 대기 시간은 더욱 길어집니다.

작동하고 있다는 것을 알 수 있는 시점. 리드 타임(lead time)이 감소하기 시작하고 PR 크기와 실패율은 이전과 같은 수준을 유지할 때입니다.

3. 더 빠르지만 깨지는 경우 (Faster but breaking)

발견되는 현상. PR의 수가 증가하며, 종종 많은 양으로 늘어납니다. PR 자체도 커지고 검토하기 어려워집니다. 검토 시간이 증가하거나, 검토 참여도가 떨어져 아무런 확인 없이 PR이 병합됩니다. 빌드 성공률이 하락하거나, 빌드가 느려집니다. 재작업(Rework)이 증가합니다. 변경 실패율(Change failure rate)이 높아지고, 복구에 걸리는 시간도 함께 늘어날 수 있습니다. 검토자들은 업무가 과부하되었다고 말하고, 번아웃(burnout) 현상이 설문조사에 나타나기 시작합니다.

일반적으로 발생하는 원인. 코드를 생산하는 것은 저렴해졌습니다. 하지만 검토, 테스트 및 릴리스하는 과정은 그렇지 못했습니다. 팀이 프로세스가 안전하게 처리할 수 있는 것보다 더 많은 것을 배출하고 있습니다.

질문해 보세요.

• 이번 달에 적절하게 검토하기에는 너무 큰 PR은 무엇인가요?
• 실제 사람의 검토 없이 병합된 것은 무엇인가요?
• 최근 사고나 롤백(rollback) 중 AI 지원 코드가 관련된 경우는 무엇인가요?
• 누가 가장 많은 검토를 수행하고 있으며, 따라잡기 위해 그들이 중단한 활동은 무엇인가요?
• AI가 사용 가능해진 지금, 더 많은 결과물을 보여줘야 한다는 압박을 느끼는 사람이 있나요?

후속 조치할 사항. PR에 크기 제한을 두고 큰 PR은 분할하세요. 검토자의 시간을 보호하고 검토를 팀원들에게 분산시키세요. 테스트와 CI(Continuous Integration) 체크를 강화하고, 위험한 변경 사항은 점진적으로 또는 기능 플래그(feature flags) 뒤에서 배포하세요. 만약 어떤 목표가 PR 개수나 AI 사용량을 보상한다면, 그 목표를 폐지하세요.

작동하고 있다는 것을 알게 되는 시점은 PR 크기와 리뷰 시간이 먼저 감소할 때입니다. 실패율과 재작업(rework)은 보통 분기 내에 뒤따릅니다.

4. 좋아 보이지만 그렇지 않은 경우

이 경우는 제목으로 된 수치들이 모두 괜찮아 보여서 알아차리기 어렵습니다.

보이는 것. 리뷰 시간이 줄고, 테스트 커버리지는 높아지며, 사람들은 더 만족합니다. 하지만 그 이면에서는 재작업이 증가하고, 매달 사용자에게 도달하는 버그가 몇 개씩 늘어나며, 중복 코드가 늘어나고, 보안 취약점이나 유출된 비밀 정보가 AI 지원 코드에서 나타나기 시작합니다.

실제 상황. 품질 검사(quality checks)는 실제로 확인하지 않고 통과하고 있습니다. 리뷰가 가벼워졌거나, 리뷰 봇이 전담하여 사람들이 그 승인을 받아들이고 있습니다. AI가 테스트를 작성하지만 코드를 충분히 테스트하지 않습니다. 스캐너는 간단한 문제만 잡아내고 설계 및 접근 제어(access-control) 문제는 놓칩니다. 배포 자체는 아직 피해를 입지 않았지만, 비용은 쌓이고 있습니다.

질문해 보세요.

• 리뷰 시간이 줄어든 이유는 무엇인가요? 사람들이 코드를 읽는지 아니면 단순히 승인만 하는 건가요?
• 우리의 테스트가 실제 버그를 잡아내나요, 아니면 주로 커버리지(coverage)만 높이는 데 집중하나요?
• 우리 리뷰 중 얼마나 많은 부분이 이제 봇에 의해 수행되며, 사람들은 직접 확인하지 않고도 그 승인을 받아들이고 있나요?
• 누군가 여전히 리팩토링(refactoring)을 하고 있나요?
• 스캐너가 찾지 못하는 보안 문제에 대해 누가 AI 지원 코드를 검토하나요?

후속 조치할 것. 각 품질 지표를 결과와 짝지으세요. 리뷰 시간은 리뷰 참여도와, 커버리지는 누출된 결함(escaped defects)과 연결합니다. 최근 승인된 PR 몇 개를 골라 읽어보며 리뷰가 얼마나 신중했는지 확인하세요. 리팩토링을 실제 작업으로 계획하세요. 비밀 정보 스캐닝(secret scanning)을 추가하고, 사람이 민감한 AI 지원 변경 사항에 대해 보안 검토를 하도록 하세요.

작동하고 있다는 것을 알게 되는 시점은 누출된 결함, 재작업 및 보안 취약점이 증가하는 것을 멈추고 리뷰 참여도가 높은 상태를 유지할 때입니다.

5. 느리지만 아무도 알아차리지 못하는 경우

보이는 것. 리드 타임(Lead time)이 늘어나거나, 작업 완료 시간이 더 오래 걸립니다. PR 개수는 정체되거나 약간 증가합니다. 개발자들은 여전히 AI가 자신들을 더 빠르게 만든다고 말합니다.

일반적으로 발생하는 일. 복잡하고 성숙한 코드의 경우, AI 제안을 확인하고 수정하는 데 시간이 걸리는 것이 직접 코드를 작성하는 것보다 더 오래 걸릴 수 있습니다. 타이핑이 더 빠르다고 느껴지기 때문에 사람들은 검토, 수정 및 도구에 컨텍스트를 설명하는 데 들어가는 시간을 알아차리지 못합니다. 이것이 METR가 발견한 패턴입니다.

질문할 내용.

• 우리 코드베이스의 어떤 부분이 AI가 잘 처리하고, 어디서 어려움을 겪나요?
• AI 출력을 수정하거나 재프롬프트하는 데 얼마나 많은 시간이 걸리나요?
• 속도 저하가 주로 하나의 코드베이스나 한 종류의 작업에서 발생하나요?
• 여기 계신 분들 중 AI 때문에 저항으로 인식되지 않으면서 속도가 느려졌다고 말할 수 있는 사람이 있나요?

후속 조치할 내용. 작업 유형별로 리드 타임(lead time)을 비교하세요. 팀 차원에서 AI가 유용한 부분과 선택적인 부분을 합의해야 합니다. 까다로운 코드베이스의 경우, 이득을 기대하기 전에 문서화나 코드 구조와 같이 AI가 참고할 수 있는 컨텍스트를 개선하는 것이 중요합니다.

작동하고 있다는 것을 알게 되는 시점은 해당 작업의 리드 타임이 이전 수준으로 돌아오거나 더 좋아졌을 때입니다.

들을 수 있는 것과 되물어볼 내용

• 개인을 순위 매기는 데 이러한 지표를 사용하지 마세요. 이들은 팀과 시스템을 설명하는 것이며, 사람들이 개인적으로 점수가 매겨진다는 것을 알게 되면 데이터는 더 이상 정직하지 않습니다.
• AI 사용에 대한 목표를 설정하지 마세요. 사람들은 그 목표를 달성할 것이고, 당신은 가치에 대해 아무것도 배우지 못할 것입니다.
• 팀들을 서로 비교하지 마세요. 그들의 코드베이스와 작업은 너무 다릅니다. 각 팀을 그 자체의 역사와 비교하세요.
• 한 스프린트만으로 판단하지 마세요. 8주에서 13주에 걸친 패턴을 기다리세요.
• DORA 지표를 조직 전체에 걸쳐 평균 내지 마세요. 이들은 서비스별 또는 팀별로 읽어야 합니다.
• AI에 대한 나쁜 소식을 저항으로 취급하지 마세요. 만약 그것이 팀에게 도움이 되지 않는다면, 당신은 알고 싶어 할 것입니다.

가능하다면 AI 지원 작업을 분리하세요

일부 도구는 AI가 지원한 PR(Pull Request)을 태그하거나, 작성자들에게 이를 선언하도록 요청할 수 있습니다. 만약 그 정보를 가지고 있다면, 다음 항목에 대해 동일 팀 내에서 AI 지원 PR과 다른 PR을 비교해 보세요: