모호한 엔지니어링 문제를 해결하기 위해 AI 위원회(AI Councils)를 활용하는 방법
AI 어시스턴트 하나는 유용합니다. 하지만 복잡한 소프트웨어 아키텍처를 다루기에는 충분하지 않습니다.
AI를 자동 완성 이상의 용도로 사용하다 보면 한 가지 패턴을 발견하게 됩니다. 단일 모델이 해결책을 제안하고, 겉보기에는 좋아 보입니다. 그대로 구현합니다. 그러다 사흘 뒤, 거대한 아키텍처 결함을 발견하게 됩니다.
이것은 모델의 실패가 아니라 프로세스의 실패입니다. 단일 모델은 자신의 가정을 스스로 의심하는 경우가 거의 없습니다.
모호한 문제를 해결하려면 AI 위원회(AI Council)가 필요합니다. 이것은 새로운 플랫폼이 아닙니다. 여러 AI 컨텍스트가 서로 다른 역할을 맡아 제안서를 검토하는 워크플로우입니다.
목표는 AI 사용을 관리된 엔지니어링 워크플로우로 전환하는 것입니다.
워크플로우는 다음과 같습니다:
• 문제 정의(Problem Statement): 문제를 프레임화합니다. • 아키텍트 에이전트(Architect Agent): 소스 기반 에이전트가 트레이드오프를 고려한 제안서를 작성합니다. • AI 위원회 비평(AI Council Critique): 다양한 AI 역할이 제안서를 검토합니다. • 피드백 합성(Feedback Synthesis): 에이전트가 모든 피드백을 평가하고 충돌 지점을 식별합니다. • 이의 제기 대장(Objection Ledger): 모든 이의 제기 사항, 심각도 및 해결 과정을 추적합니다. • 인간 거버넌스(Human Governance): 계획이 준비되었는지, 아니면 추가 라운드가 필요한지 결정합니다. • 실행 에이전트(Executor Agent): 별도의 컨텍스트가 계획을 구현합니다. • 감사 에이전트(Auditor Agent): 세 번째 컨텍스트가 원래 사양에 따라 코드를 감사합니다.
핵심은 역할 분리에서 나옵니다. 단순히 "어떻게 생각해?"라고 묻지 마세요. 각 AI 세션에 구체적인 역할을 부여하십시오:
- 시스템 사고가(System Thinker): 시스템적 리스크와 경계를 평가합니다.
- 비판적 검토자(Critical Reviewer): 가정을 반박하고 논리적 허점을 찾아냅니다.
- 단순화 전문가(Simplifier): 불필요한 복잡성을 찾아냅니다.
- 대안 검토자(Alternatives Reviewer): 다른 접근 방식을 제안합니다.
가장 중요한 부분은 이의 제기 대장(Objection Ledger)입니다. 이것이 없으면 피드백은 모호한 의견에 불과해집니다. 대장은 모든 우려 사항을 반드시 해결하도록 강제합니다. 이의 제기 사항을 Open(미결), Accepted(수용), Rejected(거부), 또는 Resolved(해결)로 표시합니다. 이를 통해 감사 가능한 의사결정 기록이 생성됩니다.
당신은 복사-붙여넣기 병목 현상이 되지 않습니다. 소스 기반 에이전트가 합성을 수행합니다. 당신은 거버너(Governor)로서 역할을 수행합니다. 수동 작업을 하는 것이 아니라, 관문을 통제합니다.
당신은 다음을 결정합니다:
- 반복을 언제 멈출 것인가.
- 사양을 언제 승인할 것인가.
- 최종 리스크를 언제 수용할 것인가.
고위험 리팩토링이나 불분명한 아키텍처에 이 방식을 사용하십시오. 사소한 버그 수정에는 사용하지 마십시오. 잘못된 설계의 비용이 높을 때만 그 오버헤드를 감수할 가치가 있습니다.
작게 시작하십시오. 비평가 한 명과 단순화 전문가 한 명만 사용해 보세요. 즉시 그 가치를 느끼게 될 것입니다.
Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii