누구냐면
+내가 제일 좋아하는 가수를 소개할게요.
+
+ 
+ 안녕하세요. 저는 웹페이지를 처음 만들어 보는 김미림입니다.
+오늘 처음으로 HTML이라는 것을 배웠어요.
+ +음악 듣기, 그림 그리기, 그리고 이제는 코딩도요.
+ + +`; + +const CODE_TAG_ANATOMY = `태그의 3단 구조 — 샌드위치를 떠올리세요 + +안녕하세요, 반가워요!
+ ─┬─ ─────────┬───────── ─┬── + 여는 태그 내용 닫는 태그 + (빵 위) (속재료) (빵 아래, /가 붙음) + +· 여는 태그와 닫는 태그
가 내용을 감쌉니다. +· 닫는 태그의 슬래시(/)가 "여기까지!"라는 표시예요. +· 예외:안녕하세요! 저는 웹페이지를 처음 만들어 본 김미림입니다.
+ +
+ 아침엔 느긋하고, 밤엔 집중이 잘 되는 편이에요.
+ 좋아하는 계절은 가을,
+ 좋아하는 음식은 떡볶이입니다.
+
두 달 안에 나만의 홈페이지를 완성하는 것!
+ + + +`; + +const CODE_LOOP = `개발의 리듬 — 오늘부터 몸에 새길 4박자 + + ① 고친다 VS Code에서 글자 하나를 바꾼다 + ② 저장한다 Ctrl + S (Mac은 Cmd + S) + ③ 새로고침 브라우저에서 F5 (또는 Ctrl + R) + ④ 확인한다 내가 바꾼 게 화면에 떴나? + + ①→②→③→④→①→②→③→④→ ... (무한 반복) + +· 저장을 안 하면 브라우저는 '옛날 파일'을 계속 보여 줘요. + "바꿨는데 왜 안 변하지?"의 90%는 저장을 빼먹은 것. +· 프로 개발자도 하루 종일 이 4박자를 돕니다. 단지 더 빠를 뿐!`; + +const CODE_MISTAKE_TAG = ` +첫 번째 문단 +
두 번째 문단
+ + +여기부터 굵게... 어라, 안 닫았네.
+다음 문단까지 전부 굵어져 버립니다!
+ +`; + +const CODE_MISTAKE_CHARSET = ` + + + + +`; + +// ── 이 페이지 안에서만 쓰는 작은 부품들 ── +// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용. +function Section({ n, title, sub, children }) { + return ( +{children}+ "코딩은 어렵고 준비물이 많다"는 소문과 달리, 웹페이지 만들기의 준비물은{' '} + 메모장 수준의 도구 하나뿐이에요. 오늘 이 시간이 끝나면, 여러분 + 컴퓨터의 브라우저에 여러분이 직접 만든 '진짜 페이지'가 떠 있을 + 겁니다. 인터넷도, 서버도, 어려운 수학도 필요 없어요. 시작해 볼까요? +
++ 유튜브, 네이버, 지금 보고 있는 이 페이지까지 — 세상 모든 웹페이지의 정체를 알면 + 코딩이 훨씬 만만해져요. 정답부터 말하면, 웹페이지는{' '} + 그냥 글자로 된 문서(텍스트 파일)입니다. 게임처럼 복잡한 프로그램이 + 아니라, 여러분이 메모장에 쓰는 일기와 같은 종류의 파일이에요. +
++ 다만 그 문서에는 약속된 표시가 들어 있어요. "여긴 제목이야", + "여긴 문단이야" 같은 표시요. 이 약속의 이름이 바로{' '} + HTML(HyperText Markup Language)입니다. 그리고{' '} + 브라우저(크롬·엣지·사파리)가 이 문서를 읽어서, 표시대로 제목은 + 크게, 문단은 나눠서 화면에 그려 줍니다. +
+{CODE_WHATIS}
+ + 여기서 오늘의 가장 중요한 사실 하나. 이 문서는{' '} + 인터넷 없이도 내 컴퓨터에서 만들고 열 수 있어요. 브라우저는 멀리 + 있는 서버의 문서만 여는 게 아니라, 내 컴퓨터에 저장된{' '} + .html 파일도 똑같이 열어 줍니다. 그러니 오늘 우리는 + 아무것도 설치된 서버 없이, 파일 하나로 웹페이지를 만들 거예요. +
++ HTML 문서는 정말로 메모장으로도 만들 수 있어요. 하지만 우리는 처음부터 개발자들이 + 실제로 쓰는 도구, VS Code(Visual Studio Code)를 쓸 거예요. + 공짜인 데다, 코드에 색을 입혀 주고(어디가 태그인지 한눈에 보임), + 내가 태그를 열면 닫는 태그를 지어서 추천해 주거든요. 메모장보다 + 실수를 훨씬 덜 하게 됩니다. +
++ 설치는 간단해요. 공식 사이트(code.visualstudio.com)에서 내 운영체제용 설치 파일을 + 받아 실행하면 끝. 처음 열면 영어 화면이 낯설 수 있는데, 오늘 쓸 건 딱 두 가지예요.{' '} + 파일 열기/저장, 그리고 폴더 열기(File → Open + Folder). 나머지 버튼은 몰라도 전혀 지장 없습니다. +
++ 도구를 준비했으면 작업 폴더를 만듭시다. 바탕화면이나 문서 폴더에{' '} + my-first-web 같은 폴더를 하나 만들고, VS Code로 그{' '} + 폴더째 여세요. 앞으로 이 강좌의 파일은 전부 이 폴더 안에서 + 살아갑니다. +
+{CODE_FOLDER}
+ + 폴더 이름 옆의 .html이라는 꼬리표, 이걸{' '} + 확장자라고 불러요. 파일 이름의 마침표 뒤에 붙어서 "이 파일은 어떤 + 종류다"를 알려 주는 표시입니다. .txt는 그냥 메모,{' '} + .html은 웹페이지, .png는 + 그림. 같은 글자 내용이라도 확장자가 .html이어야 + 브라우저가 "아, 웹페이지구나" 하고 그려 줍니다. +
++ 이제 진짜로 만들어 봅시다. VS Code에서 새 파일을 만들어 이름을{' '} + index.html로 저장하고, 아래 내용을{' '} + 직접 타이핑하세요. 복사-붙여넣기보다 손으로 쳐야 손가락이 + 기억합니다. +
+{CODE_SKELETON}
+ + 한 줄씩 뜯어 볼게요. 맨 위의 <!DOCTYPE html>은 + "이 문서는 최신 HTML 규칙으로 쓰였어요"라고 브라우저에게 알리는{' '} + 선언문이에요. 항상 파일의 첫 줄에 딱 한 번 씁니다. 그 아래부터 + 문서 전체가 <html>로 감싸이고, 그 안이 두 + 부분으로 나뉘어요. +
++ <head>는 '문서에 대한 정보'를 + 담는 곳이에요. 브라우저 탭에 표시될 제목(<title>), + 글자를 읽는 방식(charset) 같은 것들이죠. 화면 + 본문에는 안 보입니다. 반대로{' '} + <body>는 '화면에 보이는 모든 것'이 + 사는 곳이에요. 우리가 쓰는 글, 제목, 나중에 배울 이미지까지 전부{' '} + body 안에 들어갑니다. 머리(head)엔 생각이, 몸(body)엔 + 보이는 모습이 — 이름 그대로예요. +
++ 다 쳤으면 저장(Ctrl + S)하고, 파일 + 탐색기에서 index.html을{' '} + 더블클릭하세요. 브라우저가 열리면서... 여러분이 쓴 문장이 화면에 + 떠 있을 겁니다. 축하해요 — 방금 생애 첫 웹페이지를 만들었습니다. +
++ 빈 종이에 글만 덩그러니 있으면 읽기 힘들죠. 책이 장 제목 → 절 제목 → + 본문으로 정리되듯, 웹페이지도 제목과 문단으로 정리합니다. 도구는 딱 + 두 종류예요. 제목은 <h1>부터{' '} + <h6>까지, 문단은{' '} + <p>. +
+{CODE_HEADINGS}
+ + h1이 가장 크고 중요한 제목,{' '} + h6로 갈수록 작아져요. 여기서 초보자가 자주 놓치는 + 포인트 하나 — h 태그는 글자를 크게 만드는 버튼이 아니라, 중요도의 순서를 + 매기는 도구입니다. 페이지의 대표 제목은 h1{' '} + 하나, 그 아래 소제목은 h2, 그 안의 더 작은 묶음은{' '} + h3... 이렇게 건너뛰지 않고 순서대로{' '} + 쓰는 게 좋은 습관이에요. +
++ 그리고 지금까지 눈치챘을 수도 있는 규칙을 정식으로 소개할게요. 태그는 대부분{' '} + 3단 구조입니다. +
+{CODE_TAG_ANATOMY}
+ + 여는 태그(<p>)와 닫는 태그 + (</p>)가 내용을 샌드위치처럼 감싸요. 닫는 + 태그에만 슬래시(/)가 붙는다는 것, 꼭 기억하세요. + 여는 것과 닫는 것이 짝이라는 감각만 잡히면 HTML의 절반은 끝난 + 겁니다. +
++ 이제 오늘의 실습 목표, '나를 소개하는 한 페이지'를 완성해 + 봅시다. 뼈대(섹션 3)와 제목·문단(섹션 4)에 세 가지 양념을 더할 거예요. +
++ 첫째, 강조. <strong>은 "이건 + 중요해!"라며 굵게, <em>은 + "여기에 어감을 실어 줘"라며 기울여 보여 줍니다. 둘째,{' '} + 줄바꿈과 구분선. <br />은 문단을 + 새로 열 정도는 아니지만 줄만 바꾸고 싶을 때(시·주소·짧은 목록),{' '} + <hr />은 내용이 크게 바뀌는 지점에 가로 구분선을 + 긋습니다. 이 둘은 감쌀 내용이 없어서 닫는 태그 없이 혼자 다니는 + 특별한 태그예요. +
++ 셋째, 주석. <!-- 이렇게 -->{' '} + 사이에 쓴 글은 브라우저가 완전히 무시합니다. 화면엔 안 나오고, + 코드를 여는 사람에게만 보여요. "여긴 나중에 고치자", "이 부분은 이런 뜻" 같은{' '} + 나를 위한 메모를 남기는 자리입니다. +
+{CODE_ABOUT_ME}
+ + 이 예제를 참고하되, 내용은 여러분 자신의 이야기로 바꾸세요. 이름, + 성격, 좋아하는 것, 목표 — 뭐든 좋아요. 조건은 하나입니다.{' '} + 제목(h1·h2), 문단(p), 강조(strong·em)를 모두 한 번 이상 쓸 것. + 저장하고 브라우저로 열었을 때 '나'가 담긴 페이지가 뜨면 오늘의 실습 성공이에요. +
++ 소개 페이지를 만들다 보면 자연스럽게 어떤 동작의 반복에 빠지게 + 돼요. VS Code에서 고치고, 저장하고, 브라우저로 가서 새로고침하고, 확인하고. 사실 + 이게 바로 개발이라는 활동의 기본 박자입니다. 오늘 이 리듬을 몸에 + 익히면, 앞으로 어떤 언어를 배워도 같은 박자로 갑니다. +
+{CODE_LOOP}
+ + 이 리듬의 매력은 즉각성이에요. h1의 + 글자를 바꾸고 F5를 누르는 순간, 화면이{' '} + 바로 바뀝니다. 내가 쓴 글자가 곧장 결과가 되는 이 재미가, 많은 + 개발자를 이 길로 끌어들인 첫 경험이기도 해요. +
++ 그리고 요령 하나 — 조금 바꾸고, 자주 확인하세요. 열 군데를 한꺼번에 + 고친 뒤 새로고침했다가 화면이 이상해지면, 어디가 문제인지 찾기 어려워요. 한두 줄 + 바꾸고 확인, 또 한두 줄 바꾸고 확인. 이렇게 하면 문제가 생겨도 "방금 바꾼 그 + 부분"만 의심하면 되니까 금방 잡힙니다. +
++ 마지막으로, 처음 배우는 사람 대부분이 밟는 함정 세 개를 미리{' '} + 구경해 둡시다. 미리 본 함정은 함정이 아니에요 — 나중에 만나면 "아, 그거!" 하고 + 웃으며 지나갈 수 있습니다. +
++ 함정 ① 닫는 태그 빼먹기. HTML의 재미있는(그리고 무서운) 점은, + 문법이 틀려도 에러 화면이 뜨지 않는다는 거예요. 브라우저가 최대한 + 알아서 추측해 그려 주거든요. 문제는 그 추측이 내 의도와 다를 때 — 예를 들어{' '} + <strong>을 안 닫으면 그 뒤 내용이{' '} + 전부 굵어져 버립니다. +
+{CODE_MISTAKE_TAG}
+ + 함정 ② .txt로 잘못 저장되기. 메모장으로 저장하면 파일 이름을{' '} + index.html로 써도 실제로는{' '} + index.html.txt가 되는 경우가 있어요. 그러면 + 더블클릭해도 브라우저가 아니라 메모장이 열리죠. 게다가 윈도우는 기본 설정에서{' '} + 확장자를 숨겨서 이걸 알아채기 어렵습니다. 파일 탐색기 상단{' '} + 보기 → 파일 확장명에 체크해서 확장자를 항상 보이게 해 두세요. + VS Code로 저장하면 이 함정은 거의 안 밟습니다. +
++ 함정 ③ 한글 깨짐. 페이지를 열었더니 한글이{' '} + 김미림 같은 외계어로 보인다면, 십중팔구{' '} + <head> 안의{' '} + <meta charset="UTF-8" />이 빠진 거예요. +
+{CODE_MISTAKE_CHARSET}
+ + 오늘 여러분은 웹페이지의 정체(그냥 텍스트 파일!)를 알았고, VS Code와 작업 폴더를 + 갖췄고, 뼈대 → 제목·문단 → 강조·구분선·주석을 거쳐 '나를 소개하는 + 한 페이지'를 브라우저에 띄웠어요. 저장→새로고침의 리듬과 세 가지 함정까지 챙겼으니, + 이제 첫걸음이 아니라 두 걸음째를 디딜 차례입니다. 그런데 소개 + 페이지를 만들다 보면 욕심이 생기죠 — 사진도 넣고 싶고, 좋아하는 사이트로 가는 + 링크도 걸고 싶고, 취미를 목록으로 정리하고 싶고. 다음{' '} + 태그로 페이지에 살 + 붙이기 강좌에서 링크·이미지·목록 태그로 그 욕심을 전부 + 채워 봅시다. +
+{children}+ 지금까지의 웹 페이지는 멈춰 있는 그림이었어요. 클릭해도 조용하고, + 물어봐도 대답이 없죠. 오늘 그 페이지가 처음으로 말을 걸고 반응하기{' '} + 시작합니다. 설치할 것도 없어요 — 여러분의 브라우저 안에 이미 준비돼 있으니까요. + 첫 코드 한 줄의 짜릿함, 지금 시작합니다. +
++ 웹 페이지는 세 명이 함께 만드는 작품이에요. HTML이 글·버튼·사진을 + 화면에 놓고(뼈대), CSS가 색과 모양을 입히죠(꾸밈). 그런데 이 둘만으로 + 만든 페이지는 아무리 예뻐도 움직이지 않는 포스터일 뿐이에요. 버튼을 + 눌러도 조용하고, 질문해도 대답이 없습니다. +
++ 세 번째 주인공 JavaScript(자바스크립트, 줄여서 JS)가 바로 그 + '움직임' 담당이에요. 버튼이 클릭에 반응하고, 팝업이 뜨고, 계산 결과가 화면에 나타나는 + 것 — 여러분이 웹에서 본 거의 모든 움직임이 JS의 일입니다. +
+{CODE_TRIO}
+ + 좋은 소식 하나. JavaScript는 설치할 필요가 없어요. 크롬이든 엣지든, + 여러분이 지금 쓰는 브라우저 안에 JS를 읽고 실행하는 장치가 이미 들어 + 있습니다. 준비물은 브라우저 하나 — 그게 전부예요. +
++ 브라우저 안에는 개발자를 위한 비밀 작업실, 콘솔(Console)이 숨어 있어요. + 코드를 입력하고 Enter를 누르면 그 자리에서 즉시 실행되는 공간이죠. + 파일을 만들 필요도 없으니 첫 실습 장소로 딱입니다. 여는 법: 브라우저에서{' '} + F12를 누르고(맥은 Cmd+Option+I), 위쪽 탭에서{' '} + Console을 클릭하세요. +
+{CODE_FIRST_LOG}
+ + 축하해요 — 방금 그 한 줄이 여러분의 첫 프로그램입니다! 컴퓨터에게 + "이걸 적어 줘"라고 명령했고, 컴퓨터가 그대로 따랐어요. 이제 규칙 두 가지만 챙겨 봅시다. +
++ 첫째, 글자는 따옴표로 감싼다. 따옴표로 감싼 글자 덩어리를{' '} + 문자열(string)이라고 부르는데, 따옴표가 없으면 컴퓨터는 그걸 글자가 + 아니라 '어떤 이름'으로 오해해서 에러를 냅니다. 둘째, 줄 끝의{' '} + ;(세미콜론)은 "이 문장은 여기서 끝"이라는{' '} + 마침표예요. +
+{CODE_QUOTES}
+ + 콘솔의 코드는 브라우저를 닫으면 사라져요. 코드를 내 페이지의 일부로 + 만들려면 HTML 안에 심어야 합니다. 그 자리가 바로{' '} + <script> 태그예요. 이 태그의 여는 문과 닫는 문 + 사이에 적힌 것은 전부 JavaScript로 실행됩니다. +
+{CODE_SCRIPT_IN_HTML}
+ + 위치가 중요해요. <script>는 보통{' '} + </body> 바로 앞, 즉 몸통의 맨 + 끝에 둡니다. 브라우저는 HTML을 위에서 아래로 읽으면서 화면을 그리는데, + 스크립트를 끝에 두면 화면이 다 그려진 다음에 코드가 돌아요. 코드가 + "아직 안 그려진 버튼"을 찾다가 헛손질하는 사고를 막는 배치입니다. +
++ 코드가 길어지면 HTML 파일이 지저분해지겠죠? 그럴 땐 별도의{' '} + .js 파일로 분리하고, src{' '} + 속성으로 불러옵니다. CSS 파일을 따로 두고 링크로 거는 것과 똑같은 발상이에요 — + 역할별로 파일을 나누면 나중에 찾기도, 고치기도 쉬워집니다. +
+{CODE_SCRIPT_SRC}
+ + 콘솔은 개발자만 보는 무대였죠. 이번엔 사용자 눈앞으로 나가 봅시다.{' '} + alert("...")는 화면 한가운데에 팝업 창을 + 띄워 말을 걸고, prompt("...")는 질문과 함께{' '} + 입력 칸을 내밀어 사용자의 대답을 받아 옵니다. +
+{CODE_ALERT}
+ + 여기서 마법 같은 일이 벌어져요. prompt가 받아 온 대답은{' '} + let name = ...처럼 이름을 붙여 보관해 둘 + 수 있고(상자에 담는다고 상상하세요 — 자세한 건 다음 강좌에서!), 그걸{' '} + +로 다른 글자와 이어 붙여 다시 화면에 + 되돌려 줄 수 있습니다. 사용자가 "지민"이라고 답하면{' '} + "지민님 환영합니다!"가 뜨는 거죠. +
+이제 오늘의 실습입니다. 아래 내용을 통째로 저장해서 열어 보세요.
+{CODE_PRACTICE}
+ + JavaScript는 계산도 잘해요. 콘솔에 수식을 그대로 입력하면 즉시 답을 돌려줍니다. + 기호만 두 개 조심하세요. 곱하기는 x가 아니라{' '} + 별표 *, 나누기는 ÷가 아니라{' '} + 빗금 /입니다. +
+{CODE_MATH}
+ + 계산 순서는 수학 시간에 배운 그대로예요 — 곱하기·나누기가 더하기·빼기보다 먼저, + 괄호가 있으면 괄호가 최우선. 그리고 앞으로 "이 계산 맞나?" 싶을 때마다{' '} + 콘솔에 먼저 쳐 보는 습관을 들이세요. 콘솔은 언제나 켜져 있는, 거짓말 + 안 하는 계산기입니다. +
++ 그런데 여기, 초보자 열에 아홉이 밟는 함정이 하나 있어요. +
+{CODE_STRING_TRAP}
+ + "1" + 1이 2가 아니라 "11"이 되는 이유 — + 따옴표를 두른 "1"은 숫자가 아니라 글자이기 + 때문이에요. +는 한쪽이라도 글자면 계산을 포기하고{' '} + 이어 붙이기를 선택합니다. 섹션 2에서 배운 "따옴표 = 문자열" 규칙이 + 이렇게 실전에서 발목을 잡죠. +
++ 지금까지 코드는 페이지가 열리는 순간 한 번 실행되고 끝났어요. 진짜 + 재미는 지금부터입니다 — 사용자가 클릭하는 순간에 코드가 실행되게 + 만들어 볼 거예요. 버튼 태그에 onclick 속성을 붙이면 + 됩니다. 뜻 그대로 "클릭되면(on click) 이 코드를 실행해 줘"라는 예약이에요. +
+{CODE_ONCLICK}
+ + 직접 저장해서 눌러 보세요. 페이지를 열 때는 조용하다가, 여러분이 누르는 + 순간 팝업이 튀어나옵니다. 열 번 누르면 열 번 반응해요. HTML로 그려 둔 + 버튼(뼈대)과 JavaScript(움직임)가 onclick에서 처음으로 + 손을 잡은 순간입니다. +
++ 사소해 보여도 이 경험은 큽니다. 남이 만든 앱을 쓰기만 하던 사람에서,{' '} + 반응하는 것을 만드는 사람으로 자리가 바뀌었으니까요. 앞으로 배울 + 모든 것 — 게임, 웹앱, 인공지능 서비스 — 도 결국 이 구조의 확장이에요. "어떤 일이 + 일어나면(클릭·입력·시간), 어떤 코드를 실행한다." +
++ 여기까지 따라오며 이미 한 번쯤 빨간 에러를 만났을 거예요. 축하합니다, + 정상적으로 배우고 있다는 증거예요. 컴퓨터는 사람과 달리 "대충 알아듣기"를 전혀 + 못해서, 딱 세 가지에서 늘 사고가 납니다. +
++ 첫째, 대소문자. 컴퓨터에게 console과{' '} + Console은 완전히 다른 단어예요. 둘째,{' '} + 괄호와 따옴표의 짝. 연 것은 반드시 닫아야 합니다 — 여는 것만 있고 + 닫는 게 없으면 컴퓨터는 문장이 끝나길 하염없이 기다리다 에러를 내요. +
+{CODE_TYPOS}
+ + 셋째가 가장 중요합니다. 에러 메시지를 읽는 태도예요. 콘솔의 빨간 + 글씨는 선생님의 빨간 펜이 아니라, "여기 몇 번째 줄, 이게 이상해요"라고 + 알려 주는 힌트입니다. 예를 들어{' '} + Console is not defined는 "Console이란 건 모르는데?"라는 + 뜻이니, 대문자 C를 소문자로 고치면 끝이죠. 에러를 두려워하는 사람은 늘지 않고, + 에러를 읽는 사람은 빠르게 늡니다. +
++ 멈춰 있던 페이지가 오늘 처음으로 여러분에게 말을 걸고, 이름을 묻고, + 대답했어요. 콘솔에서 첫 코드를 실행했고, HTML에 스크립트를 심었고, + alert·prompt로 대화했고, 버튼을 클릭에 반응시켰고, 빨간 에러를 읽는 법까지 + 익혔습니다. 그런데 실습에서 슬쩍 지나간 게 하나 있죠 —{' '} + let name = ..., 대답을 담아 두던 그 '이름 붙인 상자'요. + 저 상자의 정체가 바로 프로그래밍의 심장, 변수입니다. 다음{' '} + 변수와 자료형: 이름 붙인 상자{' '} + 강좌에서 상자를 마음껏 만들고, "1"+1이 11이 되던 오늘의 함정도 말끔히 풀어 봅시다. +
+1부터 100 사이의 숫자를 하나 생각해 뒀어요. 맞혀 보세요!
+ + + + + +아직 시도 전이에요.
+ +`; + +const CODE_RANDOM = `// 정답 숫자 뽑기 — 게임의 심장 +// Math.random() → 0 이상 1 미만의 소수 (예: 0.7231…) +// Math.random() * 100 → 0 이상 100 미만 (예: 72.31…) +// Math.floor(…) → 소수점을 잘라 정수로 (예: 72) ← 0~99 +// … + 1 → 한 칸 밀어서 1~100 + +var answer = Math.floor(Math.random() * 100) + 1; +var tries = 0; // 시도 횟수는 0에서 시작 + +// answer는 게임이 시작될 때 딱 한 번 뽑혀서 +// 게임이 끝날 때까지 변수 안에 '기억'되어 있어요. +// 새로고침(F5)하면 다시 뽑히니, 매판 정답이 달라집니다.`; + +const CODE_CHECK = `// check() — "도전!" 버튼이 눌릴 때마다 실행될 채점 함수 +function check() { + // ① 입력창에서 값을 읽는다. 입력창의 값은 늘 '글자'라서 + // Number()로 숫자로 바꿔 줘야 정답과 비교할 수 있어요. + var guess = Number(document.getElementById('guess').value); + + // ② 시도 횟수를 하나 올린다 + tries = tries + 1; + + // ③ 조건문 삼거리: 셋 중 정확히 하나의 길로만 간다 + if (guess === answer) { + console.log('정답! ' + tries + '번 만에 맞혔어요'); + } else if (guess < answer) { + console.log('업! 더 큰 수예요.'); + } else { + console.log('다운! 더 작은 수예요.'); + } +} + +// 지금은 결과가 console.log로만 나와요(F12 콘솔에서 확인). +// 화면에 보여 주는 건 다음 섹션의 몫 — 한 번에 한 걸음씩!`; + +const CODE_UI = ` + + + + +`; + +const CODE_TEST = `[버그 사냥 체크리스트 — 직접 플레이하며 하나씩 확인] + +정상 플레이: + ☐ 작은 수(예: 1)를 넣으면 "업!"이 나오는가? + ☐ 큰 수(예: 100)를 넣으면 "다운!"이 나오는가? + ☐ 업/다운을 따라가면 결국 "정답!"에 도착하는가? + ☐ 시도 횟수가 1, 2, 3… 제대로 올라가는가? + +이상한 입력 (일부러 괴롭혀 보기): + ☐ 아무것도 안 쓰고 "도전!" → 무슨 일이? + ☐ 음수(-5)나 999를 넣으면? + ☐ 글자를 넣으면? → Number('abc')는 NaN(Not a Number)이 돼요 + +글자 입력 방어하기 — check() 맨 앞에 문지기 한 줄: + if (isNaN(guess)) { + result.innerText = '숫자를 입력해 주세요!'; + return; // 여기서 함수를 끝낸다 → 아래 채점은 실행 안 됨 + } + +에러가 나면? 빨간 글씨는 혼내는 게 아니라 '단서'예요. + Uncaught ReferenceError: chek is not defined + → "chek라는 이름은 없는데?" = 오타! check로 고치면 끝.`; + +const CODE_STYLE = ` ++ 아직 시도 전이에요. +
+ +`; + +const CODE_MAP = `[여기까지 배운 개념 지도 — 게임 속 어디에 살고 있나] + +HTML → 제목·입력창·버튼·결과 영역 (게임의 몸) +id → 요소의 이름표 (guess, result) +변수 → answer(정답 기억), tries(횟수 세기) +Math.random → 매판 다른 정답 (게임의 심장) +함수 → check() — 채점 절차를 하나로 묶은 상자 +조건문 → 업 / 다운 / 정답 삼거리 +반복 → 플레이어가 맞힐 때까지 '도전!'을 반복 +onclick → 버튼과 함수를 잇는 전선 +innerText → 화면의 글자를 바꾸는 손 +isNaN → 이상한 입력을 막는 문지기 +에러 읽기 → 빨간 글씨 = 단서, 오타 사냥 + +다음 정거장: + CSS → style 속성을 파일로 분리해 제대로 꾸미기 + 배열 → 지난 추측들을 목록으로 기억하기 [50, 75, 62] + DOM → innerText 너머, 화면을 자유자재로 주무르기`; + +// ── 이 페이지 안에서만 쓰는 작은 부품들 ── +// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용. +function Section({ n, title, sub, children }) { + return ( +{children}+ 변수, 조건문, 반복, 함수, HTML — 지금까지 하나씩 배운 조각들을 오늘{' '} + 전부 한 판에 모읍니다. 컴퓨터가 몰래 뽑은 1~100 사이의 숫자를 + 업/다운 힌트로 맞히는 웹 게임을, 설계부터 자랑까지 처음부터 끝까지 + 직접 완성해요. 끝나고 나면 확실해집니다 — "나, 코딩 할 수 있네." +
++ 오늘 만들 것은 숫자 맞히기 게임이에요. 규칙은 간단합니다. 컴퓨터가 + 1부터 100 사이의 숫자를 하나 몰래 뽑아 두면, 플레이어가 숫자를 입력해서 맞히는 거예요. + 틀리면 컴퓨터가 힌트를 줍니다 — 정답이 더 크면 "업!", 더 작으면{' '} + "다운!". 맞힐 때까지 도전하고, 맞히면 몇 번 만에 성공했는지 + 알려 줘요. +
++ 무언가를 만들 땐 완성된 모습을 먼저 보는 것이 중요해요. 목적지를 + 알아야 길을 잃지 않으니까요. 우리가 도착할 화면은 이렇게 생겼습니다. +
+{CODE_PREVIEW}
+ + 작아 보여도 이 게임 안에는 지금까지 배운 개념이 전부 들어가요. + 입력창과 버튼은 HTML, 정답을 기억하는 건 변수, + 업/다운을 판단하는 건 조건문, 버튼을 누를 때마다 실행되는 채점 + 절차는 함수입니다. 배운 조각이 하나로 맞물리는 순간을 오늘 + 직접 경험해요. +
++ 프로가 되는 습관 하나를 여기서 배워요. 바로 코드를 치기 전에 계획부터 + 쓰는 것입니다. 무작정 타자부터 치면 중간에 "어… 다음에 뭐 하지?" 하고 + 길을 잃기 쉬워요. 종이(또는 메모장)에 세 가지만 적으면 길이 선명해집니다 —{' '} + ① 화면에 뭐가 필요한가, ② 뭘 기억해야 하는가, ③ 무슨 일을 해야 하는가. +
+{CODE_PLAN}
+ + 이 계획표가 곧 이 코스의 지도예요. "화면에 필요한 것"은 섹션 3의 + HTML이 되고, "기억해야 하는 것"은 섹션 4의 변수가 되고, "해야 하는 일"은 섹션 4~5의 + 함수가 됩니다. 순서도의 삼거리(업/다운/정답)는 조건문{' '} + if / else if / else와 정확히 같은 모양이고요. +
++ 설계도가 나왔으니 몸부터 만듭니다. 메모장이나 에디터에서{' '} + game.html 파일을 만들고, 계획표의 "화면에 필요한 것" + 네 가지 — 제목, 입력창, 버튼, 결과 영역 — 을 그대로 옮겨 적어요. +
+{CODE_HTML}
+ + 여기서 제일 중요한 건 id예요.{' '} + id="guess", id="result"는 + 요소에 붙이는 이름표입니다. 다음 섹션에서 자바스크립트가 + "guess라는 이름표 달린 애, 값 좀 줘 봐"라고 이름으로 찾아오기 때문에, + 이름표 없는 요소는 스크립트가 만질 수 없어요. +
++ 이제 몸에 두뇌를 넣을 차례예요.{' '} + <script> 태그 안에 자바스크립트를 씁니다. + 첫 임무는 정답 숫자를 몰래 뽑아 두는 것 — 여기서{' '} + Math.random()이 등장합니다. +
+{CODE_RANDOM}
+ + Math.floor(Math.random() * 100) + 1을 읽는 법: + 안쪽부터 바깥쪽으로, 0~1 소수 → 0~100 미만으로 늘리고 → 소수점을 잘라 + 0~99 → 1을 더해 1~100. 마지막 + 1을 빼먹으면 + 0이 나올 수 있고 100은 절대 안 나오는, 미묘하게 틀린 게임이 돼요. +
++ 두 번째 임무는 채점입니다. 계획표의 "해야 하는 일"이었던{' '} + check() 함수를 만들고, 그 안에 조건문 삼거리를 놓아요. +
+{CODE_CHECK}
+ + 두뇌는 완성됐지만 아직 결과가 F12 콘솔에만 나와요. 플레이어는 + 콘솔을 열지 않으니, 결과를 화면에 보여 줘야 진짜 게임이죠. + 필요한 연결은 딱 두 개입니다. +
++ 첫째, 버튼과 함수를 잇는 전선 —{' '} + onclick="check()". "이 버튼이 클릭되면(on click) + check 함수를 실행해 줘"라는 뜻이에요. 둘째, 화면 글자를 바꾸는 손 —{' '} + innerText. 이름표로 찾아온 요소의 글자를 통째로 + 갈아 끼웁니다. +
+{CODE_UI}
+ + 저장하고 브라우저에서 열어 보세요. 숫자를 넣고 "도전!"을 누르면 화면 문구가 + 바뀝니다. 업/다운을 따라가다 정답을 맞히면 축하 메시지와 함께 시도 횟수가 공개돼요. + 지금 이 순간, 여러분은 움직이는 웹 게임을 처음부터 만든 사람입니다. +
++ "다 만들었다!"의 진짜 뜻은 "이제 테스트를 시작한다"예요. + 만든 사람은 자기 게임을 곱게 다루지만, 진짜 플레이어는 아무거나 넣거든요. + 그러니 우리가 먼저 일부러 괴롭혀 봅니다. +
+{CODE_TEST}
+ + 글자를 넣으면 Number('abc')가{' '} + NaN(Not a Number, "숫자 아님")이 되면서 비교가 + 전부 이상해져요. 그래서 isNaN()이라는 문지기를 함수 + 맨 앞에 세우고, 이상한 입력이면 return으로 즉시 + 함수를 끝냅니다 — "출입 불가, 채점 안 함"이죠. +
++ 동작이 확인됐으니 이제 옷을 입힐 차례예요. HTML 요소에{' '} + style 속성을 붙이면 색·크기·여백을 바꿀 수 있습니다. + 아래는 예시일 뿐 — 색과 크기는 여러분 취향대로 바꿔 보세요. + 바꾸고 → 저장하고 → 새로고침하고, 이 삼박자가 웹 개발의 기본 리듬입니다. +
+{CODE_STYLE}
+ + 다 꾸몄으면 마지막 단계, 자랑입니다. 우리 게임은{' '} + game.html 파일 하나가 전부라서, + 그 파일을 메신저나 메일로 보내면 친구도 더블클릭 한 번으로 플레이할 수 있어요. + 설치도 서버도 필요 없습니다 — 이게 웹의 힘이에요. +
++ 숨을 고르고 뒤를 돌아봅시다. 오늘 완성한 게임 파일 안에, 초급 과정에서 배운 + 개념이 전부 살아서 일하고 있어요. 어디에 뭐가 있는지 지도로 + 한 장 정리하면 이렇습니다. +
+{CODE_MAP}
+ + 그리고 목표 달성 확인. 이 코스의 시작에서 우리는 "처음부터 끝까지 내 손으로 웹 게임 + 완성"을 약속했어요. 설계(종이 코딩) → 뼈대(HTML) → 두뇌(로직) → 반응(화면) → + 테스트 → 다듬기 — 전부 여러분 손으로 지나왔습니다.{' '} + "나 코딩 할 수 있네"는 이제 기분이 아니라 증거가 있는 사실이에요. + 증거물: game.html. +
++ 축하해요 — 여러분은 이제 아이디어를 동작하는 웹 게임으로 바꿔 본 + 사람입니다. 변수로 기억하고, 조건문으로 판단하고, 함수로 묶고, HTML로 + 보여 주는 감각이 손에 남았을 거예요. 다음 정거장은 지도에 적힌 대로 CSS(제대로 + 꾸미기), 배열(여러 값을 한 줄에 기억하기), DOM(화면을 자유자재로 다루기)입니다.{' '} + 학습 센터로 돌아가 다음 강좌를 + 골라 보세요. 첫 프로젝트를 끝낸 지금이, 가장 빠르게 성장하는 순간이에요. +
+{children}+ 지금까지는 코드를 위에서 아래로 한 줄씩 써 왔어요. 그런데 같은 일을 세 번 하려면 + 같은 코드를 세 번 써야 할까요? 함수는 자주 쓰는 코드 묶음에{' '} + 이름을 붙여 두고 언제든 다시 부르는 방법이에요. 이걸 익히는 순간, + 코드를 '쓰는' 사람에서 코드를 '조립하는' 사람으로 한 단계 올라섭니다. +
++ 함수를 한 문장으로 말하면 이래요. "여러 줄의 코드를 하나로 묶고, 그 묶음에 + 이름을 붙인 것." 전자레인지의 '데우기' 버튼을 떠올려 보세요. + 버튼 하나를 누르면 안에서는 마그네트론을 켜고, 접시를 돌리고, 시간을 재는 복잡한 + 일들이 벌어지죠. 하지만 우리는 그 과정을 몰라도 됩니다. 버튼(이름)만 누르면{' '} + 약속된 일이 통째로 일어나니까요. +
+먼저, 함수가 없는 세상이 얼마나 고단한지부터 볼게요.
+{CODE_REPEAT}
+ + 복사-붙여넣기로 버틸 수는 있어요. 하지만 인사말을 바꾸는 순간 지옥이 시작됩니다. + 세 군데, 열 군데, 백 군데를 전부 똑같이 고쳐야 하니까요. 함수는 이 + 반복을 한 방에 해결합니다. +
+{CODE_REPEAT_FN}
+ + 한 번 만들면 몇 번이든 재사용 — 이게 함수의 첫 번째 선물이에요. + 그리고 놀라운 사실 하나. 여러분이 지금까지 써 온{' '} + console.log()와 alert(),{' '} + prompt()도 전부 함수였습니다. 자바스크립트를 + 만든 사람들이 "화면에 글자 찍기" 같은 자주 쓰는 일을 미리 함수로 만들어 둔 거예요. + 이름 뒤에 괄호가 붙어 있었던 게 바로 그 증거죠. +
++ 함수를 만드는 문법은 딱 네 조각이에요. function 키워드,{' '} + 이름, 괄호 ( ), 그리고 코드를 담는{' '} + 중괄호. 이렇게 함수를 만드는 걸 정의(definition)라고 + 부릅니다. +
+{CODE_DEFINE_CALL}
+ + 여기서 초보 때 가장 많이 헷갈리는 지점이 나와요. 함수를{' '} + 정의만 해서는 아무 일도 일어나지 않습니다. 정의는 "이런 명령어를 + 등록해 둘게"라는 예약일 뿐이에요. 실제로 실행하려면 이름 뒤에 괄호를 + 붙여 호출(call)해야 합니다. 요리로 비유하면 정의는{' '} + 레시피를 적어 두는 것이고, 호출은 그 레시피대로{' '} + 실제로 요리하는 것이에요. 레시피를 백 장 적어도 요리하지 않으면 + 아무도 못 먹죠. +
++ 섹션 2의 greet()는 항상 똑같은 인사만 + 해요. 그런데 사람마다 이름을 불러 주며 인사하고 싶다면? 사람 수만큼 함수를 만들 수는 + 없잖아요. 그래서 함수에는 재료를 받는 입력 구멍을 뚫을 수 있는데, + 이 구멍을 매개변수(parameter)라고 부릅니다. +
+{CODE_PARAMS}
+ + 자판기를 떠올려 보세요. 자판기(함수)에는 동전 넣는 구멍(매개변수)이 있고, 우리가 + 실제로 넣는 500원짜리 동전이 인자(argument)예요. 같은 자판기라도 + 어떤 동전과 버튼이냐에 따라 다른 음료가 나오듯, 같은 함수라도{' '} + 어떤 인자를 넣느냐에 따라 다른 결과가 나옵니다. +
+구멍은 쉼표로 구분해서 여러 개 뚫을 수도 있어요. 단, 순서가 중요합니다.
+{CODE_PARAMS_MANY}
+ + 지금까지의 함수는 결과를 console.log로{' '} + 화면에 찍기만 했어요. 그런데 계산 결과를 받아서 이어서 + 쓰고 싶다면 어떡할까요? 예를 들어 더한 값에 다시 10을 곱하고 싶다면요. + 이때 필요한 것이 return(반환)입니다. +
+{CODE_RETURN}
+ + 이 차이를 심부름으로 비유하면 이래요. console.log만 하는 + 함수는 심부름꾼이 결과를 소리 내어 외치고 그냥 가 버리는 것 — 듣긴 + 했지만 손에 쥔 건 없어요. return하는 함수는 결과를{' '} + 내 손에 건네주고 가는 것 — 받은 값을 변수에 담아 두고두고 쓸 수 + 있습니다. 그래서 돌려받은 게 없는 함수의 결과를 변수에 담으면{' '} + undefined(정해진 값 없음)가 나오는 거예요. +
++ return에는 성질이 하나 더 있어요.{' '} + return을 만나는 순간 함수는 즉시 끝납니다. 그 아래 줄이 몇 줄이든 + 전부 무시돼요. +
+{CODE_RETURN_STOP}
+ + 함수를 배우면 이런 욕심이 생겨요. "그럼 프로그램 전체를 거대한 함수 + 하나에 다 넣으면 되겠네?" — 돌아가긴 합니다. 하지만 좋은 개발자는 반대로 + 갑니다. 큰 함수 하나보다, 한 가지 일만 잘하는 작은 함수 여러 개.{' '} + 레고 성을 통짜 플라스틱으로 찍지 않고 작은 블록으로 쌓는 것과 같은 이유예요 — + 블록이 작아야 고치기도, 다시 쓰기도 쉬우니까요. +
+그리고 함수 안에서는 다른 함수를 부를 수 있습니다. 이게 조립의 핵심이에요.
+{CODE_COMPOSE}
+ + makeReport는 등급을 어떻게 매기는지 + 몰라요. 그 일은 toKorean에게 맡기고, 자기는 문장을 + 만드는 일만 하죠. 이렇게 일을 나누면 고칠 곳도 하나로 모입니다. 등급 + 기준이 바뀌어도 toKorean 한 곳만 고치면, 그 함수를 쓰는 + 모든 곳이 함께 바뀌어요. +
++ 조립이 잘 되려면 조건이 하나 있어요. 이름만 봐도 하는 일을 알 수 있어야{' '} + 합니다. 부품 상자에서 이름표 없는 부품을 뒤지는 건 고문이니까요. +
+{CODE_NAMING}
+ + 함수를 쓰다 보면 곧 이런 에러를 만나요. "함수 안에서 만든 변수를 밖에서 썼더니{' '} + not defined래요!" — 고장이 아니라 규칙입니다. + 변수에게는 자기가 사는 동네가 있는데, 이 동네의 경계를{' '} + 스코프(scope)라고 불러요. +
+{CODE_SCOPE}
+ + 규칙은 두 줄로 요약돼요. ① 함수 안(지역)에서 만든 변수는 그 함수 밖에서 + 안 보인다. ② 함수 밖(전역)에서 만든 변수는 함수 안에서도 보인다. 담장 안의 + 사람은 담장 밖 풍경을 내다볼 수 있지만, 밖에서는 담장 안이 안 보이는 것과 같아요. + 그래서 함수 밖 세상을 전역(global), 함수 담장 안을{' '} + 지역(local)이라고 부릅니다. +
++ "왜 이런 벽을 만들었을까?" 불편해 보이지만 사실은 보호막이에요. + 함수마다 담장이 있으니, 내 함수 안의 result와 남의 함수 + 안의 result가 이름이 같아도 서로 안 부딪혀요.{' '} + 담장이 없다면 프로그램 전체에서 변수 이름이 절대 겹치지 않게 관리해야 할 텐데, 함수가 + 수백 개쯤 되면 그건 불가능하죠. +
++ 이제 배운 것을 전부 조립할 시간이에요. 목표는{' '} + 숫자 2개와 연산 기호를 받아 결과를 돌려주는 계산기. 더하기·빼기· + 곱하기·나누기라는 작은 함수 4개를 먼저 만들고, 조건문으로 알맞은 + 함수를 골라 부르는 지휘자 함수 하나로 묶습니다. +
+{CODE_CALC}
+ + 코드를 뜯어보면 이번 코스의 모든 조각이 보여요. ① 정의와 호출 — + 작은 함수 4개를 정의해 두고 calculate가 호출하죠.{' '} + ② 매개변수 — a, b, op 세 개의 구멍으로 + 재료를 받고요. ③ return — 모든 함수가 결과를 돌려주니 변수에 담아 + 이어서 쓸 수 있어요. ④ 조합 — 지휘자가 작은 함수들을 부리고,{' '} + ⑤ 즉시 종료 — divide는 0으로 나누는 + 이상한 입력을 return으로 먼저 내보냅니다. +
++ 한 가지 복병이 있어요. prompt()는 사용자가 무엇을 + 입력하든 문자열을 돌려줍니다. 그대로 더하면{' '} + '3' + '4'는 '34'가 돼 + 버려요. 그래서 Number()라는 (이것도 함수!) 변환기를 + 한 번 거쳐 진짜 숫자로 바꾼 다음 계산에 넣습니다. +
++ 이제 여러분은 나만의 명령어를 만드는 사람이에요. 코드 묶음에 이름을 + 붙이고(정의), 필요할 때 부르고(호출), 재료를 넣고(매개변수), 결과를 돌려받고(return), + 작은 함수들을 조립해 계산기까지 완성했습니다. console.log가 + 사실 함수였다는 걸 아는 사람과 모르는 사람의 코드는 이제부터 점점 달라져요. 그런데 + 계산기를 만들며 빨간 에러 글씨를 몇 번 만나지 않으셨나요? 그 빨간 글씨는 사실 적이 + 아니라 가장 친절한 힌트입니다. 다음{' '} + 에러와 친해지기: 빨간 글씨 해독법{' '} + 코스에서, 에러 메시지를 읽고 스스로 고치는 법을 이어서 익혀 봅시다. +
+기사 내용이 여기에...
+ + + + +`; + +const CODE_CONSOLE = `// Console 탭에 직접 입력해 보세요 (> 뒤가 내가 치는 것) + +> 2 + 3 +5 // 브라우저가 즉시 계산해서 대답! + +> "안녕" + "하세요" +'안녕하세요' // 글자도 붙일 수 있어요 + +> 우와아아 +Uncaught ReferenceError: 우와아아 is not defined +// ↑ "우와아아가 뭔지 모르겠어요"라는 브라우저의 대답. +// 빨간 글씨 = 에러. 무섭지 않아요. '어디가 왜 안 되는지'를 +// 알려 주는 친절한 쪽지이고, 앞으로 여기서 자주 만나게 됩니다.`; + +const CODE_ORDER = ` +두 번째 문단
+ + + + +`; + +const CODE_FILE_VS_HTTPS = `file:///C:/Users/me/my-page.html https://awesomedev.dev +────────────────────────────── ────────────────────────────── +내 컴퓨터의 파일을 '직접' 연 것 멀리 있는 서버가 '보내 준' 것 +이 컴퓨터 앞에 앉은 나만 본다 주소만 알면 전 세계 누구나 본다 +인터넷이 없어도 열린다 인터넷이 있어야 한다 +저장 → 새로고침이면 바로 반영 서버에 올리는 '배포'가 필요 + +둘 다 똑같은 브라우저, 똑같은 HTML. +다른 건 딱 하나 — 문서가 '어디에서 왔는가'입니다.`; + +const CODE_PRACTICE = `탐험 실습 체크리스트 — "포털 메인 제목을 내 이름으로" + +1. 좋아하는 사이트(포털 메인 등)를 연다 +2. F12 를 눌러 개발자 도구를 연다 → Elements 탭 +3. 왼쪽 위 화살표 아이콘(또는 Ctrl+Shift+C)을 켜고 + 화면에서 바꾸고 싶은 제목 글자를 클릭 → 해당 태그로 점프! +4. 그 태그의 글자 부분을 더블클릭 → 내 이름으로 고쳐 쓴다 +5. 스크린샷을 찍는다 (Windows: Win+Shift+S) +6. F5 새로고침 → 원래대로 돌아오는 것까지 확인! + (왜 돌아오는지 설명할 수 있다면 이 코스는 합격입니다)`; + +// ── 이 페이지 안에서만 쓰는 작은 부품들 ── +// 학습 포인트: 같은 모양이 반복되면 컴포넌트로 뽑는다. props만 바꿔 재사용. +function Section({ n, title, sub, children }) { + return ( +{children}+ 주소창에 엔터를 치면 무슨 일이 벌어질까요? 우리가 매일 쓰는 브라우저는 사실{' '} + 코드를 읽어서 그림을 그려 주는 기계예요. 이 코스에선{' '} + 개발자 도구(F12)라는 만능 열쇠를 손에 쥐고, 매일 보던 웹의{' '} + 뒷면을 구경합니다. 어렵지 않아요 — 구경이 곧 공부니까요. +
++ www.naver.com을 치고 엔터를 누르는 순간, 여러분의 + 브라우저는 멀리 있는 어떤 컴퓨터에게 말을 겁니다. "네이버 첫 화면 + 주세요!" — 이걸 요청(Request)이라고 해요. 그러면 그 컴퓨터가 + "네, 여기요" 하고 문서를 보내 주죠. 이게 응답(Response)입니다. +
++ 여기서 그 '멀리 있는 컴퓨터'를 서버(server)라고 불러요. 대단한 마법의 + 상자가 아니라, 남의 컴퓨터입니다. 24시간 켜 놓고 "요청이 오면 + 응답한다"는 일만 하도록 세팅해 둔 컴퓨터예요. 여러분이 보는 모든 웹페이지는 + 어딘가의 서버가 보내 준 것입니다. +
+{CODE_CONVERSATION}
+ + 그런데 서버가 보내 주는 건 완성된 '그림'이 아니라 HTML이라는 글자 + 문서예요. 그 문서를 읽고, 해석하고, 우리 눈에 보이는 화면으로{' '} + 그려 내는 일 — 그게 바로 브라우저의 직업입니다. 크롬, 엣지, 사파리는 + 전부 "HTML을 그림으로 바꿔 주는 기계"인 셈이죠. +
++ 브라우저가 알아듣는 언어는 크게 세 가지예요. 셋이 하는 일이 딱딱 + 나뉘어 있어서, 역할만 기억하면 절대 헷갈리지 않습니다. +
+{CODE_THREE_LANGS}
+ + HTML은 "여기가 제목이고, 저기가 문단이고, 그 아래가 버튼"이라고{' '} + 구조를 정하는 뼈대예요. 우리가 지금까지 배워 온 바로 그 언어죠. + 그런데 뼈대만 있으면 모든 페이지가 흰 바탕에 검은 글씨일 거예요. 그래서{' '} + CSS가 "제목은 크게, 버튼은 파랗게" 하고 옷을 + 입힙니다. 마지막으로 JavaScript가 "버튼을 누르면 이걸 해라" 하고{' '} + 움직임을 붙여요. +
++ 중요한 건 순서예요. 옷(CSS)은 뼈대(HTML)가 있어야 입힐 수 있고, + 움직임(JavaScript)도 움직일 대상이 있어야 하죠. 그래서 모든 웹 공부는 HTML에서 + 시작합니다 — 여러분은 이미 올바른 순서로 첫 단추를 끼운 거예요. +
++ 놀라운 사실 하나. 여러분이 보는 모든 웹사이트의 코드는 공개되어 있어요.{' '} + 섹션 1에서 봤듯 서버가 HTML 문서를 통째로 보내 주니까, 받은 사람(브라우저)은 당연히 + 그 내용을 전부 갖고 있죠. 그걸 들여다보는 창이 바로 개발자 도구이고, + 여는 열쇠가 F12입니다(맥은{' '} + Cmd+Option+I). +
++ 지금 바로 눌러 보세요. 화면 옆이나 아래에 낯선 패널이 열리면 성공이에요. 그중{' '} + Elements 탭이 "지금 이 페이지의 HTML 구조"를 보여 주는 곳입니다. +
+{CODE_ELEMENTS}
+ + Elements 탭에서 태그를 더블클릭하면 글자를 고칠 수도 있어요. 뉴스 + 제목을 "내가 세계를 정복했다"로 바꾸는 것도 가능하죠. 그런데{' '} + F5로 새로고침하면? 전부 원래대로{' '} + 돌아옵니다. +
++ 왜일까요? 여러분이 고친 건 서버의 원본이 아니라, 내 브라우저에 도착한 + 복사본이기 때문이에요. 도서관 책을 복사해 와서 복사본에 낙서한 것과 같아요. + 도서관의 원본은 멀쩡하고, 새로고침은 "복사본 버리고 원본 다시 받아 오기"라서 낙서가 + 사라지는 겁니다. 요청↔응답 구조를 이해하면 이 현상이 당연해져요. +
++ 개발자 도구에는 Elements 말고도 탭이 여럿 있는데, 그중 앞으로 가장 자주 쓰게 될 곳이{' '} + Console(콘솔) 탭이에요. 콘솔은 한마디로{' '} + 브라우저와 나누는 채팅창입니다. 내가 뭔가 입력하면, 브라우저가 그 + 자리에서 실행하고 결과를 대답해 줘요. +
+{CODE_CONSOLE}
+ + 2 + 3을 치고 엔터를 눌러 보세요. 브라우저가 즉시{' '} + 5라고 대답합니다. 방금 여러분은{' '} + 컴퓨터에게 처음으로 명령을 내린 거예요. 계산기 앱을 켠 게 아니라, + 브라우저 속 JavaScript 엔진이 여러분의 명령을 읽고 실행한 겁니다. +
++ 그리고 콘솔은 에러가 표시되는 곳이기도 해요. 페이지의 JavaScript가 + 어딘가에서 넘어지면, 빨간 글씨로 "몇 번째 줄에서 왜 넘어졌는지"가 여기 찍힙니다. + 나중에 "코드가 왜 안 되지?" 싶을 때 가장 먼저 열어 볼 곳이 바로 콘솔이에요. +
++ 브라우저가 HTML 문서를 받으면 어떻게 그릴까요? 통째로 한 번에? 아니에요.{' '} + 맨 위에서부터 한 줄씩 읽으면서, 읽는 족족 그립니다. 책을 읽듯 + 위에서 아래로요. 그래서 HTML에서 먼저 쓴 것이 먼저 화면에 나타나요. +
+{CODE_ORDER}
+ + 이 '위에서 아래로' 규칙 때문에 <script>(JavaScript를 + 담는 태그)의 위치가 중요해집니다. 예제처럼 script를 body의 맨 아래에 + 두면, 실행되는 시점엔 위의 요소들이 이미 다 그려져 있어서 안심하고 + 찾아 쓸 수 있어요. 반대로 맨 위에 두면 "아직 안 그려진 것"을 찾다가 허탕을 칩니다. +
++ 지금은 "script는 아래에 두는구나" 정도만 챙겨 가면 충분해요. 핵심은 이거예요 —{' '} + 컴퓨터는 순서대로 일한다. HTML을 그리는 것도, 나중에 배울 JavaScript + 코드가 실행되는 것도, 전부 위에서 아래로, 순서대로입니다. 이 감각 + 하나가 앞으로 배울 모든 것의 바탕이 돼요. +
++ HTML 파일을 만들어 더블클릭으로 열어 봤다면, 주소창이{' '} + file:///C:/...처럼 시작하는 걸 봤을 거예요. 반면 + 네이버는 https://로 시작하죠. 이 앞부분은 "문서를{' '} + 어디에서 가져올까"를 뜻합니다. +
+{CODE_FILE_VS_HTTPS}
+ + file://은 내 컴퓨터 안의 파일을 직접 + 여는 거예요. 서버도, 인터넷도 필요 없죠. 대신 이 컴퓨터 앞에 앉은 나만{' '} + 볼 수 있습니다. 친구에게 "내 페이지 봐!"라고 링크를 보내도, 친구 컴퓨터엔 그 파일이 + 없으니 열리지 않아요. +
++ 내가 만든 페이지를 남에게 보여 주려면, 섹션 1에서 배운 그 구조가 + 필요합니다 — 누군가 요청하면 응답해 줄 서버에 내 파일을 올려 두는 + 거죠. 이 과정을 배포(deploy)라고 불러요. "내 컴퓨터의 습작"이 + "전 세계가 볼 수 있는 사이트"로 바뀌는 순간입니다. +
++ 이제 배운 걸 전부 꺼내 쓸 시간이에요. 오늘의 미션:{' '} + 좋아하는 사이트의 메인 제목을 개발자 도구로 내 이름으로 바꾸고, 스크린샷을 + 찍어 오세요. +
+{CODE_PRACTICE}
+ + 다 했다면 스스로에게 물어보세요 — 새로고침하니까 왜 원래대로 + 돌아왔지? "내가 고친 건 서버의 원본이 아니라 내 브라우저의 복사본이고, + 새로고침은 원본을 다시 받아 오는 것"이라고 답할 수 있다면, 오늘 배운 요청↔응답 + 구조가 완전히 여러분 것이 된 겁니다. +
++ 그리고 한 가지 더. 미션이 끝나도 개발자 도구를 닫지 말고, 그 사이트의 HTML을{' '} + 천천히 구경해 보세요. 제목엔 어떤 태그를 썼는지, 메뉴는 어떻게 + 쌓여 있는지. 잘 만든 사이트의 코드를 구경하는 건, 잘 쓴 글을 필사하는 것과 같은{' '} + 최고의 공부예요. 프로 개발자들도 매일 이렇게 남의 코드를 봅니다. +
++ 이제 주소창의 엔터 한 번 뒤에 숨은 요청↔응답의 대화를 알고, + HTML(뼈대)·CSS(옷)·JavaScript(움직임)의 역할을 구분할 수 있고,{' '} + F12라는 열쇠로 어떤 사이트든 뒷면을 열어 볼 수 있게 됐어요. + 콘솔에서 2 + 3을 계산시키며 컴퓨터에게 첫 명령도 내려 봤고요. + 그런데 그 콘솔 창, 계산기로만 쓰기엔 아깝지 않나요? 다음{' '} + 나의 첫 JavaScript{' '} + 코스에서, 브라우저에게 본격적으로 말을 거는 법 — 변수, 조건, 반복 — 을 배우며 + '움직임'의 세계로 들어갑니다. +
+
+
+`;
+
+const CODE_IMG_PATH = `
+
+
+
+
+
+
+
+
+`;
+
+const CODE_IMG_DEBUG = `이미지가 안 보일 때 점검 순서 (위에서부터!)
+
+① 파일 이름 오타? cat.jpg 인데 Cat.jpg 라고 썼나?
+ (대소문자·확장자 .jpg/.png 까지 정확히)
+② 파일 위치가 맞나? HTML 파일과 같은 폴더에 있나?
+ 폴더 안이면 src에 "폴더이름/" 을 붙였나?
+③ 따옴표·등호 빠짐? src="cat.jpg" 모양이 온전한가?
+④ alt는 나오나? 깨진 그림 자리에 alt 글자가 보이면
+ → 태그는 맞고 '주소'가 틀린 것!`;
+
+const CODE_UL = `
+| 요일 | +월 | +화 | +
|---|---|---|
| 1교시 | +수학 | +국어 | +
| 2교시 | +영어 | +체육 | +
안녕하세요, 웹을 배우는 중입니다.
+이 문장은 빨간색!
+이 문장은 큼직하게!
+파랗고 크게 — 세미콜론(;)으로 이어요
+ +div에 주면 상자 안 전체가 노란 배경!
+내가 제일 좋아하는 가수를 소개할게요.
+
+
+ {children}+ 지난 시간에 만든 페이지, 솔직히 좀 밋밋했죠? 글자만 있었으니까요. 오늘은 거기에{' '} + 링크·이미지·목록·표를 하나씩 얹어서, 여러분이 매일 보는{' '} + '진짜 웹페이지'의 모양을 갖춰 봅니다. 마지막엔 내 최애를 소개하는 + 페이지를 직접 완성해서 친구에게 자랑할 거예요. +
++ 웹(web)은 '거미줄'이라는 뜻이에요. 왜 거미줄이냐면, 전 세계 페이지들이{' '} + 링크로 서로 이어져 있어서죠. 파란 글씨를 누르면 다른 페이지로 휙 — + 이 당연한 동작이 없으면 웹은 그냥 문서 더미일 뿐입니다. 링크를 만드는 태그가{' '} + <a>예요. +
+{CODE_LINK_BASIC}
+ + 그런데 여기서 처음 보는 모양이 하나 등장했어요.{' '} + href="..." — 태그 이름 옆에 붙은 이{' '} + 이름="값" 짝을 속성(attribute)이라고 + 부릅니다. 태그가 "나 링크야"라고 종류를 말한다면, 속성은 "그래서{' '} + 어디로 가는 링크인데?"라는 세부 옵션을 적는 칸이에요. +
+ {/* 학습 포인트: 속성은 이 강좌 전체를 관통하는 개념 — src, alt, target, style 모두 속성이다 */} +{CODE_ATTRIBUTE}
+ + 속성은 오늘 계속 나올 거예요. 이미지의 src, 새 탭의{' '} + target, 스타일의 style — + 전부 속성입니다. 지금 이 이름="값" 모양에 익숙해지면 + 오늘 수업의 절반은 끝난 거나 다름없어요. +
+{CODE_TARGET_BLANK}
+ + 글자만 있는 페이지에 사진 한 장이 들어가는 순간, 분위기가 완전히 달라져요. 이미지를 + 넣는 태그는 <img> — 그리고 방금 배운{' '} + 속성이 바로 활약합니다. +
+{CODE_IMG_BASIC}
+ + alt는 "어차피 안 보이는데 대충 써도 되지 않나?" 싶지만, + 생각보다 중요해요. 이미지 주소가 틀렸을 때 대신 표시되고, 눈이 불편해 + 화면 낭독기를 쓰는 사람에겐 그 이미지의 전부가 됩니다. "사진1" 말고 + "창밖을 보는 고양이"처럼, 그림을 말로 옮긴다는 느낌으로 적어 주세요. +
++ 그런데 src에 적는 주소, 즉 경로(path)에는 + 두 종류가 있어요. 여기서 많이들 헷갈리니 천천히 봅시다. +
+{CODE_IMG_PATH}
+ + 연습할 땐 이미지 파일을 HTML 파일과 같은 폴더에 두고 상대 경로로 시작하는 + 게 제일 쉬워요. 그리고 이미지가 안 보이는 날은 반드시 옵니다(모두가 겪어요!). 그럴 때 + 당황하지 말고 이 순서로 점검하세요. +
+ {/* 학습 포인트: '안 될 때 점검 순서'를 미리 손에 쥐여 주면 좌절 대신 디버깅을 배운다 */} +{CODE_IMG_DEBUG}
+ + "좋아하는 음식: 떡볶이, 마라탕, 탕후루" — 이렇게 한 줄에 욱여넣는 것보다, 항목을 + 하나씩 줄 세우면 훨씬 읽기 좋죠. 그게 목록(list)이고, HTML엔 목록 + 태그가 두 종류 있습니다. 차이는 딱 하나 — 순서가 중요한가? +
+{CODE_UL}
+ {CODE_OL}
+ + 이름을 풀면 외우기 쉬워요. ul ={' '} + unordered list(순서 없는 목록, ● 점),{' '} + ol = ordered list(순서 + 있는 목록, 1. 2. 3. 번호). 그리고 둘 다 안에 들어가는 항목은 똑같이{' '} + li(list item)로 적습니다. + 바구니(ul/ol)만 다르고 + 내용물(li)은 같은 셈이죠. +
++ 한 발 더 — 목록 안에 목록도 넣을 수 있어요. 분류 안에 세부 항목이 + 있을 때 쓰는 중첩(nesting)이라는 기술입니다. 맛보기만 해 볼게요. +
+{CODE_NESTED}
+ + 시간표, 급식 메뉴, 게임 전적 — 가로세로 칸으로 정리해야 보기 좋은 정보가 + 있어요. 그럴 때 쓰는 게 표(table)입니다. 표는 태그 네 개가{' '} + 역할을 나눠 만들어요. 한꺼번에 보면 복잡하니, 역할부터 정리할게요. +
++ table은 표 전체를 감싸는 틀,{' '} + tr(table row)은 가로 한 줄(행),{' '} + td(table data)는 줄 안의 칸 하나,{' '} + th(table header)는 칸 중에서도{' '} + 제목 역할을 하는 칸(자동으로 굵게 나와요)입니다. +
+{CODE_TABLE}
+ + 표를 코드로 짤 때 요령은, 코드부터 치지 말고 종이에 행과 열을 먼저 그려 보는{' '} + 거예요. 그다음 "가로 한 줄 = tr 하나"라는 규칙으로 + 위에서부터 한 줄씩 옮기면 됩니다. +
+ {/* 학습 포인트: '행 단위로 옮긴다'는 사고 절차를 주면 중첩 태그가 외울 것에서 그릴 것으로 바뀐다 */} +{CODE_TABLE_THINK}
+ + 페이지에 내용이 늘어나면 슬슬 어수선해져요. 자기소개 따로, 좋아하는 것 따로, 연락처 + 따로 — 구역을 나누고 싶어지는 순간이 옵니다. 그때 쓰는 게{' '} + <div>(division, 구역)예요. 관련 있는 내용물을 + 한데 담는 투명한 상자라고 생각하면 됩니다. +
+{CODE_DIV}
+ + 코드를 저장하고 열어 보면... 아무것도 안 달라져 보여요. 실망하지 + 마세요, 그게 정상입니다! div는 화면에 뭘 그리는 태그가 + 아니라 묶는 태그거든요. 이사할 때 물건을 상자에 담아 두면 옮기기도 + 좋고 라벨 붙이기도 좋듯이, 내용을 상자에 담아 두면 나중에 꾸미고 배치할 때{' '} + 상자째로 다룰 수 있어요. 실제로 여러분이 보는 모든 웹사이트는 수십, 수백 개의{' '} + div 상자로 짜여 있습니다. +
++ 여기까지 만든 페이지, 내용은 갖췄는데 전부 검은 글씨에 흰 배경이라 + 심심하죠. 꾸미기의 세계를 살짝만 맛봅시다. 태그에 style{' '} + 속성(또 속성이에요!)을 달면 그 태그의 생김새를 바꿀 수 있어요. +
+{CODE_STYLE}
+ + 모양은 꾸밀항목: 값; — 여기서{' '} + 등호(=)가 아니라 콜론(:)인 걸 눈여겨보세요. 사실{' '} + style 속성의 따옴표 안은 HTML이 아니라{' '} + CSS라는 별개의 언어거든요. HTML이 페이지의{' '} + 뼈대와 내용을 맡는다면, CSS는 색·크기·배치 같은 겉모습을 + 전담하는 언어예요. 오늘 본 건 그 거대한 세계의 문틈으로 살짝 들여다본 정도입니다. +
++ 이제 오늘의 주인공, 실습입니다. 여러분이 제일 좋아하는 것 — + 가수든, 게임이든, 음식이든, 축구팀이든 — 하나를 골라 소개 페이지를 + 만들어 보세요. 조건은 딱 네 가지입니다. +
++ ① 이미지 2장 (img +{' '} + src·alt) ·{' '} + ② 링크 3개 (a +{' '} + href, 새 탭으로!) · ③ 목록 1개{' '} + (ul 또는 ol) ·{' '} + ④ 구역은 div로 나누기. 스타일은 + 자유 — 원하는 만큼 알록달록하게. +
+{CODE_FINAL}
+ + 위 코드는 예시일 뿐이에요. 그대로 베끼면 재미없죠 — 주제도, 목록 + 내용도, 링크도 전부 여러분의 최애로 바꾸세요. 이미지는 좋아하는 사진 + 2장을 HTML 파일과 같은 폴더에 넣고 파일 이름을{' '} + src에 적으면 됩니다(섹션 2에서 배운 상대 경로!). 안 + 보이면? 당황하지 말고 점검 순서 ①→④를 따라가면 반드시 잡혀요. +
+ {/* 학습 포인트: 완성 경험 + 보여 주기(공유)까지가 실습의 한 세트 — 만들고 끝나면 절반만 한 것 */} ++ 글자뿐이던 문서가 링크로 세상과 이어지고, 이미지가 박히고, 목록과 표로 정리되고, + div 상자로 구역까지 나뉘었어요. 무엇보다 속성(attribute)이라는 + 개념을 손에 넣었죠 — href,{' '} + src, style 전부 그 + 하나의 문법이었으니까요. 그런데 문득 궁금하지 않나요? 내가 쓴 이 태그들을{' '} + 브라우저는 대체 어떻게 읽어서 화면으로 바꿔 내는 걸까요? 다음{' '} + 브라우저는 내 코드를 어떻게 + 읽을까 강좌에서, 우리가 만든 페이지가 화면이 되기까지의 여정을 + 따라가 봅시다. +
+{children}+ "안녕하세요"를 100번 출력하라면 어떻게 할까요? 복사-붙여넣기 100번? 컴퓨터에겐 + 더 좋은 방법이 있어요. 100번 반복도 한 줄로 — 컴퓨터가 세상에서 + 가장 잘하는 일, 지치지 않고 똑같이 반복하기를 시키는 법을 배웁니다. + 이 코스가 끝나면 구구단 72줄을 코드 몇 줄로 뽑아낼 수 있어요. +
++ 사람은 같은 일을 반복하면 지루해하고, 지루해지면 실수해요. 컴퓨터는 정반대입니다. + 같은 일을 100만 번 시켜도 지루해하지 않고, 단 한 번도 틀리지 않아요.{' '} + 그래서 프로그래밍의 절반은 "이 일에서 반복되는 부분이 어디지?"를 + 찾아내 컴퓨터에게 떠넘기는 기술입니다. +
+{CODE_COPYPASTE}
+ + 복사-붙여넣기 100번과 반복문 3줄 — 결과는 같지만 고칠 때 차이가 + 드러나요. 문구 하나 바꾸려고 100줄을 고치는 사람과, 1줄만 고치는 사람. 개발자들은 + 이 감각을 "같은 코드를 두 번 쓰지 마라"라는 격언으로 물려받았어요. + 반복문은 그 격언을 지키는 첫 번째 도구입니다. +
++ 가장 단순한 반복문은 while이에요. 읽는 법도 영어 + 그대로입니다. "~인 동안(while) 계속해라." 괄호 안의 조건이{' '} + 참(true)인 동안 중괄호 안을 계속 실행하고, 조건이 거짓이 되는 순간 + 멈춥니다. +
+{CODE_WHILE}
+ + 여기서 제일 중요한 부품은 카운터 변수{' '} + count예요. 반복이 "지금 몇 바퀴째인지"를 세는 + 변수인데, 핵심은 매 바퀴 값이 변해야 한다는 것.{' '} + count = count + 1이 매번 값을 키워 주니까, 언젠가 + 조건 count <= 5가 거짓이 되어 반복이 멈춥니다. + 조건을 변하게 만드는 줄이 없으면? 아래처럼 됩니다. +
+{CODE_INFINITE}
+ + 섹션 2의 while 코드를 다시 보면, 반복에 필요한 재료가 세 군데 흩어져 있어요. + 시작값(let count = 1)은 반복문 위에, + 조건은 괄호에, 증가는 몸통 끝에. 이 셋을 첫 줄에 + 모아 정리한 것이 for문입니다. +
+{CODE_FOR}
+ + 세 요소는 세미콜론(;)으로 구분해요.{' '} + ① 초기화는 반복이 시작될 때 딱 한 번, ② 조건은 + 매 바퀴 시작 전에 검사(거짓이면 즉시 종료), ③ 증감은 매 바퀴가 + 끝날 때마다 실행됩니다. 셋이 한 줄에 있으니 "몇 번 도는 반복인지"를 첫 줄만 보고 + 알 수 있어요. 그래서 횟수가 정해진 반복은 for, 언제 끝날지 모르는 + 반복(예: 사용자가 그만할 때까지)은 while — 이게 관례적인 역할 분담입니다. +
++ 지금까지는 반복하며 출력만 했어요. 이제 한 단계 올라가서, 반복하며{' '} + 계산 결과를 쌓아 봅시다. 대표 문제: "1부터 100까지 다 더하면?" + — 사람은 한참 걸리지만, 반복문에겐 순식간입니다. +
+{CODE_SUM}
+ + 이 패턴의 주인공은 누적 변수 sum이에요. + 반복 바깥에서 만들어 두고, 매 바퀴{' '} + sum = sum + i로 값을 쌓아 갑니다. "지금까지의 합에 + 이번 값을 더해서, 다시 지금까지의 합으로 저장한다" — 저금통에 매일 동전을 넣는 + 것과 똑같아요. +
++ 왜 0으로 시작할까요? 저금통은 비어 있는 상태에서 + 시작해야 정확히 "넣은 만큼"이 남으니까요. 덧셈에서 0은 더해도 값이 변하지 않는 + 출발점입니다. 만약 곱셈을 누적한다면(예: 1×2×3×...) 시작값은 1이어야 해요 — + "그 연산에서 아무 영향이 없는 값"으로 시작한다는 게 원리입니다. +
++ 이전 강좌에서 배운 if(조건문)를 반복문 안에 넣으면 + 어떻게 될까요? 반복문이 모든 후보를 하나씩 훑고, 조건문이{' '} + 그중에서 골라냅니다. "2단부터 9단 중에 짝수 단만" 같은 문장을 + 그대로 코드로 옮길 수 있게 돼요. +
+{CODE_COMBO}
+ + 여기에 반복의 흐름 자체를 조종하는 두 개의 열쇠가 더 있어요.{' '} + break는 반복을 통째로 탈출하고,{' '} + continue는 이번 바퀴만 건너뛰고{' '} + 다음 바퀴로 넘어갑니다. +
+{CODE_BREAK_CONTINUE}
+ + 언제 쓸까요? break는 "찾았다! 더 볼 필요 없어"의 + 순간에(예: 명단에서 내 이름을 찾으면 멈추기), continue는 + "이건 건너뛰고 계속"의 순간에(예: 빈칸인 답안은 채점 생략) 씁니다. 남용하면 흐름이 + 꼬여 읽기 어려워지니, 지금은 "이런 열쇠가 있다"는 맛보기로 충분해요. +
++ 반복문과 늘 붙어 다니는 단짝을 소개할게요. 과일 4개를 저장하려고{' '} + fruit1, fruit2,{' '} + fruit3... 변수를 따로 만들면, 그것도 결국 + 복사-붙여넣기죠. 배열(array)은 여러 값을{' '} + 순서대로 한 상자에 담는 방법입니다. +
+{CODE_ARRAY}
+ + 꼭 기억할 규칙 하나: 인덱스(칸 번호)는 0부터 시작합니다. 첫 번째 + 항목이 fruits[0]이고, 4개짜리 배열의 마지막은{' '} + fruits[3]이에요. 처음엔 어색하지만 거의 모든 + 프로그래밍 언어가 이 규칙을 따르니, 지금 확실히 몸에 새겨 두는 게 이득입니다. +
++ 그리고 배열과 for가 만나는 순간을 보세요. 상자에 뭐가 몇 개 들었든{' '} + i = 0부터 i <{' '} + fruits.length까지 돌리면 전부 순회됩니다. "목록에 있는 것 + 전부에 대해 ~해라" — 앞으로 만들 거의 모든 프로그램의 뼈대가 되는 문장이에요. +
++ 배운 걸 손으로 굳힐 시간이에요. 첫 번째 워밍업: 별(★)을 한 줄씩 늘려{' '} + 삼각형을 만들어 봅시다. 시작 전에 먼저 규칙부터 찾아 보세요 — + "1번째 줄엔 별 1개, 2번째 줄엔 2개, ... n번째 줄엔 n개." +
+{CODE_STARS}
+ + 여기서 반복 안의 반복(중첩 반복문)이 처음 등장했어요. 바깥{' '} + for가 한 바퀴 돌 때마다, 안쪽{' '} + for는 처음부터 끝까지 전부 돕니다. + 바깥이 '줄', 안쪽이 '그 줄의 내용'을 맡는 구조 — 시계의 시침이 한 칸 갈 때 분침이 + 한 바퀴 도는 것과 같아요. +
++ 이제 진짜 미션입니다. 구구단 2단부터 9단까지 전부 출력하되, 7단만 + 별표(*)로 강조해 보세요. 필요한 재료는 전부 배웠어요 — 중첩 반복문(단 × + 곱하는 수)과 조건문(7단인가?)의 콤보입니다. 먼저 스스로 시도해 보고, 막히면 아래를 + 펼쳐 보세요. +
+{CODE_PRACTICE}
+ + 반복문에서 초보자가 빠지는 함정은 신기할 만큼 정해져 있어요. 전 세계 개발자가 + 똑같이 밟는 지뢰 세 개를 미리 구경해 둡시다. 나중에 같은 에러를 만나면 "아, 그거!" + 하고 웃으며 고칠 수 있게요. +
+{CODE_OFFBYONE}
+ + ① 하나 차이(off-by-one) 실수 — <와{' '} + <=의 차이, 0부터와 1부터의 차이로 반복이 한 번 + 더 돌거나 덜 도는 실수예요. 이름이 따로 있을 만큼 흔합니다. 처방: 조건을{' '} + 소리 내어 읽고, 첫 바퀴와 마지막 바퀴의 i 값을 손으로 적어 보기. +
++ ② 무한루프 — 조건 속 변수를 바꾸는 줄을 빼먹는 실수(섹션 2). + 처방: while을 쓸 때마다 "조건을 거짓으로 만드는 줄이 어디지?"를 반드시 자문하기. + for는 증감이 첫 줄에 강제로 자리 잡고 있어서 이 실수가 훨씬 드물어요 — for가 + '정석'인 이유 중 하나입니다. +
++ ③ i의 범위 착각 — "i가 지금 무슨 값이지?"를 머릿속으로만 추측하다 + 틀리는 경우. 처방은 단순합니다. 반복문 안에{' '} + console.log(i) 한 줄을 넣고 직접 돌려 보기.{' '} + 상상은 틀려도 출력은 거짓말을 하지 않아요. 이 습관 하나가 디버깅 실력의 절반입니다. +
++ 이제 "100번 반복"이라는 말에 복사-붙여넣기 대신 for문 3줄이 + 떠오를 거예요. while(조건이 참인 동안), for(초기화·조건·증감), 누적 변수(빈 + 저금통에서 시작해 쌓기), 반복+조건 콤보, 배열 순회, 그리고 중첩 반복으로 그린 + 별 삼각형까지 — 컴퓨터에게 지루한 일을 통째로 떠넘기는 법을 + 손에 쥐었습니다. 그런데 구구단 코드를 다른 곳에서 또 쓰고 싶다면? 매번 복사해야 + 할까요? 잘 만든 코드 뭉치에 이름을 붙여 두고 필요할 때마다 부르는{' '} + 방법이 있어요. 다음{' '} + 함수: 나만의 명령어 만들기{' '} + 코스에서, 코드를 재사용하는 진짜 기술을 이어서 배워 봅시다. +
+{children}+ 코드를 실행했더니 화면 가득 빨간 글씨가 떴다면 — 축하해요, 드디어 + 진짜 코딩을 시작한 거예요. 에러는 벌점이 아니라 컴퓨터가 주는 힌트 + 입니다. 이 코스에서는 그 힌트를 읽고, 원인을 좁히고, 스스로 고치는 힘을 기릅니다. + 이 힘 하나가 앞으로 배울 모든 것의 속도를 정해요. +
++ 처음 에러를 만나면 심장이 철렁해요. "내가 뭘 망가뜨렸나?", "컴퓨터가 고장 났나?" — + 둘 다 아닙니다. 에러는 컴퓨터가 "여기서 멈췄는데, 이유는 이거야"라고 + 최선을 다해 써 준 안내문이에요. 시험지의 빨간 채점이 아니라, + 길을 잃었을 때 나타나는 안내 표지판에 가깝습니다. +
++ 그리고 하나 더 — 에러는 모든 개발자가 매일 만나요. 10년 차 개발자도 + 하루에 수십 번씩 에러를 봅니다. 초보와 고수의 차이는 "에러를 안 만나느냐"가 아니라, + 에러를 만났을 때 얼마나 빨리 빠져나오느냐예요. +
+{CODE_EVERYONE}
+ + 가장 나쁜 반응은 에러 메시지를 읽지도 않고 코드를 이리저리 바꿔 보는 + 거예요. 그건 안내 표지판을 등지고 아무 방향으로나 달리는 것과 같아요. 오늘 이후로 + 약속 하나만 해요 — 빨간 글씨가 뜨면, 일단 읽는다. 그것만으로 문제의 + 절반은 풀립니다. +
++ 영어로 된 빨간 글씨가 길어 보여도, 뜯어 보면 언제나 세 부분으로 + 이루어져 있어요. ① 에러 이름(어떤 종류의 문제인가),{' '} + ② 설명(정확히 무엇이 문제인가),{' '} + ③ 파일과 줄번호(어디를 보면 되는가). 이 구조만 알면 아무리 긴 + 에러도 3초 안에 뼈대를 잡을 수 있습니다. +
+{CODE_ANATOMY}
+ + 읽는 순서는 거꾸로가 효율적이에요. 먼저 ③ 줄번호로 + 그 줄에 가 봅니다. script.js:12:8은 "script.js 파일의 + 12번째 줄, 8번째 글자"라는 뜻이에요. 그 줄을 눈으로 보면서 ② 설명과 대조하면, + 대부분 그 자리에서 원인이 보입니다. +
++ 영어가 겁난다면 이렇게 번역하세요. 에러 메시지의 영어는 사실{' '} + 몇 가지 패턴의 반복이에요. is not + defined = "그런 이름 모른다", is not a function = + "그건 함수가 아니다", unexpected token = "여기 올 수 없는 + 글자가 왔다", cannot read properties of null = "빈 값에서 + 뭘 꺼내려 했다". 이 네 문장만 외워도 초급 에러의 대부분을 해석할 수 있어요. +
++ SyntaxError(문법 에러)는 컴퓨터가 코드를{' '} + 실행해 보기도 전에 "이건 문장이 안 돼서 못 읽겠어"라고 손을 드는 + 경우예요. 우리말로 치면 "나는 밥을 먹었"처럼 문장이 중간에 끊긴 상태죠. 원인의 + 대부분은 짝이 안 맞는 기호 — 괄호 ( ), + 따옴표 " ", 중괄호가 하나를 열고 닫지 않은 경우입니다. +
+{CODE_SYNTAX}
+ + SyntaxError의 좋은 점(?)은 코드가 아예 시작도 못 하기 때문에 숨을 + 곳이 없다는 거예요. 줄번호가 가리키는 곳 근처에서 열고 닫는 짝만 세어 보면 대부분 + 잡힙니다. 단, 조심할 것 하나 — 에러가 가리키는 줄번호는 컴퓨터가 "여기서 이상함을 + 눈치챈" 위치라서, 진짜 범인(예: 위쪽에서 안 닫힌 괄호)은{' '} + 그 줄보다 위에 있을 수 있어요. +
++ ReferenceError(참조 에러)는 컴퓨터가 코드를 읽는 데는 성공했지만, + 여러분이 부른 이름을 찾지 못했을 때 나요. 핵심 메시지는{' '} + ... is not defined — "그런 이름은 정의된 적이 없는데?" + 라는 뜻입니다. 친구 이름을 잘못 불렀는데 아무도 돌아보지 않는 상황이에요. +
+{CODE_REFERENCE}
+ + 통계적으로 1등 원인은 대소문자 오타예요. 컴퓨터에게{' '} + userName과 username은 + 완전히 다른 이름입니다. 사람 눈에는 거의 같아 보여서 더 악질이죠. 2등은 순수한 철자 + 오타(score → scroe), + 3등은 선언하기 전에 사용 — 변수는 이름표를 붙인{' '} + let/const 줄{' '} + 아래에서만 부를 수 있어요. +
++ TypeError(타입 에러)는 이름은 찾았는데, 그 값의{' '} + 형(type)이 기대와 달라서 시킨 동작을 못 할 때 나요. 값에는 저마다 + 형이 있어요 — 숫자(number), 문자열(string), 그리고 "비어 있음"을 뜻하는{' '} + null 같은 것들이요. 숫자에게 "대문자로 바꿔!"라고 + 시키면, 컴퓨터는 "숫자는 그런 거 못 하는데…"라며 TypeError를 냅니다. +
+{CODE_TYPE}
+ + 자주 보게 될 두 문장을 기억하세요. ... is not a + function은 "함수인 줄 알고 불렀는데 함수가 아니다",{' '} + Cannot read properties of null은 "빈 값에서 뭔가를 + 꺼내려 했다"예요. 둘 다 결론은 같아요 —{' '} + 그 자리에 온 값이 내 예상과 다르다. +
++ 이때의 추적 도구가 typeof입니다. 의심 가는 값 앞에{' '} + console.log(typeof 값) 한 줄을 심으면 값의 정체가 + "number"·"string"·"object" 같은 답으로 돌아와요. "왜 안 되지?"라고 + 고민하는 시간의 절반은, typeof 한 줄이면 끝나는 경우가 많습니다. +
++ 에러 메시지가 줄번호까지 알려 주면 다행인데, 가끔은 "에러는 안 나는데 결과가 + 이상한" 경우도 있어요. 이때부터는 탐정의 시간입니다. 기본 도구는 + 단 하나, console.log — 코드 중간중간에 심어서{' '} + 값이 어떻게 흘러가는지를 눈으로 확인하는 거예요. +
+{CODE_DEBUG}
+ + 코드가 길다면 반씩 좁히기를 쓰세요. 전체의 한가운데에 log를 심고, + 거기까지의 값이 정상이면 범인은 뒤쪽 절반, 이상하면 앞쪽 절반이에요. 남은 절반에서 + 또 반을 가르고… 이걸 반복하면 100줄짜리 코드도 log 일곱 번이면 범인 줄을 특정할 수 + 있습니다. 무작정 처음부터 훑는 것보다 압도적으로 빨라요. +
++ 그리고 탐정의 제1원칙 — "마지막으로 고친 곳"부터 의심하라. 방금까지 + 잘 돌던 코드가 갑자기 죽었다면, 범인은 거의 항상 그 사이에 내가 바꾼 + 부분이에요. "내가 뭘 건드렸지?"를 먼저 되짚는 것이, 코드 전체를 뒤지는 + 것보다 백 배 빠릅니다. +
++ 혼자 15분쯤 씨름해도 안 풀리면, 그때는 바깥의 힘을 빌릴 차례예요. 첫 번째 요령은 + 간단합니다 — 에러 메시지를 그대로 복사해서 검색창에 붙여넣기.{' '} + 전 세계 누군가가 이미 같은 에러를 만나 질문을 올렸고, 답도 달려 있을 확률이 아주 + 높아요. 단, 내 변수명·파일명처럼 나만 쓰는 부분은 지우고 검색해야 + 남들의 질문과 겹칩니다. +
+{CODE_SEARCH}
+ + AI에게 물을 때도 똑같아요. "안 돼요"만 던지면 AI도 점쟁이가 될 수밖에 없어요.{' '} + ① 문제의 코드, ② 에러 메시지 전문, ③ 내가 이미 시도해 본 것 — 이 + 3종 세트를 갖춰 물으면 답의 정확도가 완전히 달라집니다. 사실 이 세트를 준비하는 + 과정에서 스스로 답을 찾는 경우도 많고요. 이걸 개발자들은 "고무 오리에게 설명하다 + 답을 깨닫는다"라고 불러요. +
++ 마지막으로 제일 중요한 것 — 답을 찾았으면 이해하고 나서 옮겨 적으세요.{' '} + 복사–붙여넣기로 일단 돌아가게 만들면 그 순간은 편하지만, 같은 에러를 다음 주에 또 + 만나요. "이 답이 왜 내 에러를 고치는가"를 한 문장으로 설명할 수 + 있을 때만 붙여넣기 — 이 규칙 하나가 성장 속도를 가릅니다. +
++ 마지막 실습은 거꾸로 갑니다. 멀쩡한 코드를 일부러 망가뜨리고, 어떤 + 에러가 뜰지 먼저 예측한 뒤 실행해서 확인하는 거예요. 에러를 스스로 + 만들어 본 사람은 에러가 더 이상 무섭지 않아요 — 어떤 실수가 어떤 빨간 글씨로 + 이어지는지, 인과가 몸에 새겨지니까요. +
+{CODE_PRACTICE}
+ + 짝이 있다면 더 재미있게 할 수 있어요. 서로의 멀쩡한 코드를 몰래 세 군데 + 망가뜨려 교환하고, 에러 메시지만 보고 전부 고쳐 내는 시합을 해 보세요. + "이 에러 메시지는 어떤 원인과 짝인가"를 맞히는 게임을 반복하다 보면, 어느 순간 + 에러 이름만 봐도 손이 먼저 움직이게 됩니다. +
++ 그리고 이 코스의 본 실습 — 버그 5개가 심어진 코드를 받아서, 에러 + 메시지만 단서로 전부 고쳐 보세요. 요령은 배운 그대로예요. ① 빨간 글씨를 읽는다 → + ② 줄번호로 간다 → ③ 에러 이름으로 유형(문법/참조/타입)을 가른다 → ④ 막히면 + console.log와 typeof로 추적한다 → ⑤ 15분 넘게 막히면 검색한다. +
++ 이제 빨간 글씨는 공포가 아니라 읽을 수 있는 안내문이 됐어요. + 에러 메시지의 세 조각(이름·설명·위치), 3대 에러 유형(Syntax·Reference·Type), + console.log와 typeof로 추적하는 탐정의 기술, 그리고 검색과 AI에게 제대로 묻는 + 법까지 — 앞으로 만날 모든 에러에 통하는 무기를 손에 쥐었습니다. + 이 무기를 제대로 시험해 볼 시간이에요. 다음{' '} + 첫 프로젝트: 숫자 맞히기 게임 + 만들기 코스에서 처음으로 나만의 프로그램을 만들어 봅시다 — 만드는 + 동안 에러가 여러 번 뜨겠지만, 이제 여러분은 그게 반가울 거예요. +
+{children}+ 모든 프로그램은 결국 값을 어딘가에 담아 두고, 필요할 때 꺼내 쓰는 일의 + 반복이에요. 그 "어딘가"가 바로 변수 — 이름표를 붙인 상자입니다. + 이 강좌에서는 상자를 만들고(let·const), 상자에 담기는 값의 세 가지 종류 + (문자열·숫자·불리언)를 익힌 뒤, 여러분의 이름으로 자기소개 문장을 조립해 봅니다. + 코딩이 처음이어도 괜찮아요 — 여기가 첫걸음이니까요. +
++ 계산기를 떠올려 보세요. 3 + 4를 누르면 7이 나오지만, + 화면을 끄는 순간 그 7은 사라져요. 프로그램은 달라야 합니다. 계산한 값을{' '} + 어딘가에 보관해 뒀다가, 나중에 다시 꺼내 써야 하죠. 그 보관함이{' '} + 변수(variable)예요. 상자 하나를 만들고, 겉에 이름표를 + 붙이고, 안에 값을 넣는다 — 이게 전부입니다. +
++ 자바스크립트에서 상자를 만드는 낱말이 let이에요. + 상자를 만드는 일을 선언(declaration), 값을 넣는 일을{' '} + 할당(assignment)이라고 부릅니다. 여기서 딱 하나 조심할 것 —{' '} + =는 수학의 "같다"가 아니라{' '} + "오른쪽 값을 왼쪽 상자에 넣어라"라는 명령이에요. +
+{CODE_BOX}
+ + 이름표는 아무렇게나 지을 수 없어요. 숫자로 시작하면 안 되고, 하이픈(-)이나 띄어쓰기도 + 안 되고, let 같은 예약어도 안 됩니다. 그리고 규칙보다 + 중요한 게 있어요 — 값의 정체가 드러나는 이름을 짓는 감각이요. +
+{CODE_NAMING}
+ + 변수(변하는 수)라는 이름 그대로,{' '} + let으로 만든 상자의 값은 언제든 바꿀 수 + 있어요. 게임 레벨이 오르고, 점수가 쌓이고, 남은 시간이 줄어드는 것 — 전부 + 변수의 값이 바뀌는 일입니다. 새 값을 넣으면 이전 값은 흔적 없이 + 사라진다(덮어쓰기)는 것만 기억하세요. +
++ 그런데 세상엔 바뀌면 큰일 나는 값도 있어요. 태어난 연도, 원주율, + 우리 서비스의 이름 같은 것들이요. 이런 값은 const + (constant, 상수)로 만듭니다. 한번 값을 넣으면 바꾸려는 순간 오류를 + 내면서 프로그램이 멈춰요 — 실수를 컴퓨터가 대신 막아 주는 거죠. +
+{CODE_CONST}
+ + 이제 상자에 담기는 값의 종류(자료형)를 하나씩 봅시다. 첫 번째는{' '} + 문자열(string) — 글자들이 실에 꿰인 듯 줄지어 선{' '} + 값이에요. 이름, 주소, 채팅 메시지, 지금 읽는 이 문장까지, 프로그램 속 모든 글자가 + 문자열입니다. 만드는 법은 간단해요 — 따옴표로 감싸면 끝. +
+{CODE_STRING}
+ + 작은따옴표('')와 큰따옴표("")는 + 완전히 같은 일을 해요. 그런데 세 번째 따옴표, 백틱 + (`` — 키보드 숫자 1 왼쪽의 키)은 특별합니다. 문자열 + 안에 변수를 끼워 넣는 구멍을 뚫을 수 있거든요. 이걸{' '} + 템플릿 리터럴이라고 불러요. +
+{CODE_TEMPLATE}
+ + 두 번째 자료형은 숫자(number)예요. 따옴표 없이 쓰면 + 숫자입니다. 다른 언어들은 정수와 소수를 다른 자료형으로 나누기도 하는데, + 자바스크립트는 17도 3.14도 + 똑같이 number 한 식구예요. 덧셈 뺄셈은 그대로인데, 곱하기는{' '} + *, 나누기는 /를 쓴다는 것만 + 새로 기억하면 됩니다. +
+{CODE_NUMBER}
+ + 낯선 친구는 %일 거예요. 퍼센트가 아니라{' '} + 나머지 연산자입니다. 10 % 3은 "10을 3으로 + 나눈 나머지", 즉 1이에요. "이게 어디에 쓰여?" 싶겠지만 —{' '} + 어떤 수를 2로 나눈 나머지가 0이면 짝수, 1이면 홀수. 다음 강좌에서 + 조건문을 배우면 이 아이디어로 홀짝 판별기를 만들게 됩니다. +
++ 세 번째 자료형은 좀 독특해요. 문자열은 무한히 많고 숫자도 무한히 많은데,{' '} + 불리언(boolean)은 값이 딱 두 개뿐입니다 —{' '} + true(참)와 false(거짓). + "지금 비가 오나?", "로그인했나?", "정답인가?" — 예/아니오로 답할 수 있는 모든 질문의 + 답을 담는 자료형이에요. +
++ 불리언은 직접 쓰기보다 비교의 결과로 태어나는 경우가 많아요.{' '} + {'>'}(크다), {'<'}(작다),{' '} + ===(같다) 같은 비교 연산자는 양쪽 값을 + 견줘 보고, 그 답을 반드시 true 아니면 false로 내놓습니다. +
+{CODE_BOOLEAN}
+ + "문자열이든 숫자든 그냥 값이면 됐지, 종류가 왜 중요해요?" 좋은 질문이에요. 답부터 + 말하면 — 컴퓨터는 값의 종류(자료형)를 보고 행동을 결정하기 때문입니다. + 겉보기엔 같은 +인데, 숫자 사이에선 덧셈을 + 하고 문자열이 끼어 있으면 이어 붙이기를 해요. +
++ 값의 정체가 궁금할 땐 typeof라는 돋보기를 대 보세요. + 값 앞에 붙이면 그 값의 자료형을 문자열로 알려 줍니다. +
+{CODE_TYPEOF}
+ + "1" + 1이 "11"이 되는 이유, + 이제 보이시죠? 왼쪽의 "1"은 따옴표에 싸인{' '} + 문자열이에요. 문자열이 낀 +는 이어 + 붙이기로 동작하니까, 숫자 1까지 글자 취급해서 "11"을 + 만듭니다. 오류도 안 내고 조용히 이상한 결과를 내놓는다는 게 진짜 + 함정이에요. +
++ 이제 손을 움직일 차례예요. 목표: 이름과 출생연도를 입력받아, 나이를 계산해서 + 자기소개 문장을 출력하는 프로그램. 오늘 배운 재료가 전부 들어갑니다 — + 변수(1), const(2), 템플릿 리터럴(3), 뺄셈(4), 그리고 형 변환(6)까지요. +
++ 새 등장인물은 prompt 하나뿐이에요. 브라우저에{' '} + 입력창을 띄우고, 사용자가 적은 내용을 문자열로 돌려주는 함수입니다. + 브라우저에서 F12를 눌러 콘솔(Console) 탭을 열고, 아래 + 코드를 한 줄씩 입력해 보세요. +
+{CODE_PRACTICE}
+ + 실행됐다면, 여기서 멈추지 말고 변수를 하나만 바꿔 보세요.{' '} + intro 문장은 그대로 두고{' '} + name에 친구 이름을 넣으면? 출생연도를 바꾸면? —{' '} + 변수 하나를 바꿨을 뿐인데 문장 전체가 따라 바뀌는 이 경험이 오늘의 + 핵심입니다. 값과 틀을 분리해 두면, 값만 갈아 끼워서 무한히 재사용할 수 있다 — 모든 + 프로그램이 이 원리로 만들어져요. +
++ 축하해요 — 프로그래밍의 가장 작은 부품을 손에 넣었습니다. 값을 상자에 담고(변수), + 바뀌면 안 되는 건 봉인하고(const), 글자·숫자·참거짓이라는 세 가지 재료를 구분하고 + (자료형), 형이 다르면 결과도 달라진다는 함정까지 겪어 봤어요. 그런데 지금 우리 + 프로그램은 위에서 아래로 한 길로만 흘러가죠. "나이가 19 이상이면 + 이렇게, 아니면 저렇게" — 상황을 보고 컴퓨터가 스스로 길을 고르게{' '} + 만들려면, 오늘 배운 불리언이 핵심 열쇠가 됩니다. 다음{' '} + 조건문: 컴퓨터가 판단하게 하기{' '} + 강좌에서 이어서 배워 봅시다. +
+{children}+ 코딩을 배우러 왔는데, 오늘은 코드를 한 줄도 쓰지 않을 거예요. 대신 + 그보다 훨씬 중요한 것부터 시작합니다 — 컴퓨터에게 '일을 시킨다'는 게 대체 무슨 + 뜻인지를 몸으로 이해하는 것. 이 감각이 잡히면, 앞으로 배울 모든 + 프로그래밍 언어가 "아, 결국 이 얘기구나" 하고 읽히기 시작해요. +
++ 영화 속 AI 때문에 컴퓨터가 엄청 똑똑하다고 느껴지지만, 진실은 반대예요.{' '} + 컴퓨터는 스스로 판단하는 능력이 전혀 없습니다. 눈치도 없고, 상식도 + 없고, "대충 알아서"라는 말을 세상에서 제일 못 알아듣는 기계죠. 컴퓨터가 잘하는 건 딱 + 두 가지 — 시킨 일을 엄청나게 빠르게, 그리고{' '} + 한 치의 오차 없이 그대로 하는 것뿐이에요. +
+{CODE_ROBOT}
+ + 위 오른쪽처럼, 사람이라면 한마디로 끝날 부탁을 컴퓨터에게는{' '} + 여덟 단계로 쪼개서, 하나하나 정확하게 말해 줘야 해요. 그리고 바로 이{' '} + '정확한 지시의 묶음'이 프로그램이고, 그걸 만드는 일이{' '} + 프로그래밍입니다. 어렵고 신비한 게 아니라, "바보지만 성실한 기계에게 + 일을 아주 자세히 시키는 기술"이에요. +
++ "프로그램"이라고 하면 컴퓨터 화면 속 뭔가를 떠올리기 쉽지만, 사실 여러분의 하루는 + 이미 프로그램으로 가득 차 있어요. 아침에 깨워 준 알람 앱, 등굣길에 탄{' '} + 엘리베이터, 건널목의 신호등 — 전부 누군가가 미리 + 써 둔 '정확한 지시의 묶음'이 돌아가고 있는 겁니다. +
++ 그리고 이 프로그램들을 뜯어 보면 놀랍도록 닮은 패턴이 하나 나와요. 바로{' '} + 입력 → 처리 → 출력입니다. 무언가를 받아서, 규칙대로 따져 보고, + 결과를 내보낸다 — 세상의 거의 모든 프로그램이 이 세 박자로 움직여요. +
+{CODE_IPO}
+ + 유튜브도 마찬가지예요. 검색어를 입력하면, 수많은 영상 중 뭘 보여 줄지{' '} + 처리(계산)하고, 목록을 화면에 출력하죠. 게임에서 + 버튼을 누르면(입력) 캐릭터가 점프할 위치를 계산해서(처리) 화면에 그려 냅니다(출력). + 앞으로 어떤 프로그램을 보든 "여기서 입력은 뭐고, 출력은 뭐지?"라고 물어보는 습관을 + 들여 보세요. +
++ 프로그램의 조상님을 하나 꼽으라면 요리 레시피예요. "무엇을, 어떤 + 순서로, 얼마나" — 정해진 단계를 순서대로 따라가면 누구나 같은 결과를 얻는 절차. + 이렇게 문제를 해결하는 단계들의 순서 있는 묶음을 멋진 말로{' '} + 알고리즘(algorithm)이라고 부릅니다. 라면 봉지 뒷면에 이미 하나 + 인쇄되어 있죠. +
+{CODE_RAMEN}
+ + 여기서 두 가지 감각을 가져가면 됩니다. 첫째, 순서가 결과를 바꾼다.{' '} + 같은 다섯 단계라도 순서를 섞으면 라면이 아니라 참사가 나와요. 컴퓨터는 우리가 쓴 + 순서를 절대 알아서 고쳐 주지 않으니, 순서를 정하는 건 온전히 프로그래머의 몫입니다. + 둘째, 한 단계만 빠져도 실패한다. "물이 끓으면"을 빼먹으면 찬물에 + 면을 넣게 되죠. 프로그램의 오류(버그)도 대부분 이런 '빠진 단계, 뒤집힌 순서'에서 + 나옵니다. +
++ "그럼 그냥 한국어로 시키면 안 돼요?" — 아주 좋은 질문이에요. 안 되는 이유는 사람의 + 말이 모호함투성이이기 때문입니다. 우리는 눈치와 경험으로 빈칸을 + 채우며 대화하지만, 컴퓨터는 모호함을 단 1도 견디지 못해요. +
+{CODE_AMBIGUOUS}
+ + 게다가 컴퓨터의 심장인 CPU가 실제로 알아듣는 말은 0과 1의 나열이 + 전부예요. 전기가 흐른다(1), 안 흐른다(0) — 이 두 가지 신호만으로 모든 걸 처리하죠. + 그렇다고 사람이 0과 1로 직접 지시를 쓰는 건 너무나 고통스럽기 때문에, 그 사이에{' '} + 프로그래밍 언어라는 다리를 놓았습니다. +
++ 그러니까 프로그래밍 언어는 사람과 기계 사이의 번역기예요. 사람이 + 읽고 쓸 수 있을 만큼은 사람의 말을 닮았고, 기계가 0과 1로 정확히 바꿀 수 있을 만큼은 + 엄격한 — 딱 중간의 언어. Python,{' '} + Java, JavaScript 같은 + 이름들을 들어 봤다면, 전부 이 '중간 언어'의 종류들입니다. +
++ 이제 진짜 코드를 구경해 봅시다. 아래는 Python이라는 언어로 쓴 세 + 줄짜리 프로그램이에요. print는 "괄호 안의 내용을 + 화면에 출력하라"는 명령입니다. +
+{CODE_RUN}
+ + 여기서 꼭 가져가야 할 감각은 하나예요. 코드는 위에서 아래로, 한 줄씩, 쓴 + 순서 그대로 실행된다. 섹션 3의 라면 레시피와 완전히 같은 원리죠. 1번 줄이 + 끝나야 2번 줄이 실행되고, 컴퓨터는 중간에 딴생각을 하거나 순서를 바꾸지 않습니다. +
++ 그리고 개발은 '한 번 쓰고 끝'이 아니라 사이클이에요. 쓰고, 돌려 보고, + 결과가 생각과 다르면 고치고, 다시 돌려 보고 — 이 반복 자체가 개발이라는 일의 + 본모습입니다. +
+{CODE_CYCLE}
+ + 개발자를 '하루 종일 코드만 치는 사람'으로 상상하기 쉽지만, 본질은 다릅니다. + 개발자는 문제를 코드로 푸는 사람이에요. "버스가 언제 올지 몰라 + 불편하다"는 문제를 도착 안내 앱으로, "손으로 계산하니 실수가 난다"는 문제를 자동 + 계산 프로그램으로 — 세상의 불편함을 찾아 정확한 절차로 바꿔 내는 + 직업이죠. +
++ 푸는 문제의 종류에 따라 분야도 다양하게 갈라져요. 웹사이트를 만드는{' '} + 웹 개발자, 스마트폰 앱을 만드는 앱 개발자, 게임 속 + 세계를 짓는 게임 개발자, 데이터에서 답을 찾고 인공지능을 만드는{' '} + AI·데이터 개발자, 그리고 이 모든 서비스가 돌아가는 서버를 책임지는{' '} + 서버(백엔드) 개발자까지. 쓰는 언어와 도구는 달라도, 전원의 + 공통분모는 오늘 배운 것 — 문제를 컴퓨터가 알아들을 만큼 정확한 단계로 쪼개는 + 능력입니다. +
++ 그래서 오늘 이 40분이 그냥 워밍업이 아니에요. "컴퓨터는 시킨 대로만 한다", + "입력→처리→출력", "순서가 결과를 정한다", "모호함을 정확함으로 바꾼다" — 이 네 + 문장은 여러분이 어떤 분야의 개발자가 되든 끝까지 들고 가는 출발점 + 입니다. +
++ 이론은 여기까지! 이제 컴퓨터가 요구하는 '정확함'이 어떤 느낌인지 직접 겪어 볼 + 차례예요. 준비물은 컴퓨터가 아니라 종이와 펜, 그리고 친구 한 명 + 입니다. 친구가 컴퓨터(로봇) 역할을 맡아요. +
+{CODE_DRAW}
+ + 이 놀이의 핵심 규칙은 "로봇은 질문할 수 없다"예요. 진짜 컴퓨터도 + 그렇거든요. 지시가 모호하면 되묻는 대신, 이상한 결과를 내거나 멈춰 버립니다. + "창문은 알아서"라고 말한 순간 그림이 산으로 가는 경험 — 그게 바로 전 세계 개발자들이 + 매일 겪는 버그의 정체예요. +
++ 그리고 오늘의 본 과제. '아침에 일어나 학교 가기'를 컴퓨터가 이해할 수준으로 + 15단계 이상 쪼개서 종이에 써 보세요. 이 과정에는 이름도 있어요 — 큰 문제를 + 컴퓨터가 처리할 수 있는 작은 단계로 나누는 것, 개발자들이 매일 하는 일의 심장부입니다. +
+{CODE_HOMEWORK}
+ + 축하해요 — 코드를 한 줄도 쓰지 않고, 프로그래밍의 심장을 이해했습니다.{' '} + 컴퓨터는 시킨 것만 시킨 그대로 하는 기계이고, 프로그램은{' '} + 정확한 지시의 순서 있는 묶음이며, 프로그래밍 언어는 사람과 0과 1 + 사이의 번역기라는 것. 그리고 등교 과정을 15단계로 쪼개면서, 큰 + 문제를 작은 단계로 나누는 개발자의 눈을 처음 떠 봤어요. 다음 코스에서는 이 '쪼개는 + 눈'을 본격적으로 훈련합니다 — 패턴을 찾고, 불필요한 것을 걷어 내고, 절차를 + 설계하는 생각법이요. 컴퓨터처럼 + 생각하기: 컴퓨팅 사고 코스에서 이어서 만나요. +
+{children}+ 실전 웹 개발의 절반은 데이터 다듬기예요. 서버가 주는 JSON은 날것의 + 재료일 뿐, 화면에 올리려면 골라내고(filter), 모양을 바꾸고(map), 집계하고(reduce), + 줄을 세워야(sort) 하죠. 이 코스에서는 for문 대신{' '} + 배열 메서드라는 잘 벼린 칼들로 — 주문 내역 200건을{' '} + TOP 5 랭킹과 월별 매출표로 요리하는 실전 기술을 익힙니다. +
++ 기초 과정에서 배운 for문으로도 모든 데이터 작업은 가능해요. 그런데 + 실무 코드를 열어 보면 for문 대신 map· + filter·reduce가 압도적으로 + 많습니다. 왜일까요? 답은 "누가 읽는 코드인가"에 있어요. for문은 인덱스 변수, 조건문, + push까지 어떻게(how) 할지를 전부 지시하지만, 배열 메서드는{' '} + 무엇을(what) 원하는지만 선언합니다. +
+{CODE_FOR_VS_METHOD}
+ + 두 코드는 결과가 완전히 같아요. 하지만 두 번째 코드를 읽는 동료는{' '} + filter와 map이라는 단어만 + 보고도 "골라서, 바꾸는구나"를 3초 만에 압니다. 코드는 쓰는 시간보다{' '} + 읽히는 시간이 훨씬 긴 물건이라, 이 3초의 차이가 쌓이면 팀 전체의 + 속도가 됩니다. +
++ map은 배열의 모든 요소에 같은 함수를 적용해 + 새 배열을 만드는 메서드예요. 개수는 그대로, 모양만 바뀝니다. 가장 흔한 + 실전 용도는 서버 모양 → 화면 모양 변환이에요. 서버는{' '} + order_id·total_price 같은 + 자기 사정에 맞는 필드를 주지만, 화면은 "42,000원"처럼 다듬어진 값을 원하니까요. +
+{CODE_MAP_SHAPE}
+ + 여기서 원칙 하나를 새기세요. map은 원본을 절대 건드리지 않습니다.{' '} + 변환 결과는 언제나 새 배열이고, res는 + 받았을 때 모습 그대로 남아요. 원본이 살아 있으면 "다른 화면에서는 원 단위 숫자가 + 필요한데?" 같은 요구가 와도 다시 요리할 수 있죠. 이 불변성 감각은 + 섹션 5의 sort에서 다시 시험대에 오릅니다. +
+{CODE_MAP_MISTAKE}
+ + filter는 조건 함수 하나를 받아, 그 + 함수가 true를 돌려준 요소들만 모은 새 배열을 + 만들어요. "결제 완료 주문만", "만원 이상만", "이번 달 것만" — 목록 화면의 온갖 + 필터가 전부 이 한 줄입니다. +
+{CODE_FILTER_FIND}
+ + filter와 find는 겉이 + 닮아서 자주 헷갈려요. 구분 기준은 결과의 자료형입니다.{' '} + filter는 조건에 맞는 전부를 담은{' '} + 배열(하나도 없으면 빈 배열 []),{' '} + find는 조건에 맞는 첫 하나인{' '} + 요소 자체(없으면 undefined)를 돌려줘요. + 목록엔 filter, 상세 조회엔 find — 손에 익혀 두세요. +
++ 한편 "있는지 여부만 궁금할" 때가 있어요. 환불 건이 하나라도 있으면 + 경고 배지를 띄운다든가요. 그럴 땐 배열을 만들 필요 없이{' '} + some(하나라도 만족?)과{' '} + every(전부 만족?)가 true/false + 로 바로 답해 줍니다. +
++ map과 filter는 배열을 넣으면 배열이 나와요. 그런데 실습 과제인 "고객별{' '} + 총 구매액"이나 "월별 매출 합계"는 배열이 아니라{' '} + 접힌 결과 하나가 필요하죠. 그 접기(fold)를 담당하는 칼이{' '} + reduce입니다. 누산기(accumulator)라는 그릇을 들고 + 배열을 한 바퀴 돌면서, 요소를 하나씩 그릇에 누적해 나가요. +
+{CODE_REDUCE_SUM}
+ + 진짜 힘은 누산기가 숫자일 필요가 없다는 데서 나옵니다. 빈 객체{' '} + {'{}'}를 초기값으로 주면, 배열을 돌며 객체에 키를 채우는{' '} + 그룹핑이 돼요. 실습 과제의 두 집계가 모두 이 패턴 하나로 풀립니다. +
+{CODE_REDUCE_GROUP}
+ + 그리고 reduce에서 가장 자주 터지는 버그 — 초기값 누락입니다. 초기값을 + 생략하면 자바스크립트는 배열의 첫 요소를 누산기의 출발점으로 삼아요. + 숫자 배열의 합계라면 우연히 맞지만, 객체 배열이라면 첫 바퀴의 누산기가{' '} + 주문 객체 자체가 되어 엉뚱한 결과가 나옵니다. +
+{CODE_REDUCE_BUG}
+ + 랭킹을 만들려면 줄 세우기가 필요하죠. sort는{' '} + 비교 함수 (a, b) => 리턴값을 받는데, + 약속은 딱 세 가지예요. 음수면 a가 앞, 양수면 b가 앞, + 0이면 그대로. 그래서 숫자 오름차순은 a - b, 내림차순은{' '} + b - a 한 줄로 끝납니다. +
+{CODE_SORT_COMPARE}
+ + 비교 함수를 생략하면 모든 요소를 문자열로 바꿔{' '} + 사전순 비교합니다. 그래서 [5, 1, 30]이{' '} + [1, 30, 5]가 되는 유명한 함정이 생겨요. 숫자 정렬엔 + 비교 함수 필수, 한글 문자열엔 localeCompare, 날짜는{' '} + new Date()로 바꿔 숫자처럼 — 세 가지 요령을 세트로 + 기억하세요. +
++ 더 무서운 함정은 따로 있어요. map·filter가 새 배열을 돌려주는 것과 달리,{' '} + sort는 원본 배열 자체를 재배열합니다. + 정렬 한 번 했을 뿐인데 다른 화면의 순서까지 바뀌어 있는 미스터리의 범인이 대개 + 이 녀석이에요. +
+{CODE_SORT_MUTATE}
+ + 칼을 하나씩 익혔으니 이제 요리 라인을 만들 차례예요. 배열 메서드는 + 결과가 다시 배열(또는 접힌 값)이라, 점(.)으로 이어 붙일 수 있습니다. + 재료가 컨베이어 벨트를 타고 공정을 하나씩 통과하는 그림이죠. 실습 과제의 절반인{' '} + TOP 5 랭킹이 정확히 이 파이프라인입니다. +
+{CODE_PIPELINE}
+ + 중간에 낯선 얼굴이 하나 있죠? reduce로 접은 결과는 객체라서 배열 + 메서드를 바로 못 씁니다. Object.entries()가 객체를{' '} + [키, 값] 쌍의 배열로 되돌려 주는 다리 + 역할을 해요. 객체 ↔ 배열을 오가는 이 왕복이 실전 집계 코드의 단골 패턴입니다. +
++ 다만 체이닝에도 과유불급이 있어요. 한 체인이 너무 길어지면 중간에 + 어떤 모양의 데이터가 흐르는지 머리로 따라가기 어려워집니다. 그럴 땐 중간 결과를 + 변수로 끊고 이름을 붙이세요. +
+{CODE_PIPELINE_DEBUG}
+ + 연습용 데이터는 평평하지만, 진짜 API 응답은 객체 안에 배열, 배열 안에 객체가 + 겹겹이 쌓여 있어요. 주문 하나에 상품이 여러 개 담기는 것처럼요. 이 중첩을 다루는 + 두 가지 필수 도구로 코스를 마무리합니다. +
++ 첫째, flatMap. "모든 주문의 상품을 + 한 줄로 나열하고 싶다"에서 map만 쓰면 배열의 배열이라는 두 겹 결과가 + 나와요. flatMap은 map을 하고 나서 한 겹을 펼쳐(flat), 바로 쓸 수 있는 + 평평한 배열을 만들어 줍니다. +
+{CODE_FLATMAP}
+ + 둘째, 옵셔널 체이닝 ?.. 섹션 3에서 + 예고했죠 — find가 못 찾으면{' '} + undefined고, 중첩 응답에는 없을 수도 있는 필드가 + 흔합니다. undefined에 점을 찍는 순간 TypeError로 화면이 + 통째로 하얗게 되니, ?.로 방어벽을 세워야 해요. +
+{CODE_OPTIONAL}
+ + 이제 날것의 JSON 앞에서 막막해하는 대신, 골라서(filter) → 모양 바꾸고(map) + → 접고(reduce) → 줄 세우는(sort) 요리 순서가 머리에 그려질 거예요. 원본을 + 지키는 불변성 감각, 초기값·반환 누락 같은 덫의 위치, 중첩 데이터를 펼치고 방어하는 + 요령까지 — 화면에 올릴 데이터를 스스로 다듬는 손을 갖췄습니다. 그런데 이 재료들, + 애초에 서버가 어떤 모양으로 주느냐도 누군가의 설계죠. 다음{' '} + REST API 설계: 주소와 동사의 문법{' '} + 코스에서, 이번엔 데이터를 건네는 쪽의 문법을 배워 봅시다. +
+{children}+ 기초 문법을 배웠는데도 "진짜 서비스"가 안 만들어지는 이유의 절반은{' '} + 비동기에 있어요. 서버는 언제 대답할지 모르는데, JavaScript는 한 번에 + 한 가지 일밖에 못 하니까요. 이 코스에서 콜백 지옥에서 async/await까지의 + 진화를 따라 걷고, 마지막엔 로딩 스피너·에러 메시지·재시도 버튼을 갖춘{' '} + 환율 검색 위젯을 직접 만들어 봅니다. +
++ 출발점은 체험이에요. 아래 코드를 브라우저 콘솔에 붙여 넣고 실행해 보세요. 함수가 도는 + 3초 동안 클릭도, 스크롤도, 입력도 전부 먹통이 됩니다. JavaScript는{' '} + 싱글 스레드 — 일꾼이 한 명뿐이라, 그 일꾼이 제자리에서 기다리면 화면을 + 그릴 사람이 없거든요. +
+{CODE_FREEZE}
+ + 그런데 웹 서비스의 핵심 일과는 네트워크 요청이에요. 서버가 0.1초 만에 + 대답할지, 3초 걸릴지, 영영 대답이 없을지 보내기 전엔 알 수 없죠. 이 + "언제 끝날지 모르는 일"을 일꾼이 그 자리에서 기다리면 앱은 서버가 느린 만큼 얼어붙어요. + 그래서 JavaScript는 다른 전략을 택합니다 — 기다리지 않고, 맡기는 거예요. +
+{CODE_KITCHEN}
+ + "일을 맡겼으면, 끝났을 때 뭘 할지도 알려 줘야" 하죠. 가장 원시적인 방법이{' '} + 콜백(callback) — 나중에 불러 달라고 함수를 인자로 넘기는{' '} + 방식입니다. 이미 써 보셨을 거예요. addEventListener의 두 + 번째 인자, setTimeout의 첫 번째 인자가 전부 콜백입니다. +
+{CODE_CALLBACK}
+ + 한 단계짜리 일이면 콜백도 충분해요. 문제는 순차 작업입니다. "환율을 + 받아서 → 그걸로 환전 계산을 하고 → 결과를 기록한다"처럼 앞 결과가 다음 단계에 필요하면, + 콜백 안에 콜백을, 그 안에 또 콜백을 넣을 수밖에 없어요. +
+{CODE_HELL}
+ + Promise는 "지금은 결과가 없지만 나중에 꼭 주겠다"는{' '} + 약속을 담은 객체예요. 콜백처럼 함수를 미리 찔러 넣는 게 아니라, 일단 + 약속 객체를 손에 받아 두고 거기에 "성공하면 이거, 실패하면 저거"를 + 붙이는 방식이죠. 약속의 일생은 세 상태로 요약됩니다. +
+{CODE_PROMISE_STATE}
+
+ 그림: Promise는 pending에서 출발해 fulfilled 또는 rejected 중 하나로 단 한 번 정착한다
++ 약속에 후속 작업을 붙이는 문법이 then(성공 시)과{' '} + catch(실패 시)예요. 그리고{' '} + then은 항상 새 Promise를 반환하기 때문에, + 콜백 지옥의 계단을 수평 사슬로 펼 수 있습니다. +
+{CODE_THEN}
+ + then 체인은 훌륭하지만, 로직이 길어지면{' '} + function과 return이 + 반복되며 눈이 미끄러져요. 그래서 나온 최종 진화형이{' '} + async/await — 같은 Promise를 동기 코드처럼 읽히는 모양 + 으로 쓰는 문법입니다. 섹션 3의 체인을 그대로 옮겨 볼게요. +
+{CODE_AWAIT}
+ + 짚어 둘 것은 await가 '문법 설탕(syntactic sugar)'이라는 점이에요. 새 + 동작이 생긴 게 아니라, then 체인과 같은 일을 다르게 표기할 뿐입니다.{' '} + await 뒤의 Promise가 정착할 때까지 그 함수의 실행이 + 멈추는데 — 섹션 1의 while 루프와 달리{' '} + 화면은 얼지 않아요. 함수만 잠들고, 일꾼(콜 스택)은 풀려나 다른 주문서를 + 처리하러 가거든요. +
++ 에러 처리는 우리가 아는 try/catch 그대로입니다.{' '} + try 블록 안 어느 await에서 실패해도 실행이{' '} + catch로 점프해요. 콜백 지옥에서 세 군데로 흩어졌던 에러 + 처리가, 여기선 익숙한 문법 한 곳으로 모입니다. +
++ 이제 도구가 갖춰졌으니 진짜 서버와 대화해 봅시다.{' '} + fetch는 브라우저에 내장된 HTTP 요청 함수로, Promise를 + 돌려줘요. 구조에서 헷갈리기 쉬운 건 await가 두 번 나온다는 점입니다 — + ① 응답(헤더)이 도착하길 기다리고, ② 본문이 다 내려와 해석되길 또 기다립니다. +
+{CODE_FETCH}
+ + 주석의 함정을 꼭 기억하세요. fetch는{' '} + 404나 500 같은 에러 응답에도 reject되지 않습니다. 서버가 "실패"라고 + 대답한 것과, 대답 자체가 안 온 것(네트워크 단절)을 구분하기 때문이에요. HTTP 수준의 + 실패를 잡으려면 res.ok(상태 코드 200~299면 true)를 확인해 + 직접 throw해야, 섹션 4에서 만든{' '} + catch 그물에 걸립니다. +
++ 데이터를 보내는 쪽도 옵션 객체 하나로 해결돼요. 메서드, 헤더, 본문을 + 지정하면 POST 요청이 됩니다. +
+{CODE_POST}
+ + await가 편하다 보니 생기는 흔한 낭비가 있어요. 서로 상관없는 요청 + 세 개를 순서대로 await하면, 앞 요청이 끝나야 다음이{' '} + 출발합니다. 달러·유로·엔 환율은 서로를 필요로 하지 않는데도요. +
+{CODE_PARALLEL}
+ + Promise.all은 Promise 배열을 받아{' '} + 전부 fulfilled되면 결과 배열을 (넣은 순서 그대로) 돌려줍니다. 단, + 성격이 확실해요 — 하나라도 rejected되면 전체가 즉시 reject됩니다. + "전원 성공 아니면 전체 실패"죠. 부분 실패를 살리고 싶을 땐{' '} + Promise.allSettled를 씁니다. +
+{CODE_ALLSETTLED}
+ + 문법을 다 배워도 실전 코드엔 한 층이 더 있어요. 요청이 나가 있는 동안 사용자는{' '} + 뭔가를 보고 있어야 하고, 실패하면 다음 행동(재시도)을 + 제안받아야 하죠. 그래서 서버와 대화하는 화면은 언제나{' '} + 로딩 · 성공 · 실패라는 3상태 중 하나에 있습니다. 이번 코스의 실습 + — 환율 검색 위젯의 골격이 바로 이 3상태 관리예요. +
+{CODE_WIDGET}
+ + 여기에 실무 감각 두 가지를 더하면 완성입니다. 첫째, 취소. 사용자가 + 검색을 연타하면 이전 요청은 의미가 없어지는데, 늦게 도착한 옛 응답이 새 화면을 덮어쓰는 + 사고가 나요. 둘째, 타임아웃. 서버가 영영 대답하지 않으면 로딩 스피너가 + 무한히 돕니다. 둘 다 AbortController 하나로 해결돼요. +
+{CODE_ABORT}
+ + 이제 "서버와 대화하는 코드"의 전체 지형이 손에 있어요. 이벤트 루프(주방), 콜백 지옥이 + 남긴 교훈, Promise의 3상태(진동벨), async/await라는 문법 설탕, fetch의 2단계와{' '} + res.ok 습관, Promise.all의 병렬 감각, 그리고 로딩·취소·타임아웃까지 — + 환율 위젯 하나에 전부 담아 봤습니다. 그런데 서버에서 받아 온 데이터는 대부분{' '} + 배열이에요. 받아 온 환율 목록을 골라내고(filter), 바꾸고(map), + 합치는(reduce) 손맛이 다음 관문입니다. 다음{' '} + 배열 메서드로 데이터 요리하기{' '} + 코스에서, fetch로 받아 온 데이터를 화면에 올리기 좋게 다듬는 기술을 이어서 익혀 봅시다. +
+{children}+ 지금까지 만든 API는 누가 요청해도 똑같이 응답했어요. 하지만 진짜 + 서비스엔 '내 계정'이 있죠. 이 코스에서는 비밀번호를 지키는 법(해시)과{' '} + 사용자를 기억하는 법(세션)을 배워, 회원가입부터 "내 글만 수정 가능" + 까지 — 계정이 있는 서비스의 뼈대를 직접 세웁니다. +
++ 로그인을 구현하기 전에, 단어부터 정확히 잡고 갑시다. 인증(Authentication)은 + "너 누구야?"를 확인하는 일이에요. 이메일과 비밀번호를 받아 "아, 김수습 + 님이군요"라고 신원을 확인하는 것 — 로그인이 바로 인증입니다. 인가(Authorization)는 + 그 다음 질문, "너 이거 해도 돼?"예요. 로그인한 사용자라도 남의 글을 + 지울 수는 없어야 하죠. 이 코스는 1~5섹션에서 인증을, 6섹션에서 인가를 구현합니다. +
++ 그런데 왜 이게 어려운 문제일까요? HTTP는 기억력이 없기 때문이에요. + 요청 하나하나가 서로를 모르는 남남입니다. 1초 전에 로그인에 성공했어도, 다음 요청이 + 오면 서버는 "누구세요?"부터 다시 시작해요. 이걸 무상태(stateless)라고 + 부릅니다. 그래서 "로그인했다"는 상태를 어딘가에 이어 붙이는 장치가 + 필요하고, 그 장치가 이 코스의 주인공인 세션과 쿠키예요. +
+{CODE_FLOW}
+ + 위 그림이 이 코스의 전체 지도입니다. ①회원가입(섹션 3) → ②~③로그인과 세션 발급(섹션 + 4~5) → ④인증된 요청(섹션 6) → ⑤로그아웃(섹션 5). 각 화살표를 하나씩 코드로 + 바꿔 나갈 거예요. +
++ 회원가입 API를 만들기 전에 반드시 짚어야 할 철칙이 있어요.{' '} + 비밀번호를 평문(입력된 그대로)으로 저장하면 안 됩니다. 실제로 국내외 + 유명 서비스들이 DB 유출 사고를 겪었고, 평문 저장이었던 곳은 사용자 전원의 비밀번호가 + 그대로 공개됐어요. 더 무서운 건 비밀번호 재사용이에요 — 한 사이트에서 + 털린 이메일·비밀번호 조합으로 다른 사이트 로그인을 시도하는 공격(크리덴셜 스터핑)이 + 바로 이어집니다. 내 서비스의 부주의가 사용자의 다른 계정까지 위험하게 + 만드는 거죠. +
+{CODE_PLAINTEXT}
+ + 해법은 해시(hash)입니다. 해시 함수는 입력을 고정 길이의 뒤죽박죽 + 문자열로 바꾸는데, 결정적인 성질이 하나 있어요 — 일방통행이라는 것. + 비밀번호 → 해시는 순식간이지만, 해시 → 비밀번호로 되돌리는 것은 불가능 + 합니다. 암호화(encrypt)와 다른 점이 바로 여기예요. 암호화는 열쇠가 있으면 복호화가 + 되지만, 해시는 애초에 되돌릴 수 없게 설계됐어요. 서버조차 사용자의 비밀번호 원문을 + 모르는 상태 — 그게 목표입니다. +
+{CODE_HASH}
+ + 위 코드에서 눈여겨볼 것 두 가지. 첫째, 같은 비밀번호인데 해시가 매번 다릅니다.{' '} + bcrypt가 무작위 솔트(salt)를 섞기 때문인데, 덕분에 공격자가 "자주 쓰는 + 비밀번호 100만 개의 해시"를 미리 계산해 와도(레인보 테이블) 우리 DB엔 안 통해요. + 둘째, bcrypt는 일부러 느립니다. cost 값(예제의 10)을 올릴수록 한 번 + 해시에 더 오래 걸려서, 초당 수백만 번 대입해 보려는 공격자의 비용이 폭증해요. + "느린 게 장점"인 흔치 않은 함수입니다. +
++ 이제 첫 코드를 짤 차례예요. 회원가입 API의 뼈대는 세 단계입니다.{' '} + ① 이메일 중복 체크 — 이미 가입된 이메일이면{' '} + 409 Conflict로 거절합니다. 409는 "요청 자체는 이해했지만 + 현재 상태와 충돌한다"는 뜻으로, 중복 자원에 딱 맞는 상태 코드예요.{' '} + ② 해시해서 저장 — 섹션 2에서 배운{' '} + bcrypt.hash로 변환한 값만 DB에 넣습니다.{' '} + ③ 응답 골라 담기 — 성공 응답(201 Created)에 + 비밀번호 관련 필드는 절대 싣지 않아요. +
+{CODE_SIGNUP}
+ + ③이 사소해 보여도 실무 사고의 단골이에요. res.json(user)처럼 + DB에서 꺼낸 객체를 통째로 응답에 넘기면, 지금은 괜찮아 보여도 나중에 + 누가 컬럼을 추가하는 순간 그 값까지 줄줄 새어 나갑니다. "응답엔 필요한 필드만{' '} + 골라 담는다"를 처음부터 손에 익히세요 — 해시조차 밖으로 내보낼 이유가 + 없습니다. +
++ 섹션 1에서 봤듯 HTTP는 기억력이 없어요. 그래서 로그인 성공의 '증표'를 매 요청에 실어 + 보내야 하는데, 그 왕복 구조가 세션 + 쿠키입니다. 흐름은 이래요. + 로그인에 성공하면 서버가 세션 저장소에 "세션ID abc1{' '} + = 사용자 7번"이라고 기록하고, 응답 헤더 Set-Cookie로 그{' '} + 세션ID만 브라우저에 건넵니다. 브라우저는 받은 쿠키를 저장해 뒀다가, + 이후 같은 사이트로 가는 모든 요청에 자동으로 실어 보내요. 서버는 쿠키 + 속 세션ID로 저장소를 뒤져 "아, 7번 사용자구나"를 복원합니다. +
+{CODE_SESSION}
+ + 여기서 역할 분담이 중요해요. 브라우저가 들고 다니는 건 뜻 없는 무작위 문자열 + (세션ID)뿐이고, "그게 누구인지"라는 실제 정보는 서버 쪽 세션 저장소에 + 있습니다. 마치 코트 보관소의 번호표처럼요 — 번호표 자체엔 코트에 대한 정보가 하나도 + 없죠. 대신 이 구조의 대가로, 서버는 로그인한 사용자 수만큼 세션을 기억하고 + 있어야 합니다(상태를 서버가 짊어지는 방식). 저장소는 개발 단계에선 메모리로 + 충분하고, 서비스가 커지면 Redis 같은 별도 저장소로 옮깁니다. +
++ 재료가 다 모였어요. 로그인은 ① 이메일로 사용자 찾기 → ② bcrypt.compare로 + 비밀번호 대조 → ③ 세션에 사용자 기록 순서입니다. 로그아웃은 그 반대로, + 서버의 세션을 파기하고 브라우저의 쿠키도 지우게 하는 + 것까지가 한 세트예요. +
+{CODE_LOGIN}
+ + 코드에서 일부러 그렇게 짠 부분이 하나 있어요. 이메일이 틀렸든 비밀번호가 틀렸든{' '} + 똑같이 "이메일 또는 비밀번호가 올바르지 않습니다"라고 답합니다. 왜 + 친절하게 구분해 주면 안 될까요? "비밀번호가 틀렸습니다"라고 알려주는 순간, 공격자에게{' '} + "이 이메일은 가입돼 있다"는 사실을 공짜로 확인시켜 주기 때문이에요. + 그 목록을 모아 비밀번호 대입 공격의 표적을 좁히죠. 에러 메시지는 사용자에겐 조금 + 불친절해도, 공격자에게 정보를 흘리지 않는 쪽이 원칙입니다. +
++ 로그아웃도 뜯어볼게요. req.session.destroy()만 하고 쿠키를 + 안 지우면 브라우저에 죽은 번호표가 남고, 반대로 쿠키만 지우고 서버 세션을 안 지우면{' '} + 서버엔 여전히 유효한 세션이 살아 있어요. 누군가 그 세션ID를 알고 있다면 + 로그아웃했다고 믿는 사용자 행세를 계속할 수 있습니다. 그래서 로그아웃 ={' '} + 서버 세션 파기 + 쿠키 제거, 반드시 둘 다입니다. +
++ 이제 "로그인한 사람만" 쓸 수 있는 API를 만들 차례예요. 순진하게 만들면 모든 핸들러 + 첫 줄마다 if (!req.session.userId) ...를 복사하게 되는데, + 라우트가 10개면 10번 복붙이고 하나라도 빠뜨리면 그대로 구멍입니다. Express의{' '} + 미들웨어가 정확히 이 문제를 풉니다 — 검사를 함수 하나로 + 모으고, 보호가 필요한 라우트에 끼워 넣는 거예요. +
+{CODE_AUTH_MW}
+ + requireLogin이 하는 일은 두 가지입니다. 세션에 사용자가 + 없으면 401로 끊어서 401 처리를 일원화하고, + 있으면 DB에서 사용자를 찾아 req.user에 실어{' '} + 다음 핸들러로 넘겨요(next()). 덕분에 뒤쪽 핸들러들은 + "여기 도달했다 = 로그인된 상태다"를 보장받고, req.user.id를 + 바로 꺼내 쓸 수 있습니다. +
++ 그리고 드디어 인가가 등장합니다. 글 수정 라우트를 보세요 — 로그인 + 검사(인증)를 통과했어도, post.authorId !== req.user.id면{' '} + 403 Forbidden으로 거절해요. 이게 소유권 검사입니다. + "누구냐"(401 문제)와 "네 것이냐"(403 문제)가 코드에서 어떻게 다른 층으로 갈라지는지, + 섹션 1의 구분이 여기서 실물이 됩니다. +
++ 완벽한 보안은 이 코스의 범위를 넘지만, 이것조차 없으면 곤란한 기본기 세 가지는 + 챙기고 마칩시다. 첫째, 쿠키 옵션. 세션ID는 곧 출입증이라 새어 나가면 + 끝이에요. httpOnly는 페이지의 자바스크립트가{' '} + document.cookie로 쿠키를 읽지 못하게 막아서, 악성 + 스크립트가 주입돼도(XSS) 세션ID 탈취를 어렵게 합니다.{' '} + secure는 HTTPS 연결에서만 쿠키를 전송하게 해서 중간 + 도청을 차단하고요. +
+{CODE_DEFENSE}
+ + 둘째, 로그인 시도 제한. 공격자는 자주 쓰는 비밀번호 목록을 기계적으로 + 대입합니다(무차별 대입, brute force). bcrypt가 한 번 한 번을 느리게 만들어 주지만, + 서버 차원에서도 "5회 연속 실패 → 잠시 잠금(429)" 같은 + 제한을 걸면 공격 비용이 훨씬 올라가요. 실패 횟수를 세고 성공하면 지우는, 단순한 + 카운터로 시작하면 됩니다. +
++ 셋째, 세션ID 재발급. 섹션 5에서 예고한 세션 고정(session + fixation) 공격은 이렇게 흘러가요 — 공격자가 세션ID 하나를 미리 확보해 피해자의 + 브라우저에 심어 둡니다 → 피해자가 그 세션ID를 단 채로 로그인합니다 → 서버가 그 세션을 + 그대로 "로그인됨"으로 승격시키면, 같은 세션ID를 아는 공격자도 로그인 상태가 + 돼요. 방어는 간단합니다. 로그인 성공 직후 세션ID를 새로 발급 + (regenerate)하면, 공격자가 심어 둔 옛 ID는 휴지 조각이 + 됩니다. +
++ 이제 여러분의 블로그 API엔 계정이 생겼습니다. 비밀번호는 해시로만 + 저장되고(솔트 덕에 같은 비번도 다른 해시), 로그인하면 세션ID라는 번호표가 쿠키로 + 오가고, 보호 라우트는 401로, 남의 글은 403으로 끊어 내죠. "누구냐(인증)"와 + "해도 되냐(인가)"를 코드로 갈라 본 경험은 앞으로 어떤 프레임워크를 만나도 그대로 + 통합니다. 다음은 화면 차례예요 — 로그인 폼의 입력값은 어디에 두고, "로그인됨" + 상태는 화면에 어떻게 반영할까요? 다음{' '} + React 상태와 이펙트 실전{' '} + 코스에서, 오늘 만든 API에 살아 움직이는 프론트엔드를 붙여 봅시다. +
+{children}+ 지금까지 우리 블로그 API의 데이터는 서버의 변수 안에 살았어요. + 서버를 껐다 켜면? 전부 증발합니다. 이 코스에서는 그 데이터를{' '} + PostgreSQL이라는 진짜 집으로 이사시키고, "댓글도 달렸는데 댓글수는 + 안 올라간" 어정쩡한 상태가 생기지 않도록 트랜잭션(all-or-nothing) + 으로 묶는 법까지 익힙니다. +
++ 백문이 불여일견이에요. 지금 만든 블로그 API에 글을 몇 개 올린 다음,{' '} + 서버를 껐다 켜 보세요. 정성 들여 쓴 글이 흔적도 없이 사라집니다. + 변수는 프로세스의 메모리(RAM) 위에 살고, 프로세스가 죽으면 메모리는 + 운영체제에 반납되니까요. +
+{CODE_MEMORY_LOSS}
+ + 데이터베이스는 이 문제를 포함해 크게 세 가지를 해결해 줍니다.{' '} + ① 영속성 — 데이터를 디스크에 안전하게 기록해서, 서버가 죽든 정전이 + 나든 살아남게 합니다. ② 동시성 — 사용자 100명이 동시에 글을 쓰고 + 지워도 데이터가 꼬이지 않게 교통정리를 해 줍니다(배열에 동시에 push하는 상황을 + 상상해 보세요). ③ 검색 — "제목에 'DB'가 들어간 글을 최신순으로 + 10개"를, 데이터가 백만 건이어도 순식간에 찾아 줍니다. 배열이었다면 매번 전체를 + 훑어야 했겠죠. +
++ 그중에서도 우리는 관계형 DB(PostgreSQL)를 선택합니다. 기준은 + 단순해요. 우리 데이터는 글·댓글·사용자처럼 서로 관계를 맺는 정형 + 데이터이고, "댓글수와 실제 댓글이 어긋나면 안 된다" 같은{' '} + 정합성이 중요하며, 뒤에서 배울 트랜잭션이 + 필요하니까요. 이 세 조건에 관계형 DB만큼 검증된 도구가 없습니다. +
++ 관계형 DB의 세계에서 데이터는 테이블(표)에 삽니다. 우리 블로그의 + 등장인물은 셋 — 사용자, 글, 댓글. 각각을 표 하나씩으로 옮기고, + 그 사이의 관계를 선으로 잇는 게 설계의 전부예요. +
+{CODE_SCHEMA}
+ + 핵심 개념 두 개만 잡으면 됩니다. PK(기본키, Primary Key)는 각 행의{' '} + 주민번호예요. 같은 이름의 사용자가 두 명이어도{' '} + id는 절대 겹치지 않아서, "그 행"을 정확히 집어낼 수 + 있죠. FK(외래키, Foreign Key)는 다른 테이블의 PK를 가리키는{' '} + 연결고리입니다. comments.post_id가{' '} + posts.id를 가리키는 순간, "이 댓글은 저 글의 것"이라는 + 관계가 데이터에 새겨져요. +
++ "글 하나에 댓글 여러 개"처럼 1:N 관계는 항상{' '} + N 쪽 테이블에 외래키 컬럼 하나를 두는 것으로 표현합니다. 댓글(N)이 + 자기 몸에 post_id를 적어 두는 거예요. 글(1) 쪽에 + "내 댓글 목록"을 배열로 넣지 않는다는 점이 배열 시절과 가장 다른 사고방식입니다. +
++ 이제 Node 서버에서 PostgreSQL에 말을 걸 차례예요. 공식에 가까운 드라이버인{' '} + pg 패키지를 쓰는데, 시작부터 습관 하나를 제대로 + 들입시다 — 연결은 커넥션 풀(Pool)로. +
+{CODE_POOL}
+ + DB 연결 한 번에는 TCP 접속과 인증이라는 비용이 들어요. 요청이 올 때마다 새로 + 연결하면 그 비용을 매번 치르고, DB 쪽도 연결 수가 폭증해 버팁니다. 풀은{' '} + 연결 몇 개를 미리 만들어 두고 빌려 줬다 돌려받는 구조라, 요청이 + 아무리 많아도 연결 수는 일정하게 유지돼요. +
++ 그리고 이 코스에서 가장 중요한 보안 습관이 나옵니다. SQL에 사용자 + 입력을 넣을 땐 반드시 파라미터 바인딩($1,{' '} + $2…)을 쓰세요. 문자열을 이어붙여 SQL을 만드는 + 순간, 사용자가 내 SQL 문장을 대신 쓰게 됩니다. +
+{CODE_INJECTION}
+ + 준비가 끝났으니 본격 이사입니다. 배열 시절의{' '} + push · find ·{' '} + splice를 각각{' '} + INSERT · SELECT ·{' '} + UPDATE/DELETE로 + 번역해요. 라우터의 겉모양(URL·상태코드)은 그대로 두고 속만 갈아 + 끼우는 게 포인트 — API를 쓰는 쪽에서는 이사한 걸 눈치채지 못해야 합니다. +
+{CODE_CRUD}
+ + 새로 익힐 무기가 둘 있어요. 첫째, INSERT ... + RETURNING * — 방금 만든 행을 (DB가 채워 준{' '} + id·created_at까지 포함해) + 그 자리에서 돌려받습니다. INSERT 후 다시 SELECT할 필요가 없죠. 둘째,{' '} + rowCount — 쿼리가 실제로 영향을 준 + 행의 수예요. UPDATE·DELETE에서 이 값이 0이면 "그런 + id의 글은 없었다"는 뜻이니, 그대로 404로 응답하면 됩니다. 배열 + 시절의 find()가{' '} + undefined를 돌려주던 것과 같은 역할이에요. +
++ 블로그 목록 화면을 떠올려 보세요. 글 제목 옆에 작성자 이름이 있고, + 아래엔 댓글 수가 붙죠. 그런데 우리 테이블에서 이름은{' '} + users에, 댓글은 comments에 + 살아요. 흩어진 데이터를 FK를 따라 이어 붙이는 도구가{' '} + JOIN입니다. +
+{CODE_JOIN}
+ + INNER JOIN은 "p.author_id가 가리키는{' '} + users 행을 찾아 옆에 붙여라"예요. 섹션 2에서 심어 둔 + 연결고리(FK)가 여기서 길이 됩니다. 댓글 수는{' '} + LEFT JOIN + GROUP BY 조합 — 글마다 매달린 댓글들을 글 단위로 + 접어서(GROUP BY p.id){' '} + COUNT로 셉니다. 댓글이 0개인 글도 목록에는 나와야 + 하니, 짝이 없어도 행을 남겨 주는 LEFT JOIN을 쓴다는 점도 눈여겨 + 두세요(INNER였다면 댓글 없는 글이 목록에서 사라집니다). +
++ JOIN을 모르면 자연스럽게 이런 코드를 쓰게 돼요 — "글 목록을 가져온 다음, 글마다 + 작성자를 또 조회". 이것이 악명 높은 N+1 쿼리 문제입니다. +
+{CODE_N_PLUS_ONE}
+ + 이 코스의 심장부입니다. 질문 하나로 시작할게요 — 계좌이체는 DB + 입장에서 무엇일까요? "A에서 빼는 UPDATE"와 "B에 더하는 UPDATE",{' '} + 두 번의 쓰기예요. 그런데 첫 번째만 실행된 순간 서버가 죽는다면? +
+{CODE_TRANSFER}
+ + 이런 "여러 개의 쓰기가 반드시 한 덩어리여야 하는" 상황을 위해 DB가 주는 도구가{' '} + 트랜잭션입니다. BEGIN으로 묶음을 + 열고, 그 안의 변경은 연필로 쓴 초안 상태로 쌓이다가,{' '} + COMMIT에서 한꺼번에 확정돼요. 중간에 무엇이든 + 잘못되면 ROLLBACK — BEGIN{' '} + 이후의 모든 변경이 통째로 없던 일이 됩니다. 절반만 반영된 어정쩡한 + 상태는 존재할 수 없어요. 그래서 all-or-nothing. +
++ 우리 블로그에도 똑같은 구조가 있어요 — 실습 과제인 "댓글 작성 + 글의 + 댓글수(comment_count) 갱신". 댓글 INSERT만 + 되고 댓글수 UPDATE가 실패하면, 화면엔 "댓글 3개"라는데 실제론 4개가 달린 이상한 + 글이 됩니다. 묶읍시다. +
+{CODE_TX_PRACTICE}
+ + 트랜잭션은 성공 경로만 봐서는 절대 체득되지 않아요. 일부러 부수는 것이 + 이번 섹션의 실습입니다. 두 가지를 눈으로 확인해 봅시다. +
+{CODE_ROLLBACK_TEST}
+ + 실습 ①은 INSERT 다음에 고의로 에러를 던져{' '} + COMMIT에 도달하지 못하게 하는 거예요. catch에서{' '} + ROLLBACK이 돌고 나면, 분명 INSERT가 실행됐는데도 + 테이블엔 아무 흔적이 없습니다. 실습 ②는 psql 터미널을{' '} + 두 개 열고, 한쪽에서 BEGIN 후 + INSERT만 한 상태로 다른 쪽에서 조회해 보는 것. 커밋 전엔 안 보이고, + 커밋하는 순간 보입니다. 각 트랜잭션이 서로의 미완성 작업을 보지 못하게 하는 이 + 성질이 격리(isolation)예요 — 깊은 격리 수준 이야기는 다음 기회에 + 다루고, 오늘은 "커밋 전의 변경은 남에게 없는 것"이라는 감각만 가져가면 충분합니다. +
++ 마지막으로 실무 감각 하나. 트랜잭션 안에서 외부 API를 호출하면 안 + 됩니다. 이유는 두 겹이에요. 첫째, 트랜잭션이 열려 있는 동안 그 연결(그리고 + DB가 잡은 잠금)은 계속 점유되는데, 외부 API가 3초 걸리면 그 3초 + 내내 다른 요청들이 줄을 서요. 느린 외부 호출 하나가 풀 전체를 말려 버릴 수 있습니다. + 둘째, DB는 롤백이 되지만 외부 세계는 롤백이 안 돼요. 트랜잭션 + 안에서 알림 메일을 보냈는데 그 뒤 롤백되면? 댓글은 없던 일이 됐는데 메일은 이미 + 날아갔죠. 그래서 원칙은 — 트랜잭션은 DB 작업만으로 짧게 닫고, 외부 호출은 + 커밋이 확정된 다음에. +
++ 이제 우리 블로그의 데이터는 서버를 껐다 켜도 살아남는 진짜 집에 + 삽니다. 테이블과 관계(PK·FK), 커넥션 풀과 $1 바인딩, RETURNING과 + rowCount, JOIN과 N+1, 그리고 all-or-nothing 트랜잭션까지 — + "돌아가는 API"를 "믿을 수 있는 API"로 끌어올리는 재료를 손에 쥐었어요. 그런데 + 데이터가 영원히 남는 순간, 새 질문이 따라옵니다. "이 요청을 보낸 사람이 + 누구인지"는 어떻게 믿죠? 비밀번호는 DB에 어떻게 저장해야 유출돼도 + 안전할까요? 다음{' '} + 로그인 구현: 세션과 비밀번호 + 해시 코스에서, 이 집에 잠금장치를 달아 봅시다. +
+글 목록을 불러오지 못했어요.
+ +{children}+ 에러는 없앨 수 없어요. 다스릴 뿐입니다. 네트워크는 끊기고, 사용자는 + 예상 밖의 값을 넣고, DB는 가끔 응답이 늦죠. 좋은 서비스의 기준은 "에러가 나느냐"가 + 아니라 에러가 났을 때의 표정이에요. 백엔드의 에러 미들웨어부터 + 프론트의 '다시 시도' 폴백 UI까지, 실패의 순간에도 품위를 지키는 설계를 한 바퀴 + 돌아봅니다. +
++ 모든 에러 처리는 이 구분에서 출발해요. 예상된 실패는 코드가 멀쩡해도 + 일어나는 일이에요. 없는 글 번호로 조회하거나 제목 없이 글을 올리려 하는 것 — 서비스가 + 살아 있는 한 매일 일어나는 정상적인 사건이죠. 반면{' '} + 버그는 코드가 잘못돼서 일어나면 안 되는 게 일어난 거예요.{' '} + undefined.title을 읽는 순간 같은 거요. +
+{CODE_TWO_KINDS}
+ + 왜 나눠야 할까요? 처방이 정반대이기 때문이에요. 예상된 실패는 + 사용자에게 "제목을 입력해 주세요"라고 설명하면 끝나지만, 버그는 + 사용자가 할 수 있는 게 없어요 — 로그에 남겨 개발자에게 보고해야 하죠. + 그리고 두 종류 모두에게 통하는 단 하나의 금기가 있습니다. 에러를{' '} + 삼키는 것이에요. +
+{CODE_SWALLOW}
+ + 자바스크립트 에러 처리에서 가장 흔한 사고 지점이 여기예요.{' '} + try/catch로 감쌌는데도 에러가 잡히지 않고 콘솔에{' '} + Unhandled promise rejection이 뜬다면, 십중팔구{' '} + await를 빼먹은 것입니다. +
+{CODE_ASYNC_LEAK}
+ + try/catch는 지금 이 자리에서 터진 에러만{' '} + 잡아요. await가 없으면 함수는 Promise의 결과를 기다리지 + 않고 지나가 버리고, 실패는 try 블록이 이미 끝난 뒤 — + catch의 손이 닿지 않는 곳에서 — 터집니다. await는 + "결과(성공이든 에러든)를 이 자리로 끌어와라"는 뜻이에요. +
+{CODE_ASYNC_RIGHT}
+ + catch 안에서의 판단 기준은 딱 하나입니다.{' '} + "여기서 이 에러를 해결할 수 있는가?" 해결할 수 있으면(빈 목록으로 + 대체, 재시도) 처리하고, 없으면 다시 던져서 해결할 수 있는 곳까지 올려 + 보내세요. 스피너 끄기, 연결 닫기 같은 정리 작업은{' '} + finally에 두면 성공·실패 어느 쪽이든 반드시 실행됩니다. +
++ throw new Error('없음') 같은 맨몸 에러의 문제는, 받는 + 쪽이 이게 어떤 종류의 실패인지 알 길이 없다는 거예요. 404를 줘야 할지 + 400을 줘야 할지, message 문자열을 사람이 읽고 추측하는 수밖에 없죠. 그래서 에러에{' '} + 이름표(클래스)와 상태코드를 실어 나르는 설계가 나옵니다. +
+{CODE_CUSTOM_ERRORS}
+ + 핵심은 세 가지예요. ① 클래스명이 곧 에러의 종류가 되고,{' '} + ② statusCode를 에러 객체에 실어 두면 + "이 에러엔 몇 번 응답"이라는 지식이 던지는 쪽에 한 번만 적히며,{' '} + ③ isExpected 표식으로 "예상된 + 실패"(섹션 1)임을 알립니다 — 이 표식이 없는 에러는 전부 버그로 취급하면 돼요. +
+{CODE_CUSTOM_USE}
+ + 라우트가 10개면 try/catch도 10벌 — 그렇게 짜면 응답 모양이 조금씩 달라지고, 하나쯤은 + 꼭 빠뜨리게 돼요. Express의 답은 에러 미들웨어입니다. 인자를{' '} + 4개(err, req, res, next) 받는 미들웨어를 + 등록하면, Express는 그걸 "에러 담당"으로 인식하고 어디서 터진 에러든 전부 + 그리로 배달해 줘요. +
+{CODE_MIDDLEWARE}
+ + 그런데 여기 유명한 함정이 하나 있어요. 동기 라우트에서 던진 에러는 + Express가 알아서 받아 주지만, async 라우트 안에서 터진 에러는 Express + 4가 받지 못합니다(Promise 거절을 감지하지 못해요). 그래서 async 핸들러를 감싸{' '} + next(err)로 배달해 주는 래퍼 패턴이 + 실무의 표준이 됐죠. +
+{CODE_ASYNC_WRAP}
+ + 에러가 미들웨어 한 곳으로 모였으니, 이제 나가는 모양을 통일할 + 차례예요. API마다 실패 응답이 제각각이면(어떤 건 문자열, 어떤 건{' '} + msg, 어떤 건 error...) + 프론트는 API 개수만큼 에러 처리 코드를 짜야 합니다. 규약은 단순할수록 좋아요:{' '} + code + message. +
+{CODE_FORMAT}
+ + code는 기계가 읽는 이름표라 절대 바뀌면 + 안 되고(프론트 분기가 여기 걸려 있어요), message는{' '} + 사람이 읽는 문장이라 자유롭게 다듬어도 됩니다. 이 역할 분리가 없으면 + "메시지 문구 하나 고쳤더니 프론트 분기가 깨지는" 사고가 나요. +
+{CODE_FORMAT_MIDDLEWARE}
+ + 백엔드가 아무리 잘해도 프론트에서 렌더링 중 에러가 나면 React는 기본적으로{' '} + 화면 전체를 비워 버려요 — 사용자 눈엔 하얀 화면만 남죠. 이걸 막는 + 안전망이 에러 바운더리(Error Boundary)입니다. 자식 컴포넌트가 렌더링 + 중에 던진 에러를 받아 내고, 무너진 자리에 대체 화면(폴백)을 세우는 + 컴포넌트예요. +
+{CODE_BOUNDARY}
+ + 설계의 핵심은 어디에 두르느냐예요. 앱 전체를 하나로 감싸면 "전부 + 죽거나 전부 살거나"가 되죠. 대신 글 목록, 댓글, 사이드바처럼 영역 단위로{' '} + 두르면 한 영역이 터져도 나머지는 멀쩡히 삽니다 — 배가 침수돼도 격벽 한 칸만 잠기는 + 것처럼요. +
++ 중요한 구분 하나: 에러 바운더리는 렌더링 중의 에러를 잡는 도구라,{' '} + fetch 실패 같은 요청 에러는 잡지 + 못합니다(이벤트 핸들러·비동기 코드는 범위 밖이에요). 요청 실패에는 상태 + 기반의 폴백 — '다시 시도' 버튼이 있는 에러 화면 — 을 직접 만듭니다. +
+{CODE_RETRY}
+ + 지금까지의 원칙을 한 줄로 줄이면 이래요 — 사용자에겐 친절한 요약, 로그엔 + 냉정한 전부. 그럼 로그는 어떻게 남겨야 나중에 쓸모가 있을까요? 첫걸음은{' '} + console.log 하나로 버티던 습관에서{' '} + 레벨(level)이 있는 로깅으로 넘어가는 것입니다. +
+{CODE_LOGGING}
+ + info는 정상 흐름의 발자국,{' '} + warn은 "아직 장애는 아니지만 눈여겨볼 것",{' '} + error는 "지금 살펴야 할 문제"예요. 레벨이 있어야 운영 + 중에 "error만 보여 줘"라고 걸러 볼 수 있고, 심각한 것만 알림으로 받는 + 자동화도 걸 수 있습니다. 두 번째 기둥은 요청 ID예요. 서버엔 수많은 + 요청이 섞여 들어오는데, 로그 줄들이 어느 요청의 것인지 묶어 주는 실이 + 없으면 에러 한 건의 앞뒤 맥락을 복원할 수 없거든요. +
+{CODE_REQUEST_ID}
+ + 이제 에러는 두렵기만 한 대상이 아니라 설계할 수 있는 대상이 됐어요. + 예상된 실패와 버그를 가르고, 커스텀 에러 클래스에 상태코드를 실어, 미들웨어 한 곳에서{' '} + code/message로 통일해 내보내고, 프론트에선 영역 단위 + 폴백과 '다시 시도'로 받아 내는 흐름 — 그리고 그 전 과정을 요청 ID로 추적하는 로깅까지. + 그런데 이렇게 다듬은 에러 처리가 정말 약속대로 동작하는지는 어떻게 + 보장할까요? 손으로 매번 눌러 볼 수는 없잖아요. 다음{' '} + 테스트 작성 실전: 자신 있게 고치는 + 힘 강좌에서, 오늘 만든 에러 응답과 폴백이 깨지면 기계가 먼저 + 알려 주는 안전망을 이어서 만들어 봅시다. +
+{children}+ 3강에서 우리는 블로그 API의 명세를 종이 위에 설계했어요. 이번엔 그 + 설계도를 진짜 돌아가는 서버로 옮깁니다. 요청이 서버를 통과하는 원리부터 + 라우터·미들웨어·계층 분리까지 — 생성(C)·조회(R)·수정(U)·삭제(D) 전 구간을 내 손으로 + 구현하고, Postman 시나리오로 끝까지 검증해 봅시다. +
++ 코드를 치기 전에, 요청 하나가 서버 안에서 어떤 길을 걷는지부터 + 그려 봅시다. 브라우저나 Postman이 GET /posts/3을 보내면, + Express는 그 요청을 ① 미들웨어 → ② 라우터 → ③ 핸들러 → ④ 응답의 + 한 줄로 통과시켜요. 이 지도 한 장이 이번 코스 전체의 뼈대입니다. +
+{CODE_JOURNEY}
+ + 미들웨어(middleware)는 요청이 핸들러에 닿기 전에 거치는{' '} + 검문소예요. 공항 보안 검색대를 떠올리면 정확합니다 — 모든 승객(요청)이 + 차례로 통과하면서 짐 검사(body 파싱), 기록(로깅), 신분 확인(인증) 같은 공통 절차를 + 거치죠. 검문을 통과시키는 신호가 next()인데, 이건 섹션 + 6에서 직접 만들어 보며 손에 익힙니다. +
++ 포트와 localhost도 정확히 해 둘게요. 한 컴퓨터에는 여러 프로그램이 동시에 + 네트워크를 쓰기 때문에, 프로그램마다 문 번호(포트)를 하나씩 배정받아요. + 우리 서버가 3000번 문 앞에서 기다리겠다고 선언하는 게{' '} + app.listen(3000)이고,{' '} + localhost는 "다른 컴퓨터가 아니라 내 컴퓨터 + 자신"을 가리키는 특별한 이름입니다. +
++ 서버 하나 띄우는 데 필요한 건 생각보다 적어요. npm init -y + 로 프로젝트 신분증(package.json)을 만들고, Express를 + 설치하고, 파일 하나에 열 줄 남짓 — 이게 전부입니다. 데이터베이스는 아직 없어요. 이번 + 실습에선 메모리 배열이 임시 DB 역할을 합니다. +
+{CODE_SETUP}
+ + node server.js로 켜고 브라우저에서{' '} + http://localhost:3000/posts를 열면 글 두 개가 담긴 JSON + 배열이 보일 거예요. 축하합니다 — 방금 여러분의 첫 API 서버가 응답한 + 겁니다. res.json()은 자바스크립트 배열·객체를 JSON + 문자열로 바꾸고, "이건 JSON이야"라는 안내(Content-Type 헤더)까지 붙여서 보내 줘요. +
++ 그런데 코드를 고칠 때마다 서버를 껐다 켜는 건 금방 지칩니다.{' '} + nodemon을 붙여 "저장하면 자동 재시작"되는 개발 흐름을 만들어 두세요. +
+{CODE_NODEMON}
+ + 이제 클라이언트가 보낸 데이터로 새 글을 만들어 봅시다. POST 요청의 + 데이터는 주소가 아니라 본문(body)에 실려 오는데, Express는 기본적으로 + body를 읽지 않아요. app.use(express.json())이라는 + 검문소를 세워야 JSON 본문이 req.body 객체로 풀립니다. +
+{CODE_POST}
+ + 여기서 상태 코드 두 개가 일하고 있어요. 성공하면 201 Created — + "만들어졌다"를 뜻하는 전용 코드로, 200보다 정확한 표현입니다. 이때{' '} + 생성된 리소스를 응답 본문에 담아 돌려주는 게 관례예요. 서버가 붙여 준{' '} + id를 클라이언트가 알아야 다음 요청(상세 조회, 수정)을 + 이어 갈 수 있으니까요. +
++ 그리고 400 Bad Request — 필수 필드가 빠진 요청은 배열에 넣기 전에 + 거절합니다. 클라이언트가 보낸 데이터는 절대 믿지 않는다가 서버 개발의 + 기본 자세예요. 검증 없이 저장하면 title: undefined인 + 유령 글이 쌓이고, 나중에 목록 화면이 깨지고 나서야 원인을 찾게 됩니다. +
++ 목록은 있으니 이제 하나만 콕 집어 꺼내 봅시다. 주소의{' '} + /posts/:id에서 :id는{' '} + 경로 파라미터 — "이 자리에 오는 값은 뭐든 받아서{' '} + req.params.id에 담아 줘"라는 자리표시자예요. +
+{CODE_GET_DETAIL}
+ + 두 가지 함정이 숨어 있어요. 첫째, URL에서 온 값은 전부 문자열입니다.{' '} + '3' === 3은 false라서, Number() + 변환 없이 비교하면 멀쩡한 글도 못 찾아요. 둘째, 없는 id에는 반드시 404 + 를 보냅니다. 200에 빈 응답을 주면 클라이언트는 "성공했는데 데이터가 이상하네?"라며 + 엉뚱한 곳을 뒤지게 돼요. 상태 코드는 서버가 클라이언트에게 하는 정직한 + 말입니다. +
++ 목록 쪽엔 쿼리스트링을 붙였어요. ?q=Express&page=1 + 처럼 주소 뒤에 붙는 옵션들은 req.query로 들어옵니다. + 경로 파라미터가 "어떤 리소스냐"를 정한다면, 쿼리스트링은 "그 목록을{' '} + 어떻게 보여 줄 거냐"(검색·정렬·페이지)를 정해요 — 3강에서 설계한 그 + 구분이 코드로 그대로 내려온 겁니다. +
++ 수정에는 두 가지 철학이 있어요. PUT은 "통째로 교체"(안 보낸 필드는 + 사라짐), PATCH는 "보낸 필드만 고침". 블로그에서 + 제목만 살짝 바꾸는 시나리오라면 PATCH가 자연스럽죠. 핵심은{' '} + undefined 체크 — "이 필드가 요청에 실려 왔는가"를 + 확인하고 온 것만 반영하는 로직입니다. +
+{CODE_PATCH_DELETE}
+ + 삭제 성공의 응답은 204 No Content입니다. "잘 처리했고, 돌려줄 내용은 + 없다"는 뜻이에요. 이미 지워진 걸 다시 보여 줄 이유가 없으니 본문 없이 상태 코드만 + 보내는 거죠. 그래서 res.json()이 아니라{' '} + res.status(204).end()를 씁니다. +
++ 그리고 설계자가 방침을 정해야 하는 순간이 하나 있어요 — 이미 없는 + 리소스를 지우라는 요청이 오면? "없다"는 사실을 알리는 404파와, "지워진 + 상태가 목표였으니 결과는 같다"며 204를 주는 파가 실무에도 둘 다 + 있습니다. 우리는 클라이언트의 버그(잘못된 id 사용)를 일찍 드러내 주는 404를 택했어요. + 어느 쪽이든 일관되게 정하고 명세에 적어 두는 것이 정답입니다. +
++ 지금까지 express.json()이라는 남이 만든 검문소를 + 썼다면, 이제 직접 만들어 봅시다. 미들웨어는 그냥{' '} + (req, res, next) 세 개를 받는 함수예요. 첫 작품은 모든 + 요청을 기록하는 로거입니다. +
+{CODE_LOGGER}
+ + next()가 이 구조의 심장이에요. "내 검문은 끝났으니{' '} + 다음 순번에게 넘겨라"는 신호죠. 이걸 부르지 않으면 요청은 그 검문소에 + 갇혀서 응답 없이 멈춥니다. 그리고 등록 순서가 곧 실행 순서 —{' '} + app.use(logger)를 라우트들보다 아래에 두면, 이미 핸들러가 + 응답해 버린 뒤라 로거는 구경도 못 해요. +
++ 두 번째 작품은 더 실전적이에요. 섹션 4~5에서 상세·수정·삭제 핸들러마다{' '} + find + 404 코드가 세 번 복붙됐던 것, + 눈치챘나요? 그 반복을 미들웨어 하나로 추출합니다. +
+{CODE_EXISTS_MW}
+ + "브라우저 주소창에 치면 되지 않나요?" — 절반만 맞아요. 주소창에 URL을 입력하는 행위는{' '} + 언제나 GET 요청입니다. 메서드를 바꿀 수도, JSON 본문을 실을 수도, + 헤더를 만질 수도 없죠. 우리가 만든 POST·PATCH·DELETE는 주소창으로는{' '} + 테스트 자체가 불가능합니다. 그래서 API 전용 도구가 필요해요. +
++ Postman은 메서드·헤더·본문을 자유롭게 조립해 쏘는 대표 도구고, VS Code의{' '} + REST Client 확장은 .http 파일에 요청을 + 적어 두고 에디터 안에서 바로 실행하는 방식이에요. 어느 쪽이든 핵심은 같습니다 —{' '} + 요청을 일회용으로 쏘고 버리지 말고, 시나리오로 저장하세요. +
+{CODE_HTTP_FILE}
+ + 이렇게 저장해 두면 코드를 고칠 때마다 전 구간을 몇 초 만에 재검증할 + 수 있어요. 특히 3번·4번 같은 실패 케이스(400·404가 제대로 나오는가)를 + 시나리오에 남겨 두는 게 중요합니다 — 성공만 확인한 API는 절반만 검증된 API예요.{' '} + .http 파일은 코드와 함께 저장소에 커밋되니, 팀 동료에게 + "이 API는 이렇게 쓰는 거예요"라는 살아 있는 문서가 되기도 하고요. +
++ 지금 우리 server.js엔 서버 설정, 데이터, 라우트 8개가 + 한 파일에 살아요. 혼자 할 땐 괜찮지만, 글·댓글·사용자로 기능이 늘고 동료가 합류하는 + 순간 모두가 한 파일을 고치며 충돌하게 됩니다. Express가 준비해 둔 + 해법이 express.Router — 라우트 묶음을 별도 파일로 떼어 + 내는 도구예요. +
+{CODE_ROUTER}
+ + 한 걸음 더 나아가 계층 분리도 맛봤어요. 라우터는 + 입출구 — 주소를 받고 상태 코드로 답하는 HTTP 담당. 서비스는 비즈니스 + 로직 — 검증하고, 만들고, 찾는 실제 일 담당. 이렇게 나누면 나중에 메모리 배열을 DB로 + 바꿀 때 서비스 파일만 고치면 되고, 라우터는 한 줄도 안 건드려요. + 역할이 나뉘어 있으면 교체도 국소적입니다. +
++ 폴더 구조는 곧 팀의 지도예요. "댓글 API 담당해 주세요"라는 요청이{' '} + routes/comments.js와{' '} + services/commentService.js 두 파일로 명확히 번역되고, + 서로 다른 기능을 맡은 동료와 같은 파일에서 충돌할 일이 사라집니다. 잘 나눈 구조는 + 코드 정리를 넘어 협업의 속도를 바꿔요. +
++ 종이 위의 명세가 돌아가는 서버가 됐어요. 요청의 여정을 그릴 수 있고, + CRUD 네 동사를 상태 코드(200·201·204·400·404)와 함께 구현했고, 반복 로직을 + 미들웨어로 추출했고, 실패 케이스까지 시나리오로 검증하는 습관과 라우터·서비스 계층까지 + 손에 쥐었습니다. 그런데 찜찜함이 하나 남았죠 — 서버를 재시작하면 글이 다 + 사라진다는 것. 데이터에게 서버의 삶과 무관한 '집'을 지어 줄 차례예요. 다음{' '} + DB 연동과 트랜잭션: 데이터가 사는 + 집 강좌에서, 메모리 배열을 진짜 데이터베이스로 옮기고 "전부 성공 + 아니면 전부 취소"라는 트랜잭션의 감각을 이어서 익혀 봅시다. +
+