[아이티센 부트캠프] AJAX

이언덕·2026년 4월 17일
ajax

아이티센 부트캠프

목록 보기
55/115
post-thumbnail

1. AJAX가 왜 필요한가

AJAX는 현재 화면을 그대로 둔 채 서버와 데이터를 주고받고, 필요한 부분만 다시 바꾸는 방식이다.
처음 보면 이름도 낯설고 코드도 길어서 어렵게 느껴질 수 있다.
하지만 이 단계에서 가장 먼저 이해해야 할 것은 문법이 아니라 왜 이런 방식이 필요했는지이다.


초보자가 AJAX를 어려워하는 가장 큰 이유는 XMLHttpRequest, onload, JSON.parse() 같은 코드가 먼저 눈에 들어오기 때문이다.
그런데 이런 코드는 전부 목적이 있어서 등장한다.
즉, AJAX는 새로운 문법을 외우는 주제가 아니라, 기존 웹 방식의 불편함을 줄이기 위해 나온 방식이라고 먼저 이해해야 한다.
코드를 먼저 외우면 예제가 조금만 바뀌어도 다시 헷갈리기 쉽다.
반대로 필요성을 먼저 이해하면 뒤에 나오는 코드도 훨씬 자연스럽게 읽힌다.


기존 방식에서는 무엇이 불편했는가

웹 페이지는 사용자가 링크를 누르거나 버튼을 누르거나 폼을 제출하면 서버에 요청을 보낸다.
그리고 서버는 그 요청 결과를 담은 문서를 다시 브라우저에 보낸다.
브라우저는 그 문서를 받아 화면 전체를 다시 보여 준다.


이 방식은 구조가 단순해서 처음에는 이해하기 쉽다.
요청을 보내면 결과 화면이 다시 나오기 때문이다.
하지만 문제는 바꾸고 싶은 것은 일부 내용뿐인데도, 실제 동작은 페이지 전체가 다시 바뀌는 흐름이 자주 생긴다는 점이다.


예를 들어 댓글 목록 하나만 다시 보여 주고 싶을 수 있다.
로그인 성공 여부만 한 줄로 알려 주면 되는 경우도 있다.
영화 순위 표에서 데이터 일부만 다시 채우면 충분한 상황도 있다.
그런데 기존 방식에서는 이런 상황에서도 페이지 전체가 다시 열리는 느낌이 생기기 쉽다.


사용자 입장에서는 작업 흐름이 끊긴다고 느끼기 쉽다.
보고 있던 위치가 사라질 수도 있다.
입력하던 흐름이 중간에 끊길 수도 있다.
즉, 필요한 것은 작은 변경인데 실제 동작은 더 크게 보이기 쉽다.


초보자 기준에서는 이렇게 이해하면 가장 쉽다.
기존 방식은 문서 전체를 다시 받는 느낌이다.
반면 AJAX는 필요한 데이터만 다시 받는 느낌이다.
이 차이를 먼저 머릿속에 넣어 두면 뒤의 설명이 훨씬 쉬워진다.


AJAX는 무엇을 바꾼 것인가

AJAX도 결국 서버와 통신한다.
즉, 서버에 요청을 보내고 응답을 받는다는 기본 구조 자체는 그대로다.
달라지는 것은 서버와 통신하느냐 아니냐가 아니라, 응답 결과를 화면에 반영하는 방식이다.


기존 방식은 서버가 새 문서 전체를 다시 보내고, 브라우저가 그 문서로 화면 전체를 다시 보여 주는 흐름에 가깝다.
반면 AJAX는 서버에서 필요한 데이터만 받아 오고, 이미 열려 있는 화면 안에서 필요한 위치만 다시 바꾼다.
즉, 통신은 그대로 하되 화면 처리 방식이 달라진 것이다.


예를 들어 댓글 목록만 다시 받아 아래 영역에 넣을 수 있다.
로그인 성공 여부만 메시지로 보여 줄 수 있다.
영화 순위 데이터만 다시 받아 표 본문만 바꿀 수도 있다.
이미지 한 장만 더 받아 현재 화면에 이어 붙일 수도 있다.
이처럼 화면 전체를 흔들지 않고도 필요한 부분만 다시 그릴 수 있게 된다.

즉, AJAX의 핵심은 새 페이지로 이동하는 것이 아니라, 현재 페이지 안에서 필요한 데이터만 다시 가져와 필요한 위치에 반영하는 것이다.
이 말을 더 쉽게 풀면, AJAX는 화면을 통째로 바꾸는 방식이 아니라 필요한 부분만 고쳐서 다시 보여 주는 방식이다.

이 두 이미지를 같이 보면 차이가 더 분명해진다.
기존 방식은 요청 뒤에 화면 전체가 다시 바뀌는 흐름이고, AJAX는 현재 화면을 유지한 채 필요한 부분만 갱신하는 흐름이다.
즉, 둘의 차이는 통신 자체보다 결과를 어디까지 다시 그리느냐에 있다.


왜 현재 화면을 유지하는 것이 중요한가

처음에는 “새로고침이 덜 된다” 정도로만 생각할 수 있다.
물론 그것도 맞다.
하지만 더 중요한 것은 사용자의 작업 흐름이 덜 끊긴다는 점이다.


사용자는 보통 하나의 작업을 이어서 하고 있다.
댓글을 읽고 있을 수도 있다.
검색 결과를 확인하고 있을 수도 있다.
로그인 입력을 마무리하는 중일 수도 있다.
이때 화면 전체가 다시 바뀌면 사용자는 지금 하던 흐름이 한 번 끊긴다고 느끼기 쉽다.


반대로 필요한 부분만 바뀌면 같은 화면 안에서 작업이 이어지는 느낌을 받는다.
이 차이는 단순히 보기 좋은 정도의 문제가 아니다.
웹 페이지를 더 자연스럽고 편하게 느끼게 만드는 중요한 차이다.
그래서 AJAX는 단순한 통신 기술이 아니라, 화면을 더 부드럽게 동작하게 만드는 방식이라고도 이해할 수 있다.


왜 이 개념을 먼저 알아야 하는가

초보자가 AJAX를 처음 배울 때 가장 많이 하는 실수는 XMLHttpRequest, onload, responseText, JSON.parse() 같은 코드 조각을 먼저 외우려는 것이다.
하지만 왜 이런 코드가 필요한지 이유를 모르면 예제가 조금만 바뀌어도 다시 낯설어진다.


반대로 지금 단계에서 AJAX의 목적을 먼저 이해해 두면 코드가 훨씬 자연스럽게 읽힌다.
버튼을 눌렀을 때 왜 페이지 전체가 아니라 div 하나만 바뀌는지 이해할 수 있다.
로그인 결과가 왜 새 페이지로 이동하지 않고 메시지 한 줄로만 보이는지 이해할 수 있다.
표 데이터가 왜 다시 채워지는지, 이미지가 왜 현재 화면에 계속 추가되는지도 연결된다.


즉, 지금 단계에서는 AJAX를 어려운 통신 기술이라고 보기보다 현재 화면을 유지하면서 필요한 부분만 다시 그리기 위한 방식이라고 이해하는 것이 가장 중요하다.
이 기준이 잡혀 있어야 뒤의 모든 예제가 하나의 흐름으로 이어진다.


여기서 꼭 기억할 핵심

기존 방식은 결과를 새 문서 전체로 다시 보여 주기 쉽다.
AJAX는 필요한 데이터만 받아 현재 화면 일부만 다시 바꾼다.
이 차이가 AJAX를 배우는 출발점이다.



2. 기존 웹 통신과 AJAX 웹 통신의 차이

AJAX가 왜 필요한지 이해했다면, 이제는 기존 웹 통신과 AJAX 웹 통신을 나란히 비교해 보면 된다.
두 방식 모두 결국은 브라우저와 서버가 요청과 응답을 주고받는다는 점에서는 같다.
하지만 응답을 어떤 형태로 받고, 그 결과를 화면에 어떻게 반영하느냐에서 큰 차이가 난다.


즉, 이 파트는 새로운 개념을 더 늘어놓는 구간이 아니다.
앞에서 본 내용을 비교 형태로 다시 정리해서, 머릿속 기준을 더 분명하게 만드는 구간이다.
기존 웹 통신은 응답 결과가 새 문서 전체에 가까운 경우가 많다.
반면 AJAX 웹 통신은 응답 결과가 필요한 데이터에 더 가깝다.
이 차이를 정확히 잡아 두면 뒤 예제들이 훨씬 덜 헷갈린다.


기존 웹 통신은 화면 전체가 다시 바뀌기 쉽다

기존 웹 통신에서는 사용자가 요청을 보내면 서버가 그 결과를 담은 새로운 문서를 다시 만들어 보낸다.
브라우저는 그 응답을 받아 현재 화면을 새로 보여 준다.
그래서 사용자는 요청을 보낸 뒤 결과로 화면 전체가 다시 바뀌는 느낌을 받기 쉽다.


예를 들어 링크를 클릭하면 다른 페이지로 이동한다.
검색 버튼을 누르면 검색 결과 화면이 다시 열린다.
폼을 제출하면 처리 결과가 담긴 새 화면이 나타난다.
이런 흐름은 구조가 단순해서 처음에는 이해하기 쉽다.
요청을 보내고 결과 화면을 받는 흐름이 눈에 바로 보이기 때문이다.


하지만 문제는 필요한 범위보다 더 크게 다시 움직인다는 점이다.
결과 메시지 한 줄만 바꾸면 되는 상황인데도 페이지 전체가 다시 열릴 수 있다.
목록의 일부만 다시 받아 오면 되는 상황인데도 화면 전체 흐름이 끊길 수 있다.
즉, 필요한 것은 작은 결과인데 사용자는 마치 새 화면을 다시 받는 것처럼 느끼게 된다.


초보자 기준에서는 이렇게 이해하면 쉽다.
기존 웹 통신은 데이터 하나를 받는다기보다 결과 화면 하나를 다시 받는 흐름에 가깝다.
그래서 사용자는 같은 작업을 이어 가는 느낌보다, 다른 화면으로 넘어가는 느낌을 더 강하게 받게 된다.


이 이미지는 기존 웹 통신이 어떻게 동작하는지 큰 흐름으로 보여 준다.
브라우저가 요청을 보내고, 서버가 새로운 페이지 결과를 다시 돌려주면, 브라우저는 그 결과 화면 전체를 다시 보여 주는 구조다.
즉, 응답 결과가 현재 화면 일부가 아니라 새 문서 전체에 가깝다는 점이 핵심이다.


AJAX 웹 통신은 현재 화면 일부만 바꾼다

AJAX도 여전히 서버와 통신한다.
즉, 브라우저가 요청을 보내고 서버가 응답을 돌려준다는 기본 원리는 같다.
하지만 서버가 항상 새 화면 전체를 다시 만들어 보내는 것은 아니다.
대신 필요한 데이터만 응답으로 보내고, 브라우저는 그 데이터를 받아 현재 화면 안의 필요한 부분만 다시 바꾼다.


이 차이가 중요하다.
기존 방식이 새 화면 결과를 다시 받아 보여 주는 흐름에 가깝다면, AJAX는 필요한 데이터를 받아 현재 화면에 반영하는 흐름에 가깝다.
그래서 사용자는 새로운 페이지로 넘어간 느낌보다, 같은 화면 안에서 내용 일부만 자연스럽게 바뀌는 느낌을 받는다.


예를 들어 댓글 목록만 다시 받아 아래 영역에 넣을 수 있다.
로그인 성공 여부만 메시지로 보여 줄 수 있다.
영화 순위 데이터만 다시 받아 표 본문만 바꿀 수 있다.
즉, 화면 전체를 흔들지 않고 필요한 부분만 다시 갱신할 수 있게 된다.


AJAX는 통신 자체를 없앤 것이 아니라, 통신 결과를 현재 화면 일부에만 반영할 수 있게 만든 방식이다.
즉, 서버와의 요청과 응답은 그대로 유지하면서도, 화면 처리 방식이 훨씬 더 유연해진 것이다.


이 이미지는 AJAX 웹 통신 구조를 보여 준다.
브라우저 안에서 AJAX 엔진이 서버와 비동기적으로 통신하고, 필요한 데이터만 받아 현재 화면 일부를 갱신하는 흐름이다.
그래서 페이지 전체가 다시 열리는 대신, 필요한 부분만 자연스럽게 바뀌게 된다.


둘의 차이를 가장 쉽게 비교하면

초보자 기준에서는 아래처럼 이해하면 가장 쉽다.

  • 기존 웹 통신
    요청을 보내면 서버가 새 화면 결과를 다시 보내고, 브라우저는 화면 전체를 다시 보여 준다.

  • AJAX 웹 통신
    요청을 보내면 서버가 필요한 데이터만 보내고, 브라우저는 현재 화면 일부만 다시 바꾼다.

여기서 중요한 것은 둘 다 서버와 통신한다는 점이다.
차이는 통신 자체가 아니라 응답 결과를 화면에 반영하는 범위에 있다.
즉, 전체 화면을 다시 그리느냐, 필요한 부분만 다시 그리느냐가 핵심이다.


이 차이를 더 단순하게 말하면 이렇다.
기존 웹 통신은 결과 페이지를 다시 받는 방식이다.
AJAX 웹 통신은 결과 데이터만 받아 현재 화면에 끼워 넣는 방식이다.
이 기준이 머릿속에 잡혀 있어야 뒤의 XML, JSON, POST, 외부 API 예제들도 모두 같은 흐름으로 읽힌다.


왜 이 비교가 중요한가

초보자는 AJAX를 배우면 무조건 새로운 기술이라고 느끼기 쉽다.
하지만 실제로는 완전히 다른 세상이 아니라, 기존 웹 통신 방식에서 화면 반영 방식을 더 세밀하게 바꾼 것에 가깝다.
즉, 서버와 통신하는 큰 구조는 그대로인데, 응답을 다루는 방식이 달라진 것이다.


이 비교를 먼저 정확히 해 두어야 뒤의 예제에서 왜 어떤 것은 새 페이지로 이동하고, 어떤 것은 같은 화면 안에 결과가 붙는지 바로 이해할 수 있다.
또 왜 AJAX 예제에서는 div, tbody, output 같은 특정 영역만 바꾸는 코드가 자주 나오는지도 자연스럽게 연결된다.


정리하면 기존 웹 통신은 새 문서 전체를 다시 보여 주는 흐름에 가깝고, AJAX는 필요한 데이터만 받아 현재 화면 일부를 갱신하는 흐름에 가깝다.
즉, 둘의 핵심 차이는 응답 결과를 어디까지 다시 그리느냐에 있다.



3. 동기와 비동기

AJAX를 이해할 때 가장 많이 헷갈리는 개념이 동기와 비동기다.
단어만 보면 어렵게 느껴질 수 있지만, 뜻은 생각보다 단순하다.
핵심은 요청을 보낸 뒤 결과가 올 때까지 기다리느냐, 아니면 요청을 먼저 보내 두고 결과가 오면 그때 처리하느냐의 차이다.


초보자는 이 개념을 속도 차이로 오해하기 쉽다.
하지만 여기서 중요한 것은 빠르다, 느리다가 아니다.
정말 중요한 것은 작업이 이어지는 방식이다.
즉, 앞의 요청이 끝날 때까지 현재 흐름이 멈추는지, 아니면 요청을 보내 놓고 다른 흐름을 이어 가다가 응답이 오면 그때 처리하는지가 핵심이다.


동기는 기다렸다가 다음으로 간다

동기는 요청을 보내면 그 결과가 올 때까지 기다리고, 응답이 끝난 뒤에야 다음 단계로 넘어가는 방식이다.
쉽게 말하면 앞 작업이 끝나야 뒤 작업으로 갈 수 있는 흐름이다.


이 말을 웹에서 생각해 보면 이해가 쉽다.
사용자가 어떤 요청을 보냈을 때 서버가 응답을 돌려줄 때까지 기다린 뒤, 그 결과 화면을 확인하는 방식이 여기에 가깝다.
즉, 요청과 응답이 하나의 묶음처럼 이어지고, 앞 단계가 끝나기 전에는 다음 흐름으로 자연스럽게 넘어가기 어렵다.


예를 들어 링크를 눌렀을 때 새 페이지가 열릴 때까지 기다리는 상황을 떠올리면 된다.
폼을 제출한 뒤 결과 화면이 다시 나올 때까지 현재 흐름이 멈춘 것처럼 느껴지는 상황도 비슷하다.
이런 흐름은 구조가 단순해서 처음에는 이해하기 쉽다.
하지만 사용자는 그동안 결과를 기다려야 하고, 화면 전체가 다시 바뀌는 느낌을 더 강하게 받게 된다.


초보자 기준에서는 이렇게 이해하면 된다.
동기는 “끝날 때까지 기다렸다가 다음으로 간다”이다.
즉, 앞의 작업이 끝나야 뒤의 작업을 이어 갈 수 있는 구조다.


이 이미지는 동기와 비동기를 비교하는 기본 개념도다.
여기서 동기는 요청과 응답이 한 줄로 이어지면서, 앞 작업이 끝나야 다음 작업으로 넘어가는 흐름으로 보면 된다.


이 이미지는 고전적인 웹 통신이 왜 동기 흐름으로 느껴지는지 보여 준다.
브라우저가 요청을 보내고, 서버가 응답을 돌려준 뒤, 그 결과로 새 화면이 다시 열리는 흐름이기 때문이다.


비동기는 먼저 보내고 나중에 처리한다

비동기는 요청을 먼저 보내고, 결과가 바로 오지 않아도 현재 흐름을 완전히 멈추지 않는 방식이다.
응답이 도착하면 미리 연결해 둔 함수가 실행되어 그때 결과를 처리한다.
그래서 AJAX 코드에서는 onload, 콜백 함수, 이벤트 처리 같은 개념이 함께 나온다.


초보자 기준에서는 이렇게 이해하면 된다.
동기가 “끝날 때까지 기다렸다가 다음으로 간다”라면, 비동기는 “일단 요청을 보내 두고, 결과가 도착했을 때 그때 처리한다”이다.
즉, 요청을 보낸 순간 바로 결과를 쓰는 것이 아니라, 응답이 도착했을 때 실행될 처리 코드를 따로 준비해 두는 구조다.


이 방식이 중요한 이유는 화면 전체를 멈춘 것처럼 다루지 않아도 되기 때문이다.
사용자는 같은 화면을 보고 있는 상태에서 다른 내용을 계속 확인할 수 있다.
그리고 응답이 도착하면 그때 필요한 부분만 바뀌게 된다.
즉, 전체 흐름을 한 번 끊고 새 페이지를 여는 방식과는 느낌이 다르다.


예를 들어 버튼을 눌렀을 때 서버에 요청은 먼저 보내지만, 페이지 전체가 다시 열리지는 않는다.
응답이 도착하면 div 안의 문장만 바뀔 수 있다.
로그인 요청을 보내도 응답이 올 때 현재 화면 안에서 성공 또는 실패 메시지만 보여 줄 수 있다.
이처럼 비동기는 요청과 화면 갱신을 분리해서 처리할 수 있게 해 준다.


이 이미지는 AJAX 웹 통신이 왜 비동기 흐름으로 이해되는지 보여 준다.
브라우저가 요청을 보낸 뒤 페이지 전체를 다시 여는 것이 아니라, 응답이 도착했을 때 필요한 데이터만 받아 현재 화면 일부를 갱신하는 구조다.


기본예제로 비동기 흐름 먼저 확인하기

AJAX 코드를 바로 보기 전에, 먼저 “나중에 실행되는 코드”가 어떤 느낌인지 작은 예제로 확인하면 이해가 쉽다.
아래 예제는 서버 요청을 실제로 보내지는 않는다.
대신 setTimeout()을 사용해서 결과가 나중에 도착하는 상황을 흉내 낸다.


중요한 점은 코드가 위에서 아래로 작성되어 있어도, 실행 결과가 반드시 코드 작성 순서 그대로 나오지는 않는다는 것이다.
setTimeout() 안의 코드는 정해진 시간이 지난 뒤 실행된다.
그래서 비동기 흐름에서는 “요청을 보냈다”와 “결과를 처리한다”가 서로 떨어져 있을 수 있다.

// basic_async.html
<body>
	<button onclick="startWork()">작업 시작</button>
	<div id="result"></div>

	<script>
		function startWork() {
			const result = document.getElementById("result");

			result.innerHTML += "<p>1. 요청을 보냈다.</p>";

			// 데이터 흐름: 요청을 먼저 보낸 뒤, 결과는 나중에 도착했다고 가정한다.
			setTimeout(function() {
				result.innerHTML += "<p>3. 결과가 도착해서 화면에 반영됐다.</p>";
			}, 2000); // 2초 뒤에 실행

			result.innerHTML += "<p>2. 결과를 기다리는 동안 다음 코드가 먼저 실행됐다.</p>";
		}
	</script>
</body>
// 출력결과
// 1. 요청을 보냈다.
// 2. 결과를 기다리는 동안 다음 코드가 먼저 실행됐다.
// 3. 결과가 도착해서 화면에 반영됐다.

이 예제에서 3. 결과가 도착해서 화면에 반영됐다.가 마지막에 출력되는 이유는 setTimeout() 안의 코드가 나중에 실행되기 때문이다.
즉, 결과 처리는 요청을 보낸 바로 다음 줄에서 일어나는 것이 아니라, 결과가 도착했다고 볼 수 있는 시점에 따로 실행된다.


이 흐름을 이해하면 뒤에서 xhr.onload를 볼 때 훨씬 덜 헷갈린다.
xhr.onload도 같은 느낌으로 이해하면 된다.
요청을 보낸 뒤 응답이 도착하면, 그때 onload 안의 코드가 실행된다.


AJAX가 왜 비동기라고 불리는가

AJAX는 서버와 통신할 때 응답이 오면 그 결과를 나중에 처리하는 구조를 자주 사용한다.
예를 들어 버튼을 눌렀을 때 바로 새 페이지로 이동하는 것이 아니라, 요청을 먼저 보내고 응답이 오면 div 안에 결과를 넣는다.
또는 일정 시간마다 요청을 보내고, 응답이 올 때마다 뉴스 문장만 바꾼다.
또는 로그인 결과가 도착했을 때 성공 메시지나 실패 메시지만 보여 준다.


이 흐름은 모두 공통점이 있다.
바로 응답이 도착했을 때 그때 처리한다는 점이다.
그래서 AJAX는 Asynchronous, 즉 비동기라는 말을 이름에 포함하고 있다.
A가 바로 이 Asynchronous를 뜻한다.


여기서 중요한 점은 AJAX가 무조건 더 빠르다는 뜻이 아니라는 것이다.
실제로 서버 응답 속도 자체는 상황에 따라 다를 수 있다.
핵심은 속도가 아니라 기다리는 방식이 다르다는 점이다.
즉, AJAX는 응답을 기다리는 동안 페이지 전체를 새로 열어 버리는 흐름 대신, 응답이 오면 그때 필요한 부분만 처리할 수 있게 해 준다.


즉, AJAX가 비동기라고 불리는 이유는 응답을 기다리는 동안 흐름을 한 번에 묶어 두지 않고, 응답이 도착했을 때 결과를 처리하는 구조를 사용하기 때문이다.


왜 이 차이를 꼭 이해해야 하는가

초보자가 AJAX 코드에서 가장 많이 헷갈리는 부분 중 하나가 왜 결과 처리를 바로 아래에서 하지 않고 onload 안에서 하는지이다.
이유는 단순하다.
요청을 보냈다고 해서 응답이 즉시 손에 들어오는 것이 아니기 때문이다.
응답은 나중에 도착할 수 있고, 그 도착 시점에 맞춰 처리해야 한다.


그래서 AJAX 코드에서는 요청을 보내는 부분과 응답을 처리하는 부분이 나뉘어 있는 경우가 많다.
처음에는 이 구조가 낯설 수 있다.
하지만 비동기 개념을 이해하면 왜 코드가 그렇게 생겼는지 자연스럽게 보인다.
send()는 요청을 보내는 역할이고, onload는 응답이 도착했을 때 실행되는 역할이라는 흐름이 머릿속에 들어오게 된다.


즉, 동기와 비동기는 단순히 용어 하나를 외우는 문제가 아니다.
AJAX 코드가 왜 그렇게 생겼는지를 이해하기 위한 핵심 기준이다.
이 기준이 잡혀 있어야 뒤의 예제에서 왜 어떤 코드는 바로 결과를 쓰지 않고, 응답 처리 함수를 따로 두는지 헷갈리지 않게 된다.


여기서 꼭 기억할 핵심

동기는 끝날 때까지 기다렸다가 다음으로 가는 방식이다.
비동기는 요청을 먼저 보내고, 응답이 도착했을 때 그때 처리하는 방식이다.
AJAX는 바로 이 비동기 흐름으로 현재 화면 일부를 갱신하는 데 강점을 가진다.



4. AJAX의 동작 순서

AJAX 코드를 처음 보면 xhr를 만들고, open()을 호출하고, send()를 하고, onload 안에서 결과를 처리하는 흐름이 한꺼번에 나와서 복잡해 보인다.
그래서 초보자는 코드 한 줄 한 줄만 보다가 전체 흐름을 놓치기 쉽다.
하지만 실제로는 어떤 예제든 거의 같은 순서로 움직인다.


즉, AJAX는 매번 완전히 다른 방식으로 동작하는 것이 아니다.
겉으로 보이는 예제가 달라도 안쪽 흐름은 반복된다.
그래서 본문 예제로 내려가기 전에, 먼저 AJAX의 기본 순서를 머릿속에 고정해 두는 것이 중요하다.
이 순서만 잡혀 있으면 뒤의 XML, JSON, POST, 외부 API 예제도 훨씬 덜 헷갈린다.


AJAX는 어떤 순서로 움직이는가

AJAX의 기본 흐름은 다음과 같다.

  • 이벤트 발생
  • JavaScript 함수 실행
  • XMLHttpRequest 객체 생성
  • 서버로 요청 전송
  • 서버가 응답 반환
  • 콜백 함수 실행
  • 현재 화면 일부 갱신

이 순서를 보면 복잡한 기능이 많은 것처럼 보여도, 실제로는 “시작 → 요청 → 응답 → 화면 반영” 흐름으로 정리할 수 있다.
즉, AJAX는 결국 서버와 통신한 뒤 그 결과를 현재 화면 일부에 반영하는 과정이다.


초보자 기준에서는 이 순서를 더 짧게 이렇게 기억해도 된다.
이벤트가 시작되고, 요청을 보내고, 응답을 받은 뒤, 화면에 반영한다.
이 한 줄 흐름이 가장 중요하다.


이 이미지는 브라우저와 서버가 AJAX로 통신하는 큰 흐름을 보여 준다.
브라우저 안에서 요청이 만들어지고 서버로 전달된 뒤, 서버 응답이 다시 돌아오면 현재 화면의 필요한 부분만 갱신하는 구조다.
즉, AJAX는 새 페이지를 통째로 다시 여는 것이 아니라, 현재 화면 안에서 필요한 위치만 바꾸는 흐름으로 이해하면 된다.


각 단계가 실제로 무슨 뜻인지

첫 번째 단계는 이벤트 발생이다.
버튼 클릭, 페이지 로드, 일정 시간 경과 같은 사건이 시작점이 된다.
즉, AJAX는 아무 이유 없이 혼자 실행되는 것이 아니라, 어떤 사건이 일어났을 때 시작된다.


두 번째 단계는 JavaScript 함수 실행이다.
이 함수가 실제 통신 준비를 담당한다.
초보자가 예제를 볼 때는 여기서부터 AJAX 코드가 시작된다고 생각하면 된다.
보통 버튼을 눌렀을 때 특정 함수가 실행되고, 그 함수 안에서 요청 준비 코드가 이어진다.


세 번째 단계는 XMLHttpRequest 객체 생성이다.
이 객체는 브라우저 안에서 서버 요청과 응답 처리를 맡는 핵심 도구다.
쉽게 말하면 브라우저 안에서 서버와 대화하는 창구 역할을 한다.
그래서 new XMLHttpRequest()가 나오면 “지금부터 서버와 통신할 준비를 하는구나”라고 이해하면 된다.


네 번째 단계는 요청 전송이다.
여기서 open()으로 어떤 방식으로 어디에 요청할지 정하고, send()로 실제 요청을 보낸다.
즉, open()은 요청 준비이고, send()는 실제 전송이다.
이 둘의 역할을 구분해서 보는 것이 중요하다.


다섯 번째 단계는 서버 응답이다.
서버는 요청을 받은 뒤 필요한 결과를 만들어 돌려준다.
이때 응답 내용은 문자열일 수도 있고, XML, JSON, 이미지 같은 파일 데이터일 수도 있다.
즉, 서버가 어떤 형식으로 응답하느냐에 따라 뒤에서 읽는 방식도 달라진다.


여섯 번째 단계는 콜백 함수 실행이다.
응답이 도착했을 때 onload 같은 함수가 실행되어 응답을 읽는다.
그래서 AJAX 코드는 응답을 받은 뒤의 처리를 이 함수 안에서 작성하는 경우가 많다.
초보자가 이 부분을 헷갈리는 이유는 요청을 보내는 코드와 결과를 처리하는 코드가 떨어져 있기 때문이다.
하지만 이것은 비동기 흐름이라서 자연스러운 구조다.


마지막 단계는 화면 반영이다.
읽어 온 데이터를 div, 표, 메시지 영역, 이미지 영역 같은 현재 화면의 특정 위치에 넣는다.
이 단계 때문에 AJAX는 새 페이지로 이동하는 기술이 아니라, 현재 화면의 일부를 다시 바꾸는 기술로 느껴진다.
즉, 이 마지막 단계가 있어야 사용자는 “페이지가 이동했다”가 아니라 “화면 일부가 바뀌었다”라고 느끼게 된다.


기본예제로 AJAX 동작 순서 확인하기

이제 위 순서를 아주 작은 코드로 확인해 보면 된다.
이 예제는 XML, JSON, 외부 API 같은 복잡한 요소를 넣지 않는다.
버튼을 클릭하면 서버에 간단한 요청을 보내고, 응답이 도착하면 result 영역에 출력한다.


이 코드는 뒤에 나오는 응용예제들의 가장 작은 뼈대라고 보면 된다.
즉, 버튼 클릭 → 요청 준비 → 요청 전송 → 응답 도착 → 화면 반영 흐름만 확인하는 기본예제다.

// basic_ajax_order.html
<body>
	<button onclick="loadText()">문장 가져오기</button>
	<div id="result"></div>

	<script>
		function loadText() {
			// 데이터 흐름: 버튼 클릭 → 서버 요청 → 응답 도착 → result 영역 변경
			const xhr = new XMLHttpRequest(); // 서버와 통신할 객체 생성

			xhr.onload = function() {
				const result = document.getElementById("result"); // 결과를 넣을 영역 선택
				result.textContent = xhr.responseText; // 응답 문자열을 화면에 반영
			};

			xhr.open("GET", "/edu/first.html", true); // 요청 방식과 주소 준비
			xhr.send(); // 실제 요청 전송
		}
	</script>
</body>

이 기본예제에서 가장 먼저 시작되는 것은 버튼 클릭이다.
버튼을 누르면 loadText() 함수가 실행된다.
그 안에서 XMLHttpRequest 객체를 만들고, open()으로 요청 정보를 준비한 뒤, send()로 실제 요청을 보낸다.


응답이 도착하면 xhr.onload 안의 코드가 실행된다.
그리고 xhr.responseText에 들어 있는 응답 문자열을 result 영역에 넣는다.
즉, AJAX 코드는 요청을 보내는 코드와 응답을 처리하는 코드가 나뉘어 있다는 점이 중요하다.


왜 이 순서를 먼저 알아야 하는가

초보자가 AJAX 코드에서 가장 많이 길을 잃는 지점은 개별 문법에 먼저 매달릴 때다.
xhr가 뭔지, open()이 뭔지, send()가 뭔지, onload가 왜 필요한지만 따로따로 보면 코드가 조각처럼 보인다.
그러면 예제가 조금만 달라져도 다시 낯설어진다.


하지만 전체 순서를 먼저 이해하면 코드가 한 덩어리 흐름으로 보이기 시작한다.
왜 xhr를 만들었는지 이해할 수 있다.
왜 open()을 호출하는지 이해할 수 있다.
왜 send()를 하는지 이해할 수 있다.
왜 응답 처리가 onload 안에 들어가는지도 자연스럽게 이어진다.


이 순서를 이해하면 AJAX 예제는 전부 같은 틀로 읽힌다.
응답 형식이 XML이든 JSON이든, 또는 이미지 파일이든 겉모습만 다를 뿐 기본 흐름은 같다.
이벤트가 시작되고, 요청을 준비하고, 서버에 보내고, 응답이 오면 읽고, 필요한 위치에 반영한다.
겉으로는 예제가 달라 보여도 안쪽 구조는 모두 같은 순서를 따른다.


예제를 읽을 때 어디를 먼저 보면 되는가

앞으로 AJAX 예제를 볼 때는 처음부터 모든 줄을 똑같이 보지 말고, 순서대로 핵심 지점을 먼저 찾으면 훨씬 쉽다.
먼저 어떤 이벤트에서 시작하는지 본다.
그다음 어디에서 XMLHttpRequest 객체를 만드는지 본다.
그다음 open()과 send()가 어디 있는지 본다.
마지막으로 onload 안에서 어떤 화면 요소를 바꾸는지 보면 된다.


이렇게 읽으면 예제 구조가 빠르게 보인다.
즉, AJAX 코드는 길어 보여도 결국 “무엇이 시작점인지”, “어디로 요청하는지”, “응답을 어디에 넣는지”를 찾으면 전체 흐름이 잡힌다.
이 기준을 먼저 갖고 내려가면 뒤 예제들이 훨씬 쉽게 읽힌다.


여기서 꼭 기억할 핵심

AJAX는 이벤트가 시작점이 된다.
XMLHttpRequest로 요청을 준비하고 send()로 전송한다.
응답이 오면 onload 같은 콜백 함수에서 결과를 읽고 현재 화면 일부를 갱신한다.
이 순서가 AJAX 예제를 읽는 가장 기본 기준이다.



5. XMLHttpRequest 객체 이해하기

AJAX 통신에서 실제 요청을 보내는 주체가 XMLHttpRequest 객체다.
초보자는 AJAX를 하나의 새로운 문법처럼 느끼기 쉽다.
하지만 실제로는 브라우저 안에서 이 객체를 만들고, 그 객체를 통해 서버에 요청을 보내고 응답을 받는 구조다.


즉, AJAX는 마법처럼 자동으로 동작하는 기능이 아니다.
브라우저가 XMLHttpRequest 객체를 사용해서 서버와 데이터를 주고받는 방식이다.
그래서 AJAX를 이해하려면 먼저 XMLHttpRequest를 “브라우저 안의 통신 도구”로 이해하는 것이 중요하다.


XMLHttpRequest 객체를 어떻게 보면 쉬운가

처음 이름만 보면 어렵게 느껴질 수 있다.
XML, Http, Request 같은 단어가 한꺼번에 붙어 있어서 더 복잡해 보인다.
하지만 초보자 기준에서는 이름을 세세하게 분석하기보다 역할부터 잡는 것이 훨씬 쉽다.


이 객체는 브라우저 안에서 서버와 대화할 때 사용하는 도구다.
어디로 요청할지 정하고, 어떤 방식으로 보낼지 정하고, 응답이 도착하면 그 결과를 읽는 일까지 이 객체를 중심으로 이루어진다.
즉, AJAX 코드에서 가장 중심에 놓이는 도구라고 보면 된다.


쉽게 말하면 이 객체는 브라우저 안에서 서버와 통신하는 창구다.
브라우저가 직접 서버에게 말을 거는 통로라고 이해해도 된다.
그래서 예제 코드에서 const xhr = new XMLHttpRequest();가 나오면 “지금 서버와 통신할 준비를 시작하는구나”라고 받아들이면 된다.


초보자는 여기서 중요한 기준 하나만 먼저 잡으면 된다.
AJAX는 추상적인 개념이고, XMLHttpRequest는 그 개념을 실제 코드로 실행할 때 쓰는 도구다.
즉, 무엇을 하느냐가 AJAX라면, 그것을 실제로 수행하는 대표 도구가 XMLHttpRequest다.


open()과 send()는 무슨 역할을 하는가

AJAX 예제를 보면 거의 항상 open()과 send()가 같이 나온다.
그래서 초보자는 둘이 비슷한 역할을 하는 것처럼 느끼기 쉽다.
하지만 역할은 분명히 다르다.


open()은 요청 정보를 준비하는 단계다.
어떤 방식으로 요청할지, 어느 주소로 요청할지, 비동기로 보낼지를 여기서 정한다.
즉, open()은 아직 요청을 실제로 보낸 것이 아니라, 어떻게 보낼지 세팅하는 단계다.


반면 send()는 실제 요청을 보내는 단계다.
open()으로 준비만 해 두고 끝나는 것이 아니라, send()를 실행해야 브라우저가 서버로 요청을 전송한다.
그래서 초보자 기준에서는 이렇게 기억하면 가장 쉽다.
open()은 요청 준비, send()는 실제 전송이다.


이 둘을 헷갈리지 않는 것이 중요하다.
왜냐하면 AJAX 코드를 읽을 때 “지금은 요청 정보를 적는 단계인지”, “지금은 진짜로 서버에 보내는 단계인지”를 구분할 수 있어야 전체 흐름이 보이기 때문이다.
즉, open()과 send()를 구분해서 보는 순간 AJAX 코드가 훨씬 덜 복잡하게 느껴진다.


기본예제로 open()과 send() 구분하기

아래 예제는 open()과 send()의 역할만 분리해서 보기 위한 기본예제다.
버튼을 누르면 요청을 준비하고, 그다음 실제 요청을 보낸다.


중요한 점은 open()만 실행한다고 서버 요청이 끝나는 것이 아니라는 점이다.
open()은 요청 정보를 정하는 단계이고, send()가 실행되어야 실제 요청이 서버로 나간다.

// basic_open_send.html
<body>
	<button onclick="requestData()">요청하기</button>
	<div id="result"></div>

	<script>
		function requestData() {
			// 데이터 흐름: 요청 객체 생성 → 요청 정보 준비 → 실제 요청 전송 → 응답 출력
			const xhr = new XMLHttpRequest(); // 서버와 통신할 객체 생성

			xhr.onload = function() {
				document.getElementById("result").textContent = xhr.responseText; // 응답 출력
			};

			xhr.open("GET", "/edu/first.html", true); // 요청 방식과 주소만 준비
			xhr.send(); // 이 시점에 실제 요청 전송
		}
	</script>
</body>

이 예제에서 xhr.open("GET", "/edu/first.html", true);는 요청을 어떻게 보낼지 정하는 부분이다.
GET 방식으로 /edu/first.html에 요청하겠다고 준비하는 단계다.
하지만 이 줄만으로 요청이 끝나는 것은 아니다.


실제 요청은 xhr.send();가 실행될 때 서버로 전송된다.
그래서 open()과 send()는 함께 자주 나오지만 같은 역할이 아니다.
open()은 요청 준비이고, send()는 실제 전송이라는 차이를 분명히 잡아야 한다.


onload와 onreadystatechange는 왜 필요한가

서버에 요청을 보냈다고 해서 바로 결과를 읽을 수 있는 것은 아니다.
응답은 시간이 걸려서 도착할 수 있다.
그래서 응답이 도착했을 때 실행할 코드를 따로 준비해 두어야 한다.
이때 사용하는 것이 onload와 onreadystatechange다.


onload는 응답이 끝났을 때 실행되는 함수다.
그래서 예제에서는 xhr.onload = function() { ... } 안에서 결과를 읽고 화면에 넣는 경우가 많다.
초보자는 onload를 “응답이 다 도착하면 이 안의 코드가 실행된다”라고 이해하면 된다.
즉, 응답 처리용 공간이라고 생각하면 쉽다.


onreadystatechange는 통신 상태가 바뀔 때마다 실행된다.
즉, 응답이 완전히 끝났을 때만 보는 것이 아니라, 요청이 어느 단계까지 왔는지 더 자세히 확인할 수 있다.
이 방식은 상태를 세밀하게 점검해야 할 때 사용된다.


처음에는 둘 다 왜 필요한지 헷갈릴 수 있다.
하지만 초보자 단계에서는 이렇게 구분하면 충분하다.
onload는 응답이 끝났을 때 한 번 처리하는 방식이다.
onreadystatechange는 통신 상태가 바뀔 때마다 확인하는 방식이다.
이 차이만 알아도 예제를 읽는 데 큰 도움이 된다.


status와 readyState는 무엇을 뜻하는가

status는 요청이 성공했는지 실패했는지를 확인하는 값이다.
가장 자주 보는 값은 200이고, 이것은 보통 요청이 정상적으로 처리되었다는 뜻으로 이해하면 된다.
초보자는 일단 “status는 성공 여부를 보는 값”이라고 잡아 두면 충분하다.


예를 들어 응답이 왔다고 해서 무조건 정상 성공은 아닐 수 있다.
주소가 틀렸을 수도 있다.
서버에서 오류가 났을 수도 있다.
그래서 응답을 처리하기 전에 status를 확인하는 습관이 중요하다.
즉, 응답이 도착했는지와 요청이 성공했는지는 같은 말이 아니다.


readyState는 요청이 어느 단계까지 진행됐는지를 보여 주는 상태값이다.
이 값이 왜 필요한지 처음에는 잘 와닿지 않을 수 있다.
하지만 응답이 아직 다 오지 않았는데 결과를 읽으려고 하면 안 되기 때문에, 통신이 어디까지 왔는지 확인하는 기준이 필요하다.
즉, readyState는 지금 요청이 준비 중인지, 진행 중인지, 끝났는지를 알려 주는 값이다.


초보자 기준에서는 둘을 이렇게 구분하면 된다.

  • status는 결과가 성공했는지 보는 값
  • readyState는 요청이 어디까지 진행됐는지 보는 값

즉, 하나는 성공 여부, 다른 하나는 진행 상태를 확인하는 값이다.
이 둘을 구분하면 코드 안의 조건문도 훨씬 자연스럽게 읽힌다.


왜 이 객체를 먼저 이해해야 하는가

초보자는 예제를 따라 치다 보면 XMLHttpRequest를 그냥 외워야 하는 긴 문장처럼 느끼기 쉽다.
하지만 이 객체의 역할을 이해하면 예제 코드가 훨씬 단순하게 보인다.
왜 객체를 만드는지 이해할 수 있다.
왜 open()을 호출하는지 이해할 수 있다.
왜 send()를 해야 하는지 이해할 수 있다.
왜 응답 처리가 onload 안에 들어가는지도 자연스럽게 연결된다.


즉, XMLHttpRequest를 이해하면 AJAX 코드가 조각난 문법이 아니라 하나의 흐름으로 보이기 시작한다.
요청 준비 → 요청 전송 → 응답 도착 → 결과 처리라는 구조가 선명해진다.
그래서 이 객체는 단순히 외워야 할 문법이 아니라, AJAX 흐름 전체를 묶어 주는 중심 도구라고 볼 수 있다.


결국 XMLHttpRequest 객체를 이해한다는 것은 AJAX 코드가 왜 그런 순서로 작성되는지 이해한다는 뜻이다.
이 기준이 잡혀 있어야 뒤의 예제에서 비슷한 코드가 반복되어도 헷갈리지 않는다.


여기서 꼭 기억할 핵심

XMLHttpRequest는 브라우저 안에서 서버와 통신하는 도구다.
open()은 요청 준비이고, send()는 실제 전송이다.
응답이 도착하면 onload나 onreadystatechange로 결과를 처리한다.
status는 성공 여부, readyState는 진행 상태를 나타낸다.
이 기준이 잡혀 있어야 AJAX 코드 전체 흐름이 자연스럽게 읽힌다.



6. 요청과 응답을 읽는 기준

서버와 통신할 때는 두 가지를 함께 봐야 한다.
하나는 요청을 어떤 방식으로 보내는가이고, 다른 하나는 응답을 어떤 형식으로 읽는가이다.
즉, 브라우저가 서버에 무엇을 어떻게 보내는지와, 서버가 돌려준 결과를 어떤 방식으로 해석하는지를 함께 봐야 전체 흐름이 보인다.


초보자는 GET, POST, responseText, responseXML, JSON.parse(), blob을 서로 따로 외우기 쉽다.
하지만 실제로는 따로 외우면 더 헷갈린다.
왜냐하면 AJAX 코드는 항상 “어떤 요청을 보냈고, 어떤 형식의 응답이 왔는가”를 한 흐름 안에서 처리하기 때문이다.
즉, 요청 방식과 응답 읽기 방식은 따로 떨어진 개념이 아니라, 한 번의 통신 안에서 함께 움직이는 기준이다.


GET은 주로 조회할 때 많이 쓴다

GET 요청은 서버에서 데이터를 읽어 오거나 조회할 때 많이 사용한다.
브라우저 주소창으로 페이지를 요청하는 경우도 기본적으로 GET 흐름으로 이해할 수 있다.
그래서 링크 이동, 목록 조회, 외부 API 데이터 확인 같은 상황은 GET 방식과 자연스럽게 연결된다.


예를 들어 영화 순위 데이터를 가져오거나, 특정 파일 내용을 읽거나, 뉴스 목록을 다시 확인하는 상황은 GET으로 이해하기 쉽다.
즉, GET은 이미 서버에 있는 내용을 가져오는 느낌이 강하다.
새로운 값을 저장하기보다는, 있는 값을 읽어 오는 쪽에 더 가깝다.


GET은 보통 요청값이 주소에 붙어 보이는 경우가 많다.
그래서 어떤 값을 보냈는지 확인하기 쉬운 장점이 있다.
반면 주소에 값이 드러나기 쉬우므로, 중요한 입력값을 보낼 때는 항상 적합한 방식이라고 보기 어렵다.
초보자 단계에서는 일단 데이터를 조회하거나 읽어 올 때 많이 쓰는 방식으로 이해하면 된다.


POST는 입력값을 서버로 보낼 때 많이 쓴다

POST 요청은 사용자가 입력한 값을 서버로 보내 처리할 때 많이 사용한다.
예를 들어 로그인, 회원가입, 글 작성처럼 사용자가 직접 입력한 값을 담아 보내는 상황이 여기에 가깝다.
즉, 화면에서 입력한 내용을 서버에게 전달해서 어떤 처리를 맡기고 싶을 때 POST가 자주 사용된다.


POST는 요청값을 주소에 붙이는 것이 아니라, 보통 요청 본문 안에 담아 보낸다.
그래서 주소만 보고는 어떤 값을 보냈는지 바로 드러나지 않는 경우가 많다.
이 구조 때문에 POST는 입력값 전송이나 처리 요청과 더 잘 어울린다.


초보자 기준에서는 이렇게 정리하면 쉽다.
GET은 읽어 오기에 가깝다.
POST는 입력해서 보내기에 가깝다.
이 둘을 이 정도로 먼저 구분해 두면 뒤의 예제를 읽을 때 훨씬 수월하다.


Content-Type은 왜 설정하는가

서버는 요청을 받을 때 “지금 어떤 형식의 데이터가 들어왔는지”를 알아야 한다.
그래서 특히 POST 요청에서는 요청 본문에 담긴 값의 형식을 알려 주기 위해 Content-Type을 설정하는 경우가 많다.
exam5에서는 application/x-www-form-urlencoded를 설정해서 아이디와 비밀번호를 일반 폼 전송과 비슷한 형식으로 보낸다.


초보자 기준에서는 이렇게 이해하면 된다.
Content-Type은 “내가 지금 어떤 모양의 데이터를 보내고 있는지 서버에 알려 주는 정보”다.
이 설정이 있어야 서버가 요청값을 더 자연스럽게 읽을 수 있다.
즉, 값을 보내는 것만 중요한 것이 아니라, 그 값이 어떤 형식인지도 함께 알려 주어야 한다는 뜻이다.


이 부분은 처음에는 작아 보일 수 있다.
하지만 서버 입장에서는 같은 데이터라도 어떤 형식으로 왔는지에 따라 읽는 방식이 달라질 수 있다.
그래서 Content-Type은 단순한 옵션이 아니라, 요청 데이터를 올바르게 해석하게 만드는 중요한 정보다.


기본예제로 GET과 POST 요청 모양 비교하기

GET과 POST는 둘 다 서버에 요청을 보내는 방식이다.
하지만 값을 보내는 모양이 다르다.
GET은 주소에 필요한 정보가 붙는 형태로 이해하기 쉽고, POST는 send() 안에 데이터를 담아 보내는 형태로 이해하기 쉽다.


아래 예제는 실제 서버 처리 결과를 확인하기 위한 코드라기보다, 요청 모양을 비교하기 위한 기본예제다.
중요한 것은 GET과 POST가 값을 담는 위치가 다르다는 점이다.

// basic_get_post.html
<body>
	<button onclick="sendGet()">GET 요청</button>
	<button onclick="sendPost()">POST 요청</button>
	<div id="result"></div>

	<script>
		function sendGet() {
			// 데이터 흐름: 요청값을 주소 뒤에 붙여 서버에 보낸다.
			const xhr = new XMLHttpRequest();

			xhr.onload = function() {
				document.getElementById("result").textContent = xhr.responseText;
			};

			xhr.open("GET", "content/login.jsp?id=ajaxtest&passwd=12345", true); // 주소에 값 포함
			xhr.send(); // GET은 보통 send() 안을 비워 둔다
		}

		function sendPost() {
			// 데이터 흐름: 요청값을 본문 데이터로 만들어 서버에 보낸다.
			const xhr = new XMLHttpRequest();
			const requestParam = "id=ajaxtest&passwd=12345"; // 서버로 보낼 값 조립

			xhr.onload = function() {
				document.getElementById("result").textContent = xhr.responseText;
			};

			xhr.open("POST", "content/login.jsp", true); // 주소에는 처리할 대상만 작성
			xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); // 데이터 형식 지정
			xhr.send(requestParam); // POST는 보낼 값을 send() 안에 담을 수 있음
		}
	</script>
</body>

GET 요청은 content/login.jsp?id=ajaxtest&passwd=12345처럼 주소 뒤에 값이 붙어 있다.
그래서 어떤 값을 보냈는지 주소만 봐도 비교적 쉽게 확인할 수 있다.


반면 POST 요청은 주소에는 content/login.jsp만 적고, 실제 값은 requestParam에 담아 send(requestParam)으로 보낸다.
이때 서버가 요청 본문을 올바르게 읽도록 Content-Type을 함께 설정한다.
즉, GET은 주소 중심, POST는 요청 본문 중심으로 이해하면 된다.


문자열 응답은 responseText로 읽는다

가장 기본은 문자열 응답이다.
서버가 일반 텍스트나 JSON 문자열처럼 글자 형태의 응답을 보냈다면 responseText로 읽는다.
즉, 응답 본문을 문자 그대로 가져오는 방식이다.


이 말이 중요한 이유는 초보자가 JSON도 처음부터 객체로 들어온다고 오해하기 쉽기 때문이다.
하지만 실제로는 서버가 보내 준 응답이 먼저 문자열 형태로 들어오는 경우가 많다.
그래서 가장 기본 출발점은 responseText라고 이해하는 것이 좋다.


문자열 응답은 화면에 원문을 그대로 출력할 수도 있다.
또는 필요한 형태로 다시 가공해서 보여 줄 수도 있다.
즉, responseText는 “응답을 문자 형태 그대로 읽는 기본 방식”이라고 보면 된다.


XML 응답은 responseXML로 읽는다

XML은 태그 구조를 가진 문서 형식이다.
그래서 단순한 문자열처럼 한 덩어리로 보는 것보다, 문서 구조를 따라 원하는 태그를 찾아 값을 꺼내는 방식으로 읽는 것이 더 자연스럽다.
이때 사용하는 것이 responseXML이다.


즉, XML 응답은 “문자열을 그대로 읽는다”보다 “태그 구조를 가진 문서를 읽는다”에 더 가깝다.
필요한 태그를 찾아 그 안의 값을 꺼내는 방식으로 처리한다고 이해하면 된다.
예를 들어 name, age, kind 같은 태그를 찾은 뒤 그 안의 값을 꺼내 화면에 넣는 흐름이다.


초보자는 여기서 중요한 기준 하나를 잡으면 된다.
XML은 그냥 글자 덩어리가 아니라 구조를 가진 문서다.
그래서 읽는 방식도 문서 구조를 따라가야 한다.
이 점 때문에 responseText가 아니라 responseXML이 사용된다.


이 이미지는 XML이 태그 구조로 데이터를 표현한다는 점을 보여 준다.
즉, 값이 단순히 나열되는 것이 아니라 태그 안에 들어 있기 때문에, 필요한 태그를 찾아 그 안의 값을 꺼내는 방식으로 읽어야 한다.


JSON 응답은 문자열을 객체로 바꿔서 읽는다

JSON은 자바스크립트 객체와 닮은 데이터 표현 방식이다.
그래서 초보자는 처음 보면 바로 객체처럼 다룰 수 있을 것 같다고 느끼기 쉽다.
하지만 서버에서 응답으로 받을 때는 보통 먼저 문자열 형태로 들어온다.
그래서 바로 속성처럼 쓰는 것이 아니라, JSON.parse()를 사용해서 자바스크립트 객체로 바꾼 뒤 사용해야 한다.


즉, JSON 응답은 “문자열로 받는다 → 객체로 변환한다 → 필요한 값을 꺼낸다” 순서로 이해하면 된다.
이 순서를 놓치면 왜 JSON.parse()가 필요한지, 왜 바로 result.name처럼 쓰면 안 되는지 헷갈리기 쉽다.


예를 들어 영화 제목, 로그인 결과, 뉴스 문장 같은 데이터를 JSON으로 받았다고 해도, 처음에는 문자열이다.
그래서 먼저 객체로 바꾸고 나서야 obj.result, obj.news, obj.movieNm처럼 속성으로 접근할 수 있다.
즉, JSON.parse()는 선택이 아니라, 문자열을 실제로 사용할 수 있는 객체 형태로 바꾸는 중요한 단계다.


이 이미지는 JSON이 키와 값 형태로 데이터를 표현한다는 점을 보여 준다.
겉모습은 객체와 비슷하지만, 응답으로 받을 때는 먼저 문자열로 들어오기 때문에 JSON.parse()로 바꿔서 사용해야 한다는 점이 중요하다.


기본예제로 JSON.parse() 이해하기

JSON.parse()는 JSON 모양의 문자열을 자바스크립트 객체로 바꾸는 기능이다.
겉모습이 객체처럼 보여도 문자열 상태에서는 객체처럼 사용할 수 없다.
따라서 먼저 JSON.parse()로 변환한 뒤 필요한 값을 꺼내야 한다.


아래 예제는 서버 요청 없이 JSON.parse()의 역할만 확인하는 기본예제다.
뒤에서 AJAX로 받은 응답도 결국 처음에는 이런 문자열이라고 생각하면 된다.

// basic_json_parse.html
<body>
	<button onclick="readJson()">JSON 읽기</button>
	<div id="result"></div>

	<script>
		function readJson() {
			// 데이터 흐름: JSON 모양 문자열 → 객체 변환 → 필요한 값 출력
			const str = '{"name":"자바스크립트","age":29,"kind":"웹앱개발 전용 OOP 언어"}'; // 문자열
			const obj = JSON.parse(str); // 문자열을 객체로 변환

			document.getElementById("result").innerHTML =
				`<h3>${obj.name}</h3><h3>${obj.age}</h3><h3>${obj.kind}</h3>`; // 객체 값 출력
		}
	</script>
</body>
// 출력결과
// 자바스크립트
// 29
// 웹앱개발 전용 OOP 언어

이 예제에서 str은 객체처럼 생겼지만 실제로는 문자열이다.
그래서 JSON.parse(str)을 거쳐 obj로 바꾼 뒤에야 obj.name, obj.age, obj.kind처럼 값을 꺼낼 수 있다.


이 기준이 잡히면 뒤의 JSON 응답 예제도 훨씬 쉬워진다.
xhr.responseText로 받은 문자열을 바로 쓰는 것이 아니라, JSON.parse(xhr.responseText)로 바꾼 뒤 필요한 값을 꺼내는 이유가 분명해지기 때문이다.


XML과 JSON은 왜 읽는 방법이 다른가

XML과 JSON은 둘 다 데이터를 표현하는 형식이다.
즉, 둘 다 서버가 값을 정리해서 보내 주는 방식이라고 볼 수 있다.
하지만 생김새가 다르기 때문에 읽는 방법도 달라진다.


XML은 태그 중심 구조다.
그래서 태그를 찾고, 그 안의 값을 꺼내는 방식으로 읽는다.
반면 JSON은 키와 값 구조다.
그래서 문자열을 객체로 바꾼 뒤, 속성 이름으로 값을 꺼내는 방식으로 읽는다.
즉, 둘 다 데이터를 담고 있지만 구조가 다르기 때문에 처리 방식도 다르다.


초보자는 둘 중 무엇이 더 어렵냐를 먼저 보기보다, “구조가 다르면 읽는 방법도 달라진다”는 기준을 먼저 잡는 것이 중요하다.
이 기준이 있어야 뒤 예제에서 왜 어떤 것은 태그를 찾고, 어떤 것은 JSON.parse()를 하는지가 한 번에 이해된다.


이 이미지는 XML과 JSON의 모양 차이를 한눈에 보여 준다.
XML은 태그가 감싸는 구조이고, JSON은 키와 값이 짝을 이루는 구조다.
즉, 응답 형식을 먼저 구분해야 하는 이유는 생김새가 다르고, 그에 따라 읽는 방식도 달라지기 때문이다.


이미지 같은 파일 응답은 blob으로 받을 수 있다

서버 응답은 항상 문자 데이터만 오는 것이 아니다.
이미지처럼 파일 형태의 응답이 올 수도 있다.
이런 경우에는 텍스트처럼 읽는 것이 아니라 blob 같은 바이너리 데이터 형태로 받아야 한다.


여기서 바이너리 데이터는 파일 자체의 내용이라고 생각하면 된다.
즉, 글자처럼 읽는 것이 아니라 파일 데이터 자체를 받아서 다루는 방식이다.
그래서 이미지 응답은 responseText나 responseXML처럼 처리하지 않고, 파일 데이터에 맞는 방식으로 받아야 한다.


이 흐름을 초보자 기준으로 쉽게 말하면 이렇다.
문자 응답은 글자로 읽는다.
이미지 응답은 파일 데이터로 받는다.
즉, 응답이 무엇인지에 따라 읽는 방식이 달라진다.
이때 초보자는 “AJAX는 글자 데이터만 가져오는 기술이 아니다”라는 점을 꼭 기억해야 한다.


왜 응답 형식을 먼저 구분해야 하는가

같은 요청 코드처럼 보여도 응답 형식이 다르면 처리 방식이 달라진다.
그래서 응답이 XML인지, JSON인지, 그냥 문자열인지, 이미지인지 먼저 구분하는 습관이 중요하다.
응답 형식을 모르고 무조건 같은 방식으로 처리하려 하면 코드가 꼬이기 쉽다.


초보자 기준에서는 아래처럼 정리하면 된다.

  • 문자열이면 responseText
  • XML이면 responseXML
  • JSON이면 responseText를 JSON.parse()로 변환
  • 이미지면 blob

이 기준은 단순 암기용 목록이 아니다.
실제로 응답을 어떻게 읽을지 결정하는 기준이다.
즉, 응답 형식을 먼저 구분해야 그다음 처리 코드도 자연스럽게 정할 수 있다.


즉, 서버 응답은 한 가지 방식으로만 읽는 것이 아니라, 응답 형식에 맞게 읽어야 한다.
이 기준이 잡혀 있어야 뒤의 예제에서 왜 어떤 것은 JSON.parse()를 쓰고, 어떤 것은 태그를 찾고, 어떤 것은 이미지 객체를 만드는지가 자연스럽게 이해된다.


여기서 꼭 기억할 핵심

GET은 주로 조회, POST는 입력값 전송에 많이 사용된다.
문자열 응답은 responseText, XML 응답은 responseXML로 읽는다.
JSON 응답은 문자열로 받은 뒤 JSON.parse()로 객체로 바꿔 사용한다.
이미지 같은 파일 응답은 blob으로 받아야 한다.
이 기준이 잡혀 있어야 요청과 응답을 한 흐름으로 자연스럽게 읽을 수 있다.



7. AJAX가 자주 쓰이는 화면 처리 패턴

예제를 하나씩 보기 전에, AJAX가 실제로 어떤 식으로 자주 쓰이는지를 먼저 묶어 두면 이해가 훨씬 쉬워진다.
예제는 전부 달라 보이지만, 실제로는 몇 가지 대표 패턴 안에서 반복된다.
즉, 이 파트는 뒤의 예제들을 미리 분류해 두는 역할을 한다.


초보자는 예제가 바뀔 때마다 완전히 새로운 기술처럼 느끼기 쉽다.
하지만 아래처럼 어떤 흐름인지 먼저 나눠 보면 훨씬 단순해진다.

  • 어떤 것은 버튼을 누른 뒤 문장을 바꾼다.
  • 어떤 것은 일정 시간마다 다시 요청해서 내용을 갱신한다.
  • 어떤 것은 입력값을 서버로 보내고 결과 메시지만 바꾼다.
  • 어떤 것은 이미지 파일을 받아 현재 화면에 추가한다.
  • 어떤 것은 외부 API 데이터를 받아 표나 목록으로 다시 구성한다.

즉, 예제를 보기 전에 “이 예제는 어떤 패턴에 속하는가”를 먼저 잡아 두면 코드가 훨씬 쉽게 읽힌다.


왜 패턴으로 먼저 묶어야 하는가

AJAX 예제는 겉으로 보면 전부 다르게 보일 수 있다.
어떤 것은 버튼 클릭으로 시작하고, 어떤 것은 자동으로 반복 실행되고, 어떤 것은 로그인 값을 보내고, 어떤 것은 외부 데이터를 표로 다시 만든다.
그래서 초보자는 예제가 바뀔 때마다 완전히 새로운 기술처럼 느끼기 쉽다.


하지만 실제 안쪽 흐름은 비슷하다.

  • 이벤트가 시작된다.
  • 요청을 보낸다.
  • 응답을 받는다.
  • 현재 화면의 특정 부분을 바꾼다.

즉, 큰 틀은 계속 반복된다.
그래서 예제를 하나하나 따로 외우기보다, 먼저 어떤 종류의 화면 처리 패턴인지 분류해서 보는 것이 훨씬 쉽다.
그러면 코드를 처음 봐도 “아, 이건 버튼 클릭형이구나”, “이건 반복 갱신형이구나”, “이건 POST 전송형이구나”처럼 빠르게 감이 잡힌다.


버튼 클릭 후 결과를 출력하는 패턴

사용자가 버튼을 누르거나 특정 동작을 했을 때 요청을 보내고, 응답이 오면 현재 화면의 특정 영역에 결과를 출력하는 방식이다.
exam1이 가장 기본적인 예제다.
이 패턴은 “요청을 보내고, 결과를 원하는 위치에 반영한다”는 AJAX의 가장 기본적인 모습을 보여 준다.


이 패턴의 흐름을 아주 단순하게 보면 아래와 같다.

  • 버튼을 누른다.
  • 서버에 요청을 보낸다.
  • 응답이 온다.
  • div 같은 특정 영역에 결과를 넣는다.

초보자가 AJAX를 처음 이해할 때 가장 먼저 익히기 좋은 패턴도 이것이다.
왜냐하면 시작점이 분명하기 때문이다.
버튼 클릭이라는 눈에 보이는 행동이 시작점이라서 전체 흐름을 따라가기 쉽다.


이 패턴의 핵심은 새 페이지로 이동하지 않고 결과를 현재 화면 안에 붙인다는 점이다.
같은 요청을 보내더라도 브라우저가 직접 이동하면 새 페이지처럼 보이지만, AJAX로 처리하면 같은 화면 안의 한 부분만 바뀐다.
그래서 AJAX의 핵심 감각을 가장 먼저 익히기 좋은 출발점이 된다.


일정 시간마다 다시 요청하는 패턴

한 번 요청하고 끝나는 것이 아니라, 일정 시간마다 다시 요청해서 화면 일부를 계속 갱신하는 방식이다.
exam4가 여기에 해당한다.
뉴스, 실시간 정보, 상태 확인처럼 반복 갱신이 필요한 경우에 많이 떠올릴 수 있는 패턴이다.


이 패턴의 특징은 사용자가 매번 직접 눌러 주지 않아도 된다는 점이다.
즉, 시작 방식이 버튼 클릭형과 다르다.
흐름을 정리하면 아래와 같다.

  • 일정 시간이 지난다.
  • 같은 요청을 다시 보낸다.
  • 응답이 오면 현재 화면 일부를 다시 바꾼다.
  • 이 과정이 계속 반복된다.

이 패턴은 버튼을 누를 때만 동작하는 것이 아니라, 시간 흐름에 따라 자동으로 요청이 반복된다는 점이 중요하다.
즉, 사용자가 계속 직접 행동하지 않아도 화면 일부가 계속 바뀔 수 있다.
이 흐름을 이해하면 AJAX가 단발성 요청만 처리하는 기술이 아니라는 점도 자연스럽게 알 수 있다.


초보자는 여기서 중요한 기준을 하나 잡으면 된다.
버튼 클릭형은 사용자의 행동이 시작점이다.
반복 요청형은 시간 흐름이 시작점이다.
하지만 둘 다 결국은 요청을 보내고, 응답을 받아, 현재 화면 일부를 바꾼다는 점에서는 같은 구조다.


폼 입력값을 보내고 메시지만 바꾸는 패턴

사용자가 입력한 값을 서버로 보내고, 응답 결과에 따라 성공 또는 실패 메시지처럼 일부 결과만 바꾸는 방식이다.
exam5가 대표적이다.
이 패턴을 이해하면 폼을 제출한다고 해서 항상 새 페이지로 넘어가는 것은 아니라는 점을 자연스럽게 알 수 있다.


처음 웹을 배울 때는 폼 제출을 하면 결과 화면이 새로 열리는 흐름부터 익히는 경우가 많다.
그래서 초보자는 폼 전송과 페이지 이동을 거의 같은 것으로 받아들이기 쉽다.
하지만 AJAX에서는 폼 입력값을 서버로 보내더라도, 응답 결과를 현재 화면의 메시지 한 줄이나 특정 영역만 바꿔서 보여 줄 수 있다.


이 패턴의 흐름을 짧게 정리하면 아래와 같다.

  • 사용자가 값을 입력한다.
  • 입력값을 서버로 보낸다.
  • 서버가 성공 또는 실패 결과를 돌려준다.
  • 현재 화면의 메시지 영역만 바꾼다.

예를 들어 로그인 성공이면 파란 문장을 보여 주고, 실패면 빨간 문장을 보여 줄 수 있다.
이 과정에서 전체 화면은 그대로 유지된다.
즉, 이 패턴은 POST 요청, 입력값 전송, 응답 결과 처리, 화면 일부 갱신이 한꺼번에 연결되는 중요한 흐름이다.
그래서 실제 웹 화면에서 자주 만나는 패턴이기도 하다.


이미지나 파일 데이터를 받아서 추가하는 패턴

AJAX는 글자 데이터만 처리하는 것이 아니다.
이미지 같은 파일 응답을 받아 현재 화면에 추가할 수도 있다.
exam6이 바로 이 흐름을 보여 준다.
그래서 AJAX를 “텍스트만 주고받는 기술”로 좁게 이해하면 안 된다.


초보자는 AJAX를 배우면 보통 JSON이나 문자열 응답부터 먼저 떠올린다.
하지만 실제로는 서버가 보내 주는 것이 항상 글자는 아니다.
이미지 파일이 올 수도 있고, 다른 파일 데이터가 올 수도 있다.
이 경우에는 텍스트처럼 읽는 것이 아니라 파일 데이터에 맞는 방식으로 받아야 한다.


이 패턴도 흐름으로 보면 단순하다.

  • 서버에 이미지나 파일을 요청한다.
  • 파일 데이터를 응답으로 받는다.
  • 현재 화면에 그 파일을 추가한다.

즉, 요청 구조는 비슷해 보여도 응답이 이미지라면 화면에 붙이는 방식이 문자 응답과는 달라진다.
이 흐름을 이해하면 AJAX의 활용 범위를 훨씬 넓게 볼 수 있다.


외부 API 데이터를 받아 가공해서 출력하는 패턴

외부 API에서 받은 데이터를 먼저 확인하고, 그 안에서 필요한 값만 골라 다시 표나 목록으로 가공해서 보여 주는 방식이다.
exam7, exam8, exam9가 이 흐름과 연결된다.
이 패턴까지 이해하면 AJAX가 단순한 요청 예제를 넘어서 실제 데이터 활용과 연결된다는 점이 보인다.


처음에는 외부 API에서 받은 응답 원문이 너무 길고 복잡해 보여서 당황할 수 있다.
그래서 초보자는 “이걸 다 외워야 하나?” 하고 느끼기 쉽다.
하지만 실제로 중요한 것은 전체 원문을 외우는 것이 아니라, 응답 구조를 먼저 확인하고 그 안에서 필요한 값만 골라 쓰는 것이다.


이 패턴의 흐름을 짧게 정리하면 아래와 같다.

  • 외부 API에 요청한다.
  • 응답 원문 구조를 먼저 확인한다.
  • 필요한 값만 골라낸다.
  • 화면에 맞게 표나 목록으로 다시 구성한다.

예를 들어 영화 순위 데이터가 길게 들어와도, 실제로 화면에 보여 줄 것은 영화 제목, 관객 수, 누적 관객 수처럼 일부 값일 수 있다.
즉, 외부 API 패턴은 데이터를 그대로 받는 데서 끝나는 것이 아니라, 받은 데이터를 다시 가공해서 현재 화면에 보기 좋게 보여 주는 단계까지 포함한다.
그래서 앞의 기본 예제보다 한 단계 더 실제 서비스 화면에 가까운 흐름이라고 볼 수 있다.


이 파트가 왜 중요한가

예제를 전부 따로 보면 복잡해 보인다.
어떤 것은 버튼을 누르고, 어떤 것은 자동으로 바뀌고, 어떤 것은 로그인 값을 보내고, 어떤 것은 표를 다시 채운다.
그래서 초보자는 예제가 바뀔 때마다 전혀 다른 기술처럼 느끼기 쉽다.


하지만 패턴으로 먼저 묶어 두면 구조가 단순해진다.

  • 이건 버튼 클릭 패턴이다.
  • 이건 반복 요청 패턴이다.
  • 이건 POST 전송 패턴이다.
  • 이건 이미지 추가 패턴이다.
  • 이건 외부 API 가공 패턴이다.

이렇게 머릿속에서 분류가 되면 예제를 볼 때도 완전히 새로운 코드처럼 느껴지지 않는다.
즉, 이 파트는 예제를 보기 전에 미리 틀을 잡아 주는 정리 구간이라고 이해하면 된다.
이 기준이 잡혀 있어야 뒤 예제들을 볼 때 겉모습보다 안쪽 구조를 먼저 읽을 수 있다.


여기서 꼭 기억할 핵심

AJAX 예제는 전부 달라 보여도 몇 가지 대표 패턴 안에서 반복된다.
버튼 클릭형, 반복 요청형, 폼 전송형, 이미지 추가형, 외부 API 가공형으로 묶어 보면 훨씬 이해하기 쉽다.
즉, 예제를 먼저 외우는 것이 아니라 어떤 화면 처리 패턴인지 먼저 분류해서 보는 것이 중요하다.



8. AJAX에서 꼭 알아야 할 제한 사항

AJAX는 현재 화면 안에서 서버와 통신할 수 있어서 편리하다.
하지만 아무 서버나 마음대로 읽을 수 있는 것은 아니다.
브라우저는 보안 때문에 기본 제한을 두고 있다.
그래서 AJAX를 제대로 이해하려면 SOP와 CORS 개념을 꼭 알아야 한다.


초보자는 외부 API 주소만 알면 언제나 바로 데이터를 읽을 수 있다고 생각하기 쉽다.
하지만 실제로는 브라우저가 보안 정책을 적용하기 때문에, 어떤 요청은 잘 되고 어떤 요청은 막힐 수 있다.
즉, 코드 문법만 맞는다고 항상 통신이 성공하는 것은 아니다.
브라우저 보안 정책과 서버의 허용 설정까지 함께 맞아야 외부 요청이 정상적으로 동작한다.


SOP와 CORS의 차이를 먼저 잡아야 한다

이 파트에서 가장 먼저 잡아야 하는 것은 SOP와 CORS를 따로 외우는 것이 아니다.
둘이 어떤 관계인지 먼저 이해해야 한다.
초보자가 가장 많이 헷갈리는 이유도 바로 여기 있다.
SOP와 CORS를 서로 완전히 반대 개념처럼 받아들이기 쉽기 때문이다.


하지만 실제로는 그렇게 보면 오히려 더 헷갈린다.
이 둘은 아래처럼 이해하는 것이 가장 정확하다.

  • SOP는 기본 제한이다.
  • CORS는 그 제한을 조건부로 풀어 주는 방식이다.

즉, 둘은 완전히 따로 노는 개념이 아니라 기본 차단과 예외 허용 관계다.
이 기준을 먼저 잡아야 뒤의 설명이 자연스럽게 이어진다.


이 비교 이미지는 SOP와 CORS를 한 번에 이해할 때 도움이 된다.
왼쪽은 기본적으로 막아 두는 흐름이고, 오른쪽은 허용 조건이 맞으면 접근이 가능해지는 흐름으로 이해하면 된다.
즉, 브라우저는 먼저 조심하고, 허용 조건이 맞는 경우에만 외부 요청을 통과시킨다고 보면 된다.


왜 브라우저는 기본적으로 막아 두는가

처음 보면 이런 제한이 불편하게 느껴질 수 있다.
외부 데이터가 필요하면 그냥 읽게 해 주면 더 편할 것처럼 보이기 때문이다.
하지만 브라우저가 아무 사이트나 자유롭게 읽게 두면 보안 문제가 생길 수 있다.


예를 들어 사용자가 어떤 사이트에 로그인한 상태라고 해 보자.
이때 전혀 다른 사이트가 마음대로 요청을 보내고 응답까지 읽을 수 있다면, 원하지 않는 정보가 노출될 수도 있다.
그래서 브라우저는 기본적으로 조심하는 쪽을 선택한다.
즉, 무조건 허용이 아니라 기본 제한 후 조건부 허용 구조로 동작한다.


초보자 기준에서는 이 흐름만 먼저 잡으면 된다.

  • 브라우저는 기본적으로 외부 요청을 무조건 믿지 않는다.
  • 다른 출처의 자원을 읽을 때는 제한을 먼저 건다.
  • 허용이 필요한 경우에는 서버가 따로 허용 설정을 해 주어야 한다.

즉, 이 제한은 괜히 만든 장애물이 아니라, 사용자의 정보를 보호하기 위한 기본 안전장치라고 보면 된다.


SOP는 무엇인가

SOP는 Same Origin Policy의 줄임말이다.
쉽게 말하면 브라우저가 기본적으로 같은 출처의 자원만 안전하게 읽도록 제한하는 정책이다.
여기서 출처는 보통 아래 세 가지를 함께 본다고 이해하면 된다.

  • 프로토콜
  • 도메인
  • 포트

이 세 가지가 모두 같아야 같은 출처라고 본다.
즉, 주소가 비슷해 보여도 이 중 하나라도 다르면 다른 출처가 될 수 있다.


초보자는 여기서 “출처가 같다”는 말을 너무 어렵게 생각할 필요는 없다.
그냥 같은 웹 주소 계열인지 확인하는 기준 정도로 이해하면 된다.
예를 들어 지금 내 웹 페이지가 있는 서버와, 데이터를 요청하려는 서버가 완전히 같은 쪽인지 보는 것이다.


SOP의 핵심은 브라우저가 다른 출처 요청을 기본적으로 바로 읽게 두지 않는다는 점이다.
즉, SOP는 브라우저가 함부로 다른 서버를 읽지 못하게 막아 두는 기본 규칙이라고 이해하면 된다.


기본예제로 같은 출처와 다른 출처 구분하기

같은 출처인지 판단할 때는 주소 전체를 느낌으로만 보면 안 된다.
기준은 크게 프로토콜, 도메인, 포트다.
이 세 가지가 모두 같으면 같은 출처로 볼 수 있고, 하나라도 다르면 다른 출처가 될 수 있다.


예를 들어 현재 페이지 주소가 아래와 같다고 하자.

// origin_check.txt
현재 페이지 주소
http://localhost:8088/edu/ajax/basic.html

이때 요청 주소를 비교하면 아래처럼 판단할 수 있다.

  • http://localhost:8088/edu/first.html
    프로토콜, 도메인, 포트가 모두 같으므로 같은 출처로 볼 수 있다.

  • http://localhost:8080/edu/first.html
    프로토콜과 도메인은 같지만 포트가 다르므로 다른 출처가 될 수 있다.

  • https://localhost:8088/edu/first.html
    도메인과 포트가 같아 보여도 프로토콜이 다르므로 다른 출처가 될 수 있다.

  • http://openapi.seoul.go.kr:8088/sample
    도메인이 다르므로 다른 출처가 될 수 있다.

즉, 주소가 비슷해 보여도 프로토콜, 도메인, 포트 중 하나가 다르면 브라우저는 다른 출처로 판단할 수 있다.
그래서 외부 API 요청은 주소만 맞는다고 끝나는 것이 아니라, 브라우저의 출처 판단과 서버의 허용 설정까지 함께 봐야 한다.


CORS는 무엇인가

CORS는 Cross-Origin Resource Sharing의 줄임말이다.
이 말은 다른 출처의 자원을 무조건 못 쓰게 한다는 뜻이 아니다.
오히려 서버가 허용하면 다른 출처의 자원도 사용할 수 있다는 뜻과 연결된다.


즉, 외부 요청이 가능하냐 아니냐는 브라우저만의 문제가 아니다.
서버도 함께 관여한다.
브라우저가 다른 출처라서 조심하고 있을 때, 서버가 “이 출처의 접근은 허용한다”는 식으로 응답해 주면 요청이 가능해질 수 있다.


초보자 기준에서는 아래처럼 이해하면 가장 쉽다.

  • SOP는 기본 제한이다.
  • CORS는 그 제한을 조건에 따라 풀어 주는 규칙이다.

즉, SOP가 “기본적으로 조심한다”라면, CORS는 “서버가 허용하면 가능하다”에 가깝다.
이 두 개념은 서로 반대라기보다, 기본 제한과 예외 허용 관계로 보면 훨씬 이해하기 쉽다.


이 이미지는 CORS를 이해할 때 특히 중요하다.
브라우저가 기본 제한을 두고 있는 상태에서, 서버가 허용 응답을 해 주어야 다른 출처의 자원을 읽을 수 있다는 흐름을 보여 준다.
즉, CORS는 브라우저 혼자 결정하는 것이 아니라, 서버의 허용 설정까지 함께 있어야 성립하는 규칙이라고 이해하면 된다.


왜 어떤 외부 요청은 되고 어떤 것은 안 되는가

초보자가 AJAX를 공부할 때 가장 많이 당황하는 부분이 바로 이것이다.
어떤 외부 API는 잘 불러와진다.
그런데 어떤 외부 API는 CORS 오류가 나면서 막힌다.
그래서 처음에는 코드가 틀린 것처럼 느껴지기 쉽다.


하지만 실제 원인은 코드 문법이 아닐 수도 있다.
외부 요청의 성공 여부는 아래처럼 여러 조건이 함께 맞아야 한다.

  • 요청 주소가 맞아야 한다.
  • 서버가 정상적으로 응답해야 한다.
  • 브라우저 보안 정책에 걸리지 않아야 한다.
  • 다른 출처라면 서버가 CORS 허용 설정을 해 주어야 한다.

즉, 외부 요청은 단순히 주소만 안다고 끝나는 것이 아니다.
브라우저와 서버가 함께 허용하는 구조여야 한다.
그래서 어떤 것은 성공하고 어떤 것은 차단될 수 있다.


이 점을 모르면 외부 요청이 실패했을 때 무조건 “내 코드가 틀렸나?”부터 떠올리게 된다.
하지만 SOP와 CORS를 알고 있으면 시야가 넓어진다.
즉, 실패 원인을 볼 때도 아래처럼 나눠서 생각할 수 있다.

  • 주소가 틀렸는가
  • 응답 데이터 형식이 다른가
  • 브라우저 보안 정책에 막혔는가
  • 서버가 외부 요청을 허용하지 않았는가

이렇게 봐야 문제를 더 정확하게 이해할 수 있다.


AJAX 예제에서 이 개념이 왜 중요한가

이 개념을 모르면 AJAX 예제를 실행했을 때 “왜 어떤 것은 잘 되고 어떤 것은 안 되지?” 하고 당황하기 쉽다.
특히 외부 Open API를 실습할 때 이런 혼란이 자주 생긴다.
로컬 자원은 잘 읽히는데, 외부 자원은 갑자기 막히는 경우가 있기 때문이다.


하지만 SOP와 CORS를 알고 있으면 외부 요청이 막혔을 때도 원인을 더 자연스럽게 이해할 수 있다.
즉, 오류가 나도 “코드가 무조건 틀렸다”가 아니라, 브라우저 보안 정책이나 서버 허용 설정 문제일 수 있다고 볼 수 있다.
이 차이는 매우 중요하다.
왜냐하면 원인을 잘못 잡으면 코드를 계속 고치기만 하다가 시간을 낭비할 수 있기 때문이다.


그래서 외부 API 요청에서 실패 결과가 나온다는 것은 단순한 실수 장면이 아니다.
오히려 AJAX가 실제 웹 환경에서 어떤 제한 안에서 동작하는지 보여 주는 중요한 학습 포인트다.
외부 Open API라고 해서 항상 바로 읽을 수 있는 것은 아니라는 점을 여기서 꼭 기억해야 한다.


여기서 꼭 기억할 핵심

브라우저는 보안 때문에 다른 출처의 자원을 기본적으로 조심한다.
SOP는 같은 출처만 기본 허용하는 정책이다.
CORS는 서버가 허용할 때 다른 출처 요청을 가능하게 하는 규칙이다.
즉, 외부 API 요청은 코드만 맞다고 되는 것이 아니라, 브라우저 정책과 서버 허용 설정까지 함께 맞아야 한다.



9. 예제 1 - 같은 요청도 결과 반영 방식이 다르다

이 예제는 AJAX의 가장 기본적인 요청 흐름을 실제 코드로 확인하는 예제다.
핵심은 “무엇을 요청했는가”보다 “그 결과를 화면에 어떻게 보여 주는가”에 있다.
즉, 같은 자원을 요청해도 브라우저가 직접 이동하는 방식과 AJAX로 요청하는 방식은 결과가 보이는 모습이 다르다.


이 예제는 예제 파트의 출발점 역할을 한다.
왜냐하면 여기서부터 AJAX의 가장 중요한 감각이 처음으로 눈에 보이기 때문이다.
같은 요청이라도 결과를 새 페이지로 보여 줄 수도 있고, 현재 화면 안에 붙일 수도 있다.
이 차이를 정확히 잡아야 뒤의 모든 예제가 자연스럽게 이어진다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 처음 보여 주는 예제다.
즉, 지금까지 배운 내용을 코드 한 번으로 묶어서 확인하는 출발점이라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 1번 AJAX가 왜 필요한가
    현재 화면을 유지한 채 필요한 부분만 다시 바꾸는 이유와 연결된다.

  • 2번 기존 웹 통신과 AJAX 웹 통신의 차이
    같은 요청이라도 새 페이지로 보여 줄지, 현재 화면 일부만 바꿀지가 다르다는 점과 연결된다.

  • 3번 동기와 비동기
    브라우저 직접 이동과 AJAX 요청의 처리 흐름 차이를 이해하는 데 연결된다.

  • 4번 AJAX의 동작 순서
    이벤트 발생 → 요청 전송 → 응답 도착 → 화면 반영 흐름을 실제 코드에서 확인할 수 있다.

  • 5번 XMLHttpRequest 객체 이해하기
    new XMLHttpRequest(), open(), send(), onload가 실제로 어떻게 쓰이는지 연결된다.

  • 6번 요청과 응답을 읽는 기준
    이 예제는 GET 요청과 responseText 응답 처리의 가장 기본 형태를 보여 준다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    버튼 클릭 후 결과를 현재 화면에 출력하는 가장 기본적인 패턴과 연결된다.

즉, 이 예제는 새로운 내용을 갑자기 추가하는 것이 아니라, 앞에서 배운 개념을 실제 화면에서 처음 확인하는 단계다.


exam1.html에는 세 가지 방식이 나란히 들어 있다.

  • 하이퍼링크 요청
  • 버튼을 이용한 직접 이동 요청
  • AJAX 요청

앞의 두 방식은 브라우저가 직접 새 주소로 이동하는 흐름이다.
즉, 요청 결과가 새 페이지처럼 보인다.
반면 마지막 방식은 현재 페이지 안에서 XMLHttpRequest 객체를 만들어 응답 내용을 특정 영역에 붙인다.
즉, 요청 결과가 현재 화면 안에 추가된다.


이 예제의 핵심은 요청 대상이 완전히 다르다는 점이 아니다.
오히려 비슷한 요청을 보냈는데 결과 반영 방식이 다르다는 점이 중요하다.
초보자는 보통 요청을 보냈다는 사실에만 집중하기 쉽다.
하지만 AJAX를 이해하려면 요청 그 자체보다, 응답을 어디에 어떻게 반영하는지를 먼저 봐야 한다.


핵심 코드

<body>
	<h1>AJAX 통신 테스트</h1>
	<a href="/edu/first.html">하이퍼링크로요청</a>
	<hr>
	<button onclick="location.href='/edu/first.html';">버튼을클릭하여요청</button>
	<hr>
	<button onclick="requestAjax();">버튼을클릭하여요청(AJAX사용)</button>
	<hr>
	<div id="result"></div>

	<script>
		function requestAjax() {
			// 데이터 흐름: 버튼 클릭 → /edu/first.html 요청 → 응답 문자열을 result 영역에 추가
			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.onload = function () {
				const result = document.getElementById("result"); // 응답을 넣을 영역 선택
				result.innerHTML += xhr.responseText + "<hr>"; // 응답 문자열을 화면에 누적
			};

			xhr.open("GET", "/edu/first.html", true); // GET 방식 요청 준비
			xhr.send(); // 요청 전송
		}
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 new XMLHttpRequest()다.
이 줄은 브라우저가 지금부터 서버와 직접 통신할 준비를 시작한다는 뜻이다.
즉, AJAX 요청의 출발점이다.


그다음 중요한 부분은 xhr.onload다.
이 함수는 응답이 도착했을 때 실행된다.
즉, 서버 응답을 받은 뒤 어떤 처리를 할지 여기 안에 적는다.
이 구조가 바로 비동기 흐름과 연결된다.


그리고 가장 중요한 줄은 아래 부분이다.

  • const result = document.getElementById("result");
  • result.innerHTML += xhr.responseText + "<hr>";

여기서 핵심은 응답을 받은 뒤 새 페이지로 이동하는 것이 아니라, 현재 화면 안의 result 영역에 내용을 붙인다는 점이다.
즉, 응답을 현재 문서 안에 반영한다는 것이 이 예제의 핵심이다.


또 +=를 사용하고 있기 때문에 기존 내용을 지우지 않고 뒤에 계속 덧붙인다.
이 점도 중요하다.
왜냐하면 이 코드는 “결과를 교체하는 예제”가 아니라 “결과를 현재 화면 안에 추가하는 예제”이기 때문이다.
즉, 버튼을 여러 번 누르면 결과가 아래로 계속 쌓이게 된다.


실행 결과를 어떻게 이해하면 되는가

하이퍼링크와 버튼 이동은 모두 브라우저가 주소를 직접 열기 때문에 새 페이지로 이동하는 느낌을 준다.
사용자는 지금 화면을 떠나서 다른 화면으로 넘어간 것처럼 느끼게 된다.
즉, 결과가 현재 문서 안에 남는 것이 아니라, 새 화면으로 바뀌는 흐름이다.


반면 AJAX 버튼은 이동하지 않는다.
현재 페이지 아래쪽에 응답 결과만 붙는다.
즉, 화면 전체는 그대로 두고 특정 부분만 바뀐다.
이 차이가 바로 AJAX를 이해할 때 가장 먼저 잡아야 하는 핵심이다.


초보자는 이 예제를 볼 때 아래처럼 비교해서 보면 가장 쉽다.

  • 하이퍼링크와 버튼 이동은 결과를 새 화면처럼 보여 준다.
  • AJAX는 결과를 현재 화면 안에 붙인다.

즉, 같은 요청이라도 브라우저가 직접 이동하면 페이지 전환처럼 보이고, AJAX로 처리하면 현재 화면 일부 갱신처럼 보인다.

이 실행 화면을 보면 차이가 더 분명하다.
앞의 방식은 이동이 일어나지만, AJAX 방식은 현재 페이지 아래쪽에 결과가 추가된다.
즉, 페이지를 갈아끼우는 것이 아니라 현재 문서 안에 결과를 덧붙이는 흐름이라는 점이 눈에 보인다.


왜 이 예제가 중요한가

이 예제는 기능 자체가 복잡하지 않다.
XML, JSON, 외부 API, POST 전송 같은 어려운 요소도 아직 없다.
그런데도 매우 중요하다.
왜냐하면 AJAX의 핵심 차이 하나를 가장 단순한 형태로 보여 주기 때문이다.


뒤의 예제에서는 응답 형식이 달라지고, 요청 방식이 달라지고, 처리 로직도 더 복잡해진다.
하지만 그 안쪽 구조는 결국 여기서 본 것과 같다.

  • 요청을 보낸다.
  • 응답을 받는다.
  • 현재 화면의 특정 위치를 바꾼다.

즉, 이 예제는 뒤의 모든 예제를 읽기 위한 가장 기본 틀을 만들어 준다.
여기서 “결과를 현재 화면 안에 붙인다”는 감각이 잡혀 있어야 이후 예제에서 왜 div, output, tbody 같은 특정 영역을 바꾸는 코드가 계속 나오는지도 자연스럽게 이해된다.


여기서 꼭 기억할 핵심

같은 자원을 요청하더라도, 브라우저가 직접 이동하면 새 페이지가 열리고 AJAX로 요청하면 현재 화면 일부만 바뀐다.
즉, AJAX의 핵심은 요청 자체보다 응답 결과를 현재 화면 안에 반영한다는 점에 있다.
이 기준이 잡혀 있어야 뒤의 모든 예제를 자연스럽게 이해할 수 있다.



10. 예제 2 - XML 응답은 문서처럼 읽는다

이 예제는 서버가 준 응답이 XML일 때 값을 어떻게 읽는지 실제로 확인하는 예제다.
문자열처럼 바로 출력하는 것이 아니라, 문서 구조를 따라 필요한 태그를 찾아 값을 꺼내는 방식이라는 점이 핵심이다.
즉, XML 응답은 단순한 글자 덩어리로 다루는 것이 아니라, 구조를 가진 문서로 읽어야 한다.


이 예제는 앞의 exam1보다 한 단계 더 나아간다.
exam1이 “현재 화면에 결과를 붙인다”는 AJAX의 가장 기본 구조를 보여 줬다면, exam2는 응답 형식이 달라지면 읽는 방법도 달라진다는 점을 처음으로 보여 준다.
즉, 이 예제의 핵심은 AJAX로 요청했다는 사실보다, 응답이 XML일 때 왜 responseXML로 읽어야 하는지 이해하는 데 있다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 XML 응답은 왜 문자열처럼 바로 다루지 않고, 문서 구조를 따라 읽어야 하는지 처음 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 4번 AJAX의 동작 순서
    이벤트 발생 → 요청 전송 → 응답 도착 → 화면 반영 흐름이 그대로 이어진다.

  • 5번 XMLHttpRequest 객체 이해하기
    new XMLHttpRequest(), open(), send(), onload가 실제로 어떻게 쓰이는지 확인할 수 있다.

  • 6번 요청과 응답을 읽는 기준
    문자열 응답은 responseText, XML 응답은 responseXML로 읽는다는 기준이 실제 코드에서 드러난다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    요청을 보내고 응답을 받아 현재 화면에 출력하는 가장 기본적인 화면 처리 패턴과 연결된다.

즉, 이 예제는 새로운 내용을 갑자기 추가하는 것이 아니라, 앞에서 배운 “응답 형식에 따라 읽는 방식이 달라진다”는 개념을 실제 코드로 확인하는 단계다.


exam2.html은 페이지가 열리면 sample.xml을 요청한다.
그리고 응답으로 들어온 XML 문서 안에서 name, age, kind 값을 찾아 화면에 출력한다.
즉, 이 예제는 XML 응답을 문서처럼 읽는 가장 기본적인 흐름을 보여 준다.


핵심 코드

// exam2.html
<body>
	<h2>onload 속성 사용 - XML응답</h2>
	<hr>

	<script>
		window.onload = function() {
			// 데이터 흐름: sample.xml 요청 → XML 문서로 응답 받기 → 태그 안의 값을 꺼내 화면에 출력
			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.onload = function(event) {
				if (xhr.status == 200) { // 요청 성공 여부 확인
					const xml = xhr.responseXML; // XML 응답을 문서 객체로 받기
					const rootE = xml.getElementsByTagName('testxml'); // testxml 태그 찾기

					let output = '';
					for (let i = 1; i < rootE[0].childNodes.length; i += 2) {
						output += `<h3>${rootE[0].childNodes[i].firstChild.nodeValue}</h3>`; // 태그 안의 값 추출
					}

					document.body.innerHTML += output; // 추출한 값을 화면에 추가
				} else {
					document.body.innerHTML += "<h3>요청 실패~~~</h3>";
				}
			};

			xhr.open('GET', 'content/sample.xml', true); // XML 파일 요청 준비
			xhr.send(); // 요청 전송
		};
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 xhr.responseXML이다.
이 줄이 바로 이 예제의 핵심이다.
응답을 단순 문자열로 받는 것이 아니라, XML 문서 형태로 받아서 읽겠다는 뜻이기 때문이다.


즉, 이 예제는 “응답을 받았다”에서 끝나지 않는다.
응답을 어떤 형식으로 읽느냐가 더 중요하다.
만약 여기서 responseText만 보고 끝내면 XML의 태그 구조를 활용하는 흐름이 잘 드러나지 않는다.
그래서 이 예제에서는 responseXML이 핵심 역할을 한다.


그다음 중요한 부분은 아래 흐름이다.

  • xml.getElementsByTagName('testxml')

  • rootE[0].childNodes[i].firstChild.nodeValue

여기서는 XML을 그냥 출력하는 것이 아니라, 태그를 찾고 그 안의 값을 꺼낸다.
즉, XML 응답은 문서 구조를 따라 원하는 값을 찾아 읽는 방식이라는 점이 코드에 그대로 드러난다.


또 반복문에서 i += 2로 움직이는 부분은 childNodes 안에 줄바꿈 같은 공백 노드까지 포함될 수 있기 때문이다.
초보자는 이 부분이 낯설 수 있다.
하지만 여기서 꼭 기억할 핵심은 숫자 규칙 자체가 아니다.
중요한 것은 XML 응답을 태그 구조 안에서 하나씩 찾아 읽고 있다는 점이다.
즉, 세부 반복 방식보다 “태그를 따라 값을 꺼낸다”는 큰 흐름을 먼저 잡는 것이 더 중요하다.


실행 결과를 어떻게 이해하면 되는가

실행하면 화면에 자바스크립트, 29, 웹앱개발 전용 OOP 언어가 차례대로 출력된다.
이 결과는 sample.xml 안의 값을 태그 구조를 따라 추출했다는 뜻이다.
즉, 값이 화면에 그냥 나타난 것이 아니라, XML 문서 안에서 필요한 태그를 찾아 꺼낸 뒤 출력한 것이다.


초보자는 이 예제를 볼 때 아래처럼 이해하면 가장 쉽다.

  • 서버가 XML 형식으로 응답을 보낸다.

  • 브라우저는 그 응답을 responseXML로 읽는다.

  • 필요한 태그를 찾는다.

  • 태그 안의 값을 꺼내 현재 화면에 출력한다.

즉, XML 응답은 “문자열 전체를 그냥 보여 주는 방식”이 아니라, 태그 구조를 따라 필요한 값만 골라서 쓰는 방식이다.
이 차이를 이해해야 뒤에서 JSON 예제와도 자연스럽게 비교할 수 있다.

이 실행 화면은 XML 안의 값이 실제로 화면에 출력된 결과를 보여 준다.
즉, 서버가 보낸 문서를 그대로 통째로 출력한 것이 아니라, 필요한 값만 꺼내 현재 화면에 반영한 결과라고 보면 된다.


왜 이 예제가 중요한가

이 예제는 AJAX 요청 자체보다 응답 형식에 따라 처리 방식이 달라진다는 점을 처음으로 분명하게 보여 준다.
즉, 같은 AJAX 코드처럼 보여도 응답이 무엇이냐에 따라 읽는 방법이 달라진다는 기준을 세워 주는 예제다.


특히 이 예제는 바로 다음 JSON 예제와 비교할 준비를 해 준다.
XML은 태그 구조를 따라 읽는다.
반면 JSON은 문자열을 객체로 바꾼 뒤 속성처럼 읽는다.
즉, exam2를 제대로 이해해야 exam3에서 왜 처리 방식이 달라지는지도 자연스럽게 이어진다.


이 예제를 통해 초보자가 꼭 잡아야 할 감각은 이것이다.

  • AJAX는 요청만 보내는 기술이 아니다.

  • 응답 형식에 맞게 읽는 기술이기도 하다.

즉, 요청과 응답은 항상 한 세트로 봐야 하고, 응답이 XML이라면 읽는 방식도 XML에 맞게 달라져야 한다.


여기서 꼭 기억할 핵심

XML 응답은 responseXML로 읽고, 태그 구조 안에서 필요한 값을 찾아 꺼내는 방식으로 처리한다.
즉, XML은 문자열처럼 통째로 보는 것이 아니라, 문서 구조를 따라 읽는 응답 형식이다.
이 기준이 잡혀 있어야 바로 다음 JSON 예제와 차이도 자연스럽게 이해할 수 있다.



11. 예제 3 - JSON 응답은 객체로 바꿔서 읽는다

이 예제는 JSON 응답을 어떻게 읽는지 보여 준다.
실무에서는 XML보다 JSON을 더 자주 보게 되므로, 이 흐름을 정확히 이해하는 것이 중요하다.
JSON 응답은 보통 문자열로 들어오기 때문에, 먼저 객체로 바꾼 뒤 필요한 값을 꺼내야 한다는 점이 핵심이다.


이 예제는 바로 앞의 exam2와 자연스럽게 연결된다.
exam2가 XML 응답을 문서 구조로 읽는 방식을 보여 줬다면, exam3는 JSON 응답을 객체로 바꿔 읽는 방식을 보여 준다.
즉, 응답 형식이 달라지면 처리 방식도 달라진다는 점을 비교해서 이해하기 좋은 예제다.
이 예제의 핵심은 JSON을 받았다는 사실보다, 왜 JSON.parse()가 꼭 필요한지를 이해하는 데 있다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 JSON 응답은 왜 바로 속성처럼 쓰지 않고, 먼저 객체로 바꿔서 사용해야 하는지 처음 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 4번 AJAX의 동작 순서
    요청 전송 → 응답 도착 → 결과 읽기 → 화면 반영 흐름이 그대로 이어진다.

  • 5번 XMLHttpRequest 객체 이해하기
    new XMLHttpRequest(), open(), send(), onload가 실제로 어떻게 쓰이는지 확인할 수 있다.

  • 6번 요청과 응답을 읽는 기준
    JSON 응답은 responseText로 받은 뒤 JSON.parse()로 객체로 바꿔 읽는다는 기준이 실제 코드에서 드러난다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    요청을 보내고 응답을 받아 현재 화면에 출력하는 가장 기본적인 화면 처리 패턴과 연결된다.

  • 10번 예제 2 - XML 응답은 문서처럼 읽는다
    XML은 태그 구조를 따라 읽고, JSON은 객체로 바꿔 읽는다는 차이를 비교해서 이해할 수 있다.

즉, 이 예제는 새로운 내용을 갑자기 추가하는 것이 아니라, 앞에서 배운 “응답 형식에 따라 읽는 방식이 달라진다”는 개념을 JSON 기준으로 다시 확인하는 단계다.


exam3.html은 페이지가 열리면 sample.json을 요청한다.
그리고 응답으로 받은 문자열을 JSON.parse()로 객체로 바꾼 다음, 반복문으로 값을 화면에 출력한다.
즉, 이 예제는 JSON 응답을 다루는 가장 기본적인 흐름을 보여 준다.


핵심 코드

// exam3.html
<body>
	<h2>onload 속성 사용 - JSON응답</h2>
	<hr>

	<script>
		window.onload = function () {
			// 데이터 흐름: sample.json 요청 → 문자열 응답 받기 → JSON 객체로 변환 → 값 출력
			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.onload = function (event) {
				const str = xhr.responseText; // JSON 응답을 문자열로 받기
				const result = JSON.parse(str); // 문자열을 객체로 변환

				let output = "";
				for (var i in result) {
					output += `<h3>${result[i]}</h3>`; // 객체의 값을 화면 출력용 문자열로 만들기
				}

				document.body.innerHTML += output; // 완성한 결과를 화면에 추가
			};

			xhr.open('GET', 'content/sample.json', true); // JSON 파일 요청 준비
			xhr.send(); // 요청 전송
		};
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 xhr.responseText다.
즉, 서버가 보낸 JSON 응답도 처음부터 객체로 들어오는 것이 아니라, 먼저 문자열 형태로 들어온다는 점이 중요하다.
초보자는 여기서 많이 헷갈린다.
겉모습이 객체처럼 보여서 바로 result.name처럼 쓸 수 있을 것 같기 때문이다.


하지만 실제로는 그전에 꼭 거쳐야 하는 단계가 있다.
바로 아래 줄이다.

  • const str = xhr.responseText;
  • const result = JSON.parse(str);

이 두 줄이 바로 이 예제의 핵심이다.
즉, 문자열로 받은 응답을 JSON.parse()로 객체로 바꾼 뒤 사용한다는 흐름이 여기서 처음 분명하게 드러난다.
이 단계를 거쳐야 이후에 result 안의 값을 속성이나 반복문으로 자연스럽게 다룰 수 있다.


그다음 중요한 부분은 반복문이다.

  • for (var i in result)
  • output += \<h3>\${result[i]}</h3>\;

여기서는 객체로 바꾼 뒤 그 안의 값들을 하나씩 꺼내 출력 문자열을 만들고 있다.
즉, 이 예제는 JSON을 그냥 화면에 그대로 붙이는 것이 아니라, 객체처럼 다룰 수 있는 형태로 바꾼 뒤 필요한 값을 꺼내는 방식을 보여 준다.


초보자가 여기서 꼭 기억해야 할 것은 반복문의 종류보다 흐름이다.
중요한 것은 JSON 응답을 문자열로 받고, 객체로 변환한 뒤, 그다음에야 값을 꺼내고 있다는 점이다.
즉, JSON.parse() 이전과 이후는 완전히 다르다고 이해하면 된다.


실행 결과를 어떻게 이해하면 되는가

실행하면 화면에 자바스크립트, 29, 웹앱개발 전용 OOP 언어가 차례대로 출력된다.
겉으로 보면 바로 앞의 XML 예제와 결과가 거의 비슷해 보인다.
즉, 출력값만 보면 둘이 크게 다른 것처럼 느껴지지 않을 수도 있다.


하지만 안쪽 처리 방식은 다르다.
초보자는 바로 이 차이를 꼭 잡아야 한다.

  • XML 예제는 태그 구조를 따라 값을 찾았다.
  • JSON 예제는 문자열을 객체로 바꾼 뒤 값을 꺼냈다.

즉, 결과가 비슷해 보여도 응답 형식이 다르면 처리 방식은 달라진다.
이 차이를 이해하는 것이 중요하다.
그래야 뒤에서 JSON 기반 응답이 나오는 로그인 예제나 외부 API 예제도 자연스럽게 이어진다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 서버가 JSON 형식의 응답을 보낸다.

  • 브라우저는 그 응답을 문자열로 받는다.

  • JSON.parse()로 객체로 바꾼다.

  • 필요한 값을 꺼내 현재 화면에 출력한다.

즉, JSON 응답은 “받자마자 바로 쓰는 것”이 아니라, 문자열 → 객체 변환 → 값 사용 순서를 반드시 거쳐야 한다.


이 실행 화면은 JSON 안의 값이 실제로 화면에 출력된 결과를 보여 준다.
즉, 응답 원문을 그대로 붙인 것이 아니라, 객체로 바꾼 뒤 필요한 값만 꺼내 현재 화면에 반영한 결과라고 보면 된다.


왜 이 예제가 중요한가

이 예제는 JSON 응답을 다루는 가장 기본적인 기준을 만들어 준다.
실제로 뒤에서 나오는 exam5, exam8, exam9도 결국은 이 흐름 위에서 움직인다.
즉, 응답을 받고, 문자열을 객체로 바꾸고, 필요한 값만 골라 사용하는 구조가 계속 반복된다.


특히 이 예제는 바로 앞의 XML 예제와 비교할 때 더 중요해진다.
둘 다 AJAX 요청을 보낸다.
둘 다 응답을 받아 화면에 출력한다.
하지만 응답을 읽는 방식은 다르다.

  • XML은 태그 구조를 따라 읽는다.

  • JSON은 객체로 바꾼 뒤 속성이나 반복문으로 읽는다.

즉, AJAX를 잘 이해한다는 것은 요청만 잘 보내는 것이 아니라, 응답 형식에 맞게 결과를 읽고 처리할 수 있다는 뜻이기도 하다.
이 예제는 그 기준을 가장 단순한 형태로 보여 준다.


여기서 꼭 기억할 핵심

JSON 응답은 먼저 문자열로 받고, JSON.parse()로 객체로 바꾼 다음 필요한 값을 꺼내 사용한다.
즉, JSON은 바로 쓰는 응답이 아니라, 객체로 변환한 뒤 다루는 응답 형식이다.
이 기준이 잡혀 있어야 뒤의 로그인 예제와 외부 API 예제도 자연스럽게 이해할 수 있다.



12. 예제 4 - 일정 시간마다 다시 요청해 화면을 갱신한다

이 예제는 AJAX 요청이 꼭 한 번만 일어나는 것은 아니라는 점을 보여 준다.
즉, 버튼을 눌렀을 때만 요청하는 것이 아니라, 일정 시간마다 다시 요청을 보내고 그때마다 화면 일부를 바꿀 수도 있다는 흐름을 확인하는 예제다.


앞의 예제들이 “한 번 요청하고 결과를 보여 주는 구조”였다면, 이 예제는 그 구조가 반복될 수 있다는 점까지 보여 준다.
즉, AJAX는 단발성 요청만 처리하는 기술이 아니라, 현재 화면을 유지한 채 필요한 정보만 계속 다시 받아 와 갱신하는 데도 사용할 수 있다.
이 예제의 핵심은 페이지 전체를 새로고침하지 않고도, 일정 시간마다 같은 위치의 내용만 계속 바꿀 수 있다는 점이다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 AJAX가 버튼 클릭 같은 한 번의 동작에만 쓰이는 것이 아니라, 시간 흐름에 따라 자동으로 반복 실행될 수도 있다는 점을 처음 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 3번 동기와 비동기
    요청을 보내고 응답이 도착했을 때 그때 결과를 처리하는 비동기 흐름과 연결된다.

  • 4번 AJAX의 동작 순서
    이벤트 시작 → 요청 전송 → 응답 도착 → 화면 반영 흐름이 반복된다는 점을 확인할 수 있다.

  • 5번 XMLHttpRequest 객체 이해하기
    new XMLHttpRequest(), open(), send(), onload가 반복 요청 안에서 어떻게 쓰이는지 확인할 수 있다.

  • 6번 요청과 응답을 읽는 기준
    이 예제는 responseText로 받은 JSON 문자열을 JSON.parse()로 객체로 바꿔 쓰는 흐름과 연결된다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    일정 시간마다 다시 요청해서 화면 일부를 계속 갱신하는 대표 패턴과 직접 연결된다.

  • 11번 예제 3 - JSON 응답은 객체로 바꿔서 읽는다
    JSON 응답을 문자열로 받은 뒤 객체로 바꿔 사용하는 방식이 실제 반복 갱신 예제에서 다시 등장한다.

즉, 이 예제는 새로운 기술을 갑자기 추가하는 것이 아니라, 앞에서 배운 비동기, XMLHttpRequest, JSON 처리 흐름이 반복 갱신 구조 안에서 어떻게 쓰이는지를 보여 주는 단계다.


exam4.html은 setInterval()을 사용해서 2초마다 서버에 다시 요청을 보낸다.
서버는 임의의 뉴스 문장을 JSON 형식으로 응답하고, 브라우저는 그 값을 받아 표 안의 한 칸만 바꾼다.
즉, 이 예제는 페이지 전체를 새로 여는 것이 아니라 특정 영역만 주기적으로 갱신하는 구조를 보여 준다.


핵심 코드

// exam4.html
<body>
	<h2>2초 간격으로 뉴스 요청 Ajax 통신</h2>
	<table border="1">
		<tr>
			<th>뉴스 내용</th>
		</tr>
		<tr>
			<td id="news">잠시 기다리세요.........................</td>
		</tr>
	</table>

	<script>
		window.addEventListener("load", function() {
			// 데이터 흐름: 2초마다 newsjson.jsp 요청 → JSON 응답 받기 → news 값으로 td 내용 교체
			setInterval(function() {
				const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

				xhr.onload = function(event) {
					if (xhr.status == 200) { // 요청 성공 여부 확인
						const str = xhr.responseText; // JSON 응답을 문자열로 받기
						const obj = JSON.parse(str); // 문자열을 객체로 변환
						const target = document.getElementById('news'); // 뉴스 출력 영역 선택

						target.textContent = obj.news; // news 값으로 화면 내용 교체
					}
				};

				xhr.open('GET', 'content/newsjson.jsp', true); // 뉴스 데이터 요청 준비
				xhr.send(); // 요청 전송
			}, 2000);
		});
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 setInterval()이다.
이 함수가 바로 이 예제를 앞선 예제들과 다르게 만든다.
앞 예제들은 버튼을 누르거나 페이지가 처음 열릴 때 한 번 실행되는 구조였다.
하지만 여기서는 같은 요청을 일정 시간마다 반복 실행한다.


즉, 이 예제의 출발점은 버튼 클릭이 아니라 시간 흐름이다.
초보자는 이 차이를 먼저 잡아야 한다.

  • 버튼 클릭형은 사용자가 직접 시작한다.

  • 반복 요청형은 시간이 지나면 자동으로 다시 시작된다.

하지만 둘 다 결국은 요청을 보내고, 응답을 받고, 화면 일부를 바꾼다는 점에서는 같은 구조다.


그다음 중요한 부분은 아래 흐름이다.

  • const str = xhr.responseText;
  • const obj = JSON.parse(str);
  • target.textContent = obj.news;

여기서는 서버가 보낸 JSON 응답을 문자열로 받은 뒤, 객체로 바꾸고, 그 안의 news 값만 꺼내 화면에 넣고 있다.
즉, 이 예제는 반복 요청 구조이면서 동시에 JSON 처리 구조도 함께 보여 준다.


마지막으로 꼭 봐야 하는 부분은 target.textContent = obj.news;이다.
여기서는 기존 내용을 지우고, 그 자리에 새 뉴스 문장으로 교체하고 있다.
즉, exam1처럼 결과를 계속 아래에 덧붙이는 구조가 아니라, 같은 위치의 내용을 계속 새 값으로 바꾸는 구조다.
이 차이 때문에 사용자는 페이지를 새로고침하지 않아도 화면 일부가 실시간처럼 계속 바뀌는 느낌을 받게 된다.


실행 결과를 어떻게 이해하면 되는가

실행 직후에는 “잠시 기다리세요...”라는 문장이 보인다.
그리고 2초가 지나면 뉴스 내용이 한 번 바뀐다.
그다음에도 2초마다 다시 요청이 일어나고, 올 때마다 같은 위치의 뉴스 문장이 새 내용으로 교체된다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 페이지가 열린다.

  • 2초마다 서버에 다시 요청을 보낸다.

  • 응답으로 받은 뉴스 문장을 읽는다.

  • 현재 화면의 같은 위치를 새 뉴스 내용으로 바꾼다.

즉, 결과가 아래로 계속 쌓이는 것이 아니라, 같은 위치가 주기적으로 갱신되는 구조다.
이 차이를 이해해야 AJAX의 활용 범위를 더 넓게 볼 수 있다.


이 실행 화면을 보면 페이지 전체는 그대로인데 뉴스 내용만 계속 바뀌는 것을 확인할 수 있다.
즉, AJAX는 새 페이지를 열지 않고도 현재 화면 일부를 반복적으로 갱신할 수 있다는 점이 눈에 보인다.


왜 이 예제가 중요한가

이 예제는 AJAX를 “버튼 눌렀을 때만 한 번 실행하는 기술”로 좁게 이해하지 않게 해 준다.
실제로 웹에서는 뉴스, 실시간 상태, 알림, 순위, 대기 정보처럼 계속 다시 확인해야 하는 데이터가 많다.
이때 페이지 전체를 계속 새로고침하면 불편하고 흐름도 끊기기 쉽다.


그래서 이 예제는 AJAX가 단순한 요청 기술을 넘어서, 현재 화면을 유지하면서 필요한 정보만 반복 갱신하는 방식이라는 점을 보여 준다.
즉, AJAX의 실용적인 느낌이 처음으로 더 강하게 드러나는 예제라고 볼 수 있다.


또 이 예제는 앞의 JSON 처리 예제를 실제 활용 쪽으로 한 단계 더 확장해 준다.
JSON을 한 번 읽고 끝내는 것이 아니라, 반복 요청 안에서 계속 읽고 화면에 반영하기 때문이다.
즉, 응답 형식 이해와 화면 갱신 패턴 이해가 함께 연결되는 중요한 예제다.


여기서 꼭 기억할 핵심

AJAX는 한 번만 쓰는 요청이 아니라, 일정 시간마다 다시 요청해서 화면 일부를 반복적으로 갱신하는 데도 사용할 수 있다.
즉, 이 예제의 핵심은 setInterval()로 같은 요청을 반복하고, 응답이 올 때마다 현재 화면의 같은 위치를 새 값으로 바꾼다는 점이다.
이 기준이 잡혀 있어야 뒤의 POST 전송 예제나 외부 API 예제도 더 자연스럽게 이어진다.



13. 예제 5 - 폼 입력값을 POST로 보내고 로그인 결과만 바꾼다

이 예제는 사용자가 입력한 값을 서버로 보내고, 응답 결과에 따라 현재 화면의 메시지만 바꾸는 흐름을 보여 준다.
즉, POST 요청, 요청 헤더 설정, JSON 응답 처리, 화면 일부 갱신이 한꺼번에 들어 있는 중요한 예제다.


앞의 예제들이 주로 데이터를 읽어 와서 보여 주는 흐름이었다면, 이 예제는 사용자가 직접 입력한 값을 서버로 보내서 처리 결과를 받는 흐름이라는 점에서 한 단계 더 실제 서비스 화면에 가깝다.
특히 로그인처럼 많이 보는 화면이기 때문에, 초보자도 “아, 이런 식으로 현재 화면 안에서 결과만 바꿀 수 있구나” 하고 감을 잡기 좋다.
이 예제의 핵심은 폼을 제출한다고 해서 항상 새 페이지로 가는 것이 아니라, 현재 화면 안에서 성공과 실패만 바로 보여 줄 수 있다는 점이다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 GET으로 읽어 오는 예제에서 한 걸음 더 나아가, 사용자가 입력한 값을 POST로 보내고 그 결과만 현재 화면에 반영하는 구조를 처음 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 3번 동기와 비동기
    폼을 눌렀다고 해서 새 페이지로 바로 이동하는 것이 아니라, 응답이 오면 그때 결과만 처리하는 비동기 흐름과 연결된다.

  • 4번 AJAX의 동작 순서
    이벤트 발생 → 요청 준비 → 요청 전송 → 응답 도착 → 화면 반영 흐름이 그대로 이어진다.

  • 5번 XMLHttpRequest 객체 이해하기
    open(), send(), onload 대신 addEventListener("load", ...)로 응답을 처리하는 방식까지 함께 확인할 수 있다.

  • 6번 요청과 응답을 읽는 기준
    POST 요청, Content-Type 설정, JSON.parse()를 통한 응답 처리 흐름이 실제 코드에서 드러난다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    폼 입력값을 보내고 성공 또는 실패 메시지만 바꾸는 대표적인 패턴과 직접 연결된다.

  • 11번 예제 3 - JSON 응답은 객체로 바꿔서 읽는다
    서버가 보낸 JSON 응답을 문자열로 받은 뒤 객체로 바꿔 결과를 판별하는 흐름과 연결된다.

즉, 이 예제는 새로운 기술을 갑자기 추가하는 것이 아니라, 앞에서 배운 POST, Content-Type, JSON 응답 처리, 현재 화면 일부 갱신 개념이 한꺼번에 묶여 나오는 단계다.


exam5.html은 아이디와 비밀번호를 입력받고, 버튼을 눌렀을 때 기본 폼 제출을 막은 뒤 AJAX로 서버에 값을 보낸다.
서버는 로그인 성공이면 ok, 실패면 fail이라는 JSON 응답을 돌려주고, 브라우저는 그 결과에 따라 메시지 색상과 내용을 바꾼다.
즉, 이 예제는 폼 전송도 현재 화면 안에서 처리할 수 있다는 점을 보여 준다.


핵심 코드

// exam5.html
<body>
	<h3>계정과 패스워드를 입력해 주세요.</h3>
	<form id="loginf" action="content/login.jsp">
		<table>
			<tr>
				<td><label for="id">계정</label></td>
				<td><input type="text" id="id" name="id" required></td>
			</tr>
			<tr>
				<td><label for="passwd">패스워드</label></td>
				<td><input type="password" id="passwd" name="passwd" required></td>
			</tr>
			<tr>
				<td><input type="submit" id="loginb" value="로그인"></td>
				<td><output></output></td>
			</tr>
		</table>
	</form>

	<script>
		window.addEventListener("load", function() {
			document.getElementById("loginb").onclick = handleButtonPress; // 로그인 버튼에 이벤트 연결
		});

		let xhr;
		let id, form;

		function handleButtonPress(e) {
			// 데이터 흐름: 기본 폼 제출 막기 → 입력값 조립 → POST 요청 → 응답 처리 함수로 이동
			e.preventDefault(); // 기본 폼 제출 방지

			xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성
			form = document.querySelector("#loginf"); // 폼 선택
			id = document.querySelector("#id"); // 아이디 입력칸 선택
			const passwd = document.querySelector("#passwd"); // 비밀번호 입력칸 선택

			const requestParam = `id=${id.value}&passwd=${passwd.value}`; // 서버로 보낼 데이터 조립

			xhr.addEventListener("load", handleResponse); // 응답 처리 함수 연결
			xhr.open("POST", form.action, true); // POST 요청 준비
			xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); // 폼 전송 형식 지정
			xhr.send(requestParam); // 입력값 전송
		}

		function handleResponse() {
			// 데이터 흐름: JSON 응답 결과 확인 → ok면 성공 메시지 → fail이면 실패 메시지와 입력 초기화
			const jsonObj = JSON.parse(xhr.responseText); // 응답 문자열을 객체로 변환
			const output = document.querySelector("output"); // 결과 출력 영역 선택

			if (jsonObj.result == "ok") {
				output.textContent = "로그인 성공!!";
				output.style.color = "blue";
			} else if (jsonObj.result == "fail") {
				output.textContent = "로그인 실패!!";
				output.style.color = "red";
				form.reset();
				id.focus();
			}
		}
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 e.preventDefault()다.
원래 폼 버튼을 누르면 브라우저는 기본적으로 폼을 제출하고, 결과에 따라 새 페이지처럼 이동하는 흐름이 생기기 쉽다.
그런데 여기서는 그 기본 동작을 먼저 막는다.
즉, 브라우저가 알아서 이동하지 못하게 한 뒤, 우리가 직접 AJAX로 요청을 보내는 구조다.


그다음 중요한 부분은 아래 흐름이다.

  • xhr.open("POST", form.action, true);
  • xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
  • xhr.send(requestParam);

이 부분은 사용자가 입력한 값을 서버로 실제 전송하는 핵심 구간이다.
여기서 POST를 사용하고 있다는 점이 중요하다.
즉, 이 예제는 데이터를 읽어 오는 것이 아니라 입력값을 서버에 보내 처리 결과를 받는 예제다.


또 Content-type을 설정한 이유도 중요하다.
서버가 “지금 어떤 형식의 데이터가 들어오는지”를 알아야 값을 자연스럽게 읽을 수 있기 때문이다.
초보자는 이 부분을 옵션처럼 가볍게 보기 쉽다.
하지만 여기서는 서버가 아이디와 비밀번호를 올바르게 해석하게 만드는 중요한 정보다.


응답 처리 쪽에서 가장 중요한 부분은 아래다.

  • const jsonObj = JSON.parse(xhr.responseText);
  • if (jsonObj.result == "ok") { ... }
  • else if (jsonObj.result == "fail") { ... }

즉, 서버는 성공 또는 실패 결과를 JSON으로 보내고, 브라우저는 그 응답을 문자열로 받은 뒤 객체로 바꿔서 결과를 판별한다.
그리고 그 결과에 따라 메시지 색상과 내용을 바꾼다.
즉, 이 예제는 “입력값 전송 → 서버 처리 → JSON 결과 반환 → 현재 화면 메시지 갱신” 흐름이 한 번에 연결되는 구조다.


또 실패했을 때 form.reset()과 id.focus()를 실행하는 점도 중요하다.
이 부분은 단순히 기능을 추가한 것이 아니라, 사용자가 다시 입력하기 편하게 만들어 주는 처리다.
즉, AJAX는 단순히 통신만 하는 것이 아니라, 응답 결과에 맞춰 화면 사용 흐름까지 자연스럽게 다듬는 데도 쓰인다는 점을 보여 준다.


실행 결과를 어떻게 이해하면 되는가

실제 테스트 기준으로 아이디는 ajaxtest, 비밀번호는 12345일 때 성공한다.
성공하면 파란색 성공 메시지가 출력된다.
실패하면 빨간색 실패 메시지가 출력된다.
그리고 실패한 경우에는 입력값이 초기화되고, 아이디 입력칸으로 다시 커서가 이동한다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 사용자가 아이디와 비밀번호를 입력한다.

  • 기본 폼 제출은 막는다.

  • 입력값을 POST로 서버에 보낸다.

  • 서버가 성공 또는 실패를 JSON으로 돌려준다.

  • 현재 화면의 메시지 영역만 바뀐다.

즉, 로그인 요청을 보냈다고 해서 새 페이지로 넘어가는 것이 아니라, 현재 화면 안에서 결과만 바뀌는 구조다.
이 차이를 이해해야 AJAX를 실제 폼 화면과 연결해서 볼 수 있다.

이 실행 화면을 보면 성공과 실패 결과가 새 페이지가 아니라 현재 화면 안에서 바로 바뀌는 것을 확인할 수 있다.
즉, 폼을 보냈다고 해서 화면 전체가 다시 열리는 것이 아니라, 필요한 메시지 영역만 갱신되는 흐름이다.


왜 이 예제가 중요한가

이 예제는 AJAX가 단순히 데이터를 읽어 오는 기술만이 아니라, 사용자 입력을 서버로 보내고 그 처리 결과를 현재 화면에 즉시 반영하는 기술이라는 점을 보여 준다.
즉, 실제 서비스 화면에서 정말 자주 쓰이는 구조를 가장 단순한 형태로 보여 주는 예제다.


특히 이 예제는 앞선 JSON 예제를 실제 활용 쪽으로 확장한다.
이전에는 JSON 값을 읽어 화면에 출력하는 흐름이었다.
하지만 여기서는 JSON이 성공과 실패를 구분하는 결과 데이터로 사용된다.
즉, 단순 출력이 아니라 응답 결과에 따라 다른 화면 반응을 만드는 단계로 넘어간 것이다.


또 이 예제는 폼 제출과 페이지 이동을 꼭 같은 것으로 볼 필요가 없다는 점도 분명하게 보여 준다.
폼 입력값을 보내더라도, 브라우저 기본 제출을 막고 AJAX로 처리하면 현재 화면 안에서 훨씬 자연스럽게 결과를 보여 줄 수 있다.
그래서 이 예제는 이후의 외부 API 예제와는 또 다른 의미로, 실제 웹 서비스 화면과 가장 가까운 예제라고 볼 수 있다.


여기서 꼭 기억할 핵심

폼 데이터를 POST 방식으로 보내고, 응답 결과에 따라 현재 화면의 메시지만 바꿀 수 있다는 점이 이 예제의 핵심이다.
즉, 폼 제출은 꼭 새 페이지 이동으로 이어지는 것이 아니라, AJAX를 사용하면 현재 화면 안에서 성공과 실패만 바로 처리할 수 있다.
이 기준이 잡혀 있어야 뒤의 이미지 응답 예제와 외부 API 예제도 자연스럽게 이어진다.



14. 예제 6 - 이미지 파일도 응답으로 받아 붙일 수 있다

이 예제는 AJAX가 텍스트나 JSON만 다루는 기술이 아니라, 이미지 같은 파일 응답도 받아서 화면에 추가할 수 있다는 점을 보여 준다.
즉, 서버 응답은 항상 글자 데이터만 오는 것이 아니며, 응답 형식이 달라지면 처리 방식도 달라진다는 점을 실제로 확인하는 예제다.


앞의 예제들이 문자열이나 JSON 응답을 읽어서 화면에 반영하는 흐름이었다면, 이 예제는 파일 데이터까지 현재 화면 안에서 처리할 수 있다는 점에서 한 단계 더 확장된 예제다.
특히 이미지를 요청하고 화면에 계속 붙여 나가는 모습을 보면, AJAX의 활용 범위가 생각보다 훨씬 넓다는 것을 쉽게 느낄 수 있다.
이 예제의 핵심은 AJAX가 글자 데이터만 가져오는 기술이 아니라, 이미지 같은 파일 응답도 현재 화면 안에서 다룰 수 있다는 점이다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 응답이 텍스트가 아니라 이미지 파일일 때는 왜 다른 방식으로 받아야 하는지 처음 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 4번 AJAX의 동작 순서
    이벤트 발생 → 요청 전송 → 응답 도착 → 화면 반영 흐름이 그대로 이어진다.

  • 5번 XMLHttpRequest 객체 이해하기
    new XMLHttpRequest(), open(), send(), onload가 실제로 어떻게 쓰이는지 다시 확인할 수 있다.

  • 6번 요청과 응답을 읽는 기준
    문자열은 responseText, XML은 responseXML, 이미지 같은 파일은 blob으로 받아야 한다는 기준이 실제 코드에서 드러난다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    이미지나 파일 데이터를 받아 현재 화면에 추가하는 대표적인 패턴과 직접 연결된다.

  • 9번 예제 1 - 같은 요청도 결과 반영 방식이 다르다
    새 페이지로 이동하지 않고 현재 화면 안에 결과를 붙인다는 기본 감각과 연결된다.

즉, 이 예제는 새로운 기술을 갑자기 추가하는 것이 아니라, 앞에서 배운 “응답 형식에 따라 읽는 방식이 달라진다”는 개념을 이미지 파일 기준으로 보여 주는 단계다.


exam6.html은 제목을 클릭할 때마다 서버에 이미지 파일을 요청한다.
그리고 응답으로 받은 이미지를 현재 화면에 계속 추가한다.
즉, 이 예제는 텍스트가 아닌 파일 응답도 AJAX로 받아 현재 화면 안에 붙일 수 있다는 흐름을 보여 준다.


핵심 코드

// exam6.html
<body>
	<h2 onclick="getImage();">이 행을 클릭해요. Ajax로 이미지를 요청하고 출력해요....</h2>

	<script>
		let imgname = 1;

		function getImage() {
			// 데이터 흐름: 클릭 → 이미지 번호 변경 → 이미지 파일 요청 → blob 응답을 img 태그로 화면에 추가
			imgname = imgname == 10 ? 1 : imgname + 1; // 다음 이미지 번호 계산

			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성
			xhr.responseType = 'blob'; // 응답을 파일 데이터로 받기

			xhr.onload = function(e) {
				if (this.status == 200) { // 요청 성공 여부 확인
					const blob = e.target.response; // 이미지 파일 데이터 꺼내기
					const img = document.createElement('img'); // img 태그 생성

					img.width = 100;
					img.height = 100;
					img.src = URL.createObjectURL(blob); // blob 데이터를 이미지 URL로 변환

					document.body.appendChild(img); // 화면에 이미지 추가
				}
			};

			xhr.open('GET', `/edu/images/${imgname}.jpg`, true); // 이미지 파일 요청 준비
			xhr.send(); // 요청 전송
		}
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 xhr.responseType = 'blob';이다.
이 줄이 바로 이 예제의 핵심이다.
앞의 예제들처럼 문자열이나 JSON을 받는 것이 아니라, 이미지 파일 데이터를 받겠다고 미리 알려 주는 설정이기 때문이다.


즉, 이 예제는 응답을 읽는 방식이 이전 예제들과 다르다.
문자열이라면 responseText로 읽으면 된다.
하지만 이미지는 글자가 아니라 파일 데이터이므로, 그에 맞는 방식으로 받아야 한다.
그래서 여기서는 blob을 사용한다.


그다음 중요한 부분은 아래 흐름이다.

  • const blob = e.target.response;
  • URL.createObjectURL(blob)
  • <img ... src=...>

여기서는 응답으로 받은 파일 데이터를 바로 화면에 보여 줄 수 있는 주소 형태로 바꾼 뒤, img 태그의 src에 연결하고 있다.
즉, 서버에서 받은 이미지를 그냥 문자열처럼 출력하는 것이 아니라, 브라우저가 화면에 표시할 수 있는 이미지로 바꿔서 붙이는 구조다.


마지막으로 중요한 부분은 document.body.innerHTML += ...이다.
여기서는 기존 내용을 지우는 것이 아니라, 이미지를 계속 뒤에 덧붙인다.
즉, 이 예제는 이미지를 한 장만 교체해서 보여 주는 것이 아니라, 클릭할 때마다 새 이미지를 현재 화면 아래에 계속 추가하는 구조다.
즉, 이 예제의 핵심은 이미지 파일 응답을 blob으로 받고, 그것을 현재 화면 안에 계속 누적해서 붙인다는 점이다.


또 imgname 값을 바꾸는 부분도 눈여겨볼 만하다.
이미지 번호를 하나씩 바꾸면서 다른 파일을 요청하고 있기 때문에, 클릭할 때마다 같은 이미지가 아니라 다음 이미지가 순서대로 붙는 흐름이 만들어진다.
즉, 요청 주소도 계속 달라지고 응답 이미지도 계속 달라진다.


실행 결과를 어떻게 이해하면 되는가

실행하면 처음에는 화면에 제목만 보인다.
그리고 제목을 한 번 클릭할 때마다 이미지가 한 장씩 추가된다.
다시 클릭하면 또 다른 이미지가 추가된다.
즉, 페이지 전체가 새로 열리는 것이 아니라, 현재 화면 안에 이미지 결과만 계속 쌓인다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 사용자가 제목을 클릭한다.

  • 브라우저가 서버에 이미지 파일을 요청한다.

  • 서버가 이미지 데이터를 응답으로 돌려준다.

  • 브라우저는 그 파일 데이터를 화면에 표시할 수 있는 이미지로 바꾼다.

  • 현재 화면 아래에 이미지를 추가한다.

즉, 이 예제는 “이미지 파일도 응답 결과가 될 수 있고, 그 결과를 현재 화면 안에 붙일 수 있다”는 흐름을 보여 준다.
이 차이를 이해해야 AJAX를 텍스트 통신 기술로만 좁게 이해하지 않게 된다.


이 실행 화면을 보면 제목을 클릭할 때마다 이미지가 계속 추가되는 것을 확인할 수 있다.
즉, 새 페이지로 이동하는 것이 아니라, 현재 문서 안에 결과가 누적되는 구조라는 점이 눈에 보인다.


왜 이 예제가 중요한가

이 예제는 AJAX의 활용 범위를 넓혀서 이해하게 해 준다.
앞의 예제들만 보면 AJAX는 문자열이나 JSON 같은 글자 데이터만 다루는 기술처럼 느껴질 수 있다.
하지만 실제로는 이미지 같은 파일 응답도 받을 수 있다.
즉, AJAX는 단순한 텍스트 통신 기술이 아니라, 서버 응답을 현재 화면 안에서 유연하게 다루는 방식이라고 볼 수 있다.


또 이 예제는 응답 형식이 달라지면 읽는 방식도 달라져야 한다는 점을 다시 한 번 분명하게 보여 준다.

  • 문자열 응답은 responseText

  • XML 응답은 responseXML

  • JSON 응답은 JSON.parse()

  • 이미지 같은 파일 응답은 blob

즉, 요청 구조는 비슷해 보여도 응답 형식에 맞는 처리 방식을 선택해야 한다는 기준을 다시 확인하게 해 준다.
이 기준이 잡혀 있어야 뒤의 외부 API 예제도 더 자연스럽게 이해할 수 있다.


여기서 꼭 기억할 핵심

응답이 텍스트가 아니라 이미지 같은 파일일 때는 blob으로 받고, 그 데이터를 현재 화면에 추가할 수 있다.
즉, AJAX는 글자 데이터만 처리하는 기술이 아니라, 파일 응답도 현재 화면 안에서 다룰 수 있는 방식이다.
이 기준이 잡혀 있어야 뒤의 외부 API 예제까지 흐름이 자연스럽게 이어진다.



15. 예제 7 - 응답 원문을 먼저 확인해 보는 이유

이 예제는 로컬 자원과 외부 자원을 요청하고, 응답 원문을 그대로 확인하는 예제다.
즉, 결과를 예쁘게 꾸며서 보여 주는 것이 목적이 아니라, 응답이 실제로 왔는지, 어떤 형식으로 왔는지, 왜 어떤 요청은 되고 어떤 요청은 막히는지를 먼저 확인하는 데 의미가 있다.


앞의 예제들은 응답을 받아 바로 화면에 반영하거나 가공하는 흐름이 중심이었다.
반면 이 예제는 그 전에 꼭 필요한 한 단계를 보여 준다.
바로 응답 원문을 먼저 확인하는 단계다.
즉, 이 예제의 핵심은 화면을 예쁘게 만드는 것이 아니라, 서버가 실제로 무엇을 돌려줬는지 먼저 확인하는 습관을 만드는 데 있다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 로컬 자원과 외부 자원을 요청했을 때, 응답이 잘 오는 경우와 브라우저 보안 정책 때문에 막히는 경우를 비교해서 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 6번 요청과 응답을 읽는 기준
    응답을 가공하기 전에 responseText로 원문부터 확인하는 흐름과 연결된다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    외부 API 데이터를 받아 먼저 확인하고, 그다음 필요한 값만 골라 쓰는 패턴과 연결된다.

  • 8번 AJAX에서 꼭 알아야 할 제한 사항
    SOP, CORS 때문에 어떤 외부 요청은 되고 어떤 요청은 막힐 수 있다는 개념과 직접 연결된다.

  • 9번 예제 1 - 같은 요청도 결과 반영 방식이 다르다
    요청 결과를 새 페이지로 이동하지 않고 현재 화면 안에 보여 준다는 기본 감각과 연결된다.

  • 11번 예제 3 - JSON 응답은 객체로 바꿔서 읽는다
    JSON.parse()로 가공하기 전에, 먼저 응답 원문 구조부터 확인하는 흐름과 연결된다.

즉, 이 예제는 새로운 기술을 갑자기 추가하는 것이 아니라, 외부 자원을 다루기 전에 응답이 실제로 왔는지부터 확인해야 한다는 기준을 세워 주는 단계다.


exam7.html은 요청할 주소를 바꿔 가며 실행할 수 있는 구조다.
로컬 자원 /edu/first.html을 요청했을 때는 응답 원문이 그대로 잘 출력된다.
또 이 실습에서는 외부 KOBIS Open API 원문도 확인할 수 있었다.
반면 버스 관련 Open API는 이 실습 환경에서 브라우저의 CORS 정책 때문에 차단되는 결과를 확인했다.
즉, 이 예제는 로컬 요청 성공, 외부 요청 성공, 외부 요청 차단을 한 번에 비교해서 보여 준다.


전체 코드

// exam7.html
<body>
	<h1>다양한 자원으로의 AJAX 요청</h1>
	<hr>
	<div></div>

	<script>
		window.addEventListener("load", function() {
			// 데이터 흐름: url 값 변경 → 해당 자원 요청 → 응답 원문을 div에 그대로 출력
			/* let url = "/edu/first.html"; */
			/* let url = "http://www.kobis.or.kr/kobisopenapi/webservice/rest/boxoffice/searchDailyBoxOfficeList.json?key=75474bdfc6c0a4eb738939dd66c101b5&targetDt=20250710"; */
			/* let url = "http://openapi.seoul.go.kr:8088/796143536a756e69313134667752417a/json/LampScpgmtb/1/100/"; */

			let url = "http://ws.bus.go.kr/api/rest/busRouteInfo/getBusRouteList?ServiceKey=%2BjzsSyNtwmcqxUsGnflvs3rW2oceFvhHR8AFkM3ao%2Fw50hwHXgGyPVutXw04uAXvrkoWgkoScvvhlH7jgD4%2FRQ%3D%3D&strSrch=360";

			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.addEventListener("load", function() {
				document.getElementsByTagName('div')[0].textContent = xhr.responseText; // 응답 원문 출력
			});

			xhr.open("GET", url, true); // 선택한 url로 요청 준비
			xhr.send(); // 요청 전송
		});
	</script>
</body>

이 예제는 전체 코드를 같이 보는 것이 중요하다.
왜냐하면 핵심이 단순히 responseText 한 줄에 있는 것이 아니라, 같은 구조의 코드에서 url만 바꿔 가며 결과를 비교하는 실험 방식 자체에 있기 때문이다.


즉, 이 예제는 “특정 코드가 무엇을 하느냐”보다 “같은 코드로 어떤 대상을 요청하느냐에 따라 결과가 어떻게 달라지느냐”를 보는 예제다.
그래서 전체 구조를 같이 봐야 의미가 제대로 살아난다.


코드에서 꼭 봐야 하는 부분

이 코드에서 가장 먼저 봐야 하는 부분은 url이다.
여기 자리에 어떤 주소를 넣느냐에 따라 결과가 완전히 달라진다.
초보자는 바로 이 점을 먼저 잡아야 한다.

  • 로컬 자원을 넣으면 응답 원문이 정상적으로 출력된다.

  • 외부 API 주소를 넣으면 응답 원문이 출력될 수도 있다.

  • 어떤 외부 API는 CORS 정책 때문에 차단될 수 있다.

즉, 이 예제는 요청 코드 자체가 복잡한 것이 아니라, 요청 대상에 따라 결과가 달라지는 구조를 보여 주는 데 의미가 있다.


그다음 중요한 부분은 아래다.

  • xhr.open("GET", url, true);
  • xhr.send();

이 부분은 선택한 주소로 실제 요청을 보내는 구간이다.
즉, url에 넣은 대상이 실제로 이 코드에 의해 시험된다.
그래서 이 예제는 특정 한 자원을 설명하는 코드가 아니라, 여러 자원을 같은 방식으로 비교해 보는 코드라고 이해하는 것이 맞다.


마지막으로 가장 중요한 부분은 아래다.

  • document.getElementsByTagName("div")[0].textContent = xhr.responseText;

이 줄은 응답을 가공하지 않고 원문 그대로 출력한다.
여기서는 JSON.parse()도 하지 않고, 태그를 찾아 값을 꺼내지도 않는다.
그냥 서버가 돌려준 내용을 문자 그대로 보여 준다.
즉, 이 예제는 화면 꾸미기 예제가 아니라, 응답 확인 예제다.
그래서 이 단계에서는 예쁘게 만드는 것보다, 서버가 실제로 무엇을 돌려줬는지 먼저 확인하는 것이 더 중요하다.


실행 결과를 어떻게 이해하면 되는가

이 예제는 요청 대상을 어떻게 바꾸느냐에 따라 결과가 달라진다.
즉, 한 가지 성공 화면만 보는 예제가 아니라, 여러 상황을 비교해서 보는 예제다.
초보자는 아래처럼 나눠서 이해하면 가장 쉽다.

  • 로컬 자원 /edu/first.html을 요청하면 응답 원문이 정상적으로 출력된다.

  • 외부 KOBIS Open API를 요청하면 JSON 원문이 출력될 수 있다.

  • 버스 관련 Open API를 요청하면 CORS 정책 때문에 차단될 수 있다.

즉, 외부 요청이라고 해서 무조건 안 되는 것도 아니고, 외부 요청이라고 해서 무조건 되는 것도 아니다.
브라우저 정책과 서버 허용 설정에 따라 결과가 달라질 수 있다는 점이 중요하다.


초보자는 이 예제를 아래 흐름으로 이해하면 된다.

  • 먼저 요청을 보낸다.

  • 응답이 오면 원문을 그대로 본다.

  • 잘 보이면 구조를 확인할 수 있다.

  • 막히면 코드가 아니라 브라우저 정책이나 서버 허용 문제를 의심할 수 있다.

즉, 이 예제는 응답 데이터를 예쁘게 쓰기 전에, 먼저 확인하고 원인을 구분하는 기준을 세워 준다.


이 화면은 로컬 자원을 요청했을 때 응답 원문이 정상적으로 출력되는 모습을 보여 준다.
즉, 같은 출처 자원은 비교적 자연스럽게 응답 내용을 확인할 수 있다는 뜻이다.


이 화면은 외부 API 요청에서도 응답 원문이 출력될 수 있다는 점을 보여 준다.
즉, 외부 요청이라고 해서 항상 막히는 것은 아니라는 뜻이다.


이 화면은 외부 요청이 CORS 정책 때문에 차단될 수 있다는 점을 보여 준다.
즉, 코드 문법이 맞아도 브라우저 보안 정책 때문에 응답을 읽지 못할 수 있다는 뜻이다.


왜 이 예제가 중요한가

이 예제는 외부 데이터를 다룰 때 가장 중요한 습관 하나를 만들어 준다.
바로 응답 원문부터 먼저 확인하는 습관이다.
이 습관이 없으면 초보자는 응답 구조도 모른 채 바로 값을 꺼내려고 하다가 더 헷갈리기 쉽다.
또 외부 요청이 막혔을 때도 무조건 코드 문제라고 생각하기 쉽다.


하지만 이 예제를 이해하면 생각 순서가 달라진다.

  • 응답이 실제로 오는가

  • 온다면 어떤 형식인가

  • 원문 구조는 어떻게 생겼는가

  • 안 온다면 브라우저 정책이나 서버 허용 설정 문제는 없는가

즉, 이 예제는 단순한 출력 예제가 아니라, 외부 API를 다룰 때 문제를 보는 기준 자체를 잡아 주는 예제다.


특히 뒤의 exam8, exam9처럼 외부 API에서 필요한 값을 꺼내 표로 구성하는 예제를 이해하려면, 먼저 이런 확인 단계가 왜 필요한지 알아야 한다.
응답 원문을 먼저 보지 않으면 그 안에서 어떤 값을 꺼내야 하는지도 알기 어렵기 때문이다.
즉, 이 예제는 뒤 예제들의 준비 단계 역할도 함께 한다.


여기서 꼭 기억할 핵심

외부 자원을 다룰 때는 바로 가공부터 하지 말고, 먼저 응답 원문이 실제로 오는지부터 확인해야 한다.
즉, 이 예제의 핵심은 응답을 예쁘게 만드는 것이 아니라, 로컬 요청 성공, 외부 요청 성공, 외부 요청 차단을 비교하면서 AJAX 통신과 브라우저 보안 제한을 함께 이해하는 데 있다.
이 기준이 잡혀 있어야 뒤의 외부 API 활용 예제도 자연스럽게 이어진다.



16. 예제 8 - 외부 JSON 응답에서 필요한 값만 골라 본다

이 예제는 외부 JSON 데이터를 받아 먼저 전체 원문을 확인하고, 그다음 필요한 값만 따로 꺼내 활용하는 흐름을 보여 준다.
즉, 응답 전체를 보는 것과, 그 안에서 필요한 데이터만 골라 쓰는 것이 서로 다른 단계라는 점을 이해하기 좋은 예제다.


앞의 exam7이 “응답 원문을 먼저 확인해야 한다”는 기준을 보여 줬다면, 이 예제는 그다음 단계로 나아간다.
즉, 원문을 본 뒤 끝나는 것이 아니라, 그 안에서 필요한 값 하나를 실제로 꺼내 보는 단계다.
이 예제의 핵심은 외부 API 응답을 처음부터 예쁘게 꾸미는 것이 아니라, 먼저 전체 구조를 확인하고 그다음 필요한 값만 골라 쓰는 순서를 익히는 데 있다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 외부 API에서 받은 JSON 응답을 다룰 때, 왜 전체 원문을 먼저 보고 그다음 필요한 값만 골라야 하는지 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 6번 요청과 응답을 읽는 기준
    JSON 응답은 문자열로 받은 뒤 JSON.parse()로 객체로 바꿔서 읽는다는 기준과 연결된다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    외부 API 데이터를 받아 먼저 확인하고, 그 안에서 필요한 값만 골라 쓰는 패턴과 직접 연결된다.

  • 8번 AJAX에서 꼭 알아야 할 제한 사항
    외부 자원을 읽을 때 브라우저 보안 정책과 서버 허용 설정을 함께 봐야 한다는 점과 연결된다.

  • 11번 예제 3 - JSON 응답은 객체로 바꿔서 읽는다
    JSON 문자열을 객체로 바꾼 뒤 필요한 값을 꺼내는 기본 흐름이 외부 API 예제에서도 그대로 이어진다.

  • 15번 예제 7 - 응답 원문을 먼저 확인해 보는 이유
    응답을 바로 가공하지 말고, 먼저 원문 구조부터 확인해야 한다는 기준과 직접 연결된다.

즉, 이 예제는 새로운 내용을 갑자기 추가하는 것이 아니라, 앞에서 배운 “원문 확인 → 구조 파악 → 필요한 값 추출” 흐름을 외부 API 기준으로 실제 확인하는 단계다.


exam8.html은 영화진흥위원회 Open API를 요청하고, 받은 응답 원문을 div에 그대로 출력한다.
그리고 코드에서는 console.log()를 이용해 첫 번째 영화 이름을 따로 추출해서 확인한다.
즉, 이 예제는 전체 응답 확인 → 필요한 값 하나 추출이라는 두 단계를 가장 단순하게 보여 준다.


핵심 코드

// exam8.html
<body>
	<div class="jumbotron text-center">
		<h1>일별 박스 오피스</h1>
		<p>영화관 입장권 통합 전산망 오픈 API 를 AJAX 기술로 활용합니다.</p>
	</div>
	<hr>
	<div id="target"></div>

	<script>
		window.onload = function() {
			// 데이터 흐름: KOBIS API 요청 → JSON 원문 화면 출력 → 첫 번째 영화명만 콘솔에서 확인
			const url = "http://www.kobis.or.kr/kobisopenapi/webservice/rest/boxoffice/searchDailyBoxOfficeList.json?key=75474bdfc6c0a4eb738939dd66c101b5&targetDt=20250713";
			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.onload = function() {
				document.getElementById('target').textContent = xhr.responseText; // 응답 원문 출력
				console.log(JSON.parse(xhr.responseText).boxOfficeResult.dailyBoxOfficeList[0].movieNm); // 첫 번째 영화명 확인
			};

			xhr.open("GET", url, true); // API 요청 준비
			xhr.send(); // 요청 전송
		};
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 아래다.

  • document.getElementById('target').textContent = xhr.responseText;
  • console.log(JSON.parse(xhr.responseText).boxOfficeResult.dailyBoxOfficeList[0].movieNm);

이 두 줄이 바로 이 예제의 핵심이다.
첫 번째 줄은 응답 전체를 그대로 보여 준다.
두 번째 줄은 그 응답 안에서 필요한 값 하나만 꺼내 확인한다.
즉, 이 예제는 전체 확인과 값 추출이 서로 다른 단계라는 점을 코드 한 번으로 보여 준다.


초보자는 외부 API를 처음 보면 바로 필요한 값부터 찾으려고 하기 쉽다.
하지만 그러면 응답 구조를 모른 채 억지로 속성 이름만 따라가게 되어서 더 헷갈리기 쉽다.
그래서 이 예제에서는 먼저 원문을 그대로 보여 준다.
그다음 그 안에서 필요한 값 하나를 골라 꺼낸다.
즉, 순서가 중요하다.


또 JSON.parse(xhr.responseText) 부분도 중요하다.
외부 API 응답도 처음에는 문자열로 들어오기 때문에, 그대로는 속성처럼 접근할 수 없다.
그래서 먼저 객체로 바꿔야 한다.
그 뒤에야 아래처럼 구조를 따라 내려갈 수 있다.

  • boxOfficeResult
  • dailyBoxOfficeList
  • [0]
  • movieNm

즉, 이 예제는 단순히 영화 제목 하나를 꺼내는 예제가 아니다.
외부 JSON 응답 안에서 필요한 값을 어떻게 찾아 내려가는지를 보여 주는 예제다.
중요한 것은 영화 제목 자체가 아니라, 전체 구조를 보고 필요한 위치까지 찾아가는 흐름을 익히는 것이다.


실행 결과를 어떻게 이해하면 되는가

실행하면 화면에는 JSON 원문이 길게 출력된다.
이것은 응답 구조를 전체로 확인하기 위한 결과다.
즉, “서버가 어떤 모양으로 데이터를 보내 줬는가”를 먼저 보는 단계다.


그리고 코드에서는 그 안의 첫 번째 영화 이름을 따로 꺼내 console에 출력한다.
즉, 화면에 보이는 원문과 별개로, 필요한 데이터 하나만 골라서 따로 사용할 수 있다는 점을 보여 준다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 외부 API에 요청을 보낸다.

  • 응답 원문을 먼저 확인한다.

  • JSON.parse()로 객체로 바꾼다.

  • 필요한 값 하나를 구조를 따라 찾아 꺼낸다.

즉, 이 예제는 “전체 응답을 읽는 단계”와 “필요한 값을 뽑아 쓰는 단계”를 구분해서 보여 준다.
이 차이를 알아야 나중에 표를 만들거나 목록을 구성할 때도 훨씬 덜 헷갈린다.


이 실행 화면은 외부 API 응답 원문이 그대로 출력된 모습을 보여 준다.
즉, 예쁘게 가공하기 전에 먼저 구조를 확인하는 단계가 왜 필요한지 눈으로 확인할 수 있다.


왜 이 예제가 중요한가

이 예제는 외부 API를 다룰 때 가장 중요한 흐름 하나를 분명하게 만들어 준다.
바로 원문 구조를 먼저 보고, 그다음 필요한 값만 골라 쓴다는 흐름이다.
이 기준이 없으면 초보자는 응답 구조도 모른 채 속성 이름만 억지로 따라가다가 더 헷갈리기 쉽다.


또 이 예제는 바로 다음 단계로 넘어가기 위한 준비 역할도 한다.
이 예제에서는 첫 번째 영화 제목 하나만 꺼내 본다.
하지만 다음 단계에서는 그보다 더 나아가 여러 값을 골라서 표나 목록으로 다시 구성하게 된다.
즉, 이 예제는 값 하나를 정확히 찾는 연습이라고 볼 수 있다.


그래서 이 예제를 통해 초보자가 꼭 잡아야 할 기준은 아래와 같다.

  • 외부 API 응답은 먼저 전체 구조를 확인한다.

  • 필요한 값은 그다음에 꺼낸다.

  • JSON 응답은 문자열이므로 먼저 객체로 바꿔야 한다.

즉, 외부 API를 다룬다는 것은 단순히 주소를 요청하는 것이 아니라, 응답 구조를 읽고 필요한 위치를 정확히 찾는 과정까지 포함한다는 뜻이다.


여기서 꼭 기억할 핵심

외부 API 응답은 먼저 전체 구조를 확인하고, 그 안에서 필요한 값만 골라 사용하는 흐름으로 접근해야 한다.
즉, 이 예제의 핵심은 응답 전체를 먼저 보고, JSON.parse()로 객체로 바꾼 뒤, 필요한 데이터 하나를 정확히 찾아 꺼내는 데 있다.
이 기준이 잡혀 있어야 바로 다음 표 구성 예제도 자연스럽게 이해할 수 있다.



17. 예제 9 - 외부 API 데이터를 표로 다시 구성한다

이 예제는 외부 API 데이터를 받아 표로 다시 구성하는 완성형 예제다.
외부 API에서 JSON 데이터를 받아 필요한 값만 골라내고, 그 값을 표 형태로 가공해서 현재 화면에 다시 출력한다.
즉, 단순히 데이터를 받는 단계에서 끝나는 것이 아니라, 받은 데이터를 다시 보기 좋은 구조로 바꾸는 단계까지 포함한다.


앞의 exam8이 “응답 원문을 먼저 보고 필요한 값 하나를 꺼내는 단계”였다면, 이 예제는 거기서 한 걸음 더 나아간다.
즉, 값 하나만 확인하는 것이 아니라 여러 값을 골라 표 구조로 다시 만드는 단계다.
이 예제의 핵심은 외부 API에서 받은 데이터를 그대로 보여 주는 것이 아니라, 필요한 값만 뽑아서 사용자가 보기 쉬운 화면으로 다시 구성하는 데 있다.


이 예제가 보여주는 상황

이 예제는 앞에서 정리한 개념들이 실제 코드에서 어떻게 연결되는지 보여 준다.
특히 외부 JSON 응답에서 필요한 값만 골라, 그것을 표 형태로 다시 만들어 현재 화면에 넣는 흐름을 확인하는 단계라고 보면 된다.


이 예제와 직접 연결되는 개념은 아래와 같다.

  • 6번 요청과 응답을 읽는 기준
    JSON 응답을 문자열로 받은 뒤 JSON.parse()로 객체로 바꾸는 흐름과 연결된다.

  • 7번 AJAX가 자주 쓰이는 화면 처리 패턴
    외부 API 데이터를 받아 가공해서 표나 목록으로 다시 출력하는 대표 패턴과 직접 연결된다.

  • 8번 AJAX에서 꼭 알아야 할 제한 사항
    외부 자원을 읽을 때 브라우저 보안 정책과 서버 허용 설정을 함께 봐야 한다는 점과 연결된다.

  • 11번 예제 3 - JSON 응답은 객체로 바꿔서 읽는다
    JSON 문자열을 객체로 바꾼 뒤 필요한 값을 꺼내는 기본 흐름이 그대로 이어진다.

  • 15번 예제 7 - 응답 원문을 먼저 확인해 보는 이유
    외부 API는 먼저 응답 구조를 확인한 뒤, 그 안에서 필요한 값을 꺼내야 한다는 기준과 연결된다.

  • 16번 예제 8 - 외부 JSON 응답에서 필요한 값만 골라 본다
    값 하나를 정확히 찾는 단계에서 더 나아가, 여러 값을 뽑아 표로 재구성하는 단계와 직접 연결된다.

즉, 이 예제는 새로운 내용을 갑자기 추가하는 것이 아니라, 앞에서 배운 “원문 확인 → 구조 파악 → 필요한 값 추출” 흐름을 표 구성 화면까지 확장한 단계다.


exam9.html은 버튼을 누르면 날짜에 맞는 KOBIS Open API 요청을 보낸다.
그리고 응답으로 받은 영화 순위 데이터에서 영화명, 관객 수, 누적 관객 수, 스크린 수를 꺼내 표 본문에 다시 채운다.
즉, 이 예제는 외부 API 데이터를 실제 화면용 표로 다시 만드는 가장 완성된 흐름을 보여 준다.


핵심 코드

// exam9.html
<body>
	<header class="jumbotron text-center">
		<h1>일별 박스 오피스</h1>
		<p>영화관 입장권 통합 전산망 오픈 API 를 AJAX 기술로 활용합니다.</p>
	</header>

	<nav>
		<button type="button" class="btn btn-outline-primary" onclick="displayMovieRanking(1)">1일전</button>
		<button type="button" class="btn btn-outline-info" onclick="displayMovieRanking(2)">2일전</button>
		<button type="button" class="btn btn-outline-success" onclick="displayMovieRanking(3)">3일전</button>
	</nav>

	<section>
		<table class="table table-hover">
			<thead>
				<tr>
					<th scope="col">영화명</th>
					<th scope="col">해당일 관객수</th>
					<th scope="col">누적 관객수</th>
					<th scope="col">스크린수</th>
				</tr>
			</thead>
			<tbody>
			</tbody>
		</table>
	</section>

	<script>
		function getFormatDate(date) {
			// 데이터 흐름: Date 객체 → yyyyMMdd 형식 문자열로 변환
			const year = date.getFullYear();
			let month = (1 + date.getMonth());
			month = month >= 10 ? month : '0' + month;
			let day = date.getDate();
			day = day >= 10 ? day : '0' + day;

			return "" + year + month + day; // API 요청용 날짜 문자열 반환
		}

		function displayMovieRanking(n) {
			// 데이터 흐름: 버튼 값 n → n일 전 날짜 계산 → API 요청 주소 생성 → 영화 데이터를 tbody에 출력
			const today = new Date();
			const d = today.getTime() - (n * 24 * 60 * 60 * 1000);
			const targetday = new Date(d);
			const targetDt = getFormatDate(targetday); // 요청 날짜 생성

			const url = "http://www.kobis.or.kr/kobisopenapi/webservice/rest/boxoffice/searchDailyBoxOfficeList.json?key=75474bdfc6c0a4eb738939dd66c101b5&targetDt=" + targetDt;
			const xhr = new XMLHttpRequest(); // AJAX 통신 객체 생성

			xhr.onload = function() {
				// 데이터 흐름: JSON 응답 → 영화 목록 배열 접근 → tr 문자열 생성 → tbody 교체
				const jsonObj = JSON.parse(xhr.responseText); // 응답 문자열을 객체로 변환
				const dom = document.getElementsByTagName('tbody')[0]; // 표 본문 선택

				let content = "";

				for (let i = 0; i < 5; i++) {
					content += "<tr><th scope='row'>" + jsonObj.boxOfficeResult.dailyBoxOfficeList[i].movieNm +
						"</th><td>" + jsonObj.boxOfficeResult.dailyBoxOfficeList[i].audiCnt +
						"</td><td>" + jsonObj.boxOfficeResult.dailyBoxOfficeList[i].audiAcc +
						"</td><td>" + jsonObj.boxOfficeResult.dailyBoxOfficeList[i].scrnCnt + "</td></tr>";
				}

				dom.innerHTML = content; // tbody에 영화 순위 출력
			};

			xhr.open("GET", url, true); // API 요청 준비
			xhr.send(); // 요청 전송
		}
	</script>
</body>

이 코드에서 가장 먼저 봐야 하는 부분은 날짜를 만드는 흐름이다.
이 예제는 단순히 정해진 주소 하나를 요청하는 것이 아니라, 사용자가 누른 버튼에 따라 다른 날짜 데이터를 요청하는 구조이기 때문이다.


즉, n값에 따라 오늘 기준 며칠 전 날짜를 계산하고, 그 날짜를 API가 요구하는 형식의 문자열로 바꾼 뒤 요청 주소에 붙인다.
여기서 중요한 것은 날짜 계산 공식 자체보다, 요청 주소가 상황에 따라 바뀐다는 점이다.
즉, 같은 코드라도 요청 대상 데이터가 계속 달라질 수 있다.


그다음 중요한 부분은 아래 흐름이다.

  • const jsonObj = JSON.parse(xhr.responseText);
  • jsonObj.boxOfficeResult.dailyBoxOfficeList[i]

여기서는 외부 API에서 받은 응답을 객체로 바꾼 뒤, 그 안의 영화 목록까지 구조를 따라 내려가고 있다.
즉, 이 예제도 결국은 JSON 응답 구조를 제대로 읽을 수 있어야 이해할 수 있다.
초보자는 여기서 “왜 이렇게 길게 내려가지?” 하고 막힐 수 있다.
하지만 핵심은 단순하다.
응답 구조 안에서 원하는 위치까지 찾아 들어간다는 것이다.


마지막으로 가장 중요한 부분은 아래다.

  • let content = "";
  • 반복문으로 <tr>...</tr> 문자열 만들기
  • dom.innerHTML = content;

이 부분이 바로 이 예제의 핵심이다.
여기서는 응답을 그대로 출력하지 않는다.
또 값 하나만 console에 찍고 끝내지도 않는다.
대신 여러 값을 뽑아서 표 행 문자열을 만들고, 그 완성된 결과를 tbody에 한 번에 넣는다.
즉, 데이터 수집 단계에서 끝나는 것이 아니라, 화면 구성 단계까지 들어간 예제다.
중요한 것은 영화 데이터 자체가 아니라, 외부 데이터를 현재 화면 구조에 맞게 다시 조립하고 있다는 점이다.


또 dom.innerHTML = content;를 사용했기 때문에, 버튼을 다시 누르면 이전 데이터 뒤에 덧붙는 것이 아니라 같은 표 본문이 새 데이터로 교체된다.
즉, 이 예제는 데이터를 누적하는 예제가 아니라, 현재 화면의 같은 영역을 새 데이터로 다시 채우는 예제다.


실행 결과를 어떻게 이해하면 되는가

처음에는 표 본문이 비어 있거나 기본 상태로 보인다.
그리고 버튼을 누르면 그 날짜에 맞는 영화 데이터가 표에 채워진다.
다른 버튼을 누르면 같은 표가 다른 날짜 데이터로 다시 갱신된다.
즉, 페이지 전체를 다시 여는 것이 아니라 표 데이터만 다시 채워지는 구조다.


초보자는 이 예제를 아래처럼 이해하면 가장 쉽다.

  • 버튼을 누른다.

  • 그 버튼에 맞는 날짜를 계산한다.

  • 날짜를 붙여 외부 API에 요청한다.

  • JSON 응답을 객체로 바꾼다.

  • 필요한 값만 골라 표 행 문자열을 만든다.

  • 현재 화면의 tbody를 새 데이터로 바꾼다.

즉, 이 예제는 외부 데이터를 그냥 받는 데서 끝나는 것이 아니라, 현재 화면에 맞는 모양으로 다시 만들어 넣는 과정까지 포함한다.
이 점이 앞 예제들과 가장 큰 차이다.


이 실행 화면을 보면 버튼을 누를 때마다 표 내용이 바뀌는 것을 확인할 수 있다.
즉, 페이지 전체가 이동하는 것이 아니라, 현재 화면의 표 본문만 날짜에 맞는 데이터로 다시 갱신되는 구조라는 점이 눈에 보인다.


왜 이 예제가 중요한가

이 예제는 외부 API 활용 흐름의 거의 완성형이라고 볼 수 있다.
앞의 예제들은 응답 원문을 확인하거나, 값 하나를 꺼내는 단계까지였다.
하지만 이 예제는 그보다 더 나아가 여러 데이터를 뽑아 실제 화면 구조로 다시 조립하는 단계를 보여 준다.
즉, 실무 화면에 훨씬 가까운 흐름이다.


특히 이 예제를 통해 초보자가 꼭 잡아야 하는 기준은 아래와 같다.

  • 외부 API 응답은 먼저 구조를 알아야 한다.

  • 필요한 값만 골라서 사용해야 한다.

  • 화면에 맞는 구조로 다시 만들어야 한다.

즉, 외부 데이터를 다룬다는 것은 단순히 요청을 보내는 것이 아니라, 응답을 읽고, 필요한 값을 골라내고, 현재 화면에 맞는 형태로 다시 표현하는 것까지 포함한다는 뜻이다.


이 기준이 잡혀 있어야 이후에 목록, 카드, 표, 차트 같은 다른 화면 구성도 같은 원리로 이해할 수 있다.
그래서 이 예제는 AJAX를 단순한 통신 기술이 아니라, 데이터를 화면으로 연결하는 기술로 보게 만들어 주는 중요한 예제다.


여기서 꼭 기억할 핵심

외부 API에서 받은 JSON 데이터를 필요한 값만 골라 표 형태로 가공해서 현재 화면에 다시 출력할 수 있다는 점이 이 예제의 핵심이다.
즉, 이 예제는 응답을 그대로 보여 주는 것이 아니라, 현재 화면 구조에 맞게 다시 만들어 tbody에 반영하는 단계까지 포함한다.
이 기준이 잡혀 있어야 외부 데이터를 활용하는 전체 흐름이 자연스럽게 연결된다.



18. 전체 흐름 다시 정리

AJAX는 새로운 화면으로 이동하는 기술이 아니다.
현재 화면을 유지한 채 서버와 데이터를 주고받고, 필요한 부분만 다시 그리는 기술이다.
이 한 줄을 정확히 이해하면 예제마다 코드가 달라 보여도 결국 같은 구조로 읽을 수 있다.


지금까지 정리한 내용을 마지막으로 한 번 더 묶어 보면, AJAX는 문법 몇 개를 따로 외우는 주제가 아니라 하나의 처리 흐름으로 이해해야 하는 개념이라는 점이 더 분명해진다.
즉, AJAX를 잘 이해한다는 것은 코드 조각을 외우는 것이 아니라, 현재 화면 안에서 데이터가 어떻게 오가고 반영되는지 흐름으로 이해하는 것이다.


AJAX를 한 줄로 다시 정리하기

AJAX의 핵심은 새 페이지로 이동하는 것이 아니라, 현재 화면을 유지한 채 서버와 데이터를 주고받고 필요한 부분만 다시 바꾸는 것이다.
즉, 전체 문서를 다시 받는 흐름보다 필요한 데이터만 받아 현재 화면 일부를 갱신하는 흐름으로 이해하는 것이 중요하다.


초보자는 AJAX를 처음 배우면 XMLHttpRequest, JSON.parse(), onload, responseText 같은 코드가 먼저 눈에 들어오기 쉽다.
하지만 이런 코드들은 전부 목적이 있어서 등장한다.
즉, 지금까지 본 모든 코드는 결국 아래 한 가지 목적을 위해 움직이고 있었다.

  • 현재 화면을 유지한다.

  • 필요한 데이터를 요청한다.

  • 응답이 오면 그 결과를 현재 화면의 특정 위치에 반영한다.

이 흐름을 기준으로 보면 예제마다 겉모습은 달라도 안쪽 구조는 계속 비슷하게 반복된다는 점이 보인다.


개념 파트에서 꼭 잡아야 하는 기준

앞부분 개념 파트에서는 왜 AJAX가 필요한지부터 시작해서, 기존 웹 통신과 무엇이 다른지, 동기와 비동기는 무엇인지, XMLHttpRequest는 어떤 역할을 하는지, 요청 방식과 응답 형식은 어떻게 다른지, 그리고 SOP와 CORS가 왜 중요한지까지 차례대로 정리했다.


이 개념들은 따로따로 외우는 내용이 아니다.
서로 연결해서 봐야 한다.
초보자는 아래 기준만 먼저 정확히 잡아도 전체 흐름이 훨씬 쉬워진다.

  • 기존 웹 통신은 새 화면 전체를 다시 보여 주기 쉽다.

  • AJAX는 필요한 데이터만 받아 현재 화면 일부만 바꾼다.

  • 비동기는 응답이 도착했을 때 그때 결과를 처리하는 흐름이다.

  • XMLHttpRequest는 브라우저 안에서 서버와 통신하는 도구다.

  • 응답 형식이 다르면 읽는 방식도 달라진다.

  • 외부 요청은 브라우저 보안 정책과 서버 허용 설정까지 함께 봐야 한다.

즉, 개념 파트는 예제 전에 미리 머릿속 기준을 세워 두는 구간이다.
이 기준이 먼저 잡혀 있어야 예제 코드가 갑자기 튀어나온 것처럼 느껴지지 않는다.


예제 파트가 공통으로 따르는 흐름

예제 파트는 exam1부터 exam9까지 조금씩 모습이 달라졌다.
어떤 것은 버튼을 눌렀고, 어떤 것은 XML을 읽었고, 어떤 것은 JSON을 객체로 바꿨고, 어떤 것은 2초마다 다시 요청했고, 어떤 것은 로그인 값을 POST로 보냈고, 어떤 것은 이미지 파일을 붙였고, 어떤 것은 외부 API 원문을 확인했고, 어떤 것은 영화 데이터를 표로 다시 만들었다.


겉으로 보면 다 다르게 보일 수 있다.
하지만 안쪽 구조는 계속 반복된다.

  • 이벤트가 시작된다.

  • 요청을 준비한다.

  • 서버에 요청을 보낸다.

  • 응답이 도착하면 결과를 읽는다.

  • 현재 화면의 특정 위치를 바꾼다.

즉, 예제마다 달라 보이는 것은 응답 형식과 화면 반영 방법이지, 큰 뼈대 자체가 완전히 달라지는 것은 아니다.
이 공통 흐름이 보이기 시작하면 AJAX 예제는 더 이상 조각난 코드가 아니라 하나의 반복 구조로 읽히게 된다.


예제들이 단계별로 보여 준 핵심

예제 파트는 단순히 여러 코드를 나열한 것이 아니다.
각 예제가 한 단계씩 역할을 나눠서 보여 준다.
즉, 앞 예제를 이해해야 뒤 예제가 자연스럽게 이어지는 구조다.


각 예제가 보여 준 핵심을 짧게 정리하면 아래와 같다.

  • exam1은 같은 요청이라도 결과를 새 페이지처럼 보여 줄 수도 있고, 현재 화면에 붙일 수도 있다는 점을 보여 줬다.

  • exam2는 XML 응답은 문서 구조를 따라 읽어야 한다는 점을 보여 줬다.

  • exam3는 JSON 응답은 문자열을 객체로 바꾼 뒤 사용해야 한다는 점을 보여 줬다.

  • exam4는 AJAX 요청이 한 번만 일어나는 것이 아니라 반복될 수도 있다는 점을 보여 줬다.

  • exam5는 폼 입력값도 POST로 보내고 현재 화면 안에서 결과만 바꿀 수 있다는 점을 보여 줬다.

  • exam6은 이미지 같은 파일 응답도 blob으로 받아 현재 화면에 붙일 수 있다는 점을 보여 줬다.

  • exam7은 외부 자원을 다룰 때 응답 원문부터 먼저 확인해야 하고, CORS 문제도 함께 봐야 한다는 점을 보여 줬다.

  • exam8은 외부 JSON 응답 전체를 먼저 본 뒤 필요한 값 하나를 골라내는 흐름을 보여 줬다.

  • exam9는 외부 API 데이터를 표 형태로 다시 구성해서 실제 화면용 데이터로 바꾸는 흐름을 보여 줬다.

즉, 예제 파트는 점점 난이도가 올라가면서도, 매번 새로운 세상을 보여 주는 것이 아니라 앞에서 배운 개념을 한 단계씩 확장하는 구조로 이어졌다.


처음 보는 코드도 읽을 수 있게 되는 기준

지금까지 내용을 이해했다면, 이제는 처음 보는 AJAX 코드가 나와도 완전히 낯설게 보이지 않아야 한다.
그럴 때는 코드를 한 줄씩 처음부터 다 똑같이 보는 것이 아니라, 아래 기준으로 읽으면 훨씬 쉽다.

  • 무엇이 시작점인가

  • 어디에서 XMLHttpRequest를 만드는가

  • 어디로 요청을 보내는가

  • 응답을 어떤 형식으로 읽는가

  • 결과를 화면 어디에 반영하는가

즉, AJAX 코드를 잘 읽는다는 것은 문법 몇 개를 외우는 것이 아니라, 요청과 응답과 화면 반영 위치를 빠르게 찾는 것이라고 볼 수 있다.
이 기준이 잡혀 있으면 예제가 바뀌어도 훨씬 덜 헷갈린다.


여기서 꼭 기억할 최종 핵심

AJAX를 잘 이해한다는 것은 “현재 화면을 유지하면서 필요한 데이터만 받아 와 원하는 위치에 반영하는 흐름”을 이해하는 것이다.
즉, AJAX는 문법 몇 개를 따로 외우는 주제가 아니라, 요청 → 응답 → 화면 반영이라는 하나의 처리 흐름으로 이해해야 하는 개념이다.
이 기준이 잡혀 있어야 새로운 예제를 보더라도 어떤 부분이 요청이고, 어떤 부분이 응답 처리이며, 어떤 부분이 화면 갱신인지 자연스럽게 읽을 수 있게 된다.

profile
이언덕
이전 포스트

[아이티센 부트캠프] MVC 패턴

다음 포스트

내부 클래스

0개의 댓글