클라이밍하는 개발자

1. TCP vs UDP: "꼼꼼한 비서" vs "성급한 배달원"인터넷에서 데이터를 보내는 방식은 크게 두 가지가 있습니다.TCP (Transmission Control Protocol): 데이터를 보내기 전에 연결을 확인하고, 순서가 바뀌거나 유실되면 다시 보내주는 신뢰성 중심의 방식입니다. (웹핑, 이메일, 파일 전송 등)UDP (User Datagram Protocol): 연결 확인 따위는 생략하고 일단 냅다 던지는 속도 중심의 방식입니다. 좀 깨져도 상관없는 실시간 스트리밍이나 게임에 씁니다.2. 3-Way Handshake: 연결을 맺는 3단계TCP는 데이터를 보내기 전, 상대방과 손을 세 번 맞잡으며 통신 준비를 마칩니다.🙋‍♂️ 1단계: SYN (Synchronize) - "저기, 대화 가..

1. 문제 상황: "거북이와 토끼의 협업"컴퓨터의 연산 속도는 비약적으로 발전했지만, 데이터를 담아두는 RAM(메모리)의 속도는 그 발전 속도를 따라가지 못했습니다.CPU: 1초에 수십억 번의 연산을 처리할 만큼 광속으로 달리는 토끼입니다.메모리(RAM): CPU에 비하면 한 걸음 떼는 데 한참 걸리는 거북이입니다.비극: CPU가 계산을 하려 해도 메모리에서 데이터를 가져오는 데 시간이 너무 오래 걸려, CPU는 대부분의 시간을 멍하니 기다리는 데(IDLE) 쓰게 됩니다.2. 해결책: 캐시 메모리 (L1, L2, L3)CPU와 메모리 사이에 "작지만 아주 빠른" 임시 창고를 하나 더 만들었습니다. 이게 바로 캐시 메모리입니다.L1 캐시: CPU 내부에 직접 붙어있는 가장 빠른 캐시. 용량이 매우 작습니다..

1. RDB의 한계: "전부 다 읽어봐야 해"일반적인 관계형 데이터베이스(MySQL 등)에서 제목에 '강아지'가 포함된 글을 찾으려면 어떻게 할까요?쿼리: SELECT * FROM posts WHERE title LIKE '%강아지%';문제: DB는 제목의 처음부터 끝까지 글자를 하나하나 대조하며 읽어야 합니다. 데이터가 1억 건이라면? 한 번 검색할 때마다 서버가 비명을 지를 겁니다. (지난번에 배운 인덱스도 단어 중간 검색에는 힘을 못 씁니다.)2. 엘라스틱서치의 비결: 역색인 (Inverted Index)엘라스틱서치는 데이터를 저장할 때 아예 '단어장'을 따로 만듭니다. 이걸 역색인이라고 부릅니다.📚 찰떡 비유: 책의 색인(Index) vs 본문일반 DB: 책을 1페이지부터 끝까지 읽으면서 '강아..

1. 찰떡 비유: 두꺼운 전공 서적의 '찾아보기(색인)'인덱스는 책의 맨 뒷부분에 있는 '색인(Index)'과 완벽히 똑같습니다.인덱스가 없을 때 (Full Table Scan): '트랜잭션'이라는 단어를 찾기 위해 책의 1페이지부터 마지막 페이지까지 한 장씩 넘기며 다 읽어야 합니다. (매우 느림)인덱스가 있을 때 (Index Scan): 색인 페이지에서 'ㅌ' 항목을 찾아 '트랜잭션: 345p'를 확인한 뒤, 바로 345페이지를 펼칩니다. (매우 빠름)2. 인덱스의 핵심 자료구조: B-Tree (Balanced Tree)데이터베이스는 인덱스를 단순히 가나다순으로 정렬해서 저장하지 않습니다. 가장 효율적으로 찾기 위해 B-Tree라는 나무 모양의 자료구조를 사용합니다.루트 노드(뿌리): 가장 위에서 길..

1. 세션(Session) vs 토큰(Token)🏨 세션 방식: "호텔 프론트의 장부"사용자가 로그인하면 서버는 메모리(세션 저장소)에 "1번 손님 로그인함"이라고 적어둡니다.손님에게는 세션 ID라는 번호표만 줍니다.단점: 손님이 수백만 명이면 서버 메모리가 터져나갑니다. 서버를 여러 대(L4/L7 로드 밸런싱)로 늘리면, 1번 서버에 로그인한 사람이 2번 서버로 갔을 때 "누구세요?"라는 소리를 듣게 됩니다. (서버끼리 장부를 공유해야 하는 번거로움 발생)🎫 토큰(JWT) 방식: "놀이공원 자유이용권"사용자가 로그인하면 서버는 손님의 정보가 담긴 '자유이용권(JWT)'을 발급해 줍니다.서버는 이 정보를 따로 저장하지 않습니다.손님은 이 이용권을 주머니에 넣고 다니다가, 다음 요청 때 서버에 보여줍니..

1. 비유: 아주 바쁜 1인 식당 🍳자바스크립트 실행 환경을 혼자서 요리하고 서빙하는 1인 식당이라고 상상해 봅시다.호출 스택 (Call Stack): 요리사(CPU)가 지금 당장 프라이팬을 돌리며 하고 있는 일입니다. 한 번에 요리 하나만 가능하죠.Web APIs (보조 주방): 오븐이나 타이머 같은 곳입니다. "고기 10분만 구워줘"라고 던져놓으면 요리사는 다른 일을 할 수 있습니다. (네트워크 요청, 타이머 등)태스크 큐 (Task Queue): 요리가 완성되어 서빙을 기다리는 음식들이 놓이는 대기대입니다.이벤트 루프 (Event Loop): 홀을 계속 뱅글뱅글 돌면서 "요리사 손이 비었나?" 확인하고, 비었으면 대기대의 음식을 손님에게 전달해 주는 지배인입니다.2. 동작 과정: "잠깐 나갔다 올..

1. 찰떡 비유: 스마트폰의 '연락처' 앱 📖DNS의 역할은 여러분 스마트폰에 있는 '연락처(전화번호부)' 앱과 완벽하게 똑같습니다.과거: 친구 집에 전화하려면 02-123-4567이라는 전화번호(IP 주소)를 외우거나 수첩을 뒤져야 했습니다.현재: 연락처 앱에 '홍길동'이라고 검색해서 통화 버튼을 누르면, 스마트폰이 알아서 010-1234-5678로 전화를 걸어줍니다.즉, DNS는 사람이 읽기 쉬운 도메인 이름(naver.com)을 컴퓨터가 읽을 수 있는 IP 주소(223.130.200.107)로 번역해 주는 거대한 인터넷 전화번호부입니다.2. IP 주소를 찾아 떠나는 5단계의 여정우리가 브라우저에 [www.naver.com](https://www.naver.com)을 입력하고 엔터를 치는 순간, 우..

1. 두 가지 암호화 방식 (이해를 위한 필수 지식)핸드셰이크(악수) 과정을 이해하려면, 먼저 인류가 발명한 두 가지 암호화 방식을 알아야 합니다.① 대칭키 암호화 (빠르지만 위험함)원리: 암호화할 때 쓰는 키와, 복호화(해독)할 때 쓰는 키가 똑같습니다.장점: 계산이 아주 단순해서 엄청나게 빠릅니다.치명적 단점: 내가 서버랑 이 방식으로 통신하려면, 내 키를 서버한테 건네줘야 합니다. 근데 그 키를 건네주는 순간 해커가 중간에서 훔쳐 가면? 끝장입니다.② 비대칭키 암호화 (안전하지만 너무 느림)원리: 키가 2개(한 쌍)입니다. **'공개키(Public Key)'**와 '개인키(Private Key)'.규칙: 공개키로 잠근 건 개인키로만 열 수 있습니다. (반대도 가능)장점: 서버가 '공개키'를 동네방네..

"한빛미디어 서평단 활동을 위해서 책을 협찬 받아 작성된 서평입니다." 🎮 나 홀로 게임 개발, AI가 정말 다 해줄까?게임 개발은 기획, 아트, 사운드, 프로그래밍 등 넘어야 할 산이 너무 많아 혼자서는 엄두를 내기 힘든 영역입니다. 저도 게임에 관심이 많아 유튜브로 게임 개발 강의도 봤었으나, 혼자 다 만들기엔 너무 어려운 장르였습니다. 하지만 AI 시대가 열리면서 "나도 혼자 게임 하나 뚝딱 만들 수 있지 않을까?" 하는 기대감이 커졌습니다. 이번에 읽은 『AI 게임 개발 with 코덱스』는 딱 저 같은 생각을 가진 사람들을 위해, AI 툴들을 팀원 삼아 게임 기획부터 출시까지의 전 과정을 훑어보는 가이드북입니다. 책을 읽으며 배운 점과 책의 후기를 정리해 보았습니다. 🛠️ 1. 게임 기획..

1. 모놀리식 (Monolithic): "모든 것을 품은 거대한 성"초기 스타트업이나 전통적인 웹 서비스는 대부분 모놀리식(Monolithic) 구조로 시작합니다. 단어 그대로 '하나의 거대한 덩어리'라는 뜻입니다.쇼핑몰을 만든다고 가정해 봅시다.로그인 기능, 상품 검색 기능, 결제 기능, 배송 추적 기능이 전부 하나의 프로젝트(코드베이스) 안에 들어있습니다.데이터베이스(DB)도 거대한 것 딱 하나만 씁니다.👍 장점 (초반에는 최고!)개발이 쉽다: 그냥 코드 하나 열어서 다 짜면 됩니다.배포가 단순하다: 덩어리 하나만 서버에 딱 올리면 끝납니다.테스트와 디버깅이 편하다: 코드가 한곳에 모여 있어서 에러 추적이 쉽습니다.👎 단점 (회사가 커지면 지옥 시작)스파게티 코드: 로그인 코드를 살짝 고쳤는데, ..