데이터와 AI가 만나는 곳.

Claude Code와 Codex 같은 AI 코딩 에이전트를 동시에 운용할 때 발생하는 수십 개 스레드의 맥락 피로를 Git 기반 Markdown 작업 큐와 담당자 수신함 구조로 다듬은 개인 실험 정리입니다.

AI가 쓴 글의 어색한 비유와 번역투를 다듬어주는 한국어 윤문 에이전트 slop-rewrite의 특징과 설치법, 그리고 에이전트 성능을 최적화하는 피드백 방식을 정리했습니다.

카카오는 AI 기술이 데모에 그치지 않고 현장 업무에 안착하도록 Forward Deployed Engineer(FDE) 조직을 운영했습니다. 엔지니어가 직접 현장의 데이터를 파악하고 일하는 방식을 혁신한 사례와 시행착오를 정리했습니다.

바이럴 비디오의 샷과 카메라 움직임, 자막, 음향, 프롬프트를 프레임별로 분해하고 복제 제작도를 출력하는 rea-video 오픈소스를 소개합니다.

NVIDIA가 공개한 9.6M 파라미터 음성 향상 모델 RE-USE의 구조적 특징과 라이선스 주의사항 및 화자 분리와 청킹을 고려한 회의록 STT 전처리 파이프라인 구축 방법을 정리합니다.

AI 코딩 에이전트 도입이 늘면서 개발자의 검증 능력이 약해지는 감독의 역설과 인지적 항복 현상을 살펴보고, 이를 예방하기 위한 실무적 대응 방안을 정리합니다.

NVIDIA가 공개한 Auto-Ontology는 데이터베이스 메타데이터를 비즈니스 용어와 SQL 수식으로 정리하여 LLM 에이전트의 환각을 방지하는 오픈소스 프레임워크입니다.

AI 코딩 에이전트가 React 기반으로 실제 제품 수준의 UI 목업과 애니메이션, Bento Grid 레이아웃을 생성하고 스스로 검증하도록 돕는 Stageshow 스킬을 소개합니다.

Q Labs가 공개한 Dust 논문을 바탕으로, 역전파 없이 활성값 노이즈 Perturbation으로 트랜스포머를 학습시키는 Zeroth-Order 기법의 원리와 메모리 및 연산 트레이드오프를 살펴봅니다.

깃허브 전 CEO 토마스 돔케가 풀 리퀘스트를 대체하는 AI 평가 시스템 트레일스 기반 개발 플랫폼 엔타이어를 공개했습니다.

Claude가 코드의 대부분을 쓰는 Claude Code 팀이 리뷰를 사람이 한 줄씩 읽는 관문에서 여러 겹의 자동 검사와 위험도별 승인으로 바꾼 과정, 리뷰가 끝없이 돌지 않게 만든 규칙, 다른 팀이 따라 할 순서를 정리했습니다.

Claude Managed Agents로 Slack과 GitHub를 정해진 시간에 읽고 요약을 올리는 자동화 예제를 따라가며, 북마크·게시 확인·원장·선호 파일·예산 상한처럼 무인 에이전트가 틀리지 않게 하는 장치를 정리했습니다.

Claude Code를 내 노트북이 아닌 작업별 가상 머신에서 돌리는 클라우드 세션의 구조와, 어떤 작업을 클라우드로 보내고 어떤 작업을 로컬에 남길지, GitHub 연결에서 막히는 지점까지 정리했습니다.

Claude Code 안에서 돌아가는 작은 JavaScript 파일, 모드가 무엇인지 알아보고 컨텍스트 창 상태를 보여주는 Token Weather 예제로 만드는 흐름과 공유 방법까지 정리했습니다.

Claude Code의 claude-api 스킬에 들어온 build-eval, hillclimb 명령이 평가 설계와 개선 루프를 어떻게 자동화하는지, 비용 절감 사례와 함께 정리했습니다.

코드보다 모델링이 먼저라는 게시글의 참고자료 7개를 읽고 남은 것을 정리한 글입니다. 도구가 세 번 바뀌어도 살아남은 원칙, 실무에서 쓰이는 이력 관리 구현 네 가지, 가장 늦게 드러나는 조직 부채를 다룹니다.

수퍼-서브 타입은 논리 모델에서 비즈니스 분류를 명확하게 만듭니다. 물리 모델로 넘어갈 때 세 가지 선택지가 생기며, DW에서는 그 선택이 차원 설계 전체를 바꿉니다.

같은 까마귀발인데 왜 해석이 다를까요. 점선 하나도 툴마다 다른 뜻을 가집니다. 프로젝트에서 모델을 공통 언어로 쓰려면 사용하는 도구의 표기법부터 맞춰야 합니다.

ERD가 같아 보여도 설계 철학은 완전히 다릅니다. OLTP는 트랜잭션 정합성을, DW는 분석 접근 경로를 우선합니다. 그 차이가 Unknown 레코드와 시점 데이터 같은 낯선 설계를 만듭니다.

Synapse, BigQuery, Redshift로 오면서 DW 모델링 관점이 어떻게 달라졌는지 정리합니다. Kimball, Data Vault, One Big Table의 실무 판단 기준도 함께 다룹니다.

차원 데이터가 바뀌면 과거를 덮어쓸지 이력을 남길지 선택해야 합니다. SCD Type 1, 2, 3의 차이를 SQL로 직접 구현하고, dbt snapshot으로 프로덕션 패턴을 만듭니다.

Bronze에 쌓아둔 원본 데이터를 정제하고 표준화합니다. 타입을 맞추고 컬럼명을 통일하며 중복을 제거합니다. dbt로 이 과정을 SQL 모델로 정의합니다.

Bronze에 데이터를 넣는 방법은 두 가지입니다. 전체를 덮어쓰거나 바뀐 것만 가져오는 방식입니다. 어떤 방식을 고르느냐에 따라 파이프라인 복잡도가 완전히 달라집니다.

Bronze, Silver, Gold. 데이터를 레이어별로 나눠 적재하면 무엇이 달라지는지 DuckDB와 dbt로 직접 구성해 봅니다.

GEO가 소비자 AI를 위한 최적화라면 AEO는 코딩 에이전트를 위한 최적화입니다. 문서 길이 제약, llms.txt, skill.md, AGENTS.md까지 필요한 파일을 정리합니다.

On-Site GEO를 완벽하게 적용해도 AI 인용의 절반은 외부 채널에서 결정됩니다. 플랫폼별 Off-Site 전략과 robots.txt 진단법을 다룹니다.

상품 마스터 DB의 데이터가 어떤 파이프라인을 거쳐 HTML 의 JSON-LD가 되는지 정리합니다. 3단계 파이프라인 구조와 SSR 기반 자동 배포 아키텍처를 다룹니다.

ChatGPT는 Wikipedia를, Perplexity는 Reddit을, Gemini는 공식 사이트를 선호합니다. 하나의 전략으로 모든 AI 플랫폼에 대응하기는 어렵습니다.

구글 상위 10위 페이지 중 AI가 인용하는 비율은 9%에 불과합니다. SEO 순위가 AI 인용을 보장하지 않는 시대에 GEO의 3대 원칙과 학술 근거를 정리합니다.

사용자가 자연어 질의를 입력한 뒤 최종 답변을 받을 때까지 각 컴포넌트가 어떤 순서로 동작하는지 정리한 글입니다. 이 글은 시리즈의 첫 글입니다. 각 구성 요소를 왜 그렇게 선택했는지, 실험 과정에서 무엇이 달라졌는지는 이어지는 글에서 다룹니다. 단일 NL2SQL의 한계와 라우팅 구조 NL2SQL을 실운영 환경에 처음 적용하면 같은 문제를 반복해서 만납니다. DDL만으로는 T_CUST_MST 같은 약어 테이블이 무슨 의미인지, “순매출"이 어떤 산식인지 LLM이 파악·추론하지 못합니다. 공개 벤치마크가 아무리 올라가도 실제 엔터프라이즈 환경에서는 정확도가 절반 이하라는 보고가 꾸준히 나옵니다. 같은 종류의 오답은 데이터셋을 바꿔도 사라지지 않습니다. ...

DataNexus를 개발하면서 Claude Code와 Codex를 함께 사용하고 있습니다. Claude Code가 라우터 로직을 수정하는 동안 별도 터미널에서는 Codex로 빠진 테스트를 보완합니다. 처음에는 두 에이전트가 같은 작업 디렉토리를 사용했습니다. 같은 파일을 동시에 수정하면서 충돌이 생겼고, 한 에이전트가 의존성 버전을 바꾸면 다른 터미널에서 진행 중이던 빌드가 실패했습니다. 충돌할 때마다 git stash로 변경 사항을 임시 보관했지만 두 에이전트를 동시에 실행할 수는 없었습니다. 하나의 작업이 끝난 뒤 다음 에이전트를 실행했습니다. git worktree로 에이전트 작업 공간 분리 일반적인 브랜치 전환은 작업 디렉토리 하나에서 체크아웃할 브랜치만 바꿉니다. git worktree를 쓰면 같은 저장소의 브랜치마다 별도 디렉토리를 둘 수 있습니다. git clone을 여러 번 할 필요도 없습니다. 각 worktree는 커밋 기록과 Git 메타데이터를 공유하고, 작업 파일만 별도 디렉토리에 둡니다. 어느 worktree에서 커밋하든 기록은 같은 저장소에 쌓입니다. ...

지난 10편까지는 SQL 생성 과정에서 주로 발생하는 오답 유형을 분석했습니다. BIRD와 Spider 벤치마크를 활용하고 다양한 모델을 테스트하면서 오답을 COLUMN_BINDING, VALUE_BINDING, DERIVED_METRIC 등의 유형으로 세분화했습니다. SQL 오답을 계속 들여다보면서, 확인하고 싶은 것이 달라졌습니다. “그렇다면 생성된 SQL과 답변의 근거는 화면에서 어떻게 시각화되어야 하는가?” 그동안 정확도 중심의 테스트에 집중하느라 실제 사용자가 화면에서 무엇을 확인해야 하는지는 놓치고 있었습니다. 비즈니스 환경에서 쓰는 데이터 분석 AI라면 수치가 어디서 왔는지 명확히 보여야 합니다. 근거를 확인할 방법이 없다면 결과가 정답처럼 보이더라도 사용자는 결국 SQL을 다시 실행하여 검증할 수밖에 없습니다. ...

9편에서 multi-candidate 실험 세 건이 모두 유의미한 결과를 내지 못했지만 Schema Binding Plan으로 넘어가기 전에 확인하고 싶은 것이 하나 더 있었습니다. 모델 성능이 병목의 원인일 수 있다는 가설을 검증했습니다. Gemini flash-lite 대신 Pro 모델을 쓰면 현재 56% 수준인 정확도를 개선할 수 있을 것이라 예상했습니다. 이 과정에서 오답 유형 분류와 Spider 실험도 함께 진행했습니다. Pro 모델로 바꿨더니 오히려 정확도가 떨어졌다 모델만 교체하고 동일한 BIRD 50문항을 실행했습니다(프롬프트, 컨텍스트, 파이프라인은 그대로). 지표는 EX(Execution Accuracy)로, 생성된 SQL을 실제로 실행했을 때 정답과 같은 결과가 나오는지 확인하는 방식입니다. ...

자체 30문항에서는 정확도 80%를 기록했지만 BIRD 공개 벤치마크 50문항에서는 56%였습니다. 9번의 실험 끝에 ‘후보 여러 개 만들어서 고르기’ 가설을 세 방향에서 모두 폐기했습니다. 남은 과제는 스키마 이해와 방법론이었습니다.