클라이밍하는 개발자

이번에는 거대한 모놀리식 서버를 잘게 쪼개는 마이크로서비스(MSA) 아키텍처를 도입했을 때 관리자가 반드시 맞닥뜨리게 되는 최대 난제이자, 이를 해결하는 우아한 방법론인 분산 트랜잭션과 Saga 패턴에 대해 알아보겠습니다."결제 서버에서 돈은 빠져나갔는데, 재고 서버가 죽어서 물건은 못 받는 상황"을 어떻게 수습할 것인가에 대한 이야기입니다.1. 과거의 평화: 모놀리식과 ACID 트랜잭션과거 모든 기능이 하나의 서버와 하나의 DB에 뭉쳐있던 시절(모놀리식)에는 데이터 관리가 참 편했습니다. 데이터베이스가 제공하는 강력한 트랜잭션(Transaction) 기능 덕분이었죠.상황: [1. 주문 생성] ➔ [2. 결제 완료] ➔ [3. 재고 차감]문제 발생: 3번 재고 차감 중에 에러가 터졌습니다!해결 (Roll..

1. CI/CD란 무엇인가?CI/CD는 두 가지 개념이 합쳐진 단어입니다. 목적은 단 하나, "개발자가 코드 작성(비즈니스 로직)에만 집중하게 만들자!" 입니다.🛠️ CI (Continuous Integration, 지속적 통합)의미: 개발자들이 짠 코드를 수시로, 자동으로 합치고(Merge) 검증하는 과정입니다.과거의 지옥: 10명의 개발자가 한 달 동안 각자 코드를 짜다가 마지막 날에 합치려다 보니 충돌(Conflict)이 엄청나게 나서 며칠 밤을 새웁니다. (머지 지옥)CI의 해결책: 하루에도 몇 번씩 코드를 메인 저장소(GitHub)에 올리게 합니다. 코드가 올라올 때마다 서버가 알아서 코드를 빌드해 보고, 자동화된 테스트(Unit Test)를 실행합니다. 버그가 있으면 바로 "삐빅! 방금 올린..

1. 전통적 아키텍처의 한계: "DB가 왕이 된 세상"기존에 가장 많이 쓰던 방식은 계층형 아키텍처(Controller ➔ Service ➔ Repository ➔ DB)였습니다. 초기에는 개발하기 아주 편했지만, 서비스가 커지면서 치명적인 단점이 발생합니다.문제점: 기획자가 "결제 취소 로직을 바꿔주세요"라고 하면, 개발자는 비즈니스 로직(Service)부터 생각하는 게 아니라 "DB(Repository) 쿼리를 어떻게 짜야 하지?"부터 고민합니다.결과: 핵심 비즈니스 로직이 데이터베이스(DB)라는 특정 기술에 꽉 종속되어 버립니다. 나중에 MySQL을 MongoDB로 바꾸려고 하면 비즈니스 로직 코드까지 싹 다 갈아엎어야 하는 대참사가 일어납니다.2. 도메인 주도 설계 (DDD): "비즈니스가 왕이다..

1. 아키텍트의 악몽: SPOF (단일 장애점)SPOF (Single Point of Failure)란 시스템 구성 요소 중에서 "이 녀석 하나만 고장 나면 시스템 전체가 마비되는 치명적인 약점"을 말합니다.상황: 웹 서버는 오토 스케일링으로 10대로 빵빵하게 늘려두었습니다. 그런데 트래픽을 나눠주는 '로드 밸런서'가 딱 1대뿐입니다.재앙: 웹 서버 10대가 아무리 멀쩡해도, 그 앞단의 로드 밸런서 1대의 전원이 나가는 순간 사용자는 서비스에 아예 접속할 수 없게 됩니다. 이때 로드 밸런서가 바로 SPOF입니다.설계의 제1원칙: 훌륭한 아키텍처에는 단 하나의 SPOF도 존재해서는 안 됩니다.2. 해결책: 고가용성 (High Availability, HA)SPOF를 없애고 시스템이 항상 정상적으로 작동하게..

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. 동작 과정: "잠깐 나갔다 올..