<!doctype html>
2026년 6월 27일 | AI 최신 트렌드
GPT-5.6 Sol의 제한 공개는 모델 성능 경쟁이 이제 벤치마크 숫자만으로 끝나지 않는다는 신호처럼 보였다. 같은 흐름 안에서 로컬 우선 지식베이스, 모델 라우팅 한계 논문, 대화형 여행 예약, 공공 인허가 AI, High-NA EUV 장비까지 같이 눈에 들어왔다. 겉으로는 서로 다른 소식인데, 내가 보기에는 공통점이 하나 있었다. AI를 잘 쓰는 문제는 모델 하나를 고르는 문제가 아니라, 접근 권한·도구 표면·검증 한계·현실 데이터·하드웨어 병목을 같이 설계하는 문제로 옮겨가고 있다.
1. GPT-5.6 Sol, 성능보다 배포 방식이 먼저 보인 발표
OpenAI의 GPT-5.6 Sol 프리뷰는 Sol, Terra, Luna라는 새 계열명과 함께 나왔다. Sol은 가장 강한 모델, Terra는 비용과 성능을 맞춘 모델, Luna는 빠르고 저렴한 모델이라는 식이다. 발표에서 흥미로웠던 건 단순히 “더 똑똑해졌다”가 아니었다. max reasoning effort, ultra mode, Codex 쪽 접근, 그리고 사이버 보안 요청을 다루는 안전 스택이 함께 묶여 있었다.
특히 제한 공개 방식이 눈에 걸렸다. 고성능 모델이 나오면 예전에는 “언제 API가 열리나”부터 봤는데, 이번에는 누가 먼저 쓸 수 있는가가 제품의 일부처럼 보인다. 정부 협의, trusted partners, 계정 단위 신호, 실시간 classifier가 모델 카드 주변에 같이 붙으니, frontier model은 점점 클라우드 제품이라기보다 규제와 감사가 붙은 운영 인프라에 가까워진다.
개발자 입장에서는 이게 마냥 먼 이야기가 아니다. 모델이 강해질수록 “프롬프트를 어떻게 잘 쓰나”보다 “이 기능이 내 계정, 내 산업, 내 위험 등급에서 실제로 열리는가”가 먼저 문제가 된다. 나는 이 지점을 보면서, 앞으로의 모델 비교표에는 정확도와 가격만 아니라 preview 범위, 안전 필터의 오탐 가능성, 장시간 작업 중 중단 조건도 같이 적어야겠다고 느꼈다.
2. OpenKnowledge, 문서 편집기가 에이전트 하네스 쪽으로 붙는 흐름
OpenKnowledge는 Obsidian이나 Notion을 대체하겠다는 식의 단순 노트 앱보다, AI가 읽고 고칠 수 있는 Markdown 작업장을 만들려는 쪽에 가깝다. GitHub 설명을 보면 로컬 우선 WYSIWYG Markdown 편집기, LLM Wiki, Claude·Codex·Cursor 통합, MCP와 skills, agentic search가 한꺼번에 붙어 있다. 말만 보면 조금 욕심이 많아 보이지만, 방향 자체는 이해가 된다.
에이전트로 코드를 짜거나 문서를 고치다 보면, 결국 문제가 “채팅창에 무엇을 물을까”에서 “에이전트가 어떤 문서를 안정적으로 읽고, 어떤 파일을 사실의 기준으로 삼고, 결과물을 어디에 남길까”로 바뀐다. OpenKnowledge가 재밌는 이유도 이 지점이다. 문서 편집기와 에이전트 하네스의 경계가 흐려지고 있다. Markdown은 사람이 읽는 노트이면서 동시에 에이전트가 조작하는 상태 저장소가 된다.
다만 나는 이런 도구를 볼 때 항상 한 번 멈춘다. WYSIWYG가 예쁘다고 해서 지식베이스가 자동으로 좋아지는 건 아니고, AI 통합이 많다고 해서 검증 책임이 사라지는 것도 아니다. 오히려 중요한 건 파일 포맷이 단순한지, Git 이력이 남는지, 로컬 모델이나 다른 제공자로 갈아탈 수 있는지, 에이전트가 문서를 고쳤을 때 사람이 diff를 볼 수 있는지다. 이 네 가지가 안 잡히면 “AI-first”라는 말은 금방 포장지가 된다.
3. 모델 라우팅 논문, 여러 모델을 섞어도 같이 틀리면 끝
When Does Combining Language Models Help?는 모델 라우팅을 볼 때 꽤 불편한 질문을 던진다. 여러 모델을 섞으면 당연히 좋아질 것 같지만, 모든 모델이 같은 문제에서 같이 틀리면 router도, voting도, mixture-of-agents도 그 벽을 넘기 어렵다. 논문은 이 공통 실패율을 β로 두고, 어떤 선택 정책도 정확도 1-β를 넘을 수 없다고 정리한다.
내가 실무적으로 건진 문장은 “pairwise correlation만 봐서는 부족하다”였다. 두 모델씩 비교했을 때 오류 상관이 낮아 보여도, 실제 어려운 문제에서는 여러 모델이 같은 방식으로 무너질 수 있다. 특히 자유응답 수학이나 코드처럼 답을 열어 놓고 만들어야 하는 작업에서 이런 공통 실패가 두드러진다는 해석은, 코딩 에이전트 평가를 할 때 그대로 와닿는다.
이건 모델 라우터를 만들지 말라는 이야기는 아니다. 오히려 만들기 전에 라우팅으로 얻을 수 있는 최대 이득을 먼저 재는 습관이 필요하다는 말에 가깝다. 비용이 큰 모델 여러 개를 부르고, judge를 붙이고, fallback을 설계했는데 공통 실패율이 높으면 시스템은 복잡해졌는데 품질 상한은 별로 올라가지 않는다. 멀티모델 오케스트레이션이 유행할수록, 이런 찬물 같은 논문이 더 필요해 보인다.
4. Omio, 여행 검색이 대화형 예약으로 바뀌는 사례
Omio의 conversational travel 사례는 조금 다른 결의 소식이다. Omio는 47개국, 3,000개 이상의 운송 제공자를 연결하는 여행 플랫폼인데, OpenAI 모델을 이용해 기차·버스·페리·항공 옵션을 대화로 탐색하고 예약 가능한 흐름으로 묶고 있다. 사용자는 “로마에서 피렌체까지 가장 빠른 길” 같은 질문을 던지고, 시스템은 실제 재고와 가격, 예약 가능성을 같이 봐야 한다.
여기서 중요한 건 “여행 챗봇”이라는 말보다 대화가 곧 거래 인터페이스가 되는 구조다. 일반 검색은 사용자가 후보를 찾고, 비교하고, 다른 사이트로 이동하는 일을 계속 떠안긴다. 대화형 예약은 그 과정을 줄일 수 있지만, 대신 모델이 틀린 경로를 그럴듯하게 말하면 바로 신뢰 문제가 된다. 그래서 live inventory, verified data, booking system 연결이 핵심이다.
또 하나 눈에 들어온 건 내부 개발 흐름이다. Omio는 Codex를 개발, 테스트, 리뷰, 유지보수에 쓰고 있고, 일부 제품 개발 시간이 예전의 20% 수준으로 줄었다고 설명한다. 나는 이런 수치를 볼 때 늘 조심스럽게 읽는다. 팀마다 코드베이스와 검증 문화가 달라서 그대로 옮겨 적을 수는 없다. 그래도 고객 인터페이스와 내부 개발 루프가 동시에 AI-native로 바뀌는 사례라는 점은 꽤 선명하다.
5. DeepMind와 영국 주택 심사, 행정 AI는 “최종 판단권”이 핵심
Google DeepMind의 영국 주택 인허가 AI prototype은 공공 서비스 쪽 사례로 볼 만했다. 영국 정부, Google Cloud, Faculty, 지역 planning authority가 Gemini 기반 도구를 만들어 주택 관련 신청 처리 시간을 절반으로 줄이는 걸 목표로 한다. 적용 대상은 loft conversion이나 home extension처럼 반복성이 높은 householder planning application이다.
구체 기능은 꽤 현실적이다. 기존 PDF와 신청 자료에서 필요한 정보를 뽑고, 지역 정책을 찾아 인용하고, 상담 의견을 요약하고, planning assessment report 초안을 만든다. 딱 모델이 잘할 법한 문서 처리 업무다. 동시에 발표는 담당 planning officer가 최종 판단권을 유지한다고 강조한다. 나는 이 부분이 가장 중요하다고 봤다.
공공 행정에 AI를 넣을 때는 “얼마나 자동화하나”보다 “책임 소재가 어디에 남나”가 먼저다. 감사 trail이 남고, 사람이 줄 단위로 검토하고, 정책 인용을 확인할 수 있어야 한다. 이 구조가 없으면 행정 AI는 처리 속도를 올리는 대신 민원과 불신을 같이 키울 수 있다. 반대로 이 구조가 잡히면, AI는 담당자의 판단을 대체하기보다 서류 더미를 정리하는 강한 보조 도구가 된다.
6. ASML High-NA EUV, AI 인프라는 칩 제조 장비에서 시작된다
MIT Technology Review의 ASML High-NA EUV 기사는 AI 인프라를 한 단계 더 아래로 끌고 내려간다. GPU가 부족하다, 데이터센터 전력이 부족하다는 말은 자주 나오지만, 그 GPU를 만들기 위한 노광 장비 병목은 상대적으로 덜 체감된다. ASML의 새 High-NA EUV 장비는 한 대에 4억 달러 수준이고, 더 촘촘한 회로를 찍기 위해 8nm 해상도와 더 높은 numerical aperture를 목표로 한다.
이 장비 이야기가 AI 트렌드에 들어와야 하는 이유는 간단하다. 모델이 커지고, inference가 늘고, 에이전트가 더 많은 토큰을 쓰면 결국 칩 수요가 폭발한다. 그런데 칩 공급은 코드처럼 복사되지 않는다. 장비 한 대의 가격, 설치 난이도, Zeiss 광학계, ASML 독점 구조, 중국 수출 통제, Intel과 TSMC의 도입 전략이 모두 AI 서비스 단가에 간접적으로 붙는다.
나는 이런 기사를 볼 때 “모델 출시 속도와 제조 장비 속도가 서로 다른 시간표로 움직인다”는 점을 다시 느낀다. 모델은 몇 달 단위로 바뀌는데, 리소그래피 장비와 팹 투자는 몇 년 단위다. 그래서 AI 인프라 논의는 GPU 이름표에서 멈추면 부족하다. 앞으로는 냉각, 전력, 패키징, 메모리, 노광 장비까지 같이 봐야 실제 병목이 보인다.
한 줄로 접어 본 흐름
여섯 소식을 한데 놓고 보니, AI 업계의 무게중심은 모델 자체에서 모델 주변의 운영 구조로 더 확실히 이동하고 있다. GPT-5.6 Sol은 접근 권한과 안전 스택을 같이 보여 줬고, OpenKnowledge는 문서 편집기를 에이전트 작업장으로 바꾸려 한다. 모델 라우팅 논문은 여러 모델을 섞어도 공통 실패를 피하지 못하면 상한이 낮다고 경고한다. Omio와 DeepMind 사례는 AI가 실제 업무와 행정 흐름에 붙을 때 데이터 검증과 책임 구조가 필요하다는 걸 보여 준다. ASML 이야기는 그 모든 소프트웨어 흐름 밑에 아주 비싸고 느린 물리 인프라가 깔려 있다는 사실을 다시 확인시킨다.
그래서 나는 이번 묶음을 “더 강한 모델이 나왔다”보다 “강한 모델을 어디에, 어떤 권한으로, 어떤 검증과 하드웨어 위에 올릴 것인가”로 읽었다. 이 질문에 답하지 못하면 좋은 모델을 가져와도 제품은 흔들리고, 답을 잘 만들면 모델 하나가 바뀌어도 시스템은 오래 간다.