반응형 전체 글506 🏠 웹 UI가 뭐야? — HTML·CSS·JavaScript를 집짓기로 이해하는 첫걸음 🏠 웹 UI가 뭐야? — HTML·CSS·JavaScript를 집짓기로 이해하는 첫걸음요즘은 "AI한테 시키면 화면 하나쯤 뚝딱 만들어 준다"는 말을 자주 듣는다. 실제로 그렇다. 그런데 막상 해 보면 금방 벽에 부딪힌다. AI가 만들어 준 화면에서 버튼 위치를 살짝 옮기고 싶은데, 뭐라고 말해야 할지 모르겠다. 어딘가 깨졌는데, 어디가 문제인지 설명을 못 한다. 결국 "다시 해 줘"만 반복하다 지친다. 이 시리즈는 그 벽을 넘기 위한 안내서다. 코딩을 한 줄도 몰라도, UI라는 말을 처음 들어도 괜찮다. 첫 편에서는 AI 도구를 켜기 전에 꼭 알아야 할 가장 기초, 곧 웹 화면이 무엇으로 만들어지고 어떻게 눈앞에 나타나는지를 집짓기에 빗대어 정리한다. 이것만 알아도 AI에게 하는 말이 확 달라진다. .. 2026. 10. 7. 🦆 DuckDB 완전 정리 — 노트북 한 대로 하는 빠른 분석 데이터베이스 🦆 DuckDB 완전 정리 — 노트북 한 대로 하는 빠른 분석 데이터베이스데이터 분석이라고 하면 흔히 거대한 클러스터와 분산 엔진을 떠올린다. 하지만 현실의 많은 분석은 수백 MB에서 수십 GB 사이, 노트북 한 대로도 충분히 다룰 만한 규모다. 이럴 때 Spark 클러스터를 띄우거나 데이터 웨어하우스에 올리는 것은 배보다 배꼽이 크다. 그렇다고 pandas로 수 GB Parquet을 집계하자니 느리고 메모리가 터진다. 바로 이 틈을 정확히 메우는 것이 DuckDB다. 흔히 "분석용 SQLite"라 불리는 이 작은 데이터베이스는, 설치도 서버도 없이 내 프로그램 안에서 돌면서 Parquet 파일을 놀랄 만큼 빠르게 SQL로 분석한다. 이 글은 DuckDB가 정확히 무엇이고, 왜 그렇게 빠른지, 어떤 킬.. 2026. 10. 7. 🪣 Amazon S3 완전 정리 — 오브젝트 스토리지의 표준이자 데이터 레이크의 바닥 🪣 Amazon S3 완전 정리 — 오브젝트 스토리지의 표준이자 데이터 레이크의 바닥클라우드에서 "파일을 어디에 저장하지?"라는 질문의 가장 흔한 답이 Amazon S3다. 웹사이트 이미지부터 앱 백업, 로그, 그리고 페타바이트급 데이터 레이크까지, 오늘날 수많은 데이터가 결국 S3 위에 얹혀 있다. 데이터 엔지니어링을 공부하면 Iceberg도, Trino도, 결국 그 데이터가 실제로 놓이는 곳은 S3 같은 오브젝트 스토리지라는 것을 알게 된다. 그런데 S3는 우리가 흔히 아는 '폴더에 파일 넣는 저장소'와는 작동 방식이 근본적으로 다르다. 이 글은 S3가 정확히 어떤 종류의 스토리지인지, 버킷·오브젝트·키 같은 핵심 개념은 무엇인지, 비용을 좌우하는 스토리지 클래스와 11개의 9로 유명한 내구성, 보.. 2026. 9. 29. ⭐ Apache Polaris 완전 정리 — Iceberg를 위한 오픈 REST 카탈로그 표준 ⭐ Apache Polaris 완전 정리 — Iceberg를 위한 오픈 REST 카탈로그 표준데이터 레이크하우스를 공부하다 보면 Iceberg 다음에 반드시 마주치는 관문이 있다. 바로 '카탈로그'다. "Iceberg 테이블을 만들었는데, 그걸 어디에 등록하고 누가 관리하지?"라는 질문에 답하는 것이 카탈로그다. 그리고 이 카탈로그를 두고 최근 업계에서는 이른바 '카탈로그 전쟁'이 벌어지고 있다. 그 한복판에 있는 것이 Apache Polaris다. Polaris는 북극성(Polaris)이라는 이름처럼, 여러 엔진과 클라우드가 하나의 기준점을 바라보게 하려는 벤더 중립 오픈 카탈로그다. 이 글은 카탈로그가 왜 필요한지부터 시작해, Polaris가 정확히 무엇이고 어떤 문제를 풀며, RBAC·크리덴셜 벤딩.. 2026. 9. 29. 🐇 Trino 완전 정리 — 흩어진 데이터를 SQL 하나로 쿼리하는 분산 엔진 🐇 Trino 완전 정리 — 흩어진 데이터를 SQL 하나로 쿼리하는 분산 엔진회사의 데이터는 한곳에 얌전히 모여 있지 않다. 주문 정보는 MySQL에, 로그는 S3의 Parquet 파일에, 사용자 이벤트는 Kafka에, 상품 검색 데이터는 Elasticsearch에 흩어져 있다. 여기서 "지난달 특정 상품을 산 사용자들의 검색 기록"을 뽑으려면? 보통은 각각 다른 도구로 데이터를 꺼내 어딘가로 옮기고 합치는 번거로운 작업이 필요하다. Trino(트리노)는 이 문제를 정면으로 해결한다. 데이터를 옮기지 않고, 있는 그 자리에서, 서로 다른 소스를 하나의 표준 SQL로 조인해 쿼리한다. 이 글은 Trino가 정확히 무엇이고, 어떤 구조로 그런 일을 해내는지, 그리고 언제 쓰고 언제 쓰지 말아야 하는지를 밑.. 2026. 9. 29. ✏️ Apache Iceberg 파고들기 ④ — Copy-on-Write vs Merge-on-Read ✏️ Apache Iceberg 파고들기 ④ — Copy-on-Write vs Merge-on-Read지금까지 세 편을 따라왔다면 한 가지 의문이 들 수 있다. Iceberg의 데이터 파일(Parquet)은 한 번 쓰면 바뀌지 않는 불변(immutable) 파일이라고 했다. 스냅샷도, 커밋도 전부 그 불변성 위에 세워졌다. 그런데 현실에서는 UPDATE로 값을 고치고 DELETE로 행을 지운다. 파일을 못 바꾼다면서, 대체 어떻게 그 안의 행 하나를 수정하고 삭제한다는 걸까? 답은 "파일을 수정하지 않고도 변경을 반영하는 두 가지 전략"에 있다. 하나는 파일을 통째로 다시 쓰는 Copy-on-Write(CoW), 다른 하나는 변경 사항만 따로 기록해 두는 Merge-on-Read(MoR)다. 이 둘의 차.. 2026. 9. 29. 🌱 Apache Iceberg 파고들기 ③ — 스키마 진화와 파티션 진화 🌱 Apache Iceberg 파고들기 ③ — 스키마 진화와 파티션 진화1편에서 우리는 Hive 테이블의 네 가지 한계를 봤다. 그중 두 가지가 유독 데이터 엔지니어를 괴롭혔다. 첫째, 컬럼을 하나 바꾸는 것만으로 기존 데이터가 조용히 깨질 수 있다는 것. 둘째, 파티션 기준을 바꾸려면 사실상 테이블 전체를 다시 써야 한다는 것. 실무에서 "컬럼 추가는 새벽에 조심스럽게", "파티션 변경은 아예 포기"가 상식이던 이유다. Iceberg는 이 두 문제를 정면으로 해결한다. 컬럼을 마음대로 추가·삭제·이름변경해도 안전하고(스키마 진화), 파티션 기준을 나중에 바꿔도 기존 데이터를 한 줄도 다시 쓰지 않는다(파티션 진화). 이번 편에서는 그것이 '어떻게' 가능한지를 메타데이터 수준에서 파고든다. 핵심 열쇠는.. 2026. 9. 29. ⏳ Apache Iceberg 파고들기 ② — 스냅샷과 타임 트래블의 내부 ⏳ Apache Iceberg 파고들기 ② — 스냅샷과 타임 트래블의 내부지난 1편에서 우리는 Iceberg가 '파일들을 메타데이터로 추적하는 테이블 포맷'이며, 커밋이란 결국 "카탈로그 포인터를 새 스냅샷으로 바꾸는 원자적 연산"이라는 것을 배웠다. 그때 스냅샷(snapshot)은 마법의 열쇠처럼 등장했다. 원자적 커밋도, 타임 트래블도, 롤백도 전부 스냅샷에서 나온다고 했다.그렇다면 그 스냅샷은 대체 안에 무엇을 담고 있을까? 이번 편에서는 실제 메타데이터 파일(metadata.json)을 직접 열어 보며, 스냅샷의 실체를 해부한다. 그리고 그것을 이용해 과거로 가고(타임 트래블), 잘못을 되돌리고(롤백), 안전하게 분기하는(브랜치·태그) 방법까지 파고든다. 개념이 아니라 '실제 파일에 이렇게 적혀 .. 2026. 9. 29. 이전 1 2 3 4 ··· 64 다음 반응형
