이벤트 기반 MSA, AI가 고친 코드가 왜 배포 후에 터지는가

한줄 요약

AI가 이벤트 기반 MSA 코드를 빠르게 고칠수록, 검증되지 않은 계약 변경이 조용히 쌓인다.

이벤트 기반 MSA(마이크로서비스 아키텍처)에서 AI 코드 수정이 배포 후에 터지는 이유는 대부분 같다. AI는 현재 서비스 안에서 가장 자연스러운 답을 만들지만, 그 이벤트를 받아 처리하는 다른 서비스의 기대값까지는 보지 못한다. 외주 개발로 이 구조를 넘겨받았거나, 기존 시스템에 AI를 붙여 유지보수를 돌리고 있다면 이 맹점은 생각보다 빨리 비용으로 돌아온다.

느슨한 연결이 맥락을 없애는 게 아니라 흩어놓는다

MSA를 도입하는 이유는 분명하다. 서비스별로 책임을 나누고, 한쪽 장애가 전체로 번지지 않게 막는다. 이벤트 기반으로 설계하면 서비스끼리 직접 호출하지 않아도 되니 결합도는 더 낮아 보인다.

그런데 이 구조에서 의존성은 없어지는 게 아니라 형태가 바뀐다. 직접 호출 대신 이벤트 이름, 페이로드 구조, 컨슈머별 처리 규칙으로 옮겨간다. 코드에서 호출 관계가 안 보인다고 서비스들이 독립적으로 움직이는 건 아니다. 결제 서비스는 주문 이벤트에서 특정 필드를 읽고, 재고 서비스는 수량 값을 믿고 예약을 건다. 이 약속이 깨지면 이벤트는 도착해도 흐름은 멈춘다.

실무에서는 이 약속을 코드 밖에서 관리한다. 이벤트 스키마, 팀 컨벤션, 운영 대시보드, 별도 문서가 그 역할을 한다. 문제는 이 맥락이 여러 저장소와 도구에 흩어져 있다는 점이다.

AI가 만든 PR이 빠른 이유, 그리고 리뷰가 여전히 느린 이유

AI 에이전트는 지정된 저장소 안에서는 빠르게 움직인다. 조건문을 수정하고, 타입을 맞추고, 테스트를 붙인다. 단위 테스트가 통과하고 CI도 통과한다. PR은 빠르게 올라온다.

하지만 리뷰어는 여기서 멈출 수 없다. 이 이벤트를 어떤 서비스가 소비하는지, 수정된 필드를 기준으로 분기하는 컨슈머가 있는지, 실패 시 어느 큐로 빠지는지를 별도로 확인해야 한다. AI는 이 맥락을 별도로 받지 않으면 알 수 없다.

결국 수정 속도는 빨라졌지만, 그 변경이 안전한지 판단하는 시간은 줄지 않는다. AI가 줄여준 코드 작성 시간을 리뷰어가 이벤트 문서, 다른 저장소, 로그를 뒤지는 시간으로 채운다. 전체 개발 비용 관점에서는 이득이 없거나 오히려 늘어난다.

이벤트 수정은 기능 수정이 아니라 계약 변경이다

이게 핵심이다. 이벤트에서 필드 하나를 정리하거나 이름을 명확하게 바꾸는 건, 현재 서비스 안에서는 작은 수정이다. 하지만 그 필드를 기준으로 결제 상태를 만들거나 배송 가능 여부를 판단하는 서비스가 있다면 계약이 바뀐 것이다.

REST API에서는 호출 성공 여부가 즉시 피드백된다. 이벤트 기반에서는 다르다. 발행 로그에 성공이 찍혀도, 컨슈머가 기대하던 값이 없으면 처리 흐름은 조용히 멈춘다. 문제가 드러나는 건 발행자 쪽이 아니라 받는 쪽이다. 이 시차가 이벤트 기반 MSA에서 버그가 늦게 발견되는 구조적 이유다.

외주 개발이나 유지보수 대행으로 이 구조를 다루는 팀이라면, 이 특성을 미리 공유해두지 않으면 AI가 올린 PR이 스테이징에서는 통과해도 프로덕션에서 터지는 상황을 반복하게 된다.

---

AI에게 이벤트 흐름을 넘기지 않으면, 기준은 매번 사람이 만든다

AI 에이전트에게 이벤트 기반 MSA 작업을 맡길 때 더 긴 프롬프트가 답은 아니다. 필요한 건 이벤트 계약과 흐름을 AI가 참조할 수 있는 형태로 정리해두는 것이다.

구체적으로는 세 가지 질문에 답할 수 있어야 한다. 이 이벤트는 어디서 발행되고, 어느 서비스가 소비하는가. 페이로드에서 컨슈머가 의존하는 값은 무엇인가. 수정 후 무엇을 확인해야 완료로 볼 수 있는가.

이 기준이 문서든 스키마 명세든 팀 규칙이든 어딘가에 있으면, AI는 현재 저장소 안에서 가장 그럴듯한 수정이 아니라 팀이 정한 이벤트 계약 안에서 움직인다. 기준이 없으면 리뷰어가 매번 같은 질문을 반복한다. AI를 붙인 뒤에도 비용이 줄지 않는 이유가 여기 있다.

변경 전에는 발행자, 컨슈머, 페이로드 의존 값을 확인한다. 변경 후에는 주요 컨슈머가 같은 값을 정상적으로 읽는지, 실패 큐에 메시지가 쌓이지 않는지, 최종 상태가 기대한 대로 바뀌었는지 본다. 이 체크리스트를 팀 규칙이나 CI에 연결해두면, AI가 만든 변경도 배포 전에 한 번 더 걸러진다.