Orc Hwang님 글 목록 - mysetting

Orc Hwang

Daejeon, Korea

Joined on 2021년 05월 12일

3:26 5/23

wiki.orchwang.dev

mobile screenshot relative

3:26

wiki.orchwang.dev

mobile screenshot

Orc’s WIKI
https://wiki.orchwang.dev

최종 피드 수집: 2026-09-09 12:16

전체 (218)

2d

브라운필드의 코끼리: 기존 조직의 AI 전환을 막는 것은 기술이 아니라 정체성이다 (Subbu Allamaraju)

원문 정보
제목: The Elephant in the Brownfield
출처: Subbu Allamaraju — 『RESTful Web Services Cookbook』 저자이자 기술 리더십 에세이스트 (subbu.org)
발행

000

2d

모든 글에 AI를 쓰면서도 AI 슬롭을 만들지 않는 법 (Ahrefs)

원문 정보
제목: How We Use AI for Every Article Without Making AI Slop
출처: Si Quan Ong, Ahrefs Blog (ahrefs.com)
발행: 2026-08-28 · 약 9분

000

2d

GPT-6 Astra: 하니스가 곧 제품이다 (Few-Shot Academy, Mangat Rai)

원문 정보
제목: GPT-6 Astra: the harness is the product
출처: Few-Shot Academy, Mangat Rai (fewshotacademy.com)
발행: 2026-09-04 · 약 8분 분량

000

2d

코드가 나빠지는 데에는 바닥이 없다 (Zach Kehs)

원문 정보
제목: There’s No Limit to How Bad Code Can Get
출처: Zach Kehs (zachkehs.com)
발행: 2026-09-04 · 짧은 에세이 (약 5분 분량)
원문 링크: https:/

000

2d

브라우저의 메인 스레드는 비싸다 — 아껴 쓰기와 안 쓰기의 성능 전략

원문 정보
제목: 브라우저의 메인 스레드는 비싸다
출처: kciter (개인 블로그, kciter.so)
발행: 2026-07-12 · 약 15~20분 분량
원문 링크: https://kciter.so/posts/the-expen

000

2d

AI가 인시던트를 처리할수록 엔지니어는 시스템과 멀어진다 (Sylvain Kalache)

원문 정보
제목: AI handles incidents, engineers lose touch with their systems
출처: Sylvain Kalache (sylvainkalache.com)
발행: 2026-09-04

000

3d

Design It!: 개발자에서 아키텍트로 (팀과 함께 설계하는 실전)

들어가며
이 글은 Architecture-Essential 시리즈의 5단계입니다. 전체 학습 지도는 Architecture Essential Curriculum에서 다시 확인할 수 있습니다.
4단계 The Software Arch

000

8d

orchwang/dotfiles: macOS·Ubuntu·Omarchy를 같은 손맛의 터미널 작업장으로 맞추기

프로젝트 소개
orchwang/dotfiles는 내가 매일 쓰는 터미널 개발 환경을 코드로 관리하는 저장소다. 겉으로 보면 zsh, tmux, nvim, git, ghostty 설정을 모아 둔 평범한 dotfiles repo처럼

001

10d

의도 부채 갚기: AGENTS.md를 ‘의도 원장’으로 다시 쓰는 법

📌 이 글에서 다루는 내용
🔍 핵심 주제
의도 부채 재정의: “누가 왜 이렇게 만들었는가”가 사람 머릿속에만 있는 상태, 그리고 그것이 에이전트 시대에 가장 비싸지는 이유
인지 체크리스트: 지금 이 프로젝트에 의도 부채가 얼마

000

15d

외로운 산의 산중 왕국, 에레보르: 황금이 세우고 황금이 무너뜨린 도시

소개
앞 편의 로슬로리엔이 살아 있는 나무 위로 올라간 엘프의 도시였다면, 이번 에레보르(Erebor) 는 그 반대 방향으로 지어진 도시입니다. 드워프는 나무를 타지 않았습니다. 대신 거대한 산 하나를 통째로 파고 들어가, 그 돌

002

15d

황금 나무의 도시, 카라스 갈라돈: 시간이 멈춘 로슬로리엔

소개
앞 편의 아이센가드가 살아 있는 나무를 모조리 베어 화로와 갱도를 지은 도시였다면, 이번 로슬로리엔(Lothlórien) 은 그 정반대편에 있는 도시입니다. 이곳 사람들은 나무를 베지 않았습니다. 대신 거대한 나무 위로 올라

002

15d

쇠의 고리, 아이센가드: 마음이 금속과 바퀴가 될 때

소개
앞 편의 에도라스가 나무와 풀로 지은 ‘살아 있는’ 도시였다면, 이번 아이센가드(Isengard) 는 그 반대편 극단입니다. 한때 이곳도 나무와 호수가 있는 초록 골짜기의 요새였지만, 마법사 사루만의 손에서 연기와 쇠와 불의

002

15d

황금궁전의 언덕, 에도라스: 초원 위에 선 기마민족의 도시

소개
곤도르의 흰 돌을 실컷 본 뒤 로한의 수도 에도라스(Edoras) 에 이르면, 마치 다른 세계에 온 듯한 인상을 받습니다. 여기에는 일곱 겹의 성벽도, 첨탑도 없습니다. 대신 초록 초원 한가운데 솟은 언덕 위에, 황금빛으로

002

15d

별들의 요새, 오스길리아스: 강 위에 무너진 곤도르의 심장

소개
곤도르를 떠올릴 때 대부분 미나스 티리스의 흰 탑을 먼저 그리지만, 곤도르의 처음이자 진짜 심장은 따로 있었습니다 — 오스길리아스(Osgiliath), ‘별들의 요새’입니다. 지금은 강 위에 흩어진 폐허로 남았지만, 한때 이

003

15d

요술의 탑, 미나스 모르굴: 시체빛에 잠긴 어둠의 쌍둥이

소개
톨킨의 세계에서 가장 아름다우면서 가장 소름 끼치는 도시를 하나 꼽으라면 미나스 모르굴(Minas Morgul) 일 것입니다. 프로도와 샘이 모르도르로 잠입하며 이 골짜기를 지날 때, 도시는 멀리서 시체처럼 창백한 빛을 뿜으

002

15d

경비의 탑, 미나스 티리스: 일곱 겹의 흰 도시

소개
『반지의 제왕』에서 인간의 마지막 큰 도시를 하나만 꼽으라면 단연 미나스 티리스(Minas Tirith) 입니다. ‘경비의 탑’이라는 이름 그대로, 이 도시는 검은 땅 모르도르를 정면으로 마주 본 채 서쪽 세계를 지키는 최후

000

15d

에워두른 산맥의 숨은 도시, 곤돌린: 완벽한 은신을 무너뜨린 하나의 배신

소개
앞 편들에서 우리는 아만의 요정들이 빛을 등지고 망명을 떠나, 첫 동족살해의 피와 만도스의 저주를 짊어진 채 중간계로 건너온 과정을 보았습니다. 이번 곤돌린(Gondolin) 은 그 놀도르가 중간계에 세운 도시들 가운데 가장

001

15d

백조의 항구, 알콸론데: 가장 아름다운 배 위에 흐른 첫 동족의 피

소개
앞 편 티리온에서 요정들은 두 나무의 빛을 등지고 망명을 결심했습니다. 이번 알콸론데(Alqualondë) 는 그 발걸음이 곧바로 첫 피를 부른 현장입니다. 바다를 사랑한 요정 텔레리가 진주로 지은 이 아름다운 항구에서, 요

000

15d

투나 언덕의 하얀 도시, 티리온: 빛을 향해 세우고, 빛을 등지고 떠나다

소개
앞 편의 발마르가 두 나무의 빛을 값없이 흘려보내던 신들의 도시였다면, 이번 티리온(Tirion) 은 그 빛을 좇아 요정들이 세운 첫 도시입니다. 발라들의 초대로 축복의 땅 아만에 건너온 요정들은, 두 나무의 빛이 가장 잘

002

16d

Stage 7 · 실전 통합 — AIR 파이프라인 · concurrency 종합 · Job 간 동시성

한눈에 보기
지금까지 배운 Ray의 기능(Core·Data·Train·Tune·Serve)을 하나의 엔드투엔드 파이프라인으로 조립해 마무리합니다. 이게 바로 Ray AIR(AI Runtime)의 비전 — “같은 파이썬 코드가 노트

000

16d

Stage 6 · Ray Serve 서빙 — 로컬 모델 배포 · 스케일/동시성

한눈에 보기
Stage 5에서 학습한 모델을 실제로 서비스하는 단계입니다. Ray Serve는 모델을 HTTP 엔드포인트로 배포하는 도구로, 공식적으로 “local first” — 배포 전에 로컬에서 전체 deployment gr

001

16d

Stage 6 · 실전 통합 — 웹 크롤러 · 워커 풀 · 비동기 I/O

한눈에 보기
마지막 단계입니다. 1~5단계에서 배운 동시성 기초 → 경량 스레드/고루틴 → 병렬화 → 동기화 → 통신을 하나의 실전 문제에 통합합니다.
프로젝트: “대량 URL 크롤러” — 수천 개의 URL에서 페이지 제목과 본문

000

16d

악의 계보와 두 개의 보석: 모르고스에서 사우론으로, 실마릴에서 절대반지로

소개
지금까지 우리는 세계가 어떻게 태어났고(1·2단계), 어떤 시대를 거쳤으며(3단계), 누가 살아가고(4단계) 어디에서 벌어지는지(5단계)를 보았습니다. 마지막으로 남은 질문은 하나입니다 — 무엇과 싸우는가?
톨킨 세계의 악은

002

16d

Stage 5 · 통신 — Queue · Pipe · Channel · select

한눈에 보기
4단계의 락은 “공유 상태를 보호”하는 방식이었습니다. 이번 단계는 다른 철학인 “메모리를 공유하지 말고, 메시지를 주고받자(Communication)” 를 다룹니다. 작업을 메시지로 나눠 주고받으면, 공유 상태를 거

000

16d

세계의 무대: 축복의 땅 아만에서 제3시대 중간계까지

소개
세계관에서 지리는 단순한 배경이 아닙니다. 톨킨에게 땅의 배치는 곧 의미의 배치입니다 — 서쪽에는 신성과 불멸이, 동쪽과 남쪽에는 필멸과 위험이 놓입니다. 엘프가 늘 서녘을 그리워하고, 악이 늘 동·남쪽에서 밀려오는 것은 우

001

16d

Stage 5 · Ray Train 분산 학습 — 데이터 샤딩 · 체크포인트

한눈에 보기
Stage 3에서 데이터를 샤딩하는 법을 배웠다면, 이 단계는 학습 자체를 워커에 분산하는 Ray Train입니다. 핵심 통찰은 — 각 워커가 데이터의 서로 다른 “샤드”를 받고, 자기 샤드로 모델을 학습한다 는 것입

001

16d

Stage 4 · Ray Tune 튜닝 — 하이퍼파라미터 자동화

한눈에 보기
머신러닝을 하다 보면 “learning_rate를 몇으로, 깊이는 얼마로” 하는 하이퍼파라미터를 만지게 됩니다. 이걸 하나하나 손으로 돌리면 시간 낭비가 큽니다. Ray Tune은 이 탐색을 코어 수만큼 병렬로 자동화

001

16d

불멸과 필멸 사이: 엘프·인간·드워프·호빗, 그리고 오르크의 기원

소개
판타지에 익숙한 독자에게 엘프·드워프·오르크는 낯익은 얼굴입니다. 오늘날 거의 모든 판타지가 이 종족들을 등장시키니까요. 하지만 그 원형이 바로 톨킨이고, 톨킨의 종족은 클리셰가 아니라 신학입니다. 각 종족은 “뾰족귀에 활을

001

16d

Stage 4 · 동기화 — Lock · Semaphore · Deadlock

한눈에 보기
3단계에서 본 counter++ 데이터 레이스가 이 단계의 출발점입니다. 병렬로 실행되는 여러 스레드/고루틴이 같은 값을 동시에 읽고 쓰면 경쟁해 잘못된 결과가 나옵니다. 이를 막는 기법이 동기화(Synchroniza

000

23d

프로덕트 역할의 새로운 정의: AI가 도구를 공짜로 만들어도 남는 것 (Marty Cagan)

원문 정보
제목: A Fresh Definition of The Product Role
출처: Silicon Valley Product Group (SVPG) · Marty Cagan (svpg.com)
발행: 2026-08-10

002

23d

엔지니어링 리더의 하루는 무엇으로 채워지는가 — 눈에 보이지 않는 매니저의 6단계 사이클

원문 정보
제목: Engineering Leaders Day-to-Day Activities
출처: Effective Engineering Leaders · James Samuel (softwareleads.substack.com

001

23d

고밀도 인재 팀을 만드는 채용 플레이북 — Cursor 채용 총괄 Adam Ward (Lenny’s Podcast)

원문 정보
제목: The playbook for building high talent density teams
출처: Lenny’s Podcast · 게스트 Adam Ward (Head of Talent, Cursor) (yout

002

27d

젠슨 황이 말하는 ‘오픈 에이전트 시스템’: 하니스가 회사의 운영체제가 되는 미래 (LangChain 대담)

원문 정보
제목: Jensen Huang: Why companies need open agent systems
출처: LangChain (YouTube 채널) · 해리슨 체이스(Harrison Chase, LangChain CEO

001

28d

The Mythical Man-Month: 개념적 무결성과 맨먼스 신화 (Brooks)

왜 50년 전 책을 지금 읽는가
Fred Brooks의 The Mythical Man-Month는 1975년에 나왔다. 저자가 IBM에서 OS/360이라는 당대 최대의 소프트웨어 프로젝트를 이끌며 겪은 실패와 교훈을 16편(초판

001

29d

코드가 아니라 아이디어를 통제하라 — antirez가 말하는 AI 시대 프로그래머의 몫

원문 정보
제목: Control the ideas, not the code
출처: antirez (Salvatore Sanfilippo, Redis 창시자) — antirez.com
발행: 2026-07 (게시 시점 기준 약 29

000

1M

취향과 판단, 그리고 AI — 에이전트가 못 가져가는 것은 ‘이름을 거는 일’이다 (Addy Osmani)

원문 정보
제목: Taste, Judgment and AI
출처: Addy Osmani (Google Chrome 엔지니어링 리더 · x.com/addyosmani)
발행: 2026년 · 약 6분 분량
원문 링크: https://

001

1M

가장 빠른 AI-first 회사는 어떻게 일하는가: 조직도를 ‘미션 팟’으로 다시 짜다 (NFX)

원문 정보
제목: How The Fastest AI-First Companies Really Work
출처: NFX / Gigi Levy-Weiss (nfx.com)
발행: 2026-07 · 약 8~10분 분량
원문 링크: htt

003

1M

자동화하지 말고 파괴하라: AI가 전문성의 문지기를 걷어내는 방식 (USV)

원문 정보
제목: Obliterate, Don’t Automate
출처: Union Square Ventures (USV) 블로그 (blog.usv.com)
발행: 2026-07-22 · 약 4분 분량
원문 링크: https://

001

1M

무엇이 하니스를 하니스로 만드는가: 에이전트 하니스의 필요충분조건 (Sandeco Macedo)

원문 정보
제목: What makes a harness a harness: necessary and sufficient conditions for an agent harness
출처: Sanderson Oliveira de Mac

001

1M

프롬프트는 언제 ‘그래프’가 되는가: Prompt Graph Engineering의 필요충분조건 (Sandeco Macedo)

원문 정보
제목: What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
출처: Sandeco Macedo (Sande

001

1M

리팩터링의 경제적 이점: AI가 짠 코드를 정리하면 토큰 비용이 83% 줄었다 (Giles Edwards-Alexander)

원문 정보
제목: The Economic Benefit of Refactoring
출처: martinfowler.com — “Exploring Gen AI” 시리즈 · 저자 Giles Edwards-Alexander (Though

000

1M

Opus 5로 그래프 메모리를 싸게 짓는 법 — 프롬프트 캐싱·effort 분리·배치로 짜는 정확한 설정 (rody)

원문 정보
제목: How to Do Graph Engineering With Opus 5 (Exact Config Inside)
출처: rody (@0x_rody) · X(트위터) 스레드
발행: 2026-07-27 · 약 6분 분

000

1M

모호한 의견에서 본질을 찾기: 문제 정의와 Principal Engineer의 사고 방식

📌 이 글에서 다루는 내용
🔍 핵심 주제
본질을 찾는 능력의 정체: 상대의 말을 이해하는 게 아니라, 상대가 표현하지 못한 생각을 재구성하는 능력
증상과 원인의 분리: “검색이 불편해요”가 정말 검색 문제인지, 정보 구조 문제

000

1M

성능·운영·트러블슈팅 (지연·대역폭 · 패킷 분석 · CDN · 관측)

들어가며
이 글은 Network-Essential 시리즈의 7단계(마지막)입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 네트워크 보안 (TLS · 방화벽 · VPN · 위협 모델

000

1M

네트워크 보안 (TLS · 방화벽 · VPN · 위협 모델)

들어가며
이 글은 Network-Essential 시리즈의 6단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 응용 계층 (HTTP/HTTPS · DNS · DHCP · 웹 요청

001

1M

응용 계층 (HTTP/HTTPS · DNS · DHCP · 웹 요청의 여정)

들어가며
이 글은 Network-Essential 시리즈의 5단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 전송 계층 (TCP · UDP · 포트 · 소켓)을 먼저 읽으면 좋

000

1M

전송 계층 (TCP · UDP · 포트 · 소켓)

들어가며
이 글은 Network-Essential 시리즈의 4단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 네트워크 계층 (IP · 서브네팅 · 라우팅 · NAT · ICMP

000

1M

네트워크 계층 (IP · 서브네팅 · 라우팅 · NAT · ICMP)

들어가며
이 글은 Network-Essential 시리즈의 3단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 링크 계층 (Ethernet · MAC · 스위칭 · ARP)을 먼

001

1M

네트워크 링크 계층 (Ethernet · MAC · 스위칭 · ARP)

들어가며
이 글은 Network-Essential 시리즈의 2단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인하고, 직전 단계 계층 모델 (OSI 7계층 · TCP/IP 4계층 · 캡슐화)을 먼

000

1M

네트워크 계층 모델 (OSI 7계층 · TCP/IP 4계층 · 캡슐화)

들어가며
이 글은 Network-Essential 시리즈의 1단계입니다. 전체 흐름은 Network Essential Curriculum에서 확인할 수 있습니다.
네트워크를 어려워하는 가장 흔한 이유는 “모든 것이 동시에 벌어진다

000

1M

Network Essential Curriculum: 계층 모델부터 성능·운영까지

소개
컴퓨터 네트워크는 백엔드·데이터·인프라·보안 어디를 가든 발밑에 깔린 공용 기반입니다. API가 느릴 때, 배포한 서비스에 접속이 안 될 때, HTTPS 인증서가 깨질 때, 방화벽 뒤의 서버가 응답하지 않을 때 — 결국 답은

000

1M

Flink SQL: dynamic table·stream-table 이원성·continuous query·changelog

도입 — 왜 SQL로 끝내는가
이 시리즈는 1단계 스트림 처리 모델에서 시작해 2단계 이벤트 시간·워터마크, 3단계 상태·체크포인트, 4단계 exactly-once, 5단계 윈도잉·조인·CEP까지 다섯 단계를 거쳤습니다. 모두 낮

000

1M

Flink 윈도잉·조인·CEP: 텀블링/슬라이딩/세션·window join·interval join·CEP 패턴

들어가며
Stream Processing Essential Curriculum의 5단계입니다. 시리즈는 이 단계에 이르러 비로소 “무엇을 계산할 것인가”의 표현력을 손에 넣습니다. 앞선 1단계 — 스트림 처리 모델에서 무한 스트림

000

1M

Flink exactly-once: 전달 보장 3종·2PC 트랜잭셔널 싱크·end-to-end 정확성

도입 — “장애가 나도 결과가 정확한가”
스트림 처리의 가장 무서운 질문은 이것입니다 — 장애가 난 뒤에 다시 돌려도, 결과는 한 번 처리한 것과 같아야 한다. 정확성이 없는 스트림 처리는 재처리가 불가능하고, 재처리가 불가능한

001

1M

Flink 상태와 체크포인트: keyed/operator state·백엔드·Chandy-Lamport 스냅샷

도입 — 왜 스트림에는 상태가 필요한가
배치 처리는 매 실행이 독립적입니다. 같은 잡을 다시 돌리면 처음부터 다시 계산합니다 — 입력은 어차피 다 모였고, 상태는 디스크의 결과로 충분히 표현되기 때문입니다. 반면 스트림 처리는 무

000

1M

Flink 이벤트 시간·워터마크: out-of-order·지각 데이터·allowed lateness

도입 — 왜 “처리 시간”이 아니라 “이벤트 시간”인가
1단계에서 잡은 Flink의 실행 모델은 데이터가 어떻게 흐르고 어디서 실행되는가를 다뤘습니다. 그 모델 위에서 이제 다뤄야 할 질문은 더 미묘합니다 — “이 흐르는 데이터를

000

1M

Flink 스트림 처리 모델: 무한 스트림·데이터플로우 그래프·연산자 병렬성

도입 — 왜 스트림 처리에는 별도의 모델이 필요한가
배치 처리는 “끝이 있는(bounded) 데이터”를 다룹니다. 입력 파일이 다 모이면 처리를 시작하고, 결과를 다 쓰면 작업이 끝납니다. 시작점과 끝점이 분명한, 그래서 일반 함

001

1M

Agentic KG 직접 구축 + 도메인별 활용 사례: 코퍼스에서 에이전트까지

들어가며
이 글은 Agentic Knowledge Graph Curriculum의 8단계이자 시리즈의 피날레입니다. 1~7단계에서 우리는 조각들을 하나씩 벼렸습니다 — 왜 그래프인지(1), 어떻게 저장·질의하는지(2), 어떻게 짓

000

1M

Agentic Knowledge Graph: 그래프를 도구이자 기억으로, temporal KG

들어가며
이 글은 Agentic Knowledge Graph Curriculum의 7단계이자 이 시리즈의 심장입니다. 지금까지 우리는 그래프를 짓고(4단계), 검색하고(5단계), 예측·추론했습니다(6단계). 이 모든 것을 지금까지

000

1M

그래프 임베딩과 추론: node embedding·link prediction·다중 홉

들어가며
이 글은 Agentic Knowledge Graph Curriculum의 6단계입니다. 지금까지 우리는 그래프를 짓고(4단계) 읽었습니다(5단계). 이 글은 한 걸음 더 나아가, 그래프에서 예측하고 추론합니다 — 아직 그

000

1M

GraphRAG: 벡터 RAG의 한계를 그래프로 메우다 — local vs global

들어가며
이 글은 Agentic Knowledge Graph Curriculum의 5단계입니다. 1단계에서 벡터 DB가 “의미가 비슷한 조각”은 잘 찾지만 연결에는 약하다는 점을 짚었고, 4단계에서 LLM으로 그래프를 짓는 법을

001

1M

데이터가 당신의 유일한 해자다: 채택 난이도로 나눈 AI 앱 2x2 지형도 (The AI Frontier)

원문 정보
제목: Data is Your Only Moat: How different adoption models drive better applications
출처: The AI Frontier — Vikram Sreekanti

000

1M

온톨로지 vs 도메인 주도 설계(DDD): 같은 뿌리, 다른 층

들어가며
이 글은 Ontology-Essential 시리즈의 심화·비교편입니다. 전체 학습 지도는 Ontology Essential Curriculum에서 확인할 수 있습니다.
시리즈를 따라오며 온톨로지를 배우다 보면, 소프트웨어

000

1M

기술적으로 뛰어난 데이터 팀이 실패하는 이유: Data-Perspective-Action 3층 모델 (Goutham Budati)

원문 정보
제목: Why Technically Excellent Data Teams Still Fail
출처: Goutham Budati, Practical Data Community (practicaldatacommunity.s

000

1M

거버넌스·진화와 FDE 워크플로: 버전·권한·도메인 협업

들어가며
6단계 액션과 운영 계층에서 우리는 온톨로지를 읽는 모델에서 행동하는 시스템으로 바꿨습니다. 객체와 링크 위에 액션과 write-back이 얹히는 순간, 온톨로지는 대시보드가 아니라 업무 시스템이 됩니다. 그런데 업무 시

001

1M

액션과 운영 계층: 읽기 모델을 행동의 시스템으로 (write-back)

들어가며
5단계에서 원천 데이터를 백킹 데이터셋으로 빚고 엔티티 해소를 거쳐 신뢰할 만한 객체 그래프를 세웠습니다. 이제 온톨로지는 조직의 현실을 꽤 정확하게 비추는 거울이 되었습니다. 고객이 누구인지, 주문이 어떤 제품을 담는지

000

1M

소스 데이터를 온톨로지로: 백킹 데이터셋과 엔티티 해소

들어가며
3단계에서 객체 타입과 속성으로 도메인의 명사를 세우고, 4단계에서 링크 타입으로 그 명사들을 그래프로 이었습니다. 화이트보드 위의 온톨로지는 이제 꽤 우아합니다 — Customer가 Order를 내고, Order가 Pr

000

1M

링크 타입과 관계: 관계를 일급 개념으로, 카디널리티와 그래프 탐색

들어가며
3단계에서 우리는 도메인의 명사 — 고객·주문·제품 — 를 객체 타입으로 승격하고 속성과 기본키를 입혔습니다. 그런데 객체만 나열된 온톨로지는 아직 온톨로지가 아닙니다. 명함첩일 뿐입니다. “이 고객이 어떤 주문을 냈는가

000

1M

객체 타입과 속성: 엔티티를 객체로, 기본키와 객체 그래프

들어가며
커리큘럼의 첫 두 단계에서 우리는 “왜”와 어휘를 갖췄습니다. 온톨로지는 스키마가 아니라 의미 계층이고, 그 밑에는 지식 그래프·RDF/OWL·속성 그래프라는 형식 기반이 있다는 것 — 여기까지가 “의미를 이해하기”였습니

000

1M

형식 기반과 그래프: 지식 그래프 · RDF/OWL · 속성 그래프

들어가며
1단계에서 우리는 온톨로지가 무엇이며 왜 필요한지를 세웠습니다 — 스키마가 “데이터를 어떻게 저장하는가”라면, 온톨로지는 “그 데이터가 무엇을 의미하는가”를 담는 공유된 의미 계층이라는 것. 그런데 이 발상은 Palant

001

1M

온톨로지란 무엇인가: 데이터 모델·스키마와 의미 계층의 차이

들어가며
데이터 엔지니어링의 언어로 조직을 보면, 조직은 테이블의 집합입니다. customers, orders, order_items — 잘 정규화된 스키마, 무결성이 걸린 외래키, 밤마다 도는 파이프라인. 그런데 그 테이블들을

001

1M

Ontology Essential Curriculum: FDE를 위한 온톨로지 기반 데이터 모델링

소개
데이터 엔지니어링이 “데이터를 어떻게 옮기고 저장하고 처리하는가”의 문제라면, 온톨로지 기반 데이터 모델링은 “그 데이터가 무엇을 의미하는가“의 문제입니다. 테이블과 컬럼, 조인 키는 기계가 이해하는 구조일 뿐, 그 자체로는

000

1M

Orc Camp: tmux 위의 코딩 에이전트들을 픽셀 캠프로 관제하기

프로젝트 소개
Orc Camp는 여러 tmux 세션의 pane에서 실행 중인 LLM 코딩 에이전트(Claude Code · Codex 등)를 한 화면에서 관제하기 위해 만든 tmux 기반 로컬 CLI 도구다. 저장소는 GitHub

000

1M

Graph Engineering: Loop Engineering 다음, 에이전트의 일을 그래프로 설계하라

주요 출처
이 글은 한 편의 아티클 분석이 아니라, 2026년 상반기 Reddit·Hacker News·엔지니어링 블로그에서 “loop engineering 다음” 으로 반복 등장하는 graph engineering 흐름을 조사해

000

1M

Mitchell Hashimoto 인터뷰: 터미널, Zig, 그리고 오픈소스의 자유 (Alex Alejandre)

원문 정보
제목: Interview With Mitchell Hashimoto
출처: Alex Alejandre 개인 블로그 (alexalejandre.com)
발행: 2026-07 · 약 12분 분량
원문 링크: https://

000

1M

데이터 품질은 ‘사다리’다: Pivotal의 On Data Quality (1) 기본기 읽기

원문 정보
제목: On Data Quality — The Fundamentals (연재 1편: Basics)
출처: Pivotal · Abraham Thomas (pivotal.substack.com)
발행: 2026-06-27

002

1M

사용자가 10배 늘었다, 서버부터 사면 될까 — 증설 전에 측정하라

원문 정보
제목: 사용자가 10배 늘었다. 일단 서버부터 사면 되나요?
출처: velog · 코헤(@gusdudco6) (velog.io)
발행: 2026-07 · 약 8분 분량
원문 링크: https://velog.io/@gus

000

1M

우리는 도둑처럼 한몫 챙길 것이다: AI가 만든 기술 부채와 시니어 개발자의 몸값 (Simon M. Stewart)

원문 정보
제목: We’re Going to Make Out Like Bandits
출처: Simon M. Stewart, 개인 블로그 (rocketpoweredjetpants.com)
발행: 2026-04-12 · 약 8분 분량

001

1M

AI 2040: Plan A — 초지능을 2040년까지 늦추자는 ‘검증된 감속’ 시나리오 (AI Futures Project)

원문 정보
제목: AI 2040: Plan A
출처: AI Futures Project — Thomas Larsen, Romeo Dean, Brendan Halstead, Eli Lifland, Ryan Greenblatt, Da

000

1M

에이전트에게 얼마나 맡길 것인가 — Martin Fowler의 Fragments (7월 13일)

원문 정보
제목: Fragments: July 13
출처: Martin Fowler (martinfowler.com)
발행: 2026-07-13 · 짧은 단편(fragment) 모음, 약 8~10분 분량
형식: 긴 아티클이 아니라

000

1M

좋은 도구는 보이지 않는다 — 도구를 정체성으로 삼지 말라 (gingerBill)

원문 정보
제목: Good Tools Are Invisible
출처: gingerBill (Bill Hall, Odin 프로그래밍 언어 창시자) — gingerbill.org
발행: 2026-07-10 · 약 6분 분량
원문 링크

001

1M

Iceberg vs Delta vs Hudi vs Paimon: 오픈 테이블 포맷 비교

들어가며
Lakehouse Essential Curriculum의 7단계이자 마지막 단계입니다. 여기까지 오면서 우리는 Iceberg 하나를 축으로 여섯 개의 렌즈를 손에 넣었습니다 — 왜 파일 위에 테이블 계층이 필요한가(문제의

000

1M

Iceberg REST Catalog · 거버넌스: 카탈로그 표준과 접근 제어

들어가며
지금까지 이 시리즈는 줄곧 “파일 위의 메타데이터”를 이야기했습니다. 그런데 한 가지 질문을 계속 미뤄 왔습니다 — db.orders라는 이름을 치면, 엔진은 어느 metadata.json이 이 테이블의 ‘현재’인지 어떻

000

1M

Iceberg compaction · 유지보수: 작은 파일 문제와 스냅샷 만료

들어가며
Lakehouse Essential Curriculum의 5단계이자, 시리즈 제3막 “어떻게 운영·선택하나”의 첫 관문입니다. 앞선 네 단계에서 우리는 Iceberg 테이블이 무엇을 할 수 있는지를 배웠습니다 — 메타데이

000

1M

Iceberg 파티션 진화 · 스키마 진화: 재작성 없는 진화

들어가며
3단계에서 우리는 Iceberg가 메타데이터 포인터 스왑으로 원자적 커밋을, 스냅샷 이력으로 시간여행을 얻는 것을 봤습니다. 그런데 이 능력들은 사실 Delta Lake나 Hudi도 각자의 방식으로 제공합니다. Lakeh

000

1M

Iceberg ACID · 스냅샷 · 시간여행: 트랜잭션과 스냅샷 격리

들어가며
2단계에서 우리는 Iceberg 테이블의 뼈대를 손에 넣었습니다 — 테이블의 상태는 metadata.json 파일 하나이고, 그 아래로 매니페스트 리스트·매니페스트·데이터 파일이 매달린다. 그리고 그 모든 파일은 한 번

001

1M

Iceberg 메타데이터 · 매니페스트 구조: 스냅샷 · 매니페스트 · 데이터 파일 계층

들어가며
1단계에서 우리는 문제를 정리했습니다 — 오브젝트 스토리지에 Parquet를 쌓는 것만으로는 테이블이 되지 않고, 디렉터리 listing에 의존하는 Hive 방식은 원자성도 일관성도 성능도 보장하지 못한다는 것. 그리고

000

1M

오픈 테이블 포맷의 문제의식: 왜 파일 위에 테이블 계층이 필요한가

들어가며
오브젝트 스토리지는 데이터 엔지니어링의 승리한 저장소입니다. 사실상 무한한 용량, GB당 몇 센트의 비용, 99.999999999%(9가 11개)의 내구성 — S3에 Parquet 파일을 쌓는 것보다 싸고 튼튼하게 데이터

000

1M

Kafka Streams: 스트림 DSL · 상태 저장 · KTable

들어가며
Kafka Essential Curriculum의 6단계이자 마지막 단계입니다. 지금까지 우리는 로그가 어떻게 저장되는지(1단계 — 분산 로그·토픽·파티션), 어떻게 쓰고 병렬로 읽는지(2단계 — 프로듀서/컨슈머·컨슈머

000

1M

Schema Registry: Avro/Protobuf · 스키마 진화 · 호환성

들어가며
4단계 Kafka Connect에서 Debezium 커넥터를 설정할 때, 우리는 value.converter=io.confluent.connect.avro.AvroConverter와 value.converter.schem

000

1M

Kafka Connect: CDC · Debezium으로 시스템 잇기

들어가며
앞의 세 단계에서 우리는 Kafka 안쪽을 다뤘습니다 — 커밋 로그가 무엇을 어떻게 저장하는지, 프로듀서와 컨슈머 그룹이 어떻게 쓰고 병렬로 읽는지, 그리고 전달 보장을 어떻게 확보하는지. 이번 단계의 질문은 방향이 다릅

000

1M

Kafka 전달 보장: at-least-once · exactly-once · 멱등 프로듀서 · 트랜잭션

들어가며
Kafka로 파이프라인을 짜다 보면 반드시 이 질문에 부딪힙니다 — “이 메시지, 유실되지는 않나요? 중복되지는 않고요?” 그리고 이 질문에 “Kafka는 exactly-once를 지원합니다”라고 한 줄로 답하는 순간,

000

1M

Kafka 프로듀서 · 컨슈머 · 컨슈머 그룹: 병렬 소비와 오프셋

들어가며
1단계에서 우리는 Kafka의 뼈대를 세웠습니다 — Kafka는 파티션 단위 append-only 커밋 로그이고, 오프셋이 각 레코드의 좌표이며, 복제와 ISR이 내구성을 지킨다는 그림입니다. 그런데 그 그림에는 아직 등

000

1M

Kafka 분산 로그 · 토픽 · 파티션: 커밋 로그 모델과 파티셔닝

들어가며
Kafka를 처음 만나면 대개 “메시지 큐의 일종”으로 소개받습니다. 그런데 이 비유는 절반만 맞고, 나머지 절반이 훨씬 중요합니다 — Kafka는 큐가 아니라 append-only 분산 커밋 로그입니다. 큐에서는 메시지

000

1M

dbt 세만틱 레이어 · 메트릭: MetricFlow로 지표 표준화

들어가며
지금까지 다섯 단계에 걸쳐 우리는 dbt로 신뢰할 수 있는 변환 그래프를 세우는 법을 익혔습니다. 모델·ref·소스로 DAG를 그리고, 테스트·문서화로 신뢰를 얹고, 매크로·Jinja로 반복을 없애고, incrementa

000

1M

dbt 패키지 · CI: Slim CI와 팀 규모 배포

들어가며
지금까지 네 단계에 걸쳐 우리는 dbt를 혼자서 잘 쓰는 법을 익혔습니다. 모델과 ref()로 의존성 그래프를 세우고, 테스트·문서로 신뢰를 얹고, 매크로·Jinja로 반복을 없애고, 4단계 dbt Incremental

000