안녕하세요 게시판 강의 보면서 정말 잘 배우고 있습니다!!  국비학원 프로젝트 하던 때를 생각해보면서 듣고 있는데, 그때는 엔티티에 생성자를 만들어서 서비스에서 그냥 썼는데 본 강의에서 팩토리 메소드 형태를 사용하는 이유가 궁금했습니다!! (기술적으로 더 진보한 형태인지요) 그리고 객체마다 response를 만들어서 commentResponse, ArticleLikeResponse 같은걸 만들어 api 반환에 사용하는데, entity랑 필드도 다르지 않은데 굳이 이렇게 일일이 response 객체를 각각 만들어서 코드를 짜야하는지 궁금합니다!!

형! 퇴근도 못하고 일하다가 이제야 형 강의보면서 주말을 맞이하고 있어! 스프링 배치를 써서 분 단위, 하루 단위 KPI를 산출하는 배치 프로그램을 만드려고 하는데, 실무에서는 어떻게 HA를 구성하는 지 궁금해졌어. 가령, k8s에서 같은 배치를 돌리는 pod가 여러 개이면 배치가 동시에 돌 것 같고, pod가 한 개이면 하나의 배치 시스템이라서 위험할 것 같은데, 어떤 식으로 실무에서 하는 지 궁금해!

안녕하세요, 강의 너무 잘보고있습니다!코드를 살펴보니 궁금한 부분이 있는데 현재 작성된 코드에서는 엔티티 간 연관관계를 맺지 않고 풀어내고계시더라고요!재미니님은 실무에서도 연관관계를 사용하지 않으시는 건지 아니면 고민 포인트(?)를 던져주신건지 궁금합니다!예를들어 Order와 OrderItem 관련해서, OrderService의 서비스 레이어인 create 메서드에서 OrderItemRepository를 사용해 saveAll을 호출하는 방식을 사용하시더라고요!저는 Order가 없으면 OrderItem은 존재하지 않아야한다고 생각해서, OrderItem의 생성을 서비스 레이어가 아닌 Order 엔티티안에서 생성하도록 강제하는 건 어떨까 생각했습니다.방법으로는OrderItem.create() 같은 생성 메서드를 protected로 막는다.OrderItemRepository를 아예 생성하지 않는다.더티 체킹을 이용하여 Order 필드에 있는 List<OrderItem> 컬렉션에 요소 추가로 OrderItem을 save한다.팀 컨벤션을 정한다.정도가 있을 것 같은데... 그렇다면 재미니님은 실무에서도 연관관계를 맺지 않는 방식을 선호하시는 건가요?사실 서비스 레이어에서 직접 호출을 통한 저장이라고 해도 문제는 없겠지만 사용하시는 방식이 궁금합니다! 그리고 추가적으로 주문 시 상품 재고를 차감시키는 메서드를 OrderHandler(OrderManager) 에 private으로 위치시키는 것과 ProductHandler(ProductManager)에 위치시키고 주입받아 사용하는 것중 어떤게 더 나은 방식일까요?private void decreaseProductStock(List<NewOrderItem> newOrderItems, Map<Long, Product> productMap) { for (NewOrderItem newOrderItem : newOrderItems) { Product product = productMap.get(newOrderItem.productId()); if (product.isStockLessThan(newOrderItem.quantity())) throw new ApiException(PRODUCT_QUANTITY_OVER); product.decreaseStock(newOrderItem.quantity()); } }고민이 되는 부분은 예를들어 위와 같은 메서드를 OrderHandler에 두자니 조금 헤비해지는 것 같고, ProductHandler에 두자니 신규 주문 시에만 사용될 것같은데.. ProductHandler에 두는게 맞는지 고민입니다..! 의견이나 힌트 주시면 좀 더 고민해보도록 하겠습니다!

안녕하세요! 궁금증이 생겨 문의 드립니다.common 공통 모듈은 서비스간 통신 데이터 구조를 표준화해서 통일성 있게 사용하기 위해서 사용한다고 이해하였습니다. 현재, 멀티모듈로 작성된 프로젝트라서 common 모듈을 작성된 것 같은데, 각각 독립적인 repository 로 운영된다면 이를 극복하기 위해 Nexus 같은 repository 에 관리하여 공통 dto 를 관리하는 방법은 어떤지 문의 드립니다. 적다 보니, 분산 환경에 대한 질문은 아니라서 죄송합니다...

안녕하십니까 좋은 강의 잘듣고 있습니다.강의를 들으면서 예제 코드도 같이 파악해보고 있는데요repository 조회시 조회한 결과에서 활성 상태를 체크할때 2가지 방법으로 구현이 되어있는 것 같습니다.repository에서 쿼리 메서드로 값 전달 findByXXAndStatus()일단 findByXX로 조회하고 filter에서 isActive 체크 2가지 경우다 결과 자체는 Active인 엔티티를 조회하겠지만, 두 경우를 언제 사용하는 것이 좋은지가 구분이 있을까요?? 일단 저라면 목록을 조회하는 경우라면 1번 방법으로 조회하면 조금이나마 성능 이점이 있을 것 같고, 단일 데이터 조회시에는 1번이나 2번이나 상관은 없을꺼 같다는 생각입니다! https://youtu.be/o5byT9Ha5Tg?si=C1zj8oP8-wSB6g7Y최근에 우테코에서도 softDelete 관련 처리를 엔티티 설정을 통해 하기도 하던데, 제미니님의 의견이 궁금하여 질문드립니다! 감사합니다! ps. 아직 제가 강의를 쿠폰 부분까지 들어서 뒤에서 이에 대한 설명이 나오는지는 확인을 못했어요! 

ProductFinder -> ProductUsecase or ProductUsecase<ProductSection>정의한 곳에 Product 서비스 와 ProductSection 서비스를 갖고 안에서 작업을 해보는건 어떻게 생각하실까요?ProductProductSecion 으로 명명하기에는 애매한 부분이 있어, Usecase라는 단어를 써서중간에 두 서비스만 사용하는 컴포넌트를 하나 두는 것은 어떻게 생각하실까요?혹은 Delegator 를 써서, 이 두 서비스를 의존해서 처리해야 하는 프로세스를 위임해버리는 타입을 하나 만드는겁니다.어떻게 생각하실까요?

1초로하면 현재 성공, 실패 각각 200, 0으로 나오고 2초로 해야 100개 씩 성공하는데 정상인가요?

@PrePersist가 있는 메서드는 영속성 컨텍스트에 엔티티를 저장할때 즉, save()나 persist() 호출 시점에 호출되는것인가요? 아니면 flush()이후에 INSERT쿼리가 실행되기 직전에 호출되는것인가요?@PreUpdate가 있는 메서드는 엔티티의 변경 감지가 일어나고 트랜잭션 커밋 또는 em.flush()시점에 UPDATE쿼리가 실행되는데, 이 UPDATE쿼리가 실행되기 직전에 호출되는것이 맞을까요? 

안녕하세요!궁금한점이 생겼는데요.로직을 수행하는 객체중 어떤것은 xxx서비스 어떤것은 xxx핸들러또는매니저(컴포넌트) 등의 객체로 나눠지는데요. 이에 대한 기준이 있을까요?컨트롤러가 호출하는 객체를 xxx서비스, 서비스가 호출하는 객체를 xxx핸들러또는매니저(컴포넌트)라고 보면 될까요? 그렇다면 컴포넌트는 특정 개념에서의 로직들이 응집되어있는 객체 라고 보면 될까요?

안녕하세요!과거에, MSA 학습용으로 모의 주식 투자 서비스(?)를 만들어본 사람입니다. 당시에, 주식 매수의 기능을, 2개의 service 로 운영했었고, 이때 각 요청의 순서는 이벤트 기반으로 처리하였습니다.client -> stock service -> kafka-> payment service(이벤트 구독)이때, 특정 문제에 대한 트랜잭션 보장을, 보장 로직을 통해 구현하였었습니다.이때, kafka pub/sub 이벤트를 동기적으로 처리되었는지 확인하도록 구성해놓았었습니다. 주식 거래와 같은 일관성이 매우 중요한 서비스에서 어떤 방향성이 더 올바른(?) 방향이라고 생각하고, 어떤 생각을 가지고 계신지 궁금합니다. 현재 생각으로는, 2pc 를 채택하는게 더 올바른 선택이었다고 생각이 듭니다.

킬구형메타데이터쪽 update를 읽다가 이해가 안가는게 있는데 형이update() 메서드는 매 트랜잭션의 커밋 직전에 호출된다. 단, 처리 도중 예외가 발생하여 트랜잭션이 롤백되는 경우에는 호출되지 않는다. 이는 실패한 처리 내용이 실행 정보에 반영되는 것을 방지한다.라고 했는데 그러면 문제가 생겨서 update를 호출하지 않고 롤백이 됬다고 하면 open입장에서는 실패했는지 안했는지도 모르는거아니야? 실패를 해도 마지막으로 저장된 곳부터 다시 시작하니까 실패를 아예 저장을 안한다는거야?재시작할때 메타테이블에서 execution값을 받아와서 괜찮은건가?

강의중에는 private long tno; private String title; private String content; private boolean complete; private LocalDate dueDate;위와같은 설정인데, 왜 갑자기 private long tno; private String title; private String writer; private boolean complete; private LocalDate dueDate;로 바뀌는 건가요?이것에 대한 설명은 어디에 있는거죠?몇강 몇분대에 있는지에 대해서 알려주시면 감사하겠습니다.  

안녕하세요.강의가 업데이트 되면서 다시 한번 강의 듣고 있네요 감사합니다.업데이트 된 강의자료(PDF, PPT)파일을 다운 받고 싶은데 어디서 다운 받아야 하나요?답변 부탁드립니다.감사합니다.수고하세요.

전체보기가 없는 상품들 목록이라면카테고리 프로덕트로 설계하는 방향은 어떻게 생각하시는지요?상품의 전체보기가 없습니다.A-Z까지 모든상품들은 카테고리로로 분류되어있고(=모든 상품들은 카테고리라는 꼬리표를 가집니다)좌측 메뉴탭에서도 카테고리별로 구분이 되어있습니다.해당 상품들을 모두 카테고리별로 선택의 상세보기에 해당상품들이 나열되도록 되어있습니다.이러한 생각은 어떤지 한번 의견 듣고싶어요. 

안녕하세요!강의를 보던 중 ReviewService의 트랜잭션 처리에 대해 궁금한 점이 있어 질문드립니다. addReview 함수에서 리뷰를 저장하는 add()와 포인트를 적립하는 earn() 두개의 중요한 함수를 사용하고 있는데, 이는 각각 별도의 트랜잭션으로 처리되어 리뷰는 저장되고 포인트는 적립되지 않는 문제가 발생할 수 있을 것 같습니다.  현재 설계에서 addReview()에 @Transactional을 붙이지 않은 특별한 이유가 있으신지 궁금합니다. 혹은 만약 의도적으로 별도 트랜잭션으로 분리한 것이라면 그 이유가 궁금합니다. 항상 감사합니다.

안녕하세요, 제미니님.유투브 및 인프런 강의 잘 시청하고 있습니다 :) 인프콘 2024에서 '지속 성장 가능한 설계를 만들어가는 방법' 이라는 주제로 발표해주신 내용이 무척 공감이 되었고, 제미니님 유투브를 찾아봤다가 강의까지 수강하게 되었습니다 이번 강의 내용은 아니지만 인프콘 영상에서 말씀해주신 개념인 '개념' 과 '격벽'을 구체적으로 실무에서 어떻게 사용하면 좋을지를 여쭤보고자 인프런 질문을 통해서 글을 올리게 되었습니다. 편의상 신규 프로젝트를 진행한다고 가정했을때,요구사항을 분석하고 도메인을 구성하는 여러 '개념'들을 나열한다.나열된 '개념'들의 급(1급, 2급, 3급 ..) 을 나눠보고 그룹화 하면서 '격벽'으로 분리한다.'격벽'으로 분리된 그룹이 어떤 개념을 통해서 연결될지 방화벽으로 동작할 개념을 생각해본다. 이는 개념간 무분별한 참조를 막기 위함이다.'개념'들과 '격벽'들을 기반으로 일단 코드로 구현부터 해본다. ('설계를 하지 말고 구현을 먼저' 하는 포인트는 이것)구현하면서 또는 운영하면서 더 나누거나 신규로 추가할 개념이 있다면 반영한다. 결과적으로 설계를 하지 않고 구현을 먼저 하고, 구현 하는 과정이나 운영 하는 과정에서 최적화 시킨다. 이것이 곧 최적의 설계로 나아가는 방향이 된다. (질문) 제가 제미니님이 말씀하신 '개념'과 '격벽'을 잘 이해한 것이 맞을까요? 실무에서 위 흐름대로 적용하면 제미니님이 강조하신 내용에 기반한 작업이 될 수 있을까요? 실무에서 실제로 말씀해주신 내용을 적용해보고 싶은데 구체적으로 어떤식으로 적용하면 될 지 몰라서 제가 이해한 내용을 바탕으로 작성을 해보았습니다. 틀린 부분이 있다면 피드백을 부탁드리고 싶습니다 :) 긴 글 읽어주셔서 감사합니다~

안녕하세요 토비님 강의 잘 수강하고 있습니다. 좋은 강의 감사드립니다. 저는 JPA엔티티를 도메인 모델로 사용하고 애플리케이션에서 이를 리턴하고 있습니다.그런데 새로운 팀원 한명이 이렇게 이야기하더군요이전에 마이바티스를 사용하다가 JPA가 나온거처럼 이를 대체하려면 코드변화가 필요할 것 입니다 사실 이것도 저는 맞는 말이라고 생각합니다. JPA 엔티티를 참조하는 모든 부분을 수정이 필요할 것 같습니다. 그럼에도 불구하고, 트레이드오프 관점에서 보면 현재 잘 사용하는 JPA엔티티를 그대로 사용하는게 더 효과적이라고 생각합니다. 여기서 궁금한게, 이렇게 새로운 데이터접근 기술이 나오게 되는 것까지 고려하는게 맞을까요? 어떠한 논리를 펼쳐서 JPA를 그대로 의존하는게 좋다고 이야기하는게 더 설득력이 있을까요?

형님 안녕하십니까!2장 작전2 내용 중에, collected_logs에 모아진 모든 로그파일 내용을 Resource[]에 담고, 이를 flatFileItemReader로 읽기를 위임하는 부분이 있습니다. 아래는 그 중 Resource[] 배열에 해당 로그 내용을 담는 부분입니다. private Resource[] getResources(String date) { try { //String userHome = System.getProperty("user.home"); String userHome = "C:/Users/gyrbs/OneDrive/Desktop"; String location = "file:" + userHome + "/collected_logs/" + date + "/*.log"; //경로 직접 주입이 아닌 Resolver를 통한 url구성은 백슬래쉬가 아닌 /로 해야 인식 PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(); return resolver.getResources(location); } catch (IOException e) { throw new RuntimeException("Failed to resolve log files", e); } } 이에 대해서 gpt한테 몇가지를 물어보았는데, 먼저 배열에 읽어야할 내용을 담고 이를 filterReader로 읽는 과정이 Resource[] 배열에 읽어야할 모든 내용을 모두 저장하고, 이 저장한 내용을 reader가 받아서 청크지향처리라면 청크사이즈만큼 읽고 넘기고 아니면 지금과 같이 일괄적인 읽기를 진행하는 것으로 보였습니다. 그래서 만약에 읽어야할 내용이 매우 커지면 Resource[]라는 배열에 이 모든 내용을 넣기가 어려울 것이고, 강의에서 항상 강조해주시는 JVM무덤, 배치무덤이 되지않을까 하는 생각이 들었습니다. 그래서 이에 대한 방안을 gpt한테 한번 물어보았는데, public class StreamingMultiFileReader<T> extends AbstractItemStreamItemReader<T> { private Iterator<Path> fileIterator; private FlatFileItemReader<T> currentReader; private final Function<Path, FlatFileItemReader<T>> readerFactory; public StreamingMultiFileReader(Path dir, Function<Path, FlatFileItemReader<T>> readerFactory) throws IOException { this.fileIterator = Files.list(dir).iterator(); this.readerFactory = readerFactory; } @Override public T read() throws Exception { if (currentReader == null) { if (!fileIterator.hasNext()) { return null; // 모든 파일 처리 완료 } Path nextFile = fileIterator.next(); currentReader = readerFactory.apply(nextFile); currentReader.open(new ExecutionContext()); } T item = currentReader.read(); if (item == null) { // 파일 끝 currentReader.close(); currentReader = null; return read(); // 다음 파일로 넘어감 } return item; } }  이런 방법이 있다고 하는데(StreamingMultiFileReader로 deletegate 처리없이, 파일 하나하나씩 바로바로 처리해나가는 과정), 파일 하나하나씩 읽어들이면서 더이상의 파일이 없을때까지 순회하여 메모리부담은 없다고는 하였습니다. 혹시, 이 방법 말고도 청크지향처리를 이용해서 청크사이즈 만큼 파일, 혹은 파일 내부의 record를 읽고 넘기는, 그리고 이 과정을 모든 파일에 대해 순회하는 방식은 없을지 질문드려보고자 합니다! 실무에서 사용하는 방법이 궁금해서 질문드리게 되었습니다! 감사합니다.

안녕하십니까 형님!2강 작전2 : 분산 서버 로그 처형 작전 관련해서, 실무적으로 어떠한 방향으로 접근하는 것이 좋을지 의문이 생겨서 질문 드려봅니다!제가 윈도우 환경에서 실행하다보니, 자료에 기술된 cli를 윈도우 환경으로 바꾸는데 많은 비용을 소모하였습다.특히 이번 내용의 경우,단순 개행문자 및 OS간 인식문제를 넘어서, 명령어를 아예 윈도우 환경에 맞게 변경을 해야한다는 점에서 다소 힘이 많이 들었던 것 같습니다.뿐만 아니라, 윈도우 cmd 환경에서의 실행을 고려해서 cmd -c의 명령어를 추가해준다든지, 리눅스의 mkdir -p가 먹히지 않으므로 mkdir를 &&로 이어서 실행하게끔 한다든지..(이러다보니 collected_logs 폴더도 최초부터 존재하지 않아야 정상 실행이 가능한 환경적 제약사항까지 고려해야 하였습니다) 전체적으로 환경의 차이를 많이 느끼고 그만큼의 비용도 일전보다는 훨씬 많이 소모된 느낌이 있었던 내용이었습니다. //-p 옵션은 윈도우에서 안먹힘..따라서 collected_logs라는 디렉토리 생성(mkdir)은 처음부터 존재하지 않아야 한다. //SystemCommandTasklet -> 반드시 cli 명령어 작성 필요 @Bean @StepScope public SystemCommadTasklet mkdirTasklet( @Value("#{jobParameters['date']}") String date) throws IOException { SystemCommandTasklet tasklet = new SystemCommandTasklet(); // //tasklet.setWorkingDirectory(System.getProperty("user.home")); //실행환경은 batch 명령어 작성환경에 상관없이 무조건 cmd //경로직접주임은 반드시 백슬래쉬 tasklet.setWorkingDirectory("C:\\Users\\gyrbs\\OneDrive\\Desktop"); String collectedLogsPath = "collected_logs\\" + date; String processedLogsPath = "processed_logs\\" + date; //String collectedLogsPath = String.format("collected_logs\\%s", date); //String processedLogsPath = String.format("processed_logs\\%s", date); String command = String.format("mkdir %s && mkdir %s", collectedLogsPath, processedLogsPath); // //tasklet.setCommand("mkdir", "-p", collectedLogsPath, processedLogsPath); //tasklet.setCommand("cmd", "/c", "mkdir", collectedLogsPath); tasklet.setCommand("cmd", "/c", command); tasklet.setTimeout(3000); // 3초 타임아웃 return tasklet; }@Bean @StepScope public SystemCommandTasklet scpTasklet( @Value("#{jobParameters['date']}") String date) { SystemCommandTasklet tasklet = new SystemCommandTasklet(); //tasklet.setWorkingDirectory(System.getProperty("user.home")); String rootDirectory = "C:\\Users\\gyrbs\\OneDrive\\Desktop"; tasklet.setWorkingDirectory(rootDirectory); String collectedLogsPath = String.format("collected_logs\\%s", date); StringJoiner commandBuilder = new StringJoiner(" && "); for (String host : List.of("localhost", "loan", "pay")) { //String command = String.format("scp %s:~\\logs\\%s.log .%s\\%s.log", // host, date, processedLogsPath, host); String src = String.format("logs\\%s.log", date); String dest = String.format("%s\\%s.log", collectedLogsPath, host); commandBuilder.add(String.format("copy %s %s", src, dest)); } //String src = String.format("logs\\%s.log", date); //String dest = String.format("%s\\%s.log", collectedLogsPath, "localhost"); tasklet.setCommand("cmd", "/c", commandBuilder.toString()); tasklet.setTimeout(10000); //10초 타임아웃 return tasklet; } 이런 느낀점이 많다보니, 이번 내용을 진행하면서, SystemCommandTasklet을 실무적으로 어떻게 활용하면 좋을지 의문점이 생겼습니다. 첫번째는, 단순히 배치를 실행하는 환경이 리눅스라면, 리눅스 환경은 어차피 한동안 안고쳐질거니까, 윈도우라면 그것대로 윈도우 배치 환경은 거의 변경이 없겠지?라는 생각으로 단순히 SystemCommandTasklet으로 구성해야겠네!라고 생각하는게 맞는지 일단 의문이 들었습니다. 배치라는게 이러한 환경적 독립성을 유지하지 않고, 배치실행환경에 맞게 일단 구성하는게 맞을까요? 물론 이 내용이 SystemCommandTasklet을 배우는데 중점이 있을 수 있겠지만, 이번에 꽤 많은 소모를 느껴서 질문드리게 되었습니다! 두번째로, SystemCommandTasklet이 아닌 Tasklet을 사용하여 아래와 같이 시스템에 의존하지 않고 모든 시스템에 적용이 가능한 Java API버전으로 구성하였는데, 빌드 성공하긴 했습니다. //-p 옵션은 윈도우에서 안먹힘..따라서 collected_logs라는 디렉토리 생성(mkdir)은 처음부터 존재하지 않아야 한다. //tasklet -> return (con, ch) @Bean @StepScope public Tasklet mkdirTasklet( @Value("#{jobParameters['date']}") String date) throws IOException { return ((contribution, chunkContext) -> { Path desktop = Paths.get("C:\\Users\\gyrbs\\OneDrive\\Desktop"); Path collected = desktop.resolve("collected_logs").resolve(date); Path processed = desktop.resolve("processed_logs").resolve(date); Files.createDirectories(collected); Files.createDirectories(processed); return RepeatStatus.FINISHED; }); } 이렇게 처음부터 시스템에 상관없는(상관없이 구동이 가능한) 로직을 구현하는게 유지보수적으로도 맞지 않을까..하는 생각이 들었습니다. 형님께서는 실무적으로 이를 적용할때 어떠한 방향으로 구성하시는지, 제가 지금 의문이 드는게 맞는것인지.. 궁금해서 질문드려봅니다!(아니면 만약 SystemCommandTasklet과 같이 시스템에 의존적인 구현이 필요하다면, 이 경우는 환경적으로 바뀔 가능성이 현저히 적다던가..이러한 특수적인 상황적 조건이 있을때 사용하실까요?) 제약사항이 생각보다 커져서 배꼽이 더 커지는 상황이었기에, 형님께 여쭤보고자 하였습니다! 감사합니다!

안녕하세요 시간날 때 틈틈히 보다가 어느새 막바지에 다다랐네요! 타임베이스 정산 배치가 실패했을 때 궁금한점이 있습니다. 우선 현재는 시간 대별로 오전 1시, 4시, 9시로 배치가 나눠져있는데이 상황에서 강의에서도 설명하셨듯이 오전 1시 배치가 오전 4시 30분에 끝나서 오전 4시의 배치가 에러가 뱉는 상황에 대해 문제를 해결하는 방법들이 궁금합니다! 우선 제가 생각한 방법들은 다음과 같습니다.1. 이벤트 기반 이벤트 기반으로 각 단계가 완료되면 바로 다름 배치 단계로 넘어가는 방식입니다.하지만 이 방법은 이미 기존 인프라와 코드를 변경해야하고 정산 시간이 고정 된다는 요구사항이 있다고도 보여 현재 요구사항에는 적절하진 않은 것 같습니다.  2. 각 배치마다 전 단계 완료 여부 상태를 확인오전 4시, 오전 9시 배치가 이전 단계의 배치 중 실패한 배치 이력이 있는지 확인하는 방법입니다.현재 스케줄링 방식으로는 이를 위해 별도의 배치 기록 테이블을 만들어서 배치 이력 관리를 추가합니다.오전 4시, 오전 9시에 해당 정산 날짜에 대해 실패한 이전 배치 단계 이력이 있다면 성공할 때 까지 N번 재시도 합니다.정산의 즉시성이 필요하다면 N번 재시도 후 실패했을 때 해당 배치 단계를 에러 상태로 처리하고,에러 로깅과 알림을 전송합니다.다음 배치 단계는 정산 날짜에 해당하는 이전 배치 이력이 에러 상태로 남아 있다면 실행하지 않습니다. 현재 요구사항에서는 수동으로 처리할 부분은 최대한 제거하는 2번 방식을 사용할 수 있을 것 같습니다.제가 배치 관리에 대해 잘 이해하고 있는지 모르겠어서 생각한 방법에 대해서 재민님은 어떻게 생각하시는지 궁금합니다.! 항상 잘 보고 있습니다 감사합니다!