오늘 바이브 코딩 분야에서 살펴볼 만한 흐름은 다섯 가지다.
새로운 Grok 4.7의 등장, 모델의 Thinking Effort를 직접 조절하는 VS Code, OpenAI의 새로운 AI 개발 학습 과정, 장기 기억을 설계하는 V7의 Context Graph, 그리고 수십 개의 코딩 에이전트를 동시에 운영한 Kiro Crew의 실험이다.
이 소식들을 하나로 묶어보면 최근 바이브 코딩의 방향이 조금씩 보인다.
좋은 모델 하나를 고르는 것에서, 모델이 일하는 환경과 컨텍스트, 기억, 검증 방법을 설계하는 것으로 중심이 이동하고 있다.
Grok 4.7 — 장시간 코딩 작업을 겨냥한 새로운 모델
SpaceXAI가 9월 21일 Grok 4.7을 공개했다.
이번 모델에서 흥미로운 부분은 단순히 코딩 벤치마크 점수가 올라갔다는 것이 아니다.
SpaceXAI 설명에 따르면 Grok 4.7은 Grok 4.6보다 더 큰 새로운 base model을 사용하고, 더 어렵고 시간이 오래 걸리는 문제를 중심으로 강화학습을 더 길게 진행했다.
특히 몇 시간에 걸쳐 수행되는 장기 작업에 더 많은 학습 비중을 두었다고 한다.
그 결과 Grok 4.7이 강조하는 능력은 크게 세 가지다.
오래 작업하기, 자신의 결과를 다시 확인하기, 긴 컨텍스트를 관리하기.
즉 한 번 코드를 만들어주는 것보다는 여러 파일을 탐색하고 코드를 수정하고 다시 확인하는 형태의 작업에 초점을 맞춘 모델이라고 볼 수 있다. SpaceXAI는 이를 코딩뿐 아니라 일반적인 knowledge work에도 적합한 모델로 설명하고 있다.
API 모델은 최대 500K context window를 지원하며 reasoning effort를 "low", "medium", "high", "xhigh"로 조절할 수도 있다. Cursor와 Grok Build에서도 사용할 수 있으며 Grok Build에서는 기본 코딩 모델로 사용된다.
이 변화에서 주목하고 싶은 것은 코딩 모델의 평가 기준이 점점 “코드를 얼마나 잘 생성하는가”에서 “얼마나 오래 안정적으로 일을 진행하는가”로 바뀌고 있다는 점이다.
초기의 AI 코딩은 함수 하나를 만들어주는 것이 중요했다.
하지만 에이전트 기반 개발에서는 상황이 다르다.
코드베이스 탐색 → 계획 → 여러 파일 수정 → 테스트 → 오류 발견 → 재수정 → 결과 검증
같은 긴 작업을 끝까지 유지할 수 있어야 한다.
Grok 4.7의 방향은 최근 코딩 모델들이 어디를 향하고 있는지를 보여주는 사례라고 볼 수 있다.
오늘의 학습 포인트
AI에게 단순히 “이 기능을 만들어줘”라고 하기보다 다음과 같은 긴 작업을 한번 맡겨보자.
"문제 분석 → 구현 계획 → 코드 수정 → 테스트 → 실패 원인 분석 → 수정 → 최종 검증"
그리고 모델이 어느 단계에서 흔들리는지 관찰해보면 장기 에이전트 작업의 특성을 이해하기 좋다.
출처: SpaceXAI — Introducing Grok 4.7 "Grok 4.7 공식 발표" (https://reference-url-citation.invalid/2)
출처: SpaceXAI Developers — Grok 4.7 "Grok 4.7 개발자 문서" (https://reference-url-citation.invalid/3)
VS Code — 같은 모델에서도 ‘얼마나 생각할지’를 선택한다
VS Code 1.139 Insiders에서는 모델 선택창에서 Thinking Effort를 직접 선택하는 기능이 추가되고 있다.
모델이 지원한다면 더 긴 Context Size도 선택할 수 있다.
작은 변화처럼 보이지만 꽤 중요한 기능이다.
그동안 AI 코딩에서는 주로 이런 고민을 했다.
“GPT를 사용할까?”
“Claude를 사용할까?”
“Grok을 사용할까?”
하지만 모델이 발전하면서 같은 모델 안에서도 작업에 투입할 추론량을 선택하는 것이 중요해지고 있다.
예를 들어 CSS 색상 하나를 바꾸는 작업과 데이터베이스 구조까지 영향을 주는 버그를 분석하는 작업에 동일한 추론량이 필요하지는 않다.
앞으로는 이런 식의 사용 방식이 자연스러워질 가능성이 있다.
간단한 수정 → Low 일반적인 기능 개발 → Medium 복잡한 디버깅 → High 아키텍처 설계 → High 또는 Max
컨텍스트도 마찬가지다.
AI 모델의 컨텍스트 창이 50만 토큰, 100만 토큰으로 커졌다고 해서 항상 모든 코드를 넣을 필요는 없다.
오히려 중요한 것은 현재 작업을 해결하는 데 필요한 정보가 무엇인지 선택하는 능력이다.
바이브 코딩에서도 결국 모델 선택뿐 아니라 Reasoning Budget과 Context Budget을 관리하는 기술이 생겨나는 셈이다.
오늘의 학습 포인트
현재 하고 있는 개발 작업을 세 가지로 나눠보자.
"Quick / Normal / Deep"
그리고 AI를 사용할 때 작업의 난이도에 따라 생각하는 양을 다르게 사용하는 습관을 만들어보면 좋다.
출처: Microsoft — Visual Studio Code 1.139 Insiders "VS Code 1.139 릴리스 노트" (https://reference-url-citation.invalid/5)
OpenAI Academy — 바이브 코딩도 ‘워크플로’를 배우기 시작한다
OpenAI는 9월 21일 Academy를 확대하면서 개발자를 위한 Build with AI 학습 경로를 공개했다.
이 과정은 Codex를 이용한 실제 코딩 작업뿐 아니라 API 기반 AI 시스템 설계, 평가(Evals), 에이전트, 검색과 retrieval, production 운영까지 다룬다.
특히 Codex 과정의 방향이 흥미롭다.
단순히 “프롬프트를 잘 작성하는 방법”을 배우는 것이 아니라 실제 repository에서 작업을 정의하고, 변경하고, 결과를 검증하는 방식에 초점을 맞추고 있다.
OpenAI Academy에는 다음과 같은 과정도 포함되어 있다.
"Get Started with Codex"
"Extend Codex Workflows"
"Scale Codex Across Governed Teams and Systems"
뒤로 갈수록 단일 코딩 작업보다 반복 가능한 workflow, 여러 작업의 병렬 처리, 관리와 governance로 주제가 확장된다.
이 흐름은 바이브 코딩을 배우는 방법에도 힌트를 준다.
예전에는 좋은 프롬프트 예시를 많이 알고 있는 것이 중요했다.
하지만 에이전트 시대에는
무슨 일을 맡길 것인가 → 어떤 정보를 줄 것인가 → 어디에서 사람이 확인할 것인가 → 결과가 맞는지 어떻게 증명할 것인가
가 더 중요해지고 있다.
즉 프롬프트 작성법에서 작업 설계법으로 넘어가고 있는 것이다.
오늘의 학습 포인트
작은 기능 하나를 골라 AI에게 처음부터 끝까지 맡겨보자.
"요구사항 정의 → 구현 → 테스트 → 결과 검토"
그리고 마지막에 “완료했다”는 설명만 받지 말고 실제 테스트 결과나 변경 파일을 근거로 보여달라고 해보자.
출처: OpenAI — Expanding OpenAI Academy with new learning paths "OpenAI Academy 발표" (https://reference-url-citation.invalid/8)
출처: OpenAI Academy — Building with AI "Building with AI 학습 페이지" (https://reference-url-citation.invalid/9)
출처: OpenAI Academy — Codex "Codex 학습 과정" (https://reference-url-citation.invalid/10)
V7 — 긴 컨텍스트보다 ‘구조화된 기억’을 만든다
AI 에이전트를 오래 사용하면 한 가지 문제가 생긴다.
프로젝트와 회사에 대한 설명을 계속 다시 해야 한다.
문서가 많아지면 AI에게 모든 자료를 매번 읽히는 것도 비효율적이다.
V7은 이 문제를 Context Graph라는 방식으로 해결하고 있다.
문서에서 사람, 회사, 사실, 관계, 수치 등의 정보를 추출해 그래프 형태로 저장한다.
에이전트가 질문을 받으면 모든 문서를 처음부터 다시 검색하는 대신 먼저 이 구조화된 정보를 조회한다.
필요한 정보가 그래프에 없을 경우에만 원본 문서에 RAG 검색을 수행한다.
장기 메모리도 비슷한 방식으로 구성한다.
최근 대화는 모델의 현재 컨텍스트에 유지하고, 오래된 정보는 Context Graph에 저장했다가 필요한 순간 다시 가져온다.
V7은 이를 institutional memory, 즉 조직의 기억이라고 표현한다.
V7 자체 테스트에서는 가장 어려운 graph query에서 GPT-5.6 Sol이 78%, GPT-6 Astra가 89%의 정확도를 기록했다고 밝혔다. 이는 V7이 자체적으로 구성한 데이터와 평가이므로 일반적인 모델 성능 비교라기보다는 해당 시스템에서의 결과로 보는 것이 적절하다.
이 접근은 개발 프로젝트에도 꽤 쉽게 적용할 수 있다.
모든 코드를 AI에게 읽히는 것보다 중요한 정보를 따로 정리할 수 있다.
예를 들어
"ARCHITECTURE.md" — 시스템 구조
"DECISIONS.md" — 중요한 기술 결정
"RUNBOOK.md" — 실행·배포 방법
"KNOWN_ISSUES.md" — 반복적으로 발생하는 문제
같은 문서를 유지하는 것이다.
이렇게 하면 AI가 프로젝트를 매번 처음부터 다시 이해해야 하는 비용을 줄일 수 있다.
오늘의 학습 포인트
프로젝트 하나에 "DECISIONS.md"를 만들어보자.
AI와 개발하면서 중요한 결정을 내릴 때마다
"결정 / 이유 / 관련 파일"
세 가지만 기록한다.
몇 주 뒤 AI에게 새로운 작업을 맡길 때 이 파일을 먼저 읽히면 장기 프로젝트에서 기억이 얼마나 중요한지 쉽게 체감할 수 있다.
출처: OpenAI — How V7 gives AI agents institutional memory "V7 Context Graph 사례" (https://reference-url-citation.invalid/13)
Kiro Crew — 에이전트가 많아지면 결국 ‘관리’가 개발이 된다
이번 주 가장 흥미로운 실험 중 하나는 Kiro 팀의 사례다.
Kiro Crew를 개발하는 풀타임 엔지니어 3명이 7일 동안 1,000개 이상의 Pull Request를 병합했다.
하루 120개가 넘는 수준이며, 모든 PR은 CI와 리뷰 과정을 거쳤다고 한다.
처음부터 수십 개의 에이전트를 운영했던 것은 아니다.
Kiro 팀은 자신들의 발전 과정을 다섯 단계로 설명한다.
1단계 — 하나의 에이전트 세션
2단계 — 여러 세션을 동시에 사용
3단계 — Memory, dashboard, cron, workflow 도입
4단계 — Agent Pipeline
5단계 — Crew Mode
3단계에서는 한 사람이 약 10~20개의 활성 세션을 관리할 수 있었다고 한다.
하지만 20개를 넘어 30개, 50개의 에이전트를 동시에 움직이기 시작하면서 새로운 문제가 나타났다.
AI가 아니라 사람이 병목이 된 것이다.
각 에이전트에게
무엇을 할지 정하고,
실행시키고,
문제가 없는지 확인하고,
결과를 판단하고,
다음 작업을 결정하는 일을
사람이 계속 해야 했기 때문이다.
그래서 등장한 것이 Crew Mode다.
Crew Mode에서는 또 다른 coordinator agent가 여러 작업을 분해하고 세션을 생성하고 진행 상황을 확인하고 작업을 종료한다.
사람은 개별 작업보다 전체 목표를 관리한다.
실제 Kiro 개발자 중 한 명은 여러 머신을 이용해 동시에 약 30~50개의 세션을 운영했다고 설명한다.
하지만 여기서 더 중요한 부분이 있다.
Kiro 팀은 처음부터 50개의 에이전트를 사용하라고 하지 않는다.
오히려 한 단계씩 올라가라고 한다.
하나의 에이전트를 제대로 사용하고,
반복되는 작업을 발견하고,
Memory를 만들고,
Workflow를 만들고,
Pipeline을 만든 뒤,
정말 사람이 병목이 되었을 때 오케스트레이션을 도입하라는 것이다.
이 접근이 현실적이다.
오늘의 학습 포인트
에이전트를 20개 띄울 필요는 없다.
두 개면 충분하다.
"Agent 1 — 구현"
"Agent 2 — 코드 리뷰"
하나는 코드를 만들고, 다른 하나는 그 결과를 독립적으로 검토하게 해보자.
이 작은 구조만으로도 하나의 AI와 대화하며 개발하는 방식과는 상당히 다른 경험을 할 수 있다.
출처: Kiro — How we built a software factory with Kiro Crew to merge 1000 PRs in a week "Kiro Crew 1,000 PR 실험 원문" (https://reference-url-citation.invalid/17)
오늘의 결론
오늘 살펴본 다섯 가지 소식을 연결하면 바이브 코딩이 어디로 움직이는지 조금 보인다.
초기의 바이브 코딩은 대략 이런 구조였다.
Prompt → Code
좋은 프롬프트를 입력하면 AI가 코드를 만들어줬다.
하지만 지금은 점점 다음과 같은 구조로 변하고 있다.
Context → Plan → Delegate → Execute → Verify → Remember → Repeat
Grok 4.7처럼 모델은 더 오래 작업하고 자신의 결과를 확인하는 방향으로 발전하고 있다.
VS Code에서는 같은 모델에서도 얼마나 생각하게 할지 직접 조절할 수 있게 되고 있다.
OpenAI는 Codex 활용법을 단순한 프롬프트가 아니라 workflow 관점에서 가르치기 시작했다.
V7은 긴 컨텍스트를 무작정 사용하는 대신 AI가 참고할 수 있는 구조화된 기억을 만들고 있다.
그리고 Kiro Crew는 여러 에이전트를 동시에 사용하다 보면 결국 사람이 그들을 관리하는 것이 새로운 병목이 된다는 것을 보여준다.
결국 바이브 코딩의 다음 단계는 더 좋은 프롬프트만은 아닌 것 같다.
앞으로 중요해질 능력은 이런 것들이다.
무엇을 AI에게 맡길지 결정하는 능력.
AI가 알아야 할 정보를 정리하는 능력.
큰 일을 작은 작업으로 나누는 능력.
AI가 만든 결과를 자동으로 검증하는 방법을 만드는 능력.
그리고 성공한 작업 방식을 Memory, Skill, Workflow로 남겨 다시 사용할 수 있게 만드는 능력.
이런 흐름을 굳이 이름 붙인다면 Agent Engineering이라고 부를 수 있을 것 같다.
지금 당장 복잡한 멀티에이전트 시스템을 만들 필요는 없다.
작게 시작해도 된다.
프로젝트 기억 파일 + 구현 Agent + 리뷰 Agent
이 정도만 만들어도 단순히 AI에게 코드를 생성시키는 것에서 한 단계 다른 개발 방식을 경험할 수 있다.
바이브 코딩의 다음 단계는 AI에게 더 많은 코드를 쓰게 하는 것이 아니라,
AI가 오랫동안 제대로 일할 수 있는 환경을 만드는 것일지도 모른다.
참고 자료
SpaceXAI — Introducing Grok 4.7 "공식 발표 보기" (https://reference-url-citation.invalid/18)
SpaceXAI Developers — Grok 4.7 "개발자 문서 보기" (https://reference-url-citation.invalid/19)
Microsoft — Visual Studio Code 1.139 Insiders "릴리스 노트 보기" (https://reference-url-citation.invalid/20)
OpenAI — Expanding OpenAI Academy with new learning paths "공식 발표 보기" (https://reference-url-citation.invalid/21)
OpenAI Academy — Building with AI "학습 과정 보기" (https://reference-url-citation.invalid/22)
OpenAI Academy — Codex "Codex 학습 과정 보기" (https://reference-url-citation.invalid/23)
OpenAI — How V7 gives AI agents institutional memory "V7 사례 보기" (https://reference-url-citation.invalid/24)
Kiro — How we built a software factory with Kiro Crew to merge 1000 PRs in a week "Kiro Crew 사례 보기" (https://reference-url-citation.invalid/25)
※ Grok, V7, Kiro의 성능 및 생산성 수치는 각 회사가 공개한 자체 벤치마크 또는 내부 사례를 포함한다. 따라서 서로 다른 제품의 절대적인 성능 비교보다는 각 팀이 관찰한 결과와 개발 방향을 이해하기 위한 자료로 보는 것이 적절하다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.