JangBaGeum.gif

AI를 이용한 프로덕션 에이전트를 운영하기는 정말 힘들다. AI 민원 처리 에이전트를 개발하였고 현재 운영 중이다. 새로운 기능 개발 / 개선은 지금도 계속 이어가고 있다. 어제 잘 동작하던 에이전트가 오늘 갑자기 다른 게 처리하거나 답을 하는 경우가 많다. 코드는 한 줄도 바꾸지 않았는데, 운영에서 사용자 컴플레인이 들어오거나 QA 테스트 중 뜬금없는 곳에서 확인 요청이 온다. 추적해 보면 결국 프롬프트 한 줄 수정, 도구 추가, 모델 버전 업그레이드 중 하나다. 처음에는 이게 무서웠다. 내가 통제하지 못하는 변수가 너무 많아서, 어디서부터 손을 대야 할지 막막했다. 단위 테스트 패턴은 그대로 안 통하고, 옵서버빌리티 도구는 이미 일어난 일만 보여줄 뿐이다. 그래서 한동안은 "이건 그냥 받아들이는 수밖..

개발자로 일하면 가장 오래 고민했던 주제 중 하나가 DB 모델링 컨벤션이다. 코드에는 ESLint, Prettier 같은 도구가 있어서 팀원 간 스타일을 자동으로 맞출 수 있지만, DB 설계에는 그런 자동화 도구가 없는 것으로 보인다. 결국 사람이 규칙을 정하고, 사람이 지켜야 한다. 이 글은 여러 프로젝트를 거치면서 정리한 나만의 MySQL 모델링 컨벤션을 정리하려고 한다. 요즘 AI를 통한 개발뿐만 아니라 설계도 함께하면서 사소한 컨벤션, 구두로 전해 내려오던 도메인적 규칙 등 모두 콘텍스트에 녹일 수 있도록 정리를 하고 있다. 이도 그 과정 중에 하나이다. 절대적인 정답은 아니고, 실무에서 반복적으로 부딪히며 다듬어 온 기준이다. 팀마다, 도메인마다 맞지 않는 부분이 있을 수 있으니 참고용으로 해도..

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 기반 라우팅우리는 가능한 한 모든 ..