이전 글 요약

이전 글에서 확인한 건, Debezium 임베디드 엔진의 콜백을 제출 스레드(TRD1)와 순서 보장 배출 스레드(TRD2)로 나누면 병렬로 처리해도 성능 손실 없이(98~101%) 순서를 지킬 수 있다는 것이었습니다. 다만 그건 id 하나 뽑아서 큐에 넣고 순서만 재본 순수 벤치마크였습니다.

이번 글에서 구현한 건 두 가지입니다.

1. MySQL을 Postgres로 갈아 끼워도, 우리 코드는 한 줄도 안 바뀔까? JDBC 드라이버를 바꿔도 애플리케이션 로직은 그대로이듯, Debezium도 “어디서 캡처할지"만 책임지고 그 뒤(가공, 전송)는 전부 우리가 용도에 맞게 짜는 애플리케이션 코드가 되도록 구현했습니다.
2. 워커 4개가 동시에 갈아엎어도, Kafka엔 여전히 1, 2, 3 순서로 꽂힐까? 지난번엔 id 하나만 뽑아 순서를 쟀지만, 이번엔 진짜 컬럼을 가공하고 진짜 Kafka로 전송하는 작은 애플리케이션으로 그 결론을 그대로 재현했습니다.

전체 데이터 흐름

멀티소스는 Debezium 커넥터 단계에서만 갈립니다. 그 뒤(TRD1 - 워커 풀 - TRD2 - KafkaSink)는 소스와 무관하게 완전히 같은 코드가 처리하고, 같은 토픽으로 모입니다.

CDC와 Debezium

서로 다른 종류의 시스템(RDBMS, 검색엔진, 캐시, 다른 서비스의 데이터베이스 등) 간에 데이터를 실시간으로 동기화해야 하는 경우, 원본 데이터베이스를 주기적으로 폴링하는 방식은 확장성과 지연 시간 모두에서 한계가 있습니다. 이 문제를 해결하는 표준적인 방법이 CDC(Change Data Capture)입니다 — 데이터베이스가 남기는 변경 로그를 실시간으로 읽어, 변경 사항을 이벤트로 만들어 필요한 곳에 전달하는 방식입니다. Debezium은 이 CDC를 구현하는 오픈소스 도구 중 가장 널리 쓰이는 것 중 하나이고, 이기종 시스템 간 데이터 동기화 파이프라인의 핵심 구성 요소로 많이 채택되고 있습니다.

MySQL 하나로는 데이터를 감당하기 힘들어지는 시점이 옵니다. 유튜브, 슬랙, 깃허브 같은 곳들이 이 문제를 풀 때 쓴 방법 중 하나가 Vitess입니다. Vitess가 뭘 하는 물건인지, 어떤 부품으로 이뤄져 있는지, 그 부품들을 실제로 어떻게 배치해야 하는지를 로컬 Docker 환경에 직접 만들어보면서 정리했습니다. 여기 나오는 구성은 GitHub 저장소에 그대로 올려뒀고, Docker만 있으면 그대로 따라 켤 수 있습니다.

1. Vitess가 뭔가요?

MySQL 하나로는 데이터가 너무 커지거나 쓰기 트래픽이 너무 많아지는 순간이 옵니다. 이때 흔히 쓰는 해법이 샤딩입니다. 데이터를 여러 MySQL로 쪼개서 나눠 담는 거죠. 문제는 샤딩을 직접 하면 애플리케이션 코드가 “이 데이터가 몇 번 서버에 있더라"를 일일이 알아야 해서 지저분해진다는 점입니다.

댓글이 쌓이고 있었다

카페 방명록에 댓글이 달리면, 사람이 직접 보는 게 아니라 로컬 LLM이 먼저 검수를 합니다. 욕설인지, 광고인지, 그냥 좋은 후기인지 판단해서 자동으로 처리하는 구조예요.

https://cafepurplemint.com (깨알같은 홍보)

그런데 어느 날 로그를 보다가 이상한 걸 발견했습니다.

[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...
[MOD] Processing 5 pending entries...

같은 로그가 계속 찍히고 있었어요. 처리가 끝나지 않은 채로 다음 폴링이 돌고 있었습니다.

원인은 단순했습니다. 댓글 하나 검수하는 데 평균 5.6초. 폴링 주기는 1초. 수학적으로 댓글이 조금만 몰려도 처리 큐가 쌓일 수밖에 없었습니다. (사실 카페 홈페이지를 만들고. 지인 단체방에 댓글 한번 해보라고 홍보아닌 홍보를 했었죠.)

3년 만에 홈페이지를 고쳤습니다

와이프는 현재 무인카페 주인입니다. 그리고 3년전 제가 워드프레스 기반으로 카페 홈페이지를 만들었었죠.

그 후로 거의 손을 안 댔습니다. 메뉴가 바뀌어도, 이미지가 달라져도, 홈페이지는 그냥 그 자리에 있었습니다. 관리가 번거로웠거든요. 어느 날 홈페이지를 열어봤더니, 현실과 너무 달랐습니다. 없어진 메뉴가 올라가 있고, 있는 메뉴가 빠져 있었습니다.

이건 아니다 싶었습니다. 그래 리뉴얼을 결심했습니다. (사실 작년ㅜ터..)

이번엔 쉽게 관리할 수 있는 구조로 처음부터 다시 만들기로 했습니다. 그 과정에서 AI를 적극 활용해보기로 했습니다.

Claude Code를 쓰다 보면 생기는 문제

요즘 개발자들 사이에서 Claude Code를 사용하는 분들이 많아지고 있습니다.

Claude Code는 Anthropic이 만든 AI 코딩 도구인데요. 터미널에서 Claude에게 말로 설명하면, 실제 코드를 작성해주는 강력한 도구입니다.

그런데 이걸 써보신 분들이라면 이런 상황을 겪어보셨을 거예요.

“회원가입 기능 만들어줘.”

라고 말했을 뿐인데, Claude가 데이터베이스 설계부터 API 코드까지 주르르 짜기 시작합니다. 처음엔 “와, 빠르다!” 싶지만, 잠깐 들여다보면 내가 원하는 방향이 아닌 경우가 많습니다.

• 이메일 인증이 없어도 된다고 했는데 들어가 있거나
• 프레임워크를 Next.js로 쓰고 싶었는데 Express로 만들거나
• 아직 기획이 안 됐는데 너무 복잡한 구조로 짜버리거나

방향이 잘못된 채로 코드가 쌓이면, 나중에 수정하는 비용이 처음부터 다시 만드는 것보다 커집니다. 그리고 Claude는 멈추지 않습니다. 계속 만듭니다.

최근 사피엔스 두꺼운 책을 3번째 시도를 거쳐 읽어나가고 있는 와중. 감정이라는 무기에서 일맥상통하는 시타르타 부처의 가르침이 머릿속을 맴돌기에. 이에 대해 기록을 해보고자 합니다. 물론 일부 발췌 문구에 여러 기록의 상상의 나래를 펼쳐 내용을 장황 늘려보았어요.

부타의 번뇌를 벗어나는 가르침

시타르타의 가르침은 번뇌를 벗어나 해탈의 경지에 이르는 것을 핵심으로 합니다. 불교에서는 이 번뇌가 인간의 고통을 낳는 근본적인 원인이고, 이를 벗어나기 위한 수양법을 가르쳐왔습니다.

1. 사성제(四聖諦)

• 고제(苦諦): 인생에는 고통(생로병사)이 있다.
• 집제(集諦): 그 고통의 원인은 탐욕,분노,어리석음 이다.
• 멸제(滅諦): 번뇌를 없애면, 열반(해탈) 에 이른다.
• 도제(道諦): 해탈에 이르는 길이 있으니, 그것이 팔정도(八正道)이다.

2. 팔정도(八正道)

• 정견(正見): 세상에 있는 그대로, 바르게 보는 것
• 정사유(正思惟): 욕심/해침/해로움 없는 올바른 생각
• 정어(正語): 거젓말/험담/욕설 하지 않는 올바른 말
• 정업(正業): 살생/도둑질/사악한 행위를 피하는 올바른 행동
• 정명(正命): 다른 생명을 해치지 않는 올바른 생활
• 정정진(正精進): 끊임없이 선한 마음을 일으키고, 악한 마음을 줄이기 위한 노력
• 정념(正念): 지금 이 순간을 맑게 알아채는 마음가짐
• 정정(正定): 마음을 고요하게 집중하는 것

감정과 마주하기?

“감정을 억누르지 말고, 있는 그대로 바로보아라.” 라는 예전 도서의 문구가 머릿속을 맴돌았다. 감정은 억압을 하거나 무시를 할 때 오히려 더 강력해지고, 부정적인 패턴으로 이어질 수 있습니다. “부정적인 감정"을 애써 외면하지 말고, 직접 마주하고 생산적인 에너지를 바꾸기를 가이드합니다.

Overview

벌써 15년이 훌쩍 넘었던 워드프레스 블로그. 워낙에 레거시 태그들이 내부적으로 많았고. 스킨을 몇번 변경하다 보니. 이미 덕지덕지 오염(?)이 되어있던 상태. 그 와중 hugo를 접하면서 이쪽으로 넘어오면 좋겠다는 생각만을 마음속으로만 했었는데. 어제 겸사겸사 마음을 잡고 이 대사작업을 진행을 해보았습니다.

hugo가 생소하신 분들도 있으실텐데.. hugo는 정적 사이트 생성기로. golang로 만들어져 있으며. 속도도 빠르고, 마크다운 기반 컨텐츠를 HTML/JS/CSS 등으로 변환해주는 녀석입니다. hugo로 글을 쓰면 좋은 것은. 굳이 GUI툴을 사용하지 않더라도. md 파일을 syntax를 적절히 넣어서 작성하면 되고. 모든 것을 git으로 관리하며. netify와 연계를 하면 기존 도메인도 제대로 활용할 수 있다는 점입니다. 로컬에서 서술하듯 글을 쓰다 보니. 가볍고, 생산적이고. 기타 등등..

Overview

일년만에, 블로그에 새 글을 올려봅니다. 그동안, 많은 주제가 있었지만, (주관적인 판단이지만) 좋은 주제일지 예전같은 확신이 서지 않아서, 많은 시간 망설이며 잠시 블로그를 멈추었습니다.

그러나, 제가 알던 경험이. 나만의 아련한 기억이 되고 점차 소멸되기 전에. 잊기 전에. 블로그 하나를 올려봅니다. 멀티DC 환경을 고려하면서, 몇가지 테스트를 하던 중. 노드간 네트워크 레이턴시를 고민을 했었는데. TC(Traffic control)를 활용하였고 나름 의미있는 결과를 도출했었는데.. 오늘은 tc에 대해서 이야기를 해보고자 합니다.

Traffic control (TC)?

동일 네트워크 상에서, DC간의 레이턴시를 고려하여 성능 변화를 테스트하고 싶은 경우가 있습니다. 특히나, 과거와는 다르게 서비스가 여러개의 DC 또는 Zone에서 분산 구동될 수 있다는 상황을 고려해본다면. 이런 테스트는 필수 입니다. 참고로, 아주 오래 전, 서울/부산 레이턴시 14ms로 인하여 대형 서비스 장애를 경험해본 입장으로. 서비스 오픈 전 이런 검증은 필수라 생각합니다.

Overview

안녕하세요. 벌써 일년이 넘는 시간동안 포스팅을 하지 않았네요.

그동안 업무적으로 많은 변화도 있던 격동의 시기였던지라, 제 삶의 가장 중요한 요소 중 하나라 생각하던 공유의 가치를 그만 간과하고 말았네요. 물론 포스팅을 멈춘 시간동안 놀지 않고 많은 경험을 쌓아보았습니다.

오늘은 그중 하나, 인메모리 데이터베이스인 Apache Ignite에 대해 이야기를 해보고자 합니다.

Apache Ignite?

이미 많은 분들이 Ignite 를 사용해보셨을 수도 있겠습니다만, 저는 DBA로 일을 하면서도 늘 제대로된 캐시 용도로 써보고 싶었던 분산 인메모리 데이터베이스가 Apache Ignite입니다.