exit 0인데 실제로는 실패한 자동화, 어디를 봐야 하나

수천 개의 테스트가 전부 초록색이었습니다.

빨간 줄 하나 없이 깔끔하게 통과.
그래서 앱을 켰는데, 화면을 보는 순간 뭔가 이상했어요.

다크모드였는데 글자가 잘 안 보였습니다.
정확히는, 배경색에 글자가 거의 묻혀 있었어요.

divider도, 아이콘도, 테마 색도 다 제대로 바뀌었는데 — 텍스트 색상만 테마를 안 따라갔어요.

그리고 테스트는, 이걸 하나도 안 잡아 줬습니다.

명령은 성공했다는데 정작 원한 효과는 안 일어난 상황.
저는 이걸 "조용한 실패"라고 불러요.
그날 이후로 제일 무서워하는 종류고요.

빨간 실패보다 초록색 실패가 무섭습니다

빨간 에러는 차라리 친절해요.
멈췄다는 걸 알려주니까요.
로그도 남고, 어디서 깨졌는지도 보이고, 다시 돌릴지 말지 판단할 수 있습니다.

초록색 실패는 그 자리에서 안 잡힙니다.
명령은 성공하고, CI도 초록이고, 스크립트도 exit 0으로 끝나는데 화면은 깨져 있거든요.

exit 0은 사실 "원하는 게 됐다"가 아니라, "프로그램이 불평 없이 끝났다"에 가깝습니다.

그날도 텍스트 색만 그런 게 아니었어요.
빈 목록일 때 뜨는 화면이 페이지마다 제각각이었고, 한국어가 줄바꿈되는 자리도 어딘가 어색하게 끊겨 있었습니다.
전부 테스트는 통과한 것들이었고요.

보통 내가 아니라, 남이 먼저 발견합니다

조용한 실패의 진짜 문제는 늦게 발견된다는 거예요.
그것도 보통 개발자가 아니라 엉뚱한 사람이요.

사용자가 버튼을 눌렀는데 반응이 없거나, 운영자가 받은 CSV의 컬럼이 비어 있거나, 고객센터로 "메일이 안 왔다"는 문의가 들어오는 식으로요.

그때쯤이면 자동화 로그는 한참 전에 지나갔고, 누가 무엇을 믿고 넘어갔는지를 거슬러 올라가 찾아야 합니다.

그래서 질문을 바꿨습니다

자동화 결과를 볼 때, 저는 질문을 바꿨어요.
"명령이 성공했나?"가 아니라 "원한 효과가 확인됐나?"로요.

파일을 만드는 자동화면 파일이 생겼는지가 아니라 그 안에 내용이 들어갔는지를 봅니다.
API 배포면 health check가 아니라 새 endpoint가 기대한 응답을 주는지를 보고요.
화면 작업이면 테스트 통과가 아니라, 실제로 그 화면을 켜서 눈으로 봅니다.
그날 글자가 묻혔던 것처럼요.

다행히 효과 확인이 거창할 필요는 없었어요.
작은 assert 하나, 캡처 한 장이면 충분할 때가 많거든요.

작업	무엇을 확인하나
파일 생성	파일 크기 + 핵심 문자열
HTML 생성	링크 하나가 실제로 열리는지
API 변경	대표 요청 하나의 응답
migration 실행	새 컬럼 readback
화면 작업	다크모드·빈 상태에서 실제 캡처

중요한 건 확인이 사용자가 실제로 보는 결과에 가까워지는 거예요.
내부 함수가 호출됐는지보다, 사용자 화면에 글자가 보이는지가 중요하니까요.

AI한테 맡길수록, 더 시끄럽게 실패해야 합니다

AI 에이전트는 빈칸을 잘 채웁니다.
파일이 없으면 비슷한 걸 찾고, 값이 없으면 기본값을 만들고, 검증을 못 했으면 "확인이 필요합니다"보다 "확인했습니다"에 가까운 문장을 내놓을 때가 있어요.

이 선의가 자동화에서는 위험합니다.
필수값이 없으면 조용히 넘어가는 대신, 차라리 시끄럽게 깨지는 편이 나으니까요.

그래서 요즘은

이제 저는 자동화가 exit 0으로 끝나는 자리 바로 다음에, 작은 확인 한 개를 꼭 붙여 둡니다.

솔직히 이걸로 조용한 실패를 다 잡는다고는 못 해요.
확인을 안 붙여 둔 자리에서 또 새는 날이 있겠죠.
그래도 그날 다크모드에서 배경에 묻혀 있던 그 글자만큼은, 다음번엔 화면을 한 번 더 켜서 잡으려고요.

이 글은 'AI 코딩 에이전트를 믿는 법' 시리즈의 한 편이에요.
위임·검증·하네스·비용 6편을 한 번에 보려면 여기로요.

https://datacook.tistory.com/156

AI 코딩 에이전트를 믿는 법 — 위임·검증·하네스·비용 6편 정리