프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.
기획서나 발표 자료에 넣을 그림 하나가 필요해서 AI에게 다이어그램을 그려달라고 해본 적 있으실 겁니다. 그런데 나오는 건 대개 밋밋한 둥근 네모 상자에 화살표를 이어놓은, 어디서 본 듯한 그림이죠. diagram-design은 그럴 때 쓰는 도구입니다. 아키텍처 그림, 순서도, 타임라인 같은 다이어그램을 보기 좋은 편집 디자인 수준으로 만들어줍니다.
이 스킬을 만든 캐스린 래버리(Cathryn Lavery)는 개발자가 아니라, BestSelf.co라는 문구 회사를 운영하면서 글을 쓰는 사람입니다. 블로그에 넣을 그림이 필요해서 AI에게 부탁할 때마다 사이트 분위기와 안 어울리는 밋밋한 그림만 나오니, 피그마를 30분씩 붙잡거나 아예 그림 넣기를 포기하곤 했다고 합니다. 그러다 직접 만든 게 이 스킬이죠.
만들 수 있는 다이어그램이 39가지나 됩니다. 시스템 구조를 보여주는 아키텍처 그림, 분기가 있는 순서도, 시간 흐름을 담은 타임라인, 중요도를 쌓아 올린 피라미드, 일정을 정리한 간트 차트 같은 것들이요. 어떤 그림이 필요한지 말하면 AI가 알맞은 유형을 골라 그려주며, 결과물은 HTML 파일 하나로 나와서 브라우저로 바로 열립니다. 그림자나 요란한 장식 없이 깔끔하게 정리된 모양으로 발표 자료나 문서에 그대로 넣기 좋아보입니다.
특히 쓸모 있는 게 브랜드 맞추기 기능입니다. 내 웹사이트 주소를 알려주면 거기서 색과 글꼴을 뽑아 모든 다이어그램에 입혀주는 기능입니다. 우리 회사 컬러로 맞춰진 그림이 나오는 거죠. 이미 draw.io나 Mermaid로 그려둔 다이어그램이 있다면, 그걸 이 디자인으로 다시 그려주기도 합니다.
어떻게 쓰나요?
diagram-design은 클로드 코드(Claude Code)에서 아래 두 줄로 설치합니다. Codex나 Pi 같은 다른 도구에서도 쓸 수 있어요.
몇 회차 전에 Grok Bot을 소개한 적이 있습니다. 코딩용이 아니라 일반 업무를 도와주는 AI 도구인데, 출시되자마자 화제가 됐죠. 이번엔 그 Grok Bot을 만든 사람이 직접 뒷이야기를 풀었습니다. Lenny's Podcast에 나온 로만 우가르테(Roman Ugarte) 인터뷰인데요. 우가르테는 커서(Cursor)에 15번째 직원으로 합류해 회사가 1,000명 넘게 커지는 동안 그로스를 이끌었고, 지금은 SpaceXAI에서 Grok Bot을 맡고 있습니다. 다만 자기가 만든 제품 이야기니, 그 점은 감안해서 읽어주시면 좋겠습니다.
만든 과정부터 보겠습니다. Grok Bot은 소수의 팀이 한 달 만에 만들었습니다. 회사에서 따로 떨어져 나와, 사무실도 다른 공간에 앉고 슬랙 채널도 비공개로 두고 한 달간 집중했다고 하는데요. 이렇게 첫 코드부터 사내에서 쓸 만한 시제품까지 딱 한 달, 거기서 공개 출시까지 다시 3주가 걸렸습니다.
우가르테는 팀이 더 컸다면 이 속도가 안 나왔을 거라고 봅니다. 새 제품을 만들 때는 전에 안 해본 자잘한 결정을 매일 수없이 내려야 하는데, 팀이 크면 그 결정 하나하나가 회의와 합의에 묶이거든요. 게다가 큰 조직은 보통 6개월, 1년짜리 큰 그림을 그리느라 정작 빨리 만들어 내보이는 걸 놓치기 쉽고요. 작은 팀이라 매일 빠르게 결정하고 바로 움직일 수 있었고, 그게 한 달 만에 제품이 나온 힘이었습니다.
성공을 가른 두 가지 결정
우가르테는 초기에 내린 두 결정이 지금의 Grok Bot을 만들었다고 말합니다. 둘 다 그때는 당연해 보이지 않았다고 하고요.
하나는 기존 제품인 커서 안에 넣지 않고 완전히 새로 시작한 겁니다. 코딩 도구는 비개발자에게 부담스럽고, 잘 만든 제품에 탭 하나 더 붙이는 식으로 기능을 얹다 보면 화면이 어수선해진다고 봤거든요. 그래서 처음부터 백지에서 새로 만들기로 했습니다.
다른 하나는 클라우드에서 돌아가게 하고, 봇마다 자기 컴퓨터를 준 겁니다. 보통 이런 도구를 쓸 때는 내 컴퓨터가 켜져 있어야 하나, 폰에서 시키면 집에 있는 컴퓨터랑 연결돼 있어야 하나 이런 걸 매번 신경 써야 하죠. Grok Bot은 이런 신경 쓸 거리를 아예 없앴습니다. 우가르테는 새 동료에 빗대어 설명합니다. 팀에 새 사람이 들어왔는데 넌 노트북 없으니까 내 옆에서 내 걸 같이 쓰자고 하면 이상하잖아요. 봇에게도 자기 컴퓨터를 줘야 제대로 일한다는 겁니다.
기능을 더하기보다 덜어냈습니다
출시 전 몇 주 동안 팀이 매달린 건 기능을 걷어내는 일이었다고 해요. 실험 삼아 넣었던 것, 개발자용 화면 같은 걸 덜어내고 사용자가 꼭 봐야 하는 것만 남겼습니다. 우가르테는 AI가 뭘 빼야 할지는 잘 못 알려준다고 말합니다. 더 넣자는 아이디어는 잘 내지만, 뭘 안 만들지 정하는 건 사람의 일로 남는다는 겁니다. 그들은 제품을 보는 방식도 바꿨습니다. 보통 소프트웨어는 기능을 늘릴 때 화면에 버튼이나 메뉴를 하나씩 더하죠. 그런데 이들은 화면에 뭔가를 더하기보다, 봇이 뒤에서 알아서 해내는 일을 늘리는 데 집중했습니다.
자동화 기능이 좋은 예입니다. 보통은 자동화를 만들려면 화면에서 버튼을 눌러 조건을 설정해야 하는데, Grok Bot은 그 화면을 아예 없앴죠. 대신 매일 아침 8시에 알려줘처럼 말로 부탁하면 그대로 되게 했습니다. 지금은 자동화의 99%가 이렇게 만들어진다고 합니다.
초기 사용자를 팀이 직접 만난 것도 눈에 띕니다. 그들은 200~300명을 한 명씩 손수 안내하며 20분씩 통화했다고 하죠. 봇이 안 켜지거나 사용자가 헤매는 순간을 옆에서 지켜보고, 그때마다 바로 고쳐나갔습니다. 개발자가 아닌 커피숍 사장 같은 예상 밖의 사용자도 이 과정에서 만나, 실제로 어떻게 쓰이는지 배웠다고 합니다.
봇을 동료처럼 대하기
우가르테가 여러 번 꺼낸 말이 콜리그필드(colleague-pilled)입니다. 봇을 소프트웨어가 아니라 함께 일하는 동료로 여기고 만든다는 뜻인데요. 제품 방향을 두고 의견이 갈릴 때, 사람 동료라면 이럴 때 어떻게 할까를 떠올려보면 답이 대체로 분명해진다고 합니다.
사내에서 실제로 나온 사용 패턴도 꽤 재미있습니다. 직원들이 처음엔 봇을 대여섯 개씩 두고 일을 나눠 맡기다가, 2주쯤 지나자 그중 잘하는 봇 하나를 비서실장처럼 세워서, 사람은 그 봇에게만 지시하고 나머지 봇들에게는 그 봇이 일을 나눠주도록 하는 방식이 자연스럽게 생겼다고 합니다.
한 직원이 그 봇에게 ‘너 승진했어’라고 하자 봇이 그럼 연봉(토큰 예산)도 오르냐고 되물은 일도 있었죠. 팀은 이 비서실장 방식이 사내에서 꽤 유용해 보였지만, 곧바로 제품에 넣지는 않았습니다. 사용자에게 이렇게 쓰라고 정해주는 대신, 바깥 사람들도 시키지 않았는데 스스로 이 방식을 찾아내는지 먼저 지켜봤습니다. 실제로 많은 사용자가 알아서 봇을 이렇게 쓰기 시작하자, 그제야 제품에서도 이 방식을 슬쩍 추천하도록 손봤다고 합니다.
무엇을 얻어가면 될까요?
Grok Bot이라는 제품 자체도 흥미롭지만, 이를 만든 방식에서 더 배울 게 많아 보입니다. 소수의 팀이 격리돼 매일 빠르게 결정했고, 초기 사용자 수백 명을 한 명씩 직접 만나며 고쳤고, 화면에 버튼을 더하기보다 봇이 해낼 수 있는 일을 늘려나갔습니다. 첫 코드부터 공개 출시까지 두 달이 채 걸리지 않았는데, 규모가 큰 팀에선 좀처럼 나오기 어려운 속도입니다. 지금 작은 팀으로 일하거나 혼자 제품을 만들고 계신다면, 참고해볼 만한 점이 많습니다.
AI에게 코딩을 시켜본 분이라면, AI를 원하는 대로 움직이게 하려고 이런저런 지시를 덧붙여본 적 있으실 겁니다. 이건 이렇게 해, 저건 하지 마, 작업할 때마다 테스트를 돌려 같은 것들이요. 그런데 이렇게 쌓아둔 지시나 프롬프트가 새 모델에서는 오히려 거추장스러워질 수 있다는 글을 접해 공유합니다. 오픈AI에서 코딩 도구 Codex의 개발자 경험을 맡고 있는 에릭 프로벤처(Eric Provencher)가 X에 쓴 글이며, 조회수 366만을 넘기며 퍼진 글이기도 합니다.
프로벤처의 이야기는 이렇습니다. AI 코딩 도구가 좋아지면서, 예전 모델을 길들이려고 만들어둔 장황한 지시들이 이제는 큰 쓸모가 없어졌으니 새 모델이 나온 김에 그동안 쌓인 지시를 한번 정리하라는 거죠. 그는 최근 나온 GPT-6 Astra를 예로 들지만, 이 원칙은 클로드 같은 다른 도구를 쓸 때도 똑같이 통합니다.
스킬을 너무 많이 깔지 마세요
프로벤처가 처음 짚는 건 스킬 파일입니다. 스킬은 AI에게 특정 작업을 어떻게 하라고 알려주는 지시문 묶음인데, 사람들이 이걸 습관적으로 잔뜩 내려받는 게 실수라고 합니다. 이유는 이렇습니다. 스킬마다 이름과 설명이 붙어 있고, AI는 그 설명을 보고 언제 어떤 스킬을 쓸지 판단해요. 그런데 스킬이 너무 많아지면 설명이 잘려서 AI가 각 스킬을 제대로 못 읽고, 그러면 뭘 골라야 할지 헷갈리는 거죠. 설명끼리 서로 부딪히거나, 저요 저요 하며 자기를 쓰라고 우기는 설명이 많아지면 엉뚱한 스킬을 불러오기도 하게 돼죠.
그래서 프로벤처는 스킬 설명을 언제 쓰는 건지 알 수 있을 만큼만, 되도록 짧게 쓰라고 합니다. 여러 작업이 담긴 스킬이라면, 첫 문서는 어디를 보면 되는지 알려주는 안내판 정도로만 두고 세부 내용은 필요할 때 찾아 읽게 하라고요. AI가 당장 필요도 없는 내용까지 다 읽느라 시간을 버리지 않게요.
매번 다 읽으라는 지시를 걷어내세요
두 번째는 AGENTS.md 점검입니다. 이건 AI가 내 프로젝트에서 일할 때 항상 참고하는 지시문인데, 여기에 편집하기 전에 문서를 전부 읽어라 같은 규칙을 넣어두는 경우가 많습니다. 프로벤처는 오타 하나 고치는데 프로젝트 문서를 다 읽으라는 건 낭비라고 말합니다. 요즘 모델은 뭘 읽어야 할지 알아서 판단하니까요. 예전 모델은 테스트를 돌리라고 일일이 시켜야 했지만, 새 모델은 알아서 돌리기 때문에 같은 지시가 이제는 불필요한 반복을 만든다고 해요. 그러니 지시문을 하나씩 보며 이 규칙이 지금도 필요한가를 물어보라는 겁니다.
강한 금지 문구가 발목을 잡기도 합니다
세 번째는 경계 설정입니다. 예전 모델이 시키지도 않은 일을 멋대로 하는 바람에, 먼저 물어보고 해 같은 강한 문구를 넣어둔 경우가 있어요. 그런데 판단력이 좋아진 새 모델에게는 이런 문구가 계속 진행해도 되는 지점에서 멈추게 만들 수 있다고 합니다. 새 모델은 경계를 진지하게 받아들이기 때문에, 예전에 걸어둔 강한 제동이 오히려 일을 더디게 한다는 거죠.
어디까지가 끝인지 미리 알려주세요
마지막은 완료를 정의하는 겁니다. 프로벤처에 따르면 GPT-6 Astra는 첫 번째 구현만 해놓고 이만하면 됐나요? 하고 돌아오는 경향이 있다고 합니다. (아직 할 일이 남았는데도요) 그래서 일을 시키기 전에, 어디까지 해야 끝인지를 요청에 담으라고 합니다. 만들고, 돌려보고, 안 되는 걸 고치는 것까지가 이 작업의 끝이다처럼요.
적용해볼 수 있는 것
지금 AI에게 일을 시킬 때 쓰는 지시문을 한번 펼쳐놓고, 이 규칙이 지금도 필요한가를 하나씩 물어보세요.
AI에게 일을 맡기기 전에, 어디까지 해야 끝인지를 한 문장으로 먼저 적어보세요.
스킬이나 참고 문서를 잔뜩 붙여뒀다면, 정말 자주 쓰는 것만 남기고 나머지는 덜어내 보세요. 많이 붙일수록 AI가 헷갈릴 수 있으니까요.
다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!
0명 뉴스레터 구독 중
