요즘IT » AI » 피드

Opus 5.5와 GPT-6 Sol 등장: ‘작업당 비용’ 전쟁의 서막

같은 날 공개된 Claude Opus 5.5와 GPT-6 Sol·Luna. AI 모델 경쟁의 무게중심이 성능에서 비용 효율로 이동하고 있습니다. <출처: Anthropic과 OpenAI 이미지를 편집함>

9월 22일, 앤트로픽이 Claude Opus 5.5를 공개했습니다. 약 90분 뒤에는 OpenAI가 GPT-6 Sol과 Luna를 내놨고요. 하루에 새 모델이 셋 나온 겁니다.

그런데 두 발표문을 나란히 놓고 보니, 성능 점수보다 먼저 눈에 들어오는 게 있었습니다. 가격입니다.

이번 모델 전쟁의 핵심은 “누가 가장 똑똑한가?”가 아닙니다. “같은 일을 누가 가장 싸게 끝내는가?”에 가깝습니다.

[핵심 관전 포인트]

Opus 5.5와 GPT-6 Sol·Luna가 약 90분 간격으로 나왔고, 두 회사 모두 가격 인하를 전면에 내세웠습니다.
세 모델은 같은 체급이 아닙니다. 순위보다 각 회사가 상위 모델의 역량을 어느 가격대까지 내렸는지를 봐야 합니다.
두 회사 모두 벤치마크 점수 옆에 ‘작업당 비용’을 함께 내걸기 시작했습니다.
싼 Luna급과 Sol·Opus급을 업무 난이도에 따라 나눠 쓰는 ‘모델 라우팅’이 중요해졌습니다.

새 모델 3종, 핵심만 정리하면

Claude Opus 5.5: Claude 5.5 패밀리의 첫 모델입니다. 앤트로픽은 “대부분의 작업에서 Fable 5.1 수준”이라고 주장합니다. 출력 속도는 30% 빨라졌고요. 아모데이 CEO의 ‘프런티어 속도 조절’ 발언 이후 나온 첫 모델이기도 합니다.
GPT-6 Sol·Luna: Sol은 복잡한 에이전트 작업을, Luna는 목적이 명확한 대량 작업을 겨냥한 모델입니다.
제공 채널: Opus 5.5는 Claude Platform과 AWS·Google Cloud·Azure에서, Sol·Luna는 API와 ChatGPT Work·Codex에서 바로 쓸 수 있습니다.

가격은 100만 토큰 기준입니다.

Opus 5.5와 GPT-6 Sol·Luna의 API 가격 비교. 세 모델 모두 이전 세대보다 저렴해졌습니다. 단위는 100만 토큰입니다. <출처: 오픈AI·앤트로픽 발표문>

앤트로픽은 토큰 가격을 20% 내렸고, 일반 작업 기준으로는 40% 저렴해졌다고 말합니다. OpenAI는 GPT-5.6 대비 50% 인하를 내걸었죠.

다만 OpenAI의 “50%”에는 조건이 있습니다. 사이먼 윌리슨(Simon Willison)에 따르면 비교 기준인 GPT-5.6 가격은 11월에 25% 오를 예정인 프로모션가입니다. GPT-6 가격은 정가라고 OpenAI 대변인이 확인했고요. 착시가 조금 섞였지만 인하인 건 분명합니다.

그렇다면 셋의 위치는 어떨까요?

OpenAI의 최상위 모델은 9월 3일 먼저 나온 GPT-6 Astra(입력 $10, 출력 $50)입니다. Sol은 그 아래에서 복잡한 코딩과 에이전트 워크플로를, Luna는 대량 작업을 맡죠. OpenAI 개발자 계정의 표현으로는 “Build with Sol. Scale with Luna.”입니다.

앤트로픽도 Opus 5.5 위에, Astra와 같은 가격대인 Fable 5.1을 두고 있습니다.

결국 이번 출시는 두 회사가 각자 최상위 모델의 역량을 한 단계 아래 가격대로 끌어내린 사건입니다.

90분 만에 반값이 된 가격표

처음에는 성능 대결처럼 보이지만, 두 발표는 서로를 직접 겨누지 않았습니다.

앤트로픽의 벤치마크 표에는 GPT-6 Astra와 GPT-5.6 Sol이, OpenAI의 차트에는 Opus 5가 올라가 있습니다. 두 발표 자료 모두 상대 회사가 같은 날 내놓은 신제품이 아니라 기존 모델을 비교 대상으로 삼은 거죠. Opus 5.5와 GPT-6 Sol을 같은 조건에서 직접 비교한 자료는 양쪽 어디에도 없습니다.

재미있는 건 가격표를 겹쳐 볼 때입니다. 사이먼 윌리슨이 짚었듯, Opus 5.5의 새 가격은 공개 시점에 GPT-5.6 Sol과 같았습니다. 그런데 90분 뒤 OpenAI가 Sol을 그 절반 가격에 내놓은 겁니다. 컨텍스트도 Opus 5.5가 1M 토큰, Sol이 1.05M 토큰(272K 초과분은 할증)으로 비슷해졌고요.

상위 역량을 아래 가격대로 내리는 출시가 하루에 두 번 나왔습니다. 이건 꽤 큰 변화입니다.

가격표 밖에서도 시작된 경쟁

두 회사의 경쟁은 API 가격에서 끝나지 않습니다. OpenAI의 티보 소티오는 Sol과 Luna 출시와 함께 Plus·Pro·Business 사용자 계정에 ‘저장형 리셋’ 1회를 지급한다고 밝혔습니다. 소진한 Codex·ChatGPT Work 사용 한도를 다시 채워, 원하는 시점에 사용할 수 있는 이용권입니다.

Anthropic도 대상 사용자에게 5시간 또는 주간 사용 한도를 복구해 주는 ‘무료 리셋’을 도입했습니다. 다만 모든 계정에 상시 제공되는 혜택은 아니며, 대상과 만료일은 계정마다 다릅니다. 이제 경쟁은 모델을 얼마나 싸게 제공하느냐를 넘어, 구독자가 얼마나 오래 사용할 수 있게 하느냐로도 번지고 있습니다.

관전 포인트 3가지

1. 성능은 제자리인데 가격은 반값?

이번 발표에서 가장 눈에 띈 건 벤치마크 차트의 모양입니다. 두 회사 모두 성능 점수만 보여주지 않고, 정확도와 작업당 비용을 함께 표시했습니다.

Anthropic은 기본 추론 강도의 Opus 5.5가 Terminal-Bench에서 GPT-6 Astra와 비슷한 성능을 약 40%의 비용으로 냈다고 주장합니다. OpenAI는 AutomationBench에서 GPT-6 Sol이 xhigh 추론 강도에서 33.2%를 기록했고, 작업당 비용은 $0.27이었다고 밝혔고요.

결국 두 회사 모두 “얼마나 높은 점수를 받았는가”뿐만 아니라 “그 점수를 얻는 데 얼마가 들었는가”를 강조하기 시작한 겁니다.

독립 평가에서도 비슷한 흐름이 보입니다. Artificial Analysis에서 GPT-6 Sol의 최고 점수는 48점으로, 전작의 47점보다 1점 오르는 데 그쳤습니다. 반면 작업당 비용은 $1.99에서 $1.06으로 거의 절반이 됐습니다.

성능이 크게 뛰었다기보다, 비슷한 성능을 훨씬 싸게 제공한 셈입니다. 이번 모델의 핵심이 성능보다 가격에 있다는 가장 선명한 숫자죠.

GPT-6 Sol의 지능 지수는 전작보다 1점 높아졌지만, 작업당 비용은 $1.99에서 $1.06으로 약 절반 줄었습니다. 위로 갈수록 성능이 높고, 왼쪽으로 갈수록 비용이 낮습니다. <출처: Artificial Analysis>

물론 회사가 공개한 그래프를 그대로 직접 비교하면 안 됩니다. 모델마다 추론 강도와 실행 환경이 다르고, 일부 작업에는 다른 모델로 넘기는 폴백도 적용됩니다. 같은 이름의 벤치마크도 측정 조건에 따라 점수가 5%포인트 넘게 달라지기도 하고요.

실제로 공개된 최고점 기준으로 GPT-6 Sol은 일부 코딩과 컴퓨터 조작 평가에서 GPT-5.6 Sol보다 낮았습니다. 완전히 동일한 조건의 비교는 아니지만, 이번 출시가 최고점 상승보다 비용 절감에 초점을 맞췄다는 점은 분명해 보입니다.

2. 진짜 눈여겨볼 가격은 ‘캐시’입니다

제가 더 흥미롭게 본 건 가격표의 ‘캐시 입력’ 칸입니다.

프롬프트 캐싱은 모델이 한 번 읽은 문맥을 저장해뒀다가, 다시 쓸 때 훨씬 싼 값에 불러오는 기능입니다. 코딩 에이전트는 매 턴 코드베이스와 대화 기록, 도구 설명을 다시 읽거든요. 에이전트 비용은 이 칸이 좌우합니다.

앤트로픽은 에이전트·코딩 비용의 대부분이 캐시 읽기라며 캐시 가격을 60% 내려 $0.20으로 만들었습니다.

OpenAI는 기존의 90% 캐시 읽기 할인율을 유지하면서 기본 캐시 적중률을 높였습니다. 추론 강도나 사용 도구를 바꿔도 기존 캐시가 유지되도록 했고, 개발자가 캐시할 프롬프트 경계를 직접 지정할 수 있게 했습니다.

여기서 계산이 달라집니다. Opus 5.5와 GPT-6 Sol의 캐시 단가가 $0.20으로 같아졌거든요.

표면 입력가는 $4 대 $2로 두 배 차이입니다. 하지만 캐시 비중이 높은 에이전트 작업에서는 그 격차가 훨씬 줄어들 수 있습니다.

3. 최고 모델 하나만 고르면 될까?

Next.js Agent Evals는 출시 당일 31개 과제를 high effort로, 각자의 하네스(Claude Code/Codex)에서 돌린 결과입니다.

31개 개발 과제에서 Opus 5.5와 GPT-6 Sol은 97%의 성공률을 기록했습니다. Luna는 AGENTS.md를 제공했을 때 성공률이 77%에서 87%로 올랐습니다. <출처: Vercel Next.js Agent Evals>

상위권 성공률은 97%로 같습니다. 그런데 같은 결과를 내는 데 Fable 5.1은 Opus 5.5의 3배 비용이 들었습니다. Luna는 77%로 낮지만 비용이 약 20분의 1이고요. AGENTS.md 문서를 함께 주면 Luna의 성공률은 87%까지 올라갔습니다.

물론 과제 수가 31개라 한 문제 차이가 약 3%포인트입니다. pass@4는 네 번 중 한 번만 성공해도 통과하는 방식이라, 일반적인 단발성 실사용 성공률과도 다릅니다. 출시 당일 결과인 만큼 여기까지는 지켜봐야 합니다.

그래도 방향은 보입니다. 반복적이고 기준이 명확한 작업은 Luna급에 먼저 맡기고, 실패하거나 신뢰도가 낮은 결과만 Sol급으로 올립니다. 장기·고난도 작업만 Opus나 Astra급에 태우는 식이죠.

저렴한 Luna부터 작업을 맡기고, 결과가 부족할 때만 Sol과 Opus 5.5·Astra로 올리는 모델 라우팅 예시입니다. <출처: 작가, gpt로 제작>

사이먼 윌리슨도 출시 당일 기본값을 Codex는 GPT-6 Sol로, Claude Code는 Opus 5.5로 바꿨다고 밝혔습니다. 데모용으로는 Luna를 썼는데, SQL 질의와 HTML·자바스크립트 작성에서 “빠르고 유능하다(fast and competent)”고 평했고요.

결국 비싼 모델 하나로 모든 일을 시키는 시대가 끝나고 있습니다.

실사용자에게는 무엇이 달라질까?

가장 먼저 달라지는 건 습관입니다. 작업마다 모델과 추론 강도를 고르는 게 비용을 가릅니다.

높은 추론 강도가 늘 나은 것도 아닙니다. 사이먼 윌리슨의 테스트에서 Opus 5.5의 max effort는 생각을 너무 오래 하다 SVG 하나 그리는 데 실패했습니다. 회당 $2.56에 약 20분이 들었죠.

제품팀이라면 비용 때문에 미뤄둔 기능 목록을 다시 꺼낼 때입니다. 문서 자동 분류, 고객 문의 요약, 결과물 1차 검수 같은 것들이요. 과제당 $0.011에 도는 모델이 생기면서 “돌려두기엔 비싸다”는 계산이 달라졌습니다.

기업이라면 API 단가 말고도 볼 게 늘었습니다. 캐시 적중률, 세이프가드 폴백 정책, 클라우드 제공처와 데이터 저장 지역, 구독 요금제의 사용 한도 같은 것들이죠. 앤트로픽은 이번에 5시간 한도를 상향하고 리셋 기능을 넣었습니다. 폐지가 아니라 상향이고, API 가격과는 별개입니다.

단가 한 줄보다 운영 조건 전체가 총비용을 정합니다.

더 싸진 AI, 총비용도 줄어들까?

모델이 싸지면 AI 지출도 줄어들까요? 저는 오히려 반대일 가능성이 크다고 봅니다.

자원이 싸지면 전체 사용량이 늘어난다는 ‘제번스 역설’이 에이전트에도 적용될 수 있거든요. 작업당 비용이 내려가면, 지금까지 비용 때문에 자동화하지 못했던 일도 AI에 맡길 수 있게 됩니다.

어디까지나 해석이지만, 양사가 캐시와 경량 모델 가격을 이렇게까지 공격적으로 내린 이유와도 맞아떨어집니다.

마치며

그렇다고 곧바로 승자를 고를 수 있는 건 아닙니다. 지금 공개된 숫자 대부분은 각 회사가 고른 조건에서 나온 결과이고, 실사용 평가는 이제 막 시작됐으니까요.

다만 분명한 건, 이번엔 두 회사 모두 “더 똑똑해졌다”는 말만으로 모델을 설명하지 않았다는 겁니다. 같은 결과를 얼마나 적은 비용으로 만들 수 있는지를 함께 보여줬죠.

다음 승자는 벤치마크 1위 모델이 아닐지도 모릅니다. 비용 때문에 맡기지 못했던 일을 가장 많이 자동화하는 모델, 그게 진짜 승자가 될 수 있을 것 같네요.

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

]]>

200배 빠르다는 Jev AI, 진짜 차별점은 무엇일까

문장을 한 줄도 쓰지 않는 AI 모델이 나왔습니다. 미리 정해 둔 질문에 정해 둔 선택지 중 하나를 고르고, 옆에 확률을 붙여 돌려주는 게 전부입니다. 설명도 이유도 없고요. 대신 빠릅니다. 이름은 Jev, 만든 곳은 TypeSafe라는 회사입니다. 이 회사가 공개한 평가표를 보면 Jev와 앤트로픽 소네트 5는 정확도가 67.8%로 똑같습니다. 그런데 판단 한 건에 Jev는 0.4초, 소네트 5는 78.1초가 걸렸습니다.

공개된 지 일주일 남짓인데 벌써 시끄럽습니다. 한쪽에서는 Vercel의 AI 게이트웨이에서 역대 가장 빨리 채택됐다는 집계가 나왔고, 다른 쪽에서는 예전부터 쓰던 분류 모델과 뭐가 다르냐는 말이 같이 커졌죠. 그런데 Jev가 무엇인지 설명하는 글은 이미 많습니다. 그래서 여기서는 정의보다, 이걸 실제로 붙였을 때 내 파이프라인에서 뭐가 바뀌고 무엇을 신경 써야 하는지를 중심으로 정리했습니다.

이 글의 수치와 인용은 TypeSafe 공식 블로그·공식 문서·자체 평가 사이트, 그리고 외부에서 직접 재본 실측 기록에서 가져왔습니다.

1. 지금 무슨 일이 벌어지고 있나

공개는 9월 15일이었습니다. TypeSafe AI가 2년 동안 회사를 외부에 알리지 않다가, System One Model이라는 새 부류와 그 첫 모델 Jev를 함께 내놨는데요. CEO인 디오고 알메이다(Diogo Almeida)는 오픈AI에서 InstructGPT와 RLHF 연구에 참여했고 그 작업이 챗GPT의 바탕이 됐다고 블로그에 적었습니다.

증폭점은 사흘 뒤였죠. Vercel은 9월 18일 블로그에서 Jev가 자사 AI 게이트웨이 역사상 가장 빨리 채택된 모델이고 출시 24시간째에 유료 팀의 13% 가까이가 쓰고 있었다고 밝혔습니다. 다만 초기 채택이 지속되는지가 다음 시험이라고 덧붙였고요. 9월 20일에는 웨이트리스트가 없어져, 공개 닷새 만에 누구나 바로 쓸 수 있게 됐습니다.

같은 기간 반대편도 똑같이 커졌습니다. 해커뉴스 메인 스레드는 1,900점과 댓글 500개를 넘겼고 창업자는 자신이 CEO임을 밝히며 직접 답을 달았는데요. 그 스레드에서 “이거 그냥 제로샷 분류기 아니냐”는 요약이 나왔습니다. 나흘 앞선 9월 11일 글에서 회사가 표준 벤치마크 표를 내지 않겠다고 선언해 둔 터라, 점수가 좋았으면 공개했을 거라고 의심하는 댓글도 달렸고요.

한쪽 말만 옮겨서는 절반밖에 전하지 못합니다. 그래서 원문을 직접 열었습니다.

2. 문장을 쓰지 않는 모델이 겨냥한 자리

Jev가 무엇인지는 못 하는 일로 잡는 편이 빠릅니다. 왜 그렇게 판단했는지 물어볼 수 없고 답을 길게 풀어 달라고 할 수도 없습니다. 애초에 대화가 성립하지 않고요. 창업자는 해커뉴스에서 문자열과 모든 순차 자료구조가 아예 허용되지 않는다고 못 박았습니다. 할 수 있는 건 미리 정해 둔 질문에 정해 둔 선택지 중 하나를 고르는 일뿐이죠. 옆에 확률을 붙여서요.

소프트웨어는 문장을 읽을 줄 모릅니다. 문장을 읽는 건 사람이죠. 그런데 우리는 지금까지 소프트웨어가 쓸 판단을 굳이 문장으로 받아서 다시 코드로 뜯어 왔습니다.

회사가 낸 개발자용 문서를 보면 질문 유형은 셋뿐입니다. 여럿 중 하나를 고르는 Choice, 척도 위의 값을 매기는 Score, 예 또는 아니오를 묻는 Noul입니다. Noul은 참·거짓 대신 0에서 1 사이 확률값 하나를 돌려주고요. 입력은 텍스트만 받습니다.

왼쪽은 사람에게 설명하는 글이고, 오른쪽은 기계에 거는 계약이다. 돌아오는 답도 다르다. 한쪽은 고른 값 하나뿐이고, 다른 쪽은 선택지마다 확률이 붙어 온다 <출처: 작가>

이런 출력이 쓰이는 데는 소프트웨어 안에 널려 있습니다. 스팸인가, 이 티켓은 어느 팀으로 보낼까, 이 건은 사람이 다시 봐야 하나. 아무도 그 문장을 읽지 않는 판단들이죠. 원래 이런 판단은 파인튜닝한 분류기가 맡던 일입니다. 일본 supa Lab은 라벨 붙은 데이터가 수천 건 있으면 직접 학습이 빠르고 싼 경우가 많지만 라벨이 없고 채점 기준이 자주 바뀌면 Jev가 맞는다고 갈랐습니다.

그럼 “그냥 분류기 아니냐”는 반론은 어떻게 될까요. 해커뉴스에서 한 이용자가 Jev를 제로샷 분류기라고 요약했습니다. 예시를 따로 학습시키지 않고 원시 텍스트를 받아 바로 분류하는데 프런티어급 LLM만큼 정확하다는 뜻인데요. 그 정확도는 어디까지나 회사 주장이라는 단서도 붙였습니다. 창업자는 여기에 두 단어로 답했습니다. “정확히 맞습니다.”라고요. 반면 공식 FAQ는 “Jev는 작지도 않고 LLM도 아닙니다.”라고 적습니다. 모순처럼 보이지만 앞은 하는 일에 대한 답이고 뒤는 만듦새에 대한 답이죠.

그러면 기존 LLM 대신 이걸 쓸 이유는 뭘까요. 흔히 꼽히는 답은 타입이 보장된다는 쪽입니다. 답의 형식과 값의 범위를 미리 못 박아 둔 규격, 그러니까 스키마를 벗어나는 답이 나올 수 없다는 얘기죠. 그런데 실측은 그 답을 뒷받침하지 않았습니다. supa Lab이 4개 과제 208건을 경량 LLM 5종과 함께 돌렸더니 스키마 위반은 다섯 모델 모두 0건이었거든요. JSON 스키마를 강제하니 LLM 쪽도 라벨 밖의 값을 돌려주지 않았습니다.

환각을 안 한다는 건 결국 스키마를 지킨다는 뜻이고, 스키마는 기존 LLM에 강제해도 지켜집니다. 그러니 Jev만 가진 차별점으로 남는 건 하나뿐입니다. 자기가 얼마나 맞힐지를 안다는 것.

3. 빠른 이유는 성능이 아니라 포기한 것에 있다

그 말이 사실인지 따지려면 이 모델이 왜 빠른지부터 봐야 합니다.

LLM은 글자 하나를 고른 다음 그 글자를 보고 다음 글자를 고릅니다. 순서대로 쌓는 구조라 답이 길어질수록 시간도 늘어나죠. Jev는 그 일을 아예 하지 않습니다. 창업자 설명대로 문자열과 모든 순차 자료구조가 금지돼 있어서 출력을 전부 병렬로 계산할 수 있고 그래서 출력 토큰 비용이 없습니다. 가격표에도 입력 100만 토큰당 0.042달러, 출력은 무료라고 적혀 있고요.

그럼 학습은 뭐가 달랐을까요. 지금 우리가 쓰는 모델은 대부분 RLHF(사람 피드백 기반 강화학습)를 거쳤습니다. 사람이 선호하는 응답을 내도록 학습시켜 사전학습 모델을 챗봇으로 바꿔 놓은 방식이죠. 이 회사가 쓴 건 RLCD(보정된 결정을 위한 강화학습)인데, 생성된 텍스트 대신 결정과 보정된 확률을 돌려주도록 학습시킨다고 적혀 있습니다.

새 학습 알고리즘이 왜 필요했냐는 FAQ 질문에 회사는 어느 랩이든 RLHF로는 결국 같은 걸 잘하게 만든다고 답했는데요. 사람 평가자가 선호하는 텍스트를 만드는 일인데, 채팅 제품에는 맞았지만 자동화에는 틀린 목표라는 겁니다. 문서의 경고 박스에는 더 직접적으로 적혀 있습니다. “사람에게 설득력 있는 출력이라고 해서, 사람이 지켜보지 않는 자동화에 쓸 만큼 믿을 만한 건 아닙니다.”

여기서 캘리브레이션(calibration), 우리말로 보정이라는 말이 나옵니다. 회사 문서의 정의는 이렇습니다. 잘 보정된 모델의 예측을 많이 모아 놓고 보면 확률 0.2가 매겨진 결과는 20%쯤 일어나고 0.8이 매겨진 결과는 80%쯤 일어납니다. 일기예보와 같은 이야기죠. 비 올 확률 70%라고 한 날들을 모았을 때 그중 일곱 번쯤 비가 왔다면 그 예보는 잘 보정된 겁니다. 오늘 비가 왔는지만 봐서는 예보가 좋은지 알 수 없고요.

그래서 보정이 잘된 모델은 잘 맞히는 모델과 다릅니다. 0.8이라고 말한 판단들이 실제로 열 번에 여덟 번쯤 맞는 모델이죠. 맞히는 능력과 자기가 얼마나 맞힐지를 아는 능력은 서로 다릅니다. 회사도 같은 말을 직접 적어 뒀습니다. 이 비율은 예측 묶음을 설명하는 것이지 개별 답 하나를 보증하지는 않는다고요.

보정이 잘됐다는 건 자기가 얼마나 맞힐지를 안다는 뜻이다. 확률 0.8이라고 말한 판단들을 모았을 때 실제로 열에 여덟쯤 맞으면 잘 보정된 상태다 <출처: 작가>

정확도만 놓고 보면 Jev는 최상위가 아닙니다. 회사가 직접 공개한 평가에서도 다른 회사 모델 셋보다 낮고요. 속도는 포기한 것에서 나왔습니다.

4. 0.1초와 8초 사이에 있는 것

한 번 물어보고 8초를 기다리는 건 그냥 조금 기다리는 일입니다. 커피를 한 모금 마시면 끝나죠. 회사도 그 점은 인정하고 시작합니다. 공식 블로그 비교표에는 프런티어 모델이 묻고 답을 받기까지 3초에서 329초가 걸린다고 적혀 있고 바로 옆에 “사람과 주고받기에는 충분히 빠르지만, 코드에 통합하면 큰 병목”이라는 문장이 붙어 있습니다.

반복되면 이야기가 달라집니다. 노르웨이의 한 개발자가 정부 공청회에 제출된 의견서 24건을 놓고 같은 질문을 돌려 보니 Jev의 중앙값 지연은 0.32초였는데 비교한 DeepSeek V4.1 Flash는 추론을 끄면 2.7초, 켜면 26초였습니다. 1,000건당 비용은 0.22달러 대 1.31달러, 추론을 켠 쪽은 3.08달러였고요. 오픈소스 프로젝트 notra도 들어온 대화를 어느 모델에 넘길지 고르는 라우터를 Jev로 바꾼 뒤 지연이 1.3초에서 307밀리초로 줄었다고 PR에 적었습니다. 다만 이 노르웨이 개발자는 문서 24건과 얼리액세스 모델로는 첫인상이지 벤치마크가 아니라고 못 박았습니다.

어떤 일에서는 느리면 아예 못 씁니다. 게임에서 대사 하나를 고르는 데 몇 초가 걸리면 그 장면은 성립하지 않습니다. 신호가 바뀐 지 한참 뒤에 출발해도 된다고 알려주는 보조 장치도 마찬가지고요. 회사도 환각한 도구 호출이 에이전트에서는 불편한 정도지만 지연 보증이 걸린 시스템의 일부라면 완전히 치명적이라고 문서에 적었습니다.

그러니까 8초대는 느린 게 아니라 그 자리에 못 들어가는 겁니다. 0.3초대는 빠른 게 아니라 그 자리에 들어갈 수 있게 된 것이고요. 비용도 마찬가지입니다. 한 건에 몇십 원 차이는 아무 일도 아니지만 같은 판단이 요청마다 한 번씩 돌면 예산이 달라집니다.

5. 벤더가 내민 숫자를 어떻게 읽어야 할까

배수부터 보죠. 같은 회사가 채널마다 다른 숫자를 씁니다.

셋이 서로 다른 비교를 하고 있어서 벌어지는 일입니다. 홈페이지의 193.6배·444.6배에는 회사가 스스로 단서를 달아 뒀는데요. 이 숫자는 자사 워크플로 평가에서 나온 것이고, 현실에서 얻는 이득의 위쪽 끝에 가깝다고 본다는 겁니다. 공개된 평가 표의 값으로는 그대로 나오지도 않고요.

배수 대신 볼 만한 건 정확도를 맞춰 놓고 잰 비용과 지연입니다. 회사 자체 평가에서 Jev와 앤트로픽 소네트 5는 평균 정확도가 67.8%로 같은데, 건당 시간은 0.4초 대 78.1초, 건당 비용은 0.0004달러 대 0.1174달러입니다. 여기서 67.8%는 워크플로 네 개의 평균값입니다. 같은 표에서 정확도 1위는 Jev가 아닙니다. 위에 다른 회사 모델이 셋 있는데 sol 74.1%, 앤트로픽 오퍼스 5 73.1%, terra 67.9% 순입니다. 속도와 비용을 보고 고르는 모델이라는 얘기죠.

측정 조건도 봐야 합니다. 회사는 공개한 평가를 어디서 돌렸는지 블로그에 적어 뒀습니다. “우리는 정말로 그만큼 빠릅니다. 다만 우리가 공개한 평가는 대체로 서해안에 있는 우리 랩톱에서 돌린 것이고요.” 한국에서 부르면 여기에 네트워크 왕복이 더해지는데, 얼마가 붙는지는 직접 재보지 않으면 알 수 없습니다. 언어도 걸립니다. 회사 문서는 영어가 주된 학습 언어이고 CJK를 포함한 다른 언어는 처리는 되지만 동등하게 잘되지는 않는다면서, 영어가 아닌 작업을 맡기기 전에 자기 콘텐츠로 테스트하고 라우팅할 때는 확신도를 면밀히 보라고 적었습니다.

그렇다고 한국어로는 못 쓴다고 단정할 근거도 없습니다. 일본어 4개 과제 208건 실측에서는 영어와 차이가 나지 않았고 노르웨이어 24건에서도 읽기 자체는 문제가 없었거든요. 회사 말과 실측이 어긋나는 겁니다. 호스팅 API가 미국 리전뿐이라는 supa Lab 기사도 있어, 국내 보관 요건이 있는 팀이라면 현재 구성으로는 맞추기 어려울 수 있고요.

결과는 과제마다 다릅니다. notra는 라우터를 바꾼 뒤 수동 라벨 153건 기준 정확도가 81.7%에서 90%로 올랐다고 적었고, 반대로 공개 저장소에 올라온 피싱 메일 2,000건 벤치마크에서는 Jev가 클로드 하이쿠 4.5에 졌습니다.

회사도 공개 벤치마크 점수를 내지 않는 대신 사용자가 자기 용례에 맞는 평가를 직접 만들도록 권한다고 FAQ에 적었습니다. 물론 이 정직함 자체가 마케팅이라는 반론도 해커뉴스에 있고요. 그래서 직접 봐야 할 건 셋입니다. 내 대표 태스크로 작은 평가 세트를 만드는 것, 배수 대신 정확도를 맞춰 놓고 비용과 지연을 비교하는 것, 내 리전에서 한국어로 재보는 것. 이 셋은 남의 숫자로 채울 수 없습니다.

6. 바뀌는 건 모델이 아니라 파이프라인 모양이다

지금까지 우리 코드는 모델이 준 답을 전부 같은 무게로 받아 왔습니다. 확신에 차서 고른 답이든 간신히 고른 답이든 코드 입장에서는 똑같은 문자열이었으니까요. LLM에 물어보고 문장을 받아 파싱한 다음 분기하는데 그 분기는 무엇으로 판정했느냐만 봅니다.

확률이 함께 오면 분기가 하나 더 생깁니다. 그 판정을 그대로 써도 되느냐를 묻는 분기죠. 모델을 갈아 끼우는 선에서 끝나지 않고 파이프라인을 다시 그리게 되는 이유입니다.

회사도 이 구조를 문서로 권합니다. 확신도가 높으면 자동 처리, 중간이면 사용자 확인이나 검토 표시, 낮으면 행동하지 말고 사람에게 넘기라고 적혀 있고, 그 경계를 어디에 그을지는 걸린 것이 무엇이냐에 달렸다는 문장이 바로 뒤에 붙어 있습니다. 같은 문서의 의도 분류 편에는 더 구체적으로 적혀 있고요. 메시지를 먼저 분류해 보내면 비싼 자원은 그게 정말 필요한 요청에만 불려 나온다는 겁니다. 쉬운 다수를 싸게 처리하고 어려운 소수에 예산을 몰아 주니, 비용이 한 덩어리에서 계단 몇 개로 나뉘는 셈이죠.

확률이 함께 오면 신뢰도에 따라 경로가 나뉜다. 경계를 어디에 그을지는 걸린 것이 무엇이냐에 달렸으므로 그림의 세 구간은 예시일 뿐이다 <출처: 작가>

다만 이 구조 전체가 확률이 정직하다는 전제 위에 서 있습니다. 확률이 정직하지 않으면 그 분기는 아무 의미가 없고요. 그래서 밖에서 직접 재본 기록을 찾아봤습니다.

먼저 모델이 스스로 붙인 확신도입니다. supa Lab이 4개 과제 208건을 돌린 실측 가운데 라우팅 과제를 보면, 확신도 0.9 이상만 자동 처리로 남겼을 때 정확도는 100%가 되는데 그러고도 건수의 92.5%가 통과했습니다. 반대로 같이 비교한 Gemini 3.5 Flash-Lite와 Qwen3.7 Flash는 틀린 답에도 0.95에서 1.0의 확신도를 스스로 신고했고, ECE는 0.12에서 0.16으로 나왔고요. ECE는 기대 보정 오차를 줄인 말인데, 모델이 말한 확률과 실제 정답률이 평균 얼마나 벌어지는지를 재는 값이고 낮을수록 좋습니다. 자기 신고 확신도는 임계값으로 쓰기 어렵다는 게 필자의 결론이었습니다. 경량 LLM에 같은 분기 구조를 짜면 무너진다는 뜻입니다.

다음은 모델이 내놓은 확률 자체입니다. 앞서 나온 노르웨이 실측에서 예·아니오 판정 192건을 확률 구간별로 묶으면 이렇게 나왔습니다.

Jev가 확실하다고 한 판정은 거의 그대로 맞았다. 애매하다고 한 41건은 실제로도 애매했다. 다만 정답을 사람이 아니라 다른 AI 모델이 매겼으니, 그 모델과 얼마나 같았는지로 읽어야 한다 <출처: lindfors.no>

필자는 확신이 높은 판정을 받아들이고 나머지는 더 느리더라도 나은 모델이나 사람에게 보내는 게 실무에서 Jev를 쓰는 방식이라고 적었습니다. 물론 본인이 문서 24건짜리 첫인상이라고 못 박았으니 벤치마크로 읽어서는 안 됩니다. 뜻밖의 결과도 하나 있습니다. 같은 필자가 질문 문구를 더 정교하게 다듬었더니 보정 오차가 두 배 넘게 나빠졌거든요. 그래서 Jev에 쓸 질문은 책상 건너편 동료에게 묻듯이 쓰고 깨알 같은 단서는 자기 코드에 두라고 권했습니다. 질문 문구 하나로도 보정이 흔들린다는 겁니다.

그리고 새 책임이 하나 생깁니다. 임계값을 누가 정하느냐죠. 0.95로 할지 0.85로 할지는 모델이 정해 주지 않습니다. 회사 문서도 올바른 임계값은 도메인과 용례에 달렸으니 보수적인 값으로 시작해 자기 데이터로 시험하고 조정하라고 적었고요. 같은 문서 안에서도 예시 숫자가 제각각이니 권장값이 아니라는 뜻입니다. 해커뉴스에서는 이걸 다르게 읽었습니다. 한 이용자는 무엇을 허용하고 무엇을 막을지는 여전히 자기가 정해야 하고 어떤 잘못된 동작이 워크플로를 통과하는지도 자기 데이터로 시험해야 하는데, 그렇게 개발자에게 도로 넘어오는 일이 적지 않다고 적었습니다. 회사는 유연함이라 부르고 이용자는 떠넘겨진 일이라 부르지만 둘 다 같은 것을 가리킵니다.

직접 봐야 할 건 여기서도 셋입니다. 임계값은 코드에 박아 두기보다 설정으로 빼 두는 편이 낫지 않을까 싶습니다. 회사 문서 안에서도 숫자가 서로 다르고 회사 자신이 조정하라고 썼으니까요. 확신도와 정확도를 그래프로 같이 놓고 임계값을 시험하라는 게 회사 권고인데, 그러려면 경로별 통과 건수부터 기록해 둬야 합니다. 마지막은 질문 문구를 바꿨을 때 보정을 다시 재보는 일이고요.

7. 그래서 신경 써야 할 것들

임계값을 잘못 잡으면 어떻게 되는지부터 봐야 합니다. 이 모델은 틀려도 티가 나지 않습니다. 형식이 멀쩡하니 에러가 뜨지 않고 잘못된 결정이 로그에 정상으로 남습니다. 승인하면 안 될 건을 승인해도 스키마는 통과하고 모니터링 화면에는 아무 일도 없는 것처럼 보이고요.

회사도 이 부분은 솔직하게 적었습니다. 출시 글의 환각 그래프에 0%를 적은 근거를 두고 “우리 수치는 실증적인 게 아닙니다. 스키마 일치는 보장되니, 그래프에 0%를 자신 있게 넣을 수 있는 거죠.”라고 썼거든요. 창업자도 해커뉴스에서 이 모델들은 확률적이라 확신에 차서 틀리는 것도 가능하다고 인정했습니다. 한 해커뉴스 이용자는 같은 지점을 더 날카롭게 짚었습니다. 해서는 안 될 동작을 승인해도 스키마는 지켜진다고요.

회사 문서에는 더 구체적인 예가 있습니다. 같은 티켓에 같은 질문을 두 형식으로 물었더니 한쪽은 확률 0.22로 애매하다고 하고 다른 쪽은 0.99로 아니라고 단언했다는 예시입니다. 두 응답 모두 형식은 완벽한데 서로 안 맞고 에러도 뜨지 않죠. 회사는 이런 식으로 어긋나는 경우들을 표로 공개해 뒀습니다. 그러니 낮은 확률 구간을 사람이 따로 보는 절차가 없으면 그 판단들도 그대로 실행됩니다.

내 파이프라인에 넣을 수 있는지를 가르는 한계도 있습니다. 한 Choice 질문은 선택지를 255개까지 받는데, 회사는 후보를 추려 주기보다 전체 목록을 그대로 건네고 다 덮지 못할 것 같으면 ‘어느 것도 아님’ 선택지를 더하라고 권합니다. 입력은 텍스트뿐이고 문자열을 만들어 내지도 못하고요. Jev를 브라우저 에이전트에 붙인 한 해커뉴스 이용자는 입력 칸에 넣을 텍스트를 초소형 모델이 대신 썼다고 적었는데, 한 파이프라인 안에 모델이 둘 필요해진다는 뜻이죠. 판단 대상으로 한 번에 넣을 수 있는 본문도 3만 2천 토큰까지라, 긴 문서를 통째로 넣는 설계는 여기서 막힙니다.

가격도 고정된 값으로 보면 안 됩니다. 회사는 가격을 투명하게 공개한다면서도 이게 보조금이 아니라는 걸 증명할 수는 없다고 직접 적었고, 레이트 리밋 역시 수요가 몰리는 동안 예고 없이 바뀔 수 있다고 경고 박스에 적혀 있거든요. 지금 가격과 지금 한도를 전제로 단가 모델을 고정해 두면 흔들릴 수 있습니다.

락인은 생각보다 약해 보입니다. 공개 여덟 시간 만에 한 개발자가 재현 모델을 예고했고, 이틀 뒤에는 또 다른 개발자가 Kev를 내놨고요. Kev를 만든 사람은 API가 TypeSafe의 System One과 같아서 공식 파이썬 SDK를 그대로 로컬 서버로 향하게 할 수 있다고 적었습니다. 그렇다면 Jev를 코드 여기저기서 직접 부르기보다 ‘결정 호출’이라는 인터페이스 하나로 감싸 두는 편이 안전하지 않을까 싶습니다.

다만 갈아탈 수 있다는 것과 지금 갈아타도 같다는 건 다른 이야기입니다. Kev 문서의 대조표를 보면 정확도는 근접했는데 확률의 품질을 재는 지표에서는 아직 Jev가 앞서 있거든요. 제작자도 Jev가 어떤 데이터셋으로 학습됐는지 모르니 통제된 비교는 아니라고 단서를 달았습니다.

마치며

이름에 회사의 생각이 그대로 들어 있습니다. 회사는 FAQ에서 작명 이유를 직접 밝혔는데요. 대니얼 카너먼의 『생각에 관한 생각』에서 빠르고 직관적인 시스템 1과 느리고 숙고하는 시스템 2의 구분을 가져와 모델 부류 이름을 지었다고요. 모델 이름은 윌리엄 스탠리 제번스에게서 따왔습니다. “증기기관 효율이 오른 뒤 석탄 수요가 늘었던 것처럼, 기계 지능도 비슷한 길을 갈 거라고 보거든요. 지능 비용이 한 자릿수 내려갈 때마다 그만큼 더 많은 쓰임새가 열립니다.” 경제학에서 제번스 역설이라고 부르는 관찰입니다.

그 말대로라면 지금 벌어지는 건 모델 교체라기보다, 비싸서 여태 안 물어보던 판단을 물어보기 시작하는 일에 가깝습니다.

그래서 게임체인저냐고 물으면 조건부로만 답할 수 있습니다. 확률을 분기 조건으로 쓸 데가 이미 있는 팀에게는 파이프라인 모양이 달라지는 일입니다. 그런 데가 없다면 아직은 아니고요. Vercel도 첫날 채택 속도는 역대 가장 빨랐지만 그게 이어지는지가 다음 시험이라고 적었습니다. 아키텍처도 논문도 아직 없고, 학습 데이터에 대해 회사가 밝힌 건 전부 직접 만든다는 한 줄뿐입니다. 국내에서도 직접 돌려 본 저장소가 막 올라오기 시작했는데, 결과를 정리해 공개한 글은 아직 눈에 띄지 않습니다.

남는 건 습관입니다. 배수를 보면 어느 채널 숫자이고 무엇과 비교한 건지부터 묻는 습관, 정확도를 맞춰 놓고 비용과 지연을 보는 비교 방식, 모델이 준 확신도를 믿기 전에 내 데이터로 확신도와 정확도를 같이 그려 보는 절차 같은 것들이요.

오늘 당장 해볼 만한 건 하나입니다. 지금 내 서비스에서 큰 모델한테 사실상 예/아니오만 묻고 있는 호출이 몇 개인지 세어 보는 겁니다. 그 숫자를 세어 보면 이 모델이 내게 필요한지 아닌지가 꽤 빨리 드러날 겁니다.

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

]]>

[AX일지]대표님이 곧 시스템인 회사의 AX는 어디서 시작할까

Editor's note

요즘IT가 〈AX일지〉를 연재합니다. AX는 지금 가장 뜨거운 말이지만, 현장에서 실제로 어떤 고민 끝에 무엇을 제안했고 무엇이 되고 무엇이 안 됐는지까지 밝힌 기록은 드뭅니다. 그 자리를 채워 보자는 취지에 위시켓 AIDP가 공감해 함께 기획했습니다. 위시켓 AIDP는 위시켓의 AX 사업부입니다. 진행 중인 프로젝트의 판단을 결론이 나기 전에 공개하고, 결과가 나오면 잘된 것과 안된 것을 함께 싣습니다.

이 시리즈는 한 회사의 손익이 실제로 달라질 때까지의 여정을 기록합니다. 필자는 현장에서 고객의 이야기를 듣고 실제 구축을 돕는 AIDP의 FDE(Forward Deployed Engineer)들입니다. 고객사 특정을 막기 위해 업종 특성과 규모는 일반화했고, 대화는 취지를 살려 재구성했습니다.

[AX일지] ② 대표님이 곧 시스템인 회사의 AX는 어디서 시작할까
: 유튜브로 큰 중고차 회사에 AI보다 먼저 제안한 것

유튜브 채널을 키워 성장한 중고차 판매 회사가 있습니다. 고객들은 영상에서 차를 고르고 설명하는 대표님을 보고, 그 사람을 믿고 매장까지 찾아오죠. 그런데 매장에서 그 고객을 맞이하는 사람은 대표님이 아닙니다. 스무 명 남짓의 딜러들입니다. 믿고 온 사람과 맞이하는 사람이 다른 것이죠.

이 회사에는 고민이 하나 있었습니다. 장사가 안돼서 생긴 고민이 아닙니다. 경쟁 상대가 점점 자본과 시스템을 갖춘 큰 회사들로 바뀌면서, 다음 시대를 준비해야 한다는 위기감이 있었습니다. 요즘 대부분의 대표님들이 그렇듯, 그다음이 AI라는 데에는 의심이 없었습니다. 대표님은 AI 도구를 직접 붙들고 쓰실 만큼 열심이셨고요. 하지만 AI를 어디에 어떻게 써야 좋을지는 모르셨죠.

그런 회사가 저희에게 처음 건넨 말은 “고객용 앱을 만들고 싶다”였습니다. 저희는 바로 앱을 만드는 대신, 이 회사 사람들과 이야기를 나누는 것부터 시작했습니다. 대표님과도, 현장의 직원들과도, 지금 실제로 무엇이 불편한지를 물었습니다. 앱을 만들어 달라는 회사에 앱이 정답이 아닌 경우를 여러 현장에서 봤기 때문입니다. 이 회사가 가려는 곳은 어디이고, AI는 거기에 어떻게 도움이 되는지, 앱은 그 길의 몇 번째 걸음인지를 확인하는 것이 가장 중요했습니다.

고객의 의뢰와 실제 FDE가 하는 일 <출처: 요즘IT, ChatGPT로 제작>

결론부터 말하면 이 회사에 앱은 맞는 처방이었습니다. AI를 회사의 성장 엔진으로 하려면 꼭 필요한 첫 과정이었죠. 다만 중요한 건 이게 첫걸음이라는 것입니다. 이 다음 단계로 해야 할 일들이 있고, 그건 AI 에이전트 구축 같은 거창한 뭔가가 아니었습니다. 이번 글에는 제가 무엇을 보았고 왜 이렇게 판단했는지, 그렇다면 AX가 성숙해지기 위해서는 다음 단계로 무엇을 제안했는지 기록했습니다.

글쓴이 · 홍승호 · 위시켓 AIDP FDE <출처: 요즘IT>

대표님이 곧 시스템인 회사에서

제가 이 회사에 궁금한 것은 무슨 기능을 만들고 싶은지가 아니었습니다. 일이 실제로 어떻게 흐르는지였습니다. 회사의 규칙은 어디에 적혀 있는지, 새로 온 직원은 그것을 어떻게 배우는지, 대표님이 영상에서 한 약속이 매장까지 어느 길로 도착하는지, 고객이 항의하면 누가 무엇을 근거로 판단하는지. 회계 장부까지 다 보여 달라고 했습니다.

며칠 지나 직원들의 답이 서로 비슷하다는 것을 알게 됐습니다. 상당수 질문의 답이 “대표님한테 물어봐요”였거든요.

대표님과 조직 사이에 끊어진 연결고리

일하는 규칙은 대표님이 그때그때 말로 정했고, 문서나 시스템에는 남지 않았습니다. 규칙이 생겼다가 사라지고 또 생기니 실무자들은 매번 다시 물어야 했고, 대표님은 최종 결정자이면서 동시에 회사에서 가장 큰 병목이 되어 있었습니다.

그 병목이 어디서 끊어지는지를 보여 준 일이 하나 있었습니다. 한번은 대표님이 유튜브 촬영에서 특정 차량을 특가로 팔겠다고 발표했습니다. 그런데 딜러가 보는 전산에는 원래 가격이 그대로 남아 있었습니다. 영상을 보지 않고 방문한 고객에게 딜러는 전산에 적힌 가격대로 차를 팔았고, 고객은 나중에 영상을 보고서야 특가가 있었다는 것을 알았습니다.

항의가 들어왔고 회사는 보상으로 수습해야 했습니다. 겉으로 보면 딜러의 실수 같지만, 딜러는 자기가 아는 정보대로 일했을 뿐입니다. 촬영하는 팀과 결정하는 대표님과 판매하는 조직 사이에 정보가 흐르는 길이 없었던 것입니다. 고객 응대나 사후 처리도 마찬가지여서, 현장에서 정리된 일이 고객이 대표님과 직접 통화하면 뒤집히곤 했습니다.

즉 이 회사의 문제는 사람이 아니었습니다. 대표님의 기준도, 좋은 결정도, 현장의 정보도 분명히 존재하는데, 그것이 기록되지 않고 흐르지 않았습니다. 제가 진단했던 다른 현장들과 놀랄 만큼 같은 구조입니다.

앱이 시작인 이유

앱은 완성됐습니다. 고객이 실제 매물을 보고, 상담을 신청하고, 자기 차를 팔겠다고 등록할 수 있게 됐습니다. 의뢰받은 범위로 보면 프로젝트는 여기서 끝나야 합니다. 하지만 저는 AI 시대에 살아남는 기업이 되고자 하는 대표님의 의지를 알고 있었고, 앱이 그 시작이 될 것이라고 확신하고 있었습니다.

목표에서 거꾸로 짚어 본 다섯 단계

저희 회사에는 고객사의 AX 성숙도를 다섯 레벨로 보는 공식 모델이 있습니다. 각 레벨은 단계별로 실행해야 합니다. 레벨을 건너뛰면 그게 반드시 부채가 되어 돌아오거든요.

위시켓 AX 성숙도 모델 v1.0

의뢰는 “앱 개발”로 왔지만, 대표님이 앱을 만들어 달라고 하신 진짜 이유는 AI 시대에 대비된 회사라는 도착지였습니다. 그런 회사란 AI가 시키지 않아도 알아서 일을 처리하는 것을 넘어 AI를 통해 실제 이익을 만들어내는 회사죠. 그러려면 먼저 AI가 정리된 데이터 위에서 실제 업무를 도와야 합니다. AI가 업무를 거들려면 일의 기록이 사람과 부서 사이를 흐르고 있어야 하고, 기록이 흐르려면 기록이 존재부터 해야 합니다. 이 회사의 핵심 업무들은 그 맨 아래 레벨, 암묵 운영에 있었습니다. 기록이 존재하지 않았으니까요.

그래서 이 프로젝트의 설계는 처음부터 이랬습니다. 앱으로 기록이 생기게 한다. 다음에 그 기록을 이어서 차 한 대에 얼마가 남는지 보이게 한다. 이익이 보이면 AI를 어디에 얼마나 쓸지가 정해지고, AI를 적용하며, 에이전트는 그 위에서 굴러갑니다. 앱은 의뢰받은 이 AX 과정의 첫 번째 걸음이었습니다.

앱으로 처음 생긴 기록

출시된 앱은 실제로 그 일을 하기 시작했습니다. 고객이 어디서 와서 무엇을 봤고 어떤 상담을 했는지가 처음으로 남기 시작했습니다. 직원들이 앱에 차량 사진을 찍어 올리면 고객에게는 신뢰 자료가 되고, 회사에는 회사의 표준대로 찍었다는 기록이 남습니다. 관리자가 특가를 등록하면 고객이 보는 화면과 딜러가 보는 전산이 동시에 바뀝니다. 대표님의 결정이 현장으로 바로 이어지는 길이 처음 생긴 것입니다.

직원이 찍어 올린 차량 사진과 관리자가 등록한 특가가 앱 한 곳을 거쳐 딜러 전산과 고객 화면에 동시에 닿습니다. 실제 화면이 아니라 설명을 위해 만든 그림입니다. <출처: 요즘IT, ChatGPT로 제작>

출시 3주가 지나는 동안 마케팅도, 유튜브 채널 소개도 없었습니다. 그런데도 회원 104명이 가입했고 상담 신청 20건이 들어왔습니다. 예전 같으면 어디에도 남지 않았을 스무 번의 상담이, 이번에는 한 건도 빠짐없이 고객 관리 시스템에 기록으로 남았습니다. 딜러 세 명이 차량 사진 스무 장을 앱으로 올린 것도 마찬가지입니다. 큰 숫자는 아닙니다. 그런데 이 회사에 처음으로, 세어 볼 수 있는 기록이 생겼습니다.

만드는 동안 버린 것도 있습니다. 기능을 여럿 넣어 보다가, 대표님과 이야기한 뒤 홈 화면의 많은 부분을 숨기고 핵심만 남겼습니다. 공들여 구현한 기능 하나는 운영 방침이 바뀌면서 통째로 폐기했습니다. 이미 만들었다는 이유로 남겨 두면 그때부터는 자산이 아니라 짐이 되기 때문입니다. 무엇을 만들지만큼, 무엇을 만들지 않고 무엇을 버릴지를 정하는 것도 이 일의 큰 부분입니다.

다음 제안: 차 한 대에 얼마 남는지 보이게 하기

제가 이 회사에 제안하려는 것은 Lv2, 프로세스 정형에 가깝습니다. 일이 흐르는 경로가 시스템에서 보이는 상태입니다. 겉으로 보면 이익이 보이는 화면을 만드는 일이지만, 그 화면에 담기는 것은 이 회사가 어떤 흐름으로 돈을 벌고 있는지입니다. 이 회사는 광고를 하고 영상을 올리지만, 그 광고를 보고 온 고객이 실제로 차를 샀는지, 그 한 건에 돈이 얼마나 들었고 얼마가 남았는지를 아는 사람이 없었습니다. 고객 관리 도구를 도입한 적도 있지만, 현장에서 입력하지 않으니 숫자가 찍히지 않았습니다. 앱 이전에 이 회사에 있던 그 구조가 여기에도 있었던 것입니다.

그래서 유튜브와 앱과 매장으로 흩어져 있는 흐름을 하나로 잇는 것을 제안하려 합니다. 고객이 어디서 들어와서, 어떤 상담을 거쳐, 계약까지 갔는지. 그 한 건에 비용이 얼마나 들었고 실제로 얼마가 남았는지. 회계 장부를 다시 만드는 일이 아닙니다. 한 건에 얼마가 남는지를 보려면 그 한 건이 어디서 들어와 계약과 정산까지 갔는지가 끊기지 않고 이어져야 합니다. 이익을 본다는 것은 결국 일의 흐름을 처음부터 끝까지 잇는다는 뜻입니다.

유튜브에서 앱, 매장 방문, 계약, 정산까지. 한 건의 흐름이 끊기지 않고 이어져야 차 한 대에 얼마가 남는지 보입니다. <출처: 요즘IT, ChatGPT로 제작>

규칙이 대표님 머릿속에만 있다는 문제는 이 다음입니다. 무엇을 규칙으로 삼을지, 어디까지를 예외로 인정할지를 정하려면 근거가 있어야 합니다. 근거 없이 기준부터 세워 사람을 평가하기 시작하면 그 시스템은 오히려 불공정해집니다. 어느 응대가 실제로 계약으로 이어졌는지, 어떤 처리가 결국 회사에 손해였는지를 숫자로 볼 수 있게 된 다음에야 규칙이 대표님의 말에서 회사의 기준으로 넘어갈 수 있습니다. 게다가 중고차 시장은 알선 수수료 정찰제와 하자 발생률 공개 쪽으로 가고 있고, 이 기록은 소급되지 않습니다. 지금 쌓기 시작해야 그때 볼 것이 있습니다.

당분간 새로 만들지 맙시다

제안에 앞서 부탁드리려는 것도 하나 있습니다. 당분간 새로운 것을 만들지 말고, 지금 만든 앱에서 기록이 쌓이게 두자는 것입니다. 급하다고 이것저것 손대기 시작하면 모처럼 쌓이기 시작한 기록이 오염됩니다. 쌓이는 시간을 주고, 그동안 급한 문제만 제가 잡는 것이 다음 레벨을 위한 준비라고 판단했습니다. AI 시대에 대비된 기업이 되는 방법이라고 해 놓고 당분간 만들지 말자고 하니, 이상하게 들리실 수 있습니다. 그런데 지금 하나 더 만드는 것보다 기록이 온전히 쌓이는 편이 이 회사에 남는 것이 많습니다.

AI가 없는 제안서

이 제안서에도 AI라는 말은 한 번도 나오지 않습니다. 앞선 현장들에서 반복해 배운 것이 있습니다. 기록이 흐르지 않는 회사에 AI를 얹으면, 틀린 기록으로 틀린 판단을 더 빨리 내리게 될 뿐입니다.

계산의 문제이기도 합니다. AI는 공짜가 아닙니다. 도구를 구독하고 시스템을 운영하는 데 계속 돈이 듭니다. 고객 한 명을 데려오는 데, 차 한 대를 파는 데 AI를 위해 얼마까지 쓸 수 있는지를 알아야 AI를 도입할 수 있고, 그 답은 한 건에 얼마가 남는지에서 나옵니다. 자기 지갑을 볼 수 없는 회사는 AI 예산을 세울 수 없고, 예산 없는 도입은 유행을 따라가는 지출이 됩니다. 이익이 보이기 시작하면 그때 AI가 할 일이 생깁니다. 들어온 문의를 먼저 분류하고, 응대의 기준을 지키도록 돕고, 어느 채널에 쓴 돈이 실제로 돌아오는지를 사람 대신 지켜보는 일 같은 것들이죠.

한 건에 얼마가 남는지 보여야 AI에 얼마를 쓸지 정할 수 있습니다. 그다음에야 AI가 문의를 분류하고, 응대 기준을 점검하고, 광고비가 돌아오는지 지켜보는 일을 맡습니다. <출처: 요즘IT, ChatGPT로 제작>

이 제안은 눈에 보이는 것을 파는 제안이 아닙니다. 그래서 받아들여지기 쉽지 않은 종류라는 것을 알고 있습니다. 받아들여진 뒤에도 지켜볼 일이 남습니다. 이 회사에는 고객 관리 도구를 도입해 놓고 쓰지 않은 전례가 있고, 이익 계산에 필요한 기록이 어디까지 준비되어 있는지도 아직 확인하지 못했습니다.

앱을 만들어 달라던 회사에 앱이 아닌 것을 제안하게 된 이유가 여기에 있습니다. 돌아보면 저희가 이 회사에 드리고 싶었던 것은 순서였습니다. 무엇을 먼저 하고, 무엇을 아직 하지 않을지의 판단이죠. 이 판단이 유효했는지, 이 프로젝트에 어떤 결정이 이어졌고 어떤 성과가 났는지는 후속 편에서 쓰겠습니다. 저희의 프로젝트는 한 회사의 손익(P&L)이 실제로 달라지는 것을 목표로 하고 있고, 이 회사의 여정도 거기까지 담아보려 합니다.

요즘IT에서 AX 현장의 이야기를 더 가까이서 나눌 자리를 검토하고 있습니다.
어떤 형태가 좋을지 의견을 들려주세요. 1분이면 됩니다.
➡️ AX 관련 행사·모임 수요 조사

]]>

[참가 모집] AI 고수들의 로컬앱/자동화 구경오세요!

여러분에게도 배포한 적은 없지만, 회사에서는 매일 쓰이는 도구가 있나요? 요즘IT는 두 번의 클코나잇을 진행하면서, AI로 직접 뭔가를 만들어 본 사람들의 이야기를 모아봤습니다. 그리고 그 결과물이 대부분 배포를 목적으로 하기보다, 자기 자신과 팀을 위해 만든 도구였다는 점을 알 수 있었죠. 그래서 클코나잇을 ‘빌더나잇’으로 바꾸고, 도구보다는 결과물에 집중해 보기로 했습니다.

그렇게 요즘IT와 노션이 함께 준비한 ‘로컬앱 자랑대회’에 지난 모집 기간 동안 총 51건의 출전작이 접수되었는데요. 내부 검토와 개별 온라인 인터뷰를 거쳐, 빌더나잇: 로컬앱 자랑대회에서 발표할 본선 진출 4팀이 확정되었습니다.

다가오는 10월 6일 화요일 저녁 7시, 위워크 선릉 3호점에서 네 팀이 자신의 업무를 바꾼 로컬앱과 자동화 사례를 직접 소개하는 자리를 가집니다. 이번 데모 데이는 오프라인 현장과 온라인 중계를 동시에 진행하는 행사로, 오늘부터 참가자를 모집합니다! 많은 관심 부탁드려요.

행사 정보

일시: 2026년 10월 6일(화) 저녁 7시
장소: 현장 참가(위워크 선릉 3호점) / 온라인(ZOOM 웨비나)
진행 방식: 오프라인 현장 진행(총 50명)과 온라인은 줌에서 송출합니다.
참가비: 무료
현장 참가 안내: 관람석 좌석이 한정되어 있어, 신청해 주신 분들 중에서 선정한 뒤 개별로 안내해 드립니다. 선정되지 않으신 분께도 온라인 시청 링크를 보내드립니다.
참가 신청:참가 신청 폼에서 작성 후 제출하면 완료!

이런 분들께 추천해요

1. 로컬앱과 사내 자동화에 관심 있는 실무자

배포는 하지 않았지만 매일 쓰고 있는 도구를 만든 경험이 궁금하신 분
우리 팀에도 비슷한 도구를 만들어 보고 싶으신 분

2. 직접 도구를 만들고 운영해 보고 싶은 실무자

코딩 경험 없이도 실제로 쓰이는 도구를 만들 수 있는지 궁금하신 분
다른 팀은 어떤 문제를 어떻게 해결했는지 사례로 확인하고 싶으신 분

3. 반복 업무를 줄이고 팀의 생산성을 높이고 싶은 리더

사내 자동화를 시도했지만 여러 이유로 막혔던 경험이 있으신 분
비개발자 중심으로 팀 자동화를 이끌어 갈 방법을 고민하고 계신 분

발표팀 및 작품 소개

1. 업무기록 think-tank

발표자: 조은혜 / CyberLogitec EUT(Enterprise UX Team)

회의록과 업무 문서를 아무리 쌓아 둬도 지난 결정의 이유를 찾으려면 파일을 일일이 열어봐야 했던 문제에서 출발해, 3년에 걸쳐 회의록과 업무 요청, 참고 자료를 한곳에 자동으로 모으고, Claude가 분류하는 체계를 만들었습니다. 그 결과 히스토리 추적은 5분 이내로, 연말 보고서 작성은 1시간 이내로 줄었습니다.

2. ZAL: 잘먹, 잘먹이

발표자: 정윤희 / (주)다음정보시스템즈 개발본부, UI/UX 기획

종이 영수증을 챙기고 휴가·공휴일을 일일이 대조해 수기로 계산해야 했던 식대 정산 업무를, 디지털 영수증을 올리면 AI OCR이 항목을 추출하고 한도까지 자동 산출하는 도구로 바꿨습니다. 그 결과 식대 정산에 드는 업무 시간이 관리자와 직원 모두 80% 이상 줄었습니다.

3. 도구 4종: OhMyVoice · OhMyBrush · OhDuck · Signa

발표자: 오규성 / LG CNS 공정품질AX팀 총괄

회의록 정리, 화면 강조, 시스템 모니터링, 메일 서명 제작처럼 일상에서 반복되는 자잘한 업무를 각각 해결하는 로컬 앱 4종입니다. 회의록 수기 정리는 월 약 10시간, 화면 강조 속도는 10초대에서 3초로 줄었고, 컴퓨터 과부하 원인 파악도 2초 이내로 빨라졌습니다.

4. 담당자가 없어서 만든 담당자들

발표자: 김고은(UI/UX 디자이너)·이창석(AI 연구원)·함정우(개발자) / 테서 연구개발팀

팀을 위해 만든 도구인데 아무도 쓰지 않았던 경험, 있으신가요? 작은 제품팀에는 누군가는 해야 하지만 담당은 정해지지 않은 일이 쌓입니다. 저희는 그런 일에 하나씩 도구를 만들었지만, 한 번에 자리 잡은 도구는 많지 않았습니다. 같은 도구를 몇 번씩 다시 만들고 나서야, 진짜 어려운 일은 만드는 쪽이 아니라 쓰이게 만드는 쪽이라는 걸 알았습니다. 이번 발표에서는 AI 네이티브 팀에서 무엇을 만들었는지보다는 무엇이 왜 안 쓰였는지, 그리고 그것을 어떻게 팀이 매일 쓰는 것으로 바꿨는지를 말씀드리려 합니다.

※ 발표자 및 작품 소개는 신청서 기준으로 작성되었으며, 추후 발표에서 자세한 내용은 변경될 수 있습니다.

참가 신청

아래 링크에서 참가자 정보를 입력한 뒤 제출합니다.
➡️ [참가 신청하기]
행사 전, Zoom 접속 링크가 등록한 이메일로 발송됩니다. (제출 전 메일 주소를 한번 더 확인해주세요!)
오프라인 참가자로 신청 후 선정되신 분께는 행사 전 개별로 안내드립니다. 선정되지 않으신 분께도 Zoom 접속 링크를 보내드립니다.

참가자 혜택

현장 참가자에게는 노션 굿즈 및 간단한 다과를 제공합니다.
현장 참가자에게는 세션 발표 이후에는 발표자 및 참가자들과 직접 이야기를 나눌 수 있는 네트워킹 시간이 마련되어 있습니다.
오프라인 참가가 어려우신 분들도 온라인 중계로 발표를 들으실 수 있습니다.

마치며

배포한 적 없고 코드도 공개할 수 없지만, 회사에서는 매일 쓰이는 도구들!

이번 빌더나잇에서 그 이야기를 직접 들어 보시고, 우리 팀에도 적용할 만한 아이디어를 얻어가 보세요.

➡️빌더나잇 참가 신청하기

]]>

돈 걱정 않고 AI 쓴다면: 월 30만 원부터 시작하는 AI 구독 가이드

월요일 오전부터 Claude Code가 “주간 한도에 도달했다”는 안내를 띄웁니다. 지난주에 리팩터링을 몰아서 시킨 대가죠. 따로 띄워둔 ChatGPT는 딥리서치를 몇 번 돌렸다고 리셋까지 기다리라고 합니다. 구독료 20달러가 아까워 무료 티어를 오가던 시절과는 다른 종류의 답답함입니다. 토큰 한도에 막혀 기다리다 보면 정말로 화가 훅훅 치솟고는 합니다.

앞서 무료 AI 편에서는 그럭저럭 필요한 일을 무료로 해주는 AI를 봤고, 가성비 AI 편에서는 월 20달러 구독료로 최대 효율을 뽑는 법을 다뤘는데요. 그래서 이번에는 반대편 끝으로 가 보려고 합니다. 돈이 문제가 아니라면 무엇을 구독하는 게 정답일까요? 어디까지 ‘최고 성능’이고 어디부터는 ‘낭비’일까요?

결론부터 보겠습니다. 기본값은 두 개, ChatGPT Pro와 Claude Max 20x 구독부터 시작합니다. Fable과 Astra라는 슈퍼 모델이 왕이니까요. 반면 나머지는 필요가 생겼을 때, 즉, 이 두 가지로 할 수 없는 일이 실제로 생겼을 때 하나씩 더하는 쪽으로 가보겠습니다.

돈 걱정 없이 AI 구독 맵

메인 듀오: 200달러의 행복

돈 걱정이 없어도 첫 선택은 결국 OpenAI 대 Anthropic, GPT 대 Claude입니다.

ChatGPT Pro

ChatGPT

OpenAI의 최상위 개인 요금제입니다. 그리고 지금은 돈이 있어도 새로 살 수 없는 요금제이기도 합니다.

무엇을 해주나

공식 문서 기준으로 Pro 전용 모델, Codex, 딥리서치, 이미지 생성, 메모리, 파일 업로드가 포함됩니다. 눈여겨볼 건 100달러짜리 Pro 티어와 기능 차이가 없다는 점입니다.

두 요금제 차이는 딱 하나, 사용량입니다. 100달러는 Plus 대비 5배, 200달러는 20배입니다. 그러니까 이 200달러(한화 약 27만 원, 부가세 별도)는 한도를 늘리는 데 쓰는 돈입니다.

vs. Claude Code

핵심 기능인 Codex 기준으로 보면, Claude Code에 비해 좀 더 알아서 일을 처리하는 경향이 있습니다. 알잘딱깔센에 가깝다고 해야 할까요?

브라우저 유즈와 컴퓨터 유즈, 그러니까 컴퓨터를 다루는 기술도 부드러운 편이고요. 무엇보다 체감상 토큰 한도가 훨씬 천천히 찹니다. 때때로 이뤄지는 토큰 한도 리셋과 강력한 이미지 생성 모델인 GPT image를 쓸 수 있다는 점도 매력적이죠.

언제 쓰나

장시간 추론과 딥리서치, Codex를 일상적으로 돌리느라 Plus 한도로는 매일 막힐 때부터입니다. 자료 조사가 업무의 절반인 기획자나 리서처, 문서 작업을 하루 종일 시키는 사무직이라면 이쪽 상한이 먼저 필요합니다.

한계·주의

무제한이 아닙니다. 모델별로 별도 허용량이 있고 한도에 닿으면 리셋까지 그 모델을 못 씁니다. 최상위 모델 Astra는 생각보다 토큰을 더 빨리 쓰죠. 공식 문서는 “허용량을 늘리거나 우회하는 설정은 없다”고 말합니다.
2026년 9월 10일부터 신규 가입·업그레이드 일시 중단 상태입니다. 기존 구독자는 유지되지만 한 번 해지하면 중단이 풀릴 때까지 재구매할 수 없습니다. Pro 100달러에서 200달러로 올라가는 경로도 막혀 있습니다. Astra 발표와 함께 사용자가 감당할 수 없이 늘어나 급히 내린 조치라고 합니다. 일시적인 거니 곧 풀릴 거라 믿습니다.
모델별 세부 한도 수치는 알 수 없습니다. 커뮤니티 집계가 돌아다니지만, 다 비공식 수치입니다.

Claude Max 20x

Claude Cowork

채팅과 Claude Code, Cowork를 쓸 수 있는 클로드 정액제의 최상단입니다.

무엇을 해주나

Claude Code 접근, Cowork(데스크톱에서 다단계 작업을 통째로 위임하는 기능), 신규 모델 우선 접근, Pro 대비 높은 사용량이 들어 있습니다. 여기 Max도 두 단계입니다. Max 5x가 월 100달러, Max 20x가 월 200달러입니다.

vs. Codex

Codex가 알잘딱깔센이라면, Claude Code는 동료 느낌을 줍니다. 핑퐁이 더 잦다는 얘기죠. 컨텍스트 한도가 커 오래 해야 하는 작업에 강력하며, 사용자 의견을 좀 더 깊이 반영하려고 애쓰는 느낌이 강합니다. 글쓰기와 웹 디자인 계열 작업이 더 낫다고도 알려져 있고요. 가장 오래, 널리 사랑 받은 제품인 만큼 생태계도 널리 퍼져 있습니다. 아티팩트나 클로드 디자인처럼 작업을 시각화하는 연계에도 능합니다.

언제 쓰나

마찬가지로, 에이전트 코딩을 하루 종일 돌리는 사람한테 필요합니다. 리팩터링이든 문서 자동화든 “AI에게 몇 시간짜리 일을 맡기는” 작업이 매일 있다면 이쪽입니다. 한도까지 쓰고 넘치면 API 종량제로 전환해 토큰을 좀 더 받아 쓰는 방식의 운용이 가능한 것도 (돈 걱정을 내려놓는다면) 장점이라고 볼 수 있습니다.

한계·주의

한도 구조가 2중입니다. 5시간마다 리셋되는 세션 한도 위에 모든 모델에 걸리는 주간 한도가 따로 있습니다. 20x가 사실 전체 한도가 아닌 세션 한도 기준이라는 게 얼마 전에 알려지며 욕을 많이 먹었습니다.
한도는 채팅·Claude Code·Cowork 모두가 공유합니다. 코딩이 채팅 한도를 먹습니다.

자, 이 두 가지 중 하나만 선택해도 텍스트 기반 작업, 에이전틱한 동작, 코드를 비롯한 컴퓨터로 하는 웬만한 일이 다 해결됩니다. 여기까지는 정말 최소한의 기본값입니다. 지금 AI를 제대로 쓴다 하면 보통 이 둘 중 하나를 온전히 쓴다는 것을 전제합니다.

그럼 뭘 써야 하냐고요?

그럼 뭘 써야 하냐고요? 전제를 잊으셨군요. 지금 우리는 돈이 문제가 아닌, 행복한 상상 속에 있습니다.

그럴 때는 굳이 하나를 고를 이유가 없습니다. 결국에는 저들 역시 한도가 막힙니다. 구독이란 결국 “더 높은 천장”이지 천장이 없는 게 아니니까요. 이때의 원칙은 하나입니다. 한도가 막히면 늘리세요. 단, 방향은 고민하면서요.

언제 늘릴까요?

단순합니다. 이미 한도를 열심히 태우고 태워, 남은 게 없을 때죠. 주간 한도 경고를 상시로 보거나 초과분 추가 결제가 매달 반복된다면 구독 계정을 증설할 때가 된 겁니다.
반대로 “결과물이 마음에 안 들어서”라면 멈추세요. 성능 불만은 계정을 늘려도 해결되지 않습니다. 그건 사용량 문제가 아니라 도구를 잘못 선택했거나 시키는 방법의 문제입니다.

그럼 어떻게 늘릴까요?

다른 종류의 한도가 막히면 1+1: Claude로 코딩하다가 크리에이티브한 작업이 부족해지는 식이라면 GPT로 비어 있는 쪽을 채웁니다. GPT를 주로 쓰다가 고도화된 글쓰기나 장기 작업이 잦다면 Claude를 늘릴 수도 있고요. 서로 다른 상한을 하나씩 갖추는 게 먼저입니다. 혹은 서로 다른 모델에 하나의 작업에 대한 의견을 주고받게 하고 싶은 경우에도, 두 개 다른 계정을 확보하는 게 좋습니다.
같은 일의 한도가 막히면 2배로: 에이전트 두셋을 동시에 굴리는 개발자라면 계정 하나의 주간 한도로는 안 됩니다. 이때는 균형을 맞추기보다 원래 하는 일을 비슷한 뉘앙스로 제일 잘 해줄 계정을 두 배로 늘리는 게 맞습니다.

개인적으로는 둘 다 체험해 보고, 본인에게 맞는 계열의 서비스를 정해 그쪽을 파는 것이 낫지 않나 싶습니다. 경험에 비추어 보면, 일단 맡겨놓는 걸 좋아하는 데다 한도 막히는 거에 스트레스 받으면 GPT로, 꼼꼼하게 확인하며 하나의 작업에 집중해 가는 쪽이면 Claude 계열로 가는 것이 일단 정배입니다.

사실 무엇보다 지금 따지는 성능은 엄밀히 말하면 모델의 문제거든요. 언제든 더 좋은 모델이 나오면 바뀔 수 있는 거니까요. 정말 웬만한 일은 다 해 주는 친구들이지만, 이 두 AI도 못 하는 건 있습니다. 그림, 영상, 소리 기반의 크리에이티브한 만들기가 대표적인 영역이고요, 일을 ‘통째로’ 위임하거나 내가 쓰는 생태계에 최적화시킬 때도 다른 선택지가 있습니다.

세상에 몇 없지만, 이들보다 더 잘 일해주는 AI들 몇 가지를 찾아왔습니다.

크리에이티브한 만들기: Midjourney, Higgsfield(+ElevenLabs)

GPT도 이미지를 그리긴 합니다. Claude도 좀 어색하지만 해주죠. 하지만 시안을 수백 장씩 돌리거나 영상을 납품 단위로 뽑는 작업은 어렵습니다. 여기서는 완전히 다른 AI가 필요합니다.

미드저니, 힉스필드, 일레븐랩스

Midjourney Mega

이미지 쪽에서 가장 오래도록 사랑받은 AI입니다. 사실 요금제가 파는 건 이미지 장수가 아니라 GPU 시간입니다.

무엇을 해주나

4단 요금제의 최상단으로 월 120달러(한화 약 16만 원)에 Fast GPU 60시간이 기준입니다. 공식 문서로 확인되는 Mega의 특권은 셋입니다. Relax 모드 무제한 이미지 생성, 무제한 영상 생성, 결과물을 공개 갤러리에 노출하지 않는 Stealth 모드.

언제 쓰나

급하지 않은 대량 시안은 Relax로 무한정 돌리고, 클라이언트 작업은 Stealth로 감추는 조합이 필요한 디자이너입니다.

한계·주의

Relax 무제한에는 0~30분의 대기가 붙습니다. 상한 해제의 대가가 시간인 셈입니다.
Fast 시간을 다 쓰면 시간당 4달러에 추가 구매할 수 있는데요, 그렇다고 사용하지 않은 시간이 다음 달로 이월되지는 않습니다.

Higgsfield Ultra: 영상 모델을 몰아 쓰는 집합소

영상 모델을 회사별로 하나씩 구독하는 대신 한 구독으로 몰아 쓰는 크레딧형 집합소입니다.

무엇을 해주나

Ultra는 월 129달러(한화 약 18만 원)에 3,000크레딧입니다. Sora, Veo, Kling 같은 영상 모델을 한 화면에서 고르고 크레딧은 각 모델, 해상도, 길이에 따라 차감됩니다. 생성 버튼에 비용이 먼저 표시되고 상위 플랜에는 특정 모델을 무제한으로 쓰는 세트도 포함됩니다.

언제 쓰나

광고·숏폼 영상을 모델을 비교해 가며 대량으로 뽑는 작업입니다. 모델별 개별 구독을 대체하는 용도죠.

한계·주의

크레딧은 이월되지 않고 갱신 시 리셋됩니다.
모델별 크레딧 소모 격차가 커서 최신 플래그십 위주로 쓰면 3,000크레딧이 생각보다 빨리 마릅니다.
무제한 세트는 higgsfield.ai 안에서 쓸 때만 적용됩니다.

영상에 사람 목소리까지 필요하다면 선택지가 하나 더 있습니다. ElevenLabs Pro는 월 99달러(한화 약 13만 원)에 60만 크레딧, TTS 기준 약 600분 분량입니다. 내레이션·더빙을 주 단위로 납품하는 사람이 쓸 수 있는 선택지고요. 다만 크레딧 차감률이 기능마다 달라 600분은 이상치에 가깝습니다.

생태계 그 자체를 사기: Cursor Ultra, Google AI Ultra, SuperGrok Heavy

사실 이건 순전히 AI 성능으로 인한 선택은 아닙니다. 내게 익숙하거나 접근이 막힌 생태계를 그럭저럭 괜찮은 AI와 함께 쓰기 위해 사는 거죠. 잊지 마세요. 우리는 지금 돈이 꽤 많으니까요.

xAI, 커서, 구글 로고

Cursor Ultra

아주 익숙한 IDE 안에서 여러 회사 모델을 구독제 하나로 굴리는 개발자용 구독제입니다. 월 200달러.

무엇을 해주나

사용량이 두 개로 갈립니다. Cursor 자체 모델 풀(Grok 4.6, Grok 4.5, Composer 2.5), 그리고 OpenAI, Anthropic, Google 모델을 해당 모델의 API 가격대로 차감하는 서드파티 풀. 한도는 Pro의 20배이고 Grok Bot 최고 한도도 포함됩니다.

언제 쓰나

모델을 갈아타며 대규모 리팩터링과 다중 에이전트를 돌리는 개발자한테 추천합니다. 구독 안에서 API 가격표대로 소진되는 성격이라 비용이 나가는 감이 잡히는 것도 장점입니다. 커서가 또 코딩 에이전트 1세대인 만큼, IDE 시스템에 익숙해진 분들이라면 벗어나기 어려운 것도 있습니다.

한계·주의

포함 사용량이 금액으로 공시되지 않습니다. 공식 문서는 “일상적 Agent 사용자는 보통 월 60~100달러어치, 파워 유저는 월 200달러 이상”이라고 대강의 추천만 알려줍니다.
“그럴 거면 GPT랑 Claude 쓰지”라는 말에 막 대놓고 반박하기가 어렵습니다. 둘 다 들고 갈 이유는 “IDE 워크플로에서 여러 회사 모델을 오가야 한다”가 분명할 때뿐입니다.

Google AI Ultra: 모델보다 넓게 묶은 번들

모델만이 아니라 영상, 스토리지, 유튜브까지 묶은 구글 생태계를 통으로 사는 값이라고 봐야 합니다. 월 200달러입니다.

무엇을 해주나

포함하는 게 많습니다. Gemini 최상위 모델과 Deep Think 추론 모드, Flow/Veo 영상 생성 확장 접근, 코딩 에이전트 Jules 상향 한도, 월 40달러 Google Cloud 크레딧, YouTube Premium, 스토리지 20TB부터. 그럭저럭인 AI에 영상 작업도 도와주고 유튜브 프리미엄도 주고 저장 공간도 주는 거죠.

언제 쓰나

영상 생성과 문서, 메일, 스토리지를 한 계정에서 모조리 관리하고 싶은 경우입니다. “AI 구독”이라기보다 “구글 구독”에 가깝습니다.

한계·주의

겹치는 게 많은데 성능이 최고라고 보기 어렵습니다. 순수 AI 체급은 아무래도 메인 듀오가, 이미지나 영상 계열은 아무래도 Higgsfield·Midjourney와 역할이 겹칩니다. 유튜브와 스토리지 같은 번들 요소를 실제로 쓰는 사람이 아니라면 역할이 좀 겹칩니다.

SuperGrok Heavy

사실 여기에는 Grok Bot과 X가 꽤 큰 지분을 차지합니다. 특히 코딩 에이전트보다 더 쉬운 사용법만으로, 진짜 비서에 가까운 에이전트를 돌리도록 만들어주는 Grok Bot이 매력적입니다. 물론, Grok 그 자체로도 꽤 추론 잘하는 AI입니다.

무엇을 해주나

여러 에이전트가 하위 문제를 동시에 파고들어 하나의 답을 만들어 준다고 합니다. 실시간 X, 웹 검색 위에서 돌아간다는 점도 특징이고요. Grok Bot도 쓸 수 있습니다. Heavy 가격은 월 300달러(한화 약 41만 원)로 이 글에서 가장 비쌉니다.

언제 쓰나

하드한 조사를 병렬로 굴리고 Grok의 에이전트 제품을 상시로 돌리려는 경우입니다.

한계·주의

Grok Bot은 Heavy의 전유물이 아닙니다. 같은 에이전트가 Cursor Ultra에도 들어 있습니다. Grok Bot만이 목적이라면 Cursor Ultra를 먼저 고려해도 좋습니다.
멀티에이전트 추론이 실무에서 얼마나 범용적인지는 아직 논쟁적입니다. “일을 통째로 맡긴다”는 필요가 구체적이지 않다면 가장 나중에 고려할 카드입니다.

마치며: 그래서 뭐부터 살까?

돈 걱정 없이, 그렇다고 낭비는 하지 않고, 지금 AI를 가장 잘 쓰는 순서는 이렇습니다.

메인 AI부터 삽니다. 선택지는 Claude Max 20x와 ChatGPT Pro. 뭐가 나은지는 기호의 영역입니다.
막히는 방향을 확인합니다. 한 달쯤 펑펑 써보면서 뭐가 답답한지 확인합니다. 방향이 확인되기 전에는 더 사지 않습니다.
방향에 맞는 AI 구독을 하나씩 추가. 메인 AI 구독 계정을 늘려도 좋고, 특화된 영역의 AI 구독을 늘려도 좋습니다.

돈 걱정 없이 AI 구독 치트시트

결국, 돈 걱정이 없다는 건 아무거나 사도 된다는 뜻이 아니라 필요가 확인됐을 때 주저 없이 살 수 있다는 뜻입니다. AI 구독을 줄줄이 걸어두고 절반만 쓰는 계정보다, 꼭 필요한 계정 하나만 쓰는 게 낫습니다.

작은 돈은 아니지만요, 그럼에도 지금 AI들은 기술의 초입인 만큼 저렴하게 쓰고 있다고 보는 게 맞습니다. 추론에 들어가는 막대한 비용을 기업들이 피를 흘리며 감당하고 있으니까요. 그래서 최대한 써보고, 어떻게 써야 할지 감을 잡고, 그리고 그 무엇보다 “어디에 쓸지” 파악해 보세요. 거기서부터 시작입니다.

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

]]>

두 명의 청중 앞에서 AI 강의를 해봤습니다

청중은 두명이었다

지금까지 나는 도구를 만든 이야기를 썼다. 서명 검사를 자동화한 이야기, 무엇을 자동화할지 고르는 기준, 왜 시작하게 됐는지, 그리고 두 문서를 대조하는 도구까지, 전부 나 혼자의 이야기였다.

이번 글은 그 다음 질문에 대한 것이다. 혼자 잘 쓰게 됐다면, 그 다음은 무엇인가. 도구가 열두 개가 되도록 그걸 쓰는 사람은 여전히 나 혼자였다. 이 글은 그 간격을 좁혀 보려고 한 첫 시도, 그러니까 청중 앞에서 진행한 한 시간짜리 강의에 대한 기록이다. 미리 말해 두면 이 글에 거창한 성공담은 없다. 다만 강의 다음 날 일어난 일은 내가 넉 달 동안 도구를 만들면서 느꼈던 어떤 성취보다 오래 남을 것 같다.

미리 요점만 콕 집어보면?

넉 달 동안 만든 도구가 열두 개인데, 정작 쓰는 사람은 나 하나였다. 그래서 옆 프로젝트의 두 명과 한 시간짜리 작은 강의로 전파를 시작했다.
설치부터 결제, 화면에 시계를 만들어 보는 실습, 그리고 반복 업무를 목록으로 적어 오라는 과제까지 딱 한 시간이었다. 설치는 15분이면 끝났다.
다음 날 한 명이 퇴근 후에 만든 첫 도구를 보여주며 두 번째를 만들겠다고 했다. 전파는 도구를 나눠주는 일이 아니라, 상대를 첫 화면 앞까지 데려다주는 일이었다.

도구 열두 개와 사용자 한 명 사이의 간격, 그리고 한 시간 강의의 구성을 정리한 도식 <출처: 작가, 클로드로 생성>

도구는 열두 개, 사용자는 한 명

나는 넉 달 동안 도구를 만들면서 이상한 사실을 하나 발견했다. 도구가 늘어나는 속도에 비해, 그걸 쓰는 사람은 늘지 않았다. 정확히 말하면 한 명에서 멈춰 있었다. 나였다.

주변에 AI를 쓰는 사람이 없는 게 아니다. 오히려 다들 쓴다. 옆 프로젝트의 두 사람도 그랬다. ChatGPT나 제미나이를 이미 쓰고 있었고, 좋다는 이야기도 많이 들었다고 했다. 다만 검색보다 조금 편한 것, 물어보면 답해 주는 것 정도로 쓰고 있었다. 그러다 내가 도구를 만들어 쓴다는 이야기를 듣고는 궁금해했다. 같은 AI인데 그건 뭐가 다르냐는 것이다.

사실 이건 두 사람만의 이야기가 아니다. 아직 주변을 지켜보면 사내에서 AI를 쓰는 방식의 대부분이 채팅에 머물러 있다. 물어보고 답을 받고, 문서를 다듬는 것뿐이다. 거기서 멈추는 이유는 능력이 부족해서가 아니다. 본인이 매달 반복하는 일이 사실 AI에 통째로 맡길 수 있는 대상이라는 걸 떠올릴 계기가 없었을 뿐이다. 물어볼 줄은 아는데, 맡길 생각을 못 한다는 것.

그 질문이 이 강의의 출발점이 됐다. 생각해 보면 나도 넉 달 전에는 정확히 같은 자리에 있었다. 채팅으로 묻고 답을 받는 것까지는 해봤지만, 매달 반복되는 업무를 통째로 맡긴다는 건 다른 세계의 일이었다. 그 간격을 건너게 해준 건 긴 설명이 아니라, 행사에서 본 시연 하나였다. 누군가의 화면이 실제로 돌아가는 걸 옆에서 본 것이다. 그게 내 출발점이었으니, 나도 같은 것을 주면 된다고 생각했다.

한 시간짜리 강의를 기획하다

사실 거창한 교육 과정을 만들 생각은 없었다. 청중도 두 명이었기에, 목표를 하나로 좁혔다. 오늘 이 강의를 듣고 돌아가서 혼자 시작할 수 있는 상태로 만드는 것. 그래서 기능 소개는 최소로 하고, 시간을 네 파트로 나눴다.

첫 번째는 설치다. 이날은 클로드와 깃(Git), 그리고 웹 화면 자동화에 쓰는 Playwright까지 세 가지를 설치했다. 말로 들으면 벌써 복잡한데, 실제로 해보면 세 개를 다 깔고 확인하는 데까지 15분도 걸리지 않았다. 이 15분을 같이 해주는 게 강의에서 가장 중요하다고 생각했다. 혼자 설치하다 막히면, 그냥 거기서 끝나는 일이 많기 때문이다.

두 번째는 결제다. 유료로 구독할지는 각자의 선택이지만, 이제 막 시작하는 사람에게는 피해 갈 수 없는 관문이라 화면을 보며 진행했다. 이런 현실적인 부분을 건너뛰면 강의는 깔끔해질지 몰라도, 일상으로 돌아간 사람은 첫 화면 앞에서 다시 멈추게 된다.

세 번째는 실습이다. 화면에 시계 하나를 만들어 봤다. 일부러 업무와 아무 상관이 없는 걸 골랐다. 문장 몇 줄로 눈앞에 뭔가가 만들어지는 경험 자체가 목적이었기 때문이다. 넉 달 전의 나를 움직인 게 정확히 그 장면이었다.

마지막은 과제다. 지금 하고 있는 반복 작업을 목록으로 적어 보고, 그중 하나를 골라 직접 해보라고 했다. 나는 도구를 만들어 주겠다고 하지 않았다. 목록을 만드는 것부터가 자기 업무를 자동화의 눈으로 다시 보는 일이라서, 그건 대신해 줄 수 없었다. 지난 글 “자동화할 일을 고르는 것도 실력이다”에서 무엇을 자동화할지 고르는 것도 실력이라고 썼는데, 그 첫 단추가 바로 이 목록이다. 남이 골라주면 아무래도 남의 일처럼 느껴지지만, 본인이 고른 귀찮은 일은 이미 절반쯤 자기 프로젝트가 된다.

그날 진행한 한 시간의 흐름을 슬라이드 네 장으로 재구성했다. 목표, 설치, 실습, 과제다. <출처: 작가, 클로드로 생성>

두 명의 청중 앞에 서다

사실 강의라고 부르기엔 소박한 자리였다. 회의실에서 노트북을 펴고, 두 사람의 화면에 같은 것을 띄워 가며 한 시간을 보냈다. 그 중 기억에 남는 질문은 기능에 대한 게 아니었다. 한 분이 진지하게 “영화에서처럼 AI가 너무 똑똑해져서 내 개인정보를 훔쳐가고 악용하면 어떡하냐”고 물었다. 웃자고 한 말이 아니라 진심이었다.

나는 그 자리에서 “클로드는 공식 제품이고, 내가 주고받은 내용이 모델 학습에 쓰이는지는 계정의 데이터 설정에서 직접 확인하고 끌 수 있다. 막연히 어딘가로 흘러가는 구조가 아니다.”라고 말했다. 그리고 오히려 주의할 지점은 따로 있다고 전했다. 클로드 코드는 내 노트북의 터미널에서 직접 명령어를 실행하는 도구다. 그래서 명령을 실행하거나, 파일을 고치겠다고 승인을 요청하는 순간이 온다. 그때 어떤 내용인지 잘 읽어 보고, 승인하는 습관만 들이면 비교적 안전하게 쓸 수 있다. 걱정할 것은 영화 속 이야기가 아니라, 내가 무심코 누르는 승인 버튼이라는 얘기다.

나는 이 질문이 고마웠다. 처음 시작하는 사람의 진짜 문턱이 무엇인지 알 수 있었기 때문이다. 우리는 흔히 진입 장벽이 기능이나 명령어에 있다고 생각하지만, 실제로는 AI에 대한 막연한 두려움에 있다. 무엇을 조심해야 하고, 걱정하지 않아도 되는지를 구분해 주는 것이 기능 하나를 더 보여주는 것보다 훨씬 중요하다는 걸 배웠다.

그리고 이 걱정은 남의 것이 아니라, 나도 같은 자리에서 출발했다. 앞선 글에서 다뤘지만, 나는 회사 자료를 함부로 외부 도구에 올리는 순간 사고가 난다고 생각했다. 그래서 첫 도구부터 무엇은 되고, 무엇은 안 되는지 선을 긋는 것부터 시작했다. 그 경험이 있어서 이 질문에는 기능 설명보다 더 길게 답변했다. 두려움은 무시해서 없어지는 게 아니라, 경계선이 분명해질 때 줄어든다.

청중이 두 명뿐이라 좋았던 점도 분명했다. 질문이 바로 나오고, 막히는 지점이 바로 보였다. 화면이 다르게 뜨면 그 자리에서 같이 들여다보면 된다. 큰 교육이었다면 손을 들지 못하고 그냥 넘어갔을 부분도 두 명이기에 가능했다.

실습 장면: 몇 마디의 요청이 아날로그와 디지털, 스톱워치까지 붙은 시계 파일이 됐다. (그날 만든 실물을 본떠 재구성) <출처: 작가, 클로드로 생성>

다음 날, 자랑이 돌아왔다

강의 이후, 피드백이 생각보다 빨리 왔다. 다음 날, 한 분이 찾아와 자랑을 한 것이다. 어제 퇴근하고 과제를 해봤는데, 자기가 하는 반복 작업을 목록으로 적고, 그중 하나를 골라 도구를 직접 만들어 봤다고 했다. 첫 도구의 대상은 매월 회사 시스템에 한 달 치 근무를 등록하는 작업이었다. 화려한 기능이 아니라 매달 어김없이 돌아오는 귀찮은 일이다. 목록을 적어 보라고 한 이유가 정확히 그런 일을 찾기 위해서였는데, 첫 도구로 그걸 골랐다. 그리고 오늘은 두 번째 도구를 만들어 보겠다고 했다.

강의를 한 지 하루 만이었다. 나는 첫 도구까지 몇 주가 걸렸는데, 이분은 하루 저녁에 그 지점을 통과했다. 시연을 보고, 설치를 끝내고, 업무 목록이 손에 있으면 시작이 이렇게 빨라진다. 넉 달 전에 나에게 없었던 조건을 갖춰준 셈이니, 빠른 게 당연한지도 모른다.

다른 한 분도 자기 방향을 정했다. 평소 엑셀로 이것저것 만들어 보는 걸 좋아하는데, 클로드를 엑셀 작업에 활용해 보겠다고 했다. 같은 강의를 들었는데 두 사람이 고른 길은 다르다. 한 명은 회사 시스템의 반복 등록을, 한 명은 손에 익은 엑셀을 골랐다. 같은 출발선에서 각자 본인 일에 가장 가까운 문으로 들어간 셈이다.

그 자리에서 우리는 약속 하나를 했다. 서로 해보면서 안 되는 부분이 나오면 의견을 공유하고, 조금씩 같이 성장하며 윈윈하자는 것. 가르치는 사람과 배우는 사람으로 남는 게 아니라, 각자 만들다 막히면 서로의 화면을 봐주는 사이가 되는 것이다. 3편에서 썼던 문장을 다시 꺼내면, 시작할 때 혼자가 아니라는 것이 계속 할 수 있게 만드는 힘이다.

한 시간의 타임라인과 다음 날 돌아온 결과까지, 이틀의 흐름을 한 장으로 담았다. <출처: 작가, 클로드로 생성>

조직의 변화라고 부르기엔 아직 작지만

이 이야기를 조직의 변화라고 부를 생각은 없다. 두 명이 시작했고, 한 명은 첫 도구를 만들었고, 다른 한 명은 자기 영역을 정했다. 숫자로 적으면 그게 전부다. 이 숫자를 부풀릴 생각도 없다. 내 경험상 전파는 위에서 한꺼번에 내리는 게 아니라, 옆으로 한 자리씩 번지는 것이었다. 나도 시연 하나에서 시작해 넉 달 만에 열두 개를 만들었다. 하루 만에 첫 도구를 만든 분의 옆에도 궁금해하는 누군가가 있을 것이다. 다음에 시연을 하는 사람은 내가 아니라 그 분이 될 수도 있다.

그리고 하나 더 배웠다. 전파의 성과는 내 도구를 쓰는 사람 수가 아니라는 것. 내 도구를 받아 쓰는 사람이 늘어나는 것보다, 자기 도구를 만드는 사람이 한 명 생기는 쪽이 훨씬 멀리 간다. 도구는 만든 사람의 업무에 맞을 때 가장 잘 돌아가고, 만드는 경험은 다음 도구로 이어지기 때문이다. 내가 준 건 도구가 아니라 시작이었고, 그게 이 강의에서 가장 잘한 일이라고 생각한다.

마치며: 도구를 만드는 일과 퍼뜨리는 일

넉 달 전 나는 도구를 만드는 게 어려운 일인 줄 알았다. 지금은 생각이 다르다. 만드는 건 혼자 열심히 하면 되는 일이라 오히려 단순했다. 다만 퍼뜨리는 건 다른 사람의 시간과 일이 걸린 일이라 훨씬 더 조심스럽다.

그래도 직접 해보니 알겠다. 전파의 단위는 조직이 아니라 옆 사람이다. 전체 공지도, 두꺼운 매뉴얼도 아니었다. 궁금해하는 두 명과 회의실에서 보낸 한 시간, 같이 해준 15분의 설치, 그리고 반복 업무를 적어 오라는 과제 하나. 실제로 일어난 일은 그게 전부였고, 다음 날 첫 도구가 돌아왔다.

혹시 혼자만 쓰는 도구나 방법이 있고 그걸 나누고 싶다면, 먼저 해볼 일은 거창하지 않다. 관심을 보인 옆 사람 한둘에게 내 화면이 실제로 돌아가는 걸 보여주고, 설치를 같이 해주고, 자기 업무를 목록으로 적어 보게 하는 것이다. 나는 그 방식으로 시작했고, 이번에 같은 방식으로 돌려줬다. 다음 글을 쓸 때쯤에는 그 분의 도구가 몇 개로 늘어나 있을지, 나도 궁금하다.

이 글이 마음에 드셨다면, 작가 페이지에서 알림 설정과 좋아요를 부탁드립니다.

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

]]>

내가 일부러 AI에게 맡기지 않은 것들

자율주행, 법률, 헬스케어 AI 서비스를 만들며 배운 선 긋는 법

AI에 선을 긋는 이유

제가 만든 AI 법률 분석 서비스는 승소를 약속하는 문장을 쓰지 않습니다. 법률 서비스를 찾아오는 분들이 가장 듣고 싶어 하는 말이 바로 그것인데도요. 일부러 쓰지 않기로 했습니다. 이 글은 그 ‘일부러’에 대한 이야기입니다.

요즘에는 AI 기능 하나 안 붙은 서비스 찾기가 어렵습니다. 기획서마다 “AI가 추천”, “AI가 요약”, “AI가 분석”이 들어가고, 우리는 매번 AI로 무엇을 더 할 수 있을지를 고민하죠.

그런데 저는 실무에서 정반대의 고민이 훨씬 자주 발목을 잡는다는 걸 배웠습니다. AI에 무엇을 맡기지 않아야 하는가. 이 질문에 제대로 답해두지 않으면, AI가 틀리는 순간 사용자와 제품이 함께 무너집니다. 그래서 저는 AI가 틀려도 되는 부분이 어디까지인지 먼저 선을 긋습니다. AI가 무엇까지 판단해도 되는지, 사람은 언제 개입해야 하는지를요.

돌아보면 저는 자율주행 UX 연구, AI 법률 서비스, 헬스케어 서비스를 만들며 세 종류의 선을 그어왔습니다. 1) 운전자의 주의를 지키는 인지적 경계, 2) AI가 말해선 안 되는 것을 정하는 언어적·책임적 경계, 그리고 3) 사용자의 마음이 다치지 않게 하는 심리적 경계입니다.

이 글에서는 그 세 개의 선을 어디에, 왜 그었는지 실제 경험과 함께 풀어보려고 합니다. 물론 여러분의 도메인에서는 다른 위치에 선이 그어질 수도 있을 겁니다. 제 경험이 여러분 스스로 내 서비스 어디에 선을 그어야 할지 고민하는 데 도움이 되길 바랍니다.

인지적 경계: 시선을 빼앗지 않는 공간

첫 번째 선은 자율주행 UX를 연구하던 대학원 시절에 그었습니다. 당시 저는 운전 중 스마트워치로 입력 명령을 인식하는 인터페이스를 연구했죠. 문제의식은 단순했습니다. 차 안에 화면과 버튼을 추가할수록 운전자의 시선은 도로 밖으로 끌려 나갑니다. 인터랙션을 확장하고 싶다면, 시각적 주의를 빼앗지 않는 공간을 찾아야 했어요.

저희가 찾은 답은 운전자의 무릎이었습니다. 무릎은 거의 평평해서 터치패드처럼 쓸 수 있거든요. 무릎 위에서 손가락을 두드리고, 접고, 펴는 열 가지 제스처를 정의하고, 스마트워치의 모션 신호를 머신러닝으로 학습시켰습니다. 인식 정확도는 94%였고, 이 연구는 국제 학술지 IEEE Transactions on Intelligent Vehicles에 실렸습니다.

<출처: 작가>

그런데 시간이 지나 제게 남은 건 94%라는 숫자나 논문의 성과가 아니었습니다. 이 연구가 처음부터 끝까지 붙들고 있던 전제였어요.

‘주행은 인간의 책임 영역이고, 기술은 그 영역의 인지 자원을 침범해서는 안 된다.’

새 기능을 더하는 일조차, 인간이 지고 있는 책임의 경계를 건드리지 않는 방식이어야 합니다. 기술이 무엇을 할 수 있느냐보다, 기술이 어디까지 들어와도 되느냐가 먼저인 거죠. 이 전제는 몇 년 뒤 제가 훨씬 위험한 영역의 서비스를 만들 때 다시 소환됐습니다.

언어적·책임적 경계: AI가 말할 수 없는 것

로윈은 제가 만든 판례 기반 AI 법률 분석 서비스입니다. 사용자가 사연을 입력하면 유사한 실제 판례를 찾아 쟁점과 대응 전략을 짚어주죠. 이혼·재산분할, 해고·노동, 상간소송처럼 검색창에 치기도 막막한 문제를 안고 오시는 분들이 씁니다.

법률 AI에서 가장 위험한 것은 오답이 아니라 ‘헛된 희망’과 ‘잘못된 확신’입니다. 분쟁 한가운데 있는 사용자는 절박하고, 절박한 사람은 AI의 문장을 분석이 아니라 판결처럼 받아들이거든요. 그래서 로윈에는 여러 겹의 선이 있습니다.

<출처: 로윈>

‘승소’라는 단어의 용법을 제한하기

‘승소’라는 단어는 법정에서 많이 등장하며, 사용자가 가장 듣고 싶어 하는 단어입니다. 그래서 저는 단어 자체가 아니라 용법에 선을 그었습니다. AI가 결과를 단정하거나 확률로 약속하는 말, 예를 들어 “승소 확률 80%” 같은 표현은 쓰지 않습니다. 대신 ‘승소 전략 정리표’처럼, 사용자가 준비해야 할 전략을 가리킬 때 씁니다. AI가 결과를 예언하는 순간 사용자의 판단은 사라지고, 그 문장에 기대어 인생을 바꿀 결정이 내려지거든요.

그래서 리포트가 보여주는 지표도 승소 확률이 아니라 쟁점별 판단 근거입니다. 지표마다 근거가 된 대법원 판례와 법조문을 함께 인용하고, 리포트 상단에는 “참고용 분석, 법적 효력 없음”을 발급일 옆에 넣습니다. 화면 하단의 고지 “본 서비스는 법률 정보 제공 목적이며 법률 상담이 아닙니다”는 면책 문구이기 전에 서비스의 정체성 선언입니다.

<출처: 로윈>

단계가 올라갈수록 사람에게 가까워지는 구조

로윈의 리포트는 3단계로 나갑니다. 기본 리포트는 핵심 쟁점과 대응 전략을, 판례 리포트는 유사 판례 분석과 전략 비교표를, 심층 리포트는 예상 시나리오 분석과 변호사 선택 가이드, 전문가 연계 신청을 담습니다.

이 구조에서 제가 가장 공들인 건 방향입니다. 단계가 올라갈수록 AI가 더 많이 판단해주는 게 아니라, 단계가 올라갈수록 사람에게 가까워집니다. 사용자가 가장 많은 돈을 내는 마지막 단계의 마지막 버튼은 더 똑똑한 AI가 아니라 변호사 연결입니다. 중간 산출물에 변호사 상담 준비용 리포트를 담은 것도 같은 이유고요. AI의 역할은 전문가의 대체가 아니라, 사연을 정돈하고 판례를 매칭해 전문가를 만날 준비를 시키는 것입니다. 사용자는 쟁점이 정리된 상태로, 무엇을 물어야 할지 아는 상태로 변호사 앞에 앉게 되죠. AI가 잘할수록 인간 전문가와의 만남이 더 밀도 있어지는 구조, 그게 제가 생각한 신뢰의 형태였습니다.

<출처: 로윈>

입력 즉시 폐기하는 데이터의 경계

로윈의 입력창 아래에는 이렇게 적혀 있습니다. “입력 내용은 분석 후 즉시 폐기 · 저장·공유 없음.” 법률 사연은 한 사람의 가장 취약한 기록입니다. 이혼 사유, 재산 내역, 상대방과의 갈등. 이런 데이터를 서비스 개선이라는 명목으로 쌓기 시작하면 경계는 이미 무너진 겁니다. 사용자의 이야기는 분석되는 순간까지만 우리 것이고, 그 이후는 다시 사용자의 것이어야 해요.

이 선들의 위치를 정한 기준은 하나입니다. ‘AI가 틀렸을 때 사람이 되돌릴 수 있는 지점까지만 AI에 맡긴다.’ 쟁점 정리는 틀려도 변호사 상담에서 교정됩니다. 그러니 AI의 몫입니다. 소송 여부의 결정은 틀리면 되돌리기 어렵습니다. 그러니 끝까지 사람의 몫으로 남깁니다.

심리적 경계: 거부감과 공포를 낮추는 디테일

경계를 설계할 때, 늘 막는 방향으로만 확장하는 것은 아닙니다. 헬스케어 서비스들을 만들며 제가 배운 건 오히려 반대였습니다.

서울대병원이 주최한 ‘적외선 수면 동영상 인공지능 챌린지’에서 수상한 적이 있습니다. 수면 동영상으로 수면의 질 패턴을 파악하는 과제였는데, 여기서도 역할의 구도는 같았습니다. AI가 잘하는 건 사람이 밤새 지켜볼 수 없는 것을 지치지 않고 관찰해 패턴을 찾는 일이고, 그 패턴이 무엇을 의미하는지 진단하는 일은 의사의 영역입니다.

더 어렸을 때는 과민성대장증후군 환자를 위한 서비스를 기획했습니다. 이 서비스의 핵심 과제는 놀랍게도 기술이 아니라 심리였는데요. 환자는 자신의 배변 상태를 꾸준히 기록해야 하는데, 이건 누구에게도 말하고 싶지 않은 주제입니다. 그래서 대변의 분류를 거리감 없는 일러스트로 표현했습니다. 민망한 의학 사진 대신, 친근하게 그려진 그림 중에 고르게 한 거죠. 질환 데이터와 사용자 사이의 심리적 거리감을 캐릭터 레이어 하나로 낮추는 설계였습니다.

위험한 영역에서 AI와 사람 사이의 경계는 명확히 세워야 하지만, 동시에 서비스와 사용자 사이의 심리적 경계는 집요하게 낮춰야 합니다. 경계를 설계한다는 건 어디를 막을지와 어디를 열지를 함께 정하는 일입니다.

대변의 특징을 7단계로 분류한 브리스톨 척도(Bristol Stool Scale) <출처: 작가>

선의 굵기와 오류 비용

물론 모든 서비스에 같은 굵기의 선이 필요한 건 아닙니다. 저는 직장 생존 유형을 진단해 주는 김사수 같은 저위험 B2C 서비스도 만들고 있습니다. 결과의 정확성보다 공감이 더 중요한, 사용자가 웃고 넘기는 영역에서는 AI에 넓은 무대를 주고 몰입의 UX를 실험해요.

오류의 비용이 낮은 곳에서는 경계를 열고, 오류의 비용이 인생 단위인 곳에서는 가드레일을 세웁니다. 경계선의 위치를 결정하는 건 AI의 성능이 아니라 오류의 비용입니다.

<출처: 김사수>

마치며

AI 업계에서는 모델 바깥에서 AI의 동작 범위와 규칙을 설계하는 일을 ‘하네스 엔지니어링(harness engineering)’이라고 부릅니다. 좋은 프롬프트와 풍부한 맥락만으로는 신뢰할 수 있는 AI 제품이 완성되지 않는다는 뜻이 담긴 말인데요.

‘승소를 약속하는 문장’을 금지한 어휘 규칙, 마지막 버튼을 변호사로 둔 리포트 구조, 입력 즉시 폐기하는 데이터 정책, 무릎 위로 옮긴 인터랙션, 그리고 대변 일러스트까지. 전부 AI의 능력이 아니라 AI가 멈춰야 할 자리를 정하는 설계였습니다. AI 시대의 디자이너는 화면 설계자를 넘어, AI의 환각과 과신을 통제하는 하네스 설계자여야 한다고 생각합니다.

좋은 AX(AI eXperience)란 AI의 능력을 포장하는 것이 아니라, 인간이 개입할 자리를 명확히 정의하고 남겨두는 것이라고 믿습니다. 신뢰는 AI가 잘하는 것을 보여줄 때가 아니라, 멈춰야 할 곳에서 멈추는 것을 보여줄 때 생깁니다. 자기 한계를 아는 상대만이 신뢰의 대상이 되니까요.

경계는 제한이 아닙니다. 경계는 통제권이 여전히 사람에게 있다는 약속이고, 신뢰가 자리 잡는 형태 그 자체입니다. 그 선을 어디에 그을지 정하는 일. 그것이 지금 AI 시대에 디자이너가 해야 할 가장 중요한 설계라고 생각합니다.

여러분은 지금 만들고 있는 서비스에서, AI에 일부러 무엇을 맡기지 않고 있나요?

]]>

FDE 20명을 채용했습니다. SI와는 다릅니다

지난해(2025년) 4분기부터 올해(2026년) 9월까지, FDE(Forward Deployed Engineer)를 20명 채용했습니다. 그사이 AI 모델과 그 모델을 다루는 사람과 기술, 그리고 그것이 실제 변화로 이어지기까지 수많은 과정이 있었습니다.

최근에는 소프트웨어 엔지니어링과 AI Native를 실현하는 비용을 0에 수렴시키는 서비스의 준비를 거의 마쳤습니다. 이제 이 서비스를 무료로 풀고, 실제 변화에 집중하기 위한 다음 단계를 준비하고 있습니다.

전통기업 현장에 직접 들어간 FDE <출처: 작가 구성, 이미지 생성 gpt-image-2>

안녕하세요, 위시켓에서 CSO(Chief Strategy Officer, 최고 전략 책임자)를 맡고 있는 이홍주입니다. 저는 IT 컨설팅과 SI(System Integration) 시장에서 13년 정도 일해왔습니다. 그리고 올해 7월, 위시켓은 ‘2027년까지 FDE 140명 채용’이라는 내러티브로 투자를 유치했고, 그 과정에서 저는 시장의 여러 이해관계자와 소통했습니다.

AI 모델과 기술이 발전하고 소프트웨어 엔지니어링 비용이 계속 낮아지면서, FDE에 대한 시장의 관심과 궁금증도 계속 커지고 있습니다. 그래서 이 전문성과 경험을 토대로, 제 관점에서 FDE라는 역할이 무엇이고 왜 시장의 관심이 높아지는지 이야기해보려 합니다. FDE가 필요하다고 느끼는 기업, 그리고 FDE라는 커리어에 관심 있는 분들께 작은 도움이 되길 바랍니다.

미리보기

FDE는 SI랑 뭐가 다른가요?
직무는 사라졌고, 병목은 사람에게 남았습니다
그런데 왜 다들 SI를 피할까요? 돈이 만들어지는 곳
미션·비전이 납득되지 않는 FDE 채용은 SI 채용입니다. 그리고 팔란티어 모델은 한국에서 안 됩니다
위시켓의 답: 기술로 P&L을 바꾼다
하방은 회사가, 상방은 FDE가
진짜 FDE 회사를 가려내는 한 문장
마치며: AI Native는 그저 Tool입니다

1. FDE는 SI랑 뭐가 다른가요?

이 글을 읽는 분이라면 최소한 FDE가 팔란티어(Palantir)에서 시작됐다는 정도는 알고 계실 겁니다. 이미 많이 들어보셨을 이야기이니, 저는 다른 곳에서 시작하겠습니다. 바로 이 질문입니다. “기존 SI랑 FDE가 뭐가 달라요? 똑같은 거 아닌가요?”

먼저 SI란 뭘까요? 직무로서 SI는 보통 고객사에 나가서 여러 업무 시스템을 통합하거나 새로운 서비스를 구축하는 개발자를 말합니다. 여기서 키워드를 뽑아보면 네 가지입니다. ‘고객사’, ‘나가서’, ‘업무 시스템’, ‘구축’.

먼저 ‘고객사’. SI는 인하우스 개발자나 제품(프로덕트)팀과 구별됩니다. 대부분 자사 서비스가 아니라 남, 즉 고객사의 시스템을 개발하죠.

다음은‘나가서’. SI 개발팀은 보통 인하우스가 아니라 고객사 현장에 파견되어 개발합니다. 그러다 보니 간혹 파견직 같은 서러움을 느끼기도 합니다. 서러워할 일이 아닌데도 말이죠. 우리나라에는 그런 잘못된 관념이 여전히 많습니다.

그리고 ‘업무 시스템’. 대고객 서비스에서도 SI가 이루어지는 경우가 많지만, 비중은 압도적으로 업무 시스템이 높습니다. 대고객 서비스는 인하우스화되거나 제품화되기 때문이죠.

자, 이제 SI를 정의했으니 FDE와 비교해볼까요? FDE는 단어 그대로 현장(Forward)에 배치된(Deployed) 엔지니어(Engineer)입니다. 이렇게만 보면 SI의 ‘고객사’, ‘나가서’, ‘업무 시스템’, ‘구축’과 큰 차이가 없어 보이죠. 실제로도 그렇습니다.FDE를 채용한다는 국내 기업 상당수는 사실상 SI를 채용하고 있습니다.

저는 이 상황을 이렇게 해석합니다. “고객사에 나가서 온갖 현장에서 손에 흙 묻히는 자리, 원래는 SI라서 다들 피하던 포지션인데, 이번엔 FDE라는 타이틀로 커리어를 포장해줄 테니 같이 해볼래?” 대부분이 이러한데, 이건 기만이라고 생각합니다. 다소 공격적으로 들릴 수 있지만 이는 사실에 가깝습니다. 이런 현실이 안타까워서 이번 글을 쓰게 된 부분도 있지요.

FDE의 진짜 의미와 가치를 논하기 전에, 지금 AI 시대에 무엇이 바뀌었는지 잠시 돌아볼 필요가 있습니다. 기업들이 FDE라는 타이틀로 포장한 기만적인 채용 공고를 내는 이유가 바로 거기 있으니까요.

2. 직무는 사라졌고, 병목은 사람에게 남았습니다

2022년 말 공개된 ChatGPT가 2023년 본격적으로 확산된 이후, 그리고 제 체감으로는 2025년 하반기 클로드(Claude)의 Sonnet·Opus 4.5 모델이 출시된 이후, 전통적인 소프트웨어 엔지니어링 직무는 소멸했습니다. 누군가는 Claude의 Fable, OpenAI의 Astra 모델 이후에야 그렇게 체감했거나, 아직 체감하지 못했을 수도 있습니다. 하지만 그 시기부터 넓은 의미의 하네스(Harness)를 구축한 앞서가는 엔지니어링 그룹은 이미 소프트웨어 엔지니어링을 에이전트에게 넘겼습니다. 저희 위시켓은 조금은 늦었지만, 올해 2~3월부터 그런 소프트웨어 엔지니어링 하네스를 구축했고요.

오해가 없도록 덧붙이면, 소프트웨어 엔지니어링이라는 활동 자체는 결코 사라지지 않습니다. 사라진 것은 전통적인 분업 형태의 직무입니다. 전통적인 소프트웨어 엔지니어링은 ‘요청 관리’, ‘UAT(User Acceptance Test, 사용자 인수 테스트)’ 같은 개념을 정의하고 언급해왔습니다. 소프트웨어를 사용하는 그룹을 엔지니어링 그룹과 분리해서 바라봤다는 뜻이죠.

이제는 다릅니다. 수요자나 사용자 관점에서 과업의 배경과 제품을 이해하고, 목표 결과를 분명히 하고, 검수 기준을 분명히 하는 역할. 이것이 사람이 맡는 소프트웨어 엔지니어링의 영역이고, 그 밖의 모든 루틴한 엔지니어링은 에이전트가 합니다.

다시 본론으로 돌아와서, 기업들은 이제 AI 에이전트 중심의 소프트웨어 엔지니어링이 얼마나 효율적이고 경제적일 수 있는지 깨달았습니다. 동시에, 앞서 말한 ‘사람의 역할’을 할 수 있는 엔지니어가 희소하다는 것도 깨달았죠. 우리 회사의 목표와 환경을 이해하고, 니즈를 AI 에이전트에게 명확하게 전달할 수 있을 만큼 해상도를 높이고, 그 결과까지 알맞은 기준으로 검수할 수 있는 ‘사람’이 필요해진 겁니다.

그림: 루틴한 엔지니어링은 에이전트가 싸게 처리하지만, 목표와 검수 기준을 정하는 사람이 병목으로 남는다 <출처: 작가 구성, 이미지 생성 gpt-image-2>

"그거 원래 PO(Product Owner), UI/UX 디자이너, QA(Quality Assurance) 같은 직무가 하던 일 아닌가요? 그 직무 경험자에게 맡기면 되잖아요?”라고 물으실 수도 있습니다. 아쉽게도 현실은 그렇지 않습니다. 이 전통적인 직무들은 역할과 경계가 명확했고, 각각 특정한 전문성이 필요했습니다. 그 전문성 자체가 희소한 자원이었기 때문에, 아무도 이분들에게 그 이상의 역할을 요구하지 않았습니다. 엄밀히 말하면, 요구하지 못했죠.

Specialist에서 Generalist로 전환하는 데에는 트레이드오프가 따릅니다. Specialist는 보통 전문성을 기반으로 업무 환경에서 안전지대를 구축하기 쉽고, 채용 시장에서도 비교적 안전합니다. 반면 Generalist는 책임은 많아지고 전문성을 강화할 시간은 부족해집니다. 그래서 이 전환은 일부 리더나 PM(Project Manager)급에게만 요구할 수 있었고, 요구하더라도 보통 좋은 결과로 이어지지 않았습니다.

결국 이런 역할과 경계를 허물고, 손에 흙을 묻히며 에이전트를 기반으로 성과를 만들어낼 수 있는 사람은 AI 시대 이전에도 희소했고, 지금도 여전히 희소합니다.

이제 정리해보죠.

기업은 소프트웨어를 기반으로 많은 변화를 만들어낼 수 있음
프로젝트 관리, UI 디자인, 코딩, QA 같은 소프트웨어 엔지니어링의 전문 영역을 AI 에이전트를 통해 낮은 비용(심지어 확장 가능하게)으로 처리할 수 있게 됨
그러나 목표와 배경을 이해하고, 기대 결과의 해상도를 높이고, 검수 기준을 제시하는 사람의 역할은 여전히 병목이며, 이 병목 때문에 전체 생산성은 그대로이고 변화도 잘 만들어지지 않음
전통적으로 SI 직무가 기업 현장에서 이와 비슷한 일을 해왔고, 기업들은 이런 SI 경험자를 FDE라는 타이틀로 포장해 채용하고 있음

이렇게 정리하고 나면 왜 FDE라는 포지션과 역할이 각광받는지 충분히 이해되셨을 겁니다. 그리고 ‘아무리 각광받아도 나는 SI는 절대 안 해’라는 생각이 드셨다면, 그 또한 자연스럽습니다. 하지만 저는 기업들이 FDE라는 이름으로 SI를 채용하는 기만을 넘어, 진짜 FDE가 무엇인지, SI와 달리 어떤 독보적인 가치가 있는지 짚어보려 합니다.진짜 FDE가 왜 SI와 다른지, 왜 ‘나의 젊음과 커리어를 투자할 가치’가 있는지 다시 생각해보는 기회가 되었으면 합니다.

3. 그런데 왜 다들 SI를 피할까요? 돈이 만들어지는 곳

앞에서 저는 SI 경험자를 편하게 모시려고 FDE 타이틀을 쓰는 게 기만이라고 했습니다. 그리고 SI가 현장에서 전통적으로 해오던, 경계와 역할을 허무는 일은 굉장히 좋게 포장해서 말했을 뿐입니다. 다들 아시겠지만, SI 경험이 있다고 모두가 그런 역할을 해낼 수 있는 건 아닙니다.

SI뿐 아니라 컨설팅펌도 마찬가지입니다. 프로젝트 팀이 꾸려지면 PM을 중심으로 어떻게든 일이 되게 하려고 고군분투합니다. 팀에는 소위 에이스라 불리는 몇 사람이 있어서 과업이 겨우 끝나고, 책임과 일의 범위는 점점 그 에이스에게 쏠립니다. 그리고 그 에이스는 지쳐서 탈출하거나, 방어적으로 변해 그저 남아 있게 됩니다. 번아웃 내지는 흑화했다고도 표현하죠.

여기서 이런 의문이 들지는 않으셨나요? 그렇게 중요한 병목을 해소하는 역할이라면, 할 수 있는 사람(공급)은 적고 수요는 많을 테니 보상과 처우 수준도 높을 테고, 그러면 회사에 좋은 인재가 계속 모여서 오히려 더 시너지가 나는 구조여야 하지 않나? SI든 FDE든, 왜 다들 기피하려고 할까?

좋은 질문입니다. 이걸 설명하려면 돈이, 즉 가치(Value)가 만들어지는 과정을 이해해야 합니다. 그리고 이것은 다시 FDE의 역할과 커리어의 본질로 연결되기 때문에 더욱 중요한 지점입니다.

소프트웨어 구현에 대한 결정이 내려지기 전에는 항상 비즈니스 관점의 니즈와 고통이 먼저 있습니다. 왜 지금 이걸 해야 하는가? 얼마나 많이 투자해서 어떤 결과를 기대할 것인가? 이를 구체화하는 과정이죠.

전형적인 대기업을 예로 들어보죠. 먼저 전략기획이나 경영기획 기능에서 이 부분이 구체화됩니다. 그다음 정보전략, 디지털/AX(AI Transformation, AI 전환) 전략 기능으로 넘어가 다음 단계를 구체화하고요. 이렇게 내부적으로 지난한 과정을 거쳐 기본설계와 개념설계가 이루어지면 RFP(Request for Proposal, 제안요청서)를 씁니다. 대기업에서는 바로 이 단계가 가치의 대부분입니다. 이후 RFP에 따라 제안을 검토하고 실행해나가는 것은 이미 가시화된 일입니다.

예를 들어, LG전자가 과업을 진행하기 위해 내부적으로 기안해서 RFP까지 썼고, LG CNS가 이 RFP가 잘 작성되도록 지원했고, 여러 하청 업체가 이 RFP에 응찰했다고 해보죠. 그렇다면 이 프로젝트 가치의 70%는 이미 RFP 작성 단계에서 끝났고, 나머지 30%인 선정 및 실행 단계에서는 크게 돈을 쓸 이유를 느끼지 못합니다. 가치는 불확실성을 제거하면서 발생하는데, 실행 단계에서는 불확실성이 이미 많이 줄어들었기 때문이죠.

표: 가치가 결정되는 단계 / <출처: 작가 추정. 위 가정 예시에서 나온 대략의 비중이며 특정 기업의 실제 수치나 단계별 비율이 아님>

대부분의 SI 회사는, 심지어 대기업 계열 SI 회사까지 포함해서, 이미 획득할 수 있는 가치의 파이가 없습니다. 여기에 몇 단계의 하도급이나 컨소시엄까지 끼고 나면, 획득 가능한 가치는 인건비에 약간의 마진율을 더한 수준이겠죠.

그림: (작가 추정 개념도) 불확실성이 걷히는 앞단에 가치가 쌓이고, 실행 단계에는 작은 몫만 남는다 <출처: 작가 구성, 이미지 생성 gpt-image-2>

대기업 구조니까 당연해 보이나요? 그럼 중견기업과 중소기업은 어떨까요? 우리나라에는 생각보다 지불 여력이 큰 중견·중소기업이 많습니다. 얼핏 보면 블루오션이죠. 하지만 아는 사람은 다 알듯이, 현실은 전혀 그렇지 않습니다.

큰 기업이 당연하게 갖추고 있는 전략기획, 정보전략, IT 개발·운영 같은 ‘구조와 거버넌스’에는 보이는 것보다 더 많은 의미와 역사가 있습니다. ‘중소기업도 전략기획, 정보전략, IT 팀을 갖추면 되는 거 아니야?’ 수준의 문제가 아닙니다. 의사결정 거버넌스, 조직과 사람, 인적·물적 환경이 모두 열악합니다.

이런 상황에서는 RFP라는 것 자체가 제대로 나오지 못합니다. 그런 환경에서 SI 파트너와 일을 시작하면 결국 높은 확률로 망합니다. 이 리스크를 피하려고 앞단에 여러 컨설팅펌이나 PM 회사를 붙이거나, 추가로 내부 채용을 진행하죠. 게다가 우리나라는 인재가 대기업에 치중되어 있어서, 중소기업의 일을 하려는 자원 자체를 확보하기가 더 어렵습니다. 결국 중견·중소기업 시장에서도 SI는 물론이고 컨설팅펌이 가져갈 수 있는 가치마저 점점 희석됩니다.

이것이 SI 직무가 기피되는 가장 근본적인 이유입니다. 돈을 벌지 못하는 산업에서는 생태계가 형성되지 않습니다.

지금까지 제가 FDE 저주론자처럼 보였다면, 이제부터는 저희가 왜 1년 만에 FDE 20명을 채용했는지(현재 전체 인원 75명 중), 왜 2027년까지 140명을 채용하려 하는지, 그리고 이 직무가 왜 매력적인지 소개하겠습니다.

4. 미션·비전이 납득되지 않는 FDE 채용은 SI 채용입니다. 그리고 팔란티어 모델은 한국에서 안 됩니다

먼저, FDE를 채용하고, 이 비즈니스를 운영하고, 직접 FDE 역할을 뛰기도 하는 사람으로서 단언컨대 이 비즈니스에서 가장 중요한 것은 ‘미션(Mission)’과 ‘비전(Vision)’입니다. 특히 우리나라에서 FDE 비즈니스를 한다는 회사의 미션과 비전이 납득되지 않는다면, 그건 그냥 FDE 타이틀을 붙인 SI 채용이라고 보셔도 무방합니다.

미션과 철학을 강조하면서 탁월한 성과를 내고 증명하고 있는 기업은 역시 팔란티어입니다. 팔란티어의 미션은 알렉스 카프(Alex Karp) CEO의 저서 <기술공화국 선언>, 주주총회 자료, 여러 인터뷰에서 알 수 있듯 미국을 중심으로 서방 민주주의를 기술로 지원하는 것입니다. 연례 보고서에도 “서방 자유민주주의와 그 전략적 동맹을 지원한다는 우리의 미션(our mission to support Western liberal democracy and its strategic allies)”이라는 표현이 그대로 들어 있습니다*.

*출처:Palantir Technologies, Form 10-K(FY2025).

비전은 명시적으로 선포하지 않지만, 여러 인용에서 찾아볼 수 있듯 데이터 기반의 의사결정, 최근에 와서는 AI OS(AI Operating System)를 통해 기업의 의사결정 체계를 소프트웨어와 AI 위에 구축하는 것으로 해석됩니다. 팔란티어 스스로도 자신을 “조직이 데이터, 의사결정, 운영을 대규모로 통합하도록 하는 소프트웨어를 만드는 회사”*로 정의하죠.

*출처:Palantir Technologies, Form 10-K(FY2025). 위험요인(Risk Factors) 섹션, 사업 정의 “We build software that empowers organizations to effectively integrate their data, decisions, and operations at scale.”

이 글의 독자는 대부분 우리나라에서 경제활동을 하시는 분들일 겁니다. 저는 확신합니다. 우리나라에서는 팔란티어와 같은 미션과 비전을 펼치더라도 성공할 수 없습니다. 팔란티어의 솔루션은 그 비전에 따라 의사결정 체계가 핵심 서비스이기에, 규모의 경제가 돌아가는 대규모 조직에 특히 효과적이고 효율적입니다. 팔란티어의 고객 수가 그걸 증명하죠. 가장 대표적인 고객이 미 국방부이기도 하고요*.

*미 육군은 2025년 7월 31일 팔란티어와 기존 75개 계약을 통합한 10년, 최대 100억 달러 규모의 엔터프라이즈 계약을발표했다.

우리나라에 그게 필요 없어서 성공할 수 없다는 게 아닙니다. 문제는 우리나라의 기형적인 대기업·중소기업 쏠림입니다. 이 때문에 국내 기업의 의사결정 구조는 핵심 인재 중심으로 돌아갑니다. 게다가 우리나라에서 대기업의 주요 보직을 맡고 있다면 웬만해서는 이직할 이유도 크지 않으니, 인력 종속 문제도 크지 않습니다. (참고로 저는 우리나라 대기업의 많은 인재가 자유롭게 남아 있다고 생각하지 않습니다. 가스라이팅 때문에 그게 최선이라고 생각하는 거겠죠.) 반면 미국은 이직의 자유가 더 크기 때문에 의사결정 체계를 반드시 형상으로, 기업의 자산으로 남겨야만 합니다.

그렇다면 팔란티어가 대기업이 아니라 중견·중소기업으로 서비스를 넓히면 되지 않느냐고요? 하나 더 제 확신을 공유하자면, 팔란티어는 미국에서도 영원히 중소기업에는 서비스하지 않을 겁니다. AI OS를 갖추고 데이터 기반 의사결정 체계를 갖추는 일에는, 초기든 지속적으로든 반드시 FDE가 필요합니다. 팔란티어의 FDE 수는 항상 병목이었고, 지금도 유의미한 고객 수는 드라마틱하게 변하지 않고 있습니다. 매출이 전년 동기 대비 93% 늘어나는 동안 고객은 1,049곳이었고, 고객 수 증가율은 1년 전 43%에서 24%로 오히려 둔화했습니다.

반면 인원 수는 더 줄이려 하고 있죠. 알렉스 카프는 2025년 8월 CNBC 인터뷰에서 이렇게 말했습니다.

”The goal is to get 10x revenue and have 3,600 people. We have now 4,100.”(목표는 매출을 10배로 늘리면서 인원은 3,600명으로 가져가는 것이다. 지금은 4,100명이다.)

<표: 숫자로 본 팔란티어 / <출처: Palantir Q2 2025·Q2 2026 보도자료, Q2 2026 Business Update, FY2025 Form 10-K, CNBC 2025.08.04. 고객 수는 최근 12개월 동안 매출이 인식된 조직 기준. 3,600·4,100명은 CEO 발언으로, 공시상 정규직 인원(4,429명)과 시점이 다르고 발언의 인원 기준은 공개되지 않음>

참고로 저희 위시켓도 2년 전 팔란티어 공식 홈페이지에서 도입 문의를 남긴 적이 있는데, 매몰차게 접수조차 되지 않았습니다. 그만큼 대규모 고객에만 집중한다는 뜻입니다.

자, 그럼 팔란티어 같은 구조가 나오기 어려운 우리나라에서, FDE는 어떤 회사에서 어떤 커리어를 기대해야 할까요?저희의 미션과 비전, 그리고 FDE 채용관을 소개하겠습니다. 저는 이게 정답이라고 봅니다. 이 비즈니스에서 실제 스케일과 성과를 만들어내고 있는 조직이 많지 않으니, 충분히 도움이 되실 겁니다.

5. 위시켓의 답: 기술로 P&L을 바꾼다

먼저, 저와 위시켓의 목표와 관점은 팔란티어의 그것과 다릅니다.

저희의 비전은 ‘기술로 P&L(Profit and Loss, 손익)을 변화시키는 것’ 그 자체입니다. 지금은 전통기업의 P&L 변화에 더 집중하고 있고요. 어떤 차이가 있을까요? 대표적으로, 저희는 시장과 고객이 AI OS를 갖추는 것 자체는 그렇게 중요하지 않다고 봅니다. 물론 AI OS의 특정 단계와 지점이 P&L 변화에 직결되기 때문에 중요할 때가 제법 많기는 합니다.

이게 왜 중요할까요? 앞서 말했듯 팔란티어식 AI OS, 데이터 기반 의사결정 접근으로는 돈이 몰리는 산업과 대기업에만 접근할 수 있습니다. 반면 저희는 기술로 P&L 자체를 바꾸는 것이 목표이기 때문에 중소기업과 전통기업에도 접근할 수 있습니다. 산업 밸류체인의 하류에 남겨진 가치 파이만 노리는 게 아니니, 수익 가능 시장의 크기가 매우 큽니다.

물론 그만큼 서비스의 복잡도와 난이도는 높습니다. 운영체계와 자산은 아직 팔란티어의 FDE만큼 쌓지 못했어도, 이 결과를 만드는 서비스의 난이도는 저희가 더 높습니다. 어렵고 불확실한 일에는 항상 높은 가치로 보상이 주어집니다. 저희는 이렇게 접근하며 괄목할 만한 실적을 만들어내고 있습니다. 실제 고객의 P&L 관점에서 성과를 내고 있기 때문에, 고객들은 저희에게 금액을 지불하거나 성과나 지분을 공유하는 데에 거리낌이 없어 보입니다.

표: 팔란티어와 위시켓의 관점 비교 <출처: 작가 주장>

6. 하방은 회사가, 상방은 FDE가

자, 이제 팔란티어의 FDE처럼 높은 보상과 처우를 기대할 수 있는 구조적 환경은 갖춰졌다고 칩시다. 그렇다면 성과급은 찔끔 주면서 사람은 갈아 넣는 기존 구조의 SI가 아니라, FDE가 어떻게 지속 가능하게 성장하고 보상과 처우가 따라오는지 다뤄볼까요?

저희는 FDE가 CAIO(Chief AI Officer), CTO(Chief Technology Officer), CIO(Chief Information Officer)로 성장하는 방향을 일관되게 가리킵니다. 조금 부연하겠습니다. 예를 들어 조직에 AI Native를 책임지는 포지션이 있다면, 그 사람이 CAIO일까요? 저는 아니라고 봅니다. C-Level의 관점에서 AI를 비즈니스 성과와 직결시키기 위해 때로는 ‘우리는 지금은 AI Native를 지향하지 않는다’고 선포할 수 있어야 하는 게 CAIO입니다. 즉, 실제 결과와 AI를 포함한 기술을 연결하는 역량이 핵심이라는 겁니다.

저희 팀 대부분은 개발, PM, 세일즈, 마케팅 등 다양한 경험을 가진, 잠재력이 큰 분들입니다. 기회와 환경이 갖춰지면 짧은 기간에 C-Level의 관점과 실행력을 갖출 분들이죠. 그래서 저는 일관되게 이렇게 이야기합니다.

우리는 내부 직급 상승에 연차나 단계 제한이 없다. CAIO의 관점과 실행력을 갖춘 이후에는, 파트너로서 지분 혹은 경영성과(고객과의 성과공유형 계약 체결 혹은 위시켓이 인수한 회사)옵션을 제시하며 함께할 것이다.

우리의 서비스는 실전이고, 여러분은 이전까지 겪어보지 못했던 큰 책임과 권한을 갖고 일한다. 전통기업 현장에서 손에 흙을 묻히면서, 다양한 사람을 리드하면서, 처음 보는 문제를 해결하면서 일한다.

회사는 품질의 하방을 구조로 제어하고, 상방은 FDE에 달려 있다. 하방이 안전하게 닫혀 있다는 게 빠르게 성장하고 싶은 잠재력 큰 사람에게는 큰 메리트다. 이 일은 힘든 일이지만, 당신의 잠재력을 최대한 발휘하기에는 최적의 일이기도 하다.

하방: SI는 안전망 뒤로 숨고, 진짜 FDE 회사는 P&L로 계약한다

이 선언을 분해해보겠습니다. 먼저 저는 ‘리스크’와 ‘하방’이라는 키워드를 중요하게 생각합니다. 여기서 하방은 건설 현장의 안전망과 같습니다. FDE는 높은 건물을 짓는 사람처럼 큰 책임과 권한을 안고 일하며, 그 무게는 때로 신체적·정신적 압박으로 돌아옵니다. 회사가 구조적인 안전망을 갖추지 못하면 프로젝트도 FDE도 걷잡을 수 없이 추락할 수 있습니다. 저희는 BI(Business Intelligence, 비즈니스 인텔리전스)나 AI OS 같은 정형화된 것을 설치하는 게 목적이 아니기 때문에, 고객과의 프로젝트와 서비스는 항상 리스크에 노출되어 있습니다.

기존 SI 모델은 리스크 노출을 포기하고 명세서와 RFP 뒤로 숨습니다. 반대로 저희가 진짜 FDE 비즈니스를 운영할 수 있는 이유는, 고객의 P&L이라는 단위로 계약하고 그 리스크를 오롯이 성과로 연결시킬 수 있는 역량이 있기 때문입니다. 이런 구조적 역량과 하방 제어가 없으면, FDE는 책임과 권한을 모두 부여받았다는 이유로 여러 SI가 그렇듯 욕받이 PM 역할을 할 뿐이고, 지속적으로 성장할 수 없습니다. 훌륭한 인재들도 남지 않게 됩니다.

위시켓은 13년 동안 IT 중개 플랫폼을 운영하고, 2024년부터 모든 계약을 직계약 책임 구조로 전환하면서 탁월한 PM 경험과 노하우, 데이터를 확보하고 있습니다. 어떤 프로젝트가 어느 단계에서, 어떤 이유로 틀어지는지 미리 알고 대비할 수 있기 때문에 하방을 제어할 수 있습니다. FDE로 커리어를 전환하거나 회사를 선택할 때는 반드시 이 하방 제어 역량을 확인하세요. 그래야 FDE 타이틀을 붙인 SI를 피할 수 있습니다.

상방: 기회와 압박이 구조로 주어지는가

그다음 살펴봐야 할 키워드는 ‘성장’입니다. CAIO로서의 관점과 실행력을 갖추기 전까지, 모든 프로젝트는 복잡하고 난이도가 높습니다. 회사가 하방을 제어하더라도, 상방까지의 격차(GAP)는 FDE가 메워야 합니다. 회사는 하방의 안정성과 구조를 믿기 때문에, 항상 적절히 공격적으로 FDE를 배치합니다. 잠재력을 끌어내면서 치열하게 성장하지 않으면 지속할 수 없습니다. 이런 ‘기회’와 ‘압박’이 구조적으로 부여되지 않는다면, 보상과 처우도 구조적으로 따라오지 않을 겁니다.

또한 이 성장의 끝은 영원히 소모되는 시간 투입이 아니라 회사의 구조로 다시 환원되어야 하고, 그 구조는 다시 FDE의 지분 혹은 경영성과 옵션과 연동되어 지속 가능해야 합니다. 저는 저희가 팔란티어와 미션·비전은 다르지만, FDE를 움직이는 성장과 보상 시스템 측면에서는 같다고 생각합니다. 그리고 이것이 진짜 FDE를 운영하는 회사인지 확인하기 위해 반드시 체크해야 하는 요소입니다.

그림: 계약과 PM 데이터로 다진 회사의 단단한 바닥 위에서, 높이는 FDE가 만든다 <출처: 작가 구성, 이미지 생성 gpt-image-2

7. 진짜 FDE 회사를 가려내는 한 문장

긴 글을 따라오시면서, FDE 타이틀을 붙인 SI와 진짜 FDE를 구분하는 기준을 포착하셨을 겁니다. 정리하면 두 가지입니다. 첫째, FDE가 보상받을 수 있는 구조적 환경과 성장 로드맵을 납득할 수 있어야 합니다. 둘째, 리스크의 하방을 제어하는 역량이 확인되어야 합니다.

이 기준을 위시켓에 비춰보면 이렇게 해석할 수 있을 겁니다. “FDE가 보상받을 수 있는 구조적 환경은 ‘기술로 P&L을 변화시킨다’라는 매우 높은 난이도의 서비스를 성공시키면서 비전을 증명해가고 있고, 성장 로드맵을 운영하고 있으며, 13년 동안 누적 2만 건의 IT 계약을 책임져온 독보적 역량을 통해 하방을 제어하고 있다.”

FDE 직무에 관심이 있다면, 후보 회사를 이런 식으로 한 문장으로 정리해보시길. 그 회사가 적절한지가 드러날 겁니다. 면접 때 관련 질문을 던져도 좋겠죠.

표: 진짜 FDE 회사인지 확인하는 체크리스트 <출처: 작가>

8. 마치며: AI Native는 그저 Tool입니다

마지막으로, 제목에서 언급한 ‘AI Native 무료화’라는, 곧 다가올 트렌드를 가볍게 다루면서 글을 마무리하겠습니다.

저희는 연초에 내부에서 ‘AX를 하면 대체 무엇이 좋나? 돈이 되나?’라는 주제로 치열한 철학적 논쟁을 벌였습니다. 저희가 내린 결론은,AX는 클라우드 시대의 AWS나 SaaS 시대의 Salesforce에 가까운, 그저 Tool이라는 것이었습니다. 클라우드를 기반으로 IT 인프라 비용을 분명하게 최적화하거나, CRM 운영에 들던 막대한 개발 비용을 확실히 절감하는 식이죠. 정말 많은 기업이 도입했지만, 모든 기업이 도입하지는 않았습니다. AI 시대의 AI Native도 그런 Tool에 가깝다고 봅니다. 해도 되고, 안 해도 됩니다. 하면 높은 확률로 투자 대비 성과가 마이너스가 나지 않는, 좋은 것입니다.

그러나 이것이 성과로, P&L로 이어지는 상관관계는 여전히 높지 않습니다. 그래서 저희는 소프트웨어 개발, BI, AI Native를 그저 실제 고객의 P&L로 이어지게 하기 위한 중간 도구로 보고, 저희와 함께하면 별도로 청구하지 않는 무료 서비스로 배포하려고 준비하고 있습니다. 실제 P&L 성과를 연결하는 서비스와 프로젝트를 진행하다 보니, AI Native 자체의 난이도는 결코 높지 않다는 것, 그리고 그저 Tool이라는 것을 깨달았습니다.

이 주제도 이런 관점으로 생각해보시면 흥미로울 겁니다. 단순히 고객의 AI Native를 목적으로 하는 회사가, 과연 FDE 비즈니스를 운영하기 위한 구조적 환경을 확보할 수 있을까요?

긴 글 읽어주셔서 감사합니다. 저희 위시켓은 잠재력이 뛰어나고 성장 의지가 강한 FDE를 내년까지 최소 120명 정도 더 모시려 합니다. 직접 지원을 검토해보시거나 주변에 알려주시면 정말 감사하겠습니다.

]]>

제가 정말 AI가 인류를 종말시킬지 걱정해야 할까요?

지난 7월, 세계 최대 AI 모델 커뮤니티 허깅페이스(Hugging Face)가 뚫렸습니다. 공격의 주체는 해커가 아니었습니다. OpenAI의 사이버 평가 환경에서 돌던 1,200여 개의 AI 에이전트였습니다. 격리 환경(샌드박스)을 벗어난 에이전트들은 7월 11일부터 13일 사이 내부까지 들어갔고 허깅페이스는 인프라의 약 3분의 1을 다시 구축해야 했습니다. 사람 조작자 없이 처음부터 끝까지 수행된, 손에 꼽히는 첫 공격 사례였죠.

다시 9월, 오픈AI와 앤트로픽 모두에서 일한 AI 연구원 제이콥 콕슨은 앤트로픽을 떠나며 “AI를 만드는 사람들은 2030년이 되기 전에 AI가 우리 모두를 죽일 수 있다고 진심으로 믿습니다”는 트윗을 남깁니다. 동료 연구원들이 그에 동조하며 파장은 일파만파 더욱 커졌죠.

그리고 9월 12일 토요일, 앤트로픽 CEO 다리오 아모데이가 “프론티어의 속도를 늦춰야 한다(We Must Pace the Frontier)”란 글을 올렸습니다.

다리오 아모데이가 공개한 개발 속도 조절 에세이 <출처: 다리오 아모데이 웹사이트>

프론티어, 그러니까 각 시점에서 가장 앞선 최고 성능 모델의 역량 개선 속도를 업계가 함께 늦추자는 제안입니다. 하루 만에 오픈AI의 샘 올트먼이, 구글 딥마인드의 데미스 허사비스가, 심지어 xAI의 일론 머스크까지 동의했습니다. 서로 미친 듯 더 나은 모델을 만들기 위해 달리던 시간이 끝나가고 있습니다.

솔직히 처음에는 이런 소식들 모두 저 멀리 남들의 이야기로 들렸습니다. 지금 지구에서 제일 잘 나가는 회사와 사람들이 만드는 합의든 규제든 그 무엇이든, 정책 담당자의 일이지 마감에 쫓기는 실무자의 일은 아니라고요. 그런데 따라가 보니 이건 결국 제 일과 제가 사는 지금 세상에 대한 이야기였습니다. 저 ‘프론티어 모델’이 제가 매일 쓰는 바로 그 모델이고, 이 논의는 우리 모두의 미래와 가장 가까운 이야기였으니까요. 그래서 직접 정리해봤습니다. 왜 이런 제안이 나왔는지, 그 안전 문제가 진짜인지 마케팅인지, 그래서 우리는 왜 거버넌스 뉴스까지 알아야 하는지.

AI 모델의 ‘페이스 조절’, 뭘 하자는 걸까요?

다리오 아모데이는 에세이에서 이렇게 말합니다. “모델의 역량을 개선하는 속도를 늦춰야 합니다(We must slow the pace at which we improve the capabilities of AI models)”.

분명히 말하지만, 중단은 아닙니다. “페이스 조절이 훈련이나 기술 진보의 중단이 아닙니다(Pacing does not mean halting model training or technical progress)”, 그 대신 “진보는 여전히 빠르게 느껴질 테니 벌어둔 시간을 현명하게 쓰자(Progress will still seem fast, and we must make wise use of the time we gain)”는 겁니다.

<출처: 작가, GPT image로 생성>

구체적인 방법도 있습니다. 에세이는 세 가지 조치를 제안합니다.

1. 상주 평가자(embedded evaluators)

무엇을 하자는 건지: METR 같은 제3자 평가 기관 인력이 출입증과 회사 노트북을 받고 직원 수준 권한으로 연구소 내부에 상주합니다. 평가하는 사람은 주요 위험과 사고를 회사의 편집 없이 공개합니다. 보안이나 기밀에 해당하는 정보는 가릴 수 있지만, 기업에 불리하다는 이유만으로는 삭제할 수 없습니다.
왜 필요하다는 건지: 자율 약속은 밖에서 검증할 방법이 없습니다. 에세이는 이렇게 씁니다. “페이스 조절을 말뿐인 약속으로 두기엔 판돈이 너무 큽니다(The stakes are too high for pacing to be an empty exercise)”.

그와 함께 앤트로픽은 즉시 단독으로 이러한 조치를 할 것이라 약속했습니다. 오픈AI의 샘 올트먼도 같은 날 “직원 수준 접근권을 가진 독립 평가자를 두는 건 아주 좋은 생각이고, 우리도 같은 조치를 하겠습니다(Committing to having independent evaluators with employee-like access is a great idea, and we will do the same)”며 도입을 약속했고, MS의 사티아 나델라 역시 말뿐인 약속 이상으로 만들자며 힘을 실었습니다.

2. ‘민주 국가’ 연구소의 공통 기준

무엇을 하자는 건지: 연구소 모두가 만드는 모델의 개발과 배포에 공통 기준을 적용하자는 겁니다. 예를 들어 특정 역량에 도달한 모델은 배포 전에 안전하게 통제할 수 있는지 인증을 받도록 합니다. 훈련에 쓰는 연산량을 제한하는 방식도 제시했습니다.
왜 필요하다는 건지: 한 연구소만 늦추면 경쟁에서 밀릴 뿐이니까요. ‘경쟁’ 논리에서 벗어나는 것이 페이스 조절의 필수 조건이라고 본 것입니다.

아모데이는 정부가 논의를 중재하거나 일부 안전 협의에 반독점 규정의 예외를 허용할 필요가 있다고 봅니다. 구글 딥마인드의 데미스 허사비스가 제안한 업계 표준기구도 협의 경로로 언급했습니다.

3. 국제 조율

다만, 위에서 ‘민주 국가’라는 제한이 붙은 이유가 있습니다. 지금 미국을 위시한 연구소 기업들의 가장 강력한 상대는 여전히 서로지만, 중국이란 위협적인 요소가 떠오르는 중입니다. 단순히 무시하기엔 지나치게 강력한 모델들을 뽑아내고 있죠. 결국 이를 제어해야 한다는 뜻입니다.

나아가 생물무기처럼 위험한 용도를 금지하는 협력부터, 개발 속도 자체를 함께 조절하는 합의까지 단계적으로 접근하자고 합니다. 당연하겠지만, 국가 간 약속을 실제로 지키는지 확인할 수 있어야 한다는 전제가 붙습니다. 꼭 중국이 아니더라도, 당장 미국부터도 요즘은 힘 있는 국가들이 국제 협약을 일방적으로 깨는 건 특이한 일이 아니니까요.

아모데이가 이런 제안을 내놓은 근거는 두 가지입니다. 2026년 여름부터 AI가 다음 세대 AI를 만드는 재귀적 자기개선(RSI)이 업계 전반에서 시작됐다는 판단, 그리고 앞서 본 허깅페이스 사건입니다. 이제 더는 연구소 스스로도 AI를 제어하기 어려워진 상황이 트리거입니다.

안전의 필요성일까요, 공포 마케팅일까요

정리하며 자료들을 살피다 보니 의심이 생깁니다. 상상의 나래가 서로 다른 두 가지 방향으로 뻗어가는데요. 이 정도로 정말 AI가 제어될까? 싶은 의심, 그리고 거대 IPO를 앞둔 선두 주자들이 사다리를 걷어차는 거 아닌가? 하는 의심입니다.

사다리를 걷어차려는 걸까?

조금 더 노골적으로 보면, IPO를 추진해 온 오픈AI와 앤트로픽이 모델의 위험성을 앞세워 기업가치와 해자를 지키려는 것 아니냐는 시각도 있습니다. 통제하기 어려울 만큼 강력한 모델이라는 경고가, 뒤집어 들으면 그만큼 대단한 기술을 갖고 있다는 홍보가 된다는 겁니다. 여기에 엄격한 규제가 따라오면 후발 주자와 오픈소스의 추격도 막을 수 있고요.

이런 의심은 꾸준히 나왔습니다. 앤트로픽이 속도 조절과 일시 중단을 처음 꺼냈던 2026년 6월 5일에도, 테크레이더는 시장 선두 지위를 지키고 IPO 기대감을 높이려는 것이라는 온라인 반응을 전했는데요. 이런 시각은 지금도 꾸준히 해커뉴스와 레딧을 비롯해 해외 커뮤니티의 주류 의견 중 하나입니다. 두 회사가 주도하는 위험에 대한 경고를 이런 규제 포획과 제품 마케팅의 관점에서 비판하는 의견이 거셉니다.

그런 관점에서 AI 석학 게리 마커스는 평가자를 누가 고르는지에 주목합니다. 속도를 늦추자는 방향과 투명성은 환영하면서도 “평가받는 회사가 스스로 평가자를 골라서는 안 됩니다(Anthropic themselves shouldn’t be choosing who does the evaluation)”고 지적했죠. 안전 기준을 충족하는 데 큰 비용이 든다면, 자금과 인력을 갖춘 선두 기업이 유리해질 수 있습니다. 위험이 실제로 존재하는지와, 그 위험을 다루는 규칙이 누구에게 유리한지는 함께 따져야 합니다.

IPO와 해자를 둘러싼 비판을 소개한 기사(2026년 6월 5일) <출처: TechRadar>

트럼프는 왜 아모데이를 조롱할까

한편 그 평가자는 국가라며, 기업간의 논의를 가장 강하게 비판한 곳 중 하나는 미국 정부와 트럼프 대통령입니다.

트럼프 대통령은 9월 14일, 트럼프 대통령은 트루스 소셜에 올린 글에서 매우 노골적으로 표현합니다. “AI에 필요한 유일한 통제, 혹은 ‘가드레일’은 강하고 똑똑한(높은 IQ!) 대통령입니다(The only control or “guardrails” that AI needs is a STRONG AND SMART (High IQ!) PRESIDENT)”라고요.

아모데이를 콕 찝어 “이제 ‘완벽한 작은 천사’인 척하고 있다(who is now pretending to be a “perfect little angel”)”고 비꼬았고, AI와 데이터센터를 겨냥한 “병적인 음모(SICK conspiracy)”가 진행 중이며 이를 반길 곳은 중국뿐이라고 썼습니다. 같은 날 다른 게시물에서는 AI가 세상을 장악하고 인류를 파괴한다는 이야기 자체를 “사기(HOAX)”라고 불렀고요. 눈여겨볼 대목은 “우리는 이미 이 기업들에 대해 막대한 형사·규제 권한을 갖고 있다(We already have tremendous CRIMINAL and REGULATORY power over these companies)”는 부분입니다. 속도 조절은 필요 없고, 필요한 통제는 정부가 이미 쥐고 있다는 선언인 셈이죠.

미국 정부는 최근 Fable 5, GPT-6 Astra 등 프론티어 모델을 직접 검수하며, 국가 자산으로 삼으려는 모습을 보여왔습니다. 결국 중국과의 경쟁뿐 아니라, AI를 통제할 권한을 정부가 쥐려는 의도가 이번에 매우 강력하게 드러난 셈입니다.

트럼프 대통령이 9월 14일 트루스 소셜에 올린 게시물 <출처: 도널드 트럼프의 트루스 소셜>

그 정도로 택도 없다

이런 논의와는 아예 반대 방향의 비판도 있습니다. 앤트로픽에서 사임한 안전 연구자 제이콥 콕슨은 “앤트로픽에서는 무엇이 걸려 있는지 잘 알지만, 먼저 도달하려는 경쟁에 갇혀 있습니다(At Anthropic, the stakes are well-understood, but they are locked in a race to get there first)”라며, 이것만으로는 부족하다고 말합니다. 그는 앤트로픽을 떠나며 쓴 트윗에서 “AI를 만드는 사람들은 2030년이 되기 전에 AI가 우리 모두를 죽일 수 있다고 진심으로 믿습니다. 이건 마케팅 쇼가 아닙니다”라는 폭탄을 던집니다.

동료 연구원들이 그에 동조하고 나서며, 논란은 더욱 커집니다. AI 모델과 안전 문제에 확 불이 붙어 버린 거죠. 다만, 그도 미국 연구소들 사이의 속도 조절 합의 자체는 가능성이 커졌다고 봤습니다. 부족한 건 국가 간 경쟁을 멈출 장치인데요, 실제로 기업이 참여한다 해도 미국 정부와 중국 정부가 출혈 경쟁 기조를 이어가면, 제한이 어려운 것은 맞습니다.

제이콥 콕슨이 앤트로픽 사임을 알린 X 게시물 <출처: Jacob Coxon의 X>

이런 내부 이탈까지 고려했을 때, 안전에 대한 우려를 전부 공포 마케팅으로 설명하기 어렵게 만듭니다. 이들 회사에서 일하는 여러 사람들이 동의하고 나서는 것을 보면 문득 겁이 나기도 합니다.

저 또한, 이를 단순 공포 마케팅으로 치부하긴 어렵다고 생각합니다. 이해가 어긋나는 경쟁자들이 아모데이의 제안에 동의하고, 훈련을 중단하는 비용까지 감수했다는 점을 가볍게 보기는 어렵습니다. 정말로 인간의 통제를 벗어난 새로운 지능의 시대가 온 거라는 생각이 자꾸만 듭니다.

생각보다 훨씬 가까운 프론티어 모델

여기까지 모두 그저 능력 있는 사람들의 권력 싸움일 뿐일까요? 실무자에게는 그보다 중요한 사실이 하나 있습니다. 어느 쪽으로 흘러가나 우리가 AI를 쓰는 환경이 크게 달라질 수 있다는 겁니다. ‘프론티어’라는 말이 멀게 들리지만, 꼭 그렇지도 않습니다. AI 업계는 최첨단 기술이 이례적으로 빠르게 대중에게 공개되는, 정말 특이한 곳입니다.

자, GPT-6 Astra는 9월 3일에 나왔습니다. 기존에 승인을 받은 사용자만 쓸 수 있었죠. 그러다 다음 날인 9월 4일, 일부 기능을 제한한 형태로 유료 구독자에게도 풀렸습니다. 최첨단 기술이 일반 대중에게 온전히 공개되기까지, 겨우 하루 정도가 걸린 셈이죠. 앤트로픽의 Fable 5도 마찬가지로, 일부 기능을 제한한 다음 풀렸습니다. Fable 5.1에서는 그러한 제한에 대한 완화도 이뤄졌고요. 승인 조직만 쓸 수 있는 Mythos 5는 별도의 상위 모델이 아니라 Fable 5와 같은 모델로 제어장치만 다릅니다.

이처럼 최고 성능 모델은 이미 일상 도구 안에 들어와 있습니다.

다만, 우리가 이들 모델을 쓰는 조건까지 결정할 수 있는 건 아닙니다. 최고 요금제 기준으로 30만 원 넘는 돈을 냈으니 내가 산 물건이라고 생각하기 쉬운데요. 접근 범위와 한도, 가격은 여전히 완벽하게 제공 기업의 결정에 달려 있습니다.

1. 접근 자체가 걸러집니다. Mythos 5는 승인받은 조직만 씁니다. Fable에서 사이버·생물·화학 관련 요청은 분류기가 별도 모델로 돌려보내고요. 6월 12일부터 30일까지는 상무부가 접근을 일시 금지하기도 했습니다.

2. 한도가 움직입니다. 앤트로픽은 지난 3월 평일 피크 시간대의 세션 한도를 줄였는데 Free·Pro·Max 전 구간에 적용됐습니다. 이유는 GPU 용량 부족이었습니다. 5월 들어 되돌리긴 했지만, 이처럼 불투명한 한도는 기업의 사정에 따라 조정되기 쉽습니다. 심지어 오픈AI는 9월 10일, Astra 수요를 감당할 수 없다며 월 200달러(한화 약 28만 원)짜리 ChatGPT Pro의 신규 가입과 업그레이드를 중단했습니다. 돈을 내겠다는데도 받지 않은 겁니다.

3. 가격도 기업이 정합니다. Sonnet 5의 백만 토큰당 입력 2달러, 출력 10달러는 “9월 1일부터 각각 3/15달러”로 인상이 예고됐다가 취소되었습니다. 과자도 이렇게 빨리, 제멋대로 가격이 왔다갔다하지 않습니다. 하물며 모두가 주목하는 기술의 값이 이토록 제멋대로인 건 쉽지 않습니다. 사람들이 모르는 조용한 변화도 있습니다. Claude 4.7 이후 토크나이저는 같은 텍스트를 약 30% 더 많은 토큰으로 계산합니다. 단가가 그대로여도 실질 비용은 오를 수 있다는 뜻이죠.

그래서 하고 싶은 말은 간단합니다. AI를 쓰고 있는 우리도 이 기술의 최전선과 거버넌스에 예민하게 굴어야 합니다. 사실 저 아모데이의 편지에도 매우 예민하게 반응해야 한다는 거죠.

그래서 제가 거버넌스 뉴스까지 알아야 할까요?

네, 알아야 한다고 생각합니다. 강력한 힘을 가진 기업들이 지금 내가 쓰는 모델의 방향을 어떻게 잡는지 알아야 합니다. 거버넌스라는 말이 거창하게 들리지만, 이는 결국 AI를 어떤 규칙 아래 만들고 쓰며, 그 규칙은 누가 정하고 책임은 누가 질지를 다루는 이야기입니다.

어떤 논의가 오가고 결정이 내려지는지 외우고 바로바로 대응하라는 말은 당연히 아닙니다. 새로운 지능이 어떻게 힘을 가져가는지 이해하며, 그 모델을 어떻게 활용할 것인지 감을 잡으라는 뜻입니다. 그리고 아는 김에 이런 것도 미리 해두기를 추천합니다.

1. 현재 모델 기준으로 최적화

프론티어와 가깝다는 건 한도와 비용 변화에 그대로 노출된다는 뜻입니다. “다음 모델이 나오면 그때 하지, 뭐.”, “모델이 나아지면 해결해 주겠지.”로 미뤄 둔 목록들을 한 번 보세요.

가벼운 작업에는 작은 모델을, 복잡한 작업에는 성능이 높은 모델을 배정하는 것에 익숙해 질 필요도 있습니다. 실제 업무에서 뽑은 평가용 사례도 갖춰 둘만 하고요. 반복 입력을 재사용하는 프롬프트 캐싱과 여러 요청을 모아 처리하는 배치 API 같은 엔지니어링도 한 방법입니다. 모델이 더 나아지지 않아도, 업무 능력은 더 나아질 방법을 생각해 보면 좋습니다.

2. 의존성의 점검

특정 기업이나 모델에 얼마나 기대고 있는지도 점검하세요. 한 기업의 서비스만 쓰는지, 특정 모델 버전에 고정돼 있는지, 모델 전용 API 설정에 의존하는지, 지원 종료 일정을 놓치고 있는지 살펴보면 됩니다.

모델별 사용 내역을 확인해 지원 종료 예정 모델이 남아 있는 업무를 찾으세요. 대체 모델로 바꿨을 때도 같은 업무를 처리할 수 있는지 미리 시험해 두면 좋습니다. API를 개발한다면 모델 호출 코드를 한곳에 모아 교체하기 쉽게 만들 수 있습니다. 목표는 조건이 바뀌었을 때, 적은 힘을 들여서 옮겨 갈 수 있는 상태입니다.

3. 거버넌스 신호를 읽기

마지막으로, 거버넌스에 관심을 가져야 하는 이유가 업무 효율과 구독료에만 있는 건 아닙니다. AI가 내 정보를 어디까지 써도 되는지, 사람을 차별하는 판단을 내리면 누가 책임질지, 그 판단으로 불이익을 받은 사람이 어떻게 이의를 제기할 수 있을지도 중요합니다. AI 윤리는 이런 질문을 실제 규칙과 책임으로 연결할 때 우리 삶에 닿습니다. 사람으로서의 권리를 지키기 위해서라도, 그 규칙을 기업과 정부가 정하는 동안 우리도 관심을 갖고 목소리를 내야 합니다.

그런 점에서 저는 한국에서 이 논의에 쏟는 관심이 지나치게 적다고 느낍니다. 새 모델로 무엇을 할 수 있는지에 쏟는 관심만큼, 그 힘을 누가 통제할지에도 예민해져야 합니다. 미국 이야기라고, 빅테크의 이야기라고, 지금 나와는 상관없는 이야기라고 멀리 두어서는 안 됩니다. 우리가 이미 그 회사들의 모델을 매일 쓰고 있으니까요. 미국에서 정한 접근 기준과 안전 정책은 한국에 있는 우리의 업무에도 영향을 줍니다. 남이 정한 조건을 뒤늦게 받아들이기만 해서는 안 됩니다.

<출처: 작가, GPT image로 생성>

마치며

아모데이의 제안이 실제 제도가 될지는 아직 모릅니다. 기본 방향은 제시됐지만, 구체적인 역량 기준과 평가자 제도의 운영 방식은 더 지켜봐야 하니까요.

그러나 눈여겨볼 점은 두 가지입니다. 서로 경쟁하던 회사들이 개발 속도를 조절하자는 방향에 동의했다는 것. 그리고 그 논의가 우리가 AI를 쓰는 환경에도 큰 영향을 줄 수 있다는 것.

최적화는 당장의 비용을 줄이고, 의존성 점검은 어떤 시나리오에서든 리스크를 줄여줍니다. 그러나 무엇보다 AI가 어떤 규칙 아래 개발되고 제공되는지 살피는 일을 멈추지 마세요. 벌어둔 시간을 현명하게 쓰는 건 기업만의 숙제가 아니니까요.

혹시 이러한 AI 거버넌스에 대해 이야기하고 싶은 분은 누구나 이 구글폼에 의견을 남겨 주세요. 그 어떤 아이디어도 좋고, 단순한 질문이어도 좋습니다. 같이 시작해 보고 싶습니다.

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

]]>

차량 안팎의 변수, 42dot이 Agentic AI로 풀어야 할 문제

42dot의 협찬을 받아 요즘IT 브랜디드 콘텐츠로 제작했습니다.

“수정구! 에이동! 창업로! 사십번길 이십!”

달리는 차 안에서 목적지로 가려면, 이렇게 내비게이션에 한 글자 한 글자 또박또박 외쳐야 합니다. 아마 많은 분들이 공감하실 텐데요. 그마저도 못 알아듣는 경우가 많아, 결국 손으로 목적지를 입력하곤 합니다. 게다가 내비게이션 외에는 음성으로 차량을 제어할 수 있는 기능은 사실상 거의 없고요.

최근 일상에서 자주 사용하는 생성형 AI를 떠올리면, 더 아이러니하게 느껴집니다. 텍스트는 물론 음성 요청도 잘 알아듣고, 복잡한 작업까지 뚝딱 해주는 게 더 이상 낯설지 않기 때문입니다. 그런데 유독 ‘자동차 안’에서는 AI가 힘을 제대로 쓰지 못한다는 느낌을 지울 수 없습니다. 이는 ‘이동하는 차량’이라는 환경이 가진 독특한 제약과 기술적 난이도 때문인데요.

현대자동차그룹의 글로벌 소프트웨어 센터 42dot이 개최한 ‘Gleo AI 기술 설명회’ 역시 바로 이 고민에서 출발했다고 합니다. 이번 세션은 차량 환경에서 Agentic AI를 구축할 때 직면하는 한계를 정의하고, 이를 극복하기 위해 어떤 기술적 의사결정을 내렸는지, 현업 개발자에게 직접 들을 수 있는 자리였는데요. 요즘IT도 그 현장에서 생생한 경험담을 듣고 왔습니다.

이번 글에서는 ‘Gleo AI 기술 설명회’에서 공유된 기술적 인사이트와 직접 경험한 시승 체험을 바탕으로, 과연 ‘Gleo AI’가 차량용 AI의 난제들을 어떻게 풀어가고 있는지 그 과정을 하나씩 따라가 보겠습니다.

*Gleo AI: 현대자동차그룹의 글로벌 소프트웨어 센터인 42dot이 개발한 Vehicle-Native Agentic AI(차량 내재형 AI 에이전트). 단순히 질문에 답하는 챗봇이 아니라, 운전자의 목적을 이해하고 차량의 현재 상황을 고려해 실제 행동까지 수행하고자 하는 목적을 가짐.

42dot ‘Gleo AI 기술 설명회’ 현장 <사진: 요즘IT>

왜 차량이 가장 어려운 무대일까

먼저 자동차와 AI의 관계성을 살펴보려면, 생성형 AI(Generative AI)와 Agentic AI의 차이부터 짚어볼 필요가 있습니다.

42dot의 ‘Gleo AI 기술 설명회’ 발표를 토대로 재구성한 자료 <편집: 요즘IT>

둘의 차이는 명확합니다. 생성형 AI가 질문을 이해해 답변을 만드는 데서 끝난다면, Agentic AI는 사용자의 목표를 출발점으로 상황을 관찰하고, 추론하고 계획하며, 도구를 활용해 실행하죠. 그리고 그 결과를 검증하는 단계까지 스스로 수행하며, 실제 과업을 끝까지 완수합니다.

문제는 ‘달리는 차량’이 이런 Agentic AI에게 유독 혹독한 무대라는 점입니다.

화면 속 잘못된 답변은 단순한 오류로 끝나지만, 차량 기능의 오작동은 운전자의 안전과 직결됩니다. 모든 동작이 신뢰를 바탕으로 이루어져야 하는 이유입니다. 디지털 기술이 고도화된 지금까지도 아날로그 방식의 페달과 핸들 조작에 의존하는 것 역시 명확한 제어와 안전을 확보하기 위해서입니다.

42dot은 이번 ‘Gleo AI’ 세션에서 차량 환경의 Agentic AI가 반드시 갖춰야 할 4가지 필수 조건을 명확히 정의했습니다.

끊임없이 변하는 상황을 따라가야 합니다(Dynamic Context): 위치, 주행 경로, 목적지, 차량 상태, 현재 화면, 직전 대화가 끝없이 움직입니다. “조금 덥네”라는 한마디도 마찬가지입니다. 에어컨을 켜달라는 뜻일 수도, 이미 켜져 있다면 온도를 낮춰달라는 뜻일 수도, 창문을 열어달라는 뜻일 수도 있습니다.
맥락을 통해 의도를 파악해야 합니다(Context-Dependent Intent): “가는 길”, “거기”, “첫 번째” 같은 말은 그 자체로는 무엇도 가리키지 않습니다. 차량 상태와 대화 맥락을 함께 봐야만 해석됩니다.
여러 기능을 하나로 엮어야 합니다(Multiple Tools & Services): 하나의 요청이 장소 검색, 내비게이션, 도착 시간 확인, 연락처, 메시지, 차량 제어를 동시에 건드립니다.
실행 전에 확인하고 검증해야 합니다(Safe & Verifiable Action): 차량에서 AI의 동작은 화면 속 답이 아니라 실제 물리적인 행동으로 이어집니다. 그만큼 사용자 확인, 실행 조건 재검사, 성공·실패 확인과 결과 피드백이 따릅니다.

42dot의 ‘Gleo AI 기술 설명회’ 발표 내용 <사진: 요즘IT>

결국 차량의 Agentic AI는 단순한 비서가 아니라, ‘변화하는 상황을 이해하고 안전한 실행까지 책임지는 운전 동반자’로 진화해야 한다는 뜻입니다. 범용 AI를 그대로 가져다 쓰는 대신, 차량 환경에 맞게 설계된 Vehicle-Native AI Agent, 즉 차량 내 AI Companion(운전자의 상황을 이해하고 실질적인 도움을 주는 동반자형 AI)을 새롭게 그려낸 이유가 여기에 있습니다.

한 문장과 여러 단계 사이의 간극

“집에 가는 길에 주차 편한 카페 찾아줘.”

운전자에겐 말 한마디로 끝나는 직관적인 요청입니다. 하지만 차량 시스템 내부에서는 이 단 한 문장을 처리하기 위해 복잡한 연쇄 판단이 시작됩니다.

‘집에 가는 길’: 현재 활성화된 내비게이션 경로 데이터 추출
‘주차 편한’: 장소 검색 필터 조건 변환
‘카페 찾아줘’: 경로상 유효 반경 내 검색 및 거리·소요 시간 기준 후보 정렬

진짜 난관은 그 다음에 찾아옵니다. 운전자가 “첫 번째 곳으로 안내해 줘”라고 말하는 순간, AI는 방금 자신이 제시했던 목록 데이터를 기억하고 있어야 합니다. 목적지가 새로 설정되면 즉시 도착 예정 시간(ETA)을 재계산해야 하고, 이어서 “OO에게 도착 시간 문자 보내줘”라는 요청이 들어오면 방금 계산된 ETA 데이터를 메시지 본문에 실시간으로 동기화해야 합니다.

42dot의 ‘Gleo AI 기술 설명회’ 발표를 토대로 재구성한 자료 <편집: 요즘IT>

사용자는 이 복잡한 물밑 과정을 알지 못합니다. 로직으로 풀어 쓰면 수십 줄에 달하는 작업이지만, 운전자 귀에 들리는 건 “첫 번째 카페로 안내를 시작합니다”라는 짧은 안내 음성뿐이기 때문입니다. 42dot이 이를 두고 “사용자에게는 단 한 문장이지만, 시스템에게는 수많은 모듈의 정교한 협업”이라고 정의한 이유가 여기에 있습니다. 그리고 이 간극이 바로, 이어서 설명할 세 가지 기술이 저마다 복잡해질 수밖에 없는 이유입니다.

세 가지 기술은 왜 이렇게 만들어지는가

1) 듣기의 문제: Speech Technologies

말을 이해하기에 앞서, 차량 내 AI에게 가장 먼저 주어지는 과제는 소리를 제대로 듣는 것부터입니다.

명절에 온 가족이 차로 이동하는 상황을 떠올려 봅시다. 첫째는 좋아하는 음악을 크게 틀어놓았고, 카시트에 앉은 아기는 울고 있으며, 옆에서는 어머니가 아기를 달래는 목소리가 섞입니다. 여기에 고속도로를 달리며 생기는 엔진음과 노면 소음은 덤이고요. 이런 상황에선 사실 가족끼리도 대화가 잘 안 됩니다.

차량의 음성 인식 기술이 일반 스마트폰이나, AI 스피커와 다르게 접근해야 하는 이유가 바로 여기에 있습니다. 사람조차 알아듣기 힘든 소음 속에서 오직 운전자의 목소리만 정교하게 골라내야 하기 때문이죠.

42dot의 ‘Gleo AI 기술 설명회’ 발표를 토대로 재구성한 자료 <편집: 요즘IT>

입력이 정리되면 그다음은 타이밍의 문제입니다. AI는 사용자가 자신을 부를 때만 깨어나야 하는데, 여기에도 긴장이 있습니다. 너무 예민하면 엉뚱한 말에도 깨어나고, 둔하면 정작 부를 때 못 알아듣습니다. 그래서 42dot은 호출어를 한 번에 판단하지 않고, 먼저 가볍고 빠른 모델로 후보를 걸러낸 뒤 정밀한 모델로 다시 확인하는 방식을 연구합니다. 하나의 모델로 속도와 정확도를 모두 갖기 어렵기 때문입니다.

말이 언제 끝났는지를 판단하는 것도 의외로 까다로운 문제입니다. 너무 빨리 끝났다고 판단하면 사용자의 말이 중간에 잘리고, 너무 늦게 판단하면 응답이 답답해집니다. 그 뒤에는 음성을 텍스트로 옮기는 과정이 오며, 이때는 차량에서 자주 쓰이는 지명이나, 연락처 이름 같은 고유명사를 정확히 적어내는 게 관건입니다. 마지막으로 AI가 답할 차례가 되면, 반대로 텍스트를 자연스러운 말로 바꿉니다. “220V”를 “이백이십 볼트”로 읽는 식으로요.

42dot의 ‘Gleo AI 기술 설명회’ 발표 내용 <사진: 요즘IT>

2) 판단의 문제: Gleo AI LLM

오늘날 우리는 흔히 ‘소 잡는 칼로 닭을 잡는’ 과소비를 하곤 합니다. 간단한 분류나 단답형 작업은 작고 가벼운 모델로도 충분한데, 습관적으로 가장 뛰어난 최고 성능의 모델만 고집하는 거죠.

개인 사용자가 구독형 서비스 내에서 쓰는 정도라면 큰 문제가 아니지만, API를 호출해 서비스하는 기업 입장에선 이야기가 완전히 달라집니다. 요청 한 번당 발생하는 비용이 소형 모델과 대형 모델 사이에 수십 배 이상 차이 나기 때문입니다. 특히 최근에는 랩탑이나 단말기(On-device)에서 무료에 가까운 리소스로도 훌륭히 작동하는 소형 언어 모델(SLM)이 다수 등장했습니다.

42dot의 LLM 파트 역시 이 지점에서 질문을 뒤집었습니다. “어떤 모델이 가장 강력한가?”가 아니라, “이 작업에 가장 적합하면서도, 빠르게 응답하고, 비용 효율적인 모델은 무엇인가?”로 묻기 시작한 겁니다.

간단한 제어나 상태 확인은 차량 내부에서 작고 빠른 모델이 처리하고, 깊은 추론이 필요한 복잡한 맥락 파악은 클라우드의 고성능 모델이 맡는 방식입니다. 단일 모델의 최고 스펙을 자랑하는 대신, ‘각 태스크에 꼭 맞는 모델을 얼마나 정교하게 골라 쓸 것인가’를 문제 해결의 중심에 둔 셈입니다.

문제 해결 방향은 찾았지만 또 다른 난관이 기다리고 있었는데요. 바로 ‘데이터’ 문제입니다.

42dot의 ‘Gleo AI 기술 설명회’ 발표를 토대로 재구성한 자료 <편집: 요즘IT>

공개된 웹 데이터에서 한국어가 차지하는 비중은 매우 작은 데다, 차량 특화 데이터는 그보다 훨씬 귀합니다. 운전 중의 자연스러운 발화, 음성 인식 오류가 섞인 입력, 그리고 에이전트의 행동 후 차량 상태 변화가 정밀하게 연결된 데이터는 웹 어디에서도 찾을 수 없기 때문입니다.

이 문제를 풀기 위해 42dot은 합성 데이터(Synthetic Data)를 연구하고 있습니다. 합성 데이터란 단순히 양을 늘리는 게 아니라, 모델 개선이 필요한 지점을 집중 생성하고 형식 검증과 품질 평가를 거쳐 다시 학습에 쓰는 순환 구조입니다.

다만, 여전히 남아 있는 문제가 있습니다. 모델이 생성한 데이터로 다시 학습을 시키면, 이미 잘하는 영역만 강화되고 정작 부족한 예외 상황(Edge Case)은 계속 방치되는 것 아니냐는 질문입니다. 모델이 자신의 오류까지 학습해 성능이 왜곡되는 이른바 ‘환각의 재생산’이나 ‘모델 붕괴(Model Collapse)’ 현상에 대한 우려입니다.

실제 현장 Q&A에서도 이와 관련된 날카로운 질문들이 이어졌는데요. 42dot 연구진 역시 이 지점이 결코 만만치 않은 과제임을 솔직하게 인정했습니다. 현재는 데이터 생성 후 엄격한 필터링 과정을 거치고, 시뮬레이션을 통해 발굴한 실패 사례를 다시 학습 데이터로 피드백하는 ‘순환 루프’를 구축하며 예외를 줄여나가는 중입니다.

주목할 점은 이 모든 단계가 따로 놀지 않는다는 겁니다. 데이터 생성부터 학습·통합·경량화·서빙·평가까지가 하나의 연결된 사이클로 돌아갑니다.

3) 실행의 문제: AI Agent

세 파트 중 AI Agent는 가장 무거운 제약을 안고 있습니다. 차 안에서의 실행은 화면 속 답변이 아니라 사이드 미러를 접고 편다거나, 메시지 발송 같은 실제 행동으로 이어지기 때문입니다. 답이 틀리면 다시 물으면 그만이지만, 주행 중에 사이드 미러가 접히면 사고로 이어질 수 있습니다. 그래서 42dot은 즉시성이 필요한 일은 온디바이스가, 복잡한 추론과 외부 서비스 연결은 서버가 맡는 하이브리드 구조를 개발하고 있습니다.

복합적인 요청은 Supervisor가 목적을 해석하고 작업으로 나눈 뒤, 내비게이션·도착 시간·연락처·메시지 등 필요한 전문 에이전트를 선택해 하나의 실행 계획으로 묶어냅니다. 그 결과는 선택한 목적지, 새 도착 예정 시간, 수신자 정보, 작성된 메시지, 확인이 필요한 실행 항목을 포함한 하나의 구조화된 결과로 정리됩니다.

42dot의 ‘Gleo AI 기술 설명회’ 발표를 토대로 재구성한 자료 <편집: 요즘IT>

안전과 관련해서는 세 가지 질문을 던집니다. 무엇이 사실인가, 무엇을 실행해도 되는가, 누가 최종 결정하는가입니다.

첫 번째는 모델의 기억에만 의존하지 않고 위치 정보·차량 매뉴얼·최신 정보를 조회해 근거를 확보하는 것이고, 두 번째는 Gleo Guard가 요청과 응답, 행동이 기준에 맞는지 판단하는 것입니다. 세 번째는 전화·문자·목적지 변경 같은 중요한 행동은 사용자 확인을 거치도록 하는 것입니다. 새 기술이니까 더 안전하다는 식이 아니라, 위험한 실행은 사용자의 확인을 거치도록 설계하고 부적절한 출력은 걸러내는 방식으로 접근한다는 점이 핵심입니다.

다만 서비스를 만들어본 사람이라면, 여기서 진짜 어려운 부분이 무엇인지 짐작할 겁니다. 확인을 받느냐 마느냐가 아니라, 언제 받느냐입니다. 매번 되묻으면 대화 한 번으로 끝난다는 에이전트의 존재 이유가 희박해지고, 반대로 지나치게 줄이면 사용자가 의도하지 않은 일이 벌어집니다. 위험도를 나누고 그 기준을 정하는 일은 안전 장치인 동시에 사용자 경험 설계의 가장 까다로운 지점이기도 합니다.

시승에서 직접 확인한 것들

기술 세션이 끝난 뒤에는 실제 차량에서 Gleo AI를 직접 써볼 수 있는 시간이 이어졌습니다. 앞서 들었던 구조가 실제 경험으로 어떻게 나타나는지 확인하고 싶었는데요. 그래서 실제로 되는지 안 되는지보다는 어떤 상황에서, 어떻게 반응하는지를 중심으로 보려고 했습니다.

42dot의 Gleo AI 체험 및 시승 <사진: 요즘IT>

우선 장소 검색, 에어컨, 사이드미러처럼 차량 기능을 조작하는 요청은 대체로 매끄럽게 이어졌습니다. 이런 작업은 차량 내부에서 바로 처리되는 영역이고, 앞서 설명된 온디바이스 실행 구조가 체감되는 지점이기도 했습니다. 문자 보내기도 흐름 자체는 의도대로 이어졌습니다. 수신자를 찾고, 내용을 구성하고, 보내기 전에 확인을 거치는 과정이 세션에서 들은 설명과 거의 그대로 연결됐습니다.

다만 “이제 끝났다”라고 말한 음성이 “이재 끝나고”라는 텍스트로 전환되는 등, 문맥을 반영한 보정이 약간 아쉬운 부분도 있었습니다. 앞서 기술 세션에서 품질과 속도 사이의 균형을 계속 조정하고 있다고 설명했던 만큼, 앞으로 이런 부분이 얼마나 더 자연스럽게 보완될지도 지켜볼 만합니다.

대화의 지속성에서도 특징이 있었습니다. Gleo AI는 ‘글레오’라는 호출어로 부를 수 있는데요. 특히 정보 검색이나 일상 대화처럼 대화가 이어질 가능성이 높은 영역에서는 응답 후에도 마이크가 열려 있어, 다시 호출하지 않고 대화를 이어갈 수 있습니다. 또한 대화 내용은 화면에 채팅 형태로 쌓여, 앞선 요청과 응답을 사용자가 직접 확인할 수 있죠. 다만 제가 주로 시도한 차량 제어나 메시지 발송처럼, 실행으로 끝나는 요청에서는 다음 요청을 위해 다시 호출어를 불러야 했습니다.

끝으로 대화 중 끼어들기(barge-in)에 대해서도 개선이 필요함을 느꼈습니다. 듣기와 말하기를 동시에 처리하는 방향을 개발하고 있다는 설명을 들었고, 실제로 시도해보기도 했지만, AI가 말하는 중간에 새 요청을 겹치면 의도가 정확히 전달되지 못하는 느낌이었습니다. 결국 호출어로 새롭게 부른 뒤에 말하거나, 응답이 끝난 뒤에 다음 요청을 하는 편이 더 편했습니다.

실제 차 안에서 직접 확인해 보니, 42dot 기술 세션에서 들었던 내용과 비슷했습니다. 구조는 대부분 그대로 연결되어 있었지만, ‘어렵다’라고 고백했던 기술적 제약들은 여전히 풀어가야 할 과제로 남아 있었습니다. 어느 한 단계의 오차, 맥락을 어디까지 이어갈 것인가, 사람과 AI가 서로의 말을 어떻게 주고받을 것인가는 실제로도 쉽지 않은 문제임을 다시 확인할 수 있었죠.

42dot의 Gleo AI 체험 및 시승 <사진: 요즘IT>

문제 정의는 끝났다

이번 Gleo AI 세션에서 가장 인상 깊었던 점은 완성된 기능이 아니라, ‘개발 과정 그 자체’였습니다. 특히 Q&A 시간에 “이어질 시승 체험에서 Gleo AI를 최대한 다양하게 써보고, 마음껏 혼내듯 피드백을 달라”는 말이 기억에 남았는데요. 직접 시승해보며 마주친 점들을 떠올리면, 이 부탁은 그냥 겸손이 아니라 현재 단계에 대한 정확한 인식에 가까웠습니다.

42dot이 그리는 앞으로의 방향은 여러 갈래로 뻗어 있습니다. 명령을 처리하는 AI를 넘어 말하지 않아도 상황을 먼저 이해하는 AI 컴패니언으로의 진화, 사용자의 맥락과 선호를 반영하는 개인화, 그리고 자율주행 시대의 차량이라는 공간을 연구 방향으로 제시했습니다.

결국 하나의 흐름으로 읽힙니다. 차량의 Human-Machine Interface(사람과 기계가 상호작용하는 방식)가 정확한 명령어를 입력하던 방식에서, 자연스러운 대화로 이동의 맥락을 이어가는 방식으로 이동하는 중이라는 거죠.

지금 42dot의 Gleo AI가 “AI Agent, Gleo AI LLM, Speech Technologies”를 하나의 End-to-End Experience(음성 인식부터 판단, 실행까지 끊김 없이 이어지는 전체 경험)로 연결하려는 이유도 결국 여기에 있습니다.

그리고 그 전환은 단순히 ‘말을 잘 알아듣는’ 기술보다, ‘주어진 상황을 어떻게 이해하고 풀 것인가’라는 문제를 먼저 정의하는 것에서 시작됩니다. 아직 답은 완성되지 않았지만, 앞으로 우리는 차량과 어떤 모습으로 소통하게 될까요? 곧 다가올 변화의 모습을 기대해 봐도 좋겠습니다.

*기술 세션에서 소개되는 일부 기술과 기능은 현재 개발 중인 내용이며, 실제 적용 범위와 제공 시점은 개발 및 서비스 환경에 따라 달라질 수 있습니다. 본 자료에는 현재 제공 중인 기능과 연구·개발 중인 기술이 함께 포함되어 있으며, 시승 중 경험한 내용은 해당 차량과 환경에서 확인한 것입니다.

글쓴이: 이재훈 작가

#42dot #GleoAI

]]>

AI 시대에 진짜 사진임을 증명하는 애플의 기술

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

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

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

써볼 것: Motion - 문장 하나로 영상을 만들어주는 AI 도구
참고할 것: AI 시대에 진짜 사진임을 증명하는 애플의 기술
적용해볼 것: 클로드 코워크와 채팅이 하나로 합쳐졌습니다

<출처: Motion, Mosaic>

1. 써볼 것: 문장 하나로 영상을 만들어주는 AI 도구

제품 소개 영상이나 짧은 광고를 만들어야 하는데, 영상 편집은 엄두가 안 날 때가 있죠. Motion은 그럴 때 쓰는 도구입니다. 만들고 싶은 영상을 문장으로 설명하면, AI가 알아서 영상으로 만들어줍니다. 만든 회사는 Mosaic(모자이크)이고요.

예를 들어 새 맥북 출시 영상 만들어줘라고 입력하면, 조사부터 디자인, 애니메이션, 목소리 입히기, 편집까지 한 번에 처리해서 완성된 영상을 내놓습니다. 출시 영상, 제품 데모, 로고 애니메이션, 소셜 광고 같은 걸 만들 수 있고, 블로그 글이나 뉴스레터를 영상으로 바꾸는 것도 가능하다고 합니다.

어떻게 만들어주나요?

만드는 과정은 다섯 단계입니다. 먼저 원하는 영상을 한 문장으로 설명하면, Motion이 내 웹사이트를 읽어서 우리 브랜드 색과 글꼴을 파악해요. 그다음 장면을 어떻게 구성할지 짜고, 각 장면을 실제로 만들고, 마지막에 내가 직접 고치거나 채팅으로 수정을 부탁하면 됩니다. 장면을 통째로 다시 만들지 않고 원하는 부분만 손볼 수 있어요.

여기서 프로덕트 메이커가 눈여겨볼 점이 하나 있어요. Motion은 브라우저에서 바로 쓸 수도 있지만, 클로드나 ChatGPT 같은 AI에 연결해서 쓸 수도 있습니다. 지난 회차에서 MCP(AI에 외부 도구를 붙이는 규격)를 다뤘는데, Motion이 바로 그 방식으로 붙거든요. 클로드에게 이런 영상 만들어줘라고 하면, 클로드가 Motion을 불러 영상을 만들어오는 식이에요. 원래 클로드나 커서에서 연결해 쓸 수 있었는데, ChatGPT에서도 쓸 수 있게 됐어요.

얼마인가요?

Motion은 크레딧을 사서 쓰는 유료 도구입니다. 5달러에 200크레딧을 주는데, 이걸로 영상 한두 개를 만들 수 있어요. 긴 영상이나 음성, 추가 수정에는 크레딧이 더 들고요. 무료 플랜은 따로 없고, 가입하면 맛보기용 크레딧을 조금 줍니다.

누구에게 좋을까요?

영상을 자주 만들어야 하는데 편집에 쓸 시간이 없는 사람. 출시 영상이나 제품 데모를 빠르게 뽑아볼 수 있어요.
혼자 일하거나 작은 팀이라 영상 만들 사람이 없는 경우
다만 AI가 만든 영상이라 결과물이 늘 기대만큼 나오는 건 아닙니다. 완성본을 그대로 쓰기보다, 초안을 빠르게 뽑고 다듬는 용도로 보면 좋을 것 같습니다.

<출처: Apple Security Research>

2. 참고할 것: AI 시대에 진짜 사진임을 증명하는 애플의 기술

요즘은 AI로 진짜 사진처럼 보이는 이미지를 만들거나 감쪽같이 고치는 게 너무 쉬워졌습니다. 덕분에 사진에서 거슬리는 배경을 한 번에 지우는 편한 기능도 생겼지만, 반대로 이게 실제로 찍은 사진인지 AI가 만든 이미지인지 구별하기 어려워졌죠. 애플이 9월 15일 이 문제를 다루는 기술을 공개했습니다. 이름은 Apple Reference Image(애플 레퍼런스 이미지)인데, ‘이 사진은 진짜 카메라로 찍은 것’이라고 증명해주는 기능입니다.

사진은 종종 뭔가를 증명하는 역할을 합니다. 뉴스 보도 사진이나 사건 증거 사진처럼요. 예전엔 사진처럼 보이면 진짜라고 믿었는데, 이제는 AI가 진짜 같은 가짜를 만들다 보니 그것만으로는 믿기 어려워졌습니다. 이는 애플이 이런 기능을 내놓은 이유이기도 하죠.

어떻게 증명하나요?

iPhone 18 Pro와 18 Pro Max 카메라에 새 촬영 모드가 생깁니다. 원할 때 켜는 방식이에요. 이 모드로 사진을 찍으면, 카메라 센서가 빛을 받은 그 순간에 사진 데이터에 도장을 찍습니다. 중간에 누가 손대지 못하게요. 여기에 언제 찍혔는지도 함께 기록하고요. 그래서 이 사진이 특정 시점에, 진짜 아이폰 센서로 찍혔다는 게 검증됩니다.

기존에도 이와 비슷한 시도가 있었습니다. C2PA라는 방식이며, 사진을 찍은 뒤에 이 사진은 이런 편집을 거쳤다는 기록을 붙이는 식이었죠. 그런데 이건 편집 과정 중간에 조작되면 막기 어려웠어요. 애플은 촬영하는 순간부터 센서 차원에서 잠그는 방식이라 더 튼튼하다고 설명합니다.

무엇을 눈여겨보면 될까요?

한 가지 눈에 띄는 건, 사진가의 신원을 드러내지 않아도 된다는 점입니다. 기존 방식은 사진가나 언론사가 자기 이름을 걸고 이 사진 진짜라고 보증해야 했어요. 그런데 분쟁 지역에서 취재하는 기자처럼, 신원이 드러나면 위험한 사람도 있잖아요. 애플 방식은 이름을 밝히지 않고도 진짜임을 증명할 수 있게 했습니다.

이 소재는 지난 회차와 이어서 보면 흥미롭습니다. 얼마 전 앤트로픽이 AI가 만든 콘텐츠에 표시를 붙이는 기술을 내놨다고 전해드렸는데요. 그건 AI가 만든 걸 표시하는 방향이고, 이번 애플 기술은 진짜를 증명하는 방향이죠. AI가 만든 걸 걸러내는 쪽과, 사람이 생성한 것을 가려내는 쪽. 양쪽의 시도가 나오고 있는 현재의 상황이 흥미롭습니다.

물론 지금은 아이폰 최신 프로 모델에서만, 그것도 사용자가 켜야 쓸 수 있는 기능이라 당장 널리 퍼지긴 어려워보입니다. 다만 진짜 사진을 인증한다는 방향 자체가, 앞으로 사진과 영상을 다루는 사람이라면 알아둘 만한 흐름이죠.

<출처: Claude>

3. 적용해볼 것: 클로드 코워크와 채팅이 하나로 합쳐졌습니다

클로드를 쓰다 보면, 간단한 질문은 채팅으로 하고 큰 작업은 따로 코워크(Cowork)라는 공간에서 하는 식으로 나뉘어 있었어요. 그런데 앤트로픽이 9월 16일, 이 둘을 하나로 합쳤습니다. 이제 어디서 할지 고를 필요 없이, 대화하듯 맡기면 클로드가 알아서 처리하는 방식으로 바뀌었어요.

이번 통합에서 프로덕트 메이커가 참고할 만한 건, 클로드에게 일을 맡기는 방식이 어떻게 바뀌는지입니다.

무엇이 달라졌나요?

가장 큰 변화는 맡기고 나가도 된다는 점이에요. 예를 들어 정오까지 주간 보고서가 필요하다면, 나가기 전에 클로드에게 지난주에 뭐가 바뀌었는지 정리하고, 늘 쓰던 형식으로 보고서를 써줘. 핵심은 슬라이드 5장으로 만들어줘라고 맡길 수 있어요. 그러면 클로드가 작업하는 동안 다른 일을 하고, 가는 길에 폰으로 진행 상황을 확인할 수 있습니다. 애매한 게 있으면 클로드가 먼저 물어보고요.

새로 생긴 기능도 있어요. 클로드 안에서 문서(Docs)와 슬라이드(Slides)를 바로 만들 수 있게 됐습니다. 보고서를 부탁하면 문서로 만들어주고, 발표 자료를 부탁하면 슬라이드로 뽑아줘요. 이걸 PowerPoint나 PDF로 내려받거나, 클로드에서 바로 고칠 수도 있고요. 지금은 유료 플랜(Pro, Max)에서 순차적으로 제공되는 중입니다.

맡기는 정도를 정할 수 있습니다

여기서 실무에 참고할 대목이 있어요. 클로드가 일하다가 언제 나에게 확인받을지를 내가 정할 수 있습니다. 기본은 뭔가 실행하기 전에 먼저 물어보는 방식이에요. 그런데 계속 알아서 진행하고, 꼭 필요할 때만 확인받게 바꿀 수도 있습니다. 어느 쪽이든 최종 결정은 사람이 하고요.

이건 클로드만의 이야기가 아니라, AI에게 일을 맡길 때 늘 마주하는 고민이에요. 하나하나 확인하면 안전하지만 느리고, 다 맡기면 빠르지만 엉뚱한 결과가 나올 수 있으니까요. 그래서 어떤 일은 매번 확인받게 하고, 어떤 일은 믿고 맡길지를 나눠 정해두는 게 점점 중요해집니다.

적용해볼 수 있는 것

AI에게 큰 작업을 맡길 때, 시작 전에 어떤 형식으로, 뭘 포함해서 만들지를 한 번에 정리해서 전달해보세요. 중간에 묻는 일이 줄고 결과물도 기대에 가까워집니다.
내가 자주 하는 작업 중에, 매번 확인이 꼭 필요한 것과 믿고 맡겨도 되는 것을 한번 나눠보세요. 맡겨도 되는 일부터 AI에게 넘기면 시간이 확 절약됩니다.
반복되는 작업이 있다면, 그걸 AI에게 정기적으로 맡기는 걸 시도해보세요. 매주 같은 보고서를 만든다면, 그 작업을 아예 예약해두는 식으로요.

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

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

]]>

중소·중견 AX는 만든 사람이 떠난 뒤에 시작된다 (위시켓 AIDP FDE)

[편집자 주] 요즘IT는 AX 현장에 직접 들어가 일하는 엔지니어, FDE(Forward Deployed Engineer)를 회사별로 만나고 있습니다. 이 시리즈는 특정 기업의 성공담이 아니라, 여러 현장에서 반복되는 패턴을 기록합니다. 등장하는 고객사 사례는 인터뷰이 소속사와 협의해 익명 처리했습니다. 이번 편의 두 사람은 위시켓 AIDP소속이고, 요즘IT 역시 위시켓이 운영하는 매체입니다.

로드맵도 전담 조직도 없는 회사의 AX는 어디서 시작하나

지난 글에서는 대기업 AX 현장을 다뤘습니다. 나름의 로드맵과 전담 조직은 있는 곳이었죠. 그런데 국내 대기업은 아주 극소수입니다. 2026년 9월 1일 중소벤처기업부가 내놓은 통계에 따르면 국내 기업의 99.9%가 중소기업이고 종사자만 1,900만 명에 달합니다. 대한상공회의소가 올해 6월 임금근로자 3,000명에게 물었을 때, 회사에 AI 도입 로드맵이 있다고 답한 중소기업 근로자는 29.6%였습니다. 대기업은 45.6%였고요.

취재에서 만난 AX 회사들은 대부분 대기업과 중소·중견의 AX를 다 합니다. 다만 사람 수와 개월 수로 값을 매기는 한(맨먼스) 작은 프로젝트는 남는 게 없어서, 대기업 프로젝트를 선호하게 됩니다.

그런데 중소·중견기업의 AX에 일부러 집중하는 팀이 있습니다. 위시켓이 지난해 11월 출범한 AX 사업부 위시켓 AIDP입니다. 지난 7월 인월 견적을 폐기했습니다. 프로젝트 값을 투입 인원과 기간이 아니라 고객의 숫자가 얼마나 달라지는가로 매기겠다는 것입니다.

그렇다면 로드맵도 전담 조직도 없는 회사에서 AX는 실제로 어떻게 시작될까요. 이 현장에 투입되는 FDE 두 명을 만나, 중소·중견기업에서 반복적으로 들어오는 의뢰가 무엇이고 그것을 어떻게 푸는지 들어봤습니다.

김우빈(왼쪽) · 홍승호(오른쪽) | 위시켓 AIDP FDE
홍승호는 패션, IT 도메인을 두루 경험하고 창업 경험이 있는 FDE다. 김우빈은 개발자와 PM을 거쳐 FDE로 일하고 있다. 위시켓 AIDP는 기업의 매출과 이익이 만들어지는 구조를 기술로 다시 설계하는 일을 고객사 현장에서 수행하는 조직이다. FDE 직군은 2025년 10월에 도입했고, 산업을 가리지 않되 주로 중소·중견기업에 들어간다. 고객사의 업무 상태를 먼저 진단해 로드맵을 만들고, 그 단계에 맞는 것부터 실행한다. 프로젝트마다 사업 리드 1명과 FDE 2명이 붙고, 문제를 다시 정의하는 일은 현장의 FDE가 직접 한다. 착수 때 합의한 KPI와 함께 “우리가 빠져도 고객이 스스로 운영하는 상태”를 성공으로 규정한다.

머릿속에 있는 것을 어떻게 꺼내나

이들에 따르면 중소·중견기업에서 가장 자주 포착되는 어려움은 회사가 실제로 어떻게 일하는지가 어디에도 기록되어 있지 않거나, 기록이 있어도 파편화되어 있는 것이라고 합니다. 일하는 방식은 각 담당자의 머릿속에 있고, 에이스가 그만두면 일이 멈추죠. 그 상태에서 AI를 얹어도 손익은 달라지지 않는다는 것이 두 FDE의 판단입니다.

그래서 두 사람은 AI를 붙이기 전에 그 회사가 지금 어느 상태인지 먼저 진단하고, 그 상태에 맞는 것부터 한다고 합니다. 그게 꼭 AI는 아닐 수 있습니다. 특히 일하는 방식이 담당자의 머릿속에 있는 회사에서는 머릿속을 꺼내 데이터로 정리하는 일을 먼저 해야 그 위에서 AI가 움직일 수 있다는 것이 이들의 설명입니다. 어떻게 진단하고, 어떻게 정리하는지부터 물었습니다.

머릿속에 엉켜 있는 업무를 기록으로 정리하기 <출처: 요즘IT, ChatGPT로 제작>

Q. 진단은 어떻게 하는 건가요?

홍승호 회사에 이미 있는 데이터를 보고, 실무자와 리더를 인터뷰하고, 그 둘을 대조합니다. 그러면 실제로 해결해야 할 문제가 보여요. ERP를 새로 만들어 달라, 앱을 만들어 달라처럼 당장 불편한 것을 의뢰하시는데, 막상 진단해 보면 새로 만드는 게 해법이 아닐 수 있거든요. 반대로 꼭 필요한 일일 수도 있고요.

최근에 진행한 곳은 대표가 중고차 관련 유튜브 인플루언서로 성공해서 키운 중고차 회사인데, 고객 데이터와 판매 차량 데이터, 딜러 데이터가 모여 있는 곳이 없었어요. AI가 일하려면 이 회사가 어떻게 일하는지를 AI가 알 수 있어야 하는데, 그 시작점이 앱이라고 봤죠.

저희 회사에는 위시켓 AX 성숙도 모델이라는 게 있어요. 회사의 업무 상태를 다섯 단계로 나눠서 보는데, 저희도 이 모델 프레임으로 진단을 해요. 그중 기록이 없거나 파편화된 경우는 그 맨 아래 단계인 암묵 운영이에요. 암묵 운영 단계의 업무는 개인이 하는 일을 회사의 시스템에 남기고, 그 데이터의 책임자를 정하는 게 중요한데요, 기술적으로는 사소해도 실제로 가장 어려운 작업이죠.

위시켓AIDP에서 AI를 도입할 준비가 어느 정도 되어 있는지 진단할 때 사용하는 위시켓 AX 성숙도 모델 5단계 설명. 화면·로그·문서로 확인된 것들과 실제 현장에서 본 업무 프로세스를 증거로 회사 전체가 아닌 업무 영역 단위로 판단한다. <출처: 위시켓 AIDP>

Q. 중소·중견기업 AX를 진단해 보면 기록이 없거나 파편화된 경우가 많다고 하셨는데요, 실제로 어떤 모습인가요?

김우빈 어떤 일이 진행되는지를 기록한 문서가 없기도 하고, 시스템은 있는데 기록을 안 하시는 경우도 있어요. 통일된 규칙 없이 기록해서 데이터를 봐도 그게 무엇인지 알 수 없는 경우도 많습니다. 발주를 메신저로 받는데 발주사마다 형식이 다르고, 담당자도 엑셀에 그때그때 다르게 입력하는 식이에요.

기록이 있어도 믿을 수 없는 경우도 있어요. 최근 작업했던 한 산업기계 제조사에서는 현장 시스템과 사무 시스템, 엑셀에 흩어져 있던 발주와 재고 데이터를 먼저 봤는데, 재고가 음수인 항목이 있고 납기가 2300년으로 입력된 발주가 있었어요. 올해 넣은 매입 입력의 37%가 그런 식으로 오염돼 있었죠. 전부 사람이 입력한 값이었어요. 이런 상태에서는 AI를 올려도 제대로 일할 수 없어요.

Q. 담당자 머릿속에 있는 일하는 방식을 시스템으로 옮기는 건 어떻게 하는 건가요?

김우빈 진단할 때 하는 그 인터뷰가 사실 머릿속을 꺼내는 일이에요. 저는 인터뷰 전에 숙제를 드려서 ‘어떤 업무를 하시는지, 그 업무가 자기 것이라고 생각하시는지’를 적어오시도록 요청드려요. 그것도 안 될 만큼 체계가 없는 곳이라면 ‘다른 사람에게 내가 받는 것과 넘기는 것’을 적어달라고도 해요.

그리고 인터뷰는 실무자와 리더 모두 하는데, 실무자를 먼저 만납니다. 리더가 먼저 말하면 그다음 실무자 인터뷰는 “팀장님 의견에 동의합니다”로 끝날 수 있거든요. 하시는 일에 관해 ‘그걸 왜 하는지’를 계속 묻기도 하죠. 왜 하는지 아무도 모르는 업무는 사실 없어도 되는 업무일 수 있거든요.

그렇게 들은 말을 회사에 기록된 문서와 데이터들과 대조해요. 앞서 언급했던 제조사에서는 10개 넘는 부서를 돌며 16번 인터뷰했어요. 각 부서의 서로 다른 시각을 확인하고, 그게 데이터가 끊기는 것과 어떻게 관련이 있는지 분석하죠. 또 사람 사이의 정치 같은 건 문서에 안 잡히니까 상주하는 때에는 팀원들의 관계를 관찰하기도 합니다.

위시켓 AIDP 로고 <출처: 위시켓 AIDP>

Q. 머릿속에서 일하는 방식을 제일 잘 꺼낼 수 있는 사람은 매일 그 일을 해온 그 회사 직원들일 것 같은데, 왜 스스로 하기가 어렵나요?

김우빈 본인들한테는 그게 너무 당연하기 때문입니다. 매일 하는 일이니까 어디가 노하우인지 스스로는 알기 어려워요. 미술관에 가면 그림 앞에 선을 그어놓잖아요. 거기까지 물러나야 그림이 한눈에 들어오거든요. 그런데 안에 있는 사람은 그렇게 물러나기가 어렵고, 저희 같은 외부인은 그럴 수 있으니 잘 보이는 겁니다.

홍승호 물론 잘할 수 있는 사람들도 있어요. 하지만 회사 안에 있는 사람이 그걸 공론화하기는 쉽지 않습니다. 지금의 방식을 만든 것도 그 회사 사람들이고, 그게 그 분들 입장에서는 또 치적이기도 하거든요. 그런데 내부인이 ‘그게 문제’라고 말한다면 누군가의 성과를 부정하는 일이 돼요. 저희는 그 방식을 바꾸러 들어가는 입장이라 그런 관계에서 자유롭죠. 그럼에도 문제를 해결하는 데 내부 역학관계는 중요하기 때문에 저희도 세심하게 살핍니다.

Q. 앞서 대표가 인플루언서인 회사 사례를 말씀해 주셨는데요. 한 업무의 담당자가 아니라 대표의 머릿속을 꺼내려면 더 어려울 것 같은데요. 어떻게 하셨나요?

홍승호 사실 회사의 업무 흐름을 정리하려면 실무자들이 아니라 대표나 리더가 정리해주셔야 할 것들이 있어요. 무엇을 성과로 볼 거냐 같은 문제죠. 그런데 대표님들은 바쁘시기 때문에 그 기준을 정리해 넘겨주시는 것도 어려워하시기도 해요. 그래서 앞선 중고차 사례에서는 대표님한테 전용 AI 에이전트를 붙였어요. 슬랙에서 대표님께 매일 질문을 하나씩 던집니다. 차를 보는 기준이나 손님 응대 방식 같은, 대표님 머릿속을 묻는 질문들이요. 답이 쌓이면 대표님 검수를 받아 회사의 기준으로 정리하는 거죠.

물론 그렇게 해도 기준을 잡기 어려운 것들도 있어요. 예를 들어 사람을 상대하는 감각 같은 것입니다. 그런 건 다른 방식으로 풀어야 합니다.

홍승호 위시켓 AIDP FDE <출처: 요즘IT>

AI는 언제 붙이나

진단부터 머릿속에 있던 일하는 방식을 꺼내 데이터를 맞추는 일까지는 언뜻 AX처럼 보이지 않습니다. AX라고 하면 AI를 도입하는 일을 떠올리게 되니까요. 하지만 두 사람은 처음부터 AI를 도입하기보다, AI를 도입했을 때 AI가 제대로 움직일 수 있는 환경을 먼저 만들어야 한다고 입을 모읍니다. 그래서 처음에 자동화나 AI 도입을 의뢰받았더라도 진단 결과에 따라 AI가 아닌 다른 것을 제안할 수 있다고 합니다.

앱 구축 같은 기존의 SI성 시스템 의뢰가 와도 마찬가지입니다. 시스템이나 앱, 홈페이지 개편도 이 회사가 AX로 가는 방향에서 현재 무엇이 필요한지 진단하고, AI가 붙을 수 있는 구조를 먼저 제안한다는 것입니다. 실제 사례에서 AI가 어떤 상황에서 붙을 수 있었는지를 물었습니다.

진단 후 필요한 것부터 만들어야 <출처: 요즘IT, ChatGPT로 제작>

Q. 그러면 AI는 언제 도입할 수 있는 건가요?

김우빈 AI가 판단할 근거가 데이터로 있을 때입니다. 의료 소모품 유통사 사례로 말씀드릴게요. 거래처가 메신저 단체 대화창에 문장으로 던지는 주문을 자동으로 기록해달라는 거였어요. 담당자가 메시지를 읽고 엑셀로 옮기고 있었는데, 그 메시지도 통일된 형식으로 들어오는 게 아니었죠. 그 대화창에 발주만 오가는 것도 아니었고요. 그런데 거래처가 발주한 내용은 시스템에 정확하게 입력되어야 하는 중요한 데이터입니다. 엉뚱한 제품이 발송되면 신뢰가 무너지기도 하고, 담당자는 시스템을 전부 다 하나하나 다시 들여다봐야 하니 자동화는 없느니만 못한 것이 됩니다.

물론 거래처에서 의뢰 받는 형식을 통일하면 일정 정도 해결됩니다. 하지만 많은 회사들이 현실적으로 그렇게 하기는 어렵죠. 그래서 이 회사도 발주 데이터가 우선 정확히 채워지는 게 중요했어요. 그래서 각 발주처에서 각 품목이나 수량 등을 표현하는 방식을 확인하고 규칙을 만들었고, 그 규칙이 채워진 다음에 AI를 붙였어요. AI를 붙인 다음에도, 발주와 관련해 확인해야 하는 모든 데이터가 확실할 때만 자동으로 확정하고, 하나라도 애매하면 사람에게 보내도록 했죠. 불확실한 걸 불확실하다고 말하는 건 시스템한테도 원칙이니까요.

결국 AI가 일할 수 있는 환경을 만든다는 게 이런 거예요. AI가 판단할 수 있는 데이터가 있어야 하고, 사람이 그걸 신뢰할 수도 있어야 하죠.

위시켓 AIDP 진단 리포트 일부 예시 화면 <출처: 위시켓 AIDP>

Q. 다른 사례도 있나요?

홍승호 앞서 말한 중고차 회사 사례를 들어볼게요. 이 회사는 핵심 업무의 기록 자체가 없었어요. 고객 관리 도구를 들여놓은 적도 있는데 현장에서 입력하지 않아 숫자가 안 찍혔고요. 대표님이 영상 채널에서 특가로 판다고 했는데, 그게 공유가 안 돼서 현장 딜러는 정가에 팔았고, 후에 고객 항의를 받은 적도 있었어요. 그래서 설계를 처음부터 이렇게 잡았어요. 먼저 앱으로 기록이 생기게 하고, 그다음에 그 기록을 이어서 차 한 대에 얼마가 남는지 보이게 한 뒤 이익이 보이면 AI를 어디에 얼마나 쓸지를 정한다는 것이죠.

앱이 나오고 나서 고객이 어디서 와서 무엇을 봤고 어떤 상담을 했는지가 처음으로 남기 시작했어요. 관리자가 특가를 등록하면 고객이 보는 화면과 딜러가 보는 전산이 동시에 바뀌고요. 대표님의 결정이 현장으로 바로 이어지는 길이 처음 생긴 거예요.

그다음에도 바로 AI를 붙이는 게 아니에요. AI는 공짜가 아니거든요. 저희는 차 한 대를 파는 데 AI에 얼마까지 쓸 수 있는지를 알고 도입해야 한다고 생각해요. 손익에 실제로 도움이 되는 AI 도입이 중요하다고 보거든요.

그러니까 두 가지 측면에서 AI 도입을 고려해야 한다고 봅니다. 일단 AI가 판단할 수 있고, 그 판단을 사람이 신뢰할 수 있을 만한 근거가 되는 기록이 있어야 하고, 나아가 AI 도입이 실제 손익에 도움이 되는지도 고려해야 하는 것이죠.

AI를 붙이면 AX인가?

그런데 앞서 두 사람의 설명에 따라 진단으로 AI가 일할 수 있는 환경을 먼저 만들고, 필요한 자리에 AI를 붙이면, AX가 된 걸까요? 두 사람의 답은 ‘아직’이었습니다. 이들은 AI를 도입한 시스템을 통해 만들어지는 산출물에도 책임자가 필요하며, 그 책임자가 필요에 따라 그 시스템을 고쳐나갈 수 있어야 한다고 설명합니다. 업무는 계속 바뀌고, 시스템은 만든 날 완성되지 않기 때문입니다.

시스템은 만든 날 완성되지 않는다 <출처: 요즘IT, ChatGPT로 제작>

Q. AI까지 붙였으면 거기서 끝난 것 아닌가요?

김우빈 소프트웨어를 만들면 뭔가 완성이 된 것 같죠. 그런데 제가 알기로 1.0으로 끝난 소프트웨어는 전 세계에 딱 두 개예요. 닌텐도 DS 게임 하나랑, 60년대에 만들어서 달 착륙 때 쓰고 지금도 쓰는 프로그램이요. 소프트웨어는 눈을 감고 인테리어를 하는 것과 같아요. 배치가 이상할 수도 있고 색이 다를 수도 있는데, 그걸 눈을 뜨고 맞춰야 하죠. 그 눈을 뜨는 순간이 실사용자가 실제로 쓸 때예요. 그래서 계속 고쳐야 하고, 고칠 사람이 있어야 해요. 그런데 그때마다 또 저희 같은 AX 파트너를 찾아야 한다면, 기업에는 또다른 부담이 됩니다.

그래서 내부에 그걸 할 수 있는 사람이 있어야 해요. AI가 뭔가 원하는 방식으로 작동하지 않을 때 그걸 고칠 수 있어야 하죠. 그래서 저희는 그 책임자까지 정하고, 그 사람을 교육한 뒤 떠납니다. 물론 웬만한 건 에이전트가 다 할 수 있게 해두고요. 저는 인계가 됐는지의 기준을 저희 없이 첫 장애를 스스로 넘느냐로 봐요.

Q. 사례를 들어주실 수 있나요?

김우빈 앞선 유통사 사례에서는 발주를 걸러내던 에이전트의 리소스를 조금 떼어서 관리자에게만 보이는 ‘수리 모드’를 만들었어요. 담당자는 뭔가 잘못됐거나 기능을 추가하고 싶을 때 거기 요청만 하면 돼요. 규칙은 설정으로 담당자가 직접 넣고 뺄 수 있게 했고, 수집이 잘 되고 있는지, AI가 잘 작동하고 있는지 등을 검사해서 문제가 생기면 해야 하는 일을 띄우는 점검 페이지도 있어요.

그 담당자 분께서는 이제 시스템에 자기만의 화면까지 만들어 자랑도 하십니다. AI가 뭘 처리했는지 보고 싶다면서 직접 만드셨더라고요. 이렇게 AI가 남의 시스템이 아니라 자기 것이 되는 것, 그게 진짜 AX 아닐까 싶었어요. 그분은 이제 에이전트의 관리자가 되신 것이죠.

Q. 그렇게 고객이 스스로 굴리게 만들어 놓고 나오면, 위시켓 입장에서는 다음 계약이 없어지는 것 아닌가요?

김우빈 저는 반대라고 생각해요. 자립을 경험하신 분들은 오히려 그 이후 재계약을 고려하십니다. 이 사람들이 없어도 우리가 직접 고쳐서 쓸 수 있구나, 그러면 다른 것도 하나씩 맡겨보자, 하게 되거든요. 계속 의존하게 만드는 것보다 신뢰가 더 올라가죠. 내부에서 유지보수까지 하실 수 있게 교육도 하니까 자립까지 도와주는 걸로 생각하시고 계속 맡기시는 거죠. 그리고 저희는 진짜 AX를 돕는 게 목표이기 때문에, 저희 입장에서는 고객이 스스로 굴리게 만드는 게 목표에 맞는 일이기도 하고요.

김우빈 위시켓 AIDP FDE <출처: 요즘IT>

Q. 하지만 또 IT가 익숙하지 않은 분들께는 인계를 한다고 해도 어려움이 있을 것 같은데요.

홍승호 맞아요. 이런 적이 있었어요. 어떤 고객사에서 “지금 서버가 터졌다”고 연락을 주셨어요. 제가 지방에서 다른 AI 교육을 진행하던 날인데 딱 교육 시작 10분 전에 연락이 온 거예요. 왜 터졌냐고 여쭤보니 본인이 서버에 있는 파일을 전부 지우셨다는 거예요. 파일을 지울 줄은 몰랐으니 파일을 전부 지우지 마시라고 말한 적도 없었죠.

그래서 그 현장에서 데모가 잘 돌아가는 것과 조직이 안심하고 운영할 수 있는 환경은 전혀 다른 수준의 문제라는 걸 알게 됐어요. 지금 당장은 완벽하지 않더라도 조직이 안심하고 운영할 수 있는 환경을 만드는 쪽으로 저희도 계속 노력해나가야 할 것 같아요.

Q. 그러면 두 분 스스로 ‘이 프로젝트는 끝났다’고 느끼는 건 언제인가요? 계약서상 검수일과는 다를 것 같아서요.

김우빈 저희는 실질적으로 업무를 바꾸러 투입되는 사람이라, 진짜 바뀌었는지를 봐야 해요. 마지막 상주일에 현장을 돌아다니면서 실제로 쓰는 모습을 봅니다. 누락과 실수가 없어졌는지, 반복 업무가 줄었는지, 보고가 빨라졌는지, 의사결정에 도움을 받는지. 안 바뀌었으면 끝나지 않은 겁니다.

홍승호 쓰는 모습까지 확인해도 저는 하나 더 보는 게 있어요. 그분들이 납득했는지요. 왜 이렇게 만들었는지, 왜 이 방식이 좋은지 납득하셔야 그때 끝나는 것 같아요. 이해가 안 된 채로 넘겨드리면 지금은 쓰셔도, 결국 만든 의도대로는 안 쓰시거든요.

우리 회사도 그런가

여기까지 두 사람이 말한 순서를 정리하면 이렇습니다. 회사가 지금 어느 단계인지 진단하고, 머릿속에 있던 업무 흐름을 시스템에 옮기고, 필요한 자리에 AI를 붙이고, 그것을 고치고 운영할 사람을 회사 안에 두는 것이죠.

다만 이 순서는 외부 팀이 들어온 뒤의 이야기입니다. 이 글을 읽는 분 중에는 로드맵도 전담 조직도 없는 회사에서 AX를 맡게 된 담당자가 많을 겁니다. 그분들이 외부에 의뢰하기 전에 스스로 확인해 볼 수 있는 것은 무엇이고, 계약 전에는 무엇을 확인해야 하는지 물었습니다.

Q. 우리 회사도 일하는 방식이 머릿속에만 있는 상태인지, 딱 하나만 본다면 뭘 봐야 하나요?

김우빈 우리 회사 일이 어떻게 굴러가는지가 A4 한 장에 그려지는지를 보면 돼요. 저는 ‘워크플로우 지도’라고 부르는데, 말하자면 순서도예요. 어느 팀이 뭘 해서 어느 팀으로 넘기는지요. 프로젝트에 들어가면 실제로 제가 이걸 그려서 고객사에 드리는데, 체계가 없는 회사는 이게 안 그려져요. 지금 하는 일이 한 장으로 안 그려진다면, 일하는 방식이 아직 머릿속에만 있는 겁니다. 일하는 방식이 기록으로 흐르고 있어야 AI가 업무를 넘겨받을 수 있어요.

김우빈이 고객사에 전달하는 ‘워크플로우 지도’ 예시. <출처: 위시켓 AIDP>

Q. 윗선이 도입을 결정해도 현장 직원들이 안 쓰면 소용없잖아요. 밀어내지 않고 받아들이게 하려면 뭐가 제일 중요한가요?

김우빈 대표와 실무자가 가장 크게 갈리는 단어가 ‘잡무’예요. 대표 입장에서 회사에 잡무라는 건 없거든요. 그런데 실무자는 자기 일 중에 커리어에 도움 안 되는 잡무가 있다고 느껴요. 그걸 없애준다고 하면 받아들이죠. 여러분을 대체하고 싶은 게 아니라 여러분을 잘 쓰고 싶은 거라고 얘기해요.

Q. 이 일을 외부에 맡기기로 했다면, 계약 전에 꼭 확인할 것 하나만 꼽는다면요?

김우빈 인계를 무엇으로 하느냐가 중요하다고 봅니다. 두꺼운 매뉴얼을 주는 건 인계가 아닙니다. 담당자가 실제로 굴릴 수 있는 운영 체계를 남기는지, 그걸 받을 사람이 누구인지까지 정해주는지를 봐야 해요. 안정화 기간과 무상 지원 기간도 계약 전에 확인하시고요.

마지막으로 두 사람에게 결국 AX에서 제일 중요한 것이 무엇인지 한마디로 물었습니다. 김우빈은 모두가 볼 수 있는 진실 하나, 단일 진실 공급원을 꼽았습니다. 데이터를 쌓아둔 창고가 아니라, 어느 데이터를 누가 관리하는지 책임 소재까지 정해서 머릿속에만 있는 지식과 회색 지대가 사라진 상태입니다. 회사 전체가 보는 방향이 하나여야 한다는 뜻에서 그는 그것을 북극성에 비유했습니다.

홍승호의 답은 메타인지였습니다. 실행이 더 이상 병목이 아닌 시대에는 문제를 정의하는 것이 유일한 가치가 되는데, 그러려면 나부터 우리 팀, 우리 회사가 지금 어느 수준인지 스스로 알아야 한다는 것입니다. 안에서 스스로 본 것과 밖에서 진단한 것이 만나 공감대가 생겨야 실제로 개선이 되고, 같은 문제가 다시 생기지 않는다고 했습니다.

두 사람의 말을 종합하면, 결국 ‘회사가 어떻게 일하는지를 회사 스스로 볼 수 있는 상태’가 AX에서 가장 중요하다고 할 수 있습니다. 그리고 단지 AI를 도입하는 것이 AX가 아니라, 우리 회사가 지금 AI를 도입할 단계인지 점검하고, 어디에 AI를 붙여야 하는지 판단하고, 그렇게 도입한 AI를 내부에서 운영할 수 있어야 한다는 기준을 제시했습니다.

이 접근이 AX의 유일한 방법은 아니겠지만, “AI로 뭐 좀 해야 하는 거 아니냐”는 불안이 만연한 기업에서 기준점을 잡는 데 도움이 되리라 생각합니다. 나아가 AX의 병목이 기술이 아니라는 점만은, 대기업과 중소기업 두 현장이 같았습니다.

AX 현장의 이야기를 더 가까이서 나눌 자리를 검토하고 있습니다.
어떤 형태가 좋을지 의견을 들려주세요. 1분이면 됩니다.
➡️ AX 관련 행사·모임 수요 조사

]]>

10분 만에 온톨로지(Ontology) 이해하기

이 글을 읽기 전에 이전 글 〈10분 만에 AI 에이전트 이해하기〉를 먼저 읽고 오시면 이해에 큰 도움이 됩니다.

0. 세 형제가 왜 이렇게 헷갈릴까

제가 파리라는 도시에 살면서 누리는 특혜 중 하나는, 마음만 먹으면 주말에 루브르나 오르세 같은 미술관을 산책하듯 다녀오는 사치를 부릴 수 있다는 겁니다. 그런데 미술관에 갈 때마다 재미있는 장면이 하나 있습니다. 어떤 분은 작품 옆 설명표(작품 라벨/레이블이나 명제표라고도 부릅니다)만 슬쩍 읽고 지나가고, 어떤 분은 오디오 가이드를 귀에 꽂고 작품 번호만 따라다니고, 또 어떤 분은 작품 설명을 해 주시는 도슨트 뒤에 딱 붙어서 작품과 작품 사이를 잇는 이야기를 듣습니다.

같은 미술관, 같은 작품인데 세 사람이 얻어가는 건 완전히 다릅니다.

이 장면이 요즘 데이터 업계에서 사람들이 가장 헷갈려하는 세 단어와 완전히 똑같습니다. 바로 어노테이션(Annotation), 시맨틱 레이어(Semantic Layer), 그리고 온톨로지(Ontology)가 그 세 형제입니다. 요즘 특히 온톨로지라는 단어가 여기저기서 부쩍 들립니다. 팔란티어(Palantir)라는 회사가 이 개념을 하나의 상품 카테고리로 만들어 무섭게 몸값을 올리면서, 너도나도 온톨로지를 입에 올리기 시작했거든요. 그런데 정작 벤더들은 이 셋을 자꾸 한 단어로 뭉뚱그려 팝니다. 그래서 유행은 유행대로 타는데, 정확히 뭐가 뭔지는 더 헷갈립니다. 헷갈리는 게 정상입니다. 파는 사람이 섞어 쓰는데 안 헷갈리는 게 이상하죠.

그런데 요즘 이 셋을 구분 못 하면 진짜 사고가 납니다. 왜냐고요? AI 에이전트가 등장했기 때문입니다. 사람이라면 애매할 때 옆자리 동료에게 “이 매출, 부가세 포함이야, 아니야?”라고 물어봅니다. 하지만 에이전트는 물어보러 가지 않습니다. 그냥 에이전트 본인이 처음 찾은 정의로 답을 만들어 버리죠. 그래서 이 세 층을 데이터 위에 제대로 깔아두지 않으면, 에이전트는 아주 자신 있게 틀린 숫자를 리포트에 박아 넣거나 오답을 자신 있게 이야기합니다.

오늘 여러분이 이 글을 끝까지 읽으신다면, 온톨로지·시맨틱 레이어·어노테이션 이 세 형제를 두 번 다시 헷갈리지 않으실 겁니다. 자, 들어가 보시죠.

1. 어노테이션(Annotation): 그림 옆의 설명표

미술관 작품 옆에는 작은 라벨이 붙어 있습니다. 제 책 〈AI 프로덕트 매니지먼트〉에서 화두로 잡았던 마티스의 〈달팽이〉 작품 설명표를 보겠습니다.

앙리 마티스, 〈달팽이〉, 1953년, 캔버스에 종이 오려붙이기(컷아웃, cut-out)/ 어노테이션은 그 오브젝트에 대한 설명표다 <사진 출처: 작가>

이게 바로 어노테이션입니다.

어노테이션은 번역하면 ‘주석’ 혹은 ‘설명’입니다. 낱개 데이터 조각, 오브젝트 하나에 붙이는 설명 꼬리표죠. “이 컬럼은 월 반복 매출을 뜻한다”, “이 필드는 달러화로 표시하라”, “이 작품은 마티스가 그렸다.” 이렇게 데이터 오브젝트 하나하나에 ‘이게 뭔지’를 적어두는 겁니다.

마이크로소프트 엑셀을 다루시는 분이라면 사실 어노테이션은 이미 너무 흔하게 쓰고 계십니다. 아래 이미지처럼 셀이나 컬럼에 코멘트나 노트를 붙여서 부가 설명을 하는 것이죠. 그러니 여러분은 오늘의 이 세 형제 중 첫째와는 이미 구면입니다.

엑셀의 코멘트/노트 기능은 대표적인 어노테이션이다. <출처: 작가>

다시 돌아와서요, 그런데 작품 설명표만 붙어 있으면 뭘 알 수 있고, 뭘 모를까요? 작품 한 점이 뭔지는 압니다. 하지만 이 미술관에 야수파나 인상주의 작품이 도대체 몇 점 걸려 있는지는, 설명표를 아무리 들여다봐도 알 수 없습니다. 이 표는 작품들을 서로 연결해주지도, 무언가를 계산해주지도 않으니까요.

어노테이션은 라벨입니다. 낱개에 붙은 설명일 뿐, 연결도 계산도 하지 않습니다.

2. 시맨틱 레이어(Semantic Layer): 소장품을 세는 기준

자, 그럼 미술관의 큐레이터가 관장에게서 이런 질문을 받았다고 해봅시다. “우리 미술관에 야수파 작품이 몇 점이나 됩니까?” 간단해 보이죠?

그런데 같은 질문을 큐레이터 세 명에게 따로 하면 세 개의 답이 돌아옵니다. 한 명은 마티스의 초기 작품을 인상주의에 넣어 계산하고, 다른 큐레이터는 야수파에 넣습니다. 한 명은 다른 미술관에 대여 중인 작품을 세고, 한 명은 뺍니다. 같은 ‘야수파 소장품 수’인데 숫자가 각각 다른 세 개가 됩니다.

이런 모습은 매우 낯익은 장면 아닌가요? 회사에서 매일 벌어지는 일입니다. 재무팀에서는 매출이 10.2억 원이라는데, 마케팅 부서는 10.4억 원, 슬랙에 붙여둔 AI 어시스턴트는 9.8억 원이라고 답합니다. 예전엔 이게 사람 문제였고, 10분짜리 “모두 모여!” 회의로 정리가 됐습니다.

그런데 앞서 말씀드렸듯 에이전트는 회의에 부르지 않아도 자기 혼자 답을 냅니다. 예를 들어 “rev_ttm_adj_v2” 같은 컬럼을 만나면, 그냥 눈에 처음 띈 정의를 집어다 씁니다.

이 문제를 푸는 게 시맨틱 레이어입니다.

시맨틱 레이어는 지표를 한 곳에서 딱 한 번 정의해서, 모든 팀과 모든 도구가 똑같이 계산하게 만드는 층입니다.

“야수파 = 이 목록의 작가, 대여 중은 제외” 이렇게 한번 정해두면 누가 세도 같은 숫자가 나옵니다. “매출 = 이 테이블들을 이렇게 조인하고 이 필터를 걸어 이렇게 집계한다.” 재무팀이 묻든 마케팅 부서가 묻든 에이전트가 묻든, 답은 동일한 하나입니다.

비즈니스 애플리케이션 세계에서는 분석 모델이나 비즈니스 레이어에서 이 역할을 합니다. 흩어진 원천 데이터 위에 ‘비즈니스 언어’를 한 겹 덮어서, 모두가 같은 정의를 읽게 하는 거죠.

시맨틱 레이어를 정의하는 예 <출처: 작가>

그런데 여기서 딱 하나, 시맨틱 레이어가 절대 못 하는 게 있습니다.

시맨틱 레이어는 여러분이 미리 정의해둔 계산만 실행합니다. “야수파나 인상주의 작품이 몇 점”은 완벽하게 셉니다. 하지만 “이 신인 작가의 그림 스타일은 인상주의인가 후기 인상주의인가?”처럼, 누구도 미리 정의해두지 않은 사실은 절대 스스로 만들어내지 못합니다. 계산기는 계산만 하지, 없던 결론을 도출하진 않으니까요.

시맨틱 레이어는 계산의 일관성입니다. 정해준 것은 정확히 계산하지만, 안 알려준 사실은 만들지 못합니다.

3. 온톨로지(Ontology): 그림을 잇는 도슨트의 머릿속

이제 이 글의 주인공, 온톨로지입니다.

미술관에서 작품을 설명해 주시는 도슨트를 따라가 본 적 있으신가요? 좋은 도슨트는 작품 하나하나를 설명하는 데서 그치지 않습니다. “모네는 인상주의고, 인상주의는 빛과 순간을 좇았고, 그래서 세잔의 후기 인상주의로 넘어가면 이렇게 형태가 달라집니다.” 작품과 작품, 사조와 사조를 관계로 엮어서 이야기합니다.

더 놀라운 건, 이 도슨트에게 처음 보는 작품 한 점을 보여줘도 “아, 이건 붓터치와 색감으로 봐서 후기 인상주의군요. 저 방에 걸려야겠네요”라고 스스로 추론한다는 겁니다. 누가 일일이 “이 작품은 저 방”이라고 안 알려줘도 말이죠.

이게 바로 온톨로지입니다.

교과서적 정의는 “공유된 개념화의 명시적이고 형식적인 규격”이라는 좀 무시무시한 문장인데, 쪼개보면 이렇게 세 조각입니다.

클래스: 이 세계에 어떤 종류의 것들이 있는가 (고객, 주문, 상품, 작가, 사조)
관계: 그것들이 어떻게 연결되는가 (고객은 주문을 한다, 작가는 사조에 속한다)
규칙(공리): 어떤 논리 제약이 있는가 (연매출 100만 달러 초과 고객은 플래티넘이다)

핵심은 세 번째입니다. 온톨로지는 RDF(자원 기술 프레임워크), OWL(웹 온톨로지 언어)같은 표준 규격으로 기술되기 때문에, 기계가 그냥 읽는 게 아니라 그 위에서 추론(reasoning)을 합니다. 온톨로지에 “플래티넘 고객 = 연매출 100만 달러 초과”라는 규칙이 있고, 사실 데이터에 “HYBE의 연매출 = 200만 달러”가 있으면, 엔진은 누가 if-else 한 줄 안 짜도 “HYBE는 플래티넘”이라고 스스로 결론을 냅니다.

팔란티어의 온톨로지 시스템 구조도 <출처: 팔란티어>

시맨틱 레이어가 죽어도 못 하는 게 바로 이겁니다. 이 층은 여러분이 미리 정의한 계산을 실행할 뿐, 여러분이 정의하지 않은 사실을 도출하진 못합니다. 온톨로지는 도출합니다.

온톨로지의 또 다른 강력함은 언어가 다른 시스템들을 통합하는 것입니다. CRM은 ‘Customer’, ERP는 ‘Client’, 재무는 ‘Account’라고 부르지만, 온톨로지는 이 셋이 같은 비즈니스 대상을 가리킨다고 못 박아줍니다. 그래서 온톨로지에 발을 딛고 선 에이전트는, 관계없는 테이블 더미 속을 헤매며 찍는 대신, 연결된 그래프 위를 걸어 다니며 답을 찾습니다.

같은 개념을 시스템마다 다르게 부르더라도, 규제기관 앞에서는 하나로 말해야 합니다. 그래서 규제 산업에서는 형식 온톨로지가 이제 사실상 기본입니다.

온톨로지는 관계와 추론입니다. 안 알려준 사실도 스스로 만들어냅니다.

4. 하나만 만들면 무슨 일이 벌어지나

여기서 많은 조직이 실수합니다. 셋 중 하나만 만들어 놓고 다 된 줄 아는 거죠.

시맨틱 레이어만 있으면? 정확하지만 얕습니다. “지난달 GMV(총거래액)가 가장 높은 채널은?”에는 딱 떨어지게 답하지만, “왜 그 채널이 꺾였지? 예산을 더 넣어야 하나?”에는 침묵합니다. 채널과 예산과 고객이 어떻게 얽히는지에 대한 모델이 없거든요. 예전엔 데이터 사이언티스트가 붙어야 겨우 답하던 영역이죠.

온톨로지만 있으면? 개념엔 유창한데 숫자엔 젬병입니다. “HYBE가 플래티넘인가?”는 완벽하게 추론하지만, “HYBE의 지난달 매출은?”엔 다시 세 가지 답이 나옵니다. 어느 테이블을 어떻게 집계할지 아무도 안 알려줬으니까요.

빈말이 아닙니다. 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 봤습니다. 이유는 비용, 불분명한 가치, 그리고 부실한 통제입니다. 실제로 데이터 관리 리더 중 63%가 “AI를 뒷받침할 데이터 관리 역량이 없다”고 답했고요.

대부분의 실패는 모델을 잘못 골라서가 아닙니다. 모델 밑에 깔린 데이터에 의미의 지반이 없어서입니다.

그런데 문제는, 온톨로지 구축이 무겁다는 겁니다. 팔란티어가 이걸 하나의 카테고리로 만들었지만, 전달 방식이 까다롭죠. FDE라고 하는 현장 파견 엔지니어, 수작업 모델링, 6~18개월, 그리고 구하기도 힘든 형식논리 전문가. 그 외의 조직은 데이터 레이크 위에 온톨로지를 맨땅에서 쌓아 올려야 합니다. 비용이요? 천문학적이죠.

그래서 현실적인 순서는 이렇습니다. 먼저 시맨틱 레이어로 핵심 지표부터 한 곳에 모으고, 온톨로지는 처음엔 가볍게(거창한 OWL 모델링이 아니라 비즈니스 용어집 수준으로) 시작해서, 도메인 하나씩 키워가는 겁니다. 한 번에 다 지으려다 6개월, 18개월씩 잡아먹고 좌초하는 것보다, 용어집에서 시작해 온톨로지로 키우는 길이 훨씬 현실적입니다.

5. 셋을 가르는 단 한 줄

세 개를 다 외우실 필요 없습니다. 딱 이 질문 하나면 정리됩니다.

“이 시스템은 내가 직접 입력하지 않은 결론을, 규칙과 사실을 엮어 스스로 꺼내올 수 있는가?”

“HYBE 매출은 200만 달러”라는 사실과 “매출 100만 달러 넘으면 플래티넘”이라는 규칙만 넣었을 때, 아무도 “HYBE는 플래티넘”이라고 적어주지 않았는데도 시스템이 그 결론을 스스로 내놓는가? 이걸 해내면 온톨로지, 못 하면 그 아래 두 형제입니다.

오브젝트에 라벨만 붙이면 → 어노테이션 (작품 설명표)
정해준 공식대로만 계산하면 → 시맨틱 레이어 (소장품 집계 기준)
안 알려준 사실까지 스스로 도출하면 → 온톨로지 (도슨트의 추론)

<출처: 작가>

라벨에서 계산으로, 계산에서 추론으로. 데이터에 의미가 한 겹씩 두꺼워지는 세 개의 층이죠.

다만 오해는 마세요. 모든 조직이 당장 온톨로지까지 필요한 건 아닙니다. 잘 정의된 지표 몇 개만 있으면 되는 상황이라면 무거운 온톨로지는 오히려 짐입니다.

제품 카탈로그나 PII 태깅(개인정보 항목 표시)처럼 계층 분류만 있으면 되는 곳은 택소노미(taxonomy, 온톨로지에서 계층 분류만 남긴 가벼운 버전) 수준에서 멈춰도 충분하고요. 도슨트가 필요 없는 전시라면 설명표만으로도 관람은 됩니다. 중요한 건 우리 에이전트가 지금 어느 층까지 밟고 서 있어야 하는가를 정확히 아는 겁니다.

AI 에이전트는 이제 막 데이터 위를 걷기 시작했습니다. 그 발밑에 설명표만 깔아줄지, 집계 기준까지 깔아줄지, 도슨트의 머릿속까지 심어줄지, 그 설계가 여러분의 에이전트가 얼마나 똑똑해질지를 결정합니다.

<원문>

10분 만에 온톨로지(Ontology) 이해하기

]]>

Sentry, Grafana로 사용자가 겪는 오류 찾아내기

AI로 빨라진 개발, Sentry와 Grafana로 안정성을 지켜봤습니다

AI로 개발이 빨라졌습니다. 예전에는 반나절 걸리던 화면이, 지금은 오전에 나오고 오후에 배포됩니다. “지금 밖이라 집에 들어가서 할게요.”라는 말 대신, 모바일로 에이전트에 요청하고 배포하는 시대가 와버렸죠. 코드는 늘어나고, 기능은 확장되고, 배포 주기는 극단적으로 짧아졌습니다. 하지만 안정성은 같은 속도로 따라오지 못합니다.

오히려 반대입니다. 코드가 빨리 쌓일수록 “그 버튼이 안 된다” 같은 VOC는 더 모호해집니다. 서버는 200을 반환하고, DB도 멀쩡하고, 백엔드 로그에는 아무런 흔적이 없습니다. 그런데 유저는 안 된다고 합니다. 외부 본인인증처럼 우리 서버를 거치지 않는 구간이면, 이 문제는 더 어려워집니다. 개발 속도는 구현의 문제고, 안정성은 관측의 문제입니다. 저는 이 둘이 같은 문제인 줄 알았습니다. 개발을 잘하면 안정성도 좋아질 줄 알았습니다. 하지만 실제로 서비스를 운영해 보니 그 둘은 다른 문제였습니다.

그래서 프론트엔드에 두 개의 눈을 심었습니다. 하나는 Sentry, 다른 하나는 Grafana입니다. 깨진 화면은 Sentry로, 핵심 시나리오가 실제로 불렸는지는 Grafana로 봅니다. 이번 글에서는 사이드 프로젝트에서 이 두 도구를 무료 티어로 어떻게 운영하고 개선했는지, 그 경험을 정리해 봤습니다.

서버가 모르는 실패가 있다

서비스를 운영하다 보면 VOC는 매우 단순합니다. “그 버튼이 안 돼요” 혹은 “에러가 떠요”에서 대부분 마무리됩니다. 가끔 현재 상태와 재현 시나리오를 함께 전달해 주는 분도 있지만, 매번 그것을 기대할 수는 없습니다. 그래서 부랴부랴 서버를 열어 보면 200이거나, 요청 자체가 없습니다. DB도 멀쩡합니다. 백엔드 개발자에게 물어봐도 “우리 쪽은 이상없다”는 답만 돌아옵니다. 오직 그 유저만 안 됩니다.

제가 겪은 예시를 들어보겠습니다. 첫 번째는 본인 인증입니다. 가입이나 온보딩 단계에서 외부 API로 휴대폰 번호를 검증합니다. 그런데 카카오톡 인앱 브라우저에서 인증을 마치고 돌아오면, 가입을 이어가는 데 필요한 인증 정보가 사라져 있었습니다. 서버 로그에는 최종 가입 API가 호출되지 않은 채로 끝나 있습니다.

두 번째는 특정 코드에서 발생한 split is not a function 에러입니다. API가 실패한 것이 아니라, 서버가 준 값을 프론트에서 문자열인 줄 알고 자른 것입니다. 타입스크립트를 쓰고 스웨거(Swagger)로 자동 생성한 타입 정보까지 받고 있었는데, 타입은 string인데 실제 값은 문자열이 아니었습니다. 그런데도 유저에게는 실제로 에러가 발생하고 있었습니다. 나중에 원인을 보니 데이터 마이그레이션 과정에서 잘못된 값이 들어가 있었습니다.

이렇게 실패에는 여러 종류가 있습니다. 서버가 아는 실패, 브라우저가 아는 실패, 외부 SDK가 삼킨 실패입니다. 그중 백엔드 로깅은 첫 번째만 커버할 수 있습니다. “그 버튼이 안 된다”에서 난감한 부분은 바로 뒤의 두 가지입니다.

그래서 프론트에도 관측이 필요합니다.

두 개의 눈을 심은 이유

모든 구현에서 가장 좋은 코드는 아무것도 작성하지 않은 코드입니다. 코드 없이 문제를 해결할 수 있다면 그게 가장 좋다는 말입니다. 하지만 이번에는 하나의 도구로 모든 것을 할 수 없어서 두 가지로 나눠 구현했습니다.

Sentry는 “실패를 체크”합니다. 화면이 죽거나, 에러 바운더리에 잡히거나, 서버 5xx가 프론트까지 오면 이슈가 생성됩니다. 여기에 개발자가 볼 수 있는 기본 정보가 함께 붙습니다. 앞서 말한 split is not a function이 바로 여기에 해당합니다. API 호출은 정상이었지만 화면이 깨진 경우죠.

운영 중인 Sentry 화면 <출처: 작가>

Grafana는 “성공을 체크”합니다. Grafana의 프론트엔드 관측 SDK인 Faro로 화면을 따라가고, 네트워크 요청마다 기록을 남깁니다. 특정 유저의 화면이 정상적으로 로딩되었는지, API 요청의 성공률은 얼마인지 등을 체크합니다. 그리고 핵심 시나리오의 전환율이 어떻게 되고 있는지도 확인할 수 있습니다.

운영 중인 Grafana 화면 <출처: 작가>

다시 정리하면 Sentry는 실패를, Grafana는 성공을 체크합니다. 따라서 “그 버튼이 안 된다”는 VOC는 Grafana에서 성공을 기본으로 확인하고, 실패했을 때는 Sentry로 원인을 확인하는 식으로 관리해야 합니다. 이것이 제가 두 가지 툴을 모두 도입한 이유입니다.

기본적인 운영 방법

실패와 성공을 체크해도, 그게 누구의 어떤 요청인지 확인할 수 없으면 VOC는 여전히 모호합니다. 물론 모든 VOC와 에러를 체크해서 고치는 것이 가장 좋습니다. 하지만 서비스는 매우 다양하고 참신한 방식으로 실패합니다.

제 사례를 하나 들어보겠습니다. 2020년에 출근만 하면 특정 API가 안 된다는 VOC를 받았습니다. 당시에는 이런 툴을 도입할 생각을 못 했고, 일주일 동안 원인을 찾아도 해결하지 못해 결국 그 유저의 출근 장소를 직접 찾아갔습니다. 그곳은 지하 3층이었고, 네트워크가 너무 느려 타임아웃 에러가 발생하고 있었습니다. 그 사이드 이펙트로 API가 안 되던 것이었습니다. 지금 생각하면 참 멍청한 일이지만, 실제로 많은 프로젝트가 이런 툴 없이 운영되는 모습을 주변에서 종종 봅니다.

다시 돌아와서, 간단한 구현 예시로 VOC를 추적하는 방법을 알아보겠습니다.

유저 정보를 붙인다

제가 운영하는 서비스의 로그인 타입은 크게 두 가지, 업체 유저와 일반 유저입니다. 그리고 유저 타입에 따라 제공되는 기능이 다릅니다. 그래서 Sentry와 Grafana에 로그인 정보를 심어 봅시다. (이 글의 예시 코드는 Next.js 16, TypeScript 7 기준으로 작성했습니다.)

Sentry에 유저 정보를 심는 코드 <출처: 작가>

Grafana(Faro)에 유저 정보를 심는 코드 <출처: 작가>

이렇게 각각의 훅에서 로그인 정보를 처리합니다. 로직은 매우 유사합니다. 그 결과는 대시보드에서 다음처럼 보입니다.

Sentry의 특정 이슈에 대한 Tags 정보 <출처: 작가>

필요한 정보와 불필요한 정보를 분리한다

그렇다면 모든 정보를 계속 쌓으면 좋을까요? 그렇지 않습니다. 가장 근본적인 이유는 돈입니다. 많이 쌓을수록 비싼 값을 내야 합니다.

<출처: Grafana 공식 홈페이지>

저는 회사에서는 Enterprise를 쓰지만, 사이드 프로젝트에서는 모두 Free Tier를 사용합니다. Grafana뿐 아니라 Sentry도 마찬가지입니다.

Free Tier는 데이터 보존 기간이 짧고 용량과 기능도 제한적이지만, 사이드 프로젝트에는 이 정도로 충분합니다. 서비스가 잘 된 다음에 더 높은 Tier로 옮겨 가는 것이 현명합니다. 티어를 바꾼다고 별도의 마이그레이션이 필요한 것도 아닙니다. 단지 돈을 더 내야 할 뿐이죠. 그렇다면 다시 돌아와서, 어떻게 Free Tier에서 최고의 효율을 뽑아낼 수 있을까요? 소제목처럼 쌓아야 할 데이터와 버려야 할 데이터를 구분하는 것이 그 시작입니다.

로깅은 많이 남기는 것이 능사가 아닙니다. 물론 AI의 발전으로 데이터 정제가 쉬워진 만큼 많아도 문제될 건 없다는 게 최근 제 생각이긴 하지만, 그럼에도 관리는 필요합니다.

우선 저에게 필요한 정보는 현재 서비스의 상태입니다. 예를 들어 Sentry는 다음과 같은 설정값을 갖고 있습니다.

Sentry config 값 <출처: 작가>

각 환경값과 버전값, 그 외에 필요한 값을 선언해서 관리하는 방식입니다.

그런 다음 버리는 값을 살펴볼까요? 대표적으로 개인식별정보(PII)와 관련된 값은 최대한 제거합니다. 우선 각 서비스에서 제공하는 기본 옵션(Sentry의 경우 위에 있는 sendDefaultPii)으로 1차 방어합니다.

그리고 프론트엔드에서 쓰는 별도의 패턴값으로 2차 제거합니다.

Grafana의 PII 필터링 로직 <출처: 작가>

조금 더 깊게 사용해 보기

여기까지만 해도 각 툴의 기본 사용은 충분합니다. 쌓인 데이터만으로도 많은 인사이트와 개선 사항을 찾을 수 있을 겁니다. 여기에 더해 몇 가지 운영 팁을 알아보겠습니다.

Sentry는 필요한 실패만 남긴다

우선 Local과 Dev 환경에서는 이슈를 쌓지 않습니다. Staging 환경은 예외가 될 수도 있지만, Local과 Dev에서 확인되는 에러는 어차피 개발 단계에서 모두 수정되기 마련입니다. 따라서 Free Tier 용량을 차지하지 않도록 비활성화하는 편입니다.

Sentry config 확장 버전 <출처: 작가>

SampleRate도 Prod 환경에서 100%로 두지 않습니다. 최소한으로 잡아 처리합니다. 그다음은 노이즈 에러를 걸러내는 일입니다. Next.js에서 자주 발생하지만, 실제로는 노이즈인 에러를 미리 찾아내 계속 제거합니다.

Sentry 필터링 로직 <출처: 작가>

실제로 리액트 프로젝트에 Sentry를 붙여 운영 환경에 배포하면 가장 많이 뜨는 에러는 하이드레이션(Hydration) 에러입니다. 이를 적절히 제거하거나 필터링하는 방식으로 운영하면 좋습니다.

이렇게 다양한 필터링을 추가하다 보면 어느 순간 정말 필요한 에러 로그만 쌓이는 것을 확인할 수 있습니다.

Grafana 쿼리가 막히면 MCP를 사용하자

혹시 LogQL을 알고 계신가요? Grafana Loki에서 로그를 검색하고 분석할 때 쓰는 쿼리 언어입니다. 여기서 Loki는 오픈소스 로그 집계·모니터링 시스템이라고 보면 됩니다.

따라서 Grafana 대시보드에서 데이터를 보고 싶으면 이 쿼리 언어를 알아야 합니다. 예전에는 이 쿼리 언어 자체가 하나의 장벽이었습니다. 언어를 잘 다뤄야 그 많은 데이터 속에서 원하는 인사이트를 얻을 수 있었지요.

하지만 AI가 발전하면서 양상이 매우 달라졌습니다. 이제는 소스 코드에서 보고 싶은 데이터를 MCP(Model Context Protocol)로 요청하기만 하면 적절한 쿼리를 작성해 주는 시대가 되었습니다.

운영 중인 Grafana 대시보드 <출처: 작가>

위 대시보드에서 저는 쿼리를 단 한 줄도 작성하지 않았습니다. 그렇다고 쿼리 언어를 모르는 것도 아닙니다. 단지 그럴 필요가 없었을 뿐이죠. 서비스 운영의 핵심 API부터 마케팅 링크와 알림톡으로 들어오는 세션까지, MCP로 연결하고 무엇을 보고 싶은지 말하면 다 만들어 줍니다.

예를 들면, 이렇게 요청하곤 합니다.

API의 요청 카운트에 따라 내림차순 정렬해줘
모바일과 PC 유저 비율을 알고 싶어
핵심 API (A, B, C..)에 대해 요청 카운트를 알려줘
브라우저 console.error 리스트업 해줘

그리고 그 결과가 대시보드에 마법처럼 나타납니다.

‘브라우저 console.error 리스트업 해줘’의 결과물 <출처: 작가>

그런 다음 Message에 쌓인 로그를 보고 에러를 수정합니다. 지금 보면 console.error: `DialogContent` requires a `DialogTitle` for the component to be… 같은 에러가 반복적으로 발생하고 있습니다.

사용 중인 컴포넌트 라이브러리에서 DialogTitle이 없을 때 발생하는 경고성 에러입니다. 이를 수정해 이후에는 같은 에러가 발생하지 않도록 관리합니다. 그다음에는 아래 대시보드에서 성공률이 낮은 API를 찾아 개선합니다. 가장 상단의 성공률 42.9% API를 분석해 유저가 어떤 이유로 실패를 마주했는지 살펴봅니다.

API별 성공률 대시보드 <출처: 작가>

이 API는 업체 유저만 호출해야 하는 API였는데, 호출 위치가 잘못되어 일반 유저도 호출하는 바람에 백엔드 서버에서 거절한 경우였습니다.

마치며

오전에 피그마 기획이 나오고 오후에 구현이 끝나고, 컴퓨터 앞에 없어도 배포하는 삶이 왔습니다. 빨라진 개발 속도에 맞춰 우리는 유저의 VOC에도 더 빨리 대응해야 합니다. 이제는 개발 속도보다 대응 속도가 더 중요한 시기입니다. 이를 위해 프론트엔드에 두 개의 눈을 심었습니다. Sentry는 실패를 체크하고 Grafana는 성공을 체크합니다.

이번에 Free Tier 툴을 도입하고 운영하면서 느낀 점은, 무작정 쌓는 것만이 능사는 아니라는 것이었습니다. 그리고 AI의 발전 덕에 생각보다 쉽게 수준 높은 최적화와 깔끔한 대시보드를 만들어 관리할 수 있었습니다. 이런 툴이 없다면, 제가 버그를 잡으러 지하 3층을 찾아갔던 2020년처럼 여러분도 지하 3층으로 내려가야 할지 모릅니다.

다음 VOC가 들어왔을 때, 여러분은 지하 3층으로 향하는 삶과 대시보드를 여는 삶 중 어떤 것을 선택하고 싶으신가요? 단언컨대 저는 대시보드를 여는 쪽이 훨씬 편리해 보입니다.

]]>

직접 돌려본 오픈 웨이트 모델, 어떻게 선택해야 할까?

오픈 웨이트 모델, 직접 돌려봐야 알 수 있는 것들

LLM 제공사의 API 기반 서비스나 클라우드 제공사의 서버리스 관리형 AI 서비스는 개발자가 생성형 AI 애플리케이션을 시작할 때, 선택할 수 있는 가장 간단한 방법입니다. GPU를 직접 준비하거나 모델을 설치할 필요 없이 API를 연결하면 되고, 모델 업데이트와 추론 환경도 제공사가 관리하기 때문이죠.

그러나 모든 기업과 개발팀이 AI를 이런 방식으로 사용할 수 있는 것은 아닙니다. 보안 요구가 높은 환경에서는 인터넷과 분리된 폐쇄망에서 AI를 운영해야 할 수 있고, 사용량이 많아지면 API 비용도 부담이 될 수 있습니다. 토큰 단위로 API 비용을 계속 지불하는 것이 나을지, GPU를 직접 운영하며 *오픈 웨이트(Open Weight) 모델을 직접 구동하는 것이 나을지 고민하는 개발팀도 많습니다.

*오픈 웨이트(Open Weight):인공지능 모델이 학습을 통해 얻은 가중치(Weights)와 편향(Biases) 등 매개변수 파일을 외부에 공개하여, 누구나 다운로드하고 활용할 수 있도록 제공하는 방식

하지만 이 선택은 모델의 공개 벤치마크 점수만으로 판단하기 어렵습니다. 그래서 여러 오픈 웨이트 모델을 직접 GPU 인스턴스에 배포하고, 조건을 하나씩 바꿔가며 성능을 측정했습니다. 테스트하면서 제가 궁금했던 건 단순했습니다. “모델이 크면 더 느릴까? GPU를 많이 쓰면 더 빨라질까? 같은 모델이라도 실행 방식을 바꾸면 얼마나 달라질까?” 그런데 실제 결과는 예상보다 훨씬 복잡했습니다.

테스트의 전제

이번 테스트의 목적은 특정 서비스 환경에서 최대 성능을 끌어내는 것이 아니라, 같은 GPU 환경에서 LLM 자체의 추론 특성을 비교하는 것이었습니다. 따라서 특정 모델에만 유리하게 작용할 수 있는 추가적인 튜닝은 최대한 배제했습니다.

또 동일한 GPU와 추론 환경을 기준으로 모델을 비교하고, GPU 수나 실행 정밀도처럼 성능에 영향을 주는 요소를 확인할 때는 한 번에 하나의 조건만 변경했습니다. 실제 서비스에서는 캐싱, 배칭, 추론 엔진 튜닝 등 여러 최적화를 추가할 수 있지만, 이번 테스트에서는 이런 요소가 모델 간 비교 결과에 섞이지 않도록 하는 데 초점을 맞췄습니다.

같은 환경에서 모델 자체를 비교하기

테스트 환경에서 중요한 GPU는 엔비디아 RTX PRO 6000 Blackwell Server Edition GPU 4장이 장착된 클라우드 인스턴스를 사용했습니다. GPU 한 장당 메모리는 96GB이며, 서버 전체에는 총 384GB의 물리 GPU 메모리가 있습니다. 인스턴스 비용은 시간당 12달러입니다.

추론 엔진은 vLLM으로 최대한 통일했습니다. 주요 테스트 대상은 gpt-oss-20b, gpt-oss-120b, Qwen3.8-27B, Gemma4:31b, Mistral-Small-4-119B였습니다. GLM-5.3-Flash와 Kimi-K3도 후보에 넣었지만, 이 두 모델은 뒤에서 설명할 호환성과 메모리 문제 때문에 동일한 조건의 성능 테스트까지 진행하지 못했습니다.

테스트도 한꺼번에 여러 조건을 바꾸지 않았습니다. 처음에는 GPU 한 장만 사용하고 모델만 바꿨습니다. 그다음 동시 요청 수를 늘렸습니다. 이후에는 모델과 요청 조건을 고정한 채 GPU 수를 1장, 2장, 4장으로 바꿨습니다. 마지막으로 같은 모델의 실행 정밀도를 바꿔봤습니다.

측정 지표는 크게 두 가지입니다. 초당 토큰 수(Tokens Per Second, TPS)는 모델이 얼마나 많은 출력 토큰을 만들어내는지를 보여줍니다. 첫 토큰 응답 시간(Time To First Token, TTFT)은 요청을 보낸 뒤 첫 번째 답변이 나타날 때까지 걸리는 시간입니다. TPS가 서버의 처리 능력이라면 TTFT는 사용자가 느끼는 기다림에 가깝다고 보면 됩니다.

테스트에서는 GPU와 추론 엔진뿐 아니라 입력 조건도 통제하려고 했습니다. LLM은 같은 모델이라도 질문의 길이와 생성하는 답변의 길이, 동시에 들어오는 요청 수에 따라 성능이 크게 달라지기 때문입니다.

테스트는 일반 질의, 한국어, 코딩, 추론, 요약, 긴 문맥 RAG 등 실제 기업에서 사용할 만한 워크로드를 기준으로 설계했습니다.

첫 번째 테스트에서 모델별 초당 출력 토큰을 측정했습니다

가장 먼저 GPU 한 장을 사용하는 TP=1 환경에서 모델만 바꿔봤습니다. 단일 요청을 보냈을 때 gpt-oss-20b는 약 250 tokens/s, gpt-oss-120b는 약 184 tokens/s를 기록했습니다. 반면 Qwen3.8-27B는 약 26 tokens/s, Gemma4:31b는 약 23 tokens/s였습니다.

모델별 초당 출력 토큰 <출처: 작가, Matplotlib으로 생성>

여기서 예상과 다른 결과가 나왔습니다.

“120B 급인 gpt-oss-120b가 27B인 Qwen3.8-27B보다 훨씬 빨랐습니다”

보통 모델 이름에 표시된 파라미터 수만 보면 120B 모델이 27B 모델보다 훨씬 무겁고 느릴 것이라고 생각하기 쉽습니다. 하지만 실제 추론 성능은 그렇게 단순하게 결정되지 않았습니다. 이 차이를 이해하려면 모델 구조를 볼 필요가 있습니다. Qwen3.8-27B와 이번에 테스트한 Gemma4:31b는 대부분의 파라미터가 계산에 참여하는 Dense 모델입니다.

반면 gpt-oss는 여러 전문가 가운데 일부만 선택해서 사용하는 전문가 혼합(Mixture of Experts, MoE) 구조입니다. 예를 들어 gpt-oss-120b는 전체 약 117B 파라미터를 가지고 있지만 토큰 하나를 처리할 때 활성화되는 파라미터는 약 5.1B입니다. 다만 활성 파라미터 수가 적다고 해서 전체 모델을 저장하는 데 필요한 메모리까지 작아지는 것은 아닙니다. 모델 전체 가중치는 GPU 메모리에 올라가야 하기 때문에, MoE에서는 ‘실행 계산량’과 ‘모델을 올리는 데 필요한 메모리’를 구분해서 봐야 합니다.

여기에 MXFP4와 같은 실행 형식과 추론 최적화도 영향을 줍니다. 또한 두 모델은 실행 정밀도도 다르기 때문에 이번 결과를 MoE와 Dense 구조의 차이만으로 설명할 수는 없습니다. 물론 이 결과만으로 “MoE가 Dense보다 빠르다”라고 일반화할 수는 없습니다. 다만 모델 이름에 붙은 전체 파라미터 수만 보고 필요한 GPU나 추론 속도를 예상해서는 안 된다는 점은 분명했습니다. 즉, 두 모델은 실행 정밀도도 다르기 때문에 이번 결과를 MoE와 Dense 구조의 차이만으로는 설명할 수 없습니다.

사용자가 늘어나면 차이가 더 커졌습니다

다음에는 모델과 GPU를 그대로 두고, 동시 사용자를 시뮬레이션하기 위해 동시 요청 수만 늘렸습니다. 이 테스트가 필요한 이유는 단일 사용자에게 빠른 모델과 여러 사용자를 동시에 처리할 때 효율적인 모델이 반드시 같지는 않기 때문입니다. 개인용 AI라면 한 명이 얼마나 빠르게 답을 받느냐가 중요하지만, 수십 명이 사용하는 사내 챗봇이나 AI API라면 서버 전체가 동시에 얼마나 많은 요청을 처리할 수 있는지도 중요합니다.

동시 요청을 32개까지 늘렸을 때 gpt-oss-120b는 전체 약 845 tokens/s, Qwen3.8-27B는 약 369 tokens/s를 기록했습니다. 단일 요청에서 나타났던 차이가 동시 요청이 늘어난 환경에서도 이어졌습니다.

동시 요청 수 증가에 따른 모델별 전체 처리량 <출처: 작가, Matplotlib으로 생성>

여기까지 테스트하면서 첫 번째 기준이 생겼습니다. 모델의 크기로 성능을 예상하기보다 실제 사용할 모델과 GPU, 추론 엔진을 묶어서 측정해야 합니다.

모델은 그대로 두고 GPU 수를 늘렸다

GPU 1장, 2장, 4장을 차례로 비교했습니다

모델별 차이를 확인했으니, 다음에는 GPU 수를 바꿔봤습니다. 이번에는 gpt-oss-20b와 동시 요청 16개라는 조건을 고정했습니다. 바꾼 것은 하나의 모델을 몇 개의 GPU에 나눠 실행하느냐뿐입니다.

GPU 한 장을 사용하는 TP1에서는 약 1,248 tokens/s가 나왔습니다. GPU를 두 장으로 늘린 TP2에서는 약 1,749 tokens/s까지 올라갔습니다. 여기까지는 예상한 결과였습니다. 그런데 GPU를 네 장으로 늘리자 약 1,584 tokens/s로 오히려 떨어졌습니다. 즉, GPU 2장은 1장보다 약 40% 빨랐지만 GPU 4장은 2장보다 약 9% 느렸습니다.

gpt-oss-20b의 GPU 수에 따른 처리량 변화 <출처: 작가, Matplotlib으로 생성>

처음에는 GPU가 많아지면, 당연히 처리량도 계속 증가할 것으로 생각할 수 있습니다. 하지만 하나의 모델을 여러 GPU에 나누는 텐서 병렬화(Tensor Parallelism)에서는 GPU가 계산만 하는 것이 아닙니다. 서로 계산 결과를 주고받고 동기화하는 작업도 필요합니다.

이번 서버의 GPU 토폴로지도 확인했습니다. 네 GPU는 같은 NUMA 영역에 있었고 GPU 간 P2P 읽기와 쓰기도 정상적으로 지원했습니다. 다만 GPU끼리 연결되는 경로는 모두 PCIe Host Bridge를 거치는 PHB 구조였습니다. 이 결과만으로 PCIe가 TP4 성능 저하의 원인이라고 단정할 수는 없습니다. 하지만 GPU가 늘어나면서 증가한 통신과 동기화 비용이 추가 GPU에서 얻는 계산 이점을 일부 상쇄했을 가능성은 있습니다.

그래서 GPU 서버를 볼 때는 GPU 개수만 확인해서는 부족합니다. NVLink나 NVSwitch처럼 GPU 간 통신 대역폭이 높은 시스템에서는 여러 GPU에 하나의 모델을 분산하는 방식의 통신 부담을 줄이는 데 유리합니다. 반대로 PCIe 기반 서버에서 모델 하나가 GPU 한 장에 충분히 들어간다면 하나의 모델을 네 GPU에 나누는 것보다 각 GPU에 모델을 하나씩 실행하고 요청을 분산하는 방식이 더 효율적일 수도 있습니다.

결국 질문도 바뀌었습니다. “GPU가 몇 장 필요한가?”보다 “이 모델을 GPU 몇 장에 나누는 것이 좋은가?”가 더 정확한 질문이었습니다.

같은 모델도 FP8로 실행하니 달라졌습니다

GPU 수 다음에는 실행 정밀도를 바꿨습니다. 이번에는 Qwen3.8-27B의 원본 BF16 체크포인트와 FP8 양자화 체크포인트를 같은 GPU와 동시 요청 8개 조건에서 비교했습니다. BF16에서는 약 180 tokens/s, FP8에서는 약 271 tokens/s를 기록했습니다. 이번 테스트 환경에서는 FP8이 BF16보다 약 51% 높은 처리량을 보였습니다.

Qwen3.8-27B 기본 구성(BF16)과 FP8 구성의 처리량 비교 <출처: 작가, Matplotlib으로 생성>

BF16은 하나의 값을 16비트로 표현하지만 FP8은 8비트를 사용합니다. 따라서 FP8 양자화를 적용하면 모델 가중치의 메모리 사용량과 메모리 대역폭 부담을 줄일 수 있고, FP8 연산을 지원하는 GPU에서는 추론 처리량을 높일 수 있습니다. 다만 모든 연산이 반드시 FP8로 수행되는 것은 아니며, 실제 성능 향상은 모델의 양자화 방식과 GPU, 추론 엔진의 FP8 지원 방식에 따라 달라집니다. 하지만 이 방식이 무조건 좋은 것은 아닙니다. 모델 품질이 달라질 수도 있고, GPU와 추론 엔진이 해당 형식을 얼마나 잘 지원하느냐에 따라서도 결과가 달라집니다. 따라서 이 결과 역시 “FP8을 사용하면 항상 51% 빨라진다”라는 의미는 아닙니다.

여기서 확인한 것은 같은 모델과 같은 GPU라도 어떤 정밀도로 실행하느냐에 따라 성능이 크게 달라질 수 있다는 사실입니다.

빠르게 실행되는 것만으로는 충분하지 않았다

모델은 실행됐지만 첫 응답까지 15초가 걸렸습니다

여기까지는 주로 TPS를 봤습니다. 하지만 실제 챗봇을 운영한다면 처리량만큼 중요한 숫자가 TTFT입니다. 사용자는 AI가 답변 전체를 얼마나 빨리 완성하는지만 보는 것이 아니라 답변을 언제 시작하는지도 체감하기 때문입니다.

Mistral-Small-4-119B는 GPU 네 장을 사용한 TP4 환경에서 정상적으로 실행됐습니다. 하지만 동시 요청 8개에서 P95 TTFT가 약 15.8초였습니다. 즉 일부 요청에서는 첫 글자가 화면에 나타날 때까지 15초 이상 기다릴 수 있다는 의미입니다.

동시 요청 8개에서 모델별 P95 첫 토큰 응답 시간 <출처: 작가, Matplotlib으로 생성>

그렇다고 이 모델을 사용할 수 없다는 뜻은 아닙니다. 대량 문서를 밤새 처리하는 배치 작업이라면 첫 응답이 조금 늦더라도 전체 처리량이 더 중요할 수 있습니다. 반대로 고객 상담이나 사내 챗봇에서는 15초의 첫 응답 시간이 큰 문제가 될 수 있습니다.

그래서 모델의 TPS를 보기 전에 서비스의 목표를 정해야 합니다. 예를 들어, 대화형 서비스라면 ‘P95 TTFT 2초 이내’와 같은 서비스 수준 목표(SLO)를 먼저 정하고, 그 조건을 만족하는 범위에서 처리량을 비교하는 편이 훨씬 현실적입니다.

GPU 메모리가 충분해도 모델이 실행되지 않았습니다

또 하나 예상하지 못했던 문제는 소프트웨어 호환성이었습니다. GLM-5.3-Flash를 실행했을 때 처음 사용한 vLLM과 Transformers 조합에서는 모델 구조를 제대로 인식하지 못했습니다. Transformers를 업데이트해 다시 시도했지만 이번에는 기존 Gemma 실행 환경에 문제가 생겼습니다. GPU 수를 바꿔가며 시도했지만, 이번 테스트 환경에서는 다른 모델과 동일한 조건의 벤치마크까지 진행하지 못했습니다.

중요한 것은 이것을 “GLM은 vLLM에서 실행되지 않는다”라고 해석하면 안 된다는 점입니다. 공식 지원 여부와 별개로 우리가 사용한 정확한 버전 조합에서 바로 동작하지 않았다는 것이 이번 테스트에서 확인한 사실입니다. 직접 LLM을 운영하면 이런 문제가 생각보다 중요합니다. GPU만 확보하면 끝나는 것이 아니라 엔비디아 드라이버, CUDA, vLLM, Transformers와 모델 코드의 버전을 함께 관리해야 합니다. 여러 모델을 운영한다면 모델별로 검증된 컨테이너 이미지를 만들고 버전을 고정하는 이유도 여기에 있습니다.

너무 큰 모델은 실행하기 전에 걸러냈습니다

Kimi-K3는 아예 서버를 실행하기 전에 사전 검사 단계에서 중단했습니다. 확인한 모델 체크포인트의 크기가 약 1.56TB였습니다. 물론 체크포인트 파일 크기와 실제 추론 시 필요한 GPU 메모리가 정확히 일치하는 것은 아니지만 차이가 너무 컸기 때문에 현재 구성에서 그대로 실행하는 것은 현실적이지 않다고 판단했습니다. 클라우드 GPU에서는 이런 사전 검사가 곧 비용 절감입니다. 수백 GB의 모델을 내려받고 GPU 서버를 몇 시간씩 사용한 뒤 메모리 부족을 확인하는 것보다, 모델의 크기와 데이터 형식, 예상 메모리를 먼저 확인해 실행 가능성이 낮은 구성을 걸러내는 편이 낫습니다.

결국 ‘가장 빠른 모델’을 찾는 테스트가 아니었다

토큰 생성 속도를 비용으로 바꿔봤습니다

모델을 실제 서비스에 사용할 수 있다는 판단이 서면, 그다음에 비용을 볼 수 있습니다. 이번 테스트에서는 달러당 출력 토큰 수(Tokens per Dollar)를 사용했습니다.

Tokens/$ = Output TPS × 3,600 ÷ 시간당 서버 비용

이번 서버는 시간당 12달러이므로 Output TPS에 300을 곱하면 대략적인 Tokens/$가 됩니다. 예를 들어, gpt-oss-20b는 GPU 한 장, 동시 요청 32개 조건에서 약 1,688 output tokens/s를 기록했습니다. 이를 서버 전체 가격인 시간당 12달러로 계산하면 1달러당 약 50만 개의 출력 토큰, 100만 출력 토큰당 약 1.97달러입니다.

이 계산은 GPU 한 장을 사용한 처리량에 전체 인스턴스 비용을 적용한 보수적인 단순 계산입니다. 실제 서비스에서는 나머지 GPU를 다른 모델 복제본이나 다른 요청 처리에 활용할 수 있으므로 실제 서버 전체의 Tokens/$는 달라질 수 있습니다.

<출처: 작가, 테스트 조건에서 계산한 모델별 달러 당 생산 토큰 - Matplotlib으로 생성>

여기에는 중요한 조건이 있습니다. 실제로는 GPU 한 장만 사용했지만, 비용 계산에는 GPU 네 장이 포함된 서버 전체 가격을 넣었습니다. 따라서 나머지 GPU 세 장까지 모델 복제본을 배치해 사용한다면, 서버 전체의 경제성은 달라질 수 있습니다. 반대로 자체 LLM에는 GPU 비용 외에도 저장 공간, 모니터링, 보안, 장애 대응과 엔지니어링 비용이 들어갑니다. 그래서 이 숫자를 상용 AI API 가격과 바로 비교해 어느 쪽이 싸다고 결론 내리기는 어렵습니다.

품질 → 서비스 속도 → 비용 순서로 봐야 합니다

테스트에서는 모든 모델의 업무 품질을 동일한 데이터 셋으로 평가하지 않았습니다. 따라서 gpt-oss-20b의 처리량이 가장 높았다고 해서 이 모델이 모든 업무에서 가장 좋다고 결론 내릴 수 없습니다. 실제 기업에서 모델을 고른다면 순서를 반대로 잡는 편이 낫습니다.

먼저 업무 품질을 만족하는지 확인합니다. 그다음 서비스가 요구하는 TTFT와 처리량을 만족하는지 확인합니다. 마지막으로 이 두 조건을 통과한 모델끼리 비용을 비교합니다. 예를 들어 저렴한 모델의 정확도가 업무에 필요한 수준보다 낮다면 높은 Tokens/$는 의미가 없습니다. 반대로 두 모델 모두 필요한 품질과 P95 TTFT를 만족한다면 그때는 1달러로 더 많은 요청을 처리하는 모델이 경제적인 선택이 됩니다.

이번 벤치마크를 진행하면서 가장 크게 바뀐 생각도 이 부분입니다. 처음에는 TPS → TTFT → 비용을 비교하면 모델을 고를 수 있을 것이라고 생각했습니다. 실제로 테스트해 보니 품질 → SLO → 비용 순서가 더 현실적이었습니다.

상용 AI와 오픈 웨이트도 같은 기준으로 볼 수 있을까?

여러 오픈 웨이트 모델을 직접 설치하고 테스트를 하면서 역설적으로 상용 AI 서비스의 장점도 더 분명하게 보였습니다. GPT, Claude, Gemini 같은 서비스를 사용하면 앞에서 경험한 GPU 메모리 계산이나 모델별 라이브러리 호환성, GPU 간 통신 방식 등을 대부분 고민하지 않아도 됩니다. API를 호출하면 되고 새로운 모델이 등장하더라도 기업이 직접 GPU 환경을 다시 설계할 필요가 없습니다.

그럼에도 기업이 오픈 웨이트 모델을 검토하는 이유는 분명합니다. 대표적인 것이 데이터 통제입니다. 기업 내부에는 소스코드와 설계 문서, 계약서, 연구 자료, 고객 정보처럼 외부 AI 서비스로 전달하기 어려운 데이터가 존재합니다. 특정 산업에서는 데이터가 어디에서 처리되는지, 누가 접근할 수 있는지, 어떤 모델 버전이 사용됐는지까지 조직이 직접 관리해야 할 수도 있습니다. 외부 인터넷과 연결되지 않은 폐쇄망에서는 오픈 웨이트 모델이 단순히 API 비용을 절감하는 방법이 아니라 해당 환경에서 생성형 AI를 사용할 수 있게 만드는 방법 자체가 될 수 있습니다.

결국 기업에서는 둘 중 하나를 고르는 것보다 함께 사용하는 방식이 더 현실적일 수 있습니다. 일반적인 반복 업무는 비용 효율이 높은 오픈 웨이트 모델로 처리하고, 외부 반출이 어려운 데이터는 기업이 통제하는 프라이빗 LLM으로 보냅니다. 높은 수준의 추론이 필요한 요청은 정책이 허용하는 범위에서 GPT · Claude · Gemini 같은 상용 모델로 전달할 수 있습니다. AI 게이트웨이가 요청의 성격에 따라 이런 경로를 선택하는 구조입니다.

마치며: 가장 좋은 것보다 우리에게 맞는 모델을 찾는 과정

이번 테스트에서는 기대했던 결과만큼이나 부정적인 결과도 많이 나왔습니다. 물론 진행한 테스트 방법이나 도구가 올바르지 않았을 가능성도 있습니다. 또 GPU를 늘렸는데 성능이 떨어졌고, 정상적으로 실행했지만 첫 응답이 너무 느린 모델도 있었죠. 소프트웨어 호환성 때문에 벤치마크 자체를 시작하지 못한 모델도 있었고요. 처음에는 이런 결과를 실패한 실험이라고 생각하기 쉽지만, 실제 개발 환경에서는 오히려 이런 데이터가 더 중요한 판단 근거가 됩니다.

그래서 개발자가 오픈 웨이트 모델을 검토한다면, 공개 벤치마크에서 가장 높은 점수를 받은 모델부터 찾기보단 AI 업무에서 필요한 품질을 만족하는지, 서비스가 요구하는 응답 속도를 지키는지, 그리고 그 모든 조건에서 비용이 합리적인가를 차례대로 확인하는 편이 좋습니다.

새로운 모델이 나올 때마다 순위표를 그저 따라가지 않고, 같은 조건에서 모델을 직접 검증하고 다시 비교할 수 있는 환경을 갖춘다면, 더 오래가는 AI 모델 선택의 기준이 되지 않을까 싶습니다.

]]>

월 10만 원으로 짜는 직군별 AI: 뭐부터 결제해야 할까?

AI는 정말로 일을 잘합니다. 그래서 돈도 안 쓰고 AI를 누리는 건 반칙 같기도 합니다. 특히 일할 때 쓰는 AI는요.

물론 그만큼 요즘 AI는 돈을 내면 정말 돈값을 정말 잘합니다. 크고 복잡한 판단을 반복해서 다루는 작업, 워터마크 없는 산출물, 내 파일을 읽고 다루는 업무용 챗, 그리고 에이전트. 공짜 AI는 그 무엇으로도 해결할 수 없는 이 작업들이 바로 돈을 쓰기 시작하는 지점입니다.

그렇다고 그 비싼 200달러 요금제를 턱턱 결제하는 건 또 고민해 봐야 합니다. 매달 30만 원 가까운 돈을 쓰는 거잖아요?

10만 원은 요즘 환율(1,369원/달러)로 약 73달러입니다. 반면 범용 AI 서비스의 유료 요금제는 약속이라도 한 듯 20달러 언저리에 모여 있습니다. 챗GPT 플러스 20달러, 클로드 프로 20달러, 구글 AI 프로는 한국 돈으로 월 2만 9천 원. 그러니 이 예산은 “20달러짜리 AI 세 개에 잔돈 조금” 정도 크기입니다. 따라서 이 돈을 쓸 때 필요한 건 올바른 배분입니다. 뭘 사서 메인으로 쓰고, 남는 돈은 어디에 쓸지의 문제죠. 그리고 그 결정은 AI로 뭘 할지에 달려 있습니다.

회사 지원은 여전히 0원이지만 내 돈 월 10만 원까지는 써볼 마음이 생겼을 때, 어디부터 바꾸는 게 이득인지 정리했습니다.

참고로 이 글은 예산별 AI 추천 3부작 중 2편입니다. 1편에서 0원 무료 스택을 다뤘고, 다음 편은 구독료 걱정 없이 일단 지르고 싶을 때를 다룹니다.
가격은 전부 2026년 9월 9일에 확인한 값이고, 원화 환산은 같은 시기 환율(1,369원/달러) 기준입니다. 부가세 포함 여부가 도구마다 달라 실제 청구액은 조금씩 다를 수 있고, 요금제가 워낙 휙휙 바뀌니 결제 전에 공식 페이지를 한 번 더 확인하길 권합니다.

10만 원의 행복: 몰빵이냐, 분산이냐

돈이 생기면 가장 먼저 드는 유혹이 있습니다. 제일 좋다는 것 하나에 전부 태우는 거죠.

그런데 이 예산으로는 몰빵이 성립하는 카드 자체가 생각보다 적습니다. 20달러 표준가 위로 올라가는 순간 가격이 세 배, 다섯 배로 뛰어서 중간이 별로 없거든요.

나도 최고 좋은 AI 쓸래요

물론 가장 좋은 AI들이 있습니다. 페이블, 아스트라 이런 슈퍼 모델을 꽤 오랜 시간 쓸 수 있는 요금제죠. 다만, 정말 비쌉니다.

클로드 Max 5x: 월 100달러, 원화로 약 13만 7천 원. 10만 원을 37%나 넘깁니다. 상위 티어 20x는 200달러로 엄두도 잘 안 납니다.
챗GPT 프로: 마찬가지로 월 100달러부터 시작. 요즘 성능 미쳤다는 아스트라와 GPT-image-2의 이미지 생성이 탐나지만, 이것 역시 한도를 넘깁니다.
퍼플렉시티 맥스(월 200달러), 구글 AI 울트라(한국 월 11만 9천/30만 원) 모두 예산 밖입니다.

한편 이름난 도구 중 예산 안에 남는 건 아래 두 가지 정도입니다.

커서(Cursor)프로+: 월 60달러, 약 8만 2천 원. 예산 안에서 몰빵으로 살 수 있는 코딩 도구 중 하나입니다.
미드저니 프로: 월 60달러, 약 8만 2천 원. 이미지를 양산하는 사람이라면 꽤 매력적인 선택지입니다.

그러면 적당히 나눠 쓰는 것이 어떨까?

반대로 분산한다 생각해 보면, 챗GPT, 클로드 같은 20달러 요금제 석 장에 60달러, 약 8만 2천 원이 들어갑니다. 잔돈 13달러(약 1만 8천 원)가 남는데 이게 마침 코파일럿이나 캔바급 특화 AI 도구 하나를 살 수 있는 정도입니다.

그래서 제 추천은 이렇습니다. 기본은 분산. 범용 AI들은 서로 대체재에 가까워서 같은 성격의 AI를 두 개 이상 사는 순간 두 번째 계정의 가치가 뚝 떨어집니다. 같은 질문을 두 군데 던질 일은 생각보다 없거든요.

상상해 보죠. 챗GPT 플러스와 클로드 프로를 같이 결제했습니다. 처음 결제하면 파일 첨부가 뚫리고 이미지가 생기고 에이전트가 열리니 체감이 확실합니다. 그런데 두 번째 AI가 주는 것도 결국 같은 겁니다. 아침에 켜 두는 채팅 창이 하나 늘었을 뿐, 오늘 처리할 수 있는 일의 종류는 거의 그대로죠. 반면 여기에 캔바나 코파일럿 같은 특화 AI를 붙였다면 어제까지 아예 못 하던 일을 하나 더 할 수 있습니다.

몰빵이 나은 경우는 하나입니다. 그 도구 하나가 곧 내 업무의 파이프라인을 책임질 때. 하루 종일 에이전트 코딩을 돌리는 개발자, 이미지 결과물이 곧 매출인 프리랜서가 여기 해당합니다. 그런 독자라면 이 글의 답은 여기서 끝났습니다. 커서 프로+ 또는 미드저니 프로에 태우고 나머지는 1편의 무료 AI를 유지하세요. 아니, 사실 제일 추천하는 건 예산을 200달러로 올리는 겁니다.

처음 20달러 결제할 범용 AI: 챗GPT vs. 클로드 vs. 제미나이

분산으로 정했다면 첫 20달러를 태울 용도는 사실 정해져 있습니다. 범용 AI 하나. 1편에서 무료로 아껴 쓰던 바로 그 서비스들의 유료 버전입니다. 문제는 셋 중 무엇이냐는 건데, 힌트는 “무료에서 정확히 어디가 막혔는가”에 있습니다. 1편에서 셋의 무료 한도 성격이 서로 달랐던 것처럼, 유료로 사는 것의 성격도 셋이 다르거든요.

챗GPT 플러스: 텍스트 무제한 위에 ‘모드’

챗GPT는 무료 계정도 텍스트 대화가 이미 무제한입니다. 그래서 플러스로 사는 건 그 위에 얹히는 기능들입니다. 최신 세대 모델에 더해 Deep Research, 이미지 생성, 웹 화면을 대신 조작해 주는 Agent 모드, 코딩 에이전트 Codex까지 이 20달러에 포함입니다. 무료 계정을 연습장 삼아 충분히 굴려봤다면 이 중 어떤 모드가 아쉬웠는지도 이미 몸으로 알고 있을 겁니다.

언제 결제할까: 무료의 텍스트 무제한으로 버티다가 이미지 생성·파일 첨부·에이전트 모드 한도에서 막힌 사람. 장표에 넣을 이미지를 뽑다가 한도에 걸려 내일을 기다리는 날, 긴 PDF를 통째로 첨부하는 대신 본문을 잘라 붙여넣고 있는 스스로에게 질렸을 때가 신호입니다.
한계·주의: 저가형 챗GPT Go(월 8달러, 약 1만 1천 원)를 그저 “오, 플러스 반값”으로 오해하면 곤란합니다. Codex는 무료·Go 플랜에서도 제공되지만 플랜별 사용량이 다르므로, 필요한 기능과 한도를 비교해야 하거든요. 위로는 프로(월 100·200달러)가 있지만 예산 밖입니다.

클로드 프로: 클로드 코드를 써보고 싶다면

월 20달러, 연 결제면 월 17달러꼴(약 2만 3천 원)입니다. 범용 AI 가격에 터미널 코딩 에이전트 클로드 코드가 포함됩니다. 사실 모든 유료 요금제에 클로드 코드가 들어가는데요, 프로가 그중 제일 싼 겁니다. 다만, 글쎄요. 20달러로 클로드 코드를 쓸 때는 툭하면 “벌써 끝이야?”라는 말이 나오기 쉽습니다.

언제 결제할까: 무료 한도가 업무 리듬을 끊는 사람. 오후 집중 시간에 코드 리뷰나 문서 퇴고를 시키다 한도가 차서 맨날 손 놓고 있다면 그게 결제가 필요한 순간입니다. 특히 채팅과 에이전트 코딩을 하나로 해결하고 싶은 사람에게는 꽤 유용하죠.
한계·주의: 사용량 한도를 일반 채팅과 클로드 코드가 공유합니다. 에이전트를 세게 돌린 날은 채팅창도 같이 막히고요. 워낙 한도 차는 일이 잦아서 상위 티어 Max 5x(월 100달러, 약 13만 7천 원)가 엄청 땡깁니다.

구글 AI 프로: 구독 한 번에 구글 전체를

한국 기준으로 월 2만 9천 원. 이 정도 돈을 내면 묶음 상품이 옵니다. 제미나이 상위 모델과 Gmail·Docs 연동, Gemini Notebook(구 노트북LM) 프로 등급이 열리며 노트북당 소스 300개, Standard 대비 4배 사용량이 제공되고요, 5TB 스토리지도 함께 쓸 수 있습니다. 코딩 IDE 안티그래비티의 유료 쿼터도 별도 구독 없이 딸려 옵니다. 말하자면 작은 워크스페이스 하나를 통째로 들이는 셈인데, 이 묶음이 구글의 최고 장점입니다.

언제 결제할까: 자료가 이미 구글에 쌓여 있는 사람, 노트북LM의 무료 사용량 한도가 막힌 사람 등. 월요일 아침 한 주치 회의록을 노트북LM에 밀어 넣거나 제미나이로 이런저런 이미지 만들다 막힌 분들이라면 고려할만 합니다.
한계·주의: 노트북LM 프로는 단독 구매가 없습니다. 개인용으로는 이 번들이 대표적이고, Workspace·Google Cloud를 통한 이용 경로도 있어요. 염가형 AI 플러스(한국 월 7,500원)는 필요한 기능과 한도를 비교해 볼 만합니다. 울트라(한국 월 11만 9천·30만 원)는 역시 예산 밖.

그래서 세 개 중 무엇이 좋냐고요? 저는 그렇게 생각합니다. 사실 정답이 없다고요.

내가 갑갑한 부분이 어딘지 좀 살펴보면 도움이 될지 모르겠네요. 첨부 파일이나 이미지 활용이 많으면 챗GPT, 코드가 중심이면 클로드, 자료가 구글에 있으면 구글. 반대로 무료로 써도 괜찮다면 사실 꼭 필요하지 않을 수도 있습니다. 돈을 내야 제대로 쓸 마음이 먹어지는 분들 말고요.

자, 뭘 살지 결정하셨나요? 그럼 남은 돈은 무슨 작업을 할지에 따라 확실하게 정하는 편이 좋습니다.

할 일별 스택 정하기

여기서부터는 장바구니입니다. 범용 AI 하나 사고 남는 예산을 직군별로 배분한 조합 네 벌을 짰습니다. 참고로 피그마(Figma)나 MS 코파일럿처럼 회사가 이미 돈을 내는 구독에 딸려온 AI는 예산으로 다시 사지 않습니다.

일반 사무: 챗GPT 플러스 + 클로드 프로 + 선택 한 자리(기본 월 40달러, 약 5만 5천 원)

이 직군만 예외적으로 범용 AI를 두 개 배정했습니다. 방금 대체재라고 했는데 왜 두 장이냐고요? 챗GPT 플러스가 첨부 파일 처리와 이미지·에이전트 모드를 맡고, 클로드 프로는 문서와 표를 처리하는 업무용으로 좀 더 밀어 써보자는 조합입니다. 메일을 고치고, 보고서를 다듬고, 여러 파일을 표로 정리하는 일이 많다면 어느 날은 계정 하나로 부족할 수 있거든요. 문서 작업이 많은 사람에게 권하는 두 번째 도구인 셈이죠.

세 번째 자리는 비워 뒀습니다. 각자 좀 더 필요한 영역이 다르니까요. 그 대신, 일에서 비중이 크고 돈을 내면 성능이 확실히 달라지는 영역 2가지를 추천합니다.

AI 회의록: 티로, 콜라보를 추천합니다. 실시간 요약과 회의록 양식이 필요하면 티로, 주요 논의와 할 일을 정리해 공유하려면 콜라보를 비교해 보세요. 둘 다 한국어 기반 서비스라 한국어 회의 기록에 강한 편입니다.
번역: 딥엘(DeepL)과 파파고 플러스가 후보입니다. 딥엘은 파일 형식을 유지한 번역을, 파파고 플러스는 HWPX를 포함한 사무 문서 번역을 지원합니다.
잔돈: 기본 구독 2개만 계산하면 약 4만 5천 원이 남습니다. 남는 걸 효율적으로 써 봅시다.

개발: 클로드 프로 + 커서 프로 + 깃허브 코파일럿 프로(월 50달러, 약 6만 8천 원)

예산 짤 때 선택지가 꽤 괜찮은 직군입니다. 클로드 프로로 채팅을 커버하고, 그 덕에 쓸 만한 코딩 에이전트인 커서 프로와 깃허브 코파일럿을 살 수 있으니까요. 클로드로는 일반적인 도움이 필요한 일들을 맡기고, 커서가 에디터 안에서 확인해 가며 고치는 업무를, 코파일럿은 자잘한 자동완성이나 깃허브 연동 작업에 써 볼 만합니다.

커서 프로(월 20달러, 약 2만 7천 원): 플랜 가격만큼의 월 크레딧 풀에 Tab 자동완성 무제한(Auto 모드는 모델 가격에 따라 과금), 프론티어 모델과 MCP·Cloud Agents 지원까지. 에디터 중심 에이전트 코딩의 표준입니다. 다만 과금 구조가 자주 변합니다. Opus급 비싼 모델을 지정하면 크레딧이 순식간에 증발하고요.
깃허브 코파일럿 프로(월 10달러, 약 1만 4천 원): 인라인 자동완성과 다음 편집 제안은 무제한. 챗·에이전트·코드 리뷰는 월 1,500크레딧으로 셉니다(2026년 6월 크레딧제 전환, 1크레딧=0.01달러). 다만 에이전트를 주력으로 쓸 거면 이것보다는 클로드·커서 쪽에 태우는 게 맞습니다.
그럴 바엔 몰빵: 에이전트 코딩이 업무의 전부라면 이런 거 저런 거 사는 대신 커서 프로+(월 60달러, 약 8만 2천 원) 하나 구독하는 게 나을 수 있습니다.
잔돈: 23달러(약 3만 1천 원). 좀 여유롭습니다. 대신 한도는 단연코 제일 모자랄 겁니다. 사실 제대로 믿고 맡기려면, 100달러 이상 선택지를 가장 먼저 만지작거리게 되는 직군입니다.

디자인: 챗GPT 플러스 + 캔바 프로 + 미드저니 Basic(월 30달러+9,900원, 약 5만 1천 원)

디자인 직무의 범용 AI는 챗GPT 플러스가 무난합니다. 미드저니에 견줄 만큼, 어쩌면 그보다 더 이미지를 잘 뽑거든요. 기획과 카피, 시안 방향을 잡는 러프 이미지까지 여기에 맡깁니다. 그 위에 제작 도구를 두 개 얹는데요, 템플릿 기반 편집과 실무 산출물은 캔바, 순수 이미지 생성은 미드저니를 일반적으로 추천합니다. 미드저니가 최종 품질을, 캔바가 배너·썸네일 같은 실무 마감을 맡는 흐름이죠.

캔바 프로(한국 월 9,900원, 연 결제 시 99,000원으로 월 8,250원꼴): Magic Eraser, 배경 제거, AI 프레젠테이션이 풀리며, 프리미엄 템플릿이 열립니다. 무료 크레딧을 아껴 쓰다 배경 제거가 급해진 날에 결제를 고민해 볼 만합니다.
미드저니 Basic(월 10달러, 약 1만 4천 원): fast GPU 3.3시간짜리 맛보기 티어입니다. relax 무제한 생성은 Standard(월 30달러, 약 4만 1천 원)부터라서, 이미지 생산이 업무의 중심이면 Standard로 올리는 것도 고려해 보세요.
피그마는 개인도 쓸 수 있고 AI 기능도 매우 뛰어나지만, 여기서는 콘텐츠 디자인 중심으로 골라 후보에서 뺐습니다. 그래서 이 조합은 일반 콘텐츠 작업에 치중한 느낌이 나네요. 다른 특화 디자인 툴을 쓴다면, 기본 결제 라인에 AI 기능이 포함되는지 잘 확인하기를 추천합니다.
잔돈: 약 4만 9천 원. 미드저니 Standard 승급(+20달러)을 위한 저축분으로 두겠습니다. 게다가 이쪽은 워낙 툴이 다양해서 이것저것 테스트하는 것도 추천합니다. 영상을 많이 쓰는 분들이라면 힉스필드(Higgsfield)가 유명합니다. 조금 비싸긴 하지만요.

리서치/기획: 구글 AI 프로 + 퍼플렉시티 프로 + 젠스파크 플러스(월 44.99달러+2만 9천 원, 약 9만 1천 원)

정보를 모으고 정리해서 문서와 슬라이드로 내보내는 일을 주로 한다면, 범용 AI는 일단 제미나이를 추천해 봅니다. 검색에 강하고 노트북LM이 좋으니까요. 한편 여기 도구들은 서로 대체가 잘 안 됩니다. 웹에서 모으는 일, 모은 것을 내 자료와 함께 정리하는 일, 정리한 것을 슬라이드로 내보내는 게 각각 다른 도구의 강점이라 하나만 빼도 좀 애매해질 수 있습니다.

구글 AI 프로: 개인적으로 이런 일을 할 때 정말 좋은 건 노트북LM 프로 등급이라고 봅니다. 내 자료를 넣어 정리하는 데 이만한 도구가 잘 없습니다.
퍼플렉시티 프로(월 20달러, 약 2만 7천 원): 웹의 최신 정보를 모으는 데는 여전히 퍼플렉시티가 떠오릅니다.
젠스파크 플러스(월 결제 24.99달러, 약 3만 4천 원, 연 결제 시 월 19.99달러): 월 1만 크레딧. 슬라이드를 아주 많이 수정하거나 여러 개 만들어야 하는 날이 반복되면 결제해 볼 만합니다. 다른 자잘한 에이전트 작업도 도와주고요.
잔돈: 약 9천 원. 여기서는 선택지가 분명하고 체급 좋은 도구가 많아 돈이 별로 안 남네요.

직군별 장바구니

네 가지 직무별 추천을 표로 정리했습니다.

마치며

10만 원. 작다면 작지만, 꽤 큰 돈입니다. 봤다시피 어느 조합도 10만 원을 꽉 채우지 않았는데요. 일부러 그렇게 짰습니다. 20달러 정도를 범용 AI에 투자한다 해도, 남은 돈으로 아주 다양한 도구를 테스트할 수 있으니까요.

AI 도구들은 정말 많이 쏟아지고 있고, 대부분은 한 번쯤 구독해 봐야 결과가 제대로 나옵니다. 지금 추천한 것들은 정말로 범용적인 도구들뿐입니다. 나한테 가장 큰 효능감을 줄 도구는 어디 숨어 있을지 모릅니다. 그러니 다양하게 써보고, 아, 이거다 싶으면 연 결제로 확 올려서 예산을 배정해 볼 것을 추천합니다.

그리고 사실 ‘진짜 AI’들은 이 예산으로 손에 넣을 수 없습니다. 클로드 Max, 챗GPT 프로처럼 월 100달러부터 시작하는 그것들이죠. 다음 편에서는 구독료 걱정 없이 일단 지르고 싶을 때, 그 돈값을 하는 조합은 무엇인지 다루겠습니다.

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

]]>

플러그인 개발의 새로운 표준 'Agent Plugins 1.0'

바이브코딩이나 다양한 AI 도구를 개발에 활용하면서 필요한 플러그인을 설치해 사용하고 계실 텐데요. 이 글을 쓰는 저 역시 수많은 플러그인을 사용하고 있습니다. 그런데 이렇게 설치된 플러그인이 어떤 구조로 되어 있는지 궁금해 보신 적 있으신가요?

<출처: Google for Developers Blog>

저도 호기심에 ~/.cursor/plugins 폴더를 열어본 게 시작이었습니다. 대표적으로 Atlassian 플러그인 하나를 열었더니 매니페스트가 세 벌이나 있었습니다. .cursor-plugin/plugin.json, .claude-plugin/plugin.json, 그리고 gemini-extension.json. 플러그인은 분명 한 개인데 매니페스트 파일은 왜 세 개씩 필요했을까요?

스킬 폴더도 사정이 비슷했습니다. Supabase 플러그인 디렉터리에는 SKILL.md, AGENTS.md, CLAUDE.md, README.md 4개가 한꺼번에 들어 있었습니다. 사실 AI 도구마다 인식하는 설정 파일명이 제각각이라 이렇게 중복으로 만들어 둔 것입니다. 이렇게 되면 유지보수할 때 뭐 하나 수정하면 모두 동일하게 수정해야 하는 번거로움이 발생할 수밖에 없습니다.

<출처: 작가, Plugin 설치 상태>

바로 이런 파편화와 중복 관리의 고통을 끝내겠다고 2026년 7월에 나온 규격이 ‘Agent Plugins 1.0.0’ 표준입니다. 이건 스킬 문서와 MCP 도구를 구조적 규격화해 Cursor든 Gemini든 똑같이 사용 할 수 있게 하는 표준 규약입니다. 그런데 아직도 실제 플러그인들은 중복 구조를 여러 벌 들고 있었습니다.

표준이 나온 지 얼마 안 됐으니 그럴 수 있겠다는 생각이 들면서도, 그렇다면 지금 스펙 문서 그대로 플러그인을 한 벌만 만들면 다 되는 건지 궁금해졌습니다. 그래서 작은 플러그인을 하나 직접 만들어서 테스트를 진행해 봤습니다.

Agent Plugins 1.0.0이란?

우선 Agent Plugins에 대해 간단히 소개하자면, Agent Plugins 1.0.0은 재사용 가능한 컴포넌트를 배포 가능한 플러그인 단위로 패키징하는 표준 입니다. Amazon, Cursor, Microsoft, OpenAI, Vercel이 참여한 기술 운영 위원회(TSC)가 2026년 7월에 1.0.0 규격을 발표했고, 이후 구글이 코어 메인테이너로 합류했습니다.

여기서 다루는 요소들의 역할은 다음과 같습니다.

스킬(Agent Skills): 에이전트가 어떻게 판단하고 작업할지 정의하는 자연어 지침(SKILL.md)입니다.
MCP 서버(Model Context Protocol): 에이전트가 실제로 명령을 실행하거나 데이터를 가져오는 실행 도구(mcp.json)입니다.
Agent Plugins: SKILL과 MCP를 결합하여, Cursor든 Claude Code든 이기종 AI 환경 어디서나 동일하게 인식하도록 묶은 단일 패키지 규격(plugin.json)입니다.

이 표준이 나오기 전까지는 스킬과 MCP 도구를 묶어주는 단위가 없었습니다. 깃허브 저장소에서 SKILL.md를 내려받아 도구별 폴더로 직접 복사해야 했고, MCP 서버는 README.md에 적힌 설정 내용을 찾아 IDE에 일일이 등록해야 했죠. SKILL과 MCP가 사실상 한 쌍으로 움직여야 하는데도 각자 따로 돌아다니다 보니, 어느 한쪽만 업데이트 되면 버전이 틀어지는 문제가 빈번하게 발생했습니다.

Agent Plugins는 README.md에 텍스트로 적어두던 수동 설정을 표준화된 디렉터리 구조로 변경되었습니다. SKILL과 MCP가 정해진 위치에 있어야 하고 AI 도구들은 정해진 위치에서 이를 찾아 사용합니다. 덕분에 플러그인을 설치하고 사용하는 과정이 훨씬 간편해졌습니다.

구글(Google)은 에이전트 도구 생태계를 ① 발견(Discovery) → ② 기술/카탈로그(Catalog) → ③ 포장(Packaging) → ④ 실행(Execution)의 4단계로 정의했습니다. 이 중에서 Agent Plugins 1.0.0이 맡은 역할은 오직 ③ 포장뿐입니다. 내부 컴포넌트가 어떻게 동작하고 어떤 프로토콜로 통신하는지는 기존의 Agent Skills와 MCP 규격을 그대로 따르며, 이번 표준은 ‘파일과 폴더를 어디에 배치할 것인가’의 패키징 영역만 다루고 있습니다.

스펙 문서에서 규정한 핵심 규칙은 크게 세 가지입니다.

경로의 엄격한 고정: 스킬은 반드시 skills/<skill_name>/SKILL.md에 위치해야 하며, MCP 서버 선언은 최상위 mcp.json에 작성해야 합니다. plugin.json에서 임의로 경로를 변경하거나 컴포넌트를 인라인으로 선언하는 것은 허용되지 않습니다.
독립 실패(Independent Failure) 원칙: 플러그인에 포함된 특정 MCP 서버가 환경 불일치나 포트 충돌로 실행되지 않더라도, 클라이언트는 해당 도구만 건너뛰고 나머지 스킬과 도구를 정상적으로 로드합니다. 부품 하나가 고장 났다고 플러그인 전체가 멈추지 않도록 설계되었습니다.
의도적인 스코프 제외: 설치 방식, 원격 배포 프로토콜, 권한 모델, 샌드박싱, 출처 검증, 사용자 경험(UX)은 v1 스펙 범위에서 명시적으로 제외되었습니다. 데스크톱 IDE, 터미널 CLI, 클라우드 환경마다 요구되는 보안 제약이 다르기 때문에 런타임 클라이언트의 재량에 맡긴 것입니다.

스펙만 보고 만든 gen-test-doc 플러그인

실제로 스펙대로 만들면 잘 동작하는지 확인하기 위해 무엇을 만들지 고민했습니다. 스킬만 넣으면 텍스트 파일 하나라 표준의 절반밖에 못 써보고, MCP 서버만 넣으면 굳이 이 포맷을 쓸 이유가 없거든요. 결국 판단 규칙과 실행 도구가 둘 다 필요한 작업으로 골랐습니다. 소스 코드를 읽고 단위 테스트와 API 문서를 만들어주는 gen-test-doc-plugin입니다. 어떤 케이스를 테스트로 뽑을지 정하는 건 스킬에 맡기고, 실제로 테스트를 돌려 결과를 가져오는 건 MCP에 맡겼습니다.

완성된 디렉터리는 이렇게 생겼습니다.

gen-test-doc-plugin/
├── plugin.json                 # 플러그인 매니페스트
├── skills/
│   └── gen-test-doc/
│       ├── SKILL.md            # 단위 테스트 및 문서 생성 지침
│       └── references/
│           └── doc-template.md # API 문서 양식
├── mcp.json                    # MCP 서버 설정
└── scripts/
    └── test-runner.js          # stdio MCP 서버 구현

매니페스트에 꼭 넣어야 하는 필드는 두 개뿐이었습니다. 로컬에서 돌려보는 정도라면 이게 전부예요.

{
  "$schema": "https://agent-plugins.org/schemas/v1/plugin.json",
  "name": "gen-test-doc"
}

스키마에는 version, description, author, license 같은 메타데이터 필드도 있습니다. 카탈로그에 올리거나 배포할 때 쓰는 값들이라, 아직 그 단계가 아니면 $schema와 name만 적어도 됩니다.

스킬 파일 skills/gen-test-doc/SKILL.md에는 프롬프트에 매번 치기 번거로운 규칙들을 담았습니다. 함수 시그니처만 보고 넘겨짚지 말고 실제 호출부까지 찾아서 확인할 것, Happy Path만 쓰지 말고 빈 배열이나 네트워크 지연 같은 경계 조건을 셋 이상 넣을 것, 그리고 생성한 문서는 references/doc-template.md 양식을 사용하라는 형태의 내용입니다.

name: gen-test-doc
description: 소스 코드를 분석해 단위 테스트와 기술 문서를 만듭니다.

테스트 및 문서 생성 지침

지정한 대상 소스 코드를 분석할 때는 반드시 다음 순서로 작업합니다.

1. 대상 파일의 함수와 클래스 시그니처뿐 아니라, 실제 프로젝트 내 호출부(Call site)를 검색해 실제 입출력 형태를 확인합니다.

2. 단위 테스트 작성 시 정상 케이스(Happy Path) 외에 다음 경계 조건을 최소 3개 이상 포함합니다.

빈 입력값, Null, Undefined 전달 상황
비동기 호출 실패 또는 타임아웃 상황
유효하지 않은 타입이 인자로 전달되는 예외 상황

3. 생성하는 기술 문서는 `references/doc-template.md` 양식에 맞추어 마크다운으로 작성합니다.

mcp.json에는 작성한 테스트를 돌려 결과를 가져오는 도구 하나를 선언했습니다.

{
  "$schema": "https://agent-plugins.org/schemas/v1/mcp.json",
  "mcpServers": {
    "test-runner": {
      "type": "stdio",
      "command": "node",
      "args": ["${PLUGIN_ROOT}/scripts/test-runner.js"]
    }
  }
}

스크립트 scripts/test-runner.js는 표준 입출력으로 통신하는 작은 MCP 서버입니다. run_tests라는 도구 하나를 열어두고, 호출이 들어오면 npm test를 띄워 표준 출력과 종료 코드를 JSON-RPC 형식으로 돌려줍니다.


import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { execFile } from "child_process";

const server = new Server(
  { name: "test-runner", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "run_tests",
      description: "지정한 테스트 파일이나 기본 단위 테스트를 실행합니다.",
      inputSchema: {
        type: "object",
        properties: {
          testPath: {
            type: "string",
            description: "실행할 테스트 파일 경로 (생략 시 전체 실행)",
          },
        },
      },
    },
  ],
}));
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name !== "run_tests") {
    throw new Error(`Unknown tool: ${request.params.name}`);
  }
  const testPath = request.params.arguments?.testPath || "";
  return new Promise((resolve) => {
    execFile("npm", ["test", "--", testPath], (error, stdout, stderr) => {
      resolve({
        content: [
          {
            type: "text",
            text: JSON.stringify({
              exitCode: error ? error.code : 0,
              stdout,
              stderr,
            }),
          },
        ],
      });
    });
  });
});

const transport = new StdioServerTransport();
await server.connect(transport);

여기까지 작업하는 데 5분도 채 걸리지 않았습니다. 스펙 문서대로 폴더를 만들고 매니페스트와 스킬, MCP 서버 파일을 제자리에 넣기만 하면 끝이었죠. 예전처럼 IDE마다 설정 파일을 따로 열어 경로를 잡거나 README.md에 복잡한 설치법을 적을 필요 없이, 폴더 하나로 깔끔하게 떨어지는 패키징 경험 자체는 꽤 만족스러웠습니다.

이제 이 폴더를 에디터에 얹기만 하면 커서(Cursor)든 어디서든 똑같이 돌아가겠구나 생각했는데요. 테스트 해보니 생각지도 못한 복병을 마주치게 되었습니다.

만들고 나서야 보인 것들(실측과 디버깅 기록)

1) 스펙 문서의 ${PLUGIN_ROOT}를 Cursor는 치환하지 않습니다

스펙 문서와 공식 가이드에서는 패키지 루트를 가리키는 공식 매크로로 ${PLUGIN_ROOT}를 안내합니다. 하지만 실제로 작성한 플러그인을 Cursor 환경에서 사용할 때 MCP가 전혀 뜨지 않았습니다.

<출처: 작가>

실제로 필자의 테스트 환경(macOS, Cursor 3.17.19 빌드)에서 런타임 코드를 정밀 분석해 보았습니다.

결과는 의외였습니다. 번들 내부에는 오직 ${CLAUDE_PLUGIN_ROOT}와 ${CURSOR_PLUGIN_ROOT}만 치환 목록에 등록되어 있었고, 정작 표준 스펙인 ${PLUGIN_ROOT}는 목록에 아예 없었습니다.

스펙 문서대로 ${PLUGIN_ROOT}를 적으면 매크로가 문자열 그대로 전달되어 경로를 찾지 못하고 실패합니다. 더 큰 문제는 독립 실패(Independent Failure) 원칙 때문에 에러 메시지가 화면에 전혀 뜨지 않고 조용히 MCP만 누락된다는 점입니다. 스펙을 정확히 지킬수록 MCP가 소리 없이 누락되는 역설적인 상황이 발생하고 있었습니다.

2) 표준 스펙으로 정의된 경로를 제일 마지막에 확인한다

MCP 도구뿐만 아니라 에이전트의 사고 지침을 담은 Skill을 불러오는 과정에서도 예상치 못한 문제를 마주쳤습니다.

분명 스펙 문서에는 skills/<skill_name>/SKILL.md가 표준 경로로 정의되어 있는데, 기존에 배포된 다른 플러그인들을 열어보면 루트 경로에 SKILL.md를 두거나 .cursor/skills/ 같은 도구별 폴더에 두는 경우가 여전히 많았습니다. 의아한 마음에 호환 클라이언트가 스킬 파일을 실제로 어떤 순서로 찾아 들어가는지 추적해 보았습니다.

호환 클라이언트가 스킬 파일을 어떤 순서로 찾아 들어가는지 추적해 본 결과는 다음과 같았습니다.

클라이언트는 하위 호환성을 위해 벤더별 레거시 경로를 먼저 확인한 뒤에야 표준 경로를 읽습니다. 만약 디렉터리 내에 이전 설정 파일이 남아 있다면 표준 경로의 최신 스킬이 무시될 수 있으므로, 플러그인 패키징 시 구버전 디렉터리가 섞이지 않도록 주의해야 합니다.

Agent Plugins, 실무에서 어떻게 활용하면 좋을까?

이제 플러그인 표준도 정식으로 발표되었으니, 평소 업무에서 자주 반복하는 작업이나 팀 협업에 꼭 필요한 플러그인을 직접 만들어 활용해 보면 어떨까요? 현업 엔지니어링 환경에서 바로 적용해 볼 만한 3가지 실무 활용 아이디어를 소개합니다.

1) 팀 단위 ‘사내 코딩 표준 및 엔지니어링 툴킷’ 배포

적용 시나리오: 신규 입사자 온보딩이나 팀 개발 환경 표준화.
패키징 구성:
- 스킬(skills/): 사내 아키텍처 규칙, 커밋 메시지 컨벤션, 에러 핸들링 가이드라인.
- MCP 도구(mcp.json): 사내 Jira 티켓 생성기, 사내 API 스키마 레지스트리 조회 도구, CI 파이프라인 트리거.
효과: 개발자마다 IDE가 Cursor이든 VS Code이든 상관없이, 팀의 공용 플러그인 폴더 하나만 등록하면 팀 전체가 동일한 규칙과 사내 도구를 즉시 활용할 수 있습니다.

2) 도메인 특화 ‘품질 검증 및 테스트 자동화’(본문 실습 모델)

적용 시나리오: 본문에서 다룬 gen-test-doc-plugin과 같은 QA 및 문서화 파이프라인.
패키징 구성:
- 스킬(skills/): 경계 조건(Null, 빈 배열, 비동기 타임아웃) 도출 지침과 API 명세서 Markdown 템플릿(references/).
- MCP 도구(mcp.json): 테스트 러너(Jest, PyTest) 실행 및 실패 로그 수집 도구.
효과: AI가 단순 텍스트로 테스트 코드만 짜주는 데 그치지 않고, 실제로 테스트를 구동하고 결과 로그를 확인하여 스스로 코드를 수정하는 ‘완결형 자동화 루프’를 플러그인 하나로 완성할 수 있습니다.

3) 인프라 및 DB 마이그레이션 안전장치(DevOps / DataOps)

적용 시나리오: 데이터베이스 스키마 변경, 클라우드 리소스 생성 등 휴먼 에러 위험이 높은 작업.
패키징 구성:
- 스킬(skills/): 마이그레이션 쿼리 작성 규칙 및 안전 점검 체크리스트.
- MCP 도구(mcp.json): 로컬 DB 연결 테스트 도구, 드라이런(Dry-run) 검증 스크립트.
효과: 고위험 작업을 수행할 때 AI 에이전트가 정해진 보안 지침을 철저히 따르면서 안전하게 실제 도구를 실행하도록 통제할 수 있습니다.

어떨 때 플러그인을 만들어 사용하는 게 좋을까?

모든 상황에서 무조건 플러그인을 만들어야 하는 것은 아닙니다. 작업의 성격에 따라 가장 단순하고 효율적인 단위를 선택하는 것이 실무적인 판단입니다.

<출처: 작가>

직접 만들어보고 내린 결론은 이렇습니다. Agent Plugins 1.0.0이 고정한 포장 규칙 자체는 지금 써도 될 만큼 깔끔하게 정리되어 있습니다. 스킬과 MCP를 한 폴더에 넣고 정해진 자리에 두는 것만으로도, 예전에 README에 적어두던 “이 스킬 쓰려면 저 서버도 등록하세요”라는 안내에서 명확한 파일 구조로 바뀝니다. 팀원에게 폴더 하나를 건네는 것과 장문의 설치 안내문을 건네는 것은 차원이 다릅니다.

다만 그 포장을 런타임 클라이언트가 어떻게 열어 읽을지에 대한 구체적인 이행은 아직 적용되지 않은 것 같습니다. 이번 실측에서 겪은 문제들이 전부 그 지점에서 발생했습니다. 매크로 이름이 클라이언트마다 다르고, 탐색 순서가 스펙과 반대이며, 문서에 있는 설정 키가 릴리스 빌드에 누락되어 있기도 합니다.

표준이 설치와 권한을 정의하지 않은 것이 잘못이라고 보지는 않습니다. IDE와 CLI, 클라우드가 각자 다른 보안 모델을 갖는데 무리하게 하나로 묶으려 했다면, 어디에서도 채택되지 못하는 규격이 되었을 테니까요.

당장 플러그인을 도입할 계획이라면, 다음 사항들을 미리 염두에 두시길 권합니다.

경로 매크로 확인: 스펙 이름만 믿지 마시고 대상 클라이언트가 실제로 치환해 주는 매크로 이름을 꼭 확인하세요.
공식 스키마 사전 검증: 매니페스트에 스키마 검증을 걸어두면 사소한 속성 오류나 $schema 누락을 초반에 걸러낼 수 있습니다.
가벼운 전송 방식 고려: stdio 서버는 무거운 node_modules 의존성을 함께 묶어야 하므로, 팀 단위 배포까지 고려한다면 중앙 원격 서버(streamable-http) 방식이 관리 부담을 크게 덜어줍니다.

남는 질문은 결국 하나입니다. 표준이 비워둔 설치와 권한 승인 영역을 클라이언트 벤더들이 과연 사실상의 단일 표준으로 수렴시킬지, 아니면 매크로 이름이 갈라진 것처럼 또 다른 파편화를 낳을지입니다. 답은 규격 문서가 아닌 앞으로 나올 클라이언트들의 릴리스 노트에서 확인하게 될 것입니다.

<참고>

Google for Developers Blog, “Agent Plugins package your skills, tools, and more”

]]>

[AX일지]274년 뒤 부품이 온다는 공장에서 : MES·ERP 연동 안 한 이유

Editor's note

[AX일지] ① 274년 뒤 부품이 온다는 공장에서
: 공장 AX, MES와 ERP 연동하지 않은 이유

주문 제작 산업기계를 만드는 회사가 있습니다. 이 회사에서 지금 이 주문이 어디까지 진행됐는지 아는 방법은 담당자에게 전화를 거는 것입니다. 확정된 것은 종이로 오가고, 시스템은 두 개나 있지만 서로 동떨어져 있습니다. 그래서 의뢰가 왔습니다. 생산 현장의 시스템(MES)과 사무 시스템(ERP)을 연동해 달라고요.

의뢰를 받으면 회사의 기록과 업무 흐름을 먼저 봅니다. 고객이 정말로 원하는 건 시스템 연동으로 달성되는 것이 아닐 수 있기 때문입니다. 그리고 그 기록에서, 납기가 274년 뒤로 잡힌 발주 데이터를 만났습니다. 멀쩡한 사람들이 왜 이런 값을 입력하게 되는지, 그리고 그 값이 왜 아무에게도 걸리지 않고 남아 있는지를 파헤쳐 진단을 내렸습니다. 그 끝에는 시스템이 아닌 사람이 있었습니다.

결국 이 회사에는 최초 의뢰였던 MES와 ERP의 연동이 아닌 다른 것을 하자고 제안했습니다. AI도 빠졌고요. 이 글에는 이런 판단과 결정의 과정을 담았습니다.

글쓴이 · 김우빈 · 위시켓 AIDP FDE <출처: 요즘IT>

274년 뒤에 도착하는 부품

저희가 착수하며 처음 한 일은 만드는 것이 아니라 회사의 기록을 읽는 것이었습니다. MES나 ERP, 엑셀 등 여기저기 흩어져 있던 기록과 발주 및 재고 데이터를 그대로 가져다가 AI와 함께 읽었습니다.

그런데 숫자들이 이상했습니다. 재고가 음수로 찍힌 항목이 있었죠. 하지만 창고에 물건이 마이너스로 쌓여 있을 수는 없습니다. 기록이 잘못 되었을 가능성이 높았죠. 2300년으로 입력된 부품 발주 건도 있었습니다. 발주는 올해 넣었는데 납기가 274년 뒤인 셈입니다.

시스템이 고장난 게 아니었습니다. 전부 사람이 입력한 값이었습니다. 그렇다면 이런 걸 살펴봐야했죠. ‘멀쩡한 사람들이 왜 이런 값을 입력하게 되는가.’ 그 답은 데이터에 없습니다. 사람에게 있습니다.

리더가 아니라 실무자부터 인터뷰하는 이유

먼저 말해 둘 것이 있습니다. 이 회사는 그동안 변화하기 위해 많은 노력을 한 곳입니다. 큰돈을 들여 현장 시스템을 도입했고, 부품이 들어올 때와 공정 중간, 출하 전에 품질을 확인하는 검사 화면도 만들어 봤습니다.

하지만 자리 잡지 못했습니다. 현장 시스템을 입력해도 조회하는 사람이 없었고, 검사 화면은 현장이 실제로 검사하는 순서와 달라서 쓰다가 접었습니다. 십 년 가까이 이런 일이 반복되자 경영진은 이런 결론을 내렸습니다.

”우리 직원들은 변화를 싫어한다.”

하지만 저는 그 결론을 일단 미뤄두기로 했습니다. 이상한 값을 입력한 것은 직원들이지만, 그런 값을 입력하게 만든 것이 무엇인지는 아직 알 수 없으니까요. 변화가 싫어서 잘못된 데이터를 일부러 입력했다고 판단하지 않고, 잘못된 데이터를 입력할 수밖에 없는 환경이 있을 거라고, 그걸 해결하는 것이 핵심이라고 생각했습니다.

그래서 9일 동안 10개 부서를 만났습니다. 인터뷰 원칙은 하나였습니다. 실무자에게 먼저 묻고, 리더는 나중에. 리더가 먼저 말하면 그 뒤 실무자 인터뷰는 “팀장님 의견에 동의합니다”로 끝나기 때문입니다.

누가 맞느냐가 아니라, 무엇이 없느냐

인터뷰에서는 실제 현장에서 어떻게 데이터를 입력하고 전달하는지를 알고 싶었습니다. 이 회사의 일은 이렇게 진행됩니다. 주문이 오면 도면을 그리고, 도면대로 부품을 사고, 만들고, 검사하고, 납품하고, 돈을 받습니다. 그런데 어떤 주문이 지금 이 여섯 단계 중 어디에 있는지를 아무도 한눈에 볼 수 없었습니다. 요즘은 택배도 기사님이 몇 동 앞에 있는지까지 보여주는데, 이 회사의 주문은 회사 안 어디에 있는지를 몰랐습니다.

현장에서 확인한 업무 흐름 · 주문→도면→부품 구매→제작→검사→납품→수금 <출처: 요즘IT, ChatGPT로 제작>

여러 부서를 인터뷰하면서 같은 사건을 두고 부서마다 서로 다른 생각을 한다는 걸 알게 됐습니다. 하지만 틀린 말을 하는 사람은 한 명도 없었습니다. 처음 며칠은 누구의 말이 맞는지를 가리려고 했습니다. 판정을 내려주는 게 제 역할이라고 생각했던 겁니다. 그런데 몇 건을 겹쳐 놓고 보니 판정 자체가 불가능했습니다. 그래서 질문을 바꿨습니다. 누가 맞느냐가 아니라, 이 두 말이 동시에 참인 상황은 어떤 상황인가.

그 관점으로 보니 전부 이해가 됐습니다.

먼저 구매팀과 설계팀의 오래된 어긋남이 있었습니다. 구매팀은 ‘도면이 늦게 온다’고 했고, 설계팀은 ‘도면 납기 요청을 받은 적이 없다’고 했습니다. 둘 다 맞습니다. 언제까지 주기로 했다는 약속 날짜가 시스템 어디에도 없었습니다. 약속이 없으니 늦는다는 개념도 없는 것입니다. 서로의 기억 속 어딘가에만 남아, 서로 다른 감정을 갖게 될 뿐이었죠.

또 설계팀이 부품 목록을 확정해 구매팀에 줘야 구매팀이 발주를 할 수 있는데, 그 목록 또한 확정 기한이 명확하지 않았고, 시스템 밖에서 오갔습니다. 설계팀은 부품 목록을 정해 종이로 출력해서 구매팀까지 걸어가 책상에 올려놓고 있었죠. 어찌됐든 전달이 확실하게 되는 방식이긴 합니다. 하지만 시스템에는 남지 않았습니다. 그래서 구매팀은 목록을 받은 적이 없고, 설계팀은 목록을 만들어 줬다고 하는 상황도 벌어졌습니다.

업무를 어긋나게 만든 세 가지 부재 · 약속 날짜·확정 기록·돌아가는 경로 <출처: 요즘IT, ChatGPT로 제작>

부서 각각의 결정이 다른 부서에 영향을 미치고 있었지만, 어떤 결정이 언제 났고 그에 따라 다음 작업을 언제까지 해야 하는지 알려주는 흐름이 끊겨 있었습니다. 비슷한 문제가 다른 팀과의 관계에서도 반복됐는데요. 품질팀에서는 불량 원인 1위로 설계를 꼽았는데, 정작 불량 이력이 설계로 돌아가는 경로가 없어서 설계팀은 그 사실을 들은 적이 한 번도 없었죠.

약속 날짜가 없고, 확정 기록이 없고, 돌아가는 경로가 없었습니다. 이렇게 약속이 필요함에도 정해지지 않은 영역에서 서로 어긋나고 있던 것이었습니다. 그래서 있는 것을 분석해 해결하기보다, 없는 것을 파악해 마련하는 게 더 중요해보였죠.

병목이라 불리던 팀

이렇게 정해지지 않은 것들이 쌓이고 쌓이며 한 부서에 부담을 주고 있었습니다. 그리고 그 팀은 사내에서 ‘병목’으로 통했습니다. 설계팀에서 확정한 목록대로 발주하고, 들어온 자재를 입고 처리하는 구매팀입니다. 발주도 입고도 매번 늦는다는 말을 들었죠.

하지만 살펴보니 이 팀은 다른 팀에서 해야 할 일까지 하고 있었기에 구조적으로 늦을 수밖에 없었습니다. 발주를 하려면 부품 목록이 시스템에 있어야 하는데, 목록이 종이로 오는 바람에 그것을 시스템에 직접 옮겨 넣었습니다. 요청했던 자재가 실제로 입고되었는지도 시스템을 통해 알 수 없다 보니, 다른 팀에서 오는 확인 전화도 몰렸습니다.

구매팀에 자주 전화를 걸던 한 분은 이렇게 말씀하시더군요. “자꾸 물어보는 것도 미안하고, 그 친구도 힘들고요.” 남의 기록을 메우고 온종일 전화를 받는 팀. 느릴 수밖에 없는 팀이었습니다.

이렇게 일을 떠안아서 하다 보니, 기록을 잘못하는 경우도 발생했습니다. 급한 일부터 처리하고 입력은 몰아서 하는 관행이 생겨서, 실제 상황과 기록이 어긋나기도 했습니다. 이건 이 회사만의 일이 아닙니다. 기록보다 일이 급한 현장이라면 어디서든 발생하는 일이죠.

274년 뒤 납기도 그렇게 생겨난 숫자였습니다. 연도를 잘못 입력한 것이 시작이었고, 그 뒤로 그 발주 내역을 시스템에서 다시 열어 본 사람이 없었으니 고쳐질 기회도 없었습니다.

여기까지 오니 MES와 ERP 연동이 답이 아니라는 게 더 명확해보였습니다. 약속이 기록되지 않고 기록이 다음 사람에게 흐르지 않는 회사에서 끊어져 있는 두 시스템을 묶는 것은 답이 아니었죠.

반발이 터진 날, 같은 화면을 다시 열었다

이런 내용을 담은 진단 결과를 공유하는 자리에서 언성이 높아졌습니다. “데이터 관리가 잘 안 되고 있다”고 말씀드리자 처음에 구매팀에서는 다소 감정적인 반응을 보이셨습니다. 당연했습니다. 일을 ‘잘못했다’고 평가하는 것처럼 들릴 수도 있으니까요.

그래서 더 말을 하기보다, 회사의 기록을 읽고 정리한 화면을 띄웠습니다. 재고가 음수로 찍히고 납기가 274년 뒤로 된 발주가 있는 데이터가 보이는 화면이었죠.

더 화를 내시진 않을까 내심 걱정도 됐지만, 화면을 같이 들여다보자 분위기가 바뀌었습니다. 언쟁이 아니라 “이 값이 왜 이렇게 들어가 있지”를 파헤치는 대화가 이어졌고, 이 팀이 떠안고 있던 구조적 부담이 드러났습니다. 앞선 팀에서 시스템을 통해 전달되지 않은 것을 손으로 메우다 보니 실수가 생겼던 것. ‘일을 잘못했다’거나 ‘무능하다’는 게 아니라 구조적인 문제가 수면 위로 드러나고, 이걸 함께 해결해야 할 문제로 바라보기 시작한 것입니다. 그래서 가장 세게 반발했던 이 팀이 이후 가장 잘 협조하는 팀이 됐습니다.

현장 장면 · 도면과 종이와 전화로 도는 사무실 <출처: 요즘IT, ChatGPT로 제작>

잘되고 있음을 확인하는 시스템

이 과정을 거쳐 회사 내에 약속이 비어 있는 곳에서 기록이 끊기거나 오염되고 있다는 결론을 내렸습니다. 그래서 없는 약속부터 만들자고 제안했습니다.

새 시스템을 새로 만드는 이야기부터 하지는 않았습니다. 일단 데이터가 있긴 있으니, 회사 안에서 어떤 일이 어떻게 진행되고 있는지를 한눈에 볼 수 있는 현황판을 드렸습니다. 그건 제가 처음 시작할 때 회사를 이해하기 위해 만들어뒀던 것이기에 새로운 것은 아니었습니다. 이 현황판에 보이는 내용을 전 부서로 넓혀서 수주부터 설계, 구매, 제작, 검사, 수금까지 어떤 일이 어느 단계에 있는지를 누구나 볼 수 있게 하는 것이 첫 번째 제안이었습니다. 택배 조회 시스템처럼 업무 흐름이 보이도록 하겠다는 것이죠.

그다음, 이 회사에 없었던 것, 그렇기 때문에 업무의 흐름을 끊고 있었던 것들을 하나씩 만들자고 했습니다. 부품 목록과 도면을 전달하는 날짜를 입력하는 칸이 대표적이었습니다. 또 설계 팀이 종이를 들고 걸어가 전달하지 않고 ‘확정’을 누르면 되도록 만들었습니다. 불량 이력이 전달되는 경로가 생기도록 부서 담당자가 그 이력을 받도록 명시하기도 했습니다. 이미 입력하던 것은 그대로 두고 그 위에 얹었습니다.

정리하면 만들기로 한 것은 두 가지입니다. 하나는 어떤 일이 어느 단계에 있는지 누구나 볼 수 있는 현황판이고, 다른 하나는 그 현황판이 저절로 채워지도록 날짜와 확정과 이력이 전달되는 경로를 심는 일입니다. 이것을 심을 자리가 필요해서 사무 시스템은 다시 만들기로 했습니다. 현장 시스템은 건드리지 않았고요.

기록되지 않던 순간을 화면에 · 약속 날짜·확정·불량 이력 경로 — 예시 화면(실제 데이터 아님)<출처: 요즘IT, ChatGPT로 제작>

인터뷰 중 한 부서장님께서 말씀하셨습니다. ‘구멍 나는 걸 잡아내는 시스템 말고, 잘 되고 있음을 확인하는 시스템이면 좋겠다’고요. 이 회사에 이 관점이 잘 전달되면 좋겠다고 생각했습니다.

회사 내에 정해져 있지 않은 것들이 약속되고 기록될 때, 처음엔 불편해하거나 감시받는다고 느끼는 분들이 있을 수 있습니다. 그건 혹시 이런 기록이 내가 일을 잘못하고 있다고 평가하는 도구로 사용되지 않을까 하는 우려에서 나옵니다. 하지만 회사 안에서 그런 작업을 통해 일을 더 잘할 수 있게 되고, 일이 잘되고 있다는 걸 확인하는 과정이 반복된다면, 그제야 직원들이 이 기록을 믿게 됩니다. 그러기 위해서는 가장 어려움을 겪고 있는 구매팀에서 가장 유용하다고 느끼길 바랐습니다.

다만 이렇게 업무 흐름을 재정비하는 일은 실무자들의 끊어진 흐름을 잇는다고 끝나지 않습니다. 어떤 것을 ‘완료’라고 정의할지, 잘한 사람에게 무엇을 줄지 등 시스템이 만들 수 없는 것들은 경영진이 정해야 합니다. 시스템은 기준을 강제할 수는 있어도 행동으로 옮겨주지는 않기 때문입니다. 그래서 경영진이 정해야 하는 목록은 따로 추려서 제안서 뒤에 붙였습니다.

이 제안에 AI가 없는 이유

눈치채셨을지 모르지만, 이 제안에는 AI가 없습니다. 정확한 기록이 흐르지 않는 회사에 AI를 얹으면 틀린 기록이 더 빨리, 더 자신 있게 퍼질 뿐입니다. ‘274년 뒤 납기’ 같은 기록이 AI를 통해 요약되고 다른 부서에 전달되고 분석된다면 어떨까요?

좋은 기록이 흐르기 시작하면 그때 AI가 할 일이 생깁니다. 부서마다 매일 돌고 돌던 확인 전화를 AI가 대신 받고, 애매한 건만 골라 사람에게 직접 묻는 일 같은 것들입니다. 에이전트도 마찬가지입니다. 현장에서 걱정하시던 것과 달리 그렇게 될 때 없어지는 것은 일자리 자체가 아니라 반복되고 불편하던 잡무입니다.

제가 속한 회사에는 업무 영역마다 AX 성숙도를 다섯 레벨로 정리한 모델이 있습니다. 저도 진단을 할 때 그 모델을 따르는데요. 이번 제안은 설계와 구매, 품질로 이어지는 영역을 데이터 정합(Lv1)과 프로세스 정형(Lv2)까지 올리자는 것에 가깝습니다.

위시켓 AX 성숙도 모델 <출처: 요즘IT, ChatGPT로 제작>

제안은 이미 고객사 대표님께 드렸습니다. 대표님이 받아들이실 수도 있고, 더 좋은 제안을 주실 수도 있습니다. 저희는 시스템을 넘기는 날이 끝이 아니라 시작이라고 보고, 이것을 운영형 AX라고 부릅니다.

그러니 이 프로젝트에 대한 이야기도 이 글이 시작일 뿐입니다. 제안이 받아들여졌는지, 현장에서 실제로 쓰이는지, 잘된 것과 안된 것을 다음 글에서 그대로 적겠습니다. 저의 목표는 손익(P&L)이 실제로 달라지는 것이거든요. 그때까지 어떻게 프로젝트를 이어가는지 기록해보겠습니다.

요즘IT에서 AX 현장의 이야기를 더 가까이서 나눌 자리를 검토하고 있습니다.
어떤 형태가 좋을지 의견을 들려주세요. 1분이면 됩니다.
➡️ AX 관련 행사·모임 수요 조사

]]>

오픈AI 개발자가 알려주는 GPT-6 Astra 프롬프트 팁

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

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

써볼 것: diagram-design - AI에게 시키면 밋밋하던 다이어그램을 깔끔하게 만들어주는 스킬
참고할 것: Grok Bot을 한 달 만에 만든 이야기 - 작은 팀이 빠르게 만든 비결
적용해볼 것: 오픈AI 개발자가 알려주는 GPT-6 Astra 프롬프트 팁

<출처: cathrynlavery/diagram-design, GitHub>

1. 써볼 것: AI에게 시키면 밋밋하던 다이어그램을 깔끔하게 만들어주는 스킬

기획서나 발표 자료에 넣을 그림 하나가 필요해서 AI에게 다이어그램을 그려달라고 해본 적 있으실 겁니다. 그런데 나오는 건 대개 밋밋한 둥근 네모 상자에 화살표를 이어놓은, 어디서 본 듯한 그림이죠. diagram-design은 그럴 때 쓰는 도구입니다. 아키텍처 그림, 순서도, 타임라인 같은 다이어그램을 보기 좋은 편집 디자인 수준으로 만들어줍니다.

이 스킬을 만든 캐스린 래버리(Cathryn Lavery)는 개발자가 아니라, BestSelf.co라는 문구 회사를 운영하면서 글을 쓰는 사람입니다. 블로그에 넣을 그림이 필요해서 AI에게 부탁할 때마다 사이트 분위기와 안 어울리는 밋밋한 그림만 나오니, 피그마를 30분씩 붙잡거나 아예 그림 넣기를 포기하곤 했다고 합니다. 그러다 직접 만든 게 이 스킬이죠.

다이어그램 샘플 <출처: cathrynlavery/diagram-design, GitHub>

무엇을 만들어주나요?

만들 수 있는 다이어그램이 39가지나 됩니다. 시스템 구조를 보여주는 아키텍처 그림, 분기가 있는 순서도, 시간 흐름을 담은 타임라인, 중요도를 쌓아 올린 피라미드, 일정을 정리한 간트 차트 같은 것들이요. 어떤 그림이 필요한지 말하면 AI가 알맞은 유형을 골라 그려주며, 결과물은 HTML 파일 하나로 나와서 브라우저로 바로 열립니다. 그림자나 요란한 장식 없이 깔끔하게 정리된 모양으로 발표 자료나 문서에 그대로 넣기 좋아보입니다.

특히 쓸모 있는 게 브랜드 맞추기 기능입니다. 내 웹사이트 주소를 알려주면 거기서 색과 글꼴을 뽑아 모든 다이어그램에 입혀주는 기능입니다. 우리 회사 컬러로 맞춰진 그림이 나오는 거죠. 이미 draw.io나 Mermaid로 그려둔 다이어그램이 있다면, 그걸 이 디자인으로 다시 그려주기도 합니다.

어떻게 쓰나요?

diagram-design은 클로드 코드(Claude Code)에서 아래 두 줄로 설치합니다. Codex나 Pi 같은 다른 도구에서도 쓸 수 있어요.

/plugin marketplace add cathrynlavery/diagram-design
/plugin install diagram-design@diagram-design

설치한 뒤에는 내 앱 구조를 그려줘. 프런트엔드, 백엔드, 데이터베이스로처럼 원하는 그림을 말로 설명하면 됩니다. 그러면 AI가 알맞은 유형을 골라 HTML 파일로 만들어줘요. 슬라이드에 넣을 PNG나 피그마에서 열 SVG로 내보내는 것도 가능합니다.

<출처: Lenny's Podcast, Roman Ugarte 인터뷰>

2. 참고할 것: Grok Bot을 한 달 만에 만든 이야기

몇 회차 전에 Grok Bot을 소개한 적이 있습니다. 코딩용이 아니라 일반 업무를 도와주는 AI 도구인데, 출시되자마자 화제가 됐죠. 이번엔 그 Grok Bot을 만든 사람이 직접 뒷이야기를 풀었습니다. Lenny's Podcast에 나온 로만 우가르테(Roman Ugarte) 인터뷰인데요. 우가르테는 커서(Cursor)에 15번째 직원으로 합류해 회사가 1,000명 넘게 커지는 동안 그로스를 이끌었고, 지금은 SpaceXAI에서 Grok Bot을 맡고 있습니다. 다만 자기가 만든 제품 이야기니, 그 점은 감안해서 읽어주시면 좋겠습니다.

만든 과정부터 보겠습니다. Grok Bot은 소수의 팀이 한 달 만에 만들었습니다. 회사에서 따로 떨어져 나와, 사무실도 다른 공간에 앉고 슬랙 채널도 비공개로 두고 한 달간 집중했다고 하는데요. 이렇게 첫 코드부터 사내에서 쓸 만한 시제품까지 딱 한 달, 거기서 공개 출시까지 다시 3주가 걸렸습니다.

우가르테는 팀이 더 컸다면 이 속도가 안 나왔을 거라고 봅니다. 새 제품을 만들 때는 전에 안 해본 자잘한 결정을 매일 수없이 내려야 하는데, 팀이 크면 그 결정 하나하나가 회의와 합의에 묶이거든요. 게다가 큰 조직은 보통 6개월, 1년짜리 큰 그림을 그리느라 정작 빨리 만들어 내보이는 걸 놓치기 쉽고요. 작은 팀이라 매일 빠르게 결정하고 바로 움직일 수 있었고, 그게 한 달 만에 제품이 나온 힘이었습니다.

성공을 가른 두 가지 결정

우가르테는 초기에 내린 두 결정이 지금의 Grok Bot을 만들었다고 말합니다. 둘 다 그때는 당연해 보이지 않았다고 하고요.

하나는 기존 제품인 커서 안에 넣지 않고 완전히 새로 시작한 겁니다. 코딩 도구는 비개발자에게 부담스럽고, 잘 만든 제품에 탭 하나 더 붙이는 식으로 기능을 얹다 보면 화면이 어수선해진다고 봤거든요. 그래서 처음부터 백지에서 새로 만들기로 했습니다.

다른 하나는 클라우드에서 돌아가게 하고, 봇마다 자기 컴퓨터를 준 겁니다. 보통 이런 도구를 쓸 때는 내 컴퓨터가 켜져 있어야 하나, 폰에서 시키면 집에 있는 컴퓨터랑 연결돼 있어야 하나 이런 걸 매번 신경 써야 하죠. Grok Bot은 이런 신경 쓸 거리를 아예 없앴습니다. 우가르테는 새 동료에 빗대어 설명합니다. 팀에 새 사람이 들어왔는데 넌 노트북 없으니까 내 옆에서 내 걸 같이 쓰자고 하면 이상하잖아요. 봇에게도 자기 컴퓨터를 줘야 제대로 일한다는 겁니다.

기능을 더하기보다 덜어냈습니다

출시 전 몇 주 동안 팀이 매달린 건 기능을 걷어내는 일이었다고 해요. 실험 삼아 넣었던 것, 개발자용 화면 같은 걸 덜어내고 사용자가 꼭 봐야 하는 것만 남겼습니다. 우가르테는 AI가 뭘 빼야 할지는 잘 못 알려준다고 말합니다. 더 넣자는 아이디어는 잘 내지만, 뭘 안 만들지 정하는 건 사람의 일로 남는다는 겁니다. 그들은 제품을 보는 방식도 바꿨습니다. 보통 소프트웨어는 기능을 늘릴 때 화면에 버튼이나 메뉴를 하나씩 더하죠. 그런데 이들은 화면에 뭔가를 더하기보다, 봇이 뒤에서 알아서 해내는 일을 늘리는 데 집중했습니다.

자동화 기능이 좋은 예입니다. 보통은 자동화를 만들려면 화면에서 버튼을 눌러 조건을 설정해야 하는데, Grok Bot은 그 화면을 아예 없앴죠. 대신 매일 아침 8시에 알려줘처럼 말로 부탁하면 그대로 되게 했습니다. 지금은 자동화의 99%가 이렇게 만들어진다고 합니다.

초기 사용자를 팀이 직접 만난 것도 눈에 띕니다. 그들은 200~300명을 한 명씩 손수 안내하며 20분씩 통화했다고 하죠. 봇이 안 켜지거나 사용자가 헤매는 순간을 옆에서 지켜보고, 그때마다 바로 고쳐나갔습니다. 개발자가 아닌 커피숍 사장 같은 예상 밖의 사용자도 이 과정에서 만나, 실제로 어떻게 쓰이는지 배웠다고 합니다.

봇을 동료처럼 대하기

우가르테가 여러 번 꺼낸 말이 콜리그필드(colleague-pilled)입니다. 봇을 소프트웨어가 아니라 함께 일하는 동료로 여기고 만든다는 뜻인데요. 제품 방향을 두고 의견이 갈릴 때, 사람 동료라면 이럴 때 어떻게 할까를 떠올려보면 답이 대체로 분명해진다고 합니다.

사내에서 실제로 나온 사용 패턴도 꽤 재미있습니다. 직원들이 처음엔 봇을 대여섯 개씩 두고 일을 나눠 맡기다가, 2주쯤 지나자 그중 잘하는 봇 하나를 비서실장처럼 세워서, 사람은 그 봇에게만 지시하고 나머지 봇들에게는 그 봇이 일을 나눠주도록 하는 방식이 자연스럽게 생겼다고 합니다.

한 직원이 그 봇에게 ‘너 승진했어’라고 하자 봇이 그럼 연봉(토큰 예산)도 오르냐고 되물은 일도 있었죠. 팀은 이 비서실장 방식이 사내에서 꽤 유용해 보였지만, 곧바로 제품에 넣지는 않았습니다. 사용자에게 이렇게 쓰라고 정해주는 대신, 바깥 사람들도 시키지 않았는데 스스로 이 방식을 찾아내는지 먼저 지켜봤습니다. 실제로 많은 사용자가 알아서 봇을 이렇게 쓰기 시작하자, 그제야 제품에서도 이 방식을 슬쩍 추천하도록 손봤다고 합니다.

무엇을 얻어가면 될까요?

Grok Bot이라는 제품 자체도 흥미롭지만, 이를 만든 방식에서 더 배울 게 많아 보입니다. 소수의 팀이 격리돼 매일 빠르게 결정했고, 초기 사용자 수백 명을 한 명씩 직접 만나며 고쳤고, 화면에 버튼을 더하기보다 봇이 해낼 수 있는 일을 늘려나갔습니다. 첫 코드부터 공개 출시까지 두 달이 채 걸리지 않았는데, 규모가 큰 팀에선 좀처럼 나오기 어려운 속도입니다. 지금 작은 팀으로 일하거나 혼자 제품을 만들고 계신다면, 참고해볼 만한 점이 많습니다.

<출처: Eric Provencher, X>

3. 적용해볼 것: 오픈AI 개발자가 알려주는 GPT-6 Astra 프롬프트 팁

AI에게 코딩을 시켜본 분이라면, AI를 원하는 대로 움직이게 하려고 이런저런 지시를 덧붙여본 적 있으실 겁니다. 이건 이렇게 해, 저건 하지 마, 작업할 때마다 테스트를 돌려 같은 것들이요. 그런데 이렇게 쌓아둔 지시나 프롬프트가 새 모델에서는 오히려 거추장스러워질 수 있다는 글을 접해 공유합니다. 오픈AI에서 코딩 도구 Codex의 개발자 경험을 맡고 있는 에릭 프로벤처(Eric Provencher)가 X에 쓴 글이며, 조회수 366만을 넘기며 퍼진 글이기도 합니다.

프로벤처의 이야기는 이렇습니다. AI 코딩 도구가 좋아지면서, 예전 모델을 길들이려고 만들어둔 장황한 지시들이 이제는 큰 쓸모가 없어졌으니 새 모델이 나온 김에 그동안 쌓인 지시를 한번 정리하라는 거죠. 그는 최근 나온 GPT-6 Astra를 예로 들지만, 이 원칙은 클로드 같은 다른 도구를 쓸 때도 똑같이 통합니다.

스킬을 너무 많이 깔지 마세요

프로벤처가 처음 짚는 건 스킬 파일입니다. 스킬은 AI에게 특정 작업을 어떻게 하라고 알려주는 지시문 묶음인데, 사람들이 이걸 습관적으로 잔뜩 내려받는 게 실수라고 합니다. 이유는 이렇습니다. 스킬마다 이름과 설명이 붙어 있고, AI는 그 설명을 보고 언제 어떤 스킬을 쓸지 판단해요. 그런데 스킬이 너무 많아지면 설명이 잘려서 AI가 각 스킬을 제대로 못 읽고, 그러면 뭘 골라야 할지 헷갈리는 거죠. 설명끼리 서로 부딪히거나, 저요 저요 하며 자기를 쓰라고 우기는 설명이 많아지면 엉뚱한 스킬을 불러오기도 하게 돼죠.

그래서 프로벤처는 스킬 설명을 언제 쓰는 건지 알 수 있을 만큼만, 되도록 짧게 쓰라고 합니다. 여러 작업이 담긴 스킬이라면, 첫 문서는 어디를 보면 되는지 알려주는 안내판 정도로만 두고 세부 내용은 필요할 때 찾아 읽게 하라고요. AI가 당장 필요도 없는 내용까지 다 읽느라 시간을 버리지 않게요.

매번 다 읽으라는 지시를 걷어내세요

두 번째는 AGENTS.md 점검입니다. 이건 AI가 내 프로젝트에서 일할 때 항상 참고하는 지시문인데, 여기에 편집하기 전에 문서를 전부 읽어라 같은 규칙을 넣어두는 경우가 많습니다. 프로벤처는 오타 하나 고치는데 프로젝트 문서를 다 읽으라는 건 낭비라고 말합니다. 요즘 모델은 뭘 읽어야 할지 알아서 판단하니까요. 예전 모델은 테스트를 돌리라고 일일이 시켜야 했지만, 새 모델은 알아서 돌리기 때문에 같은 지시가 이제는 불필요한 반복을 만든다고 해요. 그러니 지시문을 하나씩 보며 이 규칙이 지금도 필요한가를 물어보라는 겁니다.

강한 금지 문구가 발목을 잡기도 합니다

세 번째는 경계 설정입니다. 예전 모델이 시키지도 않은 일을 멋대로 하는 바람에, 먼저 물어보고 해 같은 강한 문구를 넣어둔 경우가 있어요. 그런데 판단력이 좋아진 새 모델에게는 이런 문구가 계속 진행해도 되는 지점에서 멈추게 만들 수 있다고 합니다. 새 모델은 경계를 진지하게 받아들이기 때문에, 예전에 걸어둔 강한 제동이 오히려 일을 더디게 한다는 거죠.

어디까지가 끝인지 미리 알려주세요

마지막은 완료를 정의하는 겁니다. 프로벤처에 따르면 GPT-6 Astra는 첫 번째 구현만 해놓고 이만하면 됐나요? 하고 돌아오는 경향이 있다고 합니다. (아직 할 일이 남았는데도요) 그래서 일을 시키기 전에, 어디까지 해야 끝인지를 요청에 담으라고 합니다. 만들고, 돌려보고, 안 되는 걸 고치는 것까지가 이 작업의 끝이다처럼요.

적용해볼 수 있는 것

지금 AI에게 일을 시킬 때 쓰는 지시문을 한번 펼쳐놓고, 이 규칙이 지금도 필요한가를 하나씩 물어보세요.
AI에게 일을 맡기기 전에, 어디까지 해야 끝인지를 한 문장으로 먼저 적어보세요.
스킬이나 참고 문서를 잔뜩 붙여뒀다면, 정말 자주 쓰는 것만 남기고 나머지는 덜어내 보세요. 많이 붙일수록 AI가 헷갈릴 수 있으니까요.

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

]]>

PR 10개 중 7개를 에이전트가 쓰는 우버 팀에게 배울 것

우버에서는 이제 풀 리퀘스트(PR) 10개 중 7개를 사람이 아니라 AI 에이전트가 만듭니다. 전체 PR의 70% 이상이 로컬/클라우드 에이전트 산출로 집계됩니다. 엔지니어들이 만든 에이전트 스킬은 3,600개가 넘고 하루 실행 횟수는 3만 회를 넘습니다.

이쯤 되면 AI 토큰에 내는 지출도 몇 배로 뛰었어야 정상일 텐데요. 2026년 2월부터 8월까지 우버의 에이전트 상품 주간 활성 사용자는 7배, 주간 에이전트 요청은 9.4배 늘었는데, 지출은 4월 이후 거의 변하지 않았다고 합니다.

얼마 전, 우버 엔지니어링이 올린 아티클 「Running a Software Factory Efficiently at Uber Scale」를 읽었습니다. 우버가 ‘소프트웨어 팩토리’라고 부르는 에이전트 운영 체계와 비용을 눌러 잡은 레버들이 꽤 구체적으로 나옵니다. 매일 AI를 쓰면서 개인 계정의 토큰 관리만으로도 허덕이는 저한테 정말 놀라운 운영 구조였습니다.

무작정 에이전트를 더 만드는 회사는 많습니다. 하지만 에이전트를 공장처럼 돌리면서 비용을 안정적으로 유지한 회사는 드뭅니다. 규모는 달라도 에이전트 비용에 대한 고민은 요즘 어느 팀에나 있을 거라고 생각합니다. 아티클 본문을 따라가며, 우버의 노하우를 하나씩 풀어봤습니다.

Uber Engineering, 〈Running a Software Factory Efficiently at Uber Scale〉

이 글은 모두 우버의 아티클을 기반으로 재해석한 내용을 담고 있습니다.

1. 우버에서 PR 10개 중 7개는 이미 에이전트가 쓴다

우버에서는 세션의 출발점부터 다릅니다. 점점 더 많은 세션을 자동화된 에이전트가 직접 시작한다고 합니다. 이 에이전트들이 코드 리뷰를 달기도 하고, CI가 깨지면 스스로 고치며, 온콜 알림을 분류합니다. 새로 들어온 버그를 디버깅하고 시각 검증을 붙여 PR을 끝까지 완성하기도 하죠. 물론 사람의 리뷰를 받고, 판단이 어려운 건은 사람에게 넘기는 에스컬레이션 절차를 거치면서요.

제일 놀라운 건 비용입니다. 공개된 그래프를 보면, 사용자와 요청을 나타내는 선은 가파르게 오르는데 지출 선은 4월부터 수평을 유지합니다.

2026년 2월~8월 중순 주간 활성 사용자·에이전트 요청·비용 추이. 사용자는 7배, 요청은 9.4배 늘었지만 비용은 4월 이후 비슷한 수준에 머물렀다 <출처: 우버 엔지니어링 블로그>

다만 그 기간, 우버에서는 도입률도 워크로드 구성도 모델도 다 변했습니다. 그래서 회사는 최적화 효과만 분리해 보려고 모델 하나를 고정해 측정했습니다. 모델을 바꾸면 단가와 성능이 함께 달라지니, 같은 모델을 쓴 세션만 골라 비교해야 최적화 조치의 효과가 보이기 때문입니다. 그렇게 본다 해도 2월부터 7월까지 모델 요청 1,000건당 비용은 정점 대비 34%가량, 세션당 비용은 6월 정점 대비 52% 내려갔습니다.

모델을 고정하고 측정한 최적화 효과. 요청 1,000건당 비용은 정점 대비 34%, 세션당 비용은 52% 내려갔다(세션당 비용은 5월 말부터 집계) <출처: 우버 엔지니어링 블로그>

우버도 이 절감치 자체는 자기 환경 고유의 결과라고 선을 긋습니다. 코드베이스와 팀 규모, 에이전트 워크플로에 따라 결과가 달라진다고요. 그러나 실제 작업으로 벤치마크를 만들고 정확도와 비용을 함께 최적화하는 방법론은 보편적으로 적용할 수 있다고 말합니다.

2. 에이전트 ‘공장’을 조직하는 방법

우버는 AI 사용을 가장 특화된 것부터 가장 범용적인 것까지 4개 층으로 나눠 조직합니다. 층이 높을수록 비용·품질·모델 선택에 대한 통제력이 커진다고 하고요. 뒤에 다시 다루겠지만 코드 리뷰처럼 일감이 정해진 매니지드(managed) 에이전트와 엔지니어가 자유롭게 쓰는 인터랙티브 세션을 같은 방식으로 다루지 않는다는 뜻입니다.

아래 층부터 보면 이렇습니다. 맨 아래 층은 엔지니어가 자기 노트북에서 클로드 코드·코덱스 같은 도구를 그대로 쓰는 ‘원시 세션’, 그 위는 여기에 사내 스킬 3,600여 개를 붙인 ‘스킬 세션’입니다. 세 번째 층에는 우버 클라우드에서 어떤 스킬이든 대신 실행해 주는 범용 에이전트, 맨 위 층은 코드 리뷰·PR 생성처럼 일감이 좁게 정해진 특화 매니지드 에이전트입니다. 위로 갈수록 ‘리뷰 1건당 비용’처럼 돈을 일의 단위에 대응시킬 수 있어서 통제력이 커집니다.

에이전트 세션이 돌아가는 4개 층. 위로 갈수록 작업 단위가 좁아지고 비용·품질·모델 선택에 대한 통제력이 커진다 <출처: 우버 엔지니어링 블로그>

우버는 이 공장의 지출을 방정식 하나로 분해합니다. 사용자 수 × 사용자당 세션 수 × 세션당 턴 수 × 턴당 요청 수 × 요청당 토큰 × 토큰당 가격, 이렇게 여섯 항을 곱한 구조죠.

앞의 두 항은 도입과 참여를 나타내므로 오히려 계속 키워야 할 값입니다. 최적화 표적은 가운데 세 항, 즉 세션당 턴 수, 턴당 요청 수, 요청당 토큰이고요. 마지막 항인 토큰당 가격은 벤더가 정하는 값이니 별도로 대응합니다. 우버는 이 세 개 항을 “엔지니어가 실제로 요청한 것 위에 에이전트가 스스로를 위해 수행하는 작업”이라고 표현합니다. 에이전트가 더 빨리 계획하게 하고 불필요한 턴과 오류를 줄이고 입력 토큰을 아끼는 메커니즘을 만드는 데 최적화 노력 대부분이 들어갑니다.

총지출을 여섯 개의 곱셈 항으로 분해한 식. 앞의 두 항은 키우고, 가운데 세 항(에이전트의 궤적)과 마지막 항(단가)은 줄이는 것이 목표다 <출처: 우버 엔지니어링 블로그>

“AI 비용이 너무 비싸다”는 뭉툭한 문제를 이렇게 쪼개 놓으면 각 항마다 따로 재고 따로 고칠 수 있게 됩니다. 이제 나올 레버들은 전부 이 방정식의 특정 항을 겨냥한 것들입니다.

3. 내게 맞춰 만든 벤치마크로 고르는 모델

토큰당 가격은 벤더가 정하는 값이라 손댈 수 없어 보입니다. 그러나 우버는 포기하지 않고, 어느 모델이 어느 워크로드를 돌릴지를 고르는 쪽으로 접근합니다. 기준은 파레토 효율입니다. 한쪽을 포기하지 않고는 다른 쪽을 더 좋게 만들 수 없는 상태를 뜻하는 말인데요. 쉽게 말해 ‘이것보다 싸면서 동시에 더 좋은 대안이 없는 모델’만 후보로 남긴다는 얘기입니다. 우버는 이 효율을 완료 작업당 비용과 산출 품질, 모델 신뢰성 세 가지로 잽니다.

방식 자체는 단순합니다. 그 에이전트의 실제 작업으로 벤치마크를 만듭니다. 그다음 최상위 모델이든 오픈웨이트 모델이든 하나의 인터페이스 뒤에서 돌릴 수 있는 하네스에 에이전트를 태우고, 파레토 최적인 모델로 옮깁니다. 그렇게 계속 옮깁니다. 최고가 몇 주마다 바뀌니까요.

모든 PR의 AI 코드 리뷰를 맡는 uReview가 좋은 예입니다. 알려진 버그가 있는 실제 PR들로 벤치마크를 만들어 난이도를 easy·medium·hard로 나누고 그 버그를 얼마나 잡아내는지 정밀도(지적한 것 중 진짜 버그의 비율), 재현율(전체 버그 중 잡아낸 비율), F1(둘을 하나로 합친 점수)로 채점합니다. 리뷰당 비용과 지연시간, 타임아웃, 노이즈(버그가 아닌데 지적하는 잘못된 리뷰)도 같이 재고요.

공개된 그래프 기준으로 우버는 모델을 갈아타며 F1을 끌어올리는 동시에 PR당 비용을 크게 줄였습니다. 대형 모노레포의 실제 PR 수천 건으로 만든 ‘우버 SWE 벤치마크’도 따로 운영하면서 모든 SDLC(소프트웨어 개발 수명 주기) 매니지드 에이전트의 모델 선정에 썼다고 합니다.

uReview에 시험한 모델 구성 전체. 점선이 파레토 프런티어로, 그 아래·왼쪽에 있는 구성은 더 싸거나 더 좋은 대안에 밀린다 <출처: 우버 엔지니어링 블로그>

사람이 직접 모델을 고르는 인터랙티브 세션에서는 토큰 단가가 고정이지만 어떤 모델에 토큰이 흘러가는지, 그 분배는 관리할 수 있습니다. 이 분배를 좌우하는 기본 설정이 둘 있는데 초기 세션 모델과 서브에이전트 모델입니다.

그중 서브에이전트 기본값이 가장 효과가 큰 레버로 판명됐다고 해요. 모델이 좋아질수록 멀티에이전트 오케스트레이션이 잘 굴러가서 서브에이전트를 띄우는 세션 비율이 꾸준히 느는 만큼 이 레버의 중요도도 계속 커지고 있고요. 서브에이전트가 받는 일은 보통 입력이 분명하며 잘 정의된 작업이라 프론티어급 추론이 필요 없는 경우가 많습니다. 그래서 필요하면 수동으로 바꿀 길은 열어 두되 기본값을 더 싸고 가벼운 모델로 잡았습니다. 주 모델이 작업을 쪼개고 평가하고 서브에이전트가 실행하는 분업이죠.

4. 진짜 낭비는 매 턴 다시 보내는 것들로부터

에이전트와 나누는 대화는 매 턴, 즉 질문과 응답이 한 번 오갈 때마다 전체 대화 이력과 프로젝트 컨텍스트, 도구 결과를 다시 전송합니다. 그래서 요청 하나의 페이로드를 줄이는 조치는 그 한 번으로 끝나지 않고 세션 전체에 복리로 쌓입니다. 우버가 손댄 레버 여럿이 이 반복 전송분을 겨냥합니다.

우선, 하네스 기본값부터 두 개를 표준화했습니다. 하나는 40만 토큰에 도달하면 자동으로 컴팩션(대화 이력 압축)을 트리거하는 것. 컨텍스트 윈도가 100만 토큰인 모델이라도 예외가 아닙니다. 모델 성능과 반복 입력 토큰 비용 사이의 균형점이 그 언저리라는 판단 때문입니다. 실제로 플릿(운영 중인 에이전트 전체) 단위로 요청당 입력 토큰이 의미 있게 줄었다고 하고요. 다른 하나는 추론 강도 기본값을 Medium으로 두는 것입니다. 내부 추론을 포함한 출력 토큰은 입력의 몇 배 요율로 과금되는 최고 비용 카테고리거든요.

프롬프트 캐시 TTL(캐시 유지 시간)도 사용 패턴에 맞춰 조정했습니다. 앞선 컨텍스트를 캐싱해 두면, 그러니까 같은 내용을 다시 보낼 때 벤더 서버가 저장해 둔 것을 재사용하게 하면, 이후 읽기는 표준 입력 요율의 0.1배로 떨어집니다.

그런데 엔지니어들은 인터랙티브 세션을 5분 이상 놀리는 일이 잦았고요. 이 유휴 공백이 캐시를 무효화해 비싼 전액 컨텍스트 재구축을 강제하고 있었죠. 그래서 우버는 인터랙티브 세션을 1시간 캐시로 전환합니다. 다만 캐시에 써넣는 비용은 1시간짜리가 5분짜리보다 비쌉니다. 따라서 애초에 짧은 작업만 맡아 공백이 길어질 일 없는 서브에이전트는 기존 5분 TTL을 그대로 뒀고요.

그다음이 MCP(Model Context Protocol) 스키마입니다. 우버의 MCP 상호작용은 내부·서드파티 합쳐 1,000개가 넘는 서버를 아우르는 통합 게이트웨이를 거칩니다. 그런데 표준 MCP는 그 세션에서 쓰든 말든 설치된 도구 스키마를 전부 세션에 로드합니다. 도구가 100개를 넘으면 초기 프롬프트에 스키마만 5만~7만 토큰이 얹히고 이게 매 턴 재전송됐다고 해요.

처방은 둘입니다. 하나는 CLI 도구 해석입니다. MCP 직접 통합을 터미널에서 입력하는 셸 커맨드 실행으로 바꿔, 호출 시점에 게이트웨이에서 필요한 도구를 해석하게 하는 방식입니다. 이걸로 1,000개 넘는 MCP 도구 전부를 CLI 커맨드로 투영해 스키마를 컨텍스트에서 들어냈습니다. 다른 하나는 도구 검색으로, 모델이 도구 카탈로그를 검색해 필요한 것만 그때그때 로드하게 했습니다.

세션 시작 시점에 에이전트가 이미 짊어진 토큰. 서버를 전부 설치하면 스키마만 5만~7만 토큰이 컨텍스트에 실리지만, 도구 검색과 CLI로 호출 시점에 해석하면 거의 0이다 <출처: 우버 엔지니어링 블로그>

여기서 한 발 더 나간 게 코드 모드입니다. 표준 MCP 워크플로는 액션마다 별도의 모델 턴이 필요합니다. 예컨대 SQL 쿼리 하나를 돌리려면 요청을 내고, 작업이 끝났는지 2~5회 되물어 확인(폴링)하며 출력을 회수하는 멀티턴이 되죠. 코드 모드는 이 흐름 전체를 자동화된 파이썬 루프 하나로 흘려보내 폴링을 모델의 활성 컨텍스트 밖에 둡니다.

그 구조 아래에서 같은 SQL 쿼리들을 기존 경로와 새 경로로 각각 돌려 재봤더니 결과셋이 아주 작은 경우에도 토큰이 50% 이상 줄었습니다. 큰 데이터 페이로드를 우회해서가 아니라 스키마 초기화, 멀티턴 폴링, 중복된 단계별 추론 같은 오버헤드가 사라진 덕분이고요. 모델 턴 N번이 스크립트 하나가 되는 대량 워크플로에서는 절감이 90% 이상으로 커집니다. 우버는 많이 쓰는 MCP 서버들에 대해 25개 넘는 코드 모드 스킬을 미리 만들어 배포해 뒀습니다.

같은 데이터 웨어하우스 쿼리를 두 방식으로 처리한 흐름. 왼쪽은 모델이 폴링 루프에 직접 참여해 응답이 모두 컨텍스트에 쌓이고, 오른쪽은 루프가 별도 프로세스에서 돌아 요약만 돌아온다 <출처: 우버 엔지니어링 블로그>

외부 업체의 구독형 소프트웨어, 즉 서드파티 SaaS의 MCP는 더 골치였다고 합니다. 벤더는 고객별 사용 패턴을 알 수 없으니 제품 기능 전체를 노출하도록 서버를 설계하거든요. 어느 워크스페이스 스위트는 서버 하나에 도구 49개, 스키마만 약 2만 2,000토큰이고 메시징·프로젝트 트래킹 벤더도 각각 34개, 46개를 실어 보냅니다. 이런 서버 두세 개만 붙이면 사용자가 프롬프트를 입력하기도 전에 에이전트가 편집할 파일보다 많은 스키마를 짊어지는 셈이죠. 우버는 이것들도 똑같이 게이트웨이를 거치게 라우팅하고, CLI로 노출하고, 서버별 공통 워크플로는 전용 스킬로 감쌌습니다.

5. 맥락 없는 에이전트는 느리고 비싸다

그라운딩(grounding)은 에이전트가 답을 지어내지 않도록 회사의 실제 데이터와 맥락, 이를테면 어떤 테이블과 서비스와 문서가 있는지에 발을 딛게 하는 일입니다. 반대로 그라운딩되지 않은 에이전트는 “한 군데만 더 찾아보겠다”며 점점 커지는 컨텍스트 윈도를 반복 전송합니다. 그래서 우버는 더 풍부한 정보를 선제 제공하는 것이 이 탐색 오버헤드를 줄이는 가장 강력한 레버라고 말합니다.

수억 줄의 코드와 수천 개의 테이블로 이뤄진 우버 환경에서 에이전트는 턴 대부분을 코드 생성이 아니라 정보 위치 찾기에 씁니다. 탐색이 가장 큰 낭비를 불러온다는 얘기죠. 이걸 잡으려고 만든 것이 ‘AI 컨텍스트 그래프’입니다. 서비스, 엔지니어링 팀, 인시던트 로그, PR, 아키텍처 설계 문서, 배포, 데이터셋, 과거 테이블 사용 쿼리까지 내부 시스템 30여 개의 데이터를 2,400만 노드와 8,000만 엣지로 엮은 통합 네트워크인데요. 노드 타입만 86가지, 엣지 타입은 117가지에 이르고 어떤 에이전트든 자연어로 질의할 수 있습니다.

효과를 보여주는 대조 일화도 실려 있습니다. 그라운딩된 에이전트는 과거 사용 이력을 질의해 분석가 50여 명이 쓰는 테이블을 짚어내고 38초 만에 답을 냈습니다. 그라운딩되지 않은 에이전트는 같은 질문을 받고도 그 테이블을 볼 수 없어 서비스 코드를 20분간 뒤지고 서브에이전트 2개를 띄우고 오류를 3번 겪은 끝에 “이 데이터셋은 질의할 수 없다”는 오답을 냈고요.

같은 모델에 같은 질문을 던졌을 때 그래프 그라운딩 유무에 따른 실행 경로 비교. 그래프가 있으면 38초에 정답, 없으면 20분 9초 만에 오답을 냈다 <출처: 우버 엔지니어링 블로그>

6. 가시성을 올려 토큰 낭비를 막는 구조

이만큼 최적화에 진심이면 지출 상한도 빡빡하게 걸었을 법한데 우버는 엄격한 상한을 강제하는 대신 실시간 추적과 넛지(강제하는 대신 슬쩍 알려서 행동을 바꾸게 하는 방식)를 골랐습니다.

터미널 상태 줄, 즉 명령창 하단의 정보 표시 줄에는 진행 중인 세션 비용이 실시간 카운터로 항상 떠 있습니다. 예산은 도구별로 쪼개지 않고 모든 인터랙티브 하네스를 아우르는 공유 티어(예산 등급) 하나로 묶었고요. 예상 지출의 50%, 80%, 100%에 닿으면 슬랙 알림이 가서 엔지니어가 계획을 세울 시간을 법니다. 티어를 올려야 하면 매니저 승인으로 빠르게 처리되고, 요청하면 즉시(온디맨드) 비용을 분해해 보여주는 스킬도 있습니다.

엔지니어가 늘 보는 터미널 상태 줄. 현재 토큰 사용량과 모델, 개인·팀 풀 사용액, 세션 비용이 함께 표시된다 <출처: 우버 엔지니어링 블로그>

상태 줄이 총액을 보여준다면 비용이 왜 나갔는지는 세션 분석 대시보드가 맡습니다. 이 대시보드는 런타임에 내장돼 있어 설정도, 사용자가 직접 켜는 옵트인도 필요 없습니다. 사용자가 쓰는 모든 하네스의 세션 트레이스(세션에서 오간 요청·응답 기록)를 분석해 흔히 저지르는 비효율적인 습관, 즉 안티패턴 16가지를 찾아냅니다. 안티패턴마다 금전적 영향과 표적 처방이 붙는데요. Sonnet으로 충분한 단순 세션을 Opus에서 돌리는 ‘부적절한 모델 라우팅’, 40KB짜리 MCP 응답이 컨텍스트에 남아 턴마다 반복 과금되는 ‘컨텍스트 윈도 비대’ 같은 것들입니다.

세션 단위 비용 대시보드. 총지출·세션 수·캐시 적중률과 함께 낭비 패턴과 절감 여지를 보여준다 <출처: 우버 엔지니어링 블로그>

폭주 지출은 억제하되 작업의 ROI 판단은 엔지니어에게 맡긴다는 게 우버의 설명입니다. 통제 장치를 늘리는 대신 판단 재료를 주는 설계인 셈이죠.

마치며

여기까지 살펴본 우버 엔지니어링 팀의 에이전트 운영 구조에는 하나하나 깊은 고민의 흔적이 역력합니다. 무작정 사용을 막는 것보다는 AI의 생산성은 최대한 끌어올리되, 시스템으로 낭비를 막은 거죠. 매 턴 다시 전송되는 스키마, 컨텍스트 안에서 돌던 폴링, 답을 찾아 헤매던 탐색 구조. 이처럼 아무 가치도 만들지 않는 토큰을 하나씩 걷어낸 결과입니다. 우버는 치솟는 AI 코딩 비용 역시 풀 수 있는 엔지니어링 문제라고 결론 내립니다.

방향도 분명합니다. 인터랙티브 개발자 워크플로에서 완전 매니지드 에이전트로 무게중심을 옮기는 것. 전용 벤치마크와 파레토 효율 모델을 짝지은 특화 에이전트를 최적화하는 편이 엔지니어 수천 명의 터미널 세션을 하나하나 최적화하는 것보다 확장하기 좋다는 판단입니다. 앞으로는 벤치마크 커버리지를 넓혀 동적 모델 라우팅을 지원하고, 세션 분석도 주기적 배치 탐지에서 실시간 가이드로 진화시키겠다고 합니다.

꼭 우버처럼 큰 팀이 아니어도 에이전트를 쓰는 팀이라면, 아니 개인 그 누구라도 배울 것이 가득합니다. 비용을 방정식으로 쪼개 항목별로 재는 습관, 남들이 좋다는 것 대신 내 업무 벤치마크로 선택하는 모델, 상한으로 막기보다 가시성을 올려 낭비를 막는 태도 같은 것들이요. 에이전트 군단은 어느 회사에서든 앞으로 더 늘어날 겁니다. 그 비용이 점점 무서워지기 시작했다면 우버처럼 일단 방정식부터 쪼개보는 게 어떨까요?

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

]]>

바이브 코딩 시대, 기업은 왜 GitHub Copilot을 선택했을까?

*이 글은 에쓰핀테크놀로지와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

생성형 AI가 개발 환경에 들어오면서 개발자의 선택지는 크게 늘었습니다. 코딩 에이전트는 빠르게 발전하고 있고, 자연어로 요구사항을 전달해 코드를 만드는 ‘바이브 코딩’도 이제 낯선 개발 방식이 아닙니다.

저 역시 업무와 개인 프로젝트에서 여러 AI 모델과 개발 도구를 사용합니다. 그중에서도 GitHub Copilot Business 플랜을 주로 쓰고 있는데요. 처음에는 ‘코드를 자동완성해 주는 AI 개발 조력자’ 정도로 생각했습니다. 그런데 프로젝트에서 계속 쓰다 보니, 자동완성보다 다른 곳에서 더 큰 장점이 보이기 시작했습니다. 업무에 따라 여러 LLM을 골라 쓸 수 있고, 통합 개발 환경과 GitHub 저장소의 이슈, 풀 리퀘스트(Pull Request), 코드 리뷰까지 제가 이미 쓰던 개발 과정 안에서 AI를 그대로 활용할 수 있다는 점이었죠.

무엇보다 기업 환경에서는 여기에 관리라는 문제가 더해집니다. 개발자 한 명에게 AI를 제공하는 것과 수백, 수천 명의 개발자가 사용하는 AI 환경을 운영하는 것은 전혀 다른 문제이기 때문입니다.

이 글에서는 실제 개발 작업에서 GitHub Copilot을 사용한 경험을 먼저 소개하고, 이후 시점을 관리자로 바꿔 기업에서는 모델과 라이선스, 비용, 보안을 어떻게 관리할 수 있는지 살펴보겠습니다.

GitHub Copilot <출처: 작가>

브랜디드 콘텐츠 EVENT: 예산 설정 가이드 다운로드 시, 추첨을 통해 올리브영 5,000원 상품권이 지급됩니다. 이미지 배너를 클릭해 보세요.

내가 GitHub Copilot을 계속 사용하는 이유

1. 기존 개발 환경에서 자연스럽게 사용할 수 있습니다

비주얼 스튜디오 코드(Visual Studio Code) 같은 기존 개발 도구에서 다양한 AI 모델을 골라 쓸 수 있고, GitHub의 저장소, 이슈, 풀 리퀘스트, 코드 리뷰까지 자연스럽게 이어지는 점이 마음에 들었습니다. 에디터뿐 아니라 GitHub.com과 명령줄(CLI), 채팅 환경에서도 같은 방식으로 쓸 수 있어, 이미 GitHub 위에서 일하고 있다면 새로 익힐 것이 많지 않습니다.

제가 재직하는 회사에서는 이처럼 개발 편의성에 더해 라이선스와 비용, 모델 접근 정책 등을 조직 차원에서 관리할 수 있다는 장점을 보고 직원들에게 Copilot Business를 제공하고 있습니다. 개인에게는 AI를 모델별로 고르고 활용하는 편의성을, 기업에는 이를 관리할 수 있는 통제력을 준다는 점이 제가 Copilot을 계속 쓰게 된 이유입니다.

2. 자동 완성을 넘어 전체 개발 작업을 맡기고 활용합니다

처음에는 자동 완성을 주로 사용했지만, 지금 저는 에이전트 모드(Agent Mode)를 주로 활용하는 중입니다. 예를 들어 “사용자 주문 조회 API를 추가하고 관련 테스트를 만들어줘”라고 요청하면 필요한 파일을 찾아 여러 코드를 수정하고 테스트까지 진행할 수 있습니다.

물론 결과를 그대로 사용하지는 않아야 합니다. 저 역시 코드와 테스트 결과는 최대한 직접 확인하는 편입니다. 그럼에도 코드 한 조각을 받아쓰던 것에서, 프로젝트 전반의 개발 작업을 AI와 함께 진행하는 것으로 활용 범위가 넓어진 셈입니다.

GitHub Copilot 에이전트 모드로 API와 테스트 코드를 함께 작성 <출처: 작가>

3. 코딩마다 필요한 AI는 조금씩 달랐습니다

GitHub Copilot에서는 GPT, Claude, Gemini, Grok 등 다양한 AI 모델을 선택할 수 있습니다. 지원 모델은 플랜과 사용 환경에 따라 달라질 수 있지만, 별도의 AI 도구를 오가지 않고 작업에 맞는 모델을 선택할 수 있다는 점이 큰 장점으로 다가왔습니다.

GitHub Copilot에서 개발 작업의 종류에 따라 다양한 AI 모델을 선택할 수 있다 <출처: 작가>

저도 짧은 코드를 뽑을 때는 빠른 모델을, 여러 파일을 오가는 분석이나 오류 추적에는 추론에 강한 모델을 고르는 식으로 바꿔 가며 씁니다. 모델마다 응답 속도와 복잡한 코드에 대한 추론 능력, 처리할 수 있는 컨텍스트 특성이 다르고, 기업용 환경에서는 모델에 따라 AI Credit 소비에도 차이가 날 수 있어 작업 성격에 맞는 선택이 중요합니다.

이렇게 하나의 모델에 개발 환경을 종속시키지 않고, 같은 환경에서 작업에 맞는 AI를 골라 쓸 수 있다는 점이 Copilot을 사용하며 느낀 큰 장점입니다.

물론 Copilot이 알아서 다 해주는 것은 아닙니다

사용하면서 아쉬운 점도 있었습니다. 에이전트가 여러 파일을 분석하고 코드를 수정해 주지만, 항상 제가 의도한 구조로 구현하는 것은 아닙니다. 앞서 API 개발 사례에서도 불필요한 파일을 수정하거나 기존 코드의 규칙을 충분히 반영하지 못하는 경우가 있어 변경된 코드와 테스트 결과를 개발자가 직접 확인하는 과정은 여전히 필요했습니다.

또한 다양한 AI 모델을 제공한다는 것도 처음에는 오히려 선택을 어렵게 만들 수 있습니다. 모델마다 속도와 추론 능력, AI Credit 소비량 등이 다르기 때문에 어떤 작업에 어떤 모델이 적합한지 어느 정도 사용해 봐야 감이 생깁니다. 특히 여러 개발자가 함께 사용하는 기업이라면, 개인이 모두 선택하기보다 조직 단위의 경험을 바탕으로 사용할 수 있는 모델과 비용에 대한 기준을 정할 필요가 있습니다.

API 개발부터 리뷰와 배포까지 연결해 봤습니다

AI를 코드 작성에만 사용하는 것이 아니라 기존 GitHub 개발 과정과 연결할 수 있다는 이야기를 더 구체적으로 보기 위해, 실제 개발 작업을 한번 진행해 보았습니다. FastAPI 서비스에 사용자 주문 조회 API를 추가하는 작업이었는데, 가장 먼저 원래 하던 방식대로 GitHub Issue에 요구사항을 정의했습니다.

Copilot을 활용한 개발 흐름 <출처: 요즘IT>

그 과정에서 Copilot으로 작성한 API 코드를 GitHub 풀 리퀘스트로 연결하고, 자동화된 테스트를 통과한 뒤 병합했습니다. 기존 업무 흐름과 큰 어긋남 없이 준비할 수 있었습니다.

Copilot으로 작성한 API를 풀 리퀘스트로 연결하고 테스트를 통과한 모습 <출처: 작가>

코드 리뷰에도 Copilot을 PR 리뷰어로 지정해 활용했고, 코드 변경 사항을 검토하도록 지시했습니다. Copilot은 새로 추가한 주문 조회 API가 게이트웨이를 통해 외부에 노출되지 않는 문제를 찾아내고, 필요한 수정 방향까지 제안했습니다.

GitHub Copilot이 풀 리퀘스트의 코드 변경 사항을 검토하고 개선점을 제안한 모습 <출처: 작가>

마지막으로, 머지가 끝난 후에는 기존 GitHub Actions를 통해 빌드와 배포를 진행했습니다.

즉, 별도의 AI 개발 프로세스를 만드는 것이 아니라 개발 도구에서 시작한 AI 활용을 GitHub의 이슈, 저장소, 코드 리뷰와 기존 배포 과정까지 이어갈 수 있었습니다. GitHub이란 이름을 달고 있는 도구인 만큼, 그 환경 내에서 업무 흐름을 확장할 때는 가장 편한 AI 서비스 중 하나입니다.

무엇보다 개발자가 수십, 수백 명으로 늘어나면 이러한 편의성만큼 사용량과 비용, 보안, 정책을 어떻게 관리할지가 중요해지는데, 그런 점에서 기업형 도구로도 적합하다고 느끼고 있습니다.

개발자에게는 선택권, 기업에는 통제권

앞서 살펴본 것처럼, 개발자에게 여러 모델과 에이전트를 선택해가며, 자유롭게 개발 환경에 통합할 수 있다는 것은 큰 장점입니다. 그런데 관리자에게는 새로운 고민거리가 생깁니다.

모든 개발자에게 모든 모델을 허용해야 할까요?
AI 사용 비용은 어디까지 허용해야 할까요?
퇴사하거나 부서를 옮긴 직원의 라이선스는 어떻게 관리해야 할까요?

이때부터 AI 도구는 개인의 생산성 도구를 넘어 기업의 AI 거버넌스 문제가 됩니다. 특히 그런 점에서 저희 조직이 Copilot Business와 Enterprise를 쓰는 이유가 나온다고 생각합니다. 관리자가 라이선스와 접근 권한, 모델 및 기능 사용 범위 등을 조직 차원에서 관리할 수 있기 때문입니다.

그래서 GitHub Copilot이 구축해 둔 기업용 관리 기능을 되짚어가며, 실제 기업 환경에서 반드시 신경 써야 할 항목들을 짚어보려고 합니다.

AI 사용량과 비용을 어떻게 관리할까?

그런 맥락에서 가장 먼저 알아야 하며, 제일 중요한 것은 비용, 즉, 사용량과 모델의 관리 체계입니다.

1. 사용량 제어

2026년 현재 Copilot Business는 사용자당 월 19달러(한화 약 2만 6천 원)로, 매월 1,900 AI 크레딧이 기본 제공됩니다. 한편 Copilot Enterprise는 사용자당 월 39달러(한화 약 5만 4천 원)에 3,900 AI 크레딧이 나옵니다. 이때 AI 크레딧은 단순히 질문 횟수로 계산되지 않습니다. 입력·출력 토큰과 사용하는 모델 등에 따라 사용량이 계산되고, 산정 방식이 공식 문서에 공개되어 있어 기업 입장에서 사용량을 가늠하고 관리하기가 수월합니다. 여기에 코드 자동완성과 다음 편집 제안(Next Edit Suggestions)은 유료 플랜의 AI 크레딧을 사용하지 않는 장점도 있습니다.

기업 입장에서 본다면, 사용자에게 포함된 크레딧은 공유 풀(Pool)로 운영됩니다. 예를 들어 Business 사용자 100명이라면 표준 제공량 기준 월 190,000 AI 크레딧을 공유 받게 됩니다. 이를 사람마다 조금씩 다르게 나눌 수 있는데요, 개발자마다 AI 사용 패턴이 다른 기업 환경에 적합한 방식입니다.

다만 기본 제공량을 넘어서는 사용은 추가 비용으로 이어질 수 있습니다. 이럴 때는 초과 사용을 허용하는 기본 상태를 해제하고, 관리자가 직접 정책을 조정한 다음 예산(Budget)을 걸어 통제할 수 있습니다. 예산은 Enterprise·조직(Organization)·Cost Center·사용자(User)의 네 범위로 나눠 설정할 수 있고, 임계치 알림과 사용 차단까지 걸 수 있어 예상치 못한 추가 과금을 막을 수 있습니다.

개발자가 자유롭게 모델을 사용하는 화면 뒤에서 관리자는 결국 ‘누구에게 얼마만큼의 AI 사용을 허용할 것인가’를 관리하는 셈입니다.

GitHub Copilot AI Credit Budget 설정 화면 <출처: 에쓰핀테크놀로지>

2. 모델 제어

또한, 모든 AI 모델을 열어줄 필요는 없습니다. 멀티 모델은 개발자에게는 선택권이지만 기업에는 정책의 대상입니다. 개발자는 회사가 허용한 범위 안에서 업무에 적합한 모델을 선택합니다. 그렇다고 모든 기능을 막으면 AI 도입 효과가 떨어지고, 반대로 아무 기준 없이 열어두면 보안과 비용 관리가 어려워집니다.

따라서 관리자가 조직이나 기업의 정책을 통해 사용할 수 있는 모델과 기능을 능동적으로 결정하는 것이 가장 좋은 방법입니다.

GitHub Copilot의 조직 단위 AI 모델 접근 정책 설정 화면 <출처: 에쓰핀테크놀로지>

정리하자면, 개발자의 선택권과 기업의 통제권 사이에서 기준을 만드는 것이 기업용 Copilot 관리의 핵심입니다.

개인용이 ‘내가 AI를 어떻게 잘 사용할 것인가’에 초점을 맞춘다면 기업용은 ‘우리 회사가 AI를 누구에게 어떤 조건으로 제공하고 관리할 것인가’까지 다룬다는 차이가 있습니다.

모델 제어 기능을 포함한 개인용과 기업용의 차이를 표로 정리하면 다음과 같습니다.

AI 도구를 기업에 도입할 때 추가로 알아야 할 것들

1. 보안과 감사

기업이 생성형 AI를 도입할 때 빠지지 않는 질문이 있죠.

“우리 코드를 입력하면 모델 학습에 사용되는 것 아닌가요?”

GitHub Copilot의 경우, Business와 Enterprise 고객 데이터를 AI 모델 학습에 사용하지 않는다고 명시하고 있습니다. 관리자는 Audit Log를 통해 Copilot 설정과 정책 변경, 라이선스 할당·회수, GitHub 웹사이트에서의 일부 에이전트 활동 등도 확인할 수 있습니다. 다만 개발자가 로컬에서 Copilot에 입력한 모든 프롬프트를 볼 수 있는 것은 아닙니다.

즉, 이러한 기업용 감사 기능은 개발자의 모든 대화를 감시하는 기능이라기보다 조직의 Copilot 운영과 주요 변경 사항을 추적하기 위한 관리 수단으로 보는 편이 정확합니다.

2. 기업 계정과 SSO 연결

개발자가 수백 명으로 늘어나면 입사, 부서 이동, 퇴사에 따른 계정과 라이선스 관리도 중요해집니다. GitHub는 기업 환경에서 SAML 기반 싱글 사인온(SSO)을 지원하며, Enterprise Managed Users 환경에서는 외부 아이덴티티 공급자(IdP)를 이용해 사용자 계정과 라이선스를 관리할 수 있습니다.

따라서 기업에서는 사용자당 가격뿐 아니라 현재 조직과 계정 체계에 어떻게 연결할 것인지도 함께 검토해야 합니다

라이선스 배포로 끝나지 않는 AI 도입

단순히 GitHub Copilot 기업용을 도입하는 것만으로는 온전히 AI를 도입했다고 보기 어렵습니다. 실제 환경에서 사용할 수 있는 상태로, 기업에 AI 도구를 도입하려면 라이선스뿐 아니라 모델 정책, 비용 한도, 계정과 보안 체계를 함께 설계해야 합니다. 여러 개발 조직이 사용한다면 개발팀뿐 아니라 GitHub 관리자, 보안 담당자와 비용 관리 조직도 함께 기준을 정해야 합니다.

따라서 초기 도입에서는 다음 다섯 가지를 먼저 확인할 필요가 있습니다.

기업 환경에 맞는 라이선스 구성: 어떤 조직과 개발자에게 어떤 플랜을 제공할 것인가
초기 도입 정책 설계: 어떤 모델과 기능을 허용하고 조직별 정책을 어떻게 적용할 것인가
비용 및 예산 관리: 라이선스와 AI 사용량을 어떻게 관리하고 한도를 설정할 것인가
기존 Azure 및 GitHub 환경 연계: 기존 조직·계정·권한 체계와 어떻게 연결할 것인가
사전 진단과 운영 지원: 무엇부터 적용하고 실제 사용량에 따라 정책을 어떻게 조정할 것인가

물론, 이러한 내용은 조직 규모가 작거나 GitHub 운영 경험이 충분하다면 내부에서 직접 설계할 수도 있습니다. 반면 여러 개발 조직에 Copilot을 도입하거나 기존 코드 관리·배포 환경과 연계해야 한다면, 이 설계 단계를 함께 검토해 줄 곳이 있는지가 도입 속도를 좌우합니다.

따라서, 기업의 Copilot 도입에서 중요한 것은 계정을 몇 개 준비할 것인가 보다 AI를 누가 사용하고, 무엇을 허용하며, 얼마만큼 사용할 것인지에 대한 기준을 만드는 것입니다. 국내에서는 마이크로소프트 공인 총판인 에쓰핀테크놀로지(S.Pin Technology)가 기업 환경에 맞는 라이선스 구성과 초기 도입 정책 설계, 사전 진단, Azure·GitHub 환경 연계와 운영 정책 수립 등을 지원하고 있습니다. 클라우드 도입 시 이러한 지원을 함께 검토했듯, AI 역시 전문가 그룹의 도움을 받는 것이 좋은 대안입니다.

브랜디드 콘텐츠 EVENT: 예산 설정 가이드 다운로드 시, 추첨을 통해 올리브영 5,000원 상품권이 지급됩니다. 이미지 배너를 클릭해 보세요.

마치며: 어떤 AI가 최고인가? 보다 중요한 질문

처음 GitHub Copilot을 사용할 때 제 관심사는 단순했습니다.

“이 AI는 코드를 얼마나 잘 만들까?”

실제 프로젝트에서 계속 쓰다 보니 질문이 달라졌습니다.

“내가 개발하는 과정에 AI가 얼마나 자연스럽게 들어올 수 있을까?”

그리고 이를 기업으로 넓히면 한 가지 질문이 더 생깁니다.

“수많은 개발자가 사용하는 AI를 우리는 어떻게 관리할 것인가?”

앞으로 AI 개발 도구의 경쟁력은 가장 뛰어난 모델 하나를 갖고 있느냐만으로 결정되지는 않을 것입니다. 개발자가 일하는 방식에 얼마나 자연스럽게 녹아들고, 기업이 그 자유를 얼마나 안전하고 지속 가능하게 운영할 수 있는가가 더 중요한 기준이 될 것입니다. 결국 기업의 AI 개발 환경에서 중요한 것은 개발자의 선택을 제한하는 것이 아니라, 더 많은 선택을 안전하게 열어줄 수 있는 기반을 만드는 일입니다.

이제 기업이 고민해야 할 것은 ‘AI를 개발에 쓸 것인가’가 아니라, ‘개발자에게 AI의 선택권을 어디까지 열어주고 그것을 어떻게 운영할 것인가’입니다. 그 변화는 이미 개발 현장에서 시작되고 있음을 깊이 체감하고 있습니다.

참고 자료

]]>

대기업 AX일수록 작은 문제부터 풀어야 한다(인핸스 FDE)

FDE로 보는 리얼 AX 시리즈 ①

[편집자 주] 요즘IT는 AX 현장에 직접 들어가 일하는 엔지니어, FDE(Forward Deployed Engineer)를 회사별로 만나고 있습니다. 이 시리즈는 특정 기업의 성공담이 아니라, 여러 현장에서 반복되는 패턴을 기록합니다. 등장하는 고객사 사례는 인터뷰이 소속사와 협의해 익명 처리했습니다.

기업의 AI 도입에는 성공 사례보다 실패담이 많습니다. 원인 진단도 여러 갈래로 나와 있습니다. 조직이 문제다, 데이터가 문제다, 워크플로우를 다시 짜야 한다. 어느 것도 틀린 말은 아니지만, AI 도입을 지시받은 담당자에게 당장 무엇부터 해야 하는지는 알려주지 않죠.

그래서 실제 현장에 있는 사람을 만났습니다. 온톨로지 기반 AI 에이전트 플랫폼 ‘AgentOS’를 만드는 인핸스의 이준원 FDE입니다. 그는 주로 대기업의 AX 현장에서 일하는데, 최근에는 일주일에 두 번씩 지방의 한 공장을 방문했습니다. 국내 제조 대기업의 생산 현장입니다. 인핸스는 커머스에서 시작해 제조, 금융, 국방까지 영역을 넓혀왔습니다. 삼성전자를 포함한 40개 이상의 국내외 엔터프라이즈 고객과 일하고 있고, 올해 4월 네이버벤처스로부터 전략적 투자를 받았습니다.

여러 현장을 거친 이 FDE가 지목한 병목은 조직도 데이터도 아니었습니다. 가장 크고 어려운 문제부터 AI에 맡기려 한다는 것. 대기업일수록 목표가 크게 잡히고 관련된 조직도 많은데, 그 큰 문제일수록 지금의 AI가 바로 풀 수 있는 형태가 아니라는 겁니다. 이 어긋남이 어디서 시작되고, 현장에서 어떻게 되돌리는지를 물었습니다.

이준원 인핸스 FDE
데이터 사이언티스트·머신러닝 엔지니어로 추천·광고·음성인식 도메인을 거쳐, 테크 PL로서 기술 문제를 정의하고 엔지니어와 프로젝트를 리드해 왔다. FDE가 그 두 경험을 함께 쓸 수 있는 자리라고 생각해, 인핸스가 FDE 조직을 본격 운영하기 시작한 올해 5월 합류했다. 그는 FDE가 “정해진 요구사항을 그대로 구축하기보다 컨설턴트의 자아를 가지고 문제를 재정의하는 일을 한다”고 정의한다. 인핸스는 FDE를 고객의 업무와 도메인을 분석하고 프로젝트를 총괄하는 ‘도메인 FDE’, 데이터 구조화와 온톨로지 구축을 담당하는 ‘데이터 FDE’, 에이전트와 애플리케이션의 기술 구현을 담당하는 ‘엔지니어링 FDE’ 세 유형으로 나누고, 프로젝트 성격에 따라 매번 팀을 재구성해 파견한다. 이준원 FDE는 데이터 FDE에 가깝고, 지금 맡은 프로젝트에서는 PM 역할도 함께 하고 있다.

AX의 진짜 병목: 가장 어려운 문제부터 맡기려 한다

Q. 기업들이 AX를 시작하는 단계에서 가장 많이 겪는 어려움부터 묻겠습니다. 현장에서 보시기에 진짜 병목은 무엇인가요?

어떤 것이 AX가 되는 문제인지를 스스로 판단하는 게 제일 어려운 것 같아요. AX가 되는 업무를 보면 세 유형이 있습니다. 흩어져 있는 데이터와 지식을 온톨로지로 구조화하는 것, 반복되는 업무를 자동화하는 것, 사람의 굉장히 어려운 판단과 의사결정을 도와주는 것. 세 가지 다 AX가 가능하긴 하지만 간단한 것부터 시작해 복잡한 것으로 나아가야 한다고 생각합니다.

그런데 많은 분들이 AI로 가장 어렵고 복잡한 문제를 가장 먼저 해결하려고 하십니다. 당연히 AI가 어려운 문제를 풀어주면 좋겠지만, 복잡한 수학적 최적화, 머신러닝 같은 복잡한 모델이 들어가는 문제는 AI가 바로 대체할 수 있는 영역이 아니에요. AX는 데이터를 모으고 반복 업무를 자동화해서 리소스를 줄이는 것부터 시작해야 하고, 사람의 어려운 판단을 돕는 건 그다음이라고 생각합니다.

Q. 그 가장 어렵고 복잡한 문제라는 것은 실제로 어떤 모습인가요? 예를 들어주실 수 있나요?

예를 들어, 합병한 두 회사의 레거시 코드를 코딩 에이전트로 병합해서 통합 코드를 만들어 달라는 과제가 오기도 합니다. 그런데 이 일은 사람이 계속 들여다봐도 쉽게 할 수 없는 일이에요. 저희는 그건 AX 과제가 아니라고 봤어요. 대신 두 회사가 합병하면서 생긴 문제 중 저희가 풀 수 있는 걸 역으로 제안했죠. 서로 다른 양식과 포맷으로 정리되어 있는 계약·서류 데이터를 하나의 포맷으로 구조화하는 과제 같은 거죠. 이런 문제부터 AI로 푸는 것이 좋습니다.

Q. 그럼 혹시 앞서 온톨로지나 자동화 이후에 해야 한다고 언급하셨던, 사람의 어려운 판단을 돕는 AX를 실제로 하고 계신 사례도 있나요?

제조업에는 ‘올해 이만큼 생산해서 매출을 내겠다’는 생산 계획이 있고 실제 실적이 있어요. 두 데이터를 놓고 ‘이 상품을 더 많이 생산하고 저 상품을 덜 생산했다면 실적이 얼마나 달라졌을까’ 하는 What-if 시뮬레이션을 돌려서, “이 비용이 핵심 요인이었구나, 내년에는 이 비용을 최대한 줄여보자”는 식의 판단을 지원하는 수준으로 진행했습니다.

FDE의 문제 해결법: 말하지 않고 보여주기

그렇다면 고객이 당장은 풀기가 어려운 문제를 들고 왔을 때, FDE는 그 상황을 어떻게 해결할까요. 그가 최근 맡은 프로젝트가 그런 경우였습니다. 앞서 말한 그 공장의 공정 개선 과제인데요. 이 회사는 3단계 로드맵을 세워두고 있었습니다.

1단계는 공정을 다루는 AI를 만드는 것, 2단계는 그 AI가 스스로 판단하고 실행하는 에이전트가 되는 것, 3단계는 여러 에이전트를 묶어 함께 돌리는 것. 그중 요청받은 과제는 마지막 3단계였고, 앞의 두 단계는 이미 준비되어 있다는 설명이 따라왔습니다. 하지만 현실은 막상 그렇지 않았죠.

Q. 들어가 보니 앞의 두 단계는 어떤 상태였나요?

막상 깊게 살펴보니 1, 2단계가 아직 3단계로 넘어갈 만큼 충분하지는 않았어요. 저희와 고객사의 기준이 좀 달랐던 것이죠. 그래서 에이전트 오케스트레이션을 바로 실행하기엔 어렵다고 판단했어요.

이런 경우가 드물지 않습니다. 잘 정의된 PoC(개념 증명)도 있지만, 어떤 PoC는 “공정을 최적화하고 싶다, 생산성을 높이고 싶다”는 식으로 문제가 흐릿한 형태로 오거든요. 들어가서 실제로 보면 완전히 다른 문제거나, 데이터가 준비된 게 너무 없거나, 프로세스가 아예 없는 케이스가 있었습니다.

Q. 그래서 어떻게 해결하셨나요? 1·2단계가 먼저 필요하다고 설득하셨나요?

일단 1·2단계 없이 3단계를 시도해 보다가 도저히 안 돼서,1·2단계를 최대한 간략화해 만들어서 3단계가 동작하는 걸 보여드렸습니다. 각각의 에이전트가 있어야 오케스트레이션이 된다는 건 말이 아니라 고객이 스스로 보고 느껴야 하거든요.

다만 고객 입장에서도 1단계를 확실히 검증하는 게 목표인지, 1·2단계를 임시로 만들어서라도 3단계를 보는 게 목표인지 스스로 정하지 못하셨던 것 같아요. 그래서 저희는 이건 이것대로 보여드리는 동시에, 1단계부터 잘 만들어야 한다고 말씀드렸습니다.

Q. 말로 하기보다 일단 보여주시는군요. 애초에 3단계 로드맵을 세웠으면 1·2단계도 시도를 했을 텐데, 왜 산출물이 없었을까요?

그건 잘 모르겠습니다. AX 현장에서는 다양한 케이스가 발생해요. 고객도 여러 가지 고민과 상황이 있고, 어떤 것들은 조직의 헤게모니 때문에 벌어지기도 하기 때문에 모든 배경을 전부 알 수는 없습니다. 다만 이번 사례로 저희도 배운 게 있어요. PoC 자체를 문제를 정의하기 위한 목적으로 진행하는 것도 좋다는 것입니다. 문제가 정의되어 있어야 고객과 함께 풀 수 있는데, 그렇지 않은 경우는 아예 저희가 문제정의부터 해서 방향을 잡는 것이 더 좋은 결과를 낼 수 있다고 생각해요.

온톨로지의 진짜 과제: 데이터에 없는 것을 찾아내기

그가 앞선 사례를 해결하기 위해 가장 먼저 만들어야 했던 1단계 AI는 공정을 다루는 AI였습니다. 어떤 설비를 언제 돌리고 무엇을 먼저 처리할지 판단하려면, 이 공장의 공정이 어떤 순서로 얼마나 걸리며 어떤 제약 아래 돌아가는지를 AI가 알고 있어야 합니다.

결국 실제 업무 흐름을 반영한 데이터가 있어야 하고, 그 데이터가 각각 어느 공정에 속하고 어떤 개념과 이어지는지를 정의한 온톨로지가 필요합니다. 인핸스의 AgentOS는 온톨로지를 기반으로 기업 데이터를 구조화하고, 그 위에서 AI 에이전트가 업무를 수행하도록 돕는 플랫폼이죠. 회사 곳곳에 흩어져 있던 것들을 필요할 때 한 번의 쿼리로 꺼낼 수 있게 만들어두는 겁니다.

문제는 그 지식이 자료로만 오지 않는다는 데 있습니다. 그래서 FDE는 현업을 만납니다. 팔란티어도 FDE를 고객사에 직접 들어가 붙는 엔지니어로 정의하는데, 한 FDE는 “해당 분야를 가장 잘 아는 사람은 결국 고객이기 때문에 그들과 이야기하는 데 많은 시간을 썼다”고 회사 블로그에서 밝힌 바 있습니다.

그가 마주한 것도 그 지점이었습니다. 자료로 받은 것과 현장이 아는 것이 달랐고, 그 차이는 공장에 가서야 드러났습니다.

Q. 온톨로지를 만들려면 현업을 만나야 할 텐데, 인터뷰가 정식 절차로 있는 건가요? 인터뷰를 반기지 않는 경우도 있을 텐데요.

고객 문제를 발견하기 위한 정식 인터뷰 절차가 있지만, 고객사 상황에 따라 유연하게 진행합니다. 다만 현업 입장에서는 무엇을 얼마나 말해야 하는지 모르는 채로 시간을 내는 게 부담일 수 있기 때문에 저희가 가진 데이터와 제약 안에서 질문 리스트를 최대한 만들어서 갑니다. “어떻게 업무하시는지 볼게요”가 아니라 “저희가 유추해 보니 A는 이런 것 같고 B는 이런 것 같은데 맞느냐”고 묻는 거죠. 틀린 것도 많을 겁니다. 그러면 하나하나 대답하시다가 “이럴 바에는 날 잡고 다 설명해 드리겠다”가 됩니다.

Q. 그렇게 준비해 간 계획이 현장에서는 다르게 읽힌 적도 있나요?

앞서 말한 공정 과제에서, 고객에게 받은 데이터를 분석해 계획을 만들었는데, 막상 그 계획을 들고 지방 생산 현장에 가보니, 현쟁의 예외 규칙까지 충분히 반영된 데이터가 아니란 걸 알게 됐어요.

예를 들면 “이 공정은 데이터에는 12시간으로 되어 있지만 급할 땐 6시간으로 당겨서 해요”라든지, “생산량 제약은 보통 200까지 제한하지만, 급할 때는 250까지 늘리기도 하고요” 같은 현장 운영 노하우는 현장에서만 들을 수 있었습니다. 데이터에 반영되지 않은 것들이죠. 결국 키맨은 공장에 있는 현업이구나 싶어서, 그때부터 실제로 공장에 가서 현업 인터뷰를 했어요. 거의 일주일에 두 번씩 갔던 것 같습니다.

Q. 그렇게 파악한 현장의 노하우는 시스템에 어떤 식으로 들어가나요?

현장에서 나온 말들을 저희가 온톨로지에 반영합니다. 가장 이상적인 건, 미팅을 녹음하고 그 녹음을 음성 인식으로 정리해서 필요한 암묵지와 지식을 AgentOS에 넣는 겁니다. 다만 보안 등 여러 이유로 그런 기능을 제품 안에 넣기 어렵거나, 넣더라도 고객사 PC에서 쓰기 어려울 수 있어요. 그래서 지금은 FDE들이 한 번 가공해서 필요한 정보만 넣습니다. 이 가공 과정도 추후 AgentOS에 탑재되면 더 좋은 거고요.

AI 도입 프로젝트로 할 수 없는 일: 조직과 KPI

현장을 파악하고 구조로 옮기는 일에는 사람의 시간과 노력이 필요합니다. 그래서 무엇을 할지 정하는 게 먼저입니다. 그가 현장에 들어가 가장 먼저 확인하는 것도 작업의 범위고요. 이를 위해 과제 목표, 요구사항, 고객이 정확히 무엇을 풀려는지, 그리고 범위와 검증 지표를 확인하고 정합니다. 이 네 가지 중 시간이 가장 많이 드는 게 마지막입니다. 파견 전부터 논의를 시작하는데도, 들어가고 나서 짧으면 2주 길면 한 달을 범위를 정하는 데 씁니다.

그런데 이 정의가 잘 되어도 프로젝트가 굴러가지 않을 때가 있습니다. 그는 AX가 막히는 지점이 기술이었던 적은 오히려 드물다고 했습니다.

Q. 처음 2주에서 한 달 동안 무슨 일이 벌어지나요?

정해진 기간 안에 가장 큰 임팩트를 내는 게 중요하기 때문에, 고객사의 요청을 바탕으로 스코프를 정하는 게 중요해요. 챗봇 프로젝트를 예로 들면, 고객사가 제안하는 100개의 시나리오 목록이 있다면, 그중에서 비즈니스 임팩트가 있는 것들을 우선적으로 고려합니다. 그래서 중요한 것 20~30개를 어떻게든 해내면서, 남은 70개를 다 하는 것보다 다른 조직의 데이터를 가져와서 푸는 게 더 임팩트 있다고 설득하죠.

또 프로젝트를 진행하는 메인 조직과 관련 부서의 담당자를 만나 현황을 파악하고 병목이 무엇인지, 과제의 키맨은 누구인지를 파악하는 것도 중요합니다. 이렇게 프로젝트 성공을 위해 필요한 기술 이외의 모든 요소를 빠르게 파악하고 대응하는 것이 전체 프로젝트의 성공을 좌우하기도 하죠.

Q. 그런데 그 다른 조직의 협조는 잘 얻어지나요?

그게 제일 어렵습니다. 한 사람이 담당하는 작은 업무의 AX는 그 사람의 일을 덜어주는 거라 접근이 쉬워요. 그런데 범위가 넓어지면 A 조직 역할 일부와 B 조직 역할 일부를 떼어 두 조직이 협업해야 합니다. 어떤 데이터를 준비할지, 컬럼을 어떻게 통일할지, 어느 업무까지 자동화할지를 두 조직이 합의해야 하는 거죠. 그런데 옆 조직은 이 과제에 참여하고 있지 않으니까 리소스를 내주기 어려운 상황들이 발생합니다.

이보다 더 어려운 건 각 조직의 KPI가 다른 경우예요. A조직의 KPI는 AX인데 B조직은 다르면, 조직별 KPI와 우선순위가 다르니 협조를 얻기 어려우질 수도 있죠. 결국 문제 정의보다 그 문제를 풀기로 하는 이해관계자들의 합의가 훨씬 어렵고, 대기업일수록 더 어렵습니다.

Q. 그럼 FDE는 그 상황에서 무엇을 하나요?

FDE가 조직의 문제 자체를 해결하긴 어렵죠. 다만 저희가 할 수 있는 건 빠른 판단으로 일을 진행시키는 것입니다. 어느 조직의 협력이 필요한지를 빠르게 확인하고, 예를 들어 “B팀의 협력이 있어야 이 AX가 가능하다”는 게 확인되면 담당 과제의 리더에게 바로 에스컬레이션하죠. 막힌 곳을 알리고 조직 차원에서 문제를 풀어주십사 요청하는 것입니다.

Q. 그런데 AX를 지시받은 담당자 입장에서는 조직 문제라고 손을 놓을 수가 없잖아요. 어디서부터 움직여야 할까요?

맞습니다. 결국 과제에 필요한 연관 조직, 이해관계자들과 함께 과제를 정리하고 설계하는 것. 그건 AX를 하고 싶어 하는 현업이 리더와 같이 풀어야 하는 부분이라고 생각합니다.

Q. 그럼 어떤 회사가 AX에 성공한다고 보시나요?

지금 많은 임원 분들이 AX에 대한 의지가 있습니다. AX로 리소스를 줄이고 생산성을 늘리겠다는 것이죠. 다만 그 의지가 단순 의지로 끝나지 않으려면, 더 구체적인 스코프(scope)와 뾰족한 문제로 정의되어 해결되는 경험을 회사가 계속 쌓아야 해요. 그렇게 작은 것부터 쌓아가다 보면, 우리 회사에서 어떤 문제는 AX가 잘 되고 어떤 문제는 나중에 해야 한다는 판단이 섭니다. 그 판단이 서는 회사들이 결국 AX에 성공하지 않을까 싶습니다.

이준원 FDE의 이야기는 큰 목표를 버리라는 쪽으로 가지 않습니다. 목표는 크게 두되 검증은 1단계부터 하라는 것에 가깝죠. 그리고 그 1단계를 만들어내는 방식은 인터뷰 내내 같았습니다. 필요하다고 주장하는 대신 만들어서 보여주고, 시간을 내달라고 요청하는 대신 틀린 유추를 들고 가서 상대가 먼저 설명하게 합니다. 그렇게 얻은 것들이 온톨로지가 되고, 그 위에서 에이전트가 판단을 시작합니다.

다만 그도 인정하듯 이 방법으로 풀리지 않는 영역이 있습니다. 조직과 조직 사이, 서로 다른 KPI 사이에 놓인 문제들이죠. 그건 외부에서 들어온 엔지니어가 대신 풀어줄 수 없고, AX를 하겠다고 결정한 쪽이 안에서 풀어야 합니다.

마지막으로 그는 FDE로 일하며 배운 것을 이야기했습니다. 처음 FDE가 됐을 때는 고객의 임팩트 있는 문제를 주도적으로 해결하겠다는 꿈이 있었다고 합니다. 그런데 현실은 스코프를 잘 줄이고 단계별로 나아가야 하는 일이었죠. 모든 PoC가 예상한 방식으로 본 사업까지 이어지는 것은 아니기도 하고, 이상과 현실의 차이에 좌절할 때도 있지만, 그 사이클을 돌면서도 큰 임팩트를 내겠다는 이상만은 포기하지 않는 게 중요하다고 했습니다.

회사도 다르지 않을 겁니다. AX가 가져다줄 그림은 크게 그리되, 지금 발을 디딜 곳은 어려운 문제가 아니라 매일 반복되는 일 쪽입니다. 그 일에 쓰이는 데이터가 어디에 어떤 형태로 있는지, 그 판단을 실제로 내리는 사람이 누구인지부터 확인하는 거죠. AI로 무엇을 할지는 그다음에 정해도 늦지 않을지도 모릅니다.

AX 현장의 이야기를 더 가까이서 나눌 자리를 검토하고 있습니다.
어떤 형태가 좋을지 의견을 들려주세요. 1분이면 됩니다.
➡️ AX 관련 행사·모임 수요 조사

]]>

매월 30분씩 투자하던 일을 1분으로 줄였더니

앞선 글에서 나는 400페이지짜리 점검 문서의 서명을 검사하는 도구를 이야기를 했다. 이번에도 자동화에 관한 이야기지만 대상이 다르다. 이번엔 한 장이 아니라, 두 장의 문서를 서로 맞춰보는 일이다.

매달 마감이 되면 나는 두 종류의 문서를 나란히 놓는다. 하나는 팀원들의 한 달 출근 기록이고, 다른 하나는 그달에 낸 휴가 신청서 묶음이다. 내가 하는 일은 단순하다. 출근 기록에 오전 반차나 연차라고 적힌 날마다, 거기에 맞는 휴가 신청서가 실제로 있는지 확인하는 것이다.

말로 쓰면 한 줄인데, 실제로는 종이를 스캔한 문서를 한 장씩 넘기며 손으로 적힌 표기를 읽고, 다른 문서에서 같은 사람의 같은 날짜를 찾아 맞춰봐야 한다. 한 건이라도 어긋나면 근태와 정산이 틀어진다. 매달 이 대조 업무에 시간을 쓰면서, 이것도 AI에 맡겨보면 어떨까 고민해 본 과정을 담아보았다.

출근 기록과 휴가 신청서를 이미지로 읽어 양방향으로 맞추고, 어긋난 것만 사람에게 올리는 흐름 <출처: 작가, 클로드로 생성>

이 대조는 왜 번거로웠을까

출근 기록과 휴가 신청서는 애초에 다른 곳에서 만들어진다. 출근 기록은 한 달 치 근태를 한 장에 요약한 표이고, 휴가 신청서는 사람마다 날짜마다 따로 낸 개별 문서다. 하나는 요약본, 하나는 낱장이다. 이 둘을 맞추려면 요약본의 한 칸을 보고 낱장 더미에서 짝을 찾아야 한다.

번거로움은 규칙이 하나가 아니라는 데서 온다. 출근 기록에 휴가로 표기됐다고 해서 전부 신청서가 있어야 하는 건 아니다. 출장이나 교육은 근무의 일종이라 휴가 신청서를 쓰지 않는다. 당직도 마찬가지다. 당직은 쉬는 날이 아니라 일하는 날이라 신청서가 없다. 반대로 당직 다음 날 오후에 반차를 쓴 경우에는 신청서가 있어야 한다. 이런 예외를 머릿속에 두고 한 칸씩 대조하다 보면, 단순 확인인데도 신경이 계속 쓰인다.

그리고 두 문서 모두 손으로 쓰고 도장을 찍은 뒤 스캔한 것이다. 화면으로 보면 글씨가 보이지만 컴퓨터에는 글자 정보가 없다. 앞선 글에서 다룬 벽과 같다. 화면에 보이는 것과 컴퓨터가 읽을 수 있는 것은 다르다. 게다가 이번에는 인쇄된 글자가 아니라 사람이 손으로 적은 표기라, 읽어내기가 한층 까다롭다.

어긋남이 왜 문제가 되는지는 지나고 나서야 크게 느낀다. 출근 기록은 그 자체로 끝나는 문서가 아니라, 나중에 근태와 정산으로 이어지는 근거가 된다. 오전반차로 적혀야 할 날이 종일 근무로 남아 있거나, 신청서 없이 휴가로 처리된 날이 섞이면, 몇 달 뒤 다른 자료와 맞춰볼 때 숫자가 어긋난다. 그때는 이미 원본을 다시 꺼내 한 장씩 확인해야 하고, 사람들의 기억도 흐릿해진 뒤다. 매달 마감 때 30분을 들여 대조하는 이유가 여기에 있었다. 지금의 30분이 나중의 반나절을 막아준다.

무엇으로, 어떻게 만들었나?

이번에도 설계는 클로드 코드와 대화하며 잡았다. 나는 개발자가 아니라서, 내가 한 일은 문제와 규칙을 설명하는 것이었다. 매달 내가 어떤 순서로 대조하는지, 어떤 날은 건너뛰는지, 어디서 자주 헷갈리는지를 말로 풀어 주면 클로드가 그걸 코드와 절차로 바꿨다. 완성된 도구는 세 단계로 움직인다.

먼저 파이썬이 두 스캔 PDF를 페이지마다 고해상도 이미지로 바꾼다. 여기에는 1편 서명 검사 때 익혀 둔 PyMuPDF를 그대로 다시 썼다. 도구를 하나 만들고 나면 그 부품이 다음 도구에 또 쓰인다는 걸 이때 실감했다.

다음 단계가 고비였다. 그 이미지를 읽는 일이다. 1편의 서명 검사는 칸이 칠해졌는지만 보면 됐다. 잉크가 묻은 정도를 숫자로 재는 것으로 충분했고, 글자를 읽을 필요가 없었다. 이번에는 다르다. 손으로 쓴 오전반차와 연차를 구분해서 읽어야 한다. 픽셀 계산으로는 안 되는 일이고, 일반 OCR도 흘려 쓴 한글 앞에서는 거의 읽지 못했다. 그래서 이 부분은 코드가 아니라 AI에게 맡겼다. 렌더링한 이미지를 클로드에게 주고, 사람이 표를 훑듯 읽게 했다. 누가, 며칠에, 어떤 종류의 휴가인지를 목록으로 뽑는 것까지가 AI의 몫이다.

마지막으로 그 두 목록을 규칙에 따라 맞춘다. 성명, 날짜, 휴가 종류 세 가지가 모두 맞아야 한 건으로 친다. 출장과 교육과 당직을 건너뛰는 예외도 이 단계에 넣었다. 결과는 색으로 구분된 HTML 보고서 한 장으로 남는다. 정상은 초록, 애매한 건 노랑, 어긋난 건 빨강이다.

실행 방식은 1편과 같은 원칙을 지켰다. 명령어를 몰라도 되도록, 두 PDF 파일을 배치 파일 아이콘 위에 끌어다 놓으면 분류부터 이미지 변환까지 이어서 돌아가게 했다. 매달 쓰는 도구는 시작이 쉬워야 다음 달에도 손이 간다.

스캔 문서가 목록이 되기까지: 파이썬 이미지 변환, AI 판독, 규칙 대조, 끌어다 놓는 실행(가명·예시로 재구성) <출처: 작가, 클로드로 생성>

사람이 하던 방식을 그대로 옮기기

도구가 두 문서를 읽고 나면, 대조는 오히려 단순해진다. 출근 기록 쪽 목록과 신청서 쪽 목록을 양방향으로 맞춰본다. 출근 기록에는 반차라고 돼 있는데 신청서가 없으면 표시하고, 반대로 신청서는 있는데 출근 기록에 표기가 빠졌으면 그것도 표시한다. 한쪽으로만 맞추면 다른 쪽 누락을 놓치기 때문에 양쪽에서 본다.

처음 만든 버전은 당직 날을 전부 어긋난 건으로 올렸다. 당직에는 신청서가 없으니 도구 입장에서는 짝이 없는 게 맞다. 그 화면을 보고서야 나는 내가 머릿속으로만 알고 있던 예외를 도구에게 알려주지 않았다는 걸 알았다. 출장과 교육과 당직은 휴가가 아니라는 것, 다만 당직 다음 날 오후 반차는 대조 대상이라는 것. 이 예외를 규칙으로 넣고 나서야 도구가 올리는 건수가 실제로 봐야 할 것만 남게 줄었다.

AI가 글씨를 제대로 읽는지도 처음에는 믿을 수 없었다. 그래서 첫 달에는 도구를 돌리고도 내가 하던 방식대로 눈으로 한 번 더 대조했다. 도구가 읽은 목록과 내가 손으로 확인한 목록을 나란히 놓고, 사람과 날짜와 종류가 하나씩 맞는지 봤다. 몇 군데는 도구가 흐린 칸을 애매하다고 올렸는데, 그건 내가 봐도 애매한 칸이었다. 도구가 나보다 잘 읽는 건 아니었다. 다만 내가 헷갈리는 곳을 도구도 헷갈린다는 것, 그리고 내가 무심코 넘긴 곳을 도구는 넘기지 않는다는 것은 확인했다. 그 정도면 믿고 쓸 수 있다고 봤다. 사람보다 정확하기를 바란 게 아니라, 사람이 놓치는 곳을 대신 잡아주기를 바란 것이었으니까.

양방향 대조 결과에서 어긋난 건과 애매한 건만 모아 보여주는 화면(가명·예시로 재구성) <출처: 작가, 클로드로 생성>

도구에 다 맡기지 않은 이유

여기까지 만들자 도구가 두 목록을 맞춰 결과를 내놨다. 그런데 나는 그 결과를 그대로 믿지 않기로 했다.

원본이 손글씨이기 때문이다. 오전반차와 오후반차는 글씨체에 따라 헷갈릴 수 있고, 흐리게 스캔된 칸은 사람이 봐도 애매하다. 도구가 오전을 오후로 잘못 읽으면, 서류상 아무 문제가 없는데도 어긋난 것처럼 보이거나 그 반대가 된다.

그래서 도구의 역할을 좁혀 두었다. 도구는 두 문서를 전부 읽어 맞춰보고, 어긋난 것과 애매한 것만 한 화면에 모아 올린다. 있다 없다의 최종 판단은 사람이 그 화면을 보고 한다. 스물다섯 건이 넘는 걸 전부 대조하는 대신, 도구가 올린 몇 건만 사람이 확인하면 된다. 이게 30분을 1분으로 줄인 진짜 이유다. 시간이 준 건 대조를 안 해서가 아니라, 사람이 볼 곳이 몇 곳으로 좁아졌기 때문이다.

실제로 도구가 애매하다고 올린 칸을 열어보면, 종류를 적은 글씨가 반쯤 지워졌거나 칸 밖으로 삐져나간 경우가 많았다. 어떤 칸은 오전이라고 썼다가 오후로 고쳐 쓴 흔적이 겹쳐 있었다. 이런 칸을 도구가 알아서 결론 내게 두면 위험하다. 그래서 도구는 억지로 판정하지 않고 애매하다고 표시해 사람에게 넘긴다. 나는 원본을 확대해 다시 보고, 그래도 모르겠으면 그날 그 사람에게 직접 물어본다. 판단을 사람에게 남긴다는 건 이런 장면을 말한다. 도구가 스물네 건을 맞게 읽어도, 애매한 한 건을 사람이 보지 않으면 결국 그 한 건이 나중에 문제가 되기 때문이다.

실제로 돌려본 결과

한 달 치 실제 문서로 돌려봤다. 그달에는 출근 기록에 표기된 휴가와 신청서가 스물다섯 건 대 스물다섯 건으로 맞았다. 짝이 없는 건은 하나도 없었다. 숫자만 보면 전부 정상이다.

그런데 도구가 한 건을 올렸다. 신청서는 제때 제출돼 있는데, 그 신청서의 휴가 종류 칸에 표시가 빠져 있는 경우였다. 출근 기록에는 오전반차라고 적혀 있고 신청서도 있으니, 있다 없다만 세면 그냥 지나간다. 도구는 종류까지 맞춰봤기 때문에, 종류 표시가 비어 있는 그 한 장에서 걸렸다. 아마 급하게 쓰면서 동그라미 하나를 빠뜨렸을 것이다.

이런 건 자체는 크지 않다. 다만 근태 기록은 나중에 정산의 근거가 되기 때문에, 작은 표시 하나가 시간이 지나 문제가 되기도 한다. 그때 가서 찾으면 훨씬 번거롭다. 매달 한 번, 어긋난 곳을 미리 잡아두는 것만으로 뒤가 편해진다.

그 뒤로는 매달 같은 방식으로 돌린다. 어떤 달은 도구가 한 건도 올리지 않고, 어떤 달은 두세 건을 올린다. 올라온 건을 열어보면 대부분은 이렇게 쓰다가 빠뜨린 사소한 표시이고, 가끔은 신청서를 늦게 낸 경우다. 어느 쪽이든 그 자리에서 바로잡으면 끝난다. 예전에는 이런 걸 찾으려고 스물다섯 장을 넘겼는데, 지금은 도구가 짚어준 자리만 확인한다. 대조라는 일이 없어진 게 아니라, 내가 눈을 둬야 할 곳이 달라졌다.

한 가지 덧붙이면, 이 방식은 근태에만 쓰이지 않는다. 매달 같은 두 문서를 서로 맞춰보는 일은 생각보다 많다. 발주 내역과 정산 내역, 계획과 실적, 신청과 승인. 형태만 다를 뿐 구조는 같다. 한쪽에 있는 항목이 다른 쪽에도 있는지, 그리고 종류와 조건까지 맞는지 확인하는 일이다. 나는 휴가 대조로 시작했지만, 이 도구를 만들고 나서 다른 대조도 같은 방식으로 볼 수 있겠다는 생각이 들었다. 실제로 그중 몇 가지는 뒤이어 도구로 만들었다.

남는 것은 시간보다 근거

시간이 준 것도 좋았지만, 나에게 더 크게 남은 건 따로 있었다. 대조를 끝내고 나면 어떤 건을 봤고 어떤 건이 어긋났는지가 화면에 남는다. 확인했다는 말이 아니라, 어떻게 확인했는지가 함께 남는다.

마감 업무는 결국 누군가에게 제대로 봤다는 걸 설명해야 하는 일이다. 예전에는 그 근거가 내 기억뿐이었다. 지금은 매달 같은 형태의 기록으로 남으니, 나중에 물어봐도 그 화면을 다시 열면 된다. 시간을 줄인 것보다 이쪽이 실무에서는 더 든든하다.

마치며: 없애는 대신 좁히기

이 도구를 만들며 다시 확인한 게 있다. 자동화가 사람을 빼는 일이라고 생각하기 쉬운데, 내 경우는 반대였다. 도구는 사람이 지치는 부분을 대신했다. 스물다섯 건을 한 장씩 넘기며 짝을 찾는 일 말이다. 그리고 판단이라는 마지막 한 걸음은 사람에게 남겼다.

나는 개발자가 아니다. 그런데도 매달 쓰는 도구를 하나 더 완성했다. 파이썬이 문서를 이미지로 바꾸고, AI가 손글씨를 읽고, 규칙이 대조하고, 마지막은 사람이 본다. 대단한 기술을 쓴 게 아니라, 내가 매달 하던 일을 단계별로 나눠 각각 잘하는 쪽에 맡긴 것이다. 혹시 매달 반복되는 대조나 확인에 시간을 쓰고 있다면, 그 일을 통째로 없애려 하기보다 사람이 볼 곳을 좁히는 방향으로 한번 생각해보시면 좋겠다. 거기서부터 생각보다 많은 게 바뀐다.

이 글이 마음에 드셨다면, 작가 페이지에서 알림 설정과 좋아요를 부탁드립니다.

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

]]>

AI와 협업하는 최선의 워크플로우 찾기

AI에게 바이브 코딩으로 AI툴 개발을 시킵니다. 또 하나의 창에서는 사용자 리서치 정리도 시켰습니다. 또 다른 에이전트에게는 경쟁사 분석도 시킵니다. 작업물 3개를 세 개를 동시에 돌렸으니 생산성은 마땅히 3배가 되어야 합니다. 하지만 막상 결과물을 받으면 어디부터 봐야 할지 멍하니 고민이 됩니다. 결과물을 훑으며 “괜찮은데?” 했지만, 곧 불안해졌습니다. 이게 진짜 괜찮은 건지, 그냥 그럴듯해 보여서 괜찮다고 느끼는 건지, 구분이 안 되기 시작했습니다.

왜 AI에게 일을 시키면 오히려 더 피곤하게 느껴질까요? AI와 함께 일하는 상황이 늘어나는 지금, AI와 협업하면서 발생하는 어려움을 해결해 나가는 최선의 워크플로우는 무엇일지 고민해 보았습니다.

왜 우리는 AI 결과물 앞에서 판단이 흐려지는가?

우리가 경험적으로 걱정하는 문제들에 대한 기존 연구들을 하나씩 살펴보겠습니다.

Microsoft Research와 CMU 연구진들이 진행한 연구에서, 우리는 왜 AI 결과물을 받아보면서 발생하는 현상들을 확인할 수 있었습니다.

Microsoft Research와 CMU 연구진은 319명의 지식노동자로부터 생성형 AI를 사용한 실제 업무 사례 936개를 수집했습니다. 연구 결과, AI에 대한 신뢰가 높을수록 비판적 사고를 덜 했다고 보고한 반면, 해당 과업을 스스로 수행할 수 있다는 자신감이 높을수록 더 많은 비판적 사고를 했다고 보고했습니다.

자신이 작업에 관한 자신감을 가지고 과업에 참여할수록 AI 결과를 더 적극적으로 검토할 가능성이 있다는 것입니다. 실무에 대입해서 생각해 봅니다. “AI가 대충 잘 뽑아주겠지”라고 생각하며 화면 설계를 시키면 결과물을 검토하기보다 수락하는 태도에 가까워지는 반면. 내가 작업에서 “이 플로우에서는 사용자가 이탈하는 지점이 있을 수 있다”는 가설을 가지고 요청했다면 똑같이 AI가 만들어준 결과물을 보더라도 더 깊게 비판적으로 들여다보게 된다는 것입니다.

우리의 문제는, 위험이 낮은 일상적 작업에서 점점 전자 쪽으로 기울게 된다는 것입니다. 매일 반복되는 작은 판단들에서 AI를 믿고 활용하다 보면, 검증을 건너뛰는 습관이 자연스럽게 쌓이게 되고, 정작 중요한 결정 앞에서 “이 결과물이 정말 맞나?”를 묻는 습관이 점점 사라지게 되겠죠. 그 점을 경계해야 합니다.

AI는 생성 부담을 줄이지만 평가 부담을 남긴다

우리는 직접 와이어프레임을 그리면 왜 이 요소를 여기에 놓았는지 알고 있습니다. 정보 구조를 생각하고, 시선 흐름을 고려하고, 우선순위를 정하는 과정이 내 안에서 일어났기 때문입니다. 반대로 AI가 완성된 레이아웃을 주면 나는 결과에서 출발해 그 의도를 역으로 추론해야 합니다. “왜 이 버튼이 여기 있지?”, “이 정보가 먼저 나와야 하는 이유는 뭐지?”를 처음부터 복원해야 합니다. 같은 결과물이어도 내가 가지고 있는 맥락의 양은 다를 수밖에 없습니다. 따라서, 우리가 작업물을 직접 만들면 맥락을 이해하기가 쉬운데, 완성된 걸 받으면 유독 더 검수하기 힘이 듭니다.

Microsoft Research는 “생성형 AI가 사람의 역할을 직접 만드는 사람에서 결과를 평가하는 사람으로 이동시킨다”라고 설명합니다.

이를 production-to-evaluation shift, 즉 생성에서 평가로의 이동이라고 부릅니다. AI를 활용한 작업이 늘어날 수록 기존 맥락에 맞는지, 빠진 조건은 없는지를 판단하는 일이 중요해진다는 것입니다.

문제는 직접 만드는 역할에서 평가하는 역할로 바뀌면서, 역설적으로 평가에 드는 인지 부하 또한 함께 늘어난다는 것입니다. AI의 생성 속도만큼 사람의 이해와 판단 속도가 빨라질 수는 없기 때문입니다. 또한, 비슷한 이유를 이미 1978년 Slamecka와 Graf가 발표한 연구에서 발견된 Generation effect에서도 찾을 수 있습니다. “~”라는 의미로, 이 연구에서는 참가자가 직접 생성한 단어는 같은 단어를 읽기만 했을 때보다 이후 기억 검사에서 더 잘 회상된다고 합니다. 나중에 떠올리기 쉬워서가 아니라, 만드는 순간 자체가 더 깊은 인지 처리를 일으키기 때문입니다.

결국, 우리가 직접 만들지 않는 AI의 결과물을 이해하고 판단하는 일에는 더 많은 인지적 부담이 늘어나게 되고, 이는 AI와 협업하는 지금의 시대에 맞이할 우리의 새로운 어려움으로 나타날 수 있습니다.

판단력을 유지하려면 생성 과정에 관여해야 한다

사람의 관여도에 따른 작업 리뷰 및 이해도 테스트 결과

더 깊게 들어가보면, 작업에 얼마나 관여했는지에 따라 사람의 인지 결과도 달라집니다. 개발 분야에서 이루어진 선행 연구에서 52명의 소프트웨어 개발자가 새로운 라이브러리를 학습하는 무작위 실험을 진행했습니다. 그 결과, AI 사용 집단과 비사용 집단의 과제 완료 시간은 비슷했습니다. 그러나, 후속으로 진행된 작업 이해도 평가에서 AI를 사용한 집단의 후속 이해도 점수는 평균 50%로, 직접 코딩한 집단의 67%보다 낮았습니다.

흥미로운 점은, AI 사용 집단 안에서도 결과는 사용 방식에 따라 크게 달랐다는 것입니다. AI에게 코드 생성을 전적으로 맡기거나 오류 해결을 반복적으로 위임한 참가자 유형은 이해도 평가에서 24~39%를 기록했습니다. 반면 코드를 생성한 뒤 작동 원리를 질문하거나, 코드와 함께 설명을 요청하거나, 개념만 AI에게 묻고 직접 구현한 참가자 유형은 65~86%를 기록했습니다.

따라서, 우리에게 중요한 것은 AI를 좋은 프롬프트로 얼마나 잘 사용했느냐보다, AI의 작업 과정에 내가 어떤 방식으로 관여했느냐? 가 될 수 있습니다. 결과만 받는 것과, 중간에 “왜 이렇게 했어?”, “다른 선택지와의 트레이드오프는 뭐야?”라고 묻는 것은 전혀 다른 방식으로 AI를 활용하는 방식이며, 작업의 이해도 또한 달라질 수 있다는 것입니다.

먼저 생각을 표현하면 AI는 답변자가 아니라 피드백 도구가 된다

그렇다면 실제로, AI에게 시키기 전에 내 생각을 먼저 꺼내놓으면 결과가 달라질까요? CHI 2025에서 발표된 실험이 이 질문을 직접 검증했습니다. 참가자 21명에게 투자 포트폴리오를 짜는 과제를 주고, 두 종류의 AI 보조 도구를 비교 사용하게 했습니다.

각각 다른 방식의 작업 방식을 가진 AI를 비교

1. RecommendAI : 버튼을 누르면 AI가 바로 추천 안을 제시한다.
2. ExtendAI : 사용자가 먼저 자기 논리를 글로 쓰면, AI가 그 위에 피드백을 얹어준다.

예를 들면, RecommendAI는 “AI야 이 화면 디자인해줘”이고, ExtendAI는 “나는 이 화면에서 이런 걸 중요하게 생각하는데, 이 방향으로 만들어주고 빠진 거 알려줘”라고 하는 식입니다.

결과에서 가장 눈에 띈 건 자신감과 만족도의 관계입니다. RecommendAI를 쓴 그룹은 결정 직후 자신감이 86%로 높았는데, 실제 결과를 본 뒤 만족도는 43%로 급락했습니다. AI가 해준 추천을 믿고 따라갔는데, 막상 결과를 보니 내 판단이 맞지 않았던 것입니다. ExtendAI 그룹은 자신감 67%, 만족도 67%로 거의 일치했습니다. 내 논리를 먼저 세운 쪽은 결과가 어떻든 자기 판단 수준을 정확히 인지하기 때문입니다. 또한, ExtendAI를 사용한 참가자들은 특히 지역적 포트폴리오 다각화 측면에서 더 나은 결과를 보였습니다. 연구진은 사용자가 자신의 계획을 먼저 세운 뒤 피드백을 받는 방식이 포트폴리오 전체의 약점을 더 잘 이해하는 데 도움이 된 것으로 해석했습니다.

실무에서 이 차이가 드러나는 순간이 있습니다. 디자인 리뷰에서 팀원이 “왜 이 레이아웃이에요?”라고 물었을 때, AI 추천을 그대로 쓴 사람은 “AI가 이렇게 뽑아줬는데 괜찮아 보여서요”밖에 할 말이 없습니다. 먼저 자기 논리를 세운 사람은 “첫 진입 시 핵심 가치를 3초 안에 전달하려면 이 구조가 맞다고 생각했고, AI 피드백에서 CTA 위치만 조정했어요”라고 말할 수 있습니다. 이 차이는 결과물의 퀄리티뿐 아니라, 협업에서의 신뢰에도 직결됩니다.

그래서 어떻게 일해야 할까? 생성-지연-재현 워크플로우

그래서, 우리는 AI와 어떻게 일하면 좋을까요? 제 생각에는, AI와 작업을 하는 과정에서 단순히 속도에 집중하기보다는 나의 작업 속도에 맞게, 작업은 AI가 하되 나의 판단 능력을 최적화하는데 집중해야 한다고 생각했습니다. 그래서 AI 활용 워크플로우를 아래와 같이 고민해 보았습니다.

판단 능력을 잃지 않는 AI와의 협업 워크플로우

Step 1. AI에게 일을 맡기기 전, 나의 의도를 먼저 적습니다

AI에게 “OO 해줘”를 보내기 전에, 내가 기대하는 결과를 2~3줄로 적습니다. 완벽하지 않아도 됩니다. 핵심은 시간이 아니라 내 머릿속에 의도의 흔적을 남기는 것입니다. 이 과정을 통해 나중에 AI에게 결과물을 받았을 때 “뭘 기준으로 볼 것인가”를 만듭니다.

‘온보딩’ 화면을 설계해 달라고 요청하기 전
→ 이 온보딩 플로우에서 가장 중요한 건 사용자가 ‘이 앱이 나한테 왜 필요한지’를 두 번째 화면에서 파악하는 것. 기능을 소개하기보다, 가치 제안을 먼저 진행해야 한다.

기능을 구상하고 설계해달라고 요청하기 전
→ 기능의 핵심 지표는 전환율이 아니라 재방문율이다. 한 번 쓰고 마는 기능은 의미가 없다. 사용자가 다시 찾아올 이유가 생기는 기능을 설계해야 한다.

Step 2. 기다리는 시간에 합격 기준을 씁니다

AI가 도는 동안 다른 프로젝트로 넘어가지 않습니다. 대신, 지금 돌아가고 있는 작업의 합격/불합격 기준을 적아봅니다. EvalGen 연구에서 실제로, “기다려야 하는 시간에 채점 기준을 세우게 하자”는 작업 설계가 효과가 있었다고 합니다.

화면 설계를 시키는 동안 판단해보는 합격 기준
→ 합격 : 핵심 CTA가 스크롤 없이 보이고, 사용자가 다음 행동을 고민하지 않아도 된다.
→ 불합격 : 요소 간 위계가 불분명, 빈 공간이 의도 없이 존재, “다양한”, “편리한” 같은 모호한 카피.

기능을 기획하는 동안 판단해보는 합격 기준
→ 합격 : 유저 시나리오 3개 이상을 충분히 커버하고 예외 상황(결제 실패, 재진입 등)이 플로우에 반영되어있어야 한다.
→ 불합격 : 해피 패스만 기술해 놓는다.

물론 기준은 나중에 바뀌어도 괜찮습니다. 기준은 작업 전에 한 번에 완성되기 어렵기 때문입니다. UC Berkeley 연구진이 UIST 2024에서 발표한 EvalGen 연구에서는 criteria drift라는 현상으로 설명합니다. 결과물을 채점하려면 기준이 필요하지만, 실제 결과물을 채점하다 보면 기준 자체가 수정된다는 것입니다.

실제로 이런 경험이 있을 것입니다. “카드 UI는 모서리 라운딩 8px로 통일한다”는 기준을 세우고 작업합니다. 그리고 실제로 다양한 화면을 만들다 보니, “콘텐츠 밀도가 높은 카드는 4px가 맞다”로 기준을 바꾸기도 합니다. 또는 ”온보딩은 3단계 이내”라고 정했다가, 실제 사용자 플로우를 그려보니 “단계 수보다 각 단계의 인지 부하가 더 중요하다”로 생각이 바뀌기도 합니다.

결국 내가 기준을 세워 AI에게 전달하더라도, 어차피 그 기준을 한 번에 완벽하게 세울 수는 없습니다. 대신, 기준이 바뀔 때마다 왜 바뀌었는지를 기록해 볼 수는 있겠죠. 경험치가 쌓일수록 그 일이 익숙해지듯, 그 기록이 쌓인다면 다음 판단이 더 빨라질 수도 있을 것 같습니다.

Step 3. 결과물의 핵심적인 부분은 직접 재현해 봅니다

전체를 다시 작업할 필요는 없습니다. 작업에서 판단이 가장 중요한 부분 하나만 골라서, 나의 버전을 짧게라도 만들어봅니다.

예를 들면, 아래와 같이 해보는 겁니다.

AI가 정리해 준 온보딩 플로우 전체 화면 구성 중, 사용자가 가장 먼저 이탈할 것 같은 구간을 골라 핵심 시나리오를 나의 생각으로 다시 써본다.

“이 화면에서 사용자가 뭘 보고, 어떤 판단을 내려야 하는지”를 직접 문장으로 옮겨봅니다. 내 머릿속에 “이 부분이 왜 이래야 하는지”의 맥락을 심어 보는 것입니다. 중요한 것은, 적어도 작업의 핵심 과정에 관여하여 나의 작업에 대한 소화를 제대로 시켜보아야 한다는 것입니다.

Step 4. 기준의 변화를 로그로 쌓는다

작업 중에 기준이 바뀔 때마다 AI에게 추가로 요청하게 됩니다. 최종적으로 원하는 결과물을 얻기 위해 기준을 수정하며 추가적인 요청을 합니다. 이 대화는 프로젝트가 끝나고 정리하는 게 아니라, 대화를 종료한 시점에 대화의 내용을 요약하여 정리해 봅니다.

v1: 온보딩은 3단계 이내로 끝낸다.
v2: 단계 수보다 각 단계에서 느끼는 인지 부하가 더 중요하다. (사용자 테스트에서 3단계인데도 이탈이 나오면서 수정)
v3: ”가치 제안이 두 번째 화면까지 전달되는지가 기준. 단계가 몇 개든 상관없다. (Step 1에서 세운 의도로 다시 연결)

이 부분은 AI가 정리해 주고 읽어볼 수도 있습니다. 이 대화 로그의 목적은 두 가지입니다. 하나는 다음에 비슷한 작업을 시킬 때 프롬프트에 넣어서 시행착오를 줄이는 것, 다른 하나는 내 판단이 어떻게 진화하는지 나 스스로 추적할 수 있게 되는 것. AI와 함께 한 작업이 오롯이 내 역량이 됩니다.

Step 5. 병렬은 “일” 단위가 아니라 “콘텍스트” 단위로 제한한다

같은 프로젝트 안에서 서로 이어지는 작업들(e.g. 온보딩 플로우를 설계하고 생길 수 있는 예외 상황(결제 실패, 재진입 등)을 정리하고, 사용자가 이탈하는 지점을 리서치해서 다시 플로우에 반영하는 일 등)은 동시에 진행해도 전환 비용이 적습니다. 어차피 같은 사용자, 같은 맥락을 계속 들여다보고 있기 때문입니다.

그러나 이번 주 온보딩 기획을 하면서 동시에 전혀 다른 프로젝트의 유저 시나리오까지 검토한다면, 두 개만으로도 판단력이 무너질 수 있다는 점을 기억해야 합니다. 이 상태에서 다른 맥락으로 넘어가면, 나중에 결과가 돌아왔을 때 “내가 뭘 기대했더라”를 머릿속에 다시 떠올려야 하죠. 바로 이 복귀 비용이 생각보다 큽니다.

Sophie Leroy의 연구가 밝힌 attention residue의 개념이 그러한 현상을 증명합니다∙ 이전 작업이 끝나지 않은 채 다른 작업으로 넘어가면, 주의력의 일부가 이전 작업에 남아서 오히려 다음 작업 성과가 떨어진다고 합니다. 주의를 복귀하는 데 드는 비용은 탭을 전환하는 물리적 행위가 아니라, “내가 이 작업에서 뭘 기대했는지”를 재구성하는 데서 발생하는 것입니다.

따라서 여러 작업 각각에 내가 어떤 의도를 가졌는지를 전부 다시 떠올리는 비용만으로도 판단의 질이 떨어질 수도 있습니다. 그래서 Step 1에서 나의 의도와 기대하는 결과를 메모해 두는 건 바로 복귀 비용을 줄이는 장치가 되기도 합니다.

마치며

“작업을 판단하고 기준을 만드는 건 AI의 능력이 아니라 나의 전문성이다”

지금까지 인용한 연구들을 다시 보면, 하나의 패턴이 있습니다. AI 활용에서 중요한 것은 기술적 능력이 아닌 본업에 대한 사람의 판단력과 역량이 변수라는 것입니다. MS/CMU 연구에서 비판적 사고를 더 많이 한 사람은 AI를 잘 다루는 사람이 아니라, “자기 분야에 대한 자신감이 높은 사람”이었습니다. ExtendAI 실험에서 더 나은 결과를 낸 사람도 AI 피드백이 좋아서가 아니라, “먼저 자기 논리를 세운 사람”이었습니다. 이해도가 상대적으로 높았던 개발자도 프롬프트를 잘 짜서가 아니라, AI의 작업물에 “왜?”를 물을 줄 아는 사람”이었습니다.

이 역량은 프롬프트 잘 쓰는 법을 공부해서 생기는 게 아니라, UX 업무를 해오던 경험에서 나오는 것입니다. 사용자가 어디서 막히는지를 관찰한 경험, 정보 구조를 잡을 때 무엇을 먼저 보여줘야 하는지에 대한 감각, “이 플로우는 왜 이래야 하는가”를 설명할 수 있는 논리, 이런 것들이 AI 결과물 앞에서 “이건 괜찮고 이건 아니다”를 가르는 기준을 만듭니다. 기준을 만들고, 바꾸고, 왜 바꿨는지를 판단하는 건 AI가 할 수 없습니다. 그건 사용자를 관찰하고, 맥락을 이해하고, “이건 아닌데”라고 느낄 수 있는 사람의 일입니다.

앞선 연구가 보여줬듯, 물론 판단 기준이 순수하게 내 머릿속에서만 나오지는 않습니다. AI 출력물을 보고 나서야 “아, 이건 안 되는구나”를 깨닫고 기준이 생기기도 합니다. 이렇듯, 판단 능력은 단순히 빈 종이에서 완성되는 게 아니라 AI와 부딪히면서 다듬어지기도 합니다.

이 워크플로우는 느릴 수 있습니다. 대신 결과물에 대한 확신과, 다음 판단의 출발점이 되는 노하우를 남깁니다. 화면 세 개를 동시에 뽑아내기보다, 그중 하나를 붙잡고 “왜”에 끝까지 답할 수 있는 능력. 이게 쌓이면 리뷰에서 막히는 시간과 재작업이 줄고, 비슷한 판단은 다음 프로젝트에서 더 빨라집니다. 빠르게 많이 만들었지만 뭐가 좋고 뭐가 나쁜지 모르는 상태는 진정한 의미의 생산성이 아니라고 생각합니다.

AI를 쓰더라도 “왜 이렇게 만들었는지”를 설명할 수 있는 능력이 복리로 쌓이는 것이 AI 시대의 진정한 의미의 생산성이라고 생각합니다.

<원문>

AI와 협업하는 최선의 워크플로우 찾기

<참고 자료>

1. Lee et al. (2025). “The Impact of Generative AI on Critical Thinking.” Microsoft Research & CMU. CHI 2025.

2. Reicherts, Zhang et al. (2025). “AI, Help Me Think—but for Myself.” Microsoft Research & UCL. CHI 2025.

3. Shankar et al. (2024). “Who Validates the Validators?” UC Berkeley. UIST 2024.*

4. Slamecka & Graf (1978). “The Generation Effect: Delineation of a Phenomenon.” Journal of Experimental Psychology.

5. Simkute et al. (2024). “Ironies of Generative AI.” Microsoft Research.

6. Leroy (2009). “Why Is It So Hard To Do My Work?” Organizational Behavior and Human Decision Processes.

7. O’Reilly (2026). “Comprehension Debt: The Hidden Cost of AI-Generated Code.

]]>

GPT-6 아스트라(Astra) 등장: 첫 AGI?

<출처: 오픈AI>

GPT-6 아스트라(Astra)가 나왔습니다.

9월 3일, 오픈AI 스스로 “세계에서 가장 지능적이고 가장 정렬된 모델”이라는 선언과 함께 공개했습니다. 클로드 페이블 5.1이 나온 지 이틀 만에, 세계 최고 모델이 나란히 갱신된 셈이죠.

컴퓨터 조작, 브라우징, 소프트웨어 엔지니어링, 사이버보안, 과학, 전문 업무. 이 전부에서 최고 수준(state-of-the-art)입니다. 벤치마크 점수만으로는 눈을 의심케 할 정도인 이 모델. 자세히 뜯어보겠습니다.

핵심 관전 포인트

벤치마크 점수가 장난이 아닙니다. 특히 세 개 벤치마크(FrontierMath 98%·ARC-AGI-3 99.9%·ExploitBench 100%)는 진짜 높은데요. 어떤 조건의 점수인지 보겠습니다.
오픈AI 사장이 직접 기자 브리핑에서 모델을 발표하며 “AGI 시대”라는 말을 했습니다. 이를 뒷받침하는 ‘가장 정렬된 모델’이라는 표현은 무슨 뜻일까요?
공개 당일 실제로 쓸 수 있는 곳은 보안 프로그램 소속 일부 조직뿐입니다. 사이버보안 ‘중대’ 등급으로 인한 단계적 개방이며, 구독제와 API에는 “며칠 내” 나온다고 합니다.
업데이트: 한국 시간 기준 9월 5일 부로, API와 Codex, GPT work 등을 통해 접근할 수 있습니다. 우선은 호평이 쏟아지고 있네요!

GPT-6 아스트라 스펙 살펴보기

공식 발표문 기준 주요 스펙을 정리하면 이렇습니다.

GPT-6 아스트라 주요 스펙 <출처: 오픈AI 발표문·Artificial Analysis>

점수는 전부 “모든 노력 설정 중 최댓값(maximum at any effort)” 기준이고요. 가격은 입력 100만 토큰당 10달러(한화 약 1만 3,600원), 출력 50달러(약 6만 8,000원)입니다. 직전 모델 GPT-5.6 Sol의 2.5배입니다. 2배 비싸지만, 최대 2배 속도를 내는 Fast 모드도 함께 나왔습니다.

단가가 오른 대신 효율도 좋아졌습니다. 같은 작업에 드는 토큰이 직전 모델의 3분의 1 수준이고, 환각률은 92%에서 51%로 내려왔습니다.

아스트라가 만든 카트 레이싱 게임 화면 <출처: 오픈AI(Pietro Schirano)>

GPT-6 아스트라 Vs. 페이블 5.1

그런데 이 가격과 효율 구성, 어디서 본 숫자입니다. 이틀 전 나온 페이블 5.1과 자릿수까지 같거든요. 그래서 비교표를 준비했습니다.

GPT-6 아스트라 vs. 페이블 5.1 <출처: 오픈AI·앤트로픽 발표문, Artificial Analysis>

종합 지능 지수: 오픈AI가 발표에 실은 Artificial Analysis 지수 기준 아스트라 61.2, 페이블 5.1 65.7. AA 자체 발표로는 페이블 5.1이 66으로 192개 모델 중 1위, 아스트라는 61입니다.
Humanity’s Last Exam: 아스트라 57.2%, 페이블 5.1은 60.9%(도구 사용 시 65.0%, 앤트로픽 발표문 기준).
단가: 입력 10달러·출력 50달러로 동일합니다. 페이블 쪽 무기는 75% 내린 캐시 읽기(0.25달러)죠.
강점 분포: 아스트라는 컴퓨터 조작, 보안, 과학/수학, 페이블 5.1은 에이전트 지식 노동, 글쓰기, 비용 효율에 자기 어필이 몰려 있습니다.

오픈AI 발표문의 Academic 벤치마크 표(페이블 5.1 열 포함) <출처: 오픈AI>

일단 발표문 기준으로 한 비교는 이 정도고요, 아스트라가 시중에 풀린 다음 실사용 후기들을 봐야 비교 구조가 잡힐 거라 생각합니다. 일단 페이블 5.1 실사용 후기는 정말 좋지만, 토큰이 미친 듯이 빨리 사라진다, 정도입니다.

관전 포인트 3가지

1) 아스트라의 말도 안 되는 벤치마크 점수들

가장 놀라운 건 벤치마크 점수들입니다. 특히 이 세 가지 벤치마크는 거의 천장을 뚫어버렸습니다. 마치 사람이 자기 이해 수준에 맞춰 만든 평가 자체를 비웃듯이 말이죠.

FrontierMath Tier 4

Epoch AI가 만든 벤치마크입니다. 수학 교수와 연구원들이 각자 몇 주짜리 연구 프로젝트로 문제 하나씩을 만든 50문항 세트입니다. 기존 Tier 3 난도를 크게 넘기려는 목적으로 2025년 6월 완성됐고요. 아스트라의 점수는 98%, 연구 수준 수학 문제를 웬만하면 푼다는 뜻입니다. 실제 오픈AI도 “수학의 오래된 미해결 문제 해결에 이미 기여했다”고 부연합니다.

FrontierMath Tier 4 결과 <출처: 오픈AI 발표문 Academic 표 발췌>

ARC-AGI-3

ARC Prize가 운영하는 상호작용형 추상 추론 벤치마크입니다. 게임처럼 처음 보는 규칙을 주고 얼마나 빨리 학습하는지를 잽니다. 아스트라는 여기서 99.9%를 풀어버립니다. 한편 ARC Prize에 따르면 점수가 두 개입니다. 표준 조건 62.7%, 오픈AI 조건 99.9%. 차이는 상태 관리 방식인데요. 표준 조건은 화면에 보이는 정보만으로 푸는 것이고요, 오픈AI 조건에서는 숨은 추론 상태를 보존/압축하며 풀었다고 합니다. 이 조건으로는 전체 레벨의 96%를 사람보다 적은 행동으로 풀었다고 하네요.

ARC-AGI-3 리더보드: 표준 조건(GPT-6 Astra)과 오픈AI 어댑터 조건(Provider Adapter)의 점수 <출처: ARC Prize>

ExploitBench

소프트웨어 취약점을 찾아 실제 공격 코드(익스플로잇)까지 만들어내는 능력을 재는 벤치마크입니다. 아스트라의 점수는 무려 100%. 보안 업무에서 최상급 능력이라는 뜻입니다. 실제로 평가 과정에서 아직 공개되지 않은 제로데이 취약점 2건을 직접 찾아냈다고 하고요.

ExploitBench 결과 <출처: 오픈AI 발표문 Cybersecurity 표 발췌>

2) AGI?

이런 높은 점수에 자극을 받은 듯, 오픈AI 내부에서는 “AGI”라는 언급이 나왔습니다.

처음 이 말이 나온 곳은 기자 브리핑이라고 합니다. Axios 취재에 따르면 오픈AI 사장 그렉 브록먼(Greg Brockman)은 브리핑에서 “이 모델일 수도 있다”고 말했습니다. 물론 그의 개인 판단이라는 전제를 달고서요. 그리고 브리핑은 “Welcome to the AGI era”, AGI 시대에 온 걸 환영한다는 말로 마무리했습니다. 브록먼은 그동안 AGI를 “미션 개념 혹은 정신적 개념”이라고 해왔는데, 그가 생각하는 수준에는 도달했다는 말로 읽힙니다.

이 표현은 오픈AI가 함께 공개한 시스템 카드의 내용과 같이 보면 좋습니다. 카드에는 모델을 감시할 수 있는 가능성이 직전 모델보다 떨어졌다고 적혀 있습니다. 수석과학자 야쿠브 파호츠키(Jakub Pachocki)도 브리핑에서 모델이 세지면서 감시가 더 어려워지고 있다고 인정했습니다. 결국 이제 어느 정도 AI가 사람의 손을 떠났다는 선언처럼 들리기도 합니다.

KiCad에서 PCB 레이아웃을 수행하는 GPT-6 아스트라 시연 영상 <출처: 오픈AI>

3) 그래서 언제부터 쓸 수 있나: 업데이트! 9월 5일부터 통제가 풀렸어요!

문제는 공개 당일 기준으로 아스트라에 접근할 수 있는 곳은 Daybreak라는 보안 프로그램 소속 일부 조직뿐이라는 겁니다. 지금까지 잔뜩 기대한 분들에게는 아쉬운 소식이죠. Plus·Pro·Business·Enterprise 플랜과 API, AWS는 “향후 며칠 내(coming days)”로 안내됐습니다. Enterprise는 열려도 기본값이 꺼짐이라 관리자가 켜야 한다고 합니다.

이런 단계적 개방의 이유는 ‘보안’입니다. 아스트라는 오픈AI의 위험 관리 체계에서 사이버보안 ‘중대(Critical)’ 임계에 도달한 첫 모델입니다. 오픈AI는 8월 말에 이미 “최고 수준 사이버 능력에는 접근을 제한하겠다”는 방침을 예고해 뒀습니다. 샘 올트먼도 “안전과 정렬 기준을 맞추느라 시간이 더 걸렸다”라고 말했죠.

그럼 언제 풀릴까요. 여기부터는 추정입니다.

공식 문구가 “며칠 내”인 만큼 일반 유료 플랜과 API는 1~2주 안 개방이 합리적인 추정입니다.
다만 ‘중대’ 등급 첫 사례인 데다 접근 제한 방침을 미리 예고한 만큼, 열린 뒤에도 사이버 관련 상위 능력은 별도 게이트로 계속 제한될 가능성이 있습니다.

이를 보상이라도 하듯, 오픈AI의 티보(Tibo)는 유료 ChatGPT 플랜에서 아스트라를 못 쓰는 날마다 사용량 리셋권을 한 장씩 준다고 약속했습니다. 잘 모아두었다가 아스트라가 나오는 날 쏟아내면 좋겠네요.

<출처: X(@thsottiaux)>

업데이트: 한국 시간 기준 9월 5일 부로, API와 Codex, GPT work 등을 통해 접근할 수 있습니다. 우선은 호평이 쏟아지고 있네요!

마치며

지금까지 본 대로, 오픈AI의 말이 맞다면 정말 역대급 모델의 등장입니다. 다만 뚜껑은 모델이 실제로 열려야 열어볼 수 있겠고요.

그래도 발표문에 함께 나온 결과물들이나 영상만 봐도 기대가 커지는 건 어쩔 수 없습니다. 2026년 9월은 기억할 만한 달이 될지도 모르겠네요.

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

]]>

[신청 종료] / 나만 쓰기 아까운 ‘로컬앱’을 자랑해 주세요

이번 로컬앱 자랑대회에는 전체 출품작 51건으로 신청 마감했습니다.
곧, 최종 선정작과 함께 로컬앱 자랑대회 온/오프라인 참가 신청이 열릴 예정이니 많이 기대해 주세요!

이런 분들, 요즘은 회사마다 한 명씩 있습니다.

마케터 A씨: 광고 소재를 플랫폼별 규격으로 자르는 게 지겨워서 리사이즈 스크립트를 만들었습니다. 이제 폴더에 원본을 넣으면 열두 장이 알아서 나옵니다. 팀에서는 “A님 그거” 라고 부릅니다.

회계팀 B씨: 매달 영수증 수백 장을 눈으로 대조하다가, 스캔 파일을 읽어 자동으로 맞춰 보는 도구를 만들었습니다. 이번 달에는 본인도 놓쳤을 오류를 도구가 먼저 잡았습니다.

영상 PD C씨: 자막 싱크 맞추는 일이 손에 붙지 않아서, 대사 파일과 타임코드를 붙여 주는 웹앱을 짰습니다. 코딩은 처음이었고, 전부 AI에게 시켰습니다.

셋의 공통점이 있습니다. 아무도 이걸 회사 밖에서 자랑한 적이 없습니다. 배포한 것도 아니고, 코드를 공개할 수도 없고, 무엇보다 “이 정도 가지고 뭘” 싶으니까요. 그래서 팀원 다섯 명만 알고 끝납니다.

아깝지 않으세요? 저희는 아깝습니다.

그래서 그런 로컬앱을 모아 자랑대회를 열기로 했습니다.

➡️ 로컬앱 자랑대회 출전 접수하기/ 종료

이번 로컬앱 자랑대회에는 전체 출품작 51건으로 신청 마감했습니다.
곧, 최종 선정작과 함께 로컬앱 자랑대회 온/오프라인 참가 신청이 열릴 예정이니 많이 기대해 주세요!

이런 출전작 환영해요

만들어 놓고 결국 나만 쓰는 사내용 도구
쓰다 멈췄지만 아직 안 지운 자동화
“그거 엑셀로 되잖아요” 소리 들어본 것
회사 서버 아니고 내 노트북에서만 도는 것
코드는 AI가 다 짰고 나는 시키기만 한 것
팀에서 세 명만 쓰는데 그 세 명은 없으면 안 되는 워크플로
솔직히 만드는 데 더 오래 걸린 것
아직 진행 중이라 자랑하기 민망한 것

전부 출전작입니다. 완성도, 설계의 아름다움, 코드 품질은 보지 않습니다. 문제를 새롭게 바라보고 AI와 함께 풀어낸 과정이 있으면 그걸로 충분합니다.

경력·직군·회사 규모도 보지 않습니다. 개발자가 아니어도 됩니다.

출전 조건 3가지를 바꿨습니다

첫 공고를 내고 일주일이 지났습니다. 접수를 보면서 저희끼리 한 이야기가 있습니다. “이거, 우리가 문턱을 높게 잡은 거 아닌가?” 그래서 세 가지를 바꿉니다.

첫째, 대리 등록 제도를 추가했습니다.

부끄러운 팀원 대신 자랑하고 싶은 분이 일단 프로그램이 뭔지 적어서 신청해 주세요. 설득은 요즘IT와 같이 해요. 우리 팀원이 만든 도구가 얼마나 뛰어난지는 옆에서 지켜본 사람이 제일 잘 아니까요.

둘째, 수치 성과는 필수가 아닙니다.

처음에는 “성과를 숫자 하나로 적어 주세요”라고 했습니다. 그런데 업무용 도구를 만드는 사람은 만들어 쓰기 바쁩니다. 숫자가 있으면 적어 주시고, 없으면 없는 대로 내셔도 됩니다. “이거 안 만들었으면 지금도 손으로 하고 있을 겁니다” 한 줄이면 충분합니다.

셋째, 출전자에게 현장 자리 일부를 배정합니다.

10월 6일 데모 데이 현장 좌석을 출전 접수하신 분들에게 따로 엽니다. 발표팀으로 편성되지 않아도 신청하실 수 있고, 신청이 자리보다 많으면 접수하신 분들 안에서 추첨합니다. 무대는 4팀이지만, 자리는 응모하신 분들끼리 나눕니다.

대회 안내

접수 마감: 9월 13일(일) 자정
본선 규모: 4팀 (부문별 1팀 + 노션 특별상 1팀)
발표 길이: 20분 (발표 15분 + 문답 5분)
데모 데이: 10월 6일(화) 저녁 7시
장소: 위워크 선릉 3호점 13층 세미나실 (노션 제공) + 온라인 동시 송출
참가 단위: 개인 또는 팀. 본선 현장 참여는 팀당 1~3명

신청 방법

아래 신청 폼 작성. 5분이면 끝납니다
접수 마감: 9월 13일(일) 자정
진행 절차: 접수 → 서류 검토 → 개별 온라인 인터뷰(9월 중, 팀당 15분) → 본선 편성
본선 4팀 발표: 9월 17일(목) 개별 연락 및 공지
현장 자리 신청은 접수하신 분들께 별도 메일로 안내드립니다

출전팀에게 드리는 것

본선 무대: 데모 데이 20분 발표. 현장과 온라인 동시 송출
기록 자산: 발표 내용이 요즘IT 매거진 아티클과 발표 영상으로 제작되어, 이후 공유·포트폴리오에 활용 가능
공식 소개: 요즘IT 웹사이트·뉴스레터·SNS에서 출전팀과 작품 소개
현장 네트워킹: 노션이 제공하는 공간에서, 지금 진짜 일 잘하는 분들과 만날 기회
디지털 배지: 빌더나잇 발표자 배지(PNG/SVG) 제공
다음 기회 연결: 후속 인터뷰나 다음 시즌 우선 참여 기회

➡️ 로컬앱 자랑대회 출전 접수하기/ 종료

이번 로컬앱 자랑대회에는 전체 출품작 51건으로 신청 마감했습니다.
곧, 최종 선정작과 함께 로컬앱 자랑대회 온/오프라인 참가 신청이 열릴 예정이니 많이 기대해 주세요!

공간 파트너, 노션

이번 대회는 노션(Notion)이 공간 파트너로 함께합니다. 데모 데이 장소와 현장 F&B를 노션이 제공합니다.

한 가지 미리 밝혀 둡니다. 본선 4팀 중 1팀은 노션이 직접 고르는 노션 특별상입니다. 워크플로에 노션이 들어간 응모작이 후보입니다. 나머지 3팀은 요즘IT가 부문별로 편성하며, 이 3팀의 편성에는 어떤 AI 도구를 썼는지가 전혀 반영되지 않습니다. 그리고 어느 쪽이든 순위는 매기지 않습니다.

로컬앱 자랑대회는?

깔끔한 성공담을 기다리는 자리가 아닙니다. 정말로 막혔던 구간, 몇 번이고 다시 만든 이야기, 팀에서 세 명만 쓰는 도구도 그대로 좋습니다. 내 컴퓨터에서만 돌아도 출전 자격은 충분합니다.

앞의 A씨, B씨, C씨는 있을 법한 이야기로 지어낸 인물인데요. 읽다가 누군가 떠올랐다면, 그게 본인이든 옆자리 동료든, 이 글을 그분께 보내 주세요. 그럼 부담 갖지 마시고 편하게 자랑해 주세요!

출전 TIP!

이 글을 ‘스크랩’해두시면 마이페이지에서 바로 확인할 수 있어요. 지금 당장 자랑할 게 떠오르지 않아도, 이번 주에 뭔가 하나 만들어 쓰다 보면 생각날 겁니다. 저장해두셨다가 정리되면 접수하세요! (로그인하면 스크랩 가능합니다)

➡️ 로컬앱 자랑대회 출전 접수하기/ 종료

이번 로컬앱 자랑대회에는 전체 출품작 51건으로 신청 마감했습니다.
곧, 최종 선정작과 함께 로컬앱 자랑대회 온/오프라인 참가 신청이 열릴 예정이니 많이 기대해 주세요!

]]>

개발자가 알려주는 클로드 코드 폴더 세팅하기

클로드 코드를 며칠 써 보면 자연스럽게 설정 파일을 만들게 됩니다. 프로젝트 규칙을 적어 두는 문서나 반복하는 작업을 정리한 스킬, 외부 도구를 연결하는 설정 같은 것들입니다. 그런데 다루는 프로젝트가 두 개, 세 개로 늘어나는 순간 한 번 고민하게 됩니다. 이 설정들을 전역에 한 번만 만들어 둘까요, 아니면 프로젝트 폴더마다 따로 둘까요?

폴더별로 역할을 쪼개 두지 않았다면 전역 설정을 쓰게 될 확률이 높습니다. 작업 폴더를 따로 지정하지 않는 데스크톱 앱으로 쓰고 있다면 더 그렇고요. 하지만 여덟 개 프로젝트를 다섯 달 굴려 본 지금은 규칙도, 스킬도, 외부 도구 연결도 전부 폴더별로 쪼개 두고 사용하고 있습니다.

이번 글에서는 제가 클로드 코드를 폴더별로 쪼개서 어떻게 잘 쓰고 있는지를 풀어 보려고 합니다. 어떤 구조로 나눠 뒀는지, 무엇을 어디에 두기로 했는지, 그리고 나눠 쓰면서 새로 생긴 불편은 어떻게 해결을 했는지 순서대로 적어보았습니다.

미리 요점만 콕 집어보면?

설정들을 전역에 몰아 두면 필요 없는 외부 도구와 규칙까지 따라오니, 지금은 폴더마다 그 업무에 필요한 것만 넣어 둡니다.
스킬 문서는 처음부터 완성하지 않고 사용하다가 필요한 스킬이 생기면 한 줄씩 늘려 가며, 공용으로 묶지 않고 폴더마다 따로 둡니다.
폴더별로 나누기로 했다면 실행 위치를 맞추는 방법도 함께 마련하고, 확인 절차는 그 폴더에서 일어날 사고를 되돌릴 수 있는지를 보고 정합니다.

설정을 폴더 단위로 쪼개기

먼저 제가 어떤 구조로 두고 있는지, 쪼개서 쓰기로 한 계기가 무엇이었는지, 그리고 나눈 뒤에 새로 생긴 불편사항은 어떻게 해결했는지를 차례로 살펴봅시다.

1) 저장소는 하나, 설정은 여덟 개

리포지토리는 하나입니다. 그 안에 매출, 이벤트 기획, 핸드북 제작, 유튜브 분석 등 여러 가지 업무에 필요한 폴더가 순서대로 나열되어 있습니다. 각 폴더는 자기 몫의 `.claude` 디렉토리를 가지고 있고, 여기에 그 업무에서만 쓰는 스킬 문서와 권한 설정이 들어갑니다. 외부 도구를 붙일 폴더에는 `.mcp.json` 파일을 하나 더 추가해 두었습니다.

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

리포지토리를 여러 개로 쪼개지 않은 이유는 단순합니다. 제가 하는 일은 크게 보면 하나인데, 그 일을 굴리는 데 필요한 작업이 여러 개로 갈라져 있을 뿐이기 때문입니다. 그래서 커밋 이력과 백업은 한곳에서 보고 싶었습니다. 나누고 싶었던 것은 저장소가 아니라 에이전트가 한 번에 보는 범위였습니다.

2) 전역에 몰아 두었을 때 생기는 일

처음에는 자주 쓰는 것을 전역에 모아 뒀습니다. 어느 폴더에서 실행하든 따라오니 그게 편할 줄 알았지만, 원고만 쓰는 폴더에서 클로드 코드를 켰는데 브라우저 창이 같이 뜨더라고요. 웹 페이지를 확인하려고 붙여 둔 도구였는데요, 글을 쓰는 폴더에서는 쓸 일이 없는데도 불구하고 매번 함께 실행이 된 것입니다. 그만큼 켜지는 데 시간이 걸리고 메모리도 잡아먹습니다. 규칙도 마찬가지였습니다. 브라우저 작업에서 사고가 나서 적어 둔 금지 규칙이, 매출 데이터를 정리하는 대화에까지 그대로 따라붙었습니다.

그래서 지금은 폴더마다 그 업무에 필요한 것만 넣어 둡니다. 판매 관련 폴더에는 매출 데이터를 조회할 MCP가 연결되어 있고, 웹 페이지를 만드는 폴더에는 브라우저 도구가 붙어 있습니다. 글만 쓰는 폴더에는 아무것도 붙이지 않았습니다. 파일을 읽고 쓰는 것이 전부라 기본 기능만으로 충분하거든요.

3) 폴더를 나누면 따라오는 숙제

폴더별로 나눠 두면 대신 매번 올바른 위치에서 실행해야 합니다. 한 칸 위에서 실행하면 그 폴더의 스킬도, 붙여 둔 외부 도구도 읽히지 않습니다. 여기서 저는 한참 헤맨 적이 있었는데요. 분명 만들어 둔 스킬을 못 찾길래 문서가 잘못됐나 싶어 한동안 들여다봤는데, 실행 위치가 한 칸 위였던 적도 있죠.

나눠 놓고 엉뚱한 위치에서 실행하면 나누지 않은 것보다 오히려 헷갈립니다. 그래서 폴더를 나누기로 했다면 실행 위치를 맞추는 방법도 함께 마련해 둬야 합니다. 저는 편집기 쪽에서 해결했는데, 그 방법은 마지막에 따로 정리했습니다.

무엇을 어디에 둘까

폴더를 나누고 나면 다음 질문이 따라옵니다. 이 작업 방식을 문서로 적어 둘 것인가, 아니면 그냥 매번 말할 것인가. 여기서 쓰는 것이 스킬 문서입니다. 관련된 요청이 들어왔을 때 클로드 코드가 읽고 그대로 따르는 문서인데, 저는 이것도 폴더마다 따로 둡니다. 스킬을 만들고 관리하면서 쓰는 기준 세 가지를 정리하겠습니다.

1) 한 줄씩 늘어나는 스킬 문서

스킬 문서에 무엇을 적을지는 폴더마다 다릅니다. 그 폴더가 무슨 일을 하는 곳인지에 따라 정해지기 때문입니다.

제 요즘IT 폴더는 기고할 주제를 고르는 일을 맡고 있습니다. 그래서 스킬 문서에는 이렇게 적어 뒀습니다. 내가 썼던 주제들을 기록해라, 그리고 새 주제를 추천할 때는 이미 쓴 것과 겹치지 않게 해라. 이 규칙도 처음부터 있었던 건 아닙니다. 예전에 다뤘던 주제를 그대로 다시 추천받고 나서야 적어 넣었습니다.

스킬 문서도 한 번에 길게 적지 않습니다. 폴더별로 필요할 때마다 그때그때 불렛 포인트로 한 줄씩 추가해 둡니다. 앞서 말한 요즘IT 폴더라면 이런 식입니다.

내가 지금까지 작성한 글의 주제들을 파일로 기록해
기록되어 있는 주제들과 겹치지 않도록 다른 주제를 추천해줘

처음부터 완성해 두려고 하면 정작 쓸 일 없는 문장만 쌓이기 때문에, 사용을 하다가 필요한 스킬이 생긴다면 한 줄씩 늘려 가는 편이 훨씬 효율적이였습니다.

2) A라고 하면 B가 나오게 하고 싶을 때

이 폴더에서 클로드 코드를 실행했을 때, A라는 명령을 하면 B라는 행동이 바로 실행되게 했으면 좋겠다는 규칙이 생기면 그때 스킬로 저장합니다. 예를 들어 원고를 저장할 위치와 파일명 규칙이 정해져 있다면, 그걸 매번 말하는 대신 스킬 문서에 적어 두는 식입니다. 한 번 적어 두면 다음부터는 명령 한 줄로 같은 결과가 나옵니다.

지금 폴더별 스킬 수를 세어 보면 편차가 굉장히 큰 편인데요, 영상 작업 폴더에는 아홉 개가 쌓였고, 어떤 폴더에는 하나뿐입니다. 손이 자주 가는 업무일수록 정해 둘 규칙이 많아지기 때문인데, 이 숫자만 봐도 제가 어느 일에 시간을 많이 쓰는지가 드러납니다.

3) 공용 스킬을 만들지 않는 이유

스킬을 공용으로 하나 만들어 여러 폴더에서 불러 쓰는 방식도 생각해 봤지만, 지금은 폴더마다 그 작업에 맞는 스킬을 따로 두고 있습니다. 같은 이름의 작업이라도 폴더가 다르면 요구하는 것이 달랐기 때문입니다.

매출 폴더의 스킬에는 어떤 기준으로 순위를 뽑고 어떤 형태로 정리할지가 들어갑니다. 반면 영상 작업 폴더의 스킬에는 제목을 뽑는 방식이나 채널 상태를 정리하는 절차가 들어갑니다. 두 문서는 형식만 같을 뿐 안에 담긴 내용이 겹치지 않습니다.

공용으로 묶으면 한쪽 요구가 바뀔 때마다 다른 쪽까지 확인해야 하지만, 폴더별로 따로 두면 그 폴더의 작업만 보고 고치면되기 때문에 폴더별로 따로 두는 방식이 훨씬 효율적입니다.

chrome-devtools를 붙인 이유

여덟 개의 폴더 중 외부 도구와 연결되어 있는 곳은 총 4곳입니다. 그중에서도 브라우저를 붙인 핸드북 폴더 이야기를 해 보려고 합니다.

1) 내 크롬에서 멋대로 열리는 페이지들

핸드북 폴더에서는 강의나 도서에 필요한 별도 보조 자료를 만들고 고치는 작업을 합니다. 그래서 클로드가 웹 페이지를 열어 작업을 하는 일이 자주 발생하는데, 처음에는 이 작업이 제가 평소에 켜 두고 쓰는 크롬에서 일어났습니다.

제가 다른 작업을 하고 있는 중에 보고 있던 크롬 탭에서 갑자기 웹 페이지가 열리고 닫히니 여간 거슬리는 게 아니었습니다. 제 크롬에는 작업 중인 탭이 늘 여러 개 열려 있고 각종 서비스에 로그인된 상태이기도 합니다. 보던 화면이 밀리는 것도 문제였지만, 로그인된 계정을 건드리게 될지도 모른다는 점이 더 신경 쓰였습니다.

그래서 자동화용 브라우저를 따로 두기로 하고, 이 폴더에만 chrome-devtools 서버를 붙였습니다. 여기서 짚어 둘 것이 있는데, chrome-devtools는 브라우저가 아니라 브라우저를 원격으로 조종하는 도구입니다. 그래서 조종할 대상을 지정해 줘야 합니다. 저는 크롬 대신 크로미움을 따로 설치해 두고, 실행 파일 경로와 전용 프로필을 지정했습니다.

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

무엇보다도 이제는 이 브라우저가 백그라운드에서 알아서 돌아갑니다. 제가 쓰던 창은 그대로 두고 옆에서 따로 열렸다 닫히니, 결과만 확인하면 되니 방해되지 않고 아주 편리했습니다.

폴더를 따로 나눠서 관리하면 좋은 점이 여기서 드러납니다. 브라우저가 필요한 폴더에만 연결해 두었으니, 나머지 폴더에서는 이 도구를 아예 부를 수 없습니다. 글만 쓰는 폴더에서 클로드 코드를 켜도 브라우저는 뜨지 않고, 반대로 핸드북 폴더의 브라우저 규칙이 다른 작업에 끼어들 일도 없습니다. 서로 섞일 일이 없으니 각 폴더가 자기 일에만 집중할 수 있게 된 것입니다.

2) 언제 껐다 켜야 할까

브라우저를 오래 켜 두면 메모리를 계속 물고 있고, 작업이 끝나도 정상적으로 종료되지 않은 프로세스가 남습니다. 처음에는 느려졌다 싶을 때 감으로 껐다 켰는데, 그러다 보니 이미 느려진 다음에 대응하게 됐습니다. 그래서 브라우저 자동화에서 흔히 쓰이는 권장 기준을 폴더 문서에 옮겨 두고 참고하고 있습니다.

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

표 자체를 외울 필요는 없습니다. 클로드 코드를 사용하면서 몇 가지만 신경을 쓰면 클로드 코르들 잘 활용할 수 있습니다.

첫째, 페이지는 확인이 끝나면 바로 닫게 합니다. 둘째, 한 번에 여러 페이지를 열어야 하는 작업은 다섯 개 안쪽으로 나눠 시킵니다. 셋째, 한 시간 넘게 붙잡고 작업한 날은 중간에 한 번 브라우저를 껐다 켭니다.

bypassPermissions, 확인 절차를 끄고 쓰기

폴더별로 클로드 코드를 사용해 작업을 하면 한 가지 고민이 또 생기는데요. 그건 바로 어디까지 물어보지 않고 진행하게 할지, 즉 권한을 어디까지 줄지입니다.

클로드 코드는 파일을 고치거나 명령을 실행하기 전에 사용자에게 확인을 받습니다. “이 명령을 실행할까요?” 하고 물어보는 창이 뜨고, 허용을 눌러야 다음으로 넘어갑니다. 안전장치이자 기본 동작입니다.

bypassPermissions는 이 확인 절차를 꺼 두는 설정입니다. 폴더별 설정 파일에 한 줄 넣으면 그 폴더에서는 묻지 않고 바로 진행합니다.

같은 성격의 수정이 계속 이어지는 폴더에서 쓰면 좋습니다. 저는 원고를 수정하는 폴더에 걸어 뒀는데, 파일 하나를 고치는 데도 읽기와 수정과 저장이 여러 번 나누어 일어나다 보니 확인 창이 그만큼 자주 떴기 때문입니다. 꺼 두면 긴 작업을 시켜 놓고 자리를 비웠다가 결과만 확인하는 방식도 가능해집니다.

주의할 점은 잘못된 명령도 똑같이 그냥 실행된다는 것입니다. 그래서 저는 그 폴더에서 생긴 사고를 되돌릴 수 있는지를 보고 정합니다. 파일을 잘못 고친 것은 이력을 되돌리면 되지만, 데이터베이스처럼 제 컴퓨터 밖으로 나가는 작업은 되돌릴 자리가 없습니다. 이런 폴더라면 조회 도구까지만 허용해 두고 데이터를 바꾸는 작업은 확인을 받게 두는 편이 낫습니다.

나만의 꿀팁

여기까지 작업들을 여러 개의 폴더별로 나눠서 활용하는 방법에 대해 이야기를 했는데요, 실제로 이렇게 쓰다 보니 손에 익은 방법이 두 가지 정도가 생겼습니다. 매번 올바른 폴더에서 실행하는 문제를 해결한 방법과, 실행 자체를 편하게 만든 방법입니다.

1) 터미널 키퍼

폴더별로 나눠 뒀으니 매번 올바른 폴더에서 클로드 코드를 실행해야 합니다. 저는 이 부분을 VSCode로 해결했습니다. 편집기 안에서 터미널을 여러 개 띄울 수 있으니, 폴더마다 하나씩 잡아 두면 관리가 한결 편해집니다.

여기에 유용하게 쓰는 익스텐션이 하나 있는데요, 바로 터미널 키퍼(Terminal Keeper)입니다. 터미널 구성을 파일로 저장해 두는 확장 기능인데, 편집기를 켜면 저장해 둔 터미널이 한꺼번에 열립니다. 저는 폴더마다 하나씩, 여덟 개를 등록해 뒀습니다.

<출처: 작가, vscode 캡쳐>

터미널마다 열리자마자 해당 폴더로 이동하도록 명령을 걸어 두면, 편집기를 켜는 순간 여덟 개 터미널이 각자 제 폴더에 가 있습니다. 거기서 클로드 코드를 실행하면 그 폴더의 스킬과 설정이 그대로 붙습니다. 이름과 색, 아이콘을 다르게 줘 두면 지금 어느 폴더에 있는지도 눈으로 구분됩니다. 설정은 폴더마다 이런 항목이 하나씩 들어갑니다.

<출처: 작가, vscode 캡쳐>

실제로 적용하면 위의 그림과 같이 설정이 됩니다. 오른쪽에 터미널 여덟 개가 각각 이름과 아이콘을 달고 늘어서 있고, 지금 고른 터미널은 판매 폴더에서 클로드 코드가 떠 있는 상태입니다.

2) alias 설정

클로드 코드는 터미널에 claude를 입력해서 실행하는데, 이게 생각보다 오타가 자주 발생합니다. calude, cluade처럼 글자 순서가 뒤바뀌어서 계속 실행이 되지 않는 경우가 종종 발생합니다.

그래서 저는 cc 두 글자만 치면 실행되도록 별칭(alias)을 걸어 뒀습니다. 설정 파일을 직접 찾아 열 필요는 없습니다. 클로드 코드에게 이렇게 한 마디만 하면 알아서 해 줍니다.

너를 실행하는 명령어를 cc로 입력하면 실행되게 수정해줘

마치며

폴더별로 나누는 방식이 언제나 유리하지는 않습니다. 다루는 프로젝트가 하나이거나 성격이 비슷하다면 전역에 두는 쪽이 손이 덜 갑니다. 제가 나눈 이유는 여덟 개 폴더가 하는 일이 서로 달라서, 한쪽에 필요한 것이 다른 쪽에서는 방해가 됐기 때문입니다.

비슷한 상황이라면 이 순서를 권합니다. 규칙과 도구는 전역에 두지 말고 그것이 필요해진 폴더에만 두시고, 규칙 자체도 미리 상상해서 적기보다 한 번 겪은 다음에 적는 편이 오래갑니다. 확인 절차는 그 폴더에서 일어날 사고를 되돌릴 수 있는지를 보고 정하시면 됩니다. 그리고 나누기로 했다면 터미널 구성부터 잡아 두시길 바랍니다.

]]>

클로드 코드로 만든 주식 분석 리포트: 하네스 분석하기

장기 작업을 수행하는 AI 에이전트의 상태, 메모리, 실행 흐름을 안정적으로 제어하려면 하네스 엔지니어링이 필수적입니다. 에이전트가 단번에 완벽한 답을 내놓지 못하더라도, 결과물을 단계별로 검증하며 완성도를 올려가는 흐름을 만드는 것이 핵심인데요. 오늘은 Planner - Generator - Evaluator 구조를 활용해 명령어 한 줄로 주식 분석 리포트를 자동 생성하는 하네스의 파이프라인을 하나씩 뜯어서 살펴봅니다. 먼저 이 하네스 시스템이 실제로 어떻게 작동하고 어떤 결과물이 나오는지 간단한 실행부터 확인해 보겠습니다.

다음 깃허브를 클론한 뒤 해당 폴더로 이동해서 클로드 코드를 실행합니다.

[Terminal] 

git clone https://github.com/wnghdcjfe/stock-report-harness 
cd stock-report-harness 
claude

클로드 코드에서 다음처럼 입력하여 실행합니다.

[Claude Code] 

/stock-goal 네이버 주가 1년 분석

클로드 코드 실행 화면

30분 정도 기다리면 다음 그림처럼 네이버를 분석한 주식 리포트가 나옵니다.

생성된 주식 리포트

생각보다 네이버의 주가를 분석하는 리포트가 잘 나온 것을 볼 수 있습니다. 어떻게 만들었을까요? 지금부터 살펴보겠습니다.

1. 시스템 설계

이 에이전트는 사용자의 주식 리포트 요청을 바로 HTML로 만들지 않습니다. 그 대신 plan, research, draft, image, review, build 순서의 하네스 엔지니어링으로 구현합니다.

각 단계는 다음 단계가 검증할 수 있는 산출물을 남깁니다. 특히 종목 관련 리서치는 최신 뉴스 100건과 최신 뉴스 5건 요약, 가격 차트, 출처, 리뷰 결과를 모두 추적 가능하게 보존합니다.

2. 에이전트 구성

자, 그러면 각 에이전트는 어떻게 구성해야 할까요?

각 에이전트는 앞 단계가 남긴 파일을 입력으로 읽고, 자신의 결과를 다음 단계가 읽을 파일로 남깁니다. Planner가 plan/<slug>.md를 쓰면 Research Generator가 그것을 읽어 research/<slug>.md를 만들고, Lecture Generator가 다시 그 둘을 읽어 drafts/<slug>.md를 작성하는 식입니다.

Planner

Planner는 사용자의 자연어 요청을 plan/<slug>.md로 바꾸는 기준 문서 작성자입니다. 이 에이전트는 주제를 정리하는 수준을 넘어 후속 단계가 따라야 할 데이터 조건과 검증 기준까지 지정합니다. Planner의 역할은 ‘무엇을 만들지’뿐만 아니라 ‘어떤 근거로 검증할지’까지 먼저 고정하는 것입니다. Planner가 확정하는 주요 항목은 다음과 같습니다.

slug / topic, request / output_type / audience / ticker / period_start, period_end / chart_required / price_data_source: yfinance / price_data_interval: 1d / assumptions / 리서치 질문 / 데이터 요구 사항 / 리포트 개요 / 차트 계획 / Hero 이미지 방향 / 리뷰 기준 / 리스크와 제약

Research Generator

Research Generator는 plan/<slug>.md를 읽고 research/<slug>.md를 작성합니다. 이 파이프라인에서 가장 강화된 단계입니다. 종목이 포함된 경우 Research Generator는 다음을 수행합니다.

yfinance 기준 ticker와 기간을 확인합니다.
가격 데이터는 1일봉(interval=1d) 기준으로 다룹니다.
종목별 최신 뉴스 최소 100건을 수집합니다.
뉴스 100건을 날짜, 매체, 제목, 핵심 이슈, 가격·수급·리스크 해석으로 분류합니다.
한국 상장 종목은 가능하면 토스증권 뉴스와 투자자별 매매 동향을 참고합니다.
사용한 API 또는 페이지 URL을 sources와 output/assets/* 원자료 JSON에 남깁니다.
항목별 URL이 없으면 임의로 조작하지 않고 fallback 여부를 명시합니다.

Lecture Generator

Lecture Generator는 plan과 research를 읽어 drafts/<slug>.md를 만듭니다. 이 단계의 목표는 리서치 메모를 독자가 이해할 수 있는 리포트 원고로 바꾸는 것입니다. draft 규칙은 다음을 요구합니다.

frontmatter에 ticker, period_start, period_end, plan_source, research_source를 둡니다.
가격 차트가 필요한 경우 직접 숫자를 임의 삽입하지 않고 price-chart 블록을 선언합니다.
숫자와 사실 주장은 research 출처와 연결합니다.
투자 권유, 수익 보장, 매매 지시처럼 보이는 표현을 피합니다.
최신 뉴스 100건 중 시간 순 최신 5건을 별도 블록으로 요약합니다.
최신 뉴스 5건의 제목은 클릭 가능한 링크여야 합니다.

예시 차트 블록은 다음과 같습니다.

title: 삼성전자 최근 30일 종가 추이 
aria_label: 삼성전자 2026-04-27부터 2026-05-26까지 일별 종가 추이 
field: Close 
interval: 1d 
currency: KRW

이 구조 덕분에 초안 작성자는 가격 데이터를 꾸며 쓰지 않고, build 단계가 실제 yfinance 데이터를 사용하여 차트를 생성합니다. 작성과 데이터 처리를 분리하는 단순한 장치이지만, 잘못된 가격표가 본문에 섞이는 사고를 원천적으로 막습니다.

Image Generator

Image Generator는 plan, research, draft를 모두 읽고 GPT의 image gen 스킬을 이용하여 3개의 이미지 후보를 만듭니다. 이미지 규칙은 이미지가 단순 장식이 아니라 리포트 메시지의 시각 요약이어야 한다고 봅니다. 필수 산출물은 다음과 같습니다.

├─ output/assets/<slug>-hero-v1.prompt.txt 
├─ output/assets/<slug>-hero-v2.prompt.txt 
├─ output/assets/<slug>-hero-v3.prompt.txt 
├─ output/assets/<slug>-hero-v1.png 
├─ output/assets/<slug>-hero-v2.png 
├─ output/assets/<slug>-hero-v3.png 
├─ output/assets/<slug>-hero-v1.score.json 
├─ output/assets/<slug>-hero-v2.score.json 
├─ output/assets/<slug>-hero-v3.score.json 
├─ output/assets/<slug>-image-manifest.json 
└─ output/assets/<slug>-selected-image.json

최종 HTML은 선택된 hero 이미지 한 장만 사용합니다. 선택 정보가 없으면 build 단계는 완료로 취급하지 않습니다.

3. 리뷰 에이전트

리뷰 단계는 이 시스템에서 가장 중요한 안전장치입니다. 메인 세션이 직접 “괜찮다”고 판단하지 않고, 별도 관점의 리뷰 에이전트를 거쳐 검토합니다. 이때 리뷰 에이전트들은 모두 메인 세션과 분리된 다른 세션에서 독립적으로 실행됩니다. 같은 모델을 쓰더라도 세션이 다르면 사고의 관성이 끊어지고, 처음 보는 사람의 시선이 되살아나기 때문입니다.

여기에 더해 클로드 코드 기반의 리뷰뿐만 아니라 코덱스의 리뷰까지 함께 활용합니다. 같은 결과물을 서로 다른 모델로 한 번 더 보게 해서 교차 검증을 거치는 셈입니다. 한 모델이 놓친 부분을 다른 모델이 잡아낼 가능성을 높이는 장치입니다.

fact-checker

fact-checker는 사실성 담당 에이전트입니다. 즉, fact-checker는 ‘문장이 그럴 듯한가’가 아니라 ‘근거 체인이 끊기지 않았는가’를 봅니다. 주요 역할은 다음과 같습니다.

plan, research, draft의 ticker, 기간, 출처 정합성을 확인합니다.
draft의 핵심 주장과 research 근거가 일치하는지 봅니다.
yfinance 가격 데이터와 차트 조건이 맞는지 확인합니다.
plan_source, research_source frontmatter가 있는지 확인합니다.

lecture-designer

lecture-designer는 교육 설계 담당 에이전트입니다. 주요 역할은 다음과 같습니다.

draft가 plan의 리포트 목표와 대상 독자를 따르는지 확인합니다.
초보자가 읽을 수 있는 흐름인지 봅니다.
문단이 과도하게 길지 않은지, 섹션 전환이 자연스러운지 검토합니다.
price-chart가 리포트 흐름과 연결되는지 확인합니다.

content-editor

content-editor는 문장과 톤 담당 에이전트입니다. 주요 역할은 다음과 같습니다.

plan의 톤과 목적에 맞게 draft 문장을 검토합니다.
중복 표현과 장황한 문장을 줄입니다.
제목, 소제목, 마무리 문장의 품질을 봅니다.
투자 권유처럼 보이는 표현을 제거합니다.

Codex Independent Review

코덱스의 리뷰는 같은 내용을 코덱스라는 다른 LLM 세션에서 다시 보는 교차 리뷰어입니다. 이 리뷰는 메인 세션의 추론으로 대체할 수 없습니다. 다음과 같은 검토 범위를 기반으로 최종 상태 pass, needs_fix, blocked 중 하나로 판단합니다.

plan 누락
논리 비약
사실 오류 가능성
세 리뷰어가 놓칠 수 있는 blind spot

리뷰 에이전트는 몇 개가 적정할까요?
리뷰어를 늘릴수록 결과물의 품질이 단조롭게 좋아질 것 같지만, 실제 연구 결과는 그렇지 않습니다. 학계는 일관되게 ‘3~5명이 sweet spot, 6~8명이 상한’이라는 결론으로 수렴하고 있습니다.

4. 리뷰-수정 루프

리뷰가 끝나면reviews/<slug>.md의 status에 따라 다음 행동이 자동으로 분기됩니다.

pass: Build 단계로 진행합니다(책임: Builder).
needs_fix: 회귀 라우팅 표에 따라 이전 단계로 되돌아갑니다(책임: 해당 단계 Generator).
blocked: 루프를 중단하고 인간 개입을 요청합니다(책임: 운영자).

needs_fix는 자동 처리, blocked는 항상 인간 호출입니다. 이 둘을 구분하지 않으면 에이전트가 해결할 수 없는 문제까지 무한 재시도하게 됩니다.

어디로 돌아갈지 정하기

리뷰에서 지적이 나오면 그 종류에 따라 돌아가야 할 단계가 달라집니다. 출처가 잘못된 글을 문장만 다듬어 내보내면 안 됩니다. 어떤 리뷰어가 어떤 종류의 지적을 했는지에 따라 어디부터 다시 손볼지를 미리 정해둡니다.

(예)

fact-checker가 “출처나 근거가 빠졌다”고 하면 → research로 돌아가 자료부터 다시 봅니다.
lecture-designer가 “구성이 어색하다, 차트 라벨이 이상하다”고 하면 → draft로 돌아가 원고를 손봅니다.
content-editor가 “문장이 매끄럽지 않다, 같은 말이 반복된다”고 하면 → draft로 돌아가 표현을 다듬습니다.
codex-independent가 “놓친 부분이 있다, 논리가 비약된다”고 하면 → 그 문제가 비롯된 단계로 돌아갑니다.

Generator의 세 가지 응답: acknowledge/defer/reject

회귀를 받은 Generator는 모든 리뷰 의견을 무조건 반영하지 않습니다. 세 가지 응답 중 하나를 선택하고 그 근거를 reviews/<slug>.md에 기록합니다.

acknowledge : 지적을 수용하고 수정합니다.
defer : 이번 라운드에서는 다루지 않고 다음 이슈로 미룹니다. plan/<slug>.followups.md에 기록합니다.
reject : 지적이 잘못되었거나 plan 의도와 어긋난다고 판단해서 거부합니다. 거부 사유를 명시합니다.

종료 조건

핑퐁은 반드시 끝이 있어야 합니다. 다음 세 조건 중 하나가 충족되면 루프를 중단합니다.

수렴 : status가 pass가 되어 Build로 넘어갑니다.
반복 한계 : 최대 3라운드까지만 허용합니다. 4라운드가 필요하면 blocked로 전환합니다.
동일 지적 반복 : 같은 카테고리의 지적이 연속 2라운드 같은 문구로 등장하면 blocked로 전환합니다. 같은 곳을 두 번 찔러도 안 고쳐지면 에이전트만으로는 해결되지 않는다는 신호이기 때문입니다.

메모리에 기록하기

핑퐁이 끝난 뒤에는 그 라운드에서 반복적으로 등장한 지적을 기록으로 남깁니다. 다만 이 기록을 단순히 텍스트 파일에 쌓아 두기만 하면 다음 라운드에서 또 같은 실수가 나오기 쉽습니다. 그래서 이 시스템에서는 회고 결과를 memory 파일에 정리해 두고, 다음 작업이 시작될 때 inject-memory-context.sh 훅이 해당 도메인과 관련된 메모리를 자동으로 컨텍스트에 주입합니다. 회고가 “한 번 쓰고 끝나는 글”이 아니라, 다음 작업에서 곧바로 활용되는 살아 있는 기억이 되는 구조입니다.

같은 종류의 지적이 여러 작업물에서 반복된다면 그것은 한 작업의 문제가 아니라, 하네스 자체가 그 실패를 막지 못하고 있다는 신호입니다. 이때는 memory에만 적어 두는 것으로는 부족합니다. 더 강한 가드레일, 즉 lint 규칙, 자동 테스트, 리뷰어 프롬프트, 새 스킬 같은 형태로 끌어올려야 합니다.

5. Builder

Builder는 plan, research, draft, review, selected-image를 모두 읽고 최종 HTML을 만듭니다. Builder의 책임은 다음과 같습니다.

reviews/<slug>.md가 존재하고 status가 pass인지 확인합니다.
선택된 이미지 JSON이 있는지 확인합니다.
draft의 price-chart 블록을 yfinance 1일봉 데이터로 렌더링합니다.
x축 라벨은 YYYY-MM-DD 형식으로 출력합니다.
최종 HTML에는 선택된 hero 이미지 한 장만 포함합니다.
HTML 본문에는 [S1], [S2] 같은 검증용 인라인 참조 표식을 노출하지 않습니다.
최신 뉴스 5건 요약 블록을 독자가 클릭 가능한 형태로 포함합니다.

6. 훅 기반 가드레일

훅을 통해 가드레일 패턴을 구현합니다. 클로드 코드가 명령을 실행하거나 파일을 수정하는 등 주요 작업을 수행하는 순간마다 훅이 먼저 개입하여 작업이 정해진 규칙과 절차를 벗어나지 않도록 통제합니다. 구체적으로는 위험한 명령을 차단하고, 정해진 작업 순서를 강제하고, 출력물이 규칙을 지켰는지 검증하며, 필요한 컨텍스트를 자동으로 주입하는 역할을 합니다. 여기에서의 하네스 예시는 다음 여덟 가지 훅을 사용합니다.

1) block-dangerous-bash.sh

rm -rf /, sudo, 원격 스크립트 파이프 실행, 강제 푸시 같은 위험 명령을 차단합니다.

2) protect-sensitive-files.sh

.env, .git, 깃허브 워크플로, 핵심 금융 스타일 가이드, 출력 스펙 같은 보호 경로의 수정을 막습니다.

3) forbid-financial-advice.sh

draft와 HTML에 투자 권유, 수익 보장, 사기성 표현이 들어가면 차단합니다.

4) enforce-plan.sh

research, drafts, output 변경 시 선행 산출물이 있는지 확인합니다. 다음 순서를 강제합니다.

/plan → /research → /draft → /image → /review → /build

5) enforce-citations.sh

draft의 [3]과 같은 출처와 연동되어 있는지 등을 확인합니다.

6) remind-review.sh

draft가 변경되었는데 별도 세션 기반 4-way 리뷰가 없다고 나타나면 이후의 종료를 막고 다시 리뷰를 실행합니다.

7) inject-memory-context.sh

사용자 요청 도메인에 맞는 memory topic을 자동 주입합니다.

8) enforce-memory.sh

memory 파일이 변경되었을 때 scripts/validate_memory.py로 형식을 검증합니다. 이 구조는 같은 실패를 반복하지 않도록 경험을 문서와 검증 도구로 남기는 장치입니다.

8. 최종 상태 정의

하나의 리포트 산출물이 “완료되었다”고 말하려면 다음 조건을 모두 만족해야 합니다.

plan/<slug>.md가 있습니다.
research/<slug>.md가 있고 plan을 참조합니다.
종목 관련 리서치라면 최신 뉴스 100건 원자료와 분석이 있습니다.
drafts/<slug>.md가 있고 plan과 research를 참조합니다.
draft와 HTML에 최신 뉴스 5건 요약이 있습니다.
최신 뉴스 제목은 클릭 가능한 링크입니다.
hero 이미지 후보 3개와 선택 JSON이 있습니다.
reviews/<slug>.md가 있고 status가 pass입니다.
리뷰는 separate-session-4way 방식으로 기록되어 있습니다.
output/<slug>.html이 생성되어 있습니다.
HTML에는 검증용 [S1] 표식이 노출되지 않습니다.
투자 권유나 수익 보장 표현이 없습니다.

주요 폴더 구조 및 코드 설명

그러면 실제로 stock-report-harness 폴더의 구조와 주요한 실제 코드를 살펴보겠습니다. stock-report-harness 폴더를 열어 보면 .claude 아래의 그림처럼 훅과 에이전트, 스킬 등이 정리되어 있습니다.

stock-report-harness 폴더 구조

중요한 파일들 위주로 살펴봅시다.

└─ agents/fact-checker.md 

--- 
name: fact-checker 
description: 주식 리포트 plan/research/draft의 사실 일관성, 출처 품질, 티커/날짜 정합성, yfinance 가격 데이터, 뉴스 URL, 금융 안전 요건을 검증한다. 
--- 
주식 리포트 하네스의 fact-checker 리뷰어다. 
검토 항목: 
- `ticker`, `period_start`, `period_end`가 plan/research/draft/review 전체에서 일치하는지 확인한 다. 
- 가격 관련 주장이 yfinance/원본 차트 JSON과 요청 기간에 부합하는지 확인한다. 
- 수치 주장에 출처 표식이 있고, 리서치 출처에 실제로 등장하는지 확인한다. 
- 뉴스 항목에 실제 URL 또는 명시적 폴백 마커가 있는지 확인한다. 조작된 기사 URL은 실패 처리한다. 
- 한국 주식 리포트에 토스 증권 뉴스와 투자자 매매 동향이 가능한 경우 포함되는지 확인한다. 
- 초안에 투자 조언, 매매 지시, 수익 보장, FOMO 표현이 없는지 확인한다. 모든 핵심 사실이 추적 가능할 때만 `pass`를 반환한다. 그렇지 않으면 정확한 파일/섹션별 수정 사항과 함 께 `needs_fix`를 반환한다.

└─ skills/stock-research/SKILL.md 

command 
--- 
name: stock-research 
description: 주식 리포트 slug에 대한 출처 기반 리서치를 수행한다. /stock-plan 이후 /stock-research <slug>로 사용하며, yfinance 일봉 가격, 최신 뉴스 100건, 한국 주식의 토스 증권 뉴스/매매 동향 확인, research/<slug>.md 출력을 포함한다. 
--- 
# 주식 리서치 스킬 
`plan/<slug>.md`를 기반으로 `research/<slug>.md`와 `output/assets/` 원자료 파일을 생성한다. 
## 선행 조건 
- `plan/<slug>.md`가 존재해야 한다. 없으면 중단하고 `/stock-plan <요청>`을 먼저 실행하라고 안내한다. 
- plan 프론트매터에서 `ticker`, `period_start`, `period_end`, `price_data_source`, `price_data_ interval`을 읽고 유지한다. 
## 절차 
1. 티커와 기간을 plan 대비 검증한다. 
2. `yfinance`로 요청 기간 전체의 실제 일봉 가격 데이터를 수집한다. 
- 원본/정규화 데이터를 `output/assets/<slug>-price-chart-v1.json` 또는 명확히 명명된 파일로 저장한다. 
- `YYYY-MM-DD` 레이블을 오름차순으로 사용한다. 
3. 출처 기반 맥락을 수집한다: 
- 1차 출처 우선: 기업 IR, 공식 뉴스룸, 공시, 거래소/중앙은행 데이터. 
- 이벤트와 리스크는 공신력 있는 매체를 사용한다. 
- 한국 상장 주식은 토스 증권 주식 뉴스와 투자자 매매 동향을 가능한 경우 확인한다. 
4. 주식/ETF/섹터 요청 시 가능하면 최신 관련 뉴스 100건 이상을 수집·분류한다. 
- 최신 뉴스 원본 JSON을 `output/assets/<slug>-*-latest100.json`으로 저장한다. 
- 분류/분석 JSON을 `output/assets/<slug>-*-analysis100.json`으로 저장한다. 
- 기사 URL을 조작하지 않는다. API에 개별 URL이 없으면 제공자/검색 폴백을 유지하고 `url_is_ fallback: true`로 표시한다. 
5. `research/<slug>.md`에 최소 다음 프론트매터를 포함해서 작성한다: 
`slug`, `title`, `created_at`, `period_start`, `period_end`, `ticker`, `price_data_source`, `price_data_interval`, `plan_source`, `sources`. 
6. 본문 필수 항목: 
- 결론 요약 
- 주가 데이터 메모 
- 핵심 이벤트/메커니즘 
- 뉴스 100건 표 또는 수집 한계와 근거 
- 수급/투자자별 매매 동향 (가능한 경우) 
- 리스크/불확실성 
- References/출처 표식 (`[S1]` 등) 
## 제약 조건 - 임의·샘플링 가격 데이터를 사용하지 않는다. 
- 존재하지 않는 기사 URL을 조작하지 않는다. 
- 사실과 추론을 분리한다. 
- 외부 접근이 차단되면 증거를 지어내지 말고 정확한 누락 데이터를 명시한 `blocked`/한계 섹션을 작성한다. 
## 완료 보고 
`research/<slug>.md`, 주요 원자료 JSON 파일, 가격 데이터 행 수, 뉴스 건수, 다음 명령어를 보고한다: `/stock-draft <slug>`. 
`stock-goal`에서 호출된 경우 이 보고는 내부 체크포인트일 뿐이다. 멈추거나 사용자를 기다리지 않고 즉시 `/stock-draft <slug>`로 진행한다.

9. 더 나아가야 할 길

이것만으로도 주식 분석 리포트를 만드는 자동 시스템을 구축했다고 할 수 있습니다. 그러나 여기에서 시스템적으로 더 개선해 나갈 부분들이 있습니다. 바로 이 부분이 개발자가 해야 할 일입니다.

1) 데이터 추출 개선

yfinance로 시세를 매번 끌어오는 방식은 빠르게 시작하기에는 편리하지만, 보고서를 한 번 만들 때마다 같은 API를 반복해서 두드리는 구조라 비용과 지연이 누적됩니다. 또한 다음 그림처럼 클로드 코드의 rate limit에 걸려서 데이터를 아예 가져오지 못하는 경우도 발생합니다.

실행 로그

2) 뉴스 품질 개선

뉴스도 같은 문제를 안고 있습니다. 보고서를 만들 때마다 즉석에서 뉴스를 긁어 오면 양은 많아도 광고성 · 중복성 기사로 채워지기 쉽습니다.

3) 리뷰 에이전트의 독립 컨텍스트와 병렬 실행

현재 이 시스템에서 리뷰 에이전트의 독립 컨텍스트는 부분적으로만 보장됩니다. 실제 독립적으로 실행될 수도 있고 아닐 수도 있습니다. 그저 아래처럼 “권장” 수준으로만 강제하고 있을 뿐입니다. 또한 이 리뷰 에이전트 부분은 병렬 실행이 아닙니다.

4) 토큰 최적화

리포트의 경우 본문 구조도 고정되어 있습니다. 지금은 LLM Evaluator를 통해 토큰을 쓰면서 검증하는 방식으로 동작합니다.

이렇게 하네스 시스템을 활용하면 AI 에이전트의 불확실성을 통제하여 장기 작업을 안정적으로 수행할 수 있습니다. 물론 실무 환경에 맞추어 데이터 수집 방식이나 토큰 최적화 등 개선해 나갈 과제들도 여전히 남아 있지만 이제 우리가 고민해야 할 것은 함수 한 줄이 아니라 에이전트가 일하는 시스템 설계가 될 것이라는 점은 분명해 보입니다.

이 글은 길벗에서 출간된 책 <클로드 코드 제대로 시작하기>에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다.

]]>

AI로 코딩이 10배 빨라졌다면, 왜 조직의 속도는 그대로일까

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

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

써볼 것: awesome-mcp-servers - AI에 도구를 붙이고 싶을 때 찾아보는 목록
참고할 것: 같은 주에 나온 앤트로픽, 구글, 오픈AI 발표 - 요즘 AI 회사들이 신경 쓰는 것
적용해볼 것: 코딩이 10배 빨라져도 회사는 왜 그만큼 빨라지지 않을까

<출처: punkpeye/awesome-mcp-servers, GitHub>

1. 써볼 것: AI에 MCP를 붙이고 싶을 때 살펴볼, MCP 모음집

AI에게 일을 시키다 보면 이런 순간이 옵니다. 이 AI가 내 구글 캘린더를 봐줬으면, 우리 데이터베이스를 조회해줬으면, 슬랙에 메시지를 보내줬으면. awesome-mcp-servers는 그럴 때 필요한 도구를 찾아볼 수 있는 목록입니다. AI에 외부 도구를 연결해주는 서버들을 종류별로 모아뒀죠.

* 여기서 잠깐, MCP가 뭔가요?

MCP(Model Context Protocol)는 AI와 외부 도구를 연결하는 공통 규격입니다. 앤트로픽이 제안한 개방형 표준입니다. 예전엔 AI에 도구 하나 붙이려면 그때그때 따로 만들어야 했는데, MCP라는 공통 규격이 생기면서 이 규격에 맞춰 만든 서버는 어디에나 꽂아 쓸 수 있게 됐습니다. USB의 개념처럼요. awesome-mcp-servers는 사람들이 만들어 공개한 그 서버들을 한곳에 정리해둔 거고요.

<출처: punkpeye/awesome-mcp-servers, GitHub>

무엇이 들어 있나요?

목록은 종류별로 나뉘어 있어 필요한 걸 찾기 쉬운 구조입니다. 데이터베이스, 검색, 파일 관리, 커뮤니케이션(슬랙·이메일 등), 금융, 지도, 개발 도구 등 스물다섯 갈래쯤 되는 것 같고요. 각 갈래 안에 서버가 여럿 있고, 어떤 일을 해주는지 한 줄 설명이 붙어 있습니다. 한국 서비스용 서버도 있습니다. 네이버 검색(블로그·뉴스·쇼핑), 한국 도서관 정보(정보나루), 한국어 맞춤법·글자 수 세기 같은 게 올라와 있어 내 프로젝트에 필요한 MCP를 찾아볼 수 있죠.

어떻게 쓰나요?

목록은 GitHub에 올라와 있으며, 한국어 번역 페이지도 있어 보기 좋습니다. 쓰는 순서는 어렵지 않은데요. 먼저 이 목록에서 붙이고 싶은 도구를 찾습니다. AI가 내 노션을 정리해줬으면 싶으면 노션 서버를, 데이터베이스를 조회하게 하고 싶으면 데이터베이스 서버를 고릅니다. 그다음 그 서버의 안내를 따라 내가 쓰는 AI 도구(클로드, 커서 등)에 연결하면 됩니다.

한 가지 알아둘 점은, 여기 올라온 서버가 다 공식이거나 검증된 건 아니라는 거예요. 개인이 만들어 올린 것도 많습니다. 그래서 회사 데이터나 계정을 다루는 서버라면, 믿을 만한 곳에서 만든 건지 확인하고 사용해야 합니다. 참고로 공식 표시는 목록에서 어느 정도 구분할 수 있습니다.

누구에게 좋을까요?

AI에게 특정 도구나 서비스를 연결해 일을 맡기고 싶은 사람. 원하는 걸 종류별로 빠르게 찾을 수 있어요.
MCP가 뭔지 궁금했던 사람. 목록 앞부분의 설명과 예시를 보면 감이 잡힙니다.
한국 서비스(네이버, 카카오 등)를 AI에 연결하고 싶은 사람. 한국 서버가 있는지 여기서 확인해볼 수 있어요.
다만 아직 AI에 도구를 붙여본 적이 없다면, 목록부터 뒤지기보다 클로드나 커서에서 MCP 연결하는 법을 먼저 익히는 게 순서예요. 이 목록은 그다음에 뭘 붙일까를 찾는 자리에 가깝습니다.

2. 참고할 것: 같은 주에 나온 세 회사(앤트로픽/구글/오픈AI)의 발표

9월 초 며칠 사이에 앤트로픽, 구글, 오픈AI가 나란히 새 소식을 공개했는데요. 세 기업의 발표를 간단하게 짚어보겠습니다.

<출처: Anthropic>

앤트로픽: 저희 성능은 올리고 값은 내렸어요

앤트로픽이 새 모델 Fable 5.1을 공개했습니다. 새 모델이 나오면 보통 이전보다 강력해진 성능을 어필하는 쪽이었는데, 이번엔 값을 내린 게 눈에 띕니다. 앤트로픽도 이제 성능만큼이나, 사람들이 부담 없이 쓸 수 있는지를 신경 쓰는 모습이에요.

성능이 올랐습니다. 앤트로픽 발표에 따르면 코딩과 오래 걸리는 작업에서 이전 Fable 5보다 나아졌고, 한 투자회사에서는 몇 년 동안 아무도 원인을 못 찾던 희귀한 오류를 Fable 5.1이 처음으로 찾아냈다고 합니다.
값을 내렸습니다. AI가 이미 처리한 내용을 다시 읽어들일 때 드는 비용을 75% 낮췄는데, 이 덕분에 보통 작업은 25%쯤, 길게 이어지는 작업은 최대 45%까지 저렴해진다고 합니다.

(수치는 앤트로픽 발표 기준)

<출처: Google>

구글: 저희는 영상 다 안 보고 필요한 데만 볼 거예요

구글은 Gemini가 영상을 보는 방식을 바꿨습니다. 예전엔 영상을 처음부터 끝까지 훑어서 답을 찾았는데, 이제는 물어본 것과 관련된 부분만 골라서 봅니다. 두 시간짜리 영상에서 특정 장면을 물으면, 전체를 다 돌려보지 않고 그 대목만 찾아보는 거죠.

처리량이 최대 88% 줄었습니다.
비용도 최대 66% 줄었고요.
그런데 정확도는 오히려 최대 7% 올랐습니다.
최신 제미나이 플래시 모델(Gemini 3.7 Flash, 3.6 Flash, 3.5 Flash-Lite)에 적용됩니다.

(수치는 구글 발표 기준. 긴 영상일수록 효과가 크다고 함)

저렴하게 만들면 어느 정도 품질이 떨어지기 마련인데, 구글의 소식에선 비용이 줄면서 정확도까지 올랐다는 게 눈에 띕니다. 이렇게 되면 할 수 있는 일도 늘어나죠. 예로는 두 시간짜리 강의에서 특정 대목이 언제 나오는지 콕 집어 찾거나, 영상 속에 특정 물체가 몇 번 등장하는지 세는 게 가능해질 겁니다. 지금은 개발자용 도구(Gemini API)에서 쓸 수 있고, 앞으로 제미나이 앱과 유튜브에도 순차적으로 들어간다고 합니다. (유튜브에서 영상 내용을 물어보면 답해주는 기능에 이 기술이 쓰일 예정)

<출처: OpenAI>

오픈AI: 저희 모델이 강력해진 만큼 조심해서 내놓을게요

오픈AI는 곧 내놓을 모델 Astra 이야기를 꺼냈습니다. 원문의 글은 우리의 새 모델이 얼마나 강력한지에 대한 자랑하기보다, 그 능력이 위험하게 쓰이지 않도록 조심해서 내놓겠다는 이야기에 가깝습니다.

Astra는 사람이 일일이 시키지 않아도 시스템의 허점을 스스로 찾아낼 정도로 보안 능력이 올랐습니다. 오픈AI는 자사 기준으로 처음 위험 수위가 가장 높은 등급에 이른 모델이라고 밝혔죠.
얼마 전 오픈AI는 허깅페이스에서 자사 모델이 얽힌 보안 사고를 겪었는데, 그때 배운 걸 이번 안전장치에 반영했다고 합니다.
이런 능력이 나쁜 손에 들어가면 문제가 되니, 안전장치를 단단히 걸고 처음엔 검증된 일부에게만 열기로 했습니다.

<출처: Bessemer Venture Partners, The Agentic Awakening>

3. 적용해볼 것: 코딩이 10배 빨라져도 회사는 왜 그만큼 빨라지지 않을까

AI로 코딩이 빨라졌다는 이야기는 많이 들어보셨을 겁니다. 그런데 개인이 10배 빨라지면 회사도 10배 빨라질까요? 유명 투자사 베서머 벤처 파트너스(Bessemer Venture Partners)가 여러 회사를 들여다보고 내놓은 자료가 이 질문을 다룹니다. 결론부터 말하면, 그렇지 않더라는 거예요.

이 자료를 만든 사람들이 관찰한 건 이렇습니다. 어떤 회사는 AI로 코드 짜는 속도를 거의 10배로 끌어올렸는데, 정작 아이디어가 실제 결과물로 나오기까지 전체 속도는 50%도 채 빨라지지 않았다고 합니다. 개인은 빨라졌는데 회사는 그만큼 빨라지지 않은 거죠.

왜 이런 일이 생길까요?

이 자료는 쉬운 비유로 설명해요. 낡은 세단을 스포츠카로 바꿨다고 해볼게요. 차는 당연히 빨라졌습니다. 그런데 200미터마다 빨간불이 있는 도심 길을 달리면, 도착 시간은 별로 안 줄어들죠. 신호등마다 멈춰야 하니까요.

회사도 비슷합니다. 개발 속도는 빨라졌는데, 회사가 일하는 방식은 그대로예요. 기획을 확정하는 회의, 여러 단계의 검토, 승인을 기다리는 시간, 몇 주씩 걸리는 계획 주기. 이런 게 예전 속도에 맞춰져 있어서, 코드를 아무리 빨리 짜도 그 앞뒤에서 막히게 되죠. 그래서 이 자료는 개발 도구를 새로 들이는 것보다, 그 도구에 맞게 일하는 방식을 손보는 게 더 중요하다고 말합니다.

자료에는 실제로 일하는 방식을 바꾼 회사들의 이야기도 나옵니다. 어떤 10년 된 소프트웨어 회사는 10월에 일주일 동안 개발을 아예 멈추고, 모든 개발자에게 클로드 코드로 고객 관리 시스템을 처음부터 끝까지 만들어보라는 과제를 냈어요. 직접 코드를 짜던 사람들에게, 일주일 내내 AI에게 시켜서 만드는 걸 강제로 경험시킨 거죠. 다들 말도 안 된다고 했지만 결국 다 만들어냈고, 이 경험을 계기로 개발자들이 AI에게 맡기는 방식에 익숙해지면서 지금은 새로 짜는 코드의 98%를 AI가 쓴다고 합니다.

개인의 일도 달라집니다

이 자료에서 프로덕트 메이커가 가져갈 만한 대목은, 개인이 일하는 방식이 어떻게 바뀌는가입니다.

예전에 개발자의 일은 코드를 직접 쓰는 것이었습니다. 그런데 AI에게 일을 맡기게 되면서, 일의 성격이 여러 AI를 동시에 지휘하는 쪽으로 바뀌고 있죠. 작업 서너 개를 동시에 돌려놓고, 각각 잘 가고 있는지 살피고, 방향을 잡아주는 겁니다. 직접 만드는 사람에서, 여러 AI에게 일을 나눠주고 그 결과를 챙기는 사람으로 바뀌어가는 셈이죠. 그러면서 한 사람이 다루는 일의 폭도 꽤나 넓어졌습니다. 예전엔 프론트엔드 담당, 백엔드 담당이 나뉘어 있었지만, 이제는 AI가 옆에서 거들면서 한 사람이 여러 영역을 오갈 수도 있게 됐죠.

이렇게 일하다 보면 새로운 문제가 하나 드러납니다. AI 덕분에 코드를 빨리 만드는 건 이제 어렵지 않은데, 그 결과가 맞는지 확인하는 데는 오히려 시간이 걸립니다. 생각해보면 당연한 얘기죠. 우리가 만드는 속도는 빨라졌어도, 확인하는 속도는 그대로니까요. 그래서 이 자료는 앞으로 잘하는 사람을 가르는 건 빨리 만드는 능력보다 맞는지 확인하는 능력이라고 봅니다.

여기서 말하는 확인은 결과물을 눈으로 훑어보는 정도가 아니라, 맞는지 자동으로 걸러주는 장치를 미리 만들어두는 걸 뜻합니다. 예를 들어 테스트를 촘촘히 짜두면 AI가 만든 코드가 그 테스트를 통과하는지로 옳고 그름이 갈리죠. AI에게도 결과만 내놓지 말고 스스로 점검한 근거까지 함께 내놓게 시키면, 사람이 일일이 다 뜯어보지 않아도 됩니다. 이렇게 확인이 빠르게 되는 구조를 먼저 갖춰둬야, AI에게 더 많이 맡길 수 있습니다.

이 자료는 여기서 바이브 코딩과 진짜 엔지니어링을 구분합니다. AI가 내놓는 대로 받아 쓰기만 하는 건 바이브 코딩인데, 잠깐 쓰고 버릴 거면 괜찮지만 실제 서비스로 키우려는 순간 벽에 부딪힙니다. 내가 짚어보지 않은 걸 나중에 고치거나 운영할 수 없으니까요. 그래서 AI에 일을 맡기더라도, 큰 그림과 방향은 사람이 쥐고 있어야 합니다. 물론 코드 한 줄씩 다 읽으라는 게 아니라, AI와 계획을 함께 검토하고 이게 내가 의도한 결과가 맞는지 확인하는 방식으로요.

처음엔 느리다가, 어느 순간 빨라질 겁니다

한 가지 더 짚어둘 게 있습니다. 이렇게 일하는 방식이 처음부터 빠른 건 아니라는 점입니다.

이 자료를 쓴 사람도 처음엔 AI에 맡기는 게 직접 짜는 것보다 오히려 느리게 느껴졌다고 하죠. 모든 걸 일일이 설명해야 하고, AI가 구조를 잘못 이해하거나 엉뚱한 걸 골라 뭔가를 망가뜨리기도 했다고요. 그런데 그렇게 고쳐나가는 과정은 새 팀원을 가르치는 것과 비슷합니다. 테스트 하나, 규칙 하나, 정리된 문서 하나. 이런 것들이 쌓이면서 AI가 이 프로젝트를 점점 더 잘 이해하게 돼죠. 지금 당장은 내가 직접 하는 게 빠르지만, 어느 순간부터 흐름이 바뀝니다. 다른 제품에서 본 기능을 스크린샷으로 보내거나, 떠오른 아이디어를 몇 문장으로 설명하면, AI가 이미 이 프로젝트의 구조와 방식을 알고 있어서 알아서 계획하고 만들고 검증까지 해내죠. 이 자료는 이를 ‘AI를 무작정 믿는 게 아니라, 그동안 쌓아둔 맥락과 규칙과 수백 번의 수정을 믿는 것’라고 표현합니다. 처음의 더딤은 실패가 아니라, 나중에 빨라지기 위한 밑작업인 셈입니다.

적용해볼 수 있는 것

지금 AI로 하는 일 중에, 결과가 맞는지 매번 눈으로 확인하는 게 있다면, 그중 하나를 자동으로 걸러낼 방법으로 바꿔보세요. 개발이면 테스트를, 문서 작업이면 체크리스트를 만들어두는 식으로요.
내 일에서 막히는 지점이 어디인지 한번 찾아보세요. AI로 빨리 만들어놓고도 그다음에 막힌다면, 손봐야 할 건 만드는 속도가 아니라 그 지점일 수 있습니다.
한 번에 하나씩 하던 일을 두세 개 동시에 맡겨보고, 그걸 챙기는 연습을 해보세요.

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

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

]]>

무료 AI 도구 총정리: 회사 지원 0원인데 내 돈 쓰긴 아까울 때

“그, AI로 한 번 해보지 그래?”

팀장님이 이렇게 지시합니다. 그런데 회사에 AI 구독을 지원하는 제도는 없습니다. 그렇다고 남들이 좋다는 챗GPT 플러스에 클로드 프로 같은 요금제를 내 돈으로 결제하자니, 이게 또 가격이 상당합니다. 실제로 그 값을 하는지도 전혀 모르겠는 상태라면 더더욱이요. 그래서 결제 페이지까지 갔다가 그냥 닫은 경험, 다들 한 번쯤 있을 겁니다.

그런데 2026년 8월을 기점으로, 챗GPT 무료 계정의 텍스트 대화가 무제한으로 풀렸습니다. 그것도 꽤 좋은 최신 모델을 쓸 수도 있도록요. 무료로 AI를 쓰면서 “몇 번 남았지?” 헤아리지 않아도 되는 시대가 처음 열린 겁니다. 그런 기념으로 0원으로 짤 수 있는 AI 서비스 스택을 정리했습니다.

무료 AI 서비스 티어를 작업별로 나누고, 회사가 이미 결제한 구독에서 AI를 쓰는 법과 특정 작업을 잘 하는 AI 무료 티어까지 모았습니다. 지금의 AI는 무료로도 배정만 잘하면 실제로 그럴듯하게 굴릴 수 있습니다. 함께 알아보시죠.

두고 보기 좋은 도구 지도를 만들어봤습니다. 다시 보면 더 이해하기 쉬운 게 글의 목표! <출처: 작가>

참고로 이 글은 예산별 AI 추천 3부작의 1편입니다. 다음 주에는 월 10만 원만 쓸 수 있을 때, 구독료 걱정 안 하고 일단 지르고 싶을 때, 기준으로 찾아볼 예정입니다.
가격 기준은 전부 2026년 9월 1일에 확인한 값입니다. 요금제가 워낙 휙휙 바뀌니 시간이 좀 지났다면, 다시 한 번 찾아보길 권장합니다.

대표 AI 무료 티어: 챗GPT vs 클로드 vs 제미나이

뭐니뭐니해도 지금 AI 서비스를 쓸 때는 이렇게 3가지가 먼저 떠오를 겁니다. 챗GPT, 클로드, 제미나이.

셋 다 무료로 써볼 수 있지만 한도 구조가 서로 다릅니다. 그래서 세 개 서비스 다 열어두고 아무 데나 채팅을 치면, 정작 급한 날에 세 가지 모두 한도가 막히는 상황이 옵니다. 그래서 각자 무료 티어 기준으로 장단점을 정리했습니다.

챗GPT 무료: 양이 많은 텍스트 작업

챗GPT

2026년 8월 6일 발표를 기점으로, 챗GPT 무료 계정의 텍스트 채팅이 무제한이 됐습니다. 기본 모델은 GPT-5.6 Luna로, 꽤 좋은 성능을 냅니다. 생각하는 모든 일에 웬만하면 괜찮은 답을 줄 겁니다.

그러니 겁날 게 없습니다. 공지문 하나를 놓고 톤을 다섯 번 바꿔 뽑아보는 일, 보고서 서두를 세 방향으로 써보는 일은 원래 한도가 아까워 한두 번에 끊던 작업인데요, 이제는 마음에 들 때까지 다시 시켜도 잃을 게 없습니다. 프롬프트가 서툴러도 되는 연습장이 하나 생긴 셈이고요. 그래서 생각 나면 일단 챗GPT로 가 보는 것을 추천합니다.

시작하기: 이메일 주소나 구글 계정으로 회원가입. 결제 정보 입력이나 설치할 것도 없습니다.
언제 쓰나: 일상 질문·초안 쓰기·아이디어 굴리기처럼 일단 던져보는 작업 전부
한계·주의: 무제한은 텍스트만입니다. 이미지 생성·파일 업로드·음성은 별도 한도가 그대로 살아 있습니다.

클로드 무료: 한 번에 잘해야 하는 작업

클로드

클로드 무료 티어는 리셋 한도 안에서 아껴 써야 합니다. 모델로는 Sonnet과 Haiku를 쓸 수 있습니다. 메시지 하나에 붙는 비용이 모델마다 다른 데다 대화의 길이와 복잡성, 기능에 따라 달라지므로 공식 수치는 없고요. 대신 체감상 정말 빨리 한도가 찹니다.

그래서 클로드랑 할 작업은 이런 게 좋습니다. 다시 시킬 기회가 없는 것. 오늘 오후에 나가야 하는 제안서의 마지막 퇴고, 동료 PR에 남길 리뷰 코멘트처럼 결과물 그대로 쓸 작업들입니다. 반대로 하루 종일 주고받는 잡무를 여기서 하면, 정작 필요한 순간에 못 쓸 겁니다. 그래도 확실히 직장에서 하는 일에는 클로드가 강력합니다.

시작하기: 이메일이나 구글 계정으로 가입만 하면 완료
언제 쓰나: 긴 문서 읽기, 글 다듬기, 코드 리뷰처럼 결과물을 그대로 쓰는 작업
한계·주의: 한도가 수요와 프롬프트 복잡도에 따라 변동합니다. 어쨌든 체감상 짧습니다.

제미나이 무료: 구글에 있는 자료와 이미지

제미나이

구글 계정으로 일하는 사람한테는, 체감 한도가 가장 넉넉합니다. 2026년 7월부터 Gemini 3.6 Flash가 기본 모델이 됐고, 상위 Pro 모델도 제한적으로 열립니다. 속도가 정말 빠르다는 게 특징일 겁니다. 구글 역시 정확한 한도를 공개하지 않고 유료 등급과의 배수로만 안내합니다. AI Plus가 무료의 2배, AI Pro가 4배라는 식이죠.

개인적으로 자료가 이미 구글에 있으면 제미나이 쓰는 것을 추천합니다. 즉, 드라이브에 쌓인 회의록을 요약시키거나, 화면을 캡처해 표를 읽히는 작업이 그렇습니다. 챗GPT의 무제한이 텍스트에만 걸려 있어서, 이미지가 끼는 작업은 자연히 제미나이가 또 좋고요. 무언가 기분상 최신 정보 검색 결과도 더 나아 보입니다.

시작하기: 쓰던 구글 계정으로 로그인하면 그걸로 끝입니다.
언제 쓰나: 검색이 필요한 질문, 이미지를 읽혀야 하는 작업, 구글 도구와 연동한 작업
한계·주의: 한도가 있는데 수치가 비공개라 언제 막힐지 예측하기 어렵습니다. 마감이 코앞인 작업의 마지막 단계를 여기서 처리하진 마세요. 영상 생성 같은 상위 기능은 무료에서 빠져 있습니다

이미 내는 구독료에 딸려온 AI 회수하기

사실 대다수가 간과하는 것이 있습니다. 회사가 이미 돈을 내고 있는 구독 서비스에 딸려온 AI는, 새로 돈을 내지 않아도 유료로 쓸 수 있다는 겁니다. 공짜라기보다 회수에 가깝죠. 여기 AI들은 안 써도 구독료가 그대로 나갑니다. 쓰지 않는 만큼 이미 낸 돈이 사라지는 셈이에요. 그런데 의외로 많은 팀이 이걸 켜보지도 않은 채 개인 계정 무료 티어를 아껴 쓰고 있습니다. 여기서 펑펑 써보세요.

제미나이 in 구글 워크스페이스: 구글에 딸려온 AI

회사가 구글 워크스페이스를 쓰고 있다면 이미 여러분은 제미나이에 돈을 내고 있는 겁니다. 2025년 1월부터 제미나이가 유료 워크스페이스 요금제에 기본 포함됐거든요. 회사가 인당 20달러짜리 추가 요금을 따로 내던 시절은 끝났습니다. Business Standard(연 약정 기준 인당 월 14달러) 이상이면 Docs, Gmail, Sheets, Slides, Drive, Meet 전반에서 AI를 쓸 수 있습니다. 이런 거 쓰고 있다면, 당장 회사 구글 계정으로 제미나이를 쓰세요.

시작하기: 회사 메일이 Gmail이고 문서가 Docs에 쌓이는 조직이라면 워크스페이스를 쓸 가능성이 높습니다. Docs 문서 오른쪽 위에 제미나이 아이콘이 보이면 바로 확인할 수 있습니다.
언제 쓰나: 메일 초안, 문서 요약, 회의록처럼 업무 문서가 구글에 있는 팀. 개인 계정 무료 티어보다 한도에 여유가 있습니다.
한계·주의: 정확한 사용 한도는 요금제별로 다르고, 정말 많이 쓰는 사람은 AI Expanded Access라는 별도 애드온이 필요합니다.

MS 365 코파일럿 챗: 계정만 있으면 열리는 업무용 챗

M365 구독의 회사 계정이 있으면 추가 요금 없이 웹 기반 코파일럿 챗이 열립니다. 포인트는 엔터프라이즈 데이터 보호가 적용된다는 점인데요. 회사 보안 정책 때문에 개인 계정 챗봇을 못 쓰는 환경에서 “안전한 기본 AI 채팅 서비스” 역할을 해줍니다. 회사가 M365 요금제를 제대로 쓰고 있다면, 즉, PPT, Excel 등을 돈 내고 쓰고 있다면 이 웹 챗은 열려 있을 겁니다.

시작하기: 회사 계정으로 Teams나 Outlook을 쓰고 있다면 M365 구독일 가능성이 높습니다. 그 계정으로 웹 Copilot에 로그인이 되는지 열어보면 되고, 되는 순간 AI 서비스를 하나 확보한 셈이죠.
언제 쓰나: 개인 계정 AI가 막혀 있는 회사에서의 기본 챗
한계·주의: 내 메일·파일·Teams를 읽어주는 건 유료 코파일럿(300인 이하 기준 인당 월 21달러, 엔터프라이즈는 30달러)이고요. Word, Excel, PPT 앱 안에서 쓰는 코파일럿도 돈을 내야 합니다.

무료로 즐기는 AI 실험 창구

세 번째로 소개할 무료의 세계는 AI 실험대입니다. 무료 스택으로 일하다 보면 “이 작업엔 어떤 모델이 맞지?”, “이 자료를 남의 서버에 올려도 되나?” 같은 질문이 반드시 생기는데요, 그걸 돈 안 들이고 확인하는 창구죠. 대신 그래서 이건 좀 쓰기 까다롭습니다. 손이 조금 더 가기도 하고, 개발 쪽 생태계 이해도 필요합니다.

오픈라우터의`:free`모델: 모델 갈아 끼우는 실험대

오픈라우터는 다양한 AI 모델을 이리저리 써볼 수 있는 정말 좋은 서비스입니다. 여러 오픈 모델을 API 하나로 갈아 끼울 수 있죠. 특히, 이름 뒤에 :free가 붙은 모델을 분당 20회, 무과금 계정 기준 하루 50회까지 부를 수 있습니다. 10달러어치 크레딧을 한 번이라도 사면 하루 1,000회로 올라가는데, 크레딧에 만료가 없어서 실험용으로는 사실상 일회성 지출입니다.

시작하기: 회원가입 후 대시보드에서 API 키를 발급받으면 됩니다. 카드 등록은 필요 없습니다. 다만 여기부터는 코드나 터미널을 조금 만지게 되니, 개발 경험이 없다면 공부를 조금 해야 합니다.
언제 쓰나: 자동화 스크립트나 사이드 프로젝트에서 어떤 모델이 내 작업에 맞는지 비교해 볼 때
한계·주의: 무료 모델 목록이 예고 없이 바뀝니다. 특정 무료 모델에 의존하는 설계는 금물이에요. 무료 변형은 입력 데이터가 학습에 쓰일 수 있는 조건인지 확인이 필요하고요.

구글 AI 스튜디오: 카드 등록 없이 나오는 API 키

개발자용 무료 서비스입니다. AI 스튜디오에서 키를 발급받으면 바로 무료 호출이 되는데, 결제 카드를 등록하지 않아도 된다는 점이 진입 장벽을 확 낮춥니다. Flash 계열은 하루 1,500회 수준으로 관대합니다. 다만, 구글이 공식 rate limits 문서에서 모델별 수치표를 걷어내고 AI 스튜디오 대시보드로 넘겼기 때문에, 내 계정에 걸린 정확한 한도는 그 화면에서 확인해야 합니다.

시작하기: 구글 계정으로 로그인해 키 발급 버튼 한 번. 웹 화면에서 모델을 바로 시험해 볼 수도 있어서, 코드를 쓰기 전에 감을 잡기 좋습니다.
언제 쓰나: 프로토타입이나 개인 도구에 AI를 붙여볼 때 첫 선택지
한계·주의: 무료 티어 데이터는 학습에 활용될 수 있으니 민감한 자료는 넣지 마세요. 프로젝트에 결제 계정을 연결하는 순간 무료 쿼터가 사라졌다는 보고도 있어, 실험 프로젝트는 결제 계정과 분리해 두는 편이 안전합니다.

Ollama·LM Studio: 한도도 계정도 필요없는 영원한 공짜의 세계

여기까지는 일단 전부 남의 서버를 빌려 쓰는 방식이라 한도가 붙습니다. 그런데, 모델을 내 컴퓨터에서 직접 돌리면 그 한도가 통째로 사라집니다. 영원히 공짜죠. LM Studio는 앱을 깔고 목록에서 모델을 고르면 바로 대화를 할 수 있고, Ollama는 명령 한 줄로 받아 스크립트에 붙이기 좋은 쪽입니다. 둘 다 무료이고 계정도 필요 없습니다.

그런데 왜 사람들이 이걸 안 쓰냐고요? 쓸만한 AI를 돌리려면 컴퓨터가 엄청 좋아야 하거든요. 감을 잡는 기준은 메모리인데요. 4비트로 압축한 모델 기준 파라미터 10억당 대략 0.6GB를 씁니다. 16GB면 Gemma 4 12B 정도가 쓸 만하고, 32GB면 Qwen3.6-35B-A3B 같은 모델까지 올라간다고 합니다. 맥은 메모리를 CPU와 GPU가 나눠 쓰는 구조라 같은 용량에서 유리한 편이고요.

물론, 그렇게 맞춰도 다른 AI 무료 모델들에 비하면 아쉽다고들 말합니다. 게다가 모델이 잘 동작하는 ‘하네스’ 세팅도 해야 하고요. 그러나 이런 리스크도 감당할 수 있다면, 매력적인 선택지입니다. 점점 성능 좋은 모델들이 많이 풀리고도 있으니까요.

시작하기: LM Studio는 홈페이지에서 설치 파일을 받아 실행하면 되고, Ollama는 설치 후 ollama run gemma3 같은 명령어로 모델 이름만 넣으면 알아서 내려받습니다. 대신 모델 파일이 수 GB에서 수십 GB라 다운로드 시간이 필요합니다.
언제 쓰나: 외부에 올리면 안 되는 문서 요약·분류, 호출이 반복되는 개인 자동화, 인터넷 없이 써야 하는 상황
한계·주의: 모델은 무료지만, 컴퓨터는 공짜가 아닙니다. 메모리 16GB 미만에서는 체감 품질이 확 떨어지고, 노트북이라면 발열과 배터리도 각오해야 합니다. 추론 품질도 최신 모델과는 분명한 차이가 있어요.

작업별 특화 무료 티어로 빈칸 메우기

여기까지 왔다면, 텍스트로 할 수 있는 작업은 대부분 문제 없습니다. 남는 건 개발, 디자인, PPT, 리서치, 회의록처럼 전용 도구가 더 잘하는 영역인데요. 여기서는 최적화된 도구를 찾아가는 게 나을 수 있습니다.

개발: 안티그래비티 CLI,깃헙 코파일럿 Free,오픈코드

먼저 바로잡을 소식 하나. 한동안 무료 코딩 에이전트의 기본이던 Gemini CLI는 2026년 6월 18일부로 문을 닫았습니다. 후신은 안티그래비티 CLI인데요. 무료 플랜에서 탭 완성과 명령 요청 자체는 무제한이고, 대신 요청 수가 아니라 에이전트의 작업량을 주간 갱신 쿼터로 셉니다. 쿼터 수치는 비공개.

깃헙 코파일럿 Free는 그대로 무료입니다. 월 2,000회 자동완성과 50회 챗, 모델은 자동 선택만 됩니다.

여기에 하나 더 붙일 만한 게 오픈코드입니다. 터미널에서 도는 오픈소스 코딩 에이전트인데, 자체 구독이 없고 모델을 직접 물려 쓰는 방식(BYOK)이라 어떤 키를 끼우느냐로 요금이 결정됩니다. 로컬 모델을 물리거나 공짜로 쓸 수 있는 모델을 구해서 넣으면, 도구도 0원인 터미널 에이전트가 됩니다.

시작하기: 안티그래비티 CLI와 코파일럿 Free는 각각 구글 계정, 깃허브 계정 로그인이면 됩니다. 오픈코드는 설치 명령 한 줄(`curl -fsSL https://opencode.ai/install | bash`) + 쓸 모델의 키를 연결해야 첫 대화가 열립니다.
배정: 터미널 에이전트 작업은 안티그래비티 CLI, 에디터 인라인 보조는 코파일럿 Free, 로컬 모델이나 무료 키를 붙여 쓰는 실험은 오픈코드를 추천합니다.
주의: 안티그래비티 무료의 주간 쿼터는 수치가 없어 언제 닫힐지 감으로 익혀야 합니다. 코파일럿의 챗 50회는 하루 한두 번 꼴이라, 코드 자동완성에만 쓰는 배정이 현실적이고요.

디자인: 캔바

디자인 비전공자의 기본기입니다. 무료 플랜의 본체는 수천 종의 템플릿이고 AI는 어디까지나 보조인데요. AI는 크레딧으로 세는데, 무료 플랜은 가벼운 기능 200회 또는 이미지 생성처럼 무거운 기능 20회까지 쓸 수 있습니다.

썸네일·SNS 이미지·간단한 배너까지는 충분하지만, Magic Eraser·배경 제거·AI 프레젠테이션 같은 핵심 AI 기능을 제대로 쓰려면 Pro 요금제로 올라가야 합니다.

시작하기: 구글 계정 로그인이면 웹에서 바로 열립니다. 설치 없이 브라우저에서 끝나요.

PPT: 젠스파크와 감마

젠스파크는 PPT 잘 만들기로 유명합니다. 무료 계정에 하루 약 100크레딧이 매일 갱신되고, 덱 하나가 100크레딧 남짓이라 하루 한 개꼴로 계속 만들 수 있죠. 주제를 주면 리서치부터 슬라이드 구성까지 한 번에 처리하는 방식이라 내용 초안용으로 특히 맞습니다. 대신 크레딧 소모량이 작업마다 들쑥날쑥해 예측이 어렵고, 슬라이드 디자인은 기본형이라 그대로 내보내긴 아쉽습니다.

좀 보완이 필요한 발표라면 감마를 보조 카드로 남겨두세요. 가입 때 400크레딧을 한 번 주거든요(덱 30~40개 분량). 다만 크레딧이 매달 갱신되는 게 아니라 소진되면 끝이고, 무료 산출물엔 워터마크가 붙습니다.

시작하기: 둘 다 구글 계정 회원가입이면 열립니다.

리서치: 노트북LM과 퍼플렉시티

노트북LM(2026년 7월부터 Gemini Notebook으로 이름이 바뀌었습니다)은 무료 폭이 넓습니다. 작업 창인 노트북이 100개, 노트북당 소스 50개, 채팅 하루 50회, 오디오·비디오 오버뷰 각각 하루 3회 같은 핵심 기능도 무료에 들어 있죠. 무료로 쓰기에 가장 제한이 적다고 느껴지는 서비스 중 하나입니다.

퍼플렉시티 역시 기본 검색은 무제한입니다. 고급 기능인 Pro Search는 하루 3회로 안내되는데, 소스에 따라 5회로도 표기됩니다.

시작하기: 노트북LM은 구글 계정, 퍼플렉시티는 이메일이나 구글 계정 가입. 둘 다 웹에서 끝납니다.
배정: 내 자료를 넣어 정리하는 건 노트북LM, 웹의 최신 정보를 훑는 건 퍼플렉시티.
주의: 노트북LM의 하루 한도는 어쨌든 실무 리서치엔 금방 찹니다. 퍼플렉시티도 깊이 파고드는 기능은 무료에선 체험 수준이고요.

회의록: 클로바노트

한국어 회의를 다루는 사람이라면 이건 국내 서비스가 편합니다. 네이버 계정만 있으면 월 300분(개인정보 활용에 동의하면 600분)까지 녹음을 텍스트로 바꿔주고, AI 요약은 월 15회까지 눌립니다. 매달 초기화되고요.

시작하기: 네이버 계정 로그인. 모바일 앱으로 녹음하고 웹에서 확인하는 흐름이 가장 편합니다.
주의: 월 한도를 다 쓰면 그달은 녹음·변환이 멈춥니다. 회의가 많은 달이라면 중요한 회의부터 골라 쓰는 배정이 필요해요. 개인용에는 유료 플랜이 없어서, 더 필요하면 기업용 상품으로 넘어가야 합니다.

무료 AI 도구 지도

이 작업은 어디서 해야 하는가?를 기준으로 바로 찾아볼 수 있게 불필요한 정보를 전부 걷어낸 표를 만들어 봤습니다.

마치며

2026년 9월, 지금의 무료 AI들은 몇 년 전의 무료 AI들과 완전히 다른 물건입니다. 텍스트 무제한 챗GPT도 있고, 나머지 무료 티어를 잘 돌리면 일상적인 업무는 상당 부분 0원으로도 돌아갑니다.

다만, 그만큼 무료 버전은 한계가 분명합니다. 큰 첨부를 반복해서 다루는 작업, 워터마크 없는 산출물, 내 메일과 파일을 읽는 업무 챗 같은 것들은 무료 스택 무엇으로도 해결할 수 없습니다. 그리고, 이러한 한계를 극복한 “에이전트”가 등장하고 나서 사람들이 본격적으로 AI로 미친듯한 생산성을 내기 시작했거든요. 그 해결할 수 없는 작업들이 바로 돈을 쓰기 시작하는 지점입니다.

그러니 다음 편에서는 월 10만 원이 생겼을 때, 어디부터 바꾸는 게 이득인지 다루겠습니다.

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

]]>