모호한 엔지니어링 문제를 해결하기 위해 AI Council을 활용하는 방법
AI 어시스턴트 하나는 유용합니다. 하지만 그것만으로는 항상 충분하지는 않습니다.
코딩에 AI를 사용해 보셨다면 그 패턴을 아실 겁니다. 문제를 설명합니다. 모델이 해결책을 제안합니다. 괜찮아 보입니다. 구현합니다. 그러다 사흘 뒤에 거대한 결함을 발견합니다. 아키텍처가 경계 조건(boundary condition)을 충족하지 못했거나, 분리되어야 할 두 요소를 결합해 버린 것입니다.
이것은 모델의 실패가 아니라 프로세스의 실패입니다. 단일 모델은 자신의 가정을 스스로 반박할 능력이 부족합니다.
복잡한 엔지니어링 작업을 위해서는 AI Council이 필요합니다. 이것은 새로운 플랫폼이 아닙니다. 여러 AI 역할이 서로 다른 관점에서 하나의 제안을 검토하는 구조화된 워크플로우입니다.
목표는 AI 사용을 통제 가능한(governed) 엔지니어링 워크플로우로 전환하는 것입니다.
워크플로우는 다음과 같이 작동합니다:
• 문제 정의(Problem Statement): 문제를 프레임화합니다. • 아키텍트 에이전트(Architect Agent): 소스에 기반한(source-grounded) 에이전트가 초기 제안을 생성합니다. • AI Council: 다양한 AI 역할이 제안을 검토합니다. • 피드백 합성(Feedback Synthesis): 에이전트가 모든 피드백을 병합하고 충돌 지점을 식별합니다. • 이의 제기 대장(Objection Ledger): 모든 이의 제기 사항과 심각도, 해결 방법을 추적합니다. • 인간의 거버넌스(Human Governance): 중단할지 진행할지를 결정합니다. • 실행 에이전트(Executor Agent): 별도의 에이전트가 계획을 구현합니다. • 감사 에이전트(Auditor Agent): 최종 에이전트가 원래의 사양(spec)과 코드를 대조하여 확인합니다.
Council의 역할에는 다음이 포함되어야 합니다:
- 시스템 사고가(System Thinker): 리스크와 시스템 경계를 평가합니다.
- 비판적 검토자(Critical Reviewer): 가정을 반박하고 간극을 찾아냅니다.
- 단순화 전문가(Simplifier): 불필요한 복잡성을 찾아냅니다.
- 대안 검토자(Alternatives Reviewer): 다른 접근 방식을 제안합니다.
핵심은 더 많은 모델을 사용하는 것이 아닙니다. 핵심은 역할의 분리(role separation)에 있습니다. AI에게 "이것을 검토해 줘"라고 요청하면 모호한 답변을 얻게 됩니다. 하지만 AI에게 "가장 큰 세 가지 아키텍처 리스크를 찾아줘"라고 요청하면 실행 가능한 데이터를 얻을 수 있습니다.
컨텍스트 또한 분리해야 합니다. 코드를 작성하는 에이전트와 코드를 감사하는 에이전트는 동일해서는 안 됩니다. 그래야 AI가 동일한 사각지대를 공유하는 것을 방지할 수 있습니다.
인간은 단순 노동을 하지 않습니다. 인간은 게이트(gate)를 소유합니다. 피드백이 충분한지, 어떤 리스크를 수용할지를 결정하는 것은 당신입니다. 당신은 단순 작업자가 아니라 엔지니어링 매니저입니다.
이 방식은 리스크가 큰 리팩토링이나 모호한 아키텍처 설계에 사용하십시오. 사소한 버그 수정에는 사용하지 마십시오. 실수로 인한 비용이 클 때만 이 오버헤드를 감수할 가치가 있습니다.
Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii
Optional learning community: https://t.me/GyaanSetuAi