필터 0
선택된 필터 없음
올리브영
데브옵스

에러로그 하나에 깨던 새벽에서 벗어나기까지 — 상품 모니터링 진화기

상품 모니터링 체계를 Slack 알림 중심에서 DLQ 재처리, Workflow 자동 분석, 정합성 자동화로 진화시켰습니다. 사람이 개입할 일을 줄이고 장애 판단과 대응 속도를 높인 사례를 공유했습니다.

#Datadog#DLQ
141005분
AWS
AI

Amazon Bedrock AgentCore로 구축하는 AgentOps (2): 관측성, 평가, 그리고 AgentOps 라이프사이클

Amazon Bedrock AgentCore로 에이전트 운영의 관측성, 평가, 최적화를 하나의 AgentOps 사이클로 정리했습니다. 트레이스와 메트릭, 로그를 바탕으로 품질과 안전성을 지속 개선하는 흐름을 설명했습니다.

#Amazon Bedrock#AgentOps
4005분
AWS
AI

Amazon Bedrock AgentCore로 구축하는 AgentOps (1): 파운데이션과 게이트웨이

에이전틱 AI를 프로덕션에 올리기 위한 AgentOps와 파운데이션, 게이트웨이 패턴을 소개했습니다. Amazon Bedrock AgentCore로 모델, 도구, 에이전트 접근을 통합하는 방법을 설명했습니다.

#AWS#LLM
5005분
데보션
AI

말하지 않고 만들었다 — AX를 코드로 구현한 6개월의 기록

6개월간 AX를 실제 시스템과 코드로 구현하며 얻은 경험을 정리했습니다. 모델 교체, 검수 분리, 데이터 정제, 승인 레일 등 운영 교훈을 공유했습니다.

#LLM#DB
23205분
네이버 D2
AI

AI 에이전트 회사 차리기: 설립부터 어디서든 동기화까지

AI 에이전트로 가상의 회사를 구성하고 어디서든 같은 목표로 일하게 만드는 NaverMadCat 사례를 소개했습니다. 플랫폼 구조, 자동화, 동기화, 운영 방식과 실전 시나리오를 함께 다뤘습니다.

#LLM#Claude
19005분
밸런스히어로
AI

어피닛, 모든 직원을 AI 빌더로 변화시키는 방법

직원들이 AI 도구로 직접 문제를 해결하는 빌더 문화와 해커톤 사례를 소개했습니다. 현업 지식과 기술 협업으로 실제 운영 병목을 해결하는 방향을 강조했습니다.

#자동화#LLM
18005분
밸런스히어로
AI

어피닛, 포용금융 현장 대토론회에서 인도 사례를 발표했습니다

어피닛이 포용금융 현장 대토론회에서 인도의 금융포용 사례를 공유했습니다. 대안 데이터와 AI 신용평가, 제도적 지원의 필요성을 함께 제시했습니다.

#신용평가#핀테크
6005분
교보DTS
데브옵스

SSL/TLS 인증서 유효기간 단축, 우리의 대응 전략

SSL/TLS 인증서 유효기간이 계속 단축되는 흐름과 그에 따른 운영 리스크를 정리했습니다. 자동화와 모니터링을 중심으로 한 대응 전략도 함께 제시했습니다.

#SSL/TLS#cloud
13005분
교보DTS
AI

시그니처를 넘어 행위 기반으로: 지능형 변형 공격을 막는 다층 보안 아키텍처

생성형 AI 기반 변형 공격이 기존 시그니처 방어를 빠르게 우회하는 한계를 짚었습니다. 정상 행위를 학습하는 이상 탐지와 WAF의 다층 방어 체계가 대안으로 제시되었습니다.

#LLM#WAF
8005분
넥스트리
프론트엔드

React Query 캐시 전략에 대한 고찰

React Query의 staleTime, gcTime, 키 팩토리, 무효화 전략을 중심으로 캐시 운영법을 정리했습니다. 전역 기본값과 직접 갱신을 통해 불필요한 재요청과 화면 깜빡임을 줄이는 방법을 제안했습니다.

#React#cache
29005분
넥스트리
프론트엔드

Keycloakify의 page_hint 상태 관리 개선

Keycloakify의 라운드트립 구조 때문에 `page_hint`를 단순히 React 상태처럼 다루면 새로고침 시 화면이 바뀌는 문제가 있었습니다. 마운트 시 무조건 삭제하던 로직을 진입 흐름에 맞게 조정해 직원 계정 최초 설정 화면을 유지했습니다.

#Keycloak#React
11005분
SSG.COM
백엔드

이상적인 구조가 빠른 성능은 아닙니다

기획전 API의 중복 조회와 중첩 저장 구조를 분리해 성능을 개선한 사례를 다뤘습니다. 다만 구조 분리만으로는 충분하지 않아 실제 조회 패턴과 운영 부하까지 함께 고려해야 했습니다.

#MongoDB#성능
17005분