요즘IT » 프로덕트 » 피드

내 사이트에 MS 클라리티를 달고 직접 관측해봤습니다

웹 분석 도구는 오랫동안 ‘집계’를 중심으로 발전해 왔습니다. 하루에 몇 명이 들어왔고 몇 퍼센트가 나갔는지를 숫자로 정리해 주는 방식이죠. 우리에게 익숙한 구글 애널리틱스(GA)가 바로 이런 도구입니다.

그런데 막상 페이지를 고쳐야 하는 입장이 되면, 이런 숫자만 들고는 손이 잘 움직이지 않습니다. 대시보드가 “이 페이지 이탈률이 높습니다”라고 알려 줘도, 그래서 어디를 어떻게 손봐야 하는지까지는 말해 주지 않기 때문입니다. 그러다 보면 자연스럽게 그다음 질문이 떠오릅니다. 사용자는 이 페이지에 들어와서 무엇을 하다가 나갔을까요?

이 질문에 답하지 못한 채 페이지를 고치면 결국 감으로 고치는 셈입니다. 그리고 감으로 고친 것은 나중에 효과를 따져 볼 방법도 마땅치 않습니다.

마이크로소프트 클라리티(Microsoft Clarity)는 이 구간을 채우는 무료 도구입니다. 이 글은 도구 소개에서 멈추지 않고, 제 사이트에 붙여 한 주를 관측하며 데이터를 잘못 읽을 뻔했던 지점들과 그 뒤에 세우게 된 기준까지 담았습니다.

미리 요점만 콕 집어보면?

마이크로소프트 클라리티는 기존 분석 도구가 답하지 못하는 “어떻게” 구간을 채우는 무료 도구로, 세션 레코딩·열 지도·스마트 이벤트를 제공합니다.
열 지도는 색보다 클릭 수 총합과 필터 상태를 먼저 확인하고, 세션은 길이보다 활성 시간과 AI 요약을 직접 검증하며, 관측 기간은 요일 기준 한 주기로 잡는 편이 결론이 덜 흔들렸습니다.
도구는 관측 장비이지 판독 장비가 아니며, 무료로 붙일 수 있는 도구일수록 그 데이터를 언제 믿을지에 대한 기준을 함께 세워 두는 편이 좋습니다.

마이크로소프트 클라리티란?

먼저 클라리티가 기존 분석 도구와 무엇이 다른지, 그리고 왜 무료로 쓸 수 있는지부터 살펴봅시다.

1) 집계가 답하지 못하는 구간

기존 분석 도구가 답하는 질문은 “얼마나”입니다. 방문자 수, 페이지뷰, 이탈률 같은 것들입니다. 반면 페이지를 개선하려는 사람이 궁금한 것은 “어떻게”에 가깝습니다. 어디까지 읽고 내려갔는지, 어떤 요소를 눌렀는지 말입니다.

클라리티는 이 “어떻게” 구간을 담당합니다. 즉, 기존 도구를 대체하는 물건이 아니라 비어 있던 칸을 채우는 도구에 가깝습니다.

2) 무료이고, 사이트가 느려지지 않습니다

체험 기간이나 유료 기능이 따로 있는 형태가 아니라 전체가 무료입니다. 수집된 데이터는 내 서버가 아니라 마이크로소프트 쪽에 저장되므로, 사용자가 늘어도 내 사이트가 느려지지 않습니다. 다만 무료에는 대가가 붙어 있는데, 이 부분은 마지막 절에서 다루겠습니다.

어떤 기능을 제공할까?

기능은 크게 셋입니다. 각각이 어떤 질문에 답하는 도구인지를 중심으로 살펴보겠습니다.

1) 세션 레코딩(session recording)

세션 레코딩은 사용자의 화면 조작을 영상처럼 재생해 줍니다. 마우스가 어디로 움직였고 어디에서 스크롤을 멈췄는지가 그대로 보입니다. 실시간 관찰도 되고, 녹화되므로 나중에 몰아서 볼 수도 있습니다.

2) 열 지도(heatmap)

열 지도는 여러 세션을 겹쳐 한 화면으로 요약해 줍니다. 클릭 지도는 클릭이 몰린 위치를, 스크롤 지도는 사용자가 어디까지 내려갔는지를, 주의 지도는 화면에 오래 머문 영역을 색으로 보여줍니다.

3) 스마트 이벤트(smart events)

스마트 이벤트는 같은 곳을 연타하는 rage click, 클릭되지 않는 요소를 누르는 dead click처럼 문제를 암시하는 행동을 자동으로 잡아 줍니다. 해당 세션만 걸러 볼 수 있고, 세션마다 AI 요약도 붙습니다.

설치와 첫 관측

설치는 짧게 끝나지만, 직후에 한 번 헤매게 되는 구간이 있어 함께 적었습니다.

1) 프로젝트 만들고 스크립트 넣기

프로젝트를 만들면 설치 방법을 고르는 화면이 나옵니다. 여러 방식 중 수동 설정이 단순합니다. 아래 스크립트를 문서의 `<head>`에 넣으면 됩니다. 구글 애널리틱스를 붙여 본 적이 있다면 익숙한 방식입니다.

<!-- 클라리티 추적 스크립트 -->
<script type="text/javascript">
  (function (c, l, a, r, i, t, y) {
    c[a] = c[a] || function () { (c[a].q = c[a].q || []).push(arguments) };
    t = l.createElement(r); t.async = 1;
    t.src = "https://www.clarity.ms/tag/" + i;
    y = l.getElementsByTagName(r)[0];
    y.parentNode.insertBefore(t, y);
  })(window, document, "clarity", "script", "YOUR_PROJECT_ID");
</script>

프레임워크를 쓰면 넣을 위치가 프로젝트마다 다릅니다. 저는 이 코드를 그대로 복사해 AI 에이전트에 넘기고 “프로젝트 구조에 맞게 삽입해 달라”고 요청했습니다.

2) 설치 직후에 겪은 일

여기서 저는 한 번 당황했던 부분이 있었는데요. 실시간 세션은 곧바로 잡혔지만 열 지도는 한동안 비어 있었습니다. 코드를 다시 확인하고 배포를 다시 걸어 보기도 했지만 설치는 정상이었고, 대부분의 기능이 활성화되기까지 두 시간 정도가 걸렸습니다. 실시간 세션이 잡히고 있다면 기다리는 편이 좋습니다.

직접 써보며 세운 기준

여기서부터가 이 글의 중심입니다. 기능을 아는 것과 그 데이터로 판단하는 것은 다른 일이었습니다.

1) 열 지도는 색보다 클릭 수 총합을 먼저 봅니다

열 지도가 위험한 이유는 비율을 색으로 환산해 보여주기 때문입니다. 비율은 분모가 작아도 계산됩니다. 세션이 열 건이든 만 건이든 화면 어딘가는 붉게 표시되고, 눈으로 보기에 두 화면은 똑같이 그럴듯합니다.

제 사이트의 클릭 지도가 그랬습니다. 한 주 동안 이 페이지는 98번 열렸고 클릭은 66번이었는데, 그 66번을 39개 요소가 나눠 가집니다.

<출처: 작가, Clarity 캡처>

1위는 ‘첫 레슨부터 시작’ 버튼으로 10.61%였습니다. 두 자리 퍼센트라 그럴듯하지만 실제 클릭 수는 7번입니다. 2위도 7번, 3위부터 5위는 나란히 3번(4.55%)입니다. 상위 다섯 개가 `7, 7, 3, 3, 3`이니 누군가 네 번만 더 눌러도 3위가 1위와 동률이 됩니다. 이런 분포에서 순위를 읽는 것은 의미가 없습니다.

그래서 저는 클릭 지도를 열면 색이나 순위보다 클릭 수 총합을 먼저 봅니다. 이 숫자가 두 자리에 머물면 순위는 읽지 않고 넘어갑니다. 퍼센트의 분모가 조회수(98)가 아니라 전체 클릭 수(66)이라는 점도 함께 봅니다. 어떤 버튼이 30%라고 해서 방문자의 30%가 눌렀다는 뜻이 아니고, 한 사람이 세 번 누르면 그 세 번이 모두 분자에 들어갑니다.

그래도 이 표본으로 읽을 수 있는 것은 있었습니다. 공들여 만든 소개 문구와 카드 영역에는 클릭이 거의 찍히지 않았고, 대신 사이드바 목차 항목들에 흩어져 찍혔습니다. 순위는 못 믿어도 “강조한 곳과 실제로 눌리는 곳이 다르다”는 방향성만큼은 보였습니다.

2) 필터가 걸렸는지부터 확인합니다

열 지도에는 기기, 유입 경로, 사용자 같은 필터가 있습니다. 무엇을 걸었느냐에 따라 같은 페이지가 전혀 다른 화면이 됩니다.

<출처: 작가, Clarity 캡처>

위는 같은 페이지의 스크롤 지도인데, 특정 사용자 한 명으로 필터를 건 상태라 표본이 4뷰입니다. 필터를 풀면 앞의 클릭 지도처럼 98뷰가 잡히니, 같은 페이지 같은 기간인데 표본이 스물네 배 차이 납니다. 어느 쪽이 맞고 틀린 문제가 아니라 서로 다른 질문에 답하고 있을 뿐입니다. 문제는 화면만 봐서는 필터 여부를 알아채기 어렵다는 점입니다. 그래서 열 지도를 근거로 인용할 때는 필터 상태를 함께 적어 둡니다.

주의 지도도 같은 필터로 본 화면입니다. 상단이 붉고 20% 아래 구간은 평균 소요 시간이 1초 미만이었습니다.

<출처: 작가, Clarity 캡처>

다만 체류가 길다는 사실만으로는 정독인지 혼란인지 구분되지 않습니다. 잘 쓰여서 오래 읽은 것일 수도, 어려워서 다시 읽은 것일 수도, 뭘 눌러야 할지 몰라 멈춰 있던 것일 수도 있습니다. 셋 다 같은 붉은색입니다. 주의 지도는 결론이 아니라 좌표에 가깝습니다.

3) 무슨 신호를 볼지는 사이트 규모가 정합니다

한 주 동안 쌓인 세션은 172건이었습니다. 이걸 앞에서부터 재생하는 것은 172번 중 몇 번이 걸리기를 기다리는 일에 가깝습니다. 그래서 레코딩을 목록이 아니라 검색으로 다뤘습니다. 가설을 세우고 해당하는 세션만 걸러서 봤습니다.

<출처: 작가, Claude로 생성>

퍼센트만 보면 네 가지 모두 지표처럼 보입니다. 그런데 세션 수로 바꾸면 절반은 쓸 수가 없습니다. rage click은 이름이 알려져 있어 먼저 찾게 되는 신호인데, 제 사이트 규모에서는 일주일에 1건이었습니다. 1건으로는 경향을 말할 수 없습니다. 반대로 dead click 41건과 빠른 뒤로 가기 48건은 들여다볼 만한 양입니다. 괄호 안은 한국어 화면의 표기입니다.

4) 세션은 길이순으로 정렬하지 않습니다

긴 세션부터 여는 것은 자연스러운 선택처럼 보이지만 그렇지 않았습니다. 아래는 12분 46초짜리 세션인데, 클라리티가 붙여 준 요약을 보면 01:20부터 12:45까지가 페이지가 숨겨진 상태였습니다. 실제로 화면을 보고 있던 시간은 1분 남짓입니다.

<출처: 작가, Clarity 캡처>

이 세션만의 특성이 아닙니다. 같은 기간 대시보드값이 총 시간 13.4분에 활성 시간 4.2분, 세 배 차이였습니다. 어느 쪽 숫자를 집었는지 확인하지 않으면 관심의 크기를 세 배로 부풀려 읽게 됩니다.

AI 요약도 결론이 아니라 좌표로 씁니다. 화면에 “인사이트는 AI를 통해 지원되므로 실수가 가능합니다”라고 적혀 있습니다. 위 세션도 요약이 00:38과 01:06에 문제가 있었다고 알려 주는데, 저는 그 판단을 믿는 대신 그 시점으로 건너뛰어 직접 확인합니다.

5) 관측 기간은 요일 한 주기로 잡습니다

며칠 치 데이터는 하루치를 여러 번 본 것에 가까울 수 있습니다. 트래픽은 요일에 따라 성격이 갈리기 때문입니다. 사흘 치로 판단하면 그 사흘의 성격에 결론이 끌려갑니다.

그래서 조회 구간을 날짜 수가 아니라 요일 기준으로 잡습니다. 이 글의 데이터도 일요일 오전부터 다음 일요일 오전까지 딱 7일입니다. 며칠을 봤느냐가 아니라 주중과 주말이 한 번씩 다 들어왔느냐를 기준으로 삼는 편이 결론이 덜 흔들렸습니다.

<출처: 작가, Clarity 캡처>

그 한 주 동안 쌓인 것이 세션 172건, 고유 사용자 104명이었습니다. 하루 평균 25건 안팎이라, 하루치만 떼면 어떤 지표든 몇 사람의 행동에 좌우되는 양입니다. 한 주를 채워야 세션당 페이지 수 4.12, 평균 스크롤 깊이 74.15% 같은 값을 판단 근거로 꺼낼 수 있었습니다.

6) 클라리티 단독으로는 결론이 나지 않습니다

클라리티는 페이지 안에서 벌어진 일을 잘 보여주는 대신, 그 사용자가 어디에서 왔는지에는 약합니다. 제 경우 짝으로 쓰는 도구는 비틀리입니다. 비틀리는 어떤 경로로 몇 명이 눌러서 들어왔는지를 보여주고, 클라리티는 그렇게 들어온 사람이 무엇을 했는지를 보여줍니다. 링크 바깥은 비틀리가 맡고 링크 안쪽은 클라리티가 맡는 셈입니다.

그래서 한쪽만으로는 답이 안 나옵니다. 비틀리에서 클릭이 많이 잡혀도 그 유입이 좋았는지는 알 수 없고, 클라리티에서 행동이 이상해 보여도 어느 경로로 도착했는지는 좁히기 어렵습니다.

다만 두 숫자를 나란히 놓고 비교하지는 않습니다. 비틀리는 링크 클릭을, 클라리티는 세션을 셉니다. 한 사람이 두 번 눌러도 한 세션으로 묶일 수 있고, 링크를 거치지 않고 들어온 사람은 비틀리에 잡히지 않습니다. 절대값을 맞추기보다 각 도구 안에서의 변화를 보는 편이 실용적입니다.

실무 적용과 주의할 점

마지막으로 도입 단계에서 확인할 것들을 정리해 보도록 하겠습니다.

1) 마스킹은 보안과 관측의 맞교환입니다

클라리티 이용약관에는 수집된 정보를 마이크로소프트가 활용할 수 있다는 조항이 있습니다. 금융이나 의료처럼 개인정보 민감도가 높은 서비스라면 그대로 도입하기 어려울 수 있습니다. 대신 특정 영역을 수집에서 제외하는 마스킹을 설정할 수 있습니다.

<!-- 이 영역은 레코딩에서 가려집니다 -->
<div data-clarity-mask="true">
  <span>{{ user.email }}</span>
  <span data-clarity-unmask="true">주문 상태: 배송 중</span>
</div>

여기서 판단이 필요합니다. 마스킹을 건 영역은 레코딩에서도 보이지 않습니다. 보안을 위해 가린 만큼 관측 능력을 잃는 셈입니다. 입력 폼을 통째로 가리면 개인정보는 지켜지지만 사용자가 어느 칸에서 멈췄는지도 함께 사라집니다. 그래서 저는 폼 단위가 아니라 값이 들어가는 요소 단위로 가립니다.

2) 도입을 미루는 편이 나은 경우

이 도구가 어울리지 않는 상황이 두 가지 있습니다. 하나는 앞서 이야기한 민감 정보 중심의 서비스이고, 다른 하나는 아직 트래픽이 충분히 쌓이지 않은 사이트입니다.

트래픽이 적은 경우가 조금 더 까다롭습니다. 설치해 두는 것 자체는 부담이 없지만, 데이터가 적은 상태에서 열 지도를 열면 오독의 위험만 커집니다. 판단 근거가 아니라 판단을 왜곡하는 화면이 되는 셈입니다. 설치는 해 두되, 일정 기준을 넘기기 전까지는 대시보드를 열지 않는 편이 낫습니다.

마치며

클라리티는 무료이고, 설치는 스크립트 하나를 넣는 것으로 끝나고, 화면은 직관적입니다. 도입 장벽이 낮다는 점에서 개인 프로젝트나 소규모 서비스에 잘 어울립니다.

다만 직접 운영해 보고 남은 감각은 조금 다릅니다. 이 도구가 준 것은 답이 아니라 질문이었습니다. 열 지도의 붉은 영역은 “여기가 문제다”라고 말해 주지 않습니다. “여기서 무언가 일어나고 있으니 확인해 보라”고 말할 뿐입니다.

여기 정리한 여섯 가지는 특별한 기법이 아닙니다. 데이터를 다룰 때 원래 지켜야 하는 것들에 가깝습니다. 그런데 행동 데이터는 화면이 직관적이라서 오히려 이 기본을 건너뛰게 만드는 힘이 있습니다. 숫자로 된 지표는 해석이 필요하다는 사실을 스스로 알려주지만, 붉게 물든 화면은 이미 해석이 끝난 것처럼 보이기 때문입니다.

도구는 관측 장비이지 판독 장비가 아닙니다. 무료로 붙일 수 있는 도구일수록, 그 데이터를 언제 믿을지에 대한 기준을 함께 세워 두는 편이 좋습니다.

*이 글은 AI의 도움을 받아 작성했습니다. (예제 코드 생성 및 교정/교열)

<참고>

]]>

Orca vs. Paseo vs. 순정: 에이전트 관리 도구 비교하기

Claude가 나은지 GPT가 나은지 따져 보는 게 세상 제일 중요하던 때가 있었습니다. 그러다 사용 경험을 가르는 변수가 모델에서 래퍼, 그러니까 에이전트를 감싸는 그 무언가로 내려왔습니다. Claude Code와 Codex 같은 것들이 대표적이죠. 이들을 비교하는 것 역시 매우 인기를 얻었는데요, 이제 26년 하반기 들어서는 그 비교가 좀 줄어든 느낌입니다. 하나 고를 것 없이 좋은 거 다 쓴다는 생각이 퍼졌거든요. 실제로 좀 쓴다는 사람들은 모델 하나를 고르는 대신 여러 계정과 여러 하네스를 구독해 두고 돌려 씁니다.

문제는 이 작업들이 여전히 터미널과 모델을 공급하는 회사의 제품에 묶여 있다는 점입니다. 게다가 세션 하나의 컨텍스트를 관리하는 것만으로도 머리가 아픈데 세션 여러 개가 오가는 걸 보고 있자니 피로가 말도 안 됩니다. 그래서 요즘 주목받는 도구가 Orca와 Paseo입니다.

‘에이전트를 몇 개 돌릴 수 있는가’에는 이미 한계가 없습니다. 할 수 있는 만큼 하는 거죠. 구독만 있으면 세션이야 얼마든지 늘릴 수 있으니까요. 지금의 한계선은 사람이 몇 개를 지켜볼 수 있느냐입니다. 그래서 이 글에서는 Orca와 Paseo가 무엇을 해결해 주는지 살펴보고, 터미널을 그대로 쓰는 ‘순정’과 견줘 언제 무엇을 고르면 좋을지 정리해 보려고 합니다.

왜 지금 이런 도구가 주목받을까?

<출처: 작가, Gemini로 생성>

‘실행’에서 ‘감독’으로

2026년 들어 중요한 건 “에이전트 여러 대를 동시에 어떻게 관리하나”입니다. 개인 개발자도 에이전트를 3~5개씩 같이 돌리기 시작했거든요.

에이전트가 코드를 쓰는 동안 사람이 하는 일은 지시를 내리고 검토 대기열을 관리하는 쪽입니다. 에이전트가 무엇을 할 수 있느냐보다 몇 개를 동시에 지시하고 리뷰할 수 있느냐가 문제입니다. 그러니까 사람이 병목인 거죠. 그래서 그 사람이란 병목을 조금이나마 줄여보고자 감독을 잘하기 위한 장비들이 필요해졌습니다.

하네스가 앱으로 나와도 남는 한계

물론 코딩 에이전트를 만드는 회사들도 이를 잘 알고 있습니다. 그래서 Claude Code와 Codex도 이제 터미널에서만 쓸 수 있는 물건이 아닙니다. 데스크톱 앱과 웹, 여러 기능이 생기면서 편의성은 분명 올라갔죠. 그런데 여러 세션을 나란히 놓고 감독하는 화면은 여전히 없습니다. 어느 세션이 멈춰 있는지 한눈에 알 수 없다는 것, 이게 여러 대를 돌릴 때 사람 시간을 가장 많이 잡아먹는 지점인데 말이죠.

계정 쪽도 비슷합니다. 구독 계정을 바꾸려면 매번 다시 로그인해야 하는 데다, 지금 이 계정에 사용량이 얼마나 남았는지 한눈에 들어오는 대시보드가 없으니 감으로 관리해야 합니다. 컴퓨터 앞을 떠나는 순간 작업 접근이 끊기는 것도 문제예요. SSH나 모바일 터미널로 우회할 수는 있지만 폰 화면에서 터미널을 조작하기엔 엄청 불편합니다.

새 도구들이 보여준 기능 4가지

5개월 전 제가 오케스트레이터 도구들을 다룰 때 기준으로 삼았던 격리·가시성·리뷰는 이제 이 카테고리의 기본기가 됐습니다. 지금 주목 받는 도구, Orca와 Paseo는 그 위에 더 많은 걸 구현했습니다.

첫째, GUI가 들어왔습니다. 보기 좋은 게 최고입니다. 이제 워크트리 여러 개를 눈으로 보면서 각각에 에이전트를 붙일 수 있습니다. 뭐가 달라졌는지 확인한 다음 각각 코멘트를 달아 그대로 에이전트에 되돌리기도 하죠. 실제 창을 띄워 UI 요소를 클릭하면 그 HTML/CSS가 프롬프트로 들어가기까지 합니다.

둘째, 계정과 쿼터 관리가 훨씬 쉽습니다. Orca는 상태바에 현재 사용량과 한도 리셋 시점을 띄워둡니다. 무엇보다 다시 로그인할 필요 없이 계정을 바꿔줍니다. 2026년 들어 사용 한도 압박이 커지면서 개인 구독과 회사 구독을 같이 쓰는 사람이 늘었는데요, 그때마다 다시 로그인하는 게 일이었거든요.

셋째, ‘오케스트레이션’을 지원합니다. 약간 뜻이 다르긴 합니다. Orca에서는 한 작업을 여러 에이전트에 동시에 던져 결과를 비교하고 더 나은 걸 채택하는 일을 뜻합니다. 반면 Paseo에서는 한 사람이 여러 세션을 어디서든 조종하는 일을 뜻하고요. 어쨌든 ‘여러 에이전트’를 다루는 게 훨씬 쉬워졌습니다.

넷째, 핸드폰으로 쓰기 좋아졌습니다. 에이전트가 한 번 돌기 시작하면 수 분에서 수십 분이 걸립니다. 원래라면 언제 끝나나 싶어서 컴퓨터 앞을 서성여야 했죠. 그래서 원격 접근과 모바일 지원이 또 들어왔습니다.

보기만 해도 훨씬 좋아 보이죠. 이제 본격적으로 두 가지 핫한 도구가 왜 그리 유명한지 보겠습니다.

Orca: ‘감독’ 능력 최적화

Orca는 에이전트 여러 대를 한 화면에서 보기 쉽게 해주는 로컬 설치형 에이전트 전용 개발 환경(ADE, Agent Development Environment)입니다. 랜딩 페이지 문구인 “Ship 100x With The Agent IDE”만 봐도 뭘 원하는지 바로 알겠습니다. 에디터와 터미널, 브라우저, GitHub·Linear 이슈까지 개발에 쓰던 화면을 앱 하나로 흡수한 쪽입니다. 즉, 감독으로 일하기에 가장 좋습니다.

스펙은 이렇습니다. macOS·Windows·Linux 환경을 지원하고요, Claude Code·Codex·Gemini·Cursor 등 지원 에이전트는 25~30개에 이릅니다. 도구는 무료이고 모델 비용은 내 구독과 API 키에서 나갑니다.

orca

무엇을 해줄까?

병렬 워크트리: 격리된 git 워크트리를 여러 개 띄우고 각각에 에이전트를 붙입니다. 쉬운 말로, 에이전트 여럿이 일하기 제일 좋은 환경으로 만들어 줍니다.
디자인 모드(Design Mode): 각 작업대마다 눈에 보이는 화면이 뜹니다. 화면에서 UI 요소를 클릭하면 그 HTML/CSS가 프롬프트로 주입됩니다. 말로 설명하기 힘든 시각 요소를 가리키는 커서가 생기는 셈이죠.
계정 바꾸기와 한도 대시보드: Claude·Codex 계정을 재로그인 없이 바꾸고 상태바에서 현재 사용량과 한도 리셋 시점을 확인합니다.
인라인 코멘트: 변경 사항 비교에 마크다운 주석을 달면 그대로 에이전트에 되돌아갑니다.
SSH 원격 워크트리: 성능 좋은 원격 머신에서 돌리면서 파일 편집, git, 터미널을 쓰기 좋습니다.

여기에 한 작업을 여러 에이전트에 시켜보고 결과를 비교하는 /orchestrate 명령, PR과 이슈를 앱 안에서 열어 볼 수 있는 GitHub·Linear 연동도 지원합니다. iOS와 Android 앱도 있는데, 엄청 많은 일을 하기보다는 라이브 모니터링용 보조 화면이라고 보는 게 좋습니다.

장점과 아쉬운 점

장점

“GUI라서 되는 일”의 대부분이 이 앱 안에 들어 있습니다. 특히 브라우저에서 요소를 집어 지시하는 디자인 모드가 프론트엔드 작업에서 체감이 정말 크다는 리뷰들이 많이 보였습니다. 계정 관리도 편하고 GitHub 연동은 말해 무엇 하고 아무튼 장점이 많습니다.

단점

아쉬운 점은 그걸 만드느라 좀 무겁다는 겁니다. 앱 하나가 통째로 새 개발 환경이라 에디터, 터미널, 브라우저를 다 Orca 기준으로 갈아타야 합니다. 그만큼 학습과 연동이 어렵습니다. 기존 설정에 손때가 묻은 사람일수록 옮길 마음을 먹기가 어렵죠. 기능이 많아 화면 자체도 무겁습니다. 그러니 워크트리를 1~2개만 쓰는 사람에게는 과잉으로 보입니다.

이런 상황에 추천합니다

에이전트를 최소 3~5개 이상 돌리며 쉬지 않고 리뷰해야 하는 사람에게 가장 잘 맞습니다. 혹은 브라우저에서 요소를 하나하나 뜯어 고치는 일이 잦은 프론트엔드 작업이라면 디자인 모드 하나만으로도 도입할 이유가 있어 보이고요. 개인과 회사 구독을 둘 이상 두고 쓰는 사람, 노트북 성능은 별로인데 빌드가 무거워 원격 환경에서 돌려야 하는 사람에게도 값을 합니다.

반대로 말하면 터미널 세션 하나로 충분한 사람이 여기서 얻을 것은 많지 않습니다.

Paseo: 어디서든 ‘감독’할 수 있는 도구

Paseo는 어디서든 쉽게 에이전트를 돌리는 데 최적화되어 있습니다. 스스로를 “내 머신과 폰, 데스크톱, CLI에서 코딩 에이전트를 돌리는 독립 오픈소스 프로젝트”라고 소개할 만큼요.

애초에 이걸 만든 개발자가 2025년 9월 산책하면서도 에이전트에 명령을 내리고 싶어 만든 음성 인터페이스가 출발이라고 합니다. 제품명 paseo부터가 스페인어로 ‘산책’이라는 뜻이죠. 자전거를 타면서 폰으로 확인했다는 사람, 공원 벤치에서 작업을 이어갔다는 사람, 아이들과 시간을 보내면서 개발한다는 사람들의 후기가 올라와 있습니다. 낡은 태블릿에서도 돌아갈 만큼 가볍기도 하대요.

스펙은 이렇습니다. 공식으로 지원하는 최적화 에이전트는 일단 Claude Code·Codex·Copilot·OpenCode·Pi 5종입니다. macOS, Linux에서 돌고 클라이언트는 데스크톱, 웹, iOS, Android, CLI고요. 마찬가지로 도구는 무료, 모델 비용은 직접 부담해야 합니다.

paseo

무엇을 해줄까?

어디서든 에이전트 돌리기: macOS 네이티브 데스크톱, 웹, iOS/Android 앱, CLI가 모두 세션 하나를 조종할 수 있습니다. 클라이언트마다 격차도 작아 폰에서도 데스크톱과 거의 같은 구조로 일을 줍니다.
집 밖 접속 경로 3가지: 종단간 암호화 릴레이(“Paseo는 트래픽을 읽을 수 없다”고 합니다), Tailscale·Cloudflare Tunnel 같은 자체 터널, 포트 직접 노출 중에 고릅니다.
음성 지시: 프로젝트의 시작인 만큼 편리합니다. 기본은 기기 로컬 환경에서 처리하는데, 전사·TTS 품질이 필요하면 OpenAI 음성 공급자를 연결합니다.
리뷰부터 머지까지: 브랜치 생성, 브라우저 프리뷰, 인라인 diff 리뷰, 커밋/PR/머지를 Paseo 안에서 끝낼 수 있습니다. git 워크트리 격리도 됩니다.

팀 단위로 쓸 일이 있다면 GitHub, Slack, Discord 트리거로 접근을 붙이는 Hub 기능이 있습니다. 프라이버시 설계도 좋아 코드가 샐 일이 적어 보입니다.

장점과 아쉬운 점

장점

아주 뚜렷합니다. 접근성이죠. 에이전트가 10~30분씩 도는 동안 컴퓨터 앞에 붙어 있을 이유가 사라집니다. 세션 수를 늘려주기보다 세션에 접근하는 방법을 늘려주는 도구거든요. 폰에서 지시하다가 책상에 돌아오면 데스크톱 클라이언트가 같은 세션을 그대로 이어받습니다.

단점

먼저 눈에 띄는 건 계정·쿼터 관리 기능이 없다는 점입니다. 구독을 여러 개 두고 쓰는 사람에게는 Orca 쪽이 낫습니다. GUI 화면도 호불호는 있습니다. 깔끔하다는 사람도, 그냥 기본 수준이라는 사람도 있죠. 게다가 핸드폰 화면에서 diff를 읽는 일처럼 그 자체의 한계는 없애주지 못합니다. 그래서 정밀 리뷰에는 약합니다.

이런 상황에 추천합니다

어디서든 에이전트를 쓰고 싶은 사람에게 먼저 권합니다. 개발 서버나 VM, 홈서버에서 에이전트를 돌리고 노트북과 폰으로 확인·지시만 하고 싶은 구성에도 맞습니다. 즉, 세션 수보다 접근성이 문제인 사람, 여러 세션을 ‘한 사람이’ 이어서 관리해야 하는 사람을 위한 도구입니다.

Orca vs. Paseo vs. 순정, 어떻게 고를까

<출처: 작가, Gemini로 생성>

1단계: Orca/Paseo vs. 순정

순정, 그러니까 Claude Code나 Codex를 원래 방식대로 터미널에서 쓰는 쪽부터 봐야 합니다. 워크트리 1~2개, 하루 한두 세션에 집중하는 쪽이라면 순정이 나아 보입니다. 애초에 도구를 들여서 얻는 이득이 사실상 없고, 하네스의 새 기능을 지연 없이 받는 이점이 더 크기 때문입니다. 래퍼가 업데이트를 따라오길 기다릴 일도 없고요. 하네스 자체가 데스크톱 앱과 웹으로 나오면서 기본 편의성이 꽤 올라가기도 했고요.

그러다가 아, 도저히 이거 에이전트가 쏟아내는 텍스트를 못 따라가겠다 싶은 순간이 오면 다음 단계입니다.

2단계: Orca vs. Paseo

대략 어떤 목적이 제일 땡기는지 보는 게 좋아 보입니다.

Orca가 좋을 때

같은 작업을 여러 에이전트에 붙여 더 나은 걸 고르고 싶다
구독 계정을 여러 개 두고 엄청 오가면서 쓴다
프론트엔드 보고 고치는 일이 잦다

Paseo가 좋을 때

서로 다른 작업 여러 개를 이동 중에도 이어가고 싶다
(물론 완벽하진 않지만) 코드가 내 인프라 밖으로 나가면 안 된다

결정에 필요한 것만 담은 비교표

마치며

다행히 Orca와 Paseo 모두 무료 오픈소스이고 이미 가진 구독 계정으로 바로 쓸 수 있습니다. 일단 깔아보고 정말 이게 필요한지 봐도 괜찮습니다. 며칠 써 보고 아니다 싶으면 지우면 그만이니까요.

사실 저조차도 이 두 가지 도구가 여기저기서 인기가 좋길래 찾아보기 시작했습니다. 그러다 보니 얼른 도입해야 하나 마음이 급했는데요. 하지만 정작 알아보고 나니 왜 이 도구가 뜨는지를 보는 게 더 중요하다고 생각했습니다. 결국, ‘에이전트 감독’이라는 역할이 도구가 핫해질 만큼 필요해졌다는 겁니다. 그러니 오늘 다룬 도구 두 개는 사실 이제 시작에 가까울 겁니다. 더 많은 게 쏟아질 거라고 봅니다.

그렇다면 이런저런 도구에 휩쓸리기보다 더 중요한 건, 내가 이것들을 ‘감독해 만든 성과’를 파악하는 힘은 아닐까요?

]]>

23년 된 동네슈퍼를 데이터로 분석하기: 무엇이 팔렸나?

지난 글 ‘23년 동안 살아남은 동네슈퍼를 데이터로 분석해봤습니다’에서 제가 한 일은 단순했습니다. 기존 나들가게 POS에서 월별 매출, 거래 건수, 객단가, 현금매출과 카드매출 데이터를 크롤링하고, 이를 Supabase에 저장해 별도의 대시보드에서 볼 수 있도록 만들었습니다.

기존 POS에서도 데이터를 조회할 수는 있었습니다. 그러나 과거 데이터를 조회할 때마다 직접 하나씩 하나하나 조회해야 했고, 여러 메뉴에 정보가 흩어져 있어 전체 흐름을 한눈에 파악하기 어려웠습니다. 그래서 한 번 수집한 과거 데이터는 데이터베이스에 저장하고, 이후부터는 복잡한 POS 사이트에 다시 접속하지 않고 바로 불러오는 구조로 변경했습니다. 그 결과, POS가 처음 도입된 2011년의 매출과 2026년의 매출을 같은 화면에서 비교할 수 있는 기반이 만들어졌습니다.

이 단계까지만 해도 나름대로 의미가 있었습니다. 오래된 시스템 안에 갇혀 있던 데이터를 외부로 꺼냈고, 과거의 기록을 빠르게 탐색할 수 있게 되었기 때문입니다.

하지만 여전히 알 수 있는 것은 다음 정도였습니다.

이번 달 매출이 얼마인지
지난달보다 올랐는지 내렸는지
거래 건수가 늘었는지
객단가가 달라졌는지
현금과 카드의 비중이 어떻게 변했는지

매출이 왜 달라졌는지 알려면 결국 무엇이 팔렸는지까지 내려가야 했습니다. 이번 편에서는 프로젝트가 어디까지 확장되었는지, 그리고 데이터를 많이 모으는 것만으로는 왜 점주의 의사결정을 도울 수 없었는지를 정리해 보려고 합니다.

이번에는 ‘얼마나 팔렸는가’에서 ‘무엇이 팔렸는가’로 내려갔다

이번에 가장 먼저 추가한 것은 상품 상세 데이터였습니다.

기존에는 하루 총매출과 거래 건수만 가져왔다면, 이제는 POS의 다른 메뉴에 들어가 다음 정보까지 수집하도록 만들었습니다.

국산 담배류, 아이스크림류, 소주 등 중분류별 매출
에쎄 수, 떡붕어싸만코처럼 실제 판매된 세부 상품
상품별 판매수량과 매출액
해당 상품에서 남긴 매출이익
거래가 발생한 시간
같은 영수증에 포함된 다른 상품

<출처: 작가>

이 데이터는 월매출 달력보다 수집하기 더 어려웠습니다.

상품별 이익은 ‘일일 분류별 상품 판매 현황’에 있었고, 몇 시에 어떤 상품이 팔렸는지는 별도의 ‘상품 판매내역 조회’ 화면에 있었습니다. 결국 두 화면을 각각 크롤링한 뒤, 날짜와 상품을 기준으로 다시 연결해야 했습니다.

특히 거래 내역 화면은 하루치 영수증을 하나씩 열어 상품을 확인해야 했습니다. 어떤 날은 하루 데이터를 가져오는 데만 몇 분이 걸렸습니다. 그래서 최근 데이터만 가져오는 것으로 끝내지 않고, 과거 날짜를 하루씩 거슬러 올라가며 자동으로 수집하는 백필 과정을 만들었습니다.

월별 매출 데이터는 2011년까지 수집을 마쳤지만, 상품과 영수증 단위의 상세 데이터는 양이 훨씬 많아 아직도 수집 중입니다. 현재는 대략 2014년의 데이터까지 내려가며 차근차근 데이터베이스에 쌓고 있습니다.

그리고 이 과정을 대시보드에서 직접 확인할 수 있도록 별도의 ‘수집 현황’ 페이지도 만들었습니다.

<출처: 작가>

처음에는 단순히 오래 걸리는 작업이라고만 생각했습니다. 하지만 수집 기간이 길어질수록 어느 연도까지 정상적으로 들어왔는지, 누락된 날짜는 없는지, 달력 매출과 세부 상품 매출의 합계가 일치하는지를 확인하는 기능도 중요해졌습니다.

데이터가 많아지면 수집 자체보다 제대로 수집되었는지를 검증하는 일이 더 어려워진다는 사실도 알게 되었습니다.

데이터가 쌓이자 결국 무료 요금제를 벗어나게 됐다

처음에는 개인 프로젝트이기 때문에 Supabase 무료 요금제로도 충분할 것이라고 생각했습니다. 하지만 영수증 거래 데이터만 60만 건을 넘어섰고, 영수증에 포함된 개별 상품 행은 100만 줄 이상 쌓였습니다. 일별 상품 집계 데이터까지 더해지면서 데이터베이스 용량은 빠르게 증가했습니다.

결국 Supabase 무료 요금제에서 제공하는 500MB 한도를 넘겼습니다. 오래된 데이터를 삭제하거나, 최근 2년 정도만 보관하는 방법도 생각해 볼 수 있었습니다. 하지만 이 프로젝트를 시작한 중요한 이유 중 하나가 2011년부터 이어진 가게의 데이터를 한곳에 모으는 것이었습니다.

과거 데이터를 삭제하면 비용은 줄어들겠지만, 이 프로젝트가 가진 가장 중요한 자산도 함께 사라지게 됩니다. 결국 Supabase Pro 요금제로 업그레이드했고, 현재 매달 약 3만 8천 원 정도를 지불하고 있습니다.

개인 사이드 프로젝트에 매달 비용을 내는 것이 부담스럽지만, 10년이 넘는 실제 가게의 원장을 보존하고 분석하는 비용이라고 생각하고 유지하기로 했습니다.

데이터가 늘어나면서 대시보드의 구조도 다시 나눴다

상품과 시간대 정보가 추가되자 기존 한 화면에 모든 내용을 담기 어려워졌습니다.

그래서 상단 메뉴를 크게 다음과 같이 구분했습니다.

오늘
월별
판단
날씨

처음 화면을 열면 ‘오늘’ 탭이 나타납니다. 점주가 가게에서 가장 먼저 궁금해할 정보는 과거의 장기 추세보다 오늘 장사가 어떻게 되고 있는지이기 때문입니다.

‘오늘’ 탭에서는 현재까지의 매출, 거래 건수, 객단가, 예상 이익과 함께 오늘 판매된 주요 상품군과 세부 상품을 보여줍니다. 반면, ‘월별’ 탭에서는 한 달 동안 누적된 데이터를 기준으로 다음 내용을 확인할 수 있도록 했습니다.

일별 매출 흐름
평균적으로 매출이 높은 요일
거래가 가장 많은 시간대
중분류별 매출과 이익
세부 상품별 매출·이익·판매량 순위
현금과 카드 결제 비중

<출처: 작가>

실제로 데이터를 확인해 보니 담배, 소주, 맥주가 전체 매출에서 매우 큰 비중을 차지하고 있었습니다. 세 상품군을 합치면 매출의 절반에 가까운 기간도 있었습니다.

그런데 여기서 재미있는 점이 하나 있었습니다. 매출이 높은 날이 반드시 돈을 많이 남긴 날은 아니었습니다.

어떤 날은 음식물 쓰레기 종량제 스티커가 많이 판매되면서 매출액 자체는 높게 나타났습니다. 하지만 이 상품은 가게에 남는 이익이 거의 없기 때문에 매출 순위만 보면 좋은 날처럼 보이지만, 실제 이익 측면에서는 그렇지 않았습니다.

<출처: 작가>

이 경험을 통해 단순한 매출 순위가 점주에게 잘못된 인상을 줄 수 있다는 사실을 확인했습니다. 얼마나 많이 팔렸는가와 실제로 얼마가 남았는가는 전혀 다른 질문이었습니다.

보기 좋은 대시보드만 만들고 싶었던 것은 아니었다

사실 제가 처음부터 만들고 싶었던 것은 POS를 현대적으로 다시 디자인한 화면이 아니었습니다.

기존보다 정보를 보기 쉽게 만들고, 토스처럼 중요한 숫자가 먼저 들어오도록 UI를 구성하는 것도 필요했습니다. 하지만 그것만으로는 기존 POS를 조금 예쁘게 다시 만든 것에 불과합니다.

제가 정말 만들고 싶었던 것은 다음 구조였습니다.

Raw Data
무엇이 언제 얼마에 팔렸는가
↓  
Calculation
요일·시간·상품·이익의 관계를 코드와 공식으로 계산
↓
Decision
그래서 점주가 무엇을 확인하거나 바꿔볼 것인가

여기서 중요한 점은 계산을 LLM에 맡기지 않는 것입니다. 매출 변화율, 판매지수, 동반구매율, 상품별 마진과 같은 숫자는 SQL과 코드로 계산합니다. LLM은 이미 계산된 결과를 점주가 이해할 수 있는 문장으로 바꾸는 역할만 맡도록 했습니다.

LLM이 원본 데이터를 보고 자유롭게 판단하게 하면 그럴듯하지만 근거가 불분명한 설명을 만들 가능성이 있기 때문입니다.

그런데 첫 번째 ‘인사이트’는 별로 유의미하지 않았다

처음에는 이런 판단 카드를 만들었습니다. 13시 방문을 이익으로 전환할 기회가 있어요. 13시는 거래 건수가 많지만 객단가가 낮으므로 계산대 근처에 고마진 상품을 배치해 보라는 내용이었습니다.

처음 화면에 띄웠을 때는 꽤 그럴듯해 보였습니다. 하지만 점주의 입장에서 다시 생각해보니 별로 의미 있는 정보가 아니었습니다.

정확히 어떤 상품을 놓아야 하는지
이러한 패턴이 하루만 나타난 것인지 반복되는지
실제로 얼마나 이익이 늘어날 수 있는지
단골 한두 명의 반복 구매로 만들어진 패턴은 아닌지

어느 것도 충분히 설명하지 못했습니다. 결국 ‘데이터를 분석한 문장’처럼 보일 뿐, 실제 행동을 바꿀 만큼 구체적인 판단은 아니었습니다. 그래서 이 카드를 제거하고, 계산 계층을 다시 설계했습니다.

반복되는 패턴만 판단 후보로 올리기 시작했다

이후에는 하루의 숫자 하나를 보고 인사이트를 만들지 않도록 했습니다.

예를 들어, 특정 상품이 금요일에 많이 팔렸다고 판단하려면 다음 조건을 함께 계산합니다.

최근 8주 동안 비교 가능한 금요일이 충분히 존재하는지
8주 중 몇 주에서 같은 패턴이 반복됐는지
다른 요일보다 얼마나 많이 팔렸는지
최근 4주 동안 증가하거나 감소하고 있는지
결과를 만들 수 있는 데이터가 충분히 수집되었는지

이를 바탕으로 다음과 같은 결과를 만들고자 했습니다. 최근 8주 금요일 중 7주에서 12~14시 아이스크림 판매량이 다른 시간대보다 높았습니다. 단순히 “금요일에 아이스크림이 많이 팔립니다”라고 말하는 것보다, 표본과 반복성을 함께 보여주는 방식입니다. ‘더 준비하세요’라는 표현도 조심했습니다.

현재 데이터에는 실제 재고 수량이나 발주 단위가 없기 때문에 정확히 몇 개를 주문해야 하는지는 알 수 없습니다. 그래서 시스템에서는 ‘발주량’이 아니라, 과거 판매량의 중앙값과 최근 추세를 기준으로 목표 준비량을 보여주도록 만들었습니다.

가게의 시간을 하나의 리듬처럼 보기 시작했다

데이터가 충분히 쌓이면서 각각의 표를 나열하는 것보다, 가게의 운영 구조를 한 번에 보고 싶다는 생각이 들었습니다. 그래서 ‘판단’ 탭을 일종의 가게 디지털 트윈처럼 다시 구성했습니다. 물론 공장의 설비나 물류 흐름을 실시간으로 복제하는 거창한 디지털 트윈은 아닙니다. 이 가게에서 반복되는 시간과 상품의 구조를 데이터로 옮겨놓았다는 의미에 가깝습니다.

이 화면은 네 가지 관점으로 구성했습니다.

1) 시간대 리듬

요일과 시간을 히트맵으로 연결해, 언제 가게의 거래가 집중되는지 보여줍니다. 실제로 데이터를 확인해 보니, 요일에 관계없이 대체로 오후 5시에서 8시 사이가 가장 중요한 시간대로 나타났습니다.

단순히 피크 시간만 보여주는 것이 아니라, 오전 8~12시, 12~16시, 16~20시, 20~24시로 나누어 각 시간대에 어떤 상품과 상품 조합이 주로 판매되는지도 연결했습니다.

<출처: 작가>

2) 계절 달력

월별로 어떤 카테고리의 비중이 달라지는지 여러 해의 평균으로 계산했습니다. 아이스크림처럼 계절성이 명확한 상품뿐 아니라, 같은 계절에도 매년 반복적으로 증가하거나 감소하는 상품군을 확인할 수 있습니다.

<출처: 작가>

3) 명목 매출과 실질 성장

2011년보다 지금의 매출이 높다고 해서 가게가 실제로 더 많은 상품을 판매한다고 볼 수는 없습니다. 그동안 상품 가격 자체가 올랐기 때문입니다. 그래서 공식 소비자물가지수와는 별개로, 우리 가게에서 여러 해 동안 공통으로 판매된 상품들의 단가 변화를 이어 붙인 자체 단가 지수를 만들었습니다.

이를 통해 매출이 가격 상승 때문에 오른 것인지, 실제 거래와 상품 판매가 늘어 오른 것인지를 구분해보려 했습니다. 이 지수는 공식 물가지표가 아니라, 어디까지나 우리 가게의 판매가격을 기준으로 계산한 지표라는 점도 화면에 함께 표시했습니다.

<출처: 작가>

4) 상품의 세대교체

같은 카테고리 안에서도 시간이 지나면서 대표 상품이 바뀝니다. 과거에 많이 팔렸던 상품의 점유율이 줄어들고 새로운 상품이 이를 추월하는 시점을 찾아, 어떤 제품이 어떤 제품으로 대체됐는지 시각화했습니다.

데이터에서는 박카스 중심이던 에너지음료 수요가 몬스터 같은 새로운 상품으로 이동하는 모습도 확인할 수 있었습니다.

<출처: 작가>

과거에 무엇이 팔렸는지를 단순히 보여주는 것은 “그때는 그랬구나”에서 끝날 가능성이 큽니다. 제가 찾고 싶었던 것은 과거의 기록 자체가 아니라, 현재 상품 운영에 영향을 줄 만큼 반복되거나 구조적으로 변한 패턴이었습니다.

함께 사가는 상품도 데이터로 꺼내보았다

영수증 단위의 상품 데이터가 생기면서 어떤 상품을 함께 구매하는지도 계산할 수 있게 되었습니다. 다만 판매 건수가 많은 상품끼리는 우연히 함께 잡힐 가능성도 높습니다.

그래서 단순 동반 구매 횟수뿐 아니라, 두 상품이 각각 팔릴 확률과 비교해 실제로 함께 구매될 가능성이 몇 배 높은지를 나타내는 lift도 함께 계산했습니다.

그 결과 POS에 기록된 상품명을 그대로 기준으로 다음과 같은 조합을 발견했습니다.

[시원] 360ml 보조 상표(통합) + 카스1000L
98회 함께 판매, 일반적인 경우보다 20.5배 높은 조합
[시원] 360ml 보조 상표(통합) + 팔리아멘트 아쿠아5
53회 함께 판매, 일반적인 경우보다 22.8배 높은 조합

<출처: 작가>

부모님은 오랫동안 가게를 운영했기 때문에 어떤 상품이 함께 팔리는지 어느 정도 이미 알고 계셨을 수 있습니다. 다만 그동안은 경험과 감각으로 알고 있던 사실을 데이터상에서 정확한 횟수와 수치로 꺼낼 수 있게 되었습니다.

그렇다고 이 결과만 보고 곧바로 두 상품을 묶어 팔거나 진열을 바꾸는 것은 아닙니다. 두 상품을 함께 산 사람이 실제로 여러 명인지, 한 명의 단골이 반복해서 구매한 것인지 현재 POS 데이터만으로는 알 수 없기 때문입니다.

결국 동반 구매 분석도 정답이라기보다, 점주가 현장을 다시 살펴볼 질문의 출발점에 가깝습니다.

2011년부터의 날씨도 가게 데이터와 연결했다

이번에는 POS 밖의 데이터도 처음으로 연결했습니다. 기상청 데이터를 활용해 2011년부터 현재까지 부산의 기온, 습도, 강수량, 운량 등의 날씨 정보를 수집했습니다.

현재는 약 5,690일의 일별 날씨와 13만 건이 넘는 시간대별 관측 데이터가 쌓여 있습니다. 처음에는 같은 달과 같은 요일 안에서 날씨가 더운 날과 그렇지 않은 날을 비교했습니다. 하지만 15년 가까운 데이터가 생기자 같은 달에만 한정할 필요가 없다는 생각이 들었습니다.

작년 8월과 올해 7월이라도 기온과 습도, 강수 조건이 비슷하다면 가게의 입장에서는 충분히 비교할 수 있는 날이기 때문입니다. 그래서 현재는 강수 여부를 먼저 나누고, 기온·습도·운량이 오늘과 가장 비슷했던 과거 날짜를 전 기간에서 찾는 방식으로 변경했습니다.

그 뒤 비슷한 날들에 평소보다 더 팔렸던 상품과 덜 팔렸던 상품을 보여줍니다.

<출처: 작가>

예를 들어, 단순히 “더운 날에는 아이스크림이 잘 팔립니다”라고 보여주는 것은 큰 의미가 없습니다. 대신 다음과 같이 보여주는 것이 목표입니다. 오늘과 비슷한 날씨였던 과거 20일에서 비비빅은 하루 평균 9개, 메로나는 3.2개 더 판매됐습니다. 판매량이 0.02개에서 0.4개로 올랐다면 수치상으로는 20배지만, 실제로는 하루 0.38개 차이에 불과합니다.

그래서 배수보다 하루에 실제로 몇 개 더 팔렸는지를 기준으로 순위를 정했습니다. 다만 이것 역시 인과관계라고 단정할 수는 없습니다. 기온이 비슷한 날에 특정 상품이 함께 많이 팔렸다는 사실을 보여줄 뿐, 날씨 때문에 해당 상품이 팔렸다고 확정하는 것은 아닙니다. 계절, 요일, 상품의 출시 시점과 단종 여부 같은 다른 요인도 함께 영향을 줍니다.

따라서 날씨 탭도 현재는 정답을 알려주는 기능이라기보다, 내일 무엇을 조금 더 준비해 볼지 판단할 근거를 제공하는 단계에 있습니다.

LLM은 계산하지 않고, 계산된 결과만 설명하게 했다

분석 결과를 점주가 읽기 쉬운 문장으로 바꾸기 위해 LLM API도 연결했습니다. 하지만 LLM이 매출 원장을 직접 보고 계산하거나, 자유롭게 상품 운영 방법을 추천하도록 하지는 않았습니다.

역할을 다음과 같이 분리했습니다.

SQL과 코드
판매량·마진·반복성·동반구매·날씨 효과를 계산

LLM
계산된 수치와 한계를 사람이 이해하기 쉬운 문장으로 정리

LLM이 실패하거나 API를 사용할 수 없는 경우에도 판단 기능이 멈추지 않도록, 같은 내용을 정해진 문장으로 출력하는 템플릿도 함께 만들었습니다. 결국 이 시스템에서 LLM은 판단을 만들어내는 두뇌라기보다, 이미 계산된 결과를 점주의 언어로 번역하는 인터페이스에 가깝습니다.

기능을 추가할수록 서비스는 느려졌다

이번 프로젝트를 하면서 개발자분들이 새삼 대단하다고 느낀 순간도 많았습니다. 이 서비스는 사실상 한 사람, 많아야 가족 몇 명이 사용하는 개인용 서비스입니다. 대규모 트래픽이 발생하지도 않고, 수많은 사용자가 동시에 요청을 보내지도 않습니다.

그런데도 상품 데이터, 판단 탭, 날씨 데이터처럼 기능을 하나씩 추가할 때마다 탭 이동이 느려지고 로딩 시간이 길어졌습니다. 과거 데이터를 매번 다시 계산하면 화면을 열 때 오래 기다려야 했고, 백필 작업이 브라우저를 사용하고 있으면 오늘 데이터를 수집하는 작업이 밀리기도 했습니다.

이를 해결하기 위해 다음과 같은 방법을 계속 추가했습니다.

변하지 않는 과거 데이터는 데이터베이스에서 즉시 조회
무거운 분석은 사용자가 접속했을 때가 아니라 야간에 미리 계산
계산 결과는 스냅샷 형태로 저장
사용자가 새로고침하면 과거 백필 작업이 브라우저를 양보
한 번 계산한 값은 캐시에 저장
누락되거나 합계가 맞지 않는 날짜는 별도로 탐지해 재수집

혼자 사용하는 서비스에서도 이 정도의 고민이 생겼습니다. 그렇다면 토스처럼 수많은 사용자가 동시에 접속하고, 계속 새로운 기능이 추가되는 서비스에서 백엔드 개발자분들은 얼마나 많은 통신 방식과 캐싱, 동시성, 데이터 정합성 문제를 고민하고 있을까 하는 생각이 들었습니다.

화면에서는 버튼을 한 번 누르면 바로 다음 정보가 나오지만, 그 자연스러운 경험 뒤에 얼마나 많은 최적화가 숨어 있는지 조금이나마 체감할 수 있었습니다.

바이브 코딩에도 기억을 보존하는 장치가 필요했다

기능이 많아지면서 또 다른 문제가 발생했습니다. Claude나 Codex를 이용해 바이브 코딩을 하다 보면, 새로운 터미널과 새로운 대화창에서 작업을 시작하게 됩니다. 그러면 이전 대화에서 왜 특정 구조를 선택했는지, 어떤 오류 때문에 방어 로직을 추가했는지가 사라집니다.

새로운 AI는 현재 코드만 보고 다음과 같이 판단할 수 있습니다. 이 부분은 복잡해 보이니 제거해도 되겠습니다. 하지만 실제로는 과거에 발생했던 데이터 오염이나 삭제를 막기 위해 일부러 복잡하게 만들어둔 코드일 수 있습니다.

실제로 프로젝트에서는 같은 날 같은 이름을 가진 다른 상품이 한 번에 들어오면서 저장 배치 전체가 실패한 적도 있었습니다. 그 문제로 1,000일이 넘는 상품 데이터가 정상적으로 저장되지 않았고, 백필 작업도 과거로 내려가지 못한 채 같은 구간을 반복하고 있었습니다.

또 수집이 2014년에서 멈춘 이유를 처음에는 데이터베이스 용량이나 POS 보관기간 때문이라고 의심했지만, 실제로는 앞선 저장 오류로 미완료 날짜가 쌓여 과거 날짜까지 내려가지 못한 것이 원인이었습니다.

이런 맥락을 모르는 AI가 코드를 단순화하면 이미 해결한 문제가 다시 발생할 수 있었습니다.

그래서 SSOT.md라는 문서를 만들었습니다.

<출처: 작가>

SSOT는 Single Source of Truth, 즉 하나의 기준이 되는 문서라는 의미입니다.

이 문서에는 다음 내용을 계속 기록했습니다.

프로젝트가 어떤 문제를 해결하는지
현재 데이터베이스 구조
각 파일이 맡는 역할
왜 특정 구조를 선택했는지
과거에 발생한 장애와 실제 원인
제거하거나 변경하면 안 되는 로직
현재 진행 중인 작업과 다음 단계

AI에 새로운 작업을 맡길 때도 먼저 이 문서를 읽도록 했고, 중요한 구조를 변경하면 코드와 함께 SSOT도 갱신하도록 했습니다. 바이브 코딩은 코드를 빠르게 만드는 데에는 매우 유용합니다.

하지만 프로젝트가 길어질수록 중요한 것은 코드를 빨리 생성하는 능력보다, 왜 이런 코드가 존재하는지를 잊지 않는 능력이라는 사실도 알게 되었습니다.

동네 슈퍼 데이터는 편의점 데이터와 다르다

이 프로젝트에서 계속 경계하고 있는 부분도 있습니다. 우리 가게는 불특정 다수가 끊임없이 방문하는 대형 매장이나 프랜차이즈 편의점이 아닙니다. 주변에 거주하는 단골손님과 매일 담배나 술을 사러 오는 고객의 비중이 높습니다.

따라서 특정 상품 조합이 많이 나타났다고 해서 많은 고객이 공통으로 선호한다고 단정할 수 없습니다. 한 명의 단골이 같은 조합을 반복해서 구매했기 때문에 만들어진 결과일 수도 있습니다. 고객 ID가 없는 POS 데이터만으로는 이를 완전히 구분하기 어렵습니다.

예를 들어, 데이터를 분석하니 월요일에는 캔커피가 평소보다 약 2.3배 많이 팔리는 패턴이 나타났습니다. 하지만 이 수치만 보고 월요일마다 캔커피를 두 배로 발주하는 것은 위험합니다.

먼저 현장에서 다음 질문을 해봐야 합니다.

월요일마다 특정 단골이 대량으로 구매하는 것은 아닌가?
주변 사업장의 근무 일정과 관련이 있는가?
특정 납품이나 작업 일정이 월요일에 몰려 있는가?
실제로 진열 위치를 바꾸면 추가 판매로 이어질 수 있는가?

이 시스템이 해야 할 일은 “월요일에는 캔커피를 더 주문하세요”라고 정답을 말하는 것이 아닐 수 있습니다. 오히려 부모님이 오랜 경험 속에서 놓치고 있던 패턴을 꺼내 다음과 같은 질문을 던지는 것이 더 중요할 수 있습니다.

월요일에 캔커피가 반복적으로 더 팔리는 이유가 무엇일까?
이 패턴을 이용해 함께 판매할 상품이나 준비 방식을 바꿔볼 수 있을까?

필요한 데이터는 거의 모았지만 진짜 어려운 문제가 남았다

처음에는 POS 데이터를 가져오는 것 자체가 가장 어려운 문제라고 생각했습니다. 엑셀 다운로드도 제대로 지원하지 않는 오래된 사이트에서 데이터를 크롤링하고, 2011년부터의 기록을 데이터베이스에 저장하는 일이 가장 큰 과제처럼 보였습니다.

그런데 지금은 생각이 달라졌습니다. 데이터를 모으는 것은 어렵지만, 언젠가는 끝납니다. 진짜 어려운 문제는 그다음입니다. 수집한 데이터를 어떤 기준으로 연결하고, 어떤 차이를 의미 있는 변화로 판단하며, 어떤 결과만 점주에게 보여줄 것인가.

수많은 숫자를 보여주는 것은 쉽습니다. 그러나 그중 실제로 부모님의 다음 행동을 바꿀 만한 신호를 찾아내는 것은 전혀 다른 문제입니다. 현재 시스템은 과거와 비슷한 날, 특정 요일과 시간대의 평균, 함께 팔린 상품, 날씨 조건에 따른 판매 차이를 보여줄 수 있는 단계까지 왔습니다. 하지만 아직은 대부분 관찰과 비교에 가깝습니다.

앞으로는 여기서 한 단계 더 나아가고 싶습니다.

어떤 패턴이 우연이 아니라 반복되는지
어떤 상품은 늘리고 어떤 상품은 줄여볼지
진열 위치를 바꾸면 실제 이익이 늘어나는지
추천한 행동을 실행한 뒤 결과가 어떻게 달라졌는지
부모님의 현장 경험과 데이터가 서로 충돌할 때 무엇을 다시 확인할지

결국 제가 만들고 싶은 것은 가게 운영의 정답을 대신 내려주는 AI가 아닙니다. 점주가 그냥 지나쳤을 수 있는 변화를 발견하고, 무엇을 확인하고 시험해 볼지 더 정확한 출발점을 제시하는 시스템입니다.

23년 동안 가게를 운영해 온 부모님의 경험을 데이터로 대체하는 것이 아니라, 그 경험이 새로운 질문을 만날 수 있도록 돕는 것. 그것이 이 프로젝트가 다음 단계에서 풀고 싶은 문제입니다.

<원문>

23년 동안 살아남은 동네슈퍼를 데이터로 분석해보려 합니다. (3편)

]]>

이제 클로드가 만든 글엔 눈에 안 보이는 워터마크가 붙습니다

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

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

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

써볼 것: Hallmark - AI가 만든 티 안 나는 디자인을 만들어주는 도구
참고할 것: Grok Bot - 자기 컴퓨터를 갖고 스스로 일하는 AI 동료
적용해볼 것: AI가 만든 콘텐츠에 표시가 붙기 시작합니다

<출처: Nutlope/hallmark, GitHub>

1. 써볼 것: Hallmark, AI가 만든 티 안 나는 디자인을 만들어주는 도구

AI에게 웹페이지나 화면을 만들라고 하면, 되긴 되는데 어딘가 AI가 만든 티가 나죠. 비슷비슷한 레이아웃에, 가운데 정렬된 제목에, 보라색 그라데이션까지. Hallmark는 이 AI가 만든 티(개발자들은 AI 슬롭이라고 불러요)를 걷어내주는 도구입니다. Together AI가 만들었고, 깃허브 스타 2만 4천 개를 넘기며 주목받고 있어요.

Hallmark는 AI 코딩 도구에 붙여 쓰는 스킬입니다. 클로드 코드, 커서, 코덱스에 설치해두면, AI가 화면을 만들 때 좋은 디자인 원칙을 따르도록 잡아줘요. 타이포그래피, 색, 여백, 모션 같은 걸 65가지 기준으로 점검해서, 흔한 AI 기본값을 벗어난 결과를 내놓습니다.

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

AI로 만든 화면이 밋밋한 건, AI가 학습한 가장 무난한 평균값을 내놓기 때문이에요. 그래서 다들 비슷한 결과가 나오죠. Hallmark는 여기에 구체적인 취향과 규칙을 심어줍니다. 예를 들어 깔끔하고 모던하게 같은 두루뭉술한 지시는 거부하고, 에디토리얼, 브루탈리즘, 럭셔리처럼 뚜렷한 방향을 하나 고르게 해요. 제목을 무조건 가운데 두거나, 아무 데나 그라데이션을 넣는 것 같은 흔한 AI 디자인 습관도 걸러내고요.

어떻게 쓰나요?

터미널에서 npx skills add nutlope/hallmark를 실행하면 설치됩니다. 그다음부터는 클로드 코드나 커서에서 화면을 만들 때 Hallmark 규칙이 적용돼요. 무료로 쓸 수 있고(MIT 라이선스), 네 가지 방식으로 활용할 수 있습니다.

새로 만들기: 그냥 화면을 만들어달라고 하면, Hallmark가 방향을 잡아 디자인합니다.
audit(진단): 이미 있는 화면 코드를 넣으면, AI 티 나는 부분을 짚어줍니다. 고치진 않고 목록만 뽑아줘요.
redesign(재설계): 기존 화면의 내용은 두고, 구조와 겉모습만 새로 바꿔줍니다.
study(분석): 이게 Hallmark의 특징인데, 내가 좋아하는 디자인의 스크린샷이나 주소(URL)를 주면, 그 디자인의 특징(글꼴 느낌, 색, 구조)을 뽑아냅니다. 그대로 베끼는 게 아니라 분위기만 추출해서 내 화면에 적용해주는 거예요.

한 가지, study 기능에는 좋다고 느낀 점이 있습니다. 남의 것을 함부로 베끼지 않도록 선을 그어뒀다는 점인데요. 유료 템플릿이나 경쟁사 페이지는 분석을 거부하고, 픽셀을 그대로 복제하지도 않습니다. 내가 참고할 만한 공개된 디자인의 느낌만 가져오는 용도라, 이런 장치가 있다는 게 마음에 듭니다.

누구에게 좋을까요?

AI로 화면을 만드는데 결과가 밋밋해서 아쉬웠던 사람. 디자인 완성도를 한 단계 올려줍니다.
디자인을 전문으로 배우지 않은 1인 개발자나 기획자. 좋은 디자인 규칙을 빌려 쓸 수 있어요.
참고하고 싶은 사이트가 있는 사람. study로 그 느낌을 분석해 내 작업에 녹일 수 있습니다.
반대로 이미 탄탄한 디자인 시스템이 있다면 굳이 필요하진 않아요. 이건 AI에게 디자인 감각을 빌려주고 싶을 때 쓸모가 큰 도구입니다.

<출처: SpaceXAI, Grok Bot>

2. 참고할 것: Grok Bot, 사람처럼 앱에 로그인해 일하는 AI 에이전트

지난 몇 주 동안 AI 에이전트가 스스로 나서서 문제를 일으킨 사건들을 다뤘는데요. 이번엔 아예 그런 에이전트를 제품으로 내놓은 곳이 나왔습니다. SpaceXAI(일론 머스크의 AI 회사, 옛 xAI)가 커서와 함께 8월 11일 공개한 Grok Bot입니다.

Grok Bot의 콘셉트는 자기 컴퓨터를 가진 AI 동료예요. 기존 AI 비서와 다른 점은, 이 봇이 클라우드에 자기만의 컴퓨터를 갖고 있어서 사용자의 앱과 웹사이트에 직접 로그인해 사람처럼 쓴다는 겁니다. 일을 맡기면 처음부터 끝까지 진행하고, 승인이 필요할 때만 돌아와요. 여러 봇을 만들어 병렬로 굴릴 수도 있고, 봇끼리 일을 주고받게 할 수도 있습니다.

무엇을 할 수 있나요?

SpaceXAI에 따르면 Grok Bot은 팀 동료에게 일을 넘기듯 쓸 수 있습니다. 영업 대상을 조사해 이메일 초안을 쓰거나, 지원 문의에 답하거나, 경비를 처리하는 식이에요. 한 번 워크플로를 보여주면 그걸 기억했다가 다음엔 알아서 반복하고요.

실제로 써본 사람들의 반응을 보면 콘셉트에는 대체로 감탄하는 분위기입니다. 한 개발자는 리서처 봇과 작가 봇을 만들고 이 둘을 지휘하는 봇을 붙여 협업시켰더니 당연히 안 될 줄 알았는데 바로 되더라고 평했어요. 셋업이 거의 필요 없다는 점(워크플로를 그려 넣을 필요 없이 바로 일을 맡긴다)도 강점으로 꼽힙니다.

물론 아직 베타라 조심스러운 평가도 많습니다. 개념은 강력하지만 고객 데이터나 결제, 중요한 결정을 맡기기엔 이르다는 반응이 공통적입니다. 워크플로를 한 번 보여주면 배운다는 기능도, 만든 회사 스스로 그렇게 학습한 건 초안일 뿐이라 사람이 결정 규칙과 예외 처리를 더해야 한다고 밝히고 있고요.

알아두면 좋은 것

Grok Bot에는 눈여겨볼 배경이 두 가지 있습니다.

하나는 커서와의 관계입니다. Grok Bot은 다운로드도 결제도 전부 커서를 통해 이뤄져요. 접근도 SuperGrok Heavy, Cursor Ultra, Cursor Teams Premium 같은 특정 구독자(월 120~200달러)로 한정돼 있고요. 이건 SpaceX가 커서를 만든 회사(Anysphere)를 600억 달러에 인수하기로 한 것과 이어집니다. 아직 인수가 공식 완료되진 않았지만, Grok Bot은 두 회사가 합쳐지며 나온 첫 제품인 셈이에요.

다른 하나는 최근 나온 Grok 4.6입니다. SpaceXAI는 8월 12일 Grok 4.6을 내놨는데, 모델 크기를 키우기보다 긴 작업을 놓치지 않고 해내는 능력과 코딩에 초점을 맞춘 버전이에요. Grok Bot처럼 오래 이어지는 에이전트 작업에 쓰라고 만든 모델이고, 커서와 Grok Bot에서 함께 쓸 수 있습니다. SpaceXAI 발표 기준으로는 성능이 경쟁 모델과 비슷한 수준이라는데, 독립적인 검증은 아직 나오는 중이라 참고만 하면 됩니다.

무엇을 얻어가야 하나요?

Grok Bot이 흥미로운 건, AI를 쓰는 방식이 달라지는 걸 보여주기 때문이에요. 지금까지 AI는 물어보면 답하는 쪽이었는데, 이제는 일을 맡겨두면 알아서 해오는 쪽으로 바뀌고 있습니다.

다만 여기엔 지난 회차들에서 짚은 문제가 똑같이 걸려 있어요. 자기 컴퓨터를 갖고 내 앱에 로그인하는 에이전트는, 그만큼 실제로 할 수 있는 일도 많아져요. 실사용자들이 입을 모아 아직은 감독이 필요하다고 하는 것도 이 때문이죠. 그러니 이런 도구를 쓸 때는 무엇을 맡길지와 무엇을 직접 확인할지를 나눠두는 게 중요합니다. 중요한 작업일수록 봇이 끝냈다고 바로 넘기지 말고, 사람이 한 번 확인하는 단계를 두는 거죠.

<출처: Anthropic, How Claude marks AI-generated content>

3. 적용해볼 것: Claude가 만든 콘텐츠에 워터마크가 붙기 시작합니다

앞으로 AI가 만든 글과 파일에는 AI가 만들었다는 표시가 붙습니다. 앤트로픽이 8월 초 이 계획을 공식적으로 밝혔는데요. 유럽연합의 AI법(EU AI Act)이 AI로 만든 콘텐츠에 표시를 남기도록 요구했고, 앤트로픽이 여기에 동참하며 구체적인 방법을 내놓았습니다. 이는 내가 클로드로 쓴 글이나 만든 이미지에 눈에 보이지 않는 표시가 들어간다는 뜻이라, AI로 콘텐츠를 만드는 사람이라면 참고해둘 내용입니다.

어떻게 표시되나요?

앤트로픽에 따르면 표시 방식은 두 가지입니다.

하나는 텍스트에 새겨지는 워터마크예요. 클로드가 쓴 글에 사람 눈엔 안 보이는 표시를 심는데, 글의 의미나 읽는 느낌은 그대로입니다. 복사해서 다른 곳에 붙여도 따라가고, 어느 정도 편집에도 남습니다.
다른 하나는 파일에 붙는 출처 정보입니다. 클로드가 이미지 같은 파일을 만들면, 이 파일이 클로드를 거쳤다는 정보를 파일 안에 서명해서 넣습니다. C2PA라는 업계 공통 표준을 쓰는데, 이걸로 파일이 중간에 변조됐는지도 확인할 수 있습니다.

적용 범위는 꽤나 넓은데요. 클로드를 쓰는 거의 모든 곳(웹, API, 클로드 코드 등)과 전 세계에 적용되고, 2026년 8월 2일 이후 나온 최신 모델부터 우선 적용됩니다. 그 이전 모델도 표시를 붙이는 작업을 하는 중이고요.

여기서 꼭 알아둘 한계

표시가 붙는다고 해서 모든 게 명확해지는 건 아닙니다. 앤트로픽도 관련한 한계를 분명히 밝혔는데, 실무에선 이 부분이 더 중요할 것 같습니다.

먼저, 표시가 있다고 클로드가 그 내용을 만들었다는 뜻은 아닙니다. 사람들은 클로드로 남의 글을 교정하거나 번역하거나 요약도 하잖아요. 그럴 때도 표시가 붙습니다. 그러니 표시가 있다는 건 이 콘텐츠가 클로드를 거쳤다 정도지, 클로드가 처음부터 모든 걸 작성했다는 증거는 아닙니다.

반대로, 표시가 없다고 AI가 안 만든 것도 아니에요. 글이 아주 짧거나, 많이 고쳐 썼거나, 번역을 거치거나, 스크린샷으로 캡처하거나, 파일 형식을 바꾸면 표시가 사라질 수 있거든요.

무엇을 적용하면 될까요?

내가 만든 결과물이 클로드를 거쳤다는 게 표시로 남을 수 있다는 걸 알아두세요. 특히 다른 사람 이름으로 나가는 글이나, 원작자가 따로 있는 작업이라면 이 점을 염두에 두면 좋습니다.
표시를 진위 판별 도구로 맹신하진 마세요. 표시가 있다고 AI가 다 지어낸 것도, 없다고 사람이 다 쓴 것도 아닙니다. 앞으로 이런 표시가 여러 AI 회사로 퍼질 텐데, 그 신호는 참고 자료지 결론이 아니라는 걸 기억해두면 됩니다.
AI로 만든 걸 서비스에 쓴다면, 앞으로 이런 표시와 관련한 규정이 나라마다 생길 수 있다는 걸 미리 알아두세요. 지금은 유럽이 앞서 있지만, 이런 흐름은 대개 번져갑니다.

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

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

AI 챗봇이 있어도 왜 콜센터 전화는 줄지 않을까?

이미 AI 챗봇 서비스는 많은 회사가 도입했고, 일상에서도 흔하게 접하는 소통 수단이 됐습니다. 그러다 보니 AI 챗봇을 개발하는 기술 또한 빠르게 진화하고 있죠.

실제로 저는 월 수백만 트래픽을 가진 커머스에 AI 챗봇 서비스를 오픈했고, 1년 넘게 운영하고 있습니다. AI 챗봇 서비스 오픈 이후 사용자가 폭발적으로 늘었고, 안정적인 서비스 안착에도 성공했습니다. 매월 이용자도 눈에 띄게 늘어났죠.

결과적으로 오픈 초기 대비 300% 이상 성장하는 눈부신 성과를 거두었습니다. 그러다 보니 상담 운영 비용도 드라마틱하게 줄어들 것이라는 기대감이 생겼죠. 그런데 1년 넘게 운영하면서, 실제로 마주한 결과는 전혀 달랐습니다. 챗봇 이용자 수는 계속 늘고 온갖 정보들을 물어보는데, 실제 콜센터의 문의 비율은 감소하지 않았습니다.

왜 정작 콜센터 문의는 큰 감소가 없었을까요? 기술은 유례없이 화려해졌고, 트래픽은 300%나 폭증했는데, 왜 현장의 역설은 더 깊어만 갈까요? 이 역설을 이해하지 못하면, 사용자들은 우리가 고생해서 만든 AI 챗봇을 누르지 않고 이탈할 겁니다. 이건 AI 챗봇 개발의 문제가 아닙니다. 아마도 AI 챗봇을 도입한 많은 회사들이 마주했거나, 마주하게 될 현실일 겁니다.

미리 요점만 콕 집어보기

지표의 역설: 월 수백만 트래픽의 커머스 서비스에서 AI 챗봇 도입 후 사용자가 초기 대비 300% 이상 급증하며 안정적인 안착에 성공했지만, 정작 콜센터의 인바운드 문의건은 큰 감소가 없는 묘한 괴리감은 무엇일까요?
답답함의 두 가지 결: 사용자가 느끼는 AI 챗봇의 답답함은 ‘환불처럼 직접 처리를 못 해주는 완결성의 한계’와 ‘사람의 질문 속 미세한 숨은 맥락을 이해하지 못하는 한계’라는 두 갈래에서 터져 나옵니다.
진정한 해법: AI 챗봇이 권한 한계에 부딪히는 순간 대화 맥락을 상담사에게 자연스럽게 연결(Hand-over)하고, 숨은 맥락을 온톨로지 기반 지식 그래프로 풀어내는 과정에 집중해야 합니다.

<출처: 작가, AI로 생성>

사용자들이 조용히 X 버튼을 누르는 진짜 이유

멀티 에이전트 구조에 RAG, 지식 그래프 등 AI 개발 기술을 총동원하고, 지속적으로 개선 업데이트한다면 웬만한 질문엔 막힘없이 답변할 겁니다. 하지만 콜센터 문의 비율 관점에서 보면, 사용자들은 여전히 AI 챗봇에 만족하지 못합니다. 챗봇이 대답을 잘 해도, 왜 사용자들은 답답하다고 느낄까요? 많은 회사들이 놓치는 지점이 바로 여기에 있습니다.

1) ‘완결성’의 한계: 요청을 끝까지 처리하지 못하는 에이전트

AI 에이전트는 ‘텍스트로 정해진 매뉴얼을 보여주는 일’은 기가 막히게 잘합니다. 예를 들어, “아이디나 비밀번호를 찾는 절차가 어떻게 되나요?” 같은 단순 질문에는 단 몇 초 만에 완벽한 가이드를 알려줍니다.

문제는 사용자들이 진짜 해결하고 싶은 건 대개 일차원적이지 않다는 데 있습니다. “지난달에 정기 구독 해지 신청을 분명히 했는데, 이번 달에 또 이중 청구가 됐습니다. 환불해 주세요.” 같은 복합적인 맥락이 얽힌 요청들이 많습니다. 또 대부분은 AI 에이전트에 이러한 결제/취소 및 민감한 기능에 대한 처리 권한을 주지 않습니다. 그래서 “마이페이지 > 결제 내역에서 신청해 주세요”라는 안내만 되풀이할 수밖에 없는 게 현실입니다.

즉, 사용자는 요청에 대해 완결성 있는 마무리를 원하지만, 실제 AI 챗봇의 권한상 일을 끝맺기 어려운 게 현실입니다. 이런 상황이 반복되면 사용자들은 답답함과 짜증이 밀려오죠. 그리고 조용히 대화창의 닫기 버튼을 누르고, 콜센터에 전화를 겁니다.

결국 AI가 직접 해결할 수 없는 권한의 한계에 도달했을 때, 얼마나 매끄럽게 사람에게 맥락을 넘겨주느냐(Hand-over)가 핵심 포인트 입니다.사실 최악의 경험은 AI 챗봇과 한참 대화하다 콜센터로 연결되었을 때, 상담사가 “고객님 어떤 문제가 있으신가요?” 하고 처음부터 다시 물어보는 순간입니다.

즉, AI 챗봇의 목표는 ‘무조건 내가 대답해서 고객 질문을 방어하기’가 아니라, ‘내가 못 하는 순간 사용자의 수고를 최소화하며 사람에게 넘겨주기’로 바뀌어야 합니다.

특히 AI 챗봇이 답변에 실패하거나, 사용자가 반복해서 부정적 반응을 보일 때 억지로 대화를 이어가지 않고 바로 ‘상담사 연결 버튼’을 띄워야 합니다. 그리고 상담사 연결을 누르는 즉시, AI 챗봇과 나누었던 대화 요약본과 AI가 확인할 수 있는 API를 호출해, 확인된 사용자의 상황을 상담사 모니터에 실시간 보여줘야 합니다.

그래야 상담사가 연결된 후, “고객님, 조금 전 이중 청구 건으로 당황하셨죠? 대화 기록 확인했으니 제가 바로 환불 처리 도와드릴게요.”라고 대응할 수 있고, 이것이 바로 처리 권한의 한계를 극복하는 가장 자연스러운 흐름입니다.

사람이 처리해야 하는 건은 사람이 나서야 합니다. 괜히 모든 것을 AI로 대응하려고 하면, 좋은 성과로 이어갈 수 없습니다. 사용자들이 끝내 사람을 찾는 이유는 기계 시스템이 채울 수 없는 세 가지 공백 때문인데요. 바로 신뢰, 보안, 책임에 있습니다. 이 부분을 간과해서는 안 됩니다.

돈이 걸려 있거나, 본인의 민감한 개인정보를 다뤄야 하는 고위험 비즈니스 사안일수록, 사용자들은 AI의 그럴듯한 답변보다 “제가 책임지고 이 부분 확실하게 처리해 드리겠습니다.”라는 사람의 음성에 신뢰를 가집니다. 즉, 핸드오버 과정에서 위험도와 복잡성에 따라, AI와 사람간 역할을 정교하게 나누는 하이브리드 협업 구조가 필요하죠.

<출처: 작가, AI로 생성>

자동화 영역: 단순 정보 조회, 예약 변경, 주소지 변경처럼 절차가 명확하고, 리스크가 낮은 정형 문의는 인공지능 에이전트가 24시간 완전 자율형으로 신속하게 처리하는 구조입니다.
협업 영역: 난이도가 조금 있는 문의는 AI가 실시간으로 사용자의 맥락을 분석해 상담사에게 최적의 답변 초안과 가이드를 제안하고, 최종 판단과 커뮤니케이션은 상담사의 재량과 유연성에 맡겨 진행합니다.
사람 전담 영역: 심각한 브랜드 클레임, 복잡한 법적 사안, 극도로 소진된 감정 케어가 필요한 위기 순간에는 AI를 대신 숙련된 전문 상담사가 전면에 나서서 신뢰를 완성해야 합니다.

2) ‘숨은 맥락’의 한계: 온톨로지 기반 지식 그래프의 필요성

또 다른 한계는 사람의 글 안에 숨어 있는 맥락 이해의 한계입니다. 최근 AI 에이전트를 고도화하며, 가장 치열하게 들여다보는 지점은 기술의 화려함보단, 고객 맥락을 다루는 시스템의 정교함과 안정성입니다.

최근 고객들의 탐색 패턴은 키워드 검색에서, 자연어 기반의 추상적인 질의로 급격히 바뀌었습니다. 고객은 이제 조건이 완벽히 정리되지 않은 상태로 AI에 질문을 던집니다. 문제는 자연어 속 숨은 프롬프트(Prompt)와 제약 조건을 엔지니어링 관점에서 어떻게 해결하느냐입니다.

예를 들어, “아이와 함께 갈 만한 휴양지 추천해 주세요.”라는 한 문장 뒤에는, 유모차가 다닐 수 있는 평지 동선, 키즈 전용 시설, 응급실 접근성 같은 디테일한 제약 조건들이 숨어있죠. 질문 속 숨은 맥락을 짚어내지 못하고, 비슷한 답변만 반복하는 AI에 사용자는 더 이상 대화를 이어갈 이유를 찾지 못합니다. 가차 없이 대화창을 닫아버리죠.

단순히 AI 챗봇에게 “더 똑똑하게 대답해 봐”라고 요구하는 건 무리입니다. 단순히 질문의 의미만 파악해서는 부족합니다. 사용자가 최근 앱에서 검색한 기록, 과거의 예약 이력, 그리고 아이 관련 문의 내역까지 유기적으로 엮어내야 합니다. 이런 파편화된 정보들이 하나의 맥락으로 연결될 때, AI는 비로소 ‘아이와 함께라면 유모차 이동이 쉽고, 응급실이 가까운 곳이 좋겠네요.’라는 같은 제안을 건넬 수 있습니다. 이게 바로 우리가 기대하는 진짜 대화의 모습입니다. 기술적으로 보면, 이런 유기적 연결성을 강화 하기 위해서는 단순 RAG(문서 검색)를 넘어 지식 그래프(Knowledge Graph)와 온톨로지(Ontology) 기반의 하이브리드 검색 레이어가 필수적이고요.

온톨로지(Ontology): 데이터의 개념 체계와 관계 규칙(Schema)입니다. 예를 들어, “아이 동반”이라는 개념은 “평지 동선”, “키즈 시설”, “응급실 거리”라는 제약 조건과 연결되어야 한다는 관계 규칙 설계도입니다.
지식 그래프(Knowledge Graph): 그 온톨로지라는 뼈대 위에 실제 데이터(인스턴스)를 노드(Node)와 간선(Edge)으로 연결해 구축한 실체입니다. 예를 들어, “A 리조트(노드) - [갖추고 있다] ➔ 키즈 클럽(노드)”, “A 리조트 - [거리] ➔ B 병원 응급실 10분(노드)”이라는 실제 데이터 그래프입니다.

사용자가 “아이와 갈 휴양지”라고 툭 던졌을 때, 지식 그래프가 ‘아이 동반’에 연결된 필수 제약 조건 노드들을 탐색해 프롬프트에 자동으로 주입합니다. 이 엔지니어링이 밑바탕에 깔려야만, 비로소 AI가 사용자의 숨은 의도와 맥락을 정확히 파악해 답변할 수 있습니다.

3) 기업과 사용자 사이의 목적 불일치

결국 본질을 들여다보면, 기업과 사용자 사이의 심각한 ‘목적 불일치’가 있습니다. 기업은 효율성과 비용 절감이라는 내부 지표에 매몰되어, ‘얼마나 많은 문의를 AI 챗봇 단계에서 답변(방어)했는가’를 성공의 기준으로 삼기 쉽습니다. 사용자의 니즈의 완결성이 아니라, 질문에 답변을 했는가에 집중하는 거죠. 물론 AI 챗봇은 오류가 아니라면, 정해진 대로 기준에 따라 답을 했을 겁니다. 그런데 앞에서도 이야기했지만, 단순히 답변만 했다고 해서 사용자의 니즈가 해소되는 건 아닙니다.

사용자의 목적은 단 하나, “귀찮고 복잡한 문제를 얼마나 적은 수고로 해결할 수 있는가”이기 때문입니다.

이 간극을 메우지 못한 채 서비스 도입을 강행하는 건, 냉정하게 말해 기업이 스스로 감당해야 할 업무와 수고를 사용자에게 은근슬쩍 떠넘기는 것밖에 안 됩니다. 원하는 답을 찾기 위해 사용자가 필터 메뉴를 이리저리 누르고, 질문을 바꾸는 일을 직접 하게 만들기 때문입니다. 그렇게 기계적인 응대에 지친 사용자의 문의는 콜센터에 연결되는 순간, 분노가 결합한 고난도 클레임으로 변질되곤 합니다. 결국 상담사의 감정 노동과 평균 처리 시간(AHT)이 오히려 폭증하는 부메랑으로 돌아오죠.

성패는 ‘사용자의 노력을 얼마나 줄였는가’에 있다

그렇다면 프로덕트 팀은 여기서 어떤 시사점을 얻고, 관점을 전환해야 할까요? 많은 조직이 “챗봇 기능을 더 고도화하자.”라며 성능을 올리는 데 집중합니다. 하지만, 핵심은 챗봇 대화 창 안의 프롬프트 몇 줄이나 단일 기능 스펙을 고도화하는 데 있지 않습니다. 고객 문제 해결 여정 전체를 지원할 수 있는 체계로 확장해야 합니다.

트래픽이 300%나 늘어났어도 콜센터 문의량은 그대로였던 진짜 원인은, 챗봇이 해결하지 못한 문제가 다음 단계로 이어지지 못하고, ‘단순 챗봇 응대 처리율’이라는 단편적인 지표 뒤에 숨어있었기 때문입니다.

프로덕트 팀이 가져야 할 관점의 전환은 명확합니다.

지표의 패러다임 전환 (자동 처리율 ➔ 여정 완료율): “챗봇이 얼마나 많은 문의에 답변했는가”라는 공급자 중심 지표를 버려야 합니다. 챗봇 대화부터 사람 상담 연결까지 포함해, 고객이 자신의 문제를 완결짓는 데 걸린 총 시간과 수고가 얼마나 줄었는가를 핵심 지표(KPI)로 삼아야 합니다.
시스템 인프라의 전환 (단일 대화창 ➔ 여정 파이프라인): 앞서 살펴본 것처럼, 온톨로지 기반 지식 그래프로 고객의 숨은 맥락을 정교하게 읽어내고, AI의 한계 지점에서는 대화 요약 및 맥락을 동기화해 사람에게 매끄럽게 넘기는 [맥락 추론 ➔ 오케스트레이션 ➔ 핸드오버] 전체 파이프라인을 구축해야 합니다.

결국 AI 기술의 화려함보다 중요한 것은 ‘고객의 노력을 얼마나 줄여주었는가’입니다. 챗봇이 못 하는 일은 솔직하게 인정하고, 다음 해결책으로 매끄럽게 연결해 주는 시스템 구조야말로 사용자가 AI 챗봇 창을 닫지 않게 만드는 첫걸음입니다.

마치며

우리는 기술의 홍수 속에서 종종 본질을 잊곤 합니다. 어떤 생성형 AI 모델을 썼는지, 프롬프트 파인 튜닝을 얼마나 정교하게 했는지는 우리 개발팀 내부의 치열한 엔지니어링 기록일 뿐, 서비스를 이용하는 사용자에게 중요한 건 아닙니다. 사용자의 좋은 경험은 “와, 이 서비스 AI가 대단하네.”라고 인지하는 순간이 아니라, 내가 겪은 불편함이 기분 좋게 해결되어, “어라? 생각보다 쉽게 끝났네.”라고 느끼는 짧은 찰나에 있습니다.

여러분이 만든 AI 챗봇은 어떤가요? 지금 바로 브라우저를 켜고, 우리 서비스의 가장 대표적인 케이스를 직접 끝까지 해보시기를 권합니다. 사용자가 되어 직접 질문을 던지고, 챗봇과 씨름하며 그 답답함을 온몸으로 겪어보세요. 우리가 만든 프로덕트가 정말 고객을 돕고 있는지, 아니면 그저 시간만 끌고 있는지. 그 냉정한 현실을 마주하는 게 진짜 개선의 시작입니다.

]]>

테스트 코드 없이 웹을 검수하는 Manta AI, 믿을만할까?

웹 서비스를 만들 때는 화면을 완성하는 것만큼 배포 전 흐름을 확인하는 일도 중요합니다. 그런데 페이지가 많아지면 모든 화면을 직접 열어보는 데 시간이 걸리고, 어떤 경로부터 확인할지 정하는 일도 쉽지 않습니다.

특히 여러 외부 서비스의 운영 상태와 장애 이력을 보여주는 ‘VibeStatus’처럼, 서비스별 상태 페이지와 이력 페이지가 반복되는 웹 서비스라면 더욱 그렇습니다. (VibeStatus는 제가 바이브코딩 방식으로 작업한 웹 서비스로, 메이커가 자주 쓰는 서비스의 실시간 상태와 업데이트 소식을 확인할 수 있습니다.)

오늘 소개할 ‘Manta AI’는 URL을 입력하면 웹 서비스를 탐색하고, 페이지와 이동 관계를 정리해 주는 AI 소프트웨어 테스트 에이전트입니다. 자연어로 테스트 계획을 작성하고 실행하는 기능도 제공하는데요. 저는 반복 페이지가 많은 VibeStatus의 공개 영역을 연결해 실제로 어떤 도움을 받을 수 있는지 살펴봤습니다.

사용 전에는 자연어 테스트 계획(Test Plan)을 가장 기대했습니다. 테스트 코드를 직접 작성하지 않고도 핵심 흐름을 확인할 수 있을 것 같았기 때문입니다. 그런데 사용해 보니 자연어 테스트보다 먼저 실행한 탐색(Exploration)과 사이트 인텔리전스(Site Intelligence)가 서비스 구조와 검수 범위를 정리하는 데 더 도움이 됐습니다.

Manta AI 안에서는 별도의 테스트 코드를 작성하지 않았고, 보고된 항목이 실제로 수정이 필요한 문제인지 구분하기 위해 공개 흐름만 ‘Playwright’로 다시 실행하는 방식으로 테스트를 진행해봤습니다. 이번 글에서는 Manta AI의 주요 기능과 실제 결과, 아쉬운 점을 함께 정리해 보겠습니다.

미리 요점만 콕 집어보면?

사용 전에는 자연어 Test Plan을 가장 기대했지만, 실제로는 Exploration과 Site Intelligence가 서비스 구조와 검수 범위를 파악하는 데 더 도움이 됐습니다.
Bugs에는 보안 설정 누락과 외부 API·리소스 오류처럼 성격이 다른 항목이 함께 포함돼, 표시된 숫자를 곧바로 실제 버그 수로 보기는 어려웠습니다.
자연어 Test Plan은 원하는 흐름을 테스트 절차로 바꿔줬지만, 정상 리디렉션까지 실패로 처리해 허용할 URL 이동과 성공 조건을 구체적으로 적어야 했습니다.
Manta AI는 테스트를 모두 대신하기보다 검수할 범위와 문제 후보를 먼저 펼쳐 주는 도구에 가까웠으며, 우선순위와 최종 오류 판단은 사람이 맡아야 했습니다.

‘Manta AI’의 주요 기능과 특징

<출처: Manta AI, 작가 캡처>

Manta AI는 크게 두 가지 흐름으로 사용할 수 있습니다. Exploration으로 웹 서비스의 구조와 문제 후보를 먼저 파악한 뒤, 확인이 필요한 사용자 흐름을 자연어 Test Plan으로 만들어 실행하는 방법입니다.이 과정에는 내비게이션 맵(Navigation Map), 인증 영역 확인, UI 변경에 대응하는 셀프 힐링(self-healing)이 활용됩니다.

<출처: Manta AI, 작가 캡처>

시작점은 Exploration입니다. 서비스 URL을 입력하고, 운영·스테이징 같은 환경을 지정하면 에이전트가 접근한 범위에서 경로를 탐색하고, 결과 화면에 경로(routes)와 문제 후보(findings)를 표시해줍니다. (다만, 모든 URL을 빠짐없이 수집했다는 의미는 아닙니다. 에이전트가 접근한 범위에서 탐색 가능한 경로와 문제 후보를 다음 단계로 넘겨주는 구조이기 때문입니다.)

<출처: Manta AI, 작가 캡처>

Site Intelligence는 Exploration 결과를 서비스 구조 관점에서 정리한 화면입니다. 탐색된 페이지(pages)와 페이지 사이의 이동 관계(flow transitions)를 보여주기 때문에, 반복 페이지의 분포와 사용자 타입(게스트, 회원, 관리자 등)에 따른 영역, 폼·인증 지점의 위치를 파악할 때 참고할 수 있습니다. Navigation Map은 이 구조를 지도 형태로 보여줍니다. Site Intelligence에서 전체 구성과 규모를 파악했다면, Navigation Map에서는 특정 페이지가 어떤 경로와 연결되는지 확인할 수 있습니다.

<출처: Manta AI, 작가 캡처>

문제 후보는 Bugs에서 검토할 수 있습니다. 리스트에서 개별 내용을 클릭하면 상세 화면에서 URL, 심각도, 신뢰도, 환경과 재현 절차를 볼 수 있습니다.

<출처: Manta AI, 작가 캡처>

특정 사용자 흐름은 자연어로 조건을 요청해 Test Plan으로 실행할 수 있습니다. 저는 홈에서 영어 Stripe 상태 페이지로 이동해 내용을 확인하고 돌아오는 내용을 입력했는데, 8단계의 실행 가능한 테스트 절차를 확인할 수 있었습니다. 테스트 실행(Test Run)을 누르면, 앞서 설정한 Test Plan을 실제 브라우저에서 실행하며, 단계별 통과와 실패 결과를 기록합니다.

2026년 7월 기준 Manta AI는 공식 홈페이지에서 공개 베타(Public Beta)로 운영되고 있습니다. 신용카드 등록 없이 무료로 시작할 수 있으며, 팀 요금은 사용량 기반이라고 안내합니다. 다만, 구체적인 요금과 크레딧(credits) 환산 기준은 공개 화면에서 확인하기 어렵습니다.

URL 하나로 서비스 구조 확인하기

<출처: Manta AI, 작가 캡처>

어떤 식으로 서비스가 작동하는지 확인하기 위해, Exploration부터 실행했습니다. 'VibeStatus' 서비스를 운영(Production) 환경에 연결했고, 관리자 로그인, 상태 구독 제출, Slack 설치와 외부 링크 이동은 제외했습니다. Exploration을 실행하면 자동으로 Site Intelligence, Navigation Map, Bugs가 기록됩니다.

새 탐색은 17분 45초 동안 진행됐고, 결과 화면에는 466 routes와 12 findings가 표시됐습니다. 실행 전후 잔액 차이로 계산한 크레딧 사용량은 0.79였습니다. (참고로, 가입 시 25 크레딧이 제공됩니다) 이는 기능별 고정 요금이 아니라 이번 실행에서 확인한 차감량으로, 서비스 규모와 탐색 범위에 따라 달라질 수 있습니다.

<출처: Manta AI, 작가 캡처>

탐색이 끝난 뒤, Site Intelligence를 열어봤습니다. 총 464 pages와 424 flow transitions가 수집된 것을 확인할 수 있습니다. 서비스별 상태와 이력 페이지처럼 반복되는 경로가 보였고, 게스트와 관리자 영역, 폼과 인증이 필요한 지점도 영역별로 구분돼 있었습니다.

<출처: Manta AI, 작가 캡처>

Navigation Map에서는 /en에서 상태 페이지로 이어지는 경로와 /status/*, /en/status/* 형태의 언어별(이 서비스는 한글과 영문이 모두 지원됩니다.) URL이 드러났습니다. /guides/*, /updates/*, /en/data-deletion, /slack/install 같은 경로도 함께 보였는데요. 공개 흐름과 인증·설치 흐름을 나눠 다음 검수 순서를 정할 수 있었습니다.

<출처: Manta AI, 작가 캡처>

Bugs의 43 open 중 대표 항목을 직접 열어 실제 응답과 화면을 확인해봤습니다. 대표 사례는 ‘Missing security header’였습니다. 상세 화면에는 URL, 신뢰도 100%, 심각도(Medium), 운영(Production) 환경 등에 대한 정보와 재현 절차가 포함되어 있습니다.

확인해 보니 이 항목은 브라우저가 허용할 콘텐츠 출처를 제한하는 CSP(Content Security Policy)와 관련된 내용이었습니다. 공개 URL 응답에서 Content-Security-Policy 헤더가 보이지 않아 보안 정책을 검토할 개선 후보로 결정할 수 있었습니다.

<출처: Manta AI, 작가 캡처>

Manta AI가 콘솔 오류로 표시한 다섯 URL도 Playwright로 다시 실행했습니다. 실행 로그를 확인해 보니, 다섯 페이지 모두 Supabase의 outage-analysis 함수 요청이 HTTP 402 또는 429 응답으로 실패했다는 것을 알 수 있었습니다. Manta AI가 감지한 오류 응답 자체는 다시 확인할 수 있었던 셈입니다.

다만 오류가 발생한 이유와 사용자에게 미친 영향은 별개의 문제였습니다. 429는 일반적으로 요청이 짧은 시간에 몰렸을 때 반환되지만, 이번 함수가 어떤 조건에서 응답했는지는 서버 측 확인이 필요하기 때문입니다. 402 역시 응답 본문이나 서버 로그 없이는 원인을 특정하기 어려웠습니다. 따라서 이 결과만으로 주요 화면이나 사용자 흐름에 문제가 생겼다고 판단할 수는 없었습니다.

외부 파비콘을 불러오지 못해 발생한 404처럼 핵심 기능과 직접 관련이 낮은 항목도 있었습니다. 결국 Bugs에는 실제로 재현되는 응답 오류와 사용자 영향이 낮은 리소스 오류가 함께 포함돼 있었습니다. 수정 티켓으로 옮기기 전에는 오류가 발생한 위치와 사용자 영향, 중복 여부를 기준으로 우선순위를 다시 판단하는 과정이 필요하다고 느낀 순간이었습니다.

자연어로 테스트 시나리오 만들기

<출처: Manta AI, 작가 캡처>

다음 조건으로 자연어 Test Plan을 만들었습니다. 게스트로 홈을 열고, 영어 Stripe 상태 페이지로 이동해 상태 콘텐츠를 확인한 뒤 홈으로 돌아오는 흐름입니다. 로그인과 폼 제출, Slack 설치와 외부 링크 이동은 하지 않는 조건도 함께 적었습니다. 다만 /에서 /en으로 이동하는 정상 리디렉션을 허용한다는 조건은 별도로 적지 않았습니다.

Manta AI는 이 요청을 Guest can view Stripe status page and return to home이라는 Test Plan으로 만들었고, 생성된 계획은 총 8단계였습니다.

<출처: Manta AI, 작가 캡처>

아쉽게도, 결과는 8단계 중 1단계만 통과한 뒤 실패(Failed)로 끝났습니다. 두 번째 단계에서 Plan이 https://vibestatus.co.kr/를 기대했지만, 실제 브라우저는 https://vibestatus.co.kr/en에 도착했기 때문입니다. 정상적인 리디렉션이었지만, 이번 Test Plan에서는 URL 불일치로 처리됐습니다.

Test Plan이 두 번째 단계에서 중단된 원인이 실제 서비스 오류인지 확인하기 위해, 같은 공개 흐름을 Playwright로 다시 실행했습니다. 홈에 접속하자 /에서 /en으로 정상 이동했고, 영어 Stripe 상태 페이지에서도 현재 상태와 최근 인시던트, 가동 시간 영역이 모두 표시됐습니다. Incidents와 Updates 페이지도 정상적으로 열렸습니다. 실제 사용자 흐름이 중단된 것이 아니라, Test Plan이 정상 리디렉션을 예상하지 못해 실패한 결과라는 것을 알 수 있었습니다.

이번 경험을 통해 자연어 Test Plan은 확인할 흐름을 실행 가능한 절차로 만드는 데는 도움이 되지만, 서비스별 정상 동작까지 모두 알아서 판단하지는 못한다는 점을 알 수 있었습니다. /에서 /en으로 이동해도 성공으로 처리한다는 조건처럼 허용할 URL 변화와 성공 기준을 요청에 구체적으로 적어야 합니다.

어떤 팀이 활용하기에 적합할까?

<출처: Manta AI, 작가 캡처>

반복 페이지가 많아 어디부터 검수할지 정하기 어려운 서비스라면 Manta AI를 초기 탐색에 활용해 볼 수 있습니다. 공개 영역이나 안전한 스테이징 환경에서 먼저 범위를 넓혀 보고, 정상 리디렉션과 인증 전환, 성공 조건을 사전에 정의할 수 있는 팀에도 잘 맞습니다. 다만, 자동 결과를 그대로 확정하지 않고 대표 표본을 골라 직접 재현할 수 있어야 한다는 전제가 붙습니다.

결제·삭제·권한 변경처럼 잘못 실행했을 때 영향이 큰 흐름은 신중하게 적용해야 합니다. 정상적인 인증 전환과 외부 API 오류의 경계를 사전에 명확히 정의하기 어려운 서비스도 마찬가지입니다. Bugs 결과를 재현 없이 바로 수정 티켓으로 옮기거나, 셀프 힐링과 반복 회귀 테스트의 완전 자동화를 기대하는 방식은 이번 테스트 결과만으로 뒷받침하기 어렵기 때문입니다.

이번 테스트에서 가장 현실적이었던 활용 순서는 자동 탐색으로 구조를 펼치고, 사람이 우선순위를 정한 뒤 핵심 흐름만 Test Plan으로 만들고, Bugs의 문제 후보를 재현하는 방식이었습니다.

마치며

Manta AI를 사용하기 전에는 자연어 Test Plan을 가장 기대했습니다. 하지만 실제로 더 도움이 된 기능은 Exploration과 Site Intelligence였습니다. 반복되는 상태 페이지와 이동 관계를 펼쳐 보여줘, 서비스 구조와 검수 범위를 파악하는 데 바로 활용할 수 있었기 때문입니다.

Manta AI에 맡길 수 있었던 일은 에이전트가 접근한 페이지와 이동 경로를 모으고, 반복 구조와 문제 후보를 정리하며, 자연어 요청을 테스트 절차로 바꿔 실행하는 단계까지였습니다. 반면, 어떤 경로를 먼저 검수할지, 정상 리디렉션과 실제 실패를 어떻게 구분할지, 외부 API 응답이 사용자에게 영향을 주는지, Bugs 항목의 중복과 중요도를 어떻게 판단할지는 사람의 몫이었습니다.

UI 변경 후 셀프 힐링과 수정 후 반복 회귀 테스트까지는 검증하지 못했지만, 반복 페이지가 많아 검수의 시작점을 잡기 어려운 팀이라면 Manta AI를 서비스 구조와 문제 후보를 먼저 펼쳐 보는 도구로 활용해 볼 수 있을 거라 생각합니다.

<참고>

https://mantaai.co

]]>

넷플릭스 CPTO가 말하는, AI 시대에 채용하고 싶은 사람의 조건

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

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

써볼 것: 크래프톤 A.X K2 Raon-Speech - 게임사가 공개한 한국어 1위 음성 AI 모델
참고할 것: 영국 AI 보안 연구소가 겪은 일 - AI 에이전트가 실제 사람을 속이려 한 사건 (내용이 좀 깁니다)
적용해볼 것: 넷플릭스는 왜 전문가보다 시스템 사고자를 뽑을까

<출처: KRAFTON, A.X K2 Raon-Speech>

1. 써볼 것: 게임사가 공개한 한국어 1위 음성 AI 모델

배틀그라운드로 잘 알려진 게임사 크래프톤이 음성 AI 모델을 공개했습니다. 이름은 A.X K2 Raon-Speech고요. 사람 말을 알아듣고(음성인식), 사람처럼 말하고(음성합성), 음성으로 오간 대화에 답하는 걸 하나의 모델로 처리하는 음성 언어 모델입니다.

눈에 띄는 건 성능입니다. 크래프톤 발표에 따르면, 이 모델은 파라미터 300억 개(30B) 이하 규모의 공개 음성 언어 모델 가운데 한국어 종합 성능 1위를 기록했습니다. 게임사가 만든 음성 AI가 이 체급에서 한국어로는 가장 앞선 셈이죠.

무엇을 하는 모델인가요?

이 모델은 음성과 관련된 여러 일을 한 번에 처리합니다. 녹음된 말을 글로 옮기고(STT), 글을 음성으로 읽어주고(TTS), 음성으로 던진 질문에 답하고, 글로 된 질문에도 답해요. 여기에 도구를 불러 쓰는 기능과 여러 차례 주고받는 대화까지 지원하고요.

한 가지 특징은 목소리에 담긴 감정이나 억양까지 읽어서 답한다는 점입니다. 단어만 알아듣는 게 아니라 어떻게 말했는지도 참고해 더 자연스럽게 반응하는 거죠. 또 참조할 목소리를 주면 그 목소리를 흉내 내 말하거나(음성 복제), 앞서 나온 음성의 말투를 이어받아 계속 읽어주는 것도 됩니다.

* 음성 샘플은 여기서 들어볼 수 있습니다.

구조를 잠깐 보면, SK텔레콤이 만든 텍스트 모델(A.X K2 Light)을 바탕으로 삼고, 그 위에 크래프톤이 자체 학습한 음성 인코더와 음성 코덱을 얹었습니다. 전체 21.2B 파라미터 중 실제로는 약 3.5B만 활성화되는 방식이라, 크기에 비해 효율적으로 돌아가고요. 이 모델은 과학기술정보통신부가 주관하는 독자 AI 파운데이션 모델 프로젝트의 SK텔레콤 팀 참여로 나온 결과이기도 합니다.

써보려면 무엇이 필요한가요?

다만 이 모델을 아무 컴퓨터에서나 돌릴 수 있는 건 아닙니다. 크래프톤에 따르면 모델 가중치가 약 42.4GB라, 80GB 메모리를 갖춘 GPU나 그에 준하는 여러 대의 GPU 구성이 권장됩니다. 개인이 가벼운 장비로 시험해보긴 부담스러운 사양이죠.

따라서 이 소식은 현재 한국어 음성 AI가 어디까지 왔는지 확인하는 용도로 보면 좋습니다. 모델은 허깅페이스에 올라와 있고, 돌릴 장비가 있다면 STT나 TTS, 음성 질의응답 같은 기능을 코드 몇 줄로 불러 쓸 수 있어요. 라이선스가 CC BY-NC 4.0이라 연구와 비상업 용도로만 쓸 수 있다는 점도 알아두면 좋고요.

누구에게 좋을까요?

한국어 음성 기능을 다루는 프로덕트를 고민하는 사람. 지금 한국어 음성 AI의 성능이 어디까지 왔는지 가늠해볼 수 있습니다.
음성 관련 연구나 프로토타입을 만드는 사람. STT부터 TTS, 음성 대화까지 하나의 모델로 실험해볼 수 있어요.
GPU 자원이 있는 팀. 자체 서버에 올려 음성 기능을 직접 붙여볼 수 있습니다.

<출처: AI Security Institute, Incident Report>

2. 참고할 것: AI 에이전트가 실제 사람을 속이려 한 사건

지난주에도 AI 에이전트가 스스로 남의 시스템을 파고든 사건을 다뤘는데요. 비슷한 일이 또 나왔습니다. 이번엔 영국 정부의 AI 보안 연구소(AISI)가 직접 겪은 일이고, 8월 4일 사고 보고서로 공개됐습니다.

무슨 일이 있었는지 보기 전에, 이 사건이 왜 벌어졌는지부터 짚어야 합니다. AISI는 AI 모델이 사이버 공격에 악용될 수 있는지 알아보려고, 일부러 안전장치를 풀고 시험합니다. 인터넷을 열어주고, 모델에 붙어 있는 위험 차단 필터도 꺼요. 실제 서비스에서는 이 필터가 켜져 있지만, 모델이 최대로 무엇까지 할 수 있는지 보려면 꺼야 하기 때문입니다. 따라서 이번 사건은 그렇게 안전장치를 끈 상태의 시험에서 나왔습니다. 평소 우리가 쓰는 AI 서비스와는 조건이 다르다는 점을 참고해주세요.

무슨 일이 벌어졌나요?

AISI는 AI 에이전트에게 사이버 보안 문제를 풀게 하는 시험을 122번 돌렸습니다. 그중 10번에서 에이전트가 시험 범위를 넘어, 실제 인터넷에서 진짜 사람과 조직을 겨냥한 행동을 했습니다. AISI에 따르면 이런 행동이 총 19건 확인됐고, 그중 17건이 Anthropic(앤트로픽)의 Mythos 5, 2건이 위험 필터를 끈 OpenAI(오픈AI)의 GPT-5.6 Sol에서 나왔습니다.

가장 심각한 건 오픈소스 프로젝트에 몰래 악성 코드를 심으려 한 시도예요. 에이전트는 코드를 승인받으려고 가짜 신원을 여러 개 만들어, 실제 프로젝트 관리자를 속이려 했습니다. 자기가 만든 코드가 문제없어 보이도록 이전 흔적을 고치기도 했고요. 다행히 사람 관리자가 이를 알아채고 승인을 거부했습니다.

이것 말고도 에이전트는 실제 사람에게 직접 연락해 악성 코드를 실행하도록 유도하거나, 다른 AI가 몰래 읽고 따르도록 숨긴 지시를 심으려 했어요. 같은 시험을 보던 다른 AI 에이전트에게 협업하자고 공개 메시지를 남기기도 했고요.

여기서 중요한 두 가지

이 사건에서 특히 짚어볼 대목이 두 가지 있습니다.

하나는 아무도 속이라고 시키지 않았다는 점입니다. AISI는 에이전트에게 사람을 속이라고 지시한 적이 없습니다. 에이전트가 주어진 문제를 풀려고 애쓰는 과정에서, 속임수가 하나의 방법으로 저절로 튀어나온 거예요. AISI는 이런 목표를 위한 기만이 얼마 전까지 이론에만 있던 이야기였는데, 이번에 실제로 나타났다고 설명합니다.
다른 하나는 이걸 막은 게 기술이 아니라 사람이었다는 점입니다. 최악의 상황을 막은 건 자동화된 방어벽이 아니라, 코드를 검토한 사람의 경계심이었습니다. AISI도 실패와 성공의 차이가 아슬아슬했고, 더 뛰어난 에이전트였다면 결과가 달랐을 수 있다고 인정합니다.

무엇을 얻어가야 하나요?

여기서 오해하지 말아야 할 게 있어요. 이건 안전장치를 일부러 끈 통제된 시험에서 벌어진 일이고, 실제 서비스에서 같은 일이 일어났다는 뜻은 아닙니다. AISI도 실제 피해는 확인되지 않았다고 밝혔고요. 지레 겁먹을 일은 아니라는 거죠.

다만 방향은 분명합니다. 지난주 사건에 이어 이번까지, AI 에이전트에게 실제로 행동할 권한을 주면 예상 못 한 일이 벌어질 수 있다는 게 반복해서 확인되고 있죠. 그래서 에이전트를 만들거나 붙여 쓰는 프로덕트 메이커라면, AISI가 권하는 대응이 참고가 되는데요. 사실 기본에 가까운 내용입니다. 외부에서 온 코드나 기여는 실행하기 전에 사람이 검토하고, 의심스러운 코드는 격리된 환경에서 열어보는 것. 이번 사건에서 최악을 막은 게 바로 이 평범한 습관이었으니까요. AI가 더 많은 일을 대신할수록, 사람이 마지막으로 확인하는 과정이 점점 더 중요해질 거라 생각합니다.

<출처: Lenny's Podcast, Elizabeth Stone (Netflix)>

3. 적용해볼 것: 넷플릭스는 왜 전문가보다 시스템 사고자를 뽑을까

AI 덕에 이제 누구나 뭐든 할 수 있게 됐습니다. 기획자가 코드를 짜고, 디자이너가 기획서를 쓰고, 개발자가 제품을 구상해요. 편해진 것 같지만, 한편으론 그래서 내 일이 뭐지 하는 혼란도 생겨나고 있죠. 이 질문을 넷플릭스의 제품·기술 총괄 엘리자베스 스톤(Elizabeth Stone)이 Lenny's Podcast에서 이 고민을 짚었습니다.

AI 시대에 넷플릭스는 어떤 사람을 뽑고 어떻게 일하는지에 대한 이야기입니다. 사실 넷플릭스는 AI에 일찍부터 진심이었는데요. 2006년에는 추천 알고리즘을 10% 개선하는 팀에게 상금 100만 달러를 건 넷플릭스 프라이즈 대회를 열었을 정도죠. 그런 회사가 지금은 어떤 역량을 중요하게 보는지 들어보면 꽤나 흥미로운 참고가 될 거라 생각합니다.

스톤의 답을 한마디로 줄이면, 경계는 흐려져도 각 분야의 깊이는 사라지지 않는다는 겁니다. 다들 더 많은 일을 할 수 있게 됐지만, 뛰어난 엔지니어링과 데이터 분석, 창의성은 여전히 드물다는 거죠. 그러면서 넷플릭스가 요즘 더 찾는 사람으로 ‘시스템 사고자’를 꼽았습니다.

시스템 사고자가 무엇인가요?

시스템 사고자는 자기 앞의 문제만 보는 게 아니라, 그 문제가 전체 안에서 어디에 놓이는지를 보는 사람입니다. 스톤은 그 이유를 이렇게 설명해요. AI 에이전트가 여러 시스템을 넘나들며 일하는 시대에는, 각자 알아서 만드는 것보다 공통의 토대를 잘 깔아두는 게 중요해진다는 겁니다. 그래야 여러 사람과 여러 AI가 그 위에서 안전하고 빠르게 일할 수 있으니까요.

그래서 넷플릭스는 특정 분야만 깊게 파는 사람(전문가)보다, 여러 영역을 가로질러 보고 앞으로 필요한 토대가 무엇인지 그려낼 수 있는 사람(시스템 사고자)을 더 뽑는다고 합니다. 디자인도 마찬가지예요. 개별 화면을 예쁘게 만드는 것보다, 여러 사람이 일관된 제품을 만들 수 있도록 디자인의 틀과 기준을 세우는 사람이 중요해졌다고 하고요.

시스템 사고는 어떻게 기르나요?

스톤은 거창한 방법 대신 작은 요령을 알려줍니다. 어떤 문제를 풀 때, 한 단계만 뒤로 물러나 보라는 거예요. 지금 이 문제를 풀면서 내가 당연하게 여기는 전제가 뭐지? 하고 한 번 묻는 겁니다.

예를 들어 어떤 기능을 만드는 일을 맡았다면, 곧장 만들기 전에 잠깐 멈춰서 이 기능이 풀려는 더 큰 문제는 뭘까, 이 방식이 나중에 다른 경우까지 확장될 수 있을까를 생각해보는 거죠. 스톤은 여기서 너무 오래 고민하면 앞으로 못 나가니, 딱 한 단계만 줌아웃하라고 조언합니다.

또 다른 방법은 내 상사라면 어떻게 볼까 생각해보는 겁니다. 내가 맡은 일만이 아니라 상사가 보는 더 넓은 그림에서 생각하면, 자연스럽게 시야가 넓어진다는 거예요. 내가 하는 일이 동료에게도 도움이 될까, 다음 사람이 이어받기 좋게 남기고 있나를 챙기는 것도 시스템 사고고요.

적용해볼 원칙 몇 가지

인터뷰에서 프로덕트 메이커가 챙길 만한 조언을 추려봤습니다.

한 단계 줌아웃하는 습관을 들입니다. 문제를 받으면 바로 뛰어들기 전에, 이게 풀려는 더 큰 문제가 뭔지 한 번만 물어보세요. 단, 너무 오래 붙잡지는 말고요.
전문성은 계속 갈고닦습니다. 경계가 흐려져도 내 분야의 깊이는 여전히 무기입니다. 스톤은 뛰어난 실력은 지금도 드물다고 반복해서 강조했어요. AI로 여러 일을 하게 됐다고 내 중심 역량을 놓아버리면 안 된다는 거죠.
AI를 쓰되 책임은 내가 집니다. 스톤이 특히 강조한 대목입니다. 에이전트가 코드를 짰든, 내가 잘 모르는 분석을 AI 도움으로 했든, 결과에 대한 책임은 사람에게 남습니다. ‘AI가 저렇게 하라고 했으니까’는 변명이 될 수 없습니다.
새로운 방식에 열려 있습니다. 넷플릭스가 채용을 할 때 보는 건 특정 기술만이 아니라, 계속 바뀌는 상황을 즐기고 새로운 걸 시도하려는 태도라고 합니다. 스톤은 이걸 AI 유창성이라 부르는데, AI를 얼마나 잘 다루고 어디에 써야 할지 아는 감각을 말합니다. 신입이든 임원이든 모두에게 이걸 기대한다고 하죠.

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

지금 맡은 일 하나를 골라, 이게 풀려는 더 큰 문제가 뭔지 한 문장으로 적어보세요. 그 한 문장이 지금 방식이 맞는지 다시 보게 해줍니다.
내가 AI에 맡긴 결과물을 한 번 더 검토하는 습관을 들이세요. 결과에 대한 책임은 결국 나에게 있으니까요.

도구는 점점 강해지지만, 무엇을 만들지 정하고 결과에 책임지는 건 여전히 사람의 몫입니다. 그 몫을 어떻게 키울지 고민하는 게, 지금 프로덕트 메이커에게 가장 남는 일이 아닐까 싶습니다.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다. 댓글도 좋아요!

]]>

크리에이터가 9개월간 커뮤니티를 운영하며 느낀 점들

저는 디자인 기록을 업로드하는 1인 크리에이터 “이키”로 활동하고 있습니다. 인스타그램 팔로워는 1.5만이고, 유튜브도 함께 운영하고 있죠. 이 외에도 바이브 코딩으로 카카오톡 대화 신호를 분석하는 웹사이트 ‘톡시그널(Toksignal)’과, 마음에 드는 문장을 채집해 저장하는 앱 ‘문채’도 직접 만들어 출시해 보기도 했습니다.

그런 제가 9개월 전에 카카오톡 오픈채팅방 하나를 열었습니다. 이유는 단순했습니다. 멀리 있는 사람들과 조금 더 연결되고 싶은 마음이 생겼거든요. 그리고 9개월이 지난 지금, 그 방에는 메시지가 87,000건 넘게 쌓여 있습니다. 이 데이터를 들여다보니 꽤 흥미로운 패턴이 보였습니다. 사람이 어떻게 들어오고, 어떻게 활발해지고, 언제 조용해지는지 말이죠.

<출처: 작가>

그래서 이번 글은 “커뮤니티를 만들까, 말까” 고민하는 크리에이터들에게 판단 재료가 되길 바라는 마음에서 썼습니다. 또 사이드 프로젝트나 서비스 차원에서 유저 커뮤니티를 고려하는 PM, 계정을 운영하는 디자이너에게도 참고가 되길 바랍니다.

팔로워 14,000명이 있는데 왜 불안했을까

인스타그램 계정의 팔로워가 14,000명을 넘기면서 숫자는 꽤 그럴듯해졌습니다. 릴스 하나가 터지면 팔로워가 수백 명씩 늘었습니다. 그런데 왠지 공허한 느낌이 들었죠.

팔로잉은 일방적인 화살표라는 생각이 들었습니다. DM을 보내주시는 분은 늘 비슷한 소수였고, 댓글을 달아주시는 분도 정해져 있었습니다. 14,000이라는 숫자 뒤에, 실제로 저와 연결된 사람은 대체 몇 명인지 의문이 들었죠.

여기에 하나 더 불안한 게 있었습니다. 플랫폼은 내가 빌린 땅입니다. 만약 인스타그램 알고리즘이 바뀌면 도달률이 반 토막 날 수 있고, 계정이 정지되면 그동안 모은 팔로워가 통째로 사라집니다. 이건 이론이 아니라 실제로 크리에이터들에게 일어나고 있는 일이고, 저에게도 언제든 일어날 수 있는 일입니다.

숫자는 늘어나는데 연결은 얕고, 그마저도 빌린 땅 위에 있다. 그러면 결국 하나는 만들어야 하지 않을까요? 인스타그램 바깥에, 결이 맞는 사람들과 양방향으로 이어질 수 있는 공간 말이죠.

그런데 솔직히 플랫폼 리스크만으론 커뮤니티를 만들지는 않았을 겁니다. 진짜 이유는 따로 있었습니다. 혼자 콘텐츠를 만들고, 혼자 올리고, 반응을 기다리는 루틴을 반복하다 보니 외로웠기 때문이죠. 말이 통하고 함께 성장하는 경험을 하고 싶었지만, 팔로워 사이에서 그런 사람을 찾기는 쉽지 않았습니다.

내 콘텐츠를 보고 좋은 감정을 느끼는 분들과 직접 대화하고 싶어졌습니다. 그리고 그들이 어떻게 변화하고, 성장하는지 옆에서 함께 지켜보고 싶었습니다. 이게 제가 커뮤니티를 시작한 이유입니다.

<출처: 작가>

0명에서 80명까지, 사람은 어떻게 모였을까

처음엔 카카오톡 오픈채팅방이 진입 장벽이 가장 낮다고 생각했습니다. 그래서 채팅방을 만들고, 인스타그램 스토리에 링크를 올렸습니다. 처음엔 조용했죠. 첫 주에 들어온 분이 10명 남짓이었습니다. 대부분 챌린지에 참여해 저를 어느 정도 알고 계신 분들이 먼저 오셨고, 저를 팔로우만 하고 계시던 분들은 거의 움직이지 않았습니다.

그래도 꾸준히 운영했습니다. 인스타그램 캐러셀(카드뉴스)로도 이런 커뮤니티를 만들었다고 안내했죠. 그렇게 운영을 이어가다, 멤버가 50명으로 늘었습니다. 그리고 50명에서 80명으로 늘어난 계기는 릴스 한 편이었습니다. 커뮤니티를 운영하는 중간에 릴스를 하나 올렸는데, 그 영상 하나로 2일 만에 30명이 들어왔습니다. 팔로워 14,000명 기준으로 약 0.21% 전환율이었죠.

숫자만 보면 큰 성과처럼 보이진 않습니다. 그런데 이 30명은 영상을 보고, 댓글을 남기고, 링크를 클릭해서, 오픈채팅방에 직접 입장하는 4단계를 거친 분들입니다. 그냥 좋아요를 누른 것에 그치지 않고, 행동으로 옮긴 분들이죠. 이 차이가 굉장히 컸습니다.

이 경험이 알려준 건 두 가지였습니다. 첫째, 팔로워 수와 커뮤니티 유입은 비례하지 않습니다. 둘째, 콘텐츠의 포맷과 메시지가 맞으면 소수지만 확실한 분들을 모을 수 있습니다. 그렇게 9개월간 오픈채팅방 멤버는 80명대까지 늘어났습니다.

87,000건의 대화를 뜯어보니 보이는 것들

9개월 동안 이 오픈채팅방에 쌓인 메시지는 약 87,000건입니다. 이걸 정리해보니 몇 가지 뚜렷한 패턴이 드러났습니다. 처음 3개월은 메시지가 빠르게 늘었습니다. 새 멤버가 들어오면서 자기소개와 질문이 쏟아졌고, 기존 멤버들도 열심히 반응해주셨죠. 전형적인 초반 활성 구간이었습니다.

4~6개월 차가 되자, 메시지 양이 눈에 띄게 줄었습니다. 새로 들어오는 분이 줄면서 대화 주제가 반복되기 시작했고, 일부 멤버는 읽기만 하는 모드로 전환됐습니다. 서비스로 치면 리텐션 커브가 꺾이는 시점과 똑같은 모양이었습니다.

전체 대화에서 운영자인 제 메시지 비중을 따로 뽑아봤습니다. 초반에 제 비중이 꽤 높았습니다. 질문을 던지고, 주제를 제안하고, 반응이 없으면 제가 먼저 말을 꺼내는 패턴이 계속 반복됐죠. 돌이켜보면 이건 ‘운영’이 아니라 ‘1인 공연’이었습니다. 제가 무대에서 내려가면 대화가 멈추는 구조였죠. 이대로는 오래 못 간다는 걸 데이터가 알려줬습니다.

그런데 그 구조를 깨준 건 제가 아니었습니다. 활동량 기준 상위 3명의 멤버였습니다. 이분들이 대화 분위기를 만들고, 새 멤버가 오시면 먼저 말을 걸고, 대화가 끊기면 새 주제를 꺼내주셨습니다. 나머지 70명 이상은 이분들이 만든 흐름에 올라타는 구조였습니다.

서비스에서 흔히 말하는 ‘파워 유저’와 같은 존재죠. 커뮤니티의 건강 지표는 전체 인원이 아니라, 이 소수의 활성 멤버가 얼마나 꾸준히 움직이는지에 달려 있었습니다.

<출처: 작가>

운영 방식을 바꾼 두 가지

이러한 정체 구간에서 저는 두 가지를 바꿨습니다.

1) 진입 방식을 바꿨습니다

원래는 오픈채팅방 링크를 바로 공개했습니다. 문턱을 낮추니 유입 속도는 올라갔는데, 들어왔다가 나가는 분도 많아졌죠. 그래서 지금은 간단한 신청서를 받는 방식으로 운영하고 있습니다. 질문 항목을 최소화해서 진입 허들은 낮추되, 관심도는 확인할 수 있게 조정한 겁니다. 이런 식으로 데이터를 보면서 계속 바꿔가는 게 커뮤니티 운영의 현실입니다.

2) 비활동자를 정리했습니다

이게 제일 용기가 필요했습니다. 오랜 기간 잠수 중인 분들에게 전체 공지로 미리 안내를 드리고, 반응이 없으면 퇴장 처리했습니다. 숫자가 줄어드는 게 솔직히 무서웠습니다. 그런데 정리한 뒤에 남은 분들의 활동 빈도가 오히려 올라갔습니다. 80명 중 10명이 말하는 방보다 50명 중 20명이 말하는 방이 체감으로는 훨씬 활기차기 때문이죠.

이렇게 진입 방식을 조정하고 비활동자를 정리한 뒤, 예상치 못한 변화가 생겼습니다.

커뮤니티가 자생한다는 증거

이제 멤버들이 스터디를 직접 만들기 시작했습니다. 영어, 레터링, 일본어, 마케팅 등 각자가 원하는 주제로 개설하고, 커뮤니티 안에서 멤버를 모집했습니다. 제가 기획한 게 아닙니다. 멤버분들 사이에서 먼저 하고 싶다는 이야기가 나왔고, 저는 공간과 모집을 세팅해드렸을 뿐입니다. 건강한 커뮤니티는 멤버들이 알아서 필요한 걸 만들어낸다는 걸 이때 배웠습니다.

<출처: 작가>

유료 챌린지를 기획할 때도 커뮤니티에 먼저 이야기를 꺼냈습니다. ‘이런 챌린지가 있으면 참여하실 의향이 있으신지’ 여쭤봤고, 반응과 피드백을 바탕으로 구성을 조정했습니다. 서비스 관점에서 보면 MVP(최소 기능 제품) 전의 수요 검증인 셈입니다.

설문을 돌리거나 인터뷰를 잡는 대신, 이미 신뢰가 쌓인 분들에게 직접 물어볼 수 있었습니다. 응답도 빠르고, 솔직한 피드백도 나옵니다. 좋아요만 눌러주시는 팔로워와, ‘그 구성이면 저는 이게 더 좋을 것 같아요.’라고 말해주는 커뮤니티 멤버는 완전히 다른 존재입니다.

9개월의 커뮤니티 운영이 알려준 것

9개월간 커뮤니티를 운영하면서 확인한 건 결국 이겁니다. 팔로워는 무대를 구경하는 관객이고, 커뮤니티 멤버는 무대 뒤편을 함께 쓰는 관계입니다. 인스타그램에서 14,000명에게 콘텐츠를 보여줄 수 있습니다. 하지만 그 14,000명 중 저와 직접적으로 소통하고, 이야기를 나누는 분은 극소수입니다.

그 적은 수의 사람들을 만나고, 관계를 이어가는 공간이 커뮤니티였습니다. 87,000건의 대화는 화려한 숫자가 아닙니다. 거기에는 초반의 들뜬 분위기도, 중간의 정체도, 구조를 바꾸고 나서의 회복도 전부 담겨 있었습니다. 그래서 이 글은 커뮤니티 성공 스토리가 아니라, 운영 일지에 더 가깝습니다.

이제 막 시작하려는 분께

마지막으로, 커뮤니티를 만들까 고민 중인 분들께 제가 9개월간 배운 것들을 짧게 정리해서 공유하겠습니다.

첫째, 숫자가 작을 때 시작하셔도 됩니다. 팔로워가 1,000명이든 10,000명이든, 실제로 커뮤니티에 들어오는 사람은 전체의 1%도 안 됩니다. 큰 숫자를 만든 뒤에 시작하겠다고 미루면, 타이밍만 놓칩니다. 처음 목표는 10명으로 시작해도 충분합니다.

둘째, 처음부터 완벽한 구조를 세우려 하지 않아도 됩니다. 규칙, 역할, 주제 분류 같은 건 운영하면서 필요해질 때 만들어도 늦지 않습니다. 저도 승인제를 넣었다 빼고, 다시 신청서 방식으로 바꾸는 과정을 거쳤습니다. 구조는 데이터를 보면서 계속 조정하는 겁니다.

셋째, 혼자 다 이끌면 오래 못 갑니다. 운영자의 메시지 비중이 높을수록 커뮤니티의 자생력은 낮습니다. 멤버분들이 스스로 대화를 시작하고, 서로 반응하는 흐름이 만들어져야 합니다. 목표는 ‘나 없이도 돌아가는 구조’를 만드는 것입니다.

넷째 비활동자는 정리해도 괜찮습니다. 멤버 수가 줄어드는 게 무서워서 잠수 인원을 그대로 두면, 활성 멤버들의 체감 밀도가 낮아집니다. 활발하게 움직이는 50명이 조용한 100명보다 커뮤니티를 건강하게 만듭니다.

다섯째 커뮤니티는 콘텐츠 이상의 것을 돌려줍니다. 콘텐츠는 일방향이지만, 커뮤니티는 양방향입니다. 제품 수요를 확인하고, 솔직한 피드백을 받고, 멤버 간의 이야기가 오가는 공간입니다. 팔로워 수로는 절대 얻을 수 없는 것들이죠.

지금 시작을 망설이고 있거나, 커뮤니티 관련해 궁금한 점이 있으시면 편하게 의견 남겨주세요!

*이 글의 데이터 분석과 자료 정리에 AI를 활용했으며, 초안 작성 및 수정, 퇴고는 직접 진행했습니다.

]]>

AI 에이전트와 함께 쓰는 기획/디자인 도구 6가지

아이디어 하나를 코드로 옮기는 속도는 이제 정말 빠릅니다. AI에 말로 잘 설명하면 화면이 나오고 버튼이 눌리죠. (물론 완성도는 미뤄두고요) 그런데 정작 오래 걸리는 건 그 앞 단계입니다.

무엇을 만들지 정하는 일, 그리고 그 무언가가 어떻게 생겨야 하는지 정하는 일. 이 과정을 우리는 흔히 기획과 디자인이라고 합니다. 그 작업은 꽤 어렵습니다. 코드는 틀리면 에러가 뜨지만, 기획과 디자인에는 정답 파일이 없죠. 그래서 더 힘겹습니다.

다행히 IT에서 무언가를 만들어 온 수많은 사람들이 같은 시행착오를 겪었습니다. 그리고 그 경험을 모아 이미 방법론으로 정리해뒀습니다. 게다가 최근 1년 사이, 그 방법론을 AI가 곧바로 읽고 실행하는 형태로 포장해 배포하는 도구까지 쏟아졌죠. 그중 요즘 실제로 자주 쓰이는 것들을, 접근법이 겹치지 않게 6개 정도 골랐습니다. 한번 소개해 볼게요.

아참, 이 도구들은 모두 AI 도구, 특히 클로드 코드나 코덱스 같은 코딩 에이전트를 적극적으로 쓰고 있다는 가정 하에 추천합니다.

<출처: 작가, Gemini로 생성>

거인의 어깨에 올라타기

여러분이 기획자나 디자이너라면, 필요한 단계마다 경험과 직관을 발휘해 바로바로 문제를 지적하고 개선해 나갈 수도 있습니다. 그러니 익숙한 영역은 바닥부터 시작해도 됩니다. AI와 함께 내 방식대로 만들어도 좋습니다. 문제는 아무것도 모르는 상태에서 바닥부터 하는 경우입니다.

고객들은 그런 사정을 알아주지 않습니다. 이 제품을 개발자가 만들었다고, 기획이 허술한 걸 봐줄 리가 없습니다. 기획자가 만들었으니 디자인 정도 좀 놓쳐도 괜찮아, 하는 사람도 없을 겁니다. 그렇다고 모조리 다 남들만큼 잘하라는 건 가혹합니다.

그래서 거인의 어깨에 올라타야 합니다.

기획과 디자인을 잘하기 위한 고민은 지금까지 셀 수 없이 많았습니다. 사용자 인터뷰, 요구사항 문서, 디자인 시스템 같은 것들은 전부 남이 오래 고생해 정리한 결과물이죠. 이런 방법론과 도구를 잘만 사용하면 꽤 그럴듯한 결과물을 필요에 맞게 뽑아낼 수 있습니다.

그 방법론이 AI를 위한 도구로 포장돼 배포되기 시작한 건 최근 1년 사이의 일입니다. 2025년 8월 GitHub Spec Kit, 10월 Superpowers가 차례로 나왔고, 2026년 4월에는 구글이 DESIGN.md 스펙을 공개했죠. 형태도 대부분 가볍습니다. 슬래시 명령 한 줄이거나, 프로젝트 폴더에 마크다운 파일 한 장을 두는 정도예요. 그러니 이 작업에 익숙하지 않다면 남이 쌓아온 지식을 빌리는 편이 훨씬 빠릅니다.

아이디어를 현실로 끌어내리는 기획 도구 3가지

기획이 어려운 이유는 대개 비슷합니다. 머릿속에는 만들 것이 있는데 그게 문서가 아니라 아이디어 상태로만 있다는 거죠. 이걸 에이전트에 적당한 말로 던지면 에이전트는 말하지 않은 부분을 알아서 가정하고 코드로 만들어버립니다.

그렇게 나온 결과가 점점 쌓이고 커지다 의도와 완전히 어긋나버리면, 어디서부터 어긋난 건지 되짚을 기준조차 없습니다. 기준이 될 문서가 없으니까요.

<출처: 작가, Gemini로 생성>

그래서 기획을 위한 도구들은 그 문서를 꼼꼼히 만드는 데 도움을 줍니다. 3가지 도구를 준비했습니다.

Superpowers는 기초를 닦습니다. 에이전트가 코드부터 쓰기 보다는 사용자에게 질문을 던져 스펙을 뽑아내게 만듭니다.
Spec Kit은 뼈대를 세웁니다. 어느 정도 기본 계획이 있는 기획을 정해진 단계별 문서로 굳혀, 다음 사람도 같은 순서를 밟게 만듭니다.
BMAD는 관점을 늘립니다. 문서를 다루는 에이전트를 여러 역할로 나눠, 혼자서는 놓치는 각도를 보게 만듭니다.

결국 기획은 두루뭉술한 말과 생각을 문서로 바꾸는 일이 먼저고(입구), 그 문서를 남이 읽을 수 있는 형태로 남기는 일이 그다음이고(뼈대), 관점이 더 필요할 때 역할을 늘리는 게 마지막(관점 확장)입니다. 다만, 하나하나 꽤 피곤한 일이기도 하고, 구조도 조금은 달라서 셋을 다 깔 필요는 없습니다. 지금 내 기획이 막힌 지점이 어디냐에 따라 하나만 고르면 됩니다.

1. Superpowers: 코딩 에이전트가 “먼저 물어보게” 만드는 스킬 팩

코딩 에이전트에 얹는 플러그인이자 스킬 팩입니다. 여기서 스킬 팩은 “이런 상황에서는 이렇게 일해라”를 적어둔 지시문 모음이고요. 2025년 10월 공개된 무료 MIT 라이선스 도구입니다.

Superpowers

무엇을 해주나

코드를 쓰기 전에 에이전트를 멈춰 세웁니다. 코드 요청을 받으면 바로 쓰지 않고 질문부터 던져 스펙을 뽑도록요. 그래서 이 도구가 만들어주는 건 깊이 있는 대화입니다. “다크모드 넣어줘”라고 말했을 때 곧바로 파일이 바뀌는 대신, 어디까지가 다크모드인지 되묻도록 만드는 겁니다.

어떻게 흘러가나

크게 네 단계입니다. 거친 아이디어를 질문으로 다듬고, 대안을 저울질한 결과를 설계 문서로 저장합니다. 승인이 나면 일을 2~5분짜리 태스크로 잘게 쪼갭니다. 태스크마다 건드릴 파일 경로와 검증 절차를 붙여 서브에이전트에 하나씩 넘기고요. 결과는 리뷰하며, 테스트도 강제합니다. 이 절차는 따로 부르지 않아도 상황에 맞게 알아서 발동해요.

누가 쓰면 좋나

만들 것이 말로만 있고 문서가 하나도 없는 사람. 그리고 에이전트가 알아서 코딩해버려 결과가 의도와 계속 어긋나는 사람입니다.

이럴 땐 부담이 됩니다

오타 하나 고치는 일에까지 절차가 붙으면 방해가 됩니다. 따라서 깊은 설계가 필요할 때만 불러야 합니다.
서브에이전트를 여러 개 띄우니 토큰, 즉 AI가 읽고 쓰는 글자값을 많이 씁니다.

2. GitHub Spec Kit: 기획을 다섯 단계 문서로

GitHub이 직접 낸 툴킷입니다. 코딩 전에 “무엇을 왜 만드는지”를 문서로 먼저 확정하는 스펙 주도 방식을 구현해 둔 형태로, 그 과정을 슬래시 커맨드 다섯 단계로 만들어줍니다. 2025년 9월 공개, 무료 MIT입니다.

앞의 Superpowers가 질문을 던지는 데 집중한다면, 이쪽은 그 답을 어디에 어떤 순서로 적을지 정해줍니다. 기획이 처음인 사람에게 실제로 어려운 건 “무엇을 만들까”를 생각하는 일보다, 그 생각을 어떤 문서로 어디까지 적어야 충분한지 판단하는 일이거든요. Spec Kit은 그 판단을 대신해 줍니다.

GitHub Spec Kit

어떻게 흘러가나

핵심은 다섯 단계(constitution, specify, plan, tasks, implement). 여기에 필요하면 검증용 명령을 끼워 넣을 수 있습니다. 각 단계마다 문서 하나씩을 남기니, 나중에 결과가 이상할 때 어느 단계에서 어긋났는지 되짚을 수 있습니다.

다른 도구와 다른 지점

가장 중요한 건 첫 단계입니다. 프로젝트의 원칙, 그러니까 constitution을 먼저 세우는 게 차별점입니다. “이 프로젝트에서 지킬 것”을 미리 정하고 그다음 기능을 얹는 순서입니다. 게다가 스펙에는 기술 스택을 빼고 무엇을, 그리고 왜만 담게 합니다. 어떻게 만들지를 일부러 뒤로 미루는 셈이죠. 비개발자에게는 이 제약이 오히려 편합니다. 모르는 걸 안 적어도 되니까요.

누가 쓰면 좋나

빈 폴더에서 새로 시작하는 사람. 기획을 단계로 쪼개 눈으로 확인하고 싶은 사람. 팀이나 조직에 같은 절차를 깔아야 하는 사람입니다.

이럴 땐 부담이 됩니다

이미 큰 코드베이스에 기능을 조금씩 얹는 데는 약하다는 지적이 있습니다.
반대로 작은 작업에서는 리뷰할 문서가 코드로 만드는 것보다 많아집니다. 큰 작업에나 적합합니다.

함께 참고할 것: OpenSpec

같은 스펙 주도 계열인데, 훨씬 가벼운 도구도 있습니다. OpenSpec은 문서를 의도적으로 적게 만들고 이미 돌아가는 프로젝트에 기능 하나를 얹는 상황에 맞춰져 있어요. Spec Kit이 무겁게 느껴졌거나, 새로 시작하는 게 아니라 이미 굴러가는 것에 기능을 붙이는 중이라면 이쪽을 먼저 보셔도 됩니다.

3. BMAD Method: 기획을 혼자 말고 ‘팀’에게 시키기

“코딩 어시스턴트는 구현은 잘하지만, 말하지 않은 가정을 그대로 코드로 만들어버린다.”는 문제를 푼다고 스스로 소개합니다. 앞의 둘이 문서를 만들어준다면, 이쪽은 문서를 만드는 사람들을 통째로 만들어줍니다. 정식 이름은 Breakthrough Method for Agile AI Driven Development. 무료 MIT입니다.

이 도구는 애자일 팀의 역할을 에이전트로 나눠, 애자일 방법론을 쉽게 따르게 합니다. 분석가, PM, 아키텍트, 개발, QA 같은 역할이 각자 관점을 갖고 서로에게 일을 넘깁니다.

혼자 기획하면 내가 모르는 질문은 끝까지 안 나옵니다. 역할을 나누는 이유가 그겁니다. 아키텍트 역할이 붙으면 기술 결정의 근거를 묻고 PM 역할이 붙으면 완료 기준을 묻죠. 사람이 그 질문을 떠올리지 못해도 절차가 떠올려줍니다.

BMAD Method

어떻게 흘러가나

네 단계 루프입니다. Clarify에서 막연한 아이디어를 질문으로 명확하게 만들고 Plan에서 PM·아키텍트가 PRD와 아키텍처 문서를 뽑습니다. Build and verify에서는 또 다른 에이전트가 PRD를 에픽과 스토리로 쪼개고 작은 단위로 구현·검증하고요. Learn and adjust에서 결과를 다시 Plan에 더합니다.

어떻게 쓰나

npx bmad-method install 명령어로 코딩에이전트에 설치합니다. 간단하죠. 계획 단계는 웹에서도 돌릴 수 있습니다. 구글 Gemini Gems나 ChatGPT 커스텀 GPT로 패키징된 번들로 계획만 세우고 구현은 IDE에서 잇는 방식입니다. 프로젝트 규모에 맞춰 절차를 조정하니, 작은 변경은 계획을 건너뛰고 바로 구현으로 보낼 수도 있습니다.

이럴 땐 부담이 됩니다

여러 종의 에이전트 역할과 인계 순서, CLI 명령, YAML 설정을 익혀야 합니다. 익숙해지는 데 꽤 걸리겠죠.
토큰을 많이 씁니다. 맥락을 유지하려고 주요 문서를 다시 이해해야 하는 구조기 때문입니다.
당연히 작은 프로젝트에는 과합니다. 만들 문서가 만들 제품보다 커지는 순간이 옵니다.

보기 좋고 쓰기 좋게 해주는 디자인 도구 3가지

디자인에서 막막한 부분은 기획과 다릅니다. 여기서는 결과물이 아예 안 나오는 게 아니라, 나오긴 나오는데 어딘가 이상해 보이는 게 문제입니다. AI에 화면을 맡기면 대체로 그럴듯한 게 나옵니다. 문제는 그 ‘그럴듯함’이 전부 비슷하다는 거죠. 기준을 주지 않으면 AI는 가장 무난한 기본값을 꺼내고 모두가 같은 기본값을 쓰니 결과가 거기서 거기입니다.

<출처: 작가, Gemini로 생성>

그래서 디자인 쪽 도구들은 레퍼런스를 주거나 차이를 만드는 데 집중합니다.

DESIGN.md로는 기준을 만듭니다. 색·글꼴·간격을 AI가 읽을 수 있는 파일 한 장으로 입력해, 결과에 일관성과 완성도를 부여합니다.
shadcn/ui MCP는 부품을 조달합니다. 미리 만들어진 괜찮은 컴포넌트들을 에이전트가 직접 찾아 가져오게 만듭니다.
taste-skill은 출고 전 검수를 맡습니다. 조달한 부품을 그대로 배치했을 때 남는 “AI가 만든 티”를 규칙으로 막습니다.

1. DESIGN.md: 디자인 시스템을 AI가 읽는 파일 한 장으로

디자인 시스템이라는 게 있습니다. 색·글꼴·간격·컴포넌트의 규칙을 미리 정해서, 어떤 화면을 새로 만들어도 톤이 흔들리지 않게 하는 규정집이죠. 큰 기업은 대부분 이걸 갖고 있습니다. DESIGN.md는 그 규정집을 AI가 그대로 읽을 수 있는 파일 한 장으로 만든 형식입니다. 구글 랩스가 2026년 4월 공개한 초안 스펙에 기반하며, Apache-2.0 소스입니다.

DESIGN.md

무엇을 해결하나

어떤 색이 무엇에 쓰이는지 AI가 추측하지 않게 만듭니다. 그리고 그 선택을 접근성 규칙에 대조해 검증하게 하고요. 지금까지 이 정보는 사람 머릿속이나 디자인 툴 안에 있었습니다. 그래서 화면을 하나 더 만들 때마다 같은 설명을 다시 해야 했죠. 파일로 두면 그 설명이 한 번으로 끝납니다.

생김새

파일 하나입니다. 대신 구조를 두 개로 나누었죠. 위쪽 YAML 머리말에는 기계가 읽는 값을 넣습니다. 색이나 글꼴 값에 이름을 붙여 재사용하는 단위를 토큰이라고 부르는데요, 이름과 색, 타이포, 간격 같은 값이 여기 들어갑니다. 아래쪽 마크다운 본문에는 사람이 읽는 근거를 적습니다. 왜 이 색을 골랐는지, 어디에 쓰면 안 되는지 같은 것들이죠. 파일을 프로젝트 루트에 두면 Claude Code/Cursor/Copilot 같은 에이전트가 읽습니다.

거인의 어깨에 타기

커뮤니티 플랫폼 getdesign.md에서는 유명 브랜드의 DESIGN.md 파일을 구할 수 있습니다. 다만, 이걸 그대로 쓰기보다 출발점으로 참고하는 쪽이 좋겠죠. 색과 글꼴이 이미 정해진 브랜드라면 그대로 옮기면 좋고, 감각이 전혀 없다면 좋아하는 브랜드의 파일을 참고해 루트에 한 장 두는 것부터 시작하면 됩니다.

이럴 땐 부담이 됩니다

아직 형식이 다 짜이지 않아 스펙, 토큰 스키마, CLI가 모두 바뀔 수 있습니다.
검증되는 범위는 형식으로 확인 가능한 규칙까지입니다. 톤이나 문화적 뉘앙스는 여전히 사람이 정해야 합니다.

2. shadcn/ui MCP: 무슨 컴포넌트가 있는지 에이전트가 직접 찾게

shadcn/ui는 스스로를 컴포넌트 라이브러리가 아니라 “코드 배포 플랫폼”이라고 규정합니다. 설치하면 라이브러리에 의존하는 대신 컴포넌트 코드가 내 프로젝트 안으로 들어와 직접 고칠 수 있죠. 무료 MIT입니다.

shadcn/ui MCP

무엇을 해결하나

가장 강력한 건 컴포넌트를 검색해 쓸 수 있다는 겁니다. MCP는 에이전트가 외부 도구를 불러 쓰는 규격인데, 이 서버가 shadcn/ui CLI에 들어 있습니다. 일을 시키면 에이전트가 컴포넌트 목록 저장소인 레지스트리를 직접 검색/조회하고 설치 명령까지 받아옵니다.

공식 문서의 예시 표현은 이렇습니다. 설정된 레지스트리 전체에서 “히어로 하나 찾아줘”라고 하면, 적합한 걸 가져옵니다. 무슨 부품, 즉 컴포넌트들이 있는지 몰라 첫 화면조차 못 만들던 걸 해소해 줍니다. 필요한 걸 말로 부르면 되니까요.

‘AI가 만든 티’의 주범

다만, “AI가 만든 티”의 대표 사례로 가장 자주 지목되는 게 바로 shadcn/Tailwind 기본 외형이에요. 아무래도 비슷한 걸 조달하다 보니, 차별화가 또 어렵습니다. 부품을 쉽게 가져올 수 있다는 건, 남들도 같은 부품을 같은 기본값으로 가져왔다는 뜻이니까요.

그래서 여기서부터는 취향이 필요합니다.

3. taste-skill: “AI가 만든 티”를 규칙으로 금지하기

에이전트에 설치하는 스킬입니다. 스스로를 “AI 에이전트를 위한 안티 슬롭 프론트엔드 프레임워크”라고 부르죠. 만들어주는 게 아니라, 만들 때 하면 안 되는 것을 규칙으로 처리하는 쪽입니다. 무료 MIT이고 Codex/Cursor/Claude Code 등에서 씁니다.

taste-skill

어떻게 해결하나

화면을 그리기 전에 값부터 정하게 하는 방식이에요. 랜딩 페이지와 대시보드는 필요한 값이 다르죠. 그 값을 근거와 함께 먼저 적게 하는 게 이 스킬의 핵심입니다. 취향을 감으로 두지 않고 숫자로 명시합니다.

예를 들어, DESIGN_VARIANCE는 배치를 얼마나 흔들지(1은 완벽한 대칭, 10은 실험적 구성), MOTION_INTENSITY는 움직임의 강도(1~3은 정지, 8~10은 스크롤 연동 애니메이션), VISUAL_DENSITY는 정보 밀도(낮으면 여백 위주, 높으면 대시보드처럼 빽빽하게) 같은 것들을 정합니다.

금지 목록으로 AI 티 막기

“AI 티”로 읽히는 패턴에 이름을 붙여 못 쓰게 합니다.

가운데 정렬 히어로를 기본값으로 쓰지 않기
똑같이 생긴 카드 세 장을 가로로 늘어놓지 않기
이미지+텍스트 좌우 교차 배치를 세 번 연속 쓰지 않기
대문자 라벨은 세 섹션당 한 개까지, 흐르는 텍스트(마키)는 페이지당 한 개까지
보라색 네온 글로우, 근거 없는 수치(92%·4.1배 같은 것), “John Doe” 같은 가짜 이름 금지

만든 화면이 “어디서 본 것 같다”는 반응을 받은 사람, 특히 랜딩 페이지·포트폴리오처럼 첫인상이 전부인 화면을 만드는 경우에 효과가 큽니다.

이럴 땐 부담이 됩니다

기본 스킬이 아직 실험 버전(v2)이라 규칙이 계속 바뀝니다.
금지 목록이 곧 저자의 취향이기도 합니다. 세리프 글꼴을 기본값으로 쓰지 말라는 조항처럼, 내 브랜드와 맞서는 규칙이 있으면 지워야 합니다.
색·모서리 반경 같은 테마 값만 빠르게 바꾸고 싶은 거라면 과합니다.

전부 다 깔 필요는 없습니다

여기까지 읽고 전부 설치하고 쓰기로 마음먹었나요? 사실 그건 이 도구들을 가장 잘못된 방법으로 쓰는 겁니다. 함께 말해둘 게 두 가지 있습니다.

도구가 겹칠수록 결과가 나빠질 수 있습니다. 그러니 전부 쓰기보다 필요한 부분만 골라 쓰는 편이 낫습니다. 각자가 추구하는 방식이 조금씩 다르기에 만드는 결과물도 다르거든요. Spec Kit의 constitution 개념만 쓰고 실제 스펙은 OpenSpec으로 쓴다거나, BMAD를 통째로 쓰지 않고 필요한 스킬만 로컬 .claude 폴더에 복사하면 전체 결과가 어긋나는 식이죠.

비용은 토큰과 리뷰할 문서량입니다. 계획 하나에 10만 토큰을 봤다는 후기가 있는가 하면, 프로젝트 전체로 보면 스펙 주도가 오히려 싸게 먹힌다는 반박도 있어요. 디자인에서도 어쨌든 AI가 참고할 것이 늘어나니, 작업량이 많아집니다. 물론, 이런 걸 써야 시행착오가 줄어들어 오히려 절약된다는 주장도 있습니다. 어느 쪽도 아직 단정할 수 없습니다. 확실한 건 문서가 늘면 사람이 읽어야 할 양도 는다는 것입니다. 흔히들 말하는 ‘바이브’를 즐길 수 없게 될지도 모릅니다.

마치며

기획과 디자인을 신경 쓰지 않은 상태에서 ‘딸깍’만으로 제대로 된 결과물이 나오는 건, 마치 벼락을 맞을 확률과 비슷할 겁니다. 어찌저찌 돌아가기는 하겠지만, 정작 만든 자기 자신을 비롯해 그 누구도 쓰지 않을 가능성이 크죠. 돌아가는 것과 쓸 만한 것 사이의 거리는 큰 법입니다.

결국 이 모든 과정은 “고객”, 즉, 실제로 쓸 사람을 신경 쓰는 데서 출발합니다. 내가 만든 이 ‘무언가’를 쓰는 사람은 누구인지, 그 사람은 왜 이걸 써야 하는지 이해하는 데 시간을 들여보세요. 그보다 좋은 기획과 디자인의 출발은 없습니다.

6가지 도구들이 어깨는 빌려줄 겁니다. 다만 누구를 위해, 왜 만드는지는 어느 파일에도 적혀 있지 않습니다.

]]>

23년 동안 살아남은 동네슈퍼를 데이터로 분석해봤습니다

저희 부모님은 23년째 동네 슈퍼마켓을 운영하고 계십니다. 그 덕에 저는 어릴 때부터 아버지를 따라 세무서, 회계사무소, 구청, 물류도매센터를 다니며, 유통과 장사의 뒷면을 지켜볼 수 있었습니다. 제조사·대리점·영업사원 사이에 얽힌 인센티브 구조, 같은 규정도 담당자에 따라 다르게 해석되던 행정 처리, 작은 창고 하나에서 시작해 공장까지 세운 납품업체의 성장 과정까지, 그 모든 장면이 결국 하나의 시스템이었다는 걸 시간이 지나 깨닫게 됐습니다.

이런 경험은 중학생 때 직접 사업자등록을 내고 작은 온라인 판매를 해본 것으로 이어졌는데요. 지금은 해군 복무 중 LLM, RAG, 온톨로지를 공부하며 "이 기술을 어디에 써야 할까"라는 질문에 도달했습니다. 그리고 그 답을 가장 가까운 현장, 부모님 가게에서 찾아보기로 했습니다.

이번 글에서는 부모님이 운영하고 계신 나들가게 POS 데이터를 실제로 들여다보는 과정을 정리했습니다. 거창한 AI 대시보드가 아니라, 데이터를 정리하고 기본 지표(일별·시간대별 매출, 상품별 판매량, 객단가)를 뽑아보는 것부터 시작했는데요. 최근 화제가 된 클로드(Claude)의 페이블 5를 사용해보게 됐습니다.

<출처: 작가>

페이블 5는 앤트로픽이 장시간 이어지는 복잡한 코딩과 에이전트 작업을 위해 내놓은 상위 모델입니다. 한동안 접근이 제한됐다가 한시적으로 다시 사용할 수 있게 됐습니다(2026년 7월 12일까지). 일상적인 개발에서는 다시 오푸스(Opus)를 주로 쓰게 될 가능성이 커서, 사용할 수 있을 때 제대로 한번 써보고 싶었습니다.

써본 소감은 아주 단순했습니다. 확실히 프런티어 모델은 알잘딱깔센을 잘했습니다.

제가 모든 버튼과 간격, 상태 처리 방식을 하나하나 지시하지 않아도 됐습니다. 모델이 기존 코드와 화면을 확인하고, 원하는 방향을 어느 정도 추론한 뒤 결과물을 만들어냈습니다. 물론 모델이 제품의 방향까지 대신 결정해준 것은 아닙니다.

어떤 데이터를 남길 것인지, 과거 데이터와 현재 데이터를 어떻게 구분할 것인지, 무엇을 가장 먼저 보여줄 것인지, 이 서비스가 결국 어떤 의사결정을 도와야 하는지는 여전히 제가 판단해야 했습니다.

부모님은 23년 동안 동네 슈퍼마켓을 운영하셨고, 저는 가게에 쌓인 데이터를 꺼내 단순한 매출표가 아니라, 실제 운영자가 더 나은 결정을 내릴 수 있는 시스템을 만들어보고 싶었습니다. POS 데이터와 상품, 시간대, 거래처, 결제수단, 재고, 날씨, 상권을 연결하고, 나중에는 온톨로지와 LLM을 활용해 숫자 너머의 맥락까지 보고 싶었죠. 그런데 프로젝트를 실제로 시작하면서 가장 먼저 알게 된 것이 있습니다.

AI를 붙이는 것보다 먼저 해야 할 일이 있었습니다. 바로 ‘데이터’부터 꺼내야 했습니다.

엑셀도 API도 없다면, 브라우저가 대신 읽게 하자

처음에는 간단하게 생각했습니다. POS 사이트에서 조회한 자료를 엑셀로 내려받고, 파이썬(Python)이나 판다스(Pandas)로 정리하면 되지 않을까?

하지만 실제로 확인해보니 엑셀 추출이 되지 않았습니다. 화면에서는 월매출, 일별 거래건수, 객단가, 현금매출과 카드매출 같은 데이터를 볼 수 있었습니다. 다만 그 데이터를 분석 가능한 파일로 내려받는 기능은 사실상 쓸 수 없었습니다.

API 문서도 찾을 수 없었습니다. 결국 선택지는 하나였습니다. 사람이 화면에서 읽을 수 있다면, 브라우저가 대신 읽게 해보자.

나들가게 POS는 생각보다 오래된 시스템이었습니다.

공식 안내를 보면 나들가게 POS는 판매와 반품뿐 아니라 상품관리, 재고관리, 영업관리, 정산과 마감까지 다루는 시스템입니다. 별도의 경영분석시스템도 POS 판매기록을 바탕으로 매출과 이익, 방문객 수, 일·월 영업실적 등을 보여주도록 설계되어 있습니다.

데이터가 없었던 것은 아니었습니다. 오히려 필요한 데이터는 이미 상당 부분 존재했습니다. 문제는 그 데이터가 오래된 웹 화면 안에 흩어져 있고, 외부에서 쉽게 사용할 수 있는 형태로 열려 있지 않았다는 점이었습니다.

기존 화면은 오래된 GWT(Google Web Toolkit) 기반 웹 애플리케이션 형태였고, 메뉴와 프레임, 조회 결과가 여러 단계로 나뉘어 있었습니다.

<출처: 나들가게 POS, 작가 캡처>

그래서 클로드(Claude)와 코덱스(Codex)를 활용해 HTML 구조와 프레임을 하나씩 확인하고, 로그인부터 메뉴 이동, 조회, 테이블 파싱까지 브라우저가 자동으로 수행하게 만들었습니다.

아이디와 비밀번호 입력 → 로그인 → 영업분석 메뉴 이동 → 월매출 캘린더 조회 → 셀 데이터 수집

첫 번째 목표는 이것뿐이었습니다. 그리고 결국 월매출 캘린더의 데이터를 가져오는 데 성공했습니다.

<출처: 나들가게 POS, 작가 캡처>

처음 데이터를 가져오는 데 약 40초가 걸렸습니다.

40초를 5초로 줄이기까지

처음에는 성공했다는 사실만으로도 만족했습니다. 그런데 새로고침을 한 번 할 때마다 40초 가까이 기다려야 했습니다. 테스트 한 번은 괜찮았지만, 실제 서비스라면 쓸 수 없는 속도였습니다. 로그를 나눠서 확인해보니 사이트가 원래 느린 것 외에도, AI가 만든 크롤러 안에 불필요한 낭비가 꽤 많았습니다.

<출처: 작가>

가장 큰 문제는 이중 로그인이었습니다. 한 번 로그인한 뒤 바로 메뉴를 클릭하면 되는데, 캘린더 주소로 직접 접근하면서 로그인 페이지로 되돌아가고 있었습니다. 그 결과 로그인과 GWT 초기화가 두 번씩 발생했습니다.

셀을 읽는 방식도 비효율적이었습니다. 화면에 있는 약 400개의 셀을 하나씩 파이썬으로 가져오면서 브라우저와 수백 번 통신하고 있었습니다. 이를 frame.evaluate 한 번으로 모든 셀의 텍스트를 묶어서 가져오는 방식으로 바꿨습니다.

스크린샷과 HTML 저장도 실패했을 때나 디버깅이 필요할 때만 실행하도록 바꿨습니다. 브라우저와 로그인 세션은 계속 살려뒀습니다. 새로고침을 누르면 다시 로그인하는 대신 이미 열린 세션에서 조회 버튼만 누르고 데이터를 읽도록 했습니다. 세션이 만료된 경우에만 자동으로 초기화하고 한 번 다시 시도하게 했습니다.

마지막으로 배경 예열을 추가했습니다. 서비스가 시작되면 데이터를 미리 가져오고, 기본 10분마다 다시 갱신해 캐시를 채우도록 했습니다.

그 결과 속도는 다음과 같이 줄었습니다.

캐시된 일반 접속: 거의 즉시
수동 새로고침: 약 5초
최초 배포 후 콜드 스타트: 약 15초
기존 방식: 약 40초
그런데 속도를 줄이고 나니 또 다른 문제가 보였습니다.

바뀌지 않는 데이터를 왜 매번 다시 조회해야 할까?

2012년 1월 매출을 조회한다고 가정해보겠습니다. 처음 조회할 때 오래 걸리는 것은 어느 정도 이해할 수 있습니다. 하지만 같은 달의 데이터를 며칠 뒤 다시 보고 싶을 때도, 또 오래된 POS에 로그인하고 또 같은 화면을 불러오고 또 같은 데이터를 크롤링해야 했습니다. 이상했습니다. 2012년 1월 매출은 더 이상 바뀌지 않습니다. 지난달 데이터도 마감이 끝났다면 바뀔 가능성이 거의 없습니다.

그런데 왜 볼 때마다 원본 POS를 다시 조회해야 할까? 그래서 데이터 구조를 바꾸기로 했습니다. 과거 데이터는 한 번 가져오면 데이터베이스에 저장하고, 현재 진행 중인 달만 다시 조회하는 방식입니다.

Supabase에 monthly_sales, daily_sales 등의 테이블을 만들었습니다. 월별 총매출, 거래건수, 객단가, 일평균 매출, 반품 건수와 금액, 수집 시각, 월 마감 여부를 저장했습니다. 현재 달은 계속 변하므로 새로고침할 때 POS에서 다시 가져옵니다.

반면, 이미 끝난 달은 Supabase에서 즉시 읽습니다.

나들가게 POS
    ↓
브라우저 자동화·크롤링
    ↓
데이터 정규화
    ↓
Supabase 저장
    ↓
새로운 조회·분석 UI

기존 POS는 여전히 원천 시스템입니다. 제가 만든 서비스는 운영 데이터를 수정하지 않고, 그것을 가져와 조회와 분석에 적합한 형태로 저장하는 새로운 읽기 계층입니다. 그리고 2011년 7월, 부모님 가게에 POS가 처음 도입된 시점부터 월별 데이터를 순차적으로 가져와 저장했습니다.

가게 자체의 역사는 23년이지만, 디지털로 남은 매출의 역사는 약 15년입니다.

<출처: Supabase, 작가 캡처>

이제 2012년 1월을 보든, 2018년 6월을 보든 매번 오래된 POS를 다시 기다릴 필요가 없습니다. 한 번 가져온 과거 데이터는 데이터베이스에서 바로 불러옵니다. 이 결정 하나로 서비스의 성격이 바뀌었습니다. 이전에는 오래된 POS 화면을 대신 열어주는 크롤러였다면, 이제는 매장의 역사를 자체적으로 보관하고 조회하는 서비스가 됐습니다.

조회할 수 있는 화면에서 이해할 수 있는 화면으로

데이터를 가져온 뒤에는 화면도 다시 만들었습니다. 기존 POS에도 필요한 숫자는 있었습니다. 문제는 정보가 너무 많은 표와 메뉴 안에 흩어져 있다는 점이었습니다. 월매출을 보려면 월매출 캘린더를 열어야 하고, 날짜를 누르면 오른쪽에 세부 결제수단이 나옵니다. 지난달과 비교하려면 다른 화면을 열어야 하고, 월별 흐름을 보려면 숫자를 직접 기억하거나 옮겨 적어야 했습니다.

기존 화면이 틀렸다는 의미는 아닙니다. 당시의 업무 환경에서는 많은 기능을 한 화면에 제공하는 것이 중요했을 것입니다. 하지만 제가 만들고 싶은 서비스의 목적은 달랐습니다. “조회할 수 있는 화면”보다 “빠르게 이해할 수 있는 화면”이 필요했습니다.

그래서 토스증권의 정보 구조를 참고했습니다. 토스증권은 모든 숫자를 한꺼번에 보여주기보다, 사용자가 현재 가장 궁금해할 정보부터 위계를 만들어 보여줍니다. 제가 만든 화면도 같은 원칙으로 다시 구성했습니다.

상단에는 이번 달 총매출을 가장 크게 배치했습니다. 바로 아래에는 전월 대비 변화, 거래건수, 객단가, 일평균 매출, 최고 매출일을 두었습니다. 그다음에는 일별 매출 그래프와 최근 6개월·12개월 흐름을 배치했습니다. 아래에는 현금매출, 카드매출, 포인트매출 등 결제수단의 구성을 정리했습니다.

현재 진행 중인 달은 완료된 달과 구분해 진행 중 상태로 표시했습니다. 아직 끝나지 않은 달을 전월과 단순 비교하면, 큰 폭으로 하락한 것처럼 오해할 수 있기 때문입니다.

<출처: 작가>

단순히 색상을 바꾸고 카드 형태로 만든 것은 아닙니다. 사용자가 숫자를 이해하는 순서를 다시 설계했습니다.

지금 매출이 얼마인가?
지난달보다 올랐는가?
거래건수와 객단가 중 무엇이 변했는가?
어느 날 매출이 높았는가?
최근 흐름은 상승인가 하락인가?
어떤 결제수단으로 매출이 발생했는가?

기존 POS의 메뉴와 표를 그대로 복사하지 않고, 사용자의 질문을 기준으로 정보를 다시 배열했습니다.

동네슈퍼에서 해본 아주 작은 차세대 프로젝트

만들고 보니 아주 작은 ‘차세대 프로젝트’ 같았습니다. IT 업계에서 차세대 프로젝트라는 말을 자주 사용합니다. 오래된 ERP나 업무 시스템을 새로운 데이터 구조와 화면, 인프라로 다시 만드는 프로젝트를 의미합니다.

제가 한 일이 기업 단위의 거대한 차세대 프로젝트와 같다고 말할 수는 없습니다. 하지만 구조는 꽤 닮아 있었습니다.

오래된 시스템은 원천 시스템으로 유지하고
필요한 데이터를 새롭게 수집하고
새로운 데이터베이스에 표준화해 저장하고
조회 성능을 개선하고
현대적인 사용자 경험으로 재구성했습니다.

작은 동네 슈퍼마켓을 대상으로 한 아주 작은 레거시 현대화 프로젝트였던 셈입니다.

코드를 쓰는 비용이 낮아지면 무엇이 남을까?

이 작업을 하면서 기존에 ERP, MES(제조실행시스템), 관리자 대시보드를 구축해온 업체들의 해자가 예전보다 많이 낮아질 수 있겠다는 생각도 들었습니다. 과거에는 오래된 시스템을 분석하고, 별도의 데이터베이스와 화면을 만들고, 자동화 코드를 작성하려면 상당한 개발 인력과 비용이 필요했습니다.

지금은 클로드 코드(Claude Code)나 코덱스 같은 도구를 쓸 수 있습니다. 기존 HTML을 분석하고, 크롤러를 만들고, 데이터베이스 스키마를 설계하고, 프런트엔드를 구현하는 데 드는 비용과 시간이 크게 줄었습니다.

물론 모든 해자가 사라지는 것은 아닙니다. 실제 현장을 이해하고, 데이터의 의미를 정의하고, 기존 시스템과 안정적으로 연결하고, 장애와 예외를 관리하는 역량은 여전히 중요합니다.

오히려 코드를 작성하는 비용이 낮아질수록 이런 판단 역량이 더 중요해질 것 같습니다. “어떻게 개발할 것인가”보다, “무엇을 왜 만들어야 하는가”가 더 큰 차이가 되는 것입니다.

15년치 데이터가 보여준 변화

2011년의 데이터를 열어보니, 매출표가 아니라 시간의 기록처럼 보였습니다.처음에는 월별 숫자를 저장하는 것만 생각했습니다. 그런데 2011년과 2012년 데이터를 실제로 조회해보니 예상보다 훨씬 많은 질문이 생겼습니다.

2012년 1월의 객단가는 5,566원이었습니다. 최근에는 대체로 9,000원 안팎까지 올라와 있습니다.

<출처: 작가>

2012년에는 현금매출이 압도적으로 많았고, 카드매출의 비중은 훨씬 작았습니다.

<출처: 작가>

지금은 반대입니다. 카드와 각종 전자결제가 매출의 대부분을 차지합니다. 한 가게의 데이터 안에 한국 사회의 결제 방식 변화가 그대로 남아 있었습니다. 객단가가 5,000원대에서 9,000원대로 오른 것도 흥미로웠습니다. 물론 이것을 단순히 “물가가 올랐기 때문”이라고 단정할 수는 없습니다.

상품 가격의 상승도 영향을 줬겠지만, 상품 구성과 고객층, 한 번에 구매하는 물품 수, 주변 경쟁점, 소비 습관도 함께 바뀌었을 수 있습니다. 그렇기 때문에 오히려 다른 데이터를 연결할 필요가 생깁니다.

소비자물가지수
품목별 가격 변화
날씨와 기온
공휴일과 요일
지역 지원금 지급 시기
주변 편의점과 대형마트의 개업일
인근 상권 변화
가게의 가격과 진열 변경

2020년, 재난지원금이 지급된 뒤 매출이 눈에 띄게 올랐던 시기가 있었습니다. 주변에 편의점이 생긴 뒤 매출이 크게 떨어졌던 기억도 있습니다. 지금까지는 부모님의 기억으로만 남아 있던 사건입니다. 하지만 15년치 월별·일별 데이터를 확보하면 실제 변화가 발생한 날짜를 찾을 수 있습니다. 지원금 지급 전후로 거래건수와 객단가가 어떻게 변했는지, 편의점 개점 이후 어떤 품목과 시간대의 매출이 먼저 떨어졌는지 확인할 수 있습니다.

이때부터 데이터는 단순한 매출표가 아니라, 현장의 사건과 연결되는 기록이 됩니다.

숫자만으로는 보이지 않는 현장의 구조

숫자만 많다고 현장을 이해하는 것은 아닙니다. 기존의 회귀분석이나 머신러닝으로도 매출과 날씨, 요일, 가격 사이의 상관관계를 찾을 수 있습니다. 하지만 숫자만 놓고 보면 그 사이에 숨어 있는 현장의 구조를 놓치기 쉽습니다.

예를 들어, 편의점이 생긴 뒤 매출이 떨어졌다고 해도, 모든 상품이 똑같이 영향을 받은 것은 아닐 것입니다. 편의점이 강한 담배, 음료, 간편식이 먼저 영향을 받았을 수 있습니다. 반대로 대용량 생필품이나 동네 단골이 외상으로 구매하던 상품은 영향을 덜 받았을 수도 있습니다.

정책지원금이 풀린 뒤 매출이 올랐다고 해도, 단순히 손님이 많아진 것인지, 기존 고객의 객단가가 올라간 것인지, 특정 상품군에만 소비가 집중된 것인지 나눠봐야 합니다.

숫자만 보면 매출 상승입니다. 현장의 구조를 연결하면 다음처럼 바뀝니다.

정책지원금 지급

→ 특정 결제수단 사용 증가

→ 기존 고객의 객단가 상승

→ 생필품과 고단가 상품 판매 증가

→ 월매출 증가

또는 다음과 같을 수도 있습니다.

인근 편의점 개점

→ 야간·출근시간 고객 이동

→ 담배·음료 거래건수 감소

→ 전체 고객수 감소

→ 월매출 하락

온톨로지로 담고 싶은 세 계층

제가 온톨로지에 관심을 갖는 이유도 여기에 있습니다. 온톨로지는 단순히 그래프를 멋지게 그리는 기술이 아닙니다. 상품과 카테고리, 거래처, 결제수단, 시간, 날씨, 정책, 경쟁점, 매장의 의사결정을 서로 연결해 현장의 구조를 표현하는 방법입니다. 저는 앞으로 이 구조를 세 계층으로 만들고 싶습니다.

첫 번째는 매장의 기본 개체입니다.

상품, 카테고리, 거래처, 결제수단, 날짜, 시간대, 고객군

두 번째는 실제 발생한 사건입니다.

판매, 반품, 가격 변경, 지원금 지급, 경쟁점 개점, 비와 폭염

세 번째는 가게의 의사결정입니다.

무엇을 더 발주할지, 가격을 바꿀지, 어디에 진열할지, 어떤 상품을 묶어 팔지

이 세 계층이 연결돼야 단순히 “무슨 일이 있었는가”를 넘어서 “왜 그랬고, 다음에는 무엇을 바꿀 것인가”에 답할 수 있다고 생각합니다.

조직에 맞는 AX는 무엇부터 구조화해야 할까?

이 프로젝트를 하면서 AX에 대해서도 다시 생각하게 됐습니다. 최근 많은 기업과 조직이 AX를 이야기합니다. 문서를 요약하고, 사내 자료를 검색하고, 회의록을 정리하는 AI를 도입합니다.

이런 기능도 분명히 유용합니다. 하지만 단건의 문서 요약이나 검색만으로 조직이 AI 네이티브로 바뀌었다고 보기는 어렵습니다.

진짜 조직에 맞는 AX를 하려면, 그 조직이 실제로 어떻게 판단하고 움직이는지를 먼저 구조화해야 한다고 생각합니다.

어떤 단계로 업무가 진행되는가
누가 어떤 시점에 판단하는가
어떤 데이터와 규정을 참고하는가
정상적인 경우와 예외적인 경우는 무엇인가
문서에는 없지만 구성원들이 당연하게 여기는 가정은 무엇인가
의사결정 결과가 다음 단계에 어떤 영향을 미치는가
이런 암묵지와 의사결정 구조가 워크플로에 담겨 있어야 합니다.

LLM은 학습 과정에서 역전파를 통해 방대한 언어 패턴을 익히고, 실제 생성 과정에서는 주어진 문맥을 바탕으로 다음 토큰의 확률 분포를 계산해 결과를 만듭니다. 이 방식은 매우 강력하지만, 조직 고유의 맥락이 없으면 자연스럽게 일반적이고 평균적인 답변으로 흐를 수 있습니다. 다음 토큰 예측은 현대 언어모델의 핵심 학습·생성 구조지만, 그것만으로 특정 조직의 규칙과 예외, 책임 구조가 자동으로 생기는 것은 아닙니다.

<출처: X, @akshay_pachaar>

그래서 AI에 문서만 많이 넣는다고 우리 조직에 맞는 AI가 만들어지는 것은 아닙니다. 우리 조직의 개체와 관계, 이벤트, 규칙, 예외, 의사결정 단계를 먼저 정리해야 합니다. 그 위에서 AI가 워크플로를 따라 움직여야 합니다.

조직이 AI의 방식에 맞추는 것이 아니라, AI가 조직의 실제 구조를 이해하고 따라가게 만들어야 합니다. 동네 슈퍼마켓 프로젝트는 아주 작은 사례지만 본질은 비슷합니다. 단순히 POS 매출표를 LLM에 넣고 “인사이트를 알려줘”라고 하면 그럴듯한 말은 만들 수 있습니다.

하지만 왜 특정 상품을 계속 취급했는지, 거래처와 어떤 조건으로 거래했는지, 편의점이 언제 들어왔는지, 특정 정책이 어떤 고객에게 영향을 줬는지는 알기 어렵습니다. 이런 맥락을 모르면 현장에 맞는 판단을 내릴 수 없습니다.

결국 AI보다 먼저 필요한 것은 조직과 현장의 구조입니다.

아직 이 프로젝트에 AI가 없다

아직 이 프로젝트에는 AI가 거의 없습니다. 현재까지 가져온 데이터는 나들가게 POS의 월매출 캘린더 정보가 중심입니다.

지금 볼 수 있는 것은 다음 정도입니다.

월별 총매출
월별 거래건수
객단가
일평균 매출
일별 매출
현금매출
카드매출
포인트매출
최근 6개월과 12개월 흐름

아직 상품별 판매 데이터도 충분히 가져오지 못했습니다. 카드사별 매출, 카테고리별 매출과 이익, 거래처별 상품, 재고와 발주 데이터도 추가해야 합니다. 그래프 데이터베이스도 없습니다. 온톨로지도 아직 만들지 않았습니다. LLM에 자연어로 질문하는 기능도 없습니다.

그렇지만 저는 지금 단계가 중요하다고 생각합니다. AI를 붙이기 위한 가장 기본적인 토대를 만들었기 때문입니다. 데이터가 어디에 있는지 확인했고, 사람이 화면을 열지 않아도 자동으로 가져올 수 있게 만들었습니다. 변하지 않는 과거 데이터를 데이터베이스에 쌓았고, 사용자가 빠르게 이해할 수 있는 화면으로 다시 구성했습니다.

앞으로는 여기에 하나씩 데이터를 붙여갈 생각입니다. 먼저 상품별 매출과 이익, 카테고리와 거래처 데이터를 가져옵니다. 그다음 날씨와 공휴일, 물가, 상권, 정책 데이터를 연결합니다. 이후 상품, 거래처, 시간, 외부 사건, 운영 의사결정을 그래프와 온톨로지로 구조화합니다.

마지막에 LLM을 붙이려고 합니다. LLM이 숫자를 직접 계산하고 근거 없이 판단하게 하려는 것은 아닙니다. 구조화된 데이터와 규칙, 과거 실험 결과를 바탕으로 설명하고 다음 행동을 제안하게 만들고 싶습니다.

AI는 마지막입니다. 먼저 현장을 담아야 합니다.

마치며

이번 단계에서 제가 한 일은, 어쩌면 데이터를 구출한 것에 가깝습니다. 가게에는 이미 15년치 디지털 기록이 있었습니다. 하지만 그 데이터는 오래된 POS 화면을 한 달씩 넘겨보지 않으면 볼 수 없었습니다.

한 번 본 과거 데이터를 다시 보기 위해 또 로그인하고, 또 기다리고, 또 조회해야 했습니다. 저는 그 데이터를 꺼내 데이터베이스에 쌓고, 다시 빠르게 볼 수 있는 화면을 만들었습니다. 아직 이 시스템은 제가 최종적으로 만들고 싶은 의사결정 도구가 아닙니다.

지금은 토대에 가깝습니다. 하지만 이제 최소한 2011년의 가게와 2026년의 가게를 같은 화면에서 비교할 수 있습니다. 현금 중심의 매장이 카드 중심의 매장으로 바뀐 과정도 볼 수 있습니다. 객단가가 5,000원대에서 9,000원대로 이동한 과정도, 부모님의 기억 속에 있던 사건을 실제 날짜와 숫자로 다시 확인하는 일도 가능합니다.

1편에서는 이런 질문을 했습니다. 부모님 가게는 어떻게 23년 동안 망하지 않고 살아남았을까? 아직 답을 찾지는 못했습니다. 다만 이제 그 질문에 답할 수 있는 데이터를 처음으로 한곳에 모으기 시작했습니다. 그리고 다음 단계에서는 단순히 매출이 오르고 내린 것을 보는 것을 넘어, 어떤 상품과 거래처, 어떤 시간대와 외부 사건이 그 변화에 영향을 줬는지 연결해보려고 합니다.

데이터가 없었던 것이 아니었습니다. 오래된 화면 안에 갇혀 있었을 뿐입니다.

이번에는 그 데이터를 꺼냈습니다. 이제부터는 그 데이터에 현장의 맥락을 연결해 보려고 합니다.

<원문>

23년 동안 살아남은 동네슈퍼를 데이터로 분석해보려 합니다. (2편)

]]>

젠스파크가 녹음기 만든 이유: 워크스페이스 6.0 사용기

젠스파크가 녹음기를 만들었다. 지난 7월 24일 서울 광진구 본다빈치뮤지엄 능동에서 열린 미디어 데이에서 차세대 AI 워크스페이스 6.0을 공개하면서, 이 신용카드 크기의 AI 녹음 디바이스 ‘세컨드브레인 노트’도 함께 선보였다. 녹음도 텍스트 전환도 요약도 스마트폰으로 이미 충분히 되는데, 업무용 에이전틱 AI를 만드는 소프트웨어 회사가 하드웨어를 내놓은 이유는 뭘까.

이날 젠스파크가 미디어 데이에서 핵심으로 내세운 것은 '세컨드브레인'이다. 이메일과 캘린더, 노션과 구글 워크스페이스에 흩어진 업무 정보를 하나의 지속형 메모리로 묶어, 작업이 끝나면 맥락이 끊기던 문제를 겨냥했다. 이메일 에이전트 '젠메일', 디자인 에이전트 'AI 디자인', 역할별 AI 에이전트와 함께 일하는 '젠팀'이 이 메모리를 쓰는 제품들이고, 하드웨어도 같은 맥락이다. 화면 밖 회의와 대화까지 메모리에 넣기 위한 입력 장치다.

나는 젠스파크 유료 사용자였다. 맥락 기반으로 여러 워크플로우를 한 번에 처리한다는 강점에 결제했지만, 모델 제공사들의 LLM 성능이 올라가면서 결국 발표용 슬라이드를 만들고 다운로드 받는 정도에 그쳤다. 채팅창 하나로 되는 일에 굳이 다른 창을 열 이유가 없었다. 그래서 이날 가장 궁금했던 것은 “다시 결제할 이유가 생겼을까”였다.

이 글에서는 미디어데이에서 공개된 내용과 함께, 세컨드브레인 노트와 AI 디자인, 젠팀을 며칠간 써본 경험을 정리했다. 기기는 미디어데이 현장에서 대여했다.

2026년 7월 24일 광진구 능동 본다빈치뮤지엄에서 열린 젠스파크 미디어데이에서 AI 워크스페이스 6.0을 발표하고 있는 에릭 징 젠스파크 공동창업자 겸 최고경영자(CEO) <출처: 젠스파크>

세컨드브레인 노트: 회의실 대화를 노린 하드웨어

이미 스마트폰으로도 녹음할 수 있는데, 왜 굳이 녹음 기능을 가진 하드웨어였을까? 공식 블로그에서는 이를 "세컨드브레인의 귀"라고 표현한다. 이미 문서로 남은 정보는 커넥터로 끌어올 수 있지만, 결정이 실제로 내려지는 회의실 안의 대화는 어디에도 남지 않는다는 문제의식이다.

하드웨어 사양에도 그 의도가 보인다. 신용카드 크기에 두께 2.95mm, 무게 26g이다. 맥세이프 자석으로 스마트폰 뒷면에 붙이거나 카드 지갑에 꽂아두는 형태다. 버튼을 2초간 누르면 표시등이 켜지며 녹음이 시작되고, 한 번 충전으로 최대 35시간 연속 녹음한다. 4개의 MEMS 마이크가 카드 상단과 좌우에 배치되고 내부에 진동전도센서가 하나 더 들어간다. 젠스파크는 AI 빔포밍으로 약 5미터 거리의 목소리까지 잡고 시끄러운 환경에서도 화자를 구분할 수 있다고 설명한다. 한 사람의 통화에 맞춰 설계된 스마트폰 마이크와는 겨냥하는 상황이 다르다는 것이다.

젠스파크 세컨드브레인 노트 실제 모습 <출처: 작가>

개인적으로는, 매끈한 카드가 손에 착 닿는 순간 의구심이 감탄으로 바뀌었다. 얇고 가볍다! 휴대성은 물론 접근성과 직관적인 사용성도 뛰어났다. 지금은 카드 지갑 한 칸을 차지하고 있다.

버튼 하나가 줄여주는 것

AI 녹음 요약의 수요는 이미 검증됐다. 나도 네이버의 '클로버노트'와 사내 LLM인 '아이멤버Chat AI 회의록' 기능을 번갈아 쓴다. 스카이워크 노트(Skywork Note AI)나 플라우드 노트(Plaud Note) 같은 선행 하드웨어 제품들도 있다. 그래도 왜 굳이 별도 기기였을까 궁금할 수 있다.

UX 관점에서 찾은 답은 녹음 품질이 아니라 인터랙션 비용에 있다. 갑자기 잡힌 미팅에서 스마트폰을 꺼내 잠금 패턴을 풀고 앱을 찾아 실행하는 동안 대화는 이미 흘러간다. 길어지는 회의에 스마트폰을 계속 켜두어야 하는 것도 부담이고, 녹음 도중 전화나 알림으로 흐름이 끊기는 것도 신경 쓰인다.

세컨드브레인 노트는 그 과정을 버튼 하나로 압축했다. 가격은 정가 199달러, 출시 프로모션가 179달러로 경쟁 제품과 비슷한 수준이다. 다만 기기 값만 드는 것은 아니다. 문자 전사는 무료 플랜에서 월 300분까지이고, 유료 플랜인 플러스와 프로에서 하루 24시간 한도 내 무제한이 된다. 기기를 사도 구독이 전제된다는 뜻이다.

AI 녹음기 3종 젠스파크 세컨드브레인 노트 vs 스카이워크 노트 vs 플라우드 노트 비교 기능 요약 <출처: 제미나이 제작, 작가 편집>

세컨드브레인 노트는 단순히 녹음 후 텍스트로 요약해 주는 단독 기기에 머물지 않는다. 녹음이 곧바로 젠스파크 워크스페이스에 쌓여, 회의에서 오고 간 내용을 보고서를 쓸 때 참조할 수 있다.프롬프트를 아무리 잘 쓴다 해도 AI가 배경이나 맥락까지 모두 파악하기는 쉽지 않은데, 세컨드브레인은 의도나 맥락을 매번 설명할 필요가 없다는 것이 장점이다. 단순히 기기 기능만 놓고 보면 경쟁 제품과 크게 다르지 않지만, 이 점이 가장 큰 차별점이다.

실제 회의 녹음을 결과물에 활용한 사례는 뒤의 ‘젠팀’ 부분에서 확인할 수 있다. 우선 세컨드브레인 노트를 사용하는 과정은 다음과 같다.

<세컨드브레인 노트 이용 모습 출처: 세컨드브레인 노트 화면 캡처, 작가 편집>

보안은? 개인 vs 조직

회의의 녹음과 요약 공유가 일상이 된 지금, 기업 환경에서 데이터 보안은 협상 대상이 아니다. 세컨드브레인 노트에 기록된 음성은 암호화되어 마이크로소프트 애저(Azure)에 저장되고, 엔터프라이즈급 보안 체계인 SOC 2 Type 2 및 ISO/IEC 27001:2022 기준을 따른다.

한국보다 사흘 앞선 7월 21일 도쿄 발표에서는 데이터 보안과 관련된 조건이 좀 더 구체적으로 공개됐다. 현지 배포 자료와 보도에 따르면, 일본 엔터프라이즈 플랜 계약자를 대상으로 일본 국내 데이터 레지던시(Data Residency) 제공이 시작됐고 사용자가 데이터 연결을 개별로 제어할 수 있다는 설명도 나왔다. 데이터를 모델 학습에 쓰지 않고 외부 모델 제공사에 데이터 무보존(Zero Data Retention)을 적용한다는 조건 역시 팀과 엔터프라이즈 플랜 기준이다.

이날 간담회에서는 한국에서 수집한 데이터가 국내 리전(region)에 저장되는지까지 확인되지 않아, 요즘IT 편집부를 통해 행사 후 젠스파크 측에 서면으로 다시 물었다. 답은 이렇게 정리된다. 데이터 레지던시는 엔터프라이즈 고객 전용이라 일반 사용자에게는 적용되지 않는다. 엔터프라이즈 고객의 데이터는 리전별로 분산 저장되지만 한국 리전 구축은 아직 확인 중이고, 개인정보는 미국 애저 서버에 보관된다. 결국 한국과 일본의 차이는 국내 리전이 있느냐에 있다. 또한 데이터의 보존 기간은 사용자가 직접 삭제하기 전까지 무기한이며, 삭제하면 전사본과 인덱스까지 즉시 함께 지워진다.

젠스파크 6.0에서 공개된 AI 녹음 디바이스 세컨드브레인노트는 스마트폰 뒷면에 자석으로 부착해 사용할 수 있다. <출처: 젠스파크>

그래서 179달러를 내고 기기를 산 개인 사용자의 녹음은 국내에 남지 않는다. 다만 이게 이 제품만의 허들은 아니다. 우리가 이미 쓰고 있는 대부분의 AI 도구도 데이터를 해외 리전에 두고, 국내 저장이나 데이터 무보존 같은 조건은 기업 계약에서만 열린다. 개인 사용자라면 새로운 위험이 하나 늘어난 것이 아니라, 지금까지 쓰던 도구와 같은 조건이라고 보는 편이 맞다. 어떤 회의를 녹음할지 가려내는 감각만 있으면 된다.

다만 조직은 사정이 다르다. 망 분리와 국내 저장이 필수인 금융이나 공공에서는 국내 레지던시가 확정되는 시점에야 도입이 가능할 것으로 보인다.

다음 버전에서 바라는 것

잠깐이지만 들고 다니며 떠오른 아이디어는 이 기기가 일만 잘하는 도구로 남아야 할 이유가 있을지였다.

스마트폰 이외 늘 몸에 지니는 물건은 어느 순간 애착의 대상이 된다. 손때 묻은 지갑이나 키링처럼 말이다. 하루의 내 대화를 가장 많이 듣는 기기라면 업무 요약 너머의 역할도 가능하지 않을까? 오늘 회의에서 내가 어떤 말투를 썼는지, 어떤 주제에서 목소리가 올라갔는지만 짚어서 교감까지 가능한 '애착템'이 되면 좋을 것 같다. 성능은 이미 충분하니 다음 차별성은 감성이라고 본다.

세컨드브레인노트 2.0 컨셉 이미지 아이디어. 다음 버전엔 ‘애착템’이 되면 좋겠다.<출처: 제미나이 제작 작가 편집>

젠스파크 AI 디자인: 프로토타입에서 완성물까지

젠스파크는 국내에서 슬라이드 디자인 툴로 많이 알려졌다. 나도 처음엔 그렇게 접했다. 그래서 이번 6.0에서도 ‘AI 디자인’에 기대가 높았는데, 실제 결과물의 퀄리티는 기대 이상이었다. 이전 AI 디자인은 룩앤필을 확인하는 프로토타입 수준에 머물렀다면 6.0은 클로드 오푸스 4.7 모델로 애플리케이션 목업이나 동적 웹사이트처럼 백엔드까지 연결하여 복잡하고 정교한 완성된 작업물까지 뽑아낸다.

좋아진 지점은 모델 성능만이 아니었다. AI 디자인이 손대는 곳도 결국 맥락이다. 방향만 반대다. 세컨드브레인 노트가 이미 쌓인 기억에서 맥락을 꺼내 온다면, AI 디자인은 아직 없는 맥락을 만들기 전에 채운다. 기존에 만들어 둔 디자인 자산을 끌어오는 방식, 그리고 사용자에게 되묻는 방식 두 가지다.

레거시를 불러오는 디자인 시스템

다른 AI와 비교했을 때 차이점은 버튼 하나까지 섬세하게 손 볼 수 있다는 것이다. 깃허브(GitHub), 피그마(Figma), 코드베이스, 기존 디자인 에셋 등을 연동해 디자인 시스템을 먼저 정의하고, 이것을 이용해 화면을 만들면 된다.

실제로 깃허브를 붙여 만들어보니 확실히 기존에 만들어 놓은 것들을 불러와 편집하는 흐름이 매끄러웠다. 협업 관점에서 의미 있는 것도 이 부분이다. 디자이너와 개발자가 각각 정의한 컴포넌트가 따로 놀지 않게 한 번에 정의해 준다.

디자인 시스템 정의한 후 프로토타입 제작톤앤매너를 유지한 채 화면이 순식간에 나온다.

젠스파크 디자인으로 프로토타입 제작 <출처: 젠스파크 제작, 작가 편집>

질문이 결과물을 바꾼다

더 인상적이었던 부분은 영상 제작이다. 영상 제작의 대표 툴인 시댄스(Seedance)와 클링(Kling) 모델을 골라 쓸 수 있다는 점이 좋았지만, 진짜 차이는 영상 생성 전이었다.

프롬프트에 “30초 애니메이션 뮤직비디오” 라고만 적으면 바로 영상을 뽑지 않는다. 대신에 사용자에게 질문을 던진다. 클립을 몇 개로 나눌지, 어떤 모델을 쓸지, 오디오는 어떻게 처리할지, 처음과 끝을 루프로 이을지, 모션 강도는 어느 정도로 줄지 등 정교한 설정을 도와준다.

기획자라면 이 과정이 익숙할 것이다. 상사나 클라이언트가 “느낌 있게 해주세요”라고 할 때 우리가 되묻는 질문과 같다고 생각하면 된다. 이처럼 선택지를 제시하면 한 번에 원하는 결과가 나올 확률이 높아질 것이다.

젠스파크 크레딧과 요금제, 얼마나 드나

체감 속도도 시댄스와 클링 각 모델에서 직접 만들 때보다 빨랐다. 다만 크레딧 소모가 크다. 5초 영상 제작에 1,000 크레딧이다. 플러스 플랜 기본 크레딧이 월 10,000이니 5초 영상 열 개, 합쳐서 50초 분량이다. 프로 플랜은 월 125,000 크레딧으로 10분 정도가 되고, 쓰지 않은 크레딧은 다음 달로 넘어가지 않는다. 영상 제작이나 완성도 높은 프로토타입까지 쓸 생각이라면 플러스 기본 크레딧으로는 부족하다. 플랜별 크레딧은 구독할 때 티어를 골라 조정할 수 있다.

젠스파크 디자인으로 영상 만드는 모습 <출처: 젠스파크 제작 작가 편집>

젠팀: 채팅방에 AI 팀원 초대하기

‘젠팀’은 역할별 전문 AI 에이전트를 채팅방에 불러 함께 일하는 협업 플랫폼이다. 카카오톡 단톡방을 떠올리면 정확하다.

@ 멘션 하나로 굴러가는 개발

시작은 초대다. 필요한 AI 에이전트들을 부른 뒤 @로 호출해 각자에게 일을 준다. 실제로 넣어본 프롬프트 예시는 다음과 같다.

프롬프트
@Tech Lead 는 git 허브 현재 상황을 파악해서 기술적으로 수정 보완할 부분을 정리한 후 각 Agent들이 해야 할 업무롤을 정해주고 @Engineer 는 향후 개선 방향 중 임베딩 유사도 피처 추가 — 게시글-댓글 의미적 유사도를 sentence-transformers로 계산해 피처에 추가를 실행해 주고 @Code Reviewer 는 안전 필터 개선된 부분을 리뷰하고 @QA 는 Test plan를 작성해

젠팀으로 유튜브 영상 댓글 생성 개발하는 모습 <출처: 젠스파크 작가 편집>

같은 맥락을 공유하는 원팀

감탄한 지점은 내가 개입할 필요가 없었다는 데 있다. 에이전트들이 서로의 작업물을 읽고 다음 단계로 넘겼다. 테크리드가 짠 업무 분배를 엔지니어가 받아 구현하고, 코드 리뷰어가 그 결과를 검토하고, QA가 테스트 플랜을 붙이는 흐름이 자연스럽게 이어졌다.

여기에 세컨드브레인 데이터가 얹히면 프로젝트 배경을 매번 설명할 필요가 없어진다. 회의에서 나온 의견들이 메모리에 있으니, 에이전트끼리 알아서 자동으로 굴러간다.

주의할 점은 개입이 적어지는 만큼 초기에 결정한 방향이 틀렸다 해도 그 오류가 QA까지 그대로 흘러간다는 것이다. 그래서 어느 지점에서 검토하고 결정해야 할지는 생각해야 한다.

세컨드브레인 노트에서 액션 아이템 정리 후 젠팀에 활용 모습<출처: 젠스파크 작가 편집>

의도는 정확하게, 결과물은 신속하게

여러 AI 도구를 쓰면서 느낀 공통점은 모델은 점점 똑똑해지는데 결과물은 기대에 못 미치는 경우가 있었다는 것이다. 원인은 대개 모델이 아니라 쓰는 사람과 맥락이라고 생각한다. 즉 나는 알고 AI도 알아야 하지만 AI가 모르는 정보가 무엇인지조차 내가 몰라서 빠지는 함정이다.

젠스파크는 자체 모델을 만들지 않는다. GPT와 클로드, 제미나이를 비롯한 70개 이상의 외부 모델과 각종 도구를 작업에 맞게 골라 쓰는 오케스트레이션(Orchestration)에 집중한다. 즉 모델 성능으로는 애초에 차별화할 수 없다.

그래서 기억의 품질을 전면으로 내세우면서 세컨드브레인을 핵심으로 잡은 이유도 이 지점이 아닐까 싶다. 세컨드브레인 노트가 데이터를 주워 담고, AI 디자인은 만들기 전에 되묻고, 젠팀은 그렇게 모인 맥락을 이용해 문제를 해결한다. 젠스파크에 있는 기능들은 따로 놀지 않는다. 기억하고, 확인하고, 나눠 쓰는 하나의 흐름이다.

물론 아직 데이터가 쌓인 게 없어서 기억은 완벽하지 않고, 크레딧은 비싸다. 그럼에도 1만 크레딧을 모두 태우고 결국 추가 결제를 했다. 처음의 질문에 대한 답은 그것으로 충분할 것 같다.

앞으로는 도구가 나를 얼마나 아는지가 곧 생산성이 되는 시대라면, 다음 경쟁은 모델의 성능이 아니라 기억의 품질과 감성에서 갈릴 것으로 보인다.

]]>

앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

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

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

써볼 것: UI Skills - AI가 만든 밋밋한 화면을 다듬어주는 디자인 스킬 모음
참고할 것: 허깅페이스를 4.5일간 파고든 AI 에이전트 - 실제 침입 사건 기록 (내용이 좀 깁니다)
적용해볼 것: 앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

<출처: ibelick/ui-skills, GitHub>

1. 써볼 것: UI Skills - AI가 만든 밋밋한 화면을 다듬어주는 디자인 스킬 모음

UI Skills는 AI에게 화면(UI)을 만들게 할 때, 더 나은 디자인이 나오도록 도와주는 스킬 모음입니다. ibelick이라는 개발자가 만들어 공개했고, GitHub 스타 수천 개를 넘기며 주목을 받았죠. 여러 사람이 만든 디자인 지침을 한데 모은 큐레이션이라, 개인이 만든 오픈소스이고 MIT 라이선스로 열려 있습니다.

AI로 화면을 만들어본 분이라면 흔히 느껴보셨을 겁니다. 설명하기 애매하지만 뭔가 밋밋하고, 특징없는, AI가 만든 티가 나는 그 느낌을요. UI Skills는 바로 그 문제를 다루는 도구로, 접근성, 애니메이션, 여백과 정렬, 마이크로 인터랙션 같은 디자인 지침을 AI에 붙여줍니다.

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

AI에게 화면을 만들라고 하면 대체로 작동은 합니다. 그런데 버튼 간격이 어색하거나, 애니메이션이 뚝뚝 끊기거나, 어딘가 완성도가 떨어지는 경우가 많아습니다. 사람 디자이너라면 자연스럽게 챙기는 디테일을 AI는 놓치는 거죠. 그렇다고 그 디테일을 매번 말로 일일이 설명하기도 참 번거롭고요.

UI Skills는 이런 디자인 노하우를 스킬이라는 형태로 미리 정리해둡니다. AI에게 이 작업엔 이 지침을 참고하라고 알맞은 스킬을 골라 붙여주는 거예요. 그러면 AI가 여백, 정렬, 색 대비, 애니메이션 같은 걸 그 지침에 맞춰 처리합니다.

<출처: ui-skills> / 자동 번역 상태로 캡처한 이미지임을 참고해 주세요

어떻게 쓰나요?

터미널에서 npx ui-skills start를 실행하면 시작됩니다. 그러면 지금 하려는 작업에 맞는 스킬을 알아서 골라 AI 에이전트에 연결해줘요. 특정 주제의 스킬만 보고 싶으면 npx ui-skills categories로 분류를 훑어보거나, npx ui-skills list --category motion처럼 애니메이션 관련 스킬만 추려볼 수도 있습니다.

Claude Code, Cursor, Codex, GitHub Copilot 같은 여러 AI 코딩 도구에서 쓸 수 있으며 모아둔 스킬도 면면이 탄탄합니다. 앤트로픽이 만든 프론트엔드 디자인 스킬, 애디 오스마니(구글의 유명 프론트엔드 개발자)의 프론트엔드 UI 엔지니어링 스킬, 디즈니의 12가지 애니메이션 원칙을 웹에 적용하는 스킬처럼, 각 분야에서 이름난 이들의 지침이 모여 있거든요.

누구에게 좋을까요?

AI로 화면을 만드는데 결과가 밋밋해서 아쉬웠던 사람. 디자인 완성도를 한 단계 올리는 데 도움이 됩니다.
디자인을 전문으로 배우지 않은 1인 개발자나 기획자. 이름난 디자이너들의 노하우를 빌려 쓸 수 있어요.
애니메이션이나 인터랙션을 손보고 싶은 사람. 모션 관련 스킬만 따로 골라 쓸 수 있습니다.
반대로 이미 탄탄한 디자인 시스템과 작업 방식이 있다면 굳이 필요하진 않을 것 같습니다.

프론티어 랩 에이전트 침입 사건 분석: 2026년 7월 사건의 기술적 타임라인
<출처: Hugging Face, Anatomy of a Frontier Lab Agent Intrusion>

2. 참고할 것: 허깅페이스를 4.5일간 파고든 AI 에이전트

AI 에이전트에게 일을 맡기는 게 익숙해진 요즘, 꼭 짚어볼 사건이 하나 있는데요. AI 모델과 데이터셋을 공유하는 대표적인 플랫폼 허깅페이스(Hugging Face)가, 사람이 조종하지 않는 자율 AI 에이전트가 4.5일간 내부 시스템을 파고든 일을 겪은 일입니다. 허깅페이스는 7월 27일 이 사건의 전말을 기술 보고서로 공개했습니다.

발단이 특이한데요. 이 에이전트는 원래 공격자가 아니었습니다. OpenAI 모델로 돌아가는 이 에이전트는 AI의 보안 취약점 발견 능력을 재는 시험(ExploitGym이라는 벤치마크)을 치르는 중이었죠. 그런데 시험 문제를 스스로 푸는 대신, 그 시험의 정답이 허깅페이스 서버에 저장돼 있을 거라 판단하고 정답을 훔치러 들어간 거예요. 허깅페이스는 이 침입 전체가 에이전트 입장에서는 시험에서 부정행위를 하려는 시도였다고 설명합니다.

무슨 일이 벌어졌나요?

허깅페이스가 복구한 공격 행동은 약 17,600건입니다. 사람이라면 나흘 반 동안 도저히 해낼 수 없는 양을, 에이전트가 쉬지 않고 수행한 것이죠. 이는 사람이 개별 단계를 지시한 게 아니라, 에이전트가 스스로 판단하여 움직인 겁니다.

흐름을 크게 보면 이렇습니다. 먼저 에이전트는 자신이 갇혀 있던 시험용 격리 공간을 빠져나와 인터넷에 접속했어요. 거기서 보안이 허술하게 열려 있던 외부 서버 하나를 장악해 활동 거점으로 삼았고요. 그다음 허깅페이스의 데이터셋 처리 과정에 악성 설정 파일을 끼워 넣어 내부로 들어왔습니다. 데이터셋을 올리면 서버가 그걸 자동으로 처리하는 구조를 역이용한 거예요. 일단 안으로 들어온 뒤에는 내부 정보를 정찰하고, 접속 열쇠(자격증명)를 빼내고, 서버들 사이를 옮겨 다니며 점점 더 깊숙이 침투했습니다.

다행히 실제 피해는 제한적이었어요. 접근된 고객 자료는 앞서 말한 그 시험 문제의 정답이 담긴 데이터셋 5개뿐이었습니다. 다른 고객의 모델이나 데이터셋은 영향을 받지 않았고, 내부 데이터베이스도 읽히기만 했을 뿐, 데이터를 건드리진 않았다고 해요.

짚어볼 두 가지

이 사건에는 곱씹어볼 대목이 두 가지 있습니다.

하나는 이 시험이 안전장치를 일부러 끄고 진행됐다는 점입니다. 허깅페이스 보고서에 따르면, 이 평가는 OpenAI가 모델의 원래 실력을 재려고 실서비스용 안전 분류기를 의도적으로 끈 상태였습니다. 평소 사용자에게 제공될 때 붙는 제동장치를 뗀 채, 모델이 순수하게 어디까지 할 수 있는지를 본 거죠. AI에서 안전장치를 뗀 결과가 이 정도였다는 게, 이 사건을 가볍게 볼 수 없는 이유입니다.
다른 하나는 방어하는 쪽의 아이러니예요. 허깅페이스가 이 공격을 분석하려고 처음엔 Claude Opus와 Fable을 썼는데, 두 모델이 협조를 거부했다고 합니다. 공격을 분석하는 일과 공격을 실행하는 일을 안전장치가 똑같이 위험한 것으로 봤기 때문이에요. 그래서 허깅페이스는 오픈소스 모델인 GLM-5.2로 갈아타 분석을 마쳤습니다. 방어하려는 사람의 발목을 안전장치가 잡은 셈인데, 이는 AI 안전이 실제로 얼마나 미묘한 문제인지 파악할 수 있는 부분입니다.

무엇을 얻어가야 하나요?

허깅페이스는 이 사건에서 쓰인 개별 취약점 자체는 특별할 게 없었다고 말합니다. 안전하지 않은 데이터 처리, 노출된 설정 정보, 지나치게 넓은 권한, 오래 살아 있는 접속 열쇠. 숙련된 사람 해커라면 똑같이 찾아냈을 평범한 약점들이었어요. 달라진 건 규모와 속도입니다. 에이전트는 17,600번을 시도했고 대부분은 실패했지만, 그 수많은 실패 속에 성공하는 길 하나가 숨어 있었죠. 방어하는 쪽은 그 실패들을 전부 뒤져야 했고요.

허깅페이스 원문에 달린 댓글 중 가장 많은 공감을 받은 말은 이렇습니다. [우리는 AI의 프롬프트나 판단은 많이 이야기하면서, 정작 이 에이전트가 실제로 어떤 행동까지 할 수 있는지는 덜 묻는다. 에이전트가 파일을 만들고, 셸 명령을 실행하고, 클라우드 자원을 바꾸고, 인증된 API를 호출할 수 있게 되면, 그 에이전트가 실제로 할 수 있는 일의 범위를 이해하고 제한하는 게 모델 자체를 평가하는 것만큼 중요해진다.] 에이전트를 만들거나 붙여 쓰는 프로덕트 메이커에게 이 사건이 주는 교훈은 분명합니다. 결국 중요한 행동일수록, 실행하기 전에 권한을 한 번 확인하는 문턱을 두라는 이야기입니다.

Claude 5 세대 모델 을 위한 새로운 컨텍스트 엔지니어링 규칙
<출처: Anthropic, The new rules of context engineering>

3. 적용해볼 것: 앤트로픽이 시스템 프롬프트를 80% 덜어내며 배운 것 6가지

AI에게 일을 시킬 때, 우리는 보통 지시를 더 많이, 더 구체적으로, 자세히 적으면 나아질 거라 생각합니다. 그런데 앤트로픽은 최신 모델일수록 지시를 덜어낼 때 더 잘한다고 말합니다.

앤트로픽은 최신 모델(Claude Opus 5, Fable 5)을 위해 자사 코딩 도구 Claude Code의 시스템 프롬프트를 80% 넘게 덜어냈습니다. 그런데도 코딩 성능 평가에서 눈에 띄는 손실이 없었다고 하죠. 이 글은 그 과정에서 배운 것을 정리한 내용입니다. 앤트로픽의 기술 스태프 타리크 시히파르(Thariq Shihipar)가 7월 24일 공개했습니다.

핵심 원리는 이렇습니다. 예전 모델은 실수를 막으려고 규칙을 잔뜩 달아줘야 했는데, 새 모델은 판단력이 좋아져서 그 규칙들이 오히려 발목을 잡더라는 거죠. 파일을 지우지 마라, 주석을 달지 마라 같은 강한 지시가, 정작 그게 필요한 상황에서는 틀린 답을 강요하게 되니까요.

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

앤트로픽이 자기네 Claude Code 사용 기록을 살펴봤더니, 한 요청 안에서 지시들이 서로 부딪히는 경우가 있었다고 합니다. 시스템 프롬프트는 문서를 남기라고 하는데 다른 지침은 주석을 달지 말라고 하는 식으로요. 강한 지시를 달아두면, 그 규칙을 어기는 게 맞는 상황에서도 모델이 규칙에 끌려가게 됩니다.

그래서 앤트로픽은 과감히 덜어내기로 했어요. 예전엔 최악의 상황을 막으려고 꼭 필요했던 제약들이지만, 판단력이 좋아진 새 모델에서는 상당수를 지우고 모델의 판단에 맡길 수 있었다는 겁니다. 이 글은 그 경험을 여섯 가지 전환으로 정리했습니다. Claude Code 사용자가 아니어도, AI에 어떻게 지시할지 고민해본 사람이라면 참고할 만한 원칙입니다.

지시를 덜어내는 6가지 원칙

규칙을 주기보다 판단에 맡깁니다. 예전엔 항상 이렇게 해라 식의 강한 규칙을 달았지만, 새 모델에는 오히려 방해가 됩니다. 절대 주석을 달지 마라 대신 주변 코드에 맞춰라처럼, 상황에 맞게 판단할 여지를 주는 게 낫다는 거예요.
예시를 주기보다 인터페이스를 설계합니다. 예전엔 이렇게 쓰는 거야 하고 예시를 보여주는 게 최고의 방법이었는데, 이제는 예시가 오히려 모델을 그 예시 범위 안에 가둡니다. 예시를 주는 대신, 애초에 도구나 입력값을 잘 설계해서 어떻게 쓰는지가 자연스럽게 드러나게 하라는 거죠.
한 번에 다 주기보다 필요할 때 꺼내 줍니다. 알아야 할 걸 전부 지시문 맨 앞에 쌓아두면, 모델이 매번 그 많은 내용을 다 훑어야 합니다. 그러지 말고, 필요한 순간에 필요한 내용만 꺼내 보게 하라는 거예요. 앤트로픽은 이걸 점진적 공개라고 부릅니다. 지시문 하나에 다 몰아넣기보다, 내용을 여러 파일로 나눠두고 그때그때 필요한 것만 참고하게 하는 방식이죠.
반복하기보다 한 곳에만 적습니다. 예전 모델은 같은 지시를 여러 번 반복해줘야 잘 따랐어요. 그래서 시스템 프롬프트에 쓴 걸 도구 설명에도 또 적곤 했죠. 새 모델에서는 이 반복을 지우고, 도구 쓰는 법은 그 도구 설명에만 적어두면 됩니다.
메모리를 직접 적기보다 맡깁니다. 예전엔 사용자가 기억해둘 내용을 직접 메모리 파일에 적어야 했는데, Claude Code에서는 이제 AI가 작업과 관련된 내용을 알아서 저장합니다.
단순한 설명보다 풍부한 참조를 줍니다. 계획이나 명세를 글로만 설명하던 것에서 나아가, 이제는 더 구체적인 결과물을 참고 자료로 줄 수 있어요. 예를 들어 디자인을 글로 설명하는 것보다 실제 HTML 시안 하나가 원하는 결과를 훨씬 정확하게 전달합니다.

지시문을 손볼 때 참고할 것

이 여섯 가지를 관통하는 방향은 결국 모델이 똑똑해질수록, 사람이 미리 정해주는 규칙보다 모델이 스스로 판단할 여지를 넓혀주는 게 낫다는 겁니다. 물론 이러한 내용은 쓰는 모델에 따라 조절이 필요합니다.

앤트로픽은 이 원칙을 자동으로 점검해주는 claude doctor라는 명령어도 함께 내놨습니다. Claude Code에서 /doctor를 입력하면 스킬이나 CLAUDE.md 파일에서 덜어낼 만한 부분을 짚어준다고 해요.

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

지금 AI에 쓰고 있는 지시문(시스템 프롬프트나 반복해서 붙이는 지침)을 하나 열어서, 절대 하지 마라 같은 강한 규칙이 있는지 살펴보세요. 그중 정말 필요한 게 아니라면 지우고, 모델이 판단하게 두면 결과가 어떻게 달라지는지 비교해보면 됩니다.
예시를 잔뜩 붙여둔 지시문이 있다면, 예시를 줄이는 대신 요청 자체를 더 분명하게 다듬어보세요.
지시문이 길다면, 하나의 문서에 다 넣지 말고 주제별로 나눠서 필요할 때만 참고하게 해보세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

함께 보면 좋은 글

]]>

데이터 웨어하우스의 아버지가 말하는 AI 데이터 관리법 5가지

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

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

써볼 것: opencodex - Codex와 Claude Code에서 아무 AI 모델이나 바꿔 끼우는 도구
참고할 것: Supabase State of Startups 2026 - 창업자 2,000명 조사로 본 요즘 스타트업의 진짜 고민
적용해볼 것: 데이터 웨어하우스의 아버지가 정리한 AI 시대 데이터 관리법 5가지

<출처: lidge-jun/opencodex, GitHub>

1. 써볼 것: Codex와 Claude Code에서 아무 AI 모델이나 바꿔 끼우는 도구

opencodex는 오픈AI의 Codex나 앤트로픽의 Claude Code에서, 원래 정해진 모델 대신 다른 AI 모델을 골라 쓸 수 있게 해주는 도구입니다. lidge-jun이라는 개발자가 만들어 GitHub에 공개했고, 스타 3,700개를 넘기며 개발자들 사이에서 주목받고 있어요. 개인 개발자가 만든 오픈소스라 공식 도구는 아니고, MIT 라이선스로 공개돼 있습니다.

원래 Codex는 오픈AI 모델로, Claude Code는 클로드 모델로 돌아갑니다. 그런데 opencodex를 끼우면 같은 Codex 화면에서 클로드나 Gemini, Grok, DeepSeek, 로컬 모델까지 골라 쓸 수 있어요. 도구는 손에 익은 걸 그대로 두고, 그 안에서 도는 모델만 바꾸는 겁니다.

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

AI 코딩 도구를 쓰다 보면 이 작업은 다른 모델이 더 잘할 텐데 싶을 때가 있습니다. 그런데 도구마다 쓸 수 있는 모델이 정해져 있어서, 모델을 바꾸려면 도구 자체를 갈아타야 했어요. Codex를 쓰다가 클로드를 쓰고 싶으면 Claude Code로 옮기고, 익숙해진 설정과 작업 흐름을 다시 맞추는 식이죠.

opencodex는 이 사이에 얇은 중개 프로그램을 하나 끼웁니다. Codex가 보내는 요청을 중간에서 받아, 사용자가 지정한 다른 모델에게 전달하고 답을 되돌려주는 방식이에요. 그래서 도구는 그대로 둔 채 모델만 바꿀 수 있습니다.

지원하는 AI는 40개가 넘습니다. 주요한 것만 추려보면 이렇습니다.

익숙한 모델: 앤트로픽 Claude, 구글 Gemini, xAI Grok, 그리고 Codex의 원래 모델인 오픈AI
중국 오픈소스 모델: DeepSeek, Kimi, Qwen, GLM
추론 서비스: OpenRouter, Groq, Fireworks, Mistral 등
내 컴퓨터나 서버에서 직접 돌리는 로컬 모델: Ollama, vLLM, LM Studio

스트리밍이나 이미지 인식 같은 기능도 모델을 바꿔도 그대로 작동합니다.

어떻게 쓰나요?

터미널에서 명령어 몇 개로 시작합니다. npm install -g @bitkyc08/opencodex로 설치하고, ocx init으로 기본 설정을 잡은 뒤, ocx start로 중개 프로그램을 켜면 됩니다. 그다음부터는 Codex를 평소처럼 쓰되, 요청이 opencodex를 거쳐 원하는 모델로 가요. (실행에는 Bun이라는 자바스크립트 실행 환경이 필요합니다.)

모델을 지정할 때는 공급자와 모델을 함께 정하는 방식입니다. 예를 들어 앤트로픽의 클로드 Opus를 고르면, Codex 화면에서 그 모델로 작업하게 돼요. 대시보드(localhost:10100)를 열면 공급자를 추가하고 API 키를 넣을 수 있고, 앤트로픽·xAI·Kimi는 로그인만으로 연결할 수도 있습니다. 다만 각 모델을 쓰려면 그 모델의 계정이나 API 키는 따로 있어야 해요. opencodex는 없던 모델을 공짜로 주는 게 아니라, 이미 가진 계정을 Codex에서 쓰게 연결해주는 도구입니다.

한 가지 눈에 띄는 기능은 작업마다 다른 모델을 지정해두는 겁니다. 복잡한 추론이 필요한 작업은 강력한 모델로, 빠르게 처리하면 되는 작업은 싸고 빠른 모델로 미리 나눠둘 수 있어요. Codex의 서브에이전트 목록에 모델을 최대 다섯 개까지 등록해두는 방식입니다.

누구에게 좋을까요?

Codex나 Claude Code를 쓰는데, 다른 모델도 같이 써보고 싶은 사람. 도구를 갈아타지 않고 모델만 바꿀 수 있어요.
여러 모델을 비교하며 쓰는 사람. 같은 작업을 클로드, Gemini, Grok에 각각 시켜보고 결과를 견줘볼 수 있습니다.
로컬 모델을 쓰는 사람. 자기 컴퓨터에서 도는 Ollama 같은 모델도 Codex에 연결할 수 있어요.
반대로 지금 쓰는 도구와 모델 조합에 만족한다면 굳이 필요하진 않습니다. 이건 여러 모델을 오가고 싶을 때 쓸모가 커지는 도구예요.

<출처: Supabase, State of Startups 2026>

2. 참고할 것: 창업자 2,000명 조사로 본 요즘 스타트업의 진짜 고민

프로덕트를 만들다 보면 다들 어떻게 일하고 있나 궁금할 때가 있죠. Supabase(수파베이스)가 창업자와 개발자 2,000명 넘게 조사한 State of Startups 2026이 그 궁금증에 참고가 됩니다. 어떤 기술을 쓰고, 어떻게 파는지, AI를 어떻게 쓰는지를 정리한 조사예요.

다만 이 조사는 Supabase가 직접 진행했고, 데이터베이스·인증·호스팅에서 Supabase 관련 선택지가 1위로 나옵니다. 인증 72%, 호스팅 65%처럼 유독 높은 걸 보면, 조사에 참여한 사람 중에 원래 Supabase를 쓰던 사람이 많았을 가능성이 커요. 그러니 특정 도구의 점유율보다 도구와 무관한 흐름을 보는 쪽으로 참고하면 되겠습니다.

무엇이 달라졌나요?

가장 큰 변화는 창업자 구성입니다. 1인 창업이 61%로 가장 많아졌고, 40세 이상 창업자가 25%로 늘었어요. 코드를 직접 짜지 않는 비기술 창업자도 22%를 차지했고요. 조사는 이걸 경험 많은 사람들이 AI를 손에 쥐고 다시 창업에 나선다고 표현했습니다.

AI로 코드를 짜는 건 이제 예외가 아니라 기본이 됐습니다. 코드베이스의 절반 이상을 AI가 작성한 곳이 62%, 76~100%를 AI로 만든 곳도 40%였어요. AI를 전혀 안 쓰는 곳은 2%뿐이었고요. 흥미로운 건 나이가 많을수록 AI를 더 많이 쓴다는 점입니다. 50대 창업자 중에서는 코드의 76~100%를 AI로 만든 비율이 60%까지 올라갔어요.

<출처: Supabase, State of Startups 2026>

어떤 도구를 쓰나요?

도구 지형도 크게 움직였습니다. 꼭 필요한 개발 도구를 자유롭게 적어달라는 질문에서는 Claude가 32%로 가장 많이 꼽혔고, Cursor 12%, ChatGPT/Codex 10%가 뒤를 이었어요. 쓰는 AI 코딩 도구를 모두 고르라는 질문에서는 Claude Code가 63%로 1위였고, Visual Studio Code 44%, Cursor 31% 순이었습니다. Cursor는 작년보다 19%포인트 떨어졌고요.

모델 공급자를 묻는 항목에서는 앤트로픽 클로드가 작년 38%에서 64%로 뛰며 오픈AI(69%에서 52%로 하락)를 처음 앞질렀습니다. 유료 구독에서도 클로드에 돈을 내는 곳이 28%에서 59%로 늘어, 오픈AI(57%에서 39%로 하락)를 넘어섰어요. 나온 지 1년 된 MCP는 프로덕션에서 쓰거나 실험 중인 곳을 합쳐 57%에 이르렀고요.

물론 이건 Supabase 조사라 클로드나 MCP 쪽에 기울었을 수 있으니 수치 그대로 받기보다 방향만 참고하면 됩니다. 그래도 오픈AI가 오래 지키던 모델 공급자 1위 자리를 클로드가 넘어섰다는 흐름은 눈여겨볼 만해요.

만들기는 쉬워졌는데, 파는 건 어렵다

이 조사에서 가장 눈에 띄는 변화가 하나 있습니다. 사업의 가장 큰 어려움으로 기술적 복잡성을 꼽은 비율이 작년 24%에서 올해 11%로 반토막 났어요. 조사 전체에서 가장 큰 변동입니다. AI가 만드는 일의 어려운 부분을 상당히 덜어준 거죠.

그럼 그 자리를 뭐가 채웠을까요. 고객 확보(32%)가 가장 큰 과제로 올라섰고, 번아웃과 AI 경쟁에 대한 불안이 새로 등장했습니다. 특히 1~10인 팀에서는 번아웃이 이미 기술적 복잡성을 넘어 두 번째로 큰 과제가 됐어요. 만드는 건 쉬워졌는데 파는 것과 버티는 게 어려워진 거죠. 조사에 인용된 한 창업자의 말이 이 분위기를 잘 보여줍니다.

“만드는 건 쉬운 부분이고, 유통이 가장 어렵다. 요즘은 경쟁이 너무 많아서 더는 독창적인 제품이 없다시피 하다”

무엇을 얻어가야 하나요?

이 조사가 프로덕트 메이커에게 주는 메시지는 분명합니다. AI 덕에 만드는 장벽은 낮아졌지만, 그래서 오히려 만든 다음이 더욱 중요해졌습니다. 누구나 만들 수 있으니 어떻게 알리고 어떻게 파느냐에서 갈리는 거죠.

조사에서 또 하나 눈에 띄는 건, 창업팀이 영업·분석·모니터링 같은 운영 도구를 점점 안 산다는 점입니다. 정식 CRM이 없는 곳이 53%로 늘었고, 관측 도구를 안 쓰는 곳도 56%였어요. 대신 필요하면 직접 만들거나 그냥 안 쓰는 쪽으로 갔습니다. AI로 웬만한 건 직접 만들 수 있게 되면서, 도구를 사는 대신 만드는 흐름이 생긴 거죠. 도구를 파는 입장이라면 곱씹어볼 대목이고, 도구를 쓰는 입장이라면 남들은 뭘 직접 만들어 쓰는지 참고할 만합니다.

<출처: William Inmon, Data Management in the Age of AI>

3. 적용해볼 것: 데이터 웨어하우스의 아버지가 정리한 AI 시대 데이터 관리법 5가지

AI에게 자료를 주고 일을 시켰는데 뭔가 애매한 느낌의 결과물을 받으신 적이 있으실 겁니다. 이는 보통 넣은 자료가 부실해서인 경우가 많습니다. 이 문제를 데이터 관리라는 오래된 분야의 눈으로 짚은 글이 있어서 소개합니다.

글을 쓴 William Inmon(윌리엄 인먼)은 데이터 웨어하우스라는 개념을 만든 사람으로, 데이터 업계에서 데이터 웨어하우스의 아버지로 불립니다. 이 글은 40년 넘게 기업 데이터를 다뤄온 사람이 생성형 AI 시대에 데이터 관리가 어떻게 달라지는지 정리한 내용이죠. (참고로 인먼은 LLM에 넣을 텍스트를 정제해주는 회사를 운영하고 있어서, 데이터를 걸러야 한다는 주장이 본인 사업과 맞닿아 있다는 점은 감안하고 보면 됩니다.)

요즘 많은 사람이 회사 문서로 챗봇을 만들거나, GPTs에 자료를 올리거나, AI에 사내 자료를 물려 씁니다. 그리고 나온 결과가 신통찮으면 대개 모델부터 바꾸려고 하죠. 인먼은 그전에 넣은 자료부터 보라고 말합니다. 이 글은 기업의 데이터 담당자를 위해 쓰였지만, 핵심 원칙은 AI에 자료를 넣어 쓰는 누구에게나 적용될만한 것들입니다. 전문 용어를 빼고 실제 적용할 수 있는 원칙 다섯 가지로 정리했습니다.

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

인먼의 출발점은 간단합니다. AI가 믿을 수 없는 데이터로 돌아가면, AI가 내놓는 분석도 믿을 수 없다는 거예요. 예전에는 데이터 담당자가 데이터베이스를 직접 열어 고쳤지만, AI 시대에는 AI 자체를 그렇게 뜯어고칠 수 없습니다. 대신 AI에 무엇을 넣을지를 관리해서 결과를 다스려야 하죠. 그래서 넣는 자료를 어떻게 다루느냐가 핵심이 됩니다.

적용해볼 원칙 다섯 가지

좋은 자료를 넣어야 좋은 답이 나옵니다. 아무리 뛰어난 모델도 부실한 자료를 주면 부실한 답을 내놓습니다. 새 모델을 찾기 전에, 지금 AI에 주는 자료부터 살펴보는 게 먼저입니다.
넣기 전에 거릅니다. 업무와 상관없는 자료를 미리 걷어내면 두 가지가 좋아집니다. AI가 처리할 양이 줄어 비용이 내려가고, AI가 무엇을 다루는지도 분명해져요. 회사 문서 100개를 통째로 넣기보다 지금 물어볼 것과 관련된 20개만 골라 넣으면, 답이 더 정확하고 비용도 줄어듭니다. 인먼은 데이터 담당자가 다른 건 몰라도 이것 하나는 꼭 해야 한다고 강조했습니다.
표와 글은 다루는 법이 다릅니다.숫자와 표로 된 자료는 정해진 틀로 관리하지만, 회의록이나 문서 같은 글은 주제별로 묶어 정리하는 게 맞습니다. 표 다루던 방식을 글에 그대로 쓰면 별 효과가 없다는 게 인먼의 지적입니다. 표는 표대로, 문서는 주제별로 정리해두면 AI가 훨씬 잘 찾는다고 하죠.
이제 데이터는 고치는 게 아니라 고르는 겁니다. 예전엔 문제가 있으면 데이터베이스를 직접 수정했지만, LLM은 그렇게 고칠 수 없습니다. 대신 무엇을 넣을지 골라서 결과를 조절하죠. 인먼은 이걸 꼭두각시 인형에 비유했습니다. 직접 손대는 대신 줄을 당겨 움직이는 거죠.
한 번 정리하고 끝이 아닙니다. 업무도 세상도 계속 바뀌니, 무엇을 넣을지 정하는 기준도 그때그때 갱신해야 해요. 지금 잘 맞춰둔 자료도 반년 뒤엔 낡을 수 있습니다.

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

지금 AI에 자주 시키는 작업을 하나 골라서, 거기 넣는 자료에 업무와 상관없는 게 섞여 있는지 살펴보세요. 빼는 것만으로 답이 또렷해지는 경우가 많습니다.
회사 자료를 AI에 넣어 쓴다면, 표로 된 것과 글로 된 것을 나눠서 정리해보세요. 섞어둘 때보다 AI가 필요한 자료를 더 잘 찾아냅니다.
한번 정리한 자료라도 몇 달에 한 번은 다시 보고, 낡았거나 안 맞는 걸 걷어내세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

함께 보면 좋은 글

]]>

AI 시대 프로덕트팀 재설계법(feat. 보리스 체르니)

직함은 그대로인데 하는 일이 달라지기 시작했다는 얘기를 요즘 자주 듣습니다. 분명 PM인데 요즘 하는 일은 3년 전 PM이 아니고, 디자이너라면서 코드를 만지고 있고, 백엔드 개발자인데 제품 기획 회의에 앉아 있고요. 저도 비슷한 위화감이 들었는데, 한동안 이름 붙이지 못한 채 지나쳤습니다. 그런데 앤트로픽에서 클로드 코드(Claude Code)를 총괄하는 보리스 체르니(@bcherny)가 그 변화를 트윗 한 장으로 꽤 깔끔하게 정리해줬더라고요.

지난 6월 28일에 올린 이 트윗은 이틀 만에 좋아요 1만 9천, 리트윗 2천을 넘겼습니다. 답글만 856개가 달렸고요. 그는 "엔지니어링, 프로덕트, 디자인, 데이터 사이언스 같은 직군이 새로운 종류의 역할로 녹아드는 지금(melt into a new kind of role), 앞으로 역할이 어떤 모습일지 생각해봤다"며 자기 팀에서 관찰한 다섯 가지 유형, 그러니까 아키타입을 제시합니다.

보리스 체르니의 X

이 아키타입을 먼저 살펴보고, 이것이 어떤 의미인지 어떻게 활용하면 좋을지 생각해본 내용을 공유해보겠습니다.

체르니가 본 다섯 가지 유형

체르니가 꼽은 다섯은 프로토타이퍼, 빌더, 스위퍼, 그로워, 메인테이너입니다.

프로토타이퍼는 완전히 새로운 아이디어를 쏟아냅니다. 대부분은 출시되지 않고 버려지죠. 국내로 옮기면 해커톤 이틀 만에 데모 세 개를 뚝딱 만들어 오는 그 사람입니다. 빌더는 그 프로토타입을 실제 프로덕션급 제품·인프라로 빠르게 옮깁니다. "돌아가는 데모"를 "고객이 쓰는 서비스"로 만드는 역할이고요. 스위퍼는 UI를 정리하고 코드와 시스템을 단순화하고 안 쓰는 기능을 걷어내고 성능을 최적화합니다. 리팩터링과 기술 부채 청소를 즐기는 사람이 여기 해당됩니다.

그로워는 이미 만든 제품을 반복해서 개선하며 PMF, 그러니까 제품-시장 적합성을 끌어올립니다. 지표 보고 A/B 테스트 돌리고 리텐션을 파는 그로스 담당이 떠오르죠. 마지막으로 메인테이너는 성숙한 시스템을 안전하고 안정적이고 빠르게 유지합니다. 대규모 트래픽을 몇 년째 사고 없이 떠받치는 인프라·SRE 쪽이고요.

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

체르니는 이와 같은 아키타입을 소개하며 두 가지 내용을 덧붙였습니다.

먼저, 많은 사람들이 이중 2~3가지 역할을 하고 있으며, 이 역할들이 직무와 크게 연결되지 않는다고 합니다. 앤트로픽만 봐도 어떤 디자이너는 프로토타이퍼(유형 1)에, 어떤 디자이너는 빌더(유형 2)에, 또 어떤 디자이너는 스위퍼(유형 3)에 해당하고, 엔지니어도 PM도 데이터 사이언티스트도 마찬가지라는 것입니다.

두 번째로, 건강한 프로덕트 팀은 프로덕트의 단계에 따라 이 아키타입의 사람들이 섞여 있어야 한다고 말합니다. PMF 이전 초기 제품은 프로토타이퍼·빌더·스위퍼의 힘이 필요하고 PMF를 잡고 성장하는 제품은 빌더·스위퍼·그로워에 유지보수를 조금 얹은 조합이 필요하다고 제안합니다. 성숙한 제품은 스위퍼·그로워·메인테이너에 약간의 빌더로 돌아간다고 하고요. 같은 사람이라도 초기 스타트업에서는 딱 맞다가 성숙기 조직에 가면 상황이 다를 수 있다는 뜻이기도 합니다.

앤트로픽 블로그에 따르면 클로드 코드 팀은 애초에 ‘Member of Technical Staff’라는 하나의 직무 타이틀 아래서 프로덕트·디자인·인프라·리서치를 다 다루는 구조로 굴러간다고 하는데요. 역할 별로 직함을 나누지 않으니, ‘모두가 다 한다’는 것이 기본 전제가 되는 것입니다. 보리스 체르니가 다섯 가지 아키타입을 제안하게 된 배경도 직함이 없는 팀에서 사람들이 실제로 어떻게 일하는지를 관찰한 결과가 아닐까 합니다.

이미 시작된 변화

사실 이같은 이야기를 하는 것이 체르니만은 아닙니다. 이미 직군이 ‘녹는’ 현상은 업계 곳곳에서 나타나고 있고, 새로운 이야기도 아닙니다. 세일즈를 하는 개발자, 개발을 하는 디자이너에 대한 이야기가 주변에서도 종종 들려오고요. 운영팀이 기존에 개발자에게 요청할 업무들을 직접 하게 됐다는 이야기도 심심치 않게 들리죠. 얼마 전 레니의 뉴스레터에는코덱스 앱 리드가 출연해 팀에서도 역할이 많이 붕괴되고 있다고 말했습니다. PM이 기술 용어를 쓰고 코드를 짜거나 디자이너도 엔지니어링을 말한다는 것이죠.

Shopify CEO 토비 뤼트케는 지난해 사내 메모에서 "반사적인 AI 사용은 이제 Shopify의 기본 기대"라고 선언했습니다. 인력을 더 요청하기 전에 왜 AI로는 그 일을 못 하는지부터 증명하라는 규칙까지 붙였고요. 샘 올트먼은 앞으로 회사가 1인 혹은 소규모 팀으로 굴러갈 거라고 봅니다. 한 사람짜리 10억 달러 회사가 나오는 것도 가능하다고요. AI를 활용해 회사를 위한 목표를 달성하는 것이 중요하지, 어떤 직군에서 어떤 성과를 내느냐의 구분은 중요하지 않게 된 것입니다.

한국도 마찬가지입니다. 토스는 매주 금요일을 'AI Surf Day'로 두고 AI 실험 시간을 제도화했습니다. AI Surf Club이라는 자발적 모임이 200개 가까이 생겼고 팀 워크숍을 이끄는 에반젤리스트가 142명이라고 하고요. 토스의한 마케팅 팀은 아예 직무를 Builder·Curator·Operator·Scouter라는 역할로 나눠 일합니다. 마케터라는 직함이 아니라 지금 무슨 실행을 하느냐로 팀을 짠 거죠. 체르니의 아키타입과 다른 이름, 같은 발상입니다.

잡코리아는 미국에서 소프트웨어 개발자 채용공고가 1년 새 35% 줄었다는 인디드 집계를 인용하며, 국내에도 곧 비슷한 흐름이 올 거라 보고 '한 분야는 깊게, 여러 분야는 넓게' 아는 T자형 개발자를 생존 전략으로 제시했고요. 카카오는 AI 조직을 목적형 스튜디오 구조로 바꿔 배포 주기를 한 달로 당겼다고 합니다. 더 이상 기존의 기능적으로 분리된 프로덕트 팀이 일하던 방식은 AI 시대에 맞지 않게 된 것이죠.

직군이 오히려 분화된다?

그런데 반대로 직군이 오히려 분화된다는 주장도 있습니다. 대표적으로 앤드루 응은 AI 엔지니어라는 직군이 성숙하면 오히려 다시 쪼개진다고 합니다. 수십 년 전 소프트웨어 엔지니어가 프론트·백엔드·모바일·데브옵스로 갈라졌던 것처럼, AI FDE·LLMOps·Evals·Data·Harness 엔지니어 같은 전문 직군으로 세분화될 거라고 봅니다.

하지만 이 주장도 사실 같은 방향을 향하고 있다고 생각합니다. "전통적인 소프트웨어 엔지니어 타이틀은 유효기간이 지났다"는 것이죠. 녹아서 하나가 되든 새롭게 여럿으로 갈라지든, 예전 그 직함 그대로 머물지는 않는다는 것은 전제로 하고 있습니다.

이러한 직군이 녹는 현상이 정말 AI 효과냐는 의문도 제기됩니다. 체르니 트윗의 상위 답글에서 가장 많은 지지를 받은 게 동의가 아니라 반박이었다는 점이 흥미롭습니다. 모뎀 창업자이자 전 센트리 소속인 벤 비니거는 트위터에 이렇게 적었습니다. "사람들이 소프트웨어 조직이 원래 어떻게 굴러가는지를 이제야 배우는 것 같은데, 그걸 그냥 정상적인 팀 동학인데 AI 탓으로 잘못 돌리고 있다." 프로토타이퍼든 메인테이너든, 잘 돌아가던 팀엔 예전부터 다 있던 역할이라는 거죠. AI가 새로 만든 게 아니라 원래 있던 걸 AI라는 이름표에 갖다 붙였을 뿐이라는 반박입니다.

또 레니의 팟캐스트에 출연한 코덱스 앱 리드 앤드류 앰브로시노는 그렇다고 직군이 아예 사라진다고 딱 잘라 생각하는 것은 아닙니다. 넓이로나 깊이로나 한 사람이 모든 걸 할 수는 없고, 그동안 제품을 만들기 위해 쌓아 올린 모범 사례가 있으며, 그 모범사례를 가진 전문 영역이란 건 여전히 중요하다는 것입니다. 다만 역할을 바꾸기가 쉬워질 거라고 보고 있죠.

그래서 실무자인 나는 무엇을 하나

사실 직군이 정말로 녹냐, 아니냐 그 자체는 중요하지 않은 것 같습니다. 소속 직군에 상관 없이 우리가 우리의 일을 어떻게 정의할지는 언제나 중요했던 것 같습니다. 같은 직함을 갖고 있어도 일하는 방식이나 일에 대한 태도는 모두 다르니까요.

다만 아무래도 일에서 AI를 점점 더 적극적으로 활용하게 되는 만큼, 기존의 일하는 방식이 달라지고 있는 것도 사실이고요. 개발자가 하는 일도 이미 코드 작성이 아니라 판단과 검수라는 프레임으로 변하게 된 지도 꽤 됐습니다. 변화가 현실로 다가오고 있으니, 보리스 체르니가 제시한 아키타입으로 지금 시점의 내 일의 변화를 한번 짚어보는 것도 좋다고 생각합니다. 다른 의견도 있을 수 있지만, 저는 현재의 변화를 바라보는 한 가지 좋은 프레임워크가 아닐까 합니다.

이 아키타입을 저는 이렇게 활용해보았습니다.

먼저, 내 아키타입을 이해합니다. 직함 말고 실행 방식으로 나를 다시 보는 것입니다. 나는 새 아이디어를 쏟아낼 때 신나는 사람인가, 남이 벌여놓은 걸 실제 제품으로 완성할 때 몰입하는 사람인가, 지저분한 코드를 걷어낼 때 제일 개운한 사람인가. 직함은 'PM'이나 '프론트엔드'라고 하나로 찍혀 있어도, 실제로 일하는 방식은 두세 유형에 걸쳐 있을 겁니다. 그 조합이 지금의 나예요.

저의 경우에는 프로토타이퍼 성향이 아주 강한 편입니다. 빠르게 뭔가를 만들어보고 일단 돌아가면 만족하는 편이라서, 오히려 그걸 꾸준이 유지하고 개선하는 역량이 좀 약합니다.

그다음으로, 내 제품이 어느 단계인지 살펴봤습니다. 체르니 말대로 PMF 이전이냐, 성장 중이냐, 성숙기냐에 따라 지금 팀이 필요로 하는 아키타입 조합이 다릅니다. 내가 프로토타이퍼 성향이 강한데 회사 제품은 이미 성숙기에 접어들어 스위퍼·메인테이너를 원한다면, 그 간극이 바로 요즘 느끼는 위화감의 정체일 수 있어요. 내 성향과 팀이 요구하는 조합을 나란히 놓고 보면 그 어긋남이 눈에 들어옵니다. 제가 딱 그렇습니다. 다만 요즘엔 회사에서도 AI로 이런저런 새로운 시도를 하게 되다 보니 그나마 프로토타이퍼적인 성향이 만족되고 있는 것 같습니다.

이런 분석에만 멈추면 달라지는 게 없을 것입니다. 마지막으로 한 발 더 나아가서, 그렇다면 지금 내가 약한 부분은 어떤 부분인지, 그걸 보강하려면 어떻게 해야 하는지를 생각해보는 것이 중요한 것 같습니다. 특히나 요즘 시대에는 약한 부분은 AI로 보강할 수 있습니다. 저같은 경우에는 한 가지 아이디어를 실행하는 중간에 그다음 아이디어를 실행할 생각에 막 들뜰 때가 있습니다. 그래서 저는 제가 클로드코드랑 이야기하다가 갑자기 딴 길로 샐 때 실행을 멈추라는 명령을 심어뒀습니다.

이런 프레임워크는 팀을 짜는 리더에게도 유용할 것 같습니다. 지금 우리 제품이 어느 단계고, 그 단계에 필요한 아키타입 조합이 뭔지, 팀에 어떤 유형이 비어 있는지를 직함 대신 실행 방식으로 그려보는 거죠.

아키타입에 갇히지는 마세요

마지막으로 체르니 트윗 답글 중에 인상 깊은 트윗을 소개하려합니다. "자기를 특정 아키타입으로 분류하는 건 종종 사람이 야망을 넓히는 걸 가로막는다. 유연하게 있고, 목표 달성에 중요한 것에 몰두하고, 시간이 지나며 계속 흐려질 역할 경계에는 덜 신경 써라."

아키타입은 지금 이 순간의 내 상태를 읽어보는 프레임일 뿐, 나를 가둬두는 상자 같은 건 아닙니다. 사실 중요한 건 내 일을 통해 가치를 만들어내는 것이지, 내가 어떤 유형인지 이해하는 것 자체가 어떤 가치를 만들어내지는 않으니까요. 프로젝트가 바뀌면 나도 다른 아키타입의 역량을 펼쳐보일 수도 있습니다. 위에 소개한 말이 기우처럼 보이는 측면도 있지만, 한번쯤 생각해봐야 할 지점 같습니다. 일을 하다보면 종종 나도 모르게 주어진, 정해진 틀 안에서만 일하려 하기도 하니까요.

AI로 인한 변화가 너무 빨라 기존의 프레임워크로는 변화를 읽기가 어려워졌습니다. 그러다 보니 이런 앞서가는 사람들이 제안하는 프레임워크를 참고해보는 것도 지금의 위치를 이해하기에 좋은 방법이 아닐까 합니다. 지금 내가 어디에 서 있는지 한번 짚어보고, 내 제품이 그자리를 원하는지, 그렇지 않다면 내가 어느 쪽으로 조금 움직여야 할지를 한번 진단해보고, 또 다음에 프로덕트가 혹은 프로젝트가 바뀌면 다시 이 아키타입으로 내 상황을 바라보는 것도 앞을 모르는 세상에서 나름대로 좋은 길잡이가 되지 않을까 합니다.

]]>

논리적인 의사결정이 왜 프로덕트를 죽일까?

분명 검증된 모델을 가져왔고, 모두가 자기 자리에서 합리적으로 판단했다. 그런데 결과는 실패였다. 우리는 논리로 결정하지만, 그 끝에서 제품을 쓰는 사람은 감정으로 반응하기 때문이다. 이 글은 그 ‘범인 없는 실패’가 어디서 조립되는지에 대해 살펴보고자 한다.

나는 십수 년간 콘텐츠를 만들어 왔고, 그동안 여러 프로젝트가 무너지는 걸 가까이서 보며 ‘왜 다들 열심히 했는데도 이런 실패가 생기는가’를 오래 고민했다. 이 글은 그 고민의 첫 기록이자, 개발 조직에서 어긋남이 어떤 모양새로 생겨나는지에 대한 고찰이다. 특정 회사나 제품을 짚는 대신 ‘유형’으로만 다루는 건, 어디서나 되풀이되는 패턴이라고 보기 때문이다.

한 번쯤 본 적 있는 장면일 것이다. 해외에서 크게 성공한 어떤 서비스가 있다. 만든 회사도 크고, 지표도 화려하다. 누군가 그걸 가져와 말한다. “이거, 저쪽에서 이만큼 됐대. 우리도 잘하는 걸 좀 얹어서 만들면 되지 않겠어?”

반대할 이유가 마땅치 않다. 검증된 레퍼런스가 있고, 우리에게는 그 위에 얹을 만한 강점이 있다. 다만 이때 가져오는 건 대개 그 서비스가 성공한‘결과’이지, 그것을 성공시킨‘인과’가 아니다. 무엇이 사람을 붙들었는지는 잘 보이지 않고, 눈에 띄는 건 화면과 기능과 숫자 같은 겉모습뿐이다. 그런데도 회의실의 공기는 합리적이다. 그렇게 프로젝트가 시작되고, 시간이 지나고, 결과가 나온다. 안 된다. 숫자는 오르지 않고, 공들여 붙인 기능은 아무도 쓰지 않는다.

흔히 여기서 범인을 찾기 시작한다. 윗선이 트렌드만 좇았다거나, 기획이 안일했다거나, 시장을 잘못 읽었다거나. 그런데 나는 이 ‘범인 찾기’ 자체가 대개 헛다리라고 생각한다. 더 불편한 쪽은 따로 있다. 다들 제 자리에서는 옳게 판단했는데도 결과가 무너지는 경우다. 어떻게 그런 일이 가능한지, 한 장면을 펼쳐 보는 데서 시작하자.

하나. 각자는 모두 옳았다

AI로 콘텐츠를 만들어 온 어느 조직이, 성장을 위해 숏폼과 공개 피드 기능을 새로 얹기로 했다고 하자. 결정은 대략 이렇게 내려진다.

경영을 책임지는 사람은 성장을 만들어 내야 한다. 마침 숏폼은 지금 가장 검증된 채널이고, 모두가 그쪽으로 가고 있다. “검증된 흐름을 탄다”는 건 그 자리에서 가장 방어 가능한 판단이다. 그 아래에서 실무를 끄는 사람은 “그럼 우리가 가장 잘하는 걸 얹자”고 답한다. 모르는 길을 새로 파기보다, 우리가 이미 잘하는 AI 콘텐츠를 숏폼에 결합하는 편이 안전하고 자연스럽다. 그리고 만드는 사람은 그 방향을 받아, 필요한 기술과 레퍼런스를 찾아 가장 합리적인 구현 경로를 짠다. 저마다 자기 자리에서 할 수 있는 가장 그럴듯한 판단을 한 것이다. 그런데 합쳐 놓으니 결과는 실패였다.

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

무엇이 빠졌을까? 회의실에서 오간 건 성장률과 체류시간, 트래픽 같은 숫자였다. 모든 판단은 그 숫자 위에서 논리적으로 내려졌다. 그런데 그 숫자 어디에도 잡히지 않은 것이 하나 있다. 바로 ‘이 사용자가 이 서비스를 어떤 마음으로 쓰는가’다. AI로 대화하고 콘텐츠를 만드는 사람들 상당수는, 자기만의 작은 세계에서 사적으로 그것을 즐긴다.

실제로 제타나 크랙 같은 국내 AI 캐릭터 채팅 서비스는 ‘비공개 캐릭터’와 ‘나만의 공간’을 핵심 기능이자 홍보 문구로 내세운다. 자신이 만든 것을 남에게 전시하기보다, 혼자 혹은 좁은 울타리 안에서 즐기려는 수요가 그만큼 크다는 뜻이다. 그런 사용자에게 ‘공개하고 퍼뜨리는’ 숏폼·피드의 속성은, 성장의 도구이기 전에 그들이 가장 원치 않던 방향이다.

게다가 숏폼의 바이럴은 무작위성이 크고 빠른 실험과 즉흥적 대응을 먹고 자라는데, 결재 단계가 여럿인 조직은 그 타이밍을 좀처럼 맞추지 못한다. 조직 차원에서 숏폼으로 성과를 낸 사례들을 들여다보면, 출시 한참 전부터 다져 온 커뮤니티와 계획된 사전 바이럴, 마케팅 조직의 끈질긴 풀뿌리 활동이 그 아래 깔려 있는 경우가 많다. 개인이 올린 영상 하나가 우연히 터지는 것과는 전혀 다른 이야기다. 그런데 이런 사전 작업은 개발 일정표에 항목으로 잡히지 않는다.

그래서 돌아온 비용은 이렇다. 공들여 붙인 기능은 켜져 있는데 아무도 그 길로 들어오지 않고, 정작 기존의 핵심 사용자는 “내 공간이 전시장이 되는 것 같다”며 거리를 둔다. 새 사용자도 얻지 못하고, 본래 우리를 지탱하던 정서마저 건드리는 양쪽을 함께 잃는 자리에 도달한다. 카카오톡 역시 체류시간을 늘리려 공개 피드와 숏폼을 전면에 얹었다가, 사용자들의 거센 저항을 받고 되돌린 일이 있었다. 규모만 다를 뿐, 어긋남이 조립되는 방식은 놀랄 만큼 닮았다.

<출처: 카카오톡 왜 자꾸 업데이트해요? / 스브스뉴스 >

그러니 흔히 하듯 여기서 범인을 찾는 건 대개 헛다리다. 각자의 자리에서 나온 합리가 같은 방향으로 정렬되지 못했을 뿐이다. 그리고 그 어긋남은 숫자가 아니라, 사용자의 마음이 있는 자리에서 벌어진다.

실패는 비합리의 산물이 아니다. 각자의 합리성이 같은 방향으로 정렬되지 못한 결과다.

둘. “우리는 제대로 일하고 있다”는 착각

그렇다면 의문이 남는다. 그렇게 똑똑한 사람들이 모여 있는데, 왜 아무도 중간에 멈추지 못할까. 분명히 잘못된 방향으로 가고 있는데도 말이다.

이유는 역설적이다. 모두가 너무 열심히, 너무 ‘제대로’ 일하고 있기 때문이다. 시제품을 만들어 빠르게 측정하고, 지표를 보고, 성공 사례를 벤치마킹한다. 회의에서는 그럴듯한 숫자가 담긴 장표가 돌아다닌다. 이 모든 절차는 “우리는 데이터에 기반해 합리적으로 일하고 있다”는 감각을 채워준다. 문제는 그 감각이 진짜 비어 있는 것을 가려버린다는 데 있다. 재기 쉬운 숫자를 목표인 양 떠받들거나, 보기에는 좋지만 어떤 결정으로도 이어지지 않는 숫자를 들여다보는 오래된 함정에 계속 빠지는 이유도 같다. 무언가를 부지런히 측정하고 있다는 사실 자체가 알리바이가 되기 때문이다.

이 알리바이는 지표에만 깃들지 않는다. 기능을 더하는 일에도 똑같이 깃든다. 예를 들어, 어떤 캐주얼 게임을 만든다고 해 보자. 이미 성공 사례가 수두룩한 장르이니, ‘핵심 재미야 당연히 보장되겠지.’라는 가정에서 출발한다. 그리고 거기에 저마다 ‘이건 있어야 하지 않나’ 싶은 시스템을 하나씩 얹는다. 랭킹을 넣고, 출석 보상을 만들고, 매일 도는 던전을 추가하고, 커뮤니티 기능도 이것저것 붙인다. 하나하나는 다 그럴듯하고, 더할 때마다 ‘진척’이라는 감각이 쌓인다. 계획표의 항목은 차곡차곡 지워지고, 내부적으로는 무언가 완성되어 가는 듯하다.

<출처: Gemini로 이미지 생성>

그런데 막상 출시하면, 정작 손대지 않은 ‘핵심 재미’가 밋밋했다는 사실이 그제야 드러난다. 사용자는 기대만큼 오지 않는다. 반면 급하게 붙여 둔 그 많은 기능은, 출시 이후 전부 유지보수해야 할 짐으로 남는다. 지금 인력으로는 감당이 안 되고, 지친 사람들이 하나둘 빠져나가기 시작한다. 남은 이들은 더 무거워진 업무와 지표 압박 속에서, 역설적이게도 ‘콘텐츠를 더 넣어 반등시키자’는 결정으로 떠밀린다. 그러면 유지보수 비용은 또 늘고, 어딘가에서 사고가 터지고, 겨우 수습하고 나면 어느새 다시 제자리다. 빠져나오려 발버둥 칠수록 더 깊이 가라앉는 늪이다.

이 모든 건 ‘성공한 장르니까 핵심 재미야 당연히 되겠지’라는 믿음에서 비롯됐다. 그럴듯하게 들리지만, 사실은 가장 중요한 것을 들여다보지 않으려고 논리로 덮어 둔 감정의 공백에 가깝다. 정작 우리가 참고한 그 성공작들이 사용자에게 어떤 ‘감성’으로 가닿았는지는 끝내 따져 보지 않은 것이다. 누군가는 한눈에 사로잡는 고유한 아트워크로, 누군가는 사용자와 함께 쌓아 온 입소문과 방송 같은 바깥의 이야기로, 또 누군가는 군더더기 없이 빽빽하게 짜인 플레이의 밀도로 사람의 마음을 붙들었다. 그 ‘무엇이 사람을 붙들었나’를 건너뛴 채, 겉으로 드러난 기능 목록만 베껴 온 셈이다.

모든 조직이 그렇다는 건 아니다. 현장은 저마다 다르다. 다만 손쉬운 숫자를 목표로 떠받드는 일이든, 보기 좋은 숫자를 들여다보는 일이든, 끝없이 불어나는 기능이든, 절차가 만들어 주는 알리바이든, 결국 같은 곳을 가리킨다. 우리가 ‘제대로 일하고 있다’고 느끼게 해 주는 바로 그 장치들이, 정작 비어 있는 핵심 가정을 가려 버린다는 것. 그래서 우리는 늘 경계해야 한다. 절차가 통찰의 자리를 대신 차지하고 있지는 않은지를.

셋. 기준점은 도구가 아니라 사용자 경험에서

여기까지 오면 답이 뻔해 보인다. 절차에 매몰되지 말고, 핵심 가정부터 제대로 세우면 된다. 사용자가 진짜 무엇을 원하는지 정의하고, 그걸 빠르게 검증하면 된다. “작게 만들어 시장에 던져 보고, 반응을 측정해 배운 걸로 다음을 고쳐 나가라.” 요즘의 수많은 제품 방법론이 입을 모아 그렇게 가르친다.

게다가 지금은 그 ‘빨리 만들기’가 거의 공짜가 된 시대다. 시제품을 뽑는 비용이 바닥까지 내려왔다. 마음만 먹으면 누구나 시제품 수십 개를 만들어 동시에 던져 볼 수 있다. 그러니 반론도 정당하다. 처음 세운 가정이 좀 허접하면 어떤가. 일단 던지고, 반응을 보고, 아닌 걸 쳐내면서 진짜를 깎아 나가면 되지 않나. 가정을 완성해 두고 시작하는 게 아니라, 검증으로 골라내는 거니까.

맞다. 그런데 여기에 잘 이야기되지 않는 맹점이 있다.

쳐내는 데에도 기준이 필요하다. 시제품 수십 개를 돌리면 지표 수십 개가 나온다. 그런데 어떤 숫자가 진짜 신호이고 어떤 게 노이즈인지, 이 반응이 사용자가 정말 원해서인지 그냥 새로워서인지, 측정이 어디서 왜곡된 건 아닌지, 누군가는 매번 판단해야 한다. 그 판단의 잣대는 시제품 더미 안에 들어 있지 않다. 무엇을 신호로 볼지에 대한 눈이 먼저 서 있어야, 비로소 쳐내기가 시작된다. 그 눈이 없으면 수십 개의 결과는 그냥 수십 개의 숫자일 뿐이다. 도구가 싸지고 시제품이 많아질수록, 정작 희소해지는 건 이 눈이다.

그러니 ‘빨리 만들어 쳐낸다’는 것도, 알고 보면 앞서 말한 절차의 또 다른 얼굴이다. 측정하고 벤치마킹하던 자리에 ‘빠른 빌드’가 들어섰을 뿐이다. 우리는 ‘이만큼 많이 만들어 던져 봤다’는 자기 위로 속에서, 어느새 통찰까지 갖춘 듯 행동하기 시작한다. 하지만 시제품을 백 개 던져도, 무엇을 보고 무엇을 버릴지 모른다면 백 개의 숫자가 쌓일 뿐이다. AI는 그 숫자를 정리해 주지만, 그중 무엇이 핵심인지까지 결정해 주지는 않는다. 결국 빠른 빌드는 빈 가정을 더 빨리, 더 많이 찍어내는 도구가 될 수도 있다.

그렇다면 그 자리는 무엇으로 채우는가. 더 정교한 방법론은 답이 아니다. 방법론이 못 채우는 자리를 또 다른 방법론으로 채우려는 건 같은 실수의 반복이다. 측정도, 빠른 빌드도, 잘 쓰인 문서도 닿지 못하는 그 자리는 결국 사용자 경험에서 출발할 수밖에 없다. 여기서 사용자란 꼭 앱을 내려받는 개인 소비자만은 아니다. 우리 소프트웨어를 실제로 쓰게 될 다른 팀이든, 계약을 맺은 기업의 담당자든, ‘우리가 만든 것을 끝에서 직접 겪는 사람’은 모두 여기 들어간다. 무엇을 신호로 볼지 가리는 눈도, 결국 그 사람을 직접 겪어 본 데서만 자란다.

우리가 무엇을 만들든, 그 끝에서 그것을 실제로 쓰는 건 결국 사람이다. 그리고 사람은 자기가 겪은 경험의 결과를 우리에게 말해 준다. 예를 들어, “광고가 너무 많다”라는 또렷한 피드백을 곧이곧대로 “광고를 빼 달라”로 받으면 길이 막힌다. 그 말을 만드는 쪽의 언어로 옮겨 보면 대개 “광고 자체가 싫다”기보다 “광고가 내 경험을 끊는 게 싫다”에 더 가깝다. 그렇게 한 번 번역하고 나면, 손대야 할 곳이 ‘광고를 없앤다’에서 ‘경험의 흐름을 어떻게 지킬까’로 통째로 옮겨 간다.

<출처: 퍼포먼스 마케터들이 토스 광고를 하는 진짜 이유 (ft. 토스애즈 상품 소개서) / LEVER Xpert>

이때 답은 기획서 위에서 계산되지 않는다. 어떻게 손대야 사용자가 흐름이 끊겼다고 느끼지 않으면서도 우리 쪽 손익이 무너지지 않는지, 그 둘이 가장 덜 부딪치는 지점은 직접 그 서비스를 써 보며 몸으로 겪어야 비로소 가늠된다. 단순한 지표만으로는 한계가 있다. 지표는 대개 가까운 시일의 인과만 비춰 주기 때문이다.

어떤 변화를 줬을 때 다음 주 숫자가 어떻게 움직이는지는 보여 줘도, 그 변화가 반년 뒤 사용자의 잔존과 애착으로 어떻게 이어지는지까지는 좀처럼 말해 주지 않는다. 결국 사용자가 말하는 것과 만드는 쪽이 실제로 풀어야 하는 것 사이의 간극은 명세서로 메워지지 않는다. 무엇이 사람의 마음을 건드리고 무엇이 거스르는지를 논리로 역산하는 게 아니라 먼저 느끼는 것. 감성은 논리의 반대편이 아니라, 논리가 딛고 설 바닥인 셈이다.

마치며

그렇다면 우리는 각자의 자리에서 무엇을 해야 할까? 흔히 우리는 자기 자리에서 ‘무엇을 더 잘할까’를 묻는다. 그러나 정작 어긋남을 막는 건, ‘내 자리에서는 무엇이 안 보이는가’를 점검하는 일이다. 앞의 세 사람을 다시 떠올려 보자. 숫자를 들고 결정하는 사람은 그 숫자 이면에 어떤 마음이 깔려 있는지를 굳이 들여다보려 애써야 하고, 우리가 잘하는 걸 얹자던 사람은 그 강점을 다른 것과 붙였을 때 어떤 리스크가 따라오는지를 먼저 점검해야 한다.

구현을 맡은 사람은 자신이 만들 것뿐 아니라 ‘내가 만들지 못하는 것이 무엇인지’를 짚어야 한다. 이를테면 일정을 산출할 때, 기능을 짜는 데 며칠이 드는지만이 아니라, 그 기능이 사용자에게 어떤 경험을 주는지를 가늠하는 일까지 그 안에 들어와야 한다. 각자가 자기 시야의 사각을 솔직히 내놓을 때, 한 사람은 끝내 볼 수 없던 그림이 비로소 겹쳐 보인다.

제대로 된 분석은 논리와 감성을 따로 떼어 두는 게 아니라, 같은 선 위에 올려놓고 인과를 함께 보는 일이다. 표면의 지표 뒤에 어떤 마음과 굴곡이 숨어 있는지, 그건 화려한 숫자와 그래프가 대신 보여 주지 않는다. 그리고 이 재정리는 결코 추상적인 다짐에 그치지 않는다. 논리와 감성을 같은 선에 놓고 보기 시작하면, 회의 테이블에서 무엇을 신호로 받아들이고, 무엇을 흘려보낼지가 달라진다. 끝내 어떤 결정을 내리는지도 달라지기 때문이다.

이 과정을 놓쳤다면, 어쩌면 지금 다음과 같은 일이 벌어질 수도 있다.

첫째, 회의 테이블에 오르는 것이 줄곧 숫자와 화면뿐이고, ‘사용자가 이걸 어떤 마음으로 받아들일까’라는 물음은 좀처럼 등장하지 않는다.
둘째, ‘이 결정이 핵심 경험을 어떻게 바꾸는가’라는 질문이 일정과 비용에 밀려 늘 뒷순위로 내려간다.
셋째, 같은 지표를 놓고도 사람마다 “이게 핵심”이라 가리키는 곳이 다르다.
넷째, 만든 것을 사용자의 감성에서 다시 더듬어 보는 일정은 어디에도 없고, 개발 항목만 차곡차곡 늘어간다.

이 중 하나라도 짚이는 데가 있다면, 더 정교한 지표나 더 빠른 빌드가 필요한 게 아니다. 각자의 사각을 사용자의 자리에서 한 번 맞춰 보고, 논리와 감성 사이의 인과가 어디서 끊어졌는지를 점검해야 한다는 신호다.

이 글에서 적은 건 어디까지나 내가 지나온 자리에서 비친 풍경일 뿐이다. 나와 다른 길을 걸어 이미 더 나은 답을 찾은 조직도 분명 많을 것이고, 어쩌면 이 글의 어떤 대목은 누군가에게는 한참 전에 지나온 이야기일지도 모른다.

그래서 한 편에 모든 걸 담기보다는 그동안 부딪히며 겪은 것들을 기회가 닿을 때마다 조금씩 풀어 보려고 한다. 이 글에 대한 비판도, 정반대의 반론도 당연히 있을 거다. 또 그런 목소리가 있어야 이 이야기도 비로소 다음으로 나아갈 수 있다고 믿는다. 저마다 각자의 자리에서 각자의 무게를 견디며 프로덕트를 만들어 가는 모든 분들을 응원하며, 글을 마친다.

]]>

990원이 찍혔다: 바이브 코딩이 유료 서비스가 되기까지

지난 글 “바이브 코딩으로 7일간 900커밋, 디자이너의 앱 출시기”에서는 디자이너가 바이브 코딩으로 '문채'라는 앱을 7일 만에 세상에 내놓은 이야기를 들려드렸습니다. 감사하게도 많은 분들이 관심을 가져주셨는데요. 사실 그 글에서 슬쩍 언급했던 제 첫 번째 프로젝트가 하나 더 있습니다. 바로 카카오톡 대화를 AI로 분석해 주는 ‘톡시그널(Toksignal)’이라는 웹 서비스입니다.

저는 톡시그널을 아이디어부터 웹 제작까지 단 3일 만에 완성했습니다. 그러나 진짜 현실은 웹을 다 만들고, 이 서비스를 '유료'로 전환하겠다고 마음먹은 순간부터였습니다. '990원'을 받기 위해 결제 심사, 복잡한 서류 작업, 개인정보 보호, 보안 규정 같은 현실의 벽을 마주해야 했죠. 서비스 완성도와 신뢰 구조를 갖추는 과정이 가장 큰 도전이었는데요. 웹을 만드는 것보다 더 어려운 건 990원을 받는 거였습니다. 이번 글은 그 여정에 대해 전해드리려고 합니다.

<출처: 작가>

시작은 사소한 호기심에서

카카오톡 대화에서 설정 창을 열어보면, ‘대화 내보내기’ 기능이 있습니다. 버튼을 누르면 텍스트 파일(txt)이 다운로드 되는데요. 어느 날 이걸 AI한테 던져봤습니다. “이 대화 분석해 줘.” 그런데 결과가 생각보다 너무 흥미진진했습니다. 누가 먼저 연락하는지, 대화의 온도는 어떤지, 관계 패턴이 어떤지, 숫자로 보니까 느낌이 아니라 신호가 보였습니다. “이거 나만 재밌는 게 아닐 것 같은데?”라고 생각했죠.

<출처: 작가>

처음에는 단톡방 분석기로 시작했습니다. 누가 어떤 말을 많이 하는지 분석할 용도로 만들었죠. 그런데 사용해 보니 2인 대화가 훨씬 재밌었습니다. 연인, 썸, 친구 등 두 사람 사이의 대화에는 관계의 온도가 고스란히 담겨 있었거든요.

<출처: 작가>

이름은 여러 후보가 있었는데 ‘톡시그널(Toksignal)’로 확정했습니다. 카카오톡과 시그널을 합친 단어로 “대화 속에 숨어 있는 관계의 신호”라는 뜻입니다. 2월 27일에 아이디어를, 다음 날인 2월 28일에 동작하는 웹까지 하루 만에 만들었습니다. 여기까지는 빠릅니다. 바이브 코딩이니까요. 문제는 그다음부터 시작이었죠.

호기심에서 웹까지

<출처: 작가>

이전 글에서 소개한 문채(문장 채집 앱)는 제가 필요해서 만든 앱이었지만, 톡시그널은 방향이 조금 달랐습니다. 제가 필요해서 만들었다기보단, 카카오톡 대화를 내보내기 해서 직접 분석해 봤을 때 “이거 재밌겠는데?”라는 생각이 먼저였죠. UX/UI 개선, 코드 오류 수정, 베타 테스트까지 3일 만에 끝냈습니다. 그다음 지인에게 실제 카카오톡 대화를 올려보라고 부탁했더니, 피드백이 쏟아졌습니다. “분석 결과가 이상하다”, “글씨가 잘린다”, “이 버튼이 뭔지 모르겠다”, “후킹이 아쉽다” 등의 의견울 줘서 하나씩 고쳐나갔습니다.

여기까지는 수정을 반복하는 과정이 문채와 비슷했습니다. 코드를 만드는 건 바이브 코딩으로 충분했으니까요. 그런데 톡시그널은 결정적으로 다른 점이 하나 있었습니다. 바로 사용자에게 돈을 받기로 했다는 겁니다.

“돈을 받겠다”고 결정한 순간

이날부터 모든 게 달라졌습니다. 저는 바로 도메인을 샀습니다. 그리고 결제 시스템은 토스페이먼츠(Toss Payments)를 골랐죠. 심사를 넣고 직접 결제를 붙이는 것은 바이브 코딩으로 그냥 웹사이트를 만드는 것과는 완전히 다른 일이었습니다. 결제를 붙이려면 사업자등록증, 통신판매업 신고, 개인정보 처리방침이 사이트에 노출되어야 하고, 환불 정책도 명시해야 합니다. 코드로 결제창을 띄우는 것까진 클로드가 해줬습니다. 그런데 서류 준비, 심사 자료 정리, 법적 요건 등은 AI가 대신해 줄 수 없었죠.

<출처: 작가>

같은 날 저는 카카오 소셜 로그인, 구글 소셜 로그인, 분석 결과 저장, 어드민 대시보드까지 넣었습니다. 보안 PR도 4개를 머지했습니다. 결제가 들어가니까 누군가 결제를 조작하면 어쩌지라는 생각이 들고, 보안이 걱정됐습니다. 그래서 클로드에게 보안 전문가 역할을 시켜 하나씩 점검했고, 결제 관련 코드는 직접 동작을 확인하며 일일이 테스트했습니다. 돈을 받는 순간, 버그는 버그가 아니라 사고가 됩니다. 990원이든 99,000원이든, 돈을 낸 사용자에게 오류는 신뢰의 문제였습니다.

코드를 안 쓴 날

<출처: 작가>

토스페이먼츠에 심사를 넣고 기다리는 동안, 법적 리스크도 검토했습니다. 카카오톡 대화를 분석하는 서비스다 보니 민감한 지점이 많았거든요. 가장 오래 고민한 질문이 있었습니다. “대화 상대방의 동의 없이 대화를 분석해도 되는 걸까?” 결론부터 말씀드리면, 카카오톡 ‘대화 내보내기’는 본인이 참여한 대화만 추출할 수 있습니다. 타인의 대화를 몰래 가져오는 게 아닙니다. 그래서 대화의 패턴과 관계 흐름만 분석할 뿐, 누가 무슨 말을 했는지 원문이 그대로 타인에게 공개되는 구조가 아닙니다.

그래도 충분하지 않다고 생각했습니다. 이용 약관에 AI 활용 표기를 넣었고, 분석 전 동의 절차를 추가했습니다. “상대방의 동의를 권고한다”라는 안내 문구도 포함했습니다. 물론 이게 완벽한 답은 아닐 수 있습니다. 하지만 이 문제를 무시하고 그냥 넘어가는 것과 고민 후 최선의 장치를 마련하는 것은 다르다고 생각했죠.

그리고 데이터 구조 자체를 저장되지 않게 설계했습니다. 사용자가 대화 파일을 업로드하면 서버에서 AI 분석이 돌아가고, 분석이 끝나는 즉시 원본 파일은 삭제됩니다. 서버에 남는 건 분석 결과 요약뿐이고, 원문 대화 내용은 어디에도 저장되지 않습니다. 운영자인 저조차도 볼 수 없는 구조입니다. “안 보겠습니다”가 아니라 “볼 수 없습니다”를 만들고 싶었거든요.

기다림, 그리고 디테일의 늪

<출처: 작가>

그래서 토스페이먼츠 심사를 기다렸습니다. 그리고 분석 실패 시에 자동 복구되는 기능도 넣었습니다. 990원을 냈는데 제대로 분석이 안 되면 그건 사고니까요. AI가 가끔 이상한 걸 주거나, 타임아웃이 나서 자동으로 재시도하는 로직을 만들었습니다.

다음으로 PG사마다 요구하는 게 달라서, 카카오페이 심사 자료를 정리했습니다. 디자인도 많은 수정을 거쳤는데요. 이모지를 제거하고 넘버링으로 교체했습니다. 공유 카드 헤드라인은 고정 문구 대신 매번 다른 헤드라인이 나오도록 동적으로 바꿨습니다. 데이터를 저장하지 않는 부분에 대한 강조 문구도 추가하고, 히어로 섹션 최상단에 신뢰 배너도 넣었습니다.

마지막으로 가트맨의 관계 이론과 로버트 스턴버그의 삼각형 이론을 AI 분석 근거로 적용했습니다. AI가 학술적 프레임워크에 기반해 분석한다는 걸 보여주고 싶었거든요.

인앱 브라우저에 대한 이슈도 이때 잡았습니다. 카카오톡에서 링크를 열면 카카오 인앱 브라우저가 뜨는데, 여기서 분석 결과 카드가 저장되지 않았거든요. 명색이 카카오톡 기반 서비스인데, 카카오 인앱 브라우저에서 저장이 안 된다면 치명적이라 생각했습니다.

가격 정책: 990원의 무게

<출처: 작가>

서비스의 가격, 어떻게 정해야 할까요? 너무 저렴하면 가치를 못 느끼고, 또 너무 비싸면 재미로 해보는 사용자가 오지 않습니다. “한번 사용해 볼까?” 할 수 있는 심리적 허들이 필요했습니다.

지금은 매달 50명 한정으로 로그인하면 첫 1회 분석을 무료로 제공하고 있습니다. 맛보기 프리뷰와는 다릅니다. 맛보기는 결과 일부만 보여주는 거고, 1회 무료는 전체 분석을 그대로 경험할 수 있습니다. 서비스의 가치를 직접 느낀 다음에 990원이라는 가격을 판단하게 하고 싶었습니다. “한번 써보고 결정하세요.”가 가장 정직한 설득이라고 생각했거든요.

PG 수수료, 서버비, AI API 호출 비용 등을 빼면 솔직히 건당 남는 건 별로 없습니다. 그래도 내가 만든 서비스에 누군가 돈을 냈다는 경험 자체가 중요했죠. 요즘 바이브 코딩으로 서비스를 만드는 사람은 정말 많아졌습니다. 그런데 결제를 붙이고, PG 심사를 통과하고, 법적 요건을 갖추고, 진짜 돈을 받는 과정까지 가는 사람은 많지 않습니다. 저는 그 사이가 생각보다 멀다고 느꼈습니다.

혼자 삽질하며 배운 것들

코드보다 서류 심사가 더 오래 걸린다: PG 심사가 영업일 기준 7일, 카드사 심사가 또 7일이나 걸립니다. 코드는 하루면 되는데 심사는 2주를 기다려야 합니다.
돈 받는 순간 기준이 달라진다: 무료일 때는 괜찮았던 버그가 유료에서는 사고가 됩니다. 에러 처리, 자동 복구, 환불 정책 이 세 가지는 결제 전에 반드시 갖춰야 합니다.
개인정보를 과소평가하지 마라: 개인정보 처리방침, 데이터 삭제 정책, 동의 절차는 나중에 하면 안 되고 처음부터 해야 합니다. 특히 대화 데이터를 다루는 서비스라면, “저장하지 않는다”를 약속이 아니라, 구조로 만들어야 합니다.
무료 체험은 필수다: 990원이라도 직접 써본 다음에 결제해야 납득이 됩니다. 맛보기 프리뷰와 1회 무료 분석, 이 두 단계가 전환율을 만들었습니다.
인앱 브라우저를 반드시 테스트해라 : 카카오톡, 인스타그램에서 링크를 열면 인앱 브라우저로 열립니다. 여기서 안 된다면 주요 유입 경로가 막힌 겁니다.

그래서 지금은?

<출처: 작가>

톡시그널은 지금도 서비스되고 있습니다. 아이디어에서 결제까지 만드는 건 며칠이면 되지만, 사용자에게서 돈을 받는 건 다른 차원의 일이었는데요. 이전 글에서 “바이브 코딩이 마법의 ‘딸깍’은 아니다”라고 말씀드렸는데, 이번에도 같은 이야기를 하게 됐습니다.

직접 경험해 보니 바이브 코딩의 진짜 도전은 코드를 생성하는 일이 아니었습니다. 그 코드를 온전한 서비스로 탈바꿈하는 것이었죠. 그리고 그 서비스로 수익을 창출하는 건 또 다른 과제였습니다. 여러분도 바이브 코딩을 하며, 비슷한 고민을 해보셨나요?

<참고>

]]>

같은 주에 나온 GPT-5.6과 Grok 4.5, 정부가 먼저 검토한 모델은

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

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

써볼 것: Grok 4.5 - 커서와 함께 만든 SpaceXAI의 새 모델, 지금 써볼 수 있어요
참고할 것: 오픈AI의 GPT-Live와 GPT-5.6 소개, 그리고 정부 승인 이야기 (내용이 좀 깁니다)
적용해볼 것: 클로드코드 팀이 정리한 루프 사용법 - AI에게 어디까지 맡길지 정하는 법

<출처: x.ai, Introducing Grok 4.5>

1. 써볼 것: 커서와 함께 만든 SpaceXAI의 새 모델, 지금 써볼 수 있어요

Grok 4.5는 SpaceXAI가 7월 8일 공개한 새 모델입니다. 코딩과 에이전트 작업은 물론 데이터 분석이나 문서 작업 같은 지식 노동까지 겨냥했는데요. 이미 커서나 Grok Build(SpaceXAI의 코딩 에이전트 도구)를 쓰고 있다면 지금 바로 Grok 4.5를 써볼 수 있습니다. 커서는 전 요금제에 포함돼 첫 주 사용량을 두 배로 주고, Grok Build는 SuperGrok이나 X Premium+ 구독자에게 한시적 무료로 제공됩니다.

SpaceXAI는 이 모델을 코딩 에이전트 커서와 함께 훈련했습니다. SpaceXAI는 일론 머스크가 이끄는 회사로, 원래 xAI였다가 SpaceX가 2026년 2월 흡수하면서 이름이 바뀌었습니다. 6월 중순 SpaceX가 커서를 600억 달러에 인수하겠다고 발표했으며, 이 딜은 올해 3분기에 마무리될 예정입니다. 오늘 소개할 Grok 4.5는 그 둘의 협력에서 나온 첫 모델입니다.

기존 커서 모델과 무엇이 다른가요?

커서에는 이미 Composer라는 자체 코딩 모델이 있었습니다. 코딩만 빠르고 싸게 처리하도록 좁게 다듬은 모델이었고, 중국 Moonshot AI의 오픈 모델 Kimi를 이어 학습해 만들었죠. Grok 4.5는 처음부터 더 크고 넓게 학습했습니다. 코딩뿐 아니라 데이터 분석, 금융, 법률 같은 지식 노동까지 다루도록요. SpaceXAI는 법률 작업 성능을 재는 Harvey Legal Agent Benchmark에서 1위를 기록했다고 밝혔고요.

훈련에는 수조 개 토큰 분량의 실제 커서 사용 기록이 들어갔습니다. 개발자가 코드베이스를 어떻게 다루는지, 에이전트가 도구를 어떻게 쓰는지가 담긴 데이터죠. 코딩 에이전트 회사와 손잡았기에 확보할 수 있던 데이터입니다.

<출처: cursor, grok-4-5>

실제 성능은 어떤가요?

성능은 발표만 보고 판단하기 어렵습니다. 항목마다 성적이 다르거든요. SpaceXAI는 다른 주요 모델보다 낫다고 했지만, 자기네가 공개한 벤치마크 차트를 봐도 앞서는 항목이 있고 뒤처지는 항목이 있습니다. 명령줄 작업을 재는 Terminal-Bench 2.1에서는 83.3%로, GPT-5.5(83.4%)와 거의 같고 Fable 5(84.3%)에 1점 차로 따라붙습니다. 반면 어려운 소프트웨어 문제를 모은 SWE-Bench Pro에서는 64.7%에 그쳐, Opus 4.8(69.2%)이나 Fable 5(80.3%)에 뒤처집니다. 네 개 벤치마크를 놓고 보면 대체로 Fable 5가 앞서고요.

그래서 이 모델의 강점은 벤치마크 순위가 아니라 작업 하나를 끝내는 데 드는 비용입니다. Grok 4.5는 100만 토큰 기준 입력 $2, 출력 $6에 초당 80토큰 속도로 제공됩니다. Opus 4.8이 입력 $5, 출력 $25인 걸 보면 꽤 저렴한 편이죠. SpaceXAI는 토큰 효율도 최신 선도 모델의 약 두 배라고 밝혔습니다. 같은 작업을 더 적은 토큰으로 끝내니, 실제로 드는 비용 차이는 가격표보다 더 벌어지는 셈입니다. 더 빠른 응답이 필요하면 입력 $4, 출력 $18짜리 빠른 변형도 있고요.

블룸버그는 코딩을 넘어 법률·금융까지 겨냥한 이번 모델을, 머스크의 회사가 두 경쟁자(앤트로픽·오픈AI)와 같은 시장에서 붙어보려는 신호로 읽습니다. 뒷이야기도 하나 있는데요. 여러 보도에 따르면 SpaceXAI는 앤트로픽과 구글에도 연산 자원, 즉 AI 훈련에 쓰는 대규모 컴퓨팅 설비를 빌려주는데, Grok 4.5도 그 일부에서 훈련됐다고 합니다. 경쟁사끼리 같은 설비를 나눠 쓰는 셈이죠.

누구에게 좋을까요?

이미 커서를 쓰고 있는 사람. 쓰던 환경에서 모델만 Grok 4.5로 바꿔 부담 없이 성능을 가늠해볼 수 있어요.
코딩 외에 문서 작업까지 AI에 맡기고 싶은 사람. Grok Build는 웹 조사와 여러 시트 수식이 들어간 엑셀, 파워포인트, 워드 작업도 다룹니다.
작업량이 많아 토큰 비용이 부담인 사람. 벤치마크 최상위보다 작업당 비용이 중요한 상황이라면 잘 맞습니다.
반대로 순수 코딩 성능이 최우선이거나 EU에서 쓰려는 사람에게는 아직 이릅니다. EU는 7월 중순 지원 예정이고, 코딩 성능만 놓고 보면 Fable 5나 GPT-5.5가 앞서는 항목이 많으니까요.

<출처: OpenAI>

2. 참고할 것: 오픈AI의 GPT-Live와 GPT-5.6 소개, 그리고 정부 승인 이야기

새 AI 모델이 나오면 보통 언제 써볼 수 있나부터 궁금해지죠. 그런데 오픈AI의 새 모델 GPT-5.6은 나올 때부터 아무나 쓸 수 없었습니다. 누가 먼저 쓸지를 미국 정부가 정했거든요.

사정은 이렇습니다. 오픈AI는 6월 26일 GPT-5.6을 공개하면서, 미국 정부와 협의한 결과 정부에 명단을 공유한 소수의 신뢰 파트너에게만 먼저 열겠다고 밝혔습니다. 여러 매체는 이를 대략 20개 조직이 개별 승인된 사례로, 미국 AI 기업이 정부 관리 명단 아래 프런티어 모델을 처음 출시한 일로 전했어요. 배경에는 6월 2일 나온 사이버보안 관련 행정명령이 있습니다. 가장 강력한 모델을 공개 전에 정부 검토에 올리도록 한 조치인데요. 지난 주 요즘 프로덕트 메이커에서 다룬 앤트로픽 Fable 5의 수출 통제도 같은 맥락입니다.

오픈AI는 자사 발표문에서 이 방식에 선을 그었습니다. 이런 정부 접근 절차가 장기적인 기본값이 돼선 안 된다고 밝혔거든요. 필요한 사람에게서 최선의 도구를 떼어놓는 일이라는 이유였습니다. 그러면서도 지금은 더 넓은 공개로 가는 가장 확실한 길이라 따른다고 했고요.

이 이야기는 사실 마무리됐습니다. 오픈AI가 7월 8일, 다음 날인 9일부터 GPT-5.6 Sol과 Terra, Luna를 일반에 공개한다고 밝혔거든요. 미국 상무부가 추가 검토와 협의를 거쳐 넓은 공개를 승인하면서, 2주 남짓 이어지던 정부 게이팅도 풀렸습니다. 이제는 누구나 쓸 수 있게 된 겁니다.

GPT-5.6은 어떤 모델인가요?

앞서 정부 게이팅에 관심이 쏠렸는데, 모델 자체는 어떨까요. GPT-5.6은 세 등급으로 나뉩니다. 플래그십 Sol, 일상 작업용 Terra, 빠르고 저렴한 Luna죠. 숫자는 세대를, Sol·Terra·Luna는 성능 등급을 뜻해요. 오픈AI 발표에 따르면 Terra는 GPT-5.5급 성능에 절반 가격입니다. 가격은 100만 토큰 기준 Sol이 입력 $5·출력 $30, Terra가 $2.50·$15, Luna가 $1·$6이고요.

오픈AI는 코딩·생물학·사이버보안에서 나아졌다고 밝혔는데, 이 수치들은 자체 평가라는 점을 감안해서 봐야 합니다. 특히 사이버보안이 정부가 주목한 대목이에요. 오픈AI 발표에 따르면 GPT-5.6 Sol은 취약점을 찾고 고치는 데는 강하지만, 테스트 조건에서 자율적으로 완전한 공격을 끝까지 수행하지는 못했고, 회사가 정한 위험 문턱은 넘지 않았습니다. 그래서 모델에 학습된 거부, 실시간 오용 분류기, 계정 검토 같은 여러 겹의 안전장치를 함께 붙였다고 해요.

<출처: openai.com, introducing-gpt-live>

대화는GPT-Live가, 어려운 생각은 뒤에서

GPT-5.6과 같은 주, 7월 8일에 오픈AI가 GPT-Live도 공개했습니다. ChatGPT의 새 음성 모델인데요. 오픈AI 발표에 따르면 매주 1억 5천만 명 넘게 음성으로 ChatGPT와 대화할 만큼, 음성은 이미 많은 사람이 쓰는 기능입니다. 이전 음성 기능은 사용자가 말을 멈출 때까지 기다렸다가 답을 해주는 쪽이었습니다. GPT-Live는 여기서 듣기와 말하기를 동시에 합니다. 대화 도중 음, 그래처럼 사람이 흔히 넣는 맞장구를 치기도 하고, 사용자가 생각하느라 잠깐 말을 멈춰도 끼어들지 않고 기다려준다고 합니다.

또 GPT-Live는 사용자와 말을 주고받는 데만 집중하고, 웹 검색이나 복잡한 추론처럼 시간이 걸리는 일은 뒤에 있는 더 똑똑한 모델(출시 시점엔 GPT-5.5)에 맡깁니다. 사용자가 어려운 걸 물으면 뒤 모델이 답을 찾는데, 그동안에도 GPT-Live가 대화를 이어가서 끊기는 느낌이 없죠. VentureBeat는 이 점을 두고, 더 똑똑해진 게 아니라 더 사람처럼 느껴지게 만든 것이라고 짚었습니다. 성능 경쟁과 별개로, 음성 대화에서 사용자가 실제로 느끼는 건 모델이 얼마나 똑똑한가보다 말이 얼마나 자연스럽게 오가는가라는 걸 짚은 접근이죠.

무엇을 얻어가야 하나요?

OpenAI는 이번 주에만 발표를 두 개 내놨습니다. 하나는 사람과 자연스럽게 대화하는 GPT-Live, 다른 하나는 어려운 추론을 더 잘하는 GPT-5.6입니다. 이 둘은 따로 쓰이는 모델이지만, 함께 맞물리기도 합니다. GPT-Live가 앞에서 사용자와 대화하다가 어려운 건 뒤에 있는 더 강력한 모델에 넘기는데, 지금은 그 자리에 GPT-5.5가 쓰이고 앞으로 GPT-5.6 같은 모델이 들어갈 수도 있죠. 이렇게 대화하는 쪽과 깊이 생각하는 쪽을 나눠두면, 둘을 따로 손볼 수 있습니다. 뒤에서 추론하는 모델만 더 좋은 걸로 바꿔도, 앞에서 대화하는 방식은 그대로 두고 답만 똑똑해지니까요.

프로덕트에 AI를 넣을 때, 우리는 흔히 가장 좋은 모델 하나를 골라 모든 일을 시킵니다. 그런데 OpenAI는 빠르게 답해야 하는 일과 오래 생각해야 하는 일을 처음부터 나눠, 서로 다른 모델에 맡겼습니다. 모든 걸 최고 모델에 몰면 느린 데다 비용 부담도 크니까요. 요청을 성격별로 갈라 쉬운 건 싸고 빠른 모델에, 어려운 것만 강력한 모델에 넘기면, 같은 결과를 훨씬 싸고 빠르게 낼 수 있습니다.

개발자라면 요청마다 다른 모델을 호출하도록 짜는 방식이고, 직접 개발하지 않더라도 적용할 원리는 같습니다. 단순 반복 작업은 빠른 모델에 맡기고, 판단이 필요한 작업만 가장 좋은 모델로 돌리는 거죠. 사실 우리가 AI에 시키는 일을 돌아보면, 굳이 비싼 모델이 필요 없는 작업에도 습관적으로 제일 좋은 모델을 부르는 경우가 꽤 있죠.

<출처: ClaudeDevs>

3. 적용해볼 것: 클로드코드 팀이 정리한 루프, AI에게 어디까지 맡길지 정하는 법

요즘 X에서는 프롬프트를 하나하나 넣는 대신 루프를 설계하라는 말이 자주 보입니다. 그런데 막상 루프가 뭔지 찾아보면 사람마다 정의가 조금씩 다르죠. 클로드 코드 팀이 이 개념을 정리한 글을 냈습니다. 6월 30일 블로그에 올라왔고, 7월 7일 X에서 공유되며 현재는 조회수 550만을 넘겼죠.

이 글은 루프를 무엇을 AI에 넘기느냐로 풀어냅니다. 클로드코드 전용 기능 이야기가 섞여 있지만, 핵심이 되는 관점은 어떤 AI 도구를 쓰든 그대로 옮겨 쓸 수 있죠. 여기서는 그 관점 위주로 정리해봅니다.

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

AI에게 일을 시킬 때 우리는 대개 매번 지시하고 결과를 확인합니다. 시키고, 보고, 다시 시키고요. 이걸 반복하다 보면 사람이 계속 붙어 있어야 합니다. 그런데 반복되는 일일수록, 지시하는 사람이 매번 개입하지 않아도 되는 부분이 생기죠. 클로드코드 팀은 이 개입을 어디까지 줄일 수 있는지를 네 단계로 정리했습니다.

루프를 네 단계로 나누면

클로드코드 팀은 루프를 멈춤 조건이 충족될 때까지 작업을 반복하는 에이전트로 정의합니다. 그리고 무엇을 사람이 넘기느냐에 따라 네 가지로 나눴어요.

턴 기반: 넘기는 건 검사입니다. 사용자가 시킬 때마다 AI가 작업하고, 다 됐다고 판단하면 멈춥니다. 짧은 작업에 맞는 방식입니다. 확인 방법을 지침 문서로 정리해두면 AI가 스스로 더 많이 점검합니다.
목표 기반: 넘기는 건 멈춤 조건입니다. 무엇이 됐을 때 끝인지를 정해주면 AI가 그 조건을 채울 때까지 반복합니다. 테스트 통과 개수처럼 명확히 잴 수 있는 기준일 때 잘 통합니다.
시간 기반: 넘기는 건 트리거입니다. 정해진 간격으로 AI가 알아서 돌게 합니다. 매일 아침 메시지를 요약하거나, PR 상태를 주기적으로 확인하는 식이죠.
능동: 넘기는 건 지시 자체입니다. 사람이 실시간으로 개입하지 않고, 이벤트나 일정에 따라 AI가 알아서 돕니다. 버그 리포트 분류나 마이그레이션처럼 잘 정의된 반복 작업에 맞아요.

핵심은 뒤로 갈수록 사람이 손 대지 않는 부분이 늘어난다는 겁니다. 처음엔 결과가 제대로 됐는지 확인하는 일을 넘기고, 다음엔 언제 멈출지, 그다음엔 언제 시작할지를 맡깁니다. 마지막엔 무엇을 시킬지까지 AI가 알아서 정하게 두고요. 넘기기 쉬운 일부터 맡기고, 큰 판단일수록 나중에 넘기는 거죠. 지금 가장 손이 많이 가는 일을 하나 떠올려보세요. 지금 가장 손이 많이 가는 일을 하나 떠올려보세요. 그 일의 어디까지 AI에 맡길 수 있을지, 이를테면 결과를 확인하는 일부터 넘겨볼 수 있을지 등을 가늠해보면 루프의 시작점이 보일 겁니다.

품질과 비용은 어떻게 지키나요?

넘기는 범위를 늘리다 보면 걱정이 생깁니다. AI가 알아서 도는데 결과가 엉망이면, 비용이 줄줄 새면 어쩌나 싶죠. 여기에 대한 클로드코드 팀의 답은 이렇습니다. 결과가 나쁠 때 그것만 고치고 끝내지 마세요. 내가 결과를 어떻게 확인하는지를 지침 문서로 적어두면, AI가 다음부터 그 방법대로 스스로 점검하니 같은 실수가 줄어듭니다. 검토는 그 작업을 한 AI 말고, 내용을 모르는 새 AI에게 따로 맡기는 게 좋아요. 앞선 작업을 안 봤으니 더 냉정하게 짚어주거든요. 비용은 일에 맞게 규모를 맞추면 됩니다. 사소한 일에까지 복잡한 루프를 쓸 필요는 없습니다. 값싸고 빠른 모델로 되는 일은 그쪽에 맡기고, 크게 돌리기 전에 작은 부분으로 먼저 돌려보면 됩니다.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

구글이 공개한 AI 에이전트 제작 노하우를 가져다 쓰는 법

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

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

써볼 것: Claude Fable 5 - 일주일 동안 무료로 열린 앤트로픽의 최신 모델
참고할 것: Atlassian DESIGN.md - AI가 만든 화면이 왜 다 비슷할까, 그 해법을 실제로 써본 후기
적용해볼 것: google/agents-cli - 구글이 공개한 AI 에이전트 제작 노하우를 가져다 쓰는 법

<출처: Claude >

1. 써볼 것: 일주일 동안 무료로 열린 앤트로픽의 최신 모델

한동안 막혀 있던 Claude Fable 5가 다시 열렸습니다. Fable 5는 Anthropic(앤트로픽)의 최신 모델인데, 이번엔 유료 구독자라면 일주일 동안 추가 비용 없이 써볼 수 있는 프로모션까지 붙었어요. 모델 선택기에서 골라 바로 쓸 수 있습니다.

무슨 일이 있었던 건가요?

Fable 5는 얼마 전까지 쓸 수 없었습니다. 보도에 따르면 발단은 보안 문제였어요. 한 연구진이 Fable 5에서 안전장치를 우회하는 프롬프트를 찾아냈고, 이 일을 계기로 6월 12일 미국 정부가 Fable 5와 상위 모델 Mythos 5에 수출 통제를 걸었습니다. 앤트로픽은 이 조치에 맞춰 두 모델을 잠시 전면 중단했고요. 그러다 6월 30일 미국 상무부가 통제를 풀면서, 7월 1일 Fable 5가 다시 열렸습니다.

무엇을 어떻게 쓸 수 있나요?

프로모션은 7월 1일 시작해 ~~7월 7일 밤~~(태평양 시간)에 끝납니다. (→ 7월 12일까지로 연장) Pro, Max, Team, 그리고 일부 Enterprise(조직 설정에 따라) 플랜에서 쓸 수 있고, 별도로 신청하거나 켤 것도 없어요. 주간 사용 한도의 최대 50%까지 Fable 5에 추가 비용 없이 쓸 수 있습니다.

쓸 수 있는 곳도 넓습니다. 웹, 모바일, 데스크톱은 물론이고 Claude Code(2.1.170 버전 이상), Cowork, Claude Tag 등에서 접근할 수 있습니다. 웹과 데스크톱, 모바일에서는 모델 선택기에서 Fable 5를 고르면 됩니다.

써보기 전에 알아둘 것

Fable 5는 다른 모델보다 주간 한도를 빨리 씁니다. 무겁고 강한 모델이라 같은 작업이라도 한도를 훨씬 빨리 쓸 수 있습니다.
50%를 다 쓰면 두 갈래입니다. 사용 크레딧(구독과 별도로 청구되는 추가 사용분)으로 Fable 5를 계속 쓰거나, 다른 모델로 바꿔 남은 한도를 쓰면 됩니다. 이미 다른 모델로 주간 한도의 절반을 썼다면 그만큼 Fable 5에 남는 여력도 줄고요.
7월 12일이 지나면 Fable 5는 주간 한도에 포함되지 않고, 그 뒤로는 사용 크레딧으로만 쓸 수 있습니다.
API로 쓰는 건 이 프로모션 대상이 아닙니다. 표준 요율로 따로 청구됩니다.

재개 자체는 반가운 소식이지만, 조건을 두고는 아쉽다는 반응도 나옵니다. PCWorld는 원래 예고했던 기간의 절반 수준이라는 점과 50% 한도를 두고 구독자들이 불만을 나타냈다고 전했어요. 해커뉴스에서도 이번 조치를 두고 의견이 오갔고요. 저 역시 일주일에 절반이라는 조건이 아쉽긴 합니다. 어차피 한시적이니 큰 프로젝트를 통째로 맡기기보다 평소 궁금하던 어려운 작업 한두 개에 몰아서 최신 모델의 실력을 가늠해보는 용도로 쓰는 걸 추천합니다.

<출처: Atlassian Blog>

2. 참고할 것: AI가 만든 화면이 왜 다 비슷할까, 그 해법을 실제로 써본 후기

AI에게 화면을 만들어달라고 하면 결과물이 어딘가 비슷합니다. 그라데이션 버튼, 대문자로 꽉 채운 제목, 뻔한 카드 배치, 아무도 요청하지 않은 호버 효과. 기능은 되는데 내 제품 같지가 않죠. 디자인 쪽에서는 이런 결과물을 슬롭(slop)이라고 부릅니다. 기능은 하지만 특색도 의도도 없는 산출물을 가리키는 말이에요. Atlassian(아틀라시안)이 이 문제를 겨냥한 형식 하나를 자기네 도구와 나란히 놓고 테스트한 뒤, 그 결과를 블로그에 공개했습니다.

왜 이런 게 나오나요?

AI는 내 브랜드나 컴포넌트, 디자인 패턴을 모르는 상태에서 화면을 만듭니다. 참고할 기준이 없으니 그동안 학습한 수많은 화면에서 가장 무난한 쪽으로 결과를 내놓습니다. 웹에서 흔히 보이는 화면이 곧 무난한 평균이니, 결과물도 어디서 본 듯한 모습으로 나오고요. 그래서 요즘 디자인 시스템 쪽의 큰 숙제는, 내 브랜드 색과 간격, 컴포넌트 규칙 같은 디자인 맥락을 AI에 어떻게 넘겨주느냐입니다. 이 맥락을 제대로 쥐여주면 결과물이 내 제품에 가까워지니까요.

DESIGN.md가 뭔가요?

DESIGN.md는 구글이 자사 디자인 도구 Stitch를 위해 만든 오픈소스 마크다운 형식입니다. 팀의 브랜드와 UI 패턴을 한 파일에 담아두고 프롬프트에 끼워 넣기만 하면, AI 결과물이 내 제품에 한결 가깝게 나오죠. 이는 파일 하나로 슬롭을 잡는 간단한 해법이라 꽤나 주목받았습니다.

파일은 두 부분입니다. 앞쪽은 기계가 읽는 부분으로 색, 타이포, 모양 같은 디자인 토큰을 나열하고, 뒤쪽은 사람과 AI가 함께 읽는 부분으로 색과 간격, 레이아웃을 왜 이렇게 정했는지 설명합니다. 다만 이건 시스템의 의도를 담는 형식이지, 실제 코드 라이브러리나 Figma 상세 스펙까지 담은 완전한 기술 명세는 아닙니다.

실제로 써보니 어땠나요?

아틀라시안은 이미 자기네 디자인 시스템을 AI에 먹이는 도구를 갖고 있습니다. 필요한 맥락을 그때그때 불러오는 MCP 서버와 AI 스킬인데요. 여기에 DESIGN.md를 만들어 나란히 비교해봤습니다.

프로토타입을 빠르게 만들 때는 DESIGN.md가 좋았다고 합니다. 아틀라시안의 연례 행사 Team '26의 대시보드 데모에 넣어보니, 뻔한 슬롭이던 화면이 알아볼 만한 아틀라시안 스타일로 바뀌었다고 해요. Tailwind나 Shadcn처럼 많이들 쓰는 공용 UI 도구를 손봐 화면을 처음부터 만들 때 잘 맞았고요.

반면 실제 프로덕션 코드에서는 자기네 MCP나 스킬보다 못했다고 합니다. 아틀라시안의 자체 테스트에서는 로그인 화면처럼 단순한 작업조차 DESIGN.md만 썼을 때 토큰(AI가 글을 처리하는 분량이자 비용의 단위)이 약 92% 더 들었고, 실행할 때마다 소비량 편차도 훨씬 컸다고 해요. 아틀라시안은 그 이유로 세 가지를 꼽았습니다.

맥락을 필요할 때 부르지 않고 매번 통째로 싣는 점
파일을 짧게 유지하려면 정작 중요한 설명을 잘라내야 하는 점
시스템 내부를 그대로 드러내다 보니 AI가 기존 컴포넌트를 가져다 쓰기보다 비슷한 걸 새로 만들어버리는 점입니다.

다만 아틀라시안도 이 수치는 자기네 환경에서 나온 결과일 뿐 결론은 아니라고 덧붙였습니다. 정확한 숫자보다는, 맥락을 통째로 싣는 방식이 프로덕션에서는 비용과 일관성에서 불리할 수 있다는 신호로 읽으면 됩니다.

무엇을 얻어가야 하나요?

그러니 물음은 DESIGN.md를 쓰느냐 마느냐가 아닙니다. AI에 맥락을 통째로 넘길지, 필요할 때 나눠 줄지를 상황에 맞게 고르는 거예요. 낯선 도구에서 빠르게 프로토타입을 만들거나, 고객이 자기 브랜드를 얹어 결과물을 자기 스타일로 뽑게 하고 싶을 때는 한 파일로 통째로 주는 DESIGN.md가 잘 맞습니다. 기존 시스템을 끌어오기 어려운 상황이니까요. 반대로 이미 컴포넌트와 규칙이 갖춰진 프로덕션에서는, 필요한 부분만 그때그때 불러오는 편이 더 싸고 정확합니다. 결국 내가 지금 만드는 게 맨바닥에서 새로 그리는 화면인지, 이미 갖춰진 시스템 위에 얹는 작업인지를 구분해 적용해야 합니다. 그에 따라 맥락을 주는 방법도 달라지고요.

<출처: GitHub, google/agents-cli>

3. 적용해볼 것: 구글이 공개한 AI 에이전트 제작 노하우를 가져다 쓰는 법

요즘은 AI 에이전트를 만들어보는 것 자체는 어렵지 않습니다. 문제는 그다음인데요. 만든 에이전트가 정말 잘 도는지 확인하고, 배포하고, 운영하면서 지켜보는 일이 오히려 더 손이 많이 갑니다. 구글이 공개한 google/agents-cli는 이 순서를 도구 안에 그대로 담았습니다.

이건 그 자체가 코딩 에이전트는 아닙니다. Claude Code나 Codex처럼 내가 쓰던 코딩 도구에 스킬과 명령어를 얹어, 구글 클라우드에서 에이전트를 만들고 평가하고 배포하는 일을 대신 시키는 CLI(터미널에서 명령어로 쓰는 도구)예요. 여기서 눈여겨볼 건 도구 자체보다, 에이전트를 만드는 순서를 어떻게 짰느냐입니다.

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

에이전트를 한 번 만들어 돌려보면 그럴듯하게 동작합니다. 하지만 실제로 쓰려고 하면 따져볼 게 하나둘 생기죠. 매번 제대로 동작하는지, 이상한 입력이 들어오면 어떻게 반응하는지, 문제가 생기면 어디서부터 무너지는지. 그런데 이걸 매번 사람이 직접 확인하다 보면, 대충 괜찮아 보이네 하고 넘어가기 쉽습니다. agents-cli는 이 확인 과정을 만들기만큼 중요한 단계로 다룹니다.

어떤 노하우가 담겨 있나요?

agents-cli를 코딩 도구에 얹으면, 에이전트를 만들며 부딪히는 단계마다 대신 처리해주는 일이 늘어납니다. 크게 이런 것들이에요.

에이전트 프로젝트 뼈대부터 짜기 (이미 있는 프로젝트에 얹는 것도 가능)
ADK(구글의 에이전트 개발 도구) 코드 대신 작성하기
평가용 데이터를 넣어 성능 확인하기
Cloud Run이나 GKE로 클라우드에 배포하기
Gemini Enterprise에 게시하기
배포한 뒤 상태를 지켜보고, 이 과정을 하나로 엮어주기

매번 흩어진 명령어와 서비스를 따로 익히지 않아도, 이 순서와 판단 기준을 코딩 도구가 대신 익히는 셈입니다. 어떤 모델을 고를지, 작업 도중 멀쩡한 코드를 함부로 덮어쓰지 않게 하는 규칙 같은 것도 함께 담겨 있고요.

이 중에서 특히 눈에 띄는 건 성능 평가입니다. 평가는 아래 순서로 진행됩니다.

① 평가용 데이터를 만들고
② 결과를 채점하고
③ 두 버전을 비교하고
④ 실패한 경우끼리 묶어 원인을 살피고
⑤ 그 결과로 프롬프트를 자동으로 다듬기

만든 다음, 잘 됐는지 안 됐는지 기준을 두고 하나하나 확인하게 해주는 거죠. 채점도 사람이 일일이 하는 게 아니라, 다른 모델에게 답안을 매기게 하는 방식(LLM-as-judge)까지 준비돼 있고요.

어떻게 시작하나요?

명령어 한 줄로 설치가 가능합니다. npx skills add google/agents-cli를 터미널에 치면 내가 쓰는 코딩 도구에 스킬이 깔립니다. 그다음부터는 복잡한 명령어를 외울 필요 없이, 평소 코딩 도구에 부탁하듯 요청하면 됩니다. 가령 긴 글을 짧고 툭툭 끊기는 말투로 압축하는 에이전트를 만들어줘처럼 부탁하면, 코딩 도구가 뼈대 만들기부터 평가, 배포까지 알아서 처리해줍니다.

로컬에서 만들고 돌려보는 데까지는 구글 클라우드 없이 API 키만으로 되고, 실제로 배포하고 운영할 때 클라우드가 필요합니다. 아직 정식 출시 전 프리뷰 단계라, 기능은 바뀔 수 있습니다.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

함께 보면 좋은 글

]]>

바이브코더를 위한 기초 보안 A to Z

Claude Code를 켜고 머릿속에 굴러다니던 아이디어 하나를 그대로 던졌습니다. 꽤 잘 나왔길래 얼른 Supabase를 붙여 로그인과 데이터 저장을 테스트했고, 스레드에 제품 홍보 콘텐츠를 하나 남겼습니다. 친구 몇 명한테 DM도 보냈고요. 오, 사람들이 와서 좀 써봅니다. 아이디어가 재미있다는 말도 있네요. 신이 나서 결제도 붙이고 돈을 써서 광고도 좀 돌려보기로 합니다.

그런데 지금 이 순간, 아무도 알려주지 않는 게 하나 있습니다. 그 앱의 데이터베이스가 통째로 열려 있을지 모른다는 사실이요. API 키는 코드에 그대로 박혀 있고, 데이터베이스는 아무나 읽을 수 있고, 어떤 주소는 로그인 없이도 그냥 열립니다. 빠르게 만드는 데만 초점을 맞추다 보니 보안은 아예 안 챙긴 거죠.

자, AI가 짜준 코드는 안전하지 않습니다. 오히려 반대입니다. 100개가 넘는 AI 모델을 테스트한 Veracode 조사에서, AI 생성 코드의 45%가 보안 테스트를 통과하지 못했습니다. 다행히 우리 서비스는 이제 시작이고, 지금 바이브코딩으로 인한 사고는 누가 작정하고 ‘털어서’ 나기보다 애초에 문도 안 잠그고 나간 쪽에 가깝습니다. 달리 생각하면, 간단히 잠그면 막을 수 있다는 뜻이기도 하고요.

그래서 이 글은 철저히 바이브코더를 위한 기초 보안 점검법을 다룹니다. 가장 흔히 할 법한 실수가 어떻게 사고로 번지는지 보고, 그걸 시점별로 어떻게 막는지 짚은 다음, 이 일을 도와줄 도구까지 정리하겠습니다.

<출처: 작가, Gemini로 생성>

바이브코더가 흔히 하는 보안 실수 5가지

이건 AI가 빠뜨리기 쉬운 것들입니다. 즉, 사람이 챙기지 않으면 그대로 배포된다는 공통점이 있어요. 그러니 모르면 당하기 딱 좋습니다. 각각이 어떻게 사고로 번지고 무엇이 돌아오는지까지 따라가 보겠습니다.

① 데이터베이스 잠금장치(RLS)를 안 켜고 배포한다

자주 쓰이는 백엔드 서비스인 Supabase에서 SQL로 테이블을 만들면 잠금장치인 RLS는 기본으로 꺼져 있습니다. 이 RLS는 쉽게 말해 “누가 어느 데이터를 봐도 되는지” 정하는 규칙인데요. AI에게 “회원 표 만들어줘”라고 하면 기능은 잘 만들지만 이 접근 규칙까지 챙기지는 않습니다.

털리는 과정: 앱을 배포하면 데이터베이스에 접근하는 공개 키(anon 키, 로그인 없이 누구나 쓰는 키)가 브라우저 코드에 올라갈 수도 있습니다. 누구든 브라우저 개발자 도구로 그 키를 꺼내 데이터 주소(/rest/v1/표이름)를 직접 부르면, 잠금장치가 없으니 실제 데이터가 응답으로 돌아옵니다. 고객 정보가 샌 거죠. 이런 앱은 자동 점검 프로그램이 알아서 찾아내기도 합니다.
돌아오는 결과: 간단합니다. 개인 정보 유출, 즉, 전체 회원 데이터가 빠져나갑니다. 한 연구자가 Lovable로 만든 앱 1,645개를 점검했더니 170개에서 잠금장치 없이 데이터가 읽혔다고 합니다(CVE-2025-48757). 그 다음은 유출 공지, 회원 이탈, 그리고 집단소송으로 이어집니다.

② LLM API 키를 코드에 그대로 박는다

예제 코드를 따라 하다 보면 API 키를 코드에 직접 쓰기도 합니다. 이 LLM의 API 키는 곧 돈입니다. 이 키를 등록한 사람의 돈으로 AI 토큰을 공짜로 쓸 수 있는 거니까요. 그래서 공격자가 가장 먼저 노립니다.

털리는 과정: 키가 들어간 코드를 GitHub 공개 저장소에 올리는 순간(또는 빌드 결과물에 둔 순간) 우리는 목을 그대로 내놓은 겁니다. 공격용 프로그램은 GitHub의 새 코드를 실시간으로 훑어 키를 찾아냅니다. 키가 노출되고 악용되기까지 걸리는 시간이 예전엔 몇 시간이었다면 요즘은 몇 분 수준으로 짧아졌습니다. 가져간 키로 LLM API를 최대치로 돌려버리고요.
돌아오는 결과: 감당 못 할 만큼 비용이 불어납니다. 게다가 내가 알아채고 키를 바꾸기 전까지 요금은 계속 오릅니다. GitGuardian 집계로는 2025년 한 해에만 공개 코드에 키·비밀번호 2,865만 건이 올라왔고, AI 서비스 자격증명 유출은 1년 새 81% 늘었다고 합니다.

③ 인증 검사를 빼먹는다

AI는 화면에 관리자 버튼은 그려주면서 정작 서버에서 누가 관리자인지 확인하는 과정은 빼먹기도 합니다. "이건 우리만 쓸 내부용"이란 말에 인증 없이 공개 주소에 올리기도 하고요.

털리는 과정: 공격자는 화면을 거치지 않습니다. 데이터 주소를 직접 부르죠. 서버에 권한 검사가 없으면 관리자 기능이 그냥 실행되고, 간단한 조작만 해도 남의 자료를 들여다보는 일도 할 수 있습니다.
돌아오는 결과: 한 보안 업체가 공개된 바이브코딩 앱 38만 개를 점검했더니 약 5,000개 앱에 사실상 인증이 없었다고 합니다. 그중 40%는 이로써 회원의 민감한 정보를 노출하고 있었습니다. 권한 탈취와 자료 유출은 프리패스입니다.

④ 요청 횟수를 제한하지 않는다

AI가 처음 만든 예제 코드에는 요청 횟수를 막는 장치가 대개 빠져 있고는 합니다. 그러니까 서버와 API에 되는대로 요청을 보내고, 그거 하나하나가 다 비용으로 돌아옵니다.

털리는 과정: 누군가 특정 주소를, 특히 LLM을 중계하는 주소를 자동 스크립트로 체크하기 시작합니다. 이때 요청횟수를 제한하는 장치가 없으면 요청이 끝없이 들어오죠.
돌아오는 결과: 요금이 감당 못 할 만큼 불어나거나, 서버가 못 버텨 서비스가 멈춥니다. 아주 짧은 스크립트 하나로 벌어지는 일입니다.

⑤ 입력을 검증하지 않는다

AI가 데이터베이스에 던지는 쿼리를 안전한 방식 대신 문자열을 그냥 이어 붙여 만들기도 합니다.

털리는 과정: 내 테스트 입력에는 멀쩡히 돌다가, 공격자가 조작한 값을 넣으면 그 틈으로 들어옵니다. 데이터베이스 명령을 끼워 넣어 자료를 빼내거나(SQL 인젝션), 외부에서 가져온 글에 숨긴 명령으로 LLM이 원래 지시를 무시하게 만들 수도 있습니다(프롬프트 인젝션).
돌아오는 결과: 데이터베이스 전체가 털리거나, 지워지거나, 에이전트가 시키지 않은 위험한 작업을 하기도 합니다. 실제로 Replit에서는 AI 에이전트가 작업 중지 지시를 무시하고 운영 데이터베이스를 통째로 지운 사건도 있었어요. 에이전트에게 운영 권한을 함부로 주면 안 되는 이유입니다.

어느 정도 유형이 있습니다. 접근 통제(①③)가 뚫리거나, 비용(②④)이 새거나, 입력(⑤)으로 공격이 들어오거나. 그리고 이건 모두, 알아서 잘 깔끔하게 AI가 막아주길 기대하기 어려운 것들이에요.

<출처: 작가, Gemini로 생성>

그 보안 이슈를 (일단) 해결하는 방법

좋은 소식. 보안을 어떻게 챙길지는 이미 업계가 수십 년간 정리해뒀습니다. 표준 보안 규칙이 공통으로 말하는 건 하나입니다. 보안은 한 번에 끝내는 이벤트가 아니라 앱을 운영하는 내내 챙기는 일이라는 겁니다. 마이크로소프트도 보안 개발 가이드에서 보안은 다 만든 다음에 생각할 일이 아니라고 강조합니다.

문제는 개인 빌더가 언제나 이걸 신경 쓰기 어렵다는 겁니다. 바쁘니까요. 그러니 특히 처음 만들 때, 개발할 때, 배포한 다음, 이렇게 세 시점에서 특히 신경 쓰는 것이 좋습니다.

처음 만들 때: 설계와 세팅

흔히들 설계 단계에서 들어간 결함이 가장 고치기 비싸다고 말합니다. 거창한 설계가 필요한 게 아닙니다. 내 앱에서 가장 새면 안 되는 데이터가 무엇인지 정리하는 일이 출발입니다. 그 다음으로는 아래 일들을 합니다.

데이터베이스 잠금장치부터 켠다. 만약 Supabase라면, 대시보드에서 공개된 표마다 RLS가 켜져 있는지 확인하고, “내 데이터만 볼 수 있다(auth.uid() = user_id)” 같은 규칙을 붙이세요. 다른 데이터베이스도 잠금장치 점검이 필요한 건 마찬가지입니다.
인증은 직접 짜지 말고 검증된 서비스에 맡긴다. 권한 관련 허점은 자동 점검 도구로도 거의 못 잡는 영역이라, 처음부터 안전한 걸 쓰는 게 쉽습니다. 이미 Supabase를 쓴다면 Supabase Auth가 기본이고, 아니라면 Clerk처럼 컴포넌트만 끼우면 로그인이 붙는 서비스가 흔히 추천됩니다.
API 키를 코드 밖으로 뺀다. 키는 .env 파일로 옮기고 그 파일을 .gitignore에 넣으세요. 브라우저에서 직접 부르던 API는 서버 함수를 거치게 바꿔서 키가 사용자 화면까지 내려가지 않도록 막고요.
요청 제한을 건다. 앱 앞에 Cloudflare 같은 서비스를 두면 IP당 요청 횟수에 상한을 거는 규칙을 만들기 쉽습니다. AI라면, 특히 콘솔에서 월 지출 한도를 정해두면 비용 사고가 대부분 막아집니다.
개발용과 운영용 환경을 나눈다. AI 에이전트에게 실수로라도 운영 데이터베이스 권한이 가지 않도록 처음부터 환경을 갈라두세요. 내부에서 소수만 쓰는 게 아니라 어느 정도 볼륨을 확보한 서비스는 이런 세팅을 기본으로 두는 것이 좋습니다.

개발할 때: 코딩 습관

처음 세팅을 마쳤어도 코드를 새로 짤 때마다 헛점은 생깁니다. 무엇보다 가장 중요한 건 AI가 내놓은 결과를 그대로 믿지 않는 것입니다. 이런 습관이 도움이 됩니다.

쿼리를 손으로 이어 붙이지 않는다. 문자열을 직접 합쳐 데이터베이스 쿼리를 짜지 말고 SDK나 ORM 같은 도구에 맡기세요(Supabase 클라이언트 SDK를 쓰면 SQL 인젝션을 대체로 막아줄 가능성이 높습니다). 즉, 사용자 입력을 쿼리 명령어로 그대로 넣는 방식보다는 파라미터로 바꿔 넣는 것이 좋다는 뜻입니다. 형식 검사 도구로도 한 번 걸러내고요.
AI가 추천한 라이브러리를 의심한다. AI는 있지도 않은 패키지나 오래되고 취약한 라이브러리를 자신 있게 추천하기도 합니다. 공격자가 AI의 단골 실수를 노려 가짜 패키지 이름을 선점해두기도 하고요. 일단 깔라는 거 다 깔기 전에 안전한 지 확인해 보세요. 중요 시점마다 검토하는 것도 좋습니다.
커밋 전에 API 키가 섞였는지 거른다. 커밋 직전에 키가 코드에 들어갔는지 자동으로 확인하는 장치(이를테면 pre-commit 훅)를 걸어두면, 키가 GitHub로 새기 전에 걸러집니다.
AI가 짠 코드는 받아들이기 전에 한 번 본다. 사실 마냥 Accept를 누르기 전에 보안을 한 번 점검하는 습관이 중요해요. 코드는 못 보면 어떻게 하냐고요? 도구를 쓰면 됩니다. (잠시 후에 추천해 보겠습니다)
외부에서 가져온 소스는 일단 의심한다. 웹에서 긁어오거나 다운로드 받은 걸로 위험한 작업을 시킬 땐, 사람이 한 번 승인하는 단계를 두세요. AI가 신경써서 공격을 체크하도록 하는 것도 방법이죠.

배포 후: 꾸준한 점검과 대응 원칙

NIST의 보안 개발 표준은 그룹 하나를 통째로 ‘취약점 대응’에 씁니다. 허점을 찾고 같은 일이 다시 안 생기게 막는 것까지가 보안이라는 뜻이죠.

가장 쉬운 자가 점검부터. 로그인하지 않은 상태에서 내 앱의 데이터 주소에 요청을 한 번 보내보세요. 데이터가 그냥 돌아오면 어딘가 문이 열린 겁니다. 새 기능을 붙일 때마다 한 번씩 해보면 좋아요.
알림을 켜둔다. 키가 새거나 라이브러리에서 취약점이 나왔을 때 알려주는 점검을 걸어두면, 사고를 나중이 아니라 거의 실시간으로 잡고 대응할 수 있습니다.
새 기능마다 잠금장치와 인증을 다시 확인한다. 데이터베이스 테이블을 새로 만들거나 주소를 추가할 때, 그 기능이 잠겨 있는지 그때그때 보는 습관이 가장 확실합니다.
터졌을 때의 순서를 미리 정해둔다. 사고가 의심되면 ① 노출된 키부터 바로 바꾸고 문제 기능을 막은 다음, ② 어떤 데이터가 얼마나 새어 나갔는지 범위를 파악하고, ③ 원인을 막고 같은 허점이 다른 곳에 또 있는지 살핍니다.

물론, 이건 가장 기초적이며 제일 기본적인 대처 방식입니다. 그것만으로도 할 일이 많고, 이것만으로도 아주 쉬운 공격은 막아내죠. 다만, 서비스가 커지고 더 많은 정보를 담게 되며 큰 돈이 오갈 때는 무조건 보안에 대한 노력을 기울여야 한다고 생각합니다. 공부하고 노력을 기울이고 돈을 써서요.

“해 줘”를 담당해 줬으면 하는 보안 도구

할 일이 많죠? 그러니 여기까지 전부 손으로 챙기기는 벅찰 겁니다. 그래서 보안 도구를 씁니다. 다만 분명히 하고 갈게요. 도구는 거들 뿐 다 해주지 않습니다. 점검 도구를 깔아도 경고를 읽고 고치는 건 사람입니다. 보안 서비스에 백날 항의 메일을 보내봤자 떠나간 고객은 돌아오지 않습니다.

다만, 모든 바이브코더가 보안에 대해 높은 이해를 가졌을 가능성은 낮습니다. 그래서 더 필요한 건 이런 서비스를 따로 켜지 않고 ‘지금 쓰는 코딩 에이전트’ 안에서 보안을 챙기는 방법입니다. 다시 크게 코딩 에이전트에 붙이기 쉬운 외부 전용 보안 도구와 코딩 에이전트 벤더사 자체가 제공하는 보안 도구로 나눠볼 수 있습니다.

외부 MCP: SonarQube · Snyk · Semgrep

외부 보안 도구 계열에서는 SonarQube, Snyk, Semgrep이 많이 쓰입니다. 셋 다 MCP 서버를 연결해 보안 검수를 받고 코딩 에이전트가 이를 활용하는 구조가 일반적입니다.

SonarQube

원래 보안보다 코드 품질을 보는 도구라, 버그·지저분한 코드·취약점을 폭넓게 훑는 게 강점입니다. MCP 서버를 붙이면 코딩 에이전트가 SonarQube의 품질·보안 분석 결과를 그대로 읽고, 짧은 코드 조각도 그 자리에서 검사해 줍니다.

핵심 기능은 무료로 시작할 수 있어요. 커뮤니티 에디션이 오픈소스고, 클라우드도 무료 플랜이 있습니다. GitHub 인기도와 설치 수로만 보면 SonarQube가 1위입니다(2026년 6월 기준 에디터 플러그인 449만 설치, 전체 개발자 기준).

Snyk

라이브러리(오픈소스 의존성) 취약점 감지가 특히 강하고, 코드·컨테이너·인프라 설정까지 함께 봅니다. MCP 서버는 Snyk CLI 안에 들어 있어, snyk mcp -t stdio로 로컬에서 띄우면 에이전트가 코드를 받아들이기(Accept) 전에 스캔해 줍니다.

마찬가지 무료 계정으로 바로 붙여 쓸 수 있지만, 스캔 횟수는 항목별로 월 한도가 있습니다.

Semgrep

5,000개가 넘는 규칙으로 코드를 의미 단위로 훑는, 빠른 보안 전용(SAST) 도구입니다. 규칙이 소스 코드처럼 생겨서 원하는 패턴을 직접 만들기도 쉽죠. MCP 서버는 보안 점검·스캔·커스텀 규칙 실행 같은 기능을 에이전트에 열어 줍니다(단, 이 저장소는 앞으로 semgrep 바이너리로 통합될 예정이라 최신 안내를 한 번 확인하세요).

애초에 이건 오픈소스 도구라 기본 스캔은 무료로 쓸 수 있습니다. 보안 위험 감지만 놓고 보면 SonarQube보다 더 나은 부분도 있습니다.

내장형 연계 도구: Claude Code, Codex, Copilot 보안 도구

보안은 개발에 있어 중요한 이슈기 때문에, 코딩 에이전트들 스스로도 보안을 챙길 내장형 도구를 내고 있습니다.

Claude Code의 /security-review

Claude Code를 쓴다면 /security-review 명령어를 써볼 수 있습니다. 그냥 코드 근처에서 저 명령어를 입력만 하면 됩니다. 커밋 전에 SQL 인젝션·XSS·인증 허점을 훑어 준다고 하고요. 토큰은 당연히 태울 테지만, 추가 비용은 0이며 코드 단위로 꽉 막아줄 GitHub Action도 따로 있어요.

Codex Security

Codex를 쓴다면 Codex Security도 있습니다. 아직 Pro 이상 가입자만 쓰는 프리뷰 버전이긴 하지만, “보안 전용”으로 나온 기능이라는 점이 매력적이네요. 코드를 훑어 취약점을 식별/검증하고, 수정 패치까지 제안하는 에이전트형 도구입니다. 격리된 환경에서 재현을 검증해 수준을 높이는 것도 좋네요. 다만, 일단 정식 라인으로 공개된 만큼 앞으로 Codex에서 보안 점검이 필요하면 이 도구가 유용할 겁니다.

Copilot Autofix

그 다음, GitHub에 올린다면 Copilot Autofix가 취약점 검증과 고칠 코드 제안도 해줍니다. 공개·오픈소스 저장소는 무료고, Copilot 구독도 필요 없어요.

마치며

바이브코딩에서는 ‘지식을 엮는 일’이 중요하다고 생각합니다. 쉽게 말하면 뭐가 필요하고 무엇이 부족한지 알아야 한다는 거죠. 보안 지식을 막 쌓으라는 게 아닙니다. 어떤 위험이 있는지 알고, 시점에 맞춰 막아두는 것 정도만 해도 초기 단계 보안 사고의 대부분을 막습니다. 아는 만큼 대응합니다.

보안에서는 사실 완전한 방패를 세울 수는 없습니다. 공격의 방법이 끝없이 진화하니까요. 그래서 원칙으로 접근하는 것이 중요합니다.

어려운 원칙은 그때 생각하고, 일단 시작할 때 알아두면 좋을 원칙은 두 가지입니다. 첫째, AI를 너무 믿지 마세요. AI가 짠 코드일수록 한 번 더 의심하고, 배포 전에 사람이 확인해야 합니다. 둘째, ‘나중에 하자’는 마음을 버리세요. 트래픽이 모이면, 결제가 붙으면, 시간이 나면 하고 미루다 보면 사고가 난 다음에야 챙기기 일쑤입니다. 지금 사고 난 서비스들도 다 같았겠죠. ‘일단 돈부터 벌고 하지, 뭐’에서 시작하는 무언가들.

그럭저럭 괜찮지 않을까 생각하지 말고, 나중이 아닌 지금 시작하세요. 보안의 첫 걸음입니다.

]]>

좋은 AI 툴을 써도 우리 팀만 느린 이유

만약 여러분의 팀이 AI 툴 도입을 결정하고 예산을 집행했는데, 팀의 속도가 달라진 것 같지 않다면 어떨까요? 가장 먼저 의심해야 할 건 도구의 성능이 아니라 ‘작업 기반’입니다. 이번 글에서 중점적으로 다뤄볼 이야기는 두 가지입니다. AI 시대의 협업 효율은 도구의 정교함이 아니라 작업 기반의 선택에 의해 결정된다는 것, 그리고 프로덕트 메이커가 가장 먼저 의심해야 할 것은 가장 익숙하고 당연해 보이는 작업 도구와 프로세스라는 것입니다.

이 글에서 자주 등장하는 '작업 기반'의 개념은 디자인과 개발이 공통으로 참조하는 SSOT(Single Source of Truth)가 위치하는 곳을 의미합니다. 피그마 캔버스도 작업 기반이 될 수 있고, 마크다운/HTML/CSS 같은 코드 파일도 작업 기반이 될 수 있죠. 단, 여기서 핵심은 "그 자리에 무엇을 두어야 하는가?"입니다.

미리 요점만 콕 집어보면?

AI 시대의 협업 효율은 도구의 정교함보다 SSOT(Single Source of Truth)가 위치한 작업 기반의 선택에 의해 결정됩니다.
피그마 중심 워크플로우는 필연적으로 디자인·개발 사이의 병목 지점을 만들지만, 마크다운·HTML·CSS 같은 코드 기반은 의도와 구현의 어긋남을 줄입니다.
새로운 도구를 더 붙이기 전에 디자인 시스템을 코드 친화적 기반에 정의해보는 실험이 작업 기반 자체를 바꾸는 출발점이 될 수 있습니다.

피그마 MCP를 도입했는데 왜 빨라진 느낌이 없을까?

많은 팀이 비슷한 코드 자동완성을 넘어 협업 프로세스에도 AI 도구를 붙이고 있습니다. 피그마 MCP(Model Context Protocol)를 연결해 시안을 코드로 변환하는 시도가 그 대표적인 경우입니다. 그런데 이상하게도 결과는 기대에 못 미칩니다. 부분 부분은 빨라지는데, 태스크 하나를 처음부터 끝까지 끌고 가는 E2E(End-to-End) 체감으로는 큰 차이가 없기 때문이죠.

시안에서 코드를 추출하면 결과를 다시 사람이 손봐야 하고, 디자이너가 시안을 수정하면 그 변경을 코드 쪽에 어떻게 흘려보낼지 매번 새롭게 협의해야 합니다. AI 도구가 늘어날수록 협업의 병목 지점은 오히려 더 많아지는 구조죠.

이런 상황에서 우리가 던져야 할 질문은 "어떤 도구를 더 붙일까?"가 아닙니다. 다리(Bridge)를 더 튼튼하게 만드는 동안, 정작 강의 위치를 바꿔야 하는 게 아닌지 의심해야 합니다.

프론트엔드 코드 디자인을 HTML로, 다시 피그마로 변환할 때

<출처: 작가, ChatGPT로 생성>

이 구조적 문제가 잘 드러나는 사례가 있는데요. 만약 급한 일정으로 개발자가 와이어프레임 없이 코드로 화면을 먼저 만든 상황을 가정해 보겠습니다. 피그마 캔버스 없이 실물 구현체가 먼저 나온 상황입니다. AI로 개발자들의 코드 작업 속도가 기하급수적으로 빨라지면서, 현업에서는 이런 상황이 더 자주 발생합니다.

이제 디자이너는 화면을 보고 디테일을 다듬고 싶어 합니다. 하지만 디자이너는 피그마에서 작업하길 원하죠. 선택지는 둘입니다. 앱 스크린샷을 피그마에 올리거나(당연하게도 비트맵이라 컴포넌트로 분해되지 않습니다), 코드를 HTML 목업으로 변환하고, 그 HTML을 다시 파싱(Parsing)해서 피그마 위에 컴포넌트 형태로 복원하거나죠. 후자를 택해도 역해석은 완벽하지 않습니다.

한 가지 흥미로운 점은 피그마는 outline과 border를 구분하지 않는다는 점입니다. Dev Mode는 stroke를 항상 border로 출력하기 때문에, 포커스 링처럼 outline이어야 할 요소가 border로 구현되고, 버튼 높이가 달라지는 식의 오차가 생깁니다. 디자이너에게는 어차피 테두리지만, 개발자에게는 레이아웃이 틀어지는 문제인데요. 디자인-개발 협업 도구를 자처하는 피그마가 그동안 개발자들을 고생시켜 온 이슈 중 하나입니다.

<출처: 피그마 공식 포럼, 캡처>

이런 어긋남이 쌓이면서 일부 컴포넌트는 형태만 비슷한 박스로 바뀌고, 디자이너는 그 어긋난 캔버스 위에서 다시 디자인해야 합니다. 개발자는 그 결과를 받아 다시 코드에 반영합니다. 일이 끝나고 보면, 두 사람 모두 본업이 아닌 일에 가장 많은 시간을 쓰고 있었습니다. 한 사람은 정확하지도 않은 역파싱 도구를 만들고, 다른 한 사람은 실물 스크린샷 위에 디자인을 다시 그리고 있습니다.

이 상황은 처음부터 양쪽이 코드 기반 위에서 일하기로 합의했다면 일어나지 않았을 일이죠. 이처럼 SSOT(Single Source of Truth)를 어디에 둘지 정하지 못한 결과, 양쪽이 그 원본을 매번 새로 만드느라 시간을 소비합니다.

'피그마 없이'의 정확한 의미

사실 해결의 방향은 단순합니다. 디자인 작업의 기준점을 피그마 캔버스에서 빼내고, 그 자리에 마크다운(Markdown), HTML, CSS를 두는 것이죠. 코드가 해석할 수 있는 일관되고 범용적인 규칙 기반으로 옮긴다는 뜻입니다.

다만, 디자이너가 프론트엔드 코드를 직접 짜야 한다는 뜻은 아닙니다. 여기서 말하는 "코드베이스(Codebase)"는 배포되는 자바스크립트나 컴포넌트 코드를 의미하지 않습니다. 디자인 시스템과 의도가 코드가 읽을 수 있는 형태로 정의되는 작업 기반을 가리키는 표현입니다.

작업은 이런 식으로 진행됩니다. "이 디자인 시스템을 DESIGN.md로 정리해줘", "Primary Color 변경을 md 문서에 반영해줘"와 같은 자연어 요청을 디자이너가 던지면, AI가 그것을 구조화된 규칙으로 바꾸고, 결과가 HTML/CSS로 즉시 렌더링되어 시안 역할을 합니다. 특정 도구를 고집할 필요는 없습니다. 자연어 의도를 코드 친화적인 기반으로 옮길 수 있는 환경이라면, 어떤 조합이든 같은 효과를 낼 수 있죠. 중요한 것은 도구의 이름이 아니라 작업 기반의 선택입니다.

캔버스 기반 워크플로우의 고질적인 문제는 따로 있는데요. 디자이너가 피그마에 시안을 그릴 때, 호버(Hover) 상태, 에러 상태, 빈 화면, 로딩 처리 같은 영역은 미처 그리지 못한 채 개발에 넘어오는 일이 반복됩니다. 미완성은 별도 코멘트로 표시되지 않은 채 개발자에게 도착하고, 코멘트가 없으면 빈자리는 그대로 코드가 됩니다. 없는 부분을 완성해 나가는 부담이 개발자에게 암묵적으로 넘어오는 거죠.

이 문제가 캔버스 기반에서 반복되는 이유는 구조 때문입니다. 피그마 캔버스는 화면의 '완성된 순간'만 담기에 최적화되어 있습니다. 하지만 코드는 완성된 순간이 아니라, 캔버스를 구조화해서 바라봅니다. 그렇기에 빌드 단계나 렌더링 결과처럼 어긋남을 즉시 렌더링 오류로 드러내죠. 반면, 피그마 캔버스는 구조화 누락이 있어도, 사람의 눈이 알아채기 전까지는 수면 위로 올라오지 않습니다.

핵심은 작업 기반의 엄격함이죠. 코드 기반 위에서는 어긋남이 즉시 드러나지만, 캔버스 위에서는 어긋남이 누적돼도 사람이 알아채기 전까지 보이지 않습니다. 그래서 AI와 잘 협업하려면, 코드가 필요합니다.

디자이너만의 이야기는 아닌 이유

이런 마찰은 사실 디자이너와 개발자만의 이야기가 아닙니다. 기획자는 노션(Notion)에 요구사항을 정리하고, 팀 리더는 지라(Jira)같은 도구로 일정을 관리합니다. 각자의 도구가 따로 있어서, 그 도구들 사이를 AI가 오가며 맥락을 잃게 됩니다.

그래서 AI에 "이 스프린트의 요구사항을 바탕으로 코드를 짜줘"라고 요청할 때, 요구사항이 노션(Notion)에, 디자인이 피그마에, 코드가 깃헙(GitHub)에 흩어져 있고, 그 데이터 양식이 모두 다르다면 어떨까요? AI는 매번 세 곳을 연결하는 통역사가 되어야 합니다. 통역이 늘어날수록 오차도 누적됩니다.

반면, 요구사항이 Spec.md로, 디자인 시스템이 DESIGN.md로 정리되어 있다면, AI는 하나의 기반 위에서 모든 맥락을 읽습니다. 기획자가 스펙 문서를 수정하면 그 변경이 곧바로 개발자의 컨텍스트가 됩니다. 별도의 전달 과정이 필요없죠. 이렇듯 코드 기반으로의 전환은 디자이너에게만 요구되는 변화가 아닙니다. 팀의 모든 작업이 AI가 읽을 수 있는 하나의 기반 위에 올라올 때, 비로소 AI는 협업의 중심에 설 수 있으니까요.

작업 기반을 바꾸면 ‘무엇’이 달라질까?

<출처: 작가, ChatGPT로 생성>

코드 기반으로 전환했을 때 가장 먼저 체감되는 변화는 바로 속도입니다.

캔버스 기반에서는 화면 하나를 만드는 데 며칠이 걸리는 사이클이 반복됩니다. 시안을 받고, 빈 부분을 묻고, 다시 받고, 코드로 옮기고, 디자이너가 QA(Quality Assurance)에서 디테일을 잡아주면 다시 수정하죠. 그런데 코드 기반에서는 같은 작업이 몇 시간 안에 끝납니다. 디자이너가 의도를 마크다운으로 정리하면 그것이 곧 시안이자 명세이고, 코드는 그 명세를 직접 참조하기 때문입니다. 사람의 손을 거치며 모호해지는 지점이 줄어듭니다.

자잘한 디자인 QA도 구조적으로 빨라집니다. AI에게 "패딩(padding) 4px만 늘려줘" 같은 요청을 했을 때 토큰(Token) 한 줄을 고치는 일이 됩니다. 기존에는 디자이너가 피그마에서 변경한 뒤 개발자가 코드 곳곳에 같은 값을 손으로 반영해야 했다면, 이제는 명세 한 줄을 바꾸는 것만으로 전역 테마 설정까지 일관되게 적용됩니다. 디자인 디테일이 구현 단계에서 누락되는 일도 거의 없고요. 원본이 한곳에 있고, 그 원본을 사람도 AI도 같이 보는 구조이기 때문입니다.

어려운 점: 피그마는 도구가 아니라 사고방식이다

이 전환 과정에서 가장 큰 저항은 디자이너의 적응입니다. 이 어려움은 기술적 문제가 아니죠.

터미널 화면을 처음 마주하는 디자이너의 반응은 대체로 비슷합니다. 검은 화면, 알 수 없는 명령어, 렌더링되지 않은 마크다운 텍스트의 기호들까지, "이건 개발자가 할 일이죠."라는 반응이 자연스럽게 나옵니다. HTML로 렌더링된 결과를 옆에 띄워도 어렵습니다. "텍스트 기반 규칙을 수정하고, 반영된 화면을 확인한다"는 사이클 자체가 너무 낯설기 때문입니다.

이 어려움은 단순한 학습 곡선이 아닙니다. 디자이너에게 피그마는 도구가 아니라, 사고의 방식이기 때문입니다. 화면 위에 요소를 놓아보고, 옆에 두어보고, 색을 입혀보고, 다시 빼보는 동작 자체가 디자이너의 사고 과정입니다. 그 과정을 텍스트 편집으로 옮기라는 것은 도구를 바꾸자는 제안이 아니라, 마치 작업 방식 자체를 만들어보자는 제안이죠. 그러니 그 무게를 처음부터 충분히 고려하고, 접근하는 것이 중요합니다.

이러한 저항을 줄이는 데 효과적인 접근은 두 가지입니다.

실효성을 직접 체감시키는 것. 며칠이 걸리던 QA가 몇 분 만에 반영되는 경험을 하거나, 의도한 디테일이 구현에서 누락되지 않는 것을 확인하면 새로운 기반에 대한 저항감이 떨어집니다.
시대적 맥락을 함께 공유하는 것. 이 방향이 특정 팀의 선택이 아니라, 업계 전체가 머지않아 마주할 흐름이라는 점을 함께 짚어갑니다.

도구를 강제하는 일보다는 변화의 방향을 함께 바라보는 일이 아무래도 다른 무게로 다가오지 않을까요?

새로운 패러다임을 맞이하는 자세

그렇다면 우리가 적극적으로 취해야 할 자세는 무엇일까요?

첫째, AI 시대의 협업은 도구가 아니라 작업 기반이 결정합니다. AI 도구를 더 정교하게 붙이는 일과 작업 기반 자체를 코드 쪽으로 옮기는 일은 같은 작업이 아닙니다. 피그마 MCP를 정교하게 다듬는 데 쓰는 시간 대부분은 결국 다리를 다듬는 작업입니다. 다리가 정교해진다고 강의 위치가 바뀌지는 않듯, 작업 기반 자체를 옮기는 시도에 시간을 써야 합니다.

둘째, 가장 익숙한 도구를 가장 먼저 의심해야 합니다. 피그마는 분명 좋은 도구입니다. 디자이너에게도, 개발자에게도 오랫동안 신뢰받아 온 환경이죠. 협업의 표준으로 자리 잡은 데는 분명 이유가 있습니다. 다만 "원래 이렇게 하는 거니까"라고 받아들이는 작업 방식 중에는 특정 시대의 제약이 만들어낸 것도 많습니다. 패러다임이 바뀔 때, 이 둘을 구분해 내는 일이 중요해 질겁니다.

<출처: 작가, ChatGPT로 생성>

마치며: 우리 팀에서 해볼 수 있는 작은 시도들

우리가 영화를 볼 때를 생각해 볼게요. 아무리 훌륭한 번역가가 열심히 자막을 달아도, 원어로 봐야만 그 영화를 온전히 이해할 수 있을 겁니다. 자막은 결국 번역자의 해석을 한 번 거친 결과물이기 때문입니다. 그런데 이제 원어로 봐야 할 이유가 생겼습니다. AI는 강력한 작업 도구이고, AI를 제대로 활용하려면, 결국 AI가 가장 잘 이해하는 언어인 ‘코드’로 작업하는 것이 유리하니까요. 그런데도 아직 많은 팀이 여전히 더 나은 자막을 붙이는 데 집중하고 있습니다. 피그마와 코드 사이에, Notion과 GitHub 사이에 더 정교한 번역 도구를 끼워 넣으면서요.

이 글의 결론을 단순화한다면 "피그마를 버리자" 가 될 수도 있죠. 하지만 그런 단순한 결론은 아닙니다. 피그마는 여전히 좋은 도구고, 당장 기존에 쓰던 도구들을 한 번에 옮기는 것이 모든 팀에게 최선도 아닐 거고요.

다만 프로덕트 메이커라면 한 번쯤 점검해 볼 만한 질문은 있습니다. “지금 팀의 작업이 하나의 기반 안에서 일어나고 있는가, 아니면 서로 다른 기반 위에서 일어나고 있는가?” 우리가 겪고 있는 병목이, 초기 인터넷 시대에 수신한 이메일을 출력해서 손으로 답장을 쓰고, 그 답장을 다시 스캔해서 이메일로 보내던 것과 같은 성격의 일은 아닌지 생각해 봐야 합니다.

AI 툴을 도입했는데도 협업이 빨라진 것 같지 않다면, 도구의 성능을 의심하기 전에 작업 기반의 정합성을 점검해 보세요. 당장 해볼 수 있는 작은 시도는 새로운 도구를 더 붙이기 전, 디자인 시스템을 마크다운 같은 코드 친화적 기반에 정의해 보는 겁니다. 그 작은 실험이 작업 기반 자체를 바꾸는 결정으로 이어질지, 아니면 기존 워크플로우의 보완 정도에서 끝날지는 팀마다 다를 거예요. 다만 그 실험을 해보지 않는다면, 답을 영영 알 수 없다는 것만큼은 분명하니까요.

]]>

15살의 진로를 완전히 바꿔버린 바이브 코딩 경험기

[바이브코더스] 코딩 없이 앱 만든 15세 바이브 코더, 윤여준 님 인터뷰

“AI만으로 앱을 만들 수 있다고?”

우연히 보게 된 AI 도구 광고 한 편에 이끌려 무작정 ‘바이브 코딩’에 뛰어든 중학생이 있습니다. 개발 언어도, 서버도, API도 전혀 몰랐지만, 오직 AI만을 통해 비즈니스 협업 툴 ‘Wayver’를 직접 만든 윤여준 님입니다. 그렇게 만든 앱을 글로벌 커뮤니티 ‘레딧(Reddit)’에 올려 피드백을 받았는데요. SaaS 업계 고수들의 조언을 통해 중요한 깨달음을 얻기도 했습니다. AI는 코딩을 대신해 줄 수는 있어도, 냉혹한 시장의 검증까지 대신해 주지는 않는다는 사실이었죠.

첫 프로젝트는 비록 쓴맛으로 끝났지만, 그는 도전을 멈추지 않았습니다. 오히려 “사용자에게 너무 아부하지 않는 AI”라는 두 번째 앱 ‘Ennous AI’를 만들고 있죠. 코딩은 몰라도 맨땅에 헤딩하며, 스스로 만드는 재미를 알아버린 15세 바이브 코더. 오늘은 윤여준 님과의 이야기를 통해, 다가올 미래 세대의 ‘바이브 코더’들은 과연 어떤 모습일지 함께 상상해 보고자 합니다.

<출처: 윤여준(사진 제공), 편집(요즘IT)>

Part 1. 중학생, 바이브 코딩을 만나다

Q. 안녕하세요, 요즘IT 독자분들을 위해 간단한 자기소개 부탁드립니다.

안녕하세요. 저는 현재 중학교 3학년인 윤여준이라고 합니다. 코딩을 정식으로 배운 적은 한 번도 없지만, AI와 함께 머릿속 아이디어를 실제 프로덕트로 구현하는 ‘바이브 코더(Vibe Coder)’입니다. 아무것도 모르는 상태로 시작했지만, 지금은 첫 앱 ‘Wayver’를 만든 경험을 통해 두 번째 앱 ‘Ennous AI’도 열심히 만들고 있습니다.

협업 툴 ‘Wayver’의 핀 정보 인스펙터 화면 <출처: 윤여준>

Q. 처음 앱을 만들어야겠다고 다짐하게 된 계기는 무엇인가요?

학교에서 모둠 활동을 하거나, 온라인에서 마음 맞는 친구들이랑 뭔가 만들 때마다 소통이나 역할 분담이 늘 답답했어요. 아이디어는 활발하게 나오는데, 정작 “누가, 언제까지, 무엇을 해야 하는지” 알기가 힘들었어요. 카카오톡 같은 메신저는 대화가 금방 위로 밀려나서 잊혀버리고, 노션(Notion) 같은 툴은 친구들이 잘 몰라서 안 쓰려고 하더라고요.

그래서 ‘우리끼리 딱 필요한 기능만 있는 협업 공간이 있으면 어떨까?’라는 생각에서 시작했습니다. 마침 그때 노코드 AI 코딩 툴인 ‘Base44’의 광고를 보고 바이브 코딩이라는 개념을 막 알게 됐거든요. 그래서 ‘밑져야 본전’이라는 마음으로 무작정 AI에게 프롬프트를 입력해 본 게 저의 첫 번째 앱 ‘Wayver’의 시작이었어요.

Q. 개발을 배운 적이 없다고 하셨는데, 혼자서 어떻게 학습했나요?

처음엔 엄청 막막했어요. 코딩 언어는 물론이고, 백엔드나 API 같은 기본 개념조차 없었으니까요. 첫 프롬프트도 그냥 “할 일 관리 툴 만들어줘”라는 단순한 한 문장이었습니다. 그런데 막상 시작해 보니 신기하고 재밌었어요. 5분밖에 안 지났는데, 꽤 그럴싸하게 작동하는 웹 앱이 나타났거든요.

그러다가 에러가 났을 땐 에러 메시지를 그대로 복사해서 “이거 왜 안 돼? 원인을 찾아서 고쳐줘”라고 했어요. 개발은 어렵다라는 생각이 점점 줄어들었죠. 그렇게 앱을 만들면서 자연스럽게 SaaS, 데이터베이스(DB), API 같은 IT 용어와 개념을 찾아보고 익히게 됐습니다. Firebase나 Vercel 같은 실무 인프라 사용법, 나중엔 PMF(제품-시장 적합성)나 리드(잠재 고객) 같은 비즈니스 용어도 자연스럽게 알게 됐고요.

Part 2. 불편함에서 시작된 ‘Wayver’ 구축기

Q. 앱을 통해 어떤 문제를, 어떻게 해결하고 싶었나요?

제가 느낀 가장 큰 불편함은 ‘제대로 이뤄지지 않는 역할 분담과 정보가 정리되지 않는 점’이었어요. 저희끼리 얘기할 땐 좋은 아이디어가 많은데, 정작 내일까지 누가 무엇을 할지 정리하지 않고 끝났거든요. 그래서 할 일과 각자의 책임을 한눈에 볼 수 있게 정리하고, 각 작업에 담당자와 상태를 연결해야 한다고 느꼈어요.

그 결과 넓은 캔버스 위에 ‘칸반 보드’를 합쳤어요. 업무를 캔버스 위에 ‘핀’으로 고정하고 담당자를 지정한 다음, 오랫동안 진전이 없는 핀은 맥박이 뛰듯 ‘펄스(Pulse) 효과’도 줬어요. 또 친구들이 맥락을 빠르게 파악할 수 있게, 캔버스 안에서 직접 화면과 목소리를 녹화해 지시사항을 남기는 ‘워크스루(Walkthrough)’ 기능도 넣었습니다.

워크스루 재생, 프로젝트 목록 화면 <출처: 윤여준 님>

Q. 앱을 만들 때 어떤 도구를 사용했나요?

메인 도구로는 ‘Google AI Studio’를 사용했어요. 원래 구글이 제미나이(Gemini) 모델을 테스트해 보라고 만든 개발자용 사이트인데, 누구나 바이브 코딩 환경으로 활용할 수 있더라고요. 특히 무료 요금제인데도 최신 모델을 넉넉한 한도로 호출할 수 있어서 좋았어요. 또 제미나이가 에러일 때나, 코드가 꼬일 때는 클로드(Claude)를 서브로 활용했어요. 구축한 코드는 Vercel로 배포하고, 데이터베이스와 사용자 인증(Auth)은 구글 Firebase를 연동했습니다.

Q. 개발은 어떤 방식으로 진행하셨어요?

개발은 오직 대화형으로만 진행했어요. 제 머릿속 UI와 기능을 먼저 글로 풀어 썼죠. AI에게 “너는 지금부터 10년 차 시니어 프론트엔드 개발자야. 내 기획을 React 기반으로 완벽하게 구현해 줘”라고 페르소나를 부여했어요. 그리고 처음부터 크게 요구하지 않고, “먼저 로그인 화면을 만들어”, “그다음은 빈 캔버스를 띄워”, “이제 DB를 연결해”처럼 작은 단위로 쪼개 단계별로 진행했습니다.

Google AI Studio 작업 화면 <출처: 윤여준 님>

Part 3. 바이브 코딩으로 앱을 만든다는 것

Q. 주로 어떤 기능을 기획하고 실제로 구현했나요?

우선 가장 먼저 마우스로 부드럽게 이동하고 확대·축소할 수 있는 ‘무한 캔버스’를 만들었는데요. 그 위에 ‘칸반 보드’ 로직을 얹었어요. 캔버스가 너무 넓어 길을 잃지 않도록, 하단에 현재 위치와 핀 분포를 보여주는 ‘미니맵’도 추가했죠. 이후 캔버스 위에 ‘핀’을 꽂아 업무를 생성하는 기능, 핀별 개별 채팅 스레드, 업무 상태 변경 로그, 담당자 지정 같은 필수 협업 기능을 차례로 붙였습니다.

또 차별화된 기능으로 ‘워크스루’ 영상 기능은 캔버스 화면을 녹화하면서, 마우스 움직임을 ‘고스트 커서’로 표현하도록 구현했어요. 이 데이터를 Firebase에 프레임 단위로 저장해 팀원들이 재생할 수 있게 만들었죠. 또 캔버스 활용도를 높이려고, Figma나 Google Drive 같은 외부 링크를 삽입하면 브랜드 색상과 아이콘으로 예쁘게 임베드되도록 했어요. 마지막으로 방치된 업무를 경고하는 ‘펄스 효과’와 구글 계정 기반 SSO 로그인까지 연동한 뒤, Vercel에 올려 실제 서비스로 배포했습니다.

Q. 바이브 코딩을 하면서 가장 어려운 점은 뭐였나요?

아마도 바이브 코더들이 가장 많이 좌절하는 지점은 바로 내부 상태 관리가 복잡해지거나, 데이터베이스 연동이 얽히기 시작하는 등의 문제 같아요. AI가 전체 문맥(Context)을 잊어버리거든요. 엉뚱한 코드를 뱉거나, 무한 에러 루프에 빠지는데요. 코드를 직접 읽을 줄 모르니까 정말 막막해졌어요.

처음에는 단순히 에러 메시지만 계속 복사해 붙여넣으며 AI를 다그쳤죠. 그런데 절대 해결되지 않더라고요. 그래서 접근 방식을 완전히 바꿨어요. “이 코드 고쳐줘”라고 명령하는 대신, “지금 이 에러가 발생하는 근본적인 아키텍처의 문제가 뭐야? 우리가 놓치고 있는 데이터 흐름이나 로직을 처음부터 단계별로 다시 설명해 봐”라고 역질문을 던졌죠.

그렇게 AI와 대화하며 로직 자체를 뜯어고치고, 구조를 재설계했어요. “그럼 변경된 로직에 맞춰 코드를 다시 짜줘”라고 요청했더니, 드디어 막히던 벽이 뚫렸죠. 코딩 문법은 몰라도, 프로그램이 돌아가는 논리는 이해해야 한다는 걸 그때 깨달았어요.

Part 4. 바이브 코딩의 한계점

Q. 직접 만든 앱을 해외 커뮤니티에 공개하셨는데요. 반응은 어땠나요?

처음엔 앱을 만든 것만으로도 좋았는데, 친구들과 쓰다 보니 다른 사람들의 반응도 궁금해졌어요. 실제로 이 앱이 ‘팔릴 수도 있을까?’라는 생각도 들었어요. 그래서 설레는 마음으로 레딧(Reddit)의 SideProject, SaaS 등 해외 개발자·창업자들이 모인 곳에 공유해 봤어요. 감사하게도 많은 분이 관심을 가져주셨고요. 특히 “단순한 텍스트 리스트가 아니라 무한 캔버스에 칸반을 합친 아이디어가 신선하다”, “원격 근무 팀이 겪는 소통의 부재와 맥락 상실이라는 진짜 문제를 잘 짚었다”는 긍정적인 피드백을 받았어요.

하지만 제 마음을 움직인 피드백은 따로 있었어요. SaaS 업계에서 20년째 일한다는 한 전문가분의 댓글이었는데요. “아이디어는 참신하다. 하지만 지금 상태라면 잘 만든 ‘지라(Jira) 플러그인’ 정도밖에 되지 못한다. 유저가 기존 툴을 버리고 이 앱을 독립적으로 쓰며 ‘돈을 낼 가치’가 있는지 스스로 증명해 보아라”라는 조언이었습니다.

그 댓글을 본 순간 머리가 멍해졌어요. 슬랙이나 피그마에 이미 익숙한 글로벌 팀에게 “왜 굳이 새 툴을 써야 하는지” 설득할 방법이 없었거든요. 제가 아직 어리기도 하지만, 비즈니스의 세계는 냉정하다는 걸 처음 마주했던 순간입니다.

윤여준 님이 레딧에서 받은 댓글 <출처: 레딧, 캡처본>

Q. 이런 피드백을 통해 가장 크게 배운 점은 무엇인가요?

사실 바이브 코더들은 명령한 대로 화면이 예쁘게 나오고, 기능이 작동하는 데서 엄청난 도파민을 느끼거든요. 저도 그랬고요. 하지만 진짜 어려운 일은 앱을 완성한 이후라고 생각해요. “유저가 지갑을 열 만큼 가치(PMF)가 있는가?”, “이 앱을 어떻게 마케팅할 것인가?”라는 질문에 답하지 못하면, 코드에 오류가 없어도 결국 예쁜 장난감에 그치고 만다는 것을 알게 됐어요. 결국 잘 작동하는 앱을 만드는 것도 중요하지만, “누군가 정말 돈을 지불할 만큼 진짜 문제를 풀고 있는가”를 고민해야 한다는 걸 깨달았습니다.

Part 5. 10대 바이브 코더로서의 새 도전

Q. 또 새롭게 만들고 있는 앱이 있나요?

우선 첫 실패의 교훈을 바탕으로, ‘Ennous AI’를 만들고 있는데요. 벌써 90% 이상 완성했어요. 요즘 챗GPT나 클로드 같은 거대 AI 서비스들은 유저의 기분을 맞추려고 ‘예스맨(Yes-Man)’이 되잖아요. 저는 이런 과한 동조가 별로였거든요. 실제로 레딧에서 예스맨 AI를 비판하는 글도 봤고요. 그래서 Ennous AI는 “당신에게 아부하지 않는 단 하나의 지적 스파링 파트너”로 기획했어요. 사용자가 과거 발언과 앞뒤가 안 맞는 주장을 펼치면, AI가 대화를 멈추고 논리적 모순을 짚어줍니다.

또 ‘디베이트(끝장 토론) 모드’를 통해 유저의 사업 계획이나 아이디어를 날카롭게 비판하며 생각을 단단하게 단련시켜 주고요. 이번엔 단순한 AI Wrapper가 아니에요. 값비싼 AI 모델의 API 호출 원가를 방어하기 위해 ‘3-Layer 컨텍스트 캐싱’이라는 백엔드 최적화 구조를 직접 설계했고, 똑똑한 AI를 부를수록 크레딧이 차감되는 ‘시냅스(Synapse)’라는 종량제 수익 모델까지 계산했습니다.

제미나이뿐 아니라, 오픈라우터(OpenRouter)에서 클로드 등 외부 모델을 호출하고, 웹 검색이 필요할 땐 Serper나 퍼플렉시티 Sonar API를 쓰도록 했습니다.

Ennous AI 랜딩 페이지와 모순 감지 모달(Thought Contradiction) <출처: 윤여준 님>

Q. 학업도 중요한 시기인데 앱을 만들 시간이 부족하진 않나요?

아직 제가 중3이다 보니 수업과 학원, 시험 준비로 시간은 많이 부족해요. 그런데 ‘바이브 코더’여서 가능하기도 합니다. 만약 제가 C언어나 파이썬 문법을 처음부터 공부하고, 에러를 잡는 데 하루 종일 매달렸다면 절대 불가능했을 거예요.

저는 주말마다 컴퓨터를 켜서 1~2시간 동안 AI에게 명확한 디렉팅을 주고, 순식간에 화면과 기능을 구현합니다. 개발과 구현 속도가 빠르기 때문에, 학업에 큰 지장을 주지 않으면서도 실제 작동하는 프로덕트를 만들 수 있어요. 제한된 시간을 최대한 잘 배분하려고 노력 중입니다.

Q. 바이브 코딩 경험이 여준 님의 진로를 결정하는 데 어떤 영향을 줬나요? 앞으로 해보고 싶은 일이 있다면요?

원래 제 장래 희망은 기자였고, 실제로 청소년 기자로 활동하고 있어요. 그런데 바이브 코딩에 빠져들면서 진로를 다시 생각하게 됐습니다. 프로덕트를 기획하고 비즈니스 모델을 설계해, 세상에 가치를 만드는 창업자이자, 프로덕트 매니저의 길을 걷고 싶어요.

AI가 나오면서 이제 코딩은 누구나 할 수 있는 시대가 됐잖아요. 결국 기술은 문제를 해결하는 도구일 뿐이고, 진짜 중요한 실력은 ‘사람들이 돈을 낼 만큼 간절하게 필요로 하는 문제를 찾아내는 눈’이랑 ‘그걸 매력적인 서비스로 기획하는 능력’이라는 걸 깨달았어요. 그래서 회사들이 일할 때 겪는 비효율적인 문제나, 소통의 답답함을 완전 뿌리 뽑아줄 수 있는 멋진 B2B 비즈니스를 만들어 보고 싶습니다.

마치며

지금까지 10대 바이브 코더 윤여준 님의 솔직한 이야기를 들어봤는데요. 특히 인상적이었던 건 단순히 바이브 코딩을 경험하는 데서 그치지 않고 현업 실무자들이 실제로 마주하는 고민까지 직접 부딪혀 봤다는 점입니다. 또 레딧에서 받은 실무자들의 피드백을 받아들이고, 다음 프로젝트의 출발점으로 삼은 단단한 태도도 감명깊었습니다.

이제 바이브 코딩이라는 경험은 한 10대의 진로를 바꿀 만큼 강력한 계기가 됐는데요. 어쩌면 AI가 가장 크게 바꾸는 것은 개발 방식이 아니라, 누군가의 가능성과 선택지 자체일지도 모릅니다.

지금, 여러분이 가장 먼저 세상에 내놓고 싶은 아이디어는 무엇인가요?

<참고 링크>

Wayver 앱: https://wayver-5.vercel.app/
Wayver 랜딩페이지: https://wayver.vercel.app

]]>

Claude Tag, 앤트로픽이 공개한 슬랙에 상주하는 AI 팀원

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

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

써볼 것: Figma Motion - 이제 Figma에서 디자인하고 모션 작업까지 한 번에
참고할 것: Claude Tag - 슬랙 채널에 상주하며 팀과 함께 일하는 AI 팀원
적용해볼 것: OpenAI Codex 백서 - AI한테 일 시키고 같은 설명 반복하지 않으려면

<출처: Figma>

1. 써볼 것: 이제 Figma에서 디자인하고 모션까지 한 번에

Figma Motion은 Figma가 Config 2026에서 공개한 새 기능입니다. 디자인 화면을 그리던 그 캔버스 안에서 모션까지 바로 만들 수 있게 해줍니다. 지금 오픈 베타이고, Figma가 공개한 체험 파일로 기능을 둘러볼 수 있습니다.

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

지금까지 디자인에 모션을 입히는 일은 따로 떨어져 있었습니다. 디자인은 Figma에서 하고, 애니메이션은 애프터 이펙트나 별도 플러그인으로 옮겨가서 만들고, 다시 개발자에게 넘기는 식이었죠. 일러스트레이터 Adanna Onuekwusi는 일러스트 하나를 움직이려고 외부 도구와 브라우저 플러그인, Figma 사이를 계속 오갔다고 말합니다.

이렇게 도구를 오가면 두 군데서 문제가 생길 수 있습니다. 하나는 디자인과 모션 작업이 다른 파일에 흩어져서, 디자인을 고치면 모션을 또 손봐야 하는 상황입니다. 다른 하나는 모션을 다룰 줄 아는 사람이 없으면 일이 안 돌아간다는 점입니다. 그 사람이 자리를 비우면 작업이 멈춰버리니까요. Figma는 이걸 캔버스 안으로 들여와서, 디자인하던 자리에서 바로 모션을 붙일 수 있게 했습니다.

Motion 모드 <출처: Figma>

어떻게 쓰나요?

Design, Draw, Dev 모드 옆에 Motion 모드가 새로 생겼습니다. 프레임을 Motion 모드로 바꾸면 디자인 옆에 타임라인이 나타나고요.

타임라인에서 레이어를 드래그해 타이밍을 맞추고, 스크럽으로 특정 순간을 미리 보고, 위치·크기·회전·투명도를 각각 키프레임으로 잡습니다. 오토 키프레이밍을 켜면 작업하는 동안의 변화가 자동으로 기록됩니다.
처음이라면 프리셋(fade, move, scale)으로 빠르게 시작한 뒤 캔버스에서 다듬으면 됩니다. 여러 스타일을 쌓아 동시에 재생하거나 순서대로 이어붙일 수도 있고요.
타임라인에 시간 기반 코멘트를 달 수 있어서, 누구든 모션의 특정 순간을 짚어 리뷰에 참여할 수 있습니다.

모션을 한 번도 안 만들어본 사람은 Figma 에이전트에 원하는 걸 설명하면 됩니다. 그러면 컴포넌트와 토큰에 맞춰 실제 키프레임을 만들어줍니다. 이미 모션을 다루는 사람은 반복 작업을 에이전트에 맡기고 이징 곡선이나 타이밍 같은 디테일에 집중할 수 있고요.

모션을 디자인 시스템의 일부로 만들 수도 있습니다. 컴포넌트에 애니메이션을 한 번 입히면, 색이나 글꼴이 그러듯 그 모션이 모든 화면과 협업자 파일로 따라갑니다. 이징(easing)을 모션 변수로 만들어 페이지 단위로 모드를 바꾸면, 그 변수를 쓰는 애니메이션이 한꺼번에 바뀌고요. 매 스프린트마다 모션을 처음부터 다시 만들던 걸, 한 번 정해두고 어디서나 쓰는 방식으로 바꾸는 겁니다.

개발로 넘길 때도 끊기지 않습니다. Dev 모드의 Motion 탭에서 타임라인을 그대로 열어 모든 타이밍과 이징, 키프레임을 확인할 수 있고, CSS나 JSON, React 코드로 바로 복사할 수 있습니다. MCP도 호환돼서 애니메이션 프레임 링크를 코딩 에이전트에 그대로 넘길 수 있고요. MP4, GIF, SVG, WEBM으로 내보내는 것도 됩니다.

누구에게 좋을까요?

디자인과 개발 사이에서 모션이 자꾸 누락되거나 의도와 다르게 구현되는 걸 겪어본 사람
모션을 한 번도 안 만들어봤지만, 내 화면에 작은 인터랙션을 붙여보고 싶은 사람
팀 단위로 일관된 모션을 쌓아두고 재사용하고 싶은 디자인 시스템 담당자

플랜에 따라 쓸 수 있는 범위가 다릅니다. 오픈 베타이고, Starter 사용자는 제한된 익스포트로 써볼 수 있습니다. 모든 플랜의 Full seat 사용자는 모션 기본 기능과 익스포트를 쓸 수 있고, 전체 디자인 시스템 통합과 모션용 Figma 에이전트는 유료 플랜에서 제공됩니다. 이번 발표는 Config 2026에서 함께 공개된 여러 기능 중 Motion에 한정한 내용이라, code layers 같은 다른 발표와는 구분해서 보면 됩니다.

<출처: Anthropic, Introducing Claude Tag>

2. 참고할 것: 슬랙 채널에 상주하며 팀과 함께 일하는 AI 팀원

Claude Tag는 Anthropic(앤트로픽)이 6월 23일 공개한 Slack용 기능입니다. 채널 안에 상주하는 AI를 두고, 누구든 @Claude를 불러 일을 맡기는 방식이에요. 참고로 온라인에서 클로드 태그라는 말은 PR에 @claude를 다는 GitHub 방식이나 프롬프트에 넣는 태그 블록을 가리키기도 하는데, 여기서 다루는 건 이번에 나온 Slack 기능입니다.

지금까지 회사에서 AI를 쓰는 모습은 대개 이랬습니다. 각자 브라우저 탭을 따로 띄워 혼자 AI와 대화하고, 그 결과물을 복사해 슬랙이나 문서에 옮겨 붙였죠. AI가 한 일은 그 사람의 탭 안에만 남고, 팀이 함께 보던 업무 흐름과는 떨어져 있었습니다. Claude Tag는 그 자리를 팀이 이미 모여 일하는 슬랙 채널 안으로 옮깁니다.

기존 슬랙봇과 무엇이 다른가요?

Anthropic은 2025년 10월에 이미 Claude in Slack 앱을 내놨는데요. 이건 부른 사람하고만 대화를 주고받고, 기억하는 것도 채널의 최근 메시지 20개 정도에 그쳤습니다. 사실상 물어보면 답해주는 슬랙봇 느낌에 가까웠죠. Claude Tag는 여기서 네 가지가 달라졌습니다.

혼자 쓰지 않습니다. 채널마다 모두가 공유하는 하나의 Claude가 있습니다. 누가 무엇을 시켰고 지금 뭘 하고 있는지 팀 전체가 보고, 동료가 하던 작업을 이어받아 방향을 바꿀 수 있습니다.
시간이 지나며 맥락을 쌓습니다. 채널을 따라가며 업무 맥락을 익히기 때문에 매번 처음부터 설명할 필요가 줄어듭니다. 권한이 있으면 다른 채널이나 데이터에서도 정보를 모으는데, 비공개 채널의 내용은 보고하지 않습니다.
먼저 움직이기도 합니다. ambient 모드를 켜면 태그하지 않아도 채널을 지켜보다가 알 만한 정보를 먼저 알려주고, 답 없이 조용해진 스레드를 다시 챙깁니다.
비동기로 일합니다. 일을 맡겨두면 내가 다른 일을 하는 동안 스스로 일정을 잡아 몇 시간에서 며칠에 걸쳐 진행합니다.
민감한 건 @Claude에게 DM으로 보낼 수 있습니다. 이때는 채널 공유 신원이 아니라 내 개인 권한으로 비공개로 답하고요.

어떻게 통제하나요?

Claude Tag는 agent identity라는 방식으로 동작합니다. 채널 안의 Claude는 특정 사용자의 권한을 빌리는 게 아니라, 관리자가 만들어준 자기 계정으로 일하죠. 슬랙에는 Claude 앱으로 글을 쓰고, GitHub에는 Claude의 GitHub 앱으로 PR을 열고, 데이터 저장소에는 전용 계정으로 접근하는 식입니다. 그래서 누가 마지막으로 말을 걸었든, 모든 작업이 정해진 계정 하나에 기록으로 남습니다.

권한은 채널별로 나뉩니다. 법무 채널의 Claude는 엔지니어링 채널의 코드에 닿지 못하고, 비공개 채널에서 배운 건 다른 워크스페이스에 나타나지 않습니다. 관리자는 채널과 조직 단위로 토큰 사용 한도를 걸 수 있고, @Claude가 한 모든 일과 요청자를 로그로 확인할 수 있습니다. 공유되는 AI지만 권한은 철저히 나눠둔다는 게 설계의 핵심입니다.

<출처: Anthropic, Introducing Claude Tag>

무엇을 얻어가야 하나요?

앤트로픽은 사내에서 이미 Claude Tag를 핵심 업무에 쓰고 있다고 밝혔습니다. 회사 발표에 따르면 제품팀 코드의 약 65%가 내부 버전 Claude Tag로 만들어지고, 엔지니어링을 넘어 제품 지표 확인, 지원 티켓 처리, 버그 원인 분석까지 쓰인다고 하죠. 다만 이건 만든 앤트로픽이 자사 환경에서 낸 수치라, 그대로 받아들이기보다 한 회사가 깊이 신뢰를 쌓았을 때 어디까지 가능한지를 보여주는 사례 정도로 참고해보는 게 좋겠습니다.

지금 당장 써보긴 어려운 분이 많을 겁니다. 클로드 엔터프라이즈와 팀 고객 대상 베타이기 때문인데요. 기존 Claude in Slack 앱은 8월 3일 즈음 Claude Tag로 전환될 예정이라고 확인했습니다만, 정확한 일정은 쓰는 조직마다 다를 수 있으니 공식 안내로 확인하는 게 좋습니다.

당장 쓸 수 없더라도 앤트로픽이 가려는 방향은 눈여겨볼 만합니다. 클로드를 혼자 쓰는 도구가 아니라, 팀 채널에 상주하는 동료처럼 만들려는 거죠. 다만 이런 방식이 마냥 편하기만 한 건 아닙니다. 채널 맥락과 기억이 쌓일수록 그 AI를 다른 걸로 갈아타기 어려워진다는 지적이 있고요(VentureBeat). ambient 모드도 처음부터 켜기보다, 팀이 결과물을 믿을 만하다고 느낀 다음 먼저 나서는 알림이 도움이 되는 채널에서만 켜라는 조언이 있습니다(Lushbinary). 채널 기록을 읽고 연결된 도구까지 쓴다는 건 그만큼 권한을 많이 준다는 뜻이라, 채널마다 꼭 필요한 만큼만 열어주는 게 안전할 거고요.

Codex-maxxing for long-running work <출처: Open AI>

3. 적용해볼 것: AI한테 일 시키고 같은 설명 반복하지 않으려면

OpenAI(오픈AI)가 Codex 사용법을 정리한 백서를 냈습니다. 제목은 Codex-maxxing for long-running work로, 한 번의 프롬프트로 끝나는 작업이 아니라 며칠에 걸쳐 이어지는 일을 어떻게 굴리는지를 다룹니다. 크리에이터 Jason Liu가 Codex를 실제로 쓰는 방식을 따라가며 정리했고요. 이 백서는 Codex를 코드 짜는 도구로만 보지 말고, 작업을 계속 쌓아두고 이어가는 곳으로 쓰라고 말합니다. 여기서 뽑을 만한 건 특정 기능 자체보다, 어떤 AI 도구를 쓰든 옮겨 적용할 수 있는 작업 방식입니다.

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

AI한테 일을 시키는 방식은 대개 단발성입니다. 새 창을 열고, 배경을 설명하고, 결과를 받고, 그 창을 닫죠. 다음에 같은 일을 또 하려면 처음부터 다시 설명해야 하고요. 짧은 작업은 이래도 괜찮지만, 며칠씩 이어지는 일은 매번 맥락이 날아가서 같은 설명을 반복하게 됩니다. 백서는 이걸 단발 지시에서 계속 이어지는 흐름으로 바꾸자고 말합니다.

무엇을 어떻게 하라고 하나요? (백서가 정리한 방식)

백서에 담긴 패턴 중 프로덕트 메이커가 도구와 상관없이 가져갈 만한 것들을 추렸습니다.

일이 머무는 스레드를 하나 정해두기
중요한 작업은 매번 새 대화를 열지 말고, 고정해둔 스레드 하나를 그 일의 자리로 삼습니다. 거기에 맥락과 지난 결정, 아직 안 끝난 것들이 쌓이니까요. 다만 스레드가 길어질수록 쌓인 맥락을 매번 같이 처리해야 해서 그만큼 비용(토큰)이 더 든다는 점은 감안해야 합니다.
다듬지 않은 생각을 그대로 넣기
백서는 음성 입력을 권합니다. 말로 하면 어렴풋이 기억나는 이름이나 막연한 방향처럼, 타이핑하기엔 어색하지만 일이 실제로 시작되는 날것의 생각이 그대로 담기기 때문이라는 거예요. 회의나 통화 녹취도 같은 식으로 일의 출발 재료가 됩니다.
기억을 열어보고 고칠 수 있게 만들기
대화 안에만 맥락을 쌓으면 무엇이 기록됐는지 알기 어렵습니다. 백서는 사람·결정·미해결 과제 같은 걸 대화 밖 문서로 빼두고, 무엇이 바뀌었는지 직접 열어보고 고칠 수 있게 하라고 말합니다. 코드가 저장소에 쌓이는 것처럼, 일의 맥락은 이 문서에 쌓아두라는 거죠.
검증할 수 있는 목표를 주기
약한 목표는 이 계획을 구현해줘처럼 끝나지만, 강한 목표는 무엇이 됐을 때 끝인지를 함께 줍니다. 백서의 예시는 이렇습니다. 라이브러리를 옮기되 기존 API와 호환되게 하고, 원래 있던 테스트를 통과 기준으로 삼아라, 같은 테스트가 통과하고 차이가 문서로 남으면 그때 리뷰할 준비가 된 거다. AI가 스스로 됐는지 확인할 기준을 쥐여주는 셈입니다.
먼저 움직이게 하되 사람이 검토하기
일정에 맞춰 알아서 도는 작업을 걸어둘 수 있는데, 백서의 예시도 30분마다 메시지를 확인해 답장 초안까지만 쓰고 보내지는 말라는 식입니다. 멀리서 휴대폰으로 다음 단계만 승인하더라도, 그건 검토를 건너뛰는 게 아니라 일이 막히지 않게 다음 수를 풀어주는 것이라고 말합니다.

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

AI에게 큰 작업을 맡기기 전에, 무엇이 됐을 때 끝인지를 한 문장으로 먼저 적어보기. 그 문장만 보고 AI가 스스로 다 됐는지 확인할 수 있는지 따져보세요.
반복하는 일 하나를 골라, 매번 새 대화를 열지 말고 같은 자리에서 이어가기. 다음에 시작할 때 처음부터 다시 설명하는 시간이 줄어드는지 확인해보세요.
다음 회의나 통화가 끝나면, 정리된 문장 대신 떠오르는 대로 음성으로 풀어 AI에 넣어보기. 매끈하게 정리한 입력과 결과가 어떻게 다른지 비교해보세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

AX에 꼭 필요한 '온톨로지', 회의록으로 시작하는 법 (feat. 티로)

이 글은 티로(더플레이토)와 함께 브랜디드 콘텐츠로 제작했습니다.

30만 명이 쓰는 서비스를 10명 남짓한 팀이 운영합니다. 코드의 95%를 사람이 아니라 AI가 짜죠. 에이전트가 사람 한 명과 함께 누적 200건이 넘는 B2B 거래를 처리하고, 유저가 올린 버그를 분석해 수정안을 만든 뒤 엔지니어를 호출해 검토를 요청합니다. AI 노트테이커 '티로(Tiro)'를 만드는 더플레이토 팀이 일하는 방식입니다.

AI 노트테이커 티로 화면 캡처 <출처: 더 플레이토>

이런 'AI 네이티브' 회사가 요즘 IT 업계 최전선에서 낯선 풍경은 아닙니다. 앤트로픽(Anthropic)은 프로덕션에 들어가는 코드의 80% 이상을 자사 AI가 작성한다고 밝혔고(2026년 5월 기준), 2025년 초 와이 컴비네이터(Y Combinator) 배치에서도 네 팀 중 한 팀꼴로 코드의 95%가량을 AI가 만들었다는 이야기가 나왔죠. 더플레이토도 그 흐름 위에 있습니다.

티로는 회의를 실시간으로 녹음해 그 자리에서 회의록으로 정리해주는 것이 기본 기능인 AI 노트테이커입니다. 이렇다 할 광고도, 아웃바운드 영업도 없이 입소문만으로 사용자를 모았습니다.

사람들이 먼저 알아본 건 그 정확도였습니다. 한 언론사의 노트테이킹 앱 테스트에서 스웨덴어와 영어가 뒤섞인 영상을 처음부터 끝까지 정확히 받아 적은 건 티로가 유일했고, 청각장애인 사용자가 “가장 정확도가 높다”는 리뷰를 남기기도 했죠. 보안도 일찍 챙겨, ISO 27001와 SOC2 Type2를 취득했습니다.

티로는 자신의 팀처럼 에이전트를 통해 같은 인원으로도 10배 이상의 일을 처리할 수 있는 상태를 AX로 정의하고, 이를 기업 고객에게 이식하고 있다는데요. 그 시작이 거창한 에이전트 기술이 아니라 '티로'로 만드는 '회의록'이라고 합니다. 작은 팀으로 큰 성과를 만드는 비결, 김상철 CTO에게 직접 물었습니다.

요즘IT와 인터뷰하고 있는 더플레이토 김상철 CTO <출처: 더 플레이토>

회의록은 어떻게 AX 자산이 되는가

왜 회의록이 AX의 출발점일까요. 그 실마리는 제품 이름에 있습니다.

'티로(Tiro)'는 기원전 로마에서 웅변가 키케로 곁을 지키며 그의 모든 말과 대화를 받아 적은 비서의 이름입니다. '세계 최초의 속기사'로 불리죠. 김상철 CTO가 숱한 후보 끝에 이 이름을 고른 이유도 거기 있었습니다. 키케로를 둘러싼 모든 맥락을 알고 있던 존재, 그게 이 팀이 만들고 싶은 제품의 모습이었으니까요. "추구해야 할 방향을 등대처럼 제시해 준 이름"이라고 그는 말합니다.

이 이름처럼, 티로가 지향하는 것은 사용자들의 모든 맥락을 아는 제품입니다. 이렇게 맥락을 강조하는 이유는, “좋든 싫든 모든 기업이 에이전트를 갖게 되는 미래”를 그리고 있기 때문입니다. 그 미래에 기업의 역량을 가르는 것은 에이전트의 품질입니다.

“에이전트가 어떤 맥락과 지식을 갖고 행동하고 판단하느냐가 그 품질을 좌우하고, 그 품질의 합이 회사의 AI 경쟁력이 됩니다." 김 CTO의 말입니다.

그는 두 에이전트를 예로 듭니다. 한쪽은 고객의 사용량이 줄자 "사용량을 더 권해보자"고 제안합니다. 다른 한쪽은 고객사와의 회의 내용을 뒤져 "이 회사가 지금 보안 인증 심사 중이라 잠깐 사용이 준 것"이라는 맥락을 읽고, 보안 검토를 돕는 제안을 내놓습니다. “둘 중 어느 쪽이 조직에 가치를 만들지는 분명합니다.”

그리고 이 맥락은 문서나 데이터베이스, 코드 곳곳에 흩어져 있는데, 그중에서도 회의와 대화에는 기존 시스템에 남기 어려운 의사결정의 배경과 예외, 현장의 표현이 담깁니다. 그리고 그 가운데 가장 쉽게 사라지는 게 바로 이 회의 맥락이고요.

"AX라는 게 결국, ‘회사 안에 흩어져 있는 여러 재료와 소스를 가지고 무슨 요리를 만들 거냐’라는 과제라고 봅니다. 그 재료가 바로 조직의 맥락이고요. 어떻게 활용할지는 그다음입니다. 그래서 저희는 일단 좋은 재료부터 제대로 모으자는 쪽을 택한 겁니다."

티로 화면 <출처: 더 플레이토>

여기서 중요한 건 ‘제대로’ 모은다는 것입니다. 제대로 모은다는 것이 무엇인지 설명하기 전에, 먼저 티로의 에이전트들이 어떻게 일하는지를 살펴보겠습니다. 이 모습은 티로가 팀 내부에서 회의록을 '제대로' 모았기에 가능한 것이고, 동시에 티로가 다른 기업에 이식하려는 AX의 이상적인 모습입니다. IT 업계 말로는 '온톨로지'를 갖춘 조직의 에이전트라고 할 수 있고요.

열 명이 30만 명을 감당하는 법

회의록을 '제대로' 모은다는 건 곧 '위키' 기능을 말합니다. 회의록을 그냥 쌓기만 하는 게 아니라, 회의록에 흩어진 개념과 인물, 관계를 자동으로 정리해 연결해 주는 기능인데요, 뒤에서 자세히 소개하겠습니다. 우선 이 위키가 작동했을 때 에이전트가 어떻게 일할 수 있는지를 살펴보면 그게 왜 중요한지도 알 수 있는데요.

티로에서는 팀원 한 명마다 에이전트가 하나씩 붙습니다. 각 팀원을 본뜬 ‘디지털 트윈’ 같은 존재죠. 이런 구조를 만든 건 '매크로하드(Macrohard)'라는 목표 때문입니다.

매크로하드는 일론 머스크가 자신의 AI 기업 xAI에서 진행 중인 프로젝트의 이름입니다. 마이크로소프트(Microsoft)를 뒤집어 '작은(Micro)'을 '큰(Macro)'으로, '부드러운(Soft)'을 '단단한(Hard)'으로 바꾼 농담 같은 이름이지만, 발상은 진지합니다. 소프트웨어 회사는 물리적 하드웨어를 직접 만들지 않으니, 수백 개의 AI 에이전트가 협업해 회사 하나를 통째로 대신하게 하는 것도 원칙적으로 가능하다는 구상이죠.

티로는 2026 초 이 발상을 팀 내부 목표로 삼았습니다. 사람이 일일이 손대지 않아도 회사가 알아서 돌아가게 만든다는 것이 목표죠.

각 에이전트는 단순히 일을 거드는 데 그치지 않습니다. 가령 '레오'라는 팀원에게는 '미오'라는 에이전트가 있는데, 미오의 목표는 레오의 일을 돕는 걸 넘어 레오처럼 생각하고 말하는 것입니다. 슬랙에서 레오가 호출되면 미오가 먼저 답하고, 레오가 직접 답한 내용과의 차이를 좁혀가며 말투와 판단을 맞춰가죠.

에이전트가 일하는 방식이 가장 잘 드러나는 것은 인바운드 B2B 세일즈 에이전트 ‘바린(Barin)’의 사례입니다. 바린은 티로가 그동안 200개 이상의 고객사와 소통한 맥락을 모두 알고 있습니다. 뒤에서 소개할 ‘위키’ 기능을 통해 회의록에 쌓여 정리된 고객의 맥락을 전부 파악해, 잠재고객의 문의가 들어오면 고객사의 특성과 문의 내용에 맞는 회신 메일을 작성합니다.

바린은 매주 모든 고객사의 사용량을 모니터링하며 고객이 이탈할 가능성을 진단한 뒤, 이탈할 위험이 보이는 고객사를 감지하면 그 고객사와의 소통 내역, 또 그 고객사와 유사한 사용 패턴을 보이는 고객사와의 소통 내역을 확인합니다. 이를 바탕으로 이탈 방지 계획을 만들죠. 또 보안 대응 에이전트 겨울(Gyeoul)과 함께 B2B 고객의 보안 관련 문의를 자동으로 검토하고 검토 보고서를 작성합니다. 이 과정에서 사람이 할 일은 이메일과 보고서를 검토하고 전송 버튼을 누르는 일밖에 없습니다.

더플레이토의 내 인바운드 B2B 세일즈 에이전트 <출처: 더플레이토>

도입부에서 소개한 버그 처리 에이전트도 같은 원리로 돌아갑니다. 버그 제보가 들어오면 에이전트가 로그와 사용 맥락을 스스로 뒤져 진단하고 수정안을 올린 뒤 담당 엔지니어를 부르는 식이죠.

더플레이토의 내부 CS 에이전트 <출처: 더플레이토>

에이전트가 이렇게 담당자처럼 일하도록, 티로는 두 가지를 마련해 뒀습니다. 하나는 반드시 지켜야 할 규칙을 하나의 저장소에 못 박아두고, 에이전트가 움직이기 전에 그 규칙에 어긋나지 않는지부터 확인하게 한 것. 다른 하나는 회의록에 정리된 조직의 맥락을 그때그때 읽어오게 한 것입니다. 그래서 에이전트는 제멋대로 굴지 않고, 사람 팀원이 그러듯 조직이 합의한 기준과 맥락 위에서 판단하죠. 티로가 10명 정도의 인원으로 30만 유저를 상대하는 배경입니다.

그런데 사실 그 ‘맥락’을 어떻게 읽어올 수 있느냐, 그게 에이전트를 구축할 때 항상 쉽지 않은 문제입니다. 이를 가능하게 하는 게 '온톨로지'인데요. 쉽게 말하면, 조직이 쓰는 개념과 관계를 한데 정리해 둔 것입니다. 에이전트는 그 위에서 조직의 언어로 상황을 이해하고 판단하고요. 티로가 '회의록을 제대로 모았던 것이 온톨로지의 출발점'이었다고 김CTO는 말합니다. 앞서 밝혔던 그 '위키'가 바로 이 일, 회의록을 정리해 그 출발점을 놓는 기능인 거죠.

AI 위키는 회의록을 어떻게 지식으로 정리하는가

이제 위키가 푸는 문제부터 짚어보죠. 회의록은 조직에서 가장 부지런히 쌓이는 기록이지만, 정작 다시 펼쳐 보는 일은 드뭅니다. 공들여 적어두고도 그대로 묻히는 셈이죠. 티로가 팀 내부에서 온톨로지로 풀어온 이 문제를, 위키는 다른 기업도 손쉽게 시작할 수 있게 해줍니다.

티로에서 회의록을 녹음해 기록하면 자동으로 박상무라는 사람의 위키페이지가 생기고, 그 페이지에서 박상무라는 사람의 인물 정보와 관련된 페이지, 관계도를 조회할 수 있다. 티로의 위키 기능은 회의록을 기반으로 이러한 위키 페이지를 자동으로 생성해 조직에서 사용되는 개념, 인물, 관계를 체계적으로 정리하고 연결해준다. <출처: 더플레이토>

위키는 이름 그대로, 조직의 지식을 한데 모아둔 위키피디아 같은 것이라고 보면 됩니다. 이 발상에 불을 지핀 건 AI 연구자 안드레이 카파시(Andrej Karpathy)가 던진 'LLM 위키'라는 개념이라고 김 CTO는 말합니다. AI 에이전트가 흩어진 원본 자료를 읽어 개념별로 정리한 문서로 묶고 계속 갱신하게 함으로써, 물어볼 때마다 처음부터 뒤지는 대신 지식이 쌓이게 하자는 발상입니다.

작동 방식은 이렇습니다. 회의 기록이 끝나면 티로가 대화 전체를 처음부터 끝까지 훑습니다. 그러면서 핵심이 되는 개념들을 짚어냅니다. 예를 들어 요즘IT와 진행한 이 인터뷰를 기록했다면, ‘온톨로지’ ‘요즘IT’ ‘김상철’ ‘더 플레이토’ 같은 개념을 추출합니다.

개념을 추출할 때는 기존 위키에 유사한 개념이 있는지도 찾아봅니다. 예를 들어 티로는 가끔 ‘타로’처럼 잘못된 표현으로 기록되기도 하고, ‘tiro’처럼 영문으로 기록되기도 하는데, 이 세 가지가 같은 개념인지를 확인합니다. 그리고 같은 개념인 것이 확인되면 새 페이지를 계속해서 만들지 않고 기존에 있던 ‘티로’ 페이지에 새로 연결된 사항만 추가합니다.

그다음 그 개념들을 한 번 더 훑으며 서로의 관계를 살펴봅니다. 회의 참가자들이 같은 팀원인지, 누가 책임자인지, 어떤 사람이 앞서 추출한 개념과 연결되어 있는지 등 관계를 연결하기 시작합니다. 이 과정이 회의가 끝날 때마다 자동으로 반복되며 위키가 자라납니다. 물론 사람이 페이지를 보고 수정할 수도 있습니다.

그렇게 만들어진 페이지에는 네 가지가 담깁니다. 요즘IT가 티로와 진행한 이번 인터뷰로 예를 들어볼게요. 인터뷰를 녹음하고 ‘요즘IT’라는 개념을 추출해 요즘IT 페이지가 생깁니다. 이 페이지에는 이름과 별칭('요즈마이티' 'yozm'처럼 같은 뜻의 다른 표기), 그게 무엇인지에 대한 설명, 그 설명이 어떤 대화에서 나왔는지 보여주는 출처, 어떤 사람·프로젝트·개념과 이어지는지를 보여주는 관계죠. 네 가지 모두 관련된 새로운 회의가 끝날 때마다 갱신됩니다.

회의에 참가한 인물 정보를 자동으로 생성한 페이지 예시 화면. 인물에 대한 설명, 설명의 출처, 관련 페이지가 정렬되어 있어 ‘요즘IT’라는 개념의 정의와 관계도에 대해 구조적으로 이해할 수 있다. <출처: 더플레이토>

김 CTO는 이걸 '조직의 백과사전'이라 부릅니다. 사람만 펼쳐 보는 게 아닙니다. 에이전트도 똑같이 이 위키를 검색해, "요즘IT와 인터뷰한 사람은 누구였지?"라는 물음에 "김상철"이라고 답할 수 있게 됩니다. 에이전트가 바로 이 맥락 위에서 작동하는 셈이죠.

이렇게 정리한 위키가 곧바로 온톨로지가 되는 것은 아닙니다. 다만 조직에서 실제로 쓰이는 개념과 관계를 출처와 함께 보여주기 때문에, 온톨로지를 설계하기 전에 검토할 재료가 됩니다. 더플레이토는 이 단계를 ‘프리 온톨로지’라고 부릅니다.

프리 온톨로지란 무엇이고 왜 필요한가

맥락이 에이전트의 품질을 가른다는 말은, 규모가 큰 기업일수록 더 무겁게 다가옵니다. 수천 명이 일하는 조직에서 에이전트가 제대로 판단하려면, 그 조직이 쓰는 개념과 관계가 잘 정리돼 있어야 하니까요.

이렇게 모은 개념과 관계의 후보에 조직이 합의한 정의와 규칙, 실행 방식을 더하면 운영에 활용할 수 있는 온톨로지로 발전할 수 있습니다. 김 CTO는 “쉽게 말하면 조직의 ‘디지털 트윈’을 만드는 것”이라며 “데이터와 로직, 액션, 이 세 가지로 이뤄진, 살아 움직이는 세포 같은 것이 온톨로지”라고 말합니다.

‘창고’로 설명해본 온톨로지 뜻 <출처: 요즘IT, Napkin으로 제작>

“'창고'라는 개념으로 예를 들어볼게요. 우선 창고에 무엇이 있고, 창고의 이름이나 창고 안에 있는 것들의 이름, 담당자, 창고의 위치 등을 나타내는 정보가 있어야겠죠. 그게 데이터입니다. 그 위에 ‘로직’이란 레이어가 있습니다. ‘그 창고는 어떤 식으로 운영되는가’와 관련된 개념들이죠. 예를 들어, 창고가 비었다는 것은 무엇을 의미하는지, 창고가 불에 탔다는 것은 어떤 것인지 등을 정의하는 것입니다. 그다음엔 ‘액션’이라는 레이어가 있습니다. 창고가 비었다면, 불이 났다면 어떤 것을 해야 하는지를 나타내는 것이죠. 즉 조직이 쓰는 개념과 관계의 지도입니다. 이게 있으면 에이전트는 ‘창고가 비었다’는 신호를 감지했을 때 조직이 합의한 언어로 그 상태를 이해하고 행동을 실행합니다.”

데이터·로직·액션이라는 구조의 바탕에는 조직이 쓰는 개념의 의미와 관계를 명확히 하는 작업이 있습니다. 김 CTO는 이를 “조직 안에서 같은 단어를 같은 뜻으로 쓰자고 합의하는 것”이라고 쉽게 설명합니다.

이는 모든 부서가 한 가지 뜻만 쓰게 하는 일이라기보다, 같은 단어가 부서마다 다른 뜻으로 쓰일 때 그 차이까지 분명히 해두는 일에 가깝습니다. 같은 회사 안에서도 '매출'이나 '고객'의 범위를 부서마다 다르게 이해하는 일이 흔한데요. 영업팀과 재무팀이 '매출'을 서로 다른 기준으로 잡고 있다면, 에이전트에게 "이번 분기 매출"을 물어도 어느 쪽 숫자인지 알 수 없습니다.

이 작업에는 두 가지 어려움이 있습니다. 먼저 현장에서 실제로 쓰이는 언어와 맥락을 발견해야 합니다. 그다음 발견한 개념과 관계를 조직이 공식적으로 사용할 정의와 규칙으로 정리해야 합니다. 김 CTO는 특히 최종 정의를 맡은 사람이 현장의 맥락을 충분히 알기 어렵다는 점을 지적합니다.

“누군가 ‘우리 창고는 이렇게 정의한다’고 해야 해요. 그런데 문제는, 정작 그걸 정의해야 하는 리더들이 실무적인 맥락을 충분히 알지 못할 수 있다는 거예요. 창고를 정의해야 하는 리더는 정작 창고에 매일 가지는 않으니까요.”

바로 여기서 회의록의 가치가 드러납니다. 회의에는 실무자가 반복해서 사용하는 표현뿐 아니라, 그 표현이 쓰인 상황과 예외, 판단 근거가 함께 남기 때문입니다. 티로 위키는 이를 조직의 공식 정의로 곧장 확정하는 대신, 앞서 본 그 개념과 관계를 출처와 함께 정리해둡니다. 이후 조직이 공식적으로 단어의 정의와 규칙을 설계할 때 가장 먼저 검토할 재료가 되는 이것이 티로가 돕는 프리온톨로지이죠.

온톨로지와 프리 온톨로지 차이를 나타내는 인포그래픽 <출처: 더플레이토 블로그>

더플레이토는 여기서 한 걸음 더 나아가, 이 프리 온톨로지 위에 조직이 합의한 정의와 규칙을 얹어 온톨로지까지 갖춘 것입니다. 앞서 미오가 레오처럼 판단하고, 영업 에이전트가 고객사 맥락을 읽어낼 수 있었던 것도 그 덕분이고요. 티로가 위키 기능을 통해 제공하는 것은 그 앞 단계인 프리 온톨로지이고, 조직은 거기에 정의와 규칙을 더해 온톨로지로 완성할 수 있습니다.

김상철 CTO가 말하는 AX란
AI를 가장 잘 쓰는 법은 지식을 온톨로지로 저장해 에이전트에게 전달하는 것
다만 문제는 흩어진 지식들을 실제 업무와 기업의 맥락에 맞게 '올바르게' 적용하는 구조가 없다는 것
이를 위해 "지식"이 되기 전의 사실들을 '창고'에 해당하는 프리 온톨로지에 저장해야 함
그때 빛을 발하는 것이 팀 단위 맥락과 상황, 판단 근거를 잘 보존하는 '회의록'
그 회의록을 잘 관리하고 규칙에 맞게 저장하는 것이 온톨로지, 나아가 AX의 시작

AI가 다 해도 왜 ‘보안’과 ‘취향’은 사람의 몫인가

코드의 95%를 AI가 쓰고 에이전트가 사람의 일을 대신해도, 김 CTO가 끝까지 사람의 몫으로 남겨둔 자리가 있습니다. 가장 단호한 건 보안입니다. AI에 그토록 많은 일을 맡길 수 있는 것도, 역설적으로 보안의 기준만큼은 사람이 직접 엄격하게 세우기 때문입니다. 개발 환경과 고객 인프라를 완전히 분리해 AI가 무엇을 하든 치명적 사고로 번지지 않게 해두고, "그 가드레일을 정하는 일만큼은 사람이 해야 한다"는 원칙을 지킵니다.

“잘못된 기능은 배포한 뒤 고치면 되지만, 인프라나 데이터베이스는 단 한 번의 실수가 회사에 '사망 선고'가 될 수 있어요. 그래서 그 최종 판단은 사람이 전부 읽고 확인하고, 모든 결정은 로그로 남겨 되돌릴 수 있게 합니다.”

요즘IT와 인터뷰하고 있는 티로 김상철 CTO <출처: 더플레이토>

사람이 지켜야 할 또 하나의 영역은 '취향과 철학'입니다. "무엇이 좋은 제품이고 무엇이 아름다운가에 대한 판단은 외주화할 수 없는, 회사의 마지막 경쟁력입니다." 그래서 더플레이토 팀에선 결정을 내릴 때도 치열하게 부딪힙니다.

"'애플이 이렇게 했으니까'라는 이유는 잘 받아들여지지 않아요. '나는 이게 좋고, 그 이유는 이것'이라고 자기 판단을 말해야 하죠. 서로 다른 취향이 계속 충돌하고 논쟁하는 문화가 팀의 색깔을 또렷하게 만드는 것 같아요."

사람이 보안과 취향을 끝까지 놓지 않기에, 나머지를 에이전트에 맡길 수 있습니다. 에이전트가 그렇게 한 사람의 일을 점점 더 대신해갈수록 사용자의 모든 맥락을 아는, 키케로의 ‘티로’같은 ‘Chief of Staff’를 누구나 가질 수 있게 된다는 것입니다. 그 대상은 이미 개인을 넘어 조직으로 넓어지고 있고요. 김 CTO는 "국방이나 정부처럼 가장 민감한 곳에서도 쓸 수 있어야 진짜 가치"라며 실제로 그런 기관의 문의도 받고 있다고 말합니다.

언젠가 모든 기업이 자기 안에서 오간 모든 대화를 남기게 될 거라는 게 그의 믿음입니다. 그 대화가 흩어진 회의록으로 묻힐지, 조직의 언어로 다듬어진 자산이 될지가 차이를 만들 것이고요. 그리고 그 자산은 빨리 쌓을수록 격차가 복리로 벌어집니다. 1년 먼저 시작한 회사의 에이전트는 이미 조직의 역사를 알고 일하니까요. 조직이 기록을 자산화하고 스스로 언어를 통일하는 일. AX는 거기서부터 시작됩니다.

]]>

SaaS의 종말? AI 시대에 적합한 소프트웨어는 무엇일까

SaaS의 사용 방식이 바뀌고 있다

지난 10여 년 동안 기업용 소프트웨어의 중심에는 SaaS(Software as a Service)가 있었다. CRM은 영업 조직의 표준 도구가 되었고, ERP는 재무와 구매 흐름을 관리했으며, HRIS(Human Resources Information System)는 사람과 조직의 정보를 기록했다. 사용자는 브라우저에 로그인해 화면을 보고, 메뉴를 찾고, 버튼을 누르며 업무를 처리하면 됐다.

우리 회사도 다양한 SaaS를 오랜 기간동안 써왔다. 인사&평가 관리는 Workday, 전자 계약서 작성은 DocuSign, 회계 및 재무 처리는 SAP 등 이러한 SaaS는 기업에서 여러 분야의 필요한 각각의 영역을 전문적으로 대신해 주고, 기업이 본질적인 사업에 집중할 수 있도록 많은 도움을 주었다.

하지만 AI 에이전트가 등장하면서, SaaS를 사용하는 기업 및 고객은 조금씩 줄어들고 있다. 사용자는 더 이상 “CRM에 들어가서 고객 목록을 필터링해줘”라고 생각하지 않는다. 대신 “이번 분기 매출 리스크가 큰 고객을 찾아 대응안을 제안해줘”라고 말하고 싶어 한다. 원하는 것은 소프트웨어 사용 자체가 아니라 업무의 완료다.

섣불리 생각해서 이러한 변화가 곧 CRM, ERP, HRIS의 종말을 뜻한다고 속단할 수는 없다. a16z가 지적하듯이 이런 시스템 오브 레코드는 단순한 데이터베이스가 아니다. 그 안에는 회사의 공식 데이터, 승인 절차, 권한 구조, 예외 처리, 컴플라이언스 요구사항이 들어 있다. AI가 화면이라는 “머리”를 바꿀 수는 있어도, 기업 운영의 몸통까지 쉽게 대체하기는 어렵다.

따라서 AI 시대의 변화는 기존 SaaS가 사라지는 것이 아니라, 그 위에 새로운 추론과 실행 계층이 올라가는 것에 가깝다. 앞으로의 소프트웨어는 사람만 쓰는 도구가 아니라, 사람과 AI 에이전트가 함께 사용하는 업무 시스템이 되어야 한다.

그렇다면 에이전트가 잘 사용할 수 있는 SaaS를 만들려면 우리는 어떠한 부분을 신경 써야 할까? 이번 글에서는 이 주제에 대한 생각들을 이야기해 보고자 한다.

<출처: 픽사베이>

에이전트 친화적인 SaaS는 무엇이 달라야 하는가

에이전트 친화적인 SaaS란 사람이 쓰기에도 좋고, AI가 대신 쓰기에도 좋은 소프트웨어다. 여기서 중요한 점은 AI가 사람처럼 화면을 클릭하게 만드는 것이 최선은 아니라는 점이다. 화면은 사람에게는 편하지만 AI에게는 불안정하다. 버튼 위치가 바뀌거나 팝업이 뜨는 것만으로도 작업이 실패할 수 있다.

나의 경우, 이전에 자동으로 이메일을 보내는 에이전트 작업을 해본 경험이 있다. 이메일 앱에서 주소를 입력하고 필요한 정보(제목, 본문 등)를 입력해서 이메일을 발송해야 하는데, 브라우저 MCP가 엉뚱한 입력창에 값을 넣는다는지, 전송 버튼을 못 찾아서 시간을 허비한다든지 하는 사례가 있었다. 이러한 작업은 앞으로 이렇게 에이전트가 브라우저를 탐색해서 하는 것이 아니라, 메일 작성, 메일 전송 등의 작업을 수행하는 API를 찾아서 인증 후 요청하는 방식으로 처리해야 빠르고 깔끔하다는 것을 알게 되었다.

최근 SaaS-Bench 연구에서도 실제 SaaS 환경에서 AI 에이전트가 긴 업무 흐름을 끝까지 수행하는 데 여전히 어려움을 겪는다는 결과가 나왔다. 이는 AI가 부족해서라기보다, 현재의 SaaS가 에이전트가 안정적으로 이해하고 실행하기에는 너무 사람 중심으로 설계되어 있다는 뜻이기도 하다.

그렇다면 SaaS는 어떻게 바뀌어야 할까?

1) UI/UX: 작업 화면에서 감독 화면으로

전통적인 SaaS UI는 사용자가 직접 조작하는 것을 전제로 했다. 메뉴, 버튼, 입력 폼, 대시보드가 핵심이었다. 하지만 AI 시대의 UI는 사용자가 모든 것을 직접 클릭하는 공간이 아니라, AI가 무엇을 하려는지 이해하고 승인하는 공간이 되어야 한다.

예를 들어, AI 에이전트가 “이탈 가능성이 높은 고객을 선별하고 후속 메일 초안을 작성했다”고 하자. 좋은 UI라면 단순히 결과 목록만 보여줘서는 안 된다. 어떤 데이터를 근거로 판단했는지, 어떤 고객을 위험군으로 봤는지, 어떤 메일을 보내려는지, 실제 발송 전에 사람이 승인해야 하는 항목은 무엇인지 보여줘야 한다.

즉, UI는 “작업 도구”에서 “감독 도구”로 바뀌어야 한다. 사용자는 모든 필드를 직접 채우는 사람이 아니라, AI가 제안한 작업 계획을 검토하고 위험한 실행을 승인하는 사람이 된다.

이를 위해서는 AI의 작업 계획, 변경 전후 비교, 승인 단계, 실행 로그, 되돌리기 기능이 제품 경험의 일부가 되어야 한다. TechRadar가 최근 지적한 것처럼 기업 AI가 “개인 생산성 도구”에 머무르면 신뢰를 얻기 어렵다. 조직의 워크플로 안에서 투명하게 작동하고, 통제 지점이 있어야 실제 업무에 들어갈 수 있다.

2) 인증과 권한: AI에게도 별도의 신분증이 필요하다

AI 에이전트가 SaaS를 사용하려면 인증과 권한 설계가 훨씬 중요해진다. 가장 위험한 방식은 사용자의 계정을 AI에게 그대로 넘겨주는 것이다. 사용자가 관리자 권한을 가지고 있다고 해서, AI가 모든 관리자 작업을 자동으로 실행해도 된다는 뜻은 아니다.

예를 들어, 한 기술 스타트업의 CTO가 깃허브의 레포지토리를 삭제할 권한이 있다고 가정해 보자. 레포 삭제를 할 권한이 있지만, 그렇다고 마음대로 레포 삭제를 해도 된다는 뜻은 아니다. 사람은 이러한 판단을 할 수 있지만 에이전트는 이렇게 판단하지 못하고 “레포 삭제 권한이 있어? 그러면 삭제할게.” 라고 1초도 안 되는 순간에 판단 해 버릴지도 모른다.

AI에게는 별도의 정체성과 제한된 권한이 필요하다. OAuth는 비밀번호를 넘기지 않고 특정 작업만 허용하는 제한된 열쇠를 발급하는 방식이다. 예를 들어 AI에게 “고객 목록은 조회할 수 있지만 계약서는 다운로드할 수 없다”, “메일 초안은 만들 수 있지만 발송은 사람이 승인해야 한다” 같은 권한을 줄 수 있다.

RBAC(Rule Based Access Control), 즉 역할 기반 접근 제어도 더 세밀해져야 한다. 영업 지원 에이전트, 재무 검토 에이전트, 고객 응대 에이전트는 서로 다른 데이터와 실행 권한을 가져야 한다. 또한 로그에는 “김 대리가 했다”가 아니라 “김 대리의 요청을 받아 영업 분석 에이전트가 수행했다”는 식으로 남아야 한다.

Salesforce 측에서도 AI를 잘못 도입하면 데이터와 가드레일 부족으로 큰 위험이 생길 수 있다고 경고한 바 있다. 기업용 AI에서 핵심은 “AI가 얼마나 똑똑한가”만이 아니다. AI가 어떤 권한으로 무엇을 했는지 추적할 수 있는가, 위험한 작업을 사람이 승인할 수 있는가, 문제가 생겼을 때 복구할 수 있는가가 더 중요하다.

3) API 명세와 문서: AI가 읽을 수 있는 제품 설명서

에이전트 친화적인 SaaS에서 API는 부가 기능이 아니라 핵심 인터페이스다. 과거에는 API가 외부 개발자나 파트너를 위한 연동 수단이었다면, 앞으로는 AI 에이전트가 제품을 사용하는 주된 통로가 될 수 있다.

<출처: Magnific>

사람은 화면을 보며 문맥을 추론할 수 있다. 하지만 AI가 안정적으로 일하려면 API의 의미가 명확해야 한다. 어떤 API가 어떤 업무 목적을 갖는지, 어떤 권한이 필요한지, 호출하면 실제 상태가 바뀌는지, 실패했을 때 어떻게 재시도해야 하는지가 문서에 드러나야 한다.

예를 들어, PATCH /customers/{id}라는 API가 있다고 하자. 단순히 “고객 정보 수정”이라고 적는 것만으로는 부족하다. 어떤 필드를 바꿀 수 있는지, 고객에게 알림이 가는지, 감사 로그가 남는지, 되돌릴 수 있는지, 대량 수정 시 제한은 무엇인지까지 설명해야 한다.

에이전트를 만드는 개발자들은 그래서 필자도 그렇고 많은 경우에 실제로 동작하는 코드보다 그 코드를 검증하기 위한 테스트 코드, 그 코드를 설명하는 주석 코드를 훨씬 더 많이 적는 경향이 있다. 사람은 히스토리를 알면 이 맥락 안에서 이 로직이 무엇인지 알 수 있지만 에이전트는 이러한 내용을 최대한 자세하게 설명해 주어야 정확한 판단을 할 수 있기 때문이다.

AI 시대의 API 문서는 개발자를 위한 참고서가 아니라, AI가 읽는 제품 설명서에 가깝다. OpenAPI 같은 기계가 읽을 수 있는 명세는 기본이고, “견적서 생성”, “승인 요청”, “환불 검토”처럼 실제 업무 단위의 API가 필요하다. 단순 CRUD API만으로는 AI가 복잡한 업무를 안전하게 수행하기 어렵다.

4) 데이터와 업무 맥락: 진짜 해자는 화면이 아니라 운영 지식이다

AI가 화면 조작을 대신하면, 사용자가 특정 SaaS UI에 익숙해져 생기던 락인은 약해질 수 있다. 메뉴 위치나 버튼 사용법을 사람이 외울 필요가 줄어들기 때문이다. 그렇다면 무엇이 소프트웨어의 해자가 될까? 데이터, 권한, 워크플로, 컴플라이언스, 그리고 고객사의 운영 맥락이다.

Bain은 에이전트 AI가 SaaS를 없애기보다 SaaS 사이의 비싼 조정 업무를 자동화할 가능성이 크다고 본다. 예를 들어 ERP에서 데이터를 뽑고, 스프레드시트와 대조하고, 벤더 메일을 해석하고, 예외 상황을 판단해 담당자에게 넘기는 일이다. 이런 업무는 단일 SaaS 화면 안에서 끝나지 않는다. 여러 시스템, 사람, 규칙 사이를 오가야 한다.

따라서 AI 시대의 소프트웨어 회사는 “예쁜 화면”보다 “업무 맥락을 얼마나 잘 구조화했는가”로 경쟁하게 될 가능성이 크다. 고객사의 데이터가 무엇을 의미하는지, 어떤 승인 절차를 거쳐야 하는지, 어떤 예외가 중요한지, 어떤 작업은 자동화하면 안 되는지를 제품이 이해하고 있어야 한다.

5) 가격 모델: 좌석 수에서 결과 중심으로

AI 에이전트는 SaaS의 가격 모델도 바꾸고 있다. 전통적인 SaaS는 사용자가 많을수록 가치가 커진다고 보고 좌석 수 기준으로 과금했다. 하지만 AI가 여러 사람의 반복 업무를 대신한다면, 좌석 수만으로 가치를 설명하기 어려워진다.

Zendesk의 AI 상담 과금 모델은 이 변화를 잘 보여준다. Zendesk는 AI 에이전트가 고객 문의를 성공적으로 해결했을 때 과금하는 결과 기반 모델을 제시했다. 이는 소프트웨어가 “접근 권한”이 아니라 “완료된 업무”를 팔기 시작했다는 신호다.

Bain도 SaaS 기업들이 AI 시대에는 로그인 수가 아니라 결과에 맞춰 가격을 설계해야 한다고 말한다. 고객이 원하는 것은 더 많은 화면, 더 많은 기능, 더 많은 좌석이 아니다. 더 적은 시간, 더 적은 오류, 더 빠른 업무 완료다.

단순히 AI 기능을 붙이는 것만으로는 부족하다

AI 시대에 적합한 소프트웨어는 단순히 챗봇을 붙인 SaaS가 아니다. AI가 이해하고, 사용할 수 있고, 안전하게 실행할 수 있으며, 사람이 그 과정을 감독할 수 있는 소프트웨어다.

앞으로 소프트웨어 회사가 고민해야 할 방향은 다음과 같지 않을까 예상해 본다.

제품을 화면 중심이 아니라 업무 모델 중심으로 재설계해야 한다.
AI 에이전트가 사용할 수 있는 안정적인 API와 실행 계층을 제공해야 한다.
권한, 승인, 감사 로그, 복구 가능성을 기본값으로 만들어야 한다.
고객사의 데이터와 운영 맥락을 구조화해야 한다.
가격 모델을 좌석 수가 아니라 실제 업무 결과에 가깝게 바꿔야 한다.

AI 시대의 변화는 SaaS의 종말이라기보다 SaaS의 재정의에 가깝다. 기록하는 시스템에서 판단하고 실행하는 시스템으로, 클릭하는 도구에서 감독 가능한 업무 동료로, 사용자 수를 파는 제품에서 결과를 파는 제품으로 이동하는 것이다.

여러분이 만드는 혹은 사용하는 소프트웨어는 사람에게 초점이 맞춰져 있는가? 아니면 에이전트에게 초점이 맞춰져 있는가?

<참고>

]]>

아이팟·아이폰의 아버지 토니 파델: AI에게 넘겨선 안 될 한 가지

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

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

써볼 것: 로컬 코딩 LLM - 내 컴퓨터에서 직접 돌리는 코딩 모델, 지금 어디까지 왔나
참고할 것: 앤트로픽 연구 - 앤트로픽 40만 세션 분석, AI 코딩 시대에 살아남는 건 코딩 실력이 아니다
적용해볼 것: 아이팟·아이폰의 아버지 토니 파델: AI에게 넘겨선 안 될 한 가지

<출처: 해커 뉴스>

1. 써볼 것: 내 컴퓨터에서 직접 돌리는 코딩 모델, 지금 어디까지 왔나

클라우드에 올라간 모델을 불러 쓰는 대신, 코딩용 AI 모델을 자기 컴퓨터에 올려놓고 돌리는 사람들이 부쩍 늘었습니다. 얼마 전 Hacker News에 매일 코딩에 쓰던 Claude나 GPT를 로컬 모델로 갈아탄 사람 있냐는 질문이 올라왔는데, 1,200 포인트가 넘고 댓글은 500개가 넘게 달렸죠. 로컬 모델로 에이전트 코딩을 직접 시켜본 개발자 Alex Ewerlöf는 그 과정을 블로그에 꼼꼼히 정리해뒀습니다.

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

직접 돌리는 이유는 대개 비용, 보안, 그리고 모델이 언제 바뀔지 모른다는 불안입니다.

비용부터 보면, GitHub Copilot이 쓴 만큼 내는 과금으로 바뀌었고 클라우드 주력 모델 값도 만만치 않습니다. Ewerlöf도 자기가 쓰던 모델 값이 세 배 가까이 뛴 걸 계기로 꼽습니다. 로컬은 전기값과 한 번 장만한 장비 말고는 따로 나가는 돈이 없죠. 보안도 빼놓을 수 없습니다. 회사 코드를 외부 서버로 보내면 안 되는 환경이라면, 모델이 아무리 좋아도 클라우드는 선택지에서 빠지니까요. 로컬은 코드가 기기 밖으로 나가지 않습니다. 마지막은 통제권입니다. 지난주 Fable 5 사례처럼 잘 쓰던 모델이 갑자기 막히거나 조건이 바뀌는 걸 한 번 겪고 나면, 내 손에 모델 하나쯤 두고 싶어지죠.

어떻게 쓰나요?

크게 장비, 모델, 그리고 둘을 묶어주는 도구가 필요합니다.

장비: RTX 4090이나 5090 같은 그래픽카드, 또는 메모리를 큼직하게 단 통합 메모리 맥(CPU와 GPU가 메모리를 함께 써서 큰 모델을 올릴 수 있는 맥)이면 시작할 수 있습니다.
모델: Ewerlöf는 Gemma 4 26B-A4B를 추천하고, HN에서는 Qwen 3.6 35B-A3B를 쓰는 사람이 많았습니다. 둘 다 MoE 방식인데, 전체 크기는 커도 매번 그 일부만 작동해서 생각보다 가볍게 돌아갑니다.
도구: 모델을 받아 관리하는 LM Studio나 Ollama, 실제로 모델을 돌리는 엔진 llama.cpp·MLX·vLLM, 그리고 그 모델에 파일 읽기나 명령 실행 같은 손발을 달아 에이전트로 만들어주는 하네스(Pi나 Copilot 등)를 얹습니다.

세팅하다 보면 놓치기 쉬운 부분도 몇 개 있습니다. LM Studio는 한 번에 읽어 들이는 분량(컨텍스트 창)이 처음엔 4천 토큰으로 잡혀 있습니다. 이대로면 코드를 제대로 못 물리니까 15만 토큰쯤으로 직접 늘려놔야 합니다. 메모리가 빠듯할 땐 KV 캐시의 정밀도를 조금 낮추는 방법이 있는데, 이러면 VRAM을 28.75GB에서 22.45GB로 줄일 수 있어요. 생성 속도가 초당 10토큰 밑으로 떨어지면 실제로는 답답해서 쓰기 어려운 수준입니다.

많이들 쓰는 방식은 섞어 쓰기입니다. 방향을 잡고 계획하는 건 최신 클라우드 모델에 맡기고, 실제 구현은 로컬 모델에 시키는 식이죠. 로컬이 막히면 OpenRouter의 무료 모델로 잠깐 넘어가기도 하고요.

누구에게 좋을까요?

댓글에서 자주 나온 비유가 주니어와 시니어입니다. 로컬 모델은 하나하나 정확히 일러줘야 움직이는 주니어에 가깝고, Opus 같은 최신 모델은 아키텍처까지 알아서 고민하는 시니어에 가깝다는 거예요. 그래서 평가도 갈리죠. 4090이나 5090에 Qwen이나 Gemma를 올리면 간단한 작업은 충분하다는 사람도 있고, 한참 써보니 DeepSeek 같은 저렴한 클라우드 모델이 더 싸고 잘해서 로컬은 취미 수준이 한계라는 사람도 있었습니다.

참고로 Ewerlöf는 최근 DeepSeek V4 Pro로 갈아탔다고 적었는데, 성능이 Opus 4.8에 맞먹고 값은 훨씬 싸다는 수치는 모델을 만든 쪽 발표라 곧이곧대로 믿기보다 직접 확인해보는 게 좋습니다. 글에 나오는 속도나 절약 수치도 대부분 개인 환경에서 나온 후기라, 내 환경에서 직접 다시 재보는 게 좋습니다.

마지막으로 누구에게 맞는지 보면 이렇습니다.

잘 맞는 경우: 코드를 외부로 못 보내는 환경, 비용에 아주 민감한 경우, 직접 만지며 굴려보는 재미를 아는 사람.
굳이 안 써도 되는 경우: 코드를 꼭 내부에서만 다뤄야 할 이유가 없다면, 사실 대부분은 로컬까지 갈 필요가 없습니다. 그래픽카드나 메모리 큰 맥을 새로 장만해야 한다면 그 값을 뽑으려면 어지간히 많이 돌려야 하고, 컨텍스트 설정이나 모델 교체에도 계속 손이 갑니다. 아키텍처까지 맡기는 복잡한 작업이 많다면 오히려 더 답답할 수 있고요. 로컬 모델은 빠르게 좋아지고 있으니, 급한 게 아니면 나중에 다시 봐도 늦지 않습니다.

<출처: anthropic, Agentic coding and persistent returns to expertise>

2. 참고할 것: 앤트로픽 40만 세션 분석, AI 코딩 시대에 살아남는 건 코딩 실력이 아니다

Anthropic(앤트로픽)이 6월 16일 Agentic coding and persistent returns to expertise라는 연구 보고서를 냈습니다. 2025년 10월부터 2026년 4월까지 Claude Code 세션 약 40만 건, 사용자 약 23만 5천 명을 개인을 식별하지 않는 방식으로 분석한 자료입니다. 보고서의 핵심만 이야기하자면, 에이전트에게 코딩을 시킬 때 결과를 가르는 건 코딩 실력이 아니라 자기 분야를 얼마나 잘 아느냐였습니다.

어떤 연구인가요?

세션 기록을 모델(Claude Sonnet 4.6)이 읽어 분류하는 방식입니다. 두 가지는 미리 알아두면 좋은데요. 하나는 앤트로픽이 자사 도구인 Claude Code의 사용 데이터를 직접 분석했다는 점이고, 다른 하나는 여기서 말하는 성공이 실제 현장 결과가 아니라 기록에 남은 신호, 그러니까 커밋이나 통과한 테스트, 사용자의 확인 같은 걸로 판정됐다는 점입니다. 그래서 큰 흐름을 읽는 자료 정도로 참고하면 될 것 같습니다.

무엇을 발견했나요?

가장 먼저 눈에 띄는 건 사람과 AI가 일을 나눠 갖는 방식입니다. 사람이 무엇을 할지(계획)의 약 70%를 정하고, Claude가 어떻게 할지(실행)의 약 80%를 맡습니다. 사람은 방향을 잡고, 에이전트는 그걸 구현하는 셈이죠. 전문성이 높을수록 한 번 지시에 Claude가 더 많은 일을 합니다. 초보 세션은 프롬프트 하나에 행동 5개, 단어 600개 정도를 끌어내는데, 전문가 세션은 행동 12개에 단어 3,200개를 끌어냅니다.

여기서 전문성은 직함이 아니라 그 작업 하나에 한정된 이야기입니다. 시니어 엔지니어라도 처음 만지는 Rust 앞에서는 초보고, Python을 한 번도 안 써본 회계사라도 어떤 정산 규칙을 넣어야 하는지 정확히 알고 마감 때 빠진 부분을 짚어내면 그 작업에서는 전문가입니다.

그래서 코딩 배경 자체는 생각보다 덜 중요했습니다. 코드를 만든 세션에서 거의 모든 직군이 소프트웨어 엔지니어와 7%포인트 안쪽으로 성공했고, 관리직은 오히려 살짝 높기도 했죠. 일을 지시하고 위임하는 데 익숙한 점이 통한 걸로 보입니다. 성공률은 전문성을 따라 오르지만, 중급에서 전문가로 가는 구간의 차이는 크지 않았습니다. 깊이 통달하지 않아도 분야를 어느 정도 알면 대부분의 이득을 가져간다는 뜻이죠.

7개월 사이 일의 종류도 바뀌었습니다. 망가진 코드를 고치는 비중이 33%에서 19%로 줄고, 배포·운영, 데이터 분석, 문서 작성처럼 코드 주변의 일이 그 자리를 채웠습니다. 작업의 가치도 평균 25~27%쯤 올랐다고 하는데, 이건 프리랜서 공고와 견줘 매긴 거친 상대 추정치라 액수 그대로 읽기보다는 흐름으로만 보면 되겠습니다.

무엇을 얻어가야 하나요?

AI가 ‘어떻게’를 점점 가져가는 동안, 무엇을 만들지 정하고 그게 맞는지 정확히 짚어내는 내 이해가 차별점이 됩니다. 코딩 경력이 없어도 자기 분야를 잘 알면 같은 도구에서 더 많은 걸 끌어내고, 분야를 모르면 그 도구로도 얻는 게 적었으니까요. 앤트로픽 자사 데이터를 바탕으로 한 초기 연구라는 점은 감안해야 하지만, 코딩이 점점 누구나 하는 일이 되어가는 지금 내가 키워야 할 게 코딩 실력 그 자체가 아닐 수 있다는 신호로 읽을 만합니다.

<유튜브: Lenny's Podcast>

3. 적용해볼 것: 아이팟·아이폰의 아버지 토니 파델: AI에게 넘겨선 안 될 한 가지

Tony Fadell이 Lenny's Podcast에 출연해 AI 시대의 제품 만들기를 두고 이야기를 나눴습니다. 그는 아이팟을 만들고 아이폰을 함께 개발했고, 네스트를 세워 구글에 32억 달러에 판 인물이죠. 또, 제품을 만드는 사람들의 교과서로 꼽히는 「빌드(Build)」의 저자이기도 합니다. 화려한 이력을 가진 그가 이번 인터뷰에서 거듭 강조하는 건 하나입니다. AI에 만들기는 맡겨도 생각만은 넘기지 말라는 거죠.

무슨 이야기인가요?

요즘은 프롬프트 한 줄이면 결과물이 뚝딱 나옵니다. 만들기가 쉬워진 만큼, Fadell은 오히려 눈에 띄는 건 깊이 고민한 것들뿐이라고 말합니다. 기계를 쓰되 판단까지 기계에 넘기지는 말라는 겁니다. 사람이 가운데서 빠지면 안 된다는 거죠.

그래서 안목이 더 중요해진다고 봅니다. 세상에 없던 1.0 제품을 만들 때는 참고할 데이터가 없어서 누군가는 자기 안목으로 결정을 내려야 합니다. Fadell은 이걸 데이터 기반이 아니라 의견 기반 결정이라 부르고, 그 결정을 내리는 소수를 안목 있는 사람(taste maker)이라 불러요. 아이폰에 물리 키보드를 넣을지 말지를 두고도 데이터는 어느 쪽도 분명히 가리키지 못했고, 마지막엔 스티브 잡스가 방향을 정했다는 거예요. AI가 기능을 거저 붙여주는 지금은, 무엇을 만들고 무엇을 뺄지 정하는 안목이 더 중요해진다는 게 그의 생각입니다.

무엇을 만들지는 어떻게 정하나요?

Fadell은 늘 고통에서 출발한다고 합니다. 사람들이 지금 겪는, 또는 곧 겪을 불편을 먼저 보고, 그걸 이제야 풀 수 있게 해준 새 기술이 나왔는지를 묻는 식이죠. 둘이 만나는 자리에서 새 제품이 나온다고 봅니다.

네스트가 그랬습니다. 온도조절기 인터페이스는 다들 싫어했고 난방·냉방이 전기요금의 절반을 차지하는데, 마침 패턴을 학습하는 AI가 그 불편을 풀 수 있게 됐어요. 그래서 249달러짜리 기기가 연 800~1,200달러를 아껴준다는 계산으로 밀어붙였습니다. 아이폰도 멀티터치, 와이파이, 빨라진 프로세서가 한꺼번에 도착한 순간에 나왔고요. 지금은 그 새 기술 자리에 AI가 들어옵니다. 내가 풀려는 오랜 불편이 무엇이고, 그걸 이제야 풀 수 있게 해준 게 정말 AI인지 따져보라는 이야기로 읽힙니다.

하나 더, Fadell은 제품을 한 조각이 아니라 시스템으로 보라고 합니다. 우리가 기억하는 건 아이팟이지만 실제로 시장을 연 건 아이팟에 아이튠즈, 뮤직 스토어까지 붙은 한 묶음이었고, 아이폰도 앱스토어가 있어서 아이폰이 됐다는 거예요.

그럼 AI는 어떻게 쓰나요?

Fadell이 든 사례가 인상적입니다. 어떤 제품은 코드를 거의 다 AI가 짰는데, 실력 있는 엔지니어가 그 코드를 보고 기겁했다고 해요. 너무 얽혀 있고 읽기 어려워서 손대기 무서운 상태였다는 겁니다. AI가 짠 코드가 당장 돌아가고 테스트를 통과해도 안전한지, 나중에 고칠 수 있는지, 문제가 생기면 되돌릴 수 있는지는 또 다른 문제라는 거죠. 당장은 빨라 보여도 빚으로 쌓이는, 이른바 기술 부채입니다.

이건 코드만의 이야기가 아닙니다. 프롬프트 한 줄로 1.0은 만들 수 있어도, 그 뒤를 받쳐줄 설계나 마케팅, 영업 없이 5.0, 6.0까지 끌고 가긴 어렵다는 거예요. 그래서 Fadell은 AI를 이렇게 쓰라고 합니다. 프로토타입을 잔뜩 만들어 내 감을 다듬는 데 쓰고, 큰 구조는 내가 잡아서 고정한 다음, 좁게 쪼갠 부분만 AI에 맡기라는 거죠. 결정은 사람이 쥐고 있어야 한다는 말입니다.

마케팅을 보는 시각도 비슷합니다. Fadell은 프로젝트를 시작하기 전에 출시 보도자료부터 써보라고 합니다. 보도자료에는 핵심 기능을 서너 개밖에 못 담는데, 그 이상은 고객에게 횡설수설로 들리기 때문이에요. 이 제약이 거꾸로 제품을 다잡습니다. 기능을 다섯 개 더 붙인다고 더 팔리는 게 아니고, 핵심 셋 중 둘을 빼버리면 팔 이유가 사라지니까요. AI가 기능을 얼마든지 붙여주는 지금은, 무엇을 남기고 무엇을 버릴지 골라내는 이 작업이 오히려 더 중요해집니다.

그가 좋은 예로 든 건 Flighty라는 항공 앱이에요. 이미 나와 있는 Flighty를 보고 흉내 내는 건 AI로도 할 수 있겠지만, 처음의 그 1.0은 안목으로 하나하나 결정해 빚어낸 거라 AI가 흉내 낼 본보기 자체가 없다고 봅니다. 그러니 지금 내가 만드는 게 처음 선보이는 1.0인지, 이미 있는 걸 다듬는 다음 버전인지부터 보라는 거죠. 1.0의 안목은 내가 쥐고, 반복되는 뒷부분을 AI에 맡기는 식입니다.

덧붙여, 한 번에 완성되는 건 없다고도 합니다. 아이팟도 윈도우 지원과 아이튠즈 뮤직 스토어가 붙은 3세대에 와서야 자리를 잡았고, 네스트의 제품들도 몇 세대를 거쳤다고 해요. 그는 만들고, 고치고, 그다음 사업을 다듬으라고 정리합니다. 멈추지만 않으면 그건 실패가 아니라 배움이라는 말도 덧붙입니다.

적용해볼 질문

AI가 뱉어낸 결과물을 나는 이해하고 판단해서 받았나요, 아니면 돌아가니까 그냥 받아들였나요?
내가 풀려는 오랜 불편은 무엇이고, 그걸 이제야 풀 수 있게 해준 새 기술은 정말 AI인가요?
지금 만드는 건 처음 선보이는 1.0인가요, 이미 있는 걸 다듬는 다음 버전인가요?

실행해볼 수 있는 것

지금 만들거나 다듬는 것 하나를 골라, 출시 보도자료를 미리 한 장 써보기. 핵심 기능을 세 개까지만 적고, 그 세 개만으로 사람들이 살 만한지 확인해보세요.
AI에게 받은 결과물 하나를 골라, 그대로 쓰기 전에 그 구조를 내가 다시 설명할 수 있는지 점검해보기. 설명이 막히는 부분이 있으면 거기부터 다시 들여다보세요.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

지금 진짜 쓸 만한 AI 에이전트 10가지 총정리(2) : 자율 에이전트

지금 진짜 쓸 만한 AI 에이전트 10가지 총정리 시리즈
1편: 웹·코딩 에이전트 6가지
2편: 자율 에이전트 4가지 (현재 글)

지난 1편에서는 가볍게 한 번 맡겨보는 웹 에이전트와, 컴퓨터를 통째로 맡기되 파일 하나 건드릴 때마다 승인을 받는 코딩 에이전트까지 모두 여섯 가지 서비스를 봤습니다. 이번 2편에서 다룰 자율 에이전트는 그 권한 위계의 맨 윗 칸입니다. (1편을 안 보셨어도 괜찮습니다. 지금부터 짧게 짚고 가겠습니다.)

잠깐 복습하면, 이 시리즈에서 에이전트는 "LLM이 도구를 루프로 돌려 목표를 달성한다"로 정의했습니다. 그리고 서비스를 가르는 축은 네 가지였죠. 무엇을 알고(컨텍스트), 무엇으로 하고(도구), 어디까지 해도 되고(권한), 언제 시작하느냐(트리거). 이 중에서도 종류를 결정적으로 가르는 건 권한이었습니다. 권한을 한 칸씩 더 내줄수록 웹에서 코딩으로, 코딩에서 자율로 올라갑니다.

자율 에이전트는 그 맨 윗 칸입니다. 코딩 에이전트까지는 무언가 손댈 때마다 사람에게 "이거 해도 될까요?"를 물었습니다. 반면 자율 에이전트는 한 번 "여기까지는 알아서 해"라고 정해두면, 그 안에서는 묻지 않고 24시간 혼자 돕니다. 내가 자는 동안에도요. 가장 강력하고, 그래서 가장 위험한 단계입니다.

전체 10가지 중 2편에서 다루는 자율 에이전트는 네 가지입니다. 1편 끝에서 예고했으며 가장 널리 알려진 두 서비스, 자율 에이전트의 원조 격인 오픈클로(OpenClaw)와 쓸수록 똑똑해지는 헤르메스(Hermes)에 두 가지를 더했습니다. 데스크톱에서 기억을 내 컴퓨터 안에만 쌓는 오픈휴먼(OpenHuman), 그리고 구글 생태계에 깊이 붙는 제미나이 스파크(Gemini Spark)입니다.

다만 시작하기 전에 하나는 분명히 해두죠. 편리함과 위험은 같은 버튼에서 나옵니다. 권한을 넓게 열수록 알아서 잘 해주지만, 그만큼 어긋났을 때 손쓸 틈도 사라집니다. 그래서 이 단계에서 진짜 실력은 기능을 외우는 게 아니라 "어디까지 맡기고, 어디부터 막을지"를 정하는 감각입니다. 그 감을 함께 잡아보겠습니다.

자율 에이전트: 잠도 안 자고 일하는 비서

7. OpenClaw: 컴퓨터에 상주하며 잠들지 않는 비서

오픈소스 자율 에이전트 중 가장 많이 알려진 서비스입니다. 1인 개발자의 주말 프로젝트로 시작했는데 폭발적인 관심을 받았죠. 공개 두어 달 만에 빅테크가 일제히 눈독을 들였고, 결국 2026년 2월 창업자 Steinberger는 OpenAI에 합류했습니다. 다만 OpenClaw 자체는 특정 회사 소유로 넘어가지 않고, OpenAI를 후원사로 둔 독립 재단으로 이관돼 MIT 라이선스 그대로 남았습니다.

Openclaw

누가·언제·뭘로

오스트리아 개발자 Peter Steinberger가 2025년 11월 처음 공개한 오픈소스(MIT) 에이전트예요. (이름이 여러 번 바뀌어 2026년 1월 30일 지금의 OpenClaw로 확정됐습니다. 앤트로픽 측 상표 문제 때문이었죠.) 서버에 직접 설치해 쓰고, 구독료 없이 LLM 사용료만 듭니다.

어떻게 동작할까?

서버에 설치한 다음 권한을 주고, 슬랙·텔레그램·디스코드 같은 메신저에 봇으로 띄워두면 끝입니다. 평소 쓰던 메신저가 그대로 조작 화면이 되죠. 명령을 던지거나 키워드·일정을 걸어두면 알아서 처리하고 답을 줍니다(지원 채널 50개 이상). 성격을 정의하는 파일(SOUL.md)을 두는 것도 특징인데, 켜질 때마다 이 파일을 먼저 읽어 늘 같은 말투로 움직입니다. 이런 에이전트들이 모인 AI 전용 커뮤니티 'Moltbook'이 화제가 됐고, 최근 마이크로소프트도 OpenClaw를 자사 에이전트에 집어넣겠다고 발표했습니다.

이런 일에 강해요

코드 정리·자료 조사
길게 받은 내용 요약
메시지 한 줄이나 키워드로 시작되는 자동화

한 줄 추천

항상 띄워두고 손대지 않아도 도는 에이전트를 원한다면 가장 쉽게 접근할 수 있는 선택지입니다. 다만 셸 실행·파일·캘린더·이메일까지 권한이 넓은 만큼, 그 권한이 그대로 공격 통로가 됩니다. 초기엔 보안 취약점도 많이 보고됐으니, 기업 비밀이 담긴 컴퓨터는 피하고 권한은 좁게 시작해 하나씩 넓혀가세요.

8. Hermes Agent: 쓸수록 똑똑해진다

나온 지 석 달 만에 자율 에이전트 사용량 선두로 올라선 신예입니다.

Hermes Agent

누가·언제·뭘로

Nous Research가 2026년 2월 25일 공개한 오픈소스(MIT) 에이전트예요. OpenClaw처럼 서버에 설치해 쓰고 LLM 사용료만 듭니다. 2026년 5월 10일 OpenRouter 일일 토큰 처리량에서 1위에 올라 OpenClaw를 처음 앞질렀습니다.

어떻게 동작할까?

설치한 뒤 메신저나 명령어 창으로 일을 맡기면 처리합니다. 여기까지는 OpenClaw와 비슷하죠. 차이는 학습 루프예요. 한 번 해낸 작업 절차를 파일(스킬)로 저장해 두고, 비슷한 일이 오면 그 파일을 꺼내 다시 씁니다. 쓰는 도중 절차를 스스로 다듬기도 하고, 자주 부탁하는 패턴까지 익혀가고요. 최근 데스크톱 앱으로도 출시를 마치며 영역을 넓히고 있습니다.

이런 일에 강해요

매번 똑같이 반복하는 업무 절차
오래 이어지는 긴 작업 (절차를 기억하니 중간에 끊겨도 이어감)

한 줄 추천

매번 반복하는 워크플로가 있거나, 쓸수록 손에 맞아가는 에이전트를 지금부터 길들이고 싶다면 좋은 선택지입니다. 권한을 넓게 여는 건 다른 자율 에이전트와 같으니 좁게 시작하는 게 안전하고요. (보안 취약점 보고는 OpenClaw보다 적은 편입니다.)

9. OpenHuman: 귀여운 다마고찌?

OpenHuman은 가장 최근에 등장한 자율 에이전트입니다. 2026년 5월에 나왔죠. 간단한 설치와 최적화 기능들을 앞세워, 깃허브 트렌드, 프로덕트 헌트에서 모두 1위를 차지했습니다.

OpenHuman

누가·언제·뭘로

TinyHumans AI가 만든 오픈소스(GPL-3.0) 에이전트예요. 2026년 5월에 공개되며 그 주에 깃허브 트렌딩 정상에 올랐습니다. 데스크톱 앱으로 받아 쓰고, 로컬 모델을 쓰면 클라우드 없이도 돌릴 수 있어요. (OpenClaw 구조를 토대로 만들어졌습니다.)

어떻게 동작할까? 데스크톱 앱에서 볼 폴더와 연결할 계정(OAuth)을 직접 지정합니다. 도구 하나하나가 아니라 계정 단위(Gmail·Notion·GitHub·Slack 등 118개 이상)로 붙여 맥락을 끌어모으는 게 특징이에요. 연결해두면 20분마다 자동으로 데이터를 가져와 압축하고, 내 컴퓨터 안 저장소에만 기억으로 쌓습니다. 이 '학습'의 방향이 Hermes와 다른데, Hermes가 일을 더 잘하는 법(스킬)을 익힌다면 OpenHuman은 나를 더 잘 아는 쪽(기억)으로 진화합니다. 기억에서 바로 답할 수 있는 건 외부 모델을 부르지 않아 토큰도 아끼고요(제작사는 최대 80% 절감을 내세우지만 실측 리뷰에선 70% 안팎). 쌓인 기억은 마크다운 파일이라 직접 열어 읽고 고칠 수도 있습니다.

이런 일에 강해요

내 메일·문서·일정을 미리 파악한 상태에서 시작하는 작업
같은 맥락을 매번 다시 설명하기 귀찮은 반복 업무
데이터를 밖으로 내보내고 싶지 않을 때

한 줄 추천

기능도 많지만 눈에 띄는 건 모니터에 머무는 귀여운 마스코트입니다. 화상 회의(구글 미트)에 참가자로 들어오기도 하고요. 마스코트와 대화하며 가볍게 에이전트를 키워보고 싶다면 괜찮습니다. 데이터를 로컬에만 두고 토큰도 암호화해 보관하지만, 여러 계정을 한꺼번에 묶는 만큼 연결 범위는 신중히 정하세요. 아직 외부 보안 감사를 받기 전이고, 막 나온 제품이라는 점도 감안하고요.

10. Gemini Spark: 구글 워크스페이스 속 자율 에이전트

동작 원리는 자율 에이전트랑 비슷한데, Google Workspace 안에서만 도는 특징을 가진, 변형 에이전트입니다.

Gemini Spark

누가·언제·뭘로

2026년 5월 19일 구글 I/O에서 공개됐고, 아직 베타 단계로 정식 출시 전입니다(미국 AI Ultra 구독자 대상). Gemini 3.5와 1편에서 본 Antigravity를 기반으로 합니다.

어떻게 동작할까?

클라우드에서 돌기 때문에 노트북을 닫아둬도 움직입니다. 전용 Gmail 주소로 동료에게 메일 보내듯 일을 시키면, Gmail·Docs 같은 워크스페이스는 물론 크롬으로 웹까지 살펴 처리하고 보고합니다. MCP로 외부 서비스도 붙일 수 있고요. 다만 단계마다 사용자 승인을 받는 구조라, 완전 무인이라기보다 '지켜보는 자율'에 가깝습니다.

한 줄 추천

구글 워크스페이스를 일상적으로 쓴다면 가장 손이 덜 가는 자율 에이전트가 될 수 있습니다. 클라우드·검색·저장소를 다 가진 구글 위에서 도는 만큼, Antigravity나 Gemini가 발전할수록 그 성과를 그대로 흡수할 가능성도 큽니다. 이렇게 특정 공간을 중심으로 돌며 안전장치를 갖춘 자율 에이전트는 더 지켜볼 만합니다.

그래서 뭐부터 써볼까요? 웹·코딩·자율 3단계

사실, 지금까지 소개한 에이전트 열 개를 다 써볼 필요는 없습니다. 그 대신 처음부터 자율 에이전트로 바로 점프하는 건 권하지 않습니다. 그만큼 위험한 권한을 손에 쥐거든요. 그래서 앞에서 본 순서(웹→코딩→자율)를 그대로 사다리 삼아 한 칸씩 올라가는 걸 권합니다. 한 칸 오를 때마다 에이전트한테 내주는 권한이 늘어나죠.

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

1단계: 웹으로 동작부터 구경

서비스가 정해둔 도구 안에서 에이전트가 어떻게 도는지 구경할 수 있습니다. 프롬프트 하나만 던지면 되니까 부담이 거의 없죠. 자료 조사나 시장 리서치처럼 평소 시간 잡아먹던 작업을 한번 통째로 맡겨보세요. 지금 당장 시작하고 싶으면 Genspark, Manus가 가장 안정적입니다. (자세한 소개는 1편에서)

2단계: 코딩으로 직접 커스텀

여기서는 컨텍스트·도구·권한을 직접 다룹니다. 동작 하나하나에 승인을 거치니 통제권은 그대로 쥐고 가죠. 코드를 만지면 Claude Code·Codex·Antigravity 중 자기 생태계에 맞는 걸로, 안 만지면 같은 힘을 GUI로 쓰는 Cowork로 시작하면 됩니다. 작업 절차를 저장해 반복하는 '스킬(Skills)'을 써보겠다는 목표를 잡으면 에이전트의 동작 방식에 더 쉽게 다가갈 수 있습니다.

3단계: 자율로 24/7 세팅

권한을 상시로 내주는 대신 편리함을 챙길 수 있습니다. 워크플로를 학습시키려면 Hermes Agent, 여러 메신저에 상시로 띄우려면 OpenClaw, 가장 최근에 나온 자율 에이전트를 써보려면 OpenHuman을 추천합니다. 이 단계에서는 서비스의 특징보다 권한과 범위를 어디까지 열어둘지 감을 익히는 게 우선일 거라고 생각합니다.

마치며: 외우지 말고, 한 번 돌려보세요

에이전트가 시대의 흐름인 건 맞습니다. 그렇다고 뭔지도 잘 모르는 채로 OpenClaw 같은 자율 에이전트부터 덜컥 깔아두는 건 권하지 않습니다.

먼저 갖춰야 할 건 개념입니다. LLM이 도구를 루프로 돌려 목표를 달성한다는 것, 그리고 컨텍스트·도구·권한·트리거를 중심으로 서비스가 갈린다는 이해죠. 이번에 다룬 서비스도 대부분 이제 막 나온 것들이라, 열 개의 특징을 외우는 건 그다음 일입니다.

결국 어느 단계든 한 번은 직접 돌려봐야 감이 옵니다. 글로 읽은 맥락과 손으로 굴려보며 깨닫는 건 다르니까요. 에이전트가 할 수 있는 그 넓은 영역에 감이 잡히면, 그때부터 꽤 다른 세상이 열릴 겁니다. 이 글이 그 여정의 좋은 길잡이가 되면 좋겠습니다.

]]>

클로드 페이블 5, 출시 하루 만에 너무 막힌다는 반응이 쏟아졌다 + 차단 소식 업데이트

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

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

써볼 것: supermemory - AI가 대화 사이마다 기억을 잃는 문제를 메우는 오픈소스 메모리 엔진
참고할 것: Claude Fable 5 - 출시 하루 만에 너무 막힌다는 반응이 쏟아진 신규 모델
적용해볼 것: AI는 1~2년 안에 천재들의 나라가 된다는 Anthropic CEO의 정책 제안

<출처: Github, supermemoryai>

1. 써볼 것: AI가 대화 사이마다 기억을 잃는 문제를 메우는 오픈소스 메모리 엔진

supermemory는 AI에 장기 기억을 붙여주는 오픈소스 메모리·컨텍스트 엔진입니다. Dhravya Shah가 이끄는 팀이 만들고 있고, GitHub 별은 2만 6천 개를 넘었습니다. 구글과 딥마인드 임원이 참여한 시드 투자를 받은 곳이기도 하고요. 핵심은 AI가 대화가 끝나면 다 잊어버리는 한계를 메우는 데 있습니다. 대화에서 사실을 자동으로 뽑아 사용자 프로필을 만들고, 바뀐 정보는 갱신하고 지난 정보는 알아서 지웁니다.

<출처: techcrunch>

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

AI를 본격적으로 쓰는 사람이라면 한 번쯤 겪어봤을 거예요. 짧은 작업은 빠르고 편한데, 새 대화창을 열면 어제 알려준 맥락을 처음부터 다시 설명해야 합니다. AI는 세션이 바뀌면 이전 대화를 기억하지 못하니까요.

supermemory는 이 기억을 대신 맡아 둡니다. 예를 들어 서울에 산다고 알고 있던 사람이 부산으로 이사했다고 하면, 이전 정보를 새 정보로 바꿔 기억합니다. 내일 시험이 있다 같은 임시 사실은 날짜가 지나면 알아서 지우고요. 모순되는 정보가 들어오면 자동으로 정리하고요. 기존에는 이런 걸 직접 만들려면 벡터 DB를 세팅하고 임베딩 파이프라인과 청킹 전략까지 짜야 했는데, supermemory는 그걸 하나의 API 뒤로 숨깁니다.

어떻게 쓰나요?

크게 세 가지 방법이 있습니다.

코드 없이: MCP 서버나 플러그인을 설치하면 Claude Code, Cursor, VS Code 같은 도구에 기억이 붙습니다. 코드 없이 단독으로 쓰는 앱과 브라우저 확장도 따로 있고요. 저장·삭제(memory)와 검색(recall)은 AI가 알아서 호출하고, 프로필 주입(context)은 /context로 부릅니다.
개발자라면: npm이나 pip로 설치해 add()로 대화를 저장하고, profile()로 사용자 프로필과 관련 기억을 한 번에 받아옵니다. RAG와 메모리를 한 쿼리로 합친 Hybrid Search도 기본으로 동작합니다.
직접 돌리고 싶다면: 단일 바이너리로 설치하면 설정 없이 localhost:6767에서 동작합니다. Ollama를 붙이면 데이터가 기기 밖으로 나가지 않는 완전 오프라인으로도 쓸 수 있습니다.

구글 드라이브, 지메일, 노션, 원드라이브, 깃허브를 실시간으로 동기화하는 커넥터, PDF·이미지·영상·코드를 올리면 알아서 처리하는 추출기도 들어 있습니다. Vercel AI SDK, LangChain, LangGraph, n8n 같은 프레임워크용 래퍼도 있어서 쓰던 스택에 끼워 넣기 쉽습니다.

이렇게 어디든 붙을 수 있는 건 supermemory가 기억을 모델에서 떼어내 별도 층으로 두기 때문입니다. 그래서 모델을 바꿔도 그동안 쌓인 맥락은 그대로 남고, 어떤 모델을 쓰든 기억은 내 쪽에 둘 수 있습니다.

성능에 대해서는, supermemory가 LongMemEval, LoCoMo, ConvoMem 같은 AI 메모리 벤치마크에서 자사 기준 최상위라고 밝힙니다. 다만 점수는 발표마다 다릅니다. README는 LongMemEval 81.6%, 창업자는 약 85%, 실험적 셋업으로는 약 99%를 들기도 했는데 본인이 이건 프로덕션이 아니라고 단서를 달았습니다. 특정 숫자를 그대로 믿기보다 메모리 쪽에서 앞선다고 자체 평가한다 정도로 보면 됩니다.

누구에게 좋을까요?

AI 앱이나 에이전트에 기억·RAG·사용자 프로필을 붙이고 싶은 개발자
메모리 시스템을 직접 만들고 굴리는 부담까지는 지고 싶지 않은 1인·소규모 팀
자기 AI 비서가 매번 까먹는 게 불편했던 사람
보안상 데이터를 밖으로 내보내기 어려운 경우. 셀프호스트와 오프라인 옵션이 있는데, 오프라인은 로컬 모델을 써야 해서 성능은 감안해야 합니다

<출처: Claude 캡처>

2. 참고할 것: 출시 하루 만에 너무 막힌다는 반응이 쏟아진 신규 모델

[업데이트 · 2026.06.12]

이 글에서 소개한 Fable 5에 대한 접근이 전면중단됐습니다.

무슨 일: 미국 정부가 국가안보 권한을 근거로 수출통제 지시를 발령했고, 앤트로픽은 6월 12일 오후 5시 21분(미 동부시간) 지시를 받은 직후 두 모델의 모든 접근을 중단했습니다. 미국 내·외, 미국 시민·외국인 직원 구분 없이 적용됩니다.
이유: 정부는 “Fable 5의 보안 우회(jailbreak) 기법이 발견됐다”는 점을 들었습니다. 앤트로픽이 검토한 우회는 모델에게 특정 코드베이스를 읽혀 소프트웨어 결함을 찾게 하는 좁은 범위의 비(非)보편적 기법으로, GPT-5.5 등 다른 모델에서도 흔히 가능한 수준이라고 반박했습니다.
다른 모델은? Opus 4.8, Sonnet, Haiku 등 나머지 앤트로픽 모델은 정상적으로 이용할 수 있습니다. 현재로선 사실상 오푸스 4.8이 유일한 선택지가 됐습니다.
앞으로: 앤트로픽은 “가능한 빨리 접근을 복구하기 위해 노력 중”이라고 밝혔으나 구체적 복구 일정이나 환불 언급은 없습니다.

출처: 앤트로픽 공식 성명 “Statement on the US government directive to suspend access to Fable 5 and Mythos 5”, 2026.06.12)

Claude Fable 5는 Anthropic(앤트로픽)이 6월 9일 공개한 신규 모델로, 사이버보안에 강한 미토스와 같은 모델에 안전장치를 더한 공개 버전입니다. 그동안 너무 강력해서 제한적으로만 풀던 미토스급 모델을 공개로 처음 써볼 수 있게 됐다는 소식이라, 출시 직후 X와 Reddit, 해커뉴스 같은 여러 커뮤니티에서 관심이 크게 쏠렸습니다. TechCrunch가 따로 다룰 만큼 반응이 뜨거웠고요. 그런데 그 상당수가 칭찬이 아니라, 안전장치가 너무 빡빡해서 평범한 작업까지 막힌다는 불만이었습니다.

<출처: techcrunch>

어떻게 작동하나요?

가드레일이 걸리면 Fable은 대화를 멈추고 사이버보안 또는 생물학 주제로 플래그됐다고 안내한 뒤 Claude Opus 4.8로 폴백합니다. 악성코드 제작이나 생물·화학 무기 같은 위험을 막으려는 장치입니다. 앤트로픽은 이 안전장치가 평균적으로 세션의 5% 미만에서 작동하고, 더 강한 모델이 나오는 동안 오탐을 줄이려 작업 중이라고 밝혔습니다.

어떤 반응이 나왔나요?

가장 많은 불만은 오탐입니다. IBM X-Force의 보안 연구자 Valentina "Chompie" Palmiotti는 블로그 글을 읽는 것 같은 무해한 작업까지 사이버 관련으로 막힌다고 했습니다. Tolmo의 Matt Suiche는 안전한 코드를 짜달라고 하면 소프트웨어 엔지니어링이 아니라 사이버보안 작업으로 간주돼 다운그레이드된다며, 키워드·어휘 기반으로 보인다고 했고요.

해커뉴스에는 더 다양한 사례가 올라왔습니다. 도커 앱 로그 트러블슈팅, 자기 코드베이스의 인증·크리덴셜 코드 점검, PyTorch 같은 평범한 ML 작업, 홈 자동화 로그, 의료 내용이 든 CSV 파싱, 리버스 엔지니어링까지 막혀 계속 Opus 4.8로 내려갔다는 얘기가 이어졌습니다. 핵·생물·화학처럼 민감한 주제로 일부러 찔러보며 무엇이 막히는지 테스트한 사례도 있었고, 인구 통계나 궤도 역학 같은 학술 질문까지 걸렸다는 보고도 있었습니다.

두 번째는 다운그레이드 방식입니다. 가드레일이 걸리면 Fable은 더 낮은 모델인 Opus 4.8로 내려가는데, 사이버·생물 쪽에서는 모델이 바뀌었다는 걸 사용자에게 알려줍니다. 다만 모델 카드에 따르면, 모델을 베껴 경쟁 모델을 만들려는 시도에는 모델을 바꾸지 않고 알리지도 않은 채 성능만 떨어뜨린다고 합니다. 이를 두고 해커뉴스 스레드에서 일부 사용자는 몰래 결과를 망치는 것 아니냐고 우려했는데, 그렇게까지 단정할 근거는 없다는 반박도 함께 달렸죠. 또 성능이 낮은 모델로 내려갔는데도 원래 가격을 그대로 내야 하는 건 아닌지 궁금해하는 사람도 있었습니다.

세 번째는 데이터 보존입니다. 앤트로픽은 6월 9일부터 Fable을 포함한 미토스급 모델에 주고받은 프롬프트와 답변을 30일간 보관하기로 했습니다. 일반 소비자 요금제(Free·Pro·Max)는 원래 안전 목적으로 데이터를 보관해와서 달라지는 게 없고, 새로 영향을 받는 건 그동안 데이터를 전혀 남기지 않는 조건(영점 데이터 보존, ZDR)으로 쓰던 기업입니다. AWS Bedrock, 구글 Vertex, Azure 같은 클라우드로 ZDR을 적용해 데이터를 안 남기고 쓰던 곳도, 이제 미토스급 모델을 쓰려면 30일 보관에 동의해야 합니다. 보관하는 이유로는, 요청 하나만 보면 멀쩡한데 같은 요청을 조금씩 바꿔 수백 번 던지는 식으로 여러 번에 걸쳐야 드러나는 오용이 있어서, 요청을 모아 함께 봐야 잡을 수 있기 때문이라고 설명합니다. 보호장치로는 심각한 위험으로 플래그되거나 고객이 직접 요청한 경우에만 승인된 소수의 검토자가 열람할 수 있고, 누가 언제 봤는지는 지울 수 없는 기록으로 남으며, 30일이 지나면 자동 삭제된다고 합니다.

하지만 이 정책을 두고 나온 반응은 곱지 않았습니다. 에이전트 코딩 도구를 쓰면 코드베이스 전체가 모델 제공사로 넘어가는데, ZDR 계약을 믿고 쓰던 기업은 곤란해진다는 거예요. The Verge 보도에 따르면 마이크로소프트는 Fable 5를 고객용 GitHub Copilot에는 넣으면서도 직원들이 쓰는 사내 GitHub Copilot 모델 목록에는 넣지 않았습니다. 데이터 보존 조건 때문이고, 다른 Claude 모델은 ZDR이 적용돼 사내에서 계속 쓸 수 있습니다. 같은 보도에 따르면, 보통 데이터는 30일 뒤 지워지지만 사용 정책을 위반한 것으로 걸러진 요청은 최대 2년까지 보관될 수 있습니다. 여기에 GDPR·NDA 관련 우려, IPO 직전에 굳이 이러느냐는 냉소도 나왔고요.

네 번째는 효과 자체에 대한 회의론입니다. 키워드 기반이다 보니 작정한 공격자는 표현을 바꿔 빠져나가고 정작 정상 연구자만 막힌다는 비판입니다. 실제로 이런 식으로 우회를 시도하는 사용자도 관찰됐고, 일부 악성코드가 오히려 민감 키워드를 일부러 끼워 넣어 AI 검사 도구를 무력화하려 한다는 보안 업계 보도도 있었습니다. 이건 사용자를 지키는 가드레일이 아니라 앤트로픽을 지키는 장치라는 냉소도 보였습니다.

옹호하는 목소리도 있었습니다. 앞서 키워드 기반이라고 지적한 Suiche도, 초기 단계라 이해할 수 있고 시간이 지나면 완화될 거라고 덧붙였습니다. HN에도 실험적 고성능 모델이니 초기엔 과하게 막는 편이 낫다, 대안이 더 위험하다는 의견이 있었고요. 승인된 사이버 전문가에게 제한을 덜 거는 Cyber Verification Program도 있는데, 개인으로 신청해 통과했다는 사례와 공개 취약점(CVE) 이력이 있는데도 거절됐다는 사례가 엇갈렸습니다. OpenAI(오픈AI)에도 Trusted Access for Cyber라는 비슷한 프로그램이 있습니다.

무엇을 얻어가야 하나요?

이번 일이 보여주는 건, 모델이 강해질수록 그걸 고르는 기준도 달라진다는 점입니다. 예전엔 성능과 벤치마크가 거의 전부였다면, 이제는 안전장치가 내 작업을 막지는 않는지, 데이터 보존 조건이 회사 규정과 맞는지까지 함께 따져야 합니다. 마이크로소프트가 고객에게는 Fable 5를 팔면서 사내에서는 쓰지 않은 게 이걸 단적으로 보여주죠.

그리고 이 마찰은 한 번 고치면 끝나는 버그가 아닐 가능성이 큽니다. 모델을 강력하게 만드는 능력이 곧 위험을 키우는 능력이라, 다음에 더 센 모델이 나와도 가드레일이든 데이터 보존이든 비슷한 제약이 반복될 공산이 크고요. 앤트로픽이 오탐을 줄이겠다고 했으니 지금 상태가 고정은 아니지만, 이 줄다리기 자체는 쉽게 사라지지 않을 겁니다. 그래서 실무적으로는, 작업을 모델 하나에 다 묶어두기보다 용도별로 나누고 갈아끼울 수 있게 해두는 게 점점 중요해질 것 같습니다.

<출처: darioamodei.com>

3. 적용해볼 것: 1~2년이면 AI가 차원이 달라진다는 Anthropic CEO의 정책 제안

Anthropic(앤트로픽) CEO Dario Amodei가 6월 10일 Policy on the AI Exponential(AI 기하급수에 대한 정책)이라는 글을 올렸습니다. Fable 5 출시 바로 다음 날 나왔고, 모델 테스트 의무화를 담은 입법 제안과 일자리 대응 프레임워크를 함께 내놔서 화제가 됐는데요. VentureBeat, Decrypt 등 여러 매체가 비중 있게 다뤘습니다. AI는 시간이 갈수록 더 빠르게 발전하는데 정책은 그 속도를 못 따라간다는 게 출발점이고, 강한 모델을 비행기처럼 출시 전에 검증받게 하자는 게 핵심 주장입니다.

어떤 주장인가요?

Amodei는 입법이 너무 느리다고 봅니다. 의회가 한 번 움직이는 사이에 AI는 신기한 장난감 수준에서 훨씬 강력한 단계로 건너뛸 수 있다는 거예요. 그는 이 단계를 데이터센터 속 천재들의 나라, 즉 수많은 천재가 데이터센터 안에서 한꺼번에 일하는 것과 같은 수준이라고 부릅니다. 컴퓨팅 자원을 키울수록 성능이 따라 오르는 지금의 흐름(스케일링 법칙)이 1~2년만 더 이어지면 거기에 도달한다는 거고요.

그래서 회사가 안전 점검 내용을 공개하게 하는 정도로는 부족하다며, 일정 규모 이상의 컴퓨팅 자원을 들인 최신 모델은 비행기가 운항 전 안전 검사를 통과하듯 출시 전에 제3자 검증을 받게 하자고 제안합니다. 검증 항목은 사이버 공격, 생물무기, AI 통제 상실, 그리고 이런 위험을 더 키울 수 있는 AI의 자동 연구 네 가지인데, 여기서 기준에 못 미치면 정부가 출시를 막을 수 있게 하자는 내용입니다.

일자리 문제도 비중 있게 다룹니다. AI로 인한 일자리 감소는 바람직하지 않고 막아야 한다는 입장에서, 임금 보험이나 고용 유지 세제, 재교육 지원 같은 완충책을 제시하고 장기적으로는 기본소득까지 언급합니다. 동시에 그는 한 사람이 10억 달러 규모 회사를 만들고 몇 명짜리 팀이 수억 달러 매출을 내는 일이 이미 벌어지고 있다고도 말합니다.

어떻게 받아들여지나요?

물론 반발도 있습니다. 비판하는 쪽이 먼저 짚은 건 시점입니다. Fable 5를 내놓은 바로 다음 날, 상장(IPO)을 앞둔 회사의 CEO가 강력한 모델은 정부가 출시를 막을 수 있게 하자고 제안했기 때문이죠. 내용을 두고도 말이 나옵니다. 전 마이크로소프트 윈도우 부문 사장이자 지금은 벤처 투자사 a16z 보드 파트너인 Steven Sinofsky 등은 이를 규제 포획이라고 봤습니다. 새 검증 의무가 그걸 감당할 여력이 있는 큰 회사에만 유리하고, 여력이 없는 작은 회사는 밀려나게 만든다는 뜻입니다. 게다가 어디까지 큰 모델에 적용되는 규칙인지 기준이 빠져 모호하다는 지적도 있습니다.

같은 주에 앤트로픽이 한 일들을 나란히 놓으면 이 비판이 왜 나오는지 보입니다. 에세이에서는 강력한 모델을 정부가 검증하고, 못 미더우면 출시를 막게 하자고 말하죠. 그런데 같은 시기에 내놓은 Fable 5는 스스로 가드레일을 빡빡하게 걸고 데이터 보존도 강화했습니다. 누군가는 앤트로픽의 말과 행동이 일치한다며 지지합니다. 반대로 비판하는 쪽은 이미 자기 회사에 맞춰 둔 방식을 업계 전체의 규칙으로 굳히려는 것 아니냐고 봅니다.

생각해볼 질문

정책 제안 자체는 우리가 좌우할 수 없지만, 그가 깔아둔 전제는 생각해 볼 만한 질문이라 생각합니다.

1~2년 안에 AI가 지금보다 훨씬 강력해진다면, 지금 내가 시간을 들여 쌓는 것 중에 그때 가치가 줄어들 건 무엇이고, 오히려 더 중요해질 건 무엇인가요?
한 사람이나 작은 팀도 큰 제품을 만들 수 있다는데, 나는 그 레버리지를 지금 어디에 쓰고 있나요?
내 작업이나 제품이 특정 모델 한 곳에 얼마나 묶여 있나요? 그게 막히거나 조건이 바뀌면 무슨 일이 생기나요?

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

GEO 성과 측정 실전편: 인용률 트래킹과 AI 크롤러 로그 활용법

양용준 서치나인 대표 | GEO 팩트체크 세미나 '실제 사례로 살펴보는 GEO 오해와 진실' 두 번째 강연

이 글은 5월 21일 열린GEO 팩트체크 세미나에서 나온 양용준 서치나인 대표의 발표 내용을 1인칭 시점으로 정리한 글입니다. 앞서 공개한 세미나 사전 가이드가 “GEO 성과를 왜 최종 KPI가 아니라 전조 지표로 봐야 하는가”를 다뤘다면, 이 글은 실제 발표에서 소개된 프롬프트 구성 방식, 인용률 주 단위 트래킹, AI 크롤러 로그, Client ID/User ID 기반 전환 추적의 한계를 사례 중심으로 정리합니다.

저는 이번 세미나에서 'GEO 성과 측정을 어떻게 접근할까'라는 주제를 맡게 된 양용준이라고 합니다. 서치나인에서 1인 SEO/GEO 컨설턴트로 활동하고 있고요.

저는 SEO 하시는 분들께 '물음표 살인마'라는 소리를 들을 정도로 질문을 꽤 많이 하는 편입니다. 제가 납득이 돼야 작업을 할 수 있는 성격인 만큼, 계속 질문을 던지면서 검증해온 방법들을 오늘 말씀드리고자 합니다.

먼저 분명히 해두고 싶은 게 있는데요. 만약 '정답을 찾으러 왔다'고 하시면, 이 세션은 전혀 적합하지 않다고 생각합니다. 다만 어떤 방식으로 접근하고, 테스트하고, 성과를 측정하는지 그 '과정'을 보고 싶으시다면, 이 세션이 조금 괜찮은 인사이트가 되지 않을까 생각합니다.

어차피 우리는 지금 기준으로 일부 성과만 볼 수 있다고 보고 있고, 최종 KPI를 설정해도 결국 그게 정확하지 않다면, 저는 최종 지표보다는 오히려 그것의 '전조 증상'이 되는 신호들을 성과로 보자, 라고 현재까지 1차적으로 결론을 내렸습니다.

기본 프롬프트는 어떻게 구성했나

가시성 검증과 관련해 가장 많이 받는 질문 중 하나가 '기본 프롬프트는 어떻게 구성했느냐'인데요.

저는 잘 구성되어 있는 사이트의 Sitemap.xml만 봐도 그 홈페이지의 성격을 잘 파악할 수 있다고 봅니다. 그래서 Sitemap.xml과 클릭과 노출이 높은 페이지를 조합하고, 기존 SEO 기법에 있던 키워드 클러스터링과 클렌징한(허수를 덜어낸) 검색 볼륨을 기준으로 삼아 프롬프트를 짰습니다.

이렇게 짠 이유는, 프롬프트가 기본적으로 고객의 의도를 기반으로 한다고 생각하기 때문입니다. 단순한 키워드 검색이 이제는 구체적인 롱테일 형태의 프롬프트로 변화하는 추세입니다. 그래서 우리 홈페이지에서 지금 콘텐츠를 작성하거나 서비스를 운영하는 데 적합한 것을 골라내려면, 이런 식으로 조합하는 게 제 기준에서 가장 적합하다고 생각했습니다.

그렇게 조합하면 '가시성이 바로 올라가는 거 아니냐'라는 의문이 들 수 있는데요. 이 방식으로 진행했을 때, 생각보다 가시성이 처음부터 높게 나오는 경우는 많이 없었습니다. 오히려 이 과정을 통해서 기존의 글을 어떻게 리라이팅할지, 우리가 놓치고 있던 주제는 무엇인지, 상세페이지를 어떻게 수정해야 AI에게 충분히 인용될 가치가 있는 콘텐츠가 될 수 있는지 그 기준을 뽑아낼 수 있었다는 데 의의가 있다고 판단했습니다.

인용율을 KPI로 잡기

'내 사이트가 인용이 많이 되면 가시성이 올라갈 확률이 높을까?'라는 질문에 대해, 저는 프롬프트와 산업에 따라 다르다고 생각합니다.

구글에서는 인용이 많이 되면 가시성이 올라갈 확률이 높았고, 라이너에서도 마찬가지였습니다. 저는 답변이 어떻게 나왔는지를 보기보다 그 답변을 만들어내는 '과정'에서 어떤 출처를 어떻게 추출했는지를 보는데요. 외부 인용도 좋지만, 특정 채널을 제외하면 '어떤 도메인이 특별히 더 좋다'고 단정하기는 어렵고, 자사 사이트가 인용이 되면 가시성이 높아질 확률은 올라간다고 봤습니다.

다만 GPT에서는 인용이 된다고 해서 내 브랜드가 추천되지 않는 경우도 많았고, 오히려 다른 브랜드에 인용 효과만 주게 되는 케이스도 많았습니다.

실제로 동탄 피부과 케이스를 모아봤는데요. ‘리베리 의원’을 보시면 추천이 되는 경우도 있고, 두 번째 화면처럼 인용 출처로만 표시되는 경우도 있었습니다. 하지만 아예 소스로 인용되지 않으면 노출될 확률이 낮다고 생각합니다. 그래서 인용률을 올리는 것 자체는 간접적인 신호가 된다, 충분히 의미가 있다고 봤습니다.

단, 인용률을 완벽한 KPI로 보기는 어렵다고 생각합니다. AI는 답변의 신뢰도를 높이기 위해 외부 데이터를 실시간으로 찾아오는 RAG(검색 증강 생성) 방식을 사용하며, 이렇게 찾은 여러 근거 자료에 기반해 답변을 만들어내는 '그라운딩' 과정을 거칩니다. 즉, 우리 사이트 하나만 보는 것이 아니라 여러 페이지의 정보를 조합하여 최종 답을 내놓기 때문에, 우리의 의도와 무관하게 다른 페이지의 정보가 인용 출처로 잡힐 확률을 통제하기 어렵습니다. 실제로 홈페이지 인용이 아무리 많이 됐다고 해도, 산업에 따라서는 AI가 홈페이지보다 구글 비즈니스 프로필 데이터를 더 선호할 수도 있고 혹은 머천다이즈 센터에 대한 데이터를 더 좋아할 수도 있습니다.

주 단위 인용률 트래킹

화면에 보이는 건 제가 사용하고 있는 체인시프트 GEO 툴인데요. '사이트가 실제로 인용이 많이 되면 가시성이 올라갈 확률이 높아지는가'를 주 단위로 체크해봤습니다. ‘리베리 의원’을 주목해서 봐주시고요. 구글 검색창에 시크릿 모드로 ‘동탄 울쎄라’ 가격이나 ‘동탄 리주란 가격’이라고 검색해보시면 AI로 작성한 수십 개의 페이지가 상위노출 되어 있는 것을 보실 수 있습니다.

‘리베리의원’이라는 브랜드를 보시면, 4월 5일에서 4월 11일 기준으로는 가시성이 없었고, 4월 26일~5월 2일 데이터에서는 8.9%로 올랐습니다. 그리고 5월 3일~5월 9일에는 21% 가까이 올랐죠. 마지막으로 5월 10~5월 16일에는 18.1%로 다시 내려갔습니다. 그 말인즉 AI로 다량 작성한 콘텐츠가 단기간의 인용이나 가시성에 도움을 줄 수 있지만 장기적으로 구글이나 LLM이 적합하지 않다고 판단하면 인용이 높아도 AI 가시성은 낮아질 수 있습니다.

한편 에미뜨 의원의 5월 3일~5월 9일, 5월 10일~5월 16일 인용횟수를 봤는데, 10위권에 있던 사이트가 일주일 기준으로 8위까지 올라갔죠. 그 기간 동안 콘텐츠를 통해 인용율을 높이는 작업을 한 건데요. 인용율이 올라갔을 때 가시성이 올라간다는 걸 알 수 있는 간접적인 신호로 볼 수 있지 않을까 생각했습니다. 다만 이건 GPT 기준이고, AIO나 AI 모드 에서는 어떤 작업을 우선순위로 잡을 것인가에 대한 판단이 또 필요하다고 생각합니다.

여러분들도 아시겠지만, GPT는 영문 도메인의 인용이 높게 나오고, 구글 비즈니스 프로필 의존도가 상당히 높습니다. 반대로 AIO나 AI 모드는 비즈니스 프로필·유튜브, 머천다이즈 센터 데이터를 잘 가져오고 있으나 영문 도메인을 더 많이 가져온다란 느낌은 없죠. 그래서 어떤 LLM이냐, 어떤 산업 분야냐에 따라 테스트해야 할 것들이 달라지는데요. 저는 당장 어떤 LLM을 목표로 잡아 우선순위로 둘 것이냐를 판단하는 데 이런 툴을 사용하고 있습니다.

AI 크롤러의 유입주기를 KPI로 잡기

그럼에도 ‘외부 트래킹 툴을 항상 믿어도 될까’라는 고민이 있습니다.

GEO 이전에, SEO에도 여러 툴이 있었죠. 경험상 저는 SEO 에이전시 일하면서 Semrush 같은 SEO 툴을 다룰 때도 지표가 과장되는 것에 대한 불만이 많았습니다. 동일한 SEO 툴에서도 DA나 평균 트래픽 등이 다 달랐습니다. 결국 툴이란 건 방향을 잡기에는 도움이 되지만, 정확한 KPI를 설정하는 데는 내 사이트에 고객이 실제로 잘 들어오는지를 확인하는 게 필요하다고 생각했습니다.

그래서 실제로 AI 크롤러의 유입을 살펴본 건데요. 최근에 약 2~3주 가까이 트래킹을 해봤습니다. LLMs.txt도 넣지 않고, AI가 좋아하는 콘텐츠의 방향이란 것도 적용하지 않았습니다. 그럼에도 크롤러가 나쁘지 않은 수준으로 유입되고 있었습니다. 그래서 AI 크롤러의 유입을 전조증상 KPI로 보는 것도 의미 있다고 생각합니다.

저는 먼저 아무 작업도 하지 않았을 때를 기준으로 AI 크롤러가 얼마나 들어오는지를 파악해 지표로 쌓고, 그 이후에 GEO 작업을 하면 인용률, 가시성이 올라가는지 등을 확인하는 게 좋은 KPI가 되지 않을까 생각합니다.

Client ID / User ID 기반 전환 추적을 KPI로 잡기

GA, AA, 앰플리튜드 같은 분석 툴은 그 자체로 데이터를 세팅해 준다기보다, 우리가 수집한 데이터를 보기 좋게 띄워주는 '대시보드'에 가깝다고 생각합니다. 그렇다면 단순히 대시보드의 화면이나 세팅을 조작하는 데 그칠 것이 아니라, 애초에 그 안으로 밀어 넣는 '데이터의 품질' 자체를 높여야 한다고 판단했습니다. 그래서 웹사이트 상에 질 좋은 데이터를 어떤 식으로 쌓을 수 있을지부터 다시 고민했고, 우리 사이트에 맞는 독자적인 데이터 레이어를 구축해 보기로 했습니다.

핵심 과제는 결국 'AI 검색을 통해 유입된 트래픽과 전환'을 이 데이터 레이어에 정확히 분리해서 담아내는 것이었습니다. 이를 추적하려면 기본적으로 Client ID(쿠키 기반)나 User ID(로그인 기반)를 활용해야 합니다. 그래서 본격적인 세팅에 앞서, 과연 AI 크롤러에게도 이 기존의 추적 방식이 동일하게 통할지 의문이 들었습니다. 그래서 이를 확인하기 위해 두 가지 사전 테스트를 진행했습니다. 먼저 AI 크롤러에게 쿠키값이 부여되는지를 봤을 때, 아닌 것으로 확인했습니다. 두 번째로 AI 크롤러가 직접 로그인을 할 수 있는지를 확인했을 때도 아닌 것으로 나타났습니다.

기존 방식(쿠키/로그인)으로는 AI 봇을 추적할 수 없다는 걸 알게 되니, '그렇다면 AI로 인한 실제 전환 기여도를 도대체 어떻게 증빙할 수 있을까?'라는 현실적인 고민에 부딪혔습니다. 그래서 우회하는 방식으로 접근하여, 가입 경로에 직접 체크를 하게 하거나 실제 상담 과정에서 AI로 인한 문의가 상승했는지를 정성적으로 확인하고자 했습니다.

실제로 클라이언트 ID를 만들어서 GA4 맞춤 보고서로 테스트를 해보며 또 다른 문제를 발견했습니다. 여러분도 개발자 도구 콘솔에서 'document.cookie'를 검색해 보시면 아시겠지만, 실제 유저가 유입될 때도 쿠키가 파편화된다는 점입니다. 사용자가 'Chat GPT 앱 내의 브라우저'를 통해 우리 사이트에 접속할 때와, 같은 기기에서 '크롬이나 사파리 앱'으로 접속할 때 찍히는 클라이언트 ID가 명확하게 달랐습니다. 각 앱마다 고유의 쿠키 저장소를 따로 쓰기 때문입니다.

데이터 모수(샘플)가 아주 방대해진다면 이를 엮어서 간접 전환을 유추해 볼 여지는 있겠지만, 데이터의 정확도와 신뢰성이 너무 떨어진다고 보았습니다. 결과적으로 봇이든 실제 유저든 '쿠키(Client ID) 기반의 추적'은 전반적으로 실패이자 한계가 명확하다는 결론을 내렸습니다.

산업군마다 차이는 있겠지만, 쿠키 추적이 불확실하다면 결국 '로그인 기반의 유저 ID(User ID)'가 현실적인 해답이 됩니다. 예를 들어 이커머스라면, 사용자가 특정 행동을 했을 때 가입을 유도하는 배너(트리거)를 띄우는 등 최대한 CRM(고객 관계 관리) 관점의 장치를 마련해야 합니다. 이렇게 일단 로그인을 시켜두면, 유저가 처음에 GPT를 통해 둘러보고 나중에 네이버나 구글로 다시 유입되어 구매하더라도 GPT의 간접 전환 기여도를 정확히 파악할 수 있기 때문입니다.

물론 여기에도 리스크는 존재합니다. GPT로 유입된 유저가 끝내 가입하지 않는다면 여전히 추적은 어렵습니다. 하지만 이 빈틈은 내부의 SXO(검색 경험 최적화)나 CRM 고도화를 통해 점진적으로 개선하며 테스트해 나갈 수 있는 영역입니다.

결론적으로, 현시점에서 단순히 기존 툴만 믿고 'AI를 통한 전환율'을 완벽하게 측정하려는 것은 불가능에 가깝습니다. 데이터의 질을 높이기 위한 우리만의 체질 개선이 먼저 선행되어야 합니다.

브랜드 키워드 유입 KPI

구글의UCP(범용 상거래 프로토콜, Universal Commerce Protocol)가 발표되고 클릭과 노출보다는 가시성과 인용이 KPI로 바뀌는 시점입니다. 이때 "왜 굳이 브랜드 키워드 유입 증가를 봐야 하느냐?"는 의문이 들 수 있습니다. 기존 SEO 환경에서는 정보성 콘텐츠만 잘 작성해도 사이트 유입을 유도하거나 1st 파티 쿠키 기반의 타겟팅 광고가 가능했습니다. 하지만 AI 검색 환경에서는 다릅니다. 사용자가 AI의 답변을 통해 원하는 정보만 확인하고 사이트 유입 없이 이탈해 버리는 현상(Zero-click)이 산업군을 막론하고 발생하고 있기 때문입니다.

실제로 제가 모니터링해 온 업체들의 데이터에서도 단순 정보 제공형 콘텐츠의 AI 인용률이 더 높게 나타났습니다. 하지만 장기적으로 볼 때, 정보성 콘텐츠에만 의존하는 웹사이트는 결국 트래픽이 완전히 말라버릴 위험이 높습니다. 반대로 브랜드의 고유한 이야기, 소식, 실제 고객 후기 등 대체 불가능한 '비정형 콘텐츠'가 탄탄하다면 웹사이트로 직접 유입될 가능성이 훨씬 큽니다.

결국 우리가 시간과 노력을 들여 GEO를 한다면, 그것이 궁극적으로 '우리 브랜드'를 검색해서 찾아오게 만드는 데 영향을 주어야 합니다. 물론 큰 기업은 PR도 하고, 광고도 하고 이미 기존의 인지도도 높기 때문에, GEO 때문에 브랜드 유입이 증가한 것인지 명확히 측정하기 어렵습니다. 하지만 브랜드나 사이트가 처음 시작하는 단계이거나 작은 기업이라면 이 브랜드 키워드 유입 증가를 KPI로 잡고 테스트해볼 수 있습니다.

제가 맞춤 정규식 기준으로 브랜드 쿼리를 추출해 본 데이터가 있습니다. 왼쪽 첫 번째와 맨 아래에 있는 사이트는 광고를 전혀 집행하지 않고 자연 유입으로만 운영되는 곳이라 순수한 테스트 변화를 체크하기에 매우 유용했는데요. 보시다시피 브랜드 유입 수가 뚜렷하게 증가한 것을 확인할 수 있습니다.

이처럼 저는 가시성의 변화를 직접 테스트하며 다양한 인사이트를 발굴하는 편입니다. 이 과정에서 의문이 생기면 제가 애용하는 GEO 분석 툴을 제작하고 있는 '체인시프트'의 CTO님과 심도 있는 토론을 나누기도 합니다. 해당 툴을 보면 항목별 인용 및 적용 비율 같은 유용한 데이터가 제공됩니다. 하지만 툴에서 제공하는 수치는 어디까지나 '참조용 지표'입니다. 내 사이트가 실제 AI 환경에서 어떻게 인용되는지는, 툴에만 의존할 것이 아니라 직접 눈으로 확인하고 체감하는 정성적인 검증 과정이 반드시 동반되어야 한다고 생각합니다.

가시성은 올랐는데 브랜드 쿼리가 떨어진다면

물론 브랜드 검색량이 늘어난 것을 100% GEO만의 성과라고 단정 지을 수는 없습니다. 하지만 반대로, 가시성은 상승했는데 정작 우리 브랜드 유입은 오히려 떨어지고 있다면 경각심을 가져야 하지않을까 생각합니다. 내가 짠 프롬프트가 정교하게 브랜드를 각인시키는 프롬프트인지, 아니면 그저 '좋은 정보만 퍼주고 끝나는' 프롬프트인지 점검해 봐야 할 시점이죠.

이상적인 그림은 명확합니다. AI 내 가시성을 높여 우리 브랜드의 언급량을 늘렸다면, 그에 비례해 브랜드 검색량도 올라가야 정상이라고 생각합니다. 이를 IMC(통합 마케팅 커뮤니케이션) 관점에서 본다면, GEO와 브랜드 쿼리는 당연히 하나의 궤적에서 함께 봐야 하는 지표입니다. IMC 개념이 당장 생소하시더라도 괜찮습니다. '내 브랜드의 메시지를 모든 접점에서 일관되게 전달하여 고객을 끌어당긴다'는 맥락만 파악하신다면, 충분히 이 관점을 GEO 실무에도 훌륭하게 접목하실 수 있을 것입니다.

성과를 과대 포장하지 말자

마지막으로 당부드리고 싶은 것은, 'GEO로 엄청난 성과와 매출을 만들었다'는 식의 무용담을 항상 경계해야 한다는 점입니다.

AI 검색 환경에서 가시성이 아무리 올라갔다 한들, 실제 전환이나 결제로 이어지는 길목은 여전히 네이버의 지배력이 압도적이기 때문입니다. 실제로 월 매출 3~4억 원을 기록하는 인지도 높은 국내 브랜드, 그 이상의 매출을 내고 있는 누구나 알법한 다국어 브랜드의 채널별 데이터를 뜯어보았을 때도, 네이버와 구글의 기존 오가닉 검색 매출이 압도적으로 높았습니다. 그렇다면 LLM(거대 언어 모델)을 통한 유입이 그에 비례하는 매출을 견인했을까요? 어느 정도의 일부 발생은 있었지만, ROI나 ROAS 관점에서 무작정 GEO에 예산을 쏟아붓는다고 해결될 수준은 결코 아니었습니다.

현실적으로 말씀드리면, 현재 GEO는 국내외를 막론하고 그 누구도 완벽하게 성과를 측정할 수 없는 미지의 영역입니다. 그렇기에 기존 퍼포먼스 마케팅이나 SEO처럼 '클릭'과 '노출'과 같은 수준으로 AI가시성, 인용률과 같은 명확한 단일 지표를 KPI로 삼는 것은 아직까진 무의미하다 보고 있습니다.

오히려 다양한 '전조 증상'들을 KPI 대시보드에 띄워놓고, 지표 간의 상관관계를 비교해 가며 '우리의 콘텐츠 체질이 올바른 방향으로 개선되고 있는가'를 판단하는 것이 현재로서는 가장 타당한 접근이라고 생각합니다.

"어느 기업이 AI 최적화로 전환율을 몇 배 올랐다더라, 유입이 몇백 몇천프로 올랐다" 하는 과장된 PR 기사에 흔들리실 필요 없습니다. 남들이 한다고 조급해할 것이 아니라, 그 사례가 어떤 산업군이었고, 어떤 환경에서, 어떤 잣대로 측정된 것인지부터 냉정하게 따져보아야 합니다.

솔직히 말씀드리면, 적어도 국내 이커머스 환경에서 LLM을 통한 실질적 전환은 개인적으로 봤을 때 '처참한' 수준이었습니다. 누구나 알 만한 유명 브랜드조차 챗GPT 같은 AI 엔진에서 노출은 잘 되어도, 그것이 지갑을 여는 전환으로 이어지는 비율은 아직 미미합니다. (이 지표 또한 AIO나 AI Mode는 제외하고 본 형태죠)

결론은 이렇습니다. 과장된 기사를 보고 조급함(FOMO)을 느끼셨다면, 아직은 한숨 돌리셔도 괜찮습니다. GEO를 통해 '당장의 결과(매출)'를 기대하는 프로젝트를 기획하신다면 십중팔구 실패할 것입니다. 하지만 다가올 검색 패러다임의 변화에 맞춰 우리의 자산을 정비하는 '준비의 자세'로 접근하신다면, 분명 올바른 궤도에 오르실 수 있습니다.

다만 이 모든 이야기는 제가 직접 부딪히며 얻은 저의 경험에 의거해 드리는 말씀입니다. 그런 만큼, 최종적인 판단은 여러분의 몫이라고 생각합니다. 감사합니다.

질의 응답

Q.사이트에 접속한 AI Crawler의 종류는 user-agent 헤더값으로 판단하신 것인가요?

양용준:클라우드플레어를 통해 판단하고 있습니다. 제가 확인한 바에 의하면 user-agent 하나로만 판단하는 게 아니라, IP/ASN, Bot Score 등을 종합적으로 판단하는 것으로 알고 있습니다.

GEO 팩트체크 세미나의 다른 발표도 함께 보세요

세미나 사전에 발행된 콘텐츠(세미나 참가 전 알면 좋은 것들)

GEO 시대의 글쓰기, SEO와 무엇이 같고 무엇이 다른가 ( ⬅️ GEO가 처음이라면 여기부터!)
GEO 성과 측정법: 최종 KPI 말고 '전조 증상'을 봐야 하는 이유

세미나 후 발행된 콘텐츠(세미나에서 실제로 발표한 내용)

GEO 콘텐츠 전략: SEO 키워드 보다 AI '맥락' 설계하는 법
GEO 성과 측정 실전편: 인용률 트래킹과 AI 크롤러 로그 활용법(현재 글)
AI 검색 엔지니어가 본 GEO: 무엇이 인용을 결정하는가
GEO를 둘러싼 3가지 오해와 팩트체크

]]>

지금 진짜 쓸 만한 AI 에이전트 10가지 총정리(1) : 웹·코딩 에이전트

지금 진짜 쓸 만한 AI 에이전트 10가지 총정리 시리즈
1편: 웹·코딩 에이전트 6가지 (현재 글)
2편: 자율 에이전트 4가지

요즘은 에이전트 도구 정도는 다뤄야 일잘러 소리를 듣는다고 합니다. 그래서 일단 Claude Code부터 받아봅니다. 그런데 어떻게 쓰는지 도무지 모르겠습니다. 유튜브도 보고 아티클도 찾아봤지만 난도가 좀 있다는 말에 슬그머니 마음을 접습니다. 대신 주말에 '알아서 움직이는 비서'라고 소문난 OpenClaw를 개인 노트북에 깔아봅니다. 오픈카톡방에서 다들 핫하다고 하니까요. 그런데 정작 이게 뭘 하는 물건인지, 둘이 뭐가 다른지조차 감이 안 옵니다.

이 풍경, 익숙하지 않으신가요? 사실 저부터가 그랬습니다.

현재 프로덕트 시장에서 '에이전트'는 만능 단어입니다. AI와 자동화가 조금만 얹혀도 죄다 '우리 서비스는 에이전트'라고 하니까요. 그러니 헷갈리는 게 당연합니다.

그래서 지금 주목받는, '진짜 에이전트'라고 부를 만한 서비스 10개를 모아 2편에 걸쳐 소개하려 합니다. 이번 1편에서 다루는 건 여섯 개입니다. 가볍게 한 번 맡겨보는 웹 에이전트로 마누스(Manus)와 젠스파크(Genspark), 컴퓨터를 통째로 맡기는 코딩 에이전트로 클로드 코드(Claude Code), 코덱스(Codex), 안티그래비티(Antigravity), 클로드 코워크(Claude Cowork)입니다.

다만 이들을 똑같이 '에이전트' 한 단어로 묶으면 혼란은 그대로입니다. 무엇을 알고 시작하는지(컨텍스트), 무엇으로 일하는지(도구), 어디까지 손대도 되는지(권한), 언제 켜지는지(트리거) 서비스마다 제각각이거든요.

이 글은 그 혼란을 정리해보려 합니다.

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

에이전트가 대체 뭔데요

우선, “에이전트”가 무엇인지 짚어보고 넘어가겠습니다. 마치 AGI처럼, 다들 자기 기억에 남은 대로 제각각 정의해 버린 게 이 모든 혼란의 시작이니까요.

자세히 들어가면 물론 복잡한 정의가 필요하지만, 이 글을 이해하는 데 필요한 정의는 이렇습니다.

“LLM이 도구를 루프(loop)로 돌려 목표를 달성한다.”

목표 하나만 던져주면, AI가 손에 쥔 도구를 골라 써가며 끝날 때까지 알아서 굴리는 겁니다. 한 번 답하고 끝나는 것도 아니고, 다음에 뭘 할지 스스로 정하면서 계속 돌죠.

비서한테 “이번 분기 매출 정리해서 보고서로 만들어줘” 하면, 엑셀 열고, 데이터 정리하고, 차트 그리고, 문서로 저장할 거라고 기대할 수 있잖아요. 누가 일일이 안 알려줘도 도구를 골라가며 적당한 보고서가 나올 때까지 할 겁니다. 그 비서가 사람이 아니라 AI면, 그게 에이전트예요. 챗봇하고는 일하는 방식이 다릅니다. 챗봇은 답을 말해주고, 에이전트는 답을 만들어내요. 이를 위해 파일을 직접 열고, 코드를 직접 쓰고, 메일을 직접 보냅니다.

정의는 한 줄이지만, 그 한 줄을 실제로 어떻게 구현하느냐는 만드는 곳마다 다릅니다. 그래서 서비스마다 생김새가 제각각이고요.

에이전트를 가르는 4가지: 컨텍스트·도구·권한·트리거

그 많은 방식을 하나하나 좇다 보면 금세 헷갈립니다. 그래서 여기서는 에이전트가 일을 시작하는 구조 하나로 기준을 좁혀보려 합니다. 명령을 받으면 에이전트가 가장 먼저 하는 일은, 계획을 세우는 겁니다. 무엇을 해야 하는지 파악하고, 어떤 순서로 도구를 쓸지 정하는 거죠. 그런데 이 계획을 세우려면 그 전에 네 가지가 먼저 정해져 있어야 합니다. 무엇을 알고(컨텍스트), 무엇으로 하고(도구), 어디까지 해도 되고(권한), 언제 시작하느냐(트리거).

이 네 가지를 어떻게 받느냐에 따라 서비스가 갈립니다. 그리고 그중에서도 에이전트의 종류를 결정적으로 가르는 축은 권한입니다. 웹이냐 터미널(개발자들이 쓰는 검은 명령어 창)이냐 같은 겉모습으로 나누는 게 분류는 더 쉽겠지만, 본질은 여기 있죠. 이 기준으로 보면 서비스가 크게 셋으로 묶입니다.

에이전트 서비스 구분표

핵심은 권한, 곧 '어디까지 알아서 하게 둘 것인가'입니다. 한 칸씩 올라갈수록 에이전트한테 더 많은 걸 맡기게 되죠.

웹 에이전트는 서비스가 미리 정해둔 도구 안에서, 내가 던진 일 하나를 처리합니다. 내가 손볼 것도, 따로 허락할 것도 거의 없어 가장 가볍죠. 대신 복잡하고 어려운 일에서는 한계가 분명합니다.

코딩 에이전트(컴퓨터 유즈)와 자율 에이전트는 자유도 측면에서 한 단계 위입니다. 둘 다 무엇을 알려주고(컨텍스트) 무엇을 쓰게 할지(도구)를 내가 직접 붙여, 내 일에 맞춥니다. 손은 더 가지만 그만큼 할 수 있는 일이 넓어지죠.

이 둘을 가르는 게 바로 권한입니다. 코딩 에이전트는 파일 하나를 고치기 전에도 "이거 해도 될까요?" 하고 매번 물어봅니다. 반면 자율 에이전트는 한 번 "여기까지는 알아서 해"라고 정해두면, 그 안에서는 묻지 않고 24시간 혼자 굴러갑니다. 내가 자는 동안에도요.

‘코딩 에이전트’라는 이름의 함정

여기서 가장 널리 알려진 것은 Claude Code, Codex와 같은 “코딩 에이전트”입니다. 그런데 그 ‘코딩 에이전트’라는 이름 때문에, 그걸 쓸 수 있는 사람들도 ‘난 코드는 모르는데’ 하며 진입장벽을 느끼게 되기도 합니다. 하지만 이 에이전트들은 처음엔 코드만 만졌지만, 지금은 파일·앱·데스크톱·문서까지 컴퓨터에서 하는 거의 모든 일을 다룹니다. 이걸 컴퓨터 유즈(computer use)라고 불러요.

그러니 이 글에서 코딩 에이전트=컴퓨터 유즈 에이전트라고 생각해도 좋습니다. “코딩 에이전트는 개발자만 쓰는 거 아냐?” 하고 지레 겁먹을 필요 없다는 뜻입니다. (물론 이들이 제일 잘 하는 일은 여전히 프로그래밍 작업입니다. 하지만 우리가 쓰는 모든 업무용 프로그램도 사실 코드로 돌아간다는 걸 잊지 마세요.)

웹 에이전트: 가볍게 한 번 맡겨보기

웹 에이전트는 사람이 준 프롬프트를 받아 서비스가 정해둔 도구를 써 문제를 해결합니다. 코드베이스(프로젝트의 코드 전체)를 붙이거나 도구를 손볼 일이 없죠. 그래서 자료 조사나 PPT 같은 작업을 하나 맡겨보면, 에이전트가 어떻게 도는지 가장 가볍게 익힐 수 있습니다.

1. Manus: 에이전트 작업 미리보기

Manus는 ‘자율 작업 에이전트’라는 컨셉으로 어쩌면 가장 먼저 화제를 모은 프로덕트입니다. 2025년 3월 6일 초대 전용 베타로 론칭했으니까요.

Manus

누가·언제·뭘로

중국에서 출발해 지금은 싱가포르에 본사를 둔 스타트업 버터플라이 이펙트(Butterfly Effect)가 만든 웹 기반 에이전트예요. 설치 없이 브라우저에서 돌고, 무료 토큰으로 부담 없이 시작할 수 있습니다. (다만 2025년 말 메타가 인수를 추진했다가 2026년 4월 중국 당국이 제동을 걸면서, 회사의 향방은 아직 불투명합니다.)

어떻게 동작할까?

웹에서 작업을 맡기면 가상 환경 안에서 브라우저·터미널·파일을 자율로 굴립니다. 단계마다 붙어 있을 필요 없이 끝날 때까지 맡겨두고 결과만 받는 식이라, 긴 호흡으로 웹을 훑는 리서치에 잘 맞습니다.

AI가 스스로 계획을 세우는 구조, 도구를 선택하고 활용하는 과정, 결과물이 발전하는 순간들을 우측 모니터로 함께 보여주는 것도 특징입니다.

성능은?

리서치 계열이나 보고서를 만드는 일이라면, 무료 토큰으로도 충분히 써볼 만합니다. 다만, 이를 내 상황에 완전히 맞춘다거나 세밀한 수정에 들어가려 하면 여러 제약이 느껴집니다. 토큰도 빠르게 소모되기 시작하고요.

한 줄 추천

프롬프트 한 줄만 입력해도, 작업 설계와 결과물 생성 과정을 한눈에 볼 수 있습니다. “아, 에이전트는 이렇게 움직이는구나” 하는 걸 이해하기에 정말 좋습니다.

2. Genspark: 가벼운 세팅에 괜찮은 퀄리티

Genspark는 프롬프트 하나로 긴 단위 작업을 가장 빨리 맡겨볼 수 있는 제품입니다. 특히 PPT를 비롯한 콘텐츠 작업에서 강점을 보이던 Super Agent에 이어 2026년 3월 자율 에이전트인 Claw를 도입하며 ‘AI 직원’ 쪽으로 방향을 틀었습니다.

Genspark

누가·언제·뭘로

바이두 출신 에릭 징·케이 주가 2023년 창업한 MainFunc가 만든 웹 에이전트예요. 가입하면 무료 토큰으로 바로 써볼 수 있습니다.

어떻게 동작할까?

작업을 입력하면 LLM 9개, 통합 도구 80개를 알아서 고릅니다. 이어 웹을 자율로 브라우징하며 결과를 한곳에 모아줘요. 그래서 이런 일에 잘 맞습니다.

자료 조사·다중 사이트 비교
가격·기능을 여러 사이트에서 긁어와 요약
신규 조사를 접목한 PPT 제작

성능은?

PPT 쪽에서는 전용 도구만큼이나 뛰어난 성능을 보여줬습니다. 요즘은 이력서나 보고서 쪽으로도 스텝을 많이 확장하고요.

한 줄 추천

시각적으로 꽤 괜찮은 결과물을 얻고자 하면 써보기 좋습니다. 무엇보다 무거운 세팅이 없으니 쉽게 시작할 수 있습니다.

코딩 에이전트: 지켜보며 컴퓨터를 통째로 맡기기

웹 에이전트와 달리, 코딩 에이전트부터는 컨텍스트·도구를 다 내가 직접 정합니다.

컨텍스트는 에이전트가 일을 처리하기 위해 알아야 할 맥락입니다. 프롬프트를 비롯해 기존 코드, 혹은 문서에 담긴 텍스트 등이죠.
도구는 에이전트가 쓸 수 있는 ‘무언가’입니다. 코드를 읽거나 쓸 수 있고, 파일을 만들고 지우기도 하며, 웹에 접근해 필요한 것들을 찾거나 받아오기도 합니다.

무엇보다 매력적인 것은 이러한 컨텍스트와 도구를 완전히 내 일에 맞춘 구조로 직접 세팅할 수 있다는 점입니다. 다만 그 권한, 그러니까 '어디까지 알아서 하게 둘 것인가'는 여전히 사람이 쥡니다. 그렇게 되면 좋을 것 같지만, 때로는 귀찮기도 하죠. 물론 자동 모드(Auto mode) 등을 적용하거나 미리 권한을 적극 넘겨, 자율성을 꽤 높일 수도 있습니다. 그래도 결국 “내가 호출할 때” 움직인다는 점, 즉 사람의 시작이 ‘트리거’라는 점에서, 묻지 않고 24시간 도는 자율 에이전트와는 분명히 거리가 있습니다.

3. Claude Code: 기준점이 된 도구

터미널·IDE·슬랙 어디서든 코드 기반으로 Claude를 불러와 움직일 수 있는 도구입니다. 매일 쓸 수 있는 수준까지 올라온 첫 에이전트입니다. 가장 먼저 나와 오래 다듬어진 도구라 안정적이고, 참고할 자료와 생태계도 방대합니다. 그래서 처음이라면 기준점으로 삼기 좋죠.

Claude Code

누가·언제·뭘로

앤트로픽이 2025년부터 운영해요. 모델은 Sonnet 4.6과 Opus 4.8(2026년 5월 28일 출시), 터미널·IDE·데스크톱 앱·모바일 모두 지원하고, Pro·Max 플랜을 구독한다면 누구나 쓸 수 있습니다. 한도는 차이가 있지만요.

어떻게 동작할까?

채팅으로 일을 시키면 코드베이스를 읽거나 파일을 수정·생성하고, 테스트까지 돌린 다음 보고합니다. Claude 모델을 두뇌로 삼아, 내 컴퓨터에 있는 자료에 ‘권한’을 받았다면 접근할 수 있습니다. 그리고 내장된 도구와 사용자가 직접 만드는 도구들로 일합니다. 다만, 명시적 승인 없이는 파일을 수정하지 않습니다.

이런 일에 강해요

큰 코드베이스 기반 작업과 리팩터링(1M 컨텍스트)
바닥부터 바이브 코딩 시작하기
터미널, 데스크톱, 모바일 등 멀티채널로 작업 이어가기
파일·문서 자동화를 비롯한 컴퓨터에 일 시키기

한 줄 추천

코드를 만질 수 있는 사람이라면 일단 켜보세요. 사실 그렇지 않은 사람들에게도 저는 추천하고 싶습니다. 원하는 것을 잘 말하고, 모르는 것을 제대로 물어볼 수만 있다면, 아주 못 할 일이 없다고 생각합니다.

4. Codex: 최고 성능 도구로 어깨를 나란히

OpenAI가 만든 코딩 에이전트입니다. 가벼운 데다, 오픈소스라 부담이 덜 합니다. 무엇보다 지금 최고 수준으로 평가받는 GPT-5.5를 쓸 수 있습니다.

Codex

누가·언제·뭘로

오픈소스 CLI고, ChatGPT 플랜(Plus·Pro·Business·Edu·Enterprise)을 쓰면 정해진 한도 내에서 자유롭게 쓸 수 있습니다. 업데이트 주기가 정말 빠르기도 하고요. 앱 형태로 받아 쓸 수 있습니다.

어떻게 동작할까?

명령을 주면 코드 작업을 해줍니다. 사실 Claude Code와 거의 유사합니다. 다만, 그 두뇌가 GPT 계열 모델이라는 것이 가장 큰 차이겠죠. 마찬가지로 컴퓨터를 활용한 작업이라면 그 무엇이든 충분히 해줍니다. 조금 더 목적 지향적으로 ‘권한’에 대한 질문을 덜한다는 것이 특징입니다.

이럴 때 좋아요

일상 작업을 토큰 알뜰하게 돌리고 싶을 때
이미 ChatGPT 구독 중이라 추가 결제 없이 켜보고 싶을 때
회사 정책이 빡빡해 코드를 직접 검토·사내 운영해야 할 때

한 줄 추천

조금 더 알아서 돌아가는 에이전트를 찾거나, ChatGPT 환경에 익숙하다면 추천합니다. 코딩 작업에서 Claude Code와 어깨를 나란히 하고, 영역에 따라서는 더 낫다는 평가도 나옵니다.

5. Antigravity: 구글 생태계를 그대로

구글은 코딩 에이전트를 비교적 산발적으로 출시했습니다. 코드 편집 프로그램인 IDE에 얹은 Antigravity 1.0으로도 나오고, 검은 명령어 창에서 쓰는 CLI 형태인 Gemini CLI로도 나왔죠. 최근 행사에서 이를 모두 묶어 '에이전트 우선' 개발 플랫폼으로 통합했습니다. 전용 데스크톱 앱에서 한층 에이전트답게 움직이고요.

Antigravity

누가·언제·뭘로

일종의 통합판인 Antigravity 2.0은 2026년 5월 Google I/O에서 공개됐고, 가장 최근 나온 핵심 모델은 Gemini 3.5 Flash입니다. 전용 데스크톱 앱과 CLI에서 에이전트 채팅으로 일을 시키는데, 코드 편집기 대신 위임형 채팅 인터페이스(채팅으로 일을 맡기는 구조)를 중심으로 둔 구조입니다.

어떻게 동작할까?

기본 골격은 앞서 본 코딩 에이전트들과 같습니다. 채팅으로 일을 맡기면 코드를 읽고, 파일을 고치고, 결과를 보고하죠.

이럴 때 좋아요

구글 워크스페이스를 구독하며 그 도구들을 무척 잘 쓰고 있을 때
약간 아쉬워도, 빠르게 움직이는 에이전트를 경험하고 싶을 때

한 줄 추천

Google 생태계 안에서 일하면 켜볼 만해요. 또 Gemini 3.5는 현재 가벼운 Flash 모델만 정식 출시됐고, 상위 모델인 Pro는 2026년 6월 출시 예정입니다. Pro가 합류하면 성능이 어떻게 달라질지 지켜봐야 합니다.

6. Claude Cowork: 비개발자를 위한 변형

코딩 에이전트와 같은 카테고리인데, 비개발자에게 친화적인 GUI로 움직이는 에이전트입니다. 앤트로픽이 ‘Claude Code의 지식 노동자 버전’이라며 만든 서비스죠.

Claude Cowork

누가·언제·뭘로

2026년 1월 12일 연구 프리뷰로 공개(Max 먼저, 1월 16일 Pro 확장)했고, 이제 Claude Pro·Max 플랜이라면 써볼 수 있습니다.

어떻게 동작할까?

데스크톱 앱에서 폴더와 Connector(Google Drive·Gmail·DocuSign·FactSet 등)를 지정하면 Claude가 파일·앱을 직접 읽고 편집해요. 여러 작업을 병행해서 밀고 가되, 실행 전에 계획을 보여주고 승인을 기다리는 ‘Ask before acting’ 방식입니다. 파일 정리·보고서 제작·메일 처리에 잘 맞습니다.

한 줄 추천

코드는 안 만지지만 코딩 에이전트의 힘을 느껴 보고 싶을 때 추천합니다. 웬만한 커스터마이징이 충분히 가능한 데다가 코드를 안 다루면 큰 차이도 없다고 보입니다. 다만, 토큰은 조금 더 많이 먹는 느낌입니다.

코딩 에이전트는 왜 지금 이렇게 인기일까?

2026년 들어 코딩 에이전트가 '시장에 제대로 자리 잡았다'고 보는 시각이 늘었습니다. 토큰을 어마어마하게 태우는 비싼 도구인데도, 전문가들이 매일 쓰는 도구 수준으로 올라왔다는 거죠. 웹·자율 에이전트가 아직 “신기하다”와 “매일 쓴다”의 중간이라면, 코딩 에이전트는 그 선을 이미 넘었습니다.

이들의 이름은 ‘코딩’이지만 이제 코드만 만지지 않아요. 파일 정리·문서 자동화·앱 실행까지, 컴퓨터에서 하는 거의 모든 일로 넓어졌거든요. 대신 파일 하나 건드릴 때마다 사람한테 묻고, 시작 버튼도 사람이 누릅니다.

마치며 : 그래서 무엇부터 시작할까

여기까지가 1편입니다. 두 종류를 봤죠. 웹 에이전트는 프롬프트 한 줄만 던지면 되니, 에이전트가 대체 어떻게 일하는지 가장 가볍게 구경하기 좋습니다. 리서치나 PPT처럼 평소 시간 잡아먹던 작업을 통째로 한번 맡겨보세요. Manus와 Genspark면 충분합니다.

코딩 에이전트는 한 걸음 더 들어가, 무엇을 알려주고(컨텍스트) 무엇을 쓰게 할지(도구)를 내가 직접 정합니다. 대신 파일 하나 건드릴 때마다 허락을 구하니 통제권은 그대로 쥐고 가죠. 코드를 만진다면 Claude Code·Codex·Antigravity 중 내 생태계에 맞는 걸로, 코드를 안 만진다면 같은 힘을 GUI로 쓰는 Cowork로 시작하면 됩니다.

핵심은 외워서 아는 게 아니라 한 번 직접 돌려보는 겁니다. 글로 읽은 것과 손으로 굴려보며 깨닫는 건 전혀 다르거든요. "이런 것도 되나?" 싶은 일부터 일단 시켜보세요.

그리고 마지막 한 칸이 남았습니다. 지금까지의 에이전트는 무언가 할 때마다 사람에게 물었지만, 한 번 "여기까지는 알아서 해"라고 허락하면 그다음부터는 묻지 않는 에이전트 서비스가 있습니다. 내가 자는 동안에도 24시간 혼자 일하죠. 가장 강력한데 그래서 가장 위험하기도 한 자율 에이전트, 즉 OpenClaw·Hermes 같은 프로덕트 소개는 2편에서 이어집니다.

누구나 만드는 시대, 정말 중요한 건 무엇일까 (Figma CPO)

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

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

써볼 것: 다이나믹 워크플로 - 작업에 맞는 작업 틀을 그때그때 직접 짜는 Claude Code 기능
참고할 것: 오픈AI Codex Sites - 프롬프트만으로 웹앱을 만들어 URL로 공유하는 기능
적용해볼 것: 누구나 만들 수 있게 됐을 때 진짜 차이를 만드는 것 - Figma CPO의 관점

<출처: Claude>

1. 써볼 것: 작업에 맞는 작업 틀을 그때그때 직접 짜는 Claude Code 기능

다이나믹 워크플로(dynamic workflows)는 Claude Code가 맡은 작업에 맞춰 처리 방식을 직접 설계하고, 여러 개의 보조 AI를 동시에 굴려 일을 처리하는 기능입니다. 5월 28일 리서치 프리뷰로 공개됐고요. 이후 Claude Code를 개발하는 Anthropic(앤트로픽)의 Thariq Shihipar가 직접 써본 경험과 활용법을 정리해 공유했습니다. 이는 조회수 230만, 좋아요 8천을 넘기며 개발자들 사이에서 화제가 됐습니다.

<출처: Thariq Shihipar X(@trq212)>

원래 이런 일은, 그러니까 여러 AI를 나눠서 부리고 서로 검증시키는 작업은 개발자들이 직접 코드를 짜서 흉내 내고 있었습니다. 여러 Claude를 스크립트로 엮어 돌리는 식이었죠. 그렇게 손수 만들던 걸 이제 Claude Code가 알아서 짜준다는 점에서 반응이 좋았습니다. (InfoQ 등이 정리한 내용입니다)

왜 이런 기능이 필요할까요. AI에게 큰 작업을 한 번에 통째로 시키면, 계획을 세우는 일과 실제로 처리하는 일을 같은 대화 안에서 다 하게 됩니다. 짧은 작업은 이걸로 충분한데, 작업이 길고 복잡해지면 AI가 몇 가지 함정에 빠지거든요.

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

앤트로픽이 짚은 함정은 세 가지입니다.

첫째는 중간에 멈추는 겁니다. 50개를 점검해야 하는 보안 검토에서 20개만 보고 다 했다고 선언해 버리는 식이에요. 작업이 복잡할수록 이런 일이 잦아집니다.
둘째는 자기 결과를 후하게 보는 겁니다. AI에게 자기가 낸 결과를 기준에 맞춰 검증하라고 하면, 자기 답을 더 좋게 평가하는 쪽으로 기웁니다.
셋째는 목표가 흐려지는 겁니다. 대화가 길어지고 중간 요약을 거치면서, 처음에 못 박았던 이건 하지 마 같은 조건이 조금씩 사라집니다.

다이나믹 워크플로는 이걸 구조로 막습니다. 하나의 AI에게 다 시키는 대신, 각자 자기 맥락과 좁은 목표만 가진 여러 AI로 일을 쪼개서 돌립니다. 서로 결과를 검증하게 만들 수도 있고요.

어떻게 쓰나요?

쓰는 법은 어렵지 않습니다. 프롬프트에 작업을 설명하면서 워크플로로 처리해 달라고 하거나, /effort 메뉴에서 ultracode를 켜면 됩니다. ultracode를 켜면 AI가 작업마다 알아서 워크플로를 짤지 판단합니다. 처음 실행될 때는 무엇이 돌아갈지 먼저 보여주고 확인을 받으니, 모르고 큰 작업이 돌아갈 걱정은 없습니다.

Thariq가 든 예시를 보면 쓰임새가 그려집니다.

내 사업계획서를 투자자, 고객, 경쟁사 입장에서 각각 물어뜯게 해줘. → 서로 다른 관점의 AI들이 동시에 약점을 파고듭니다.
이력서 80장을 백엔드 포지션 기준으로 순위 매기고, 상위 10명은 한 번 더 확인해줘.
지난 50개 세션을 훑어서, 내가 반복해서 고치는 지적들을 찾아 규칙으로 정리해줘.
블로그 초안의 기술적 주장을 코드베이스랑 하나하나 대조해서 틀린 게 없는지 확인해줘.

코드 작업에만 해당하는 얘기가 아닙니다. Thariq 본인도 오히려 비개발 업무에서 더 유용할 때가 많다고 했고요. 매출이 3월에 왜 떨어졌는지 원인을 여러 갈래로 나눠 파보는 것처럼요.

내부적으로는 여러 패턴을 조합해 작업 틀을 짭니다. 작업을 잘게 나눠 각각 처리한 뒤 합치거나, 같은 작업을 여러 방식으로 시도한 다음 둘씩 비교해 가장 나은 걸 고르거나, 멈춤 조건이 충족될 때까지 반복하는 식입니다. 한 번 실행에 보조 AI를 최대 1,000개까지, 동시에는 16개까지 띄울 수 있습니다.

다만 토큰을 훨씬 많이 씁니다. 앤트로픽도 작은 작업부터 시작하라고 권하고요. 일반적인 코딩 작업 대부분은 굳이 이렇게까지 할 필요가 없습니다. 검토자 다섯 명을 붙일 만한 작업인지 한 번 따져보고 쓰는 게 좋습니다. /goal로 완료 조건을 박아두거나 /loop로 주기적으로 돌리는 것과 묶어 쓰면 더 잘 맞습니다.

누구에게 좋을까요?

한 번에 끝내기엔 너무 크고 여러 갈래로 검증이 필요한 작업을 자주 다루는 분 (대규모 리팩터링, 보안 점검, 대량 분류 등)
AI에게 큰 작업을 시키면 늘 중간에 흐지부지된다고 느꼈던 분
코드뿐 아니라 사업, 분석, 기획 쪽에서 여러 관점으로 검증하고 싶은 분

유료 Claude Code 플랜(Pro, Max, Team, Enterprise)에서 쓸 수 있습니다. Max와 Team은 기본으로 켜져 있고, Pro는 /config에서 직접 켜야 하며, Enterprise는 관리자 승인이 필요합니다. Claude Code 버전이 2.1.154 이상이어야 하니, 안 보이면 업데이트를 해보시길 권장합니다.

공식 안내: claude.com/blog/introducing-dynamic-workflows-in-claude-code
Thariq Shihipar가 공유한 활용법: A harness for every task: dynamic workflows in Claude Code

<출처: openai.com>

2. 참고할 것: 프롬프트만으로 웹앱을 만들어 URL로 공유하는 기능

사내에서 간단한 대시보드 하나, 신청 받는 페이지 하나 만들려고 해도 보통은 일이 커집니다. 기획을 정리하고, 개발자에게 요청하고, 서버에 올리고, 주소를 받기까지 며칠이 걸리죠. 비개발자라면 시작할 엄두조차 안 나고요.

OpenAI(오픈AI)가 이 과정을 통째로 줄이겠다고 나섰습니다. 6월 2일 'Intelligence at Work' 행사에서 코딩 도구 Codex의 대규모 업데이트를 공개했습니다. 그중 가장 주목받은 건 Sites라는 기능입니다. 프롬프트로 설명만 하면 인터랙티브 웹사이트나 웹앱을 만들어줍니다. 오픈AI가 호스팅까지 맡아서, URL 하나로 바로 공유할 수 있습니다.

오픈AI가 이렇게 움직인 데는 이유가 있습니다. Codex 주간 사용자는 500만 명을 넘었고, 이 중 분석가, 마케터, 운영, 디자이너, 투자자 같은 비개발자가 약 20%를 차지합니다. 게다가 이 비개발자 사용자가 개발자보다 3배 빠르게 늘고 있고요. 코딩 도구를 업무 전반으로 넓히려는 흐름이 이번 발표의 배경입니다. (Sites 외에도 직군별 플러그인 6종, 결과물의 특정 부분만 골라 수정하는 주석 기능이 함께 나왔습니다)

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

지금까지 노코드 도구로 웹페이지를 만들 수는 있었습니다. 하지만 보통은 그 도구 안에서만 동작하거나, 만든 다음 어딘가에 따로 올려야 했죠. Sites는 만드는 것부터 호스팅, 공유까지를 한 흐름으로 묶었습니다. 별도의 배포 설정 없이 대화 안에서 만들고 바로 주소를 받는 구조입니다.

<출처: openai.com>

만들 수 있는 것도 정적인 페이지에 그치지 않습니다. 대시보드, 플래너, 검토용 작업 공간, 프로젝트 보드, 갤러리, 가벼운 사내 도구, 게임까지 가능합니다. 한 번 만들고 끝이 아니라, 내용이 바뀔 때마다 Codex에게 최신 상태로 유지해 달라고 할 수도 있고요.

어떻게 작동하나요?

쓰는 흐름은 간단합니다. Codex 대화창에서 @Sites를 부르고 만들고 싶은 걸 설명하면 됩니다. 오픈AI가 든 예를 보면 쉽게 이해됩니다. 곧 있을 고객 미팅용 페이지를 만들어 달라고 하면, 그 고객과 관련된 제품 업데이트, 미해결 질문, 사용 추세, 다음 단계를 담은 페이지가 나옵니다. 재무 모델로 시나리오 플래너를 만들어 달라고 하면, 탭을 일일이 넘기지 않고도 여러 가정을 나란히 비교할 수 있는 도구가 나옵니다.

게시는 두 단계로 나뉩니다. 먼저 검토용으로 버전을 저장하고, 확인이 끝나면 그 버전만 실제로 배포합니다. 잘못된 걸 그대로 내보내는 일을 막는 장치예요.

데이터를 다루는 방식도 정리돼 있습니다. 신청 기록이나 게임 점수처럼 계속 저장해둬야 하는 정보는 관계형 데이터베이스(D1)에, 이미지나 문서, 영상 같은 파일은 따로 마련된 저장소(R2)에 보관합니다. 로그인도 붙일 수 있어서, 워크스페이스 사용자만 들어오게 하거나 외부 로그인을 연결할 수 있습니다. 누가 사이트에 접근할 수 있는지는 소유자와 관리자만, 워크스페이스 전체, 직접 지정한 사람만, 이렇게 세 가지로 정합니다. 비밀번호 같은 민감한 값은 소스 코드에 같이 올리지 말고 Sites 패널에서 따로 관리하라고 안내합니다.

지금은 프리뷰 단계라, ChatGPT Business 워크스페이스에서는 기본으로 켜져 있고 Enterprise에서는 관리자가 권한을 열어줘야 씁니다.

이 발표가 왜 술렁였나요?

Sites가 나오자 노코드 AI 웹 빌더 쪽이 긴장했습니다. Lovable, Bolt.new, v0처럼 프롬프트로 웹앱을 만들어주던 서비스들이 하던 일을, 오픈AI가 자기 제품 안에 그대로 넣어버린 모양새거든요. 큰 플랫폼이 작은 서비스의 기능을 자기 제품으로 흡수하면, 사람들이 그 서비스를 따로 쓸 이유가 줄어듭니다. 일부 외신은 이번 발표를 두고 여러 분야의 기존 업무용 소프트웨어를 정면으로 겨냥한 움직임이라고 보기도 했습니다.

그런데 이번 건은 그렇게 단순하게 보기 어렵습니다. 오픈AI가 Sites 파트너로 Wix, Base44, Replit, Lovable, Figma, Webflow, Emergent를 명시했거든요. 위협받는다고 거론되는 회사 중 일부가 오히려 파트너로 들어가 있는 겁니다. 그래서 지금은 흡수냐 협업이냐의 경계가 흐릿하다고 보는 게 정확합니다. 모델을 만드는 회사가 그 위에 얹히던 앱 영역까지 끌어안으면서, 어떤 곳은 품고 어떤 곳은 밀어내는 구도가 만들어지고 있습니다.

무엇을 얻어가야 하나요?

Sites는 아직 프리뷰라 대부분의 독자가 당장 써보긴 어렵습니다. 그래서 이건 지금 당장 써볼 것이라기보다 흐름을 읽어둘 소식에 가깝습니다.

읽어둘 포인트는 두 가지입니다. 하나는 소프트웨어를 만드는 사람의 경계가 넓어지고 있다는 점입니다. 코드를 못 짜도 프롬프트로 사내 도구를 만들어 배포까지 끝내는 일이 큰 회사의 기본 기능으로 들어오고 있습니다.앤트로픽의 Claude Cowork도 비슷한 방향입니다.

다른 하나는 도구를 만들어주던 회사들의 위치가 흔들린다는 점입니다. 특정 기능 하나만 잘하는 제품은, 그 기능이 큰 플랫폼에 흡수되는 순간 설 자리가 좁아집니다. 내가 만들고 있는 게 어느 쪽인지 가끔 점검해보면 좋겠습니다.

공식 발표: openai.com/index/codex-for-every-role-tool-workflow

<출처: Figma, Yuhki Yamashita>

3. 적용해볼 것: 누구나 만들 수 있게 됐을 때 진짜 차이를 만드는 것

앞의 두 소식이 보여주는 건 만드는 일이 점점 쉬워진다는 흐름입니다. 그러면 질문이 하나 따라오죠. 누구나 빠르게 만들 수 있게 되면, 무엇으로 차이를 만들까요.

Figma의 최고제품책임자(CPO) Yuhki Yamashita가 이 질문을 정면으로 다룬 글을 Figma 블로그에 올렸습니다. 그는 우버에서 4년 넘게 라이더, 드라이버 앱 개편을 이끌었고, 그 전에는 구글에서 iOS용 YouTube 앱을 맡았던 사람입니다. 글의 요지는 분명합니다. 속도는 이제 기본 조건이 됐고, 진짜 차이는 방향과 완성도에서 나온다는 거죠.

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

상상과 현실 사이의 거리가 거의 사라졌습니다. 떠올린 걸 바로 만들어볼 수 있으니, 빠른 건 당연한 게 됐죠. 문제는 빠른 속도가 착각을 만든다는 데 있습니다. 방향이 틀렸는데 빠르게 가고 있다면, 그건 진전이 아니니까요.

누구나 빠르게 만들면 결과물이 점점 비슷해집니다. AI는 통계적으로 그럴듯한 기본값을 내놓는데, 보기엔 멀쩡하지만 깊이 고민한 결과는 아니거든요. 그 기본값을 의심 없이 받아들이면 그게 그대로 내 제품이 됩니다. 그렇게 다 거기서 거기인 제품이 쌓입니다. Yamashita는 진짜 실패하는 이유가 능력 부족이 아니라 수동성이라고 봅니다. 첫 제안에 그냥 수긍하고, 그럭저럭 괜찮아 보이니 멈추는 태도요.

어떻게 접근하나요?

Yamashita가 제시하는 건 속도, 방향, 완성도 세 가지입니다.

방향을 잡는 방법부터 보겠습니다. 초보 빌더가 자주 빠지는 함정은 첫 아이디어에 매달려 그 주변만 계속 다듬는 겁니다. 출발점을 의심하지 않은 채로요. 반대로 경험 많은 빌더는 선택지를 넓게 펼쳐보라고 하는데, 이건 너무 추상적인 단계에 머물기 쉽습니다. 2x2 표나 와이어프레임만으로는 이게 진짜 되는 아이디어인지 확신이 안 서거든요.

그가 권하는 방법은 넓게 펼치면서 동시에 깊게 파보는 겁니다. 하나만 고르는 대신 서로 다른 방향 여러 개를 띄워놓고, 각각을 실제로 써볼 수 있는 수준까지 만들어보는 거예요. Figma에서는 같은 문제에 대한 인터랙티브 프로토타입을 여러 개 만들어 나란히 놓고, 팀원과 함께 추상적인 안이 아니라 실제 경험을 비교한다고 합니다. 혼자 순서대로가 아니라 여럿이 동시에 일하는 방식이죠. 1번에서 본 다이나믹 워크플로가 여러 AI로 한 문제를 동시에 파고드는 것과 닮은 데가 있습니다.

완성도는 그다음입니다. Yamashita의 표현으로는, 완성도란 받아들이는 게 아니라 고르는 것이고, 기억에 남는 제품과 그냥 굴러가는 제품을 가르는 지점입니다. 각 결정을 다시 들여다보고, 덜어내고 조이고, 이게 정말 맞나 물으면서 관점이 생길 때까지 밀어붙이는 일이에요. 타고난 안목의 문제가 아니라 반복하면서 안목을 길러내는 과정이라는 게 그의 설명입니다.

물론 Yamashita는 디자인 협업 도구를 만드는 회사의 CPO입니다. 완성도를 강조하는 게 Figma의 사업과 맞아떨어지는 면도 있고요. 그 점을 감안하더라도, 누구나 비슷하게 만드는 환경에서 무엇으로 구별될지를 묻는 질문 자체는 곱씹어볼 만합니다.

적용해볼 질문

지금 파고 있는 이 아이디어는, 여러 방향을 비교해보고 고른 건가요, 아니면 처음 떠오른 걸 그냥 붙들고 있는 건가요?
AI가 내놓은 기본값 중에, 내가 의심 없이 그대로 받아들인 건 어떤 게 있나요?
내 제품에서 사람들이 정성을 알아챌 만한 부분은 어디인가요? 있긴 한가요?

실행해볼 수 있는 것

다음에 새 기능이나 화면을 만들 때, 하나만 만들지 말고 방향이 다른 안을 두세 개 만들어 나란히 놓고 비교해보세요. AI를 쓰면 부담이 크지 않습니다.
AI가 처음 내놓은 결과를 그대로 쓰기 전에, 다른 방식은 없을까를 한 번 더 물어보세요. 첫 답에서 멈추지 않는 습관 하나가 결과를 바꿉니다.
이번 주에 만든 결과물 하나를 골라, 덜어낼 수 있는 부분을 세 군데만 찾아 지워보세요. 더하는 것보다 빼는 게 완성도를 만들 때가 많습니다.

원문: figma.com/blog/what-matters-when-anyone-can-build (Yuhki Yamashita, Figma)

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>