아래 글은 [스프링캠프 2024] Spring AI : LLM에도 봄이 찾아오다 (황민호)님의 발표를 듣고 정리한 글입니다. 1. 발표자 소개황민호 개발자님은 카카오에서 10년차 개발자로서 다음 클라우드, 다음 검색, 모먼트 광고 플랫폼, 오픈소스 플랫폼 등 다양한 프로젝트를 스프링 부트로 개발해왔습니다. 현재는 AI 교육 자문과 CTO 기술 전략 스텝 역할을 수행하고 있으며, ChatGPT 등장 이후 AI 관련 발표를 활발히 진행하고 있습니다. 2. 생성형 AI의 역사와 현재생성형 AI는 단순한 객체 인식 기술을 넘어, 텍스트, 이미지, 사운드 등 다양한 형태로 정보를 생성할 수 있는 능력을 갖추게 되었습니다. 기존 객체 인식 모델인 YOLO와 같은 딥러닝 모델은 특정 객체를 인식하는 데 주력했지만,..
대규모 트래픽을 고려한 올리브영 아키텍처 구축 프로젝트(2024.08.12. ~2024.08.30.(3주))를 진행하며 기록한 내용을 아카이브 용도로 남깁니다. 금요일에 프로젝트 주제가 발표된 후 그 다음주부터 바로 프로젝트를 진행해야 했기 때문에주말 동안 프로젝트의 방향성을 잡기 위해 올라와 있는 올리브영 테크 블로그 글들을 보며 중요한 점들을 정리했습니다. 가능한 모든 게시글을 확인하며 도움이 되거나 중요한 내용들을 최대한 정리해두었습니다. 그 중 특히 중요했던 두 가지를 간추려 간단히 정리해보았습니다. 1. CI/CD 툴로 Jenkins를 채택하지 않은 이유저희 팀 프로젝트의 경우 결과적으로 Jenkins를 사용하지 않고 ArgoCD와 Gitlab을 이용했습니다.다음과 같은 이유 때문입니다.인용: ..
잔디 일기 서비스의 2차 배포 이후 가장 먼저 구현해야 할 기능은 댓글 알림 기능이라고 판단했습니다. 이 기능은 기존 회원들이 다시 방문하도록 유도할 수 있어, 서비스 활성화에 중요한 역할을 합니다. 알림 기능은 크게 세 가지 방법을 고려했습니다. 웹 브라우저 알림: 사용자 브라우저에서 권한을 요청하고, 실시간으로 알림을 전송할 수 있습니다. 다만, 사용자가 권한을 허용하지 않으면 효과가 제한적입니다.UI 내 알림 기능 추가: 웹 서비스 내부에 알림 확인 기능을 추가할 수 있습니다. 그러나, 서비스를 방문해야만 알림을 확인할 수 있다는 점에서 재방문 유도에는 한계가 있습니다. 또한 프론트엔드 개발자분들의 업무 일정으로 추가 작업이 어려워 새로운 기능 개발이 어려웠습니다.이메일 알림: 현재 구글 로그인 방..
1. Redis와 Kafka를 활용해서 물건 구매 로직을 구현한 이유1. Redis를 이용한 실시간 재고 관리물건 구매 요청이 들어오면 Redis에서 물건 수량을 즉시 감소하도록 설계했습니다. 서비스는 예약된 시간에만 오픈되기 때문에, 서비스 시작 전 Redis에 물건의 초기 수량을 미리 저장해두는 방식으로 준비하고 있습니다. 현재는 물건 수량 감소 로직만 구현되어 있지만, 추후 서비스가 안정화되면 Redis에 물건 수량을 미리 저장하는 로직도 추가할 계획입니다.2. Kafka를 이용한 순차적 DB 반영한 번에 대량의 구매 요청이 들어올 경우를 대비해 Kafka를 사용하여 데이터의 순차 처리를 보장하고자 했습니다. 물건 구매 요청이 발생하면 해당 요청을 Kafka에 기록하고, Kafka의 Consumer..
서비스를 개발할 때 UUID를 Primary Key로 사용하는 방법이 있습니다. 하지만 저는 Member 클래스에만 UUID를 필드로 추가하였고, 그 이유를 정리해 보았습니다. 1. 왜 UUID 사용하지 않아야 할까?UUID는 전역적으로 고유한 식별자를 생성할 수 있어 데이터베이스의 ID로 자주 사용됩니다.하지만 프로젝트를 진행하면서 저장 공간 효율성과 검색 성능을 고려해 UUID를 ID로 사용하지 않기로 결정 했습니다. 1.1. 저장 공간 효율성UUID는 128비트로 길이가 길어, 숫자형 ID보다 더 많은 저장 공간을 차지합니다. 1.2. 검색 성능UUID는 랜덤하게 생성되기 때문에 데이터베이스에서 인덱스를 생성할 때 정렬되지 않은 상태로 저장됩니다.이로 인해 데이터베이스 검색 시 성능이 떨어질 수 있..
최근 프로젝트에서 객체 생성 시 Builder 패턴을 도입할지 고민했지만, 필수 필드 누락으로 인해 객체가 잘못 생성될 위험이 있어 Builder 패턴을 사용하지 않기로 결정했습니다. 이에 대해 간단히 기록해 보았습니다. 1. Builder 패턴의 장점1.1. 가독성 향상Builder 패턴은 복잡한 객체의 생성 과정을 가독성 높게 표현할 수 있습니다.// 예시: Builder 패턴을 이용한 객체 생성Member member = new Member.Builder() .id(1L) .name("Yeseul Hong") .email("yeseul@example.com") ..