03 · 소켓 채팅에서 HTTP로 · AI 웹 개발 교실

친구와 통신하고 규칙을 붙인 뒤 HTTP 요청·응답과 가짜 로그인을 관찰합니다.

오늘 남길 이해: 프로그램끼리 데이터를 주고받고, 그 뜻을 해석하려면 함께 따르는 규칙이 필요합니다.

먼저 03-0 소켓 채팅에서 혼자 에코 → 함께 중계 → 한 줄 메시지 규칙을 경험합니다. 각 묶음 끝에서 관찰과 설명을 남기고 멈춰도 됩니다. 에코가 된 뒤 on의 등록과 데이터 도착 시 호출만 짧게 짚습니다. 함수 전달·실행 순서와 nc·telnet 도구 교체는 선택이며, 건너뛰어도 기본 실습을 마칠 수 있습니다. “한 줄을 메시지로 읽자”는 우리 규칙을 설명할 수 있으면 공동 채팅을 종료하고 각자 아래 HTTP 실습으로 이어갑니다.

HTTP는 브라우저와 서버가 공통으로 사용하는 규칙입니다. 기존 03-1~03-3의 요청 보내기 → 응답 확인하기 → 문장 하나 바꾸기를 진행하고, 03-6 가짜 로그인 관찰에서 POST 본문을 읽습니다. 03-4·03-5는 선택으로 유지합니다. 실험 수는 하루 할당량이 아니며 예상 → 실행 → 작은 변경 → 내 설명으로 진행합니다.

03-1. 요청 보내기

ZIP을 완전히 풀고 03-통신과웹 폴더를 편집기와 터미널에서 엽니다. Node.js 24를 사용하며 외부 패키지나 API 키는 필요 없습니다. npm install도 필요 없습니다. 첫 성공 등 다른 8080 서버는 먼저 Ctrl+C로 종료하세요.

07-http-observe/server.mjs를 읽고 브라우저를 열면 터미널에 무엇이 나타날지 예상합니다. 폴더의 07은 파일 구분 번호이며 일곱 번째에 배워야 한다는 뜻이 아닙니다.

npm run http:observe

서버 터미널을 둔 채 브라우저에서 http://127.0.0.1:8080/hello를 엽니다. 화면의 Hello, HTTP!와 서버 로그의 GET /hello를 찾으세요. 브라우저가 아이콘을 받으려고 /favicon.ico를 추가 요청할 수도 있습니다.

03-2. 응답 확인하기

Chrome 개발자 도구의 Network 탭을 열고 Disable cache를 선택합니다. 개발자 도구를 열어 둔 채 같은 주소로 새 요청을 보냅니다.

hello 문서 요청을 골라 다음 세 증거를 비교합니다. 한 줄씩만 기록해도 충분합니다.

관찰 위치	찾을 것
브라우저 Network → Headers	Request URL, Request Method `GET`, Status Code `200`
브라우저 Network → Response	`<h1>Hello, HTTP!</h1>`
서버 터미널	같은 경로의 `GET /hello`

응답 본문의 HTML과 브라우저가 그린 화면은 어떻게 다른가요? 200은 서버가 보낸 상태 값입니다. 화면 내용이 내가 원한 기능을 만족한다는 보장은 아닙니다.

이 예제는 Node의 http 모듈이 해석한 요청을 받습니다. HTTP 요청을 처리하는 콜백은 TCP의 data 이벤트와 다릅니다. 모든 경로에 같은 응답을 보내므로 /missing에도 200이 나옵니다. 아직 경로별 처리나 404를 구현하지 않았습니다.

03-3. 문장 하나 바꾸기

먼저 파일만 저장했을 때와 서버를 다시 실행했을 때 응답이 같을지 예상합니다. 주소를 http://127.0.0.1:8080/hello로 맞춰 둡니다.

서버 코드의 Hello, HTTP!만 Hello, team!으로 바꿉니다. 처음에는 영어·숫자·기본 기호(ASCII)를 사용합니다.

파일을 저장만 하고 새 요청을 보내 이전 문장과 새 문장 중 무엇이 보이는지 확인합니다. 이어서 파일 저장 → 서버 Ctrl+C → 다시 npm run http:observe → 브라우저 새 요청 순서로 확인하세요. 이 서버는 파일 저장만으로 자동 재시작되지 않습니다.

두 결과를 비교하고, 바꾼 뒤 응답 본문과 화면을 함께 보고 상태 코드와 요청 경로도 비교하세요. 이제 “이 문장은 어느 프로그램에서 만들어졌고 어떻게 브라우저에 왔는가?”를 코드와 관찰 결과로 설명하면 기본 실험을 마친 것입니다.

AI에게 도움을 요청한다면 먼저 내 예상·실제로 본 결과·관련 코드를 전달하고, 한 줄 변경을 제안받아 검증하세요. 전체 서버를 대신 만들게 하기 전에 직접 본 근거를 남깁니다.

선택 · 친구 접속과 서버 중단

친구 접속: 서버 컴퓨터의 다른 터미널에서 npm run doctor로 Wi-Fi IPv4 주소를 찾고 친구가 http://친구IP:8080/hello로 접속합니다. 역할을 바꿔 보세요. 127.0.0.1은 각자의 컴퓨터, 0.0.0.0은 서버의 수신 설정이며 친구에게 줄 접속 주소가 아닙니다. 네트워크가 기기 간 통신을 막으면 같은 컴퓨터의 브라우저로 계속합니다.
서버 중단: 자신의 서버를 켜고 http://127.0.0.1:8080/hello에서 Network의 200과 본문을 먼저 확인합니다. 친구 주소를 보고 있었다면 내 주소로 돌아오세요. 이미 열린 화면을 둔 채 자신의 서버를 끄면 화면과 새 요청이 각각 어떻게 될지 예상합니다. Network의 Disable cache를 유지하고 새 요청의 실패를 관찰합니다. 서버를 다시 켜서 복구되는지도 확인하세요. 연결 실패는 서버가 보낸 HTTP 404와 다릅니다.

다음 · ●●●로 가리면 전송할 때도 숨겨질까?

가짜 로그인 관찰에서 각자 HTTP POST를 보내고 교사의 Wireshark 화면에서 자기 demo 번호와 공개 입력을 찾습니다. 개인 캡처는 선택입니다. 같은 입력을 04 HTTPS로 보냈을 때 무엇이 달라지는지도 비교합니다. 실제 포털 비밀번호를 사용하는 실험은 아닙니다.

마무리 · 다음 웹앱에서도 같은 흐름 찾기

오늘 본 흐름은 브라우저의 요청 → 서버의 처리 함수 → HTTP 응답 → 화면입니다. 앞으로 화면에서 fetch로 요청을 보내도 같은 경계를 찾습니다. 다음 코드를 지금 실행하거나 새로 만들 필요는 없습니다.

오늘 관찰한 역할	05 화면과 서버에서 다시 볼 자리
브라우저가 `/hello`로 요청	`src/lib/generate-plan.ts`의 `fetch('/api/plan', ...)`
`http.createServer`에 전달한 함수가 요청 처리	`src/app/api/plan/route.ts`의 `POST(request)`가 서버 처리 함수로 전달
`response.end(...)`가 HTML 응답	`src/lib/server/plan-handler.ts`의 `Response.json(...)`이 결과 데이터 응답

오늘은 HTML을 받아 표시했고, 05에서는 받은 JSON 데이터로 화면을 만듭니다. AI가 서버 응답을 바꿨다면 어디에서 확인할까요? 오늘처럼 Network의 응답과 실제 화면을 함께 확인한다는 연결만 남깁니다.

더 궁금해졌을 때

학생 실습지 ZIP의 materials/에서 소켓·HTTP·로그인 관찰 실습지를 찾을 수 있습니다.

이 심화를 모두 끝내야 화면과 서버 단원으로 넘어갈 수 있는 것은 아닙니다.

03 · 소켓 채팅에서 HTTP로