planplan

본문 바로가기

일기 / 가치관 / 회고

개발 고민

카테고리 없음 [여운 Yeowun ] AI/LLM을 활용해 API 스펙 자동 동기화로 업무 효율 높이기 1. 배경팀 프로젝트를 진행하며 핵심 기능 외의 부가 기능들도 계속 기획/추가되는 과도기 상황이었다. 아직 기능 명세서가 구체화 되지 않은 상황속에서 백엔드 팀의 미션은 PM이 기획한 문서가 기술적으로 실현 가능한지 레퍼런스를 검토하고, 기능이 확정되는 즉시 개발에 들어갈 수 있도록 인프라를 미리 준비해두는 것이었다. 궁극적으로는 프론트 개발자가 프론트 개발에만 집중할 수 있도록 API를 최대한 빠르게 제공하는 것이 목표였다. 순조롭게 잘 진행되고 있는 것 같았는데, 예상치 못한 노가다가 존재했다. API의 기능 자체는 변하지 않았지만, 요청/응답 스펙은 세부적으로 계속 바뀌었다. 이 변경 사항을 프론트 개발자가 매번 수기로 확인하고 코드에 반영해야 하는 구조였다. 특히 우리 팀의 프론트 개발자는 1명뿐..
카테고리 없음 60명을 48명으로 깎았다가 결국 상한 자체를 없앤 기록 — 대기열 시스템 만들기 들어가며블랙프라이데이, 매초 20명씩 대기열에서 참여열로 무한히 들어오는 구조를 만든 시점에서, 참여열의 사람들이 아무도 주문하지 않는 상황을 그려봤다. 아무도 주문하지 않으면?스케줄러는 1초마다 20명씩 대기열에서 참여열로 데려온다. 근데 참여열에 들어온 유저가 바로 주문하는 건 아니다. 상품을 구경하고, 고르고, 배송지를 입력하는 동안 참여열에 계속 머물러 있고, 그 사이에도 스케줄러는 멈추지 않는다. 아무도 주문하지 않는 극단적 상황을 그려봤다. TTL 5분 동안 스케줄러가 데려오는 인원은 20명 × 300초 = 6,000명이었다. 6,000명이 참여열에 있는 상태에서 동시에 주문 버튼을 누른다면, DB 커넥션 풀 100개에 6,000건이 몰리게 된다. 대기열을 세운 이유가 이런 동시 요청을 ..
카테고리 없음 머릿속이 복잡해서 일단 그려본 랭킹 시스템 설계 시작하게 된 배경패션 이커머스 도메인을 다루다 보니, 인기 있는 상품을 발견할 수 있는 수단이 부족하다는 게 계속 마음에 걸렸습니다. 유저 행동 데이터(조회, 좋아요, 주문)는 이미 수집되고 있었지만, 정작 이 데이터가 유저에게 직접적인 탐색 가치로 연결되지는 못하고 있었습니다.그래서 "지금 인기 있는 상품을 빠르게 발견할 수 있게 해주자"라는 목표로 일간 상품 랭킹 시스템을 도입하기로 했습니다. 홈 메인의 "오늘의 인기 상품", 상품 목록의 "인기순 정렬", 상품 상세 페이지의 "현재 순위 표시" 같은 기능들을 1인 기초 설계부터 구현해야 하는 미션이 생겼습니다. 랭킹이라는 도메인 고민하기설계를 고민하면서 제가 정리한 랭킹의 특징은 다음과 같습니다.1. 랭킹에는 순서가 있습니다. 순서를 정하려면 정렬 ..
DB 비관적락은 정말 순서를 보장할까? - MySQL의 트랜잭션 스케줄링 CATS 개요낙관락과 다르게 나는 비관락은 순서를 보장하는 매커니즘이라고 생각했었다. 왜? 검색했더니 "작업 순서 보장" 이라는 말을 다른 트랜잭션 요청들의 순서 보장이라고 멋대로 오해했기 때문이다. 여기에 개인적인 유추가 더해졌다. 비관락은 먼저 온 트랜잭션이 락을 잡고 사용하는 동안, 다른 트랜잭션은 커넥션을 점유한 채 타임아웃까지 대기한다. 이 동작에서 자연스럽게 대기 큐가 연상되었고, FIFO 구조라면 도착 순서대로 잠금이 허가될 것이라고 예상했다. 그러나 비관락은 정확한 트랜잭션 요청 순서를 항상 보장하지는 않는다. 왜 그럴까? 전통적으로 MySQL은 트랜잭션의 잠금 허가(Grant)를 순수하게 대기(Waiting) 순서에만 근거해 결정해 왔다. 이 방식을 FCFS(First Come First Se..
카테고리 없음 Claude Code로 개발하며 만든 컨벤션 검증 시스템 — Skills, Hook, ArchUnit, 서브 에이전트 서론컨벤션은 있는데 왜 안 지켜질까? 팀 프로젝트에서 느낀 한계사이드프로젝트 동아리에서 팀 개발을 하면서, 코딩 컨벤션 문서를 꽤 공들여 만든 적이 있다. 패키지 구조부터 Entity 설계 방식, DTO 네이밍 규칙까지 나름 상세하게 정리했다. 그런데 실제로 코드를 작성하기 시작하면 문제가 반복됐다. 하지만 매번 확인하는게 정말 쉽지 않다. 점점 문서를 확인하지 않고 각자의 감으로 작성했다. 주간 회의가 끝나고 나서 따로 컨벤션 관련 이야기하는 시간이 많아졌었다.돌이켜보면 문제의 근본 원인은 컨벤션 문서의 품질이 아니었다. 첫째, 암기에 의존하는 구조였다. 컨벤션이 있어도 결국 개발자가 기억해서 적용해야 했다. 둘째, 피드백 시점이 너무 늦었다. 컨벤션 위반은 커밋 후 코드 리뷰에서야 발견됐다. ..

포스팅

티스토리툴바