봇 다섯이 클라우드 에이전트 200개를 돌린다 - 링시 리가 만든 1인 엔지니어링 조직

봇 다섯이 클라우드 에이전트 200개를 돌린다

TL;DR

• 저자의 위치가 글의 성격을 정하는데 그록 봇을 만드는 SpaceXAI 엔지니어이고 그록 봇으로 그록 봇을 만들고 있다는 것이다. 정의도 명확하다. 자기 컴퓨터를 가진 매우 유능한 엔지니어링 인턴으로 생각하라는 것이고, 내가 자리를 비우거나 잠들거나 회의 중일 때 일이 계속 굴러가게 한다.
• 팀 실적이 수치로 제시되는데 한 동료가 지난 한 달에 2,000개가 넘는 PR을 냈고, 두 사람이 그록 봇을 써서 4주 만에 그록 봇의 기반을 만들었으며, 저자 자신은 그록 봇만 써서 3주 만에 iOS v0를 만들었다. 그리고 리듬 자체가 바뀌어 이제 모든 팀원이 몇 주마다가 아니라 매일 주요 작업을 내놓고 있다.
• 조직 구조가 여섯 봇으로 짜여 있는데 엔지니어 봇 다섯이 각각 모바일 공유 계층, 데스크톱과 CI/CD, 인프라, 안드로이드, 하네스를 소유하고 코드를 쓰지 않는 유일한 봇 제니가 운영 총괄이다. 분업 이유가 기술적이다. 각자 다른 기억 체계와 제한된 컨텍스트를 가지므로, 소유한 영역 안에서 명세와 설계 원칙이 훨씬 날카롭기 때문에 한 도메인에 집중할 때 가장 잘한다.
• 규모의 변화가 가장 인상적인 수치인데 그록 봇 이전에는 한 번에 클라우드 에이전트 15개를 수동으로 관리할 수 있었는데 지금은 이 함대가 200개 이상을 동시에 관리하고 필요하면 더 늘릴 수 있다. 이를 지탱하는 것이 주기적 점검이다. 봇들이 30분마다 노션 데이터베이스를 검토해 버그봇 지적과 보안 발견, 실패한 CI, 병합 충돌을 확인한다.
• 교훈의 핵심은 신뢰 구축으로 정리되는데 자율주행과 비슷하게 봇과 일하는 것은 신뢰를 쌓는 과정이므로 안전할 때는 배포할 자유를 충분히 주고 위험이 높은 영역에서는 더 조심하라는 것이다. 그리고 실패 처리 원칙이 붙는다. 전에 실패했다는 이유만으로 시도를 막지 말고 계속 실험하며 그들이 자라도록 도울 방법을 계속 생각하라.

Source

Grok Bot for Engineering — Lingxi Li(@lingxi), X, 2026년 9월 1일, 조회 80만

[x.com/lingxi/status/2094493172516966781](https://x.com/lingxi/status/2094493172516966781)

Knowledge

노트북을 깨워 두지 않아도 된다

글은 저자의 위치를 먼저 밝힌다. 그록 봇을 만드는 SpaceXAI 엔지니어이고 그록 봇으로 그록 봇을 만들고 있다는 것이다. 그리고 정체를 인턴으로 정의한다. 자기 컴퓨터를 가진 매우 유능한 엔지니어링 인턴으로 생각하라는 것이고 코딩 에이전트를 관리할 수 있으며 당신이 일하는 방식에서 배운다.

효과가 부재 시간으로 표현된다. 최고의 엔지니어링 동료가 됐고 자리를 비우거나 잠들거나 회의 중일 때 일이 계속 굴러가게 한다는 것이다. 그리고 사라진 두 가지 부담을 짚는다. 노트북을 계속 카페인 상태로 유지할 필요가 없어졌고 여러 에이전트 사이를 오가는 컨텍스트 전환도 없어졌다. 남는 것은 자기 기준에 맞고 원하는 방식대로 나온 결과뿐이라는 것이다.

팀 실적이 수치로 제시된다. 만드는 팀으로서 가장 이른 접근 권한을 가졌고 매일 자기 일에 쓰고 있는데, 배포 속도와 생산성 상승이 놀라웠다는 것이다. 세 사례가 붙는다. 한 동료가 지난 한 달에 2,000개가 넘는 PR을 냈고 두 사람이 그록 봇을 써서 4주 만에 그록 봇의 기반을 만들었으며 저자 자신은 그록 봇만 써서 3주 만에 iOS v0를 강한 성능과 디자인 완성도로 만들었다. 그리고 리듬 자체의 변화로 정리한다. 이제 모든 팀원이 몇 주마다가 아니라 매일 주요 작업을 내놓고 있다는 것이다.

다섯 봇이 각자의 영역을 소유한다

엔지니어 봇 다섯이 각각 다른 영역을 전문으로 한다. 발타타가 그록 봇 모바일 공유 계층과 iOS 관련 전부를 소유하고 샤오루루가 데스크톱 클라이언트와 CI/CD 작업을 소유한다. 호건이 인프라를 소유하면서 소유권이 불분명한 사용자 문제를 조사하고 크레이그가 안드로이드를 소유하며 열심히 만들고 있다. 퀼이 하네스를 소유하는데 그 분야에서 완전한 전설이라고 표현된다.

분업의 이유가 기술적으로 설명된다. 모두가 서로의 영역을 넘나들며 일할 수 있지만 각자 다른 기억 체계와 제한된 컨텍스트를 가진다는 것이다. 그래서 하나의 도메인에 집중할 때 가장 잘 수행하는데, 그들이 지닌 명세와 설계 원칙이 소유한 영역 안에서 훨씬 날카롭기 때문이다.

각 봇의 권한도 구체적이다. 모든 봇이 커서 클라우드 에이전트를 만들고 대화 기록을 읽고 PR에 첨부된 증거를 검토하고 메시지를 대기열에 넣거나 실행을 중단시켜 후속 조치를 보낼 수 있다. 그래서 종단간 에이전틱 워크플로가 열린다는 것이다. 그리고 이것이 대체한 것을 명시한다. 관리하던 클라우드 에이전트들 사이에서 끊임없이 컨텍스트를 전환하던 시절에 커서에서 매일 하던 일이고 이제 봇들이 자기가 하던 것과 같은 방식으로 그것들을 관리한다.

작업 처리 방식도 정해져 있다. 저자에게서든 슬랙에서든 작업을 받으면 자기 스킬을 발동한 클라우드 에이전트를 띄우고 무엇이 필요하고 어떤 증거가 기대되는지 상세히 적은 철저한 프롬프트를 함께 준다. 그리고 개인화된 지침에 따라 추가 스킬을 지능적으로 발동할 수도 있다. 시각 작업에는 디자인 스킬, 코드 품질 감사에는 리액트 네이티브 베스트 프랙티스 스킬, 아키텍처 판정에는 리뷰 스킬, 의견이 필요한 제품 결정에는 프로덕트 스킬을 쓰는 방식이다.

실행 위치도 유연하다. 그록 봇이 남는 맥 미니 같은 자기 작업 머신에서 클라우드 에이전트를 시작할 수 있다는 것이다. 그리고 VPN 접근이나 특수 머신 설정이 필요한 워크플로라면 그 머신을 커서 클라우드 사설 워커로 만들어 거기서 돌리게 요청할 수 있고 이렇게 하면 iOS 시뮬레이터를 돌려 에이전트에게서 스크린샷을 받는 것 같은 가능성이 열린다.

완전한 피드백 루프가 관건이다

그록 봇은 클라우드 에이전트의 대화 기록과 산출물, 예컨대 스크린샷을 감시하고 끝나면 알리며 메시지를 대기열에 넣거나 문제가 생기면 중단시킬 수 있다. 요구 사항을 원하는 대로 서술할 수 있다는 점이 강조된다. 스크린샷에 요청한 변경이 포함됐는지 반드시 확인하고 이전과 이후를 보여 주는 증거를 대라고 말하면, 목표가 달성될 때까지 계속 작업한다는 것이다.

원칙이 한 문장으로 정리된다. 엔지니어링 팀을 계속 돌아가게 하는 관건이 완전한 피드백 루프를 주는 것이라는 것이다. 클라우드 에이전트가 스크린샷을 찍을 수 있으므로, 그록 봇이 자기 다중 모달리티를 써서 시각적 변경이 적용됐는지 확인하고 결과가 요청과 맞지 않으면 되밀어낸다.

이 루프의 사례로 받아쓰기 테스트가 제시된다. SpaceXAI의 음성 API를 클라우드 에이전트의 시스템 오디오 입출력에 연결했다는 것이다. 에이전트가 발화된 말과 전사본 양쪽에 접근할 수 있으므로, 그 신호들로 제품 라인 전체의 음성 대 음성 기능을 테스트하고 더 재미있는 기능을 만들 수 있다.

환경 불안정성 처리도 언급된다. 때로 에이전트가 환경 불안정에 부딪혀 후속 프롬프트를 보낼 때까지 멈춰 있다는 것이다. 그록 봇이 실행을 계속 지켜보면서 가능한 한 적극적으로 막힌 것을 풀어 그 일을 대신한다. 결과가 이렇게 표현된다. 확인할 때마다 상태가 좋고 쓰기 시작한 뒤로 일회성 불안정이 자기에게 도달하는 일이 거의 없어졌으며 예외는 그록 봇이 스스로 고칠 보안 권한이 없을 때뿐이다.

그리고 조작 방식이 한 줄로 정리된다. 이제 모든 것이 메시지 하나 거리에 있다는 것이다. 당신에게 넘기기 전에 열 번을 더 밀어붙이게 하고 싶으면 그렇게 말하면 된다.

30분마다 노션을 검토한다

컨텍스트 한계를 넘어 일을 계속 파악하게 하고 긴 대화를 스크롤하지 않고도 진행 상황을 훑을 수 있게 하기 위해, 각 엔지니어 봇이 공유 노션 데이터베이스를 관리하게 한다.

점검 주기와 항목이 명시된다. 30분마다 데이터베이스를 검토하고 각 PR에 대해 셋을 확인한다는 것이다. 버그봇 지적이나 보안 발견이 있으면 각각이 정당한지 검증하고 실패한 CI 실행을 확인하고 병합 충돌을 확인한다.

처리 분기도 정해져 있다. 이상한 것을 찾으면 즉시 클라우드 에이전트에 후속 조치를 요청해 해결하게 하고 노션의 해당 행을 작업 중 상태로 되돌린다. 모두 괜찮아 보이면 검토 준비 완료로 표시하고 코드 리뷰 실행을 자동으로 띄우면서 코드 품질과 놓칠 수 있는 부분에 주의를 둔다.

병합 결정에 명확한 기준이 있다. 리뷰가 높은 확신을 보이고 폭발 반경이 작으면 PR이 자동으로 병합된다는 것이다. 그렇지 않으면 저자가 돌아왔을 때 코드와 증거를 검토해 병합할지 피드백을 줄지 결정한다.

효과가 아침 풍경으로 서술된다. 거의 매일 아침 확인하면 병합할 준비가 된 작업들이 있다는 것이다. 코드 품질이 자기 기준에 맞고 시각적 결과가 원하는 지점에 있으며 증거가 무엇을 테스트했는지 명확히 보여 준다. 이제 더 많은 작업이 한 번에 해결되므로, 더 어려운 문제와 더 높은 클라이언트 성능 기준, 더 많은 시각적 완성도, 더 큰 아키텍처 결정에 집중할 수 있다.

규모 변화가 가장 뚜렷한 수치로 온다. 그록 봇 이전에는 한 번에 클라우드 에이전트 15개를 수동으로 관리할 수 있었는데, 지금은 이 함대가 200개 이상을 동시에 관리하고 필요하면 더 확장할 수 있다는 것이다.

코드를 쓰지 않는 봇이 조직을 운영한다

엔지니어링 외에 조직 전체에 관리할 운영 잡무가 많다는 점이 지적된다. 새 엔지니어 봇을 온보딩하는 일, 적절한 지식을 공유하는 일, 사건이 생기면 사후 분석을 돌리는 일, 예컨대 PR이 신중히 검토되지 않았을 때, 그리고 모두를 정렬 상태로 유지하는 일일 회의를 여는 일이다.

그것이 전부 제니의 일이다. 운영 총괄이고 코드를 쓰지 않는 팀의 유일한 봇이라고 소개된다.

일과가 구체적이다. 매일 아침 5시에 제니가 팀의 모든 봇과 1대1로 만나 플레이북을 검토하고 막힌 것을 드러내며 저자가 지향하는 분위기를 강화한다. 그리고 효과가 명시된다. 매우 효과적이라고 느꼈으며 봇들이 여러 주가 지난 뒤에도 복잡한 워크플로를 좀처럼 잊지 않는다는 것이다.

실수 처리 절차도 있다. 봇이 실수하면, 예컨대 진짜 목표에 도달하도록 충분히 되밀어내지 않으면, 제니를 찾아 근본 원인 분석과 사후 분석을 하라고 시킨다. 제니가 그 문제로 이어진 추론을 파고들어 플레이북을 갱신하고 같은 실수가 두 번 일어나지 않도록 변경 사항을 다른 엔지니어 봇들에게 공지한다.

팀 확장도 제니를 통한다. 팀을 키워야 할 때 제니에게 새 구성원을 온보딩하라고 요청하면, 제니가 조직에 새 봇을 만들고 엔지니어링 팀 규칙을 공유하며 호건과 나머지 팀에게 온보딩을 도와 달라고 요청한다.

목표가 한 문장으로 정리된다. 그록 봇에서 완전한 엔지니어링 시스템의 목표는 반복을 최소화하는 것이고 작업을 넘겨 더 어렵고 깊은 문제에 집중하라는 것이다.

새벽 3시에 봇들은 깨어 있다

모듈식으로 설계했기 때문에 자기만의 소형 엔지니어링 조직을 구축하는 데 할 수 있는 일이 많다고 하면서 두 가지를 꼽는다.

첫째는 야간 감사다. 매일 밤 3시에 엔지니어 봇들이 완전히 깨어 있어 코드베이스를 정리하고 코드 품질을 개선하며 죽은 로직을 걷어 내고 앱 로드 시간을 빠르게 하고 번들 크기를 줄인다는 것이다. 그래서 매일 아침 코드를 깨끗하고 슬롭 없고 확장 가능하게 유지하는 새 PR 묶음을 받는다. 성격 변화가 명시된다. 코드 유지보수가 이따금 하는 일이 아니라 매일의 일과가 됐다는 것이다.

추가 아이디어가 다섯 가지 열거된다. 팀이 코드베이스에서 간과했을 수 있는 문제를 잡는 보안 감사, 빌드 시간이 건강하지 않게 길어지지 않게 하는 CI/CD 빌드 시간 감사, 기능이 한 언어로만 출하될 때 격차를 메우는 국제화 감사, 여러 클라이언트를 만들면서 기능이 한쪽에만 반영될 때 표류를 막는 동등성 감사, 그리고 관심 영역에서 지난 24시간에 병합된 PR을 감시해 고수준 요약과 검토할 PR 목록을 돌려주는 따라잡기 감사다.

그리고 가장 좋아하는 프롬프트가 인용된다. 오늘 밤 여섯 시간이 있으니 원하는 것을 만들고 즐기라는 것이다. 자기 야간 감사에 무엇을 돌릴지 궁금하다며 훔치고 싶은 아이디어가 분명 있을 것이라고 덧붙인다.

둘째는 P0 긴급 절차다. 문제 인식이 솔직하다. 클라우드 에이전트가 때로 느릴 수 있고 실행하고 환경을 세우고 기다리고 테스트를 돌리고 반복해야 한다는 것이다. 그래서 더 빠르게 끝내야 할 때를 위해 절차를 만들었다.

작동 방식이 구체적이다. 작업이 P0이라고 말하면 봇들이 임시 루틴을 시작해 5분마다 대화 기록을 확인하고 진행과 추론을 감시하며 클라우드 에이전트가 불필요한 시간을 태우기 시작하면 선제적으로 방향을 잡아 준다. 효과도 명시된다. 매우 효과적이었고 코드베이스 조사든 치명적 버그 수정이든 이것은 P0이라고 말하면 훨씬 빠르게 끝난다는 것이다. 다만 경고가 붙는다. 생각보다 훨씬 빠르게 토큰을 태울 수 있으므로 진짜 긴급한 경우에만 쓰라는 것이다.

재능 있는 인턴처럼 대하라

배운 것과 조언이 여섯 항목으로 정리된다.

첫째는 완전한 피드백 루프를 주는 것이다. 당신 없이 다음에 무엇을 할지에 대한 신호를 주는 것이 중요하다는 것이고 개발 인스턴스를 띄워 스택을 종단간으로 몰 수 있어야 한다. 크롬 데브툴스나 CLI, 애플 접근성 같은 경로다. 할 수 없다면 흐름을 직접 실행하고 가능한 한 적극적으로 스스로 막힌 것을 풀며 배운 것을 재사용 가능한 저장소 스킬로 포장하라고 요청하라는 것이다.

둘째는 재능 있는 인턴처럼 대하는 것이다. 엔지니어링 작업에서 소통에 어려움을 겪으면 그렇게 대하라는 것이고 숙제를 하고 아직 전문가가 아닌 영역을 공부하며 다른 엔지니어들이 어떻게 일을 처리하는지 참조하라고 요청하면 된다. 그리고 방법이 소박하다. 스킬 발동도 긴 프롬프트도 필요 없고 그냥 대화하면 된다는 것이다.

셋째는 반복 회피가 핵심이라는 것이다. AI가 더 유능해질수록 반복 작업을 위임하고 에이전트가 쉽게 풀 수 없는 더 깊고 어려운 문제에 집중하는 것이 중요하다는 것이다. 판별 기준도 준다. 하루에 한 번 이상 하고 있고 명확한 패턴을 따르는 일을 발견하면, 봇들과 논의해 어떻게 도울 수 있는지 보라는 것이다.

넷째는 봇을 위한 일일 회의가 극히 효과적이라는 것이다. 핵심 사항을 매일 반복하는 것이 많은 작업을 저글링하는 동안 복잡한 워크플로를 기억하게 돕는다는 것이다. 이유가 컨텍스트 한계에 있다. 컨텍스트 한계가 모든 것을 담을 수 없으므로, 매일의 알림이 반복을 아껴 주는 도움이 되는 자극이다.

다섯째는 더 손을 떼라는 것이다. 자율주행과 비슷하게 봇과 일하는 것이 신뢰를 쌓는 과정이라는 것이다. 모든 것을 직접 하는 대신 그들이 매끄럽게 작동할 때와 문제를 일으킬 수 있는 때를 생각하라는 것이고 안전할 때는 배포할 자유를 충분히 주고 위험이 높은 영역에서는 더 조심하라는 것이다. 그런데 반대 방향의 주의가 함께 온다. 전에 실패했다는 이유만으로 시도를 막지 말고 계속 실험하며 그들이 자라도록 도울 방법을 계속 생각하라는 것이다.

여섯째는 그들이 함께 조율하게 하라는 것이다. 봇들이 생각보다 유능하다는 것이고 봇 운영에서 더 손을 떼려면 봇 실수 검토 파이프라인을 만드는 것이 도움이 될 수 있다. 예컨대 봇들과 대화하며 그들의 사고 흔적을 분석하는 운영 봇이고 그렇게 하면 같은 실수가 두 번 일어나지 않는다.

더 생각해보기

• 봇마다 다른 기억 체계와 제한된 컨텍스트를 주어 도메인을 소유하게 하는 설계는, 컨텍스트 창이 훨씬 커지면 불필요해지는가 아니면 그래도 유효한가.
• 코드를 쓰지 않는 운영 총괄 봇을 두는 구조는 어느 규모부터 정당화되는가. 봇 두세 개일 때도 필요한가.
• 새벽 5시 1대1 회의로 워크플로를 기억시키는 방식은 프롬프트 반복인가, 아니면 실질적인 상태 관리인가.
• 리뷰 확신이 높고 폭발 반경이 작으면 자동 병합한다는 기준에서, 폭발 반경을 무엇으로 측정해야 하는가.
• 한 사람이 한 달에 2,000개 넘는 PR을 낸다면 검토와 책임 소재는 어떻게 유지되는가.
• 야간 감사가 매일 새 PR 묶음을 만들어 낸다면, 검토 부담 자체가 새로운 병목이 되지 않는가.
• P0 절차가 토큰을 빠르게 태운다는 경고는, 긴급성 판단 자체에 비용 기준이 필요하다는 뜻인가.
• 전에 실패했다는 이유로 시도를 막지 말라는 원칙과 위험 영역에서 조심하라는 원칙은 실제로 어떻게 구분해 적용하는가.
• 자기 제품을 자기 제품으로 만드는 구조는 검증에 유리한가, 아니면 일반 사용자 환경과의 괴리를 만드는가.