핵심 요약

  • 그록봇은 대화창보다 봇을 중심으로 일을 구성한다. 각 봇에 역할과 도구를 주고, 사람이 요청하기 전에도 업무를 살피도록 설계했다.
  • 팀이 함께 쓰는 봇은 담당자의 업무 지식과 작업 방식을 공유하는 수단이 된다. 다만 여러 사람의 지시가 충돌할 때 누구를 따라야 하는지는 여전히 해결할 과제다.
  • 개발 자동화의 출발점은 AI가 직접 프로그램을 실행하고 결과를 확인하게 만드는 것이다. 기능이 작동하는 것과 코드 품질이 좋은 것은 별개다.
  • 반복 검토에 토큰을 쓰기보다 코드 구조와 자동 검사에 제약을 넣으면 비용을 줄일 수 있다. 중요한 인프라와 데이터베이스 작업에는 사람의 검토가 여전히 필요할 수 있다.
  • 실행 속도가 빨라질수록 무엇을 만들고 무엇을 내보내지 않을지 정하는 일이 중요해진다.

대화 상대를 넘어 업무를 맡는 동료로

Y Combinator의 대담 프로그램 ‘라이트 콘’에 그록봇 개발 핵심 팀원인 로런 탄과 로먼 우가르테가 출연했다. 두 사람은 첫 코드부터 출시까지 7주 만에 만든 제품을 소개하며 AI가 실제 동료처럼 일하려면 무엇이 필요한지 이야기했다.

출발점은 AI 코딩 도구가 엔지니어의 일하는 방식을 바꾸는 모습이었다. 목표를 향해 오래 작업하고 필요한 도구를 쓰는 AI 에이전트를 개발팀 밖에서도 활용할 수 있을지 실험했다.

그록봇의 설계 원칙은 세 가지다. 일을 대화나 파일이 아니라 봇 중심으로 구성하고, 봇도 사람과 같은 도구를 쓰며 계속 작동하면서 먼저 할 일을 찾아야 한다. 각 봇에는 이름과 역할, 작업 지침, 도구를 부여한다. 우가르테는 회사에 기여하려는 봇이라면 자기 컴퓨터 같은 작업 환경도 필요하다고 봤다.

내부 반응은 AI 도구에 적극적인 직원과 익숙하지 않은 직원 양쪽에서 좋았다고 한다. 사용법을 깊이 파고들지 않아도 시작할 수 있고 업무에 맞춰 설정할수록 더 많은 일을 맡길 수 있다는 점이 특징이었다.

개인의 도구가 팀의 작업 방식이 된다

개발팀이 소개한 사내 사례에서는 마케팅팀이 봇에 구글 광고와 페이스북 광고 계정을 제공하고 예산을 정해줬다. 광고 봇은 디자인 봇과 협업해 소재를 만들고 여러 안의 성과를 비교한다. 영업팀도 잠재 고객 조사와 영업 운영 업무를 전문 봇에 맡기기 시작했다.

직원마다 비슷한 봇을 따로 만들기보다 팀이 함께 쓰는 전문 봇에 업무 지식을 모으는 것을 중시한다. 영업 담당자들이 공유 봇에 각자의 모범 사례를 반영하면 다른 팀원도 그 방식을 활용할 수 있다. 업무를 가장 잘 아는 사람이 봇을 관리하며 견습 직원처럼 가르치는 형태다.

봇을 나누는 기준은 하나로 정해져 있지 않다. 엔지니어링·마케팅처럼 직무별로 구성할 수도 있고 고객마다 여러 업무를 담당하는 봇을 둘 수도 있다. 우가르테는 여러 문제를 한꺼번에 맡는 만능 봇보다 특정 문제를 계속 살피는 작은 봇 팀을 선호한다고 말했다.

슬랙에서 협업하면 작업 방식 자체도 퍼진다. 한 직원이 스레드에서 봇을 불러 문제를 해결하는 모습을 동료가 보고 다음 업무에서 따라 하는 식이다. 개인 대화창 안에 머물던 활용법이 팀의 공통 자산으로 바뀐다.

권한과 신뢰는 작은 업무부터 쌓는다

AI 동료가 늘어나면 조직 안의 관계도 이해해야 한다. 여러 사람이 슬랙에서 의견을 주고받을 때 봇은 누가 해당 분야의 전문가인지, 누구에게 결정권이 있는지 제대로 파악하지 못할 수 있다. 개발팀은 이런 문제를 제품과 에이전트 실행 환경, 모델 수준에서 함께 풀어야 한다고 봤다.

그록봇에는 소유자와 관리자, 협업자를 구분하는 개념이 있지만 인증과 접근 권한에는 아직 업계 공통의 정답이 없다는 입장이다. 우가르테가 제시한 기준은 사람을 채용할 때의 절차였다. 역할에 맞는 계정과 권한을 주고 신뢰가 쌓이면 접근 범위를 넓히는 방식이다.

실제 초기 사례도 제한된 권한에서 출발했다. 데이터 과학팀은 반복해서 들어오는 분석 요청을 처리하려고 데이터베이스를 읽기만 하는 봇을 만들었다. 직원은 슬랙에서 질문하고 봇은 데이터를 조회해 답하지만 다른 행동은 할 수 없다.

우가르테는 이를 세 단계로 구분했다. 먼저 읽기 전용 업무로 신뢰를 쌓고 다음에는 실제 행동을 포함한 과제를 처음부터 끝까지 맡긴다. 그 뒤에야 하나의 직무나 성과를 지속해서 책임지게 한다. 그는 마지막 단계까지는 아직 갈 길이 멀다고 말했다. 전화번호와 신용카드까지 가진 동료라는 구상 역시 앞으로 이루고 싶은 모습으로 제시했다.

자동화의 최소 단위는 스스로 확인하는 반복 작업이다

탄은 슬랙에서 동료와 봇 ‘포테이토’를 함께 불러 기능을 만든 사례를 소개했다. 참고 영상을 주고 비슷한 기능을 지원하려면 무엇이 필요한지 물었더니 봇이 커서 클라우드 에이전트를 실행했다. 에이전트는 자기 가상 컴퓨터에서 앱을 구동하고 시제품의 영상과 화면을 가져왔다.

팀은 약 200개 메시지가 오간 스레드에서 결과물을 보며 수정 방향을 논의했다. 탄은 이 작업에서 커서를 직접 열지 않았고 코드 변경을 검토·반영하는 단위인 풀 리퀘스트(PR)도 직접 읽지 않았다고 했다. 대신 실제로 나온 화면과 영상을 확인했다.

이런 방식은 준비 없이 바로 작동한 것이 아니다. 탄은 작업 지침과 코드 제약, 자동 검사 체계에 상당한 투자가 필요했다고 강조했다.

그가 제시한 가장 작은 작업 반복 구조는 작성 → 실행 → 확인 → 수정이다. 사람이 매번 프로그램을 실행해줘야 한다면 반복 과정의 일부가 여전히 사람에게 남아 있다. 에이전트가 직접 앱을 사용하고 성능 지표까지 확인해야 자기 결과를 고칠 수 있다.

원하는 기능이 작동한다고 좋은 코드가 되는 것은 아니다. 속도가 느리거나 자원을 낭비할 수 있다. 엔지니어의 역할은 에이전트가 기본적으로 더 좋은 코드를 쓰도록 환경을 설계하는 쪽으로 옮겨간다. 그 기반을 만든 뒤에는 모니터링 경고가 발생했을 때 봇이 문제를 재현하고 수정하는 단계로 확장할 수 있다.

검토 비용은 코드에 규칙을 새겨 줄인다

대담에서는 에이전트 코드 검토에 수천만 토큰이 드는 문제도 나왔다. 토큰은 모델이 입력과 출력을 처리하는 단위다. 탄은 여러 모델을 동원해 서로 반박하게 하는 검토가 유용할 수 있지만 최근에는 그 비중을 줄였다고 말했다.

검토 에이전트가 제품의 목표나 향후 계획을 충분히 모르면 중요하지 않은 문제를 붙잡을 수 있기 때문이다. 곧 없앨 기능을 이상적인 형태로 다듬는 데 시간을 쓰는 상황도 생긴다.

탄은 코드베이스 자체를 일종의 기억으로 봤다. 반복해서 지적하는 문제를 코드 구조, 인터페이스 설계, 프로그램을 실행하지 않고 규칙 위반을 찾는 정적 분석에 반영하면 같은 검토를 되풀이할 필요가 줄어든다. 그 위에 작업 지침과 필요한 사람의 검토를 더한다.

그록봇 데스크톱 앱에서는 화면을 그리는 렌더러 스레드가 무거운 작업 때문에 멈추는 문제를 줄이려고 의존성 검사기를 만들었다. 메인 스레드와 렌더러 스레드의 코드 사이에서 가져오기를 금지하는 규칙이다. 실행 시간을 자동으로 예측하는 도구는 아니지만 무거운 작업이 화면 처리 경로로 섞이는 일을 구조적으로 제한했다.

탄은 이런 접근을 주로 일반적인 제품 개발과 유지보수에 적용하며 인프라나 데이터베이스, 배포처럼 민감한 부분에는 사람이 계속 관여할 필요가 있다고 덧붙였다.

더 많이 만드는 능력과 출시 판단은 다르다

우가르테는 개발 속도가 높아지면서 팀의 병목이 구현 인력보다 제품 방향에 합의하는 일로 이동했다고 말했다. 아이디어를 논의하면 누군가 이미 관련 PR을 만들어둔 일이 반복됐다. 하지만 모두 반영하면 서로 다른 개인 프로젝트가 뒤섞인 제품이 될 수 있다.

팀은 작은 오류 수정과 사용자가 매일 접하는 핵심 화면 변경을 다르게 다룬다. 탄이 만든 자동화 체계는 여러 경로로 들어오는 고객 의견에서 작은 버그를 찾아 재현하고 수정한다. 반면 버튼 위치나 핵심 사용 경험을 바꾸는 작업은 내부에서 충분히 사용해본 뒤 판단한다. 내부 반응이 엇갈리는 변경도 출시하지 않는다고 했다.

탄 역시 자동화의 주된 대상을 새 기능보다 버그 수정, 성능 개선, 사용 불편 해소에 두고 있다. 유지보수를 에이전트에 맡겨 확보한 시간은 제품 경험을 고민하는 데 쓴다.

이 원칙을 다른 직무로 옮기기는 더 어렵다. 소프트웨어에는 빌드와 테스트, 배포를 검증하는 체계가 있고 맥락도 코드에 모여 있다. 다른 업무의 지식은 사람의 머릿속이나 문서, 접근하기 어려운 시스템에 흩어져 있다. 무엇을 개선했다고 볼지도 코드보다 명확하지 않다.

우가르테는 실행 자원이 풍부해질수록 실패 원인이 실행력 부족에서 목표와 의도를 잘못 정의한 문제로 옮겨갈 수 있다고 봤다. 그록봇 팀의 사례에서도 자동화는 출시 판단을 대신하지 않았다. 봇이 일을 수행할 조건을 만들고 맡길 범위와 좋은 결과의 기준을 정하는 일이 사람에게 남았다.