[월간 기록] 2025년 12월

RDB 기반 큐, 비동기/논블로킹 관련 글 작성

RDB 기반 큐로 회사 내부에 문제 많던 코드를 개선했는데, 만족스러운 경험이였다. 나중에 기회가 되면 다뤄볼까 한다. 또한 새로운 블로그 글도 작성했는데, 이 두 작업에 이번 달의 대부분을 투자했다.

수집

흥미롭거나 유용했던 자료들

Lobsters - 해커뉴스와 비슷하지만 초대제로 운영되는 커뮤니티 | GeekNews

기본적으로 해커뉴스를 더 많이 보긴 하는데, 여기에도 재미있거나 유익한 내용이 많다. 업로드 가능한 사람이 제한적이라 그런지 올라오는 글이 해커뉴스와 잘 겹치지 않는 것 같다.

SQLite는 어떻게 테스트되는가 | GeekNews

SQLite의 테스트 방법론에 대한 공식 문서이다.

SQLite가 최근 서버 쪽에서도 사용하자는 의견이 종종 보여서 찾아보다가 알게 되었다. 로컬에서 돌려도 될 만큼 가볍고, 생각보다 높은 성능과, 수많은 기기에서 쓰일만큼 높은 신뢰도가 마음에 든다.

토이프로젝트에서 서버를 만들어야 한다면 Rust, SQLite를 사용해 만들어보고 싶다는 생각을 하고 있다.

SQLite의 알려지지 않은 이야기 | GeekNews나 Quality Management도 함께 보면 좋다.

Wide Events: 로깅의 새로운 패러다임

기존 로깅 방식의 근본적인 문제를 해결하려는 새로운 접근법. 요청당 수십 줄의 분산된 로그 대신, 하나의 포괄적인 구조화된 이벤트를 발행하자는 의견이다.

공감하는 사람들도 많을거라 생각하는데, 서비스의 로그를 분석하다 보면 불편한 상황이 많이 생긴다. 필요한 정보를 주는 로깅이 없다거나, 연결된 로그를 찾기 어렵다거나 등등.

실제 운영을 통한 평가를 받아봐야 확실해지겠지만, 이 기법을 사용한다면 문제 해결이 쉬워지지 않을까 싶다.

나날이 발전하고픈 개발자를 위한 AI 활용법

관심 가는 거만 메모했다. 빠진부분이 많다.

그 외

작업

학습, 개발, 실험 등 직접 손댄 것들

RDB 기반 큐를 사용해보기

DB의 작업 성공과 함께 사이드이펙트나 추가 처리(알림, 비동기 처리)가 필요한 경우, MQ가 유용하다. 하지만 당장 고트래픽 처리와 확장성이 필요 없다면 DB 기반 스케줄러를 쓰는 게 더 좋다. (90% 이상의 경우 여기에 해당할 것이다.)

회사에서 db-scheduler를 사용하여 별도 인프라 추가 없이 단계별로 복구 가능한 Task를 만들 수 있었고, 기존의 여러 문제를 해결하는 만족스러운 결과를 얻었다. 이에 대한 건 따로 블로그를 써볼 예정이다.

우아한형제들 기술블로그에서도 유사한 패턴을 직접 구현한 사례가 있다. (왜 직접 만들었는지는 모르겠지만)

Rust에는 apalis가 제일 유명한 거 같다.

블로그 글 "동기/비동기, 블로킹/논블로킹 개념은 어디서부터 잘못되었나" 작성

X에서 개발 관련 포스팅을 보면서 시간을 때우곤 하는데, 동기/비동기 관련 사분면이 잘못되었다는 글을 보게 되었다.

명확하게 설명은 못했지만 저런 사분면으로 나눠서 설명하는 것이 뭔가 이상하다는 생각을 가지고 있던 터라, AI를 활용해 여러 자료를 찾아보았다. 이런 사분면 설명은 잘못된 설명이라는 걸 알게 되어 글을 작성했다.

요즘엔 AI를 사용하면 이전에 비해 자료 검색 속도가 말도 안 되게 빨라졌다. 정확한 자료를 빠르게 찾아볼 수 있어서 좋다.

짧은 생각

근황과 요즘하는 생각

기존에 오픈소스 기여에 관심을 가지고 더 깊이 있는 부분에 참여하고 싶었지만, 아직 많이 부족함을 느끼고 있다. 기초적인 능력 향상에 집중하기 위해 한동안은 쉴 예정이다.

AI를 개발과 자료조사에 적극 활용하면서, 공식문서나 개념을 쉽게 풀어쓴 블로그 글을 볼 필요가 없어졌다. 이제는 전문성 있는 글이나 개인적인 시선이 담긴 글 위주로 보고, 나도 그런 글을 쓰려고 하고 있다. (어떻게 보면 AI가 저품질 글을 대체했다고 볼 수 있을까?)