에이전트가 혼자 일하는 팀, 실제로 가능한가
'자율 에이전트가 이슈를 스스로 클레임하고, 코드를 작성하고, QA 시나리오를 돌리고, 커밋까지 붙여서 완료 처리한다.' 이게 실제로 돌아가는 시스템이 있다. Fiberplane의 Otter 프레임워크가 그 구현체다. Claude Code 기반의 이 자율 코딩 에이전트 시스템은 fp라는 로컬 이슈 트래커를 통해 작업 생명주기를 통제하고, ast-grep으로 아키텍처 규칙을 강제하며, drift로 QA 시나리오 문서의 신선도를 유지한다. 팀원이 자리를 비워도 에이전트는 할당된 이슈 트리를 따라 작업을 이어간다.
이 시스템의 핵심은 에이전트가 '알아서 판단'하도록 놔두는 게 아니라, 판단 가능한 범위를 설계로 미리 가둬두는 구조다. FP_AGENTS.md가 세션 플로우를 정의하고, check-before-done 훅이 bun run check 통과 전에는 이슈 완료를 물리적으로 막는다. 에이전트가 컨텍스트 압축 직전에 반드시 커밋하도록 유도하는 규칙도 있다. '자율'처럼 보이지만, 실제로는 인간이 설계한 제약의 격자 위에서 돌아가는 구조다.
자동화가 흡수하지 못하는 것들
그렇다면 이 구조에서 인간 개발자는 무엇을 하는가. dev.to에 올라온 AI-Augmented 개발자 역할 분석 글은 이 질문에 구체적인 답을 준다. AI가 반복 구현을 흡수할수록, 개발자의 시간은 세 방향으로 재분배된다. 아키텍처 설계, 의도 명세(intent specification), 그리고 검증 설계다.
Otter 사례가 이 세 가지를 잘 보여준다. 에이전트에게 넘기기 전에 인간이 해야 하는 가장 중요한 작업은 '이슈 잘 쓰기'다. 모호한 이슈는 에이전트가 의도를 추측하게 만들고, 그 추측은 자율 세션에서 수정되지 않은 채 커밋으로 굳는다. 제목, 컨텍스트, 하위 이슈 분해—이 작업이 잘 되어 있어야 에이전트의 실행 경로가 예측 가능해진다. 이건 코드 작성 능력이 아니라 요구사항을 기계가 처리 가능한 단위로 쪼개는 설계 능력이다.
마찬가지로 QA 시나리오 설계도 인간의 영역이다. 어떤 명령을 실행하면 어떤 출력이 나와야 하는지를 drift 앵커로 고정해놓지 않으면, 에이전트가 코드를 바꿨을 때 시나리오가 조용히 낡아버린다. 컴파일 에러는 나지 않지만, 테스트는 더 이상 현재의 동작을 검증하지 않는 상태가 된다. 이 drift를 설계 단계에서 방지하는 것—이것도 에이전트가 할 수 없는 인간의 판단 영역이다.
신뢰는 쌓이는데 만족도는 왜 떨어지나
그런데 현장 분위기는 이 방향과 좀 어긋난다. Stack Overflow 2025 개발자 설문(49,000명 참여)에 따르면 현재 업무에 만족하는 개발자는 24%에 불과하다. 그리고 AI 도구 신뢰도는 작년보다 낮아졌다. 84%가 AI 도구를 쓰고 있거나 쓸 예정이지만, 46%는 AI 출력물을 신뢰하지 않는다고 답했다. 긍정 감정 비율은 1년 사이 70%대에서 60%대로 빠졌다.
이 수치가 불편한 이유는, 에이전트 도입의 서사와 정반대이기 때문이다. 도구를 더 많이 쓰는데 더 안 믿고, 더 빨리 만드는데 더 불행하다. 설문 응답자들은 AI가 '거의 맞지만 완전히 틀린' 코드를 자신감 있게 내놓고, 그걸 디버깅하는 데 오히려 시간이 더 든다고 말한다. 내가 만든 게 아니라 내가 고친 게 되어버리는 경험—이것이 '문제 해결'이라는 개발자 본연의 만족감을 갉아먹는 구조다.
Otter 같은 시스템이 주목받는 이유가 여기 있다. 에이전트를 그냥 풀어놓으면 디버깅 비용이 팀 전체로 분산되지만, 검증 레이어를 설계로 구워놓으면 그 비용이 대폭 줄어든다. bun run check가 oxlint, tsgo, ast-grep, drift lint를 한 번에 돌리고, 하나라도 실패하면 에이전트가 스스로 읽고 고치고 재실행한다. 인간이 리뷰할 때는 이미 기계적 오류가 걸러진 diff만 보면 된다. 이건 '에이전트를 믿는' 구조가 아니라, '에이전트가 틀려도 잡히는' 구조다.
팀 리드가 설계해야 할 것들
AI-First 팀 리빌딩 관점에서 Otter 사례가 주는 시사점은 명확하다. 자율 에이전트가 작동하는 팀에서 팀 리드의 설계 대상은 '코드'가 아니라 에이전트가 작업을 수행하는 제약 구조 그 자체다.
첫째, 이슈를 에이전트가 처리 가능한 단위로 분해하는 기준을 만들어야 한다. 추상적인 에픽이 아니라, 하위 이슈 단위로 쪼개고, 각 이슈에 충분한 컨텍스트를 담는 작성 관례가 필요하다.
둘째, 검증 레이어를 코드베이스에 내장해야 한다. 스타일 검사, 타입 검사, 아키텍처 규칙, QA 시나리오 신선도 검증—이것들이 CI처럼 자동으로 실행되고 실패 시 에이전트의 완료 처리를 차단해야 한다.
셋째, 에이전트가 남긴 감사 추적을 읽는 루틴이 필요하다. fp의 이슈 코멘트, Effect 트레이스, 커밋 히스토리—이것들이 팀 리드가 '세션 이후 무슨 일이 있었는지' 재구성하는 도구가 된다. 에이전트 관리는 코드 리뷰가 아니라 감사 로그 해석에 가까워진다.
전망: 병렬 에이전트가 오면 더 복잡해진다
Otter 팀도 솔직하게 인정한다—현재 fp 워크플로우는 에이전트 한 명이 순차적으로 이슈를 처리하는 시나리오에 최적화되어 있다고. 의존 관계가 있는 태스크, 혹은 여러 에이전트가 같은 코드베이스를 병렬로 수정하는 시나리오는 아직 풀지 못한 문제다.
이 문제가 열리는 순간, 팀 구조 설계의 복잡도는 한 차원 올라간다. 에이전트 간 작업 분배, 충돌 해소, 품질 책임 소재—이것들은 기술 문제인 동시에 조직 설계 문제다. 그리고 그 설계를 인간이 해야 한다는 사실은 변하지 않는다.
코드베이스가 스스로 달리기 시작하는 시대에, 팀원이 하는 일은 더 적어지는 게 아니라 더 높은 추상도로 이동한다. 에이전트를 대신해 코드를 짜는 사람은 필요 없어지지만, 에이전트가 올바른 코드를 짤 수 있는 조건을 설계하는 사람—그 역할의 밀도는 오히려 올라가고 있다.