Видео

이렇게 꾸준히 하신다는 것 자체가 너무 대단하십니다. 영상 퀄에비해 구독자랑 조회수가 너무 적은 것 같네요. 내년에는 입소문타서 흥하는 채널이 되기를..!

1만 기념 오프라인 모임 기대가 됩니다

왜 구독을 안누르지 ?😢

구독자 수 지금이 저점이네요. 아마 같은 영상 여러번 보는 사람이 많은 것 같아요! 조금 길어도 많이 돌려보게 됩니다.

제미니님 덕에 회사 내 멀티모듈 프로젝트 운영 관리 하는데 있어서 많은 인사이트 얻었고 실제로도 적용한 부분이 몇개 있곤합니다. 덕분에 꽤나 많이 꼬였던 프로젝트가 그나마 조금은 볼만해졌네요.. ㅎㅎ 앞으로도 개선해야할것들이 많이 남긴 했지만요! 2024년도 남은 이틀 마무리 잘 하시고 2025년에는 가정에서나 일에서나 모든면에서 더욱더 원하시는 일 잘 되시길 바라겠습니다.^^ 미리 새해 복 많이 받으세요!

제미니님 쵝오

1등 댓글!

크지 않은 규모의 프로젝트에 주니어 1명과 중간급 1명이 투입되서 개발하는데 프로젝트를 이끌어 가는 중간급이 시작부터 모노레포 + 클린아키텍처를 도입하는걸 봤는데요, 주니어 1분은 레이어드도 잘 모르시던 분이었어요 결국 그 프로젝트는 2인으로 시작했으나 커밋은 중간급분만 거의 혼자 하고 있고, 그분 나가시고 그 프로젝트를 감당할 분들이 없어서 결국 레이어드로 갈아 엎어버리는 경우를 옆에서 지켜보면서 많은걸 느꼈습니다 ( 저는 프론트라 옆에서 지켜봄 )

예전부터 쭉 보면서 정말 많은 인사이트를 얻어갑니다. 아직 주니어라 많은 부분을 이해하기엔 힘들지만, 저도 영향을 받아 지속 성장 가능성에 대해서 중요하게 생각하게 됐는데 그 앞에 함께를 붙이니 많은 것들이 어렵게 느껴졌습니다. 그래서 요즘은 함께 지속 성장 가능한 소프트웨어를 만드는 법, 혹은 함께 지속 성장 가능한 소프트웨어를 만드는 팀이 되는 법에 대해 많이 생각하게 됩니다 :).. 남은 한 해도 잘 마무리 하시고 항상 건강하시길 바랍니다

repository pattern과 그보다 벗어나는 넓은 범위의 읽기 dao에 대한 로직을 분리해서 사용했을때에 대한 이야기가 맞을까요? 뭔가 도구레이어, reader,writer라는게 본적없는 말이다 보니까 덜 와닿는 부분이 있네요 그리고 implementation layer는 구현계층이 맞지 도구레이어라고 하면 오히려 혼란줄거 같네요

안녕하세요 재민님 채널을 알게된지 얼마 안되었는데, 실무 경험이 부족한 제게 큰 도움이 되는 것 같습니다. 항상 감사합니다. 쩌스트라는 프로젝트를 하신다길래 검색해서 봤는데 open api로 도서 데이터를 활용하시는 것으로 보이더라구요. 혹시 재민님은 도서 데이터를 배치 돌려서 내부 db에 저장하는 형태로 구현하셨을까요?? 저도 도서 관련 개인 프로젝트를 하고 있는데, 처음에는 제 db에서는 isbn값만 관리하려다가, 다건 조회나 책정보를 함께 가져오는 상황이 많아서 서버로 요청이 들어왔던 isbn에 해당하는 도서정보는 외부 api 호출해서 db에 쌓고 있으면 호출 없이 정보를 반환해주고 있거든요. 외부 데이터를 어떤 방식으로 관리하는 게 좋을지 고민이 많아 댓글 남기게 되었습니다 영상으로 설명해주신 내용이 지금 제가 하는 작업에 많은 참고가 되었습니다 감사합니다

역할과 책임..!! 점진적 개선... 한번에 완벽할 수 없다 😮😮 긴영상 귀하네요 오늘도 잘 보고 갑니다 😊

오늘도 쓰지말자 시리즈 잘봤습니다 ㅎㅎ 저도 물론 제미니님의 글을 보고 인사이트를 얻었지만, 기본적으로 '지속적, 성장가능한' 이라는 목표가 있고 그럴 가능성이 있는 프로젝트를 진행할 때 추가적인 레이어를 도입해야 한다고 생각했습니다. 그리고 레이어를 도입해서 인프라 - 비즈니스 간에 의존성을 낮추어 비즈니스 로직이 변경되야 하는 이유(ex. 기본적인 요구사항의 변경)가 적어도 외부에 의해서 변경되면 안되겠다고 생각해서 implement 레이어를 도입했습니다. 좋은 영상 감사합니다 ~

OOP 에서 말하는 도메인모델들을 구현 레이어에 놓는다 라고 이해했습니다 OOP 의 중요성을 오늘도 느끼고 있습니다

저도 구현 레이어인줄 알았는데 아니었군요..부끄럽네요 여러모로 반성하게 되는 영상이네오 감사합니다!

작은 회사에서 레이어 컨벤션을 만들어가는데 항상 큰 인사이트를 얻습니다. 배워가는 걸 "고민하면서" 쓸 수 있도록 노력해야겠네요.

오늘도 잘 보고 갑니다 : >

핵심은 무지성으로 만들지말고 프로젝트 상황에 맞춰 사용하자네요. 그리고 다른 영상에서도 공통적으로 전달하시려는 메시지가 "소프트웨어" 이기 때문에 그 환경, 프로젝트에 맞게 설계하고 구현하자가 맞는거 같네요. (정답은 없다!) 오늘도 좋은 인사이트 얻고 갑니다.

좋은 영상감사합니당 :) 설득의 근거가 아니라 핑계거리를 찾는 사람이 많은 것 같아요

common의 저주는 꼭 기억해둬야겠네요 호호호..

안녕하세요 제미니님 항상 영상 즐겨보고 있는 구독자 1인입니다 ㅎㅎ 말씀하신 내용중에 나혼자 개발하는게 아닌, 함께 일하는 구성원들과 환경에 따라 유지보수가 용이하게 구조를 가져가야한다는 말이 너무 공감되서 글 남겨요! 과거에 부끄럽지만 함께 일하는 동료분들의 눈높이에 맞추기 보다 잘못되어있는 패키지 구조가 있다면 자체적으로 바꿔보는 등 여러가지 시도를 많이했었는데 연차가 쌓이고 돌이켜 생각해보니 제가 떠나도 과연 제가 변경하거나 추가했던 구조를 문서화 해두더라도 유지보수할 수 있는 환경이었나? 라고 생각하면 제대로 고려를 못한것 같아 반성하게 되더라구요 ㅠㅠ 이번 올려주신 영상을 통해 다시한번 되돌아보고 다짐하게 되는 계기가 되는 영상인것 같아요 항상 좋은 내용 제공해주셔서 감사합니다 ! ㅎㅎ

스타트업에 1년정도 근무한 입장에서 너무 공감이 가네요.. 그런데 혼자 끙끙대지 않고 질문을 바로바로 했을 때 이것을 같이 고민해주는 사람이 아무도 없는 경우가 많아 힘드네요.. 회사 분위기도 중요한 것 같습니다. 나름대로 혼자 여러방면으로 고민하고 질문을 해도 돌아오는 대답은 "나도 몰라요 구글에 검색해보세요"밖에 없었고, 잘 모르는 부분에 대해서 능력으로 평가하기도 하더라구요. "이전회사에서 ~ 이렇게 했다"가 안좋다는 것은 굉장히 와닿네요.... 제가 많이 당하고 있기 때문에.

안녕하세요! 백엔드 개발을 공부하고 있는 취준생입니다! 사이드 프로젝트 경험밖에 없어 영상과 같은 모듈 구조를 처음보는데 모듈마다 어떤 기능을 담당하는지, 모듈들이 합쳐져 하나의 서버가 되는지 아니면 각 모듈별로 서버가 있는지 궁금합니다!

안녕하세요 재민님 좋은 영상 감사합니다! 영상속에서 2가지 질문이 있어서 댓글을 남기게 되었는데요! 1. 만약, 영상속 예시의 QnA에서 요구사항으로 QnA List가 필요할 경우에는 List<QnA> 를 만들기 위해서 Question과 Answer 리스트를 각각 jpa로 조회하고 조합(mapper)하는 방식으로 사용하시는 걸까요?! 2. 1의 상황에서 추가 요구사항으로 Question의 Provider와 Answer의 Provider 가 id값이 아닌 username이 필요하다면, Answer와 Question에서 필요한 Provider의 id 값들을 추출하여 (ex. Set<Long>) Provider 정보를 조회(ex. findAllByIds)하고 mapper를 통해 조합하여 QnA 리스트를 만드는 방식을 사용하는 걸까요??? 항상 좋은 영상 다시 한번 감사합니다!! (__)

내가 만든 소프트웨어가 살아있다는 라는 말이 뭔가 뭉클하네요.ㅎㅎㅎ 개인의 성장도 중요하지만, 급여를 받는 입장에서 회사구성원을 위한 배려도 중요하다고 배우네요 감사합니다 : >

서비스 로직에서 사업용 아이템들이 대부분.. 정리되어야 하는데 현실은 기본적인 로직들이 마치 서비스인것마냥 ... 널부러지죠

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ진짜 회상하시고 참으면서 말씀하시는게 느껴지네요ㅋㅋㅋㅋㅋㅋㅋ

솔직히 퇴근때 걸으면서 듣기만 할때가 많은데 개발자 라디오처럼 해도 좋을만큼 목소리도 좋고 이해도 잘되용

저도 이 부분 고민이 많았는데 영상 올려주셔서 감사합니다. 항상 잘 보고 있습니다. ㅎㅎ

항상 차분하고 자세한 설명 잘 듣고 있습니다. 좋은 말씀 감사해요.😀

🎉공감합니다. 자신이 작성한 공통기능이 사방팔방으로 퍼졌을때 조그마한 변경사항으로 수없이 뒤엎어 볼때 비로소, 난 공통의 저주안에 있구나 란걸 오랜후에 깨닳게 되는것 같습니다. 어디선가 본 내용을 상기시키게 되서 고맙네용.. 질문이 하나 있습니다. Kotlin, TS 기반 개인라이브러리(maven: kt-support, npm:ts-support)를 dart 패키지(pub.dev:dart_support)로 마이그레이션 중인데, 제가 사용하는 공통같은 base 패키지 이름이 'support' 인데, 꽤나 이것도 좀 저주스멜이 풍깁니다. 어떻게 보시나요? 부연설명으로 support 하위로 domain, infra, application, lang, 등의 서브패키지가 있고, 주요한 요소들로는 핵사고날패턴관련 인터페이스 또는 추상모델클래스, 추상메모리저장소클래스, 외부라이브러리 관련 추상화인터페이스, 원시타입 유틸함수 같은게 있습니다. 구성해보면서 시간이 많이 들거나 자꾸 어디에 어느 함수를 support 하위에 넣어야 하는걸까? 하는순간 시간소요도 꽤 됬던거 같구요, 과거에 작성한 구조를 변경하기도 하고, 괭장히 소모적이라 느끼고있네요 ㅎ ps. 아.. 생각해보니 support 내 폴더를 라이브러리화 할땐 support 가 라이브러리 프로젝트의 루트로 해놨습니다. 이건 또 커먼 라이브러리의 저주라고도 할 수 있을까요?ㅎㅎ

안녕하세요! 예제에선 restdoc을 사용하고 있는데요. swagger, restdoc 등 여러가지 문서화 프레임워크 중에 restdoc을 가장 선호하시는지, 그렇다면 그 이유는 무엇인지 궁금합니다! 혹, 여유 있으실 때 간단하게 답변주시면 정말 감사하겠습니다. 미리 감사드립니다. ( _ _ )

처음 프로젝트 생성시에 필수로 들어가야 하는 모듈은 무엇이 있을까요

오우 이 시간에,,,

안녕하세요! 저번에 답변 주신 내용 재밌게 잘 들었습니다! 이번에도 염치불구하고 현재 사이드프로젝트 중 궁금한점 질문 남깁니다! 1. 동일한 비즈니스 객체 내에서 중복된 코드는 명시적으로 남겨두는 편이신가요? 아니면 private 메서드로 빼는 편이신가요? 완벽히 동일한 기능을 할것이라고 생각해서 메서드로 빼놨다 추후 생긴 기능으로 인해 한줄만 다른 동일한 로직을 만들었던 기억에 여쭤봅니다! 2. 비슷한 맥락일수도 있을거같은데, 입력 객체 검증 외에 서비스 레이어에서 발생하는 검증으로 인한 throw exception은 어떻게 처리하시는 편인가요? 지극히 개인적인 생각이지만, 서비스 레이어에서 명시적으로 남겨놓는것이 좋다고 생각하면서도, 로직의 명료함이 떨어지는것 같다고 생각이 들었습니다 하지만 따로 해당 서비스레이어의 검증 객체를 생성하자니, 불필요한 레이어가 추가된다고 생각되서 질문드립니다! 영상 항상 잘 보고있고 추운 날씨 감기조심하세요! 감사합니다

저같은 경우는 공통으로 뽑으려는 녀석이 "비즈니스적인 요소를 포함하는가" 를 기준으로 삼고 있습니다. 비즈니스 요소를 포함하는 녀석을 공통이라고 생각해서 빼려고 하는경우 대부분이 응집이 잘못된 케이스가 상당히 많았거든요

안녕하세요 제미니님 쓰시는 노트북 상세 스펙 알 수 있을까요?

영상 속 예시 api/v1/users/{userId}/orders 에서 user를 묵음으로 처리한다면 api/v1/orders?userId={userId} 의 형태로 처리하게 되는 건가요?

이번 에피소드는 주제랑 내용이 너무 이상하네요... 누가 멀티모듈을 만든다고 구현이 잘될거라 생각한다는건지.. 실제 그런 사람이 있는지 궁금합니다.

구현레이어에서 XXManager, XXProcessor 의 클래스는 보통 어떤 책임을 가지나요?

이번 영상 마이크 설정이 바뀌었는지 저음이 귀에 꽂히네요 훨씬 좋은 것 같습니다.

중간에 한 말씀 보고 생각났는데 나주에 시간 나실떄 구독자 레포나 pr 하나 보고 조언받고 싶은 부분 고려해서 코드리뷰한번 하는것도 보면 재밌을거같아요

안녕하세요, 제미니님. 실무적 관점에서 소프트웨어 개발 시에 어떻게 접근 해야 하는지 큰 그림과 부분부분 디테일 함을 학습할 수 있어서 너무 좋았습니다. 약 30분 가량 되는 영상임에도 불구하고 제미니님께서 10년 이상 고민하며 체득한 개발 고민들이 녹아있음을 한번에 느낄 수 있었습니다. 정말 좋은 영상 감사드립니다!