176만명의 커뮤니티!! 함께 토론해봐요.
미해결
AWS SAA-C03 자격증 벼락치기 - 딱 163문제로 2주만에 합격하기
해답에 (A)가 오답인 이유가 Glacier 유형은 법/감사/규정 목적으로 장기 보관해야 되는 경우에만 사용하기 때문이라고 해설이 되어 있는데 문제에는 회사의 보안 규정에 스토리지 전략을 따르는 것으로 주어져 있습니다. 문제에서의 회사의 보안 규정이 법/감사/규정에 포함되지 않는건가요?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요. 최근 객체 간 의존 방향 고민에 많은 시간을 쏟고 있어 질문드립니다. 핵심 질문 도메인/서비스 간 의존 방향을 결정할 때 어떤 기준을 적용하면 좋을까요? "누가 누구를 알아야 하는가"에 대한 판단 기준이나 원칙이 있을까요? 저는 덜 중요한 개념의 변경이 중요한 개념에 영향을 주면 안된다고 생각하고 있었습니다. 그래서 중요한 개념이 덜 중요한 개념을 모르도록 코드를 짜려고 노력하는데요. 막상 개발할 때는 이게 잘 안되어서 고민에 시간을 많이 사용하거나, 타협하곤 합니다. 이런 상황이 이번 강의를 보면서도 나타나 질문글을 작성하게 되었습니다. 구체적인 상황 그런데 강의에서 download 메서드를 CouponService로 이동하는 과정을 보고 다음과 같은 의문이 들었습니다: 변경 후 구조: CouponService → OwnedCoupon, OwnedCouponRepository 의존 OwnedCoupon → Coupon, CouponRepository 의존 우려 사항: Coupon과 OwnedCoupon이 서로를 알게 되는 것이 순환 참조나 강결합을 유발하지 않을까? OwnedCoupon에 필드 추가 시, 기존에는 OwnedCouponService만 수정하면 됐지만 이제는 CouponService도 함께 수정해야 함 논리적으로는 CouponService에 download 기능이 있는 것이 맞아 보이지만, Coupon과 OwnedCoupon이 서로 알게 되는 것이 괜찮은 설계인가? 이런 고민에 시간을 많이 쓰다 보니 개발 시간이 부족하다고 느껴집니다. 마감을 위해 구현 후 리팩토링하는 방식으로 진행하고 있지만, 리팩토링을 못할 때도 많고 마음의 짐으로 남는 것 같습니다. 조언 부탁드립니다. 감사합니다.
미해결
죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
킬9형 안녕 실무에서 Spring batch를 실행해줄 스케줄러와 batch 실행 환경은 어떤게 있는지 궁금해. 현재 인프라는 AWS에서 EKS, ElastiCache(Redis), Aurora MySQL을 사용하고 있어.
해결됨
제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
jwt가 뭔지 왜 사용하는건지에 대한 자세한 내용은 안 다루는거 같고 전반적인 crud의 감만 잡고 넘어 가는건지 궁금합니다. 이부분을 part2에서 제대로 배우는지 아님 제가 추가로 학습을 해야하는 부분일까요? 설명히 제대로 안 된 부분들을 직접 찾아서 공부하면서 강의를 듣다보니 흐름도 깨져서 파트2 에서 다룬다면 전반적인 구현정도로만 넘어가려고 질문드립니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 레거시와 AI 활용편
안녕하세요 강사님. 지난번 '어드민 예약 변경 시 쿠폰 회수' 관련 질문을 드렸던 수강생입니다. 답변 주신 내용을 바탕으로 설계를 보완하던 중, 스냅샷 데이터의 범위와 확장성 에 대해 추가적인 고민이 생겨 조언을 구합니다. [현재 아키텍처 상황] 현재 예약 테이블에는 예약 시점의 가격 정보를 JSON 형태의 스냅샷 으로 저장하고 있습니다. 이유: 가격 결정 요소(할인, 이벤트, 기업 지원 등)가 빈번하게 변경/추가되어 RDB 컬럼으로 대응하기 어렵기 때문입니다. 저장 데이터: 현재는 '결과값' 위주로 저장합니다. (예: 적용된 할인 명, 타입(정액/정률), 최종 할인 금액) [직면한 문제: 변경 시점의 기준 모호성] 예약 시점(T1)과 변경 시점(T2) 사이에 정책이 변경되었을 때, 어드민에서 예약을 수정하면 어떤 정책을 따라야 하는가 에 대한 딜레마입니다. 만약 기획 요구사항이 "변경 시점(T2)의 정책이 아니라, 최초 예약 시점(T1)의 정책 조건을 유지한 채 금액만 다시 계산해 주세요" 라고 한다면 문제가 복잡해집니다. 현 구조의 한계: 현재 JSON에는 '결과(할인액)'만 있고 '조건(최소 결제 금액, 당시 허용된 옵션 목록 등)'은 없습니다. 예상되는 부작용: 이를 해결하려면 예약 시점의 모든 검증 조건(Condition) 을 JSON에 다 때려 넣어야 합니다. 이렇게 되면 도메인 로직이 바뀔 때마다 JSON 스키마도 계속 비대해지고, 과거 JSON 데이터와 현재 로직 간의 정합성을 맞추기 매우 까다로워질 것 같습니다. [질문] 이처럼 "빈번하게 변하는 가격 정책"과 "과거 기준 수정"을 동시에 만족해야 할 때, 실무에서는 보통 어떤 접근 방식을 취하나요? JSON 스냅샷 확장: 다소 복잡해지더라도 예약 시점의 검증 조건(Parameter)들까지 모두 JSON에 스냅샷으로 남기는 게 맞나요? (JSON 컬럼 사용이 잘못된 선택이었을까요?) Policy Versioning (정책 버전 관리): 아니면 가격/할인 정책 테이블 자체를 버전 관리(Effective Date 등)하여, 예약 시점의 policy_version_id 를 매핑해두고 로직을 태우는 방식을 써야 할까요? 현실적인 타협: 아니면 보통 어드민 변경 건은 "재계산 불가(단순 금액 입력)"로 처리하거나, "무조건 현재(T2) 정책"을 따르게 하는 등 복잡도를 낮추는 타협점을 찾나요? 확장성 있는 가격 스냅샷 설계에 대한 강사님의 경험과 조언을 부탁드립니다..!
해결됨
제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
현재 강의에서 serveStatic 함수를 통해 정적 파일 요청을 처리합니다. 하지만 보통은 정적인 파일들 요청을 위해 apache 서버를 사용하고 node.js 는 동적인 요청을 위해서 쓰이는 경우가 대부분이라고 생각하는데 맞을까요?
미해결
카카오 PlayMCP와 Spring AI가 만나는 실전 에이전트 개발
안녕하세요 강사님! 13강에서 MCP Client을 구현한 뒤 postman으로 /w 엔드포인트로 호출 시 500에러가 납니다. “message”: “You exceeded your current quota, ~” OpenAI 크레딧을 따로 구매해야 되는 걸까요?
미해결
AWS SAA-C03 자격증 벼락치기 - 딱 163문제로 2주만에 합격하기
자료에서 제공해주시는 문제들이 강사님께서 수강자들 이해를 돕기 위한 형태로 직접 내용 제작하신건지, 아니면 실제 덤프 문제를 번역해서 강의 및 해설해주시는 건지가 궁금합니다.
해결됨
제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
Express.js를 사용하면 res.writeHead(200, { "content-type": "text/html"}) 위와 같은 writeHead가 자동으로 들어가게 되나요? 또 node는 Express.js와 달리 여러 에러 400, 500에 대해 일일이 writeHead를 달아줘야 하는지도 궁금해요
해결됨
제미니의 개발실무 - 커머스 백엔드 레거시와 AI 활용편
이전강의에 이어 이번강의도 또 듣게되네요 선생님께서 늘 강의에서 느낀다 라는 표현을 많이 하시는데 이게 되게 중요한건가 보네요 잘 듣겟습니다
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요 실무에서 '관리자(Admin) 예약 변경 기능' 정책을 두고 기획팀과 이견이 있어, 실무에서는 어떤 방식이 범용적인지 여쭙고 싶습니다. [시스템 상황] 유저가 예약할 때 다양한 할인(이벤트, 타임세일, 쿠폰, 기업지원 등)이 적용되며, 이 정보는 예약 시점에 스냅샷(Snapshot) 으로 저장됩니다. 현재 어드민(상담원/운영팀) 이 유저의 예약 시간/날짜를 변경하는 기능을 개발 중입니다. [이슈 사항] 기획상으로는 어드민에서 시간을 변경할 때도 모든 할인 조건을 '실시간'으로 재검증 하라고 합니다. 문제는 재검증 과정에서 '쿠폰 박탈' 같은 상황이 발생한다는 점입니다. 예시 상황: 유저가 5만원 짜리 예약에 5만원 이상 결제 시 사용 가능한 10% 쿠폰 을 씀. 어드민이 사정상(또는 유저 요청으로) 가격이 저렴한 타임이나 옵션으로 변경함 -> 결제액이 4만원 이 됨. 기획 요구사항: "최소 결제 금액(5만원) 조건을 불만족하게 되었으니, 자동으로 쿠폰 적용을 해제(원복)하고 금액을 재계산 한다." [제(개발자) 의견 및 고민] 저는 위 기획이 어드민 기능의 목적 과 UX(고객 경험) 에 맞지 않는다고 생각합니다. 고객 경험 훼손: 유저는 단지 시간을 바꿨을 뿐인데, 시스템이 엄격하게 검증해서 "조건 미달이니 쿠폰 뺏어가겠습니다"라고 하면 컴플레인 요지가 다분합니다. (유저 입장에선 혜택 유지를 원하니까요.) 데이터 복잡도: 이미 스냅샷으로 저장된 할인 정보를, 수정 시점에 다시 현재 기준의 마스터 데이터(쿠폰 유효기간, 최소금액 등)와 대조해서 '줬다 뺏는' 로직을 짜는 건 구현 복잡도 대비 실익이 너무 적습니다. 관리자의 재량: 어드민에서의 변경은 보통 '강제성(Override)' 을 띠는 경우가 많은데, 시스템이 칼같이 혜택을 잘라버리는 게 맞나 싶습니다. [질문] 보통 예약 도메인에서 관리자(Admin)가 개입하여 예약을 변경할 때 도, 이렇게 엄격하게 유저의 할인 자격(최소금액, 유효기간 등)을 재검증하여 박탈 시키는 게 맞나요? 아니면 어드민 권한 변경인 경우 "기존 스냅샷(혜택)을 최대한 유지" 해주거나, 가격 변동이 불가피하면 "취소 후 재예약" 을 하는 프로세스가 더 일반적인가요? 개발자로서 이 복잡한 '조건부 쿠폰 회수' 로직을 방어하고 싶은데, 설득력 있는 논리가 필요합니다. 조언 부탁드립니다!
미해결
AI 시대에 살아남기: Supabase로 백엔드 뚝딱!
작년 12월 러바블을 시작으로 커서, 안티그래피 그리고 클로드코드 등을 활용하여 바이브코딩을 해왔습니다. 그러면서 백엔드의 중요성을 몸소 느끼게 되었죠. 아주 간단한 건 버셀과 수파베이스를 어찌저찌 ai에게 물어보면서 연동을 했지만, 전문적인 지식이 필요함을 느끼게 되었습니다. 그러던 중 기적처럼 어제 이 강의가 개설된 것을 알게 되었죠. 너무 감사합니다. 한번 열심히 배워보겠습니다. 비개발자 출신이기에 다소 어려울 수도 있겠지만 뭐 하다보면 되겠죠 .ㅎ
미해결
AI 시대에 살아남기: Supabase로 백엔드 뚝딱!
수파베이스에 대한 갈증이 있었는데 타 플랫폼도 그렇고 한국강좌가 없어서 많이 아쉬워하고 있었는데요 인프런에 2만2천원짜리 강의하나밖에 없어서 그것을 듣긴했는데 그것만으론 많이 아쉬움을 느끼고 있던차에 이 강의가 나왔다는 메일을 받고 정말 기뻐서 바로 결제했습니다 수파베이스를 활용해서 만들고싶은 것들이 잔뜩 머릿속에 있거든요 감사히 잘 듣겠습니다.
미해결
AWS SAA-C03 자격증 벼락치기 - 딱 163문제로 2주만에 합격하기
순서상 1p 에 수업자료 목록이 나와야 할 것 같은데 25p에 작성되어 있습니다. 25p 에는 ECS, Lambda .. 가 와야할 것 같은데 해당 내용 자체가 pdf 파일에 누락되어 있습니다.
미해결
죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
킬구형 내가 그동안 보면서 정리한내용으로, 실습을 진행해보려고 혼자 스스로 파일을 만들었어. 실습 환경은 h2 데이터 베이스로 테스트 했고, 메타테이블은 자동으로 만들어졌어. 간단한 스텝과 잡을 만들어서 콘솔에서 잘 실행되는것 까지는 확인을 했는데 실제 데이터 베이스 테이블인 batch_job_instance와 같은 테이블에는 데이터가 들어가지 않아. 혹시 몰라서 db url도 확인해봤는데 정확하게 일치하고.. 이런경우는 어디를 확인해보면 제일 좋을까..? 콘솔에서 에러도 나지 않고 정상적으로 배치가 실행돼서 답답해 미치겠어 ㅠㅠㅠ 콘솔에서 insert 쿼리는 안나가고 있는데, 쿼리가 왜 안나가는지를 도통 모르겠어 ㅠㅠ 다 잘되는데 메타테이블에만 데이터가 들어가지 않네.. 참고로 tasklet 방식으로 테스트 해봤어. 부트 4.0.1 버전 사용하고 있어 킬구형 강의자료 에서도 중간에 postgresql로 전환하던데 혹시 h2는 뭔가 지원을 하지 않는걸까?
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
안녕하세요! 수업 잘 듣고 있습니다. 사소한 내용이긴한데.. 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(), ) } }
해결됨
제대로 배우는 Express.js: Part1 기초부터 심화까지 [기초편]
readFileSync 메서드는 동기적인 메서드라 이벤트 루프에서 막혀서 파일을 읽어오는동안 스레드를 멈춰서 실무에선 잘 사용 안 하지 않나요? 단순히 서버의 흐름 이해를 돕기위한 코드 정도로 이해해도 될까요? 혹시 이 강의는 express와 서버의 개념만 이해하고 넘어가는 정도의 강의일까요? 실무적인 관점의 강의는 파트 2라고 보면 될까요 아님 파트1 파트2 모두 실무적인 관점의 코드는 작성하지 않고 넘어가나요?
미해결
죽음의 Spring Batch: 새벽 3시의 처절한 공포는 이제 끝이다.
안녕하세요, 강사님. 강의와 직접적인 내용은 아니지만, 사내에서 발생한 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. 질문 강사님께서 보시기에 위 상황에서 가장 권장되는 해결 방향 또는 실무적으로 안전한 접근 방식 은 무엇이라고 생각하시는지 궁금합니다. 긴 글 읽어주셔서 감사드리며, 가능하실 때 조언 주시면 많은 도움이 될 것 같습니다. 감사합니다.
해결됨
카카오 PlayMCP와 Spring AI가 만나는 실전 에이전트 개발
"섹션 6. 커스텀 클라이언트 제작 및 최종 데모"에서 "25. BibleMCPClient 직접 설계 및 만들기"와 "26. Client-Side MVC 로직 및 UI 연동"의 강의 영상이 동일합니다. 확인 부탁드립니다.
해결됨
제미니의 개발실무 - 커머스 백엔드 기본편
상황 정리 저희가 매장 관리자용 통합 예약 관리 시스템 을 개발하고 있습니다. 현재 시스템 구조 [외부 예약 플랫폼 (네이버 같은)] ↓ 자동 연동 [매장 POS 시스템 (티오더 같은)] ↓ API 폴링 [우리 통합 관리 시스템] 고객이 외부 플랫폼에서 예약하면 POS에 자동으로 들어옴 우리는 POS API를 폴링해서 예약 데이터를 가져옴 우리 어드민에서 직접 예약 등록 기능도 곧 추가 예정 문제 상황 POS 업체에 확인해보니: API에서 외부 플랫폼 예약 구분이 안 됨 → 구분값 추가 예정 외부 예약은 원칙적으로 수정 불가 현재는 수정이 되지만 플랫폼 API 키가 연결 안 되어 사실상 불가능 DB만 바꿔서는 의미 없고, 외부 플랫폼 API 재호출이 필요 POS와 외부 플랫폼 간 연동이 아직 불완전한 상태 논의된 두 가지 방향 A안 (readonly 방식) - 우리 어드민 생성 예약 → POS 직접 등록 (수정 가능) - 외부 플랫폼 예약 → POS에서 폴링해서 조회만 (수정 불가) - UI에서 "외부 예약" 표시하고 수정 버튼 비활성화 - 수정 필요시 원본 플랫폼 바로가기 링크 제공 B안 (통합 수정 방식) - 모든 예약을 우리 시스템에서 직접 수정 가능하게 - 외부 예약 수정 시 POS API → 외부 플랫폼 API 호출까지 처리 장단점 분석 A안 장점 각 시스템의 책임 범위가 명확함 동기화 정합성 이슈 없음 외부 플랫폼 정책 변경에 영향 안 받음 여러 플랫폼을 한 곳에서 조회만 해도 관리자 리소스 절감 효과 A안 단점 수정은 여전히 각 플랫폼에서 해야 함 "진정한 통합 관리"는 아님 B안 장점 완전한 통합 관리 경험 관리자가 한 곳에서 모든 예약 제어 B안 단점 외부 플랫폼 API 직접 연동 불가 (계약 주체가 매장) POS가 외부 플랫폼 제어 API를 제공해야 하는데 현재 없음 POS-외부 플랫폼 양쪽 동기화 복잡도 높음 외부 플랫폼 정책(취소규칙 등) 변경 시 계속 대응 필요 문제 발생 시 책임 소재 애매 질문 이런 다중 오리진 데이터를 통합하는 시스템 에서: readonly로 가는 게 맞을까요, 아니면 수정까지 구현해야 할까요? 단계적으로 접근한다면 어떤 순서가 좋을까요? 1단계: 통합 조회만 2단계: POS가 API 제공하면 그때 수정 추가 비슷한 사례에서 일반적으로 어떻게 접근하나요? 현재 상황에서는 A안(readonly)이 합리적이라고 판단됩니다. 하지만 시간이 지나서 다음 조건들이 충족된다면: POS에서 외부 예약 플랫폼 식별값을 제공 외부 예약 플랫폼 API를 저희가 제공받을 수 있음 그때는 어떤 아키텍처로 가야 할까요? 옵션 1: 직접 호출 방식 [우리 시스템] → [외부 플랫폼 API] (직접 호출) → [POS API] (동기화용) 우리가 외부 플랫폼 API를 직접 호출 POS는 조회 + 동기화 확인용으로만 사용 옵션 2: POS Proxy 방식 [우리 시스템] → [POS API] → [외부 플랫폼 API] POS가 외부 플랫폼 제어 API를 제공하도록 요청 우리는 POS API만 호출하면 POS가 내부적으로 플랫폼 API 처리 외부 플랫폼 변경사항은 POS가 책임 옵션 3: readonly 유지 [우리 시스템] → [POS API] (조회만) 기술적으로 가능해져도 readonly 유지 각 플랫폼 바로가기만 제공 어떤 방식이 일반적이고, 각 옵션의 trade-off는 무엇인가요? 특히 옵션 1 vs 옵션 2에서: 우리가 직접 여러 외부 API를 관리하는 게 나을까요? 아니면 POS가 Proxy/Gateway 역할을 하게 하는 게 나을까요?
