• 알림 정보(AlarmArgs)를 별도 클래스로 분리함.

• JPA에서 AlarmArgs를 매핑할 때 발생하던 오류(Basic attribute type should not be 'AlarmArgs') 해결

1. 알림 데이터를 JSON 형태로 DB에 저장할 수 있도록 @Convert + AlarmArgsConverter 적용함. (향후 구조 확장을 고려해 JSON 방식 채택 (확장성과 유연성 확보를 위함임.))
2. AlarmEntity에 @Column(columnDefinition = "json") 명시하여 DB에서 JSON 타입으로 인식되도록 설정)

📌 오늘 배운 주요 내용 정리

🔸 JPA에서 자바 객체를 DB에 저장하는 방법:

1. @Embeddable + @Embedded

   • 자바 객체를 컬럼 단위로 DB에 분해해서 저장함.
   • 검색이 쉽고 쿼리 성능이 좋다.
   • 구조가 고정적일 때 적합함.

2. @Convert + 커스텀 AttributeConverter

   • 객체를 JSON 문자열로 직렬화해 하나의 컬럼에 저장한다.
   • 구조가 유동적이고, 변경 가능성이 많을 때 적합하다.
   • JSON 필드 검색 시 일반 SQL이 아니라 JSON_EXTRACT 등의 함수를 사용하는게 필요하다.

→ 내 프로젝트에서는 알림 정보 구조가 알림 종류에 따라 계속 달라질 수 있어서 JSON 저장 방식이 더 적합하다고 판단했다.

@Convert 어노테이션

이 어노테이션은 단순히 @Column(columnDefinition = "json")만으로는 해결되지 않는 JPA 매핑 에러를 방지하는 필수 키워드 이다! → JSON 문자열로 직접 변환/역변환하는 로직을 명확히 지정해줘야 JPA가 오류 없이 작동하기 떄문.

코드를 작성할 때, 설계에서의 관점을 좀 더 비중있게 다뤄야 하는구나. JPA와 DB 구조 설계에 있어 "확장성과 유지보수"를 고려하는것에 대한 중요성을 잘 인식해야겠다.

1. 추가할 기능

• 좋아요 기능 사용자가 특정 게시물에 좋아요를 누름 사용자가 이미 좋아요를 눌렀다면 취소됨 (토글 방식) 좋아요 개수를 조회할 수 있음

• 댓글 기능 사용자가 특정 게시물에 댓글을 작성할 수 있음 댓글을 수정할 수 있음 댓글을 삭제할 수 있음 특정 게시물의 모든 댓글을 조회할 수 있음

2. 테스트 코드 추가 순서

• 좋아요 기능 테스트 코드 작성

  1. 좋아요 추가/취소 (likePost_Success)
  2. 로그인하지 않은 사용자가 좋아요 시도 (likePost_UnauthorizedError)
  3. 존재하지 않는 게시물에 좋아요 시도 (likePost_PostNotFoundError) 댓글 기능 테스트 코드 작성

• 댓글 작성 (createComment_Success)

  1. 로그인하지 않은 사용자가 댓글 작성 시도 (createComment_UnauthorizedError)
  2. 존재하지 않는 게시물에 댓글 작성 시도 (createComment_PostNotFoundError)
  3. 댓글 수정 (modifyComment_Success)
  4. 본인이 아닌 사용자가 댓글 수정 시도 (modifyComment_InvalidPermissionError)
  5. 댓글 삭제 (deleteComment_Success)
  6. 본인이 아닌 사용자가 댓글 삭제 시도 (deleteComment_InvalidPermissionError)
  7. 특정 게시물의 댓글 목록 조회 (getComments_Success)

테스트 코드에서는 MockBean을 사용해 PostService와 CommentService를 모킹(mocking)하여 실제 데이터베이스 연동 없이 서비스 레이어의 동작을 검증할 예정임.

먼저, 좋아요 기능을 추가하고, 댓글 기능을 추가하는 방식으로 진행함.

이름 수정의 원칙

1. 의도 명확히 표현: 예시)

   • shouldReturnFeedListWhenUserIsAuthenticated: 로그인된 사용자가 요청했을 때 피드 목록이 반환된다는 것을 명확히 표현함.
   • shouldReturnUnauthorizedWhenUserIsNotAuthenticated: 비로그인 상태에서 401 상태를 반환하는 경우를 명확히 표현함.

2. 테스트 조건과 기대 결과 포함:

   • 메서드 이름에서 테스트 조건(whenUserIsAuthenticated)과 기대 결과(shouldReturnFeedList)를 함께 명시함.

3. 일관된 네이밍 패턴 사용:

   • should + 동작 + 조건 형태로 작성하여 가독성을 높임.

이름 변경 후 기대 효과

• 메서드 이름만으로 테스트의 목적을 쉽게 이해할 수 있어 유지보수가 용이해짐.
• 협업 시 다른 개발자들과의 의사소통이 원활해짐.

1. 비즈니스 요구사항을 상위 레벨에서 검증하기 위함. 컨트롤러 테스트는 애플리케이션의 외부 레이어(HTTP 요청/응답 처리)를 검증하는 역할을 하며, 사용자 요청(HTTP API 호출)이 어떻게 처리되고 어떤 결과를 반환해야 하는지를 상위 레벨에서 설계하고 확인할 수 있음.

   -> 이를 통해 비즈니스 요구사항을 상위 레벨에서 정의한 후, 하위 레이어(서비스, 리포지토리)를 구현하는 방식으로 개발할 수 있음.

2. HTTP 인터페이스 설계를 명확히 하기 위함. 컨트롤러 테스트를 먼저 작성하면 HTTP 인터페이스(API 설계)가 명확해짐.

   -> 어떤 URL로 어떤 HTTP 메서드(POST, GET, PUT, DELETE)를 사용하며, 요청 및 응답 데이터 형식이 어떻게 생겼는지를 컨트롤러 테스트 작성 단계에서 자연스럽게 정의할 수 있음. (외부와의 상호작용 방식을 먼저 확정)

3. 현재 프로젝트에서 상위 레벨부터 하위 레벨로 내려가는 설계 방식을 따르고 있으므로 컨트롤러 테스트를 먼저 작성하고, 이에 맞는 서비스 테스트 및 로직을 구현하는 방식은 상위 레벨부터 하위 레벨로 내려가는 설계 방식(Top-Down Approach)임. -> 이 방식은 요구사항 흐름을 따라가기 쉽고, 로직 누락이나 중복을 방지할 수 있다.

4. 초기 단계에서 서비스 레이어가 복잡하지 않을 가능성이 있기 때문. 초기에 서비스 레이어가 단순하거나 특정 규칙만 처리해야 한다면, 컨트롤러 테스트를 작성하면서 자연스럽게 서비스 레이어를 구현할 수 있다. -> 빠른 개발을 진행할 수 있게 됨.

(결론: 나는 TDD의 초보자이므로 사용자 요청/응답 관점에서 시작하는 것이 더 직관적임.)

최근 관점에서의 권장 방식 ~ 서비스 테스트를 먼저 작성하는 이유:

1. 비즈니스 로직 중심 테스트

• 서비스 계층은 핵심 비즈니스 로직을 포함하고 있어 가장 중요한 테스트 대상이먀, 컨트롤러는 단순히 요청을 받아 서비스로 전달하는 간단한 역할이 대부분이므로.

2. 테스트 안정성

• 컨트롤러 테스트는 HTTP 요청/응답, 시큐리티 설정 등 외부 요인에 영향을 받기 쉽다! 서비스 테스트는 이러한 외부 의존성이 적어 더 안정적이다.

3. 개발 효율성

• 서비스 테스트를 먼저 작성하면 비즈니스 요구사항에 집중할 수 있다. (핵심 로직이 검증된 후 컨트롤러 구현이 더 수월해짐)

즉, 서비스 테스트를 먼저 작성하면:

1. 진짜 중요한 규칙을 먼저 만들고
2. 나중에 API가 바뀌어도 핵심 기능은 안전하며
3. 사용자 입장에서 중요한 기능을 먼저 검증할 수 있다는 장점이 있다.

(이러한 접근 방식은 Martin Fowler의 글이나 Clean Architecture(Robert C. Martin)와 같은 현대적인 아키텍처 패턴에서도 강조되고 있음)

현재 진행중인 커넥티 SNS 어플리케이션에서 게시물 작성 기능을 예시로 들어 TDD 접근 방식의 차이를 알아본다.

1. 컨트롤러 테스트 먼저 작성하는 경우

@Test
void 게시물_작성_성공() {
    // given
    PostCreateRequest request = new PostCreateRequest("제목입니다", "내용입니다", List.of("image1.jpg"));

    // when
    ResponseEntity<PostResponse> response = postController.createPost(request);

    // then
    assertThat(response.getStatusCode()).isEqualTo(HttpStatus.CREATED);
    assertThat(response.getBody().getId()).isNotNull();
}

이 방식은 HTTP 응답이나 요청 형식에 먼저 집중하게 된다. 실제 중요한 비즈니스 로직은 아직 테스트되지 않은 상태다.

2. 서비스 테스트 먼저 작성하는 경우

@Test
void 게시물_작성시_이미지는_최대_5장까지_가능하다() {
    // given
    List<String> tooManyImages = List.of("1.jpg", "2.jpg", "3.jpg", "4.jpg", "5.jpg", "6.jpg");

    // when & then
    assertThatThrownBy(() -> 
        postService.createPost("제목", "내용", tooManyImages))
        .isInstanceOf(TooManyImagesException.class);
}

@Test
void 게시물_내용은_최대_500자까지_가능하다() {
    // given
    String tooLongContent = "A".repeat(501);

    // when & then
    assertThatThrownBy(() -> 
        postService.createPost("제목", tooLongContent, List.of()))
        .isInstanceOf(ContentTooLongException.class);
}

@Test
void 게시물_작성_성공시_팔로워에게_알림이_발송된다() {
    // given
    String title = "제목";
    String content = "내용";
    List<String> images = List.of("image1.jpg");

    // when
    Post savedPost = postService.createPost(title, content, images);

    // then
    verify(notificationService).notifyFollowers(savedPost);
    assertThat(savedPost.getTitle()).isEqualTo(title);
    assertThat(savedPost.getContent()).isEqualTo(content);
}

서비스 테스트를 먼저 작성하면 다음과 같은 비즈니스 규칙들을 먼저 검증할 수 있다:

1. 이미지는 최대 5장까지만 첨부 가능하다
2. 게시물 내용은 500자를 넘을 수 없다
3. 게시물 작성 시 팔로워들에게 알림이 발송되어야 한다

이렇게 접근하면 경우의 장점:

1. SNS 서비스에서 정말 중요한 도메인 규칙들을 먼저 검증할 수 있다
2. 나중에 API 스펙이 바뀌더라도 (예: REST → GraphQL) 핵심 비즈니스 로직은 그대로 유지된다
3. 실제 사용자 시나리오에 더 집중할 수 있다

(상위 항목 관련 예시 설명 추가)

1. 도메인 규칙 먼저 검증하기

• 인스타그램에서 사진을 10장 올리려고 하면 "최대 5장까지만 가능합니다"라고 뜬다. -> 이것이 도메인 규칙임.
• 컨트롤러 테스트만 작성하면 "응답 코드가 400이 와야 한다"는 것만 테스트하게 된다.
• 서비스 테스트를 먼저 작성하면 "왜 5장이어야 하는지", "6장이 들어오면 어떻게 처리해야 하는지" 등 진짜 중요한 규칙을 먼저 테스트할 수 있다.

2. API 스펙이 바뀌어도 비즈니스 로직 유지

• 음식점으로 비유하면:
  • 컨트롤러는 "주문을 받는 직원"이다 (배달앱으로 주문받을지, 전화로 받을지, 매장에서 받을지)
  • 서비스는 "요리사"다 (실제로 음식을 만드는 비즈니스 로직)
• 주문 방식(API)이 바뀌어도 요리(비즈니스 로직)는 그대로다
• 서비스 테스트를 먼저 하면 "음식이 제대로 만들어지는지"를 먼저 검증할 수 있다

3. 실제 사용자 시나리오에 집중

• 컨트롤러 테스트만 하면: "API 호출했을 때 응답이 잘 오는가?"만 확인
• 서비스 테스트를 먼저 하면:
  • "사용자가 게시물을 작성하면 팔로워에게 알림이 가야 한다"
  • "게시물에 욕설이 있으면 작성이 안 된다"
  • "해시태그는 최대 10개까지만 가능하다" 등 실제 사용자가 경험하는 기능들을 먼저 테스트할 수 있다

->그렇지만 "반드시" 따라야 하는 규칙은 아님. 프로젝트의 특성이나 팀의 상황에 따라 컨트롤러 테스트를 먼저 작성하는 것이 더 효율적일 수도 있으며, 특히 API 스펙이 먼저 확정되어야 하는 경우라면 컨트롤러 테스트를 먼저 작성하는 것이 유리할 수 있음.

Claude의 주요 장점을 활용하여 보고서, 기획서, 기술 문서를 효과적으로 작성하기 위함

1. Claude의 특장점 이해

• 긴 컨텍스트 이해: 대규모 데이터와 긴 문맥을 빠르게 이해하고 처리 가능
• 전문적 문서 작성: 체계적이고 명확한 문서 작성 지원
• 상세한 분석 능력: 데이터 기반의 논리적 분석 및 결과 도출
• 구조화된 결과물 제공: 요구에 맞는 포맷과 형식으로 결과 제공

2. 보고서 작성 예시

(1) 비즈니스 보고서 작성

• 요청 예시:

    AI 도구 도입에 따른 업무 효율성 분석 보고서를 작성해주세요.
  
    구성:
    1. 현황 분석
    2. 도입 효과
    3. 비용 분석
    4. 향후 계획
  
    각 섹션은 구체적 데이터와 사례를 포함해주세요.

• 현황 분석은 최신 데이터가 활용됨
• 도입 효과를 정량적/정성적으로 구분하여 설명함
• 비용 분석은 명확한 근거 자료와 함께 제시됨

(2) 기술 문서 작성

• 요청 예시:

    신규 AI 서비스 기술 명세서를 작성해주세요.
  
    포함 내용:
    - 시스템 아키텍처
    - 주요 기능 명세
    - API 문서
    - 보안 고려사항
  
    전문적인 용어와 표준 형식을 사용해주세요.

• 기술 용어를 정확하게 사용하며, 필요 시 정의를 제공

• 도식화된 아키텍처와 간결한 설명을 함

• 사용자의 요청에 따라 보안 고려사항을 자동으로 포함한 문서를 작성하거나, 이미 작성된 문서에서 보안 관련 항목을 추가하거나 개선하도록 요청할 수 있음.

  (웹 애플리케이션 인증 시스템 기술 문서에 대한 도식화된 답변 예시, Mermaid 마크다운으로 지원함.)

(3) 기획서 작성 : 프로젝트 기획서 작성

• 요청 예시:

    AI 교육 프로그램 기획서를 작성해주세요.
  
    필수 항목:
    - 프로그램 개요
    - 목표 및 KPI
    - 세부 커리큘럼
    - 소요 예산
    - 기대 효과
  
    교육 대상은 일반 직장인이며, 8주 과정으로 구성해주세요.

  • 예) KPI,예산: 측정 가능한 구체적 목표 제시해주며, 항목별 세부 내역과 근거를 제공해준다.

(4) 문서 분석 및 개선 필요 시

문서 리뷰 요청

• 요청 예시:

    첨부한 마케팅 기획서를 검토하고 다음 관점에서 개선점을 제시해주세요:
  
    1. 구성의 논리성
    2. 데이터 활용도
    3. 실행 가능성
    4. 예산 적절성
  
    각 부분별 구체적인 개선 방안도 함께 제시해주세요.

  • 데이터의 시각화가 필요한 경우 해당 내용을 명시해줌.
  • 실행 가능성과 현실성을 고려한 피드백 제공해준다고 함.

** (5) 구조화된 결과물 얻기**

• 요청 형식 예시:

    다음 형식으로 작성해주세요:
  
    1. 개요
       - 배경
       - 목적
    2. 본문
       - 주요 내용
       - 세부 설명
    3. 결론
       - 요약
       - 제언

효과적인 요청 방법

1. 문서 목적 명확히 제시: 예) 보고서, 기획서, 기술 문서
2. 대상 독자층 지정: 예) 경영진, 개발자, 일반 사용자
3. 형식 및 스타일 명시: 예) 표준화된 템플릿 제공
4. 강조점 설정: 주요 섹션 및 핵심 내용을 중심으로 요청

주의해야 할 사항

• 명확한 요구사항을 전달.
• 단계별로 수정/보완을 요청하기.
• 형식의 일관성을 유지하기.
• 핵심 내용 강조해서 전달.

1. Python 웹 스크래핑 코드 작성

프롬프트

Python으로 웹 스크래핑 코드를 작성해주세요. 조건:

• requests, beautifulsoup4 사용
• 에러 처리 포함
• 결과를 CSV로 저장
• 주석 상세히 포함

2. 코드 디버깅 및 개선

프롬프트

이 코드에서 발생할 수 있는 잠재적 문제점을 분석하고, 개선된 버전을 작성해주세요.

응답(Response)

위의 프롬프트를 입력하니 이미지처럼 응답을 작성하며 디버깅을 진행하는 코드 줄을 보여준다. 코드를 다른 창에서 보여줄 수 있도록 업데이트 되었나 보다. 해당 창에서는 파이썬 코드를 바로 실행할 수도 있게 만들어두었다.

본 예시에 적용된 구체적인 프롬프트 기법

1. 명확하고 구체적인 프롬프트 작성

• 조건을 필수적으로 명시:
  프롬프트에서 requests, beautifulsoup4 사용, 에러 처리, CSV 저장 등 구체적인 요구사항을 명시해야함. (조건이 구체적일수록 AI는 더 적절한 코드를 생성함)

  → 프롬프트 예시:
  "Python으로 웹 스크래핑 코드를 작성해주세요. requests와 beautifulsoup4를 사용하고, 에러 처리를 포함해 결과를 CSV로 저장해주세요."

2. 체계적인 문제 해결 방식을 유도

• 프롬프트의 단계적 요구: 세부 기능을 단계적으로 요구한다. (AI가 코드를 논리적으로 분리하고, 단계별 접근 방식을 사용하도록 유도한다.)

  → 프롬프트 예시:
  "Python으로 웹 스크래핑 코드를 작성하고, 네트워크 오류 및 HTTP 오류를 처리해주세요. 결과는 CSV 파일로 저장하고, 각 함수에 주석을 자세히 달아주세요."

3. 컨텍스트를 유지하고 세부적인 요구를 반복

• 이미 작성된 코드를 기반으로 문제점을 분석하고 개선하는 방식을 사용한다. (AI가 기존 코드를 참조하고 연속적으로 수정 및 개선 작업을 수행하도록 한다.)

  → 프롬프트 예시:
  "위 코드를 기반으로, 발생할 수 있는 문제점을 분석하고 코드 품질을 향상시켜 주세요."

4. AI에게 역할을 부여함 (Persona 기법)

• AI에게 역할을 명시적으로 부여하면, 전문적이고 신뢰할 수 있는 답변을 얻을 수 있음. → 프롬프트 예시:
  • "당신은 Python 전문가입니다. Python으로 웹 스크래핑 코드를 작성하고, 발생할 수 있는 에러와 보완책을 설명해주세요."
  • "프로그래밍 강사처럼 코드를 설명하고, 각 단계별로 상세한 주석을 추가해주세요."

5. 에러 처리 및 예외 상황 대응 요구

• 프롬프트에 에러 처리와 예외 상황을 포함하면, AI가 더 견고한 코드를 생성하도록 유도됨. (에러 핸들링 없이 단순한 스크래핑 코드를 요구하는 경우와 비교해 코드 안정성이 크게 향상된다. )

  → 프롬프트 예시:
  "HTTPError, ConnectionError, Timeout 등 주요 예외를 처리하는 코드를 작성해주세요."

6. 결과물 평가 및 검증 요청

• AI에게 코드를 검증하고 예상되는 오류나 문제를 분석하도록 요청

  → 프롬프트 예시:

  • "코드 실행 후 데이터가 없는 경우, 경고 메시지를 출력하고 종료하도록 작성해주세요."
  • "추출된 데이터가 없는 경우, 사용자에게 경고 메시지를 출력하는 기능을 추가해주세요."

7. 프롬프트 반복 및 리팩토링 요청

• 첫 번째 코드 생성 이후 응답을 개션하는 방법

  → 프롬프트 예시:

  • "코드의 효율성을 높이고 중복 코드를 제거하는 방식으로 리팩토링해주세요."
  • "추출된 데이터가 많아질 경우를 대비해 CSV 저장 방식을 개선하고, 파일이 존재하면 덮어쓰지 않고 추가 저장하도록 수정해주세요."

주의할 사항!

• 데이터 정확성 확인
• 응답 코드에 대한 테스트가 필요함 (결과 검증 필수)

AI와의 상호작용에서 중요한 요소 중 하나는 컨텍스트(context)를 효과적으로 활용하는 것이다. 컨텍스트(~맥락)를 잘 사용하면 AI가 사용자의 의도를 더 정확하게 파악하고, 더욱 자연스럽고 일관된 답변을 제공할 수 있다.

1. 이전 대화 참조하기

AI는 독립적인 질문에 답변하는 것뿐만 아니라, 이전 대화의 내용을 기억하고 참조할 수 있다. 이를 통해 AI는 대화의 흐름을 이어가며, 연관된 질문에도 일관된 답변을 제공한다.

예시:
사용자: for 문으로 리스트 순회하는 법 알려줘.
AI: Python에서 for 문을 사용해 리스트를 순회하려면 다음과 같이 작성합니다.

fruits = ['apple', 'banana', 'cherry']
for fruit in fruits:
    print(fruit)

사용자: 다른 예제도 보여줘.
AI: 다음은 리스트에서 짝수만 출력하는 예제입니다.

numbers = [1, 2, 3, 4, 5, 6]
for number in numbers:
    if number % 2 == 0:
        print(number)

위 예시에서 AI는 '다른 예제도 보여줘'라는 요청을 받았을 때, 이전 대화에서 'for 문'과 '리스트 순회'를 주제로 다룬 것을 기억하고 관련된 추가 예제를 제공한다.

2. 연속된 질문하기

연속된 질문을 통해 AI는 사용자의 깊이 있는 궁금증을 해결할 수 있다. 초기 질문에서 파생된 후속 질문을 하더라도 AI는 맥락을 유지하며 흐름을 이어간다.

예시:
사용자: 인공지능의 종류에는 무엇이 있어?
AI: 인공지능에는 좁은 인공지능(Narrow AI), 범용 인공지능(General AI), 초지능(Super AI)이 있습니다.
사용자: Narrow AI에 대해 자세히 알려줘.
AI: Narrow AI는 특정 작업에 특화된 인공지능으로, 예를 들어 음성 비서나 이미지 인식 프로그램이 이에 해당합니다.

AI는 '인공지능의 종류'라는 초기 질문에서 'Narrow AI'라는 개념을 인식하고, 추가 질문에 대해 구체적으로 설명한다.

3. 대화 맥락 유지하기

대화가 길어질수록 AI가 대화의 흐름을 기억하고 일관된 정보를 제공하는 것은 매우 중요하다. 이를 통해 대화가 부자연스럽게 끊기지 않고, 사용자는 AI와의 상호작용에서 더 유용한 경험을 얻을 수 있다.

예시:
사용자: 내일 비가 올까?
AI: 내일은 비 소식이 없습니다.
사용자: 그럼 주말에는 어떨까?
AI: 주말에는 비가 올 가능성이 있습니다. 토요일 오후에 비 예보가 있습니다.

'주말에는 어떨까?'라는 질문은 명확하게 날씨를 지칭하지 않는다. 하지만 AI는 이전 질문에서 '날씨'를 주제로 다뤘음을 인식하고 자연스럽게 답변을 이어간다.

주의할 점

효과적인 사용을 위한 방법

• 구체적인 지시어 사용하기
• 단계별로 질문하기
• 필요시 부가 설명 추가하기

한계점을 이해한다

• 최신 정보가 제한됨
• 사실 정보의 재확인이 필요함
• 윤리적 가이드라인을 준수하는지

프롬프트 엔지니어링은 대규모 언어 모델 LLM의 성능을 극대화하는 데 핵심적인 역할을 하며, 명확하고 구조화된 요청을 통해 모델이 원하는 답변을 정확하게 도출할 수 있도록 유도해야 한다.

이 글에서는 대규모 언어 모델(LLM)을 다루는 기술인 프롬프트 엔지니어링의 최적화 기법을 확인하기 위해, 논문 "Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4"에서 제시된 주요 기법과, LLM의 성능을 극대화하는 방법을 정리했다.

(논문에서는 LLaMA-1/2 및 GPT-3.5, GPT-4와 같은 최신 언어 모델을 대상으로 26가지의 원칙을 적용해 프롬프트를 최적화하는 방법을 제시했다. 이러한 원칙은 정확성 및 응답 품질을 평균 57.7%, 36.4% 향상시켰다.)

주요 프롬프트 엔지니어링 전략

1. 프롬프트 구조 및 명확성

• 대상 독자 명시: "해당 독자는 이 분야의 전문가입니다"와 같이 명확한 대상 설정
• 명령형 문구 사용: "이 작업을 수행하세요"와 같은 명확한 지시어 사용

2. 구체성 및 정보

• 예시 포함: "아래 예시와 같은 방식으로 답변하세요"
• 편향 제거: "편향되지 않은 답변을 작성하세요"

3. 사용자 상호작용 및 참여 유도

• 추가 정보 요청: "필요한 경우 질문을 통해 정보를 요청하세요"
• 점진적 피드백: "각 단계마다 피드백을 제공하고 개선하세요"

4. 콘텐츠 및 언어 스타일

• 불필요한 공손함 제거: "감사합니다", "부탁드립니다" 등의 표현 생략
• 모델 역할 부여: "당신은 수학 교사입니다"와 같이 모델에 명확한 역할을 부여

5. 복잡한 작업 및 코딩 프롬프트

• 복합 작업 분해: 복잡한 문제를 여러 단계로 나누어 프롬프트 작성
• 코드 예제 제공: "아래의 예제 코드를 참조하여 문제를 해결하세요"

출처 및 참조

Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4, Sondos Mahmoud Bsharat, Aidar Myrzakhan, Zhiqiang Shen, 2023. https://arxiv.org/pdf/2312.16171

• AI에게 전달하는 명령/질문/지시문
• AI의 출력을 결정하는 핵심 요소
• 의도 전달을 위한 소통 도구

프롬프트 엔지니어링이란?

프롬프트 엔지니어링은 AI 언어 모델(예: GPT-4o)의 성능을 극대화하기 위해 프롬프트(질문이나 명령어)를 설계하고 개선하는 전략과 기법을 의미함.

참고) 오픈AI 에서 제공하는 효과적인 프롬프트 작성 방법

역할/ 작업/ 형식/ 제약 의 단계가 필요함. (OpenAI는 명확하고 구체적인 작업 지시, 콘텍스트 제공, 그리고 원하는 출력 형식의 명시를 통해 AI 모델의 성능을 극대화할 수 있다고 강조함.)

https://platform.openai.com/docs/guides/prompt-engineering

문서 주요 내용

1. 프롬프트 엔지니어링의 목적

   • AI가 더 나은 결과를 생성하도록 돕는 것
   • 프롬프트를 어떻게 작성하느냐에 따라 AI의 답변 품질이 달라지기 때문에 효율적인 프롬프트 작성법을 익히는 것이 중요하다는 점을 강조한다.

2. 해당 문서에서 제시하는 6가지 주요 전략

   • 명확한 지시 작성 (Write clear instructions)

     • 원하는 답변의 형식, 길이와 난이도를 명확히 요구해야함.
     • 예: "200자 이내로 요약해줘"

   • 참고 자료를 제공 (Provide reference text)

     • AI가 허위 정보를 생성하지 않도록 신뢰할 수 있는 자료를 입력으로 제공함.

   • 복잡한 작업을 단순하게 나누기 (Split complex tasks into subtasks)

     • 복잡한 요청은 단계별로 나눠서 지시함.

   • Give the model time to think

     • 논리적으로 단계별 사고를 하도록 유도한다.

   • 외부 도구를 사용 (Use external tools)

     • 검색 엔진이나 코드 실행기 등 외부 도구와 AI를 결합해 더 나은 결과를 생성하도록 한다.

   • 변경 사항을 체계적으로 테스트한다. (Test changes systematically)

     • 프롬프트를 개선하면서 결과를 비교하고 최적의 방식을 찾아가는 과정을 진행한다.

적절한 AI 도구를 선택하기 위해서 고려해야 할 것

• 목적 적합성: 수행하고자 하는 작업에 최적화된 도구인지 검토해야 한다. 도구가 해결하고자 하는 문제와 일치하는지)
• 비용 효율성: 사용 비용 대비 얻을 수 있는 가치를 평가해야 함.(예산에 맞는 툴 선택)
• 출력물 품질: 결과물의 정확성과 완성도를 확인해야 한다.

• 도구의 설정을 최적화하거나, 후처리 작업을 추가하는 방법 고려

• 사용 편의성: 학습 곡선과 인터페이스의 직관성을 고려해야 함. (효율성에 영향을 미치기 때문)

활용 전략

1️⃣ 명확한 목적 설정

• 해결하고자 하는 문제를 명확하게 정의
• 기대하는 결과물을 구체화해야함.

2️⃣ 도구 조합 활용

• 각 도구의 장점을 조합하여 워크플로우를 구성
• 상호 보완적으로 도구를 활용

3️⃣ 품질 관리

• 결과물의 정확성을 검증해야 한다. -> 직접 서치하고 검증하는 과정이 필요하다.
• 데이터의 품질을 관리하는 것이 중요하다. 자문을 구하거나, 신뢰할 수 있는 데이터 소스를 사용해야 한다.
• 지속적인 피드백을 통해 결과물을 개선해야 한다.

4️⃣ 역량 개발

• AI 도구를 효과적으로 활용하기 위해 지속적인 학습이 필요함.
• 다양한 도구를 사용해보고 경험을 늘려야 한다.
• 최신 트렌드와 기술 동향을 파악하는 것이 중요하다.

1. 함수는 작게, 더 작게

• 함수는 작아야 한다.
  • 한 눈에 들어올 정도로 짧아야 함.
  • 5~20줄 정도가 이상적임.
• 함수는 한 가지 일을 해야 한다.
  • 한 가지 작업만 수행하고, 그것을 잘 해야 함.
  • 여러 작업이 섞이면 읽기 어렵고 유지보수가 힘들어짐.

2. 함수는 한 단계의 추상화만 수행

• 함수 내부의 모든 문장은 동일한 추상화 수준을 가져야 함.
  • 상위 수준의 추상화와 하위 수준의 구현이 섞이면 읽기 어렵고 수정이 어려워짐.
• 추상화가 섞이면 새로운 함수로 추출해야 함.

3. 함수의 이름은 명확하고 직관적으로

• 함수 이름은 동사나 동사구로 작성해야 함.
  • 예: getUser(), calculateTax(), validatePassword()
• 이름만으로 함수가 어떤 일을 하는지 알 수 있도록 작성해야 함.
  • 나쁜 예: process(), doTask()
  • 좋은 예: sendEmailToUser()

4. 함수는 적은 수의 인수를 가져야 함

• 최대 3개 이하의 인자가 이상적임.
  • 0~2개가 가장 좋음.
  • 3개 이상이면 파라미터 객체로 묶어서 전달.
  • 예: createOrder(String userId, String itemId, int quantity) 대신
    createOrder(OrderRequest request) 형태로 단순화 가능.

5. 부수 효과(side effect)를 피하라

• 함수는 입력값을 받아서 출력값을 반환하는 순수 함수 형태가 이상적임.
• 전역 변수 수정, 객체 상태 변경 등 숨겨진 부수 효과가 있으면 함수의 동작을 예측하기 어려워짐.

6. 명령-질의 분리(Command-Query Separation)

• 질의 함수: 값을 반환하지만 상태를 변경하지 않음.
  • 예: isUserActive(), getBalance()
• 명령 함수: 상태를 변경하지만 값을 반환하지 않음.
  • 예: disableUser(), updateProfile()
• 명령과 질의를 섞지 말라.
  • 예: checkAndDeleteUser() → 삭제는 명령이고, 확인은 질의이므로 분리해야 함.

7. 오류 처리도 한 가지 일처럼 보이게 하라

• try-catch 문은 함수에서 분리해야 함.
• 오류 처리 자체를 별도 함수로 작성해 가독성을 높임.

  try {
      deleteFile(filename);
  } catch (Exception e) {
      logError(e);
  }

  ➡️ deleteFileSafely(filename) 형태로 추출 가능.

8. 함수는 읽기 쉽고 이해하기 쉬워야 한다

• 코드의 흐름이 위에서 아래로 자연스럽게 읽히도록 작성해야 함.
• 함수 호출 순서가 논리적인 흐름을 따르도록 작성하는 것이 중요함.

정리

• 작은 함수, 명확한 이름, 부수 효과 없는 순수 함수가 좋은 코드의 핵심이다.
• 함수를 작게 쪼개고, 명확한 책임을 가지도록 설계하는 것이 클린 코드의 핵심 철학이다.

1장: 깨끗한 코드

• 코드 : 기계가 이해하고 실행할 수 있도록 작성된 요구사항의 명세이자 언어이다.
  -> 엄밀하고 정확하며 상세해야 함 (단순화만이 답이 아님.) -> 기능의 의도*를 분명히 드러내야 하며, *중복을 피하고 검색하기 쉬워야 함.

• 깨끗한 코드의 특징

  1. 검색이 쉽다: 변수, 메서드, 클래스의 이름이 직관적.
  2. 중복이 없다: 같은 코드나 기능이 여러 곳에 반복되지 않음.
  3. 명확하다: 코드를 읽는 것만으로도 의도가 파악되어야 함.
  4. 발음하기 쉬운 이름: 소통이 쉬워야 함.

2장: 의미 있는 이름

• 클래스 이름은 명사가 적절 ( User, Order처럼 역할을 표현 )

• 메서드 이름은 동사나 동사구로 표현하는게 적절함 (get으로 시작하는 메서드, calculateTotal, send~ 등, 이들 처럼 동작을 표현한다.)

• *일관성을 유지해야함 -> * 같은 의미의 개념에는 일관성있게 같은 단어를 사용해야 함. ( 예를들어, fetch, get, retrieve 중 하나만 사용하는것이 좋다. 마찬가지로, 같은 동작을 하는 개념에는 같은 단어를 일관성있게 사용해야한다. (동일 코드 기반에 controller, manager, driver 를 혼재해서 쓴다면 안되겠지?)

• 인코딩을 피하라 ( 변수나 클래스 이름에 불필요한 정보를 붙이는 것을 의미.)

  1. 헝가리식 표기법
     변수 이름에 데이터 타입을 붙이는 방식임.
     예: strName, iCount
     ➡️ IDE가 타입을 알려주니 더는 필요하지 않음.

  2. 멤버 변수 접두어
     변수 이름 앞에 _나 m_을 붙이는 방식임.
     예: _userName, m_password
     ➡️ 읽기 어렵고 비일관적임.

  3. 인터페이스와 구현 클래스 구분
     인터페이스 이름에 I를 붙이거나, 구현 클래스에 Impl을 붙이는 방식. 좋은 예: UserService, UserServiceDefault

     -> 불필요한 정보는 빼고, 이름만으로 의도를 명확히 드러내야 한다.

인터페이스와 구현 클래스 구분 에 관한 의문점: 현재 진행하고 있는 커넥티 개인 프로젝트에서는 하위 구현 클래스 이름으로 UserServiceImpl을 사용하고 있다.

이 부분이 걸리는데, 클린코드의 관점에서는 Impl 같은 이름이 클래스의 역할이나 의도를 명확히 드러내지 못한다고 보는 것으로 보인다.

이것을 클린코드의 관점에서 개선하려면, 역할을 명확히 표현 해야하고, 클래스 이름만 보고도 어떤 구현인지 알 수 있도록 이름을 지어야 하는 것일까? 스프링에서는 Impl을 관용적으로 사용하는 경우가 많은 것으로 알고있다.

의미를 더 드러낼 수 있는 이름으로 리팩토링하면 가독성이 좋아지려나? -> 지금 사용하는 UserServiceImpl가 스프링 환경에서는 흔히 쓰이는 방식이 아닌가? 개선이 필요한 것인가?

기타 : 이름 짓기에서 고려할 추가 사항

1. 문제 영역/ 해법 영역의 구분

   • 문제 영역: 현실 세계의 개념에 집중.
     • 예: User, Address, Order
   • 해법 영역: 기술적 구조에 맞는 이름 사용.
     • 예: UserController, OrderRepository, AddressValidator 1. 해법 영역과 문제 영역의 개념 구분
   • 문제 영역: 실제로 해결하려는 문제나 도메인과 관련된 개념임.
     예: User, Order, Product (현실 세계에서 사용하는 용어)
   • 해법 영역: 프로그래머들이 익숙한 기술적 용어를 의미함.
     예: Controller, Service, Repository (애플리케이션 구조나 구현을 위한 용어)
     ➡️ 구분해서 사용해야 함:
     • 도메인 관련 코드는 문제 영역의 용어를 사용해야 직관적임.
       예: User, Address
     • 구현 관련 코드는 해법 영역 용어를 사용해 역할을 명확히 해야 함.
       예: UserRepository, AddressValidator

2. 맥락을 명확하게 개선하기

   • 이름만으로도 역할과 의도가 명확해야 함.
   • 접두어를 적합하게 사용해야함 접두어를 사용할 때는 맥락을 명확히 하기 위해 의미 있는 용어를 선택해야 함.
   • 나쁜 예: FirstName (어떤 맥락의 이름인지 불분명)
   • 좋은 예: addrFirstName (주소와 관련된 이름임을 명확히 표현)
     ➡️ 하지만 접두어 사용은 너무 길거나 중복되지 않도록 간결하게 유지하는
     • 좋은 예: addrFirstName (주소와 관련된 이름임을 명시)
     • 나쁜 예: FirstName (맥락이 불분명)

3. 불필요한 맥락을 추가하지 않도록 주의하기

   • 나쁜 예: AccountAddressStreet
   • 좋은 예: Street (이미 Address 객체 안에 포함된 변수라면 충분함)

테스트코드를 만들기에 장벽이 있던 리팩토링 필요한 코드 예시

리팩토링 후, 테스트코드를 만들기 쉬워짐

1. 코드 분석: Interface와 DI의 역할

• 코드 스크린샷 설명:

  • GitHubService는 Interface로 정의되어 있고, 이를 구현한 DefaultGitHubService는 실제 GitHub API와 통신하는 역할을 한다.
  • RepositoryRank는 GitHubService를 생성하지 않고, DI(Dependency Injection)를 통해 외부에서 주입받아 사용한다.
  • getPoint 메서드는 주입받은 GitHubService를 이용해 GitHub 저장소의 정보를 조회하고, 특정 점수를 계산한다.

• 이 설계의 핵심:

  1. RepositoryRank는 구체적인 구현체(DefaultGitHubService)가 아닌 역할(Interface)만 알기 때문에 강한 결합을 피하고 유연성을 높임.
  2. 테스트 시에는 실제 GitHubService 대신 Mock 객체를 주입하여 외부 종속성을 제거하고 로직 테스트를 가능하게 함.

2. Interface와 DI의 필요성

• Interface 사용 이유:

  1. 구현체 교체 용이성:
     • GitHubService 인터페이스를 사용하면, BitBucket이나 GitLab 등 다른 API로 확장할 때 RepositoryRank를 수정할 필요 없이 새로운 구현체만 추가하면 됨.
  2. 테스트 용이성:
     • Mock 객체를 사용해 GitHubService의 동작을 시뮬레이션할 수 있음.

• DI(Dependency Injection)의 역할:

  1. 코드의 책임 분리:
     • RepositoryRank는 GitHubService를 직접 생성하지 않고 외부에서 주입받기 때문에 자신의 역할(점수 계산 로직)에만 집중할 수 있음.
  2. 테스트 유연성:
     • DI를 통해 Mock 객체를 주입받아 실제 GitHub API를 호출하지 않고도 테스트 가능.

3. 구체적인 예시: Interface와 DI가 없을 때의 문제점

• Interface와 DI 없이 RepositoryRank가 GitHub 객체를 직접 생성하고 사용하는 경우:

  public class RepositoryRank {
      private GitHub gitHub = new GitHub();
  
      public int getPoint(String repositoryName) throws IOException {
          GHRepository repository = gitHub.getRepository(repositoryName);
          // ...
      }
  }

• 문제점:

  1. RepositoryRank가 GitHub 객체에 강하게 결합되어 있어 구현체 교체가 어렵다.
  2. 테스트 시 실제 GitHub API를 호출해야 하므로 네트워크 환경이나 API 상태에 따라 테스트 결과가 달라질 수 있다.
  3. BitBucket 등 다른 API를 추가하려면 기존 코드를 수정해야 하므로 OCP(Open-Closed Principle)를 위반한다.

4. 구체적인 예시: Interface와 DI를 사용한 설계의 장점

• Interface와 DI를 활용한 현재 설계:

  public class RepositoryRank {
      private GitHubService gitHubService;
  
      public RepositoryRank(GitHubService gitHubService) {
          this.gitHubService = gitHubService;
      }
  
      public int getPoint(String repositoryName) throws IOException {
          GitHub gitHub = gitHubService.connect();
          GHRepository repository = gitHub.getRepository(repositoryName);
          // ...
      }
  }

• 장점:

  1. 유연한 구성: GitHubService 구현체를 교체하거나 확장할 때 RepositoryRank를 수정할 필요가 없다.
  2. 테스트 가능성: Mock 객체를 주입받아 외부 종속성을 제거한 상태에서 로직 테스트 가능.
  3. 확장성: BitBucket, GitLab 등 다른 서비스에 대한 구현체를 추가하고 DI를 통해 주입하면 쉽게 확장 가능.

5. 이 설계의 객체지향 원칙 준수

• SRP(단일 책임 원칙):
  • RepositoryRank는 점수 계산이라는 자신의 주된 역할에만 집중하고, 외부 API 호출 방식은 GitHubService에 위임한다.
• OCP(개방-폐쇄 원칙):
  • GitHubService 구현체를 교체하거나 추가할 때 기존 코드를 수정할 필요 없이 확장이 가능하다.
• DIP(의존성 역전 원칙):
  • RepositoryRank는 구체적인 구현체가 아닌 추상화된 GitHubService 인터페이스에 의존한다.

6. TDD(테스트 주도 개발)와의 연결

• Interface와 DI의 역할:

  • Mock 객체를 사용해 테스트를 독립적으로 수행할 수 있다.
  • 외부 의존성을 제거하여 테스트 속도와 안정성을 확보한다.

• TDD의 본질:

  • 이러한 설계는 테스트 가능성을 높이고, TDD 방식으로 개발할 때 변경에 강한 구조를 제공한다.

7. 스프링과의 연결: DI 컨테이너 활용

• DI 컨테이너의 역할:
  • 스프링의 DI 컨테이너가 GitHubService 구현체를 생성하고 RepositoryRank에 주입함으로써 DI를 자동으로 처리한다.
• 스프링 빈 등록:
  • @Component, @Bean 등을 사용해 GitHubService 구현체를 스프링 컨테이너에 등록하고 관리할 수 있다.
• 테스트 시 Mock 주입:
  • @MockBean을 사용해 테스트 환경에서 Mock 객체를 주입받아 테스트를 수행할 수 있다.

8. 이 내용이 스프링 학습에 중요한 이유

• 스프링은 DI를 기반으로 한 프레임워크로, DI와 Interface를 적절히 사용하는 것이 스프링의 핵심이다.
• 이 예시는 스프링의 철학인 "구성(configuration)과 사용의 분리"를 잘 보여준다.
• 스프링을 제대로 활용하려면 Interface와 DI의 원리와 이점, 그리고 객체지향 설계 원칙을 이해하는 것이 필수적이다.

Interface와 DI를 사용한 설계는 객체지향 원칙을 준수하며, 테스트 가능성과 확장성을 극대화한다. 이 설계를 이해하고 적용하는 것은 스프링 프레임워크의 핵심 철학을 이해하고 활용하는데에 필수적이다.

3. 인덱스와 DML 작업의 상관관계: 인덱스가 DML에 취약한 이유

   • 여기서 DML(Data Manipulation Language)은 데이터를 조작하는 작업(쓰기 작업)을 의미하며, INSERT, UPDATE, DELETE 명령어가 포함된다.
   • 인덱스는 검색 속도에 이점이 있지만, 반대로 DML 작업에는 부담이 될 수 있다.
     • 인덱스를 생성하면, 데이터 삽입, 수정, 삭제 시 인덱스까지 함께 갱신해야 하기 때문이다.
     • 특히, 인덱스가 많을수록 갱신해야 할 인덱스가 많아지면서 작업 속도가 느려진다.
   • 따라서 인덱스는 읽기 작업(SELECT)에는 도움이 되지만, 쓰기 작업(DML)에는 성능 저하의 원인이 될 수 있어 균형 잡힌 설계가 필요하다.

   결과적으로 , 인덱스는 검색 성능을 높여주지만, DML(DML(Data Manipulation Language) 작업이 많아지면 인덱스를 갱신하는 작업이 성능 저하로 이어질 수 있다.

4. 인덱스 스플릿(Index Split) 현상: DML 작업 시(특히 데이터 삽입이 잦은 경우) 발생하는 문제

• 인덱스 스플릿 : 인덱스 페이지가 가득 찬 상태에서 새로운 데이터를 중간에 삽입해야 할 때 발생하는 인덱스 페이지 분할 현상, 인덱스가 자주 갱신되거나 중간 삽입이 빈번한 환경에서는 이 스플릿 현상이 빈번해짐.

• 예를 들어, 순서가 정해진 인덱스에 중간 위치에 새로운 값을 넣어야 하는 상황에서 기존 페이지에 공간이 부족할 경우, 인덱스 페이지를 두 개로 나누어 데이터를 재배치하게 된다. 이로 인해 데이터 재배치와 새 페이지 생성 작업이 추가로 발생하여 성능 저하를 일으킨다.

인덱스 페이지를 나눈다?

인덱스는 데이터를 효율적으로 검색하기 위해 만들어진 특정한 자료 구조 이며, 이 자료 구조는 여러 개의 페이지로 나뉘어 데이터를 저장한다. '페이지'란 데이터베이스가 데이터를 저장하는 기본 단위로, 특정 크기의 데이터 묶음이다.

인덱스 스플릿(Index Split) 현상 발생의 흐름

1. 인덱스는 정렬된 순서로 데이터를 저장해 둔다. 예를 들어, 숫자 순서로 데이터를 정렬한다고 하면 10, 20, 30, 40, 50 같은 순서로 인덱스 페이지에 저장된다.

2. 인덱스 페이지는 한정된 공간을 가지고 있으므로, 한 페이지에 저장할 수 있는 데이터의 양이 정해져 있다. 페이지가 꽉 차면 새로운 데이터를 그 페이지에 추가할 수 없게 된다.

3. 예를 들어, 인덱스가 10, 20, 30, 40으로 차 있는데 중간에 25라는 값을 추가해야 한다면 문제가 생기며, 이미 페이지가 꽉 차 있으므로 더 이상 데이터를 넣을 공간이 없게 된다.

4. 이럴 때 데이터베이스는 인덱스 페이지를 두 개로 나눠서(스플릿) 데이터를 재배치한다.

   • 예를 들어, 기존 페이지를 두 개로 나누고, 한 페이지에는 10, 20을 넣고, 다른 페이지에는 25, 30, 40을 넣는 방식으로 데이터를 재구성하게 된다.

5. 이렇게 되면 새로운 페이지가 추가되고, 기존 데이터가 재배치되면서 더 많은 공간을 확보하게 되며, 이 과정에서 추가적인 작업과 시간이 필요하기 때문에 성능 저하가 발생할 수 있다. (성능 저하가 발생하는 이유는, 페이지가 나뉘게 되묜서 새로운 페이지 생성과 데이터 이동 작업을 필요로 하기 때문에, 추가적인 자원과 시간이 소요되기 때문이다.

• 데이터가 자주 삽입되거나 인덱스가 자주 변경되는 경우에는 이 스플릿 현상이 자주 발생하여 전체 시스템의 성능에 부정적인 영향을 줄 수 있다. ( 예를 들어, 날짜가 순차적으로 증가하는 주문 테이블이 있고, 주문일 컬럼에 인덱스를 걸면, 새로운 주문이 들어올 때마다 날짜가 인덱스의 끝부분에 추가되므로 중간에 삽입이 발생하지 않아 인덱스 스플릿이 거의 일어나지 않는다.) 하지만, 무작위로 생성되는 고객 ID 컬럼에 인덱스를 걸면 새로운 데이터가 중간에 삽입될 가능성이 높아 인덱스 스플릿이 빈번히 발생하여 성능 저하를 초래할 수 있다.)

그러므로, 인덱스를 설계할 때는 삽입이 자주 일어나는 컬럼에 대해 신중하게 고려하고, 인덱스 스플릿 현상이 성능에 미치는 영향을 최소화할 수 있도록 효율적인 인덱스 설계 (삽입이 자주 일어나는 컬럼에 인덱스를 적용할 때, **인덱스 스플릿이 최소화될 수 있도록 설계하도록 하는 설계)**가 필요하다.

이 말은, 집계 함수가 데이터를 계산할 때 NULL 값을 계산 대상에 포함하지 않고 계산한다는 것을 의미한다. 쉽게 말해, 집계 함수는 NULL을 데이터가 없는 것으로 간주하고 제외한 후 결과를 계산한다.

따라서 NULL 값을 처리할 때는 집계 결과에 영향을 미치지 않으니, 필요에 따라 COALESCE 함수 등을 사용해 NULL을 다른 값으로 대체하는 방식을 사용할 수도 있다.

주요 집계 함수와 NULL 처리 방식

1. SUM (합계)

   • NULL 값을 무시하고 나머지 숫자 값만 합산한다.
   • 예: SUM(값)은 NULL을 포함하지 않은 값들만 더한 결과를 반환한다.

2. AVG (평균)

   • NULL 값을 제외한 나머지 숫자 값의 평균을 계산한다.
   • 계산 공식: AVG = (합계 / NULL이 아닌 값의 개수)
   • 예: NULL이 있더라도 나머지 값들로만 평균을 구한다.

3. COUNT (개수)

   • COUNT(*): NULL을 포함한 전체 행의 개수를 반환한다.
   • COUNT(컬럼): 해당 컬럼에서 NULL이 아닌 값의 개수를 반환한다.

4. MAX / MIN (최대값 / 최소값)

   • NULL을 제외한 값들 중에서 최대값과 최소값을 반환한다.

예시로 이해하기

다음과 같은 데이터가 있다고 가정하자:

SUM 함수

SELECT SUM(값) AS 합계 FROM 테이블;

• 10 + 20 + 30 = 60
• 결과: 60

AVG 함수

SELECT AVG(값) AS 평균 FROM 테이블;

• 평균 = 합계 / NULL이 아닌 값의 개수 = 60 / 3
• 결과: 20

COUNT 함수

SELECT COUNT(*) AS 전체행, COUNT(값) AS 값개수 FROM 테이블;

• COUNT(*): 전체 행의 개수(4개)를 반환 (NULL 포함).
• COUNT(값): NULL이 아닌 값만 세기 때문에 3을 반환.
• 결과: 전체행 = 4, 값개수 = 3

MAX / MIN 함수

SELECT MAX(값) AS 최대값, MIN(값) AS 최소값 FROM 테이블;

• 최대값: 30
• 최소값: 10
• NULL은 무시되므로 계산에 포함되지 않음.

계층형 데이터 구조란?

계층형 데이터 구조는 부모-자식 관계와 같이 데이터가 계층적으로 연결된 형태를 말한다. 예를 들어, 조직도나 카테고리 트리 등이 이에 해당한다. 이러한 구조에서는 데이터 간에 상위와 하위 관계가 존재하여 계층을 이루게 된다.

셀프 조인이 필요한 이유

단순히 SELECT 문으로 데이터를 가져오는 것만으로는 테이블 내의 계층 관계를 명확하게 표현하기 어렵다. 특정 항목의 상위 또는 하위 데이터를 함께 조회하려면, 동일한 테이블을 자신과 조인하는 셀프 조인이 필요하다.

예를 들어, 직원 정보를 담은 테이블이 다음과 같이 있다고 가정하자:

• 직원 ID는 각 직원의 고유 식별자이다.
• 이름은 직원의 이름이다.
• 상사 ID는 해당 직원의 상사의 직원 ID를 나타낸다.

이때, 각 직원과 그 직원의 상사 이름을 함께 조회하려면 다음과 같이 셀프 조인을 사용한다:

SELECT 직원.이름 AS 직원이름, 상사.이름 AS 상사이름
FROM 직원
LEFT JOIN 직원 AS 상사 ON 직원.상사ID = 상사.직원ID;

• 직원 테이블을 상사라는 별칭으로 한 번 더 사용하여 셀프 조인을 수행한다.
• ON 절에서 직원의 상사 ID와 상사의 직원 ID를 연결한다.

결과는 다음과 같다:

• 홍길동은 최고 관리자이므로 상사 이름이 null이다.
• 김철수와 이영희의 상사는 홍길동이다.
• 박민수의 상사는 김철수이다.

이렇게 계층형 데이터 모델에서 셀프 조인은 동일한 테이블 내에서 계층 관계를 표현하고 조회하기 위해 필수적이다. 단순한 SELECT 문만으로는 부모-자식 관계를 명확하게 나타낼 수 없으므로, 셀프 조인을 통해 계층 구조의 데이터를 효과적으로 다룰 수 있다.

제 3 정규화의 목적

제 3 정규화는 테이블 내에서 기본 키가 아닌 컬럼이 다른 비키(non-key) 컬럼을 결정하지 않도록 만드는 것이다. 즉, 기본 키에 대해서만 종속성을 갖도록 하여 데이터의 중복을 줄이고, 이상 현상(Anomalies)을 방지하는 것이 목적이다.

이행적 종속(Transitive Dependency)이란?

• 이행적 종속은 비키 컬럼이 또 다른 비키 컬럼을 결정하는 관계를 의미한다.
• 예를 들어, 학생 테이블에서 기본 키가 학생 ID라고 할 때, 학생 ID → 학과 ID → 학과 이름과 같은 형태가 이행적 종속이다. 이 경우 학생 ID는 학과 이름을 직접 결정하지 않고, 중간의 학과 ID를 통해서 결정하는 관계가 발생한다.

제 3 정규화 과정

1. 이행적 종속 관계가 있는 컬럼을 분리하여 새로운 테이블을 생성한다.
2. 생성된 새로운 테이블에 기본 키를 추가하여 나머지 속성들이 오직 그 기본 키에 종속되도록 만든다.

예시

제 3 정규화 전 (이행적 종속 존재)

위 테이블에서는 학생 ID가 기본 키다. 학과 ID는 학생 ID에 종속되어 있지만, 학과 이름이 학과 ID에 종속되는 이행적 종속이 발생하고 있다.

제 3 정규화 후 (이행적 종속 제거)

학생 테이블

학과 테이블

이제 학생 테이블에서 학과 이름 컬럼을 분리하여 학과 테이블을 생성함으로써 이행적 종속을 제거했다. 이제 학생 테이블에서는 모든 속성이 기본 키인 학생 ID에 대해서만 직접적으로 종속되어 있으며, 학과 테이블에서도 학과 ID가 학과 이름을 결정하게 되어 중복을 줄이고 데이터의 일관성을 유지할 수 있게 된다.

이처럼 제 3 정규화를 통해 데이터베이스가 보다 깔끔하고 효율적인 구조를 가지게 된다.

1. 함수적 종속(Functional Dependency)란 하나의 컬럼이 다른 컬럼을 결정하는 관계를 의미한다. 예를 들어, 학생 ID가 학생 이름을 결정할 수 있다면, 학생 이름은 학생 ID에 함수적으로 종속되어 있다고 할 수 있다.

2. 부분 함수적 종속(Partial Dependency)이란 복합 키(여러 개의 컬럼이 합쳐져 기본 키 역할을 하는 경우)를 사용하는 테이블에서, 기본 키의 일부만으로 특정 컬럼이 종속되는 것을 의미한다. 예를 들어, 수강 테이블에서 (학생 ID, 과목 ID)가 기본 키라면, 학생 이름이 학생 ID에만 종속되는 경우가 발생할 수 있다. 이때 학생 이름은 전체 기본 키 (학생 ID, 과목 ID)에 대해 부분적으로만 종속된 것이다.

3. 완전 함수적 종속(Full Functional Dependency)이란 기본 키의 모든 컬럼에 대해 종속된 상태를 의미한다. 제 2 정규화를 달성하려면 기본 키의 일부가 아닌 전체에 대해 완전히 종속되어야 한다.

제 2 정규화 과정은 이러한 부분 함수적 종속을 제거하기 위해 부분적으로 종속된 컬럼들을 별도의 테이블로 분리하는 것이다. 예를 들어, 학생 ID와 관련된 속성들(예: 학생 이름, 학년)을 새로운 테이블 학생 테이블로 분리하여, 수강 테이블에서는 완전하게 종속된 속성들만 남겨두는 방식으로 나눌 수 있다.

이 과정을 통해 데이터 중복을 줄이고 테이블 구조가 보다 효율적으로 변하게 된다.

아래는 제 2 정규화 전후의 예시를 테이블로 정리한 것이다. 이 예시는 수강 테이블을 기준으로 부분 함수적 종속을 제거하는 과정을 보여준다.

제 2 정규화 전 (부분 함수적 종속 존재)

위의 테이블에서는 학생 ID와 과목 ID가 복합 기본 키다. 하지만 학생 이름과 학년은 학생 ID에만 종속되어 부분 함수적 종속이 발생하고 있다.

제 2 정규화 후 (완전 함수적 종속)

학생 테이블

수강 테이블

이제 학생 테이블과 수강 테이블로 분리되어, 학생 ID와 관련된 학생 이름과 학년 속성들이 완전 함수적 종속 관계를 갖게 되었다. 이를 통해 데이터의 중복이 줄어들고, 테이블이 보다 효율적으로 관리될 수 있게 된다.

첫 번째 테스트 코드

@Test
@DisplayName("Post 작성 성공")
void testCreatePostSuccess() {
    String title = "Sample Title";
    String body = "Sample body";
    String userName = "sampleUserName";

    // Mocking
    when(userEntityRepository.findByUserName(userName)).thenReturn(Optional.of(mock(UserEntity.class)));
    when(PostEntityRepository.save(any(PostEntity.class))).thenReturn(mock(PostEntity.class));

    PostEntity mockPost = new PostEntity(title, body);
    when(PostEntityRepository.save(any())).thenReturn(mockPost);

    Assertions.assertDoesNotThrow(() -> postService.createPost(title, body, userName)); 
}

설명

1. userEntityRepository Mocking: findByUserName(userName) 호출 시 모의 UserEntity 객체를 반환하도록 설정하여, 데이터베이스에 실제 사용자가 있는 것처럼 시뮬레이션합니다.
2. PostEntityRepository Mocking:
   • PostEntityRepository.save(any(PostEntity.class)) 호출 시 mock(PostEntity.class) 객체가 반환되도록 설정합니다.
   • 이후 PostEntity mockPost를 생성하여, PostEntityRepository.save(any()) 호출 시 mockPost를 반환하도록 추가로 설정합니다.
3. Assertions.assertDoesNotThrow(...): postService.createPost(...) 호출 시 예외가 발생하지 않는지 확인합니다. 여기서 예외가 발생하면 안 되는 이유는, 성공적인 Post 생성 로직이 실행되었음을 확인하는 테스트이기 때문입니다. 예외가 발생하면 Post 생성이 실패한 것으로 간주됩니다.

특징

• 이 테스트는 기본적인 Mocking만 수행하고 있습니다.
• PostEntity 인스턴스를 두 번 Mocking하는 불필요한 중복이 있을 수 있습니다.

두 번째 테스트 코드

@Test
@DisplayName("Post 작성 성공")
void testCreatePostSuccess() {
    TestInfoFixture.TestInfo fixture = TestInfoFixture.get();

    when(userEntityRepository.findByUserName(fixture.getUserName()))
        .thenReturn(Optional.of(UserEntityFixture.get(fixture.getUserName(), fixture.getPassword())));
    when(postEntityRepository.save(any())).thenReturn(mock(PostEntity.class));

    Assertions.assertDoesNotThrow(() -> 
        postService.createPost(fixture.getUserName(), fixture.getTitle(), fixture.getBody())
    );
}

설명

1. TestInfoFixture를 사용한 Mocking: TestInfoFixture.get() 메서드를 사용하여 fixture 객체를 받아옵니다. 이 객체는 테스트용 데이터를 포함한 객체로, userName, title, body 등의 속성을 가진 TestInfoFixture.TestInfo 인스턴스입니다.
2. Fixture를 사용한 데이터 설정:
   • UserEntityFixture.get(...)을 통해 실제와 유사한 UserEntity 객체를 생성하고 반환합니다. 이는 데이터가 일관된 형태를 유지하도록 도와주어 테스트의 가독성을 높입니다.
   • userEntityRepository.findByUserName(fixture.getUserName())이 호출되면 UserEntityFixture.get(...)을 통해 생성된 모의 UserEntity가 반환되도록 설정합니다.
3. postEntityRepository.save(any()) Mocking: postEntityRepository.save(any())가 호출될 때 모의 PostEntity 객체를 반환하도록 설정합니다.

특징

• Fixture를 통해 데이터의 일관성을 유지합니다. Fixture는 여러 테스트에서 동일한 데이터를 사용하여, 테스트 코드의 반복을 줄이고 코드 가독성을 높입니다.
• 더 깔끔한 Mocking: PostEntity의 Mocking이 단일 호출로 이루어지며, 첫 번째 테스트에 비해 불필요한 Mocking이 줄어듭니다.

비교 및 차이점 요약

결론적으로, 두 번째 코드가 Fixture를 통해 데이터 일관성을 제공하고, 중복된 Mocking을 제거하여 가독성과 유지보수성을 높인 테스트 코드입니다. Fixture를 적극적으로 활용하면 코드의 구조가 더 명확해지고 테스트 유지 관리가 용이해집니다.

로그인 성공을 테스트하기 위해 다음과 같이 코드를 작성했지만, encoder.matches(...) 부분에서 에러가 발생함

@Test
@DisplayName("로그인 성공: 올바른 사용자명과 비밀번호")
void testUserLoginSuccess() {
    // 테스트에 필요한 사용자 정보를 설정
    String userName = "testuser";
    String password = "password";

    // Fixture로 테스트용 가짜 UserEntity 생성
    UserEntity fixture = UserEntityFixture.get(1L, userName, password);

    // Mocking 설정
    when(userEntityRepository.findByUserName(userName)).thenReturn(Optional.of(fixture));

    // 실제 메서드 실행 및 성공 여부 검증
    Assertions.assertDoesNotThrow(() -> userService.login(userName, password));
}

이 코드에서는 userEntityRepository.findByUserName(userName)의 결과를 Mocking하여 fixture를 반환하도록 했으나, 테스트가 여전히 실패함

-> 이슈 해결 : encoder.matches(...) 부분을 추가로 Mocking 하는 코드를 추가 (encoder.matches(...) 부분에서 실제 비밀번호 비교가 이루어지지 않아 에러가 발생한 것으로 파악)

encoder.matches(...)는 비밀번호를 비교하는 메서드로, 로그인 시 사용자가 입력한 비밀번호와 DB에 저장된 인코딩된 비밀번호를 비교하지만,테스트 환경에서는 입력 비밀번호와 암호화된 비밀번호의 일치 여부를 파악할 필요가 없음. 그러므로, 비밀번호가 일치한다고 가정하는 상황을 만들어주어야 테스트가 원활하게 진행되며,

이를 위해 encoder.matches(...)를 다음과 같이 기존 코드에 추가로 Mocking하여 항상 true를 반환하도록 설정. (mocking 의도 : 로그인 성공을 위한 테스트의 조건을 간단하게 만들기 위함 ~ Mocking으로 특정 결과를 반환하도록 설정한다.)

(추가한 코드)

when(encoder.matches(password, fixture.getPassword())).thenReturn(true);

(정리)

1. 이 Mocking 설정이 없을 경우, encoder.matches(...)는 실제로 비밀번호를 비교하는데, 테스트에서는 이 과정이 불필요하고, 실제 암호화된 비밀번호가 없으므로 비밀번호 비교가 항상 실패하여 테스트가 실패하게 되는 것이다.

2. Mocking 추가 후: encoder.matches(...)가 true를 반환하도록 설정하여, userService.login(...) 메서드는 비밀번호가 일치한다고 가정하고 테스트가 통과됨

수정 후 정상 로그인 테스트를 통과한 코드

@Test
@DisplayName("로그인 성공: 올바른 사용자명과 비밀번호")
void testUserLoginSuccess() {

    // 테스트에 필요한 사용자 정보를 설정
    String userName = "testuser";
    String password = "password";

    // Fixture로 테스트용 가짜 UserEntity 생성
    UserEntity fixture = UserEntityFixture.get(1L, userName, password);

    // Mocking 설정
    when(userEntityRepository.findByUserName(userName)).thenReturn(Optional.of(fixture));
    when(encoder.matches(password, fixture.getPassword())).thenReturn(true); // 추가된 Mocking 설정

    // 실제 메서드 실행 및 성공 여부 검증
    Assertions.assertDoesNotThrow(() -> userService.login(userName, password));
}