본문 바로가기

전체 글

주문·취소 연동에서 중복 처리를 막기 위한 DB 선점 처리 외부 제휴 연동이나 주문·취소 배치 작업을 하다 보면 같은 데이터가 여러 번 처리될 가능성을 항상 고려해야 한다. 특히 주문, 취소, 클레임처럼 짧은 시간 안에 많은 요청이 들어오고 상태가 계속 바뀌는 업무에서는 단순히 “대상 데이터를 조회해서 처리한다”는 방식만으로는 안전하지 않다.예를 들어 취소 대상 데이터를 조회한 뒤 처리하는 도중에 다른 배치나 수동 처리 로직이 같은 데이터를 다시 가져가면, 동일 건에 대해 중복 API 호출이 발생하거나 내부 상태가 두 번 변경될 수 있다. 외부 API 호출은 성공했지만 내부 후처리가 실패하는 경우, 반대로 내부 상태는 변경됐지만 외부 전송 결과를 저장하지 못하는 경우도 생길 수 있다. 그래서 이런 업무에서는 “지금 이 데이터는 누가 처리 중인가?”를 DB 기준으.. 더보기
제휴사 개발을 위한 멱등성 처리는? 외부 제휴 API 취소 연동에서 멱등성이 중요한 이유1. 단순 API 호출보다 어려웠던 취소 상태 흐름외부 제휴 API를 연동할 때 처음에는 요청을 보내고 응답을 저장하면 끝날 것처럼 보인다. 하지만 주문취소나 클레임 취소처럼 상태가 계속 바뀌는 업무는 단순한 API 호출만으로 안정적으로 처리하기 어렵다.외부 제휴사에서는 취소 요청이 들어왔지만 내부 주문 연동은 아직 실패 상태일 수 있고, 이미 처리된 클레임이 다시 수집될 수도 있다. 반대로 외부 API 전송은 성공했지만 내부 후처리나 이력 저장이 실패하는 경우도 생길 수 있다.그래서 취소 연동에서는 “요청이 들어왔다”보다 “지금 이 건을 처리해도 되는 상태인가”를 먼저 확인하는 과정이 중요했다.2. 처리 직전 상태를 다시 확인해야 하는 이유배치가 클레.. 더보기
프롬프트 엔지니어링이란? 1. 프롬프트 엔지니어링이 뭐냐?LLM은 똑똑하지만 의도를 추론하는 대신, 지시를 해석한다.그래서 결과의 질은 모델보다 프롬프트의 설계력이 좌우한다.Prompt Engineering =LLM이 원하는 사고 경로를 타도록 입력을 설계하는 기술즉:질문을 잘하는 게 아니라사고 구조를 디자인하는 것2. LLM은 어떻게 생각하냐?LLM의 본질:다음에 올 단어를 확률적으로 예측“이게 정답인지”가 아니라“이 문맥에서 자연스러운 흐름인지”를 계산그래서 이런 특징이 있다:특성의미지시 형태에 민감질문 구조가 바뀌면 답도 바뀜맥락 의존앞 내용이 사고 프레임을 결정모호성 증폭애매하면 애매하게 답함명확성 증폭구체적이면 천재처럼 답함LLM은 똑똑한 게 아니라**사고 구조를 “따라하는 기계”**다.3. 프롬프트 엔지니어링의 핵심 .. 더보기
유지보수 쉽고, 확장 잘되고, 배포가 자유로운 웹 서비스를 만드는 12가지 원칙 The Twelve-Factor App https://12factor.net The Twelve-Factor AppBackground The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku pla12factor.net소개 현대에는 소프트웨어가 일반적으로 서비스로 제공됩니다. 이를 웹 앱 또는 서비스형 소프트웨어라고 합니다. 12단계 앱은 다음과 같은 서비스형 소프트웨어 앱.. 더보기
파이어베이스, 원링크 전환으로 인한 원클릭 수정 function getAppMarket () => {....다양한 인코딩 거치기return `https://~~.onelink.me/9n9r?` + `af_dp=${af_dp}&af_force_deeplink=true&` + `deep_link_value=${deep_link_value}&` + `af_ios_url=${af_ios_url}&af_android_url=${af_android_url}&` + `af_web_dp=${af_web_dp}&is_retargeting=true`; } $("#goAppDown").on('click', function(){ location.href= getAppMarket(location.hre.. 더보기
데이터를 기준으로 DOM을 제어해보았다. 내가 만든 구조의 의도혜택 노출 여부를 DOM이 아니라 데이터로 결정한다.데이터 갱신은 오직 한 곳에서만 한다.(데이터의 진입점을 단일화 — React의 “상태 관리 컴포넌트”처럼 동작)전역 상태(benefitList)를 모든 화면 컴포넌트가 구독하는 구조.렌더링 주기가 거의 없기 때문에, 동적 프레임워크 도입보다 효율적.즉, 정적이지만 상태 일관성이 필요한 페이지에 맞춤형으로 설계한 코드야.// main.jsvar benefitList = {};... if (Array.isArray(discountList) && discountList.length > 0) { // 청구할인율과 전시혜택 신용카드의 할인율은 같아야 함. const isCreditCard = (order) =>.. 더보기
jQuery 환경에서도 React스러운 상태관리를 해보기 기획-개발-운영의 모든 사이클을 다 거쳤던 지난 프로젝트와 달리 이번 프로젝트는 이미 상용 배포된 프로젝트를 운영하며 추가 개발을 진행이 목적이었던 터라, 기존 소스에대한 이해와 적응이 가장 중요했다. 하지만? 처음 프로젝트 투입 시 제일 중요한 건 역시 세팅.(인텔리제이 쓰는 사람이 나밖에 없었다. 받은 것도 sts에 맞춰진 세팅 문서였다. 나중엔 내가 모든 팀원들에게 인텔리제이, VSCode에서 서버 띄우고 소스 파악하는 방법이나 라이브러리, 린트등 설정 퀵문서를 생성해서 배포 했다. 일개 사원이지만 그래도 그렇게 하니 효율이 많이 늘었다! 기존 sts, 이클립스 쓰던 팀장님 과장님께 종종 깃 히스토리를 내가 대신 확인해드리기도 했었다. git 라이브러리가 sts, 이클립스엔 없으니까. 그리고 확실히.. 더보기
이슈에대한 정리 방법(옵시디언, 노트패드) 이슈가 발생할 때 정리 해서 나중에 회의 때나 검수 받을 때 항상 더블체크를 쉽게 하는 게 나만의 습관이다.노트패드에 입력할 때도 많지만 보통은 옵시디언을 사용하는 편.노트패드는 편하고 빠르지만 옵시디언만큼의 기록에대한 것보단 코드 사용성에 초점을 두고 있어 사용 방향에 차이를 두고 있다.보통 로그나 당일 이슈건에대해선 노트패드를 쓰지만정리할 여유가 있을 땐 옵시디언에 차곡차곡 저장해놓는 편이다. 더보기