AI가 뉴스레터 초안을 써줬는데, 읽어보니 전부 다시 써야 했습니다. 더 좋은 프롬프트를 쓰면 나아질까요? 더 똑똑한 모델을 쓰면 될까요? 개발자이자 뉴스레터 운영자인 Jason Yingling은 둘 다 아니라고 말합니다. 문제는 모델이 아니라 단위였습니다.

Jason Yingling이 자신의 블로그에 AI 업무 활용 경험을 정리한 글을 발표했습니다. AI에게 “뉴스레터를 써줘”라고 시켰을 때는 항상 실패했지만, “30개 링크를 5개 주제로 분류해줘”라고 시켰을 때는 잘 됐습니다. 그 차이를 파고들었더니, AI가 잘 작동하는 작업과 그렇지 않은 작업을 가르는 구조적인 이유가 있었습니다.

출처: Agentic Engineering for All: Finding Repeatable Work in Any Job – Jason Yingling

AI는 왜 큰 작업에서 실패하는가

LLM은 확률적으로 작동합니다. 다음 토큰을 생성할 때마다 확률적으로 선택하고, 그 선택이 쌓입니다. 작업 범위가 넓을수록 중간에 내려야 하는 암묵적 판단이 많아지고, 각 판단마다 의도에서 조금씩 벗어날 가능성이 생깁니다.

“뉴스레터를 써줘”라고 하면, AI는 어떤 톤으로 열지, 무엇을 포함할지, 어떻게 닫을지를 수백 번 결정합니다. 그 누적된 이탈이 “AI가 쓴 것처럼 들리는” 결과물을 만들어냅니다. 반면 “이 링크들을 주제별로 묶어줘”라고 하면, 수용 가능한 출력의 범위가 좁아서 확률적 특성이 오히려 강점이 됩니다. 구조가 없는 입력을 패턴으로 읽어내는 건 기존 자동화 도구가 못 하던 일이고, LLM이 진짜 잘 하는 일입니다.

반복성이 숨어 있는 곳

“내 일은 자동화할 수 없어”라고 생각할 때, 보통은 일 전체를 상상하고 있습니다. 그런데 전체 일이 반복되는 경우는 드뭅니다. 반복되는 건 그 판단 작업을 둘러싼 스캐폴딩입니다.

정보가 들어오는 수집 단계, 그걸 정리하는 분류 단계, 압축하는 요약 단계, 모양을 잡는 포맷팅 단계, 다음 사람에게 넘기는 패키징 단계. 이 단계들은 역할마다 형태가 다르지만, 같은 역할 안에서는 매주 비슷하게 반복됩니다. 주간 보고서는 매번 같은 구조, 회의 요약은 매번 같은 형식, 프로젝트 브리프는 매번 같은 항목들. 실제 판단이 필요한 작업은 이 스캐폴딩의 한가운데에 있고, 스캐폴딩이 바로 레버리지가 있는 곳입니다.

어느 작업에 AI를 써야 하는가: 2×2 매트릭스

Yingling이 제안하는 도구는 간단합니다. 업무의 각 작업을 두 축으로 놓아보는 겁니다.

• 수평축(반복성): 이 작업이 자주 반복되는가, 일회성인가
• 수직축(출력 구조): 결과물의 형태가 정해져 있는가, 매번 다른가

네 칸이 나오고, 각 칸마다 AI 활용 방식이 달라집니다.

우상단 — 먼저 자동화할 곳: 반복성 높고, 출력 구조도 정해진 작업입니다. 링크 주제 분류, 회의 요약, 이메일·Slack·Jira 인바운드 정리가 여기 해당합니다. 결과물을 검증하기 쉽고, 반복 횟수가 많아서 시간 절감 효과가 빠르게 쌓입니다. 시스템을 만들 가치가 가장 높은 칸입니다.

좌상단 — 검토를 강화하며 활용: 출력은 정해져 있지만 빈도가 낮습니다. AI를 쓸 수 있지만 속도 이득이 작고 검토 부담이 상대적으로 높습니다. 우상단을 먼저 정비한 뒤에 손을 댈 영역입니다.

우하단 — 대화 상대로 활용: 반복은 되지만 출력이 매번 달라지는 작업입니다. 헤드라인 아이디어, 첫 문장 후보, 열린 브레인스토밍이 여기에 속합니다. AI가 시스템이 아닌 생각 파트너 역할을 합니다.

좌하단 — 사람이 해야 할 곳: 반복성도 낮고, 출력도 정해지지 않은 작업입니다. 새로운 프로젝트의 전략적 방향 설정, 오리지널 크리에이티브 기획이 여기에 있습니다. AI를 여기에 던지면 어디서나 봤을 법한 결과물이 나옵니다. “AI가 안 통한다”는 경험의 대부분은 이 칸에 AI를 시도한 경우입니다.

작게 쪼갤수록 시스템이 개선된다

2×2로 우상단 후보를 찾았다면, 그걸 그대로 AI에게 맡기는 건 아직 이릅니다. “좁은 작업”처럼 보여도 그 안에 암묵적 판단이 생각보다 많습니다. 핵심은 그 작업을 더 작은 단위로 쪼개서, 각각에 명확한 입력과 검증 가능한 출력을 붙이는 겁니다.

Yingling이 직접 만든 콘텐츠 파이프라인 ‘Kessel Run’이 그 예입니다. 글쓰기 전 과정을 아이디어 정박 → 훅 선택 → 구조 설계 → 섹션 초안 → 보이스 개인화 → 최종 교열의 단계로 나누고, 각 단계에 사람의 검토와 입력을 넣었습니다. 어느 단계도 혼자서 글 전체를 쓰려 하지 않고, 그게 시스템이 작동하는 이유입니다.

단위가 작아지면 검증도 빨라집니다. “이번 뉴스레터가 잘 됐나?”는 일주일 뒤에나 알 수 있지만, “이 링크가 올바른 클러스터에 들어갔나?”는 5초면 확인됩니다. 피드백 루프가 짧아지면 어느 프롬프트가 견고한지, 어느 단계가 더 명확한 기준이 필요한지를 빠르게 파악하고 고칠 수 있습니다. 시스템이 쓸수록 나아집니다.

에이전트까지 가야 하는가, 복잡도를 맞추는 법

Yingling은 AI 활용에 대략적인 사다리를 제안합니다. 프롬프트(일회성 질문) → 스킬(반복 가능한 절차 패키징) → 워크플로우(스킬들의 연결) → 에이전트(자율 판단과 도구 사용 추가). 위로 올라갈수록 능력이 커지지만 실패 가능성도 커집니다.

에이전트는 아래 단계들이 잘 정의되어 있을 때 비로소 제 역할을 합니다. 그렇지 않으면 버그를 고치다가 프로덕션 데이터베이스를 날리는 에이전트 같은 사례가 나옵니다. 복잡도는 기술이 허락하는 수준이 아니라, 작업이 실제로 요구하는 수준에 맞춰야 합니다.

이 프레임워크가 흥미로운 건 “AI를 더 많이 써라”가 아니라는 점입니다. 판단이 필요한 진짜 작업에 더 많은 시간을 쓰기 위해, 그 주변 스캐폴딩을 AI에게 넘기자는 이야기입니다. 2×2가 Yingling에게 준 건 AI 활용량이 아니라 글을 쓸 여유였습니다.