안녕하세요 강사님. 지난번 '어드민 예약 변경 시 쿠폰 회수' 관련 질문을 드렸던 수강생입니다. 답변 주신 내용을 바탕으로 설계를 보완하던 중, 스냅샷 데이터의 범위와 확장성 에 대해 추가적인 고민이 생겨 조언을 구합니다. [현재 아키텍처 상황] 현재 예약 테이블에는 예약 시점의 가격 정보를 JSON 형태의 스냅샷 으로 저장하고 있습니다. 이유: 가격 결정 요소(할인, 이벤트, 기업 지원 등)가 빈번하게 변경/추가되어 RDB 컬럼으로 대응하기 어렵기 때문입니다. 저장 데이터: 현재는 '결과값' 위주로 저장합니다. (예: 적용된 할인 명, 타입(정액/정률), 최종 할인 금액) [직면한 문제: 변경 시점의 기준 모호성] 예약 시점(T1)과 변경 시점(T2) 사이에 정책이 변경되었을 때, 어드민에서 예약을 수정하면 어떤 정책을 따라야 하는가 에 대한 딜레마입니다. 만약 기획 요구사항이 "변경 시점(T2)의 정책이 아니라, 최초 예약 시점(T1)의 정책 조건을 유지한 채 금액만 다시 계산해 주세요" 라고 한다면 문제가 복잡해집니다. 현 구조의 한계: 현재 JSON에는 '결과(할인액)'만 있고 '조건(최소 결제 금액, 당시 허용된 옵션 목록 등)'은 없습니다. 예상되는 부작용: 이를 해결하려면 예약 시점의 모든 검증 조건(Condition) 을 JSON에 다 때려 넣어야 합니다. 이렇게 되면 도메인 로직이 바뀔 때마다 JSON 스키마도 계속 비대해지고, 과거 JSON 데이터와 현재 로직 간의 정합성을 맞추기 매우 까다로워질 것 같습니다. [질문] 이처럼 "빈번하게 변하는 가격 정책"과 "과거 기준 수정"을 동시에 만족해야 할 때, 실무에서는 보통 어떤 접근 방식을 취하나요? JSON 스냅샷 확장: 다소 복잡해지더라도 예약 시점의 검증 조건(Parameter)들까지 모두 JSON에 스냅샷으로 남기는 게 맞나요? (JSON 컬럼 사용이 잘못된 선택이었을까요?) Policy Versioning (정책 버전 관리): 아니면 가격/할인 정책 테이블 자체를 버전 관리(Effective Date 등)하여, 예약 시점의 policy_version_id 를 매핑해두고 로직을 태우는 방식을 써야 할까요? 현실적인 타협: 아니면 보통 어드민 변경 건은 "재계산 불가(단순 금액 입력)"로 처리하거나, "무조건 현재(T2) 정책"을 따르게 하는 등 복잡도를 낮추는 타협점을 찾나요? 확장성 있는 가격 스냅샷 설계에 대한 강사님의 경험과 조언을 부탁드립니다..!
The 10x AI-Native Developer: 회사에서 AI로 압도적 성과를 내는 법
안녕하세요. 회사에서도 AI 도구(Claude Code)를 적극적으로 사용하고 계신 것 같았는데, 보안 관점에서 AI 도구 사용에 대한 내부 가이드나 기준이 있는지 궁금합니다. 실제 딩코딩님 회사에서는 개발자들이 AI 도구를 어떤 범위까지 사용하도록 허용 하고 있는지, 그리고 현업에서 보안적으로 특히 고려해야 할 부분 은 무엇인지 알고 싶습니다. 예를 들어, 실제 민감한 고객 데이터 는 AI 도구에 질문하거나 제공하지 않도록 한다든지, 또는 credential이 포함된 코드 에서는 AI 도구 사용을 금지한다든지, 내부 시스템 아키텍처나 인프라 구조 는 AI에 제공하지 않도록 한다든지, 혹은 회사 내부의 특정 핵심 로직 은 민감해서 AI 사용을 제한한다든지요. 이처럼 AI 도구 사용과 관련해 내부적으로 정해진 기준이나 가이드라인이 있다면 , 어떤 식으로 운영되고 있는지 공유해주실 수 있을지 궁금합니다.
안녕하세요, 강의 잘 수강하고 있습니다 😃 40강에서 Naver 이메일의 text를 가져오려고 Email get many 노드에서 text content를 포함하니 무한 로딩에 걸립니다. content 크기 문젠가 싶어 limit을 1로 잡아도 그러네요. ↑text content 포함 시 ↑text content 미포함 시 text content와 html content에서 그런 문제가 발생하고 다른 값(header 등)을 선택하면 문제가 없습니다. 네이버 이메일 문제인지 싶어서 Gmail도 해보니 똑같네요. 원인을 알고 싶습니다ㅠ
