안녕하세요 실무에서 '관리자(Admin) 예약 변경 기능' 정책을 두고 기획팀과 이견이 있어, 실무에서는 어떤 방식이 범용적인지 여쭙고 싶습니다. [시스템 상황] 유저가 예약할 때 다양한 할인(이벤트, 타임세일, 쿠폰, 기업지원 등)이 적용되며, 이 정보는 예약 시점에 스냅샷(Snapshot) 으로 저장됩니다. 현재 어드민(상담원/운영팀) 이 유저의 예약 시간/날짜를 변경하는 기능을 개발 중입니다. [이슈 사항] 기획상으로는 어드민에서 시간을 변경할 때도 모든 할인 조건을 '실시간'으로 재검증 하라고 합니다. 문제는 재검증 과정에서 '쿠폰 박탈' 같은 상황이 발생한다는 점입니다. 예시 상황: 유저가 5만원 짜리 예약에 5만원 이상 결제 시 사용 가능한 10% 쿠폰 을 씀. 어드민이 사정상(또는 유저 요청으로) 가격이 저렴한 타임이나 옵션으로 변경함 -> 결제액이 4만원 이 됨. 기획 요구사항: "최소 결제 금액(5만원) 조건을 불만족하게 되었으니, 자동으로 쿠폰 적용을 해제(원복)하고 금액을 재계산 한다." [제(개발자) 의견 및 고민] 저는 위 기획이 어드민 기능의 목적 과 UX(고객 경험) 에 맞지 않는다고 생각합니다. 고객 경험 훼손: 유저는 단지 시간을 바꿨을 뿐인데, 시스템이 엄격하게 검증해서 "조건 미달이니 쿠폰 뺏어가겠습니다"라고 하면 컴플레인 요지가 다분합니다. (유저 입장에선 혜택 유지를 원하니까요.) 데이터 복잡도: 이미 스냅샷으로 저장된 할인 정보를, 수정 시점에 다시 현재 기준의 마스터 데이터(쿠폰 유효기간, 최소금액 등)와 대조해서 '줬다 뺏는' 로직을 짜는 건 구현 복잡도 대비 실익이 너무 적습니다. 관리자의 재량: 어드민에서의 변경은 보통 '강제성(Override)' 을 띠는 경우가 많은데, 시스템이 칼같이 혜택을 잘라버리는 게 맞나 싶습니다. [질문] 보통 예약 도메인에서 관리자(Admin)가 개입하여 예약을 변경할 때 도, 이렇게 엄격하게 유저의 할인 자격(최소금액, 유효기간 등)을 재검증하여 박탈 시키는 게 맞나요? 아니면 어드민 권한 변경인 경우 "기존 스냅샷(혜택)을 최대한 유지" 해주거나, 가격 변동이 불가피하면 "취소 후 재예약" 을 하는 프로세스가 더 일반적인가요? 개발자로서 이 복잡한 '조건부 쿠폰 회수' 로직을 방어하고 싶은데, 설득력 있는 논리가 필요합니다. 조언 부탁드립니다!
섹션 19 부분은 예전에 강의하셨을 때 쓰신 스프링부트 2점대 버전을 3점대 버전으로 업그레이드하는 강의인가요? 최신 강의 기준 업데이트 하신 3점대 버전으로 강의를 듣고 있는데 섹션 19에서 강의가 정확히 어떤 강의인지 궁금합니다. 만약 2점대 버전을 3점대 버전으로 업그레이드 하는 강의라면, 섹션 19에서 분산 트레이싱, swagger, kubernates 부분만 들어도 되는걸까요?
현재 백엔드 프로젝트에서 스프링 시큐리티 프레임워크 도움을 받기 위해 CSRF 설정은 끄고 <form> 전송과 세션 방식으로 로그인 하고 있잖아요. (저는 그렇게 보였는데 아니면 제가 잘못 이해한거구요..) 그런데 요즘은 SSR 방식이 아닌 현재 프로젝트처럼 프론트 따로 서버 따로 해서 서버는 REST API 만 개발하고 JWT 방식을 쓰잖아요 JWT 도 보안에 한계가 있는데 아무튼 이걸 떠나서 현재 CSRF 설정을 끄고 <form> 전송으로 로그인하는게 보안상 많이 위험한 건 아닌가요? 제가 애초에 잘못 이해하고 있어서 질문 자체가 잘못되었을 수 있지만 관련해서 답변 부탁드립니다
MemberDetail 테이블의 UK_MEMBER_DETAIL_PROFILE_ADDRESS 유니크 제약 조건과 관련해서 질문이 있습니다. 39장 강의 마지막 부분에서, 해당 프로파일 주소(profile_address)를 빈 문자열로 바꿔 삭제할 수 있는 부분 테스트를 추가 하셨는데, 그런데 이렇게 되면 여러 사용자가 프로필 주소를 빈값으로 변경 할 경우 제약 조건에 충돌이 발생할 수 있을 것 같습니다. profile_address 값을 빈값으로 설정할 수 없도록 테스트를 조정하는게 더 맞아 보이는데 제가 생각한게 맞을까요?
킬구형 내가 그동안 보면서 정리한내용으로, 실습을 진행해보려고 혼자 스스로 파일을 만들었어. 실습 환경은 h2 데이터 베이스로 테스트 했고, 메타테이블은 자동으로 만들어졌어. 간단한 스텝과 잡을 만들어서 콘솔에서 잘 실행되는것 까지는 확인을 했는데 실제 데이터 베이스 테이블인 batch_job_instance와 같은 테이블에는 데이터가 들어가지 않아. 혹시 몰라서 db url도 확인해봤는데 정확하게 일치하고.. 이런경우는 어디를 확인해보면 제일 좋을까..? 콘솔에서 에러도 나지 않고 정상적으로 배치가 실행돼서 답답해 미치겠어 ㅠㅠㅠ 콘솔에서 insert 쿼리는 안나가고 있는데, 쿼리가 왜 안나가는지를 도통 모르겠어 ㅠㅠ 다 잘되는데 메타테이블에만 데이터가 들어가지 않네.. 참고로 tasklet 방식으로 테스트 해봤어. 부트 4.0.1 버전 사용하고 있어 킬구형 강의자료 에서도 중간에 postgresql로 전환하던데 혹시 h2는 뭔가 지원을 하지 않는걸까?
먼저 gpt를 통해 elk 스택을 설치했습니다. discover를 클릭하니 아래의 이미지와 맞지 않은 결과가 나오는데.. 상위버전이나 혹은 하위버전처럼 나오는경우 어떻게하면 좋을까요? http://localhost:5601/app/management/kibana/indexPatterns/ 으로 이동하게되는데.. create dataview는 어떤 경로로 나올수있을까요? 아래의 docker정보는 실제 제가 설치한 정보입니다. Index patterns이 나옵니다.
안녕하세요, 무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점을 설명한 부분에 질문이 있습니다. 페이지 방식을 무한 스크롤 방식에 적용 시 문제점으로 아래 2가지를 제시하셨는데요, 1) 페이지가 추가된 경우, 데이터 중복 조회 문제 2) 페이지가 삭제된 경우, 데이터 누락 문제 궁금한 점은, 이러한 문제는 무한 스크롤에서 사용했을 때 뿐 아니라, 페이지 번호 방식을 사용할 때도 마찬가지로 문제가 있는 것 아닌가 싶다는 것입니다. 페이지 번호 방식 자체의 한계라고 생각하는데, 페이지 번호 방식에서는 발생하지 않는 문제인가요?
안녕하세요! 수업 잘 듣고 있습니다. 사소한 내용이긴한데.. OrderService.create 에서 OrderKeyGenerator 객체를 를 주입받아 generate() 를 호출해서 orderKey 를 생성하는 부분에서 OrderKeyGenerator class 는 상태를 가지지도 않고 Property 를 가지지도 않는데 static method, 함수로 구현 되어도 되지 않았을까 하는 생각이 들었는데요. 어떤 고려사항이 있는지 궁금합니다. static 이든 함수든 객체 메서드이든 상관 없다? 나중에 OrderKeyGenerator 가 확장되는 것이 고려된 것? OrderSerivce 에서 사용하는 기능이니 주입되는 것이 더 응집되어 보여서 더 좋다? 그냥 함수를 가져다 쓰는 것보다 객체를 주입하는 쪽이 테스트 하기 좋다? generate 가 순수함수가 아니라서? class OrderKeyGenerator { fun generate(): String { return Base64.getUrlEncoder().withoutPadding().encodeToString( ByteBuffer.allocate(16).apply { UUID.randomUUID().also { putLong(it.mostSignificantBits) putLong(it.leastSignificantBits) } }.array(), ) } }
강사님 강의 재밌게 너무 잘 보고있습니다!!! 클로드 코드에 대해서도 사용해보니까.. 재밌어요 PostgreSQL을 왜 선택하고 특징, 장점까지 잘 보았습니다. 하지만 MySQL에 유리한 프로젝트는 무엇인지 궁금합니다. PostgreSQL선택한 이유중에 부분 인덱스 지원해주고 JSON을 효율적으로 저장할 수 있는 타입인 JSONB도 지원해주고 커뮤니티도 풍부하고 READ COMMITTED - 높은 읽기 성능을 제공해주는것으로 MySQL보다 전부 뛰어나다고 생각이듭니다. MySQL과 차이점은 MySQL은 Reapeatable Read로 정합성을 챙기고 MVCC덕분에 높은 읽기 성능을 가지고 있는걸로 알고있습니다. 그 외에 MySQL의 장점과 유리한 프로젝트들 예시를 좀 조언을 얻고싶습니다
수업 챕터 14. 세션 로그인 ▶ ︎ 구현과 동작 에서 6분 35초쯤에 Docker 에서 Redis Container 로 진입하시고 /data # redis-cli 명령을 작성하실 때, 원래는 이런 명령어를 사용하시면 안된다고 하시는데 그럼 원래는 무슨 명령어를 사용하는지 궁금하네요
안녕하세요, 강사님. 강의와 직접적인 내용은 아니지만, 사내에서 발생한 Spring Batch 오류와 관련해 조언을 구하고자 문의드립니다. 혹시 시간이 괜찮으시다면 의견을 주시면 정말 감사하겠습니다. 1. 사용 환경 Java 1.8 Spring Boot 2.7.18 Spring Batch 4.3.10 2. 문제 상황 Spring Batch의 ExecutionContext 에 한글 문자열을 저장한 이후, 다음 배치 실행 시 아래와 같은 오류가 발생하며 Job이 지속적으로 실패하는 현상이 있었습니다. java.lang.IllegalArgumentException: Unable to deserialize the execution context at org.springframework.batch.core.repository.dao.JdbcExecutionContextDao$ExecutionContextRowMapper.mapRow ~ Caused by: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xb2 해당 Job은 chunk 기반 배치이며, 마지막 close() 시점에 다음 Step에서 사용할 정보를 ExecutionContext 에 저장하고 있었습니다. 이때 ResultMsg: "정상 처리" 와 같이 한글 문자열 을 저장한 이후부터 문제가 발생했습니다. 3. 원인 분석 IDE(Eclipse) 인코딩: UTF-8 DB 인코딩: NLS_CHARACTERSET = KO16MSWIN949 BATCH_JOB_EXECUTION_CONTEXT 테이블에 데이터가 저장되는 구조로 확인했습니다. SHORT_CONTEXT (VARCHAR2(2500)) SERIALIZED_CONTEXT (CLOB) 2500byte 이하의 데이터는 SHORT_CONTEXT 에 저장되는데, 해당 컬럼이 MS949 기반 VARCHAR2 이다 보니 UTF-8 기반으로 직렬화된 ExecutionContext 내 한글 데이터가 깨지면서 다음 실행 시 역직렬화 실패가 발생한 것으로 판단했습니다. 4. 고민 중인 해결 방안 현재 아래와 같은 방안들을 검토 중입니다. ExecutionContext에 한글 자체를 사용하지 않도록 제한 로깅/메시지 성 데이터는 저장하지 않거나, 필요 시 영문만 사용 ExecutionContext에 putString 시 인코딩 설정 ExecutionContext 직렬화 방식 변경 ExecutionContextSerializer 를 DefaultExecutionContextSerializer 명시정으로 설정 (Spring Batch 4는 기본적으로 JacksonExecutionContextStringSerializer) 5. 질문 강사님께서 보시기에 위 상황에서 가장 권장되는 해결 방향 또는 실무적으로 안전한 접근 방식 은 무엇이라고 생각하시는지 궁금합니다. 긴 글 읽어주셔서 감사드리며, 가능하실 때 조언 주시면 많은 도움이 될 것 같습니다. 감사합니다.
자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]
@PutMapping("/user") public void updateUser(@RequestBody UserUpdateRequest request){ String readSql = "select * from user where id=?"; String sql = "update user set name=? where id=?"; jdbcTemplate.update(sql, request.getName(), request.getId()); } 웹페이지에서 update를 발생시켜서 put 요청이 올라 왔을때 UserUpdateRequest dto에 id와 name이 들어 간다는건 웹에서 요청이 올라왔을때 json에 이미 해당 name에 대한 id 정보가 있다는 거죠? id는 db에서 자동적으로 생성해 준다고 했었는데, 이 id를 웹에서는 어떻게 알고 있나요?
안녕하세요 토비님!! 강의를 완강하고 제 프로젝트를 리팩토링하면서 피드백받고싶은점이 생겨 질문글을 올립니다. Repository Port를 기술에 종속시키지 않기 위해 Adapter에서 JPA, MyBatis, QueryDSL을 조합하는 구조를 선택했는데, 이 설계 방향이 적절한지 조언을 구하고 싶습니다. 현재 구조 core/ └── domain/ └── application/ └── required/ ← Port 인터페이스 └── ~Repository adapter/ └── persistence/ ├── ~RepositoryAdapter ← Port 구현체 ├── ~JpaRepository ← Spring Data JPA └── ~MybatisMapper ← Mybatis 매퍼 인터페이스 의존 관계 [Service] → [Repository] ←impl― [RepositoryAdapter] → [JpaRepository] → [MybatisMapper] → [JPAQueryFactory] (core) (core) (adapter) (adapter) 예시 @Repository @RequiredArgsConstructor public class ItemRepositoryAdapter implements ItemRepository { private final ItemJpaRepository itemJpaRepository; private final ItemMybatisMapper itemMybatisMapper; @Override public List<Item> findBySearchRequest(ItemSearchRequest request) { return itemMybatisMapper.findBySearchRequest(request) .stream() .map(Item::from) .toList(); } @Override public List<Item> saveAll(List<Item> items) { return itemJpaRepository.saveAll(items); } } @Repository @RequiredArgsConstructor public class AuctionRepositoryAdapter implements AuctionRepository { private final JPAQueryFactory jpaQueryFactory; private final AuctionJpaRepository auctionJpaRepository; @Override public void deleteAllByRegionAndRealmId(RegionType region, Long realmId) { QAuction qAuction = QAuction.auction; BooleanBuilder filter = new BooleanBuilder(); filter.and(qAuction.region.eq(region)); if (realmId == null) { filter.and(qAuction.realmId.isNull()); } else { filter.and(qAuction.realmId.eq(realmId)); } jpaQueryFactory.delete(qAuction) .where(filter) .execute(); } @Override public int saveAll(List<Auction> auctions) { if (auctions.isEmpty()) return 0; return auctionJpaRepository.saveAll(auctions).size(); } } 이 구조를 선택한 이유 동적 쿼리, 벌크 연산 등 JPA만으로 해결하기 어려운 케이스가 있어 MyBatis와 QueryDSL을 병행 사용하고 있습니다. 일반적인 방식인 Port 인터페이스가 Spring Data JPA Repository를 상속하는 구조를 채택하지 않은 이유: MyBatis나 QueryDSL 기반 구현체를 만들 수 없음 CustomRepository 인터페이스를 별도로 만들어야 하는 복잡도 증가 현재 방식의 장점: Port 인터페이스가 순수 Java 인터페이스로 유지됨 RepositoryAdapter에서 상황에 맞는 기술을 자유롭게 조합 가능 추가 인터페이스 없이 단순한 구조 유지 저는 현재 구조가 의존 관계도 외부에서 내부로 향하고 테스트도 쉬워서 괜찮다고 생각하는데 토비님의 생각도 듣고싶습니다!! 좋은 강의 감사합니다!!
