Seminar/#7 #12

oOccasio · 2025-12-26T03:17:49Z

🔥Pull requests

👷 과제 구현

필수과제

앱쟁 신청하기
기경, 밋업 열정적으로 참여하기
아티클에 댓글 추가히기

선택과제

캐싱으로 성능 최적화
대용량 데이터 처리 및 정렬 최적화
인프라 설계 시각화
테스트 코드 도입(일부)
실시간 채팅(하나의 큰 실시간 채팅방 구현)
N+1 개선 및 프로젝션

구현한 내용에 대해서 설명해주세요과 고민한 점

Comment + Member - N+1 문제

Comment의 작성자인 Member를 가져오는데서 나오는 N+1 문제

2025-12-25T21:09:52.510+09:00  INFO 9120 --- [assignment] [nio-8080-exec-2] o.s.a.g.s.f.JwtAuthenticationFilter      : Authentication Successful: JwtAuthenticationToken [Principal=org.sopt.assignment.global.security.info.UserPrincipal@61afdbf5, Credentials=[PROTECTED], Authenticated=true, Details=null, Granted Authorities=[ROLE_USER]]
Hibernate: 
    select
        count(*) 
    from
        articles a1_0 
    where
        a1_0.id=?
Hibernate: 
    select
        c1_0.id,
        c1_0.article_id,
        c1_0.content,
        c1_0.created_at,
        c1_0.is_update,
        c1_0.member_id,
        c1_0.modified_at 
    from
        comments c1_0 
    left join
        articles a1_0 
            on a1_0.id=c1_0.article_id 
    where
        a1_0.id=? 
    limit
        ?
Hibernate: 
    select
        m1_0.id,
        m1_0.birthday,
        m1_0.created_at,
        m1_0.email,
        m1_0.gender,
        m1_0.modified_at,
        m1_0.name,
        m1_0.password,
        m1_0.role 
    from
        members m1_0 
    where
        m1_0.id=?

로그를 보면 select 를 3개를 날리는 것을 볼 수 있음

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getComments(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findByArticleId(articleId, pageable).map(GetCommentResponseDto::from));
    }

Article이 존재하는지에 대한 판단을 하는 articleId인 부분 한개
그리고 commentRepository에서 comment와 member를 부분에서 2가지를 가져오는 모습을 보여줌

→ 이를 fetch Join으로 해결

@Query("SELECT c FROM Comment c JOIN FETCH c.member WHERE c.article.id = :articleId")
    Page<Comment> findByArticleId(Long articleId, Pageable pageable);

하지만 Pagination과 Fetch Join은 같이 사용할 수 없는 것으로 알고 있음

LIMIT은 호출한 객체 기준으로 가져오는 것이 아닌 row기준으로 SELECT하기 때문에 한 객체에 여려가지의 객체가 Join되어 있는 경우면 그 행의 수만큼 다른 객체의 결과가 안보임
즉 페이징이 꼬여버리기 때문에 Hibernate는 DB 페이징 방식이아니라 메모리 페이징 방식을 사용하게 되고
메모리 페이징은 당연히 모든 객체를 가져온 후 페이징하는 것이기 때문에 메모리 초과가 일어나고 성능이 매우 안좋아짐

→ @OneToMany 의 경우는 이런 문제가 발생하지만 @ManyToOne 의 경우에선 이런문제가 일어나지 않음!

→ 그 이유는 한객체당 하나의 Member를 가져오기 때문에 여러가지 객체가 Join될 가능성이 없음!

2025-12-25T21:42:48.477+09:00  INFO 10018 --- [assignment] [nio-8080-exec-1] o.s.a.g.s.f.JwtAuthenticationFilter      : Authentication Successful: JwtAuthenticationToken [Principal=org.sopt.assignment.global.security.info.UserPrincipal@56a340a8, Credentials=[PROTECTED], Authenticated=true, Details=null, Granted Authorities=[ROLE_USER]]
Hibernate: 
    select
        count(*) 
    from
        articles a1_0 
    where
        a1_0.id=?
Hibernate: 
    select
        c1_0.id,
        c1_0.article_id,
        c1_0.content,
        c1_0.created_at,
        c1_0.is_update,
        c1_0.member_id,
        m1_0.id,
        m1_0.birthday,
        m1_0.created_at,
        m1_0.email,
        m1_0.gender,
        m1_0.modified_at,
        m1_0.name,
        m1_0.password,
        m1_0.role,
        c1_0.modified_at 
    from
        comments c1_0 
    join
        members m1_0 
            on m1_0.id=c1_0.member_id 
    where
        c1_0.article_id=? 
    limit
        ?

후에, 로그를 다시보게 되면 하나의 select문으로 Comment와 Member를 조회중인 것을 볼 수 있음

→ 하지만 내가 필요한건 멤버 이름인데 Member의 모든 필드를 조회하는 모습…

최적화하기 - Projection과 쿼리

Option1 - DTO 를 직접 조회하기 (JPQL Projection)

// CommentRepository
@Query("""
    SELECT new org.sopt.assignment.comment.dto.response.GetCommentResponseDto(
        c.id,
        c.content,
        c.member.id,
        c.createdAt
    )
    FROM Comment c
    WHERE c.article.id = :articleId
    """)
Page<GetCommentResponseDto> findCommentDtosByArticleId(
    @Param("articleId") Long articleId, 
    Pageable pageable
);

장점
- Member 테이블 건드리기 X
- 필요한 컬럼만 SELECT 가능
- 타입 안전함
단점
- DTO 생성자 필요(Record면 ㄱㅊ!)
- 패키지 경로 하드코딩

Option2: Interface Projection

// DTO 대신 interface
public interface CommentSummary {
    Long getId();
    String getContent();
    Long getMemberId();  // c.member.id
    LocalDateTime getCreatedAt();
}

// Repository
@Query("SELECT c.id as id, c.content as content, c.member.id as memberId, c.createdAt as createdAt " +
       "FROM Comment c WHERE c.article.id = :articleId")
Page<CommentSummary> findCommentSummariesByArticleId(@Param("articleId") Long articleId, Pageable pageable);

장점
- 패키지 경로 하드코딩 없음
- DTO 클래스 불필요
- 간단함
단점
- Interface라서 불편함(생성자, 메서드 추가 불가)
- 테스트 어려움(Mock 필요) ← 생성자가 없음
- JSON 직렬화 시 Getter의존 ← 필드가 없음
- 불변성 보장 안됨
쓰는 시기
- 간단한 조회용
- Controller에서 바로 반환
- 변환 로직 불필요

Option3: 네이티브 쿼리

@Query(value = """
    SELECT 
        c.id,
        c.content,
        c.member_id,
        c.created_at
    FROM comments c
    WHERE c.article_id = :articleId
    """, nativeQuery = true)
Page<Object[]> findCommentsByArticleIdNative(@Param("articleId") Long articleId, Pageable pageable);

장점
- DB 특화 기능 사용 가능(MySQL 함수 등)
- 복잡한 쿼리 작성 쉬움
- 성능 최적화 극대화(인덱스 힌트)
단점
- DB 종속적(MySQL → PostgreSQL 전환 시 수정)
- 타입 안전성 없음(Object[] )
- 수동 매핑 필요
- 오타 컴파일시 못잡음

EntityGraph는 힌트이고 Fetch Join은 명령이다

Fetch Join (INNER JOIN) - 명시적으로 조인하라고 하는 것, JPQL 표준 키워드, 명시적 페치
EntityGraph (LEFT JOIN) - Hint 제공, 선택적 최적화, 느슨한 처리

Command(명령) vs Hint

명령
- 반드시 이렇게 해야하는 것
- JPA 구현체는 무조건 따르게 됨
힌트
- 이렇게 하면 좋을것 같은데라는 느낌
- JPA 구현체가 무시할 수도 있음(대부분 실행함)

JPA Hint 종류

Query Hint

@QueryHints({
    @QueryHint(name = "org.hibernate.readOnly", value = "true"),
    @QueryHint(name = "org.hibernate.fetchSize", value = "50")
})
Page<Comment> findAll(Pageable pageable);

EntityGraph(특별한 힌트)

@EntityGraph(attributePaths = {"member", "article"})
Page<Comment> findAll(Pageable pageable);

// "member랑 article 같이 가져오면 좋겠어~"

Fetch Mode Hint

@Fetch(FetchMode.JOIN)
private Member member;

// "가능하면 JOIN으로 가져와~"

힌트의 특징

선택적 적용

// Hibernate는 이 힌트 적용
@QueryHint(name = "org.hibernate.readOnly", value = "true")

// 다른 JPA 구현체(EclipseLink)는 무시할 수 있음

보장안됨

@EntityGraph(attributePaths = {"member"})
// "member를 조인해줘"라고 제안
// Hibernate가 상황에 따라 안 할 수도 있음 (실제론 거의 적용)

성능 최적화 목적

// 기능 변경 X, 성능만 개선
@QueryHint(name = "org.hibernate.cacheable", value = "true")

Test Code 작성

V1 → N+1 문제 해결 Fetch Join 적용

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getCommentsV1(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findByArticleId(articleId, pageable).map(GetCommentResponseDto::from));
    }

V2 → DTO Projection

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getCommentsV2(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findCommentDtoByArticleId(articleId, pageable)
                .map(GetCommentResponseDto::from));
    }

V3 → Interface Projection

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getCommentsV3(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findCommentSummariesByArticleId(articleId, pageable)
                .map(GetCommentResponseDto::from));
    }

V4 → Native Query

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getCommentsV4(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findCommentsByArticleIdNative(articleId, pageable)
                .map(GetCommentResponseDto::from));
    }

V5 → N+1 문제 해결 전

@Transactional(readOnly = true)
    public PageBaseDto<GetCommentResponseDto> getCommentsV5(Long articleId, Pageable pageable) {

        articleService.validateArticleExists(articleId);

        return PageBaseDto.from(commentRepository
                .findCommentByArticleId(articleId, pageable).map(GetCommentResponseDto::from));
    }

테스트코드

@Test
    @DisplayName("Fetch Join 만")
    void V1_성능_측정() {
        Pageable pageable = PageRequest.of(0, 10);

        long startTime = System.currentTimeMillis();

        PageBaseDto<GetCommentResponseDto> result =
                commentService.getCommentsV1(1L, pageable);

        long endTime = System.currentTimeMillis();

        System.out.println("V1 실행 시간: " + (endTime - startTime) + "ms");
    }

    @Test
    @DisplayName("DTO Projection")
    void V2_성능_측정() {
        Pageable pageable = PageRequest.of(0, 10);

        long startTime = System.currentTimeMillis();

        PageBaseDto<GetCommentResponseDto> result =
                commentService.getCommentsV2(1L, pageable);

        long endTime = System.currentTimeMillis();

        System.out.println("V2 실행 시간: " + (endTime - startTime) + "ms");
    }

    @Test
    @DisplayName("Interface projection")
    void V3_성능_측정() {
        Pageable pageable = PageRequest.of(0, 10);

        long startTime = System.currentTimeMillis();

        PageBaseDto<GetCommentResponseDto> result =
                commentService.getCommentsV3(1L, pageable);

        long endTime = System.currentTimeMillis();

        System.out.println("V3 실행 시간: " + (endTime - startTime) + "ms");
    }

    @Test
    @DisplayName("Native Query")
    void V4_성능_측정() {
        Pageable pageable = PageRequest.of(0, 10);

        long startTime = System.currentTimeMillis();

        PageBaseDto<GetCommentResponseDto> result =
                commentService.getCommentsV4(1L, pageable);

        long endTime = System.currentTimeMillis();

        System.out.println("V4 실행 시간: " + (endTime - startTime) + "ms");
    }

    @Test
    @DisplayName("N+1 문제")
    void V5_성능_측정() {
        Pageable pageable = PageRequest.of(0, 10);

        long startTime = System.currentTimeMillis();

        PageBaseDto<GetCommentResponseDto> result =
                commentService.getCommentsV5(1L, pageable);

        long endTime = System.currentTimeMillis();

        System.out.println("V5 실행 시간: " + (endTime - startTime) + "ms");
    }

    @Test
    void 전체_성능_비교() {
        Pageable pageable = PageRequest.of(0, 10);

        long v1 = measure(() -> commentService.getCommentsV1(1L, pageable));
        long v2 = measure(() -> commentService.getCommentsV2(1L, pageable));
        long v3 = measure(() -> commentService.getCommentsV3(1L, pageable));
        long v4 = measure(() -> commentService.getCommentsV4(1L, pageable));
        long v5 = measure(() -> commentService.getCommentsV5(1L, pageable));

        System.out.println("\n========== 성능 비교 ==========");
        System.out.println("V1: " + v1 + "ms");
        System.out.println("V2: " + v2 + "ms");
        System.out.println("V3: " + v3 + "ms");
        System.out.println("V4: " + v4 + "ms");
        System.out.println("V5: " + v5 + "ms");
        System.out.println("==============================\n");
    }

첫번째 테스트 결과

V1 → N+1만 해결한경우

V1 실행 시간: 36ms
V2 → DTO Projection

V2 실행 시간: 31ms
V3 → Interface Projection

V3 실행 시간: 29ms
V4 → Native Query

V4 실행시간: 32ms
V5 → N+1 해결 X

V5 실행시간: 38ms

생각보다 성능차이가 안나서 멤버 1000개 댓글 10000개로 각각 10개씩 댓글 작성해서 조회하는 싱황가정

두번째 테스트

V1 → N+1 Fetch Join 해결 - 37ms
V2 → Dto Projection - 35ms
V3 → Interface Projection - 29ms
V4 → 37 ms
V5 → 76ms

→ 여러번 실행해본 결과 N+1 해결 안했을 경우가 확실히 느리고 Interface Projection이 확실히 빠르고 나머지는 비슷비슷

DTO Projection은 객체 생성 비용 존재
1. 쿼리 실행
2. 각 Row 마다 CommentQueryDto 생성 → 생성자 호출
3. ResponseDto 로 변환
Native Query

Objectp[] -> DTO 변환 수동 , 타입캐스팅 과정
Interface
1. 쿼리 실행
2. 프록시 객체 생성(가벼움)
3. ResponseDto 변환 시에만 실제 접근

Test Code 실행시 Interface Projection 오류

1번째 오류

Null return value from advice does not match primitive return type for: public abstract boolean org.sopt.assignment.comment.repository.CommentSummary.isUpdate()
org.springframework.aop.AopInvocationException: Null return value from advice does not match primitive return type for: public abstract boolean org.sopt.assignment.comment.repository.CommentSummary.isUpdate()
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:237)
    at jdk.proxy3/jdk.proxy3.$Proxy213.isUpdate(Unknown Source)
    at org.sopt.assignment.comment.dto.response.GetCommentResponseDto.from(GetCommentResponseDto.java:47)
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
    at java.base/java.util.ArrayList$Itr.forEachRemaining(ArrayList.java:1085)
    at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
    at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
    at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
    at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
    at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
    at org.springframework.data.domain.Chunk.getConvertedContent(Chunk.java:131)
    at org.springframework.data.domain.PageImpl.map(PageImpl.java:86)
    at org.sopt.assignment.comment.service.CommentService.getCommentsV3(CommentService.java:65)
    at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:360)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:380)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:728)
    at org.sopt.assignment.comment.service.CommentService$$SpringCGLIB$$0.getCommentsV3(<generated>)
    at org.sopt.assignment.comment.CommentPerformanceTest.V3_성능_측정(CommentPerformanceTest.java:93)
    at java.base/java.lang.reflect.Method.invoke(Method.java:580)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

JPA Interface Projection은 쿼리 결과 그대로 매핑함
- 엔티티를 로딩하는 것이 아닌
- SELECT 절에 포함된 컬럼 값으로 프록시를 만들어서 getter에 매핑시켜줌
→ 근데 isUpdate 칼럼 값이 null로 넘어옴
엔티티에선 boolean값의 기본값을 false로 해줬음

→ 그렇다면 boolean 값에 실제 null이 들어가서 일어나는 문제가 아니라 매핑을 잘못 시키고 있다는 것
JavaBeans getter 규칙을 보게되면
isUpdate 에서 오류가 난이유?

필드명 = isUpdate

property name = isUpdate

getter = getIsUpdate

public interface CommentSummary {
    Long getId();
    String getContent();
    String getMemberName();
    LocalDateTime getCreatedAt();
    boolean getIsUpdate();
}

→ getIsUpdate 로 바꾸면 문제가 해결됨

Projection vs 엔티티/POJO
- boolean일 경우 getter는 isXXX는 엔티티/POJO에선 맞는 말
- 하지만 Interface Projection에선 메서드 이름 기반이기 때문에 getIsUpdate를 사용해야 함

#인덱스

기존

@Table(name = "articles", indexes = {
        @Index(name = "idx_member_id", columnList = "member_id"),
        @Index(name = "idx_title", columnList = "title"),
        @Index(name = "idx_created_at", columnList = "created_at")
})

idx_title

제목 완전 일치 검색에만 효과적
제목 부분검색 LIKE '%keyword%'에는 인덱스 안탐
title에 이미 UNIQUE제약조건이 있어서 자동으로 인덱스 생성

idx_created_at

단일 인덱스로는 비효율적임
실제 쿼리는 보통 WHERE member_id = ? ORDER BY created_at DESC
단일 칼럼 인덱스는 정렬에만 도와줌
WHERE + ORDER BY커버 실패

@Table(name = "articles", indexes = {
    // 1. 복합 인덱스: 회원별 최신 게시글 조회
    @Index(name = "idx_member_created", columnList = "member_id, created_at"),
    
    // 2. 태그별 최신 게시글 조회 (필요시)
    @Index(name = "idx_tag_created", columnList = "tag, created_at")
})

idx_member_created

WHERE 조건과 ORDER BY를 하나의 인덱스로 처리
페이징 쿼리에 최적

idx_tag_created

TAG가 있는 이유가 TAG 검색이 있을때라고 생각하기 때문에
그를 대비하여 created 와 TAG를 복합인덱스

-> 이렇게 인덱스를 바꾸면 검색 조건이나 정렬조건을 추가해야함

#인프라구조도

ECS를 사용했습니다
ECS의 특징으로는 자동 장애 복구, 무중단 배포, 모니터링 및 로깅 통합, 확장성에서 유리하고
운영 안정성과 개발 생산성, 확장성 준비에서 이점을 얻어 갈 수 있습니다
EC2 t3.small 기준 17달러만 내게 된다면 Task 정의만 잘한다면 그냥 EC2 t3.small을 쓰는 것보다 ECS 관리해주는 t3.small을 사용하는게 유리하다고 생각합니다

ECS는 운영타입이 Fargate와 EC2가 있는데, Fargate는 서버리스로 EC2를 직접 관리하지 않아도 되는 것이고 EC2는 ECS에서 자동 생성해주는 흔히 아는 EC2 타입으로 알고 있는데, 사용 경험이 EC2 밖에 없어서 구조도를 저렇게 그려봤습니다

ECS의 구성요소

1. 클러스터 Cluster

역할: 컨테이너들이 실행될 컴퓨팅 리소스의 논리적 그룹
예시: "웹서버 클러스터", "데이터베이스 클러스터"

구성 요소:
- EC2 인스턴스들의 그룹 (EC2 Launch Type)
- 또는 Fargate의 서버리스 컴퓨팅 (Fargate Launch Type)

2. Task Definition (작업 정의)

역할: 컨테이너 실행을 위한 청사진 (Blueprint)
Docker Compose의 yml 파일과 유사한 역할

포함 내용:
- 사용할 Docker 이미지
- CPU/메모리 할당량
- 네트워킹 설정
- 환경 변수
- 볼륨 마운트

3. 작업(Task)

역할: Task Definition에 기반해 실제 실행되고 있는 컨테이너 인스턴스
비유: 레시피(Task Definition)로 만든 실제 요리(Task)

특징:
- 하나의 Task = 하나 이상의 컨테이너
- 같은 Task 안의 컨테이너들은 같은 서버에서 실행
- localhost로 서로 통신 가능

4. Service(서비스)

역할: Task들을 지속적으로 관리하고 원하는 상태를 유지

주요 기능:
- 원하는 개수의 Task 유지 (예: 항상 3개 실행)
- Task가 죽으면 자동으로 새 Task 시작
- 로드밸런서와 연결
- Rolling 업데이트 수행
- Auto Scaling 지원

Public Subnet에 외부와의 통신을 위한 NAT Gateway를 배치합니다 (프라이빗 서브넷 -> NAT Gateway -> 인터넷)
인바운드 트래픽을 처리할 수 있는 ALB도 public subnet에 배치합니다(인터넷 -> ALB -> 프라이빗 서브넷의 ECS

Private Subnet안에는 ECS 클러스터를 두고 가용성 높게하기 위해 각각의 가용영역에 EC2를 1개씩 배치합니다 EC2안에는 스프링 부트 컨테이너, Redis 컨테이너, Nginx 컨테이너를 각각 태스크 정의를 통해 배치하고 프라이빗 서브넷 그룹에 RDS를 배치해줍니다. 그리고 CI/CD 및 이미지 저장소를 위한 ECR을 VPC 외부에 배치해줍니다

ECS는 특이하게 ENI와 PAUSE 컨테이너로 네트워크 및 통신을 관리하는데 이 내용은 너무 길어질것 같아서 생략하겠습니다!

🚨 참고 사항

웹소켓관련해서는 조금이따가 정리해서올리겠습니다... 아직 정리가 덜된부분이 있어가지구...

11 create comment

…ive Query vs N+1 API

oOccasio added 12 commits December 22, 2025 22:42

feat(temp): #

6dd66b2

11 create comment

feat: #11 Create Comment API

b40c707

feat: #11 Get Comments API

f32f065

feat: #11 Update Delete Comment API

a5bbfff

fix: Error Code 400 -> 401

292845a

test: #11 Fetch Join vs DTO Projection vs Interface Projection vs Nat…

5f2421d

…ive Query vs N+1 API

test: #11 CommentPerformance Test Code

299afef

feat: #11 Chat Basic Mechanism

a8ce840

feat: #11 Chat Response Style Refine

300d598

feat: #11 Chat Auth Link

d683fbd

feat: #11 Chat Get Current User And Chat Service

2dea912

feat: #11 Chat Typing Message Represent

1922681

oOccasio self-assigned this Dec 26, 2025

oOccasio added the ✨ assignment New Assignment label Dec 26, 2025

oOccasio linked an issue Dec 26, 2025 that may be closed by this pull request

[SEMINAR] 7주차 세미나 #11

Open

refactor: #11 Article Index Refactoring

a20198e

oOccasio requested review from byunhm02, hyodongg and sae2say December 26, 2025 03:27

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Seminar/#7 #12

Seminar/#7 #12

Uh oh!

oOccasio commented Dec 26, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Seminar/#7 #12

Are you sure you want to change the base?

Seminar/#7 #12

Uh oh!

Conversation

oOccasio commented Dec 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔥Pull requests

👷 과제 구현

필수과제

선택과제

구현한 내용에 대해서 설명해주세요과 고민한 점

Comment + Member - N+1 문제

최적화하기 - Projection과 쿼리

EntityGraph는 힌트이고 Fetch Join은 명령이다

Test Code 작성

테스트코드

첫번째 테스트 결과

두번째 테스트

Test Code 실행시 Interface Projection 오류

1. 클러스터 Cluster

2. Task Definition (작업 정의)

3. 작업(Task)

4. Service(서비스)

🚨 참고 사항

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

oOccasio commented Dec 26, 2025 •

edited

Loading