에이전트 코드 리뷰를 멈추다: 대신 하는 일

주의: 이 글은 파워 유저들을 위한 것입니다. Claude Code와 같은 코딩 에이전트를 매일 구축하는 것에 익숙하고, CI(지속적 통합), 병합 대기열(merge queues), 기능 플래그(feature flags)에 익숙하다고 가정합니다. AI 여정 초반이라면 나중에 읽도록 북마크해 두세요. Operate의 게시물들이 시작하기 더 좋은 곳입니다.

2주 전, 저는 소프트웨어를 구축하는 방식을 바꿨습니다. 그 이후로 562개의 PR(Pull Request)을 병합했고, 솔직히 말해서 그 밤 네 번은 산에서 하이킹을 했습니다.

비디오에서는 제가 현재 어떻게 작업하는지 정확하게 설명합니다. 아래에는 글로 된 보조 자료가 있습니다: 설정, 프롬프트, 수치, 그리고 이번 주에 시도해 볼 것들입니다.

만약 여전히 에이전트가 작성한 모든 줄을 검토하고 있다면, 이 글이 당신을 위한 것입니다.

전체 워크플로우를 네 줄로 요약하면

의도를 설정한다. 에이전트와 함께 계획하여 무엇을 만들고 왜 만드는지에 동의할 때까지 진행합니다. 가드레일(Guardrails)을 설정한다. 에이전트가 우회할 수 없는 테스트, CI, 그리고 리뷰 봇을 만듭니다. 목표를 설정한다. 한 세션에, 하나의 코디네이터 에이전트와 하위 에이전트들이 작업을 수행합니다. 작은 조각으로 병합되게 한다. 자동 병합(Auto-merge), 기능 플래그, 검증, 반복합니다.

무엇이 바뀌었나

모델들은 지난 몇 주 동안 극적으로 변했습니다. 특히 Opus 5.5가 그렇습니다. 몇 주 전만 해도 저는 누구에게도 이런 방식으로 작업하라고 말하지 않았을 겁니다. 항상 제가 작업을 확인해야 한다고 느꼈습니다. 품질이 충분한가? 이것을 병합해야 하는가?

이제는 에이전트가 두 가지 요소, 즉 **올바른 의도(right intent)**와 그 의도가 실제로 충족되도록 보장하는 **올바른 가드레일(right guardrails)**만 설정된다면 전체 계획을 스스로 수행할 수 있다고 느낍니다. 이 두 가지만 제대로 갖추면 에이전트가 마음껏 작동하도록 할 수 있습니다.

이 작업의 대부분은 Spare의 내부 운영 플랫폼인 Sightline에 투입되었습니다. 제가 모든 것을 가장 먼저 시도하는 곳입니다.

이제 진짜 작업은 가드레일이다

AI 코드는 비결정적(non-deterministic)이며 위험을 내포합니다. 하지만 인간 코드 역시 비결정적이며, 정확히 같은 위험을 가지고 있습니다. 우리는 사람이 실수를 하지 않도록 SRE 시스템을 구축했습니다. 이제 에이전트가 실수하지 않도록 훨씬 더 강화된 동일한 시스템이 필요합니다.

사고 발생 시 사용하는 무비난 문화(blameless culture)를 에이전트에게도 적용합니다. 즉, 에이전트가 실수를 하더라도 에이전트를 비난하지 않습니다. 대신 어떤 가드레일(guardrail)이 부족했는지 묻고 그것을 구축하는 데 집중합니다.

이는 품질 관리가 중요하지 않다는 의미는 아닙니다. 에이전트 역시 문제를 일으킬 수 있습니다. 바로 이 때문에 가드레일이 필요한 것입니다. Sightline PR은 병합되기 전에 다음 과정을 모두 거칩니다:

단위 테스트(Unit tests)
엔드투엔드 테스트(End-to-end tests)
CI, Bugbot, Strix
Mergify는 위의 모든 항목이 통과할 때까지 PR을 병합 대기열에 넣지 않습니다.

따라서 무언가가 대기열에 올라가면, 단 하나의 위험 신호도 건너뛸 수 없다는 것을 알 수 있습니다.

가드레일은 스스로를 보호하기도 합니다. 저희는 Bugbot에게 더 많은 테스트를 요청하도록 시킵니다. CI 내의 이러한 피드백 루프(feedback loops) 덕분에 우리는 시스템 가동 시간(uptime)을 위험에 빠뜨리지 않으면서도 이렇게 빠르게 진행할 수 있습니다. 그리고 만약 무언가가 새어 나오더라도, 단순히 코드를 수정하는 데 그치지 않습니다. 가드레일 자체를 수정합니다.

워크플로우 단계별 설명

1. 에이전트와 계획 세우기

모든 세션은 같은 방식으로 시작됩니다. 저는 Claude를 열고 함께 계획을 수립합니다. 어떻게 작업을 분할할지, 어떤 어려움이 있을지, 어떤 위험 요소가 있는지 논의합니다. 또한 UX 미리보기(UX preview)도 요청하는 경우가 많은데, 그래야 무언가를 구축하기 전에 사용자가 어떤 느낌일지 확인할 수 있습니다.

지금 제가 시간을 가장 많이 쓰는 부분이 바로 여기입니다. 저는 코드가 아니라 계획을 검토합니다.

2. 목표 설정 (매번 동일한 프롬프트 사용)

계획에 동의하면, 세션을 열고 목표를 설정합니다. 제가 사용하는 프롬프트는 단어 하나 틀리지 않고 다음과 같습니다:

자동 병합(auto-merge)을 사용하여 계획을 달성하고 코드를 배포하세요. 당신이 조정자(coordinator)입니다. 직접 작업을 수행하지 마세요. 모든 것은 서브 에이전트(sub-agents)를 사용하고, 가능한 경우 병렬화하세요.

3. 조정자의 컨텍스트 유지하기

조정자 역할은 큰 도움이 됩니다. 최상위 에이전트는 계획과 상태만을 보유하므로, 그 컨텍스트가 깨끗하게 유지됩니다. 서브 에이전트들이 실제 작업을 수행하며, 계획이 구체화됨에 따라 나타났다 사라집니다.

4. 작은 조각으로 병합하기

제가 스스로 병합하도록 내버려 두었는데, 솔직히 상당히 안전합니다. 이 모델들은 신중해서 무언가를 망가뜨리고 싶어 하지 않습니다. 모든 것을 기능 플래그(feature-flag)로 처리해 달라고 요청하면 그렇게 해줍니다. 왜냐하면 병합할 수 있기 때문에 작은 조각들로 배포하기 때문입니다. 무언가를 배포하고, 스테이징 또는 프로덕션 환경에서 엔드투엔드 테스트(end-to-end tests)를 실행하여 작동하는지 확인한 다음, 다음 것을 배포합니다. 다단계 배포(Multi-stage deploys), 작은 증분(small increments)으로요.

조금 논란의 여지가 있는 의견을 드리자면: 로컬에서 작업하며 반복적으로 수정하는 거대한 PR 하나가, 모든 검사를 통과한 스무 개의 작은 PR들보다 결국 더 위험할 수 있습니다.

5. 변경 사항(diffs)이 아닌 진행 보고서를 검토하세요

저는 돌아와서 진행 보고서를 요청합니다. 에이전트가 HTML 보고서를 만드는데, 무엇이 완료되었는지, 다음은 무엇인지, 그리고 저에게 무엇이 필요한지가 담겨 있습니다. 제가 검토하는 것은 바로 그것입니다.

6. 며칠 동안 실행하게 하고, 여러 개를 동시에 실행하세요

제가 생각하기에 대부분의 사람들이 놓치는 부분이 여기 있습니다: 목표(goals)가 밤새도록, 필요하다면 며칠 동안 실행되도록 내버려 두세요. 저희 커스텀 역할 목표는 하루 이상 실행되었습니다. 저는 주기적으로 확인하고, 보고서를 읽고, 필요한 경우 자극을 주어 실제로 목표에 도달할 때까지 계속 진행되도록 했습니다.

저는 보통 관련 없는 기능들로 두세 개 또는 네 개의 목표를 동시에 실행합니다. 이것이 우리가 정말 빠르게 많은 것을 처리할 수 있게 해줍니다.

더 크게 요청하세요

우리 대부분은 여전히 이 도구들을 매우 빠른 엔지니어처럼 사용합니다: 이 티켓을 구현하고, 이 엔드포인트(endpoint)를 추가하는 식입니다. 그것도 작동하지만, 너무 작게 생각하고 있습니다. 목표 워크플로우(goal workflow)를 사용하면 훨씬 더 높은 수준의 의도(intent)를 설정하거나, 개방형 질문을 하거나, 아니면 전체 비즈니스 문제 자체를 던져주고 무엇이 일어나야 하는지 스스로 파악하게 할 수 있습니다.

"역할 편집기(role editor) 추가하기" 대신에 목표는 "Sightline의 권한이 Spare처럼 모든 곳에서 작동하도록 만들기"였습니다. "OKRs를 패키지로 이동시키기" 대신에는 "Sightline을 다른 팀들이 확장할 수 있는 플랫폼으로 전환하기"였습니다.

당신은 이것보다 훨씬 더 멀리 밀어붙일 수 있습니다:

"우리 CI가 너무 느려요. 더 빠르게 만들어 주세요." 바로 그거예요. 어디서 시간이 낭비되는지 찾아내고 고치게 하세요.
"엔터프라이즈 고객사 중 한 곳에서 PPVH(Pages Per View Hours)가 낮게 측정되고 있어요. 5일 치 데이터를 파헤쳐서 어떻게 최적화할 수 있을지 알아봐 주세요." 이건 코딩 작업이 아니라 진짜 비즈니스 문제입니다.
"관리자 패널 전반에 걸쳐 프론트엔드 UX가 일관성이 없어요. 불일치한 부분을 찾아내고 제거하는 것을 도와주세요."

이것들은 티켓(tickets)이 아닙니다. 이것들은 결과물(outcomes)입니다. 이제 모델들은 결과물을 받아 그것을 세분화하고 하루 이상에 걸쳐 목표를 향해 작업할 만큼 충분히 좋아졌습니다.

용량: 토큰이 병목 현상을 일으키다

이렇게 일하게 되면서, 토큰(tokens)이 병목 현상(bottleneck)이 됩니다. 개별 플랜으로는 더 이상 충분한 크레딧을 제공하지 못하고, 초과 사용료는 매우 비쌉니다.

제가 하고 있는 것은 여러 개의 Claude 계정을 운영하는 것입니다. 각각 약 200달러짜리 다섯 개의 계정이고, 'Claude Swap'이라는 도구를 이용해 이들 사이를 전환합니다. 이 도구는 각 계정의 5시간 및 7일 사용량을 모니터링하고, 어느 한쪽이 90%에 도달하면 자동으로 스위칭하여 모든 것이 백그라운드에서 계속 실행되도록 합니다.

완벽하지는 않습니다. 계정을 전환할 때 Claude 아티팩트(artifacts)나 모바일 앱에서의 원격 제어 기능 같은 것들이 손실되고, 저는 브라우저와 휴대폰에서 끊임없이 다시 로그인해야 합니다. 시간 낭비입니다. 그래서 이번 주에는 스위칭 없이 동일한 문제를 해결하는 도구들, 즉 Paseo, Orca, Superset 및 몇 가지 다른 도구들을 살펴보고 있습니다.

앞으로의 방향성

우리의 업무는 개별적인 결과물을 배포하는 것에서 벗어나고 있습니다. 제품을 진화시키는 시스템을 구축하는 쪽으로 이동하고 있습니다. 우리가 의도(intent)를 설정하면, 그 목표를 향해 스스로 치유되는(self-heal) 시스템을 구축합니다.

우리는 이미 이를 수행하고 있습니다: 버그를 수정하는 자동화, SRE 작업용 자동화, 취약점 연구를 수행하는 에이전트, 그리고 보안 위험을 자동으로 완화하기 위한 초기 작업입니다. 다음은 데이터베이스와 렌더링에서 낮은 품질이나 성능 문제를 찾아내고 UI의 불일치성을 찾는 시스템과, 이를 수정하는 에이전트들입니다. 테스트 커버리지의 격차를 찾고 테스트 케이스를 작성하는 에이전트들이 올 차례입니다.

우리가 개별적인 모든 것을 파악하는 것이 아닙니다. 시스템이 더 나은 곳으로 치유되도록 지키는 가드레일(guardrails)을 세우는 것입니다.

이번 주에 시도해 볼 세 가지 방법

하나의 실제 기능 코드만 검토하는 것을 멈추세요. 위험도가 낮은 것부터 시작하세요. 자신감이 생기면 더 큰 것에 적용해 보세요.
티켓(ticket)이 아닌 문제(problem)를 제시하세요. 얼마나 멀리 갈 수 있는지 확인해 보세요.
접근하고 있는 표면적(surface area)을 살펴보세요. 에이전트가 틀릴 수 없도록 어떤 가드레일이 빠져 있나요? 스스로 문제를 해결할 수 있는 루프는 무엇인가요?

여러분에게 효과적인 것이 있다면 듣고 싶습니다. 이것들을 시도해 보고, 결과가 어땠는지 답장이나 댓글로 남겨주세요. 저는 에이전트를 활용하여 구축하는 방법에 대해 더 많은 글을 쓸 예정입니다.

Alexey