173만명의 커뮤니티!! 함께 토론해봐요.
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
헤더 질문드립니다. 헤더의 메인 햄버거 모양이 모바일 화면에서 보이지 않습니다. 엑스표창은 보이지만 팝업창에 메뉴의 하위 요소가 보이지 않는이유가 혹시 글자색상이 투명색으로 지정되어도 그런 현상이 나옵니까? 메인 화면을 설정할때 처음 엘리멘터써킷 이전에 다른 메뉴를 설정을 하고 엘리멘터 써킷 메뉴를 재 지정하고 이전 메뉴를 삭제 했던 과정이 있었는데 그 과정에서 잘못되었다면 메뉴가 보이지 않을수 있는ㄴ지요
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
헤더설정 질문 드립니다. 헤더를 푸터와 함께 별도로 작업을 해 놓았고. 메인 홈화면에서는 헤더를 만든후 원래 페이지에 만들었던 헤더 페이지를 지워 헤더를 모든 페이지에 활성화 시켰습니다. 당연히 엘리멘터로 편집창에서 보면 홈화면이나 다른 블로그 게시판 이런 페이지에서는 헤더의 모습을 볼수 없지만 홈페이지 주소로 들어가면 헤더가 나옵니다. 하지만모바일 화면에서 활성화 시켜보면 헤더의 메인 햄버거 모양까지 나오고 햄버거 모양을 클릭했을때 팝업창이 활성화 되는 모습이 가려져서 보이지가 않습니다. 조언구합니다.
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
여기서 만든 메뉴위에 이런게 추가적으로 뜨는데 구조 컨테이너에도 안나오는데 이거 어떻게 없에는지 궁금합니다. 웹버전에서는 안보이는데 모바일버전에서만 뜨네요
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
1강 구매한 도메인 주소는 asdfqwer을 구매했는데, 2강 호스팅에서 대표 도메엔 연결에서는 왜 구매한 도메인 주소를 연결하지 않고 갑자기 다른 도메인을 연결하였나요? 원래 구매한 도메인을 연결하는게 맞죠? 초보라서 몰라서 질문드립니다.
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
지금 웹 페이지를 강의에 따라서 만들고 있는데 엘리멘터로 편집을 하기전에 워드프레스로 작업을 했던 웹 화면이 있어서 웹페이지를 열어보면 엘리멘터로 작업한 홈 화면이 먼저 나오지 않고 이전에 워드프레스로 작성한 웹 페이지가 먼저 나옵니다. 엘리멘터로 작업한 홈화면이 제일 먼저 보여지게 하려면 어떻게 하나요
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
홈 세팅 끝나고 첫번째 섹션 1 듣고 있는데요 텍스트 편집기 추가 하는데 컨테이너 화면에서 보이지 않습니다. z-인덱스를 6으로 올려봐도 화면에서 나타나지 않습니다. 혹시 다른 설정을 조정해야 하나요
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
안녕하세요. 강의 잘 듣고있습니다. ^^ 이제 홈화면 세팅하고 있는데요. 처음 페이지 설정을 홈, 블로그, 게시판, 문의사항 네가지를 만들어준 다음 홈화면 세팅을 하는데.. 편집은 엘리멘터로 당연히 하고 있고요. 그런제 제가 진행하는 엘리멘터에서는 홈화면에서 home이라는 글자가 상단에 자리를 차지하고 있어서 이미지 비율이라던가 다른 글자의 비율이 전혀 맞지가 않아서 모바일 화면 구성 세팅에서는 진도가 나가기 어려워 질문드려요.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
좋아요. 하드코딩에 대해 알려주는 강의가 95% 인데, 일 하는 법에 대해 알려주는 강의인 것 같아요. 제가 강의 듣다가 가만 생각이 들던데, 일 잘하는 사람이 되기 위해 필요한 것들을 알려주는 강의가 아닐까 라는 생각이 드문드문 들더군요.
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
아무리 찾아도 안보여서 질문드립니다.
미해결
비전공자도 따라하는 워드프레스 홈페이지 제작
강의 오늘 처음으로 듣고 있습니다. 강의에 필요한 사진들은 어디서 다운받을 수 있는지 궁금합니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요 제미니님 유튜브랑 인프런 강의 잘 듣고 있습니다. 항상 감사합니다. 😃 다름이 아니라 강의를 보고 사이드 프로젝트를 해보고 있는데, 도메인과 엔티티를 분리해서 엔티티는 단순 DB 매핑용으로만 쓰고 모든 비즈니스 로직을 도메인에서 처리해보려 하고 있습니다. 그러다 보니 '수정'같은 경우(예를 들면 state를 예약에서 취소로 변경하는)에는 id로 엔티티를 찾고 도메인으로 매핑해서 도메인 내부에서 검증과 로직을 처리해야 하는데, 매핑하는 과정에서 수정하는 데 불필요한 List<같은 격벽 하위 도메인> 들도 다 조회를 해서 세팅을 해줘야 하더라구요. 1 : N 관계라 쿼리도 많이 나가게 되고 수정에 불필요한 필드들을 세팅하는 거라서 비효율적이라 생각해서 개선을 해보려 합니다. 강의 예제 코드에서는 단순 update는 entity 에서 처리하는 것 같던데, 저는 도메인과 엔티티 계층을 엄격히 분리해서 service 내에서 entity를 의존하는 것이 불가능한 상황입니다. 또한 비즈니스 로직도 엔티티가 아닌 도메인 내부에 놓고 싶습니다. 수정에 필요한 필드만 가지고 있는 수정용 도메인을 만들어서 처리할까 생각도 해보았는데, 비즈니스 로직이 흩어지는 것도 이상하고, 얕은 지식이지만 애그리거트 루트에서 데이터 변경이 이루어져야 한다는 생각이 있습니다. 그렇다고 도메인 내부의 하위 도메인 리스트를 nullable하게 가자니 제미니님이 OrderSummary 관련 강의 때 말씀하신 null을 허용하는 도메인을 웬만해서는 선호하지 않는다에 공감이 가서 고려를 안하고 있습니다. 조언을 주시면 정말 감사하겠습니다 ㅜ.ㅜ 😢
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요, 강의랑 유튜브 너무 잘 보고있습니다. 강의를 보면서 여러 인사이트를 얻었습니다! 궁금한 점은 코틀린이 아닌 자바를 사용할 경우엔 엔티티 객체를 도메인 객체로 변환해서 return 해줄 때 코드가 다소 지저분해지는데요 ㅠㅠ 어떤 방식이 가장 유효할지 의견 부탁드립니다! 엔티티 객체에 toDomain() 과 같은 도메인 객체 변환 메서드 생성 Mapper 클래스 생성 (ex. ProductMapper.toDomain(entity)) (생성 한다면 어느 모듈, 위치에..?) 추가적으로 도메인 객체를 사용한다면, 엔티티 -> 도메인 -> 클라이언트 응답 DTO 와 같은 변환 과정을 거의 필수적으로 거쳐가야하는데, 이 부분에 대해서 도메인 객체와 엔티티 객체의 분리 시점이 재미니님은 있으신건가요? 아니면 프로젝트 시작부터 도메인과 엔티티는 구분해서 사용할 것이다! 라고 정하고 시작하시는 편이신가요? 물론 프로젝트의 규모와 도메인의 복잡도 등에 따라 유연하게 변해야 한다고 생각하지만, 해당 경험이 없다시피 하다보니 현재 프로젝트 구조에서 구현 레이어 밖으로 나갈때 도메인 객체로 변환의 이점과 트레이드 오프에 대해 어떻게 생각하시는지 궁금합니다!
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
CouponService쪽에선 다른 Service와 다르게 Implement Layer를 의존안하고, DataAccess Layer의 Repository 계층에 의존하고 있던데, 왜 그런걸까요?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
상품 목록 조회가 복잡해질 때의 상황을 생각해보고 있는데요. 감이 오지 않는 부분들이 몇가지 있어 질문드립니다. 상품 목록 조회 시 옵션 개념이 있다면 재고는 어떻게 처리해야 할까요? 재고는 상품옵션들의 조합이 가지고 있는 것이 이상적일 것 같은데, 상품 목록 조회던, 상세 조회던 품절 여부와 최대 구매가능 수량을 나타내기 위해서는 재고 정보도 필요해보입니다. 따라서 Product 필드에 해당 상품의 전체재고수량(모든 조합의 실재고 합)을 필드로 가지고 있는게 맞나? 라는 생각이 들고... 필드로 가지고 있다면 상품 조회 시 조합을 전부 조회하고 매번 합해 주어야 하나? 그럼 Product 테이블 컬럼단에 미리 합한 값을 넣어두어야 하나? 여러 생각이 듭니다. 다음으로는 프로모션(타임세일) 적용가, 쿠폰적용가 등으로 보여줘야 한다면 이게 실질적으로 Product 도메인 객체의 가격을 변경해도 되는 건가? 라는 생각도 했습니다.프로모션(타임세일) 적용가, 쿠폰적용가 등으로 보여줘야 한다면 쿠폰적용가, 타임세일 적용가 등이 처음에는 보여주기만을 위한 정보이지 않을까 생각했는데, 실제 주문할 때 반영될 금액이기도 하고, 타임세일 같은 경우는 대부분 모두에게 적용되어 보이는 형태이기에... 뷰의 목적이 아니라 개념적으로 봐도 되는걸까? 라는 생각이 듭니다. 조금 고도화 하여 생각해보니 감이 잡히지 않는 부분들이 너무 많네요,,, 실무에서는 주로 어떤 구조를 추구하는지 제미니님은 어떻게 생각하시는지 궁금합니다. 긴 글 읽어주셔셔 감사드려요!
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요 제미니님, 유튜브부터 계속 꾸준히 보다가 강의 릴리즈 하신 후 바로 구매하여 듣고 있는 사람입니다. 먼저, 생각할 거리를 많이 주는 좋은 강의 감사드립니다. 다름이 아니라, 일단은 ProductSerivce 안에서 Product라는 개념만을 명확히 다루고자 하였기에 Controller에 타 개념의 Service들도 혼재되는? 그런 상황이라고 이해했습니다. 물론 다 선택의 영역이겠지만, 개발자분들 중에선 Presentation 영역(Controller)을 최대한 가볍게 가지고 가시려는 분들도 많은것 같습니다. 그래서 대신에 여러 서비스들이 혼재되는 상황을 Facade 등을 도입해서 여러 개념의 서비스들에 대한 presentation 계층에서의 접근을 일원화하고 각 서비스단에서의 복잡성은 해결하고자 하는 케이스도 실무에서 종종 접했는데요. 이에 대해서는 제미니님께서 어떻게 생각하시는지 궁금합니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요 제미니님 유투브때부터 잘 보고 있습니다! 그 25분쯤에 controller에 여러 service들을 주입받아서 사용하시는 부분에 대한 질문이 있습니다. 1. 그럼 격벽으로 넘어도 되는 개념 사이에서는 a service에서 b finder or b appender 를 호출해도 괜찮은건지..? 2. 격벽으로 넘어서 안돼는 개념 사이에서는 강의에 나온것처럼 여러 service를 controller에서 받아서 response를 만들어야 하는건지.....?또 그렇게 되면 controller에서 여러 service를 알아야하니까 그건 또 문제가 없는지.. 궁금합니다!! 제미니님은 주로 어떻게 하시나요!? 감사합니다
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요. 지난번에도 질문 남겼었는데 또 찾아뵙게 되었습니다. user 의 경우 많은 개념들이 참조하게 될 것 같습니다. 회원탈퇴라는 기능이 제공될 때, 회원이 탈퇴되면 관련된 개념들을 삭제해야된다고 할 경우 이를 어떻게 해결하는 것이 좋을까요? user 쪽에서 관련 개념들을 찾아서 삭제하기에는 개념 격벽간의 순환 참조(?)가 발생하게 될 것 같습니다. 카프카나 메시지 큐 등을 이용해서 처리할 수 있을 것 같은데 현재 이를 처리할 수 있는 별도의 인프라는 없다고 가정해보고 싶습니다. 그렇다면 어플리케이션 이벤트(ApplicationEventPublisher)를 사용하는 것이 방법이 생각납니다. 하지만 이벤트를 사용하게 되면 어플리케이션의 로직 흐름을 보기가 조금 어려우지는 것 같다는 생각도 들어서 괜찮은 방법인지 고민이 됩니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요, 제미니님! 강의 완독 후, 결제 시스템의 안정성을 높이기 위해 개인 프로젝트에 외부 PG사 연동 구간에 장애 격리 처리를 직접 구현하며 경험하고 있습니다. 구현 과정에서 고민했던 설계 내용과 제 나름의 가설이 맞는지, 그리고 기존 강의 코드의 설정 의도에 대해 여쭤보고 싶습니다. 🙇🏻♂️ 1. 서킷 브레이커 도입 및 트랜잭션 분리 전략 @Component class BeeceptorPaymentClient( private val restClient: RestClient, private val circuitBreaker: CircuitBreaker, ) : PaymentClient { private val log = LoggerFactory.getLogger(javaClass) override fun requestPayment(command: PaymentCommand): PaymentResult { return circuitBreaker.run("beeceptor-payment") { executePayment(command) } .fallbackIfOpen { log.warn("[Circuit Open] Beeceptor 결제 서비스 차단됨. 잠시 후 재시도 필요.") throw CoreException(ErrorType.PAYMENT_EXTERNAL_API_UNAVAILABLE) } .getOrElse { e -> when (e) { is HttpClientErrorException -> { log.warn("[PAYMENT_REJECTED] 결제 거절: ${e.responseBodyAsString}") throw CoreException(ErrorType.PAYMENT_REJECTED) } is CoreException -> throw e else -> { log.error("[PAYMENT_FAILED] Beeceptor 결제 호출 실패", e) throw CoreException(ErrorType.PAYMENT_EXTERNAL_API_FAIL) } } } } } 외부 PG사 장애 전파를 막기 위해 Resilience4j 를 도입했고, 테스트를 위해 Beeceptor를 활용했습니다. 설정 전략: COUNT_BASED (최소 10회, 실패율 50% Open), 단순 비즈니스 에러(4xx)는 ignoreExceptions 로 제외하여 시스템 장애만 감지하도록 설정했습니다. 트랜잭션 분리 (Facade 패턴): 트랜잭션에 대한 DB 커넥션 점유 시간을 최소화하기 위해 아래와 같이 로직을 3단계로 분리했습니다. 1. 검증: DB 조회 (ReadOnly 트랜잭션) 2. 외부 요청: 외부 PG API 호출 (No 트랜잭션 + 서킷 브레이커 적용) 3. 상태 업데이트 : 결제 결과 저장 (Write 트랜잭션) @Component class PaymentConfirmFacade( private val paymentService: PaymentService, private val paymentClient: PaymentClient, ) { fun success(orderKey: String, externalPaymentKey: String, amount: BigDecimal): Long { // 1. [DB Transaction] 결제 검증 val command = paymentService.validatePayment(orderKey, externalPaymentKey, amount) // 2. [No Transaction] 외부 API 호출 val paymentResult = paymentClient.requestPayment(command) // 3. [DB Transaction] 결제 완료 처리 // 외부 API에서 받은 결과(transactionId 등)를 넘겨줌 return paymentService.completePayment(orderKey, paymentResult) } } [질문] Facade 패턴을 적용함에 따라 '외부 요청'(2번)은 성공했으나, '상태 업데이트 및 저장'(3번)에서 DB 장애 등으로 실패할 경우 데이터 불일치가 발생합니다. 현재 로직상 completePayment 가 실패하면 트랜잭션이 롤백되어 TransactionHistory 조차 남지 않고 Payment 상태는 READY 로 유지됩니다. 따라서 저는 배치/스케줄러 를 통해 일정 시간이 지나도 READY 상태로 남아있는 결제 건들을 조회한 뒤, PG사 결제 내역 조회 API와 크로스 체크 하여 누락된 결제를 보정하는 로직이 필요하다고 판단됩니다. 이러한 접근 방식이 실무에서사용하는 일반적인 보정 패턴인지 궁금합니다. 2. DB Connection/Socket Timeout 설정 의도와 Facade 적용 시의 상관관계 외부 API 타임아웃(Connect 3s, Read 30s)을 학습하며 적용하던 중, 기존 강의 프로젝트의 db-core.yml 설정이 눈에 들어왔습니다. connection-timeout: 1100 (1.1초) socketTimeout: 3000 (3초) [질문 1] 보통 DB 타임아웃을 넉넉하게 잡는 경우도 있는데, 이렇게 타이트하게 설정하신 의도가 "트래픽 급증 시 DB 커넥션을 얻지 못하면 빠르게 실패 처리 하여 스레드 풀 고갈을 막고 시스템 전체 장애를 방지 하기 위함" 인지, 혹은 다른 운영 노하우가 담겨 있는 것인지 궁금합니다. [질문 2] 저는 Facade 패턴을 적용하여 외부 API 호출 시점에는 트랜잭션(DB Connection)을 점유하지 않도록 분리 했습니다. 따라서 기술적으로는 DB 타임아웃과 서킷 브레이커(외부) 타임아웃을 서로 독립적인 관점으로 설정해도 된다고 판단했습니다. 다만, 실무 운영 관점에서는 결국 '전체 사용자 대기 시간(User Latency)' 이라는 제약이 존재할 텐데, 이때 전체 응답 시간 제한 내에서 DB와 외부 API 타임아웃 비중을 어떻게 배분하시는지 강사님만의 기준이나 노하우가 궁금합니다 ! 긴 글 읽어주셔서 감사합니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
요즘 쇼핑몰 커머스등은 비회원 주문이 있는 경우가 거의 대부분인 것 같은데 비회원 주문,결제의 개념이 추가된다면 어떻게 개선될 수 있을까요? api가 복제되는 느낌으로 가야하는지.. 주문, 장바구니, 결제 등등 유저아이디 대신 게스트아이디로 조회하는 등과 같이 작은 부분만 바뀌고 나머지 로직은 동일 반복될 것 같습니다. 주문조회시에도 회원 비회원.. 서비스는하나를 쓰고 OrderFinder에서 함수로 나누는 방식도 생각납니다. 어떤 방식이 더 있을까요?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요. DB 레이어를 다루는 것에 대해 몇가지 질문이 있습니다. 프로젝트 버전 1.1 포인트 적립 트랜잭션 리뷰 작성 ReviewService.addReview )에서 포인트 적립 PointHandler.earn )이 한 트랜잭션에서 이루어져야 될 것 같다고 생각했는데 분리되어 있습니다. 이렇게 처리해도 충분한지 여쭤보고 싶습니다. CancelService, PaymentService 에서는 같은 트랜잭션에 있음 낙관적 락 예외 처리 PointBalanceEntity 에는 동시성 처리를 위해 @Version (낙관적 락)을 두었다고 해주셨습니다. 현재는 낙관적 락 예외가 발생하면 500 에러가 발생할 것으로 보이는데, 저는 평소 최대한 이 낙관적 락 예외를 잡아서 적절히 다른 예외로 변환하여 던지도록 했었습니다. 낙관적 락 예외에 대해서 500에러가 발생하도록 처리하는 것으로 충분할지 고민됩니다. Repository, JpaRepository 분리 현재 프로젝트는 서비스 -> 컴포넌트(Finder, Handler, ...) -> JpaRepository 형태로 계층 관계가 있는 것 같습니다. 그런데 재미니님의 유튜브를 보면 서비스 -> 컴포넌트(Finder, Handler, ...) -> Repository(개념 객체를 다루는?) -> JpaRepository 형태의 계층을 이루고 있는 것으로 보입니다. 첫번째 계층구조를 보면 종종 서비스에서 단순히 컴포넌트를 한번 호출하는 정도인 경우가 많은 것 같습니다. 두번째 계층구조를 사용한다면 서비스에서 단순히 컴포넌트를 한번 호출하고, 그 컴포넌트에서도 단순히 Repository를 한번 호출하는 정도인 경우도 많이 생길 것 같습니다. 이러한 이유로 저는 첫번째 계층구조 정도로 충분한가? 라고도 생각했는데 두번째 계층구조를 선택하시게 되는 이유가 궁금합니다. 두번째 계층구조 관련해서 여러 영상들이 있겠지만 우선 저는 아래 영상 참고했습니다. https://www.youtube.com/watch?v=b5xWS8MYl0Q Repository 가 분리된 경우에서의 검증, 업데이트 로직 데이터를 검증, 업데이트할 때 어떤 재미니님과 같은 프로젝트 구조를 가져간다면 어떤 식으로 코드가 나오게 될 지 궁금합니다. 검증, 업데이트라 하면 제가 생각한 예시 상황은 리뷰가 7주일이 지나면 업데이트 할 수 없다는 요건이 있다고 가정해보겠습니다. 제가 생각한 것은 아래와 같습니다. public class ReviewService { private final ReviewFinder reviewFinder; private final ReviewProcessor reviewProcessor; public void update(ReviewUpdate reviewUpdate) { var review reviewFinder.get(reviewUpdate.id()); if (review.canUpdate()) { throw new CoreException(); } var updatedReview = review.update(reviewUpdate); reviewProcessor.update(updatedReview); } } 이전에 프로젝트 구조에 대해서 고민이 많이 되었을 때 재미니님의 유튜브를 보면서 프로젝트 구조를 잡는데 도움이 많이 되었습니다. 그런데 제가 그 의도나 스타일을 완전히 이해하지는 못하고 있는 것 같아서 재미니님의 스타일들을 한번 배워보고 싶습니다. 유튜브에서부터 정말 도움 많이 받고있습니다. 좋은 강의 감사합니다!!
