| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
- spring boot
- SQL
- http
- DB
- DL
- docker
- java
- VUE
- AI
- frontend
- Studying
- CS
- Android
- springboot
- cloud
- TypeScript
- react
- OS
- Python
- Design
- Spring
- Database
- Network
- architecture
- 배포
- Kotlin
- Algorithm
- blockchain
- inflearn
- GCP
- Today
- Total
목록java (66)
소소한 지식 저장소
1. 스프링 컨테이너 생성// Spring Container 생성ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);ApplicationContext를 스프링 컨테이너라고 하며, 이는 인터페이스임.AnnotationConfigApplicationContext는 이 인터페이스의 구현체 중 하나로, 자바 설정 클래스(AppConfig.class)를 기반으로 컨테이너를 생성합니다.즉, 선언할 때, public class AnnotationConfigApplicationContext implements ApplicationContext 임컨테이너가 생성될 때 내부에는 비어있는 스프링 빈 저장소..
스프링 전환의 핵심 로직 요약1. 설정 정보의 변화 (AppConfig)기존: 단순한 자바 클래스. 개발자가 직접 메서드를 호출해 객체를 생성함.스프링: @Configuration이 붙어 스프링의 **'설정 지도'**가 됨. 메서드 위의 @Bean은 "이 객체를 관리해줘!"라는 등록 마크임.2. 관리 주체의 변화 (IoC 컨테이너 등장)ApplicationContext: 우리가 만든 AppConfig를 읽어서 객체들을 담아두는 **'거대한 창고'**입니다.스프링 빈(Bean): 창고에 보관된 객체들입니다. 기본적으로 메서드 이름(예: memberService)이 이름표가 됩니다.package com.example.spring_study.spring_study;import com.example.spring..
1. 결정적인 차이: 제어의 흐름 (Inversion of Control)라이브러리: '나'가 주체가 됩니다. 내가 필요할 때 라이브러리를 직접 호출해서 사용합니다. (내가 도구를 골라 쓰는 것) - 제어의 흐름을 개발자가 가짐프레임워크: '프레임워크'가 주체가 됩니다. 프레임워크가 정해준 규칙대로 코드를 작성하면, 프레임워크가 내 코드를 대신 실행 (틀 안에 내가 들어가는 것) - 제어의 흐름을 프레임워크가 가짐비유로 이해하기라이브러리는 '연장'. 내가 집을 짓다가 망치가 필요하면 망치를 꺼내 쓰고, 드릴이 필요하면 드릴을 꺼내 씁니다. 언제 어떤 도구를 쓸지는 전적으로 내가 결정합니다.프레임워크는 '모델하우스'. 이미 거실, 안방, 주방의 위치(틀)가 정해져 있습니다. 나는 그 안에서 벽지의 색깔을 ..
1. Before: 다형성만 사용 (OCP, DIP 위반)인터페이스를 썼지만, 서비스 내부에서 직접 구현체를 선택하고 있는 상태입니다.package com.example.spring_study.spring_study.member;public class MemberSeviceImpl implements MemberSevice{ private final MemberRepository memberRepository = new MemoryMemberRepository(); @Override public void join(Member member) { memberRepository.save(member); } @Override public Member findMembe..
1. SRP: 단일 책임 원칙 (Single Responsibility Principle)핵심: 한 클래스는 하나의 책임만 가져야 한다.판단 기준: 가장 중요한 기준은 변경이다. 변경이 발생했을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것이다.예시: UI 변경, 객체의 생성과 사용을 분리하는 것 등.2. OCP: 개방-폐쇄 원칙 (Open/Closed Principle)핵심: 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀(변경하지 않아도 된다) 있어야 한다.방법: 다형성을 활용하여 인터페이스를 구현한 새로운 클래스를 만들어 기능을 확장한다.문제점: MemberService가 구현 클래스를 직접 선택하는 경우(예: new MemoryMemberRepository()), 구현 객체 변경 시 ..
1. AOP가 필요한 상황 (Before AOP)기존의 MemberService는 아래와 같이 핵심 로직보다 시간 측정 로직이 더 비대해진 상태였습니다.// MemberService의 기존 모습 (핵심 로직과 공통 로직의 혼재)public Long join(Member member) { long start = System.currentTimeMillis(); // 공통 관심 사항 try { validateDuplicateMember(member); // 핵심 관심 사항 memberRepository.save(member); // 핵심 관심 사항 return member.getId(); } finally { long fi..
기존에는 리포지토리를 만들 때 EntityManager를 주입받고, JPQL을 직접 작성하고, 구현 클래스를 만들어야 했습니다. 하지만 스프링 데이터 JPA를 사용하면 인터페이스 선언만으로 모든 게 끝납니다.1. 핵심 구조: JpaRepository 상속가장 먼저 해야 할 일은 JpaRepository를 상속받는 인터페이스를 만드는 것입니다.package com.example.spring_study.domain.repository;import com.example.spring_study.domain.Member;import org.springframework.data.jpa.repository.JpaRepository;import java.util.Optional;public interface Sprin..
1. 컴포넌트 스캔과 자동 의존관계 설정스프링이 애플리케이션 실행 시 @Component와 관련된 어노테이션을 찾아 자동으로 빈(Bean)을 생성하고 연결하는 방식입니다.핵심 어노테이션@Component: 스프링 빈으로 자동 등록됩니다.@Controller, @Service, @Repository: 내부적으로 @Component를 포함하고 있어 스캔 대상이 됩니다.@Autowired: 스프링 컨테이너에서 연관된 객체를 찾아 주입해 줍니다. (DI: Dependency Injection)코드 예시package com.example.spring_study.domain.controller;import com.example.spring_study.domain.service.MemberService;import ..
1. 서두: 성능 최적화를 위한 아키텍처 설계 상황현재 프로젝트의 성능을 극대화하기 위해 Full-Async 지향 구조를 설계했습니다.WebClient: FastAPI와의 외부 통신 비동기화.Reactive Redis: Upstash 캐시 접근 비동기화.Postgres (JPA): 유일한 동기(Blocking) 구간인 DB 접근을 스케줄러 분리를 통해 해결.2. 전략: 스케줄러 분리와 자원 동기화Postgres는 현재 JPA(동기) 방식을 사용하므로, 메인 비동기 일꾼(Event Loop)이 DB 작업 때문에 멈추는 것을 방지하기 위해 **boundedElastic**이라는 별도의 주차장(스레드 풀)을 할당했습니다.🔧 설정 1: 환경 변수 (.env 또는 application.properties)DB ..
1. 배경: 데이터의 '개수'가 아닌 '흐름'기존의 List나 User 객체는 데이터를 이미 다 가져온 '결과물'입니다. 반면 WebClient에서 사용하는 Mono와 Flux는 데이터가 도착할 것이라는 **'약속(Publisher)'**입니다. (데이터가 1개일지, 여러 개일지에 따라 적절한 그릇을 선택)2. Mono (0 ~ 1개의 데이터)*"단 한 번의 응답"**이 필요한 모든 곳에 사용합니다. 주로 상세 조회, 생성, 수정, 삭제 결과에 쓰입니다.[실제 코드 예시: 단일 사용자 정보 조회]파이썬 서버나 DB에서 특정 유저 한 명의 정보를 가져올 때의 전형적인 패턴입니다.public Mono getUserDetail(Long userId) { return webClient.get() ..
