HTTP/Guides/Browser detection using the UA string

김동현·2026년 3월 22일

mdn 학습 번역 - Web Technology

목록 보기

21/28

안녕하세요! 프론트엔드 개발을 하다 보면 "현재 접속한 사용자가 크롬인지, 사파리인지, 혹은 모바일인지 데스크톱인지" 알아내야 할 때가 반드시 생기죠. 이때 가장 먼저 떠올리는 것이 바로 오늘 배울 사용자 에이전트(User-Agent)입니다.

하지만 이 UA 문자열을 파싱해서 브라우저를 감지하는 방법은 사실 수많은 버그를 낳는 '위험한 유혹'이기도 합니다. 오늘은 왜 이 방법이 위험한지, 그리고 프론트엔드 실무에서는 이를 대체하기 위해 어떤 똑똑한 방법(기능 감지 등)을 사용하는지 원문 그대로 꼼꼼하게 번역해 드리며 설명해 드릴게요. 자, 시작해 봅시다!

사용자 에이전트 문자열을 이용한 브라우저 감지 (UA 스니핑)

브라우저는 서버로 요청을 보낼 때마다, 사용자 에이전트(user agent, UA) 문자열이라는 값을 담은 User-Agent HTTP 헤더를 포함합니다. 이 문자열은 브라우저의 종류, 버전 번호, 그리고 브라우저가 실행 중인 호스트 운영체제(OS)를 식별하기 위한 목적으로 사용됩니다.

User-Agent: <product> / <product-version> <comment>

JavaScript에서도 navigator.userAgent 속성을 통해 이 문자열에 접근할 수 있습니다:

console.log(window.navigator.userAgent);
// Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

💡 강사의 팁: 서버 사이드 렌더링(SSR) 환경을 구축할 때 이 navigator.userAgent를 무턱대고 컴포넌트 내부에서 호출하면 문제가 발생할 수 있습니다. 서버에는 window나 navigator 객체가 존재하지 않기 때문에 에러가 나거나, 서버와 클라이언트 간의 렌더링 결과가 달라져 Hydration(수분 공급) 불일치 에러를 겪기 쉽습니다. 따라서 브라우저 감지보다는 CSS 미디어 쿼리나 훅(Hook)을 이용한 지연 평가를 활용하는 것이 훨씬 안전한 패턴입니다!

이 UA 문자열을 파싱(이를 때때로 "UA 스니핑(UA sniffing)"이라고 부릅니다)하여 문자열에 포함된 값에 따라 웹사이트의 동작을 다르게 바꾸고 싶은 유혹이 들 수 있습니다. 하지만 이를 안정적으로 해내는 것은 매우 어려우며, 흔히 버그의 원인이 되곤 합니다.

이 문서는 브라우저 감지를 위해 UA 문자열을 사용할 때 빠지기 쉬운 일반적인 함정들과 권장되는 대안들을 설명합니다. 문서의 끝부분에는 문자열을 이용한 UA 감지 힌트를 제공하긴 하지만, 이는 절대적으로 필요한 경우에만 사용해야 합니다!

이 문서의 내용 (In this article)

왜 브라우저 감지보다 기능 감지가 더 나을까 (Why feature detection is better than browser detection)
UA 스니핑의 대안 (Alternatives to UA sniffing)
브라우저 감지를 사용하는 잘못된 이유들 (Invalid reasons to use browser detection)
관련된 UA 문자열 부분 추출하기 (Extracting relevant UA string parts)
같이 보기 (See also)

왜 브라우저 감지보다 기능 감지가 더 나을까 (Why feature detection is better than browser detection)

각 브라우저에 맞춰 사이트 기능을 조정하려는 시도가 왜 복잡성을 더하고 잠재적인 버그를 유발하는지, 다음 예시를 통해 살펴보겠습니다.
어떤 애플리케이션이 JavaScript에서 후방 탐색(lookbehind assertion) (?<=…)을 사용하는 splitUpString() 함수를 활용하려고 합니다:

let splitUpString;

if (navigator.userAgent.includes("Chrome")) {
  const camelCaseExpression = new RegExp("(?<=[A-Z])");
  splitUpString = (str) => String(str).split(camelCaseExpression);
} else {
  // 이 폴백(대체) 방식은 비효율적이지만 작동은 합니다.
  splitUpString = (str) =>
    String(str)
      .split(/(.*?[A-Z])/)
      .filter(Boolean);
}
console.log(splitUpString("fooBar")); // ["fooB", "ar"]
console.log(splitUpString("jQWhy")); // ["jQ", "W", "hy"]

이 코드는 몇 가지 잘못된 가정을 하고 있으며, 이로 인해 잘못된 브라우저나 브라우저 버전에서 코드가 실행될 경우 애플리케이션이 망가질 수 있습니다:

부분 문자열 Chrome을 포함하는 모든 사용자 에이전트 문자열이 Chrome 브라우저를 나타낸다고 가정합니다.
UA 문자열을 기반으로 한 브라우저 감지에서 가장 큰 문제 중 하나는, 브라우저와 사용자 에이전트들이 일상적으로 다른 브라우저인 척 위장(spoofing)하거나 여러 브라우저의 정보를 혼합해서 포함한다는 점입니다.
브라우저가 Chrome이라면 후방 탐색(lookbehind) 기능이 항상 사용 가능하다고 가정합니다.
실제로는 해당 기능이 추가되기 이전의 구버전 Chrome일 수도 있고, 반대로 향후에 해당 기능이 제거된 더 최신의 Chrome 버전일 수도 있습니다.
가장 결정적으로, 다른 어떤 브라우저도 이 기능을 지원하지 않는다고 가정해 버립니다.
이 기능은 언제든지 다른 브라우저에 추가될 수 있습니다. 이 경우, 조건에 일치하지 않는(Chrome이 아닌) 모든 브라우저들은 꼼짝없이 비효율적인 대체(fallback) 코드만 사용해야 합니다.

중요한 점은 브라우저를 감지하는 방법(UA 스니핑이든, 클라이언트 힌트이든, 다른 HTTP 헤더의 존재 여부나 내용이든 간에)이 무엇이든 상관없이 이러한 문제들은 항상 존재한다는 것입니다.
어떤 브라우저가 사용되는지 아는 것은 중요하지 않습니다. 이 경우 우리가 실제로 찾고 있는 것은 기능 감지(feature detection)이며, 이에 대해서는 아래에서 더 자세히 설명하겠습니다.

UA 스니핑의 대안 (Alternatives to UA sniffing)

다음 섹션들은 브라우저 감지를 대체할 수 있으면서도, UA 스니핑보다 훨씬 더 견고하고 훨씬 더 다양한 시나리오에 적용할 수 있는 대안들을 설명합니다.

기능 감지 (Feature detection)

기능 감지란 페이지를 렌더링하고 있는 브라우저가 무엇인지 알아내는 대신, 특정 기능(feature)을 클라이언트가 사용할 수 있는지 직접 확인하는 방식입니다.
해당 기능이 지원되지 않는 경우에는 대체재(fallback)를 사용하면 됩니다.
다음 기능 감지 예시는 클라이언트가 Geolocation API를 지원하는지 확인합니다.
전역 Navigator 객체에 geolocation 속성이 존재하는지 확인함으로써 이를 알아낼 수 있습니다.

if ("geolocation" in navigator) {
  navigator.geolocation.getCurrentPosition((position) => {
    // Google Maps API 등에서 지도로 위치를 보여줍니다.
  });
} else {
  // 대신 정적인(static) 지도를 보여줍니다.
}

이 방법은 여러 가지 기능에 폭넓게 사용할 수 있습니다.
예를 들어, PDF 파일을 브라우저 안에서 인라인(inline)으로 볼 수 있는지, 또는 VirtualKeyboard API가 지원되는지 등을 다음과 같이 확인할 수 있습니다:

if ("application/pdf" in navigator.mimeTypes) {
  // 브라우저가 PDF 파일의 인라인 뷰를 지원합니다.
}
if ("virtualKeyboard" in navigator) {
  // 브라우저가 Virtual Keyboard API를 지원합니다.
}

스타일(CSS)의 경우에도, CSS 내에서 @supports 앳룰(@-rule)을 사용하여 기능 감지를 할 수 있습니다. 특정 기능이 없는 경우를 확인하고 싶다면 not 키워드와 결합하면 됩니다.
CSS에서 이를 사용하는 방법에 대한 정보는 기능 쿼리 사용하기(Using feature queries) 문서를 참조하세요.

@supports (display: grid) {
  .box {
    display: grid;
    gap: 2rem;
  }
}

@supports not (property: value) {
  /* 대체를 위한 CSS 규칙들 */
}

💡 강사의 팁: 요즘은 Storybook 같은 도구를 이용해 컴포넌트 주도 개발을 많이 하시죠? 이런 독립적인 환경에서 컴포넌트를 만들 때도, 브라우저 환경에 의존적인 UA 스니핑 대신 @supports 같은 기능 감지 쿼리를 적극 활용하면 어떤 환경에서든 깨지지 않고 안전하게 렌더링되는 UI를 작성하고 테스트할 수 있습니다.

특정 기능에 대해 브라우저 간 동작이 다른 드문 경우에는, 브라우저가 해당 API를 어떻게 구현하는지 직접 테스트해 보고 그에 따라 사용 방법을 결정해야 합니다.
자세한 내용은 기능 감지 구현하기(Implementing feature detection) 문서를 참조하세요.

모바일 기기 감지 (Mobile device detection)

UA 스니핑(그리고 뒤에 나올 클라이언트 힌트)의 가장 흔한 오용 사례는 클라이언트가 모바일 기기인지 감지하려는 시도입니다.
일반적으로 사람들은 사용자의 기기가 터치 친화적인지(touch-friendly), 그리고 화면이 작아서 버튼에 여백(padding)을 더 넣는 등의 최적화가 필요한지를 알고 싶어 합니다.

대신, 최신 API를 사용하여 기능을 감지해야 합니다.
예를 들어 터치 지원 여부를 확인하려면 Navigator 인터페이스의 maxTouchPoints 속성을 확인해 볼 수 있습니다:

if (navigator.maxTouchPoints > 1) {
  // 브라우저가 멀티터치를 지원합니다.
}

레이아웃과 같은 다른 문제에 대해서는 flexbox나 grid와 같은 최신 CSS를 활용하여 유연한 레이아웃을 구성하세요.
작은 화면에서 콘텐츠를 억지로 숨기는 대신 레이아웃이 동적으로 조정되도록 해야 합니다.
JavaScript 기반의 조정을 최소화하고, 대부분의 레이아웃 변경은 미디어 쿼리(Media queries)가 처리하도록 해야 합니다.

사용자가 기기를 회전하거나 다른 화면 모드로 전환할 때 부드러운 전환을 보장하고 싶다면, 기기 방향 감지(Detecting device orientation)를 살펴볼 수 있습니다.
폴더블 기기의 경우 Device Posture API 같은 최신 API도 있지만, 아직 지원 범위가 크게 다르므로 브라우저 호환성 데이터를 반드시 확인해야 합니다.

클라이언트 힌트 (Client hints)

Blink 기반 브라우저(Chromium, Edge, Brave, Vivaldi 등)의 경우, 사용자 에이전트 클라이언트 힌트(User agent client hints)라는 대안이 있습니다.
클라이언트 힌트는 서버가 HTTP 헤더나 JavaScript API를 통해 클라이언트에게 기기 정보를 선제적으로 요청하는 방식입니다.

클라이언트 힌트는 위장(spoofing)하기가 덜 쉽고 파싱하기 더 쉬운, 더 작고 신뢰할 수 있는 정보 조각들을 제공한다는 점에서 Blink 기반 브라우저를 감지할 때 UA 스니핑보다 낫습니다.
하지만 클라이언트 힌트를 기반으로 사이트의 기능을 변경하는 것 역시 여전히 좋은 생각은 아닙니다!
가능하다면 앞서 설명한 대로 기능 감지와 점진적 향상(progressive enhancement) 기법을 사용하는 것이 좋습니다.

예를 들어, HTTP 메커니즘에서 서버는 후속 요청 시 클라이언트가 포함해야 할 헤더 목록과 함께 Accept-CH 헤더를 포함합니다.
서버가 클라이언트에게 다음과 같은 응답을 보낸다고 가정해 보겠습니다:

Accept-CH: Sec-CH-UA-Mobile, Sec-CH-UA-Platform, Sec-CH-UA

이는 후속 요청 시 클라이언트로부터 다음 헤더들을 보내달라고 요청하는 것입니다:

Sec-CH-UA-Mobile: 클라이언트가 모바일 기기인지 나타내는 불리언(boolean) 값.
Sec-CH-UA-Platform: 클라이언트가 실행 중인 플랫폼("Windows", "Android" 등).
Sec-CH-UA: 사용자 에이전트의 브랜드명과 중요한 버전 정보.

클라이언트가 클라이언트 힌트를 지원한다고 가정하면, 이후의 요청에서 다음과 같이 UA 클라이언트 힌트가 나타날 수 있습니다:

GET /my/page HTTP/1.1
Host: example.site

Sec-CH-UA: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96"
Sec-CH-UA-Mobile: ?1
Sec-CH-UA-Platform: "Android"

클라이언트 힌트에 대해 더 알아보려면 HTTP 클라이언트 힌트(HTTP Client hints) 문서를 참조하세요.
이 기능을 사용하기 전에 브라우저 호환성(Browser Compatibility) 세부 정보를 반드시 확인하시기 바랍니다.

기타 기술 및 원칙 (Other techniques and principles)

점진적 향상 (Progressive enhancement)
: 이 디자인 기법은 웹사이트를 '계층(layers)' 단위로 개발하는 상향식(bottom-up) 접근 방식을 의미합니다. 가장 단순한 계층(기본 기능만 동작하는)에서 시작하여, 다음 계층으로 올라갈수록 더 많은 기능을 사용하여 사이트의 역량을 향상시켜 나가는 방식입니다.

우아한 성능 저하 (Graceful degradation)
: 이 방식은 반대로 하향식(top-down) 접근 방식입니다. 원하는 모든 최신 기능을 총동원하여 최고의 사이트를 먼저 구축한 다음, 구형 브라우저에서도 어떻게든 작동하도록 다듬어 나가는 방식이죠. 이는 점진적 향상보다 더 어렵고 효율성이 떨어질 수 있지만, 특정 상황에서는 유용할 수 있습니다.

브라우저 감지를 사용하는 잘못된 이유들 (Invalid reasons to use browser detection)

기능 감지나 점진적 향상 대신 여전히 브라우저 감지를 고려하고 계신다면, 혹시 다음과 같은 (잘못된) 이유 때문은 아닌지 스스로 점검해 보세요:

특정 브라우저 버전의 특정 버그를 우회(work around)하려고 시도 중이다.
: 여러분이 그 버그를 마주친 최초의 사람일 확률은 거의 없습니다.
전문가나 다른 관점을 가진 사람들이 버그를 더 잘 피하거나 우회할 수 있는 힌트를 제공해 줄 수 있습니다.
만약 문제가 흔치 않은 것이라면, 이 버그가 브라우저 공급업체의 버그 추적 시스템(Mozilla; WebKit; Blink; Opera)에 이미 보고되었는지 확인해 볼 가치가 있습니다.
브라우저 제작사들은 버그 리포트에 주목하며, 여러분의 제보가 문제를 고치거나 더 신뢰할 수 있는 우회 방법을 제공하는 데 도움이 될 수 있습니다.

방문자의 브라우저에 따라 다른 HTML을 제공하려고 한다.
: 이것은 일반적으로 나쁜 생각이지만, 이것이 불가피하게 필요한 드문 경우도 있습니다.
의미 없는(non-semantic) <div>나 <span> 요소를 추가하는 방식으로 이 문제를 막을 수는 없는지 고민해 보세요.
디자인 자체에 문제가 있는 것은 아닌지 검토해 보세요: 점진적 향상이나 유동적 레이아웃(fluid layouts)을 사용하면 굳이 이렇게 다른 HTML을 제공할 필요성을 없앨 수 있지 않을까요?
정확한 UA 감지를 적용하는 노력과 HTML 구조 자체를 재작업하는 노력 사이에서 무엇이 더 나은 선택일지 비교해 보아야 합니다.

방문자의 브라우저가 특정 기능을 가지고 있는지 확인하려고 한다.
: 사이트에서 특정 기능을 사용해야 하는데 일부 브라우저가 아직 이를 지원하지 않아서, 호환되지 않는 브라우저 사용자에게는 기능이 적더라도 확실히 작동할 구버전 웹사이트를 제공하고 싶을 수 있습니다.
이는 UA 감지를 사용하는 가장 최악의 이유입니다. 왜냐하면 결국 모든 브라우저들은 시간이 지나면 그 기능을 따라잡게(지원하게) 될 것이기 때문입니다.
게다가, 이런 방식으로 수많은 브라우저들의 수많은 기능 지원 여부를 일일이 테스트하는 것은 실용적이지도 않습니다.

관련된 UA 문자열 부분 추출하기 (Extracting relevant UA string parts)

위의 모든 옵션들을 다 검토해 보았지만 최후의 수단으로 여전히 UA 문자열을 파싱해야만 한다면, 이 섹션의 힌트들이 도움이 될 것입니다.
불행하게도 사용자 에이전트 문자열의 각 부분들은 전혀 통일성이 없으므로, 여기서부터는 꽤나 까다로운 작업이 될 것입니다.

💡 강사의 팁: 브라우저 호환성 때문에 UA 스니핑 코드를 한 땀 한 땀 정규식으로 짜기보다는, 요즘은 Vitest나 여러 테스트 도구에서 제공하는 브라우저 환경 시뮬레이션을 통해 크로스 브라우징 이슈를 격리된 환경에서 테스트하고 수정하는 것이 트렌드입니다. 무조건 문자열을 자르기 전에 다시 한번 대안을 생각해 보세요!

렌더링 엔진 (Rendering engine)

공통된 렌더링 엔진(rendering engine)을 공유하는 브라우저들은 페이지를 동일한 방식으로 표시합니다. 즉, 한 브라우저에서 잘 작동한다면 동일한 엔진을 쓰는 다른 브라우저에서도 잘 작동할 것이라고 가정하는 것이 꽤 합리적입니다.
현재 활발히 사용되는 주요 렌더링 엔진은 Blink, Gecko, WebKit 세 가지입니다.

아래 예시에서 렌더링 엔진은 Gecko/20100101 문자열로 표시됩니다. 이는 엔진 이름이 Gecko임을 나타내고, "gecko-Trail"인 고정 문자열 20100101은 "데스크톱" 환경임을 의미합니다:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

웹사이트에서 렌더링 엔진 이름을 감지하는 것은 꽤 흔한 일입니다. 역사적으로 수많은 사용자 에이전트들은 웹사이트들이 오직 렌더링 엔진 이름만 보고 자신들을 차단해 버리는 것을 피하기 위해, 다른 렌더링 엔진의 이름까지 덤으로 추가하곤 했습니다.
따라서 렌더링 엔진을 감지할 때는 오탐지(false-positives)가 발생하지 않도록 각별히 주의해야 하며, 이 방법 자체가 본질적으로 신뢰하기 힘든 방식이라는 점을 명심해야 합니다.
macOS의 Chrome 134에서 전송된 다음 UA 문자열을 살펴보세요:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36

엔진 (Engine)	반드시 포함해야 할 문자열	세부 정보 (Details)
Blink	`Chrome/xyz`
Gecko	`Gecko/xyz`
WebKit	`AppleWebKit/xyz`	WebKit 브라우저들은 `like Gecko`라는 문자열을 추가합니다. 감지 로직을 주의해서 적용하지 않으면 Gecko 엔진으로 잘못 인식(오탐지)할 수 있습니다.
Presto	`Opera/xyz`	구식입니다; Presto는 버전 15 이상의 Opera 브라우저 빌드에서는 더 이상 사용되지 않습니다 (Blink 엔진 참고).
EdgeHTML	`Edge/xyz`	구식입니다; EdgeHTML은 버전 79 이상의 Edge 브라우저 빌드에서는 더 이상 사용되지 않습니다 (Blink 엔진 참고).

렌더링 엔진 버전 (Rendering engine version)

Gecko 엔진을 제외한 대부분의 렌더링 엔진은 RenderingEngine/VersionNumber 토큰에 버전 번호를 넣습니다.
다음 예시에서 이는 rv:138.0 문자열에 해당하며, 렌더링 엔진 버전 번호가 Firefox 버전과 동일한 138.0임을 의미합니다:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

브라우저 이름 및 버전 (Browser name and version)

사람들이 "브라우저 감지"를 원한다고 말할 때, 그들이 실제로 원하는 것은 흔히 "렌더링 엔진 감지"인 경우가 많습니다.
이는 대개 "Firefox"나 "Safari"인지 확인하기보다는 "Gecko"인지 "WebKit"인지 감지하는 것을 의미합니다.

대부분의 브라우저는 BrowserName/VersionNumber 형식으로 이름과 버전을 설정합니다.
하지만 해당 형식 안에 브라우저 이름만이 유일한 정보로 존재하는 것은 아니기 때문에, 브라우저의 이름을 완벽히 '알아낼' 수는 없으며 단지 여러분이 찾고자 하는 이름이 포함되어 있는지 '확인'만 할 수 있습니다.
다음 예시에서 브라우저 이름은 Firefox/138.0 부분이며, 이는 브라우저 이름이 Firefox이고 소프트웨어 버전이 138.0임을 나타냅니다:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

어떤 브라우저들은 서로 충돌하는 정보를 전송하기도 합니다: 예를 들어 Chrome은 Chrome과 Safari를 동시에 보고합니다.
따라서 Safari를 감지하려면 Safari 문자열이 있는지 확인하는 동시에 Chrome 문자열이 '없는지' 확인해야 합니다. Chromium 역시 스스로를 Chrome이라고 보고하는 경우가 많고, SeaMonkey는 스스로를 Firefox라고 보고합니다.

사용자 에이전트 문자열에는 Keyword/Value 문법 주변에 다양한 텍스트가 포함되어 있으므로 BrowserName 부분에 정규 표현식(regular expressions)을 사용할 때는 매우 조심해야 합니다.
예를 들어 Safari와 Chrome은 둘 다 like Gecko라는 문자열을 포함하고 있습니다.

브라우저 이름	반드시 포함해야 할 문자열	반드시 포함하지 말아야 할 문자열
Firefox	`Firefox/xyz`	`Seamonkey/xyz`
Seamonkey	`Seamonkey/xyz`
Chrome	`Chrome/xyz`	`Chromium/xyz` 또는 `Edg.*/xyz`
Chromium	`Chromium/xyz`
Safari	`Safari/xyz` *	`Chrome/xyz` 또는 `Chromium/xyz`
Opera 15+ (Blink 기반 엔진)	`OPR/xyz`
Opera 12- (Presto 기반 엔진)	`Opera/xyz`

Safari는 두 가지 버전 번호를 제공합니다: 하나는 Safari/xyz 토큰 안의 기술적(technical)인 버전 번호이고, 다른 하나는 Version/xyz 토큰 안의 사용자 친화적인(user-friendly) 버전 번호입니다.

물론, 다른 브라우저들이 특정 상황에서 이 문자열들을 위장(spoofing)하지 않을 것이라는 보장은 절대 없습니다.
그렇기 때문에 사용자 에이전트 문자열을 사용한 브라우저 감지는 신뢰할 수 없으며, 버전 번호를 확인하는 용도로만(과거 버전을 위장할 확률은 낮으므로) 조심스럽게 사용해야 합니다.

운영체제 감지 (Operating system detection)

운영체제(OS) 정보는 대부분의 UA 문자열에 포함되어 전송되지만(웹에 특화되지 않은 플랫폼 제외), 그 형식은 매우 다양합니다.
이는 User Agent의 주석(comment) 부분에서 두 개의 세미콜론(;) 사이에 위치하는 고정 문자열로, 각 브라우저마다 고유한 형태를 띱니다.

이 정보는 OS의 종류, 그리고 종종 OS 버전이나 기반이 되는 하드웨어 정보(32/64비트, Mac의 경우 Intel/PPC, Windows PC의 경우 x86/ARM CPU 아키텍처)를 나타냅니다.
다음 예시에서는 Intel Mac OS X 10.15 문자열이 이에 해당합니다:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

어떤 경우든 이 문자열들은 언제든지 변경될 수 있으므로, 패턴이 미리 알려진 이미 릴리스된 구형 브라우저들을 감지할 때만 사용하는 것이 좋습니다.
새로운 브라우저 버전이 출시될 때마다 여러분의 코드를 알맞게 수정하려면 방문자 기록이나 UA 문자열 조사 데이터를 참고하시길 바랍니다.

모바일, 태블릿, 또는 데스크톱 (Mobile, Tablet or Desktop)

사용자 에이전트 스니핑을 수행하는 가장 흔한 이유는 브라우저가 실행되고 있는 기기의 형태(타입)를 알아내기 위함입니다.

브라우저나 렌더링 엔진이 오직 단 한 가지 유형의 기기에서만 실행될 것이라고 절대 단정 짓지 마세요.
특히 브라우저나 렌더링 엔진마다 적용되는 각기 다른 기본값(defaults)에 의존해서는 안 됩니다.
브라우저가 모바일, 태블릿, 데스크톱 중 어디에 있는지 파악하기 위해 OS 토큰을 절대 사용하지 마세요.
OS는 두 가지 이상의 기기에서 실행될 수 있습니다 (예를 들어, Android는 휴대폰뿐만 아니라 태블릿에서도 실행됩니다).

다음 표는 일반적인 브라우저 공급업체들이 자사 브라우저가 모바일 기기에서 실행되고 있음을 나타내는 방식들을 요약한 것입니다:

브라우저	규칙	예시
Mozilla (Gecko, Firefox)	주석(comment) 안에 `Mobile` 또는 `Tablet` 포함.	`Mozilla/5.0 (Android 15; Mobile; rv:136.0) Gecko/136.0 Firefox/136.0`
WebKit 기반 (Android, Safari)	주석 바깥에 `Mobile Safari` 토큰 포함.	`Mozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30`
Blink 기반 (Chromium, Google Chrome, Opera 15+, Edge on Android)	주석 바깥에 `Mobile Safari` 토큰 포함.	`Mozilla/5.0 (Linux; Android 4.4.2; Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047`
Edge on Windows 10 Mobile	주석 바깥에 `Mobile/xyz` 및 `Edge/` 토큰 포함.	`Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; Xbox; Xbox One) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Mobile Safari/537.36 Edge/16.16299`

요약하자면, UA 문자열의 그 어디에든 Mobi라는 문자열이 있는지 찾아보면 됩니다.
만약 기기 화면이 충분히 커서 Mobi 표시가 없다면, 데스크톱 버전의 사이트를 제공해야 합니다 (물론 모범 사례로서 데스크톱 기기 역시 터치스크린을 가질 수 있으므로 당연히 터치 입력 지원도 포함해야 합니다).

같이 보기 (See also)

김동현

프론트에_가까운_풀스택_개발자

이전 포스트

HTTP/Guides/Content negotiation/Default Accept values

다음 포스트