묻고 답해요
164만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
강의를 들으면서 궁금한 점
Spring(Java)을 약 1~2년 정도 공부하다가, 최근 입사 후 NestJS를 새롭게 배우고 있습니다.공부하기 위한 강의를 듣던 중 문득 궁금증이 생겨 이렇게 질문을 남깁니다.NestJS를 사용하는 이유가 무엇일까요?제가 지금까지 배워온 관점에서 보면, Spring은 생태계가 훨씬 풍부하고 레퍼런스도 많으며, 엔터프라이즈 환경에서 안정성이 매우 높다고 느껴졌습니다.반면 NestJS는 비동기 I/O 처리에 강점이 있어 성능적으로 빠르다는 인상을 받았지만, 단순히 그 이유만으로 NestJS를 선택해야 할까 하는 의문이 들었습니다.물론 기술 선택에는 여러 요소가 있겠지만, 실무적으로나 기술적으로 Spring 대신 NestJS를 선택하는 명확한 이유가 무엇인지 궁금합니다.단순 궁금증이었습니다...!
-
해결됨시스템 디자인 첫걸음: 면접에서 돋보이는 백엔드 아키텍처 설계하기
로드밸런싱 관련 질문
안녕하세요 강사님! 강의 잘 듣고 있습니다.실제 서비스 환경에서 로드 밸런서를 두는 시점(예: 트래픽 기준이나 서버 수 기준)을 어떻게 판단하시는지 궁금합니다.단순히 서버 부하율이 높아졌을 때 적용하는 건지, 아니면 아키텍처 설계 초기에 미리 구성하는 경우가 더 일반적인지도 궁금합니다.
-
해결됨[코드팩토리] [초급] NestJS REST API 백엔드 완전 정복 마스터 클래스 - NestJS Core
DELETE 요청의 반환값은 어떤 기준으로 결정하는 게 좋을까요?
CRUD 중 DELETE 요청의 경우 어떤 기준으로 반환 타입을 정하는 게 좋을지 궁금합니다.제가 생각하기에는 아래 두 가지 방식이 있을 것 같습니다.강사님께서는 이러한 상황에서 어떤 기준을 표준으로 사용하시는지 궁금합니다.1. 일관된 응답return { success: true, data: null };CREATE, READ, UPDATE와 동일하게 성공 여부를 명시하고 data는 null로 처리하여 응답 구조를 통일하는 방식입니다.이렇게 하면 프론트엔드에서 일관된 형태로 응답을 처리할 수 있을 것 같습니다.2. HTTP 표준 준수 (204 No Content)@HttpCode(204)응답 본문을 따로 내려주지 않고 상태 코드만 반환하는 방식입니다.이 경우 RESTful 표준에 부합하고 불필요한 네트워크 비용을 줄일 수 있을 것 같습니다.다만 프론트엔드에서는 응답 본문이 없어 분기 처리가 필요할 수도 있을 것 같습니다.이 두 가지 방식 중에서 실무에서는 어떤 기준으로 선택하시는지 또는 프로젝트 성격에 따라 구분하는 기준이 있을지 궁금합니다.
-
해결됨강의 하나로 끝내는 백엔드 모든 지식!
22강 마지막 영상 짤림
큰 문제는 아닙니다만 22강이 마지막에 갑자기 종료되는 문제가 있습니다. 따로 어디에 말씀드려야 할지 모르겠어서 Q&A 게시판에 남깁니다.
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
MessageConversionException 예외 타입
안녕 킬구형 형 때문에 이번 추석 연휴 재밌게 보내고 있어. 고마워 형. 강의를 보면서 예제 소스에 대한 궁금증이 생겨서 질문을 남겨. 6장. 작전4: 원격 청킹 (Remote Chunking) - 전방위적 타격이 시작되다. ☠ '데이터 변화 모듈(SerDes Classes)' 예제에서 예외 객체로 MessageConversionException을 사용하는데 클로드에서는 통상 Kafka를 사용할때는 org.apache.kafka.common.errors.SerializationException 을 사용해야 kafka와 호환이 된다고 하더라구. 이거에 대해 설명 부탁해도 될까?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
실무 예시가 궁금합니다.
형 아직 잘 이해가 안되서 그러는데, Job 안에서 Chunk 방식 Step과 Tasklet 방식 Step을 혼합해서 사용하는 실무 예시를 알려줄수 있어?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
Spring Data JPA 사용 시 자동 주입 관련 질문
킬구형 Spring Data JPA 사용하면 JpaRepository 인터페이스를 사용해서 PlatformTransactionManager, DataSource를 자동으로 주입받아 사용할 수 있는데, 강의에서는 스프링배치의 세밀한 조정을 위해 일부러 JpaRepository를 사용하지 않는 거야?아래 두 강의에 둘 다 데이터소스와 트랜잭션매니저를 직접 활용하고 있어서 궁금해서 물어봐3장. 작전1: 관계형 데이터베이스 읽고 쓰기 (테이블의 심장에 처형장을 세우다 ☠)OPERATION DOUBLE TAP - Spring Batch Test(추가) 생각해보니 예전에 아주 간단한 로직의 스프링배치 앱을 JpaRepository, JPQL을 이용해서 만들었던 만들었던 기억이 있는데,, 혹시 JpaRepository을 일부러 사용하지 않는 이유가 있는지 궁금해
-
해결됨제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
ejs 와 어떤 개발언어로 조합해서 사용했을때 성능이 좋을까요?
ejs 와 어떤 개발언어로 조합해서 사용했을때 성능이 좋을까요?
-
해결됨제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
404, 500 에러 처리 외에 특정 개발 구문에서 에러 발생했을때 찾는 방법이 있을까요?
404, 500 에러 처리 외에 특정 개발 구문에서 에러 발생했을때 찾는 방법이 있을까요?
-
해결됨제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
테스트시 포스트맨 외 테스트 할수 있는 방법이 있을까요?
테스트시 포스트맨 외 테스트 할수 있는 방법이 있을까요?
-
해결됨제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
보안에 취약 한가요?
보안에 취약 한가요?
-
해결됨제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
json 대신 로그인, 회원가입 일때 db 연결 및 data 사용하려면 어떻게 하나요?
json 대신 로그인, 회원가입 일때 db 연결 및 data 사용하려면 어떻게 하나요?
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
예제 궁금증
실제로 실행을 못해보는환경이라서 질문하는건데,JobLauncher를 활용한 REST API 구현의 예제같은경우 컨트롤러 하나를 생략없이 다 표현한거같은데 jobRegistry 는 di받지않았는데 어떻게 실행하는거임?빼먹은건가? job = jobRegistry.getJob(jobName);
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
TransactionManager 분리
TransactionManager 분리에 대해서 이해가 잘 가지 않는게 있어. 실제 운영 환경에서는 배치와 비즈니스 데이터 DB를 분리하는게 필수라고 했잖아?근데 이 분리의 단위가 배치용 메타데이터 저장만 분리를 하는게 맞는거야? 현재 사이드 프로젝트에서 멀티모듈 구조에 (MSA는 아님) API 모듈과 배치 모듈을 따로 분리한 상태야.유저 데이터에서 생일을 뽑아서 내일 생일인 유저에게 FCM 을 발송하는 배치를 만드는데,이때 만들어준 예제처럼 @BatchDataSource와 비즈니스 로직용 @Primary DataSource를 분리하게 되면,API 모듈용 DB Connnection을 배치에서도 똑같이 갖다 쓰는거 아니야 ?? 즉, 배치에서 API 쪽 커넥션을 가져다 써서 배치가 돌 때 커넥션이 고갈날 수 있지 않을까? 라는 생각이 들었어지금 이해한 바로는 @BatchDataSource, @BatchTransactionManager를 분리하고 주입해줘도 Reader -> Processor -> Writer 에는 @Primary 걸 쓰는것 같은데 맞아 ?나는 DB 분리와 함께, 비즈니스 로직에 대한 커넥션, 트랜잭션도 배치용으로 분리하고 싶은데 이럴땐 어떻게 해야해?특히나 배치에서도 JpaTransactionManager를 쓰고 싶은 경우에는 어떻게 해야해 ?원하는 바는, API 처리용 DB 커넥션은 커넥션대로 있고, 배치 메타데이터용 커넥션 따로, 배치에서 라이브 DB에서 유저 데이터를 가져오는 커넥션 따로 구성하고 싶어 (배치가 API 모듈 에 영향을 주지 않았으면 해서,,,) 혹시 내가 강의를 제대로 이해를 못한거라면 알려줘
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타(?) 발견
킬구형 강의 자료 중간에 이상한 문구 발견해서 제보해강의 회차: 5장. 작전4: Flow - 배치의 흐름을 지배하라 (분기점에서 생사를 쥐락펴락하라 ☠🏴☠)이상한 문장: 즉, Spring Batch의 암시적 전환 규칙 대상에서 제외된다는 뜻이다.재시도Claude는 실수를 할 수 있습니다. 응답을 반드시 다시 확인해 주세요.강의 자료 중간에 LLM에서 가져온 내용을 잘못 편집한 것 같아.
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타 발견
가령 다음과 같이 getExecutionContextSerializer() 메서드를 오버라이드하면g에 볼드처리안됨--원시적 침투 예제의 BatchConfig에서 DefaultBatchConfiguration 상속을 제거하고@EnableBatchProcessing을 추가하자. 다음과 같이 말이다.예제밑의 예제가 그냥 기존 DefaultBatchConfiguration 방식만 나와있음아마 기존과 수정을 두개 다 표시하는식으로 하고싶었을거같음--JobContext/StepContext: Late-Binding의 최종 무기고키룩형 JobContext/StepContext가 존재하면 배치 스코프가 활성화된 상태라는 것은 알겠어. 근데 이 JobContext/StepSontext 대체 어디에 써먹는거지? 단순히 활성화를 의미하는게전부인가?키룩형 -> 갈매기가 되고싶은 내면의 소리일수있음괜찮음 주변에 돌멩이 지망생도 있고 독수리 지망생,딸기우유 지망생도 있어서 이해할수있음
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
멀티모듈에서 DB 커넥션 풀 분리
DataSource에 대한 질문 배치를 적용중인데, 멀티모듈에서 배치용 Application을 따로두고, 배치용 yaml에서 datasource를 두었고, api쪽도 yaml에서 datasource를 보고 있다.이때 , 아래와 같이 Config에서 Bean을 통해 Datasource을 생성, JobRepository에 전달해주지 "않아도" 커넥션이 분리가 되는가?API 쪽 디비와, 배치 디비의 커넥션풀을 따로 쓰고싶은데 아래와 같이 별도 세팅 없이 yaml만으로 분리는 안되는지 궁금하다...@Configuration class JpaConfig { @Bean @ConfigurationProperties("spring.datasource") fun batchDataSource(): DataSource { return HikariDataSource() } @Bean fun jobRepository( batchDataSource: DataSource, transactionManager: PlatformTransactionManager, ): JobRepository { return JobRepositoryFactoryBean().apply { setDataSource(batchDataSource) setDatabaseType(DatabaseType.POSTGRES.name) setTransactionManager(transactionManager) afterPropertiesSet() }object } }
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
오타 발견
SimpleStepHandler - Step 실행의 관리자Step의 실행은 StepHandler에 의해 의해 통제된다. Spring Batch는 기본 구현체로 SimpleStepHandler를 사용하는데, 이 컴포넌트가 Step 실행의 전체 라이프사이클을 관리한다.의해 의해 <-그리고 Step Squad 핵심 요약 있으니까 너무좋은데 Job Squad 에서도 핵심요약이 있었으면 더 좋았을거같음뭐 스탭이나 잡이나 내용이 거의 비슷비슷하긴한데(Execution 반드시 새거만들고,상태변경시 즉시 메타데이터저장소에 저장하고)그래도 실제 실행 따라가는 느낌이라 정리가 잘 안되는느낌이긴해서 마지막에 방점찍으면 보기 더 편할거같은느낌
-
미해결죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
writer retry 관련해서 궁금한 점이 있습니다.
반말은 조금 부끄러워서.. 존댓말로 질문드리겠습니다. ItemWriter에서 예외 발생 시 재시도 - 청크 단위로 재시도 관리 1. ItemWriter에서 예외 발생 시 ItemProcessor부터 처리가 재개된다.2. ItemProcessor에서와 달리, ItemWriter에서의 재시도 횟수는 청크 단위로 관리된다. 요 부분에서 실제로 배치를 돌려보니 writer부터 재시작하는 것을 확인 가능했습니다.. 관련해서 원인을 분석해보니, 아래 결론에 도달했는데 맞을까요? processorNonTransactional() 설정이 켜져있으면 Item 단위로 처리 결과를 캐시에 저장하기때문에 processor는 모두 완료 처리 -> writer부터 시작processorNonTransactional() 설정이 꺼져있으면 청크 단위로 완료 처리하기때문에 processor부터 다시 시작
-
해결됨죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
청크 지향 처리 시 벌크 read 방법?
킬구형, 청크 지향 처리 시 벌크 read를 할 수 있는 방법이 있어?ItemReader 사용 시 소스에서 1건 씩 데이터를 읽어온다면, 단건 SELECT문이 매번 날아가거나 아니면 JDBC의 ResultSet next()를 사용하는 것 같은데,, 전자면 DB 부하가 너무 심하고 후자여도 네트워크 IO가 꽤 발생할 것 같은데..지금 수백? 수천만? 건 정도의 데이터를 마이그레이션 해야하는 업무를 받았는데, 청크 생성 시 DB 부하나 네트워크 트래픽을 좀 줄이고 싶은데 다건 SELECT를 통해 처리하는 방법이 있을까?