우아한남형제들의 주간 미팅 형식은 주간 스프린트 회고와 프로젝트 및 다음 스프린트 방향성에 대해 이야기하는 것으로 구성되어 있습니다. 1. 주간 스프린트 회고 회고는 먼저 일주일 간 각자의 진행 상황 보고로 시작합니다. 이번 스프린트에서 마음에 들었던 점, 개선이 필요한 점에 대해 논의합니다. 이번 주에는 각자의 서비스 개발에 진척이 있었지만 JavaDoc, Test Code, 자원 배치 및 CD 작업이 미완료되었습니다. 추가로 완수해야 할 작업은 미완료된 서비스 개발입니다. 이 세 가지 측면에서 회고한 후 Jira에 체크한 일들을 함께 확인합니다. 이후 이번 스프린트에 대한 후기를 자리에서 남기며, 후기는 좋았던 점과 개선할 점으로 나누어 모두가 함께 이야기합니다. 저는 이번 스프린트에서 애자일 프로세..

우아한 남형제들 서비스에서 팀원끼리 하나 협의를 한 것이 있습니다. 팀원이 사용해야 될 여지가 있다면 문서로 서로 공유하기로 한 것이죠. 그리고 저는 Eureka를 맡아서 개발하기로 했습니다. 이미 Confluence 에다가는 팀원에게 등록하는 법에 대해 공유는 되어 있지만 무료버전 Confluence 는 문서가 Public 하게 공유가 안되어 티스토리에도 옮기게 되었습니다 :) Eureka 란? Eureka is the Netflix Service Discovery Server and Client. The server can be configured and deployed to be highly available, with each server replicating state about the regi..

배경 문제는 'MEMBER' 테이블에 가데이터를 삽입하는 도중, 'ROLE_ID' 필드에 대한 "Unique index or primary key violation" 오류가 발생하면서 시작. 이 오류는 '사용자' 테이블의 'ROLE_ID'에 잘못 적용된 unique 제약조건 때문에 발생했습니다. 문제 해결을 위한 접근 https://stackoverflow.com/questions/10008476/dropping-unique-constraint-for-column-in-h2 Dropping unique constraint for column in H2 I try to drop unique constraint for column in h2, previously created as info varchar(2..

애자일 도입 배경 사실 우아한 남형제들 프로젝트는 시작한 지 벌써 근 2달은 되어갑니다. MSA 고민할바엔 일단 시작해보자라는 말과 함께 시작한 게 작년 12월이니깐요. 팀은 현재 백엔드 4명이고, 필자를 제외하곤 전원 취업후 바쁘게 살아가고 있고, 필자는 현재 취업을 위해 해축갤 이라는 프로젝트를 진행하고 있습니다. 다들 회사나 개인 프로젝트에 치중하느라 우아한 남형제들 프로젝트는 뭔가 진행이 되긴 하지만 사실상 잠정 중단 상태나 다름 없었습니다. 진전은 거의 없었고, 뭘 하긴 하더라도 서로 뭘 하는지 전혀 트래킹이 되지 않았기 때문에. 2023 연말에 주변 정리를 하다 이렇게 하다가는 서로의 시간만 버리겠다고 생각해 서로의 솔직한 프로젝트 회고 및 회의가 필요하다고 느껴 신년 기념 1월 1일에 모이자..

최근 작업한 배달의 민족 '장바구니 추가' 기능에 대한 업데이트와 그 배경에 대해 공유하고자 합니다. 설계상의 오류: 불필요한 유효성 검사 초기 설계에서는 메뉴 ID의 유효성, 재고 상태 확인, 가게 ID의 유효성 등 여러 단계의 검증을 포함했습니다. 작성을 할 때부터 처리해야 하는 유효성 검사도 많은 데다가, MSA 환경이라 분리가 되어 있어 네트워크를 타고 해야 하는 유효성 검사면,, 성능이 무자비하게 안 좋을 거라 생각했습니다. 그래서 이에 대해 팀원들과 주간 회의에서 얘기하다 받은 피드백은 프론트엔드가 어차피 해당 가게의 메뉴를 이미 가져오는 상황에서 요청을 보내는 거라 메뉴 ID의 유효성 검증은 중복되고 불필요한 과정이라는 겁니다. 또한, 재고 상태를 DB에서 관리하는 것이 실제로는 의미가 없다..

오늘은 '결제 취소 기능'의 개발 과정에 대한 글을 쓰러 왔습니다. 초기 설계의 오류 : 결제 서비스의 역할 혼동 초기에 결제 취소 기능을 설계할 때, 사용자가 직접 결제를 취소할 수 있는 시나리오를 고려했습니다. 기존의 모놀리식 방식에서는 이러한 방식이 틀리지 않다고 할 수 있습니다. 왜냐하면 모든 서비스에 대한 코드가 다 하나의 시스템 안에 같이 있기 때문이죠. 그러나 이는 결제 서비스의 본질적인 역할에 대한 오해에서 비롯된 것이었습니다. 결제 서비스는 말 그대로 '결제'라는 행위를 관리하는 것이지, 사용자가 직접 취소를 요청하는 것은 아닙니다. 수정된 프로세스 팀원들과의 논의를 통해 실제 배달의 민족에서 결제 취소를 하기 위해서는 고객센터가 이를 수작업으로 고객한테서 취소 요청을 받고 전달하거나, ..

https://organic-hunter-0ab.notion.site/FCM-60b5f7ebbb1f486a8b139ebe4ea5a09c?pvs=4 이 글은 위 팀 노션에서 서로 공유하기 위한 글이지만, 다른 사람들에게도 공유되면 좋겠어서 옮긴 글입니다 :) 배경 Firebase Cloud Messaging(이하 FCM) 관련해서 user-service는 알람 이벤트를 어떻게 핸들링할지 의뢰가 들어왔습니다. 이 부분에 대해서 협의가 충분히 고려해야 되는 이유는 사용자에게 실제로 가는 알람까지 여러 마이크로서비스의 협업이 동반되기 때문입니다. 간략히 FCM 의 과정을 설명하자면 사용자가 애플리케이션에 로그인할 때 생성되는 FCM 토큰을 활용하여 사용자가 주문 상태 변경과 같은 중요한 이벤트를 실시간으로 받아..