AI 정적분석으로 서비스의 한계 찾기

안녕하세요. 노머스 백엔드팀에서 fromm 서비스를 개발하는 김연태입니다.

이슈찾기대회

지난 8월, 테크조직에서는 이슈찾기대회가 열렸습니다.

fromm은 특정 아티스트의 채팅, 게시글, 라이브 한번에 해당 아티스트의 모든 팬덤들이 일제히 움직입니다. 따라서 전체 유저수의 증가보다는 가장 큰 팬덤이 어느정도의 규모인지가 최대 트래픽을 결정하는 특징이 있습니다. 2026년 들어 몇몇 아티스트들의 급격한 성장이 있었고 앞으로도 더욱 큰 트래픽을 소화할 필요가 있었기에 현재의 서비스 수준을 점검할 필요가 있었습니다.

부하테스트

서비스가 어느정도의 트래픽을 소화할수 있는가? 라는 질문에 대해 대답할 수 있는 방법으로는 부하테스트를 떠올리기 가장 쉽습니다. 물론 fromm 서비스에서도 다양한 방법으로 꾸준히 부하테스트를 진행해왔고 이런 방법들을 Wonderwall 은 부하 테스트를 어떻게 진행했을까? 를 통해 공유한적도 있습니다. 그러나 부하테스트는 다음과 같은 문제들이 있었습니다.

복잡한 시나리오 테스트의 어려움

locust, k6, artillery 등 기존에 사용하던 부하발생기로는 시나리오가 복잡한 경우를 테스트하기 어려웠습니다. VWR(대기열시스템)을 예로 들면 오픈 직후 3만명의 트래픽이 한번에 몰리고, 이후 10초 동안 추가로 들어오는 트래픽의 60% 가량이, 그 이후 10분 동안 나머지 40%의 트래픽이 들어오는 상황에서 대기 중인 사람들의 약 3%가 매분 접속을 종료하는 시나리오는 부하발생기의 기본 기능만으로 재현하기가 쉽지 않았습니다. 여기에 인증 여부에 따라 동작이 달라지는 API를 반드시 함께 테스트해야 하는 경우에도 시나리오를 구성하기가 어려웠습니다.

k8s 를 사용해 일부 해결했으나 많은 비용 발생

이런 시나리오를 테스트하기 위해 k8s 위에 원하는 client를 직접 pod로 띄워 부하테스트를 진행했고, 복잡한 시나리오의 상당 부분을 해결할 수 있었습니다. 하지만 client를 구성하는 것 외에도 이를 제어할 controller, 테스트 중 상황을 확인할 dashboard 등을 함께 구성해야 했고 여기에 많은 시간이 들었습니다. 준비 기간이 길어지는 만큼 부하테스트 기간도 길어졌고, 그동안 k8s 인프라에 사용되는 비용도 함께 늘어났습니다.

이러한 문제 때문에 부하테스트는 fromm 서비스 전체를 점검하는 용도보다는 채팅, VWR, 특정 페이지 입장 등 일부 영역에 한정해 지엽적으로 진행되어 왔습니다. 물론 해당 영역에 대해서는 어느정도의 트래픽을 소화할 수 있는지 예측하고 향후 대응 방향을 잡을 수 있었습니다. 하지만 부하테스트를 수행했음에도 예상하지 못한 곳에서 장애가 발생하거나, 트래픽과는 무관하게 유저 혹은 컨텐츠 수가 늘어나는 것만으로 장애가 발생하는 경우도 있었습니다.

그래서 이번 이슈찾기대회에서는 부하테스트로는 발견하지 못했지만 여전히 잠재되어 있는 문제들을 그동안의 경험과 AI의 힘을 빌려 찾아보고자 했습니다.

첫번째 시도

그동안 팀의 백엔드 개발자로 일하면서 다양한 장애를 겪었을 뿐만 아니라, 당장 장애로 이어지지는 않았지만 위험해 보이는 알람과 로그들도 많이 봐왔습니다. 이 중에는 아직 일부만 대응되었다고 생각하거나 제대로 대응되었는지 확신이 없는 것들도 있었는데요, 첫번째 시도에서는 이런 사례들을 바탕으로 fromm의 백엔드 레포를 Claude에게 주고 같은 문제가 발생하거나 더 크게 확대될 수 있는 부분을 코드 기반으로 찾아달라고 요청했습니다.

비슷한 문제가 많이 발견될 거라고 기대했지만 결과는 달랐습니다. 제가 예시로 준 것과 같은 수준의 문제는 거의 나오지 않았고, 대신 트래픽이 늘었을 때 이런 부분이 문제가 될 수 있다는 의견만 이것저것 많이 나왔습니다. 그래서 하나씩 검수를 해보았는데 대부분 근거가 부족해 신뢰하기 어려웠고, 실제 서비스 상황과는 동떨어진 이야기들이 대부분이었습니다.

원인은 다음과 같았습니다.

• 백엔드 레포만 제공하다 보니 AI가 각 API와 코드가 어디에서 어떻게 사용되는지 알 수 없었다.
• 같은 종류의 문제라 하더라도 완전히 같은 형태의 코드가 아니라면 식별하지 못했다.

두번째 시도

이번에는 웹, 앱 등 프론트엔드 레포까지 모두 제공해서 어떤 API가 어디에서 호출되는지 알 수 있도록 했습니다. 또 첫번째 시도에서 문제를 한정해주니 그 문제 위주로만 찾는 것 같아서, 이번에는 현재 어느정도의 유저가 가입되어 있고 어느정도의 트래픽이 발생할 수 있는지 상황만을 제시한 채 문제를 찾아보도록 했습니다.

식별된 문제는 첫번째 시도보다 훨씬 늘었지만 여전히 유의미한 문제는 많지 않았습니다. 코드리뷰 수준의 지적이 너무 많이 나와서 그 중 정말 맞다고 생각되는 내용을 하나씩 골라내기조차 어려운 수준이었고, 트래픽에 대한 예측은 여전히 근거 없이 추측에 가까웠습니다.

이번에 생각한 원인은 다음과 같았습니다.

• AWS의 네트워크, 인스턴스 타입, 큐 및 이벤트 소스 설정 등 인프라 레벨에서 정의되는 정보와 한도(limit)를 알지 못한다.
• 서비스에서는 DB 테이블 중 필요한 컬럼만 엔티티로 정의해서 사용하고 있어, AI는 실제 테이블 구조와 테이블의 데이터 규모를 알지 못한다.
• 상황만 주고 문제를 찾게 하기에는 질문이 너무 광범위하다.

어떻게 하면 잘 찾아낼 수 있을까?

두번의 실패를 겪고 나니 AI에게 적절한 정보를 제공하지도, 좋은 질문을 하고 있지도 않다는 생각이 들었습니다. 그래서 우선 AI를 사용하지 않는다는 가정 하에, 부하테스트를 거치지 않고도 서비스의 안정성을 예측할 수 있는 방법론에는 어떤 것들이 있는지 찾아본 뒤 이 방법들을 모아 스킬로 만들어 문제를 찾아보기로 했습니다.

찾은 방법들은 다음과 같습니다.

Google NALSD (Non-Abstract Large System Design)

Google SRE Workbook 12장에서 소개하는 방법으로, 설계가 몇 배의 트래픽까지 버틸 수 있는지를 실제 숫자로 계산해서 검증합니다.

• 가능한가, 더 낫게 할 수 있는가, 예산 안에서 가능한가, 장애를 견디는가를 반복해서 묻는다.
• 새로운 설계뿐 아니라 이미 운영 중인 시스템을 분석하는 용도로도 사용한다.
• 초당 500 요청, 평균 지연 200ms면 동시에 처리 중인 요청은 100개와 같이 throughput과 latency로 동시성을 계산한다.
• 단 “load testing is still a necessity”라고 하며, 계산은 설계를 검증하는 용도일 뿐 부하테스트는 여전히 필요하다고 이야기한다.

Google PRR (Production Readiness Review)

Google SRE Book 32장에서 소개하는 방법으로, SRE 팀이 서비스의 운영을 넘겨받기 전에 거치는 신뢰성 리뷰입니다.

• 서비스의 세부 사항을 기반으로 신뢰성 요구사항을 식별하는 절차.
• 아키텍처와 서비스 간 의존성, 메트릭과 모니터링, 긴급 대응, Capacity planning, Change management, 성능을 리뷰한다.
• 유저 입장에서의 실패가 제대로 모니터링되고 알람이 설정되어 있는지까지 함께 확인한다.

AWS ORR (Operational Readiness Review)

AWS가 운영 장애에서 얻은 교훈을 질문 목록으로 정리해, 다른 팀이 같은 장애를 반복하지 않도록 만든 리뷰 방법입니다.

• 장애 사후 분석(COE)의 결과를 모범 사례가 포함된 질문 목록으로 만든다.
• 장애를 더 짧게, 더 적게, 더 작게 만드는 것을 목표로 한다.
• 한 번 발생한 장애를 질문으로 바꿔 다른 워크로드에도 동일하게 적용한다.

AWS Well-Architected Reliability Pillar

AWS Well-Architected Framework의 안정성 원칙입니다.

• 서비스 쿼터와 제약 조건을 파악하는 것이 확장성 검토의 출발점이다.
• REL01-BP06은 현재 쿼터와 최대 사용량 사이에 장애 조치를 흡수할 수 있는 여유(ex. 15%)를 두라고 권장한다.
• 리전마다 기본 쿼터가 같다고 가정하거나 피크 트래픽으로 검증하지 않는 것을 안티패턴으로 꼽는다.

Azure Well-Architected FMA (Failure Mode Analysis)

Azure Well-Architected의 RE-03 항목으로, User Flow의 각 단계별로 발생할 수 있는 장애를 식별하는 방법입니다.

• User Flow를 중요도에 따라 나눈 뒤 단계마다 장애 유형, 영향 범위, 대처 방안을 정리한다.
• 장애 유형에 Component overload가 포함되어 트래픽 증가 상황을 그대로 다룰 수 있다.
• 발생 가능성은 숫자가 아닌 정성적인 등급으로 판단한다.

Limit과 Quota

코드와 설정의 한도와 클라우드 서비스의 기본 쿼터를 가지고 문제가 되는 포인트를 계산하는 방법입니다.

• Little’s Law를 사용해 Lambda 동시성, DB 커넥션, 처리 중인 요청 수를 RPS × 평균 지연 으로 계산한다.
• 하지만 평균 latency를 모르면 몇 배까지 버티는지는 알 수 없고, 평균값만으로는 성능이 급격히 무너지는 지점을 예측할 수 없다는 한계가 있다.

자료조사의 결론

자료조사를 하면서 깨달은 것은 부하테스트를 대체하겠다는 목적으로는 원하는 문제를 찾을 수 없다는 점이었습니다. 부하테스트로 발견할 수 있는 문제와 소스코드 및 인프라 설정을 입력으로 발견할 수 있는 문제는 애초에 종류가 달랐습니다. 무엇을 입력으로 쓰느냐에 따라 알 수 있는 내용은 다음과 같이 나뉘었습니다.

코드와 설정만으로 알 수 있는 내용

• 커넥션 풀 크기 × 최대 동시 실행 수와 DB의 max_connections
• SQS의 VisibilityTimeout과 컨슈머 Lambda의 timeout
• DLQ가 설정되지 않은 큐
• SQS FIFO의 throughput limit
• SQS의 최대 동시성과 Lambda 계정 동시성

CloudWatch Metrics, Service Logs, Quota Docs로 알 수 있는 내용

새로 부하를 발생시키지 않아도, 이미 쌓여 있는 메트릭과 로그, Quota Docs로 얼마나 여유가 있는지 확인할 수 있습니다.

• 큐의 메시지 지연 메트릭
• Lambda Throttles 발생 히스토리
• DB 커넥션 Usage
• 서비스 쿼터 대비 현재 사용량

부하테스트를 시행해야 알 수 있는 내용

실제로 부하를 발생시켜야만 측정할 수 있는 값들입니다.

• 요청당 서비스 처리 시간
• 콜드스타트 p99 Latency
• 장애 복구 시 요청이 한번에 몰리는 thundering herd

이 중 부하테스트를 제외한 두 가지 영역의 문제를 최대한 식별하고자 했습니다.

세번째 시도

제공하는 정보

세번째 시도에서는 코드만 제공하지 않고, 코드가 실제로 동작하는 환경에 대한 정보를 먼저 정리해서 함께 제공했습니다.

AWS 인프라

• awscli로 읽기 전용 조회 명령만 실행해 인프라 설정을 수집한 뒤, 민감한 값들은 마스킹했습니다.
• 수집된 내용이 AI에게 제공되어도 괜찮은 정보인지 확신이 없는 부분은 수동으로 하나씩 확인했습니다.
• 전체 과정 중 가장 많은 시간이 소요된 정보 정리 과정이었습니다.

DB 스키마

• 이미 여러 레포에 DDL이 sql 파일로 정리되어 있었고 entity 정의, DML 문서 등도 있어서 AI를 사용해 수집할 수 있다고 판단했습니다.
• 다만 레포의 정의와 실제 테이블이 다를 수 있기 때문에 정확한 정보를 위해서는 운영 DB에서 직접 수집해야 한다고 생각했고, 운영 DB에 영향을 주지 않도록 수집 방법에 신경을 썼습니다.
• Reader 인스턴스에서 pg_dump 대신 카탈로그 조회만 사용했고, 테이블의 행 수도 COUNT(*) 대신 reltuples의 추정치를 사용했습니다.

아키텍쳐

• 배포 설정을 파싱하고 각 소스코드를 분석해서 서비스 간의 흐름을 diagram으로 생성했습니다.

어떻게 문제를 찾을지에 대한 프롬프팅

문제를 찾을 때는 RPS에 대한 문제와 N에 대한 문제를 나누고자 했습니다. 어떤 인프라로 어느정도의 RPS까지 버틸 수 있는지와, 처리해야 하는 데이터의 규모(N)가 커졌을 때 소스코드 레벨에서 어떤 문제가 발생할 수 있는지는 서로 다른 질문이었습니다. 예를 들어 IN 절에 대상 유저 id를 그대로 넘기는 쿼리는 대상 유저 수가 PostgreSQL의 바인드 파라미터 상한인 65,535를 넘는 순간 요청 한 건만으로도 실패합니다. 이런 문제는 RPS를 아무리 높여도 테스트 데이터의 규모가 작으면 드러나지 않습니다. 이렇게 질문을 나눈 뒤 앞에서 소개한 방법들을 각각 독립적으로 수행하며 문제를 찾도록 했습니다.

프롬프팅의 전체적인 방향은 다음과 같았습니다.

수집한 자료와 AI가 판단한 결과는 디렉토리부터 분리해서 관리했습니다. 이렇게 하면 모든 모델이 동일한 자료를 입력으로 사용하게 되고, 모델이 내린 판단이 다시 다른 모델의 입력으로 섞여 들어가는 것을 막을 수 있습니다.

모델간 교차검증

하나의 모델로만 이 작업을 수행하면 실제로는 문제가 되지 않는 부분을 편향되게 이야기하거나, 존재하지 않는 문제를 이야기하는 경우가 있었고 이를 사람이 하나하나 검수해야 했습니다. 그래서 제가 검수하기 전에 서로 다른 모델들로 각각 문제를 찾은 뒤, 각 모델이 낸 결론을 해당 모델을 제외한 다른 모델들이 적대적으로 리뷰하고 그 결과를 병합하면 신뢰도를 높일 수 있을 것이라고 판단했습니다.

사용된 하네스와 모델들은 다음과 같습니다.

• Claude - Fable5
• Claude - Opus5
• Codex - GPT5.6 Sol
• Codex - GPT5.6 Luna
• Antigravity - Gemini 3.7 Flash
• Pi - Grok4.6
• Opencode - Muse Spark 1.2

전체 흐름은 다음과 같습니다.

최종 제출

이 과정을 거쳐 나온 문제들도 결국 전부 직접 검수를 거쳐야 했습니다. 하지만 첫번째, 두번째 시도에서 얻은 결과보다 훨씬 신뢰할 수 있는 수준이었고, 실제로 다수의 문제들은 비즈니스 요구사항에 따른 영향도와 우선순위만 다시 매긴 뒤 우선순위가 높은 순서대로 제출할 수 있었습니다.

부족했던 점

시간에 쫓겨 최종 제출은 완료했지만, 직접 검수하는 단계에서 아쉬웠던 점들을 소개합니다.

서비스 쿼터를 수집 목록에 넣지 않았다

Lambda Concurrency Limit, ElastiCache Parameter Group 설정, IoT Core의 Service Quota 정보를 넣어주지 않아서, 4건의 문제는 실제 한도를 확인하지 못한 채 미확인 상태로 남았습니다. 앞에서 소개한 Well-Architected Reliability Pillar가 가장 먼저 확인하라고 하는 항목이 서비스 쿼터였는데 이번엔 이 부분이 빠졌습니다.

이미 있는 메트릭을 대부분 사용하지 못했다

부하를 발생시키지 않아도 확인할 수 있는 지표들이 이미 쌓여 있었지만 모든 로그 및 메트릭을 조회할 시간이 없었고, 대부분 활용하지 못했습니다.

• Lambda의 Throttles, ConcurrentExecutions 메트릭
• SQS의 ApproximateAgeOfOldestMessage (큐에서 가장 오래 대기 중인 메시지의 시간)
• PostgreSQL의 pg_stat_activity를 통한 커넥션 사용 현황
• pg_stat_statements에 기록된 쿼리별 파라미터 개수의 최대값

결론

부하테스트 vs 정적분석

처음에는 부하테스트를 대신하는 방법으로 접근했지만, 제가 시도한 정적분석은 부하테스트를 대체하는 방법이 아니라 서로 보완하는 방법이라는 것을 알 수 있었습니다. 부하테스트와 정적분석이 각각 나눠서 맡을 수 있는 역할은 다음과 같았습니다.

	부하테스트	정적분석
조작하는 변수	RPS, 동시 사용자 수	N(데이터 규모), 설정값, 배치 크기
답하는 질문	이 시나리오에서 어디까지 버티는가	시나리오 밖에 어떤 문제가 있는가
결과물	포화 지점, p99 지연, 인프라 스펙	위험 지점 목록, 수정할 코드
필요한 것	테스트 환경, 데이터, 부하발생기, 시간	코드, 설정, DB 스키마, 인프라
할 수 없는 것	시나리오에 없는 경로, 작은 N으로는 드러나지 않는 문제	포화 지점, 성능이 급격히 무너지는 시점, 실제 처리 시간
비용	준비 비용이 크고 반복할 때마다 비용이 크다	준비 비용은 크지만 한번 준비하면 반복 비용이 적다
역할	가설을 검증	테스트 시나리오의 초안

앞으로의 시도

이번 이슈찾기대회 과정을 통해 많은 문제들을 효과적으로 찾을 수 있었고, 퀄리티부문 1등이라는 성과도 얻을 수 있었습니다. 이 과정에서 많은 시행착오를 겪으며 나름대로 효과적인 방법을 찾은 만큼, 앞으로의 과제는 부하테스트 대비 저렴한 비용으로 자주 반복할 수 있는 이 방법들을 어떻게 잘 활용해서 꾸준히 서비스의 퀄리티를 높여갈 수 있을지에 대한 고민이 필요할 것 같습니다.

여기까지 글을 관심있게 읽어주신 모든분께 감사드립니다🙇‍

당신의 예술이 세상을 바꾼다.

저희와 함께 서비스의 품질을 높이기 위해 고민하고 함께 성장해나갈 개발자를 찾습니다. 관심있으신분들은 우측상단 Recruit 버튼을 통해 언제든지 지원부탁드립니다😀

참고자료

• NALSD Workbook (Google SRE Classroom, PDF)
• The Evolving SRE Engagement Model (Google SRE Book, Ch.32)
• Managing Load (Google SRE Workbook, Ch.11)
• Operational Readiness Reviews (AWS Well-Architected)
• REL01-BP06 Ensure that a sufficient gap exists between the current quotas and the maximum usage (AWS)
• Failure mode analysis RE:03 (Azure Well-Architected)
• Capacity planning PE:02 (Azure Well-Architected)
• Telling Stories About Little’s Law (Marc Brooker)
• Lambda quotas
• Lambda SQS scaling
• SQS quotas
• PostgreSQL limits
• Wonderwall 은 부하 테스트를 어떻게 진행했을까?
• 대기열 서비스 10만명 부하테스트 여정기
• LLM 심판 에이전트와 함께한 사내 이슈 찾기 대회: AI 판정을 시도하며 배운 것