기회는 준비된 자에게

오늘 한 일- 스프링 강의 수강- Optional 객체 공부- 영어 공부배운 것- 스프링의 의존관계 주입 방식에는 생성자 주입, 수정자 주입, 필드 주입, 일반 메서드 주입이 있다.- @Autowired는 기본적으로 필수 주입이며, required = false를 사용하면 선택 주입으로 처리할 수 있다.- @Nullable, Optional를 통해 주입할 Bean이 없는 경우도 처리할 수 있다.- Optional는 값이 있을 수도 없을 수도 있는 상황을 표현하는 래퍼 객체이다.

오늘 한 일- 스프링 강의 수강- LeetCode 3Sums 문제 정리 [Link]- 카프카 챌린지 4부 라이브 참여 (22:00 ~ 23:30)- 영어 공부- 체력 운동배운 것- 스프링 컴포넌트 스캔과 의존관계 자동 주입

이번에 정리할 문제는 LeetCode 15번 3Sum이다. 정수 배열 nums가 주어졌을 때, 서로 다른 세 인덱스 i, j, k를 골라 nums[i] + nums[j] + nums[k] = 0이 되는 모든 트리플렛을 찾아야 한다.이 문제에서 중요한 조건은 두 가지다. 세 인덱스가 서로 달라야 하고, 결과에 중복된 트리플렛이 포함되면 안 된다.문제정수 배열 nums가 주어질 때, 다음 조건을 만족하는 모든 트리플렛을 반환해야 한다.i, j, k는 서로 다른 인덱스여야 한다.nums[i] + nums[j] + nums[k] = 0이어야 한다.중복된 트리플렛은 결과에 포함하면 안 된다.제약 사항은 다음과 같다.3 접근브루트 포스로 생각해보기가장 단순한 방법은 세 개의 인덱스를 모두 직접 고르는 것이다.for..

오늘 한 일- 스프링 강의 수강- 카프카 Producer와 Record 정리 [Link]배운 것- @Configuration이 붙은 설정 클래스는 Spring이 CGLIB을 사용해 프록시 클래스로 관리한다.- 이를 통해 @Bean 메서드가 직접 호출되더라도 새 객체를 만들지 않고, Spring 컨테이너에 등록된 싱글톤 빈을 반환하도록 보장한다.- 즉, @Configuration은 설정 클래스 내부의 @Bean 호출에서도 싱글톤이 깨지지 않도록 도와준다.

애플리케이션에서 발생한 이벤트가 Kafka Broker에 저장되기까지는 Producer 내부의 여러 단계를 거친다.Producer는 Kafka에 이벤트를 적재하는 역할을 하지만, send()를 호출한다고 해서 Record가 곧바로 Broker로 전송되는 것은 아니다. 내부적으로는 직렬화, 파티션 결정, 배치 누적, 전송 요청 생성 과정을 거친다.이 글에서는 이벤트가 Record로 만들어진 뒤 Producer 내부에서 어떤 단계를 거쳐 Kafka Broker에 저장되는지 흐름 중심으로 살펴본다. 이벤트는 Record로 변환되어 전송된다애플리케이션에서 발생한 이벤트가 그대로 Kafka에 저장되는 것은 아니다. Producer는 Kafka에 보낼 데이터를 Record 형태로 만들어 전송한다.Record에는 이..

오늘 한 일- LeetCode 스터디 코드 리뷰 및 복습- 스프링 강의 수강배운 것- XML 기반 스프링 빈 설정GenericXmlApplicationContext를 사용해 XML 파일로 스프링 빈을 설정하는 방법을 학습했다.스프링 컨테이너는 설정 정보 자체가 자바 코드인지 XML인지에 직접 의존하지 않고, 최종적으로 생성된 BeanDefinition을 기반으로 빈을 관리한다.즉, 설정 정보를 어떤 방식으로 작성하더라도 스프링 컨테이너는 BeanDefinition이라는 공통된 메타 정보를 통해 빈을 생성하고 관리한다는 것을 이해했다.- 싱글톤 컨테이너싱글톤 패턴의 개념과 단점을 학습했다.직접 싱글톤 패턴을 구현하면 구현 코드가 필요하고, 구체 클래스에 의존하기 쉬우며, 테스트가 어려워지는 등의 단점이 있..

오늘 한 일- 데이터베이스 강의 수강- 고객 ERP 트러블 슈팅 주제로 블로그 글 작성 (Link) 배운 것- 동적 설계에서 EAV 모델과 JSON 설계 방식을 학습했고, 각각의 장단점을 비교하면서 학습을 진행하였다.

고객/계약 데이터를 관리하는 고객사 내부 ERP를 약 1년간 개발 및 유지보수하고 있었습니다. 이 시스템은 여러 지점에서 입력한 고객 계약 데이터를 운영자가 승인하고, 이후 계약/결제/입금 관련 업무를 관리하는 백오피스 형태의 웹 애플리케이션이었습니다. 문제가 발생한 기능은 승인 완료된 고객 데이터를 조건에 맞게 엑셀로 내보내는 기능이었습니다. 초기에는 데이터 규모가 작아 문제가 없었지만, 운영 기간이 길어지면서 고객 데이터가 수천 건까지 쌓였고, 전체 기간·전체 고객을 대상으로 엑셀 내보내기를 실행했을 때 502 응답이 발생했습니다. 이번 글에서는 대량 엑셀 내보내기에서 서버 메모리 피크가 커진 원인과, 기존 다운로드 경험을 유지하면서 이를 분할 조회 방식으로 개선한 과정을 정리합니다.(NodeJS 와..