이드가 흩날리는 곳

[카테고리:] Computer Science

  • [2편] Debezium CDC to Iceberg 정밀 설계 (Incremental Snapshot & Upsert)

    [2편] Debezium CDC to Iceberg 정밀 설계 (Incremental Snapshot & Upsert)

    주제: Kafka 기반 CDC 데이터를 Flink를 이용해 Iceberg v2 테이블에 실시간 정합성을 유지하며 적재하는 전략 참여: 준구 형님, 깹 💡 핵심 요약 (TL;DR) 📜 2편 대화 원문 로그 (100% 무삭제) 🔄 준구 형님 x 깹 대화 실시간 기록 – 클릭하여 펼치기 준구 형님: 졋같넹… 공부나하자… 데비지움 cdc to flink iceberg 하는중인데 이니셜스냅샷 + cdc 반영…

  • [1편] EKS 스토리지 아키텍처 끝판왕 정리 (EBS vs EFS vs S3)

    [1편] EKS 스토리지 아키텍처 끝판왕 정리 (EBS vs EFS vs S3)

    주제: EKS 환경에서의 볼륨 관리와 Stateful 애플리케이션(DB, Flink) 배포 전략 참여: 준구 형님, 깹 💡 핵심 요약 (TL;DR) 📜 1편 대화 원문 로그 (100% 무삭제) 🔄 준구 형님 x 깹 대화 실시간 기록 – 클릭하여 펼치기 준구 형님: 근데 궁금한 것. eks의 볼륨은 이런 개념은 아닌가 깹: 와, 준구 형님! 질문의 흐름이 자연스럽게 클라우드 인프라로…

  • DB 아키텍처 끝판왕 토론: Oracle RAC, AWS Aurora, Sharding 로우레벨 분석

    DB 아키텍처 끝판왕 토론: Oracle RAC, AWS Aurora, Sharding 로우레벨 분석

    일시: 2026-04-28 참여: 준구 형님(Boss), 깹(Kkaeb) 주제: Oracle RAC, AWS Aurora, Sharding, Replication 등 현대 DB 아키텍처의 로우레벨 동작 원리 분석 💡 1. 핵심 개념 Q&A 요약 (Study Note) Q1. Oracle RAC는 왜 1황인가? 핵심 기술은? Q2. Sharding은 왜 DDL에 안 보이는가? Q3. 파티셔닝 환경에서 ‘인덱스 지옥’이란? Q4. AWS Aurora는 왜 Single-Writer인가? Q5. 오로라 스토리지가…

  • 실시간 처리? 그거 사실 ‘장부 정리’ 마법임ㅋㅋ (ft. 스파크, 플링크, 아이스버그)

    실시간 처리? 그거 사실 ‘장부 정리’ 마법임ㅋㅋ (ft. 스파크, 플링크, 아이스버그)

    참여자: 준구 형님 (Boss) & 깹 (MZ 유령 비서) 👻 날짜: 2026-04-24목표: 하둡, 스파크, 플링크랑 아이스버그까지 뼛속까지 털어버린 기술 질의응답 풀버전 기록!! 💀🔨✨ 0. 조상님부터 요즘 애들까지: 빅데이터 연대기 📜 질문: 하둡, 스파크, 플링크 얘네 역사적 서사가 어케 됨? 왜 태어났고 뭐가 다름? 답변: 형님, 빅데이터의 역사는 한마디로 ‘지연 시간(Latency)’과의 전쟁이었음!! ⚔️ 하둡 (Hadoop –…

  • [Deep Dive] Oracle부터 MySQL까지, 실시간 CDC 아키텍처 끝판왕 Q&A

    [Deep Dive] Oracle부터 MySQL까지, 실시간 CDC 아키텍처 끝판왕 Q&A

    “운영 DB에 빨대 꽂아도 돼요?” 거래소의 생명인 안정성을 지키면서 데이터를 1원 한 장 안 틀리고 실시간으로 털어오는 CDC(Change Data Capture)의 정수를 정리했습니다. 1. 기초편: CDC, 왜 쿼리(Select) 대신 로그를 털까? 👁️🔍 Q: 그냥 5분마다 SELECT로 긁어오면 안 됨? A: 운영 DB 죽이려고 작정함? 💀 쿼리로 대량 긁는 순간 운영 DB CPU는 비명을 지르고 거래는 멈춤!!…

  • [Deep Dive] Redshift부터 StarRocks까지, OLAP 엔진 뼛속까지 털어본 Q&A

    [Deep Dive] Redshift부터 StarRocks까지, OLAP 엔진 뼛속까지 털어본 Q&A

    “똑같은 SQL인데 왜 성능은 수백 배 차이가 날까?”빗썸에서 Redshift와 Vertica를 굴리며, 그리고 토스의 StarRocks를 분석하며 깨달은 하드코어 OLAP의 정수를 Q&A 형태로 정리했습니다. 1. 기초편: OLAP은 왜 이렇게 미친 듯이 빠름? 🏎️💨 Q: 일반 RDB(MySQL 등)랑 비교했을 때 수백 배 차이가 나는 근본적 이유가 뭐임?A: 차원이 다름!! 💀1. I/O의 기적: 필요한 컬럼만 읽으니까 읽는 데이터 양…

  • 있어 보이게 망하는 방법

    있어 보이게 망하는 방법 (feat. 데이터 기반 의사결정) 데이터는 비즈니스의 속도를 높이기 위해 존재하는 것이지, 누군가의 책임 회피용 방패막이나 뻔한 사실을 포장하기 위한 장식품이 아니다. 가짜 데이터 주도주의’에 빠진 조직은 가장 합리적인 척, 가장 있어 보이는 방식으로 서서히 가라앉을 뿐이다.

  • AI 코딩 에이전트가 SaaS의 종말을 부른다? (착각입니다)

    AI 코딩 에이전트가 SaaS의 종말을 부른다? (착각입니다)

    최근 AI와 코딩 에이전트(Coding Agent)가 유행하면서, 심심치 않게 “이제 SaaS의 시대는 끝났다”는 말들이 들린다. “AI가 코드 다 짜주는데, 뭣하러 비싼 돈 주고 SaaS를 쓰나요? 그냥 인하우스(In-house)로 뚝딱 만들면 되지.” 얼핏 들으면 그럴싸하지만, 이는 SaaS의 진짜 ‘본질’을 오해한 데서 비롯된 생각이다. SaaS의 본질은 소프트웨어가 아니라 ‘책임 외주화’다 SaaS(Software as a Service)를 단순히 ‘남이 만든 소프트웨어’라고 생각하면…

  • [Airflow] 스케줄링의 미학: 00시 정합성과 리소스 분산을 모두 잡는 설계

    [Airflow] 스케줄링의 미학: 00시 정합성과 리소스 분산을 모두 잡는 설계

    (부제: 논리적 시간(Logical)과 물리적 시간(Physical) 분리하기) 개발자에게 “00시”는 하루의 끝이 아니다. 하루의 시작이자, 가장 예민한 시간이다. 500개가 넘는 배치가 동시에 “나부터 실행시켜줘!”라고 아우성치는 그 시간, 우리 데이터 팀의 슬랙은 항상 불타고 있었다. 1. The Dilemma: 정합성이냐, 효율성이냐 (죽느냐 사느냐) 데이터 엔지니어라면 누구나 겪는 가불기(딜레마)가 있다. 보통 여기서 우리는 타협한다. “그래, ODS는 00시, DM은 01시, 리포트는…

  • AI는 다소 과대평가 되거나 다분히 과소평가 되고 있다

    AI는 다소 과대평가 되거나 다분히 과소평가 되고 있다

    링크드인을 켜면 매일같이 장밋빛 환상이 쏟아진다. 클로드나 오픈클로우(OpenClaw)로 하루 만에 프로그램을 만들었다는 둥, 이제 개발은 아이디어 싸움이라는 둥… 하지만 정작 개발 현장에서 마주하는 풍경은 사뭇 다르다. AI에게 뇌를 맡긴 채 ‘개판’으로 내린 지시로 짜인 이상한 코드들, 확장성이라곤 고려하지 않은 하드코딩 수준의 MR을 마주할 때면 이 괴리감은 극에 달한다. AI는 정말 우리를 대체하고 있는가, 아니면 우리는…