안녕하세요, geek님. 영상 16:55~ 부분에서 설명해주시는 conflict를 해결할 수 있는 방법에 대해서 다음 네 가지를 설명해주셨습니다. main 브랜치 쪽 diff를 더한다. test 브랜치 쪽 diff를 더한다. (선택됨) 둘 다 더한다. 둘 다 더하지 않고, 아예 다른 내용을 적는다. 그리고 예제에서는 2번 방식을 선택해주셨고, 이에 따라서 머지 커밋은 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) + test 최신 커밋과의 diff( blue ) 즉, 3개가 더해져서 만들어지는 커밋인데요. 이로 인해 3-way merge라는 이름으로 불린다고 이해했습니다. 여기서 질문이 생기는데요. 만약 1번 방식을 선택한다면, 머지 커밋이 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) 즉, 2개가 더해져서 커밋이 만들어집니다. 그런데 앞서 말씀하신 내용을 고려하면 머지의 세부 명칭(예를 들어 3-way merge같은)에 영향을 주는 요소는 '커밋 히스토리의 모양'입니다. 따라서 2개가 더해져서 커밋이 만들어지는 이 상황도 여전히 3-way merge라고 부를 수 있습니다. 그래서 처음 들었던 의문은 "1번 방식을 택했을 때는 2개가 더해지는 건데, 이때도 3-way라고 부르는 것은 그냥 관례적인 표현인가?" 입니다. 그리고 질문을 작성하면서 제가 스스로 내린 답변은 "더하는 개수가 3개여야 하는 것이 아니고, 더할지 말지 고민하는 기준점이 3개 인 상황이라 3-way라는 이름이 붙은 것 같다" 입니다. 즉, 커밋 히스토리가 예제와 같은 상황에서는 다음 3가지 를 기준점으로 사용하게 됩니다. 두 브랜치의 공통 부모 (base) main 브랜치의 최종 커밋 test 브랜치의 최종 커밋 각 기준점에 대해 어떤 판단을 내리느냐에 따라 세 개를 더하는 2번 상황이 되거나 두 개를 더하는 1번 상황이 되거나, 또 다른 3번, 4번 상황이 될 수도 있습니다. 하지만 '기준점이 3개'라는 사실을 모든 상황에서 동일하기 때문에 3-way merge라는 이름이 붙여진 것으로 판단했습니다. 가르쳐주신 내용에 혼란을 느낀 부분을 서술하느라 글이 좀 길어졌는데, 결론적으로 '기준점이 3개라서 3-way merge라고 부른다'는 제 판단이 적절한지 여쭤보고 싶습니다.
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 출력이 나오는 문제에서 항상 이 두 개를 고려하곤 하는데 가끔은 기준이 안잡혀서 고민입니다
현재처럼 서비스 구조가 거의 테이블 단위로 DB와 API 서비스가 분리될 때, 이런 구조에서 화면에서 리스트 형태로 두 도메인 데이터를 함께 조회해야 하는 경우가 있을 것 같습니다. 예를 들자면 게시글과 게시글 조회 수를 함께 보여주는 리스트 API가 필요한 상황에서, 단건 조회라면 프론트에서 별도로 API를 호출해도 괜찮을 것 같은데, 페이징 처리나 리스트 형태로 여러 데이터를 묶어서 조회해야 할 때, 실무에서는 보통 한 서비스에서 다른 서비스를 RestClient(Feign 등) 로 호출해서 데이터를 합치는 방식으로 처리하는지, 아니면, 같은 도메인 서비스로 묶어버린다던지 아니면 프론트엔드에서 각각의 API를 호출한 뒤 병합하는 방식으로 처리하는지 궁금합니다. 실제 현업에서는 이런 경우 어떤 접근 방식을 주로 사용하나요?
실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)
fetch join 부분이 조금 어렵게 느껴져서, gpt에게 물어보며 공부했습니다. 강의에서 fetch join으로 나온 중복 데이터를 DISTINCT 키워드를 이용해서 제거해주시는 부분을 보았는데, gpt가 다음과 같이 설명해주는 것을 보았습니다. DISTINCT 키워드가 SQL과 JPA 양쪽에서 다르게 동작하기 때문에 완전한 중복 제거가 보장되진 않습니다. 이 말이 맞다면 현업에서는 이런 문제를 어떤 식으로 해결하는지 궁금합니다!
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 중첩 클래스를 학습하다 보니 실무에서도 종종 쓰일까 생각이 들었습니다.(쓰니까 있지 않을까 싶습니다?) 예시로 Member, Role 과 같은 객체가 있을 때, 이 관계를 중첩 클래스로 표현하는 게 더 합리적일까요? 부족하다 보니 이런 고민이 드네요!(코드와 주관에 따라 다르겠지만 일반적인 경우로 가정)
안녕하세요. 좋은 강의로 덕분에 webflux에 대해 쉽게 이해할 수 있었습니다. 저는 현재 kotlin으로 개발하는 프로젝트가 있어, webflux를 사용할때는 coroutine을 함께 사용하는데요, 이렇게 하면서 코드를 함수형처럼 짤 수 있어 보다 쉽게 동료들에게 보여줄 수 있었습니다. 혹시 강사님께서도 coroutine을 함께 사용하기도 하시는지, 그렇다면 java가 아닌 kotlin을 사용한 강의 계획이 있는지 궁금합니다. 또한, 강의에서 쉽게 설명해주셨지만 비즈니스 로직이 좀 더 추가되는 경우 코드가 많이 복잡하고 가독성이 어려워지던데, 가독성을 위한 팁들이 있는지 궁금합니다. ps. webflux 2 프로젝트에는 사용 가능한 gmemini api key가 입력되어 있습니다. 😅
학습 관련 질문을 최대한 상세히 남겨주세요! 고민 과정도 같이 나열해주셔도 좋습니다. 먼저 유사한 질문이 있었는지 검색해보세요. 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. 안녕하세요. 향로님의 추석 챌리지에서 우연히 제목을 보고 바로 구매했는데 아직 완강하지는 못했지만 정말 좋은 강의 같습니다! 선배 개발자님이 개발하시는 느낌으로 보고있습니다! ㅎㅎ 궁금한 점은 혹시 실무에서도 이런식으로 서브쿼리를 이용해서 대규모 데이터에 대해서 처리를 하는지가 궁금해져서 질문 남겨봅니다!
강의에서는 H2 인메모리 DB를 이용해 테스트를 진행하셨는데, 실무에서는 테스트 환경에서 실제 MySQL이나 PostgreSQL 같은 실제 운영 DB와 동일한 컨테이너 기반 테스트 DB를 사용하는 경우도 많은 것 같습니다. 실무에서는 인메모리 DB와 컨테이너 DB 중 어떤 상황에서 어떤 것을 선택하시는지, 선택 기준이나 장단점에 대해 조언을 받을수 있을까요?
안녕하세요 강사님. 강의에서 Path Enumeration 방식을 활용해 데이터베이스 조회 성능을 최적화하는 방법을 매우 유익하게 배웠습니다. 실제 대규모 서비스 환경에서 이 조회 결과를 Redis로 캐싱하려고 할 때, 캐시를 저장하는 자료구조 선택에 대해 강사님의 의견을 듣고 싶습니다. 현재는 Path를 기반으로 DB에서 계층 구조를 유지하며 정렬된 댓글 목록을 조회하고 있습니다. 이 결과를 Redis에 저장하는 방법으로 아래 두 가지를 고려하고 있습니다. 1. List 구조 (LRANGE) 장점: DB에서 조회한 정렬 순서를 그대로 Redis에 저장할 수 있어, 조회 시 한 번에 가져올 수 있습니다. 고민: CUD(특히 중간 삽입) 발생 시 전체 List를 삭제하고 DB에서 다시 조회해 재저장해야 하므로 비효율적일 수 있습니다. 2. Sorted Set 구조 (ZADD) 장점: 각 댓글을 멤버로 저장하고 Path 값이나 정렬 기준을 score로 부여하면, CUD 발생 시 해당 멤버만 ADD/REMOVE로 처리할 수 있어 갱신이 효율적입니다. 고민: Path 기반의 정렬 값을 Redis의 score로 매핑하는 과정이 다소 복잡합니다. 이처럼 캐싱 로직의 구현 복잡도(Sorted Set)와 갱신 효율성(List의 TTL 전략) 사이의 균형을 고려할 때, 강사님께서는 무한 depth 댓글 구조를 캐싱할 때 어떤 Redis 자료구조가 더 적합하다고 생각하시는지 궁금합니다. 감사합니다.
안녕하세요 ! 강의 잘 듣고 있습니다. 최근 OutBox 패턴을 사용해보려고 시도중입니다 ! CDC도구를 사용하지않고 어플리케이션에서 폴링을 구현한다고 하였을 때 폴링전용 어플리케이션을 따로 두어야 하는지 궁금합니다. ex) 주문서버에서 DB에 저장 -> 폴링 서버에서 DB에 저장된 이벤트를 폴링으로 조회 후 메시지 발행 이렇게 생각한 이유는 주문서버에 폴링을 구현한다면 스케일 아웃 상황에서 폴링 로직도 저절로 스케일아웃되기때문입니다. 여러개의 폴링 로직이 같이 돌아가면 데이터가 꼬일 수도 있지 않을까 합니다. 어플리케이션 폴링구조의 outbox 패턴 구현에 대한 정석이 있는지 궁금합니다.
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예) [질문 내용] 강의를 듣다가 궁금한 부분이 있어 질문 드립니다. this 와 super의 호출 순서는 왜 중요한가요? 개념으로 이해하기에는 부모에 해당하는 super가 있어야 자식에 해당하는 this 를 호출할 수 있다고 생각하고 있습니다. top -down으로 이해하고 있는데 이것외에도 중요한 이유가 있을까요?
실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)
안녕하세요. 수업 내용과는 크게 관계가 없지만... 예외처리 관련 내용에 대한 질문을 드립니다. 스프링이 제공하는 표준 예외( IllegalArgumentException , IllegalStateException )와 비즈니스 로직을 표현하는 커스텀 예외( NotFoundUserException ) 사이에서 표준 예외를 사용하는 경우와 커스텀 예외를 사용하는 경우에 대한 기준을 알 수 있을까요? 감사합니다.
안녕하세요, 강의 잘 듣고 있습니다. Git을 정리하는 데 큰 도움을 받고 있습니다. 다름이 아니라 GitHub에서 브랜치를 메인 브랜치로 병합할 때 사용하는 전략에 대해 궁금합니다. 기본 병합(merge), 스쿼시 & 머지(squash & merge), 리베이스 & 머지(rebase & merge) 방식이 있는데, 어떤 방식을 선호하시는지 여쭤보고 싶습니다. 개인적으로는 로컬에서 작업할 때는 리베이스 & 머지 를 선호합니다. 히스토리를 깔끔하게 유지할 수 있기 때문입니다. 반면에 메인 계열 브랜치(dev, prod 등)로 병합할 때는 기본 병합 을 사용해야 기능 추가 히스토리를 명확히 추적할 수 있다고 생각합니다.
안녕하세요. 빈약한 도메인 모델에 관하여 질문이 있습니다. 현재 개인적으로 진행하는 프로젝트에서 데이터 홀더 역할정도만 하는 빈약한 도메인 모델이 있습니다. repository에는 테이블의 상태 컬럼을 업데이트하는 메소드가 존재하는데 이를 도메인 모델 내부에 메소드를 만들어 업데이트하고 repository의 save를 통해 엔티티의 상태를 update하는 것이 강의에서 의도한 내용으로 이해했는데 맞을까요? 추가로 이런 경우(비즈니스 로직이 복잡하지 않은)에 꼭 도메인 모델이 없어도 될지 궁금합니다.
