오늘은 오랜만에 웹에 관련된 포스팅입니다.
혹시 초창기에 서비스 되던 웹의 모습을 알고 계신가요? 지금 우리가 사용하고 있는 대표적인 포털 사이트인 네이버와 다음의 초창기 모습은 현재의 모습과는 사뭇 달랐습니다.
제가 기억하는 모습보다도 훨씬 이전의 화면들이라 낯설게 느껴지는데, 몇 가지 특징들이 눈에 들어옵니다. 요즘은 어딜가도 쉽게 찾아 볼 수 있는 CSS를 이용한 화려한 스타일들은 보이지 않고, 파란색 밑줄이 그어진 a 태그나 블릿이 찍혀있는 li 태그 등 HTML 태그들이 기본으로 갖고있는 스타일들이 그대로 노출되어 있는 모습입니다. 이제는 거의 사용되지 않는 table 태그도 보이네요. 두 페이지 사이의 시간 간격이 1년(네이버 1998년 12월, 다음 2000년 2월)이 조금 넘게 있는만큼 이러한 특징은 네이버에서 상대적으로 더 두드러지게 나타나고 있습니다.
캡쳐에서는 나타나지 않지만, 이 당시의 웹의 특징을 한 가지 더 꼽아보자면 바로 Ajax 기술이 보편화되지 않았다는 점입니다. 오늘 포스팅의 주제는 바로 이 Ajax입니다.
Ajax란?
Ajax는 Asynchronous JavaScript And XML, 즉 비동기 자바스크립트와 XML을 이르는 약자입니다. 보통 페이지를 새로 갱신하지 않고 비동기 통신을 이용해 데이터를 가져오는 기법을 의미합니다. 쓸때는 가장 앞의 A만 대문자로, 나머지는 소문자로 쓰며 읽을때는 영미쪽에선 에이잭스, 유럽쪽에선 아약스라고 읽었지만 현재는 대부분 에이잭스라고 읽습니다.
위의 웹 사이트가 서비스 되던 시기에는 이러한 Ajax 기술이 거의 사용되지 않았습니다. 그 이전에도 존재는 하던 기술이었지만, 구글이 Gmail과 지도 등의 웹 애플리케이션을 만들때 활용하며 본격적으로 이목을 끌기 시작한 것이 2004년부터이니 위에서 소개한 98년과 00년의 두 페이지에 적용되지 않은건 이상한 일이 아닙니다.
그럼, Ajax를 사용하면 어떤 이점이 있을까요?
Ajax의 장점
페이지 이동 없이 화면 전환이 가능하다
기존에는 서버가 클라이언트에게 보낸 페이지에 다른 내용을 표시해주려면 페이지 이동이 필요했습니다. 서버로부터 그 내용이 포함된 페이지 자체를 다시 받아와서 사용자에게 띄워주어야 했기 때문입니다. 그러나 Ajax를 이용하면 원하는 데이터만 요청해서 새로 받아오고, 이를 화면에 표시해줌으로서 기존의 불필요한 페이지 이동 없이도 화면 전환이 가능하게됩니다.
서버의 자원을 절약할 수 있다
불필요한 페이지 이동이 없으니, 서버가 내려줘야 하는 데이터의 크기도 작아지게 됩니다. 수신할 데이터의 절대적인 양이 줄어들다보니 그만큼 서버가 하는 일이 적어지게 되어 부담을 줄여줄 수 있습니다.
사용성이 높아진다
위의 특성들 덕분에 사용자와 페이지 간의 인터렉션이 향상됩니다. 페이지가 이동하지 않으니 중간에 페이지가 깜빡거리는 현상 없이 데이터를 보여줄 수 있고, 응답 속도 자체도 빨라지게 되어 높은 사용성을 갖게됩니다. 서버의 역할이 줄어든만큼 클라이언트에서 동작에 대한 처리를 할 수도 있습니다.
이렇듯 Ajax는 많은 장점을 갖고 있기 때문에 실제로 현재 대부분의 페이지에서 사용되고 있습니다.
Ajax의 단점?
장점이 있다면 단점이 있듯, Ajax에도 단점이 있습니다. 다만 알려져있는 Ajax의 단점을 Ajax를 사용하지 않아야 할 충분한 이유가 되는 단점으로 보아야하는지에 대한 의문은 여전히 남아있습니다.
Ajax를 사용할 수 없는 브라우저에선 사용할 수 없다?
Ajax를 지원하지 않는 브라우저들을 살펴보면 오페라 7 이하, IE 4.0 이하, 텍스트 기반 브라우저, 시각 장애인을 위한 브라우저와 1997년 이전에 출시된 모든 브라우저 등이 있습니다. 현재 시점에서 대부분의 웹 서비스가 지원 목록에 포함시키는 브라우저는 넓게 잡아도 IE 10버전 정도로 Ajax가 지원되는 IE 5 버전과는 큰 차이가 있을 뿐더러 IE 자체의 지원도 종료되면서 사실상 생각할 필요가 없는 수준이 되었습니다.
또한 시각 장애인을 위한 브라우저 대신 기존 브라우저에서 확장 프로그램으로 올려 사용할 수 있는 스크린 리더 서비스가 많이 출시되어있기 때문에, 이를 위한 웹 접근성을 지켜준다면 이 또한 고려 대상이 아니게 됩니다.
페이지 이동없이 통신이 이루어져 보안상의 문제가 생긴다?
클라이언트에서 통신이 이루어지면 서버에서 모든 작업을 처리할때보다 보안상의 문제가 생길 여지가 상대적으로 많아집니다. 다만 서버에서 모든 작업을 처리하면 보안상으로 반드시 안전하다고 확신할 수 없을 뿐더러, Ajax가 주는 장점을 포기하면서까지 클라이언트 통신을 하지 않을 이유로는 충분하지 않아 보입니다. 물론 경우에 따라 다른 상황이 될 순 있겠지만 현재의 절대 다수를 차지하는 웹 서비스가 고려할만한 단점은 아닙니다.
요청을 남발하면 서버의 부하가 늘 수 있다?
요청을 남발하는 경우는 애초에 코드가 잘못 작성되었거나 오류가 발생한 것을 전제로 합니다. 이는 비단 클라이언트 뿐의 문제가 아니며, 서버에서도 잘못된 코드로 인해 자체적으로 부하가 가해질 수 있으므로 적절하지 않은 반례입니다.
동일 출처 정책으로 인해 다른 도메인과는 통신이 불가능하다?
동일 출처 정책(Same-Origin Policy)는 많은 프론트 개발자들을 괴롭게 만들었습니다. 저도 얼마전까지 교차 출처 리소스 공유, 악명 높은 CORS에 치이며 마음이 아팠던터라 어떤 마음일지 공감은 됩니다.
다만 이러한 동일 출처 정책의 경우 단점이라고 볼 수는 없습니다. 다른 도메인과의 통신을 자유롭게 허용해주게되면 언제 어디서 악의적인 공격자에게 문서가 오염될지 알 수 없습니다. 따라서 이러한 정책들은 브라우저 단에서 잠재적인 위협을 방지해주는 고마운 정책이라고 볼 수 있습니다.
그럼에도 귀찮은건 맞습니다
현재
위에서 언급한 것처럼, Ajax는 장점이 명확하고 시간이 흐르며 단점 또한 의미를 잃어버린 기술이기에 현재는 대부분의 웹 사이트에서 사용하고 있습니다. 다만 초기에 Ajax를 사용함에 있어서 사용성을 위해 호환성과 웹이 갖추어야 할 표준, W3C의 철학등을 포기하면서까지 적용해야 하는지에 대해서는 많은 논의와 비판적인 시각이 있었습니다. 새로운 기술의 등장에 대한 일종의 과도기였던 셈이네요.
그 당시를 기준으로 본다면 충분히 납득할 수 있는 의견들이었고, 해당 기술이 충분히 자리잡고 이후 웹에 뛰어든 입장에서 보아도 새로운 인사이트를 주는 경우가 많아서 개인적으로 굉장히 인상 깊었습니다. 이 글을 쓰며 보았던 문서들의 링크는 아래 참고 문서에 남겨두겠습니다.
다음에는 이러한 Ajax를 구현하기 위해 자바스크립트에서 어떤 방법들을 사용해왔고, 지금은 어떻게 발전하게 되었는지 더 구체적인 내용을 담아보도록 하겠습니다.
읽어주셔서 감사합니다.
참고 문서
웹 2.0, 기타 등등, 그리고 한국의 웹 (1) - 남세동님
'이론 > Frontend' 카테고리의 다른 글
| Yarn PnP가 Typescript를 인식하지 못할때 (0) | 2023.02.25 |
|---|---|
| 웹 표준에 대한 고찰 (0) | 2023.02.15 |
| 리액트에서 기본 컴포넌트를 만들때 (1) | 2022.12.22 |
| Canvas API 사용해보기 (4) | 2022.12.09 |
| Context API 개념 잡기 (0) | 2022.11.22 |
댓글