Grok Bot을 만든 제품 설계, 기능 대신 일을 끝내는 AI 동료

TL;DR

• Grok Bot은 작은 팀이 약 한 달 만에 내부 제품을 만들고 그 뒤 약 3주 동안 공개 출시를 준비했다. 기존 코딩 제품에 탭을 붙이는 대신 지식 노동자를 위한 별도 경험을 설계했다. 빠른 개발에는 작은 의사결정을 현장에서 끝내는 팀 구조가 기여했다.
• 초기 사용자 200~300명을 직접 온보딩하며 혼란과 실패를 관찰했다. 내부에서 나온 사용법도 외부 사용자에게 먼저 가르치지 않고 자연스럽게 나타나는지 확인했다. 비개발자와 소규모 사업자의 피드백이 내부 사용만으로 놓친 문제를 드러냈다.
• 핵심 설계는 클라우드에서 계속 일하며 자기 컴퓨터를 가진 장기 실행 봇이다. 사용자의 기기를 켜 두거나 세션 사이에 맥락을 복사하는 부담을 줄인다. 작업별 대화창보다 역할·기억·도구를 갖춘 동료에 가까운 사용 모델이다.
• 사용자가 원하는 것은 더 많은 버튼보다 끝난 일이다. 출시 전 기능을 줄이고 클릭·로그인처럼 전체 작업을 막는 실패를 해결했다. 마지막 일부를 사람이 계속 챙겨야 한다면 시간뿐 아니라 주의력도 여전히 묶인다.
• 경쟁력은 미래의 방어 장벽을 미리 그리는 일만으로 생기지 않는다. 지금 불가능한 일을 가능하게 만들고 모델이 발전하면 그때의 보조 장치를 다시 없애는 실행이 중요하다. 이는 개발팀의 경험적 설명이며 제품의 모든 작업에 대한 성공률 보장은 아니다.

한 달의 내부 개발과 별도 제품을 택한 이유

Roman Ugarte는 Grok Bot의 첫 코드부터 작동하는 내부 제품까지 약 한 달이 걸렸고 공개 출시까지는 그 뒤 약 3주가 더 필요했다고 설명한다. 시작은 소수 인원이 사무실의 별도 공간과 전용 Slack 채널에서 일하는 방식이었다. 매일 수많은 작은 결정을 내려야 했기 때문에 큰 조직의 장기 계획과 합의 과정을 그대로 적용하기 어려웠다. 내부 출시 뒤에는 개발팀이 아닌 다른 부서도 기존 도구 대신 이 제품을 선택하는지 확인했다.

지식 노동용 기능을 Cursor에 추가하는 선택도 검토했다. 코딩 에이전트는 비개발 업무도 수행할 수 있지만 개발자용 브랜드와 화면은 다른 직무의 사용자에게 부담이 될 수 있었다. 여러 제품의 방향을 탭으로 묶으면 사용자가 조직의 구분을 그대로 떠안는 경험이 된다는 판단도 있었다. 별도 제품으로 시작하면서 화면과 작업 흐름 전체를 새 사용자에 맞출 수 있었지만 모든 기업이 반드시 제품을 분리해야 한다는 결론은 아니다.

직접 온보딩은 교육과 동시에 제품 실험이었다

핵심 팀은 약 2주 동안 수백 명의 초기 사용자를 직접 만났다. 온보딩 통화 중 컴퓨터가 준비되지 않거나 사용자가 설정을 이해하지 못하는 상황을 함께 겪으면 다음 사람에게 같은 문제를 반복시키지 않겠다는 압력이 생겼다. 기능 요청을 문서로 전달받는 것보다 실패의 비용을 구체적으로 체감하는 방식이다. 인터뷰의 200~300명은 이 초기 온보딩 규모이며 통제된 사용자 연구의 표본이나 성공률을 뜻하지 않는다.

테스트 대상도 AI 전문가만으로 채우지 않았다. 커피숍 운영자는 Shopify 연결의 불안정함과 상품 문구 작성 같은 문제를 전달했고 이는 개발자 중심의 내부 사용과 달랐다. 범용 지식 노동 제품을 만들면서 개발자에게 익숙한 방식만 확인하면 중요한 사용자 집단을 놓칠 수 있다. 비개발자에게 어떤 작업이 막히는지를 알아내는 일이 제품 범위를 넓히는 근거가 됐다.

내부에서는 역할별로 여러 봇을 쓰다가 한 봇을 비서실장처럼 두고 다른 봇의 일을 조정하게 하는 패턴이 나타났다. 팀은 외부 사용자에게 처음부터 그 구조를 강요하지 않고 비슷한 사용법을 스스로 발견하는지 관찰했다. 실제로 같은 패턴이 나타난 뒤 조금 더 권장하는 방향으로 제품에 반영했다. 다만 모든 사용자가 같은 구조를 원하지는 않았으므로 되돌릴 수 없는 기본 사용법으로 고정하지는 않았다.

출시 전에 더한 것만큼 걷어낸 것도 많았다

초기 화면에는 개발팀이 문제를 파악하기 위한 내부 상태와 기억, 모델 동작을 살피는 기능이 섞여 있었다. 공개 출시를 준비하며 팀은 사용자가 직접 이해할 필요가 없는 요소를 줄였다. 동료에게 모든 클릭을 실시간으로 보고하라고 요구하지 않듯 봇의 도구 호출을 끝없이 보여줄 필요도 없다는 관점이다. 실제 사용자에게서는 긴 내부 동작 기록보다 할 일 목록과 우선순위 정도를 알고 싶다는 피드백이 나왔다.

우선순위를 정하는 문장도 바꿨다. 제품에 무엇이 추가됐는지보다 이제 봇이 무슨 일을 할 수 있는지로 출시 내용을 설명한다. 자동화 역시 사이드바에서 트리거와 동작을 조립하기보다 매일 특정 시각에 알려 달라고 대화로 부탁하는 방식으로 설계했다. Ugarte는 플랫폼 자동화의 99%가 이 방식으로 만들어진다고 설명하지만 집계 기간과 분모는 인터뷰에서 따로 밝히지 않는다. 핵심은 메뉴를 늘리지 않고도 사용자의 의도를 실행 가능한 작업으로 바꾸는 데 있다.

모델 점수보다 전체 업무를 막는 실패를 해결한다

팀이 출시 전 집중한 또 다른 일은 실제 업무가 끝까지 작동하도록 만드는 것이었다. 영업팀이 쓰는 도구 중에는 지원되는 API나 MCP가 부족한 경우가 있었고 에이전트는 화면을 직접 조작해야 했다. Salesforce 화면의 작은 영역을 정확히 클릭하지 못하거나 로그인이 막히면 그 앞의 단계가 아무리 잘돼도 전체 업무는 중단됐다. 이런 사례를 인프라 팀에 전달해 브라우저 정보와 화면 조작을 개선했다.

개선의 단위는 대시보드 점수만이 아니었다. 지난주 내내 실패하던 영업 업무가 오늘은 완료되는지가 훨씬 직접적인 피드백이었다. 팀은 사용자가 실제로 맡긴 작업을 모아 범주별로 진전이 있는지 확인했다. 인터뷰는 그 평가 체계의 상세한 데이터셋이나 수치를 공개하지 않지만 벤치마크 상승과 사용자가 맡길 수 있는 업무의 증가를 구분해야 한다는 제품 개발 기준은 분명하다.

채용팀의 사례도 이력서 요약에서 끝나지 않는다. 학회 사이트에서 새 논문을 내려받아 아직 추적하지 않은 공동저자를 찾고 목록에 추가한 뒤 내부 인맥과 연결해 소개를 요청하는 반복 업무가 등장한다. 후보가 현재 구직 중인지보다 해결할 문제에 가장 적합한 사람이 누구인지에서 시작한 업무다. 자동화가 맡는 것은 탐색과 정보 연결이며 사람은 후보와 관계를 만들고 합류를 설득하는 데 집중한다.

클라우드와 자기 컴퓨터가 바꾸는 사용 방식

Grok Bot 팀은 초기에 실행 환경을 클라우드에 두기로 결정했다. 사용자는 노트북을 켜 두어야 하는지, 휴대전화에서 시작한 작업이 집의 컴퓨터와 연결돼야 하는지 고민하지 않도록 설계했다. 봇이 사용자의 기기와 별개로 존재하고 어디서 접근해도 같은 상태를 이어 가는 경험을 지향한다. 두 번째로 봇에게 API뿐 아니라 직접 조작할 컴퓨터 환경도 제공하기로 결정했다.

이 구조는 사람이 쓰는 기기를 봇과 번갈아 조작하는 불편을 줄이려는 선택이다. Ugarte는 새 동료를 채용하고도 같은 노트북을 계속 함께 쓰게 하는 상황에 빗댄다. 다만 인터뷰에서 봇마다 별도 VM을 사용하는지 같은 내부 배치의 세부 사항은 확정하지 않는다. 자기 컴퓨터라는 제품 개념을 특정 가상화 구성이나 완성된 보안 보장으로 해석해서는 안 된다.

그는 OpenClaw가 모델에 필요한 도구를 주고 지속적인 동료처럼 대하는 가능성을 보여줬다고 평가한다. Grok Bot이 겨냥한 차이는 이 사용법을 일반 사용자와 기업이 쉽게 시작할 수 있는 제품으로 정리하는 데 있었다. 사용자가 skills나 슬래시 명령을 알아야 하는 부담도 줄이려 한다. 이력과 맥락은 매번 새 대화에 복사하는 대신 역할별로 오래 유지되는 봇에 쌓이며 사용자에게 드러나는 원격 컴퓨터 조작도 장기적으로 줄이려는 구상이다.

AI 동료라는 기준은 기억과 협업의 설계를 이끈다

제품 선택이 애매할 때 팀은 같은 상황에서 인간 동료에게 무엇을 원할지 묻는다. 메시지를 주고받다가 짧은 음성 대화와 화면 공유로 생각을 맞춘 뒤 다시 비동기로 일하는 경험이 한 예다. 인터뷰에서 이는 앞으로 만들고 싶은 협업 방식으로 등장하며 이미 완성된 기능이라고 단정할 수 없다. 여러 버튼을 능숙하게 다루는 사람 대신 의도를 전달하고 결과를 조정하는 사람을 중심에 두는 제품관이다.

개인 생활과 회사 업무에도 비슷한 형식이 적용될 수 있지만 데이터와 역할은 분리할 필요가 있다. Ugarte는 한 제품이 양쪽을 지원할 수 있다고 보면서도 사람들이 개인과 업무의 경계를 원한다는 점을 인정한다. 개인의 기억을 넘어 조직이 공유하는 기억과 여러 팀원이 참여하는 봇은 아직 풀어야 할 문제로 남는다. 사용 화면이 단순하다는 사실만으로 기업용 통제까지 단순해지지는 않는다.

구체적인 활용에서는 QA 봇의 컴퓨터 안에 Grok Bot 앱을 설치해 새 버전의 작업 흐름을 시험하게 하는 사례가 나온다. 결과를 Notion 문서의 과거 테스트와 비교하면 대화 도구 안에서 다시 대화만 하는 것보다 훨씬 넓은 작업을 맡길 수 있다. 또 다른 봇은 Slack·이메일·외부 제품 언급을 모아 즉시 알릴 일과 일일 요약에 넣을 일을 나눈다. 긴급 호출까지 맡기려면 오탐에 대한 신뢰가 먼저 필요하다는 조건도 붙는다.

마지막 일부를 사람이 챙기면 여전히 그 사람의 일이다

Ugarte가 대비하는 90%와 100%는 인터뷰에서 측정한 작업 성공률이 아니다. 일이 대부분 진행돼도 중간에 개입해야 할지 계속 생각하고 마지막 부분을 고쳐야 한다면 사용자의 주의력은 여전히 묶여 있다는 설명이다. 반대로 맥락을 넘긴 뒤 끝난 결과를 받는 경험은 위임의 성격 자체를 바꾼다. 제품이 지향하는 목표를 모든 업무에 대해 완전한 신뢰성이 달성됐다는 주장과 구분해야 한다.

사용자에게 주는 조언도 세밀한 설정법보다 필요한 맥락을 먼저 전달하는 데 가깝다. 이메일과 업무 도구를 연결한 뒤 어떤 일을 덜어 줄 수 있는지 제안받고 실제 가치가 있는 것부터 별도 봇에 맡기는 방식이다. 숙련된 사용자는 여러 봇이 만든 결과물을 한 저장소나 읽기 쉬운 데이터베이스에 모으는 구조를 설계할 수 있다. 접근 권한을 주는 판단과 결과를 검토하는 책임까지 자동으로 사라지는 것은 아니다.

경쟁력은 오늘의 불가능한 일을 해결하며 쌓인다

Ugarte는 Cursor가 경쟁 속에서 살아남은 이유를 기존 제품을 고집하지 않고 모델의 능력에 맞춰 방향을 바꾼 문화에서 찾는다. 모델이 못하던 일을 대신하던 인터페이스와 보조 장치는 모델이 좋아지면 걷어낼 대상이 된다. 팀 내부의 제품을 삭제한다는 표현은 이 지속적인 재설계를 뜻한다. 문제를 발견하면 허락을 기다리기보다 필요한 사람과 자원을 모아 해결한다는 실행 문화도 함께 강조한다.

방어 가능한 경쟁우위를 먼저 도식으로 그려 놓기보다 지금은 어려운 일을 가능하게 만들어 사용자가 찾아오게 하자는 주장이다. 그 과정을 반복하면 유통과 데이터, 신뢰의 이점이 생길 수 있다. 개인이 먼저 새로운 작업 방식을 경험하고 직장에서도 요구하는 확산 경로를 기대하지만 조직의 업무와 기억을 다루는 문제는 별도로 풀어야 한다. 이 대담은 제품 개발자의 경험과 방향을 설명하며 경쟁 제품 대비 성능이나 시장 지배를 독립적으로 검증한 자료는 아니다.

참고 자료

Lenny’s Podcast — How we built Grok Bot in a month

Lenny Rachitsky — 에피소드 소개와 참고 링크

영어 자동자막 전체를 바탕으로 정리하고 공식 에피소드 소개로 인명·제품명과 개발 일정을 대조했다. 소개 페이지에서 전체 유료 전사는 확보하지 못했으며 광고와 말미의 취향 문답은 본문에서 제외했다.