며칠 전 기술 그룹에서 불평 게시글을 하나 봤습니다. 글쓴이는 프로젝트 출시 전에 도구로 CSS를 압축했는데, 다음 날 동료가 스타일 파일을 열어 보니 화면 가득 한 줄로 뭉쳐진 문자들뿐이었고, 그 자리에서 폭발했다고 합니다. "누가 쓴 거야? 사람이 볼 수 있는 건가?" 글쓴이는 억울하게도 압축은 빌드 프로세스의 일부라서 어쩔 수 없었다고 합니다.
이 일은 사실 꽤 전형적이라 거의 모든 프런트엔드 팀에서 싸워 본 적이 있을 겁니다. 오늘은 이 문제를 제대로 따져 봅시다. CSS 압축 후 동료가 이해 못 하면, 이 책임은 도대체 누가 져야 할까요?
먼저 CSS 압축이 무엇인지 설명하겠습니다. 쉽게 말해, 코드의 공백, 줄바꿈, 주석을 모두 제거하고 변수명을 최대한 짧게 만들어 파일 크기를 줄이고 웹페이지 로딩을 빠르게 하는 것입니다. 이것 자체는 문제가 없습니다. 온라인 환경에서는 성능을 추구하므로 압축은 기본 작업입니다. 하지만 문제는 많은 사람들이 압축된 파일을 코드 저장소에 직접 커밋하고, 심지어 원본 파일을 덮어쓰기도 한다는 점입니다. 동료가 코드를 pull 하면 "a{b:c;d:e}" 같은 천재지변만 보게 되니, 당황하지 않을 수 있겠습니까?
그럼 이 책임을 누구에게 돌려야 할까요? 어떤 사람은 압축 도구의 잘못이라며 너무 "폭력적"이라고 합니다. 하지만 도구는 무죄입니다. 그것은 명령을 실행하는 프로그램일 뿐이며, 압축하라고 하면 죽어라 압축할 수밖에 없습니다. 칼로 채소를 썰다가 손을 베었다고 칼이 너무 날카롭다고 탓할 수는 없지 않습니까?
어떤 사람은 동료의 잘못이라며, 프런트엔드 엔지니어가 압축된 코드를 이해하지 못하는 것은 기본기가 부족한 것이라고 합니다. 이 말은 배부른 소리입니다. 압축된 코드는 원래 브라우저를 위한 것이지 사람을 위한 것이 아닙니다. 소설을 모스 부호로 번역해서 친구에게 보냈는데 친구가 이해하지 못한다고, 친구의 국어 실력이 부족하다고 탓할 수 있습니까? 정상적인 사람의 독서 습관은 들여쓰기, 주석, 줄바꿈이 있는 코드를 보는 것이며, 압축된 코드는 완전히 반인간적입니다. 동료에게 압축된 코드를 억지로 읽으라고 요구하는 것은 능력 향상이 아니라 고문입니다.
제 생각에는 진짜 책임은 프로세스와 규범에 있어야 합니다. 쉽게 말해, 팀이 "무엇을 커밋해야 하고 무엇을 커밋하지 말아야 하는지"에 대한 합의가 없는 것입니다. 올바른 방법은 소스 코드(즉, 사람이 읽도록 작성된 CSS)를 저장소에 그대로 두고, 압축은 빌드 단계에서 자동으로 수행되며, 압축된 파일은 dist 디렉터리에 출력하거나 출시 산출물에 직접 패키징하여 버전 관리에 커밋할 필요가 없도록 하는 것입니다. 하지만 많은 팀이 편의를 위해, 또는 처음에 제대로 생각하지 않고 압축 파일도 함께 커밋하여 문제가 발생합니다.
어떤 사람은 회사에서 압축 파일을 커밋하도록 요구한다면 어떻게 하냐고 말할 수 있습니다. 예를 들어 일부 정적 호스팅 플랫폼이나 백엔드가 저장소의 파일을 직접 참조하는 경우입니다. 이런 상황은 실제로 존재하지만 해결책이 없는 것은 아닙니다. 압축을 별도의 빌드 단계로 만들어 코드를 수정한 후 바로 압축해서 커밋하는 대신 출시 전에 실행할 수 있습니다. 또는 pre-commit 훅 같은 도구를 사용하여 커밋 전에 자동으로 처리하여 저장소에 항상 읽을 수 있는 압축되지 않은 버전이 있도록 보장할 수 있습니다. 방법은 어려움보다 많으며, 핵심은 팀에서 누군가 이 규범을 세우는 것입니다.
또 하나 쉽게 간과되는 점은 코드 주석입니다. 많은 CSS 압축 도구는 기본적으로 주석도 삭제하므로, 압축 파일에 단서를 남기고 싶어도 남길 수 없습니다. 따라서 중요하고 후임자가 이해해야 할 로직은 반드시 소스 파일에 작성해야 하며, 압축 후에도 볼 수 있을 것이라고 기대하지 마십시오. 이것이 소스 파일을 보존하는 것이 중요한 이유입니다. 그것은 팀 협업의 "진짜 본체"이기 때문입니다.
결국 CSS 압축 자체는 나쁜 일이 아닙니다. 나쁜 것은 이에 맞는 관리 습관이 없다는 것입니다. 동료가 이해하지 못하는 것은 그가 못해서도, 도구가 어리석어서도 아니라 워크플로에 한 단계가 빠져 있기 때문입니다. 이 일은 요리와 같습니다. 칼은 좋은 칼이지만, 음식을 으깨서 상에 내놓으면 손님이 보기 안 좋다고 하는데, 칼을 탓할 수 있습니까?
그러니 더 이상 이 일로 싸우지 마십시오. 다음에 이런 일이 생기면 솔직하게 프로세스가 정해지지 않았다고 인정하고, 바로 규범을 보완하십시오. 소스 파일은 저장소에, 압축은 빌드에 맡기고, 아무도 압축 산출물을 직접 커밋하지 마십시오. 이미 이렇게 했다면, 이런 책임을 질 일이 없지 않습니까? 쉽게 말해, 기술 문제 뒤에는 종종 관리 문제가 있습니다. 그렇지 않습니까?