Go Gradually - Repository

추천 이전 글: Rabbit MQ의 이름 짓기 [RabbitMQ] Rabbit MQ의 이름 짓기개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다dev.go-gradually.me Rabbit MQ를 이용한 이벤트 송/수신 방식을 설계하려면, 이 또한 계약을 설계해야 한다.프로토콜, API, 메시지 포맷 등을 설계하는 것은 성능 최적화 이상 중요한 백엔드 개발자의 매우 중요한 역할 중 하나이다.MSA 에서 이벤트 기반 메시징을 설계할 때, 다음과 같은 사항들을 고려해야 한다.프로듀서 주체Exchange nameRouting key컨슈머 주체Queue nam..

개발자에게 가장 중요한 역량은 "이름 짓기"이다. 이름을 잘 지어둬야 나중에 읽을 때 빠르고 헷갈리지 않게 읽을 수 있기 때문인데, RabbitMQ 사용 시에는 이름을 지어야 할 부분이 세 군데나 있다. 생산자 선언ExchangeRouting Key소비자 선언QueueBinding key (routing key에 의존적)나는 딱히 이름 짓기에 재능이 없어서 매번 AI에게 도움을 많이 받는데, 적어도 이름을 짓는데 어느정도 규칙이 있어야 나중에 읽을 때 무리가 없기 때문에, 각각의 수행하는 역할과 책임에 집중해서 이름을 짓는 규칙을 정해본다.과거 scheduleMemberNestedDtoMap 이라는 해괴한 이름을 짓고 팀원에게 쓴소리를 들은적도 있었다... 기본적으로 위 세 요소는 각각 다음과 같은 역할..

항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.현 시스템에 대한 감사를 유지하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기.윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것핀잇 프론트 구현핀잇 Auth 구현핀잇 OIDC 연결카페 알바배포 방식 정리이번주에 하지 못한 것DB Delete 작동 방식 깔끔하게 정리하기데이터 지역성 정리푸쉬알림 기능다음주에 할 수 있는 것AI 모델 설계DB Delete 작동 방식 깔끔하게 정리하기코틀린 코루틴 학습다음주에 할 수 없는 것Double DQN 논문 리뷰주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 글 작성API 사용 로깅 - 백엔드 성능 테스트용다음주..

이번 글은 이전 글의 다음 단계인 2, 3단계에 대해 다룹니다.코드는 다음 링크를 통해 확인 가능합니다. GitHub - GoGradually/pinit-authContribute to GoGradually/pinit-auth development by creating an account on GitHub.github.com 첫 MSA 도입, 한번에 다 만들려고 하면 복잡하다.각각 독립적인 기술인 만큼, JWT + OIDC 조합 두 단계로 나눠서 접근하자.목차내 JWT 인증 흐름 먼저 만들기그다음 OIDC 로그인 붙여서 “로그인 수단”만 확장하기회원가입 이벤트 발행 + be 서버에 공개 키 공유해서 인증 연동하기2. OIDC (외부 로그인) 붙이기(0) OIDC의 이해User-Browser사용자가 브라우..

코드는 다음 링크를 통해 확인 가능합니다. GitHub - GoGradually/pinit-authContribute to GoGradually/pinit-auth development by creating an account on GitHub.github.com 첫 MSA 도입, 한번에 다 만들려고 하면 복잡하다.각각 독립적인 기술인 만큼, JWT + OIDC 조합 두 단계로 나눠서 접근하자.목차내 JWT 인증 흐름 먼저 만들기그다음 OIDC 로그인 붙여서 “로그인 수단”만 확장하기회원가입 이벤트 발행 + be 서버에 공개 키 공유해서 인증 연동하기 이번 글에서는 0~1번 내용에 대해 다룬다. 0. 큰 그림 결정하기아키텍처 결정pinit-auth = 인증/토큰 발급 서버pinit-be = 일정/통계..

사실 중요한 건 무엇을 배포하느냐만큼, 어떻게 배포하느냐이다. 소프트웨어 개발은 기획과 설계부터 테스트와 배포에 이르기까지 여러 단계와 페이즈로 이루어진 과정이다.그중에서도 배포(deployment)는 실제로 제품이 최종 사용자에게 전달되는 단계이기 때문에, 소프트웨어 개발 생명주기(SDLC)에서 특히 중요한 단계가 된다. 하지만 소프트웨어 배포는 많은 변수와 위험 요소 때문에 복잡해질 수 있다.모든 개발자는 새 릴리스가 프로덕션을 폭파시키는 그 순간을 두려워한다.화난 사용자들, 한밤중 롤백, 끝없는 디버깅. 배포 과정은 다양한 접근 방식과 도구를 통해 자동화·관리·모니터링할 수 있고, 이를 통해 다음과 같은 점들을 보장할 수 있다.애플리케이션이 최종 사용자에게 신속하게 배포되고, 다운타임을 최소화할 수..

핀잇 백엔드의 핵심 비즈니스 로직의 구현을 마치고, 간단하게 FE를 구현해 사용해보는 도중 통계가 정상적으로 기록되지 않는 문제를 마주했다. 먼저 문제가 생긴 애플리케이션 로직을 찾아보았다.orElseGet으로 새로운 통계 객체 생성 후 save() 를 호출해 저장을 수행하고 있었는데, 이 동작에 문제가 생긴 것처럼 보였다.먼저, 이벤트가 정상적으로 발행되지 않거나, 이에 대한 구독이 이루어지지 않았는지가 의심스러웠다. 그래서 다음과 같이 중단점을 걸고 디버깅을 수행했다.하지만 그 결과는 아래와 같이 중단점에 잘 도착하는 모습을 확인할 수 있었다.또한 값 변경도 잘 되는 것을 확인할 수 있었다.이벤트의 발행/구독에 대한 의심을 걷어낸 나는, 그 다음으로 이루어지는 작업인 SQL에 관심이 생겼다.그렇게 s..

구독 중이던 포스트를 읽던 중 위 영상으로도 유명한 리처드 파인만의 좋은 인용구가 있어 글을 작성해본다.리처드 파인만의 노벨 물리학상 수상 후, 도모나가의 제자이기도 했던 옛 제자 코이치 마노가 축하 편지를 썼다.파인만은 마노 씨에게 지금 무엇을 하고 있느냐고 답장을 보냈다. 이에 대한 코이치 마노의 답장은 다음과 같았다."난류 대기를 통한 전자기파 전파에 대한 몇 가지 응용을 포함하여 결맞음 이론을 연구하고 있습니다… 소박하고 현실적인 유형의 문제입니다." 이에 파인만은 제자에게 다음과 같은 편지를 보냈다.친애하는 Koichi에게, 자네에게서 편지를 받고, 또 자네가 연구소에서 그런 자리를 맡게 되었다는 소식을 들으니 나는 매우 기뻤네. 그런데 편지 내용을 읽어보니 자네가 정말로 슬퍼하고 있는 것 같..

항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기. 윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것프로그래머스 AI추천 문제 풀기카카오 모빌리티 면접오토에버 코테핀잇 백엔드 - 애플리케이션 레이어 & 인터페이스 레이어이번주에 하지 못한 것DB Delete 작동 방식 깔끔하게 정리하기핀잇 프론트 (미완)디자인 토큰 완성레이아웃/라우팅 스켈레톤컴포넌트 조립다음주에 할 수 있는 것배포 방식 정리데이터 지역성 정리다음주에 할 수 없는 것쿠팡이러다 신규되것다.Double DQN 논문 리뷰면접용 CS 재정리 → 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 정..

항상 무언가를 수행하기.체계적인 상태를 유지하기.큰그림 그리고 핵심 짚기.처음부터 끝까지 차근차근 전개하기.보상 체계를 깨끗히 유지하기.입장 중심이 아닌 이익 중심으로 사고하기. 윈-윈 전략 생각하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것프로그래머스 AI추천 문제 풀기핀잇 백엔드 - 도메인 레이어 마무리핀잇 백엔드 - 애플리케이션 레이어이사카카오 면접 준비ACT카페 알바이번주에 하지 못한 것핀잇 백엔드 - 인터페이스 레이어DB Delete 작동 방식 깔끔하게 정리하기다음주에 할 수 있는 것핀잇 프론트 (미완)디자인 토큰 완성레이아웃/라우팅 스켈레톤컴포넌트 조립DB Delete 작동 방식 깔끔하게 정리하기다음주에 할 수 없는 것쿠팡핀잇 백엔드 - 인터페이스 레이어Double DQN 논문 리뷰면..

Get과 Post는 구현 방식이 비교적 단순하지만, Patch의 경우 몇가지 고려해야 할 점이 있다.여기서 외부 라이브러리 사용은 자제하고 싶었다.외부 라이브러리의 변경으로 인한 버그와 같은 문제는 피하고 싶었다.그렇다면 이제 Patch를 구현하기 위해, Patch의 요구사항을 살펴보자.HTTP Patch 메소드데이터의 부분 업데이트를 요청한다.PUT과 달리 멱등성을 보장하지 않는다.캐시가 가능하지만, 본문까지 캐시 키로 봐야 해서 일반적으로 잘 쓰이지 않는다.Patch의 경우, 프론트와 백 중 한 곳에서 "어디에서 변경이 발생했는가"를 확인하는 작업이 필요하다.프론트가 편하게 만들 경우, 백엔드에서 뭐가 변경되었는지 명확히 알지 못하는 문제가 존재한다.그렇다고 각 수정 내용을 하나씩 Post 메소드로 ..

이번주, 지나치게 목표를 높게 잡았다.지킬 수 있을 만큼만 잡을 것항상 무언가를 수행하기.체계적인 상태를 유지하기.보상 체계를 깨끗히 유지하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것프로그래머스 AI추천 문제 풀기핀잇 백엔드 - 도메인 레이어(80%)이번주에 하지 못한 것핀잇 프론트 (미완)디자인 토큰 완성레이아웃/라우팅 스켈레톤컴포넌트 조립다음주에 할 수 있는 것핀잇 백엔드 - 도메인 레이어 마무리핀잇 백엔드 - 애플리케이션 레이어핀잇 백엔드 - 인터페이스 레이어DB Delete 작동 방식 깔끔하게 정리하기다음주에 할 수 없는 것쿠팡Double DQN 논문 리뷰면접용 CS 재정리 → 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 정리코틀린 코루틴 학습 다음주에 해야하는 것프로그래머스 A..

"아프니까 청춘이다" 책의 저자 김난도 씨는 사실 아직도 논란이 많이 되고 있고, "청년층의 적"처럼 여겨지기도 한다.하지만 개인적으로 이 말은 어느정도 맞다고 생각하는 부분이 있어, 조금은 꼰대같을 수 있겠지만 대나무숲처럼 끄적여본다."시스템"화가 잘 되어있는가나는 주변 사람들이 원치 않는 일을 겪었을 때, 대부분의 문제는 시스템 탓이라고 이야기한다.누군가를 위로하거나 응원해줄 때 자주 이야기해주는 말이지만, 사실 속으론 하지 못한 말이 있다.그 시스템을 바꿀 수 있는 것도 사람이다. 그 문제는 이미 "시스템화"되어 있어, 나 뿐만 아니라 그 다음사람도, 그 다다음 사람도 겪게 된다.그 시스템을 바꾸려면, 일시적인 손해(비용)이 발생하기 마련이다.그때, 나는 "이를 감당할 자신이 있는가?"를 물어봐야 ..

문제가 되는 비즈니스 로직일정 간의 사이클 검사Dependency는 from/to 두 개의 schedule을 알고 있다.CycleChecker는 그 중 indegree가 0인 임의의 schedule을 잡고, 의존관계를 탐색하며 사이클이 존재하는지를 파악한다.일정 삭제일정 삭제 시, 해당 일정을 알고 있는 모든 의존관계를 제거한다.즉, Dependency 추가와 삭제 모두 관련된 모든 일정이 관리한다.이전 일정이 완료되었는지 확인일정은 이전 일정을 직접 알고있지 않다.Dependency라는 엔티티를 거쳐서 알고 있다.from.isCompleted()로 사전 완성 일정 체크 일정 간의 사이클 검사일정 간의 사이클 검사에는 Schedule 정보가 필요하지 않다.따라서, ownerId로 해당 사용자의 모든 연관..

항상 무언가를 수행하기.체계적인 상태를 유지하기.보상 체계를 깨끗히 유지하기.다음에 무엇을 해야 할 지 상상하기.이번주에 한 것ADsP쉽다과하게 준비한 감도 없잖아 있지만, 유의미한 학습이었다.쿠팡카페 알바카카오 2차 코테마이다스 코테이번주에 하지 못한 것핀잇 프론트 (미완)디자인 토큰 완성레이아웃/라우팅 스켈레톤컴포넌트 조립다음주에 할 수 있는 것핀잇 프론트 (미완)디자인 토큰 완성레이아웃/라우팅 스켈레톤컴포넌트 조립시행착오다음주에 할 수 없는 것쿠팡Double DQN 논문 리뷰코틀린 코루틴 학습 다음주에 해야하는 것프로그래머스 AI추천 문제 풀기면접용 CS 재정리 → 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 정리

주의: 본 내용은 DB 내용에 대한 기초 지식이 어느정도 있음(DB 스캔의 작동 방식)을 가정하고 작성되었습니다.DB는 백엔드에서 가장 중요한 역할을 수행한다.DB 성능은 연동하는 모든 서버 성능에 영향을 주기 때문에, DB에 존재하는 기능을 전문가 수준으로 깊이 이해할 수 있다면 이상적이겠지만 조금만 신경 써도 DB 성능 문제를 충분히 줄이거나 없앨 수 있다.인덱스 설계예상하지 못한 테이블 풀 스캔은 DB 성능에 좋지 않은 영향을 끼친다.이를 피하기 위해서 보통 인덱스를 사용하는데, 이때 인덱스를 제대로 알고 써야 원하는 성능 효율을 얻을 수 있다.인덱스는 조회 패턴을 기준으로 설계해라.단일 인덱스 vs 복합 인덱스의 차이를 고려해라선택도(Selectivity)를 고려해라가능하다면, 커버링 인덱스를 활..