temp0.7은 생성형 AI를 단순히 결과물 생성 도구로 소비하는 것이 아니라,
AI 모델의 작동 원리, 프롬프트 설계, 데이터 처리 방식, 모델의 한계와 편향을 이해하고
이를 실제 문제 해결에 적절히 활용하는 방법을 탐구하는 융합 학술 동아리이다.

본 동아리는 금융 데이터 분석, 경량 LLM 실험, 머신러닝 모델 학습, 웹 서비스 연동 프로젝트를 통해
생성형 AI를 똑똑하게 사용하는 역량을 기르는 것을 목표로 한다.

융합 동아리 목표

로컬 경량 LLM 모델을 직접 학습/파인튜닝하고, 머신러닝 실험 환경을 확보한 뒤, 학습된 모델을 웹 서비스와 API 형태로 연동하는 것

플랫폼 비교

Hugging Face 고려할 만한 모델

Azure에서 쓸 수 있는 모델/서비스 구분

Azure에서 고려할 만한 모델

플랫폼별 비용/크레딧 비교

ㅁㄴㅇㅁ

설문조사 만들어보면 구글폼이나 타입폼 같은 거 써봤을 텐데, 막상 응답 보면 좀 아쉽다. 왜 이렇게 생각했는지. 오늘 소개할 Theysaid는 그 문제를 AI로 풀어낸 서비스이다.

Theysaid가 뭔데?

한 줄 요약하면, AI가 설문을 대화형 인터뷰로 바꿔주는 툴이에요.

기존 설문은 응답자가 질문 보고 답 입력하고 끝인데, Theysaid는 응답자가 답을 입력하면 AI가 꼬리 질문을 던져요. 예를 들어 "구독 가능성 4점"이라고 하면, AI가 바로 "오 높게 주셨네요, 어떤 부분에서 그렇게 생각하셨어요?" 이런 식으로요. 인터뷰랑 설문을 합쳐놓은 느낌?

핵심 기능들

1. AI 프로젝트 생성 (AI Project Creator)

설문을 만들 때 질문을 하나하나 직접 짤 필요 없어요. AI 버디 Evo한테 목적만 말하면 된다.

예를 들어 "고객 피드백을 모으고 싶어" 라고 입력하면 Evo가 몇 가지 추가 질문을 통해 맥락을 파악하고, 거기에 맞는 설문/인터뷰 프로젝트를 통째로 만들어줘요. 질문 유형(5점 척도, 서술형, 객관식, 랭킹 등)도 알아서 잡아준다. 단순히 질문 생성에서 끝나는 게 아니라, 생성된 질문을 개선 / 수정 / 직접 입력 세 가지 방식으로 다듬을 수 있다.

2. AI 가르치기 (Teach AI)

이게 진짜 특이한 기능인데, 우리 회사 문서나 웹사이트 URL을 AI한테 업로드해주면 AI가 우리 조직의 맥락, 톤, 목표를 학습한다. 그러면 이후 질문을 생성할 때 단순 일반 질문이 아니라 우리 서비스에 맞춤화된 질문을 뽑아줘요. 학습 자체는 약 10~15분이면 완료된다.

예: 진행중인 서비스라면 우리 제품 도움말 문서를 업로드 → AI가 제품 구조를 이해하고 거기에 맞는 질문 생성

3. 대화형 응답 수집 (AI Moderation)

가장 핵심 기능이다. 응답자가 답변을 입력하면 AI가 그걸 보고 추가 질문(Follow-up)을 던진다. 채팅처럼 자연스럽게 흘러가서 응답자 입장에서도 훨씬 편하고, 우리 입장에서도 더 깊은 인사이트를 얻을 수 있다.

3.0 업데이트부터는 2-Way Voice 기능도 추가됐다. 텍스트 대신 음성으로도 대화할 수 있어서 더 자연스러운 인터뷰가 가능해졌다.

4. AI 분석 + 액션 아이템

응답이 다 모이면 그냥 숫자만 보여주는 게 아니다.

• 테마 분석: 응답 전체에서 반복되는 패턴과 주요 주제를 자동으로 정리
• 인사이트 요약: "사용자들은 가격 대비 가치를 긍정적으로 인식하고 있다" 같은 종합 평가
• 액션 아이템: "멤버십 소개가 부실하다는 응답이 많음 → 상세 설명 페이지 보완 필요" 식으로 체크리스트 형태로 제공

작은 프로젝트라면 여기서 바로 진행 여부 관리도 가능함.

5. Conditional Logic (조건부 분기)

응답 내용에 따라 다음 질문을 다르게 보내주는 기능이다. 예를 들어 NPS 점수가 낮으면 "어떤 부분이 불만족스러우셨나요?", 높으면 "가장 마음에 드셨던 부분이 뭔가요?" 이런 식으로 개인화된 흐름을 만들 수 있다.

6. AI 이탈 방지 (Re-engagement)

응답자가 대화 중간에 멈추면 AI가 먼저 "Still there?" 하고 말을 건다. 일반 설문이면 그냥 탭 닫고 끝인데, 이렇게 대화를 이어가려는 시도 자체가 응답 완료율을 높이는 데 도움이 됨. 작은 기능 같지만 UX 관점에서 꽤 신경 쓴 디테일이다.

기존 설문 툴이랑 다른점

아쉬운 점

• 서비스 언어가 영어라 한글로 바꾸는 작업을 계속 요청해야 함
• AI가 가끔 질문 흐름을 놓쳐서 이미 답한 내용을 또 묻기도 함
• AI를 가르치다" 기능이 언제 어디에 적용되는지 UI에서 명확하게 안 알려줌
• 서버가 불안정함

써볼 만한 이유

무료 플랜으로 설문 1개에 응답 50개까지 가능함. 유저 리서치나 팀 내 피드백 수집할 일 있으면 한번 써보셈.

👉 ai.theysaid.io

CEN AI는 아이티센클로잇에서 개발한 기업 맞춤형 클라우드 기반 AI 챗봇 서비스로 이미 사용 중인 구글 클라우드 같은 플랫폼 기반으로 우리 회사만의 생성형 AI 챗봇을 구축할 수 있다면 어떨까? 업무 생산성은 또 얼마나 달라질까요?

아이티센클로잇은 멀티 클라우드 환경에서 Cloud Native 애플리케이션 개발과 DevOps 플랫폼 구축 등 전문기술 역량을 갖춘 기업이다. 특히 클라우드 기반 AI 기술과 데이터 분석 역량을 바탕으로 다양한 산업분야의 디지털 혁신을 기술적으로 지원하고 있다. 클라우드 전환, 구축과 운영, 컨설팅, 솔루션 제공까지 다양한 영역에서 활동중이다.

회사에 맞는 생성형 AI 챗봇 왜 필요한가?

• 챗GPT나 gemini와 같은 범용 AI 모델은 개인을 위한 서비스이다.

• 범용 LLM(대규모 언어 모델)은 일반적인 데이터를 학습한 것이지, 회사의 구체적인 내부 데이터는 학습하지 못한다.

실제로 지식 노동자들은 하루 8시간 중 생산적인 시간은 2시간 정도고, 나머지 6시간은 정보 검색 등 준비 작업에 소비한다.

특히 RAG(검색증강생성)기술을 쓰면 기업 내부에서 생산된 최신 데이터를 정화히 활용, AI가 흔히 일으킬 수 있는 할루시네이션 현상을 크게 줄이고, 답변의 출처까지 명확히 제공해 신뢰도를 높인다.

생성형 AI 챗봇의 성능은 결국 데이터의 품질과 양에 따라 결정된다. 하지만 많은 기업들이 이미 갖추고 있는 데이터들이 잘 정리되어 있지 않거나, 상당히 파현화되어 있는 경우가 많다. -> 그래서 도입 초기에 모든 데이터를 완벽하게 준비하려하지 않고, 명확한 평가가 가능한 특정 시나리오와 관련된 데이터를 우선적으로 준비했다.

실제로 범용 AI 모델을 쓰면 정보의 정확도가 80%정도지만, 기업 전용 챗봇을 활용하면 정확도가 95% 이상으로 올라간다.

구글 클라우드 벤더 기반 장점

1. 빠르게 서비스를 출시할 수 있다.

2. 비용 관리 측면에서 효율적이다.

3. 데이터 관리와 보안이 쉽고 안정적이다.

클라우드 환경의 큰 장점은 관리형 서비스가 많다는 점이다. 이는 기업이 최신 기술의 인프라나 서비스 구축과 설정, 관리조차 직접하지 않아도 된다.

CEN AI도 최신 기술 기반의 클라우드 서비스를 이용해 개발한 솔루션으로, 고객사 환경에 적용할 때도 클라우드 환경을 활용하기 때문에, 온프레미스 기반의 솔루션보다 훨씬 빠르고 간편하게 구축할 수 있다.

기반 클라우드 서비스를 구글 클라우드로 선택한 이유

• 다양한 형태의 데이터와 이를 잘 처리하는 제미나이 모델의 장점

• 제미나이 모델이 다양한 형태의 데이터를 잘 다룬다.

CEN AI 유지보수

데이터 라이프 사이클 관리와 챗봇의 응답 품질 관리를 위해 기업 환경에서 정확한 정보를 제공하는 것이 핵심이기 때문에 사용자 피드백을 적극적으로 수집하고, 로그 분석 및 품질 프레임워크를 도입함. 또 보안 리스크를 위해 데이터 암호화 및 마스킹, 입력이나 출력 단계의 가드레일, 역할 기반 접근 제어 등 보안장치들을 추가해 나가고 있다.

RAG 기술은 기본적으로 공개된 정보만 학습된 일반적인 언어모델을 기업 내부의 데이터까지 확장할 수 있도록 해주는 기술이다. 사용자의 질문을 정확히 분석한 뒤, 관련된 기업 내부 문서를 검색하고, 이를 종합적으로 분석,요약해서 최적의 결과를 제공하는 기술이다.

내부 시스템 및 데이터 연동과 기존 챗봇과의 비교

CEN AI는 기업이 내부에 가지고 있는 데이터를 찾아서 쓸 수 있도록 RAG 기술을 기반으로 만들었고 ERP나 CRM 같은 기존 시스템들이랑도 쉽게 연결할 수 있다.

특히 자체적으로 만든 도큐먼트 파서 같은 기술을 이용해서 단순히 키워드만 뽑는 게 아니라 문서의 맥락이나 의도까지 이해하도록 했다. 또 데이터를 업무나 특성에 맞춰 각각의 AI 에이전트로 만들고, 이 에이전트들을 하나의 슈퍼 에이전트가 다시 통합해서 관리하기 때문에, 여러 시스템과 데이터를 자연스럽게 연결 할 수 있다.

비즈니스 관점에서 CEN AI는 일반 생성형 AI 챗봇과 차별화된 노선을 지향한다. -> 단순히 정보만 주는 게 아니라, 실제 기업 고객의 업무 상황과 맥락을 이해하고, 업무를 직접 도와주는 역할까지 한다. 회사 내부 시스템과 쉽게 연동해서 업무를 자동화하거나 최적하고 불특정 다수의 사용자를 대상으로 한 일반 생성형 AI 챗봇과 달리 CEN AI는 기업마다 서로 다른 요구에 맞춰 유연하게 쓸수 있어 기업 사용자의 실제 업무 효율을 높인다.

CEN AI 핵심 기능

CEN AI 기술

• MCP(Model Context Protocol)

• A2A(Application-to-Apllication)

• ADK(Application Development Kit)

CEN AI 플로우

느낀점

이번 CEN AI를 조사하면서 단순한 AI 챗봇이 아니라, 기업 환경에서 실제 업무를 처리하기 위한 구조적인 AI 시스템이 필요하다는 점을 알게 되었다. 기존에 내가 생각하던 AI는 질문에 답변을 제공하는 수준이었지만, CEN AI는 여러 AI Agent가 역할을 나누고, 내부 데이터와 외부 데이터를 함께 활용하며, 실제 업무까지 수행하는 구조라는 점에서 큰 차이가 있었다.

특히 MCP, A2A 기술을 통해 AI가 협업하고 데이터를 활용하는 구조가 인상 깊었으며, 이는 내가 진행 중인 PromptGuard 프로젝트에도 적용할 수 있는 방향이라고 느꼈다.

서비스에서 사용자의 신원을 검증하고 식별된 사용자에 맞춰 서비스를 제공하기 위해서는 별도의 검증 프로세스가 필요하다.

인증

"너 누구야?"를 확인하는 과정

사용자가 누구인지 신원을 확인하는 절차이다.

• 아이디 + 비밀번호 로그인
• 지문 인식
• OTP 인증
• 구글 로그인

과정 흐름

1. 사용자가 로그인 요청
2. 서버가 비밀번호/토큰 확인
3. 맞으면 -> 인증 성공
4. 틀리면 -> 인증 실패

@PostMapping("/login")
public ResponseEntity<?> login(@RequestBody LoginDto dto) {
    authenticationManager.authenticate(
        new UsernamePasswordAuthenticationToken(dto.getUsername(), dto.getPassword())
    );
}
// 인증은 신원 확인이다.

인가

"그래서 이 사람이 이걸 해도 돼?"를 확인하는 과정

이미 인증된 사용자가 특정 자원에 접근할 권한이 있는지를 확인하는 과정이다.

• 일반 유저는 관리자 페이지 접근 불가
• 글 작성자는 자기 글만 수정이 가능
• 관리자만 회원 삭제 가능

@PreAuthorize("hasRole('ADMIN')")
@GetMapping("/admin")
public String adminPage() {
    return "관리자 페이지";
}
// 인가는 권한 확인이다.

현대적인 온라인 서비스들은 대부분 인증과 인가를 기반으로 운영된다. 또한 대부분의 웹/앱 서비스들은 HTTP 프로토콜을 사용하여 통신한다. HTTP 프로토콜은 비연결성(Connectionless), 무상태(Stateless)의 특징을 지니기 때문에, 최초 로그인을 한 이후 서버에서 클라이언트에 이전 상태를 기억하고 있지 않다.

지연로딩이란?

JPA에서 실제 데이터가 필요한 시점까지 데이터베이스 조회를 지연하는 기법이다.

엔티티를 처음 조회할 때 연관된 데이터를 즉시 로드하지 않고, 그 연관된 데이터가 실제로 사용될 때 데이터베이스에서 조회하는 방식이다. -> 불필요한 데이터 조회를 줄여서 성능을 최적하하는데 유리하다.

지연로딩의 기본동작

지연 로딩을 설정하면 연관된 엔티티나 컬렉션은 처음에 프록시 객체로 로드된다.

프록시는 실제 엔티티를 대신하는 객체로, 데이터베이스 조회가 필요할 때 프록시가 실제 데이터를 조회하여 값을 제공한다.

따라서 처음부터 연관된 데이터를 모두 로드하는 것이 아니라 실제 접근 시점에 데이터베이스에서 로드 되도록 지연된다.

@oneToMany 지연로딩 설정

@Entity
public class Team {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "team", fetch = FetchType.LAZY) // 지연 로딩 설정
    private List<Member> members = new ArrayList<>();

    // getter, setter
}

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "team_id")
    private Team team;

    // getter, setter
}

Team 엔티티의 members 필드에 fetch = FetchType.LAZY 옵션을 설정했다.

Team 엔티티를 조회할 때 members 리스트는 데이터베이스에서 즉시 로드되지 않으며, members 컬렉션에 실제 접근하는 순간 데이터베이스에서 조회가 이루어진다.

지연로딩의 장점

1. 성능 최적화

• SELECT 수 감소
• JOIN 감소
• 네트워크 트래픽 감소
• DB CPU 사용량 감소

2. 쿼리 예측이 쉬워짐

• EAGER는 언제 쿼리가 나가는지 코드만 보고 알기 어렵다.

3. 큰 연관 관계 관리

• 연관된 데이터가 많은 경우, 초기 로딩 시 성능 저하를 방지하고 필요한 시점에 필요한 데이터를 불러온다.

4. 복잡한 연관관계에서 안전하다.
5. 화면/기능별로 유연한 조회 전략이 가능하다.

• 지연로딩을 쓰면 조회 전략을 선택할 수 있음.

6. 실무 패턴과 잘 맞는다.

지연로딩의 주의사항

1. 프록시 초기화

• 지연 로딩된 프록시는 트랜잭션 범위를 벗어난 후에는 초기화할 수 없기 때문에, 연관 데이터를 접근하려면 트랜잭션 내에서 접근해야 한다.

*2. N + 1 *

• 지연 로딩을 잘못 사용하면 N + 1 문제가 발생한다. 이를 해결하기 위해 fetch join을 쓰거나 DTO를 직접 조회해야한다.

3. 직렬화 문제 → 지연 로딩된 엔티티를 컨트롤러에서 그대로 반환하면, JSON 직렬화 과정에서 프록시가 초기화되며 예외나 불필요한 쿼리가 발생할 수 있다.

4. 로그·디버깅 문제 → 엔티티를 로그로 출력하거나 디버깅할 때 toString()이나 getter 호출로 지연 로딩이 실행되어 의도치 않은 DB 조회가 발생할 수 있다.

5. equals / hashCode 문제 → equals나 hashCode에서 연관 엔티티에 접근하면 프록시가 초기화되어 성능 저하나 예외가 발생할 수 있으므로 식별자 기준으로만 구현해야 한다.

6. 컬렉션 + 페이징 문제 → 지연 로딩된 컬렉션을 fetch join과 함께 페이징하면 메모리 페이징이 발생해 심각한 성능 문제가 생길 수 있다.

7. 만능 오해 → 지연 로딩은 성능 최적화 수단일 뿐 만능이 아니며, 상황에 따라 fetch join이나 DTO 조회와 함께 사용해야 한다.

JPA를 사용하여 데이터를 수정하려면 Entity를 조회하여 조회된 Entity 데이터를 변경만 하면 데이터 베이스에 자동으로 반영이 되도록하는 기능을 바로 Ditry Checking이라고 한다.

Dirty Checking의 동작 방법

JPA는 영속성 컨텍스트를 생성하여 DB와 유사하게 이용하여 Entity의 Life Cycle을 관리한다.

그럼 JPA는 영속성 컨텍스트에 Entity를 보관할 때 최초의 상태를 저장하고 있다. 이것을 스냅샷이라고 하며 영속성 컨텍스트가 Flush되는 시점에 스냅샷과 Entity의 현재 상태를 비교하여 달라진 Entity를 찾는다.

이후 변경된 필드들을 이용하여 쓰기지연 SQL 저장소에 Update 쿼리를 생성하여 쌓아둔다.

모든 작업이 끝나고 트랜잭션을 커밋을 하면 이때 쓰기지연 SQL 저장소에 있는 쿼리들을 DB에 전달항 Update를 진행한다.

@Transactional
public void updateUsername(Long id) {
    Member member = memberRepository.findById(id).get(); // 영속 상태
    member.setUsername("newName"); // 값 변경
    // save() 없음!
}

이 코드에 반영되는 것은?

UPDATE member SET username = 'newName' WHERE id = ?

-> 이게 dirty checking이다.

Dirty Checking의 동작조건

1. 영속 상태여야 한다.
2. 트랜잭션 안에 있어야 한다.
3. 값이 실제로 변경되야 한다.

readOnly = true 라면?

• dirty checking 비활성화
• 조회 전용 메서드에 붙이는게 좋음

Dirty Checking은 영속성 컨텍스트가 관리하는 엔티티의 변경 사항을 자동으로 감지하여 트랜잭션 커밋 시점에 UPDATE SQL을 생성하는 JPA의 핵심 기능이다.

이 문제는 문자열 배열 seoul이 주어졌을 때, 배열 안에 포함된 Kim의 위치를 찾아서 그 값을 이용해 지정된 형식의 문자열을 반환하는 문제이다.

for문을 사용해서 Seoul 배열안에 Kim이라는 문자열과 동일한 이름의 문자열이 있으면 그 인덱스를 찾아 반환하면 된다.

class Solution {
  public String solution(String[] seoul) {
    for (int i = 0; i <= seoul.length; i++){
      if(seoul[i].equals("Kim")){
        return "김서방은 " + i + "에 있다";
      }
    }
    return "";
  }
}

String 배열의 seoul에 문자를 넣어주고 solution() 메서드를 호출하고 결과를 result에 저장해 호출한다.

public class Main {
  public static void main(String[] args) {
    Solution sol = new Solution();
    String[] seoul = {"Jane", "Kim"};
    String result = sol.solution(seoul);
    System.out.println(result);
  }
}

Hook

Hook을 직역하면 "갈고리"라는 뜻이다. react에서 hook은 hook into에서 따왔다고 한다. hook into는 "~에 연결하다" 혹은 "연동"의 의미를 가지고 있다. 이 Hook을 사용하면 Functional compenentd에 변수를 연결하여 lifecycle을 관리할 수 있다.

Funtional component? -> 함수로 작성된 component

Hook은 Web application을 설계하는데 매우 직접적인 개념이다. 사실 Web에서 javascript 기능 없이 index.html만 간단하게 디자인 적으로 제공한다면 Hook은 필요 없을지도 모릅니다.

React Hook의 규칙

1. 리액트 Hook은 반복문, 조건문 혹은 중첩된 함순 내에서 호출되며 받느시 최상위에서만 Hook을 호출 해야한다. 또한 Hook은 렌더링 시 항상 동일한 순서로 호출 되어야한다.

2. Hook은 React함수 내에서 호출 해야한다. 즉 리액트 Hook은 함수형 컴포넌트에서 호출해야하고 추가적으로 custom hooks에서 호출이 가능하다.

마지막으로, 커스텀 Hook은 여러 Hook을 조합하여 반복되는 로직을 하나의 함수로 분리한 것이다. 커스텀 Hook을 사용하면 코드 중복을 줄이고, 기능 단위로 로직을 재사용할 수 있어 유지보수성이 향상된다.

다음은 UseState와 use Effect에 대해 알아보겠다

vite(프랑스어로 '빠르다')는 Vue.js의 창시자 Evan You가 개발한 차세대 프론트엔드 빌드 도구로 네이티브 ESM을 기반으로 한 즉가적인 서버 구동과 빠른 HMR(페이지를 새로고침하지 않고 수정된 모듈만 즉시 교체하여 반영하는 기능)을 제공한다.

Vite 프로젝트를 실행하기 위해서는 node.js가 깔려있어야합니다.

node.js 설치

그럼 이제 본격적으로 vite 프로젝트를 생성해보겠다. 일단 먼저 cmd창을 관리자 권한으로 실행해주세요. 저는 D드라이브에 폴더 생성하겠습니다.

npm create vite@latest

위 명령어를 입력해서 폴더를 생성해주세요. 그리고 Project name을 입력해주세요.

저는 framework를 React를 사용할 것이기 때문에 React 골라주도록 하겠습니다.

언어 방식 선택에서 Javascript를 골랐고 rolldonw-vite가 뜨는데 No 선택해주시면 됩니다.

npm 설치해주시면 됩니다.

터미널 창에 주소를 복사해서 url 주소에 넣고 다음과 같은 화면이 나오면 성공입니다.

먼저 NVM을 설치해보자. 인터넷에 NVM 설치를 검색하면 NVM 설치 공식 사이트가 있습니다. 거기서 nvm-setup.exe 클릭해서 다운받아주세요.

NVM 설치 공식사이트

이 화면이 나오면 설치해주시면 됩니다.

설치가 완료되면 cmd창을 열어서 nvm이라고 검색해주세요. ⚠️ cmd는 관리자 권한으로 실행 눌러주세요

nvm 이라고 검색을 하면 nvm 설치 확인 여부와 버전을 알 수 있습니다.

Node 24 설치

nvm install 24

cmd 창에 위 명령어를 입력해주세요.

이렇게 뜨면 24 버전이 설치가 완료되었습니다.

이 문제는 주어진 수가 짝수이면 2로 나누고, 홀수이면 3을 곱한 뒤 1을 더하는 과정을 반복하면서 해당 연산이 1이 될 때까지 몇 번 수행되는지를 계산하는 문제이다.

주어진 수가 1인 경우에 0, 수행된 횟수가 500번을 넘길 때까지 1이 되지 않으면 -1을 반환하여야합니다.

class Solution {
  public int solution(long num) {
    int count = 0;
    if (num == 1) return 0;

    while(true){
      if (num % 2 ==0){
        num /= 2;
        count += 1;
      }
      else {
        num = num *3 + 1;
        count += 1;
      }
      if (num == 1){
        break;
      }
    }
    if(count > 500){
      return -1;
    }
    else{
      return count;
    }
  }
}

while(true)를 사용해서 무한 루프를 굴려주고 정수가 1이 되면 break로 반복문을 빠져나오게 만들면 되는 간단한 문제입니다.

public class Main{
  public static void main(String[] args) {
    Solution sol = new Solution();
    int result = sol.solution(626331);
    System.out.println(result);
  }
}

626331은 카운트 횟숫가 500이 넘어가기 때문에 -1을 반환하는 것을 볼 수 있습니다.

자바 애플리케이션에서 데이터베이스와 상호작용할 때 Entity는 중요한 역할을 합니다. JPA에서 Entity는 데이터베이스의 테이블과 자바 클래스 간의 매핑을 정의하며, 데이터베이스 작업을 객체지향적으로 관리할 수 있게 도와줍니다.

EntityMangerFactory

클래스 자체나 생성한 인스턴스도 엔티티라고 부릅니다. 엔티티 매니저 팩토리는 엔티티 매니저 인스턴스를 관리하는 주체이다 애플리케이션 실행 시 한 개만 만들어지며 사용자로부터 요청이 오면 엔티티 매니저 팩토리부터 엔티티 매니저를 생성합니다.

EntityManager

엔티티 매니저란 영속성 컨텍스트에 접근하여 엔티티에 대한 테이터 베이스 작업을 제공합니다.

1. find() : 영속성 컨텍스트에서 엔티티를 검색하고 영속성 컨텍스트에 없을 경우 데이터베이스에서 데이터를 찾아 영속성 컨텍스트에 저장한다.

2. persit() : 영속성 컨텍스트를 저장한다.

3. remove() : 엔티티 클래스를 영속성 컨텍스트에서 삭제한다.

4. flush() : 영속성 컨텍스트에 저장된 내용을 데이터베이스에 반영한다.

영속성 컨텍스트와 사용시 이점에 대해서는 전 블로그를 참고해주세요 엔티티 설명

ORM과 JPA에 대한 설명

JPA의 작동방식

JPA는 자바 객체(Entity)와 데이터베이스 테이블을 매핑하여, SQL을 직접 작성하지 않고도 DB를 다룰 수 있게 해주는 ORM 표준이다.

Controller -> Service -> Repository(JPA) -> EntityManager-> 영속성 컨텍스트 -> DB

Entity

DB 테이블과 매핑되는 자바 객체

@Entity
public class Member {
  @Id
  private Long id;
}

**EntityManager**

JPA의 실질적인 관리자
CRUD 담당

> ```
entityManager.persist(entity);
entityManager.find(Member.class, id);

영속성 컨텍스트

Entity를 관리하는 1차 캐시 공간

JAP 동작 단계별 설명

1. 엔티티 생성 (비영속 상태)

 Member member = new Member("kim");

• 자바 객체
• DB랑 관계 X

2. 영속 상태 전환

entityManager.persist(member);

• 객체가 영속성 컨텍스트의 1차 캐시에 저장됨
• 엔티티 상태가 비영속 -> 영속(managed)로 변경

3. 쓰기 지연(SQL 저장 단계)

• persist() 호출과 동시에 JPA는 해당 엔티티에 대한 INSER SQL을 생성하지만 즉시 DB에 실행하지 않고 쓰기지연 SQL 저장소에 보관된다.

-> DB에 반영 X

4. 트랜잭션 커밋 또는 flush

@Transactional

또는

entityManager.flush();

• 트랜잭션이 끝나는 순간 영속성 컨텍스트에 쌓여있던 SQL 실행.

flush는 쓰기 지연 SQL 저장소에 있는 SQL들을 DB로 전송하고 DB와 영속성 컨텍스 상태를 동기화함 -> rollback이 가능해짐

5. 조회 동작(1차 캐시)

entityManager.find(Member.class, id);

• 먼저 영속성 컨텍스트(1차 캐시) 확인
• 있으면 DB 조회 X
• 없으면 DB 조회 O

5. 변경 감지(Dirty Checking)

member.setName("park");

• 트랜잭션 커밋 시점에 JPA가 변경 여부 자동 감지
• UPDATE 쿼리 자동 생성

6. 삭제

entityManager.remove(member);

• 트랜잭션 종료 시 DELETE 실행

Repository

public interface MemberRepository extends JpaRepository<Member, Long>

내부적으로 EntityManager를 사용하고 데이터 접근 로직을 담당한다.

JpaRepository는 Spring Data JPA에서 제공하는 인터페이스로, EntityManager를 직접 사용하지 않고 CRUD 기능을 수해할 수 있게 해준다. 그 중에서 JpaRepository에 기본 메서드들이 내장되어 있어 Spring Data JPA가 런타임에 구현체를 자동 생성하여 데이터베이스 접근을 처리한다.

findAll()

List<Member> members = memberRepository.findAll();

• 해당 Entity 테이블의 모든 행 조회 == SELECT * FROM member;

FindById()

Optional<Member> member = memberRepository.findById(1L);

• PK 기준 조회
• 1차 캐시를 먼저확인 후 없으면 DB 조회

그 외에도 save(), count(), delete()등의 메서드가 내장되어있다.

이 문제는 두 정수 a, b가 주어지면 a와 b 사이에 있는 모든 정수의 합을 구하는 문제이다.

간단한 문제이지만 a가 b보다 무조건 크다고 생각하고 풀었다가 틀렸음;;

따라서 a와 b의 대소관계가 정해져 있지 않기 때문에 if를 사용하고 사이에 있는 정수의 합을 구해야하기 때문에 for문을 사용해야한다.

a < b이면 a부터 b까지 1씩 증가하며 더해야 하고 a >=b 이면 a부터 b까지 1씩 감소하며 더해야한다.

class Solution {
  public long solution(int a, int b) {
    long sum = 0;

    if(a < b){
      for (int i = a; i <= b; i++){
        sum += i;
      }
    }
    else{
      for (int i = a; i >= b; i--){
        sum += i;
      }
    }

    return sum;
  }
}

a == b가 같은 경우는 else에 들어간다. solution 메서드에서 두개의 정수 a와 b를 매개벼누로 받도록 정의되어 있으므로, main 메서드에서 해당메서드에 두 개인자를 전달해야 한다.

3 ~ 5까지 3 + 4 + 5 = 12가 나오는 것을 볼 수 있다.

이 문제는 어떤 정수 x가 하샤드 수가 되려면 x가 자기 자릿수의 합으로 나누어 떨어져야 합니다.

정수 x를 받아서 하샤드 수면 true 아니면 false를 반환하게 하는 문제입니다.

자릿수의 합을 구하기 위해 x % 10 -> 마지막 자릿수를 추출하고 x / 10 한 값을 더하여 answer 변수에 넣고 x는 원래 숫자를 보존하기 위해 sum 변수에 넣어두고 마지막에 sum % answer == 0이 되면 true 아니면 false를 반환하게 한다.

class Solution {
  public boolean solution(int x) {
    int answer = 0;
    int sum = x;
    while (x > 0){
      answer += x%10;
      x /= 10;
    }

    if (sum % answer == 0){
      return true;
    }
    return false;
  }
}

main 함수도 Solution 클래스 객체를 생성하고 solution 메서드가 boolean 반환타입으로 명시되어 있으므로 main 함수에서 참/거짓을 판단하는 boolean을 써야합니다. -> int로 쓰면 오류

public class Main{
  public static void main(String[] args) {
    Solution sol = new Solution();
    boolean result = sol.solution(11);
    System.out.println(result);
  }
}

11 -> 1 + 1 =2이다. 11 / 2을 하면 0이 아니므로 하샤드 수가 아님 -> false 반환

이 문제는 정수 n을 매개 변수로 입력받으면 각 자릿수를 큰 수부터 작은 순으로 정렬하여 값을 반환하는 문제이다.

이코드는 정수 -> 문자 -> 배열 -> 정렬 -> 다시 정수로 풀어야한다.

1. 정수를 문자열로 반환

• 정수 상태에서 자릿수로 바로 접근하기 위해 사용
• 문자열로 바꾸면 한글자씩 처리가 가능

2. 자릿수를 배열로 저장

• Collections.reverseOdrder()가 내림차순을 쓸 때 사용하는 것인데 Integer 타입에서만 사용이 가능함

3. 문자열를 숫자로 반환 s.charAt(i) -> 문자 '1', '8'에서 -'0'을 하면 ASCII 코드로 숫자로 반환됨

4.내림차순 정렬 ** 5. 숫자를 문자열로 다시 붙이기**

• 기존 값에 10을 곱해 자리를 왼쪽으로 밀고 현재 자릿수를 더해 새로운 정수를 만든다.

import java.util.Arrays;
import java.util.*;
import java.util.Collections;

class Solution {
  public long solution(long n) {
    String s = String.valueOf(n);
    Integer[] arr = new Integer[s.length()];

    for (int i = 0; i < s.length(); i++) {
      arr[i] = s.charAt(i) - '0';
    }

    Arrays.sort(arr, Collections.reverseOrder());

    long answer = 0;
    for (int j = 0; j < arr.length; j++) {
      answer = answer * 10 + arr[j];
    }

    return answer;
  }
}

정수를 문자열로 변환해서 배열에 저장한 뒤 내림차순으로 정렬하고 곱셈 연산을 이용해서 새로운 정수를 직접 재구성하면 된다.

public class Main {
  public static void main(String[] args) {
    Solution sol = new Solution();
    long n = 118372;
    long result = sol.solution(n);
    System.out.println(result);
  }
}

다른 사람 풀이

import java.util.*;

class Solution {
  public long solution(long n) {
    String s = String.valueOf(n);
    Integer[] arr = new Integer[s.length()];

    for (int i = 0; i < s.length(); i++) {
      arr[i] = s.charAt(i) - '0';
    }
    Arrays.sort(arr, Collections.reverseOrder());


    StringBuilder sb = new StringBuilder();
    for (int j = 0; j < arr.length; j++) {
      sb.append(arr[j]);
    }

    return Long.parseLong(sb.toString());
  }
}

StringBuilder는 문자열을 계속 이어 붙이기 위한 객체로 쓰이고 내부적으로 가변 문자열 구조를 가진다.

예) sb.append(8), sb.append(7) ~

-> "873211"

그리고 Long.parseLong(sb.toString());으로 문자열 형태를 정수형 Long으로 변환시켜 반환한다.

초기 구현 단계에서는 GET/api/memos 요청을 통해 전체 메모 목록을 조회하도록 구현되어 있었다.

초기 구현 단계에서 Memo 엔터티는 메모 테이터 구조를 정의하고 @Entity 어노테이션을 통해 DB테이블과 매핑되어 있었고 timestamped의 상속을 받아 생성/수정시간 등이 기록되어 있었다.

본 프로젝트는 메모 앱에서 간단 검색 기능을 추가하는 것이고 정렬이나 로직은 엔터티의 역할이 아니므로 Service Repository에서 처리해야한다.

MemoRequstDto는 클라이언트로부터 전달받는 데이터만을 담는 객체로 사용되었고 사용자의 입력값(usernmae,contents)를 엔티티로 전달하기 전 중간 매게체 역할을 하고 있었고 MemoResponseDto는 서버가 클라이언트에게 반환하는 데이터를 담는 객체로 메모 조회시 클라이언트에게 전달할 데이터를 정희하고 엔티티의 필요한 정보만 선택적으로 노출하는 역할을 하고 있었다.

이를 통해 엔티티를 외부에 직접 노출하지 않고, 요청과 응답에 필요한 데이터만을 전달하는 구조를 구성하여 유지보수성과 확장성을 확보하는 기반이 되었다.

메모 조회 동작 방식

• Controller에서 getMemos()메서드를 통해 서비스 호출하였습니다.
• Service에서 Repository의 메서드인 findAll()을 사용하였습니다.
• 데이터베이스에 저장된 메모를 정렬 조건 없이 그대로 조회

그럼 지금부터 검색기능을 구현해보자

MemoController

package com.meta.memo.controller;
import com.meta.memo.dto.MemoRequestDto;
import com.meta.memo.dto.MemoResponseDto;
import com.meta.memo.service.MemoService;
import org.springframework.web.bind.annotation.*;
import java.util.List;


@RestController
@RequestMapping("api/memos")

public class MemoController {
    // 멤버 변수 선언
    private final MemoService memoService;

    //생성자 주입(DI)
    public MemoController(MemoService memoService){
        this.memoService =  memoService;
    }

    @PostMapping()
    public MemoResponseDto createMemo(@RequestBody MemoRequestDto memoRequestDto) {
        return memoService.createMemo(memoRequestDto);
    }

    @GetMapping()
    public List<MemoResponseDto> getMemos(){
        return memoService.getMemos();
    }

    @PutMapping("{id}")
    public Long updateMemo(@PathVariable Long id, @RequestBody MemoRequestDto memoRequestDto) {
        return memoService.updateMemo(id, memoRequestDto);
    }

    @DeleteMapping("{id}")
    public Long deleteMemo(@PathVariable Long id){
        return memoService.deleteMemo(id);
    }
}

MemoController는 현재 메모 생성, 조회, 수정, 삭제에 대한 Rest API를 제공하고 있고 클라이언트의 요청을 받아 DTO 형태로 전달받아 서비스 계층에 처리결과를 JSON 형태로 반환한다. 여기서 특정 키워드가 포함된 메모를 조회하는 API를 구현해야한다.

API 구현 조건

http://localhost:8080/api/memos/contents?keyword=

• 메서드명은 getMemosByKeyword

@GetMapping()
    public List<MemoResponseDto> getMemosByKeyword(@RequestParam String keyword){
        return memoService.getMemosByKeyword(keyword);
    }

해당 메서드는 메모 내용(/contents)에 특정 키워드가 포함된 메모 목록을 조회하는 기능을 수행한다. 클라이언트는 Query String 방식으로 검색할 키워드를 전달하고 JSON형태의 메모 목록으로 반환된다.

@RequestParam -URL에 포함된 keyword 값을 파라미터로 바인딩하고 별도의 RequestBody 없이 조회 목적의 요청을 한다.

return memoService로 검색 조건 keyword만 서비스 계층으로 전달된다 참고로 memo.java에 @Getter가 있기 때문에 get~가 사용이 가능함

MemoService

컨트롤러 계층에서는 위와 같은 키워드 기반 조회 API를 추가하였지만 해당 API를 호출했을 때 서비스 계층에 실제 실행될 메서드가 존재하지 않고 구현이 되어있지 않아 정상적으로 응답을 반환할 수 없다.

그래서 서비스 계층에 getMemosByKeyword를 구현하였다.

  public List<MemoResponseDto> getMemosByKeyword(String keyword){
    List<MemoResponseDto> memoResponseDtoList = memoRepository.findAll().stream()
        .map(MemoResponseDto::new)
        .toList();
    return memoResponseDtoList;
  }

** 해당 메서드의 역할**

• MemoRepository.findAll()을 통해 전체 메모 데이터를 조회 -> 참고로 findAll()은 JpaRepository를 MemoRepository에서 상속받고 있기 때문에 사용이 가능하다.
• 각 엔터티를 MemoResponseDto로 매핑
• 조회된 Memo엔터티를 스트림으로 변환
• 변환된 결과를 리스트로 반환

MemoRepository

서비스 계층에서는 위와 같은 방식으로 findAll()로 임시 구현을 하였는데 이 방식은 문제가 생긴다. 일단 키워드 검색 조건이 데이터베이스에 반영되지 않고 메서드 이름은 검색이지만 실제로 작동은 되지 않는다.

그래서 검색과 정렬을 데이터베이스에서 처리하도록 MemoRepository에 쿼리 메서드를 추가하였다.

public interface MemoRepository extends JpaRepository<Memo, Long> {
    List<Memo> findAllByContentsContainingOrderByModifiedAtDesc(String keyword);
}

메서드 구성과 의미

• findAllBy : 조건에 맞는 모든 데이터를 조회한다.

• contents : Memo 엔터티의 contents 내용

• Containing : Keyword가 포함된 데이터

• OrderByModifedAtDesc : 수정 시간 기준 내림차순 정렬

새로운 쿼리 메서드를 정의 했기 때문에 서비스 계층에 있는 List도 다시 작성해야한다.

public List<MemoResponseDto> getMemosByKeyword(String keyword){
    List<MemoResponseDto> memoResponseDtoList = memoRepository.<span style = "color : red">findAllByContentsContainingOrderByModifiedAtDesc(keyword)</span>
        .stream()
        .map(MemoResponseDto::new)
        .toList();
    return memoResponseDtoList;
  }

findAll()을 바꿔주어야한다. findAllByContentsContainingOrderByModifiedAtDesc(keyword)

하지만 실제로 코드를 반영해보면 웹에서는 내림차순 정렬이 되지 않는다. 검색 기능(getMemosByKeyword)은 수정 시간 기준 내림차순 정렬이 포함된 Query Method를 적용했으나, 실제 웹 화면에서는 전체 메모 목록을 조회하는 /api/memos API만 호출하고 있었기 때문에 검색 API의 정렬 결과가 화면에 반영되지 않았다. 이후 전체 조회(getMemos)에도 수정 시간 기준 내림차순 Query Method를 별도로 적용하면서 웹 화면에 최신순 정렬이 정상적으로 반영되었다.

public interface MemoRepository extends JpaRepository<Memo, Long> {
    List<Memo> findAllByContentsContainingOrderByModifiedAtDesc(String keyword);
    List<Memo> findAllByOrderByModifiedAtDesc();
}

MemoRepository에 새로운 메서드를 추가했으니 서비스 계층에서 getMemos 메서드에도 쿼리 메서드를 적용해야한다.

  public List<MemoResponseDto> getMemos() {
    List<MemoResponseDto> memoResponseDtoList = memoRepository.findAllByOrderByModifiedAtDesc().stream()
        .map(MemoResponseDto::new).toList();
    return memoResponseDtoList;
  }

코드를 실행하면 코드가 내림차순으로 정렬되는 것을 볼 수 있다. Postman에서도 실행해보자.

Postman과 구글 크롭 url에 조건에 있는 해당 url을 넣었을 때 Json 텍스트를 반환하고 200 OK가 뜨는 것을 볼 수 있다.

HTML 반영

html은 시간 부족으로 기존에서 크게 건들지는 못했다.

1. Header 영역 구성

Memo 페이지의 메인 타이틀 header부분에 변화를 주었다. 먼저 좌우에 이미지를 배치하여 무슨 내용을 메모에 기록하면 되는지 주제를 주었고 이미지는 position : abolute를 기반으로 간단히 배치하였다.

2. 검색 영역 구성

사용자가 특정 키워드를 입력해 메모를 검색할 수 있도록 검색 영역을 추가하였다. 검색 입력창과 버튼을 분리하여 기능별 역할이 수행하도록 구생하였다. 검색 버튼은 입력한 키워드를 기반으로 서버에 검색 요청을 보내고, 전체보기는 기존 전체 메모 목록을 다시 불러오는 역할을 한다.

// 메모 검색
      function searchMemos() {
          const keyword = $('#keyword').val().trim();

          if (keyword === '') {
              alert('검색어를 입력해주세요');
              return;
          }

          // 1) 기존 목록 비우기 (검색 결과로 덮어쓰기)
          $('#cards-box').empty();

          // 2) 검색 API 호출
          $.ajax({
              type: 'GET',
              url: `/api/memos/contents?keyword=${encodeURIComponent(keyword)}`,
              success: function (response) {
                  // 3) 검색 결과 렌더링 (기존 addHTML 재사용)
                  for (let i = 0; i < response.length; i++) {
                      const message = response[i];
                      addHTML(message['id'], message['username'], message['contents'], message['modifiedAt']);
                  }

                  // 검색 결과 없을 때(선택)
                  if (response.length === 0) {
                      $('#cards-box').append(`<div style="padding:15px; color:#666;">검색 결과가 없습니다.</div>`);
                  }
              },
              error: function () {
                  alert('검색 요청 실패: 서버 실행/URL을 확인하세요');
              }
          });
      }

검색 버튼을 클릭할 경우 seachMemos()함수가 실행되고 해당 함수는 Ajax를 통해 GET /api/memos/contents?keyword=? 형태로 API에 요청을 보내고 서버는 contents에 키워드가 포함된 메모를 조회하여 JSON 형태로 응답한다. 응답으로 받은 결과는 기존 메모 목록을 비우고 검색결과를 화면에 랜더링한다.

새로고침은 getMessages() 함수를 재사용하여 검색결과에서 전체 메모 목록으로 돌아갈 수 있도록하게 한다.

3. 올라가는 버튼 구현

마지막으로 간단하게 전에 썼던 누르면 위로 올라가는 버튼 구현

회고록

• MemoController에서 처음에 getMemosByKeyword 함수 기능을 넣으라고 했을 때 getMemos 전체 조회를 없애고 기능을 넣었다가 웹사이트가 안열려서 코드를 복구하고 새로 특정 키워드가 포함된 APi 메모함수를 만들었음

• 이후 서비스 계층과 MemoRepository까지 잘 작성하였으나 쿼리 메서드 이름을 찾아보고 입력했지만 실행에 오류가 생겨서 gpt에게 쿼리 메서드 이름을 어떻게 작성하면 되는지 물어보고 작성함.

• 이후 postman에 실행할 때 json 텍스트를 불러오지 못함 -> String keyword를 작성안했었음.

• 쿼리 메서드를 잘 작성했지만 실제 웹사이트에서는 반영이 되지 않음 -> Gpt에게 물어보니 getMemosByKeyword가 수정 시간 기준 내림차순 정렬은 반영이 되었으나 실제 웹사이트에서는 전체 메모 목록을 조회하는 api/memos를 호출하고 있었기 때문에 getMemos로 반영이 되어 내림차순 정렬이 되지 않고 있었다. 그래서 새로운 쿼리 메서드를 추가하였다.

• html을 구성하는데는 시간이 좀 부족해서 디자인적으로 많이 아쉬웠다. 기존 html에 사진밖에 넣지 못했다.

• 검색기능을 구현하면서 기존목록을 비우는 과정을 생각하지는 못했고 키워드를 불러와야겠다는 생각만했었다. 그리고 js는 아직 잘 사용을 못한다고 생각했다.

객체지향 언어의 객체와 관계형 데이터베이스의 테이블을 자동으로 매핑해주는 기술을 말합니다.

예를 들어, 데이터베이스에 'age'와 'name'이라는 컬럼이 있고, 그 값으로 각각 20, 홍길동이 저장되어 있다고 가정하면 이런 데이터를 자바에서 어떻게 해야할까?

보통 우리는 SQL이라는 언어를 사용해서 데이터베이스에서 데이터를 추출한다. 원래라면 SELECT * From user와 같은 쿼리를 직접 써서 데이터를 가져와야 하지만 데이터 양이 방대할 수 있고 코드랑 sql을 따로 관리해야 해서 헷갈릴 수가 있다.

쉽게 말해 SQL에 대한 지식이 깊지 않아도 기본적인 CRUD는 자바 코드로만 데이터베이스에 접근해서 원하는 데이터만 가져올 수 있습니다. -> 자바 코드 속의 객체와 데이터 베이스의 테이블을 연결해주는 다리 역할을 해주는 것이 ORM이다.

ORM의 장점과 단점

장점

• SQL을 직접 작성하지 않고, 사용하는 언어로 데이터베이스에 접근할 수 있다.
• 객체지향적으로 코드를 작성할 수 있기 때문에 비즈니스 로직에만 집중할 수 있다.
• 데이터베이스 시스템이 추상화되어 있어, 예를들어 MySQL에서 postgreSQL로 전환할 때 추가 자작업이 거의 필요없다. 즉 데이터베이스 시스템에 대한 종속성이 줄어든다.
• 매핑하는 정보가 명확해지기 때문에 ERD에 대한 의존도를 낮출 수 있고, 유지보수 시 유리하다.

단점

• 프로젝트가 복잡해질수록 ORM의 사용 난이도 높아질 수 있다.
• 복잡하고 성능이 중요한 쿼리는 ORM으로 해결하기 어려운 경유가 있다.

JPA란

자바 객체를 데이터베이스 테이블과 매핑해서 DB작업을 쉽게 해주는 자바에서 사용하는 ORM기술 표준이다.

쉽게 말하면 SQL을 직접 많이 안 써도 자바 객체만으로 DB에 저장,조회,수정,삭제(CRUD)를 할 수 있게 해주는 기술

JPA의 장점과 단점

장점

• 기본 CRUD를 SQL없이 처리가 가능해 반복적인 SQL작성이 줄어들어 개발 속도가 빨라지고 생산성이 매우 높아진다.

• 테이블이 아니라 자바 객체 중심으로 개발 되고객체 간 관계를 코드로 표현해 비즈니스 로직이 명확해지고 코드 가독성이 좋아져 객체적인 개발이 가능해진다.

• DB가 바뀌어도 코드 수정이 거의 없고 특정 DB에 종속되지 않는 구조를 가져 데이터베이스 독립성을 가진다.

• 테이블 구조 변경시 SQL 전부를 수정할 필요가 없고 엔티티만 수정하면 자동 반영되어 유지보수에 용이하다.

• 1차 캐시, 변경 감지, 쓰기 지연 개발자가 신경 쓰지 않아도 성능을 어느 정도 보장해 자동 최적화가 가능하다.

단점

• 영속성 컨텍스트, 트랜잭션, 지연로딩/즉시 로딩등의 개념을 이해하지 못하면 오류 원인 파악이 어렵다.

• 복잡한 통계, 다중 조인 쿼리 등 복잡한 쿼리에 한계가 있다.

• SQL이 자동 생성되기 때문에 어떤 쿼리가 나가는지 모를 수 있고 N + 1 문제 등 성능 튜닝이 어렵다.

• 대량 배치 처리와 SQL 최적화가 매우 중요한 경우 등 모든 상황에 적합하지 않을 수 있다.

JPA의 핵심 개념

1. Entity(엔터티)

@Entity
public class Memo {
    @Id
    @GeneratedValue
    private Long id;
}

자바 클래스가 DB테이블과 매핑된다. @Entity는 DB랑 연결이 된다.

2.EntityManager

entityManager.persist(memo);

JPA의 핵심 관리자이고 엔터티를 저장,조회,삭제하는 역할이 있다.

3. Persistence Context(영속성 컨텍스트)

엔티티를 관리하는 1차 캐시 공간

특징 :

• 같은 ID조회 시 DB재조회를 하지 않는다.
• 변경 감지가 자동으로 된다.
• 트랜잭션이 끝나면 DB에 반영된다.

4. Repository(Spring Data JPA)

public interface MemoRepository extends JpaRepository<Memo, Long> {
}

기본 CRUD를 자동 제공하고 메서드 이름만으로 쿼리 생성이 가능하다.

5. 트랜잭션(@Transactional)

@Transactional
public void updateMemo(...) { }

작업 단위를 보장하고 중간에 에러가 나면 자동으로 롤백하는 기능이 있다.

JPA는 개발 생산성과 유지보수성을 크게 향상시키는 ORM 기술이지만, 내부 동작에 대한 이해 없이 사용할 경우 성능 문제를 유발할 수 있다. 따라서 JPA의 장점을 살리기 위해서는 트랜잭션과 영속성 컨텍스트에 대한 충분한 이해가 필요하다.

본 개발자도 JPA 내부 동작을 구현하다가 코드가 꼬여서 성능문제를 유발했음..

싱글톤 패턴은 특정 클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴이다. 이 패턴은 주로 전역 상태를 관리하거나 자원의 중복을 방지하고 싶을 때 사용됩니다.

예를 들어 네트워크 매니저, 데이터 베이스 연결 객체 등은 애플리케이션 전체에서 하나의 인스턴스로만 존재해야합니다.

싱글톤 패턴의 특징

• 인스턴스의 유일성 보장

• 클래스 인스턴스가 하나만 존재합니다.

• 전역 접근

• 프로그램 어디서나 동일한 인스턴스를 접근할 수 있습니다.

• 지연 초기화

• 필요할 때까지 인스턴스를 생성하지 않아 메모리 사용을 최적화하 수 있습니다.

싱글톤 패턴을 언제 사용할까?

• 전역 상태를 관리할 때

• 사용자의 로그인 상태나 애플리케이션 설정 등 앱 전체에서 일관된 상태를 관리해야 할 때

• 공유 자원을 관리할 때

• 네트워크 연결, 파일 입출력, 데이터베이스 접근 등 여러 클래스에서 동시에 접근하는 자원을 중앙에서 관리하고 싶을 때

• 비용이 큰 객체의 중복 생성을 방지할 때

• 초기화 비용이 크거나 메모리 사용량이 큰 객체를 여러번 생성하는 것을 방지하고 싶을 때

싱글톤 패턴의 사용방법

1. 생성자 private

• 외부에서 new로 객체 생성을 못하게 막는다.

2. static 변수로 인스턴스 하나만 생성

• 클래스 내부에 자기 자신 타입의 객체를 하나만 둠

3. static 메서드로 그 인스턴스 반환

• 어디서든 접근이 가능하다.

public class Singleton {

    // 1. 유일한 인스턴스
    private static Singleton instance = new Singleton();

    // 2. 생성자 private
    private Singleton() {}

    // 3. 인스턴스 반환 메서드
    public static Singleton getInstance() {
        return instance;
    }
}

Singleton s1 = Singleton.getInstance();
Singleton s2 = Singleton.getInstance();

System.out.println(s1 == s2); // true (같은 객체)

싱글톤 패턴의 주의사항

싱글톤 패턴은 편리하지만 잘못 사용하면 유지보수와 테스트면에서 어려움을 초래할 수 있습니다.

• 의존성 주입의 어려움

• 싱글톤 객체는 전역적으로 사용되기 때문에 테스트 시에 모킹을 사용하기 어렵습니다.

• 과도한 전역 상태 사용

• 전역적으로 접근 가능한 객체가 많아지면 코드의 의존성이 높아지고 버그 발생 가능성이 증가합니다.

• 멀티스레드 환경에서의 안정성

• 스레드 안전한 싱글톤 구현이 필요할 수 있습니다. static let은 기본적으로 스레드 안전성을 제공하므로 대부분의 경우 안전하지만 추가적인 고려가 필요할 수 있습니다.

DI(Dependency injection)

DI를 이해하기 위해 먼저 Dependency부터 알아보자.

Dependency, 한국어로 종속성, 의존성은 하나의 객체가 다른 객체의 기능에 의존하는 관레를 말합니다. DI에는 직접 객체를 생성해서 자신이 사용하는 일체형 관계와 외부에서 생성한 객체를 사용하는 결합형 관계가 있다.

1. Constructor Injection : 직접 객체 생성

class B {
    // B 클래스의 내용
}

class A {
    private B b;

    public A() {
        b = new B(); // A의 생성자에서 B 객체를 직접 생성
    }
}

일체형 관계에서는 class A와 Class B가 강하게 결합되어 있음을 의미합니다. 이 경우 class B의 구현 변경이 필요할 때 class A도 함께 수정해야 하는 단점을 갖게 됩니다.

2.Setter Injection : 외부에서 객체 주입

class B {
    // B 클래스의 내용
}

class A {
    private B b;

    public A() {
        // A 생성자에서는 B 객체를 생성하지 않습니다.
    }

    public void setB(B b) {
        this.b = b; // 세터를 통한 의존성 주입
    }
}

// 사용 예
class Main {
    public static void main(String[] args) {
        B b = new B(); // B 객체를 외부에서 생성
        A a = new A(); // A 객체 생성
        a.setB(b);     // Setter를 통한 A 객체에 B 객체 주입
    }
}

결합형 관계에서는 class B의 인스턴스를 외부에서 생성한 후 class A에 제공합니다. 이렇게 다른 클래스에 대한 의존성을 외부에서 주입 바든 방식을 바로 의존성 주입이라고 하고 이 같은 경우 class B를 다른 구현으로 쉽게 바꿀 수 있으며, class A를 변경할 필요가 없는 장점을 얻으며 테스트도 용이하게 됩니다.

스프링이 DI를 해주는 방식

개발자가 Bean으로 ICO 컨테이너 등록한 객체를 쓰는 방식이다.

IoC(Inversion of control)

IoC는 영어 그대로 제어의 역전이라는 뜻이다. 프로그램의 흐름을 개발자가 제어하지 않고, 프로그램이나 프레임웍이 직접 제어를 한다는 말이다. 컴포넌트의 의존 관계 결정, 객체의 생명 주기와 같은 일을 대신 수행해준다.

사용자의 요청이 들어오면, 요청에 알맞은 Bean을 생성해서 필요한 일을 하도록 시킨다. 해당 Bean이 할 일을 마치면 Bean을 삭제해준다. 하지만 이런 객체의 생성과 소멸이 어떻게 이루어지는지 알 필요가 없다. 프로그래머가 직접 제어 할 필요가 없이 프레임웤이 직접 제어해주기 때문이다. 이것이 IoC 제어의 역전이다.

컨테이너?

컨테이너는 IoC컨테이너라고도 불린다. 컨테이너는 코드의 처리 과정을 위임 받은 독립적인 존재이다.

적절한 설정을 해주면, 프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 관리한다.

객체 및 이들간의 관계, 상호작용 등을 기반으로 프로그램을 설계하는 방법론 및 프로그래밍 패러다임의 일종으로, 넓게는 명령형 프로그래밍에 속한다.

프로그램을 단순히 데이터와 처리 방법으로 나누는것이 아니라, 프로그램을 수많은 객체라는 기본 단위로 나누고 이들의 상호 작용으로 서술하는 방식이다. 여기서의 객체란 메소드 변수를 가지며 특정 역할을 수행하도록 인간이 정의한 추상적인 개념이다.

객체지향의 3요소

1. 객체(Object)

• 데이터(속성) + 기능(메서드)를 하나로 묶은 단위 예) 학생 객체 -> 이름, 학번 + 수강신청(), 성적조회()

2. 클래스(Class)

• 객체를 만들기 위한 설계도 class Student{...}

3. 메시지(Message)

• 객체 간 메서드 호출(요청) student.getScore()

객체지향의 4대 특징

캡슐화

-프로그램 내에서 같은 기능을 목적으로 작성된 코드를 모아서 다른 곳(클래스)에서 안보이게 숨기는 것 클래스에 정의된 속성(Attribue)는 숨기고 (private), 객체가 수행할 기능은 공개(Public)하는 것을 의미한다.

상속

-클래스 사이에 부모와 자식 클래스가 존재할 수 있다는 뜻이다. 자식 클래스는 상속받는 부모 클래스의 속성(변수) 및 기능(메소드, 함수)를 물려받는 것을 의미한다.

추상화

-객체의 공통적인 특징과 핵심 기능만을 뽑아내고, 불필요한 세부 구현을 숨기는 것을 의미한다. 이를 통해 구현에 대한 의존도를 낮추고 코드의 유지보수성과 확장성을 향상시킬 수 있다.

다형성

Overriding과 Overloading으로 나뉨 https://velog.io/@minjae-yun/Overload-VS-Override 자세한 설명은 위 사이트에서..

5원칙 SOLID

S -> SRP(단일 책임의 원칙: Single Responsibility Principle)

• 하나의 클래스는 하나의 목적을 위해서 생성되며, 클래스가 제공하는 모든 서비스는 하나의 책임을 수행하는 데 집중되어 있어야 한다는 원칙입니다.

• 이는 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 함을 의미합니다.

• SRP 원리를 적용하면 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있습니다.

• 코드의 가독성 및 유지보수에 있어서 유리합니다.

• 객체 지향 프로그래밍의 5원칙 중 나머지 4원칙의 기초가 되는 원칙이다.

O -> OCP(개방폐쇄의 원칙: Open Close Principle)

• 소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 원리이다.

• 이것은 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화 해야 한다는 의미로, 요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 쉽게 확장해서 재사용할 수 있어야 한다는 뜻이다.

• 재사용 코드를 만드는 기반이며, OCP를 가능하게 하는 중요 메커니즘은 추상화와 다형성.

L -> LSP(리스코브 치환의 워칙: The Liskov Substitution)

• 자식 클래스(서브 타입)는 언제나 자신의 부모 클래스(기반 타입)를 대체할 수 있다. 즉, 부모 클래스가 들어갈 자리에 자식 클래스를 넣어도 계획대로 잘 작동해야 한다는 것.

• 상속의 본질인 원리

• 이를 지키지 않을 경우 부모 클래스 본래의 의미가 변해서 is a 관계가 무너짐

I -> ISP(인터페이스 분리의 원칙: Interface Segregation Principle)

• 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리.

• 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소환의 인터페이스만을 사용해야한다.

D -> DIP(의존성역전의 워칙: Dependency Inversion Principle)

• 구조적 디자인에서 발생하던 하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구하는 위치관계를 끊는 의미의역전입니다.

• 실제 사용 관계는 바뀌지 않으며, 추상을 매개로 메시지를 주고 받음으로써 관계를 최대한 느슨하게 만드는 원칙이다.