TL;DR

• 「AI 어시스턴트에게 역할을 부여하여 알아서 스크럼 개발을 하게 만들자」라고 2.5개월간 시도했으나, 프로세스는 보기 좋게 붕괴되었다
• 프로세스 무시, 할루시네이션 (Hallucination)의 연쇄, 물리적인 파일 충돌로 인한 머지 지옥(Merge Hell) 등 AI의 추론 특성에 기인한 5가지 현상을 확인
• 현재의 AI에게 자율적인 프로세스 관리를 통째로 맡기는 것은 시기상조이다. 다만, AI가 진지하게 폭주하는 모습을 관찰하는 2.5개월의 시행착오는 순수하게 즐거웠으며, 현실적인 접근 방식(인간이 통제하고 AI가 실행)으로 전환하는 좋은 계기가 되었다

문득, 「AI에게 프롬프트로 『당신은 PO, 당신은 스크럼 마스터, 그리고 당신은 개발자야』라고 역할을 부여하면, 자동으로 스크럼 개발을 진행해 주지 않을까?」라는 나태한 생각에서 AI 스크럼 개발을 시도해 보았습니다.

전용 멀티 에이전트 프레임워크(Multi-agent Framework) 등은 사용하지 않고, 평소 사용하던 CLI형 AI 어시스턴트에 프롬프트로 지시를 내리는 것만으로 구성한 경량 검증 구성입니다.

하지만 검증 자체는 본격적이어서, 평소의 일상적인 소프트웨어 수정 작업을 모두 이 「AI 스크럼 개발」로 대체하여, 실제 개발 사이클 속에서 기능하는지를 일부러 장기간에 걸쳐 테스트해 보았습니다.

그러나 결과적으로 AI에게 프로세스 관리를 통째로 맡기는 것은 극히 어려웠으며, AI에 의한 「나홀로 스크럼」은 보기 좋게 붕괴되었습니다.

본 기사에서는 그 과정에서 일어난 「AI 특유의 스크럼 붕괴 현상」에 대해 비망록으로서 정리해 둡니다.

약 2.5개월간 실제 수정 작업을 통해 시행착오를 반복하며, 단일 AI 어시스턴트에게 스크럼 프로세스를 통째로 맡겨본 결과, 주로 다음과 같은 5가지 프로세스 붕괴가 확인되었습니다.

LLM은 본질적으로 「주어진 과제(프롬프트)에 대한 즉시 해결」을 지향합니다.

그렇기 때문에 「지금은 플래닝(Planning) 페이즈이다」라는 제약을 주어도, 백로그(Backlog) 상에 이슈(Issue)가 존재하면 프로세스를 무시하고 직접 코드 수정(해결)으로 뛰어들어 버리는 거동이 빈번하게 발생했습니다. 인간이 정의한 「프로세스나 의식(Ritual)의 준수」를 자율적인 에이전트에게 강제하는 것은 매우 어려운 일이었습니다.

플래닝 페이즈에서 프롬프트로 여러 역할을 부여하여 자율적으로 대화(계획 수립)하게 하려고 시도했으나, 단일 채팅 세션 내에서 롤플레이(Role-play)를 유지하는 것 자체가 어려웠습니다.

설령 역할을 (인격) 전환하며 대화하게 하더라도, 컨텍스트(Context)가 섞여 버려서 역할을 전환할 때마다 이전 역할의 잘못된 추측(할루시네이션 (Hallucination))을 비판 없이 이어받아, 요구사항에서 점점 벗어나 버리는 것이 고작이었습니다. 단일 AI를 이용한 자기 완결형 「대화를 통한 합의 형성」 프로세스는 현재의 가벼운 방식으로는 어차피 성립되지 않는다고 조기에 포기했습니다.

구현 페이즈에 들어가면, 이번에는 물리적인 파일 조작에 있어 다음과 같은 두 가지 점이 심각한 문제로 부상했습니다.

국소 최적화에 의한 설계 파괴: 버그 수정 등에서 AI는 시스템 전체의 설계를 고려하지 않고, 최단 시간 내에 동작하는 해결책을 즉시 적용하는 경향이 있습니다. 패치 코드로 해결해 버리고, 그 이후 그것이 대량으로 전체 코드를 오염시켰습니다. -
상태 동기화의 결여 (물리적인 파일 충돌): 전항의 플래닝이 「대화의 엇갈림」이었다면, 이것은 「물리적인 파일의 상호 덮어쓰기」입니다. AI 어시스턴트 스스로가 자율적으로 워크플로우(Workflow, 서브 태스크)를 나누고, 백그라운드에서 여러 작업을 병렬로 실행한 결과, 프로세스 간에 코드 변경 상황을 인식(파일 잠금 등의 협조)하지 못해 서로의 성과물을 덮어쓰는 사태가 발생. 최종적으로 머지 컨플릭트(Merge Conflict)가 다발하였고, 그 충돌 해결을 위해 AI가 리소스를 다 써버려, API 이용 비용(토큰 비용)과 시간을 끝없이 낭비하는 무한 루프에 빠졌습니다.

플래닝 시의 「대·중·소 (T-shirt Size)」 방식의 상대적 추정 자체는, 과거의 기준을 기록하게 함으로써 AI도 올바르게 수행할 수 있었습니다.

하지만 그것을 소화하는 「벨로시티 (Velocity) 측정」은 전혀 성립하지 않았습니다. 주요 원인은 다음 두 가지입니다.

• AI 스스로가 「현재 시각」을 정확하게 참조하지 못해, 작업에 걸린 경과 시간을 착각해 버린다.
• AI 측의 커맨드 실행 허가 대기 등, 시스템 측의 대기 시간이 노이즈로 혼입되기 때문에, 순수한 「태스크 소화 시간」을 측정할 수 없게 된다.

스프린트(Sprint) 종료 시의 레트로스펙티브(Retrospective, 회고)에서 AI에게 원인 분석과 개선책 제시를 요구했더니, 그럴듯한 반성문을 출력해 주었습니다.

하지만 LLM (Large Language Model)의 구조상, 텍스트를 통한 피드백이 다음 세션의 영구적인 행동 기준(가중치)으로 직접 반영되지는 않습니다. 프로젝트의 규약 파일(AI용 규칙 정의 등)에 아무리 반성 사항을 기록하더라도, 다음 스프린트(Sprint)에서 완전히 동일한 실수가 끊임없이 반복되는 결과로 끝났습니다.

위의 과제에 대해, "인간이 PO (Product Owner) 및 스크럼 마스터 (Scrum Master)를 겸임하며, AI의 행동을 그때마다 관리·수정한다"는 운영 방식으로 전환해 보았습니다.

이를 통해 스크럼으로서의 형태는 간신히 유지할 수 있었으나, 인간 측에 가해지는 마이크로매니지먼트 (Micromanagement) 부하가 극도로 높아져, "개발 프로세스의 자동화·효율화"라는 당초의 목적에서 완전히 벗어나는 결과가 되었습니다.

이번 검증을 통해 얻은 교훈은 다음과 같습니다.

장단점의 경계선 발견: LLM은 "주어진 과제를 최속으로 해결하는 것"에 있어서는 천재적이지만, "인간과 마찬가지로 프로세스를 관리하고 애자일 (Agile) 의식을 준수하는 것"은 근본적으로 서툽니다. 이 경계선을 명확히 그을 수 있었던 것이 가장 큰 수확이었습니다. -
단일 AI에 의한 "1인 스크럼"으로부터의 졸업: 프롬프트 (Prompt)만으로 여러 명의 역할을 나누어 연기하게 하는 접근 방식은 컨텍스트 붕괴 (Context Collapse)를 일으킵니다. AI에게는 "역할"이 아니라 "명확하게 구분된 단일 태스크 (Task)"를 부여해야 한다는 것을 알게 되었습니다. -
전용 프레임워크의 가능성과 LLM의 현주소: "전용 멀티 에이전트 프레임워크 (Multi-agent Framework) 등을 사용하면 해결되지 않을까?"라는 의견도 있을 것입니다. 확실히 파일 충돌(사건 3)이나 시간 측정(사건 4)은 완화할 수 있습니다. 하지만 프로세스 무시(사건 1)나 할루시네이션 (Hallucination, 환각)의 연쇄(사건 2)와 같이 LLM의 추론 특성 그 자체에서 기인하는 과제는 남습니다. 그렇기에 억지로 AI끼리 협조하게 만들기보다, 지금의 AI 강점을 100% 활용할 수 있는 다른 아키텍처 (Architecture)를 모색할 여지가 있습니다.

마치며: 실패를 즐긴다는 지견

"전자동 스크럼 개발"은 아직 꿈의 연장선에 있었지만, 이것이 결코 비관적인 결말은 아닙니다.

AI에게 프로세스 관리를 통째로 맡길 수 없다는 것을 알게 됨으로써, "인간이 프로세스를 통제하고, AI에는 실행에만 전념하게 한다"는 현실적인 접근 방식으로 전환하는 좋은 계기가 되었습니다.

무엇보다 이 2.5개월에 걸친 "AI가 성실하게 폭주하며 멋지게 자멸해 가는 모습"을 관찰하는 시행착오의 과정 자체가 기술적으로 매우 자극적이고 순수하게 즐거운 시간이었습니다.

본 기사가 AI 활용을 위해 시행착오를 겪고 계신 여러분께, 피식 웃음이 나는 현시점의 안티 패턴 (Anti-pattern)으로서 즐거움을 드릴 수 있다면 좋겠습니다.