Suppressions of Suppressions — overreacted

보통 빌드 실패를 생각할 때, 우리는 주로 문법 오류나 “모듈을 찾을 수 없습니다”와 같은 오류들을 떠올립니다. 사용하는 파일을 체크인하지 않는 실수는 하지 말아야겠죠. 나중에 충돌이 발생하는 것보다 지금 빌드 오류가 나는 것이 낫습니다.

또한 기술적으로는 “빌드가 완료되었다”고 하더라도 더 넓은 범위에서 빌드를 실패로 처리하고 싶은 경우가 있습니다. 예를 들어, 린팅(linting)이 실패하면 그 빌드를 배포하고 싶지 않을 것입니다. 심지어 메인 브랜치에 이미 병합되었더라도 말입니다! 만약 린트 규칙이 잘못된 경우라면 언제든지 억제(suppress)할 수 있습니다. 따라서 잘못된 코드를 배포하는 것보다는 CI가 실패하는 것이 낫습니다. 규칙이 틀렸다고 확신한다면 억제 처리를 하고, 그 처리를 다른 사람이 리뷰하도록 합니다.

사실 억제는 유용한 기능입니다. 때로는 규칙 자체가 잘못되었거나 지나치게 엄격할 수도 있고, 혹은 규칙이 추ㅏㄱ되기 전에 작성된 오래된 코드를 옮길 때 이미 존재하는 규칙 위반이 있을 수도 있습니다. 다시 말해, 처음부터 규칙을 위반하지 않은 적이 없는 코드일 수도 있는 것입니다.

하지만 사람들이 린트 규칙 억제에 익숙해지면 새로운 문제가 생길 수 있습니다. 어떤 규칙은 절대로 억제해서는 안 되는 중요한 경우일 수 있기 때문입니다! 규칙을 무시하는 것이 올바른 선택이라 생각할지라도, 이는 사이트를 마비시키거나 성능을 크게 저하시킬 수 있는 위험이 있습니다. 실제로 저 역시 안전하다고 생각하고 규칙을 억제했다가 문제를 일으킨 경험이 있습니다.

그렇다면 이런 문제를 어떻게 해결할 수 있을까요? 모든 규칙 억제를 완전히 금지할 수는 없습니다. 억제는 점진적으로 규칙을 도입하거나 폐기할 때, 또는 실제로 잘못된 경고(false positive)나 특별한 예외 상황을 처리할 때 유용하기 때문입니다.

이러한 상황에서 사용할 수 있는 한 가지 방법이 있습니다.

바로 특정 규칙의 억제를 막기 위한 또 다른 린트 규칙을 도입하는 것입니다. 이 새 규칙은 설정된 특정 규칙들을 억제하려는 시도를 탐지하고 경고를 발생시킵니다. 예를 들어, 디렉터리 계층 구조를 관리하는 팀이 특정 규칙은 억제해서는 안 된다고 판단한 경우, 해당 규칙을 억제하려 할 때 이 새 규칙이 위반으로 표시되는 것입니다.

즉, 특정 규칙들의 억제를 금지하는 린트 규칙인 것입니다.

농담처럼 들릴 수도 있지만, 실제로 페이스북에서는 유사한 린트 규칙이 존재했고 아주 유용했습니다. 오픈소스 커뮤니티에서도 eslint-plugin-eslint-comments/norestricted-disable 이라는 규칙이 비슷한 목적을 가지고 있습니다.