코딩 에이전트(Coding agents)가 실패하는 이유는 단지 모델이 컨텍스트(context)가 부족하기 때문만은 아닙니다. 팀들은 모델을 둘러싼 워크플로(workflow) 또한 놓치곤 합니다. 즉, 무엇을 먼저 검사할지, 어떤 증거가 검증(verification)으로 간주될지, 언제 작업을 인계(handoff)할지, 그리고 언제 인간을 위해 멈춰야 할지에 대한 부분입니다.

AgentSmith는 이를 구성(composition) 문제로 정의하는 새로운 오픈 소스 에이전트 하네스(agent harness)입니다. 이 프로젝트의 공개 저장소(public repository)에는 공유된 core/, 작업 유형별 profiles/, hooks/, 그리고 setup.sh 엔트리 포인트(entry point)가 포함되어 있습니다. README에서는 다양한 종류의 작업에 적합한 프로필(profiles)을 사용하여 공통된 베이스라인(baseline)을 조립하는 방법을 설명합니다. Repository · README

이러한 구조가 유용한 점

안정적인 팀 가이드라인을 역할별 지침(role-specific instructions)과 분리함으로써 워크플로 드리프트(workflow drift)를 줄일 수 있습니다. 모든 프로젝트에 약간씩 다른 메가 프롬프트(mega-prompt)를 복사해 넣는 대신, 팀은 계획(planning), 검증(verification), 인계(handoff) 관례를 가시화하고 재사용할 수 있습니다. 이것은 워크플로 계층(workflow layer)이지, 코드 탐색 도구(code-navigation tools)를 대체하는 것이 아닙니다. grep, LSP, 파일 읽기 등은 여전히 코드베이스(codebase)에 대해 서로 다른 질문에 답을 제공합니다.

이것이 증명하지 못하는 것

지침 계층(instruction layer)은 런타임 격리(runtime isolation), 자격 증명 경계(credential boundaries), 네트워크 제한(network restrictions) 또는 운영 환경 승인(production approvals)을 강제하지 않습니다. 이러한 것들은 에이전트가 읽는 텍스트 외부에서 작동하는 제어 장치가 필요합니다. 즉, 최소 권한 접근(least-privilege access), 감사 추적(audit trails), 그리고 중대한 행동에 대한 명시적인 인간의 결정 등이 필요합니다. 설치 프로그램과 규칙 구조가 존재한다는 사실이 이러한 제어 장치들이 존재한다는 증거는 아닙니다.

이러한 구분은

만약 귀하의 팀이 이미 검토(Review) 및 CI 관례를 갖추고 있음에도 불구하고, 여러 에이전트(Agent)들에게 이를 반복해서 설명해야 하는 상황이라면 이 패턴을 연구해 볼 가치가 있습니다. 먼저 공유되어야 할 소수의 규칙 세트를 식별하는 것부터 시작한 다음, 프로젝트별 작업은 별도로 분리하십시오. 만약 실제 요구사항이 비밀 관리(Secrets management), 샌드박싱(Sandboxing), 또는 변경 승인(Change approval)에 있다면, 이러한 제어 평면(Control-plane) 문제들을 먼저 해결하십시오.

해당 저장소(Repository)는 MIT 라이선스를 따르며, 이번 검토 기간 동안 공개 릴리스(Public releases) 목록은 비어 있었습니다. 따라서 이를 성숙도의 증거라기보다는 초기 설계 참조(Early design reference)로 취급하는 것이 합리적입니다. Core 디렉토리 · Profiles 디렉토리 · License · Releases

테스트되지 않음 / 실행되지 않음: 이 기사는 공개 저장소 자료에 대한 읽기 전용 검토를 바탕으로 작성되었습니다. 저는 setup.sh를 실행하거나, 프로젝트를 설치하거나, 해당 프로젝트의 주장 또는 운영 동작을 독립적으로 검증하지 않았습니다.