Claude Code, 프롬프트보다 하네스가 먼저입니다
요즘 Claude Code를 설치하고 바로 프롬프트부터 넣는 경우를 자주 봅니다. 물론 프롬프트도 중요합니다. 다만 실제로 결과 차이를 더 크게 만드는 지점은 프롬프트 문장 자체보다 작업을 굴리는 구조, 즉 하네스(harness) 설계에 더 가깝다고 생각합니다.
Posts by Category
blog
AI시대 DW: schema-aware reasoning은 결국 무엇을 잘하자는 이야기일까
이 글은 AI 시대의 DW 모델링은 어떻게 달라져야 할까 와 semantic layer를 왜 다시 보게 되는가 에서 이어지는 내용입니다.
AI시대 DW: semantic layer를 왜 다시 보게 되는가
지난 글에서 AI 시대의 DW 모델링 이야기를 하면서 semantic layer 이야기를 잠깐 꺼냈습니다. 그런데 이 주제는 짧게 한 문단으로 끝내기에는 아쉬움이 있었습니다.
AI시대 DW: 모델링은 어떻게 달라져야 할까
요즘은 AI에게 SQL 초안을 맡기는 일이 꽤 자연스러워졌습니다. 예전에는 쿼리를 직접 짜는 시간이 더 길었다면, 지금은 질문을 다듬고 결과를 검증하는 시간이 더 길어지는 경우도 많습니다. 저도 실제로 SQL 작성 속도 자체는 예전보다 빨라졌다고 느낍니다.
DW 유저 상태 Fact 모델링: 상태를 구간으로 저장하는 Interval Table
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
DW 유저 상태 Fact 모델링: Transition Table은 언제 필요할까
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
DW 유저 상태 Fact 모델링: 활동한 날만 저장하는 Activation 모델
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
DW 유저 상태 Fact 모델링: First/Last 모델이 먼저 맞는 경우
이 글은 유저 상태 스냅샷 포스트 와 시리즈 개요편 에서 이어지는 내용입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
DW 유저 상태 Fact 모델링: Daily Snapshot 다음에 볼 수 있는 대안들
이 글은 유저 상태 스냅샷 포스트 의 후속 개요편입니다. 앞선 글을 아직 안 보셨다면 먼저 보고 오셔도 좋습니다.
활성 유저 지표 Fact를 운영하고 계신다면 유저 상태 스냅샷(User State Snapshot)도 고려해보세요.
DW에서 fact를 꼭 이벤트 단위로만 만들어야 하는 것은 아닙니다. 어떤 문제는 이벤트보다 상태 를 저장하는 편이 훨씬 낫습니다.
SQL Pipe Syntax, 좋아 보였지만 우리 팀은 아직 쓰지 않기로 했습니다
최근 SQL 파이프 구문(pipe syntax)을 다시 살펴봤습니다. Google이 먼저 강하게 밀고 있고, BigQuery는 물론 Databricks도 지원하고 있습니다. 겉으로만 보면 꽤 매력적입니다. 특히 복잡한 SQL을 자주 읽고 고쳐야 하는 사람에게는 “왜 진작 이렇게 안...
AI한테도 조인 시키실 건가요? 저는 와이드 테이블로 갑니다 (Star Schema vs. Wide Table)
데이터 웨어하우스 모델링 이야기를 하면 늘 스타 스키마 vs. 플랫 와이드 테이블 이야기가 나옵니다. 예전에는 이 질문에 꽤 정석적인 답이 있었습니다. 분석용이면 스타 스키마, 운영성이나 단순 조회면 와이드 테이블 정도로 정리하곤 했습니다.
Audit Log로 데이터 웨어하우스 가드레일 만들기
운영 데이터베이스를 GCP DataStream으로 ODS에 스트리밍하다 보면, “스트리밍만 잘 되면 끝”이라고 생각하기 쉽습니다. 하지만 실제 운영에서는 데이터 적재보다 적재 이후의 관리가 더 어렵습니다.
나는 메달리온이 싫습니다
요즘 데이터 플랫폼 이야기를 하면 거의 자동으로 따라오는 단어가 있습니다. 바로 Bronze, Silver, Gold로 이어지는 메달리온 아키텍처입니다. 여전히 많이 쓰이고, 특히 Databricks 생태계에서는 사실상 기본값처럼 취급되기도 합니다.
좋은 데이터 모델은 저장이 아니라 질문을 위해 존재합니다
데이터 모델링 이야기를 하다 보면 대화가 쉽게 구조 쪽으로 흘러갑니다. 정규화가 맞는가, 스타 스키마가 맞는가, 와이드 테이블이 맞는가, 레이크하우스가 좋은가 같은 질문들이 먼저 나옵니다. 물론 이런 논의는 중요합니다. 다만 실무에서는 모델이 실패하는 이유가 구조가 덜 예뻐서인 경...
BigQuery Dynamic Data Masking 적용 파이프라인 정리
BigQuery에서 개인 정보가 포함된 테이블을 운영하다 보면, 단순히 권한을 나누는 수준만으로는 부족한 경우가 많습니다. 특히 ODS나 분석용 테이블이 자동 생성되거나 재생성되는 환경에서는, 민감 컬럼에 대한 정책 적용이 한 번만 누락되어도 그대로 노출 위험으로 이어질 수 있습니다.
MWAA에서 Secrets Manager를 붙여서 Connection과 Variable을 관리한 방법
Airflow를 운영하다 보면 언젠가 한 번은 같은 고민을 하게 됩니다. Connection 이나 Variable 을 UI에 직접 넣고 관리해도 되나, 아니면 외부 비밀 저장소로 빼야 하나 같은 고민입니다.
Airflow Worker가 32개인데 왜 모니터링에는 10개만 보일까
Airflow를 운영하다 보면 숫자가 직관을 배신하는 순간이 있습니다. 설정상 worker 수는 32 인데, 모니터링 화면을 보면 동작 중인 worker가 많아야 10개 정도로만 보이는 경우가 그렇습니다.
MWAA 워커를 아끼고 싶다면, Airflow Deferrable Operators를 봐야 합니다
Airflow를 운영하다 보면 생각보다 자주 드는 아쉬움이 있습니다. “이 태스크는 사실 하는 일이 거의 없는데 왜 워커를 계속 잡아먹고 있지?” 같은 종류의 아쉬움입니다.
Airflow BashOperator로 Cloud Function 실패를 감지했던 기록
Airflow에서 BashOperator 로 Cloud Function을 호출할 때, 저는 당연히 함수 내부에서 Exception이 발생하면 태스크도 실패할 것이라고 생각했습니다. 그런데 예상과 다르게, 함수는 터졌는데 Airflow는 아주 평온하게 SUCCESS 를 찍어주는 상황...