<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>EK Dev Blog</title>
    <link>https://loveAlakazam.github.io/blog/</link>
    <description>Recent content on EK Dev Blog</description>
    <generator>Hugo -- 0.125.7</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 10 May 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://loveAlakazam.github.io/blog/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>항해99 6주차 회고(WIL)</title>
      <link>https://loveAlakazam.github.io/blog/docs/hh-08-week06-remind/</link>
      <pubDate>Sat, 10 May 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/hh-08-week06-remind/</guid>
      <description>Q. 인상깊었던 주제는 무엇이었나요? 분산락과 캐시 전략중 어떤 주제가 더 인상깊었나요?
항해를 하기전 레디스를 사용해왔을때는 JWT 토큰정도로만 해왔습니다. Key value 기반 NoSQL 데이터베이스인 레디스가 단순히 캐싱의 역할을 하지 않고 Lock으로서의 역할을 할 수 있다는걸 이번과제를 통해 새로알게됐습니다. 또한 읽기와 쓰기에서의 캐싱전략이 여러가지가 있다는걸 처음알게됐습니다.
해당 개념을 통해 어떤 구조적/성능적 문제 해결을 가능성을 느꼈나요?
아직까지는 과제를 수행해보면서 어느점이 문제인지, 그에 대한 해결은 무엇인지에 대한 답변이 명확하지 않았습니다. 그래도 떠오르는 한가지는 캐싱쪽에서는 트랜잭션을 접근하기전에 캐시저장소(redis)에서 캐시히트가되면 빠른 응답을 해줄 수 있다는 점입니다.</description>
    </item>
    <item>
      <title>RDBMS 락을 사용한 동시성문제 해결</title>
      <link>https://loveAlakazam.github.io/blog/docs/rdbms-locks/</link>
      <pubDate>Tue, 22 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/rdbms-locks/</guid>
      <description>동시성 문제 (RaceCondition) 여러개의 스레드가 같은 공유자원에 대해서 동시에 읽기/쓰기 접근 요청할 때 공유자원의 데이터의 정합성이 깨지는 현상.
데드락 (DeadLock) 1 2 3 4 화장품가게 에는 립밤 1개, 스킨로션 1개 를 판매하고 있다. - 손님 A가 립밤 1개를 집었다. - 손님 B가 스킨로션 1개를 집었다. 손님 A 는 (B가 집은) 스킨로션을 원하고, 손님 B 는 (A가 집은) 립밤을 원한다.
손님 A의 입장에서는 손님B가 스킨로션을 내려놓을 때까지 기다려야하고 손님 B의 입장에서는 손님A가 립밤을 내려놓을 때까지 기다려야한다.</description>
    </item>
    <item>
      <title>RDBMS(Mysql)에서의 인덱스 개념 정리</title>
      <link>https://loveAlakazam.github.io/blog/docs/rdbms-index/</link>
      <pubDate>Mon, 14 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/rdbms-index/</guid>
      <description>만능은 없다. TradeOff는 있다. 읽기 성능이 좋으면 쓰기성능이 구리고, 쓰기성능이 좋으면 읽기성능에 구려진다.
정규화 쓰기성능을 높임으로써 데이터 중복을 줄이고 일관성을 높인다.
반정규화 읽기성능을 높임으로써 일부 중복을 허용한다.
트랜잭션 격리 수준 Uncommitted Read - 커밋되지 않은 읽기 다른 트랜잭션에서 커밋되지 않은 데이터에도 접근하게 할 수 있는 격리수준 DirtyRead: 커밋되지 않은 트랜잭션에 접근해서 아직 정상반영되지 않은 데이터를 읽는 현상 (해당 데이터는 롤백되어 없어질 수도 있다) Committed Read - 커밋된 읽기 다른 트랜잭션에서 커밋된 데이터에만 접근할 수 있게 하는 격리수준 Non-Repeatable Read: 하나의 트랜잭션에서 동일한 SELECT 쿼리문을 실행했을 때 커밋전의 데이터와 커밋후의 데이터가 읽히면서 다른결과가 생기는 현상 Repeatable Read - 반복가능한 읽기 커밋된 데이터만 읽을 수 있으며, 자신보다 빨리 수행된 트랜잭션에서 커밋한 데이터만 읽을 수 있는 격리 수준</description>
    </item>
    <item>
      <title>정적 팩토리 메소드</title>
      <link>https://loveAlakazam.github.io/blog/docs/factory-methods/</link>
      <pubDate>Sun, 13 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/factory-methods/</guid>
      <description>서론 단위테스트의 목데이터를 만들때 생성자를 호출하게되어 연관관계를 갖는 도메인을 setter로 설정시켜서 목데이터를 생성하는데 점점 무거워지는 불편함을 겪었습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 @Test void 신규_임시예약상태의_예약도메인_생성에_성공된다() { // given long userId = 1L; long concertSeatId = 1L; User user = new User(userId, &amp;#34;은강&amp;#34;); Concert concert = new Concert(1L, &amp;#34;항해와 함께하는 TDD 단위테스트 콘서트&amp;#34;, &amp;#34;항해플러스&amp;#34;); // 👈 도메인 엔티티 생성자를 직접호출!</description>
    </item>
    <item>
      <title>아키텍쳐 고민하기</title>
      <link>https://loveAlakazam.github.io/blog/docs/upgrade-architect/</link>
      <pubDate>Sat, 05 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/upgrade-architect/</guid>
      <description>ERD 개선하기 보완피드백1: 유저와 토큰 테이블 분리하기
보완피드백2: 테이블의 역할을 고민해서 만들기
payments 라는 엔티티에 금액정보가 없어서 책임을 다하지 못할 수 있음.
As-Is (1차 설계) To-Be (2차 설계) 테이블개수를 6개 -&amp;gt; 8개 로 확장했습니다. 토큰(tokens) 테이블 추가 포인트 내역(point_histories) 테이블 추가 payments 테이블에 결제금액(price) 를 추가하여 결제에 대한 책임을 부여했습니다. 2차 설계안 고민포인트 1번을 참고하여, 날짜에서 예약가능여부(is_available)을 추가했습니다. ERD 2차 설계안 고민포인트 대기열토큰의 대기순서를 나타내려면, 토큰테이블에 대기순서를 기재하는게 좋을까요 아니면 대기열큐를 하나의 테이블로 나타내어 대기순서를 기재하는게 좋을까요?</description>
    </item>
    <item>
      <title>항해99 2주차 회고 (WIL)</title>
      <link>https://loveAlakazam.github.io/blog/docs/hh-08-week02-remind/</link>
      <pubDate>Sat, 05 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/hh-08-week02-remind/</guid>
      <description>멘토링하면서 깨달은 점 객체에게 책임을 부여시켜서 분리를 한다면 TDD 도 가능합니다.
우리는 그동안 코딩을하면서 API를 설계하고 개발했다. 코딩으로 설계를 할 수 있다 하지만 견고하거나 명확하지 않을 수 있습니다.
명확한 설계가 뒷받침된다면 코딩은 단순히 명확한 설계를 구체화하는 수단이 될 수 있습니다.
과제 발제시간에 발제 코치인 허재님이 말씀하신 부분이 기억이 남습니다.
설계가 명확하면, &amp;ldquo;코드를 치는 행위&amp;rdquo; 는 목표를 달성하는 &amp;ldquo;수단&amp;rdquo; 이 된다.
설계가 명확하지 않으면, &amp;ldquo;코드를 치는 행위&amp;rdquo; 는 불필요한 &amp;ldquo;노동&amp;rdquo; 이 된다.</description>
    </item>
    <item>
      <title>SpringBoot에서 Swagger 도입부터 트러블슈팅에 배포까지...(?)</title>
      <link>https://loveAlakazam.github.io/blog/docs/swagger-api/</link>
      <pubDate>Fri, 04 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/swagger-api/</guid>
      <description>서론 API명세서는 프론트엔드와 백엔드간의 협업을 위해서 가장 필요한 도구입니다. 백엔드 개발자는 API를 설계하고 공유할때 API명세서를 만듭니다. API 명세서를 다루는 대표적인 툴로는 Swagger가 있습니다. 이번에는 Swagger 을 도입하는 과정과 중간에 겪은 트러블슈팅 해결과정 그리고 더나아가서 직접 github-action으로 배포하는 과정을 공유해보도록하겠습니다.
스프링부트에 스웨거 도입하기 Java: 17 SpringBoot: 3.4.4 build.gradle 에 추가하기 1 2 3 4 5 6 7 dependencies { // Swagger UI implementation &amp;#39;org.springdoc:springdoc-openapi-starter-webmvc-ui:2.0.2&amp;#39; ...생략... } application.yaml 에 추가하기 1 2 3 4 5 6 7 8 9 10 11 spring: application: name: hhplus-concert .</description>
    </item>
    <item>
      <title>항해99 1주차 회고 (WIL)</title>
      <link>https://loveAlakazam.github.io/blog/docs/hh-08-week01-remind/</link>
      <pubDate>Sat, 29 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/hh-08-week01-remind/</guid>
      <description>멘토링하면서 깨달은 점 통합테스트/유닛테스트 의 범위는 정해져있지 않다. 통합테스트에 대한 최소 기준은 내가 호출할 친구가 통합테스트로 검증되어있는지 확인을 합니다. 단위함수가 아닌 2개이상의 함수나 외부의존성이 있는지 e2e 관점으로도 통합테스트를 할 수 있다. 비개발자 를 대상으로 내부동작보다는 호출했을때 실질적은 결과를 보여주는 테스트도 괜찮은 편. 가까운 대상을 테스트하는게 좋다 DTO입장에서는 서비스 메서드함수 한개가 통합테스트가 될 수도 있다. 단위테스트는 테스트 대상외의것들을 (서비스의 의존성을 비롯한 테스트 대상에는 해당되지않지만 서비스에 연결되어있는 대상들을) Mocking 을 해야한다. 객체에게 책임을 부여하면 불필요한 코드를 제외할 수 있다.</description>
    </item>
    <item>
      <title>synchronized 와 ReentrantLock 은 어떤 차이점이 있을까?</title>
      <link>https://loveAlakazam.github.io/blog/docs/multi-thread-locks/</link>
      <pubDate>Wed, 26 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/multi-thread-locks/</guid>
      <description>동시성제어를 테스트하는 것은 단위테스트에 적합할까? 통합테스트에 적합할까? JVM 내에서 동시성테스트를 하려고한다면, synchornized, ReentrantLock, JVM 내 큐(queue)를 사용하는 방법이 존재합니다. 그러나 동시성제어를 테스트할때 통합테스트에서 실행해야되는건지 아니면 유닛테스트에서 테스트를 해야될지 애매할겁니다.
단위테스트는 가장 작은 테스트인만큼 1개 메서드/함수 단위로 독립적인 기능을 빠르게 검증하기 위한 테스트입니다. 동시요청이 발생할 때 큐를 이용해서 순서를 제공해주거나 잠금(locking)연산을 수행하여 다른요청이 접근하지 못하도록 막거나, 큐를 이용해서 순서를 보장해줘야하는 역할까지 검증을 해야되기 때문에 단위테스트만으로는 어려울거같습니다.
즉, 동시성은 여러개의 스레드가 동시에 접근하거나 실행될 때 발생하는 문제를 검증해야하므로, 단일 스레드 환경에서 실행되는 단위테스트만으로는 동시적인 상황을 재현하기가 어렵습니다.</description>
    </item>
    <item>
      <title>객체의 책임(도메인 주도)</title>
      <link>https://loveAlakazam.github.io/blog/docs/object-responsibility/</link>
      <pubDate>Wed, 26 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/object-responsibility/</guid>
      <description>목적 UserPointService 의 충전/사용 메서드를 리팩터링한다 절차지향적인 코드를 객체지향적으로 변경해보자 냄새나는 코드? 포인트 충전 로직 개선시키기 수정 이전 (절차지향적) 포인트 충전 내부로직 플로우 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 // PointServiceImpl.java @Service @RequiredArgsConstructor public class PointServiceImpl implements PointService { @Override public ChargeResponse charge(ChargeRequest request) { long id = request.id(); long amount = request.amount(); UserPoint userPoint = this.</description>
    </item>
    <item>
      <title>동시성 제어 (Concurrency Methods)</title>
      <link>https://loveAlakazam.github.io/blog/docs/concurrency-methods/</link>
      <pubDate>Mon, 24 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/concurrency-methods/</guid>
      <description>동시성제어(concurrency control) 정의 멀티스레드 관점에서의 동시성 제어 여러스레드가 동시에 공유자원인 프로세스의 데이터, 파일, 힙, 코드 를 접근하는 것을 제어하는 것을 의미합니다.
멀티스레드 환경의 스레드는 메인메모리 로부터 값을 복사하여 CPU 캐시에 저장하여 작업을 합니다.
CPU가 2개 이상이라면 멀티스레드 환경에서 각 스레드는 서로다른 CPU에서 동작하고 있으며 이는 각 스레드가 같은 변수에 대해 읽기/쓰기 동작을 수행할 시 각 CPU 캐시에 저장된 값이 다르기 때문에 변수값 불일치 문제가 발생합니다.
이러한 불일치 문제를 해결하기 위한 방법인 동기화 기법이 필요합니다</description>
    </item>
    <item>
      <title>프로세스 동기화</title>
      <link>https://loveAlakazam.github.io/blog/docs/concurrency-theory/</link>
      <pubDate>Sun, 23 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/concurrency-theory/</guid>
      <description>프로세스 동기화 동시성제어에는 운영체제 프로세스의 상호배제 동기화 개념들과 많이 연결되어 있습니다. 그래서 관련용어에 대해 전공서적을 읽어보고 정리해봤습니다.
동기화(synchronization) 프로세스들 사이의 수행시기를 맞추는 것 을 의미하며, 프로세스 동기화 라고도 정의합니다. 프로세스들 사이의 수행시기를 맞춘다 함은 특정 자원에 접근할때 하나의 프로세스만 접근하거나 프로세스를 올바른 순서대로 실행하는 것을 두가지를 일컫습니다.
실행순서제어 를 위한 동기화: 동시에 실행되는 프로세스를 올바른 순서대로 실행하는 것을 의미합니다.
상호배제 를 위한 동기화: 상호배제는 공유가 불가능한 자원, 동시에 접근이 안되는 자원을 동시에 접근하지 못하게 하는 것을 의미합니다.</description>
    </item>
    <item>
      <title>항해를 시작하는 마음가짐</title>
      <link>https://loveAlakazam.github.io/blog/docs/hh-start/</link>
      <pubDate>Sat, 22 Mar 2025 14:34:00 +0900</pubDate>
      <guid>https://loveAlakazam.github.io/blog/docs/hh-start/</guid>
      <description>지금까지의 회고 현재는 스스로 찾아야되고 병행을 해야했지만, 나를 더 디벨롭하고 싶습니다.
시간관리의 중요성을 느꼈고, 늦게 출발하고 남들보다 뒤처지기도 했습니다. 이제는 더이상 뒤쳐지고 싶지 않습니다.
느리다는 이유로 많이 회피해왔던 것도 있고 자신감이 없어지기도 했습니다. 남과 비교하면서 나를 깎아 내렸으니까요. 그치만 계속 비교로 나를 채찍질하기보다는 내가 느린걸 인정하고 나의 페이스대로 묵묵히 꾸준히 문제를 하나씩 해결해나가고 싶습니다.
항해플러스에 참여한 계기 단순 CRUD API 설계 및 개발이 아닌 한단계 더 나아가고 싶습니다.
실무진과 선배개발자들은 어떤 코드/설계/철학을 원하는지 궁금합니다.</description>
    </item>
  </channel>
</rss>
