Backpressured

팀에서 AI 에이전트를 운영하기 시작하면서 한 가지 문제가 생겼습니다. AI에게 우리 시스템에 대한 정확한 컨텍스트를 어떻게 전달할 것인가. Git 레포지토리에 Markdown 문서를 쌓고 관련된 문서끼리 링크를 걸었습니다. 벡터DB도, 임베딩도, 별도의 검색 시스템도 없었습니다. AI 에이전트가 읽고 참고하게 하려는 목적이었지만, 사람이 필요한 지식을 찾고 관리하기 쉽게 만들고 싶기도 했습니다. 이렇게 문서를 연결하고, AI 에이전트가 읽고 갱신 PR을 올리는 방식은 Andrej Karpathy가 소개한 LLM Wiki와 비슷합니다. 하지만 문서에 링크가 존재한다고 해서 AI가 그 구조를 탐색에 활용하는 것은 아닙니다. 실제로 운영 중인 에이전트는 주로 rg로 검색하고 필요한 파일을 읽으며 문서를 찾습니다. 그렇다면 현재 문서에 걸어둔 링크를 AI가 직접 따라갈 수 있게 하면, 검색만 사용할 때보다 필요한 문서를 더 잘 찾을 수 있을까요? 토큰도 줄일 수 있을까요? ...

회사 기술 블로그에서 Debezium과 Flink로 CDC 파이프라인을 재설계하고, 이를 기반으로 데이터 복제 방식을 증분 처리 중심으로 전환한 이야기를 다룬 적이 있습니다. MySQL의 변경분을 Debezium이 캡처하고, Kafka를 거쳐, Flink가 S3와 Iceberg 테이블로 복제하는 구조입니다. 전체 아키텍처와 선택 배경은 그 글들에서 다뤘으니 여기서는 생략하겠습니다. 이 글은 그 다음 이야기입니다. Debezium을 운영하면서 겪은 일은 크게 두 종류였습니다. 하나는 데이터가 조용히 어긋나는 문제였고, 다른 하나는 커넥터가 예상과 다르게 움직이는 문제였습니다. 이번 글에서는 먼저 데이터가 어긋났던 경우들만 정리합니다. ...

CDC 파이프라인을 Debezium과 Flink로 재설계한 이유에서 Debezium + Flink 기반 CDC 파이프라인을 소개했습니다. Debezium이 DB 변경분을 캡처하고, Kafka를 거쳐, Flink가 5분마다 S3에 Parquet 파일로 저장하는 구조입니다. 파이프라인은 1년 넘게 잘 동작했습니다. 데이터 정합성도 검증됐고, 운영도 안정적이었습니다. 문제는 데이터 플랫폼 TCO 분석을 하면서 S3 비용을 뜯어보기 전까지는 보이지 않았습니다. S3 비용, 스캔량만 보면 안 됩니다 AWS에서 Athena를 쓰는 팀이라면 대부분 이렇게 알고 있습니다: “Athena 비용 = 스캔한 데이터량 × $5/TB” ...