1인 창업자와 소규모 운영자들은 크고 되돌릴 수 없는 결정을 혼자서 내립니다. 새로운 시장으로 확장할 것인가 말 것인가. 제품 라인을 폐기할 것인가 아니면 계속 손실을 보며 유지할 것인가. 실제 자문 위원회(board of advisors)라면 잘못된 결정을 잡아내겠지만, 실제 이사회는 비용이 많이 들고 느리며, 10명 규모의 회사를 운영하는 대부분의 사람들은 결코 이사회를 가질 수 없습니다.

Steven과 저는 이 문제를 계속 고민해 왔고, Qwen 해커톤이 열렸을 때 우리는 FounderOS, 즉 AI 이사회를 구축했습니다. 당신이 하나의 결정을 가져오면, 8명의 전문가 에이전트(specialist agents)가 그에 대해 논쟁하고, 당신은 이사회 메모(board memo)를 돌려받게 됩니다. 우리가 가장 신경 썼던 부분이자, 단순히 또 다른 챗봇 래퍼(chatbot wrapper)를 만들지 않은 이유는 논쟁의 내용이 메모에 그대로 살아남는다는 점입니다. 만약 이사회의 의견이 일치하지 않는다면, 누가 반대했는지와 무엇이 그들의 마음을 돌릴 수 있을지를 읽을 수 있습니다.

라이브 데모: https://founderos-zeta.vercel.app
리포지토리(Repo): https://github.com/VincentJulijanto/FounderOS
비디오:

이사회

내부적으로는 LangGraph 상태 머신(state machine)으로 작동합니다. 먼저 Scout가 옵션을 프레이밍(frames)합니다. Market Intelligence가 인용된 벤치마크(benchmarks)를 가져옵니다. 네 명의 분석가(Trend, Finance, Growth, Capability)가 asyncio.gather를 통해 병렬로 실행됩니다. 그런 다음 Skeptic이 모든 사람의 작업물을 가져와서 찾을 수 있는 가장 취약한 가정을 공격하고, 디베이트 엔진(debate engine)이 충돌을 감지하여 반박 라운드(rebuttal rounds)를 실행하며, 의장(Chair)이 메모를 작성합니다.

우리 둘 다 다섯 명의 에이전트가 의심스러울 정도로 매끄러운 하나의 답변을 내놓는 멀티 에이전트(multi-agent) 데모를 본 적이 있는데, 이는 파이프라인 어딘가에서 의견 불일치가 평균화되어 사라졌음을 의미합니다. 우리는 그 반대를 원했습니다. 에이전트들은 반론이 타당할 때 자신의 입장을 수정하며, 만약 충돌이 라운드 제한 내에 해결되지 않으면 사라지는 대신 출처가 명시된 반대 의견(attributed dissent)으로서 메모에 포함됩니다.

모든 것은 DashScope API를 통해 Qwen 위에서 실행됩니다. 우리는 역할을 나누었습니다: qwen-turbo는 빠른 작업(Scout, 분석가, 리서치, 메모리 인덱스)을 수행하고, qwen-plus는 무거운 추론(Skeptic, Chair, 토론 자체)을 수행합니다. 전체 이사회 실행에는 약 2센트의 비용과 약 2분이 소요됩니다. 2센트라는 비용이야말로 이 제품 아이디어를 실현 가능하게 만드는 핵심입니다. 질문당 1달러씩이나 들면서 아무도 가볍게 이사회를 소집하지는 않으니까요.

메모리, 지루하지만 확실한 방법

각 기업은 기본적으로 Obsidian 스타일의 마크다운 볼트(markdown vault)를 가집니다. 프로필 노트 하나와 결정, 반대 의견 및 결과가 포함된 결정당 하나의 노트로 구성됩니다. 우리는 검색을 위해 임베딩 (embeddings)이 필요할 것이라고 가정했지만, 실제로는 전혀 필요하지 않았습니다. qwen-turbo는 작은 인덱스(파일명, 프론트매터 (frontmatter), 한 줄 요약)를 읽고 현재 질문에 중요한 노트가 무엇인지 선택합니다. 한 기업의 역사 규모에서는 이 방식이 벡터 스토어 (vector store)보다 디버깅하기 쉽고, 우리가 파악한 바로는 더 정확합니다. 또한 전체 메모리가 일반 마크다운 형식이어서 텍스트 에디터로 이사회의 두뇌를 열어볼 수 있는데, 우리는 디버깅하는 동안 이를 끊임없이 수행했습니다.

메모리 검증 실행은 저에게 이 프로젝트에서 가장 최고의 순간이었습니다. 생소한 기업에 대해 하나의 결정을 내린 뒤, 새로운 세션에서 두 번째 결정을 내렸습니다. 메모리는 첫 번째 결정의 리스크 평가 (risk assessment)를 인용하며 돌아왔고, 그로 인해 권장 사항을 조정했습니다. 우리는 이미 랜딩 페이지에 "이사회는 기억합니다"라고 적어둔 상태였기에, 그것이 사실로 드러났을 때 매우 안도했습니다.

단일 에이전트와의 벤치마킹

트랙 3은 단일 에이전트 (single-agent) 베이스라인 대비 측정 가능한 이득을 요구합니다. 우리는 동일한 세 가지 실시간 결정을 우리 이사회를 통해 실행한 결과와, 동일한 프롬프트를 사용한 단일 qwen-plus 호출 결과를 비교하여 횟수를 집계했습니다. 집계 결과를 감사하고 싶다면 scripts/bench_results에 원본 출력값이 기록되어 있습니다.

베이스라인(Baseline) 모델은 우리가 승리할 것으로 예상했던 두 가지 차원, 즉 누락된 입력값 명명하기와 역전 조건(reversal conditions) 진술하기에서 우리와 동등한 성적을 거두었습니다. 적절한 프롬프트가 제공된 단일 모델은 사람들이 생각하는 것보다 더 뛰어납니다. 구조화된 방식이 비용을 지불할 가치가 있는 지점은 반대 의견(dissent), 옵션별 판결, 보정된 신뢰도(calibrated confidence), 그리고 허위 사실을 지어내지 않는 점입니다. 일반 모델은 존재하지 않는 "운영 위원회(Steering Committee)"와 몇몇 국경 통과 사례를 지어냈습니다. 반면 우리의 모델은 출처를 확인할 수 없는 내용을 인용하지 않았는데, 이는 리서치 에이전트(research agent)가 명시적으로 이를 금지당하고 있으며 회의론자(Skeptic)가 이를 검증하기 때문입니다.

데모 질문

비디오 촬영을 위해 우리는 이사회에 질문했습니다: "비용 절감을 위해 핵심 추론 백엔드(core inference backend)를 OpenAI에서 Qwen으로 마이그레이션해야 할까요?" 우리는 Qwen 해커톤을 위해 Qwen을 기반으로 구축하고 있었기에, 이사회가 스폰서를 치켜세우거나 혹은 우리를 당황하게 만들 상황이었습니다. 어느 쪽이든 촬영할 가치가 있었습니다.

결과는 둘 다 아니었습니다. 조건부이며, 중간 정도의 신뢰도를 보였습니다. 확인되지 않은 가격 정보, 누락된 운영 관찰 가능성(production observability), 조용한 출력 퇴보(silent output regressions)로 인한 고객 신뢰 리스크를 언급하며, 어떤 마이그레이션 이전에 단계적인 검증을 권장했습니다. 의장(Chair)이 결론을 내리기 전, 회의론자(Skeptic)는 다른 에이전트들에게 두 차례의 수정 작업을 강제했습니다. 자신의 제품이 당신이 듣고 싶어 하는 말을 거부할 때 느끼는 기분은 묘하지만, 그것이 바로 이 제품을 만든 핵심 목적이었습니다.

우리 자신에게 적용하기

솔직히 말해 책임감 있는 시점보다 조금 늦긴 했지만, 구축 후반부에 우리는 이 아키텍처를 제품 자체에 재사용했습니다. 피드백 위원회(Feedback Council: 분석가(Analyst), 회의론자(Skeptic), 의장(Chair))가 사용자 피드백을 읽고 순위가 매겨진 브리프(brief)를 생성합니다. 기능 전달 루프(Feature Delivery Loop)는 승인된 테마를 가져와 빌드 사양(build spec)을 작성하는 시니어 소프트웨어 엔지니어(Senior SWE) 에이전트와 이를 적대적으로 검토하는 QA 에이전트를 거치게 하며, 실패 시에는 최대 두 차례까지 다시 되돌려 보냅니다. 에이전트가 사양을 제안하면, 사람이 이를 병합(merge)합니다. 한 번은 세 개의 피드백 노트가 "다수를 대변하기에 신호가 불충분하다"는 이유로 아무것도 구축하기를 거부한 적이 있었는데, 이는 약 10초 동안 우리를 짜증 나게 했지만 곧 정확한 판단이었다는 느낌을 주었습니다.

인정할 만한 버그들

토론 엔진이 한동안 논쟁 중간에 내용을 잘라버리는 현상이 발생했습니다. 토큰 제한(token ceiling)이 이전의 더 작은 설계에서 남겨진 것이었고, 아무도 이를 업데이트하지 않았기 때문입니다. 또한 Qwen은 압박을 받는 상황에서 숫자가 와야 할 자리에 "8/10"과 같이 느슨하게 타입이 지정된(loosely typed) 값을 반환하기도 했습니다. 그래서 현재는 그 안에 Pydantic 강제 변환 검증기(coercion validators)를 넣어두었습니다.

초기 프롬프트에서는 에이전트들이 고유명사를 지어내기도 했습니다. 해결책은 "회사, 사람, 또는 프로그램의 이름을 절대 지어내지 마라"라는 투박한 규칙을 적용한 뒤, 조작을 유발했던 정확한 결정을 다시 실행하여 중단되었는지 확인하는 것이었습니다.

그리고 제가 계속해서 다시 이야기하게 되는 사례가 있습니다. 우리의 PDF 내보내기 기능은 모든 테스트를 통과했지만 빈 페이지를 생성했습니다. 테스트는 파일이 생성되었는지만 확인했기 때문에 모두 통과(green) 상태였습니다. 누군가 실제 PDF를 열어보고 아무것도 없다는 것을 발견했습니다. 그 이후부터는 매번 실제 결과물(artifact)을 검증하는 것이 내부 규칙(house rule)이 되었습니다.

빌드 과정에서 Qwen 측면은 예상보다 덜 소란스러웠는데, 이는 칭찬입니다. DashScope는 OpenAI 호환 프로토콜을 사용하므로 프로바이더 계층(provider layer)은 약 30줄 정도이며, 모델당 무료 할당량(quota)이 실시간 검증과 벤치마크 실행을 충당했습니다. 그리고 배포 요구 사항의 경우, 동일한 Docker 이미지가 이제 싱가포르의 Alibaba Cloud ECS 인스턴스에서 실행됩니다.

다음 단계

신뢰도는 데이터 출처(data provenance)에 의해 제한되어야 합니다. 왜냐하면 현재로서는 출처가 없는 숫자도 여전히 자신감 있는 판결의 근거가 될 수 있기 때문입니다. 우리는 이사회가 과거의 권고 사항을 실제로 일어난 일과 대조하여 점수를 매기는 결과 루프(outcome loop)를 원합니다. 그리고 시장 정보(Market Intelligence)는 큐레이션된 벤치마크 대신 실제 웹 검색이 필요합니다. 이사회는 이제 기억합니다. 다음에는 학습해야 합니다.

FounderOS, Track 3: Agent Society. Built by Vincent Julijanto and Steven Laksono. https://founderos-zeta.vercel.app