GitHub: https://github.com/jaemyeong-hwnag/observe-fix개발팀이 처리하는 작업은 성격이 다르다.신규 기능 구현이나 비즈니스 로직 변경은 판단이 필요하다. 왜 이 방향으로 만드는지, 어떤 트레이드오프가 있는지, 기획자와

Claude Code를 쓰기 시작하면서 자동화 못하나 고민을 했다.그 답을 찾기 위해 두 가지 방식을 직접 만들어서 써봤다. 실제 사용하고 ai 한테 물어본 결론은 한쪽은 특정 상황에서만 의미 있었고, 나머지는 팀 단위에서나 진짜 가치가 있었다.질문 내용 워크플로우 개

Aurora MySQL의 binlog를 실시간으로 캡처하여 S3에 구조화된 데이터로 저장하는 서버리스 CDC(Change Data Capture) 파이프라인이 프로젝트는 Aurora MySQL 데이터베이스의 모든 데이터 변경 이벤트(INSERT, UPDATE, DELE

관련 링크: Datadog Summit Seoul 후기(velog)Datadog Learn(무료) 코스에서 SLI를 정의하고 SLO를 설정한 뒤, SLO 위반 시 알림 전파와 담당자 자동 할당까지 구성했다.SLI 정의APM 기반: HTTP 상태코드(2xx/5xx)를 기

AI, Observability 2가지가 제일 큰 주제였다.이중에 AI 관련 내용을 제일 크게 노출했다.요즘 대세인 AI에 맞게 많은 내용중에 AI가 포함되어 있다. 실제 핸즈온에서도 "작은 LLM 애플리케이션 개발부터 관측까지"이 있었는데 가보고 싶었지만 신청할때 인

프로젝트 개요 기존 RDS(MySQL) 환경에서는 여러 테이블의 히스토리성 데이터(감사 이력, 변경 로그 등)를 각각 별도의 테이블에 저장해 관리하고 있었습니다. 감사 로그(히스토리 데이터)는 저장 빈도는 높고, 조회 빈도는 낮아 RDS의 저장/운영 비용과 성능 측면에서 비효율적이었습니다. 데이터 관리 일관성과 운영 효율성을 위해 DynamoDB 기반 이...

Dockerfile에서 apt-get update && apt-get install -y curl 실행 중 아래와 같은 오류가 발생했다:Debian 10 (buster)은 2024년 기준으로 EOL(지원 종료)되어 공식 저장소에서 제거되었기 때문에, apt-get up

최근 코딩테스트를 준비하면서 아래와 같은 문제를 자주 느꼈다:문제를 보고도 접근 방식이 떠오르지 않음AI가 짜준 코드는 동작하지만, 왜 그렇게 구현되는지 모름비슷한 문제를 다시 풀려고 하면 스스로 구현하지 못함기본 개념이 부족하니 디버깅도 어려움이 과정에서 AI 자동완

Kotlin Coroutine 환경에서 대량의 FCM Push 메시지를 처리할 때,많은 예제나 문서에서는 Dispatchers.IO를 사용하는 것을 기본으로 제시합니다. 그러나 실무에서는 다음과 같은 이유로 커스텀 ThreadPoolTaskExecutor를 Corout

도입: 왜 큐를 고려하게 되었는가?메시지 서버를 설계하면서 처음에는 HTTP 기반의 요청 처리를 고려했습니다. 하지만 HTTP는 클라이언트의 요청 수에 따라 서버가 직접 응답해야 하므로, 서버의 처리 능력과 상관없이 부하가 한순간에 몰릴 수 있는 위험이 있습니다.

이슈 위에 이미지는 앱 푸쉬 발송 워터플이다. 원인 스펙 vCPU: 1 Memory: 2G 원인 firebase-admin-java를 9.2.0 이후 버전 부터 이슈 발생 기존 버전의 경우 sendAll 메서드를 사용할댸 SDK 자체에서 http 요청을 batch

기존 PHP 레거시 코드를 kotlin으로 변환

테스트하는 모듈에 @SpringBootApplication 이 없어서 발생테스트 패키지에 아래 추가

핫픽스 건으로 배포할때 실제 개발 수정시간은 1분이더라도 배포하는데 5분이 걸리면 실제 운영까지 적용되는 시간은 최소 6분이다.크리티컬 이슈의 경우 무엇보다 속도가 중요한데 이럴때 배포 버튼만 누르고 기다리면 답답했던 경우가 있었다해결 방법은 배포 플로우중에 테스트 부

정기 배포시 유용한 전략참조https://techblog.woowahan.com/2553/

말 그대로 베이스를 재배치 브랜치의 시작점을 재설정branch의 변경사항을 최신 상태로 유지가 가능커밋 라인을 정리하여 히스토리를 깔끔하게 유지리베이스 사용법최근 3개의 커밋을 interactive rebase 한다wq 로 저장 종료현재 “0번 feature - 커밋

비동기가 왜 필요한가?2개의 쿼리 조회시 속도가 너무 느려 사용 최대 로컬에서 500ms 발생적용해도 문제 없나?쿼리 자체가 개별적으로 동작하는 쿼리라 이슈 없음왜 느린가?외부 서비스에 요청해서 결과값을 가져오는데 이때 속도가 이슈결과운영에서 평균 80ms참고 : ht

jpa 에서 쿼리 작성 후 해당 쿼리의 count 를 가져올때 동일한 조건을 또 써야되서 불편해서 추가한 확장 함수

가능하면 사용안하는게 좋은것 같다.1\. 명시적이지 않다. 필수 값인지 그냥 사용해도 되는지2\. 휴먼 에러 만약 실수로라도 값을 입력하지 안은경우 오류 발생 가능아래는 배포후 다른 작업의 오류를 같이 찾으면서 경험 했던 내용이다.상품 정보가 정상적으로 나오지 않았던

Open Session In View 개인적인 생각을 먼저 말하면false 로 사용하는게 좋을것 같다. false -> true 변경은 크게 이슈가 없지만, true -> false 변경시 프로젝트에서 어떤 사이드 이펙트가 발생할지 모른다.이전에 프로젝트를 진행했을때