목적

본 구상의 목적은 AI를 단순한 코딩 지원이나 부분적인 코드 리뷰 도구로 이용하는 단계를 넘어, 일상적인 업무 전체나 시스템 개발 프로세스 전체(요구사항 정의, 설계, 구현, 테스트, 운영)를 자율적으로 추진·제어하는 메커니즘을 제안하는 것이다.

개발 프로세스를 추상화하고, AI가 현재 위치(Phase/State)를 이해하여 자율적으로 태스크를 실행할 수 있는 구조를 만듦으로써, 인간은 '작업자'에서 '프로젝트 책임자(Gatekeeper / PM)'로 입지를 변경하고, 시스템의 개발 속도와 품질을 비약적으로(고도화 및 고속화) 향상시키는 것을 목표로 한다.

개요

우리의 상시 업무나 시스템 개발은 상태와 전이 조건으로 정의되는 **"유한 오토마톤 (Finite State Machine: FSM)"**으로 표현 가능하다.

예를 들어 시스템 개발은 V-모델로 표현되는 경우가 많다.

본 모델에서는 현재의 페이즈(State) 및 접근 가능한 성과물(Context)을 외부 스토리지에 유지하고, AI가 항상 이를 참조하게 함으로써 다음에 수행해야 할 태스크를 결정·실행하게 한다.

인간의 역할은 각 페이즈 간을 전이하는 경계 조건(Definition of Done: DoD)에서의 "성과물 승인·의사결정"으로만 한정한다. 이를 통해 기존 SIer에서의 "다수의 멤버를 통괄하는 PM / 최종 결정자"의 입지에 인간을 배치하고, 실제 개발 작업의 대부분을 AI 군단에 위임하는 개발 체제를 실현한다.

이후에는 시스템 개발 케이스를 예로 들어, AI 자율 구동형 시스템 개발 모델의 구상을 정리한다.

내용

1. 상태 전이 (유한 오토마톤) 모델

결정론적 상태 관리: 시스템 개발의 각 공정(요구사항 정의, 기본 설계, 상세 설계, 구현, 단체 테스트, 통합 테스트 등)을 State로 엄격하게 정의한다. AI의 컨텍스트 내에서 상태 전이를 관리하지 않고, 결정론적인 워크플로우 관리 도구로 관리한다.

컨텍스트·성과물 스토어: Git 리포지토리 등의 외부 스토리지를 Single Source of Truth (SSOT)로 삼고, 각 State의 출력 성과물(Markdown 형식의 사양서, PlantUML, 코드, 테스트 결과 등)을 원자적(Atomic)으로 버전 관리한다.

현재의 페이즈를 항상 외부에서 확인할 수 있는 장소에 배치하여 인간이 AI의 현재 위치를 파악할 수 있도록 함과 동시에, 여러 AI가 서로 다른 State의 태스크를 수행하지 않도록 제한할 수 있다.

또한, 기존 개발 방법론의 지식과 자산을 활용하여 Git 등을 활용해 성과물의 버전 관리를 수행한다.

2. Actor-Critic (작성자·비판자) 멀티 에이전트 구조

Actor (작성자 에이전트): 지시된 State에서의 성과물(설계서나 코드)을 "작동하는 것·요건을 충족하는 것"으로서 생성한다.

Critic (비판자 에이전트): Actor가 생성한 성과물에 대해 요구사항 누락, 보안 취약점(Security Hole), 비기능 요구사항, 에지 케이스(Edge Case) 등의 관점에서 철저하게 적대적(Adversarial) 리뷰·검증을 수행한다.

기존 개발 방법론의 지식을 활용하여 QA 엔지니어 등의 리뷰어로 Critic을 위치시킨다.

3. 인간 (Gatekeeper)의 의사결정 모델

• 인간은 코드나 설계서의 모든 행을 정독하지 않고, Critic 에이전트의 검증을 통과한 성과물에 관한 "요약 보고" 및 "트레이드오프(Trade-off)·리스크 제시"를 받고 Go / No-Go 판정을 내린다.
• 인간의 승인(Pull Request의 머지 등)이 상태 전이(Next State)의 물리적인 트리거가 된다.

기존 개발 방법론에서도 페이즈의 이행은 PM의 승인을 거쳐 이루어지는 경우가 많으며, AI 자율 구동형 시스템 개발 모델에서도 동일한 의사결정 프로세스를 답습한다.

과거에 검토한 사항

본 모델의 실현 가능성 및 견고성을 검증하기 위해 다음과 같은 관점에서 검토를 수행하였다.

1. 비가역적인 상태 파탄 (되돌리기·백트랙 시의 성과물 불일치)

우려 사항: 테스트 단계에서 요구사항 정의의 오류가 판명된 경우 등, 과거의 State로 돌아갈 때의 차분 클린업(오래된 불일치 코드나 설계서의 정리)이 복잡해져 AI가 수렴하지 못하게 될 리스크.

결론: "전체 폐기·재생성 (Reset & Rebuild)" 채택. AI의 생성 속도가 매우 빠르다는 것을 전제로 하여, 복잡한 차분 업데이트 및 정합성 유지에 비용을 들기보다는, 전제 조건(입력 사양)을 수정한 후 대상 State 이후의 성과물을 모두 폐기하고 처음부터 재생성하는 것이 더 심플하고 안전하다고 정리하였다.

이는 기존의 개발 방법론에서도 발생했던 문제로, 폭포수(Waterfall)형 개발은 이를 줄이는 데 주력하고, 애자일(Agile)형 개발은 이를 허용하는 대신 재작업(Rework)의 최소화를 도모하고 있다.

AI 자율 구동형 시스템 개발 모델에서는 AI의 생성 속도를 전제로 할 때, 애자일형 개발 이상의 규모로 '전체 폐기 및 재생성(Reset & Rebuild)'을 허용하는 것이 가능하며, 재작업 비용을 대폭 절감할 수 있다.

2. 경계 조건(Definition of Done: DoD)의 모호함

우려 사항: "사양을 충족하는가", "적절한 설계인가"와 같은 감각적·정성적인 DoD를 AI만으로 판정할 경우, 얕은 수준의 성과물인 상태로 단계가 진행되어 버릴 리스크.

결론: 인간(Gatekeeper)에 의한 의사결정 포인트로 설정. DoD의 최종 확인 및 상태 전이(State Transition)의 승인 권한을 인간에게 부여함으로써, 모델의 폭주를 확실히 방지한다.

단, 모든 상태 전이를 인간이 판단하면 AI의 자율성이 손상되므로, 프로젝트의 규모나 성격에 따라 DoD 승인 포인트를 적절히 설정할 필요가 있다.

3. 공모(Collusion)와 컨텍스트 공유에 의한 맹점

우려 사항: Actor와 Critic이 동일한 문맥(Context), 프롬프트, 전제 조건을 공유하고 있을 경우, 요구사항의 오인이나 사양의 빈틈에 대해 '같은 착각'을 일으켜 적절한 리뷰가 이루어지지 않을 리스크.

결론: 컨텍스트의 완전 분리(Context Separation). Actor와 Critic 사이에서 문맥을 공유하지 않도록 하며, Critic에게는 최종 요구사항 정의서와 성과물만을 '블랙박스 형태의 제3자'로서 제공함으로써 독립적인 객관적 검증을 담보한다.

이 또한 기존의 개발 방법론에서 발생하기 쉬운 문제로, 리뷰 담당자가 설계자와 동일한 문맥을 가질 경우 리뷰의 맹점이 생길 수 있다.

또한, 리뷰어가 리뷰 대상자(Reviewee)나 상급자에게 눈치를 보며(忖度, Sonntaku) 리뷰를 타협하는 경우도 있다.

AI 자율 구동형 시스템 개발 모델에서는 Actor와 Critic의 문맥을 분리함으로써 리뷰의 맹점을 최소화할 수 있다.

나아가 AI는 눈치를 보지 않기 때문에, Critic은 Actor의 성과물에 대해 철저한 리뷰를 수행하는 것이 가능해진다.

4. 보고 요약에서의 정보 결손 및 인간의 컨텍스트 상실

우려 사항: AI의 요약 보고에 의존함으로써 중대한 리스크를 간과할 가능성이나, 상세 내용을 파악하지 못한 인간이 적절한 의사결정을 내리지 못하게 될 리스크.

결론: 현행 인간 조직과 동일한 수준의 리스크로 허용. 대규모 개발에서의 기존 PM·의사결정자들 또한 마찬가지로 보고·요약 기반의 의사결정을 수행하고 있으며, 이는 현실적인 트레이드오프(Trade-off)로서 허용 가능하다고 판단한다.

이 역시 기존의 개발 방법론에서 발생하기 쉬운 문제이며, 적절하게 과부족 없는 보고를 수행하는 것은 어렵다.

기존에는 보고자가 상급자의 의도에 눈치를 보며 보고 내용을 조정하거나, 보고자에게 불리한 정보를 숨기는 경우가 있었다.

AI 자율 구동형 시스템 개발 모델에서는 AI는 눈치를 보거나 정보를 은폐하지 않으므로, 리스크가 저감된다고 볼 수 있다.

Future works

최소 구성 PoC(개념 실증) 구축- CLI 도구 및 소규모 모듈에 대한 기능 추가(Issue 1건에 대한 사양 결정 → 설계 → 구현 → 테스트의 1사이클)를 자동 실행하는 프로토타입 엔진의 구축 및 검증.

Actor-Critic 에이전트 간의 문맥 분리 프롬프트 설계- Critic 에이전트가 과도하게 타협하지 않으면서도 무한 루프에 빠지지 않기 위한 평가 기준 및 프롬프트 엔지니어링(Prompt Engineering) 확립.

결정론적 상태 관리 엔진과 GitOps의 통합- 상태 관리 수단과 GitHub API/GitOps 워크플로우를 연계하여, PR 생성 및 승인을 통한 자동 상태 전이 파이프라인을 구현한다.

결론

개발 프로세스 전체를 '유한 오토마톤(Finite Automaton)'으로 추상화하고, 상태 관리와 성과물 관리를 외부화한 상태에서, 문맥을 분리한 Actor-Critic형 AI 에이전트에게 자율 실행을 맡기는 접근 방식은 이론적·실용적으로 매우 강력한 모델이다.

AI의 '압도적인 생성 속도'를 전제로 함으로써, 기존의 재작업 비용을 '재생성(Reset & Rebuild)'을 통해 극복하고, 인간은 성과물의 경계 검증(DoD)과 최종적인 Go/No-Go 판단에만 리소스를 집중하는 것이 가능해진다.

본 구상은 단순한 작업 보조를 넘어선 'AI-Native형 시스템 개발'을 실현하며, 개발의 속도와 품질을 차원이 다른 수준으로 끌어올릴 가능성을 지니고 있다.

Discussion