CI/CD에서의 LLM 통합: 코드 완성 그 이상의 실제 활용 사례

README.md 파일에 GitLab API 토큰이 나타났습니다. 이 토큰은 머지(merge)되기 전, 커밋(commit)되고 푸시(push)되었으며 두 명의 엔지니어에 의해 리뷰되었습니다. 하지만 아무도 이를 발견하지 못했습니다.

이것은 주니어 개발자의 실수가 아니었습니다. 두 리뷰어 모두 숙련된 인원이었습니다. 토큰은 200줄짜리 파일의 47번째 줄에 있었고, 설치 지침 사이에 끼어 있었습니다. 스프린트(sprint)가 끝나갈 무렵, 다른 세 개의 리뷰가 대기 중인 상황에서 그것은 마치 문서처럼 보였습니다. 그것은 눈에 띄게 노출된 비밀(secret)이었습니다.

우리는 다음 날 정기 감사(audit) 중에 이를 발견했습니다. 그때 이미 해당 토큰은 저장소(repository)에 18시간 동안 머물러 있었습니다.

3주 후, 우리의 Jenkins MR(Merge Request) 검증 파이프라인에 LLM을 통합한 후에는, 동일한 패턴 — 즉 문서에 임베디드된 토큰 — 이 사람이 리뷰를 위해 디프(diff)를 열기 전, 자동으로 플래그(flag)가 지정되었을 것입니다. 심각도(severity)는 CRITICAL. 특정 라인 지정. 수정 제안까지 포함해서 말입니다.

그 단 한 번의 사건이 통합의 정당성을 부여했습니다. 그 이후에 이어진 모든 과정은 그것이 올바른 아키텍처 결정이었음을 확인시켜 주었습니다.

이 글은 우리가 무엇을 구축했는지, 무엇을 배웠는지, 그리고 더 중요하게는 CI/CD에서의 LLM 통합이 실제로 효과를 발휘하는 곳은 어디인지, 반대로 해결하는 문제보다 더 많은 문제를 일으키는 곳은 어디인지에 대해 다룹니다.

왜 CI/CD가 적절한 통합 지점인가

구체적인 활용 사례를 살펴보기 전에, 왜 CI/CD 파이프라인가 LLM 통합에 특히 적합한지에 대해 정확히 짚고 넘어갈 가치가 있습니다.

LLM은 텍스트를 기반으로 작동하는 패턴 인식기(pattern recognizers)입니다. CI/CD 파이프라인은 예측 가능한 시점에 엄청난 양의 구조화된(structured) 및 반구조화된(semi-structured) 텍스트를 생성합니다: 머지 시점의 코드 디프(code diffs), 실패 시의 빌드 로그(build logs), 적용(apply) 전의 인프라 계획(infrastructure plans), 배포 이벤트(deployment events), 테스트 결과(test results) 등이 그것입니다. 이 텍스트들은 이미 생성되고 있습니다. 문제는 이를 다음 파이프라인 단계로 전달하는 것 이상의 유용한 작업을 수행할 수 있느냐 하는 것입니다.

특정 사례의 경우, 답은 '예'입니다. 그리고 핵심 단어는 '특정'입니다.

대부분의 팀이 CI/CD에서 LLM 통합을 탐색할 때 범하는 실수는 이를 타겟팅된 기능이 아닌 일반적인 기능으로 취급하는 것입니다. LLM은 이미 대부분의 파이프라인(pipelines)에 존재하는 결정론적 도구(deterministic tools) — 린터(linters), 정적 분석기(static analyzers), 테스트 러너(test runners) — 를 대체하는 것이 아닙니다. LLM은 바로 그러한 결정론적 도구들이 부족한 부분, 즉 문맥적 패턴 인식(contextual pattern recognition), 자연어 생성(natural language generation), 그리고 규칙 기반 시스템(rules-based system)에 깔끔하게 들어맞지 않는 교차 분석(cross-cutting analysis) 분야에서 유용합니다.

이러한 프레임워크를 바탕으로, 실제 운영 환경에서 효과가 있었던 다섯 가지 활용 사례를 소개합니다.

활용 사례 1: 자동화된 MR/PR 코드 리뷰

작동 방식: 머지 리퀘스트(merge request)의 diff를 가져와서, 구조화된 리뷰 프롬프트(review prompt)와 함께 변경된 파일들을 LLM으로 전송한 뒤, 사람이 리뷰를 열어보기 전에 MR에 인라인 댓글(inline comments)로 분석 결과를 직접 게시합니다.

구현: Jenkins 파이프라인이 GitLab 웹훅(webhook)을 통해 모든 MR 이벤트 발생 시 트리거됩니다. Python 스크립트가 GitLab API를 통해 diff를 가져오고, 파일 유형을 인식하는 프롬프트(Python, Terraform, JavaScript에 대한 별도 프롬프트)와 함께 각 변경된 파일을 LLM에 전송하며, GitLab API를 통해 분석 결과를 다시 MR에 게시합니다.

파이프라인 단계:

stage('AI Code Review') {
    when {
        expression {
...

post { failure } 블록은 타협할 수 없는 필수 사항입니다. AI 리뷰 단계는 LLM API 실패나 타임아웃(timeout)으로 인해 머지(merge)를 차단해서는 절대로 안 됩니다.

월 100개 이상의 MR에서 잡아내는 것들:

하드코딩된 자격 증명(credentials) — 코드나 문서에 포함된 API 키, 데이터베이스 비밀번호, 토큰. Terraform 보안 설정 오류 — 0.0.0.0/0에 개방된 보안 그룹(security groups), 암호화되지 않은 RDS 인스턴스, IAM 와일드카드 정책(wildcard policies). 비동기 함수(async functions)에서의 에러 핸들링(error handling) 누락. 애플리케이션 로그에 기록된 민감한 데이터.

실제로 필요했던 프롬프트 엔지니어링(prompt engineering):

첫 번째 버전은 심각도(severity) 구분 없이 MR당 30개 이상의 결과물을 생성했습니다. 개발자들은 일주일 만에 리뷰를 읽는 것을 중단했으며, 이는 AI 리뷰가 아예 없는 것보다 더 나쁜 결과였습니다. 세 번의 수정을 통해 이를 해결했습니다.

리뷰당 최대 10개의 결과(findings)로 제한을 두어 모델이 우선순위를 정하도록 강제했습니다. 필수적인 심각도 분류(CRITICAL/HIGH/MEDIUM/LOW)를 통해 개발자가 모든 내용을 읽지 않고도 우선순위를 정할 수(triage) 있게 했습니다. 파일 유형별 프롬프트(File-type-specific prompts) — Terraform 리뷰는 Python 리뷰와 다른 사항을 점검함 — 를 도입하여 무관한 결과들을 극적으로 줄였습니다.

비용 고려 사항: MR(Merge Request)이 월 100개 이상이고 각 MR마다 여러 파일이 포함되는 경우, 모델 선택이 매우 중요합니다. 이 정도 규모에서는 가볍고 높은 처리량(high-throughput)에 최적화된 모델이 빠르고 비용 효율적입니다. 자동화된 코드 리뷰를 위해 더 뛰어난 추론 모델(reasoning model)을 사용하는 것은 비용 효율적이지 않습니다. 해당 작업에는 그 정도의 능력이 필요하지 않기 때문입니다.

활용 사례 2: 파이프라인 실패 진단 (Pipeline Failure Diagnosis)

작동 방식: CI/CD 파이프라인이 실패하면, 실패 로그가 LLM으로 전송되어 평이한 영어(plain-English)로 된 진단과 권장 조치 단계(remediation steps)를 반환합니다. 이는 파이프라인 실패 알림의 추가 정보로 구조화되어 제공됩니다.

해결하는 문제: 빌드 로그를 읽는 것은 느리고, 엔지니어마다 달라지는 컨텍스트(context)를 필요로 합니다. 파이프라인 출력에서 CrashLoopBackOff로 나타나는 Kubernetes 포드(pod) 실패는 로그를 추출하고, describe 출력을 읽고, 최근 변경 사항과 교차 참조하는 과정이 필요합니다. 숙련된 엔지니어는 이를 10~15분 내에 수행할 수 있습니다. 경험이 적은 엔지니어는 45분이 걸릴 수도 있으며, 여전히 근본 원인(root cause)을 놓칠 수 있습니다.

LLM은 동일한 로그 출력을 읽고 30초 이내에 구조화된 진단을 반환할 수 있습니다. 항상 정확한 것은 아닙니다. 하지만 엔지니어가 수동 조사를 시작하기 전에 가장 먼저 확인해야 할 사항이 될 만큼 충분히 자주 정확합니다.

출력 형태:

진단(DIAGNOSIS): OOMKill — 컨테이너가 메모리 제한을 초과함

메모리 고갈로 인해 kubelet에 의해 포드가 종료되었습니다.
...

구현 패턴: 실패 후 웹훅(post-failure webhook)이 스크립트를 트리거하여 파이프라인 로그의 마지막 200줄과 특정 실패 단계의 출력을 추출합니다. 이를 LLM에 보내고, 진단 내용을 Slack 실패 알림에 추가합니다. 엔지니어는 별도로 확인하는 것이 아니라 알림과 함께 컨텍스트를 전달받게 됩니다.

활용 사례 3: 인프라 계획 검토 (Infrastructure Plan Review)

기능: 파이프라인에서 terraform apply가 실행되기 전, 계획(plan) 출력 결과가 보안 및 구성 검토를 위해 LLM으로 전송됩니다. 발견된 사항은 파이프라인 댓글로 게시되며, CRITICAL 등급의 발견 사항에 대해서는 선택적으로 apply 단계를 차단(gate)할 수 있습니다.

중요성: Terraform 계획 검토는 '지친 엔지니어 문제(tired engineer problem)'가 가장 심각하게 나타나는 지점입니다. 인프라 변경 사항이 파이프라인의 apply 단계에 도달할 때쯤이면, 대개 한 번의 검토를 거친 상태입니다. 하지만 이 검토는 종종 매우 빠르게 이루어지며, Terraform에 대한 컨텍스트가 부족한 사람이 수행하는 경우가 많습니다. 개별적으로 보면 명백한 보안 설정 오류(security misconfigurations)도 200줄에 달하는 계획 출력물 속에서는 보이지 않게 됩니다.

탐지 내용:

CRITICAL: aws_security_group.api — ingress rule allows 0.0.0.0/0
on port 5432 (PostgreSQL). Database should not be publicly accessible.
Fix: restrict to application security group ID only.
...

차단(Gate) vs 정보 제공(Inform): CRITICAL 등급의 발견 사항에 대해서는 apply가 진행되기 전 수동 승인을 요구하도록 파이프라인을 구성할 수 있습니다. HIGH 이하 등급의 경우, 발견 사항은 정보 제공용으로 처리됩니다. 즉, apply는 실행되지만 팀에 알림이 전송됩니다. 이러한 균형을 통해 정당한 변경 사항을 차단하지 않으면서도, CRITICAL 보안 이슈에 대해서는 반드시 사람의 검토를 거치도록 보장할 수 있습니다.

활용 사례 4: 릴리스 노트 생성 (Release Notes Generation)

기능: 릴리스 머지(release merge) 후, 릴리스 브랜치의 커밋 메시지(commit messages), PR 제목(PR titles), PR 설명(PR descriptions)이 LLM으로 전송되어 일관된 형식의 구조화된 릴리스 노트를 생성합니다.

제거되는 노고: 릴리스 노트를 작성하는 작업은 모든 팀원이 지쳐 있고 다음 스프린트에 집중하고 있는 스프린트 종료 시점에 발생합니다. 출력물의 품질은 마감 기한에 가까워질수록 반비례하여 떨어집니다. 팀마다 노트의 형식이 일관되지 않으며, 중요한 변경 사항은 묻히고 사소한 변경 사항은 과장되기도 합니다.

구조화된 커밋 데이터로부터 릴리스 노트를 생성하는 LLM은 일관된 결과물을 만들어내며, 변경 사항을 기능(features), 수정(fixes), 중대한 변경(breaking changes), 인프라(infrastructure) 등으로 정확하게 분류하고 이해관계자에게 전달할 커뮤니케이션 초안을 작성합니다.

중요한 주의 사항: LLM(Large Language Model)이 생성한 릴리스 노트(release notes)는 게시하기 전에 반드시 사람의 검토를 거쳐야 합니다. 모델은 제품 관점에서 어떤 변경 사항이 중요한지 알 수 없으며, 단지 커밋(commit)이 설명하는 내용을 분류하고 요약할 수 있을 뿐입니다. 가치는 판단(judgment)을 제거하는 것이 아니라, 초안 작성의 수고(toil)를 없애는 데 있습니다.

활용 사례 5: 인시던트 런북(Incident Runbook) 생성

작동 방식: 인시던트(incident) 발생 시, 엔지니어가 서비스 이름, 증상 및 환경을 제공합니다. LLM은 즉각적인 조치, 조사 단계, 에스컬레이션(escalation) 기준 및 롤백(rollback) 절차를 포함한 구조화된 런북을 생성합니다.

인시던트 종료 후가 아닌 인시던트 도중에 사용하는 이유: 인시던트 종료 후의 런북은 향후 발생할 인시던트를 위해 가치가 있습니다. 인시던트 도중에 LLM이 생성한 런북은 현재 발생한 인시던트에 유용합니다. 특히 온콜(on-call) 엔지니어가 직접 구축하지 않았거나 최근에 운영해 보지 않은 서비스와 관련된 인시던트의 경우 더욱 그렇습니다.

출력 결과는 권위적인 것이 아닙니다. 이는 압박감이 가장 높은 상황에서 조사를 구조화할 때 발생하는 인지 부하(cognitive load)를 줄여주는 시작점입니다. 생성된 런북을 검토하는 숙련된 엔지니어는 무엇이 관련이 있고 무엇이 관련이 없는지 즉시 식별할 것입니다. 그러한 판단에는 여전히 사람이 필요합니다.

작동하지 않는 것 — 솔직한 평가

비즈니스 컨텍스트(business context)는 LLM에게 보이지 않습니다. CI/CD에서의 모든 LLM 통합은 코드(diffs), 로그(logs), 계획(plans)과 같은 아티팩트(artifacts)를 기반으로 작동하며, 왜 코드가 이렇게 작성되었는지, 제품이 무엇을 요구하는지, 또는 인접 시스템에 어떤 기술 부채(technical debt)가 존재하는지는 이해하지 못합니다. 이러한 컨텍스트를 필요로 하는 활용 사례는 프롬프트(prompt) 품질에 관계없이 낮은 품질의 결과물을 생성할 것입니다.

알람 피로(Alert fatigue)는 실제적인 실패 모드입니다. 신호 대 잡음비(signal-to-noise ratio)가 불충분한 상태에서 너무 많은 결과물을 만들어내는 AI 리뷰는 무시될 것입니다. 무시되는 자동화된 출력은 자동화된 출력이 없는 것보다 더 나쁩니다. 이는 엔지니어가 해당 소스로부터 오는 신호(향후 중요한 신호를 포함하여)를 무시하도록 길들여지기 때문입니다. 재현율(recall)보다 정밀도(precision)를 극대화하기 위한 프롬프트 엔지니어링(prompt engineering)이 필수적입니다.

규모가 커질수록 비용은 복리로 증가합니다. MR(Merge Request)이 월 100개 이상이고 각 MR마다 여러 파일이 포함된다면, 모델 선택에 따른 토큰 경제성(token economics)은 매우 중요해집니다. 각 사용 사례(use case)에 대해 수용 가능한 출력 품질을 생성하면서도 가장 비용 효율적인 모델을 벤치마킹하는 것은 프로덕션 배포 전에 수행할 가치가 있는 엔지니어링 작업입니다.

보안에는 세심한 아키텍처(architecture)가 필요합니다. 코드 차이(code diffs), 인프라 계획(infrastructure plans), 그리고 파이프라인 로그(pipeline logs)에는 부분적으로 마스킹된 비밀번호(secrets), 내부 호스트 이름(internal hostnames), 서비스 계정 이름(service account names)과 같은 민감한 정보가 포함될 수 있습니다. 이러한 정보를 외부 API로 전송하려면 명시적인 데이터 분류(data classification)와 정책 결정이 필요합니다. 엄격한 데이터 거주성(data residency) 요구 사항이 있는 조직의 경우, 자체 호스팅 모델 배포(self-hosted model deployment)가 필요할 수 있습니다.

프롬프트 관리(prompt management)는 지속적인 작업입니다. Python/Django 코드베이스에서 잘 작동하는 프롬프트는 Go 마이크로서비스(microservices) 아키텍처에 맞춰 조정이 필요합니다. 엔지니어 10명 규모의 스타트업에서 좋은 결과를 내는 프롬프트는 100명 규모의 팀을 위해 튜닝(tuning)이 필요합니다. 프롬프트를 한 번 작성하면 끝나는 정적 설정(static configuration)으로 취급하는 것은 실수입니다. 프롬프트는 다른 시스템 구성 요소와 마찬가지로 동일한 반복(iteration) 규율이 필요합니다.

효과적인 아키텍처 패턴 (Architecture Patterns That Work)

파이프라인 내 통합 시점: 코드 리뷰(code review) 및 인프라 계획 검토에는 프리 머지(Pre-merge) 단계가 적합합니다. 이슈가 반영되기 전에 문제를 포착하는 데 가치가 있기 때문입니다. 릴리스 노트(release notes) 생성에는 포스트 머지(Post-merge) 단계가 적합합니다. 완전한 머지 컨텍스트(merge context)가 필요하기 때문입니다. 파이프라인 진단(pipeline diagnosis)에는 실패 시 트리거(Triggered on failure) 방식이 적합합니다. 실제 실패 출력값(failure output)이 필요하기 때문입니다.

실패 처리(Failure handling): 모든 LLM 통합 지점은 기본적으로 비차단(non-blocking) 방식이어야 합니다. GitLab CI의 allow_failure: true나 Jenkins의 post { failure }와 같은 방식입니다. 외부 API의 가용성(availability)이 배포를 막아서는 안 됩니다.

코드로서의 프롬프트 관리(Prompt management as code): 프롬프트를 사용하는 파이프라인 코드와 함께 버전 관리되는 파일에 저장하십시오. 프롬프트의 변경 사항은 파이프라인 로직의 변경 사항과 동일한 리뷰 프로세스를 거쳐야 합니다. 이를 통해 프롬프트 변경으로 인해 출력 품질이 저하될 경우 롤백(rollback)이 가능하며 감사 추적(audit trail)을 제공할 수 있습니다.

사용 사례별 모델 선택(Model selection by use case):

사용 사례 (Use Case)	권장 모델 유형 (Recommended Model Type)	이유 (Reasoning)
코드 리뷰 (대량 처리) (Code review (high volume))	높은 처리량에 최적화된 모델 (High-throughput optimized)	처리량이 많아 비용이 중요해짐
...

향후 발전 방향 (Where This Is Heading)

위에서 설명한 사용 사례들은 공통된 특징을 공유합니다. 바로 LLM이 텍스트를 생성하면 사람이 이를 검토하고 조치를 취한다는 점입니다. 이미 진행 중인 다음 단계의 진화는 LLM이 직접 행동을 취하는 방향으로 나아가고 있습니다. 즉, 실패한 테스트를 식별하고, 수정 사항을 생성하며, PR(Pull Request)을 생성하고, 머지(merge) 전 사람의 승인을 요청하는 방식입니다.

이러한 에이전트 패턴(agentic pattern)은 리스크 프로필(risk profile)을 크게 변화시킵니다. 사람이 무시할 수 있는 댓글을 작성하는 LLM은 영향 범위(blast radius)가 제한적입니다. 하지만 PR을 생성하고 인프라를 수정하는 LLM은 세심한 가드레일(guardrails), 승인 워크플로(approval workflows), 그리고 명시적인 범위 제한(scope limitation)을 필요로 합니다.