TL;DR

• AI에게 프로세스나 컨텍스트(Context) 관리를 통째로 맡기면, 추측이 발산하여 폭주와 파탄을 초래한다.
• 이를 방지하려면 아키텍처(Architecture)를 통해 AI의 행동에 물리적인 "가드레일(Guardrail, 경계선)"을 설치해야 한다.
• **"티켓(Issue)에 의한 경계선 설정"**과 **"Git에 의한 절대적인 상태 관리"**를 결합한 『티켓 주도 개발(TiDD, Ticket-Driven Development)』은 현재 우리가 효능감을 느끼고 있는 매우 현실적이고 강력한 접근법 중 하나이다.

AI에게 코드 수정이나 기능 추가를 요청했을 때, 다음과 같은 경험을 한 적이 없으신가요?

"지시한 요구사항에서 벗어나 멋대로 무관한 코드를 쓰기 시작한다"
"자료 작성을 부탁하면 레이아웃이나 포맷을 멋대로 망가뜨린다"

이러한 AI의 폭주는 우리가 AI에 대해 **오픈 루프(Open Loop, 피드백과 경계선이 없는 상태)**로 자유로운 추론을 허용해 버리는 시스템 설계의 결함에서 발생합니다.

"프롬프트(Prompt)를 다듬어 AI를 똑똑하게 움직인다"라는 접근 방식에는 한계가 있습니다.

필요한 것은 **"아키텍처(Architecture, 구조)를 통해 AI의 폭주를 물리적으로 봉쇄한다"**라는 제어 공학적인 시점입니다.

AI를 안전하게 업무 파이프라인에 편입시키기 위해서는 "사고의 제어", "표현의 제어", "상태의 동기화"라는 세 가지 기둥이 필요합니다.

TiDD 자체는 이미 많은 개발 현장에 침투한 기법이지만, AI 주도 개발(AI-Driven Development)에 있어서는 그 의미가 완전히 다릅니다.

인간 엔지니어라면 "티켓의 스코프(Scope) 외의 코드는 건드리지 않는다", "분위기를 파악해 의도를 헤아린다"라는 암묵적인 상식이 작동합니다. 하지만 확률적인 추론 엔진(Inference Engine)인 AI에게는 그것이 없습니다. AI는 국소적인 최적화를 추구하며 관계없는 파일까지 새로 쓰거나, 전체 설계를 파괴하는 Diff를 아무렇지 않게 출력하는 고유한 경향(약점)을 가지고 있습니다.

그렇기에 AI에게 "알아서 잘 개발해줘"라고 통째로 맡기는 것이 아니라, 프로세스를 다음과 같은 피드백 제어계(Feedback Control System)로 재정의하여 AI의 사고에 "물리적인 가드레일"을 설치해야 합니다.

목표값(제약): 티켓(Issue) -
조작량(출력): AI가 생성하는 코드 차분(git diff) -
제어 대상(상태): Git 리포지토리(Repository)

(※ 엄밀한 제어 이론으로서의 게인(Gain)이나 무효 시간(Dead time)을 논하는 것이 아니라, 어디까지나 "비결정적인 AI를 안전하게 운용하기 위한 강력한 멘탈 모델(비유)"로 파악해 주세요)

AI에게는 항상 "현재 활성화된 단일 티켓(Issue)"만을 부여합니다. AI의 업무는 "해당 티켓의 요구사항을 충족하는 최소한의 git diff를 출력하는 것"으로만 제한됩니다.

여기서 중요한 점은 "AI가 자발적으로 경계선을 지켜주는 것이 아니다"라는 점입니다. 인간과 달리 AI는 틈만 나면 티켓 외의 코드까지 멋대로 수정하려고 합니다.

인간의 PR 리뷰가 "성선설에 기반한 최종 확인"인 것에 반해, 여기서의 리뷰는 "AI의 폭주를 전제로 한 필수 검열 게이트"로서 기능합니다.

이 아키텍처에서는 반드시 **"인간의 리뷰와 Git으로의 커밋(Commit)"**이 크리티컬 패스(Critical Path)에 개입하며, 출력된 Diff가 티켓의 경계선을 벗어나 있다면 인간이 리젝트(Reject)하고, 문제가 없다면 커밋하여 상태를 확정합니다.

프로세스를 인간이 쥐고 Git이라는 물리적인 검문소를 설치함으로써, AI 특유의 "컨텍스트(Context)의 폭주"를 물리적으로 차단할 수 있게 된 것입니다.

인간의 작업이라면 "레이아웃이 조금 깨지면 미세 조정하면 된다"로 끝나지만, AI는 확률적인 흔들림을 가지기 때문에 표현의 자유도를 주면 매번 비결정적인 레이아웃 파괴를 반복한다는 고유한 문제가 있습니다.

이를 방지하기 위해 표현(View)과 데이터(Model)를 철저하게 분리합니다.

AI에게는 시스템 프롬프트 등을 통해 "순수한 텍스트나 소스 코드(Model: 주로 Markdown)만을 출력하라"고 엄명하여, 장식이나 PDF화와 같은 표현(View)의 권한을 완전히 박탈합니다.

View의 생성(컴파일)은 AI가 아니라 CI(GitHub Actions 등) 상의 스크립트에 맡깁니다.

이와 같이 "결정론적인 스크립트"에 표현을 위임함으로써, AI의 변덕에 의한 레이아웃 깨짐이 구조적으로 발생하지 않게 됩니다.

"소스 코드와 문서가 영원히 괴리되어 부패해 간다"는 현장의 영원한 과제.

인간끼리라면 "암묵적인 기억과 아웅다웅하는 호흡"으로 어떻게든 되는 경우도 있지만, AI에게 정확한 문맥을 갖게 하여 기능시키려면 "절대적으로 신뢰할 수 있는 현재 상태(SSOT, Single Source of Truth)"가 필수불가결합니다.

위의 기둥 1과 기둥 2를 통해 소스 코드와 자료 모두 「Git으로 관리되는 순수한 텍스트」로서 안전하게 다룰 수 있는 상태(이른바 Docs as Code 체제)가 완성되면, 이 과제 또한 자동으로 해결됩니다.

AI에게 「Git의 최신 코드 차이점 (Diff, 확정된 사실)」을 읽히고, 그에 따라 「마크다운 문서 (Markdown Document)」를 수정하도록 하는 플로우를 구축함으로써, AI가 할루시네이션 (Hallucination, 추측에 의한 거짓말)을 일으키는 것을 줄이고 사양서를 항상 최신 상태로 유지할 수 있습니다.

「인간이 프로세스를 통제하고, AI에는 실행에만 전념하게 한다」.

이 TiDD (티켓 기반 개발, Ticket-Driven Development) 접근 방식에서 엔지니어의 주된 업무는 「제로 베이스에서 코드를 타이핑하는 것」이 아니게 됩니다.

「AI의 출력 속도에 인간의 리뷰가 따라가지 못하게 되지 않을까?」라는 우려는 타당합니다. 하지만 제로 베이스에서 타이핑하던 시간을 모두 「요건의 분할 (티켓화)」과 「리뷰」에 집중할 수 있게 되기 때문에, 결과적으로 스루풋 (Throughput, 처리량)은 압도적으로 향상됩니다.

AI에 대해 **「적절한 기억 (티켓과 Git 이력)을 부여하고, 출력된 차이점 (Diff)을 감사하며, 다음 상태로 확정시키는 컨텍스트 (Context)의 관리자」**가 되는 것.

이것이야말로 AI의 장점을 최대한 끌어내면서도 폭주 리스크를 억제하는 「현대 엔지니어링의 최적해 중 하나」가 아닐까 생각합니다.