Codex와 GitLab으로 버그 수정 (새 탭에서 열림)

Codex는 터미널에서 코드를 분석하고 수정·테스트하는 데 강력하지만, 실제 배포에는 이슈 관리, 머지 리퀘스트, CI/CD, 코드 리뷰와 승인 과정이 필요하다. 글은 GitLab과 Codex를 연계해 Rust WebSocket 버그를 수정하고, GitLab MCP로 이슈와 개발 맥락을 반영하며, GitLab Duo Agent Platform의 외부 에이전트로 리뷰 피드백까지 처리하는 흐름을 소개한다. 핵심 결론은 코딩 에이전트의 빠른 구현 능력과 GitLab의 소프트웨어 생명주기 관리 기능을 결합해야 코드 작성부터 운영 배포까지 연결할 수 있다는 것이다.

Codex와 GitLab을 결합하는 전체 워크플로

• Codex는 저장소 안에서 코드를 읽고, 수정안을 만들고, 명령을 실행하고, 테스트까지 수행한다.
• 그러나 코드 작성만으로는 소프트웨어가 배포되지 않는다.
  • GitLab 이슈
  • 머지 리퀘스트
  • CI/CD 파이프라인
  • 보안 스캔
  • 코드 리뷰
  • 최종 사람의 승인 등이 필요하다.
• 글에서는 Tanuki IoT Platform 프로젝트의 Rust metrics backend를 대상으로 세 가지 활용 사례를 제시한다.
  • 로컬 Codex로 Rust WebSocket 버그 수정
  • GitLab MCP로 이슈 요구사항과 개발 맥락을 Codex에 제공
  • GitLab Duo Agent Platform에서 Codex를 외부 에이전트로 사용해 MR 리뷰 피드백 처리

실습 환경과 프로젝트 구조

• 필요한 환경:
  • 터미널에서 실행 가능한 Codex
  • 이슈가 포함된 GitLab 프로젝트
  • 선택적으로 GitLab MCP 서버와 GitLab Duo Agent Platform
  • Rust 컴파일러와 Cargo
• 프로젝트를 GitLab에 가져온 뒤 로컬에 clone하고 저장소 루트에서 codex를 실행한다.
• 주요 대상은 backend/ 아래의 Rust metrics store다.
  • 센서는 REST API로 측정값을 전송한다.
  • 대시보드는 WebSocket 스트림으로 실시간 데이터를 받는다.
• AGENTS.md를 통해 Codex에 Rust 도구 체인, 빌드 명령, 테스트 방법, 코드 품질 기준을 알려줄 수 있다.

WebSocket 메트릭 필터 버그 재현

• 백엔드는 REST API에서는 메트릭 필터링을 지원하지만, WebSocket 스트림에서는 필터가 제대로 적용되지 않는 문제가 있었다.
• 서버 실행:

PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml

• 특정 센서와 메트릭을 구독:

websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius'

• 같은 센서에 서로 다른 메트릭을 전송한다.

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}'

curl -s -X POST http://localhost:9090/api/metrics \
  -H 'Content-Type: application/json' \
  -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}'

• 기대 결과는 temperature_celsius만 수신하는 것이다.
• 실제로는 humidity_percent도 스트림에 나타나므로, /ws가 metric 쿼리 파라미터를 무시하고 있음을 확인할 수 있다.

로컬 Codex를 이용한 버그 수정

• Codex에 다음과 같이 작업을 요청한다.

I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric.

• Codex는 저장소와 AGENTS.md를 분석해 다음 작업을 수행한다.
  • /ws 핸들러의 기존 sensor 필터 로직 조사
  • 선택적 metric 쿼리 파라미터 지원 추가
  • 센서와 메트릭 조합에 따른 필터링 구현
  • 관련 테스트 추가
  • README.md와 AGENTS.md 등 문서 갱신
• 변경 후 포맷팅, 테스트, 빌드를 실행하고 최종 diff를 검토한다.
• 이후 Codex에 브랜치 생성, 커밋, 원격 저장소 push를 맡길 수 있다.

GitLab 머지 리퀘스트와 CI/CD 검증

• 코드가 MR에 올라가면 GitLab이 이후 생명주기를 담당한다.
• 파이프라인에서 다음 검증이 수행된다.
  • 빌드와 테스트
  • 보안 스캔
  • Rust 코드 스타일 및 품질 검사
  • GitLab Duo Code Review
• 배포 후에는 동일한 로컬 테스트를 다시 실행해 sensor와 metric을 모두 지정했을 때 요청한 메트릭만 전달되는지 확인한다.
• 검증 결과와 로컬 테스트 내용을 MR에 댓글로 남겨 리뷰 맥락을 공유한다.

GitLab MCP로 이슈와 요구사항 연결

• 로컬 저장소만 보는 Codex는 GitLab에 있는 다음 정보를 알 수 없다.
  • 버그 이슈의 상세 내용
  • 합의된 기능·비기능 요구사항
  • 구현 메모
  • 관련 MR 상태
  • 파이프라인 상태
• GitLab MCP 서버를 연결하면 Codex가 이슈를 직접 조회할 수 있다.
• 이슈에는 다음과 같은 내용이 포함될 수 있다.
  • 문제 재현 방법
  • 기능 요구사항
  • 비기능 요구사항
  • 필요한 테스트
  • README.md, AGENTS.md 갱신 요구
  • 구현 방향에 대한 메모
• 따라서 사용자가 긴 요구사항을 프롬프트에 복사하지 않아도, Codex가 GitLab 이슈를 단일 기준 정보로 활용해 구현할 수 있다.
• 이는 단순히 코드를 고치는 것보다 프로젝트의 합의된 요구사항과 개발 프로세스에 맞춘 변경을 가능하게 한다.

실용적인 적용 권장 사항

• Codex에는 작업 범위와 기대 동작을 명확히 요청하고, AGENTS.md에 빌드·테스트·스타일 규칙을 기록하는 것이 좋다.
• 코드 수정 전에는 실제 API와 WebSocket 동작을 명령줄에서 재현해 버그를 객관적으로 확인한다.
• GitLab MCP를 사용해 이슈를 직접 참조하게 하면 요구사항 누락을 줄일 수 있다.
• Codex가 작성한 코드는 GitLab MR, CI/CD, 보안 스캔, 사람의 리뷰를 거친 뒤 배포해야 한다.