【장애 조사】 AI에게 로그를 무작정 넘기는 것보다, 사람이 5분간 분해한 후 전달하는 것이 더 빨랐다

일부러 사내 검증 환경에서 장애가 발생하도록 시켰습니다.

로그에는 다음과 같이 기록되어 있습니다.

HikariPool-1 - Connection is not available,
request timed out after 30000ms.

자, 어떻게 조사할까요?

• 경험 있는 엔지니어가 평소처럼 조사한다
• 일단 AI에게 로그 전체를 넘긴다
• AI로 가설을 세운 후, 사람이 조사한다
• 사람이 상황을 정리한 후, AI를 사용한다

결국 어떤 방식이 가장 빠르게 '진짜 원인'에 도달할 수 있을까요?

이번에는 같은 장애를 사용하여 진행 방식을 바꾸고, 원인 특정까지의 프로세스를 비교해 보았습니다.

먼저 결과를 말씀드리자면,

가장 빨랐던 것은 '사람이 먼저 분해 → AI에게 생각하게 함 → 사람이 검증한다'였습니다.

AI에게 전부 맡기는 것도 아니고,
사람 혼자 노력하는 것도 아니었습니다.

핵심은 어디를 AI에게 전달하느냐였습니다.

검증용으로 Web API를 통해 다음 장애를 재현했습니다.

환경은 다음과 같습니다.

Java 21
Spring Boot 3.x
MySQL 8
...

주문 검색 API가 있습니다.

GET /api/orders/search

평소에는 정상 작동하지만, 데이터 건수가 어느 정도 많아지면 응답이 급격히 나빠집니다. 최종적으로는 500 에러가 발생합니다.

로그를 보면,

HikariPool-1 - Connection is not available,
request timed out after 30000ms.

게다가,

SQLTransientConnectionException

CPU 사용률은 그리 높지 않습니다. 메모리에도 여유가 있습니다.

그런데 DB 연결만 고갈됩니다.

이 로그만 보면, 처음에 의심하게 되는 것은 이것입니다.

maximumPoolSize가 작나?

혹은,

DB가 느리나?

또는,

커넥션 누수(Connection Leak)?

어느 것이든 그럴싸해 보입니다.

그리고 여기가 이번 장애 조사에서 흥미로웠던 부분입니다.

에러 메시지가 가리키는 곳과, 장애를 일으킨 원인이 달랐습니다.

문제가 되었던 코드를 상당히 단순화하면 이런 상태였습니다.

List<Order> orders = orderRepository.search(condition);
for (Order order : orders) {
List<OrderDetail> details = 
...

검색 결과가 10건이라면 큰 문제가 아닙니다.

하지만 1,000건이 반환되면,

주문 검색 1회
명세 검색 1,000회
----------------
...

SQL이 발행됩니다. 이른바 N+1 문제입니다.

접근이 중첩되면서 대량의 SQL이 발행되고, DB 연결이 오랫동안 점유됩니다. 그 결과,

HikariPool-1 - Connection is not available

이 발생하고 있었습니다.

즉,

표면적인 증상
↓
DB 커넥션 부족
...

이번에 비교한 것은 다음 4가지 패턴입니다.

먼저 평소처럼 조사합니다. 로그를 봅니다.

Connection is not available

DB 상황을 봅니다. 커넥션 수를 봅니다. 슬로우 쿼리를 봅니다. 재현시킵니다. 접근 로그를 봅니다. 직전 변경 사항을 봅니다. SQL 로그를 출력합니다.

여기까지 조사했을 때 의아한 점이 있었습니다.

비슷한 SELECT가 대량으로 나오고 있다

코드를 봅니다.

for (Order order : orders) {
orderDetailRepository.findByOrderId(order.getId());
}

발견했습니다. N+1이었습니다.

원인 특정: 약 42분

확실하기는 합니다. 다만, 후보를 하나씩 제거했기 때문에 꽤 시간이 걸렸습니다.

다음은 AI입니다. 처음에는 일부러 정보를 많이 정리하지 않고 넘겼습니다.

Spring Boot 시스템에서 다음과 같은 오류가 발생했습니다.
HikariPool-1 - Connection is not available,
request timed out after 30000ms.
...

AI로부터는 상당히 많은 후보들이 돌아왔습니다.

예를 들어,

・maximumPoolSize 부족
・DB 처리 시간 장기화
・커넥션 누수(Connection Leak)
...

어느 것도 틀린 것은 아닙니다.

하지만 곤란합니다.

후보가 너무 많습니다.

그리고 초반에,

maximumPoolSize를 늘려서 확인해 보세요

라는 방향도 나왔습니다.

여기서 설정값을 변경하면 일시적으로 증상이 개선될 가능성이 있습니다.

하지만 N+1은 그대로 남아있습니다.

오히려 위험합니다.

이것은 굉장히 빠릅니다.

몇 초 만에요.

다만,

그것이 이번 장애의 원인인지
는 별개의 문제였습니다.

결국,

어떤 조건에서 발생하는가?
언제부터?
무엇이 바뀌었는가?
...

를 사람이 조사해야 합니다.

유력 후보 제시: 수십 초
근본 원인 특정: 약 31분

AI의 답변은 빠릅니다.

하지만, 장애 조사가 끝나는 것은 아닙니다.

다음으로는 처음부터 AI에게 조사 방침까지 생각하게 합니다.

다음 장애에 대해,
가능성이 높은 순서대로 원인 가설을 정리해 주세요.
또한, 각각을 가장 짧은 시간 안에 구분하기 위한
...

이렇게 정보를 늘리자 답변이 상당히 좋아졌습니다.

AI로부터,

1. 쿼리 실행 시간 증가
2. N+1 등으로 인한 SQL 발행 수 증가
3. 장기 트랜잭션
...

형태로 정리되었습니다.

오.

N+1이 상당히 위에 나왔습니다.

그래서 SQL 로그를 확인했습니다.

대량의 SELECT 문을 발견했습니다.

코드를 확인했습니다.

원인 특정.

원인 특정: 약 23분

상당히 빨라졌습니다.

마지막 방법입니다.

갑자기 AI에게 묻지 않습니다.
먼저 사람이,

'사실'만을 모읍니다.

이번에 정리한 것은 이것뿐이었습니다.

【현상】
주문 검색 API가 타임아웃한다
【발생 조건】
...

여기까지 정리해서 AI에게 전달합니다.

Spring Boot + MySQL의 장애 조사입니다.
다음은 확인된 사실입니다.
・주문 검색 API에서 발생
...

그러자 상당히 직설적으로,

첫 번째 후보:
주문 목록을 가져온 후, 주문 단위로 상세 SQL을 실행하고 있다.
N+1 쿼리 가능성

이 나왔습니다.

게다가,

・1 리퀘스트당 SQL 발행 수
・검색 결과 건수와 SQL 발행 수의 관계
・최근 추가된 상세 조회 처리

를 확인하라고 제안했습니다.

코드를 봅니다.

for (Order order : orders) {
orderDetailRepository.findByOrderId(order.getId());
}

거의 한 방이었습니다.

원인 특정: 약 16분

이번에 가장 빠른 결과가 나왔습니다.

요약하자면 다음과 같습니다.

물론 장애 내용이나 엔지니어의 경험치에 따라 결과는 달라집니다.

다만, 이번에 상당히 명확해진 것이 있습니다.
AI를 사용할 때 자꾸 저지르는 실수가 이것입니다.

이 에러의 원인을 알려주세요.

하지만 AI 입장에서는 정보가 부족합니다.
당연히 답변은 이렇게 나옵니다.

가능성 ①
가능성 ②
가능성 ③
...

맞습니다.

하지만,

장애 조사에서 '올바른 후보를 많이 제시하는 것'이 목적은 아닙니다.

필요한 것은,
이번 원인을 가장 짧은 시간 안에 하나로 좁히는 것입니다.

이번에 가장 효과적이었던 것은 전문 지식을 사용한 어려운 분석이 아니었습니다.
다음 정보를 정리한 것이었습니다.

언제 발생하는가?
무엇을 할 때 발생하는가?
어디까지는 정상인가?
...

장애 조사의 기본 그 자체입니다.
예를 들어,

Connection Timeout이 발생하고 있습니다

만으로는 정보량이 적습니다.
하지만,

100건에서는 발생하지 않는다.
500건부터 느려진다.
1000건에서는 거의 발생한다.
...

라고 한다면, 한 번에 원인에 가까워집니다.
AI를 사용하고 있으면,

로그를 전부 붙여넣기
↓
원인을 묻기

이런 식을 하고 싶어집니다.

하지만 실제 장애 조사에서는 그보다도,

사람
↓
사실을 정리하기
...

쪽이 더 강력합니다.

특히 중요한 것이 마지막 부분입니다.

예를 들어 이번에,

AI가 이렇게 답변했다고 가정해 봅시다.

N+1 문제일 가능성이 높습니다.

그때,

아, N+1인가.

여기서 끝내면 장애 조사가 아닙니다. 확인해야 합니다.

예를 들어 SQL 발행 횟수 같은 것을요.

검색 결과 10건
→ SQL 11회
검색 결과 100건
...

이것만으로도 상당히 강력한 증거가 됩니다. 게다가 코드를 살펴봅니다.

for (Order order : orders) {
repository.findByOrderId(order.getId());
}

그리고 수정합니다. 예를 들어 JOIN이나 일괄 조회로 변경합니다.

List<Long> orderIds =
orders.stream()
.map(Order::getId)
...

다시 측정해 봅니다.

SQL 1001회
↓
SQL 2회

부하 테스트를 합니다.

재현되지 않습니다.

여기까지 진행하고 나서,

'원인이었다'라고 말할 수 있습니다.

AI가 원인을 결정하는 것이 아닙니다. 사실이 원인을 결정합니다.

개인적으로 가장 중요하다고 느낀 부분은 여기입니다.

AI 활용이라고 하면, 프롬프트를 잘 작성하는 것에 주목하기 쉽습니다. 물론 중요합니다.

하지만 장애 조사에서는 그 이전에,
무엇을 알고 있고 무엇을 모르는지를 구분할 수 있는 것이 압도적으로 중요합니다.

AI는 이 차이를 저절로 메워주지 않습니다.

이번 방식을 실무에 적용하면 상당히 간단해집니다. 장애가 발생하면 바로 AI에게 던지지 말고, 먼저 이 7가지를 채웁니다.

■ 1. 무엇이 일어나고 있는가?
500 에러, 지연, 데이터 불일치 등
■ 2. 언제부터?
...

이것을 AI에게 전달합니다. 실제로는 다음 템플릿만으로도 상당히 사용할 수 있습니다.

시스템 장애를 조사하고 있습니다.
아래는 확인된 '사실'입니다.
【현상】
...

포인트는,

원인을 알려줘

가 아니라,

어떻게 하면 그 가설을 부정하거나 확정할 수 있을까?

까지 묻는 것입니다. 이것만으로도 AI가 상당히 '조사관'에 가까워집니다.

이번에 시도해 보고 느낀 것은, AI가 들어와도 장애 조사의 기본은 변하지 않는다는 점입니다. 오히려 중요성이 커지는 것 같습니다.

사실을 본다
↓
분리한다
...

이 중간에 AI가 들어간 것뿐입니다. AI는,

가설을 대량으로 도출하기
놓친 부분을 지적하기
코드를 읽기
...

하는 것이 매우 뛰어납니다.

반면, 인간에게는,

어떤 사실이 중요한지 판단하기
운영 환경의 상황을 이해하기
정보의 정확성을 판단하기
...

와 같은 업무가 남아 있습니다.

이번 결과를 한마디로 요약하자면, AI가 장애를 조사하는 것이 아니라, 사람이 AI를 사용해 조사 범위를 빠르게 좁히는 것이었습니다. AI 단독이 최고였던 것도 아니고, 인간만으로도 최고가 아니었습니다.

사람이 관찰하기
↓
AI에게 생각하게 하기
...

이 왕복 과정이 가장 빨랐습니다. 개인적으로는, AI 시대의 엔지니어링에서 중요한 것은 '스스로 모든 답을 낼 수 있는 것'에서 '가장 짧은 경로로 올바른 답에 도달하는 것'으로 변화하고 있다고 생각합니다.

장애 조사는 그 변화가 매우 명확하게 드러나는 업무 중 하나일지도 모릅니다. 에스프리포트는 AI를 사용해서 끝내는 것이 아니라, AI를 어떻게 실무의 성과로 연결할지를 고민하고 있습니다. 기술 자체뿐만 아니라, AI와 인간 각각의 강점을 결합하여 고객 가치에 연결하는 엔지니어링을 앞으로도 찾아가겠습니다.