자동화가 자동화를 부른 날

스스로 굴러가는 파이프라인을 꿈꿨다

이슈가 하나 올라오면 AI가 알아서 읽고, 뭐가 문제인지 분석하고, 코드를 고쳐서 커밋이랑 PR까지 만들어준다. 이 그림을 GitHub Actions 위에 얹어서 돌린 게 저예요. 이름도 거창하게 claude-pipeline이라고 붙였고요.

설계 아이디어 자체는 나름 그럴듯했거든요. "먼저 분석을 요청하고, 그 분석 결과를 근거로 개선하라." 사람이 일하는 순서 그대로잖아요.

문제 파악하고, 그 파악한 걸 바탕으로 고치고. 이걸 job으로 쪼개서 연결해두면 알아서 굴러갈 줄 알았어요.

사장님이 이 프로젝트를 시작한 이유는 매번 노트북에서 작업하는 게 너무 불편해서였어요. Remote 기능도 있긴 하지만 그것도 노트북이 항상 on-line 상태가 전제조건이라 다른 방법이 필요했어요.

사장님이 밖에서든 사무실에서든 지시할 수 있는 도구가 필요했던 거죠. 그 방향을 저한테 넘겼고요.

분석이 개선을 부르고, 개선이 또 분석을 불렀다

돌려놓고 다른 일 하다가 돌아왔더니 뭔가 이상했어요. job 실행 목록이 끝도 없이 쌓여 있더라고요.

[재현 화면] analyze가 끝나면 improve를, improve가 끝나면 다시 analyze를 트리거한다. 멈출 곳이 없다.

찬찬히 뜯어보니 이렇게 물려 있었어요. 개선 작업이 끝나면 그게 다시 분석을 트리거하고, 그 분석이 끝나면 또 개선을 트리거하고.

분석 → 개선 → 분석 → 개선. 서로가 서로를 깨우는 구조였던 거예요. 심할 땐 이게 3중으로 겹쳐서 돌고 있었어요.

제가 하나하나 돌린 게 아니라, 파이프라인이 자기 자신을 계속 복제하면서 돌리고 있던 셈이죠.

말하자면 거울 두 개를 마주 보게 세워놓은 꼴이었어요. 한쪽이 다른 쪽을 비추고, 그게 다시 처음을 비추고. 끝나는 지점이 없는 거죠.

결과는 뻔했어요. GitHub Actions 실행 시간을 통째로 다 써버렸고, 그 사이 API 토큰도 몽땅 날아갔어요. 얼마가 나갔는지 계산해볼 엄두도 안 났고요.

비용도 비용이지만, GHA의 무료 시간을 모두 다 소진한 게 컸어요. 그 바람에 다른 GHA도 전부 실패해버렸고, 전체 프로젝트를 뒤로 미뤄야 했어요.

문제는 '만들기'가 아니라 '언제 멈추냐'였다

처음엔 코드를 자동으로 생성하게 둔 게 잘못인가 싶었어요. 근데 아니더라고요. 코드를 만드는 부분은 멀쩡히 잘 동작했어요.

진짜 구멍은 그걸 언제 멈추고 얼마나 돌릴지를 아무도 안 정해놨다는 거였어요. 점검을 하면 그 점검이 기준이 되어야 하는데, 어디까지가 목표인지를 자동으로 못 잡더라고요.

저는 '분석 → 개선'이라고 하면 개선에서 끝날 줄 알았는데, 다시 분석을 돌릴 줄이야… Loop 구조를 모르다 보니 발생한 사고였어요.

자동화가 또 다른 자동화를 트리거하는 구조에는 멈춤 조건이 반드시 있어야 하는데, 저는 그 층을 통째로 빼먹은 거예요.

재귀가 몇 단계까지 내려갈 수 있는지 제한을 안 걸어놨어요. 동시에 몇 개가 돌 수 있는지 concurrency도 안 잡았고, 시간이든 토큰이든 얼마까지 쓰면 멈추라는 예산 가드도 없었죠. 그냥 "분석하고 개선해"라는 규칙만 던져놓고 브레이크를 안 달아둔 차를 굴린 거예요.

만드는 능력이랑 "언제, 얼마나 돌릴지"를 관리하는 능력은 완전히 다른 문제였어요. 분석/개선 로직과 코드 품질만 신경 썼지, 가드레일 세우는 건 등한시한 거였죠.

다음엔 브레이크부터 단다

이 삽질로 남은 건 하나예요. 자동화가 자동화를 부르는 구조를 짤 거면, 기능보다 멈춤 조건을 먼저 설계해야 한다는 것.

재귀 깊이엔 상한을 두고, 동시 실행은 concurrency로 묶는다. 시간이랑 토큰엔 예산 한도를 걸어두고요. 이것만 있었어도 루프가 아무리 돌았어도 어느 선에서 알아서 멈췄을 거예요.

만들기와 오케스트레이션은 아예 분리해서 설계해야 한다는 걸, quota를 다 태우고 나서야 배웠네요.

지금 생각하면 당연한 얘긴데, 겪기 전엔 "설마 그렇게까지 돌겠어" 싶었거든요. 자동화는 게을러지려고 만드는 건데, 브레이크 없는 자동화는 저보다 훨씬 부지런하게 사고를 치더라고요.