Ajax 를 이용한 비동기식 통신에 관한 정리……

Ajax 를 이용한 비동기식 통신.

 

겉모습으로는 전체적인 Page Refresh 가 일어나지 않으면서 통신을 이루어지게 하는 것 처럼 보이지만, 실상은 보이지 않는 영역에서 iframe 을 이용해 get 또는 post 를 하고, 해당 결과 값을 다시 읽어 들여 처리를 이어가는 방식으로 구현이 된다.

 

문제는 본래의 웹 특징에서 발생한다.

 

우리가 사용하는 웹 서비스란 놈은 참으로 클라이언트 쪽으로 일방적이다 싶을 정도로 편협해 있는 놈이라서 클라이언트의 요청이 없는 이상은 클라이언트에게 지시를 하지도, 메세지를 보내지도 못한다. 더욱이 웃긴 사실은 이 클라이언트 놈은 웹 페이지를 요청해놓고서 내용만 받아버리면 연결을 끊어버린다.

 

사실상 웹 서버에서는 이 놈이 접속을 해 있는건지, 페이지를 요청하긴 했는데 계속 보고 있는건지, 진작에 닫아버리고 딴짓하고 있는지 확인할 방법이 없다.

 

하지만 실질적으로 서비스를 위해 필요한 기능이다보니, iframe 을 만들고, 그 안에 서버에 전송할 데이터를 담을 폼을 만들고서 값을 다음에 post 를 해버린다. 그리고 iframe 안에서 결과 값을 받아와 refresh 가 이루어진 뒤에 남은 결과 값을 가지고 추가적인 작업을 진행하게 된다.

 

그런데 여기서 사실상 정말 마음에 들지 않는 현상이 일어난다. post 를 한거 까진 좋은데 refresh가 일어났고 해당 작업이 완료되었다는 사실을 인식할 방법이 없다는 거다. 그래서 또 reflesh 시에 나타나게 될 response 에 parent 에 접근하게 되는 javascript 를 첨부하여 보내거나 timer 를 돌리는 추가적인 작업이 들어간다.

 

사실상 실질적인 값의 전송과 수신은 iframe 안에서 이루어지고 실질적으로 메인 페이지 에서는 단지 그 iframe 을 조작하여 값을 얻어오는 부분과, 그 값을 바탕으로 보여지고 있는 부분에 대한 값을 바꿔주는 부분, 현재 화면에서 이벤트가 일어나면 그에 대한 처리를 진행하고 값을 다시 iframe 에서 넘겨 전송하는 과정의 연속인 것이다.

 

이런 불편함을 좀 해소하고자 우리나라에서는 대대적으로 ActiveX 라는 것을 소위 "떡칠" 하는 웹서비스를 구성해왔다. 이 녀석은 사실상 Ajax 개념이 정리 되기 이전, 그리고 웹 기술이 지금의 수준에조차 미치지 못했을 때, 이러한 통신의 문제점을 해결하기 위한 하나의 방편으로 효과적인 대체안이였다.

 

그러나 시간이 흐른 지금 이 ActiveX 는 각광 받지 못하고 있고, 보다 넓은 환경으로의 진보를 막고 있는 거치적 거리는 요소로 전락해가고 있다. 이유인즉 웹 브라우저 호환성을 충족 시키지 못하고 Internet Explorer 를 사용할 것을 무언적으로 요구하고 있기 때문이다. 덕분에 외국에서는 Internet Explorer 사용율이 급감한 데에 비해 우리나라에서만 아직도 사용율이 90% 이상을 차지하는 기현상을 나타내고 있다.

 

물론, 인터넷이 많이 보급화 되어 있는 것에 비해 기대치에 비해 컴퓨터 활용 능력이 그리 높지 못하는 것도 그 이유중에 하나 이겠지만, (게임이나 오락을 즐기고 단순한 웹서핑을 하는 것은 누구나 할 수 있지만 정작 기기를 다루거나 보다 나은 툴이나 도구를 이용하는데에는 인색하기 때문이 아닌가 하고 추측하고 있다) 아무튼 이러한 요소가 많은 장애가 되는 것은 사실이다.

 

이야기가 다소 옆으로 새었지만, 다시 본론으로 돌아와서, Ajax를 이용한 통신은 재대로 활용하고 구축하지 못한다면 사실상 실시간이라고 표현은 하더라도 실시간이 아니게 된다.

 

무엇보다 중요한것은 보안인데, 거의 주축이 되는 부분이 자바스크립트이기 때문이다.

 

왜 자바스크립트와 보안이 중요한 부분이 되고 문제가 될 수 있는 부분일까? 그것 바로 클라이언트 기반에서 모든 기능이 돌아간다는 데 있다. 클라이언트 메모리에 값이 담기게 되고 하다보니, 디버깅이나 메모리를 감시하거나 제어하는 것으로 값의 조작이 가능하고 함수의 호출 순서조차 변경이 가능하다.

 

요컨데 디버깅을 통해 브레이크를 걸어두고 메모리를 감시하면, 서버에서 받아온 값이 무엇이고, 서버에 값이 어떤식으로 전송이 되는지 확인해서 변위, 조작을 할 수 있다는 것이다. 이는 보안과 관련된 문제이다 보니 예민할 수 밖에 없다.

 

근래에 들어 OPENAPI 가 등장하고 일부 서버에 대한 요청과 값 전송 등이 일부 공개되는 API 형태가 등장했지만, 여기에서 요구되는 API Key 나 Referrer 가 등장하게 된 게 바로 이러한 이유에서 기인한다.

 

---

2012. 09. 03 Kinesis 작성.