AI가 루틴 업무를 먼저 먹는다 — 작은 팀의 역량 재편

Reid Hoffman과 Mark Pincus가 공동 창업한 Prentis가 $100M 투자 유치 협상 중이다. 두 사람의 명성보다 중요한 건 베팅의 방향이다. 루틴 컴퓨터 업무 자동화가 조만간 코딩 보조를 제치고 AI의 가장 큰 유스케이스가 될 것이라는 주장.

이 전제가 맞다면, 지금 "개발자를 더 뽑아야 한다"는 방향만 보고 있는 작은 팀은 역량 투자 우선순위를 잘못 잡고 있을 가능성이 높다. 다만, "AI 잘 쓰는 사람"으로 기준을 바꾸면 된다는 단순한 결론도 함정이 있다. 그 함정이 어디에 있는지부터 짚는 게 먼저다.

코딩 보조가 아닌 루틴 자동화 — 전선이 이동하고 있다

AI 도구 도입 초기, 대부분의 팀이 가장 먼저 손댄 건 개발자 생산성이었다. Copilot, Cursor 같은 도구로 코드 작성 속도를 올리는 것. 그게 첫 번째 전선이었다.

Prentis의 베팅은 그 전선이 이동하고 있다는 선언에 가깝다. 단순 반복 작업 — 폼 채우기, 데이터 이동, 화면 클릭, 보고서 추출 — 이런 것들이 AI가 가장 빠르게 먹어치울 영역이라는 것이다. 이 업무들은 반드시 개발자가 맡던 것도 아니었다. 운영팀이, 재무팀이, 콘텐츠팀이 매일 했던 일이다.

루틴 자동화가 성숙하면 누가 이득을 보고 누구의 역할이 줄어드는지 — 이 질문이 팀 역량 논의의 실제 중심이 돼야 한다.

$100M이 드러내는 것 — 숫자로 읽는 신호

$100M 라운드는 얼리스테이지 기준으로 작은 숫자가 아니다. 같은 공간을 노리던 Adept는 2022년 시리즈B로 $350M을 유치했다가 결국 Amazon에 팀이 흡수됐다. Cognition은 2024년 $175M을 들고 Devin을 선보였다. 자본은 계속 이 공간으로 몰렸지만 아직 명확한 승자가 없다.

Prentis의 등장이 시사하는 게 있다. 코딩 어시스턴트 시장은 이미 대형 플레이어들이 장악했다는 것. 그래서 그 아래 레이어 — 실제 컴퓨터 화면을 조작하는 자동화 — 가 다음 전장으로 굳어지고 있다. Reid Hoffman 같은 사람이 이 타이밍에 직접 창업 테이블에 앉는다는 건, 시장 형성이 가시권에 들어왔다는 판단일 가능성이 높다.

작은 팀 입장에서 이 신호가 의미하는 건 간단하다. 도구가 나왔을 때 어디에 쓸지 맥락을 미리 잡아두지 않으면, 도구가 나와도 1-2년을 그냥 흘려보낸다.

개발자를 더 뽑아야 하는가 — 작은 팀의 진짜 딜레마

우리 팀도 이 질문을 반복해왔다. 자동화 파이프라인을 늘려야 할 때마다 "개발자 한 명 더 있으면"이라는 말이 자연스럽게 나온다.

그런데 들여다보면, 실제 병목은 코드를 짜는 속도가 아닌 경우가 많았다. 어떤 데이터를 어디서 가져올지 판단하는 것, 자동 발행된 결과물이 맞는지 검증하는 것, 봇이 이상하게 돌고 있는 걸 감지하는 것 — 이게 실제 병목이었다. 코딩 역량보다 판단 역량에 훨씬 가깝다.

루틴 자동화 AI가 성숙할수록, 이 판단 레이어의 가치가 더 올라간다. AI가 클릭하고 옮기고 정리하는 건 기계가 한다. 그렇다면 "이 자동화가 의도대로 돌고 있는가", "이 결과를 믿어도 되는가"를 판단하는 사람이 필요해진다. 코드를 많이 아는 것과는 다른 근육이다.

AI 개발자 과정의 함정 — 무엇을 먼저 배울 것인가

요즘 "ai 개발자 과정"이라고 불리는 커리큘럼 대부분이 LLM API 호출, 프롬프트 엔지니어링, RAG 구현을 다룬다. 틀린 내용이 아니다. 그런데 Prentis 베팅이 맞다면, 그 위의 레이어 — 루틴 자동화 오케스트레이션 — 에 대한 이해가 더 빠르게 핵심 역량이 된다.

직접 봇을 몇 달 운영해보니 이게 확실해졌다. 프롬프트는 며칠이면 어느 정도 잡힌다. 진짜 어려운 건 "이 봇이 언제 잘못 돌고 있는지 어떻게 감지하는가", "실패했을 때 사이드이펙트가 무엇인가"를 구조적으로 설계하는 일이었다. 이건 AI 문법 지식보다 시스템 사고 근육에 달려 있다.

학습 순서를 이렇게 짜는 게 낫다고 본다. LLM 기초를 배우기 전에, 에러 감지와 롤백 설계, 외부 의존성 관리, 비동기 실패 처리 같은 시스템 설계 감각을 먼저 키우는 것. 그다음에 LLM이나 자동화 도구를 얹으면 훨씬 빠르게 붙는다. 순서가 거꾸로 되면 도구는 다룰 줄 알아도 문제가 생겼을 때 손을 못 댄다 — 그게 오히려 더 위험하다.

지금 바로 쓸 수 있는 시사점

채용 기준부터 손봐야 한다. "Python 잘 씀"보다 "이 자동화가 왜 틀렸는지 찾아낼 수 있음"을 더 높게 봐야 한다. 루틴 자동화 시대엔 코드 생산 속도보다 시스템 전체를 읽는 디버깅 감각이 오래간다. 면접에서 코딩 테스트 대신 "이 봇이 이상하게 동작한다, 어디서부터 파겠냐"를 물어보는 편이 훨씬 변별력이 있다.

팀 내 학습 투자는 오케스트레이션 중심으로 재설계할 것. AI 개발자 과정을 선택한다면 API 호출 문법보다 에이전트 체이닝, 실패 시나리오 설계, 자동화 감사 로그 구성을 먼저 다루는 커리큘럼을 골라야 한다. 이 세 가지 없이 AI 도구를 팀에 넣으면 아무도 책임지지 않는 블랙박스가 하나 더 생기는 꼴이다.

루틴 업무 인벤토리를 지금 적어라. 팀에서 매주 반복하는 컴퓨터 작업 목록 — 데이터 복사, 보고서 생성, 파일 이동, 상태 확인. 30분이면 나온다. Prentis류 도구가 1-2년 안에 이 목록의 상당 부분을 먹을 것이고, 목록이 있어야 도구가 나왔을 때 바로 맥락을 댈 수 있다. 없으면 도구가 나와도 어디에 쓸지 몰라서 시간을 낭비한다.

마지막으로, "개발자 1명 더"보다 "오케스트레이터 1명"을 먼저 생각해봐야 한다. 코드를 짜는 사람이 아니라, 자동화 파이프라인 전체를 설계하고 감시하고 개선하는 역할. 팀이 작을수록 이 역할이 더 높은 레버리지를 낸다.

원문: AI News & Artificial Intelligence | TechCrunch