OK캐쉬백 복지 포인트 서비스 개발기: 보안, 대용량 처리, 그리고 현실적인 선택들
OK캐쉬백 복지 포인트 서비스는 3개월 안에 연내 오픈해야 하는 일정에 보안·대용량 처리 요구가 함께 걸려 있었다.
OK캐쉬백 복지 포인트 서비스는 3개월 안에 연내 오픈해야 하는 일정에 보안·대용량 처리 요구가 함께 걸려 있었다.
SK플래닛이 11번가 자회사 편입 후 OpenAI 기반 AI 기술과 에이전틱 커머스 적용 흐름을 조직 전반에 공유할 자리가 필요했다.
SQL을 모르는 현업 담당자가 데이터를 요청하면 분석팀과 며칠씩 요구사항을 조율해야 했고, 반복 커뮤니케이션 비용이 컸다.
SK플래닛 Tech Topic 블로그는 운영 초기 월 0.5~1개 기고, 1~2천 조회수에 머물러 개인 회고 수준에서 조직 채널로 자라기 어려웠다.
소스 화자의 음성을 타깃 화자의 목소리로 변환하면서 음색(timbre), 피치(F₀), 음악적 리듬을 동시에 보존하기 어렵다.
수십 개 광고 네트워크·수백 개 배치-네트워크 조합의 최저가(Min Price)를 마케터가 수동 조정하는 것이 불가능한 규모로 성장했다.
블랙아이스는 육안 식별이 불가능해 운전자가 위험을 인지하기 전에 사고가 발생한다.
기존 Native AR은 SDK 통합 복잡성과 앱 설치 진입장벽으로 사용자 도달율이 낮았다.
대화형 LLM 서비스에서 비활성 탭 전환 시 브라우저 Throttling으로 스트리밍 렌더링이 지연되고, 대화가 누적될수록 DOM 노드 증가로 성능이 저하됐다.
기존 DMP에서 마케터가 57,829개 트레잇 카테고리 중 필요한 세그먼트를 수동으로 찾는 데 2~3시간이 소요됐다.
LLM 기반 Text-to-SQL 서비스에서 반복 호출 시 지연 시간과 토큰 비용이 과도했다. Lambda 기반 설계는 SSE 미지원과 타임아웃 제한 문제도 있었다.
라이브커머스 성장에 따라 AWS ELB + ECS 컴퓨팅 비용이 급증했다. 프론트엔드 서버 트래픽이 다른 API 서버보다 월등히 높아 고정 비용 부담이 컸다.
Figma 시안에서 React/Vue 컴포넌트를 수동으로 구현하면 반복 작업이 많고 설계-코드 간 간극이 발생함.
B2B 영상 생성 서비스에서 LLM 응답의 비결정성, TTS 호출 실패 시 예외 처리, 높은 응답 지연이 운영 문제로 대두됨.
UX와 FE 간 핸드오프에서 디자인 의도가 코드로 정확히 반영되지 않아 QA 이슈의 45.59%가 디자인 시스템으로 예방 가능했음.
여러 서버에 걸친 배포를 수동으로 처리하면서 일관성 부재와 서비스 중단이 반복되고, L4 out/in 타이밍을 수동으로 조율하는 비용이 높음.
OK캐쉬백 커뮤니티 오글오글에서 무플이 많아 첫 글 작성 사용자의 참여가 저조했다.
로딩 스피너로 인해 사용자가 다음 화면을 예측할 수 없어 탐색 경험이 저해됐다.
QA 업무의 요구사항 분석과 테스트 케이스 작성에 많은 시간이 소요됐다.
기존 배치 기반 처리는 파생 데이터 생성이 1일 이상 지연되어 실시간 인사이트를 제공할 수 없었다.