AI 코딩 에이전트를 위한 결정론적 거버넌스 레이어의 필요성

문제점: 거대한 AI 코드 diff의 혼란

자율적인 코딩 도구는 전체 구현을 실행하고, 스크립트를 돌리며, 몇 초 만에 수백 줄의 코드를 커밋할 수 있습니다. 하지만 이러한 도구를 사용하는 개발팀을 관리했거나 복잡한 기능을 혼자 구축해 본 경험이 있다면, 아마도 거대한 코드 diff를 마주했을 것입니다.

단 하나의 모호한 프롬프트가 기술 리드(tech lead)가 자신 있게 검토하는 데 몇 시간이 걸리는 대규모의 다중 파일 PR로 변모합니다. 기능은 구축되지만, 단계별 제품 근거와 아키텍처 결정 사항은 종종 휘발성 채팅 기록 속에 사라집니다. 해결책은 엄격한 워크플로우 가드레일(guardrails)을 적용하는 것입니다.

저는 주요 명세 기반 개발(spec-driven development, SDD) 워크플로우를 모두 시도해 보았고, 제가 발견한 것은 이들이 제품 형태에 90% 초점을 맞추고 실제 구현에는 훨씬 적게 집중한다는 것이었습니다. 이는 실용적이고 의례적인 절차가 적으면서도 컨텍스트와 유연성 면에서 견고하다고 좋아하는 get-shit-done의 경우에도 마찬가지입니다.

하지만 저는 더 전문화된 무언가가 필요했습니다.

Get Tasks Done 소개

저는 AI 지원 개발을 위한 경량의 결정론적 상태 기계 레이어(deterministic state machine layer)를 제공하기 위해 get-shit-done에서 Get Tasks Done을 구축했습니다. 이는 GitHub 네이티브 통합을 활용하여 고수준의 인간 의도와 실행 AI 에이전트 간의 격차를 해소하며, 명세(specifications)를 세분화된 실행 작업으로 변환합니다.

유동적이고 예측 불가능한 구현 단계 대신, GTD는 개발을 다음과 같은 명시적이고 감사 가능한(auditable) 단계로 구조화합니다:
제품 의도 ➔ 마크다운 명세 ➔ 세분화된 GitHub 이슈 ➔ 원자적 PR

아키텍처: 에이전트 레이어의 가드레일

시스템은 다섯 가지 개별 레이어를 걸쳐 조정됩니다:

계획 아티팩트(Planning Artifacts)

로컬 마크다운 계획 템플릿은 작고 고도로 제한된 프롬프트 경계를 강제합니다. 정보를 단단하게 국지화함으로써 컨텍스트 드리프트(context drift)가 현저히 감소합니다. 저는 여기에 계획 작업이 드리프트를 피하기에 충분히 원자적임을 보장하는 철저한 작업 분해(task decomposition) 게이트를 추가했습니다 (심지어 더 저렴한 모델로 실행되도록 합니다).

런타임 명령어 및 상태

결정론적 도구(Deterministic tools)는 에이전트가 상태 기계(state machine)를 읽는 방식을 관리하여 성공/실패 신호를 표준화합니다.

GitHub 작업 이슈

로컬 계획 단계(local planning phase) 동안 매핑된 모든 계획 작업은 그 의존성 트리와 함께 GitHub 이슈로 직접 내보내집니다.

격리된 PR 추적

에이전트는 해당 개별 이슈에 연결된 브랜치에 엄격하게 제한된 범위 내에서 작업을 실행하여 코드 격리(code isolation)를 보장합니다. 자율적인 **작업 오케스트레이션(task orchestration)**은 여러 에이전트를 사용하여 단일 단계에서 여러 작업을 구현할 수 있지만, 결국 PR을 통해 인간의 개입(human-in-the-loop)을 유지합니다.

실제 ROI: 이것이 나의 SDLC를 어떻게 변화시켰나

최고 기술자로서 개인 프로젝트에서도 모범 사례를 적용하는 저는 승인하는 데 2분밖에 걸리지 않는 원자적이고 단일 의도(single-intent)의 PR들을 검토하기 시작했습니다. 저는 제가 작업하고 있는 코드베이스에 대한 통제권을 되찾았습니다. 독립 개발자로서, 에이전트가 손상된 구현이나 리팩터링에서 루프를 돌리면서 발생하는 막대한 토큰 소모 비용을 지불하는 것을 멈췄습니다. 저는 그들을 작업에 고정시키고 명확한 경계 내에 두었습니다.

오픈 소스 및 다음 단계

GTD는 완전히 오픈 소스이며, 로컬 우선(local-first)으로 설계되었고 SDK 덕분에 기존 터미널 및 CI 설정과 원활하게 인터페이스할 수 있습니다. 이는 원래 저장소에서 상속받은 기능입니다.

코드를 확인하고 전체 사양을 읽거나 GitHub ai-is-gonna/get-tasks-done에서 제 실행 계층에 기여해 주세요. 여러분의 엔지니어링 팀이 에이전트 워크플로우를 어떻게 다루고 있는지 의견을 듣고 싶습니다!

연결하기!

• 저장소 스타: 오픈 소스 AI 가드레일을 지원하고 싶다면 GitHub에 별표를 눌러주세요 ⭐
• 여정 팔로우: 저는 X(이전 Twitter)에서 AI 에이전트 시대의 엔지니어링에 대한 일일 통찰력을 공유합니다: @iltroiani
• 피드백: 팀에서 에이전트 워크플로우를 어떻게 다루고 있나요? 아래 댓글에서 논의해 봅시다!