icodesiuuuu 님의 블로그

동기 (Synchronous)동기는 순차적으로 실행된다.하나의 작업이 시작되면 끝날 때까지 다음 작업은 진행되지 않는다.즉, 코드의 작성 순서 = 실행 순서라고 보면 된다.@Service@RequiredArgsConstructorpublic class OrderService { private final PaymentService paymentService; private final InventoryService inventoryService; public void order(Long userId, Long productId) { // 1. 결제 paymentService.pay(userId, productId); // 2. 재고 감소 in..

인기있는 콘서트나 스포츠 경기 예매를 하다 보면 항상 대기열이 발생한다. 그러다 보면 드는 생각“아니 서버 좀 늘리면 되는 거 아니야?” 요즘은 AWS, Google Cloud 같은 클라우드 환경이 잘 되어 있어서 트래픽이 몰리면 서버를 유동적으로 늘렸다가 줄이는 것도 충분히 가능한 시대다. 이 질문 자체는 틀린 말이 아니다. 실제로 서버를 늘리는 것도 중요한 대응 방법 중 하나다.그런데 문제는, 예매 시스템은 단순히 ‘서버 개수’만으로 해결되는 구조가 아니라는 점이다. 바로 외부 서비스와의 연동 문제다.예매는 단순히 웹 서버에서 끝나는 작업이 아니라,결제본인 인증알림 전송로그인 및 계정 시스템같은 여러 외부 시스템과 연결되어 동작한다.즉, 내 서버만 아무리 늘려도 함께 연결된 외부 시스템이 버티지 못하..

일반적인 서비스에서는 조회(Read)의 비율이 훨씬 높다. 특히 조회를 할 때 단순 데이터 뿐만 아니라 집계 데이터(count, sum 등)를 함께 보여주는 경우도 많다.예를 들어, 게시글 목록에서 이런 정보를 보여준다고 가정해보자.댓글 수좋아요 수이걸 단순하게 구현해보면SELECT p.id, p.title, (SELECT COUNT(*) FROM comment c WHERE c.post_id = p.id) AS comment_cnt, (SELECT COUNT(*) FROM post_like l WHERE l.post_id = p.id) AS like_cntFROM post pORDER BY p.id DESCLIMIT 20;이렇게 쿼리를 작성할 수 있다.이 쿼리는 논리적으로 정확하지..

DB를 설계할 때는, 조회 기능과 트래픽 규모를 고려해서 설계해야 한다. 예를 들어 하루에 게시글이 100건 정도 올라오는 작은 커뮤니티를 생각해보자. 하루 방문자가 1,000명이고, 한 명이 평균 10번 정도 게시글 목록이나 상세 페이지를 조회한다고 가정하면 하루 조회 수는 약 10,000건이다. 이를 초 단위로 단순 환산하면 평균 TPS는 매우 낮은 수준이다. 반면 하루 게시글이 10만 건 올라오고, 하루 방문자가 100만 명인 대형 커뮤니티는 상황이 완전히 다르다. 사용자 한 명이 평균 20번씩 목록 조회, 상세 조회, 검색을 수행한다고 가정하면 하루 수천만 건의 조회 요청이 발생할 수 있다. 이때 게시글 목록을 가져오는 쿼리가 매번 ORDER BY created_at DESC와 함께 풀스캔을 ..

DAO(Data Access Object)는 데이터에 접근하는 객체DB에 데이터를 CRUD하는 로직을 따로 모아놓은 계층 왜 필요 함?DB 접근 코드는 꽤 지저분하고 반복 됨DB 연결SQL 작성파라미터 바인딩쿼리 실행결과를 객체로 변환자원 정리이걸 서비스 로직에 다 작성하면 비즈니스 로직과 섞여서 코드가 복잡해짐그래서service : 업무 흐름, 비즈니스 로직 담당DAO : DB 접근 담당 1. 역할 분리를 위해예를 들어 “상품을 등록한다”는 기능이 있다고 가정해볼 때, 이 기능에는 두 종류의 일이 섞여 있을 수 있어.비즈니스 로직상품명이 비어 있으면 안 된다가격은 0보다 커야 한다중복 상품명은 안 된다데이터 접근 로직insert SQL 실행select SQL 실행DB 연결 및 결과 매핑이 둘은 성격이 ..

개발을 하면서 테스트 코드를 활용해서 로직을 확인하는 과정이 중요해지고 있음많은 개발자들이 어떻게 하면 테스트 코드를 더 잘 작성하고 활용할 수 있을지에 대해 고민해 왔고, TDD(테스트 주도 개발)도 등장했음 테스트 코드를 작성하는 이유개발 과정에서 문제를 발견할 수 있다테스트 코드를 먼저 작성하든, 비즈니스 로직을 먼저 작성하든 테스트 하는 것은 코드에 잠재된 문제를 발견하는데 큰 도움이 됨. 일부러 오류가 발생할 수 있는 테스트 코드를 작성해서 예외 처리를 확인하거나, 의도한 비즈니스 로직에 맞춰 테스트 코드를 작성해 결과가 잘 나오는지 확인하는 등 애플리케이션 코드를 검증할 수 있음.리팩토링의 리스크가 줄어든다서비스가 개발되면, 계속해서 코드를 추가하고 수정함. 코드를 수정하거나 추가하면 그 코드..

REST API를 호출하면 이런 일이 일어남클라이언트가 서버에 요청POST /usersContent-Type: application/jsonAuthorization: Bearer abc123{ "name": "홍길동", "age": 20}이 요청에는 크게 3가지가 있음요청 라인: POST /users헤더: Content-Type, Authorization바디: { “name” : "홍길동", "age": 20}서버 응답HTTP/1.1 201 CreatedContent-Type: application/json{ "id": 1, "name": "kim"}응답에도 역시 있음.상태코드: 201 Created헤더: Content-Type바디: { "id": 1, "name": "홍길동" } RequestE..

영속성 컨텍스트(Persistence Context) 는 JPA를 이해할 때 가장 중요한 개념 중 하나다. 사실 JPA가 단순한 SQL 자동 생성기가 아니라는 점도, 대부분 영속성 컨텍스트 때문에 가능하다. 쉽게 말하면,영속성 컨텍스트는 엔티티를 관리하는 JPA의 내부 저장소이자 작업 공간이다. JPA는 엔티티를 그냥 DB에 바로 넣고 바로 꺼내는 방식으로 동작하지 않는다. 중간에 영속성 컨텍스트라는 공간을 두고, 여기서 엔티티를 관리한 뒤 필요한 시점에 DB와 동기화한다. 영속성 컨텍스트란?영속성 컨텍스트는 엔티티를 영구 저장하는 환경이라고 표현한다. 여기서 중요한 건 “DB 자체”가 아니라, 엔티티 객체를 관리하는 메모리상의 컨텍스트라는 점이다. 예를 들어 이런 코드가 있다고 해보자.Member me..

객체지향과 관계형 데이터베이스는 애초에 설계 철학이 다르다.객체지향: 현실 세계를 객체, 참조, 상속, 캡슐화로 표현RDB: 데이터를 테이블, 컬럼, PK, FK, JOIN으로 관리그래서 객체를 그대로 DB에 저장하려고 하면 여러 불일치가 생긴다. 이걸 ORM, 특히 JPA가 중간에서 많이 완화해준다.1. 세분성(Granularity)객체는 하나의 개념을 여러 클래스로 잘게 나눠서 표현할 수 있는데, DB는 하나의 테이블로 단순하게 저장하는 경우가 많다.즉, 클래스 수와 테이블 수가 딱 맞지 않는다는 문제다.예시객체class Member { Long id; String name; Address address;}class Address { String city; String street; String zi..

Spring 기반 백엔드 개발을 하다 보면 JPA라는 기술을 자주 접하게 된다. 실제로 많은 자바 프로젝트에서 데이터 접근 기술로 JPA를 사용한다. 그렇다면JPA는 무엇인가?왜 많은 자바 프로젝트에서 JPA를 사용할까?JPA는 어떻게 동작하는 걸까?이 질문을 제대로 이해하려면 ORM, Hibernate, 그리고 객체와 데이터베이스의 차이를 함께 알아야 한다 JPA란?JPA는 Java Persistence API의 약자로, 자바에서 ORM을 사용하기 위한 표준 인터페이스이다.JPA는 ORM 기술 자체가 아니라 ORM을 사용하기 위한 표준 규격이다. 즉, JPA는 이렇게 말한다."자바에서 데이터베이스를 객체로 다루려면 이런 방식으로 사용하자" 예를 들어 JPA에서는 다음과 같은 코드를 사용할 수 있다.M..