JangBaGeum.gif

AI가 생활화되면서 개발에 있어 더욱 중요해진 것이 있다. 바로 설계라고 생각한다. AI 에이전트들은 각자의 컨텍스트를 가지고 각자의 요구사항을 해결하는 데 집중한다. 하지만 우리는 하나의 프로젝트 전체 요구사항을 단일 AI 컨텍스트에 맡기지 않는다. AI의 컨텍스트도 거대한 요구사항을 감당하지 못한다. 이 과정에서 서비스의 일관성을 유지하고 유지보수성을 높이기 위해, 인간이 할 수 있는 '설계'의 역할은 더욱 중요해졌다. 특히 외부로 제공되는 API는 한 번 정해지면 서비스가 종료되기 전까지 사라질 수 없다. 업데이트를 진행할 때도 하위 호환성은 반드시 고려해야 한다. 이런 면에서 API 설계는 대충 넘어갈 일이 아니라, 충분한 시간을 들여 고민해야 하는 영역이라고 생각한다. 이전에 API 디자인 패턴..

요즘 AI 코딩 에이전트 없이 개발하는 사람은 거의 없을 것이다. 이 영역의 문화도 빠르게 변하고 있다. 기획부터 개발, QA까지 단순히 AI 에이전트에게 명령하는 수준을 넘어서, 유기적인 에이전트 팀을 구성하여 하나의 제품을 만들어내는 방법론들도 다양하게 등장하고 있다. 우리 조직에서도 Claude를 도입하여 실무에서 적극적으로 사용하고 있다. 개인적으로 Claude Code의 능력은 정말 잘하는 수준의 주니어를 뛰어넘을 정도라 생각하고, 생산력도 무시무시할 정도로 높아진 것이 체감된다. (Claude Code를 도입하면서 오히려 내 일이 늘어나는 아이러니한 상황이 벌어지고 있다...) 그런데 결국 모두가 AI 코딩 에이전트를 이용하여 개발하고 있고, 어느 정도 생산력이 상향 평준화된 상황에서 한 ..

운영하는 서비스의 코드 혹은 아키텍처의 설계를 보다 보면 "왜 이렇게 만들었을까?" 하는 정말 순수한 궁금증이 생긴 적이 많았을 것이다. 우리가 현재 운영하는 서비스는 지금의 모습이 되어 열심히 굴러가기까지 수만은 설계의 갈림길에 있었을 것이고 누군가들은 당시 최고의 방향으로 결정하여 서비스를 만들어 나아갔을 것이다.그러나 이러한 결정은 기록되지 않으면 그 당시 결정을 위한 노력들이 휘발된다. 혹은 실무자의 입에서 입으로 전해오는 구전영하는 서비스의 코드 혹은 아키텍처의 설계를 보다 보면 "왜 이렇게 만들었을까?" 하는 정말 순수한 궁금증이 생긴 적이 많았을 것이다. 우리가 현재 운영하는 서비스는 지금의 모습이 되어 열심히 굴러가기까지 수만은 설계의 갈림길에 있었을 것이고 누군가들은 당시 최고의 방향으로..

우리는 클러스터링 된 WebSocket 서버 환경에서 실시간 메시징 기능을 제공하고 있다. 클라이언트 수가 증가함에 따라 WebSocket 서버의 수평 확장이 자연스럽게 필요해졌고, 이에 따라 다음과 같은 메시지 라우팅 문제를 고민하게 되었다.예를 들어,사용자 A는 서버 1에 접속하고,사용자 B는 서버 3에 접속해 있다고 하자.이때 A가 B에게 메시지를 보내려면 B가 연결된 서버를 알아야 한다.즉, 클러스터 환경에서는 "어느 서버에 누구(userId)가 붙어 있는지"에 대한 라우팅 정보 관리가 핵심이다.이 문제를 해결하기 위한 대표적인 방법은 다음과 같다:Redis 등에 라우팅 테이블을 유지Gateway 서버에서 중앙 집중형 라우팅 처리Consistent Hashing 기반 라우팅우리는 가능한 한 모든 ..

Go 언어를 사용하지 않아도 goroutine이라는 단어는 한 번쯤 들어봤을 것 같다."가볍다", "수십만 개도 문제없다", "스레드보다 효율적이다" 같은 말이 항상 따라 나온다.그런데 실제로 goroutine이 어떻게 동작하길래 이련 평가를 받는가 라는 궁금증이 생겼다. 나는 Go 언어를 사용하는 개발자는 아니다. 하지만 주로 사용하지 않는 언어 혹은 기타 기술들의 동작 원리와 녹아있는 방법론, 사상을 공부하는 것은 늘 영갑을 주고 실제 개발을 할 때 적용할 수 있는지 고민하는데 정말 큰 도움을 준다. 특히 goroutine처럼 기존 병렬성 개념을 재해석한 구조를 깊이 들여다보면, 언어를 넘어서 시스템 설계나 성능 최적화에 대한 감각을 키우는 데에도 큰 도움이 될 것 같았다. 이번 글에서는 gorout..

담당하여 운영 중인 도메인 서비스에서 RabbitMQ로 이벤트 메시지를 발행하는 과정을 하드하게 운영하고 있다.주요 메시지는 주문/결제 등 고객 서비스에 직결되는 데이터였기 때문에, 단 한 건의 메시지도 누락되면 안 된다는 목표를 가질 수밖에 없었다.하지만 RabbitMQ는 메시지를 보장하는 여러 기법을 제공하고 있고, 이를 잘못 설계하거나 오용하면 "메시지를 보장하려다가 오히려 시스템이 느려지고 불안정해지는" 결과를 초래할 수도 있다.그래서 이번 과정에서 RabbitMQ의 메시지 발행자 입장에서 가능한 메시지 배달 보장 방식들을 전부 정리해 보고, 각 단계의 장단점과 성능 비용에 대한 감을 잡고 서비스에 맞는 골디락스 존을 찾고자 한다. # RabbitMQ 발행자 입장에서의 메시지 배달 보장 8단계메..