에이전트 코딩은 컨텍스트만큼만 훌륭하다 (새 탭에서 열림)

코딩 에이전트의 성능과 신뢰성은 코드 작성 능력보다 프로젝트 생명주기 전반의 맥락을 얼마나 활용하느냐에 달려 있다. 저장소만 보는 에이전트는 컴파일되는 코드를 만들 수 있지만, 이슈 요구사항·CI 규칙·보안 정책·리뷰 기준까지 반영하기 어렵다. GitLab처럼 이슈, 파이프라인, 보안 스캔, 머지 리퀘스트를 연결하면 에이전트가 조직의 가드레일 안에서 작업하고, 리뷰 라운드와 머지까지 걸리는 시간을 줄일 수 있다.

저장소만 보는 에이전트의 한계

• 에이전트는 로컬 파일과 사용자가 입력한 프롬프트를 기반으로 코드를 수정하고 빌드를 실행한다.
• 코드가 컴파일되더라도 다음 정보를 알지 못할 수 있다.
  • 이슈의 인수 조건과 구현 메모
  • 비기능 요구사항
  • CI 설정에 정의된 린터·테스트·품질 기준
  • 조직의 코드 리뷰 규칙과 보안 정책
• 결과적으로 “동작하는 코드”와 “팀이 실제로 요구한 변경” 사이에 차이가 생긴다.
• 이슈 링크 누락, 새로 추가된 린터 규칙 위반, 승인되지 않은 의존성 추가 같은 재작업이 발생할 수 있다.

GitLab 이슈를 연결했을 때의 변화

• GitLab MCP 서버를 연결하면 에이전트가 코딩 전에 관련 이슈를 조회할 수 있다.
• 이슈의 요구사항, 구현 메모, 라벨, 마일스톤을 확인해 계획에 맞는 수정이 가능해진다.
• 예를 들어 Codex는 머지 리퀘스트 설명에 Closes #32를 추가해 코드 변경과 이슈의 관계를 명시한다.
• Claude Code는 get_issue로 버그 리포트를 가져오고, create_merge_request로 적절한 참조가 포함된 MR을 생성한다.
• 즉, 에이전트의 작업이 단순한 코드 수정에서 프로젝트 계획과 연결된 변경으로 확장된다.

머지 리퀘스트 안에서 수행하는 리뷰와 수정

• MR이 생성되면 GitLab의 Code Review Flow가 자동으로 리뷰 피드백을 게시한다.
• 에이전트는 MR 내부의 외부 에이전트로 호출되어 다음과 같은 후속 작업을 수행할 수 있다.
  • 누락된 테스트 추가
  • 문서 주석 보완
  • 리뷰에서 발견된 검증 로직의 공백 수정
• 수정 사항은 MR 브랜치에 직접 커밋된다.
• 새 커밋마다 CI/CD 파이프라인이 자동 실행되므로, 에이전트의 수정 결과를 즉시 검증할 수 있다.
• 사람은 다른 도구로 전환하지 않고 MR에서 변경 내용과 파이프라인 결과를 검토한다.
• 이 흐름은 리뷰 반복 횟수와 머지까지 걸리는 시간을 줄이는 데 기여한다.

플랫폼 전체 맥락과 조직의 가드레일

• 플랫폼 팀은 조직 내 AI 개발 방식에 대해 다음을 결정한다.
  • 허용할 에이전트
  • 에이전트가 접근할 수 있는 도구와 데이터
  • 결과물을 검증하는 방법
  • 사람의 승인과 판단이 필요한 지점
• DevSecOps 플랫폼에는 에이전트가 필요로 하는 생명주기 정보가 모여 있다.
  • 이슈 트래커: 요구사항과 우선순위
  • CI/CD 설정: 품질 기준과 자동 검증
  • 코드 리뷰 지침: 스타일과 개발 표준
  • 보안 스캐너: 취약점 정책
  • MR: 자동화와 최종적인 사람의 승인
• IDE나 터미널 기반 에이전트가 아무리 뛰어나도 제공된 파일 중심으로만 판단한다.
• 반면 플랫폼은 이슈부터 파이프라인, 보안 정책, 배포 대상, 승인 규칙까지 전체 흐름을 볼 수 있다.
• 따라서 안전하게 배포되는 결과물은 에이전트 자체의 능력뿐 아니라 플랫폼이 제공하는 가시성과 통제에 좌우된다.

AI가 코드를 더 많이 만들 때의 보안 영향

• 코드 생성 속도가 빨라지면 새 취약점, 보안 스캔 결과, 수정용 MR도 함께 증가한다.
• 기존에는 보안팀이 취약점을 탐지·분류한 뒤 개발자에게 수정 요청을 보내고 기다리는 과정이 병목이었다.
• 에이전트가 수정까지 빠르게 수행하면 병목은 “무엇을 고칠까”에서 “어떤 AI 생성 수정 MR을 먼저 사람이 승인할까”로 이동한다.
• 우선순위를 정하려면 다음과 같은 전체 맥락이 필요하다.
  • 프로젝트 전체 코드
  • 데이터 흐름
  • 실제 배포 환경
  • 조직에 적용되는 보안 정책
• 이런 맥락이 있으면 단순한 심각도 점수가 아니라 실제 환경에서의 노출 가능성을 기준으로 취약점을 우선순위화할 수 있다.
• GitLab 보안 계층은 프로젝트 맥락을 활용해 오탐을 걸러내고 확인된 취약점을 식별한다.
• 확인된 취약점에 대해서는 agentic SAST vulnerability resolution이 취약 코드와 주변 코드를 분석해 수정 MR을 자동 생성한다.
• 이후 파이프라인이 수정 사항을 검증하고, 최종 머지 여부는 사람이 결정한다.
• 즉, 에이전트가 수정 작업을 담당하더라도 승인과 거버넌스는 사람에게 남는다.

AGENTS.md를 활용한 프로젝트별 지침

• 두 튜토리얼 모두 저장소에 AGENTS.md 파일을 두고 에이전트의 행동 지침으로 활용한다.
• 이 파일에는 다음과 같은 내용이 포함될 수 있다.
  • 프로젝트 구조
  • 실행해야 할 명령어
  • 코드 품질 기준
  • 수정해서는 안 되는 파일이나 영역
• Codex와 GitLab 튜토리얼에서는 Rust 에디션, 비동기 동시성 패턴, CI 이미지 고정 정책 등이 정의되어 있었다.
• 이를 통해 에이전트가 매번 프롬프트로 설명받지 않아도 프로젝트의 기술적 규칙과 변경 범위를 일관되게 준수할 수 있다.

플랫폼 팀은 에이전트를 단독 코딩 도구로 도입하기보다 이슈·AGENTS.md·CI/CD·보안 스캔·MR 리뷰를 연결한 workflow 안에 배치하는 것이 좋다. 에이전트가 더 많은 작업을 자동화할수록 자동 검증은 강화하고, 최종 승인과 책임은 사람에게 남겨야 한다.