"이 검사 건너뛰기" 버튼이 결국 팀을 망쳐요 — 게이트는 막지 말고 유연하게

CI/CD를 운영하다 보면 '게이트(gate)'라는 걸 만나요. 코드를 합치기 전에 통과해야 하는 관문이죠. 테스트가 전부 통과해야 한다, 코드 커버리지가 80% 이상이어야 한다, 린트(lint) 검사에 걸리면 안 된다, 리뷰 승인을 한 명 이상 받아야 한다... 이런 규칙들이에요. 그런데 이 게이트를 운영하다 보면 꼭 마주치는 고민이 있어요. "급할 땐 좀 건너뛰게 해줘야 하지 않나?"라는 거예요. 이번에 소개할 주장은 명확해요. 게이트를 '선택 사항(optional)'으로 만들지 말고, '유연하게(flexible)' 만들라는 거죠.

선택 사항으로 만들면 결국 무너져요

게이트를 optional로 만든다는 건, 보통 "체크박스 하나 끄면 통과"처럼 아무 대가 없이 건너뛸 수 있게 하는 거예요. 처음엔 "정말 급한 핫픽스 때만 쓰자"고 약속해요. 그런데 사람 심리가 그렇잖아요. 한 번 건너뛰어도 별일 안 생기면, 다음엔 좀 덜 급해도 건너뛰고, 그다음엔 그냥 귀찮아서 건너뛰어요. 마감이 코앞이면 누구나 제일 만만한 게이트부터 끄거든요. 결국 그 게이트는 "있으나 마나 한 장식"이 되고, 품질을 지키려고 만든 장치가 오히려 "원래 안 지켜도 되는 것"이라는 신호를 팀에 보내게 돼요.

유연하게 만든다는 건 뭐냐면요

'flexible'은 게이트의 '목적'은 지키되, 그 목적을 만족시키는 '방법'을 여러 개 열어주는 거예요. 예를 들어 '테스트 커버리지 80%' 게이트가 있다고 해봐요. optional 방식은 "오늘은 그냥 끄고 넘어가자"예요. flexible 방식은 이래요. 첫째, 테스트를 더 써서 80%를 맞추거나. 둘째, 정말 테스트하기 어려운 코드라면 "이 부분은 왜 커버하지 않는지" 이유를 명시적으로 남기고(waiver), 그 기록이 코드 리뷰에 함께 올라오게 하는 거예요. 핵심 차이는 '마찰(friction)'과 '기록(audit trail)'이에요. 그냥 끄는 건 흔적도 책임도 안 남지만, 예외를 신청하는 건 약간의 수고가 들고 누가 왜 면제했는지가 남거든요.

이 작은 차이가 문화를 바꿔요. 예외를 쓰는 게 '공짜'가 아니라 '의식적인 결정'이 되니까, 사람들이 진짜 필요할 때만 쓰게 돼요. 나중에 "이 모듈은 왜 테스트가 없지?" 싶을 때 기록을 따라가면 당시 판단의 맥락도 보이고요. 게이트가 무너지지 않으면서도 현실의 급한 상황을 받아줄 수 있는 거죠.

업계 흐름에서 보면

이건 'paved road(포장도로)'나 'guardrail(가드레일)'이라고 부르는 요즘 플랫폼 엔지니어링 사고방식과 맞닿아 있어요. 무조건 막는 단단한 벽(hard gate)도 아니고, 아무나 넘는 뻥 뚫린 길도 아닌, "기본은 안전한 길로 유도하되 벗어나려면 의식적으로 핸들을 꺾어야 하는" 설계죠. 깃허브의 필수 리뷰 우회 기록, 변경 사유를 강제하는 배포 승인 플로우 같은 것들이 같은 철학이에요. 규칙을 사람의 '의지'에만 맡기지 않고, 시스템이 '기록과 약간의 마찰'로 받쳐준다는 게 공통점이에요.

한국 개발자에게

사내 CI 파이프라인이나 코드 리뷰 규칙을 손볼 일이 있다면, "이 게이트, 끌 수 있게 할까 말까?"라는 이분법에서 한 발 벗어나 보세요. "끄는 대신, 이유를 남기고 통과하게 하면 어떨까?"라고 질문을 바꾸는 거예요. 슬랙으로 "이번만 머지 좀요"라고 부탁하던 걸, 사유를 적는 라벨이나 코멘트로 바꾸기만 해도 팀의 책임 문화가 달라져요. 규칙을 더 엄하게가 아니라 더 똑똑하게 만드는 방향이라 생각하면 돼요.

여러분 팀의 CI에는 '그냥 끄고 넘어가는' 게이트가 있나요? 그게 정말 필요한 예외였는지, 아니면 어느새 기본값이 돼버렸는지 한번 돌아보면 어떨까요?