게시일: 2025년 11월 7일
일본 전역의 38,000개가 넘는 엔터프라이즈 고객의 브라우저 호환성을 관리하는 것은 간단한 일이 아닙니다. Kintone이 매일 150만 개가 넘는 애플리케이션의 중요한 비즈니스 운영을 지원하므로 모든 브라우저 지원 결정이 중요합니다.
일본의 선도적인 그룹웨어 회사인 Cybozu는 맞춤 브라우저 지원 매트릭스의 유지보수 부담을 피하면서 제품 전반에서 일관된 웹 표준을 유지하는 방법을 모색해야 했습니다.
해결 방법이 무엇일까요? Baseline을 개발 표준으로 채택하여 웹 플랫폼 기능 채택에 대한 접근 방식을 혁신했습니다.
문제: 추측을 통한 브라우저 지원
Baseline 이전에는 Cybozu가 액세스 로그와 수동 버전 추적을 기반으로 자체 브라우저 지원 기준을 유지했습니다. 표준은 액세스 로그의 상위 98% 를 차지하는 브라우저를 지원하는 것이었고, 이 기준을 벗어나는 브라우저를 사용하는 사용자에게는 브라우저 업데이트 메시지가 표시되었습니다.
매 분기마다 Cybozu의 엔지니어링팀은 기준 업데이트에 총 1시간 정도를 할애했습니다. 하지만 개발팀에 기준을 통합하는 과정이 원활하지 않았고, 새 CSS 기능을 언제 사용할 수 있는지에 관한 질문이 상당히 많았습니다. 새 JavaScript API의 폴리필은 언제 삭제될 수 있나요? 지금 사용할 수 있는 기능은 무엇인가요?
Cybozu의 맞춤 기준은 개발자의 유지관리성과 유용성이 부족했을 뿐만 아니라 사용자 에이전트 감지 및 수동 버전 추적을 기반으로 구축하는 것이 최신 웹의 진화 속도를 따라갈 수 없다는 사실도 깨달았습니다.
User-Agent 문자열을 신뢰할 수 있나요?
Cybozu의 이전 접근 방식에서는 User-Agent 문자열에서 브라우저 이름과 버전을 파생시킨 다음 이러한 결과를 '사용자' 데이터로 집계했습니다. 하지만 이것이 사용자의 실제 상황을 제대로 반영할까요?
User-Agent는 HTTP 요청 헤더로, 모든 클라이언트가 무엇이든 될 수 있다고 주장할 수 있는 정보입니다. 제품 액세스 로그에는 봇, 크롤러, 공격자 및 기타 소스의 요청이 대량으로 포함되어 있습니다. 일부 클라이언트는 취약점 검사와 같은 다양한 목적으로 의도적으로 오래된 User-Agent 문자열을 전송합니다. 따라서 액세스 로그는 지원해야 하는 사용자를 나타낼 수 없습니다.
사용자 에이전트가 사용 가능한 기능을 반영할 수 없음
브라우저 버전은 기능에 매핑되지 않습니다. 예를 들어 채널 (안정화/베타/개발자/Canary), 기능 플래그, Finch 실험, 엔터프라이즈 정책에 따라 동일한 버전 번호가 다른 기능을 가질 수 있습니다. 또한 브라우저마다 기능 구현 시기가 다릅니다. CSS Nesting은 Safari 16.5 (2023년 5월)에서 출시되었지만 Chrome 112 (2023년 4월)에서는 출시되지 않았습니다. User-Agent 문자열은 기능 사용 가능 여부를 나타내지 않습니다.
브라우저 버전을 직접 지원해야 함
브라우저 업데이트는 새로운 기능에 관한 것만이 아닙니다. 정기적인 브라우저 출시에는 새로운 기능과 함께 중요한 보안 패치와 버그 수정이 포함됩니다. 오래된 버전이 지원되면 새 기능 사용을 피하는 것만이 문제가 아닙니다. 이는 동시에 사용자 안전에 직접적인 영향을 미치는 결정입니다. 엔터프라이즈 환경에서는 일부 사용자에게 합법적인 제약이 적용될 수 있습니다. 예를 들면 다음과 같습니다.
- 조직에 업데이트를 방지하는 엄격한 브라우저 정책이 있을 수 있습니다.
- 기존 하드웨어는 최신 브라우저 업데이트를 지원하지 않습니다.
- 변경 승인 프로세스가 느린 규제 대상 업계의 사용자
하지만 이러한 사용자를 지원하면 취약한 상태를 유지할 수 있습니다.
오래된 브라우저 버전의 알려진 취약점을 악용하여 보안 사고가 발생한 경우 '사용자가 요청했기 때문에 이 브라우저가 지원되었습니다'라고 말하는 것은 합당한 설명이 아닙니다. 공격이 업데이트된 브라우저를 적절하게 유지하는 다른 사용자에게 확산되는 경우, 안전하지 않은 브라우저에 대한 지원을 중단하지 못한 책임은 개발자와 기타 프로젝트 이해관계자에게 있습니다.
Cybozu는 이 접근 방식이 브라우저를 최신 상태로 유지하는 대부분의 사용자에게 위험을 초래한다는 것을 깨달았습니다. 로그 수만을 기반으로 브라우저를 지원하는 것은 적절한 보안 검증이 부족합니다. 새 기능을 놓치는 것뿐만 아니라 사용자를 보호해야 하는 책임도 다하지 못하게 됩니다.
질문이 '이 버전을 사용하는 사용자는 몇 명인가?'에서 '브라우저 버전을 기반으로 사용자를 지원해야 하는가?'로 바뀝니다.
Cybozu에 Baseline이 적합한 이유
Cybozu는 브라우저 지원 기준 유지의 운영 오버헤드뿐만 아니라 이전 방법론의 근본적인 결함을 해결하는 새로운 접근 방식이 필요했습니다. 기준은 Cybozu에 정확히 이러한 기능을 제공했습니다.
외부에서 유지관리되는 진화하는 기준
매 분기마다 브라우저 버전을 수동으로 재평가하는 대신 Baseline은 임의로 결정을 내리는 개별 회사가 아닌 W3C WebDX 커뮤니티 그룹에서 유지관리하는 변동 목표를 제공합니다. 즉, 기준은 브라우저 공급업체와 표준 기관의 의견을 반영하여 자동으로 발전합니다.
Kintone에서 더 이상 버전 기준을 직접 관리할 필요가 없습니다. 기준이 별도의 조치 없이 발전합니다. 기능의 기준 상태는 가용성 질문에 명확하게 답변하며, 플랫폼이 발전함에 따라 답변이 자동으로 업데이트됩니다.
기능 수준 정밀도
개별 브라우저의 상황을 추적하는 대신 Baseline은 근본적으로 다른 접근 방식을 취합니다.
Baseline Widely available은 주요 브라우저에서 30개월 이상 사용할 수 있는 웹 기능을 나타냅니다. 이 기간은 '개발자 신호, 시간 경과에 따른 브라우저 출시 채택, 높은 총 시장 점유율 지원 추정치, WebDX 커뮤니티 그룹의 최적 판단'을 근거로 결정되었습니다. 이 기준점을 설정하면 Baseline에서 관찰할 수 없는 개별 브라우저 상황을 추적하는 작업이 필요하지 않습니다.
Baseline을 사용하면 개발자가 브라우저 전반에서 특정 기능의 사용 가능 여부에 관한 직접적인 답변을 얻을 수 있습니다. 이제 'CSS 컨테이너 쿼리를 사용할 수 있나요?'라는 질문에 답변할 수 있습니다. 개발자는 호환성 매트릭스를 상호 참조하지 않고도 MDN이나 기타 문서에서 기준 상태를 즉시 확인할 수 있습니다.
보안을 고려한 설계
Cybozu는 널리 제공되는 기준을 표준으로 채택하여 지원 정책을 브라우저 공급업체의 지원 수명 주기와 자연스럽게 연관되는 기간에 맞췄습니다. 여전히 활발하게 유지관리되는 브라우저는 널리 제공되는 모든 기능을 지원하는 동시에 중요한 보안 업데이트를 받습니다.
액세스 로그 기반 기준은 지원을 오래된 브라우저에 고정할 수 있어 사용자가 업데이트할 인센티브가 사라집니다. Baseline을 채택하면 최신 기능을 자신 있게 사용할 수 있을 뿐만 아니라 웹 플랫폼이 발전함에 따라 오래된 브라우저를 사용하는 사용자도 자연스럽게 업데이트해야 할 필요성을 느끼게 됩니다.
기준선은 취약한 브라우저를 명시적으로 제외하지 않으며, 사용자가 브라우저를 업데이트하도록 자연스러운 인센티브를 제공합니다.
기준 채택
Baseline을 채택하려면 Cybozu의 기존 버전 관리에서 전환해야 했습니다. 즉, Cybozu는 기준선이 심각한 단점 없이 작동할 것이라는 확신이 필요했습니다. 영향을 받는 사용자의 비율을 파악하는 것은 엔터프라이즈 수준의 도입에 매우 중요했습니다.
Google 애널리틱스 기준선 검사기는 Google 애널리틱스에서 내보낸 데이터를 분석하여 각 기준선 연도의 기능을 지원하는 사용자 비율을 보여주는 도구입니다. 이 도구를 통해 Cybozu는 기준선 타겟 선택이 사용자에게 미치는 실제 영향을 확인할 수 있었습니다. 기준선 검사기를 실행한 후 Cybozu는 다음과 같은 놀라운 사실을 발견했습니다.
기준 검사기를 통해 Cybozu 사용자의 98.8% 가 널리 사용 가능한 기준 타겟을 지원하는 브라우저를 사용하는 것으로 확인되었습니다. 이는 이전 Cybozu의 내부 표준인 사용자 98% 이상보다 더 넓은 범위입니다. 제공된 데이터를 기반으로 세 가지 주요 사항을 분석할 수 있습니다.
- 이전에 지원되던 브라우저는 영향을 받지 않습니다.
- 이전에 지원되지 않던 브라우저: 기준 널리 사용 가능 기준을 충족하지만 더 이상 브라우저 업데이트 프롬프트가 표시되지 않는 브라우저로, 약 0.8% 를 차지합니다.
- 나머지 브라우저는 이전과 같이 브라우저 업데이트 메시지를 계속 수신합니다.
특히 이로 인해 거짓양성을 없앨 수 있었습니다. 즉, 지원되는 브라우저를 사용함에도 불구하고 불필요하게 경고가 표시되었던 사용자의 비율이 약 0.8% 였습니다. 동시에 이전에 지원되었던 사용자에게 경고를 표시하여 거짓 음성을 도입할 수는 없습니다.
이 데이터를 통해 Cybozu는 Baseline Widely available을 타겟으로 자신 있게 채택할 수 있었습니다.
실제 기준의 영향
기준을 정책으로 채택하는 것은 한 가지 일이었지만, 이를 운영하려면 도구와 프로세스를 빌드해야 했습니다. 개발자가 기준 상태를 수동으로 확인하지 않고 지원되지 않는 기능을 실수로 사용하지 않도록 해야 했습니다.
ESLint 구성을 기반으로 한 정적 분석
@cybozu/eslint-config은 Cybozu 제품 전반에서 사용되는 OSS 기반 구성입니다. 빌드 시점에 CSS 기능을 Baseline과 비교하는 css-baseline 사전 설정부터 지원되었습니다.
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
개발자가 아직 Baseline에서 널리 제공되지 않는 기능을 사용하면 ESLint에서 즉시 피드백을 제공합니다.
이렇게 하면 호환성 문제가 프로덕션에 도달하지 않습니다. 개발자는 개발 프로세스 초기에 정보에 입각한 결정을 내릴 수 있습니다. 기능이 널리 제공될 때까지 기다리거나, 영향을 받는 사용자를 정확히 파악하여 점진적 개선을 구현할 수 있습니다. (ESLint의 CSS 및 기준 지원에 대해 자세히 알아보세요.)
널리 사용 가능한 기준을 타겟팅하도록 트랜스파일러 구성
최신 빌드 도구에서 기준을 타겟으로 지원하기 시작했습니다. 예를 들어 Vite는 추가 구성 없이 프로덕션에서 널리 사용되는 기준을 자동으로 타겟팅합니다. 이제 Browserslist에서 Baseline도 지원합니다.
다양한 컴파일러 설정을 사용하면 JavaScript와 CSS가 필요한 경우에만 트랜스파일되므로 이미 널리 지원되는 기능에 대한 불필요한 변환과 polyfill을 피할 수 있습니다.
사용자 의견에 대한 수동 기준 유지관리 및 브라우저 감지 시스템 삭제
가장 큰 유지보수 이점은 수동 브라우저 버전 추적을 없앤 것입니다. 이제 Cybozu는 지원할 브라우저 버전을 논의하기 위해 분기별 회의를 하는 대신 공개적으로 유지관리되는 @web-platform-dx/baseline-browser-mapping 패키지를 사용하여 이러한 질문에 답합니다.
또한 Cybozu는 오래된 브라우저를 사용하는 사용자에게 업그레이드 메시지를 표시하기 위해 자동 브라우저 감지 기능을 구축했습니다.
브라우저 감지 기능은 @web-platform-dx/baseline-browser-mapping 패키지에서 호환되는 브라우저 버전을 직접 가져옵니다.
이는 빌드 프로세스 중에 실행되며 모든 제품팀에서 공유되는 경고 배너를 생성합니다. 기준선 널리 사용 가능 창이 최신 브라우저를 포함하도록 이동하면 시스템에서 수동 개입 없이 변경사항을 자동으로 선택합니다.
커뮤니케이션 간소화
가장 중요하면서도 예상치 못한 이점 중 하나는 Baseline이 팀 간 커뮤니케이션을 간소화했다는 것입니다. 이전에는 브라우저 호환성 논의에 회사별 도메인 지식(지원되는 브라우저, 버전, 현재 사용 가능한 기능)이 필요했습니다. 신입 사원은 내부 표준을 배우는 데 시간이 필요했습니다. 이제 Baseline을 통해 웹 커뮤니티에서 널리 인정되는 동일한 호환성 기준을 참조합니다.
또한 엔지니어링팀과 더 넓은 웹 커뮤니티 내에서 공유 어휘가 생성됩니다. 기능 채택을 논의할 때 모두 동일한 소스의 동일한 데이터를 참조하므로 내부 정책을 설명하거나 서로 다른 호환성 프레임워크 간에 번역할 필요가 없습니다.
개발 도구도 따라잡았습니다. 이제 Visual Studio Code와 Chrome DevTools의 스타일 패널에 Baseline 호환성 정보가 직접 표시됩니다. 개발자는 더 이상 MDN이나 Can I use를 지속적으로 확인하여 기능을 안전하게 사용할 수 있는지 확인할 필요가 없습니다. 도구가 즉시 알려줍니다.
모두가 제품을 자신 있게 사용할 수 있도록 지원
Baseline을 사용하면 브라우저 호환성에 대한 생각을 관리해야 하는 부담에서 신뢰할 수 있는 기반으로 근본적으로 바꿀 수 있습니다. Google의 구현 전략은 모든 단계에서 자동화에 중점을 두었습니다.
- 개발 시간 피드백: 정적 분석 및 기준 상태 카드
- 빌드 시간 유효성 검사: 트랜스파일러가 널리 사용 가능한 기준을 자동으로 타겟팅합니다.
- 런타임 감지:
baseline-browser-mapping를 사용하는 지원되지 않는 브라우저에 대한 사용자 대상 경고 - 지속적인 업데이트: 기준 데이터와의 자동 동기화로 수동 유지관리 불필요
결과는 다음과 같습니다.
- 브라우저 버전 유지보수에 소요되는 시간이 0시간입니다.
- 기능 수준의 확실성으로 98.8% 이상의 사용자 커버리지가 유지됩니다.
- FAQ에 대한 즉각적이고 자발적인 답변: '이 브라우저 버전에서 이 기능을 사용할 수 있나요?'라는 질문에 답변합니다.
- 엔지니어링팀 간 공유 어휘
- 기능 도입을 위한 명확한 경로를 통해 필요한 경우 팀에서 새 기능 통합 및 폴리필 삭제 시기를 논의하도록 유도합니다.
기준 채택을 고려하는 조직의 경우 이러한 변화가 사용자에게 어떤 영향을 미치는지 아는 것이 중요합니다. Google 애널리틱스 기준선 검사기와 같은 도구를 사용하면 이 측정을 더 간단하고 명확하게 설명할 수 있습니다. 데이터를 신뢰하고 Baseline을 채택하기로 결정한 후에는 성장하는 Baseline 생태계를 사용하여 개발 워크플로를 구성할 수 있습니다.
웹 플랫폼은 과거보다 더 강력하고 일관적이며 안정적이고 빠르게 진화하고 있습니다. Baseline을 사용하면 프로덕션에서 이 기능을 자신 있게 활용할 수 있습니다.
리소스
- 일본어 원본: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- Cybozu ESLint 구성: GitHub의
@cybozu/eslint-config - Google 애널리틱스 기준선 검사기: Google 애널리틱스 기준선 검사기
- 기준 브라우저 매핑:
@web-platform-dx/baseline-browser-mapping - 기준에 대해 알아보기: MDN의 기준