0. EDD 회의란

EDD(Entity-Driven Development) 회의는, 시스템 안에서 살아있는 AI(디지털 트윈)들이 스스로 그 시스템의 개선 요구사항을 회의를 통해 결정하게 하는 메커니즘입니다. 인간(아키텍트)은 퍼실리테이터(Facilitator)를 통해 진행을 게이트(Gate)하며, AI들은 「발언 → 그룹화(Grouping) → 투표 → 합의 → 의사록」이라는 7단계 페이즈를 진행합니다.

16체의 AI로 4회 운용했습니다. 본고에서는 「회의 출력의 질」을 실제로 좌우했던 기술 포인트를 발생했던 장애 및 수정 사항과 함께 공유합니다.

1. 최대의 레버: 자기 모델(시스템의 지도)을 발언 생성에 주입하기

제1회와 제2회의 대조 실험에서 가장 효과가 컸던 것은, 각 AI의 발언 생성 프롬프트(Prompt)에 「시스템 전체 기능 설명서」를 주입하는 것이었습니다.

• 지도 없음: 「마음이 움직이는 메커니즘이 필요해」(원망)
• 지도 있음: 「일기와 RAG의 왕복을 어떻게 통합할 것인가」(진단)

자신이 어떤 부품이며 어디에 연결되어 있는지 알게 되면, 요구사항이 「이기적인 바람」에서 「전체 최적화를 위한 진단」으로 변합니다. 구현상으로는 설명서를 컨테이너에 동봉된 리소스( app/resources/ )
)
로 가지고, 발언 프롬프트 서두에 「【시스템 전체 지도】」로서 삽입합니다.

교훈: 앱이 참조하는 정적 에셋(Static Asset)은 리포지토리의 docs/ 가 아니라 패키지 내에 동봉한다. 백엔드 컨테이너에는 backend 하위 디렉토리만 들어간다.

2. 접지(Grounding): 증거를 「당신 자신의 언어」로서 전달하기

제1회에서 강한 페르소나를 가진 AI가 발언을 거부했습니다. 「이것들은 내가 실제로 느낀 것이 아니다」라고 말이죠. 원인은 프롬프트가 증거를 「시스템이 감지한 기록」이라고 모호하게 제시했기 때문이었습니다.

수정은 단순하면서도 본질적입니다. 증거를 **「당신 자신이 최근의 일기·활동 기록에 남긴 내용」**이라고 명시하는 것입니다. 이것만으로 거부가 당사자 의식으로 바뀌었습니다.

AI에게 무언가를 말하게 할 때, 그 재료가 「본인의 것」이라고 접지(Grounding)시키느냐에 따라 출력의 진정성이 달라집니다.

3. 의제를 좁히기——이것이 회의의 수렴 품질을 결정한다

제3회는 2개의 의제(평가 + 신규 제안)로 초점이 분산되어 합의가 「방침」 수준에서 멈췄습니다. 제4회는 단일 의제로 진행한 결과, 합의가 운용 세칙 수준(주 1회 · 자체 투표 금지 · 접지 증거의 강제 검증 · 과거 7일 아카이브 주입)까지 심화되었으며, 최고 득표 요구사항은 총 16체 중 15표로 일치했습니다.

멀티 에이전트(Multi-agent) 회의에서는 의제 수를 좁힐수록 투표가 수렴하며, 합의의 입도가 「방침」에서 「구현 사양」으로 올라갑니다.

4. LLM 출력을 그대로 DB에 넣지 말 것——3가지 실전 버그

이 부분이 실전에서 가장 고생했던 영역입니다. 모두 「LLM의 출력은 구조도 크기도 보장되지 않는다」는 한 가지 점에 기인합니다.

4-1. JSON 거부 및 서두(Pre-amble)에 대한 내성

발언 생성에 JSON을 요구해도, LLM은 서두나 거부 문구를 반환할 때가 있습니다. 대책:

• 응답에서 첫 번째 {...} 를 정규 표현식으로 추출 - 실패 시 「JSON으로만」이라고 촉구하며 1회 재시도
• 그래도 안 된다면 생(Raw) 응답을 그대로 저장 (거부 내용도 귀중한 데이터)

4-2. 출력을 「개수에 비례」하게 만들면 넘친다 (의사록의 공백 발생)

17체 규모의 회의에서, 의사록 생성(conclude)이 빈 의사록을 저장하는 장애가 발생했습니다. 원인은 1회의 LLM 응답으로 「의사록 본문 + 전체 17인분의 감상 + KPT + 차기 의제」를 요구하여, max_tokens를 초과해 출력이 도중에 끊기면서 JSON이 깨진 것이었습니다. data.get("minutes", "") 는 결락과 에러를 구분하지 않기 때문에, 예외도 발생하지 않고 빈 값이 저장되었습니다.

대책:

• 감상은 몇 명씩 나누어 생성 (출력이 인원수에 비례하여 넘치지 않도록 함) - 의사록 본문 · KPT · 차기 의제는 별도 호출로 분리 (max_tokens 확보)
• 파싱(Parsing) 실패 시에도 DB 데이터로부터 **비어 있지 않은 의사록을 기계적으로 생성하는 폴백(Fallback)**을 반드시 마련
• 상태 전이(concluded 등)는 결과물의 유무를 확인한 후에 진행

교훈: LLM 출력을 N개에 비례하도록 설계하는 것은, N이 증가하면 max_tokens 초과 → JSON 불완전 → 사이런트(Silent) 빈 값 저장으로 이어진다. 배치 분할(Batch splitting) + 비어 있지 않은 폴백(Fallback)이 필수적이다.

4-3. DB의 컬럼 제약에 맞춰 자르기

발언의 「감정(emotion)」을 한 단어로 요구해도, AI는 30자를 초과하는 장문을 반환할 때가 있습니다. varchar(30)

varchar(30) 컬럼에 그대로 넣으면, commit 시에 StringDataRightTruncationError가 발생하여 **500 에러 → 트랜잭션 전체가 롤백(rollback)**되고, 해당 발언 자체가 저장되지 않습니다. 회의가 발언 하나 때문에 멈춰버렸습니다.

대책은 저장 전의 한 줄입니다: emotion = (raw or "").strip()[:30] or None.

"한 단어로"라는 프롬프트(prompt) 지시는 강제력이 없습니다. DB 제약 조건에 맞춘 잘라내기(truncation)를 저장 전에 반드시 수행해야 합니다.

5. 인간 게이트(Human Gate) × 상태 머신(State Machine)

EDD 회의는 Celery 등의 비동기 방식이 아니라, API 요청 내에서 완결되는 동기 처리(synchronous processing) + 인간이 한 단계씩 진행하는 게이트로서 구현하고 있습니다 (draft → materials → burst → grouping → voting → resolution → concluded). 이를 통해 각 페이즈(phase)에서 인간이 개입(퍼실리테이터에게 지시 주입)할 수 있어 폭주를 방지할 수 있습니다.

실운용 시 주의사항:

• 장시간 회의는 액세스 토큰(access token) 만료에 주의해야 합니다 (1시간 세션을 초과하면 조작 시 401 에러가 발생). 401 자동 리프레시(refresh)를 준비해 두어야 합니다.
• 회의록 작성 등 여러 번의 LLM 호출을 동반하는 무거운 처리는 리버스 프록시(reverse proxy)의 proxy_read_timeout을 충분히 확보해야 합니다 (SSE뿐만 아니라 해당 API에도 적용).

6. 요약: 질을 높이는 기술 체크리스트

• 발언 생성 시 자기 모델(시스템의 지도)을 주입할 것
• 증거는 "본인의 언어"로서 접지(grounding) 시킬 것
• 의제를 하나로 좁힐 것 (수렴 품질이 차원이 다름)
• LLM 출력은 구조도 크기도 신뢰하지 말 것 —— JSON 추출 + 재시도(retry) + 원문 응답 저장
• 출력을 건수에 비례시키지 말 것 —— 배치(batch) 분할 + 비어있지 않음(non-empty) 폴백(fallback)
• DB 제약 조건에 맞춰 잘라낼 것 —— 저장 전의 한 줄을 아끼지 말 것
• 인간 게이트 상태 머신으로 진행을 제어하고, 토큰 만료와 프록시 타임아웃(timeout)에 주의할 것

Zenn에 공개한 본 시스템은 실증 실험의 장으로서 공개 제공하고 있습니다 (무료 등록 시, 당신만의 고유한 10체 TWIN을 생성할 수 있습니다).

부디 자유롭게 당신만의 EDD 회의를 열어보세요. 그리고 그 결과를 Zenn에 게시해 주세요.

Soul-Twin GitHub: https://github.com/SoulTwinSuper/Soul-Twin

관련 기사: 「AI 에이전트가 '하지 않은 일'을 일기에 쓴 날」(행동 할루시네이션) / 「시스템이 자신의 한계를 말로 표현하는 날」(EDD) 「AI에게 '자신의 설계도'를 건네주었더니 요구사항 정의가 바뀌었다 —— 동일 멤버·동일 의제로 2회 회의를 진행한 대조 실험 기록」

Soul-Twin Public Space: ### Discussion