26기에서의 아쉬움Nexters 26기 때 나는 유저가 아닌 내 머릿속 시나리오에 집착하고 있었다. PM으로서, 아래의 슬로건을 걸고 프로젝트를 시작했다.주변 사람들이 각자의 삶에서 의미를 발견하고, 그 의미를 통해 행복을 찾길 바랍니다.그러기 위해선 자기 자신의 가치관을 알아가는 것이 중요하다고 생각합니다. 우리 팀은 Schwartz의 가치 이론에 기반한 자기 발견 앱인 Loopy를 만들었다.UT에서 크게 불편하다는 얘기를 듣지 못했고, 나는 문제가 없다고 착각했다.유저들이 침묵한 건 만족해서가 아니라 우리가 짠 시나리오를 벗어날 수 없었기 때문이었다. 결과적으로 잘못 잡은 컨셉으로 인해 사용하기 불편한 UI/UX가 만들어졌고, 결과를 좋지 못했다.아쉬운 점이 많았지만, 배운 게 있었다. 27기에는 다..

선착순 이벤트 시스템을 설계한다고 가정해보자. 요구사항은 아래와 같다.요구사항:매일 제한된 수량의 무료 체험 제공선착순 N명 정확히 선정1명만 1개만 주문 가능동시 요청 처리 필수일별 재고 수량 기록 필요단일 데이터베이스 시스템, 여러 개의 서버 컨테이너가장 중요한 것은 동시성 제어이다.100개의 재고가 있을 때 동시에 1,000명이 요청하면 어떻게 정확히 100명에게만 제공할 수 있을까? 이때 일반적으로 제시되는 해결책들은 아래와 같다.비관적 락(SELECT FOR UPDATE)낙관적 락(JPA @Version)데이터베이스 네임드 락Redis 분산 락하지만 단일 데이터베이스 환경에서 분산 락은 오버엔지니어링일 수 있고, 낙관적 락은 재시도 로직이 복잡하며, 비관적 락은 대기 시간이 길어질 수 있다.이 ..

너무 느린 외부 API우리 팀은 외부 시스템과의 연동 프로젝트를 진행하게 되었다. 요구사항은 간단해 보였다. "해당 일자에 주문이 가능한지 외부 API를 통해 확인할 수 있어야 한다." 하지만 실제로 구현해보니, 고객에게 정확한 정보를 전달하기 위해선 한 화면에서 40~60건의 날짜별 배송 계획을 한 번에 조회해야 했다. 병렬 처리를 적용했음에도 불구하고 API 응답 시간은 500ms에서 1초, 심지어 요청이 여러 번 겹치면 그 이상 소요되었다. 연동사에서 제공해준 bulk API를 사용했는데 오히려 더 느려졌다.사용자가 주문 가능 일자를 확인할 때마다 1초 이상을 기다려야 한다니, 이건 명백히 사용성에 심각한 문제였다. 우리는 데이터가 일자 단위로 예측 가능하고 실시간이 덜 중요하다는 점을 주목했다.캐..

Spring에서 @Transactional(readOnly = true)는 DirtyChecking 모드를 Manual 모드로 바꿔줘 성능 최적화를 위해 사용된다고 알려져 있지만, 오히려 불필요한 JDBC 호출로 인해 성능이 저하될 수 있다. 이 글은 Elastic APM을 통해 확인한 실제 호출 로그를 바탕으로 readOnly 트랜잭션이 성능에 어떤 영향을 주는지 분석하고, 실무적으로 더 나은 대안을 제시한다. 아는 사람만 아는 @Transactional의 비밀다음 API는 @Transactional(readOnly = true)로 선언된 Service 메소드를 호출한다. Elastic APM을 통해 추적한 결과, 해당 API는 단 2개의 SELECT 쿼리만 실행함에도 불구하고, 여러 번 JDBC 호출..

시작할 때의 마음글또 9기가 좋았다.커뮤니티에 속해 다른 사람들과 교류하고, 글을 쓰며 발전해나가는 내 모습이 마음에 들었다. 그래서 10기에도 참여했다. 마지막 글또를 시작하며 몇 가지 목표를 세웠었다.즐기기한 달에 한 명씩 알아가기일주일 앞서서 글 제출하기그렇게 부담스럽지 않은 목표였다.글또 9기 때처럼 매일 야근에 시달리고 있는 시기도 아니었기에, 이번엔 좀 더 여유롭게 할 수 있으리라 생각했다.  게다가, 이번엔 회사 동료분과 함께 하는 활동이었기에 심리적 부담도 덜햇다.'동료가 커뮤니티 활동에 참여하면 나도 껴야지~''다른 활동에 참여할 때, 회사 분들에게 권유도 해봐야지~'그런 긍정적인 생각으로 시작했다. 하지만 우려했던 일이 결국 벌어지고 말았다."지금도 벌여 놓은 일이 많은데, 글또 커뮤니..

당신의 애플리케이션은 안전한가요?"혹시 서비스 운영 중 아무런 이상이 없어 보이던 시스템이 갑자기 느려지고, 응답 시간이 증가하며, 결국 장애로 이어진 경험이 있지는 않나요? 우리가 흔히 간과하는 작은 코드 한 줄이 애플리케이션 성능 저하와 서버 장애를 초래할 수 있다는 사실, 알고 계셨나요?" 이런 문제는 대부분 메모리 관리의 작은 실수에서 시작된다. 애플리케이션이 실행되는 동안 메모리는 끊임없이 할당되고 해제된다. 특히 Java의 JVM 메모리 관리 방식을 제대로 이해하지 못하면, 시스템 성능 저하와 장애를 초래하는 메모리 누수(memory leak)가 발생하여 시스템 성능이 점점 저하될 수 있다.위 그래프는 JVM 메모리 사용량을 보여준다. 특정 시점에 메모리 사용량이 급격히 증가하고 있다. 많은 ..