Press n or j to go to the next uncovered block, b, p or k for the previous block.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 | // 이 파일이 하는 일: 개발 용어 사전의 '데이터'. 강좌 7개 카테고리에서 나오는 용어 98개를 // 초보 눈높이로 정의했다. 화면(GlossaryPage)은 이 배열을 검색·표시만 한다. // 학습 포인트: 데이터와 화면을 나누면, 용어를 추가할 때 여기 한 줄만 넣으면 된다. export const GLOSSARY_CATEGORIES = ["컴퓨터 기초", "네트워크", "서버와 데이터", "소프트웨어", "디자인", "앱 개발", "도구·보안"]; export const GLOSSARY = [ { term: `CPU (중앙처리장치)`, category: `컴퓨터 기초`, short: `컴퓨터의 두뇌`, desc: `메모리에서 명령어를 가져와(Fetch) 해석하고(Decode) 실행하는(Execute) 명령어 사이클을 1초에 수십억 번 반복하는 핵심 부품이에요. 코어·스레드·클럭 같은 스펙이 모두 이 CPU의 성능을 나타냅니다. 우리 플랫폼을 빌드(npm run build)하거나 서버가 요청을 처리할 때 실제로 일하는 게 CPU예요.` }, { term: `GPU (그래픽처리장치)`, category: `컴퓨터 기초`, short: `화면·대량계산 전담 일꾼`, desc: `화면에 픽셀을 그리려고 단순한 계산을 동시에 수천 개씩 처리하도록 만든 칩이에요. 이 '한꺼번에 많이' 특성 덕분에 게임 그래픽뿐 아니라 AI 학습·추론에도 필수라, AI 시대에 값이 크게 뛰었습니다. CPU가 소수의 복잡한 일을 잘한다면, GPU는 똑같은 계산을 대량으로 밀어붙이는 데 강해요.` }, { term: `RAM (메모리)`, category: `컴퓨터 기초`, short: `지금 작업 중인 책상`, desc: `CPU가 당장 쓰는 데이터를 잠시 올려 두는 빠른 작업 공간으로, 전원이 꺼지면 내용이 전부 사라지는 '휘발성'이에요. 용량이 크다고 속도가 빨라지는 게 아니라 동시에 펼쳐 둘 수 있는 작업이 많아집니다. IDE·브라우저·Docker를 함께 띄우는 개발 환경에선 16GB 이상이 현실적인 최소선이에요.` }, { term: `스토리지 (Storage · SSD·HDD)`, category: `컴퓨터 기초`, short: `전원 꺼져도 남는 책장`, desc: `파일·프로그램을 영구 보관하는 저장장치로, 전원이 꺼져도 내용이 남는 '비휘발성'이라 RAM과 정반대예요. 요즘은 빠른 SSD(특히 NVMe)가 표준이고, 느린 HDD는 대용량 보관용으로 남았습니다. 프로그램을 실행하면 스토리지(책장)에서 꺼내 RAM(책상)에 펼치는 흐름을 알면 컴퓨터가 느려지는 이유도 보여요.` }, { term: `캐시 (Cache)`, category: `컴퓨터 기초`, short: `CPU 손 닿는 곳의 재료 선반`, desc: `자주 쓰는 데이터를 CPU 바로 옆에 미리 올려 둬서 느린 RAM까지 매번 다녀오지 않게 하는 초고속 임시 저장 공간이에요. CPU 안에 L1·L2·L3 세 층으로 있고, 가까울수록 작고 빠릅니다. 원하는 데이터가 캐시에 있으면(캐시 히트) 빠르고, 없어서 RAM까지 가면(캐시 미스) 수십 배 느려져요.` }, { term: `메인보드 (Mainboard · 마더보드)`, category: `컴퓨터 기초`, short: `부품을 잇는 도로망`, desc: `CPU·RAM·그래픽카드·저장장치·주변기기가 전부 꽂혀 서로 데이터를 주고받는 커다란 기판이에요. 부품들의 '도로망'이자 만남의 장소라, 어떤 CPU·RAM을 꽂을 수 있는지가 이 메인보드 규격으로 정해집니다. 데스크탑을 조립할 때 부품 호환성의 기준이 되는 판이에요.` }, { term: `2진수 (Binary · 이진수)`, category: `컴퓨터 기초`, short: `0과 1 두 개로 세는 셈법`, desc: `전기 스위치의 켜짐(1)·꺼짐(0) 두 상태만으로 모든 수를 표현하는 방식으로, 상태가 둘뿐이라 전압이 흔들려도 헷갈리지 않아 컴퓨터의 기본 언어가 됐어요. 숫자뿐 아니라 문자·색·이미지·소리까지 결국 0과 1의 나열로 저장됩니다. 각 자리값(1,2,4,8…)을 더하면 10진수로 바꿀 수 있어요.` }, { term: `비트·바이트 (Bit·Byte)`, category: `컴퓨터 기초`, short: `데이터 크기의 기본 단위`, desc: `비트(bit)는 0 또는 1 한 개, 바이트(Byte)는 비트 8개 묶음으로 영어 한 글자 크기예요. 8비트면 2의 8제곱인 256가지를 표현할 수 있고, KB·MB·GB·TB는 여기에 1,024배씩 곱해 커집니다. 파일 크기·RAM 용량·네트워크 속도가 전부 이 단위로 표시돼요.` }, { term: `운영체제 (OS · Operating System)`, category: `컴퓨터 기초`, short: `하드웨어를 총괄하는 매니저`, desc: `CPU·메모리·디스크 같은 자원을 앱들에 나눠 주고 프로세스·파일·보안 권한을 관리하는, 컴퓨터의 총괄 소프트웨어예요. Windows·macOS는 사람이 쓰기 편하게, Linux는 서버에서 24시간 안정적으로 도는 데 강합니다. 우리 개발 PC는 대개 Windows, AWS EC2 서버는 전부 Linux를 써요.` }, { term: `프로세스 (Process)`, category: `컴퓨터 기초`, short: `지금 실행 중인 프로그램`, desc: `디스크에 저장된 프로그램(레시피)을 실제로 실행해 CPU와 메모리를 쓰며 살아 움직이는 상태를 프로세스(요리 중인 냄비)라고 해요. 크롬 창 하나에도 프로세스가 여러 개 뜨고, OS는 이들을 아주 잘게 번갈아 실행(문맥 교환)해 동시에 도는 것처럼 보이게 합니다. 작업 관리자의 '프로세스' 탭에서 직접 볼 수 있어요.` }, { term: `컴파일 (Compile)`, category: `컴퓨터 기초`, short: `코드를 기계가 읽게 번역`, desc: `사람이 읽고 쓰는 소스 코드를, 컴퓨터가 실행할 수 있는 저수준 형태(기계어나 바이트코드 등)로 번역하는 과정이에요. CPU는 우리가 쓴 Java·JavaScript를 그대로 못 읽어서 실행 전에 이 번역이 필요합니다. npm run build나 ./mvnw package처럼 코드를 실행 파일로 '빌드'할 때 컴파일이 핵심 단계라, 파일이 많을수록 CPU를 크게 써요.` }, { term: `파일시스템 (File System)`, category: `컴퓨터 기초`, short: `디스크에 붙인 정리 장부`, desc: `그냥 0과 1의 바다인 디스크 위에, 어떤 데이터가 어디서 어디까지인지 기록한 '장부'를 얹어 우리가 파일과 폴더로 다루게 해 주는 규칙이에요. Windows는 NTFS, USB·SD카드는 exFAT, 리눅스 서버는 ext4를 주로 씁니다. 파일 이름·크기·위치 같은 메타데이터를 이 파일시스템이 관리해요.` }, { term: `확장자 (File Extension)`, category: `컴퓨터 기초`, short: `파일 뒤에 붙는 이름표`, desc: `파일 이름 끝의 .jpg·.docx 같은 꼬리표로, 어떤 프로그램으로 열지 OS에 알려 주는 '이름표'일 뿐 내용물 자체는 아니에요. 진짜 파일 종류는 맨 앞 몇 바이트(매직 넘버)로 정해지므로, 확장자만 바꾼다고 내용이 바뀌지는 않습니다. 그래서 photo.jpg를 photo.txt로 바꿔도 데이터는 그대로예요.` }, { term: `경로 (Path)`, category: `컴퓨터 기초`, short: `파일까지 찾아가는 주소`, desc: `파일이나 폴더의 위치를 나타내는 주소로, 뿌리(루트)부터 전체를 적는 절대경로와 지금 위치 기준으로 적는 상대경로가 있어요. 리눅스는 /로, Windows는 C:\\로 시작하는 차이가 있습니다. React에서 매일 쓰는 import App from '../App'의 '../'가 바로 '부모 폴더'를 가리키는 상대경로예요.` }, { term: `IP 주소 (IP address)`, category: `네트워크`, short: `인터넷상의 '집 주소'`, desc: `네트워크에 연결된 모든 기기에 붙는 고유 번호로, 데이터가 어디로 가야 할지 정하는 기준이다. 192.168.x.x 같은 사설 IP는 집·회사 내부용이고, 공인 IP는 인터넷 바깥에서 찾을 수 있는 주소다. 우리 학습 플랫폼도 AWS EC2 서버의 IP 위에서 돌아간다.` }, { term: `DNS`, category: `네트워크`, short: `도메인↔IP 전화번호부`, desc: `edu.awesomedevapp.com 같은 외우기 쉬운 이름을 컴퓨터가 쓰는 숫자 IP 주소로 바꿔 주는 시스템이다. 브라우저는 주소를 입력받으면 먼저 DNS에 '이 이름의 IP가 뭐야?'라고 물어본 뒤에야 접속한다. DNS가 없으면 우리는 사이트마다 숫자 IP를 전부 외워야 한다.` }, { term: `HTTP`, category: `네트워크`, short: `브라우저↔서버 대화 규칙`, desc: `웹에서 브라우저(클라이언트)와 서버가 주고받는 요청·응답의 약속된 양식이다. GET(조회)·POST(생성) 같은 메서드로 '무엇을 하고 싶은지'를 밝히고, 서버는 그 결과를 응답으로 돌려준다. 우리 플랫폼의 /api/courses 호출도 전부 이 HTTP 요청이다.` }, { term: `HTTPS / TLS`, category: `네트워크`, short: `암호로 봉인한 HTTP`, desc: `HTTP 통신을 TLS라는 암호 기술로 감싸, 중간에서 누구도 내용을 엿볼 수 없게 만든 것이다. 주소창의 자물쇠(🔒)가 켜져 있으면 아이디·비밀번호가 봉투 속에서 오간다는 뜻이라, 공용 와이파이에서 특히 중요하다. 우리 플랫폼은 Caddy가 인증서를 받아 자동으로 HTTPS를 걸어 준다.` }, { term: `TCP`, category: `네트워크`, short: `확실한 택배`, desc: `데이터를 빠짐없이, 순서대로 전달하는 것을 보장하는 통신 방식이다. 연결을 먼저 맺고(3-way 핸드셰이크) 잃어버린 조각은 다시 보내기 때문에, 파일·로그인·메시지처럼 한 바이트도 틀리면 안 되는 데이터에 쓴다. 우리 플랫폼의 웹·DB 통신은 전부 TCP 위에서 오간다.` }, { term: `UDP`, category: `네트워크`, short: `빠른 확성기 방송`, desc: `확인·재전송 같은 절차를 생략하고 데이터를 그냥 빠르게 내보내는 통신 방식이다. 몇 개 유실돼도 '최신 정보'가 더 중요한 실시간 영상·게임·음성통화에 어울린다. 정확함보다 속도를 고른 선택이라, 안전하지만 느릴 수 있는 TCP와 정반대 성격이다.` }, { term: `포트 (Port)`, category: `네트워크`, short: `IP라는 건물의 방 번호`, desc: `한 기기(IP) 안에서 어떤 프로그램이 통신을 받을지 구분하는 번호다. 443은 HTTPS, 22는 SSH, 5432는 PostgreSQL처럼 유명 서비스는 번호가 전 세계 공통으로 정해져 있다. 우리 백엔드(Spring Boot)가 8080 포트에서 뜨고 localhost:8080으로 접속하는 것도 이 규칙이다.` }, { term: `패킷 (Packet)`, category: `네트워크`, short: `데이터를 나눈 택배 상자`, desc: `큰 데이터는 통째로 못 보내니 작은 조각으로 쪼갠 것이 패킷이며, 상자마다 순서 번호가 붙는다. 상자들이 서로 다른 길로 가도 도착지에서 번호대로 다시 조립하면 원본이 된다. 지금 보는 이 페이지의 글자들도 수십~수백 개 패킷으로 나뉘어 도착한 것이다.` }, { term: `대역폭 (Bandwidth)`, category: `네트워크`, short: `도로의 '차선 수'`, desc: `단위 시간에 통과할 수 있는 데이터의 최대량으로, 흔히 Mbps(초당 메가비트)로 표시한다. 8비트가 1바이트라, 100Mbps라도 실제 다운로드는 약 12.5MB/s에 그친다 — 광고 속도가 체감보다 빨라 보이는 이유다. 지연시간(반응 속도)과는 다른 개념이라는 점이 핵심이다.` }, { term: `상태코드 (HTTP status code)`, category: `네트워크`, short: `서버 대답의 첫마디`, desc: `서버가 요청 결과를 세 자리 숫자로 알려 주는 것으로, 첫 숫자만 봐도 분위기를 안다 — 2xx 성공, 4xx 요청 잘못, 5xx 서버 잘못. 200(성공)·401(로그인 필요)·404(없는 주소)·500(서버 오류)이 대표적이다. API가 안 될 때 '상태코드가 뭐야?'가 디버깅의 첫 질문이다.` }, { term: `쿠키 (Cookie)`, category: `네트워크`, short: `브라우저가 든 번호표`, desc: `서버가 발급해 브라우저에 저장해 두는 작은 데이터로, 이후 요청마다 자동으로 따라붙는다. HTTP는 매 요청이 끝나면 상대를 잊어버리는데(무상태), 쿠키라는 번호표 덕분에 로그인 상태가 계속 유지된다. 우리 플랫폼도 세션 쿠키로 페이지를 옮겨도 '김미림 님'을 알아본다.` }, { term: `방화벽 (Firewall)`, category: `네트워크`, short: `포트를 여닫는 문지기`, desc: `어떤 통신을 허용하고 막을지 규칙으로 걸러 주는 보안 장치다. 꼭 필요한 포트만 열고 나머지는 닫는 '최소 권한'이 기본 원칙이며, AWS에서는 보안 그룹(Security Group)이 이 역할을 한다. 실수로 DB 포트를 인터넷 전체에 열어 두면 큰 사고로 이어질 수 있다.` }, { term: `VPN`, category: `네트워크`, short: `인터넷 위 암호화 터널`, desc: `내 기기와 목적지 사이에 암호화된 통로를 만들어, 중간에서 통신 내용을 못 보게 하고 마치 다른 위치에서 접속하는 것처럼 보이게 한다. 회사 내부망에 안전하게 접속하거나 공용 와이파이에서 자신을 보호할 때 쓴다. 특정 요청만 대신 전하는 프록시보다 더 넓은 범위의 트래픽을 통째로 감싼다.` }, { term: `프록시 (Proxy)`, category: `네트워크`, short: `요청을 대신 전하는 대리인`, desc: `클라이언트와 서버 사이에서 요청·응답을 중계하는 중간 서버다. 요청을 대신 받아 뒤쪽 서버로 넘기는 '리버스 프록시'는 부하 분산·HTTPS 처리·보안에 쓰이며, 우리 플랫폼의 Caddy와 Gateway가 바로 그 예다. VPN이 '터널'이라면 프록시는 '창구 대리인'에 가깝다.` }, { term: `서버 (Server)`, category: `서버와 데이터`, short: `요청 오면 응답 내주는 프로그램`, desc: `서버는 특별한 기계가 아니라 '요청을 기다렸다가 응답을 돌려주는 프로그램'이자 역할이다. 이 플랫폼도 서울 EC2 위의 Caddy·Spring Boot 같은 서버 프로그램이 여러분의 요청을 받아 화면과 데이터를 내려준다. 여러분의 노트북도 서버 프로그램을 켜는 순간 서버가 된다.` }, { term: `클라이언트 (Client)`, category: `서버와 데이터`, short: `서버에 요청 보내는 쪽(손님)`, desc: `클라이언트는 서버에게 "이거 주세요"라고 요청을 보내는 쪽으로, 보통 여러분의 웹 브라우저나 앱이다. 서버가 식당 직원이라면 클라이언트는 주문하는 손님이다. 지금 이 학습 페이지를 열고 있는 브라우저가 바로 클라이언트다.` }, { term: `데이터베이스 (Database, DB)`, category: `서버와 데이터`, short: `데이터를 정리해 보관하는 창고`, desc: `데이터베이스는 회원·강좌·진도 같은 데이터를 표(테이블) 형태로 안전하게 저장하고 빠르게 꺼내 쓰도록 만든 소프트웨어다. 이 플랫폼은 PostgreSQL이라는 관계형 데이터베이스를 쓴다. 앱을 껐다 켜도 데이터가 사라지지 않는 이유가 바로 DB에 담겨 있기 때문이다.` }, { term: `SQL`, category: `서버와 데이터`, short: `DB에게 말 거는 질의 언어`, desc: `SQL(Structured Query Language)은 데이터베이스에 "이 데이터 꺼내줘/넣어줘"라고 지시하는 표준 언어다. SELECT로 조회하고 INSERT·UPDATE·DELETE로 넣고 고치고 지운다. 이 플랫폼의 진짜 회원·진도 테이블을 SQL로 조회하며 배우게 된다.` }, { term: `테이블 · 행 · 열 (Table / Row / Column)`, category: `서버와 데이터`, short: `데이터를 담는 엑셀 같은 표`, desc: `관계형 DB는 데이터를 표(테이블)에 저장하며, 가로 한 줄이 행(레코드=데이터 한 건), 세로 칸이 열(컬럼=속성)이다. 예를 들어 '회원' 테이블에서 한 행은 한 사람이고, '이름'·'이메일' 열은 그 사람의 속성이다. 엑셀 시트를 떠올리면 거의 똑같다.` }, { term: `기본키 · 외래키 (Primary Key / Foreign Key)`, category: `서버와 데이터`, short: `행을 구분하는 번호표와 연결고리`, desc: `기본키(PK)는 테이블에서 각 행을 유일하게 구분하는 값(예: 회원 id)으로, 절대 중복되지 않는 번호표다. 외래키(FK)는 다른 테이블의 기본키를 가리켜 두 표를 잇는 값으로, '이 진도 기록은 몇 번 회원의 것'인지를 연결한다. 이 고리 덕분에 흩어진 표들이 하나의 데이터로 이어진다.` }, { term: `인덱스 (Index)`, category: `서버와 데이터`, short: `DB의 책 뒤 '찾아보기'`, desc: `인덱스는 특정 열의 값을 미리 정렬해 둔 색인으로, 원하는 행을 처음부터 다 뒤지지 않고 빠르게 찾게 해 준다. 책 맨 뒤의 '찾아보기(색인)'와 같은 역할이라 데이터가 많을수록 조회 속도 차이가 크다. 다만 데이터를 넣고 고칠 때는 조금 느려지므로 꼭 필요한 열에만 건다.` }, { term: `캐시 (Cache)`, category: `서버와 데이터`, short: `자주 쓰는 걸 가까이 두기`, desc: `캐시는 자주·반복해서 쓰는 데이터를 원본(DB)보다 빠른 곳에 잠깐 복사해 두어 속도를 높이는 기법이다. 매번 창고(DB)까지 가는 대신 책상 위에서 바로 꺼내 쓰는 셈이다. 이 플랫폼은 Redis 계열인 Valkey를 캐시로 써서 시세·토큰 같은 데이터를 빠르게 내려준다.` }, { term: `NoSQL`, category: `서버와 데이터`, short: `표가 아닌 유연한 저장 방식`, desc: `NoSQL은 관계형 표(SQL) 대신 키-값·문서 같은 유연한 구조로 데이터를 다루는 데이터베이스들을 통칭한다. 정해진 표 구조가 덜 엄격해 아주 빠르거나 대용량 처리에 유리한 대신, 복잡한 관계 조회는 SQL이 더 낫다. 캐시로 쓰는 Redis/Valkey가 대표적인 키-값 NoSQL이다.` }, { term: `API`, category: `서버와 데이터`, short: `프로그램끼리의 약속된 창구`, desc: `API(응용 프로그램 인터페이스)는 프로그램끼리 정해진 규칙으로 요청·응답을 주고받는 창구다. 식당 메뉴판처럼 "이렇게 요청하면 이런 걸 준다"는 약속이라, 화면(프론트엔드)은 서버(백엔드)의 API를 불러 데이터를 받는다. 이 플랫폼의 화면들도 전부 /api/... 주소로 서버에 요청해 채워진다.` }, { term: `REST API`, category: `서버와 데이터`, short: `주소로 자원을 다루는 API 방식`, desc: `REST는 웹 API를 설계하는 대표 방식으로, 데이터를 '자원'으로 보고 URL 주소로 지정한 뒤 GET(조회)·POST(생성)·PUT(수정)·DELETE(삭제) 같은 HTTP 메서드로 다룬다. 규칙이 단순하고 예측 가능해 가장 널리 쓰인다. 이 플랫폼의 /api/auth, /api/market 같은 주소가 REST 스타일이다.` }, { term: `JSON`, category: `서버와 데이터`, short: `데이터를 주고받는 공용 문서 형식`, desc: `JSON은 데이터를 '이름:값' 쌍과 목록으로 적는 가벼운 텍스트 형식으로, API가 데이터를 주고받는 표준 포장지다. {"name":"미림","progress":40}처럼 사람도 읽을 수 있고 거의 모든 프로그래밍 언어가 이해한다. 서버가 보내는 응답, 앱이 보내는 요청 대부분이 JSON이다.` }, { term: `컨테이너 (Container / Docker)`, category: `서버와 데이터`, short: `앱을 통째로 포장한 상자`, desc: `컨테이너는 프로그램과 실행에 필요한 환경을 하나의 상자로 묶어, 어느 컴퓨터에서도 똑같이 돌아가게 하는 기술이다. Docker(도커)가 대표 도구이며 "내 컴퓨터에선 됐는데" 문제를 크게 줄여 준다. 이 플랫폼도 Caddy·Spring Boot·PostgreSQL을 각각 컨테이너로 포장해 docker-compose로 함께 띄운다.` }, { term: `SSH`, category: `서버와 데이터`, short: `원격 서버에 안전하게 접속`, desc: `SSH(Secure Shell)는 멀리 있는 서버에 암호화된 통로로 접속해 터미널 명령을 내리는 방법이다. 비밀번호나 키(key)로 인증하며 오가는 내용이 암호화돼 안전하다. 이 플랫폼 서버(서울 EC2)에 들어가 로그를 보거나 배포할 때 바로 SSH로 접속한다.` }, { term: `변수 (variable)`, category: `소프트웨어`, short: `값을 담아 이름 붙인 상자`, desc: `데이터를 저장해 두고 이름으로 꺼내 쓰는 공간이다. 예를 들어 const title = '미림'처럼 값을 담아두면 코드 여러 곳에서 그 이름으로 재사용할 수 있다. 이 플랫폼 코드 곳곳의 const·let 선언이 모두 변수이며, 코딩 기초에서 가장 먼저 배우는 개념이다.` }, { term: `함수 (function)`, category: `소프트웨어`, short: `입력을 받아 결과를 내는 기계`, desc: `반복되는 일을 하나의 이름으로 묶어 필요할 때 불러 쓰는(호출하는) 코드 덩어리다. 입력값(매개변수)을 받아 처리한 뒤 결과를 돌려준다(return). 버튼을 눌렀을 때의 동작, 강좌 카드를 그리는 로직 등 이 앱의 기능 대부분이 함수 단위로 나뉘어 있다.` }, { term: `조건문·반복문 (control flow)`, category: `소프트웨어`, short: `만약 ~이면, ~인 동안 반복`, desc: `조건문(if)은 상황에 따라 실행할 코드를 고르고, 반복문(for·while)은 같은 일을 여러 번 되풀이한다. 예를 들어 여러 강좌를 화면에 하나씩 그릴 때 반복문(React에서는 배열의 map)이 목록을 돌며 카드를 만들어 낸다. 프로그램이 위에서 아래로만 흐르지 않고 판단하고 반복하게 만드는 기본 도구다.` }, { term: `배열 (array)`, category: `소프트웨어`, short: `번호표 붙은 칸들의 줄`, desc: `여러 값을 순서대로 담고, 0번부터 시작하는 번호(인덱스)로 각 칸에 접근하는 자료구조다. 강좌 목록처럼 '여러 개를 순서대로' 다룰 때 쓴다. 순서대로 훑기는 빠르지만 특정 값이 들어 있는지 처음부터 끝까지 찾으면 개수가 많을수록 느려진다.` }, { term: `스택·큐 (stack & queue)`, category: `소프트웨어`, short: `쌓기 vs 줄서기`, desc: `스택은 나중에 넣은 것을 먼저 꺼내는(LIFO) 구조로, 되돌리기(Undo)나 함수 호출 기록 같은 곳에 쓰인다. 큐는 먼저 들어온 것을 먼저 꺼내는(FIFO) 구조로, 순서대로 처리하는 작업 대기열에 쓰인다. 담는 방식이 아니라 '꺼내는 순서'가 다른, 목적에 맞춘 그릇이다.` }, { term: `해시맵 (hash map)`, category: `소프트웨어`, short: `이름표로 바로 찾는 사전`, desc: `'열쇠(key) → 값(value)' 쌍으로 저장해, 키만 알면 개수와 상관없이 거의 즉시 값을 찾는 자료구조다(자바스크립트의 객체·Map). 배열이 처음부터 뒤지는 것과 달리 '학번으로 학생 찾기'처럼 곧바로 접근한다. 조회가 잦은 곳이나 캐시에서 속도의 핵심이 된다.` }, { term: `컴포넌트 (component)`, category: `소프트웨어`, short: `화면을 이루는 조립 블록`, desc: `화면을 독립적인 조각으로 나눈 재사용 단위로, React 화면을 만드는 기본 블록이다. 바깥에서 받아오는 값을 props, 컴포넌트가 스스로 기억하는 값을 state라 하며, state가 바뀌면 화면이 자동으로 다시 그려진다. 이 플랫폼의 강좌 카드와 각 페이지가 전부 컴포넌트로 만들어져 있다.` }, { term: `라이브러리·프레임워크 (library vs framework)`, category: `소프트웨어`, short: `빌려 쓰는 도구 vs 큰 뼈대`, desc: `라이브러리는 내가 필요할 때 불러다 쓰는 기능 모음(예: 날짜 처리 도구)이고, 프레임워크는 정해진 구조 안에 내 코드를 채워 넣는 큰 뼈대다. '내가 라이브러리를 부르고, 프레임워크가 나를 부른다'가 핵심 차이. 이 앱은 React·Spring Boot라는 프레임워크 위에 여러 라이브러리를 얹어 만든다.` }, { term: `커밋 (commit)`, category: `소프트웨어`, short: `코드 변경의 저장 지점`, desc: `바꾼 내용을 하나의 묶음으로 기록하는 Git의 저장 단위로, '무엇을 왜 바꿨는지' 메시지를 함께 남긴다. 이 스냅샷들이 쌓여 있어 언제든 과거 상태를 돌아보거나 되돌릴 수 있다. 작고 의미 있는 단위로 자주 커밋하는 습관이 협업의 기본기다.` }, { term: `브랜치 (branch)`, category: `소프트웨어`, short: `본류를 건드리지 않는 작업 갈래`, desc: `메인 코드에서 갈라져 나온 독립 작업 공간으로, 새 기능이나 실험을 안전하게 만들다가 완성되면 다시 합친다(merge). 여러 사람이 서로를 방해하지 않고 동시에 일할 수 있게 해준다. 이 저장소의 개발도 main에서 갈라진 작업 브랜치 위에서 이뤄진다.` }, { term: `Pull Request (PR)`, category: `소프트웨어`, short: `내 브랜치를 합쳐달라는 요청`, desc: `내가 만든 브랜치를 메인에 합치기 전에 동료에게 검토(코드리뷰)를 받는 절차이자 화면이다. 변경된 내용을 한눈에 보여주고, 토론과 수정을 거쳐 승인되면 병합된다. 우리 Gitea에서 이뤄지며, 좋은 PR 매너(작은 단위·친절한 설명)는 수습에게 특히 중요한 협업 역량이다.` }, { term: `디버깅 (debugging)`, category: `소프트웨어`, short: `버그를 찾아 고치는 추적`, desc: `프로그램이 잘못 동작하는 원인(버그)을 찾아 고치는 과정이다. 에러의 스택트레이스(어디서 터졌는지 알려주는 호출 경로)를 읽고, 브레이크포인트로 실행을 멈춰 값을 확인하며 단서를 좁혀간다. 에러 메시지는 혼내는 말이 아니라 '여기를 보라'는 단서라는 태도가 핵심이다.` }, { term: `리팩터링 (refactoring)`, category: `소프트웨어`, short: `동작은 그대로, 속을 정리`, desc: `겉으로 보이는 동작은 바꾸지 않으면서 코드 내부를 더 읽기 쉽고 고치기 쉽게 다듬는 작업이다. 좋은 이름 짓기, 길고 복잡한 함수 쪼개기 등이 대표적이다. 테스트 코드가 있으면 '정리한 뒤에도 똑같이 동작하는지'를 확인할 수 있어 안심하고 리팩터링할 수 있다.` }, { term: `테스트 코드 (test)`, category: `소프트웨어`, short: `코드를 검사하는 코드`, desc: `내 코드가 기대대로 동작하는지 자동으로 확인하도록 짠 코드다. 한 번 만들어두면 기능을 고칠 때마다 자동으로 재검사해, 예전에 잘 되던 것이 조용히 망가지는 사고를 막아준다. '미래의 나를 지키는 보험'이라 불리며, 이 플랫폼에서도 실제 테스트가 학습 교재로 쓰인다.` }, { term: `UI/UX`, category: `디자인`, short: `화면 겉모습(UI) + 쓰는 경험(UX)`, desc: `UI(User Interface)는 버튼·색·글자처럼 눈에 보이는 화면 요소이고, UX(User Experience)는 그 화면을 쓰면서 겪는 편함·흐름 전체다. 둘 다 좋아야 좋은 제품이며, 예쁘기만 하고 쓰기 불편하면 UX가 실패한 것이다. 이 학습 플랫폼의 강좌 화면도 UI와 UX를 함께 설계한 결과다.` }, { term: `시각적 위계 (Visual Hierarchy)`, category: `디자인`, short: `뭘 먼저 볼지 정해 주는 순서`, desc: `크기·굵기·색·위치 차이로 화면 요소에 '먼저 볼 것 → 나중에 볼 것'의 순서를 만드는 것이다. 사람은 글을 꼼꼼히 읽기보다 훑어보기(스캔) 때문에, 제목을 크고 진하게·보조 정보를 작고 연하게 두면 눈길을 원하는 곳으로 이끈다. 학습 센터의 강좌 카드에서 제목이 설명글보다 크고 진한 이유가 이것이다.` }, { term: `대비 (Contrast)`, category: `디자인`, short: `서로 달라서 눈에 띄는 정도`, desc: `두 요소의 밝기·색·크기 차이를 말하며, 차이가 클수록 잘 구분되고 눈에 띈다. 특히 글자색과 배경색의 명도 대비가 낮으면 흐릿해 읽기 어려워지므로 가독성과 접근성의 핵심 기준이 된다. 강조 버튼을 브랜드 블루로 칠해 회색 배경과 대비를 준 것이 그 예다.` }, { term: `타이포그래피 (Typography)`, category: `디자인`, short: `글자를 읽기 좋게 다루는 기술`, desc: `폰트 종류, 글자 크기, 굵기, 줄 간격(행간)을 조절해 글을 읽기 좋게 배치하는 기술이다. 화면 정보의 대부분이 글자라 디자인 완성도를 크게 좌우하며, 본문은 보통 15~16px에 행간 1.5~1.6, 제목은 더 크게 두어 위계를 만든다. 세리프(명조처럼 삐침 있음)와 산세리프(고딕처럼 깔끔함)를 구분하는 것이 기본이다.` }, { term: `그리드 (Grid)`, category: `디자인`, short: `화면을 세우는 보이지 않는 모눈종이`, desc: `요소들을 일정한 간격과 열에 맞춰 배치하도록 돕는 보이지 않는 격자다. 특히 모든 간격·크기를 8의 배수(8·16·24px)로 맞추는 8pt 그리드를 쓰면 '몇 px 띄울까' 고민이 줄고 화면이 저절로 정돈된다. 여러 카드의 윗변·왼쪽이 같은 선에 맞으면 그리드를 꺼도 깔끔해 보인다.` }, { term: `여백 (Whitespace)`, category: `디자인`, short: `일부러 비워 둔 빈 공간`, desc: `요소 사이나 주변에 일부러 남겨 둔 빈 공간으로, 흰색이 아니어도 여백이라 부른다. 비어 있어 낭비처럼 보이지만 관련된 것을 묶어 주고 화면에 숨 쉴 틈을 줘 오히려 읽기 쉽고 정돈돼 보이게 한다. 안쪽 여백(padding)은 바깥 여백(margin)보다 작거나 같게 두는 것이 기본 감각이다.` }, { term: `벡터 그래픽 (SVG)`, category: `디자인`, short: `확대해도 안 깨지는 '그리는 법' 그림`, desc: `이미지는 크게 두 종류다. 비트맵(PNG·JPG)은 칸마다 색을 기록해 확대하면 계단처럼 깨지고, 벡터(SVG)는 '어떻게 그리는지'를 수식으로 기록해 아무리 키워도 매끈하다. 그래서 아이콘·로고처럼 여러 크기로 쓰는 그림은 SVG가 유리하고, 사진처럼 색이 복잡한 것은 비트맵을 쓴다.` }, { term: `와이어프레임 (Wireframe)`, category: `디자인`, short: `색 없이 구조만 그린 설계 도면`, desc: `색·이미지·폰트 없이 네모와 선만으로 화면의 뼈대(무엇이 어디에, 얼마나 크게 놓이는지)를 그린 밑그림이다. 코드로 만들기 전에 빠르게 그려 보고 아니면 버리는 용도라, 완성도를 일부러 낮춰 고치는 비용을 줄인다. 보통 손그림(Lo-Fi) → 회색 박스(Mid-Fi) → 시안(Hi-Fi) 순으로 완성도를 올린다.` }, { term: `프로토타입 (Prototype)`, category: `디자인`, short: `진짜처럼 눌러 보는 가짜 앱`, desc: `실제로 코딩하기 전에, 화면들을 연결해 버튼을 누르면 다음 화면으로 넘어가도록 만든 '눌러 볼 수 있는 모형'이다. 피그마 같은 도구에서 화면을 선으로 이어 만들며, 개발 없이도 흐름의 어색함이나 빠진 화면을 미리 발견할 수 있다. 와이어프레임이 정지 그림이라면 프로토타입은 움직이는 시연본이다.` }, { term: `피그마 (Figma)`, category: `디자인`, short: `브라우저에서 도는 협업 디자인 툴`, desc: `웹 브라우저에서 바로 쓰는 화면 디자인 도구로, 무료 계정으로 시작할 수 있고 여러 명이 실시간으로 같은 파일을 함께 편집한다. 프레임(화면 틀)·오토레이아웃(자동 정렬)·컴포넌트(재사용 부품)·프로토타입 기능으로 와이어프레임부터 시안·개발 전달(핸드오프)까지 한 곳에서 처리한다. 오늘날 UI 디자인의 사실상 표준 도구다.` }, { term: `디자인 시스템 (Design System)`, category: `디자인`, short: `색·글꼴·부품의 공식 규칙집`, desc: `색·간격·글꼴 같은 값(토큰)과 버튼·카드 같은 부품(컴포넌트)에 이름과 규칙을 정해 팀 전체가 똑같이 쓰도록 묶은 것이다. 사람마다 제각각 디자인하는 것을 막아 일관성을 지키고 작업 속도를 높인다. 이 플랫폼의 global.css에 정의된 색·간격 변수가 바로 살아 있는 디자인 시스템의 예다.` }, { term: `컴포넌트 (Component)`, category: `디자인`, short: `재사용하는 화면 부품`, desc: `버튼·카드·입력창처럼 여러 곳에서 반복해 쓰는 화면 조각을 하나의 부품으로 만들어 둔 것이다. 피그마에서는 원본(마스터) 하나만 고치면 복제본이 전부 함께 바뀌어, 디자인을 수정할 때 일일이 손볼 필요가 없다. 디자인 시스템의 '2층'에 해당하며, 토큰(색·간격)을 조합해 만든다.` }, { term: `터치 타깃 (Touch Target)`, category: `디자인`, short: `손가락으로 누르는 영역의 크기`, desc: `버튼·링크처럼 손가락으로 눌러야 하는 영역과 그 최소 크기를 말한다. 마우스 포인터보다 손가락 끝이 뭉툭해서, 모바일에서는 최소 44×44px 정도를 확보해야 빗나가지 않고 편하게 눌린다. 또 엄지가 편히 닿는 화면 아래쪽에 자주 쓰는 버튼(하단 탭바 등)을 두는 것이 모바일 설계의 기본이다.` }, { term: `접근성 (Accessibility)`, category: `디자인`, short: `누구나 쓸 수 있게 만드는 배려`, desc: `시력이 약하거나 색을 구분하기 어렵거나 마우스를 못 쓰는 사람까지 포함해, 모두가 제품을 쓸 수 있게 설계하는 것이다. 글자·배경의 명도 대비를 충분히 주기, 이미지에 대체 텍스트(alt) 달기, 색만으로 정보를 전하지 않기 등이 대표 실천이다. 특정 소수만을 위한 것 같지만 결국 모든 사용자의 편의를 높인다.` }, { term: `네이티브 앱 (Native App)`, category: `앱 개발`, short: `그 OS 전용 언어로 만든 앱`, desc: `안드로이드는 Kotlin/Java, iOS는 Swift처럼 각 운영체제 전용 도구로 만든 앱이다. 카메라·센서 등 기기 기능을 가장 빠르고 완전하게 쓸 수 있지만, 두 플랫폼을 따로 개발해야 해 품이 많이 든다. 이 카테고리에서 크로스플랫폼·PWA와 비교하며 '언제 네이티브를 고르나'를 배운다.` }, { term: `크로스플랫폼 (Cross-platform)`, category: `앱 개발`, short: `코드 하나로 안드로이드·iOS 둘 다`, desc: `한 벌의 코드로 안드로이드와 iOS 앱을 함께 만드는 방식으로, React Native·Flutter가 대표 주자다. 개발 인력과 시간을 아낄 수 있어 스타트업이 즐겨 쓴다. React를 아는 웹 개발자가 앱으로 넘어갈 때 첫 다리가 된다.` }, { term: `안드로이드 (Android)`, category: `앱 개발`, short: `구글의 모바일 OS(로봇 🤖)`, desc: `구글이 만든 모바일 운영체제로 전 세계 스마트폰 점유율이 가장 높다. 앱은 주로 Kotlin으로 Android Studio에서 개발하고 APK/AAB 파일로 배포한다. 화면 단위인 '액티비티'와 그 생명주기가 앱 동작의 기본 골격이다.` }, { term: `iOS`, category: `앱 개발`, short: `아이폰용 애플 OS(사과 🍎)`, desc: `애플의 아이폰·아이패드 운영체제로, 앱은 Swift 언어와 Xcode 도구로 개발하며 개발에 맥(Mac)이 필요하다. 생태계 규칙과 심사가 엄격한 대신 사용자 결제·품질 기대가 높다. 안드로이드와 함께 모바일 앱의 양대 축이다.` }, { term: `Kotlin (코틀린)`, category: `앱 개발`, short: `안드로이드 공식 1순위 언어`, desc: `JetBrains가 만든 언어로, 구글이 안드로이드 개발 1순위로 공식 지정했다. Java와 호환되면서 문법이 간결하고 null 안전성이 좋아 흔한 실수를 줄여준다. 안드로이드 네이티브 앱을 만들 때 가장 먼저 배우는 언어다.` }, { term: `Swift (스위프트)`, category: `앱 개발`, short: `iOS 앱 만드는 애플 언어`, desc: `애플이 iOS·macOS 앱을 위해 만든 언어로, 안전하고 읽기 쉬운 문법이 특징이다. 최신 UI 도구인 SwiftUI와 짝을 이뤄 화면을 선언형으로 그린다. 아이폰 네이티브 앱 개발에 꼭 필요한 언어다.` }, { term: `React Native (리액트 네이티브)`, category: `앱 개발`, short: `React로 진짜 앱 만들기`, desc: `웹에서 쓰는 React 문법 그대로 안드로이드·iOS 네이티브 앱을 만드는 크로스플랫폼 프레임워크다. 웹 지식이 거의 그대로 이어져 웹 개발자의 앱 입문 다리로 좋다. 이 플랫폼에서 쌓은 React 경험을 앱으로 확장하는 지름길이다.` }, { term: `Flutter (플러터)`, category: `앱 개발`, short: `위젯 레고로 앱 조립(Dart)`, desc: `구글이 만든 크로스플랫폼 프레임워크로, Dart 언어를 쓰고 화면의 모든 것을 '위젯(Widget)' 블록으로 조립한다. 자체 렌더링 엔진으로 안드로이드·iOS에서 똑같은 화면을 빠르게 그린다. React Native와 함께 크로스플랫폼의 양대 선택지다.` }, { term: `앱 생명주기 (App Lifecycle)`, category: `앱 개발`, short: `앱이 켜지고 멈추는 단계들`, desc: `앱 화면이 생성→표시→가려짐→종료로 이어지는 정해진 단계와, 각 단계에서 자동으로 호출되는 함수들을 말한다(안드로이드 액티비티, iOS 뷰컨트롤러). 전화가 와서 앱이 잠시 멈출 때 데이터를 안전하게 저장하려면 이 흐름을 알아야 한다. '중단·복귀'가 잦은 모바일의 핵심 개념이다.` }, { term: `PWA (프로그레시브 웹 앱)`, category: `앱 개발`, short: `설치되는 웹앱`, desc: `브라우저로 만든 웹사이트를 홈 화면 설치·오프라인·푸시 알림까지 되게 해 앱처럼 쓰게 하는 기술이다. 스토어 심사 없이 배포할 수 있어, 우리 웹앱(React) 자산을 가장 적은 비용으로 앱화하는 길이다. 서비스 워커와 매니페스트가 두 기둥이다.` }, { term: `서비스 워커 (Service Worker)`, category: `앱 개발`, short: `웹앱 뒤에서 도는 일꾼`, desc: `웹페이지와 별개로 브라우저 뒤에서 도는 스크립트로, 네트워크 요청을 가로채 캐시로 응답하거나(오프라인) 푸시 알림을 받는다. PWA가 인터넷 없이도 동작하게 하는 핵심 부품이다. 화면이 닫혀 있어도 살아 있어 백그라운드 작업을 맡는다.` }, { term: `웹 앱 매니페스트 (Web App Manifest)`, category: `앱 개발`, short: `웹앱의 신분증(JSON)`, desc: `앱 이름·아이콘·시작 주소·화면 방향 등을 적어 둔 JSON 파일로, 브라우저가 이걸 읽어 웹앱을 홈 화면에 '설치'해 준다. PWA를 진짜 앱처럼 보이게 하는 설정표다. (안드로이드 네이티브의 AndroidManifest.xml과 이름은 비슷하지만 다른 것이다.)` }, { term: `앱 권한 (Permission)`, category: `앱 개발`, short: `카메라·위치 쓰겠다는 허락`, desc: `앱이 카메라·위치·연락처·알림 등 민감한 기능에 접근하려면 사용자에게 받아야 하는 동의다. 필요한 순간에 꼭 필요한 것만 요청하는 게 원칙이며, 과한 권한 요구는 스토어 심사에서 거절 사유가 된다. 앱 보안과 신뢰의 첫 단추다.` }, { term: `스토어 심사 (App Store Review)`, category: `앱 개발`, short: `앱 등록 전 통과 시험`, desc: `만든 앱을 구글 Play·애플 App Store에 올리기 전, 플랫폼이 정책·보안·품질 기준으로 검토하는 과정이다. 특히 애플은 심사가 까다로워 반려되면 수정 후 재제출해야 한다. 배포 일정을 잡을 때 이 심사 기간을 반드시 감안해야 한다.` }, { term: `터미널 / 셸 (Terminal / Shell)`, category: `도구·보안`, short: `글자로 명령하는 검은 창`, desc: `터미널은 명령어를 입력하고 결과가 글자로 나오는 창(화면)이고, 셸(shell)은 그 안에서 내가 친 명령을 해석해 실행하는 프로그램이에요. 하나의 Windows Terminal 창에 PowerShell·Git Bash 같은 여러 셸을 탭으로 열 수 있어요. 우리 서버(AWS EC2)는 리눅스라 접속하면 결국 터미널로 다루게 되니, 개발의 현관문 같은 도구입니다.` }, { term: `CLI (명령줄 인터페이스)`, category: `도구·보안`, short: `마우스 대신 명령어로 조작`, desc: `CLI(Command Line Interface)는 버튼·아이콘을 클릭하는 대신 명령어를 타이핑해서 프로그램을 다루는 방식으로, 마우스로 누르는 GUI의 반대말이에요. git·npm·docker 같은 개발 도구 대부분이 CLI로 동작해요. 손에 익으면 반복 작업을 훨씬 빠르고 정확하게, 그리고 자동화까지 할 수 있습니다.` }, { term: `IDE (통합 개발 환경)`, category: `도구·보안`, short: `코딩 도구를 한 상자에`, desc: `IDE(Integrated Development Environment)는 코드 편집·실행·디버깅·검색을 한곳에 묶어 둔 프로그램이에요. 자바 쪽 IntelliJ가 대표적이고, VS Code도 확장을 더하면 IDE처럼 쓸 수 있죠. 자동완성·오류 표시·단축키 덕분에 메모장으로 코딩할 때보다 훨씬 빠르고 실수도 줄어듭니다.` }, { term: `환경변수 (Environment Variable)`, category: `도구·보안`, short: `코드 밖에 숨겨 두는 설정값`, desc: `환경변수는 프로그램 바깥(운영체제·실행 환경)에 저장해 두고 실행될 때 꺼내 쓰는 값이에요. DB 비밀번호·API 키 같은 비밀값을 코드나 Git에 넣지 않고 환경변수로 주입하는 게 보안의 기본입니다. 우리 플랫폼도 .env 파일로 값만 바꿔 개발용·운영용을 같은 코드로 돌려요.` }, { term: `패키지 매니저 (Package Manager)`, category: `도구·보안`, short: `라이브러리 설치·관리 도구`, desc: `패키지 매니저는 남이 만든 코드 묶음(라이브러리)을 명령 한 줄로 내려받고 버전을 관리해 주는 도구예요. 프론트의 npm, 자바의 Maven이 대표적이죠. npm install 한 번이면 프로젝트에 필요한 수많은 패키지를 알아서 맞춰 설치해 줍니다.` }, { term: `의존성 (Dependency)`, category: `도구·보안`, short: `내가 빌려 쓰는 남의 코드`, desc: `의존성은 내 프로젝트가 돌아가려면 필요한 외부 라이브러리, 즉 빌려 쓰는 코드예요. package.json이나 pom.xml에 목록이 적혀 있고 패키지 매니저가 그 목록대로 설치하죠. 편리하지만 버전이 안 맞거나 보안 취약점이 있는 의존성은 문제를 일으킬 수 있어 관리가 중요합니다.` }, { term: `인증 / 인가 (Authentication / Authorization)`, category: `도구·보안`, short: `누구인가 vs 뭘 해도 되나`, desc: `인증(Authentication)은 "네가 진짜 그 사람 맞아?"를 확인하는 것(로그인), 인가(Authorization)는 "그럼 이건 해도 돼?"라며 권한을 따지는 것이에요. 로그인은 됐지만 관리자 메뉴엔 못 들어가는 게 인증은 통과·인가는 거부된 상태죠. 우리 플랫폼도 로그인(인증) 뒤 학생/멘토 권한(인가)을 나눠 화면과 API 접근을 제어해요.` }, { term: `해싱 (Hashing)`, category: `도구·보안`, short: `되돌릴 수 없는 한 방향 지문`, desc: `해싱은 어떤 값을 규칙에 따라 알아볼 수 없는 고정 길이 문자열로 바꾸되, 원래 값으로 되돌릴 수 없게 만드는 것이에요(복호화되는 암호화와 다른 점). 비밀번호는 평문 저장 대신 반드시 해싱해 보관하는데, 우리 백엔드도 BCrypt로 해싱해서 DB가 털려도 원문 비밀번호는 알 수 없게 합니다.` }, { term: `암호화 (Encryption)`, category: `도구·보안`, short: `열쇠로 잠갔다 푸는 비밀문`, desc: `암호화는 데이터를 열쇠(키)로 잠가 아무나 못 읽게 만들고, 올바른 열쇠로만 다시 풀(복호화) 수 있게 하는 기술이에요. 해싱과 달리 되돌릴 수 있다는 점이 다르죠. 웹의 HTTPS(TLS)와 와이파이의 WPA가 전부 암호화라, 공용 와이파이에서 누가 엿봐도 암호문만 보이게 됩니다.` }, { term: `세션 / 쿠키 (Session / Cookie)`, category: `도구·보안`, short: `로그인 상태를 기억하는 장치`, desc: `HTTP는 매 요청을 남처럼 대해서, 로그인 상태를 유지하려면 별도 장치가 필요해요. 쿠키는 브라우저가 서버에서 받아 저장했다가 요청마다 자동으로 딸려 보내는 작은 데이터 조각이고, 세션은 서버가 "이 사람은 로그인된 아무개"라고 기억하는 상태예요. 로그인 정보가 든 쿠키를 훔치면 남의 계정이 되므로 httpOnly·HTTPS로 보호합니다.` }, { term: `최소 권한 원칙 (Least Privilege)`, category: `도구·보안`, short: `딱 필요한 만큼만 권한을`, desc: `최소 권한 원칙은 사람·프로그램·계정에게 일하는 데 꼭 필요한 최소한의 권한만 주는 보안의 기본 철학이에요. 한 곳이 뚫려도 피해를 그 범위에 가두는 게 목적이죠. 우리 AWS 보안그룹이 필요한 포트만 열고 나머지는 닫는 것, DB 계정에 DROP 권한을 안 주는 것이 모두 이 원칙입니다.` }, { term: `무차별 대입 (Brute Force)`, category: `도구·보안`, short: `비밀번호를 기계로 마구 찍기`, desc: `무차별 대입(브루트포스)은 가능한 아이디·비밀번호 조합을 자동으로 수만 번 시도해 로그인을 뚫으려는 공격이에요. 인터넷에 서버를 올리면 봇이 곧바로 SSH·로그인 화면을 두드리기 시작하죠. 강한 비밀번호, 로그인 시도 횟수 제한, IP 제한, 2단계 인증이 이를 막는 기본 방어입니다.` }, { term: `SQL 인젝션 (SQL Injection)`, category: `도구·보안`, short: `입력창에 DB 명령 몰래 끼우기`, desc: `SQL 인젝션은 로그인·검색 입력창에 SQL 문법을 섞어 넣어, 서버가 그걸 명령으로 잘못 실행하게 만드는 공격이에요. 성공하면 남의 데이터를 통째로 빼내거나 지울 수도 있죠. 사용자 입력을 쿼리에 직접 이어 붙이지 않고 파라미터로 분리(프리페어드 스테이트먼트)하면 막을 수 있습니다.` }, { term: `XSS (크로스 사이트 스크립팅)`, category: `도구·보안`, short: `페이지에 악성 스크립트 심기`, desc: `XSS는 게시글·댓글 같은 입력에 악성 자바스크립트를 심어, 그 페이지를 보는 다른 사용자의 브라우저에서 실행되게 하는 공격이에요. 남의 쿠키나 로그인 정보를 훔치는 데 자주 쓰이죠. 사용자 입력을 화면에 그대로 출력하지 않고 특수문자를 이스케이프 처리하면 막을 수 있습니다.` }, ]; |