사용자를 1000명 모아본 서비스는 성공한 서비스일까?
·
카테고리 없음
AI 시대 신입의 딜레마요즘 Codex, Claude Code 같은 도구들과 함께하면서 개발 생산성이 눈에 띄게 높아졌다. 그런데 아이러니하게도, 이 생산성의 향상은 곧 취업 시장에 떨어질 나를 불안하게 만든다. 채용 시장의 문을 뚫으려면 어떤 방향을 추구해야 할까? LLM보다 신입이 더 나을 수 있는 점은 과연 뭘까? 이런 고민들이 머릿속을 떠나지 않는다. 소프트웨어 마에스트로 과정에 참여하면서 현업 시니어 멘토들을 여러 분 만났는데, 많은 분들이 비슷한 이야기를 했다. 어중간한 신입을 뽑을 이유가 없다는 것이다. 돈을 들여 신입에게 월급을 주는 것보다, LLM으로 확장할 수 있는 생산성이 회사 입장에서는 더 크다는 판단이 이미 현장에 퍼져있었다. 이런 회의감을 안고 지내던 중, 담당 엑스퍼트님과의 미..
DB의 물리적 조인
·
카테고리 없음
서론지금까지 학습했던 Join 쿼리는 inner join, outer join, cross join, self join 같이, 쿼리문에 명시하는 정보가 전부였다.그러나 이는 논리적 조인만을 이야기하는 것으로, 실제로 DB가 이 조인 쿼리를 어떻게 물리적으로 조인해오는지는 다른 관점에서 보아야 한다.즉, 우리가 조인 쿼리를 튜닝하여 성능을 개선한다는 것은, 정확히는 쿼리문만을 보고는 이야기할 수 없다.쿼리문만을 보고 튜닝한다는 것은 말이 안된다. 성능 개선 튜닝을 하려면 실행 환경을 꼭 보아야 한다.물리적 조인Nested Loop Join동작 방식가장 단순한 이중 루프이다. 외부 테이블이 작고, 내부 테이블에 좋은 인덱스가 있을 때 빛을 본다.외부 테이블의 각 행마다 내부 테이블을 반복적으로 탐색해, 조인..
Spring 이벤트 발행 - 소비 패턴
·
카테고리 없음
Spring의 이벤트 발행 - 소비 패턴Order가 완료되면 OrderCompletedEvent를 발행하고, 이 이벤트를 소비하는 로직이 따로 존재한다고 가정하자.AbstractAggregateRoot 없는 순수 Spring Event이벤트 발행@Service@RequiredArgsConstructorpublic class OrderService { private final ApplicationEventPublisher publisher; private final OrderRepository orderRepository; @Transactional public void complete(Long orderId) { Order order = orderRepository.fi..
Java의 Lock 매커니즘과 Lock Reentrancy
·
카테고리 없음
Java에서 임계구역을 보호(상호 배제, mutual exclusion)하기 위하여 대표적으로 두가지 락 매커니즘을 사용할 수 있다.synchronizedpublic class SynchronizedExample { private int counter = 0; // synchronized 메서드 → this 객체의 모니터 락을 사용 public synchronized void methodWithKeyword() { ... } // synchronized 블록 → 동일하게 this 객체의 모니터 락을 사용 public void methodWithBlock() { synchronized (this) { ... } }}..
L4/L7 Load Balancer (TCP 3-way handshake 시나리오)
·
Network
Load Balancer (로드 밸런서)란?다중 서버 문제단일 서버 환경에서, 서버 성능에 의해 병목을 겪는다면, Scale up 또는 Scale out을 고려해야 한다. Scale up은 단일 서버 환경은 유지하는 대신, 서버 자체 성능을 올려 병목을 해결하는 방법이고, Scale out은 서버 개수를 늘려 처리량을 늘려서 병목을 해결하는 방법이다. Scale up을 하더라도, 서버가 SPOF(단일 장애점, Single Point Of Failure)가 될 가능성이 있기 때문에 우리는 Scale Out을 고려하는 상황이라고 해보자. 즉, 단순하게 서버가 한대에서 두대로 늘어난 상황이다.클라이언트가 우리 서버를 접근하려면 도메인 네임을 통해 접근해야 한다. 그런데 도메인 네임은 IP와 1:1로 매칭될 것..
권한 변경 이벤트: AT는 어떻게 대응해야 할까? 에 대한 고찰
·
Project
서론지금까지 프로젝트를 하며 토큰 방식 인증에 대해 아무런 의문을 가지지 않고 사용해 왔다. 기본 원칙은 다음과 같다.AT TTL은 짧게, RT TTL은 길게AT에 유저의 권한을 포함한 기본 정보 (민감 정보는 제외하고..) 를 담아두기AT 만료 후 RT를 통한 AT 갱신 시, RTR 방식 적용프로젝트를 장기적으로 진행하며 권한 변경 API 등을 설계하던 중, 이런 의문도 들기 시작했다.이미 AT를 발급받은 유저의 권한을 변경하는 이벤트가 일어나면?-> 이전 권한을 가진 AT는 서버에서 어떻게 대응해야 하는가?토큰 방식 인증/인가는 stateless 하기 때문에 (정확하게는 AT에만 해당하는 말이지만), 서버는 AT만을 보고 권한 판단을 할 수 밖에 없다. 이렇게 중간에 권한 변경이 일어난다면, 인증 구..
AWS CDK: AWS CloudFormation을 추상화하자
·
CI&CD
지난 주 토요일 AWS Community Day 2025에 참여했다. 5월에 참여했던 Student Community Day와는 다르게, 이번에는 학생들 뿐만 아니라 AWS 인프라를 사용하는 다양한 사용자(주로 현직 개발자 등..) 분들이 모두 참여할 수 있는 날이었다. 그래서인지 세미나의 주제도 상당히 큰 규모를 가정하고 말하고 있었고, 솔직히 내 기준에는 조금 어려웠기도 했다. 다음 해에 예정된 커뮤니티 데이까지, 인프라에 대한 인사이트를 넓히고자 한다. Student Community Day 2025 에서는 Terraform이라는 IaC 도구를 블로그 글로 다루며 AWS CloudFormation과도 비교했었다. 이번 Community Day에서는 여기에서 더 나아가 CDK 라는 도구를 알게 되었는..
LocalTime.MAX 사용 시의 DB 반올림 이슈
·
Spring
문제 상황진행하는 프로젝트에서, 특정 날짜와 범위가 주어지면, 해당 범위의 스케줄을 모두 조회해오는 쿼리가 있었다.예를 들면, 요청 중앙값이 2025-09-15이고 요청 범위가 7이라면, 2025-09-12 ~ 2025-09-18 기간의 스케줄을 조회해오는 쿼리였다.Service Layer@Transactional(readOnly = true)public List getSchedule(ScheduleRequestParam request) { LocalDate median = Optional.ofNullable(request.median()).orElse(LocalDate.now()); // 요청 중앙값 Integer range = request.range(); // 요청 범위 LocalD..
Terraform으로 Infra를 Code로 관리하자!
·
CI&CD
지난주 토요일 AWS Student Community Day에 참여했다. 많은 연사자분들이 클라우드에 관한 유익한 이야기를 해주셨는데, 그중에 Terraform이라는 흥미로운 기술을 알게 되어, 들은 내용을 정리하면서 조금 더 알아보았다.(사담이지만, AWS Korea가 위치한 역삼 센터필드는 정말 신기했다. 엘레베이터 타기 전에 터치패드로 층수 선택하고, 내부에 층 버튼이 없는 엘리베이터는 살면서 처음봤다..) IaC란?Terraform이 무엇인지 이해하려면 먼저 IaC가 무엇인지 알아야 한다. IaC(Infrastructure as Code)란, 인프라, 즉 서버나 데이터베이스 등을 코드로 정의하여 자동화하고 재현 가능하게 관리하는 방식이다. 재현 가능하다 함은 즉, 어느 개발자가 어느 환경에서 실행..
정형 데이터를 담는 값 타입 컬렉션을 대체해보자
·
카테고리 없음
요구사항: 푼 문제 데이터를 어떻게 효율적으로 저장할 것인가?우리 학회에서 진행 중인 프로젝트는 Solved.ac API를 사용해 백준에서 푼 문제 데이터를 불러오고 있다. 이때 각 학회원의 푼 문제 수는 Solved 엔티티에 저장하며 문제 티어와 사용자를 기준으로 각 데이터를 구분하고 있다. 이러한 방식에는 큰 문제가 있다. 백준에서는 문제 티어가 Unrated부터 Ruby 1까지 총 31단계로 나뉘는데, 이는 즉 Solved 테이블의 row 수가 (학회원 수) x 31이 된다는 의미이다. 학회원이 학기마다 유동적이지만 보수적으로 잡아도 100명인데, 이는 즉 row 수만 3000여개가 될 수 있다는 말이다. 이는 성능 및 유지보수 면에서 너무 비효율적인 방법이라고 생각했다.그렇다고 각 난이도에 대해 ..