개발관련/정보

모질라(Mozilla)란? / User-Agent 구조의 기원, 유래/ User-Agent Mozilla/5.0 시작 이유

고통받는다 2023. 7. 5. 19:58

저번 포스팅에서 Http 통신을 위해 header에 넣어 보내는 User-Agent에 대해 포스팅을 했었습니다.

그곳에서 저희는 대부분의 브라우저들이 Mozilla5.0을 사용한다는 것을 확인했었죠.

아니 나는 크롬에서 접속했는데?, 네이버 웨일에서 접속했는데? 왜 모질라가?

그럼 이 Mozilla 라는건 대체 뭐길래 이렇게나 많은 곳에서 사용하는 걸까요?

인터넷을 특정 기업이 독점하게 된다면..?

 

 

인터넷은 우리 사회에 있어 절대 빠질 수 없는 아주 편리한 기술입니다.

만약 이 인터넷 기술을 특정 기업이 독점한다면 어떤 사태가 발생할까요...?

본인 기업에 유리한 방향으로 기술을 개발하고 사용자들에게 불이익을 준다고 해도... 대안이 없으니 이용자들은 어쩔 수 없이 사용을 해야 할 겁니다.​

90년대 넷스케이프와 MS

 

과거에는 이 인터넷을 특정 기업이 독점을 했었습니다.

그게 바로 넷스케이프 회사에서 만든 넷스케이프 커뮤니케이터 웹 브라우저였습니다.

돈이 되는 인터넷을 그냥 무료로 배포했을 리가 없겠죠? 당연히 상용화를 하면서 돈을 엄청나게 많이 벌었습니다.

하지만 이런 영광은 오래가지 못하게 되었는데..

이유는 MS가 IE(Internet Explorer)를 개발하고 자신들이 개발한 Window에 무료로 탑재하였기 때문이죠..

OS를 사면 무료로 탑재해 주는 IE, 돈 주고 사용해야 하는 넷스케이프... 사용자들의 선택은 너무나도 당연한 것이었습니다.

결국 IE에 밀려서 망하기 직전까지 간 넷스케이프는.. MS에 반독점법으로 제소를 했고... 처음에는 반독점법을 인정을 하였으나.. 소비자에게 도움이 된다는 이유로 IE를 Window에 끼워팔지 못하게 하는 건 해제가 되었습니다.

소송은 계속되었고... 결국에는 MS의 IE 반독점을 인정을 하였으나... 사용자들은 소송 와중에도 계속 IE로 빠져나가고 있었고... 도입되는 신기술도 IE에 따라갈 수가 없었죠.​

넷스케이프의 몰락과 모질라의 탄생

결국 넷스케이프는 1998년 넷스케이프의 원본 코드를 오픈 소스로 공개하여 오픈소스 진영의 개발자들의 힘을 빌리기로 합니다.

소스 공개... 진행시켜

이를 기초로 나타난 것이 바로 "모질라 프로젝트"입니다.

모질라의 어원은 모자이크 킬러라는 소리도 있고... 영화 고질라와 모자이크 웹브라우저를 합성한 말이라고 하는 등 여러 설이 있습니다.

모질라 협회가 만들어지고 2003년 7월까지 모질라 협회가 AOL의 이름을 걸고 개발을 주도하였으나..

생각보다 IE 점유율을 가져오지 못하여... 개발부서를 폐지하게 됩니다.

그 이후로는 모질라 커뮤니티가 중심이 되어 비영리 단체인 모질라 재단을 설립하였고 개발을 주도했습니다.

그리고 이곳에서 FireFox라는 웹 브라우저를 만들게 되죠.

모질라 재단이 개발한 파이어 폭스

 

그래서 왜 User-Agent에 모질라가 다 붙음?

 

 

자... 그럼 돌아와서 왜 User-Agent에 모두 모질라가 붙느냐....라고 한다면

호환성 유지 때문입니다...

인터넷 웹 브라우저는 넷스케이프와 MS의 IE가 있었다고 했었죠.

그리고 개발자들이 우스갯소리로 뭐든지 원인은 MS에 있다고 말하죠..

이번에도 MS가 원인입니다.

MS... 또 너냐!!!!

UA가 더러워진 단계는 다음과 같습니다.

1.

MS의 IE가 넷스케이프 브라우저의 UA를 흉내 냄으로 처음으로 UA가 더럽게 만들어지기 시작했습니다.

(최초 시발점)

2.

넷스케이프 브라우저의 엔진을 오픈소스 프로젝트로 공개한 이후에는 렌더 엔진 정보도 UA에 추가하기 시작되었습니다.

3.

브라우저 전쟁 이후 엄청나게 많은 브라우저들이 생겼는데, 이 브라우저들의 호환성을 유지하기 위해 기존 브라우저 UA에 계속해서 스트링을 덧붙여서 이런 끔찍한 혼종이 만들어지게 된 겁니다..​

'Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Mobile Safari/537.36'

네이버 웨일 UA 예시

이게 왜 이렇게 되었는지 한번 그 시절의 사정을 알아보도록 하겠습니다.

 

브라우저 전쟁과 흑화 한 IE 개발자들

 

위 쪽에서 설명했다 싶이 IE와 넷스케이프의 전쟁은 IE의 승리로 끝이 났지만... 원래 초창기 IE는 넷스케이프에 상대가 되지 않았습니다.

때문에 당시 웹 서버들은 UA를 체크해서 이게 넷스케이프인지 아니면 IE 인지 확인 후 넷스케이프라면 특별한 처리를 해주었는데... 그것이 바로 프레임 태그 처리였습니다.

그 이유가 넷스케이프는 최초로 프레임 태그를 지원한 브라우저였기 때문이었습니다.

( 늘 그렇듯이.. 언제나 최초는 특별하죠.. )

프레임 태그란 HTML 파일 내에서 또 다른 HTML 파일의 콘텐츠를 불러오는 태그입니다.

이 기능은 각 콘텐츠를 따로 불러오는 컨테이너의 역할을 했을 뿐 아니라 HTML을 역할별로 나눌 수 있다는 점에서 매우 획기적인 기능이었습니다.

하지만... 위에서도 설명드렸다 싶이 넷스케이프 브라우저가 최초로 해당 기능을 지원하는 브라우저였고... 다른 브라우저는 지원하지 않았습니다.

그럼 웹서버들은 어떻게 처리를 했겠습니까?

당연히 UA를 확인한 후 브라우저에 맞춰서 HTML을 따로 제공하는 방법을 선택을 했겠죠.

경쟁 상대인 IE도 프레임 태그를 지원을 했습니다.

하지만!!! 당시 웹서버들은 오직 넷스케이프 브라우저인지 아닌지만 판단하여 프레임 태그를 지원을 했었죠..

(이걸 다 수정하는 것도 일이고... 당시 그다지 점유율이 높지 않았던 IE를 위해 웹 서버를 개발한 회사들은 지금 당장 수정을 할 필요가 없었죠...)

시간이 흘러 웹 서버들이 IE를 지원해 줄 때까지 천천히 기다리면 되었으나... 시장에 영향을 미칠 정도로 반영이 되려면 너무나도 오랜 시간이 걸린다는 문제가 생겼죠..

그 시간을 기다리지 못한 IE 개발자들은... 결국 흑화 해 버리고 말았습니다.

자신들의 UA를 Mozilla로 시작하게 만듦으로 웹 서버를 속이는 방법을 사용한 것이죠.

뭐... 뭐라고...?

놀랍게도 당시 웹 서버들은 브라우저 제품 이름만 보았기 때문에... 저 방법이 먹혔습니다.​

넷스케이프의 몰락 그리고 게코 엔진의 등장

위쪽에서 언급했던 것처럼 넷스케이프도 결국 IE에 의해 몰락하게 되었습니다.

모질라 재단을 만들었다고 했죠. 이때 공개한 것이 넷스케이프 6의 랜더 엔진인 게코 엔진입니다.

그리고 2002년 이 엔진을 기반으로 한 파이어 폭스가 만들어지게 되었죠

게코 엔진에서는 UA가 지켜야 할 사항을 적어놨는데 그 내용은 다음과 같습니다.

Mozilla/Version (Platform; Encryption; OS-or-CPU; Language; PrereleaseVersion)Gecko/GeckoVersion ApplicationProduct/ApplicationProductVersion

 

사실 게코 엔진이 등장하고 나서부터는 맨 앞의 Mozilla/5.0은 더 이상 필요 없는 존재가 되었으나.. 늘 그렇듯이 이전 코드와의 호환성을 위해 남겨두게 되었습니다.

이때부터 모든 UA 스트링의 시작은 항상 Mozilla/5.0이 되었습니다.​

더욱더 괴랄해지는 UA

 

히히 나도 MS 따라 해야지

여기서 끝나면 다행이지만....

안타깝게도 그렇지 않습니다.

안 그래도 MS 때문에 이상해진 UA에 애플이 똥을 집어넣었거든요...​

애플의 사파리 브라우저 발표

2003년 애플은 웹킷 기반의 사파리 브라우저를 발표하게 됩니다.

웹킷은 KHTML에서 파생된 프로젝트로, 애플이 여러 기능들을 집어넣어 별도의 프로젝트로 분리한 것이라고 합니다.

자 자신만의 브라우저와 엔진을 만들었다... 뭔가 익숙한 상황인 거 같지 않습니까?

네 맞습니다.. 현재 시장은 게코 기반의 브라우저들이 대세인 상태입니다.

그럼 웹킷 기반의 사파리를 어떻게 시장에 풀 것인가가 문제였죠..

고민을 하다가 애플도 마이크로소프트와 똑같은 선택을 하게 됩니다.

바로 (KHTML, like Gecko)라는 스트링을 집어넣은 것이죠..

크롬의 등장.

이제 저희들이 익숙하게 사용하는 브라우저인 크롬이 등장을 했습니다.

하지만 크롬 역시 웹킷 기반의 브라우저였기 때문에... 렌더 엔진이 사파리처럼 인식이 되어야 했습니다.

그래서 어쩔 수 없이 사파리의 UA를 따라 하면서 거기에 자신들의 브라우저인 Chrome 스트링을 끼워 넣었습니다.

나보고.. 어쩌라고....

'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36'

 

그래서 이런 UA가 만들어진 것이죠..

즉 위 UA는 과거부터 내려온 똥에 의해...

  1. 윈도우에서 동작하는 크롬 브라우저임
  2. 웹킷 기반 브라우저임
  3. 사파리처럼 인식돼야 해서 사파리 UA를 따라 함
  4. 게코 엔진과 호환하기 위해 (KHTML, like Gecko) 스트링을 씀
  5. 모든 브라우저의 UA는 넷스케이프 호환임을 따라야 함

저런 동작을 처리해야 해서 이런 괴랄한 UA가 탄생하게 된 것입니다.​

결론

 

UA가 이렇게 만들어진 이유는 결국 기존에 있던 타 브라우저 흉내 내기가 계속해서 이어진 탓입니다.

호환성을 유지하기 위해 억지로 쓸모없는 정보들만 가득 차버리니... 허허 이게 뭐 하는 짓인지 모르겠네요..

처음에는 파이썬 http 통신을 위해 header 부분 공부하다... User-Agent가 뭐지? 하면서 찾고... 왜 시작이 Mozilla/5.0으로 시작하는가 의문을 가지면서 끝없이 파내려 갔는데... 이런 이유가 있었을 줄이야 ㅎㅎ...

공부하면서도 정말 흥미로웠고 재미있었습니다.