그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Browser
Browser

User-Agent 헤더는 뭐고, 실무에서 어디까지 써도 되나요?

실무3/5
설계4/5
인간3/5
기초1/5

면접관의 질문 의도

UA를 정의 수준으로만 아는지, 아니면 왜 UA 분기가 위험한지와 그럼에도 UA가 필요한 좁은 자리를 같이 짚는지를 가르는 질문이다. 호환성 대응을 평소 어떻게 풀어왔는지가 답에서 자연스럽게 드러나야 한다.

큐레이션 답변

학습 자료

User-Agent는 요청을 보낸 클라이언트의 브라우저·엔진·OS 정보를 담아 보내는 HTTP 헤더다. 서버는 요청 헤더에서, 클라이언트는 navigator.userAgent로 읽는다. 문제는 UA 문자열이 역사적으로 호환성을 위해 거짓 정보까지 섞여 있는 포맷이라 정밀 분기의 근거로는 약하다는 점이다. 그래서 실무 원칙은 단순하다. 가능한 한 기능 감지로 풀고, UA는 다른 방법이 없을 때만 좁은 범위로 쓴다.

좋은 답변 구조

  1. 01UA 헤더가 무엇이고 어디서 읽는지(서버 요청 헤더 / navigator.userAgent) 짧게 정의한다
  2. 02UA 분기의 한계를 짚는다 — 거짓 정보가 섞인 포맷이고 UA Reduction으로 동결되는 중이라는 점
  3. 031차 원칙이 기능 감지이며 Client Hints가 표준 방향임을 설명한다
  4. 04UA를 정당하게 쓰는 좁은 케이스(로그 집계, 봇 식별, 특정 버그 우회)를 들고 답을 닫는다

자주 실수하는 포인트

UA를 "기기 정보를 정확히 알려주는 헤더"로 단정하고 거짓 포맷 역사를 모른다
기능 감지를 대안으로 떠올리지 못하고 모든 분기를 UA 정규식으로 처리한다
Client Hints나 UA Reduction 같은 표준 방향을 모른 채 "UA 보고 분기하면 됩니다"로 끝낸다
UA가 정당하게 쓰이는 자리(로그·봇 식별·특정 버그 우회)를 한 케이스도 못 든다

실무 맥락

  • 특정 브라우저에서만 재현되는 렌더링·입력 버그를 단기 우회해야 하는 상황
  • 트래픽 로그에서 봇·크롤러를 가려내 분석 지표를 정리해야 하는 상황
  • 구형 브라우저 점유율이 남아 있어 폴리필이나 대체 UI 제공 여부를 정해야 하는 상황
  • 기존 UA 분기 코드를 Client Hints로 옮길지, 기능 감지로 걷어낼지 결정해야 하는 상황

본인 경험에 녹이는 힌트

특정 브라우저 버그를 UA 분기로 막아본 경험이 있다면 그 분기를 언제 걷어냈는지까지 같이 말할 수 있다

기능 감지로 바꾸면서 분기 코드가 줄어든 사례가 있다면 유지보수 비용 관점으로 연결할 수 있다

로그 분석에서 UA를 봇 식별 용도로 써본 적이 있다면 "UA를 분기가 아니라 관찰용으로 쓴 케이스"로 풀 수 있다

Client Hints 도입을 검토하거나 적용해 본 경험이 있다면 표준 방향에 대한 감각을 자연스럽게 보여줄 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1UA 분기가 불가피할 때 어디서 어떻게 끊는 게 안전한가요?
Q2feature detection은 어떤 기준으로 적용하고 한계는 무엇인가요?
Q3Client Hints(Sec-CH-UA 등)는 UA와 어떻게 다르고 언제 도입을 고려하나요?
Q4UA Reduction이 진행되면 기존 코드의 어떤 부분이 먼저 깨질까요?
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문