에이전트에게 코딩을 맡기며 2개월간 겪은 시행착오와 루프 구축기

올봄에 에이전트에 완전히 올인했다. 배포 속도는 즉각적으로, 그리고 눈에 띄게 빨라졌다. 그러다 한 6주 정도 지났을 때 프로덕션에서 버그가 4번 터졌는데, 그중 3번은 우리가 알기도 전에 유저가 먼저 겪었고, 하나는 결제 경로에서 터졌다.

아무도 코드를 개판으로 짠 건 아니었다. 그게 이해하는 데 시간이 좀 걸렸다. 그 4번의 사고 전부 티켓에 적힌 대로 정확하게 구현은 됐는데, 정작 테스트가 커버하지 못하는 인접한 부분을 건드린 게 문제였다. 사람이 직접 코드를 짤 때는 자기가 뭘 건드렸는지 대충 알고 있었으니까 테스트 스위트도 그렇게 짜여 있었던 거지.

그러니까 문제는 생성 품질이 아니었다. 우리가 변경 사항을 만들어내는 속도만큼 그걸 검증할 방법을 만들어내지 못한 게 문제였다.

지금 우리가 돌리는 방식은 이렇다.

티켓이 기획 에이전트로 넘어가면 코드가 아니라 기획 파일이 나온다. 사람이 그 기획을 읽는다. 이 과정은 5분 걸리는데, 안 거치고는 못 배긴다. 우리도 해봤는데 안 되더라.

구현 에이전트는 그 기획에 맞춰서 자기 워크트리에서 작업을 한다.

QA 에이전트는 기획서에서 건드린다고 명시된 부분에 대한 여정을 짜고 PR 프리뷰에서 돌린다. 테스트가 통과해야만 머지가 가능하다. 이게 예전엔 없던 건데, 사실 이게 핵심이었다.

머지하고 나면 모니터링 에이전트가 프로덕션의 주요 흐름을 감시하다가 뭔가 이상하면 PR을 연다. 이건 무조건 사람이 승인한다. 예외는 없다. 에이전트가 지 맘대로 머지한 적은 단 한 번도 없고, 애초에 그럴 권한도 없다.

이 모든 건 coldtea에서 돌아간다. QA랑 모니터링이 터미널이랑 같은 곳에 있어서 굳이 대시보드 두 개를 더 띄워놓고 신경 쓸 필요가 없다는 게 장점이다. macOS 전용이라는 게 좀 뼈아픈 제약이긴 한데, 이것 때문에 기존 환경을 고집하던 팀원 한 명을 떠나보내기도 했다.

시스템이 자리 잡고 3주 동안의 수치를 뽑아봤다. PR 28개 머지했고, 프로덕션 버그는 2개 터졌다. 둘 다 유저가 발견하기 전에 모니터링 에이전트가 1시간 안에 잡아냈고, 내가 확인하기도 전에 수정 PR이 올라와 있었다. 6주 동안 버그 4개 터지고 그중 3개를 유저가 먼저 발견했던 예전이랑 비교하면 확실히 낫다.

이제 단점들을 말해볼 건데, 꽤 많다.

이게 돌아가는 이유는 수정 PR을 사람이 직접 승인하기 때문이다. 모니터링 에이전트가 알아서 머지하게 두는 순간, 뭐가 고장 났는지 지 멋대로 판단해서 프로덕션을 수정하는 기계를 만드는 꼴이다. 우리는 절대 그렇게 안 할 거고, 그렇게 하는 놈이 있다면 누구랑이라도 싸울 생각이다.

핵심 흐름인 인증, 결제, 내보내기 경로 같은 건 사람이 직접 짠 테스트를 유지했다. 에이전트가 짠 건 넓은 범위를 커버하고, 사람이 짠 건 커리어 걸린 중요한 부분을 커버하는 식이다. 기존 테스트 스위트 다 지우라고 하는 놈들은 다 사기꾼이다.

PR 28개에 버그 2개면 절대적인 수치로 봐도 좋은 건 아니다. 예전보다는 낫지만 0은 아니고, 이 시스템으로 0을 만들 수 있을 것 같지도 않다.

그리고 QA 에이전트가 아무 의미 없는 테스트만 짜지 않게 만드는 데 3주 정도 튜닝이 필요했다. 처음엔 죄다 "페이지 로드됨, 요소 존재함" 이런 것만 짜대서 쓸모가 없었다. 초반에는 누군가 계속 들여다봐야 한다.

봄의 나 자신에게 해주고 싶은 말은 이거다. 코딩 속도는 애초에 병목이 아니었고, 그걸 빠르게 한다고 해결될 문제가 아니었다. 진짜 필요했던 건 작업하는 곳에서 바로 검증이 이루어지는 환경이었다. 그래야 배포 속도랑 검증 강도를 두고 오후 내내 고민하는 짓을 안 하지.