Go Gradually - Repository

코드는 다음 링크를 통해 확인 가능합니다. 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..

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

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

필자는 개발보다 알고리즘을 먼저 접했기 때문에, 휴리스틱한 기법보단 증명을 통한 완벽한 계산에 익숙했다.하지만 최근 직접 서비스를 개발해보고, 다양한 AI-ML 알고리즘을 접하기도 하며 휴리스틱과 근사 방법에 어느정도 익숙해지면서, "엄밀한 증명"만 생각하던 상태에서 벗어나게 되었다.이 과정에서 자연스럽게 "Exact 알고리즘"과 "휴리스틱 알고리즘"의 분류 기준을 생각하게 되었다. Exact 알고리즘정확한 답이 증명으로 보장된 알고리즘 휴리스틱 알고리즘정확한 답이 아니더라도, 정확한 답 수준의 풀이를 반환하는 알고리즘원래의 정의는 이렇지만, 이 정의는 실무에서 알고리즘을 선택하는데에는 약간의 미흡함이 있다고 생각했다.따라서 정의를 다음과 같이 약간 수정했다. Exact 알고리즘정확한 답이 증명으로 보장..

일정 도메인일정 타입집중 작업행정 작업(이메일 회신, 전화, 짧은 보고, 회의 준비)짧은 업무(유지관리 활동, 운동, 청소, 정리, 일기 쓰기)일정 중요도(1~10)일정 예상 소요시간일정 마감 일자현재 일정 상태고정된 일정 여부일정 관계 도메인이전에 마쳐야 하는 일정이후에 수행해야 하는 일정사용자 도메인아이디닉네임수면 시간식사 시간쉬는 날이번주 총 집중 시간이번주 총 업무 시간

본 목록은 일정 관리 제품 "PinIt"의 Use Case로, 핵심적으로 구현해야 하는 필수 기능부터 제품의 특색을 살리는 부가기능까지의 기능 구현 우선순위를 기준으로 1, 2, 3순위로 나타낸 Use Case이다. 1순위일정 추가기능사용자는 일정 추가 버튼을 클릭하여 일정 추가 창을 연다사용자는 그 안에 다음을 입력한다.일정 이름일정 타입일정 마감일자일정 중요도일정 예상 시간이전에 수행해야 하는 일정이후에 수행해야 하는 일정사용자는 일정 자동 배치 버튼을 클릭할 수 있다.시스템은 추천 일정 배치일자를 결정한다.시스템은 입력값을 검증한다.시스템은 입력받은 대로 DB에 일정을 추가한다.사후조건사용자가 일정 배치를 수행하지 않았을 경우, 일정 추가를 선택한 날짜에 해당 일정을 추가한다.일정이 DB에 추가되..

다양한 알고리즘의 고민이전 글에서 이것 저것 수행해보고 난 뒤, 좀 더 다양한 기법들에 대해 트레이드오프를 이해할 필요성을 느낀 나는 다양한 알고리즘을 공부했다. 하지만 이번 MountainCar 환경에서는, 결국 DQN으로 다시 회귀할 수밖에 없었다.그 근거는 다음과 같다.나는 최근 다양한 정책 경사 알고리즘들을 공부해왔는데, 각 알고리즘은 해결하고자 하는 문제가 현재 MountainCar 의 상황과 맞지 않았다.하이퍼파라미터 튜닝은 예술의 영역이고, 숙련자들 또한 기존에 푼 문제와 논문에 존재하는 하이퍼파라미터를 참고하여 하이퍼파라미터를 설정한다는 것을 확인했다. REINFORCEREINFORCE는 가장 기초적인 Policy Gradient Method로, 다음과 같은 이점과 한계를 갖고 있다.이점정..

https://gymnasium.farama.org/environments/classic_control/mountain_car/ Gymnasium DocumentationA standard API for reinforcement learning and a diverse set of reference environments (formerly Gym)gymnasium.farama.org 요구사항 정의Mountain Car MDP는 사인곡선의 바닥에 확률적으로 배치된 자동차로 구성된 결정론적 MDP이다.가능한 동작은 자동차에 양방향으로 적용할 수 있는 가속뿐이다. 이 MDP의 목표는 오른쪽 언덕 꼭대기의 목표 상태에 도달하기 위해 자동차를 전략적으로 가속하는 것이다.Mountain Car Continuous ..