OpenAI가 내부 데이터를 공개했다. 2025년 8월까지만 해도 사내 AI 토큰의 10%에도 미치지 못했던 Codex가, 지금은 전체 주간 AI 출력 토큰의 99.8%를 담당한다. 엔지니어링팀만의 이야기가 아니다. 법무, 재무, 채용 부서까지 AI 출력의 85% 이상을 Codex로 생성하고 있고, 비개발자 사용자는 같은 기간 137배 늘었다. 챗봇 시대는 이미 끝났고, 에이전트가 표준이 됐다는 선언이 이제는 데이터로 뒷받침된다.
그런데 이 숫자 앞에서 테크 리드로서 내가 먼저 드는 질문은 하나다. 에이전트가 하루에 60시간분의 작업을 병렬로 처리한다면, 그 작업의 맥락은 어디에 남는가? 커밋 히스토리는 "auth 리팩토링"이라고만 말한다. 어떤 두 가지 접근을 시도했고, 무엇이 깨졌으며, 왜 그 방향을 버렸는지—그 판단의 전 과정은 AI 세션 안에만 존재하다가, 탭을 닫는 순간 사라진다.
이건 기록 관리 문제가 아니라 팀의 버스 팩터 문제다. 누군가 팀을 떠나면 코드는 남지만 추론은 사라진다. 신규 입사자는 결론만 상속받고 과정은 재현할 수 없다. 6개월 뒤 "왜 이렇게 만들었지?"라는 질문에 아무도 답하지 못한다. 예전에는 이 문제를 해결하려면 가장 바쁜 사람에게 문서를 써달라고 부탁해야 했다. AI 에이전트 시대에는 구조가 달라졌다. 최고의 엔지니어링 기록은 이미 생성되고 있다—우리가 매일 삭제하고 있을 뿐이다.
오픈소스 프로젝트 Klear-Team-Brain(Apache-2.0)은 이 문제를 정확히 겨냥한다. Claude Code와 Codex가 ~/.claude, ~/.codex에 남기는 JSONL 세션 파일을 자동으로 수집해, 시크릿을 클라이언트 사이드에서 제거한 뒤 git 저장소에 커밋한다. 별도의 데이터베이스나 클라우드 계정이 필요 없다. 검색은 git grep으로 돌아간다. MCP를 통해 Claude Code에 연결하면 "auth 리팩토링 세션에서 아직 미해결로 남긴 게 뭐였지?"를 자연어로 물을 수 있다. 핵심은 단순하다—팀원이 추가로 할 일이 없다는 것. 도구를 쓰기만 하면 기록은 자동으로 쌓인다.
세션 기록 보존이 지식 축적 문제를 다룬다면, 두 번째 설계 원칙은 검증의 신뢰도 문제를 다룬다. 메인 에이전트가 코드를 쓰고, 테스트를 통과시키고, 완료를 선언한다. 나중에 뭔가 잘못됐다는 걸 발견한다. null 케이스가 빠졌거나, 스펙과 다른 에러 메시지가 나오거나, 테스트는 통과하지만 살짝 다른 컨텍스트에서 깨진다. 이건 에이전트의 지능 문제가 아니다. 완료 편향(completion bias) 문제다. 코드를 쓴 주체가 같은 코드를 검증할 때, 이미 "완성됐다"는 전제로 읽는다. 인간 코드 리뷰에서 작성자가 본인 PR을 가장 못 잡는 것과 정확히 같은 구조다.
해법은 프롬프트 튜닝이 아니다. "비판적으로 리뷰하라"고 지시해봤다. 조금 낫다. 하지만 에이전트는 자신의 완료 편향과 싸워야 하고, 그건 약한 힘이다. 구조적 해법은 툴 스코핑이다. 읽기 전용 리뷰어 에이전트를 메인 에이전트와 분리한다. 리뷰어는 Read, Grep, Glob만 쥔다. Edit, Write, Bash는 없다. 수정할 수 없으면 완료할 것도 없다. 완료할 것이 없으면 확인 편향이 작동하지 않는다. 수정 권한을 제거하면 발견 능력이 날카로워진다.
실제로 리뷰어 에이전트가 잡아내는 건 구체적이다. 스펙에서 합리적이지만 살짝 벗어난 구현 결정—메인 에이전트는 "느낌이 맞다"고 넘기지만 스펙을 그대로 들고 읽는 리뷰어는 플래그를 단다. 해피 패스만 처리된 엣지 케이스—"이 입력이 비어 있으면?"은 쓸 때보다 읽을 때 더 잘 보인다. 그리고 테스트-구현 커플링—구현과 테스트가 같은 맹점을 공유하며 함께 쓰였을 때, 리뷰어는 "이 테스트가 코드를 커버하는가, 아니면 동작을 커버하는가"를 묻는다. 이 둘은 다르다.
구현은 간단하다. 메인 에이전트가 완료한 뒤, diff와 스펙을 읽기 전용 툴셋만 가진 두 번째 에이전트에 넘긴다. 리뷰어의 아웃풋은 발견 목록이다. 메인 에이전트가 그걸 받아 처리하고, 필요하면 한 번 더 리뷰어를 돌린다. 프로덕션으로 가는 코드, 스펙이 정밀하게 정의된 기능, 인수인계가 예정된 모듈—이 세 조건 중 하나라도 해당하면 오버헤드를 감수할 가치가 있다.
세 가지 설계 원칙을 정리하면 이렇다. 첫째, 에이전트 전환은 선택이 아니다. OpenAI 내부 데이터는 이미 그 방향을 가리킨다. 테크 리드가 준비하지 않으면 팀은 알아서 전환되고, 거버넌스 없이 흩어진다. 둘째, 세션은 팀의 가장 정직한 엔지니어링 기록이다. 그걸 보존하는 구조를 짜지 않으면, 팀은 매일 최고의 의사결정 맥락을 삭제하고 있는 셈이다. 셋째, 검증은 에이전트를 분리해야 신뢰할 수 있다. 같은 컨텍스트, 같은 완료 의지를 공유하는 에이전트는 자기 작업을 제대로 리뷰하지 못한다. 툴 스코핑으로 역할을 구조적으로 분리하라.
OpenAI의 데이터가 보여주는 미래는 사람 한 명이 여러 에이전트를 병렬로 운영하며 하루 60시간분의 작업을 처리하는 세계다. 그 세계에서 테크 리드의 역할은 에이전트를 잘 쓰는 것만이 아니다. 에이전트가 생성한 작업물의 맥락을 보존하고, 검증을 구조적으로 설계하고, 팀 전체가 그 지식을 재사용할 수 있게 만드는 것—그게 AI-First 팀의 진짜 인프라다.