늘 빨간불인 검사는 검사가 아닙니다

「코드를 올리면 자동으로 검사가 돌고, 태그를 붙이면 앱이 자동으로 빌드·배포됩니다.」
외부에서 만든 제품을 이어받으며 받은 문서는 그렇게 적혀 있었습니다.

9월 9일, 그 문서를 믿지 않고 하나씩 실측했습니다.
자동 검사는 최근 8회 전부 실패였고, 앱 자동 릴리스는 4월 이후 멈춰 있었습니다.

이 글은 그날의 실측을 원문으로 옮기고, 대표가 가져갈 세 칸을 정리한 기록입니다.
제품명·서버·저장소 이름은 싣지 않습니다.

먼저 검사부터 봤습니다.
코드 변경이 올라올 때마다 문법·단위·통합·빌드·보안 검사가 돌게 되어 있었습니다.

네 가지 검사가 동시에 빨강이면 누구도 원인을 보지 않습니다.
빨간불이 기본값이 된 순간, 검사는 신호가 아니라 장식이 됩니다.

다음은 앱 릴리스였습니다.
버전 태그를 붙이면 맥·윈도 앱을 빌드해 배포하는 자동화가 있었습니다.

마지막 성공은 3월 30일이었습니다.
그 뒤 두 번 실패한 채 다섯 달이 지났고, 사용자가 받는 최신 앱은 누군가의 노트북에서 서명 없이 손으로 빌드한 것이었습니다.

서버 배포 문서도 열어 봤습니다.
문서가 가리키는 클라우드 주소는 이미 사라져 404 였고, 실제 배포는 다른 서버에 사람이 접속해 손으로 올리는 방식이었습니다.

문서에 「자동」이라고 적혀 있는 것과 자동화가 살아 있는 것은 다른 일입니다.

같은 날 저희는 밀린 작업 서른두 건을 일괄 착수했습니다.
저녁까지 코드 약 스무 건이 주 브랜치에 합쳐졌습니다.

그런데 라이브에 올라간 것은 0건이었습니다.
합치는 것과 올리는 것 사이에 열쇠가 하나 있었고, 그 열쇠는 한 사람에게만 있었습니다.

서버 접속권은 운영자 한 사람의 IP 에만 열려 있었습니다.
데스크톱 앱은 자동화 결제가 막혀 있었고, 모바일 앱은 스토어 키가 새로 필요했습니다.

주 브랜치에는 이걸 막아 줄 규칙도 없었습니다.
리뷰 필수 0, 검사 필수 0.

규칙이 0 이니 합치는 속도는 빨랐고, 열쇠가 하나이니 올리는 속도는 0 이었습니다.
만든 것이 쌓이기만 하는 구조입니다.

합치는 권한은 열려 있고 올리는 열쇠는 한 사람에게만 있으면, 만든 것은 쌓이기만 합니다.

검사가 없으면 대표는 「검사가 없다」는 사실을 압니다.
검사가 늘 빨강이면 대표는 「검사가 있다」고 믿고, 팀은 빨강을 무시하는 법을 배웁니다.

그 상태에서 진짜 고장이 나면 같은 색으로 옵니다.
8회 연속 실패 안에 새 고장이 섞여 있었는지, 아무도 구분할 수 없었습니다.

대표가 물을 질문은 하나입니다.
「이 검사가 마지막으로 초록이었던 날이 언제입니까.」

한 달 넘게 빨강이면 그 주에 둘 중 하나를 정합니다.
고치거나, 끕니다. 끄는 것도 결정이고, 방치는 결정이 아닙니다.

빨간불이 정상이 되면 진짜 고장도 같은 색으로 옵니다.

이번 제품은 문서만 보면 자동화가 세 겹이었습니다.
검사 자동화, 앱 릴리스 자동화, 서버 배포 자동화.

실측하니 세 겹 모두 살아 있지 않았습니다.
검사는 8회 연속 실패, 릴리스는 4월 20일이 마지막 시도, 서버 배포 문서는 사라진 주소를 가리켰습니다.

GitHub 문서도 같은 전제를 둡니다.
필수 검사는 성공 상태여야 보호된 브랜치에 변경을 넣을 수 있다는 규칙인데, 이 제품은 그 규칙 자체가 0 이었습니다.

그래서 자동화의 존재는 문서가 아니라 세 줄로 판정합니다.
마지막 성공 일자, 누가 돌렸나, 문서의 주소가 지금 살아 있나.

셋 중 하나라도 비면 그 자동화는 없는 것으로 칩니다.
「있는데 잠깐 고장」 대신 「없음」으로 적어야 다음 결정이 나옵니다.

자동화의 존재 여부는 마지막으로 성공한 날짜 한 줄로 판정합니다.

AI 에이전트가 하루에 스무 건을 만들어도, 올리는 열쇠가 한 사람에게 있으면 결과는 같습니다.
이번 제품에서는 서버 접속권·앱 서명키·스토어 키 세 가지가 전부 그랬습니다.

다른 제품에서 같은 표를 먼저 만들어 본 적이 있습니다.
어느 열쇠가 우리 것이고, 어느 열쇠가 외부 소유라 당길 수 없는지를 한 장에 적었습니다.

표의 열은 넷이면 됩니다.
열쇠 이름, 어느 계정, 어느 IP 또는 어느 기기, 두 번째로 쓸 수 있는 사람.

마지막 열이 비어 있는 행이 곧 병목입니다.
두 번째 사람이 없으면 자동화에라도 같은 길을 열어 둡니다. 그래야 만든 것이 그날 나갑니다.

열쇠가 한 사람에게만 있으면 AI 든 사람이든 만든 것은 쌓이기만 합니다.

정리

경고 신호

• 자동 검사가 몇 주째 빨강인데 「원래 그래」로 넘기고 마지막 초록 날짜를 아무도 모른다

• 문서에 「태그 붙이면 자동 배포」라고 적혀 있지만 마지막 성공 기록이 몇 달 전이다

• 배포 문서가 가리키는 주소가 이미 사라졌고 실제 배포는 한 사람이 손으로 한다

• 주 브랜치에 리뷰 필수·검사 필수가 0 이고 서버 접속권이 한 사람의 IP 에만 열려 있다

좋은 신호

• 검사마다 「마지막으로 초록이었던 날」을 알고, 한 달 넘게 빨강이면 그 주에 고치거나 끈다

• 자동화 하나마다 마지막 성공 일자·돌린 사람·문서 주소 생존 세 줄이 적혀 있다

• 열쇠 이름·계정·IP·두 번째 사람 네 열짜리 표가 있고 마지막 열이 빈 행이 없다

• 합쳐진 코드가 그날 라이브에 오르고, 오르지 못한 이유가 표의 어느 행인지 바로 짚인다

이어받은 제품에서 이 다섯 가지만 물어보세요

1. 자동 검사가 마지막으로 초록이었던 날이 언제입니까?
   한 달 넘게 빨강이면 검사는 없는 것입니다. 이번 제품은 최근 8회 전부 실패였고, 그 주에 고치거나 끄거나 둘 중 하나를 정해야 했습니다.

2. 자동 배포가 마지막으로 성공한 날짜와 돌린 사람은 누구입니까?
   문서가 아니라 기록으로 답해야 합니다. 이번 제품의 앱 릴리스는 3월 30일이 마지막 성공, 4월 20일이 마지막 시도였습니다.

3. 배포 문서가 가리키는 주소가 지금 살아 있습니까?
   이번 제품의 서버 배포 문서는 사라진 클라우드 주소를 가리켰고 실제 배포는 다른 서버에 손으로 올리는 방식이었습니다.

4. 주 브랜치에 리뷰 필수와 검사 필수가 몇 개 걸려 있습니까?
   이번 제품은 둘 다 0 이었습니다. 규칙이 0 이면 합치는 속도만 빠르고, 올리는 쪽 병목은 그대로 남습니다.

5. 서버 접속권·서명키·스토어 키가 각각 누구 계정, 어느 IP 에 묶여 있습니까?
   네 열짜리 표에서 두 번째 사람이 빈 행이 병목입니다. 이번 제품은 세 열쇠 전부 한 사람에게 있어 하루 약 20건 머지에 라이브 0건이었습니다.

자주 묻는 질문

Q. CI 가 계속 실패하는데 그냥 두면 무슨 문제가 생깁니까?

빨간불이 기본값이 되면 진짜 고장도 같은 색으로 와서 아무도 구분하지 못합니다. 저희가 이어받은 제품 한 곳은 최근 8회 전부 실패였고, 그 안에 새 고장이 섞여 있었는지 확인할 방법이 없었습니다. 없는 검사보다 나쁜 상태입니다.

Q. 자동 배포가 있는지는 어떻게 확인합니까?

문서 대신 마지막 성공 일자·돌린 사람·문서 주소 생존 세 줄을 봅니다. 셋 중 하나라도 비면 그 자동화는 없는 것으로 적습니다. 이번 제품의 앱 릴리스는 3월 30일이 마지막 성공이었고 문서 주소는 404 였습니다.

Q. 검사를 고칠 시간이 없으면 어떻게 합니까?

끕니다. 끄는 것도 결정이고, 늘 빨강인 채 두는 것만 결정이 아닙니다. 한 달 넘게 빨강이면 그 주에 고치거나 끄거나 둘 중 하나를 정하고, 다시 켤 때는 초록인 날짜부터 새로 셉니다.

Q. 코드가 많이 합쳐졌는데 왜 라이브에 안 올라갑니까?

합치는 것과 올리는 것 사이에 열쇠가 있고, 그 열쇠가 한 사람에게만 있기 때문입니다. 이번 제품은 서버 접속권이 운영자 한 사람의 IP 에만 열려 있어 하루 약 20건이 합쳐지고 라이브 배포는 0건이었습니다. 배포 번들은 사람이 올 때까지 대기였습니다.

Q. 열쇠 표에는 무엇을 적습니까?

열은 넷입니다. 열쇠 이름, 어느 계정, 어느 IP 또는 어느 기기, 두 번째로 쓸 수 있는 사람. 서버 접속권·앱 서명키·스토어 키·클라우드 프로젝트·키스토어 원본을 행으로 두고, 마지막 열이 빈 행부터 두 번째 사람이나 자동화에 같은 길을 엽니다.