10월 15일 AI 뉴스: 더 많이 만드는 AI, 검토는 어떻게 따라갈까
목차 · 원하는 부분으로 이동
10월 14일 수집분 · 원문·제품 문서 확인: 2026년 10월 15일 KST. 발표와 개인 경험담을 구분했으며 직접 측정한 성능 보고서는 아닙니다.
1. Gemini 4 Argon: 확대된 이용 경로를 확인할 때
사진 속 책상이 레이싱 코스로. 실제 제작에는 여러 도구와 에이전트가 함께 쓰였다.
쉽게 풀어보기 · 이용 조건과 주의점
공식 발표: 2026년 10월 13일 · 모델 문서 확인: 10월 15일
쉽게 풀면: 같은 건물의 서로 다른 출입구다. 대화창에서 쓰는 길, 개발 도구에서 쓰는 길, 내가 만든 서비스가 API로 호출하는 길이 따로 있다. API는 프로그램끼리 요청과 응답을 주고받는 연결 창구다. 같은 Argon을 쓰더라도 앱 구독료에 API 사용료까지 포함되는 것은 아니다. 예를 들어 개인 앱에서 질문하는 일과 고객용 요약 기능을 만드는 일은 먼저 확인할 요금 조건이 다르다.
Google은 Gemini 4 Argon을 개발자·기업·일반 이용자에게 확대한다고 발표했다. 발표가 안내하는 주요 경로는 다음과 같다.
- Gemini 앱·검색 AI Mode: Google AI Pro 또는 Ultra 구독자
- Antigravity: Google AI Ultra 구독자
- 서비스에 연결하는 Gemini API: 유료 등급
API의 도입 요금은 100만 입력 토큰당 2달러, 출력 토큰당 10달러다. 발표에 따르면 2026년 11월 30일 도입 기간이 끝난 뒤에는 각각 4달러와 20달러가 적용된다. Google 공식 발표
‘최대 100만 토큰’이라는 문구도 조건을 함께 봐야 한다. 현재 모델 문서의 기본 동기식 출력 한도는 65,536토큰이다. 더 긴 출력에는 long decode가 필요하고, 입력과 출력을 합친 전체 한도는 1,048,576토큰이다. Argon 자체의 출력 형식은 텍스트이며 이미지·오디오 생성은 지원하지 않는다. Gemini API 모델 문서
Google이 공개한 책상 사진 기반 레이싱 게임도 여러 도구를 연결한 시연이다. Antigravity의 여러 에이전트가 반복 검토하면서 Blender MCP, Nano Banana, Three.js 등을 사용했다. 공식 시연 설명
읽는 기준: 긴 코딩 작업을 맡길 후보가 늘었다. 다만 시연의 완성도를 내 작업의 성공률로 옮겨 생각하지 말자. 같은 작은 과제로 결과, 총비용, 실패 뒤 복구 시간을 비교하는 편이 유용하다.
2. Anthropic Scion: 코드가 늘자 관리 기반을 다시 만들었다
코드 병합량이 급증하자 검토·테스트를 받쳐 줄 관리 기반도 바꿨다.
쉽게 풀어보기 · 이용 조건과 주의점
공식 기술 글: 2026년 10월 13일
쉽게 풀면: 주방이 빨라져도 음식이 바로 나가지는 않는다. 요리가 끝난 뒤 주문 확인과 포장이 밀리면 손님은 계속 기다린다. 코드도 작성 뒤 검토와 테스트를 통과해야 실제 서비스에 들어간다. 여러 프로젝트의 코드를 한곳에 모은 저장소가 모노레포이고, 변경마다 자동 검사를 돌리는 과정이 CI다. 이 비유는 병목을 이해하기 위한 것으로 Scion의 내부 구조를 뜻하지 않는다. 작은 팀이라면 도구를 바꾸기 전에 이번 주 변경들이 어느 단계에서 가장 오래 기다렸는지부터 확인할 수 있다.
Anthropic은 사내 모노레포를 자체 버전 관리 시스템 Scion으로 이전한 과정을 공개했다. 회사 집계에 따르면 하루 병합 건수는 2026년 5월 약 2,500건에서 9월 3만 건 이상으로 늘었다. 소스 관리, 빌드, CI가 늘어난 물량을 따라가는 일이 병목이 됐다.
7명 팀은 Scion과 코드 검토 도구 Antique, 관련 시스템을 만들고 5개월 만에 이전을 마쳤다고 설명한다. 사람의 검토도 계속한다. 해당 시스템 팀은 모든 변경 요청을 검토하되, 한 줄씩 읽는 방식에서 변경 의도와 설계 제약을 살피는 쪽으로 역할이 달라졌다고 밝혔다. Anthropic 기술 원문
이 사례를 적용할 때는 저장소 규모를 먼저 따져야 한다. Anthropic은 Scion이 일반적인 Git 대체재가 아니며, 대부분의 저장소에는 Git의 설계가 적절하다고 명시했다. 이례적으로 큰 저장소와 막대한 내부 AI 사용량을 다른 팀의 표준으로 삼기는 어렵다.
읽는 기준: 지금 적용할 질문은 “우리도 버전 관리 시스템을 바꿀까?”보다 작다. 코드 생성 이후 어디에서 기다리는지 먼저 보자. 리뷰 대기, 테스트 실행, 충돌 해결, 되돌리기에 걸린 시간을 나누면 다음에 고칠 병목을 찾기 쉽다.
3. diff-tour: AI 코드의 변경 이유를 따라 읽는 도구
바뀐 코드 옆에 길 안내를 붙인다. 설명이 맞는지는 코드와 테스트로 확인한다.
쉽게 풀어보기 · 이용 조건과 주의점
초기 공개 도구 · 최초 출시일 미확인 · README 확인: 2026년 10월 15일
움직이는 공식 데모 보기 (약 1.5MB)
쉽게 풀면: 변경된 부분에 안내문을 붙여 주는 도구다. diff는 코드의 이전 모습과 바뀐 모습을 비교한 기록이다. 낯선 전시에서 안내문을 읽으면 관람 순서가 잡히듯, 변경 이유를 먼저 들으면 긴 코드도 어디부터 읽을지 정하기 쉽다. 다만 안내문이 작품 자체는 아니듯 AI의 설명도 코드의 정확성을 보증하지 않는다. “오류 처리를 추가했다”는 설명을 받았다면 해당 코드와 오류 상황의 테스트를 직접 찾아보자.
diff-tour는 Git 변경을 단계별 설명으로 보여 주는 터미널 도구다. 로그인한 Claude Code, Codex CLI, Gemini CLI 중 하나로 안내를 만들며, 화면의 코드는 해당 커밋에서 읽어 표시한다. 변경 목적, 실패할 때의 동작, 검토자가 물어볼 질문을 따라가는 방식이다. 공식 저장소
사용 전에는 읽기 전용과 외부 전송을 구분해야 한다. README에 따르면 비교 대상 파일, diff, 커밋 메시지는 선택한 도구의 공급자에게 전달되며 해당 계정의 약관이 적용된다. 원본 저장소를 수정하지 않는다는 설명이 코드를 외부에서 처리하지 않는다는 뜻은 아니다.
현재 화면 언어는 영어·일본어다. Gemini CLI 지원은 실험적이며, README는 실제 Gemini 모델로 전체 안내를 생성하는 시험을 아직 마치지 않았다고 적고 있다. 코드 속 악성 지시가 설명을 왜곡할 가능성도 경고한다. 지원 범위와 데이터 처리 설명
읽는 기준: 큰 변경을 인수인계하거나 낯선 AI 코드를 이해할 때 살펴볼 만하다. 설명이 그럴듯한지와 실제 코드가 올바른지는 따로 확인해야 한다. 먼저 공개 예제나 비밀정보가 없는 작은 저장소에서 시험하자.
4. 공유 달력 사례: 작은 앱에도 연결과 검증 시간이 든다
첫 앱의 목표는 작게: 동료의 휴가 일정을 한 화면에서 함께 확인하기.
쉽게 풀어보기 · 이용 조건과 주의점
작성자 경험담 · 원문 발행: 2026년 10월 14일
쉽게 풀면: 화면은 가게의 진열대에 가깝다. 진열대를 갖췄어도 출입문과 창고가 제대로 연결돼야 가게를 열 수 있다. 앱에서는 로그인과 데이터 저장이 그 역할을 한다. 이 비유가 실제 시스템 설계와 일대일로 맞는 것은 아니지만, 화면 완성과 출시 준비가 다른 일임을 보여 준다. 공유 달력이라면 “내 일정은 고칠 수 있고, 권한 없는 사람의 일정은 고칠 수 없는가?”를 별도 계정으로 시험해 볼 수 있다.
요즘IT의 한 기획자는 동료들의 휴가 일정을 수기로 적고 확인하던 불편에서 공유 달력 앱을 시작했다. 첫 범위는 일정 등록·수정·삭제, 다른 사람의 일정 확인, 간단한 로그인으로 잡았다.
작성자는 Render, Supabase, 카카오톡 로그인을 사용했고, 설계부터 QA와 출시까지 약 일주일이 걸렸다고 설명한다. 이 가운데 카카오톡 로그인 적용에만 3일을 썼다. 이는 한 사람의 제작 경험이며 누구나 같은 기간에 완성한다는 근거는 아니다. 작성자의 바이브 코딩 회고
읽는 기준: 첫 앱을 고를 때는 누가 무엇을 불편해하는지 한 문장으로 적어 보자. 화면이 만들어진 뒤에도 계정 연결, 접근권한, 잘못된 입력과 실패 상황을 확인할 시간이 남는다. 실제 사용자에게 줄 첫 버전의 범위를 작게 잡으면 이 과정까지 끝내기 쉽다.
5. 기록 정리 사례: 파일을 줄인 뒤 어떤 질문을 할 것인가
흩어진 기록을 연결하면 질문하기 쉬워진다. AI가 찾은 관계는 원문으로 다시 확인한다.
쉽게 풀어보기 · 이용 조건과 주의점
작성자 회고 · 원문 발행: 2026년 10월 14일
쉽게 풀면: 책장을 정리하는 일과 답을 찾는 일은 다르다. 책을 주제별로 꽂으면 찾기 편해지지만, 책등만 보고 결론을 낼 수는 없다. AI가 문서를 묶는 작업도 비슷하다. 서로 가까이 묶였다는 이유만으로 원인과 결과가 입증되지는 않는다. 예를 들어 “고객 요청 때문에 출시가 미뤄졌나?”를 묻는다면, 요청과 결정의 날짜를 대조하고 다른 이유로 연기된 기록도 함께 읽어야 한다.
다른 요즘IT 글은 종료한 서비스의 기록을 다시 읽은 경험을 다룬다. 작성자는 490개 파일을 Claude Code로 정리해 노트 34개와 핵심 문서 몇 개로 재구성했다고 설명한다. 서로 다른 시기의 고객 기록과 의사결정을 나란히 보면서 운영 중에는 놓쳤던 관계를 발견했다는 회고다. 작성자의 기록 정리 원문
파일 수와 소요 시간은 이 작업의 사례값이다. 문서를 줄였다는 사실만으로 분석이 정확해졌거나 다른 자료도 같은 속도로 처리된다고 말할 수는 없다.
읽는 기준: 오래된 문서를 정리한다면 먼저 질문 하나를 정하자. 예를 들어 “반복해서 미뤄진 결정은 무엇이며 당시 이유는 어떻게 달랐나?”라고 물을 수 있다. AI가 묶은 패턴마다 원문 위치와 날짜를 남기고, 맞지 않는 사례도 함께 찾아야 과도한 일반화를 줄일 수 있다.
오늘 업무에 적용한다면
확인할 세 가지와 30분 실험 보기
AI 작업에 세 가지 확인 지점을 붙이기
오늘의 소식들을 업무에 적용할 때는 새 도구를 한꺼번에 늘리기보다, 작업 하나에 다음 세 지점을 붙여 보자.
- 시작 전: 이용 조건과 데이터 범위. 사용할 계정, 예상 비용, 외부로 보내도 되는 파일을 정한다. 예를 들어 코드 설명을 시험할 때는 공개 예제부터 고른다.
- 생성 뒤: 변경 이유와 근거. “어떤 파일을 왜 바꿨나?”, “어느 원문에서 이 해석이 나왔나?”를 결과와 함께 받는다. 설명에서 가리킨 위치를 직접 열어 본다.
- 사용 전: 실패 조건과 복구 방법. 앱이라면 권한 없는 계정과 잘못된 입력을 시험한다. 기록 분석이라면 결론에 맞지 않는 원문을 찾는다. 원본은 보존한다.
세 지점이 모두 복잡할 필요는 없다. 첫 실험에서는 각 항목을 한 줄씩 적어도 충분하다.
바로 해볼 실험
30분 동안 공개된 작은 코드 변경 하나를 읽어 보자.
먼저 스스로 변경 목적과 걱정되는 점을 적는다. 이어 AI에게 같은 변경을 설명하게 하고, 답변이 가리킨 파일과 줄을 확인한다. 마지막에는 “이 코드를 망가뜨리면 어떤 테스트가 실패해야 할까?”를 묻는다.
측정할 것은 설명의 길이보다 이해에 걸린 시간, 잘못 짚은 근거, 새로 찾은 검토 질문이다. 이 기록이 있어야 다음 도구나 모델과 비교할 수 있다.
마무리
오늘의 발표와 사례는 서로 규모가 다르다. 대형 모델의 이용 확대, 초대형 저장소의 재설계, 코드 설명 도구, 작은 앱과 개인 기록 정리가 같은 성능을 입증하는 것은 아니다.
다음 작업 하나를 골라 보자. AI가 만든 결과에서 무엇을 읽고, 어떤 근거와 테스트로 확인할 것인가?