BYUN Kyuhyun

“What separates people who use AI well from those who don’t?” It’s a question I get from colleagues often. It’s been three years since ChatGPT launched, and over a year since I started using Claude Code in earnest. In that time, the way I work has fundamentally changed. It’s no longer just “asking AI things”—the way I think alongside AI has shifted. In this post, I want to share honestly how I use Claude: how I ask questions, the patterns I follow to solve problems, and what I’ve discovered recently by combining it with Codex. ...

“AI를 잘 쓰는 사람과 못 쓰는 사람의 차이는 뭘까?” 동료들에게 자주 받는 질문이다. ChatGPT가 나온 지 3년, Claude Code를 본격적으로 쓴 지 1년이 넘었다. 그 사이에 내 작업 방식은 근본적으로 바뀌었다. 단순히 “AI에게 물어보는 것"이 아니라, AI와 함께 생각하는 방식 자체가 달라졌다. 이 글에서는 내가 Claude를 어떻게 활용하고 있는지—질문하는 방식, 문제를 해결하는 패턴, 그리고 최근 Codex와 병용하면서 발견한 것들을 솔직하게 공유하려 한다. 질문의 진화: “이거 해줘"에서 “같이 생각하자"로 처음 AI 도구를 쓸 때는 검색 엔진의 연장선이었다. “Go에서 map을 순회하면서 삭제하려면?” 같은 단답형 질문. Stack Overflow 대신 Claude에게 물어볼 뿐이었다. ...

“빠르게 실패하라(Fail Fast).” 스타트업과 프로덕트 세계에서 가장 많이 들리는 조언 중 하나다. 아이디어를 빠르게 시장에 내놓고, 피드백을 받고, 방향을 수정하라. 틀린 말이 아니다. 하지만 현실은 종종 이랬다. 빠르게 만드느라 수준이 떨어지고, 수준이 떨어지니 피드백 자체가 왜곡되고, 왜곡된 피드백으로 잘못된 결론을 내린다. AI가 이 공식을 근본적으로 바꾸고 있다. 과거의 Fail Fast: 속도와 수준의 트레이드오프 전통적인 Fail Fast에는 구조적 한계가 있었다. 빠르게 만들려면 수준을 타협해야 했다. MVP(Minimum Viable Product)라는 이름 아래, “최소한으로 동작하는” 수준의 프로덕트를 만들어 시장에 내놓았다. 문제는 이 “최소한"의 수준이 너무 낮았다는 점이다. ...

“Fail fast.” It’s one of the most common pieces of advice in the startup and product world. Ship your idea quickly, get feedback, adjust course. It’s not wrong. But reality often looked like this: building fast meant building poorly, building poorly meant distorted feedback, and distorted feedback led to wrong conclusions. AI is fundamentally changing this equation. The Old Fail Fast: The Trade-off Between Speed and Quality Traditional Fail Fast had a structural limitation. Building fast meant compromising quality. Under the banner of MVP—Minimum Viable Product—teams shipped products that were “minimally functional.” The problem was that the bar for “minimal” was too low. ...

용어 사전 이 글에서 자주 등장하는 핵심 용어를 먼저 정리한다. 용어 설명 MPP (Massively Parallel Processing) 다수의 Node가 Query를 분할하여 동시에 처리하는 Architecture Leader Node Client 요청을 받아 SQL Parsing, Query Planning, Code Generation을 수행하고 결과를 집계하는 Coordinator Compute Node 실제 데이터를 저장하고 Query Segment를 병렬 실행하는 Worker Node Slice Compute Node 내부의 병렬 처리 단위. 독립적인 CPU, Memory, Disk Partition을 가짐 RMS (Redshift Managed Storage) S3 기반 Tiered Storage. Local SSD Cache + S3 Cold Storage로 구성 AQUA (Advanced Query Accelerator) Storage Layer에서 FPGA/Nitro Processor로 Filtering과 Aggregation을 사전 수행하는 가속기 Zone Map 각 1MB Block의 Min/Max 값을 Memory에 보관하는 Metadata. Block Skipping에 사용 AZ64 Amazon이 자체 개발한 SIMD 기반 Compression Algorithm. Numeric/Date Type에 특화 WLM (Workload Management) Query Queue별 Memory, Concurrency Slot을 배분하는 Resource Management 시스템 ATO (Automatic Table Optimization) Query Pattern을 분석하여 Distribution Key/Sort Key를 자동 최적화하는 AI 기반 기능 RPU (Redshift Processing Unit) Redshift Serverless의 Compute 단위. 1 RPU = 16GB Memory Concurrency Scaling Workload 급증 시 Transient Cluster를 자동 추가하여 Throughput을 확장하는 기능 SQA (Short Query Acceleration) 짧은 Query를 전용 Queue(Service Class 14)에서 우선 실행하여 긴 Query에 Block되지 않게 하는 기능 MVCC (Multi-Version Concurrency Control) 각 Transaction이 데이터의 Snapshot을 기반으로 동작하여 Read/Write Blocking을 최소화하는 동시성 제어 들어가며 Amazon Redshift는 2012년 re:Invent에서 발표되어 2013년 2월 15일 GA(General Availability)된 이후, Cloud Data Warehouse 시장의 판도를 바꾸어 놓았다. 2025년 기준 수만 개의 조직이 Petabyte 규모의 데이터를 Redshift 위에서 분석하고 있다. ...

들어가며 BigQuery의 Performance는 단순히 좋은 Query Engine 하나로 만들어지지 않았다. 그 아래에는 Google이 20년 넘게 진화시켜 온 Infrastructure Stack이 있다. Colossus: Exabyte 규모의 Distributed File System Capacitor: Compressed 상태에서 직접 Query할 수 있는 Columnar Format Jupiter: 13 Petabits/sec Bandwidth의 Data Center Network Dremel: Tree 구조 병렬 Execution Engine Borg: 수만 대 Machine의 Cluster Management System 이 글에서는 이 중 Colossus와 Capacitor에 집중한다. BigQuery에서 Query를 실행하면, 실제 데이터는 어디에 어떻게 저장되어 있고, 어떤 원리로 읽히는지 구조적으로 살펴본다. ...

용어 사전 이 글에서 자주 등장하는 핵심 용어를 먼저 정리한다. 용어 설명 MPP (Massively Parallel Processing) 다수의 Node가 Query를 분할하여 동시에 처리하는 Architecture Slot BigQuery의 Compute 단위. 가상 CPU + Memory + I/O를 추상화한 Resource Unit RPU (Redshift Processing Unit) Redshift Serverless의 Compute 단위. 1 RPU = 16GB Memory Columnar Storage 데이터를 Row가 아닌 Column 단위로 저장하는 방식. 분석 Query에서 필요한 Column만 읽어 I/O 절감 Distribution Key Redshift에서 데이터를 Node 간에 분산하는 기준 Column. JOIN Performance에 직접 영향 Sort Key Redshift에서 데이터를 디스크에 물리적으로 정렬하는 기준 Column. Filter Performance에 직접 영향 Partitioning BigQuery에서 Table을 날짜/정수 범위 등으로 논리 분할. Scan 범위를 제한하여 비용과 속도 모두 개선 Clustering BigQuery에서 Partition 내 데이터를 특정 Column 기준으로 정렬. 최대 4개 Column 지정 가능 WLM (Workload Management) Redshift의 Query Queue 관리 시스템. Query 종류별 Memory/Concurrency 배분 ATO (Automatic Table Optimization) Redshift가 Query Pattern을 분석하여 Distribution Key/Sort Key를 자동 최적화하는 기능 Zero-ETL Source Database → Data Warehouse로 데이터를 ETL Pipeline 없이 자동 복제하는 기능 Dry Run BigQuery에서 Query를 실행하지 않고 Scan량과 예상 비용만 미리 확인하는 기능. 무료 AQUA (Advanced Query Accelerator) Redshift RA3 Node에서 Storage Layer의 AWS 전용 Processor/FPGA로 사전 Filtering/Aggregation을 수행하는 가속기 Materialized View Query 결과를 사전 계산하여 저장한 View. 반복 Query의 속도를 크게 개선 BI Engine BigQuery의 In-memory Analysis Layer. Sub-second Response로 Dashboard를 가속 들어가며 Cloud Data Warehouse를 선택하는 일은 단순한 기술 비교가 아니다. 조직의 데이터 전략, 운영 문화, 그리고 장기적인 Cloud Roadmap에 깊이 관여하는 의사결정이다. ...

“임팩트 있는 일에 집중하라.” 요즘 어디서든 들을 수 있는 말이다. OKR을 세우든, 스프린트 플래닝을 하든, 우리는 항상 “가장 임팩트가 큰 일이 무엇인가?“를 묻는다. 틀린 말이 아니다. 하지만 이 조언이 “작은 일은 하지 마라"로 오해되는 경우가 많다. 나는 오히려 이렇게 생각한다. 임팩트가 없어 보이는 작은 일들을 꾸준히 끝내야, 임팩트가 큰 일을 할 수 있다. 왜 그런지 이야기해보려 한다. 정리되지 않은 집에서는 일할 수 없다 정신의학에서는 환경과 정신 상태의 연관성을 오래전부터 연구해왔다. 집이 어수선하면 머릿속도 어수선해진다. 이것은 비유가 아니라 실제로 인지 자원이 소모된다는 뜻이다. ...

들어가며 문제를 해결하거나 새로운 것을 학습할 때, 표면적인 이해에 그치지 않고 깊이 있는 지식을 쌓는 것이 중요하다. 이 글에서는 문제의 본질을 파악하고 깊이 있게 탐구하기 위한 다양한 Deep Dive 방법들을 우선순위(꼭 알아야 하는 순서)대로 정리했다. Charlie Munger는 “고립된 사실만 기억해서는 아무것도 진정으로 알 수 없다. 사실들이 이론의 격자(Latticework) 위에 매달려 있지 않으면, 사용 가능한 형태로 가지고 있지 않은 것이다"라고 했다. 이 글이 여러분의 Mental Model Latticework를 구축하는 데 도움이 되길 바란다. ...

Overview If you’re running Apache Beam pipelines with GPUs or large ML models, you’ve probably hit “CUDA out of memory” errors. Here’s what’s happening: each worker process loads its own copy of your model, eating up memory until everything crashes. Apache Beam 2.49.0 added MultiProcessShared to fix this. It lets you share one copy of a resource (like a GPU model) across all processes on a worker, instead of loading it separately in each process. This can drop your memory usage from 24GB to 3GB. ...