어? 이 버그 지난 달에도 나왔는데?

어? 이 버그 지난 달에도 나왔는데?

또 이 버그

아침 9시. 슬랙 알림이 울렸다.

“결제 페이지에서 금액이 안 넘어와요.”

손이 멈췄다. 이 문장, 어디서 봤다.

지난달 장애 리포트를 뒤졌다. 있었다. 똑같은 증상. 똑같은 모듈.

팀원에게 물었다. “이거 지난번에 고쳤잖아.”

“네, 근데 또 났어요.”

커피를 마셨다. 벌써 두 번째다.

포스트모템은 뭐하러 쓴 건지

지난달 장애 포스트모템을 열었다.

3페이지짜리 문서. 원인 분석, 근본 원인, 재발 방지책까지 다 있다.

재발 방지책 3가지:

  1. API 파라미터 검증 로직 강화
  2. 결제 모듈 통합 테스트 케이스 추가
  3. 배포 전 해당 시나리오 필수 체크

1번은 했다. 2번은 반만 했다. 3번은 안 했다.

개발 리드에게 물었다. “체크리스트 왜 안 따른 거예요?”

“일정이 빡빡해서요. 근데 이건 다른 이슈 아닐까요?”

로그를 봤다. 같은 이슈였다.

일정이 빡빡하면 품질은 뒤로 가는 게 이 조직의 공식이다.

재발 방지책이 지켜지지 않는 이유

점심 먹고 팀원들이랑 얘기했다.

“또 똑같은 거 났어.”

“아… 그거요? 저번에 포스트모템 썼는데.”

“응. 근데 아무도 안 지킴.”

이유는 간단하다.

첫째, 바빠서. 일정 지키는 게 최우선이니까.

둘째, 책임이 없어서. 재발 방지책 안 지켜도 징계 없음.

셋째, 추적이 안 돼서. 누가 체크해야 하는지 모호함.

넷째, 문화가 없어서. “이번만”이 모든 걸 정당화함.

팀원이 물었다. “팀장님, 이거 어떻게 해요?”

“모르겠어. 나도.”

솔직히 모르겠다. 13년 했는데 답이 없다.

경영진한테 보고

오후 3시. CTO 리포트 미팅.

“같은 이슈가 재발했습니다.”

“어떻게 된 거죠?”

“재발 방지책이 제대로 이행되지 않았습니다.”

“왜요?”

“일정 압박이 있었고, 체크리스트가 강제가 아니었습니다.”

침묵이 흘렀다. 5초쯤.

“그럼 이번엔 어떻게 할 건가요?”

또 물어본다. 어떻게 할 거냐고.

“배포 전 필수 체크리스트를 강제화하겠습니다. 승인 프로세스를 추가하고, QA 팀장 사인 없으면 배포 못 하게 하겠습니다.”

“그럼 일정은요?”

“지켜야죠. 품질이랑 일정 둘 다.”

불가능한 걸 약속했다.

CTO는 고개를 끄덕였다. “기대하겠습니다.”

미팅이 끝났다. 나왔다. 화장실 갔다.

거울을 봤다. 피곤한 얼굴.

“재발 방지책 강제화.” 말은 쉽다. 현실은 어렵다.

강제화가 답일까

퇴근 전에 테스트 전략 회의를 잡았다.

“이제부터 배포 전 체크리스트 필수입니다. QA 팀장 승인 없으면 배포 안 됩니다.”

개발 리드가 물었다. “그럼 시간 더 걸리는데요?”

“당연하죠. 품질 체크하려면.”

“일정은 어떻게 하고요?”

“그건 PM이랑 조율해야죠.”

PM이 끼어들었다. “우리 일정 못 미루는 거 아시잖아요.”

알지. 다 안다.

일정은 못 미루고, 품질은 지켜야 하고, 리소스는 그대로.

이게 내가 13년간 들은 말의 요약이다.

“그럼 어떻게 해야 하는데요?” 개발 리드가 물었다.

“자동화를 늘려야죠. 수동 테스트 줄이고, 회귀 테스트 자동화하고.”

“예산은요?”

“신청했어요. 작년부터.”

승인 안 났다. 올해도 아마 안 날 거다.

시스템의 문제

퇴근길 지하철에서 생각했다.

재발 방지책이 안 지켜지는 건 개인의 문제가 아니다.

시스템의 문제다.

개발자가 게을러서? 아니다. 다들 밤늦게까지 일한다.

PM이 무책임해서? 아니다. 일정 압박받는 건 그쪽도 마찬가지.

QA가 제대로 안 해서? 우리는 했다. 다 했다.

문제는 구조다.

일정이 최우선이고, 품질은 부차적이고, 재발 방지는 선택 사항인 구조.

장애 터지면 난리 나지만, 터지기 전엔 아무도 신경 안 쓰는 구조.

포스트모템은 쓰지만 아무도 안 읽는 구조.

“다음엔 조심하자”가 재발 방지책이 되는 구조.

이 구조를 바꾸려면 뭐가 필요한가.

경영진의 의지? CTO는 관심 없다. 숫자만 본다.

프로세스 강화? 이미 충분히 강하다. 안 지켜서 문제지.

문화 개선? 13년 해봤는데 문화는 안 바뀐다.

그래도 해야 하는 일

다음 날 아침. 출근했다.

재발 방지책 강제화 문서를 작성했다.

  • 배포 전 필수 체크리스트 30개 항목
  • 각 항목별 담당자 지정
  • QA 팀장 최종 승인 프로세스
  • 미이행 시 배포 중단 권한

개발팀에 공유했다. 항의가 들어왔다.

“이거 다 하려면 시간이 2배로 걸리는데요.”

“그럼 자동화하세요. 제가 도와드릴게요.”

“자동화 구축할 시간도 없는데요.”

“그럼 계속 똑같은 장애 터지겠네요.”

말을 멈췄다. 더 할 말이 없었다.

PM한테 따로 메시지를 보냈다.

“이번 스프린트에 자동화 구축 일정 넣어주세요. 3주면 회귀 테스트 80% 커버 가능합니다.”

“다음 스프린트에 넣을게요.”

“이번 스프린트요.”

“기능 개발이 우선이잖아요.”

“품질도 기능입니다.”

읽씹당했다.

팀원들과의 대화

점심시간에 팀원들이랑 밥 먹었다.

막내가 물었다. “팀장님, 재발 방지책 강제화하면 진짜 달라질까요?”

“모르겠어. 근데 안 하는 것보단 낫지.”

“저는… 회의적이에요.”

“나도.”

다들 웃었다. 쓴웃음.

10년차 팀원이 말했다. “저도 예전 회사에서 비슷한 거 해봤어요. 처음엔 다들 따르다가 한 달 지나면 형식적으로 바뀌더라고요.”

“알아. 근데 그래도 해야지.”

“왜요?”

“안 하면 뭐라도 바뀌냐?”

대답이 없었다.

우리는 알고 있다. 이 방법도 완벽하지 않다는 걸.

하지만 안 하는 것보단 낫다.

매번 같은 장애 보고 가만히 있는 것보단.

“어? 이 버그 지난 달에도 나왔는데?”라고 말하고 아무것도 안 하는 것보단.

조직 문화라는 벽

퇴근 전에 CTO한테 메일을 보냈다.

제목: 재발 장애 근본 원인 및 개선 방안

내용은 3페이지.

  • 최근 6개월간 재발 장애 통계: 전체 장애의 37%
  • 재발 원인: 재발 방지책 미이행 82%
  • 미이행 원인: 일정 압박 65%, 프로세스 부재 23%, 리소스 부족 12%
  • 개선 방안: 배포 프로세스 강화, 자동화 투자, 품질 메트릭스 KPI 반영

마지막 문장:

“품질은 선택이 아닌 필수입니다. 재발 방지책 이행을 조직 KPI에 포함시켜주시기 바랍니다.”

보내고 나니 허무했다.

이런 메일, 매 분기마다 보낸다. 13년 동안.

답장은 늘 비슷하다.

“중요한 의견 감사합니다. 검토하겠습니다.”

검토만 하고 끝이다.

왜 안 바뀔까.

품질보다 속도가 중요해서? 맞다.

장애 터져도 큰일 안 나니까? 맞다.

QA가 알아서 막아주니까? 맞다.

조직 문화는 바뀌지 않는다. 위에서 바꾸지 않으면.

그래도 기록은 남긴다

밤 10시. 집에 왔다.

노트북을 켰다. 개인 기록을 작성했다.

“2024년 X월 X일. 결제 모듈 재발 장애. 지난달과 동일. 재발 방지책 미이행.”

이런 기록이 쌓인 지 3년.

왜 쓰냐고? 모른다.

누가 볼 것도 아닌데. 나조차 다시 안 읽는데.

그래도 쓴다.

언젠가 누군가 물어볼 때 보여주려고.

“왜 품질이 안 좋아졌나요?”

그때 이 기록을 보여줄 거다.

“재발 방지책을 안 지켰습니다. 계속. 반복적으로.”

증거는 남겨야 한다.

안 그러면 나중에 QA 탓이 된다.

“QA가 제대로 테스트 안 해서 장애 났다.”

아니다. 우리는 했다. 다 했다.

기록이 증명한다.

13년 차의 회의감

솔직히 말하면 회의적이다.

재발 방지책 강제화해도 달라질까? 모르겠다.

프로세스 만들어도 안 지키면 끝이다.

자동화 구축해도 예산 안 나오면 끝이다.

조직 문화 바꾸자고 해도 위에서 관심 없으면 끝이다.

QA 13년 했다. 나아진 것도 있다.

툴은 좋아졌다. Jira, TestRail, CI/CD.

방법론도 발전했다. 애자일, DevOps, 시프트 레프트.

하지만 본질은 안 바뀌었다.

“일정이 급해서”, “이번만”, “다음엔 제대로 하자”.

이 말들은 13년 전이나 지금이나 똑같다.

그래도 해야 한다. 이게 내 일이니까.

팀원들이 보고 있으니까.

“팀장님도 포기하면 우리는 뭐 하나요?”

포기하면 안 된다. 아직은.

내일도

내일 아침 9시에 긴급 회의가 잡혔다.

안건: 재발 장애 대응 방안 논의.

또 같은 얘기 할 거다.

“원인이 뭡니까?” “왜 또 났습니까?” “어떻게 할 겁니까?”

나는 같은 대답을 할 거다.

“재발 방지책이 지켜지지 않았습니다.”

“이번엔 강제화하겠습니다.”

“프로세스를 개선하겠습니다.”

그리고 한 달 뒤, 또 같은 장애가 날 거다.

또 같은 회의를 하겠지.

이게 내 일이다. QA 팀장.

재발 장애를 막는 사람이 아니라, 재발 장애를 기록하는 사람.

변화를 만드는 사람이 아니라, 변화를 요청하는 사람.

씁쓸하다.

하지만 내일도 출근한다.

커피 마시고, 슬랙 확인하고, 또 싸울 거다.

“어? 이 버그 지난 달에도 나왔는데?”

이 말을 더 이상 안 하는 날이 올까.

모르겠다. 13년 했는데도.



재발 장애는 품질 문제가 아니라 조직 문화 문제다. 근데 문화는 안 바뀐다.