자가 유지보수 소프트웨어: Ramp가 모니터링과 버그 수정을 AI 에이전트에 맡긴 방법

핵심 메시지

• AI가 코드 작성을 떠맡자 병목은 코딩이 아니라 유지보수와 관측(observability)으로 옮겨갔다.
• 매일 밤 크론으로 도는 백그라운드 코딩 에이전트가 보안 점검과 회귀 테스트를 돌리고, 찾은 버그마다 수정 PR을 자동으로 올리게 했다.
• 에이전트가 샌드박스 안에서 실제로 돌아가는 코드에 요청을 보내 버그를 재현하게 하니, 잡음이 줄고 수정의 신뢰도가 올라갔다.
• 야간 자동화는 매일 상태 없이 처음부터 시작하는 탓에 같은 경로만 반복 점검해 성과가 줄었고, 이를 모니터라는 추상화로 풀었다.
• AI를 붙여도 잡음이 많은 알림은 결국 무시당한다. 사람에게 도달하는 알림은 반드시 진짜 문제여야 한다는 것이 최대 교훈이다.

쉽게 이해하기

Ramp Labs의 엔지니어 알렉스 레빈슨은 최근 몇 달 동안 코딩을 거의 AI에 맡겼다고 말한다. 그러자 그의 하루는 대시보드를 들여다보며 '내 코딩 에이전트를 어디로 보내야 하나'를 찾는 시간으로 채워졌다. 병목이 코드를 쓰는 일에서 코드를 유지하고 관측하는 일로 옮겨간 것이다.

실험의 토대는 사내에서 만든 백그라운드 코딩 에이전트다. 이 에이전트는 대상 저장소를 샌드박스 안에서 실제로 빌드해 실행한다. 정적 파일만 읽어서는 보이지 않는 미묘한 동작까지 살아 있는 코드를 두드려 확인할 수 있고, 세션을 원하는 만큼 띄울 수 있으며, 사내 도구 연동이 이미 끝나 있어 도구 세팅에 시간을 쓰지 않아도 된다.

첫 시도는 단순했다. 매일 밤 크론으로 세션을 띄워 정해진 프롬프트를 주고 보안 점검, 핵심 기능 정상 동작 확인, 최근 병합된 PR 스트레스 테스트, 숨어 있던 버그 탐색을 시켰다. '문제가 아니라 해결책과 함께 아침을 맞고 싶다'는 생각에서, 찾은 버그마다 수정 PR을 자동 생성하게 했다. 수정이 통과하려면 처음의 재현을 반드시 통과해야 한다는 조건도 걸었다.

효과는 있었지만 약점도 분명했다. 자동화가 상태를 갖지 않아 매일 밤 기본 동작으로 되돌아가고 같은 경로만 다시 확인했다. 게다가 운영 앱에서 쏟아지는 로그·지표·스팬의 양이 너무 많아, 명확한 예외 메시지가 없는 문제 — 특정 함수의 P90·P99 지연이나 두 지표의 상관관계로만 드러나는 문제 — 는 찾아내기 어려웠다.

해법은 모니터였다. 모니터 설명란은 클라우드에 남는 지속적인 저장소 역할을 하고, 모니터는 특정 이슈에 대해 만들어지므로 에이전트의 시야를 좁혀 준다. PR이 병합될 때마다 에이전트를 불러 새 코드에 대한 모니터를 세우게 하고, 모니터가 울리면 다시 에이전트를 불러 고치게 하는 구조다. 대신 처음 켜자마자 쓸모없는 알림이 쏟아져, 알림의 타당성을 먼저 평가해 잡음이면 모니터를 조정하거나 지우는 분류 단계를 넣어야 했다.

주요 인사이트

• 샌드박스에서 실제로 재현된 오류만 다루게 한 설계가 잡음 감소와 수정 품질 향상을 동시에 가져왔다. 재현을 통과해야만 수정으로 인정하니 '고쳤다고 주장하는 PR'이 걸러진다.
• 중복 알림은 모니터 설명란을 에이전트의 메모장처럼 쓰는 방식으로 해결했다. 수정 PR을 올린 에이전트가 그 사실을 설명란에 적어 두면, 다음 세션은 이미 수정이 올라갔음을 보고 조용히 종료한다.
• 발표자가 그리는 새 모니터링 패러다임은 코드베이스 전체에 균일하게 촘촘한 관측을 적용하고, 관측 체계가 코드와 함께 진화하도록 만드는 것이다. 기존 방식은 일부 핵심 구역만 계측되고 나머지는 사실상 감시되지 않는다.
• 실제 사례로, 특정 회사 직원들이 제품을 벤치마킹하려 접속하는 것을 막았는데 차단 구현이 허술해 다시 로그인에 성공한 일이 있었다. 알림과 함께 수정안이 곧바로 도착했고 병합으로 끝났다.
• 이 실험 전체가 기존 에이전트를 감싼 얇은 래퍼였다는 점이 핵심이다. 개별 에이전트는 이미 '상자 안의 소프트웨어 엔지니어'이고, 진짜 생산성은 세션들을 어떻게 엮고 맥락을 어떻게 연결하느냐에서 나온다.

자주 묻는 질문

관련 AI 소식