보이지 않는 것들을 꺼내는 기술: 코드 의존성과 글꼴 사용권을 함께 점검하는 이유

시작: 우리가 눈감는 것들이 문제를 만든다

당신은 마지막으로 프로젝트 폴더에서 깊숙한 곳을 들여다본 적이 있는가. 보통 우리는 개발 도구가 자동으로 설치한 파일이나 디자이너가 골라 둔 글꼴을 그냥 받아들인다. 한편에서는 수천 개의 작은 패키지가 쌓인 폴더가 느리게 증식하고, 다른 한편에서는 화면에 표시되는 글자의 모양과 쓰임새가 라이선스 한 줄로 결정된다. 이 둘 사이에 어떤 공통점이 있는지 상상해 본 적이 있는가.

표면적으로는 관련 없어 보인다. 하나는 코드의 거대한 트리 구조이고, 다른 하나는 미세한 활자 디자인이다. 그러나 둘 다 보이지 않는 것이라는 공통점을 갖고 있다: 유지 비용, 법적 조건, 성능 영향, 그리고 사용자 경험을 좌우하면서도 일상적 관리 대상에서 빠져나가 버리는 것들이다. 이 글은 그 보이지 않는 것들을 어떻게 꺼내고, 이해하고, 책임 있게 관리할지에 대한 실용적인 사유를 제안한다.

긴장: 왜 우리가 이렇게 무심한가

여러 프로젝트에서 공통으로 보이는 문제가 있다. 개발자는 기능을 만들고, 디자이너는 화면을 다듬는다. 그러나 둘 다 자주 한 가지를 놓친다: 외부 자산의 출처와 조건을 주기적으로 점검하는 루틴이 없다는 점이다. 그 결과는 다음과 같다.

• 코드 의존성 폴더는 중복과 불필요한 코드로 팽창한다. 이는 빌드 성능 저하, 보안 취약성, 디버깅의 어려움을 초래한다. 그 뿌리는 우리가 의존성의 실체를 제대로 확인하지 않기 때문이다.
• 글꼴은 화면 경험에 결정적인 영향을 주지만, 라이선스 조건은 서비스 제공 방식에서 큰 제약이 될 수 있다. 예를 들어 개인용 무료 글꼴이 상업적 서비스에 사용될 때 발생하는 법적 위험을 자주 간과한다.

이 둘을 연결하는 핵심 긴장은 다음이다: 우리는 시스템의 외형은 관리하지만 그 근거인 자산의 출처와 조건을 투명하게 만들지 않는다. 투명성 부족은 비용으로 전환된다. 비용은 느리게, 혹은 갑자기 발생한다.

재구성: 보이지 않는 것들을 다루는 통합적 프레임워크

여기서 제안하는 중심 아이디어는 간단하다: 모든 외부 자산을 하나의 생태계로 보라. 코드 패키지, 글꼴 파일, 이미지, 폰트 라이선스 텍스트는 모두 같은 원칙으로 다룰 수 있다. 이를 위해 네 단계의 프레임워크를 제안한다. 각 단계는 실용적이고 즉시 적용 가능하다.

1. 탐색(Inspect): 보이는 결과물만이 전부가 아니다. 먼저 무엇이 설치되어 있고 무엇이 포함되어 있는지 찾아야 한다. 도구를 사용해서 대상을 목록화하고 이상 징후를 포착하라.

예시: 의존성 폴더를 수동으로 열어보는 대신 특정 도구를 사용해 진단할 수 있다. 그런 도구는 중복 패키지, 용량을 차지하는 파일, 로컬에만 남아 있는 개발 전용 패키지 등을 찾아준다. 한 프로젝트에서 발견되는 300메가짜리 node_modules는 불필요한 서브패키지가 대량 포함된 결과인 경우가 많다. 같은 맥락에서 웹 프로젝트의 글꼴 폴더를 점검하면 임베디드되지 않은 오프라인용 폰트, 라이선스 파일 누락, 혹은 용량이 큰 TTF 파일이 포함되어 있는지 알 수 있다.

2. 출처 확인(Attribute): 어떤 것이 어디에서 왔는지, 어떤 권리가 부여되어 있는지 명확히 하라. 단순한 메모 한 줄이 큰 비용을 막는다.

예시: 글꼴 파일에는 보통 라이선스 텍스트가 함께 있어야 한다. 파일 이름 옆에 "개인용 무료"라는 문구가 있을 때 그 사용 범위를 확인하지 않으면 상업적 프로젝트에서 문제가 될 수 있다. 코드 패키지도 마찬가지다. 특정 패키지가 어떤 라이선스를 따르는지, 최근에 유지보수가 이루어졌는지, 알려진 취약성이 있는지 메모해 두면 배포 시 리스크를 줄일 수 있다.

3. 간소화(Prune): 모든 것이 필요하지는 않다. 중복을 제거하고, 용도에 맞는 최소한의 자산만 남겨라. 단순함은 유지보수성과 성능으로 돌아온다.

예시: 웹 글꼴은 보통 전체 글자집을 모두 필요로 하지 않는다. 라틴 알파벳만 쓰는 서비스에서 한글 완전 집합을 포함한 글꼴을 넣어 둔 경우 용량 낭비이다. 마찬가지로, node_modules 폴더 안의 특정 패키지는 사실 메이저 버전 변경 이후 사용되지 않게 될 수도 있다. 주기적으로 애셋을 정리하고 서브셋팅을 적용하면 초기 로드 시간과 빌드 시간이 줄어든다.

4. 적용과 문서화(Apply and Document): 변경을 배포할 때는 출처, 용도, 점검 날짜와 책임자 정보를 함께 기록하라. 자동화 도구와 체크리스트를 CI 파이프라인에 통합하면 실수가 줄어든다.

예시: 새로운 글꼴을 프로젝트에 추가할 때는 폰트 파일, 라이선스 파일, 사용 범위에 대한 간단한 문서를 저장소에 포함하라. 의존성 변화가 있을 때는 자동 검사 도구가 실패하도록 해 배포 전에 수동 확인을 요구할 수 있다.

이 네 단계는 서로 순환한다. 탐색에서 출발해 문서화로 돌아와 지속적으로 개선되는 사이클을 만든다. 기술과 디자인 자산 모두에 같은 규칙을 적용하면 팀 간 소통 비용도 줄어든다.

구체적 도구와 실전 팁: 바로 적용 가능한 행동 지침

이제 실무에서 바로 쓸 수 있는 구체적 방법들이다. 핵심은 도구와 규칙을 결합하는 것이다.

• 정기 진단을 자동화하라: 의존성 폴더를 검사하는 도구를 주기적으로 실행하라. 이 도구는 중복 패키지, 과도한 용량, 오래된 패키지를 리포트할 수 있어야 한다. 출력 결과는 사람이 해석하기 쉬운 형태로 저장하라.

• 글꼴은 자산으로 분류하라: 모든 글꼴 파일에 대해 다음 항목을 문서로 남겨라: 출처, 라이선스 문구 전문, 사용 범위(예 개인용, 웹 사용, 임베디드), 설치 날짜, 책임자. 이 문서는 코드 저장소의 근간 폴더에 위치시키라.

• 서브셋과 포맷 최적화: 웹용 글꼴은 서브셋을 만들어 사용하라. 필요한 글리프만 포함하면 파일 크기를 크게 줄일 수 있다. 또한 WOFF2 같은 현대 포맷을 우선적으로 제공하라. 코드 의존성은 필요 없는 빌드 타임 의존성을 제거해 빌드 산출물을 경량화하라.

• 라이선스 체크를 CI에 포함하라: 배포 전에 자동으로 글꼴 사용 권한과 패키지 라이선스를 검사하는 스크립트를 돌려라. 라이선스가 비허용적이거나 불명확할 경우 파이프라인이 실패하도록 설정하면 배포 실수를 미연에 방지할 수 있다.

• 작은 실험을 통해 신뢰를 쌓아라: 새로운 폰트를 도입할 때는 먼저 작은 기능 토글로 실험하라. 사용자 반응과 성능을 비교한 뒤 점진적으로 확장하라. 의존성 업데이트도 마찬가지다. 한 번에 모든 패키지를 올리는 대신 핵심 패키지부터 순차적으로 검증하라.

간단한 체크리스트 예시

코드를 커밋하거나 글꼴을 추가하기 전에 다음 항목을 확인하라:

• 이 자산의 출처는 어디인가요. 출처를 문서로 남겼나요.
• 라이선스는 어떤 범위를 허용하나요. 상업적 사용이 가능한가요.
• 파일 크기와 성능 영향은 어느 정도인가요. 서브셋이 가능한가요.
• 유지보수 책임자는 누구인가요. 정기 점검 주기가 정해져 있나요.

이러한 작은 습관은 프로젝트의 장기적 비용을 크게 낮춘다.

결론: 투명성은 안정성과 창의성의 기반이다

보이지 않는 자산을 드러내고 관리하는 일은 단순한 정리 행위가 아니다. 그것은 시스템에 대한 책임을 명확히 하고, 창의적 선택의 자유를 보장하는 전제 조건이다.

의존성 폴더와 글꼴 파일은 처음에는 기술적이거나 미적 선택으로 보일 수 있다. 그러나 시간이 지나면 둘 다 조직의 운영 리스크와 사용자 경험을 결정하는 핵심 자산이 된다. 작은 의식의 전환으로 우리는 문제를 사전에 포착하고, 불필요한 비용을 줄이며, 더 나은 디자인과 성능 결정을 내릴 수 있다.

이제 질문은 간단하다: 당신의 다음 배포 전, 무엇을 들여다볼 것인가. 한 번의 클린업으로 끝나지 않을 것이다. 그러나 작은 루틴 하나를 추가하는 것만으로도 프로젝트의 미래를 바꿀 수 있다.

핵심 요약: 바로 적용할 수 있는 행동들

• 정기적으로 의존성 폴더를 검사하라. 자동 도구를 사용해 중복과 불필요한 패키지를 찾아 삭제하라.
• 모든 글꼴 파일에 출처와 라이선스 정보를 문서화하라. 개인용 무료 라벨이 상업적 사용 허가를 의미하지는 않는다.
• 글꼴과 패키지 모두에 대해 서브셋과 최적화 전략을 적용하라. 파일 크기를 줄이면 성능과 비용이 개선된다.
• 배포 파이프라인에 라이선스 및 안전성 검사를 넣어 의도치 않은 사용을 차단하라.
• 작은 실험과 점진적 적용을 통해 신뢰를 쌓고 급격한 변화를 피하라.

마지막으로 기억하라: 시스템의 보이지 않는 층을 꺼내어 볼 때 우리는 단지 문제를 찾는 것이 아니다. 우리는 선택의 근거를 확보하고, 더 창의적이며 책임 있는 결정을 내릴 수 있는 기반을 만드는 것이다.