플랫폼을 쓰는 팀이 처리량 8%, 변경 안정성 14%가 더 낮았다 — DORA 데이터를 인과로 읽으면 안 되는 이유

들어가며 — "도입률 90%"라는 숫자부터 뜯어보기
DORA 2024가 실제로 발견한 것 — 좋은 소식과 불편한 소식
DORA 자신이 내놓은 세 가지 가설 — 세 번째가 중요하다
2025년, DORA는 "효과"라는 단어를 버렸다
"플랫폼 품질"은 무엇으로 측정되었나
벤더 리서치 읽는 법 — Puppet 2026 편
이 데이터로 할 수 있는 말과 할 수 없는 말
그래서 월요일에 무엇을 할 것인가
마치며
참고 자료

들어가며 — "도입률 90%"라는 숫자부터 뜯어보기

2026년 중반에 플랫폼 엔지니어링을 해야 하느냐고 묻는 사람은 별로 없습니다. 논쟁은 끝난 것처럼 보입니다. DORA의 2025년 리포트는 플랫폼 챕터의 핵심 발견을 이렇게 요약합니다 — "플랫폼 도입은 거의 보편적이다: 90%." 전담 플랫폼 팀을 둔 조직은 76%로, 이제 지배적인 조직 모델이라고 적혀 있습니다.

그런데 이 숫자가 무엇을 센 것인지부터 봐야 합니다. DORA가 설문에서 쓴 플랫폼의 정의는 부록에 이렇게 적혀 있습니다 — 플랫폼이란 "여러 애플리케이션이나 서비스에 걸쳐 공유되는 역량의 집합"이고, 한 회사에 겹치는 플랫폼이 여러 개 있을 수 있지만 그걸 통칭해 "그 플랫폼"이라 부른다는 것입니다.

이 정의라면 전사가 같이 쓰는 Jenkins 하나도 플랫폼입니다. 공유 쿠버네티스 클러스터도 플랫폼이고, 사내 공통 CI 템플릿도 플랫폼입니다. 2024년 리포트는 이 점을 더 노골적으로 적었습니다 — 올해 설문에서는 내부 개발자 플랫폼의 정의를 "꽤 넓게(quite broad)" 두었고, 그 결과 응답자의 89%가 내부 개발자 플랫폼을 쓰고 있는 것으로 나왔다고요.

그러니 "도입률 90%"는 "90%의 조직이 Backstage 같은 포털과 골든 패스를 갖췄다"는 뜻이 아닙니다. "90%의 조직에 공유되는 무언가가 있다"에 가깝습니다. 이 차이를 붙잡고 있어야 나머지 숫자들이 제대로 읽힙니다.

그리고 진짜 흥미로운 건 그 다음입니다. 같은 연구 프로그램이, 플랫폼을 쓰는 쪽이 처리량과 안정성에서 더 나빴다고 보고했다는 사실입니다.

DORA 2024가 실제로 발견한 것 — 좋은 소식과 불편한 소식

2024년 DORA 리포트는 플랫폼 엔지니어링에 챕터 하나를 통째로 할애했습니다. 그해 설문에는 전 세계에서 약 3,000명의 실무자가 응답했습니다. 리포트의 표현을 그대로 옮기면 이렇습니다.

좋은 소식 쪽:

내부 개발자 플랫폼 사용자는 개인 생산성이 8% 높았다.
팀 성과는 10% 높았다.
조직의 소프트웨어 딜리버리 및 운영 성과는 플랫폼을 쓸 때 6% 높아진다.

여기까지는 우리가 기대하던 그림입니다. 그런데 바로 다음 문장이 이렇게 이어집니다 — "그러나 이 이득이 대가 없이 오지는 않는다. 처리량과 변경 안정성은 각각 8%와 14% 감소했는데, 이는 놀라운 결과였다."

리포트는 이 대목에 "예상치 못한 단점(The unexpected downside)"이라는 소제목까지 따로 붙였습니다. 숫자를 다시 뜯어보면:

처리량. 플랫폼을 쓰지 않는 쪽과 비교해 약 8% 감소.
변경 안정성. 14% 감소. 리포트는 이게 무슨 뜻인지 친절하게 풀어 씁니다 — "변경 실패율과 재작업 비율이 플랫폼을 쓸 때 유의미하게 증가한다"는 뜻입니다.

여기에 하나가 더 붙습니다. 플랫폼을 "전체 애플리케이션 생애주기 동안 반드시 플랫폼만 써서" 작업하도록 요구받는다고 답한 응답자들에게서는 처리량이 6% 더 낮았습니다. 플랫폼 사용을 의무화한 쪽이 더 느렸다는 겁니다.

그리고 가장 불편한 조합 — 리포트는 불안정성과 플랫폼이 결합되면 번아웃 수준이 더 높아지는 연결고리를 발견했다고 적습니다. 다만 곧바로 못을 박습니다: "그렇다고 플랫폼이 번아웃을 유발한다는 말은 아닙니다."

이 문장이 이 글 전체의 핵심입니다.

DORA 자신이 내놓은 세 가지 가설 — 세 번째가 중요하다

여기서 DORA를 높이 평가할 만한 지점이 나옵니다. 자기 데이터가 자기 주장과 어긋나는 결과를 냈을 때, 리포트는 그걸 숨기거나 얼버무리지 않고 "우리도 왜인지 완전히는 모른다"고 쓴 뒤 가설을 나열합니다.

첫째, 기계장치가 늘어난다. 배포 전에 변경이 통과해야 하는 단계가 많아졌다는 설명입니다. 리포트의 표현으로는, 내부 개발자 플랫폼으로 빌드하고 배포하면 시스템 사이의 — 그리고 암묵적으로 팀 사이의 — "핸드오프" 수가 대개 늘어납니다. 코드를 커밋하면 테스트, 보안 검사, 배포, 모니터링을 담당하는 서로 다른 시스템이 차례로 집어 갑니다. 각 핸드오프는 시간이 끼어들 기회이고, 그래서 처리량이 떨어지지만 "일을 끝낼 수 있는 능력은 순증한다"는 것입니다.

둘째, 강제된 배타성. 위에서 본 6% 감소입니다. 플랫폼이 그 일에 적합하지 않은데도 반드시 써야 한다면, 늘어난 지연이 그대로 비용이 됩니다.

셋째 — 그리고 이게 결정적입니다 — 역인과 가설. 리포트를 그대로 옮기면 이렇습니다: 변경 불안정성과 번아웃 수준이 높은 팀이 안정성을 개선하고 번아웃을 줄이려는 노력으로 플랫폼을 만드는 경향이 있다는 것. 그리고 한 문장 더 — "이 가설대로라면, 플랫폼 엔지니어링은 번아웃과 변경 불안정성을 가진 조직의 증상(symptomatic)입니다."

곱씹어 볼 만합니다. 이게 사실이라면 화살표가 반대입니다. 플랫폼이 불안정성을 만든 게 아니라, 불안정한 조직이 플랫폼을 만든 겁니다. 아픈 사람이 병원에 많다고 병원이 병을 만든 게 아닌 것과 같습니다.

그리고 이 설문 데이터만으로는 두 방향을 구분할 방법이 없습니다. 어느 시점의 스냅샷 하나로는, "플랫폼 → 불안정"과 "불안정 → 플랫폼"이 똑같은 상관관계로 보입니다.

안정성 하락에 대해서도 리포트는 비슷하게 여러 갈래를 열어 둡니다. 하나는 낙관적인 해석입니다 — 플랫폼이 있으면 나쁜 변경이 나가도 빠르게 복구할 수 있다는 자신감이 생기고, 그래서 팀이 더 실험적으로 더 자주 밀어 넣습니다. 이 경우 높아진 변경 실패율은 나쁜 신호가 아니라 실험이 늘어난 결과입니다. 다른 하나는 비관적인 해석입니다 — 플랫폼이 자동화된 테스트 실행을 제공하는데 애플리케이션 팀이 정작 테스트를 개선하지 않고 처리량만 우선하면, 나쁜 변경이 그냥 통과해서 재작업으로 돌아옵니다.

같은 숫자가 정반대의 이야기 두 개를 지지합니다. 이건 데이터의 결함이라기보다, 이런 종류의 데이터가 원래 할 수 있는 말의 한계입니다.

한 가지 더, 2024년 리포트에는 자주 인용되지 않는 유용한 발견이 있습니다. 플랫폼의 나이를 함께 보면 곡선이 J자를 그립니다 — 플랫폼 이니셔티브 초기에 성과가 오르고, 그다음 하락과 회복을 거치며 플랫폼이 성숙합니다. 리포트는 이걸 "초기 이득을 실현한 뒤 어려움을 만나는" 전형적인 전환 이니셔티브 패턴이라고 부릅니다. 장기적으로는 생산성 이득이 유지된다고도 적혀 있습니다. 2년 차에 숫자가 나빠졌다고 플랫폼 팀을 해체하려는 조직이 있다면, 이 J커브를 보여 주는 게 도움이 될 수 있습니다.

그리고 무엇이 이득을 만드는지에 대한 발견도 구체적입니다. 개발자 독립성 — "개발자가 인에이블링 팀에 의존하지 않고 애플리케이션 생애주기 전체에 걸쳐 자기 일을 수행할 수 있는 능력"으로 정의됩니다 — 이 확보되면 개인과 팀 양쪽에서 생산성이 5% 향상됩니다. 반면 전담 플랫폼 팀의 존재는 개인 생산성에는 영향이 미미했고 팀 수준에서만 6% 이득이 있었습니다. 그리고 플랫폼에 대한 피드백을 수집하지 않는 것은 부정적 영향을 준다고 명시돼 있습니다.

2025년, DORA는 "효과"라는 단어를 버렸다

2025년 리포트는 2025년 9월에 나왔습니다. 표본은 4,867명(리포트 표현으로는 "거의 5,000명")이고, 100시간이 넘는 정성 데이터가 함께 들어갔습니다.

이 리포트에서 가장 눈여겨볼 대목은 플랫폼 챕터가 아니라 각주입니다. 20번 각주를 그대로 옮기면 이렇습니다.

작년에 우리는 "효과(effects)"라는 표현을 썼습니다. 그러나 올해는 "비교(comparisons)"의 언어로 말하려 합니다. 인과적으로 말할 수 있는 조건을 만들려 노력하지만, 우리가 근저의 인과 구조를 이해하고 있다는 잘못된 확신을 주고 싶지 않습니다. 때때로 인과적 표현을 쓰겠지만, 궁극적으로 우리가 하는 것은 비교입니다.

그리고 그 근거로 겔만과 힐의 『Regression and Other Stories』를 인용합니다 — 관찰된 것은 관찰적 패턴이며, "회귀에 대한 가장 안전한 해석은 비교로 보는 것"이라고요.

이건 흔한 일이 아닙니다. 매년 수천 명을 조사해 리포트를 파는 연구 프로그램이, 자기 표현의 강도를 스스로 한 단계 낮춘 겁니다. 그런데 정작 이 리포트를 인용하는 기사와 컨퍼런스 슬라이드는 거의 예외 없이 "플랫폼이 조직 성과를 높인다"는 인과문으로 옮깁니다. 원문이 "비교"라고 못 박은 것을요.

플랫폼 챕터의 내용도 정직합니다. 2025년 리포트는 2024년의 발견을 이렇게 요약합니다 — 플랫폼은 조직 성과와 생산성에 긍정적 영향을 주지만, "그 이득에는 트레이드오프가 따라왔다: 소프트웨어 딜리버리 불안정성 증가와 처리량 감소."

그리고 2025년 데이터에서도 이 패턴은 사라지지 않았습니다. 리포트는 이렇게 적습니다 — "과거 연구와 일관되게, 더 나은 플랫폼은 소프트웨어 딜리버리 불안정성의 작지만 신뢰할 만한 증가와 연관되어 있으며, 이는 더 높은 변경 실패율과 재작업 증가를 의미한다."

DORA의 해석은 이번엔 낙관 쪽으로 기웁니다 — 이 불안정성 증가는 "건강한 고속 시스템의 특징일 수 있다"는 것이고, 플랫폼이 실패로부터의 복구를 빠르고 값싸게 만들어 주니 팀이 더 실험하고 사소한 실패를 더 감수하는 일종의 리스크 보상(risk compensation)이라는 겁니다. 그럴듯한 해석입니다. 다만 이것도 해석이지 측정된 게 아닙니다.

"플랫폼 품질"은 무엇으로 측정되었나

2025년 리포트의 헤드라인 발견은 이겁니다 — 고품질 내부 플랫폼이 AI 도입의 효과를 증폭한다. 더 정확히는, 플랫폼 품질이 낮을 때 AI 도입이 조직 성과에 주는 영향은 무시할 만한 수준이고, 플랫폼 품질이 높을 때는 강하고 긍정적입니다. 구글 클라우드 블로그가 "고품질 내부 플랫폼과 AI 가치 실현 능력 사이에 직접적인 상관관계"라고 홍보한 그 발견입니다.

그러면 "플랫폼 품질"은 어떻게 측정됐을까요. 리포트 본문은 이렇게 설명합니다 — 플랫폼 품질은 응답자가 자기 플랫폼이 가지고 있다고 답한 12개 특성의 개수를 나타내는 단일 점수로 측정됩니다.

부록에 그 문항이 실려 있습니다. "당신의 플랫폼은 다음 특성을 어느 정도로 보여 줍니까?"라는 질문에 딸린 항목들입니다.

- 플랫폼이 신뢰할 수 있는 애플리케이션과 서비스를 만들고 운영하도록 돕는다
- 플랫폼이 안전한 애플리케이션과 서비스를 만들고 운영하도록 돕는다
- 플랫폼의 UI가 명료하고 깔끔하다
- 플랫폼이 독립적으로 일하는 데 필요한 도구와 정보를 제공한다
- 플랫폼이 내가 예상하는 방식으로 동작한다
- 플랫폼이 필요한 프로세스(코드 리뷰, 보안 승인 등)를 따르도록 돕는다
- 플랫폼이 내 작업 결과에 대해 명확한 피드백을 준다
- 플랫폼에서 수행하는 작업이 잘 자동화되어 있다
- 플랫폼 팀이 내가 준 피드백에 따라 움직인다
- 플랫폼이 사용하기 쉽다
- 플랫폼이 하위 인프라의 복잡성을 효과적으로 추상화한다

읽어 보면 알겠지만, 이건 전부 주관적 인식입니다. "플랫폼이 사용하기 쉽다", "내가 예상하는 방식으로 동작한다" — 측정된 지표가 아니라 개발자가 느낀 것입니다. 여기에 나쁜 뜻은 없습니다. 개발자 경험은 원래 주관적인 것이고, 그걸 묻는 건 정당합니다.

문제는 결과 변수 쪽도 똑같이 주관적이라는 데 있습니다. 부록의 "결과를 어떻게 평가했는가" 절을 보면, 조직 성과(organizational performance)는 이런 문항으로 측정됩니다 — "지난 1년간 당신의 조직은 목표 대비 다음 지표에서 어떻게 했습니까?" 그리고 항목은 조직의 전반적 성과, 전반적 수익성, 조직 및 미션 목표 달성, 고객 만족, 운영 효율, 제품·서비스 품질입니다.

즉 감사받은 재무제표가 아닙니다. 응답자가 자기 회사의 수익성을 목표 대비 어떻게 느끼는지 리커트 척도로 답한 것입니다. 생산성도, 코드 품질도, 개인 효과성도 전부 "self-assessed"라고 부록에 명시돼 있습니다.

그러면 "고품질 플랫폼이 조직 성과를 높인다"는 문장의 실제 내용은 이렇게 됩니다 — 자기 플랫폼을 좋게 평가한 사람은 자기 회사도 좋게 평가하는 경향이 있다. 이건 여전히 의미 있는 발견입니다. 하지만 인과 주장과는 거리가 멉니다. 회사가 잘 나가서 플랫폼에 투자할 여력이 있었을 수도 있고, 그냥 회사를 긍정적으로 보는 사람이 모든 문항에 후하게 답했을 수도 있습니다(공통 방법 편향이라고 부르는 그것입니다).

표본 모집 방식도 봐 둘 만합니다. 리포트의 방법론 챕터가 직접 밝히는 대로, DORA는 두 경로로 응답자를 모읍니다 — 블로그·이메일·소셜 미디어를 통한 "유기적(organic)" 경로이고, 여기엔 커뮤니티에 부탁해서 퍼뜨리는 스노볼 샘플링이 포함됩니다. 그리고 이를 보완하는 패널 경로가 있습니다. 확률 표본이 아닙니다. DORA의 소셜 미디어와 커뮤니티 반경 안에 있는 사람들, 즉 DevOps 담론에 이미 관여한 사람들이 과대 표집됩니다. 정성 인터뷰 쪽 편향은 더 뚜렷합니다 — 리포트 스스로 밝히듯 78명의 인터뷰 대상자 중 76명이 미국에 있었고, 리포트는 이를 인터뷰어의 언어 능력과 일정상 제약 때문이라고 설명합니다.

마지막으로, 이 리포트의 발행 주체를 짚고 넘어가야 합니다. 2025년 DORA 리포트는 구글 클라우드가 발행하며(저작권 표시는 "Google LLC", CC BY-NC-SA 4.0), 리서치 파트너로 IT Revolution, GitHub, GitLab, SkillBench, Workhelix가 이름을 올렸습니다. 클라우드와 개발자 도구를 파는 회사들이 "플랫폼과 AI에 투자하라"는 결론이 나오는 연구를 후원한 것입니다. DORA의 방법론이 이 업계에서 가장 성실한 축에 속한다는 것과, 이 이해 상충이 존재한다는 것은 둘 다 사실입니다. 둘 다 기억해야 합니다.

벤더 리서치 읽는 법 — Puppet 2026 편

비교 대상이 있으면 기준선이 잡힙니다. 2026년에 나온 Puppet(Perforce)의 State of DevOps Report: Platform Engineering Edition 2026을 보겠습니다. 헤드라인 숫자들은 이렇습니다.

플랫폼 엔지니어링이 성숙한 조직의 73%가 그 성숙도가 AI 성공을 이끈다고 답했고, 덜 성숙한 조직에서는 44%였다.
조직의 66%가 인프라 워크플로에 AI를 적용하고 있지만, 완전 자율 운영을 보고한 곳은 31%뿐이며, 표준화된 내부 개발자 플랫폼 환경에서는 44%로 올라간다.
플랫폼 성숙 조직의 79%가 성숙한 거버넌스를 보고했고, 미성숙 조직에서는 14%였다.
성숙한 조직의 81%가 AI를 신뢰한다고 답했고, 미성숙 조직은 48%였다. 표준화된 IDP 환경에서는 92%, 공식 거버넌스가 있는 조직에서는 94%까지 오르며, 임기응변식 거버넌스에서는 51%였다.

숫자 자체는 정확합니다. 제가 페이지 원문에서 확인했습니다. 문제는 이 숫자들이 무엇을 말할 수 있느냐입니다.

먼저 표본. 방법론 페이지를 열어 보면 이렇게 적혀 있습니다 — "이 연구는 820명의 글로벌 IT 의사결정권자(itdms), 구매 영향자, DevOps 실무자를 대상으로 한 20분짜리 온라인 설문으로 수행되었다."

구매 영향자가 표본에 명시적으로 포함돼 있습니다. 인프라 자동화 제품을 파는 회사가, 구매 결정에 영향을 주는 사람들에게, 플랫폼 성숙도가 좋은 것인지 물었습니다. 이게 곧 숫자가 틀렸다는 뜻은 아닙니다. 다만 이 표본은 "개발자들이 플랫폼을 어떻게 경험하는가"보다 "구매 담당자들이 무엇을 믿는가"에 훨씬 가깝습니다.

그리고 같은 페이지의 "Limitations" 절 전체가 이 한 문장입니다 — "결과는 자기보고된 관행과 인식을 반영한다."

한 문장입니다. DORA가 인과 언어에 대해 각주를 달고 겔만을 인용하며 표현 강도를 낮추는 동안, 여기서는 820명 설문의 한계가 한 줄로 처리됩니다. 이게 벤더 리서치를 읽을 때의 실용적 신호입니다 — 한계 절의 길이가 그 연구를 얼마나 믿을지에 대한 꽤 좋은 근사치입니다.

내용 쪽에서도 조심할 게 있습니다. "플랫폼 성숙 조직의 79%가 성숙한 거버넌스를 보고했고 미성숙 조직은 14%"라는 문장에서, 성숙도와 거버넌스를 누가 판정했을까요. 같은 응답자입니다. 그리고 성숙도 모델이 거버넌스를 성숙도의 구성 요소로 포함한다면, 이 상관은 발견이 아니라 정의에 가까워집니다. 저는 Puppet의 성숙도 모델 정의를 끝까지 확인하지 못했으므로 그렇다고 단정하지 않겠습니다. 다만 이런 형태의 "성숙한 조직은 X도 잘한다" 문장을 만나면 항상 물어야 합니다 — X가 성숙도 정의 안에 이미 들어 있지는 않은가?

"73%가 성숙도가 AI 성공을 이끈다고 답했다"도 마찬가지입니다. 이건 AI 성공에 대한 측정이 아니라, 사람들의 믿음에 대한 측정입니다. 두 개는 다른 것입니다.

이 데이터로 할 수 있는 말과 할 수 없는 말

정리해 보겠습니다.

할 수 있는 말:

플랫폼이라 부를 만한 공유 역량은 이제 거의 모든 조직에 있다(넓은 정의 기준 90%). 전담 플랫폼 팀도 76%로 지배적 모델이다.
플랫폼을 쓴다고 답한 사람은 자신의 생산성과 팀 성과를 더 높게 평가하는 경향이 있다(2024년 기준 8%, 10%).
동시에, 플랫폼을 쓴다고 답한 사람은 처리량과 변경 안정성을 더 낮게 보고했다(8%, 14%). 이 패턴은 2025년에도 방향이 유지됐다.
자기 플랫폼을 고품질로 평가한 사람은 AI 도입과 조직 성과의 연관을 더 강하게 보고했다.
개발자 독립성은 반복해서 등장하는 신호다. 인에이블링 팀 없이 일을 끝낼 수 있을 때 생산성이 5% 높았다.

할 수 없는 말:

"플랫폼을 도입하면 처리량이 8% 떨어진다." 화살표 방향이 확정되지 않았습니다. DORA 자신이 역인과 가설을 명시적으로 열어 뒀습니다.
"고품질 플랫폼이 조직 성과를 높인다." DORA가 2025년에 정확히 이 표현을 피하기로 했습니다. 이건 비교이지 효과가 아닙니다.
"플랫폼 성숙도가 AI 성공을 만든다." 이건 성숙하다고 자평한 사람들이 그렇게 믿는다는 보고입니다.
"우리 회사도 8% 오를 것이다." 확률 표본이 아니고, 당신 회사는 표본에 없습니다.

한 가지 더 덧붙이면, 이 모든 숫자는 리커트 척도의 표준화된 차이를 백분율로 옮긴 것이지 스톱워치로 잰 게 아닙니다. "처리량 8% 감소"는 배포 횟수를 세어 8% 적었다는 뜻이 아니라, 처리량 관련 문항들의 응답이 그만큼 낮았다는 뜻입니다.

그래서 월요일에 무엇을 할 것인가

이 글은 "플랫폼 엔지니어링을 하지 마라"가 아닙니다. 도입률이 90%인 상황에서 그건 실없는 조언입니다. 다만 이 연구들을 제대로 읽으면 실무적으로 쓸 만한 게 몇 개 나옵니다.

자기 데이터를 측정하십시오. 이게 첫 번째이자 가장 중요한 항목입니다. DORA 표본에 당신 회사는 없습니다. 그리고 설문의 "처리량"과 당신 CI 로그의 배포 횟수는 다른 것입니다. 다행히 후자는 직접 셀 수 있습니다. 플랫폼 온보딩 전후로 팀별 배포 빈도와 변경 실패율을 실제로 측정하면, 남의 리커트 척도보다 훨씬 나은 근거가 생깁니다.

배타성을 강제하지 마십시오. 데이터에서 가장 행동 가능한 항목입니다. 플랫폼만 쓰도록 요구받은 응답자들이 처리량 6% 감소를 보고했습니다. 골든 패스는 가장 쉬운 길이어야지 유일한 길이어야 하는 게 아닙니다. 플랫폼을 우회할 수 있게 두되, 우회가 필요한 순간이 바로 로드맵의 입력입니다.

핸드오프를 세어 보십시오. DORA의 첫 번째 가설이 처리량 하락을 핸드오프 증가로 설명합니다. 이건 검증 가능합니다. 커밋에서 프로덕션까지 시스템과 팀 경계를 몇 번 넘는지, 각 경계에서 대기 시간이 얼마인지 실제로 그려 보세요. 대기 시간이 실행 시간을 압도한다면 그게 당신의 8%입니다.

개발자 독립성을 지표로 삼으십시오. 반복해서 나오는 신호입니다. "인에이블링 팀 없이 이 작업을 끝낼 수 있는가"는 설문 없이도 물어볼 수 있고, 티켓 시스템에서 대신 셀 수도 있습니다 — 플랫폼 팀에 들어온 "이것 좀 해 주세요" 티켓의 비율이 곧 독립성의 역수입니다. 2024년 리포트가 피드백 수집 자체를 성공 요인으로, 미수집을 부정적 요인으로 꼽은 것도 같은 맥락입니다. 이 이야기는 Backstage 카탈로그를 IDP의 기반으로 세우기 편에서 도구 관점으로 따로 다뤘습니다.

불안정성이 늘었다면 어느 쪽인지 구분하십시오. DORA는 두 해석을 모두 열어 뒀습니다 — 실험이 늘어서 사소한 실패가 는 것인지(건강한 리스크 보상), 아니면 나쁜 변경이 그냥 통과하는 것인지(테스트를 방치한 결과). 이건 당신 조직에서 확인 가능합니다. 실패한 변경의 복구 시간과 사용자 영향을 보면 됩니다. 빨리 복구되고 사용자가 못 느꼈다면 전자에 가깝고, 롤백이 길고 고객이 티켓을 열었다면 후자입니다.

2년 차 하락에 놀라지 마십시오. J커브는 예측된 패턴입니다. 다만 J커브를 모든 부진의 변명으로 쓰는 것도 곤란합니다 — 회복이 언제쯤 보여야 하는지 미리 적어 두고, 그 시점에 정직하게 확인하십시오.

마치며

이 글에서 하고 싶은 말은 하나입니다. 우리 업계에서 가장 자주 인용되는 플랫폼 엔지니어링 근거는 설문입니다. 자기보고된 인식을, 확률 표본이 아닌 집단에서, 한 시점에 모은 것입니다. 그리고 그 설문을 만든 사람들이 그 사실을 우리보다 훨씬 잘 알고 있어서, 2025년에는 아예 "효과"라는 단어를 쓰지 않기로 했습니다.

그런데 그 리포트가 컨퍼런스 슬라이드와 내부 제안서로 옮겨질 때는 언제나 인과문이 됩니다. "DORA에 따르면 플랫폼이 조직 성과를 6% 높입니다." 원문에는 그렇게 안 적혀 있습니다.

동시에 반대 방향의 과잉 교정도 경계해야 합니다. "설문이니까 무의미하다"는 것도 틀렸습니다. 5,000명의 실무자가 일관되게 같은 방향을 보고하는 것은 그 자체로 정보입니다. 플랫폼과 불안정성의 연관이 2024년과 2025년에 걸쳐 재현됐다는 것도 정보입니다. 단지 그 정보가 "무엇이 무엇을 일으켰는가"를 말해 주지 않을 뿐입니다.

가장 정직한 태도는 DORA 자신의 태도를 그대로 빌리는 것 같습니다 — 우리는 비교를 하고 있고, 인과 구조는 모르며, 가설은 여러 개이고, 그중 하나는 화살표가 반대일 수 있다. 그 위에서 우리가 할 일은, 남의 설문 숫자를 인용하는 대신 자기 조직에서 셀 수 있는 것을 세는 것입니다.