Orc’s WIKI - mysetting

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-22 13:17

전체 (167)

20h

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

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

000

20h

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

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

000

20h

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

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

000

20h

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

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

000

20h

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

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

000

20h

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

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

000

1d

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

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

000

1d

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

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

000

1d

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

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

000

1d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

000

3d

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

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

001