목차

• 에이전트는 붙이는 게 아니라 기르는 것
• 병목은 실행이 아니라 계획과 검증
• 통제보다 가시화, 지시보다 목격

“슬라이드를 준비할 생각이 없었는데, 지난번 비슷한 자리에서 나만 빈손이었다. 그래서 급하게 몇 장 짜왔다.” 첫 발표는 그렇게 시작했다. 그리고 곧바로 덧붙였다. 이건 우리가 AI를 이렇게 잘 쓰고 있다는 자랑이 아니라, 그냥 이렇게 쓰고 있다는 이야기라고. 스타트업 대표들이 모여 각자의 AI 활용법을 보여주는 자리였고, 그 첫마디가 그날 전체의 톤을 정했다. 완성된 답을 들고 온 사람은 아무도 없었다. 다들 자기 조직의 크기와 데이터와 사정에 맞춰 이제 막 걸음을 뗀 사람들이었고, 나는 그 걸음들 사이에서 반복해서 들리는 것들을 적어왔다.

에이전트는 붙이는 게 아니라 기르는 것

가장 오래 남은 이야기는 한 회사의 디자이너에게서 나왔다. 그는 에이전트를 디자인 툴에 바로 연결하는 걸 거부했다. 대신 자신이 디자인을 어떻게 시작하는지, 프로세스가 어떻게 흘러가는지, 결과물을 어떤 기준으로 평가하는지를 전부 매뉴얼로 먼저 정리했다. 그리고 그걸 주입한 에이전트에 사람 이름을 붙이고, 진짜 신입 디자이너를 기르듯 훈련시켰다. 뽑아보게 하고, 피드백을 주고, 다시 뽑아보게 하고. 지금은 요청 하나에 시안 몇 개를 비교해 내놓는 수준까지 왔다고 했다. 도구 연동은 나중 문제고, 지식 주입이 먼저라는 것.

같은 회사는 목표 수준을 먼저 박아두는 방식으로 움직이고 있었다. “AI를 쓸 거면 최소 이 정도까지 자동화되지 않으면 의미가 없다”는 선을 긋고, 그 선에 도달할 때까지 수백 개의 서비스를 자동으로 생성하고 배포해보면서 품질 담당자가 전수 검수로 공통 에러를 걸러 로직에 되먹였다. 대량 생산을 학습 루프로 쓰는 셈이다. 팀원들은 아무도 직접 손으로 작업하지 않는다. 각자의 지식을 도구에 계속 부어 넣는 게 일이다.

기르는 이야기는 조직 쪽에서도 나왔다. 한 회사는 퇴사자의 인수인계를 사람 대신 사내 봇에게 시킨다. 떠나는 사람이 후임을 붙잡고 설명하는 대신, 봇에게 지식을 다 넣어두고 봇째로 넘긴다. 에이전트와 일하며 쌓인 맥락이 증발하지 않고 회사의 자산으로 컴파운딩되는 구조를 만드는 게 핵심이라고 했다. 조직도를 에이전트가 읽을 수 있는 형태로 만들어 경영 파트너로 쓴다는 대표도 있었다. 조직 구조를 진단해보라고 하면 문제를 짚어준다. 팀에 물어보면 바쁜 사람들 며칠을 잡아먹을 것 같아 아예 묻지 않게 되던 질문들을, 이제는 부담 없이 실시간으로 던진다고 했다.

병목은 실행이 아니라 계획과 검증

여러 사람이 다른 언어로 같은 진단을 내렸다. 실행하는 에이전트는 이미 충분히 잘한다. 문제는 앞단의 계획과 뒷단의 검증이고, 이 둘은 서로 얽혀 있다.

한 대표는 주니어 개발자들이 매달 상당한 토큰을 태우는데 결과물이 엉망인 걸 보고 이 결론에 도달했다고 했다. 그가 찾은 방법은 목표만 정해주고 리서치를 넓게 시키는 것이었다. 논문과 경쟁 서비스는 당연하고, 전혀 다른 업계는 이 문제를 어떻게 푸는지까지. 그렇게 모은 리서치를 문서로 만들고, 관계를 엮어 다시 하나로 합치고, 그 안에 자기 도메인 지식을 섞으면 생각지 못한 아이디어가 나온다고 했다. 그리고 그렇게 계획의 품질이 오르면, 신기하게도 검증의 품질까지 따라 오른다는 것이다. 좋은 데이터가 뭐냐는 질문에 대한 답은 담백했다. AI가 만든 데이터는 AI가 스스로 검증할 수 없다. 그러니 이미 존재하는 검증 가능한 근거 — 논문, 기사, 실측 — 에 기반한 것만 좋은 데이터다.

구체화 단계에서 시작하는 도구 하나가 여러 번 언급됐다. grill-with-docs라는 스킬인데, 뭘 만들고 싶은지 뿌옇게만 잡힐 때 “목적이 뭔가, 기대 효과는 뭔가, 이게 되면 뭐가 달라지나”를 집요하게 되물어 추상화 레벨을 낮춰준다. 핵심은 그 문답 과정이 통째로 문서로 남는다는 것. 그 문서를 다듬으면 그대로 재사용 가능한 스킬이 되고, 다음 사람은 같은 대화를 처음부터 반복할 필요가 없다. 애용한다는 대표는 요즘 뭘 만들든 이걸로 시작한다고 했다.

검증 쪽에는 정직한 고백이 있었다. 개발팀 규모가 있는 한 회사는 생산성이 오르자 풀리퀘스트가 폭증했고, 전 구성원 리뷰라는 팀 문화 속에서 다들 코드를 대충 보기 시작했다. 리뷰 봇을 두 단계나 붙여봤지만, 안정성이 생명인 제품에서는 결국 도메인을 이해하는 사람이 책임지고 봐야 하고, 그 사람은 이제 하루 종일 리뷰만 본다. “아직 답을 못 찾았다”는 말이 그날 가장 정직한 결론이었다.

조금 결이 다르지만 같은 뿌리의 지적도 있었다. 세상 대부분의 서비스에는 쓰기 API가 없다는 것. 데이터를 읽는 건 되는데 행동하는 API는 없는 경우가 대부분이고, 브라우저 자동화로 우회하면 토큰만 태우고 실패한다. 이 근본 문제를 사람처럼 마우스와 키보드로 직접 조작하는 런타임으로 푸는 회사가 있었는데, 그 대표의 분석이 흥미로웠다. 최신 모델들이 인상적으로 보이는 지점은 사실 API가 없는 환경에서 실패를 초고속으로 반복해 결국 해내는 능력이라는 것. 우리가 감탄하는 것의 정체가 무엇인지 다시 생각하게 하는 말이었다.

통제보다 가시화, 지시보다 목격

돈 이야기는 의외로 통제의 언어가 아니었다. 한 회사는 태스크별로 API 키를 발급해 비용이 실시간으로 보이게 했다. 그러자 누가 조이지 않아도 팀원들에게 비용 감각이 알아서 생겼다. 다른 회사는 사용량이 적은 사람은 API로, 많은 사람에게만 구독 시트를 주는 식으로 이원화하되, 리턴은 어느 정도 믿음의 영역으로 남겨뒀다. 토큰 상한을 “본인 월급만큼”으로 정한 회사도 있었다. 예산 규칙처럼 들리지만 실은 2인분 역할을 하라는 메시지였다. 그리고 도입을 설득할 때는 거창한 비전보다 산수가 빨랐다. 전 구성원이 하루 한 시간씩만 아끼면 얼마가 절감되는지 계산해 보여주니 “안 할 이유가 없다”로 끝났다고 했다.

확산도 같은 문법이었다. 지시가 아니라 목격. 한 개발자가 이틀 휴가를 내면서 에이전트 혼자 앱 하나를 끝내게 했고, 돌아와 그 경험을 공유하자 팀의 참여도가 눈에 띄게 올라갔다. 격주로 몇 명이 10분씩 자기 활용법을 보여주는 쇼앤텔을 들여온 회사도 같은 원리를 말하고 있었다. 어떤 지침이나 매뉴얼보다 눈으로 본 성공 사례 하나가 크게 작동한다.

직군별 온도차에 대한 관찰도 있었다. 백엔드 개발자들은 AI를 반기는데 프론트엔드 쪽은 저항이 많았다는 것. 백엔드는 애초에 변경점이 화면에 보이지 않으니 결과물을 신뢰하기 쉬운 반면, 프론트는 자기가 바꾼 게 바로 눈에 보이는 그 과정 자체를 즐기는 사람이 많아서라는 가설이 나왔다. 저항을 직군의 문제가 아니라 일의 피드백 구조 문제로 읽어야 한다는 얘기다. 채용 기준에 대해서도 비슷한 전환이 있었다. AI 스킬 자체를 보지 않는다는 대표가 인상적이었는데, 도구를 만져본 적 없던 구성원들이 몇 달 만에 자동화 시스템을 만들어내는 걸 보고, 변별점은 툴 경험이 아니라 인접 영역으로 확장하려는 태도와 학습 능력이라고 결론 내렸다고 했다.

민감한 데이터를 다루는 회사들의 대화도 실용적이었다. 원본 데이터를 주지 않고 설계만 시키는 접근 — “데이터가 이런 구조이고 이런 필드가 있는데 비식별화하려면 어떻게 해야 하나”를 물으면 규제 근거까지 포함해 설계해준다. 실행과 설계를 분리하면 데이터를 넣지 않고도 갈 수 있는 길이 꽤 있다. 민감도에 따라 컴퓨터를 물리적으로 분리해 쓰거나, 민감한 작업만 로컬 모델로 돌리는 사례도 있었다. 보안과 활용 사이 어디에 설지는 결국 회사마다의 성향 차이라는 데 다들 동의했다.

돌아오는 길에, 에이전트를 기르던 그 디자이너가 처음에 가장 힘들어했던 이유를 떠올렸다. 참고할 레퍼런스가 전혀 없어서였다고 했다. 그런데 그날 그 자리에 모인 사람들은 서로에게 바로 그 레퍼런스가 되어주고 있었다. 누군가는 수백 개의 서비스를 자동으로 뽑아봤고, 누군가는 검증의 병목과 몇 달째 씨름 중이고, 누군가는 API가 없다는 문제 자체를 사업으로 풀고 있었다. 헤어지기 전 누군가 슬랙 채널을 하나 만들었다. 참고할 만한 자료가 있으면 올려달라고 했다. 나는 아직 아무것도 올리지 못했다.