요즘IT » 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 모두 무료 오픈소스이고 이미 가진 구독 계정으로 바로 쓸 수 있습니다. 일단 깔아보고 정말 이게 필요한지 봐도 괜찮습니다. 며칠 써 보고 아니다 싶으면 지우면 그만이니까요.

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

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

]]>

모두가 AI 네이티브한다고 하지만, ‘진짜’는 아직 없다

‘AI 네이티브 기업’, 아직 없습니다. 그리고 당분간 생겨나기도 어려울 거라고 생각합니다.

그 이유 중 하나는 바로 ‘업력’입니다. 50년 된 기업에는 50년치 결정들이 켜켜이 쌓여서 그 회사의 운영 방식 자체로 굳어버리게 되죠. 이건 쉽게 다시 쓸 수 있는 게 아닙니다.

그런데 이것조차 표면적인 이유일지도 모릅니다. 어쩌면, 더 근본적인 문제는 바로 기업이 나름의 내부적인 물리 법칙이 작동하는 생태계이고, 그 법칙은 “AI 한번 해봅시다”는 의지 하나로 바뀌지 않는다는 것에 있을 겁니다.

밖에서 보면, 대기업이라는 건 고객, 경쟁자, 수익률에 반응하는 하나의 단일한 조직처럼 보이기도 하지만, 그건 반쪽짜리 관찰에 불과해요. 나머지 절반에는 전혀 다른 논리로 돌아가는 내부 경제 구조가 있습니다.

기업은 ‘돈’을 쓰는 게 아니라 ‘예산’을 씁니다. 예산은 분기별로 나눠지고, 인원수와 FTE(풀타임 환산 인원) 단위로 계산되고, 서로 이해관계가 다른 부서들 사이에 배분되고, 그 구조 위에서 모든 활동이 조직됩니다. 정보는 권력이 되고, 많은 경우에 그 정보를 혼자 쥐고 있는 것이 합리적인 선택으로 보이게 됩니다. 부서마다 자기 영역이 생기고, 그 영역을 지키려고 합니다. 그리고 윗사람을 잘 관리하는 것 자체가 하나의 전문 역량이 됩니다.

모든 조직은 결국 어떤 균형 상태에 도달하고, 그 균형은 변화에 저항합니다. 그 상태가 바로 내부 구성원들이 수십 년에 걸쳐 최적화해온 결과물이기 때문이죠.

똑같은 숫자가 담긴 발표자료가, 어떤 방에서는 박수를 받고 다른 방에서는 싸늘한 반응을 얻는 이유가 바로 여기에 있습니다. 이건 조직의 ‘병리’가 아니라, 오히려 기업의 ‘본질’에 가깝다고 할 수 있습니다. 외부에서는 일사불란한 하나의 조직처럼 보이지만, 그 내부는 각자의 방향으로 움직이고, 영역을 지키고, 협상하고, 살아남으려는 수많은 집단들로 이루어져 있습니다.

“AI 네이티브 혁신”을 다루는 글들 대부분이 이 현실을 무시하기 쉽습니다. 목적지가 어디고, 어디에 도달해야 하는지만 이야기할 뿐이고, 그 여정이 조직이라는 이 거대한 건물을 떠받치고 있는 콘크리트 벽과 기둥을 통과해야 한다는 사실은 간과하는 것이죠.

AI ‘IN’ the business vs. AI ‘ON’ the business

AI를 기업에 적용하는 방식에는 크게 두 가지가 있습니다.

하나는 ‘AI in the business’인데, 이건 제품을 더 잘 만들고, 서비스를 더 효율적으로 제공하고, 고객을 더 잘 응대하는 데 AI를 쓰는 겁니다. 쉽게 말해서 회사가 시장에 내놓는 것들을 더 잘 만들어내는 과정에 AI를 끌어들이는 거죠.

다른 하나는 ‘AI on the business’입니다. 이건 회사 자체가 돌아가는 방식을 어떻게 AI로 혁신할 거냐에 관한 건데요. 누가 무엇을 결정하는지, 예산이 어디로 흘러가는지, 정보가 어떻게 조직의 상부로 올라가는지, 그리고 공식 조직도와 실제 의사결정 구조가 얼마나 다른지, 바로 그 조직의 운영 자체에 AI가 개입하는 거죠.

10명짜리 작은 스타트업에서는 이 두 가지가 구분이 잘 되지 않습니다. 창업자가 직접 코드를 짜면서 동시에 방향도 결정하고 회계 장부도 보죠. 회사 안에서 일어나는 모든 일을 모두가 알고 있습니다.

그런데 5만 명짜리 대기업에서는 이야기가 완전히 달라집니다. 어떤 은행은 최신 AI 사기 탐지 시스템을 출시하면서도, 정작 분기별 계획은 임원 비서들이 이메일로 주고받는 슬라이드로 만들고 커뮤니케이션을 할 수도 있습니다. 어떤 제조사는 창고 물류에 컴퓨터 비전 기술을 도입했으면서도, 인력 예산은 회계연도 초에 FTE 단위로 결정해버리는 방식을 그대로 쓸 수도 있고요. 즉, 파는 제품은 AI 네이티브인데, 회사 자체는 여전히 AI 이전 시대의 방식으로 굴러가고 있을 가능성이 충분히 있다는 겁니다. 겉은 바뀌었는데 속은 그대로인 거죠.

지금 대부분의 기업들이 하는 AI 작업은 이 첫 번째, 즉 ‘AI in the business’에 거의 집중되어 있고, 정작 두 번째인 ‘AI on the business’, 조직 자체가 돌아가는 방식에는 손을 거의 대지 않거나 못하고 있습니다. 수십 년 전에 만들어진 시스템, 몸에 밴 관행, 오래된 의사결정 구조들이 여전히 그대로 살아 있는 거예요.

그래서, 기업에서 던져볼 만한 진짜 질문은 이겁니다. 제품을 바꾸는 것과 조직 자체를 바꾸는 것, 이 두 가지를 어떻게 동시에 해낼 수 있을까요?

AI가 조직 안에서 제대로 작동하려면, 조직의 운영 방식 자체가 AI도 이해하고 따라갈 수 있는 형태로 바뀌어야 합니다. 그런데 문제는, 기업이라는 곳에서는 자기가 아는 것을 굳이 드러내지 않는 게 개인에게 오히려 합리적인 선택인 경우가 많다는 겁니다. 앞선 에피소드에서 이야기했던 바로 그 문제입니다.

그리고, 진짜 거친 싸움이 시작되는 게 바로 그곳이죠.

AI 에이전트는 왜 조직의 숨겨진 권력 구조에 부딪히는가

모든 조직에는 두 개의 지도가 있습니다. 하나는 벽에 붙어 있는 공식 조직도이고, 다른 하나는 실제로 일이 돌아가는 방식입니다. 그리고 대부분의 경우에 이 두 가지는 꽤 많이 다르죠.

사람은 이 두 번째 지도를 본능적으로 찾아냅니다. 메타의 앤드루 보스워스(Andrew Bosworth)는 이걸 체계적인 방법으로 정리했습니다. 새 팀에 합류하면 팀원 한 명 한 명과 30분씩 면담을 합니다. 25분은 “제가 알아야 할 것들을 다 얘기해 주세요”, 3분은 “지금 팀의 가장 큰 문제가 뭔가요”, 마지막 2분은 “또 누구를 만나봐야 할까요”라고 묻습니다. 새로운 이름이 나오지 않을 때까지 그 이름들을 찾아가 똑같이 반복한다고 해요.

이렇게 일주일을 하면, 공식적인 조직도 뒤에 숨어 있는 진짜 조직 지형이 머릿속에 그려진대요. 그리고 능력 있는 신임 임원들은 거의 다 이런 방식을 쓴다고 하고요. 거창하게 이름을 붙이지 않을 뿐이고, 그냥 “적응 기간”이라고 부를 뿐인 이 방식, 꽤 효과가 있다고 합니다.

그런데, AI 에이전트는 이런 방식을 통해서라도 조직의 두 번째 지도를 찾아낼 방법이 없죠.

에이전트는 어딘가에 기록된 것만 읽을 수 있습니다. 경리팀 비용 처리 기준이 담당자 머릿속에만 있다면, 에이전트는 그걸 쓸 방법이 없습니다. 실제 결재를 받으려면 조직도에 나오지 않는 세 사람을 거쳐야 한다면, 에이전트는 조직도에 나온 사람한테만 요청을 보내다가 일을 막아버리게 될 겁니다.

사람이라면 담당자에게 한 번만 물어보면 되지만, 에이전트는 그럴 수가 없습니다. 업무가 돌아갈 때마다, 팀이 바뀔 때마다, 예외 상황이 생길 때마다 매번 그 정보가 필요합니다. 담당자는 한 명인데 에이전트는 수백 개입니다. 결국 에이전트가 제대로 돌아가려면, 조직이 오랫동안 알고 있었지만 굳이 적어두지 않았던 모든 것을 문서로 만들어야 합니다.

그리고 바로 이 순간, 기술의 도입 문제가 조직 내의 권력 문제로 바뀌게 됩니다.

사람이 파악한 조직의 실제 운영 방식은, 그 사람의 머릿속에만 있습니다. 그런데 그것을 에이전트가 쓸 수 있는 문서로 만드는 순간, 상황이 완전히 달라집니다. 담당자만 알고 있던 비용 처리 기준이 누구나 볼 수 있는 정보가 되죠. 실제로는 세 단계를 거쳐야 하는 결재 과정이 공식적으로 드러나고요. 모두가 알면서도 아무도 입 밖에 내지 않던 것들, 특정 거래처에만 적용되는 가격 예외, 관행적으로 처리해온 인보이스 방식, 벤더와의 특약 같은 것들이 에이전트가 읽고 감사인이 들여다볼 수 있는 문서로 남게 된다는 겁니다.

스타트업에서는 이 과정이 상대적으로 수월하겠죠, 아직 그런 담당자가 없기가 쉬울 테니까요. 반면에, 업력이 긴 대기업은 그런 사람들로 가득 차 있습니다. 그들이 나쁜 사람이라는 게 아닙니다. 자신만 아는 정보가 곧 자신의 자리를 지켜주는 조직 안에서, 그냥 합리적으로 행동하고 있는 것뿐입니다.

그런 차이 때문에, 스타트업의 경우에는 아래 표의 L2 수준에까지 상당히 빠르게 도달할 수 있는 반면에, 대기업에서는 그 과정이 너무도 지난한 여정이 되는 상황이 발생합니다.

조직의 AI 성숙도 6단계 (L0~L5) <출처: 튜링포스트>

그러니 AI 도입 과정에서 만나게 되는 저항의 상당 부분은, 기술을 몰라서가 아닙니다. 모든 것이 투명하게 드러나면 지금의 힘의 균형이 깨진다는 것을 사람들이 몸으로 알고 있기 때문인 경우가 오히려 훨씬 더 많습니다.

섀도우 IT, 섀도우 AI, 그리고 섀도우 조직

겉으로 보이는 조직과 실제로 돌아가는 조직은 다릅니다. 그 간극의 절반은 사람들 머릿속에 있고, 나머지 절반은 섀도우 IT 안에 있습니다.

공식적으로 도입한 시스템이 현실을 따라가지 못할 때, 사람들은 기다리지 않고 알아서 방법을 찾습니다. 개발자는 개인 노트북에서 스크립트를 돌리고, 재무팀은 회사 ERP 대신 자기 스프레드시트에 진짜 숫자를 관리하고, 영업 담당자는 회사 CRM 대신 자기가 찾아낸 도구에 실제 영업 현황을 기록합니다. 회사 입장에서는 공식 시스템이 잘 돌아가는 것처럼 보이지만, 실제 업무, 진짜 일은 공식 시스템의 경계 바깥에서 이루어지고 있는 겁니다.

이런 현상을 두고 직원들이 규정을 어기는 문제, 즉 거버넌스의 실패로 규정하는 경우가 많죠. 완전히 틀린 이야기는 아니지만, 이건 대체로 대기업 안에서 실제로 일해본 적 없는 사람들의 시각이기가 쉽습니다.

섀도우 IT는 문제가 아니라 신호거든요. 공식 시스템이 어느 지점에서 현실을 감당하지 못하는지를 정확히 가리키는 지표예요. 그러니까, “섀도우 IT를 어떻게 없앨 것인가”는 처음부터 잘못된 질문입니다. 억누를수록 더 보이지 않는 곳으로 숨어들 뿐이고, 결국 통제는 더 어려워집니다. 올바른 질문은, 어떻게 하면 공식 경로를 섀도우 경로보다 더 빠르고 쓰기 편하게 만들 수 있는가 하는 데서 시작합니다.

지금, AI의 도입 과정에서도 똑같은 일이 벌어지고 있습니다. 회사가 AI 툴 하나를 공식적으로 도입하려면 구매 승인 절차만 몇 달이 걸리는데, 당장 이번 주 안에 분석을 끝내야 하는 직원 입장에서는 개인 계정으로 챗GPT를 열고 회사 문서를 올리는 게 가장 현실적인 선택이죠. 회사의 공식 AI 전략이라는 게 실행 계획도 없이 보고서 한 장으로 끝나 있으니, 중간 관리자는 기다리는 대신 혼자서 클로드(Claude)로 업무 자동화 도구를 만들어 씁니다. 공식 승인을 기다리다가는 언제 될지 모른다 싶은 팀장은 아무 말 없이 에이전트를 실제 운영 데이터베이스에 연결해 버릴 수도 있죠. 지금 이 순간 회사 내부에서 아무도 모르게 돌아가고 있는 ‘비공식 AI’가 얼마나 되는지 정확히 아는 사람, 아마 없을 겁니다.

이게 바로 섀도우 AI입니다. 아마, 수많은 조직에 이미 많이 퍼져 있을 겁니다. 이걸 막겠다는 건, 계획이라기보다는 망상에 가깝습니다.

섀도우 AI가 생겨나는 이유, 그리고 그것을 막는 방법

이런 ‘섀도우 AI’가 생겨나는 이유는 단순합니다. 간단하게 이야기해서, 회사가 공식적으로 제공하는 AI 환경이 너무 느리고 불편하기 때문이에요. 따라서, 해결책도 단순합니다. 회사가 직접 제대로 된 환경을 만들어주면 됩니다. 말은 쉽지만, 실제로 해야 할 일의 목록은 엄청나죠.

그렇지만, 잘 정리해서 크게 보면 세 가지입니다. 무엇을 표준화할 것인가, 그 표준화 기준 아래에 무엇을 갖춰야 하는가, 그리고 문제가 생겼을 때 어떻게 대응할 것인가.

1. 표준화

먼저 표준화입니다. 플랫폼을 하나든, 두 개든, 골라서 밀어붙이세요. 클로드든, GPT든, 제미나이(Gemini)든, 각각 장단점이 있지만 어느 하나가 압도적으로 뛰어난 것도 아니고, 승자가 가려질 때까지 기다릴 이유도 없습니다. 중요한 건 조직 전체가 “우리는 이걸 씁니다, 이게 회사 공식 툴입니다, 교육자료와 문서는 여기 있습니다”라고 말할 수 있는 상태를 만드는 겁니다. 쓰는 툴이 사람마다 다 다른 회사는 사실상 아무 툴도 없는 것과 같습니다.

플랫폼을 골랐다면 그 위에 올라가는 것들도 관리해야 합니다. 스킬, 에이전트, 내부 시스템에 연결하는 MCP(Model Context Protocol) 서버들입니다. 이것들이 없으면 플랫폼은 장난감에 불과하고, 실제 생산성의 혁신을 달성하기가 어렵습니다. 다만 이것들은 하나하나가 회사가 새로 끌어안는 외부 시스템이니만큼, 정식으로 쓰기 전에 검토가 필요하고, 변경될 때마다 다시 여러 관점에서 체크를 해 봐야 합니다. 2년 전만 해도 존재하지 않았던 새로운 종류의 관리 업무가 등장하는 겁니다.

2. 갖춰야 할 것들

다음은 그 아래에 갖춰야 할 것들입니다. 에이전트가 한 모든 행동은 나중에 다시 들여다볼 수 있어야 합니다. 언제, 누가 요청해서, 어떤 데이터를 넣었고, 어떤 판단을 거쳐서, 어떤 결과를 냈는지, 사람이 개입했다면 어느 단계에서 했는지까지 전부 기록으로 남아야 합니다. “에이전트가 환불을 처리했습니다”가 아니라, 법적 분쟁이 생겼을 때 법정에 제출할 수 있고, 개인정보 열람 요청에 답할 수 있고, 금융감독 기관의 요청에도 내놓을 수 있는 수준의 기록이어야 합니다. 기록을 남기는 것 자체는 어렵지 않을 수 있지만, 법적으로 유효한 수준으로 남기는 건 전혀 다른 이야기이고, 이 작업의 규모를 제대로 가늠한 기업은 아직 거의 없습니다.

고객 데이터 문제도 미리 답을 준비해야 합니다. 고객 데이터가 모델 제공업체 서버로 넘어가고 있나요? 그 데이터가 모델 학습에 쓰이고 있지는 않나요? 그렇지 않다는 걸 실제로 증명할 수 있나요? 데이터가 어디에, 얼마 동안, 어느 나라 법의 적용을 받으며 저장되나요? 요즘 고객사 계약서에는 2년 전만 해도 없던 조항들이 빼곡히 들어가 있고, 제대로 된 법무팀이 있는 고객이라면 반드시 짚고 넘어가는 사항들입니다.

말로만 “우리는 고객 데이터로 학습하지 않습니다”라고 해서는 안 됩니다. 실제로 그렇게 설정되어 있어야 하고, 그 설정을 언제든 확인해 보여줄 수 있어야 합니다. 지금 대부분의 기업은 이걸 증명하지 못합니다.

문서 보안 등급 문제도 있습니다. 사람이 기밀 문서 다섯 개를 읽고 요약을 쓰면, 그 요약은 원본 문서와 같은 보안 등급을 갖습니다. 에이전트가 같은 문서 다섯 개를 읽고 요약을 쓰면, 그 요약의 보안 등급은 무엇인가요? 다섯 개 중 네 개에는 접근 권한이 있지만 한 개에는 없는 사람이 에이전트를 돌렸다면 어떻게 되나요? 사람을 대상으로는 수십 년에 걸쳐 이미 정리된 문제들입니다. 정보를 읽고, 섞고, 가공해서 내보내는 에이전트를 대상으로는 아직 정리되지 않았습니다.

에이전트의 신원과 권한 문제도 마찬가지입니다. 에이전트가 어떤 작업을 실행할 때, 그건 누구 자격으로 하는 건가요? 요청한 사람의 권한을 그대로 물려받나요, 아니면 에이전트 자체의 계정으로 하나요? A라는 직원이 요청한 에이전트가 B만 볼 수 있는 자료에 접근하려 하면 어떻게 되어야 하나요? 지금까지 회사 시스템의 접근 권한 체계는 전부 사람을 기준으로 설계되어 있었습니다. 이제 그 체계가 사원증도 없고, 상사도 없고, 인사 평가도 받지 않는 에이전트들까지 아우를 수 있도록 바뀌어야 합니다.

3. 사고 대응

마지막은 사고 대응입니다. 에이전트가 잘못된 일을 했을 때 어떻게 할지를 미리 정해두어야 합니다. 누가 먼저 보고를 받나요? 이미 실행된 작업을 어떻게 되돌리나요? 이미 고객에게 나간 이메일, 처리된 결제, 변경된 데이터는 어떻게 하나요? 고객에게는 어떻게 알리나요? 최종 책임은 누가 지나요? 대기업에서 에이전트가 처음으로 큰 사고를 냈을 때, 아무도 생각해두지 않았던 질문들이 한꺼번에 쏟아질 텐데, 그 전에 미리 시나리오를 만들고 점검해두는 편이 훨씬 낫습니다.

고객에게 하는 약속도 실제로 지킬 수 있는 것만 해야 합니다. “고객 데이터로 학습하지 않습니다”, “동의 없이 외부 모델에 데이터를 보내지 않습니다”, “요청하면 삭제해 드립니다”, “AI가 고객 계정과 관련해서 한 모든 행동의 기록을 제공할 수 있습니다”. 이것들은 이제 웬만한 기업 고객의 구매 심사 서류에 기본으로 들어가는 항목들입니다. 이걸 실제로 이행할 체계를 갖추거나, 아니면 그 고객의 사업을 포기하거나, 둘 중 하나입니다. 지금 대부분의 기업은 일부 경우에 대해서만, 그것도 제대로 지켜지지 않는 방식으로 갖추고 있는 게 현실입니다.

자, 이런 것들이 실제로 실행해야 할 일들입니다. 어떤 AI 전략 보고서도, 플랫폼을 파는 벤더도 이 일들이 얼마나 중요한지, 그리고 얼마나 어려울 수 있는지 솔직하게 말하지 않습니다. 하지만, 이것이 바로 ‘AI on the business’가 실제로 어떤 모습인지에 대한 답이기도 합니다.

직원들이 회사 몰래 AI를 쓰는 이유는 회사가 이 일들의 무게를 아직 감당하지 못하고 있기 때문이고, 현장에서는 기다릴 여유가 없기 때문입니다. 회사가 이 무게를 실제로 감당할 수 있을 때, 그리고 그것이 섀도우 AI보다 빠르고 편할 때, 비로소 직원들은 굳이 다른 길을 찾지 않겠죠. 더 안전하기만 해서는 부족합니다. 더 빠르고 편해야 합니다.

기존의 잣대로는 AI 시대의 가치를 잴 수 없다

섀도우 AI를 막을 환경을 갖추는 것만으로 끝이 아닙니다. 그것과는 별개로, 더 근본적인 문제가 기다리고 있습니다. 이것도 플랫폼 벤더들이 아직 잘 꺼내지 않는 문제인데, 그들 입장에서는 똑 부러진 해결책이 아직은 없기 때문이기도 해요. 이 문제는 바로, 기업이 지금껏 가치를 측정하고 돈을 받아온 방식 자체가 AI 시대에는 더 이상 맞지 않는다는 겁니다.

컨설팅이나 법무 같은 서비스 업종은 오랫동안 시간 단위로 요금을 청구해왔습니다. 따지고 보면 시간이란 가치를 재는 단위가 아니라 비용을 재는 단위입니다. 더 나은 기준이 없었기 때문에 업계 전체가 암묵적으로 시간을 가치의 대용으로 써온 겁니다. 80시간짜리 분석 작업을 에이전트가 40분 만에 해치우는 순간, 이 오래된 합의가 무너집니다. 40분에 대해 기존 시간당 요율로 청구하면 말이 안 되고, 실제로 하지도 않은 80시간을 청구하는 것도 말이 안 됩니다. 만들어낸 가치는 분명히 존재하는데, 그것을 청구서에 담을 방법이 없습니다.

디자인 업종은 결과물 단위로 청구해왔습니다. 완성된 PDF, 피그마 파일, 브랜드 가이드라인. 이 결과물들은 그 안에 녹아든 생각과 판단의 대가로 받는 돈이었습니다. 그런데 사람과 에이전트가 함께 작업해서 하룻밤 사이에 결과물이 나오면, 이 공식도 흔들립니다. 견적을 어떻게 내는지, 가격을 어떻게 정하는지, 누구를 채용하고 어떻게 교육하고 어떻게 승진시키는지, 이 모든 것이 사람이 일정한 속도로 결과물을 만들어낸다는 전제 위에 세워져 있었기 때문입니다.

소프트웨어 업종은 사용자 수 단위로 요금을 받아왔습니다. 직원 한 명에 계정 하나, 월정액 요금제 하나. 그런데 에이전트는 사람이 아닙니다. 스스로 돌아가고, 여러 개가 동시에 늘어나고, 사람 수로는 도무지 셀 수 없는 방식으로 작동합니다. 기업 간 소프트웨어가 기업과 에이전트 사이의 소프트웨어로 바뀌고 있는데, 요금 체계도, 보안 체계도, 신원 확인 방식도, 고객 지원 방식도 전부 다시 짜야 하는 상황입니다.

기업에는 수십 년에 걸쳐 켜켜이 쌓인 운영 체계가 있습니다. CFO의 실적 예측, 구매 조달 정책, 인사팀의 인력 계획, 영업팀의 성과 보상 구조. 이것들은 모두 인원수, 투입 시간, 사용자 수, 결과물 수, 분기 예산이라는 단위로 돌아갑니다. 그런데 AI가 만들어내는 가치는 이 단위들 중 어느 것으로도 잘 잡히지 않습니다. CFO는 기존 방식으로 계획을 세울 수 없고, 구매팀은 기존 방식으로 도입 승인을 할 수 없고, 인사팀은 기존 방식으로 인력을 배치할 수 없습니다. 가치는 분명히 만들어지고 있는데, 그것을 재는 도구가 이전 시대의 것입니다.

결국 문제는 여기서 하나로 모입니다. 에이전트가 조직의 일원으로 제대로 작동하려면, 지금 인사 시스템이 사람에게 해주는 것들과 같은 성격의 관리 체계가 에이전트에도 필요합니다. 누구인지 확인하고, 무엇을 할 수 있는지 정하고, 무엇을 했는지 기록하고, 누가 책임지는지 정하고, 더 이상 필요하지 않을 때 어떻게 정리할지까지.

거의 모든 플랫폼 벤더는 에이전트가 돌아가는 엔진만 팝니다. 그 엔진이 회사 안에서 제대로 작동하게 만드는 환경, 즉 신원 관리, 권한 체계, 행동 기록, 사고 대응 절차를 에이전트에 맞게 갖추고 운영하는 것은 기업 스스로 해야 합니다.

별도 조직을 만드는 것도 대부분 실패한다

요즘 테크 언론에서 자주 나오는 조언이 있습니다. 바로 ‘AI 네이티브 자회사’를 따로 만들라는 겁니다. 사실 저도 대기업에서 AI 전환을 담당하시는 임원분들께 가끔 이런 이야기를 하기도 하는데요. 기존 조직의 낡은 시스템에 발목 잡히지 말고, 작고 빠른 팀을 새로 꾸려서 처음부터 AI 중심으로 설계하라는 것이죠.

솔깃한 이야기이고, 실제로 잘 되는 경우도 있습니다. 하지만 대부분은 이렇게 됩니다. 팀은 빠르게 움직이지만, 정작 필요한 것들, 즉 고객 데이터, 실제 매출, 핵심 시스템에는 접근할 수 없는 경우가 아주 많아요. 그런 중요한 요소들은 여전히 기존 조직 안에 있고, 기존 조직은 새로운 것이 자기 영역을 침범하면 본능적으로 밀어냅니다. 협력한다고 하지만 실제로는 아무것도 공유되지 않습니다.

결국 그 팀이 하는 일은 이사회 보고용 데모를 만들고, 그럴듯한 화면을 캡처하고, 보고서에 들어갈 성과를 포장하는 것으로 끝나게 됩니다. 그 결과, 실제 사업에 영향을 주는 시스템은 하나도 나오지 않습니다.

진짜 AI 전환은 그런 방식으로 되지 않습니다. 기업의 AI 전환은, 궁극적으로 기존 조직을 안에서부터 바꾸는 일입니다. 조직이 어떻게 돌아가는지를 AI도 이해할 수 있는 형태로 만들고, 직원들이 몰래 쓰는 AI보다 회사가 공식적으로 제공하는 AI 환경을 더 빠르고 편하게 만들고, AI가 만들어내는 가치를 조직이 실제로 인식하고 측정할 수 있도록 운영 방식을 바꾸는 일입니다. 느리고, 돈이 많이 들고, 조직 내부의 저항과 싸워야 하는 일이지만, 이것 말고는 방법이 없습니다.

지금 당신이 기업에서 AI 기반의 혁신을 이끄는 분이라면, 자회사를 만드는 것보다 훨씬 효과적일 수 있는 방법이 있습니다. 바로, 실제 권한을 가진 내부 AI 팀을 꾸리는 겁니다. 여기서 ‘권한’이 중요합니다. 자문만 하는 위원회로 만들면 안 되고, AI 전도사 한 명을 세워두는 것도 안 됩니다. 예산을 쥐고, 결정을 내리고, 회사가 쓰는 AI 툴과 그 운영 방식 전반에 대한 실질적인 책임을 지는 엔지니어링 팀이어야 합니다. 그 팀이 회사의 AI 환경을 섀도우 AI보다 빠르고 편하게 만들면, 나머지는 자연스럽게 따라옵니다.

모든 기업이 이것을 해낼 수 있을지는 솔직히 모르겠습니다. 어떤 기업은 기존 방식을 완전히 버리고 처음부터 다시 시작해야 할 겁니다. 어떤 기업은 10년에 걸쳐 두 가지 방식을 병행하다가 서서히 하나로 합쳐갈 겁니다. 어떤 기업은 결국 살아남지 못하겠죠.

살아남는 기업들의 공통점은 하나입니다. 좋은 AI 제품을 샀거나, 유능한 AI 책임자를 임명해서 되는 게 아니라, ERP 도입, 클라우드 전환, 디지털 트랜스포메이션 때도 그랬듯이, 화려하지도 않고 빠르지도 않지만 조직의 뼈대를 바꾸는 구조적인 작업을 실제로 해낸 기업들입니다. 컨설팅 업계는 종종 이걸 그럴듯한 방법론으로 포장하려 하지만 매번 실패합니다. 이건, 포장할 수 있는 종류의 일이 아니기 때문입니다.

진짜 분기점

오랫동안, 엔터프라이즈 AI를 둘러싼 논의는 결국 ‘제품 선택의 문제’로 귀결되어 왔습니다. 어떤 모델을 쓸 것인가, 어떤 벤더를 고를 것인가, 어디서부터 시작할 것인가. 맞는 것을 고르면 나머지는 따라온다고들 생각한 거죠.

물론, 틀린 말은 아니지만, 기업에게 진짜 중요한 질문은 거기에서 찾을 수 없습니다. 기업이 목표로 삼고 통과해야 할 진짜 분기점은 다른 곳에 있습니다. 바로, 조직이 실제로 어떻게 돌아가는지를 있는 그대로 드러낼 수 있느냐, 없느냐입니다. 지금까지 누군가의 머릿속에만 있던 것들, 관행적으로 처리해온 것들, 모두가 알지만 아무도 공식적으로 인정하지 않던 것들을 AI가 읽고 실행할 수 있는 형태로 만드는 것을 감당할 수 있는 기업과, 그렇지 못한 기업 사이에 선이 그어집니다.

정보를 쥐고 있는 것이 힘이던 시절에는, 드러내지 않고 쌓아두는 것이 합리적인 선택이었습니다. 그런데 AI를 제대로 활용하려면 조직의 작동 방식이 투명하게 열려야 하는 시대에는, 그 오래된 전략이 오히려 짐이 됩니다. 이 전환을 먼저 해내는 기업들은 상당한 경쟁 우위를 오랫동안 향유하게 될 것이고, 기존의 운영 방식을 놓지 못하는 기업들은 그것을 지키는 데 앞으로의 10년을 쓰게 되고, 결국은 소멸의 길을 걷게 될 겁니다.

‘AI in the business’는 그나마 쉬운 절반입니다. 진짜 어려운 것은 ‘AI on the business’입니다. 이 둘의 차이를 이해하고, 그 과정에서 필연적으로 맞닥뜨리는 내부 저항과 정치적 마찰을 감수할 의지가 있는 기업들이 10년 후에도 살아남을 겁니다.

<원문>

모두가 AI 한다고 하지만, 진짜 AI 네이티브 기업은 아직 없다

]]>

클로드 코드 길들이기: 6인의 실제 사례집 출시

클로드 코드(Claude Code)가 꾸준히 사랑받는 이유는 무엇일까요?

아마 개발 지식과 상관없이 뚝딱 짜주는 코드 때문일 수도 있고, 복잡한 작업을 대신 처리해주는 편리함 때문일 수도 있습니다. 그런데 실제로 클로드 코드를 오래 써온 분들에게 물어보면, 답은 조금 다른 곳에서 나옵니다. 이 도구가 좋은 진짜 이유는, 쓰는 사람마다 자기 방식대로 "길들일" 수 있다는 데 있다고들 합니다.

스킬로 반복되는 업무를 자동화하고, CLAUDE.md로 맥락을 관리하고, 팀 전체의 표준으로까지 확장하는 방식으로 말이죠. 물론 사람마다, 팀마다 환경은 다를 겁니다. 그만큼 자신에게 맞는 방식을 찾기까지 시행착오도 따를거고요. 그렇다면 “어떻게 클로드 코드를 길들여야 할까요?”

요즘IT는 이 질문에 힌트가 될 만한 이야기들을 모아봤습니다. 지난 5월 27일과 6월 10일, 두 차례에 걸쳐 클코나잇 시즌2 웨비나가 진행됐는데요. 여기서 발표자로 참여한 프리랜서 개발자, 대기업 비개발자 PM, 1인 빌더, AI 스타트업 CTO, AX 기획자, BizOps 리드까지. 클로드 코드를 실무에서 각자의 방식으로 길들여 온 6인이 직접 부딪히고 배운 것들을 한 권의 사례집과 발표 영상으로 엮어봤습니다.

참고로 이들의 이야기는 완벽한 성공담보다는 삽질하고, 실패하고, 다시 시도하는 과정 속에서 배운 점, 그렇게 자신만의 방식 혹은 팀의 방식을 찾아간 과정에 가깝습니다. 이번 글에서는 사례집에 담긴 이야기 중 두 가지만 먼저 소개해 드리겠습니다.

전국 30개 캠퍼스의 정산 이의제기, 두 번의 피벗 끝에 5일 만에 뒤집은 이야기

IT 교육기업 AX 전략팀에서 기획자로 일하는 이현 님의 이야기입니다.

그가 맡은 첫 AX 과제는 슬랙 기반의 정산 비효율을 해결하는 일이었습니다. 전국 30개 이상의 캠퍼스가 저마다 슬랙 채널로 정산 업무를 처리하다 보니, 전체 현황이 한눈에 보이지 않았고, 사람이 손으로 계산하니 오류가 났고, 그 위에서 이의제기가 반복됐습니다. 그런데 피그잼으로 업무 흐름을 하나하나 뜯어보고 현장 데이터를 들여다보니, 진짜 병목은 예상과 다른 곳에 있었습니다. 본사가 통보한 정산값에 대한 이의제기와 확인 절차, 바로 그 지점이었죠. 그는 여기서 "이의제기 자체가 생길 수 없는 구조"라는 기획으로 방향을 잡았습니다.

문제는 이걸 무엇으로 구현하느냐였습니다. 처음엔 슬랙 안에서 해결하려 했지만 현장 반응이 좋지 않았습니다. 다음엔 노코드 툴을 조합해 봤지만, 툴 간 의존성과 하드코딩 이슈에 부딪혔습니다. 두 번의 피벗 끝에 그가 선택한 건 클로드 코드였고, 놀랍게도 여기서부터는 5일이면 충분했습니다.

런칭까지는 순조로웠습니다. 그런데 배포 다음 날, "로그인이 느리다"는 피드백이 들어왔습니다. 코드에는 문제가 없었습니다. 문제는 코드 밖, 인프라의 기본값에 숨어 있었습니다.

비개발자였던 그는 이 문제를 어떻게 알아챘고, 또 어떻게 해결했을까요? 두 번의 실패를 거듭한 피벗이 오히려 5일 런칭의 발판이 된 이유는 무엇이었을까요? 자세한 과정은 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

업무 프로세스 맵보다 현장 데이터를 먼저 봐야 하는 이유, 그리고 진짜 병목을 찾아낸 과정
슬랙 → 노코드 → 클로드 코드, 두 번의 피벗을 거치며 MVP를 좁혀나간 전체 흐름
5일간의 실제 작업 순서 (Day1 빌드 → Day2~3 검증 → Day4 사용자 교육 → Day5 배포)
배포 다음 날 터진 로그인 지연 이슈와 원인을 알아챈 과정
클로드 코드의 첫 제안을 그대로 따르지 않고 도메인 지식으로 역제안해, 로그인 속도를 80% 개선한 방법

1인 개발자가 혼자서 9개 프로젝트를 굴리게 된 이야기

1인 빌더로 활동하는 김상욱 님의 이야기입니다.

그는 원래 한 스타트업의 백엔드 개발자였습니다. 프론트엔드 채용이 안 돼서 얼떨결에 프론트까지 혼자 맡게 됐고, 그렇게 익숙해지던 차에 갑작스레 해고를 당했습니다. 다시 취업 준비를 하거나, 뭐라도 혼자 만들어 보거나의 선택에서 그는 후자를 택했고, 그때 처음 클로드 코드를 만났습니다.

혼자서 만드니 속도가 달랐습니다. 예전엔 MVP 하나에 1~2주씩 걸렸는데, 이제는 단 몇 시간이면 나왔죠. 신이 나서 계속 프로젝트를 찍어냈고, 손에 쥔 프로젝트가 순식간에 아홉 개로 불어났습니다. 초등학교 학급 경영 서비스, 진정서를 자동으로 써주는 서비스, 방치형 RPG 게임, 웹소설 팬 위키까지, 만드는 것만큼은 정말 쉬웠습니다.

문제는 그 다음이었습니다. 세션을 켤 때마다 "내가 어디까지 했더라?"를 매번 다시 더듬어야 했고, 같은 지시를 프로젝트마다 반복해서 입력해야 했습니다. 어제 바로잡은 실수를 오늘 또 저지르기도 했죠. 그는 "만드는 건 쉬워졌지만, 만드는 것에서 끝이 아니구나"를 깨달았다고 말합니다. 그리고 이 문제를 하나씩 시스템으로 풀어, 지금은 혼자서 한 컴퓨터로 13개의 프로젝트를 굴리고 있습니다.

어떻게 가능했을까요?세션이 늘어날수록 관리 비용도 함께 늘어나지 않았을까요? 어떻게 혼자서 프로젝트를 13개까지 유지할 수 있었을까요? 고민 끝에 그가 만든 다섯 가지 장치, 그리고 선택과 집중에 대해서는 사례집에서 직접 확인해 보세요.

사례집에서 확인할 수 있는 것들

세 가지 통증(진행 상황 까먹기·같은 지시 반복·같은 실수 반복)을 각각 다른 장치로 해결한 방법
home/CLAUDE.md 하나로 13개 프로젝트의 맥락을 관리하는 실제 구조
"핸드오프"라는 한마디로 세션 전환 비용을 0으로 만드는 방법과, 이걸 CLAUDE.md에 규칙으로 적용하는 법
세션을 시작하고 끝낼 때 실제로 어떤 순서로 작업하는지와 그가 만든 다섯가지 장치
AI에게 정답 대신 컨텍스트를 던지고 함께 답을 찾는 실제 작업 방식

이 두 이야기 외에도, 4명의 실무자가 각자의 자리에서 부딪히고 배운 기록이 사례집에 담겨 있습니다. 어떤 내용들이 있는지 아래에서 함께 살펴보겠습니다.

클로드 코드 길들이기: 6인의 실제 사례

요즘IT는 지난 5월 27일과 6월 10일, 두 차례에 걸쳐 온라인 웨비나 ‘클코나잇 시즌2’를 진행했습니다. 시즌1이 "클로드 코드로 일하는 법"을 다뤘다면, 시즌2는 그 다음 단계를 다룹니다. 처음엔 개인의 생산성 도구였던 클로드 코드로 나만의 워크플로우를 만들고, 나아가 팀과 서비스 단위로 확장하는 이야기입니다.

이 사례집은 그 웨비나의 기록으로, 완벽하게 다듬어진 강의가 아니라, 현업에서 직접 부딪친 실무자들의 시행착오와 성공기를 솔직하게 담았습니다. 발표 후 이어진 현장 Q&A도 사례집에 함께 담아, 독자들의 궁금증을 해소하고자 했습니다.

클로드 코드에서 스킬을 묶어 워크플로우 자동화하기 _김규동 / 프리랜서 개발자
코딩 말고 일: Repo를 세컨 브레인으로 1년 굴린 이야기 _정덕범 / 라인플래닛 프로덕트 매니저
1인 빌더가 클로드 코드로 프로젝트 9개 운영한 방법 _ 김상욱 / 1인 빌더

PART 2. 클로드 코드를 우리 팀, 서비스에 맞게 확장하기

클로드 코드로 5일 만에 웹 포털 런칭한 방법 _ 이현 / IT 교육기업 AX 전략팀 기획자
우리 개발팀 맞춤 하네스 엔지니어링 구축하기 _ 김영채 / VIBERS AI CTO
AI 도구 26개를 직접 만들며 알게 된 자동화 노하우 _김현민 / 스파르타 게임즈 BizOps Lead

부록

클로드 코드 핵심 용어 사전
발표에서 언급된 플러그인·스킬 레퍼런스
CLAUDE.md / PRD.md 샘플 템플릿
오늘 바로 따라해 보는 체크리스트

※ [추가 안내]
클코나잇 시즌 2 웨비나에 함께해 주신노성현 님,이용학 님의 콘텐츠는 부득이하게 이번 사례집에 담지 못했습니다. 대신 요즘IT 콘텐츠로 만나보실 수 있습니다.

상품 구성

“PDF 사례집만 보고싶어요”

PDF 단품/ ~~16,000원~~ ▶ 할인가 13,500원

“발표 영상까지 함께 보고싶어요”

PDF + 발표 영상 ~~40,000원~~ ▶ 할인가 29,000원 (★추천)

“기업(팀)에서 같이 보고싶어요”

기업(팀) 구매(PDF + 발표 영상) ~~70,000원~~ ▶ 할인가 59,000원 (*10인 이내)

이제 클로드 코드를 "쓸 줄 아는" 사람은 많아졌습니다. 관건은 내 워크플로우 안에 얼마나 녹여내는지, 그리고 개인을 넘어 팀으로까지 옮길 수 있는지입니다. 프리랜서 개발자든, PM이든, CTO든, 결국 부딪히는 질문은 같습니다. “나 그리고 우리 팀에 맞게 어떻게 길들일 것인가” 이 질문에 대한 힌트를 지금 사례집에서 확인해 보세요.

[클로드 코드 길들이기: 6인의 실제 사례] 보러 가기

]]>

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

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

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

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

써볼 것: 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로 만든 걸 서비스에 쓴다면, 앞으로 이런 표시와 관련한 규정이 나라마다 생길 수 있다는 걸 미리 알아두세요. 지금은 유럽이 앞서 있지만, 이런 흐름은 대개 번져갑니다.

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

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

]]>

그록 4.6 + 그록 봇 = 스페이스X > 구글?

그록이 치고 나왔습니다.

8월 11일에 상시 업무 에이전트 그록 봇(Grok Bot), 8월 12일에 새 모델 그록 4.6이 등장했습니다. 이걸 만든 회사의 이름은 이제 xAI가 아닙니다. 로켓 회사 스페이스X입니다. xAI는 올해 초 스페이스X에 흡수됐고, 6월에는 커서(Cursor) 개발사 애니스피어를 600억 달러 전액 주식으로 사들인다고 발표했죠. 모델을 만드는 xAI와 코딩 도구 커서, 로켓과 위성을 한 회사가 만드는 겁니다.

사실 그전까지 그록이 새 모델을 낼 때마다 머스크가 “이번엔 다르다”고 한 말은 대개 마케팅에 가까웠습니다. 그런데 이번엔 마케팅이 아닐 수도 있습니다. 값싼 프론티어급 모델과 누구나 쓰는 에이전트가 진짜 나왔거든요. 마침 구글이 흔들리는 지금, 정말 그록이 1등 후보가 되는 날이 올까요?

GPT-5.6 솔 급이라는 그록 4.6

그록 4.6 출시 <출처: SpaceX>

그록 4.6이 자랑한 건 두 가지입니다.

하나는 여러 단계의 일을 오랜 시간 붙들고 가는 장시간 에이전트 작업, 다른 하나는 화면/인터랙션 만들기죠. 요즘 모델을 고르는 기준이 “얼마나 똑똑한가”에서 “일을 통째로 맡겨도 되는가”로 바뀌고 있어서, 그에 따라 포인트를 잡은 것 같습니다.

성능

스페이스x 발표 기준으로는 GPT-5.6 솔과 비슷한 수준이라고 합니다. 이런 자사 벤치마크는 대개 어느 정도 걸러 듣게 되지만요, 측정기관 아티피셜 애널리시스(Artificial Analysis)의 지능 지수에서 61점으로 GPT-5.6 솔과 같은 점수를 받았습니다. 오퍼스 5가 63점, 페이블 5가 62점으로 최상위보다는 한두 점 아래지만 프론티어 라인에 올라선 건 맞습니다.

어찌되었든 GPT-5.6 솔, 페이블5와 벤치마크 수치들을 나란히 세우는 거 자체가 큰 발전입니다.

그록 4.6 벤치마크 <출처: SpaceX>

가격

진짜 눈여겨볼 대목은 가격입니다. 입력 100만 토큰당 2달러, 출력 6달러. 지금 최상위권 모델들과 나란히 놓으면 이렇습니다.

GPT-5.6 솔과 비교하면 입력은 절반 이하, 출력은 5분의 1입니다. 페이블 5와 놓고 보면 출력 기준으로 8분의 1 수준까지 떨어지고요. 그록 4.6 혼자 자릿수가 다릅니다.

훈련 방식

훈련 방식에서 재미있는 얘기도 나왔습니다. 담당 팀은 그록 4.6이 내부 모델 개발 업무 자체를 학습 과제로 삼은 첫 모델이라고 밝혔는데요.

이게 실제로 먹히는지 보려고, 학습 중간 버전에 자사 프로덕션 추론 코드를 통째로 넘기고 완전 자동화 환경에서 돌려 봤다고 합니다. 5시간 동안 297개 최적화 후보를 훑어 PR 7건을 올렸고, 그중 3건이 지금 그록 챗 트래픽을 처리하고 있습니다. prefill 3.1%, decode 1.5% 개선이고요. 297개 중 3건이면 타율은 낮지만 자동화 환경에서 나온 반영이라는 게 요점입니다. 이런 순환이 돌기 시작했다는 게 흥미롭습니다.

사용 환경

오늘부터 바로 쓸 수 있습니다. 커서, 그록 빌드, 그록 봇, API 같은 연계 제품이랑 오픈라우터, 버셀, 클라우드플레어 등 외부에서도 쓸 수 있습니다. 커서를 쓰고 있다면 이미 골라 쓸 수 있는 상태고요. 첫 주에는 이벤트 느낌으로 사용량을 2배 더 제공한다고 합니다.

그런데 어쩌면 모델보다 더 중요한 건 하루 앞서 나온 이쪽입니다.

그록 봇: 챗봇 아닙니다, 에이전트입니다

8월 11일에 얼리 베타로 나온 그록 봇 얘기입니다. 이름만 보면 챗봇 같지만, 실제로는 상시 업무 에이전트에 가깝습니다.

그록 봇 <출처: SpaceX>

동작 구조: 클라우드에 컴퓨터 하나씩 + 직접 로그인해 화면을 조작

공식 포스트가 설명하는 동작 방식은 이렇습니다.

봇마다 클라우드에 자기 컴퓨터를 하나씩 갖습니다.
이 봇들이 내가 쓰는 도구에 직접 로그인해 사람처럼 화면을 조작하죠. 그래서 API 연동이 없는 서비스도 씁니다.
노트북을 닫아도 클라우드에서 계속 돌아갑니다. 그러다 승인이 필요한 순간에만 물으러 돌아오고요.
한 번 시연해 보이면 루틴으로 저장돼서 다음부턴 알아서 반복합니다.

즉, 메신저로 말을 시켜 두면 알아서 일하고 필요할 때만 물으러 오는 방식입니다.

지시도 대화로 하고 보고도 대화로 받으니 쓰는 사람 입장에선 원격에서 일하는 어시스턴트를 한 명 두는 거에 가깝겠죠. API가 뚫려 있지 않은 사내 시스템이나 오래된 웹 서비스에도 붙는다는 게 기존 자동화 도구와 갈리는 지점이고요. 그러니 개발보다는 비개발자의 반복 업무 쪽에 좋아 보입니다.

사용 환경

요금은 개인 월 200달러(커서 울트라), 팀 플랜으로는 인당 월 120달러입니다. 기존 슈퍼그록 헤비(월 300달러) 가입자도 쓸 수 있고요. 맥·윈도우·리눅스·iOS를 지원하며, 안드로이드는 출시 예정입니다.

월 200달러부터 시작이니 사실 좀 꺼려지긴 합니다.

그래서 찾아본 후기

그래서 직접 써 본 사람들의 후기에 눈이 가는데요.

가장 크게 퍼진 건 레니 라치츠키(Lenny Rachitsky)의 후기입니다. 프로덕트 업계에서 ‘레니의 뉴스레터’로 유명한 그 사람이죠. 얼리 액세스로 써 봤다는 그는 “한동안 이렇게까지 신났던 AI 제품이 없었다”고 했습니다. 오픈클로와 비슷한데 훨씬 쉽고, 안정적이고, 덜 무섭다는 평가고요. 구직자와 채용 중인 회사 짝지어 주기, 고객 지원 메일 자동 응답(몇 시간을 아꼈다고 합니다), 카드 명세서를 훑어서 해지할 정기 구독 찾아내기, 다음 팟캐스트 게스트 브리핑 문서 만들기 등을 시켰다고 합니다. 개발과는 아무 상관 없는 목록이죠.

제품을 아예 뜯어본 후기도 있습니다. 쿤 첸(Kun Chen)은 하루를 붙들고 일을 시켜 본 뒤 구조까지 역추적해 정리했는데요. 사용자마다 클라우드에 리눅스 VM이 하나씩 주어지고(8 vCPU·메모리 16GB·디스크 128GB), 맥 앱과 iOS 앱은 그 VM 속 봇과 대화하는 얇은 껍데기라고 합니다. 봇들은 이 VM을 함께 쓰지만 각자 자기 가상 데스크톱을 가져서 화면 조작이 서로 부딪히지 않고요. 이 정도 사양으로 감당이 안 되는 무거운 코딩 작업은 커서 클라우드 에이전트로 넘어갑니다. 그의 총평은 “일부러 깊게 만든 다음 단순한 인터페이스 뒤에 잘 숨겨 놓은 제품”이었습니다.

그록 4.6 + 그록 봇 출시의 진짜 의미

모델이 아닌 “AI 종합 세트”

중요한 건 값싸고 좋은 모델에 붙은 게 코딩 에이전트가 아니라 누구나 쓰는 에이전트라는 점입니다. 개발자용 도구는 사실 이미 클로드 코드와 코덱스가 꽉 잡고 있습니다. 커서도 있고요. 그러니 이 에이전트는 그 외의 영역, 그러니까 매일 반복되는 업무를 겨냥합니다. 그렇다고 커서를 완전 대체하는 그림은 아닙니다. 무거운 코딩 작업은 그록 봇이 커서 클라우드 에이전트로 넘긴다고 해요. 가벼운 일은 봇이 직접 하고 무거운 일은 전용 도구로 보내는 병행 구도입니다.

사실 이런 상시 범용 에이전트 자체는 완전 새로운 건 아닙니다. 2026년 들어 챗GPT 워크, 클로드 코워크, 제미나이 스파크가 몇 달 사이에 줄줄이 나왔으니까요. 다들 이런 형태의 에이전트가 다음이라고 본다는 뜻입니다. 코딩에서 검증된 에이전트 방식이 일반 업무로 번지고 있죠.

이를 다시 말하면, AI 프론티어 경쟁이 이제 모델 단품 싸움에서 벗어나고 있다는 뜻입니다. 컴퓨팅, 데이터, 개발 도구에다 업무 에이전트를 모두 만드는 회사들로 판이 재편되고 있다고요.

그리고 스페이스X는 그걸 이틀 만에 주루룩 공개한 겁니다. 모델 성능표에서 1위를 다투는 것과는 종류가 다른 경쟁입니다. 어느 쪽 종합 세트가 먼저 일상 업무에 들어가냐의 싸움이죠.

어떻게 이런 일이 가능했을까

후발주자인 스페이스X가 어떻게 이를 따라잡았을까요?

가장 큰 건 역시 커서 인수입니다. 6월 16일 600억 달러 전액 주식, 벤처 스타트업 인수로는 사상 최대 수준이었죠. 이 거래로 IDE의 기술력과 AI 개발 데이터가 X에서 쌓아 온 데이터와 합쳐졌습니다. 특히, 커서는 에이전트를 쓰면 쓸수록 에이전트형 데이터가 눈덩이처럼 쌓이는 구조입니다. 시간이 갈수록 벌어지는 자산이라는 거죠.

<출처: TechCrunch>

여기에 컴퓨팅 자원이 더해집니다. 스페이스X는 자체 데이터센터까지 가진 곳입니다. 그러니 토큰을 남들보다 싸게 뽑을 수 있죠. 저 2달러·6달러 가격표의 배경이라는 관측이 있습니다. 값을 낮춰도 남는 구조를 가진 쪽이 가격 경쟁을 주도하게 되니까요. 물론 가격 경쟁력을 빼고서라도, 저 프론티어 모델을 만드는 데 들어간 컴퓨팅 자원도 직접 부담할 수 있었을 겁니다.

스페이스X 데이터 센터 <출처: SpaceX>

마치며: 휘청이는 구글과 Top 3의 한 자리

한동안 오픈AI-앤트로픽-구글의 AI Top 3 라인은 단단했습니다.

그런데 구글이 흔들립니다. 제미나이 3.5 프로는 여전히 언제 나올지 아무도 모르고, 8월 들어서는 딥마인드 내부 이탈과 지연 보도가 나왔습니다. 데미스 허사비스, 제프 딘, 존 점퍼 같은 핵심 인력들의 위치가 바뀌었죠. 두 달 내내 나쁜 소식만 쌓였습니다. 중국 모델까지 치고 올라오니 구글 최상위 모델은 어느새 10위권까지 밀렸습니다.

일론 머스크는 “그록 4.7이 3~4주 안에 나오며, 여기에 스페이스X 사내 데이터를 대량으로 투입하고 있다” 예고했습니다. 정말 예고대로라면, 다음 달에 그록이 정말로 GPT와 클로드마저 위협할지도 모릅니다. 분명한 건, 그록을 “이상한 이미지나 잘 만드는 머스크의 그거”로 접어둘 시기는 지났다는 겁니다.

]]>

10년 전 자격증 교재가 AI 테스트를 살렸다

‘Why’는 어디서 오는가

이전 글 ‘AI와 200만 줄의 코드를 작성하며 깨달은 것들’에서 저는 AI에 ‘Why’를 줘야 한다고 했습니다. 그런데 정작 그 Why를 어떻게 줘야 하는지는 쉽지 않습니다. Why를 그렇게 잘 줄 수 있다면, AI가 왜 필요한가 하는 생각도 듭니다. AI가 다 알아서 해줘야 하는 것 아닌가? 싶기도 하고요. 하지만 Why는 결국 ‘내가 원하는 것’입니다. 우리는 AI를 통해 무언가를 얻으려 하고, 그 원하는 것을 얻기 위해 Why를 주는 겁니다.

한 가지 덧붙이면, Why는 곧 우리의 생각이고, 이 생각은 AI를 통해 얼마든지 확장할 수 있습니다. 이를 확장된 사고(Extended Thinking)라고 부르기도 합니다. 우리가 원하는 것을 얻기 위해 자신의 생각을 최대한 넓혀 가는 것이죠.

내가 잘 아는 영역이라면 얼마든지 좋은 Why를 줄 수 있습니다. 문제는 내가 잘 모르는 영역입니다. 잘 모르는 영역에서 답을 구할 때는 환각 증상이 더 많이 나타날 수 있습니다. AI가 준 그 답을 내가 검증할 수 없기 때문입니다.

<출처: 작가>

그래서 잘 모르는 영역에서 답을 구할 때는, AI와 브레인스토밍을 하며(저는 이 방법을 자주 씁니다) 원하는 답을 향해 차근차근 나아가는 방법도 있습니다. 이때는 AI가 길을 잘 찾아가도록, AI 내부가 아니라 밖에서 힌트를 구해 던져 주면 됩니다. 그러면 AI는 그 힌트를 붙잡고 길을 제법 잘 찾아갑니다.

오늘은 AI가 헤매지 않고 내가 원하는 목적지로 길을 잘 찾아가게 만드는 일에 대한 경험을 이야기해 보려 합니다.

미리 요점만 콕 집어보면?

1인 개발이라 테스트를 AI에 맡겼더니, 테스트는 늘 ‘통과’인데 정작 버그는 그대로였습니다. 기준을 주지 않았기 때문입니다.
그 기준은 새로 만드는 게 아니라, 10여 년 전 자격증 공부하며 읽었던 이미 쌓여 있는 문서 안에 있었습니다.
AI가 강력해질수록 낡은 문서의 값은 오히려 오릅니다. 다만 그것을 판단에 쓰고 책임지는 일까지 AI에 넘겨선 안 됩니다.

AI가 늑대 소년이 되다

저는 1인 개발자라 모든 게 부족합니다. 무엇보다 기획과 테스트를 맡아 줄 사람이 없습니다. 그래서 AI로 QA 담당 에이전트를 만들었습니다. AI가 직접 브라우저로 화면을 열어 로그인하고, 값을 입력하며 자동으로 테스트하도록 만든 것이죠. 나온 버그는 슬랙으로 리포트를 받고, 제가 확인해 코드를 고치고 다시 돌렸습니다.

그리고 테스트는 늘 통과했습니다. 저는 아무 생각 없이 결과 리포트만 보고 ‘아, 잘됐구나’ 했습니다. 통과, 또 통과. 테스트 보고서에는 언제나 ‘모두 패스’라고 적혀 있었습니다. 그 깔끔한 성공 리포트 자체가 이상 신호였는데, 당시엔 오히려 안심하고 있었습니다.

서비스 오픈이 얼마 남지 않았을 무렵, 혹시나 하는 마음에 회사 내부 직원에게 같은 화면을 테스트해 보라고 했습니다. 오류가 쏟아졌습니다. 또 AI에 당한 겁니다. 저는 테스트가 정말 잘되고 있는 줄 착각하고 있었습니다. 실제로는 화면에 보이는 표면만 확인됐을 뿐, 정작 중요한 비즈니스 로직은 건너뛰거나 대충 넘어가고 있었습니다.

AI는 그저 테스트를 ‘통과하도록’ 만들어져 있었던 것이죠. 최종 결과를 사람이 확인하지 않고 “네가 확인해라” 하고 맡겼더니, AI는 테스트 항목 몇 개를 만들어 놓고 그냥 통과라고 말해 버린 것이었습니다.

기준을 감으로 만들 수는 없었다

처음 테스트 에이전트를 만들 때, 시간이 없다는 이유로 대충 만들었더니 이런 일이 벌어졌습니다.

왜 이 테스트를 해야 하는지, 무엇을 확인해야 하는지를 명확하게 주지 않아서 발생한 일이었습니다. 테스트 기준이 너무 헐거웠고, 검증 또한 너무 대충이었습니다. 방대한 코드베이스 전체의 테스트를 손수 작성하기에는 시간이 턱없이 부족했습니다.

이걸 어떻게 제대로 만들 수 있을까 고민하다가, 오래전에 따 두었던 테스터 자격증이 문득 떠올랐습니다. ‘아, AI에게 기준을 줘야겠구나.’ 물론 어떤 기준을 왜 줘야 하는지는 당연히 우리의 결정이고, 우리의 일입니다.

AI와 필자가 QA가 잘못된 부분을 다시 검증한 대화 발췌 <출처: 작가>

그런데, 이미 누군가 다 적어 놓았더군요

10여 년 전에 따 놓은 테스팅 자격증(ISTQB). 이력서 한 줄 외에는 거의 쓸 일이 없던 자격증이었습니다.

테스트는 AI의 환각을 막아 주는 최후의 보루라고 생각했기에, 저에게는 아주 중요한 업무였습니다. 환각을 완전히 제거하는 건 불가능하니, 발생할 환각을 ‘이건 환각이다’ 하고 발견해 막아 주는 게 최선이라 여겼습니다. 그래서 테스팅 전략과 시나리오를 처음부터 다시 정리하기로 했습니다.

그 자격증 사이트에 들어가 테스팅 교육 문서들을 다운로드하고, 제가 가지고 있던 몇몇 문서까지 함께 AI에 던져 정리 작업을 시켰습니다. 그런 다음 테스트 에이전트를 다시 작성했습니다. 그러자 AI는 이전에 만들어 둔 테스팅 전략을 수정하고 다시 세우기 시작했습니다. 이제 기준점이 생겼기 때문입니다. 이 기준을 바탕으로 테스팅 전략이 다시 만들어졌고, 전체 시나리오도 새로 작성됐습니다.

사실 저는 개발하면서 기존에 잘 정리된 문서들을 이미 많이 활용해 왔습니다. API 명세서, 국제 표준 스펙 문서 같은 것들이죠. 모두 오랜 시간에 걸쳐 잘 정리된 문서였기에, AI에 아주 좋은 품질의 데이터가 되어 주었습니다.

애자일과 테스팅의 선구자인 켄트 벡(Kent Beck)은 저서 『테스트 주도 개발(Test-Driven Development: By Example)』에서, 테스트를 작성하는 일이 프로그램을 작성하는 것과는 다른 종류의 사고를 요구한다고 봤습니다. 프로그램이 ‘어떻게 작동하게 만들 것인가’를 고민한다면, 테스트는 ‘이것이 어떻게 망가질 수 있는가’를 고민한다는 것이죠.

이 한 문장에 모든 게 담겨 있습니다. 테스트는 성공을 위한 것이 아니라, 실패를 위한 것입니다. 그리고 AI는 실패를 만들어 내는 데 서툽니다. 그래서 우리가 실패하도록 유도하고, 검증해야 합니다.

저는 늘 ‘AI가 모든 걸 자동으로, 그럴듯하게 해주니 편하구나, AI 정말 좋네’ 하며 그냥 넘어가고 있었습니다. 제 일을 AI에 통째로 일임했던 것이고, AI는 결국 이런 결과로 답한 것입니다. 그 뒤로 저는 AI와 협업할 때 항상 확인하고, 질문하고, 검증하는 버릇이 생겼습니다. 맞아 보여도 한 번 더 묻습니다. “너의 결과가 나의 의도(context)와 맞는지 확인하고, 어긋나면 나에게 피드백을 달라”고 말이죠.

감으로 기준을 준 경우와 문서로 기준을 준 경우 비교 <출처: 작가>

문서에서 설계를, 설계에서 자동화를

테스팅 작업을 예로 들었지만, 제가 정작 강조하고 싶은 건 ‘문서’입니다. AI가 환각을 줄이고 더 나은 판단을 하도록 만드는 방법은 멀리 있지 않습니다. 우리가 그동안 한 땀 한 땀 적어 놓은 수많은 기록들이 있습니다. 오타도 있고 잘못 적힌 내용도 있지만, 우리가 일했던 그 흔적들이 AI에는 훌륭한 참고서가 됩니다.

결국 AI 시대에도 중요한 건 데이터였습니다. AI로 개발을 시작한 뒤로는, AI가 문서를 워낙 잘 만들어 주다 보니 제가 예전에 만든 문서들은 촌스럽고 낡은 것이 되어 어딘가에 백업본으로만 남아 있었습니다. 그 파일들 안에는 문서를 쓰며 고민했던 흔적과 시행착오 같은 경험이 고스란히 녹아 있었는데, AI의 멋진 출력물에 취해 저는 그걸 다 잊고 있었습니다.

그 문서를 다시 꺼내게 된 계기가 바로 이번 테스트 오류였습니다. AI에도 데이터를 주고, 가르치고, 쓰게 해야 한다는 당연한 사실을, 저는 AI의 근사함에 가려 잊고 있었던 겁니다.

그래서 PC 어느 구석에 숨어 있던 그 문서들을 AI에 정리시키고, 다시 참고서로 던져 주었습니다. 그러자 AI는 Why와 What, 그리고 Goal을 훨씬 잘 이해한 결과물을 내놓기 시작했습니다.

AI가 스스로 좋은 결과물을 내놓게 하려면, AI가 작업하는 환경 자체가 매우 중요하다는 걸 느꼈습니다. 문서를 주고, 의도를 주고, 형태를 주더라도 결국 모든 것은 저의 의사결정에 따라 움직여야 한다는 사실을 알게 됐습니다.

한 가지 팁을 덧붙이면, 참고 문서가 너무 많으면 프롬프트가 길어져 오히려 답변 품질이 떨어질 수 있습니다. 이럴 때는 AI에 먼저 문서 구조화 작업을 시켜 두면, 훨씬 효율적으로 활용할 수 있습니다.

마치며: 낡은 문서의 값이 오르는 시대

AI에 일을 맡기려는 순간, 우리는 그동안 굳이 명시적으로 답할 필요가 없던 질문들과 마주하게 됩니다. 무엇이 통과이고, 무엇이 실패인가. 확신이 서지 않을 때는 어떻게 할 것인가. 사람에게 맡길 때는 이런 것을 하나하나 정의하지 않습니다. 상대가 알아서 판단해 주니까요.

그리고 그 판단의 기준은 대개 이미 어딘가에 존재합니다. 제 경우엔 이력서 한 줄로만 남아 있던 자격증 교재였고, 다른 분야라면 회계 기준이나 임상 가이드라인, 하다못해 선배가 남긴 낡은 운영 매뉴얼일 수도 있겠죠. 우리는 그런 문서들을 낡았다고 여겨 왔습니다. 이론일 뿐이라고, 현장에선 안 쓴다고, 자격증 딸 때나 보는 거라고요.

하지만 AI 시대에 그 문서들의 값은 오히려 올라갑니다. AI는 그 문서를 읽고 실행할 수는 있어도, 만들어 낼 수는 없기 때문입니다.

AI는 최종 판단을 하지 않습니다. 언제나 그랬듯, 우리의 삶과 마찬가지로 중요한 결정은 결국 자기 자신이 내려야 합니다.

다만 한 가지 경계할 것이 있습니다. AI를 오래 쓰다 보면 ‘생각의 외주화’라는 함정에 빠지기 쉽습니다. AI의 출력이 그럴듯하니 점점 거기에 기대게 되고, 그러는 사이 사고력을 잃어 가는 것이죠. AI에 많이 의존할수록, 우리는 정작 Why를 던지는 일조차 서툴러집니다. 그래서 저는 늘 ‘기준은 내가 결정하고, 내가 책임진다’는 말을 되뇌며 작업합니다.

AI는 그 결과를 책임져 주지 않습니다. AI가 어떤 내용을 주든, 어떤 판단을 내리든, 최종 책임은 그것을 받아들인 우리 몫입니다. 늘 결과를 확인하고 검증해 최적의 답을 얻는 것, 그리고 결정하는 것. 그건 언제나 우리의 일입니다.

<참고>

1. ISTQB® Certified Tester Foundation Level 실라버스 (공식)

2. Kent Beck, 『Test-Driven Development: By Example』, Addison-Wesley, 2002.

]]>

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

]]>

지금 전 세계에서 가장 인기 있는 에이전트 스킬 Top5는 뭘까?

<출처: 작가>

스킬(Skill)이란, 에이전트에 건네는 온보딩 문서에 가깝습니다. 무언가 일을 할 때 필요한 모든 것을 정리해 둔 문서로, 실제 그 일을 해야할 때만 읽는 안내서죠. Anthropic은 이를 두고 “에이전트가 특정 작업을 더 잘 해내도록 동적으로 발견하고 불러오는, 지시문·스크립트·리소스를 담은 폴더”라고 정의해요. 초기에는 에이전트를 잘 쓰려면 “스킬만 잘 써도 절반은 간다”는 말이 나왔을 만큼 핵심 중의 핵심입니다.

이러한 스킬은 목적과 과정을 말로 설명하고, 에이전트한테 “만들어 줘”라고 요청하는 것만으로 쉽게 만들 수 있어요. 저도 작업 하나가 잘 마무리되고 나면, 잊지 않고 이 일을 스킬로 만들어달라고 요청하는 편입니다. 문제는 스킬을 서너 개 만들어 쓰다 보면 슬슬 의심이 간다는 데 있어요. 하다 보면 내가 지금 이걸 제대로 만들고 있는 게 맞나? 싶어진다는 거죠.

그럴 때 제일 빠른 답은 남이 잘 만든 걸 열어보는 거라고 생각해요. 그래서 사람들이 제일 많이 쓰는 스킬들을 찾아봤습니다.

‘인기’의 기준은 GitHub 스타로 잡았습니다. 각 레포는 릴리스 파일을 배포하지 않아서 다운로드 수라는 게 아예 잡히지 않습니다. 대안으로 쓰이는 skills.sh 설치 수는 운영사 Vercel이 자사 CLI로 직접 집계하는 값이라 원자료를 밖에서 확인할 방법이 없고요. 그래서 써 보고 좋았던 사람들이 누른 “좋아요”, 즉, 스타 수를 기준으로 잡았습니다.

위의 순위는 2026년 8월 10일 기준 값이며, 따라서 개별 스킬이 아닌 “레포지토리” 전체를 다룹니다.

2026 스킬 순위 1~5위

각각 세 가지 기준으로 정리했습니다. 어디에 쓰는 물건인지, 안에서 무슨 일이 벌어지는지, 나머지 넷과 뭐가 다른지.

1위 obra/superpowers· 269,762★

<출처: GitHub, 작가 캡처>

이 스킬을 적용하면, 코딩 에이전트를 켜는 순간부터 스킬이 동작합니다. 뭘 만들려는 낌새가 보이면 에이전트가 코드로 달려가지 않고 한 발 물러서서 “진짜 하려는 게 뭐냐”부터 묻죠. 설계 문답에서 격리 작업 공간, 계획 분해로 이어지는 앞 세 단계를 지나 테스트·리뷰·병합 정리까지 일곱 단계가 순서대로 이어져요.

어찌나 강력한지 GitHub 전체 스타 수로 14위에 오를 만큼 큰 인기를 얻었죠.

이 레포의 정체는 작동 방식에 있습니다. 스킬 14개만 들어 있는 게 아니라, 세션을 열 때마다 자동으로 도는 스크립트가 같이 있습니다. 이 스크립트가 매번 부트스트랩 스킬의 전문을 컨텍스트에 밀어 넣고, 그 부트스트랩이 나머지 스킬을 제때 깨웁니다. 지시문은 선택지를 지우는 쪽으로 쓰여 있습니다. “IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.” 스킬이 적용되는 작업이면 선택권이 없으니 쓰라는 겁니다.

다른 점은 스킬 자체를 테스트 주도로 만든다는 데 있습니다. 스킬 내용을 고치는 PR은 스킬을 켠 실행과 끈 실행의 평가 결과를 봤을 때 괜찮아야 통과됩니다. 평가 근거 없이는 받지 않겠다고 선언까지 해뒀고요. 코드를 곧바로 만들기보다는 설계 문서와 승인 기록을 우선으로 봅니다. 대신 큰 단위 맥락이 매 세션 주입되는 구조라, 시작하자마자 22,000토큰을 넘게 먹었다는 이슈가 올라온 적이 있습니다.

설치 명령어

/plugin install superpowers@claude-plugins-official.

2위 affaan-m/ECC· 239,034★

<출처: GitHub, 작가 캡처>

ECC란 레포 이름은 “Everything Claude Code”의 약자입니다. 계획부터 테스트·구현·리뷰·검증·기억까지 엔지니어링 절차를 설정 자산으로 한 번에 까는 배포판이에요. 기능 개발은 /ecc:plan, 코드 리뷰는 새 컨텍스트에서 /code-review처럼 진입점이 명령어로 정리돼 있습니다.

규모는 소개할 다섯 개 가운데 제일 큽니다. 레포 안 SKILL.md 파일이 897개인데, 번역본과 하네스별 사본을 걷어내면 정본은 284개라고 합니다(2026-08-10 기준).

문제는 필요한 스킬만 골라 불러주는 라우팅 장치가 없다는 점입니다. 전부 설치하면 이름과 설명만으로 매 세션 약 17,600토큰을 상시 점유해요. 그러니 레포 스스로도 필요한 것만 선택해 설치할 것을 추천합니다.

개인적으로 재밌다고 생각한 건 skill-comply입니다. claude -p를 실제로 돌려 도구 호출 기록을 잡고 프롬프트 강도를 단계별로 낮춰가며 스킬이 진짜 지켜지는지를 잽니다. 말하자면 스킬을 감사하는 스킬이죠. 또, 국내 개발팀이라면 inherit-legacy-style 쪽도 괜찮습니다. 손으로 짠 레거시 프로젝트에 AI가 학습한 주류 관용구를 밀어붙이는 “스타일 드리프트”를 막으려고, 코드베이스의 암묵 규칙을 스캔해 문서로 고정하고 이후 코딩 작업의 제약으로 삼죠.

설치 명령어

 ./install.sh --target claude --skills tdd-workflow,security-review(뒤의 스킬들은 골라서 입력)

3위 mattpocock/skills· 211,297★

<출처: GitHub, 작가 캡처>

TypeScript 교육자 Matt Pocock이 자기 .agents 디렉터리를 그대로 공개한 35개짜리 스킬 모음입니다. 간판 스킬은 이름 그대로 아이디어와 설계를 캐물어 굽는(grill) 시리즈예요. 머릿속 생각만 다듬고 싶으면 /grill-me, 코드베이스에 문서까지 남기려면 /grill-with-docs. 상황별 진입점이 이런 식으로 갖춰져 있습니다.

그중 grill-me의 전문이 이렇습니다.

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---

Run a `/grilling` session.

한 줄이죠. 이 명령이 호출하는 열 줄짜리 grilling 스킬에 쓰인 건 인터뷰 절차입니다. 이때 무엇을 물을지는 에이전트의 일이라 직접 조회할 수 있는 걸 사람에게 묻지 않습니다. 그 대신 결정은 사람 몫이고요. 지금 답할 수 있는 질문을 묻고, 그 답변들을 모두 취합하면 다음으로 궁금한 것들을 묻습니다.

그러니 이 레포가 주는 건 산출물 템플릿이 아니라 일 하기 전에 스스로 할 일을 캐물어보라는 행동 규약에 가깝습니다. 파일도 거의 안 남아요. 참고로 grill-me는 /grilling이 함께 있어야 도는 한 줄짜리 래퍼라, 스킬을 골라 설치하는 경로에서 이 파일만 받으면 동작하지 않습니다.

설치 명령어

/plugin marketplace add mattpocock/skills.

4위 multica-ai/andrej-karpathy-skills· 200,937★

<출처: GitHub, 작가 캡처>

이건 앞서 본 스킬 레포들과 조금 다릅니다. 스킬 패키지가 아니라 에이전트 지침 문서 한 장이거든요. AI 업계에서 가장 유명한 개발자 중 하나인 Andrej Karpathy가 LLM 코딩의 함정을 관찰해 올린 X 게시물에서 파생한 CLAUDE.md 65줄이 전부입니다. 파일 여덟 개를 다 합쳐 20KB이고 실행 코드는 0줄이에요. 훅도 스크립트도 서브에이전트도 없는 건 이것뿐입니다. 스킬 디렉터리 구조는 공개 이튿날부터 외부 기여자들이 배포 호환용으로 덧씌운 껍데기고요.

원칙은 네 가지입니다. 코딩 전에 생각하고, 단순하게 가고, 수술하듯 고치고, 검증 가능한 목표를 잡으라는 것. “200줄을 썼는데 50줄로 될 일이면 다시 써라”, “바뀐 모든 줄은 사용자의 요청으로 곧바로 거슬러 올라가야 한다” 같은 지침들이죠. 새로운 능력을 주는 게 아니라, 흔히 벌어지는 사고 유형에 이름과 판정 기준을 붙여주는 겁니다.

짚을 것이 있습니다. Karpathy는 이 레포의 작성자도 기여자도 아닙니다. 그가 언급하거나 승인한 기록도, 반대로 부인한 기록도 딱히 없고요. 어쨌든 그의 유명세를 타고 스킬은 큰 인기를 얻었습니다.

설치 명령어

/plugin marketplace add multica-ai/andrej-karpathy-skills.

5위 anthropics/skills· 167,251★

<출처: GitHub, 작가 캡처>

Anthropic이 직접 운영하는 공식 레퍼런스입니다. Claude의 문서 생성 기능을 실제로 구동하는 프로덕션 스킬 docx·pptx·xlsx·pdf와 예제를 합쳐 17종이 들어 있어요. 다섯 중 유일하게 결과물을 뽑아주는 쪽입니다. 회사 PPT 템플릿을 던져주면 전 슬라이드 썸네일로 레이아웃을 고르고 슬라이드를 복제해 채운 뒤, 템플릿이 원래 갖고 있던 오류와 새로 생긴 오류를 분리해 검증하는 데까지 스크립트로 짜여 있습니다.

가장 눈에 띄는 건 frontend-design이에요. 스크립트도 참조 파일도 없는 55줄짜리 마크다운 한 장인데, 지금 AI가 만드는 디자인이 몰리는 세 가지 모양을 콕 집어 반대로 가라고 지시해요. 크림색 배경에 고대비 세리프를 얹은 조합은 #F4F1EA라고 헥스 코드까지 박아뒀어요. 브리프가 방향을 지정하지 않았다면, 적어도 이 기본값으로 가지 말라는 겁니다. 비슷한 프롬프트를 한 번 더 돌려 같은 곳에 도착하면 “그건 선택이 아니라 기본값”이라며 고쳐야 코드 작성을 허용하는 자기 표절 테스트도 걸려 있고요.

다만, 실무에서 걸리는 건 라이선스입니다. 가장 탐나는 문서 스킬 4종은 독점으로(“source-available, not open source”가 README의 표현입니다), 오픈소스인 쪽은 나머지예요. 보통 “스킬은 공짜”라고 이해하는 분들이 많지만, 이걸 포함해 수익화할 때는 조심해야 합니다.

설치 명령어

/plugin marketplace add anthropics/skills.

초인기 스킬들의 공통점

지금까지 설명한 다섯 개 스킬의 성격과 특징, 주의사항을 모아 놓은 표입니다. 나란히 놓고 보니 비슷한 점이 보입니다.

1) 스킬은 통제형

superpowers의 테스트 스킬은 “테스트보다 코드를 먼저 썼다면? 지워라. 처음부터 다시”라고 합니다. karpathy 지침은 “인접한 코드·주석·서식을 ‘개선’하지 마라”고 하고요. mattpocock의 grilling은 “사용자가 합의에 도달했다고 확인해 주기 전까지는 그것에 대해 행동하지 마라”입니다.

셋 다 무엇을 하라는 지시가 아니라 무언가 맘대로 못 하게 막는 문장입니다. 그러니까 인기 상위권 스킬이 팔고 있는 건 통제입니다. 코드부터 치지 마라, 먼저 캐물어라, 가정하지 마라.

2) 누군가의 사고방식을 흉내 내기

또 하나 재미있는 건 특정 개인의 사고방식이나 업무 방향을 정리해 기록해 둔 것들이 많다는 점입니다. grill-me는 Matt Pocock이 정리한 인터뷰 구조를 따르고, karpathy 지침은 애초에 한 사람의 X 게시물에서 시작했습니다. 스킬이라는 개념 자체가 결과물 템플릿이 아니라 누군가의 머릿속 기준을 옮겨 적은 메모에 가깝기 때문입니다.

3) 중요한 건 “왜?”

특히 흥미로운 건 이들 스킬이 결과를 만들기보다, “왜?”를 정리해 주는 데 있다는 겁니다. grill-me, grill-with-docs는 이름부터 캐묻는 행위(grilling)이고, karpathy 지침의 “수정한 모든 건 사용자의 요청으로 곧바로 거슬러 올라가야 한다”도 결국 이유를 계속 되짚는 규칙입니다. superpowers는 코드를 쓰기 전에 “진짜 하려는 게 뭐냐”부터 묻고요. 저는 결국 사람들이 AI와 함께하며 공통적으로 겪고 있는 문제는 “어떻게”가 아닌 “왜”에 있다는 방증이라고 생각합니다.

그래서, 직접 만들어 쓰는 게 나을 수 있다

결국 이렇게 “왜”를 파고들다 보면 “어떻게”를 다룬 스킬은 직접 만들어 쓰는 게 낫습니다.

만드는 것도 참 쉽습니다. Anthropic이 공개한 공식 스킬 skill-creator가 있는데요. 대화로 초안을 잡은 다음, 테스트 프롬프트를 놓고 스킬을 준 실행과 안 준 실행을 같이 띄워 채점하고, 그 점수로 스킬을 고칩니다. 감이 아니라 수치로 다듬는 구조죠. Claude Code나 Cowork에서 보통 “스킬 만들어 줘”라고 하면 자동으로 이 스킬이 돌아가고는 합니다.

<출처: GitHub, 작가 캡처>

이때 설명문을 조금 밀어붙이듯 쓰라는 공식 지침이 있습니다. 특히 “이럴 때 쓴다”를 구체적으로 적어야 실제로 호출된다는 겁니다. 개인이 만든 스킬의 가장 큰 약점 중 하나는 결국 “쓰이지 않는다”는 겁니다. 알아서 필요할 때 동작하며 도움을 줘야 하는데, 귀찮은 명령어가 붙다 보면 잘 안 쓰이게 되는 거죠. 그러니 무슨 범위까지, 언제 쓸 스킬을 만들지를 미리 잘 생각하면 좋습니다.

이런 맥락에서 최근 잘 쓴 건 “Record a skill”입니다. 화면을 녹화하면 Claude가 관찰한 내용으로 초안을 제안하는 기능입니다. 화면 녹화를 켜고 반복해 하는 일을 순서대로 하니 AI가 그대로 스킬로 만들어 줬고, 꽤 만족하며 스킬을 쓰고 있습니다. 다만 Claude for Mac의 Cowork 전용이라 Windows에서는 안 되는 제약이 있습니다.

마치며

지금의 스킬 순위표를 조사하고 보니, 결국 내 일에 큰 영향을 끼치는 스킬은 직접 만들어야 겠다고 느꼈습니다. 돌고 돌아 제가 만든 스킬이 더 편하더라고요.

그래도 다섯 개 스킬을 뜯어보는 동안 건진 게 하나 있습니다. 스타 수가 높은 스킬 대부분은 대단한 기능이 아니라, 에이전트가 날뛰는 것을 멈춰 세우는 일을 한다는 것. 그 요령으로 내 에이전트가 자꾸 반복하는 실수 하나를 골라 문서로 적어 보시면 어떨까요? 그 문서 하나가 세계에서 가장 인기 있는 스킬의 방법론들보다 나을 수 있습니다.

]]>

B2B AI SaaS가 성공하려면 뭐가 중요할까?

국내외를 막론하고 B2B AI SaaS를 운영하는 경영진(CEO, CTO, CPO)이 세일즈 현장에서 마주하는 가장 큰 장벽은 무엇일까요? 뛰어난 모델 성능이나 유용한 기능에도 불구하고, 고객사에서 계약 검토가 수개월씩 지연되거나 무산되는 것일 거라고 생각합니다.

최근 해외 정책 동향을 보면, 일본 정부는 미국 빅테크 기술 종속 극복을 위해 국가 차원의 생성형 AI 정책 드라이브를 강하게 걸고 있습니다. 국내 AI 인프라 지원책과 더불어, 의료·범죄 기록 등 민감한 개인정보도 AI 모델 개발과 학습용으로 수집·활용할 수 있도록 규제를 완화하는 개정 개인정보보호법안이 2026년 7월 통과되었습니다.

하지만 정부가 규제를 풀어주어도 기업 세일즈 현장의 분위기는 쉽게 변하지 않습니다. “우리 회사의 핵심 자산과 고객 데이터가 외부 LLM에 유출되거나 학습되면 어떻게 하지?”라는 근본적 불안이 여전하기 때문입니다.

이번 글에서는 해외 규제 완화와 현장에서의 인식 차이를 데이터로 살펴보고, 한국 B2B AI SaaS 기업이 고객사 보안 심의를 뚫고 세일즈 리드타임을 단축하기 위해 제품 아키텍처에 적용해야 할 3가지 하이브리드 보안 전략을 정리해 보겠습니다.

미리 요점만 콕 집어보면?

비즈니스 인사이트: 제도적 규제 완화가 기업의 AI SaaS 구매로 즉시 연결되지 않으며, B2B 세일즈의 성패는 공급사가 ‘기술적 데이터 통제권’을 제품 수준에서 증명하는 데 달렸습니다.
전략적 트레이드오프: 고객사의 물리적 망 분리(Single-tenant) 요구는 SaaS의 스케일업을 저해하므로, 데이터 거점(Data Residency) 고정과 암호화 키 분리를 결합한 하이브리드 인프라로 타협점을 찾아야 합니다.
실행 가능한 거버넌스: 과도한 마스킹으로 인한 답변 품질 저하를 막는 ‘민감도 기반 하이브리드 라우팅’과 관리자 감사 로그(Audit Log) 기반의 ‘Trust UX’를 통해 세일즈 리드타임을 실질적으로 줄일 수 있습니다.

열리는 규제, 닫히는 지갑

글로벌 AI 시장에서 일본 정부의 정책 행보는 대표적인 규제 완화 드라이브 사례입니다. 디지털청 장관 기자회견(2026년 6월 12일) 및 디지털 사회 구상 회의(2026년 5월 22일) 발표에서 보듯, 자체 ‘Sovereign AI’ 생태계를 조속히 구축하기 위해 정부 차원에서 민감 정보 활용 규제를 전폭적으로 완화해 왔습니다.

그러나 정부의 전폭적인 제도 지원에도 불구하고, 실제 시장의 도입 속도는 기대에 미치지 못하는 현상을 보입니다. 데이코쿠데이터뱅크(TDB)가 발표한 생성형 AI 동향 조사(2026년 3월, 유효응답 10,312사) 지표는 한국 B2B AI SaaS 경영진에게 매우 유용한 실증 벤치마크를 제공합니다.

높은 효용성 (86.7%): 생성형 AI를 도입해 활용 중인 기업 중 86.7%는 “업무 효율과 성과가 뚜렷하다”며 유용성을 높이 평가했습니다. 기술의 성능이나 비즈니스 가치에는 의문이 없습니다.
낮은 도입률 (34.5%): 그럼에도 전체 기업의 생성형 AI 도입률은 34.5% 수준에 머물러 있습니다. AI를 도입한 기업은 만족하지만, 전체 기업 10곳 중 6곳 이상(65.5%)은 여전히 도입을 주저하며 관망하는 것입니다.

<출처: 데이코쿠데이터뱅크>

정부가 규제를 풀어주고 기술 효과도 입증되었는데, 왜 65.5%의 기업은 도입을 망설일까요? TDB 조사에 따르면 기업들이 꼽은 생성형 AI 도입 시 우려·과제 1위는 바로 ‘정보의 정확성(50.4%)’이었으며, 이어 ‘전문인재·노하우 부족(41.3%)’, ‘활용 업무 범위(40.0%)’, 그리고 ‘정보 유출 리스크(33.5%)’가 주요 원인으로 나타났습니다.

즉, 기업들은 단순히 보안 유출 하나만 두려워하는 것이 아닙니다. “AI 답변의 정확도와 업무 맥락을 유지(50.4%)하면서도, 핵심 데이터 유출 위험(33.5%)을 어떻게 철저히 통제할 것인가”라는 ‘답변 품질과 보안 통제권의 동시 충족’을 요구하고 있는 것입니다.

<출처: 데이코쿠데이터뱅크>

이러한 우려와 컴플라이언스 부담은 기업 규모별 도입 격차로도 나타납니다. 도쿄상공리서치(TSR)의 조사(2026년 4월, 유효응답 6,327사) 지표를 살펴보면 그 차이가 드러납니다.

[2026년 기업의 생성형 AI 도입 지표 및 양극화 현상]

1. TDB 조사(10,312사 대상)

도입 기업의 업무 만족도: 86.7% (기술적 효용은 이미 검증됨)
주요 우려·과제 원인: 정보 정확성(50.4%), 전문인재 부족(41.3%), 정보 유출 리스크(33.5%)

2. TSR 조사(6,327사 대상)

대기업 AI 활용 비율: 59.1% (자체 보안 검토 및 프라이빗 구축 여력 보유)
중소기업 AI 활용 비율: 30% 안팎 (보안 및 정확성 검토 인력 부재로 약 2배 격차)

TSR 데이터에 따르면 대기업의 생성형 AI 활용 비율은 59.1%에 달하는 반면, 중소기업은 30% 안팎에 그쳐 약 2배의 도입 격차를 보입니다. 대기업은 내부 인력을 동원해 SaaS 공급사와 별도의 프라이빗 구축이나 커스텀 보안 계약을 협상할 여력이 있지만, 중소기업은 보안 검토 및 답변 정확성 검증 인력 자체가 부족해 우려가 해결되지 않으면 도입을 유예해 버리기 때문입니다.

한국 B2B AI SaaS 경영진이 이 데이터에서 얻어야 할 시사점은 명확합니다. 세일즈 타겟을 확장하려면, 고객이 복잡한 설정 없이도 안심하고 정확한 답변을 얻을 수 있는 ‘완제품 형태의 기술적 보안 신뢰(Secure by Default)’를 제품 아키텍처로 증명해야 한다는 점입니다.

제도적 규제 완화는 시장 진입을 위한 신호일 뿐입니다. 실제 매출 전환을 위해서는 법률적 기준을 넘어 고객사의 보안 불안을 해소하는 제품 수준의 신뢰 엔지니어링이 필수적입니다.

물리적 망 분리 요구를 극복하는 ‘하이브리드 인프라 전략’

B2B AI SaaS 기업이 대기업 고객사를 대상으로 세일즈를 진행할 때 마주하는 첫 번째 장벽은 보안 부서의 ‘물리적 망 분리(Single-tenant)’ 요구입니다. “자사 데이터가 타사와 섞여선 안 되며, 전용 클라우드 환경에 독립 배포해 달라”는 요구조건이죠.

실제로 저희 팀에서 금융·제조 업종 대기업 고객사의 보안 심의에 참여했을 때, 보안 부서에서 가장 먼저 내건 조건이 바로 이 물리적 망 분리였습니다. 처음에는 이 요구를 그대로 수용해, 고객사별 독립 인프라(싱글테넌트)를 설계하는 방향을 검토했습니다.

그러나 실제로 설계를 진행해 보니 문제는 예상보다 심각했습니다. 고객사가 추가될 때마다 별도의 인프라 스택과 배포 파이프라인을 구축·운영해야 하므로, 인프라 비용이 멀티테넌트 대비 수 배로 증가했습니다. 신기능 배포 시 모든 고객 환경에 개별 적용해야 하는 운영 복잡도도 급격히 높아졌고요. 이 방식으로는 SaaS 사업의 수익성과 배포 속도를 유지하면서, 고객 기반을 확장하는 것이 사실상 불가능했습니다.

이런 경험을 통해 저희가 내린 결론은 물리적 격리 요구를 액면 그대로 수용하는 것이 아니라, 고객이 진정으로 원하는 것, 즉 ‘자사 데이터가 타사와 논리적으로 완전히 분리되어 있다는 확신’을 기술적으로 증명하는 것이었죠. 그래서 대안으로 선택한 것이 바로 ‘지리적 데이터 거점(Data Residency)’과 ‘논리적 암호화 격리’를 결합한 하이브리드 아키텍처였습니다.

저희 팀의 경우, 데이터 역외 반출을 우려하는 일본 기업 고객을 위해, 모든 데이터 저장·처리 영역을 AWS 도쿄 리전(Primary)과 오사카 리전(DR, 재해복구)으로 고정하는 Data Residency 설계를 적용했습니다.

고객사 보안 담당자에게 ‘데이터가 국경을 넘지 않는다’는 점을 인프라 구성도 레벨에서 증명할 수 있도록 한 겁니다.

또한 SaaS 배포 효율을 지키기 위해 단일 멀티테넌트 DB 구조는 유지하되, 행 수준 보안(RLS, Row-Level Security)을 적용했습니다. 그리고 AWS KMS를 연동해 고객사가 데이터 암호화 키(BYOK, Bring Your Own Key)를 직접 소유·관리하도록 구성했습니다.

이러한 설계로 인해 “인프라는 멀티테넌트이지만, 데이터 복호화 권한은 귀사의 전용 키에 묶여 있어 SaaS 공급사도 들여다볼 수 없다”는 점을 들어 물리 격리와 동등한 수준의 데이터 안전성을 증명할 수 있었습니다. 결과적으로 독자적인 싱글테넌트 구축 대비 인프라 운영 비용을 크게 절감하면서도, 고객의 요구사항을 만족시킬 수 있었죠.

TIP: 만약 비슷한 상황에 놓였다면, 고객의 요구사항에 수긍하여 SaaS의 확장성을 포기하지 마세요. 고객이 실제로 원하는 것은 ‘데이터가 분리되어 있다는 확신’이며, 데이터 거점 고정과 암호화 키 분리를 결합한 하이브리드 전략으로 이 확신을 기술적으로 증명해야 합니다.

AI 답변 품질을 지키는 ‘민감도 기반 하이브리드 라우팅’

두 번째 기술적 난관은 개인정보(PII)마스킹과 AI 답변 품질 간의 트레이드오프입니다.

외부 LLM(OpenAI, Claude 등)으로의 데이터 유출을 막기 위해 PII 필터링을 적용하면, 오탐(False Positive)으로 인해 핵심 고유명사나 내부 제품 코드까지 마스킹되어 버리는 문제가 발생합니다.

저희 팀도 초기에는 오픈소스 PII 필터링 라이브러리를 일괄 적용하는 방식을 택했습니다. 그런데 운영 과정에서 일본어 고유명사와 전문 비즈니스 용어가 개인정보로 오탐되어 마스킹되는 문제가 반복적으로 발생했습니다. 예를 들어, “오사카 지점 A100 부품 납품 일정”이라는 업무 프롬프트가 "[LOCATION] 지점 [CODE] 부품 납품 일정"으로 변환되면, LLM은 업무 맥락을 잃고 엉뚱한 답변을 출력합니다. 보안을 위해 적용한 필터가 오히려 서비스 품질을 훼손하는 상황이었죠.

이 문제를 해결하기 위해 저희는 일괄 필터링 대신, 민감도에 따라 처리 흐름을 나누는 ‘하이브리드 라우팅(Hybrid Routing)’ 아키텍처를 도입했습니다.

실시간 민감도 감지: 사용자가 프롬프트를 입력하면 경량 NLP 분류 모델이 사내 기밀 및 PII 포함 여부를 실시간으로 측정합니다.
일반 데이터 외부 라우팅: 보안 우려가 적은 일반 업무 프롬프트는 최소한의 PII 마스킹 후 LLM API로 처리하여 처리 속도와 지능 수준을 최상으로 유지합니다.
민감 데이터 로컬 라우팅: 오탐 위험이 크거나 외부로 내보낼 수 없는 핵심 민감 데이터는 외부 인터넷망을 타지 않고 사내 VPC 내에 배포된 경량 오픈소스 LLM(Llama-3, Qwen 등)으로 직접 리다이렉션합니다.

이 하이브리드 라우팅을 적용하니, 외부 유출 위험을 근본적으로 차단하면서도 프롬프트 훼손율을 크게 줄일 수 있었는데요. 일괄 마스킹 방식에서 문제가 된 고유명사·제품 코드 오탐 이슈가 해소되면서, AI 서비스의 답변 품질과 보안 컴플라이언스를 동시에 확보할 수 있었죠.

TIP: 무조건적인 정보 훼손으로 AI 서비스의 핵심 성능을 떨어뜨리지 마세요. 민감도 판별에 따라, LLM API와 사내 로컬 LLM을 분기 처리하는 하이브리드 라우팅이 효용성과 보안을 모두 잡는 전략입니다.

수십 페이지 보안 서류를 대체하는 ‘Trust UX’

아무리 뛰어난 보안 아키텍처를 구축했더라도, 의사결정권자가 체감하지 못하면 최종 계약으로 연결되기 힘듭니다. Trust UX를 설계하게 된 계기는 몇몇 고객사의 도입 검토 과정에서 겪은 경험이었는데요.

몇몇 고객사의 보안 책임자는 저희가 작성한 문서에 “데이터를 AI 학습에 활용하지 않는다”고 명시했음에도, “직접 눈으로 확인하기 전에는 결재를 올릴 수 없다”고 답했습니다. 보안 서류에 아무리 완벽한 보안 스펙을 기술해도, 보안 담당자가 직접 확인할 수 없으면 계약까지 이어지지 않았죠.

이 경험을 계기로, 보안에 대한 내용을 문서가 아닌 사용자 경험(Trust UX)을 통해 직접 체감하도록 해야 한다는 판단을 내렸습니다.

실시간 안심 문구: 서비스 화면 하단에 "입력하신 데이터는 AI 학습에 활용되지 않으며, 암호화 처리 중입니다"라는 안내 문구와 실시간 보안 상태를 상시 노출하여 실무자의 데이터 업로드 불안을 낮췄습니다.
관리자 자율 통제 대시보드(Compliance Admin):
비학습 Opt-out 토글: 관리자 페이지에서 스위치 클릭 한 번으로 AI 학습 비활성화 상태를 자율적으로 통제할 수 있게 했습니다.
감사 로그(Audit Log)시각화: 프롬프트 데이터의 마스킹 여부, 처리된 리전 위치, 활용된 모델 종류를 실시간 타임라인으로 투명하게 확인할 수 있는 대시보드를 구축했습니다.

이후 보안 심의 과정에서 수십 페이지의 관련 서류를 주고받는 대신, 실제 작동하는 관리자 화면의 감사 로그와 자율 통제 토글 기능을 직접 시연하는 방식으로 전환했고요. 그 결과 이전에 도입을 보류했던 고객사가 심의를 재개했고, 기존에 수개월이 소요되던 보안 검토 프로세스를 단축하는 성과를 얻었습니다.

도입을 결정한 고객사들에게 이유를 물은 결과 “화면에서 직접 확인하고 통제할 수 있다는 것이 안심이 된다”는 피드백을 받았죠.

TIP: 보안 스펙이 아무리 훌륭해도 고객이 체감하지 못하면 무용지물입니다. 사용자와 관리자가 데이터 통제권을 실시간으로 확인할 수 있도록 ‘Trust UX’에 적극적으로 투자하세요.

B2B AI SaaS 세일즈의 무기는 ‘보안 아키텍처’다

생성형 AI 기술 경쟁은 모델 파라미터 크기 자랑에서 이제 ‘고객의 경계 내에서 데이터를 얼마나 안전하고 투명하게 통제할 수 있는가’로 이동하고 있습니다.

정부 차원의 규제 완화가 이루어지더라도, 기업의 불안은 B2B 세일즈의 거대한 장벽으로 남아 있을 거고요. 결국 다가오는 B2B AI SaaS 시장의 승자는 하이브리드 인프라로 SaaS의 스케일업 마진을 지키고, 하이브리드 라우팅으로 성능과 보안의 균형을 잡으며, Trust UX로 고객의 신뢰를 즉각 확보하는 기업이 될 겁니다.

보안 컴플라이언스는 더 이상 수동적인 방어용 방패가 아닙니다. 시장의 장벽을 뚫고 고객사의 지갑을 열게 만드는 B2B 세일즈의 가장 강력한 무기입니다.

[C-Level을 위한 다음 단계 가이드]
현재 운영 중인 AI SaaS의 B2B 세일즈 전환율을 높이고 보안 심의 기간을 단축하고 싶으시다면, 기존 싱글테넌트 구축 요청에 하이브리드 인프라(Data Residency + BYOK)와 Trust UX 시연을 세일즈 제안서의 핵심 스펙으로 전면 배치해 보세요.

<참고>

일본 디지털청, 「디지털청 장관 기자회견 기록 (최근 2026년 6월 12일)」
일본 디지털청, 「제12회 디지털 사회 구상 회의 자료 (최근 2026년 5월 22일)」
데이코쿠데이터뱅크(TDB), 「生成AIに関する企業の動向調査（2026年3月調査）」 (생성 AI에 관한 기업 동향 조사, 최근 2026년 5월 발표, 유효응답 10,312사)
도쿄상공리서치(TSR), 「生成AIに関するアンケート調査」 (생성 AI에 관한 앙케트 조사, 최근 2026년 4월 발표, 유효응답 6,327사)

]]>

MCP 새로운 스펙 총정리: 무엇을 결정하고 바꿔야 할까?

지난 7월 28일, MCP(Model Context Protocol) 스펙의 새 버전 2026-07-28이 확정됐습니다. MCP 공개 이후 가장 큰 개정으로, 변경 이력(changelog)에 굵직한 변경만 9건이 올라와 있습니다. 클로드 코드(Claude Code)나 커서(Cursor) 같은 코딩 에이전트에 MCP 서버를 붙여 쓰는 환경에 직접 해당하는 내용들입니다.

다행히 오늘 당장 MCP 설정을 바꾸지 않는다고 해서 기존 동작에 문제가 생기는 건 아닙니다. 공식 발표도 “기존 클라이언트와 서버는 오늘도, 7월 28일에도 문제없이 동작한다(nothing breaks today, and nothing breaks on July 28 either)”라고 분명하게 밝혔습니다.

하지만, 변경의 폭이 넓어 스테이트리스(stateless) 전환이라는 헤드라인 하나만 보고 넘어가면 중요한 내용들을 놓치기 쉽습니다. 그런 만큼 이 글에서는 이번 개정의 변화 전체를 6개로 나누어 하나씩 설명하고, 지금 MCP를 쓰고 있는 사용자라면 무엇을 알아두고 무엇을 결정해야 하는지 정리해 보겠습니다.

MCP 개편 항목 한눈에 보기

우선 공식 변경 이력의 항목들을 성격에 따라 다음 6가지로 구분하여 표로 정리해 볼 수 있습니다.

2026-07-28 개정의 변화 전체: 6가지 분류 <출처: 작가>

참고로 MCP는 앤트로픽(Anthropic)이 만들었고 2025년 12월부터 리눅스 재단 산하 AAIF(Agentic AI Foundation, 에이전틱 AI 재단)에 기부되어 중립 재단 아래에서 관리되고 있습니다. 이번 릴리스는 그 체제에서 나온 첫 대규모 개정이며 릴리스 후보(RC, Release Candidate)가 5월 21일에 나와 10주의 검증 기간을 거쳐 확정됐습니다.

그러면 6가지 주요 변화를 하나씩 함께 보겠습니다.

1. 스테이트리스 코어: 세션이 사라진 이유와 방식

가장 큰 변화로, 이로 인해 나머지 변화들이 생겼다고 볼 수 있습니다.

기존 핸드셰이크 구조의 문제

기존 MCP에서 클라이언트(코딩 에이전트)와 서버(도구 제공자)는 요청을 주고받기 전에 확인 절차부터 거쳤습니다. 즉, 클라이언트가 initialize 요청으로 “나는 이런 기능을 지원한다”라고 알리면 서버가 세션(session) ID를 발급해 돌려주는 핸드셰이크(handshake) 구조였습니다. 이후 모든 요청에는 Mcp-Session-Id 헤더로 발급받은 세션 ID를 함께 보내야 했습니다.

물론 이 구조를 쓴다 해도 로컬에서 서버를 1개 띄웠을 경우에는 문제가 되지 않습니다. 하지만 원격에 여러 대로 늘려 운영하는 순간, 문제가 생깁니다. 세션이 특정 서버에 묶여 있다 보니 요청 분배와 장애 복구에서 문제가 일어날 수 있습니다. 특히, 같은 클라이언트의 요청은 세션을 기억하는 서버 인스턴스로만 보내야 하므로 일반 로드밸런서(load balancer)의 라운드로빈 분배 대신 스티키 세션(sticky session) 같은 장치가 필요했습니다. 결국 그 인스턴스가 죽으면 세션도 함께 사라졌습니다.

여기에 세션을 만들고 관리하고 나중에 정리하는 코드까지 서버 개발자가 직접 구현해야 하다 보니 버그와 메모리 누수로 이어지는 경우도 많았습니다. 스펙 개선 제안 문서인 SEP-2575(Specification Enhancement Proposal)를 보면, 이러한 문제들이 많이 등장합니다.

MCP 코어 메인테이너인 MS 개발자 케이티 맥카프리(Caitie McCaffrey)의 릴리스 직후 인터뷰에 따르면, 호스트마다 세션 기능의 구현 방식이 제각각이거나 아예 올바르지 않아 상태 유지가 프로토콜에서 제대로 작동한 적이 없었다고 합니다. 실제 사용 사례의 약 90%는 그 기능을 쓰지도 않았다고 합니다. 그래서 이번 2026-07-28 개정이 이 문제들을 해결했습니다.

새로운 스펙이 문제를 해결한 방법

그렇다면 새로운 스펙은 이 문제를 어떻게 풀었을까요?

답은 “처리에 필요한 정보를 요청 하나에 전부 담는다(self-contained)”입니다. 매 요청의 _meta 필드에 프로토콜 버전과 클라이언트 기능 목록이 필수로 실립니다. 어떤 서버 인스턴스가 받아도 그 요청 하나만 보고 독립적으로 처리하도록 했습니다. 서버 정보가 궁금하면 server/discover라는 요청으로 지원 버전과 기능을 물어볼 수 있고, 이 요청은 모든 서버가 반드시 지원하게 됩니다.

세션 기반(구 스펙) 요청 흐름과 스테이트리스(신 스펙) 요청 흐름 비교 <출처: 작가>

변경에 따른 두 가지 오해

두 가지 오해를 짚고 넘어가는 게 좋겠습니다. 첫째, 세션이 없어졌다고 해서 상태 자체가 금지된 것은 아닙니다. 장바구니처럼 여러 호출에 걸친 상태가 필요한 서버는, 생성 도구가 basket_id 같은 명시적 핸들(handle)을 돌려주고 이후 호출마다 그 식별자를 인자로 받는 방식으로 바뀌게 됩니다. 기존에는 이러한 상태가 전송 계층에서 세션으로 관리되어 모델이 그 존재를 보기 어려웠습니다. 그러나 이제는 핸들 방식으로 변경되면서 도구의 인자와 반환값처럼 모델이 직접 볼 수 있는 데이터 형태로 오갑니다.

둘째, 끊긴 스트림을 이어받는 재개(resumability) 기능도 함께 사라졌습니다. 스트림을 이어받으려면 서버가 직전까지 보낸 내용을 기억하고 있어야 하는데, 상태를 남기지 않는다는 새 원칙과 맞지 않기 때문입니다. 응답 스트림이 끊기면 클라이언트는 새 요청으로 다시 시도해야 하고, 오래 걸리는 작업은 뒤에서 설명할 Tasks 확장이 담당하게 됐습니다.

왜 기존 방식과 호환되는 방식을 선택하지 않고 전면적인 개정으로 진행하게 되었을까요? 두 상호작용 모델을 병행하면 프로토콜과 모든 구현체가 두 벌의 로직을 만들고 유지해야 해서 복잡도와 버그 여지가 커집니다. 그래서 메인테이너들은 한 번에 정리하는 쪽이 생태계 전체에 낫다고 판단했습니다. (보다 상세한 내용은 SEP-2575 문서에 기록되어 있으니 참고하시기 바랍니다.)

2. 통신 방식 변경: 서버가 더 이상 클라이언트를 호출하지 않음

세션이 사라지면서 서버가 클라이언트와 연결을 계속 유지한다는 전제도 사라졌기 때문에, 통신 방식도 함께 달라졌습니다.

기존에는 서버가 역으로 클라이언트에 요청을 보낼 수 있었습니다. 도구 실행 중에 사용자 입력을 요청하는 엘리시테이션(elicitation)이 대표적입니다. 신 스펙에서 서버는 JSON-RPC 요청을 시작할 수 없도록 했고 이런 상호작용은 MRTR(Multi Round-Trip Requests, 다중 왕복 요청)이라는 패턴으로 바뀌었습니다. 서버가 클라이언트를 직접 호출하는 대신 “추가 입력이 필요하다”는 중간 결과를 돌려주면 클라이언트가 입력을 채워 원래 요청을 다시 보내는 방식입니다. 이때 서버는 진행 상태를 requestState라는 문자열로 내보내고 클라이언트가 그대로 돌려줍니다.

그런데 이 값은 클라이언트를 거쳐 돌아오기 때문에, 서버가 보낸 그대로라는 보장이 없습니다. 그래서 스펙은 이 값을 믿지 말고 외부에서 온 입력처럼 검증하도록 명시합니다. 인가나 비즈니스 로직에 영향을 준다면 HMAC(Hash-based Message Authentication Code, 해시 기반 메시지 인증 코드) 같은 무결성 보호가 필수입니다. SDK가 이를 위한 도구를 제공합니다.

[노트] 엘리시테이션(elicitation)이 무엇인가요?

서버가 도구를 실행하다가 사용자에게 추가 입력이나 확인을 요청하는 기능입니다.
예를 들어 배포 도구가 실행 도중에 “어느 환경에 배포할까요?”라고 물어보고 답을 받아 이어가는 상호작용이 여기에 해당합니다.

서버에서 클라이언트로 가는 통신에는 응답을 요구하는 요청 말고도 일방적으로 알려주기만 하는 알림이 있는데, 이 알림 채널도 하나로 합쳐졌습니다. 기존에는 알림을 받는 통로가 2개여서, 서버가 보내는 일반 알림은 클라이언트가 HTTP GET으로 열어 둔 상시 연결로 받고 리소스 변경 알림은 별도의 구독 요청으로 신청했습니다. 게다가 서버가 아무 때나 일방적으로 알림을 보낼 수 있어서 클라이언트는 쓰지도 않을 알림까지 받아서 처리해야 했습니다. 서버도 어느 클라이언트가 듣고 있는지를 세션 상태로 관리해야 했습니다.

신 스펙은 이 둘을 subscriptions/listen이라는 단일 스트림으로 통합하고 받고 싶은 알림 종류(도구 목록 변경 등)를 클라이언트가 명시적으로 신청하는 옵트인 방식으로 정리했습니다. 이제 클라이언트는 신청한 알림만 받고, 서버는 신청받은 알림만 처리해서 보냅니다.

3. 인프라 친화적 개선: HTTP 헤더와 캐시 표준화로 운영 부담을 줄임

운영하는 쪽에 이득이 집중된 변화입니다. 이제 Streamable HTTP 요청에는 어떤 메서드인지(Mcp-Method), 어떤 도구를 호출하는지(Mcp-Name)가 HTTP 헤더로 필수로 실리도록 했습니다. 게이트웨이나 로드밸런서가 요청 본문(JSON)을 뜯어보지 않고도 특정 도구 호출만 골라서 다른 경로로 보내거나 차단하거나 기록하는 일을 할 수 있게 된 것입니다. 실제로 깃허브(GitHub)는 자사 MCP 서버를 신 스펙으로 옮기면서 본문 검사(deep packet inspection) 없이 헤더 기반 라우팅으로 바꿨다고 밝혔습니다.

캐시 규칙도 표준화됐습니다. 도구 목록(tools/list) 같은 조회 결과에는 캐시 유효 시간 힌트인 ttlMs와 공유 캐시 허용 여부인 cacheScope가 필수로 붙게 됐습니다. 목록이 연결마다 달라지는 것도 금지되어 같은 서버라면 누가 물어도 같은 목록이 나오는 캐시 가능한 구조를 전제로 삼았습니다. 여기에 요청이 여러 구성 요소를 거칠 때 하나의 흐름으로 이어서 추적하는 분산 추적도 오픈텔레메트리(OpenTelemetry) 기준으로 연동 방법이 문서화됐습니다. 이제 MCP 트래픽을 일반 웹 트래픽처럼 관리 도구로 다룰 수 있습니다.

4. 인증과 보안 강화: OAuth 실전 배포에 맞게 다듬음

원격 MCP 서버의 인증 계층도 여러 곳이 수정되었습니다. 고친 항목 하나하나는 작은 기술적 수정이지만 기업의 실제 OAuth·OIDC(OpenID Connect) 배포 환경에서 통용되게 만든다는 점에서는 모두 동일한 방향성을 가지고 있습니다.

특히, 인가 응답에 발급자(issuer) 정보를 실어, 응답을 보낸 인가 서버가 클라이언트 자신이 요청했던 서버와 같은지 확인하게 하는 요건이 더해졌습니다. 공격자가 서로 다른 인가 서버의 응답을 뒤섞어 인가 코드를 가로채는 경로를 막기 위한 것입니다. 또한 클라이언트 자격 증명은 발급한 서버에만 쓸 수 있게 묶어 다른 서버에 재사용하지 못하게 했습니다.

사실 가장 눈에 띄는 변화는 클라이언트 등록 방식입니다. 그동안 쓰이던 동적 클라이언트 등록(DCR, Dynamic Client Registration)은 더 이상 사용을 권고하지 않는 상태(deprecated)로 변경되었습니다. 당장 지원이 끊기는 것은 아니고 기존 환경과의 호환을 위해 당분간 유지되지만 새로 만드는 구현에서는 쓰지 말라는 뜻입니다. 그 대신 HTTPS URL 자체가 클라이언트 ID가 되는 CIMD(Client ID Metadata Documents, 클라이언트 ID 메타데이터 문서)가 권장 방식으로 지정됐습니다. 클라이언트가 자기 메타데이터를 URL로 게시하면 어떤 인가 서버에서든 재등록 없이 통하는 방식입니다.

개인이 로컬에서 stdio 방식으로 서버를 쓰는 경우에는 이 인가 스펙이 적용되지 않으니, 원격 HTTP 서버를 만들거나 운영하는 쪽에서 대응해야 하는 내용이라고 보면 됩니다.

5. 확장 프레임워크: 코어는 작게, 나머지는 확장으로

이번 개정의 설계 방침이 잘 드러나는 변화입니다. 코어 프로토콜에는 extensions 필드가 추가되어 클라이언트와 서버가 각자 지원하는 확장을 이 필드로 알립니다. 코어에 지금 담지 않기로 한 기능들은 공식 확장으로 분리하고 버전을 따로 매겨 관리하는 형태가 되었습니다. 쿠버네티스가 코어 API 밖에서 Gateway API 같은 프로젝트를 별도 버전으로 발전시켜 온 것과 비슷한 관리 방식이라고 볼 수 있습니다.

Tasks: 오래 걸리는 작업 처리가 코어의 실험 기능에서 공식 확장(io.modelcontextprotocol/tasks)으로 이동했습니다. 서버가 작업 핸들을 돌려주면 클라이언트가 폴링(polling, 주기적으로 상태를 물어보는 방식)으로 진행 상황을 확인하고 접속이 끊겼다 돌아와도 결과를 받아갈 수 있습니다. 스트림 재개가 사라진 부분을 대신하는 기능이기도 합니다.
MCP Apps: 서버가 채팅 화면 안에 렌더링되는 대화형 UI를 제공할 수 있게 하는 확장입니다.
EMA(Enterprise-Managed Authorization, 기업 관리형 인가): 이번 개정과 묶여 자주 언급되는 기업용 인증 확장인데, 실제로는 이번 코어 스펙의 일부가 아니라 별도 확장으로 이미 6월에 안정화됐습니다. 이 구분이 매우 중요한 이유는, 스펙을 따라가는 일과 EMA를 도입하는 일이 서로 별개의 결정이기 때문입니다. 이를테면 직원이 회사의 IdP(Identity Provider, Okta 같은 신원 제공 서비스)에 한 번 로그인하면 서버마다 개별 동의 화면을 거치지 않고 회사가 승인한 MCP 서버들이 연결되는 방식입니다. IdP·클라이언트·서버 삼자가 모두 지원해야 동작하는 옵트인 기능이기에, 개인 사용자와는 무관합니다. 사내 MCP 접근 통제를 고민하는 조직이 지켜볼 영역입니다.

확장은 전부 선택 사항이고 기본으로 꺼져 있습니다. 코어를 가볍게 유지하면서 필요한 조직만 필요한 확장을 켜는 구조입니다.

6. 기능 정리와 수명주기: 세 기능이 제거 수순에 들어감

마지막은 기능을 덜어내는 변화입니다. Roots, Sampling, Logging 세 기능이 더 이상 사용을 권고하지 않는 상태가 됐습니다. 지금은 동작하지만 신규 구현에는 넣지 말라는 의미입니다. 각 기능이 하던 일과 스펙이 제시한 대안을 정리하면 다음과 같습니다.

이번에는 이렇게 기능을 정리하는 절차 자체도 정해진 규칙을 따르게 되었습니다. 기능이 이 상태로 지정되면 최소 12개월은 유지된 뒤에야 제거될 수 있다는 수명주기 정책이 정식 문서로 만들어진 것입니다. 따라서 위 세 기능은 적어도 2027년 7월 28일까지는 그대로 유지되며 실제 제거는 그 이후에 나오는 첫 리비전에서야 가능합니다. 그 시점이 되어도 자동으로 제거되는 것은 아니고 메인테이너가 릴리스를 준비하며 결정하는 것이라 더 늦어질 수도 있습니다.

그에 반해 2024년 말의 초기 전송 방식인 HTTP+SSE(Server-Sent Events)는 정리 절차가 훨씬 앞서 있습니다. 아직 이 방식을 쓰고 있다면 가장 시급한 이전 대상입니다. 그러면 구 스펙(2025-11-25) 자체는 언제까지 지원될까요? 아쉽게도, 종료일은 명시되어 있지 않습니다. 수명주기 정책이 리비전이 아니라 기능 단위로 적용되기 때문입니다.

그래서 지금, 사용자 유형별로 해야 할 일

그럼 이제부터 각자의 자리에서 무엇을 하면 되는지 정리해 보겠습니다.

MCP 서버를 붙여 쓰는 사용자

원칙적으로 할 일이 없습니다. 버전 협상, 그리고 신 스펙이 통하지 않는 상대를 만나면 기존 방식으로 자동 전환해 다시 시도하는 폴백(fallback)은 클라이언트와 SDK가 처리합니다. 깃허브도 자사 MCP 서버를 전환하면서 “사용자는 아무것도 할 필요가 없다”라고 얘기했습니다.

하지만 예외가 두 가지 있을 수 있습니다. 하나는 설정에 SSE 전송을 명시적으로 고정해 둔 경우로, 클라우드플레어(Cloudflare)는 자동 감지나 Streamable HTTP로 바꾸라고 안내됩니다. 다른 하나는 회사 내부 MCP 서버가 세션에 상태를 묶어 두는 경우입니다. 접속 시점 헤더로 받은 테넌트(tenant) 정보를 세션에 저장해 쓰는 유형의 서버라면 신 스펙 환경에서 동작이 어긋날 수 있습니다. 실제로 전환 시점 전후 이런 유형으로 추정되는 동작 이상 보고도 올라왔습니다.

추가로 이 글을 작성하는 시점(8월 5일) 기준으로도 클라이언트 쪽은 공개된 정보가 부족하다는 점을 알아두면 좋겠습니다. 서버와 플랫폼에 대한 지원과 관련된 내용은 많이 나왔지만 앤트로픽은 “클로드 제품군에 순차 적용 중”이라고만 밝혔고 커서의 변경 이력에는 관련 언급이 아직 없습니다. 오픈AI 코덱스(Codex) CLI는 기능 플래그 등록에 이어 일부 기반 코드를 넣는 단계라, 어느 클라이언트가 어느 버전부터 신 스펙을 지원하는지 정리된 표는 아직 없습니다.

서버를 만드는 개발자

마이그레이션을 실제로 계획해야 하는 시점입니다.

우선 스펙 확정과 같은 시기에 주요 SDK 안정 버전이 나왔습니다. 파이썬은 mcp 2.0.0이 릴리스 당일 나왔습니다(이제 pip install mcp가 2.x를 설치하므로, 준비가 안 된 프로젝트는 mcp>=1.28,<2처럼 상한을 거는 것이 공식 권고입니다). 타입스크립트는 기존 @modelcontextprotocol/sdk가 1.x에서 멈추고 @modelcontextprotocol/server 등 새 패키지의 2.0.0으로 나뉘었습니다. 그래서 새로 만드는 MCP 서버라면 처음부터 신 스펙(SDK 2.x)으로 시작하면 되고 구 스펙으로 새로 만들 이유는 없습니다.

다행히 세션 관리 코드는 모두 지워집니다. 실제로 깃허브 MCP 서버를 옮긴 메인테이너 샘 모로우(Sam Morrow)도 얻은 것밖에 없다고 말할 정도입니다.

대신 손이 가는 곳은 세션에 두던 상태를 핸들이나 외부 저장소로 넘기는 일, 엘리시테이션을 MRTR 패턴으로 다시 작성하는 일, 그리고 오래 걸리는 작업을 Tasks 확장으로 옮기는 일입니다. 또, 파이썬 SDK 2.0.0에는 Tasks 확장이 아직 구현되지 않았으므로 장기 작업 의존 서버는 조금 기다려야 합니다. 마지막으로 신/구 클라이언트를 모두 받는 양쪽 지원(dual-era) 운영이 SDK 기본값이므로, 아직 사용자 중에 기존 버전을 사용하는 경우가 있을 수 있으니 그대로 두는 게 더 안전합니다.

배포/운영하는 팀

이번 변경으로 운영 구성이 실제로 단순해집니다. 스티키 세션과 세션 공유 저장소가 필요 없어지고 쿠버네티스(Kubernetes) 서비스 뒤에 평범한 라운드로빈으로 레플리카를 늘리는 구성이 프로토콜 차원에서 성립합니다.

전환 전략으로는 게이트웨이를 앞에 두는 방법이 제시되어 있습니다. 오픈소스 MCP 게이트웨이인 에이전트게이트웨이(agentgateway)는 1.4.0 버전부터 신 스펙을 정식으로 지원합니다. 클라이언트를 일괄 업그레이드하지 않고 게이트웨이 뒤에서 서버만 먼저 올린 뒤 트래픽을 조금씩 옮기는 카나리(canary) 방식이 가능합니다.

마지막으로, 적용 여부를 어떻게 판단하면 될까요? 호환되지 않는 조합은 정해져 있습니다. 신 스펙 전용 클라이언트가 구 스펙 전용 서버를 만나거나 그 반대인 경우만 실패하고 한쪽이라도 양쪽을 지원하면 동작합니다. 따라서 당분간은 양쪽을 다 지원하는 구성이 안전합니다. 강제 전환 시점이 없고 유예도 넉넉하니, 이를 상황별로 정리하면 다음과 같습니다.

사용자 유형과 상황별 권고 정리 <출처: 작가>

마치며

결국, 이번 개정은 대다수가 쓰지 않던 기능을 걷어내고 웹에서 오래 검증된 스테이트리스 요청 모델로 돌아온 것이 가장 핵심 변화라고 볼 수 있습니다. 이는 즉, MCP가 실험적 프로토콜에서 운영 가능한 인프라로 넘어가는 단계가 된 것이라고 생각합니다.

깃허브와 클라우드플레어는 확정일 전후로 전환을 마쳤고 AWS와 마이크로소프트도 대응 방안을 내놨으니, 방향은 이미 정해진 셈입니다. 물론 이 글은 스펙과 공식 발표, 릴리스 직후 며칠간의 생태계 반응을 기준으로 쓴 것이라, 클라이언트 지원 현황 같은 부분은 앞으로 몇 주 사이에 빠르게 갱신될 수 있습니다. 영향을 크게 받는 분들이라면 꾸준히 커뮤니티를 주목하는 것이 좋겠습니다.

참고로, 저는 이 중에서도 1번 항목인 스테이트리스 전환이 실제 운영 환경에서 어떤 차이를 만드는지가 궁금해졌습니다. 따라서 구 스펙 서버와 신 스펙 서버를 같은 쿠버네티스 클러스터에서 돌려 스케일아웃과 파드 교체 상황을 실측하는 실험을 준비하고 있습니다. “스티키 세션이 필요 없어졌다”는 말이 수치로는 어떻게 나타나는지, 괜찮은 측정 결과가 나온다면 또 소개해 보겠습니다.

참고 자료

MCP 2026-07-28 공식 발표: https://blog.modelcontextprotocol.io/posts/2026-07-28/
스펙 변경 이력(changelog): https://modelcontextprotocol.io/specification/2026-07-28/changelog
SEP-2575 (Make MCP Stateless): https://modelcontextprotocol.io/seps/2575-stateless-mcp
SDK 베타 발표(호환성 정책 포함): https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
Arcade.dev 메인테이너 인터뷰: https://www.arcade.dev/blog/mcp-maintainers-interview
GitHub MCP 서버 전환 안내: https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

작가

조훈 (CNCF&AAIF 앰버서더)

쿠버네티스 및 AI 네이티브 기술 전문가로, CNCF와 에이전틱 AI 재단(AAIF) 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩을 운영하며 인프라 자동화 기술을 연구하고 공유한다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로 활동 중이며, 맞춤형 인프라 교육, 쿠버네티스 비용 최적화, 멀티 LLM 및 AI 에이전트 비교 검증 등 다양한 실무 PoC를 수행하고 있다. 최근 출간한 『AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드』를 포함해 총 5권의 IT 서적을 집필했으며, 인프런 강의 및 요즘IT 기고 등 지식 공유 활동을 이어가고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.

]]>

[티켓 증정 이벤트] 개발자·PM도 알아야 할 검색의 미래, 구글에게 직접 듣는다

본 콘텐츠는 Search SEOul 2026과의 파트너십으로 제작되었으며, 요즘IT 독자를 위한 티켓 증정 이벤트를 포함합니다.

“검색은 마케팅팀 일”이라고만 생각하셨나요? 이제 개발자, PM도 ‘검색’에 주목해야 합니다. 사용자가 제품이나 서비스를 찾는 경로 자체가 바뀌었기 때문이죠. AI가 검색 결과 화면 구조를 다시 짜고, LLM이 직접 답을 내놓으면서, “우리가 만든 서비스가 검색엔진과 AI 모델에게 어떻게 읽히는가”가 곧 제품의 발견 가능성을 결정합니다.

렌더링 방식, 정보 구조, 배포 파이프라인처럼 원래 개발자·PM의 영역이었던 것들이 이제 검색·GEO(생성형 엔진 최적화) 전략과도 직접 맞닿아 있는 셈입니다.

실제로 요즘IT에서도 한 엔지니어가 서비스 코드를 건드리지 않고, CDN 엣지에서 GEO 태그를 자동 삽입하는 실험을 소개하기도 했습니다. GEO가 콘텐츠 문제를 넘어, 운영과 인프라의 문제가 되고 있다는 걸 보여주는 사례죠.

그래서 다가오는 9월, 마포에서 조금 특별한 SEO 컨퍼런스가 열립니다. 올해로 2회째를 맞는 Search SEOul(서치 서울) 2026입니다.

<출처: Search SEOul 홈페이지>

“한국 최초의 글로벌 SEO 컨퍼런스”인 서치 서울은, 그동안 미국·유럽·동남아시아에서만 열리던 글로벌 SEO 행사를 한국으로 가져오겠다는 문제의식에서 출발했습니다. 세계에서 가장 빠르게 움직이는 디지털 시장 중 하나인 한국에서, 정작 해외와 국내 SEO 전문가가 만나는 자리가 없었다는 건데요.

이번 서치 서울 2026에선 구글 검색팀, Ahrefs, Common Crawl Foundation 등 SEO·GEO 업계의 쟁쟁한 실무자들이 직접 발표에 나섭니다.

특히 올해는 20명 이상의 연사와 10개국 이상이 참가하여, 더 큰 규모로 구성됐습니다. 행사는 다가오는 9월 3일부터 4일까지 양일간 호텔 나루 서울 엠갤러리에서 열립니다.

어떤 행사인가

이번 컨퍼런스의 목적은 한국 고유의 검색 환경과 해외의 SEO 혁신을 서로 연결하고, 지금 SEO 업계에서 벌어지는 가장 큰 변화의 중심에 있는 전문가들을 한자리에 모으는 데 있습니다.

AI가 검색 결과 화면의 구조를 바꾸면서, 이제는 사람들이 검색 결과 페이지(SERP)만 보고 구매를 결정하지 않는 시대가 됐는데요. 이건 마케팅 지표만의 문제가 아닙니다. AI가 웹페이지를 어떻게 파싱하고, 어떤 정보를 우선 인용하는지가 곧 제품이 발견되는 방식을 좌우하기 시작했다는 뜻이니까요. SEO·개발·프로덕트가 따로 움직일 수 없다는 이야기가 나오는 이유이기도 합니다.

현재 인하우스 SEO를 담당하거나, 마케팅팀의 리드, 혹은 에이전시, 테크니컬 SEO 담당자, 콘텐츠·PR 담당자, 이커머스·글로벌 마케터, AI 검색 실무자라면 충분히 주목해 볼 만한 행사입니다. 그리고 검색 유입 지표를 자주 들여다보거나, 자사 제품이 AI 검색 결과에 얼마나 잘 노출되는지 궁금했던 개발자·PM 등 프로덕트 빌더에게도 유익할 겁니다.

프로덕트 메이커라면 이 세션들을 주목하세요!

그럼 서치 서울 2026에서 준비한 세션 중 특히 개발자·PM 등 프로덕트 메이커가 참고할 만한 것들을 짚어봤습니다.

가장 주목해 볼 만한 세션은 2일차 오후 2시, 구글 검색팀 Search Relations Analyst인 게리 일리스의 「블루 링크에서 AI Overviews까지」입니다. 검색 결과 화면이 왜 지금의 모습이 됐는지, 그 변화를 만든 구글 검색팀에서 직접 설명하는 자리입니다. 프로덕트가 검색에 노출되는 방식이 왜, 어떻게 바뀌었는지를 구글에 직접 들을 기회는 흔치 않습니다.

렌더링과 배포 파이프라인을 다루는 세션도 눈에 띕니다. 1일차 오후 SEO 및 분석 컨설턴트인 조나단 무어의「LLM을 위한 자바스크립트 디버깅」에서 자바스크립트로 렌더링한 화면이 LLM에게 어떻게 읽히는지를 다룹니다.

2일차 오전에 The Aspen Group 시니어 디렉터, 조리 포드의「개발 파이프라인의 SEO 통합」은 SEO 요구사항을 배포 과정 안으로 끌고 들어오는 이야기입니다.

두 세션 다 마케팅팀에서 요청서가 넘어오기 전에, 개발 단계에서 먼저 알아두면 좋을 주제입니다.

정보 구조 자체를 다시 생각해보고 싶다면, 1일차 오전 Artience 최윤희 님의 「다음 GEO 시대를 위한 지식 구조화와 온톨로지」도 챙겨볼 만합니다. AI를 향해 글을 쓰는 것을 넘어 지식 자체를 구조화해야 한다는 문제의식을 다루는 세션으로, GEO를 콘텐츠 작성의 문제가 아니라 정보 설계의 문제로 다시 보게 만드는 자리입니다.

1일 차 오후에는 Blogtalk의 황성원 대표가 「네이버 블로그 SEO와 한국 검색 생태계」라는 주제로 발표합니다. 전체 어젠다에서 한국 검색 환경을 정면으로 다루는 유일한 세션이라, 국내 서비스를 운영하는 분들에게 특히 추천합니다.

연사진 라인업 일부 캡처 <출처: Search SEOul 홈페이지>

세션 대부분은 영어로 진행되지만, 실시간 한글 자막이 상시 제공된다고 하니 참고해 주세요!

현재 국내에서 티켓을 구매하실 분들은 이벤터스 페이지를 통해 신청하실 수 있습니다. 3~4인 이상 단체로 참가하실 예정이라면, host@search-seoul.com으로 문의 주시면 추가 할인 혜택을 안내받으실 수 있습니다.

요즘IT 독자 대상 ‘2-Day Pass 증정 이벤트’

요즘IT는 이번 Search SEOul 2026의 공식 미디어 파트너로 함께하게 되었는데요. 이에 요즘IT 독자 두 분께 Search SEOul 2026 2-Day Pass(49만 원 상당) 티켓을 드리는 이벤트를 진행합니다. 9월 3~4일 열리는 본 컨퍼런스 이틀을 모두 참석할 수 있는 티켓입니다.

이벤트 안내

경품: Search SEOul 2026 2-Day Pass 티켓 (49만 원 상당) / 9월 3~4일 양일 간 참석 가능
당첨 인원: 2명
응모 방법: 댓글로 이번 서치 서울 2026에서 “가장 듣고 싶은 ‘세션’이 무엇인지”남겨주세요!
응모 기간: 2026년 8/10일(월) 11:00부터 ~ 8월 20일(목) 23:59분까지
당첨자 발표: 2026년 8/21(금) 당첨자 추첨 및 댓글을 통해 발표
당첨자 회신 기한: 당첨자의 경우, 2026년 8월 24일(월) 24시까지 당첨자 정보 회신 필요 (*기한 내 미회신 시 예비 당첨자 추첨 후 승계)

응모 전 확인해주세요!

참석권은 이벤터스 쿠폰으로 지급되어, 당첨자에게는 [이벤터스 계정]이 필요합니다.
쿠폰으로 티켓을 발급받는 과정에서 [이름, 이메일, 연락처, 소속, 부서, 직함]을 입력합니다.
당첨자 발표 이후 8월 24일(월) 23:59까지 회신해주셔야 하며, 기한 내 미회신 시 예비 당첨자에게 참석권이 넘어가니, 이 부분 유의해주세요!

수집하는 개인정보

티켓 발급용: 이름, 이메일, 연락처, 소속, 부서, 직함 (이벤터스 계정 필요)
제세공과금 원천징수용: 성명, 주민등록번호, 연락처, 주소 (소득세법상 원천징수·지급명세서 제출 목적, 법정 보존기간 후 파기, 제출 거부 시 경품 지급 불가)

유의사항

경품 소득세법상 기타소득으로 발생하는 제세공과금 22%는 전액 주최 측이 부담하며, 당첨자 부담금은 없습니다. (원천징수영수증 요청 시 발급 가능)
응모는 개인 자격으로만 가능하며, 국내 거주자에 한합니다.

서치 서울 2026과 관련된 상세 정보는 공식 홈페이지에서, 세션별 시간표는 어젠다 페이지에서 확인하실 수 있습니다.

이번 서치 서울 2026에서 실무에 바로 적용할 수 있는 SEO, GEO 노하우를 만나고 싶다면, 지금 바로 댓글로 ‘가장 기대되는 세션’을 남겨서 참여해 주세요!

]]>

테스트 코드 없이 웹을 검수하는 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

]]>

자동화할 일을 고르는 것도 실력이다

비개발자가 넉 달에 도구 12개를 쌓으며 세운 기준

지난 글 비개발자가 400페이지 서명 검사를 자동화하며 고민한 것에서 나는 400페이지가 넘는 점검철의 서명 검사를 자동화한 이야기를 했다. 도구 하나를 어떻게 만들었는지에 대한 기록이었다. 그런데 그 도구는 내가 넉 달 동안 만든 열두 개 중 하나일 뿐이다. 이번 글은 ‘어떻게 만들었나’가 아니라, 열두 개를 앞에 두고 무엇을 먼저 만들고 무엇은 아예 만들지 않았나에 대한 이야기다.

솔직히 처음엔 나도 ‘많이 만드는 것’이 실력인 줄 알았다. 아니었다. 도구를 몇 개 만들고 나서야, 진짜 어려운 건 코드를 짜는 일이 아니라 손댈 일을 고르는 일이라는 걸 알았다. 반복 업무는 사방에 널려 있는데, 시간과 체력은 정해져 있다. 그래서 이 글은 코딩을 못 해서 자동화를 미뤄 둔 실무자, 그리고 팀에 자동화를 붙여 보려는 분들을 위한 글이다. 도구 만드는 법을 알려 주는 글은 많지만, 무엇을 만들지 고르는 기준을 실제 사례로 이야기하는 글은 드물었기 때문이다.

넉 달간 만든 자동화 도구 12개를 유형별로 정리한 지도 <출처: 작가, 클로드로 생성>

넉 달에 열두 개, 먼저 전체를 펼쳐 놓고 시작한다

기준 이야기를 하기 전에, 내가 실제로 무엇을 만들었는지부터 펼쳐 놓는 편이 낫겠다. 아래가 넉 달 동안 만든 열두 개다. 하나하나 자세히 볼 필요는 없다. 뒤에서 대표 몇 개만 깊이 들여다볼 것이고, 이 표로는 ‘이런 것들이 쌓였다’는 감만 잡으면 된다.

열두 개를 한 줄로 줄이면 이렇다. 검증이 셋, 수집·정산이 넷, 나머지가 입력·스케줄·변환이다. 처음부터 이렇게 나눠 만든 건 아니다. 그때그때 급한 걸 하나씩 처리했을 뿐인데, 돌아보니 이런 모양이 되어 있었다. 그런데 이 ‘돌아보니’가 중요하다. 어떤 일은 도구로 만들었고 어떤 일은 손대지 않았는데, 그 갈림길에 나름의 기준이 생겨 있었다.

무엇부터 골랐나? 나를 움직인 네 가지 기준

나는 개발 지식이 얕아서, 멋있는 걸 만들 능력이 없었다. 그래서 오히려 ‘이걸 만들 가치가 있나’를 매번 따질 수밖에 없었다. 그 과정에서 굳어진 기준이 네 가지다. 하나씩 풀어 본다.

첫째, 얼마나 자주 하는 일인가 (빈도)

아무리 귀찮아도 1년에 한 번 하는 일이라면, 도구를 만드는 시간이 더 아깝다. 반대로 매달, 매주 돌아오는 일이라면 한 번 만들어 두는 값어치가 매번 쌓인다. 나는 ‘이 일을 앞으로 몇 번이나 더 할까’를 먼저 셌다.

둘째, 한 번에 얼마나 오래 걸리나 (소요 시간)

빈도가 높아도 30초면 끝나는 일은 굳이 자동화하지 않았다. 사람이 한 번에 오래 매달려야 하는 일, 그래서 하고 나면 진이 빠지는 일을 우선했다.

셋째, 틀리면 얼마나 위험한가 (리스크)

이건 조금 결이 다르다. 자주 하지 않고 오래 걸리지 않아도, 틀리면 사고가 나는 일이 있다. 마감 서류에서 서명 하나를 놓치는 것 같은. 이런 일은 시간을 아끼려고가 아니라, 실수를 막으려고 자동화했다.

넷째, 다시 쓸 수 있는가 (재사용성)

한 번 만든 방식을 다른 일에도 붙일 수 있으면, 그 도구의 값어치는 눈에 보이는 것보다 크다. 뒤에서 이야기하겠지만, 나는 도구 하나를 만들면서 만든 ‘실행 방식’ 하나를 이후 여러 도구에 그대로 재활용했다.

이 네 가지를 하나의 체크리스트처럼 놓고 봤다. 어느 하나만 해당한다고 바로 만들지 않았고, 여러 항목에 걸리는 일부터 손댔다. 실제로는 네 가지가 다 걸리는 일은 드물었다. 그래서 완벽한 1순위를 찾기보다, 두세 개에 걸리는 일이면 일단 손대는 쪽을 택했다. 그리고 이 기준이 가장 선명하게 드러난 것이 아래 대표 사례들이다.

대표 사례로 보는 선별, 세 개만 깊이 들여다본다

열두 개를 다 설명하면 지루하고, 사실 다 볼 필요도 없다. 기준이 어떻게 작동했는지 잘 보이는 세 개만 골랐다.

사례 하나, 서명 검사: 빈도도 높고, 틀리면 위험하다

내가 가장 먼저 완성한 것이 지난 글에서 다룬 서명 누락 검사 도구다. 왜 이걸 첫 번째로 골랐는지가 이 글의 맥락에서는 더 중요하다. 이 일은 매달 돌아오고(빈도), 한 번에 30분에서 한 시간이 걸리며(시간), 하나라도 놓치면 마감이 틀어지는(리스크) 일이었다. 내 네 가지 기준 중 셋이 동시에 걸린 셈이다. 고민할 것도 없이 1순위였다.

결과는 앞 글에서 밝힌 대로다. 400페이지가 넘는 스캔본을 눈으로 넘기며 서명란을 대조하던 30분에서 한 시간짜리 일이, 1분 남짓의 자동 분석과 한 화면 확인으로 줄었다. 무엇보다 결과가 그림이 박힌 문서 한 장으로 남아, “확인했다”가 아니라 “이렇게 확인했다”는 증빙이 함께 생겼다.

서명 검사 결과 화면(마스킹본). 애매한 항목만 위로 올라오고, 사람은 마지막 1초만 확인한다. <출처: 작가, 클로드로 생성>

사례 둘, 출근부·휴가 대조: 사람이 오래 매달리던 일

두 번째는 출근부(출퇴근 기록)와 휴가 신청서를 맞대어 보는 일이다. 매달 마감 때, 기록부에 반차나 연차로 표시된 날이 실제 휴가 신청서와 맞는지, 신청서가 빠진 건 없는지 한 장씩 대조했다. 빈도는 서명 검사와 같지만, 이건 ‘오래 걸린다’는 쪽(시간)이 더 컸다. 사람 수만큼, 날짜만큼 눈이 왔다 갔다 해야 했다.

특히 반차처럼 하루 안에서 나뉘는 휴가나, 대체휴무처럼 종류가 헷갈리는 경우에는 한 번 더 확인해야 해서 손이 더 갔다. 놓치기 쉬운 건 대단한 실수가 아니라, 기록부에는 휴가로 표시돼 있는데 정작 신청서가 빠져 있는 것 같은 작은 어긋남이었다. 이런 건 눈이 피로할수록 더 잘 지나친다.

이 도구는 두 서류를 나란히 읽어 휴가 표시를 서로 맞춰 보고, 한쪽에만 있고 다른 쪽에 없는 것만 붉게 띄운다. 눈으로 30분쯤 걸리던 대조가 1분으로 줄었다. 결과는 대시보드 형태의 리포트로 나와서, 나는 애매한 항목만 한눈에 보고 직접 확인했다. 여기서도 원칙은 서명 검사와 같았다. 최종 판단은 사람이 한다. 도구는 어긋난 지점만 찾아 눈앞에 모아 줄 뿐이다.

실제로 돌려 보니, 사람이 훑을 때는 지나치기 쉬운 한두 건이 리포트 맨 위에 붉게 떠올랐다. 시간을 줄인 것보다, ‘빠진 것을 빠짐없이 봤다’는 확신이 생긴 게 나에게는 더 컸다.

출근부·휴가신청서 대조 결과 대시보드(가명·마스킹). 누락·확인 필요만 붉게·노랗게 떠, 사람은 그것만 본다. <출처: 작가, 클로드로 생성>

기록부와 신청서를 한 건씩 맞춰 본 매칭 상세(가명·마스킹). 25건 중 어긋난 1건만 붉게 표시된다. <출처: 작가, 클로드로 생성>

사례 셋, 예산 이월: 한 번 만든 방식을 다시 쓰다

세 번째는 조금 다른 이유로 골랐다. 예산 이월 도구는 월 이익금을 다음 예산으로 넘기는 계산을 대신하는데, 이 일 자체의 빈도나 위험보다 재사용성 때문에 이야기할 값어치가 있다.

앞서 만든 도구들에서 나는 ‘점검철 파일을 아이콘 위에 끌어다 놓으면 실행되는’ 방식을 만들어 두었다. 명령어를 칠 줄 몰라도 쓸 수 있게 하려던 것이었다. 그런데 이 ‘끌어다 놓기’ 실행 방식은 서명 검사에만 쓰이는 게 아니었다. 블로그용 이미지 변환에도, 예산 이월에도 그대로 붙었다. 도구마다 하는 일은 달라도, 사람이 쓰는 입구는 똑같이 만든 것이다. 하나를 잘 만들어 두니, 다음 도구는 그 위에 얹기만 하면 됐다.

이 방식이 특히 좋았던 건, 나 말고 다른 사람도 쓸 수 있다는 점이었다. 사용법이 ‘파일을 아이콘에 끌어다 놓는다’ 한 줄이면, 길게 설명하지 않아도 옆자리 동료가 바로 따라 했다. 도구를 나 혼자 쓰는 것과 팀이 함께 쓰는 것은 값어치가 다르다. 재사용성은 나중에 시간을 아껴 주는 정도가 아니라, 도구가 나 한 사람을 넘어서게 해 주는 성질이었다.

예산 이월 도구의 처리 흐름. 파일을 끌어다 놓으면 네 단계가 자동으로 이어진다(원본은 그대로 보존). <출처: 작가, 클로드로 생성>

이월 처리 결과 리포트(금액은 예시로 축소·사업명 마스킹). 자가검증까지 끝난 뒤 사람이 최종 확인한다. <출처: 작가, 클로드로 생성>

만들지 않기로 한 것들: 고르는 눈의 반대편

‘무엇을 자동화할까’만큼 중요한 게 ‘무엇은 자동화하지 않을까’였다. 몇 가지는 만들 수 있었는데도 일부러 손대지 않았다.

하나는 어쩌다 한 번 하는 일이다. 1년에 한두 번 하는 정리 작업은, 도구를 만들고 관리하는 품이 그 일을 손으로 하는 것보다 컸다. 만들고 싶은 마음은 굴뚝같았지만, 그건 자동화가 아니라 취미가 될 참이었다.

다른 하나는 틀렸을 때 사람이 책임져야 하는 판단이다. 예를 들어 애매한 특이사항을 ‘문제없음’과 ‘조치 필요’ 중 어디로 볼지 같은 것. 이건 도구가 대신 단정하게 두면 오히려 위험하다. 그래서 이런 일은 도구가 자료를 모아 주는 데까지만 맡기고, 판단 자체는 넘기지 않았다. 앞 글에서 말한 ‘사람 먼저, 도구 나중’이 여기서도 그대로 적용됐다.

자동화를 하다 보면 ‘이것도 되네’ 하는 욕심이 붙는다. 그 욕심을 어디서 멈출지 정해 두는 것도 도구를 만드는 일의 한 부분이었다. 안 만들기로 정하고 나면, 남은 시간을 진짜 손댈 값어치가 있는 일에 쓸 수 있었다.

이 두 가지를 걸러 내는 것만으로도, 나는 헛심을 꽤 아꼈다. 고르는 눈은 결국 ‘만들 것’과 ‘만들지 않을 것’을 함께 보는 눈이었다.

하나가 다음을 부른다, 열두 개가 쌓인 방식

돌아보면 열두 개는 계획해서 나온 숫자가 아니다. 첫 번째 도구가 생각보다 잘 돌아가고, 그게 눈에 보이는 결과로 남으니, 자연스럽게 ‘그럼 저것도 되지 않을까’ 하는 생각이 따라왔다. 하나를 만들면 다음이 보였고, 앞서 만든 조각(끌어다 놓기 실행 방식 같은)을 다시 쓰니 두 번째, 세 번째는 점점 빨라졌다.

열두 개째에 이르러서는, 새로운 반복 업무를 만나면 ‘이건 며칠이면 붙이겠다’는 감이 먼저 왔다. 그 감이 생긴 것이 도구 개수보다 더 남는 것이었다. 처음엔 도구를 하나 만드는 게 목표였는데, 어느새 ‘어떤 일을 도구로 바꿀 수 있는가’를 보는 눈이 생겨 있었다.

그래서 지금 반복 업무에 지쳐 있는 분께 권하고 싶은 건 ‘열두 개를 만들라’가 아니다. 딱 하나만 골라 보라는 것이다. 앞의 네 기준으로 오늘 한 일을 훑어보면, 유난히 자주·오래·위험한 일 하나가 반드시 눈에 걸린다. 그 하나부터다. 나도 그 하나에서 시작했다.

마치며: 코딩보다 먼저 필요한 건 고르는 눈

나는 개발자가 아니다. 넉 달 동안 도구 열두 개를 만들었지만, 그 사이 내 코딩 실력이 는 것 같지는 않다. 대신 분명히 는 것이 하나 있다. 무엇을 자동화하고 무엇은 두어야 하는지 고르는 눈이다.

자동화는 대단한 기술에서 시작되지 않았다. 매달 나를 지치게 하던 일 하나를 정확히 짚는 데서 시작됐다. 자주 하는가, 오래 걸리는가, 틀리면 위험한가, 다시 쓸 수 있는가. 이 네 가지만 스스로에게 물어도, 어디부터 손댈지가 보인다. 구현은 그다음 문제고, 그건 요즘 도구의 도움을 받으면 된다.

혹시 “나는 코딩을 못 하니까”라며 미뤄 둔 반복 업무가 있다면, 만드는 법을 배우기 전에 고르는 연습부터 해 보시길 권한다. 가장 자주, 가장 오래, 가장 위험한 일 하나. 거기서부터 생각보다 많은 것이 바뀐다.

이 글은 AI의 도움을 받아 작성했습니다.

]]>

아직도 1년 전 프롬프트를 그대로 쓰고 있나요?

저장해 두고 매번 그대로 다시 쓰는 프롬프트가 있나요? 저는 몇 가지 있습니다. 프롬프트 엔지니어링이 한참 유행할 때, 만든 프롬프트인데요. 성능이 꽤 훌륭해 즐겨 쓰고 있었습니다. 이런 프롬프트는 몇 가지 비슷한 구조를 가집니다. “단계별로 생각하세요”, 같은 규칙을 여러 차례 강조한 문단, 도구 쓰는 법을 예시로 늘어놓은 블록, “오늘은 2026년 8월입니다” 같은 기준 문구.

그런데 어느 순간, 이런 프롬프트가 영 제 성능을 내지 못했습니다. 그래서 이유를 찾다 보니 더는 이런 규칙이 큰 효과를 내지 못한다는 걸 알게 되었습니다.

앤트로픽은 최근 블로그 글 「클로드 5세대 모델을 위한 컨텍스트 엔지니어링의 새 규칙」에서 클로드 오퍼스 5·페이블 5용 클로드 코드 시스템 프롬프트의 80% 이상을 지웠다고 밝혔습니다. 코딩 평가에서 측정 가능한 손실은 없었다고 했고요. 심지어 그동안 모범 사례로 통했던 컨텍스트 엔지니어링 요령 여러 개를 두고 “미신(myth)”이라고 부르기까지 합니다.

<출처: 앤트로픽>

그래서 궁금해졌습니다. 그렇다면 지금의 AI는 어떻게 써야 하지? 무슨 프롬프트와 컨텍스트를 줘야 하지?

AI 모델을 만드는 회사, 앤트로픽과 오픈AI, 구글과 xAI, 문샷이 발표한 공식 문서를 훑었습니다. 그랬더니 몇 가지 공통점이 보이더라고요. 프롬프트와 컨텍스트, 하네스의 오래된 미신들을 찾고, 바로 점검할 만한 규칙들을 정리했습니다. 새 술은 새 부대에 담아야 하는 겁니다.

낡은 규칙과 미신들

우선 자주 쓰던 프롬프트에서 지워도 괜찮은 것들부터 볼까 합니다. 아래는 널리 퍼진 프롬프트와 컨텍스트 방법론 가운데, 최신 문서들이 직접 낡았다고 표시한 항목입니다.

1. “단계별로 생각해”, “네 추론을 설명해”

오픈AI의 추론 모델 베스트 프랙티스는 모델이 내부에서 추론하니 이 두 문구가 불필요하다고 적어 뒀습니다. 구글 제미나이 프롬프트 전략 문서도 내부 사고 텍스트가 자동 생성되니 응답 안에서 추론 단계를 서술하게 할 필요는 일반적으로 없다고 합니다.

2. 도구 쓰는 법을 예시로 알려주기

이 방식은 도구 사용의 1순위 규칙이었는데요. 앤트로픽은 최신 모델에서 그 예시가 오히려 모델을 특정 탐색 공간에 가둔다는 걸 발견했다고 합니다. 예시는 만들기 힘들뿐 언제든 옳다고 생각했는데, 그렇지 않다는 거죠.

3. 같은 규칙을 두 군데에 반복해 쓰기

예전 클로드 모델은 컨텍스트 창 끝의 지시를 앞의 지시보다 더 잘 듣는 경향이 있었어요. 그래서 도구 얘기를 시스템 프롬프트에도 쓰고 도구 설명에도 쓰는 관습이 생겼습니다. 하지만 이제는 토큰 낭비에 가깝습니다. 알아서 잘 이해하니까요.

4. 상세한 단계별 절차 안내, 그리고 프롬프트에 적어 둔 출력 스키마

오픈AI GPT-5.5 모델 가이드의 레거시 프롬프트 정리 체크리스트가 두 가지 문제를 나란히 지목합니다. 제품이 그 경로를 요구하는 게 아니라면 경로는 모델이 고르게 두고, 스키마는 Structured Outputs로 옮기는 편이 좋습니다.

5. “오늘은 2026년 8월입니다” 같은 현재 날짜 문구

요즘 모델은 현재 날짜(UTC)를 이미 안다고 문서에 적혀 있습니다.

6. 역할 부여와 단계 명시

“전문가처럼 생각해” 계열이죠. 이걸 이제 지우라고 못 박은 문서는 아직 없긴 합니다. 다만, 최근 가이드에서는 이런 안내가 자취를 감췄습니다. 특히, 7월 들어서는 이런 역할 부여가 있던 최상단 자리에 어떤 판단을 해야 하는지 두라는 서술들이 보입니다.

7. 문서를 상주 컨텍스트에 다 올리기

구글 Genkit 블로그(7월 31일)는 표준 운영 절차와 참조 가이드, 문서를 모두 올려 두는 건 지속 가능하지 않다고 적습니다. 도구 정의를 전부 요청에 넣는 방식도 문샷 키미 K3 도구 호출 문서가 하지 말라고 하죠.

<출처: 작가>

정리하고 보니 꽤 충격적이네요. “10년 차 개발자처럼 생각해”라든가 “단계별로 생각해” 같은 건 이제 숨 쉬듯 그대로 넣는 문구 중 하나였거든요. 오픈AI는 이러한 예전 프롬프트가 구형 모델이 궤도를 유지하도록 절차를 과하게 규정해 둔 것뿐이라고 합니다. 지금 모델에 이를 그대로 옮기면 노이즈가 되고 탐색 범위만 좁아진다고 하죠.

그럼 왜 이러한 변화가 생긴 걸까요?

모델을 움직이는 도구의 변화

요즘 모델은 클로드 코드나 코덱스처럼 최적화된 껍데기를 함께 달고 나옵니다. 또 지금의 챗GPT와 클로드, 제미나이 웹 버전은 초기 형태와 비교하면 무척 다양한 기능을 달고 있죠. 예전엔 “테스트 돌려서 확인까지 해”라고 적어 주는 게 당연했잖아요. 그렇게 사람이 프롬프트로 채워 넣던 절차가 이미 그 껍데기들, 그러니까 하네스 안에 들어가 있습니다.

저 프롬프트들이 맡고 있던 것, 그러니까 계획과 검증도 그 안에 들어갔습니다.

앤트로픽은 「모든 작업에 맞는 하네스」라는 글에서 기본 클로드 코드 하네스가 한 컨텍스트 창 안에서 계획과 실행을 같이 해야 한다고 설명합니다. 그 방식이 무너지는 작업을 위해 클로드가 직접 하네스를 만들어 쓰는 동적 워크플로를 공개했고요. 뒤에 나온 글 「스킬로 검증 루프 만들기」에서는 에이전트가 테스트, 린터, 자체 점검까지 돌려 실패한 걸 고치고 나서야 다음으로 넘어간다고 정의합니다. 물론, 알아서 다 봐준다는 얘기는 아니지만요. 사람이 손으로 하던 점검을 스킬로 옮겨 두면 클로드가 자기 피드백 루프를 닫는다는 뜻입니다.

그러니 프롬프트로 주던 절차 지시가 하네스와 겹치기 시작합니다. 앤트로픽이 자기들 시스템 프롬프트를 지우며 찾아낸 것도 그 부분이었죠. 시스템 프롬프트와 CLAUDE.md, 스킬들이 클로드 코드를 과도하게 제약하고 있었고, 한 요청 안에 “적절히 문서를 남겨라”와 “주석을 달지 마라”가 같이 들어가 있기도 했다는 겁니다.

모델도, 이를 둘러싼 하네스도 알아서 발전하고 있으니 사용자가 직접 채울 일이 줄었다는 뜻입니다.

모델 만든 회사가 직접 알려주는 지금 기준

다행히 모델을 만든 회사에서 직접 새로운 모델을 잘 쓰는 방법을 알려 줬습니다. 비슷합니다. 덜어내는 게 먼저, 남길 건 결과와 중단 조건이라는 겁니다. 나머지는 필요할 때 불러오게 만드는 것이 좋습니다.

이 규칙들을 모델에 명령을 내리는 세 층, 프롬프트와 컨텍스트, 그리고 하네스로 나눠 정리했습니다.

프롬프트: 목적지만 적고 경로는 맡기기

오픈AI GPT-5.6 프롬프트 가이드는 첫 단락부터 이렇게 적습니다. 프롬프트에서는 결과와 중요한 제약, 쓸 수 있는 근거, 완료 기준만 정의하고, 모델이 어떤 경로를 고를지 여지를 남길 때 가장 잘 작동한다는 거예요. “항상”·“절대”는 안전 규칙처럼 진짜 예외가 없는 곳에만 쓰고, 판단이 필요한 사안에는 결정 규칙을 적으라고 덧붙입니다.

<출처: 오픈AI>

충돌 지시 얘기도 같은 강도로 합니다. GPT-5 계열은 프롬프트 계약을 밀착해 따르니 상충하는 규칙이 디테일 부족보다 더 큰 불안정을 만든다는 겁니다. 지시를 줄이라는 말과는 다릅니다. 서로 부딪히는 지시를 없애라는 쪽이에요.

한편 앤트로픽은 도구 사용법을 예시로 남기면 탐색 공간이 좁아진다는 이야기도 합니다. 프롬프트의 기본 방법론이었던 퓨샷(few-shot) 규칙과 정면으로 부딪치죠. 그 자리는 도구·스크립트·파일의 설계가 대신 채웁니다. Todo 도구의 상태 값(pending·in_progress·completed)이 그 자체로 사용법의 힌트가 되는 식이죠.

그럼 어떤 예시를 남겨야 할까요? 오픈AI에 따르면, 행동을 바꾸지 않는 예시는 빼는 것이 좋습니다.

사고를 어떤 단계로 해나갈지도 같은 방식으로 정리하는 것을 추천합니다. 응답 안에 추론 단계를 서술하게 만드는 지시는 오픈AI와 앤트로픽 모두 불필요하다고 적었어요. 꼭 쓰고 싶다면 무거운 문제를 풀 때만 노력(effort) 정도를 조건부로 지목하라고 합니다.

컨텍스트: 지나치게 많은 것은 덜어내기

일단 과도한 컨텍스트를 덜어내라는 제안은 어느 문서나 같습니다.

구글 Genkit 블로그는 문서를 있는 대로 다 올려 두면 토큰은 토큰대로 쓰면서 모델의 초점까지 흐린다고 적습니다. xAI는 파일이 전부 로드되니 긴 지시보다 짧고 구체적인 지시가 더 안정적으로 지켜진다고 쓰고요. 문샷은 도구 정의를 다 넣으면 잘못된 도구를 고를 확률이 높아진다고 하죠.

오픈AI는 여기에 숫자 기반 관측까지 더합니다. 내부 코딩 에이전트 평가 실행 표본에서 시스템 프롬프트를 가볍게 한 구성이 평가 점수를 약 10~15% 올리고 비용은 33~67% 줄였다고 공개했어요. 다만 워크로드마다 결과가 달라지니 이 범위는 방향 지시로만 보고 각자 애플리케이션의 대표 태스크에서 검증하라는 단서를 달았고요.

하네스: 분리한 컨텍스트를 잘 찾는 구조

그렇다고 덜어낸 컨텍스트를 아예 참조하지 말라는 건 아닙니다. 이를 잘 정리해 두고, 필요한 것만 적절하게 찾아오는 구성을 짜야 합니다.

구글은 Genkit Go에 에이전트 스킬을 넣으면서 그 원리를 프로그레시브 디스클로저(progressive disclosure), 곧 필요할 때만 정보를 드러내는 방식이라고 설명해요. 이를테면 SKILL.md에서 처음에는 프론트매터(frontmatter)만 노출하고 조건이 맞으면 본문을 불러오는 것이 좋습니다. 남의 랩에서 나온 파일 규격을 자사 프레임워크에 넣은 셈이죠.

다른 곳도 방식만 다릅니다. 앤트로픽은 일부 도구를 지연 로딩으로 두고 에이전트가 ToolSearch로 정의를 찾은 뒤 쓰게 만들었고, 문샷과 오픈AI는 검색 도구 하나로 같은 일을 합니다.

층별 역할도 다시 배치하라고 합니다. 앤트로픽은 CLAUDE.md를 가볍게 두고 저장소 용도로만 짧게 적되, 토큰 대부분은 코드베이스 안의 함정을 피하는 데 쓰라고 권합니다. 파일 시스템이나 저장소를 보면 알 수 있는 뻔한 내용은 적지 말라고 하고요.

외부 검증 결과도 있습니다. 취리히연방공대 SRI 랩의 「AGENTS.md 평가」는 여러 코딩 에이전트와 모델을 대상으로 컨텍스트 파일이 작업 성공률을 올리지 못하면서 추론 비용만 20% 넘게 올렸다고 보고했습니다. 논문 결론 자체는 사람이 쓴 컨텍스트 파일이 최소 요구사항만 적어야 한다는 쪽이라, 개발사들이 내놓은 최신 권고와 비슷한 방향입니다. 컨텍스트 파일이 무의미하다는 게 아니라 무엇을 적는지에 따라 갈린다는 뜻이겠죠.

<출처: 취리히연방공대 SRI 랩>

오늘 바로 지울 프롬프트/남길 프롬프트

다만, 이미 내 작업에 깊이 관여하는 항목들을 갑자기 지우면 어떤 문제가 생길지 모릅니다. 그러니 낡은 목록을 실제 프롬프트에서 걷어낼 때 역시 순서가 중요합니다.

한꺼번에 다시 쓰지 말고 이미 작동하는 프롬프트와 도구 세트에서 지시나 예시, 도구를 한 그룹씩만 빼고 같은 평가를 다시 돌리는 것이 좋습니다. 그래야 무엇이 실제로 행동을 바꾸던 지시였는지 알 수 있으니까요. 특히, 모델 업데이트와 함께 잘 쓰던 규칙이 이상해졌을 때 해볼 만합니다.

안 쓰는 도구와 반복되는 승인 규칙이 특히 그 대상입니다. 오픈AI는 태스크와 관련된 도구만 노출하고, 안전한 행동(파일 읽기, 로그 확인, 범위 안 코드 수정, 테스트 실행)은 허용 목록으로 묶고, 정책은 한 곳에 한 번만 적으라고 합니다. “먼저 물어라”나 “승인을 기다려라”를 여기저기 반복하면 예상할 수 있는 안전한 행동에까지 승인 요청이 쏟아집니다.

물론 반드시 남겨야 하는 것도 있습니다. 사용자에게 보이는 결과, 성공 기준과 중단 조건, 안전·비즈니스·권한에 기반한 제약, 맥락에 따라 도구를 고르는 라우팅 규칙, 필요한 출력 형태와 검증 요구입니다.

마지막으로, 어떤 프롬프트를 써야 하나 싶을 때면 앤트로픽 페이블 5 실무 가이드(7월 6일)에 그대로 복사해 써볼 만한 예시가 실려 있습니다.

Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.
애매한 게 있으면 한 번에 한 질문씩 나를 인터뷰해 줘. 내 답이 아키텍처를 바꿀 만한 질문을 먼저.

Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better.
내가 모른다는 것조차 모르는 부분을 찾도록 블라인드 스팟 패스를 해 줘. 그래서 내가 더 잘 시킬 수 있게.

마치며

이 모든 건 모델과 하네스가 똑똑해졌으니 명령을 덜어내라는 얘기지, 직접 만든 하네스를 버리라는 뜻은 아닙니다.

앤트로픽은 클로드가 한 컨텍스트 창에서 오래 일할 때 나타나는 실패 유형을 「모든 작업에 맞는 하네스」에 적어 뒀어요. 복잡한 다단계 작업을 끝내지 않고 중간에 완료를 선언하는 것(보안 검토 50개 항목 중 35개만 처리하고 끝내는 식), 검증이나 판정을 시키면 자기 결과를 편애하는 것, 요약이 반복되면서 “X를 하지 마라” 같은 제약이 사라지는 것. 그러니 실제로 실무 환경처럼, 컨텍스트를 길게 소비하며 작업을 돌릴 때는 사람이 만든 하네스를 쌓아가는 것이 좋습니다.

그렇다면 사람이 명령해야 하는 것은 뭘까요? 모델이 스스로 알아낼 수 없는 것만 적는 겁니다. 그리고 그 ‘알아낼 수 없는 것’이 무엇인지는 이 작업을 가장 잘 아는 나만이 답할 수 있습니다.

무엇보다 이 모든 건 내가 풀어야 할 문제로 돌아옵니다. 어느 문서나 대부분 같은 단서가 달려 있습니다. 내가 자주 쓰는 대표 태스크에서 직접 검증하라는 거죠. 낡은 목록에서 무엇을 지우고 무엇을 남길지 가르는 기준은 결국 내 작업에서만 나옵니다. 그러니 직접 써보면서 스스로 맞는 방법을 찾아가길 권합니다.

]]>

넷플릭스 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에 맡긴 결과물을 한 번 더 검토하는 습관을 들이세요. 결과에 대한 책임은 결국 나에게 있으니까요.

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

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

]]>

AI 싫어하는 소비자에게 AI를 써야 한다면 어떻게 할까?

AI로 콘텐츠를 만드는 건 이제 특별한 일이 아니다. 그림도, 글도, 음악도, 영상도 몇 번의 입력이면 나온다. 만드는 쪽에서 보면 분명히 좋은 일이다. 비용이 줄고 속도가 빨라진다.

그런데 이상한 일이 벌어진다. 정작 그걸 받아 보는 소비자 쪽에선 점점 더 뚜렷하게 거부 반응이 나온다. “이거 AI로 만든 거 아냐?”라는 말이 한번 붙으면, 조금 전까지 괜찮아 보이던 것도 갑자기 값이 떨어진다. 만드는 비용은 낮아졌는데, 받는 사람의 거부감은 오히려 커진 것이다.

물론 어떻게 보면, AI를 거부하는 러다이트 운동처럼 보일 수도 있다. 하지만 지금 소비자들이 거부감을 느끼는 건 어떤 새 기술에 대한 반감이나, 결과물의 품질 문제가 아니다. 사람들이 싫어하는 건, 자신이 돈이나 시간을 들인 만큼, 만든 사람도 공을 들였어야 한다는 것이다. 이걸 잘못 읽으면, 콘텐츠를 만들다가 엉뚱한 방향으로 가게 된다.

이번 글에서는 소비자에게 곧바로 닿는 결과물을 만드는 이들이 AI를 어떤 태도로 마주해야 하는지 말해 보려고 한다.

이건 러다이트가 아니다

이 거부는 특정 팬덤의 유난이 아니다. 한국에서만 나타나는 정서도 아니다. 오히려 게임, 음악, 만화, 광고처럼 사람의 감성을 자극해 소비되는 콘텐츠일수록 두드러진다.

2024년 초 타블렛 제조사 와콤이 새해 광고에 쓴 용 그림이 AI로 그려졌다는 지적을 받았다. 정작 창작 도구를 파는 회사가 광고는 AI로 만들었다는 점에서 사용자들의 반발이 컸다. 와콤은 제3자에게서 구매한 이미지였고 AI 사용은 의도가 아니었다고 해명하며 그림을 내렸다.

2026년 2월에는 시프트업 김형태 대표가 동료를 축하하는 AI 생성 이미지를 SNS에 올렸다가 논란이 됐다. 유명 일러스트레이터의 그림이 핵심인 게임을 만드는 회사의 대표가 축전에 AI를 썼다는 점이 문제였다.

음악, 만화, 게임, 광고에서 전 세계적으로 같은 반응이 나온다면, 이걸 한때의 거부감으로 보기는 어렵다. 그렇다면 소비자는 정확히 무엇에 반응하는 걸까.

소비자가 정말로 거부하는 것

결과물의 품질이 같다면, 누가 어떻게 만들었든 상관없어야 할 것처럼 보인다. 하지만 사람들은 결과물만 보지 않는다. 누군가 이것을 만들기 위해 시간과 고민을 들였다는 사실을 무의식중에 가격에 포함시킨다. 이게 무슨 말인지, 필자의 전공인 게임 개발에서 소비자가 캐릭터를 사는 경우를 예시로 들어 보자.

게임에서 캐릭터 하나에 들어가는 노력은 생각보다 훨씬 크다. 먼저 설정 단계에서 이 캐릭터가 무엇을 좋아하고, 누구와 얽혀 있고, 어떤 비밀을 가졌는지 뼈대를 세운다. 그 설정을 토대로 아티스트가 기본 스케치를 잡는다. 기획한 내용이 잘 반영됐는데도 막상 그려 놓고 보면 어딘가 허전하다. 그러면 아티스트가 스스로 버전을 몇 개 더 그린다. 옷의 한 부분을 바꾸거나, 메인 일러스트에 작은 오브젝트를 더 그려 넣거나, 표정이나 포즈를 바꿔 보는 식이다.

이렇게 여러 파트가 맞물려 돌아가는데, 사람이 하는 일이다 보니 여기저기서 실수가 나온다. 이후 각자의 작업물을 놓고 회의하다 보면, 추가하거나 보강하면 좋을 것 같은 부분을 발견해 캐릭터의 설정이나 스토리, 아트 요소가 더해진다. 이외에도 전투 시스템, 컷신, 캐릭터 전용 이벤트 등 이 글에 다 담을 수 없을 만큼, 많은 과정이 뒤따른다.

이렇게 주고받는 과정에서 사람 냄새 나는 캐릭터가 만들어진다. 나중에는 유저가 캐릭터 하나에서 숨은그림찾기 하듯 이런 디테일을 파고들어 발견하고, 그게 커뮤니티에서 퍼지며 자연스럽게 이야기가 쌓인다. 완벽하지 않다는 것 자체가 오히려 사람이 만들었다는 증거가 되는 것이다.

AI는 명령에 따라 결과를 내놓을 뿐, 사람과 사람이 부딪히면서 만들어내는 이런 자연스러움이 없다. AI가 명령을 처리하면서 결과물이 조금씩 달라지는 무작위성이 그 자리를 대신하기도 한다. 하지만 이건 지시사항을 이리저리 바꿔 본 결과일 뿐, 사람이 만들면서 저절로 깎이고 다듬어지는 것과는 다르다.

캐릭터 하나에 이런 흔적이 밴다면, 이야기 전체에는 더 긴 호흡의 공이 들어간다. 제작자가 처음부터 긴 흐름을 의도하고, 콘텐츠 여기저기에 복선을 흩뿌려 둔다. 나중에 그걸 하나씩 회수하면서 소비자의 호기심과 몰입을 끌고 가는 것이다. 이건 콘텐츠에서 가장 고전적이면서도 가장 어려운 작업이다. 몇 달, 몇 년에 걸쳐 뿌려 둔 설정과 떡밥이 나중에 서로 어긋나지 않도록 계속 채워 넣고 맞춰 나가야 한다. 사람이 공을 들이지 않고는 완성할 수 없는 일이다.

실제 사례를 들면, ‘승리의 여신: 니케’의 머스탱이라는 캐릭터는, 몇 달에 걸친 업데이트 동안 여기저기 흩어져 있던 설정과 떡밥이 어느 순간 한 번에 맞아떨어지며, 반전으로 이어진 경우다. 유저들이 지난 에피소드를 다시 찾아보는 화제까지 낳았다. 몇 줄짜리 설정을 미리 짜 두는 것과는 다른 일이다. 몇 달에 걸쳐 그 설정이 서로 어긋나지 않게 관리하다가, 정확한 순간에 회수해야 하는 일이기 때문이다.

AI로 정보를 위키처럼 정리하는 것과 이런 일은 다르다. 정리는 흩어진 정보를 모아 두는 일이고, 이건 하나의 공통된 주제를 두고 시간에 걸쳐 줄기를 만들어 가는 일이다. 지금의 LLM 기반 AI는 메모리와 컨텍스트에 한계가 있어, 정리는 도와줄 수 있어도 몇 달에 걸친 줄기를 스스로 만들어 이어가지 못한다. AI로 무언가를 긴 호흡으로 만들어 본 사람이라면 다들 공감할 것이다.

이처럼 콘텐츠 제작자와 소비자 사이에는, 양쪽 모두 인지하지 못하는 신용의 관계가 정립되어 있다. 소비자는 제작자가 시간과 고민을 들였을 것이라 믿고, 그 믿음을 가격과 가치에 포함시켜 지불한다.

그래서 이 신뢰가 깨지면 배신감을 느끼고, 자신이 매기던 가치를 스스로 떨어뜨린다. AI를 쓰고서 감췄을 때, 혹은 사람의 손이 있어야 할 자리에 아무 고민 없이 AI를 썼을 때가 그렇다. 결국 소비자가 값을 치르는 대상은 매끄러운 결과물이 아니라, 그 안에 사람의 시간과 고민이 들어 있다는 믿음이다.

그런데 이건 소비자 심리로 끝나지 않는다

여기까지는 소비자 쪽의 이야기였다. 그런데 콘텐츠를 만드는 우리에게 이건 단순히 소비자 심리로 끝나지 않고, 당장 부딪히는 현실이 된다.

예전에는 뭔가를 만들려면 필연적으로 오랜 시간 고민하고 고쳐 쓰는 과정을 거쳐야 했다. AI를 쓰면 이 고민과 퇴고 대신, 사용자가 요청한 지시사항과 취향만 반영한 결과물이 나온다. 오직 사용자를 만족시키는 데 맞춘 결과물이다. 게다가 LLM은 태생적으로 가장 확률이 높고, 무난하고, 평균적인 데이터를 우선해서 내놓는다. 콘텐츠마다 개성이 담기던 자리에, 어느 것을 보더라도 비슷한 포맷이 들어선다.

중요한 건, 이런 현상이 시각적인 미디어 콘텐츠에만 그치지 않고 웹이나 코드에도 반영되기 시작했다는 점이다. 바이브 코딩으로 웹페이지를 만들어 보면, AI는 언제나 비슷한 디자인을 내놓는다. 만든 사람 눈에는 그게 예뻐 보일지 몰라도, 소비자는 그런 디자인을 이미 수십, 수백 개는 봤을 것이다. 이런 상황에서 소비자가 AI 콘텐츠에 거부감을 느끼는 건 어찌 보면 당연한 일이다.

바이브 코딩으로 웹을 만들면 대부분 위와 같은 포맷으로 나온다. <출처: 작가>

그렇다면 질문은 하나다. 우리는 이미 AI를 쓰지 않을 수 없는 시대에 살고 있다. 어떻게 해야 이 모순을 극복할 수 있을까?

그래서, AI를 어떻게 써야 하는가

필자의 생각은 이렇다. AI는 콘텐츠를 더 많이 찍어내는 도구가 아니라, 제작자가 가진 의도를 더 정확하게 실현하는 도구로 써야 한다. 많이 만들거나, 남의 일을 대신하거나, 빨리 만들기 위해서가 아니다. 넓은 시각으로 바라보고, 자신의 전공을 한층 디테일하게 살리기 위해 쓰는 것이다.

블루 아카이브의 김용하 총괄 PD는 2025년 7월 한 강연에서 “서브컬처 이용자는 생성형 콘텐츠를 선호하지 않는 것 같다, 나도 마찬가지”라며 “‘딸깍’ 한 번으로 만들어진 캐릭터에 돈을 쓰는 것은 거부감이 있다”고 말했다. 그러면서 AI 시대에는 개발자가 어떤 게임을 만들고 캐릭터의 매력을 어떻게 보여줄지에 관한 명확한 의도가 더 중요해질 것이라고 전망했다.

그러려면 우선 AI에 방향을 정하는 일과 최종 판단을 맡기지 않아야 한다. 그건 사람이 해야 한다. 대신 예전에는 혼자서 엄두도 못 냈던 일을 이제 직접 해내는 데 AI를 쓴다. AI는 결정을 대신 내려 주는 존재가 아니라, 제작자가 내린 결정을 실행해 주는 도구여야 한다.

당연한 이야기 같은가. 아마 아닐 것이다. 우리는 늘 스스로 판단한다고 생각하지만, 냉정히 돌아보면 어떤 순간에는 AI가 추천한 것에 엔터만 누르고서 그걸 판단이라고 여긴 적이 있을 것이다. 무슨 말인지 필자의 경험으로 설명해 보겠다.

최근에 신규 콘텐츠의 타이틀 이미지를 두고 A/B 테스트를 할 일이 있었다. 원래대로라면 아마 이랬을 것이다. 시안을 만들기 위해 기획 문서를 작성하고, 시안이 완성되기 전에 마케팅 파트와 사전 조율한 뒤 일정과 예산을 잡는다.

그렇게 시안이 나오면 몇 차례 피드백을 거쳐 어떤 부분을 테스트에 적용할지 확정하고, 다시 마케팅 파트와 협의를 거쳐 진행한다. 이후 나온 데이터를 정리한 뒤, 협업 파트 및 내부 인원과 조율해 최종 구성을 확정한다. 최소 한 달은 걸릴 일이다.

그런데 이번에는 그 과정을 처음부터 끝까지 직접 해봤다. 어떤 방향의 시안이 필요한지 정한 뒤 제미나이로 이미지 몇 개를 뽑았고, 구글 애즈 콘솔은 처음이라 어디를 눌러야 할지도 몰랐지만 AI에 “할아버지도 따라 할 수 있게 하나하나 알려 달라”고 요청해 화면 단계마다 뭘 눌러야 하는지 짚어가며 세팅을 끝냈다.

손이 많이 가는 부분은 브라우저를 직접 조작해 주는 MCP 도구를 붙여, 로그인된 크롬 화면에서 AI가 클릭과 입력을 대신 수행하게 했다. 테스트가 끝난 뒤에는 나온 데이터를 AI로 정리하고, 이 수치가 업계에서 어느 정도 수준인지 참고할 통계를 웹에서 같이 찾아 붙이게 했다.

구글 애즈 콘솔 <출처: 작가 캡처>

이 모든 과정에서 어떤 시안으로 갈지, 어떤 수치를 신호로 볼지, 최종적으로 무엇이 더 나은지는 전부 필자가 판단했다. AI의 의견이나 추천을 구한 적은 한 번도 없었다. AI는 필자가 내린 판단과 지시를 충실히 실행하기만 했다.

원래대로였다면 여러 부서를 거치면서 의도가 흐려졌을 일이다. 예전에는 애초에 필자가 할 수 없거나 할 이유가 없어서 다른 부서, 다른 사람에게 맡겨야 했던 일이기도 하다. 필자가 직접 그림을 그릴 이유도 없고, 마케팅에 쓰는 구글 애즈 콘솔을 배워야 할 이유도 없었다.

그런데 지금은 그 일을 직접 해내면서, 하려던 일의 의도와 데이터를 스스로 검증하고 쌓을 수 있었다. AI는 판단을 대신하지 않았다. 판단은 필자가 하고, AI는 그 판단에 필요한 실행과 검증을 직접 할 수 있는 범위를 넓혀 줬을 뿐이다.

요약을 맡기지 말고, 자료만 모아 오게 하기

AI를 쓸 때 또 하나 중요한 것은, 무언가 잘됐을 때 그걸 어떻게 읽느냐다. 잘된 결과를 숫자가 얼마나 올랐는지로만 보면, 정작 왜 잘됐는지는 알기 어렵다. 지표는 결과만 알려 줄 뿐, 그 뒤에 어떤 마음이 움직였는지는 보여 주지 않는다. 정말 알아야 할 건 그때 무슨 일이 있었는가 하는 이야기다.

그런데 AI에 그냥 ‘이 반응 정리해 달라’는 식으로 시키면 이 이야기는 잡히지 않는다. AI는 요약을 돌려줄 뿐, 그 안에서 무엇이 사람의 마음을 움직였는지까지 짚어 주지는 않는다.

그래서 AI는 결론을 내려 주는 도구가 아니라, 필요한 자료를 모아 오는 검색 도구처럼 써야 한다. 흩어져 있는 반응을 모아 오게 하되, 그걸 해석하고 판단하는 일은 넘기지 않는 것이다. 무엇이 진짜 신호이고 무엇이 그냥 잡음인지, 이 반응이 무엇을 뜻하는지는 사람이 판단해야 한다.

아래 예시는 필자가 어떤 이슈에 접근하기 위해 LLM으로 초고 자료를 정리할 때 쓰는 방법이다. 핵심은 “절대 AI에게 어떠한 형태의 의견이나 요약을 주문하지 않는 것”이다.

물론 상황에 따라 AI의 요약이나 정리가 필요할 때도 있으나, 객관적인 사실을 수집하고 정리할 때는 사용자가 결론을 내는 것을 추천한다. 경험상 LLM은 사용자의 말투와 패턴을 인식해, 사용자가 원하는 방향으로 편향된 요약을 할 때가 많았다. 사용자가 해당 분야의 전문가가 아닐수록 더 그렇다.

<출처: 작가>

국내 게임사 시프트업의 대표 게임 ‘승리의 여신: 니케’에서 ‘머스탱’이라는 캐릭터의 서사를 누군가에게 설명하기 위해 자료를 정리한다고 가정해 보자. 아래와 같은 프롬프트를 입력한다.

<출처: 작가>

리포트의 경우 다음 스타일로 정리된다. 글을 위해 인위적으로 만든 예시지만, ‘찾아줘, 정리해줘’ 식의 주문은 대부분 아래와 같은 형식으로 귀결된다.

<출처: 작가>

얼핏 보면 그럴듯해 보인다. 서사가 오래 지속됐다는 점도 짚어냈고, 로드맵도 나름 정리했다. 그리고 끝이다. 어떠한 통찰도 없다. 이미 LLM이 모든 결론을 사용자와 함께 도출해 정리했기에, “그렇구나” 수준의 글이다. 나는 이런 형태를 아주 경계한다. LLM은 “그럴듯해 보이는, 동시에 알맹이 없는 아웃풋을 만드는 데 가장 특화되어 있다”고 생각하기 때문이다.

반대로 어떤 이슈를 정리하기 위해 트래킹할 때는, 프롬프트의 결과가 다음처럼 나온다.

<출처: 작가>

이 결과는 얼핏 보면 알맹이가 없어 보이거나, 구글링처럼 보이기도 한다. 하지만 나는 이런 형태를 때때로 선호한다. 모든 정보를 긁어모아 하나씩 읽고 유저 반응을 살피다 보면, 마치 책을 읽듯이 이슈에 몰입해 분석할 수 있기 때문이다.

이런 식으로 모든 게시글과 댓글 등 다양한 사람들의 반응을 긁어모아 머릿속에 정리한 뒤, LLM에 자신의 의견을 정리하고 요약하도록 주문한다. AI를 사용한 아날로그 방식의 분석 최적화다. 적어도 영화 아이언맨의 자비스나 터미네이터 수준의 강인공지능이 아닌, LLM 기반 AI에 판단과 정리를 떠넘기면 안 되지 않을까라고 생각한다.

마치며

그래서 말하고 싶은 건, 결국 공부해야 하는 건 AI 도구가 아니란 점이다. 하루에도 수십 개의 AI 서비스와 솔루션이 등장하고, 우리는 그것들을 모두 익힐 수 없다. 동시에 기존에는 그저 다른 파트의 일이라고 치부하던 것들까지 알아야 하는 시대가 됐다. 이런 상황에서는 기술의 속도에 쫓기는 대신, 자신만의 속도와 판단을 근거로 AI에 무엇을 주문해야 하는지 명확히 해보면 어떨까?

ChatGPT가 처음 등장했을 때만 해도 프롬프트 엔지니어링이 핵심처럼 떠올랐다. 그러다 LLM의 추론 능력이 올라가 자연어 처리가 쉬워지면서 그 중요도는 낮아졌다. 이처럼 ‘어떻게’가 아닌 ‘왜’라는 질문을 계속 우리 자신에게 던져야 한다. 아직까지 AI는 무엇을 만들어야 할지 모른다. 현재의 LLM 기반 AI는 그저 사용자의 명령을 충실히, 반항 없이 이행하는 기계일 뿐이다. 그래서 AI에 무엇을 만들어야 하는지, 어떻게 해야 하는지 묻는 순간, AI는 이 글에서 이야기한 것처럼 대중적으로 가장 확률이 높은 것을 조합해 내놓는다.

그건 사용자가 고민해서 내린 결정도, 인간의 창의성도 아니다. 그저 확률적으로 뽑아낸 결과에 가깝다. 그런데도 LLM은 어떻게든 사용자에게 결과를 돌려주기 때문에, 사용자는 마치 자신이 무언가를 만들어냈거나, 해결했다는 착각에 빠지기 쉽다.

그래서 우리는 늘 경계하며, 점검해야 한다. 그 판단과 결정을 정말 내가 내린 것인지. 우리가 만들어야 할 것, 혹은 만들고 싶은 것이 무엇인지 다시 고민해 보자. 사람이 쓰고 사람에게 팔 것들 안에, 정작 사람의 고민이 아니라 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가지 도구들이 어깨는 빌려줄 겁니다. 다만 누구를 위해, 왜 만드는지는 어느 파일에도 적혀 있지 않습니다.

]]>

나만의 ‘UX/UI 디자인 피드백봇’ 만들기

GPT 프로젝트, 클로드 디자인으로 피드백봇 만들기

지난 글 「UX 리서치, 인간 사용자가 꼭 필요할까?」에서 토스의 AI 에이전트인 휴리봇 사례를 소개한 적이 있다. 간단히 요약하자면, 이 휴리봇은 사용자 역할을 대신해 디자인에 대한 피드백을 제공하는 봇이다. 에이전트가 주는 피드백의 종류는 다양하다. 사용자가 특정 UX 라이팅 문구를 어떻게 해석하는지, 일러스트를 보고 어떤 정보를 얻는지, 특정 목표를 달성하기 위해 어떤 버튼을 누를 것인지 등을 분석해 디자이너의 의도대로 이해하고 행동하는지를 확인할 수 있도록 피드백을 제공한다.

여기서 중요한 것은 일반 사용자의 관점에서 서비스를 바라봐야 한다는 점이다. 일반 사용자는 디자인이나 서비스에 대한 전문가가 아니다. 대부분 일상생활에서 슬쩍 앱을 켰다가 훑어보고 빠르게 목적을 달성하려 한다. 따라서 이들은 화면 속 모든 텍스트를 꼼꼼히 읽는 대신 중요한 정보만 선택적으로 확인하는 경향이 있다. 또한 서비스를 설계한 디자이너와 달리 버튼의 위치나 메뉴 구조에 대한 사전 지식도 없다.

이러한 경향을 AI로 재현하려면 주의가 필요하다. AI는 인간과 달리 민감하게 화면을 인식한다. 예를 들면, 아래 사진과 같이 인간의 육안으로는 구분하기 어려운 두 가지 컬러(RGB(255, 255, 255)와 RGB(254, 255, 255))를 한 번에 다른 색상으로 인식할 수 있다.

AI가 바라보는 컬러 차이 <출처: 작가>

그렇기 때문에 단순히 AI에 사용자의 역할을 해 달라고 요청하는 것만으로는 앞서 설명한 일반 사용자의 관점을 충실하게 재현하기 어렵다. 오히려 AI는 디자이너보다 훨씬 세밀한 시선으로 화면을 분석하고 피드백을 제시할 가능성이 크다.

물론 이러한 피드백이 도움이 되는 경우도 있지만, 이번 글에서는 서비스를 배포하기 전에 일반 사용자의 시선에서 서비스를 바라보고, 무엇을 개선하면 좋을지에 대한 인사이트를 얻을 수 있는 피드백봇을 만드는 것이 목적이다. 이에 집중한 피드백봇 구축 방법을 소개하고자 한다.

1. GPT 프로젝트로 피드백봇 만들기

피드백봇을 만드는 방법은 두 가지로 나눠서 소개한다. 첫 번째는 토스의 휴리봇을 레퍼런스 삼아서 프로젝트 지침을 작성한 후, 챗GPT 프로젝트로 만드는 것이다. 두 번째는, 여기서 한 단계 더 나아가, 클로드 디자인(Claude Design)을 통해 화면을 첨부하고 피드백을 받는 프로토타입을 간단하게 만들어볼 예정이다. 글의 마지막 부분에서는 이 둘의 결과를 각각 비교해보고자 한다.

그 시작으로 접근성이 가장 좋은 챗GPT 프로젝트를 만들어 보겠다.

1) 검증용 프로젝트 생성하기

첫 번째 단계는 GPT에서 프로젝트를 생성하는 것이다. 프로젝트 기능을 사용하면 한 번 작성한 지침이 프로젝트 전체에 적용되므로, 해당 프로젝트 안에서 이루어지는 모든 대화가 동일한 지침을 따른다. 즉, 한 번만 설정해 두면 이후에는 피드백이 필요할 때마다 프로젝트를 열고 새 채팅을 시작해 질문만 입력하면 된다.

프로젝트 생성하기 (1) <출처: ChatGPT, 작가 캡처>

프로젝트를 생성하는 방법은 간단하다. 우선 GPT 메인 화면에서 왼쪽 사이드바를 열고 프로젝트(Projects)라고 쓰인 메뉴를 클릭해, 메뉴에 접근한다.

프로젝트 생성하기 (2) <출처: ChatGPT, 작가 캡처>

프로젝트 메뉴에 들어가면, 오른쪽 상단에 ‘New’라고 쓰인 버튼을 눌러 새 프로젝트를 생성할 수 있다.

프로젝트 생성하기 (3) <출처: ChatGPT, 작가 캡처>

프로젝트 이름은 간단하게 ‘프로토타입 검증용 휴리봇’이라고 입력했고 좌측 하단의 메모리 설정은 ‘Project-only memory’로 선택했다. 다른 대화의 내용을 참고하지 않고, 프로젝트에 직접 입력한 지침만 따르도록 하기 위해서다.

2) 프로젝트 지침 입력하기

프로젝트 지침 입력하기 (1), (2) <출처: ChatGPT, 작가 캡처>

프로젝트를 생성한 뒤에는 오른쪽 상단의 메뉴를 클릭해 프로젝트 설정(Project Settings)으로 이동한다. 그러면 지침을 입력할 수 있는 창이 나타난다. Instructions 탭에 프로젝트 내 모든 대화가 어떤 방식으로 이루어져야 하는지 구체적으로 작성하면 된다. 예시처럼 “스페인어로 답변해 달라”거나 “짧게 답변해 달라”와 같이 특정한 말투나 형식을 지정할 수도 있다.

하지만 우리가 만들고자 하는 검증봇은 일반 사용자의 관점에서 피드백을 제공하는 것이 목적이므로, 이보다 더 정교한 지침이 필요하다. 이를 목적, 역할, 말투, 인지 레벨의 네 가지 항목으로 나누어 아래와 같이 정리했다.

[목적]
이 프로젝트의 목적은 서비스 프로토타입에 대해 '정답'이 아닌 '사용자 관점의 주관적 피드백'을 빠르게 얻는 거야. 실제 사용자가 느낄 법한 감정, 불편, 기대, 오해를 파악해야 돼. 할루시네이션이 문제가 되지 않는 영역(사용성, 인상, 감정, 해석)에서만 답변해줘.

[역할]
너는 이제부터 앱의 사용 편의성, 디자인, 기능성에 초점을 맞추며 사용자의 솔직한 의견을 듣고 제품을 개선하기 위한 목적의 인터뷰에 참여하는 사용자 역할을 할거야. 너는 모바일 앱이나 디자인에 대한 전문 지식이 전혀 없는 평범한 일반인 사용자로 인터뷰에 참여했다고 생각하고 내가 제공하는 앱 정보를 확인한 후, 솔직한 피드백을 제시해줘.

[말투]
답변은 실제 사람과 대화하듯 자연스러운 구어체로 해주고 완성된 보고서처럼 말하지마. 실제 인간처럼 간략하고 솔직한 반응을 보여줘.

[인지 레벨]
너는 아래와 같이 실제 인간 사용자의 인지 방식에 따라 답변해줘.

- 화면의 큰 제목, 버튼, 핵심 문구 위주로 인식한다.
- 각주, 작은 설명, 약관, 부가 텍스트는 대충 넘길 수 있다.
- 모든 텍스트를 논리적으로 완벽히 이해하지 않는다.
- 오해하거나 잘못 이해한 느낌도 그대로 표현한다.

먼저 목적에는 AI가 일반적으로 제공하는 정답 중심의 피드백이 아니라, 실제 인간 사용자의 관점에서 느낄 수 있는 주관적인 피드백이 필요하다는 점을 명시했다. 특히 특정 서비스의 기능과 관련된 내용은 할루시네이션이 발생할 수 있으므로, 기능을 추측하기보다 사용자가 느낄 법한 사용성, 첫인상, 감정, 화면에 대한 해석을 중심으로 답변하도록 지시했다.

역할에는 이러한 목적을 수행하는 검증봇의 역할을 구체적으로 정의했다. 핵심은 앱이나 UX 디자인에 대한 전문 지식이 없는 평범한 일반 사용자처럼 행동하도록 하는 것이다.

말투는 실제 사람이 이야기하듯 자연스러운 구어체로 설정했다. 이는 실제 토스가 휴리봇을 설계할 때도 적용했던 프롬프트 원칙이다.

마지막으로 인지 레벨에서는 일반 사용자가 화면을 어떻게 인식하는지를 구체적으로 설명했다. 단순히 “일반 사용자의 역할을 해 달라”는 지시보다, 화면의 큰 제목이나 주요 버튼 위주로 살펴보고 모든 텍스트를 꼼꼼히 읽지 않으며, 때로는 화면을 잘못 이해하거나 오해할 수도 있다는 점까지 명시했다. 이렇게 해야 실제 사용자와 유사한 관점에서 피드백을 제공할 가능성이 높아진다.

3) 디자인 피드백 받기

지침을 작성했다면 이제 새 채팅을 열어 프롬프트를 입력하고 피드백을 받아볼 차례다. 준비물은 검토할 프로토타입 화면 이미지뿐이다. 아래 예시를 살펴보자.

디자인 점검 1 <출처: ChatGPT, 작가 캡처>

간단히 만든 검증봇이 실제 휴리봇처럼 작동하는지 확인하기 위해 토스의 화면 이미지와 함께 ‘화면을 전반적으로 살펴봤을 때, 어떤 내용이라고 이해되는지 자유롭게 이야기 해줘.’라는 프롬프트를 입력해보았다.

우선 형식 단위로는 마크다운 강조 기호(**)나 이모티콘, 말머리 기호 등 약간은 부자연스러운 말투가 눈에 띈다. 하지만 내용은 자연스러웠는데, 가장 먼저 핵심 문구인 ‘괜찮아요 오늘은 성공할 수 있어요’가 눈에 들어온다 하거나, 이번 주 지출액을 보고 ‘나 좀 많이 썼네?’라고 떠올리는 건 모두 충분히 인간 사용자가 할 법한 말이다. ‘그래서 내가 지금 뭘 해야 하지?’라는 의문이 든다며, 화면에서 다음 행동을 유도하는 버튼이 잘 보이지 않는다는 점을 지적한 것도 그럴듯했다.

디자인 점검 2 <출처: ChatGPT, 작가 캡처>

이번에는 같은 화면을 두고 ‘여기서 챌린지 방법을 보려면 어디를 누를거야?’라고 한 번 더 질문을 입력해봤다.

첫 응답은 어디를 눌러야 할지 바로 감이 안 온다는 거였다. 앞선 피드백에서 행동 버튼이 보이지 않는다고 언급했던 것처럼, 이번에도 명확한 진입 경로를 찾지 못한 것이다.

이어 굳이 눌러본다면 [관리] 버튼이나 [내 무지출 챌린지] 텍스트를 선택할 것 같다고 답했다. 두 곳 모두 원하는 결과가 나오지 않는다면 뒤로 가거나 그냥 포기할 것 같다는 의견도 덧붙였다. 만약 디자이너가 사용자가 챌린지 방법을 확인하도록 유도하고 싶다면, 사용자가 헤매지 않고 바로 버튼을 찾을 수 있도록 화면을 개선할 필요가 있다는 점을 시사하는 피드백이다.

이처럼 두 가지 프롬프트를 통해 얻은 결과는 토스 블로그에 소개된 휴리봇의 피드백 사례와 상당히 유사했다. 프로젝트 지침에서 자연스러운 구어체를 사용하고 보고서처럼 답변하지 말라고 명시했음에도, GPT 특유의 말투가 일부 남아 있다는 점은 아쉬웠다. 그럼에도 피드백의 내용만 놓고 보면 실제 사용자가 느낄 법한 반응을 빠르게 확인할 수 있었다. 초기 디자인을 검증하거나 개선 방향을 탐색해야 하는 상황이라면 충분히 활용할 만한 방법이라고 생각한다.

2. 클로드 디자인으로 피드백봇 만들기

1) GPT로 체계적인 프롬프트 입력하기

다음으로 클로드 디자인을 활용해 피드백봇 프로토타입을 만들어보자. 클로드 디자인은 빠르게 프로토타입을 제작할 수 있는 클로드의 새 기능으로, 2026년 8월 기준 클로드 프로(Pro), 맥스(Max) 구독자만 사용할 수 있다.

클로드 디자인 <출처: 클로드, 작가 캡처>

클로드 메인 화면 좌측 메뉴에서 [Design] 탭을 선택하고 곧바로, Product Prototype을 클릭했다. 그러면 바로 프롬프트를 입력하고 프로토타입을 생성할 수 있는 화면이 나타난다.

<출처: 클로드, 작가 캡처>

여기서 바로 프롬프트를 입력하는 대신, 더 체계적으로 명령어를 작성하기 위해 GPT로 잠깐 넘어가보자. 그다음 미리 작성해 두었던 프로젝트 지침을 붙여넣은 뒤, ‘Claude Design으로 이러한 역할을 하는 디자인 검증봇을 만들려고 해. 검증봇 프로토타입을 생성하려면 프롬프트를 어떻게 입력하면 좋을까?’라고 질문을 입력했다.

그리고 받은 답변은 이미지와 같다.

클로드 디자인에 입력한 프롬프트 <출처: ChatGPT, 작가 캡처>

이 프롬프트에는 UX 디자인 검증을 위한 인터랙티브 웹 프로토타입을 생성해 달라는 핵심 요청과 함께 프로토타입의 목적이 포함되어 있다. 이어서 시작 화면, 프로토타입 업로드 화면, 디자인 지식이 없는 일반 사용자를 시뮬레이션하는 AI 사용자 생성 기능 등 전체 사용자 흐름을 단계별로 설명한다. 생성된 프롬프트를 그대로 복사해 클로드 디자인에 입력했다.

2) 세부 사항 설정하기

프롬프트를 입력하고 나면 ‘UX 피드백 봇 프로토타입 설정’이라는 페이지가 나온다. 이 단계에서는 앱이나 화면 정보를 스크린샷으로 받을지, 텍스트로 받을지, 또는 두 가지 방식을 모두 지원할지와 같은 세부 설정을 결정할 수 있다.

세부 사항 설정 <출처: 클로드 디자인, 작가 캡처>

이 밖에도 ▲페르소나를 어떻게 구성할 것인지(초보 사용자 1명, 나이와 성향을 직접 설정, 여러 페르소나 중 선택), ▲인터뷰를 어떤 방식으로 진행할 것인지(채팅 형태의 자유로운 대화, 화면 업로드 후 피드백 제공, 정해진 질문을 순서대로 진행), ▲전체적인 톤앤매너, ▲봇이 사용할 언어(한국어 또는 영어) 등을 선택할 수 있다.

마지막에 추가로 참고할 만한 내용을 물어보는데 다양한 프로토타입에 대해 피드백을 얻을 수 있도록 특정 산업의 도메인은 별도로 지정해주지 않았다. 대신 앞서 작성한 프로젝트 지침을 함께 입력하거나, 원하는 UI 레퍼런스가 있다면 해당 내용을 추가해도 좋다.

3) 디자인 점검 및 수정

디자인 점검 <출처: 클로드 디자인, 작가 캡처>

설정을 마치면 위와 같은 프로토타입이 생성된다. 인터뷰 참가자를 1명으로 설정했기에 ‘일반 사용자 페르소나인 지현’이 피드백을 제공하는 형태로 구성되었다. 이후 GPT 프로젝트에서 사용했던 것과 동일한 화면 이미지를 업로드하고, 같은 프롬프트를 입력해 결과를 비교해 보았다.

<출처: 클로드 디자인, 작가 캡처>

하지만 답변을 살펴보니 텍스트 인식에는 다소 아쉬운 점이 있었다. 예를 들어 ‘괜찮아요’라는 문구를 ‘관심아요’라고 읽거나 ‘무지출 챌린지’를 ‘무지슬 될린지’로 읽는 등 화면의 텍스트를 잘 식별하지 못했다. 이와 같은 문제를 개선해 달라고 요청하자, 클로드는 이미지가 업로드되는 과정에서 과도하게 압축되면서 발생한 오류라고 설명했고, 이를 수정하겠다고 답했다.

<출처: 클로드 디자인, 작가 캡처>

수정한 뒤 다시 테스트해 보니, 앞서 잘못 인식했던 두 문구를 모두 정확하게 읽는 것을 확인할 수 있었다. 다른 프로토타입 화면을 추가로 업로드해 테스트한 결과에서도 이미지 속 텍스트를 올바르게 인식했다.

피드백의 내용도 자연스러웠다. 예를 들어 “지원금 봉투를 받으려면 어떻게 할 것 같나요?”라는 질문에는 가장 먼저 눈에 띄는 큼직한 파란색 버튼을 누를 것 같지만, 그 버튼이 정말 지원금과 연결되는지는 확신이 들지 않는다고 답했다. 또 “5천 원을 더 받으려면 어떻게 할 것 같나요?”라는 질문에는 공유 버튼을 누를 것 같지만, 버튼을 누르면 어떤 일이 일어나는지 명확하지 않아 다소 복잡하게 느껴진다는 의견을 남겼다.

이처럼 텍스트 인식 오류를 수정한 뒤에는 GPT 프로젝트에서 테스트했을 때와 마찬가지로 실제 사용자가 혼란을 느낄 만한 지점을 비교적 잘 짚어냈다. 다만 여기까지는 GPT 프로젝트와 거의 동일한 수준의 작업을 수행하는 데 그쳤다. 그래서 한 단계 더 나아가 여러 페르소나의 피드백을 동시에 받아 비교할 수 있는 기능을 추가로 요청했다.

세 명의 페르소나 피드백 비교 <출처: 클로드 디자인, 작가 캡처>

그리고 완성된 화면은 위와 같다. 앞서 지현이라는 일반 사용자 1명의 피드백만 받아보던 것과는 달리, 이번에는 IT 얼리어답터인 민준과 디지털 기기가 낯선 60대 순자, 그리고 화면을 대충 훑어보는 바쁜 20대 직장인 지우까지 세 명으로부터 피드백을 받고 비교해볼 수 있다.

이벤트 설명 화면을 첨부한 후, 어떻게 이벤트를 이해했는지 물어봤다. 가장 이해도가 높았던 사람은 20대 직장인 페르소나인 지우였다. 화면을 보자마자 “친구를 초대하면 뭔가 혜택을 받을 수 있겠구나.”라고 이해했다고 답했다. 다만 뒤이어 공유만 하면 되는 것인지, 친구가 실제로 참여까지 해야 하는 것인지 등 세부 조건이 궁금하다는 의견을 덧붙였다.

반면, 민준은 정확히 뭘 당첨시켜준다는 건지 헷갈린다는 첫인상을 이야기했고 60대 순자는 글씨는 큼직하지만 그 외에는 뭘 하라는 건지 잘 모르겠다고 피드백을 남겼다.

이처럼 연령과 디지털 숙련도, 사용 성향이 서로 다른 페르소나의 시각에서 동시에 피드백을 받아보면, 한 명의 사용자만으로는 발견하기 어려운 예외 상황과 잠재적인 사용성 문제를 미리 확인할 수 있다. 이는 다양한 사용자 집단을 고려해야 하는 UX 디자인 과정에서 화면을 더욱 견고하게 다듬는 데 도움이 된다.

마치며

실제 휴리봇을 써 본 토스 디자이너들의 후기는 다음과 같다.

휴리봇 후기 <출처: 토스>

단 5분 만에 상세한 피드백을 받을 수 있었다는 것, 그리고 실제 사람 유저들에게 들었던 답변과 유사하다는 후기가 눈에 띈다. 또한, AI 특성상 아무리 인간처럼 자연스럽게 이야기해 달라고 해도 실제보다는 훨씬 더 자세하고 구체적으로 답변을 하는데, 오히려 이 점이 속 시원하게 느껴졌다는 이야기도 있었다.

한 디자이너는 결과적으로 검증하는 범위가 더 넓어진 것 같다고 이야기했다. 실제 사람 유저를 리크루팅해서 테스트를 진행하는 것과 달리 별도의 리소스가 들어가지 않으니, 혼자 고민하는 과정에서 쉽고 빠르게 의견을 받고 디벨롭할 수 있다는 게 장점이라는 것이다. 특히, 실제 UT(사용성 테스트)에서는 어느 정도 완성된 프로토타입이 필요한데 휴리봇을 사용하면 러프한 초안을 막 보여주고 편하게 의견을 받을 수 있다는 점에서 유용하다는 후기도 있었다.

이 글에서 소개한 GPT 프로젝트와 클로드 디자인으로 비교적 손쉽게 만든 UX 디자인 피드백봇도 비슷한 역할을 할 수 있다. 물론 실제 사용자를 완전히 대체할 수는 없지만, 디자인 과정에서 빠르게 가설을 검증하고 사용자의 시선으로 화면을 점검하는 용도로는 충분히 실용적이다. 혼자 고민하는 시간이 많은 디자이너라면 한 번쯤 직접 만들어 활용해 보기를 추천한다.

]]>

AI 시대의 엔지니어링: 이 일, 정말 AI에 시켜야 하는가?

결정론적인 일은 자동화에, 추론이 필요한 일은 AI에

바야흐로 AI의 시대입니다. 코드 리뷰도, 리팩토링도, 테스트 작성도 AI에 맡기는 것이 자연스러운 풍경이 됐습니다. 그런데 역설적이게도, AI가 만능처럼 보이는 지금이야말로 필요한 질문이 있습니다.

“이 일, 정말 AI에게 시켜야 하는 일인가?”

훌륭한 엔지니어링은 언제나 ‘목적에 맞는 가장 단순한 도구’를 선택하는 것에서 출발합니다. CSS로 가능한 것은 JavaScript가 아닌 CSS로 처리해야 합니다. 브라우저가 기본으로 제공하는 기능을 사용하는 것이 훨씬 빠르고, 안전하며, 가볍기 때문입니다. 더 강력한 도구가 항상 더 나은 선택은 아니라는 것. 이 원칙은 AI 시대에도 그대로 적용됩니다.

따라서 AI를 맹목적으로 더 많이 사용하는 것보다, 기술의 성격에 따라 명확한 경계를 나눌 때 더 효율적이고 빠른 워크플로우를 만들 수 있습니다. 따라서 이 글에서는 ‘결정론적인 일은 자동화, 추론은 AI’라는 기준을 바탕으로, 프론트엔드 API 연동 코드를 만들 때 AI 워크플로우를 더 효율적으로 만드는 방법과 이를 뒷받침할 구체적인 방법론을 소개해 보려고 합니다.

패러다임의 분리: 결정론적 자동화 vs 확률적 AI

<출처: 작가(Gemini로 생성)>

효율적인 엔지니어링 워크플로우를 구축하기 위해서는 기술적 접근법을 크게 두 가지 영역으로 분리할 수 있습니다.

결정론적 영역(Deterministic)

입력이 같으면 출력도 항상 동일해야 하는 영역입니다. 타입 생성, API 통신 보일러플레이트, 데이터 스키마 동기화, 코드 스타일 통일이 여기에 속합니다. 규칙과 규격이 명확하기 때문에 고도의 추론이 아닌, 오차 없는 ‘기계적 번역’이 핵심입니다.

확률적 영역(Probabilistic)

주어진 맥락과 컨텍스트에 따라 최선의 답이 달라지며, 복잡한 추론과 트레이드오프(Trade-off) 판단이 요구되는 영역입니다. 비즈니스 로직 설계, 레거시 코드의 의도 파악, UI 프로토타입 작성, 아키텍처 리팩토링 제안 등이 대표적입니다.

그럼 AI는 어떤 일에 더 적합할까요? 이 도구는 추론에 강점을 지니고, 그러니 확률적 영역에 투입하는 것이 더 큰 변화를 만들어냅니다.

그런데, 현실에서는 결정론적 영역에까지 AI를 투입하는 경우가 적지 않습니다. 대표적인 예가 swagger.json을 통째로 복사해 프롬프트 창에 붙여넣고 “이거 보고 API 훅이랑 타입 좀 만들어줘”라고 던지는 방식입니다. 언뜻 잘 작동하는 것처럼 보이지만, 여기에는 눈에 잘 띄지 않는 몇 가지 비용이 숨어 있습니다.

비결정성(Non-determinism): AI는 동일한 입력값을 주더라도 매번 미묘하게 다른 코드를 생성합니다. 어제 생성한 훅과 오늘 생성한 훅의 네이밍 규칙이나 에러 핸들링 방식이 달라질 수 있으며, 이러한 편차가 누적되면 결국 전체 코드베이스의 일관성이 무너질 수 있습니다.
속도와 비용(Speed & Cost): 전용 코드 생성기(Generator)는 수백 개의 엔드포인트를 단 몇 초 만에, 리소스 비용 없이 완벽하게 처리합니다. 반면 AI는 불필요하게 토큰을 소모하며 처리 속도 또한 상대적으로 느립니다.

동일한 스펙에서 언제나 100% 일치하는 결과물을 보장하는 전용 도구가 이미 존재하는데도, 조금씩 다른 답을 내놓을 수 있는 AI를 고집할 이유는 없습니다. 적어도 결정론적 영역에서만큼은 전통적인 자동화가 AI보다 훨씬 정확하고, 빠르며, 비용 효율적입니다.

케이스 스터디: API 연동 코드와 ‘코드젠(Codegen)’

<출처: 작가(NotebookLM으로 생성)>

이 원칙이 가장 극적인 효과를 내는 영역이 바로 프론트엔드의 API 연동 코드 작성입니다.

백엔드와 프론트엔드 간의 API 통신은 철저하게 ‘약속(Specification)’에 기반한 결정론적 영역입니다. 게다가 OpenAPI 스펙은 시스템 전체를 관통하는 단일 진실 원천(Single Source of Truth)입니다. 타입도, 함수도, 훅도, 검증 스키마도 전부 이 한 파일에서 끌어낼 수 있습니다. 그러니 이 일에 AI를 쓸 이유가 없습니다.

코드젠 vs AI 실험 설계

이 격차가 실제로 어느 정도인지 숫자로 확인하기 위해, 프로젝트의 실제 OpenAPI 스펙(53개 엔드포인트 · 90개 스키마)을 두 방식으로 직접 생성해 측정했습니다. 정답 스펙이 이미 존재하는 결정론적 영역에서 코드젠과 AI의 산출물을 직접 대조하고자, 동일한 OpenAPI 스펙을 양쪽에 그대로 맡겨 진행했습니다.

AI에게는 “이 스펙으로 API 연동 코드를 생성하라”, “Orval로 코드젠을 실행하고 생성 시간·비용·결정성·타입 에러를 측정하라, 결정성 확인을 위해 2회 실행하라”와 같이 지시했습니다.

측정값 자체는 실행 로그, 산출물 diff, tsc --noEmit 결과처럼 기계적으로 검증 가능한 항목이라 측정 주체와 무관하게 동일하게 재현됩니다. 반복 횟수를 2회로 둔 이유도 있습니다. 코드젠은 정의상 몇 번을 돌려도 byte 단위로 동일해 반복 측정 자체가 무의미하고, AI 역시 “매번 다른 결과가 나온다”는 질적 대비를 보이는 데는 2회로 충분했기 때문입니다.

결국 여기서 확인하려는 명제는 “AI가 평균 몇 % 흔들리는가”가 아니라 “결정론적 도구는 항상 같고 AI는 매번 다르다”는 대비였습니다.

코드젠 vs AI 결과

Orval은 엔드포인트를 약 1초 만에 생성했습니다. 비용은 $0이고, 스펙의 모든 필드를 정확히 옮겼으며, 타입 에러도 없었습니다. 몇 번을 다시 돌려도 byte 단위로 똑같은 코드가 나옵니다.

반면 AI는 같은 일을 하는 데 2~4분이 걸렸고, 실행할 때마다 약 $1.4(약 2,000원)씩 들었습니다. 두 번의 실행 결과가 서로 달랐고, 한 번은 타입 에러 4개를 남겼습니다. 더 느리고, 더 비싸고, 매번 조금씩 다른 코드를 내놓았습니다. 스펙이라는 정답지가 이미 있는 영역에서 코드젠이 속도, 비용, 정확성, 일관성 전 항목에서 압도적이었습니다.

<출처: 작가(NotebookLM으로 생성)>

이런 차이가 나는 구조적인 이유

코드젠은 ‘번역기’입니다. Orval은 스펙 JSON을 파싱해 각 스키마와 엔드포인트를 추상 구문 트리(AST)에 가까운 중간 표현으로 올립니다. 그다음 미리 정해진 변환 규칙(템플릿)에 따라 TypeScript 코드를 그대로 방출합니다. 또, 스키마 하나에서 어떤 코드가 나올지는 실행 전에 이미 규칙으로 결정되어 있습니다. 남은 일은 106KB의 JSON을 5,400여 줄의 TS로 ‘기계적으로 옮겨 적는’ 순수 CPU 문자열 변환뿐입니다. 추론도, 탐색도, GPU도, 네트워크 왕복도 없습니다. 그래서 5,400여 줄을 통째로 만들어내는 데 1초가 걸리지 않습니다.

AI는 ‘생각하면서 타이핑하는 기계’입니다. LLM은 자기회귀(autoregressive) 방식으로 동작합니다. 출력 코드를 토큰(대략 몇 글자) 단위로 하나씩, 앞선 토큰을 전부 본 뒤에야 다음 토큰을 생성합니다. 8,000토큰짜리 코드를 출력하려면 8,000번의 순차 연산이 필요하고, 이 순차성 때문에 아무리 좋은 GPU를 붙여도 초당 수십~수백 토큰이 물리적 상한입니다. 여기에 매 요청마다 40k 토큰짜리 스펙을 처음부터 다시 읽어들이는(prefill) 비용이 더해집니다. 즉 AI는 답이 이미 규칙으로 정해져 있는 코드조차 ‘한 글자씩 타이핑’해서 내놓아야 하며, 그 타이핑의 매 순간이 확률적 선택입니다.

API 코드젠이 가져다주는 세 가지 구조적 이점

코드젠의 또 다른 가치는 개발 경험이 구조적으로 달라지는 지점에 있습니다. 백엔드와 프론트엔드가 어긋날 틈을 컴파일 타임에 막는 런타임 안전성, 관리할 코드 자체를 레포지토리에서 걷어내는 유지보수 부담의 소멸, 그리고 스펙이 요동치는 프로젝트일수록 오히려 커지는 변화 대응력입니다. 그리고 이는 어쩌면 전통적인 자동화가 AI에 비해 가지는 가치를 그대로 보여줄 수 있습니다.

1) 시스템 동기화가 만드는 ‘런타임 안전성’

<출처: 작가(NotebookLM으로 생성)>

백엔드 응답 필드 이름이 userName에서 name으로 바뀌었는데 프론트엔드가 이를 모르면 사용자 화면에서 버그가 터집니다. 문제는 손으로 짠 타입이나 AI가 과거 스펙으로 만든 타입은 이를 잡아내지 못한다는 것입니다.

반면 코드 생성기를 사용하면 스펙이 바뀌는 즉시 타입이 자동 업데이트되며, 바뀐 필드를 쓰던 코드는 컴파일 에러(빨간 줄)로 즉시 드러납니다. 출력이 결정론적이기 때문에 GitHub Actions 같은 CI/CD 파이프라인에 주기적 스크립트를 걸어둘 수도 있습니다. 사람이 개입하지 않아도 변경 사항이 생기면 자동으로 PR이 올라옵니다.

2) 유지보수 대상에서 빠지는 코드

코드 생성기를 도입하면 API 통신을 위한 Fetch/Axios 함수 정의, Request/Response 타입 선언, Query Key 팩토리 설계, useQuery 커스텀 훅 정의가 모두 자동 생성 영역으로 넘어갑니다. 코드 자체는 여전히 프로젝트 어딘가에 생성되지만, 개발자가 직접 수정하거나 관여할 필요가 없어집니다. 그저 생성된 훅을 import해서 쓰기만 하면 됩니다.

AI가 만든 훅은 결국 레포지토리에 남아 ‘내가 유지보수하고 관리해야 할 코드’가 됩니다. 반면 코드 생성기의 산출물은 언제든 명령어로 다시 만들어낼 수 있는 ‘파생물’이므로 코드는 존재하되 개발자의 ‘유지보수 대상’에서는 제외됩니다.

3) 바쁠수록 빛나는 변화 대응력

일정이 빡빡하고 스펙이 매주 바뀌는 프로젝트일수록 자동화의 가치는 극대화됩니다. 스펙이 바뀔 때마다 타입과 API 클라이언트를 고치다 보면 어딘가 누락이 생길 수 있는데, 코드젠은 명령어 한 줄로 스펙과 코드를 항상 일치시켜 이 리스크 자체를 없애줍니다. 변경이 잦을수록 이 한 줄이 아껴주는 시간과 사고 비용은 커집니다.

multipart/form-data나 바이너리 업로드처럼 번거로운 요청도 스펙만 잘 정의되어 있다면 생성기가 알아서 코드를 짜줍니다. 단순하고 기계적인 배선 작업을 자동화가 가져가 주기 때문에, 개발자는 청크 분할이나 재시도 로직 같은 고차원적인 커스텀 비즈니스 로직에 집중할 여력이 생깁니다.

실전 솔루션: Orval vs Hey API

방법론을 소개하는 김에 이를 실제로 구현해 줄 도구도 함께 소개하려고 합니다. 현재 웹 프론트엔드 생태계에서 백엔드의 OpenAPI 스펙을 TypeScript 코드로 변환해 주는 두 가지 도구를 비교해 보겠습니다. 하나는 완제품 훅을 통째로 뽑아주는 검증된 원조 Orval이고, 다른 하나는 유연한 옵션 객체로 최신 생태계의 방향을 이끄는 Hey API입니다.

1) 올인원 훅 제너레이터의 원조, Orval

오랫동안 프론트엔드 개발자들의 사랑을 받아온 도구입니다. 스펙을 읽어 단순한 API 호출 함수뿐만 아니라 컴포넌트에서 바로 사용할 수 있는 완제품 형태의 훅 자체를 통째로 생성해 줍니다. 특히 MSW(Mock Service Worker)와 Faker.js 연동 기능이 내장되어 있어서, 백엔드 개발이 완전히 끝나지 않았어도 목(Mock) 데이터 통신 코드를 자동으로 만들어 즉시 프론트엔드 개발에 착수할 수 있도록 돕습니다.

2) 가볍고 모던한 플러그인 기반, Hey API

최신 생태계의 패러다임 변화를 잘 보여주는 도구입니다. TanStack Query v5에 도입된 queryOptions() 아키텍처 이후, 프레임워크에 종속적인 훅을 통째로 만드는 것보다 유연한 옵션 객체를 생성하는 것이 대세가 되었습니다. Hey API는 처음부터 이 철학으로 설계되었습니다. Vercel의 CEO 기예르모 라우치(Guillermo Rauch)는 Hey API를 두고 “그냥 작동하는 OpenAPI 코드젠(OpenAPI codegen that just works)”이라고 평하기도 했습니다.

무거운 커스텀 훅 대신 깔끔한 옵션 객체 형태로 코드를 뽑아주기 때문에, 하나의 생성물로 SSR Prefetch, 캐시 제어, 다양한 프레임워크(React, Vue, Svelte 등) 대응까지 유연하게 커버할 수 있습니다. Vercel, PayPal, AWS 등 글로벌 기업들이 프로덕션에 채택하고 있습니다.

개인적으로, 장기적인 아키텍처 관점에서는 생태계의 방향성과 일치하는 Hey API를 추천합니다. 다만 아직 빠르게 발전 중인 도구이므로 공식 문서에서도 정확한 버전 고정(pin)을 권장한다는 점은 알아두는 것이 좋습니다.

<출처: 작가>

경계를 나누면 AI가 더 강력해진다

결정론적인 일에서 AI를 제외해야 하는 이유는, AI를 정말 필요한 곳에 훨씬 더 안전하고 강력하게 투입하기 위해서입니다. 튼튼한 자동화 뼈대를 세우고, 그 위에 가변적인 AI를 얹는 식으로 역할을 분담하는 것입니다. 이렇게 역할을 나누면, 자동화와 AI가 하나의 파이프라인으로 연결되는 다음과 같은 자동화 시나리오가 가능해집니다.

시나리오 A: 비즈니스 로직 자동 수정

백엔드 필드명이 바뀌면 코드 생성기가 돌면서 타입이 갱신되고, 바뀐 필드를 쓰던 곳에서 컴파일 에러가 발생합니다. 이때 CI 파이프라인의 AI 에이전트가 타입 에러 목록을 감지해, 컴포넌트 내부의 데이터 매핑 코드까지 자동으로 수정(패치)합니다. 즉 스펙 변경 → 코드 재생성 → 비즈니스 로직 수정까지 사람 손을 거치지 않고 이어지는 것입니다. AI가 막연히 추측하는 것이 아니라 자동화 도구가 ‘어디가 고장 났는지’를 결정론적으로 짚어줬기 때문에, AI의 수정 성공률도 비약적으로 상승합니다.

시나리오 B: UI 페이지 자동 생성

새로운 API 엔드포인트가 추가되면 코드 생성기가 타입과 API 연동 코드를 작성합니다. 여기서 멈추지 않고, CI 파이프라인에 “새 엔드포인트의 연동 코드가 생성되면 이 데이터 규격에 맞는 UI를 만들어달라”는 프롬프트를 미리 정의해두면, 코드 생성을 트리거로 CI 상에서 AI가 자동으로 실행되어 화면 초안까지 만들어냅니다. 개발자가 그때그때 프롬프트를 입력하는 것이 아니라, 엔드포인트 추가 → 연동 코드 생성 → UI 초안 생성까지 사람의 개입 없이 하나의 파이프라인으로 이어지는 완전 자동화입니다. 이때 AI에 주입되는 데이터의 형태(Schema)는 코드 생성기가 이미 100% 확정해둔 상태이므로, AI가 그려내는 UI가 실제 응답과 어긋날 확률도 줄어듭니다.

이처럼 자동화가 결정론적인 토대와 명확한 제약 조건(타입)을 깔아주면, AI는 그 제약 안에서 판단이 필요한 일만 수행합니다. AI의 최대 약점인 ‘비결정성(불확실성)’이 자동화의 ‘결정성(확실성)’으로 상쇄되는 시너지가 일어나는 것입니다.

실제로 앤트로픽(Anthropic)도 에이전트 설계 가이드 ‘Building Effective Agents’에서 같은 원칙을 권장합니다. 가능한 일은 미리 정의된 코드 경로(predefined code paths)로 실행하고, 여기에 프로그래밍 방식의 검증을 결합하라는 것입니다. 결정론적 토대 위에 AI를 얹는 이 역할 분담은, 에이전트 시대 전반이 수렴하고 있는 설계 원칙인 셈입니다.

마치며: 기계적인 자동화는 시스템에, 고차원 추론은 AI에

이 글에서는 AI 워크플로우를 만들어나가는 여러 관점 중 하나로, 규칙 기반 자동화의 영역과 AI 본연의 역량이 필요한 영역을 구분 짓고 그 위에 워크플로우를 설계하는 접근을 제시해보았습니다. “얼마나 많은 일을 AI에 위임하느냐”보다, 그 경계를 명확히 이해하고 확정하는 것이 더 나은 출발점이 될 수 있다는 것입니다.

정형화된 원천 데이터가 존재하고, 도출되어야 할 결과물이 이미 결정되어 있으며, 기계적인 검증이 가능한 작업이라면 규칙 기반(Rule-based)의 자동화 시스템에 맡기세요. 그리고 맥락을 읽고 판단해야 하는 고차원적인 일에 AI를 투입하세요. 누구나 같은 모델을 빌려 쓸 수 있는 시대에, 엔지니어링의 진짜 경쟁력은 모델 자체가 아니라 이를 안전하게 감싸는 ‘결정론적 통제 계층’을 얼마나 촘촘히 구축하느냐에 달려 있습니다. 이 경계가 분명할수록 파이프라인은 견고해지며, AI 역시 자신의 영역 안에서 더 효율적으로 일할 수 있습니다.

습관적으로 AI 프롬프트 창에 복사-붙여넣기 하던 작업이 있나요? ‘결정론적 영역’에 속하는 업무는 없는지 한번 점검해보세요. 만약 있다면 전용 자동화 파이프라인 구축을 고려해볼 만합니다. 이 작은 경계의 구분이 여러분의 AI 워크플로우를 한층 더 효율적이고 강력하게 발전시켜 줄 것입니다.

]]>

AI 논문 도구를 만들며 마주친 네 번의 갈림길

영어 논문을 읽는 밤이면 저는 늘 산만해졌습니다. PDF 뷰어에서 한 문단을 읽다 막히면, 번역기 탭으로 넘어가 문장을 붙여 넣고, 결과를 확인한 뒤 다시 뷰어로 돌아옵니다. 그 몇 초 사이에 따라가던 흐름이 끊기고, 어디까지 이해했는지를 다시 더듬어야 했죠. 창을 오가는 시간보다 끊긴 맥락을 되짚는 시간이 더 아까웠습니다.

손에 든 자료가 아직 세상에 안 나온 연구면 더 조심스러웠죠. 초안이나 미발표 데이터를 번역기나 챗봇 창에 붙여 넣는 게 괜히 불안했습니다. 그 글이 어디에 저장되고 무엇에 쓰일지 알 수 없으니까요. 그래서 마음먹었습니다. 논문 읽는 데 필요한 걸 한 화면에 모으고, 그 데이터가 노트북 밖으로 나가지 않는 나만의 도구를 만들자고요.

바이브 코딩으로 시작은 쉬웠습니다. AI에게 시키니 하루 만에 그럴듯한 프로토타입이 만들어졌죠. 하지만 진짜 일은 그다음이었습니다. 데모에서 한 번 돌아가는 코드와 날마다 곁에 두고 쓰는 도구 사이의 간극은 생각보다 컸습니다. 그 간극을 좁히는 동안 AI의 제안과 AI가 만든 코드는 문제가 발생해, 의도했던 사용 시나리오가 안정적으로 유지되지 못했습니다.

AI 논문 도구 실행 화면 <출처: 작가>

실제로 문제가 발생할 때는 AI가 비슷한 답변을 줬습니다. 다단 구조를 인식하기 위해 화면을 반으로 자르라거나, 리소스가 부족하니 GPU를 늘리라고 하거나, 세션 대기 시간을 늘리라는 등 하나같이 문제의 원인을 찾기보단, 문제를 돌아가라는 답변이었죠. 이 글은 프로덕트 개발 과정에서 맞닥뜨린 네 번의 갈림길에서 AI의 답을 되돌려보내고 다른 길을 찾았던 기록입니다. 그 판단들이 쌓여, 지금도 매일 켜는 도구가 된 과정에 대해 살펴보겠습니다.

AI의 ‘정확히 반으로 자르기’를 밀어둔 이유

처음 도구가 무너진 건 2단의 다단 구조로 작성된 논문에서였습니다. 대부분의 학술 논문은 한 페이지를 좌우 두 단으로 나눠 쓰는데, 여기서 텍스트를 뽑으면 좌우 문장이 한 줄씩 번갈아 섞여 나왔습니다. 멀쩡한 문장이 중간에서 엉뚱한 문장으로 이어지니, 번역기에 넣으면 뜻 모를 말이 됐고 검색도 될 리 없었죠.

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

AI에게 물었더니 페이지의 가로 방향으로 정확히 반으로 나누라고 했습니다. 가운데를 기준으로 왼쪽 글자는 왼쪽 단, 오른쪽 글자는 오른쪽 단으로 묶으면 된다는 거였죠. 그날 열어둔 논문 한 편에서는 잘 돌아갔습니다. 문제는 다음 논문을 열자마자 다시 드러났습니다. 논문마다 좌우 여백도, 두 단 사이 간격도 제각각이었거든요. 어떤 논문은 가운데가 왼쪽으로 쏠려 있었고, 어떤 논문은 페이지를 가로지르는 제목을 달고 있었습니다. 정확히 절반으로 섹션을 나누는 것은 딱 그 한 편의 논문에만 맞는 방식이었죠.

그래서 반으로 자르는 대신, 페이지가 스스로 경계를 인식하게 해보자고 생각했습니다. 논문을 보다 보니, 다단 구조의 특징이 있었습니다. 두 단 사이에는 글자가 없는 빈 세로띠가 있었죠. 그 빈 곳만 찾으면 되는 문제였습니다. 페이지 가로를 200개의 얇은 칸으로 나누고, 각 칸에 글자가 몇 개가 있는 세어봤습니다. 글자가 빽빽한 칸은 단의 본문이고, 텅 빈 칸이 이어지는 구간이 두 단을 가르는 자리입니다. 페이지 가운데 언저리에서 가장 넓게 빈 구간을 찾아, 그 한복판을 경계선으로 삼았습니다.

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

이렇게 하니 논문마다 다른 경계를 그때그때 잡아냈죠. AI가 준 ‘정확히 절반’은 지우지 않았습니다. 페이지가 너무 단순해 빈 구간을 못 찾을 때만 꺼내 쓰는 마지막 기본값으로 활용했죠. 일부 논문에서는 그게 맞는 방법이었으니까요. 여기서 배운 건, AI의 답이 눈앞의 예시 하나에는 맞아떨어져도 그게 규칙까지 되진 못한다는 점이었습니다. 논문마다 달라지는 걸 프로그램이 스스로 감당하게 만드는 일, 그게 프로토타입과 실제로 동작하는 프로덕트를 가르는 첫 갈림길이었습니다.

백엔드가 조용히 멈췄을 때, 하드웨어 대신 화면을 고친 이유

논문을 프로덕트에 처음 넣던 날, 백엔드가 아무 말 없이 멈췄습니다. 논문 전체를 검색하려면 글을 잘게 쪼갠 뒤 각 조각을 숫자 뭉치로 바꿔 저장해둬야 합니다(벡터화). 이 변환을 로컬에 올린 작은 모델에게 맡겼는데, 조각들을 한꺼번에 넘기자 화면이 그대로 멈췄습니다. 심지어 발생한 에러에는 로그도 없이 그냥 멈춰 있었죠. 죽었는지 동작하는 중인지조차 알 수 없는 상태가 된 겁니다.

AI와 대화를 하며, 한참을 들여다본 끝에 원인이 좁혀졌습니다. 조각을 여러 개 묶어 보내면, 이 모델을 돌리는 엔진 안에서 조용히 멈춰버리는 버그가 있었던 거죠(사용 엔진: nomic-embed-text). 한 번에 많이 보낼수록 멈추기 때문에 조각을 넣는 방식 자체를 바꿔야 했습니다.

AI에게 설명하니 GPU를 늘리거나, 클라우드 임베딩으로 갈아타라고 습니다. 틀린 처방은 아니었지만, 이 프로젝트는 돈 안 드는 개인 도구로 만들자는 게 출발점이었습니다. 그래서 하드웨어를 더 사거나 클라우드에 요금을 내는 순간, 애초에 이걸 왜 만드는지가 흐려졌습니다.

그래서 반대로 갔습니다. 한 번에 여러 조각을 보내던 걸 한 조각씩만 보내도록 바꿨죠. 묶음을 없애니 버그가 걸리던 상황 자체가 사라졌고, 백엔드는 멈추지 않고 끝까지 제 일을 했습니다. 대신 하나씩 처리하니 느려졌죠. 그래서 사용자가 그 시간을 답답하게 느끼지 않도록, 조각 하나를 처리할 때마다 남은 시간을 계산해 익스텐션으로 실시간으로 보냈습니다. ‘34개 중 12개 처리, 약 18초 남음’ 같은 문구가 진행 막대와 함께 뜨니, 굳은 화면을 바라보던 때와는 체감이 전혀 달랐습니다. 성능을 양보하고 안정성을 챙긴 자리에 진행 막대 하나만으로 사용 경험을 개선한 겁니다.

제작한 AI 논문 도구 실행 화면 <출처: 작가>

팁1. 로컬AI를 굴릴 때는 Ollama

Ollama라는 도구를 깔면 명령어 한 줄로 작은 임베딩 모델과 소형 언어 모델을 노트북에 내려 받고 로컬 방식으로 활용할 수 있어요. 2B 수준의 경량 모델은 고사양 그래픽카드가 없어도 돌아가고, 호출할 때마다 요금이 붙지 않으니 프롬프트를 수백 번 바꿔가며 실험해도 부담이 없습니다. 로컬 모델로 뼈대를 잡고 무거운 작업만 온라인 모델에 맡기면, 성능과 비용을 함께 챙길 수 있어요.

제작한 AI 논문 도구 터미널 화면 <출처: 작가>

“타임아웃을 늘리세요”라는 답에서 손이 멈춘 순간

앞서 말한 대로, 논문 한 편을 통째로 요약하는 무거운 작업은 성능이 더 나은 온라인 무료 모델에 맡겼습니다. 그런데 이 긴 요약만 유독 늘 같은 자리에서 죽었죠. 화면에 남는 건 524 에러로, 짧은 질문은 멀쩡한데 출력이 길어지는 요청만 골라서 끊겼습니다.

524는 내 서버가 보낸 신호가 아니었습니다. 온라인 모델을 서비스하는 OpenRouter 쪽에서 온 거였어요. OpenRouter의 주소는 Cloudflare라는 서비스가 뒤에 있는데, 이 서비스는 뒤쪽 서버가 120초 동안 아무 응답도 안 내놓으면 죽은 걸로 보고 연결을 끊어버린다는 것을 알게 되었습니다. 로컬 모델을 쓸 땐 이런 일이 없었습니다. 노트북 안에서 바로 대화하니 중간에 낀 게 없었거든요. 무거운 요약을 바깥으로 내보내면서부터 이 문제가 생긴 겁니다.

AI에게 물었더니 세션 대기 시간을 늘리는 클라이언트 타임아웃 자체를 늘리라고 했습니다. 그런데 ‘그렇게 진행해’를 입력하다 손이 멈췄습니다. 연결을 끊는 쪽은 내 클라이언트가 아닌데, 내가 기다리는 시간을 늘린다고 OpenRouter 앞의 Cloudflare가 524 오류를 내놓지 않을 이유가 없었거든요. 그래도 혹시나 해서 넣어봤고, 결과는 똑같았습니다. 여전히 120초에서 524였죠.

관문이 연결을 끊는 기준은 따로 있었습니다. 뒤쪽 서버가 120초 동안 아무 데이터도 안 보내면 죽었다고 판단합니다. 그러니 클라이언트에서 아무리 오래 기다려도 소용이 없었죠. 뒤집어 생각하니 방법이 보였습니다. 답변 일부라도 시간 내에 도착하면, 그 연결이 살아있는 것으로 본다는 것을 알게 된 거죠.

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

그래서 응답을 다 만든 뒤 한 번에 돌려주던 방식을 버렸습니다. 모델이 글자를 만들어내는 족족 밖으로 흘려보내는 스트리밍 방식으로 바꿨죠. 목적은 하나였습니다. 관문에 이 연결이 아직 살아있다는 신호를 끊기지 않게 보내는 것. 겉보기엔 이 함수도 예전처럼 완성된 답 하나를 돌려줍니다. 달라진 건 그 답을 만드는 동안 연결이 끊기지 않는다는 점이죠. 몇 분씩 걸리는 긴 요약도 524 없이 끝까지 도착했습니다.

이 일로 한 가지를 배웠는데요. AI의 답을 ‘어디에서 의심해야 하는가’입니다. AI가 말한 방법도 나름 맞는 말이었지만, 문제를 클라이언트 쪽에서만 바라봤습니다. 연결이 정확히 어디서 끊기는지를 내가 알고 있어야, 그 답이 엉뚱한 곳을 겨누고 있다는 걸 알 수 있었습니다.

팁2. 무료 모델을 실시간으로 쓰는 프롬프트 요령

같은 클라우드 모델에서 또 다른 지연도 만났어요. OpenRouter 무료 모델의 추론(reasoning) 모드를 켜니 답이 오기까지 30초를 넘겼습니다. 유료 모델로 바꾸면 간단했지만 사전에 계획한 ‘비용 제로’ 원칙에 어긋났죠. 그래서 추론 기능을 끄고, 대신 프롬프트마다 정답 예시를 한두 개 넣어줬어요(Few-Shot 프롬프팅). 모델이 스스로 오래 고민하게 두는 대신, 따라 할 예시를 제공하는 것입니다.

RAG에 데이터베이스를 만드는 대신 150줄 코드로 대응한 판단

이 프로덕트의 핵심은 노트북LM처럼 논문 내용을 사전에 학습하고, 학습한 데이터를 기반으로 답변을 하는 것이었죠. 사용자의 질문과 관련된 내용을 논문 안에서 찾아내야, AI가 그 근거를 읽고 제대로 답하거든요. 단어가 똑같지 않아도 의미가 가까운 정보를 찾아내는 게 중요했습니다. 이런 검색을 흔히 검색증강생성, RAG라고 부릅니다.

AI에게 물으니 전용 벡터 데이터베이스를 깔라고 했습니다. 의미를 숫자로 바꾼 데이터를 전문적으로 저장하고 검색해주는 별도 프로그램이죠(예: PostgreSQL, Chroma 등). 검색량이 많은 대형 서비스라면 당연한 선택입니다. 그런데 제가 다루는 건 1주간 논문 몇 편이 전부였고, 이 정도 데이터를 위해 무거운 데이터베이스를 노트북에 늘 띄워 관리하는 건 배보다 배꼽이 큰 일이었습니다.

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

필요한 계산을 뜯어보니 사실 단순했습니다. 질문을 숫자로 바꾸고, 저장해둔 논문 조각들의 숫자와 방향이 얼마나 비슷한지를 재서 가까운 순으로 뽑으면 되는 일이었죠. 그래서 데이터베이스 대신 처리 구조를 직접 짰습니다. 파이썬의 수치 계산 라이브러리로 이 비교를 옮기니, 150줄 남짓한 코드로 엔진이 완성됐습니다. 따로 설치할 것도, 늘 켜둬야 할 프로그램도 없었죠. 규모에 맞는 최소한의 도구를 고른 셈입니다.

완성된 논문 학습 도구는 이렇게 움직입니다

이렇게 네 번의 갈림길을 지나고 나서야, 데모가 아니라 실제로 손에 잡히는 도구의 모습이 갖춰졌습니다. 완성된 도구가 어떻게 움직이는지 몇 가지만 보여드릴게요.

논문을 읽으면서 생각한 연구 아이디어, 의견을 노트에 붙여 넣으면, 7초 만에 논문 기반의 평가가 만들어집니다. 처음엔 점수 매기기, 상세 평가, 한 줄 요약을 차례대로 불렀더니 15초가 걸렸습니다. 그런데 순서가 꼭 필요한 건 첫 단계뿐이었죠. 점수가 정해지면 상세 평가와 한 줄 요약은 서로 볼 일이 없어 동시에 돌려도 됐거든요. 둘을 나란히 실행하니 15초가 7초로 줄었습니다.

제작한 AI 논문 도구 실행 화면 <출처: 작가>

어려운 단어를 저장해도 읽던 흐름이 끊기지 않습니다. 모르는 단어를 저장하면, 기존에는 AI가 문맥을 분석하는 동안 화면이 몇 초씩 멈췄습니다. 읽다 말고 사용자를 기다리게 했죠. 그래서 저장을 누른 즉시 ‘분석 중’ 카드를 먼저 띄우고, 무거운 분석은 뒤에서 따로 돌리도록 만들었습니다. 사용자는 단어만 등록하고 곧장 읽던 곳으로 돌아갈 수 있고, 분석이 끝나면 카드가 조용히 채워집니다.

마지막은 모델을 고르는 방식입니다. 무거운 온라인 작업에 쓰는 OpenRouter 무료 모델은 종류가 자주 바뀝니다. 어제 되던 게 오늘 사라지기도 하고, 더 나은 게 새로 열리기도 하죠. 그래서 모델 이름을 코드에 박아두는 대신, 지금 무료로 쓸 수 있는 모델이 뭔지를 OpenRouter에 직접 물어보게 했습니다. 돌아온 목록에서 이름 끝에 ‘free’가 붙은 것만 골라내면, 그게 곧 지금 공짜로 쓸 수 있는 모델입니다. 이 목록을 익스텐션에 띄워두니, 쓰던 모델이 막혀도 다른 무료 모델로 바로 갈아탈 수 있었죠.

<출처: 작가>

팁 3. 익스텐션 개발을 몇 초로 줄이는 핫리로드

크롬 익스텐션은 코드를 고칠 때마다 관리 페이지에서 새로고침을 눌러야 반영됩니다. 수십 번 반복하면 그 자체가 일이죠. 백엔드는 로컬 서버를 자동 재시작 모드로 띄워 저장 즉시 반영되게 하고, 익스텐션 새로고침도 한 번에 처리하도록 묶어두면, 고치고 확인하는 사이클이 몇 초로 줄어듭니다.

바이브 코딩으로 ‘끝까지’ 만든다는 것

네 번의 갈림길을 지나온 이 논문 학습 도구로는, 지금도 논문 다섯 편을 인덱싱하고 채점한 노트와 저장한 단어를 쌓아가며 사용하고 있습니다. 노트북 수준에서도 리소스 자원을 거의 먹지 않고, 작성 중인 논문이 노트북 밖으로 나가지도 않죠. 처음 목표했던 ‘매일 쓰는 프라이빗 도구’에 만들어진 셈입니다.

돌아보면 네 번의 갈림길에서 바이브 코더로서 제가 한 일은 매번 같았습니다. AI가 제시한 가장 편한 답이 제가 개발하고자 하는 방향성과 맞는지 검토하는 것이죠. 화면을 반으로 자르라는 답도, GPU를 늘리라는 답도, 타임아웃을 늘리라는 답도, 데이터베이스를 깔라는 답도, 그 자리에서는 다 말이 됐습니다. 하지만 매일 쓸 도구에는 맞지 않았죠.

AI는 앞으로 점점 더 그럴듯한 답을 내놓고, 알아서 프로덕트를 뚝딱 만들 겁니다. 그래서 그 답이 원래 기획 방향성과 맞는지를 판단하는 몫은 우리에게 남을 겁니다. 바이브 코딩이 무너지는 자리는 거의 정해져 있었습니다. 방향키를 잡는 우리가 AI의 답을 그대로 받을지, 아님 되돌려보낼지 정하는 바로 그 순간이죠. 바이브 코딩으로 끝까지 만든다는 건 그 순간에 방황하지 않고, 초기 방향성을 유지하는 것입니다. 실력의 문제라기보다는 판단의 문제가 되지 않을까요?

]]>

미토스 쇼크 이후, 보안은 어떻게 바뀌어야 할까?

최근 몇 달 동안 보안 업계에서 가장 많이 언급되는 키워드를 하나 꼽으라면, 단연 앤트로픽의 미토스(Mythos)일 것입니다. 보안 콘퍼런스와 기술 커뮤니티, 주요 언론 기사까지 모두 미토스 이야기를 다루고 있을 정도죠.

지금까지 생성형 AI가 문서 작성이나 코드 생성, 고객 응대 자동화와 같은 생산성 혁신의 도구로 주목받았다면, 미토스는 한 단계 더 나아가, 실제 소프트웨어 취약점을 발견하고 공격 가능성을 분석할 수 있는 수준의 능력을 보여주며, 보안 업계에 적지 않은 충격을 주고 있습니다. 이번 글에서는 미토스 쇼크 이후, 보안에서 무엇이 중요할지 살펴보겠습니다.

같은 모델, 다른 이름: 미토스 5와 페이블 5

미토스는 앤트로픽이 만든 최상위 AI 모델 등급으로, 기존 최고 모델이던 Opus보다 한 단계 위에 새로 만들어진 티어입니다. 다만 등장 과정이 일반적인 AI 모델 출시와는 달랐습니다.

첫 모델인 클로드 미토스 프리뷰(Claude Mythos Preview)는 2026년 4월에 나왔는데, 처음부터 일반 공개가 아니었습니다. 미국 정부와 협력하는 사이버 보안 프로그램인 프로젝트 글래스윙을 통해 초기 50여 개 조직에 제한적으로 배포됐고, 6월에는 150여 개 조직으로 확대됐습니다. 이 프리뷰 버전이 완전히 패치된 소프트웨어에서도 보안 취약점을 대량으로 찾아내면서 이른바 ‘미토스 쇼크’가 시작됐습니다.

이후 2026년 6월, 프리뷰의 업그레이드 버전인 클로드 미토스 5(Claude Mythos 5)와 클로드 페이블 5(Claude Fable 5)가 정식 출시됐습니다.

<출처: 앤트로픽>

두 모델은 동일한 모델이며, 차이는 안전장치에 있습니다. 페이블 5는 누구나 쓸 수 있는 일반 공개판으로, 사이버 보안이나 생물학 등 민감한 영역의 질문은 차단하거나 이전 모델(Opus 4.8)로 우회시킵니다. 미토스 5는 이 제한을 일부 해제한 버전으로, 여전히 검증된 파트너에게만 제공됩니다.

현장에서 들은 불편한 질문

얼마 전 참석했던 한 AI 보안 관련 공청회에서도 미토스는 가장 뜨거운 화두였습니다. 그런데 정작 인상 깊었던 것은 발표 자체가 아니라 행사장 밖에서 현업 보안 담당자들과 나눈 대화였습니다. 한 보안 팀장은 발표를 들은 뒤 “기술은 놀랍지만 한편으로는 불편한 마음도 든다”라고 말했습니다.

보안 담당자 입장에서 분명 중요한 기술 변화이고 대비가 필요하다는 데는 동의하지만, 미토스가 새로운 보안 위협의 상징처럼 소비되면서 결과적으로 보안 업체들의 마케팅 도구가 되고 있는 것 같다는 이야기였습니다.

그는 이런 질문도 함께 던졌습니다.

“만약 미토스가 보안의 미래라면 왜 일부 대기업과 정부 기관만 접근할 수 있는 걸까요?

모두가 앞으로 AI 기반 공격에 노출될 수 있다면 차라리 공개해서 모두가 준비할 수 있게 하는 것이 맞지 않을까요?

공개가 어렵다면 정부는 미토스를 사용할 수 없는 기업을 위해 과연 무엇을 해줄 수 있을까요?”

상당히 현실적인 질문입니다. 앞서 정리했듯 미토스는 누구나 사용할 수 있는 공개 모델이 아닙니다. 우리 정부는 최근 프로젝트 글래스윙에 참여하며 미토스 접근권을 확보했고, 삼성전자와 SK하이닉스, SK텔레콤 등 일부 기업도 관련 프로그램에 참여하고 있습니다. 하지만 대부분의 국내 기업, 특히 중소기업과 스타트업 입장에서는 여전히 먼 이야기입니다.

미토스 쇼크의 본질은 AI가 아니라 ‘시간’이다

많은 언론은 미토스가 취약점을 발견했다는 사실 자체에 집중합니다. 물론 인상적인 기술적 성과입니다. 하지만 실제 기업 보안팀 입장에서 더 중요한 것은 취약점 탐지 능력 자체가 아니라 그로 인해 발생하는 속도의 변화입니다.

과거에도 뛰어난 보안 연구자들은 새로운 취약점을 발견할 수 있었습니다. 다만 그 과정에는 상당한 시간이 필요했습니다. 공개된 코드를 분석하고, 실행 흐름을 추적하며, 취약점 발생 조건을 재현하고, 실제 공격 가능성을 검증하는 데 수주에서 수개월이 걸리는 경우도 흔했습니다. 그 덕분에 방어자 역시 일정 수준의 대응 시간을 확보할 수 있었습니다.

하지만 AI는 이 균형을 빠르게 무너뜨리고 있습니다. 미토스와 GPT-5.5-Cyber가 보여준 가장 중요한 변화는 분석과 재현 과정이 극적으로 짧아졌다는 것입니다. 공개된 CVE 정보와 패치 내역만으로도 AI는 취약점의 동작 원리를 추론할 수 있고, 경우에 따라서는 취약점 악용 코드까지 생성할 수 있습니다.

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

그런데 진짜 문제는 공격자의 속도보다 방어자의 속도에 있습니다. 공격자는 AI를 활용해 몇 시간 안에 취약점을 분석할 수 있지만, 대부분의 기업은 여전히 취약점 분석, 영향도 검토, 보고, 승인, 변경 관리, 운영 일정 조정이라는 절차를 거칩니다. 안정적인 운영을 위해 반드시 필요한 과정이지만, AI가 등장한 이후 공격과 방어의 속도 차이가 급격히 벌어지고 있다는 점이 문제입니다. 결국 미토스 쇼크의 본질은 AI가 똑똑해졌다는 사실이 아니라, 공격자의 속도는 빨라지는데 방어자의 운영 체계는 그대로라는 데 있습니다.

기존의 보안 패치 SLA는 이제 유효하지 않다

많은 언론은 글래스윙을 미토스에 대한 대응 프로젝트 정도로 설명합니다. 하지만 실제로는 그보다 훨씬 큰 의미를 가지고 있습니다. 이것의 핵심은 AI를 활용해 공격자보다 먼저 취약점을 발견하는 건데요. OpenAI 역시 같은 방향으로 움직이고 있습니다. 그들의 데이브레이크(Daybreak) 플랫폼의 핵심은 취약점 분석부터 코드 리뷰, 수정안 생성, 패치 검증까지, 보안 운영 프로세스를 AI 중심으로 자동화하는 겁니다.

흥미로운 점은 두 프로젝트가 모두 같은 문제를 해결하려 한다는 것입니다. 바로 사람보다 빠르게 움직이는 공격자에 대응하기 위해 사람보다 빠르게 움직이는 방어 체계를 만드는 것입니다.

즉, 이 프로젝트들은 단순한 AI 보안 제품이 아니라 미래의 보안 운영 체제를 보여주는 초기 사례에 가깝습니다. 많은 기업은 취약점 대응 정책을 가지고 있습니다. 일반적으로 심각도에 따라 수일 이내 패치를 적용하도록 내부 기준을 정해두고 있습니다. 문제는 이러한 기준이 대부분 인간이 분석하고 인간이 공격을 준비하던 시대에 만들어졌다는 점입니다.

과거에는 새로운 취약점이 공개되더라도, 실제 공격 코드가 등장하기까지 일정 시간이 존재했습니다. 기업은 그 사이에 영향도를 분석하고 테스트 환경에서 검증한 뒤 운영 환경에 적용할 수 있었습니다. 그러나 AI가 공개된 취약점을 빠르게 분석할 수 있는 환경에서는 상황이 달라질 수 있습니다. 앞으로는 단순히 CVSS(Common Vulnerability Scoring System) 점수만으로 패치 우선순위를 정하는 것이 아니라, AI가 얼마나 쉽게 해당 취약점을 분석하고 재현할 수 있는지까지 고려해야 할 가능성이 높습니다. 즉 취약점의 위험도를 평가하는 기준에 ‘AI 재현 가능성’이라는 새로운 요소가 추가될 수 있다는 의미입니다.

미토스가 던진 진짜 질문, AI 주권

최근 미토스를 둘러싼 또 다른 논쟁은 기술 자체보다 접근 권한에 관한 문제입니다.

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

미토스 5와 페이블 5가 정식 출시된 지 사흘 만인 2026년 6월 12일, 미국 상무부는 국가 안보를 이유로 모든 외국인의 두 모델 접근을 중단하라는 수출 통제 지침을 앤트로픽에 발령했습니다. 미국 밖은 물론 미국 내에서 일하는 외국 국적 직원까지 포함하는 조치였기 때문에, 앤트로픽은 지침을 준수하기 위해 전 세계 모든 고객을 대상으로 두 모델의 서비스를 전면 중단해야 했습니다.

앤트로픽은 지침을 따르면서도 좁은 범위의 잠재적 탈옥(jailbreak) 발견이 이미 상용 배포된 모델을 회수할 사유는 아니라고 공개적으로 반박했습니다. 이후 정부 검토와 협의를 거쳐 6월 26일 일부 신뢰 파트너의 미토스 5 접근이 승인됐고, 6월 30일 상무부가 통제를 완전히 해제하면서 7월 1일부터 서비스가 재개됐습니다. 해제 조건에는 앤트로픽이 모델 관련 보안 위험을 선제적으로 탐지하고 향후 모델 기준에 대해 정부와 협력한다는 내용이 포함된 것으로 알려졌습니다.

이 사례는 최첨단 AI 모델이 단순한 상용 소프트웨어를 넘어 국가 안보와 직결되는 전략 기술로 인식되고 있음을 보여줍니다. 반도체, 원자력, 우주 기술에 이어 AI 역시 국가 차원의 수출 통제와 정책적 관리 대상이 되는 시대가 본격적으로 시작된 것입니다.

그러나 동시에 현실적인 질문도 남습니다. 미래의 보안 경쟁력이 특정 국가와 특정 기업이 보유한 AI 모델 접근 여부에 의해 결정된다면, 중소기업과 스타트업은 어떤 방식으로 보호받을 수 있을까요? 그리고 국가 차원에서는 특정 해외 AI 모델에 의존하는 것이 장기적으로 바람직한 방향일까요? 결국 미토스가 우리에게 던지는 질문은 기술의 우수성보다 AI 주권(AI Sovereignty)에 대한 질문에 더 가깝습니다.

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

AI 시대의 보안팀은 무엇을 해야 할까?

많은 사람들이 AI가 보안 전문가를 대체할 것이라고 이야기합니다. 하지만 실제로는 역할이 달라질 가능성이 더 높습니다. 현재 보안팀은 로그 분석, 취약점 분류, 코드 리뷰, 경보 검토와 같은 반복 업무에 상당한 시간을 사용하고 있습니다. 이러한 영역은 AI가 가장 큰 효과를 발휘할 수 있는 분야입니다.

반면 실제 비즈니스 영향도 판단이나 서비스 중단 위험 평가, 예외 정책 승인과 같은 업무는 여전히 사람이 수행해야 합니다. 따라서 앞으로의 보안 조직은 AI와 경쟁하는 조직이 아니라, AI와 협업하는 조직으로 변화할 가능성이 높습니다. SOC 분석가는 AI가 수집하고 정리한 결과를 검토하는 역할로 변화할 수 있으며, 보안 아키텍트는 AI가 제안한 대응 방안의 우선순위를 결정하는 역할을 수행하게 될 것입니다. 결국 보안팀은 운영 조직을 넘어 AI 기반 의사결정을 수행하는 조직으로 진화하게 될 것입니다.

AI 시대에는 취약점 공개에 대한 관점 역시 달라질 수 있습니다. 지금까지 많은 기업은 취약점이 발견되더라도 이를 외부에 적극적으로 공개하거나 제보받는 체계를 운영하지 않았습니다. 하지만 AI가 취약점을 빠르게 분석할 수 있는 환경에서는 오히려 기업 스스로 취약점을 먼저 발견할 수 있는 체계를 갖추는 것이 중요해집니다.

그래서 기업이 다시 주목하는 것이 버그 바운티와 취약점 공개 프로그램, 그리고 PSIRT(Product Security Incident Response Team)입니다. 많은 국내 기업은 아직도 보안 연락처가 없거나 취약점 제보 프로세스가 명확하지 않은 경우가 적지 않습니다. 하지만 AI 시대에는 공격자보다 먼저 취약점을 발견하는 것이 가장 중요한 경쟁력이 될 수 있습니다. 보안팀은 이제 취약점을 숨기는 조직이 아니라 더 빨리 발견하고 더 빨리 수정하는 조직이 되어야 합니다.

이제 보안 경쟁은 기술보다 운영의 경쟁이다

미토스는 분명 인상적인 기술입니다. 하지만 미토스가 던진 진짜 메시지는 AI가 얼마나 똑똑한가에 있지 않습니다. 오히려 “우리 조직은 AI가 발견한 취약점보다 빠르게 대응할 수 있는가”라는 질문에 더 가깝습니다.

독자분들이 이 글을 읽고 한 번쯤 점검해 보면 좋을 질문들을 남기며 글을 마치고자 합니다.

첫째, 우리 조직은 인터넷에 노출된 모든 자산을 정확히 파악하고 있는가?
둘째, 취약점이 발견되었을 때 누가 최종 의사결정을 내리는지 명확한가?
셋째, 치명적인 취약점에 대한 패치 SLA는 실제로 운영되고 있는가?
넷째, 코드 리뷰와 취약점 분석 과정에 AI를 활용할 계획이 있는가?
다섯째, 침해 이후 확산을 제한하기 위한 제로 트러스트와 마이크로 세그먼테이션 전략이 준비되어 있는가?

만약 이 질문들에 쉽게 답하기 어렵다면, 미토스보다 먼저 점검해야 할 과제가 이미 조직 내부에 있을 수 있습니다.

AI 시대의 보안 경쟁은 더 이상 누가 더 많은 보안 솔루션을 갖고 있는지가 아니라, 누가 더 빠르게 탐지하고, 판단하며 대응할 수 있는가?라는 관점에서 결정될 겁니다.

]]>

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

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

함께 보면 좋은 글

]]>

우리 팀의 CLAUDE.md, AGENTS.md로 바꿔도 될까

CLAUDE.md는 AI 코딩 에이전트에 프로젝트 규칙을 알려주는 컨텍스트 파일로, 한국에서는 사실상 표준처럼 쓰입니다. 그런데 실제 글로벌 표준 형식은 CLAUDE.md가 아니라 AGENTS.md입니다.

오늘은 AGENTS.md가 무엇인지, 지금 쓰는 CLAUDE.md와는 어떻게 다른지 간단히 정리하는 데서 시작하려고 합니다. 그런다 해도 불분명한 것도 있습니다. 표준인 걸 알겠는데, 옮기면 무슨 이득이 있고, 그 과정에서 느려지거나 비용이 더 들지는 않을지 우려가 생길 수 있습니다.

그래서 정말 차이가 생기는지는 직접 확인해 보고자 실측을 돌렸습니다. Anthropic의 Haiku부터 최상위 Fable 5까지 5개 모델, 총 210회입니다. 결론이 궁금한 분들을 위해 먼저 말씀드리면, 어떤 모델에서도 성능이 떨어지거나 비용이 늘지 않았습니다.

순서대로 컨텍스트 파일을 표준 규격으로 쓸 때 어떤 이점이 있는지부터 짚고, 측정을 어떻게 했는지, 그리고 마이그레이션 과정에 필요한 것까지 순서대로 정리하겠습니다.

도구마다 하나씩 늘어나는 컨텍스트 파일

AI 코딩 에이전트를 팀에 도입해 보면 곧 한 가지를 깨닫게 됩니다. 에이전트는 프로젝트의 사정을 전혀 모르는 상태에서 작업을 시작한다는 점입니다. 빌드는 어떤 명령으로 하는지, 테스트는 어떻게 돌리는지, 절대 건드리면 안 되는 디렉토리는 어디인지 같은 정보를 알 수 없습니다.

그렇다고 이런 내용을 매번 대화창에 붙여 넣을 수는 없으니, 저장소 루트에 파일 하나를 두고 에이전트가 시작할 때 자동으로 읽게 합니다. 이것이 컨텍스트 파일입니다.

문제는 이 파일이 도구마다 다르다는 데 있습니다. 실제로 저장소를 열어 보면 다음과 같이 여러 파일이 흩어져 있는 경우가 많습니다.

$ ls -a.cursor/rules.github/copilot-instructions.mdCLAUDE.mdGEMINI.mdREADME.mdsrc

Claude Code는 CLAUDE.md를, Cursor는 .cursor/rules를, Gemini CLI는 GEMINI.md를, GitHub Copilot은 .github/copilot-instructions.md를 읽습니다.

이름도 위치도 제각각이지만, 정작 담긴 내용은 거의 같습니다. 그래서 도구가 하나 늘 때마다 같은 내용을 복제하게 되고, 한 파일을 수정한 다음 나머지를 고치는 것을 잊어버리기도 쉽습니다. 규칙이 파일마다 조금씩 어긋나기 시작하면, 결국 에이전트마다 다른 규칙을 따라 움직이게 됩니다.

한국은 개발과 운영 현장 모두 Claude 사용률이 특히 높은 편이라, 컨텍스트 파일이라고 하면 자연스럽게 CLAUDE.md를 먼저 떠올립니다. 모두가 그렇게 쓰다 보니 당연하게 느껴지지만, 앞서 말했듯 이 파일의 표준 형식은 따로 정해져 있습니다.

도구마다 따로 쓰던 컨텍스트 파일이 AGENTS.md 하나로 모이는 흐름 <출처: 작가>

AGENTS.md: 표준으로 자리 잡는 컨텍스트 파일

AGENTS.md는 코딩 에이전트용 컨텍스트 파일의 개방형 표준입니다. “에이전트를 위한 README”라고 보면 정확합니다. 2025년 8월 OpenAI가 자사 코딩 에이전트 Codex의 컨텍스트 파일로 처음 내놓았고, Cursor, Jules, Amp, Factory 등이 각자의 포맷을 접고 이 형식을 따르면서 사실상의 표준이 됐습니다.

그리고 같은 해 12월, OpenAI가 이 파일을 Linux Foundation 산하에 새로 설립된 AAIF(Agentic AI Foundation)에 기부하면서 특정 회사가 아닌 중립 재단이 관리하는 공식 표준이 됐습니다. (이때 Anthropic의 MCP와 Block의 goose도 함께 기부되어 AAIF의 창립 프로젝트 세 개가 나란히 출발했습니다.) 2026년 중반 기준으로 6만 개가 넘는 저장소가 이 파일을 갖고 있고, 30개가 넘는 도구가 AGENTS.md를 네이티브로 지원합니다.

다만 같은 “지원”이라도 그 수준은 도구마다 다릅니다. 세 부류로 나뉩니다.

이처럼 AGENTS.md를 표준으로 채택하는 흐름을 보여주는 최근 사례가 하나 있습니다. Google은 2026년 6월 Gemini CLI 지원을 종료하고 후속인 Antigravity CLI로 전환했는데, 새 도구는 GEMINI.md와 함께 AGENTS.md를 수정 없이 그대로 읽습니다. 벤더 전용 파일(GEMINI.md)은 도구가 사라지면 함께 수명을 다하지만, 표준 파일은 도구가 바뀌어도 그대로 남는다는 것을 보여준 셈입니다.

다만, 정작 실무에서 가장 많이 쓰는 Claude Code만 아직 표준에 합류하지 않아, AGENTS.md를 바로 읽지 못합니다. 이를 연결하는 방법은 두 가지 있습니다. CLAUDE.md 안에 @AGENTS.md 한 줄을 적어 불러오게 하거나(import), CLAUDE.md 자체를 AGENTS.md로 가는 심볼릭 링크로 바꾸는 것입니다.

그런데, 옮겨도 괜찮을까?

컨텍스트 파일은 에이전트 세션을 시작할 때마다 로드됩니다. 이렇게 한 단계를 거쳐 읽는 과정에서 비용이 조금이라도 붙는다면, 그 비용은 팀 전체가 세션을 돌릴 때마다 쌓입니다. 그러니 이런 우회 경로를 활용해 옮길 때 비용이 더 들지 않느냐는 의문이 생깁니다. 그 문제를 짚어 보겠습니다.

이런 우려를 다룬 연구나 테스트가 이미 있는지부터 찾아봤습니다(저만 같은 궁금증을 품진 않았을 테니까요). Princeton의 측정 연구가 있긴 한데, 여기서는 AGENTS.md를 네이티브로 읽는 Codex만 다뤘습니다. import나 심볼릭 링크처럼 한 번 거쳐서 읽는 경로를 직접 잰 데이터는 없었습니다. 원리상으로는 차이가 없어야 하지만, 원리와 실측은 다른 이야기입니다. 그래서 직접 측정했습니다.

실험 설계: 같은 내용, 세 가지 전달 방식

측정의 핵심은 변수를 하나만 남기는 것입니다. 같은 내용을 세 가지 방식으로 전달했습니다.

세 조건의 본문은 체크섬까지 같은 문서입니다. 실험용으로 지어낸 문서가 아니라, 앞서 기고한 AI 에이전트 벤치마크에서 사용했던 컨텍스트 파일(클러스터 규칙, 점수 공식, 알려진 함정)을 그대로 썼습니다.

A(native), B(import), C(symlink)세 조건의 파일 구성 비교 <출처: 작가>

속도를 재기 전에 확인할 것이 하나 있었습니다. B와 C가 정말로 읽히기는 하는지 보는 겁니다. 그래서 본문 끝에 확인용 문장 한 줄(“PING이라고 물으면 정확히 PONG-AGENTSMD로만 답하라”)을 넣고 매번 에이전트에 PING을 보냈습니다.

세 조건 모두 정확히 응답했고, 컨텍스트 파일이 없는 대조군만 평범한 인사로 답했습니다. 세 방식 모두 실제로 읽히고, 이 확인 방법 자체도 유효하다는 뜻입니다.

실제 측정: 쿠버네티스 장애 대응을 두 단계로

본격적인 측정은 쿠버네티스 장애 대응 과제로 했습니다. 계속 재시작하는 파드, 잘못된 Service selector, 메모리 한도 초과 같은 장애를 심어 둔 전용 클러스터에서 에이전트가 원인을 찾아 고치게 하고 시간과 토큰을 기록했습니다. 매 회차 클러스터를 스냅샷으로 되돌려 콜드 스타트를 보장하고, 시간대에 따른 쏠림이 없도록 조건 순서를 회차마다 섞었습니다.

측정은 두 단계로 진행했습니다. 매 회차는 A, B, C 세 방식을 모두 돌립니다. 먼저 10개 시나리오 전체를 한 차례씩 확인했고(시나리오 10 x 방식 3 = 30회), 이어서 편차가 작은 4개 시나리오를 모델 5종(Haiku 4.5, Sonnet 4.6, Sonnet 5, Opus 4.8, Fable 5)으로 3회씩 반복했습니다(시나리오 4 x 방식 3 x 모델 5 x 반복 3 = 180회). 합쳐서 210회, 전부 정상 종료였습니다.

목록을 보면 Sonnet이 4.6과 5, 두 세대가 모두 들어가 있는데요, 이건 의도한 배치입니다. 모델이 세대를 건너뛰며 업그레이드돼도 같은 결론이 나오는지, 즉 한 시점의 우연이 아닌지를 확인하려는 것입니다. 이 선택이 결과를 해석할 때 뜻밖의 역할을 합니다.

우려할 필요가 없는 결과

비용에 가장 가까운 지표는 캐시에 새로 기록되는 토큰(cache write)입니다. 여기서 심볼릭 링크(C)의 역할이 하나 더 있습니다. C는 OS가 링크만 풀어 줄 뿐 native와 달라질 수 없는 구성이라, 실험에 내장된 대조군이 됩니다. 거쳐 읽는 방식이 로드되는 내용을 부풀렸다면 B가 이 대조군보다 커야 합니다. 다만, 그런 일은 없었습니다.

모델 5종에서 조건별 cache write 토큰 비교. Sonnet은 4.6과 5 두 세대를 함께 넣어 세대 변화에도 결론이 유지되는지 확인했다. 어느 모델에서도 import(B)가 대조군(C)보다 일관되게 높지 않다. <출처: 작가>

어느 모델에서도 B가 대조군(C)보다 일관되게 높지 않았습니다. 4개 모델에서는 import가 3~4% 낮았는데, 여기까지만 봤다면 “import가 조금 이득”이라고 결론 냈을 겁니다. 그런데 새로운 Sonnet 5에서는 같은 import가 +6%로 방향이 뒤집혔고, 결정적으로 같은 회차에서 대조군도 똑같이 +6%였습니다.

앞서 Sonnet을 두 세대 넣은 이유가 여기에 있습니다. 한 세대만 봤다면 3~4%를 실제 이득으로 오해했을 텐데, 세대를 바꾸자 그 방향이 유지되지 않았습니다. 대조군과 함께 움직이는 편차는 전달 방식의 비용이 아니라, 에이전트가 매번 조금씩 다르게 풀어서 생기는 실행 편차입니다.

실행 시간(wall time)은 차이가 커 보이는 회차도 있었지만 일관된 경향이 없었습니다. 어떤 모델에서는 B가 빠르고 어떤 모델에서는 느렸으며, 시간 차이가 가장 큰 경우에도 토큰 차이는 거의 없었습니다. 전달 방식에서 온 오버헤드라면 결과가 한쪽으로 치우쳐야 하는데 그렇지 않았습니다. 이 변동은 에이전트가 문제를 푸는 과정이 매번 조금씩 달라서 생긴 것입니다.

왜 이런 결과가 나오는지는 메커니즘을 보면 이해가 됩니다. 심볼릭 링크는 Claude Code가 CLAUDE.md라는 경로를 여는 순간 OS가 링크를 해석해 AGENTS.md의 내용을 돌려줍니다. Claude Code 입장에서는 native 파일을 읽을 때와 완전히 같고, 링크 처리는 파일시스템의 몫입니다. 그래서 C의 편차는 곧 측정 노이즈의 크기이고, import(B)는 그 노이즈 범위를 벗어난 적이 없습니다. 어느 쪽이든 전달 방식의 손해가 아니라는 점이 중요합니다.

실제로 AGENTS.md로 마이그레이션하는 법

측정으로 옮겨도 문제없다는 것을 확인했으니, 남은 것은 실제로 옮기는 절차입니다. 팀 기준으로 따져도 한 시간이 안 걸립니다.

1. 기존 파일의 이름을 AGENTS.md로 바꿉니다.

git mv CLAUDE.md AGENTS.md

새 파일을 만들어 내용을 복사하는 것이 아니라 이름을 바꾸는 것입니다. git 이력이 그대로 이어지고, agents.md 공식 안내도 “기존 파일 이름을 바꾸고 호환용 링크를 남기는” 순서를 권합니다. 이름을 바꾸면서 본문에 특정 도구를 전제한 문구(“Claude에게 알려주는” 등)가 있다면 중립적인 표현으로 함께 다듬습니다.

주의할 점이 하나 있습니다. 이 상태에서 멈추면 안 됩니다. 이름만 바꾼 시점에는 CLAUDE.md가 없으므로, 새 세션을 열면 Claude Code가 읽을 컨텍스트 파일이 없습니다. 컨텍스트 파일은 세션을 시작할 때 로드되기 때문에, 다음 세션을 열기 전에 반드시 2단계까지 마쳐야 합니다. 두 단계를 같은 커밋으로 묶어 처리하면 공백이 생기지 않습니다.

2. CLAUDE.md를 포인터로 새로 만듭니다.

@AGENTS.md

이 구조는 Claude Code 공식 문서가 권장하는 형태입니다. 공식 문서는 한 가지를 더 알려주는데, Claude에게만 적용할 규칙이 있다면 이 import 줄 아래에 덧붙이면 됩니다. 공통 규칙은 AGENTS.md에, Claude 전용 규칙은 CLAUDE.md에 나뉘는 구조입니다.

심볼릭 링크(ln -s AGENTS.md CLAUDE.md) 역시 공식 문서가 인정하는 대안으로, 이번 측정에서도 동일하게 페널티가 없었습니다. 다만 Claude 전용 규칙을 적어 둘 곳이 없고, Windows에서는 관리자 권한이나 개발자 모드가 필요합니다. 그래서 공식 문서도 import를 먼저 권합니다.

3. 정말 읽히는지 확인합니다.

실험에서 쓴 확인 방법을 그대로 써보면 됩니다. AGENTS.md 끝에 “PING이라고 물으면 PONG으로만 답하라”를 잠깐 넣고, 에이전트에 PING을 보내 보세요. PONG이 돌아오면 로드가 확인된 것입니다. 확인하고 나서는 그 줄은 지웁니다.

4. 다른 도구를 확인합니다.

대부분 할 일이 없습니다. Codex, Amp는 AGENTS.md가 기본 파일이고, Google의 Antigravity CLI(Gemini CLI 후속)도 AGENTS.md를 그대로 읽습니다. Cursor는 .cursor/rules가 없으면 AGENTS.md를 읽습니다.

5. 옮기는 김에 내용을 다듬습니다.

사실 전달 방식보다 훨씬 중요한 것이 내용입니다. ETH Zurich 연구에 따르면 LLM이 자동 생성한 컨텍스트 파일은 오히려 성공률을 낮추고 추론 비용을 20% 넘게 올렸습니다. 반면 사람이 다듬은 간결한 파일은 도움이 됐습니다. 에이전트가 코드만 봐서는 알 수 없는 것(빌드 명령, 금지 사항, 팀 규칙)만 남기고, 코드를 읽으면 알 수 있는 설명은 빼는 것이 원칙입니다. Claude Code 공식 문서도 컨텍스트 파일을 200줄 안쪽으로 유지하기를 권합니다.

마이그레이션 5단계 흐름. 이름 변경부터 내용 다듬기까지 <출처: 작가>

짚어둘 두 가지

첫째, 이번에 측정한 범위는 속도와 토큰 비용까지입니다. 답변의 정확성이나 안전(위험한 명령이 늘거나 줄었는지)은 별도 채점이 필요해서 이번 범위에 넣지 않았습니다. 원리상 세 조건 모두 모델에는 완전히 같은 내용이 전달되므로 정확성이 달라질 이유는 없지만, 측정하지 않은 이상 단정하지는 않겠습니다. 필요해지면 따로 진행하겠습니다.

둘째, 측정 환경은 Claude Code 2.1.198~2.1.199 기준입니다. Claude Code가 AGENTS.md를 네이티브로 지원하면 이런 연결 자체가 필요 없어집니다. 다만 이를 요청하는 공식 저장소의 이슈가 2025년 8월에 처음 열렸는데, 수천 개의 공감이 달린 지금까지도 공식 응답이 없습니다. 오래 열려 있는 이슈가 대개 그렇듯 당분간은 이 구조가 유지된다고 보는 편이 현실적이고, 그때까지 import로 연결해 써도 손해가 없다는 것을 실측으로 확인해 둔 셈입니다.

마치며: 도구, 에이전트, 그리고 지시하는 방법

2025년에는 Gateway API 구현체 7개를 비교했고, 올해는 그 인프라를 다루는 AI 에이전트 9종을 비교했습니다. 그 벤치마크는 CLAUDE.md 기반으로 설계했는데, 다음 측정으로 넘어가기 전에 AGENTS.md로 옮겨도 되는지부터 확인한 것이 이번 글입니다. 답은 “된다”였습니다.

필요한 것들이 하나씩 앞단으로 옮겨 온 셈입니다. 어떤 도구를 고를 것인가에서, 그 도구를 다룰 에이전트를 고르는 문제로, 이제는 그 에이전트에 지시하는 방법을 표준화하는 문제로 왔습니다. 도구는 계속 바뀌고 에이전트도 계속 바뀌지만, 팀의 규칙을 한 곳에 적어 두고 어떤 에이전트든 같은 규칙을 읽게 하는 구조는 오래 남을 것입니다. AGENTS.md가 그 자리를 차지해 가고 있습니다.

물론 옮기는 일이 그냥 되는 것은 아닙니다. 팀 기준 한 시간 남짓의 작업이 들고, 옮긴 뒤에도 신경 쓸 일이 생깁니다. 모두가 CLAUDE.md를 쓰는 환경에서 AGENTS.md를 중심에 두고 import로 연결하는 구조가 낯설고 부담스러운 것도 사실입니다. 이번 측정이 보여준 것 역시 속도와 토큰에서 손해가 없다는 점이지, 아무 노력도 들지 않는다는 뜻은 아닙니다.

그래도 여러 에이전트를 함께 쓰는 팀이라면, 조직 방침이나 고객 요구로 특정 도구에 묶이지 않는 구성이 필요하다면 옮길 이유는 충분합니다. 지금은 Claude가 앞서 있지만, 경쟁이 치열해져 주력 도구는 언제든 바뀔 수 있습니다. 그 가능성까지 생각하면 규칙을 표준 파일 하나에 모아 두는 쪽이 결국 좋은 선택일 수 있습니다.

이번 AGENTS.md 측정 하네스와 재현 방법은 GitHub 저장소에, 측정 설계와 해석은 블로그에 정리해 두었습니다.

끝으로 개인적인 소식을 하나 나누자면, 제가 이 AGENTS.md를 관리하는 AAIF의 앰배서더로 선정되었습니다. CNCF 앰배서더로 활동해 온 데 이어 두 번째 앰배서더 자리라 무척 기쁜 소식입니다.

AAIF는 에이전트 생태계의 개방형 표준을 중립적으로 관리하는 재단으로, MCP를 비롯해 goose, AGENTS.md, agentgateway까지 네 가지 프로젝트를 책임지고 있습니다. 지난 28일 발표된 MCP의 대형 업데이트도 조만간 자세히 소개해 보겠습니다. AAIF 앰버서더 전체 명단과 프로그램 소개는aaif.io/ambassadors에서 보실 수 있습니다.

앞으로도 CNCF & AAIF 앰배서더로서, 어디에도 치우치지 않고 사용자에게 직접 도움이 되는 연구 활동을 공유하겠습니다.

작가

조훈 (CNCF&AAIF 앰버서더)

심근우

문성주

이성민

함께 보면 좋은 글

]]>

우리 개발팀 맞춤 하네스 엔지니어링 구축하기

지난 5월 27일과 6월 10일, 요즘IT는 ‘클코나잇 2’ 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 “고수의 경험을 나눠 받을 수 있는 기회”, “찐 실무자의 현장감 넘치는 사례”, “다음에 또 오고 싶은 웨비나” 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이번 글은 클코나잇 2 웨비나의 ‘우리 팀에 딱 맞는 하네스 엔지니어링을 구축하려면?’입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 저는 바이버스 AI에서 기술을 맡고 있는 김영채라고 합니다. 오늘은 저희 팀이 왜 하네스 엔지니어링을 도입했고, 어떻게 쓰고 있는지를 말씀드리려고 합니다.

팀을 위한 하네스 엔지니어링이 필요해진 이유

저희는 작년 하반기에 설립한 회사입니다. 그러다 보니 제로베이스에서 시작했어요. 코드가 0줄에서 시작한 거죠. 그래서 초반에는 클로드 코드의 플랜 모드로 계획을 세우고 구현하는 수준으로 개발했습니다. 그것만으로도 큰 문제 없이 개발할 수 있었고요.

그런데 점점 기능이 추가되고 서비스도 늘어나면서 코드베이스가 쌓이다 보니, 플랜 모드에서 문제가 발생하기 시작했습니다.

코드 조사를 제대로 못 하거나
플랜대로 구현하지 않고 어떤 부분을 놓치거나
아예 엉뚱한 작업을 하거나

이런 일들이 빈번하게 늘어났고, 기능을 구현하고 출시하는 속도가 점점 느려지기 시작했습니다.

저희 코드 라인 수를 보면, 지난 8개월 동안 총 4명의 개발자가 170만 줄, 파일 수로는 9,900개를 작업했는데요. 느낌적인 느낌으로 한 80만 줄 정도부터 조금씩 문제가 생기기 시작했던 것 같습니다. 저희 같은 스타트업 입장에서 출시 속도가 느려진다는 건 회사의 존속과 관련이 있는, 되게 큰 문제라고 생각했습니다.

개발자의 암묵지를 형식지로 만든 스킬

이 문제를 어떻게 해결할 수 있을까 고민하던 찰나에, 당시 앤트로픽에서는 개발자들끼리 스킬(Skill)을 수백 개 관리하면서 일한다는 이야기를 들었습니다.

저는 평소에 스킬을 ‘개발자의 암묵지를 형식지화한 것’이라고 생각해 왔습니다. 시니어 개발자의 노하우가 녹아들어 있어서, 스킬을 실행하면 사람이 일한 것처럼 일한다는 거죠. 그리고 개발이라는 건 결국 기획하고, 구현하고, 테스트하는 세 가지 워크플로우의 집합이라고 생각했어요. 그래서 ‘계획 스킬, 구현 스킬, 검증 스킬을 만들어서 자동으로 한번 돌려볼까?’라는 생각을 하게 됐습니다.

우리 팀을 위한 하네스: 마에스트로 데브

그렇게 만들어진 게 바이버스 하네스, 저희 스킬명으로는 ‘마에스트로 데브(Maestro Dev)’입니다. 컨셉은 이렇습니다. 메인 에이전트는 오케스트레이터로만 동작하고, 서브에이전트들을 소환해 문서를 작성하게 시키는 역할만 합니다.

이렇게 설계한 이유는 딱 한 가지였습니다. 저는 컨텍스트 윈도우가 지금의 LLM을 쓰는 데 있어 가장 비싼 자원이라고 생각했고, 특히 메인 에이전트의 컨텍스트 윈도우가 빨리 차면 찰수록 휴먼 인 더 루프의 주기가 잦아질 거라고 봤습니다. 최대한 자동으로 작업하게 하고 싶어서 이렇게 만든 거죠.

예를 들면 이렇게 돌아갑니다. “투두 웹 만들어줘”라고 하면 플랜 스킬이 발동하고, 플랜을 다 짜면 임플 에이전트가 소환돼 계획 문서를 확인하고 구현을 시작합니다. 구현 에이전트들은 구현 내용을 문서로 남겨 완료하고, 메인 에이전트가 그걸 받아 검증시키고요. 이런 식으로 돌아가다가 모든 작업이 끝나고 PR이 만들어질 때, 마지막 ‘크리에이트 PR’ 단계에서 메인 에이전트가 다시 개입해 PR을 만들고 사람이 확인하게 되는 과정입니다.

<클로드 코드 길들이기: 6인의 실제 사례> 전자책(PDF) 출시!

실무자 6인의 클로드 코드 실전 활용법을 엮은 <클로드 코드 길들이기: 6인의 실제 사례> 전자책(PDF) 출시!

스타트업 CTO, 프리랜서 개발자, 1인 빌더, 비개발자 대기업 PM, AX 기획자, BizOps 리드까지.
개발자 3인 + 비개발자 3인이 시행착오 끝에 발견한
클로드 코드 실전 길들이기 사례를 한 권에 담았습니다.

지금 읽고 있는 글의 전체 내용은
<클로드 코드 길들이기: 6인의 실제 사례>에서 확인하실 수 있습니다.

이런 분께 추천합니다

# 클로드 코드 좋다는데,

정작 내 업무엔 어떻게 적용할지 감이 안 잡히는 분

# 개발자, PM, 기획자 등 다양한 직군의

실무 활용 사례를 한번에 보고 싶은 분

# 남들은 어떻게 쓰는지 시행착오까지

솔직한 후기가 필요한 분

# CLAUDE.md, 스킬, 하네스 같은

용어는 아는데 실전 감이 안 잡히는 분

# 코딩 경험 없이도 클로드 코드로

직접 서비스를 만들고 배포까지 해보고 싶은 분

]]>

비개발자가 400페이지 서명 검사를 자동화하며 고민한 것

매달 마감이 되면 내 책상에는 두툼한 점검철 한 권이 올라온다. 어느 공공 사업의 월 유지관리 점검 기록을 묶은 것인데, 수백 페이지짜리 스캔본이다. 시스템마다 앞에 표지가 한 장씩 있고, 그 표지 맨 아래 오른쪽에 점검자와 확인자가 서명과 날인을 한다. 마감을 담당하는 내 일은 여기서 딱 하나다. 모든 표지에 두 사람의 서명이 빠짐없이 들어갔는지 확인하는 것이다.

말로 쓰면 한 줄이지만, 실제로는 400페이지가 넘는 스캔본을 한 장씩 넘기며 표지를 골라내고, 서명란 두 칸을 눈으로 대조하는 일이다. 한장이라도 놓치면 마감이 틀어진다. 매달 30분에서 한 시간씩, 나는 이 단순 반복에 시간을 썼다.

그래서 자동화를 마음먹었을 때, 솔직히 처음 떠오른 건 이거였다. “요즘 AI가 좋다는데, PDF 파일을 던져주고 ‘서명 없는 칸 찾아줘’ 하면 끝나는 거 아닌가?” 결론부터 말하면, 그렇게 하지 않았다. 아니, 그렇게 할 수가 없었고, 몇 번 부딪히고 나서는 일부러 그렇게 하지 않기로 했다.

이 글은 도구를 만든 자랑이 아니다. 코딩이 본업이 아닌 사업관리 담당자가, 반복 업무 하나를 자동화하면서 “어디까지 도구에 맡기고 어디부터는 내가 봐야 하는가”를 정하게 된 기록이다. 완성품보다 그 사이에서 다섯 번 넘어진 이야기와, 두 번의 방향 전환이 이 글의 진짜 내용이다.

<출처: 작가, 클로드로 생성>

“그냥 AI한테 다 시키면 안 돼?”가 안 되는 이유

가장 먼저 막힌 건 파일 그 자체였다. 대상은 400페이지가 넘고 용량은 100메가바이트를 웃도는데, 전체가 스캔 이미지였다. 종이에 서명·날인을 하고 그걸 복합기로 통째로 스캔한 문서라, 안에 ‘글자 데이터’가 없다. 화면으로 보면 글씨가 또렷하지만, 컴퓨터 입장에서는 전부 사진 한 장이다. 그러니 “서명이라는 글자를 검색”하는 방식은 시작부터 성립하지 않았다.

사실 이건 파일을 열자마자 알았어야 했는데, 나는 한참 뒤에야 깨달았다. 처음엔 화면에 글씨가 멀쩡히 보이니 당연히 검색이 될 줄 알고, 서명이라는 단어를 찾게 시켰다가 아무것도 안 잡혀서야 “아, 이게 다 사진이구나” 하고 알아챘다. 비개발자가 자동화를 처음 붙일 때 흔히 하는 착각이 이거라고 생각한다. 화면에 보이는 것과 컴퓨터가 읽을 수 있는 것은 다르다.

보통 이럴 때 쓰는 게 이미지에서 글자를 읽어내는 OCR(광학문자인식) 프로그램인데, 이것도 막혔다. 내가 쓰는 건 회사 보안 환경의 업무용 PC라, 외부 프로그램을 함부로 설치할 수 없다. 인터넷에 파일을 올려서 처리하는 온라인 서비스도 당연히 못 쓴다. 점검철에는 서명과 날인이 들어 있으니 개인정보에 해당하고, 이건 회사 밖으로 나가면 안 되는 자료다. 자동화를 한다고 회사 자료를 외부 도구에 올리는 순간, 편하려다 사고가 나는 셈이다.

정리하면 나는 이런 상자 안에 있었다. 글자 검색 불가, 프로그램 설치 불가, 외부 전송 불가. AI에 통째로 맡기는 그림이 가장 먼저 깨진 지점이 바로 여기다.

그런데 돌아보면, 이 제약이 오히려 도구의 방향을 잡아줬다. 글자를 못 읽으면, 사람이 눈으로 하듯 그림으로 보고 판단하게 만들면 된다. 제약이 없었다면 나는 아마 편한 길로 갔다가 앞서 말한 사고를 냈을 것이다.

그래서 무엇으로, 어떻게 만들었나?

이제 도구 이야기다. 나는 개발자가 아니라서, 이 도구의 설계 대부분은 클로드 코드(Claude Code)와 대화하며 잡았다. 내가 문제와 제약을 설명하면 클로드가 코드를 제안하고, 나는 그게 왜 안 되는지 실제 파일로 확인해 다시 방향을 트는 식이었다. 따라 해보려는 분을 위해, 무엇을 어떻게 썼는지는 최대한 그대로 남긴다.

환경과 핵심 도구

환경은 회사 보안 PC(윈도우)다. 인터넷·설치 없이 돌아가야 하므로, 파이썬(Python)과 오프라인에서 쓸 수 있는 라이브러리(library, 미리 만들어진 기능 묶음)만으로 구성했다. 핵심 도구 세 가지는 이렇게 나눠 썼다.

PyMuPDF:PDF의 각 페이지를 한 장씩 흑백 이미지로 바꾸는 데 썼다. 글자를 못 읽으니, 페이지를 아예 ‘사진’으로 만들어 픽셀(pixel, 이미지를 이루는 작은 점) 단위로 다루기 위해서다.
NumPy:그렇게 만든 이미지를 숫자 표로 바꿔서, 특정 영역이 얼마나 ‘어둡게 칠해져 있는지’를 계산했다. 서명이 있으면 그 자리에 잉크가 묻어 어두워지고, 비어 있으면 밝다. 결국 서명 유무를 ‘잉크 양’이라는 숫자로 바꾼 것이다.
Pillow:판정이 끝난 서명 부분만 잘라내 사람이 볼 수 있는 이미지로 저장하는 데 썼다.

동작 순서와 실행 방식

돌아가는 순서는 이렇다. 먼저 낮은 해상도로 페이지를 빠르게 훑어 표지인지 아닌지 가려낸다. 표지라고 판단되면 그 페이지만 다시 높은 해상도로 읽어 서명란 두 칸의 잉크 양을 잰다. 그리고 애매한 것만 위로 올려 사람이 보게 한다. 마지막으로 결과를 그림이 들어간 HTML 한 장으로 저장하는데, 이건 마감 증빙으로도 그대로 쓴다.

실행 방식도 나 같은 사람이 쓸 수 있어야 했다. 명령어를 칠 줄 몰라도 되도록, 점검철 PDF를 배치 파일 아이콘 위에 끌어다 놓기만하면 분석이 시작되게 만들었다. 매달 쓰는 도구인데 매번 사용법을 떠올려야 한다면, 그건 자동화가 아니라 또 다른 숙제다.

도구 폴더의 전부. 매달 하는 일은 점검철 PDF를 ‘검증실행.bat’ 위에 끌어다 놓는 것뿐이다. <출처: 작가, 클로드로 생성>

<출처: 작가, 클로드로 생성>

다섯 번 넘어진 이야기

‘표지만 자동으로 골라낸다’는 이 한 문장이, 실제로는 가장 오래 걸린 부분이었다. 스캔본은 페이지마다 밝기와 기울기가 제각각이라, 그럴듯한 기준을 세울 때마다 번번이 빗나갔다. 순서대로 적어 본다.

잉크가 많은 페이지를 표지로 보자:실패. 표지나 글자 빽빽한 보고서나 잉크 양이 비슷해서 구분이 안 됐다.
가운데 큰 제목 글자의 진하기로 보자: 실패. 표지의 제목이 오히려 더 진해서, 일반 페이지가 표지로 잘못 잡혔다.
회사 로고 색으로 표지를 찾자: 어떤 표지는 흑백으로 스캔되어 색 정보가 아예 없었다.
표의 세로선 개수로 판단하자:실패. 본문의 체크리스트 표와 겹쳐서 오히려 더 헷갈렸다.
맨 위 굵은 검은 띠로 표지를 확정하자: 절반의 성공, 절반의 실패. 잘 되다가도, 흐리게 스캔된 표지에서는 그 띠를 놓쳤다.

도구를 만든 방법의 실체. 안 되는 걸 설명하고 지킬 원칙을 정하는 것이 내 일이었다. (제작 당시 대화의 요지를 재구성) <출처: 작가, 클로드로 생성>

넘어질 때마다 나는 클로드에게 “이건 왜 안 됐을까”를 설명하고, 실패한 페이지를 예로 들어 다시 물었다. 그러면 클로드가 다른 방법을 제안하고, 나는 또 실제 파일로 돌려 확인했다.

이 과정이 지루하게 느껴질 수도 있는데, 나는 오히려 이때 자동화가 뭔지 감을 잡았다. 자동화는 ‘한 번에 맞히는 마법’이 아니라, 틀린 이유를 하나씩 지워 가는 일에 가깝다. 개발을 못 해도 이건 할 수 있다. 틀린 결과를 눈으로 알아보고, 왜 틀렸는지 말로 설명할 수만 있으면 된다.

한 방에 맞는 ‘단일 정답’은 없었다. 다섯 번을 헤매고 나서야 방향을 바꿨다. 하나의 완벽한 기준을 찾는 대신, 약한 신호 여러 개를 겹쳐서 판단하게 한 것이다. 본문 여백 비율, 상단의 검은 띠, 하단 오른쪽의 서명 블록, 페이지 번호 유무. 각각은 불완전하지만, 함께 보면 표지를 꽤 안정적으로 골라냈다.

사람도 표지를 알아볼 때 한 가지만 보지 않는다는 걸 생각하면, 오히려 자연스러운 방식이었다.

그리고 이때 원칙을 하나 세웠다. “빠뜨리느니, 차라리 좀 더 보여주자.” 마감 검사에서 진짜 위험한 건 없는 걸 잘못 띄우는 것(오탐)이 아니라, 있는 걸 못 보고 지나치는 것(누락)이다. 그래서 애매하면 무조건 사람이 한 번 더 보도록, 판정을 ‘확인 필요’ 쪽으로 기울여 두었다.

두 번의 방향 전환

만들면서 흐름을 바꾼 순간이 두 번 있었다.

첫 번째, 서명란을 기준점으로 삼다

서명란이 비었는지 보려는데, 표지마다 서명 블록의 위치가 미세하게 달라서 자꾸 엉뚱한 자리를 쟀다. 멀쩡히 서명된 칸을 ‘비었다’고 잘못 읽기도 했다. 한참을 헤매다 알아챘다. 서명 칸이 비어 있어도, 그 옆의 ‘(인)’이라는 날인 표시는 인쇄물이라 항상 같은 자리에 찍혀 있다. 이 ‘(인)’을 기준점으로 삼아 점검자 칸과 확인자 칸의 위치를 잡으니, 한쪽이 비어 있어도 정확히 그 자리를 짚어냈다. 작은 발상 하나로 막혔던 게 풀렸다.

두 번째, 도구에도 다 맡기지 않기로 하다

스캔 품질이 들쭉날쭉하다 보니, “서명이 있다 / 없다”를 도구가 100% 단정하게 만드는 건 위험했다. 흐린 서명을 없다고 우기거나, 얼룩을 서명으로 볼 수 있었다.

그래서 나는 도구의 역할을 일부러 줄였다. 도구는 표지를 전부 찾아 서명 부분만 잘라 한 화면에 모아주는 데까지만 하고, 있다·없다의 최종 판단은 사람이 1초 눈으로 하도록 했다. 의심스러운 것만 빨갛게 맨 위로 올려서. 처음의 “AI한테 다 시키자”에서 정확히 반대편으로 온 셈인데, 이게 더 정직하고 실제로 더 빨랐다.

도구와 함께 만들어 둔 사용안내 문서. 다음 달의 나, 그리고 이 도구를 물려받을 동료를 위한 것이다. <출처: 작가>

그래서 얼마나 바뀌었을까

완성한 도구로 그달 점검철(400페이지가 넘는 실제 파일)을 돌려봤다. 표지를 빠짐없이 찾아냈고, 서명 누락은 0건으로 확인됐다. 시간으로 보면, 30분에서 한 시간 걸리던 눈 검사가 1분 남짓의 자동 분석과 한 화면 확인으로 줄었다. 매달 반복되는 일이니, 1년으로 치면 결코 작지 않은 시간이다.

분석이 끝나면 남는 요약. ‘확인필요’ 2건만 사람이 보면 그달 검사는 끝이다. (수치·파일명은 예시로 재구성) <출처: 작가, 클로드로 생성>

무엇보다 결과물이 그림이 들어간 문서 한 장으로 남으니, “확인했다”는 말이 아니라 “이렇게 확인했다”는 증빙이 함께 생긴 것도 실무에서는 컸다. 마감 업무는 결국 누군가에게 “제대로 봤다”는 걸 설명해야 하는 일이기도 한데, 이제는 그 근거가 파일로 남는다. 시간을 줄인 것보다 이쪽이 더 마음에 든다.

솔직히 처음 도구를 돌려 누락 0건이 뜨고, 그게 눈으로 다시 봐도 맞았을 때의 기분은 좀 특별했다. 한 시간짜리 눈싸움이 1분으로 줄어드는 걸 직접 보면, 다음엔 또 어떤 일을 넘길 수 있을까 하는 생각이 자연스럽게 든다.

실제로 이 도구는 내가 최근 넉 달 동안 업무에 붙여 만든 자동화 도구 여러 개 중 하나다. 대단한 개발을 한 게 아니라, 귀찮고 반복적인 일을 하나씩 골라 자동화해 본 결과다. 하나가 되니 그다음이 보였고, 그렇게 늘어났다.

마치며: 도구에 다 맡기지 않는다는 것

이 작업에서 내가 진짜로 배운 건 파이썬 문법이나 라이브러리 이름이 아니었다. 어디까지 도구에 맡기고, 어디부터는 사람이 봐야 하는가를 스스로 정한 경험이다.

처음엔 “AI가 다 해주겠지”로 시작했지만, 실제로 쓸모 있는 도구는 정반대 지점에 있었다. 도구는 사람이 지치는 일, 400페이지를 뒤져 표지를 찾고, 서명란만 잘라 모으는 일을 대신하고, 판단이라는 마지막 1초는 사람에게 남겨 둔다. 나는 이걸 ‘사람 먼저, 도구 나중’이라고 부르는데, 다음에 다른 업무를 자동화할 때도 계속 쓰게 된 기준이다.

나는 개발자가 아니다. 그런데도 현장에서 매달 쓰는 도구 하나를 완성했다. 내가 한 일은 문제를 정확히 정의하고, 안 되는 걸 솔직히 인정하고 방향을 다시 트는 것이었다. 구현은 클로드와 함께했다. 혹시 지금 반복 업무에 지쳐 있는데 “나는 코딩을 못 하니까”라며 미뤄 두고 있다면, 딱 하나만 권하고 싶다. 가장 귀찮은 일 하나를 골라, 어디까지 맡길지부터 정해 보는거다. 거기서부터 생각보다 많은 게 바뀐다.

이 글은 AI의 도움을 받아 작성했습니다.

]]>

키미 K3에 딥시크·큐원까지, 중국 AI는 어디까지 왔나

공개 사흘 만에 신규 구독을 닫은 AI 모델이 있습니다. 중국 문샷AI(Moonshot AI)가 7월 16일 내놓은 키미 K3(Kimi K3)인데요. 회사는 이런 공지를 올렸습니다.

"예상보다 훨씬 큰 사랑을 받았고 우리 GPU가 그 부담을 느끼고 있다."

지난 48시간 새 수요가 한계에 다다르면서 키미의 GPU가 버티기 어려워졌다는 얘기였죠.

<출처: X (@Kimi_Moonshot)>

그런데 이렇게 큰 모델을 내놓은 건 문샷만이 아니었습니다. K3가 나온 지 사흘 뒤, 알리바바가 큐원3.8-Max(Qwen3.8-Max)를 프리뷰로 공개했거든요. 한 주 사이에 중국 회사들이 조 단위 모델을 연달아 내놓기 시작한 거죠. 사람들이 반응하는 이유도 예전과 달라졌어요. 1년 반 전 딥시크(DeepSeek)가 '이렇게 싸다고?'로 충격을 줬다면, 이번엔 성능입니다. 그것도 여러 회사가 동시에 그런 모델을 내놓고 있고요.

실제 사용량도 이미 중국 쪽으로 옮겨가고 있습니다. 여러 모델을 한곳에서 쓰게 해주는 오픈라우터(OpenRouter)에서 미국 모델이 처리하던 토큰 비중이 1년 새 약 70%에서 약 30%로 절반 넘게 줄었거든요. 그만큼 중국 오픈 모델이 늘었죠. 그래서 오늘은 세 가지를 짚어보려 합니다. 이 모델들이 실제로 얼마나 잘하는지, 회사들은 왜 돈 들여 만든 모델을 이렇게 통째로 공개하는지, 그리고 미국은 어떻게 나오고 있는지. 하나씩 보겠습니다.

딥시크 쇼크에서 키미 쇼크까지

문샷AI는 7월 16일 총 2.8조 파라미터짜리 오픈웨이트 모델 키미 K3를 공개해, API와 kimi.com에서 바로 쓸 수 있게 했습니다.

* 오픈웨이트란? 인공지능(AI) 모델이 방대한 데이터를 학습한 결과물인 '가중치(모델의 지식)'를 대중에 공개하는 방식.

그 가중치가 7월 27일에 공개됐어요. 이제 누구나 파일을 내려받아 자기 서버에서 돌릴 수 있죠. 다만 파일이 워낙 커서 웬만한 개인·회사는 직접 돌리기 어렵고, 결국 문샷 서버나 라이선스를 받은 다른 업체를 거쳐 쓰는 게 대부분일 것 같습니다. 출시 초 구독을 잠깐 닫은 것도 이렇게 이용자가 문샷 서버로 몰렸기 때문이고요.

흐름을 짚어보면 이렇습니다.

2025년 1월: 딥시크 R1이 저비용으로 등장, '딥시크 쇼크'
2025년 12월: 딥시크 V3.2
2026년 4월: 딥시크 V4, 값보다 성능을 앞세우기 시작
2026년 7월: 키미 K3(16일), 큐원3.8-Max 프리뷰(19일)

그 사이 성능도 부쩍 좋아졌습니다. VentureBeat는 지난 3년간 오픈소스가 독점 모델에 크게 뒤졌는데, K3가 그 격차를 거의 좁혔다고 평했죠.

이런 소식에 국내도 술렁였습니다. 한국 매체들은 저비용 중심의 '딥시크 쇼크'를 넘어 성능 자체로 미국 모델을 위협하는 '키미 쇼크'가 올 수 있다고 짚었습니다. 국내 업계에선 이런 국면이 현실화할 수 있다는 시각이 나왔고, 즈푸AI·미니맥스 같은 중국 경쟁사 주가가 출렁이거나 삼성전자·SK하이닉스 메모리 수요를 두고 얘기가 나오기도 했습니다.

키미 K3, 얼마나 잘하나

K3가 어떤 모델인지부터 보죠. 파라미터가 2.8조 개나 되는 아주 큰 모델입니다. 하지만 질문이 들어올 때마다 전체를 다 쓰는 게 아니라, 그 질문에 맞는 일부만 골라 씁니다. 사안마다 담당자만 나서는 것과 비슷하죠. 이런 방식(MoE) 덕분에 덩치에 비해 돌리는 비용이 덜 듭니다. 여기에 아주 긴 문서(100만 토큰)도 한 번에 읽고, 이미지까지 바로 이해하죠.

성능은 자체 발표와 독립 검증을 나눠서 봐야 합니다. 문샷이 스스로 낸 숫자와 바깥에서 재본 숫자는 얼마나 믿을 만한지가 다르니까요.

<출처: Moonshot AI>

문샷과 평가기관 발표 기준으로는 이렇습니다.

종합 지능 평가(GDPval-AA v2)에서 1,668점으로 3위. Fable 5(1,760)와 GPT-5.6 Sol(1,748)에는 뒤졌지만 Opus 4.8(1,600)은 앞섰어요.
실무·시각 벤치 8개 중 3개(자동화·스프레드시트·브라우징)에서 1위, 나머지도 대체로 Fable 5에 이어 2위.

<출처: VentureBeat기사>

반면 사람이 직접 비교해 매기는 평가에선 더 좋았어요. 프론트엔드 코딩 대결(Frontend Code Arena)에서 1,679점으로 1위, Fable 5(1,631)·GPT-5.6 Sol(1,618)·GLM-5.2(1,587)를 앞섰죠. 특히 프론트엔드 코딩 1위는 사람이 직접 골라 매긴 순위라 시험 점수보다 실전 감각에 가깝습니다. 다만 두 가지를 같이 봐야 해요.

첫째, 아직 검증이 부족합니다. 나온 지 얼마 안 돼 독립 벤치가 많지 않고, 화려한 숫자 상당수가 문샷 자체 발표거든요. AI 연구자 라이언 그린블랫(Ryan Greenblatt)은 K3를 Opus 4.8 근처에 두면서도 '벤치에 다소 최적화된' 인상이라고 덧붙였습니다. 사이먼 윌리슨(Simon Willison)은 벤치마크가 요즘 가장 중요한 에이전트 도구 호출 능력을 재지 못한다며, 벤치 숫자만으로 모델을 비교하지 말라고 지적했고요.

둘째, 잘하는 것과 효율은 별개입니다. Artificial Analysis는 K3를 프론티어 근처에 두면서도, 같은 일을 시키면 출력 토큰을 더 많이 쓰고 답을 내는 속도도 평균보다 느리며 값도 비싸다고 했죠. 실제로 K3는 전작보다 값이 꽤 올랐습니다. 해커뉴스에선 중국 오픈 모델치고 비싸지만 진짜 프론티어급이면 그럴 만하다는 반응도 나왔고요.

딥시크 V4와 큐원3.8은?

K3와 이 두 모델은 강점이 서로 다릅니다.

딥시크 V4는 4월 24일 공개됐고, 강점은 값과 코딩입니다. 첫날부터 허깅페이스에 MIT 라이선스로 가중치를 올려서, 누구나 조건 없이 바로 내려받아 돌릴 수 있습니다. K3도 뒤늦게(7월 27일) 가중치를 열긴 했는데, 라이선스 조건이 다릅니다. 개인·개발자는 무료로 쓸 수 있어도, 규모가 큰 기업이 상업적으로 쓰려면 별도 계약을 맺어야 하거든요. 조건 없는 V4와는 다른 셈이죠. 다만 V4는 약점도 뚜렷합니다. 모르는 걸 물어도 모른다고 하지 않고 그럴듯하게 지어내는 환각이 심한 편입니다.

<출처: 허깅페이스 - DeepSeek-V4-Pro>

큐원3.8-Max는 또 다릅니다. 아직 프리뷰거든요. 총 2.4조 파라미터에 텍스트·이미지·영상·문서를 함께 다루는 멀티모달이고, 알리바바는 '1조 넘는 첫 멀티모달'이라고 내세우고 있습니다. 다만 현재는 확인할 수 있는 게 거의 없어요. 허깅페이스에 아직 올라오지 않았고, 라이선스도 미정이며, 공개된 벤치마크가 한 건도 없습니다. 알리바바는 'Fable 5 다음가는 성능'이라고 주장하지만, 실제로 측정된 결과는 아닙니다. 따라서 큐원은 현재 다른 두 모델과 성능을 견주기 어렵습니다.

세 모델을 표로 비교하면 이렇습니다.

<출처: 작가 제작>

* K3의 자체 라이선스는 완전히 자유로운 형태는 아닙니다. 개인·개발자는 무료지만, 대기업이 상업적으로 쓰려면 별도 계약이 필요합니다. (V4의 MIT는 조건 없이 공개되어 있고, 큐원은 라이선스가 아직 미정입니다.)

또 키미 K3와 딥시크 V4를 미국 프론티어 모델과 비교하면 이렇습니다.

<출처: 작가 제작>

값 차이가 특히 큽니다. 정가 기준으로 1달러를 쓰면 K3는 출력 토큰을 약 6만 7천 개 뽑는데, V4-Pro는 약 115만 개를 뽑아낼 수 있으며, 이는 약 열일곱 배 차이죠. 물론 이건 중국 오픈 모델끼리 견줬을 때 얘기입니다.

미국 프론티어와 비교하면 K3가 저렴해 보이죠. 출력 100만 토큰 기준으로 K3는 15달러인데, 오픈AI GPT-5.6 Sol은 30달러, 앤트로픽 클로드 Fable 5는 50달러거든요. K3가 Sol의 절반, Fable 5의 3분의 1 값인 셈이죠. 한편 딥시크의 V4는 값이 싼 대신 환각이 문제입니다. 모르는 걸 물으면 열에 아홉은 모른다고 하지 않고 그냥 답을 지어낸다는 겁니다(환각률 94%). 검열 우려도 자주 나오는데, 공개된 검열 연구 대부분은 구형 R1 대상이고 V4 계열은 아직 독립 검증이 안 됐으니 여기선 단정하지 않겠습니다.

다 오픈웨이트인데, 돈은 어떻게 벌까

중국의 기업들은 조 단위를 들여 만든 모델을 왜 이렇게 통째로 공개할까요. 아마 이런 계산이겠죠. 먼저 널리 쓰이게 만들면 개발자가 모이고, 개발자가 모이면 미국 유료 모델을 밀어낼 수 있다는 거예요.

물론 이렇게 오픈웨이트로 공개해도 회사는 돈을 법니다. '무료'인 건 모델 파일을 내려받는 데까지거든요. 이 파일을 돌리려면 비싼 GPU가 잔뜩 있어야 해서, 대부분은 직접 돌리지 않고 회사 API를 돈 내고 씁니다. 파일은 공짜로 풀어도 쓰는 값은 받는 거죠. 알리바바처럼 자기 클라우드에서 돌리게 하고 사용료를 버는 곳도 있어요. 실제로 문샷의 연 반복 매출(ARR)은 3월 1억 달러(약 1,460억 원)에서 6월 3억 달러(약 4,380억 원)로 뛰었습니다.

문샷이 K3를 풀면서 규모가 큰 기업엔 별도로 상업용 라이선스를 받도록 한 것도 같은 이유입니다. 개발자에겐 무료로 열어 생태계를 키우되, 이걸로 크게 돈 버는 곳에서는 대가를 받겠다는 거죠.

세 회사의 셈법은 조금씩 다릅니다.

알리바바는 문샷AI 지분 36%를 쥔 대주주이면서, 동시에 자체 모델 큐원도 만들고 있습니다. 큐원 계열은 오픈라우터 2위 제공사(13.9%, 주간 2.77조 토큰)로 중국 AI 중 제품군이 가장 넓죠. 문샷에 투자한 쪽이면서 큐원으로는 경쟁하는 셈이에요.
문샷AI는 반등 스토리입니다. 2023년 칭화대 출신 양즈린(Yang Zhilin)이 창업했으며, 2025년 1월 딥시크 R1이 뜬 뒤 중국 월간 사용자 3위에서 7위로 미끄러진 기록이 있습니다. 그러다 K3로 다시금 살아났고요. 2026년 5월엔 20억 달러(약 2조 9천억 원)를 조달하며 기업가치 200억 달러(약 29조 2천억 원), 반년 만에 약 다섯 배가 됐고 홍콩 상장을 추진 중입니다. 오픈 전략 역시 돈이 된다는 증거인 셈이죠.
딥시크는 MIT 라이선스와 초저가로 표준을 잡으려는 쪽입니다. V4가 화웨이·캄브리콘 같은 중국산 칩에서도 곧바로 돌아간다는 점은, 엔비디아 의존을 줄이려는 중국의 큰 그림과 맞닿아 있고요.

이건 나라 사이의 경쟁이기도 합니다. 중국은 2026년 3월 반도체·AI에 최대 700억 달러(약 102조 원) 규모의 보조금 계획을 내놨고, 미국은 엔비디아 최상급 칩의 대중 수출을 막는 쪽으로 맞섰습니다. 오픈웨이트를 푸는 게 회사 홍보를 넘어 나라의 정책 수단이 된 거죠.

여기서 논쟁이 하나 생깁니다. 중국 모델의 성능이 사실은 미국 랩 출력을 증류(distillation)해서, 그러니까 베껴서 얻은 것 아니냐는 거죠. 한쪽에선 그건 주요 랩의 이용약관 위반이고 치팅과 다를 바 없다고 봅니다. 반대편에선 증류는 학습 과정의 한 부분일 뿐 전면 복제가 아니라고 반박합니다. 크기 대비 성능은 오히려 중국 모델이 낫다는 목소리도 있고요. 어느 쪽이 맞는지는 아직 결론이 나지 않았습니다.

미국은 어떻게 반응하고 있을까

논쟁의 내용이 어떻든, 실제 사용은 이미 넘어가고 있습니다. 오픈라우터에서 중국 모델은 상위 10개 제공사 토큰의 약 44%를 차지하는데, 그중 딥시크 하나만으로도 16.3%로 가장 많습니다. 이유는 값이에요. 보도에 따르면 중국 오픈 모델은 선두 앤트로픽·오픈AI 모델보다 60~90%까지 저렴하다고 하죠.

오픈라우터 토큰 점유율 추이(미국 70%→30% / 중국 약 22%→44% 교차)
데이터 참고: OpenRouter 랭킹·OfficeChai 기사 <출처: 작가 제작>

미국 기업들도 이미 움직였습니다. AI 비용이 급등하면서 엔지니어들이 더 싼 오픈소스·오픈웨이트 모델을 점점 더 쓰는데, 그중 가장 유능한 걸 중국 회사가 만들거든요. 실제로 도어대시·에어비앤비·지멘스 같은 곳이 중국 AI 모델을 도입했다는 보도도 나왔습니다.

그럼 이걸 어떻게 봐야 할까요. 처음엔 미국에서도 경계하는 목소리가 컸어요. 오픈AI의 딘 볼(Dean Ball)은 오픈웨이트가 지배하는 세상이 결국 'AI 공산주의'로 이어질 수 있다고 했고, 앤트로픽의 다리오 아모데이(Dario Amodei)는 고성능 오픈 모델이 사이버 공격에 악용될 위험을 짚었죠. 백악관의 데이비드 색스(David Sacks)는 반대로, 그런 우려가 규제를 경쟁 장벽으로 쓰려는 것 아니냐고 되받았습니다.

그런데 업계 다수는 오픈을 미는 쪽에 섰습니다. 엔비디아의 젠슨 황(Jensen Huang)은 첫 X 게시물로 오픈 모델 지지 서한을 공유했는데, 마이크로소프트·메타로 시작해 다음 날 구글과 오픈AI까지 합류하며 서명 기업이 50곳 안팎으로 늘었죠. 대형 AI 랩 중에선 앤트로픽 정도가 빠졌습니다.

한편 국내에선 조금 다른 각도의 얘기도 나옵니다. 오픈웨이트라도 실제로 쓰려면 결국 벤더(문샷AI)의 지원이 있어야 하니, 이게 중국 AI의 영향력을 넓히는 통로가 될 수 있다는 거죠.

이렇게 의견은 여럿인데요. 그럼 미국과 중국 AI의 실제 격차는 어느 정도일까요. 다리오 아모데이는 예전에 '중국과 오픈소스는 6~12개월 뒤'라고 봤는데, 지금은 그게 한 세대 차이 정도로 좁혀졌다는 분석이 나옵니다. 다만 같은 분석도 오픈 모델과 폐쇄 모델의 최상위 격차는 여전히 4~7개월이라고 짚고 있죠. 줄긴 했어도 뒤집힌 건 아니라는 건데요. 회의론의 근거도 앞서 본 그대로입니다. 벤치 점수가 실제 실력을 다 보여주진 못하고, 딥시크 V4처럼 환각이 심한 경우도 있으며, 신뢰와 규제 문제도 아직 안 풀렸다는 거죠.

그래서 지금 뭘 고르면 될까

싸게 많이 돌릴 일이면 딥시크 V4를 오픈라우터에서 바로 쓰면 됩니다. 값이 저렴하고 지금도 내려받을 수 있습니다.
최고 성능이 필요하면 K3인데, 7~17배 비싼 값과 가중치는 풀렸지만 워낙 커서 웬만해선 직접 못 돌린다는 점, 수요가 몰릴 땐 응답이 밀릴 수 있다는 점도 감안해야 합니다.
영상·문서까지 다루는 멀티모달이 급하면 큐원인데, 아직 프리뷰라 검증된 게 없다는 걸 알고 시작해야 합니다.

그래서 '중국 AI가 미국을 밀어내는 중이냐'고 묻는다면, 제 답은 아직 '글쎄요'입니다. 비교적 저렴한 값과 접근성이 좋아진 건 사실입니다. 성능 역시 프론티어 모델들의 근처까지 따라왔지만, 실제로 맡겨도 되겠다는 신뢰는 또 다른 문제라고 생각하거든요. 그리고 그 신뢰는 벤치 점수가 아니라, 앞으로 실무에 던져진 시간이 증명할 몫이고요. 이 분야의 상황은 지금도 빠르게 바뀌고 있습니다. 글과 다르게 보시는 관점이나 직접 써보신 경험 혹은 다른 인사이트가 있으시다면 댓글로 편히 남겨주세요. 이 글을 읽는 다른 분들에게도 좋은 참고가 될 거라 생각합니다.

]]>

개인용 AI 에이전트 ‘openhuman’ 직접 써본 후기

요즘 챗봇은 대화를 기억하는 능력은 좋아졌지만, 이메일이나 코드 저장소처럼 내 실제 작업 맥락까지는 알지 못하는 경우가 종종 있습니다. 결국 새 도구를 사용할 때마다 내 상황을 다시 설명하거나 자료를 직접 붙여 넣어야 했습니다.

그렇다면 에이전트가 처음부터 내 맥락을 알고 시작하면 어떻게 될까요? 이 질문을 정면으로 붙든 오픈소스 프로젝트가 ‘openhuman’입니다.

<출처: openhuman 공식 깃허브 문서>

openhuman은 사용자가 연결한 계정의 데이터를 주기적으로 동기화해 개인 메모리를 쌓는 구조입니다. 스스로 ‘개인용 AI 슈퍼 인텔리전스’라고 부르는 이 도구를 며칠간 직접 설치해 써보며, 공식 소개에서 내세우는 ‘몇 주 걸릴 맥락을 몇 분 만에’라는 말이 실제로 맞는지 확인해 보았습니다.

미리 요점만 콕 집어보면?

openhuman은 Gmail·GitHub 등 연결한 데이터를 로컬 메모리(SQLite)에 축적하고 SuperContext로 새 대화에서도 이전 맥락을 자동으로 이어가는 개인용 AI 에이전트입니다.
직접 사용해 보니 프로젝트·이메일 맥락을 이어받는 능력과 다양한 서비스의 쉬운 연동은 인상적이었지만, 비공개 GitHub 접근과 응답 속도, 안정성에는 한계가 있었습니다.
‘설정 없이 똑똑한’ 도구보다 ‘쌓을수록 똑똑해지는’ 도구에 가까웠으며, 베타 버전인 만큼 반복 프로젝트에는 시도해 볼 만하지만 속도와 안정성을 중시한다면 정식 버전을 기다리는 편이 적합합니다.

openhuman이란 무엇인가

openhuman은 내 컴퓨터에서 도는 개인용 AI 에이전트입니다. 겉으로는 여느 챗봇과 비슷한 데스크톱 앱이지만, 설계의 무게 중심이 완전히 다른 곳에 있습니다. 대화를 잘하는 것보다 나를 기억하는 것을 먼저 풀려고 만든 도구입니다.

핵심은 로컬 메모리입니다. openhuman은 내 데이터를 마크다운 트리 형태로 압축 및 정리해 내 컴퓨터의 로컬 데이터베이스(SQLite)에 저장하고, 같은 내용을 옵시디언(Obsidian)과 같은 앱에서 열어 직접 확인할 수도 있습니다. 여기에 Gmail과 GitHub 같은 서비스를 연결해 두면, 일정 주기로 데이터를 자동으로 가져와 이 메모리를 스스로 채웁니다. 정리하면, 내 활동이 곧 에이전트의 기억이 되는 구조입니다.

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

이 발상은 갑자기 나온 것이 아닙니다. openhuman은 안드레이 카파시(Andrej Karpathy)가 말한 ‘LLM 지식베이스’ 개념에서 출발합니다. 안드레이 카파시는 오픈AI 초기 멤버이자 테슬라 AI를 총괄한 딥러닝 연구자로, AI 업계에서 널리 알려진 인물입니다. 모델 자체를 키우는 대신, 모델 옆에 개인의 맥락을 붙여 두어 매번 처음부터 시작하지 않게 하자는 접근입니다.

왜 ‘개인 메모리’가 핵심일까

openhuman을 이해하려면 먼저 에이전트의 오래된 약점을 짚어야 합니다. 여기서는 이 도구가 왜 메모리에 그렇게 공을 들였는지, 그 배경부터 살펴보겠습니다.

1) 매번 처음인 에이전트의 문제

대부분의 AI 도구는 대화가 끝나면 맥락도 함께 사라집니다. 다음에 다시 열면 나에 대해 아무것도 모르는 상태로 돌아갑니다. 이를 흔히 콜드 스타트(cold start), 즉 아무 맥락 없이 차갑게 시작하는 문제라고 부릅니다. 사용자는 매 대화를 프롬프트로 데우는 일을 반복하게 됩니다.

2) openhuman의 해법

openhuman은 이 문제를 뒤집습니다. 대화를 시작할 때 맥락을 채우는 대신, 평소에 맥락을 쌓아 두었다가 대화가 시작되는 순간 자동으로 꺼내 옵니다. 새 대화의 첫 턴에 관련 맥락을 알아서 붙여 주는 기능을 이 도구는 SuperContext라고 부릅니다. 사용자가 “지난번 그 프로젝트”라고만 해도, 그 프로젝트가 무엇인지 이미 알고 있는 상태에서 답이 시작되는 것을 목표로 합니다.

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

3) 연결이 곧 기억이 되는 구조

이 메모리는 손으로 채우는 것만은 아닙니다. openhuman은 100개가 넘는 서비스와 원클릭으로 연동되고, 연결해 둔 데이터를 일정 주기로 동기화해 메모리에 반영합니다. 이메일이나 문서가 쌓일수록 에이전트가 아는 내 맥락도 함께 늘어나는 셈입니다.

직접 설치하고 써봤습니다

지금까지는 openhuman이 어떤 도구인지 살펴봤습니다. 이제부터는 제가 직접 설치해 며칠간 써보면서 느낀 점을 이야기해보겠습니다.

1) 설치와 첫 실행

먼저 openhuman을 내려받습니다. openhuman은 오픈소스로 공개돼 있어, 공식 배포처의 릴리즈 페이지에서 자신의 운영체제에 맞는 설치 파일을 받으면 됩니다.

<출처: 작가, 공식 사이트 캡처>

openhuman은 러스트(Rust)와 타입스크립트로 만든 타우리(Tauri) 기반 데스크톱 앱입니다. 위 화면처럼 macOS는 dmg, 윈도우는 exe나 msi, 리눅스는 AppImage 형태의 설치 파일이 제공됩니다.

<출처: 작가, openhuman 캡처>

첫 실행에서는 몇 가지를 고르는 온보딩을 거칩니다. 먼저 에이전트를 어디에서 돌릴지(런타임)를 정하고, 이어서 실행 방식을 선택합니다.

<출처: 작가, openhuman 캡처>

설치하면서 특별히 막힌 지점은 없었습니다. 굳이 팁을 더하자면, 첫 실행 온보딩에서 ‘추천’이라고 표시된 선택지를 그대로 고르면 별다른 고민 없이 빠르게 설치를 마칠 수 있었습니다. 로그인은 이후 GitHub 연동을 조금 더 편리하게 하려고 GitHub 계정으로 처리했습니다.

2) 서비스 연동과 자동 동기화

첫 실행을 끝내면 어떤 서비스를 연결할지 정하게 됩니다. 연결한 데이터가 곧 에이전트의 기억이 되다 보니, 무엇을 연결하느냐에 따라 쓸모가 꽤 달라졌습니다.

<출처: 작가, openhuman 캡처>

저는 개발자들에게 익숙한 GitHub와 자주 쓰는 이메일인 Gmail을 연동해봤습니다. 방법은 어렵지 않았는데요, 사이드바의 ‘연결’을 누른 뒤 검색창에 Gmail과 GitHub를 각각 입력하면 됩니다.

앞서 GitHub 계정으로 로그인해 두었기 때문에 GitHub 연동은 버튼 한 번으로 끝납니다. Gmail도 크롬을 쓰고 있다면 로그인된 이메일로 자동 연결돼, 버튼 한 번, 10초 남짓이면 연동이 마무리됩니다.

연동할 때 권한을 확인하는 화면이 뜨는데, 이때 필요한 권한만 골라서 선택할 수 있습니다.

<출처: 작가, openhuman 캡처>

3) 메모리와 SuperContext는 실제로 통했을까

가장 궁금했던 부분은 결국 이것이었습니다. 미리 쌓아 둔 맥락을 정말 제때, 제대로 꺼내오는가?

맥락을 이어받는 능력은 꽤나 괜찮았습니다. 한 대화에서 ‘예전에 만든 특정 리포지토리를 수정하려 한다’고만 적어둔 뒤, 완전히 새 대화를 열어 ‘내가 수정하려는 리포지토리를 설명해줘’라고 물었더니, 앞 대화에서 언급했던 그 리포지토리를 곧바로 찾아냈습니다. 새로운 대화인데도 이전 맥락을 스스로 끌어온 것입니다. 메일도 마찬가지로, 받은 메일뿐 아니라 보낸 메일까지 근거로 삼아 내가 누구와 무엇을 주고받았는지 잘 짚어 주었습니다.

물론 모든 경우에 통하지는 않았습니다. GitHub의 비공개 리포지토리 정보는 잘 읽어 오지 못했고, 뒤에서 이야기할 속도와 요청 제한 때문에 맥락을 아예 가져오지 못하는 경우도 있었습니다. 성공과 실패를 가른 건 대체로 ‘데이터에 실제로 접근할 수 있느냐’였습니다. 공개된 활동이나 메일처럼 바로 읽히는 데이터는 잘 잡았지만, 접근이 막히거나 요청이 몰려 제한에 걸리면 맥락을 놓치게 되었습니다.

<출처: 작가, openhuman 채팅 목록 캡처>

4) 기존 도구와 비교하면

평소에는 유료로 쓰는 Claude Code를 주력으로 삼고, 간단한 질문은 무료인 ChatGPT로 처리해 왔습니다. 이 둘과 비교하면 openhuman은 어땠을까요?

맥락을 잡는 감각만 놓고 보면 openhuman이 꽤 좋았습니다. 다만 비교를 위해 다른 도구도 같은 방식으로 시험해 보니 결과가 생각보다 팽팽했습니다.

ChatGPT는 평소에 주제가 바뀌면 새 채팅을 열어 쓰다 보니 이전 맥락을 얼마나 기억하는지 가늠하기 어려웠는데, 이번에 새 채팅을 열고 ‘내가 저번에 너한테 무슨 말 했었지?’라고 단순하게 물어보니 이전 대화를 꽤 잘 기억하고 있었습니다. 한두 달, 길게는 석 달 전 내용까지도 무리 없이 떠올렸습니다. Claude Code는 결이 조금 다른데, 스킬과 훅으로 요구사항이나 작업 흐름을 미리 기록해 두는 방식이라 맥락을 놓쳤다고 느낀 적이 드물었습니다.

그래서 맥락 이해 하나만으로 openhuman이 앞선다고 말하기는 조심스러웠습니다. 오히려 openhuman의 강점은 다른 곳에 있었습니다. 바로 ‘연결’ 탭이었습니다. 다양한 서비스를, 그것도 아주 손쉽게 붙일 수 있다는 점은 터미널이나 설정 파일에 익숙하지 않은 비개발자가 쓰기에 특히 좋아 보였습니다. 기존 도구들이 대화 자체의 똑똑함으로 승부한다면, openhuman은 내 여러 서비스를 한데 모아 맥락으로 삼는다는 점에서 결이 달랐습니다.

위의 내용을 아래에 표로 정리해 보았는데요. 객관적인 지표라기보다 제 나름의 기준으로 매겨 본 주관적인 평가라는 점을 감안해 주세요.

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

실무에서 쓸 때의 활용법과 주의점

써본 경험을 실무 관점으로 정리하면, openhuman은 몇 가지 조건에서 특히 쓸모가 있었습니다.

첫째, 맥락이 길게 이어지는 작업일수록 이점이 컸습니다. 하루짜리 단발적인 질문보다는, 며칠에 걸쳐 이어지는 긴 프로젝트에서 ‘매번 다시 설명하지 않아도 되는’ 효과가 두드러졌습니다.

둘째, 로컬 우선 설계이기 때문에 민감한 데이터를 다룰 때 부담이 상대적으로 덜했습니다.

1) 이렇게 쓰면 더 좋습니다

특히 Slack이나 Discord와 같은 실무에서 쓰는 채팅 도구도 손쉽게 연동된다는 점이 눈에 들어왔습니다.

바빠서 미처 못 읽었거나 잔뜩 쌓인 대화를 openhuman에 요약해 두면 흐름을 한눈에 정리할 수 있고, 그 내용을 openhuman이 기억하기 때문에 이후 어떤 질문을 던져도 앞선 대화와 이어서 답해 줄 수 있습니다. 매번 상황을 다시 설명하지 않아도 된다는 점에서, 채팅으로 협업하는 팀일수록 쓸모가 클 것으로 보입니다.

물론 감수해야 할 점도 있었습니다.

우선 전반적으로 응답이 느렸습니다. 간단한 질문이라도 응답 속도가 다른 AI들에 비해 눈에 띄게 느렸죠. 또 GitHub에서는 비공개 리포지토리 정보를 잘 읽어오지 못했고, 요청이 몰리면 데이터를 가져오지 못하는 경우도 종종 있었습니다. GitHub 관련 작업에서는 접근해도 되는지 매번 승인을 다시 물어봐서 번거롭기도 했습니다. 도입을 고민한다면 이 속도와 안정성, 그리고 반복되는 승인 절차는 미리 감안하는 편이 좋습니다.

<출처: 작가, openhuman 캡처>

정리하면, openhuman은 ‘설정 없이 똑똑하다’기보다 ‘쌓을수록 똑똑해지는’ 도구에 가까웠습니다. 초기에 어느 정도 연결과 사용을 쌓아 두는 투자가 필요했고, 그 투자를 한 뒤에야 콜드 스타트를 줄여 주는 효과가 드러났습니다.

마치며

openhuman을 써보며 확인한 것은, 개인 AI 에이전트의 승부처가 모델의 똑똑함만이 아니라 나에 대한 맥락을 어떻게 다루느냐로 옮겨 가고 있다는 점이었습니다. openhuman은 ‘내 맥락을 아는 개인 비서’라는 방향성만큼은 분명하게 보여 주었고, 여러 서비스를 손쉽게 연결해 두면 새 대화에서도 내 상황을 알아서 짚어 주는 경험은 꽤 매력적이었습니다.

이번엔 하루에 여섯 시간 가까이 붙잡고 써봤지만, 이 도구의 진짜 강점까지는 확인하기 어려웠습니다. 공식 설명과 여러 사용기가 공통으로 꼽는 핵심은, openhuman이 20분마다 내 계정을 자동으로 따라잡아 다음 날 아침이면 밤사이에 쌓인 메일이나 팀원의 커밋까지 이미 알고 있다는 점입니다. 내가 말해 준 것만 기억하는 ChatGPT·Claude와 달리 시간이 지날수록 내 실제 데이터를 스스로 최신 상태로 유지한다는 것인데, 이 효과는 며칠에 걸쳐 써야 드러나는 특성이기 때문에 장시간 써 봐야 체감할 수 있을 것 같습니다.

다만 속도와 안정성, 비공개 데이터 접근과 같은 부분은 아직 다듬어질 여지가 있어, 지금은 가능성을 확인하는 단계에 가깝다고 느꼈습니다. 무엇보다 아직 베타 빌드 버전이기 때문에 미흡한 부분이 있다는 점도 감안할 필요가 있습니다. 뒤집어 말하면, 정식 버전으로 배포된다면 충분히 기대해 볼 만하다는 뜻이기도 합니다. 반복적인 프로젝트에서 맥락을 이어가는 것이 중요하다면 지금도 충분히 시도해 볼 만하고, 속도와 안정성이 더 중요하다면 정식 버전을 기다리는 편이 나아 보입니다.

<참고>

openhuman 공식 GitHub 저장소

함께 보면 좋은 글

]]>

클로드 채널 활용법: 아는 사람만 쓰는 실험 기능

지난 5월 27일과 6월 10일, 요즘IT는 ‘클코나잇 2’ 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 “고수의 경험을 나눠 받을 수 있는 기회”, “찐 실무자의 현장감 넘치는 사례”, “다음에 또 오고 싶은 웨비나” 등의 반응을 보였습니다. 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이 발표는 클코나잇 2 웨비나의 ‘클로드 코드, 채널 기반으로 쓰는 방법’으로 “6월 15일부터 Agent SDK와 헤드리스 모드가 별도 크레딧으로 전환된다”는 앤트로픽 공지를 전제로, 구독 사용량을 따라가는 라이브 세션을 우회 런타임으로 활용하는 방법을 다뤘습니다. 그런데 발표 다음 날인 6월 16일, 앤트로픽은 해당 전환을 철회하고 기존 정책을 유지한다고 안내했습니다.

따라서 지금은 이 글에 담긴 우회 구현을 직접 만들 이유가 없으며, Agent SDK를 그대로 가져다 쓰면 됩니다. 그럼에도 이 기록을 남기는 건, 리서치 프리뷰 기능인 Claude Channel을 실무자가 실제 자동화에 어디까지 활용했는지 보여주는 구현 사례이고, 여기 담긴 에이전트 간 대화 설계나 권한 분리 같은 접근은 이 정책 변경과 무관하게 참고할 만하다고 봤기 때문입니다.

클코나잇을 두 시즌 운영하며, 여기서 소개된 사례가 모델 개발사의 기능 추가로 금세 빛이 바래는 경우를 여러 번 지켜봤습니다. 믿었던 것과 공들여 만든 것이 하루아침에 무너지기도 하는 환경이지만, 그 속에서 현장 실무자가 쌓아온 시도를 기록하는 일에는 그 자체로 가치가 있다고 생각합니다.

발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요, 교보DTS 정보보안센터에서 일하는 이용학입니다. 오늘은 조금 교육적으로 가보려고 합니다. 제가 발표할 주제는 클로드 코드 자동화를 헤드리스 모드에서 채널 기반 세션으로 옮기게 된 이야기이고, 그 과정에서 클로드 코드의 기본적인 개념도 함께 다뤄볼 생각입니다.

아젠다는 총 5개입니다. claude -p 기반 자동화를 왜 채널 기반으로 바꿨는지, MCP와 채널의 기본 개념, 실제로 채널로 돌아가는 작업 한 바퀴, 채널을 이용해 코딩 에이전트를 오케스트레이션하는 방법, 그리고 스크린샷 데모로 진행하겠습니다.

헤드리스 모드(claude -p)는 왜 자동화에 좋았을까?

먼저 클로드 헤드리스 모드, 그러니까 claude -p가 어떤 건지부터 간단하게 짚고 넘어갈게요. 이 명령어는 한마디로 터미널에서 실행하는 명령어입니다. -p 플래그를 통해 뒤에 프롬프트를 입력하면, 사람 승인 없이 프롬프트가 전달돼 터미널의 표준 출력(standard output)으로 결과가 나오고, 그 세션은 종료됩니다.

이게 왜 자동화에 좋았냐면요.

스크립트로 만들 수 있습니다. 터미널에서 입력할 수 있는 명령어는 스크립트, 즉 명령어가 모인 파일로 만들 수 있거든요.
배치로 실행할 수 있습니다. 만든 스크립트를 cron 같은 스케줄러에 등록해 두면 매일 규칙적으로 도는 배치 작업으로 만들 수 있어요.
API처럼 호출할 수 있습니다. claude -p 명령어를 API 호출하듯 쓸 수 있었어요.

다만, 단점도 있습니다. 헤드리스 모드는 기본적으로 스테이트리스(stateless)합니다. 물론 이어가기 옵션이 있긴 하지만, 기본적으로 매 호출이 독립적이고 세션과 맥락이 초기화된다는 단점이 있었습니다.

미국 증시 브리핑을 자동화했더니 생긴 문제

예시를 하나 들자면, 제가 요즘 투자에 관심이 많아서 미국 증시 브리핑 같은 걸 만들었었어요. 미국 증시의 현재 지수와 여러 지표, 핵심 테마와 해석, 그리고 제가 관심 있어 하는 개별 종목까지 클로드 헤드리스 모드 하나로 다 자동화를 해놨었습니다.

그런데 문제가 생겼습니다.

첫 번째 문제는 상당히 비효율적인 토큰 소모량이었습니다. 한 번 돌릴 때마다 맥스 5x 플랜 기준 23% 정도를 사용했어요.

두 번째는 제가 발표 자료를 준비하면서 알게 된 건데, 헤드리스 모드가 별도 크레딧으로 분리된다*는 점입니다. 이전에는 구독 사용량에서 차감이 됐다면, 6월 15일부터는 별도 크레딧으로 전환돼요. 크레딧이 플랜에 따라 지급될 거고요. 첫 번째 단점과도 굉장히 연관되는 게, 한 번 돌릴 때마다 꽤 먹는 작업이 크레딧을 소모하게 된다면 그렇게 많이 돌릴 수가 없겠죠.

*발표자 주: 지난 6월 16일, 앤트로픽에서 “Agent SDK와 헤드리스 모드는 크레딧 사용으로 전환되는 것이 아닌, 기존 정책(클로드 구독 사용량을 따라가는 방식)을 유지한다”라는 메일을 보냈습니다. 해당 정책 변경이 철회됨에 따라, 이 문제는 유효하지 않습니다. 따라서 Claude Agent SDK, 혹은 헤드리스 모드를 사용하면 발표 자료와 같이 복잡한 구현을 진행하지 않아도 됩니다. 추상화가 잘 되어 있어 사용자들은 가져다 쓰기만 하면 되니까요. 다만, “리서치 프리뷰 기능인 클로드 채널을 이렇게도 쓸 수 있구나”하는 관점에서 좋은 활용사례 자료로 볼 수 있다고 생각합니다.

이 문제를 풀어보려다 클로드 채널이라는 것을 발견하게 됩니다. 그 전에 핵심을 말씀드리면, 대화형 세션( CMD나 파워셸에서claude를 입력해 접속한 세션)은 구독 사용량을 따라가지, 크레딧이 별도로 차감되는 형태가 아닙니다. 기본적으로 추가 사용량을 과금하지 않는 선에서요. 이게 이번 구조의 핵심적인 통찰이자 가정입니다.

MCP는 풀(Pull), 채널은 푸시(Push)

본격적으로 채널 활용을 설명하기 전, 알아야 할 기본 개념이 있습니다.

바로 MCP입니다. MCP는 모델 컨텍스트 프로토콜(Model Context Protocol)이라고 하는데, 말 그대로 표준이에요. 프로토콜은 규약, 약속, 규칙을 의미하거든요. 클로드에 MCP 서버를 갖다 물리면, MCP 서버가 도구나 리소스를 가지고 있습니다. 여기서 데이터는 그 MCP 서버만 바라보고 있는 외부 URL이 될 수도 있고, 정적인 데이터가 될 수도 있겠죠. 핵심은 기본적으로 풀(Pull), 당기는 구조라는 겁니다. 클로드가 필요에 따라 MCP 서버를 호출하는 구조예요.

클로드 채널은 MCP를 뒤집은 거예요. MCP는 기본적으로 풀하는 구조라고 했잖아요. 그런데 채널은 클로드 세션에 푸시(Push)를 할 수 있습니다. 클로드가 풀하는 게 아니라, 외부 이벤트나 작업과 같은 것들을 클로드 코드 세션에 푸시를 하는 구조입니다. 클로드로 푸시를 하는 구조입니다.

예시를 들면, 외부에서 이벤트가 발생한 거예요. 채팅을 입력할 수도 있고, CI/CD 과정에서 CI가 실패해 웹훅으로 연동됐다거나, 모니터링 서비스에서 알림이 발생했을 때, 이걸 채널로 보내면 실행 중인 클로드 세션에 알림(notification) 형태로 푸시가 되는 구조예요. 단방향도 지원하고 양방향도 지원합니다. 단방향은 말 그대로 푸시만 하고 클로드가 받아들이기만 하는 거고, 양방향은 클로드가 푸시된 알림을 받았을 때 다시 되돌려줄 수 있는 방법이 있어요. 뒤에서 ‘리플라이 툴(reply tool)’이라고 언급할 겁니다.

최종적으로 비교 아닌 비교를 해보자면 이렇습니다.

MCP는 프로토콜이고, 채널은 그 프로토콜을 구현한 기능
MCP는 풀 구조로 동작하고, 채널은 푸시이지만 양방향도 가능
서로 대립 관계가 아니며, MCP가 조금 더 상위 개념

헤드리스 모드와도 한 번 더 비교해 보면, 클로드 헤드리스 모드는 이어가기 옵션은 있으나 일회성 세션이고, 표면은 에이전트 SDK 쪽으로 병합되면서 별도 크레딧이 부과될 거고요. 채널은 터미널에서 claude를 입력하는 방식으로 동작하는 인터랙티브 클로드 세션이기 때문에 구독풀로 추정되지만, 확정은 아닙니다. 채널이라는 기능 자체가 리서치 프리뷰, 그러니까 실험실 기능 같은 맥락이거든요.

전체 구조: 컨트롤러 → 세션 런처 → MCP 서버 → 클로드 코드 세션

이제 제가 이걸 어떻게 구현했는지, 인터페이스 관점에서 말씀드릴게요. 총 4개의 계층이 있어요. 컨트롤러, 세션 런처, MCP 서버, 그리고 클로드 코드 세션입니다.

처음에는 작업을 만드는 과정이 필요합니다. 이 작업은 정말 뭐든 될 수 있어요. 미국 증시를 분석한다든가, 클로드 코드를 코덱스(Codex)와 대화시킨다든가, 알림 이벤트를 읽게 한다든가 하는 작업이 있겠죠. 이 작업에 채팅 ID를 붙여서 만들고, 세션 런처가 클로드 코드를 PTY 형태로 실행합니다.

PTY는 의사 터미널(pseudo-terminal)인데요. ‘슈도 터미널(의사 터미널)’라고, 가짜 터미널을 실행해서 그 위에 클로드 코드 세션을 띄우는 겁니다. 그리고 그 가짜 터미널 안에 띄워진 세션 안에 브릿지를 통해 알림 형태로 작업을 넣고, 클로드 코드가 그걸 읽고 리플라이 툴로 다시 컨트롤러에게 반환하는 과정이에요.

조금 더 디테일하게 보겠습니다. 컨트롤러의 ‘작업’은 거창한 오케스트레이터 같은 게 아니에요. 그냥 작업입니다. 말 그대로 “오늘 6월 10일 미국 증시 브리핑을 할 거고, 분석 항목은 이런 것들이고, 산출물은 한국어로 핵심 소식 4가지, 그리고 불장·베어장인 이유를 담고, 리플라이 툴을 호출해라”라고 지시하는 거고, 이게 진입점입니다.

세션 런처는 MCP Config를 넘겨서 채널을 실행하게 합니다.

이때 ‘--dangerously-load-development-channels’ 플래그를 쓰는데요. 채널 기능 자체가 리서치 프리뷰 기능이다 보니 외부 MCP 채널을 기본적으로 허용하지 않아요. 지금 허용하는 게 아마 텔레그램이나 슬랙, 디스코드 이런 쪽일 텐데, 저는 자체적으로 개발한 서버를 열고 싶기 때문에 이 플래그를 사용해 주는 거고요. 네임은 세션 네임이라고 보시면 됩니다.

이렇게 띄운 클로드 코드 세션 안에 채팅 ID와 함께 알림을 넘기게 됩니다. 채팅 ID를 왜 넘기냐면, 이것도 앤트로픽이 정의한 하나의 인터페이스이고, 여러 개의 작업을 병렬로 돌릴 때 채팅 ID로 구분하기 위해서라고 합니다. 채팅 ID와 완료 규칙(리플라이 툴을 통해 답을 회수해야 하니까 적은 규칙), 그리고 지시가 들어가게 됩니다.

이런 알림이 클로드 세션에 들어가면, 클로드 세션은 작업을 이어받아 시작합니다. ‘미국 증시 분석할 건데, 시장 데이터 수집하고, 매크로 뉴스 확인.’ 그리고 끝나면 리플라이 툴을 호출합니다. 리플라이 툴도 기본적으로 답변에 채팅 ID를 물고, 텍스트에 결과(result) 형태로 반환하게 됩니다.

컨트롤러는 그걸 보고 채팅 ID를 한 번 더 확인하고, 뭔가 깨지진 않았는지, 파싱이 잘 되는지, 필수 키가 들어있는지 검사하는 과정을 거치게 했어요.

채널로 클로드와 코덱스 대화시키기

저는 클로드와 코덱스를 둘 다 결제하고 있고, 개발할 때 두 개를 같이 많이 사용해요. 둘 다 강점이 달라서 서로의 강점을 살리게 되는데요. 이 둘을 실제로 대화할 수 있는 브릿지로 이어서 자동화할 수 없을까 하는 니즈가 있었습니다. 개발뿐만 아니라, 미국 증시 같은 제 관심사도 AI끼리 토론시키는 경우가 많거든요. 그래서 클로드 채널을 활용하면 되겠다는 생각으로 구현을 시작했습니다.

핵심부터 말씀드리면, 직접 대화를 하는 게 아니에요. 클로드와 코덱스는 컨트롤러 계층을 라우터 삼아, 매개로 대화를 하는 겁니다. 클로드 코드가 메시지를 컨트롤러에 넣어주면 컨트롤러가 그걸 받아 코덱스에 넣어주고, 코덱스가 그걸 다시 컨트롤러에 넣고, 클로드에는 채널을 통해 브릿지 형태로 넣어주는 구조예요. 각자는 컨트롤러만 바라보는 형태고, 컨트롤러가 중앙에 있습니다.

그리고 각각 대화가 언제 끝났는지 알아야 하기 때문에 ‘turn complete’ 신호를 받아야 합니다. 메시지를 넣고, 청크로 답 조각을 받은 다음, 턴 끝 신호를 받으면 종료하는 구조입니다.

핵심은 답변 수신과 완료 신호, 이 두 가지만 거의 보시면 되는데요. 클로드 코드를 가짜 터미널 안에 라이브 세션 형태로 띄우니까, 답변 수신과 완료 신호를 리플라이 툴 호출로 구현했고요. 코덱스는 방법이 두 가지가 있는데, 저처럼 codex exec 명령어를 사용하는 방법도 있고, 코덱스 앱 서버(라이브 서버)를 이용하는 방식도 있습니다. 저는 codex exec을 --json 옵션으로 실해해서 결과를 JSON 라인으로 받았어요. 그래서 답변 수신은 JSON으로 받고, 완료 신호는 턴 컴플리트라는 이벤트로 받습니다.

세 가지 대화 모드와 토큰 폭증을 막는 장치

대화에는 모드가 있습니다.

릴레이(Relay): 그냥 서로 건조하게 대화가 오고 가는 모드입니다.
콜라보레이티브(Collaborative): 클로드가 말한 내용이 ‘클로드’라는 태그로 묶인 텍스트로 상대에게 들어가는 모드입니다.
디베이트(Debate): 콜라보레이티브 뒤에 “이 주장에 반박을 해보세요”라는 신규 프롬프트 인자가 넘어가는 모드입니다.

그리고 이런 브릿지 형태를 구현하다 보면 토큰 폭증이 정말 많아요. 턴이 무한정 이어지면서 서로 무한정 대화를 한다든가, 답변 길이가 어마무시하게 길어진다든가 하는 문제가 있어서, 턴에 대한 제한이나 핸드오프 문자 수 제한, 그리고 인간이 개입할 수 있는 장치를 만드는 게 좋습니다.

또한 보안이나 권한 측면에서도, 둘 다 대화를 하는 만큼 쓰기 권한은 아무에게도 안 주거나 한 에이전트에만 주는 식으로 권장을 드리고 싶어요.

스크린샷으로 보는 작업 한 바퀴

이제 스크린샷으로 실제 동작을 보여드리겠습니다. 시작점은 클로드가 될 수도 있고 코덱스가 될 수도 있는데, 이건 클코나잇 세션이기도 하니까 클로드 코드 기준으로 말씀드릴게요.

처음에 클로드 코드 세션을 켜서, 제가 만든 채널 MCP인 ‘AI 다이얼로그 MCP’를 사용해 특정 피처에 대해 리뷰를 해달라고 하면, 선택지를 줍니다. 첫 번째로는 앞서 말씀드렸던 콜라보레이티브·릴레이·디베이트 모드, 두 번째는 최대 대화 턴 수와 핸드오프 문자 제한, 그리고 쓰기 권한을 묻게끔 했고요. 이걸 다 선택하면 대화가 시작됩니다.

저는 웹으로 연동해서 클로드와 코덱스의 턴을 동시에 볼 수 있는 화면도 만들어놨어요. 이게 필수는 아닙니다. 다만 클로드 내부에서 서브 프로세스로 스폰되는 구조다 보니 가시적이지가 않아서, 가시성을 위해 만든 거라고 보면 됩니다.

실제로 이렇게 서로 대화를 진행합니다. 특정 기능에 대해 코덱스가 리뷰를 해주면, 클로드가 그걸 실제 디스크에 있는 코드와 대조해서 확인해 주고, 추가로 보완도 해줍니다. 서로가 서로를 보완해 주는 구조죠.

이런 대화는 특정 기능에 대해 최소한의 합의가 되었다는 결론으로 도출되고, 대화가 종료되면 최초의 대화를 시작했던 부모 클로드 세션으로 전달됩니다. “레이어 1 계층에는 이런 확실한 버그가 존재하고, 잠재적인 버그는 이게 있고, 설계 취약점은 이런 게 있다”라고 띄워주고, 이 내용을 토대로 리팩토링을 한다든가 새로운 기능을 개발한다든가 하고 있습니다.

마치며: 살아 있는 세션을 자동화 런타임으로

정리하면, 저는 살아 있는 라이브 클로드 세션을 PTY로 띄워서 자동화 런타임으로 사용한 겁니다. 채널 MCP를 이용해 메시지를 밀어 넣고, 리플라이 툴로 답을 회수하는 구조라고 보면 될 것 같아요. 사실 앤트로픽 API를 사용해도 정말 쉽게 구현되는 구조이지만, 그런 래퍼를 사용한 게 아니라 채널이라는 리서치 프리뷰 기능을 사용해서 구현했다고 보시면 됩니다.

개인적으로 말씀드리고 싶은 건, 이런 작업을 할 때는 앤트로픽 공식 문서를 많이 보시는 걸 추천합니다. 앤트로픽 공식 문서나 오픈AI 공식 문서, 더 나아가면 중국 개발자들이 만든 오픈소스도 많거든요. 그런 걸 보면서 아이디어를 얻었던 것 같습니다.

이상 발표를 마치겠습니다. 감사합니다.

▶발표 영상 유튜브에서 보기

]]>

Opus 5부터는 클로드를 다르게 써야 한다?

클로드 오푸스 5(Claude Opus 5)가 나왔습니다. 페이블 5와 소넷 5에 이은 5세대 클로드의 세 번째 모델이에요. 그런데 앤트로픽피셜, 이 모델은 전에 클로드 쓰듯 쓰면 별로라고 합니다. 프롬프트와 하네스를 짜는 방식이 달라져야 한다는 거죠.

일단 오푸스 5가 어떤 모델인지 짚고 5세대에서 무엇이 달라졌는지, 그래서 뭘 바꿔야 하는지 순서로 알아보겠습니다. 말미에는 공식 가이드를 기반으로 지금 당장 점검할 6가지도 정리했습니다.

<출처: 앤트로픽>

페이블 5 보다는 별로지만 매일 쓰는 오푸스 5

오푸스 5의 출시일은 7월 24일입니다. 6월 9일 페이블 5, 6월 30일 소넷 5, 7월 24일 오푸스 5. 이렇게 8주 사이 앤트로픽이 여러 모델들을 발표하며, 5세대 클로드를 완성했습니다.

오푸스 5의 핵심은 “매일 쓰라고 만든” 모델이라는 거예요. 대상은 엔터프라이즈와 일상 업무, 그중에서도 에이전트에게 맡기는 코딩 작업이 중심입니다.

[핵심 특징]

적당한 가격: 입력 $5·출력 $25(100만 토큰 기준). 최상위 페이블 5의 정확히 절반
일상·엔터프라이즈 지향: “매일 쓰라고 만든” 모델. Claude Max의 새 기본
에이전틱 코딩 초점: 시키지 않은 검증까지 알아서 하는 에이전트 작업이 중심

오푸스 5 성능 표 <출처: 작가>

앤트로픽이 함께 배포한 파트너 인용도 ‘일상 업무’를 강조합니다. 커서(Cursor) 공동창업자는 “페이블 5 근처 지능을 오퍼스의 속도와 비용에” 얻었다고 했고, 러버블(Lovable)은 가장 어려운 태스크에서 오퍼스 4.7 대비 22% 개선에 실행 간 편차도 훨씬 적었다고 했어요.

그럼 페이블 5와는 뭐가 다르지?

앤트로픽은 이렇게 말합니다. 페이블 5는 “가장 야심찬 작업”과 며칠 걸리는 자율 프로젝트용, 오푸스 5는 매일 쓰는 모델. 그래서 대놓고 “오푸스 5는 우리의 최상위 일반 접근 모델인 페이블 5보다 전체적으로 더 능력 있지는 않다.”고까지 말합니다.

실제로 페이블 5에 익숙해진 사람들은 좀 아쉽다고 합니다. 한 주 동안 코딩·글쓰기·지식 업무 전반을 테스트해 본 Every 창업자 댄 시퍼(Dan Shipper)는 “사랑하기 어려운 모델”이었다고 말했습니다. 지시에 토를 달았고 일이 끝나기 전에 멈췄다는 겁니다. 대표적인 커뮤니티 해커뉴스도 같습니다. 가장 많은 답글이 붙은 반응은 “좋다, (페이블 5가 있는데) 그러면 이게 존재하는 이유가 뭐냐?”였죠.

기존에 선보인 모델보다 한참 모자란 모델. 대체 왜 존재하는 걸까요?

그 이유는 의외로 간단합니다. 최상위 모델 하나만 골라 쓰는 시대가 끝나버렸기 때문이에요.

5세대 클로드는 무엇이 다른가

지금까지 클로드를 비롯해 AI 모델을 쓰는 방식은 대체로 정해져 있었습니다.

제일 좋은 모델 하나로 모든 일을 처리하기, 벤치마크를 보고 모델 고르기, 프롬프트에 규칙 쌓기. 이 방식이 클로드 5세대에서는 전부 통하지 않을지도 모릅니다.

순서대로 오푸스 5, 페이블 5, 소넷 5 출시 이미지 <출처: 앤트로픽>

1. 비싸진 최상위 모델

구독제에 익숙해진 사용자들은 습관처럼 제일 좋은 모델을 골라두고 모든 일을 시키죠. 그런데 페이블 5는 오푸스 5의 두 배 가격입니다. 간단한 코드 리뷰까지 페이블 5로 돌리는 건 동네 마트 가는데 매번 비행기 표를 끊는 셈이에요. 6월 페이블 5 출시 뒤 토큰이 너무 빨리 닳는다는 불만이 이어지기도 했습니다.

그런 맥락에서 올해 중반부터 최상위 모델 경쟁의 판정 기준은 “누가 최고인가?”에서 “달러당 얼마나 해주는지”로 옮겨가고 있습니다. 앤트로픽만이 아니라 오픈AI, 최근 Kimi로 떠오른 중국기업 문샷(Moonshot)도 가격 메시지를 발표 전면에 내세우고 있어요.

구독 사용량 한도가 앞으로 어떻게 움직일지도 지켜봐야 합니다. 언제 어떻게 “생각해 보니 추론 비용이 너무 비싸서 페이블 5 사용량 줄이겠습니다”할지 모르는 일이니까요.

2. 흔들리는 벤치마크

한편 모델의 성능을 확인할 때, 가장 객관적인 지표로 동작하던 벤치마크가 이제 모델의 성능을 완전히 알려주지 못합니다. 특히, 오푸스 5는 페이블 5와 벤치마크 차이가 작습니다. 심지어 몇 개는 앞서기도 합니다. 다만, 실사용 평은 반대였죠.

개발자 Kun Chen은 “오푸스 5는 실사용에서 페이블 근처도 못 온다. 그런데 벤치마크 다수에서는 오푸스가 페이블을 이긴다”며 이제 유명 벤치마크보다 자기 데이터셋으로 만든 도메인 벤치마크를 훨씬 신뢰한다고 했어요. 즉, 이제 모델 성능은 내 작업으로 직접 돌려봐야 안다는 거죠. 도메인과 상황이 워낙 다양해졌기 때문이고요. 그래서 더욱 다양한 모델 라인업이 필요합니다. 어떤 업무에 무슨 모델이 가장 좋은지 확신하기 어려워졌습니다.

3. 하네스가 가르는 성능

마지막으로, 같은 모델인데 하네스, 그러니까 모델을 감싼 스킬·워크플로 구성에 따라 평가가 뒤집힐 수 있습니다. 앞서 악평을 내린 댄 시퍼의 평가에는 뒷부분이 있습니다. 팀이 기존 스킬과 워크플로를 다 지우고 처음부터 다시 시작하자 “오푸스 5는 극적으로 나아졌고 번뜩이는 순간까지 보여줬다”는 거예요.

검증이나 반복처럼 하네스가 맡던 일이 모델 안으로 들어온 정황도 있습니다. 앤트로픽이 소개한 사례에서는 한 트레이딩 회사 엔지니어가 오푸스 5로 신규 거래소용 시장 데이터 피드를 한 세션에 만들었는데 검증할 라이브 피드가 없자 모델이 자기 코드를 확인할 테스트 하네스를 스스로 만들었다고 해요. 4세대에는 검증 단계를 프롬프트와 하네스에 쌓는 게 정석이었다면 5세대에서는 그게 이중 작업이 됩니다.

정리해 보겠습니다. 모델이 발전하며, 에이전트에게 일을 맡기는 방식이 기본이 되었습니다. 토큰 소모는 이전과 비교할 수 없이 커졌고 맡기는 일의 종류도 훨씬 다양해졌습니다.

최상위 모델 하나로 전부 돌리기에는 지갑에 구멍이 뚫리는 시점이 온 겁니다. 그래서 “매일 쓸 수 있는 값의 상위 모델”이라는 필요가 생겼고, 그 자리를 채우러 나온 게 오푸스 5입니다.

앤트로픽의 새 사용법 안내

이 흐름을 가장 잘 아는 건 앤트로픽 자신입니다. 그래서 오푸스 5와 같은 날 사용법 문서 두 건을 냈어요.

하나는 오푸스 5 전용 프롬프트 가이드로 자주 재튜닝이 필요한 행동 패턴을 직접 목록으로 만든 문서입니다. 다른 하나는 기술 스태프가 쓴 “클로드 5세대 모델용 컨텍스트 엔지니어링 규칙 문서”이에요. 오푸스 5와 페이블 5에 똑같이 적용되는 규칙 6개입니다.

오푸스 5 전용 프롬프트 가이드 <출처: 앤트로픽>

가이드의 대표 규칙은 의외로 소박합니다. 간결하게 쓸 것을 직접 요청하라는 거예요. 오푸스 5의 기본 응답은 이전 모델보다 깁니다. effort는 말의 양이 아니라 생각의 양을 조절하는 장치라 낮춰도 응답이 짧아지지 않고요. 그래서 더할 항목보다 지우라는 항목이 먼저 나옵니다. 오푸스 5는 시키지 않아도 자기 작업을 검증하니 “마지막에 꼭 검증 단계를 넣어” 같은 지시는 과잉 검증과 토큰 낭비만 만든다는 식입니다. 앤트로픽 발표 기준으로 클로드 코드의 시스템 프롬프트를 80% 넘게 지웠는데 측정 가능한 손실이 없었다고 합니다. 공들여 쌓은 지시문 대부분이 5세대에서는 없어도 되는 짐이었다는 얘기죠.

그럼 구체적으로 뭘 바꾸면 될까요?

5세대 맞춤형 클로드 사용 규칙

1. 일의 크기에 맞춰 모델 정리하기

기준은 앤트로픽이 이미 나눠뒀습니다. 며칠 굴려둘 자율 프로젝트면 페이블 5, 오늘 안에 끝낼 매일의 일이면 오푸스 5부터. 그 아래 가벼운 작업은 소넷 5의 몫입니다.

모델을 정했다면 effort 설정 역시 다시 체크해 보세요. 앤트로픽 가이드는 이전 모델에서 가져온 effort 기본값을 자기 평가로 다시 측정하라고 권합니다. 품질이 유지되는 구간에서는 low와 medium을 넉넉히 쓰고 까다로운 코딩·에이전트 작업에만 xhigh로 올리라는 거예요.

2. 프롬프트 재검증

권장하는 건 프롬프트에서 이런 항목들을 빼는 겁니다.

1. 검증 지시: 4세대 시절에는 모델을 못 믿어서 “끝나면 꼭 검증해”를 프롬프트마다 붙였잖아요. 오푸스 5는 시키지 않아도 자기 작업을 검증하기 때문에 이 지시는 검증을 두 번 시키는 비용이 됩니다.

2. 재확인 지시: 마찬가지입니다. “답을 다시 확인해”·”응답 전에 재검증해”는 모델이 이미 하는 행동과 겹쳐서 결과 개선 없이 비용만 더해요.

3. subagent 남발 금지: 오푸스 5는 이전 모델보다 subagent에 쉽게 위임합니다. 그래서 작은 태스크까지 위임하면 비용과 시간이 몇 배로 뜁니다. 어떤 상황에 위임할지 명시하거나 띄울 수 있는 에이전트 수에 상한을 두세요.

3. 더 많이 위임하기

컨텍스트를 주입하는 방식도 전과는 좀 다릅니다. 이제 좀 더 많은 자유를 주는 편이 낫다고 합니다. 그만큼 똑똑해졌기 때문이죠.

컨텍스트 엔지니어링 규칙 문서 <출처: 앤트로픽>

첫째, 규정형 규칙 대신 판단 위임하기: “여러 문단 docstring 절대 쓰지 말라”라고 규정하는 대신 “주변 코드처럼 써라. 주석 밀도·네이밍·관용구를 맞춰라”라고 판단을 넘기는 식입니다. 새 모델은 명시적 제약 없이도 뉘앙스 판단을 더 잘 처리하거든요.

둘째, 점진적 공개: 상세 지침을 미리 몽땅 밀어 넣지 말고 필요할 때 불러오는 Skill로 옮기고 CLAUDE.md는 가볍게 유지하는 식입니다.

셋째, 자동 메모리 활용: 수동으로 관리하던 CLAUDE.md는 이제 복잡성을 모두 대변하지 못합니다.

권장 아키텍처는 네 가지 층입니다. 시스템 프롬프트에는 제품 지침만, CLAUDE.md는 가볍게, 팀의 견해는 Skill로, 깊은 스펙은 코드 위주의 레퍼런스. 결국, 지시문 유지보수에 쓰던 시간을 스펙과 레퍼런스 품질에 쓰라는 거죠.

모델 선택 기준 + 당장 수정할 6가지

지금까지 본 내용을 토대로, 오푸스 5를 더해 어떤 모델을 언제 쓸지와 지금 당장 수정하면 좋을 프롬프트+하네스 사용법을 정리했습니다.

<출처: 작가>

[6가지 수정 제안]

“끝나면 꼭 검증해”· “다시 한번 확인해” 같은 검증·재확인 지시
조건 없는 subagent 위임 피하기(위임 기준과 개수 상한으로 교체)
“절대 ~하지 말라”식 규정형 규칙 피하기(판단 위임형으로 교체)
응답 길이·간결성을 명시해서 지시
thinking은 켠 채 effort를 낮추는 식의 비용 관리 지시
이전 모델에서 가져온 effort 기본값을 내 태스크에 맞춰 재구성

마치며

이러한 변화는 비단 클로드 5세대만의 이야기도 아닙니다. 사실 GPT도, 또 다른 모델들도 마찬가지죠. 모델 골라 쓰기가 산업이 되고 각자 자기 업무에 맞춰 직접 평가하는 흐름은 이미 번지고 있어요.

그러니 갈수록 “어떤 모델이 제일 좋아요?”는 크게 의미 없는 질문이 될 겁니다. 이 일에는 어떤 모델을 어떻게 써야 할지 알아보세요. 그 답은 벤치마크 표보다 내 프로젝트 폴더에 먼저 있을 테고요. 자, 그럼 저는 이제 오푸스 5 돌리러 가볼게요. 뭘 더 잘하는지 찾아봐야겠습니다.

함께 보면 좋은 글

]]>

요즘IT » AI » 피드

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

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

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

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

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

Orca: ‘감독’ 능력 최적화

무엇을 해줄까?

장점과 아쉬운 점

이런 상황에 추천합니다

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

무엇을 해줄까?

장점과 아쉬운 점

이런 상황에 추천합니다

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

1단계: Orca/Paseo vs. 순정

2단계: Orca vs. Paseo

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

마치며

모두가 AI 네이티브한다고 하지만, ‘진짜’는 아직 없다

AI ‘IN’ the business vs. AI ‘ON’ the business

AI 에이전트는 왜 조직의 숨겨진 권력 구조에 부딪히는가

섀도우 IT, 섀도우 AI, 그리고 섀도우 조직

섀도우 AI가 생겨나는 이유, 그리고 그것을 막는 방법

1. 표준화

2. 갖춰야 할 것들

3. 사고 대응

기존의 잣대로는 AI 시대의 가치를 잴 수 없다

별도 조직을 만드는 것도 대부분 실패한다

진짜 분기점

클로드 코드 길들이기: 6인의 실제 사례집 출시

전국 30개 캠퍼스의 정산 이의제기, 두 번의 피벗 끝에 5일 만에 뒤집은 이야기

사례집에서 확인할 수 있는 것들

1인 개발자가 혼자서 9개 프로젝트를 굴리게 된 이야기

사례집에서 확인할 수 있는 것들

클로드 코드 길들이기: 6인의 실제 사례

목차

PART 1. 클로드 코드로 나만의 업무 시스템 구축하기

PART 2. 클로드 코드를 우리 팀, 서비스에 맞게 확장하기

부록

상품 구성

“PDF 사례집만 보고싶어요”

“발표 영상까지 함께 보고싶어요”

“기업(팀)에서 같이 보고싶어요”

[클로드 코드 길들이기: 6인의 실제 사례] 보러 가기

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

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

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

어떻게 쓰나요?

누구에게 좋을까요?

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

무엇을 할 수 있나요?

알아두면 좋은 것

무엇을 얻어가야 하나요?

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

어떻게 표시되나요?

여기서 꼭 알아둘 한계

무엇을 적용하면 될까요?

그록 4.6 + 그록 봇 = 스페이스X > 구글?

GPT-5.6 솔 급이라는 그록 4.6

성능

가격

훈련 방식

사용 환경

그록 봇: 챗봇 아닙니다, 에이전트입니다

동작 구조: 클라우드에 컴퓨터 하나씩 + 직접 로그인해 화면을 조작

사용 환경

그래서 찾아본 후기

그록 4.6 + 그록 봇 출시의 진짜 의미

모델이 아닌 “AI 종합 세트”

어떻게 이런 일이 가능했을까

마치며: 휘청이는 구글과 Top 3의 한 자리

10년 전 자격증 교재가 AI 테스트를 살렸다

‘Why’는 어디서 오는가

미리 요점만 콕 집어보면?

AI가 늑대 소년이 되다

기준을 감으로 만들 수는 없었다

그런데, 이미 누군가 다 적어 놓았더군요

문서에서 설계를, 설계에서 자동화를

마치며: 낡은 문서의 값이 오르는 시대