안녕하세요. 좋은 강의 감사합니다.값 객체에 대한 내용을 듣고 궁금했던 점이 있었는데, 섹션 4 퀴즈를 풀면서 해소되는 동시에 새로운 질문이 생겼습니다.값 객체를 사용하는 메소드를 과도하게 호출하여 OOM(Out of Memory)이 발생할 것으로 예상되는 경우, 이를 어떻게 회피할 수 있는지 궁금합니다.아직 강의를 전부 듣지 않아서 이후에 나올 내용일 수도 있겠지만, 지금 드는 생각으로는 Map을 이용해 내부적으로 캐시를 구현하여 메모리 사용량을 줄이는 방법이 떠오르는데, 이 접근법이 맞을지 궁금합니다.

서버단에서 받은 액세스토큰을 프론트담당은 React의 전역 상태 관리(Context, Recoil, Zustand, Redux 등) 를 통해 메모리에 저장하고 사용한다고 하던데 상태 관리 라이브러리 중 어떤 걸 실무에서 주로 사용하나요?

강의를 복습할 때, 저 스스로 진도 체크를 하지 않으면 진도 체크가 불가능한 상황입니다. 그래서 진도 체크가 가능하게 강의 진도 초기화같은 기능을 출시할 계획이 있나요?

킬구형 텍스트 강의임에도 몰입감 있는 구성에 연휴에 재밌게 공부하고 있어. 고마워FlatFileItemWriter에 대한 흐름을 정리하고 질문 해볼게1. sourceType() 메서드 내 객체 타입에 따라 FieldExtractor 구현체가 결정된다.2. (Bug가 fix되기 전까지) sourceType() 메서드 내 객체 타입이 Record일 경우 names() 메서드 호출은 무시되고, Record 타입의 모든 property가 쓰일 수밖에 없다.3. 그렇기에 Record 타입에서 필드 하나를 제외하고 파일을 쓰고싶다면, fieldExtractor()를 사용한 커스텀 구성을 통하여 필드 하나를 제외해야 한다.내가 강의를 보면서 정리한 흐름이고, 아래는 그 정리 중 나온 질문이야Q1. BeanWrapperFieldExtractor일 경우 필드 하나를 제외하고 싶다면, names()에서 해당 필드만 제외해도 되나? Q2. 만약 위와 같은 방법이 된다면, RecordFieldExtractor 관련 Bug가 fix 된 후에 FieldExtractor를 직접 커스텀하는 경우가 별로 없지 않을까 싶은데.. 혹시 내가 생각하지 못한 부분이 있을까?고마워 킬구형아

안녕하세요. 이제 막 자료구조와 알고리즘을 알아가고 있습니다. 선생님의 강의 덕분에 천천히 음미하며 재밌게 수업을 듣고 있습니다. 혹시 이런 제게 추천할 만한 자료나 사이트가 있으실까요?

이번 강의에서 아키텍처 설명과 interface를 활용해 계층 간 의존도를 끊는 방법을 보며 시야가 넓어지는 느낌을 받았습니다.토비님은 새로운 프로젝트를 시작하거나 기존 코드를 리펙토링할 때, 어떤 기준으로 아키텍처를 선정하는지 궁금합니다.팀원들의 지식 범위나 프로젝트의 뱡향성, 개발 속도 등 여러 요소 중 어떤 부분을 더 중요하게 고려하시는지도 듣고 싶습니다.

안녕하세요 DeFi 개발자가 되기 위해 이 강의 이후로 또 추천해주실만한 강의가 있을까요?

안녕하세요 강사님!아직 완강은 아니지만 너무 재밌게 잘 보면서 많이 배우고 있습니다! 이번 강의를 보다가 궁금한 점이 생겨 질문을 남깁니다!강의에서 제시해주신 조회수라는 정보가 게시판이라는 도메인으로 보았을 때 비교적 중요하지 않다고 하신거에 충분히 동의합니다!근데, 문득 조회수를 통해 수익이 발생하는 서비스(ex. 유튜브)에서는 중요한 정보 아닌가? 라는 고민이 생겼습니다. 중요한 정보인데 쓰기가 자주 발생하는 상황에서 In-Memory 저장소를 메인으로 사용하고 RDB를 백업용으로 사용하면 위험하지 않나? 라는 생각이 들었습니다!이럴 때에는 보통 어떻게 처리하시나요? (이럴 때 NoSQL을 사용하나요?) 

안녕하세요! 영호님. 강의 잘 듣고 있습니다.  현실적으로 DB 스키마가 이미 정해져 있거나, 기존 데이터를 마이그레이션해야 해서 새롭게 설계하기 어려운 경우, 또는 DBA가 별도로 관리하는 환경에서는 책임주도 설계를 적용하기가 쉽지 않을 것 같습니다. 이런 상황에서도 객체지향적인 설계를 현실적으로 적용할 수 있는 방법이 있을까요?(DAO를 중간 계층으로 두면 어느 정도 해결될까요? 아니면 도메인 레이어와 퍼시스턴스 레이어는 분리된 영역이니 크게 상관없을까요? 반대로, 두 레이어가 지나치게 달라지면 오히려 유지보수가 더 어려워지지는 않을까 하는 걱정도 듭니다.)그리고, 책임주도 설계가 이론적으로는 유지보수에 강하다고 하지만, 실제로는 아직 구조가 다소 복잡하게 느껴져서 오히려 유지보수성을 해칠 수도 있지 않을까 합니다. 이런 복잡함은 설계 패턴에 익숙해지면 자연스럽게 해소될까요?감사합니다!

안녕하세요 :)저는 게임 개발자를 희망해서 C#으로 코테를 준비하고 있습니다. C#에는 기본 제공 PriorityQueue가 프로그래머스 환경에서 지원되지 않는데, Python이나 C++처럼 heapq나 priority_queue를 쓸 수 없는 경우 어떻게 대비하는게 좋을지 여쭙고 싶어 질문드립니다!

4.2) 첫 React App 생성하기 강의 질문 입니다.10:15에서 module.exports = { … } 로 시작하는데 이건 cjs 시스템 문법으로 알고 있는데, 5:14에서 나오는 package.json의 type은 module로 되어있는데 두개의 시스템을 동시에 사용하는게 가능한건가요?

안녕하십니까 ?현재, 실전 자바 중급 2편을 듣고 있는 2년차 개발자입니다. 평소에 아무런 생각없이 사용하고 있던 자료 구조들에 대해 공부하게 되니까, 어떻게 사용해야하는 지와 왜 해당 자료구조가 시간복잡도 상 좋은 지에 대해 알 수 있어서, 새롭게 느끼고 있습니다. 혹시, 자바 관련해서 강의를 더 듣는 다면, 어떤 강의가 실무에 도움될지 궁금해서 여쭙습니다. 혹시나 더 추천하는 강의가 있으실까여?

Relay는 React 개발팀이 만든걸로 알고 있는데요! 그래서 더 매력적이라고 느껴지는데 어떤 특징과 장단점으로 Apollo로 강의를 진행하게 되셨는지 궁금합니다. 다른 클라이언트들 대비해서 어떤지도 궁금하네요!

안녕하세요~! 궁금한 점이 생겨 문의드립니다! DOM + CSSOM > Render Tree를 만들기 때문에 CSS 배치에 따라 CRP에 영향을 주는 것까지는 이해했는데요! script는 async 또는 defer 속성을 알맞게 적어주기만 하면 실행 순서만 보장이 되고 안되고의 차이이고 CRP에는 영향을 주진 않는건가요?

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? 예2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예[질문 내용]Spring에서 SessionScope와 RequestScope는 실제로 어떤 관계로 동작하나요?예를 들어, 사용자가 로그인되어 세션이 유지되는 동안에도, 각 요청(Request)마다 RequestScope 빈이 새로 생성되는 구조인가요?아니면 JWT 기반 인증처럼 세션과 관계없이 매 요청마다 인증 로직이 수행되는 방식인가요?또 실제 실무에서는 로그인한 사용자의 상태를 SessionScope로 유지하면서 RequestScope 빈을 함께 사용하는 경우가 많은지도 궁금합니다.

선배 개발자로서 알려주시는 강의 내용들이 정말 좋았는데요, 그와 더불어 앞으로 주니어 백엔드 개발자로서 어떤 역량을 조금 더 집중해서 키우면 좋을지 조언을 부탁드리고 싶습니다.또, 아직 이를 수도 있지만 이직을 준비할 때 도움이 될 만한 공부 방향이나 추천해주실 만한 책이 있다면 알려주시면 감사하겠습니다. 강의 중간중간 소개해주시는 책들이 많아서 최근에 또 추천해주실 책이 생기셨는지 궁금합니다.

[질문 템플릿]1. 강의 내용과 관련된 질문인가요? (예/아니오)2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오)3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오)[질문 내용]Spring Data JPA에 있는 인터페이스를 사용하는 경우가 많이 보이는데 강의에서는 EntityManager를 주입받아서 직접 구현하는 방식으로 설명해주신 이유가 궁금합니다.

이터레이터 패턴에서 이터레이터가 나왔고이터레이터는 컨테이너 순회(특히 맵 순회)를 쉽게 할 수 있게 한다. 제가 이해한 게 맞을까요?

안녕하세요!덕분에 아키텍처에 대한 큰 그림을 그려보며 강의를 듣고 있습니다. MSA 전환 시점 관련해서 질문 드립니다.모놀리식 아키텍처에서 MSA로 전환하는 적절한 시점은 어떤 기준으로 잡는게 좋을까요?물론 상황마다 다르겠지만, 강사님은 어떤 기준을 가장 중요하게 생각하시는지 궁금합니다.예를 들어, Scale-out 한계, 빌드&배포 시간 증가, 혹은 서비스 크기와 복잡성 같은 요소들.. 이 있을 것 같은데 제가 미처 생각 못한 부분이 있다면 덧붙여 답변 부탁드립니다.감사합니다!

회사 규모상 프로젝트를 혼자서 개발하는 경우, 강의의 내용을 적용해서 도메인 문서를 만드는 것이 개발에 대한 정리나 추후 다른 사람이 봤을 때 도움이 될 수는 있으나, 당장 시간에 쫓기기도 하고 다른 사람의 피드백 없이 혼자서 정리하다 보면 잘 정리하기 힘들다는 생각이 되는데요. 이런 상황에서의 정리는 오히려 도움이 안될 수도 있다는 생각이 드는데, 토비님께서는 어떻게 생각하시는지 궁금합니다.