"무언가에 집착한다는 것은 내가 그 방향성으로 가는 것이 '지름길'이라고 느끼는 것일 수도 있다." 라는 의미일 수도 있겠네요. 좋은 견해 감사합니다. 오늘도 하나 배웠습니다. 역시 경험이 많은 분의 이야기를 듣는 건 정말 정말 너무나도 소중한 것 같아요. 이렇게 시간을 내서 영상을 통해 전달해주시는게 정말 감사합니다.
신입들도 미래에 대한 고민 때문에 커뮤니티나 컨퍼런스 다니는 거에요. 요즘은 기술스택이나 트렌드, 아키텍처 같은 굵직굵직한 부분이 빠르게 바뀌고, 또 서로 융합되기도 하니.. 빅테크 업계의 노하우나 정보를 얻으려고 하는거죠. 미래를 데뷔하지 않으면 회사를 퇴사하는 순간 아무것도 아니게 될까봐 그런거죠. 단적인 예로 전세계적으로 ai 개발이 치열한데 한국은 ai 모델을 개발할 수 있는 인력이 전무하다는 통계가 있을 정도죠. 사실 이런 부분은 기존에 회사에 다니는 선임 개발자들이 더 관심을 갖고 추진해 나가야 하는 상황인데, 일이 바쁘다는 이유로, 필요성을 못느낀다는 이유 등 온갖 이유드리븐 개발로 점철된 개발커리어를 쌓아가기 때문에 힘겨워하는 분들이 많죠. 신입에게도 한 수 배운다는 마인드가 필요한 시점인것 같아요. 물론 저도 많이 배우고 있습니다😢
안녕하세요 늘 좋은 영상 올려주셔서 감사합니다! 이 영상과는 관련이 없지만 제미니님의 여러 영상들 보다가 궁금증이 생겨서 질문드립니다! [지속 성장 가능한 소프트웨어를 만들어가는 방법] 글에서 layer 규칙을 설명해주실 때 아래와 같이 말씀해주셨습니다. 1. layer간 역류 참조는 금지되어야 하고, 순방향으로 참조되어야 함. 2. layer를 건너뛰어서 참조하지 말아야 함. 3. 예외적으로 Implement Layer에서는 동일 레이어간 참조가 가능 의문이 들었던 점은 아래와 같습니다. 1. [레이어간 객체 변환 + 중요한 객체를 더 고민하자](ruclips.net/video/Zs4VYXudYIQ/видео.html) 5분 8초에 나오는 내용에서 controller에 속하는 객체가 implement layer로 건너뛰어서 참조(AppendQuestionRequest가 toXXX 메서드 안에서 건너 뛰어서 참조)하고 있는데 위의 2번 규칙에 어긋나는 것 같다는 생각이 들었습니다. 혹시 이 경우는 참조가 아니라 사용하는 경우고, 사용하는 경우는 가능한건가요? 2. [# DB 외래키에 대해 / JPA 인 덱스 명시 + 양방향 연관관계](ruclips.net/video/6q0-IT5J0nI/видео.html) 16분 12초, [JPA Entity 연관관계 어떻게 걸까요? + 엔티티 연관관계 PTSD](ruclips.net/video/vgNHW_nb2mg/видео.html) 9분 21초 에 나오는 내용에서 data access layer에서 implement layer를 참조하고 있는 것 같아서 역류 참조가 되고 있다는 생각이 들었습니다. 이 경우도 위와 마찬가지로 참조가 아니라 사용하는 경우라서 가능한건가요? 저는 역류 참조라는 의미를 Data Access Layer는 Implement Layer을 모르는 것처럼 가장 아래 계층?은 위 계층을 몰라야 된다고 해석했는데 잘못된 이해가 있다면 설명 부탁드리겠습니다!!
봐주셔서 감사합니다! 1. AppendQuestionRequest 는 개념객체 중 하나이며 business layer 에 속할수도 있고 implement layer 에 속할 수도 있습니다. (정확하게 표현하려면 추가 설명이 필요할 듯 한데 나중에 영상으로 얘기해보겠습니다, 지금 기준으로 쉽게 이해하시려면 business layer 에 있다고 보시면 될 것 같습니다.) 사실 이부분은 별도로 다루지 않았는데, 정확하게는 레이어들은 각 컴포넌트들에 대하여 포커싱하여 보는게 맞습니다. 그래서 레이어 역류가 아니고 순방향 참조로 보는게 맞습니다. 2. 해당 구조(도메인 모듈을 추출한구조)에서 db-coe 모듈은 도메인의 스펙을 따른 구현체에 불과합니다, 고로 레이어 범위에 포함되어 있지 않습니다. 도메인 모듈에서 XXRepository 라고 선언하였을텐데, 이를 따른 구현체일 뿐입니다. 이에 대한 근거로 domain 모듈은 db 모듈의 존재 자체를 모르고 있습니다. 고로 레이어 역류가 아닙니다. 3. >> 혹시 한 모듈에서 진행할 때는 말씀해주신 layer규칙을 따라야 하지만, 멀티모듈은 의존성을 제어할 수 있기 때문에 모듈별로 참조를 제어하는걸까요? 이건 정확히 어떤 것을 말씀하신지 이해가 잘 안가서 잘 모르겠지만, 모듈별로 참조를 제어해야하는 것은 아닙니다. 중요한건 지켜야하는 중심 개념이 잘 지켜지고 있고, 그 중심으로 어플리케이션 전체가 오염 없이 중심을 잘 잡고 흔들리지 않게 하는 것 같습니다. 레이어도 그것을 위한 도구 중 하나 라고 보면 좋을 것 같습니다.
@@geminikims 정성스러운 답변 감사합니다!! 답변을 듣고 또 궁금한 점이 생겼습니다. 2번에서 db-core 모듈은 도메인의 스펙을 따르는 구현체라고 하셨습니다. 그러면 db-module에서 repository를 묶어주는 coreRepository까지는 implement layer라고 생각해야하는 걸까요? 그렇다면 db-module에는 implement layer와 data access layer가 같이 있는건가요? 3번은 "모듈 별로 참조를 제어해야하는 건가"라는 의문에서 나온 질문이었습니다. 답변 감사합니다.!! 혹시 재민님은 jpa 변경감지 기능을 사용 안하시는 편이신가요? 제가 이런 구조를 처음 접해봐서 그런건지 몰라도 변경감지 사용이 어려운 것 같더라구요 Implement계층에서 엔티티를 알게 하고 변경감지를 해도 되는걸까요?
회사일은 당연히 잘 해야하는거고, 회사일로만 발전하다보면 한계가 명확합니다. 사수가 없는 곳도 많고, 있어도 도움이 안되거나 회사에서는 개발에 대한 얘기가 없을 수 있습니다. 그런 분들 한테는 커뮤니티를 통해서 성장하는 것도 하나의 방법 입니다. 물론 외부활동 한다고, 회사일을 안하는 사람은 문제지만, 남들하는거 까지 고깝게 보지 마시기 바랍니다.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
"무언가에 집착한다는 것은 내가 그 방향성으로 가는 것이 '지름길'이라고 느끼는 것일 수도 있다." 라는 의미일 수도 있겠네요. 좋은 견해 감사합니다. 오늘도 하나 배웠습니다. 역시 경험이 많은 분의 이야기를 듣는 건 정말 정말 너무나도 소중한 것 같아요.
이렇게 시간을 내서 영상을 통해 전달해주시는게 정말 감사합니다.
주절주절한 영상에 집착과 지름길이라는 키워드로 요약해주시다니! 도움이 되었다면 다행이네요!
좋게 봐주셔서 감사합니다!😁
개인적으로 '기술뽕' 맞았다고 표현하는데요...
결국 실무경험이 쌓이면서 치유되더라구요. 제 경험입니다...
기술뽕 맞고나면... 자연스레 오버엔지니어링하게 되고... 그 오버엔지니어링이 발목을 잡는 순간 치유되는...
맞아요 저도 절차적으로 구현하는 환경에서 스파게티 코드 경험하고 나서 그랬죠
테스트와 설계 역량 익히고 헥사고날 아키텍처까지 스무스하게 넘어가더군요
과제전형에 단위테스트부터 헥사고날 적용하고, 요구사항도 다 맞췄는데 탈락 맛보고
“내가 오버엔지니어링 했구나”라고 자기반성 함😂😂
결국 경험이 최고의 스승 같긴합니다ㅎㅎ 물론 모든 경험의 가치가 같지 않고, 동일한 경험을 해도 사람이 천차만별이지만요..😭
야근하랴 주말에 일하랴 회사에서 풀스택으로 일하면서 오늘 신입분들 이력서 들어온 것들 보면서 커뮤니티나 컨퍼런스 이런 것과 동떨어져서 살아온 저한테 회의감을 느꼈는데 위로 받았습니다😢
위로가 되었다니 다행이네요! 하시는 일들이 별것 아닌 것들 처럼 보일 수 있지만 분명 가치가 있을 겁니다!
다만, 하셨던 일에 대한 정리와 미래에 대한 고민은 계속 하시면서, 새로운 도전도 하셨으면 좋겠습니다!
화이팅입니다!
신입들도 미래에 대한 고민 때문에 커뮤니티나 컨퍼런스 다니는 거에요. 요즘은 기술스택이나 트렌드, 아키텍처 같은 굵직굵직한 부분이 빠르게 바뀌고, 또 서로 융합되기도 하니.. 빅테크 업계의 노하우나 정보를 얻으려고 하는거죠. 미래를 데뷔하지 않으면 회사를 퇴사하는 순간 아무것도 아니게 될까봐 그런거죠. 단적인 예로 전세계적으로 ai 개발이 치열한데 한국은 ai 모델을 개발할 수 있는 인력이 전무하다는 통계가 있을 정도죠.
사실 이런 부분은 기존에 회사에 다니는 선임 개발자들이 더 관심을 갖고 추진해 나가야 하는 상황인데, 일이 바쁘다는 이유로, 필요성을 못느낀다는 이유 등 온갖 이유드리븐 개발로 점철된 개발커리어를 쌓아가기 때문에 힘겨워하는 분들이 많죠. 신입에게도 한 수 배운다는 마인드가 필요한 시점인것 같아요. 물론 저도 많이 배우고 있습니다😢
정말 중요한 내용인 것 같습니다.
영상 감사합니다!
봐주셔서 감사하고 공감 감사합니다!🙂
항상 많이 배우고있습니다 감사합니다😊
봐주셔서 감사합니다!😁
한주 시작하기 최고의 말씀이네요. 잘 들었습니다!!
과찬이시네요!🙂 봐주셔서 감사합니다!
좋은 주제 감사합니다!
봐주셔서 감사합니다!😁
하아.. 현업에서 코볼이랑 90년대 초창기 자바스크립트 문법으로 화면 쪽 코딩하는데.. 현업 일 잘해봤자.. 포트폴리오만들어서 얼른 튀어야.. 그냥 이직할려그러면 기술 스택때문에 연봉을 무슨 반토막을 내려하네요
그런 상황이라면... 당연히 비상 탈출 준비하셔야합니다ㅜㅜ!!
모든 상황이 동일하지 않으니 빠른 탈출 기원드려요!
공통 모듈 만들어야할까 영상도 그렇고 이 영상도 굉장히 공감이 갑니다! 주변에 같이 하고 싶은 시니어 개발자신거 같네요.
좋게 봐주시고 공감 감사드립니다🙂
좋은 동료가되는게 먼저
회사에서 좋은 동료는 무엇인가? 에는 여러가지 항목과 관점이 있겠지만, 일과 기본을 잘하는 것과 일맥상통하는 부분이 있다고 봅니다🙂
안녕하세요 늘 좋은 영상 올려주셔서 감사합니다! 이 영상과는 관련이 없지만 제미니님의 여러 영상들 보다가 궁금증이 생겨서 질문드립니다!
[지속 성장 가능한 소프트웨어를 만들어가는 방법] 글에서 layer 규칙을 설명해주실 때 아래와 같이 말씀해주셨습니다.
1. layer간 역류 참조는 금지되어야 하고, 순방향으로 참조되어야 함.
2. layer를 건너뛰어서 참조하지 말아야 함.
3. 예외적으로 Implement Layer에서는 동일 레이어간 참조가 가능
의문이 들었던 점은 아래와 같습니다.
1. [레이어간 객체 변환 + 중요한 객체를 더 고민하자](ruclips.net/video/Zs4VYXudYIQ/видео.html) 5분 8초에 나오는 내용에서 controller에 속하는 객체가 implement layer로 건너뛰어서 참조(AppendQuestionRequest가 toXXX 메서드 안에서 건너 뛰어서 참조)하고 있는데 위의 2번 규칙에 어긋나는 것 같다는 생각이 들었습니다. 혹시 이 경우는 참조가 아니라 사용하는 경우고, 사용하는 경우는 가능한건가요?
2. [# DB 외래키에 대해 / JPA 인 덱스 명시 + 양방향 연관관계](ruclips.net/video/6q0-IT5J0nI/видео.html) 16분 12초,
[JPA Entity 연관관계 어떻게 걸까요? + 엔티티 연관관계 PTSD](ruclips.net/video/vgNHW_nb2mg/видео.html) 9분 21초
에 나오는 내용에서 data access layer에서 implement layer를 참조하고 있는 것 같아서 역류 참조가 되고 있다는 생각이 들었습니다. 이 경우도 위와 마찬가지로 참조가 아니라 사용하는 경우라서 가능한건가요?
저는 역류 참조라는 의미를 Data Access Layer는 Implement Layer을 모르는 것처럼 가장 아래 계층?은 위 계층을 몰라야 된다고 해석했는데 잘못된 이해가 있다면 설명 부탁드리겠습니다!!
혹시 한 모듈에서 진행할 때는 말씀해주신 layer규칙을 따라야 하지만, 멀티모듈은 의존성을 제어할 수 있기 때문에 모듈별로 참조를 제어하는걸까요?
봐주셔서 감사합니다!
1.
AppendQuestionRequest 는 개념객체 중 하나이며 business layer 에 속할수도 있고 implement layer 에 속할 수도 있습니다.
(정확하게 표현하려면 추가 설명이 필요할 듯 한데 나중에 영상으로 얘기해보겠습니다, 지금 기준으로 쉽게 이해하시려면 business layer 에 있다고 보시면 될 것 같습니다.)
사실 이부분은 별도로 다루지 않았는데, 정확하게는 레이어들은 각 컴포넌트들에 대하여 포커싱하여 보는게 맞습니다.
그래서 레이어 역류가 아니고 순방향 참조로 보는게 맞습니다.
2.
해당 구조(도메인 모듈을 추출한구조)에서 db-coe 모듈은 도메인의 스펙을 따른 구현체에 불과합니다, 고로 레이어 범위에 포함되어 있지 않습니다.
도메인 모듈에서 XXRepository 라고 선언하였을텐데, 이를 따른 구현체일 뿐입니다.
이에 대한 근거로 domain 모듈은 db 모듈의 존재 자체를 모르고 있습니다.
고로 레이어 역류가 아닙니다.
3.
>> 혹시 한 모듈에서 진행할 때는 말씀해주신 layer규칙을 따라야 하지만, 멀티모듈은 의존성을 제어할 수 있기 때문에 모듈별로 참조를 제어하는걸까요?
이건 정확히 어떤 것을 말씀하신지 이해가 잘 안가서 잘 모르겠지만, 모듈별로 참조를 제어해야하는 것은 아닙니다.
중요한건 지켜야하는 중심 개념이 잘 지켜지고 있고, 그 중심으로 어플리케이션 전체가 오염 없이 중심을 잘 잡고 흔들리지 않게 하는 것 같습니다.
레이어도 그것을 위한 도구 중 하나 라고 보면 좋을 것 같습니다.
@@geminikims 정성스러운 답변 감사합니다!! 답변을 듣고 또 궁금한 점이 생겼습니다.
2번에서 db-core 모듈은 도메인의 스펙을 따르는 구현체라고 하셨습니다. 그러면 db-module에서 repository를 묶어주는 coreRepository까지는 implement layer라고 생각해야하는 걸까요?
그렇다면 db-module에는 implement layer와 data access layer가 같이 있는건가요?
3번은 "모듈 별로 참조를 제어해야하는 건가"라는 의문에서 나온 질문이었습니다. 답변 감사합니다.!!
혹시 재민님은 jpa 변경감지 기능을 사용 안하시는 편이신가요?
제가 이런 구조를 처음 접해봐서 그런건지 몰라도 변경감지 사용이 어려운 것 같더라구요
Implement계층에서 엔티티를 알게 하고 변경감지를 해도 되는걸까요?
정리하자면 본업은 본업답게 부업은 부업답게 하자는 말씀이시네요
맞습니다!🙂 주객전도를 조심해야죠!
출근길 최고의 선택
긴 연휴 후 출근이네요.. 화이팅🥲
왔다 내 마약
🤩🤩🤩
좋은 이야기 감사합니다
봐주셔서 감사합니다!🙂
균형 맞추는게 어려운거 같아요
다 상황이 다르니..
맞습니다 상황이 모두 다르니 계속 측정하고 느끼며 균형을 잡아야하는 것 같습니다! 정답지가 있는 문제가 아니니까요!
위로 많이 받습니다.ㅠ 제 방향이 틀리지 않았다는 걸 재미니님 영상 보면서 많이 느껴요 ㅠ
위로가 되었다니 다행이네요..! 계속 화이팅입니다!
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 하고싶은 말이 많으신데 극도로 조심스러워하시는 모습.... 재밌게 들었습니다
ㅎㅎ 또 너무 한 쪽으로 비춰질 수 있으니 약간 조심 해봤습니다..!
제발 주석 좀 달아줘 !!!!!
ㅜㅅㅜ
🥲🥲🥲
느슨해진 정신상태에 회초리 잘맞았습니다 😂😂😂
회초리 까진 아니지만..!ㅎㅎ 화이팅입니다!!😁
입정합니당
감삼다
봐주셔서 감사합니다!😁
회사일은 당연히 잘 해야하는거고, 회사일로만 발전하다보면 한계가 명확합니다.
사수가 없는 곳도 많고, 있어도 도움이 안되거나 회사에서는 개발에 대한 얘기가 없을 수 있습니다. 그런 분들 한테는 커뮤니티를 통해서 성장하는 것도 하나의 방법 입니다.
물론 외부활동 한다고, 회사일을 안하는 사람은 문제지만, 남들하는거 까지 고깝게 보지 마시기 바랍니다.
??? 당연히 그걸 모르는 사람도 있나요? 저도 동일하게 생각하고 영상에서도 말했을텐데 본인이나 고깝게 보지마세요
이 사람은 도대체 영상을 몇 분 까지만 봤길래 이런 댓글을 달 수 있는걸까.. 항상 말을 끝까지 듣는 습관을 길러보세요
민감한 부분에 조심조심히 영상을 올리셨는데, 댓쓴분도 조심스러웠으면 어땠을까 참 아쉽네용..^_^
정말 같이 일하기 싫은 부류😂😂
???