요약(TL;DR): 저는 ai-flow-anything를 만들었습니다. 이는 코드베이스를 인터뷰하고, 프로젝트 유형을 감지하며, 코드와 대조하여 스스로 감사(audit)하는 지식 베이스(knowledge base)를 갖춘 디자인 우선(design-first) 플로우를 생성하는 마크다운(markdown) 네이티브 워크플로우 생성기입니다. 빌드 단계, CLI, DSL이 필요 없으며 오직 마크다운만 사용합니다. Claude Code, Cursor, GitHub Copilot, OpenCode, Kimi Code와 함께 작동합니다. MIT 라이선스입니다.

제가 씨름해 온 문제:
AI 코딩 어시스턴트(AI coding assistants)는 코드를 작성하는 데는 놀라울 정도로 뛰어나지만, 프로세스(process)에는 형편없습니다. 모든 새로운 작업이 마치 처음부터 시작하는 것처럼 느껴집니다. 디자인 문서(design doc), 아키텍처 컨텍스트(architecture context), 왜 그런 결정이 내려졌는지에 대한 흔적이 없습니다. AI는 생각하기 전에 코드를 작성합니다. 그리고 Claude, Cursor 또는 Copilot 사이를 전환할 때 모든 컨텍스트(context)를 잃게 됩니다. 또 다른 문제는 새로운 프로젝트로 이동할 때, 지난 프로젝트를 위해 미세 조정(fine-tuned)했던 모든 설정과 기술을 잃어버린다는 점입니다.

제가 원했던 것:

디자인 우선(Design-first) 및 강제화 — 디자인이 승인될 때까지 작업 코드를 작성하지 않으며, 모든 단계는 명시적인 [A]ccept(수락) / [F]eedback(피드백) / [R]eject(거절) 게이트에서 종료됩니다. AI는 자신의 작업이 완료되었다고 스스로 결정할 수 없습니다.
어떤 AI 어시스턴트와도 작동 (특정 도구에 종속되지 않음)
프로젝트 유형을 자동 감지하고 그에 따라 워크플로우(workflows)를 맞춤화함
변하지 않는 지식 베이스(knowledge base) — 단순히 방치되어 썩어가는 문서가 아님
디자인 → 구현(implement) → 테스트(test) → PR → 배포(deploy)까지 모든 작업을 추적

작동 방식:

프로젝트에 클론(Clone): git clone https://github.com/yusufkaraaslan/ai-flow-anything.git .ai-workflow
초기화 — AI가 프로젝트 유형(Unity, Godot, React, FastAPI, Flutter, …)을 감지하고, 코드베이스를 인터뷰하며, 목표에 대해 질문합니다.
9가지 맞춤형 플로우(flows) 확보 — 디자인, 구현, 프리(quick fixes), 병렬 구현(parallel-implement), PR, 테스트, 배포, 문서, KB 동기화

이 저장소(repo)는 두 개의 디렉터리를 제공합니다: .ai-workflow/** (엔진 — 지침, 범용 규칙, 스택별 프로필 및 9개의 렌더링된 플로우 파일) 및 **flow-storage/ (지식 베이스 — 프로젝트 아키텍처, 팀 문서, 그리고 불변의 디자인 문서, 엣지 케이스(edge cases), 다이어그램, 계획 및 학습된 교훈을 포함한 작업별 기록).

제가 개발한 과정:
저는 게임을 개발할 때 AI를 사용합니다. 작업하는 동안 반복되는 패턴을 찾아 기록해 둡니다. 두세 개의 작업에 걸쳐 충분한 메모가 수집되면, Claude를 사용하여 제가 수행 중인 작업의 일부를 자동화하는 기본적인 스킬(skill)을 만듭니다. 시간이 지나면서 이러한 스킬들은 개별 프로젝트와 다양한 유형의 작업에 맞춰 미세 조정(fine-tuned)되고 맞춤 제작됩니다. 그런 다음 새로운 게임으로 넘어가 워크플로(workflow)의 정수를 추출하고 이 과정을 반복합니다. 결국 시행착오를 거쳐 ai-flow-anything이 스스로 형성되었습니다.

실패를 포함하여 검증된 결과:
저는 제가 만들고 있는 Godot 및 Unity 게임에서 초기 버전을 4개월 동안 직접 사용(dogfooding)해 보았습니다. 작업별(per-task) 측면은 진정으로 잘 작동했습니다. 렌더링된 PlantUML 다이어그램을 포함한 전체 디자인 패키지를 통해 16개의 기능이 출시되었으며, 구현 계획(implementation plans)은 실제 커밋(commit)으로 이어졌습니다.

가장 마음에 드는 두 가지 부분은 다음과 같습니다: AI가 git worktree를 통해 독립적인 작업 패키지를 병렬로 구현하고 의존성 순서에 따라 병합(merge)한다는 점, 그리고 승인(sign-off) 후에는 디자인이 불변(immutable)이라는 점입니다(편차는 별도로 기록되므로 기록의 정직함이 유지됩니다).

하지만 작업 간 지식 베이스(cross-task knowledge base)는 조용히 노후화(stale)되었습니다. 몇 달이 지나자, 지식 베이스가 실제 코드베이스와 모순되었습니다(잘못된 테스트 프레임워크, 완화되었던 '엄격한' 제약 조건 등).

노후화된 지식 베이스(KB)는 비어 있는 것보다 더 나쁩니다. AI가 실행할 때마다 이를 신뢰할 수 있는 컨텍스트(context)로 로드하기 때문입니다. v1.0.0은 바로 그 실패 덕분에 존재합니다. 이제 모든 플로(flow)는 지식 베이스의 주장을 신뢰하기 전에 실제 상황과 대조하여 점검(spot-check)하며, 상태 명령(status command)은 드리프트(drift)를 감사(audit)하고, KB-sync 플로는 모든 주장(주장 → 관찰된 현실 → 제안된 수정)을 검토하여 리뷰 게이트(review gates)에서 기록을 복구합니다.

철학:

AI는 엔진입니다 — 모든 지침은 AI가 읽고 따르는 산문 형태의 마크다운 (markdown)입니다.
문서 우선 (Documentation-first) — 단 한 줄의 코드를 작성하기 전에 설계를 먼저 합니다.
신뢰에는 검증이 필요합니다 — 코드와 괴리될 수 있는 문서는 반드시 코드와 대조하여 확인해야 합니다.
마크다운 편집을 통한 커스터마이징 — 규칙, 단계, 또는 완전히 새로운 플로 (flow)를 추가할 수 있습니다.

지원 스택: Unity, Godot, React/Vue/Angular/Svelte, FastAPI/Django/Express/Go, Flutter/React Native, 그리고 범용적인 폴백 (fallback). 플랫폼: Claude Code, Cursor, GitHub Copilot, OpenCode, Kimi Code CLI — 얇은 래퍼 (thin wrappers) 형태이며, 워크플로 (workflow) 로직은 동일합니다.

여러분께 드리는 질문:
여러분은 AI의 지식 베이스 (knowledge base)가 노후화되는 것을 어떻게 방지하고 계신가요? 무엇이 잘 작동하고 무엇이 문제인지 듣고 싶습니다.
/u/Critical-Pea-8782 가 r/OpenAI 에 게시함
[link] [comments]