웹개발을 하다보면 User-Agent String이라는걸 보게됩니다.
접속한 사람의 브라우저가 뭔지 서버에서 확인하는 그런건데 이게 요상한 역사가 있습니다.
2024년현재 이 Agent String(이하 UA)는 그냥 꼼수와 꼼수와 꼼수를 거쳐 하나의 거대한 역사의 한 장면을 연출합니다

처음에는 간단했습니다. Mosaic시절부터 Netscape때 까지만.

NCSA Mosaic/3.0 (Windows 95)
Mozilla/4.8 [en] (Windows NT 5.0; U)


위는 Win95의 모자이크고 아래는 윈도2000에서 넷스케이프4.8 (넷스케이프의 개발명이 Mozilla였습니다.)로 접속시 뜨는 UA입니다.
대충 이렇게 브라우저 이름과 운영체제가 뜨는 수준이었습니다.

하지만 Javascript(이하 JS)가 등장하면서 이를 활용한 웹페이지들이 만들어졌고 이를 지원하지 않으면 제대로 뜨지 않으니 웹개발자들은 지원여부를 구분해야했습니다. 다만 이를 지원하는지 확인하는게 UA밖에 없었습니다. 그래서 당시 주류이자 Javascript를 유일하게 지원했던 Netscape냐 아니냐 정도로 구분했습니다.

그 당시 쓰던 코드가 UA문구중에 Mozilla가 있느냐 없느냐 였습니다. 그러다 Internet Explorer(이하IE)가 등장하면서 꼬이기 시작합니다.

IE는 Netscape와 호환을 목표로 했기에 JS가 지원됐지만 웹페이지들은 Mozilla라는 문구만 확인했기에 IE에도 JS가 안되던 이전페이지만 보여줬고 이를 해결하기위해 MS가 만든건

Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)

(Win95에서 IE2.0사용시)

네... User Agent에 Mozilla라고 집어넣고 compatible이라는 문구를 넣었습니다.
즉 나는 넷스케이프와 호환되는 녀석이다라고 적은건데 이 때까지만해도 이게 재앙의 시작일줄은 몰랐을겁니다.

이후 버전업을 하고 Windows가 이런저런 에디션이 생기면서 UA는 더 지랄맞아지게 됩니다

Mozilla/4.0 (compatible; U; MSIE 6.0; Windows NT 5.1) (Compatible; ; ; Trident/4.0; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 1.0.3705; .NET CLR 1.1.4322)


WindowsXP x64버전의 IE6.0을 32비트버전으로 실행했으며 닷넷프레임웍을 3.5버전으로 설치된 환경이라는 의미입니다.

닷넷프레임웍버전이 끼어들어간 이유가 당시 MS가 당시 많이 쓰이던 자바대신 닷넷을 밀고있었는데 이게 또 버전별로 호환을 탔기 때문입니다.

네...벌써 개판입니다. 하지만 MS는 IE개발에 손을 놓았고 Firefox가 등장하면서 또 한번의 격변이 일어납니다.

Firefox는 그래도 MS보단 고집이 있어서 (그리고 무엇보다 Netscape의 직계후손이라서)UA를 깔끔하게 보냈습니다.

Mozilla/5.0 (X11;U;Linux i686;en-US;rv:1.8.1) Gecko/2006101022 Firefox/2.0

 

리눅스 X11환경에서 영문으로 돌아가는 Firefox 2.0 대충요런식입니다.
특히 여기서 Gecko라는 문구가 중요한데 당시 웹표준이 대두가 되면서 HTML5가 이슈가 되기 시작했습니다. 그 당시 HTML5의 지원을 제일 서두르던것이 Firefox의 Gecko엔진이었고 Firefox의 엔진인 Gecko를 쓰는지만으로 HTML5가 지원되는지 아닌지 판단하곤했습니다. (Gecko는 오픈소스였기에 Firefox기반브라우저가 우후죽순 있었습니다.)

여기서 그동안 IE를 쓰던 애플은 자기들만의 브라우저가 있어야겠다고 판단하고 오픈소스 엔진인 KHTML을 가지고 Webkit이라는 엔진을 발표한뒤 Safari라는 이름으로 브라우저를 내놓게 됩니다.

Webkit은 HTML5를 준수하는 브라우저 였지만 웹페이지는 이를 알 수가 없었고 Gecko와 호환된다는 명목으로 UA에 like Gecko라는 문구를 적습니다.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/532.0+ (KHTML, like Gecko) Version/4.0.3 Safari/531.9.2009


물론 자신의 이름도 꼭 뒤에 적어서 Safari인지 판단하도록 했습니다.

그리고 Webkit을 기반으로 한 Chrome이 등장하면서 또 한번의 격변이 일어나는데...

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chromium/15.0.871.0 Chrome/15.0.871.0 Safari/535.2


다시 개판이 되기 시작했습니다. 당시에는 Webkit을 이용한게 맞으니까 AppleWebkit이라고 적는건 이해하는데 뒤에 Safari도 함께 적었습니다. 그게 Webkit이 아닌 Safari라는 문구를 쓰는게 더 익숙했던 Webkit용 페이지 덕분에 그냥 Safari를 적었다고 합니다. 덕분에 크롬을 쓰면 애플홈페이지에서 맥 전용기능을 실행하려 들었다고 하네요.

추가로 IE11도 HTML5를 준수하면서 똑같이 like Gecko문구를 추가합니다.

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko


어쩌다보니 자바스크립트지원 여부를 판단하는 Mozilla라는 문구처럼 Gecko라는 문구는 HTML5지원여부를 판단하는 문구가 되어버렸고 Mozilla와 관계없는 모든 브라우저가 Mozilla라고 적고 역시 Gecko엔진을 쓰지 않는 모든 브라우저가 Gecko를 적는 요상한 현상이 일어났습니다.

여기에 크롬이 브라우저의 대세가 되고 HTML5의 특정 기능들이 크롬에서 가장 먼저구현되며 Chrome이라는 문구를 찾아 전용코드를 쓰는 일이 생기게 되었는데

Chromium으로 만들어진 Edge는 당연히 이를 지원하기에 Chrome이라는 문구를 넣었습니다

 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.19582


당연히 뒤에 자신이 Edge라는 문구를 추가해서요.

Mozilla에 Gecko에 Safari에 이젠 Chrome이라는 문구까지 UA에 들어가기 시작했습니다.

하하...이젠 개판이네...

,

※제목을 저렇게 해놓긴했지만 정확히 말하면 일반인이 생각하는 해커에 더 가깝습니다.
하지만 개발자는 곧 해커라고 볼 수있으니(안좋은 의미의 해커가 아니라 좋은 의미의 해커)그게그거 아닐까 싶습니다.

영화나 드라마등에서 개발자는 무슨 컴퓨터 앞에서 뚜드리고 뭔가 척!하면 짠하고 뭐가되는 그런 이미지입니다.
그런데 현실은 다들 알다시피 "이게 왜 이러지?"단계가 존재합니다. "생각한다-구현한다-기도한다"라는 개발자유머가 있을정도지요.

하지만 비개발자들은 개발을 맡기면 그냥 알아서 뿅하고 가져온다고 생각하는듯 합니다. 사실 개발의 80%가 디버깅이니 수없는 노가다끝에 만드는건데 말이지요.

개발자가 말하는 기능구현 = 이제 첫단추끼웠다. 이제 디버깅작업이다.
비개발자가 생각하는 기능구현 = 아무문제없이 완벽하다


PSP가 막 팔리던 시절 펌웨어 첫 해킹성공으로 사진한장이 공개됐는데 그냥 PSP화면에 "Hello, World!"가 띄워져있었습니다.
당연히 관련 커뮤니티는 난리났는데 당시 모 게시판에선 "고작 문구하나 띄운거가지고 뭔 호들갑이냐"라는 댓글을 달려있었습니다.
비개발자입장에선 "고작 문구"겠지만 이게 무엇을 의미하는거냐면 PSP라는 플랫폼에서 새로운 무언가를 만들수 있는 환경이 생겼다는겁니다.

사실 모든 개발환경을 갖추고 제일먼저하는건 "Hello World"를 띄우는겁니다. 해당 개발환경이 제대로 만들어진건지 확인하는것이지요.

비개발자들은 이 Hello World띄우는게 쉽다고 생각한거 같지만 개발자들입장에선 개발환경의 완성이라는 큰 의미인겁니다.
(이해가 안 된다면 집을 짓기위한 터다지기 작업이 완료됐다고 생각하시면 됩니다)

국내에선 디X인사이드 컴갤이나 Github갤에서 이런 요상한 글들이 많이 보이는데 거긴 아무래도 비개발자출신 자칭개발자들이 많아서 벌어지는듯 합니다. Hello World비하는 일상에 C99와 C17이 뭐가 다르냐고 하더군요. (Visual C++만 쓰는경우 이렇게 되곤합니다. 즉, 타 플랫폼 경험부족)

그러니까 개발자들에게 개발은 계단처럼 하나하나 밟아나가는 일입니다.
하지만 비개발자들은 개발이 짠하고 나오는걸로 착각을 자주합니다. 그러니 어렵게 하지말고 개발자들 힘들게 안 했으면 좋겠네요.

,

RHEL과 CentOS이야기는 리눅스쓰시는분들이라면 잘 아실겁니다.

RHEL은 전세계에서 가장 인기있는 대규모 서버용 배포판이고 안정성도 충분히 검증되어왔습니다. 그리고 그 안정성을 바탕으로 기술지원등의 수익을 벌고 있습니다.
그리고 대한민국한정으로 리눅스로 밥벌어먹을때 익혀야할 필수 배포판입니다.(우분투는 대한민국에서 아쉽게도 이쪽에서 크게 힘을 못 씁니다)

그리고 CentOS는 이 RHEL과의 호환성을 보장하고 무료로 배포된 배포판이기에 RHEL쓰다가 CentOS로 바꿔도 쓰던거 그대로 쓸 수있을 정도로 RHEL과 호환성이 좋기에 굳이 기술지원이 필요없다면 개인차원에서도 RHEL공부용으로 쓰기 좋은 배포판이었습니다. 그리고 국내에선 네이버나 카카오같은 자체개발능력이 있는곳에선 CentOS를 주력으로 쓰고있었지요.

그러다 CentOS를 직접 레드햇이 인수하게 되는데 이때까진 그래도 괜찮았습니다. 호환성을 무기로 점유율을 늘린건데 호환성이 더 좋아지면 더 좋아졌지 개판이 될거라고는 생각못했으니까요.

하지만 레드햇은 CentOS의 목을 쳐버리고 말았습니다.
기존 CentOS의 지원기간을 줄이고 이후에는 CentOS Stream이라는 개발버전만 남기기로 했습니다.

CentOS Stream은 RHEL과 호환되지 않습니다. RHEL은 안정성이 검증된 특정버전을 꾸준하게 보안업데이트만 하면서 지원해주는것이 특징인데 CentOS Stream은 말그대로 Debian unstable마냥 굴러가거든요.
Debian unstable과 stable이 일부 라이브러리에서 서로 충돌나는것처럼 CentOS Stream과 RHEL은 충돌납니다.

이후 CentOS의 후신을 자처하며 Rocky가 등장했고 Oracle도 CentOS에서 넘어올 수있도록 스크립트까지 배포하며 열심이었는데 레드햇은 이 Rocky도 마음에 안들었는지 유료 구독자 이외에는 자신들의 소스접근을 차단하기에 이르렀습니다. (호환성을 얻기위해선 소스를 알아야겠지요. 이걸 못 하게 막은겁니다.)

레드햇이 리눅스 개발커뮤니티에서 끼치는 영향을 생각하면 이건 상당히 위험한 행보입니다. 당장 RHEL의 점유율에는 영향이 없겠지만 (아니, 오히려 RHEL의 점유율은 올라갔습니다) 이미 개발자들에게 찍혀버렸고 CentOS로 RHEL관리법을 배우던 학생들도 사라져버렸습니다.

보통 CentOS로 공부하던 사람들이 현장에서 RHEL을 쓰는 방식으로 점유율이 높아진건데 이들이 사라지고 말았으니 이후 미래는 조금 위험해지지 않았나 싶습니다.

P.S RHEL의 소규모버전은 무료로 풀었다고 합니다. 학교등의 소규모 서버는 이걸로 한다고쳐도 규모있는 중견기업은 어떻게 해야할까요? RHEL을 구독해야할까요?

,