챗GPT 탭을 닫고 AI 에이전트를 직접 돌린 기록

OpenAI 공백이 건드린 진짜 질문

Fidji Simo가 OpenAI 2인자 자리를 내려놨다. 병가가 예상보다 길어졌고, 결국 복귀 대신 퇴임을 택했다. IPO를 앞두고 Anthropic과 엔터프라이즈 시장을 두고 경쟁해야 하는 시점이라 타이밍이 묘하다는 평이 많다.

이 뉴스가 우리 팀 실무에 주는 직접적인 충격은 솔직히 0에 가깝다. 모델은 계속 나올 거고, API는 열려 있다. C-suite가 누가 앉든 GPT-4o가 갑자기 멍청해지진 않는다.

그런데 이 뉴스가 흥미로운 지점은 따로 있다. OpenAI가 내부 공백을 채우는 동안, 그 아래에서 실제로 모델을 업무에 붙인 팀과 그렇지 않은 팀의 격차가 조용히 벌어지고 있다는 사실이다.

핵심부터 말하면: 챗GPT에서 수동으로 하던 것을 API 호출로 옮기고 cron으로 자동 실행하는 것, 이게 에이전트의 시작이다. 단, 막상 해보면 "프롬프트를 잘 쓰면 다 된다"는 생각이 가장 먼저 발목을 잡는다. 그 함정이 왜 생기는지, 실제로 어떻게 풀었는지를 아래에 적었다.

챗GPT 활용법의 현실적인 천장

챗GPT가 대중화된 지 3년이 넘었다. 그런데 대부분의 팀에서 챗GPT 활용법은 아직 비슷한 패턴에 머무른다. 브라우저 탭 열고, 질문 타이핑하고, 결과 복붙. 조금 더 나아가면 프롬프트를 정교하게 다듬거나 커스텀 GPT를 만들어 공유하거나, 회사 슬랙에 GPT 봇을 붙이는 정도다.

틀린 방향이 아니다. 이것도 분명한 생산성 향상이다. 하지만 거기서 멈추면 AI는 결국 "내가 탭을 열어야 시작하고, 닫으면 멈추는 도구"에 그친다. 내가 없으면 아무것도 안 된다. 사람이 병목이다.

더 실질적인 문제가 있다. 수동 챗GPT 활용은 스케일이 안 된다. 하루에 한 건 하던 작업을 열 건으로 늘리려면 사람이 열 배 더 앉아 있어야 한다. 에이전트는 그 병목을 끊는다. 내가 자고 있어도 돌아가는 구조를 코드로 만드는 것. 그것뿐이다.

에이전트가 뭔지 — SF 없이 설명하면

"AI 에이전트"라는 말에 자율 로봇 이미지가 자동으로 따라붙는 게 문제다. 업계 마케팅이 그쪽으로 과하게 달려간 탓이다. LangChain이나 CrewAI 데모를 보면 AI가 스스로 계획을 세우고 실행하는 것처럼 묘사된다. 현실은 다르다.

실제 실무에서 쓰는 에이전트는 훨씬 단순하다. LLM 호출 하나를 파이프라인 안에 넣고, 그 출력으로 다음 액션을 결정하는 스크립트. 파이썬 50줄이면 충분하다. 프레임워크가 필요하지 않다.

구체적으로 콘텐츠 자동화를 예로 들면: DB에서 미처리 주제를 조회하고 → LLM을 호출해 본문을 생성하고 → 결과물이 품질 기준을 통과하면 DB에 저장하고 → 슬랙이나 디스코드로 알림을 보낸다. 이 흐름이 매일 새벽 cron으로 자동 실행되면, 나는 자고 있어도 된다. 이미 에이전트다.

에이전트가 복잡해지는 건 루프가 생길 때다. 생성 결과를 검수 LLM에 다시 넣고, 통과 여부에 따라 재시도하거나 다음 단계로 넘어가는 것. "멀티 스텝 에이전트"라고 부르지만 코드로 보면 if/else와 while 루프다. 어렵지 않다. 개념이 낯설 뿐이다.

직접 붙이면서 부딪힌 것들

우리 팀이 이 구조를 실제로 운영하면서 배운 것들. 세 가지 함정이 있었다.

첫 번째는 프롬프트 신뢰다. 초기에는 시스템 프롬프트에 "1500자 이상으로 작성해줘"라고 적는 것만으로 분량을 믿었다. 몇 달 동안 그냥 그렇게 했다. 당연히 안 됐다. 모델은 400자짜리를 뱉고도 지시를 따랐다고 생각한다. 결국 코드 게이트를 만들었다. 공백 제거 후 글자 수를 재고, 미달이면 재생성 1회, 그래도 미달이면 발행을 건너뛴다. 이 변경 이후 분량 문제가 사라졌다. 프롬프트 부탁이 아니라 코드 측정이 유일한 해결책이었다.

두 번째 함정은 더 찾기 어려웠다. DB 연결 끊김이다. LLM 호출이 길어지는 날 파이프라인이 중간에 조용히 죽는 경우가 생겼다. 오류 로그도 제대로 나오지 않았다. 원인은 MySQL의 기본 idle timeout이 300초(5분)라는 것이었다. LLM 호출이 5분을 넘기면 DB 커넥션이 끊기고, 그 다음 쿼리에서 Lost connection 에러로 프로세스가 폭사한다. 해결책은 공통 헬퍼를 만드는 것이었다. 쿼리 직전마다 ping으로 커넥션 상태를 확인하고, 끊겼으면 자동으로 재연결한다. 이런 게 블로그 튜토리얼에 나오지 않는 실전 이슈다.

세 번째는 비용 설계다. 처음엔 모든 호출에 같은 모델을 썼다. 대량 생성에 고성능 모델을 쓰면 비용이 금방 올라간다. 지금은 대량 생성은 Haiku급 소형 모델, 검수와 판단이 필요한 단계는 Sonnet급 이상으로 나눠 쓴다. 이 분리만으로 동일 품질에서 비용이 절반 이하로 내려갔다. 도구의 문제가 아니라 설계의 문제다.

그리고 넷이라면 관찰 가능성이다. 파이프라인은 실제로 돌기 시작하면 반드시 어딘가에서 조용히 실패한다. 발행이 안 된 이유가 LLM 오류인지, 품질 미달인지, DB 문제인지 — 로그 없이는 알 수 없다. 최소한 성공·실패 건수와 스킵 이유를 디스코드 채널에 쌓아두는 것만으로 운영이 완전히 달라진다. 눈에 보이는 게 없으면 개선도 없다.

OpenAI 공백에서 읽어야 할 신호

Simo 퇴임 뉴스로 다시 돌아오면, 실무자가 읽어야 할 신호가 하나 있다.

OpenAI는 점점 "플랫폼"이 되려 한다. API 위에 기업들이 자기 파이프라인을 얹는 구조다. 그 플랫폼 회사의 C-suite가 흔들리는 동안, 자기 에이전트 레이어를 직접 소유한 팀은 흔들리지 않는다. 모델 공급사가 바뀌어도 — OpenAI에서 Anthropic으로, 혹은 반대로 — 교체 비용이 API 호출 한 줄 수정이면 끝난다.

반대로 ChatGPT 탭에만 의존하는 팀은 플랫폼 정책 변화에 그냥 쓸린다. 사용량 제한이 강화되거나 특정 기능이 유료 플랜으로 올라가면 그때마다 수동으로 대응해야 한다.

소규모 팀일수록 자체 구축의 이점이 크다. 대기업은 벤더 계약과 보안 검토에 몇 달이 걸린다. 작은 팀은 오늘 오후 스크립트 하나를 짜서 내일부터 실제로 돌릴 수 있다. 이 민첩성이 지금 이 시점의 실질적인 경쟁 우위다.

지금 당장 시작하는 법

가장 빠른 시작점은 단순하다. 지금 매주 3번 이상 반복하는 작업 하나를 고른다.

이메일 초안, 회의록 요약, 데이터 분류, 콘텐츠 아이디어 — 무엇이든 상관없다. 챗GPT 탭에서 수동으로 하고 있는 작업이 있다면, 그게 자동화 1호 후보다.

시작은 이렇다. API 키를 발급받는다(OpenAI나 Anthropic 모두 첫 달 무료 크레딧이 있다). 파이썬 스크립트로 API 호출 하나를 만들고, 결과를 파일이나 슬랙으로 내보낸다. cron에 등록해서 주기적으로 실행한다. 여기까지가 진짜 1단계다. 멀티 스텝 파이프라인, 재시도 로직, 조건 분기 — 이건 파이프라인이 실제로 돌고 나서 붙여도 늦지 않다.

하나만 처음부터 챙겨라. 품질 게이트다. 출력 결과를 코드로 검증하고, 기준을 어겼을 때 재시도할지 스킵할지를 명시적으로 처리한다. "꼭 지켜줘"를 프롬프트에 적는 것으로는 부족하다. 그 경험을 직접 하는 건 꽤 허탈하다. 가능하면 건너뛰는 게 낫다.

모델은 계속 좋아진다. 그 모델을 자기 파이프라인 안에 넣은 팀과 그렇지 않은 팀의 격차는 지금 이 순간에도 조용히 벌어지고 있다.

원문: AI News & Artificial Intelligence | TechCrunch