AI가 만든 앱의 운영 문제, 자동으로 찾는 법

개발자가 코드를 읽고 문제를 찾는다.

앞으로 더 현실적인 방식은 이렇습니다.

시스템이 계속 검사하고
배포 전에 자동으로 막고
운영 중에는 패턴으로 감지하고
AI 리뷰어 스킬이 반복 실수를 찾아낸다

코드 리뷰 없이 이런 문제를 발견할 수 있을까?

가능합니다. 단, 사람의 눈으로 보는 코드 리뷰를 줄이려면 자동화된 가드레일이 필요합니다.

AI가 만든 앱에서 자주 생기는 문제는 대부분 패턴이 있습니다.

여기서 API는 앱끼리 요청과 응답을 주고받는 약속, DB는 데이터베이스, SQL은 데이터베이스에 질문하는 언어를 뜻합니다.

느린 API
데이터베이스(DB) 쿼리 수 증가
반복되는 SQL
페이지네이션 없는 대량 조회
긴 AI 작업으로 인한 타임아웃
사용자 수가 늘수록 급격히 느려지는 엔드포인트
토큰 비용 폭증
백그라운드 작업 실패 증가
권한 없는 접근 시도

이런 것들은 개발자가 코드를 한 줄씩 읽지 않아도 모니터링, 추적, 정적 분석, 성능 테스트, CI(Continuous Integration, 지속적 통합) 게이트로 꽤 많이 잡아낼 수 있습니다.

중요한 것은 “리뷰를 안 한다”가 아닙니다. 리뷰를 사람의 기억에 의존하지 않고 시스템화한다는 뜻입니다.

1. 운영 중에는 “증상”으로 찾는다

운영 환경에서 봐야 할 기본 신호는 네 가지입니다.

latency: 응답이 얼마나 느린가
traffic: 얼마나 많이 호출되는가
errors: 얼마나 자주 실패하는가
saturation: CPU, 메모리, DB 연결, 큐가 얼마나 찼는가

이 네 가지는 SRE(Site Reliability Engineering, 사이트 신뢰성 엔지니어링)에서 흔히 말하는 골든 시그널입니다. 특히 응답 시간 증가는 시스템 포화의 초기 신호가 될 수 있습니다. p99는 전체 요청 중 가장 느린 1%를 보는 지표입니다. 이런 꼬리 지연 시간(tail latency)을 보면 평균 응답 시간만 볼 때 놓치는 문제를 발견하기 쉽습니다. (Google SRE)

AI 앱에서는 여기에 몇 가지를 더 봐야 합니다.

AI 토큰 사용량
AI API 호출 횟수
AI API 타임아웃
작업 큐 대기 시간
작업 실패율
재시도 횟수
사용자별 비용
파일 처리 시간
DB 쿼리 수
DB 쿼리 총 시간

즉, 단순히 “서버가 살아 있나?”가 아니라 요청 하나가 내부적으로 어떤 일을 얼마나 많이 했는지를 봐야 합니다.

2. 추적으로 N+1 쿼리와 반복 호출을 찾는다

N+1 쿼리는 목록을 한 번 가져온 뒤, 목록의 각 항목마다 추가 쿼리를 다시 보내는 패턴입니다. 데이터가 적을 때는 티가 안 나지만, 항목 수가 늘면 요청 하나가 수십·수백 개의 데이터베이스 호출로 커집니다.

가장 강력한 방법은 분산 추적(distributed tracing)입니다.

예를 들어 요청 하나를 추적했을 때 이런 모양이 보인다면 위험합니다.

GET /users

DB: SELECT * FROM users
DB: SELECT * FROM orders WHERE user_id = 1
DB: SELECT * FROM orders WHERE user_id = 2
DB: SELECT * FROM orders WHERE user_id = 3
DB: SELECT * FROM orders WHERE user_id = 4
...
DB: SELECT * FROM orders WHERE user_id = 100

이건 전형적인 N+1 쿼리입니다.

개발자가 코드를 직접 보지 않아도 추적 결과만 보면 알 수 있습니다.

요청 하나에 DB 쿼리가 100번 이상 나간다
같은 SQL이 매개변수만 바뀌어서 반복된다
엔드포인트 응답 시간이 데이터 개수에 비례해서 증가한다

OpenTelemetry 같은 표준 관측성 프레임워크는 추적, 지표, 로그를 수집하고 내보내는 방식을 제공합니다. 특히 DB 클라이언트 span(작업 한 구간의 시간 기록)은 DB 호출 시간까지 관찰할 수 있으므로, 엔드포인트 하나 안에서 DB가 몇 번 호출되고 어디서 느린지 추적하는 데 적합합니다. (OpenTelemetry)

좋은 자동 감지 규칙은 이런 식입니다.

한 HTTP 요청 안에서 DB 쿼리가 20개를 넘으면 경고
50개를 넘으면 알림
같은 SQL 패턴이 10번 이상 반복되면 N+1 의심
DB 시간이 전체 요청 시간의 70% 이상이면 DB 병목 의심

3. 느린 API만 보지 말고 “느려지는 방식”을 본다

단순히 “응답 시간이 2초를 넘으면 알림”으로는 부족합니다.

AI가 만든 앱의 구조적 문제는 보통 이렇게 드러납니다.

레코드 50개: 100ms
레코드 500개: 800ms
레코드 5,000개: 타임아웃

즉, 중요한 것은 현재 속도만이 아니라 데이터 증가에 따른 기울기입니다.

확인해야 할 지표는 다음과 같습니다.

p50 latency
p95 latency
p99 latency
response size
rows returned
DB query count
DB total duration
memory usage
CPU usage

여기서 p50은 전체 요청의 가운데값, p95는 가장 느린 5%, p99는 가장 느린 1% 쪽 응답 시간을 보는 지표입니다. p99가 높으면 대부분은 빨라도 일부 사용자가 매우 느린 응답을 겪고 있다는 신호입니다.

예를 들어 GET /documents가 처음에는 200ms인데 문서 수가 늘수록 p95가 계속 올라가면 페이지네이션, 인덱스, 쿼리 구조를 의심해야 합니다.

4. 느린 DB 쿼리와 쿼리 계획으로 전체 스캔을 찾는다

코드 리뷰 없이도 DB가 위험한 쿼리를 알려줄 수 있습니다.

봐야 할 것은 이런 것들입니다.

slow query log
query duration
rows scanned
rows returned
index 사용 여부
sequential scan 여부
temporary sort 여부

PostgreSQL에서는 EXPLAIN을 사용해 쿼리 계획을 확인할 수 있고, planner가 어떤 방식으로 쿼리를 실행하는지 볼 수 있습니다. 쿼리 구조와 데이터 속성에 맞는 계획을 고르는 것이 성능에 중요하므로, 자주 쓰는 쿼리는 계획을 확인해야 합니다. (PostgreSQL)

예를 들어 이런 신호가 보이면 위험합니다.

Seq Scan on documents
Rows Removed by Filter: 499980
Execution Time: 3500ms

의미는 간단합니다.

필요한 행은 몇 개 안 되는데
DB가 테이블 대부분을 훑고 있다

이건 보통 인덱스가 없거나 쿼리가 인덱스를 못 쓰는 구조입니다.

자동화할 수도 있습니다.

배포 전 핵심 쿼리에 EXPLAIN 실행
Seq Scan이 특정 크기 이상 테이블에서 나오면 실패
예상 행 수와 실제 행 수 차이가 크면 경고
쿼리 시간이 기준을 넘으면 실패

5. 페이지네이션 누락은 운영 지표에서 쉽게 잡힌다

페이지네이션 없는 API는 운영 지표에서 바로 보입니다.

이런 패턴을 볼 수 있습니다.

response_bytes가 계속 커진다
rows_returned가 수천, 수만 개로 증가한다
p95 응답 시간이 데이터 개수와 함께 증가한다
메모리 사용량이 요청마다 튄다
브라우저가 목록 화면에서 멈춘다

자동 규칙은 이렇게 둘 수 있습니다.

목록 API에서 rows_returned > 200이면 경고
rows_returned > 1000이면 알림
response size > 1MB이면 경고
페이지네이션 파라미터 없이 목록 엔드포인트가 호출되면 경고

그리고 API 계약 자체에 규칙을 넣어야 합니다.

모든 목록 API는 limit을 가진다
기본 limit은 20 또는 50
최대 limit은 100 또는 200
커서 또는 페이지 토큰을 반환한다

6. 긴 AI 작업은 HTTP 지연 시간과 타임아웃으로 잡는다

HTTP(Hypertext Transfer Protocol)는 브라우저와 서버가 요청과 응답을 주고받는 기본 규칙입니다. HTTP 요청 안에서 너무 오래 걸리는 AI 작업을 처리하면 사용자는 기다리다가 타임아웃을 보게 됩니다.

AI 앱에서 아주 흔한 문제입니다.

사용자 요청
→ PDF 파싱
→ AI 호출
→ 요약 생성
→ DB 저장
→ 이메일 발송
→ HTTP 응답

이 구조는 데모에서는 괜찮지만 운영 환경에서는 위험합니다.

운영 중에는 이런 지표로 드러납니다.

POST /analyze p95 응답 시간이 30초 이상
HTTP 타임아웃 증가
사용자가 같은 요청을 여러 번 누름
AI API 재시도 증가
같은 작업 결과가 중복 저장됨
서버 메모리 급증

자동 규칙은 이렇게 둘 수 있습니다.

HTTP 요청이 5초 이상 걸리면 경고
10초 이상 걸리는 엔드포인트가 AI API를 호출하면 백그라운드 작업 전환 후보
파일 처리 + AI 호출 + 이메일 발송이 한 요청 안에 있으면 차단

좋은 구조는 이것입니다.

HTTP 요청은 작업만 생성한다
즉시 job_id를 반환한다
작업자가 백그라운드에서 처리한다
사용자는 작업 상태를 조회한다

운영 지표도 API가 아니라 작업 중심으로 봐야 합니다.

job_queue_wait_time
job_processing_time
job_success_rate
job_failure_rate
job_retry_count
job_cancel_count
ai_token_usage_per_job
ai_cost_per_job

7. 권한 문제는 자동 보안 테스트로 잡는다

권한 문제는 코드 리뷰보다 **부정 테스트(negative test)**가 더 효과적일 때가 많습니다.

예를 들어 문서 API가 있다고 합시다.

GET /documents/:id
PUT /documents/:id
DELETE /documents/:id

자동 테스트는 이렇게 해야 합니다.

User A가 만든 문서를 User B가 조회할 수 있는가?
User B가 User A의 문서를 수정할 수 있는가?
일반 사용자가 관리자 API를 호출할 수 있는가?
로그아웃 상태에서 파일 다운로드가 되는가?

이 테스트는 사람이 매번 리뷰하지 않아도 CI에서 실행할 수 있습니다.

OWASP(Open Web Application Security Project)는 웹 애플리케이션 보안을 다루는 공개 프로젝트입니다. ASVS(Application Security Verification Standard)는 웹 애플리케이션 보안 요구사항과 검증 기준을 제공하는 표준으로, 접근 제어, 입력값 검증, 오류 처리, 로깅 같은 항목을 자동 테스트 체크리스트로 바꾸기에 좋습니다. (OWASP Foundation)

권한 문제는 운영 모니터링에서도 일부 감지할 수 있습니다.

403 Forbidden 증가
다른 user_id 리소스 접근 시도 증가
관리자 엔드포인트 호출 실패 증가
다운로드 API의 비정상 호출 증가

403 Forbidden은 서버가 요청은 이해했지만 접근을 허용하지 않는 상태입니다. 예를 들어 로그인은 되어 있지만 다른 사용자의 문서를 열 권한은 없을 때 나올 수 있습니다.

하지만 권한 문제는 운영 중 발견하면 이미 위험합니다. 가능하면 배포 전에 자동 테스트로 막아야 합니다.

8. 코드 리뷰 대신 정적 분석 규칙을 만든다

반복되는 실수는 정적 분석으로 잡을 수 있습니다.

예를 들어 JavaScript/TypeScript 앱이라면 이런 패턴을 금지할 수 있습니다.

findMany() without take
getAllUsers()
getAllDocuments()
SELECT *
for loop 안의 await db.*
map(async ...) 안의 db query
API route without auth middleware
list endpoint without pagination
external API call without timeout

도구로는 CodeQL, Semgrep, ESLint 사용자 정의 규칙 같은 것을 쓸 수 있습니다. CodeQL은 코드를 데이터처럼 쿼리해서 취약점과 오류 패턴을 찾는 방식이고, GitHub code scanning과 연결해 알림으로 표시할 수 있습니다. (GitHub Docs) Semgrep은 직접 작성한 코드의 보안 취약점이나 특정 코드 패턴을 찾고 CI/CD에 통합할 수 있는 정적 분석 도구입니다. (docs.semgrep.dev)

예를 들어 이런 규칙을 만들 수 있습니다.

규칙: Prisma findMany에는 반드시 take가 있어야 한다.

나쁜 코드:
db.user.findMany()

허용 코드:
db.user.findMany({
  take: 50,
  cursor: ...
})

또 다른 규칙입니다.

규칙: API route에서 currentUser 또는 requireAuth가 없으면 실패

나쁜 코드:
export async function GET(req) {
  const docs = await db.document.findMany()
  return Response.json(docs)
}

허용 코드:
export async function GET(req) {
  const currentUser = await requireAuth(req)
  const docs = await db.document.findMany({
    where: { userId: currentUser.id },
    take: 50
  })
  return Response.json(docs)
}

이런 규칙은 사람 리뷰보다 더 일관되게 동작합니다.

9. 성능 테스트를 CI 게이트로 만든다

성능 문제는 운영 환경에서 처음 발견하면 늦습니다. 배포 전에 작은 부하 테스트라도 돌려야 합니다.

예를 들어 스테이징 DB에 큰 테스트 데이터를 넣습니다.

users: 100,000
documents: 1,000,000
messages: 5,000,000
jobs: 500,000

그리고 핵심 API에 대해 기준을 둡니다.

GET /documents p95 < 500ms
GET /documents DB query count <= 5
GET /documents rows_returned <= 100
POST /ai-jobs response time < 1s
GET /jobs/:id p95 < 300ms

k6 같은 부하 테스트 도구는 기준값을 정의해 성능 기대값을 통과/실패 기준으로 만들 수 있습니다. 즉, 성능 기준을 사람이 감으로 보는 것이 아니라 CI에서 실패시킬 수 있습니다. (Grafana Labs)

예를 들어 perf/documents.js라는 k6 테스트 파일을 이렇게 둘 수 있습니다.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const baseUrl = __ENV.BASE_URL;
  const response = http.get(`${baseUrl}/api/documents?limit=100`);

  check(response, {
    'status is 200': (res) => res.status === 200,
  });
}

이 기준은 30초 동안 가상 사용자 10명이 목록 API를 호출했을 때, p95 응답 시간이 500ms를 넘거나 실패율이 1% 이상이면 테스트를 실패시킵니다.

GitHub Actions에서는 스테이징 URL을 STAGING_URL secret으로 저장해두고 이렇게 실행할 수 있습니다.

name: Performance gate

on:
  pull_request:
  workflow_dispatch:

jobs:
  k6:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: grafana/setup-k6-action@v1
      - uses: grafana/run-k6-action@v1
        with:
          path: perf/documents.js
          flags: --env BASE_URL=${{ secrets.STAGING_URL }}

grafana/setup-k6-action은 k6를 설치하고, grafana/run-k6-action은 지정한 k6 테스트를 실행합니다. threshold가 실패하면 이 GitHub Actions job도 실패합니다. (grafana/run-k6-action)

중요한 것은 “많은 트래픽”만 테스트하는 것이 아닙니다. AI 앱에서는 다음도 테스트해야 합니다.

큰 파일 업로드
긴 프롬프트
동시 AI 작업 생성
AI API 실패
AI API 타임아웃
중복 제출
작업 재시도
사용자별 호출 제한

10. AI 비용 폭주는 사용량 모니터링으로 잡는다

AI 앱에서는 성능만큼 비용도 중요합니다.

운영 중 반드시 봐야 하는 지표는 다음입니다.

user_id별 AI 호출 수
endpoint별 AI 호출 수
작업별 입력 토큰
작업별 출력 토큰
모델별 비용
재시도로 인한 추가 비용
캐시 적중률
동일 문서 재처리 횟수

위험한 패턴은 이런 것입니다.

한 사용자가 짧은 시간에 수백 번 호출
같은 문서를 계속 다시 요약
실패한 AI 요청을 계속 재시도
무료 사용자가 고비용 모델 사용
목록 화면에서 행마다 AI API 호출

자동 방지책은 다음과 같습니다.

사용자별 일일 토큰 한도
작업별 최대 토큰 한도
모델별 예산
중복 문서 해시 기반 캐시
재시도 최대 횟수
고비용 작업은 큐로 제한
관리자 대시보드에 비용 표시

11. 개발 단계에서 “프로덕션 가드레일 스킬”을 만든다

가장 좋은 방법은 AI에게 앱을 만들게 한 뒤, 별도의 AI 스킬이 자동으로 검사하게 하는 것입니다.

이 스킬은 코드 리뷰어처럼 감상문을 쓰는 것이 아니라, 배포 차단 기준을 적용해야 합니다.

예를 들어 프로젝트에 이런 파일을 둡니다.

.ai/skills/production-guardrail.md

내용은 이런 식입니다.

너는 프로덕션 가드레일 리뷰어다.

목표:
AI가 만든 앱을 운영 환경에 배포하기 전에 위험한 구조를 자동으로 찾는다.

반드시 검사할 항목:
1. 페이지네이션 없는 목록 API
2. 반복문 안 DB 쿼리
3. 반복문 안 외부 API 호출
4. findMany without take
5. getAllUsers, getAllDocuments 같은 전체 조회
6. 서버 측 권한 확인 없는 API
7. user_id, organization_id 소유권 확인 누락
8. 입력값 검증 누락
9. 긴 AI 작업을 HTTP 요청 안에서 처리
10. 타임아웃 없는 외부 API 호출
11. 재시도는 있는데 멱등성이 없는 작업
12. DB 마이그레이션에 인덱스 누락
13. 작업 테이블/상태 없이 백그라운드 작업 처리
14. 토큰/비용 한도 없는 AI 호출
15. 핵심 경로에 로깅 누락

출력 형식:
- 차단 이슈: 배포하면 안 되는 문제
- 경고: 배포 전 수정 권장
- 제안: 구조 개선 제안

각 항목마다 다음을 작성한다:
문제:
위험한 이유:
어떤 규모에서 터지는가:
자동 검출 가능성:
수정 방향:

이 스킬은 개발자가 직접 코드 리뷰를 하지 않더라도, 매번 같은 기준으로 검사하게 만들 수 있습니다.

12. 배포 전 자동 게이트를 만든다

실제로는 이런 파이프라인을 추천합니다.

1. 린트
2. 타입 검사
3. 단위 테스트
4. API 계약 테스트
5. 보안 정적 분석
6. 운영 규칙 검사
7. DB 마이그레이션/인덱스 확인
8. 대용량 시드 데이터 성능 테스트
9. AI 사용량 예산 테스트
10. 프로덕션 가드레일 스킬 리뷰

배포 기준은 명확해야 합니다.

차단 이슈가 있으면 배포 실패
p95 응답 시간 기준 초과 시 배포 실패
목록 API에 페이지네이션이 없으면 배포 실패
인증 없는 보호 API가 있으면 배포 실패
DB 쿼리 수 예산 초과 시 배포 실패
AI 토큰 예산 초과 시 배포 실패

이렇게 하면 코드 리뷰를 사람이 매번 하지 않아도, 자주 반복되는 위험한 실수는 자동으로 막을 수 있습니다.

자동 감지 규칙 예시

실제로 봐야 할 대시보드

AI 앱이라면 대시보드를 이렇게 나누는 것이 좋습니다.

API 대시보드

endpoint별 p50 / p95 / p99 latency
endpoint별 error rate
endpoint별 request count
endpoint별 response size
endpoint별 timeout count

DB 대시보드

slow query top 20
query count per request
DB total duration per request
rows scanned / rows returned
index scan vs sequential scan
connection pool usage

AI 대시보드

model별 호출 수
model별 입력/출력 토큰
model별 비용
endpoint별 AI 비용
user별 AI 비용
재시도 횟수
타임아웃 횟수
캐시 적중률

작업 대시보드

queue length
queue wait time
job processing time
job success/failure rate
retry count
stuck jobs
dead letter queue

보안 대시보드

401 (인증 실패)/ 403 (권한 거부) rate
관리자 API 접근 시도
다른 사용자 리소스 접근 실패
파일 다운로드 실패/성공 비율
비정상적으로 많은 요청을 보내는 user_id

자주 묻는 질문

프로덕션 가드레일이란 무엇인가요?

프로덕션 가드레일은 위험한 코드, 느린 쿼리, 보안 허점, 실패하는 작업을 실제 사용자에게 도달하기 전 또는 도달한 직후에 잡아주는 자동화된 검사나 모니터입니다.

웹 애플리케이션에서 무엇을 모니터링해야 하나요?

응답 시간, 오류율, 데이터베이스 쿼리 수와 지속 시간, 큐 길이, AI 토큰 비용, 이상 접근 패턴을 모니터링하세요. 사용자에게 영향을 주는 지표부터 시작하세요.

로깅과 추적의 차이는 무엇인가요?

로깅은 개별 사건을 기록합니다. 추적은 하나의 요청이 여러 서비스를 지나가는 경로를 따라가며 시간이 어디에 쓰이고 어디서 실패하는지 보여줍니다.

CI 게이트란 무엇인가요?

CI 게이트는 코드가 배포되기 전에 실행되는 자동화된 검사입니다. 린트, 테스트, 타입 검사, 보안 스캔, 쿼리 계획 검사 등이 포함될 수 있습니다.

같은 운영 버그가 반복되지 않게 하려면 어떻게 하나요?

장애를 규칙으로 만드세요. 다음에 같은 패턴을 잡을 수 있는 정적 분석 검사, 테스트, 알림을 추가하고 CI 파이프라인에 포함하세요.

핵심은 “사후 감지”와 “사전 차단”을 같이 하는 것

모니터링만 있으면 문제를 빨리 발견할 수는 있습니다. 하지만 이미 운영 환경에서 사용자에게 영향을 준 뒤일 수 있습니다.

그래서 구조는 이렇게 가져가야 합니다.

개발 중:
AI 스킬 + 정적 분석 + lint 규칙

배포 전:
CI 게이트 + 성능 테스트 + 보안 테스트 + DB 쿼리 계획 검사

운영 중:
관측성 + 대시보드 + 알림 + 이상 감지

장애 후:
발견된 문제를 다시 정적 규칙이나 테스트로 등록

마지막 단계가 중요합니다.

한 번 운영 환경에서 발견된 문제는 다시 사람이 기억하게 만들면 안 됩니다. 반드시 규칙으로 만들어야 합니다.

장애 발생
→ 원인 분석
→ 감지 가능한 패턴 추출
→ 정적 규칙 또는 런타임 알림 추가
→ CI 게이트에 포함
→ 같은 실수 재발 방지

결론

요즘 개발자는 모든 코드를 일일이 리뷰하지 않는 방향으로 가고 있습니다. 특히 AI가 코드를 많이 생성하는 환경에서는 사람이 모든 변경 diff를 읽는 방식이 더 이상 잘 맞지 않습니다.

대신 필요한 것은 자동화된 프로덕션 가드레일입니다.

코드에서 위험한 패턴을 찾고
배포 전에 성능과 보안을 검증하고
운영 중에는 응답 시간, 쿼리 수, 토큰 비용, 작업 실패 같은 신호를 감시하고
문제가 발견되면 다시 규칙으로 만들어 재발을 막는다

AI가 만든 앱의 문제는 대부분 갑자기 생기지 않습니다. 먼저 신호가 나타납니다.

응답 시간이 조금씩 늘어난다
DB 쿼리 수가 많아진다
같은 SQL이 반복된다
응답 크기가 커진다
작업 큐가 밀린다
AI 비용이 특정 엔드포인트에서 튄다
특정 사용자의 실패율이 높아진다

이 신호를 볼 수 있게 만들면, 코드 리뷰 없이도 많은 문제를 발견할 수 있습니다.

그리고 더 좋은 방법은 운영 환경에서 발견하기 전에 막는 것입니다.

AI 시대의 프로덕션 개발은 “코드를 잘 읽는 능력”보다 “실수를 자동으로 발견하는 시스템을 만드는 능력”이 더 중요해지고 있습니다.