CodePrep

📘 1. 현재 구조의 한계 📋 테이블 설계 (기존 방식)PRODUCT_COMBO_COMPONENT_ONE PRODUCT_COMBO_COMPONENT_TWO PRODUCT_COMBO_COMPONENT_THREE💣 문제점• 구성품이 4개 이상이면 저장 자체가 불가• MyBatis 매핑에서 OR ... OR ... 하드코딩 반복• 구성품 수가 늘어날수록 쿼리, VO, 화면 모두 전면 수정 필요📘 2. 확장 가능한 테이블 구조로 리팩토링 ✅ 테이블 정규화CREATE TABLE PRODUCT_COMBO_COMPONENT ( PRODUCT_COMBO_COMPONENT_NUMBER NUMBER PRIMARY KEY, PRODUCT_COMBO_NUMBER NUMBER NOT NU..

피드백 #1. “30% 할인이라고 써 있는데 왜 더 싸지?”→ 단순 조합 할인만 출력될 경우, 실제 할인 체감도 떨어짐 ❓ 현상• 조합상품에 대해 30% 할인만 보여주는 구조• 구성 상품에도 10%, 20%씩 이미 할인 적용된 경우가 있음• 소비자 입장에선 "어? 할인 별로 없네?"라고 인식• 실제로는 원가 대비 40% 넘게 깎였는데도 표시 안됨 ❗ 핵심 논점• 단순 조합 할인율만 보여줘선 할인 혜택 체감 어려움• 개별 할인 + 조합 할인의 누적 결과가 최종가• 따라서 표시해야 할 할인율 = 총 할인율(%)✅ 계산 조건항목값A 상품1000원 → 10% 할인 → 900원B 상품1000원 → 20% 할인 → 800원개별할인 후 총합900 + 800 = 1700원조합할인 30% 적용1700 × 0.7 = 11..

🔧 1. “테스트 결제인데 왜 실패하지?”→ 화면 공유/녹화, 실제로 결제 실패 유발함 ❓ 현상테스트 환경에서 카카오페이 결제 테스트 중브라우저에서 결제하기 클릭 → 바로 “결제 실패” 발생결제 API 요청은 정상인데, 창이 뜨자마자 실패❗ 핵심 논점단순 오류 아님카카오페이는 화면 녹화·공유·미러링 감지 시, 결제를 보안상 차단함실결제든 테스트 API든 예외 없음✅ 감지 조건 1️⃣ Google Meet, Zoom 등 화면 공유 중2️⃣ OBS, macOS 녹화 도구 등 화면 녹화 중3️⃣ 스마트뷰, 크롬캐스트 등 화면 미러링 중 모두 보안 위협으로 인식되어결제창(WebView or 앱) 진입 시 즉시 실패 처리🔍 어떻게 감지하나? 1️⃣ Android: FLAG_SECURE로 캡처 차단2️⃣ iOS..

🛠️ 1. “할인 계산 위치는 정해져 있다?”→ 아니다. 책임과 맥락이 기준 ❓ 현상서비스 설계 시 할인 계산을 프론트에서 할지, 백엔드/DB에서 할지 논의 발생일부 개발자는 "프론트에서 하면 UX 빠르다", 일부는 "백엔드가 정합성 보장된다"고 주장❗ 핵심 논점실제로는 "둘 다 가능"한 것이 아니라,책임 소재와 보안, 유지보수 기준에 따라 위치가 결정됨 ✅ 정리 기준판단 기준백엔드 적합프론트 적합보안성쿠폰/포인트/회원등급 등 민감 정보 포함단순 고정 비율 할인정책 변경 빈도잦은 할인율 변경거의 없음계산 복잡도등급+쿠폰+이벤트 중첩10% 고정 할인기록/정산 연계DB 저장값 기준 정산 필요표시 전용UI 반응성속도보다 정합성이 중요빠른 피드백 제공⚙️ 2. 실무 적용 기준은 “표시용 vs 결제용” ❓ 현상..

🛠️ 1. InfoWindow는 떴는데, 편의점 정보는 안 보임 ❓ 현상마커 클릭 시 InfoWindow는 열리지만, 편의점 이름과 주소가 비어 있거나 undefined로 표시됨⁉️ 원인카카오 장소 검색 결과에서 road_address_name이 없는 경우가 있어, undefined로 표시됨또한 place.y, place.x의 좌표 값을 kakao.maps.LatLng에 넘기지 않고 바로 출력하는 실수도 있었음✅ 해결주소 출력 시 road_address_name || address_name 방식으로 처리좌표 변환 시 new kakao.maps.LatLng(place.y, place.x)로 명확히 객체 생성 후 사용🛠️ 2. 가장 가까운 편의점이 아닌, 배열 첫 번째만 표시됨 ❓ 현상검색된 편의점 중 ..

🛠️ 1. 에디터 미출력 이슈 ❓ 현상등록 페이지 진입 시 CKEditor가 화면에 보이지 않음⁉️ 원인JS에서 초기화한 textarea ID와 JSP 상 ID 불일치✅ 해결ID를 정확히 일치시키자 에디터 정상 출력🛠️ 2. 이미지 미리보기 불가 ❓ 현상이미지 삽입 시 CKEditor에 미리보기가 보이지 않음⁉️ 원인CKEditor는 단순 경로가 아니라 업로드 후 반환된 URL을 로 삽입해야 함✅ 해결이미지를 서버에 업로드 후 JSON 형태로 URL 반환 → 에디터에서 삽입되도록 구현🛠️ 3. 이미지 업로드 프로세스 오해 🧠 초기 생각클라이언트에서 로컬 경로로 미리보기를 띄우는 줄 착각 🔁 실제 동작📤 폼데이터로 서버에 업로드 → 📨 URL 응답 → 🖼️ 자동 삽입🛠️ 4. 한글 파일명..

🔹 1. 에디터 커스터마이징 목적 1️⃣ 게시글 작성 중 이미지 직접 업로드 기능 제공2️⃣ 에디터에서 태그 삽입까지 실시간 자동 처리3️⃣ 사용자 UX 중심 작성 환경 구현🔹 2. 업로드 서버 구조 (Java/Spring) 📌 컨트롤러 경로• POST /boardCombo/CKEditor5/uploadImage• GET /boardCombo/CKEditor5/loadImage 📌 업로드 처리 흐름 ✅ MultipartFile 수신✅ UUID 기반 고유 파일명 생성✅ upload.path 경로에 저장✅ 이미지 URL 반환 (/loadImage?name=...) 📌 이미지 불러오기 처리 ✅ 저장된 경로에서 파일 조회✅ Files.probeContentType() → MIME 타입 설정✅ byte..

🔹 18. 리뷰 이후의 작성자 역할 📌 18-1. 리뷰 피드백 반영 시 주의사항 ✅ 단순 수정이 아닌, 피드백의 의도 파악이 중요✅ PR에 리뷰가 달리면 "수정 커밋"으로 반영 → 리뷰 흐름 유지✅ 리뷰어가 남긴 질문에는 답글 또는 수정 이력으로 응답 📌 18-2. 리뷰어 제안을 수용하지 않을 경우 ✅ 이유 설명 → 논의 유도✅ 무시 ❌, 대화 ⭕ (기술적 근거 + 현재 컨텍스트 기반 판단)🔹 19. 리뷰어의 승인 기준 📌 19-1. Approve 판단 기준 ✅ 변경사항 충분히 검토 후 👍 Approve✅ 동작 확인, 코드 일관성, 사이드 이펙트까지 고려 ➡️ 단순 통과용 리뷰는 의미 없음 → 책임감 있는 승인 필요 📌 19-2. 승인 전 확인 포인트🔍 테스트 통과 여부📁 주요 파일 변경..

🔹 17. 리뷰어/작성자 역할 분담 기준과 매너 📌 17-1. PR은 "검토받을 준비"가 되었을 때만 생성👉 PR을 리뷰어에게 보내는 건 검토 요청이 아닌 검토 책임 이관 ➡️ 미완성/충돌 있는 PR은 혼란만 유발 ✔️ 리뷰 전에 아래 체크리스트 완료하기 : 🔍 git diff로 변경 내역 스스로 검토📂 누락된 파일 없는지 git status 확인📝 커밋 메시지 논리적이고 목적별로 구성📄 PR 설명에 기능 요약, 주의사항, 제외 파일 명시 📌 17-2. 리뷰어는 '방어적 리뷰'가 아니라 '협력적 리뷰'👉 단순 오류 찾기보다 개선 제안과 대안 제시가 핵심 ➡️ “이 부분 문제 있음”보다 “이런 방향은 어떨까요?”가 더 생산적✔️ 코드 컨벤션, 테스트 범위, 성능 영향까지도 함께 고려 📌..

🔹 16. 협업 효율을 높이는 브랜치 전략 📌 16-1. 브랜치는 목적별로 분리👉 기능 개발, 버그 수정, 실험 등 브랜치 목적을 명확히 구분 ✔︎ 예시 :• feat/login-auth• fix/board-comment-npe• test/image-upload ➡️ 브랜치 이름만 봐도 작업 내용을 알 수 있어야 함 📌 16-2. main/master 브랜치는 항상 배포 가능 상태 유지👉 직접 커밋 ❌ / 오직 PR을 통해서만 병합👉 긴급 핫픽스는 별도 hotfix/ 브랜치로 관리 ➡️ 품질 안정성과 신뢰도 확보 📌 16-3. PR은 작은 단위로 자주 보내기👉 2,000줄짜리 PR보다 200줄 PR이 리뷰와 테스트에 훨씬 유리 • 변경량이 많아질수록 리뷰 지연 → 병합 지연 → 갈등 발생 ..