전체 아키텍처

🖥️

Client-Server

전통적인 요청-응답 모델

클라이언트가 서버에 요청(Request)을 보내면, 서버가 처리 후 응답(Response)을 반환하는 가장 기본적인 통신 구조

🔌

WebSocket

양방향 실시간 통신

HTTP 핸드셰이크 후 TCP 연결을 유지하며, 서버와 클라이언트가 자유롭게 메시지를 주고받는 전이중(full-duplex) 통신 프로토콜

📨

SSE (Server-Sent Events)

서버→클라이언트 단방향 스트림

HTTP 연결을 유지하며 서버가 클라이언트에 이벤트를 단방향으로 스트리밍하는 방식. text/event-stream 형식 사용

💎

GraphQL Subscription

GraphQL 스키마 기반 실시간 이벤트

GraphQL의 subscription 타입을 통해 클라이언트가 특정 이벤트를 구독하고, 서버가 데이터 변경 시 자동으로 업데이트를 전달하는 방식

🪝

Webhook

이벤트 발생 시 HTTP 콜백

이벤트가 발생하면 사전에 등록된 URL로 HTTP POST 요청을 보내는 역방향 API 호출 방식

📡

Publish-Subscribe

메시지 브로커를 통한 비동기 통신

발행자(Publisher)가 메시지를 토픽에 발행하면, 해당 토픽을 구독한 모든 구독자(Subscriber)에게 메시지가 전달되는 방식

📬

Message Queue

큐를 통한 비동기 작업 처리

생산자(Producer)가 메시지를 큐에 넣으면, 소비자(Consumer)가 순서대로 꺼내 처리하는 점대점(point-to-point) 비동기 통신 방식

🔗

Peer-to-Peer (P2P)

중앙 서버 없이 직접 통신

각 노드가 클라이언트이자 서버 역할을 하며, 중앙 서버 없이 노드 간 직접 데이터를 교환하는 방식

🚀

QUIC vs WebRTC: 왜 QUIC으로 돌아왔나?

WebRTC의 복잡함에 지쳐 QUIC으로 전환한 실전 사례

Google이 만든 UDP 기반 전송 프로토콜 QUIC. TCP+TLS를 하나로 합쳐 0-RTT 연결, 스트림 독립성, Connection Migration을 제공. 원격 데스크톱 같은 실시간 스트리밍에서 WebRTC보다 단순하면서도 강력한 대안

📶

WiFi CSI로 위치 분석은 어떻게 동작하나?

단일 WiFi 신호의 물리 계층 데이터를 레이더처럼 활용

WiFi 신호의 CSI(Channel State Information)를 분석하여, 카메라 없이 사람의 위치·움직임·호흡·심박까지 감지하는 기술. 각 서브캐리어의 진폭과 위상 변화로 밀리미터 수준의 공간 정보를 추출

🦷

블루투스가 노출하는 당신의 정보들

BLE 신호만으로 생활 패턴·위치·행동이 추적되는 원리

블루투스를 켜두는 것만으로도 MAC 주소, 기기명, 제조사, BLE 서비스 UUID 등이 끊임없이 브로드캐스트됨. 라즈베리파이 하나로 주변 사람의 출퇴근 패턴, 택배 도착 시점, 집 비는 시간대까지 파악 가능

⚙️

WebAssembly(WASM)는 어떻게 동작하나?

C++/Rust/Zig 코드를 브라우저에서 네이티브 속도로 실행

WebAssembly(WASM)는 C++, Rust, Zig 등으로 작성된 코드를 바이트코드로 컴파일해 브라우저에서 네이티브에 가까운 속도로 실행하는 기술. JavaScript로는 불가능한 고성능 연산(이미지/비디오 처리, 3D 렌더링, 터미널 파서 등)을 웹에서 구현 가능

🏆

WASM을 웹의 1급 언어로 만들기

JS glue 없이 Web API를 직접 호출하는 Component Model

2017년 출시 이후 WASM은 웹에서 "2급 시민" — DOM/console 등 Web API에 직접 접근할 수 없고 반드시 JS glue code를 거쳐야 함. Mozilla가 제안한 Component Model은 WIT로 API를 선언하고 JS 없이 직접 호출을 가능하게 하여, WASM을 브라우저의 1급 실행 환경으로 격상시키려는 시도

NEW

🎮

WebGPU — 브라우저가 로컬 GPU를 직접 쓰는 방법

WebGL의 후속, Vulkan/Metal/DX12 수준의 저수준 GPU API가 브라우저에 들어왔다

WebGPU는 브라우저에 내장된 JavaScript API로, 웹페이지가 로컬 GPU 하드웨어에 직접 접근할 수 있게 한다. WebGL의 후속이며 OS별로 Vulkan/Metal/DirectX 12에 매핑된다.

📐

설계도 패턴 비교

SVG, Mermaid, draw.io, D2, Excalidraw — 어떤 방식으로 그릴 것인가

아키텍처 다이어그램을 그리는 5가지 대표적 방식을 비교. 코드 기반(Mermaid, D2, PlantUML) vs GUI 기반(draw.io, Excalidraw) vs 직접 렌더링(SVG/HTML+CSS). Git 관리, 협업, 자동화, 표현력 측면에서 각각의 트레이드오프를 정리

🌍

DNS 도메인 설정은 어떻게 반영되나?

onamae.com 같은 사이트에서 도메인 설정하면 실제로 어떤 일이 일어나는가

DNS(Domain Name System)는 도메인명(예: example.com)을 IP 주소(예: 93.184.216.34)로 변환하는 인터넷의 전화번호부. onamae.com 같은 레지스트라에서 도메인을 설정하면 루트 서버 → TLD 서버 → 권한 네임서버 순으로 계층적으로 전파되어 전 세계에서 접속 가능해진다

⏳

네임서버 변경은 왜 24~72시간 걸리나?

네임서버(NS) 변경 시 전파가 느린 진짜 이유와 각 단계별 캐시 구조

네임서버 변경은 단순한 DNS 레코드 변경과 달리 TLD(.com/.net) 레벨의 캐시까지 갱신이 필요하다. TLD NS 레코드의 TTL이 보통 48시간이고, ISP 리졸버가 이를 캐시하므로 전 세계에 반영되기까지 24~72시간이 소요된다

🔒

DNS-PERSIST-01은 어떻게 동작하나?

Let's Encrypt의 지속적 DNS 인증 레코드로 반복 검증 제거

Let's Encrypt 인증서 발급 시 매번 DNS TXT 레코드를 변경해야 하는 DNS-01의 한계를 해결. _validation-persist. TXT 레코드에 CA 계정 정보를 한 번만 설정하면 이후 발급/갱신에 재사용

🏢

onamae.com은 DNS 제공 업체가 되려면?

ICANN 인증부터 Anycast 인프라까지, 도메인 레지스트라의 뒷면

onamae.com 같은 DNS 제공 업체(레지스트라)가 되려면 ICANN 인증, Anycast DNS 네트워크, EPP 프로토콜 구현, WHOIS/RDAP 데이터베이스, DDoS 방어 등 대규모 인프라와 규정 준수가 필요하다

🛒

도메인 구입의 흐름

TLD 선택부터 갱신 관리까지, 도메인 구매의 모든 단계

도메인 구매는 TLD 선택 → WHOIS 가용성 확인 → 레지스트라 선택 → 등록 (연락처 정보 + WHOIS Privacy) → DNS 초기 설정 → 갱신 관리의 순서로 진행된다. 도메인 라이프사이클, 프리미엄 도메인 시장, 도메인 도난 방지까지 포괄 해설

🔐

무료 HTTPS 서비스들의 원리

Let's Encrypt, Cloudflare, ACM이 무료 인증서를 제공하는 방법

ACME 프로토콜, 도메인 검증, CA 신뢰 체인, TLS 핸드셰이크 등 무료 HTTPS 서비스의 핵심 원리를 해부합니다

🚨

DNS 장애 사고 사례 모음

인터넷을 멈춘 대형 DNS 장애들과 교훈

Dyn DDoS, Facebook BGP 사고, Fastly 장애 등 주요 DNS 관련 장애 사례를 분석하고, 단일 장애점 방지를 위한 실무 교훈을 정리합니다

🚇

ngrok은 어떻게 동작하나?

리버스 터널로 로컬 서버를 인터넷에 노출

ngrok은 로컬 개발 서버를 공개 URL로 노출하는 터널링 서비스. 내 PC에서 ngrok 클라이언트가 ngrok 클라우드에 아웃바운드 연결을 열고, 외부 트래픽이 그 터널을 타고 로컬로 전달됨

💬

Slack Socket Mode는 어떻게 동작하나?

Webhook 없이 아웃바운드 WebSocket으로 이벤트 수신

Slack Bot이 공개 URL 없이 이벤트를 수신하는 방식. Bot 서버가 Slack에 WebSocket 연결을 먼저 열면, Slack이 그 연결을 통해 이벤트를 push. 방화벽 뒤에서도 동작

🤖

ChatGPT 스트리밍은 어떻게 동작하나?

SSE로 토큰 단위 실시간 응답 전달

ChatGPT가 답변을 한 글자씩 표시하는 비밀. OpenAI API가 SSE(Server-Sent Events)로 생성된 토큰을 즉시 스트리밍 전송하면, 클라이언트가 하나씩 받아 화면에 렌더링

🐙

GitHub Webhook은 어떻게 동작하나?

git push → HTTP POST → CI/CD 트리거

GitHub에서 코드 push, PR 생성 등 이벤트 발생 시, 사전에 등록한 URL로 HTTP POST를 보내 외부 시스템(CI/CD, 슬랙 알림 등)을 자동으로 트리거하는 방식

⚙️

Sidekiq는 어떻게 동작하나?

Redis 기반 백그라운드 잡 큐 시스템

Rails에서 무거운 작업(이메일 발송, 이미지 처리 등)을 백그라운드로 넘기는 시스템. 웹 프로세스가 Redis 큐에 잡을 넣으면, Sidekiq 워커 프로세스가 꺼내서 비동기 처리

📹

WebRTC는 어떻게 동작하나?

브라우저 간 직접 영상/음성/데이터 전송

브라우저끼리 중앙 서버 없이 영상통화, 화면공유, 파일전송을 하는 기술. 시그널링 서버로 연결 정보를 교환한 뒤, STUN/TURN으로 NAT를 뚫고 P2P 직접 연결

🔌

MCP는 어떻게 동작하나?

AI 모델과 외부 도구를 표준 방식으로 연결하는 오픈 프로토콜

MCP(Model Context Protocol)는 AI 모델(LLM)과 외부 도구·데이터 소스를 표준화된 방식으로 연결하는 오픈 프로토콜. Host(Claude 등)가 Client를 통해 MCP Server에 연결하면, Server가 DB·파일·API 등 외부 시스템을 AI에 노출

🔀

MCP Transport: stdio vs Streamable HTTP

로컬 개발과 클라우드 SaaS 배포의 차이

MCP는 두 가지 공식 transport를 지원: stdio(로컬)와 Streamable HTTP(원격/SaaS). 2025년 3월 도입된 Streamable HTTP로 SaaS 벤더가 MCP 서버를 클라우드에 배포하고 다수의 클라이언트가 접근 가능

🖥️

tmux는 어떻게 동작하나?

터미널 멀티플렉서로 세션 유지 & 분할

tmux는 하나의 터미널에서 여러 세션을 관리하는 터미널 멀티플렉서. 서버-클라이언트 구조로, SSH 연결이 끊겨도 세션이 유지되고 나중에 다시 attach 가능

🔀

Vercel Subdirectory Reverse Proxy는 어떻게 동작하나?

Next.js 도메인 아래 서브디렉토리로 외부 서버 콘텐츠를 통합하여 SEO 권위를 집중

negabaro.com(Vercel/Next.js)에서 /blog/* 경로를 Rails(DigitalOcean) 또는 Jekyll(GitHub Pages) 등 외부 서버로 리버스 프록시. 사용자에게는 단일 도메인으로 보이면서, 실제 콘텐츠는 별도 서버에서 렌더링. 백엔드 기술 스택에 무관하게 canonical/robots.txt/asset 절대 URL 설정으로 SEO 권위를 메인 도메인에 집중하는 구조

NEW

🐳

Docker 컨테이너의 내부 구조

Linux 네임스페이스부터 macOS 지원, GPU까지 — 10년간의 기술적 진화

2013년 등장한 Docker는 Linux 네임스페이스로 VM 없이 프로세스를 격리한다. CLI 뒤에는 수십 년간의 시스템 연구가 숨어 있고, macOS/Windows 지원을 위해 라이브러리 VMM이라는 역발상 아키텍처를 채택했다.

NEW

🐛

Keploy — eBPF로 트래픽을 가로채 API 테스트를 자동 생성하는 구조

eBPF가 커널에서 connect() 목적지를 몰래 바꿔치기하는 투명 프록시 패턴

keploy record로 앱을 감싸면, eBPF가 커널 레벨에서 모든 아웃바운드 연결의 목적지를 로컬 프록시로 리다이렉트한다. 앱은 모른다. 프록시가 프로토콜별로 트래픽을 파싱해서 테스트 케이스+Mock을 YAML로 뽑아낸다.

NEW

💀

Python .pth 파일을 이용한 서플라이 체인 공격 — LiteLLM 사례 분석

pip install만으로 전체 시스템이 탈취되는 공격 체인의 구조

2026년 3월, 월 9500만 다운로드의 Python 라이브러리 LiteLLM에 악성 코드가 주입되었다. .pth 파일이라는 Python의 잘 알려지지 않은 메커니즘을 악용해서 import 없이 설치만으로 시스템을 탈취하는 공격이다.

NEW

🏗️

좋은 시스템 설계란 — 눈에 띄지 않는 설계가 최고의 설계다

상태 관리, DB 설계, 캐싱, 이벤트 처리, 장애 복구까지 — 검증된 단순함의 힘

좋은 시스템 설계는 복잡해 보이지 않는다. 오랜 기간 별다른 문제가 발생하지 않고, "이 부분은 신경 쓸 필요 없다"는 반응이 나오면 성공이다. 상태를 저장하는 컴포넌트를 줄이고, 검증된 단순한 구조를 쓰는 게 핵심이다.

NEW

🎯

협업은 헛소리다 — 소수가 만들고, 다수가 회의한다

Brooks의 법칙, Ringelmann 효과, 그리고 협업 도구가 감추는 책임 확산의 구조

조직 내 실질적 성과는 소수가 만든다. 테크 업계는 이 문제에 '협업'을 처방했지만, 실제로는 조율 도구만 늘고 산출물은 나오지 않는 구조가 고착됐다. 진짜 필요한 건 협업 인프라가 아니라 개인의 주체적 판단과 책임(ownership)이다.

NEW

🧪

테스트 코드가 새로운 해자(Moat)가 되는 시대

AI 시대에 진짜 자산은 코드가 아니라 테스트 스위트다

AI가 코드를 한 줄도 안 보고 문서와 테스트만 학습해서 경쟁 제품을 1주일 만에 만들어내는 시대다. 코드는 더 이상 해자가 아니다. 진짜 자산은 수만 개의 엣지 케이스를 커버하는 테스트 스위트다.

NEW

🎬

FFmpeg — 25년간 미디어 세계를 지탱해온 스위스 아미 나이프

아키텍처, 코덱 추상화, 필터 체인, 하드웨어 가속까지 — FFmpeg의 내부 구조 해부

FFmpeg은 거의 모든 미디어 포맷을 디코딩·인코딩·변환·스트리밍할 수 있는 오픈소스 멀티미디어 프레임워크다. 2000년 Fabrice Bellard가 시작해 25년 넘게 개발이 이어지고 있다. YouTube, Netflix, Meta, VLC, OBS — 미디어를 다루는 거의 모든 곳에서 FFmpeg이 돌아간다.

NEW

📡

Meta의 FFmpeg 활용 — 하루 수백억 회, 대규모 미디어 처리의 비밀

내부 포크 폐기, 멀티레인 병렬 인코딩, 실시간 품질 메트릭, 자체 ASIC까지

Meta는 하루 수백억 회 FFmpeg을 실행한다. 오랫동안 내부 포크에 의존했지만, FFmpeg 커뮤니티와 협력해 멀티레인 병렬 인코딩과 실시간 품질 메트릭을 업스트림에 구현하고 내부 포크를 완전히 폐기했다. 자체 ASIC인 MSVP도 FFmpeg 표준 API로 통합했다.

NEW

📦

FFmpeg 버전별 변화 — 6.0에서 8.1까지, 무엇이 달라졌나

멀티스레딩 리팩토링, Vulkan 코덱, 하드웨어 가속 확대, 그리고 8.1 "Hoare"까지

FFmpeg 6.0부터 8.1까지 메이저 변화를 정리한다. Meta 기반의 멀티스레딩 리팩토링(6.0~8.0), Vulkan 하드웨어 코덱, 인루프 디코딩, 그리고 최신 8.1 "Hoare"의 xHE-AAC, D3D12, Rockchip 인코딩까지.

NEW

🎤

Nightingale 코드 분석 — Rust + ML로 만든 오픈소스 노래방 앱의 구조

Tauri 2 + Python ML 서버 + UVR/Demucs 음성 분리 + WhisperX 가사 동기화 + 실시간 피치 감지

Nightingale은 개인 음악 파일을 노래방으로 바꿔주는 오픈소스 앱이다. Rust(Tauri 2) 백엔드가 Python ML 서버를 내장 프로세스로 관리하고, UVR Karaoke 모델이나 Demucs로 보컬을 분리한다. WhisperX로 단어 단위 가사를 동기화하고, McLeod 알고리즘으로 실시간 피치를 감지한다.

NEW

✨

Sparkling — TikTok의 크로스 플랫폼 인프라

Lynx 엔진 위에서 실제 앱을 돌리기 위한 프로덕션 프레임워크

TikTok이 자사 앱에서 Lynx 엔진을 프로덕션 규모로 운용하기 위해 구축한 인프라 레이어를 오픈소스로 공개했다. React Native에 Expo가 필요하듯, Lynx 엔진 위에서 실제 앱을 운용하려면 빌드 파이프라인, 네이티브 브릿지, 내비게이션 같은 인프라가 필요하다. Sparkling이 그 갭을 메운다.

NEW

🐱

Lynx — TikTok의 크로스 플랫폼 UI 엔진

React처럼 쓰고, 네이티브로 렌더링

Lynx는 TikTok이 공개한 크로스 플랫폼 UI 렌더링 엔진이다. 웹 기술(React 유사 문법)로 코드를 작성하면 네이티브 렌더링으로 Android/iOS 화면을 그려준다. React Native와 비슷한 포지션이지만, TikTok 프로덕션에서 검증된 자체 렌더링 파이프라인을 갖고 있다는 게 차별점.

NEW

🤖

Agentic AI — 자율 에이전트의 기본 구조

LLM이 도구를 쓰고, 판단하고, 반복하는 구조

Agentic AI는 LLM이 단순히 텍스트를 생성하는 걸 넘어, 스스로 계획을 세우고 도구를 호출하며 목표를 향해 반복 실행하는 시스템이다. "챗봇"과 "에이전트"의 차이는 자율성이다. 챗봇은 질문에 대답하고, 에이전트는 목표를 향해 스스로 행동한다.

NEW

🔁

Agent Loop — 에이전트의 실행 루프 해부

while 루프 하나가 에이전트의 전부다

에이전트의 핵심은 "LLM을 루프 안에서 돌리는 것"이다. 한 번 호출하고 끝나는 게 아니라, 도구 호출 결과를 받아서 다시 LLM에 넘기고, LLM이 다음 행동을 결정하는 사이클. 이 루프를 어떻게 설계하느냐가 에이전트의 품질을 결정한다.

NEW

🔧

Tool Use 패턴 — LLM에 손과 발을 달아주기

함수 호출을 통해 LLM이 외부 세계와 상호작용하는 구조

LLM은 텍스트만 생성할 수 있다. 파일을 읽거나, API를 호출하거나, DB를 조회하려면 "도구"가 필요하다. Tool Use는 LLM에게 사용 가능한 함수 목록을 알려주고, LLM이 필요할 때 함수를 호출하게 하는 패턴이다.

NEW

😅

Ralph Wiggum Loop — 에이전트가 같은 삽질을 반복할 때

"I'm in danger" — 에이전트가 빠져나오지 못하는 루프의 원인과 대책

에이전트가 같은 에러에 같은 수정을 반복하고, 진전 없이 토큰만 태우는 상태. 심슨 가족의 Ralph Wiggum이 "I'm in danger"라고 하면서 멍하니 앉아있는 밈에서 따온 이름. AI 에이전트 개발에서 가장 흔하고 비용이 큰 안티패턴이다.

NEW

🤝

Human-in-the-Loop — 사람이 끼어드는 타이밍

완전 자율 vs 적절한 개입, 그 균형점

에이전트가 모든 걸 자동으로 하면 편하지만, 돌이킬 수 없는 행동(데이터 삭제, 프로덕션 배포, 결제)은 사람이 확인해야 한다. Human-in-the-Loop은 "언제 사람한테 물어볼 것인가"를 설계하는 패턴이다.

NEW

🔧

Harness(하네스)란 무엇인가

테스트 실행 환경에서 AI 에이전트까지, 대상을 감싸서 제어하는 시스템

Harness는 AI에 국한된 개념이 아니다. 원래 소프트웨어 공학의 Test Harness에서 온 것으로, "대상을 감싸서 제어하는 실행 환경" 전체를 뜻한다. AI 하네스든, 테스트 하네스든, 핵심은 같다 — 대상 자체보다 대상을 감싸는 시스템의 설계가 결과를 좌우한다.

NEW

⚖️

Harness Engineering vs Prompt Engineering

프롬프트를 잘 짜는 것과 실행 환경을 잘 짜는 것은 다르다

Prompt Engineering은 모델에게 "뭘 해라"를 잘 전달하는 기술이다. Harness Engineering은 모델이 "어떤 환경에서 실행되느냐"를 설계하는 기술이다. 같은 프롬프트라도 하네스가 다르면 결과가 완전히 달라진다.

NEW

🛡️

가드레일 설계 — 모델이 삽질하기 전에 막는 법

입력 필터, 출력 검증, 행동 제한으로 안전한 하네스 만들기

모델은 확률적으로 출력한다. 10번 중 9번 맞아도 1번은 틀린다. 가드레일은 그 1번이 프로덕션에서 터지지 않게 막는 안전장치다. 입력 단계, 실행 단계, 출력 단계 각각에 가드레일을 둔다.

NEW

📊

평가 파이프라인 — 하네스 품질을 측정하는 법

감으로 판단하면 진다, 자동화된 평가 체계가 필수다

하네스를 바꿨는데 좋아졌는지 나빠졌는지 모르면 의미가 없다. 평가 파이프라인은 하네스 변경의 효과를 정량적으로 측정하는 시스템이다. SWE-bench, HumanEval 같은 벤치마크도 결국 평가 파이프라인의 일종이다.

NEW

🧠

컨텍스트 윈도우 관리 — 유한한 기억의 전략

100만 토큰이어도 넣는 방법이 중요하다

컨텍스트 윈도우는 모델의 "작업 기억"이다. 크기가 커져도 무한하지 않고, 넣는 순서와 내용에 따라 성능이 달라진다. 하네스의 핵심 역할 중 하나가 이 제한된 공간을 효율적으로 관리하는 것이다.

NEW

🎼

오케스트레이션 패턴 — 모델 호출을 조합하는 법

한 번의 호출로 안 되면, 여러 번을 어떻게 엮는가

복잡한 작업은 모델 한 번 호출로 끝나지 않는다. 여러 모델 호출을 어떤 순서로, 어떤 조건에서 실행하느냐가 오케스트레이션이다. Agentic AI의 에이전트 루프도, RAG도, 코드 생성 파이프라인도 전부 오케스트레이션 패턴이다.

NEW

🏭

gstack 해부 — 하네스 엔지니어링 실전 사례

Garry Tan이 Claude Code로 60일간 60만 줄을 칠 수 있었던 구조

gstack은 Y Combinator CEO Garry Tan이 공개한 Claude Code 스킬 팩이다. 23개 slash command로 하나의 모델을 역할별 전문가 팀으로 분리한다. 같은 Claude인데 하네스를 바꿨을 뿐이다. 이게 하네스 엔지니어링의 위력이다.

NEW

🐛

Keploy — eBPF로 트래픽을 가로채 API 테스트를 자동 생성하는 구조

eBPF가 커널에서 connect() 목적지를 몰래 바꿔치기하는 투명 프록시 패턴

keploy record로 앱을 감싸면, eBPF가 커널 레벨에서 모든 아웃바운드 연결의 목적지를 로컬 프록시로 리다이렉트한다. 앱은 모른다. 프록시가 프로토콜별로 트래픽을 파싱해서 테스트 케이스+Mock을 YAML로 뽑아낸다.

NEW

🗂️

Git은 내부적으로 어떻게 동작하나?

Blob, Tree, Commit — Git의 3가지 객체

Git은 content-addressable 파일 시스템이다. 모든 파일과 디렉토리, 커밋은 SHA-1 해시로 식별되는 객체로 저장된다. Blob(파일), Tree(디렉토리), Commit(스냅샷) 세 가지 객체만 이해하면 Git의 대부분이 설명된다.

NEW

🔀

rebase vs merge, 언제 무엇을 쓰나

히스토리 보존과 선형화의 트레이드오프

merge는 두 브랜치를 merge commit으로 합친다. rebase는 커밋을 다른 베이스 위로 다시 쌓는다. merge는 히스토리를 있는 그대로 남기고, rebase는 선형으로 정리한다. 공유 브랜치에는 merge, 개인 브랜치에는 rebase가 기본 원칙이다.

NEW

↩️

reset vs revert, 뭘 언제 쓰나

히스토리를 고치는 법 vs 되돌리는 커밋을 추가하는 법

reset은 브랜치 포인터를 과거 커밋으로 옮긴다. revert는 반대 변경을 담은 새 커밋을 추가한다. 혼자 작업 중이면 reset, 이미 push한 커밋이면 revert가 안전하다.

NEW

📦

stash 제대로 쓰기

작업 중 브랜치 전환이 필요할 때

stash는 커밋하지 않은 변경을 임시 저장소에 밀어넣고 working tree를 깨끗하게 만든다. 브랜치 전환, cherry-pick, 긴급 bugfix 대응에 쓴다. checkout -- . / reset --hard 대신 stash를 쓰면 실수로 변경을 날릴 일이 없다.

NEW

🌲

worktree로 여러 브랜치를 동시에 체크아웃

clone 여러 번 안 해도 된다

git worktree는 같은 저장소를 여러 디렉토리에 각기 다른 브랜치로 체크아웃할 수 있게 해준다. clone을 여러 번 할 필요가 없고, .git 디렉토리는 공유되므로 용량도 절약된다. 긴 빌드가 도는 동안 다른 브랜치 작업을 병행할 때 진가가 나온다.