💡 질문하기 전에 먼저 확인해보세요! 답변을 기다리는 동안, 아래 항목들을 먼저 확인해보시면 문제가 해결될 수도 있어요. 강의 내용 다시 보기: 혹시 놓친 부분이 없는지 해당 챕터의 강의를 한 번 더 돌려보셨나요? 오타 및 들여쓰기 확인: 파이썬은 특히 들여쓰기에 민감해요. 코드에 오타나 잘못된 들여쓰기는 없는지 꼼꼼히 확인해주세요. 에러 메시지 검색: 빨간색 에러 메시지가 떴다면, 메시지 전체를 복사해서 구글에 그대로 붙여넣기 해보세요. 전 세계 개발자들이 비슷한 문제를 겪고 해결책을 공유해두었을 확률이 높습니다. Q&A 게시판 검색: 혹시 다른 분이 먼저 비슷한 질문을 올렸는지 게시판을 한번 살펴보는 것도 좋은 방법이에요. 해당 강의 화면에서 코드를 보고 설명하시는 것 같은데 화면이 계속 인프런 강의소개 페이지인데 제가 맞게 보고 있는걸까요?
안녕하세요. Airflow 3.0 에서 EmailOperator 사용시 conn_id 를 세팅하지 않으면 smtp_default 를 기본적으로 사용하고 있어보입니다. smtp_default 세팅은 config 파일에 보니 email_conn_id(AIRFLOW__EMAIL__EMAIL__CONN__ID) 에 세팅되어 있어 EmailOperator 와 fail났을때 smtp_default를 세팅해놓으면 동시에 사용 가능한것은 아닐까요?
선생님 안녕하세요. 최대 혹은 최소값으로 ans를 int(1e6, 1e7, 1e8) 등 다양하게 설정하시는데 혹시 기준이 있을까요? 문제를 풀다 보면 탐색 전에 미리 최소값이나 최대값을 세팅해야 하는 경우가 있는데, 그 세팅의 베스트 프랙티스나 혹은 float(int) 같이 최대/최소값을 따로 정하시는 로직이 후반부에 나오는지 궁금합니다.
인사말 안녕하세요. 질 높은 강의를 제공해주셔서 너무 감사하다는 말씀드립니다. 아직 강의를 모두 본 것은 아니어서, 제가 질문드리고자 하는 내용이 강의에 포함이 되어있을지 모르겠습니다만.. 궁금한 내용을 질문드립니다. 질문 많은 모놀리식 프로젝트에서는 Spring Web + Spring Data JPA를 의존성을 주입하고 개발을 하고 저 또한 이러한 방식의 개발을 경험해왔습니다. Spring Data JPA와 Spring Web은 동기방식으로 동작하게 되는데, MSA의 독립 모듈을 만들 때 해당 의존성들을 사용하는 것이 바람직한지 모르겠습니다. 강의의 내용처럼 하나의 서비스는 독립적으로 구성된 수십개에서 수백개의 독립된 애플리케이션으로 동작을 하게 될 것인데요. 상황에 따라 다르기는 하겠지만 Spring Web과 Spring Data JPA를 사용하는 독립된 애플리케이션이 있게 된다면 이쪽에서 병목이 일어나 엄청난 성능 이슈가 발생할 것으로 생각이듭니다. 이와 같은 고민을 갖고 GPT한테 물어보니 WebFlux와 R2DBC를 사용하여 모두 비동기적으로 만드는 것이 권장되는 사항이라고 하는데 이 답변이 맞을까요? MSA를 구성한다고 한들, 모놀리식보다 성능상 좋지가 않으면 MSA로 구축할 필요성이 없을 것인데, 제가 우려하는 성능상의 심각한 문제 / 병목현상을 예방하기 위한 설계를 어떻게 해야하는지 너무 궁금합니다. 추가적으로는 Speing web이나 Spring Data Jpa가 MSA에거 어느 점에 필요하게 됭까요? 성능 관점에서 도무지 필요성을 느끼지 못하고있습니다. 질문이 너무 두서가 없는데... 질문 내용이 강사님께 잘 전달되었길 바랍니다..!
토비님의 의견에 동의합니다. 화면에서 필드 하나 필요하다는 수정사항을 처리하기 위해 Presentation 레이어 이외의 클래스들을 수정하고 싶진 않아요. 그럼에도 불구하고 현업에선 정말 수많은 이유를 들어서 DTO로 반환하는 걸 유지하려고 합니다. 별도의 관심사를 끌어안게 되면서 애플리케이션 레이어의 테스트 코드 작성이 까다로워지고, 그로 인해 안정성이 하나씩 무너지고 균열이 생기기 시작하는 지점이 이곳이지 않을까 싶어요. 어찌보면 강의를 들을까 고민하던 때에 가장 매력있게 보였던 챕터였고, 무언가 해답을 얻을 수 있을까 했지만 여전히 뭔가 용기가 생기진 않는 것 같습니다. 물론 그것이 토비님 탓은 아니죠. 훌륭한 가르침이지만, 단지 이것을 제 현장에 전파할 때 발생할 어려움에 벌써 머리가 아파지는 것.. 그 뿐입니다. 질문은 아니고 그저 넋두리였습니다. 나머지 강의 마저 잘 들어보겠습니다. 감사합니다
[질문 템플릿] 1. 강의 내용과 관련된 질문인가요? 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 안녕하세요, 영한님! JPA 활용2 강의 감사한 마음으로 잘 보고 있습니다. @PostConstruct는 빈이 생성되고 의존성 주입이 모두 끝난 직후에 자동으로 실행되는 메서드로 프록시 생성 이전에 실행되기 때문에 @Transactional과 함께 사용할 수 없어, init() 메서드에서 두 애노테이션(@PostConstruct, @Transactional)을 함께 작성할 수 없는 걸까요? GPT 답변을 참고한 후 질문 드립니다!
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 예 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 예 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) 예 [질문 내용] 여기에 질문 내용을 남겨주세요. 강의 3분 정도 쯤에 나오는 createOrder 메서드 생성 시 정적 팩토리 메소드를 사용하는 이유가 궁금해 여러 질문과 답을 읽어보았는데요. 의미 있는 메서드 이름 부여, 객체 생성 불필요 등 여러 장점이 있다는 것을 알았습니다. 그렇다면 대부분 생성자보단 정적 팩토리 메소드로 객체를 생성하는 것이 좋은 건가요? 아니면 객체 생성 시 연관관계 설정이나 복잡한 로직이 있을 때만 정적 팩토리 메소드로 만들어주는 게 좋은 건가요? 정적 팩토리 메소드 사용 이유에 어떤 기준이 있는 건지, 아님 보통 관례로 이렇게 사용하는 건지 궁금합니다!
POST API 첫번째 강의에서 main.py의 52번 줄에 request를 dict() 형식으로 꼭 맞춰 주어야하나요?? 출력은 request >> id=4 contents='aaa' is_done=True request.dict() >> {'id': 4, 'contents': 'aaaa', 'is_done': True} 이렇게 되는데, 그냥 request 만 써도 swagger UI에서 보았을 땐 똑같이 dict 형식으로 들어오더라구요. 궁금해서 문의드립니다.
맹목적인 파라미터의 숫자가 아닌 보통 함축적 정보를 전달하기 위해 DTO, 즉 파라미터 오브젝트를 사용해서 전달하는 방식은 워낙 간결한 방식이라 저도 선호도가 높긴 합니다. 하지만 엔티티의 영역에서 DTO와 유사한 레코드 형식의 매개변수를 전달 받는 방식은 어느 정도 엔티티의 순수성이 침해 받는 방식이 아닌가 생각이 들어서요. 실제로 작성하신 코드를 봤을 때 그런 순수성 집착 보다 휴먼 에러를 사전에 방지하는 접근 방식이라 매우 적절한 트레이드 오프라고 생각이 들기도 합니다. 이 부분에 대해서 개인적인 궁금증이 생겨서 질의 드립니다. 아직 강의를 다 본 상황이 아니라서 이런 질문을 하는 게 맞는지 작성하는 지금 이 순간 조차 고민이 되지만, 실제로 제가 생각하던 방식과의 거리감이 느껴져서 질문을 남겨봅니다.
안녕하세요 토비님! 항상 강의를 통해 새로운 시야를 얻는 것 같아 감사하게 듣고 있습니다! 강의를 수강하던 중 궁금한 점이 하나 생겨 질문 드립니다. 우선 현재 Section7, 39강까지 수강한 상태입니다. 도메인 규칙 상으로 프로필 주소가 제거 가능하다고 정해졌고, 이는 코드로 상세히 표현되었다고 생각했습니다. 하지만 " 프로필 주소는 제거할 수 있다 "라는 규칙을 적용해 memberA가 프로필 주소를 빈 문자열 형태로 변경한다면, memberB의 경우 동일하게 빈 문자열을 저장할 수 없으니 프로필 주소를 제거할 수 없는 것 아닌가라는 생각이 들었습니다. 그래서 기존 Github에 공개된 코드 테스트에서 실험을 진행했습니다. (제 코드는 차이가 있을 수 있어서 공개된 자료를 이용했습니다.) MemberRegisterTest#updateInfoFail 에 아래와 같이 테스트를 추가해 보니 entitymanager.flush() 부분에서 Unique index or primary key violation 이 발생했습니다. 제 생각에는 도메인 규칙을 변경하거나, profile_address의 값이 빈 문자열일 경우 NULL을 저장하도록 로직을 변경해야한다고 생각합니다. 혹시 제가 놓친 부분이 있는지, 토비님의 의견은 어떠신지 궁금합니다. 항상 감사하게 수강하고 있습니다!
최근에 제가 고민했던 부분의 토비님의 의견이 궁금해서 질문드립니다. “계층형 아키텍처와 헥사고날 아키텍처는 정말 본질적으로 다른 걸까?” 예를 들어, 계층형 아키텍처에서도 인터페이스를 통해 상위 계층이 하위 계층을 의존하도록 설계하면 DIP(Dependency Inversion Principle)를 지킬 수 있습니다. 그렇게 하면 헥사고날 아키텍처가 지향하는 의존성 역전 과 사실상 동일한 구조가 만들어지지 않을까요? 그렇다면 DIP를 잘 구현한 계층형 아키텍처는 헥사고날 아키텍처와 다르지 않다 고도 볼 수 있을 것 같습니다. 이 생각대로라면, 우리가 그동안 “계층형 아키텍처”라고 부르며 개발하던 많은 구조들이 사실상 헥사고날 아키텍처였던 것 아닌가? 라는 생각도 들었습니다. 만약 두 아키텍처가 여전히 다르다고 본다면, 그 차이는 폴더 구조나 패키지 구성 방식 처럼 물리적인 형태에서 오는 걸까요? 하지만 두 아키텍처 모두 논리적이고 추상적인 설계 철학 을 이야기하는 것인데, 물리적 구조로만 구분하는 건 이상하다고 느껴집니다. 결국 저는, 잘 설계된 아키텍처라면 헥사고날이든 계층형이든 최종 목표는 동일하다 , 라는 생각이 들었습니다. 즉, SRP(Single Responsibility Principle) 를 지키고, 외부 기술의 변화가 도메인에 영향을 주지 않아야 하며 (헥사고날), persistence 계층이 바뀌더라도 핵심 비즈니스 로직은 변하지 않아야 한다 (계층형), 는 점에서 둘의 지향점은 같다고 느낍니다. 혹시 제가 놓치고 있는 중요한 관점이 있을까요? 토비님께서는 이 두 아키텍처를 어떻게 구분하시고, 어떤 기준을 중요하게 보시는지 궁금합니다.
안녕하세요. 김판다 강사님을 보조하는 이조교 입니다. 저는 강사님 개인 메일로 도착한 질문들을 정리해, 다른 수강생분들께도 도움이 되도록 질문 게시판에 깔끔하게 편집해 올리고 있습니다. 개인 메일( pandakimt@gmail.com )로 질문하셔도, 강사님이 활발히 답변해드립니다. 제목: 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 구글 코랩에서는 셀마다 변수 값을 다시 정의해야 하나요? 아니면 첫 번째 셀에서 x = 10 이라고 하면, 두 번째 셀에서도 x 를 그대로 쓸 수 있나요?
