AI를 활용한 문제 해결: OpenAI vs DeepSeek
I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the text, I’ll keep the source link at the top and translate the rest into Korean while preserving all formatting, markdown, and technical terms.
AI‑Powered Root‑Cause Analysis
AI는 이제 글쓰기부터 코딩까지 모든 분야에서 필수 도구가 되었습니다. 최신 LLM은 프롬프트만 잘 만들고 약간의 조정만 하면 거의 손쉽게 작업을 수행할 수 있을 정도로 강력합니다.
Coroot(관측성을 단순화하는 오픈소스 프로젝트)에서는 AI(LLM + ML)를 활용해 근본 원인 분석을 자동화했습니다. 정확한 근본 원인을 찾는 일은 가능한 시나리오가 많아 까다롭습니다. 우리 사용자 중 다수는 데이터베이스, 네트워크 성능, 특정 런타임 등에 대한 전문가가 아니기 때문에 명확한 설명과 함께 문제 해결 방법을 제시해야 합니다.
이번 블로그에서는 여러 LLM이 혼돈 실험을 어떻게 진단하는지 테스트해 보기로 했습니다. 진행을 빠르게 하기 위해 텔레메트리 데이터를 프롬프트로 변환하는 대신 스크린샷을 그대로 LLM에 입력했습니다.
그 결과는 충격적이었습니다.
OpenAI GPT‑4o
Prompt (no other context provided):
답변
제공된 PostgreSQL 모니터링 대시보드를 보면 ALTER TABLE 문이 성능 문제를 일으키고 있는 것으로 보이며, 그 결과는 다음과 같습니다.
- 쿼리 지연 증가 – 평균 쿼리 지연 시간이 급등했으며, 특히
pg‑cluster‑2에서 두드러집니다. ALTER TABLE에 의한 I/O 부하 – “ALTER TABLE” 문(alter table articles alter column body set not null)이 상당한 I/O를 소비하고 있습니다(Queries by I/O time 그래프 참고).- 잠긴 연결 및 쿼리
- Postgres connections 그래프에서 잠긴 연결이 급증했습니다.
- Locked queries 그래프는
ALTER TABLE작업 때문에 쿼리가 차단되고 있음을 보여줍니다. - Blocking queries 그래프는
ALTER TABLE쿼리가 락을 잡고 다른 여러 쿼리를 차단하고 있음을 나타냅니다.
- 복제 지연 –
ALTER TABLE작업으로 발생한 쓰기 백로그 때문에 복제 지연이 급증했습니다.
왜 이런 현상이 발생했나요?
ALTER TABLE … SET NOT NULL 은 테이블 전체를 스캔해 새 제약 조건을 위반하는 행이 없는지 확인해야 하는 작업입니다. 이 과정에서 테이블 전체에 락이 걸리며, 작업이 끝날 때까지 읽기·쓰기가 모두 차단됩니다. 특히 읽기·쓰기가 빈번한 고부하 환경에서는 큰 문제가 됩니다.
해결 방법 (즉시 조치)
-- 다운타임을 유발한다면 ALTER TABLE 작업을 중단
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE query LIKE '%ALTER TABLE articles alter column body set not null%';중단 후 남아 있는 락을 확인합니다:
SELECT *
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;장기적인 해결책
ALTER TABLE 작업이 비용이 많이 드는 만큼, 다음과 같은 모범 사례를 고려하세요.
-
온라인 친화적인 방식으로 전환
-- 1️⃣ 검증되지 않은 체크 제약조건을 추가 (비차단) ALTER TABLE articles ADD CONSTRAINT articles_body_not_null CHECK (body IS NOT NULL) NOT VALID; -- 2️⃣ 누락된 값 채우기 (필요한 경우) -- 3️⃣ 제약조건 검증 (여전히 비차단) ALTER TABLE articles VALIDATE CONSTRAINT articles_body_not_null; -- 4️⃣ 위반이 없으면 컬럼을 NOT NULL 로 설정 ALTER TABLE articles ALTER COLUMN body SET NOT NULL; -
pg_repack을 이용한 무중단 마이그레이션pg_repack -t articles --dbname=mydatabase -
트래픽이 적은 시간대에 스키마 변경 수행 – 프로덕션 환경에서는 유지보수 창을 예약하세요.
-
대형 테이블 파티셔닝 – 작업을 작은 파티션 단위로 제한해 영향을 최소화합니다.
Source: …
결론
ALTER TABLE 작업이 articles 테이블을 잠그고 있어, 쿼리 지연과 복제 지연이 크게 발생하고 있습니다. 권장되는 접근 방식은 다음과 같습니다:
- 다운타임을 초래하고 있다면 작업을 취소합니다.
- 온라인‑안전 대안(체크 제약조건 + 검증)을 사용합니다.
- 스키마 변경을 신중히 일정에 잡고, 최소한의 영향을 위해
pg_repack같은 도구를 고려합니다.
DeepSeek‑R1
프롬프트: (동일한 스크린샷)
답변
데이터는 **pg‑cluster‑2**에서 장기 실행 ALTER TABLE 명령이 articles 테이블에 대해 발생한 심각한 성능 문제를 나타냅니다. 이 작업은:
articles테이블에 배타적 잠금을 보유하고 있습니다.- 다른 중요한 쿼리(
SELECT,INSERT)를 차단하고 있습니다. - 높은 쿼리 지연(10‑15 초), 활성/잠긴 연결 급증, 처리량 감소, 그리고 다른 클러스터에서 약간의 복제 지연을 초래하고 있습니다.
즉각적인 해결책
-- ALTER TABLE 쿼리의 PID 찾기
SELECT pid, query
FROM pg_stat_activity
WHERE query ILIKE '%ALTER TABLE articles alter column body set not%';
-- 안전하다면 종료
SELECT pg_terminate_backend(pid);종료 후, 잠금이 해제되었는지 확인합니다:
SELECT *
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;장기적인 권고사항
- GPT‑4o에 대해 설명한 동일한 온라인‑친화적 접근 방식을 따르세요.
pg_repack또는 유사 도구를 사용해 무중단 스키마 변경을 수행하세요.- 무거운 DDL 작업은 유지보수 창에 맞춰 일정에 잡으세요.
- 매우 크고 자주 변경되는 테이블에 대해서는 파티셔닝을 고려하세요.
최종 생각
두 모델 모두 단일 스크린샷만으로 인상적인 정확도의 분석을 제공했습니다. LLM이 우리 도메인을 “이해”하고 깊이 있는 실행 가능한 요약을 생성할 수 있다는 점은 매우 흥미롭습니다. 그러나 단일 공급업체에만 의존하는 것은 견고한 솔루션이 아닙니다.
DeepSeek의 R1 모델은 OpenAI 제품에 대한 강력한 대안임을 입증했으며, 다중 공급업체 전략이 신뢰할 수 있는 벤더‑중립 AI‑구동 관찰성을 제공할 수 있다는 확신을 주었습니다.
DeepSeek‑R1은 OpenAI와 상당히 유사한 답변을 제공합니다. 저는 이것이 OpenAI 모델에 대한 실용적인 대안이라고 말할 수 있을 정도로 정확하다고 생각합니다.
추가로, 제 실험실에서 다른 오픈‑소스 모델들을 테스트했지만, 최대 70 억 파라미터 모델만 실행할 수 있었습니다. 이 범위에서는 우리 요구에 맞는 OpenAI 혹은 더 큰 DeepSeek 모델에 근접한 것을 찾지 못했습니다.
ALTER TABLE 차단 문제
-- 차단 중인 쿼리 찾기
SELECT pid, query
FROM pg_stat_activity
WHERE query LIKE '%alter column body%';
-- 종료
SELECT pg_terminate_backend(pid);주의: 이 작업이 데이터 손상을 일으키지 않는지 확인하세요(예: ALTER가 마이그레이션의 일부인 경우).
DDL 작업 재스케줄링
트래픽이 적은 시간에 스키마 변경을 수행하거나 온라인 DDL 도구를 사용하세요:
pg_repack– 배타적 잠금 없이 테이블을 재구성합니다.CREATE INDEX CONCURRENTLY– 인덱스 관련 변경을 쓰기를 차단하지 않고 수행합니다.
ALTER TABLE 최적화
컬럼을 NOT NULL 로 설정하려면 이미 NULL 값이 없음을 확인해야 합니다. 사전 정리 예시:
UPDATE articles
SET body = ''
WHERE body IS NULL; -- 예시 정리장기적인 개선 방안
잠금 타임아웃 사용
SET LOCAL lock_timeout = '5s';
ALTER TABLE ...;쿼리 모니터링 및 튜닝
SELECT id FROM articles WHERE created ...쿼리를 최적화합니다.
AIOps가 드디어 도착했나요?
예, 시스템 동작을 설명하는 충분한 데이터가 있을 때만 가능합니다.
CPU, 메모리, 디스크 사용량만으로는 불가능했을 것입니다. 이번 사례에서 AI의 진정한 마법은 전체 그림을 이해하고, 도메인 지식을 적용하며, 문제 해결 방안을 제시하는 능력에 있습니다.
Coroot의 AI‑구동 근본 원인 분석
Coroot는 eBPF + 머신 러닝을 결합해 LLM만으로는 놓치기 쉬운 컨텍스트를 포착합니다. 모두를 위한 관찰성을 더 간단하고 접근 가능하게 만들겠다는 우리의 약속의 일환으로, 여러분도 Coroot를 설정할 수 있습니다.
무료로 오픈‑소스 버전과 함께 사용할 수 있습니다.
우리는 이것이 텔레메트리를 파고들어 시간을 절약하고 팀의 근본 원인 분석을 더 쉽게 만드는 데 도움이 되길 바랍니다.