언제 쓰나
스택 트레이스는 길고 진짜 원인 줄은 한두 개일 때, 또는 새벽에 알림을 받고 어디부터 봐야 할지 판단이 서지 않을 때 씁니다. 가설을 나열만 하는 게 아니라 "무엇부터 확인하면 가설이 가장 빨리 갈라지는지" 순서를 받기 때문에, 헤매는 시간이 줄어듭니다.
사용법
{environment}에 실행 환경을 적습니다. (예:Node.js 20 / Docker / AWS ECS,Spring Boot 3 / RDS MySQL){log}에 로그를 붙여 넣습니다. 에러 발생 직전 20~30줄까지 함께 넣어야 맥락이 잡힙니다.- 출력의 4단계 확인 순서를 위에서부터 실행하고, 결과를 다시 붙여 넣으면서 대화를 이어가면 범위가 좁혀집니다.
사용 예시
입력
실행 환경: Node.js 20 / Docker / AWS ECS, DB는 RDS PostgreSQL
로그:
2026-08-02T03:14:07Z INFO request GET /api/orders
2026-08-02T03:14:37Z ERROR TimeoutError: Connection terminated due to connection timeout
at Client._connectionCallback (/app/node_modules/pg/lib/client.js:132:24)
2026-08-02T03:14:37Z ERROR pool has 10/10 connections in use
출력 (요약)
요약: 주문 조회 요청이 DB 커넥션을 얻지 못하고 30초 뒤 타임아웃했습니다. 풀이 정원(10)까지 찬 상태입니다.
가설 1 (가능성 높음) — 커넥션 누수
근거: 풀 10/10 포화 + 타임아웃이 연결 획득 단계에서 발생
동반 증상: 시간이 갈수록 실패율 증가, 재배포 직후 정상화
가설 2 — 느린 쿼리가 커넥션을 오래 점유 (추정)
가설 3 — RDS 측 max_connections 도달 또는 페일오버
확인 순서
1. pg_stat_activity 에서 idle in transaction 세션 수 확인 — 가설 1과 2를 즉시 구분
2. RDS 콘솔의 DatabaseConnections / 이벤트 로그 확인 — 가설 3 배제
3. 최근 배포 diff 에서 client.release() 누락 경로 확인
임시 조치: 해당 태스크 재시작으로 풀 초기화
근본 조치: finally 블록에서 release 보장, 풀 획득 타임아웃을 30초에서 5초로 축소
팁
- 같은 에러가 반복된다면 "이 로그 3건의 공통점과 차이점만"이라고 요청해 패턴을 먼저 잡으세요.
- 민감정보(토큰, 개인정보, 내부 도메인)는 붙여 넣기 전에 가려야 합니다.
{log}안의 값은 그대로 모델에 전달됩니다. - 원인이 좁혀졌으면 그대로 코드 리뷰 프롬프트로 넘겨 해당 함수의 수정안을 받으면 이어서 처리됩니다.