opensre — CI 실패 원인을 추적해 수정 PR까지 푸시하는 CLI 에이전트
무엇인가
OpenSRE는 CI 파이프라인이 실패한 순간에 개입하는 CLI 기반 소프트웨어 에이전트다. Tracer-Cloud가 공개한 Python 구현이며, 저장소 설명은 스스로를 'CI/CD 신뢰성을 위한 오픈소스 에이전트'로 규정한다. 기능 축은 크게 셋으로 갈린다. 저장소의 CI 신뢰성을 분석하는 진단, 실패한 체크를 PR 단위에서 고치는 수정, CI를 계속 초록으로 유지하는 상시 에이전트 운영이다. 분류상으로는 관측(observability) 도구와 코드 생성 에이전트의 경계에 놓인다. 로그·메트릭·트레이스를 모아 보여주는 데서 멈추지 않고, 원인을 추론한 뒤 저장소에 변경을 만들어 PR 브랜치로 밀어낸다는 점에서 관측 도구보다 한 단계 더 나아간다. 반대로 범용 코딩 어시스턴트처럼 편집기 안에서 코드 조각을 제안하는 도구도 아니다. 실행 환경은 터미널이고, 다루는 1차 입력은 실패한 CI 런 자체다.
어떻게 동작하나
CI가 빨간불이 되는 순간 시스템이 알려주는 것은 '무언가 실패했다'는 사실뿐이다. 왜 실패했는지, 어떻게 고쳐야 하는지는 알려주지 않는다. README는 이 간극을 도구의 존재 이유로 내세운다. 마감 압박 아래에서 팀은 재실행 버튼을 누르고 넘어가고, flaky 체크가 쌓이며, main 브랜치는 빨간 상태로 남고, 실제 조사는 시간이 남는 시니어 엔지니어의 몫으로 밀린다. 이 구조에서 조사 품질은 사람의 여유에 비례하고, 같은 실패가 반복되어도 지식이 축적되지 않는다. OpenSRE가 겨냥하는 것은 코드를 고치는 일 이전의 조사 단계다. 실패 로그를 읽고, 가설을 세우고, 검증하는 반복 작업을 에이전트의 도구 호출 루프로 옮긴다. 부수적으로 실패율, CI 불안정에 잃은 개발자 시간, main이 빨간 채로 유지된 기간 같은 비용 지표를 뽑아낸다. 조사가 자동화되면 재실행으로 시간을 버티는 관행 자체가 근거를 잃는다.
무엇과 다른가
동작은 여섯 단계로 정리된다. 첫 단계에서 실패한 체크와 CI 로그, 최근 커밋과 배포, 상관된 로그·메트릭·트레이스를 가져온다. 두 번째로 외부 LLM 호출 전에 민감 식별자를 마스킹한다(선택). 세 번째가 핵심으로, 연결된 시스템들을 가로지르며 가설을 세우고 도구 호출 루프 안에서 검증한다. 이때 CI 자체가 만든 실패와 코드가 만든 실패를 분리한다. 같은 빨간불이라도 원인이 다르면 처방이 달라지므로, 이 분리가 재실행으로는 얻을 수 없는 판단을 만들어낸다. 네 번째로 근거를 링크한 답변을 대화에 남긴다. 다섯 번째로 원인을 고친 변경을 PR 브랜치에 푸시해 사람이 리뷰하게 하거나, 다음 조치를 제안하고 선택적으로 복구 액션을 실행한다. 여섯 번째로 요약을 Slack, PagerDuty, Telegram에 게시한다. 사용자가 도구를 열지 않아도 결과가 도착하는 구조다.
어떻게 쓰나
구성은 CLI를 중심으로 여러 진입점이 같은 에이전트를 감싼다. 프로세스 진입점 지도는 main.py에서 시작한다. 서브커맨드 없이 opensre를 실행하면 계정을 검증한 뒤 REPL이 열리는데 TTY가 필요하다. 세션 제어용 슬래시 명령(/help, /status, /cost, /sessions, /resume, /compact, /new, /exit)과 통합 확인용(/integrations list, /integrations verify)이 있고, Ctrl+C는 세션 상태를 잃지 않고 진행 중인 턴만 취소한다. 헤드리스 CLI는 터미널·스크립트·CI 잡에서 한 턴을 비대화식으로 실행하며 stdin 프롬프트, JSON 출력, 도구 승인을 다룬다. Python API는 소스 체크아웃을 전제로 세션·대화·출력 싱크를 코드에서 제어한다. 배포 쪽에는 OpenSRE Cloud 관리형 게이트웨이, make build-gateway-image와 make deploy-gateway로 만드는 AMI+systemd 게이트웨이(Telegram 전용, Docker 미사용), Dockerfile을 쓰는 자체 호스팅 컨테이너 경로가 있다. 테스트는 tests/e2e에 클라우드 기반 시나리오의 종단 간 케이스로 두고, tests/README.md의 의미론적 카탈로그 명명으로 e2e와 유닛, 로컬과 클라우드 경계를 드러낸다.
전제와 한계
대체 경로와의 차이는 데이터가 어디로 가는지, 그리고 컨텍스트를 누가 모으는지에서 갈린다. 첫째, 사람이 로그를 열어보고 재실행하는 방식은 컨텍스트 수집을 전적으로 사람에게 맡긴다. OpenSRE는 로그·커밋·배포·메트릭 수집을 고정된 단계로 만들어 조사 품질의 편차를 줄이는 대신, 연결되지 않은 시스템의 정보는 볼 수 없다. 둘째, 호스티드 CI 관측 SaaS는 대시보드와 알림까지 제공하지만 수정은 여전히 사람 몫이다. OpenSRE는 자체 호스팅과 자기 모델을 전제로 데이터를 자기 인프라에 두는 대신, 모델 품질과 운영 비용을 사용자가 책임진다. 셋째, 범용 코딩 에이전트는 로컬 작업 트리를 중심으로 움직여 CI 러너에서만 나타나는 재현 조건과 환경 차이를 다루기 어렵다. OpenSRE는 실패한 런 자체를 입력으로 삼는다. 공통 트레이드오프는 자율성과 검토 비용이다. 변경은 PR 브랜치로 푸시되어 리뷰를 거치도록 설계되어 있고, README도 공개 알파 단계로 핵심 워크플로는 조기 탐색용이며 API와 통합이 바뀔 수 있다고 명시한다.
실무 진입은 두 가지 전제에서 출발한다. 코드 프로젝트가 열린 터미널과 Git 저장소다. 전체 워크플로 시연에는 Git 저장소가 권장되지만 필수는 터미널뿐이다. 설치 후 `opensre`를 실행하면 로그인과 첫 화면이 이어지고, 첫 실행에서 호스티드 모델이 활성화된다. 인스톨러는 `main`의 최신 빌드를 sudo 없이 가져온다. 설치 직후 `opensre`를 찾지 못하는 경우가 가장 흔한 실패 지점이므로, 인스톨러가 출력한 PATH 안내를 따르거나 새 터미널을 연다. 웹앱 기여자는 `opensre setup --dev`로 `http://localhost:3000`을 경유해 인증한다. 게이트웨이는 `make build-gateway-image` 다음 `make deploy-gateway` 순서로 만들며, Docker 없이 서버 이미지에 설치되어 새 서버가 그 이미지에서 시작한다. 컨테이너 경로에서는 저장소의 `Dockerfile`을 배포하고 `MODE`를 고른 뒤 `LLM_PROVIDER`와 해당 API 키를 설정한다. `DATABASE_URL`은 Slack Events API 복제본처럼 게이트웨이가 공유 Postgres 상태를 필요로 할 때만 붙인다. 여기서 `MODE`와 `LLM_PROVIDER`를 서로 다른 조합으로 두면 기동은 되어도 모델 호출이 실패하므로, 두 값은 한 쌍으로 맞춰 잡는다.
README에는 정식 릴리스 번호 체계가 없다. 대신 'Public Alpha'라는 단계 표기가 있고, 인스톨러가 `main`의 최신 빌드를 가져온다는 문장이 버전 정책을 대신한다. 즉 사용자가 고정할 수 있는 값은 배포 태그가 아니라 설치 시점이고, 같은 명령이 시점에 따라 다른 빌드를 놓을 수 있다. 설치 경로는 macOS·Linux와 Windows(PowerShell)로 나뉘며, 지원 플랫폼과 문제 해결은 Install locally 문서를 참조하도록 안내한다. README가 프로젝트를 활발히 개발 중이며 API와 통합이 바뀔 수 있다고 밝힌 점을 감안하면, 이 롤링 방식은 의도된 선택으로 읽힌다. 알파 단계에서 태그를 고정하면 버그 수정이 사용자에게 도달하는 속도가 느려지고 유지보수 부담이 커진다. 그 대가로 재현성은 사용자 몫이 된다. 같은 동작을 반복 관찰해야 하는 팀이라면 컨테이너 경로에서 이미지 다이제스트를 고정하는 편이 안전하다. 구버전 사용자를 위한 마이그레이션 절차나 별도 설치 경로는 README에 적혀 있지 않으며, 업그레이드는 사실상 인스톨러 재실행과 같다.
지원 범위는 README가 스스로 밝힌 알파 표기에서 먼저 갈린다. 핵심 워크플로는 조기 탐색에 쓸 수 있는 수준이고 완전히 안정적이지 않으며, API와 통합이 바뀔 수 있다. 대화형 셸은 TTY를 요구하고 계정이 활성이어야 열린다. 로그아웃 상태로 남는 것은 가능하지만 비활성 계정으로는 셸 자체가 뜨지 않는다. Python API는 소스 체크아웃을 전제로 하므로 설치본만으로는 쓸 수 없다. 민감 식별자 마스킹은 선택 단계이고 외부 LLM 호출 자체를 막지는 않는다. AMI+systemd 게이트웨이는 Telegram 전용이며 Docker를 쓰지 않는다. 자체 호스팅 컨테이너는 `MODE`와 `LLM_PROVIDER`, 제공자 API 키를 사용자가 준비해야 하고 모델 품질과 운영 비용도 사용자 책임이다. 관리형 경로를 택하면 조직 관리자가 웹앱에서 프로비저닝해야 한다. 수집 범위 역시 연결된 시스템으로 한정되므로, CI 로그와 메트릭·트레이스·알림 채널이 붙어 있지 않으면 추론에 쓸 근거도 없다.
선택 기준은 실패 원인 조사가 반복 업무인지, 데이터를 어디에 둘 수 있는지로 정리된다. CI 실패가 잦고 조사가 소수 시니어에게 몰리며 로그·메트릭·트레이스가 이미 한 곳에 연결되어 있다면, 도구 호출 루프가 그대로 값을 낸다. 반대로 실패가 드물거나 대부분 코드 리뷰 단계에서 잡힌다면 상시 에이전트를 붙일 이유가 적다. 외부 SaaS에 로그를 보낼 수 없고 모델도 직접 운영해야 한다는 조건이면 자체 호스팅과 자기 모델 전제가 맞고, 모델 운영을 맡기고 싶다면 관리형 게이트웨이 경로가 낫다. CI 러너에서만 재현되는 실패를 다루려면 런 자체를 입력으로 삼는 구조가 유리하고, 편집기 안에서 코드를 고치는 흐름이 중심이라면 범용 코딩 에이전트가 낫다. 사람 리뷰 없이 자동 머지까지 가는 파이프라인을 원한다면 기본형이 PR 브랜치 푸시라는 점이 걸린다. 안정적인 API가 필요한 프로덕션 자동화에는 알파 단계라는 조건이 붙는다.