안녕하세요 실습 중 컴파일 오류가 왜 발생하는지 이해가 안되어 질문 남깁니다. private final MemberRepository memberRepository; private final EmailSender emailSender; private final PasswordEncoder passwordEncoder; 해당 코드에서 EmailSender와 PasswordEncoder 부분에서 Could not autowire. No beans of 'EmailSender' type found. 컴파일 오류가 발생합니다. final을 제거하면 컴파일 오류가 발생하지는 않는데요 하지만 github 페이지에 올려주신 소스코드를 보면 현재 영상 시점과 코드 구조가 100% 일치하지는 않지만 스프링 빈 관련 설정을 따로 해준 것 같진 않아보입니다만.. 토비님 영상에서는 오류가 없고 제 코드에서는 컴파일 오류가 나네요. 어떤 시점에 따로 Spring Bean 관련 설정이 되어있는게 있다던가.. 아님 제가 빼먹은 부분이 있다면 알려주실 수 있으신가요? 문제가 되는 부분 전체 코드 첨부드립니다. 시간되실 때 확인 부탁드립니다. 감사합니다. package com.ggne.splearn.application.required; import com.ggne.splearn.domain.Email; /** * 이메일을 발송한다. */ public interface EmailSender { void send(Email email, String subject, String body); } package com.ggne.splearn.domain; public interface PasswordEncoder { String encode(String password); boolean matches(String password, String passwordHash); }
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 섹션 3에서 runnable를 인터페이스로 불러서 사용할 때 static으로 정의하는 이유가 있나요? 그리고 간간히 왜 이거는 생성자를 받아오지 않고 바로 써야 하는지, 이건 왜 static을 써야 하는지 등등의 의문이 드는데 제가 자바에 대한 이해가 부족해서 그런 걸까요? ㅜㅜ 중급편 내용이 아는 내용이라 건너뛰었는데 중급도 수강하는게 맞을까요?
안녕하세요 토비님! 좋은 강의 만들어주셔서 잘 듣고 있습니다. 작은 질문이 하나 있는데요. checkDuplicateEmail 메서드와 동시 요청에 관한 질문이 있습니다. 섹션 5. 28강 회원 애플리케이션 서비스 테스트(2) 20:47초 경에 email 중복 체크를 위하여 checkDuplicateEmail 메서드 코드를 작성하였고, 같은 email로 가입하려고 하면 DuplicateEmailException이 발생하는 것을 확인하였습니다. 그런데 여기서 다른 가정을 해보고 그런 상황에서 토비님이라면 어떻게 하셨을지 궁금합니다. 만약 email이 아닌 id로 회원가입을 하는 상황을 가정한다면, email과 다르게 id는 여러 사람이 같은 id로 회원가입하려고 시도할 수 있습니다. 따라서 동시에 2개의 요청이 들어오게 된다면 checkDuplicateEmail는 둘 다 통과하고 DataIntegrityViolationException이 발생하게 될 것입니다. (DB에서 유니크 제한을 걸었기 때문에) 규칙인 id는 중복되지 않는다는 지켜지겠지만, 사용자가 보게 될 예외는 우리가 의도했던 DuplicateEmailException가 아니게 되겠죠. 여기서 궁금한 점은 이런 상황까지 고려하여 코드를 작성하여야 하는 것인지 아니면 그냥 넘어갈 것인지 궁금합니다. 저라면, 드물게 발생할 것이라고 예상을 했다면 로깅만 잘 해놓고, 해당 예외가 많이 발생했거나 관련 cs문의가 많이 들어온다면 추가로 코드를 작성할 것 같습니다. 처음부터 만약 많이 발생할 것이라고 예상했다면 try-catch를 통해 예외를 변경해줬을 것 같습니다. 아마 다음과 같은 코드가 될 것 같습니다. @Override public Member register(MemberRegisterRequest registerRequest) { try { checkDuplicateEmail(registerRequest); Member member = Member.register(registerRequest, passwordEncoder); memberRepository.save(member); emailSender.send(member.getEmail(), "등록을 완료해주세요", "아래 링크를 클릭해서 등록을 완료해주세요"); return member; } catch (DataIntegrityViolationException e) { if (/*e를 통해 유니크 키 예외를 확인했다면*/) { throw new DuplicateEmailException(); } throw e; } } 서비스의 코드가 현재보다는 보기 지저분해진다고 생각했습니다. (아니면 이 방법이 아닌 다른 방법이 있을까요?) 토비님은 어떻게 생각하시는지 궁금합니다.
안녕하세요! 토비님ㅎㅎ 강의를 잘 듣고있는데, 궁금한게 있어 여쭤봅니다! 템플릿/콜백 구조에서 '고정된 틀(템플릿)'과 변하는 로직(콜백)의 경계를 어디까지 두는 게 좋을지 궁금합니다. 예를 들어 강의에서는 ApiTemplate 안에서 URI 생성, 응답 처리, 예외 변환까지 모두 포함되어 있는데, 이런 부분들도 콜백으로 분리하는게 맞을까요 아니면 템플릿 내부에 두는 게 더 적절할까요?
안녕하세요 토비님 명료한 설명, 가르침받고 있습니다! 테스트 관련해서 모든 클래스마다 테스트가 있어야하나 생각해보다가 크게 두 가지 질문이 있어 이렇게 남겨봅니다~ 1. 작성하는 모든 클래스에 대해 테스트를 해야하는지, 테스트를 만들지 않아도 괜찮은 경우가 있을까요? 예를 들면 아래 경우에 테스트 의미가 있을까라고 생각이 들었네요 테스트 대상 클래스가 협력자(?)를 추가 로직없이 wrapping하는 경우, 즉 대상 클래스가 단순 wrapper인 경우 2. 강의 중에서 PaymentService에 있던 valid 체크로직을 Payment로 이동하였고, 이에 따라 PaymentTest에 도메인 오브젝트에 대한 테스트를 작성하였습니다. 헌데 PaymentServiceTest에서 valid에 대한 test suite가 있는 상황입니다. 이 경우 PaymentServiceTest만으로 PaymentTest는 커버가 되는 상황이기에 PaymentTest의 valid 테스트는 하지않아도 되는거 아닐까요? 혹은 Payment에서 테스트하는게 더 적절하다면 PaymentService에서 valid 테스트는 하지않고 단순 Payment가 생성되었는지만 체크하도록 테스트를 수정해야할까요? 감사합니다!
aop의 단점을 보완하기 위해 advice 패턴을 사용하셨는데, 매번 코드에 advice가 들어가는게 좀 번거로울 수도 있을거 같다는 생각이 들어서 질문드립니다..! aop의 단점을 극복하기 위해 사용한거지만,, 혹시 Advice를 aop처럼 분리시켜서 적용시키는 방법이 따로 또 있을까요
$ kill-9.. 킬구형 추석 연휴는 잘 보냈는가.. 처음에 텍스트로만 구성된 강의인 걸 결제한 후 알게되어 당황했지만.. 걱정 마라.. 금방 킬며들었다.. 눈으로 읽고 생각하는 즐거움을 알게되었다.. 무엇보다 그동안 피로했을 내 귀를 지켜줘서 고맙다.. 아직 강의 초반이지만 궁금한 부분이 있어서 질문 올린다.. 대용량 트래픽을 다루는 회사에서는 배치 메타데이터의 양도 어마어마할 것 같은데 실무에서는 배치 메타데이터를 어떻게 관리하는 지가 궁금하다.. 혹시 배치 메타데이터를 활용할 일이 없을 것 같으면 안쌓는 것도 권장하는 방법인가..
기존에는 @Transactional 만으로 데이터 일관성이 보장된다고 생각했습니다. 하지만 강의를 들으며 동시에 재고를 조회·갱신하는 상황에서 격리성이 보장되지 않는 문제가 발생할 수 있다는 점을 뒤늦게 인식했습니다. 이런 흐름을 이력서에서 “단순 구현 → 시스템 안정성 중심의 설계로 성장한 과정”으로 기술적 사고 확장으로 어필해도 괜찮을까요? 아니면 너무 이론적으로 보일까요? (항상 서비스 내 로직만 고려해서 롤백 여부로 트랜잭션을 생각했는데, 큰일이네요ㅜㅜ )
안녕하세요! 강의에서 GC와 JVM 메모리 관리에 대해 설명해주신 부분을 듣다가, 제가 겪었던 Thread Starvation 문제가 떠올라 질문을 남기게 되었습니다 🤓 제가 겪었던 상황에 대해서 정리해보겠습니다. ✔ 1차 문제 발생 [프로젝트 환경] - Spring Boot 3.x, Java 21 - AWS EC2 t3.small (2 vCPU, 2GB RAM) - Docker 컨테이너 배포 - 개발 서버 (비용 최적화 목적) [문제 발생 과정] 초기에는 Docker 메모리 제한 없이 JVM만 -XX:MaxRAMPercentage=75.0로 설정했습니다. 카카오 소셜 로그인 기능을 추가한 후 배포 시 Thread Starvation 문제가 발생했습니다. # 초기 설정 (문제 발생) - Docker: 메모리 제한 없음 - JVM: -XX:MaxRAMPercentage=75.0 (호스트 2GB의 75% = 1.5GB) [결과] - JVM이 힙 1.5GB + 스택/Metaspace 400MB = 총 1.9GB 사용 - OS/Docker 600MB 사용 - 총 2.5GB 필요 → t3.small 2GB 초과 - Thread Starvation 발생 [1차 해결] Docker 메모리 제한을 추가하고 JVM heap을 축소했습니다. # Dockerfile ENTRYPOINT ["java", "-XX:+UseZGC", "-Xms512m", "-Xmx1g", "-jar", "app.jar"] # 배포 스크립트 docker run -d --memory="1.5g" --memory-swap="1.5g" --cpus="1.8" ... ✔ 2차 문제 발생 이후 구글/네이버 소셜 로그인, CRUD API들이 추가되면서 다시 Thread Starvation이 발생했습니다. AWS EC2 서버를 재부팅하고 SSH로 서버에 접속해서 원인을 파악해보았습니다. 아래 내용은 당시 작성했던 깃허브 이슈 내용입니다. ✏ 문제 상황 정리 1. 컨테이너 상태 확인 - docker ps -a | grep nugudi-dev (컨테이너는 실행중이지만 unhealthy 상태) - docker top nugudi-dev (컨테이너 내부 프로세스 확인: 아무런 프로세스도 출력되지 않았습니다 → Java 프로세스가 죽은 상태) 2. 헬스체크 실패 원인 확인 - Connection reset by peer 에러 → Spring Boot 애플리케이션이 정상적으로 응답할 수 없는 상태 3. 컨테이너 로그 확인 - HikariCP에서 반복적으로 Thread Starvation 경고 → GC가 CPU를 독점하여 애플리케이션 스레드들이 실행될 기회를 얻지 못하고 있는 상태 4. OOM Killer 확인 - docker inspect 명령으로 OOMKilled 여부 확인 → false → Linux의 OOM Killer가 프로세스를 강제 종료한 것이 아니라, Java 프로세스가 메모리 부족으로 인한 GC Thrashing 상태에서 스스로 응답 불가 상태 5. 메모리 사용량 측정 - EC2 인스턴스의 실제 메모리 사용 현황을 파악하기 위해 컨테이너를 중지한 상태에서 free -m 명령 실행 - OS + Docker 데몬: 256MB 사용 - t3.small 인스턴스의 총 메모리: 1901MB - → 컨테이너에 안전하게 할당 가능한 메모리: 1901MB - 256MB = 1645MB (약 1.6GB) 6. Docker 메모리 사용량 확인 (docker stats nugudi-dev --no-stream) - 재부팅 후 안정화된 상태에서 컨테이너의 메모리 사용량 확인: 866MB / 1.5GB (56%) 사용 - 안정화된 상태의 메모리 사용량. (따라서 애플리케이션 시작 단계에서의 피크 메모리 사용량은 아닙니다.) 7. CPU 크레딧 확인 - 78-90 크레딧 유지하고 있음. 따라서 CPU 크레딧 고갈 문제는 아니라고 생각했습니다. - 문제의 원인은 메모리 부족으로 인한 GC Thrashing으로 예상됩니다. 🧐 원인 파악 [메모리 부족 원인] 애플리케이션 시작 단계에서는 모든 클래스를 한 번에 로딩하고, 모든 Spring Bean을 생성하며, DB 커넥션 풀을 초기화하는 등 메모리 사용량이 피크에 달합니다. 이 시점에서 필요한 메모리가 Docker limit인 1.5GB를 초과하면서 메모리 부족 상태가 발생했습니다. 메모리를 확보할 수 없게 된 GC는 계속해서 메모리 확보를 시도하며 CPU의 90% 이상을 소비하게 되고, 이로 인해 애플리케이션 스레드들이 실행될 기회를 얻지 못하는 Thread Starvation 상태에 빠지게 된 것으로 예상됩니다. [ZGC의 문제점] 현재 사용 중인 ZGC는 초저지연을 목표로 설계된 GC 알고리즘입니다. 이를 위해 복잡한 메모리 구조를 사용하며, 이 과정에서 heap 크기의 10-20%를 Native Memory로 추가 소비합니다. 현재 너구디의 설정인 1GB heap 기준으로 약 200MB의 Native Memory를 사용하는 것입니다. 반면 G1GC는 heap의 약 5%만을 Native Memory로 사용하므로 약 50MB 정도만 필요합니다. 따라서 ZGC를 G1GC로 변경하면 약 150MB의 Native Memory를 절약할 수 있습니다. ZGC는 수백 GB 이상의 대용량 heap과 초저지연이 중요한 프로덕션 환경에 적합하지만, 1GB 정도의 작은 heap을 사용하는 너구디 개발 서버에서는 오히려 메모리 오버헤드가 부담이 됩니다. G1GC는 10-50ms의 pause time을 가지지만, 개발 서버에서는 이 정도의 지연은 문제가 되지 않으며, 메모리 효율성이 훨씬 중요하다고 판단했습니다. [애플리케이션 시작 vs 안정화 메모리 차이] docker stats로 확인한 866MB(56%)는 애플리케이션이 시작을 완료하고 안정화된 상태의 메모리 사용량입니다. 하지만 애플리케이션 시작 단계에서는 훨씬 더 많은 메모리가 필요합니다. 시작 단계(0-2분)에서는 JVM이 모든 클래스를 메모리에 로딩하고(+200MB), Metaspace를 초기화하며(+150MB), Spring Boot가 모든 Bean을 생성하고(+300MB), DB 커넥션 풀을 초기화하며(+100MB), 캐시를 초기화(+100MB)합니다. 이 시점의 피크 메모리 사용량은 1400-1500MB 입니다. 시작이 완료된 후(3분 이후)에는 GC가 불필요한 임시 객체들을 정리하면서 메모리 사용량이 800-900MB로 감소하여 안정화됩니다. 🤔 질문 1. GC 알고리즘 선택에 대해 1GB 수준의 heap에서 ZGC보다 G1GC가 적합하다고 판단하여 변경했습니다. 이러한 판단이 적절한지 여쭤보고싶습니다. ZGC는 어느 정도 규모의 heap부터 효과적인지 궁금합니다. 2. -Xms = -Xmx 설정에 대해 gemini 코드 리뷰에서 "서버 애플리케이션은 초기 힙과 최대 힙을 동일하게 설정하여 힙 확장 오버헤드를 제거하는 것이 좋다"는 의견을 받았습니다. 메모리가 빡빡한 상황(여유 100MB)에서 처음부터 1.2GB를 할당하는 것이 안전한 선택이 맞을까요..! 오히려 512MB로 시작해서 필요할 때 늘리는 게 더 안전한것일지 여쭤보고 싶습니다. 3. Docker 메모리 제한과 JVM heap 비율에 대해 현재 Docker 1.6GB 중 JVM heap 1.2GB (75%)로 설정했는데, 이 비율이 적절한지 여쭤보고 싶습니다. 일반적으로 권장되는 비율이 있는지 궁금합니다! 4. Native Memory 측정에 대해 현재는 관련해서 정리해둔 기술 블로그 등을 통해 (G1GC는 heap의 5%, Metaspace 100MB 등)로 추정했는데, 실제로 정확히 측정하려면 어떻게 해야 하는지 궁금합니다! -XX:NativeMemoryTracking=detail 같은 옵션을 운영 환경에서 사용해도 성능에 영향이 없을까요?! 5. 현업에서의 리소스 관리 이런 제한된 리소스 환경을 어떻게 관리하시나요?! 메모리 설정의 기준은 어떻게 정하시는지 궁금합니다! 6. 모니터링 지표 Thread Starvation을 사전에 감지하려면 어떤 지표를 모니터링해야 할까요?? 강의 내용과 연결하여 최근에 개발하면서 궁금했던 부분들을 남기게 되었습니다! 초기 스타트업에서 백엔드 개발을 하고 있는데 개발하면서 이슈가 생기면, 강의들을 보기도 하고 구글링을 열심히 하기도 하고 AI와 정말 긴 대화를 나누기도 하면서 원인을 찾고 저희 상황에 제일 적합한 해결책을 찾고있습니다. 하지만 제가 문제 상황을 맞게 파악한건지, 가장 최선의 해결책을 찾은게 맞는지 늘 더 생각하게 되는 것 같습니다. 그리고 스스로의 판단에 확신을 갖기 위해서 더욱 더 많이 공부하고 기반을 탄탄하게 해야함을 느낍니다. Thread Starvation 문제를 겪고 제가 파악하고 해결한 방법이 적합한지, 리소스 관리와 관련해서 현업에서는 어떻게 관리하고 모니터링하는지 여쭤볼 수 있는 분이 주변에 없어서 긴 글을 남기게 되었습니다 🤓 ..읽어주셔서 감사합니다 :)
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 여기에 질문 내용을 남겨주세요. flush()는 영속성 컨텍스트의 변경 내용을 DB에 반영하지만, 영속성 컨텍스트 자체를 초기화하지는 않는다고 들었어요. 그렇다면 flush() 이후에도 1차 캐시에 남아있는 엔티티의 상태는 그대로 유지되나요?
안녕하세요, 강의를 통해 대규모 시스템 설계에 대한 다양하고 실무적인 방법을 배우게 되어 감사히 수강하고 있습니다! 수강중 Transactional Outbox 테이블 관련하여 궁금한 부분이 있어 질문드립니다. 실무에서는 보통 "Outbox 테이블에 Insert -> kafka send 후 Outbox 상태 Update" 하는 방식으로 쓰일까요? 강의에서는 간단히 Delete로 구현한다고 말씀주셔서 질문드려봅니다! Update 하는 방식도 자주 쓰인다면 Outbox 테이블은 파티셔닝(p20251001 와 같이)하여 관리하고 주기적으로 삭제하는 방식일지도 궁금하여 질문드립니다!
안녕하세요 강사님! 카프카를 사용하면서 궁금한 점이 있어서요~ 예를 들어 주문 시스템을 구현한다고 하면요. 주문에 대해 상태가 계속 바뀌어 해당 이벤트를 받을 수 있도록 카프카를 붙이려고해요. consumer가 동일한 주문 id에 대해 상태 업데이트를 해야 하니, producer가 순서 보장되도록 카프카 key도 동일하게 셋팅하면 consumer는 순서대로 status를 제대로 update 하는데요. 만약 producer가 메시지 발행을 비동기적으로 진행하도록 구현했다고 하면, 무언가 이슈로 주문 생성 -> 주문 취소 순이 아닌 주문 취소 -> 주문 생성 순으로 발행되었다면 consumer 입장에서 메시지 순서가 제대로 들어왔음을 어떻게 인지할 수 있을까요..? 이런 상황은 발생하지 않을까요..? ㅎㅎ
[질문 내용] 람다 (lambda) 람다는 익명 함수 이다. 따라서 이름 없이 함수를 표현한다. (매개변수) -> {본문} 용어 - 람다 vs 람다식(Lambda Expression) 람다 : 익명 함수를 지칭하는 일반적 용어. (개념) 람다식 : (매개변수) → {본문} 형태로 람다를 구현하는 구체적인 문법 표현을 지칭 람다도 익명 클래스처럼 클래스가 만들어지고, 인스턴스가 생성된다. 함수형 인터페이스 함수형 인터페이스는 정확히 하나의 추상메서드를 가지는 인터페이스를 말한다. 람다는 추상 메서드가 하나인 함수형 인터페이스에만 할당할 수 있다. 단일 추상 메서드를 줄여서 SAM(Single Abstract Method)라 한다. @FunctionalInterface를 통하여 함수형 인터페이스를 보장할 수 있다. 추상 메서드가 추가되면 컴파일 오류 발생 ! (Ex) @Override를 통해 재정의된 함수임을 알 수 있듯이. 고차함수(Higher-Order Function) 고차 함수란, 함수를 값처럼 다루는 함수를 뜻함 함수를 인자로 받는 함수(메서드) 함수를 반환하는 함수(메서드) 기본 함수형 인터페이스 다음은 자바가 기본으로 제공하는 대표적 함수형 인터페이스이다. Function : 입력 O, 반환 O Consumer : 입력 O, 반환 X Supplier : 입력 X, 반환 O Runnable : 입력 X, 반환 X 특화 함수형 인터페이스 Function으로 구현가능하나, 테스트 용도인 인터페이스라는 것을 명확히 하기 위해 사용 Predicate : 입력 O, 반환 boolean 조건 검사, 필터링 용도 Operator (UnaryOperator, BinaryOperator) : 입력 O, 반환 O 동일한 타입의 연산 수행, 입력과 같은 타입을 반환하는 연산 용도 추석 완강 챌린지 중 질문드리고 싶으나, 아직 완벽히 이해된 단계가 아니어서 부득이 복습하며 정리한 내용을 질문으로 작성했습니다. ㅠㅠ 틀린 부분 있다면 지적 부탁드립니다!
<c:out>을 사용하면 HTML의 특수문자가 포함되있을 경우 HTML을 해석하지 않고 출력한다는데. HTML은 특수문자를 태그로서 가지고있는 마크업 언어인데... 이게 무슨말인지 이해를 잘 못하겠어요... 인터넷의 다른 블로그 글을 봐도 거의다 똑같은 설명이라... 그냥 있는 그대로 출력을 한다는건지 HTML태그 안의 내용을 출력한다는건지 아리쏭 합니다.. 그리고 Spring에서 Beans으로 등록한다는 의미가 스프링에서 자체적으로 관리를 한다?고 이해하고 있는데... 자바를 배우고 바로 spring으로 넘어와서 그런지 servlet의 개념도 어렵습니다... 어디서 부터 손봐야할지 모르곘어요.... 죄송함니다..
강의 잘 듣고 있습니다! 강의를 듣던 중 궁금한것이 있는데요. 예를 들어 결제 API를 만든다면: - 금액, 결제수단: 필수 - 할인쿠폰, 메모: 선택 @Builder를 사용할 때 필수 파라미터 처리가 궁금합니다. 결제 API 같은 걸 만든다면 금액은 필수인데, @NonNull은 런타임 체크로 알고 있는데요. 프로그램을 실행해야 에러를 확인할 수 있었습니다. 필수 항목을 빠뜨리면 컴파일 에러가 나게 할 수는 없나요? 실무에서는 런타임 체크로 충분한가요, 아니면 중요한 객체는 컴파일 타임 체크를 위해 직접 구현해야 할까요?
킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워 FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게 1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다. 2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다. 3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor() 를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다. 내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야 Q1. BeanWrapperFieldExtractor 일 경우 필드 하나를 제외하고 싶다면, names() 에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까? 고마워 킬구형아
안녕하십니까 ? 현재, 실전 자바 중급 2편을 듣고 있는 2년차 개발자입니다. 평소에 아무런 생각없이 사용하고 있던 자료 구조들에 대해 공부하게 되니까, 어떻게 사용해야하는 지와 왜 해당 자료구조가 시간복잡도 상 좋은 지에 대해 알 수 있어서, 새롭게 느끼고 있습니다. 혹시, 자바 관련해서 강의를 더 듣는 다면, 어떤 강의가 실무에 도움될지 궁금해서 여쭙습니다. 혹시나 더 추천하는 강의가 있으실까여?
