핵심 요약
사람이 코드를 쓰지 않고, 에이전트(Codex)가 제품 코드부터 문서·CI·리뷰까지 "소프트웨어 생산" 전부를 수행하게 하려면 개발의 중심이 코딩에서 환경 설계와 피드백 루프 구축으로 이동한다.
그 핵심은 에이전트가 읽고 실행할 수 있는 지식(문서·규칙·관측 신호)을 리포지터리에 체계적으로 넣고, 아키텍처 불변조건을 기계적으로 강제하며, 엔트로피를 자동 "정리 작업"으로 상시 회수하는 것이다.
에이전트의 관점에서 보면 실행 중에 컨텍스트 내에서 액세스할 수 없는 것은 사실상 존재하지 않는 것입니다. Google Docs, 채팅 스레드 또는 사람들의 머릿속에 있는 지식은 시스템에서 접근할 수 없습니다. 리포지터리 내의 버전 관리되는 아티팩트(예: 코드, 마크다운, 스키마, 실행 계획)에만 접근할 수 있습니다.
"사람이 조정하고, 에이전트가 수행"으로 역할을 바꾸기
에이전트 우선 개발에서 사람의 핵심 업무는 더 이상 "한 줄 더 잘 짜기"가 아니라, 에이전트가 안정적으로 성과를 내는 판을 깔아주는 일이다.
즉 목표를 잘게 쪼개 에이전트가 조립할 수 있는 블록(설계→구현→테스트→검토)을 만들고, 막히는 지점은 개인 역량의 문제가 아니라 시스템 결핍의 신호로 해석한다.
현장감 있는 비유로는 "셰프(사람)가 매번 요리를 하는 대신, 주방 동선·레시피·도구·위생 규칙을 설계하고 로봇 조리사가 반복 생산하게 만드는 것"에 가깝다.
빈 리포지터리에서 시작해 '전부 에이전트 산출물'로 운영하기
이 사례는 첫 커밋부터 스캐폴드, 규칙, 에이전트 사용법 문서까지 에이전트가 만들었다는 점이 중요하다.
결과적으로 제품 로직뿐 아니라 테스트, CI, 릴리스 툴링, 내부 도구, 문서, 대시보드 정의, 심지어 리뷰 코멘트 응답까지 "리포지터리에 있는 모든 것"이 에이전트 생성물이라는 운영 철학으로 이어진다.
이 철학이 강력한 이유는 책임 소재가 "어느 파일을 누가 손댔지?"가 아니라 "이 시스템이 다음에도 같은 품질로 만들 수 있지?"로 바뀌기 때문이다.
에이전트가 앱을 '읽게' 만들어 QA 병목을 풀기
처리량이 올라가면 사람 QA는 곧 병목이 된다.
그래서 앱 UI와 실행 상태를 에이전트가 직접 관찰·조작할 수 있게 만드는 투자가 필요해진다(예: 변경사항마다 격리된 인스턴스를 띄우고, 브라우저 자동화로 DOM 스냅샷·스크린샷·탐색을 수행하게 함).
여기에 로그·메트릭·트레이스를 에이전트가 쿼리 가능한 형태로 제공하면, "버그 재현→수정→검증"이 사람의 눈이 아니라 실행 신호 기반의 루프로 돌아간다.
문서 전략: "1,000페이지 설명서" 대신 "지도(맵)" 제공하기
에이전트의 컨텍스트는 희소 자원이라, 거대한 단일 지침서는 오히려 핵심 제약을 흐리고 빠르게 낡는다.
해결책은 짧은 안내서(목차/지도 역할)와, 구조화된 기록 시스템(docs/)을 분리하는 것이다.
요지는 "AGENTS.md는 길찾기 표지판, docs/는 박물관 전시실"처럼 만들고, 계획(실행 계획·의사결정 로그·기술부채 목록)까지 버전 관리해 외부 대화(Slack, Docs)에 의존하지 않게 하는 데 있다.
"에이전트가 볼 수 없으면, 존재하지 않는다"를 전제로 설계하기
에이전트는 실행 중 접근 가능한 리포지터리 아티팩트만 기반으로 추론한다.
따라서 팀의 암묵지(채팅에서 합의된 규칙, 선호, 운영 원칙)를 리포지터리로 끌어와야 하며, 이는 새 팀원 온보딩 문화를 코드베이스에 이식하는 것과 같다.
또한 에이전트가 내부화하기 쉬운 "지루하지만 예측 가능한" 기술(안정적 API, 명확한 계층, 투명한 동작)을 선호하게 되고, 때로는 불투명한 외부 라이브러리에 기대기보다 필요한 부분을 재구현하는 편이 더 싸게 먹힌다.
아키텍처는 문서가 아니라 '기계적 강제'로 지킨다
문서만으로는 에이전트가 만든 코드의 일관성을 유지하기 어렵다.
그래서 계층 구조, 의존성 방향, 명명 규칙, 로깅 형식, 파일 크기 같은 불변조건을 맞춤형 린터와 구조 테스트로 강제하고, 에러 메시지 자체를 "수정 지침"으로 설계해 에이전트 컨텍스트에 주입한다.
핵심은 중앙에서 경계를 엄격히 정의하되, 경계 안에서는 표현의 자유를 주는 것이다("도시의 건축법은 엄격하지만, 건물 인테리어는 자율" 같은 모델).
병합·리뷰 규범도 처리량에 맞게 재설계한다
에이전트 처리량이 사람 주의력을 초과하면, 전통적인 '강한 게이트'는 속도를 갉아먹는다.
따라서 PR 수명을 짧게 하고, 어떤 문제는 완벽히 막아 서기보다 후속 실행에서 빠르게 고치는 쪽이 전체 비용이 낮아질 수 있다.
다만 이 접근은 처리량이 작은 팀의 모범답안이 아니라, "수정은 싸고 대기는 비싼" 환경에서만 성립하는 절충이라는 점이 중요하다.
자율성의 임계점: 한 번의 프롬프트로 "끝까지" 가게 만들기
툴링과 피드백 루프가 충분히 인코딩되면, 에이전트는 버그 재현(필요시 영상 기록)부터 수정 구현, 검증, PR 생성, 리뷰 응답, 빌드 실패 수정, 병합까지 단일 작업 흐름으로 수행할 수 있다.
이 수준은 모델 능력만으로 자동으로 얻어지지 않고, 리포지터리 구조·도구·관측 가능성·규칙이 함께 쌓였을 때 도달하는 "시스템 임계점"에 가깝다.
엔트로피(드리프트)는 자동 가비지 컬렉션으로 관리한다
에이전트는 기존 패턴을 복제하므로, 최적이 아닌 패턴도 빠르게 퍼뜨릴 수 있다.
사람이 주기적으로 수동 정리하는 방식은 확장되지 않기 때문에, "황금 원칙"과 정기 정리 작업을 리포지터리에 인코딩해 편차를 탐지하고, 품질 등급을 갱신하며, 타깃 리팩터링 PR을 자동 생성·병합하는 식의 가비지 컬렉션 루프가 필요해진다. (스케쥴링을 통한 정리 작업 - 랄프 루프 등)
기술 부채를 "한 번에 갚는 대출"이 아니라 "매일 이자를 바로 납부하는 자동이체"로 바꾸는 발상이다.
인사이트
에이전트 우선 개발의 승부처는 모델이 아니라 시스템이다.
당장 적용한다면, (1) 에이전트가 스스로 확인 가능한 관측 신호(로그·메트릭·UI 재현 경로)를 먼저 깔고, (2) 지식은 거대 매뉴얼이 아니라 짧은 지도+구조화된 기록으로 관리하며, (3) 아키텍처·취향은 문장으로 설득하지 말고 린터·테스트로 강제하고, (4) 드리프트 정리를 "정기 자동 작업"으로 만들어 사람이 병목이 되지 않게 설계하라.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.