모든 AI 모델 이름을 외우지 마세요

새 모델이 나올 때마다 비슷한 질문이 반복됩니다.

"지금 제일 좋은 모델이 뭔가요?"

"이제 어느 정도까지 자동화할 수 있나요?"

"AGI는 언제 오는 건가요?"

질문 자체는 자연스럽습니다. 문제는 이 질문들이 대부분 너무 큰 단위로 묶여 있다는 점입니다. 모델 이름 하나, 벤치마크 점수 하나, AGI 타임라인 하나로는 이번 주에 무엇을 만들고, 무엇을 맡기고, 무엇을 아직 사람이 검증해야 하는지 결정하기 어렵습니다.

이번 주에 AI가 제대로 처리할 수 있는 작업은 어디까지 넓어졌을까?

AI 빌더에게 가장 필요한 덕목은 아마 "빠르게 버리는 능력"일 것입니다.

왜 모델 카탈로그만으로는 부족할까

모델 카탈로그는 유용합니다. 어떤 모델이 코딩에 강한지, 어떤 모델이 긴 컨텍스트를 잘 다루는지, 어떤 모델이 비용 대비 효율적인지 빠르게 비교할 수 있기 때문입니다.

하지만 무수히 많이 업데이트 되는 카탈로그에는 한계가 있습니다.

첫째, 수명이 짧습니다. 한 분기만 지나도 상위권 모델의 이름이 바뀝니다.

둘째, 실제 처리하는 업무 단위와 맞지 않습니다. 벤치마크에서 높은 점수를 받은 모델이 곧바로 팀의 운영 워크플로우를 안정적으로 대체하는 것은 아닙니다.

셋째, 실패의 원인을 완벽히 규명하지 못합니다. 모델이 "잘한다"는 말과 "끝까지 맡겨도 된다"는 말은 엄연히 다른 개념입니다.

즉, 중요한 것은 "어떤 모델이 1등인가"가 아닙니다.

중요한 것은 이겁니다.

어떤 범위의 작업까지, 어떤 신뢰도로, 어떤 비용에, 어떤 운영 환경 안에서 맡길 수 있는가?

AI 프론티어가 매번 정답이 될 순 없습니다.

AI frontier라는 말을 들으면 흔히 하나의 최첨단 기술 정점을 떠올립니다.

가장 높은 점수, 가장 큰 모델, 가장 최신 발표를 생각하기 쉽습니다.

하지만 빌더 관점에서 frontier의 의미는 조금 다릅니다.

• 빌더가 방향을 제시했을때 AI가 끝까지 완수 할 수 있는 능력
• AI가 초안은 완벽히 만들지만 중간에 무조건 사람 손이 타는 작업

이 둘의 경계선을 주목해야 합니다. 어떤 작업은 모델 업데이트 하나로 갑자기 자동화 가능해지고, 어떤 작업은 여전히 같은 지점에서 깨집니다. 또 어떤 작업은 데모에서는 잘 되지만 실제 운영에서는 로그, 권한, 데이터 품질, 예외 케이스, 비용 때문에 실패합니다.

그래서 빌더는 AI 프론티어를 네 가지로 나누어 봐야합니다.

1. 작업의 범위 - AI가 한번에 얼마나 오래 끌고 갈 수 있는가?
2. 효율성 - 사례 몇개만 보여줘도 곧바로 따라 하는가?
3. 작업 단가 - 한 번 돌려서 진짜 쓸 만한 결과 하나 얻는데 얼마 드는가?
4. 도구 호출 안정성 - API 등 Tool를 필요로 할때 정확히 호출하고 결과를 처리할 수 있는가?

1. 작업의 범위

첫 번째 항목은 작업 범위입니다.

여기서 작업 범위는 단순히 모델이 오래 대답할 수 있다는 뜻이 아닙니다. 사람이 10분, 1시간, 반나절, 하루를 써야 끝낼 수 있는 작업을 모델이 어느 정도 신뢰도로 끝까지 마무리할 수 있는지를 뜻합니다.

예를 들어 "뉴스 기사 5개 요약하기"와 "이번 주 AI 인프라 뉴스에서 제품화 가능한 신호만 골라 뉴스레터 초안까지 작성하기"는 전혀 다른 작업입니다. 전자는 짧은 변환 작업이고, 후자는 탐색, 선별, 판단, 문체 통일, 출처 검증이 들어간 긴 작업입니다.

모델의 능력을 "사람이 걸리는 작업 시간"으로 환산하면, 빌더가 체감하는 자동화 가능 범위와 훨씬 가까워집니다.

빌더가 숙지해야 할 질문은 이겁니다.

이 워크플로우는 아직 10분짜리 작업인가, 아니면 이제 1시간짜리 작업까지 묶어서 맡길 수 있는가?

이 경계가 움직이는지 면밀히 살펴야 합니다. 이전에는 사람이 단계마다 확인해야 했던 워크플로우를 하나의 에이전트 실행 단위로 묶을 수 있습니다.

반대로 아직 작업 범위가 충분히 늘어나지 않은 영역에서는, 무리하게 전체 자동화를 설계하기보다 무조건 중간에 검증 하는 지점을 만들어 놔야합니다.

2. 효율성 — 처음 보는 문제를 얼마나 잘 푸는가

두 번째 항목은 효율성입니다.

모델이 이미 많이 본 문제를 잘 푸는 것과, 처음 보는 패턴을 적은 예시만 보고 풀어내는 것은 다릅니다. 빌더에게 중요한 것은 후자입니다. 실제 업무에는 항상 새로운 문서 양식, 사내 용어, 예외 케이스, 도메인 특화 규칙이 등장하기 때문입니다.

ARC Prize는 AGI를 단순히 "경제적으로 가치 있는 일을 많이 자동화하는 시스템"으로 보지 않고, 인간 수준의 학습 효율성에 가까워지는 시스템으로 정의합니다. ARC-AGI가 측정하려는 것도 축적된 지식이 아니라, 제한된 예시에서 새로운 문제에 적응하고 일반화하는 능력입니다.

이 관점은 빌더에게 중요합니다.

모델이 공개 벤치마크에서 높은 점수를 받더라도, 빌더가 내놓은 서비스의 데이터 구조와 사용자 맥락을 처음 봤을 때 같은 품질로 동작한다는 보장은 없습니다.

특히 한국어 업무 문서, 로컬 규제, 조직 내부 프로세스, 특정 직무의 도메인처럼 공개 데이터에 충분히 노출되지 않은 영역에서는 효율성이 바로 가장 큰 병목이 됩니다.

그래서 빌더가 던져야 할 질문은 이겁니다.

이 모델은 우리 도메인의 컨텍스트를 몇 개의 예시만 보고 안정적으로 따라오는가?

이 부분은 아직 사람이 우위에 있는 영역 같습니다.

모델이 공개된 데이터를 잘 분석하는 것은 누구나 알고 있습니다.

반대로 조직 내부의 맥락을 구조화하고, 좋은 예시를 만들고, 실패 케이스를 알맞은 피드백 루프로 돌리는 일은 여전히 빌더가 가질 수 있는 유니크한 포인트입니다.

3. 작업 단가

세 번째 항목은 작업 단가입니다.

AI 비용을 이해할 때 단순히 토큰 가격을 봐선 안됩니다.

아래 비용도 고려 하셔야 합니다.

• 입력 토큰 비용
• 출력 토큰 비용
• 검색과 API 호출 비용
• 재시도 비용
• 사람이 검수하는 비용
• 실패했을 때 되돌리는 비용

빌더에게 중요한 것은 "모델 호출 한 번의 가격"이 아니라,

"고객에게 내놓을 수 있는 아웃풋 한 단위를 만드는 총비용" 입니다.

Sam Altman은 2025년 글에서 같은 수준의 AI를 사용하는 비용이 약 12개월마다 10배씩 낮아지고 있으며, GPT-4에서 GPT-4o 사이 토큰 가격이 크게 낮아졌다고 설명했습니다.

Stanford HAI의 2026 AI Index도 생성형 AI가 매우 빠른 속도로 확산되고 있으며, 소비자들이 무료 또는 저비용 AI 툴에서 큰 가치를 얻고 있다고 주장합니다.

이 항목이 중요한 이유는 간단합니다.

어제는 경제성이 맞지 않던 워크플로우가, 비용이 한 자리 내려가면 갑자기 제품화 가능한 기능이 됩니다. 반대로 겉보기에는 저렴해 보여도 재시도와 검수 비용이 높으면 운영에서는 비싼 기능이 됩니다.

빌더가 봐야 할 질문은 이겁니다.

이 자동화는 토큰 기준으로 싼가, 아니면 최종 결과물 기준으로 싼것인가?

좋은 AI 제품은 모델 호출 비용을 줄이는 데서 끝나지 않습니다.

실패율을 낮추고, 검수 시간을 줄이고, 재사용 가능한 중간 산출물을 남겨서 최종 결과 한 단위의 비용을 낮추는 것 입니다.

4. 도구 호출 안정성 — 데모가 아닌 운영 환경에서 버티는가?

네 번째 항목은 도구 호출 안정성입니다.

최근 AI 제품은 단순 채팅에서 벗어나고 있습니다. 파일을 읽고, 검색을 하고, 데이터베이스를 조회하고, 코드를 실행하고, 슬라이드를 만들고, 업무 도구 안에서 액션을 수행합니다.

이 변화는 AI를 "단순 답변 툴"에서 "업무 실행 툴"로 바꿔줍니다.

하지만 여기서 병목이 생깁니다.

모델이 좋은 답을 아는 것과, 여러 도구를 순서대로 호출해 실패 없이 끝까지 실행하는 것은 다릅니다.

권한이 없을 수 있고, API 응답이 바뀔 수 있고, 데이터가 비어 있을 수 있고, 중간 결과가 틀릴 수 있습니다. 운영 환경에서는 이런 작은 실패들이 곧 신뢰도 + 안정성 문제로 이어집니다.

어제 포스트 했던 블로그에서 언급 했던 것처럼 Anthropic은 금융 서비스용 에이전트 템플릿을 공개하면서, AI는 점점 더 업무 워크플로우 일부가 되어간다는 것을 보여주고 있습니다.

다만 빌더가 확인해야 할 것은 "가능하다"가 아닌 "반복 실행해도 깨지지 않는다"입니다.

빌더가 고려해야 할 질문은 이겁니다.

이 에이전트는 성공 사례 하나를 보여주는가, 아니면 실패 케이스까지 포함해 운영 가능한가?

도구 호출 안정성은 AI 제품 출시에 있어 매우 중요한 척도입니다. 이 한계를 넘지 못하면 데모가 아무리 좋아도 팀의 핵심 워크플로우에는 절대 들어오지 못합니다.

한 눈에 정리하자면

"이번 주에는 어떤 모델이 1등인가?"보다

"이번 주에는 어느 항목이 중요해졌는가?"가 빌더에게 더 실용적인 질문입니다.

AGI 타임라인보다 중요한 것

AGI가 언제 오는지는 아무도 모릅니다.

Dario Amodei는 AI가 생물학 연구의 속도를 크게 높여 50년의 발전을 5~10년으로 줄일 수 있다고 주장합니다.

Leopold Aschenbrenner는 2027년 전후 AGI 수준 시스템이 가능하다고 주장합니다.

이런 전망은 물론 중요합니다.하지만 당장 결정을 내려야하고 작업을 해야하는 빌더에게는 조금 더 좁은 범위의 질문이 필요합니다.

AGI가 도달해도 나의 제품은 과연 가치 있을까?

이 질문은 사실 대답하기 너무 어렵습니다.

예를 들어 단순히 "요즘 제일 좋은 모델을 연결한 Wrapper"는 오래 버티기 어렵습니다.

모델이 바뀌면 차별화가 사라지기 때문입니다.

반대로 좋은 데이터 구조, 검증 루프, 사용자 맥락, 업무별 실패 케이스, 운영 가능한 도구 호출 레이어를 쌓는 제품은 AGI가 와도 충분히 가치가 있는 제품일 수도 있습니다.

저는 현실적인 빌더가 승산이 있다고 생각합니다. 그 누구보다 냉정할 수 있어야 하며, 제품에 대한 고찰과 고민 그리고 실행은 항상 동반 되어야 합니다.

빌더에게 가장 큰 리스크는 모델은 이미 어나더레벨이 되었는데도, 지난 분기의 가정으로 제품을 계속 만드는 것입니다.

빌더 포지셔닝

특히 국내 빌더에게는 유니크한 기회가 있습니다.

모델 접근성은 빠르게 평준화되고 있습니다. Claude, ChatGPT, Gemini 같은 frontier 툴은 모든 국내 사용자에게 열려 있습니다.

더 이상 "좋은 모델을 먼저 쓰는 것"만으로 큰 차이를 만들기는 어렵습니다.

한국어 업무 컨텍스트, 조직 프로세스, 한국 시장의 직무별 데이터, 한국 사용자에게 맞는 알맞은 큐레이션입니다. 이것이 한국 빌더가 가져갈 수 있는 차별화입니다.

구체적으로:

• 국내 도메인 데이터를 좋은 구조로 정리하기
• 직무별 반복 업무를 작은 실행 단위로 쪼개기
• 모델 실패 케이스를 지속적으로 수집하기
• 사람이 검증해야 하는 지점을 제품 안에 설계하기
• 글로벌 AI 신호를 한국 사용자에게 맞게 재해석하기

모델은 평준화됩니다. 하지만 컨텍스트는 평준화되지 않습니다.

이를 잘 이해하는 것이 빌더에게 가장 중요한 덕목이 아닐까 합니다.

마치며

모델 이름을 외우고 써본다는 것만으로는 부족합니다.

모델 이름은 항상 바뀔겁니다.

대신 AI 흐름을 읽고 파악하고, 혼돈 속에서 AI의 한계와 가능성을 읽을 수 있는 능력은 그 누구보다 빌더에게 중요한 자산으로 남지 않을까 합니다.

파도에 휩쓸리지 마시고, 타시길 바라면서 이 글을 마칩니다.

참고자료

1. METR, Measuring AI Ability to Complete Long Tasks, 2025. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/
2. ARC Prize Foundation, ARC-AGI Benchmark. https://arcprize.org/arc-agi
3. Sam Altman, Three Observations, 2025. https://blog.samaltman.com/three-observations
4. Stanford HAI, AI Index Report 2026. https://hai.stanford.edu/ai-index/2026-ai-index-report
5. Anthropic, Claude for Financial Services / Finance Agents. https://www.anthropic.com/news/finance-agents
6. Dario Amodei, Machines of Loving Grace, 2024. https://www.darioamodei.com/essay/machines-of-loving-grace
7. Leopold Aschenbrenner, Situational Awareness: The Decade Ahead, 2024. https://situational-awareness.ai/