우리가 어떻게 AI를 사용하여 여러 저장소(Repository)에 걸쳐 CI를 더 엄격하고, 관찰 가능하며, 개선하기 쉽게 만들었는지에 대하여.

구현(Implementation)과 전달(Delivery) 양쪽 분야에서 모두 일해본 경험을 통해, 저는 현재의 AI 시대에 복잡한 요구사항이 반드시 가장 큰 문제는 아니라는 점을 배웠습니다.

AI는 우리가 요구사항을 세분화하고, 생소한 저장소(Repository)를 탐색하며, 구현 아이디어를 생성하는 것을 도울 수 있습니다. 이는 구현 단계를 훨씬 더 쉽게 만듭니다.

하지만 구현은 전달의 한 부분일 뿐입니다. 기능(Feature)은 여전히 실제 엔지니어링 시스템을 거쳐야 합니다.

그 기능은 그것을 전달하는 저장소(Repository), CI 규칙, 리뷰 프로세스(Review process), 그리고 배포 경로(Deployment path)에 부합해야 합니다.

구현이 빨라짐에 따라, 이를 둘러싼 엔지니어링 시스템이 더욱 중요해지고 있습니다. 진짜 과제는 모든 변경 사항이 테스트되고, 요구사항에 따라 리뷰되며, 머지(Merge)하기에 안전한지 확인하는 것입니다.

대체에 대한 두려움을 넘어

AI가 개발자를 대체할 것이라는 두려움이 많습니다.

그러한 우려 중 일부는 타당합니다. 일상적인 구현 작업이 AI의 도움으로 생성, 테스트 및 리뷰될 수 있게 되면, 주니어(Entry-level) 단계의 기회는 더 제한적일 수 있습니다.

이는 특히 소프트웨어 개발에서 첫 기회를 얻으려는 사람들에게 중요한 도전 과제입니다.

하지만 저는 이것을 개발자 역할의 종말로 보지 않습니다.

저는 이를 소프트웨어 분야에서 일하기에 가장 흥미로운 시기 중 하나라고 생각합니다.

가치가 이동하고 있습니다.

일상적인 코드를 작성하는 것은 차별화 요소가 되어가고 있습니다. 문제를 이해하고, 올바른 질문을 던지며, 동작을 검증하고, 트레이드오프(Trade-off)를 결정하며, 결과에 대해 책임을 지는 것이 더욱 중요해지고 있습니다.

AI는 구현(Implementation)을 만들어낼 수 있지만, 비즈니스 맥락(Business context), 숨겨진 제약 조건(Hidden constraint), 운영 리스크(Operational risk), 또는 해당 솔루션이 팀에 적절한지 여부를 자동으로 이해하지는 못합니다.

이것이 바로 워크플로(Workflow) 품질이 중요한 이유입니다.

가장 큰 혜택을 보는 개발자는 반드시 AI에게 가장 많은 코드를 생성하도록 요청하는 사람들이 아닙니다. 그들은 규율 있는 프로세스(disciplined process) 안에서 AI를 사용할 수 있는 사람들입니다. 즉, 요구사항을 정의하고, 증거를 검사하며, 결과를 테스트하고, 리스크를 검토하며, 그 주변의 시스템을 개선하는 사람들입니다.

주니어 개발자들에게 그 경로는 변할 수 있지만, 사라지지는 않습니다. 기본기(Fundamentals), 디버깅(debugging), 커뮤니케이션(communication), 제품 이해도(product understanding), 그리고 AI와 효과적으로 협업하는 능력이 훨씬 더 중요해질 것입니다.

이러한 관점의 변화는 우리가 CI(지속적 통합, Continuous Integration)에 접근하는 방식을 바꾸어 놓았습니다. 우리는 CI를 어떻게 더 빠르게 실행할지부터 시작하지 않았습니다. 대신, 어떻게 하면 올바른 문제들을 더 많이 잡아낼 수 있을지를 물었습니다.

진짜 작업은 CI 워크플로(Workflow)를 강화하는 것이었습니다

최근에 우리는 다음과 같은 여러 책임을 가진 GitLab CI 워크플로(Workflow) 작업을 진행했습니다.

• 머지 리퀘스트(merge request)가 생성될 때 연결된 이슈(issue)를 Status::In Review로 이동
• 머지(merge) 후에 이슈를 Status::Done으로 이동
• 전체 머지 리퀘스트(merge request)에 대해 AI 리뷰(AI review) 실행
• AI 리뷰가 치명적이거나 높은 심각도의 결함을 확인하면 파이프라인(pipeline) 차단
• 머지 리퀘스트(merge request)에 종료 참조(closing reference)가 포함되지 않은 경우 댓글 남기기

중요한 부분은 단순히 더 많은 CI 잡(job)을 추가하는 것이 아니었습니다.

우리는 AI를 사용하여 워크플로(Workflow) 자체를 검사하고 더 나은 질문을 던졌습니다.

• Status::In Review가 머지 리퀘스트(merge request)가 실제로 티켓(ticket)과 연결되어 있음을 증명하는가?
• Status::Done이 기본 브랜치(default branch)로의 실제 머지(merge) 후에만 실행되는가?
• AI가 찾아낸 결과가 구체적인 증거 없이 머지를 차단할 수 있는가?
• 머지 리퀘스트(merge request)에 종료 참조(closing reference)가 누락되면 어떤 일이 발생하는가?
• 어떤 체크(check)가 일반적인 정책(generic policy)이고, 어떤 체크가 특정 리포지토리(repository)에 속하는가?

이러한 질문들은 CI를 단순한 명령어의 집합에서 품질 관리 시스템(quality control system)으로 변화시켰습니다.

목표는 CI를 더 복잡하게 만드는 것이 아니었습니다. 무엇이 자동으로 체크되는지, 어떤 증거가 필요한지, 그리고 무엇이 머지(merge)를 차단해야 하는지 등 각 결정을 더 명시적으로 만드는 것이었습니다.

AI가 파이프라인(Pipeline)에서 실제로 사용되는 방식

AI 리뷰는 개발자가 수동으로 실행해야 하는 별도의 도구가 아닙니다. 이는 머지 리퀘스트 (Merge Request)가 기본 브랜치(default branch)를 대상으로 할 때 실행되는 GitLab CI 잡 (job)입니다.

설정은 네 가지 간단한 부분으로 구성됩니다:

1. 고정된(pinned) AI CLI가 CI 잡에 설치됩니다.
2. 작은 리포지토리 스크립트가 머지 리퀘스트 컨텍스트 (context)를 수집합니다.
3. AI가 구조화된 JSON 리포트 (report)를 반환합니다.
4. 별도의 잡이 해당 리포트를 평가하여 파이프라인 (pipeline) 통과 여부를 결정합니다.

이 잡은 최신 버전을 무작정 설치하는 대신, 고정된 버전의 AI CLI를 사용합니다:

ai_review:
  image: node:22-bookworm-slim
  before_script:
...

이 사례에서 AI는 OpenAI Codex CLI를 통해 접근됩니다. 정확한 CLI는 달라질 수 있지만, 중요한 점은 버전이 명시적이고 잡이 격리된 CI 환경에서 실행된다는 것입니다.

리포지토리 스크립트는 전체 리포지토리를 모델에 맹목적으로 보내지 않습니다. 리뷰에 필요한 컨텍스트 (context)만을 수집합니다:

• 머지 리퀘스트 설명;
• 연결된 종료 이슈 (closing issues) 및 해당 요구사항;
• 변경된 파일 및 디프 (diff);
• 변경 사항 주변의 관련 파일 내용;
• 현재 커밋 SHA 및 대상 브랜치.

프롬프트 (prompt)는 또한 AI가 어떤 결론을 내릴 수 있는지 정의합니다. 예를 들어, 요구사항은 Covered (충족), Partial (부분적), Missing (누락), 또는 Not verifiable (검증 불가)로 표시됩니다. 발견 사항에는 카테고리, 심각도 (severity), 영향을 받는 경로, 증거, 영향 및 권장 사항이 반드시 포함되어야 합니다.

응답은 사용되기 전에 JSON 스키마 (schema)를 통해 검증됩니다. 그런 다음 리포트는 CI 아티팩트 (artifact)로 저장되고 머지 리퀘스트 코멘트 (comment)로 게시됩니다. 이를 통해 추론 과정이 가시화되며 다음 잡에 안정적인 입력을 제공합니다.

자격 증명 (credentials)은 책임에 따라 분리됩니다:

• AI 액세스 토큰 (access token)은 리뷰 잡이 AI 도구를 호출할 수 있게 합니다.
• GitLab 자동화 토큰 (automation token)은 워크플로 (workflow)가 머지 리퀘스트 데이터를 읽고 코멘트나 라벨 (label)을 업데이트할 수 있게 합니다.

두 가지 모두 마스킹된 그룹 수준의 CI 변수 (CI variables)로 관리됩니다. 리뷰 작업 (review job)은 AI 토큰을 사용합니다. 게이트 작업 (gate job)은 AI를 호출할 필요가 없으므로, 리포트 아티팩트 (report artifact)를 소비하고 환경에서 AI 토큰을 제거합니다.

이러한 분리는 두 가지 이유로 유용합니다. 민감한 자격 증명 (credentials)이 노출되는 위치를 제한하며, 최종 게이트가 검토된 리포트와 결과가 달라질 수 있는 또 다른 AI 요청을 생성하는 것을 방지합니다.

실제로 흐름은 다음과 같습니다:

머지 리퀘스트 (Merge request)
    -> GitLab 컨텍스트 (context) 수집
    -> 구조화된 출력 (structured output)을 통한 AI 리뷰
...

따라서 AI는 분석과 설명에 사용됩니다. GitLab CI는 출력값 검증, 커밋 확인, 머지 리퀘스트 업데이트, 그리고 최종 정책 강제 적용의 책임을 유지합니다.

리포지토리가 아닌, 개선된 워크플로를 패키징하세요

공유 컴포넌트 (shared component)는 유용한 결과물이었지만, 그것이 주요 개선 사항은 아니었습니다. 핵심적인 개선 사항은 CI 정책을 명시적이고 강제 가능하게 만든 것이었습니다. 그것이 명확해진 후에야 재사용 가능한 부분들을 패키징할 수 있었습니다.

워크플로를 개선한 후, 다음 질문은 간단했습니다:

모든 리포지토리에 동일한 워크플로를 매번 수동으로 설정해야 할까요?

대답은 여전히 '아니오'였습니다.

개선된 .gitlab-ci.yml 로직을 모든 리포지토리에 복사하는 대신, 우리는 공유 GitLab CI 컴포넌트를 만들었습니다.

사용하는 리포지토리는 공유 템플릿을 포함하기만 하면 됩니다:

include:
  - project: your-group/ci-components
    ref: v0.1.0
...

공유 컴포넌트는 다음을 제공합니다:

• issue_status_in_review
• issue_status_done
• ai_review
• ai_review_gate

리포지토리는 여전히 자체적인 빌드 (build), 린트 (lint), 유닛 테스트 (unit test), E2E, 그리고 배포 (deployment) 작업을 소유합니다.

이러한 분리는 중요합니다.

Go 리포지토리가 Python 리포지토리 구조를 강제로 사용할 필요는 없습니다. 프론트엔드 (frontend) 리포지토리가 백엔드 (backend) 테스트 명령어를 상속받을 필요도 없습니다.

하지만 두 리포지토리 모두 동일한 머지 리퀘스트 정책이 필요할 수 있습니다.

재사용 가능한 부분은 파이프라인 (pipeline)의 모든 명령어가 아니라, 품질 정책 (quality policy)입니다.

AI 리뷰에는 결정론적 경계 (Deterministic Boundary)가 필요합니다

AI 리뷰는 유용하지만, AI의 응답이 머지 요청 (merge request)의 병합 여부를 직접 결정해서는 안 됩니다.

AI 리뷰어는 구조화된 보고서 (structured report)를 생성합니다. 이는 티켓 커버리지 (ticket coverage), 정확성 (correctness), 회귀 위험 (regression risk), 보안 (security), 성능 (performance), 유지보수성 (maintainability) 및 기타 카테고리를 평가합니다.

그 후 'Critical' 및 'High' 등급의 발견 사항 (findings)은 독립적으로 검증됩니다.

최종 게이트 (final gate)는 다음과 같은 결정론적 조건 (deterministic conditions)을 확인합니다:

• 보고서가 현재 커밋 (commit)에 대한 것인가?
• 발견 사항이 독립적으로 확인되었는가?
• 심각도 (severity)가 여전히 차단 (blocking) 상태인가?
• 보고서 생성 후 사람의 재량권 행사 (human override)가 추가되었는가?

이를 통해 우리는 더 나은 경계를 가질 수 있습니다.

AI는 방대한 머지 요청 (merge request)에 대해 추론 (reasoning)하는 데 유용합니다.

파이프라인 (pipeline)은 정책 (policy)을 강제하는 책임을 집니다.

AI의 출력은 확률적 (probabilistic)인 반면, 머지 게이트 (merge gate)는 예측 가능 (predictable)해야 하므로 이러한 구분은 매우 중요합니다.

워크플로 (Workflow)를 재사용 가능하고 안전하게 만들기

워크플로의 품질은 AI 단계만으로 완성되지 않습니다. 자동화가 예측 가능하고 재사용하기 안전하도록 만들어야 합니다.

누락된 종료 참조 (closing references) 가시화

머지 요청 (merge request)에 Closes #123과 같은 참조가 포함되어 있지 않으면, 파이프라인 (pipeline)이 무엇이 누락되었는지 설명하는 댓글을 자동으로 남깁니다.

또한 작업 (job)이 실패하므로 머지 전에 문제를 확인할 수 있습니다. 설명이 업데이트된 후 파이프라인을 다시 실행 (retry)할 수 있습니다.

공유 컴포넌트 고정 (Pinning)

각 저장소 (repository)는 최신 변경 사항을 묵시적으로 따르는 대신, v0.1.0과 같이 특정 컴포넌트 버전 (component version)을 사용합니다.

이는 공유 CI (CI)의 업데이트가 모든 저장소에 예기치 않은 변경을 일으키지 않음을 의미합니다. 저장소는 변경 사항이 검토된 후에 버전을 업데이트할 수 있습니다.

자동화를 위한 전용 봇 (bot) 사용

워크플로 (workflow)에는 이슈 라벨 (issue labels)과 댓글을 업데이트하기 위한 자격 증명 (credentials)이 필요합니다. 이러한 자격 증명은 개발자의 개인 계정이 아닌, 그룹 수준에서 관리되는 전용 CI 봇 (CI bot)에 귀속되어 저장됩니다.

이는 소유권을 팀에 유지시키며, 인력이나 책임 소재가 변경될 때 자동화(automation)를 더 쉽게 유지 관리할 수 있게 해줍니다.

저장소별 체크(checks)를 로컬로 유지하기

공유 컴포넌트(shared component)는 공통적인 머지 리퀘스트(merge request) 정책을 처리합니다. 각 저장소(repository)는 여전히 자체적인 빌드(build), 린트(lint), 단위 테스트(unit test), E2E, 그리고 배포(deployment) 작업을 정의합니다.

레이블(Labels) 또한 저장소별로 설정할 수 있습니다. Go 프로젝트와 TypeScript 프로젝트가 동일한 리뷰 정책을 공유한다고 해서 반드시 동일한 명령어를 사용할 필요는 없습니다.

그 결과, 모든 저장소가 동일한 구조를 가진 것처럼 가장하지 않으면서도 공통된 품질 기준(quality bar)을 확보할 수 있습니다.

엔지니어링 리더십(Engineering Leadership)에는 어떤 변화가 생기는가?

AI는 병목 현상(bottleneck)을 변화시킵니다.

이전에는 업무의 상당 부분이 요구사항을 코드로 번역하고, CI 워크플로(workflow)가 의도된 정책을 제대로 포착했는지 수동으로 확인하는 것이었습니다.

이제 AI는 그러한 구현 과정의 마찰(friction)을 크게 줄여줄 수 있습니다.

엔지니어링 리더십의 역할은 다음과 같은 부분에 더 집중하게 됩니다:

• 재사용 가능한 경계(reusable boundaries) 정의
• 어떤 체크(checks)가 결정론적(deterministic)으로 유지되어야 하는지 결정
• 반복되는 정책을 자동화(automation)로 전환
• AI 출력물을 검증 가능(verifiable)하게 만들기
• 저장소 간의 유연성 유지
• 속도가 프로세스에서 증거(evidence)를 제거하지 않도록 보장

업무는 여전히 복잡합니다.

하지만 그 복잡성은 더 작고 재사용 가능한 시스템으로 조직화될 수 있습니다.

최종 요약 (Final Takeaways)

복잡한 요구사항에는 여전히 신중한 사고가 필요합니다.

AI가 아키텍처(architecture), 테스트(testing), 또는 리뷰(review)의 필요성을 없애지는 않습니다.

하지만 무엇이 실용적인지(practical)를 변화시킵니다.

수동 검사에 의존하던 리뷰 프로세스는 자동화되고 증거에 기반한 게이트(gate)가 될 수 있습니다.

일단 품질 정책이 명확해지면, 반복되는 CI 로직은 버전 관리되는 공유 컴포넌트(shared component)가 될 수 있습니다.

가장 큰 개선은 단순히 코드를 더 빨리 작성하는 것이 아닙니다.

복잡한 업무를 더 쉽게 조정(coordinate), 검증(verify), 그리고 재사용(reuse)할 수 있는 시스템을 만드는 것입니다.

그것이 바로 AI가 엔지니어링 팀에게 가장 큰 레버리지(leverage)를 제공하는 지점입니다.