개발로 자기계발

kubectl 타임아웃이 프로세스를 종료시키던 버그, 예외 처리로 바로잡기

한눈에 보기subprocess.run(timeout=8)은 제한 시간을 넘기면 TimeoutExpired를 발생시킨다.파드 신원 검증 타임아웃은 요청 거부로 처리하되, executor 프로세스는 종료되지 않아야 한다.예외를 ValueError로 변환하면 검증은 fail-closed로 유지하면서 실행 프로세스를 살릴 수 있다.문제 상황호스트 전용 작업을 실행하기 전에 파드 신원을 확인하는 로직이 있었다. 이 함수는 내부적으로 kubectl get pods를 호출해 대상 파드 정보를 조회한다. 호출에는 Kubernetes 요청 제한 시간과 subprocess 제한 시간이 함께 설정돼 있었다.기존 코드에서는 subprocess.run() 호출 중 발생하는 subprocess.TimeoutExpired를 처리하..

RDS vs Aurora PostgreSQL 비교 실험 (1)

왜 이걸 하게 됐나DBA로 일하다 보면 "RDS랑 Aurora 중에 뭐가 더 나아요?"라는 질문을 자주 받습니다. 그런데 고객사 운영 환경을 직접 부하 테스트할 수는 없습니다. 그래서 테스트 계정에 RDS PostgreSQL과 Aurora PostgreSQL을 똑같은 스펙으로 띄우고, 동일한 데이터를 넣어 직접 비교해보기로 했습니다.이번 1편은 그 첫 단계 대용량 데이터를 적재하면서 두 엔진의 차이가 어디서 나타나는지를 CloudWatch 지표로 관찰한 기록입니다.실험 환경공정한 비교를 위해 두 엔진을 완전히 동일한 조건으로 맞췄습니다.항목값엔진PostgreSQL 16.14인스턴스db.r6g.large (2 vCPU / 16GB)리전서울 (ap-northeast-2)적재 도구pgbench 17.10데이터..

만든 이유프로젝트마다 아키텍처 다이어그램을 그리는 건 생각보다 시간을 잡아먹습니다. draw.io 열어서 AWS 아이콘 찾고, 하나씩 배치하고, 선 연결하고, 라벨 달고. 서비스 7 ~ 8개짜리 간단한 구성도에도 20 ~ 30분은 금방 갑니다.AI 코딩 도구를 쓰면서 "아키텍처도 말로 설명하면 간단한 초안이라도 그려주면 좋겠다"는 생각이 들었습니다. 그래서 어떤 LLM이든(Kiro, Claude Code, Codex, Grok) 동일하게 동작하는 전역 스킬을 만들었습니다."API Gateway → Lambda → DynamoDB 구조 그려줘" 한마디면 draw.io 파일이 생성됩니다.뭘 하는 스킬인가/aws-arch-diagram은 두 가지 방식으로 동작합니다:자연어 입력 — "CloudWatch → S..

왜 만들었나운영 DB에서 슬로우 쿼리가 터지면 DBA가 직접 세션을 열어 확인하고, 실행계획을 뜯어보고, 개발자한테 "여기 인덱스 태워야 합니다" 하고 전달합니다. 이 과정이 건당 짧으면 10분, 길면 30분 넘게 걸립니다. 하루에 여러 건 들어오면 튜닝 분석에만 반나절이 가버리죠.이 시간을 줄여보고 싶었습니다. 알람이 올라오면 세션 스캔부터 실행계획 분석, 튜닝 권고문 작성까지 AI가 대신 해주면 — 제가 검토만 하면 되니까요. Amazon Bedrock의 Claude 모델을 붙여서 이 파이프라인을 자동화했습니다.현재 Oracle, MySQL, PostgreSQL, MSSQL, DocumentDB 5개 엔진에서 돌아가고 있고, 분석 결과는 Google Chat으로 바로 떨어집니다.전체 구조두 개의 La..

한눈에 보기URL 필드가 있어도 private_submitted 상태라면 공개 게시 행으로 처리하지 않습니다.무효 승인 상태는 확정 발행 상태가 아닐 때 집계 대상에서 제외합니다.회귀 테스트는 URL이 있는 비공개·대체 상태 행이 빈 결과로 이어지는지 확인합니다.문제 상황블로그 인게이지먼트 수집 과정에서는 게시물 레코드의 여러 필드에서 URL을 확인합니다. 이때 공개 게시 여부가 확정되지 않은 행에도 URL 필드가 채워질 수 있습니다.예를 들어 publish_status가 private_submitted이고 approval_status가 superseded인 레코드에 publish_url이 함께 들어올 수 있습니다. URL만 확인하면 이 행을 공개 게시물처럼 다룰 가능성이 생깁니다.이번 수정의 범위는 이..

가용성을 모니터링하는 코드가 오히려 특정 장애를 조용히 삼키고 있었다. 네트워크가 끊기거나 HTTP 예외가 발생하면 프로브(probe)가 예외를 잡지 못하고 스택 위로 전파되어, 관측 창(observation window)에 샘플 자체가 기록되지 않았다.한눈에 보기• ConnectionError와 HTTPException이 except 블록 밖으로 빠져나가 샘플이 누락됐다.• 누락된 샘플은 가용률 계산 분모에서 사라져 결과가 낙관적으로 왜곡됐다.• 두 예외를 명시적으로 잡아 "network_error"로 기록하고, missing_samples와 모니터링 커버리지 지표를 추가해 해결했다.결론부터probe() 함수의 except 블록에 ConnectionError와 HTTPException을 추가하고, 관측..

Playwright의 browser.new_context()에 user_agent를 추가하는 변경은 한 줄로 끝나 보인다. 그러나 실제 코드와 테스트 대역의 호출 계약을 함께 맞추지 않으면, 운영 코드는 새 인자를 넘기는데 테스트 스텁은 인자를 받지 못하는 불일치가 생긴다.한눈에 보기• User-Agent는 문자열 상수로 분리해 브라우저 컨텍스트를 만들 때 명시한다.• 테스트용 가짜 브라우저도 키워드 인자를 받을 수 있게 바꾼다.• 이 변경만으로 차단 우회나 인증 성공을 보장한다고 해석하면 안 된다.먼저 결론실제 변경의 핵심은 아래 두 줄이다. 운영 코드에서는 고정 User-Agent를 전달하고, 테스트 대역에서는 사용하지 않는 키워드 인자를 받아 호출 형태를 맞춘다.ADMIN_SMOKE_USER_AGE..

여행 숙소 글을 만들었는데 자꾸 서울 동네 이야기가 섞였습니다. 문장 품질의 문제가 아니라, 다른 콘텐츠용 입력값을 잘못 재사용한 구조 문제였습니다.한눈에 보기• 증상: 전국 숙박 추천글에 목동·상암동 같은 생활권이 반복됐습니다.• 원인: 동네 콘텐츠용 지역 시드를 여행 콘텐츠에도 공통으로 사용했습니다.• 해결: 지역 시드를 제거하고 여행 테마를 별도 입력으로 분리했습니다.먼저 결론재사용 가능한 것은 생성 절차였고, 재사용하면 안 되는 것은 콘텐츠의 맥락이었습니다. 공통 함수라고 해서 모든 채널에 같은 입력값을 넣으면 결과가 안정되는 것은 아닙니다.이번 문제는 글을 더 잘 써 달라는 지시로 해결되지 않았습니다. 여행 글에 맞는 입력 계약을 별도로 만드는 것이 핵심이었습니다.문제 상황기존 파이프라인은 오늘..