CS 209

[1일 1CS] 도메인 이름은 어떻게 IP 주소로 바뀔까? DNS와 레코드의 이해

우리가 인터넷을 사용할 때 주소창에 '192.168.0.1' 같은 복잡한 숫자를 외워서 치는 사람은 없습니다. 대신 'naver.com'이나 'google.com' 같은 기억하기 쉬운 도메인 이름을 사용하죠.하지만 컴퓨터는 숫자(IP 주소)로만 통신할 수 있습니다. 그래서 사람들이 입력한 도메인 이름을 실제 서버의 IP 주소로 변환해 주는 거대한 전화번호부 시스템이 필요한데, 이것이 바로 도메인 네임 시스템(DNS)입니다. 1. 도메인 구조와 네임 서버의 계층도메인 이름은 점(.)을 기준으로 나뉘며, 오른쪽에서 왼쪽으로 갈수록 더 좁고 상세한 영역을 의미합니다. 전 세계의 수많은 도메인을 한 대의 서버에서 관리할 수 없기 때문에, 각 영역을 전담하는 네임 서버들이 계층 구조로 나뉘어 있습니다.루트 도메인..

[1일 1CS] React 컴포넌트 설계에 객체지향을 적용하는 이유

React 개발을 하다 보면 함수형 컴포넌트라는 이름 때문에 객체지향 개념과는 거리가 멀다고 생각하기 쉽습니다. 하지만 컴포넌트를 설계하고 조립하는 과정에서 객체지향의 철학을 적용하면, 요구사항이 시시각각 변하는 프론트엔드 환경에서도 흔들리지 않는 견고한 코드를 만들 수 있습니다. 1. 객체지향의 3대장: 역할, 책임, 협력객체지향을 아주 쉽게 이해하기 위해 동네 카페를 상상해 보겠습니다. 카페가 원활하게 돌아가려면 손님, 키오스크, 바리스타라는 세 명의 등장인물이 필요합니다.역할: 특정 상황에서 객체가 맡은 임무입니다. (손님, 키오스크, 바리스타)책임: 역할을 다하기 위해 해야 하는 행동입니다. (커피 주문하기, 주문 접수하기, 커피 제조하기)협력: 서로 메시지를 주고받으며 카페라는 시스템을 굴러가게..

[1일 1CS] LIKE 검색은 왜 느릴까? 엘라스틱서치(Elasticsearch)의 역색인과 분석기

쇼핑몰에서 '셔츠'를 검색했는데, 상품명에 영문으로 'shirt'라고 적힌 옷은 검색 결과에 나오지 않아 답답했던 적이 있으신가요? 혹은 데이터가 쌓일수록 검색창에 단어를 입력하고 엔터를 쳤을 때 모래시계만 뱅글뱅글 도는 것을 본 적이 있을 것입니다.일반적인 관계형 데이터베이스(RDB)에서 사용하는 'LIKE' 검색은 왜 느리고 한계가 명확한지, 그리고 이를 완벽하게 극복한 검색 엔진 '엘라스틱서치(Elasticsearch)'의 마법 같은 원리에 대해 알아보겠습니다. 1. 기존 RDB 검색의 한계와 엘라스틱서치의 철학우리가 흔히 쓰는 RDB의 LIKE 쿼리(예: LIKE '%셔츠%')는 치명적인 단점이 있습니다. 데이터베이스에 있는 수백만 개의 행(Row)을 처음부터 끝까지 하나하나 뒤져보는 '풀 스캔(..

[1일 1CS] 결제 버튼을 두 번 누르면 돈이 두 번 빠져나갈까? API 멱등성의 이해

사용자가 쇼핑몰에서 결제 버튼을 눌렀습니다. 그런데 로딩 화면만 빙글빙글 돌고 응답이 없어서, 답답한 마음에 결제 버튼을 한 번 더 눌렀습니다. 만약 이때 고객의 통장에서 돈이 두 번 빠져나간다면 어떻게 될까요?이런 끔찍한 대참사를 막기 위해 백엔드 개발자가 API를 설계할 때 반드시 고려해야 하는 핵심 개념이 바로 '멱등성(Idempotency)'입니다. 오늘은 멱등성이 무엇이며 어떻게 구현하는지 알아보겠습니다. 1. 멱등성이란 무엇인가?멱등성은 원래 수학에서 쓰이는 용어로, '연산을 여러 번 적용하더라도 결과값이 달라지지 않는 성질'을 뜻합니다. 1에 1을 아무리 여러 번 곱해도 결과가 1인 것과 같습니다.이 개념을 HTTP 웹 통신으로 가져오면 다음과 같이 정의할 수 있습니다."동일한 요청을 한 번..

[1일 1CS] 서버를 조종하는 해커의 함정: SSRF 공격과 방어 전략

웹 서비스의 규모가 커지고 클라우드 환경이 기본이 되면서, 해커들의 공격 방식도 점점 교묘해지고 있습니다. 애플리케이션 보안을 다루는 국제 비영리 단체 OWASP는 2021년 'Top 10 보안 취약점'에 새로운 공격 방식을 신규로 등재했습니다. 바로 서버를 해커의 꼭두각시로 만들어버리는 치명적인 취약점, SSRF(Server-Side Request Forgery, 서버 측 요청 위조)입니다. 1억 명의 고객 정보가 유출되었던 대형 금융사 해킹 사건의 원인이기도 한 SSRF 공격은 무엇이며 어떻게 막아야 하는지 알아보겠습니다. 1. SSRF 공격이란 무엇인가?SSRF 공격은 쉽게 말해 '공격자가 우리 서버를 조종해서, 서버가 대신 외부나 내부의 특정 주소로 요청을 보내게 만드는 해킹 기법'입니다.보통 해..

[1일 1CS] 리액티브 프로그래밍이란 무엇일까?

최근 스프링(Spring) 진영에서 웹플럭스(WebFlux)라는 단어가 자주 들려옵니다. 넷플릭스나 아마존처럼 엄청난 트래픽을 감당하는 기업들이 도입하면서 유명해진 개념인데요, 이 기술들의 근간이 되는 철학이 바로 '리액티브 프로그래밍(Reactive Programming)'입니다.단순히 코드를 작성하는 방법을 넘어, 데이터가 흘러가는 패러다임 자체를 완전히 뒤바꾼 리액티브 프로그래밍이 무엇인지 알아보겠습니다. 1. 기존 방식의 한계와 리액티브의 등장 배경과거의 시스템은 '동기 블로킹' 방식으로 일했습니다. 식당에서 종업원이 손님 A의 주문을 받고 요리가 나올 때까지 주방 앞에서 꼼짝 않고 기다리는 방식입니다. 손님이 적을 땐 괜찮지만, 대규모 트래픽이 몰리면 시스템 전체에 병목 현상이 발생합니다.이를 ..

[1일 1CS] 웹소켓 끊김 현상, 자동 재연결만으로 충분할까?

배달 앱에서 라이더의 위치가 실시간으로 움직이거나, 주식 호가창이 깜빡이는 것은 모두 웹소켓(WebSocket) 덕분입니다. 그런데 만약 지하철을 타면서 와이파이가 LTE로 바뀌는 찰나의 순간, 이 연결이 끊어진다면 어떻게 될까요? 대부분의 실시간 서비스는 연결이 끊어지면 자동으로 다시 연결을 시도합니다. 하지만 때로는 이 '자동 재연결'만으로는 부족해서 개발자가 직접 세밀하게 통제해야 하는 순간들이 찾아옵니다. 웹소켓 재연결의 중요성과 직접 로직을 구현해야 하는 상황에 대해 알아보겠습니다. 1. 튼튼한 다리도 가끔은 무너진다: 웹소켓이 끊어지는 이유웹소켓은 한 번 연결되면 계속 유지되는 특성이 있지만, 현실의 네트워크 환경은 생각보다 훨씬 불안정합니다.네트워크 환경 변화: 스마트폰이 와이파이 영역을 벗..

[1일 1CS] AI 시대에도 SOLID 원칙은 유효할까?

최근 챗GPT나 코파일럿 같은 AI가 개발자 대신 코드를 짜주는 시대가 되었습니다. 그러다 보니 개발자들 사이에서는 "어차피 AI가 코드를 다 짜주는데, 우리가 굳이 객체지향 설계나 SOLID 원칙 같은 복잡한 이론을 배워야 할까?"라는 의문과 불안감이 생겨나기 시작했습니다.과연 AI 시대에 좋은 코드에 대한 인간의 기준은 의미가 없어진 걸까요? 이 불안감을 해소하기 위해 진행된 아주 흥미로운 '블랙잭 게임 구현 실험' 결과를 통해, AI 시대에 SOLID 원칙이 가지는 진짜 가치를 알아보겠습니다. 1. SOLID 원칙 가볍게 짚어보기실험을 보기에 앞서, 객체지향 프로그래밍의 5대 원칙인 SOLID를 아주 간단히 복습해 보겠습니다.단일 책임 원칙 (S): 하나의 클래스는 오직 하나의 역할만 맡아야 한다...

[1일 1CS] HTTPS는 어떻게 보안과 속도를 모두 잡았을까? 대칭키와 비대칭키

개인 프로젝트를 만들 때 별다른 설정을 하지 않으면 웹 주소는 HTTP로 시작합니다. 하지만 이 HTTP 통신은 치명적인 단점이 있습니다. 우리가 주고받는 아이디, 비밀번호 같은 데이터가 '평문(우리가 읽을 수 있는 글자)' 그대로 인터넷 망을 돌아다닌다는 것입니다. 만약 누군가 중간에서 이 데이터를 가로채면 개인정보가 그대로 털리게 됩니다.이 위험을 막기 위해 데이터를 알 수 없는 문자로 뒤섞어 버리는 기술이 바로 암호화(HTTPS)입니다. 오늘은 이 암호화 기술이 어떻게 발전해 왔고, 현대의 웹은 어떻게 보안과 속도라는 두 마리 토끼를 모두 잡았는지 알아보겠습니다. 1. 세상에서 가장 빠른 자물쇠: 대칭키암호화의 가장 기본은 '대칭키' 방식입니다. 데이터를 잠글 때(암호화) 쓴 열쇠와, 잠금을 풀 때..

[1일 1CS] 프론트엔드 개발자의 주적, CORS 에러 완벽하게 이해하기

프론트엔드 개발을 하다 보면 누구나 한 번쯤 시뻘건 에러 메시지와 마주하게 됩니다. 분명히 백엔드 서버도 잘 켜져 있고 내 코드도 완벽한데, 브라우저 콘솔 창에 "Blocked by CORS Policy"라는 에러가 뜨면서 데이터 통신이 꽉 막혀버리는 현상입니다.개발자들을 당황하게 만드는 이 CORS 에러는 도대체 왜 발생하는 것이며, 어떻게 해결해야 할까요? 브라우저의 보안 정책이라는 관점에서 아주 쉽게 풀어보겠습니다. 1. 모든 것의 시작: SOP (동일 출처 정책)CORS를 이해하려면 먼저 브라우저의 기본 보안 규칙인 SOP(Same-Origin Policy, 동일 출처 정책)를 알아야 합니다.쉽게 말해 브라우저는 아주 깐깐한 아파트 경비 아저씨와 같습니다. "우리 아파트 주민(같은 출처)이 아니면..