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-07-24 02:46

전체 (167)

2d

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

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

000

2d

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

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

000

2d

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

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

000

2d

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

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

000

2d

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

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

000

2d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

4d

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

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

000

4d

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

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

000

4d

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

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

000

5d

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

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

000

5d

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

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

000

5d

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

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

000

5d

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

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

000

5d

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

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

000

5d

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

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

000

5d

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

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

001

5d

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

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

000

5d

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

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

000

5d

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

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

000

6d

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

6d

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

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

002

6d

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

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

000

6d

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

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

000

6d

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

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

000

6d

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

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

001

6d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

9d

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

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

000

10d

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

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

000

10d

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

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

000

10d

dbt Incremental · Snapshot: 증분 모델과 SCD 이력 관리

들어가며
3단계에서 매크로와 Jinja로 SQL을 프로그래밍하는 법을 익혔습니다. dbt가 SQL을 컴파일 시점에 생성한다는 사실, 그리고 {% if %} 분기로 상황에 따라 다른 SQL을 만들어낼 수 있다는 사실을 손에 쥐었죠.

000

10d

dbt 매크로 · Jinja: SQL을 프로그래밍하기

들어가며
1단계에서 모델과 ref()가 세우는 의존성 그래프를, 2단계 — dbt 테스트 · 문서화에서 그 그래프 위에 신뢰를 얹는 법을 봤습니다. 이번 3단계는 dbt SQL이 일반 SQL보다 강력한 근본 이유를 파고듭니다. 지

000

11d

Airflow 배포와 운영: KubernetesExecutor · 모니터링 · 로깅

들어가며
지금까지 다섯 단계에 걸쳐 우리는 파이프라인을 선언하는 법(DAG·오퍼레이터, 스케줄러·Executor 내부, XCom·TaskFlow)과 견고하게 만드는 법(센서·deferrable, 백필·catchup·멱등)을 익혔습

000

11d

Airflow 백필 · Catchup · 멱등: 재실행해도 안전한 파이프라인

들어가며
4단계에서 센서와 deferrable 오퍼레이터로 외부 상태를 효율적으로 기다리는 법을 익혔습니다. 이제 견고함의 나머지 절반, 어쩌면 더 중요한 절반을 다룰 차례입니다 — 재실행입니다.
파이프라인은 반드시 다시 돌게 됩

000

11d

Airflow 센서 · Deferrable 오퍼레이터: 외부 상태를 효율적으로 기다리기

들어가며
지금까지 이 시리즈에서 다룬 것은 모두 “우리가 통제하는 세계” 안의 이야기였습니다. DAG를 코드로 선언하고, 스케줄러가 큐에 넣고, Executor가 실행하고, XCom으로 데이터를 넘기고 — 모든 등장인물이 Airf

000

11d

Airflow XCom · TaskFlow API: 태스크 사이로 데이터 흘리기

들어가며
1단계에서 파이프라인을 DAG로 선언했고, 2단계 — 스케줄러 · Executor 내부에서 그 선언이 무엇에 의해 어떻게 실행되는지를 봤습니다. 거기서 확인한 사실 하나가 이번 글의 출발점입니다. 각 task instan

000

11d

Airflow 스케줄러 · Executor 내부: 무엇이 언제 task를 실행하는가

들어가며
1단계에서 우리는 파이프라인을 DAG·오퍼레이터·태스크로 선언하는 법을 익혔습니다. 그런데 파이썬 파일에 DAG를 써 두었다고 해서 무언가가 저절로 돌아가는 것은 아닙니다. 그 선언을 읽고, “지금 이 시점에 실행해야 할

000

11d

Airflow DAG · 오퍼레이터 · 태스크: 파이프라인을 코드로 선언하기

들어가며
Airflow의 모든 것은 한 줄로 요약됩니다 — 파이프라인은 파이썬 코드다. GUI에서 박스를 끌어다 놓는 대신, 개발자는 “무엇을, 어떤 순서로, 언제 실행할지”를 파이썬 파일 하나에 선언합니다. 그 선언의 문법이 바

000

12d

dbt Essential Curriculum: 애널리틱스 엔지니어링 심화 로드맵

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 5단계 데이터 변환·처리(Processing)에서 우리는 처리를 “엔진으로 옮기는 일”(Spark 같은

000

12d

Stream Processing Essential Curriculum (Apache Flink) — 스트림 처리 심화 커리큘럼

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 5단계 데이터 변환·처리(Processing)에서 우리는 스트림 처리를 다루며 이벤트 시간 vs 처리

000

12d

Spark Essential Curriculum

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 5단계 데이터 변환·처리(Processing)에서 우리는 분산 처리가 왜 MapReduce에서 Apac

000

12d

Lakehouse Essential Curriculum (Apache Iceberg) — 레이크하우스 에센셜 커리큘럼

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 4단계 데이터 저장(Storage)에서 우리는 데이터 웨어하우스·레이크·레이크하우스의 차이를 짚고, 레

000

12d

Kafka Essential Curriculum: 분산 로그부터 스트림 처리까지

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 3단계 데이터 수집(Ingestion)에서 우리는 원천 시스템의 데이터를 어떻게 안정적으로 가져오는지

000

12d

Airflow Essential Curriculum: 파이프라인 오케스트레이션 정복

소개
Data-Engineering-Essential 오버뷰 시리즈는 데이터 엔지니어링 수명주기 전체의 지도를 그렸습니다. 그 6단계 오케스트레이션(Orchestration)에서 우리는 수많은 수집·변환 작업을 언제·어떤 순서로·

000

18d

위로가 아니라 옆으로 — LLM이 가져온 새로운 추상화의 본질 (Martin Fowler)

원문 정보
제목: LLMs bring new nature of abstraction
출처: Martin Fowler (martinfowler.com)
발행: 2025-06-24 · 약 5~7분 분량, 소제목 없이 한 편의 짧은 에

000

18d

팀이 성공해야 개인이 성공한다 — 강한 팀은 오래 앉아 있어서 만들어지지 않는다

원문 정보
제목: 팀이 성공해야 개인이 성공한다
출처: w0nder.land (https://w0nder.land) · 개인 블로그
발행: 2026-03-21 · 약 6분 분량
원문 링크: https://w0nder.land/po

000

18d

짧은 목줄(Short Leash) 방법 — AI 코딩 에이전트를 통제하며 고품질 코드를 만드는 법 (Greg Slepak)

원문 정보
제목: The Short Leash AI Coding Method For Beating Fable
출처: Greg Slepak · okTurtles Blog (blog.okturtles.org)
발행: 2026-07-0

000

18d

“디자인 패턴” 소리 한 번만 더 들으면 미쳐버릴 것 같다 — 패턴이라는 용어를 향한 반론 (purplesyringa)

원문 정보
제목: If I hear “design pattern” one more time, I’ll go mad
출처: purplesyringa’s blog (purplesyringa.moe)
발행: 2025-09-04 · 약

000

18d

IDE의 죽음? — 편집기에서 ‘에이전트 오케스트레이터’로 옮겨 가는 개발의 중심 (Addy Osmani)

원문 정보
제목: Death of the IDE?
출처: Addy Osmani · Elevate (addyo.substack.com)
발행: 2026-03-20 · 약 8~10분 분량
원문 링크: https://addyo.subs

000

21d

AI 네이티브 채용의 철학: 코딩 테스트가 죽은 시대에 무엇을 평가할 것인가 (Musinsa · Tao Kim, ‘The Philosophy: AI Native Hiring’)

원문 정보
제목: The Philosophy: AI Native Hiring (AI 네이티브 채용 시리즈 3부작 Part 1)
출처: 무신사 기술블로그 (techblog.musinsa.com) · 저자 Tao Kim
발행: 202

000

21d

YAGNI가 아낀 것은 타이핑이 아니었다 — 옵션과 NPV로 다시 읽는 YAGNI (Kent Beck)

원문 정보
제목: The Cost YAGNI Was Never About
부제: “If you think YAGNI is about saving effort, cheap generation should retire it. It d

000

21d

애자일에게 작별을 — 워터폴은 이미 1970년에 반박됐고, 스펙은 돌아오고 있다 (Saying Goodbye to Agile)

원문 정보
제목: Saying Goodbye to Agile
저자: Lewis Campbell
출처: 개인 블로그 (lewiscampbell.tech) · 약 5분 분량
원문 링크: lewiscampbell.tech/blog/26

000

21d

에이전틱 코딩은 함정이다 — 인지 부채와 스킬 위축을 경계하며 (Lars Faye)

원문 정보
제목: Agentic Coding is a Trap
부제: Remaining vigilant about cognitive debt and atrophy.
출처: Lars Faye (larsfaye.com)
발행: 202

000

22d

엔지니어링 리더십의 규칙을 다시 쓰다: AI가 바꾼 5가지 원칙 (Will Larson)

원문 정보
제목: Revised rules of engineering leadership
출처: Will Larson (lethain.com)
발행: 2026-06-15
원문 링크: https://lethain.com/revise

000

28d

CS336 17강 — 정렬 (3): 정책 경사와 GRPO 직접 구현

CS336-LLM-From-Scratch 시리즈의 17단계이자 마지막 강의입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (16강 — 정렬 (2): RLVR와 추론 모델에서 이어집니다.)
16강이 “무엇을 최적화하나

000

28d

CS336 16강 — 정렬 (2): RLVR와 추론 모델

CS336-LLM-From-Scratch 시리즈의 16단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (15강 — 정렬 (1): SFT와 RLHF에서 이어집니다.)
15강의 RLHF는 사람 선호를 학습한 보상 모

000

28d

CS336 15강 — 정렬 (1): SFT와 RLHF

CS336-LLM-From-Scratch 시리즈의 15단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (14강 — 데이터 (2)에서 이어집니다.)
여기서부터 유닛 5(정렬)가 시작됩니다. 유닛 1~4를 지나며 우

000

28d

CS336 14강 — 데이터 (2): 필터링·중복 제거·데이터 믹스

CS336-LLM-From-Scratch 시리즈의 14단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (13강 — 데이터 (1)에서 이어집니다.)
13강이 “무엇을 모으나”(출처·수집·추출)였다면, 14강은 “어

000

28d

CS336 13강 — 데이터 (1): 웹을 학습 코퍼스로, 그리고 저작권

CS336-LLM-From-Scratch 시리즈의 13단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (12강 — 평가에서 이어집니다.)
유닛 4의 다른 반쪽 — 데이터로 들어섭니다. 강의(Percy Liang)

000

28d

CS336 12강 — 평가(Evaluation): 하나의 참된 평가는 없다

CS336-LLM-From-Scratch 시리즈의 12단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (11강 — 스케일링 법칙 2에서 이어집니다.)
유닛 3(스케일링·추론)을 마치고 유닛 4(데이터 & 평가)로

000

28d

CS336 11강 — 스케일링 법칙 2: 실전 레시피와 muP

CS336-LLM-From-Scratch 시리즈의 11단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (10강 — 추론으로 잠시 빠졌던 스케일링 주제를, 9강에 이어 마저 다룹니다.)
스케일링 법칙의 두 번째이자

000

28d

CS336 10강 — 추론(Inference): KV 캐시와 메모리 한계의 게임

CS336-LLM-From-Scratch 시리즈의 10단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (9강 — 스케일링 법칙 1에서 이어집니다.)
스케일링에서 잠시 벗어나, 학습이 끝난 모델을 실제로 굴리는 이

000

28d

CS336 9강 — 스케일링 법칙 1: 작게 실험해 크게 예측하기

CS336-LLM-From-Scratch 시리즈의 9단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (8강 — 병렬화 2에서 이어집니다.)
유닛 3(스케일링 & 추론)이 시작됩니다. 상상해 봅시다 — 부자 친구가

000

28d

CS336 8강 — 병렬화 2: 텐서·파이프라인 병렬과 3D 병렬화

CS336-LLM-From-Scratch 시리즈의 8단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (7강 — 데이터 병렬에서 이어집니다.)
7강이 병렬화의 개념(데이터 병렬·ZeRO/FSDP)이었다면, 8강(P

000

28d

CS336 7강 — 병렬화 1: 데이터 병렬과 ZeRO/FSDP

CS336-LLM-From-Scratch 시리즈의 7단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (6강 — 커널과 Triton에서 이어집니다.)
지금까지는 GPU 한 장을 짜내는 이야기였습니다. 7강(Tats

000

28d

CS336 6강 — 커널과 Triton: 측정하고, 퓨즈하라

CS336-LLM-From-Scratch 시리즈의 6단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (5강 — GPU에서 이어집니다.)
5강이 “GPU가 어떻게 동작하나”였다면, 6강(Tatsunori Hashi

000

28d

CS336 5강 — GPU: 병목은 연산이 아니라 메모리다

CS336-LLM-From-Scratch 시리즈의 5단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (4강 — MoE에서 이어집니다.)
유닛 2의 후반, 시스템 강의가 시작됩니다. GPU는 언어 모델을 굴러가게

000

28d

CS336 4강 — Mixture of Experts: 연산은 그대로, 파라미터만 키우기

CS336-LLM-From-Scratch 시리즈의 4단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (3강 — 아키텍처에서 이어집니다.)
2025년 현재, 최고 성능의 오픈·클로즈드 모델 상당수가 Mixture

000

28d

CS336 3강 — 아키텍처와 하이퍼파라미터: 현대 트랜스포머의 합의

CS336-LLM-From-Scratch 시리즈의 3단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (2강 — 자원 회계에서 이어집니다.)
이 강의(Tatsunori Hashimoto)의 제목은 “LM 아키텍처와

000

28d

CS336 2강 — PyTorch와 자원 회계: 6ND와 메모리를 냅킨에 계산하기

CS336-LLM-From-Scratch 시리즈의 2단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다. (1강 — 토크나이제이션에서 이어집니다.)
1강이 “효율”이라는 코스의 주제를 선언했다면, 2강은 그 효율을 측

000

28d

CS336 1강 — 개요와 토크나이제이션: BPE를 밑바닥부터

CS336-LLM-From-Scratch 시리즈의 1단계입니다. 전체 지도는 CS336 커리큘럼에서 볼 수 있습니다.
언어 모델은 이제 API 한 줄로 부르는 블랙박스가 되었습니다. CS336은 그 블랙박스를 열어 밑바닥부터(fr

000

28d

CS336: 밑바닥부터 만드는 언어 모델 — Essential Curriculum

소개
대형 언어 모델(LLM)은 이제 API 한 줄로 호출하는 블랙박스가 되었습니다. 하지만 그 안에서 토큰이 어떻게 잘리고, 어텐션이 어떻게 계산되며, 수천 장의 GPU가 어떻게 한 모델을 나눠 학습하고, 데이터와 정렬이 모델의

000

28d

스타트업의 진짜 문제는 번레이트가 아니라 의사결정이다 (The Next Web)

원문 정보
제목: Startups don’t have a burn problem, they have a decision problem
출처: The Next Web (https://thenextweb.com)
발행: 미상 (원문

000

29d

DataOps·운영·신뢰성: 데이터 시스템을 소프트웨어처럼 운영하기

들어가며
여기까지 오면서 우리는 데이터를 모으고(수집), 쌓고(저장), 다듬고(변환), 흘려보내고(서빙), 믿을 수 있게(품질·거버넌스) 만드는 법을 차례로 익혔습니다. 그런데 한 가지 질문이 남습니다 — 그렇게 만든 파이프라인을

000

29d

데이터 품질·거버넌스·관측가능성: 믿을 수 있는 데이터 만들기

들어가며
새벽 2시에 도는 파이프라인이 모든 잡을 성공으로 마치고, Airflow의 DAG는 초록색으로 빛납니다. 오케스트레이터는 “이상 없음”을 보고합니다. 그런데 아침 9시, 임원 대시보드의 매출이 절반으로 뚝 떨어져 있습니다

000

29d

사례별 파이프라인 설계: 실시간 분석·이벤트·ML 피처·CDC

들어가며
지금까지 이 시리즈는 데이터 엔지니어링의 부품을 하나씩 익혀 왔습니다. 수명주기라는 사고의 틀, ETL→ELT·레이크하우스로 이어진 진화의 맥락, 그리고 수집·저장·변환·오케스트레이션·아키텍처 패턴까지. 그런데 실무에서

000

29d

데이터 아키텍처 패턴: Lambda·Kappa·Medallion·Data Mesh

들어가며
지금까지 이 시리즈에서 수집·저장·변환·오케스트레이션이라는 개별 부품을 하나씩 살펴봤다면, 이번 글은 그 부품들을 어떻게 조립할 것인가를 다룹니다. 같은 Kafka, 같은 Spark, 같은 레이크하우스를 쓰더라도, 그것들

000

29d

오케스트레이션(Orchestration): DAG·스케줄링과 견고한 파이프라인

들어가며
데이터 파이프라인은 결코 하나의 작업으로 끝나지 않습니다. 원천에서 데이터를 끌어오고, 저장소에 적재하고, 변환하고, 품질을 검증한 뒤, 마트로 서빙하고, 어쩌면 모델 학습까지 — 수십, 수백 개의 작업이 정해진 순서와

000

29d

데이터 변환·처리(Processing): 배치·스트림 엔진과 SQL 변환

들어가며
앞 단계에서 우리는 데이터를 어디에 어떤 형태로 쌓을지(저장)를 다뤘습니다. 그런데 raw 상태로 쌓아 둔 데이터는 그 자체로는 쓸모가 적습니다. 타입이 제각각이고, 결측치가 섞여 있으며, 여러 원천이 따로 놀고, 비즈니

000

29d

데이터 저장(Storage): 웨어하우스·레이크·레이크하우스와 파일·테이블 포맷

들어가며
수집(Ingestion) 단계를 지난 데이터는 어딘가에 쌓여야 합니다. 그런데 “쌓는다”는 한 단어 뒤에는 생각보다 많은 결정이 숨어 있습니다. 데이터 웨어하우스에 넣을 것인가, 레이크에 부을 것인가, 둘을 합친 레이크하

000

29d

데이터 수집(Ingestion): 배치·스트리밍·CDC와 수집 도구

들어가며
수명주기에서 수집(Ingestion)은 원천 시스템에서 데이터를 실제로 끌어와 우리 영역으로 들이는 단계입니다. 1단계에서 살펴봤듯 데이터 엔지니어링의 가장 큰 병목이 자주 발생하는 지점이기도 합니다. 원천은 우리가 통제

000