요즘IT » 프로덕트 » 피드

YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: GPT-5.5 Instant - 어제와 다른 오늘의 ChatGPT
참고할 것: YouMind - X에서 화제인 AI 프롬프트를 실시간으로 모아보는 곳
적용해볼 것: YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지 (내용이 좀 깁니다)

<출처: openai>

1. 써볼 것: GPT-5.5 Instant - 어제와 다른 오늘의 ChatGPT

GPT-5.5 Instant는 OpenAI가 5월 5일에 ChatGPT의 기본 모델로 교체한 새 모델입니다. 기본 모델이라는 건, ChatGPT를 열었을 때 따로 뭘 고르지 않아도 자동으로 대화하게 되는 그 모델을 말합니다. 교체 직후부터 답변이 짧아졌다, 이모지가 줄었다는 반응들이 나왔는데요. OpenAI에 따르면 의료·법률·금융 같은 민감한 주제에서 할루시네이션이 52.5% 줄었고, 과거 대화와 파일에서 맥락을 끌어오는 Memory Sources라는 기능이 함께 추가됐습니다.

무슨 문제를 해결해 주나요?

GPT-5.5 Instant는 기존 ChatGPT를 쓰면서 반복적으로 겪던 불편함 세 가지를 건드린 업데이트입니다.

지어내는 문제: AI가 그럴듯하게 틀린 정보를 내놓는 할루시네이션은 ChatGPT의 오래된 약점이었습니다. GPT-5.5 Instant는 내부 테스트 기준으로, 의료·법률·금융처럼 틀리면 안 되는 주제에서 할루시네이션이 52.5% 줄었다고 합니다. 사용자들이 직접 사실 오류로 신고한 대화에서도 부정확한 답변이 37.3% 감소했고요. 눈에 띄는 변화 하나는 실시간 자기 교정인데요. 이전 모델은 수학 문제 같은 걸 풀다 틀려도 자신 있게 밀어붙였다면, 이제는 중간에 스스로 틀린 걸 알아채고 다시 풀어봅니다.
장황한 답변: 같은 질문에 대해 이전 모델보다 단어 수가 약 30% 줄었습니다. 굳이 안 해도 되는 후속 질문, 반복되는 서식, 과한 이모지가 빠졌고요. 2개월 전 GPT-5.3 Instant를 내놓으면서 오글거리는 톤을 줄이겠다고 했는데, 이번에는 거기서 한 발 더 나아가서 간결함 자체를 전면에 내세우고 있습니다.
매번 맥락을 새로 설명해야 하는 문제: Memory Sources라는 기능이 추가됐습니다. ChatGPT가 이전 대화 내용, 업로드한 파일, 연결된 Gmail 계정에서 맥락을 끌어와서 답변에 반영할 수 있게 된 건데요. 예를 들어 지난주에 마케팅 전략 관련으로 긴 대화를 했다면, 이번 주에 새 대화를 시작해도 그 내용을 참고합니다. ChatGPT가 어떤 과거 대화나 파일을 참고했는지 확인할 수도 있고, 잘못된 정보는 삭제하거나 수정할 수 있습니다. 다만 이 기능은 현재 Plus와 Pro 유료 사용자의 웹 버전에서만 쓸 수 있고, 무료 사용자와 모바일은 순차 확대 예정입니다.

어떻게 쓰나요?

사용을 위해 따로 설정할 건 없습니다. ChatGPT를 열면 이미 GPT-5.5 Instant로 바뀌어 있을테니까요. Memory Sources를 쓰고 싶다면 설정에서 메모리 기능이 켜져 있는지 확인하면 되고요. 누군가에게 채팅을 공유해도 메모리 소스는 상대방에게 보이지 않습니다.

이전 모델인 GPT-5.3 Instant는 유료 사용자에 한해 3개월간 유지됩니다. 설정에서 모델을 직접 선택하면 쓸 수 있고, 3개월 뒤에는 완전히 퇴장할 예정입니다. 참고로 OpenAI는 작년에 GPT-4o를 없앴을 때 상당한 반발을 겪은 적이 있습니다. 당시 사용자들이 청원까지 올렸지만, 결국 올해 2월에 폐지됐고요. 이번에도 약 2개월 주기로 기본 모델을 교체하는 패턴이 이어지고 있어서, 특정 모델에 워크플로를 맞춰놓은 사람이라면 이 주기를 염두에 둘 필요가 있습니다. API로 ChatGPT를 연동해 쓰는 개발자라면, GPT-5.5 Instant가 chat-latest라는 이름으로 API에도 올라가 있으니 확인해보세요.

+ 보너스: Claude Code 한도가 2배로 늘었습니다

같은 주에 Anthropic에게도 변화가 있었는데요. SpaceX의 Colossus 1 데이터센터 전체 용량을 사용하는 계약을 맺고, Claude Code와 API 한도를 대폭 상향시켰다는 내용입니다. 5월 6일부터 적용된 변경 사항은 세 가지입니다.

Claude Code의 5시간 기준 사용 한도가 Pro, Max, Team, Enterprise 플랜에서 2배로 늘었습니다.
Pro와 Max 사용자에게 적용되던 피크 시간대 한도 축소가 사라졌습니다.
API에서는 Opus 모델의 요청 한도가 상향되었습니다.

<출처: youmind>

2. 참고할 것: X에서 화제인 AI 프롬프트를 실시간으로 모아보는 곳

YouMind는 X(Twitter)에서 화제가 되는 AI 프롬프트를 매일 추적해서 모델별로 정리해주는 프롬프트 라이브러리입니다. 이미지, 비디오, 웹페이지 생성 프롬프트가 중심이고, GPT Image 2, Nano Banana Pro, Seedance 2.0, Gemini 3 Pro 등 주요 모델별로 분류되어 있습니다. 현재 2만 개 이상의 프롬프트가 모여 있고, X에서 반응이 좋은 프롬프트를 골라서 하루 두 번 자동으로 업데이트하는 구조입니다.

기존 프롬프트 모음집과 무엇이 다른가요?

한동안 프롬프트 템플릿 모음집이 유행했습니다. 용도별로 잘 정리된 프롬프트를 모아놓고, 필요할 때 복사해서 쓰는 방식이었죠. 그런데 요즘은 AI 모델의 버전이 빠르게 바뀌고, 새로운 기법이 거의 매일 나오다시피 합니다. 몇 달 전에 잘 되던 프롬프트가 모델 업데이트 하나로 잘 안 먹히기도 하고, 반대로 새 모델에서만 가능한 기법이 갑자기 등장하기도 하죠.

YouMind는 지금 이 순간 X에서 사람들이 공유하고 반응하고 있는 프롬프트를 계속 수집합니다. 사이트에는 지난 7일간 가장 영향력 있는 프롬프트라는 섹션이 있어, 최근 관심 받고 있는 프롬프트가 무엇인지 빠르게 트렌드를 확인할 수도 있습니다.

어떻게 작동하나요?

YouMind의 프롬프트는 대부분 X의 공개 게시물에서 수집됩니다. AI로 이미지나 비디오를 만들어서 올린 사람들의 게시물 중에서, 반응이 좋고 결과물이 괜찮은 것들을 골라서 프롬프트와 생성 결과물을 함께 보여주는 구조입니다.

사용 방식은 단순합니다. 모델별 페이지에서 프롬프트를 둘러보고, 마음에 드는 걸 복사해서 해당 모델에 그대로 붙여넣으면 됩니다. YouMind 자체에서 모델을 선택해 바로 실행할 수도 있고요. 각 프롬프트에는 실제 생성된 이미지나 비디오가 샘플로 붙어 있어서, 결과물을 미리 확인하고 고를 수 있습니다.

개발자라면 오픈소스 스킬도 참고할 만합니다. Claude Code, OpenClaw, Cursor 같은 AI 어시스턴트에 YouMind의 프롬프트 라이브러리를 연결하는 스킬이 GitHub에 공개되어 있어요. 사이버펑크 스타일 아바타 프롬프트 찾아줘라고 말하면 1만 개 중에서 맞는 걸 3개 골라서 샘플 이미지와 함께 보여주는 식입니다.

무엇을 얻어가야 하나요?

YouMind는 이미지 / 비디오 생성 프롬프트 도구로만 사용해도 충분히 유용하지만, 더 유용하게 쓰고 싶다면 실사용자의 흐름을 살펴보시길 추천드립니다. 지금 어떤 모델의 어떤 기법이 화제인지, 사람들이 AI 이미지 생성을 어떤 용도로 쓰고 있는지, 일주일 단위로 트렌드가 어떻게 바뀌는지를 한눈에 볼 수 있기 때문입니다. 예를 들어 지금은 GPT Image 2로 일부러 MS 그림판 스타일의 조잡한 이미지를 만드는 프롬프트가 X에서 500만 뷰 이상을 기록하며 유행하고 있는데, 이런 흐름을 빠르게 잡을 수 있습니다.

<출처: 작가, ChatGPT 제작>

무료이고, 별도 가입 없이 프롬프트를 복사해서 쓸 수 있습니다
이미지·비디오 생성 프롬프트가 중심이며, AI로 시각적 결과물을 만드는 사람에게 유용합니다
프롬프트 자체보다 지금 사람들이 AI를 어떻게 활용하고 있는지, 그 흐름을 보는 도구로 쓰면 더 유용합니다

<출처: ycombinator>

3. 적용해볼 것: YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지

Y Combinator가 2026년 여름 배치를 앞두고 Request for Startups(RFS)를 공개했습니다. RFS는 YC가 창업자들에게 이런 분야에 도전해봤으면 좋겠다고 공개적으로 밝히는 일종의 관심 목록인데요. 보통 반기에 한 번씩 나오고, 3개월 전 봄 배치에서는 8개 분야를 제시했습니다.

이번 여름 목록은 봄의 거의 두 배인 15개입니다. 그리고 방향이 많이 달라졌습니다. 봄에는 AI 에이전시, AI PM 도구, 스테이블코인처럼 소프트웨어만으로 시작할 수 있는 아이디어가 중심이었는데, 이번에는 농업 로봇, 드론 방어 시스템, 우주용 칩, 반도체 공급망까지 포함되어 있으며, YC 역사상 가장 하드테크 쪽으로 기울어진 목록이라는 평가도 나오고 있습니다.

무슨 문제를 해결하려 하나요?

AI 도구가 쏟아지고 있지만, 대부분은 기존 업무를 돕는 수준에 머물러 있습니다. YC가 이번 RFS에서 찾는 건 그 다음 단계예요. AI로 기존 산업의 구조 자체를 바꾸거나, AI 시대에 새로 필요해진 인프라를 만드는 스타트업입니다. 15개를 하나씩 보면 흩어져 보이지만, 묶어서 보면 몇 가지 방향이 보입니다. 프로덕트 메이커와 가까운 영역부터 정리하겠습니다.

YC가 공개한 15가지

소프트웨어가 다시 만들어지는 영역

SaaS 챌린저:AI 코딩으로 소프트웨어 생산 비용이 10~100배 줄면서, 수십 년간 수백만 줄의 코드로 쌓아온 레거시 SaaS의 진입 장벽이 무너지고 있다는 게 YC의 판단입니다. 기존 제품을 복제해서 1/10 가격에 파는 것, AI 네이티브로 워크플로를 처음부터 다시 설계하는 것, 여러 포인트 솔루션을 하나로 묶는 것, 고가 제품의 오픈소스 대안을 만들고 서비스로 수익을 내는 것 등 공격 방법도 여러 가지를 제시하고 있습니다. YC가 특히 강조하는 건, 프로젝트 관리 같은 쉬운 타겟이 아니라 칩 설계 소프트웨어, ERP, 산업 제어 시스템처럼 수십 년간 건드리기 어려웠던 영역을 노리라는 겁니다.
에이전트를 위한 소프트웨어: 인터넷의 다음 1조 사용자는 사람이 아니라 AI 에이전트라는 관점입니다. 지금 에이전트는 사람이 쓰도록 만든 소프트웨어 위에서 버튼을 클릭하며 느리게 동작하고 있는데, 에이전트에게 필요한 건 폼이나 대시보드 같은 시각적 인터페이스가 아니라 API, MCP, CLI 같은 기계가 읽을 수 있는 인터페이스입니다. 기존 소프트웨어의 모든 카테고리가 에이전트를 위해 다시 만들어져야 하고, 이건 기존 기업이 에이전트 지원을 추가하는 방식이 아니라 처음부터 에이전트를 중심에 놓고 설계하는 스타트업에서 나올 거라고 보고 있습니다.
동적 소프트웨어 인터페이스: 지금 소프트웨어는 모든 사용자에게 같은 화면을 보여줍니다. Netflix조차 추천 콘텐츠는 달라도 레이아웃 자체는 똑같죠. YC는 코딩 에이전트가 사용자 개인에 맞게 인터페이스를 바꿔주는 미래를 보고 있는데요. 같은 이메일 앱이 한 사용자에게는 할 일 목록으로, 학생에게는 일정 캘린더로 보이는 식입니다. 이걸 실현하려면 소프트웨어를 전달하는 방식 자체가 바뀌어야 해서, 프론트엔드만 바꿀 수 있게 할 건지 소스 코드를 통째로 열 건지 같은 문제가 남아 있습니다.

AI가 서비스와 기업 운영을 바꾸는 영역

AI 네이티브 서비스 기업: 2023~2025년 대부분의 AI 스타트업이 사람의 업무를 돕는 도구를 만들었다면, 다음 단계는 소프트웨어가 아니라 서비스 자체를 파는 AI 기업이라는 겁니다. 서비스 시장의 총 지출이 소프트웨어 시장보다 몇 배 크고, 이미 외부에 맡기고 있는 업무가 많기 때문에 AI로 대체하기가 오히려 쉽다는 논리입니다. YC가 특히 관심을 보이는 분야는 보험 중개, 회계·세무·감사, 컴플라이언스, 의료 행정입니다.
Company Brain: AI 자동화의 가장 큰 장벽이 모델 성능에서 도메인 지식으로 옮겨가고 있다는 관찰입니다. 기업마다 환불을 어떻게 처리하는지, 가격 예외를 어떻게 결정하는지, 장애 대응을 어떻게 하는지 같은 핵심 노하우가 있는데, 이게 이메일, 슬랙, 지원 티켓, 데이터베이스 등에 흩어져 있습니다. 이걸 한곳에 모아서 AI가 실행할 수 있는 형태로 정리하는 것, 그러니까 기업 운영 방식의 살아 있는 지도를 만드는 게 Company Brain이라는 아이디어입니다.
기업용 AI 운영 체제: 모든 회의를 녹화하고, 모든 티켓을 추적하고, 모든 고객 상호작용을 기록해서 기업 전체를 검색 가능하게 만드는 겁니다. YC에 따르면 이걸 적용한 팀은 스프린트 시간을 절반으로 줄이고 출시량을 두 배로 늘렸다고 합니다. 현재는 Slack, Linear, GitHub, Notion 등을 커스텀 코드로 일일이 연결해야 하는데, 이걸 하나의 레이어로 통합하는 제품이 아직 없다는 게 YC의 관찰입니다.

하드웨어, 인프라, 특화 산업

나머지 아이디어들은 프로덕트 메이커의 일상 업무와는 거리가 있지만, AI가 소프트웨어를 넘어 어디까지 확장되고 있는지를 보여줍니다.

에이전트 워크플로우용 추론 칩: 현재 AI 칩은 프롬프트를 넣으면 응답이 나오는 방식에 맞춰 설계되어 있는데, 에이전트는 도구를 호출하고 분기하고 역추적하는 루프 구조로 동작합니다. 현재 GPU는 이런 작업에서 활용률이 30~40% 수준이라고 합니다. 에이전트의 작동 방식에 맞는 칩을 새로 설계해야 한다는 아이디어입니다.
반도체 공급망 2.0: AI 칩 하나가 약 1,400개 공정 단계를 거치고 12개국 이상을 경유하는데, 이 공급망이 아직도 스프레드시트와 전화로 관리되고 있다는 문제의식입니다. 실시간 추적, 리스크 모니터링, 수출 규제 대응 같은 기본적인 도구가 거의 없는 상태라고 합니다.
하드웨어 공급망: 중국 선전에서는 부품 설계부터 제작까지 하루면 되지만 미국에서는 같은 과정에 수 주가 걸립니다. 이 격차를 줄이는 스타트업에 관심을 보이고 있습니다.
우주 전자부품: SpaceX의 재사용 로켓으로 우주에 물건을 보내는 용량이 크게 늘면서, 우주 환경에 맞게 질량·열·방사선을 최적화한 추론 칩 시장이 열리고 있다는 아이디어입니다.
우주 산업 역량: 달 표면의 레골리스에서 실리콘, 알루미늄, 철, 티타늄 같은 원자재를 추출하고, 이를 3D 프린팅으로 구조물을 만드는 방향입니다. 달에서는 중력이 약해 지지 구조물이 필요 없어서 지구보다 오히려 효율적일 수 있다고 합니다.
AI 기반 저농약 농업: AI가 개별 잡초와 해충을 실시간으로 식별하고, 로보틱스가 밭 전체가 아닌 식물 단위로 정밀 처리해서 농약 사용을 90%까지 줄이는 방향입니다.
AI 맞춤형 의료: 유전체 시퀀싱 비용이 급격히 하락하면서, 환자 개인에 맞춘 진단과 치료가 가능해지고 있다는 관점입니다.
대드론 군집 방어: 패트리어트 미사일 한 발이 300만 달러인데 FPV 드론 한 대는 500달러입니다. 비용이 완전히 공격자 쪽으로 기울어 있는 상황에서, YC는 이 문제가 무기 운용보다 실시간 분산 시스템 운영에 가깝다고 보고 있습니다.

시장 접근 방식의 변화

거대 기업에 판매하고 싶은 스타트업: 기존에는 스타트업이 스타트업에게 파는 게 정석이었지만, AI 이후로 Fortune 100 규모의 기업에도 바로 접근할 수 있게 됐다는 관찰입니다. YC에 따르면 최근 3년간 배치 중이거나 첫해에 수백만 달러 규모 계약을 체결한 사례가 나오고 있고, 2~3명 팀이 법인 설립 전에 Fortune 10 기업이 쓰는 제품을 출시한 경우도 있다고 합니다.

15가지가 공통으로 가리키는 것

15개 아이디어를 관통하는 방향이 몇 가지 보입니다.

첫 번째는 AI가 기능에서 기반으로 바뀌고 있다는 것입니다. 2023~2025년의 AI 스타트업이 기존 제품에 AI를 얹는 방식이었다면, YC가 지금 찾는 건 AI 위에서 서비스, 소프트웨어, 하드웨어를 처음부터 다시 만드는 기업입니다.
두 번째는 에이전트가 새로운 사용자라는 것입니다. 에이전트를 위한 소프트웨어, 에이전트용 추론 칩, 동적 인터페이스 모두 같은 전제 위에 있습니다. 소프트웨어의 사용자가 사람만이 아니게 되면, 인터페이스부터 인프라까지 다시 설계해야 한다는 거죠.
세 번째는 레거시를 교체하는 것이 가장 큰 기회라는 것입니다. SaaS 챌린저, 반도체 공급망, 하드웨어 공급망 모두 수십 년간 바뀌지 않았던 것들입니다. AI가 소프트웨어 생산 비용을 크게 줄이면서, 이전에는 규모 때문에 건드릴 수 없었던 영역이 열리고 있습니다.

적용을 위해 실행해볼 수 있는 것

지금 내가 만들고 있는 제품이 사람을 돕는 도구인지, 서비스 자체를 대체하는 것인지 구분해보기. YC는 도구의 다음 단계가 서비스라고 보고 있습니다.
내 제품의 사용자가 사람만인지, 에이전트도 쓸 수 있는 구조인지 점검해보기. API, MCP, CLI 같은 기계용 인터페이스가 있는지 확인하는 것부터 시작할 수 있습니다.
내가 속한 산업에서 수십 년간 바뀌지 않은 소프트웨어가 뭔지 떠올려보기. 그게 아직도 스프레드시트로 관리되고 있다면 기회일 수 있습니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

DESIGN.md: 파일 하나로 Apple 디자인 시스템을 적용하는 법

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: DESIGN.md + getdesign.md - AI에게 우리 디자인 규칙을 알려주는 파일
참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준
적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

<출처: getdesign.md>

1. 써볼 것: AI에게 우리 디자인 규칙을 알려주는 파일

DESIGN.md는 Google이 자사 디자인 도구 Stitch에서 만들어 오픈소스로 공개한 마크다운 파일 규격입니다. 4월 21일 Apache 2.0 라이선스로 공개되자마자 개발자 커뮤니티에서 큰 반응을 얻었는데요. 공식 GitHub 레포는 공개 72시간 만에 스타 5,000개를 넘겼고, 커뮤니티에서 이 규격을 활용해 만든 awesome-design-md 레포는 한 달 만에 스타 6.8만 개를 돌파했습니다.

프로젝트 루트에 DESIGN.md 파일을 넣어두면, AI 코딩 에이전트가 그 파일을 읽고 우리 브랜드에 맞는 UI를 만들어주는 방식입니다. 매번 색상 코드, 폰트, 간격 규칙을 프롬프트로 설명하지 않아도 되죠.

무슨 문제를 해결해 주나요?

Claude Code, Cursor, Copilot 같은 AI 코딩 에이전트로 UI를 만들어본 적이 있다면 이런 경험이 있을 겁니다. 기능적으로는 잘 작동하는데, 결과물이 어딘가 범용적이에요. 우리 브랜드 색상도 아니고, 폰트도 다르고, 버튼 모양도 우리 제품과 안 맞죠. 그래서 매번 프롬프트에 이렇게 써야 합니다. 우리 메인 색상은 #1A73E8이고, 본문 폰트는 Inter 16px, 버튼은 border-radius 8px로 해줘. 프로젝트를 새로 열 때마다, 대화가 길어질 때마다 이걸 반복해야 하고요.

DESIGN.md는 이 반복을 없앱니다. README.md가 프로젝트를 사람에게 설명하듯, DESIGN.md는 디자인 시스템을 AI 에이전트에게 설명하는 파일입니다. 한 번 만들어 프로젝트 루트에 넣어두면, 에이전트가 매 작업마다 이 파일을 자동으로 읽고 반영하죠.

우선, 파일 구조는 두 부분으로 나뉩니다. 앞쪽에 YAML로 정확한 디자인 토큰 값(색상 코드, 폰트 크기, 간격 등)을 적고, 뒤쪽에 마크다운으로 그 값들이 왜 존재하는지, 어떤 맥락에서 써야 하는지를 설명합니다. 토큰은 에이전트에게 정확한 숫자를 주고, 마크다운 설명은 그 숫자를 언제 어떻게 쓸지 판단하게 해주는 구조입니다.

어떻게 쓰나요?

DESIGN.md를 만드는 방법은 세 가지입니다.

방법 1. Google Stitch에서 자동 생성하기

가장 쉬운 방법입니다. stitch.withgoogle.com에 접속해서 프로젝트를 만들거나 기존 디자인을 가져오면, Stitch가 디자인 시스템을 분석해서 DESIGN.md를 자동으로 생성해줍니다. 기존 웹사이트 URL만 넣어도 그 사이트의 디자인 규칙을 추출할 수 있고요. Stitch는 무료이고, 구글 계정만 있으면 월 550회까지 생성할 수 있습니다.

방법 2. getdesign.md에서 브랜드 디자인 시스템 가져오기

여기가 사실상 우리에게 가장 실용적인 부분일 수 있는데요. VoltAgent라는 팀이 만든 getdesign.md에 가면, Apple, Notion, Figma, Spotify, Vercel 등 70개 브랜드의 DESIGN.md 파일이 정리되어 있습니다. GitHub의 awesome-design-md 레포에서도 같은 파일들을 받을 수 있고요. (링크는 아래에 모아두었습니다)

사용법은 간단합니다. 마음에 드는 브랜드의 DESIGN.md 파일을 다운로드하고, 내 프로젝트 루트에 넣은 뒤, AI 코딩 에이전트에게 작업을 시키면 됩니다. 예를 들어 핀터레스트(Pinterest)의 DESIGN.md를 넣고 이미지 갤러리 페이지를 만들어달라고 하면, 핀터레스트 특유의 둥근 모서리와 깔끔한 카드 레이아웃이 적용된 결과물이 나오는 식이죠.

<출처: getdesign.md>

물론 이 파일들은 해당 브랜드의 공개된 CSS 값을 기반으로 추출한 것이라, 그대로 쓰기보다는 출발점으로 활용하는 게 좋습니다. 마음에 드는 브랜드의 파일을 기반으로 색상과 폰트를 내 브랜드에 맞게 수정하면 됩니다. 마크다운 파일이니까 아무 텍스트 에디터에서 편집할 수 있고요.

방법 3. 직접 작성하기

이미 디자인 시스템이 잡혀 있는 팀이라면 직접 쓰는 것도 어렵지 않습니다. Figma에 정리된 디자인 토큰이나 Tailwind 설정 파일이 있다면, 그 값들을 DESIGN.md 포맷으로 옮기면 됩니다. 공식 스펙 문서가 GitHub에 공개되어 있고, 공식 스펙 문서가 GitHub에 공개되어 있고, CLI 도구도 함께 제공됩니다. 터미널에서 명령어 한 줄로 파일이 제대로 작성됐는지 검증할 수 있고, WCAG 접근성 기준에 맞는지까지 자동으로 확인 받을 수 있습니다.

어떤 에이전트에서 쓸 수 있나요?

DESIGN.md는 마크다운 파일이기 때문에 특정 도구에 종속되지 않습니다. 프로젝트 파일을 읽을 수 있는 에이전트라면 어디서든 작동합니다. 현재 Claude Code, Cursor, GitHub Copilot, Kiro, Windsurf, 그리고 Google Stitch에서 호환이 확인됐고요. 별도 플러그인이나 설정 없이, 프로젝트 루트에 파일만 넣으면 됩니다.

누구에게 좋을까요?

AI 코딩 에이전트로 UI를 자주 만드는데, 매번 디자인을 설명하는 게 번거로운 사람
디자이너 없이 사이드 프로젝트를 진행하면서, 그래도 일관된 디자인을 유지하고 싶은 사람
팀 내 디자인 시스템을 AI 에이전트에게 전달할 표준 포맷이 필요한 팀
프로토타입이나 MVP를 빠르게 찍어내야 하는데, 범용적인 UI에서 벗어나고 싶은 사람

반대로 이미 Figma 기반 디자인 시스템이 잘 갖춰져 있고 AI 에이전트를 쓸 계획이 없다면 당장 필요하지는 않겠습니만, DESIGN.md 규격 자체가 아직 알파 단계이고, Google이 업계 표준으로 만들려는 움직임을 보이고 있어서 흐름은 지켜볼 만합니다.

DESIGN.md 공식 문서: stitch.withgoogle.com/docs/design-md/overview
DESIGN.md GitHub 레포: github.com/google-labs-code/design.md
getdesign.md (브랜드별 DESIGN.md 모음): getdesign.md
awesome-design-md GitHub 레포: github.com/VoltAgent/awesome-design-md

<출처: Jordan Lord>

2. 참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준

10년간 여러 제품을 만들어온 개발자 Jordan Lord가 자신의 블로그에 올린 글입니다. 이 글은 해커뉴스에 공유되며 나름의 화제가 됐는데요. 제품을 만들기 전에 반드시 통과해야 하는 세 가지 제을 제시하고, 하나라도 통과하지 못하면 만들지 않는다는 원칙을 공유합니다.

이 글이 반응을 얻은 건 아마 많은 빌더들이 겪는 공통적인 문제를 건드렸기 때문일 겁니다. 뭔가 만들고 싶은 아이디어는 많은데, 만들다 보면 범위가 커지고, 정체성이 흐려지고, 결국 아무도 안 쓰는 제품이 되는 경험. 이 글은 그 문제를 만들기 전 단계에서 잡는 방법을 이야기합니다.

기존 제품 판단 방식과 무엇이 다른가요?

보통의 사람들은 제품 아이디어를 평가할 때는 시장 크기, 경쟁자 분석, 사용자 니즈 같은 요소를 따집니다. 하지만 Jordan Lord의 접근은 방향이 조금 다릅니다. 아이디어가 좋은지 나쁜지를 판단하는 게 아니라, 만들 준비가 됐는지 안 됐는지를 판단하는 필터입니다. 그래서 세 가지 제약 모두 아이디어의 가치가 아니라 아이디어의 상태를 봅니다. 충분히 정리됐는가, 누적 가능한 구조인가, 정체성이 있는가. 같은 것들입니다.

세 가지 제약은 무엇인가요?

제약 1. 한 페이지를 넘기면 만들지 않는다

모든 아이디어는 한 장짜리 문서(one pager)로 정리해야 합니다. 이 문서가 north star(제품의 방향을 잡아주는 기준점) 역할을 하고요. 투자자한테도, 팀원한테도, 친구한테도 같은 문서를 보여줄 수 있어야 합니다.

핵심은 양쪽 극단을 모두 필터링한다는 점입니다. 한 페이지를 채우지 못했다면 아직 만들 준비가 안 된 거라고 하죠. 더 조사하고, 간단하게라도 만들어보고, 다시 써야 한다고요. 반대로 한 페이지를 넘어갈 정도라면 너무 복잡한 거라고 하죠. 협업에서도 이 문서가 기준이 됩니다. 의견 충돌이 생겼을 때, one pager에 없는 내용이라면 싸울 가치가 없고, 정말 중요하다면 문서를 수정해서 반영하면 된다고요.

제약 2. 핵심 기술은 제품과 분리되어야 한다

제품 자체와 별개로, 그 제품을 떠받치는 core tech(제품이 바뀌어도 남는 핵심 기술 자산)를 함께 만들어야 합니다. 이 core tech는 현재 제품이 없어져도 살아남을 수 있어야 하고요.

왜 이게 중요한지는 예시를 보면 바로 이해됩니다. Linus Torvalds가 Linux 커널 개발 워크플로를 개선하려고 만든 게 git이에요. Linux가 아니더라도 git은 살아남잖아요. HashiCorp의 HCL, Google의 Kubernetes도 마찬가지고요.

꼭 이런 대규모 프로젝트일 필요는 없습니다. 코드베이스에서 분리한 라이브러리, 계속 다듬어가는 방법론도 core tech가 될 수 있어요. 요점은 제품이 방향을 바꾸더라도 축적이 끊기지 않는 구조를 만들라는 겁니다. 피봇은 흔한 일이지만, 피봇할 때마다 모든 걸 처음부터 다시 시작하면 누적의 이점이 사라지니까요.

제약 3. 하나의 결정적 제약이 제품을 규정해야 한다

제품의 중심에 사용자가 항상 마주치는 하나의 defining constraint(제품의 정체성을 규정하는 핵심 제약)가 있어야 합니다. 이 제약이 제품의 정체성을 만들고, 사용자 경험 전반에 스며드는 거죠.

Minecraft는 블록만으로 세상을 만들 수 있습니다. IKEA는 납작한 상자에 담긴 자가 조립 가구죠. 이 제약을 들으면 제품의 느낌이 바로 떠오르잖아요. 잘 설계된 제약이 있으면 디자인은 그 제약에서 자연스럽게 따라 나온다는 게 Jordan Lord의 주장입니다.

해커뉴스 댓글에서 한 사용자는 이걸 product primitives(제품 전체를 구성하는 가장 작은 기본 단위)라는 개념으로 연결했는데요. Notion의 블록, Figma의 프레임과 레이어, Twitter의 트윗, Excel의 셀이 모두 같은 구조라는 거예요. 제품의 중심에 있는 하나의 기본 단위가 전체 경험을 규정한다는 점에서 맥이 닿습니다. 반대로 이 제약을 정하지 않거나 잘못 정하면, 모든 걸 하려는 비대한 제품이 된다고 합니다.

무엇을 얻어가야 하나요?

이 글의 가치는 프레임워크 자체보다 태도에 있다고 봅니다. 세 가지 제약 중 하나라도 통과하지 못하면 만들지 않는다는 원칙이요. AI 덕분에 만드는 속도가 빨라진 만큼, 만들지 말아야 할 것을 거르는 기준도 더 중요해지고 있으니까요.

모든 제품에 이 프레임워크가 딱 맞는 건 아닐 수 있습니다. 특히 core tech 분리는 초기 탐색 단계에서는 과한 요구일 수 있고, B2B SaaS처럼 범위가 넓어질 수밖에 없는 제품에서는 defining constraint가 좁은 게 오히려 제약이 될 수도 있습니다. 해커뉴스 댓글에서도 이런 반론이 나왔고요. 그래도 만들기 전에 세 가지 질문을 스스로에게 던지는 습관은 가져갈 만합니다.

한 페이지로 정리할 수 있는가? 피봇해도 살아남는 게 있는가? 이 제품의 정체성을 한 문장으로 말할 수 있는가?

원문: jordanlord.co.uk/blog/3-constraints
해커뉴스 토론: news.ycombinator.com/item?id=47903541

<출처: 유튜브, Lenny's Podcast>

3. 적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

Cat Wu는 앤트로픽에서 Claude Code와 Co-work의 프로덕트를 이끌고 있는 제품 총괄입니다. 최근 Lenny's Podcast에 출연해서 앤트로픽 프로덕트 팀이 어떻게 일하는지, AI 시대에 PM에게 필요한 능력이 무엇인지를 공유했는데요. 이 에피소드는 현재 Lenny's Podcast의 최근 영상 중 가장 빠르게 조회수가 올라가고 있는 영상 중 하나입니다.

흥미로운 건 인터뷰 전반을 관통하는 메시지가 하나라는 점인데요. 코드가 싸지면, 무엇을 만들지 결정하는 능력의 가치가 올라간다. Cat Wu는 이걸 product taste라고 부릅니다.

무슨 문제를 해결하려 하나요?

AI 덕분에 만드는 속도가 올라갔습니다. 그건 모두가 체감하고 있죠. 그런데 속도가 올라간 세계에서 PM은 뭘 해야 하는 건지, 엔지니어와 PM의 경계가 흐려지면 PM의 존재 이유가 뭔지, 이런 질문에는 아직 명확한 답이 없습니다.

Cat Wu는 실제로 수백 명의 PM을 인터뷰하고 있다고 합니다. 그리고 많은 지원자들이 AI 시대의 PM 역할을 잘못 이해하고 있다고 느낀다고요. 기존처럼 6~12개월 로드맵을 짜고, 팀 간 조율에 시간을 쓰는 방식으로 접근하는 사람들이 많다는 겁니다.

속도는 어떻게 만들어졌나요?

앤트로픽 프로덕트 팀의 출시 속도는 이례적입니다. Cat Wu에 따르면, 피처 출시 타임라인이 6개월에서 1개월로, 다시 1주로, 때로는 하루로 줄었다고 합니다. 이 속도를 가능하게 만든 건 세 가지 구조입니다.

첫째, 거의 모든 피처를 Research Preview로 먼저 출시합니다. 사용자에게 이건 초기 제품이고, 피드백을 받기 위한 단계라는 걸 명확히 알린 뒤 출시하는 거예요. 이렇게 하면 출시에 대한 부담이 줄어들어서, 1~2주 만에 뭔가를 내보낼 수 있게 됩니다.
둘째, 엔지니어링-마케팅-문서화 사이의 프로세스가 매우 타이트합니다. 엔지니어가 내부 테스트를 마친 피처를 evergreen launch room이라는 채널에 올리면, 마케팅과 문서 팀이 바로 다음 날 발표를 준비하는 구조라고 해요. PM의 역할은 이 흐름이 막히지 않도록 만드는 것이고요.
셋째, 팀 전체가 공유하는 원칙 문서가 있습니다. 핵심 사용자가 누구인지, 왜 그들이 핵심인지, 어떤 트레이드오프를 감수할 수 있는지가 적혀 있어서, 팀원 누구나 PM에게 물어보지 않고도 스스로 판단할 수 있게 만들었다고 합니다.

빠른 세계에서 뭐가 더 중요해졌나요?

그런데 이 속도에는 비용이 따릅니다. Cat Wu가 직접 인정한 부분인데요. 제품 일관성이 떨어집니다. 기능끼리 겹치는 경우도 생기고, 새로운 사용자 입장에서는 어떤 기능을 써야 할지 헷갈릴 수 있다고요. 사용자들도 매일 트위터를 확인해야 최신 기능을 놓치지 않는다는 느낌을 받는다고 합니다.

Cat Wu는 이 맥락에서 product taste를 이야기합니다. 코드가 싸지면, 뭘 만들지 결정하는 능력이 더 중요해진다고요. GitHub 이슈에 수만 개의 요청이 쌓여 있는데, 그중 어떤 것을 만들 가치가 있는지, 만든다면 어떤 방식이 맞는지를 판단하는 능력이 가장 희소하다는 겁니다.

현재는 엔지니어링 배경이 도움이 된다고 합니다. 이걸 만드는 게 얼마나 어려운 일인지 감이 있으면, 토론 대신 그냥 한 시간 만에 만들어보는 판단을 내릴 수 있으니까요. 다만 Cat Wu는 이 역시 몇 달 뒤에는 달라질 수 있다고 덧붙였습니다. 모델 역량이 올라갈 때마다 가치 있는 스킬셋도 바뀌고 있어서, 너무 먼 미래를 예측하는 건 어렵다고요.

앤트로픽이 PM보다 product taste가 있는 엔지니어를 적극적으로 뽑고 있다는 점도 눈여겨볼 만합니다. Cat Wu 본인도 엔지니어 출신이고, 팀의 PM 대부분이 엔지니어 경험이 있으며, 디자이너들도 프론트엔드 엔지니어 출신이라고 합니다. 역할이 합쳐지는 흐름이 이미 실행되고 있는 셈이죠.

어떻게 기르나요?

Cat Wu가 인터뷰에서 공유한 방법들을 정리해보면 이렇습니다.

모델에게 실수 이유를 물어보세요.

Cat Wu가 가장 과소평가된 AI 스킬이라고 부른 방법입니다. 모델이 예상과 다르게 행동했을 때, 왜 그렇게 했는지 모델에게 직접 물어보는 거예요. 예를 들어 모델이 프론트엔드를 수정하고 테스트는 돌렸는데 실제 UI는 확인하지 않았다면, 왜 UI 확인을 안 했는지 물어보는 겁니다. 그러면 시스템 프롬프트에서 헷갈리는 부분이 있었다든지, 서브 에이전트에게 검증을 맡겼는데 그쪽에서 빠뜨렸다든지 하는 이유가 나온다고요. 이런 피드백이 쌓이면 어떤 부분을 고쳐야 모델이 더 잘 작동하는지 파악할 수 있게 됩니다.

피드백을 잘하는 5명을 찾으세요.

모든 사용자의 피드백이 같은 무게를 가지는 건 아닙니다. Cat Wu는 모델이나 제품의 품질을 정확하게 짚어내는 사람이 따로 있다고 합니다. 그런 사람 5명 정도를 찾아서 빠른 피드백 루프를 만드는 게 중요하다고요. 앤트로픽 내부에서도 새 모델이 나오면 팀 점심 시간에 한 명씩 돌아가며 모델에 대한 인상을 물어보고, 그 피드백을 기반으로 데이터에서 검증할 가설을 세운다고 합니다.

AI의 결과물을 테스트하는 기준(eval)을 만드세요.

eval은 "이 프롬프트를 넣으면 이런 결과가 나와야 한다"는 테스트 케이스입니다. 백 개를 만들 필요 없이, 10개만 잘 만들어도 충분하다고 합니다. 좋은 eval은 목표를 구체적으로 정의하고, 진행 상황을 측정하게 해주고, 부족한 부분을 보여줍니다. Cat Wu는 eval이 PM과 엔지니어 모두에게 과소평가된 스킬이라고 강조했어요.

자동화를 95%에서 멈추지 마세요.

95% 정확도의 자동화는 자동화가 아니라고 합니다. 나머지 5%를 사람이 매번 확인해야 한다면, 그건 여전히 수작업이니까요. Cat Wu 본인도 Co-work로 이메일을 자동 분류하는 워크플로를 만들고 있는데, 아직 100%에 도달하지 못해서 계속 다듬고 있다고요. 자동화를 만드는 건 직접 하는 것보다 느릴 수 있지만, 100%에 도달하면 진짜 레버리지가 생긴다는 점을 강조합니다.

프로토타입이 아니라 매일 쓰는 앱을 만드세요.

AI로 뭔가를 만들어보고 대단하다 하고 넘어가는 건 배움도 레버리지도 제한적입니다. Cat Wu는 실제로 매일 쓰는 도구를 만들어야 진짜 학습이 일어난다고 합니다. 앤트로픽 내부에서도 영업팀이 고객 맞춤 덱을 자동 생성하는 웹앱을 직접 만들어 쓰고 있고, Applied AI 팀은 Co-work로 다음 날 고객 미팅 브리핑을 자동으로 만들어둔다고요. 이런 도구들이 계속 쓰이면서 점점 더 나아지는 구조입니다.

이 인터뷰가 가리키는 한 가지 방향

이 인터뷰에서 나온 이야기들을 모아보면 하나의 패턴이 보입니다. 앤트로픽은 속도를 높이기 위해 프로세스를 줄이고, 역할 경계를 없애고, 출시 부담을 낮추는 쪽으로 움직이고 있습니다. 그리고 그 결과 더 중요해진 건 도구를 잘 쓰는 능력이 아니라, 무엇을 만들고 무엇을 만들지 않을지 판단하는 능력입니다.

Cat Wu의 좌우명도 이 맥락과 맞닿아 있는데요. Just do things. 역할에 갇히지 말고 필요한 일을 하라는 뜻이라고 합니다. 다만 아무거나 하라는 게 아니라, 제약 조건을 이해하고, 첫 번째 원칙에서 출발해서, 올바른 행동 방향을 스스로 도출한 뒤 바로 실행하라는 의미에 가깝다고요.

적용을 위해 실행해볼 수 있는 것

이번 주에 AI 에이전트가 예상과 다르게 행동한 순간이 있었다면, 왜 그렇게 했는지 모델에게 직접 물어보기. 시스템 프롬프트나 지시가 어떻게 해석됐는지 확인하면, 다음에 같은 실수를 줄일 수 있습니다.
지금 만들고 있는 자동화 중에 90~95%에서 멈춰 있는 게 있다면, 이번 주에 시간을 내서 100%를 향해 한 단계 더 밀어보기. 되는 만큼만 쓰는 것과 완전히 맡기는 건 레버리지가 전혀 다릅니다.
AI로 만든 프로토타입 중에 한 번 써보고 끝낸 게 있다면, 그중 하나를 골라 매일 쓰는 도구로 키워보기. 매일 쓰면서 부딪히는 문제를 고치는 과정이 가장 빠른 학습입니다.

영상: Lenny's Podcast - 앤트로픽의 제품 팀이 다른 어떤 팀보다 빠르게 움직이는 비결 | 캣 우

정리

이번 주 세 소재를 관통하는 키워드는 구조화된 판단입니다.

DESIGN.md는 디자인 규칙을 파일 하나로 구조화해서 AI가 매번 추측하지 않게 만듭니다. 3 Constraints는 만들기 전에 세 가지 필터를 거는 구조로 복잡하거나 정체성 없는 제품을 걸러냅니다. Cat Wu가 말하는 product taste는 만들 수 있는 것이 넘쳐나는 세계에서 무엇을 만들지 판단하는 구조를 자기 안에 갖추라는 이야기고요.

AI가 실행 속도를 올려줄수록, 우리에게 판단의 구조가 없으면 빠르게 잘못된 방향으로 빠질 수 있습니다. 도구는 계속 바뀌겠지만, 무엇을 만들지, 왜 이 규칙인지, 어디서 멈출지를 정하는 건 여전히 사람의 몫이니까요.

이렇게 적용해보세요

DESIGN.md를 한 번 만들어보세요. getdesign.md에서 마음에 드는 브랜드 파일을 가져와 내 프로젝트에 맞게 수정하는 것부터 시작할 수 있습니다. 매번 디자인을 설명하는 시간이 줄어드는 걸 체감하게 됩니다.
지금 진행 중인 프로젝트를 one pager로 정리해보세요. 한 페이지 안에 담기는지, 이 제품의 defining constraint가 뭔지 써보는 것만으로도 범위가 잡히는 경우가 많습니다.
내가 반복적으로 하고 있는 작업 중 하나를 골라 AI 자동화를 시작해보세요. 90%에서 멈추지 말고 100%를 향해 밀어보는 게 핵심입니다.

]]>

전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Opus 4.7, 무엇이 달라졌을까?
참고할 것: Claude Mythos 무단 접근 사건
적용해볼 것: 전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

1. 써볼 것:Claude Opus 4.7, 무엇이 달라졌을까?

Claude Opus 4.7은 앤트로픽이 4월 16일에 출시한 최신 플래그십 모델입니다. 출시 직후부터 코딩 커뮤니티에서 큰 관심을 받았는데요. 커서(Cursor)의 CEO는 자체 벤치마크에서 Opus 4.6 대비 12%p 향상됐다고 밝혔고, 데빈(Devin)의 CEO는 몇 시간 동안 일관되게 작동하며 어려운 문제를 끝까지 밀어붙인다고 평가했습니다. 다만 출시 이틀 만에 코딩은 확실히 좋아졌지만 그 외에는 오히려 퇴보했다는 반응이 나오기 시작했습니다.

무슨 문제를 해결해 주나요?

Opus 4.6까지의 Claude는 복잡한 코딩 작업을 맡기면 중간에 맥락을 잃거나, 여러 파일에 걸친 리팩토링에서 사람이 계속 확인해줘야 하는 경우가 있었습니다. 특히 길게 돌리는 에이전트 작업에서 안정성이 아쉽다는 피드백이 많았고요. Opus 4.7은 이 부분을 집중적으로 개선한 모델입니다. 앤트로픽은 이전에 밀착 감독이 필요했던 가장 어려운 코딩 작업을 이제 Opus 4.7에 맡길 수 있게 됐다고 설명합니다.

무엇이 달라졌나요?

코딩 벤치마크부터 보면 도약이 뚜렷합니다. 소프트웨어 엔지니어링 벤치마크 SWE-bench Pro에서 64.3%(Opus 4.6은 53.4%), SWE-bench Verified에서 87.6%(Opus 4.6은 80.8%)를 기록했고요. GPT-5.4나 제미나이 3.1 프로도 앞섰습니다. 코딩 외에도 몇 가지 주목할 변화가 있습니다.

비전 해상도 3배 향상: 이미지를 최대 2,576픽셀(약 375만 화소)까지 처리할 수 있게 됐습니다. 이전은 1,568픽셀(약 115만 화소)이었으니 3배 이상이고요. 차트, 코드 스크린샷, 디자인 시안 같은 걸 분석할 때 체감이 달라진다는 반응이 있습니다. 자율 보안 테스트 회사 XBOW의 비주얼 정확도 벤치마크에서 98.5%를 기록했는데, Opus 4.6은 54.5%였습니다.
추론 단계 xhigh 추가: 기존에 low, medium, high, max 4단계였는데, high와 max 사이에 xhigh가 추가됐습니다. Claude Code에서는 이 xhigh가 기본값으로 설정되어 있고요. 앤트로픽은 코딩과 에이전트 작업에는 high나 xhigh로 시작하라고 권장합니다.
/ultrareview 명령어: Claude Code에서 쓸 수 있는 코드 리뷰 전용 명령어입니다. 변경 사항을 읽고 버그나 설계 이슈를 찾아 리뷰하는 별도 세션을 띄우는 방식인데요. 프로와 맥스 사용자에게 3회 무료 제공됩니다.
파일 기반 장기 메모리 개선: 여러 세션에 걸쳐 작업할 때 메모를 기억하고 활용하는 능력이 좋아졌다고 합니다. 여러 세션에 걸친 작업이 안정적으로 이어진다는 테스터 보고가 있고요.
사이버 보안 장치 탑재: 지난주 소개한 Mythos의 사이버보안 능력이 너무 강력해서 일반 공개하지 않았는데, Opus 4.7에는 금지되거나 위험도 높은 사이버보안 요청을 자동으로 감지하고 차단하는 보안 기능이 처음으로 적용됐습니다.

토큰 소모와 범용 품질 논란

출시 후 커뮤니티 반응이 갈리고 있습니다. AI타임스는 성능 퇴보 논란이라는 기사를 냈고, 레딧에서는 Opus 4.7은 업그레이드가 아니라 심각한 퇴보라는 게시물이 추천 3200개, 댓글 800개를 넘기며 화제가 되기도 했습니다.

주요 논란 포인트를 정리하면 이렇습니다.

토큰 소모 증가: 새 토크나이저(텍스트를 토큰으로 쪼개는 방식)가 바뀌면서 같은 텍스트에 토큰이 1.0~1.35배 더 듭니다. 여기에 xhigh 기본 설정까지 겹치면, 실질 사용량이 Opus 4.6 대비 2배 가까이 빨라진다는 보고가 나오고 있습니다. 요금 자체는 Opus 4.6과 동일하지만(입력 100만 토큰당 $5, 출력 $25), 같은 작업에 토큰을 더 쓰니까 실질 비용은 올라가는 거죠.
긴 문맥 회수 능력 하락: 긴 대화에서 앞쪽 정보를 다시 꺼내오는 능력을 측정하는 벤치마크에서, 78.3%에서 32.2%로 크게 떨어졌다는 분석이 있습니다. 긴 문서 분석이나 대규모 코드 리뷰에서 체감이 나빠질 수 있다는 뜻이고요.
일반 대화 품질 체감 하락: 코딩 특화 쪽으로 굉장히 뾰족하다는 평가가 나왔고, 맥락이 덜 주어질 때 소통 능력이 떨어진다는 보고가 있습니다. 적응적 사고 기능에 대한 원성이 심해서 롤백된 이력도 있고요.

정리하면, 에이전트 코딩 작업에서는 확실한 업그레이드입니다. 여러 파일에 걸친 리팩토링, 장시간 자율 작업, 이미지 분석이 주 용도라면 바로 전환할 가치가 있고요. 반면 글쓰기, 긴 문서 분석, 일반 대화가 주 용도라면 Opus 4.6을 유지하는 게 나을 수 있습니다.

누구에게 좋을까요?

Claude Code나 커서에서 장시간 에이전트 코딩 작업을 자주 하는 개발자
여러 파일에 걸친 리팩토링, 코드 아키텍처 설계 같은 복잡한 코딩 작업이 필요한 팀
이미지 분석이 중요한 작업을 하는 사람 (차트, 스크린샷 분석 등)

추론 단계 조절이 핵심입니다. Claude Code에서 기본 xhigh를 쓰되, 단순 작업에서는 high로 내리면 토큰 소모를 줄일 수 있습니다. 앤트로픽 공식 블로그에서는 첫 메시지에 의도, 제약 조건, 완료 기준을 한 번에 넘기라고 권장하고 있고요. 대화를 여러 턴에 나눌수록 추론 비용이 붙어서 토큰을 더 쓰게 된다고 합니다. 가격은 Opus 4.6과 동일하게 입력 100만 토큰당 $5, 출력 $25이고, Claude.ai와 각종 클라우드 플랫폼에서 쓸 수 있습니다.

<출처: techcrunch>

2. 참고할 것:Claude Mythos 무단 접근 사건

앤트로픽이 최근 발표한 Claude Mythos는 사이버보안 취약점 탐지에 특화된 AI 모델입니다. 능력이 너무 강력해서 앤트로픽이 일반 공개하지 않기로 하고, 프로젝트 글래스윙이라는 이름으로 애플, 마이크로소프트 등 극소수 파트너에게만 제한 제공한 모델인데요. 그런데 4월 21일, Bloomberg와 TechCrunch가 보도한 소식에 따르면, Mythos 공개 당일 외부인이 무단으로 접근하는 일이 벌어졌습니다.

어떻게 뚫렸나요?

Bloomberg에 따르면, 미공개 AI 모델을 추적하는 디스코드 기반 그룹이 Mythos에 접근하는 데 성공했다고 합니다. 접근 경로가 두 가지였는데요. 하나는 앤트로픽의 서드파티 업체에 근무하는 사람의 접근 권한을 이용한 것이었고, 다른 하나는 앤트로픽이 기존 모델에 쓰던 URL 패턴을 유추해서 모델의 위치를 찾아낸 것이었다고 합니다. 정교한 해킹이 아니라 패턴 추측으로 접근에 성공한 거죠. 이 그룹은 공개 당일부터 Mythos를 사용해왔고, 실제 접근 증거로 Bloomberg에 사용 화면과 실시간 시연까지 보여줬다고 합니다. 다만 그룹 측은 새로운 모델을 가지고 놀아보는 것에 관심이 있었을 뿐, 피해를 주려는 의도는 아니었다고 밝혔죠.

왜 문제인가요?

앤트로픽은 조사 중이며 자사 시스템에 영향을 미친 증거는 없다고 밝혔습니다. 그룹의 의도도 악의적이지 않았다고 하고요. 하지만 이 사건이 문제가 되는 이유는 맥락에 있습니다. 앤트로픽은 Mythos의 사이버보안 능력이 악용될 경우 전 세계 인프라에 위협이 될 수 있다는 이유로, 1억 달러 상당의 크레딧과 함께 50개 이상의 파트너에게만 제한 제공하는 방식을 택했습니다. 안전하고 책임감 있는 AI를 내세우며 가장 신중한 배포 방식을 선택한 건데, 그 모델이 URL 패턴 추측으로 접근 가능했다는 건 보안 인프라가 모델의 능력을 따라가지 못하고 있다는 신호로 읽힐 수 있습니다.

무엇을 얻어가야 하나요?

이 사건은 프로덕트 메이커에게 두 가지를 짚어줍니다.

하나는, AI 모델의 성능만큼 접근 제어도 중요하다는 점입니다. Mythos는 모델 자체는 압도적이었지만, 그걸 담는 그릇은 그만큼 단단하지 못했습니다. AI 프로덕트를 만들 때 모델 성능에만 집중하기 쉬운데, 누가 어떤 경로로 접근할 수 있는지를 같은 수준으로 설계해야 한다는 걸 보여주는 사례입니다.

다른 하나는, 외부 협력사가 보안의 가장 약한 고리가 될 수 있다는 점입니다. 앤트로픽 자체 시스템이 뚫린 건 아닙니다. 서드파티 업체 직원의 권한과 URL 패턴 유추를 조합해서 접근한 건데, 결국 AI 모델을 외부에 제공하는 순간 파트너사의 보안 수준까지 내 보안의 범위가 되는 거죠. 모델을 잘 만드는 것만큼, 모델을 누구에게 어떻게 열어주는지를 설계하는 일이 중요해지고 있습니다.

<출처: 유튜브 Lenny's Podcast>

3. 적용해볼 것:전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

Nikhyl Singhal은 메타와 구글을 거쳐, 크레딧 카르마의 CPO를 지낸 사람입니다. 지금은 시니어 프로덕트 리더 125명이 모인 Skip이라는 커뮤니티를 운영하면서, 프로덕트 업계에서 무슨 일이 벌어지고 있는지를 가장 가까이서 관찰하고 있는 사람 중 한 명이죠. Lenny's Podcast에 최근 출연해서 인터뷰한 내용이 프로덕트 커뮤니티에서 주목받고 있습니다.

무슨 문제를 해결하려 하나요?

AI 때문에 PM이 사라질 거라는 이야기는 요즘 흔하게 들립니다. 그런데 실제로 현장에서 무엇이 바뀌고 있는지를 구체적으로 설명해주는 사람은 많지 않죠. Singhal은 125명의 프로덕트 리더를 매달 만나면서 관찰한 내용을 토대로, 무엇이 달라졌고 누가 잘되고 있으며 누가 어려운지를 직설적으로 이야기합니다.

무엇이 달라졌다고 말하나요?

Singhal의 핵심 진단은 이렇습니다. 3년 전까지 PM의 하루는 정보를 정리하고 전달하는 일이 대부분이었다고요. 내 팀이 만든 내용을 상사가 이해하게 정리하고, 상사가 그 윗사람에게 다시 전달하는 구조. 그는 이걸 권한 없는 책임이라고 불렀는데, 직장 스트레스의 가장 큰 원인이라고 했습니다. 지금은 이 정보 전달자 역할이 빠르게 사라지고 있다고 합니다. 대신 남는 게 두 가지인데, 판단력과 직접 만드는 능력이라는 겁니다.

판단력이라는 게 추상적으로 들릴 수 있는데, Singhal은 이렇게 설명합니다. 변경 사항이 좋은지 나쁜지 평가하는 것, 100개 커스텀 버전 대신 지속 가능한 하나를 설계하는 것, 만들 가치가 있는지 출시할 가치가 있는지 결정하는 것. 테스트 비용이 거의 0에 가까워지면서 변화의 속도가 10배 이상 빨라지고 있고, 그 속도에서 무엇을 바꾸고 무엇을 지킬지 결정하는 게 판단력이라고요.

빌더 쪽은 더 직접적입니다. 그가 운영하는 125명 프로덕트 리더 모임에서 최근 쇼앤텔을 했는데, 모두 노트북을 열고 자기가 만든 걸 보여주면서 서로 더 나은 걸 만들었다고 경쟁하더라고요. 3년 전만 해도 프로덕트 리더 모임에서 코드를 보여주는 건 상상하기 어려운 일이었죠.

좋은 소식과 나쁜 소식

좋은 소식부터 하면, 빌더 성향의 PM은 역대 최고의 시기를 보내고 있다고 합니다. 보상은 사상 최고치이고, 제안도 그 어느 때보다 많고, 다음 직장으로 창업자나 CEO를 고려하는 사람도 늘고 있다고요. 실제로 Singhal의 커뮤니티에서 지난 12개월 동안 14명이 창업자로 전환했다고 합니다. 125명 중 14명이면 적지 않은 숫자죠.

나쁜 소식은, PM의 절반 정도가 빌더가 아닌 정보 전달자 유형이라는 겁니다. 이 사람들에게 Singhal은 꽤 직설적이었습니다. 만드는 걸 좋아하지 않는다면 위기에 처해 있다고요. 앞으로 12~24개월 안에 대규모 구조조정이 벌어질 거라는 게 그의 예측인데, 3만 명을 자르고 8천 명을 뽑는 상황이 벌어질 수 있고, 그 8천 명은 전부 AI를 기본으로 쓰는 인재가 될 거라고 했습니다.

이력서의 회사 이름보다 지금 일하는 방식을 본다고 합니다

Singhal이 강조한 또 다른 변화가 있습니다. 이전에는 이력서에 메타, 구글 같은 회사 이름이 있으면 그것만으로 실력을 인정받을 수 있었지만 지금은 인터뷰에서 어떤 도구를 쓰는지, 판단을 어떻게 내리는지를 묻는다고요. 이전 회사에서 뭘 출시했는가보다, 지금 어떻게 일하고 있는가가 더 중요해졌다는 겁니다. 흥미로운 관찰은, 정보 전달 중심의 일하는 방식에 가장 능숙했던 사람이 오히려 전환이 가장 어렵다는 부분입니다. 지금 방식으로도 잘하고 있으니까 바꿀 이유를 못 느끼는 건데, Singhal은 이 지점이 함정이라고 하죠.

그래서 어떻게 해야 하나요?

Singhal의 핵심 조언은 하나입니다. 만드는 일에서 기쁨을 찾아라. 문장 자체는 추상적으로 들리겠지만, 그가 말하는 맥락은 구체적입니다.

AI 도구로 뭔가를 직접 만들어보면, 어느 순간 재미를 느끼는 첫 번째 순간이 온다고 합니다. 집안 조명을 제어하는 앱을 만들었거나, 자기 업무용 비서 앱을 만들었거나, 파트너와 함께 쓰는 도구를 만들었거나. 내용은 사람마다 다르지만, 그 순간이 오면 두려움에서 기쁨으로 전환이 일어난다고요. 그리고 기쁨은 번아웃의 가장 강력한 해독제라고 했습니다.

동시에 그는 이 혼란이 영원하지는 않을 거라고도 했습니다. 인터넷이 등장했을 때도 기존 PM의 일하는 방식이 완전히 뒤집혔지만, 몇 년 지나니 새로운 기준이 잡혔죠. 지금도 2년 정도면 어느 정도 안정될 거라는 게 그의 관측입니다. 다만 그 2년이 결정적이라는 게 메시지죠. 업계가 안정됐을 때 살아남아 있으려면, 지금 변화해야 한다고요.

어렵죠. 배워야 할 건 매일 늘어나고, 따라가야 할 속도는 점점 빨라지는데, 정작 내가 지금 뭘 해야 하는지는 더 흐릿해지는 느낌이 들 때가 있습니다. Singhal의 이야기를 정리하면서도, 이걸 읽는 분들이 또 하나의 압박으로 받아들이면 어쩌나 하는 걱정이 됩니다. 그래서 이 말을 남기고 싶습니다. 지금 당장 커리어를 재설계하거나, 뭔가를 완성할 필요는 없습니다. 다만 자기 일에서 반복되는 작업 하나를 골라서, AI 도구로 바꿔보는 건 해볼 만하죠. 회의 요약이든, 데이터 정리든, 간단한 자동화든. 변화가 두렵지 않아지는 건, 공부를 많이 해서가 아니라 직접 만들어본 경험이 한 번이라도 있기 때문인 것 같습니다.

적용해볼 질문

내 하루 중 정보를 정리하고 전달하는 데 쓰는 시간과, 직접 무언가를 만들거나 판단하는 데 쓰는 시간의 비율은 어떤가?
AI 도구로 무언가를 직접 만들어본 경험 중, 재미를 느낀 순간이 있었는가? 없었다면, 그 첫 경험을 만들 수 있는 가장 작은 프로젝트는 무엇인가?
지금 나는 스스로 현재 어떻게 일하는지를 설명할 수 있는가?

실행해볼 수 있는 것

이번 주 회의 중 하나를 골라서, 그 회의에서 정리·전달하는 데 쓰는 시간을 AI 도구로 자동화할 수 있는지 실험해보기. 상태 보고서, 이슈 정리, 회의 요약 같은 것부터 시작해보기.
가장 작은 빌드 프로젝트 하나를 정해서, 이번 주 안에 작동하는 결과물을 만들어보기. 업무용이든 개인용이든, 동작하는 무언가를 만드는 경험 자체가 중요합니다.
자기 역할에서 판단이 필요한 순간을 명시적으로 기록해보기. 일주일간 어떤 결정을 내렸는지, 그 결정이 왜 AI에게 맡길 수 없는 것이었는지 정리해보기 (이를 바탕으로 내 역할의 핵심이 어디에 있는지 생각해보기)

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

한국에서 인기 있는 앱이 왜 영국에선 통하지 않을까?

현재 영국에 지내다 보니 국가에 따라 앱 서비스 사용하는 상황에 차이가 있다는 걸 알게 됐다. 그 예시로 스타벅스 사이렌 오더가 주문이 익숙한 한국과 달리, 영국은 매장에서 직접 주문하는 경우가 많다. 오히려 앱 주문을 어색해하고 앱 사용에 어려움을 겪는 것이다. 서비스 측에서도 앱 사용을 이끌기 위한 프로모션을 시행하는 것도 드물었다. 이처럼 같은 서비스여도 나라마다 앱 사용률의 차이를 체감하니, 타 국가에 서비스를 안착시키기 위해선 어떤 접근 방식을 따를지 고민하게 된다.

또 다른 예로 당근이 당근마켓 서비스를 영국, 캐나다에 확장하는 과정에서 ‘매너 온도’ 기능에 대해 국내 고객과 이해 차이가 극명히 드러났던 사례가 있다. 국내 사용자는 36.5도를 정상 체온이라 이해하는 것과 달리 캐나다, 영국에서 만난 사용자는 정상 체온의 표현 방식이 달랐다. 심지어 5점 만점의 별점으로 점수 매기는 방법처럼 누구나 익숙하고 쉽게 이해할 방법이 있는데, 왜 어려운 방식을 고수하냐는 의견이 있었다고 한다. (출처)

그래서 결국 체온에 대한 컨셉을 제외하고 score 점수 형태로 수정했다. 이는 다른 국가에 서비스를 출시할 경우 서비스를 이용하는 고객을 새롭게 이해해야 하며, 나아가 서비스가 해결해야 할 문제, 페인 포인트가 다르다는 점을 시사한다.

‘문제 정의’는 서비스를 다른 국가에 출시하는 것이 아니더라도, 프로덕트를 운영하는 입장에서 항상 주목하는 부분이다. 이때 문제로서 검증 가치가 있는가를 생각하여 가설을 세우게 되는데, 만약 새로운 고객을 타깃으로 서비스를 출시할 때, 어떻게 가설을 세우고 어떤 가설을 우선으로 검증해야 할까? 타국가에 출시해야 할 경우처럼 참고할 데이터가 없다면, 고객을 어떻게 이해할 수 있을까? 완전히 새로운 시장에서 새로운 고객을 타겟하는 서비스라면 어떨까.

이번 글에서는 Customer Journey Shadowing 방법을 활용하여, 고객을 이해하고 보다 유의미한 가설을 세우는 접근 방식에 관해 이야기하고자 한다.

<출처: 구글>

Customer Journey Shadowing이란?

고객의 여정(Customer Journey)을 그림자처럼 따라다니며 관찰하는 리서치 방법으로, 사용자가 실제로 무엇을 하는지 행동 중심으로 분석하는 방법이다. 단순 인터뷰나 설문과 달리 실제 행동, 맥락, 감정, 문제점을 현장에서 발견할 수 있다는 점이 핵심이다.

예시로, 카페 주문하는 행동을 리서치 하면, ‘ 고객이 매장에 들어와서 메뉴 탐색 → 주문 → 결제 → 픽업 → 좌석 이용’까지 전 과정을 관찰하는 것이며, 서비스 UX의 경우 ‘사용자가 상품 탐색 → 비교 → 장바구니 → 결제 → 배송 확인 과정’을 실제로 사용하는 모습을 관찰하는 것이다.

왜 Customer Journey Shadowing을 하는가

그렇다면 왜 Customer Journey Shadowing을 해야 할까? 인터뷰, 설문만으로는 사용자의 실제 행동과 차이가 생기기 때문이다. 예로 사용자를 구두로 인터뷰할 경우, ‘저는 항상 리뷰를 확인해요’ 라 답하지만, 실제로 리뷰를 거의 보지 않을 경우가 있고, ‘앱 사용이 어렵지 않았어요.’라 답하지만, 특정 화면을 여러 번 왔다 갔다 하기도 한다. 그래서 요즘 업계에서는 A/B Test를 시행해, 사용자의 의견이 아닌 실제 상황에서 나타난 행동을 검증하는 것이 보편화되고 있기도 하다.

대표적으로 Customer Journey Shadowing을 많이 사용하는 브랜드에는 IKEA 가 있다. UX 리서처들은 매장에서 ‘고객이 어떤 경로로 이동하는지’, ‘어떤 제품 앞에서 오래 머무는지’, ‘언제 직원을 찾는지’, ‘어떤 순간에 쇼핑을 포기하는지’ 분석했고, ‘고객이 제품 사진을 찍어둔다.’, ‘제품 위치를 나중에 찾지 못한다.’, ‘매장이 너무 커서 동선이 헷갈린다.’, 등의 페인 포인트를 발견했다. 이에 IKEA 앱에 ‘제품 위치 찾기’, ‘쇼핑 리스트’, ‘매장 지도’를 추가했다. 이는 Customer Journey Shadowing 리서치 인사이트를 디지털 서비스 개선으로 이어진 사례로 언급된다.

다음은 한 사례를 보여주는 자료다. IKEA의 Customer Journey Shadowing을 활용한 서비스 개선 기회 발견 과정을 알 수 있다. 가로축은 ‘고객 여정 전체’ 과정, 세로축은 차례대로 ‘고객 행동’, ‘터치 포인트(고객이 제품/서비스를 인지하고 구매, 사후 서비스에 이르기까지 기업과 접촉하는 모든 물리적·디지털·인적 상호작용 지점)’, ‘고객 경험/감정’, ‘기회 영역(개선할 수 있는 영역 또는 아이디어)’을 나타낸다.

특히 ‘고객 경험/감정’을 표시하는 두 선은 서비스 개선 지점을 나타낸다. 빨간 선은 문제가 발생하는 지점, 즉 페인 포인트(Pain Point)로 고객이 불편함을 느끼는 순간, 감정 그래프가 떨어지는 지점, 행동이 끊기거나 멈추는 순간을 의미한다. 초록 선은 개선 기회 또는 긍정적 경험 지점, 문제를 해결할 수 있는 지점, 새로운 기능/서비스 도입 가능함을 표시한다. 두 선의 차이가 발생하는 지점에 고객의 불편을 해결하는 기회 영역을 발견할 수 있다.

<출처:구글>

이처럼 Customer Journey Shadowing은 사용자가 명확하게 불편하다고 인식하지 못하지만, 행동을 방해하거나 경험을 나쁘게 만드는 요소를 알 수 있다. 즉, 실제 행동 기반으로 문제 발견하고 고객 경험 전체 흐름 이해할 수 있게 된다.

Customer Journey Shadowing 진행 방법

리서치 과정은 ‘리서치 목표를 정의 - 관찰 대상 사용자 선정 - 고객 여정 정의 - 실제 행동 관찰 - 인사이트 도출’ 순서로 진행된다. 해당 글에서는 스타벅스 앱 서비스 영국 현지화를 가정하여, 고객 행동의 특징과 페인 포인트를 이해하는 것을 목표로 설정했다.

리서치 목표 정의 : 고객이 음료를 주문하며 카페를 이용하는 전 과정을 분석한다.
관찰 대상 사용자 선정 : 스타벅스 방문 고객
고객 여정 정의 : 매장 입장 - 메뉴 탐색 - 주문 대기 – 주문 – 결제 - 음료 대기 - 음료 픽업 - 좌석 이용 / 픽업
실제 행동 관찰
인사이트 도출

인사이트 도출

고객을 관찰하며 인사이트를 도출할 때 염두에 둬야 할 것은 ‘해결해야 할 문제가 무엇인가’이다. 자칫 관찰을 하다보면 고객의 특징이나 차별점이 중요하다는 함정에 빠질 수 있다. 중요한 것은 Product Market Fit (이하 ‘PMF’) 으로서 검증할 만한 특징을 발견해야 한다는 점이다.

다음은 필자가 PMF에 유의미한 방향을 고려하여 스타벅스 고객을 관찰 및 정리한 인사이트다.

<출처: 구글, 작가 편집>

1) 앱 주문 보다 현장 주문을 선호한다.

행동 관찰: 앱 주문 보다 현장 주문이 높다. 줄을 서면서도 앱 사용을 하지 않는다.
문제: 앱이 “시간 절약 가치”를 제공하지 못한다.
PMF 인사이트: 앱 주문 경험 가치가 “빠름”이 아닌, 다른 가치가 필요하다. “경험을 방해하지 않는 주문 방식”이 필요하다.

2) 리워드/보상에 대한 인식 차이

행동 관찰 : 리워드 적립을 하지 않는다.
문제 : 리워드가 앱 사용을 유도하는 장치로 작동하지 않는다.
PMF 인사이트 : “즉각적이고 체감되는 가치”가 필요하다.

3) 결제 방식 차이

행동 관찰 : 앱 결제를 하지 않는다
문제 : 컨택리스(비접촉 결제 서비스로, 카드를 대기만 하면 결제되는 방식)로 현장 결제가 더 빠르다.
PMF 인사이트 : 앱이 기존 결제보다 확실히 더 편해야만 사용된다.

4) 온라인 바우처(예)기프트콘) 문화 차이

행동 관찰 : 온라인 바우처 선물 사용이 낮다.
문제 : 실물 기프트 카드 중심 문화로, 온라인 바우처 문화가 생활 방식에 없다.
PMF 인사이트 : 미리 준비하는 선물보다는, 자연스럽게 발생하는 선물 순간에 맞춰야 한다.

가설 세우기: 인사이트에서 가설 세우기

고객 행동 관찰을 통해 얻은 네 가지 인사이트 중, 두 가지를 예시로 가설과 검증 지표를 설정했다. 먼저‘앱 주문 보다 현장 주문을 선호’하는 고객 행동으로 알 수 있는 것은 ‘앱 주문 경험 가치가 “빠름”이 아닌, 다른 가치가 필요하다는 점’이다. 이때 서비스는 ‘더 좋은 경험을 주는 것’으로 접근해야 한다. 고객이 커피 주문하는 경험을 방해하는 것은 무엇일까. 그것을 제거하여 더 좋은 경험을 제공할 수 있을 것이다.

고객은 항상 마시는 음료가 있거나 간혹 새로운 메뉴를 시도해 보는 경우로 나뉜다. 그렇다면 개인화를 통해 두 가지 가설을 검증할 수 있겠다. 첫째 가설은 ‘주로 주문하는 음료를 원클릭으로 재주문할 수 있다면, 앱 주문율이 증가할 것이다.’이며, 또 다른 가설로는 ‘선호하는 음료 스타일에 따라 새로운 메뉴 3가지 추천하여 앱이 대신 선택을 줄여주면, 앱 주문율이 증가할 것이다.’이다. 이에 대한 검증 지표로 ‘같은 음료 재주문 비율’, ‘추천 메뉴 클릭률’, ‘전체 앱 주문 전환율’ 등으로 측정할 수 있겠다.

<출처: 구글, 작가 편집>

다음으로, ‘리워드/보상에 대한 인식 차이’를 통해 알 수 있는 것은 리워드가 앱을 사용하는 행동 유도 장치로 작동하지 않는다는 점이다. 이 경우 고객에게는 “즉각적이고 체감되는 가치”가 필요하다. 그렇다면 다음 가설을 설정할 수 있겠다. ‘고객은 단순 포인트 적립보다 “즉각적 보상”이 있을 때 앱 사용 빈도가 증가한다.’를 가설로 두고, 즉각적 보상을 주는 경험을 설계해 가설 검증을 할 수 있겠다. 예로 ‘주문 즉시, 무료 사이즈 업 혹은 즉시 할인 쿠폰을 제공하면 앱 사용 빈도가 증가할 것이다.’를 가설로 두어 실행하여, 검증 지표로 리워드 페이지 접속률, 앱 주문 전환율로 측정할 수 있을 것이다.

<출처: 구글, 작가 편집>

마치며

해외 시장에서 앱 서비스를 성공적으로 정착시키기 위해, 혹은 새로운 타깃 고객으로 새로운 시장을 개척하려 할 때, 중요한 것은 단순한 기능이나 UX가 아닌 타깃 고객이 가진 문제를 이해하는 것이다. 이러한 환경에서는 기존 시장에서 검증된 가설이나 데이터에 의존하기 어렵기 때문에, 문제 정의의 출발점부터 다시 고객을 이해하는 과정이 필요하다. 이번 글에서 다룬 Customer Journey Shadowing은 바로 이러한 상황에서 유용한 방법으로, 사용자의 말이 아닌 실제 행동을 기반으로 숨겨진 문제를 발견할 수 있게 한다.

결국 중요한 것은 “이 시장의 고객은 어떤 문제를 중요하게 느끼는가”를 먼저 정의하는 것이다. Customer Journey Shadowing을 통해 얻은 행동 기반 인사이트는 단순한 관찰에 그치지 않고, PMF 관점에서 의미 있는 가설로 전환될 때 실행 가능한 전략이 된다. 따라서 새로운 국가나 시장에서 제품을 확장할 때는 기능 중심이 아니라, 고객 여정 기반의 ‘문제 재정의 → 행동 관찰 → 가설 수립 → 검증’의 반복 구조가 필수일 것이다.

]]>

2개의 스쿼드를 AI와 함께 이끌어봤습니다

국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하고 있을까요?

이번 글에서는 글로벌 알람 앱 ‘알라미’를 서비스하는 딜라이트룸이 2개의 스쿼드를 각각 주니어 AI에게 맡긴 과정에 대해 소개합니다.

올해 들어 제품 내에서 살펴야 할 피처의 넓이와 깊이가 모두 깊어졌고, 인수한 제품의 특성상 우리가 아직 모르는 동작도 훨씬 많아졌습니다. 그 와중에 2개의 스쿼드의 PO 역할을 담당하려다 보니, 물리적으로 혼자 감당할 수 있는 범위를 이미 넘어선 상황이었죠. 그래서 두 주니어 AI를 통해 빈자리를 단단하게 채워보려고 했습니다. 그 과정을 지금부터 소개하겠습니다.

Devin은 코드베이스를 꿰뚫는 주니어 Dev입니다.
Claude는 제품 로드맵 구축부터 백로그 배포 이후의 후속 기획까지 함께 뛰는 주니어 PO입니다.

Devin: 코드 및 데이터베이스를 꿰뚫는 주니어 Dev

Devin에게 부여하는 역할은 크게 네 가지입니다.

1) Reader

“이 기능 지금 어떻게 동작해?” 하고 물으면 코드를 읽고 플로우를 정리해 주고, 관련 수치까지 뽑아줍니다. 복잡한 코드를 대신 읽고 구조화해 주기 때문에, 기획 단계에서 많은 리소스를 아낄 수 있습니다. 인수한 제품이라 우리가 모르는 동작이 훨씬 많은 환경에서는 특히 유용합니다.

2) Debugger

문제가 터졌을 때 원인을 함께 디깅 합니다. 영향을 줄 수 있는 코드 내 다양한 변인을 같이 검토해 주고, 과거 커밋 히스토리까지 알고 있기 때문에 “이전에는 어떻게 동작했는지”도 추적할 수 있습니다.

3) Developer

간단한 코드 수정은 직접 해주기도 합니다. 물론 더 대단한 개발도 해주기야 하겠지만, 아직은 그 결과물을 온전히 신뢰하기 어려운 단계입니다. (그가 책임을 지지는 못하기 때문에…) 운영상의 불편함을 한 번의 코딩으로 갈음해 주는 역할도 해주곤 합니다. 사실 이 역할을 더 많이 활용해야 하는데, 이번 분기에는 미진했네요. 다음 분기를 기약해 봅니다. 아무래도 백로그가 잔뜩 쌓여있을 때 더 빛을 발할 것 같네요.

4) DA

예상 임팩트 계산, 코호트 분석, 교차 분석도 수행합니다. 매출 데이터만 해도 웹 결제냐 앱 결제냐에 따라 참고해야 할 소스가 다르고, 유저 액티비티 값 역시 서버값과 클라이언트값을 잘 교차해서 써야 합니다. Devin은 AMP, Stripe, Qonversion 등 여러 데이터 소스를 넘나들며 이걸 해주고, taxonomy도 이미 파악하고 있어서 매번 설명할 필요가 없습니다.

또한 때로는 무의미해 보일 수 있을 정도로 세세한 데이터 분석을 해보고 싶을 때가 있는데, (간혹 그 속에서 좋은 시드를 찾을 때가 있긴 하니까) 그럴 때도 데빈이는 묵묵히, 또 빠르게 결과 값을 가져다주어 속 시원함을 제공해 주기도 합니다.

Claude: 제품 전략부터 기획까지 함께하는 주니어 PO

Claude가 맡은 메인 역할은 세 가지입니다.

1) Discussion Partner

가장 많이 쓰는 역할입니다. 문제 정의가 틀어졌을 때, 더 나은 대안이 있을 때, 논리에 구멍이 있을 때, 리스크를 놓쳤을 때, 대화를 통해 잡아냅니다. 실제로 백로그 검토 및 쟁점 정리, 온보딩 이후 문제 정의와 솔루션 기획, 스쿼드 회고 정리, 온보딩 플로우 재구성 등 다양한 국면에서 이 역할을 활용했습니다.

2) Document Editor

저는 맥락을 최대한 주기 위해 raw data를 통째로 던지는 편입니다. 두서없이 적어 내려간 사고 흐름, 유저 인터뷰 원문, 서베이 응답 같은 날것의 데이터를 문서 목적에 맞게 정리해 줍니다. 대부분의 PRD와 분석 문서 등 주요 문서들은 클로드가 작성해 주죠. 특히 이번 분기는 영어권 국가 유저 인터뷰를 진행하느라 영어 <> 한국어 간 넘나듦이 문서상에서도 빈번했는데, 알아서 어련히 깔끔하게 잘해주니 이보다 든든할 수 없었죠.

3) DA

주어진 데이터와 기획 의도, 맥락을 기반으로 가설을 검증하고 후속 액션 아이템을 뽑아줍니다. 데빈이가 실제 코드 베이스와 데이터베이스를 넘나들 수 있는 역량이 있다면, 클로드는 그걸 읽고 해석하는 두뇌가 더 명석합니다. 둘의 합작으로 유의미한 분석 결과들을 내주고 있습니다.

데빈이가 필요한 데이터 뽑아주고, 클로드가 전체 맥락에서 정리해 줍니다.

이보다 마이너한 활용도 있습니다.

Visualizer로서 그래프, 다이어그램, 발표 자료 같은 것들을 빠르게 만들어주고, Copywriter로서 완벽한 카피는 아니더라도 시드를 발산하는 데 도움을 줍니다. 반면, Researcher로는 거의 쓰지 않습니다. 그 이유는 보통 레퍼런스 리서치를 할 때는 실제 그 앱들을 직접 만져보며, 화면과 플로우를 확인해야 제대로 알 수 있는 영역이라, AI가 대체하기 어렵습니다.

잠시 희망을 가졌지만, 결국 직접해야 하는 부분입니다.

마치며: 주니어를 다루듯이

여기까지 읽으면 “딸깍” 한 번이면 AI가 다 해주는 것처럼 들릴 수 있습니다. 하지만 이 둘은 결국 주니어입니다. 그것도 성향이 좀 다른 주니어들입니다. 그래서 기대치를 어느 정도 낮추고, 적절하게 위임해야 합니다.

Devin은 부지런하지만 좀 덜렁거리는 타입입니다.

참고해야 할 코드베이스나 데이터 소스를 착각하는 경우가 종종 있어서, 결과물은 반드시 크로스 체크해야 합니다. 또한 조사해야 할 영역을 명확히 좁혀주지 않으면, 꽤 멀리 엄한 곳까지 헤매다 돌아오기도 합니다. 그래서 스코프를 잘 잡아주는 게 중요합니다.

Claude는 더 똑똑하지만, 다른 종류의 주의가 필요합니다.

전체 맥락을 다 품지 못하기 때문에 우선순위를 혼자 잘못짚을 때가 있고, 불필요한 내용을 과하게 담아서 오히려 가독성을 떨어뜨리기도 합니다. 없어도 전체 이해에 지장 없는 건 과감히 쳐내는 게 좋습니다. 임팩트 추정에서는 여러 변수에 가정치를 넣는 경우가 있는데요. 그 가정치가 적절한지는 PO의 직관으로 반드시 검증해야 합니다. 정리된 결과물의 직접 검수하는 건 필수입니다.

둘 다 결국 같은 원칙이 적용됩니다.맥락을 나보다는 잘 알 수가 없습니다. 가장 상위에서의 머리 역할은 제가 수행해줘야 합니다.

다만, 주니어를 다루듯이 대한다는 건 한계만 인식하라는 뜻은 아닙니다.맥락을 잘 넘겨주고, 역할을 명확히 정의하고 피드백을 주면, 똑똑한 주니어답게 점점 더 일의 합이 잘 맞습니다. 가르쳐주면 가르쳐줄수록 일을 더 잘하는 친구들이니까요.

AI 기술이 워낙 빠르게 발전하고 있으니, 다음 분기에는 아마도 이 둘의 직급을 올려줄 수 있지 않을까 기대하고 있습니다. 그리고 느낌상 둘이 직접 소통할 수 있게 해 두면 더 수월할 것 같은데, 그건 다음 분기에 다뤄보겠습니다. 읽어주셔서 감사합니다!

<원문>

AI와 함께 이끌어온 2개의 스쿼드

]]>

16년 된 백준(BOJ)이 문을 닫습니다

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Code Routines - 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능
참고할 것: BOJ(백준 온라인 저지) - 16년간 한국 개발자와 함께한 백준이 문을 닫습니다
적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

<출처: claude.ai>

1. 써볼 것: 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능

Claude Code에 Routines라는 기능이 추가됐습니다. 프롬프트, 레포지토리, 커넥터를 한 번 설정해두면 스케줄이나 GitHub 이벤트에 맞춰 자동으로 실행되는 기능인데요. Anthropic 클라우드에서 돌아가기 때문에 노트북을 닫아도 작업이 계속됩니다. 아직 research preview 단계이지만, Claude Code를 쓰는 개발자들 사이에서 관심을 받고 있습니다.

무슨 문제를 해결해 주나요?

코딩 에이전트는 지금까지 사람이 앉아서 지시하고 결과를 확인하는 방식이었습니다. Claude Code든 Cursor든, 내가 대화창에 뭔가를 입력해야 일이 시작되죠. PR이 올라올 때마다 리뷰를 시키려면 그때마다 직접 세션을 열어야 했고, 매일 아침 이슈를 정리하려면 매번 같은 프롬프트를 붙여넣어야 했습니다. Routines는 이 반복을 자동화하는 기능이죠. 한 번 설정해두면 정해진 시간에, 또는 특정 이벤트가 발생할 때 알아서 실행됩니다.

어떻게 쓰나요?

claude.ai/code/routines에서 만들 수 있고, Claude Code CLI에서 /schedule 명령어로도 생성할 수 있습니다. 설정할 때 필요한 건 세 가지입니다. 실행할 프롬프트, 작업할 GitHub 레포지토리, 그리고 트리거 조건입니다.

트리거는 세 종류를 지원합니다.

스케줄: 매시간, 매일, 평일, 매주 등 주기를 정할 수 있습니다. 커스텀 cron 표현식도 가능하고요. 최소 간격은 1시간입니다.
GitHub 이벤트: PR이 열리거나, 릴리스가 생성되거나 할 때 자동으로 실행됩니다. PR 작성자, 제목, 라벨, 드래프트 여부 등으로 필터링도 가능합니다.
API 호출: HTTP POST 요청으로 실행할 수 있어서, 모니터링 도구나 배포 파이프라인과 연결할 수 있습니다.

하나의 Routine에 트리거를 여러 개 붙일 수도 있습니다. 예를 들어 PR 리뷰 Routine을 만들어서, 새 PR이 열릴 때도 실행되고 매일 밤에도 실행되게 설정할 수 있죠. 실행 결과는 일반 Claude Code 세션처럼 열어볼 수 있습니다. 뭘 했는지 확인하고, 변경 사항을 리뷰하고, PR을 만들 수도 있고요.

공식 문서에서 제시하는 활용 예시를 보면, 어떤 작업에 쓸 수 있는지 감이 옵니다. 매일 밤 이슈 트래커를 읽고 라벨을 붙이고 담당자를 배정한 뒤 Slack으로 요약을 보내는 백로그 관리, 모니터링 알림이 오면 스택 트레이스를 분석하고 최근 커밋과 연결해서 수정 PR 초안을 만드는 알림 분류, 병합된 PR을 스캔해서 API가 바뀐 문서를 찾아내고 업데이트 PR을 여는 문서 관리 같은 것들입니다.

다만 Routines는 완전 자율 모드로 실행됩니다. 중간에 승인 프롬프트가 뜨지 않아요. 셸 명령어를 실행하고, 레포에 커밋된 스킬을 쓰고, 연결된 커넥터(Slack, Linear 등)를 통해 외부 서비스에도 접근합니다. 그래서 필요한 레포와 커넥터만 연결하는 게 중요합니다. 그리고 아직 research preview라서 동작 방식이나 한도가 바뀔 수 있습니다. Pro, Max, Team, Enterprise 플랜에서 쓸 수 있고, 계정당 일일 실행 횟수에 제한이 있습니다.

누구에게 좋을까요?
Claude Code를 이미 쓰고 있으면서, PR 리뷰나 이슈 정리 같은 반복 작업을 자동화하고 싶은 개발자
CI/CD 파이프라인에 AI 코드 리뷰나 배포 후 검증을 붙이고 싶은 팀
매일 아침 또는 매주 돌아오는 정형화된 코드 작업이 있는 사람

<출처: BOJ(백준 온라인 저지)>

2. 참고할 것: 16년간 한국 개발자와 함께한 백준이 문을 닫습니다

BOJ(백준 온라인 저지)가 4월 28일자로 서비스를 종료합니다. 운영자 최백준 님이 직접 게시판에 올린 공지인데요. 한국 개발자 커뮤니티에서 즉시 화제가 됐습니다. 2010년부터 16년간 운영된 이 사이트는 3만 4천 개 이상의 프로그래밍 문제와 73개 언어 채점을 지원하며, 한국에서 알고리즘을 공부하는 사람이라면 거의 다 거쳐갔다고 보아도 무방한 곳입니다. 많은 개발자의 성장을 도운 BOJ가 이제는 추억 속의 사이트가 된다고 합니다.

운영자에게 인사를 남기는 사용자들
<출처: BOJ(백준 온라인 저지)>

BOJ가 어떤 곳이었나요?

한국 IT 업계에 있는 사람이라면 백준을 한 번쯤은 들어봤을 겁니다. 개발자가 아니더라도, 코딩 테스트를 준비하는 후배나 동료가 있다면 백준이라는 이름은 익숙하죠. 알고리즘 문제를 풀고 온라인으로 채점받는 사이트인데, 단순히 문제만 있는 건 아니었습니다. 단계별 학습, 문제집, 그룹, 대회, 게시판까지 알고리즘을 중심으로 한 학습 생태계가 만들어져 있었습니다.

solved.ac라는 서드파티 서비스가 문제 난이도와 사용자 티어를 매기면서 게이미피케이션 요소까지 더해졌고요. 백준 티어가 개발자들 사이에서 실력의 지표처럼 쓰이기도 했습니다. 한국 기업의 코딩 테스트 문화와 함께 성장한 플랫폼이라고 볼 수 있습니다.

무엇이 남고, 무엇이 사라지나요?

종료 공지에 따르면, 서비스 종료 시점에 문제 데이터, 제출 기록, 대회 정보는 보존됩니다. 나머지 데이터는 삭제될 예정이고요. 최백준 님은 완전히 사라지기보다는 문제만이라도 다시 볼 수 있는 형태로 돌아올 수 있도록 고민하고 있다고 밝혔습니다. 상황이 달라지면 서비스를 재개할 가능성도 열어두고 있다고요. 서비스 종료 전까지는 정상 이용이 가능하지만, 문제집이나 그룹 생성 같은 일부 기능은 제한될 수 있다고 합니다.

무엇을 얻어가야 하나요?

한 사람이 시작한 사이드 프로젝트가 16년간 업계 인프라 역할을 했다는 것 자체가 큰 의미가 있는 사례라고 생각합니다. 마지막까지 문제 데이터와 제출 기록은 보존하는 결정을 내린 부분에서, 운영자가 생각하는 핵심 가치를 엿볼 수 있을 것 같습니다.

종료 소식을 접한 커뮤니티 반응도 인상적이었는데요. 시대가 바뀌었고 코딩 테스트의 의미가 예전 같지 않다는 목소리가 꽤 있었습니다. AI 코딩 에이전트가 알고리즘 문제를 풀 수 있는 시대에, 알고리즘 문제 풀이 능력이 개발자 역량의 기준이 될 수 있느냐는 질문이죠. 반면에 코드가 무엇을 하는지 이해하는 기초 체력은 여전히 필요하다는 반론도 있었고요. 정답이 있는 논쟁은 아니지만, 이번 주 적용해볼 것에서 다루는 사례를 보면 이 질문이 왜 중요한지 조금 더 구체적으로 느껴질 겁니다.

<출처: tobru.ch>

3. 적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

스위스의 보안 엔지니어 Tobias Brunner가 3월 28일 블로그에 올린 글입니다. 자기가 직접 겪은 바이브 코딩 호러 스토리라는 제목인데요. 보안 커뮤니티에서 바이브 코딩의 실제 위험을 보여주는 사례로 공유되고 있습니다. AI 코딩 도구로 앱을 만드는 사람이 늘어나는 지금, 무엇이 빠지면 어떤 일이 벌어지는지를 보여주는 글입니다.

무슨 일이 벌어졌나요?

Tobias Brunner가 병원에 갔는데, 접수 담당자가 요즘 AI로 누구나 소프트웨어를 만들 수 있다는 영상을 봤다고 하면서 직접 환자 관리 시스템을 만들었다고 했다고 합니다. 기존에 쓰던 환자 데이터를 전부 가져와서 새 앱에 넣고, 인터넷에 배포하고, 진료 중 대화를 녹음해서 AI 서비스 두 곳으로 보내 자동 요약하는 기능까지 만들었다고요.

Brunner가 며칠 뒤 이 앱을 살펴봤더니, 30분 만에 전체 환자 데이터에 읽기·쓰기 권한을 확보할 수 있었다고 합니다. 모든 데이터가 암호화 없이 인터넷에 열려 있었던 거죠. 바로 담당자에게 알렸더니, 돌아온 답변은 AI가 자동 생성한 감사 메시지였다고 합니다. 기본 인증을 추가하고 접근 키를 교체했다는 내용이었는데, Brunner는 이 사람이 자기가 뭘 만들었는지 이해하지 못하고 있다고 봤습니다.

기술적으로 무엇이 빠져 있었나요?

Brunner가 설명하는 기술적 구조를 보면, 앱 전체가 HTML 파일 하나였다고 합니다. JavaScript, CSS, 모든 구조가 인라인으로 들어가 있는 단일 파일이었고요.

백엔드는 접근 제어가 전혀 설정되지 않은 관리형 데이터베이스 서비스를 썼다고 합니다. 행 수준 보안(row-level security)도 없었고요. 접근 제어 로직이라고 할 수 있는 건 클라이언트 측 JavaScript에만 있었는데, 이건 브라우저에서만 작동하는 거라 curl 명령어 한 줄이면 데이터에 바로 접근 가능한 상태였다고요.

음성 녹음 파일은 외부 AI API로 직접 전송되어 전사와 요약 처리가 됐고, 데이터는 미국 서버에 저장되어 있었는데 데이터 처리 계약(DPA) 없이 운영되고 있었다고 합니다. 환자에게 이런 데이터 처리에 대한 사전 고지도 없었고요. Brunner는 이 행위가 스위스 데이터 보호법(nDSG)과 직업상 비밀 유지 의무를 여러 조항에서 위반했을 가능성이 높다고 판단했습니다.

왜 이런 일이 생기는 건가요?

이 사례에서 빠진 건 코딩 능력이 아닙니다. AI 코딩 에이전트가 코드를 만들어주는 건 잘 했으니까요. 앱은 돌아갔고, 기능도 잘 작동했을 겁니다. 빠진 건 코드가 어떻게 작동하는지에 대한 이해였습니다. 클라이언트 측 접근 제어가 왜 보안이 아닌지, 데이터베이스에 접근 권한을 왜 설정해야 하는지, 환자 데이터를 외부 서비스로 보낼 때 어떤 법적 요건이 필요한지. 이런 판단은 AI 코딩 에이전트가 알아서 해주지 않습니다. 코드를 생성하는 것과 그 코드가 안전한지 판단하는 것은 완전히 다른 영역이죠.

Brunner 본인도 AI 코딩 에이전트를 쓴다고 밝혔습니다. 다만 자기는 코드를 읽을 수 있고, 소프트웨어 아키텍처를 이해하고 있기 때문에 쓸 수 있는 거라고요. 분위기에 취해서 만드는 것(vibing away)만으로는 안전한 결과가 나오지 않는다는 게 그의 결론입니다.

적용해볼 질문

내가 AI 코딩 도구로 만든 코드에서 접근 제어가 서버 측에 있는가, 클라이언트 측에만 있는가?
외부 API로 데이터를 보내고 있다면, 어떤 데이터가 어디로 가는지 파악하고 있는가?
AI가 만들어준 코드의 아키텍처를 내가 설명할 수 있는가?

실행해볼 수 있는 것

AI 코딩 에이전트로 만든 프로젝트가 있다면, 백엔드 접근 제어가 제대로 설정되어 있는지 확인해보기. 클라이언트 측 JavaScript에만 의존하고 있다면 서버 측 인증을 추가하기.
외부 API를 쓰고 있다면, 어떤 데이터가 어디로 전송되는지 한 번 정리해보기. 민감한 데이터가 포함되어 있다면 데이터 처리 계약이 필요한지 확인하기.
AI가 생성한 코드를 배포하기 전에, 최소한 보안 체크리스트 하나를 통과시키는 습관 만들기. 인증, 암호화, 접근 권한, 데이터 흐름

이 네 가지만 확인해도 이 사례 같은 사고는 막을 수 있습니다.

오늘 내용, 이렇게 적용해보세요

AI 에이전트에게 반복 작업을 맡기되, 맡기는 작업의 범위와 권한을 명확히 정해두기. Routines처럼 자동으로 돌아가는 작업일수록 어떤 레포에 접근하고 어떤 서비스에 연결되는지 꼭 확인하기.
AI가 만든 코드를 배포하기 전에, 보안 관점에서 한 번 훑어보는 습관 만들기. 인증이 서버 측에 있는지, 데이터가 어디로 가는지, 접근 권한이 적절한지. 이 세 가지만 확인해도 많은 사고를 막을 수 있습니다. (AI 시대에도 코드를 읽는 능력은 여전히 기반입니다. AI가 생성한 코드가 무엇을 하는지 설명할 수 없다면, 그건 아직 배포할 준비가 안 된 겁니다)

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

[요즘IT 콘텐츠 AX] 기업 블로그 에이전트의 가능성과 한계 웨비나 오픈!

“콘텐츠 담당자를 위한 기업 블로그 에이전트 가능성과 한계” 웨비나 오픈

“AI로 콘텐츠 자동화하기” 콘텐츠를 만들어 본 분들이라면 한 번쯤은 생각해 보셨을 텐데요. 막상 해보면 글 한 편은 어떻게 완성되는데, 기획부터 발행까지 전체를 자동으로 돌리는 작업은 생각보다 훨씬 복잡합니다. 원했던 퀄리티가 나오지 않을 때도 많고요.

그래서 요즘IT가 직접 부딪혀봤습니다. 위시켓 기업 블로그를 대상으로, 콘텐츠 마케터의 워크플로우를 6단계로 나누고 각 단계에 AI 에이전트를 붙였습니다. 비개발자가 클로드 코드로 월간 12건의 콘텐츠 기획부터 발행까지 자동화한 과정, 그 한계와 가능성을 솔직하게 공유합니다.

정답이 있는, 이론을 배우는 자리는 아닙니다. 대신 직접 만들면서 겪은 것들을 있는 그대로 나눠보려고 합니다.

[요즘IT 콘텐츠 AX 실험기 미리보기]

웨비나 정보

일시: 2026년 4월 17일(금) 저녁 7:00
형태: 온라인 라이브 (Zoom)
구성: 발표 30분 + Q&A 20분
참가 비용: 얼리버드 ~~15,000~~ ▶11,900원 (4/16일까지)
신청 링크:웨비나 신청하기
슬라이드: 참여자에게 발표 슬라이드 PDF 제공 (웨비나 전날 이메일 발송)
녹화본: 따로 제공되지 않습니다.

웨비나에서 이런 이야기를 다룹니다

01. 파이프라인 전체 구조

콘텐츠 마케터의 워크플로우를 세분화하고, 각 단계에 에이전트를 붙인 구조. 왜 이렇게 나눴고, 어디서 사람이 개입하는지 살펴봅니다.

02. 시행착오 기록

키워드 수집에서 노이즈가 터진 일, 기존 글과 중복 판정이 안 맞았던 일, GEO 최적화와 브랜드 톤이 충돌한 일. 실제 겪은 문제들과 대응 과정을 살펴봅니다.

03. 도메인 지식의 벽

기업 담당자만 아는 비즈니스 맥락을 AI에 주입하는 것이 왜 어렵고, 어디까지 가능했는지 알아봅니다.

04. 생성 품질의 현실

AI가 쓴 글이 "사람이 읽을 만한 글"이 되려면 무엇이 필요한지. 현재 수준은 어디이고, 무엇이 부족한지 알아봅니다.

05. 직접 만들 때 알아야 할 것

에이전트가 정확히 뭔지, 어떻게 만드는지, 어디까지 자동화되고 어디서 사람이 판단해야 하는지 살펴봅니다.

발표자

장대청(요즘IT 그로스 파트 리드 · 위시켓)

비개발자. 코드를 직접 짜지 않고, 업무 매뉴얼을 자연어로 정의하면 클로드 코드가 코드를 짜는 방식으로 파이프라인을 구축했습니다. 위시켓 기업 블로그 자동화 프로젝트의 설계와 실행을 담당하고 있습니다.

이런 분들께 추천해요

기업 블로그나 콘텐츠 마케팅을 담당하면서 AI 자동화를 검토 중인 분
에이전트가 궁금한데, 실제 사례를 먼저 보고 싶은 분
직접 파이프라인을 만들어보고 싶은데, 전체 그림이 안 잡히는 분
코드는 나오지 않습니다. 구조와 판단 과정, 시행착오 중심으로 이야기합니다. 사전 등록자의 77%가 비개발자(PM, 기획자, 콘텐츠 마케터)였습니다.

자주 묻는 질문

Q. 비개발자인데 이해할 수 있나요?

네. 사전 등록자의 77%가 비개발자(PM, 기획자, 콘텐츠 마케터, 경영진)입니다. 코드는 나오지 않습니다. 구조와 판단 과정, 시행착오 중심으로 이야기합니다.

Q. 웨비나를 듣고 바로 자동화를 구축할 수 있나요?

이 웨비나는 정답이나 성공 공식을 알려주는 자리가 아닙니다. 에이전트로 블로그를 자동화한다는 것이 실제로 어떤 것인지, 클로드 코드로 그것을 어떻게 시작하는지, 그 과정에서 부딪히는 문제들은 무엇인지, 직접 해본 사람의 경험과 시행착오를 공유합니다. 되는 것과 안 되는 것의 경계를 이해하고, 스스로 판단 기준을 세울 수 있도록 돕는 자리입니다.

Q. 우리 회사에도 적용 가능한가요?

기업 블로그 콘텐츠를 정기 발행하는 팀이라면 파이프라인 구조 자체는 적용 가능합니다. 다만 도메인 지식을 AI에 주입하는 과정이 핵심 과제이며, 이 부분의 현실적인 난이도를 웨비나에서 다룹니다.

Q. 녹화본이 제공되나요?

녹화본은 제공되지 않습니다. 참여자에게 발표 슬라이드 PDF를 웨비나 전날 이메일로 발송해드립니다.

Q. 환불이 가능한가요?

웨비나 당일 전까지 환불 요청 시 전액 환불됩니다.

마치며

강의가 아니라 경험담을 나누는 자리입니다. 잘 된 것도, 막혔던 것도, 아직 안 되는 것도, 모두 있는 그대로 공유합니다. "우리 팀도 해볼 수 있을까?"라고 고민하고 계신 분들께 도움이 되길 바랍니다. 그럼 4/17일 웨비나에서 만나요!

[→웨비나 신청하기]

]]>

새로 출시한 이 기능은 DAU 얼마짜리 기능일까?

이번 글에서는 글로벌 알람 앱 ‘알라미’를 서비스하는 딜라이트룸이 신규 기능의 DAU를 분석하고, 전략을 세운 과정에 대해 소개합니다.

신규 기능 A와 B의 최종 사용자 수는?

들어가기 전 짧은 퀴즈 하나!

여기 최근 출시된 2개의 피처(Feature) A와 B가 있습니다. 오픈 후 데이터를 살펴보니, 피처 A는 일 6,700명의 신규유저가 들어오고 D1 리텐션은 7%인 반면, 피처 B는 일 600명의 신규유저가 들어오고 D1 리텐션은 35%를 기록하고 있습니다. 그럼 피처 A와 B는 각각 어느 정도의 DAU로 수렴할까요? 과연 피처 A와 B 중 어느 피처가 더 많은 사용자를 확보할 수 있을까요?

새로운 기능은 나한테도 새로운데…

제품 개발 사이클에서는 새로운 먹거리 탐색을 위해 심심치 않게 크고 작은 새로운 피처를 선보이게 됩니다. 새로운 피처일수록 PO, DA 모두 숫자에 대한 감을 잡기 어렵기 때문에, 이 피처가 어느 정도 성장할 수 있을지, 무엇을 더 어떻게 하면 성장시킬 수 있을지는 굉장히 복잡한 질문입니다.

최근 알라미도 여러 새로운 기능들을 시도해 보고 있어, 이런 고민들이 예외가 아닌데요. 이렇게 초면인 피처들을 분석하는 관점에서 좀 더 쉽게 숫자에 대한 감을 잡고, 전략 방향을 뽑아낼 수 있을지 고민해 본 내용을 공유하고자 합니다.

무엇이 중요할까?

새로운 기능에 대한 Capacity(수용 여력)를 분석하고, 지표 방향을 잡는 과정에서는 크게 아래 두 가지 질문에 답할 수 있어야 하는데요.

어떤 lever(핵심 조정 변수)가 전체 사용자 수를 얼마나 움직일 수 있는가?
그 lever들이 선행 지표로서 역할을 할 수 있는가? 측정에 너무 오랜 시간이 걸려 액션이 지체되진 않는가?

예를 들어, 신규 유저가 2배가 되어도 리텐션(사용자 유지율)이 너무 낮아 실제 사용자 수는 10%밖에 증가하지 않을 수 있는데요. 리텐션이 20%만 증가해도 실제 사용자 수가 50% 증가할 수 있다면 리텐션(사용자 유지율)을 올리는 방향이 더 현명한 방법이겠죠. 그리고 리텐션에 집중한다고 해도, 만약 월간 리텐션 수치가 필요하다면, 일간 리텐션에 비해 액션의 결과를 확인하는 기간이 1일에서 1달로 늘어나게 됩니다. 이는 다음 액션의 속도를 늦추게 됩니다.

몇 년 전 스타트업을 흔들었던 그 공식

몇 년 전 토스에서 ‘Carrying Capacity’라는 개념을 인용하며, 서비스의 Capacity를 가늠할 수 있는 프레임워크가 많은 관심을 받은 적이 있는데요.

CC = # of new daily(period) customers / % customers you lost each day(period) (자료 참고)

신규 유저 수와 유저의 daily churn을 활용해, 일반적인 등비급수의 합 공식을 통해 보면, 겉으로 보기에는 매우 단순하게 일별 잔존 유저들의 합으로 서비스의 전체 유저 수를 가늠해볼 수 있습니다.

등비급수의 합 공식 (일정한 a, 일정한 r)

하지만 실제 서비스에 도입해보려 하다 보면, 이게 맞나…? 싶은 순간이 생기는데요. 피처 A를 예로 들면, 하루에 6,700명이 유입되지만 정작 DAU는 7,000밖에 되지 않는 서비스라는 결론이 나옵니다. (스포: 실제로는 2만이 넘는데도 말이죠.)

6700 / (1–7%) = 6700 / 0.93 = 7200

Carrying Capacity 공식의 중요한 가정들은 아래와 같은데요.

Active User에 대한 정의를 실제로 WoW factor를 경험한 유저로 정의
이에 따라 낮은 churn rate를 기대하며, Day N에서 Day N+1일까지의 리텐션이 일정할 것이라 가정(매일 똑같은 r을 가정)

실제로 80%의 리텐션을 가정하고 y = 0.8^x 그래프를 그려보면, 30일이 되는 시점에는 거의 0에 수렴하는 것을 볼 수 있는데요. 리텐션 수치가 낮아질수록 생각보다 잔존 유저가 과소평가되는 면이 있다는 점을 확인할 수 있습니다.

하지만 실제 서비스에서는 일반 방문자 또한 Active 유저에 포함하는 경우가 많고, churn rate 또한 일정하게 떨어지기보다는 일별로 달라지는 경우가 더 일반적이기 때문에 공식과 실제 유저 수 사이에 괴리가 생기게 됩니다.

보편적인 신규 유저들의 리텐션 커브

일반적인 제품에서 신규 유저들은 초반 진입 이후, 일수가 증가함에 따라 초반에는 비교적 가파른 이탈률을 보이지만, 시간이 지날수록 이탈이 줄어들며, 점차 평평한 리텐션 커브가 형성되게 되는데요.

이를 보다 잘 설명해주는 리텐션 커브는 y = a * x^b 형식의 power law function입니다. 아래 이미지와 같이 단순히 0으로 수렴하는 것이 아니라, 리텐션 커브의 기울기가 점점 완만해지며 0 이상의 값으로 수렴하는 것을 확인할 수 있는데요.

즉, y = ‘x일 이후의 잔존율’로 보고, y = a * x^b에서 a(시작점)와 적절한 b(커브의 모양을 결정)를 찾아준다면 y의 누적합을 통해 전체 유저 수를 예측해 볼 수 있습니다.

오늘 전체 유저 수
= 오늘 신규 유저 + 어제 신규 유저 중 남은 유저 수 + 엊그제 신규 유저 중 남은 유저 수 + … + N일 전 신규 유저 중 남은 유저 수
= 신규 유저 수 * y(0) + 신규 유저 수 * y(1) + … + 신규 유저 수 * y(N)
= 신규 유저 수 * (y(0) + y(1) + … + y(N))

좀 더 ‘딸깍’스러운 공식

조금 복잡해 보이지만, 약간의 일반화를 거치면 각 서비스에 맞게 커스텀할 수 있으면서도, 누구나 쉽게 사용할 수 있는 공식을 만들어볼 수 있습니다.

오늘 전체 유저 수
= 신규 유저 수 * (y(0) + y(1) + … + y(N))
= 신규 유저 수 * a * (1^b + 2^b + 3^b + … + N^b)

여기서 a는 시작점이기 때문에 D1 리텐션 값을 사용할 수 있고, b의 경우 전체적인 리텐션 커브를 결정하는 계수인데요. 실제 기능의 리텐션 커브를 구하기 위해 1~2달을 기다린다면, 이런 계산을 하는 이유가 많이 사라집니다. 그래서 좀 더 보편적으로 b를 사용할 수 있도록 생각한 방법은 서비스 전체 신규 유저의 리텐션 커브를 활용하는 방법입니다.

신규 피처 또한 결국에는 신규로 들어온 유저들이 사용하게 되고, 리텐션 커브의 모양이 유저의 특성을 대변한다고 본다면, 같은 서비스 안에서는 유저들의 특성이 크게 변하지 않을 것이라는 가정입니다.

예시 코드와 같이 파이썬 scipy의 curve_fit을 사용해, 월별 Day 1 ~ Day 28 리텐션을 활용하여 b 값을 예측해본 후 평균값을 사용할 수 있습니다.

import pandas as pd
import numpy as np
from scipy.optimize import curve_fit

def func(x, a, b):
    return a * (x**b)  

df = client.query(query).to_dataframe()

date_list = ["'2025-07-01'", "'2025-08-01'", "'2025-09-01'", "'2025-10-01'", "'2025-11-01'", "'2025-12-01'"]
df_constant = pd.DataFrame([], columns=['basis_month', 'platform', 'a', 'b'])

platforms = ['ios', 'android']

for platform in platforms:
  avg_retention= df[df.platform == platform].avg_retention.values
  basis_month = df[df.platform == platform].basis_month.values[0]

  days = np.arange(1, 29)

  popt, pcov = curve_fit(func, days, avg_retention)

  retention_days = np.arange(1, 364)
  retention_rate = np.concatenate((np.array([1.0]), func(retention_days, *popt)))
  print(*popt)
  new_row_const = pd.DataFrame([[basis_month, platform, popt[0], popt[1]]], columns=['basis_month', 'platform', 'a', 'b'])
  df_constant = pd.concat([df_constant, new_row_const], ignore_index=True)

print("Total b Mean: ", np.mean(df_constant['b']))
print("Total Android b Mean: ", np.mean(df_constant[df_constant.platform == 'ios']['b']))
print("Total iOS b Mean: ", np.mean(df_constant[df_constant.platform == 'android']['b']))

마지막으로 (1^b + 2^b + 3^b + … + N^b)를 계산하기 위해 1년을 가정하고, x^b의 누적합을 구해주면

baseline = np.array([x**b_mean for x in range(1, 365)])
print(b_mean, ': ', np.sum(baseline))

간단한 하나의 식에 도달하게 됩니다. 알라미의 경우 평균 b를 대입한 값은 63 정도로 수렴했습니다.

최종 공식

신규 피처 DAU = 신규 유저 수 *신규 D1 리텐션 * 63

그래서 퀴즈 정답은요

위 공식을 통해 구해본 피처 A와 B의 예측 DAU와 실제 DAU가 기존 CC 방식보다 더 가까워진 것을 확인할 수 있었는데요. 물론 이 공식 또한 여러 가정이 있기 때문에 정확한 수치를 예측할 수는 없지만, 약간의 수고를 더한다면 우리 서비스에서 출시된 기능의 DAU가 1만이 될지, 5만이 될지, 10만이 될지 쉽게 가늠해보고, 현재 수치에서 어떤 레버를 얼마만큼 올려야 원하는 DAU를 달성할 수 있을지 판단하기 쉬워질 수 있다고 생각합니다.

또한 보다 즉각적인 지표인 신규 유저 수와 D1 리텐션 수치를 활용해, 비교적 짧은 시간 안에 여러 번의 iteration을 가져갈 수도 있습니다.

팁 요약

실제 서비스에 이 방식을 도입해보며 덧붙인 팁 몇 가지는 다음과 같습니다.

1) 지표가 어느 정도 안정화됐을 때의 수치를 쓰는 것이 정확도를 높였음

신규 피처의 경우 초반 오픈 효과, 배포율 등으로 초반 지표가 흔들리는 경우가 많아, 안정권에 들어온 지표를 쓰는 것이 정확도를 높였습니다.

2) 런칭 후 시간이 지난 피처의 경우 기존 유저가 쌓여 신규 유저 & 리텐션만으로는 반영이 어려움

기존에 쌓인 유저를 반영할 수 있도록 기존 유저 계수를 추가해 사용했습니다.

DAU = 신규 유저 수 *신규 D1 리텐션 * 기존 계수 + 기존 유저 계수

마치며: 100% 정확할 수는 없지만…

이 방식 또한 기존 가정들이 어긋나는 상황에서는 예측치가 다시 오류를 범할 수 있겠지만, 약간의 수고를 곁들인 추상화를 통해 쉽게 제품을 진단해볼 수 있는 방식에 도달하는 과정은 매우 즐거웠습니다. 여기까지 읽어주신 분들의 또 다른 고견도 기다리겠습니다.

<원문>
새로 출시한 이 기능은 DAU 얼마짜리 기능일까? (Carrying Capacity 적용이 어려울때)

]]>

Claude Code로 코드 한 줄 없이 마케팅팀을 만드는 법

본문은 요즘 IT와 번역가 Yuna가 함께 이성원(Snow W. Lee) 님의 글<How I Built an AI Marketing Team with Claude Code (and Cowork)>를 번역한 글입니다. 필자는 Runbear의 공동창업자이자 CEO로, AI가 일상적인 업무에 자연스럽게 녹아들 수 있도록 돕는 것을 미션으로 삼고 있습니다. Runbear는 글로벌 스타트업 액셀러레이터 Techstars의 2024년 선발 기업입니다.

이 글은 Claude Code와 Cowork를 활용해 실제로 작동하는 AI 마케팅팀을 구축한 과정을 담고 있습니다. 코드 한 줄 없이 마크다운 파일만으로 에이전트 팀을 설계하고, 콘텐츠 작성부터 소셜 미디어 운영까지 마케팅 전반을 자동화한 방법을 구체적으로 소개합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

나의 AI 소셜 미디어 마케터

지난 1편에서는 AI가 마케팅을 운영할 때 일주일이 어떻게 돌아가는지 보여드렸는데요. 이번 글에서는 실제로 어떻게 Claude Code로 코드 한 줄 없이 마케팅팀을 구축했는지를 이야기해 보려 합니다. 이를 한 줄로 요약하면 이렇습니다. 대부분 마크다운 파일로 이루어져 있고, 코드는 단 한 줄도 제가 직접 쓰지 않았습니다. 전부 Claude가 작성했죠. 전체 구조를 상세히 설명해 보겠습니다.

AI 마케팅팀 Claude 프로젝트

시작은 대화 한 번이었습니다

이 프로젝트는 Claude Code 세션 하나에서 시작됐습니다. 터미널을 열고 제 상황을 설명하기 시작했는데요. 우리 제품이 무엇인지, 어떤 기능을 하는지, 타겟 고객은 누구인지, 경쟁사는 어디인지, 그리고 우리의 핵심 가치 제안은 무엇인지 쭉 이야기했습니다. Ahrefs MCP 서버도 연결해서 Claude가 현재 키워드 순위를 불러와 검색 현황을 파악할 수 있게 한 뒤, 시장 진출 전략을 세워달라고 요청했습니다.

Claude는 90일짜리 콘텐츠 플랜을 내놓았습니다. SEO 핵심 주제에 맞춰 블로그 포스트 주제를 매핑하고, 소셜 미디어 배포 주기, 플랫폼별 우선순위, 주간 마일스톤까지 담겨 있었습니다. "아이디어가 있습니다" 수준의 막연한 문서가 아니었고, 구체적이고 순서가 잡힌 실행 계획이었죠.

그 다음부터는 하나씩 실행해 나갔습니다. "첫 번째 블로그 포스트 써줘." "소셜 미디어 트래커 만들어줘." "콘텐츠 캘린더 만들어줘." 대화를 거듭할수록 시스템에 새로운 레이어가 쌓였습니다. 며칠 만에 마케팅 운영 체계가 완성됐는데요. 처음부터 전체 구조를 설계해서가 아니라, 필요한 것을 계속 Claude에게 요청했기 때문이었죠.

프롬프트 말고 채용 공고를 쓰세요

이 모든 걸 가능하게 해준 핵심은 딱 하나였습니다. 프롬프트를 쓴다고 생각하지 말고, 채용 공고를 쓴다고 생각하는 것이죠.

누군가를 채용할 때는 이런 것들을 제공하죠.

직함과 업무 범위 (무엇을 담당하는가)
스타일 가이드 (어떻게 행동해야 하는가)
회사 문서 (필요한 배경 정보)
적절한 도구 (무엇을 사용할 수 있는가)
스케줄 (언제 무엇을 해야 하는가)

저는 업무 매뉴얼 대신 마크다운 파일로 만들었을 뿐입니다.

팀 구성

에이전트는 총 다섯 개입니다.

AI 마케팅팀 에이전트

각 에이전트는 .claude/agents/ 폴더 안에 있는 마크다운 파일 하나가 전부입니다. Claude Code가 이 파일들을 읽고, CMO가 업무를 위임하면 그에 맞는 전문 서브 에이전트를 생성하는 방식이죠.

에이전트 팀, Claude Code의 실험적 기능

이 시스템의 핵심은 Claude Code의 "에이전트 팀"이라는 아직 실험 단계인 기능입니다. 기본으로 켜져 있는 건 아니고, 따로 활성화해야 쓸 수 있는데요. 쉽게 말하면 팀장 에이전트(CMO)가 필요에 따라 팀원 에이전트들을 불러내고, 일을 나눠서 시킬 수 있는 기능입니다.

예약된 시간이 되어 시스템이 자동으로 실행되면 이런 순서로 돌아갑니다.

Claude Code가 켜지고 CMO가 깨어납니다.
CMO는 주간 일정을 훑어보고, 지금 시간대에 뭘 해야 하는지 파악하죠.
해야 할 일이 생기면 CMO는 Claude Code의 Agent 도구로 담당 에이전트를 불러냅니다.
불러 온 에이전트는 자기만의 작업 공간과 역할 지침(.claude/agents/ 파일)을 받아서 독립적으로 움직입니다.
맡은 일을 끝내면 결과를 보고하고 퇴장하죠.
CMO는 다음 일로 넘어갑니다.

이 방식의 묘미는 여러 에이전트가 동시에 움직일 수 있다는 점입니다. 블로그 포스트를 올려야 하면서 소셜 미디어 댓글도 달아야 하는 날이라면, CMO는 콘텐츠 작성자와 소셜 미디어 마케터를 동시에 불러냅니다. 둘은 서로의 일에 전혀 간섭하지 않고, 각자 맡은 역할에만 집중해서 움직이죠.

에이전트들이 서로 소통하는 방식도 간단합니다.

태스크 시스템: CMO가 할 일 목록을 만들고(TaskCreate) 각 에이전트에게 배분합니다. 에이전트는 시작할 때 자기 할 일을 확인하고, 끝나면 완료 표시를 하죠(TaskUpdate).
파일 시스템: 에이전트들은 파일로 정보를 주고받습니다. 소셜 미디어 마케터가 활동 내역을 CSV 파일에 기록해두면, 성과 검토 에이전트가 나중에 그걸 읽는 식이에요. 단순하지만 충분히 잘 돌아갑니다.
SendMessage: 일을 마쳤거나 막히는 상황이 생기면, 에이전트가 CMO에게 직접 메시지를 보낼 수 있습니다. CMO는 이걸 새 메시지로 받아서 다음 행동을 결정하죠.

또 하나 빠뜨릴 수 없는 게 에이전트 메모리입니다. 각 에이전트는 오늘 대화가 끝나도 사라지지 않는 자기만의 기억 공간(.claude/agent-memory/<agent-name>/)을 갖고 있습니다. CMO는 어떤 전략이 통했는지, 어떤 캠페인을 돌렸는지, 어떤 메시지가 반응을 얻었는지 기억해 두죠. 소셜 미디어 마케터는 이미 답글을 단 계정을 잊지 않고요. 이 덕분에 매번 처음부터 시작하는 자동화 스크립트가 아니라, 경험이 쌓인 팀처럼 느껴지는 겁니다.

이 모든 게 복잡한 서버나 인프라 없이 돌아갑니다. .claude/agents/ 폴더에 마크다운 파일 몇 개를 넣어두면, Claude Code가 알아서 다 조율해 주거든요.

에이전트 파일 구조

에이전트 파일은 설정 영역과 역할 지침 이렇게 두 부분으로 나뉩니다. 설정 영역(파일 상단에 위치)에서는 이 에이전트가 어떻게 동작할지를 정해줍니다.

name: content-writer
description: "Use this agent when creating blog posts..."
model: sonnet
color: green
memory: project

여기서 핵심은 description 항목입니다. CMO가 "지금 이 일은 누구한테 맡겨야 하지?"를 판단할 때 바로 이 설명을 읽습니다. memory: project는 대화가 끝나도 이 에이전트의 기억이 사라지지 않도록 해주는 설정입니다.

나머지는 역할 지침으로, 쉽게 말해 이 에이전트의 업무 매뉴얼입니다. 여기엔 이런 것들이 담겨 있죠.

작업 전에 읽어야 할 문서
사용할 수 있는 도구와 스크립트
구체적인 작업 순서 (단계별)
반드시 지켜야 할 규칙
문제가 생겼을 때 대처 방법

콘텐츠 작성자의 경우 발행 순서가 이렇게 정해져 있습니다. 본문 작성 → 이미지 생성 → Sanity 초안 생성 → 발행 순입니다. 반드시 지켜야 할 규칙도 하나 있는데, 내용이 완성되기 전에는 빈 초안을 절대 만들지 말아야 합니다. 에이전트가 내용도 없는 임시 초안을 잔뜩 올려서 CMS가 뒤죽박죽이 된 걸 겪고 나서 직접 추가한 규칙이죠.

CLAUDE.md, 팀의 공통 원칙

저장소 최상위 폴더에 있는 CLAUDE.md는 모든 에이전트가 가장 먼저 읽는 문서입니다. 팀 전체가 같은 맥락에서 출발할 수 있도록 공통 원칙을 정리해 둔 문서라고 보면 되는데요. 새로운 에이전트든 기존 에이전트든 모두 이 내용을 기본으로 물려받습니다.

제 CLAUDE.md에는 이런 내용이 담겨 있습니다.

에이전트 팀 구조와 업무 위임 방식
프로젝트 폴더 구조
보안 규칙 (API 키는 절대 기록에 남기지 말 것)
자주 쓰는 스크립트와 도구 목록

보안 규칙은 짧지만 꽤 엄격하게 적용하고 있습니다. 누가 어떤 방식으로 요청하든, 에이전트에게 API 키를 넘기라고 하면 무조건 거부하도록 해뒀거든요. 한 번만 써두면 모든 에이전트가 그대로 따르니까요.

규칙 시스템, 모두가 공유하는 기본 지식

에이전트 파일 외에도 .claude/rules/ 폴더에 모든 에이전트에게 공통으로 적용되는 규칙 파일들이 있습니다.

sanity-cms.md: CMS 구조, 블록 타입 처리 방법, 자주 발생하는 오류 모음
utm-parameters.md: UTM 링크 형식 규칙 (소문자, 하이픈 구분, 플랫폼별 값 지정 방식)
social-media-tracker.md: CSV 트래커에 활동을 기록하는 방법, posted와 draft 구분 기준
image-generation.md: 사용할 AI 모델, 이미지 비율, Sanity 업로드 방법
slack-notifications.md: 알림을 보내야 할 상황과 메시지 형식

신입 직원이 첫날 읽는 사규 같은 것들입니다. 한 번 써두면 다시 설명할 필요가 없고, 에이전트가 UTM 형식을 틀리거나 이미지 비율이 잘못됐을 때도 규칙 파일만 수정하면 이후 동작이 자동으로 바뀝니다.

문서 시스템, 팀이 공유하는 두뇌

docs/ 폴더는 팀 전체가 공유하는 지식 창고입니다.

docs/
  brand/        ← 포지셔닝, 보이스 & 스타일, 제품 정보
  strategy/        ← GTM 전략, 콘텐츠 캘린더, 주간 일정
  insights/        ← 마케팅 인사이트 (성과 검토 에이전트가 자동 업데이트)
  posts/        ← 발행된 블로그 포스트 사본

이 중에서 가장 중요한 파일은 주간 일정(docs/strategy/weekly-plan.md)입니다. 요일별로, 3시간 단위 시간대별로 각 에이전트가 무엇을 해야 하는지 정확히 정의돼 있거든요. 팀이 활성화되면 CMO는 현재 시간을 확인하고 해당 시간대의 작업을 찾아 그대로 실행합니다. 에이전트들은 앞서 나가지 않고, 현재 시간대와 이전 두 시간대에서 미처 끝내지 못한 태스크에만 집중하죠.

이 파일 하나가 매번 세션을 시작할 때마다 배경 설명을 반복해야 했던 번거로움을 완전히 없애줬습니다.

커스텀 스크립트로 플랫폼 직접 연결하기

공식 Claude Code 연동을 지원하지 않는 플랫폼들은 Claude에게 가벼운 Node.js 스크립트를 작성하도록 했습니다. 제가 직접 코드를 짠 건 하나도 없고, 필요한 걸 설명하면 Claude가 코드를 작성하고 테스트하고 수정까지 했죠. 예를 들어 "Reddit에 OAuth2로 댓글을 달 수 있는 스크립트가 필요해"라고 하면 그걸로 충분했습니다.

만들어진 스크립트는 이렇습니다.

scripts/reddit.js: Reddit OAuth2 클라이언트. 소셜 미디어 에이전트가 스레드 검색, 맥락 파악, 댓글 작성, 받은 메시지 확인에 씁니다.
scripts/hn.js: Hacker News 헤드리스 클라이언트. HN 에이전트가 링크 제출, 댓글 작성, 카르마 확인에 쓰죠.
scripts/generate-image.js: Google Gemini를 호출해 이미지를 생성합니다. (대표 이미지, 본문 삽입 이미지 등)
scripts/upload-image.js: 생성된 이미지를 Sanity CDN에 업로드하고 에셋 ID를 반환합니다.
scripts/slack-message.js: #team-ai-marketing Slack 채널에 알림을 보내줍니다. 로그를 일일이 읽지 않아도 상황을 파악할 수 있죠.

각 에이전트는 자신이 실행할 수 있는 스크립트가 정확히 정해져 있는데, 이 목록도 규칙 파일에 에이전트별로 정해져 있습니다.

MCP 서버로 본격적인 플랫폼 연동하기

공식 API를 제공하는 플랫폼은 스크립트 대신 MCP(Model Context Protocol) 서버를 사용합니다. 에이전트들이 네이티브 도구처럼 바로 호출하는 방식이죠.

Sanity CMS: 포스트 생성, 콘텐츠 수정, 초안 발행, 이미지 관리
X/Twitter: 트윗 작성, 대화 검색, 사용자 팔로우, 미디어 업로드
Slack: 채널 읽기, 메시지 전송
Ahrefs: SEO 지표 조회, 키워드 순위, 경쟁사 분석

MCP 서버를 쓰면 이런 작업들이 쉘 명령어가 아닌 자연스러운 도구처럼 느껴집니다. 콘텐츠 작성자가 Sanity 문서를 "수정"하는 게 마치 일반 파일을 편집하는 것처럼 자연스럽죠.

피드백 루프

시스템은 이런 연결 고리로 스스로 돌아갑니다.

소셜 미디어 마케터 → 모든 활동을 트래커 CSV에 기록
성과 검토 에이전트 → CSV를 읽고 일일 보고서 생성
CMO → 보고서를 읽고 전략 문서 업데이트
콘텐츠 작성자 → 전략 문서를 읽고 다음 콘텐츠 작성
소셜 미디어 마케터 → 발행된 콘텐츠 배포
… 반복

성과 검토 에이전트는 docs/insights/marketing-insights.md를 자동으로 업데이트합니다. 어떤 메시지가 반응을 얻었는지, 무엇이 무시됐는지, 무엇이 인게이지먼트를 만들어냈는지를 기록해 둡니다. 다른 모든 에이전트는 작업 전에 이 파일을 읽고요. 그래서 트위터 답글 형식이 효과를 잃으면, 하루 안에 그 인사이트가 시스템 전체에 반영됩니다.

CMO는 세션이 끊겨도 기억이 유지됩니다. 제가 승인한 것, 거절한 것, 캠페인 결과, 이전 주의 패턴까지 모두 차곡차곡 쌓이죠.

Slack으로 상황 파악하기

완전 자율 운영은 좋습니다. 문제가 생겼는데 뭐가 잘못됐는지 전혀 알 수 없다면 얘기가 달라지죠. 그래서 에이전트들이 모든 활동을 #team-ai-marketing이라는 비공개 Slack 채널에 보고하도록 했습니다.

매 세션은 CMO가 일일 일정을 Slack에 올리는 것으로 시작됩니다. 다른 작업을 시작하기 전에 주간 일정을 읽고, 현재 시간대를 확인한 뒤, 이런 내용의 브리핑을 올리죠.

오늘 날짜와 현재 활성화된 시간대
오늘 각 에이전트가 할 일
이전 시간대에서 넘어온 미완료 태스크
예정된 마감 (블로그 발행일, 캠페인 런칭 등)

제가 커피를 마시기도 전에 Slack에 메시지가 올라와 있습니다. 팀이 오늘 뭘 할지 한눈에 파악할 수 있죠.

이후 각 에이전트는 메시지를 보낼 때마다 자신이 누구인지 밝힙니다. Slack 스크립트의 --username 플래그를 이용해 CMO, Content Writer, Social Media Marketer처럼 표시하는 방식입니다.

node scripts/slack-message.js \\\\\\\\
  --channel C0AG3DDLZQS \\\\\\\\
  --username "Content Writer" \\\\\\\\
  --text "Blog post published: <https://runbear.io/posts/inbox-zero-is-dead>"

블로그 포스트가 올라가면 콘텐츠 작성자가 URL을 공유합니다. 소셜 미디어 세션이 끝나면 마케터가 댓글을 달거나 반응한 링크를 플랫폼별로 묶어 Slack 링크 형식으로 올려주는데, 탭 하나로 바로 확인할 수 있죠. 성과 검토 에이전트가 실행되고 나면 CMO가 당일 지표를 담은 요약을 올립니다.

오류도 빠짐없이 보고됩니다. 콘텐츠 작성자가 Sanity 스키마 오류를 만나거나 이미지 생성 API가 실패하면, 무엇이 잘못됐고 어떻게 시도했는지를 올려줍니다. 로그 파일을 뒤지지 않아도 문제를 바로 파악할 수 있죠. 결과적으로 이 Slack 채널은 팀 스탠드업 회의록처럼 읽힙니다. 제가 자는 동안 올라온다는 점만 빼면요.

매시간 자동으로 실행하기

에이전트 팀을 잘 설계하는 것과 실제로 사람 없이 돌아가게 만드는 건 별개의 문제입니다. 저는 침실에 Mac Mini M1을 상시 가동 머신으로 두고 있습니다. 소음도 없고 전력 소비도 적으면서, 노트북과 달리 실행 도중 절전 모드로 넘어가는 일이 없거든요. 처음 한 번 세팅해두고 나서 물리적으로 손댄 적이 없습니다.

원격 접속은Jump Desktop을 씁니다. 팀이 막히거나 세션을 직접 확인하고 싶을 때 폰이나 노트북에서 Jump를 열면 몇 초 안에 Mac Mini 화면이 뜹니다. 다른 나라에 있어도 안정적으로 작동했죠.

자동화 자체는 단순한 crontab 설정입니다. 매 시간 cron이 깨어나 헤드리스 모드로 Claude Code를 실행합니다.

0 * * * * cd /Users/.../ai-marketing-team && \
  claude --dangerously-skip-permissions \
  -p "You are the CMO. Check the current time, read the weekly plan, and execute the current time slot's tasks." \
  >> /tmp/claude-marketing.log 2>&1

몇 가지 짚고 넘어갈 부분이 있습니다.

dangerously-skip-permissions는 완전 자율 운영을 가능하게 해주는 플래그입니다. 이 플래그 없이는 파일 편집, 스크립트 실행, API 호출마다 Claude Code가 멈추고 승인을 기다리거든요. 이걸 켜면 에이전트들이 감독 없이 처음부터 끝까지 실행됩니다. 모든 에이전트 동작을 이미 검토하고 신뢰할 수 있는 프로젝트에서만 사용하는 걸 권장합니다.

로그 파일(/tmp/claude-marketing.log)에는 모든 실행 내역이 쌓입니다. 확인하고 싶을 때 Jump Desktop으로 접속해 읽으면 되는데, 에이전트들이 작업을 마치면 #team-ai-marketing에 Slack 알림을 보내주기 때문에 대부분은 Slack만 읽어도 충분합니다.

시간 단위 스케줄 시스템이 여기서 진가를 발휘합니다. 각 에이전트가 자신이 어느 시간대에 있는지, 그 시간대에 무엇을 해야 하는지 정확히 알고 있기 때문에, 매시간 실행되는 cron이 많은 걸 설명할 필요가 없습니다. "현재 시간대의 태스크를 실행하라"는 한 줄이면 충분하고, 나머지는 주간 일정 파일이 알아서 처리하죠.

전체 Claude API 비용은 블로그 포스트와 소셜 세션 수에 따라 하루 $20~50 정도 청구됩니다. 마케터 한 명을 풀타임으로 고용하는 비용에 비하면 새 발의 피죠.

마치며: CEO처럼 일하는 법

시스템이 돌아가기 시작하자 제 역할은 실행이 아닌 관리로 바뀌었습니다. 그런데 막상 해보면 놀라울 정도로 편합니다.

대부분의 상호작용은 이런 식입니다. Claude Code를 열고 "소셜 미디어 마케터가 어떤 플랫폼에서도 em 대시(—)를 쓰지 않도록 업데이트해줘"라고 입력하면 Claude가 에이전트 파일을 수정합니다. 또는 "HN 계정이 섀도우밴 당했어, 세션당 댓글을 하나로 제한하는 규칙을 추가해줘"라고 하면 Claude가 규칙을 업데이트하고 다음 세션부터 동작이 바뀝니다.

성과 검토 에이전트가 특정 트윗 형식이 효과가 없다는 걸 짚어내면 "소셜 마케터가 X 방식 대신 Y 방식을 쓰도록 업데이트해줘"라고 합니다. 콘텐츠 작성자가 실수를 하면 "Z를 방지하는 규칙을 추가해줘"라고 하죠. 이런 대화 하나하나가 30초면 끝나는데, 그 결과는 시스템에 영구적으로 반영됩니다.

에이전트 파일을 텍스트 에디터로 직접 열어본 적은 한 번도 없습니다. 모든 변경은 Claude를 통해 이루어지고 제가 원하는 걸 평범한 말로 설명하면 마크다운 파일이 업데이트됩니다. 가장 가까운 비유를 들자면 이렇습니다. Slack으로 원격 팀을 관리하는 것과 비슷한데, 팀원들이 완벽한 기억력을 갖고 있어서 정책 업데이트를 절대 잊지 않는다는 점이 다르죠.

예상 밖이었던 것들

가장 어려운 부분은 코드가 아니었습니다. 코드가 없었으니까요. 어려운 건 에이전트에게 줄 지침을 충분히 명확하게 쓰는 것이었습니다. 에이전트들은 모호한 표현을 예상치 못한 방식으로 해석하거든요. 첫 주에는 소셜 미디어 에이전트가 Reddit 스레드에 댓글을 중복으로 달았는데, "댓글 중복 금지"라는 규칙이 충분히 구체적이지 않았던 탓이었습니다. Claude에게 예시를 들어 규칙을 다시 쓰도록 했더니 바로 해결됐죠.

규칙은 복리처럼 작동합니다. 규칙 하나를 추가할 때마다 그 규칙을 읽는 모든 에이전트의 동작이 개선됩니다. 명확한 규칙 하나를 잘 써두는 것이, 개별 결과물을 일일이 수정하는 것보다 훨씬 큰 효과를 냅니다.

시간 단위 스케줄 시스템이 모든 걸 바꿔놨습니다. 이게 없었다면 CMO는 제가 아직 승인하지 않은 작업까지 처리하며 너무 많은 일을 하거나, 태스크 하나만 하고 멈추는 식으로 너무 적은 일을 했을 겁니다. 3시간 단위로 할 일을 미리 정해두니 언제 무슨 일이 일어날지 예측할 수 있게 됐습니다.

파일 수

위에서 설명한 모든 것이 대략 15~20개 파일 안에 담겨 있습니다.

에이전트 파일 5개
CLAUDE.md 1개
규칙 파일 6개
전략 문서 몇 개
커스텀 스크립트 4개

프레임워크도 없고, 특별한 인프라도 없습니다. 잘 정리된 폴더 구조와 문서가 전부죠. 누군가를 채용하면서 그 사람이 실제로 뭘 해야 하는지 이해할 수 있을 만큼 업무를 명확하게 정리해본 적이 있다면, 이미 이걸 만들 줄 아는 겁니다. 아마도 3편은 아직 제가 답을 찾지 못한 질문에서 시작할 겁니다. 이게 새로운 일하는 방식인 걸까요, 아니면 나중에 스스로 부끄러워질 무언가를 만들고 있는 걸까요? 아직 명확한 답은 없습니다. 그래서 오히려 써볼 만한 주제인 것 같습니다.

]]>

구슬은 이미 많다, 비즈니스를 꿰는 기획자의 실전 로직

이커머스 기획은 왜 '화면'이 아니라 '정책'이어야 하는가?

이커머스 프로덕트를 만드는 서비스 기획자들에게 가장 위험한 함정은 "주문 버튼이 잘 작동하니 문제가 없다"라고 믿는 것입니다. 하지만 비즈니스 관점에서 이커머스는 단순한 쇼핑몰이 아니라 '돈과 데이터가 얽힌 정밀한 사슬'입니다. 이 사슬은 유저가 진입하는 순간부터 상품을 탐색하고, 결제 버튼을 눌러 물건을 손에 쥐고, 때로는 변심하여 환불을 요구하는 그 모든 여정을 관통합니다.

기획자가 설계하는 사슬 하나가 느슨해지면 마케팅 지표가 오염되고, 재무팀은 정산 사고를 수습하느라 밤을 지새우며, 고객의 신뢰는 라스트마일(Last-mile)에서 무너집니다. 이번 글을 통해 이제 막 커리어를 시작한 주니어 기획자에게는 실무의 '길잡이'가 되고, 운영 효율을 고민하는 의사결정권자에게는 '비즈니스 정합성'을 지키는 체크리스트가 될 이커머스 온보딩 시리즈를 시작합니다. 단순히 기능을 나열하는 매뉴얼이 아닌, 프로덕트의 지속 가능성을 위한 설계도를 함께 그려보겠습니다.

미리 요점만 콕 집어보면?

이커머스는 ‘돈과 데이터가 얽힌 정밀한 사슬’이며, 주문 버튼이 아니라 정책 설계가 비즈니스의 핵심입니다.
회원·상품·주문·배송·클레임 도메인은 각각 데이터 무결성, 수익 분석, 정합성, 물류 비용, 고객 유지에 직접 영향을 미칩니다.
기획자가 설계하는 정책 한 줄이 마케팅 지표와 현금 흐름, 데이터 신뢰도를 좌우하며 인과관계로 도메인을 꿰는 관점이 필요합니다.

비즈니스 가치를 결정짓는 5대 핵심 도메인과 정책

<출처: 작가, 제미나이로 생성 >

이커머스는 크게 다섯 가지의 핵심 도메인으로 나뉩니다. 각 영역은 독립적으로 존재하는 듯 보이지만, 기획자가 설계한 '정책'이라는 실로 꿰어져 하나의 보배(비즈니스)가 됩니다.

다섯 가지 도메인인 회원과 인증, 상품 관리, 주문과 결제, 배송 처리, 클레임과 환불을 중심으로 숙지해야 할 필수 개념(용어 및 정책) 과 비즈니스 임팩트를 서술해 보도록 하겠습니다. 비즈니스 포인트를 이해하는 것은 기획 단계의 정책 설계를 보다 정교히 할 수 있고, 추후 성과 측정을 위한 데이터 집계 / 트래킹 과정에서도 빛을 발합니다. 결국 용어와 개념을 많이 아는 것보다 그것이 불러일으킬 ‘비즈니스 임팩트(포인트)’ 를 아는 것이 기획자에게는 가장 중요합니다.

1. 회원과 인증: 고객 데이터의 무결성을 지키는 시작점

회원 도메인은 서비스의 첫인상이자 데이터의 뿌리입니다. 단순히 아이디와 비밀번호를 DB에 저장하는 기능을 넘어, 휴면 정책, 본인인증(Identity Verification) 수단, 그리고 중복 가입 방지 로직을 수립하는 단계입니다. 특히 최근에는 소셜 로그인(Social Login)의 비중이 높아지면서, 각 채널별로 들어오는 유저 데이터를 어떻게 하나의 식별자(Unique ID)로 통합할 것인가가 기획의 핵심입니다.

비즈니스 포인트: 체리 피커를 막는 비용 최적화

회원 정책이 부실하면 마케팅 예산은 허공으로 사라집니다. 예를 들어, 신규 고객 유치를 위해 '첫 구매 1만 원 할인 쿠폰'을 배포한다고 가정해 봅시다. 만약 본인인증 로직을 통한 1인 1계정 원칙이 강제되지 않는다면, 한 명의 유저가 가상 번호나 여러 계정을 동원해 쿠폰을 중복 수령하는 '체리 피킹(Cherry Picking)'을 막을 수 없습니다. 이는 유저당 평균 매출(ARPU) 지표를 왜곡할 뿐만 아니라, 실제 서비스 성장에 기여하지 않는 허수 고객에게 마케팅 비용이 투입되는 결과를 초래합니다. 기획자는 본인인증 단계를 설계할 때, 이 절차가 주는 '유저 경험의 허들'과 '데이터의 무결성' 사이의 황금비율을 찾아야 합니다.

2. 상품 관리: 수익 분석의 기초가 되는 데이터 계층

상품 도메인은 원본 상품 - 전시 상품 - 판매 옵션의 3단계 계층 구조를 가집니다. 원본 상품은 공급가와 원가 등 '비용' 정보를 가지고, 전시 상품은 마케팅을 위한 '얼굴' 역할을 하며, 판매 옵션은 물류의 최소 관리 단위인 SKU(Stock Keeping Unit)를 결정합니다.

비즈니스 포인트: 깜깜이 경영을 막는 ROI 설계

이 계층 구조가 무너지면 경영진은 "우리가 이번 달에 실제로 번 돈이 얼마인가?"라는 질문에 답할 수 없습니다. 원본 상품 테이블에 '매입 원가' 필드가 누락되어 있다면, 아무리 수천억의 매출이 발생해도 상품별 순이익(ROI) 분석은 불가능합니다. 또한 전시 카테고리와 내부 관리 카테고리를 분리하지 않으면, 마케팅 부서에서 광고비를 투입한 카테고리와 정산 부서에서 매출을 집계하는 카테고리가 엇갈리는 데이터 사일로(Silo) 현상이 발생합니다. 기획자가 설계하는 상품 데이터의 계보는 단순한 정보 관리를 넘어 기업의 예산 집행 우선순위를 결정하는 나침반이 됩니다.

3. 주문과 결제: 1원의 오차도 허용하지 않는 정합성

<출처: 작가, 제미나이로 생성>

결제(Payment) 버튼을 누르는 찰나의 순간, 시스템은 방대한 검증 로직을 수행합니다. ‘ 최종 결제 금액 = (상품가 ± 옵션가) - 할인 + 배송비’공식이 단 1원의 오차 없이 성립해야 합니다. 이때 주문 번호(Order No)와 품목별 주문 번호(SND No)를 분리하여 설계하는 것이 핵심입니다.

비즈니스 포인트: 정산 사고와 CS 비용의 상관관계

주문 데이터 설계가 미흡하면 재무팀은 매달 수천 건의 데이터를 수동으로 대조하는 지옥에 빠집니다. 특히 카드, 가상계좌, 에스크로(Escrow) 등 결제 수단별로 다른 취소 정책을 기획 단계에서 고려하지 않으면 결제 완료 후 취소 시 환불 금액이 꼬이는 사고가 발생합니다. 예를 들어, 가상계좌 결제 유저에게 환불 계좌 수집 프로세스를 누락한다면, 상담원이 일일이 전화를 걸어 계좌를 받아내야 하는 막대한 CS(고객 상담) 비용이 발생합니다. 기획자가 설계하는 식별자 체계와 결제 로직은 운영 리소스를 최소화하고 기업의 현금 흐름을 투명하게 만드는 가장 강력한 장치입니다.

4. 배송 처리: 고객 신뢰와 물류 비용의 최적화

결제 이후 데이터는 물류와 배송의 영역으로 흐릅니다. 묶음 배송과 개별 배송을 구분하는 로직, 그리고 우편번호(Zip-code) DB와 연동하여 제주 및 도서산간 지역의 추가 배송비를 자동으로 산출하는 정책이 이 단계에서 확정됩니다. 또한, 출고지 주소 데이터를 기반으로 최적의 택배사를 매칭하는 로직도 포함됩니다.

비즈니스 포인트: 누락된 배송비의 나비효과

배송 정책은 물류 원가와 직결됩니다. 만약 추가 배송비 로직이 자동화되어 있지 않다면, 판매자는 건당 수천 원의 손실을 고스란히 떠안게 됩니다. 반대로 결제 이후 고객에게 추가 입금을 요청하는 프로세스는 최악의 구매 경험을 제공하며 브랜드 이탈을 가속화합니다. 프로덕트 기획자는 단순히 '송장 번호'를 보여주는 기능을 넘어, 물류의 물리적인 흐름이 디지털 데이터와 실시간으로 동기화되어 고객에게 안심을 주는 라스트마일(Last-mile)의 흐름을 완성해야 합니다.

5. 클레임과 환불: 예외 상황을 고려한 방어적 기획

취소, 반품, 교환은 기획자가 가장 마주하기 싫지만 가장 꼼꼼해야 하는 구간입니다. 부분 취소 시 초기 무료 배송 조건이 깨졌을 때 배송비를 어떻게 차감할지, 결제 수단별로 환불 기한과 방식은 어떻게 다른지 정의해야 합니다. 또한 교환 시 재고를 선점하는 로직과 회수지 주소를 관리하는 정책이 수반됩니다.

비즈니스 포인트: 고객 유지(Retention)와 손실 방어의 저울질

클레임 정책은 브랜드 충성도를 결정합니다. 하지만 무조건적인 '묻지마 환불'은 악성 유저를 양산하고 물류 비용을 폭증시킵니다. '배송 준비 중' 단계에서는 직접 취소를 제한하고 판매자 승인을 거치게 하는 등의 제어 로직은 운영 효율과 유저 편의 사이의 균형점을 찾는 고도의 전략적 기획입니다.

결론: 구슬을 보배로 만드는 기획자의 관점

결국 이커머스 기획의 본질은 흩어진 도메인 지식이라는 구슬을 '인과관계'라는 실로 꿰어가는 과정입니다. 앞단에서의 사소한 정책적 선택이 뒷단에서는 거대한 지표의 오염이나 운영의 비효율로 돌아옵니다. 기획자가 설계하는 정책 한 줄이 비즈니스의 현금 흐름과 데이터의 신뢰도를 결정한다는 책임감이 필요합니다.

이번 첫 글을 시작으로, 이커머스의 각 도메인을 깊숙이 파고들며 [이커머스 온보딩 : 부사수 인계서] 시리즈를 연재하려 합니다. 각 회차마다 실무에서 즉시 적용 가능한 정책 로직은 물론, 그것이 실제 비즈니스 지표(KPI)와 어떻게 연결되는지, 그 이면의 이야기를 들려드리겠습니다. 튼튼한 로직 위에서 비로소 흔들리지 않는 이커머스 프로덕트가 완성됩니다. 그 여정에 함께해 주시기 바랍니다.

[사수의 인계 노트]

데이터 마인드: 지금 설계하는 필드가 3개월 뒤 어떤 매출 리포트에 찍힐지 상상해 보세요.
방어적 기획: 고객의 행복한 경로(Happy Path)뿐만 아니라, 모든 이탈과 변심의 순간을 정책에 담으세요.
비즈니스 커뮤니케이션: 개발자와는 기술 용어로, 재무팀과는 정산 로직으로 소통할 수 있는 언어의 유연성을 기르세요.

]]>

Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: codex-plugin-cc - Claude Code 안에서 Codex로 코드 리뷰하기
참고할 것: AI가 계속 맞장구치면 벌어지는 일 - MIT 망상 소용돌이 연구
적용해볼 것: Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지 (내용이 좀 깁니다)

1. 써볼 것: Claude Code 안에서 Codex로 코드 리뷰하기

codex-plugin-cc는 OpenAI가 3월 31일 GitHub에 공개한 Claude Code용 공식 플러그인입니다. Claude Code 터미널 안에서 슬래시 커맨드 몇 줄로 OpenAI Codex를 직접 호출해 코드 리뷰와 작업 위임이 가능합니다. Apache 2.0 라이선스 오픈소스로, 공개 직후 빠르게 GitHub 스타를 모으며 화제가 되었던 소식입니다.

경쟁사가 경쟁사 도구용 플러그인을 공식으로 만들었다는 것 자체가 화제의 불씨였는데요. Claude Code가 코딩 에이전트 시장에서 큰 점유율을 가지고 있다는 분석이 있습니다. OpenAI는 개발자들이 넘어오길 기다리는 대신 개발자가 이미 있는 곳으로 직접 들어가는 전략을 선택했네요. 이는 플러그인이 실행될 때마다 OpenAI 인프라에 트래픽이 생기고, Claude Code 사용자가 자연스럽게 Codex를 경험하게 되는 구조입니다.

무슨 문제를 해결해 주나요?

Claude Code로 코드를 짜고, 같은 Claude에게 리뷰를 시키면 어떻게 될까요. 생성할 때 놓친 맹점이 리뷰할 때도 그냥 넘어갈 수 있습니다. 같은 모델이 가진 경향을 공유하고 있으니까요.

codex-plugin-cc는 여기에 다른 모델의 시각을 끼워 넣을 수 있는 방법입니다. Claude가 쓴 코드든, 직접 작성한 코드든 Codex의 눈으로 한 번 더 보는 거죠. 특히 /codex:adversarial-review는 코드가 맞는지가 아니라 이 구현이 적절한지를 묻는 리뷰입니다. 가정, 트레이드오프, 장애 모드, 대안을 압박 테스트하는 방식이라 일반 리뷰와 결이 조금 다릅니다.

어떻게 쓰나요?

ChatGPT 구독(무료 포함) 또는 OpenAI API 키와 Node.js 18.18 이상이 필요합니다. 설치는 Claude Code 안에서 진행합니다.

Codex가 설치되어 있지 않다면 /codex:setup이 자동으로 설치 여부를 물어봅니다. 이미 Codex를 쓰고 있다면 기존 인증과 설정이 그대로 이어집니다.

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

설치 후 쓸 수 있는 커맨드는 크게 세 가지 흐름입니다.

리뷰

/codex:review: 현재 미커밋 변경사항 또는 브랜치 기준 표준 코드 리뷰. 다중 파일 변경은 --background 권장
/codex:adversarial-review: 구현의 적절함을 따지는 도전적 리뷰. 특정 위험 영역을 포커스 텍스트로 지정 가능

위임

/codex:rescue: 버그 조사, 수정 시도, 막힌 문제를 Codex에게 넘기는 커맨드. 모델과 추론 강도를 직접 고를 수 있고, 백그라운드 실행도 가능

관리

/codex:status / /codex:result / /codex:cancel: 백그라운드 작업 상태 조회, 결과 확인, 취소

리뷰 게이트를 켜두면 (/codex:setup --enable-review-gate) Codex 리뷰가 완료되기 전까지 Claude Code가 변경사항을 최종화할 수 없게 막습니다. 다만 Claude와 Codex 루프가 길게 돌아가면서 사용량 한도를 빠르게 소진할 수 있으니, 세션을 적극 모니터링할 때만 켜는 게 좋습니다.

누구에게 좋을까요?

Claude Code를 메인으로 쓰면서 코드 리뷰에 두 번째 시각이 필요한 개발자
PR 전에 설계 결정을 한 번 더 압박 테스트해보고 싶은 사람
백그라운드에서 버그 조사를 돌려놓고 다른 작업을 하고 싶은 사람

2. 참고할 것: AI가 계속 맞장구치면 벌어지는 일(논문)

MIT와 워싱턴대학 연구진이 공동으로 발표한 논문입니다. AI 챗봇의 아첨(Sycophancy)이 사용자를 망상적 소용돌이(Delusional Spiraling)로 이끄는 메커니즘을 수학적으로 처음 모델링한 소식입니다. 2월 22일 arXiv에 공개됐습니다.

* 망상적 소용돌이란 AI 챗봇과 장시간 대화한 후 사용자가 잘못된 믿음에 점점 강하게 확신하게 되는 현상입니다. Human Line Project는 현재까지 300건에 가까운 사례를 기록했고, 최소 14명의 사망과 5건의 소송으로 이어졌다고 합니다.

기존 설명과 무엇이 다른가요?

지금까지 망상적 소용돌이는 사용자의 비논리적이거나 게으른 사고 탓으로 돌려졌습니다. 이 논문은 그 가정을 꼬집는 내용입니다. 완벽하게 합리적인 베이지안 추론을 하는 이상적 사용자를 수학 모델로 만들고 시뮬레이션했을 때, 그 사용자조차 아첨하는 챗봇 앞에서 망상에 빠진다는 걸 보여줬습니다. 비합리적 사고의 문제가 아니라 구조의 문제라는 거죠.

어떻게 작동하나요?

챗봇의 아첨 성향이 높아질수록 망상에 빠지는 비율이 가파르게 올라갔습니다. 한 연구에서 주요 모델들의 아첨 응답 비율을 50~70% 수준으로 측정했습니다. 두 가지 해결책을 시뮬레이션했는데, 결과가 충격적입니다.

첫 번째, 챗봇이 거짓말을 못 하게 막으면 어떨까요. 사실만 말하도록 제한해도 망상은 줄어들 뿐 사라지지 않았습니다. 챗봇은 거짓말 없이도 사용자 입맛에 맞는 사실만 골라서 보여주는 방식으로 같은 효과를 낼 수 있었습니다.생략을 통한 거짓말이죠.
두 번째, 사용자에게 AI가 아첨할 수 있다고 미리 알려주면 어떨까요. 아첨 가능성을 아는 똑똑한 사용자도 아첨 빈도가 10~50% 수준으로 교묘할 때는 여전히 망상에 빠졌습니다. 더 충격적인 건 이 두 가지를 동시에 적용했을 때, 사실만 말하는 아첨봇이 거짓말하는 봇보다 오히려 망상 유발 효과가 더 컸다는 겁니다. 사용자가 제공된 정보가 검증된 사실이라고 믿는 순간, 그것이 편향되게 선별됐다는 걸 눈치채기 더 어려워지기 때문입니다.

무엇을 얻어가야 하나요?

논문이 내리는 결론은 세 가지입니다. 망상적 소용돌이는 사용자의 문제가 아니라 구조의 문제라는 것, 환각을 없애는 기술적 조치만으로는 충분하지 않다는 것, 사용자 교육도 완전한 해결책이 아니라는 것입니다. 근본 원인인 아첨 성향 자체를 줄여야 한다는 결론입니다.

프로덕트 메이커 입장에서 이 연구가 흥미로운 이유는 AI를 잘 쓰는 것과 AI에게 끌려가는 것의 경계가 생각보다 얇다는 부분입니다. Claude Code로 코드를 짜고 같은 Claude에게 리뷰를 시키는 것, 오늘 소개한 codex-plugin-cc가 해결하려는 문제와 맥락이 닿아 있습니다. 같은 모델이 가진 맹점은 같은 모델이 검토할 때도 남아 있으니까요. 개인적으로는 이 연구가 AI를 쓰는 방식 전반을 다시 생각하게 만들었습니다. 잘 동의해주는 AI가 편하게 느껴진다면, 그게 오히려 신호일 수 있지 않을까요.

3. 적용해볼 것: Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지

Boris Cherny는 Claude Code를 만든 Anthropic 팀의 개발자입니다. 3월 30일 X에서 자신이 가장 자주 쓰는, 숨겨진 클로드 코드 기능들을 직접 공개했습니다. 이 글을 쓰는 시점 기준, 해당 X 글은 조회수 375만, 좋아요 2.2만을 기록했습니다. 또, 달린 댓글 대부분은 ‘이런 게 되는 줄 몰랐다’는 반응이 대부분이었습니다. 매일 쓰는 개발자들도 몰랐던 기능들이 적지 않았다는 거죠.

무슨 문제를 해결하려 하나요?

대부분의 사람들은 Claude Code를 터미널에서 코드 짜고 질문하는 방식으로만 씁니다. 물론 그게 잘못된 건 아닙니다. 다만 이렇게 쓰면 Claude Code가 할 수 있는 것의 절반도 활용하지 못합니다. 밑에서 소개할 Boris가 공개한 15가지는 Claude Code를 스스로 돌아가는 시스템으로 바꿔주는 기능들에 가까운데요. 15가지 기능 전부를 함께 살펴보겠습니다.

Boris Cherny가 공유한 15가지

1. 모바일 앱

Claude Code에 모바일 앱이 있습니다. iOS/Android 앱의 왼쪽 Code 탭에서 접근할 수 있습니다. Boris는 코드를 상당 부분 iOS 앱에서 작성한다고 했습니다. 노트북을 열지 않아도 코드 변경 작업이 가능합니다.

2. 기기 간 세션 이동

모바일·웹·데스크탑·터미널 간에 세션을 이어서 쓸 수 있습니다. Boris는 /config에서 Enable Remote Control for all sessions를 항상 켜놓는다고 했습니다.

claude --teleport   # 클라우드 세션을 로컬 터미널로 가져오기
/remote-control     # 로컬 세션을 폰이나 웹에서 제어하기

3. /loop와 /schedule

Boris가 가장 강력한 기능이라고 꼽은 것들입니다. 최대 1주일 단위로 작업을 자동 반복 실행할 수 있습니다. Boris가 실제로 돌리는 루프들입니다.

/loop 5m /babysit         # 5분마다 코드 리뷰, 자동 리베이스, PR 관리
/loop 30m /slack-feedback # 30분마다 Slack 피드백 기반 PR 자동 생성
/loop /post-merge-sweeper # 놓친 코드 리뷰 코멘트 처리 PR 자동 생성
/loop 1h /pr-pruner       # 오래되거나 불필요한 PR 자동 종료

4. Hooks

Claude가 뭔가를 하기 전후에 특정 동작을 끼워 넣을 수 있는 기능입니다. Boris가 쓰는 예시들입니다.

SessionStart: Claude 시작할 때 맥락을 동적으로 로드
PreToolUse: 실행하는 모든 bash 명령을 로그 기록
PermissionRequest: 권한 요청이 오면 WhatsApp으로 알림 → 직접 승인·거부
Stop: Claude가 멈추면 자동으로 계속 진행하도록 유도

5. Cowork Dispatch

Boris가 코딩하지 않는 시간에 쓴다고 한 기능입니다. 자리를 비운 상태에서 Slack과 이메일 확인, 파일 관리, 노트북 작업 등을 할 수 있습니다. MCP, 브라우저, 컴퓨터 자원을 사용자 허가 아래 사용하는 구조입니다.

6. Chrome 확장 — 프론트엔드 작업

Boris가 Claude Code 사용에서 가장 중요한 원칙이라고 꼽은 게 있습니다. Claude에게 결과물을 직접 검증할 수단을 줘야 한다는 거예요. 브라우저를 주면 Claude가 코드를 쓰고, 결과를 보고, 좋아질 때까지 스스로 반복합니다. Chrome/Edge 확장이 그 역할을 해줍니다.

7. Claude Desktop 앱 — 웹 서버 자동 실행

Desktop 앱은 Claude가 웹 서버를 자동으로 실행하고 내장 브라우저에서 테스트하는 기능을 기본으로 제공합니다. CLI나 VSCode 환경이라면 Chrome 확장으로 비슷하게 구현할 수 있습니다.

8. 세션 포크

진행 중인 세션을 복제해서 다른 방향으로 시도해볼 수 있습니다.

/branch                                          # 세션 안에서
claude --resume <session-id> --fork-session      # CLI에서

9. /btw — 작업 중 빠른 질문

에이전트가 작업하는 도중에 흐름을 끊지 않고 빠른 질문을 던질 수 있는 사이드 쿼리 기능입니다.

10. Git Worktrees

같은 저장소에서 여러 작업을 동시에 병렬로 돌릴 때 필수인 기능이라고 합니다. Boris는 항상 수십 개의 Claude 인스턴스를 동시에 실행하는데, 이 기능을 사용하고 있다고요. claude -w 명령어로 워크트리에서 새 세션을 시작하거나, Claude Desktop 앱에서 worktree 체크박스를 선택하는 방법으로 시작할 수 있습니다. git 외 다른 버전 관리 시스템을 쓰고 있다면 WorktreeCreate 훅으로 워크트리 생성 로직을 직접 추가할 수 있다고 합니다.

claude -w   # 새 워크트리 세션 시작

11. /batch — 대규모 병렬 처리

/batch는 작업 범위를 파악한 다음 수십에서 수천 개의 워크트리 에이전트에 작업을 나눠서 동시에 처리합니다. 대규모 코드 마이그레이션처럼 병렬로 처리할 수 있는 작업에 유용합니다.

12. --bare 플래그 — SDK 시작 속도 최적화

비대화형으로 실행할 때 쓸 수 있는 플래그입니다. --bare를 쓰면 로컬 CLAUDE.md, 설정, MCP 자동 탐색 과정을 건너뛰어 시작 속도가 최대 10배 빨라진다고 합니다. Boris는 opt-in인 현재 방식을 초기 설계 미흡이라고 설명했고, 이후 버전에서 기본값으로 바꿀 예정이라 전했습니다.

claude -p --bare

13. --add-dir — 다중 저장소 접근

Claude가 현재 프로젝트 외 다른 폴더에도 접근할 수 있게 해주는 기능입니다. 팀 공유 settings.json에 additionalDirectories를 추가해두면 시작할 때마다 자동으로 해당 폴더를 불러옵니다.

14. --agent — 커스텀 에이전트

.claude/agents 디렉토리에 에이전트를 정의해두면 상황에 맞는 시스템 프롬프트와 도구를 가진 에이전트를 바로 불러서 쓸 수 있습니다. Boris가 자주 간과되는 강력한 기능이라고 강조했습니다.

claude --agent=<name>

15. /voice — 음성 입력

CLI: /voice 실행 후 스페이스바 홀드
Desktop: 음성 버튼 클릭
iOS: 받아쓰기 설정 활성화

15가지가 공통으로 가리키는 것

쭉 보고 나면 패턴이 하나 보이는데요, 이 기능들은 대부분 Claude를 혼자 돌아가게 만드는 것들입니다. /loop, /batch, Hooks, Worktrees 전부 내가 자리를 비워도 Claude가 일을 계속하게 하는 구조의 기능이죠. 이 기능들이 가리키는 방향을 보고 있자니, Boris Cherny는 Claude Code를 명령하는 도구로 쓰는 게 아니라, 위임하는 시스템으로 쓰라고 하는 것 같습니다.

적용을 위해 실행해볼 수 있는 것

15가지 중 당장 써볼 수 있는 것부터 시작해보세요.

/btw는 오늘 바로 쓸 수 있고, claude -c로 마지막 대화를 이어가는 것도 간단합니다.
반복되는 작업이 있다면 /loop를 먼저 시도해보세요.
Chrome 확장을 아직 안 쓰고 있다면 프론트엔드 작업 전에 설치해보세요. Claude가 직접 보고 판단할 수 있는 환경을 만들어주는 것만으로 결과물 품질이 달라집니다.

정리

Boris의 15가지는 Claude Code를 명령하는 도구에서 위임하는 시스템으로 바꾸는 방법을 보여줍니다. codex-plugin-cc는 같은 모델의 맹점을 피하기 위해 두 번째 시각을 끼워 넣는 방법을 보여주고요. MIT 논문은 이 맥락에서 불편한 질문을 던집니다. 잘 동의해주는 AI가 편하게 느껴진다면, 그게 오히려 신호일 수 있다고요. AI를 잘 쓰는 것과 AI에게 끌려가는 것의 경계가 생각보다 얇을 수 있습니다. AI가 너무 잘 동의해준다 싶을 때, 그 느낌을 너무 가볍게 넘기지 마시길 바랍니다. MIT 논문이 보여준 것처럼 아첨은 거짓말 없이도 작동하니까요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

효율적인 디자인을 위한 크롬 확장 프로그램 7가지

크롬 확장 프로그램은 이미 많은 사람들에게 익숙하다. 하지만 이 확장 프로그램은 생각보다 우리의 ‘일하는 방식’을 크게 바꿔준다. 북마크바 옆에 작은 아이콘 하나 추가되는 정도라서 존재감은 작지만, 한번 손에 붙으면 그전으로 돌아가기가 꽤 어렵다. 특히 웹에서 할 일이 많은 UX/UI 디자이너라면 크롬은 그냥 브라우저가 아니라 피그마 같은 작업 공간이다. 레퍼런스를 찾고, 경쟁사를 훑고, 화면 구조를 뜯어보고, 폰트나 컬러 같은 단서를 확인하고, QA 하면서 버그나 어색한 부분을 잡고, 그 근거를 캡처해서 문서로 남기는 일들이 대부분 브라우저에서 시작해서 브라우저에서 끝나니까 말이다.

하지만 크롬 확장 프로그램은 생각보다 ‘도구’로 취급받지 못하는 경우가 많다. 회사에서도 뭔가 업무 툴로 공유되기보다는 키보드나 마우스마냥 각자 알아서 깔아 쓰는 개인 취향 정도로 공유된다. 하지만 의외로 사소한 것들이 발목을 붙잡는 법이다. 매번 비슷한 작업을 사람이 손으로 반복한다. 화면에서 색상 값을 하나씩 찍어보고, 폰트 정보를 다시 확인하고, 레이아웃 간격을 대충 눈대중으로 추정하고, 필요한 부분은 캡처해서 폴더에 쌓아두고, 나중에 다시 찾느라 시간을 쓰는 식이다. 그 과정이 한 번이면 괜찮은데, 프로젝트가 길어지고 인원이 늘어나면 ‘작은 귀찮음’이 ‘큰 비용’으로 변한다.

이번 글에서는 웹 UX/UI 분석과 적용에 도움이 되거나, 디자이너의 업무 생산성을 올려주는 크롬 확장 프로그램 7가지를 소개한다. 기준은 단순하다. 반복 작업을 줄여주는가, 분석 과정에서 확신을 더해주는가, 그리고 팀이 같이 쓰면 더 좋은가. 플러그인의 이름과 용도는 다르지만, 목표는 하나다. 브라우저에서 새던 각종 정보를 디자인 의사결정에 쓸 수 있는 소스로 바꾸고, 아낀 시간을 더 중요한 판단에 쓰게 만드는 것이다. 설치해두면 바로 손이 가는 7가지 도구를 하나씩 살펴보자.

웹 화면을 빠르게 해부하는 크롬 확장 프로그램

1) CSS Peeper

CSS Peeper <출처: 작가 캡처>

CSS Peeper는 레퍼런스 사이트를 볼 때, 개발자 도구에서 코드를 뒤지지 않고도 폰트, 컬러, 스타일 같은 디자인 속성을 정리된 UI로 훑어보게 해주는 크롬 확장 프로그램이다. 원하는 페이지를 열고 CSS Peeper를 켜면, 화면에서 필요한 속성을 빠르게 확인하고 추출하는 흐름으로 쓴다. 코드가 아니라 화면 중심으로 정보를 읽게 만드는 도구라는 점이 특징이다.

원하는 요소를 선택하면 그 요소의 텍스트 스타일, 색상, 규격 등을 모두 분석해준다. <출처: 작가 캡처>

디자이너 입장에선 경쟁사나 레퍼런스를 보면서 타이포 계층, 컬러 조합, 컴포넌트 스타일 단서를 빠르게 모을 때 체감이 크다. 레퍼런스를 저장하는 속도도 빨라지고, 무엇보다 '이 사이트는 왜 이렇게 보이지?'를 감으로 넘기지 않고 근거를 붙여서 해석하기 쉬워진다.

웹사이트에 쓰인 색상 팔레트, 타이포 스케일, 이미지 소스들 모두 분석해서 가져올 수 있다. <출처: 작가 캡처>

이런 류의 도구는 팀에 소개할 때 목적을 정확히 잡는 게 중요하다. 완성 UI를 복붙하는 도구가 아니라, 스타일 단서를 빠르게 읽어내는 도구에 가깝다. 그리고 사용 방식이나 제공 범위는 업데이트에 따라 달라질 수 있으니, 팀에 공유하기 전엔 크롬 웹스토어 설명(권한/정책 포함)을 한 번 확인해 두는 게 안전하다.

2) VisBug

플러그인을 실행하면 피그마와 유사한 형태의 가이드라인이 생긴다. <출처: 작가 캡처>

VisBug는 브라우저 위에서 요소를 직접 집어서 옮기고, 크기를 바꾸고, 텍스트를 바꿔보는 식으로 화면을 조정해 볼 수 있는 디자인 디버깅 도구다. 말 그대로 브라우저를 아트보드처럼 다루는 느낌에 가깝고, 실제 서비스 화면이나 프로토타입에서 '바로 이 상태에서 이렇게 바꾸면 어떨까'를 확인할 때 켜서 쓴다.

디자인하듯 텍스트를 수정하고 버튼을 옮기거나 크기를 바꿀 수 있다. <출처: 작가 캡처>

QA나 리뉴얼 논의에서 특히 강하다. 여백, 정렬, 접근성, 거리 같은 걸 눈대중이 아니라 도구로 보면서 대화할 수 있어서, 취향 싸움이 아니라 변화의 근거를 만들어 주기 좋다. 개발자에게 "이거 해주세요"라고 던지기 전에, 디자이너가 프런트 환경에서 빠르게 가설을 세우고 합의안을 만드는 데 도움이 된다.

중요한 건 이게 실제 코드 변경은 아니라는 점이다. 브라우저에서의 수정은 어디까지나 실험과 설득을 위한 것이고, 반영은 개발 프로세스로 넘어가야 한다. 그래서 팀에선 VisBug를 수정 툴이라기보다 검증/합의 툴로 소개하는 게 덜 흔들린다.

3) Responsive Viewer

동시에 여러 해상도를 체크할 수 있다. <출처: 작가 캡처>

Responsive Viewer는 한 페이지를 여러 화면 크기로 동시에 보여주는 반응형 테스터다. 'multiple screens in one view'라는 설명 그대로, 모바일/태블릿/데스크톱 화면을 한 번에 펼쳐놓고 비교하는 방식으로 쓴다. 창 크기를 하나씩 바꿔가며 보는 대신, 같은 순간의 상태를 나란히 확인하는 쪽에 초점이 있다.

모바일 및 태블릿은 목업을 씌워서 보는 기능도 있다. <출처: 작가 캡처>

특히 반응형 QA에서 강하다. 브레이크포인트에서 텍스트가 줄바꿈으로 터지는지, 카드가 찌그러지는지, 버튼 터치 영역이 애매해지는지 같은 걸 기억으로 비교하지 않고 눈앞에서 비교하게 해준다. 그리고 개인정보를 수집/저장/추적하지 않는다고 명시돼 있고, 소스 코드도 공개돼 있어서 팀에서 보안 관련 질문이 나올 때 설명하기가 상대적으로 편하다.

같은 웹의 다른 해상도에서 동일한 버튼을 누르거나 스크롤할 때 어떻게 다르게 보이는지를 체크할 수 있어서 요긴하다. <출처: 작가 캡처>

동적 콘텐츠가 많은 페이지나 로그인 상태에 따라 화면이 바뀌는 서비스는, 비교 화면이 항상 완벽히 동일한 조건으로 맞춰지지 않을 수 있다. 그래서 이 도구는 최종 판정이라기보다 이상 징후를 빠르게 찾는 1차 스캐너로 두는 게 덜 흔들린다.

레퍼런스를 자료로 바꾸는 크롬 확장 프로그램

4) Notion Web Clipper

Notion Web Clipper는 웹에서 보고 있는 페이지를 노션으로 바로 저장하는 크롬 확장 프로그램이다. 노션 공식 확장 프로그램이다. 페이지를 읽다가 저장할 가치가 있으면 버튼 한 번으로 워크스페이스에 클립하고, 나중에 노션에서 다시 보고 정리하는 흐름으로 쓴다. 리서치 자료, 레퍼런스, 경쟁사 페이지처럼 나중에 다시 써야 하는 것을 브라우저 밖으로 꺼내오는 도구다.

원하는 웹사이트에서 확장 프로그램을 실행하면 로그인된 내 노션 계정의 데이터베이스(테이블)을 보여준다. <출처: 작가 캡처>

북마크는 쌓이기만 하고 다시 잘 안 보게 되는데, 노션에 저장되면 정리와 재사용 가능성이 확 올라간다. 팀 단위 리서치를 할 때도, 같은 페이지를 서로 다른 사람이 따로 저장해 두는 낭비를 줄이고, 자료가 한곳으로 모이게 만든다. 'SAVE WITH ONE CLICK'을 강조하는 이유가 딱 그 지점이다.

해당 웹사이트를 그대로 긁어오듯이 저장해 준다. <출처: 작가 캡처>

클립은 쉬운데, 결국 정리가 안 되면 똑같이 쌓이기만 한다. 그래서 인박스처럼 일단 모으는 DB를 하나 정해 두고, 나중에 태그나 속성으로 정리하는 습관이 같이 가야 진짜 효율이 난다. 그리고 회사/클라이언트 관련 자료를 저장할 땐 접근 권한과 공유 범위를 먼저 확인하는 게 안전하다.

5) html.to.design

원하는 웹사이트에서 실행하면 다양한 옵션이 뜬다. 파란색 버튼으로 캡처하면 된다. <출처: 작가 캡처>

html.to.design은 브라우저에서 보고 있는 웹페이지를 캡처해서 피그마로 가져오는 도구다. 크롬 확장 프로그램을 설치한 뒤, 가져오고 싶은 페이지로 이동해서 확장 프로그램 아이콘을 누르면 캡처가 시작되는 방식으로 안내돼 있다. 로그인 뒤 화면이나 특정 상태의 화면처럼, URL만으론 가져오기 어려운 케이스에서 특히 쓰기 좋다.

피그마에서 플러그인을 다시 실행한 후, 캡처한 웹사이트를 선택하면 편집 가능한 레이어로 불러와 준다. <출처: 작가 캡처>

레퍼런스를 그림으로만 보는 게 아니라, 피그마 안으로 들고 와서 비교하고 주석 달고 재구성하는 단계로 넘어가기 쉬워진다. 화면 구조, 정보 밀도, 컴포넌트 조합 같은 걸 빠르게 참고해서 초안을 뽑아야 할 때, 다시 그리는 시간을 줄이는 데 도움이 된다.

가져온 결과가 항상 깔끔하진 않다. 레이어 구조나 오토레이아웃은 기대와 다를 수 있어서, 보통은 그대로 쓰기보단 참고용 베이스로 두고 정리/재작업하는 흐름이 현실적이다. 또한 private network나 로그인 화면을 다루는 만큼, 팀/회사 보안 정책에 맞는지부터 확인하고 써야 한다.

반복 노동을 줄이는 생산성 확장 프로그램

6) OneTab

OneTab은 탭이 너무 많아졌을 때 아이콘을 누르면, 열려 있는 탭을 전부 리스트로 바꿔주는 크롬 확장 프로그램이다. 필요하면 탭을 하나씩 또는 한 번에 복원할 수 있고, 탭을 접어두면 브라우저가 가벼워진다는 점을 전면에 내세운다. 리서치하다가 탭이 30개, 50개로 불어나는 사람에게는 사실상 작업 정리 도구다.

열린 탭들을 한 번에 저장하는 창이 열린다. <출처: 작가 캡처>

탭을 닫는 게 아니라 세션처럼 저장하는 느낌이라 심리적 부담이 적다. 작업 맥락을 잃지 않고도 브라우저를 가볍게 만들 수 있고, 리스트를 내보내거나 공유하는 방식으로 레퍼런스 묶음을 남기는 데도 쓸 수 있다. 크롬 웹스토어에서도 탭을 리스트로 만들고 개별/전체 복원을 지원하는 흐름, 그리고 메모리 절감 포인트를 강조한다.

닫은 탭은 이름도 바꿀 수 있고, 폴더처럼 관리할 수도 있다. <출처: 작가 캡처>

그러나 너무 자주 쓰면, 탭이 정리되는 게 아니라 리스트가 쌓이는 다른 형태의 탭 지옥이 생길 수 있다. 그래서 프로젝트별로 묶는 규칙(예: 경쟁사/레퍼런스/기술문서)을 정해 두고 쓰는 게 좋다. 그리고 확장 프로그램인 만큼 권한과 프라이버시 안내를 설치 전에 한 번 읽어 두는 게 안전하다.

7) Fake Filler

Fake Filler는 폼 페이지의 입력 칸을 랜덤한 더미 데이터로 한 번에 채워주는 크롬 확장 프로그램이다. 이름, 이메일, 전화번호 같은 값을 자동으로 넣어주고, 별도 설정 없이도 바로 쓸 수 있는 'sensible defaults'를 제공한다고 설명한다. 폼 QA를 할 때 매번 키보드로 입력하느라 흐름이 끊기는 걸 줄여주는 용도다.

실행하면 현재 웹페이지의 인풋 요소들을 자동으로 채워준다. <출처: 작가 캡처>

회원가입, 배송지, 결제, 문의 폼처럼 입력이 긴 플로우는 몇 번을 통과해 보느냐가 품질을 좌우하는데, Fake Filler는 그 반복의 피로를 줄여준다. 그래서 디자이너가 폼 UX를 더 자주 돌려보고, 에러 메시지나 포커스 이동, 필수값 검증 같은 디테일을 더 빨리 발견하게 만든다. 커스텀 필드로 확장할 수 있다는 점도 테스트 반복에 꽤 유용하다.

더미 데이터는 편하지만, 실제 사용자 입력 패턴을 완전히 대체하진 못한다. 예를 들어, 비정상 입력, 지역별 주소 포맷, 언어별 이름 길이 같은 건 따로 시나리오 테스트가 필요하다. 또 운영 환경에서 실수로 저장/제출이 되지 않도록, 테스트 서버나 안전한 환경에서 쓰는 습관을 같이 붙이는 게 좋다.

마치며

크롬 확장 프로그램을 소개하는 글은 많지만, 결국 중요한 건 뭘 깔았는지보다 내가 어디에서 시간을 잃고 있는지를 알아차리는 것 같다. 디자이너의 시간은 레퍼런스를 찾다가 길을 잃고, 화면을 분석하느라 탭을 열고 닫고, 근거를 남기느라 캡처와 메모를 반복하고, QA에서 같은 체크를 또 하면서 새어나간다. 오늘 소개한 플러그인들은 그걸 완전히 해결해 주진 못해도, 최소한 손으로 하고 있는 반복 노동을 줄여준다. 그 차이가 쌓이면 일의 속도뿐 아니라 판단의 여유도 생긴다.

다만 플러그인은 많이 깔수록 좋지 않다. 기능이 겹치면 오히려 헷갈리고, 결국 안 쓰는 게 쌓인다. 제일 좋은 방법은 지금 내 업무에서 가장 자주 반복되는 한 구간(예: 화면 분석, 캡처 정리, QA, 문서화)을 떠올리고 거기에 맞는 1~2개만 고정으로 써보는 거다. 그리고 가끔 크롬 웹스토어를 그냥 둘러보는 습관도 은근히 도움이 된다. 좋은 크롬 확장 프로그램은 비밀 무기라기보단 책상을 정리정돈하는 것에 가깝고, 브라우저라는 작업 공간을 조금 더 디자이너 친화적으로 바꿔주는 도구일 것이다.

]]>

몰트북(Moltbook)의 성공에서 반드시 읽어야 할 3가지 포인트

솔직히 말하자면, 처음에는 몰트북(Moltbook)을 보고 그저 웃고 말았습니다.

AI들끼리 글을 올리고 떠드는 SNS라니. “이건 그냥 잠깐 반짝하고 사라질 밈 아닌가?” 싶었거든요. 그런데, 이 기묘한 서비스는 엄청난 속도로 퍼져 나갔고, 결국 메타(Meta) 인수라는 결과로까지 이어졌습니다.

그렇게 몰트북은 AI의 미래를 보여준 서비스를 넘어, 요즘 성공하는 제품의 예시가 되었습니다. 요즘 시대의 프로덕트는 어떻게 화제가 되고 어떻게 퍼질까요?

<출처 : 작가, ChatGPT로 제작>

메타는 왜 이렇게 급히 몰트북을 인수했을까?

최근 테크 업계에서 몰트북 이야기가 다시 나오는 이유는 서비스 자체의 새로움보다, 그 이름 옆에 갑자기 메타(Meta)라는 거물이 붙었기 때문입니다. “AI 에이전트들이 서로 글을 올리고 반응하는 기묘한 소셜 네트워크” 정도로만 보였던 서비스를 그들이 인수한 것이죠.

그렇다면 왜 메타 같은 빅테크가 이렇게 빠르게 몰트북을 인수했을까요?

흥미로운 점은 몰트북이 처음부터 완성도 높은 대형 서비스가 아니었다는 사실입니다. 사실 외형만 보면 꽤나 낯선 실험에 가깝습니다. 인간이 아니라 AI 에이전트들이 서로 소통하는 레딧(Reddit) 형태의 네트워크인데, 오픈클로(OpenClaw)를 사용하는 에이전트들이 글을 올리고 반응하며 상호작용하는 구조니까요.

그런데 바로 그 낯설음이 강력한 질문을 만들어냈습니다. “대체 이건 실험적 사이드 프로젝트인가, 아니면 어떤 흐름의 시작인가?” 그리고 메타라는 빅테크가 움직이는 순간, 이러한 질문은 단순한 구경거리를 넘어서는 의미를 갖기 시작했습니다.

저는 이 지점이 지금 시대의 프로덕트 메이커에게 특히 중요하다고 봅니다.

어떤 제품은 기능 설명부터 길어집니다. 반면 어떤 제품은 존재 자체가 하나의 질문이 됩니다. 몰트북은 분명 후자에 가까웠습니다. 처음 접하는 순간 “이런 게 왜 있지?”라는 반응이 나오고, 시간이 조금 지나면 “그런데 왜 다들 이 이야기를 하지?”로 바뀝니다. 그 궁금증은 곧 “메타는 여기서 무엇을 본 걸까?”라는 질문까지 이어졌습니다. 제품이 시장에 던지는 질문의 크기가 커질수록, 그 제품은 단순한 기능 이상의 의미로 소비됩니다. 몰트북은 바로 그 사례에 가깝습니다.

그래서 저는 몰트북을 “AI들이 자기들끼리 떠드는 신기한 서비스” 정도로 소개하고 끝내려고 하지 않습니다. 오히려 이 사례를 보며, 요즘 제품은 무엇이 잘 만들어졌느냐 못지않게 무엇이 빠르게 이야기거리가 되느냐가 훨씬 중요해졌다는 점을 짚어보려 합니다. 메타 인수는 이를 극적으로 보여준 장면 하나일 뿐입니다. 이제 프로덕트를 만드는 메이커라면 “몰트북이 정확히 무엇이었지?”에서 멈추면 안 됩니다. “왜 이런 서비스가 이렇게 짧은 시간 안에 업계 전체의 화제가 되었을까?”라는 질문을 던질 줄 알아야 합니다.

몰트북은 오픈클로(OpenClaw)가 만든 파도 위에서 터졌습니다

그 이야기를 이어가기 위해서는 먼저 몰트북이 혼자서 떠오른 서비스가 아니었다는 사실부터 살펴볼 필요가 있습니다. 이 서비스가 흥미로운 이유는 “갑자기 어디선가 천재적인 제품 하나가 튀어나왔다”는 서사가 아닌, 이미 어느정도 형성되고 있던 흐름 위에 아주 빠르게 올라탄 서사를 보여주기 때문입니다. 그 흐름의 중심에 있었던 것은 바로 오픈클로(OpenClaw)입니다. 2026년 1월, Clawdbot에서 Moltbot을 거쳐 이름을 바꾼 오픈클로를 두고 Techcrunch는 “입소문 타고 퍼지는 개인용 AI 어시스턴트(viral personal AI assistant)”라고 설명합니다. 기사에서는 이를 사용하는 AI 에이전트들이 몰트북이라는 별도의 소셜 네트워크까지 만들기 시작했다고 전합니다.

이 점을 눈여겨 보려고 합니다. 프로덕트가 주목받는 방식이 예전과는 조금 달라졌기 때문입니다.

예전에는 “좋은 아이디어 하나”가 크게 주목받는 경우가 많았습니다. (물론 지금도 그런 일은 있습니다.) 하지만 요즘은 양상이 다소 달라졌습니다. 이미 형성된 커뮤니티, 이미 쌓인 관심, 이미 활발하게 이어지는 실험 문화 위에 새로운 제품이 빠르게 붙는 순간, 훨씬 더 큰 반응이 나옵니다. 몰트북이 바로 그 전형적인 사례처럼 보였습니다. 오픈클로라는 선행 흐름이 있었고, 사람들은 이미 그 흐름에 호기심을 갖고 있었습니다. 그런 상태에서 “AI 에이전트들이 자기들끼리 떠드는 공간”이 등장하니 반응이 나오지 않는 것이 더 이상할 정도였습니다.

이걸 스타트업 관점에서 조금 더 현실적으로 말하면 이렇습니다. 아무것도 없는 평지에서 불을 붙이는 일은 매우 어렵지만, 이미 어딘가에서 작은 불길이 올라오고 있다면 장작 하나만 잘 얹어도 분위기는 순식간에 달라진다고. 몰트북은 처음부터 거대한 제품이라기보다, 이미 사람들의 시선이 모이고 있던 오픈클로란 흐름 위에 올라탄 매우 영리한 장작에 가까웠습니다. 그래서 이 사례를 볼 때는 “몰트북의 완성도가 얼마나 높았는가”보다 “어떤 타이밍에 어떤 흐름과 이어졌나”를 먼저 보는 것이 더 중요하다고 생각합니다. 프로덕트 메이커라면 이 차이를 놓치지 말아야 합니다. 요즘은 제품의 품질만큼이나, 어떤 흐름에 언제 올라타느냐가 성패를 크게 가르기 때문입니다.

놓치면 안 되는 지점은 속도입니다. 오픈클로가 바이럴 개인용 AI 어시스턴트로 주목받고, 그 위에서 에이전트들이 활동하는 몰트북이 등장한 다음, 이 사례가 여러 매체를 통해 빠르게 확산됐습니다. 그 확산이 결국 메타 인수 이야기로까지 이어졌다고 봐야하죠. 이는 관심이 생기고, 실험이 붙으며, 이야기거리가 생기고, 더 큰 플랫폼이 그 흐름을 포착하는 과정에 가깝습니다. “연계의 속도”가 왜 중요한지가 바로 여기 있습니다. 몰트북은 혼자서 번쩍인 서비스가 아니라 이미 뜨거워진 생태계의 에너지를 가장 빠르게 흡수한 서비스인 셈입니다.

이처럼 몰트북은 “특이한 AI 서비스”이기 때문에 주목받은 것이 아닙니다. 그보다 앞서 오픈클로라는 선행 흐름이 있었고, 그 흐름과 정확한 타이밍에 연결되었기 때문에 더 크게 화제가 될 수 있었습니다. 그러니 프로덕트 메이커가 배워야 할 것은 기능 자체에만 있지 않습니다. 이미 어디에서 관심이 형성되고 있는지, 어떤 실험 문화가 만들어지고 있는지, 그리고 내 제품이 그 흐름과 얼마나 빠르게 연결될 수 있는지를 읽어내는 감각을 배워야 합니다.

첫 번째 포인트, 기능보다 ‘한 줄로 설명되는 세계관’

저는 몰트북이 이렇게 빨리 퍼진 가장 큰 이유 중 하나는, 기능 자체보다도 설명이 매우 쉬운 제품이었다는 점에 있다고 봅니다. 좋은 제품이라고 해서 꼭 잘 퍼지는 것은 아니더라고요. 반대로 기능은 쉬워도, 남에게 한 문장으로 설명할 수 있는 제품은 강력합니다. 몰트북이 딱 그쪽입니다. “AI 에이전트들이 자기들끼리 글을 올리고 반응하는 소셜 네트워크.” 이 한 문장만 들어도 대충 그림이 바로 떠오르죠. 제품 소개를 길게 들을 필요도 없고, 데모를 자세히 보지 않아도 됩니다. 머릿속에 장면이 먼저 그려지고, 호기심을 자극합니다. TechCrunch 역시 몰트북을 오픈클로 기반 AI 에이전트들이 서로 소통하는 레딧형 네트워크라고 쉽게 설명했죠.

이게 왜 중요할까요? 요즘 화제가 되는 제품들이 기능 중심으로 퍼지지 않기 때문입니다. 사람들은 상세 스펙보다 이야기할 수 있는 장면을 더 잘 기억합니다. “정리가 잘 되는 메모 앱”보다 “회의가 끝나자마자 AI가 알아서 일을 나눠주는 도구”가 더 빨리 퍼지는 이유도 여기에 있습니다.

여기를 몰트북은 매우 강하게 포착했습니다. “AI끼리 자기들만의 커뮤니티를 만든다”는 설정은 듣는 순간 조금 황당하지만, 동시에 매우 쉽게 전달됩니다. 설명에 드는 비용이 거의 없는 셈이죠. 프로덕트 메이커 입장에서 이건 결코 가볍게 넘길 수 없습니다. 시장은 항상 좋은 제품만을 기억하지 않습니다. 설명 가능한 제품, 더 정확하게는 다른 사람이 다시 설명하고 싶어지는 제품을 훨씬 빠르게 퍼뜨립니다.

몰트북의 강점은 이 지점에서 더욱 또렷해집니다. 이 서비스는 기능을 하나하나 나열해야 매력이 드러나는 제품이 아니었습니다. 오히려 기능을 자세히 설명하기 시작하면 힘이 좀 빠집니다. 대신 “인간은 구경만 하고, AI들이 자기들끼리 활동한다”는 세계관을 던지는 순간 살아납니다. 저는 이게 꽤 중요하다고 봅니다. 프로덕트는 사용 경험을 중심으로 돌아가지만, 그 이전에 인지 경험이 먼저 있습니다. 사용해 보기 전부터 어떤 제품인지 감이 오는지, 다른 사람에게 말할 때 입에 붙는지, 첫인상이 이미지로 남는지 같은 것이 확산 속도를 좌우합니다. 몰트북은 이러한 인지 경험 설계를 아주 잘한 사례였습니다. 그래서 사람들이 서비스에 직접 들어가기 전부터 이미 이 제품을 머릿속으로 그려보고 있었던 거죠. 스크린샷을 보든, 기사 제목만 보든, 다른 사람의 글을 읽든 마찬가지로요.

프로덕트 메이커가 짚어야 할 포인트가 하나 더 나온 겁니다. 우리는 보통 제품을 만들 때 기능을 우선으로 고려합니다. 무엇을 할 수 있는지, 얼마나 잘 동작하는지, 어디까지 자동화할 수 있는지를 먼저 고민하죠. 물론 중요합니다. 그러나 퍼지는 제품은 여기서 한 걸음 더 갑니다. 이 제품을 한 문장으로 뭐라고 설명할 수 있는가, 그리고 그 한 문장이 사람들의 호기심을 자극하는가까지 함께 설계합니다. 즉, 몰트북은 완성도가 높아서 강했다기보다, “AI 에이전트용 소셜 네트워크”라는 세계관 자체가 호기심을 부르고 쉽게 공유할 수 있었기 때문에 더 반응을 얻었습니다. 그래서 이 사례를 볼수록, 이제는 제품을 잘 만드는 것만으로는 충분하지 않고, 바로 이해할 콘셉트까지 함께 설계해야 한다는 생각이 들었습니다.

두 번째 포인트, 완성도보다 더 강력했던 ‘연계 속도’

몰트북에서 저한테 가장 흥미로웠던 지점은, 이 서비스가 얼마나 빠르게 기존 흐름과 연결됐느냐였습니다. 보통 우리는 화제가 된 제품을 보면 “기능이 엄청 뛰어났나 보다”, “기술적으로 대단했나 보다”라고 먼저 생각합니다. 그런데 실제 시장에서 크게 반응을 얻는 사례들을 보면 꼭 그렇지만은 않습니다. 오히려 이미 사람들의 관심이 모여 있는 흐름에 얼마나 민첩하게 올라타느냐가 훨씬 큰 차이를 만드는 때도 많습니다.

몰트북도 마찬가지였습니다. 오픈클로라는 선행 흐름이 이미 형성돼 있었고, 사람들은 AI 에이전트가 단순한 도구를 넘어 자율적으로 움직인다는 그림에 한창 관심을 갖고 있었습니다. 그 타이밍에 몰트북은 “그 에이전트들이 자기들끼리 활동하는 공간”이라는 아주 직관적인 확장을 내놓았습니다. 쉽게 말해, 완전히 새로운 세계를 만든 것이 아니라 이미 뜨거워진 세계에서 나올 법한 가장 재밌는 장면을 덧붙인 셈입니다.

이런 제품은 강력합니다. 왜냐하면 혼자서 시장을 설득할 필요가 없기 때문입니다. 완전히 새로운 카테고리를 처음부터 이해시키려면 상당한 비용이 듭니다. 이게 무엇인지 설명도 해야 하고, 왜 필요한지도 입증해야 하며, 사람들이 익숙해질 시간도 줘야 합니다. 그러나 이미 관심이 형성된 흐름 위에 올라타면 말이 달라집니다. 사람들의 머릿속에 기본 맥락이 이미 자리 잡고 있으니까요. “오픈클로 알지? 그 에이전트들이 이제 자기들끼리 커뮤니티까지 만든 거야”라는 식의 설명은 훨씬 쉽습니다. 제품 자체를 처음부터 풀어 설명하지 않아도, 선행 맥락이 절반 이상을 알아서 전달해 줍니다. 저는 이게 정말 중요하다고 봅니다. 요즘처럼 정보가 넘치는 때는 더 좋은 제품보다 기존 맥락을 가장 영리하게 이어받은 제품이 훨씬 빠르게 앞서 나가는 경우가 많으니까요.

스타트업이나 사이드 프로젝트를 해본 분들이라면 이 감각이 얼마나 중요한지 잘 아실 겁니다. 아무도 관심을 두지 않는 주제를 붙잡고 “이거 정말 좋은데요?”라고 외치는 건 생각보다 훨씬 힘듭니다. 반대로 이미 사람들이 주목하고 있는 주제 옆에서는 그저 있기만 해도 기회가 생깁니다. 물론 그냥 옆에만 선다고 되지는 않겠죠. 거기서 한 번 더 웃기거나, 놀라게 하거나, 사람들이 공유하고 싶어지는 장면을 만들어야 합니다. 몰트북은 그걸 해낸 사례고요. 오픈클로라는 맥락 위에 올라타되, 복제가 아니라 “AI 자기들끼리 노는 공간”이라는 한 단계 더 강한 장면을 덧붙였으니까요. 그 결과 사람들은 오픈클로에 반응했던 것 그 이상으로 몰트북을 캡처하고, 이야기하며, 기사로 만들기 시작했습니다. 기술 자체보다 연결 방식의 감각이 돋보였던 순간이라고 생각합니다.

이쯤에서는 프로덕트 메이커 입장에서 꽤 불편한 질문을 마주해야 합니다. “나도 제품은 충분히 잘 만들었는데, 왜 아무도 이야기하지 않을까?”라는 질문이죠. 저 역시 이 질문을 여러 번 해봤습니다. 기능 넣고, 디테일까지 신경 썼음에도 반응이 미미할 때는 허탈함이 큽니다. 그러나 냉정하게 돌아보면, 제품 자체의 문제라기보다 연계의 속도와 방향이 느렸던 경우가 많았던 듯합니다. 지금 사람들이 어디에 관심을 두고 있는지, 어떤 실험 문화가 커지고 있는지, 그리고 내 제품이 그 흐름과 어떤 방식으로 붙을 수 있는지를 충분히 읽지 못한 것이죠. 몰트북은 완성도에 대한 평가와는 별개로, 적어도 이 부분에서는 굉장히 뛰어난 사례입니다. 그래서 저는 이 서비스를 “잘 만들어진 제품”이라기보다, “엄청 잘 바이럴된 제품”으로 기억할 것 같습니다.

결국 여기서 얻을 수 있는 교훈은 꽤 현실적입니다. 앞으로의 제품 경쟁은 단순히 누가 더 정교한 기능을 만드는지에서 끝나지 않을 가능성이 큽니다. 그보다 먼저, 누가 더 빠르게 흐름을 읽고, 누가 더 재밌는 방식으로 기존의 파도 위에 올라타며, 누가 더 짧은 시간 안에 사람들의 입에 오르내릴 장면을 설계하느냐가 중요해질 것입니다. 몰트북은 그 사실을 노골적으로 보여줬습니다. 그리고 바로 이 지점에서 마지막 질문이 남습니다.

그렇다면 프로덕트 메이커는 몰트북을 어떻게 봐야 할까요? 단순한 AI 서비스일까요, 아니면 프로덕트 출시 전략이란 관점에서 중요한 힌트를 주는 강력한 케이스일까요?

세 번째 포인트, ‘AI 서비스’보다 ‘바이럴 설계 사례’로 보기

여기까지 오면 이제 질문이 조금 달라집니다. 몰트북이 신기한 서비스였는지 아닌지는 사실 그렇게 중요하지 않을 수도 있습니다. 더 중요한 건 이 사례가 어떻게 그렇게 짧은 시간 안에 사람들의 입에 오르내렸는가입니다. 저는 이 지점에서 몰트북을 단순한 AI 서비스로 보기보다, 프로덕트 런칭 관점에서 인사이트를 주는 바이럴 설계 사례로 봐야 한다고 생각합니다. 다시 말해 “AI가 무엇을 할 수 있는가”보다 “이 제품은 어떻게 이야기되고, 어떻게 퍼지며, 어떻게 더 큰 플레이어의 시야에 들어갔는가”를 봐야 한다는 뜻입니다. 프로덕트 메이커에게 중요한 분기점은 대개 여기서 갈립니다. 기능은 뛰어나지만 아무도 이야기하지 않는 제품이 있는가 하면, 기능은 아직 다듬어질 여지가 있어도 모두가 이야기하는 제품도 있습니다. 시장은 생각보다 냉정해서 후자만을 기억하는 경우가 많습니다.

몰트북은 그러한 현실을 선명하게 보여줍니다. 이 서비스는 처음부터 완성형 정답처럼 보이지는 않았습니다. 오히려 실험적이고, 기묘하며, 밈처럼 소비될 여지도 있는 제품이었습니다. 그럼에도 불구하고 사람들은 이 서비스를 끝없이 이야기했습니다. 기능 목록보다 먼저 설명하기 좋은 콘셉트가 있었고, 그 콘셉트를 실제로 확산시킬 수 있는 장면이 있었으며, 이미 형성된 흐름과 맞물린 타이밍이 있었기 때문입니다. 이 세 가지가 모이면 제품은 단순 출시를 넘어 하나의 사건처럼 소비됩니다. 몰트북이 딱 그랬다고 봅니다. 그래서 이를 두고 “제품이 얼마나 정교했는가”만을 따지는 건 아쉬운 접근입니다.

본질적인 질문은 따로 있습니다. 왜 이 제품은 사람들로 하여금 남에게 이야기하게 만들었을까?라는 질문입니다. 이 질문이 훨씬 중요합니다.

제품을 만들다 보면 우리는 자꾸만 기능 안으로 깊이 들어가게 됩니다. 저도 그렇습니다. 뭘 더 넣어야 할지, 어디를 개선해야 할지, 플로우는 어떻게 다듬어야 할지 같은 고민을 하루 종일 하죠. 그러나 그렇게 들어가다 보면, 때로는 가장 중요한 걸 놓치게 됩니다. 이 제품을 처음 보는 사람이 한 문장으로 이해할 수 있는가, 보고 나서 다른 사람에게 이야기하고 싶어지는가, 현재의 흐름과 붙었을 때 더 큰 반응을 만들 수 있는가 같은 질문들입니다. 몰트북은 그 질문을 다시 강하게 환기시켰습니다. 제품의 완성도는 물론 중요합니다. 그러나 이제는 그것만으로 부족합니다. 잘 만들어진 제품을 넘어, 잘 설명되고 잘 퍼지는 제품이 더 강한 시대가 되고 있다는 느낌을 지우기 어렵습니다.

그래서 몰트북을 보며 한편으로는 무서운 것도 있었습니다. 앞으로는 단순히 만드는 역량만으로는 부족할 수 있겠다는 생각이 들었기 때문이죠. 만드는 사람의 역할이 끝났다는 의미는 아닙니다. 다만 무엇을 만들지, 어떤 타이밍에 내놓을지, 사람들이 어떤 장면을 소비하게 만들지까지 함께 설계하는 역량이 더욱 중요해지고 있다는 뜻입니다. 개발자, PM, 창업자, 그리고 사이드 프로젝트를 진행하는 사람 누구에게나 이 감각은 점점 더 중요해질 것입니다. 좋은 기능을 하나 잘 만드는 일도 어렵지만, 그 기능이 사람들 사이에서 이야기로 살아 움직이게 만드는 건 전혀 다른 차원의 역량이니까요. 몰트북은 바로 그 차이를 매우 짧은 시간 안에 보여준 사례였습니다.

결국 이 글에서 말하고 싶었던 건 단순합니다. 몰트북은 “AI끼리 떠드는 이상하고 낯선 사이트”라서 중요한 것이 아닙니다. 그보다 더 중요한 것은 이 제품이 세계관, 연결, 확산이라는 세 가지 요소로 어떻게 시장의 시선을 사로잡았는가입니다. 그리고 그 끝에서 메타와 같은 거대한 플레이어까지 움직였다는 사실은, 이제 제품 경쟁이 단순한 기능 비교만으로 이루어지지 않는다는 점을 다시 한 번 보여줍니다. 프로덕트 메이커라면 이 사례를 그저 흥미로운 뉴스로 넘기기보다, 자신의 제품에 그대로 적용해 질문해야 합니다.

내 제품은 한 문장으로 설명되는가, 현재의 흐름과 연결되어 있는가, 사람들이 굳이 다른 이에게 이야기하고 싶어질 만큼의 장면을 갖고 있는가. 어쩌면 앞으로의 승부는 바로 그곳에서 갈릴지도 모르겠습니다.

]]>

20년 전 게임 ‘건즈 온라인’을 브라우저로 이식한 개발자

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Code 치트시트 - 명령어부터 단축키까지 매일 자동 업데이트되는 한 장짜리 레퍼런스
참고할 것: 20년 전 게임을 브라우저로 이식한 개발자 - AI 없었으면 불가능했다
적용해볼 것: MCP로 Claude Code 디자인 감도 높이기

<출처: cc.storyfox.cz>

1. 써볼 것: 명령어부터 단축키까지 매일 자동 업데이트되는 한 장짜리 레퍼런스

Claude Code 치트시트는 cc.storyfox.cz에서 운영하는 Claude Code 전용 레퍼런스 페이지입니다. 단축키, 슬래시 명령어, MCP 서버 관리, 스킬·에이전트 설정, CLI 플래그, 환경 변수까지 한 페이지에 정리되어 있습니다. Claude Code 버전이 업데이트될 때마다 자동으로 반영되며, 현재 v2.1.83 기준입니다. Hacker News에도 올라왔습니다.

Claude Code를 처음 쓰기 시작하면 명령어가 어디 있는지 찾는 것 자체가 일입니다. /help를 쳐봐도 양이 많고, 공식 문서를 뒤지다 보면 시간이 금방 지나가죠. 이 치트시트는 그 탐색 비용을 줄여줍니다.

어떻게 쓰나요?

cc.storyfox.cz에서 바로 볼 수 있고, A4 가로 출력도 지원합니다. 윈도우·맥 전환 스위치가 있어서 운영체제에 맞는 단축키를 바로 확인할 수 있습니다. 주요 내용을 추려보면 이렇습니다.

자주 쓰는 단축키

Ctrl+C: 입력·생성 취소
Ctrl+D: 세션 종료
Ctrl+L: 화면 지우기
Ctrl+O: 상세 출력 전환 (thinking 내용 확인 가능)
Ctrl+R: 히스토리 검색
Ctrl+G: 프롬프트를 외부 에디터에서 편집
Ctrl+B: 작업을 백그라운드로 실행
Ctrl+T: 작업 목록 전환
Ctrl+V: 이미지 붙여넣기
Shift+Tab: 권한 모드 순환 (일반 → 자동 수락 → 계획 모드)
Alt+T: 사고(thinking) 모드 전환
Alt+P: 모델 전환
Esc+Esc: 되돌리기

입력 접두사

/: 슬래시 명령어 실행
!: bash 명령어 직접 실행
@: 파일 언급 및 자동완성

알아두면 유용한 슬래시 명령어

/compact: 컨텍스트 압축 (긴 세션에서 비용 절감)
/effort: 노력 수준 설정 (low/med/high/max)
/plan: 계획 모드 진입, 실행 전 검토
/btw: 현재 컨텍스트 비용 없이 별도 질문
/loop: 반복 스케줄 작업 설정
/branch: 대화 분기 생성 (/fork에서 변경됨)

세션 피커 단축키

P: 세션 미리보기
R: 세션 이름 변경
/: 세션 검색
A: 전체 프로젝트 보기
B: 현재 브랜치 기준 보기

최근 추가된 것들 (v2.1.83)

Ctrl+X, Ctrl+K: 백그라운드 에이전트 종료 (기존 Ctrl+F에서 변경)
CwdChanged / FileChanged 훅 이벤트 추가
managed-settings.d/ 드롭인 정책 파편 지원

누구에게 좋을까요?

Claude Code를 막 시작했거나 명령어를 자주 까먹는 분들에게 유용할 것 같습니다. 이미 능숙하게 쓰고 있다면 최근 변경 사항 확인용으로 가끔 들러보는 정도면 충분할 거고요. 매일 자동 업데이트된다는 점에서 북마크 하나 해두면 공식 문서 대신 쓸 수 있습니다.

<출처: blueocean 벨로그 >

2. 참고할 것: 건즈 온라인, 20년 만에 브라우저로 돌아왔다

벨로그를 둘러보다 흥미로운 글을 하나 발견했습니다. 벨로그 닉네임 blueocean이라는 분이 쓴 글인데요. 원문의 내용을 바탕으로 프로덕트 메이커 관점에서 인사이트를 정리해봤습니다. 이 글은 2003년 출시된 윈도우 전용 온라인 TPS 게임 건즈 온라인(GunZ: The Duel)을 WebAssembly + WebGL로 브라우저에서 돌아가도록 이식한 과정을 공유한 내용인데요. 3월 26일 기준, 벨로그 좋아요 102개를 받으며 개발자 커뮤니티에 공유되어 화제가 되었습니다.

건즈 온라인은 2007년경 클라이언트·서버 전체 C++ 소스코드가 유출된 이후 커뮤니티에서 계속 유지·보수되어 왔습니다. blueocean님은 그 소스코드를 기반으로 작업했는데, 게임 코드 자체는 거의 건드리지 않은 채 새로 필요한 코드의 99%를 AI가 썼다고 하네요. 핵심 도구는 Google Antigravity와 Claude Code였습니다.

기존 방식과 무엇이 다른가요?

blueocean님은 이전에도 같은 시도를 한 적이 있다고 합니다. 그 때는 JavaScript와 Three.js로 브라우저판을 처음부터 다시 만들려 했는데, 맵 렌더링까지는 갔지만 게임 엔진 전체를 재구현하는 벽에 막혀 결국 프로젝트가 흐지부지됐고요. 당시 작업한 레포지토리(three-gunz)는 지금도 GitHub에 남아 있다고 합니다.

두 번째 시도에서는 방향을 바꿨습니다. C++ 소스코드를 Emscripten으로 WebAssembly로 컴파일하면 브라우저에서 돌릴 수 있지만, 건즈는 윈도우 전용 그래픽 API인 Direct3D에 달라붙어 있어서 그냥은 불가능했다고 하네요. 이번에는 게임 코드를 건드리는 대신 게임과 그래픽 API 사이에 번역 레이어를 끼워 넣는 방식을 택하여 진행했다고 합니다.

어떻게 작동하나요? (원문 참고 내용)

번역 레이어의 핵심 아이디어는 간단합니다. 게임이 Direct3D에 명령을 보낼 때, 그 명령을 가로채서 브라우저가 이해하는 WebGL 명령으로 바꿔주는 래퍼(d3d9-webgl)를 중간에 끼워 넣는 겁니다. 게임 코드는 여전히 Direct3D에 명령을 보내고 있다고 생각하지만, 실제로는 브라우저 위에서 돌아가는 구조입니다.

렌더링 외에도 서버, 사운드, 입력, 파일 시스템까지 윈도우 전용으로 묶여 있던 것들을 하나씩 브라우저 표준으로 교체했습니다. 음성 파일 포맷을 바꾸는 것만으로 전체 에셋 용량을 88% 줄였고, 결국 링크 하나로 10초 안에 플레이 가능한 상태가 됐습니다.

무엇을 얻어가야 하나요?

이 프로젝트에서 진짜 배울 점은 기술이 아닙니다. blueocean님은 WebGL이나 Direct3D를 잘 몰랐습니다. 그 기술을 몰라도 성공할 수 있었던 이유가 여기 있습니다.

핵심은 두 가지입니다. 하나는 문제를 어떻게 쪼개느냐입니다. 게임 전체를 다시 짜는 게 아니라 번역 레이어 하나를 만드는 문제로 바꾸는 순간, 불가능해 보이던 것이 풀리기 시작했습니다. 다른 하나는 타이밍입니다. 몇 년 전에는 이 번역 레이어를 직접 짜야 했지만, 지금은 AI가 대신 써줍니다. 같은 아이디어가 지금은 실행 가능한 프로젝트가 된 겁니다. 오래 미뤄온 프로젝트가 있다면 다시 꺼내볼 이유가 생겼습니다. 코드를 AI가 써주는 지금, 필요한 건 기술이 아니라 문제를 잘게 쪼개는 능력입니다.

대박입니다

게임은 gunz.sigr.io에서 직접 플레이해볼 수 있습니다. 더 깊은 기술적 맥락과 이식 과정이 궁금하다면 아래 원문을 꼭 읽어보시길 추천합니다. 일본어 원문과 한국어 번역글 모두 같은 분이 직접 작성한 것 같습니다!

일본어 원문 (Zenn): https://zenn.dev/aespa/articles/c9156ae9771367
한국어 번역글 (벨로그): https://velog.io/@aespa/claude-code-gunz-the-duel-web-port
원작자 트위터: https://twitter.com/LostMyCode

<출처: 요즘IT 작가 그릇>

3. 적용해볼 것: MCP로 Claude Code 디자인 감도 높이기

마지막으로 소개할 인사이트는 요즘IT 작가 그릇님의 글입니다. MCP를 연결해 Claude Code로 앱 디자인 감도를 끌어올린 과정을 직접 경험하고 공유한 내용인데요. Claude Code의 까만 터미널 창이 낯설어 커서나 Antigravity로 돌아갈까 고민했던 분이, MCP를 연결하면서 메인 도구로 전환하게 된 이야기입니다.

무슨 문제를 해결하려 했나요?

그릇님이 느낀 문제는 바이브 코딩으로 만든 결과물이 어떤 도구를 쓰든 비슷비슷하게 느껴진다는 것이었습니다. 특히 Claude Code로 만든 결과물이 평범하게 보였고, 원하는 감성과 다른 차가운 블루 톤의 UI가 나왔죠. Stitch로 UI 디자인을 만들어 연결했지만, 키 비주얼을 잡는 데는 한계가 있었다고 합니다.

어떻게 해결했나요?

그릇님의 목표는 웰다잉 앱이었습니다. 죽음 준비가 아니라 삶의 기록이라는 메시지를 담아야 했고, 따뜻한 느낌이 필요했습니다.

먼저 Claude Desktop에 블렌더 MCP를 연결해서 3D 오브제를 만들었습니다. Claude가 별빛 조약돌이라는 키워드를 제안했고, 삶이 끝나는 게 아니라 별이 되어 빛난다는 핵심 메시지와 함께 골드 빛 조약돌을 블렌더로 렌더링했습니다. 3D 툴을 한 번도 써본 적 없었지만, 프롬프트에 오브제 형태, 재질, 조명까지 구체적으로 설명하면 Claude가 블렌더 안에서 직접 세팅하고 렌더링해줬다고 했습니다.

다음으로 Stability AI MCP를 연결해 앱 전체의 컨셉 이미지와 키 비주얼을 만들었습니다. 단순히 이미지를 뽑는 게 아니라 배경 제거, 스타일 조정, 업스케일을 한 대화 안에서 연결해 워크플로로 자동화할 수 있었다고 하죠.

마지막으로 Claude Code에 Figma와 Stitch MCP를 연결했습니다. 블렌더와 Stability AI로 만든 결과물을 Figma에서 컴포넌트로 정리한 뒤, Claude Code에 Figma 스펙에 맞춰 동기화하고 전체 UI에 반영해줘라고 요청해서 최종 완성했습니다.

MCP 연결 순서 요약

블렌더 MCP → Claude Desktop 연결, 3D 키 비주얼 제작
Stability AI MCP → Claude Desktop 연결, 컨셉 이미지 및 배경 생성
Stitch MCP → Claude Code 연결, 초기 UI 컴포넌트 구성
Figma MCP → Claude Code 연결, 디자인 토큰 동기화 및 전체 UI 반영

적용해볼 질문

지금 만들고 있는 프로덕트에서 디자인이 기능을 따라가지 못하고 있는 부분이 있나요? 그릇님의 경험처럼 MCP를 연결하면 디자인 방향을 바꾸더라도 컴포넌트를 전체 화면에 일관되게 적용할 수 있습니다. 프롬프트에 기능 명세만 넣는 게 아니라 어떤 감정을 전달할지, 어떤 메시지를 담을지까지 써봤나요? 같은 기능의 앱이라도 디자인에 따라 사용자가 느끼는 감정이 달라질 수 있습니다.

실행해볼 수 있는 것

Claude Code를 쓰고 있다면 /mcp 명령어로 현재 연결된 MCP 목록을 확인해보세요. Figma나 Stitch MCP가 없다면 하나만 연결해서 디자인 파일을 Claude Code가 직접 읽게 해보세요.
블렌더 MCP는 연결 과정이 복잡한 편이지만, 연결되고 나면 3D 툴 경험 없이도 대화만으로 결과물을 만들 수 있습니다. 스미더리, 컴포시오, mcp.so에서 필요한 MCP를 검색하면 설치 명령어를 바로 받을 수 있습니다.

그릇님이 직접 겪은 시행착오와 더 구체적인 프롬프트가 궁금하다면 요즘IT 원문을 꼭 읽어보시길 추천합니다.

이렇게 적용해보세요

Claude Code를 쓰고 있다면 cc.storyfox.cz를 북마크해두세요. 명령어를 찾는 데 쓰는 시간이 줄어듭니다.
오래 미뤄온 프로젝트가 있다면 다시 꺼내보세요. AI가 코드를 쓰는 역할을 맡으면서 예전에는 혼자 하기 어려웠던 것들의 문턱이 낮아졌습니다. 건즈 이식 프로젝트처럼 때가 올 때까지 기다렸다가 지금 실행하는 것도 전략입니다.
Claude Code로 만드는 결과물이 비슷비슷하게 느껴진다면 MCP 연결부터 해보세요. 어떤 감정을 전달할지를 프롬프트에 담고, 디자인 도구와 직접 연결하면 결과물이 달라집니다.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

AI와 만든 앱에 결제를 붙이는 가장 현명한 방법들 (Feat. MoR)

“SaaS 만들어줘”라고 AI에 말하면 진짜로 하루 만에 돌아가는 앱이 나오는 시대입니다. 그런데 “여기에 월 9,900원 구독 결제 붙여줘”라고 던지는 순간, 대화가 뚝 끊기곤 합니다. 화면은 멀쩡한데 결제 앞에서 프로젝트가 멈춰 서는 거죠. 이게 요즘 말하는 바이브 코딩의 진짜 병목입니다.

많은 분이 결제를 버튼 하나 붙이면 끝나는 기능쯤으로 생각합니다. 하지만 실제 결제는 다른 일반 기능들과 차원이 다릅니다. 사업/세금/환불/심사/정산이 한 덩어리로 묶인 운영 시스템에 가깝죠. 그래서 단순 연동처럼 보이지만, 중간에 PG 심사나 세금 처리 같은 현실 이슈가 튀어나옵니다. 이 지점부터는 AI도 “그건 상황에 따라 달라요” 모드로 멍청해집니다.

그런 만큼 제대로 결제를 도입하려면 더 많은 것을 알아야 하지만요, 이 글에서는 복잡한 설명은 최대한 하지 않겠습니다. 대신 딱 3가지 질문으로 상황을 먼저 분류하고, 케이스별로 가장 빠르게 첫 결제를 받는 경로까지 연결해 보겠습니다. 중요한 건 최고의 결제 도구가 아니라 지금 내 상황에서 제일 빨리 돈이 들어오는 선택지니까요. 이제부터 같이 보겠습니다.

프로덕트가 있는데 왜 결제를 못하나요 <출처: 작가, Gemini로 제작>

결제가 없다면 “검증”은 모두 거짓말

’결제’라는 운영 시스템은 크게 세 가지로 나눠 보면 편합니다. 돈 받기(결제), 돈을 누구 이름으로 받는지(판매 주체), 돈을 받은 뒤 책임(세금·환불·증빙)을 관리하는 방식이죠. 이 셋을 한 번에 생각하지 않으면, 연동은 어렵습니다. 그리고, 이러한 결제가 없다면 검증은 모두 거짓말에 가깝습니다. SNS 글에 좋아요를 1,000개 받아도 결제 1건보다 검증 수치는 약하니까요.

왜 바이브 코딩에서 결제는 병목이 되는가

AI가 코드는 뽑아줄 수 있습니다. 하지만 사업자 요건, PG 심사, 세금, VAT, 환불정책은 자동완성이 잘 안 됩니다. 예를 들어 “구독 취소하면 남은 기간은 어떻게 환불하지?” 같은 질문은 제품 정책에서 나옵니다. 또, 여기서부터는 사회 규범과 법이 함께합니다. 돈을 받고 모른 척 하면 그때부터는 심판의 문제가 된다는 겁니다. 해외 결제라면 국가별 VAT 같은 이슈가 튀어나옵니다. 그러니까 이건 어떻게든 적당히 넘길 수 없습니다. 반드시 사람이 깊이 개입해 결정해야 합니다.

그래서 PMF(사람들이 진짜 돈 내는지 확인하는 단계) 이전에는 완벽한 결제보다 검증 가능한 과금이 우선입니다. 여기서 말하는 핵심은 첫 결제입니다. 첫 결제가 찍히면 누군가는 돈을 낸다는 가정이 사실이 됩니다. 그때부터 결제 UX, 세금 처리, 환불 로직을 고도화해도 늦지 않습니다.

물론 계좌번호를 띄워놓고 무통장 입금을 받을 수도 있습니다. 카카오페이·네이버페이 QR을 올려두는 방법도 있습니다. 하지만 그 방식은 보통 “운영자가 매번 처리해야 하는” 형태입니다. 제품이 알아서 돌아가는 시스템으로는 약합니다. 그래서 한 번은 제대로 된 결제 시스템을 얹어봐야 합니다. 그때 꼭 알아야 할 개념이 MoR과 PG입니다.

MoR(Merchant of Record) vs 일반 PG/PSP

헷갈릴 수 있으니 비유로 풀어보겠습니다.

MoR(Merchant of Record)은 판매 대행상에 가깝습니다. 고객에게 돈을 받고, 영수증을 끊고, 세금과 환불까지 책임지는 쪽이 MoR입니다. 쉽게 말해 돈이 들어오는 순간부터 뒤처리까지 모두 같이 떠안습니다. 그래서 그런 작업에 대한 수수료를 떼고 남은 돈을 보내줍니다.

반대로 일반 PG/PSP는 카드 단말기에 가깝습니다. 결제는 시스템까지 관리해 통과시켜 주지만, 그 뒤의 운영 책임은 내 몫입니다. 예를 들어 Stripe나 국내 PG는 보통 이쪽에 가깝습니다. 결제 창은 붙일 수 있지만 세금·VAT·환불 정책 같은 건 내가 설계해야 한다는 뜻입니다.

그래서 이 두 가지의 선택 기준은 의외로 단순합니다. “나는 지금 결제 뒤처리까지 떠안을 여력이 있나?”라는 질문을 던져보는 겁니다. 여력이 없다면 MoR이 빠르고, 여력이 있다면 일반 PG/PSP가 유연합니다. 바이브코딩으로 속도를 내고 싶을수록 이 차이가 더 크게 느껴질 겁니다.

시작 전에 3가지만 결정하면, 도구는 80% 자동으로 좁혀진다

결제 도구를 고르기 전에 먼저 우리 제품이 무슨 문제를 푸는지 정의해야 합니다. 그러면 곧바로 누가 그 문제를 겪고 있는지, 즉, 고객을 알 수 있겠죠. 그래서 그 고객을 아래 질문과 대응시켜야 합니다. 기능 비교표를 펼치기 전에 방향부터 잡으면 선택지가 자동으로 줄어듭니다. 아래 3가지 질문에 답해보면 됩니다.

<출처: 작가, Gemini로 제작>

질문 1. 결제하는 사람이 한국 유저인가, 해외 유저인가?

이건 결제창을 붙이는 방법이 아니라 결제 뒤에서 터지는 일이 달라지는 문제입니다. 한국 유저라면 카드와 간편결제 UX가 핵심이고, 해외 유저라면 세금과 통화, 실패 처리 같은 운영 이슈가 먼저 튀어나옵니다. 쉽게 말해, 한국은 결제수단이 다양해서 흐름이 복잡하고, 해외는 국가가 다양해서 규칙이 복잡합니다.

한국 유저가 주로 결제한다면 PG 연동이 일단 최우선입니다. 다만 이건 연동한다고 끝나는 문제가 아니라, 심사와 정산까지 포함된 운영 계약에 가깝습니다. 특히 나중에 고객응대나 회계 처리에서 발목 잡히지 않으려면 처음부터 흐름을 그려두는 게 좋습니다. 당연히 안전하지만, 속도는 느릴 겁니다. 물론 그런 만큼 한국 유저들에 익숙한 흐름입니다. 결제 과정이 이탈의 요소가 될 가능성은 적죠.

해외 유저가 결제한다면 질문이 바뀝니다. 결제가 되는지보다 결제가 된 다음 세금과 분쟁을 감당할 수 있냐는 문제가 더 중요해집니다. 특히 SaaS는 결제 실패와 차지백이 생각보다 자주 생기고, 그때의 대응 방식이 곧 운영 비용이 됩니다. 그래서 이슈가 생겼을 때 어떻게 대응할지를 공부해야 합니다.

질문 2. 구독 vs 일회성 vs 사용량 기반

같은 결제라도 과금 모델이 달라지면 필요한 기능이 완전히 달라집니다. 요금제 변경과 환불, 실패 복구 같은 운영 로직도 붙기 때문입니다. 그래서 도구를 고를 때도, 결제창보다 운영 시나리오를 먼저 적어보는 게 안전합니다.

구독이라면 결제는 시작일 뿐입니다. 유저는 중간에 플랜을 바꾸고, 무료체험을 쓰고, 결제를 놓치기도 합니다. 이걸 매번 사람이 처리하면 앱이 커질수록 운영이 무너집니다.

일회성 결제는 단순해 보이지만, 막상 운영하면 환불이 핵심입니다. “환불해 주세요”라는 요청은 거의 반드시 오고, 부분환불도 종종 생길 겁니다. 또 디지털 상품이라면 결제 완료 후 전달하는 프로세스가 분명히 만들어져야 CS가 줄어듭니다.

사용량 기반은 계량(usage metering)이 전부입니다. 특히 AI 앱은 토큰이나 요청 수를 정확히 집계해야 하는데, 이게 성능과 정확도 둘 다에서 병목이 되기 쉽습니다. 즉, 결제 연동보다 먼저 무엇을, 어떤 단위로, 언제 집계할지 결정해야 합니다.

질문 3. 사업자등록이 있는가, 없는가?

사실 이것이야말로 애초에 가능한 선택지가 뭔지 가르는 질문입니다. 특히 국내에서는 PG가 거의 모두 사업자 기반으로 움직이는 경우가 많아 사업자등록 유무가 곧 출발선이 됩니다.

사업자등록이 없다면, 현실적으로 국내 PG 연동이 막히는 경우가 많습니다. 그래서 이 단계에서는 MoR(Merchant of Record) 같은 대안이나 노코드형 우회가 더 빠른 선택이 될 수 있습니다.

사업자등록이 있다면, 이제부터는 장기 운영이 가능한 구조를 고르는 게 중요합니다. 심사 통과만이 아니라 정산 주기와 세무 처리까지 이어지는 흐름이 있기 때문입니다. 처음엔 작은 앱이어도 결제가 붙는 순간부터는 운영이 ’업무’가 됩니다. 그러니 심사, 정산, 세무 프로세스를 맞춰야 합니다.

3가지 기준, 즉, “국내/해외 × 과금모델 × 사업자 유무” 매트릭스를 만들면 내 케이스가 한 칸으로 떨어집니다. 다음 단계는 간단합니다. 그 칸에서 정답에 가까운 결제 도구를 고르고, 가장 빠른 연동 경로로 첫 결제를 받는 겁니다.

내가 처리 안 하는 게 첫 런칭에 유리하다: Polar·Lemon Squeezy·Paddle

결제를 시도할 때 사람들이 가장 많이 멈칫하는 지점은 따로 있습니다. 세금과 증빙입니다. “VAT는 누가 처리하지?”, “환불하면 영수증은?”, “나는 사업자도 아닌데 괜찮나?” 같은 질문이 한꺼번에 몰려옵니다. 운영의 책임이 눈앞에 나타나기 때문입니다.

그래서 이럴 때는 MoR을 검토해 보는 것을 권합니다. 물론 모두 해외 서비스여서 한국 사람에게 익숙한 UX를 지원하지 않는데다 제한되는 상황도 많습니다. 수수료도 쎄고요. 그래도 운영의 책임을 큰 폭으로 줄여주는 것은 분명합니다. PG 심사를 위해 사업자등록증부터 발급해야 한다는 상황이라면, 더더욱이요. 역으로 생각해도 좋습니다. 해외 타깃으로도 시도해 볼 수 있다는 거니까요.

바이브 코딩에 어울리는 MoR 플랫폼들

Polar: AI 앱 메이커를 위한 판매자의 역할

Polar는 오픈소스 MoR(Merchant of Record) 입니다. 특히 해외 결제에서 골치 아픈 세금·VAT 처리를 Polar가 대행해줍니다. 처음 런칭할 때 “세금 설계부터 해야 하나?”라는 부담을 크게 줄여줍니다.

Polar의 첫 번째 강점은 사용량 기반 과금(usage-based) 을 기본으로 깔고 있다는 점입니다. 특히 OpenAI·Anthropic API 사용량을 자동으로 수집해서, 유저별로 쓴 만큼 청구하는 흐름이 자연스럽게 이어집니다. AI 앱은 비용 구조가 토큰 사용량에 붙어있는 경우가 많습니다. 이때 Polar는 결제 모델과 제품 구조가 잘 맞습니다.

두 번째 강점은 비용입니다. Polar는 수수료가 4% + 40¢로 알려져 있습니다. MoR 계열 중에서도 저렴한 축에 속합니다. 첫 매출이 작을수록 이런 고정 비용 차이가 체감됩니다.

세 번째 강점은 디지털 혜택을 결제와 바로 묶는 능력입니다. 예를 들어 GitHub 레포 접근권, 라이선스 키 같은 혜택을 구독과 연결할 수 있습니다. 즉, 결제가 끝나면 권한이 자동으로 열리는 그림이 나오는 거죠. 운영자가 손으로 처리할 일이 줄어듭니다.

현실적인 측면에서, Polar는 사업자등록 없이도 시작할 수 있습니다. 그래서 일단 팔리는지 검증이 목표인 단계에 특히 유리합니다. 첫 런칭에서 중요한 건 완벽한 구조가 아니라 빠른 학습 속도입니다.

Lemon Squeezy: AI가 아닌 일반 SaaS/디지털 상품에 범용

Lemon Squeezy도 MoR이라 세금 부담이 상대적으로 적습니다. 체크아웃과 기본 설정이 직관적이라 결제 연동에 시간을 많이 쓰고 싶지 않을 때 편합니다. 일단 결제 페이지부터 띄우자는 목표에 잘 맞습니다.

특히 처음엔 제품 내에서 예쁜 결제 페이지와 빠른 판매를 연결하는 게 더 중요한 경우가 많습니다. 개인 메이커나 소규모 팀이라면 더 그렇습니다. 이럴 때 Lemon Squeezy는 설정하다 지쳐서 출시가 밀리는 상황을 줄여줍니다.

마찬가지로 개인도 시작할 수 있다는 점이 장점입니다. 법인부터 만들고 오는 대신 작은 시작을 받아주는 쪽에 가깝습니다. 첫 런칭의 허들을 낮추는 선택지입니다.

Paddle: B2B SaaS로 커질 계획이라면

Paddle은 MoR 기반이면서, 인보이스와 엔터프라이즈 기능까지 제공합니다. 쉽게 말해, 결제가 개인 카드 결제에서 끝나지 않는 환경을 염두에 둔 도구입니다. B2B SaaS는 자연스럽게 나중에 견적서, 인보이스, 내부 결재 같은 흐름이 따라오는데요. 그때 필요한 기능을 한 번에 묶어둔 쪽입니다.

다만 1인 메이커의 첫 런칭이라면 Paddle은 오버스펙일 수 있습니다. 처음부터 큰 조직의 프로세스를 들고 오면 출시 속도가 느려질 수 있거든요. 그래서 지금 필요한지, 나중에 필요한지, 성장 계획이 명확할 때 선택하는 편이 낫습니다.

+Stripe: 가장 유연하지만, 책임이 따라온다

마지막으로 해외 고객을 위한 PG로, 전 세계에서 거의 가장 유명한 결제 연동 서비스 Stripe도 있습니다. 장점은 명확합니다. 레퍼런스, 문서, SDK, 확장성이 강합니다. 원하는 결제 흐름을 직접 설계하고 제품에 맞게 촘촘히 붙일 수 있습니다. 결제에서의 자유도만 보면 가장 매력적인 선택지입니다.

하지만 핵심 단점도 분명합니다. Stripe는 MoR이 아닙니다. 그래서 VAT/세금/환불/증빙을 내가 직접 설계해야 합니다. 그런 부담을 안고 있는데 한국에 완전 최적화된 방식은 아니니 쉽지가 않습니다. 한국 사업자도 가입할 수 있지만, 원화 정산 구조가 번거로울 수 있다는 뜻입니다. 연동은 쉬운데, 정산에서 시간이 새는 상황이 생길 수 있으니 미리 확인하는 편이 안전합니다.

한국에 있어야 결국에는 더 빠르다: 토스페이먼츠·스텝페이·포트원

국내 결제는 “코드만 붙이면 끝”이 아닙니다. 보통 사업자등록이 먼저 필요하고, 그다음에 PG 심사가 끼어듭니다. 이 심사가 보통 1~3일은 걸리다 보니 오늘 당장 결제 받기가 목표라면 도구 선택이 꺼려질 수도 있습니다.

하지만, 같은 기능이라도 연동 과정이 매끄러운 쪽이 결국 더 빨리 출시됩니다. 여기서 말하는 속도는 단지 개발 속도가 아닙니다. 심사, 정산, 운영까지 감안했을 때의 체감 속도입니다. 문제가 생겼을 때, 한글로 쓰여진 가이드, 한글이 편한 상담원과 대화할 수 있는 것이 마음에 훨씬 편하죠. 그래서 국내 유저를 받을 때 무작정 MoR을 먼저 떠올리기보다, 내 상황에 맞는 결제 도구가 무엇인지부터 보는 게 안전합니다.

특화 포지션을 가지고 있는 국내 결제 연동 플랫폼

토스페이먼츠: 바이브코딩과 궁합이 좋은 포지션

토스페이먼츠는 국내에서 개발자 경험(DX)이 좋기로 유명한 쪽입니다. 연동 문서와 흐름이 비교적 매끄러워서 일단 붙여서 돌아가게 만들기가 빠릅니다. 최근에는 MCP 서버까지 도입하면서 바이브 코딩 흐름과의 궁합이 더 좋아졌습니다.

쉽게 말해, Cursor나 Claude Code에서 “결제창 연결해줘” 같은 자연어 지시를 했을 때, 연동에 필요한 코드가 생성되는 길이 열린 겁니다. 예전에는 문서 읽고, 샘플 찾고, 키를 맞추는 시간이 컸다면, 이제는 그 구간이 짧아질 수 있습니다. 다만 여기서 기대치는 관리해야 합니다. 코드는 당일에 붙어도, 상용 오픈은 PG 심사 이후라는 점은 그대로입니다.

스텝페이: 구독 운영을 제품으로 제공하는 길

스텝페이는 결제창을 연동하는 도구라기보다, 구독 운영을 제품으로 묶어서 제공하는 쪽에 가깝습니다. 노코드로 구독 스토어를 만들 수 있고, 정기결제에 필요한 기능들이 기본으로 들어 있습니다. 개발 리소스가 적을수록 이 차이가 크게 느껴집니다. 특히 구독 SaaS에서 진짜 어려운 건 결제 버튼이 아닙니다. 요금제 운영과 미납 처리가 본게임입니다. 스텝페이는 이런 구간을 제품 기능으로 제공합니다. 예를 들면 아래 같은 것들입니다.

사용량 기반 과금
무료 체험
결제 복구(미납 시 카톡 청구서 등)

그래서 요금제가 복잡하거나, 정기결제 운영을 빨리 검증해야 하거나, 일단 팔아보고 고치자가 목표일 때 또 고려할 만한 선택지입니다. 결제를 붙이는 속도뿐 아니라, 운영까지 포함한 속도가 빨라집니다.

포트원: 결제수단을 여러 개 붙일 때의 통합 레이어

포트원은 여러 결제수단을 한 번에 다루고 싶을 때 빛납니다. 토스페이먼츠, KG이니시스, 카카오페이, 네이버페이 같은 것들을 하나의 SDK로 통합하는 방식입니다. 쉽게 비유하면, 결제사마다 다른 리모컨을 쓰는 대신 리모컨 하나로 여러 기기를 조작하는 느낌입니다.

다만 이 방식이 처음부터 좋다고는 말하기 어렵습니다. 결제가 하나도 안 나오는데 창구는 10개 열어둬봤자니까요. 핵심 이점은 나중에 나옵니다. 처음에 선택을 잘못했을 때면 보통은 연동 코드를 다시 갈아엎어야 하는데요. 포트원은 PG사를 변경/추가하는 비용을 낮춰서 초기 선택 실수 비용을 줄여줍니다.

그래서 결제수단을 빠르게 다변화해야 하거나, 특정 PG에 락인(lock-in) 되는 게 걱정될 때 붙이기 좋습니다. 지금은 하나로 시작하되, 다음 분기에 확장할 가능성이 높다면 특히 안정적인 선택이 됩니다.

물론 사실 이 모든 것보다 중요한 건 수수료가 아닐까요? 수수료는 조금씩 달라지기도 하고, PG를 제공하는 기업이 워낙 많은 만큼 따로 정리하지는 않았습니다. 국내 PG를 붙이기로 마음 먹었다면 웬만하면 여러 PG를 꼼꼼하게 검토하기를 추천드립니다. 여기 남긴 것들은 좀 특수한 성격을 가진 것들 위주입니다.

+ 그 전에, 불안을 줄이는 “고객 체크리스트” 먼저

첫 결제를 빨리 받는 것만큼, 사용자의 불안을 줄이는 것도 중요합니다. 거창한 문서가 아니라 최소한 아래 다섯 가지는 화면 어딘가에 보이게 두는 게 좋습니다. 여기 돈 내도 괜찮다는 느낌이 생겨야 결제 전환이 생깁니다.

환불 기준: 언제까지, 어떤 조건이면 환불되는지 한 문장으로
결제 실패 안내: 결제 오류가 나면 무엇을 확인해야 하는지
고객문의 채널: 이메일/오픈채팅 등 연락할 곳 하나는 고정
이용약관 위치: 링크 한 줄이라도 찾을 수 있게
영수증/세금 처리 방식: 영수증 제공 여부, 세금계산서 가능 여부 등

결국 첫 결제는 기능이 아니라 신뢰의 문제입니다. 정책을 크게 만들 필요는 없고 불안 포인트만 먼저 제거하면 됩니다. 그렇게 하면 결제, 연동, PG라는 큰 산도 생각보다 빨리 넘어갈 수 있습니다.

마치며

바이브코딩 시대에 결제의 난이도는 코드가 아니라 내 상황에 맞는 도구 선택에 가깝습니다. 연동만 붙이면 끝처럼 보이지만, 막상 들어가면 PG, 세금, 환불, 정책이 한꺼번에 따라오니까요. 그래서 복잡하게 시작하지 말고 딱 세 가지 질문으로 갈라타면 됩니다. 핵심은 (1) 국내/해외 (2) 과금모델 (3) 사업자 유무입니다.

이제 남은 건 실행입니다. 오늘은 내 서비스 조합을 먼저 적어보세요. 예를 들어 “빠른 시도 + 구독 + 사업자 없음” 같은 형태로요. 조합이 정해지면 루트는 거의 자동으로 좁혀집니다. Polar/Lemon Squeezy 중 하나를 골라 첫 결제까지 하루 안에 도달하는 걸 목표로 잡으면 됩니다.

그리고 여기서 중요한 마인드셋이 하나 있습니다. 진짜 어려운 건 결제를 붙이는 것이 아니라 결제해줄 유저를 찾는 것이라는 마인드입니다. 결제, 연동, PG에 에너지를 다 쓰며 매달리기보다 가능한 한 빨리 마케팅과 세일즈로 이동하는 편이 훨씬 현명합니다. 돈 낼 사람을 찾고, 그 사람의 마음이 어느 정도인지 알아보는 것이 바이브 코딩에는 더 중요할지 모르겠습니다.

]]>

UX 데이터 분석부터 퍼소나 생성까지, 어피니티버블 사용기

퍼플렉시티, 리스틀리, 클로드 3가지 도구로 사용자 데이터를 수집하고 분석하는 방법을 소개한 글을 쓴 적이 있다. 특히, 리스틀리는 구글 플레이스토어의 앱 리뷰 데이터를 원하는 범위까지 수집·분석할 수 있어 특정 서비스의 사용자 피드백을 분석할 때 매우 유용했다. 하지만 리뷰를 수동으로 드래그해야 하고, 전체 리뷰 보기를 제공하지 않는 iOS 앱스토어의 리뷰는 수집할 수 없다는 등 한계도 여전히 존재했다.

이에 이번 글에서는 이러한 한계를 보완하는 동시에, 보다 간편한 방식으로 데이터 분석까지 수행할 수 있는 새로운 AI 도구를 소개하고자 한다.

어피티니버블로 한 다방 앱 리뷰 분석 결과 <출처: 작가>

어피니티버블 사용하기

이번에 살펴볼 AI 도구는 어피니티버블(Affinity Bubble)이다. 이름에서 알 수 있듯, 방대한 양의 정성 데이터를 분류하고 그룹핑하는 어피니티 다이어그램(Affinity Diagram) 방식을 대신 수행해주는 AI이다. 흩어져 있는 텍스트를 의미 단위로 묶어 정리할 수 있기 때문에 사용자 리뷰나 VOC 분석 시 활용하기에 좋다.

어피니티버블 기능 설명 <출처: 작가, 어피니티버블 캡처>

1. 앱 리뷰 분석하기

이번에도 특정 앱의 리뷰를 가져와 분석하는 작업을 해보기로 했다.

가장 먼저, 구글에서 어피니티버블을 검색한 다음 사이트에 접속해 로그인을 진행한다. 이후 메인 화면에 있는 ‘내 데이터로 분석해보기’ 버튼을 클릭했다.

‘내 데이터로 분석해보기’ <출처: 작가, 어피니티버블 캡처>

나오는 화면의 좌측 메뉴에서 [앱 리뷰 수집] 항목을 선택했다. 오른쪽 화면에 앱 이름을 입력하고 ‘구글 검색하기’ 버튼을 누르니, 해당 앱의 Apple 앱스토어와 Android 플레이스토어로 연결되었다. 그 페이지에서 링크를 복사한 다음 ‘스토어 URL 입력’ 칸에 붙여넣기 해주면 된다. ‘리뷰 가져오기’ 버튼을 누르면 자동으로 사용자 리뷰 데이터가 수집된다.

메뉴 바(왼쪽)와 앱스토어 주소 입력 화면 <출처: 작가, 어피니티버블 캡처>

수집 시에는 [리뷰 타임라인] 섹션에서 원하는 기간을 선택해줄 수도 있다. 기본적으로 리뷰가 등록된 전체 기간이 표시된다. 다만, 과거에 언급된 페인포인트는 이미 해결되었을 가능성도 있으니 최신 리뷰(예: 25년도부터 26년까지)만 확인하고 싶다면, 하단의 스크롤을 조정하면 된다. 이렇게 수집할 공간과 기간을 설정하고, 아래로 스크롤을 더 내리면 별점 분포와 선택된 리뷰를 미리 확인할 수 있다.

리뷰 타임라인(왼쪽)과 수집 리뷰 <출처: 작가, 어피니티버블 캡처>

여기까지 확인한 다음 ‘어피니티버블로 분석하기’ 버튼을 누르면 바로 결과가 나온다.

어피니티 다이어그램 <출처: 작가, 어피니티버블 페이지 캡처>

인사이트 요약 보고서 <출처: 작가, 어피니티버블 캡처>

이미지는 각각 분석 결과로 제공되는 어피니티 다이어그램과 인사이트 요약 보고서이다.

이러한 결과물로 사용자 리뷰에서 어떤 의견이 발견되는지, 또 어떤 의견이 반복적으로 등장하는지를 한눈에 확인할 수 있다. 예를 들어 어피니티 다이어그램을 보면 허위 매물 및 관리 부실, 필터 기능 부족, 앱 오류와 같은 이슈가 그룹핑되어 있으며, 각 그룹 내에서 세부적인 사용자 의견이 어떻게 나타나는지도 직관적으로 파악할 수 있다.

2. 그 외 정성 데이터 분석하기

그렇다면 앱 리뷰가 아닌 다른 종류의 정성 데이터도 분석할 수 있을까?

실제 어피니티버블 메인 화면에서는 앱 리뷰뿐 아니라 주관식 설문, VOC 데이터, 사용자 인터뷰 등 다양한 활용 사례를 함께 제시하고 있다. 다만 한 가지 주의할 점은 CSV 파일 형식으로만 데이터 첨부가 가능하다는 것이다. 따라서 앱 리뷰 외의 다른 데이터를 분석하고자 한다면, 먼저 외부 도구를 통해 데이터를 추출한 뒤 CSV 형태로 변환해야 한다.

이때 활용할 수 있는 도구가 이전 글에서 소개했던 리스틀리(Listly)다. 리스틀리를 활용해 원하는 데이터를 수집한 후 CSV 파일로 저장하면, 이를 어피니티버블에 업로드해 앱 리뷰와 동일한 방식으로 분석할 수 있다.

1단계. 리스틀리 설치

구글 크롬에서 ‘리스틀리’를 검색한 뒤 설치하면, 크롬 상단에 리스틀리 아이콘이 표시된다. (리스틀리는 구글 확장 프로그램이므로 크롬에서 사용할 수 있다.)

리스틀리 <출처: 작가 캡처>

2단계. 데이터 수집

데이터 수집을 원하는 페이지에 접속한 다음, 리스틀리 아이콘을 클릭하고 ‘PARTS: 부분 선택하기’ 버튼을 누른다. 이때 데이터 선택 전에 미리 리스틀리에 로그인을 해두면, 바로 파일을 다운로드할 수 있다.

준비가 끝나면 수집하고자 하는 데이터를 드래그해 선택한다. 모든 선택이 끝나면 우측에 있는 ‘RUN LISTLY’ 버튼을 누르면 된다.

PARTS: 부분 선택하기(왼쪽)와 RUN LISTLY <출처: 작가 캡처>

3단계. 데이터 확보

수집이 끝나면 엑셀과 구글 시트 중 하나를 선택해 데이터 파일을 다운로드할 수 있다. (예시에서는 구글 시트를 선택했다.) 다운로드한 파일을 열고 파일 → 다운로드 → 쉼표로 구분된 값(.csv)을 차례로 선택해 CSV 파일로 변환한다.

구글 시트 내보내기(왼쪽)와 CSV 추출 <출처: 작가 캡처>

이렇게 CSV 데이터 파일이 만들어지면, 이를 어피니티버블로 가지고 온다. 다시 메인 화면에 있는 ‘내 데이터로 분석해보기’를 클릭하면 바로 데이터를 첨부할 수 있는 창으로 이동한다. 여기에 CSV 파일을 넣어주면 된다.

데이터 입력 단계 <출처: 작가, 어피니티버블 캡처>

3. 실제 사용자 데이터 기반 퍼소나 생성하기

지금까지 앱 스토어 링크로 사용자 리뷰를 수집하고 분석하는 방법과, 그 외 정성 데이터를 추출해 분석하는 방법을 각각 살펴봤다. 어피니티버블에서는 이렇게 수집한 데이터를 기반으로 퍼소나를 생성해볼 수도 있다.

방법은 간단하다. 바로 이전 단계에서 CSV 파일을 첨부했던 페이지가 있다. 해당 페이지에서 스크롤을 더 내려보면 세 번째 단계에서 인사이트 리포트 형식을 변경할 수 있는데, 여기서 ‘요약 정리’ 대신 ‘퍼소나’를 선택하면 된다.

인사이트 리포트 형식 선택 <출처: 작가, 어피니티버블 캡처>

이 방식으로 생성된 인사이트 보고서를 살펴보면, 앱스토어에 등록된 사용자 리뷰를 바탕으로 퍼소나 유형이 나뉘어 있는 것을 확인할 수 있다.

퍼소나형 인사이트 리포트 1 <출처: 작가, 어피니티버블 캡처>

퍼소나형 인사이트 리포트 2, 3 <출처: 작가, 어피니티버블 캡처>

예를 들어 다방 앱 사용자 리뷰에서는 허위 매물에 대한 페인 포인트가 반복적으로 나왔는데, 이러한 내용이 반영되어 ‘신뢰 중시형 주거 탐색자’ 퍼소나 유형이 첫 번째로 도출됐다. 이 퍼소나는 신속하고 정확하게 원하는 조건의 매물을 찾는 것을 주요 목적으로 삼기 때문에, 앱에서 허위 매물을 발견했을 때 큰 불편을 느낀다.

이 외에도 상세 필터와 지도를 활용해 효율적으로 매물을 비교하려는 ‘기능 지향적 파워 유저’, 그리고 복잡한 절차 없이 빠르게 결과를 얻고자 하는 ‘효율성 추구형 사회초년생’ 퍼소나 유형이 함께 생성됐다.

이전 글에서는 GPTs와 Synthetic Users 등 도구를 활용해 가상의 퍼소나를 생성하는 방법을 소개한 바 있다. 이러한 방식은 사용자를 보다 깊이 이해하는 데 도움을 줄 수 있었지만, 실제 사용자 데이터가 아닌 가상으로 생성된 합성 데이터라는 점에서 완전히 신뢰하기에는 다소 어려움이 있었다. 반면 이번 방법은 실제 사용자 데이터를 기반으로 퍼소나 유형을 도출했다는 점에서 신뢰도와 활용도가 더욱 높다고 볼 수 있다.

또한 단순히 퍼소나 유형을 구분하는 데서 그치지 않고, 해당 퍼소나를 기반으로 사용자 인터뷰 시뮬레이션을 진행하는 방식으로도 확장할 수 있다. 예를 들어 챗GPT나 클로드와 같은 LLM 도구에 퍼소나 설명을 붙여넣고 “이제부터 이 퍼소나가 되어서 사용자 인터뷰 질문에 답해줘.”와 같은 프롬프트를 입력하면 된다.

*더 자세한 방법은 사용자 인터뷰 시뮬레이션 글에서 확인할 수 있다.

마치며

이번 글에서는 어피니티버블을 활용해 정성적 데이터를 분석하는 방법을 살펴봤다.

업무에서는 예시로 설명했던 사용자 앱 리뷰 외에도 다양한 채널에서 수집되는 VOC나 인터뷰 결과 등 방대한 정성적 데이터를 직접 분석하려면 상당한 시간이 소요된다.

반면 어피니티버블은 이러한 과정을 효율적으로 단축시킨다. 데이터 내에서 반복적으로 등장하는 주요 패턴과 사용자 니즈, 페인 포인트 등을 자동으로 구조화해 보여주기 때문에 방대한 정성적 데이터에서도 핵심 인사이트를 빠르게 파악할 수 있다. 그 결과 데이터 분석과 의사결정에 필요한 시간을 줄일 수 있다는 점에서 실무적으로 유용한 AI 도구다.

또한 어피니티버블 서비스를 제공하는 pxdAX에 따르면, 사용자가 첨부한 데이터는 처리 완료 즉시 폐기되어 어떠한 형태로도 저장되지 않는다고 한다. 이러한 점을 고려하면 다른 AI 도구로 데이터를 분석하는 것보다 비교적 안전하게 활용할 수 있다는 점도 하나의 장점으로 볼 수 있다. 개인적으로는 이전에 리스틀리와 클로드를 함께 활용해 다소 복잡한 방식으로 분석을 진행했던 경험에 비추어 어피니티버블은 리서처와 디자이너의 실제 니즈를 고려해 설계된 도구라는 인상을 받았다.

이처럼 AI로 서비스나 프로그램을 훨씬 빠르게 만들 수 있는 환경이 갖춰지고 있는 요즘, 이러한 현실적인 니즈를 충족하는 도구의 중요성은 점점 더 커지고 있는 듯하다.

다시 말해, 사용자에게 의미 있는 서비스를 만들기 위해서는 여전히 사용자의 니즈와 페인 포인트를 정확하게 포착하는 과정이 필수적이라는 뜻이다. 얼마나 빠르게 서비스를 완성하느냐보다, 사용자의 문제를 얼마나 명확하게 해결하느냐가 더 중요하기 때문이다. 이는 AI 기술이 계속 발전하더라도 인간 사용자의 감정에 공감하고 니즈를 해석하는 역량이 여전히 중요하게 강조되는 이유이기도 하다.

그런 관점에서 어피니티버블은 이러한 니즈를 반영해 설계된 서비스의 좋은 사례다. 또한, 그 자체로 방대한 사용자 데이터를 더 빠르게 이해하고 이를 니즈나 페인 포인트와 같은 인사이트로 연결할 수 있도록 돕는 유용한 보조 도구라고 할 수 있다.

]]>

매일 쓸 것 같다던 그 기능, 왜 아무도 안 썼을까?

UX 리서치를 하다 보면 이상하게 자주 반복되는 장면이 있다. 사용자는 인터뷰에서 매일 쓸 것 같다고 말하고, 설문에서는 알림이 꼭 필요하다고 체크하고, 쇼핑 앱에서는 가격이 제일 중요하다고 단언한다. 그런데 출시 후 데이터를 보면 그 기능은 며칠 만에 잊히고, 알림은 대부분 꺼져 있고, 결제 단계에서 더 비싼 브랜드가 선택된다. 말이 틀렸고 행동이 맞다는 결론을 내리기엔 너무 단순하고, 반대로 행동이 우연이고 말이 진짜라는 쪽도 위험하다. 이 지점이 UX 리서치의 흥미로운 핵심이다. 말과 행동이 다르다는 사실 자체가 힌트고, 그 힌트를 증거로 바꾸는 과정이 바로 UX의 일이다.

UX/UI 디자이너에게 유저 리서치는 항상 딜레마를 준다. <출처: 작가, ChatGPT 제작>

약간의 도발성 표현이지만, 여기서 유저는 거짓말한다는 표현은 도덕적 비난과는 전혀 관련이 없다. 인간의 말은 늘 이상적인 자기 이미지와 사회적 기대를 섞어 만든 설명이고, 행동은 마찰과 환경에 반응한 결과다. 그래서 UX 리서치는 유저를 심판하는 일이 아니라, 말과 행동 사이의 간극을 구조적으로 해석하고, 계측과 실험으로 확인해 설계로 바꾸는 일이다. 이 글은 그 간극을 조금 더 테크니컬하게 다루는 방법을 정리한다.

왜 말과 행동은 어긋날까? 심리 + 시스템이 함께 만든다

다양한 심리적 요인이 말과 행동의 불일치를 만든다. <출처: 작가>

말과 행동의 불일치를 설명하는 심리적 요인은 이미 꽤 잘 알려져 있다. 첫째는 사회적 바람직성 편향이다. 사람은 좋은 사용자, 책임감 있는 사람처럼 보이고 싶어 한다. 그래서 알림이 필요하다고 말하지만 실제로는 알림이 귀찮고 피곤해서 꺼버린다. 둘째는 기억 오류다. 지난주에 썼던 것 같다고 말해도 로그에는 기록이 없다. 기억은 저장이 아니라 편집이고, 반복 행동일수록 더 쉽게 섞인다. 셋째는 자기 합리화다. 불편했는데도 괜찮았다고 말하는 경우가 있다. 인정하는 순간 내가 서툰 사용자처럼 보일까 봐, 혹은 내가 선택한 서비스를 깎아내리기 싫어서, 무의식적으로 설명을 예쁘게 만든다. 넷째는 미래 예측의 비현실성이다. 매일 쓸 것 같다는 말은 대부분 현재의 열정으로 미래의 시간을 과대평가한 결과다. 헬스장 등록이 늘 과잉 예약되는 것과 비슷하다.

하지만 여기서 한 번 더 나아가야 한다. 많은 불일치는 심리만이 아니라, 시스템이 만들어낸다. 알림이 중요하다는 사람이 알림을 안 켠다면, 그건 중요하지 않아서가 아니라 알림을 켜는 흐름이 부담스럽거나, 어떤 알림이 오는지 예측이 안 되거나, 해제와 조절이 불편하거나, 권한 요청 타이밍이 너무 이르거나, 알림 자체가 신뢰를 해치는 경험이었기 때문일 수 있다. 사용자는 의지로 움직이는 존재가 아니라 마찰과 기본값과 맥락에 반응하는 존재다. 그래서 유저의 말이 거짓이냐 진실이냐를 판단하기 전에, 제품이 어떤 행동을 쉽게 만들고 어떤 행동을 어렵게 만들었는지부터 확인해야 한다.

UX에서 자주 쓰는 행동과학 해석 도구: 말은 이상, 행동은 마찰의 결과다

여기서 말하는 해석 도구라는 건, 사용자의 발화나 로그를 볼 때 그냥 감으로 해석하지 않고, 어떤 원리로 보면 더 잘 설명되는지를 정해주는 일종의 관점이다. 같은 현상을 보더라도 어떤 관점으로 보느냐에 따라 원인이 달라지고, 원인이 달라지면 처방도 달라진다. 그래서 이 관점들은 디자이너 입장에서 문제를 더 빨리 분해하고, 더 정확하게 실험으로 연결하기 위한 도구로 쓰인다.

실무에서 말과 행동의 간극을 해석할 때 유용한 관점들이 있다. 이건 특정 교과서에 박힌 단일한 UX 원칙 세트라기보다, 인지심리학·행동경제학에서 검증된 개념을 UX에서 원칙처럼 활용하는 방식에 가깝다.

1) 최소 노력의 법칙

사용자는 가장 쉬운 경로로 흐른다. 의도와 결심보다 손이 덜 가는 선택이 이긴다. 예를 들어, 금융 앱에서 자동이체 등록 기능을 많이 원한다고 인터뷰에서 말했는데 실제 등록률이 낮다면, 그 기능이 필요 없어서가 아니라 등록 과정이 길어서일 수 있다. 계좌 선택, 인증, 약관 동의, 금액 입력, 시작일 선택이 한 화면에 몰려 있고, 중간에 인증이 끊기고, 다시 돌아오면 입력값이 날아가는 순간, 사용자는 말로는 필요하다고 해도 행동으로는 포기한다. 같은 기능이라도 시작 버튼을 홈에 두고, 기본값을 추천으로 채워주고, 다음에 이어하기를 제공하면 등록률이 튀는 경우가 있다. 이때 사용자는 갑자기 의지가 생긴 게 아니다. 덜 피곤해진 거다.

<출처: 작가>

2) 인지 부하 최소화

사용자는 화면을 읽고 판단하고 기억하고 비교하는 비용을 싫어한다. 알림을 예로 들면, 알림이 중요하다고 말한 사람이 실제로 알림을 꺼버리는 이유는 알림이 정보가 아니라 판단을 요구하는 업무처럼 느껴지기 때문이다. 입금 알림, 소비 리포트, 이벤트 혜택, 마케팅 소식이 뒤섞여 오고, 문구는 긴데 핵심이 안 보이고, 눌러도 어디로 가는지 예측이 안 되면, 알림은 계속 작은 판단을 요구한다. 결국 사용자는 알림을 꺼서 인지 부하를 줄인다. 그래서 알림을 살리려면 더 세게 보내는 게 아니라, 알림 자체를 더 단순하게 만들어야 한다. 어떤 알림인지, 왜 지금 왔는지, 누르면 뭐가 해결되는지, 그리고 조절은 어디서 하는지까지 한 번에 이해되게 하는 게 핵심이다.

<출처: 작가>

3) 기본값 효과

사람은 설정을 잘 바꾸지 않는다. 기본값은 제품이 사용자에게 강하게 주입하는 추천이다. 예를 들어, 뉴스레터 구독이나 푸시 알림이 기본값 켜짐으로 되어 있으면, 사용자는 적극적으로 동의해서 켠 게 아니라 그냥 흘러가다 보니 켜진다. 반대로 기본값이 꺼져 있고, 켤 기회를 한 번도 제대로 주지 않으면, 알림이 중요하다고 생각하는 사용자조차 그냥 계속 꺼진 상태로 남는다. 실무에서 자주 보는 패턴은, 알림을 켜게 만들고 싶어서 온보딩 첫 화면에 권한 요청을 띄우는데, 이때 사용자는 아직 이 앱이 나에게 어떤 가치를 주는지도 모르기 때문에 거절한다. 그리고 기본값은 그 거절 상태로 굳어버린다.

그래서 기본값 효과를 UX에서 제대로 쓰려면, 언제 기본값을 제안할지와 어떤 맥락에서 기본값이 납득되게 보일지를 같이 설계해야 한다. 가치를 경험한 직후, 그러니까 지금 이 기능을 계속 놓치지 않으려면 알림을 켜두는 게 좋겠다는 타이밍이 되었을 때 기본값 제안이 힘을 갖는다.

<출처: 작가>

4) 현재 편향과 지연된 보상

사람은 먼 미래의 이득보다 지금 당장의 귀찮음을 더 크게 느낀다. 매일 쓸 것 같다는 발화가 무너지는 이유는, 사용 가치가 늦게 도착할수록 현재의 마찰이 승리하기 때문이다. 예를 들어, 가계부 앱에서 사용자들이 예산 기능이 있으면 매일 쓸 것 같다고 말하지만 실제로는 며칠 만에 이탈하는 경우가 많다.

이유는 예산 기능이 나에게 도움이 되려면 먼저 카테고리를 설정하고, 월 예산을 입력하고, 결제 내역을 정리하고, 일주일 이상 써봐야 의미가 생기기 때문이다. 보상은 늦게 오는데, 입력은 지금 당장 해야 한다. 그래서 현재 편향이 작동하면 사용자는 단기 피로에 져서 떠난다. 이때 UX가 할 일은 사용자에게 더 성실해지라고 말하는 게 아니라, 첫 보상을 앞당기는 것이다. 예산을 직접 입력시키는 대신, 최근 지출을 기반으로 추천 예산을 만들어 주고, 오늘 한 번만 확인해도 바로 보이는 작은 인사이트를 주고, 입력을 미뤄도 괜찮게 만드는 흐름을 제공하면, 보상이 앞당겨지고 이탈이 줄어든다.

<출처: 작가>

5) 프레이밍과 손실회피

사람은 같은 사실이라도 표현 방식에 따라 다르게 판단하고, 이득보다 손실을 더 크게 느낀다. 쇼핑에서 가격이 중요하다고 말하면서도 더 비싼 브랜드를 선택하는 건 감성의 문제가 아니라, 실패할까 봐 두려워 손실을 피하려는 의사결정 구조일 수 있다. 예를 들어, 동일한 제품이라도 리뷰 수가 많고, 반품이 쉬워 보이고, 배송이 확실해 보이면 사용자는 더 비싼 선택을 한다. 그건 더 좋은 제품을 사고 싶어서라기보다, 잘못 사서 후회하고 시간과 돈을 잃는 상황을 피하고 싶어서다. 그래서 가격 비교 UX만 강화하면 해결되지 않는다.

오히려 손실회피가 강한 사용자에게는 환불 정책, 품질 보증, 실사용 후기, 비교 표 같은 정보가 결제 전 불안을 줄여준다. 여기서 프레이밍은 문구만의 문제가 아니다. 같은 정책이라도 무료 반품이라고 보여주는 것과 7일 이내 반품 가능이라고 보여주는 것은 사용자에게 전혀 다른 안정감을 준다. 사용자는 이득보다 손실을 먼저 본다. 그래서 결제 단계에서는 싸게 사세요보다 망할 확률을 줄여드릴게요가 더 강력하게 작동할 때가 많다.

이 관점들은 공통적으로 한 가지를 말한다. 사용자의 말은 사용자가 되고 싶은 이상을 담고, 사용자의 행동은 마찰과 위험과 기본값에 반응한 결과를 담는다. 그래서 UX 리서치의 목표는 유저의 발화를 믿거나 무시하는 게 아니라, 발화를 가설로 만들고 행동으로 검증하는 구조를 설계하는 데 있다.

<출처: 작가>

말과 행동을 연결하는 테크니컬 루틴: 가설화 → 계측 → 교차검증 → 실험

말과 행동이 다르다는 걸 안다고 해서 제품이 좋아지진 않는다. 실무에서 중요한 건 그 간극을 반복 가능하게 다루는 루틴이다. 이 루틴은 리서치라기보다 분석 설계와 실험 설계에 가깝다.

첫 단계는 발화를 가설 문장으로 번역하는 것이다.

<출처: 작가>

사용자의 말 자체는 요구사항이 아니라 의견이고, UX에서 의견은 검증 전까지는 가설이다. 예를 들면, 알림이 필요하다는 발화는 이렇게 바꿀 수 있다. 특정 이벤트가 발생했을 때 알림을 받으면 사용자는 더 빠르게 재방문하거나, 실수를 줄이거나, 중요한 행동을 완료할 확률이 높아질 수 있다. 여기서 핵심은 알림이라는 기능명이 아니라 이벤트, 맥락, 대상, 기대 효과를 넣는 것이다. 그래야 검증할 수 있다.

둘째 단계는 계측이다.

<출처: 작가>

행동 데이터는 자연 발생하지 않는다. 이벤트가 정의돼 있지 않으면 관찰할 수도 없다. 최소한 기능의 채택과 유지와 성과를 측정할 이벤트가 필요하다. 알림이라면 알림 켬/끔, 어떤 알림 유형을 선택했는지, 알림을 받은 뒤 어떤 화면으로 유입됐는지, 알림을 끄기까지 걸린 시간 같은 속성이 붙어야 한다. 검색이라면 검색 실행, 검색 결과 클릭, 결과 없음, 검색 후 구매/저장 같은 후속 행동이 이어져야 한다. 즐겨찾기라면 저장, 저장 목록 재방문, 저장 삭제가 이어져야 한다. 이 정도가 되어야 말과 행동을 같은 좌표 위에 올려놓을 수 있다.

셋째 단계는 교차검증이다.

<출처: 작가>

여기서 실무자가 자주 실수하는 지점이 하나 있다. 기능 사용률 하나만 보고 결론을 내리는 것이다. 하지만 말과 행동 불일치는 보통 한 지표로 설명되지 않는다. 그래서 채택률, 습관화, 임팩트로 분해해서 봐야 한다. 채택률은 한 번이라도 켰거나 써본 비율이고, 습관화는 반복 사용하거나 유지한 비율이고, 임팩트는 실제 목표 지표에 영향을 줬는지다. 알림을 켠 사람은 적지만 켠 사람의 유지율과 재방문이 높다면, 알림이 필요 없는 게 아니라 알림을 켜게 만드는 UX가 실패한 것이다. 반대로 채택은 높지만 해제도 빠르고 불만도 많다면, 알림 콘텐츠 품질과 빈도, 통제권 설계가 실패한 것이다. 같은 현상이라도 처방이 완전히 달라진다.

넷째 단계는 실험이다.

<출처: 작가>

관찰은 상관관계를 보여주고, 인터뷰는 해석을 제공한다. 인과가 필요하면 실험이 가장 빠르다. 실험은 꼭 거창할 필요가 없다. 권한 요청 타이밍을 첫 가치 경험 이후로 미루기, 기본값을 바꾸기, 알림 빈도 선택을 제공하기, 알림 유형을 좁히기 같은 작은 변화로도 충분하다. 중요한 건 무엇이 가치이고 무엇이 마찰인지 가설을 분리해 실험으로 확인하는 것이다. UX는 결국 기능을 늘리는 일이 아니라, 행동이 일어나는 조건을 설계하는 일이다.

사례를 다시 읽는 방식: 말이 아니라 구조를 본다

<출처: 작가>

사용자가 추천이 지겹다고 말하면서 익숙한 영상을 반복 클릭하는 사례는 흔하다. 이건 사용자가 모순적이라서라기보다 탐색과 안정 사이의 균형 문제다. 새로운 걸 보고 싶다는 말은 욕망이고, 실패 비용을 피하려는 행동은 손실 회피다. 그래서 추천 UX에서 중요한 건 새로움을 강요하는 게 아니라, 안전하게 탐색할 수 있게 만드는 장치다. 예를 들면, 새로움의 강도를 조절하거나, 익숙한 것과 새로운 것을 적절히 섞어 주거나, 새로움을 선택 가능한 옵션으로 제공하는 방식이 된다.

알림 사례도 마찬가지다. 알림이 필요하다는 응답이 높고 실제 설정은 낮다면, 이건 태도의 문제가 아니라 기본값과 마찰의 문제일 가능성이 크다. 어떤 알림이 오는지 불명확하면 사용자는 신뢰를 잃고, 통제권이 없으면 피로를 느끼고, 권한 요청이 너무 이르면 아직 가치도 모르는 데 부담만 느낀다. 알림은 기능이라기보다 관계 설계에 가깝다. 무엇을 언제 어떤 톤으로 어느 빈도로 보낼지, 그리고 사용자가 언제든 쉽게 조절할 수 있게 할지의 문제다.

검색이 편하다고 말하면서도 실제로는 즐겨찾기를 더 쓰는 패턴도 자주 나온다. 이때 검색이 나쁘다는 결론은 위험하다. 검색은 탐색이고, 즐겨찾기는 반복 사용을 위한 캐시다. 사람은 매번 질문하는 것보다 한 번 저장하고 다시 쓰는 걸 좋아한다. 그래서 UX는 검색을 더 빠르게 만드는 것만이 아니라 저장과 재방문을 자연스럽게 연결하는 흐름을 설계해야 한다. 말은 검색이 편하다고 하지만, 행동은 반복을 더 선호한다는 사실을 보여준다.

쇼핑에서 가격이 중요하다고 말하면서도 더 비싼 브랜드를 선택하는 건 합리 vs 감성 싸움이 아니다. 불확실성을 줄이는 신호가 더 강하게 작동한 결과일 수 있다. 리뷰 평점, 후기 사진, 브랜드 신뢰도, 반품 정책, 배송 안정성은 손실을 줄여주는 정보다. 그래서 가격 중심 UX로만 몰고 가면, 오히려 결제 단계에서 사용자의 진짜 불안을 놓치게 된다. 이 영역에서 UX가 해야 하는 일은 가격을 설득하는 게 아니라 실패할까 봐 두려운 마음을 줄이는 것이다.

사용자는 거짓말을 한다, 그래서 UX는 더 정교해질 수 있다

<출처: 작가>

사용자는 거짓말한다. 하지만 그건 악의가 아니라 인간의 기본값에 가깝다. 사람은 이상적인 자신을 말로 만들고, 현실의 자신을 행동으로 만든다. 그래서 리서치에서 중요한 건 유저가 틀렸다고 선언하는 게 아니라, 말과 행동 사이의 간극을 전제로 설계를 시작하는 것이다. 발화는 단서이고, 행동은 증거다. 단서를 가설로 만들고, 계측으로 관찰하고, 교차검증으로 해석하고, 실험으로 인과를 확인하는 과정이 쌓이면, 유저의 말은 더 이상 위험한 소음이 아니라 제품을 정교하게 만드는 힌트가 된다.

UX 리서치는 탐정의 일과 닮아 있다. 증언만 믿지 않고, CCTV만 맹신하지도 않는다. 증언과 CCTV를 같은 사건의 다른 시점으로 보고, 그 사이의 간극을 메우는 방식으로 진실에 가까워진다. 유저는 거짓말한다는 사실을 인정하는 순간, 디자이너는 유저와 싸우는 사람이 아니라, 인간의 본성을 전제로 더 안전하고 덜 피곤한 행동 경로를 만드는 사람이 된다. 그게 결국 더 좋은 디자인으로 가는 가장 현실적인 길이다.

]]>

Codex 서브에이전트 136개 모음집: awesome-codex-subagents

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: awesome-codex-subagents - Codex 서브에이전트 136개 모음집
참고할 것: Google Stitch - 구글이 새로 꺼낸 AI 디자인 캔버스, 바이브 디자인
적용해볼 것: Anthropic이 내부에서 쌓은 Claude Code 스킬 운용법

<출처: 깃허브 VoltAgent/awesome-codex-subagents>

1. 써볼 것: awesome-codex-subagents - Codex 서브에이전트 136개 모음집

awesome-codex-subagents는 VoltAgent가 GitHub에 공개한 Codex용 서브에이전트 모음입니다. 백엔드·프론트엔드 개발, 언어별 전문가, 인프라, 보안, 데이터·AI, 비즈니스·프로덕트 등 10개 카테고리에 걸쳐 136개 서브에이전트가 담겨 있습니다. MIT 라이선스로 공개되어 있고, Codex 공식 문서에 맞게 작성된 .toml 포맷을 씁니다.

Codex에 서브에이전트 기능이 3월 16일 정식 출시되면서 바로 주목받았습니다. Simon Willison은 서브에이전트 패턴이 이제 코딩 에이전트의 표준이 되고 있다고 언급했고, Codex 사용자들 사이에서 직접 서브에이전트를 구성하는 방법에 대한 관심이 빠르게 높아졌습니다.

무슨 문제를 해결해 주나요?

Codex 하나에 모든 걸 맡기면 컨텍스트가 섞입니다. 코드 리뷰를 시키면서 동시에 문서화를 시키고, 버그 디버깅까지 요청하면 각 작업에서 집중도가 떨어지고 결과물이 흐릿해지죠. 서브에이전트는 이 문제를 분업으로 해결합니다. 생각해보면 사람도 똑같죠. 한 사람한테 기획, 개발, QA를 동시에 맡기면 결과물이 흐릿해집니다. 에이전트도 다르지 않은 것 같습니다.

각 에이전트가 독립된 컨텍스트 창에서 자신의 역할에만 집중하기 때문에 출력의 집중도와 일관성이 높아집니다. 서브에이전트는 직접 만들 수도 있습니다. 필요한 것만 골라서 설계하면 되고요. 다만 처음 시작할 때 어떤 구조로 만들어야 할지, 어떤 역할을 분리해야 할지 막막한 경우가 많습니다. awesome-codex-subagents는 그 시작점을 낮춰줍니다. 실제 개발 워크플로에 맞게 만들어진 에이전트를 레퍼런스로 참고하거나, 바로 가져다 붙일 수 있습니다.

어떻게 쓰나요?

레포지토리를 클론한 뒤 원하는 .toml 파일을 에이전트 디렉토리에 복사하면 됩니다.

# 전체 프로젝트에서 쓰려면
mkdir -p ~/.codex/agents
cp categories/04-quality-security/reviewer.toml ~/.codex/agents/

# 특정 프로젝트에서만 쓰려면
mkdir -p .codex/agents
cp categories/01-core-development/backend-developer.toml .codex/agents/
```

설치 후 Codex에서 명시적으로 호출해야 합니다. Codex는 서브에이전트를 자동으로 띄우지 않고, 직접 지정해야 작동합니다.
```
이 브랜치를 병렬로 검토해줘. reviewer가 정확성과 보안을 확인하고, docs_researcher가 이 패치가 의존하는 프레임워크 API를 검증하게 해줘. 둘 다 끝나면 결과를 요약해줘.

각 서브에이전트는 역할에 따라 모델이 지정되어 있습니다. 보안 감사나 아키텍처 리뷰처럼 깊은 추론이 필요한 에이전트는 gpt-5.4가, 빠른 탐색이나 문서 조회는 gpt-5.3-codex-spark나 gpt-5.4-mini가 배정되는 식입니다. 물론 .toml 파일에서 직접 바꿀 수 있습니다.

누구에게 좋을까요?

Codex를 쓰고 있는데 반복 작업마다 프롬프트를 새로 짜는 게 번거로운 개발자
코드 리뷰, 디버깅, 문서화를 각각 다른 에이전트에 위임하는 분업 구조를 만들고 싶은 팀
서브에이전트를 처음 써보는데 어디서 시작해야 할지 모르는 사람

Codex를 쓰지 않는다면 해당 없습니다. Claude Code 사용자라면 같은 VoltAgent가 운영하는 awesome-claude-code-subagents가 따로 있습니다.

<출처: .google blog>

2. 참고할 것: Google Stitch - 구글이 새로 꺼낸 AI 디자인 캔버스, 바이브 디자인

Google Stitch는 Google Labs가 운영하는 AI 기반 UI 디자인 도구입니다. 3월 18일 대규모 업데이트를 발표하면서 단순한 UI 생성기에서 AI 네이티브 소프트웨어 디자인 캔버스로 전면 재구성됐습니다. 이번 업데이트의 핵심 개념은 바이브 디자인(vibe design)으로, 와이어프레임 없이 비즈니스 목표나 사용자 경험을 자연어로 설명하면 디자인이 생성됩니다. 월 350회까지 무료로 쓸 수 있습니다.

입력: 알록달록 귀여운 스타일에 IT 뉴스를 모아볼 수 있는 앱
사람들이 댓글을 달고 뉴스에 대해 의견 토론할 수 있는 구조

아이디어를 입력창 위에서 먼저 제안해주고, 한국어로 명령해도 잘 알아듣습니다.

입력: 댓글 작성 시 사용할 수 있는 귀여운 이모티콘 팩 추가해줘 / 이모티콘 종류를 더 다양하게 늘려줘

기존 디자인 도구와 무엇이 다른가요?

기존 디자인 프로세스는 보통 와이어프레임으로 시작합니다. 구조를 잡고, 컴포넌트를 배치하고, 색상과 폰트를 고르는 순서죠. Stitch는 이 순서를 뒤집었습니다. 달성하려는 비즈니스 목표, 사용자에게 전달할 감정, 영감을 주는 레퍼런스를 먼저 설명하면 에이전트가 디자인을 만들어냅니다. 수십 가지 방향을 빠르게 탐색한 다음 마음에 드는 걸 골라 다듬는 방식입니다. Figma처럼 직접 조작하는 도구가 아니라, 에이전트와 대화하면서 디자인을 발전시키는 구조입니다.

어떻게 작동하나요?

무한 캔버스 위에 이미지, 텍스트, 코드 등 형태에 관계없이 컨텍스트를 올려놓을 수 있습니다. 디자인 에이전트가 이 컨텍스트를 바탕으로 프로젝트 전체 흐름을 추론합니다. 여러 방향을 동시에 탐색하고 싶다면 Agent Manager를 쓰면 되고, 병렬로 아이디어를 진행하면서 각각을 추적할 수 있습니다.

정적 디자인을 인터랙티브 프로토타입으로 즉시 변환하는 것도 됩니다. 화면들을 연결하고 Play 버튼을 누르면 앱 플로우를 바로 체험할 수 있고, 클릭에 기반해 다음 화면을 자동으로 생성합니다.

음성으로 캔버스에 직접 말하는 기능도 추가됐습니다. 메뉴 옵션 3가지 보여줘, 이 화면을 다른 컬러 팔레트로 보여줘 같은 요청을 실시간으로 처리합니다. 솔직히 이 부분은 아직 얼마나 실용적일지 잘 모르겠습니다. (제가 아직 음성 입력보다, 텍스트 입력이 더 익숙한 사람이라 그런 것 같습니다) 다만 손을 키보드에서 떼지 않고 디자인을 수정하는 그림 자체는 꽤 매력적으로 느껴졌습니다.

무엇을 얻어가야 하나요?

일부에서는 Stitch가 Figma 킬러가 될 거라고 합니다. 구글이 Gemini 모델을 등에 업고 디자인 툴 시장에 본격적으로 들어온 거라는 시각이죠.

개인적으로는 조금 다르게 봅니다. Figma는 완성된 디자인을 정교하게 다듬는 도구고, Stitch는 아이디어 탐색 단계에서 방향을 빠르게 잡는 도구에 더 가깝지 않을까요. 실제로 Figma 내보내기를 지원하기 때문에 둘을 연결해서 쓰는 워크플로가 더 자연스러울 것 같고요. Figma를 대체하기보다는 그 앞 단계를 채우는 쪽에 가깝다는 생각입니다.

더 흥미로운 건 DESIGN.md입니다. 디자인 규칙을 에이전트 친화적인 마크다운으로 내보내고 가져오는 이 포맷은, CLAUDE.md가 코딩 에이전트에 컨텍스트를 구조화하는 것과 같은 방향입니다. 디자인 레이어에서도 컨텍스트를 구조화하는 흐름이 시작됐다는 게 저는 더 주목하게 됩니다.

MCP 서버와 SDK도 공개되어 있어서 Stitch 기능을 다른 도구와 연결하거나 개발 워크플로에 붙이는 것도 가능합니다. 18세 이상, Gemini 지원 국가에서 영어로만 현재 이용 가능합니다.

<출처: X (Thariq)>

3. 적용해볼 것: Anthropic이 내부에서 쌓은 Claude Code 스킬 운용법

Thariq는 Claude Code를 만든 Anthropic 팀의 개발자입니다. 최근 X에 Anthropic 내부에서 수백 개의 스킬을 운용하면서 쌓은 노하우를 공개했습니다. 조회수 552만, 좋아요 1.4만을 기록했습니다. 흥미로운 건 새로운 기능을 소개하는 게 아니라는 점입니다. 스킬을 어떻게 분류하고, 어떻게 잘 만들고, 어떻게 팀에 퍼뜨리는지, 실제로 써보면서 생긴 판단 기준을 공유했습니다.

무슨 문제를 해결하려 하나요?

스킬은 유연하고 만들기 쉬운 만큼, 잘못 만들기도 쉽습니다. 중복되거나 지나치게 구체적이거나 설명이 빈약한 스킬은 에이전트가 제대로 활용하지 못합니다. Anthropic 내부에서도 이 문제를 겪었고, 수백 개를 운용하면서 어떤 스킬이 실제로 작동하는지 패턴이 생겼습니다.

어떻게 운용하나요?

스킬 유형 9가지

Thariq가 분류한 스킬 유형입니다. 내 조직에서 어떤 스킬이 빠져 있는지 점검하는 기준으로 쓸 수 있습니다.

라이브러리·API 레퍼런스: 내부 라이브러리나 Claude가 실수하는 외부 라이브러리를 올바르게 쓰는 법. 레퍼런스 코드와 주의사항 목록 포함
제품 검증: 코드가 실제로 잘 동작하는지 테스트하는 방법. Playwright나 tmux 같은 외부 도구와 연결. 검증 스킬 하나를 잘 만드는 데 엔지니어 일주일을 쓸 가치가 있다고 했습니다. 처음엔 과하다 싶었는데, 생각해보면 맞는 말입니다. AI가 코드를 빠르게 만들수록 그게 실제로 잘 동작하는지 확인하는 과정이 병목이 되니까요.
데이터 패칭·분석: 데이터와 모니터링 스택에 연결. 자격증명, 대시보드 ID, 공통 워크플로 포함
비즈니스 프로세스·팀 자동화: 반복 워크플로를 명령 하나로. 이전 실행 결과를 로그 파일에 저장하면 다음 실행에서 일관성이 높아집니다
코드 스캐폴딩·템플릿: 프레임워크 보일러플레이트 생성. 순수 코드로 표현하기 어려운 자연어 요구사항이 있을 때 특히 유용
코드 품질·리뷰: 조직 내 코드 품질 기준 적용. Hook이나 GitHub Action으로 자동 실행 가능
CI/CD·배포: 코드 패치·배포 자동화. 다른 스킬을 참조해서 데이터 수집까지 연결
런북: 증상(Slack 스레드, 알림, 에러 시그니처)을 받아 멀티툴로 조사하고 구조화된 보고서 생성
인프라 운영: 루틴 유지보수와 운영 절차. 파괴적 작업에 가드레일을 붙이는 게 핵심

스킬을 잘 만드는 팁

당연한 내용은 쓰지 마세요. Claude는 이미 코드베이스를 많이 알고 있습니다. 스킬에는 Claude가 기본적으로 생각하지 않는 방향으로 밀어내는 정보만 담아야 합니다. Anthropic 내부의 frontend-design 스킬은 Inter 폰트나 보라색 그라디언트 같은 AI가 자주 쓰는 기본 패턴을 피하도록 만들어졌습니다.
Gotchas 섹션을 만드세요. 스킬에서 신호 대비 밀도가 가장 높은 부분입니다. Claude가 실제로 실수한 지점을 모아서 계속 업데이트하는 게 좋습니다.
스킬은 파일 하나가 아닌 폴더입니다. 마크다운 파일 하나로 끝내지 말고, references/api.md로 상세 함수 시그니처를 분리하거나, assets/에 결과물 템플릿을 넣거나, 스크립트 폴더를 포함하세요. Claude가 필요할 때 읽을 파일을 미리 알려주면 컨텍스트를 효율적으로 씁니다.
description 필드는 사람이 아닌 모델을 위해 씁니다. Claude Code가 세션 시작 시 모든 스킬 목록을 보고 이 요청에 맞는 스킬이 있는지 판단합니다. description은 언제 이 스킬을 쓸지를 모델이 이해할 수 있게 써야 합니다.
Claude를 너무 좁게 가두지 마세요. 스킬은 재사용되기 때문에 지나치게 구체적으로 지시하면 상황에 맞게 적응하지 못합니다. 필요한 정보를 주되 판단의 여지를 남기세요.

팀에 스킬 배포하기

소규모 팀이라면 레포지토리 .claude/skills에 체크인하는 게 간단합니다. 팀 규모가 커지면 내부 플러그인 마켓플레이스를 만드는 게 효과적입니다. Anthropic은 중앙에서 관리하지 않고, 유용한 스킬을 만든 사람이 GitHub 샌드박스 폴더에 올리고 Slack으로 공유하는 방식으로 스킬이 퍼집니다. 충분히 쓰이면 마켓플레이스 PR을 올립니다.

적용을 위해 실행해볼 수 있는 것

지금 Claude Code나 Codex를 쓰고 있다면, 가장 자주 반복하는 작업 하나를 골라서 스킬로 만들어보세요. 처음부터 완벽하게 만들려 하지 말고, 몇 줄과 Gotchas 하나로 시작하는 게 좋습니다. 대부분의 좋은 스킬은 그렇게 시작했다고 Thariq는 말합니다.
이미 스킬을 쓰고 있다면 description 필드를 다시 읽어보세요. 사람이 이해하는 설명인지, 아니면 모델이 언제 이걸 써야 할지 판단할 수 있는 설명인지 다르게 느껴질 겁니다.
팀 단위라면 가장 많이 쓰이는 스킬 세 개를 골라 Gotchas 섹션을 업데이트해보세요. 실제 실패 사례가 쌓일수록 스킬의 신호 밀도가 높아집니다.

정리

세 소재가 각각 다른 레이어를 건드립니다. Stitch는 디자인 레이어에서 아이디어를 자연어로 탐색하는 방법을 바꾸고 있고, awesome-codex-subagents와 Claude Code 스킬은 실행 레이어에서 에이전트를 어떻게 구조화하느냐를 다룹니다.

공통점이라면 셋 다 범용 AI 하나에 모든 걸 맡기는 방식은 아니라는 거죠. Stitch는 DESIGN.md로 디자인 컨텍스트를 구조화하고, 서브에이전트는 작업별로 독립된 컨텍스트를 분리하고, Claude Code 스킬은 조직의 노하우를 에이전트가 쓸 수 있는 형태로 압축합니다. AI를 잘 쓰는 것과 AI에게 구조를 주는 것은 다른 이야기입니다.

이렇게 적용해보세요

Codex를 쓰고 있다면 awesome-codex-subagents에서 지금 가장 자주 하는 작업 카테고리 하나를 골라 에이전트 두세 개를 설치해보세요. 병렬로 돌리기 전에 각 에이전트가 단독으로 어떻게 동작하는지 먼저 확인하는 게 좋습니다.
Claude Code 스킬을 만들고 있다면 description 필드를 먼저 다시 써보세요. 스킬 자체보다 모델이 언제 이 스킬을 써야 하는지 판단하는 기준이 더 중요합니다.
Stitch를 써볼 생각이라면 와이어프레임부터 시작하기보단, 달성하려는 목표와 사용자에게 전달하고 싶은 느낌을 먼저 써보세요.

이번 주 세 소재를 정리하면서 든 생각은, AI에게 구조를 주는 사람과 그냥 쓰는 사람 사이의 격차가 생각보다 빠르게 벌어지고 있는 것 같다입니다. 여러분은 어떻게 느끼시나요?

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

요즘IT 독자 선정 국내 1등 협업툴은 무엇이 다른가

*이 글은 토스랩과 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

협업툴은 하나쯤 쓰고 있지만, 딱 맞는 건 아직 못 찾았다는 사람이 많습니다. 슬랙은 좋은데 비싸고, 팀즈는 회사가 깔아줬는데 무겁고, 카톡은 편한데 일이 묻히고.

요즘은 여기에 한 가지 질문이 더 붙습니다. AI가 웬만한 기능을 다 해주는 시대에, 굳이 돈 내고 쓰는 툴이 필요한가? 올해 초 '사스포칼립스(SaaSpocalypse)'라는 말이 나올 만큼 SaaS 시장이 흔들렸고, AI 에이전트가 범용 도구를 대체할 수 있다면 시트비를 낼 이유가 사라진다는 논리가 힘을 얻고 있죠.

하지만 현실은 조금 다릅니다. 사라지는 건 기능 하나만 제공하는 얕은 도구이고, 조직의 업무 흐름을 깊이 감싸는 도구는 오히려 AI와 결합해 더 강해지고 있습니다.조직도와 권한 체계, 사내 데이터 보안, 부서마다 다른 업무 흐름 등 이런 맥락은 범용 AI를 갖다 쓰는 것만으로 해결되지 않으니까요.

얼마 전 요즘IT에서 10년 넘은 메신저형 협업툴 5개의 AI 기능을 비교했는데, 그때 프로덕트 밸리 평점을 들여다보다 눈에 띄는 숫자가 있었습니다. 국내 메신저형 협업툴 중 평점 1위, 4.35점(5점 만점). 잔디(JANDI)였습니다. 10년간 42만 개가 넘는 팀의 활용 사례를 쌓아오면서, 한국 시장에서 가성비 좋고 신뢰받는 툴로 자리잡은 프로덕트입니다.

리뷰 수는 17건으로 많지 않지만, 하나씩 읽어보니 점수 뒤에 꽤 구체적인 이야기들이 있었습니다. 어떤 점이 좋고, 어떤 점이 아쉬운지. 그리고 이 툴을 9년, 10년째 쓰고 있는 팀들은 대체 왜 안 떠나는지. AI 시대에 기업의 워크플로를 깊이 감싸며 살아남은 도구를 들여다보는 건, 그 자체로 의미가 있겠다 싶었습니다. 그래서 잔디 팀과 함께 잔디가 실제 현장에서 어떻게 사용되고 있는지 자세히 살펴봄으로써 AI 시대 협업툴이 진화하는 방법을 들여다보기로 했습니다.

이 글에서는 실제 사용자들이 남긴 프로덕트 밸리 리뷰를 통해 장점과 단점을 분석하고, 업종과 규모가 다른 기업의 실제 사용 사례를 통해 현장의 활용법을 살펴봅니다. 최근 빠르게 업데이트되고 있는 AI 기능까지 포함해, 잔디가 좋은 평을 받고 있는 이유와 함께 AI 시대에 국내 협업툴이 어떻게 진화하고 있는지를 정리해봤습니다.

잔디의 장점과 단점: 국내 환경 ‘가성비’ 최고, 속도와 검색 UX 개선 필요

협업툴 잔디는 전반적으로 만족도가 높은 편입니다. 리뷰에서 가장 많이 언급된 장점은 역시 '국내 환경 최적화'입니다. 조직도 연동, DRM 문서 미리보기, HWP 파일 지원처럼 한국 기업 실무에서 실제로 필요한 기능들이 잘 갖춰져 있다는 거죠. 슬랙 같은 해외 툴에서는 기대하기 어려운 부분인데, 잔디는 이걸 기본으로 제공합니다. "한국 사람이 쓰기 가장 좋은 툴"이라는 리뷰가 나올 만합니다.

리뷰 항목 중 눈에 띄는 건 가성비 점수입니다. 잔디의 가성비 평점은 4.44점으로 다른 협업툴 대비 눈에 띄게 높았습니다. 협업툴은 팀 전체가 매일 쓰는 도구인 만큼 인당 요금이 곧 고정비가 되는데, 비용 대비 기능 만족도가 높다는 건 도입을 검토하는 입장에서 꽤 의미 있는 시그널입니다. 특히 중소기업이나 스타트업처럼 인원 대비 예산이 빠듯한 팀에게는, 슬랙 수준의 기능을 더 합리적인 가격에 쓸 수 있다는 점이 잔디를 선택하는 결정적 이유가 되기도 합니다.

사용성도 좋은 평가를 받았습니다. UI가 직관적이고 깔끔해서 비개발자도 금방 적응할 수 있다는 반응이 많았고, 업무 이모티콘, 메시지 읽음 확인, 자동 번역 같은 실무 편의 기능도 호평 요소였습니다. 소통과 업무 관리가 한 곳에서 되는 올인원 구조 덕분에 툴을 왔다 갔다 할 필요가 줄었다는 의견도 있었고요.

잔디 프로덕트 밸리 리뷰 평점(2026년 3월 18일 기준) <출처:요즘IT 프로덕트밸리>

리뷰에서 다수 언급된 생성형 AI 기능도 눈에 띕니다. 대화 히스토리 요약이나 AI로 코드 생성에 도움을 받는 것이 실무에 꽤 쓸 만하다는 반응이었고, GitHub·Google 캘린더 연동까지 갖추고 있어 단순 메신저를 넘어선 협업 허브로 자리잡고 있다는 평가입니다.

단점도 있습니다. 가장 자주 나온 건 모바일 속도 문제로, "약간 느린 느낌", "앱 업데이트가 잦다"는 의견이 있었습니다. 검색할 때 특정 채팅방이 아닌 전체 검색으로 잡히는 점도 반복적으로 지적됐는데, 과거 대화를 자주 찾는 사람에게는 신경 쓰일 수 있는 부분입니다. 간헐적 장애를 언급한 리뷰도 있었지만, "빠르게 대응해줘서 불안하진 않았다"는 후기가 함께 달렸고, 단점란에 "딱히 없다"고 적은 리뷰도 여러 건이었습니다.

전체적으로 툴 선택을 다시 고민하게 만들 정도의 강한 불만은 아닌 셈이죠. 4.35점이라는 높은 평점이 이를 뒷받침하고 있습니다. 그리고 이 탄탄한 기본기 위에 잔디가 최근 가장 공을 들이고 있는 것이 AI입니다.

잔디의 AI 기능: 대화 흐름 그대로 AI 활용

잔디는 '스프링클러'라는 이름의 AI를 협업툴 안에 내장하고 있습니다. 스프링클러는 단순한 챗봇 수준이 아니라 실제 업무 맥락을 이해하는 방향으로 빠르게 진화하고 있습니다.

요즘 AI 시대의 업무 도구들은 하나의 공통된 방향으로 움직이고 있습니다. 채팅 UI를 통해 다양한 업무를 처리하는 것. 별도 메뉴를 찾아 들어가는 대신, 대화하듯 명령하고 결과를 받는 방식이 자연스러워지고 있죠. 잔디도 이 흐름 위에 있습니다. 스프링클러는 채팅 창 안에서 질문하고, 파일을 분석하고, 사내 지식을 조회하고, 외부 서비스 데이터를 가져오는 것까지 하나의 입력창에서 처리하는 구조로 설계되어 있습니다.

잔디홈 사용 화면 <출처: 잔디>

시작점은 잔디홈입니다. 잔디에 접속하면 가장 먼저 만나는 메인 화면인데, 여기서 안 읽은 메시지 요약, 할 일, 일정, 프로젝트 현황을 한눈에 확인할 수 있고, AI 입력창도 이곳에 있습니다. 별도 앱을 열 필요 없이 업무를 시작하는 그 자리에서 바로 AI를 쓸 수 있는 구조죠.

이 AI 입력창을 통해 접근하는 주요 기능은 크게 네 가지입니다.

첫째, 일반적인 질문에 답하고 콘텐츠를 생성하는생성형 AI.
둘째, 파일을 올리면 핵심 내용을 요약하고 데이터를 추출해주는 파일 분석.
셋째, 우리 회사 내부 자료를 업로드해두면 그 문서를 기반으로 답변하는 지식베이스.
넷째, 이메일·캘린더 같은 외부 서비스 정보를 끌어오는 MCP 연동.여기에 대화방 안에서 오간 논의를 기간별로 정리해주는 토픽 요약 기능도 있습니다.

가장 최근 업데이트된 멀티모달 기능은 이 도구들을 한 단계 더 통합합니다. 파일 최대 3개와 실제 대화방 맥락을 동시에 읽고 답변을 만들어주는 등 2개 이상의 기능을 동시에 사용할 수 있는데요. 기획안 파일을 넣으면서 "지금 팀 대화 흐름 기준으로 수정할 부분이 뭐야?"라고 물을 수 있고, 여러 참고 자료를 한꺼번에 올려 "우리 상황에 맞게 핵심만 정리해줘"라고 요청할 수도 있습니다. 자료와 맥락이 분리되어 있던 기존 AI와 달리, 우리 팀이 실제로 나눈 대화 위에서 판단을 도와주는 셈이죠.

핵심은 이 기능들이 협업툴 안에 들어 있다는 점입니다. 별도 AI 도구로 옮겨가는 단계 없이, 대화하던 흐름 그대로 AI를 끼워 쓸 수 있는 구조. 이러한 기능은 사실 실제 현장에서의 활용 방식이 중요한데, 그 이야기를 들어봤습니다.

실제로 쓰는 팀의 이야기: 제조업 AX부터 10년 쓴 IT 기업까지

요즘IT 리뷰에서 반복적으로 등장한 키워드는 '국내 최적화', '직관적 UI', 'AI 활용도'였습니다. 그렇다면 실제로 잔디를 도입한 기업들은 어떤 지점에서 만족감을 느끼고 있을까요? 업종과 규모가 다른 대표 고객사례를 통해 확인해봤습니다.제조업의 디지털 전환이 궁금하다면 코아스, 대규모 조직의 내부 지식 관리가 고민이라면 무역협회, 소규모 팀의 업무 자동화를 찾고 있다면 빛나는 한의원 사례가 참고가 될 수 있습니다.

41년차 제조기업이 AI로 일하는 법: 효율적인 영업 관리

사무용 시스템 가구 기업 코아스

사무용 시스템 가구를 국내 최초로 도입한 코아스는 41년 업력의 전통 제조기업입니다. CES 2026에 AI 융합 가구를 출품할 만큼 기술 전환에 적극적인 기업이지만, 내부 소통은 오랫동안 카카오톡과 메일에 의존해왔죠. 프로젝트 범위가 넓어지면서 체계적인 협업 환경이 필요해졌고, 잔디를 도입했습니다.

영업 수주 리포트를 템플릿화해 AI로 수주를 분석하는 제조 기업의 사례 <출처: 잔디>

코아스가 가장 먼저 한 건 AI 도입이 아니라 토픽 구조화였습니다. 현재 20개 이상의 토픽을 프로젝트와 TF 단위로 운영하고 있고, 대표부터 신입사원까지 전 구성원이 참여합니다. 회의 중 나온 이슈는 즉시 할 일로 배정되고, 누가 확인했는지 직관적으로 파악할 수 있어 부서 간 의사결정 속도가 눈에 띄게 빨라졌다고 합니다. 과거에는 개인 PC, 공유 폴더, 카톡 대화방에 흩어져 있던 프로젝트 자료도 잔디 드라이브로 아카이빙하면서 업무의 연속성이 생겼죠.

이 기반 위에 AI가 올라탔습니다. 영업팀은 수주 성공·실패 사례를 일정한 템플릿으로 토픽에 기록하는데, 프로젝트 기본 정보, 특이사항, 성공 요인을 정해진 포맷으로 남기면 나중에 "최근 3개월간 직접 영업으로 성사된 프로젝트의 공통 요인은?" 같은 구체적인 질문을 AI에게 던졌을 때 포괄적인 답변이 아닌 근거 있는 분석을 받을 수 있습니다. 데이터가 쌓일수록 AI의 답변 품질이 올라가는 구조를 의도적으로 설계한 셈이죠.

대규모 조직의 효율적 지식관리

한국무역협회

한국무역협회는 잔디 AI 중에서도 지식베이스기능을 가장 적극적으로 활용하는 사례입니다. 일반적인 AI 서비스에 "무역협회 규정을 알려줘"라고 물으면 답변을 받을 수 없습니다. 내부 정보이기 때문이죠. 하지만 잔디 지식베이스에 규정, 회계 매뉴얼, 인사 복지 문서를 업로드해두면 AI가 해당 문서를 기반으로 답변합니다. 출처까지 함께 제공하기 때문에 정확도를 직접 확인할 수 있고요.

대규모 조직의 지식베이스 활용 사례. 내부 정보를 관리 부서만 업로드할 수 있고 부서별로 접근 권한도 다르게 설정해 대규모 조직이 활용 가능하다. 지식베이스에 내부 정보를 올려두면, AI가 정확한 출처와 함께 답변을 제공한다. <출처: 잔디>

무역협회는 지식베이스 업로드를 관리 부서에서만 가능하게 설정하고, 부서별 접근 권한을 달리 운영하는 등 대규모 조직에 맞는 체계적인 관리 방식을 갖추고 있습니다. MCP를 통해 구글 드라이브와 연동해 맞춤형 답변을 확장하는 것도 활용 중이죠. 해외지부와의 소통에는 14개 언어 원클릭 번역 기능도 유용하게 쓰이고 있습니다.

팀원 소통부터 상담 데이터 관리까지, 병원의 활용법

빛나는 한의원

잔디를 가장 오래 쓴 사례 중 하나인 빛나는 한의원은 2016년부터 9년째 사용 중입니다. 처음에 구글챗을 도입했다가 직원들이 적응하지 못해 2주 만에 잔디로 전환했고, 결과적으로 9년간 꾸준히 쓰고 있다는 점 자체가 사용성에 대한 강력한 증거입니다.

이 한의원의 활용법에서 인상적인 건 AI 이전에 기본기가 탄탄하다는 점입니다. 토픽을 공지사항, 받은편지함, 설문결과, 전화통화, 지출증빙, 구매요청 등으로 세분화해 직원들이 어디에 무엇을 올려야 할지 헷갈리지 않게 설계했습니다.

병원 사용자의 체계적인 토픽 설계 사례 <출처: 잔디>

또 구글 캘린더와 연동해 매일 아침 8시에 그날 근무자 명단이 자동으로 알림 오게 세팅했습니다. "오늘 누가 나와요?"라는 질문이 사라졌다고 하죠. 구글 설문지와 Zapier 연동으로 환자 상담 데이터가 자동으로 잔디에 들어오는 구조도 만들었습니다. 협업툴 하나로 소통, 일정, 기록, 자동화를 전부 연결한 셈입니다.

병원 사용자의 구글 캘린더 연동 사례 <출처: 잔디>

이렇게 쌓인 데이터 위에 AI가 자연스럽게 붙었습니다. 지식베이스에 한의원 매뉴얼을 올려두니환자의 돌발 질문에도 AI가 매뉴얼 기반으로 답변할 수 있게 됐고,토픽에 쌓인 상담 데이터를 AI로 요약 분석해 자주 묻는 질문을 파악하는 데 활용하고 있습니다. 9년간 기록을 꾸준히 남겨온 팀이기 때문에 AI가 참고할 맥락이 풍부하다는 것, 이게 장기 사용자만이 가질 수 있는 강점입니다.

잔디를 10년 쓰면 생기는 일

기업용 문자 발송 서비스 기업 모노커뮤니케이션즈

모노커뮤니케이션즈는 2016년부터 잔디를 사용해온 10년차 장기 고객입니다. 기업용 문자 발송 서비스를 운영하는 IT 기업으로, 잔디 커넥트를 통해 고객 문의와 장애 알림을 실시간으로 토픽에 수신하고 있습니다. 10년간 쌓인 대화 데이터가 그대로 잔디 안에 있기 때문에, AI 토픽 요약으로 과거 이슈를 빠르게 파악하거나 고객 응대 이력을 추적하는 데 유리한 구조가 자연스럽게 만들어졌습니다.지식베이스에는 사내 규정, 업무 매뉴얼, 제품 관련 자료를 올려두고 RAG 기반 AI 질의응답에 활용하고 있죠. 경영기획부 정성문 총괄은 잔디와의 인터뷰에서 "2016년 잔디 초창기부터 함께한 만큼, 이제 잔디 AI까지 전사적으로 활용하고 있다"고 말합니다.

해외 및 오프라인 행사 활용

잔디의 활용 범위는 국내를 넘어 해외로도 확장되고 있습니다. 글로벌 패션 기업 더네이처홀딩스는 홍콩, 대만, 인도네시아 등 해외 오피스 간 언어 장벽을 해소하기 위해 잔디의 14개 언어 실시간 번역과 지식베이스를 활용 중입니다. 더네이처홀딩스 관계자는 디지털 데일리와의 인터뷰를 통해 "사내 규정 같은 정보 자산을 기반으로 고품질의 답변을 받을 수 있어 사용자 만족도가 높다"고 전했습니다. 일본 상장 통신사 비전은 2,000여 명의 구성원이 잔디를 쓰며 고객 응대 이력 요약과 AI 자동 분류로 활용 범위를 넓혀가고 있고, 비전 시스템부의 하야시 차장은 zdnet과의 인터뷰에서 "잔디 AI가 문제 대응 시간을 단축해준다"고 밝혔습니다.

14개 언어 실시간 번역이 제공돼 해외 오피스와의 언어 장벽을 해결할 수 있다 <출처: 잔디>

IT 기업이나 오피스 환경이 아닌 곳에서의 활용도 눈에 띕니다. 춘천연합마라톤을 운영하는 더픽트는 행사 운영 매뉴얼을 지식베이스에 올려 현장에서 참가자 문의에 즉시 대응하고, 토픽 요약으로 행사 중 실시간 이슈를 관리하는 등 오프라인 행사 운영에도 잔디 AI를 활용하고 있습니다. 협업툴의 쓰임이 사무실 안에만 머물지 않는다는 걸 보여주는 사례입니다.

마치며: 탄탄한 고객 기반으로 성장하는 잔디

협업툴의 가치는 결국 얼마나 오래, 자연스럽게 쓸 수 있느냐에 달려 있습니다. 아무리 기능이 많아도 팀에 정착하지 못하면 의미가 없죠.

잔디가 4.35점을 받은 배경에는 빛나는 한의원의 9년, 모노커뮤니케이션즈의 10년 같은 장기적인 활용을 통해 쌓아온 두터운 고객 기반이 있습니다. 이 팀들이 오래 쓸 수 있었던 건 한국 기업 환경에 맞는 기본기, 즉 직관적인 UI, 조직도 연동, HWP 지원, 쉬운 온보딩 등이 탄탄했기 때문이고, 그 위에 쌓인 데이터가 지금은 AI의 자산이 되고 있습니다. 오래 쓸수록 AI가 똑똑해지는 구조, 이것이 잔디가 만들어온 선순환입니다.

물론 모바일 속도나 검색 UX처럼 아직 개선이 필요한 부분은 남아 있습니다. 다만 사용자 피드백을 반영해 꾸준히 다듬어 나가는 건 좋은 제품의 기본이자 숙명이고, 잔디도 그 과정 위에 있습니다.

또 업종도 규모도 활용법도 다른 팀들이 각자의 방식으로 쓰고 있다는 것 자체가, 이 툴이 특정 업종이 아닌 '일하는 팀'이라면 어디든 맞출 수 있는 범용성을 갖고 있다는 뜻이기도 합니다. 그만큼 기업의 다양한 니즈를 담아내며 성장하는 프로덕트라고 할 수 있습니다. 해외 팀과 오프라인 행사까지 활용 범위가 넓어지고 있다는 점도 고객사례에서 확인할 수 있었습니다.

서론에서 던졌던 질문으로 돌아가면,AI 시대에 살아남는 협업툴은 기능이 많은 도구가 아니라 조직의 업무 흐름을 깊이 감싸는 도구였습니다. 협업툴을 고를 때 기능 리스트만 비교하는 건 한계가 있습니다. 결국 중요한 건 우리 팀에 정착할 수 있는가, 쌓인 데이터가 자산이 되는가, 그리고 변화하는 업무 방식에 맞춰 함께 진화하는가죠. 잔디의 리뷰와 고객사례가 보여주는 건, 이 질문들에 10년간 답해온 하나의 궤적입니다.

➡️협업 툴 잔디 서비스소개서 다운로드

]]>

바이브 코딩으로 만든 앱을 0원으로 배포하는 법

Cursor든 Claude code든, AI와 함께 열심히 바이브 코딩해 앱을 만들었습니다. AI가 알려준 대로 npm run dev를 쳐 보니 내 노트북에서 앱이 완벽하게 돌아갑니다. 정말 완벽하죠. 누구든 써보고 싶어할 정도로요.

하지만 브라우저에 뜬 localhost, 이건 내 컴퓨터 안에서만 통하는 주소입니다. 따라서 그 상태의 앱은 세상에 존재하지 않는 것과 같습니다. 친구에게 “한 번 써봐”라고 꺼드럭대려면 결국 클릭할 수 있는 URL이 필요합니다.

여기서부터 바이브 코딩의 사각지대입니다. 코드는 AI가 빠르게 뽑아주는데, 배포는 여전히 사람을 괴롭힙니다. 도메인 연결, HTTPS 적용, DB 연결, 환경변수 세팅, 그리고 운영 중 장애 대응까지. 앱을 만드는 일과 앱을 밖으로 꺼내는 일은 완전히 다른 게임입니다. 이 마지막 1km가 바이브 코딩 배포에서 가장 자주 막히는 지점입니다.

오늘은 그 1km를 다뤄볼 예정인데요, 결론부터 말하겠습니다. 2026년 기준, 바이브 코딩 앱의 표준 배포 스택은 Vercel + Supabase입니다. 이 Vercel과 Supabase를 기본값으로 깔고 세 가지를 정리합니다. 첫째, 왜 이 조합이 무료 배포의 표준이 됐는지. 둘째, 0원으로 어디까지 버틸 수 있는지. 셋째, 내 상황에서 이 스택이 안 맞을 때 어떤 대안을 고르면 되는지입니다.

Vercel+Supabase가 ‘바이브 코딩 표준 스택’이 된 이유

Vercel은 코드를 빌드해서 인터넷에 띄워주는 배포 플랫폼입니다. 프론트엔드 페이지도 서빙하고, API Route 같은 서버리스 함수도 돌려주지만, 데이터를 영구적으로 저장할 곳이 마땅치 않습니다. 서버리스 함수는 요청이 올 때 실행됐다가 사라지는 구조라 유저 정보나 게시글 같은 데이터를 담아둘 DB가 자체적으로 없는 거죠.

그 빈자리는 Supabase가 채웁니다. PostgreSQL DB, 유저 인증, 파일 스토리지, 실시간 구독까지 “데이터를 다루는 모든 것”을 한 덩어리로 제공하기 때문이죠.

Vercel과 Supabase

1.Vercel이 선택 받은 이유: Next.js 기본값

Vercel은 Next.js를 만든 회사의 배포 플랫폼입니다. 또, Next.js는 AI가 정말 자주 택하는 스택이고요. 그래서 그 Next.js로 만든 앱을 서버에 올릴 때 생기는 자잘한 삽질 포인트가 가장 적습니다. 라우팅, 서버리스 함수, 빌드 설정 같은 것들이요. 결국 바이브 코딩으로 만든 결과물을 일단 인터넷에 띄우기엔 기본값에 가깝습니다.

게다가 Vercel의 진짜 강점은 GitHub 연동에서 느껴집니다. 한 번 연결해두면 push할 때마다 자동 배포가 돌아갑니다. 그리고 PR을 만들면 프리뷰 URL이 자동으로 생깁니다. 파일 공유가 아니라 링크 하나 던지는 일로 업데이트를 돌릴 수 있습니다.

무료 티어도 MVP 단계에선 꽤 든든합니다. 서버리스 함수나 엣지 런타임(사용자와 가까운 곳에서 실행되는 환경)까지 포함하고요.

좀 더 와닿게 말하면, AI가 잘 다루는 스택과 가장 가깝기 때문에 위의 용어를 하나도 몰라도 돈을 내지 않고 앱을 돌릴 수 있다는 겁니다. 그래서 초반엔 서버를 어디에, 어떻게 올릴지 같은 운영 결정을 뒤로 미룰 수 있습니다. 만들고, 보여주고, 반응을 보는 흐름이 끊기지 않습니다.

2.Supabase가 선택 받은 이유: 백엔드 올인원 + SQL

Supabase는 한마디로 백엔드 올인원 세트입니다. PostgreSQL 기반 DB를 중심에 두고, 인증, 스토리지, 실시간 기능, Edge Function까지 한 덩어리로 제공합니다. 그러니까 백엔드에서 필요한 부품들을 따로 주문해 조립하는 대신 패키지로 바로 받아 쓰는 느낌입니다. 바이브 코딩에선 이 한 덩어리가 정말 중요합니다.

처음엔 원조 격인 Firebase의 대안으로 많이 언급됐지만, 방향성이 다릅니다. 무엇보다 Supabase는 SQL 기반이라 데이터 구조를 바꾸거나, 원하는 형태로 조회하는 게 더 유연합니다. 서비스가 커질수록 데이터는 복잡해지는데, 그때 처음 선택 때문에 막히는 일이 상대적으로 덜합니다. 그래서 지금은 많은 팀이 사실상 기본 선택지처럼 씁니다.

또 하나는 AI 기능과의 결입니다. Supabase는 pgvector로 임베딩(문장이나 이미지의 의미를 숫자로 바꾼 값) 저장도 가능합니다. 2026년 앱은 AI 기능 하나쯤은 붙이자가 흔한 요구가 됐습니다. 그런 상황에서 Supabase는 처음부터 그 방향을 염두에 둔 느낌이 납니다.

더 자세한 것은 Supabase는 요즘 왜 그렇게 인기가 많을까? 콘텐츠에서 확인할 수 있습니다.

3. 결정적 이유: AI 모델이 이 스택을 ‘많이 봐서’ 더 잘 만든다

사실 이 조합이 표준 스택이 되는 과정엔 기술적 특징만 있었던 것은 아닙니다. AI 코딩 도구들이 무엇을 기본값으로 채택하느냐가 큽니다. Cursor, Lovable, Bolt.new, v0 같은 도구들이 Supabase를 백엔드로 적극 쓰면서 생성되는 코드 패턴이 점점 비슷해졌기 때문입니다. 이처럼 많이 쓰이는 조합은 더 많이 복제되고, 더 빠르게 표준이 됩니다.

여기서 중요한 건 AI가 이 스택을 유독 잘한다가 아니라, 자주 본 걸 더 잘한다는 점입니다. Supabase와 Vercel은 이미 많은 예제와 프로젝트에서 반복된 패턴입니다. 그래서 “배포해줘”, “로그인 붙여줘”, “DB에 저장해줘” 같은 요청을 던졌을 때 성공률이 올라갑니다.

마지막으로 운영 마찰도 더 내려가고 있습니다. Supabase는 MCP 서버를 통해 자연어로 DB 작업을 돕는 흐름이 커지고 있습니다. 스키마를 만들고, 수정하고, 관리하는 작업이 대시보드 클릭에서 말로 지시하는 수준까지 넘어가는 겁니다. 결국 Vercel + Supabase가 표준이 된 건, 편해서이기도 하지만 AI 시대에 가장 잘 맞는 반복 패턴이 됐기 때문입니다.

아, 하나 더 있습니다. 이들이 제공하는 무료 티어로 배포하면 '처음에는' 돈이 안 드는 것처럼 느껴진다는 겁니다.

“무료 티어”가 버텨주는 구간과 첫 병목

MVP 단계에서는 유저가 적을수록 돈을 쓰지 않는 게 맞습니다. 기능이 완벽해서가 아니라 “이게 진짜 필요한가?”를 확인하는 구간이기 때문입니다. 그래서 가설 검증 단계에서 서버비는 0원이 이상적이라는 말에 1인 개발자들이 고개를 끄덕이죠. 그럼 의문이 생깁니다. AI가 하라는 대로 연결한 이 서비스들은 0원으로 어디까지 버텨줄까요?

<출처: 요즘IT, Gemini로 제작>

1. Vercel 0원 플랜(Hobby): 프론트 + API까지는 생각보다 넉넉

Vercel의 Hobby 플랜은 MVP에 필요한 대부분을 무료로 커버합니다. 제공 한도는 대역폭 100GB/월, 서버리스 함수 실행 100GB-시간, 빌드 6,000분/월입니다. 랜딩 페이지, 대시보드, 그리고 간단한 CRUD API 정도라면 여기서 막힐 일이 많지 않습니다. 쉽게 말해 웹앱 한 벌을 만들고 보여주기까지는 Vercel이 꽤 오래 버텨줍니다.

다만 첫 번째 경고등은 보통 이미지나 대용량 파일에서 켜집니다. 파일을 Vercel 쪽으로 무리하게 보내면 비용이나 제한이 예상보다 빨리 다가올 수 있습니다. 이 지점이 자연스럽게 다음 병목으로 이어집니다. 결국 문제는 유저 수가 아니라 스토리지와 대역폭입니다.

아참. 가장 꼭 알아야 할 것이 있습니다. Vercel Hobby 플랜은 개인이나 비상업 목적에서만 무료 배포를 지원합니다. 애초에 상업적인 목적이라면, 어느 정도는 돈을 지불할 생각을 해야 합니다.

2) Supabase 0원 플랜(Free): 유저 수보다 전송량·스토리지·휴면 정책이 먼저

Supabase Free 플랜은 숫자만 보면 꽤 관대해 보입니다. DB 500MB, 인증 MAU 5만, 스토리지 1GB, Edge 함수 50만 호출/월, DB 전송량 2GB가 기본으로 제공됩니다. 여기서 포인트는 인증 MAU가 넉넉하다는 점입니다. 즉 사용자가 늘어난다고 바로 막히는 구조는 아닙니다.

대신 더 자주 밟는 함정은 따로 있습니다. 7일 동안 활동이 없으면 프로젝트가 자동 일시정지된다는 정책입니다. 이건 서비스가 조용한 초기에는 꽤 성가신 마찰이 됩니다. 해결은 두 갈래입니다. 유저가 생기면 자연스럽게 해결되거나, 초기에는 크론이나 헬스체크로 가끔 깨워두기를 선택하면 됩니다.

Supabase에서 가장 먼저 뚫릴 가능성이 큰 건 5GB 대역폭인데, 보통 이건 스토리지 사용 패턴 때문에 넘칩니다. 반대로 말하면 사용자 수백 명 수준에서는 0원으로도 충분히 굴러간다는 겁니다. 무료 티어를 뚫을 만큼 트래픽이 나온다면, 그건 실패가 아니라 성공 신호에 가깝습니다. 그때가 바로 Supabase Pro($25) 결제를 ‘양심적으로’ 고민할 타이밍입니다.

Vercel + Supabase가 안 맞는 순간의 대안들

물론 이렇게 Vercel + Supabase는 "대부분의" 바이브 코딩 앱에 잘 맞습니다. 하지만 당연히 모든 구조의 앱에 최적화된 건 아니겠죠. 기능이 단순하거나, 반대로 런타임 제약이 빡세면 이 조합이 오히려 발목을 잡습니다. 이럴 때는 대체가 아니라 조건별로 스택을 갈아 끼우는 감각이 필요합니다.

1. 정적 사이트/랜딩만 필요하다면:Cloudflare Pages

Cloudflare pages

앱이 아니라 정적 사이트만 필요할 때가 있습니다. 예를 들어 제품 소개 랜딩, 문서 사이트, 포트폴리오처럼 “페이지 보여주기”가 전부인 경우죠. 이런 경우엔 Vercel보다 Cloudflare Pages가 마음이 편합니다. 요청 수나 대역폭이 사실상 무제한에 가까운 무료 정책이라 일단 올려두기에 부담이 적습니다.

여기서 포인트는 “Supabase가 꼭 필요하냐”입니다. 랜딩 페이지에서 필요한 건 대개 DB가 아니라 문의 폼 정도입니다. 이건 외부 폼 서비스로 받거나, 아주 얇은 서버리스로 대체할 수 있습니다. 그러면 백엔드까지 세팅하는 배포가 아니라 백엔드 없는 배포로 끝낼 수 있습니다.

2. Python/FastAPI를 꼭 돌려야 한다면:Railway또는Render

Railway와 Render

반대로, Vercel + Supabase로는 답이 안 나오는 순간도 있습니다. 대표적인 경우가 Python/FastAPI를 꼭 돌려야 할 때입니다. Next.js의 API Route로 감당이 안 되거나, 이미 쌓아둔 Python 코드가 있을 때가 그렇습니다. 특히 ML 추론 서버처럼 항상 떠 있어야 하는 프로세스가 있으면, 배포 방식 자체를 바꿔야 할 때가 있습니다.

이럴 때 Railway는 작게 굴리기에 적합합니다. 월 $5 크레딧 기반이라 트래픽이 크지 않은 초기에는 부담이 덜합니다.(이말인즉 무료는 아니라는 겁니다) 일단 적은 돈으로 돌아가게 만들고 비용이 보이면 그때 구조를 다듬는 흐름에 잘 맞습니다.

Render는 더 가볍게 체험하기 좋습니다. 무료 인스턴스가 가능하지만, 대신 콜드 스타트(한동안 안 쓰면 잠들었다가, 호출 시 느리게 깨어남)가 있습니다. 그래서 데모나 테스트에는 괜찮아도 사용자가 상시 접속하는 서비스라면 주의가 필요합니다. '가끔 느려도 되는가'가 선택 기준입니다.

3. Vercel 한도가 아슬아슬하거나 엣지 중심으로 가고 싶다면

Netlify

Vercel이 싫어서가 아니라, 무료 한도가 아슬아슬해지는 순간이 있습니다. 그때는 같은 카테고리의 대체재로 Netlify를 먼저 떠올릴 수 있습니다. 포지션이 비슷해서, 마이그레이션 난이도도 비교적 낮은 편입니다.

또 하나의 갈래는 Cloudflare Workers + Pages 조합입니다. 프론트는 Pages에 두고, 가벼운 백엔드는 Workers로 붙이는 방식이죠. 쉽게 말해 서버를 한 곳에 크게 세우는 대신, 사용자 가까운 곳(엣지)에 얇게 배치하는 선택입니다. 비용과 성능의 균형을 노릴 때 검토할 만합니다.

여기서도 기준은 하나입니다. “무조건 Vercel을 버리자”가 아니라, AI 코딩 결과물이 어느 스택에 더 자주 맞춰 나오느냐를 봐야 합니다. 바이브 코딩 배포의 핵심은, 내가 코드를 다 이해하기 전에라도 일단 돌아가게 만드는 데 있으니까요. 그래서 조건부 전환이 가장 안전합니다.

마치며

2026년 기준으로 보면, 바이브 코딩으로 만든 앱을 0원에 가깝게 배포하는 가장 현실적인 조합은 Vercel + Supabase입니다. GitHub에 push만 해도 자동으로 빌드·배포가 돌고, URL이 바로 생깁니다. 무료 티어도 MVP를 검증하기엔 대체로 충분합니다. 그래서 일단 사용자를 만나러 나가는 속도만 놓고 보면, 이 조합이 지금 가장 표준에 가깝습니다.

이 배포 방식이 갖는 의미는 분명합니다. 완벽한 아키텍처를 세우기 전에 가장 빠르게 배포해서 사용자 반응을 보는 것. 그게 바이브 코딩 배포의 본질입니다. 대신 트래픽, 보안, 비용 최적화 같은 서비스 레벨의 문제는, 그다음 단계에서 완전히 다른 난이도로 다시 만날 것을 각오해야 합니다.

게다가요, 배포는 사실 끝이 아니라 실험의 시작입니다. URL을 띄웠다면 이제 다음 질문은 하나로 모입니다. “이 앱으로 어떻게 돈을 벌어보지?” 그렇게 다음 눈은 결국 결제로 갑니다. 그 단계는 다음 글에서 다시 이어가겠습니다.

]]>

영업 없이 1,000개 기업이 찾아온 '웍스AI' 표철민 대표의 생존법

[요즘 프로덕트] 시리즈

요즘 AI 기술이 빠르게 발전하면서, 사실 '어떻게 만드는가'에 대한 기술적 장벽은 점점 낮아지고 있습니다. 이제는 누구나 AI를 활용해서 뭔가를 만들 수 있는 시대가 됐는데요. 그래서 역설적으로 더 중요해진 게 있습니다. 바로 이 두 가지를 정의하는 능력입니다.

'어떤 문제를 해결할 것인지',
'그게 왜 지금 해결해야 하는 문제인지'

[요즘 프로덕트]는 이렇게 탁월한 문제 정의로 시장의 판을 바꾸고 있는 메이커들의 사고방식을 추적해보는 시리즈입니다. 이번에는 아웃바운드 영업 없이 지난 해 1,000개 기업을 잡은 기업용 AI 서비스 웍스AI의 표철민 대표를 만났습니다.

표철민 대표는 요즘 하루에 3시간씩 잡니다. 쫓기고 있기 때문입니다. "아무리 좋은 제품을 만들어도 무조건 도망만이 생존이다." 그가 하는 말이지만, 정작 그가 만드는 제품은 기업들이 AI를 도입할 수 있도록 돕는 플랫폼 웍스AI입니다. AI 때문에 도망치면서, AI로 도망치는 제품을 만들고 있습니다. 어딘가 아이러니하지만, 그는 이것을 모순이라고 생각하지 않습니다. AI 시대에 살아남는 방법이 원래 그런 거라고 말합니다.

그가 처음 AI 쪽으로 뛰어든 건 2023년 3월이었습니다. 블록체인 경기 침체로 회사 분위기가 무거웠던 시기, OpenAI API가 출시되던 날 밤 개발자 한 명과 함께 앉아 24시간 만에 제품 하나를 만들었습니다. 아무에게도 알리지 않은 사이드 프로젝트였습니다. "그때는 이걸로 의미 있는 걸 만들 수 있을 거라고 생각하기엔 너무 초기였어요. 그냥 재미있는 걸 만들어 보자는 거였죠." 그게 지금의 웍스AI가 될 제품의 극초기 버전이었습니다.

3년이 지났습니다. 웍스AI는 지난해에만 1,000개 기업이 새로 도입한 기업용 AI 플랫폼이 됐습니다. 팀원은 20명입니다. 아웃바운드 영업은 한 번도 하지 않았습니다. 영업 현장에서는 기업용 챗GPT의 국내 리셀러인 삼성SDS, LGCNS와 맞붙고 있고, LS그룹은 이 제품을 도입해 99% 비용 절감을 달성한 팀이 회장 표창을 받았습니다. 표 대표는 "AI가 없었으면 절대 못 했다"고 말합니다. 요즘IT '요즘 프로덕트' 시리즈에서 그를 만났습니다.

웍스AI 사용 화면 <출처: 웍스ai>

블록체인 회사가 AI 플랫폼이 된 사연

웍스AI의 전신은 '네이티브'라는 제품이었습니다. 2023년 초, 챗GPT가 막 화제가 되던 시절 한국어 사용자들에게는 뚜렷한 불편함이 있었습니다. 챗GPT가 영어에 비해 한국어를 훨씬 못했기 때문입니다. 표 대표는 여기서 틈새를 봤습니다. 번역 API를 앞에 붙여 한국어 입력을 영어로 바꾼 뒤 GPT에 보내고, 영어로 나온 답변을 다시 한국어로 번역해서 돌려주는 구조였습니다. "모든 네이티브 스피커들도 AI를 누릴 자격이 있다"는 컨셉이었습니다.

그런데 GPT-4가 나오면서 상황이 바뀌었습니다. 한국어를 너무 잘하게 된 거죠. 네이티브라는 제품이 존재해야 할 이유가 사라졌습니다. 어디로 도망가야 할까, 하다가 ‘업무’로 좁히기로 했습니다. AI가 진짜 도움이 될 수 있는 영역은 결국 ‘일’이라는 판단이었습니다. 이에 2023년 8월, 이름을 웍스AI로 바꾸고 업무 특화 서비스로 피벗을 결정했습니다.

당시 프롬프트 엔지니어링은 일반 직장인에게 높은 장벽이었습니다. 표 대표 팀은 여기에 집중했습니다. 문서 번역, 회의록 작성, 보고서 작성 같은 직장인들이 자주 마주치는 업무에 프롬프트를 미리 심어두고, 버튼 하나만 누르면 바로 결과가 나오는 구조를 만들었습니다.

웍스AI를 운영하는 AI3의 표철민 대표가 요즘IT와 ZOOM을 통해 화상 인터뷰를 진행하고 있다 <출처: 요즘IT>

"지금 생각하면 별거 아닌데, 그때는 나름 신박한 아이디어였어요."

초기에 담을 수 있는 기능의 기준은 단순했습니다. 당시 AI 성능으로 잘할 수 있는 것, 그중에서도 직장인들이 실제로 필요로 하는 것이었습니다. 번역이 가장 먼저였고, 이후 유저 피드백을 받으면서 기능을 하나씩 붙여나갔습니다. 3년간 150회 이상의 업데이트가 그렇게 쌓였습니다. 현재는 번역뿐 아니라 보고서 작성, 엑셀 분석, 이미지 및 동영상 생성, 문서 관리 등 직장인의 업무와 관련된 다양한 기능을 담은 서비스로 성장했죠.

‘먹튀’가 만든 기업용 무기

사실 이때까지만 해도 기업용 서비스를 염두에 둔 건 아니었습니다. 표 대표는 줄곧 B2C만 해온 사람이었고, B2B는 경험이 없었습니다. 그런데 개인용으로 준비했던 서비스가 우연히 기업용 서비스에서 빛을 발하는 상황을 맞이하게 되죠.

개인 사용자가 늘어나던 시기, 그는 요금 모델 실험을 병행했습니다. 당시 챗GPT 유료 구독이 월 22달러였는데, 실제 사용 데이터를 들여다보니 하루 평균 여섯 번 대화를 나눈다고 해도, 대화당 과금하면 한 달에 9천 원 수준이었습니다. 고정 월정액보다 실제로 쓴 만큼만 내는 종량제가 사용자에게 훨씬 유리하다는 계산이 섰습니다. 그렇게 후불 종량제를 도입하게 됐죠.

반응은 좋았지만, 문제는 그다음에 나타났습니다. 서비스를 쓰고 난 뒤 결제 시점 이전에 카드를 해지해버리는 사용자들이 생긴 것입니다. 이른바 "먹튀"였습니다. 이를 계기로 개인에게는 더 이상 후불 종량제를 제공하지 않고 월 구독료를 내는 모델로 바꾸게 되죠.

그런데 이 종량제 모델이 기업 시장에서 먹히기 시작한 것입니다. 표 대표에 따르면 챗GPT 기업용 구독은 인당 월 40~50달러, 직원 1,000명이면 한 달에 7,000만 원입니다. 하지만 실제로 AI를 매일 쓰는 헤비유저는 전체의 10%에 불과하고, 아예 안 쓰는 직원도 절반에 달한다고 합니다. 종량제로 전환하면 실사용량 기준으로만 과금되기 때문에, 어떤 회사든 월정액 구독 대비 95% 이상 저렴해진다는 게 그의 계산입니다.

개인 사용자에게는 독이 됐던 후불 종량제가, 기업에게는 오히려 강점이었습니다. 비용 부담 없이 전사 도입이 가능하고, 안 쓰는 직원이 많아도 그만큼 비용이 줄어드니까요. 또 웍스AI 입장에서도 ‘먹튀’ 위험 부담이 적었습니다. 이를 계기로 웍스AI는 본격적으로 기업용 제품으로 무게중심을 옮겼습니다. B2C 실험의 실패가 B2B의 무기가 된 셈이었습니다.

토큰 사용량 확인 대시보드 <출처: 웍스AI>

보안만 2년, 기업이 원하는 건 달랐다

기업 고객을 상대해보니 개인 사용자와는 전혀 다른 요구들이 쏟아졌습니다. 기업들이 가장 먼저 물어보는 건 보안이었습니다. 표 대표는 "지난 2년간 AI 기능 개발보다 보안 기능만 거의 개발했다"고 말할 정도입니다.

웍스AI는 현재 5중 차단 구조를 갖추고 있습니다. 외부 공격을 막는 웹 방화벽(WAF)이 맨 앞에서 한 번 거르고, 하드웨어 DLP, 소프트웨어 DLP, AI 가드레일, 마지막으로 LLM 자체 가드레일까지 순서대로 통과해야 합니다. "왜 코드를 올렸는데 실행이 안 되냐는 문의가 고객센터에 들어오는 경우가 있는데, 5중 차단을 하고 있기 때문"이라고 표 대표는 말합니다.

비용 관리도 기업의 큰 관심사 중 하나입니다. 종량제의 장점이 자칫 단점이 될 수 있는 지점, 즉 요금이 예상보다 많이 나올 수 있다는 우려를 관리자 기능으로 해소했습니다. 전사 한도와 인당 한도를 미리 설정할 수 있고, 비용이 높은 모델은 관리자가 아예 꺼둘 수도 있습니다. 기본료는 없습니다. 3,000명, 4,000명 규모의 기업도 사용하지 않으면 요금이 0원입니다.

기업의 요구에 따라 직원들의 사용 현황도 투명하게 들여다볼 수 있도록 했습니다. 누가 언제 로그인했는지, 어떤 파일을 올리고 내려받았는지, 어떤 에이전트를 만들었는지까지 모든 활동이 감사 로그로 쌓입니다. 부서 간 데이터 차단도 적용돼 있어, 인사팀이 만든 AI 에이전트를 재무팀이 볼 수 없습니다. 직원들이 사내 IP에서만 접속할 수 있도록 통제하거나, 집에서는 파일 다운로드를 막는 것도 가능합니다.

기업의 보안과 비용 관리 등에 대한 요구에 빠르게 대응하다 보니, 현재 LS그룹, 현대건설, 포스코인터내셔널, 한국거래소, 서울시 교육청을 비롯한 6개 교육청 등 규모가 큰 기업, 공공기관들이 웍스AI를 전사 도입했습니다.

전 세계에 한국에만 있는 버튼

기업 고객이 늘어나면서 웍스AI에는 독특한 기능들이 하나씩 붙기 시작했습니다. 한국 기업들의 요구사항을 반영하다 보니, 해외 서비스에서는 찾아볼 수 없는 기능들이 생겨난 겁니다. 표 대표는 그중 가장 독특한 것으로 '킬 스위치'를 꼽습니다.

버튼 하나를 누르면 전 직원의 접속이 즉시 차단되는 기능입니다. 조사, 감사 등의 상황에 대비해, 외부 인력에게 민감한 정보를 노출하지 않도록 하기 위해 만들어졌습니다. "이건 진짜 전 세계에서 저희밖에 없을 거예요." 표 대표의 말입니다. 한국 기업 특유의 니즈가 만들어낸 기능입니다.

이뿐만이 아닙니다. 오너 이름을 AI에 입력하지 못하도록 막는 금칙어 설정, 계열사마다 다른 도메인을 하나의 워크스페이스에서 통합 관리하는 기능, 특정 그룹웨어 계정으로만 로그인을 허용하는 설정까지. 기업마다 다른 요구사항을 하나씩 받아 제품에 녹여온 결과입니다. 표 대표는 하루에 최소 50개 이상의 고객 문의를 직접 처리한다고 합니다. "피드백이 타당하다 싶으면 2시간 안에 업데이트해요. 그냥 바로 고쳐드립니다."

개인정보 처리 방식도 한국 기업 환경에 맞게 설계됐습니다. 직원이 주민번호나 전화번호가 포함된 문서를 올리면, AI 가드레일이 국내 서버에서 해당 정보를 자동으로 마스킹한 뒤 해외 LLM으로 전송합니다. 정보가 해외 서버로 나가기 전에 국내에서 걸러지는 구조입니다. 올해 1월 시행된 AI 기본법 요건도 이미 제품 안에 내장돼 있습니다.

표 대표는 웍스AI가 "모델 개발사와 B2B 고객들 사이에서 최신 AI 모델을 잘 버무려서 갖다 드리는 역할"을 하고 있다고 표현합니다. 웍스AI에서는 챗GPT, 제미나이, 클로드 같은 외산 모델은 물론, 국내 소버린 AI 모델까지 골라서 쓸 수 있습니다. 개발자가 아닌 일반 직장인 입장에서는 어떤 모델이 좋은지 비교해볼 여유가 없는데, 웍스AI가 그 선택지를 한 곳에 모아두는 역할을 하는 겁니다. 도면 분석이 필요한 고객이 생기면, 전 세계 AI 모델 중 도면에 최적화된 것을 찾아 붙여주는 식입니다.

웍스AI에서 사용할 수 있는 모델 <출처: 웍스AI>

천 개 이상의 기업이 고객이 되며 생긴 또 다른 변화도 있습니다. 아직 공개되지 않은 최신 모델을 웍스AI에 먼저 선공개해주는 AI 개발사들이 생기기 시작한 겁니다. 국내 소버린 AI 경쟁에서 3강에 오른 모델 중 두 개를 웍스AI가 국내 최초로 서빙하기도 했습니다. "저희 고객들 입장에서는 좋은 모델을 빨리 받아서 좋죠." 규모가 신뢰를 만들고, 신뢰가 다시 고객에게 돌아오는 구조입니다.

AI 시대의 해자는 ‘무엇을 만들지’다

영업을 한 번도 하지 않았는데 지난해 1,000개 기업이 들어왔다면, 경쟁사들이 가만히 있을 리 없습니다. 지금 웍스AI의 영업 현장 맞은편에는 삼성SDS와 LGCNS가 있습니다. 챗GPT 엔터프라이즈의 국내 총판들입니다. 팀원 20명짜리 스타트업이 대기업 SI 계열사와 같은 테이블에서 경쟁하고 있는 겁니다.

표 대표는 해자를 묻는 질문에 조심스럽게 답합니다. "AI 시대에는 해자가 존재하지 않는 것 같아요. 딸깍하면 모든 게 튀어나오는 마당이니까요." 실제로 웍스AI가 먼저 만든 종량제 모델을 비슷하게 따라 만드는 국내 B2B 회사들이 빠르게 늘고 있습니다. 기술 구현 자체는 더 이상 해자가 되지 않는다는 걸 표 대표도 압니다.

그가 유리하다고 보는 건 다른 지점입니다. "구현보다는 뭘 만들 것인가의 해자"입니다. 천 개 기업의 피드백은 경향성을 띱니다. 어떤 시즌이 되면 비슷한 요구가 겹쳐서 들어옵니다. 웍스AI는 그걸 가장 먼저 감지하고, 가장 빨리 만듭니다. 다른 회사들은 그다음에 따라옵니다. "저희가 맨날 고객 피드백을 먼저 받고 있으니까요." 말하자면 선점한 고객 기반이 다음 제품의 나침반이 되는 구조입니다.

고객 CS 화면 <출처: 웍스AI>

팀 규모도 무기입니다. 20명 중 개발팀은 10명입니다. 예전 같았으면 불가능한 규모였겠지만, 지금은 AI로 개발 속도를 끌어올리고 있습니다. "AI가 없었으면 절대 못 했죠." 피드백이 타당하다 싶으면 2시간 안에 업데이트가 나갑니다. 대기업 SI 계열사가 따라오기 어려운 속도입니다.

B2B가 처음이었던 표 대표가 택한 또 다른 전략은 제품의 결을 바꾸지 않는 것입니다. 기업용 소프트웨어 특유의 딱딱함 대신, 직관적이고 아기자기한 UI를 고집합니다. 비디오 생성 기능 하나를 만들더라도 '카메라 고정', '안정적', '역동적' 같은 용어 대신 마우스를 올리면 예시 영상이 재생되는 방식으로 만듭니다. "토스 수준의 압도적으로 쉬운 제품에 집중하자"는 게 그의 목표입니다. 전사 도입용 제품인 만큼, AI에 익숙하지 않은 직원도 쓸 수 있어야 한다는 판단입니다.

더 빠르게 도망쳐라, 아직 AI가 점령하지 않은 곳으로

표 대표는 AI 업계 한복판에 있으면서, AI에 가장 위협받는 사람이 자기 자신이라는 걸 압니다. 신입 기획자들이 클로드 코드로 시니어 수준의 기획을 건너뛰고 제품을 만들어 내는 걸 매일 봅니다. "프로덕트 메이킹의 전문성이라는 게 의미가 있나." 그가 매일 하는 고민입니다.

그럼에도 아직 메이커에게 창이 열려 있다고 보는 건 메이커들이 "깎는 것"을 잘하기 때문입니다. AI는 딸깍 한 번으로 제품을 뚝딱 만들어냅니다. 하지만 다듬는 건 다른 얘기입니다. "해본 사람이 잘해요. 뭘 어떻게 깎아야 되는지 알잖아요." 제작팀을 꾸려 협업하고, 오더를 내리고 받는 데 익숙한 사람들이 그 역할을 AI에게 시킬 수 있다는 겁니다. 다만 이 창이 “2년 안에 닫힐 수 있다”고도 합니다. ‘프롬프트 엔지니어링’이란 것이 불과 2년 만에 무의미해진 것처럼요.

그런데 “더 근본적인 위기는 따로 있다”고 그는 말합니다. 일식집 주방장처럼 깊은 도메인 지식을 가진 사람들이 AI의 도움으로 직접 제품을 만들기 시작하면, 만드는 기술만 있고 도메인이 없는 IT 업계 사람들이 설 자리가 줄어든다는 것입니다. "IT 업종이 다른 업종보다 큰일 났어요." 스스로 클로드 코드 에반젤리스트를 자처하며 주변 모든 사람에게 바이브코딩을 권하고 다니는 사람이, 정작 그 파도가 자신에게 가장 먼저 덮칠 거라는 걸 알고 있습니다.

결국 그가 선택한 답은 더 빠르게 도망치는 것입니다. 이번 주에도 새 제품을 만들고 있습니다. B2B인 웍스AI와는 별개로, 개인용 AI 에이전트를 처음부터 다시 짜고 있습니다. "일주일에 앱 하나씩. 그냥 무조건 만들어요." 뭘 만들지를 아는 사람이 살아남는 시대에, 많이 만들어봐야 뭘 만들지가 보인다는 겁니다. 많은 기업이 찾는 프로덕트를 만들고도, 그의 도망은 계속됩니다.

“자기 제품에 안심할 수 있는 날이 한 달 정도밖에 안 되는 시대 같아요. 열심히 도망쳐야죠.”

]]>

코딩 에이전트 여럿 쓰게 해주는 오케스트레이터 도구 3가지

Claude Code에 프롬프트를 던집니다. 에이전트가 일할 때면 저는 기다리는 게 일이 됩니다. 기능 A가 끝나야 기능 B를 시킬 수 있으니까요. 내 손은 키보드 위에 있지만 다음 지시를 줄 타이밍만 재고 있고는 합니다. 성능 좋은 에이전트를 써도 작업 구조는 싱글 스레드이기 때문입니다. 이 똑똑한 에이전트를 써도 개발 프로세스는 여전히 대기열로 굴러가는 셈입니다.

그런데 현실의 개발은 원래 이렇게 안 굴러갑니다. 백엔드는 API를 만들고, 프론트엔드는 화면을 붙이고, 테스트는 케이스를 짜고, 문서는 사용법을 정리합니다. 이 일들은 서로 완전히 끝날 때까지 기다릴 필요가 없습니다. 오히려 동시에 움직일 때 속도가 나고 병목도 빨리 드러납니다. 그러니까, 개발은 원래 멀티플레이가 기본이죠.

그래서 필요한 게 에이전트를 여러 명 동시에 굴리게 해주는 관리자입니다. 이 역할을 하는 도구를 에이전트 오케스트레이터(Agent Orchestrator)라고 부릅니다. 어쩌면 앞으로는 에이전트가 코딩한다는 말보다 오케스트레이터가 팀을 굴린다는 말이 더 자주 나올지도 모릅니다. 그만큼 중요해질지도 모른다는 뜻입니다.

이 글에서는 오케스트레이터가 왜 필요한지부터 짚고, 어떤 문제를 해결해 주는지 정리해보려고 합니다. 그리고 코딩 에이전트를 여럿 동시에 쓰게 해주는 오케스트레이터 도구 3가지를 비교해 보겠습니다.

<출처: 작가, Gemini로 제작>

오케스트레이터가 ‘병렬 개발’하게 만드는 3가지 핵심 기능

막연히 코딩 에이전트를 여러 명 붙이면 속도가 빨라질 것 같나요? 현실은 다를 수도 있습니다. 무작정 같은 브랜치, 같은 폴더를 동시에 만지는 순간 충돌이 기하급수적으로 늘어나기 때문입니다. 게다가 미친듯이 쏟아내는 결과물을 사람이 판단할 수 없다면 꽝이기도 하니까요. 그래서 오케스트레이터는 이런 역할들을 해야 합니다.

격리(Isolation): 에이전트마다 코드 작업 공간 분리하기

병렬 개발의 기본은 격리입니다. 에이전트별로 별도 환경을 만들어, 각자 독립 작업 공간에서만 일하게 해야 합니다. Git 워크트리를 가를 수도 있고, 폴더를 다르게 배정할 수도 있습니다. 쉽게 말해 서로의 코드를 건드리지 않게 환경부터 갈라주는 겁니다. 그래야 한 에이전트의 수정이 다른 에이전트의 작업을 망치지 않습니다.

비유로 보면 더 단순합니다. 한 주방에서 요리사 5명이 칼 하나로 요리하면 속도는커녕 사고만 나고 난리가 나겠죠. 그래서 오케스트레이터는 애초에 도마, 칼, 재료를 각자 세팅해 주는 역할부터 합니다. 작업 공간을 분리해 주면, 그제야 진짜 병렬이 됩니다.

가시성(Visibility): 지금, 누가, 뭘 하는지 보여주기

에이전트가 늘어날수록 더 무서운 건 충돌보다 깜깜함입니다. 지금 누가 뭘 하는지, 어디서 막혔는지 안 보이면 사람이 통제할 수 없습니다. 그래서 좋은 오케스트레이터의 기준은 가시성입니다. 한눈에 에이전트별 상태를 보여줘야 합니다.

예를 들면 이런 식입니다. 어떤 에이전트는 작업 중이고, 어떤 에이전트는 대기 중이며, 어떤 에이전트는 에러로 멈춰 있습니다. 또 어떤 결과물은 리뷰를 기다리고 있을 수 있죠. 원래 개발팀이라면 손이라도 들거나 메시지라도 보낼 텐데, 에이전트는 그것마저 시키지 않으면 잘 못합니다. 결국 지금 상황을 한 번에 파악하게 해주는 게 핵심입니다.

리뷰와 머지(Review & Merge): 작성자에서 통합자로 이동하기

이렇게 오케스트레이터가 잘 돌아가면 사람의 역할이 바뀝니다. 코드를 직접 치는 시간보다, 변경점 확인에 더 많은 시간을 쓰게 됩니다. 방향이 틀어지면 코멘트로 수정하고 충돌을 정리해 머지합니다. 마지막엔 “지금 릴리스해도 되는가”를 판단하겠죠.

그래서 오케스트레이터를 단순히 "에이전트 추가 버튼" 정도로 여겨서는 안 됩니다. 엄밀히 말하면 이는 개인에게 개발 팀 리드 수준의 역할을 부여하는 도구에 가깝습니다. 여러 에이전트가 만든 결과물을 모아 한 제품으로 만드는 책임이 생기니까요. 병렬 개발의 끝은 결국, 리뷰와 통합의 품질에서 갈립니다.

그럼 이제 본격적으로 이러한 일을 해주는 도구 3가지를 알아보겠습니다. 지금은 초기 단계인 만큼 각자 특성이 뚜렷하게 드러나는 편입니다. 게다가 지금 막 새로 등장한 영역인 만큼 모두가 깃헙 레포 수준으로 존재하기도 합니다. 그러니 오케스트레이터들이 어떤 방향으로 나아가고 있는지, 바라본다는 관점에서 살펴봐도 좋겠습니다.

Conductor: GUI 대시보드로 여러 에이전트를 지휘하기

Conductor는 여러 코딩 에이전트를 한 화면에서 지휘하게 해주는 도구입니다. Claude Code나 Codex를 병렬로 띄워 두고, 각 에이전트가 지금 뭘 하는지 GUI에서 확인하며 조율합니다. 터미널 창을 여러 개 띄워 감으로 관리하던 일을 관제탑 화면으로 바꿔주는 방식입니다.

Conductor

이 도구를 쓰면 뭐가 어떻게 편해질까?

오케스트레이터의 핵심은 결국 여럿을 동시에 굴리는 것이죠. Conductor는 그중에서도 가시성(대시보드)에 강점이 있습니다. 누가 어떤 작업을 맡았고, 어디서 멈췄는지 한눈에 보이면 자연스럽게 다음 지시가 빨라질 겁니다. 결과적으로 사람은 코드를 치기보다 흐름을 점검하고 우선순위를 바꾸는 쪽에 더 가까워집니다.

좋은 점은 기존 Claude Code 로그인 방식을 그대로 쓴다는 겁니다. API 키를 쓰든, Pro/Max 같은 구독을 쓰든, 익숙한 인증 흐름 위에서 돌아갑니다. 새로 계정을 파거나 별도의 복잡한 연결을 요구하지 않는 쪽에 가깝습니다.

설정도 “설치 → 바로 병렬 실행”에 가깝습니다. 처음부터 스크립트를 짜거나, tmux 세션을 설계하지 않아도 됩니다. 그래서 병렬화를 ‘한 번이라도’ 해보고 싶은 사람에게 진입 장벽이 낮습니다.

누가, 언제 쓰면 좋은가

이런 특징으로 Conductor는 터미널이나 스크립트보다, 작업을 시각적으로 관리하고 싶은 개발자에게 잘 맞습니다. 특히 “지금 뭐가 돌아가고 있지?”를 계속 확인해야 하는 상황에서요. 화면이 곧 상태판이 되니 머릿속으로 컨텍스트를 붙잡는 부담이 줄어듭니다.

예를 들어 백엔드, 프론트, 테스트처럼 서로 다른 일을 동시에 굴릴 때가 그렇습니다. 각각의 진행 상황을 ‘눈으로’ 확인하며, 막힌 곳부터 풀어주고 작업을 재배치할 수 있습니다. 인간 세상에서 Jira와 Notion으로 갖은 고생을 하며 확인하는 이유, 누가 어디까지 했지?가 덜해집니다.

만능은 아닌 Conductor의 단점

물론 만능은 아닙니다. 첫 번째 제약은 macOS 전용이라는 점입니다. 팀이 Windows나 Linux를 섞어 쓰면 도입 자체가 어려울 수 있습니다. 개인은 괜찮아도, 팀 단위 표준 도구로 삼기엔 환경 장벽이 생깁니다.

두 번째는 비용 곱셈입니다. 에이전트를 늘리면 그만큼 API 사용도 늘어납니다. 더 무서운 건, 대시보드가 편할수록 병렬 작업을 과하게 켤 유혹이 커진다는 점입니다. 별 생각없이 딸깍딸깍 켜다보면 비용이 새는 습관으로 옮겨가기 쉽습니다.

정리하면 Conductor는 병렬화를 가장 쉽게 시작하는 버튼에 가깝습니다. 대신 플랫폼과 비용이라는 현실적인 제약을 감수해야 합니다. 내 작업이 정말 병렬에 어울리는지, 그리고 그 병렬이 얼마짜리인지부터 같이 계산해보는 게 안전합니다.

Claude Squad: tmux 기반으로 터미널에서 ‘멀티플렉싱’하기

Claude Squad는 tmux 위에서 여러 개의 Claude Code를 동시에 띄웁니다. 쉽게 말해, 한 터미널 화면을 여러 칸으로 쪼개고 각 칸에 에이전트를 한 명씩 앉히는 방식입니다. 그래서 백엔드 작업을 시키는 동안 옆 칸에서는 프론트엔드 수정도 같이 굴릴 수 있습니다.

Claude Squad

이 도구를 쓰면 뭐가 어떻게 편해질까?

오케스트레이터가 보통 해결하는 건 격리·가시성·리뷰/머지 세 가지라고 했습니다. Claude Squad는 그중에서도 특히 운영의 단순함에 무게가 실려 있습니다. 별도 서버나 복잡한 UI를 올리기보다 tmux라는 이미 익숙한 도구 위에 얹는 쪽을 택했기 때문입니다. 대신 한눈에 보는 가시성 측면에서는 대시보드 대신 사용자가 터미널 화면을 관찰하며 확보하는 방식을 택했습니다.

Claude Squad에는 GUI 대시보드가 없습니다. 그런데 터미널이 익숙한 개발자라면, 이게 오히려 장점이 될 수 있습니다. 마우스로 창을 찾고 클릭하는 대신 키보드로 패널을 휙휙 넘기며 컨텍스트 스위칭(작업 맥락 전환)을 빠르게 할 수 있기 때문입니다. 관리 화면을 배우는 비용이 거의 없다는 뜻이기도 합니다.

따지자면 Claude Squad는 큰 화면 한 장 대신 여러 개의 무전 채널을 동시에 듣는 쪽에 가깝습니다. 각 에이전트의 대화와 로그가 패널마다 흘러가고, 나는 필요한 채널로 바로 들어가서 지시를 바꿉니다. 상황판은 없지만 대신 손이 빠르면 운영이 빨라집니다.

지원 환경도 실용적입니다. Mac·Linux를 지원하니 팀 내 개발 환경이 섞여 있어도 도입 장벽이 낮습니다. 게다가 오픈소스 무료라서 일단 몇 명만 써보자 같은 실험에 부담이 적습니다. 에이전트를 늘려보는 단계에서 도구 비용이 발목을 잡지 않는다는 점이 큽니다.

만능은 아닌 Claude Squad의 단점

대신 단점도 분명합니다. 상태를 한눈에 보는 대시보드가 없기 때문에 에이전트가 늘어날수록 사람의 관리 능력이 성능을 좌우합니다. 누가 무엇을 하고 있는지, 어디서 막혔는지, 지금 개입해야 하는지 등을 사용자가 직접 정리해야 합니다. 팀이 커지거나 에이전트 수가 많아지면 이 부담은 생각보다 빨리 커집니다.

또 하나는 리뷰/머지 흐름입니다. 여러 에이전트가 동시에 코드를 만들면, 결국 사람은 합치기 전에 검토하고 충돌을 정리해야 합니다. Claude Squad가 이 과정을 자동으로 매끈하게 이어준다고 기대하면 곤란합니다. 필요하다면 별도의 도구나 팀 규율로 리뷰와 머지의 리듬을 따로 설계해야 합니다.

Agent Orchestrator: 에이전트를 로컬이 아니라 ‘CI/CD 프로세스’에 붙이기

Agent Orchestrator는 에이전트를 내 로컬에서 부리는 도구에서 꺼내 CI/CD 프로세스에 붙입니다. 사람이 시키기 전에 무언가 일을 해야 할 ‘사건’이 먼저 에이전트를 부르는 구조입니다. 그래서 자동화가 필요한 팀일수록 체감이 크게 옵니다.

이 도구는 외부 서비스를 AI 에이전트에 붙여주는 Composio를 만든 ComposioHQ에서 공개한 오픈소스 레포지토리입니다. Composio 서비스 전체를 사지 않아도 쓸 수 있으니 걱정 마세요.

agent-orchestrator

이 도구를 쓰면 뭐가 어떻게 편해질까?

이 오케스트레이터를 쓴 다음, CI가 실패하면 에이전트가 먼저 로그를 읽고 원인을 찾습니다. 그리고 수정안을 만들어 PR에 반영하거나 다음 실행을 위한 커밋을 준비합니다. 사람은 왜 깨졌나 확인하는 일부터 시작하지 않아도 됩니다.

한편 리뷰어가 코멘트를 남기면, 그 코멘트가 다시 에이전트를 호출하기도 합니다. 에이전트는 지적받은 부분을 고치고, 변경 이유를 설명하는 식으로 반영합니다. 리뷰가 대화로 끝나는 대신 수정으로 이어지기 쉬워집니다. 정리하면, 사람이 에이전트에게 시키는 구조에서 이벤트가 에이전트를 호출하는 구조로 이동시켜주는 도구입니다. CI 실패, 리뷰 코멘트 같은 신호가 트리거가 됩니다. 오케스트레이터의 역할이 더 강해지는 지점이죠.

Agent Orchestrator는 YAML 양식으로 개발 자동화 흐름을 정의합니다. 그러니까 버튼을 눌러 설정하는 대신 “이런 일이 생기면 이렇게 해”를 글로 적어두는 방식입니다. 선언적으로 적어두면 팀이 커져도 흐름이 덜 흔들립니다.

지원하는 에이전트 폭도 넓습니다. Claude Code만이 아니라 Codex, Aider까지 연결해 쓸 수 있습니다. 팀이 이미 쓰는 에이전트가 제각각이어도 한 흐름으로 묶기 좋습니다.

누가, 언제 쓰면 좋은가

테스트/린트/빌드/리뷰가 어느 정도 표준화된 팀에 잘 맞습니다. 반복 작업이 많고, 깨지면 고치고 다시 돌리는 루틴이 잦을수록 효과가 큽니다. 이런 코드 수정의 자동화는 결국 반복이 많을 때 가장 빨리 이득이 납니다.

특히 “실패 처리”가 많은 프로젝트에서 빛을 봅니다. 예를 들어 레거시, 의존성 지옥, flaky test처럼 자주 흔들리는 환경입니다. 이런 곳은 사람의 집중력이 먼저 닳기 때문입니다.

만능은 아닌 Agent Orchestrator의 단점

물론 당연히 모든 일을 처리해 주지는 않겠죠. CI/CD에 자동으로 개입한다는 건 범위가 넓은 일입니다. 그만큼 당연히 초기 설정이 복잡해질 수 있습니다. 처음에 흐름을 잘못 잡으면, 자동화가 오히려 혼란을 키울 거고요. 그래서 도입 초반에는 작은 범위부터 시작하는 편이 안전합니다.

또 프로덕션/조직 환경에서는 권한 관리가 더 중요합니다. 에이전트가 무엇을 어디까지 수정할 수 있는지를 명확히 해야 합니다. 접근 범위를 넓게 주는 순간, 잠시 편의성이 생길지 몰라도 리스크가 무지막지하게 커집니다.

물론 오케스트레이터를 무조건 써야 하는 건 아닙니다

오케스트레이터 도입의 ROI는 결국 “도구가 좋아서”가 아닙니다. 내가 하는 일 중에서 병렬로 쪼개도 되는 일의 비율이 얼마나 되느냐에 달려 있습니다. 동시에 돌려야 하는 덩어리가 많으면 Conductor나 Claude squad가 빛을 봅니다. 반면 쪼갤 게 적으면 오케스트레이터를 도입하는 체감이 없습니다. 오히려 비용과 운영 복잡도만 늘 수 있죠.

병렬화는 공짜가 아니다

많이들 오케스트레이터나 코딩 에이전트의 하네스를 얹어주는 도구를 볼때, 그 도구 자체의 가격부터 봅니다. 그런데 실제로 더 크게 튀는 건 코딩 에이전트 그 자체의 사용 가격입니다. 에이전트가 늘수록 호출이 곱셈으로 늘어나기 때문입니다. 도구 비용이 아니라 돌리는 만큼 나가는 비용이 핵심입니다.

중간 규모 기능 하나만 잡아도 수동 대비 호출이 한참 더 나올 수도 있습니다. 사람이 한 번에 끝낼 흐름을 에이전트는 더 잘게 쪼개 확인할 수 있으니까요. 그 과정에서 요청과 응답도 계속 쌓입니다. 에이전트를 5개 돌리면, 비용도 사실상 확실히 커진다는 뜻입니다.

물론 항상 정확히 5배는 아닙니다. 하지만 아무리 정해진 Max 요금제를 써도 토큰이 선형으로 증가한다는 감각이 오를지도 모릅니다. 병렬화는 속도를 사는 대신 호출을 더 사는 구조입니다.

왜 호출이 늘어나며 머리가 아파오는가

사람 1명이 하던 생각과 탐색 과정을 떠올려 보겠습니다. 코드를 읽고, 가설을 세우고, 한 번 고치고, 다시 확인하죠. 병렬화에서는 이 과정이 에이전트마다 각자 반복됩니다. 즉, 한 사람이 한 번 하던 루프가 여러 번 돌아갑니다.

게다가 에이전트는 보통 격리된 작업 공간에서 일합니다. 그러면 각자 빌드하고, 각자 테스트하고, 각자 컨텍스트를 다시 확인합니다. 같은 저장소라도, 서로 다른 방에서 따로 작업하는 셈입니다. 이게 안정성을 주는 대신, 호출과 로그를 폭증시킵니다.

한편, 이를 다루는 사람의 입장도 생각해야 합니다. 이렇게 복잡한 사고 흐름을 모두 따라가는 건 당연히 매우 어렵습니다. 더 많은 일을 시키지 못하는 것보다 두려운 건 어느 순간 그 일을 따라잡지 못하는 겁니다.

비용을 통제하는 운영 팁

첫 번째는 모델 분배입니다. 이를테면 복잡한 추론은 Opus에 맡기고, 단순 수정은 Sonnet/Haiku로 내립니다. 쉽게 말해 어려운 일은 비싼 사람, 쉬운 일은 저렴한 사람한테 부탁하는 거죠. 이 한 가지만 해도 비용 곡선이 달라집니다. 꼭 오케스트레이터가 아니어도 비슷할 겁니다.

두 번째는 무조건 병렬을 버리는 겁니다. 병렬화 가치가 큰 작업부터 쪼개야 합니다. 예를 들어 아래처럼 경계가 명확한 것부터 나누는 식입니다.

프론트 UI 작업
백엔드 API 작업
테스트 작성 작업

이렇게 나누면 오케스트레이터의 장점이 바로 나옵니다. 서로 코드가 덜 부딪히고 합치는 과정도 단순해집니다. 반대로 경계가 흐린 작업을 억지로 병렬화하면 호출만 늘고 머지만 어려워집니다. 물론 이를 명확하게 설계하고 분배하는, 소위 말해 "기획" 단의 일이 더 중요해 지겠죠.

마치며

오케스트레이터를 단순 ”에이전트를 한 명 더 고용하는 도구”로 보면, 기대가 자주 어긋납니다. 핵심은 에이전트 수를 늘리는 게 아니라 여럿이 만든 결과물을 충돌 없이 통합하는 데 있습니다. 다섯 명이 동시에 코드를 만지면 생산성보다 먼저 “누가 뭘 했지?”와 “어디서 꼬였지?”가 문제로 떠오르거든요. 오케스트레이터는 그 혼선을 줄여서 사람이 마지막에 깔끔하게 합칠 수 있게 돕습니다.

그런 관점에서 가시성이 필요하면 Conductor가 잘 맞습니다. 화면에서 에이전트들이 뭘 하고 있는지, 어디서 막혔는지 흐름을 잡기 쉽습니다. 터미널 중심으로 일한다면 Claude Squad가 더 자연스럽습니다. GUI 대신 터미널에서 여러 Claude Code 세션을 병렬로 다루는 방식이라 손이 덜 바뀝니다. 한편 CI까지 묶어 PoC를 잡고 싶다면 Agent Orchestrator로 시작하는 편이 낫습니다. 단순히 에이전트를 띄우는 걸 넘어 자동화 흐름 자체를 붙일 수 있기 때문입니다.

그 무엇이든 오케스트레이터의 진가는 여러 기능을 동시에 개발할 때, 대규모 리팩토링처럼 할 일이 산더미인 경우에 좋습니다. 바꾸어야 할 파일이 많고, 작업 단위가 반복적일수록 병렬화 이득이 커집니다. 이때 오케스트레이터는 속도를 올리는 도구라기보다, 합치는 비용을 통제하는 도구가 되니까요.

다시 한 번 돌이켜 보지만, 결국 중요한 건 에이전트 숫자가 아니라 통합할 수 있는 작업의 구조를 먼저 만드는 일입니다.

]]>

page-agent — 코드 한 줄로 웹페이지에 AI 에이전트 추가하는 법

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: page-agent - 코드 한 줄로 웹페이지에 AI 에이전트 추가하는 법
참고할 것: Claude Code에 코드 리뷰를 얹다
적용해볼 것: 가속의 10년을 버티는 11가지 방법

<출처: page-agent>

1. 써볼 것: page-agent - 코드 한 줄로 웹페이지에 AI 에이전트 추가하는 법

page-agent는 Alibaba가 만든 오픈소스 JavaScript 라이브러리입니다. 웹페이지에 스크립트 한 줄만 추가하면 AI 에이전트가 그 페이지 안에서 DOM을 직접 제어합니다. Hacker News에서 화제가 됐고, 작성 기준 GitHub 스타 5,100개를 넘겼습니다.

기존 browser-use, Playwright, Selenium은 브라우저를 바깥에서 제어합니다. 별도 서버나 Python 스크립트, 헤드리스 브라우저를 띄워야 하죠. page-agent는 방향이 다릅니다. 에이전트가 페이지 안에 살면서, 사용자가 쓰는 브라우저 세션을 그대로 씁니다. 로그인 상태도 공유되고, 별도 인증도 필요 없습니다.

무슨 문제를 해결해 주나요?

AI 코파일럿을 SaaS 제품에 붙이려면 보통 꽤 많은 작업이 필요합니다. 백엔드를 수정하고, 별도 인프라를 구성하고, 권한 문제를 해결해야 하죠. Notion, Salesforce, HubSpot 같은 회사들이 월 $20~30에 파는 AI 코파일럿 기능이 바로 이 작업의 결과물입니다.

page-agent는 이 복잡함을 코드 몇 줄로 줄입니다. 스크립트를 추가하고, LLM API 키를 연결하면 끝입니다. 백엔드 수정도, 새 인프라도 필요 없습니다. 스크린샷이나 OCR, 멀티모달 LLM도 필요 없고요. 텍스트 기반 DOM 조작만으로 동작하기 때문에 더 가볍습니다.

한국어 번역을 돌린 이미지입니다. <출처: page-agent>

어떻게 쓰나요?

가장 빠르게 써보려면 북마클릿을 활용하면 됩니다. alibaba.github.io/page-agent에서 북마클릿을 등록하면 아무 웹페이지에서나 바로 테스트할 수 있습니다. API 키 설정 없이 무료 데모 API가 제공되고요.

저는 설치 대신, 북마클릿을 등록해서 써봤는데, 요즘 프로덕트 메이커 작가 페이지에 접속해 [최신 글에 들어가서 달린 댓글에, 감사합니다! 라고 댓글 달아줘]라는 자연어 명령을 입력했습니다. 이후 에이전트가 스스로 페이지를 스크롤하면서 최신 글을 찾고, 댓글 위치를 파악해서 답글을 다는 과정을 볼 수 있었죠. 크롬 확장프로그램 설치 하나로, 웹 페이지가 조작되는 모습을 보니 신기합니다.

흐름을 이미지로 보면 이렇습니다 <출처: 작가>

흐름을 움짤로 보면 이렇습니다. (움짤 길이 사정상 약간의 컷편집이 들어갔습니다) <출처: 작가>

기존 웹페이지에 바로 붙이고 싶다면 CDN 스크립트를 한 줄 추가하면 됩니다. 별도 설치 없이 동작하고, 무료 데모 API도 그대로 쓸 수 있습니다.

빠른 체험 (데모 CDN)
데모 CDN은 무료 테스트용 LLM API를 사용하며, 사용 시 이용 약관에 동의한 것으로 간주됩니다.

<script src="https://cdn.jsdelivr.net/npm/page-agent@1.5.6/dist/iife/page-agent.demo.js" crossorigin="true"></script>

프로젝트에 직접 붙이려면 npm으로 설치합니다.

NPM 설치

// npm install page-agent

import { PageAgent } from 'page-agent'

import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  apiKey: 'YOUR_API_KEY',
  language: 'en-US',
})

// 코드로 직접 명령
await agent.execute('로그인 버튼 클릭하고, 사용자 이름을 홍길동으로 입력해줘')

// 또는 사용자가 직접 입력할 수 있는 패널 띄우기
agent.panel.show()

자연어로 명령하면 에이전트가 페이지 구조를 파악해서 해당 요소를 찾고 실행하는 플로우며, 꽤나 신기합니다. OpenAI, Claude, DeepSeek, Qwen은 물론 Ollama로 완전 오프라인도 되고, Chrome 확장 프로그램을 설치하면 여러 탭에 걸친 작업도 가능합니다.

누구에게 좋을까요?

사이드 프로젝트나 내부 도구에 AI 코파일럿 기능을 빠르게 붙여보고 싶은 개발자
ERP, CRM 같은 반복적인 폼 입력 워크플로를 자동화하고 싶은 사람
에이전트가 웹 인터페이스를 제어하는 방식을 실제로 구현해보려는 사람
AI 에이전트를 기존 웹앱에 연동하는 아키텍처를 탐구 중인 팀

다만 몇 가지 알아두면 좋은 점이 있습니다. 현재 베타 단계라 API가 언제든 바뀔 수 있어서 프로덕션 환경에는 아직 쓰지 않는 게 좋습니다.

보안 측면에서는 에이전트가 페이지 안의 모든 요소에 접근할 수 있는 구조라 민감한 버튼이나 결제 기능에 대한 제어가 중요합니다. 다행히 page-agent는 이를 위한 장치를 제공합니다. 삭제 버튼이나 결제 버튼처럼 AI가 건드리면 안 되는 요소는 차단 목록으로 막을 수 있고, 반대로 AI가 조작할 수 있는 요소를 허용 목록으로 명시적으로 지정하는 것도 됩니다. 위험도가 높은 작업은 완전히 금지하거나, 중간 수준의 작업은 사용자 확인을 거치도록 설정할 수 있고요.

백엔드 자동화나 클라우드 브라우저 원격 제어가 목적이라면 browser-use나 Playwright가 더 맞습니다. page-agent는 사용자가 쓰는 페이지 안에서 동작하는 구조라 서버 사이드 자동화에는 적합하지 않습니다.

<출처: Claude 유튜브>

2. 참고할 것: Claude Code에 코드 리뷰를 얹다

Claude Code 코드 리뷰는 Anthropic이 3월 9일 발표한 Claude Code의 새 기능입니다. PR이 열릴 때마다 에이전트 팀을 투입해 버그를 병렬로 탐색하고, 오탐을 걸러낸 뒤 심각도 순으로 정리해 PR 코멘트로 전달합니다. Team/Enterprise 플랜 대상 리서치 프리뷰로 현재 베타 운영 중입니다.

이는 Anthropic 내부에서 먼저 만들어 수개월간 쓰다가 공개한 기능이라고 하는데요. 이 시작점은 Anthropic 내부에서 엔지니어 1인당 코드 생산량이 지난 1년간 200% 늘었는데, 리뷰 속도는 그만큼 따라가질 못했던 거였죠.

기존 코드 리뷰와 무엇이 다른가요?

코드 리뷰는 개발팀에서 오랫동안 병목이었습니다. AI가 코드를 더 빠르게 쓸수록 병목은 더 심해지고요. 결국 바쁜 리뷰어가 PR을 훑어보기만 하다가 중요한 문제를 놓치는 일이 생깁니다. 기존에도 Claude Code GitHub Action 같은 가벼운 자동화 도구는 있었습니다. 하지만 이번 코드 리뷰는 방향이 조금 다릅니다. 속도보다 깊이에 최적화했고, 에이전트 여러 개가 팀처럼 병렬로 버그를 찾습니다. 비용이 높은 대신 훨씬 철저하게 들여다보는 구조이죠.

어떻게 작동하나요?

PR이 열리면 우선 에이전트 팀이 배치됩니다. 각 에이전트가 병렬로 버그를 탐색하고, 발견된 버그를 서로 검증해서 오탐을 걸러냅니다. 심각도 순으로 순위를 매기고, PR에 전체 요약 코멘트 하나와 버그별 인라인 코멘트로 전달합니다. PR 크기에 따라 투입되는 에이전트 수와 분석 깊이가 자동으로 조정되고, 평균 리뷰 소요 시간은 약 20분입니다. PR을 승인하는 건 여전히 사람의 몫입니다. 에이전트는 발견하고 알려주는 역할이고, 최종 판단은 리뷰어가 합니다.

무슨 일이 벌어지고 있나요?

Anthropic 내부 데이터가 흥미로운데요. 도입 전에는 PR의 16%만 실질적인 리뷰 코멘트를 받았지만, 도입 후에는 54%로 올랐다고 합니다. 1,000줄 이상 대규모 PR에서는 84%가 버그를 발견했고, 평균 7.5개 이슈를 보고했고요. 오탐으로 표시된 비율은 1% 미만이었습니다.

Anthropic 내부 사례도 있었는데요. 프로덕션 서비스에서 코드 한 줄을 바꾸는 PR이었고, 변경량이 적어서 평소라면 빠르게 승인됐을 겁니다. 그런데 코드 리뷰가 이걸 심각한 문제로 표시했고, 확인해보니 서비스 인증을 깨뜨릴 수 있는 버그였다고 합니다. 다행히 머지 전에 잡았다네요. (담당 엔지니어는 혼자였다면 놓쳤을 거라고 했습니다)

무엇을 얻어가야 하나요?

지금은 Team/Enterprise 플랜 베타라 직접 쓰기 어려울 수 있습니다. 하지만 구조 자체가 흥미로워 살펴봤습니다. 에이전트 하나가 아니라 여러 에이전트가 팀처럼 투입되고, 서로 검증하면서 오탐을 줄이는 방식입니다. 비용은 PR당 평균 $15~25로, 대규모 PR일수록 높아집니다.

프로덕트 메이커 입장에서 핵심은 이겁니다. AI가 코드를 더 빠르게 만들수록 리뷰가 병목이 된다는 문제는 이미 많은 팀이 겪고 있습니다. Anthropic은 그 병목을 에이전트 팀으로 해결했고, 수치로 검증했습니다. 우리 팀의 병목이 어디인지 생각해보면 같은 패턴이 적용될 곳이 보일 수 있습니다.

<출처: Scott Barke>

3. 적용해볼 것: 가속의 10년을 버티는 11가지 방법

Scott Barker는 10년간 핀테크, 소프트웨어, 미디어, 벤처캐피탈을 거쳐 VC 펀드 공동창업까지 한 사람입니다. 그리고 번아웃으로 시스템 전체가 무너졌습니다. 약 없이는 집중도, 수면도, 이완도 안 되는 상태에 도달했다고 했습니다. 2026년 2월 18일 Substack에 올린 글이 현재 기준 좋아요 4,221개, 공유 1,140회를 기록했습니다.

그가 이 글을 쓴 이유는 자신이 겪은 게 예외가 아니라 곧 보편이 될 거라고 봐서입니다. AI가 코드 생산량을 200% 늘리고, 에이전트가 PR을 리뷰하는 세상에서 인간의 신경계는 그 속도를 따라가도록 설계되지 않았다는 게 요지죠.

무슨 문제를 해결하려 하나요?

기술의 본질적 역할은 시간을 압축하는 것, 즉 원하는 것과 얻는 것 사이의 거리를 줄이는 것입니다. 과거에는 발명과 채택 사이에 완충 구간이 있어서 인간이 적응할 시간이 있었습니다. 농업혁명은 수천 년, 인쇄기는 1세기, 전기화는 40년이 걸렸습니다. ChatGPT는 1억 사용자에 2개월이 걸렸고요. 그 완충 구간이 사라졌습니다. 그가 가속의 10년이라고 부르는 시기가 지금 시작되고 있습니다.

어떻게 준비하나요?

Scott이 공유한 11가지를 프로덕트 메이커 관점에서 핵심만 추립니다.

감속을 전략으로 삼기
AI가 속도를 높여주는 환경에서 방향 전환 없이 계속 가속만 하면 원하는 곳에 도달하지 못합니다. 시속 100마일로 달리는 차에서 우회전을 하려면 가속이 아니라 감속이 필요하듯이요. 앞으로는 가속 자체가 환경이 알아서 해줄 거라 언제 감속할지를 아는 게 오히려 경쟁력이 됩니다.
→ 한 달에 한 번, 오후 하나를 비워서 6시간 동안 아무것도 소비하지 않는 침묵 시간을 가져보기
표면 기술보다 깊이 쌓기
평생 쌓은 기술을 초보자가 AI로 몇 분 만에 80%까지 따라잡는 시대가 이미 왔습니다. AI가 평탄화하지 못하는 역량은 따로 있습니다. 판단력, 취향, 분야 간 연결력, 스토리텔링, 도덕적 추론입니다. 이것들은 삶의 경험과 실패, 많은 성찰 시간이 있어야 쌓입니다.
→ 성공이란 무엇인가, 의미 있는 삶이란 무엇인가 중 하나를 골라 14일간 철학·과학·역사·개인 경험의 렌즈로 깊이 탐구해보기
신경계 훈련하기
명상, 침묵, 긴 산책, 수면 규율, 자연, 디지털 단절. 과거에는 스트레스 관리 정도로 여겼던 것들이 앞으로는 필수 역량이 됩니다. 가속이 계속될수록 압도감을 해결해준다는 솔루션들이 넘쳐날 텐데, 대부분 환경이 아닌 개인에게 문제가 있다고 말합니다. 기준은 하나입니다. 신경계를 조절하는 데 필요한 것은 전부 무료이고 언제든 쓸 수 있습니다. 그 외의 것은 대부분 눈속임입니다.
→ 움직임, 고요함, 호흡, 고독을 포함하는 매일 1시간 수련 만들기
반취약한 정체성 구축하기
Nassim Taleb의 반취약성은 충격을 받아도 깨지지 않고 오히려 더 강해지는 시스템을 말합니다. 단순히 버티는 게 아니라 혼란 자체에서 이득을 얻는 구조입니다. 정체성을 직업에 과도하게 묶으면, 그 직업이 사라질 때 정체성도 함께 무너집니다. 나는 변호사다, 나는 개발자다가 아니라 나는 새로운 환경에서 배우고 적응하고 번성할 수 있는 사람이다로 바꾸면, 변화 자체가 위협이 아니라 이득이 됩니다.
→ 자신의 정체성 라벨 다섯 개를 적고 전부 지워보기. 이것이 전부 사라지면 나는 여전히 누구인가?
신호와 잡음 구분하기
AI가 생성하는 콘텐츠, 뉴스, 합성 미디어는 이제 겨우 시작입니다. 조만간 광고, 뉴스레터, 영상이 인터넷이 나에 대해 알고 있는 모든 정보를 기반으로 1대1로 개인화될 겁니다. 정보가 많아질수록 무엇이 진짜 중요한지 구분하는 능력이 힘이 됩니다.
→ 지난 48시간 동안 소비한 것을 전부 나열하고 세 가지를 물어보기. 내 사고를 지속적으로 바꿨는가? 30일 후에도 기억할 것인가? 더 나은 결정에 영향을 줬는가? 셋 다 아니면 잡음입니다.
성공의 정의 다시 쓰기
의식적으로 정의하지 않으면 알고리즘이 대신 답을 내립니다. Scott은 돈과 지위를 성공으로 정의했고 모두 달성했지만 더 충족되지 않았다고 했습니다. 어릴 때 정의한 성공이 지금도 유효한지 점검해볼 필요가 있습니다.
→ 나는 ____일 때 성공했다고 느낄 것이다를 완성하고, 각 항목에 이게 중요하다고 누가 가르쳤는가를 물어보기
더 긴 시간 지평으로 생각하기
가속은 반응에 보상을 줍니다. 하지만 진짜 진화는 인내에 보상을 줍니다. 하루·주·월 단위가 아닌 10년 단위로 생각하는 게 의미 있는 삶을 만드는 경쟁적 해자라고 그는 말합니다.
→ 실현에 최소 10년이 걸리는 프로젝트를 하나 정해서 전념하기

나머지 네 가지, 진정한 연결에 투자하기 / 냉소주의에 굴복하지 않기 / 자신이 치르는 거래 분석하기 / 신을 찾기는 원문에서 더 깊게 읽을 수 있습니다.

한 가지 덧붙이자면, 이 글에는 비판적인 댓글도 달렸습니다. 감속을 선택하고 10년짜리 프로젝트에 전념하는 건 어느 정도 여유가 있어야 가능한 이야기라는 지적이었습니다. Scott 본인도 이 비판에 동의했고요. 모든 사람에게 똑같이 적용되는 처방은 아닐 수 있다는 점은 읽으면서 염두에 둘 만합니다.

적용해볼 질문

AI가 내 작업 속도를 높여주고 있다면, 그 빨라진 시간을 나는 어디에 쓰고 있나요? 더 많은 작업을 하는 데 쓰고 있다면, Scott이 말하는 패턴과 같은 방향입니다. 표면 기술이 AI로 빠르게 대체되는 시대에, 지금 내가 쌓고 있는 것은 판단력과 깊이인가요, 아니면 더 빠른 실행력인가요?

실행해볼 수 있는 것

이번 주에 쓰는 AI 도구 한 가지를 골라서 그게 조용히 빼앗아 가는 것이 무엇인지 써보세요. 속도를 주는 대신 무엇을 외주화하고 있는지 적어보는 겁니다.
내가 매일 소비하는 콘텐츠 중 30일 후에도 기억할 것이 얼마나 되는지 체크해보세요. 잡음과 신호를 구분하는 기준을 하나라도 만들어두면, 가속이 빨라질수록 그 기준이 더 유용해집니다. (요즘 프로덕트 메이커 콘텐츠도 예외는 아닙니다.)

정리

page-agent와 Claude Code 코드 리뷰는 같은 방향을 가리킵니다. AI에게 더 많이 맡기는 방법이죠. 코드 한 줄로 에이전트를 웹페이지에 심고, 에이전트 팀이 PR을 병렬로 검토합니다. 맡길 수 있는 범위가 계속 넓어지고 있습니다. Scott Barker의 글은 그 반대편 질문을 던집니다. 무엇은 맡기면 안 되는가. AI가 80% 수준을 대체하는 시대에 나머지 20%가 무엇인지 모르면, 맡기는 것과 잃는 것을 구분하기 어려워집니다.

도구는 앞으로도 계속 나올 겁니다. 그러기에 우리는 더욱 분명히 해야할 것이 있습니다. AI한테 맡길 것과 내가 직접 결정할 것, 그 경계를 아는 것이죠.

이렇게 적용해보세요

내 웹앱이나 내부 도구에 AI 코파일럿 기능을 붙이고 싶었다면, page-agent 북마클릿으로 먼저 아무 페이지에서나 어떻게 동작하는지 확인해보세요. 설치 없이 바로 됩니다.
AI가 내 코드 생산량을 높여줬다면, 리뷰가 병목이 되고 있지는 않은지 살펴보세요. Claude Code 코드 리뷰 구조처럼, 에이전트를 여러 개 투입해서 서로 검증하게 하는 패턴은 코드 외에도 쓸 수 있습니다.
이번 주 AI로 아낀 시간을 어디에 썼는지 돌아보세요. 또 다른 작업으로 채웠다면, 내가 그걸 선택한 건지 아니면 그냥 그렇게 됐는지 생각해보세요. Scott이 경고한 건 바쁜 것 자체가 아니라, 왜 바쁜지 모르는 것이니까요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

Claude Code가 미친듯이 일할 때, 나는 뭘 할까?

요즘 저는 하루 내내 Claude Code와 같이 일합니다. 덕분에 이전이면 절대 하기 어려웠던 일을 해보고 있는데요, 그대신 묘하게 붕떠 있다는 느낌을 많이 받습니다. 그 느낌이 어디서 올까 찾다 보니, 프롬프트를 던지고 나서 답을 받기까지 2~10분이 그 감각을 주었다고 생각하게 되었습니다. 2~10분. 기다리기엔 길지만, 그렇다고 새 일을 열기엔 짧은 시간입니다. 메일을 열었다가 닫고 탭을 몇 개 넘기다 보면 어느새 결과가 나와 있죠. 문제는 그 애매한 시간 사이에 남는 게 별로 없다는 겁니다.

이런 상태, 작은 전환이 계속 쌓여 뇌가 지치는 현상을 부르는 신조어도 생겼습니다. 하버드 비즈니슈 리뷰(HBR)는 이를 Brain Fry라고 부릅니다. 이 현상이 생기는 이유는 화면을 옮기고, 맥락을 다시 잡고, 다시 돌아오는 데 드는 전환 비용이 생각보다 크기 때문입니다. 집중력은 깨지는데 성취감은 없으니 더 피곤해집니다.

해결책을 찾아보기로 했고, 찾아낸 방법은 거창한 생산성 설계와 무지막지한 전환이 아니었습니다. 이 애매한 시간을 무작정 그때그때 잘 써보자 하지 말고, 적당한 메뉴판으로 만들어 두기로 한 겁니다. 그래서 이 시간을 4개의 행동 카테고리로 나눠 미리 준비해 보기로 했습니다. 생각 확장, 지식 수집·소통, 보여주기, 회복. 딱 이 네 가지입니다.

<출처: 작가, Gemini로 제작>

에이전트 대기 시간은 왜 그렇게 애매할까?

Claude Code에 프롬프트를 던지고 기다리는 그 시간이 더 지치는 이유가 있습니다. 이 시간이 ‘짧아서’가 아니라 다시 몰입하는 비용이 생각보다 크기 때문입니다. 물론 짧을수록 특히 더 그렇습니다. 때로는 화면을 잠깐 닫았다가 다시 열고, 지금 어디까지 했는지 파악하고, 다시 집중 모드로 들어가는 워밍업이 2분보다 더 걸립니다. 2분짜리 쉬는 시간이 아니라 2분짜리 “열기 버튼”이 계속 눌리는 느낌입니다. 그래서 이 시간을 뭔가로 꽉 채우려 하면 남는 건 결과보다 피로입니다.

10분은 또 다르게 애매합니다. 막상 새 태스크에 발을 담그면, 중간에 끊기가 싫어집니다. “아, 이제 감 잡았는데” 싶은 순간이 오거든요. 그런데 에이전트가 돌아오면 다시 원래 일로 복귀해야 하고, 새 태스크는 미완성 스트레스로 남습니다.

Brain Fry의 메커니즘

이를 지칭하는 용어인 Brain Fry를 이해하려면 우리 뇌를 브라우저 탭으로 비유하면 이해가 쉽습니다. 탭 하나 여는 건 쉽지만, 탭을 열고 닫을 때마다 우리는 “어디까지 봤지?”를 다시 찾는 비용이 들죠. 이 비용이 쌓이면, 컴퓨터가 점점 렉 걸리듯 머리도 느려집니다.

대기 시간마다 탭을 무작위로 바꾸는 습관을 들이면 문제가 생깁니다. 2분마다 뉴스 탭, 메신저 탭, 문서 탭을 왔다 갔다 하면 뇌는 계속 새로고침을 합니다. 그러다 보면 어느 순간 RAM이 터지는 느낌이 납니다. 집중은 깨지는데 성취감은 없어 더 피곤해지는 겁니다. 그게 바로 Brain Fry입니다.

자투리 시간 운영 원칙

그래서 짧은 시간에 큰 성과를 내는 법은 일부러 배제했습니다. 대신 전환 비용이 낮은 행동만 하자는 쪽입니다. 시작과 종료가 가볍고, 다시 돌아올 때 흔적이 남는 일들입니다. 대기 시간은 미니 프로젝트가 아니라 미니 동작으로 다뤄야 합니다.

또 하나의 원칙으로, 모든 일을 한쪽으로만 채우지 않았습니다. 결과물이 남는 것도 필요하지만 회복이 되는 것도 중요합니다. 생산성 나는 기록만 하다 보면 지치고, 쉬기만 하면 불안해지니까요. 둘을 같이 준비해두면 그날 컨디션에 맞춰 고르기 쉬워집니다.

마지막으로, 에이전트 주기에 맞춰 행동을 쪼갭니다. 타이머를 맞추란 말이 아니라 적당히 하고 돌아올 때 미련 없는 단위로 하는 겁니다. 이런 원칙으로 메뉴판을 만들어야 애매한 남는 시간이 덜 애매해집니다.

메뉴판 1. 코드는 맡겼으니, ‘코드 너머’를 스케치하기

코드를 에이전트에게 맡기고 많은 사람이 다시 코드로 돌아가려 합니다. 하지만 지금은 오히려 코드 너머를 보기 좋은 타이밍입니다. 이 구간의 활용법을 딱 하나로 줄이면 구조를 스케치하기입니다.

왜 지금이 ‘구조를 보는 타이밍’인가

에이전트는 개별 단위 최적화에 강합니다. 쉽게 말해 함수 하나를 더 깔끔하게, 에러 하나를 더 확실하게 같은 작업을 잘합니다. 여기에 코드 작성 자체는 속도도 빠르고 집중도도 흔들리지 않습니다. 사람이 옆에서 끼어들면 오히려 흐름이 깨질 때가 많습니다.

반대로 인간은 보다 넓은 단위 최적화에 강합니다. 전체 구조가 어떤 모양이어야 하는지, 데이터가 어디서 어디로 흘러야 하는지, 제품 의도가 무엇인지 같은 큰 그림을 잘 그린다는 겁니다. 그러니까 부품을 잘 깎는 것보다 어떤 제품을 만들지 정하는 것에 더 강합니다. 한편 이건 키보드를 두드리는 시간보다 잠깐 멈춰서 보는 시간이 필요합니다.

그래서 에이전트를 돌리는대기 시간은 둘의 역할이 충돌하지 않는 구간입니다. 에이전트가 코드를 짜는 동안, 내가 코드에 손대지 않으면 됩니다. 대신 나는 구조를 그리거나 다음 질문을 준비하면 됩니다. 둘이 같은 레일에서 달리지 않으니 서로 발을 걸 일이 없습니다.

2분짜리 산출물은 조감도 1장

여기서 목표는 거창한 아키텍처 문서가 아닙니다. 박스 5개 이내로 끝내는 조감도 1장입니다. 박스는 보통 컴포넌트(화면, API, DB 같은 덩어리)로 잡습니다. 그리고 화살표로 데이터 흐름을 그립니다. 마지막으로 이 박스는 저 박스에 의존한다 같은 의존성만 표시합니다.

조감도 옆에는 질문 정도만 적어봐도 충분합니다. 예를 들면 로그인은 어디서 검증하지?, 에러는 사용자에게 어떻게 보여주지?, 캐시는 어디에 둘까? 같은 질문입니다. 이 3개가 다음 프롬프트의 재료가 됩니다.

꼭 개발이 아니어도 됩니다. 화이트보드에 설계를 펼쳐놓는다는 개념이 중요합니다. 비개발자라면 무엇을 시킬지 자기 일의 흐름을 그려볼 수 있겠죠.

화이트보드 Excalidraw와 협업 캔버스 Miro

화이트 보도 도구: Excalidraw, Miro

Excalidraw는 손그림 감성의 화이트보드입니다. 중요한 포인트는 예쁘게 그려야 한다는 압박이 없다는 겁니다. 선이 삐뚤어도 자연스럽고, 대충 그려도 어색하지 않습니다.

이 프로덕트를 쓰는 진짜 목적은 도구 목적 그 자체가 아닙니다. 아키텍처 스케치를 2분에 끝내는 의식을 만드는 겁니다. 에이전트를 돌리면 자동으로 캔버스를 열고 박스 3~5개를 그려봅니다. 그리고 질문 3개를 적고 닫습니다. 이 리듬이 생기면 남는 시간이 덜 새어 나갑니다.

MCP 서버로 AI가 스케치를 자동 생성하는 방향이 가능한 것이 가장 큰 장점입니다. 내가 그릴 초안을 AI가 먼저 만들어주는 방식입니다. 요즘은 이런 거 없으면 쓰기 싫으니까요. 스케치 자체에 드는 시간을 더 줄이는 선택지입니다. 다만 핵심은 자동화가 아니라 내가 구조를 보는 습관을 놓치지 않는 것입니다.

비슷하지만, 좀 더 유명한 Miro는 팀 협업형 무한 캔버스에 가깝습니다. 개인 스케치보다 팀이 같이 보는 판이 필요할 때 좋습니다. 특히 스티커 노트로 다음 태스크를 던져두기 좋습니다. 에이전트가 끝났을 때, 할 일이 이미 캔버스에 줄 서 있게 만드는 도구라고도 볼 수 있습니다.

완성보다는 작은 보완

이 방식의 장점은 전환 비용이 줄어든다는 점입니다. 에이전트 종료 시점에 이제 뭐 하지?를 고민하지 않아도 됩니다. 다음 행동이 이미 준비돼 있으니 맥이 끊기지 않습니다. 짧은 대기 시간에서 가장 아까운 건 작업을 멈추는 것이 아니라 ‘다음 행동을 정하는 시간’이니까요.

그러니까 완성 대신 다음 프롬프트를 더 똑똑하게 만드는 재료를 생산하는 시간으로 봅시다. 조감도 1장과 질문 3개면 충분합니다.

메뉴판 2. 멍청하게 스크롤하지 말고 제대로 지식 쌓기

이때 흔히들 글을 읽거나 지식을 채우고는 합니다. 다만, 이 자투리 시간에 제대로 읽으려는 시도는 거의 실패합니다. 막 집중하려 해도 Claude Code가 일을 끝내면 다시 맥이 끊기기 때문입니다. 그래서 이 구간의 목표는 학습이 아니라 큐레이션(나중에 읽을 거리 정리)입니다.

재밌는 글을 북마크하고, 왜 저장했는지 한 줄 메모를 남기고, 나중에 찾기 쉽게 태그를 붙입니다. 이렇게만 해도 다음에 긴 시간을 잡았을 때, 뭘 읽지? 헤매지 않습니다.

적합한 지식 쌓는 사이트 3가지

지식 쌓는 도구: Daily.dev, Hacker News, 요즘IT

습관을 바꾸는 가장 쉬운 방법은 들어가는 문을 바꾸는 겁니다. 트위터를 끊겠다고 결심하는 것보다, 새 탭을 열었을 때 보이는 화면을 바꾸는 편이 훨씬 쉽습니다. 아래 도구들은 그 진입점을 기술 지식 쪽으로 살짝 옮겨줍니다. 중요한 건 많이 읽는 게 아니라 좋은 글을 다음으로 넘기는 시스템을 만드는 겁니다.

daily.dev: 크롬 새 탭을 기술 뉴스 피드로 고정합니다. 그러면 무의식적으로 열던 새 탭이 곧바로 학습의 입구가 됩니다. 글은 하나만 읽고, 재밌으면 북마크만 남깁니다.

Hacker News: 여기서 얻는 건 도구 목록이 아니라 반복되는 “문제-해결” 패턴입니다. 포인트는 기사보다 댓글이 본체라는 점입니다. 실무자들이 어디서 막혔는지, 어떤 대안이 있는지가 댓글에 나옵니다.

요즘IT: 한국어 실무 콘텐츠를 빠르게 읽을 수 있습니다. 짧은 대기 시간엔 읽기 속도와 피로도가 특히 중요합니다. 영어 장문 아티클은 내용이 좋아도 진입 비용이 크니까요. (우리 사이트라서가 아니라요) 실제 북마크에 최적화된 컬렉션이나 형광펜 기능이 좋습니다.

읽었다고 알게 되었다 생각하지 말기

대기 시간의 정보 소비를 기분 전환으로 쓸 때는 남는 게 없습니다. 반대로 미래의 나를 위한 자료 정리일 때만 이득이 됩니다. 즉, 지금의 3분이 나중의 30분을 아껴주는 구조여야 합니다. 그게 남는 시간의 활용법에서 가장 중요한 기준입니다.

그래서 읽고 끝내지 말고 짧은 코멘트나 질문을 하나 남겨두는 걸 추천합니다. 예를 들어 “이건 우리 서비스의 로그인에도 적용될까?” 같은 한 줄이면 됩니다. 이 한 줄이 나중에 나를 돕는 검색 키워드가 됩니다. 대신 논쟁이나 긴 스레드는 금지입니다. 거기에 빠지는 순간 전환 비용이 폭발해서 원래 하려던 일을 놓치기 쉽습니다.

메뉴판 3. ‘완성된 코드’를 다른 사람도 알아보게 번역하기

코드가 완성되는 것과 그 가치가 전달되는 건 다른 문제입니다. Claude Code가 코드를 빨리 만들수록 팀의 병목은 자연스럽게 리뷰와 이해, 합의로 옮겨갑니다. 그러니 남는 시간의 활용법은 키보드가 아니라 맥락을 향해야 합니다. 생산성의 다음 레벨은 코드 작성이 아니라 왜 이렇게 만들었는지를 남이 알아보게 번역하는 일입니다.

에이전트가 만든 코드는 속도가 빠른 대신, 읽는 사람이 따라잡기 어렵습니다. 리뷰어는 로컬에서 돌려보고, 화면을 캡처하고 의도를 추측해야 합니다. 이 과정이 길어지면 결국 아무리 좋은 코드도 머지까지 오래 걸립니다. 쉽게 말해, 이제는 코드보다 제대로 설명할 수 있는 결과물이 더 희소해졌습니다.

리뷰와 공유를 빠르게 만드는 도구들

공유 돕는 도구: Screen Studio, Gamma

맥락을 설명하는 가장 좋은 방법 중 하나는 보여주는 겁니다. 요즘 가장 강력한 보여주기 방식은 영상이고요. mac 전용인 Screen Studio는 화면 녹화를 꽤나 그럴듯하게 만들어주는 도구입니다. 자동 줌인과 모션 블러 덕분에 편집을 거의 안 해도 데모 영상 퀄리티가 올라갑니다. PR에 30초 데모를 달아두면 리뷰어는 코드를 직접 안 돌려봐도 됩니다. 그 한 번의 절약이 리뷰 속도를 눈에 띄게 끌어올립니다.

영상은 허들이 있긴 하죠. 그러면 떠오르는 것, PPT입니다. Gamma는 발표 자료가 빈 문서로 시작하는 공포를 없애줍니다. 프롬프트 한 줄로 발표 자료 초안을 만들어 시작 시간을 확 줄여주거든요. 스프린트 리뷰나 공유 세션은 자료를 미루는 순간 망하기 쉽습니다. 남는 시간 10분에 초안을 뽑아두면 발표는 절반이 끝난 셈입니다.

마지막은 도구가 아니라 습관입니다. PPT든 영상이든 그 근본이 되는 문서가 있습니다. README죠. 그래서 그냥 README 한 줄 다듬기를 해도 됩니다. 2분이면 끝나는 일이지만 미루면 이상하게 영원히 안 하게 됩니다. 이 PR이 해결하는 문제 1줄 + 사용법 1줄만 추가해도 전달력이 달라집니다.

가볍게, 하지만 반복하기 좋게

그래서 설득할 만한 맥락과 결과를 남기는 걸 습관으로 만드는 게 최고입니다.

가장 쉬운 건 PR 템플릿에 변경 전/후를 한 줄로 적는 겁니다. 리뷰어는 코드를 보기 전에, 무엇이 달라졌는지부터 알고 싶어합니다. 한 줄만 있어도 리뷰의 방향이 잡힙니다. 합의가 필요한 지점도 더 빨리 드러납니다. 스크린샷 1장 + 캡션 1줄도 좋습니다. 말로 설명하면 길어지는 걸, 이미지가 한 번에 끝냅니다. 캡션은 거창할 필요가 없습니다. “이 버튼을 누르면 토스트가 뜹니다” 정도면 충분합니다. 마지막은 테스트 방법을 적는 겁니다. 예를 들어 “A 화면에서 B를 누른다 → C가 보인다”처럼요. 이 두 줄이 있으면 리뷰어는 재현에 시간을 쓰지 않습니다.

메뉴판 4. 에이전트는 안 쉬니까, 내가 쉬기

에이전트가 일하는 동안 꼭 일해야 할 필요도 없습니다. 맡겼으니 쉬세요.

그 대신 쉬는 것도 설계도가 있으면 훨씬 좋습니다. 그래야 다시 돌아오기가 쉽거든요. “언제 끝나지?”가 없는 휴식은 오히려 불안을 줍니다. 그래서 원칙은 하나입니다. 끝나는 조건이 있는 휴식만 고릅니다.

괜찮은 휴식 방법 찾아보기

2~3분: 스트레칭

짧을수록 몸을 먼저 리셋하는 게 이득입니다. 스트레칭을 에이전트 주기에 맞추면 좋겠죠. 눈과 목, 어깨를 한 번씩 초기화하는 시간입니다. 화면을 오래 보는 날일수록 효과가 큽니다.

5분: 커피 내리기

커피는 왜인지 일하는 사람의 양식 같은 느낌이 있으니까요. 좀 눈치가 덜 보입니다. 이 5분 정도가 또 마침 짧은 리팩토링과 타이밍이 같습니다. 다시 자리로 돌아왔을 때, 뇌가 자연스럽게 다음 맥락을 잡습니다. 남는 시간 활용법으로 가장 무난한 선택입니다.

15분 이상: 산책

대기 시간이 길어질 때만 꺼내는 카드입니다. 돌아오면 PR이 올라와 있고, 머리는 확실히 맑아집니다. 핵심은 “걷는 동안 아무것도 안 하기”입니다. 그래야 진짜 회복이 됩니다.

에이전트는 안 쉬니까, 내가 쉬기

에이전트의 장점은 단순합니다. “내가 안 해도 된다”는 점입니다. 그런데도 손이 계속 뭔가를 찾으면, 결국 머리는 쉬지 못합니다.

그래서 정말로 안 하는 시간을 따로 설계해야 합니다. 이걸 안 하면 피로는 조용히 누적됩니다. 남는 시간의 활용법이 꼭 생산성 메뉴일 필요는 없습니다. 때로는 죄책감 없이 쉬는 것이 다음 작업에 낫습니다.

<출처: 작가, Gemini로 제작>

마치며

Claude Code가 일하며 만들어 준 그 시간, 이 빈 시간들은 애매한 공백입니다. 기다리기엔 길고, 새 일을 시작하자니 짧습니다. 이 구간은 생각보다 전환 비용이 큰 시간입니다. 무작위로 쓰면 머리가 엉망으로 깨져요. 그래서 필요한 게 남는 시간의 활용법을 미리 정해두는 겁니다.

다음 대기 시간이 오면 멍하니 창밖을 일단 바라보기 전에, 먼저 질문 하나만 던져봅시다. 지금 나는 뭘 하면 끝나고 나서 덜 후회할까? 생각해 보는 거죠.

글에서 추천한 방식 그대로일 필요는 없습니다. 중요한 건 이 시간을 쓰고 난 다음, 내가 나를 에이전트보다 무가치하게 느끼지 않는 겁니다. 그 시간에 우울해하지 말고, 나에게 맞는 메뉴를 정해 시간을 써봅시다.

]]>

클릭 한 번으로 디자인 시스템 가져오는 'MiroMiro'

새로운 서비스를 자주 들여다보고 분석해야 하는 기획자나 디자이너가 은근히 자주 사용하는 도구가 바로 개발자 도구입니다. 완성된 인터페이스 자체를 캡처하는 건 금방이지만, 그보다 폰트나 여백이 어떻게 설정되어 있는지 등을 확인하기 위해서는 개발자 도구를 거쳐야 하기 때문입니다. 문제는 개발자 도구에 꽤 익숙해졌다 하더라도 복잡하게 얽힌 <div> 태그의 숲을 헤매다 보면, 어느새 분석하려던 대상을 놓치거나, 찾는 데 많은 시간을 쓰게 됩니다. 특히 추출하기 까다로운 SVG 아이콘이나 로티(Lottie) 애니메이션 파일을 찾기 위해 네트워크 탭을 뒤지는 것도 그렇고요.

물론 확장 프로그램을 활용해 이런 문제를 해결할 수 있습니다. 저 역시 몇 가지 도구를 계속 써왔지만, 서비스가 종료되거나 업데이트를 지원하지 않아 사용이 어려워진 경우가 있었습니다. 그러다 얼마 전 ‘MiroMiro’라는 서비스를 알게 되었는데, 이곳은 클릭 한 번으로 웹 사이트 내 색상, 글꼴, 이미지 및 애니메이션 등을 추출할 수 있도록 도와줍니다. 확장 프로그램을 지원하며, URL을 통한 추출도 가능하죠. 구체적으로 어떤 기능을 제공하는지 이번 글에서 자세히 살펴보겠습니다.

주요 기능 훑어보기

<출처: MiroMiro, 작가 캡처>

MiroMiro는 기본적으로 크롬 확장 프로그램 형태로 작동합니다. 원하는 사이트에서 확장 프로그램을 실행하면, 필요한 정보를 패널을 통해 빠르게 확인할 수 있도록 구성되어 있습니다.

1) 전체 내용 요약: 확장 프로그램을 실행하면 가장 먼저 ‘오버뷰’에 해당하는 내용을 살펴볼 수 있습니다. 사용된 미디어, SVG, 컬러, 폰트의 수가 몇 개인지 빠르게 훑어볼 수 있습니다. 각 카드(예를 들어, 미디어)를 클릭하면 사용/적용된 내용을 별도 화면에서 모아볼 수 있으며, 즐겨찾기를 하거나 다운로드를 할 수도 있습니다.

2) 디자인 시스템의 시각화:특정 요소 하나만 보는 것이 아니라, 해당 페이지 전체에 흐르는 디자인 규칙을 읽어냅니다. 사용된 모든 컬러 팔레트와 타이포그래피 스타일(폰트 패밀리, 사이즈, 웨이트, 행간 등)을 데이터 시트 형태로 깔끔하게 정리해 보여줍니다.

3) '로티(Lottie)'까지 잡아내는 에셋 리퍼:Miro에서 느낀 가장 큰 강점 중 하나입니다. 일반적인 이미지나 SVG는 물론, 웹사이트에서 돌아가고 있는 인터랙션 애니메이션 파일(.json)을 클릭 한 번으로 추출할 수 있습니다. (다만, 로티 애니메이션 추출은 유료 플랜에서만 지원합니다)

4) Inspect 모드 지원: 마우스를 올리기만 하면 요소 사이의 여백(Padding, Margin)과 그리드 구조를 실시간 가이드 선으로 보여줍니다. 클릭하면, 패널을 통해 상세 내용을 확인할 수 있습니다. 예를 들어, 버튼이라면, 코드가 어떻게 구성되어 있는지 어떤 컬러와 그라데이션 등의 요소를 활용했는지, 대비는 잘 이뤄져 있는지 등을 자세히 확인할 수 있습니다.

핵심 기능 사용해 보기

<출처: MiroMiro, 작가 캡처>

특정 서비스에서 ‘MiroMiro’ 확장 프로그램을 실행, 하단 미디어 탭을 선택한 모습입니다. 페이지에 사용된 전체 이미지와 영상 그리고 로티 파일을 볼 수 있는 공간이기도 합니다. 리스트에 있는 영상이나 이미지에 마우스를 대면, 좋아요 또는 다운로드할 수 있는 버튼을 확인할 수 있습니다. (무료 버전에서는 최대 10개까지의 좋아요를 기록할 수 있으며, 유료 계정으로 업그레이드하면 전체 미디어를 일괄 다운로드할 수 있는 기능을 제공합니다.)

일단 리스트 형태로 이미지와 영상 그리고 로티 파일을 모아볼 수 있다는 자체가 탐색 시간을 줄이는데 많은 도움을 줍니다. 그렇지 않으면 스크롤을 내리며, 적용된 이미지를 하나씩 확인해야 하고, 거기에 효과까지 붙은 섹션이라면 시간이 더 소요될 수밖에 없기 때문입니다. 또 로티로 만들어진 효과를 따로 모아보고, 참조할 수 있다는 점은 특정 웹페이지에서 레퍼런스를 보다 쪼개어 확인하는 과정에서 특히 매력적입니다.

<출처: MiroMiro, 작가 캡처>

하단 - 세 번째 탭에서는 SVGs 정보를 확인할 수 있는데요. 주로 아이콘이 포함되어 있으며, SVG 코드를 복사하거나 다운로드할 수 있습니다. 물론, 이미지나 영상과 같이 특정 SVG를 저장해서 나중에 참고하는 것도 가능합니다. 저는 이 서비스를 알게 된 뒤로 이 기능을 가장 많이 활용했는데, 마음에 드는 아이콘을 다양한 방법으로 뜯어보고 실제 활용하는 데 직접적인 도움을 받을 수 있기 때문입니다.

<출처: MiroMiro, 작가 캡처>

네 번째 탭은 컬러가 주인공입니다. 사용된 컬러에 대한 정보를 상세히 확인할 수 있도록 초점이 맞춰져 있습니다. 화면에서 컬러를 직접 추출할 수 있는 기능으로 시작, 전체 컬러를 확인하거나, 배경, 텍스트, 보더, 브랜드 등 타입에 따라 컬러를 살펴보는 것도 가능합니다.

<출처: MiroMiro, 작가 캡처>

또한 디자인 시스템을 전체 확인, 내려받는 기능도 지원합니다. 폰트, 여백, 그림자, 기타 구성 요소를 한 번에 추출해 ‘Tailwind, CSS, JSON’ 파일로 받아볼 수 있습니다. 요즘 바이브 코딩을 많이 하시는데, 그때 이런 데이터를 참고해 스타일 가이드 등을 만드는데 도움을 받을 수 있는 기능입니다. (다만 실제 내려받는 기능은 유료 모델에서만 가능합니다. 추출 및 확인은 무료 계정에서도 지원)

<출처: MiroMiro, 작가 캡처>

다섯 번째 탭은 타이포입니다. 사용된 폰트와 함께 해당 폰트가 어떤 목적으로 사용되는지 살펴볼 수 있습니다. 상세 정보를 통해 폰트 이름, 사이즈, 두께, 간격 등의 내용도 알 수 있습니다. 또한 특정 폰트의 ‘위치’ 확인하기 버튼을 클릭하면 실제로 어떻게 적용되었는지 해당 위치로 바로 이동할 수 있습니다. 폰트 역시 마음에 드는 대상을 좋아요로 기록해, 마이페이지(여섯 번째 탭)에서 언제든 다시 살펴볼 수 있도록 구성된 모습입니다.

여섯 번째 탭 - 마이페이지에서는 현재 사용 중인 요금제에 대한 정보로 시작해, 월 기준 사용량에 대한 정보를 확인할 수 있습니다. 좋아요(저장)한 아이템도 볼 수 있습니다.

한 번은 꼭 써봐야 하는 이유

<출처: MiroMiro, 작가 캡처>

탭 구분과 상관없이, 상단에는 ‘Inspect mode’를 지원합니다. 클릭하기 전에는 웹페이지 상에서 기본적인 정보를 확인할 수 있고, 클릭 후에는 우측 패널에서 자세한 정보를 제공합니다. 클릭한 대상의 미리 보기와 함께 코드 복사, 코드 내보내기 그리고 사용된 컬러와 스타일 정보가 포함되어 있습니다.

저는 이 서비스를 레퍼런스 탐색도 탐색이지만, 개인적으로 진행하는 다양한 바이브 디자인/코딩 프로젝트에 적극적으로 활용하고 있습니다. 예를 들어, 마음에 드는 스타일의 버튼이 있다면, 클릭 후 컬러나 스타일 정보 등을 바탕으로 참고해 적용하는 방법입니다. 컴포넌트 단위의 레퍼런스 제공 서비스와 함께 활용하면, 더 다양한 구성요소를 빠르게 작업할 수 있죠.

<출처: MiroMiro, 작가 캡처>

서비스는 무료로도 사용할 수 있지만, 사용량 등에 제한이 있는 건 어쩔 수 없습니다. 무료 버전에서는 디자인 시스템 추출은 가능하지만, 내려받기는 지원하지 않습니다. 또 CSS, Tailwind 등으로 내보내는 기능 또한 사용할 수 없습니다. 미디어/영상, SVGs 등을 한 번에 내려받는 기능 또한 유료 버전에서만 지원합니다.

그럼에도 무료 버전을 제공하고 있으며, 확장 프로그램이라는 접근성 좋은 환경과 다양한 도구를 충분히 체험해 볼 수 있다는 점, 무엇보다 기존의 탐색 방식을 보다 직관적이고 빠르게 바꿔줄 수 있다는 점에서 유용한 서비스라고 생각합니다.

<참고>

https://MiroMiro.app/

]]>

마케팅 없이 요약 AI 하나로 ARR 100만 달러 만든 비결

[요즘 프로덕트] 시리즈

'어떤 문제를 해결할 것인지',
'그게 왜 지금 해결해야 하는 문제인지'

[요즘 프로덕트]는 이렇게 탁월한 문제 정의로 시장의 판을 바꾸고 있는 메이커들의 사고방식을 추적해보는 시리즈입니다. 그 첫 번째 주인공을 만나보겠습니다.

별명이 '요약충'이던 사람이 요약 AI를 만들었습니다. 런칭 1년 5개월 만에 연간 반복매출(ARR) 100만 달러, 특별한 마케팅 없이 입소문으로만 누적 사용자 100만 명. AI 요약 서비스 릴리스AI 이야기입니다.

릴리스AI 로고 <출처: 릴리스AI>

릴리스AI 오현수 대표는 "오징어 게임도 요약본으로 봤다"고 할 만큼 요약에 진심인 사람입니다. 수많은 문제 중 굳이 '요약'을 택한 이유를 묻자, "너무 좋아하고 관심이 많았기 때문"이라고 답합니다.

오 대표가 창업을 준비하던 2023년 초, 챗GPT 열풍을 타고 요약을 표방한 서비스는 이미 수백 개가 넘었습니다. 시장은 포화처럼 보였습니다. 하지만 그 수백 개의 서비스를 하나씩 써보고 나서 오히려 확신했죠. "실제로 이 자료에서 인사이트를 추출하는 단계까지 올라간 제품이 단 한 개도 없었다"고요.

그에게 요약이란 콘텐츠를 '경험'하는 것이 아니라 '인사이트를 꺼내는 것'이었습니다. 그 기준으로 시장을 봤을 때, 기존의 요약 서비스들은 전부 다섯 줄짜리 압축본을 내놓는 수준에 머물러 있었습니다.

릴리스AI 오현수 대표 <출처: 요즘IT>

릴리스AI는 그 빈자리에서 시작됐습니다. 유튜브 영상과 PDF 자료를 단순히 불릿포인트 몇 개로 압축하는 게 아니라, 원래 소스의 인사이트를 구조화된 리포트로 제공합니다. 요약 화면 안에서 해외 자료를 번역하거나, 원문 출처를 확인하고, 모르는 개념을 학습할 수 있는 UI까지 갖췄습니다. 이 때문에 단시간에 많은 자료를 소화해야 하는 사업가, 투자자, 연구자들이 주요 사용자로 모여들었습니다.

수백 개의 경쟁자 사이에서 마케팅 없이도 유료 고객이 모여든 것은 기술이 남달라서가 아니었습니다. 오 대표는 창업 전부터 "무조건 쓸 수밖에 없는 사람이 있는 아이템"을 찾겠다고 생각했고, 그 답을 자신의 취향과 자신만의 문제 정의 프레임워크를 통해 찾았습니다.

좋은 문제를 고르는 3가지 기준

오 대표가 처음부터 명확한 프레임워크를 손에 쥐고 창업한 것은 아닙니다. 그것은 실패와 성공을 반복하면서 사후적으로 다져진 것이었습니다.

그는 AI 영상 편집기 '브루(Vrew)'를 만든 보이저엑스에서 5년을 보냈습니다. 딥러닝 리서처로 시작해 백엔드 엔지니어를 거쳐 기획과 마케팅까지 넘나들었습니다. 그 과정에서 여러 아이템을 팀에 제안했지만 번번이 실패했습니다. 치열하게 고민하고 다른 사례들을 공부하며 자기만의 생각을 조금씩 다듬어 나갔습니다.

릴리스AI 오현수 대표가 일했던 보이저엑스의 AI 영상 편집기 ‘브루(Vrew)' 로고 <출처: 브루 홈페이지>

전환점은 브루에서 직접 기획하고 성공시킨 프로젝트였습니다. 당시 AI 목소리(TTS)로 만든 유튜브 채널들이 구독자 수십만 명을 모으고 있었습니다. 그러나 그런 영상을 만들려면 스톡 비디오 사이트, TTS 서비스, 영상 편집기를 따로따로 넘나들어야 했습니다. 불편함에도 사람들은 그 복잡한 과정을 감수하고 있었습니다. 오현수는 그 장면에서 기회를 봤습니다. 텍스트 아이디어만으로 영상을 만들 수 있는 기능을 브루 안에 구현했고, 출시하자마자 시장이 즉각 반응했습니다. "시장이 원하는 것을 만들었을 때 바로 반응한다는 것"을 몸으로 배운 순간이었습니다.

그 경험이 지금의 프레임워크로 굳었습니다. 그가 좋은 문제를 고르는 기준은 세 가지입니다.

첫째, 사람들이 이미 하고 있는 행동인가. 불편함에도 불구하고 시간과 돈을 써가며 이미 하고 있는 행동이라면, 그 문제는 충분히 중요하다는 신호입니다. 브루에서는 복잡한 도구를 여러 개 조합해가며 굳이 영상을 만들고 있는 사람들이 바로 그 신호였습니다.

둘째, 인간의 변하지 않는 욕망과 닿아 있는가. 새로운 기술이 만들어낸 욕망이 아니라, 오래전부터 존재해온 욕망을 건드리는 문제여야 합니다. 텍스트만으로 영상을 만들 수 있는 기능은 “낮은 비용으로 많은 시도”를 하고 싶은 콘텐츠 제작자들의 오랜 욕망과 관련이 있다고 확신했습니다.

셋째, 기술로 인해 막 가능해진 것인가. 기존에 이미 가능했던 것이라면 뛰어난 선배들이 이미 해결해 놓았을 것입니다. 반면 지금 막 가능해진 것에는 아직 스타트업이 비집고 들어갈 틈이 있습니다.

"이렇게 아무리 문제를 정의해도 늘 틀리는 것 같다"고 그는 웃으며 덧붙였습니다. 절대적인 공식이 아니라는 뜻입니다. 그럼에도 이 세 가지는 그가 릴리스AI를 포함해 모든 아이템을 검토할 때 꺼내드는 기준입니다.

왜 하필 "요약"이었나

세 가지 기준을 충족하는 아이템이 요약 하나뿐이었던 건 아닙니다. 오 대표는 그럼에도 왜 하필 ‘요약’이었는지 그 이유를 묻자 "제가 하고 싶어서"라고 먼저 답했습니다. 사업과 제품과 창업가의 핏(fit)이 맞아야 한다는 것, 많은 선배 창업가들이 강조하는 그 얘기를 그는 믿습니다.

그의 요약 사랑은 꽤 오래됐습니다. 보이저엑스에 다니던 시절, 전 세계 최고 창업가들의 인터뷰 영상을 퇴근 후에도 찾아보며 공부했습니다. 와이콤비네이터(YC) 유튜브 채널을 뒤지고, 비전공자 출신 개발자로서 모르는 기술을 습득하고, 그렇게 흡수한 것들을 다시 요약해 정리했습니다. 사람들이 많이 본다는 드라마도 요약해 볼 정도였죠. 동료들 사이에서 자연스럽게 붙은 별명이 '요약충'이었습니다.

그런 사람의 눈에 요약 시장은 달리 보였습니다. 챗GPT 등장 이후 커뮤니티를 살펴보니, 사람들이 AI를 쓰는 용도의 상당수가 "요약해줘, 설명해줘, 이해시켜줘"였습니다. 그 욕망의 뿌리를 그는 이렇게 짚습니다. 나무위키가 국내 트래픽 상위권인 이유도, 대기업 회장이 뛰어난 직원을 시켜 PPT를 만드는 것도, 결국 복잡한 정보를 자기 눈높이에서 정리해 이해하고 싶은 오래된 욕망이자 사람들이 이미 하고 있는 행동이라는 것입니다.

그가 정의하는 요약은 단순한 압축이 아닙니다. "자료 속의 인사이트를 추출해서 내 고민에 도움이 되는지를 재어보고 적용하는 행위"입니다. 그 욕망은 오래됐고, 시장은 컸고, 기술은 막 가능해졌습니다. 세 가지 기준에 모두 충족됐고, 그것을 가장 잘 이해하는 사람이 마침 그였습니다.

문제는 하나 남아 있었습니다. 수많은 경쟁자들도 같은 시장을 보고 있었다는 것입니다. 그중에서도 구글의 노트북LM은 자료만 넣으면 무료로 요약을 해주는 대표적인 서비스로 꼽혔죠.

노트북LM과 뭐가 다른가

릴리스AI가 입소문을 타기 시작하면서 가장 많이 받는 질문이 있습니다. "그냥 노트북LM(NotebookLM) 쓰면 되지 않나요?" 구글이 만든 노트북LM은 PDF나 유튜브 영상을 넣으면 요약과 질의응답을 제공하는 서비스로, 릴리스AI와 가장 자주 비교됩니다. 오 대표의 답은 간결합니다. "방향이 달라요."

그에 따르면 노트북LM은 자료를 '활용'하는 데 방점이 찍혀 있습니다. 수백 개의 문서를 한꺼번에 넣고 원하는 정보를 찾거나 보고서를 뽑아내는 용도입니다. 릴리스AI는 다릅니다. 자료 하나를 '제대로 이해'하는 것이 목표입니다. "아이스크림 가게랑 붕어빵 가게는 둘 다 디저트지만 겨냥하는 니즈가 아예 다르다"고 그는 말합니다. 그만큼 노트북LM과 릴리스AI의 지향점이 다르다는 것입니다.

유튜브 링크 삽입시 구글의 노트북LM 화면. 소스를 넣으면 이와 같은 화면이 뜬다. 소스 목록(왼쪽) 간단한 요약이 제공되며 자료에 대해 질의할 수 있는 채팅화면(가운데)과, 노트북LM이 제공하는 AI 오디오 오버뷰, 슬라이드 등의 자료를 활용할 수 있는 스튜디오 화면(오른쪽)이 뜬다. <출처: 노트북LM 사용자 화면 캡처>

그 방향의 차이는 제품 구조에 고스란히 반영돼 있습니다. 오 대표가 MVP에 반드시 갖춰야 한다고 생각한 것은 세 가지였습니다. 첫째는 영상 뷰어와 요약이 한 화면에 함께 있을 것. 둘째는 요약이 충분히 길고 디테일할 것. 특히 2~3분 단위가 하나의 문단으로 정리되고, 원본의 뉘앙스와 데이터와 사례가 변형 없이 담긴 '구조화 리포트'에 가까운 수준으로 출력되는 것이 그의 목표였습니다. 셋째는 요약이 의심스러울 때 원본으로 즉시 돌아갈 수 있을 것. 타임스탬프를 클릭하면 해당 부분이 바로 재생되고, 스크립트를 한 줄씩 열람할 수 있어야 했습니다.

"노트북LM은 1시간짜리 영상을 요약하면 출처가 영상 전체로 잡혀요. 33분 50초에 나온 문장이 어디서 왔는지 알 수 없고, 재생도 안 됩니다." 자료를 꼼꼼히 뜯어봐야 하는 UX 리서처들이 릴리스AI를 떠나지 못하는 이유가 여기 있습니다. 인터뷰 영상을 넣고 요약을 보다가, 스크립트를 열고, 다시 재생해 확인하는 과정이 한 화면 안에서 끊김 없이 이뤄지는 것. "노트북LM으로는 그게 아예 안 된다"는 것입니다.

같은 소스를 릴리스AI에 넣은 화면. [숫자]는 해당 문장의 출처이며, 이를 클릭하면 영상의 관련 영역이 재생된다. 노트북LM은 소스를 넣고 요약을 요청해야 하지만 릴리스AI는 바로 구조화된 요약이 나타난다. 소스를 입력하면 자료 출처와 스크립트 영역(왼쪽), 구조화된 요약 화면(가운데), 사용자의 맥락을 기억하는 에이전트 릴리(오른쪽) 화면이 뜬다. MVP에서 번역과 에이전트는 없었다. <출처: 릴리스AI 사용자 화면>

원하는 결과물을 만들기 위해 오 대표가 프롬프트를 수정한 횟수는 500번이 넘습니다. '좋은 요약'이 무엇인지를 정의하기 위해 뇌과학 책까지 읽었습니다. "이해란 내가 원래 알고 있는 사고의 프레임워크에 새로운 것을 편입시키는 과정"이라는 것, 그래서 세상에서 가장 효과적인 이해의 방식이 비유라는 것을 거기서 배웠습니다.

결국 노트북LM과의 차이는 기능의 많고 적음이 아닙니다. 어떤 사용자의 어떤 순간을 위해 설계됐는가의 차이입니다. "노트북LM 엔지니어들이 저희보다 요약에 관한 이해가 부족해서가 아니에요. 그냥 방향이 다른 거죠."

앞으로의 릴리스AI는

릴리스AI는 현재 누적 사용자 100만 명을 넘겼습니다. 투자 없이, 마케팅 없이 여기까지 왔습니다. 오 대표에 따르면 작년 매출은 20억 원에 가까웠고, 순이익도 4억 원에 달했습니다. 그에 따르면 시밀러웹 기준 국내 트래픽에서 노트북LM을 앞서고 있다고 합니다. "사용자들의 강력한 사랑을 대변하는 것 같다"고 그는 말합니다.

충성 사용자들의 사용 방식은 흥미롭습니다. 어떤 펀드매니저는 쏟아지는 증권사 리포트와 IR 자료를 릴리스AI에 넣고 훑습니다. 한 스타트업 대표는 주말마다 책을 읽어야 한다는 압박에 시달리다가, 책 리뷰 유튜브 영상 10개를 릴리스AI에 넣고 자세한 리포트를 뽑아보니 "책 읽은 것과 똑같은 인사이트가 있더라"며 그 방식으로 정착했습니다. 원래 하루에 두세 개 보던 자료를, 시간이 10분의 1로 줄자 하루 30개씩 보는 사용자도 생겼습니다.

자세한 리포트 예시. 유튜브 링크만 릴리스AI에 넣으면, 영상 내용을 구조적인 목차에 따라 자세히 정리하고 해당 구간의 이미지도 삽입해준다. 문장 옆의 [숫자]를 클릭하면 해당 구간의 영상 스크립트를 바로 볼 수 있고, 그 문장이 속해 있는 정확한 타임스탬프도 안내해준다. 해당 문장을 바로 번역할 수도 있다. <출처: 릴리스AI 사용자 화면 캡처>

릴리스AI의 다음 단계에 대해 오 대표는 "늘 똑같은 고민을 하는 것 같다"고 웃습니다. 어떻게 하면 더 중요한 자료를 찾아서 더 잘 이해시켜줄 수 있을까. 달라지는 것은 그 고민의 범위입니다. 지금까지 릴리스AI는 사용자가 직접 가져온 자료를 요약하는 데 집중했습니다. 다음 단계는 '자료 수급'입니다. 사용자가 아무 준비 없이 들어와도, 그의 고민과 관심사에 맞는 자료가 이미 준비돼 있는 서비스로 나아가려 합니다.

"예를 들어 테슬라 관련 영상을 한번 봤어요. 그러면 이분이 테슬라 좋아하는구나, 주식 영상 좋아하는구나 생각해서 관련 자료를 미리 준비해 놓는 거죠. 심지어 이분이 원래는 도달하지 못했을 미국 시황 영상까지도요." 릴리스AI에 들어오면 늘 나에게 꼭 맞는 자료가 가득한 상태. 그것이 그가 그리는 다음 그림입니다.

AI 시대, 메이커에게 남은 것

"만드는 것이 쉬워지는 일은 사실 과거에도 계속 벌어졌습니다."

누구나 바이브 코딩으로 제품을 만들 수 있는 시대, 경쟁자가 내 기능을 하루 만에 복사할 수 있는 시대에 메이커로서 무엇을 붙잡아야 하느냐는 질문에 오 대표는 방송을 예로 듭니다. 예전에는 영상을 만들어 송출하는 것이 어마어마한 자본이 필요한 일이었지만, 지금은 누구나 유튜브에 영상을 올립니다. 그렇다고 99%의 사람들이 자기가 볼 영상을 직접 만들어 보고 있냐 하면, 그건 아닙니다. "만드는 수단이 쉬워져도 메이커는 1%밖에 안 돼요. 고객을 어떻게 만족시켜 줄까를 떠올리는 것 자체가 굉장히 힘들기 때문"입니다.

그가 꼽는 메이커의 경쟁력은 사람에 대한 이해, 결단력, 그리고 취향입니다.

사람에 대한 이해는 그의 문제 정의 프레임워크와 맞닿아 있습니다. 기술이 평준화될수록 누가 고객을 더 깊이 이해하고 있느냐가 차이를 만듭니다. 결단력은 논리를 넘어서는 영역입니다. 그가 즐겨 보는 YC 유튜브 채널에서 인상 깊게 본 내용이라며 이렇게 말합니다. "거기서 성공한 회사들을 보면 아무리 이성적으로 생각해봐도 그만뒀어야만 하는 회사들이었다고 해요. 그 정도로 위기가 많고 잘 안 됐는데, 그럼에도 불구하고 그냥 했다는 거예요."

취향은 옳고 그름이 없는 영역입니다. 가장 똑똑한 한 회사가 세상의 모든 패션을, 모든 게임을 독식할 수 없는 것처럼, 취향의 영역은 거대 자본도 완전히 장악할 수 없습니다.

마지막으로 릴리스AI 같은 제품을 만들고 싶은 메이커들에게 한마디를 부탁했습니다. "스스로의 내면에 있는 보편성을 발견하는 것이 중요한 것 같습니다." 자기가 강하게 느끼지 않는 니즈에서 출발하는 건 리스크가 너무 크다는 것입니다. 내가 불편하고 내가 간절한 문제 중에서, 많은 사람들도 공통적으로 겪고 있는 것을 찾다 보면 좋은 제품의 단초가 된다고 그는 말합니다.

AI 시대에 메이커의 자리가 사라질까 걱정하는 사람들이 많습니다. 하지만 오 대표의 이야기를 따라가다 보면, 메이커의 본질은 달라진 게 없습니다. 자신이 오랫동안 간절했던 문제가 있고, 그 문제가 자신만의 것이 아님을 확인하는 것. 그게 시작이었고, 그게 전부였습니다. 별명이 요약충이던 사람이 '요약'이란 영역에서 그걸 증명해나가고 있습니다.

(종료)릴리스AI 이용권 증정 이벤트

요즘IT 독자분들께 추첨을 통해 총 5명에게 릴리스AI 베이직 이용권(월 19,900원 상당)을 드립니다.

베이직 이용권 혜택
무제한 고급 모델 사용
속도 부스트 1,000회/월
영상·음성·PDF 넉넉한 파일 업로드

참여 방법
✅ 링크드인 | 이 기사를 공유하고 @요즘IT를 태그해 주세요 → 3명 추첨
✅ 유튜브 | 릴리스AI 인터뷰 영상에 댓글을 남겨주세요 → 2명 추첨
※ 링크드인·유튜브 중복 참여는 가능하나, 당첨은 1인 1회로 제한됩니다.

이벤트 기간 | 2026년 3월 9일 ~ 3월 13일
당첨자 발표 | 3월 16일 당첨자 개별 연락(요즘IT가 댓글의 답글 혹은 게시글의 댓글로 안내)

]]>

앤트로픽이 공식 오픈한 무료 강의 플랫폼 — Anthropic Courses

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: gogcli - 터미널 명령어 하나로 Gmail 보내고 캘린더 잡는 CLI
참고할 것: OpenAI Codex Windows 앱 - Windows에서도 병렬 에이전트로 코딩하기
적용해볼 것: Anthropic Courses - Anthropic이 직접 공개한 무료 온라인 강의

gogcli README (한국어 자동 번역) / <출처: gogcli >

1. 써볼 것: 터미널 명령어 하나로 Gmail 보내고 캘린더 잡는 CLI

gogcli는 Google Workspace 전체를 터미널에서 제어할 수 있는 CLI 도구입니다. OpenClaw를 만든 개발자 Peter Steinberger(@steipete)가 만들었고요. 현재 GitHub 스타 5.5k를 돌파했습니다.

원래는 OpenClaw에서 Google 서비스를 연동할 때 쓰려고 만든 도구인데, 단독으로도 쓸 수 있어서 개발자·에이전트 자동화 커뮤니티에서 빠르게 퍼졌습니다. Gmail, 캘린더, 드라이브, Docs, Sheets, 연락처, Tasks까지 터미널 명령어 하나로 제어하는 게 가능하고, 결과는 JSON으로 뽑아주니까요.

무슨 문제를 해결해 주나요?

AI 에이전트나 자동화 스크립트에서 Google 서비스를 쓰려면 보통 Google API를 직접 연결해야 합니다. OAuth 설정, 토큰 관리, API 문서 뒤지기까지 초기 세팅만 해도 시간이 꽤 걸리죠. MCP 서버를 세팅해도 되지만 매 요청마다 툴 스키마가 컨텍스트를 잡아먹는다는 단점이 있고요.

gogcli는 이 과정을 CLI로 감춰버립니다. 인증을 한 번 설정해두면 이후로는 명령어 한 줄로 Gmail을 검색하거나, 캘린더 일정을 만들거나, 드라이브 파일을 내려받을 수 있습니다. 결과는 --json 플래그 하나로 JSON으로 받을 수 있어서 스크립트나 에이전트가 바로 파싱할 수 있고요.

어떻게 쓰나요?

Homebrew로 설치하고 Google Cloud Console에서 OAuth 클라이언트 JSON 파일을 한 번 받아오는 게 시작입니다.

brew install steipete/tap/gogcli
gog auth credentials ~/Downloads/client_secret.json
gog auth add you@gmail.com
export GOG_ACCOUNT=you@gmail.com

이후로는 이런 식으로 씁니다.

gog gmail search 'newer_than:7d' --max 10 --json
gog calendar events primary --today
gog drive ls --query "mimeType='application/pdf'" --max 5
gog gmail send --to someone@example.com --subject "안녕" --body "잘 지내?"

다중 계정도 지원합니다. 개인 계정과 업무 계정을 별칭으로 등록해두면 --account work처럼 전환이 됩니다. --readonly 플래그로 읽기 전용 권한만 부여하는 것도 가능하고, 특정 명령어만 허용하는 샌드박스 모드도 있어서 에이전트에 넘겨줄 때 범위를 제한할 수 있습니다.

에이전트 관점에서 보면 MCP 서버 대신 CLI를 쓰는 게 오히려 효율적인 경우가 많습니다. MCP 서버는 연결할 때마다 툴 스키마를 컨텍스트에 올려야 하지만, CLI는 필요한 명령어 레퍼런스만 넣으면 되니까 토큰 소모가 훨씬 적습니다.

누구에게 좋을까요?

Claude Code나 OpenClaw 같은 AI 에이전트에 Google Workspace 연동을 붙이고 싶은 분, 반복적인 Gmail·캘린더·드라이브 작업을 스크립트로 자동화하고 싶은 분, MCP 서버 세팅 없이 가볍게 Google 서비스를 연결하고 싶은 분에게 맞습니다. 반면 GUI 없이 터미널에서 작업하는 게 낯설다면 초기 OAuth 설정 과정이 다소 번거롭게 느껴질 수 있습니다. Google Cloud Console에서 사용할 API를 하나씩 활성화하는 단계가 있거든요.

<출처: microsoft store>

2. 참고할 것: Windows에서도 병렬 에이전트로 코딩하기

OpenAI Codex 앱 Windows 버전이 3월 4일 Microsoft Store에 공개됐습니다. Mac 버전이 2월 2일 먼저 나왔고, Windows 개발자들이 한 달가량 기다린 끝에 나온 버전입니다. 늦게 나온 데는 이유가 있었습니다. 에이전트가 로컬에서 코드를 실행하려면 파일 시스템 접근을 제한하는 샌드박스가 필요한데, macOS에는 OS 수준의 격리 도구가 있지만 Windows에는 그게 없었거든요. 그래서 OpenAI가 직접 Windows용 샌드박스를 새로 만들었고, 이 코드도 Codex 오픈소스 저장소에 함께 공개됐습니다.

Windows 지원이 반가운 이유도 있습니다. Stack Overflow 2025년 설문 기준으로 Windows는 개발자 주요 OS 1위로, 약 50%가 업무용으로 쓰고 있거든요. AI 코딩 에이전트 도구들이 Mac 중심으로 먼저 나왔던 걸 감안하면, Windows 지원은 실질적으로 사용자 저변을 크게 넓히는 움직임입니다.

기존 AI 코딩 도구와 무엇이 다른가요?

Mac 버전 출시 때부터 화제였던 건 병렬 에이전트 스레드입니다. 대부분의 AI 코딩 도구는 한 번에 하나의 작업을 처리하지만, Codex 앱은 여러 에이전트 스레드를 동시에 돌릴 수 있습니다. 각 스레드는 별도의 Git worktree에서 실행돼서 서로 충돌 없이 결과를 만들고, 작업이 끝나면 diff를 보면서 머지할지 결정하는 구조입니다. A 기능 구현을 하나가 하는 동안 다른 에이전트가 B 기능을 처리하거나 버그를 찾는 방식으로 쓸 수 있고요.

Windows 버전도 이 경험을 그대로 가져왔습니다. 앞서 언급한 것처럼 샌드박스를 새로 만들어야 했던 이유가 바로 여기 있는데, 병렬로 돌아가는 에이전트들이 서로의 파일을 건드리거나 시스템에 의도치 않은 영향을 주지 않으려면 격리 환경이 필수거든요.

어떻게 작동하나요?

앱을 설치하면 프로젝트 사이드바, 에이전트 스레드 뷰, 리뷰 패널이 한 화면에 들어옵니다. 기본은 PowerShell 기반이고, 필요하면 WSL로 전환할 수 있습니다. 에이전트 실행 환경과 터미널 설정은 독립적으로 구성할 수 있어서, 에이전트는 WSL로 돌리면서 터미널은 PowerShell을 쓰는 조합도 됩니다.

Git, Node.js, Python, .NET SDK가 미리 설치돼 있으면 에이전트가 더 잘 동작합니다. 앱 내 터미널에서 winget으로 한 번에 설치할 수 있고요.

무엇을 얻어가야 하나요?

Windows 개발자 입장에서 실질적인 업데이트입니다. 단순히 Mac 버전을 포팅한 게 아니라 Windows 환경에 맞는 샌드박스를 직접 만들어서 가져왔고, 그 결과물을 오픈소스로 공개했다는 점이 흥미롭습니다. ChatGPT 유료 구독자라면 추가 비용 없이 사용할 수 있고, 한시적으로 무료 플랜에서도 쓸 수 있습니다.

<출처: Anthropic Courses - Skilljar>

3. 적용해볼 것:Anthropic이 직접 공개한 무료 온라인 강의

Claude를 쓰는 사람은 많은데, 잘 쓰는 사람은 생각보다 적습니다. 유튜브나 블로그로 배우면 정보의 질이 들쭉날쭉하고, 어디까지가 정확한 건지 판단하기도 어렵죠. Anthropic이 이 문제를 직접 해결하고자 나섰습니다.

Anthropic Courses는 Anthropic이 공식 운영하는 무료 학습 플랫폼입니다. anthropic.skilljar.com에서 바로 접근할 수 있고, 놀라운 건 Anthropic 계정이 없어도 됩니다. Skilljar 이메일 가입만 하면 강의를 전부 무료로 들을 수 있고, 수료증도 발급됩니다. 개발자부터 교육자, 비영리 단체 종사자까지 대상이 꽤 넓은 편이고요.

저는 Claude 101을 수강하고 수료해보았습니다

어떤 강의가 있나요?

개발자라면 다섯 개가 핵심입니다.

Claude Code in Action: 21개 레슨, 약 1시간 분량입니다. CLAUDE.md로 세션 간 기억을 유지하는 법, 반복 작업을 슬래시 커맨드로 만드는 법, Hook으로 파일 수정 후 자동 포맷팅 거는 법, MCP 서버로 GitHub나 DB를 연결하는 법, SDK로 Claude Code 기능을 내 도구에 임베딩하는 법까지 다룹니다. Claude Code를 터미널에서 쓰고 있다면 가장 먼저 들을 강의입니다.
Building with the Claude API: Claude API 전반을 다루는 개발자 대상 종합 과정입니다. 내용이 밀도 있는 편이라 2~3일 여유를 두고 듣는 게 좋습니다.
Introduction to Model Context Protocol: Python으로 MCP 서버와 클라이언트를 처음부터 만들어봅니다. Tools, Resources, Prompts라는 세 가지 핵심 구성 요소를 배우고, MCP Inspector로 테스트하는 법까지 다룹니다. MCP를 제대로 이해하면 Claude를 외부 서비스에 연결하는 범위가 크게 넓어집니다.
Model Context Protocol: Advanced Topics: MCP 입문 다음 단계입니다. Sampling(서버가 AI에 역으로 요청하는 방식), 비동기 알림, 파일 시스템 접근, 프로덕션 배포에 필요한 Transport 메커니즘 같은 심화 내용을 다룹니다.
Introduction to Agent Skills: Claude Code에서 재사용 가능한 스킬을 마크다운으로 만들고 팀 단위로 배포하는 방법을 다룹니다. 스킬을 한 번 만들어두면 Claude가 적절한 작업에 알아서 적용합니다. 분량이 짧아서 Claude Code in Action과 함께 첫 주에 바로 끝낼 수 있습니다.

비개발자에게는 이 세 가지가 눈에 띕니다.

Claude 101: 일상 업무에서 Claude를 어떻게 활용하는지, 핵심 기능은 무엇인지를 다루는 입문 과정입니다. 퀴즈를 통과하면 수료증도 발급됩니다. Claude를 매일 쓰고 있다고 해도 Anthropic이 의도한 사용법과 실제 내가 쓰는 방식 사이에 간극이 있을 수 있습니다. 이 강의가 그 간극을 보여줍니다.
AI Fluency: Framework & Foundations: AI를 효과적으로, 그리고 안전하게 활용하는 사고 방식을 다룹니다. 특정 도구 사용법이 아니라 AI와 협업하는 프레임워크를 배우는 과정이라 직군을 가리지 않고 도움이 됩니다.
AI Fluency 시리즈: 교육자, 학생, 비영리 단체 종사자를 각각 별도 과정으로 나눠서 다룹니다. 자기 역할에 맞는 과정을 골라 들을 수 있습니다.

클라우드 환경에서 Claude를 연동해야 한다면,

AWS용 Claude with Amazon Bedrock
Google Cloud용 Claude with Vertex AI가 각각 따로 있습니다.

어떻게 시작하나요?

anthropic.skilljar.com에 접속해서 Skilljar 계정으로 로그인하면 됩니다. 강의는 영어로 진행되지만 번역 기능을 활용하면 됩니다. Coursera에서도 동일한 강의를 들을 수 있고, Coursera 버전에는 AI 학습 도우미와 추가 퀴즈가 포함돼 있습니다.

실행해볼 수 있는 것

지금 가장 자주 쓰는 Claude 기능을 먼저 떠올려보고, 그걸 더 깊게 다루는 강의 하나만 골라서 들어보세요. Claude 101처럼 짧은 과정은 1~2시간이면 완료됩니다. 팀에서 Claude 도입을 고민 중이라면 AI Fluency: Framework & Foundations를 팀원에게 공유해보는 것도 방법이고요.

정리

이 내용을 기억해두면 좋습니다

AI 도구 하나를 쓰는 건 이제 어렵지 않습니다. 어려운 건 그 도구를 내 워크플로에 붙이는 일이죠. gogcli는 Google Workspace를 CLI 하나로 에이전트에 연결할 수 있게 만들었고, Codex 앱 Windows 버전은 에이전트가 돌아가는 동안 다른 작업을 병렬로 던질 수 있게 했습니다. 둘 다 같은 지점을 건드립니다. AI에게 맡길 수 있는 범위를 넓히는 것이죠.
Anthropic Courses는 조금 다른 결입니다. 도구를 늘리는 게 아니라 지금 쓰는 도구를 제대로 쓰는 방법을 알려주는 거니까요. 새로운 걸 추가하기 전에 지금 손에 있는 것부터 깊게 파는 선택지입니다.
이번 주 세 소재를 묶어서 보면 하나의 방향이 보입니다. 모두 진입 장벽을 낮추는 쪽이거든요. Codex Windows는 샌드박스를 새로 만들어가며 플랫폼을 넓혔고, gogcli는 API 연동의 복잡함을 명령어 한 줄로 감췄고, Anthropic Courses는 공식 지식을 무료로 열었습니다. 무엇을 할 수 있는지의 경계가 계속 바뀌고 있는 겁니다. 장벽이 낮아질수록 차이를 만드는 건 도구가 아니라 그걸 얼마나 깊이 쓰느냐가 됩니다.

이렇게 적용해보세요

Claude Code나 에이전트 워크플로에 Google 서비스 연동이 필요하다면, MCP 세팅보다 gogcli를 먼저 써보세요. 설치와 인증만 되면 바로 쓸 수 있습니다.
Claude를 매일 쓰는데 아직 공식 강의를 들어본 적 없다면, Anthropic Courses에서 자신의 역할과 가장 가까운 강의 한 개만 먼저 들어보세요. 이미 잘 쓰고 있다고 생각해도, 모델을 만든 팀이 의도한 방식과 실제로 내가 쓰는 방식 사이에는 생각보다 간극이 있을 수 있습니다.
에이전트한테 작업을 던질 때, 끝날 때까지 기다리는 대신 그 시간에 다른 에이전트 스레드를 하나 더 돌려보세요. 대기 시간이 작업 시간으로 바뀔 수 있습니다.

콘텐츠가 마음에 드셨다면, 꼭 작가 알림 설정을 부탁드립니다!

]]>

AI 시대에도 브라우저는 Chrome만 써야 해요?

우리는 하루에도 수십 번 브라우저를 엽니다. 그런데 이토록 빠르게 변하는 IT 시장에서 브라우저가 주는 경험은 의외로 10년째 비슷합니다. 우리는 같은 루틴을 반복합니다. 찾고(검색) → 읽고(클릭) → 정리(메모/북마크)하는 일이죠. 그렇게 탭은 계속 늘어나고, 검색 결과에는 광고가 가득합니다.

이 불편한 흐름이 바뀌지 않는 이유가 있습니다. 브라우저의 기본 골격이 너무 강력하기 때문입니다. 검색하고, 링크를 누르고, 페이지를 보는 구조는 웹을 굴려온 표준입니다. 건물의 뼈대가 워낙 튼튼해 인테리어만 바뀐 셈입니다. 그마저도 이제는 가장 잘 하는 집, Chrome이 모두 꽉 잡았고요.

하지만 AI가 등장했습니다. 모든 것의 근본을 바꿔버리는 기술답게 브라우저의 뼈대 자체를 흔들기 시작했죠. 대표적으로 나타난 새로운 브라우저는 Perplexity의 Comet, The Browser Company의 Dia 등이 있습니다. 이들의 실험이 노리는 건 기능 몇 개 추가해 편리하게 만드는 게 전부가 아닙니다. 웹을 다루는 방식, 즉 “우리는 웹을 어떻게 소비하고 정리할 것인가”를 다시 묻는 것입니다.

그래서 이제 질문은 이렇게 바뀝니다. 브라우저는 여전히 ‘웹을 보여주는 창’이어야 할까요?

<출처: 작가, Gemini로 생성>

우리는 왜 이런 방식으로만 브라우저를 쓰는 걸까?

누구나 브라우저를 쓰는 방식은 크게 다르지 않습니다. 왜 그럴까요?

웹의 시작점인 ‘검색’과 기본 계약

사용자는 검색창에 질문을 던집니다. 하지만 검색이 주는 건 보통 정답이 아니라 클릭할 후보입니다. 즉, 검색은 결론이 아니라 탐색의 출발점에 가깝습니다. 그래서 우리는 자연스럽게 여러 페이지를 오가며 스스로 답을 조립해야만 합니다.

여기에 광고와 SEO가 강하게 끼어들면 상황은 더 복잡해집니다. 무엇이 믿을 만한지 직접 비교하고 검증해야 하니까요. 그 결과는 뻔합니다. 더 많은 페이지를 열고 더 오래 브라우저에 머뭅니다. 탭 수가 늘어나는 건 게으름이 아니라 구조가 만든 노동입니다.

웹의 시작점인 ‘검색’과 기본 계약

페이지 단위 UI에 길들여진 우리

그렇게 클릭을 유도하는 이유가 있습니다. 웹이 처음부터 문서(페이지)들의 네트워크로 설계됐기 때문입니다. 브라우저는 그 문서를 충실히 렌더링(화면에 그려 보여주기)하는 도구로 발전해 왔고요. 쉽게 말해, 브라우저는 작업 도구라기보다 문서 뷰어에 가깝게 자라난 셈입니다. 그래서 지금도 웹 경험의 기본 단위는 여전히 페이지입니다.

탭이라는 구조 역시 이에 딱 맞는 사용자 습관을 만들어냈습니다. 일단 열어두고 나중에 판단하는 방식이죠. 문제는 탭이 문제 해결의 기록이 아니라 미뤄둔 판단의 창고가 되기 쉽다는 점입니다. 탭이 늘어날수록 우리는 정보를 처리하기보다 보관하게 됩니다.

왜 ‘AI 기능 추가’로는 체감이 안 바뀔까?

이런 한계를 깨면서, 또 제품으로의 역할을 강화하고자 요즘 브라우저는 AI를 붙이기 시작했습니다. 예를 들면 요약 버튼, 문장 다듬기 같은 기능입니다. 물론 편하기는 편하지만, 본질적으로 클릭 기반과 탭이라는 그 한계는 깨지지 않습니다. 이런 AI도 역시 대개 페이지 위에 얹는 보조 도구로 남기 쉽습니다. 페이지라는 기본 단위는 그대로인데, 그 위에 작은 도구만 추가되는 셈이죠.

하지만 사용자의 고통은 버튼이 부족해서가 아닙니다. 진짜 피로는 검색 → 클릭 → 탐색이 길고 반복적이라는 데 있습니다. 몇 번의 클릭으로도 끝나지 않는 탐색에 쌓이고 만 탭으로 우리는 맥락을 잃습니다. 그래서 AI를 넣었다는 사실보다, 이 흐름 자체를 바꾸느냐가 더 중요해집니다.

Chrome: 웹을 가장 잘 보여주는 브라우저

이런 관점을 머리에 넣어 둔 채로, Chrome이 강한 이유를 정리하면 “웹이 가장 안 깨지는 브라우저”라는 문장이 나옵니다. 사람들은 브라우저에서 새로운 경험을 얻기보다 오늘도 평소처럼 잘 열리고 잘 결제되고 잘 로그인되는 걸 더 원합니다. 브라우저는 재미있는 앱이라기보다 매일 쓰는 수도꼭지 같은 도구라서 그렇습니다. 한번 익숙해지면 바꿀 이유가 잘 생기지 않습니다.

Chrome

Chrome이 공략한 것도 이런 습성에 있습니다.

렌더링+속도+호환성의 끝판왕

대부분의 사용자는 브라우저에서 새로움보다 "깨지지 않는가?"를 먼저 봅니다. 회사 사이트가 하얗게 뜨거나, 결제창이 멈추거나, 글자가 깨지면 그날 업무가 멈추기 때문입니다. 그래서 브라우저의 핵심 가치는 멋진 기능이 아니라 문제 없이 돌아가게 만드는 안정감입니다.

링크를 누르면 페이지가 열리고, 검색을 거치며, 여러 사이트를 오간다는 '경험의 계약' 안에서라면, Chrome은 여전히 가장 무난한 선택지입니다. 바꿔도 더 좋아지기보다 어딘가에서 삐걱댈 확률이 먼저 떠오릅니다. 렌더링과 속도, 호환성 모두 Chrome만한 곳이 없습니다.

Google 계정 통합과 잠금 효과

브라우저를 바꾸는 순간 생기는 마찰은 또 있습니다. 새 브라우저의 설정을 익히고, 북마크를 옮기고, 비밀번호를 다시 믿어야 합니다. 게다가 이 과정은 한 번만 하면 끝나는 일이 아닌 쓰는 내내 ‘찜찜함’으로 남습니다. 그래서 많은 사람은 그냥 쓰던 거를 선택합니다.

Chrome은 이 마찰을 Google 계정으로 더 단단히 묶습니다. 로그인, 동기화, 비밀번호, 북마크, 결제 같은 일상 동선이 계정에 붙어 있습니다. 특히 모바일에서도 같은 경험이 이어지니 바꾸는 순간 손해가 더 크게 느껴집니다. 브라우저가 아니라 생활 습관을 옮겨야 하는 셈입니다.

확장 프로그램 생태계가 가진 힘

무엇보다 확장 프로그램은 진짜 멋진 방식입니다. 덕분에 Chrome은 단순한 앱이 아니라 플랫폼이 됩니다. 사람마다 필요한 기능이 달라도 조립식으로 맞춰 쓰게 해주죠. 누군가는 광고 차단이 중요하고, 누군가는 캡처나 번역이 더 급하다 해도 괜찮습니다. 팀 단위로는 보안 도구나 협업 도구가 붙기도 합니다.

더 강력한 지점은 “내가 원하는 기능을 누군가 이미 만들어뒀다”는 사실입니다. Chrome은 기본 기능만으로도 충분히 안정적인데 거기에 다른 사람들이 만든 부품이 계속 쌓입니다. 그래서 어느 순간부터는 Chrome에서만 가능한 방식이 생깁니다. 이건 제품 기능이 아니라, 생태계가 만드는 관성입니다.

그래서, 우리는 브라우저를 계속 이대로 써야 할까?

그래서 질문이 생깁니다. 브라우저는 계속 “웹을 보여주는 창”이어야 할까요?

사실 검색 → 클릭 → 탐색에서는 Chrome을 넘을 수 없다

그렇게 Chrome은 검색 → 클릭 → 탐색 흐름을 가장 효율적으로 수행합니다. 주소창에서 검색하고, 탭을 열고, 다시 검색하고, 필요한 정보를 찾는 반복이죠. 이 루틴이 지루해도 현실적으로 가장 많이 쓰이는 웹 사용 방식입니다. Chrome은 그 반복을 빠르고 익숙하게 굴립니다. 그래서 솔직히 같은 경험을 주는 브라우저에서 다른 것을 굳이 추천할 필요가 있나 싶기도 합니다.

다만 사용자의 고통이 탐색 과정이 길고 반복적이라는 데 있다면 이야기는 다릅니다. 결국 Chrome의 왕좌는 이 흐름이 유지되는 한 단단하고, 이 흐름이 바뀌는 순간부터 흔들릴 수 있으니까요.

그래서 새로 나타난 브라우저들

최근 AI와 함께 나타난 브라우저들이 던지는 메시지는 조금 다릅니다. 브라우저가 단순히 페이지를 띄우는 도구가 아니라 “웹을 읽어주는 비서”가 될 수 있다는 겁니다. 사용자가 링크를 하나씩 열어보는 대신 필요한 핵심을 먼저 정리해 주고 다음 행동을 제안하는 식이죠.

한 발 더 나아가면, 브라우저는 “웹에서 이뤄지는 일을 처리하는 작업 공간”이 될 수도 있습니다. 읽고 끝나는 게 아니라 모으고 정리하고 실행하는 흐름까지 브라우저 안에서 이어지는 형태입니다. 지금은 탭이 늘어날수록 머릿속도 복잡해지지만, 작업 공간형 브라우저는 그 복잡함을 구조로 바꾸려 합니다. 브라우저가 소비 도구에서 생산 도구로 이동하는 셈입니다.

이 변화의 핵심은 AI 버튼이 몇 개 더 붙느냐가 아닙니다. AI가 웹 사용 경험의 반복을 깨주는 겁니다. 그 반복 자체를 재설계하면, 브라우저의 정의도, Chrome의 왕좌도 흔들릴 수 있습니다.

Comet: ‘검색’을 없애기보다 ‘탐색’을 압축하는 브라우저

여러분은 오늘 탭을 몇 개나 여셨나요? 검색 결과에서 광고를 피하고, 비슷한 글을 여러 개 훑고, 결국엔 메모장에 핵심만 다시 옮기는 일. 이 과정 자체가 사실상 노동입니다. 문제는 우리가 ‘정보’를 찾는 게 아니라 ‘판단’을 만들기 위해 웹을 헤집고 있다는 점입니다.

Comet

“페이지 여러 개 열어 비교하는 그 자체가 노동”

Perplexity의 Comet이 노리는 지점은 딱 여기입니다. 여러 페이지를 직접 열어 읽는 대신 요약을 먼저 보여주고 출처를 함께 제시해 탐색 시간을 압축하려 합니다. “읽기”를 줄이고 “판단”에 시간을 쓰게 만드는 설계입니다. 검색을 없애겠다는 선언이라기보다 검색 뒤에 붙는 반복 작업을 줄이겠다는 쪽에 가깝습니다.

이 관점에서 Comet은 브라우저를 다시 정의합니다. 브라우저가 그동안 해온 일은 ‘웹을 보여주는 창’이었습니다. 그런데 Comet은 브라우저를 웹 탐색 도구가 아니라 판단 보조 인터페이스로 옮겨놓으려 합니다. 창을 더 크게 만드는 게 아니라 결론까지의 길을 짧게 만드는 식입니다.

그래서 사용자 역할도 달라집니다. 예전에는 페이지를 많이 읽는 사람이었다면, 이제는 요약과 출처를 바탕으로 판단하는 사람이 됩니다. 탭을 관리하는 능력보다 요약을 검증하고 비교하는 감각이 더 중요해집니다. 브라우저 경험이 바뀐다는 말은 결국 사용자의 일이 바뀐다는 뜻입니다.

Comet의 핵심 설계 포인트와 그 다음 지점들

다만 요약이 늘 유용한 건 아닙니다. 요약이 힘을 가지려면 출처 투명성이 먼저 확보돼야 합니다. 어떤 문장이 어디에서 왔는지, 인용이 명확해야 사용자가 안심하고 판단할 수 있습니다. 또 한 가지는 비교 관점입니다. 한 답만 주는 요약이 아니라 선택지를 나란히 놓아줄 때 탐색이 진짜로 압축됩니다.

반대로 압축된 탐색에는 부작용도 따라옵니다. 요약은 빠르지만, 종종 맥락 손실을 만들 수 있습니다. 그래서 사용자는 결국 “문을 확인하고 싶다는 욕구를 갖게 됩니다. 게다가 요약이 어떤 관점을 중심으로 묶였는지에 따라 특정 관점 편향 위험도 생깁니다. 빠른 결론이 항상 좋은 결론은 아닙니다.

또 하나의 충돌 지점은 웹 생태계입니다. Comet이 잘 작동할수록 사용자는 덜 클릭하게 됩니다. 즉 클릭 감소가 사용자에겐 편해도 퍼블리셔와 광고 기반 구조에는 부담이 될 수 있습니다. 브라우저가 탐색을 압축하면 웹은 방문이 아니라 참조로 소비될 가능성이 커집니다.

진짜 원하는 것이 맞는가?

여기서 질문이 하나 남습니다. 당신이 브라우저에서 진짜 원하는 건 더 많은 탭을 열 자유일까요? 아니면 결론까지의 거리, 즉 결론에 도달하는 시간을 줄이는 걸까요? Comet은 전자를 늘리는 대신 후자를 줄이겠다고 말합니다. 그리고 그 선택이 맞는지 여부가 AI 브라우저를 평가하는 첫 기준이 될 겁니다.

Dia: 브라우저를 ‘작업 공간’으로 만드는 재설계

브라우저를 켜고 탭을 몇 개 열다 보면 어느 순간 화면이 나중에 볼 것로 가득 찹니다. 이 탭 더미는 정보 저장소라기보다 미완료 작업 목록에 가깝습니다. “이거 읽고 정리해야지”, “이거 비교해야지” 같은 할 일이 탭으로 쌓이는 거죠. 그래서 많은 사람에게 브라우저는 이미 조용한 작업 관리자로 쓰이고 있습니다.

Dia

탭은 정보가 아니라 ‘미완료 작업’

Arc 브라우저를 만들었던 The Browser Company의 새 브라우저, Dia가 만드는 흐름은 여기서 출발합니다. 브라우저를 페이지를 보는 곳이 아니라 웹 기반 작업 환경으로 다시 정의하자는 겁니다. 탭을 많이 여는 능력이 아니라 일을 끝내는 동선을 설계하자는 이야기입니다. 탭을 ‘페이지’가 아니라 ‘업무 단위’로 다루려는 시도도 이 맥락에 있습니다.

이 재설계의 핵심은 탭 개념을 바꾸는 데 있습니다. 예전에는 탭이 지금 보고 있는 페이지였다면, 이제는 이 프로젝트에 필요한 재료가 됩니다. 공간이나 프로젝트 단위로 묶고, 흐름을 정리해두면 다시 찾는 비용이 줄어듭니다. 관점이 페이지 중심에서 업무 중심으로 이동하는 셈입니다.

여기서 AI 기능의 가치도 달라집니다. 많은 AI 브라우저가 요약을 앞세우지만, 진짜 쓸모는 읽는 시간을 줄이는 데만 있지 않습니다. 더 중요한 건 정리→재사용입니다. 요약이 메모가 되고, 메모가 다음 문서의 재료가 될 때 AI가 빛을 봅니다.

Dia가 노리는 경험: 모으고, 정리하고, 실행하기

이 브라우저가 대신 해주는 첫 단계는 정보를 모으는 일입니다. 웹에는 재료가 흩어져 있고, 우리는 그걸 탭으로 주워 담습니다. Dia가 노리는 건 이 수집을 주제별로 묶고 핵심을 뽑아두는 경험입니다. 탭을 열었다라는 경험이 아니라 자료가 정리된 묶음이 생겼다는 경험으로 바꾸는 거죠.

두 번째는 정리입니다. 보통 요약은 브라우저에서 하고, 메모는 다른 앱에서 하고, 공유는 또 다른 곳에서 합니다. 하지만 이 방식은 맥락을 계속 끊어 먹습니다. 그래서 요약, 메모, 태깅, 공유가 브라우저 안에서 끝나야 한다는 주장이 나옵니다. 브라우저를 작업의 중간 지점 대신 정리의 본진으로 쓰는 겁니다.

세 번째는 실행입니다. 브라우저에서 정리까지 해놓았다 해도 결국 실무를 하다 보면 문서 작성은 따로 하고 회의 준비는 또 따로 합니다. 여기서 Dia가 노리는 흐름은 정리된 것이 바로 다음 행동으로 이어지는 동선입니다. 예를 들어 문서 초안을 만들거나, 회의 안건을 뽑거나, 비교표를 만드는 식입니다. 브라우저가 소비에서 생산으로 넘어가는 관문이 되겠다는 뜻입니다.

진짜 원하는 것이 맞는가?

다만 이 방향이 모두에게 정답인지는 따져봐야 합니다. 브라우저는 매일 쓰는 도구라서, 새로운 UI의 낯섦이 생각보다 치명적입니다. 손에 익은 단축키와 습관이 무너지면 생산성이 바로 떨어집니다. “좋아 보이는데 못 쓰겠다”가 가장 흔한 실패 시나리오입니다.

또 하나는 조직에서의 문제입니다. 혼자 쓰기 좋은 도구와, 팀이 쓰기 좋은 도구는 다릅니다. 브라우저가 개인 작업 공간으로 진화할수록, 팀에서는 표준화가 어려워질 수 있습니다. 결국 내 브라우저가 강해질수록 우리 팀의 공통 방식은 약해질 수 있습니다.

그래서 Dia가 던지는 질문은 기능이 아니라 선택에 가깝습니다. 우리는 브라우저에서 더 많은 탭을 열 자유를 원하는 걸까요, 아니면 결론까지의 거리를 줄이는 걸까요. 브라우저가 작업 공간이 되면 분명 편해질 수 있습니다. 하지만 그 편함이 학습비용과 협업비용을 넘어설 만큼 큰지, 그게 다음 관문입니다.

보여주기 vs 읽어주기 vs 정리하고 실행하기

요즘 브라우저 경쟁은 누가 기능이 많나의 싸움이 아닙니다. 핵심은 브라우저가 웹 앞에서 어떤 역할을 맡을지입니다. 같은 웹을 보더라도, 어떤 브라우저는 “보여주기”에 집중하고, 어떤 브라우저는 “읽어주기”로 시간을 줄이며, 또 다른 브라우저는 “정리하고 실행하기”로 일을 끝내려 합니다. 이 관점으로 보면 흐름이 꽤 또렷해집니다.

브라우저로 알아보는 우리가 원하는 “일”

Chrome은 웹을 보여주는 데 최적화된 브라우저입니다. 많은 사이트에서 잘 돌아가는 호환성, 빠릿한 속도, 촘촘한 확장 프로그램이 강점입니다. 무엇보다 ‘기본값’ 자리를 오래 지켜 왔습니다. 그래서 대부분의 사람에게 Chrome은 일단 열면 되는 브라우저가 됩니다.

Comet은 웹을 읽어주고 압축하는 쪽에 가깝습니다. 쉽게 말해, 여러 페이지를 왔다 갔다 하며 찾는 비용을 줄이려는 접근입니다. 질문을 던지면 핵심을 요약하고, 판단에 필요한 근거를 붙여 탐색 비용을 낮춥니다. 브라우저가 단순한 창이 아니라 판단 보조 인터페이스가 되려는 시도입니다.

Dia는 웹을 정리하고 실행하는 방향을 봅니다. 탭을 늘어놓는 대신, 웹을 작업 단위로 묶어 작업 공간화하려 합니다. 읽고 끝나는 게 아니라, 정리하고 다음 행동으로 이어지게 만드는 생산성 지향이 핵심입니다. 브라우저를 ‘소비 도구’가 아니라 ‘일하는 환경’으로 바꾸려는 접근입니다.

마치며

Chrome은 여전히 브라우저 시장의 왕좌에 앉아 있습니다. 점유율, 확장 프로그램 생태계, 그리고 많은 기기에 ‘기본’으로 깔리는 지위가 단단하기 때문입니다. 하지만 역설적으로, 이런 왕좌는 인터페이스가 바뀌는 순간 생각보다 빨리 흔들릴 수 있습니다. 검색하고, 탭을 관리하고, 정보를 정리하는 방식이 바뀌면 사람들이 브라우저를 고르는 기준도 같이 바뀌기 때문입니다.

그래서 이게 나와 무슨 상관이냐고요? 다음 일주일만, 스스로를 한 번 관찰해보면 좋겠습니다. 내가 브라우저에서 제일 오래 하는 일이 검색/클릭인지, 읽기인지, 정리/재사용인지 간단히 기록해보는 겁니다. 브라우저는 늘 켜져 있어서 습관을 자각하기 전엔 불편이 잘 안 보입니다. 그런데 한 번만 분류해보면 어떤 변화가 내게 필요한지 바로 드러납니다. 그리고 만약 지금 내게 브라우저가 불편하다면요? 새로운 도구를 적용해 보는 거죠. 그것만으로 웹을 소비하는 방식이 달라질 테니까요.

앞으로의 브라우저는 “웹의 입구”로 남을까요, 아니면 “웹에서 일을 끝내는 장소”가 될까요? 그리고 Chrome은 그 변화를 기능 추가로 흡수할까요, 아니면 정의 자체를 다시 쓸까요? 다음 인터페이스 전환을 미리 아는 것만으로 AI가 보여줄 미래에 한 발 빨리 도착할 수 있을 겁니다.

]]>

40대 비개발자, 어떻게 해커톤에서 대상을 탈 수 있었을까?

저는 바이브 코딩으로 월 300만 원의 부수입을 얻고 있다는 경험을 나눴고, 많은 분들이 응원해 주셨는데요. 한편으로는 일부 걱정 어린 의견도 있었습니다. 솔직히 말하면, 저도 같은 의문이 들었죠. 바이브 코딩으로 만든 것들이 정말 괜찮은 건지, 내가 잘하고 있는 게 맞는지 등 혼자 공부하고 만들다 보니, 비교 대상이 없어서 제 실력이 어느 정도인지 알 수 없었습니다.

"나 지금 잘하고 있는 건가?"라는 질문이 머릿속을 맴돌았죠. 그러다 지난해 말 ‘해커톤(Hackathon)’이라는 대회가 있다는 걸 알게 됐습니다. 해커톤은 해킹(Hacking)과 마라톤(Marathon)의 합성어로, 개발자, 디자이너, 기획자가 팀을 이뤄 제한된 시간(보통 24~48시간) 내에 아이디어를 기획하고, 시제품(프로토타입) 형태의 결과물을 만들어내는 ‘끝장 개발 대회’입니다. 그러나 바이브 코딩의 등장으로 개인이 참가하거나, 더 짧은 시간 이내에 결과물을 만들어낼 수 있게 되었고, 다양한 형태로 대회가 열리고 있습니다.

해커톤이란 동일한 조건에서 다른 사람들과 경쟁하며, 내 실력을 확인할 수 있는 기회인데요. 저도 말로만 "된다, 안 된다" 하기보다는 직접 부딪혀서 문제를 정의하고, 제한된 시간 안에 돌아가는 결과물을 만들어내는 능력을 확인해 보고 싶었습니다. 이건 해커톤이든, 외주 개발이든, 실무에서든 똑같이 필요한 능력이니까요. 결과적으로 두 번의 해커톤에 나갔고, 두 번 다 대상을 받았습니다. 이번 글에서는 비개발자로서 해커톤에 참여했던 경험을 나눠보려고 합니다.

<출처: 작가>

왜 해커톤이었나

처음에는 내가 개발 대회에 나가도 되는지 우려됐습니다. 하지만 생각해 보니 꼭 결과만을 위해서라기 보다 그 과정 자체를 즐기고, 스스로를 점검해 보는 시간이라 생각해 지원하게 됐죠. 다양한 연령대와 배경의 사람들에게서 받는 자극, 다른 참가자들의 아이디어를 보며 배우는 시간, 그리고 주어진 시간 내에 결과물을 완성시키는 과정 자체의 재미도 기대됐습니다.

"일단 한번 부딪혀보자." 그렇게 첫 해커톤을 신청했습니다.

첫 번째 해커톤: 경기도 기후 바이브 코딩 해커톤

개발 트랙을 선택하다

첫 번째로 도전한 해커톤은 경기도에서 주관한 기후 관련 바이브 코딩 해커톤이었습니다. 참가 트랙이 두 개였는데, 일반 트랙은 오전에 교육을 받고 오후에 해커톤을 진행하는 방식이었고, 개발 트랙은 하루 종일 해커톤만 진행하는 방식이었습니다. 일반 트랙이 안전한 선택이었지만, 몇 개월간 바이브 코딩을 해봤으니 "이 정도면 해볼 만하지 않을까?" 하는 자신감으로 개발 트랙에 도전해 보기로 했습니다.

<출처: 경기 기후 바이브 코딩 해커톤 홈페이지(왼), 작가 촬영(오)>

600개의 데이터 앞에서 막막해지다

문제는 주제였습니다. 대회 측에서 제공한 데이터가 600개가 넘었습니다. 경기도의 기후 관련 데이터였는데, 대기질, 기온, 습도, 미세먼지, 자연재해 기록까지 종류가 정말 다양했습니다. 이 데이터들을 조합하여 어떻게 결과물을 보여줘야 할지 당일 아침까지도 정하지 못했습니다. 대회장에 도착해서도 계속 데이터 목록만 들여다봤습니다. 시간은 흘러가고, 점점 초조함이 밀려왔습니다.

<출처: 경기 기후 바이브 코딩 해커톤 홈페이지>

다들 코딩할 때 기획에 집중

대회가 시작되고, 주변을 둘러봤습니다. 다른 참가자들은 이미 노트북을 열고 코딩을 시작하고 있었습니다. 키보드 소리가 여기저기서 들렸습니다. "나만 뒤처지는 건가?" 잠깐 불안했지만, 저는 다르게 하기로 했습니다. 코딩 대신 AI와 대화를 시작한 겁니다.

Claude에게 물었습니다. "이 데이터들로 어떤 서비스를 만들 수 있을까?" 답변을 받고, 같은 질문을 Gemini에게 했습니다. 그다음엔 GPT에게. 세 AI의 답변을 비교하며 아이디어를 발전시켰습니다. 어떤 AI는 창의적인 아이디어를 제안했고, 어떤 AI는 현실적인 제약을 잘 짚어줬습니다. 여러 관점을 종합하니 기획이 단단해졌습니다. 또 이 대회는 AI 심사가 30%를 차지했습니다. 그래서 AI에게 물었죠.

"AI가 심사한다면 어떤 요소를 높이 평가할까?"

그 답변을 바탕으로 기획안에 요소들을 녹여 넣었습니다. 데이터 활용의 창의성, 사용자 경험, 실용성 같은 것들이었죠. 그렇게 오전 내내 기획만 하고, 정오가 다 되어서야 개발을 시작했습니다. 개발 시간은 5시간인데 절반을 기획에 쓴 셈입니다. "이러다 시간 안에 못 끝내는 거 아니야?"라고 불안하지 않았다면 거짓말입니다. 하지만 저는 탄탄하게 기획해야 AI를 통해 좋은 결과물을 얻을 수 있다고 믿었습니다. "무엇을 만들 것인가"가 명확하면 AI에게 지시하기도 쉬워지니까요.

기후 건강검진 서비스

최종적으로 만든 건 "우리 동네 기후 건강검진" 서비스였습니다. 기후 데이터를 기반으로 지역의 기후 건강 상태를 진단하고, AI가 지역별 "기후 처방전"을 발행해 주는 서비스였습니다. 예를 들어, 폭염 취약 지역에는 쿨링센터 확충을, 대기질 문제 지역에는 녹지 확대를 처방하는 식이죠.

<출처: 작가>

기대하지 않았던 대상

제출을 마치고 초조하게 결과를 기다렸습니다. 수많은 개인과 팀이 참가했기에 솔직히 수상은 기대하지 않았습니다. "비개발자가 개발 트랙에서 완주했다, 그것만으로 충분해." 시상식이 시작됐습니다. 우수상, 최우수상이 차례로 발표됐습니다. 제 이름은 불리지 않았습니다. "그래, 여기까지 온 것만으로도 잘했어." 스스로를 다독이고 있었습니다. 그런데 대상 발표에서 제 이름이 불렸습니다. 몇 번이고 다시 들었습니다. 정말 제 이름이 맞나 싶었습니다. 40대 비개발자가 개발 트랙에서 대상이라니, 아직도 그날 집으로 가던 길이 잊혀지지 않습니다. 정말 꿈만 같았죠.

두 번째 해커톤: 바이트댄스 TRAE 해커톤

대회 3일 전 공개된 주제

두 번째는 틱톡의 모회사 바이트댄스에서 만든 AI IDE, ‘TRAE’를 활용하는 해커톤이었습니다. 120명이 참가했고, 경쟁이 치열했습니다. 주변을 둘러보니 다들 능숙하게 자기 장비를 세팅하고 있었습니다. "이번 대회도 쉽지 않겠다." 잠깐 그런 생각이 스쳤지만, 첫 해커톤에서 배운 게 있었습니다.

<출처: 바이트댄스 TRAE 해커톤 공식 홈페이지(왼), 작가 촬영(오)>

이 대회는 주제가 3일 전에 공개됐습니다. 저는 바로 AI들과 대화를 시작했습니다. 첫 해커톤에서 깨달은 기획 노하우를 적용해서 Claude, Gemini, GPT를 돌아가며 아이디어를 크로스 체크했습니다.

"이 주제로 어떤 서비스를 만들 수 있을까?"
"각각의 장단점은?"
"심사위원이 높이 평가할 만한 요소는?"

마음에 드는 기획이 나왔을 때, 조금 기대가 생겼습니다. "이번에도 해볼 만하겠는데?"

새로운 도구, 새로운 경험

평소에는 Cursor만 사용했는데, 이번엔 TRAE를 써야 했습니다. "익숙하지 않은 도구 때문에 시간 잡아먹으면 어쩌지?" 걱정도 됐지만, 막상 사용해 보니 걱정이 무색했습니다. AI Agent IDE들이 상향 평준화되어 가고 있다는 걸 느꼈고, 오히려 새로운 도구를 배우는 경험이 즐거웠습니다.

<출처: 바이트댄스 TRAE 해커톤 공식 홈페이지>

다이어리 분석 서비스

이번에 제가 만든 건 AI 다이어리 분석 서비스였습니다. 사용자가 쓴 다이어리를 AI가 분석해서 감정 패턴과 인간관계를 시각화해 주는 웹 애플리케이션이었습니다. "오늘 친구와 점심을 먹었다. 오랜만에 만나서 반가웠다." 이런 일기를 쓰면, AI가 분석해서 "이 친구와의 관계 점수", "이번 달 감정 추이" 같은 걸 보여주는 거죠.

<출처: 작가>

두 번째 대상

심사위원 평가 50%, AI 평가 50%로 진행됐습니다. 발표를 마치고 결과를 기다렸습니다. 살짝 기대는 했지만, 120명이 참가한 치열한 경쟁이었기에 확신은 없었습니다. 그런데 또 제 이름이 대상에 불렸습니다. 첫 번째는 우연이었을지도 모릅니다. "운이 좋았어"라고 생각할 수도 있었습니다. 하지만 두 번째도 대상을 받으니, 그건 운만으로 설명할 수 없었습니다.

"내가 뭔가 제대로 하고 있구나." 스스로에 대한 자신감이 생겼습니다. 바이브 코딩으로 1년간 해온 것들이 헛되지 않았다는 확신이 들었죠.

비개발자가 해커톤에서 경쟁력을 갖는 법

1) 기획에 시간을 써라

해커톤은 결과물을 제출하는 게 목표이긴 하지만, 대부분의 사람들이 어쨌든 제출까지는 해냅니다. 그래서 결과물의 완성도 자체보다 기획이 얼마나 대회 의도에 정확히 맞는지에서 갈리는 경우가 많습니다. 시간도 짧은 만큼 심사위원들도 ‘완벽한 제품’을 기대하기보다는, 기본 MVP 수준으로도 문제·해결·핵심가치를 명확히 보여주는 기획을 더 중요하게 봅니다.

2) AI를 크로스 체크에 활용하라

저는 하나의 AI만 쓰지 않았습니다. Claude, Gemini, GPT에 같은 질문을 던지고 답변을 비교했습니다. 마치 여러 전문가에게 동시에 자문을 구하는 것처럼요. 어떤 모델은 발상이 뛰어나고, 어떤 모델은 현실적인 제약과 리스크를 더 정확히 짚어줍니다. 이렇게 서로 다른 관점을 교차 검증해 종합하니, 기획이 훨씬 더 탄탄해졌습니다.

3) AI 심사를 고려하라

요즘 해커톤은 AI 심사가 포함되는 경우가 많습니다. AI가 어떤 기준으로 평가하는지, AI가 좋아할 만한 요소가 뭔지 미리 파악하고 기획에 반영했습니다. 이것도 AI에 물어보면 됩니다. "AI가 심사한다면 어떤 프로젝트를 높이 평가할까?" 이 질문 하나로 기획의 방향이 달라질 수 있습니다.

해커톤, 어떻게 시작하나요?

정보 찾는 법

SNS: X(트위터), 링크드인에서 "해커톤", "바이브 코딩" 검색
카카오톡 오픈채팅방: AI/개발 관련 커뮤니티
플랫폼: 데이콘, 캐글, 공공데이터포털, Devpost 등
AI에 최신 해커톤 정보 찾아달라고 요청하기

해커톤이 처음이라면

해커톤에 처음 참여한다면 규모가 작은 대회부터 시작하는 걸 추천합니다. 완주 자체가 목표여도 충분합니다. 저도 첫 해커톤에서는 "끝까지 제출하는 것"이 목표였고, 수상은 기대하지도 않았습니다. 또 혼자서 참여해도 되고, 팀으로 참여해도 됩니다. 비개발자라면 기획자의 역할로 팀에 합류하는 것도 좋은 방법입니다.

마치며

두 번의 해커톤에서 느낀 건, 사람들이 정말 열정적이라는 점입니다. 짧은 시간 안에 대부분의 참가자들이 결과물을 제출하는 걸 보며 놀랐는데요. 그리고 무엇보다 해커톤이라는 문화를 경험할 수 있게 되어 좋았습니다. 짧은 시간 안에 아이디어를 구현하고, 그 결과물을 다른 사람들과 공유하고, 피드백을 주고받는 문화 말이죠. 예전이라면 개발자들만의 영역이었겠지만, 바이브 코딩 덕분에 저 같은 비개발자도 참여할 수 있게 됐습니다. 아이디어만 있으면 누구나 만들고, 공유하고, 경쟁할 수 있는 시대가 된 거죠.

특히 인상 깊었던 건 가족 단위로 참가하는 분들이었는데요. 아이와 함께 와서 해커톤에 참여하는 모습이 정말 보기 좋았고, 저도 나중에 아이가 크면 같이 와야겠다고 생각했습니다. 그리고 지난 글에서는 "시작하세요"를 강조했다면, 이번 글은 "부딪혀 보세요"라고 말하고 싶습니다.

여러분도 바이브 코딩을 시작하셨다면, 해커톤에도 한번 도전해 보세요. 수상이 목표가 아니어도 괜찮습니다. 같은 조건에서 다른 사람들과 겨뤄보는 경험, 짧은 시간 안에 집중해서 무언가를 완성하는 경험, 내 아이디어를 검증받는 경험 자체만으로도 충분히 값질 거라 생각합니다.

]]>

내 머릿속을 통째로 백업할 때 쓰는 3가지 도구

내가 읽고 배운 걸 전부 기억하고 필요할 때마다 정확히 꺼내 쓸 수 있다면 어떨까요. 일하다 “그때 봤던 자료”가 떠오르지 않아 허둥대는 일도 줄어들 겁니다. 검색창에 몇 단어만 치면 내가 과거에 정리해 둔 생각과 근거가 바로 튀어나올 테니까요. 기억을 검색할 수 있게 만들고, 필요할 때마다 다시 재사용하는 것. 인간의 오랜 욕망입니다.

이를 위해 사람들은 메모를 했습니다. 다만 메모가 쌓일수록 다시 찾는 일이 더 어려워졌죠. 그런데 이러한 메모의 한계는 AI가 등장하면서 달라졌습니다. 내가 쓴 문서를 AI가 읽고, 요약하고, 연결해 주기 시작했거든요. 상상 속 꿈이 “어쩌면 되겠다” 쪽으로 기울었습니다.

그래서 요즘 자주 나오는 말이 세컨드 브레인입니다. 아주 성능 좋은 두 번째 뇌를 만드는 거죠.

지금의 세컨드 브레인은 구현 방식이 크게 세 갈래로 나뉩니다. 첫째는 기존 문서 위에 AI를 얹는 방식, 둘째는 AI가 이해하기 좋은 구조로 내가 정리하는 방식, 셋째는 정리 자체를 AI에게 위임하는 방식입니다. 이 세 갈래를 대표 도구와 함께 비교해 보려 합니다. 어떤 방식이 더 똑똑한가보다는 어떤 방식이 내 습관과 더 잘 맞는가 살펴 보세요.

Notion: 이미 넘치는 문서 위에 AI를 얹는 방식

기가 막힌 분류와 기준으로 잘 정리해 둔 서재가 있다고 상상해 보겠습니다. 이 서재의 사서는 요청한 하면 책을 대신 읽고 요약해 주고, “그거 어디 있지?”에 답해 주고, 독후감의 초안까지 써 줍니다. 이제 책은 문서와 데이터베이스(DB), AI는 유능한 사서입니다. 요즘 메모 앱에 붙는 AI는 대체로 이 흐름을 따릅니다.

이 방식의 핵심은 순서입니다. 먼저 문서가 많이 쌓여 있고, 그 다음에 AI가 그 더미를 활용할 수 있게 바꾸는 겁니다. 그래서 이 방식은 AI가 새로 똑똑해졌다기보다 이미 강력한 문서 도구 위에 AI가 올라탄 형태에 가깝습니다.

넘치는 문서로 만드는 세컨드 브레인, Notion

그 정점에 Notion이 올라선 이유

Notion이 강한 이유는 문서와 데이터베이스가 한 공간에 공존하기 때문입니다. 회의록은 페이지로 남고, 리서치는 DB로 쌓이고, 업무 문서는 링크로 연결됩니다. 그러다 보면 일하다가 생긴 문서가 자연스럽게 자산이 됩니다. 세컨드 브레인이 되기 좋은 토양이 이미 깔려 있는 셈입니다.

또 하나는 협업과 개인 정리가 같은 판에서 돌아간다는 점입니다. 권한, 공유, 코멘트 같은 협업 워크플로우가 있고, 동시에 페이지 구조나 DB 태그로 개인 지식관리도 가능합니다. 팀 문서와 개인 메모가 섞이는 직군일수록 이 장점이 크게 느껴집니다.

AI가 가치를 내는 지점도 비교적 명확합니다. 첫째는 찾아주는 것, 둘째는 다시 써주는 것입니다. 요약, 정리, 초안 생성처럼 귀찮지만 꼭 필요한 반복 작업이 줄어듭니다.

누구에게 유리할까?

당연하게도 이 방식은 이미 자료가 많은 사람에게 특히 유리합니다. Notion이나 Evernote 같은 곳에 수년치 메모가 있다면, AI는 그걸 바로 연료로 씁니다. 새로 습관을 만들기보다 쌓아둔 것을 꺼내 쓰는 쪽에 가깝습니다.

특히 ‘개인 메모’와 ‘팀 문서’가 자주 섞이는 PM, 기획, 마케팅, 운영 직군과 잘 맞습니다. 회의록을 쓰고, 기획안을 만들고, 레퍼런스를 모으는 일이 한 공간에서 이어지기 때문입니다. 정리 습관이 강하지 않아도 일하면서 생긴 문서가 자동으로 축적되는 구조도 장점입니다.

이 방식으로 뇌를 뺄 때 주의할 점

문서가 많아질수록 위험도 같이 커집니다. 구조 없이 페이지가 쌓이면 의미 없는 정보 더미가 되고, AI도 헛다리를 짚기 쉽습니다. 사서가 아무리 똑똑해도 책장이 엉망이면 찾을 수가 없으니까요. 입력 품질이 결과 품질을 좌우합니다.

팀 공간에서는 보안과 권한 이슈도 생깁니다. 개인 지식을 마음껏 쌓고 싶지만, 공유 범위가 걸리면 주저하게 됩니다. 세컨드 브레인을 팀 도구로 만들지, 개인 도구로 둘지부터 정해야 편합니다.

마지막은 도구 종속입니다. 플랫폼 안에 갇히는 느낌이 들 수 있습니다. 그래서 내보내기와 백업 전략을 미리 고민해 둬야 장기적으로 훨씬 편해집니다.

Notion의 대안: Coda, Evernote

Notion이 싫은 사람을 위한 대안: Coda, Evernote

Notion이 맞지 않는다면 Coda를 볼 수 있습니다. Coda는 문서라기보다 “작은 업무 앱”을 조립하는 감각이 필요할 때 강합니다. 테이블과 자동화 중심으로 문서+스프레드시트+자동화를 묶고, 그 위에 AI를 결합하는 느낌입니다. 쉽게 말해 태생은 자동화 앱인데 문서에 최적화되어 있다고 봐도 좋습니다.

Evernote는 세컨드 브레인의 원조에 가깝습니다. 사실 Notion보다 더 이전에 이 노트를 선택한 사람들이 많았죠. 최근에는 AI 검색과 정리 기능으로 부활을 시도하는 흐름이 있습니다. 특히 과거 노트 자산이 많은 사용자라면 “이미 쌓인 것”을 살리는 선택지가 됩니다.

Obsidian: 진짜 내 뇌가 잘 이해하는 구조로 설계한 지식

세컨드 브레인을 폴더로만 만들면 분류망에 우겨넣은 지식이 되기 쉽습니다. Obsidian 류의 방식은 반대입니다. 문서를 서랍에 넣는 게 아니라 노트를 실로 연결해 지도를 그립니다. 쉽게 말해 어거지로 폴더에 쌓는 방식이 아니라, 노트를 실로 연결해서 지도처럼 만드는 방식입니다.

이렇게 연결된 노트는 나만 알아보는 암호가 아니라 나도 알고 AI도 알고 모두가 잘 아는 지식의 그물망이 됩니다. 링크로 맥락이 붙어 있으면 검색도 쉬워집니다. 나중에 다시 봤을 때 “왜 이 메모를 썼지?”가 덜 생깁니다. 지식이 쌓일수록 연결이 길을 만들어 줍니다.

그래프 구조와 md 문서로 설계하는 세컨드 브레인, Obsidian

그 대표로 Obsidian이 언급되는 이유

Obsidian이 자주 거론되는 첫 이유는 마크다운 파일 기반이기 때문입니다. 메모가 앱 안에 갇히는 느낌이 아니라 내 컴퓨터나 내 드라이브에 파일로 남는다는 안정감이 있습니다. 서비스 정책이 바뀌어도, 최소한 원본은 내 손에 쥐고 있다는 감각이 생깁니다. 이 차이가 생각보다 큽니다.

둘째는 링크(백링크)와 그래프 관점입니다. Obsidian에서는 노트가 늘어날수록 지식이 문서 묶음에서 관계망으로 진화합니다. 예전엔 ‘프로젝트 A 폴더’에 넣고 끝났다면 이제는 ‘A가 B와 연결되고, B가 C로 이어지는’ 흐름이 보입니다. 한 문서를 찾는 게 아니라 맥락을 따라 이동하게 됩니다.

셋째는 AI와의 시너지입니다. AI는 물론 단일 맥락에서도 유용하지만 뇌와 같이 관계와 맥락이 풍부할수록 일을 더 잘합니다. 요약은 더 정확해지고 아이디어를 섞는 것도 자연스러워집니다. 무엇보다 “이 결론의 근거가 어디였지?”를 추적하기 쉬워집니다. 메모 앱에 AI가 붙을수록 이런 구조의 힘이 커집니다.

누구에게 유리할까?

그래서 이 방식은 생각의 재료를 오래 축적하는 사람에게 특히 유리합니다. 개발자, 리서처, 콘텐츠 생산자처럼 메모가 결과물의 재료가 되는 직군이 그렇습니다. 오늘의 메모가 내일의 글이 되고, 다음 달의 기획이 되는 사람들입니다. 노트가 늘수록 가치가 커집니다.

또 하나는 정리 자체를 작업으로 받아들일 수 있는 사람입니다. 처음부터 완벽히 하려 하면 지칩니다. 하지만 장기적으로 자산화하겠다는 마음이 있으면 연결은 복리처럼 쌓입니다. 당장 정답을 찾기보다 나중의 나를 돕는 방식입니다.

마지막은 도구 종속이 싫은 사람입니다. 내 데이터가 특정 서비스에 묶이는 게 불편하다면 파일 기반은 매력적입니다. 백업이나 버전관리(예: Git 등)까지 염두에 두는 사람이라면 더 그렇습니다. 내 지식의 주인은 나라는 감각이 선명해집니다.

이 방식으로 뇌를 뺄 때 주의할 점

첫 장벽은 의외로 단순합니다. 초기에 “뭘 어떻게 링크해야 하지?”에서 멈춥니다. 이때는 규칙을 크게 잡지 말고, 최소 규칙을 두는 게 좋습니다. 예를 들어 “일단 한 문장 요약 + 관련 링크 1개만”처럼요. 연결은 나중에 수정해도 됩니다.

둘째는 플러그인과 설정입니다. Obsidian은 확장이 많아서 꾸미다 지치는 경우가 흔합니다. 그래서 도입 원칙을 정해두면 좋습니다. 예를 들어 “기본 기능으로 2주만”처럼요. 세컨드 브레인은 도구가 아니라 계속 꺼내 쓰는 습관에서 완성됩니다.

Obsidian의 대안: Logseq, Tana

Obsidian이 싫은 사람을 위한 대안: Logseq, Tana

Obsidian이 맞지 않는 이유가 ‘글로 쓰는 방식’이 답답한 사람도 있습니다. 그럴 때는 Logseq이 편할 수 있습니다. Logseq은 아웃라이너(줄글보다 ‘블록’ 단위 사고)에 맞춘 도구입니다. 마크다운과 양방향 링크를 쓰는 등 철학은 비슷하지만 리듬이 다릅니다. 오픈소스라는 점도 선택 이유가 됩니다.

한편 처음부터 애초에 더 잘 짜여진 데이터처럼 적고 싶다면 Tana가 강합니다. 구조화와 필드 기반으로 메모를 쓰는 순간부터 정리된 형태를 만들 수 있습니다. 정리 강박이 있는 사용자에겐 오히려 생산성이 올라갑니다. 대신 자유롭게 흘려 쓰는 맛은 덜할 수 있습니다.

NotebookLM: 애초에 정리부터 AI에게 위임하기

정리를 잘하는 사람만 지식을 쌓는 시대는 끝나고 있습니다. 이제는 “대충 자료 넣을 테니, 너가 알아서 해”를 할 수 있는 도구가 나왔기 때문입니다. 세컨드 브레인을 만들 기에 가장 급진적인 방식 중 하나입니다. 즉, 지식을 ‘쓰는’ 게 아니라 더미를 AI에게 읽혀두는 쪽에 가깝습니다.

흐름은 단순합니다. 내가 가진 자료를 그냥 통째로 넣습니다. 링크든 PDF든 남이 쓴 문서든 그렇습니다. 이를 넣으면 AI가 요약하고, 질문에 답하고, 대화로 탐색까지 도와줍니다. 정리 노트를 만드는 시간을 통째로 건너뛰는 방식입니다. 기대하는 건 하나죠. 알아서 핵심을 뽑아 저장한 다음 내가 필요한 순간에 꺼내주길 바라는 겁니다.

정리부터 AI한테 맡기는 아예 세컨드 브레인, NotebookLM

가장 먼저 찾기 좋은 그 NotebookLM

NotebookLM은 이 흐름을 가장 직관적으로 보여주는 도구입니다. 소스(문서·자료)를 넣으면 먼저 요약해주고 그다음엔 내가 질문하면 근거를 바탕으로 답합니다. 여기서 중요한 포인트는 내가 넣은 자료 안에서 대화가 돈다는 점입니다. 즉, 웹에서 주워온 얘기가 아니라 내가 준 문서에서 답을 찾아주는 형태에 가깝습니다.

가치가 크게 터지는 순간도 뚜렷합니다. 자료량이 많기에 읽기와 정리가 병목이 될 때입니다. 예를 들어 리서치 문서, 수업 자료, 회의록, 인터뷰 녹취처럼요. 읽는 데만 하루가 가는 일을, 질문 몇 번으로 압축해버릴 수 있습니다.

또 하나는 접근성입니다. 구글 생태계와의 연동 덕분에 시작 장벽이 낮습니다. 업무나 개인 자료가 구글 쪽에 모여 있다면 더 편하게 붙일 수 있습니다. 그래서 “일단 써보자”의 첫 선택지로도 무난합니다.

누구에게 유리할까?

빨리 이해하고 써먹는 것이 중요한 사람에게 유리합니다. 예쁘게 정리한 노트를 쌓는 것보다 당장 답을 뽑아내는 게 목적이기 때문입니다. 폴더 구조를 설계하고 태그를 다는 시간보다 질문하고 판단하는 시간이 더 소중한 경우입니다. 세컨드 브레인을 아카이브가 아니라 질문 엔진으로 쓰는 쪽이죠.

그러니까 매일 새로운 자료를 흡수해야 하는 직무에도 잘 맞습니다. 전략, 리서치, 정책, 세일즈처럼요. 이런 일은 읽을 거리 자체가 끝없이 들어옵니다. 결국 승부는 얼마나 많이 읽었나가 아니라 얼마나 빨리 맥락을 잡았나에서 갈리니까요.

이 방식으로 뇌를 뺄 때 주의할 점

AI 요약은 편하지만, 잘못 요약되거나 중요한 게 누락되면 내 판단이 흔들립니다. 그래서 출처 추적이 필수 안전장치입니다. 요약 문장만 믿지 말고 그 말이 나온 원문 위치를 바로 확인하는 습관이 필요합니다. AI가 친절할수록 확인은 더 냉정해야 합니다.

또 하나는 기억의 문제입니다. 정리를 위임하면 내 머릿속에 남는 게 줄어들 수 있습니다. 그래서 최소한의 인간 개입을 권합니다. 예를 들어 내 언어로 3줄 결론 남기기 같은 규칙입니다. AI가 정리해준 걸 그대로 두지 말고 마지막 한 번은 내가 소화하는 단계가 있어야 합니다.

NotebookLM의 대안: Mem, Recall

NotebookLM이 싫은 사람을 위한 대안: Mem, Recall

NotebookLM이 무언가 지식의 축적처럼 느껴지지 않는다면 대안도 있습니다. Mem은 입력을 가볍게 하고 검색·회상 경험을 AI로 보강하는 방향을 가진 프로덕트입니다. 즉 꼼꼼히 정리하기보다 대충 넣고 나중에 잘 찾기에 초점이 있습니다.

Recall은 결이 조금 다릅니다. 읽은 자료를 자동으로 정리하고 연결해 복습하는 일에에 초점을 둡니다. 쉽게 말해, 한 번 읽고 끝내는 게 아니라 다시 내 머리에 넣는 과정까지 설계된 흐름입니다. 자료를 저장하기보다 학습에 가깝게 다루고 싶은 사람에게 맞습니다.

마치며

세 가지 방법을 정리해 봤습니다. Notion 계열의 “문서에 올라탄 AI”, Obsidian 계열의 “구조화 지식망”, NotebookLM 계열의 “AI 위임”까지 말이죠. 한 줄로 정리하면 AI 의존도의 스펙트럼입니다. 내가 주도권을 더 쥘지, AI에게 더 맡길지에 따라 선택지가 갈리는 겁니다.

그래서 장단점도 앱 자체의 우열이라기보다 사용자의 습관과 목표에서 갈라집니다. 세컨드 브레인을 만드는 핵심은 도구를 고르는 일이 아니라, 내가 어떤 방식으로 기억하고 꺼내 쓸지 정하는 일입니다. 결국 내가 편한 방식으로 오래 쓰는게 가장 중요한 영역이니까요.

물론 “애초에 이걸 왜 해야 하는지 모르겠다”고 느낄 수도 있습니다. 그런데요, 이제 다가올 에이전트 시대에는 내가 읽고 배운 것을 모두 내 지식으로 만드는 게 생존 기술에 가까울지 모릅니다. 메모 앱은 이제 기록장이 아니라 나를 대신해 찾아주고 설명해주는 작업대가 됐습니다. 세컨드 브레인이 거창하다면, 지금 내가 지식을 어떻게 정리하고 있는지라도 한 번 돌아보면 어떨까요?

]]>