요즘IT » 프로덕트 » 피드

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 얼마짜리 기능일까?

신규 기능 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에게 더 맡길지에 따라 선택지가 갈리는 겁니다.

그래서 장단점도 앱 자체의 우열이라기보다 사용자의 습관과 목표에서 갈라집니다. 세컨드 브레인을 만드는 핵심은 도구를 고르는 일이 아니라, 내가 어떤 방식으로 기억하고 꺼내 쓸지 정하는 일입니다. 결국 내가 편한 방식으로 오래 쓰는게 가장 중요한 영역이니까요.

물론 “애초에 이걸 왜 해야 하는지 모르겠다”고 느낄 수도 있습니다. 그런데요, 이제 다가올 에이전트 시대에는 내가 읽고 배운 것을 모두 내 지식으로 만드는 게 생존 기술에 가까울지 모릅니다. 메모 앱은 이제 기록장이 아니라 나를 대신해 찾아주고 설명해주는 작업대가 됐습니다. 세컨드 브레인이 거창하다면, 지금 내가 지식을 어떻게 정리하고 있는지라도 한 번 돌아보면 어떨까요?

]]>

렌트어휴먼(RentAHuman), AI한테 고용당하겠다는 50만 명이 모였다

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

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

써볼 것: Claude Code Remote Control - 모든 기기에서 로컬 세션 계속하기
참고할 것: 렌트어휴먼(RentAHuman), AI한테 고용당하겠다는 50만 명이 모였다
적용해볼 것: Claude Code 창시자가 전하는 AI 시대 빌더의 사고방식과 실전 팁

<출처: Anthropic>

1. 써볼 것: Claude Code Remote Control - 모든 기기에서 로컬 세션 계속하기

Claude Code Remote Control은 Anthropic이 2월 24일에 공개한 Claude Code의 새 기능입니다. 터미널에서 돌리고 있는 Claude Code 세션을 스마트폰이나 태블릿에서 그대로 이어받을 수 있는 건데요. 코드가 클라우드로 올라가지 않고 내 컴퓨터에서 계속 실행된다는 게 핵심입니다.

이 기능은 발표 직후 개발자들 사이에서 빠르게 퍼졌는데요. 그냥 폰에서 코드를 보는 게 아니라, 데스크톱에서 하던 작업을 진짜로 모바일에서 이어갈 수 있다는 점이 반응을 끌었습니다. VentureBeat도 2026년 가장 실용적인 코딩 기술 중 하나라는 개발자들의 평가를 소개했고요.

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

Claude Code를 쓰다 보면 한 가지 불편한 점이 있습니다. 작업을 시켜놓고 결과를 확인하려면 노트북 앞에 앉아 있어야 한다는 거예요. 커피를 사러 가거나, 회의에 들어가거나, 산책을 하고 싶어도 터미널을 떠날 수가 없죠.

이번 주 적용해볼 것에서 다룰 Boris Cherny(Claude Code 창시자)도 Lenny's Podcast에서 이 얘기를 했는데요. 본인이 코딩의 3분의 1을 iOS 앱에서 한다고요. 2026년에 폰으로 코딩하게 될 줄은 상상도 못했다고 합니다. Remote Control이 바로 이걸 가능하게 만드는 기능이에요.

물론 이전에도 WebSocket 브릿지를 직접 만들거나, VPN을 세팅해서 비슷한 환경을 만든 개발자들이 있었습니다. 하지만 이런 방법은 연결이 끊기기 쉽고, 세팅에 시간이 걸렸어요. Remote Control은 이걸 명령어 하나로 해결합니다. 포트 포워딩도 VPN도 필요 없어요.

어떻게 쓰나요?

사용 방법은 간단합니다.

터미널에서 claude remote-control (또는 줄여서 claude rc) 입력
화면에 세션 URL과 QR 코드가 표시됨
claude.ai/code 또는 Claude 모바일 앱에서 접속

이미 세션이 진행 중이라면 /rc 명령어를 쳐도 됩니다. 스페이스바를 누르면 QR 코드를 켜고 끌 수 있고요.

핵심은 세션이 항상 내 컴퓨터에서 돌아간다는 점입니다. 폰은 그냥 리모컨 역할을 하는 거예요. 파일 시스템, MCP 서버, 프로젝트 설정이 전부 그대로 유지됩니다. 터미널에서 보내든, 폰에서 보내든, 브라우저에서 보내든 대화는 실시간으로 동기화되고요.

노트북이 잠자기 모드에 들어가거나 네트워크가 끊겨도 세션은 백그라운드에서 살아 있습니다. 컴퓨터가 다시 켜지면 자동으로 재연결돼요. 여러 세션을 동시에 돌리고 있어도 괜찮습니다. 각 세션이 모바일 앱에 별도 항목으로 뜨거든요.

참고로 --sandbox 플래그를 붙이면 파일 시스템과 네트워크를 격리한 상태로 실행할 수도 있습니다. 민감한 프로젝트에서 유용하죠.

누구에게 좋을까요?

Claude Code에 작업을 시켜놓고 자리를 비우는 일이 잦은 개발자
에이전트 여러 개를 동시에 돌리면서 결과를 중간중간 확인하고 싶은 사람
출퇴근길이나 이동 중에 코딩 세션 상태를 체크하고 싶은 사람
회의 중에도 진행 상황을 놓치고 싶지 않은 사람

다만 몇 가지 제약이 있습니다. 세션당 원격 연결은 한 개만 가능하고, 터미널 프로세스를 완전히 닫으면 세션이 끝납니다. 그리고 현재는 Max 플랜(월 100~200달러) 전용이에요. Pro 사용자에게도 곧 확대될 예정이지만, Team이나 Enterprise 플랜은 아직 미지원입니다.

이미 claude.ai/code 웹 버전을 쓰고 있다면 헷갈릴 수 있는데요. 웹 버전은 Anthropic 클라우드에서 실행되는 별도 환경이에요. 로컬 설정 없이 바로 쓸 수 있는 대신, 내 컴퓨터에 있는 프로젝트 파일이나 도구와는 연결되지 않습니다. Remote Control은 반대로, 내 컴퓨터에서 돌아가는 기존 세션을 다른 기기에서 이어받는 개념이에요. 목적이 다릅니다.

<출처: RentAHuman>

2. 참고할 것: 렌트어휴먼(RentAHuman), AI한테 고용당하겠다는 50만 명이 모였다

렌트어휴먼(이하 RentAHuman)은 AI 에이전트가 사람을 검색하고, 골라서, 직접 일을 시키는 플랫폼입니다. 2월 초 출시 이후 50만 명 이상이 등록했고, Nature, Futurism, Gizmodo 등 주요 매체에서 앞다퉈 다뤘습니다.

AI가 디지털 세계에서는 거의 뭐든 할 수 있지만, 택배를 받거나 매장에 가서 물건을 확인하는 건 여전히 못 하잖아요. 그 빈자리를 사람으로 채우겠다는 겁니다. 슬로건이 AI needs your body인 이유예요.

기존 긱 이코노미와 무엇이 다른가요?

Upwork나 Fiverr 같은 플랫폼은 사람이 사람을 고용합니다. 의뢰인이 요구사항을 정리하고, 프리랜서를 찾고, 대화를 나누고, 결과물을 확인하죠.

RentAHuman은 이 과정에서 의뢰인이 사람이 아니라 AI입니다. Claude나 MoltBot 같은 AI 에이전트가 직접 사람을 검색하고, 작업을 맡기고, 완료 여부를 확인합니다. 이때 AI 에이전트는 MCP(AI가 외부 서비스와 소통하는 표준 규격)나 REST API(프로그램끼리 데이터를 주고받는 방식)를 통해 플랫폼에 접속해요. 중간에 사람 관리자가 끼어들지 않습니다.

사람 쪽에서는 프로필을 만들고 자기 기술, 위치, 시간당 요금을 설정하면 됩니다. AI 에이전트가 조건에 맞는 사람을 골라서 일을 시키는 구조예요.

어떻게 작동하나요?

작업은 두 가지 방식으로 이뤄집니다.

첫 번째는 직접 고용입니다. AI 에이전트가 사람 목록을 훑어보고 조건에 맞는 사람을 골라 바로 일을 맡기는 거예요.
두 번째는 Task Bounty라는 구인 게시판 형태입니다. AI가 작업을 올리면 사람들이 지원하고, AI가 그중 적합한 사람을 선택합니다.

보수는 작업이 끝나면 암호화폐로 즉시 지급됩니다. 구체적으로는 스테이블코인(달러 가치에 연동되는 암호화폐)을 씁니다. 작업 종류와 보수 범위는 꽤 넓은데요. 트위터 팔로우 같은 단순 작업은 1달러, 우체국 택배 픽업은 40달러, 특정 사진 촬영은 100달러 수준입니다. 그 외에도 매장 방문, 제품 테스트, 이벤트 참석 같은 작업이 올라오고 있어요.

실제로는 어떤 일이 벌어지고 있나요?

숫자만 보면 인상적입니다. 50만 명 이상이 등록했고, 인도, 동남아, 남미, 동유럽 등 다양한 지역에서 사람들이 몰렸어요. 흥미로운 건 Nature 보도입니다. 생물학자, 물리학자, 컴퓨터 과학자 같은 연구자들도 자기 전문 기술을 등록하기 시작했다고 해요. 워싱턴 스퀘어 파크에서 비둘기 수를 세거나, 새로 나온 이탈리안 레스토랑을 방문해보는 식의 작업이 과학자들에게도 배정되고 있다고요.

하지만 현실은 좀 다릅니다. Gadget Review 보도에 따르면, 샌프란시스코에서 올라온 40달러짜리 택배 픽업 작업에 30명이 지원했는데 이틀이 지나도 아무도 완료하지 못했습니다. 등록자 중 암호화폐 지갑을 연결한 사람은 13%에 불과하다는 분석도 있어요. 대부분은 돈을 벌려고 온 게 아니라 신기해서 가입한 거라는 얘기죠.

실제로 작업을 완료하고 돈을 받았다고 확인된 사례는 AI 스타트업 CEO인 Pierre Vannier가 API 키(프로그램 접속에 필요한 암호)를 확인해준 건 정도입니다. 이것도 자율적인 AI가 작업을 만든 건지, 사람이 마케팅 목적으로 올린 건지 불분명하다는 지적이 있고요.

보안 문제도 큽니다. 분쟁이 생겼을 때 중재 시스템이 없어요. AI가 결과물을 거부하면 사람 쪽에서 할 수 있는 게 없고, 반대로 사람이 일을 안 해도 마찬가지입니다. 유일한 안전장치는 평판 점수뿐이에요.

창립자 Alexander Liteplo는 소프트웨어 엔지니어 출신으로, 이 플랫폼을 주말 사이에 만들었다고 합니다. Gizmodo에 따르면 플랫폼에 문제가 생겼을 때 그의 대응은 지금 Claude가 고치고 있다였어요. 플랫폼 자체도 AI로 만들고, AI로 고치는 셈이죠. 누군가 이건 디스토피아라고 하자, 그는 그냥 맞다고 대답했습니다.

무엇을 얻어가야 하나요?

RentAHuman에 가입해서 돈을 벌라는 얘기는 아닙니다. 보안도 불안하고, 실제 수익 사례도 거의 없으니까요. 주목할 건 방향입니다.

지금까지 AI 논의는 대부분 AI가 사람의 일을 대신한다는 방향이었습니다. 하지만 RentAHuman은 정반대예요. AI가 계획하고, 사람이 실행합니다. AI가 사람을 고용하는 구조예요.

AI 에이전트가 외부 서비스와 연결되는 MCP 생태계가 커지면서 이게 기술적으로 가능해진 건데요. 아직은 실험 단계지만, AI가 디지털 세계에서 할 수 있는 일이 늘어날수록 물리적 세계와의 간극은 더 선명해집니다. 그 간극을 메우려는 시도는 계속 나올 거예요.

프로덕트 메이커 관점에서 생각해볼 포인트가 하나 있습니다. 로봇이 아직 비싸고 할 수 있는 것도 제한적인 지금, 시간당 5~15달러의 사람이 훨씬 유연한 실행 수단이라는 현실이에요. RentAHuman은 이걸 그냥 공식화한 거죠. 이 패턴은 다른 영역에서도 나타날 가능성이 높습니다. 다만 노동 착취의 자동화라는 비판도 진지하게 받아들여야 합니다. 하루 25달러로 AI 에이전트를 운영하면서 사람에게 잡무를 일방적으로 위임할 수 있다는 건, 효율의 문제이면서 동시에 윤리의 문제이기도 하니까요.

* 한 가지 짚고 넘어갈 게 있습니다. 50만 명이라는 등록자 수는 플랫폼 측 발표 기준입니다다. RentAHuman은 출시 이틀 만에 7만 3천 명의 계정이 등록했다고 했는데, 과학·기술 전문 매체 Futurism이 직접 확인해보니 열람 가능한 프로필은 83개뿐이었다고 합니다. 창업자 Liteplo도 중복 계정이나 불완전한 등록이 포함됐을 수 있다고 인정했고요. 또, 암호화폐 지갑을 실제로 연결한 사람은 전체의 13%에 불과했습니다. 등록은 50만이 넘는데 AI가 올린 작업은 1만 1천여 건, 그중 완료된 건 약 5,500건입니다.

MIT 경제학 교수 David Autor는 이걸 두고 스턴트, 그러니까 이목을 끄는 퍼포먼스에 가깝다고 평가했습니다. 결국 50만이라는 숫자의 대부분은 화제성에 끌려 가입만 하고, 실제로 일할 준비가 된 사람은 극소수라는 뜻입니다. 그래도 이 현상이 흥미로운 건 변하지 않습니다. 실제로 돌아가는 마켓플레이스냐는 별개로, AI가 사람을 고용한다는 개념 자체에 50만 명이 반응했다는 사실이 시사하는 바가 있으니까요.

<출처: Youtube 'Lenny's Podcast'>

3. 적용해볼 것: Claude Code 창시자가 전하는 AI 시대 빌더의 사고방식과 실전 팁

Boris Cherny는 Anthropic에서 Claude Code를 만들고 이끄는 엔지니어입니다. Meta에서 Facebook, Instagram, WhatsApp 등 전체 코드 품질을 담당했고, TypeScript 프로그래밍 책을 쓰기도 한 사람이에요. 최근 실리콘밸리 PM들이 가장 많이 듣는 팟캐스트 중 하나인 Lenny's Podcast에 출연해서, 자신이 작년 11월 이후 코드를 단 한 줄도 직접 쓰지 않고 있다고 밝혔습니다. 그러면서도 매일 PR(코드 변경 요청)을 10개에서 30개씩 올리고 있다고요.

Boris만 그런 게 아닙니다. Spotify는 최고 수준의 개발자들이 12월 이후 코드를 한 줄도 직접 작성하지 않았다고 공식 발표했고요. 반도체 분석 전문 기관 Semi Analysis 보고서에 따르면, 전 세계 GitHub 커밋(코드 저장 기록)의 4%가 이미 Claude Code로 작성되고 있습니다. 연말까지 전체의 5분의 1에 도달할 거라는 전망도 나왔어요.

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

AI 코딩 도구가 빠르게 좋아지고 있지만, 실제로 어떻게 써야 생산성이 오르는지는 여전히 막막한 사람이 많습니다. 도구는 매달 업데이트되는데, 작업 방식은 6개월 전에 머물러 있는 거죠.

Boris도 같은 문제를 겪었다고 합니다. 몇 달 전에 메모리 릭(프로그램의 메모리 사용량이 계속 늘어나다 결국 죽는 버그)을 잡아야 했는데요. 습관적으로 옛날 방식대로, 메모리 상태를 저장하고 특수 도구로 분석하고 있었대요. 그런데 팀에 새로 온 엔지니어는 그냥 Claude Code한테 메모리 릭이 있는 것 같은데 찾아줄래?라고 시켰습니다. Claude Code가 알아서 분석 도구를 만들고, 문제를 찾고, 수정 코드까지 올렸어요. Boris보다 빨리요. 오래 써온 사람일수록 예전 모델 기준으로 생각하기 쉽다는 겁니다. 더 이상 Sonnet 3.5가 아닌데, 습관은 그때 머물러 있는 거죠.

어떻게 해결했나요?

Boris가 인터뷰에서 공유한 내용을 크게 두 가지로 나눌 수 있습니다. 하나는 Claude Code를 잘 쓰는 실전 팁이고, 다른 하나는 AI 시대에 제품을 만드는 사람이 가져야 할 사고방식입니다.

실전 팁 1. 가장 좋은 모델을 쓰세요

Boris는 항상 최고 성능 모델(현재 기준 Opus 4.6)에 최대 노력 모드를 켜고 쓴다고 합니다. 비용을 아끼려고 저렴한 모델을 쓰면 오히려 손해라는 거예요. 덜 똑똑한 모델은 같은 작업에 토큰을 더 많이 쓰고, 수정도 더 필요하고, 사람이 더 많이 개입해야 하니까요. 직관에 반하지만 좋은 모델이 오히려 더 싸게 먹힐 때가 많다는 겁니다.

실전 팁 2. 플랜 모드로 시작하세요

Boris는 작업의 80%를 플랜 모드로 시작한다고 합니다. 플랜 모드는 AI한테 아직 코드를 쓰지 말고 계획만 세워라고 시키는 건데요니다. 터미널에서 Shift+Tab 두 번이면 들어가고, 데스크톱 앱이나 웹에서는 버튼이 있어요.

이렇게 계획을 먼저 세우고, 계획이 괜찮아 보이면 그때 실행시킵니다. Boris에 따르면 계획이 좋으면 Opus 4.6이 거의 매번 한 번에 정확한 결과를 만들어낸다고요. 계획 단계에서 방향을 잡아주는 게 결과물 품질에 훨씬 큰 영향을 미친다는 거예요.

실전 팁 3. 에이전트를 여러 개 동시에 돌리세요

Boris는 항상 5개 이상의 에이전트를 동시에 실행합니다. 인터뷰를 녹음하는 그 순간에도 5개가 돌아가고 있었다고 해요. 하나가 끝나면 결과를 확인하고, 다음 작업을 시키고, 또 다른 걸 확인하는 방식입니다.

아침에 일어나서 제일 먼저 하는 것도 폰에서 Claude 앱을 열어 에이전트를 시키는 거라고 합니다. 어제 짠 코드가 맞나 확인시키는 식이에요. 코드를 타이핑하는 게 아니라 원하는 걸 설명하는 것. 이게 지금 코딩이라고요.

사고방식 1. 사용자가 제품을 남용하는 방식을 관찰하세요

Boris가 공유한 제품 원칙 중 가장 인상적인 건 잠재 수요를 읽는 방법이었습니다. Claude Code는 개발자용 도구로 만들어졌는데, 데이터 사이언티스트가 터미널에서 SQL 분석을 하고, 누군가는 토마토 재배에 쓰고, 누군가는 MRI 분석에 쓰고 있었대요. 터미널이라는 장벽을 넘어서까지 이런 일을 하고 있다는 건, 이 도구가 코딩 너머로 갈 준비가 됐다는 신호였어요.

Boris는 이렇게 말합니다. 사람들이 제품을 설계 의도와 다르게 무리해서라도 사용하는 걸 보면, 그 용도에 맞는 전용 제품을 만들어야 한다는 뜻이라고요. 비개발자용 AI 에이전트인 Cowork가 바로 거기서 나왔습니다. Claude Code를 이용해서 단 10일 만에 만들었고요.

사고방식 2. 모델을 가두지 말고, 6개월 뒤를 위해 만드세요

많은 사람이 AI한테 1단계, 2단계, 3단계 식으로 엄격한 순서를 강제합니다. 하지만 Boris에 따르면 거의 항상 모델한테 도구와 목표만 주고 알아서 하게 두는 쪽이 더 나은 결과를 낸다고 합니다.

Claude Code 자체도 이 철학으로 만들어졌습니다. 제품 자체가 모델이에요. 도구가 아주 적고, 뼈대가 거의 없습니다. 모델이 어떤 도구를 어떤 순서로 쓸지 스스로 결정하게 두는 구조예요.

이건 AI 연구자 Rich Sutton이 말한 쓴 교훈(Bitter Lesson)과 같은 맥락입니다. 워크플로를 정교하게 짜서 성능을 10~20% 올려도, 다음 모델이 나오면 그 이득이 사라지는 경우가 많다는 거예요. 장기적으로는 범용적인 모델에 베팅하는 게 낫습니다.

같은 이유로 Boris는 지금 모델 수준에 맞춰서 타협하지 말라고 합니다. 처음 6개월은 제품이 어색하고 불편할 수 있어요. 하지만 6개월 뒤에 더 좋은 모델이 나왔을 때, 그 모델에 딱 맞는 제품이 이미 준비돼 있으면 폭발적으로 맞아떨어지기 시작합니다. Claude Code가 처음부터 맞힌 게 이거라고 Boris는 말해요. 초기에 Sonnet 3.5는 코딩 실력이 충분하지 않았지만, 언젠가 모델이 충분히 좋아질 거라는 데 베팅했고, 실제로 그 변곡점이 왔습니다.

사고방식 3. 제너럴리스트가 되세요

Boris가 인터뷰 후반에 한 가장 도발적인 말은, 소프트웨어 엔지니어라는 직함이 사라지기 시작할 거라는 겁니다. 대신 빌더(builder)라는 이름으로 대체되거나, 모든 사람이 PM이면서 코딩하는 형태가 될 수 있다고요.

실제로 Anthropic의 Claude Code 팀에서는 PM도 코딩하고, 디자이너도 코딩하고, 파이낸스 담당자도 코딩한다고 합니다. 역할 경계가 이미 50% 정도 겹치고 있다는 거예요.

Boris에 따르면 앞으로 가장 보상받는 사람은 AI를 잘 쓰는 것만으로는 안 되고, 여러 분야를 넘나들 수 있는 제너럴리스트라고 합니다. 제품과 인프라를 함께 보는 엔지니어, 디자인 감각이 있는 개발자, 사용자와 대화하면서 다음에 뭘 만들지 판단할 수 있는 사람. 코딩 능력보다 문제를 발견하고 정의하는 능력이 더 중요해지는 거죠.

생각해볼 질문

우리 제품을 의도와 다르게 사용하는 사람이 있다면, 거기에 어떤 잠재 수요가 숨어 있는 건 아닐까?
내 직무에서 AI가 대신할 수 있는 부분과 내가 직접 판단해야 하는 부분의 경계가 어디인지 정리해본 적 있는가?

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

Claude Code를 쓰고 있다면, 다음 작업을 플랜 모드로 시작해보기. 계획이 마음에 들면 그때 실행시키고, 수정 사항은 자동 승인하기.
저렴한 모델을 쓰고 있다면, 하루만 최고 성능 모델로 바꿔서 같은 작업을 시켜보기. 수정 횟수와 결과 품질이 어떻게 달라지는지 비교하기.
에이전트를 하나만 돌리고 있다면, 두 개를 동시에 열어서 서로 다른 작업을 시켜보기. 하나가 돌아가는 동안 다른 하나의 결과를 확인하는 루틴 만들기.
AI한테 강제하고 있는 워크플로 단계가 있다면 하나를 빼보기. 목표와 도구만 주고 결과를 관찰하기.

정리

이 내용을 기억해두면 좋습니다

코딩의 형태가 바뀌면, 코딩을 둘러싼 모든 것도 바뀝니다. Boris는 코드를 한 줄도 안 쓰면서 하루에 PR 30개를 올리고, Remote Control은 그 작업을 폰에서 이어가게 해주고, RentAHuman은 AI가 코딩 너머의 물리적 실행까지 사람에게 맡기기 시작했습니다. 코딩이 해결된 문제가 되면서, 다음 질문은 AI가 계획하고 사람이 실행하는 세계에서 내가 어디에 서 있을 것인가로 넘어가고 있어요.
도구가 좋아지면 도구를 쓰는 방식도 바뀌어야 합니다. 6개월 전 모델 기준으로 일하면 6개월 전 생산성에 머물러요. Boris가 새로 온 엔지니어한테 메모리 릭 디버깅에서 진 이유도 이거예요. 습관이 모델을 따라가지 못한 거죠. 새 모델이 나올 때마다 내가 직접 하던 것 중 이제 맡길 수 있는 게 뭔지 리셋하는 사람이 앞서갑니다.
제약과 자율 사이의 균형이 결과를 결정합니다. Boris 팀은 사람을 일부러 적게 배정해서 AI 활용을 끌어올렸고, 모델한테는 엄격한 순서 대신 목표만 줘서 더 나은 결과를 얻었습니다. 반대로 RentAHuman은 AI에게 사람 관리까지 맡기면서, 분쟁 중재도 보안도 없는 상태가 됐고요. 어디까지 맡기고 어디서부터 직접 판단할 것인가. 이 선을 의식적으로 긋는 게 중요합니다.

이렇게 적용해보세요

다음 작업을 플랜 모드로 시작해보기. AI한테 바로 코드를 쓰게 하지 말고, 계획을 먼저 세우게 한 뒤 그 계획을 검토하고 실행시키기.
새 모델이 나올 때마다 이전에 안 됐던 작업을 다시 시도하기. 지금 직접 하는 일 중 맡길 수 있게 된 게 있는지 점검하기.
제품을 만들고 있다면, 사용자가 의도와 다르게 쓰는 패턴을 일주일간 관찰하기. (거기에 다음 제품의 실마리가 있을 수 있다)

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

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

]]>

Supabase는 요즘 왜 그렇게 인기가 많을까?

요즘은 AI와 노코드 덕분에 화면이 정말 빨리 나옵니다. 버튼 몇 번만 누르면 MVP가 그럴듯하게 완성되기도 합니다. 그런데 출시 날짜는 뒤로 미뤄집니다. 대개는 “사용자 데이터를 어떻게 남기고 관리하지?”라는 질문에 답하지 못해서 그렇습니다.

이런 병목은 백엔드에서 발생합니다. 가장 먼저 로그인, 그러니까 인증(Auth)은 단순 회원가입만 붙이면 끝이 아닙니다. 비밀번호 재설정, 소셜 로그인, 세션 처리처럼 생각보다 갈래가 많습니다. 나아가 DB는 무엇을 고를지부터 고민입니다. 한 번 정하면 바꾸기 어렵다고 하니까요. 권한과 배포는 더 부담스럽습니다. “일단 돌아가게 해볼까?“ 와 “안전하게 운영하기” 사이의 거리가 멀다는 뜻입니다.

그래서 초기 팀은 딜레마에 자주 걸립니다. 직접 구축하면 통제권은 생기지만, 설계와 운영이 너무 무겁습니다. 반대로 SaaS에 기대면 당장은 빠르지만, 나중에 기능 제약이나 비용 구조에 발목이 잡힙니다. 결국 속도와 통제권 중 하나를 고르라는 질문을 받게 됩니다.

이 틈을 파고든 해법이 BaaS입니다. 백엔드의 기본 부품을 “서비스처럼” 가져다 쓰는 방식이죠. 그리고 요즘 이 흐름의 상징처럼 언급되는 이름이 Supabase입니다. 왜 BaaS가 대세인지, Supabase는 그중 왜 자주 선택되는지 살펴보겠습니다.

<출처: 요즘IT, Gemini로 제작>

백엔드가 ‘병목’이 되는 진짜 이유

프론트엔드와 MVP 제작은 AI와 노코드 덕분에 빨라졌습니다. 그런데 막상 출시를 앞두면, 팀의 속도를 잡아당기는 쪽은 다시 백엔드 병목이 됩니다. 이유는 단순히 “백엔드가 어렵다”가 아니라 초기 팀에게 백엔드는 선택지가 너무 많고, 한 번 결정하면 되돌리기 어렵기 때문입니다. 쉽게 말해, 기능을 만드는 일보다 기본 판을 깔아야 하는 일이 먼저라는 뜻입니다.

클라우드 인프라는 과한 선택지

백엔드 구축을 생각할 때, 클라우드 인프라는 가장 일반적인 선택지입니다. 하지만 조금이라도 제대로 해보려는 순간 해야 할 일이 한꺼번에 늘어납니다. VPC, 배포 파이프라인, 모니터링, 스케일링 같은 것들이죠. 하나하나 언젠가 필요한 건 맞지만 초반에는 제품의 핵심 가설을 검증하기도 전에 개발 속도를 꺾어버립니다. 마치 작은 가게를 열면서 대형 마트 수준의 보안과 물류부터 설계하는 느낌입니다.

특히, 이 서비스가 될지 안 될지를 빨리 확인해야 하는 팀이라면 더 치명적입니다. 검증이 먼저인데 인프라 준비가 출시 시간을 미루게 됩니다. 결국 문제는 기술이 아니라 순서입니다. 지금 필요한 것이 정교한 인프라보다는 빠른 실험과 반복이라면 말이죠.

단순 취향이 아닌 DB 선택

DB는 “나중에 바꾸면 되지”가 잘 안 통하는 영역입니다. SQL을 갈지 NoSQL을 갈지부터 시작해 나중에 마이그레이션을 어떻게 할지까지 연결됩니다. 인덱싱이나 쿼리 최적화를 뒤로 미루면 어느 순간 성능이 아니라 일정이 무너집니다. 그래서 제품에 붙이는 DB는 취향 문제가 아니라 제품의 길을 정하는 지도에 가깝습니다.

더 현실적인 문제는 MVP에서도 데이터 구조가 금방 빚이 된다는 점입니다. 처음엔 일단 저장만 되면 괜찮다고 시작할 수도 있습니다. 그러다 곧 검색과 정렬, 통계, 권한 조건이 붙습니다. 그러면 임시로 만든 구조가 발목을 잡아 기능 하나 추가할 때마다 데이터부터 뜯어고치게 됩니다. MVP를 빨리 만들려다 검증 수준에도 못 가는 DB 환경으로 팀의 속도를 늦추는 역설이 생깁니다.

권한/보안은 처음부터

인증은 구현 자체보다 실수 비용이 더 큽니다. 이메일/소셜 로그인, 세션 관리, 토큰, 비밀번호 재설정, MFA 같은 기능은 목록만 봐도 부담스럽습니다. 더 큰 문제는 일단 대충 해보기가 거의 불가능하다는 점입니다. 한 번 사고가 나면 작은 서비스일수록 신뢰가 더 크게 무너집니다.

권한 모델도 마찬가지입니다. 조직/팀/역할/리소스 단위로 누가 무엇을 할 수 있는지 정해야 하는데 이게 생각보다 MVP 단계에서 바로 필요해집니다. 첫 고객이 들어오는 순간, 관리자 화면과 멤버 초대, 데이터 접근 범위가 동시에 생기기 때문입니다.

게다가 고객이 하나라도 들어오면 보안은 기능이 아니라 기본값(default)의 문제가 됩니다. “기본 설정이 안전하냐”가 곧 제품의 품질 기준이 되고, 만약 여기서 문제가 생기면 아이디어 검증 자체는 뒤로 밀리기 때문이죠. 잘못된 기본값은 조용히 쌓이다가 어느 날 사고로 터집니다.

그럼 백엔드를 없애는 게 아니라 서비스처럼 쓰게 만들까?

그래서 서비스가 동작하려면 결국 백엔드에 대한 고민이 필요합니다. 만들자니 힘들고 냅두자니 고민인 백엔드 인프라. 그래서 요즘 팀들은 “백엔드를 서비스처럼 쓰자”로 방향을 틉니다. 그 답안 중 하나가 BaaS이고, 그 흐름 한가운데에 Supabase가 있습니다.

BaaS가 패키지로 제공하는 기본 구성요소

BaaS는 백엔드를 조립하지 않게 해주는 패키지입니다. 보통 아래 구성요소를 한 묶음으로 제공합니다. 즉, 하나씩 붙이고 연결하느라 시간을 쓰지 않게 해줍니다.

데이터베이스
인증(Auth)
스토리지
API 자동 생성
서버리스 함수

핵심은 단순히 “편하다”가 아닙니다. 원래 인프라를 조립하느라 쓰던 시간을 제품 로직과 UX로 옮기는 게 목적입니다. 사용자가 누를 버튼, 관리자가 볼 화면, 팀이 지켜야 할 규칙을 더 빨리 만드는 쪽으로요.

BaaS의 가치: 초기 비용을 0에 가깝게 만들기

태생이 그런 만큼 BaaS의 가치는 초기 비용을 0에 가깝게 만드는 데 있습니다. 여기서 비용은 돈만이 아니라 첫 배포까지 들어가는 시간과 판단의 무게까지 포함합니다. 특히 “이걸 지금 정해야 하나?” 같은 고민을 줄여주는 편입니다.

정리하면 핵심 가치는 이렇게 두 가지입니다. 첫째, 첫 배포까지의 시간이 짧아집니다. 인증, DB, API 같은 선택을 한 번에 건너뛰니 결정 피로가 줄어듭니다. 둘째, 표준화된 보안/권한 프리셋이 기본선을 만들어줍니다. 완벽하진 않아도 적어도 내놓을 법한 기본 구성에 최소한의 답이 됩니다.

통제권과 구조의 트레이드오프

물론 BaaS가 만능은 아닙니다. 플랫폼이 정한 방식에 맞춰 데이터 모델과 권한 모델을 배워야 하니까요. 당연히 기본 구조를 안다는 전제 하에 제공하다 보니 비개발자한테는 어렵습니다. 한편 내 시스템의 구조에 익숙한 개발자한테는 또 걸리적거리고요. 익숙해지면 빠르지만, 처음엔 그 방식 자체가 제약처럼 느껴질 수 있습니다. “내가 원하는 구조”보다 “플랫폼이 잘하는 구조”에 맞추게 되니까요.

그리고 서비스가 커질수록 미뤄둔 문제가 다시 튀어나옵니다. “지금은 편한데, 나중에도 이걸 계속 끌고 갈 건가?”라는 질문이요. 결국 BaaS는 속도를 주는 대신 일부 통제권을 교환하는 선택입니다. 그래도 Supabase 같은 도구는 그 교환을 “덜 아프게” 만드는 쪽에서 주목받습니다.

그 중에는 Supabase가 손이 가더라

BaaS를 찾는 사람이 늘수록 자연스럽게 “그럼 뭘 쓰지?”가 다음 질문이 됩니다. 그때 가장 자주 이름이 오르는 선택지 중 하나가 Supabase입니다. 빠르게 붙여 쓸 수 있으면서도 개발자 수준에서 내가 쓰고 있는 백엔드를 비교적 또렷하게 느낄 수 있기 때문입니다. 쉽게 말해, 백엔드 병목을 줄이되 통제권을 완전히 내려놓진 않게 해주는 쪽에 가깝습니다.

BaaS, Supabase

Supabase의 장점으로 꼽히는 세 가지 특징을 뽑아봤습니다.

1. AI·웹 개발 생태계와의 궁합

요즘은 AI 덕분에 프로토타입이 정말 빨리 나옵니다. 아직 기본 개념과 사용자가 느껴야 할 가치만 있는 수준의 제품에 필요한 건 거창한 인프라보다는 바로 붙일 수 있는 백엔드입니다.

특히 웹 개발, 그중에서도 풀스택 흐름은 요구가 뚜렷합니다. DB + Auth + Storage + API를 따로따로 고르는 게 아니라 한 덩어리로 빠르게 묶어 쓰고 싶어 합니다. 여러 제품을 조합하다 보면 설정과 권한 연결에서 시간이 새기 때문입니다. Supabase는 이 한 번에 갖추기 욕구와 잘 맞물립니다. (BaaS의 수요와 같은 맥락으로, 그런 특징을 가진 제품이라는 뜻입니다)

2. PostgreSQL 기반이라는 안정성

Supabase가 주는 안정감의 핵심 중 하나는 PostgreSQL 기반이라는 점입니다. 요즘 가장 인기 있는 DBMS의 하나인데요, 이를 구동하는 건 SQL입니다. SQL은 자료도 많고 이미 써본 사람도 많습니다. 팀에 경험자가 한 명만 있어도 대화가 빨라집니다. 쉽게 말해 SQL이 팀의 공용어가 되기 좋습니다.

또 그러니 제품 개발을 넘어 운영까지 이어지기 쉽습니다. 나중에 분석, 리포팅, 장애 대응을 할 때도 같은 언어로 데이터를 볼 수 있습니다. 지금 만든 테이블이 나중에 어떻게 쓰일지를 상상하기도 수월합니다. 이런 확장성은 초기 팀에게 꽤 큰 보험이 됩니다.

그리고 심리적인 포인트도 큽니다. 나중에 다른 곳으로 옮길 때도 데이터 레이어를 이해하기 쉽습니다. 개발자라면 데이터가 어떤 구조로 쌓이는지, 어떤 쿼리로 꺼내는지 감이 잡히니까요. 즉, 속도뿐 아니라 ‘설계의 흔적’을 남길 수 있습니다.

3. 벤더 종속성 부담을 줄이는 포지션

BaaS를 망설이게 하는 대표 이유는 벤더 종속성(락인)입니다. 편하긴 한데, 플랫폼을 바꾸는 순간 비용이 폭발할까 봐 불안합니다. Supabase는 완전 관리형에 가깝게 제공하면서도, 바닥에는 데이터·스키마·SQL 같은 표준이 깔려 있습니다. 이 구조가 내가 플랫폼에 끌려간다는 느낌을 줄입니다.

여기에 필요하면 자체 호스팅도 가능하다는 선택지가 더해집니다. 당장 하겠다는 뜻이 아니라, 대안 검토가 가능한 구조라는 점이 중요합니다. 선택지가 있다는 것만으로도 락인 불안이 크게 줄어듭니다. 초기 팀이 특히 민감해하는 지점이기도 합니다.

정리하면 메시지는 이겁니다. “지금은 빠르게, 나중엔 선택할 수 있게.” 서비스를 쓰되, 내 데이터의 주도권은 최대한 유지하고 싶다는 욕구가 있습니다. Supabase는 그 중간 지점을 비교적 현실적으로 채워 주면서, 상징적인 선택지가 됐습니다.

Supabase만이 언제나 옳은 답은 아니다

그렇다고 Supabase가 모두에게 늘 최선은 아닙니다. 이를테면 팀의 목표가 “이번 달 안에 MVP를 띄우는 것”인지, “1년 뒤 운영까지 버티는 구조”인지에 따라 답이 달라집니다. 결국 선택의 기준은 기능의 많고 적음이 아니라 지금 겪는 백엔드 병목이 어디서 생기는지입니다.

왼쪽부터 Firebase, Neon, Planetscale

Firebase: 모바일과 가장 쉬운 시작

Firebase는 전형적인 BaaS입니다. 특히 모바일 앱처럼 빨리 만들고, 바로 배포하고, 바로 측정해야 하는 상황에서 강합니다. 인증, 데이터 저장, 푸시 같은 기본 재료가 한 세트로 준비돼 있어 MVP 속도가 빠릅니다.

다만 데이터 모델이 NoSQL에 잘 맞는 제품일 때 좋습니다. 데이터가 문서처럼 뭉텅이로 움직이고 관계가 단순할수록 편합니다. 반대로 주문-결제-정산처럼 관계가 촘촘한 도메인이라면, 관계형 모델을 우회해서 설계해야 할 일이 늘어납니다. 그때부터는 “쉽게 시작했다”의 이점이 설계 부담으로 바뀔 수 있습니다.

또 한 가지 특징은 Google 생태계와의 밀착입니다. 처음엔 편합니다. 하지만 서비스가 커질수록 “여기서 나가려면 얼마나 힘들까?”라는 질문이 빨리 찾아올 수 있습니다. 즉, 속도를 얻는 대신 종속성을 더 빨리 체감할 수 있습니다.

Neon: BaaS보다는 서버리스 PostgreSQL

Neon은 엄밀히 말하면 BaaS라기보다 서버리스 PostgreSQL에 가깝습니다. 초점은 인증이나 스토리지가 아니라 데이터베이스를 쓰는 경험 자체를 더 빠르고 유연하게 만드는 데 있습니다. 예를 들어 빠른 프로비저닝이나 DB 브랜칭처럼, DB 개발 흐름을 바꾸는 기능에 강점이 있습니다. 백엔드 패키지보다는 DB 작업대를 잘 만들어둔 느낌입니다.

그래서 Neon은 Auth/Storage/API를 한 번에 맡기는 목적과는 결이 다릅니다. 핵심은 “Postgres를 잘 쓰게” 하는 플랫폼이라는 점입니다. 백엔드 전체를 위임하기보다, 데이터 레이어를 단단히 잡고 싶은 팀에 맞습니다. 즉, 백엔드 병목이 DB 운영과 개발 속도에서 생길 때 더 매력적입니다.

PlanetScale: 서버리스 MySQL + 스케일/운영 친화

PlanetScale은 서버리스 MySQL을 중심에 둔 DB-as-a-Service입니다. 특히 무중단 스키마 변경처럼 커진 서비스에서 치명적인 운영 문제를 줄이는 데 초점이 있습니다. 트래픽이 늘고 배포가 잦아질수록 “DB 변경이 곧 장애”가 되는데 그 부담을 낮춰주는 방향입니다. 쉽게 말해, 성장통을 덜 겪게 해주는 DB 운영 도구에 가깝습니다.

그래서 PlanetScale은 처음부터 빨리 만들기보다 성장 이후에도 안전하게 굴리기에 강합니다. 이미 제품-시장 적합성이 보이고 데이터 운영이 경쟁력이 되는 팀이라면 매력적인 선택지가 됩니다. 백엔드 병목이 운영 난이도로 옮겨가는 순간에 특히 그렇습니다. (지난해부터 PostgreSQL도 지원하기 시작했습니다)

대안들 vs. Supabase

Supabase는 Firebase처럼 “전체 백엔드 패키지” 접근을 취합니다. 동시에 Neon이나 PlanetScale처럼 DB 표준 기반의 감각, 즉 SQL과 Postgres 중심의 익숙함을 제공합니다. 그래서 빠르게 만들고 싶지만, 통제권도 놓치기 싫다는 팀에게 중간 지점이 됩니다.

그러니까 BaaS라는 새로운 요구는 잘 부합하면서도 PostgreSQL, Auth 등에서 안정감을 준다는 뜻입니다. 모든 팀에 정답은 아니지만, 이 균형점이 Supabase가 상징이 된 이유입니다.

선택은 단순하게 시작하면 됩니다. MVP 단계에서 속도, 기본 보안, 표준 데이터 모델을 동시에 원하면 Supabase를 먼저 검토하세요. 모바일 중심으로 초고속 MVP가 목표라면 Firebase가 더 편할 수 있습니다. DB 중심으로 설계를 가져가고 싶다면 Neon, PlanetScale 같은 DB 특화 옵션도 함께 비교해보면 좋습니다.

마치며

이제 AI와 노코드 덕분에 화면은 생각보다 빨리 만들 수 있습니다. 그런데 제품을 “진짜 서비스”로 굴리려는 순간, 백엔드 병목이 다시 튀어나옵니다. 인증과 권한은 결정이 필요하고, 보안은 실수하면 바로 사고가 나며, 운영은 시간이 갈수록 부담이 커집니다.

이때 BaaS가 뜰 수밖에 없습니다. 백엔드를 없애는 게 아니라, 백엔드를 서비스처럼 가져다 쓰게 해주기 때문입니다. 데이터베이스, 인증, 스토리지, API 같은 기본 세트를 한 번에 줍니다. 그래서 팀은 인프라보다 제품의 핵심 로직에 시간을 씁니다.

그중 Supabase가 사랑받는 이유는 균형점에 있습니다. Firebase처럼 빠르게 시작하되, PostgreSQL 기반이라 데이터 모델과 SQL 감각을 유지할 수 있습니다. 오픈소스 구조라 나중에 빠져나올 길이 보인다는 점도 큽니다. 완전 관리형과 완전 구축형 사이에서, 통제권과 속도를 같이 잡아줍니다.

서비스는 빨리 내고 싶은데 불안한가요? BaaS라는 키워드, 그리고 Supabase를 확인해 봅시다.

]]>

구글 14년차 엔지니어가 공유한, 직군 불문 교훈 14가지

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

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

써볼 것: 하루 만에 GitHub 스타 400개 받은 65줄짜리 텍스트 파일
참고할 것: GPT 전체를 200줄로 압축하면 남는 것 - Karpathy의 MicroGPT
적용해볼 것: 구글 14년차가 정리한 14가지 교훈

<출처: forrestchang 깃허브>

1. 써볼 것: 하루 만에 GitHub 스타 400개 받은 65줄짜리 텍스트 파일

오늘 써볼 것에서 소개할 CLAUDE.md는 AI 코딩 도구의 행동 규칙을 담은 65줄짜리 마크다운 파일입니다. Claude Code에서 바로 쓸 수 있고, Cursor나 VS Code 확장으로도 설치할 수 있습니다.

이 파일을 만든 건 forrestchang이라는 개발자인데요. OpenAI 공동창업자 Andrej Karpathy가 X에서 AI 코딩 도구의 문제점을 상세히 지적한 글에서 영감을 받아, 그 관찰을 4가지 원칙으로 정리한 겁니다. 공개 직후 GitHub에서 하루 만에 스타 400개를 달성했고, 현재는 6,500개를 돌파한 상황입니다. 또, Hacker News 메인에도 올라 활발한 토론이 벌어지기도 했죠. 흥미로운 건 이 파일이 고작 65줄이라는 겁니다. 수조 원을 들여 훈련시킨 거대 AI 모델에, 65줄짜리 텍스트 파일 하나를 얹었을 뿐인데 정말 코드 품질이 달라지는 걸까요? 아래에서 좀 더 살펴보겠습니다.

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

AI 코딩 도구를 써본 분들은 공감하실 텐데요. Claude Code든 Cursor든, AI한테 코드를 시키면 자주 겪는 문제가 있습니다.

첫째, AI가 멋대로 추측하고 달려갑니다. 모르면 물어봐야 하는데, 물어보지 않아요. 알아서 해석하고 알아서 만들어버립니다. 나중에 보면 전제 자체가 틀린 경우가 많죠.
둘째, 코드를 불필요하게 복잡하게 만듭니다. 100줄이면 될 걸 1,000줄로 짜요. 요청하지 않은 추상화를 덧붙이고, 사용하지 않을 설정 옵션을 미리 만들어둡니다.
셋째, 건드리지 말아야 할 코드까지 건드립니다. 함수 하나만 고쳐달라고 했는데, 옆에 있는 주석을 슬쩍 지우거나 관련 없는 코드를 리팩터링합니다.

이건 Karpathy가 직접 관찰하고 공유한 문제이기도 합니다. Karpathy는 2025년 12월부터 AI 에이전트로 코딩하는 비율을 80%까지 올렸는데요. 그 과정에서 발견한 공통적인 실수 패턴을 X에 상세히 공유했습니다. forrestchang은 이 내용을 4가지 원칙으로 정리해서 CLAUDE.md 파일로 만들었고, 그게 바로 이 가이드라인입니다.

어떻게 쓰나요?

설치 방법은 간단합니다. Claude Code를 쓴다면 터미널에 한 줄만 입력하면 됩니다.

npx skills add forrestchang/andrej-karpathy-skills

Cursor나 VS Code를 쓴다면, 프로젝트 루트 폴더에 CLAUDE.md 파일을 직접 추가해도 됩니다. 확장 마켓플레이스에서도 설치할 수 있고요.

파일 안에는 4가지 원칙이 들어 있습니다.

원칙 1. 코딩 전에 생각하기 → AI가 멋대로 추측하지 않고, 불확실한 부분이 있으면 사용자에게 물어보도록 만듭니다. 여러 가지 해석이 가능한 요청을 받았을 때, 하나를 골라 달려가는 게 아니라 선택지를 보여주고 확인을 구합니다.
원칙 2. 단순하게 짜기 → 요청받은 것만 구현하고, 그 이상은 하지 않도록 합니다. 테스트 기준은 간단해요. 시니어 엔지니어가 보고 "이거 너무 복잡한데?"라고 말할 것 같으면 다시 줄이는 겁니다.
원칙 3. 수술하듯 정밀하게 수정하기 → 요청과 직접 관련 있는 코드만 수정합니다. 변경한 모든 줄이 사용자의 요청으로 거슬러 올라갈 수 있어야 합니다.
원칙 4. 목표 기반으로 실행하기 → AI한테 "뭘 해라"라고 지시하는 대신, "성공 조건이 뭔지" 알려주고 스스로 반복하게 합니다. 테스트를 먼저 짜게 하고, 통과할 때까지 루프를 돌게 하는 방식이죠.

여기서 주의할 점이 하나 있습니다. 이 파일이 AI 코딩의 품질을 극적으로 바꿔주는 마법은 아닙니다. 이 파일을 발견하고 Cursor/VS Code 확장까지 직접 만든 네덜란드 개발자 Michiel Beijen도 블로그에서 리뷰했는데요. 실제로 써봤는데, 효과가 있는지 확신하진 못하겠다고요. LLM은 같은 프롬프트를 줘도 매번 다른 결과가 나오는 비결정적 특성이 있어서, 플라시보와 실제 개선을 구분하기가 어렵기 때문입니다. 그럼에도 수많은 개발자가 효과를 체감한다는 후기도 많습니다.

이 파일이 주목받는 이유는 따로 있어요. AI한테 매번 더 좋은 프롬프트를 쓰려고 애쓰는 것보다, 일하는 방식 자체를 규칙으로 정의해주는 게 더 근본적인 접근이라는 점입니다. 매번 잘 지시하려고 에너지를 쏟는 대신, 규칙을 한 번 세팅해두면 매 작업에 적용되니까요.

누구에게 좋을까요?

Claude Code, Cursor, VS Code에서 AI 코딩을 쓰는 사람
AI가 코드를 짜주면 리뷰하는 데 오히려 시간이 더 걸리는 사람
CLAUDE.md나 .cursorrules 같은 규칙 파일을 아직 안 써본 사람
팀에서 AI 코딩 가이드라인을 만들고 싶은데 어디서부터 시작할지 모르는 사람

반대로, 이미 프로젝트에 맞는 규칙 파일을 잘 운영하고 있다면 굳이 이 파일을 추가할 필요는 없어보입니다. 이 가이드라인은 범용적인 행동 규칙이라, 프로젝트별 맞춤 규칙과 함께 쓸 때 효과가 좋습니다.

<출처: Andrej Karpathy blog>

2. 참고할 것: GPT 전체를 200줄로 압축하면 남는 것 - Karpathy의 MicroGPT

MicroGPT는 GPT의 학습과 추론 전 과정을 단 하나의 파이썬 파일에 담은 프로젝트입니다. 외부 라이브러리 없이, 순수 파이썬 200줄만으로요. OpenAI 공동창업자이자 전 Tesla AI 디렉터인 Andrej Karpathy가 2월 12일에 공개했습니다.

반응은 즉각적이었습니다. GitHub Gist에 공개된 지 일주일 만에 스타 5,000개 가까이 받았고, 1,000개가 넘는 포크가 생겼습니다. C#, JavaScript, Rust, Common Lisp 등 다른 프로그래밍 언어로 옮기는 작업도 활발히 이어지고 있고요.

Karpathy 본인은 이걸 예술 작품이라고 불렀습니다. 10년간 LLM의 본질을 극한까지 단순화하려는 집착의 결과물이고, 이보다 더 줄일 수는 없다고요.

기존 LLM 교육 자료와 무엇이 다른가요?

GPT가 어떻게 작동하는지 이해하려면 보통 두 가지 벽이 있습니다. 첫째, 수학이 어렵습니다. 둘째, 코드가 복잡합니다. PyTorch 같은 프레임워크가 수만 줄의 코드로 핵심 원리를 감춰버리니까요.

MicroGPT는 이 두 가지 벽을 한꺼번에 없애줍니다. import하는 라이브러리가 os, math, random, argparse 딱 네 개입니다. PyTorch도 없고, NumPy도 없고, TensorFlow도 없습니다. 그런데 이 안에 토크나이저(텍스트를 숫자로 바꾸는 장치), 자동 미분 엔진(신경망이 학습하는 핵심 메커니즘), 트랜스포머 아키텍처, 옵티마이저(학습 속도를 조절하는 장치), 학습 루프, 추론 루프가 전부 들어 있습니다.

어떻게 작동하나요?

MicroGPT는 3만 2천 개의 영어 이름 데이터를 학습해서, 실제로는 존재하지 않지만 그럴듯하게 들리는 새로운 이름을 만들어냅니다. 학습이 끝나면 kamon, vialan, areli 같은 이름이 나오는데요. 이름 생성 자체는 소박해 보이지만, 이게 작동하는 원리는 ChatGPT와 정확히 같습니다.

우리가 ChatGPT에 질문을 하면, 모델 입장에서 그건 하나의 문서 시작점이에요. 모델은 그 문서를 통계적으로 가장 자연스럽게 이어나갈 뿐입니다. MicroGPT도 같은 원리로 이름이라는 문서를 완성하는 거예요.

차이는 규모에 있습니다. MicroGPT의 파라미터(모델이 학습하는 숫자들)는 4,192개입니다. GPT-2는 15억 개, 최신 LLM은 수천억 개를 가지고 있죠. 하지만 다음 토큰을 예측하고, 어텐션으로 맥락을 파악하고, 역전파로 학습하는 핵심 알고리즘은 동일합니다.

Karpathy의 표현이 정확합니다. 대규모 모델을 가능하게 하는 건 방대한 엔지니어링이지만, 알고리즘의 본질은 이 200줄 안에 모두 담겨 있다고요.

왜 이게 의미 있나요?

이 프로젝트가 단순한 교육용 코드와 다른 점이 세 가지 있습니다.

첫째, 알고리즘과 엔지니어링을 깔끔하게 분리해서 보여줬습니다. 우리가 매일 쓰는 ChatGPT는 거대해 보이지만, 그 거대함의 정체는 원리가 아니라 규모입니다. 더 많은 데이터를 더 빠르게 처리하기 위한 엔지니어링이 99%이고, 핵심 알고리즘은 200줄에 다 들어갑니다. 이걸 눈으로 확인할 수 있다는 게 중요해요.
둘째, 보통 프레임워크가 감춰주는 과정을 직접 구현했습니다. 신경망이 학습하려면, 각 숫자가 결과에 얼마나 영향을 미치는지 자동으로 계산하는 과정이 필요한데요. 보통은 PyTorch가 대신 해줘서 눈에 안 보입니다. MicroGPT는 이걸 40줄 남짓의 코드로 밑바닥부터 만들었습니다.
셋째, 10년간 계속 줄여온 과정의 마지막 단계입니다. Karpathy는 micrograd(자동 미분), makemore(문자 생성), nanoGPT(GPT-2 훈련), nanochat(100달러로 ChatGPT 만들기)를 차례로 만들어왔습니다. MicroGPT는 이 모든 걸 하나의 파일로 압축한 결정체예요. 추가한 게 아니라 계속 뺀 겁니다.

무엇을 얻어가야 하나요?

프로덕트 메이커가 MicroGPT에서 가져갈 건 코드가 아닌, 복잡한 것에서 본질만 남기는 사고방식입니다.

기능을 추가하는 건 누구나 할 수 있습니다. 진짜 어려운 건 빼는 거죠. 이는 Karpathy가 10년에 걸쳐 한 일이기도 합니다. 매번 프로젝트를 만들 때마다 "이건 꼭 있어야 하나?"를 물어서 한 겹씩 벗겨낸 겁니다.

프로덕트를 만들 때도 같은 질문을 해볼 수 있습니다. 지금 내가 만들고 있는 것에서, 핵심이 아닌 것은 무엇인가? 빼도 작동하는 것은 무엇인가?

GPU 없이 일반 노트북에서 몇 분이면 돌아가니까요. 코드를 이해할 필요 없이 실행만 해봐도, 200줄짜리 파일 하나로 AI가 이름을 만들어내는 걸 직접 볼 수 있습니다. 궁금하신 분은 Google Colab notebook에서 실행해 볼 수도 있습니다.

<출처: Addy Osmani>

3. 적용해볼 것: 구글 14년차가 정리한 14가지 교훈

Addy Osmani는 구글 Chrome 개발자 경험 팀을 이끌었고, 현재는 Google Cloud AI 디렉터로 일하고 있습니다. Chrome DevTools, Lighthouse 같은 도구를 만든 사람이에요. 4천만 명 이상의 개발자가 그가 만든 도구를 쓰고 있죠.

2월 12일, Osmani가 자신의 뉴스레터에서 구글 14년 경험에서 뽑은 추가 교훈 14가지를 공개했습니다. 이전에 쓴 21가지 교훈이 큰 반응을 받았는데, 사람들이 특히 관심을 보인 건 기술 조언이 아니라 팀과 의사결정에 대한 이야기였대요. 그래서 이번엔 아예 그 주제에 집중했습니다.

흥미로운 건, 14가지 교훈 중 상당수가 코딩과 관련 없다는 겁니다. 의사결정, 실행력, 시스템 설계에 대한 이야기가 대부분이고, 이건 프로덕트를 만드는 사람이라면 직군을 가리지 않고 적용할 수 있는 내용입니다.

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

프로덕트를 만드는 사람이 가장 많이 하는 말이 뭘까요. 아마 "해야 하는데"일 겁니다. 해야 하는데 시간이 없고, 해야 하는데 결정이 안 나고, 해야 하는데 뭘 먼저 해야 할지 모르겠고. Osmani가 14년간 관찰한 것도 결국 이 문제입니다. 똑똑한 사람들이 모여도 일이 안 되는 이유는 대부분 능력 부족이 아니라, 결정이 느리거나 구조가 없어서라는 거예요.

14가지 중 프로덕트 메이커에게 가장 와닿을 6가지를 골라서 전달드리겠습니다.

어떻게 해결했나요? (Addy Osmani가 공유한 교훈 중 선별)

1. 최고의 엔지니어는 올바른 문제를 고릅니다

모든 "예"는 다른 무언가에 대한 암묵적인 "아니오"입니다. Osmani는 뛰어난 엔지니어들이 모든 버그, 모든 기능 요청, 모든 부탁에 "예"라고 말하다 번아웃되는 걸 수없이 봤다고 합니다. 달력이 다른 사람의 우선순위로 채워지면, 자기 로드맵은 미완성 프로젝트의 무덤이 됩니다.

큰 영향을 만드는 사람들은 더 빠르거나 더 똑똑해서가 아니에요. 뭘 할지를 더 냉정하게 고르는 겁니다. 잘못된 일을 하는 것의 기회비용은, 잘못된 일을 하고 있다는 것 자체입니다.

2. "해야지"는 계획이 아닙니다. "화요일에 내가 할 것"이 계획입니다

팀은 의도에 빠져 허우적거립니다. 온보딩 플로를 개선해야지, 지연 시간을 줄여야지, API 문서를 정리해야지. 몇 달 후에 같은 항목이 그대로 남아 있죠.

Osmani의 해법은 간단합니다. 의도를 가장 작은 다음 행동으로 바꾸고, 거기에 이름과 날짜를 붙이는 겁니다. "온보딩을 개선해야 한다"가 아니라 "화요일에 Sarah가 사용자 세션 3회를 돌리고 핵심 불편 사항을 정리한다"로 바꾸는 거예요. 모호한 의도는 불안을 만들고, 구체적인 약속은 추진력을 만듭니다.

3. 느린 코드는 증상입니다. 느린 의사결정은 항상 문제입니다

프로젝트가 느려지면 보통 속도를 탓합니다. 사람이 부족하다, 코드가 지저분하다, 열심히 안 한다. 하지만 Osmani의 경험에서 느린 코드는 증상이고, 느린 의사결정이 병이었습니다.

결정이 몇 주, 몇 달씩 걸리면 이유를 파봐야 합니다. 맥락이 공유되지 않아서 트레이드오프를 판단할 수 없는 건지, 책임자가 불분명해서 서로 기다리고 있는 건지, 틀리는 게 두려워서 결정을 미루는 건지.

Osmani가 본 가장 빠른 팀은 최고의 프로그래머가 모인 팀이 아니었습니다. 결정이 몇 주가 아니라 몇 시간 안에 이루어지는 팀이었어요. 권한이 명확하고, 맥락이 공유되고, 틀려도 커리어에 타격이 없는 환경이었기 때문입니다.

4. 영웅 문화를 피하세요. 영웅이 필요 없는 시스템을 만드세요

한 사람이 위기를 구하는 게 반복되는 패턴이라면, 그건 자랑이 아니라 실패 신호입니다. Osmani는 팀들이 영웅을 축하하면서 정작 영웅이 필요해진 근본 원인은 무시하는 걸 봐왔다고 합니다. 그 사람이 떠나면 아무도 시스템을 모릅니다. 영웅에 대한 축하는 구조적 문제를 가려버리는 거예요.

정상적인 경로를 기본값으로 만들어야 합니다. 문서를 쓰고, 지식을 분산하고, 평범한 화요일을 기준으로 시스템을 설계하는 거죠. 위기 상황이 아니라요.

5. AI는 초안을 싸게 만듭니다. 취향이 비싸집니다

이제 누구나 코드를 만들 수 있습니다. 코드, 콘텐츠, 디자인을 만드는 비용이 급격히 낮아지고 있으니까요. AI한테 시키면 한 개 만들 시간에 열 개를 뽑아줍니다.

그러면 차이를 만드는 건 뭘까요. 고르는 능력입니다. 무엇을 만들지, 무엇을 지울지, 무엇을 단순하게 만들지, 무엇을 출시하지 않을지. Osmani는 이걸 취향(taste)이라고 부릅니다. 선택지를 구분하고 올바른 것을 고르는 능력이 희소 자원이 된다는 겁니다. 생산은 싸지고, 편집은 비싸지고, 선택이 전부가 됩니다.

6. 신뢰는 팀의 레이턴시 최적화입니다

신뢰가 있으면 일이 빨라집니다. 이 사람이라면 잘 판단했을 거라는 전제가 있으니까요. 확인 회의를 세 번 잡을 필요 없이, 한 번이면 됩니다. 반대로 신뢰가 없으면 같은 결정을 내리는 데 몇 배의 시간이 걸립니다. Osmani는 기술력은 보통인데 모두의 신뢰를 받아서 큰 일을 해내는 엔지니어를 봤다고 합니다. 반대로 기술력은 뛰어난데 아무도 같이 일하려 하지 않아서 결국 아무것도 못 한 엔지니어도 봤고요.

약속을 지키고, 실수를 솔직하게 인정하고, 다른 사람의 일을 쉽게 만들어줄 때마다 신뢰가 쌓입니다. 코드가 아무리 좋아도, 같이 출시해줄 사람이 없으면 의미가 없으니까요.

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

지금 하고 있는 일 중에서 "내가 안 하면 어떻게 되지?"를 물어보기. 큰 문제가 없다면, 그건 지금 내가 할 일이 아닙니다.
"해야지" 목록에서 가장 중요한 항목 하나를 골라서 "언제, 누가, 무엇을" 형식으로 바꿔보기. 이번 주 안에 할 수 있는 크기로 쪼개기.
반복적으로 내가 나서서 해결해야 하는 일이 있다면, 그 일을 시스템으로 만들 수 없는지 생각해보기. 영웅이 필요 없는 구조가 좋은 구조입니다.
AI로 만든 결과물을 볼 때, 무엇을 남기고 무엇을 뺄지 의식적으로 판단해보기. 생산이 아니라 선택에 시간을 더 쓰기.

정리

이 내용을 기억해두면 좋습니다

AI 코딩의 차이는 모델 성능에서 나오지 않습니다. 구조에서 나옵니다. 65줄짜리 규칙 파일이 수천 개의 스타를 받은 건, AI한테 매번 잘 지시하는 것보다 일하는 방식을 한 번 정의해주는 게 더 효과적이기 때문입니다. 규칙을 만드는 사람과 만들지 않는 사람의 차이가 점점 벌어질 겁니다.
복잡한 걸 더 복잡하게 만드는 건 누구나 합니다. 본질만 남기고 나머지를 제거하는 데 10년이 걸렸다는 게 MicroGPT의 진짜 이야기입니다. Karpathy는 기능을 추가한 게 아니라 매번 한 겹씩 벗겨냈고, 그 끝에 200줄이 남았습니다. 프로덕트도 마찬가지예요. 추가하는 건 쉽고, 빼는 게 어렵습니다.
AI가 초안을 싸게 만들수록, 무엇을 남기고 무엇을 뺄지 판단하는 능력이 비싸집니다. 코드를 짜는 건 AI가 하고, 규칙을 정하는 건 사람이 합니다. 열 개의 선택지를 만드는 건 AI가 하고, 하나를 고르는 건 사람이 합니다. 기술이 아니라 판단이 희소 자원이 되는 시대입니다.

이렇게 적용해보세요

AI 코딩 도구를 쓴다면, 프로젝트 폴더에 규칙 파일 하나 만들어보기. 거창할 필요 없이, AI가 자주 실수하는 패턴 3가지만 적어도 충분합니다.
지금 만들고 있는 프로덕트에서 빼도 되는 기능 하나 찾아보기. 추가하기 전에 "이거 없어도 핵심이 작동하나?" 물어보기.
"해야지" 목록을 "이번 주 화요일에 내가 할 것" 형식으로 바꿔보기. 구체적인 날짜와 이름이 붙어야 의도가 실행이 됩니다.

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

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

]]>

우리 팀이 JIRA 없애고 마크다운 파일 하나로 전환한 이유

안녕하세요! 해외 IT 소식을 전하는 트파원입니다.

본문은 The Concurrent Mind의 글 <Stop Using JIRA: How We Scaled to 50 Engineers Using Only a Markdown File>을 번역한 글입니다. 필자는 프로그래머이자 기술 콘텐츠 크리에이터로, 코드와 창의성, 그 사이에 숨겨진 교훈에 대해 글을 공유하고 있습니다. 이번 글은 복잡한 프로젝트 관리 도구에 지친 한 엔지니어링 리더(필자)가 마크다운 파일 하나로 팀의 업무 방식을 근본적으로 바꾸고, 배포 빈도를 3배로 끌어올린 실험의 기록입니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 각주(*표시)는 '번역자주'입니다.

미리 요점만 콕 집어보면?

JIRA는 나쁜 제품이 아니지만, 대부분의 팀에게는 실제로 존재하지 않는 문제를 위해 설계된 도구입니다.
마크다운 파일 하나(WORK.md)로 프로젝트를 관리한 결과, 배포 빈도는 3배 증가하고 티켓 관리에 쓰던 주당 6시간이 45분으로 줄었습니다.
최고의 프로젝트 관리 시스템은 '사라지는' 시스템, 즉 사용하는 데 드는 시간이 논의하는 데 드는 시간보다 적은 시스템입니다.

<출처: 원작자>

모든 것의 시작:JIRA이슈 4,200개를 삭제하게 만든 티켓

제가 JIRA 이슈 4,200개를 일괄 삭제하게 만든 티켓의 이름은 PLAT-4892였습니다. 그 티켓을 찾는 데 11분이 걸렸습니다. 보드 3개를 뒤지고, 에픽 2개를 파헤쳤는데요. ‘리뷰 중(In Review)’ 상태의 태스크들이 무덤처럼 쌓여 있었고, 그것들을 기억하는 엔지니어는 아무도 없었습니다. 겨우 찾아낸 티켓의 설명란에는 “그거 고치기”라고만 적혀 있었고, 담당자는 8개월 전에 퇴사한 사람이었습니다.

그날 오후, 무언가가 제 안에서 끊어졌습니다. 그다음 우리 레포지토리에 들어가 WORK.md라는 파일을 하나 만들었습니다. 그리고 제 커리어를 끝낼 수도 있는 슬랙 메시지를 하나 보냈습니다.

“우리는 JIRA를 그만 씁니다. 다음 주 월요일부터, 이 마크다운 파일이 우리의 전체 프로젝트 관리 시스템입니다.”

CTO는 4초 만에 답장을 보냈습니다. “내 사무실로. 지금 당장.”

모든 걸 끝낼 뻔한 미팅

솔직히 말하자면, 저는 손에 땀을 쥐고 그 의자에 앉았고, 머릿속으로는 사직서를 반쯤 써놓은 상태였습니다.

“엔지니어 12명을 텍스트 파일 하나로 관리하겠다는 거야?” 그가 말했습니다.

“우리는 일을 관리하느라 너무 바빠서, 정작 일 자체를 어떻게 하는지 잊어버렸습니다.” 제가 대답했습니다.

그는 한 시간처럼 느껴지는 시간 동안 저를 쳐다보았습니다. 그리고 예상치 못한 말을 했는데요.

“30일을 줄게. 배포 빈도가 단 한 번이라도 떨어지면, 자네는 끝이야.”

그 후 한 달 동안 저는 제대로 잠들지 못했습니다.

내 직업을 구한 시스템

첫날 우리의 WORK.md는 이렇게 생겼습니다.

# WORK.md - Week of March 8

## Shipping This Week
- [ ] Auth: rate limiting on login (maria)
- [ ] Search: fuzzy matching (dev)
- [ ] API: deprecate v1 endpoints (james)

## Blocked
- Payment refactor waiting on Stripe keys (sarah)
  ^ asked finance Tuesday, following up

## Next Up
- Mobile push notifications
- Dashboard redesign

## Shipped
- March: 0 features (we just started)

전체 시스템이 이게 전부였습니다. 워크플로우도 없고, 커스텀 필드도 없고, 오후 내내 잡아먹는 *그루밍 세션도 없었습니다. 그저 태스크, 담당자, 블로커가 모두에게 보이는 것, 그게 전부였습니다.

*백로그 그루밍(Backlog Grooming): 백로그 항목을 검토하고 정리하는 정기 회의

이 파일은 우리 *모노레포에 들어 있었습니다. 버전 관리는 Git이 처리했고, 모든 변경은 풀 리퀘스트를 거쳤습니다. 무언가를 끝내면 체크박스에 표시했고, 막히면 맥락과 함께 적어뒀습니다.

*모노레포(Monorepo): 여러 프로젝트의 코드를 하나의 저장소에서 관리하는 방식

다시는 돌아가지 않겠다고 확신한 순간

그렇게 19일 차, 우리의 배포 빈도가 2배로 뛰었습니다. 더 열심히 일해서가 아니었는데요. ‘일에 대한 일’을 그만뒀기 때문입니다. *스탠드업은 45분짜리 상태 보고 쇼에서 8분짜리 실제 커뮤니케이션으로 바뀌었습니다. 엔지니어들은 더 이상 “그 티켓 어디 있어?”라고 묻지 않게 되었습니다. 답은 항상 같은 파일, 같은 장소에 있었으니까요.

*스탠드업(Standup): 매일 아침 짧게 진행하는 팀 미팅

한 시니어 개발자가 있었습니다. 3년 동안 모든 프로세스 변경에 불만을 제기하던 사람이었습니다. 그가 제 자리로 걸어와서 이렇게 말했는데요. “이걸 인정하기 싫지만, 태어나서 처음으로 다른 사람들이 뭘 하고 있는지 실제로 알게 됐어요.”

바로 그때 알았습니다. 우리가 진짜 무언가를 찾았다는 것을 말이죠.

3년 후, 엔지니어 50명

그렇게 우리는 다시는 JIRA로 돌아가지 않았습니다. 배포 빈도는 3배가 되었습니다. 그리고 티켓 관리에 쓰는 주당 시간은 6시간에서 45분으로 줄었습니다. “이 티켓 어디 있어?”라는 슬랙 메시지는 완전히 사라졌습니다. 하지만 숫자로는 실제로 무엇이 바뀌었는지 담아낼 수 없었는데요.

엔지니어들은 상태를 업데이트하는 대신 서로 대화하기 시작했습니다. 소프트웨어는 프로세스가 아니라, 사람이 만드는 것이라는 사실을 다시 기억하게 되었습니다.

아무도 듣고 싶어 하지 않는 불편한 진실

JIRA는 나쁜 제품이 아닙니다. 제가 말하고 싶은 건 JIRA를 쓰지 말자는 말을 하려는 것이 아닙니다. 다만 대부분의 팀이 실제로 가지고 있지 않은 문제를 위해 설계된 제품이라는 겁니다. 우리는 “진짜 회사는 JIRA를 쓴다”는 이유로 이 제품을 도입했습니다. 복잡함이 성숙함처럼 느껴져서 설정을 이리저리 만졌습니다. 그 고통이 프로페셔널함의 대가라고 생각했기에 참고 견뎠죠.

그러나 고통의 원인은 비용이 아니라, 낭비였습니다. 최고의 프로젝트 관리 시스템은 ‘사라지는 시스템’입니다. 사용하는 데 걸리는 시간이, 그것에 대해 논의하는 데 걸리는 시간보다 적은 시스템 말입니다.

우리에게 그 답은 마크다운 47줄이었습니다. 그렇게 3년째입니다. 현재 엔지니어는 50명이지만, 나는 그날 오후, “마침내 더는 못 참겠다고 결심”한 이후로 단 한 번도 티켓 관리 시스템을 열어본 적이 없습니다.

여러분의 생각은 어떠신가요?

<원문>

Stop Using JIRA: How We Scaled to 50 Engineers Using Only a Markdown File

]]>

잔디·슬랙·팀즈·네이버웍스·플로우, AI 기능 어디까지 왔나

메신저형 협업툴이 등장한 지 어느덧 10년을 넘어섰습니다. 슬랙이 2013년, 잔디가 2014년에 출시된 이후, 이 도구들은 이메일 중심이던 업무 소통 방식을 완전히 바꿔놓았습니다. 그런데 지금, 이 툴들이 다시 한번 근본적인 변화를 맞고 있습니다. AI때문입니다.

사실 메신저형 협업툴에는 태생적인 한계가 있었습니다. 대화는 빠르게 흘러가지만, 그 안에서 지식과 실행은 잘 남지 않는다는 것. 중요한 합의는 스크롤 아래로 묻히고, 할 일은 누군가의 기억력에 의존하게 됩니다. "말은 잘 모으는데, 일로 바꾸는 건 약한 도구"였던 셈입니다. 10년간 쌓인 이 숙제를 각 툴은 이제 AI로 풀려 하고 있습니다. 그래서 협업툴의 경쟁 축이 "대화를 얼마나 잘 연결하느냐"에서 "대화를 얼마나 업무 비서처럼 정리해주느냐"로 변하고 있죠. 이 글에서는 국내외 대표적인 메신저형 협업툴 5가지가 AI로 어디까지 '비서화'했는지를 살펴봅니다.

이전에 “요즘IT 독자들이 직접 뽑은 1등 협업툴은?”에서 다뤘던 10가지 툴 중 출시 10년차 이상된 툴만 골랐습니다. AI 기능은 결국 그동안 쌓아온 사용자 기반과 업무 데이터 위에서 작동하기 때문에, 시장에서 오래 검증된 툴일수록 AI 전환의 실질적 효과를 판단하기에 적합하다고 봤습니다. 요즘IT 프로덕트 밸리 평점 순으로 정리하면, 잔디, 슬랙, 네이버웍스, 팀즈, 플로우입니다.

국내외 대표적인, 10년 넘은 메신저형 협업 툴 TOP 5. 왼쪽부터 순서대로 잔디, 슬랙, 네이버웍스, 팀즈, 플로우

각 툴이 공통으로 해결하는 문제와, 선택을 가르는 한 끗 차이를 정리하고, 마지막에는 이런 10년 넘은 협업 툴의 진화가 가진 의미를 짚어보겠습니다.

잔디(JANDI): 대화를 사내 지식으로 바꾸는 ‘스프링클러’

프로덕트 밸리 평점 4.52

메신저형 협업툴을 오래 써본 팀일수록 이상한 순간에 발이 묶입니다. 분명 예전에 채널에서 결론이 났는데, 막상 다시 찾으려면 DM, 프로젝트 방, 파일 댓글까지 다 뒤져야 하죠. 담당자가 바뀌거나 프로젝트가 재가동되면 더 심각합니다. 대화는 남아 있는데 업무 히스토리로 정리돼 있지 않아, 매번 처음부터 하게 됩니다.

잔디가 겨냥한 핵심 페인 포인트(pain point)는 간단합니다. 메시지는 계속 쌓이지만, 그게 업무 히스토리로 남지 못한다는 점입니다. 채널과 DM, 프로젝트 방에 흩어진 대화는 시간이 지나면 그때 그 일을 담당했던 누군가가 알았던 내용으로만 남습니다. 그래서 담당자 교체가 생기면 인수인계가 길어지고, 프로젝트를 다시 시작할 때는 맥락을 복원하는 데만 며칠이 걸립니다. 이러한 문제를 AI를 통해 어떻게 해결하고 있을까요?

국내 대표 메신저형 협업툴 잔디. 2014년 출시됐다.

대표 AI 기능: ‘스크롤 노동' 줄이고, 필요한 걸 앞으로 꺼낸다

첫 번째는 잔디의 AI 기능 브랜드인 '스프링클러(Sprinkler)'입니다. 2025년 3월 정식 출시된 스프링클러는 대화와 문서에 흩어진 정보를 AI로 모아, 필요한 답을 찾고 요약까지 해주는 기능 묶음입니다.

구체적으로 여섯 가지 핵심 기능으로 구성됩니다.

① 생성형 AI(ASK AI): 잔디 안에서 바로 LLM에 질문하고 답변을 받아 메시지로 활용할 수 있습니다. 별도로 ChatGPT 등 외부 서비스로 이동하거나 복사·붙여넣기할 필요가 없습니다.
② 지식 베이스(Knowledge Base): 사내 정책, 규정, 매뉴얼 등을 전용 드라이브에 업로드하면 RAG 기반으로 기업에 최적화된 답변을 도출합니다.
③ 토픽 맥락 요약: 대화방에서 주고받은 메시지를 요약하고, 해당 내용을 바탕으로 질문에 답변을 얻을 수 있습니다. 과거 프로젝트 히스토리를 바로 요약해 주니, 대화창을 끝없이 내리는 ‘스크롤 노동’이 크게 줄어듭니다.
④ 파일 분석 AI: 첨부 파일을 열지 않아도 AI가 파일 내용을 요약하고, 파일과 관련된 질문에 답변합니다.
⑤ 스레드 요약: 길어진 스레드의 맥락을 분석·요약하며, 원하는 정보가 나올 때까지 연속 프롬프팅이 가능합니다.
⑥ 메시징 어시스턴트 및 메시지 번역: 문장 스타일 개선과 16개 언어 실시간 번역을 지원해, 외국인 멤버와의 협업 허들을 낮춥니다.

잔디의 지능형 대시보드 ‘잔디 홈’ 홍보 이미지 (출처: 잔디)

두 번째는 지능형 대시보드 '잔디홈'입니다. 2025년 8월 출시된 잔디홈은 개인화된 업무 대시보드로, 읽지 않은 메시지가 있으면 AI가 주제별로 요약해 핵심을 빠르게 파악할 수 있게 해줍니다. 오늘의 일정과 해야 할 일을 한 화면에서 보여주고, 생성형 AI를 바로 활용해 공지문 초안 작성이나 번역 같은 작업을 채팅창과 연결해 처리할 수 있습니다. 쉽게 비유하면, 책상 위에 쌓인 종이를 정리해 ‘오늘 확인할 것’과 ‘바로 쓸 도구’를 앞줄에 놓아주는 느낌입니다.

AI 전략(3S): ‘똑똑함’을 넘어서는 3가지 포인트

잔디의 AI 전략은 세 가지 축으로 읽을 수 있습니다. 첫 번째는 정확도(Smart) 입니다. 잔디는 주제별 대화방(토픽)을 기준으로 AI가 동작하도록 설계해, 주제와 연결된 정보만을 바탕으로 답변을 생성합니다. 여기에 RAG 기반 지식 베이스를 더해 기업 내부 문맥에서 엉뚱한 답을 내는 환각(Hallucination)을 줄이는 방향에 초점을 둡니다. 협업툴에서는 ‘그럴듯한 답’보다 ‘틀리지 않는 답’이 더 중요하다는 전제입니다.

두 번째는 안전성(Secure) 입니다. 협업툴은 업무 데이터가 한곳에 모이는 만큼, 보안은 켜고 끄는 옵션이 아니라 시작 조건에 가깝습니다. 잔디는 100% SaaS 기반으로 운영되며, AI 기능도 기업 데이터 유출을 방지하는 안전한 환경 위에서 설계됩니다. 즉, 편리함을 위해 안전을 나중에 붙이지 않겠다는 의지를 보입니다.

세 번째는 업무 밀착(Seamless) 입니다. 잔디는 한국 기업 문화에 맞는 흐름으로 AI를 붙여, 지식 관리 플랫폼에 가까운 방향을 지향합니다. 서준호 CTO가 잔디홈을 출시하며 낸 보도자료를 통해 ‘인텔리전스 허브(Intelligence Hub)로 발전시키겠다’고 밝힌 것처럼, 메신저 안에서 자연스럽게 AI를 쓰고 결과물을 바로 업무에 연결하는 구조를 만들어가고 있습니다. 멋진 데모가 아니라, 실제 팀의 보고·공유·인수인계 흐름에 들어오게 만드는 전략입니다.

한 줄 평가: 메신저를 ‘회사 지식’으로 바꾸려는 AI

정리하면, 잔디의 포지셔닝은 ‘메신저를 회사의 기억(지식)으로 바꾸려는 AI’입니다. 경쟁의 축은 화려한 생성 기능이 아니라, 검색·요약으로 히스토리를 복원하는 능력과 업무 우선순위를 앞으로 꺼내는 능력입니다. 협업툴이 AX의 출발점이 되려면, 결국 ‘대화가 자산이 되는가’가 핵심인데, 잔디는 그 지점을 정면으로 공략합니다.

리뷰를 작성한 뒤 이 링크에 휴대폰 번호를 남겨주셔야 응모가 완료됩니다!

슬랙(Slack): ‘주 97분 절약’을 내세운 검색·요약 중심의 생산성 AI

프로덕트 밸리 평점 4.40

슬랙은 ‘탐색 비용’을 줄이는 데 AI를 집중 투입했습니다. 채널이 늘어날수록 협업툴은 편해지기보다 피곤해집니다. 하루에도 몇 번씩 “어디에 뭐가 있었지?”를 묻게 되고, 검색을 해도 원하는 결론이 바로 나오지 않기 때문입니다. 메시지는 쌓이는데, 맥락은 흩어져서 결국 사람의 시간이 들어갑니다. 이 문제를 해결하는 슬랙의 방식을 살펴보겠습니다.

메신저형 협업툴 슬랙. 2013년 출시됐다.

대표 AI 기능: ‘찾기’와 ‘읽기’를 AI에게 맡긴다

슬랙의 검색 답변(Search Answers)은 검색 결과를 링크로 나열하는 대신, 대화 맥락을 읽고 ‘답’ 형태로 정리해줍니다. 필요한 문장만 뽑아 건네는 방식이죠. 그래서 사용자는 채널을 오가며 확인하는 비용을 줄일 수 있습니다. 검색이 ‘탐색’이 아니라 ‘결론 도착’에 가까워집니다.

슬랙 AI 기능 (출처: 슬랙 홈페이지)

요약 기능도 같은 방향입니다. 읽지 못한 수백 개 메시지를 몇 문장으로 줄여, 지금 따라가야 할 맥락을 빠르게 복구합니다. 특히 일일 요약(Recaps)은 사용자가 구독한 채널의 주요 내용을 매일 아침 브리핑해, 업무 우선순위를 즉시 잡게 돕습니다. 회의 전후로 ‘어제 무슨 얘기였지?’를 묻는 시간이 줄어듭니다.

자동화는 워크플로 빌더에서 강화됩니다. 사용자가 자연어로 “이런 상황이면 이렇게 처리하고 싶다”라고 설명하면, AI가 맞는 워크플로를 추천하거나 초안을 만들어줍니다. 개발이나 복잡한 설정 없이, 반복 업무를 조금씩 기계에게 넘기는 출발점이 됩니다.

슬랙 워크플로 빌더 (출처: 슬랙 홈페이지)

또 하나는 서드파티 AI 연동입니다. 슬랙은 단일 툴이라기보다, 노션·구글 드라이브·세일즈포스 같은 수천 개 앱을 대화창에 붙여 쓰는 구조입니다. 그래서 슬랙 대화창 하나가 업무를 처리하는 지능형 허브 역할을 하게 됩니다. 사용자는 “어디 앱에서 처리해야 하지?”를 덜 고민하게 됩니다.

AI 전략: 보안과 신뢰

메신저형 협업툴의 현실은 단순합니다. 대화에는 일정, 고객, 내부 이슈 같은 민감정보가 자연스럽게 섞입니다. 슬랙은 이 전제를 피하지 않고, 보안과 신뢰를 AI 전략의 중심에 둡니다.

핵심은 LLM을 슬랙의 신뢰 경계 안에서 호스팅하는 ‘에스크로 VPC’ 방식입니다. 그리고 고객 데이터로 LLM을 학습시키지 않는 원칙을 강조합니다. 이 지점이 글로벌 엔터프라이즈에서 신뢰를 쌓는 방식입니다.

한 줄 평가(포지셔닝): ‘97분’을 숫자로 못 박은 검색·요약 AI

슬랙의 포지셔닝은 선명합니다. 사용자가 업무에 집중할 시간을 안전하게 벌어주는 AI입니다. 슬랙 AI 사용자는 주당 평균 97분을 절약한다는 지표로, 효율성을 감각이 아니라 숫자로 증명하려 합니다.

또한 10년간 쌓인 대화의 맥락(Context)을 버리지 않으면서, 필요한 정보만 핀셋처럼 뽑아주는 인터페이스에 집중합니다. 정리하면 슬랙의 AI는 화려한 생성보다, 협업툴에서 가장 자주 발생하는 고통인 검색과 요약을 끝까지 파고듭니다.

네이버웍스(NAVER Works): 하이퍼클로바X 기반 ‘한국어 맥락’ 최적화와 조직 맞춤형 AI

프로덕트 밸리 평점 3.39

한국어 기반의 조직에서 한국어 품질은 ‘있으면 좋은 옵션’이 아니라, 이 협업툴을 써도 되는지를 가르는 입구가 됩니다. 메일과 메신저에는 생략도 많고 뉘앙스 알아야 이해할 수 있는 문장들이 많은데, 협업툴의 AI가 만들어주는 요약이 엉뚱하거나 맥락을 놓치는 추천을 해준다면 사용자는 바로 기능을 꺼버립니다.

여기에 공공·금융처럼 보안과 내부통제가 강한 업종은 장벽이 더 높습니다. 외부 AI를 연결하기 어렵고, 데이터가 어디로 가는지 설명하기도 까다롭습니다. 그래서 한국어를 잘하는 것만큼, ‘우리 조직 환경에서 안전하게 돌아간다’가 도입의 전제 조건이 됩니다. 네이버웍스는 이 문제를 AI로 풀고 있습니다.

메신저형 협업툴 네이버웍스. 2013년 출시됐다.

대표 AI 기능: 커뮤니케이션 부담을 줄이는 방향

네이버웍스의 핵심은 메일에서 바로 체감되는 기능입니다. 메일 요약과 답장 추천으로, 읽는 시간과 쓰는 시간을 동시에 줄여줍니다. 메일을 다 읽기 전에 핵심을 먼저 잡고, 첫 문장을 덜 고민하게 만드는 방식입니다.

다음은 AI 스튜디오입니다. 완성된 AI 기능을 ‘그냥 쓰는’ 데서 끝나지 않고, 팀 업무 방식에 맞춘 맞춤형 업무 어시스턴트를 직접 만들 수 있게 합니다. 메시지, 게시판 등의 데이터를 기반으로 맞춤형 업무용 AI 어시스턴트를 손쉽게 제작할 수 있습니다.

네이버웍스 AI 스튜디오 출시 홍보 이미지 (출처: 네이버웍스)

여기에 기업용 클로바노트를 결합하면 회의 흐름이 정리됩니다. 회의에서 나온 말을 기록으로 남기고, 그 기록이 공유로 이어지면서 누락이 줄어듭니다. 즉 ‘회의-기록-공유’가 한 덩어리로 연결되며, 회의가 끝난 뒤의 정리 작업이 가벼워집니다.

AI 전략: ‘한국어 최적화’와 ‘조직 맞춤’의 결합

첫 번째 전략은 AI 제작 플랫폼화입니다. AI 스튜디오를 통해 비개발자도 사내 데이터 기반의 어시스턴트를 만들어 배포하는 구조로 바꾸고 있습니다. 실제로 베타 3개월 동안 830개가 제작됐다는 점은, 기능보다 ‘만들 수 있는 판’에 무게를 둔 선택으로 읽힙니다.

두 번째는 네이버 AI 생태계의 수직 통합입니다. HyperCLOVA X, 클로바노트, 파파고 같은 기술을 협업툴 안에 묶어 메일, 회의록, 번역, 문서 요약을 끊김 없이 잇습니다. 사용자는 앱을 옮겨 다니기보다, 한 공간에서 업무 맥락을 이어가게 됩니다.

세 번째는 공공·보안 민감 시장을 정면으로 겨냥한 접근입니다. CSAP 인증 획득, 행정망 내 SaaS 제공, ‘클로바 스튜디오 포 거브(CLOVA Studio for Gov)’를 통해 외부 AI를 쓰기 어려운 기관에서도 생성형 AI를 활용할 수 있는 조건을 갖춥니다. 결과적으로 ‘보안 때문에 못 쓴다’는 이유를 줄이며, 공공기관에서의 협업툴 포지션을 선점합니다.

네 번째는 일본에서의 검증을 바탕으로 한 확장입니다. 일본 유료 비즈니스 챗 8년 연속 1위, 글로벌 고객사 59만 곳이라는 실적을 기반으로 한·일 양국에서 AI 협업 플랫폼의 표준을 만들겠다는 흐름입니다. 국내 최적화에 머무르지 않고, 검증된 시장 레퍼런스로 다음 단계를 준비하는 셈입니다.

한 줄 평가: 한국 조직의 문맥을 가장 잘 알아듣는 AI 비서

네이버웍스는 ‘한국 조직의 문맥을 가장 잘 알아듣는 AI 비서’를 지향합니다. 협업툴에 AI가 더해질 때는 거창한 자동화보다 ‘한국어로 정확히 이해하고, 조직 방식에 맞게 쓸 수 있냐’에 가깝습니다. 결국 네이버웍스의 무기는 기능의 개수보다, 한국어·현업 맞춤이라는 한 끗 차이입니다.

MS 팀즈(Teams): M365를 관통하는 코파일럿, 회의의 ‘결정·실행’을 자동화하다

프로덕트 밸리 평점 3.32

회의는 끝났는데, 진짜 일은 시작도 못 하는 날이 많습니다. 누가 무엇을 하기로 했는지, 언제까지인지가 회의록·메일·채팅·캘린더로 흩어지면 말만 하고 끝나는 회의가 됩니다. 결국 회의 내용을 다시 정리하고, 다시 공유하고, 다시 확인하는 이중 업무가 생깁니다. 여기에 하루 수백 개씩 쌓이는 채팅과 채널 메시지까지 더하면, 따라잡는 것 자체가 일이 됩니다.

팀즈가 겨냥한 핵심 페인포인트는 바로 이 회의 피로도와 맥락의 단절, 그리고 채팅 과부하입니다. 팀즈는 이 문제를 어떻게 AI로 해결하고 있을까요?

메신저형 협업툴 마이크로소프트 팀즈(Microsoft Teams). 2017년 출시됐다.

대표 AI 기능: 결정과 실행을 한 번에 붙입니다

팀즈의 인텔리전트 리캡(Intelligent Recap) 은 회의가 끝나면 결정 사항과 후속 작업(Action Items) 을 자동으로 뽑아줍니다. 사람이 회의 내용을 되감기하며 정리하지 않아도, ‘무엇을 하기로 했는지’가 먼저 정리됩니다. 핵심은 요약이 아니라, 실행을 위한 단위로 쪼개준다는 점입니다. 요약 템플릿도 '발언자별 정리', '핵심 요점 중심' 등 여러 형태로 선택하거나 직접 만들 수 있어서, 팀마다 원하는 회의록 포맷에 맞출 수 있습니다.

마이크로소프트 팀즈 리캡 (출처: 팀즈 홈페이지)

회의 중에도 AI가 작동합니다. "아까 누가 리스크 얘기했지?" 같은 질문이 나오면, 실시간 코파일럿 Q&A가 회의 흐름을 끊지 않고 필요한 맥락을 즉시 찾아줍니다. 화면에 공유된 파워포인트나 웹 콘텐츠도 이해하기 때문에, 대화 내용뿐 아니라 시각 자료까지 포함해서 질문에 답합니다. 회의가 길어질수록 생기는 '기억의 공백'을 줄여주는 장치입니다.

마이크로소프트 팀즈 실시간 코파일럿 (출처: 팀즈 홈페이지)

회의 밖에서도 같은 논리가 적용됩니다. 채팅·채널 요약 기능은 출장이나 휴가 후 수백 개 쌓인 메시지를 핵심만 추려 보여줍니다. 최대 30일간의 메시지를 분석해 주요 논의, 결정 사항, 미해결 항목을 정리하고, 원문 메시지로 바로 이동할 수 있는 인용 번호까지 붙여줍니다. 채팅에서 공유된 파일도 열어보지 않고 코파일럿이 요약해주는 기능까지 더해져, 읽는 비용 자체를 줄입니다.

여기에 2025년 하반기부터는 협업형 에이전트가 추가됐습니다. 채널마다 붙는 채널 에이전트는 대화 속에 묻힌 마감일을 찾아내거나, 진행 상황을 요약하거나, 자연어로 질문하면 답하는 ‘팀 전용 AI 동료’ 역할을 합니다. 회의에는 퍼실리테이터 에이전트가 안건 준비부터 미해결 질문 추적까지 맡습니다. 코파일럿이 "개인 비서"였다면, 에이전트는 "팀 비서"로 확장된 셈입니다.

AI 전략: M365를 관통해 ‘심리스한 업무 비서’가 됩니다

팀즈의 강점은 협업툴 하나의 기능이 아니라, Microsoft 365 전체를 잇는 연결력에 있습니다. 회의에서 나온 결정은 Planner의 태스크로, 논의 내용은 Word 문서로, 요약은 Outlook 메일로 바로 이어집니다. 문서·메일·캘린더·회의·채팅을 따로 보지 않게 만들고, 하나의 흐름으로 묶습니다. 코파일럿에게 "이번 주 Teams 채팅과 이메일에서 프로젝트 X 관련 내용을 요약하고, 내가 후속 조치할 항목을 정리해줘"라고 요청하면 채팅·메일·캘린더를 교차 분석해 답변을 생성하는 식입니다. 즉, 팀즈는 회의만 똑똑하게 만드는 게 아니라, 회의 이후의 문서 작업과 커뮤니케이션까지 이어지는 '심리스(Seamless)한 업무 비서'를 지향합니다. 독보적인 점유율과 배포력은 이 전략을 현실로 만드는 기반입니다.

한 줄 평가: 회의와 문서가 많은 조직의 표준형 AI 비서

팀즈는 “회의와 문서가 많은 조직의 표준형 AI 비서”에 가깝습니다. 특히 결정 → 후속 실행을 끊기지 않게 연결하는 데 강합니다. 회의를 줄이는 것보다 ‘회의가 남기는 결과물’을 자동화하는 접근입니다. 회의를 실행으로 바꾸는 전략이죠.

플로우(flow): 자연어로 프로젝트를 ‘생성’하고 ‘진행’시키는 실행형 AI(Flow AI 2.0)

프로덕트 밸리 평점 3.09

프로젝트 관리형 협업툴을 도입할 때, 가장 먼저 부딪히는 벽은 ‘세팅’입니다. 일을 쪼개고, 담당자를 붙이고, 일정을 깔끔히 정리해야 비로소 굴러가는데요. 기능이 많을수록 이 초기 작업이 더 무겁게 느껴집니다. 그러다 보면 "일단 급하니까"라는 이유로, 결국 엑셀로 회귀하는 장면이 자주 나옵니다.

여기에 한 가지 더, 하루 업무가 끝나면 "오늘 뭘 했지?"를 정리하는 시간도 적지 않습니다. 프로젝트 관리 도구에 기록은 쌓이는데, 그걸 다시 보고서로 바꾸는 건 결국 사람의 몫입니다. 플로우가 겨냥한 지점은 딱 여기입니다. 프로젝트 관리 도구의 실패는 기능 부족이 아니라, 첫 단추를 끼우기 어렵고 반복 작업이 계속 발생해서 생깁니다. 플로우는 이 부담을 자연어로 낮추는 쪽을 선택했습니다.

메신저형 협업툴 플로우(flow). 2015년 출시됐다.

대표 AI 기능: 자연어로 프로젝트를 만들고, 아래까지 내려줍니다

플로우의 AI 기능 중 대표적으로 다섯 가지를 소개합니다.

① AI 프로젝트 생성: "마케팅 캠페인 프로젝트 만들어줘"처럼 말하듯 입력하면, AI가 프로젝트를 만들고 그 아래에 필요한 업무 리스트까지 자동으로 뽑아줍니다. 빈 칸이 가득한 기획서 앞에서 멈추는 대신, AI가 "일단 초안"을 깔아주는 방식입니다.

② AI 하위 업무 생성: 업무명만 작성하면, 그 업무를 완료하기 위해 필요한 후속 업무들을 AI가 자동으로 제안합니다. 프로젝트 생성이 "큰 틀"을 잡아준다면, 하위 업무 생성은 "실행 단위"까지 쪼개주는 역할입니다.

③ AI 일일보고: 오늘 내가 플로우에서 한 활동(업무 상태 변경, 댓글, 완료 처리 등)을 AI가 자동으로 요약해서 게시글로 만들어줍니다. "오늘 뭐 했지?"를 되짚으며 보고서를 쓰는 시간을 줄여주는 기능입니다.

④ AI 업무 필터: "이번 주 마감인 마케팅팀 업무 보여줘"처럼 자연어로 검색하면, 복잡한 필터 조건 없이 원하는 업무를 바로 찾아줍니다. 비서에게 말하듯 검색하는 방식입니다.

⑤ AI 게시글 템플릿: 주간보고, 회의록, 공지문 등 자주 쓰는 포맷의 콘텐츠를 AI가 맞춤으로 생성해줍니다.

AI 전략: ‘요약’이 아니라 ‘실행’으로 시간을 줄입니다

플로우는 2025년 5월 10주년 행사에서 "AI 에이전트 협업툴"로의 전환을 선언했습니다. 핵심은 자체 개발한 AI 에이전트 제품군 메이트X(MateX) 입니다. 'Mate'라는 이름에는 AI를 단순 자동화 도구가 아니라 함께 일하는 '동료'로 보겠다는 철학이 담겨 있습니다.

메이트X는 LLM 기반 챗봇에 플로우의 협업 데이터를 결합한 RAG 에이전트로 구성됩니다. 기존 5가지 AI 기능에 더해, AI 스마트 검색(플로우 내부 데이터는 물론 외부 클라우드까지 통합 검색)과 AI 인사이트 보고서(반복 보고서 자동화, 핵심 내용 요약 후 경영진 전달)가 추가로 공개됐습니다.

방향은 명확합니다. 복잡한 PM 기능을 버튼과 메뉴로 학습시키기보다, 자연어 명령으로 제어하게 만드는 겁니다. 읽고 정리해주는 데서 끝나는 게 아니라, 프로젝트를 "만들고 굴리고 보고하는" 쪽에 무게를 둡니다. 또한 전자결재, 이메일 등 그룹웨어 핵심 기능까지 통합한 '올인원 플랫폼'을 지향하며, 여러 도구를 오가는 비용 자체를 줄이려는 전략입니다.

한 줄 평가: “요약해주는 AI가 아니라, 일을 ‘만들어’ 굴리는 AI”

플로우는 "요약해주는 AI"보다 "일을 만들어 굴리는 AI"에 가깝습니다. 특히 프로젝트의 셋업과 운영 자동화, 그리고 일일보고에서 강점을 드러냅니다. 메시지 중심으로 흐르는 잔디, 슬랙, 팀즈, 네이버웍스가 '정보를 정리해 주는 비서'에 가깝다면, 플로우는 '일감을 구조로 바꿔주는 비서'에 가깝습니다. 협업툴이 AX를 말할 때, 플로우의 답은 "말로 시키면 프로젝트가 시작된다"입니다.

10년 된 협업툴의 AI 진화가 의미하는 것

다섯 툴이 AI를 붙이는 방식은 달라도, 출발점은 같았습니다. 요약·검색·질의응답으로 "읽고 찾는 비용"을 먼저 줄인 뒤, 각자의 강점 영역으로 분기하는 구조입니다. 잔디는 흩어진 대화를 지식으로 모으고, 슬랙은 검색 피로를 제거하며, 팀즈는 회의에서 실행까지 M365 전체를 관통합니다. 네이버웍스는 한국 조직의 업무 맥락과 보안 시장에 강하고, 플로우는 일을 요약하기 전에 생성해 실행을 앞당깁니다.

그런데 이 변화를 "기능이 늘었다"로만 보면 핵심을 놓칩니다. 본질적인 전환은 따로 있습니다.

대화가 드디어 '자산'이 됩니다. 지금까지 메신저에 쌓인 수만 개의 메시지는 스크롤 아래로 묻히는 휘발성 데이터였습니다. 하지만 AI가 요약하고, 검색하고, 연결해주는 순간, 그 대화는 검색 가능한 업무 기록이 되고, 인수인계 자료가 되고, 의사결정의 근거가 됩니다. 서문에서 말한 "말은 잘 모으는데 일로 바꾸는 건 약한 도구"라는 협업툴의 10년 된 한계가, 이제야 풀리기 시작한 셈입니다.

업무 환경은 "덜 힘들게" 바뀝니다. 회의록을 다시 쓰고, 채널을 다시 뒤지고, 보고서를 다시 정리하는 이중 작업이 줄어듭니다. AI가 대신 읽고, 정리하고, 실행 단위로 쪼개주면서, 사람은 판단과 결정에 더 집중할 수 있게 됩니다. 이건 먼 미래가 아니라, 다섯 툴 모두가 지금 만들어가고 있는 현실입니다.

다만 이 변화가 제대로 작동하려면, 신뢰가 먼저입니다. AI가 업무 데이터를 다루는 이상, 정확도(엉뚱한 답을 내지 않는가), 보안(데이터가 어디로 가는가), 운영 방식(누가 무엇을 볼 수 있는가)은 편리함보다 앞서야 하는 조건입니다. 다섯 툴이 공통으로 RAG, 에스크로 VPC, CSAP 인증 같은 보안 및 신뢰 관련 키워드를 내세우는 이유도 여기에 있습니다. 결국 협업툴의 AI는 "얼마나 똑똑하냐"보다 "얼마나 믿고 쓸 수 있냐"가 도입의 첫 번째 질문이 됩니다.

도구는 버튼을 눌러 쓰는 대상에서, 맥락을 이해하는 동료에 가까워지고 있습니다. 그리고 그 동료가 진짜 쓸모 있으려면, 우리가 먼저 "무엇을 기록으로 남기고, 무엇을 AI에 맡길지"를 정하는 순서가 필요합니다. AX는 도구의 문제가 아니라, 일하는 방식을 다시 설계하는 일이니까요.

잔디를 사용해보셨다면 요즘IT 프로덕트밸리에서 리뷰를 남겨 주세요.
프로덕트 밸리에 잔디 리뷰를 남겨주신 분들(선착순 50명 한정)께 네이버페이 5,000원을 드립니다. 참여 완료 후, 아래 폼을 입력해주세요!

✅참여 완료 폼 작성하기

]]>