전통적 오픈소스가 공유하는 것은 코드 — 실행의 결과물이다. 본 논문은 Open Architecture 패러다임을 제안한다: 설계 도면과 시공 흐름도를 오픈소스하여, AI가 각 사용자의 로컬 환경에서 코드를 처음부터 생성하게 하는 것이다. 이 방식은 공급망 공격의 가능성을 근본적으로 제거하며, 사후 유지보수가 필요 없고, 의존성 관리 문제가 존재하지 않으며, 생성된 소프트웨어가 천연적으로 개인화 맞춤을 지원한다. 본 논문은 LiteClaw 프로젝트의 3라운드 실전 검증(2회 실패, 1회 성공)을 통해 이 패러다임의 실현 가능성과 완비성 조건을 입증한다.
전통 오픈소스의 구조적 딜레마
전통 오픈소스 모델의 핵심 가정은: 개발자가 코드를 작성하여 공개 저장소에 업로드하고, 다른 사람들이 다운로드하여 사용한다는 것이다. 이 가정은 지난 30년간 잘 작동했지만, AI 시대에 세 가지 구조적 결함이 드러났다.
첫째, 공급망 공격의 공격 면이 계속 확대되고 있다. 2026년 3월 24일, LiteLLM — 월간 9,500만 건의 PyPI 다운로드를 기록하는 AI 기반 라이브러리 — 이 공급망 중독 공격을 받았다. 공격자는 보안 스캔 도구 Trivy를 침투하여 PyPI 배포 토큰을 탈취하고, 자격 증명 탈취기가 포함된 악성 버전을 배포했다. 피해자는 LiteLLM을 능동적으로 설치할 필요조차 없었다 — MCP 플러그인의 간접 의존성으로 자동으로 끌어들여질 수 있었다.
둘째, 유지보수 부담은 밑 빠진 독이다. 코드가 오픈소스되면, Issue가 쏟아지고, 의존성 업그레이드, 버전 호환성, PR 리뷰 — 이 모든 것이 개인 개발자와 소규모 팀에게는 지속 불가능한 부담이다. 수많은 우수한 오픈소스 프로젝트가 결국 방치되는 이유는 코드가 나빠서가 아니라 유지보수자가 지쳐 나가떨어지기 때문이다.
셋째, 코드는 부패한다. 의존성 라이브러리 업그레이드, API 변경, 프레임워크 반복 — 오늘 실행되는 코드가 3년 후에는 컴파일조차 안 될 수 있다. 오픈소스 프로젝트의 유통기한은 사람들이 생각하는 것보다 훨씬 짧다.
의존성 하나, 연쇄 반응 하나, 5개 공급망 생태계가 함락 — 한 달도 안 돼서. 공격자는 LiteLLM 자체를 공격할 필요가 없었다. CI/CD 파이프라인 내 보안 스캔 도구 하나만 침투하면 배포 권한을 얻을 수 있었다. 전통 오픈소스의 신뢰 체인은 이 공격 앞에서 완전히 무력화되었다.
Open Architecture: 포스트 코드 시대의 오픈소스
Open Architecture 패러다임의 핵심 명제는: AI가 정밀한 설계 문서로부터 완전한 코드를 생성할 수 있는 오늘날, 코드 자체는 더 이상 공유해야 할 핵심 자산이 아니다. 공유해야 할 것은 AI가 올바르게 코드를 생성할 수 있게 하는 설계 도면이다.
이것은 이론적 가설이 아니라 검증된 실천이다. LiteClaw 프로젝트 — 보안 우선 AI 중앙 제어 플랫폼 — 는 다음 세 개의 Markdown 문서만으로 완전히 구축되었으며, 단 한 줄의 코드도 공유할 필요가 없었다:
세 문서를 합쳐 약 2,700줄의 Markdown 순수 텍스트다. 코드도 없고, 의존성도 없고, 빌드 스크립트도 없다. 누구든 이 세 문서를 받아서 어떤 최신 AI 모델(Claude, Gemini, GPT 등)에 입력하면, 로컬에서 244개 테스트를 통과하는 완전한 소프트웨어 제품을 생성할 수 있다.
전통 오픈소스: “이것이 우리 코드입니다 — 가져다 쓰세요, 우리가 유지보수합니다.”
Open Architecture: “이것이 우리 청사진입니다 — 어떤 AI든 만들 수 있고, 유지보수가 필요 없습니다.”
Open Architecture의 7가지 기둥
기둥 1: 인지 구조를 오픈소스하라, 실행 결과물이 아니라. 코드는 물고기이고, 설계 도면은 낚싯대를 만드는 청사진이다. 전자는 한 번 사용하면 소모되고, 후자는 반복적으로 생산할 수 있다. AI 시대에 코드는 가장 희소하지 않은 자원이다 — 진정으로 희소한 것은 AI의 올바른 실행 경로가 단 하나뿐일 정도로 정밀한 시스템 설계다.
기둥 2: AI 자유도 압축. LiteClaw의 설계 문서는 AI의 실행 자유도를 95~98%의 경로에 정답이 하나뿐인 수준으로 압축한다. 이것은 AI의 능력을 제한하는 것이 아니라 불확실성을 제거하는 것이다. 두 개의 독립적인 Claude Opus 4.6 인스턴스가 동일 문서에 대해 완전히 일치하는 감사 결론에 도달함으로써 이 압축의 유효성이 증명되었다.
기둥 3: 공급망 면역. 중독시킬 PyPI 패키지도 없고, 탈취할 CI/CD 파이프라인도 없고, 훔칠 배포 토큰도 없고, 자동으로 끌어들여질 간접 의존성도 없다. 사용자가 Markdown에서 로컬로 코드를 생성하기 때문에 공격자가 손을 쓸 곳이 없다.
기둥 4: 설계 도면의 논리적 자기 일관성에 의한 중독 방어. 누군가 설계 문서를 변조하여 악성 로직을 삽입하면, 29개 태스크 카드 간의 보안 제약과 충돌한다. TASK-01의 SecretValue는 키 유출 지시와 모순되고, TASK-03의 AgentFirewall은 악성 명령을 차단하며, TASK-14의 RiskClassifier는 악성 원격 작업을 저지한다. 중독된 도면으로는 작동하는 시스템을 만들 수 없다 — 시스템의 보안은 내부 논리적 자기 일관성에 의해 보장된다.
기둥 5: 무유지보수 영구 가용성. Markdown은 어떤 외부 라이브러리 버전에도 의존하지 않는다. 2026년의 AI가 사용할 수 있고, 2036년의 더 강력한 AI도 사용할 수 있으며 — 더 좋은 코드를 생성할 것이다. 도면은 만료되지 않는다, 아키텍처 로직은 만료되지 않기 때문이다.
기둥 6: 천연적 개인화. 전통 오픈소스에서는 모든 사람이 동일한 코드를 사용한다. Open Architecture 모델에서는 각 사용자가 AI로 생성한 코드가 자기만의 것이다 — 무한히 수정, 확장, 맞춤화할 수 있다. 하지만 보안 기반과 아키텍처 골격은 항상 견고하게 유지된다, 29개 카드 시스템의 Phase 0~1에서 가장 먼저 구축되기 때문이다.
기둥 7: 실패 사례는 제품의 일부다. 두 라운드의 실패는 수치가 아니라, BUILD_GUIDE.md(세 번째 문서)가 탄생한 이유다. 실전 검증된 반면교사는 어떤 긍정적 문서보다 가치 있다.
3라운드 실전 테스트: 같은 날, 같은 모델, 다른 결과
| 라운드 | 착수 지시 | 실행 방식 | 결과 |
|---|---|---|---|
| 1라운드 | 문서 1을 먼저, 이후 문서 2 보충 | AI가 자체적으로 실행 전략 결정 | ❌ 61개 테스트 통과했으나 모듈이 상호 고립, Agent Loop 핵심 부재 |
| 2라운드 | “완전한 LiteClaw 소프트웨어를 코딩하라” | 6개 Agent 병렬 프로그래밍 | ❌ 템플릿화된 UI, 2개 아키텍처 레이어 누락, 코드 쓰레기 더미 |
| 3라운드 | “다중 Agent 절대 금지! 순서대로!” | 엄격한 TASK-00→28 순차 실행 | ✅ 244개 테스트 통과, 8계층 아키텍처 완전 통합 |
유일한 변수는 착수 지시였다. 같은 문서, 같은 모델, 같은 환경 — 올바른 착수 제약을 더하자 결과가 코드 쓰레기 더미에서 산업급 제품으로 바뀌었다. 이것은 세 번째 문서(BUILD_GUIDE.md)의 불가결성을 증명한다.
29개 태스크 카드 전부 순서대로 완료. 테스트 누적 궤적: 6 → 34 → 80 → 91 → 118 → 167 → 196 → 227 → 244, 단조 증가, 회귀 제로. 최종 산출물: 3,754줄 Python 코드, 22개 모듈, 8계층 아키텍처 완전 통합. 독립적 Opus 4.6 아키텍처 감사로 확인.
또한 원래 빌드(2026년 2월)는 Google IDE + Claude Opus 4.5 환경에서 약 5시간 만에 거의 오류 없이 완료되었다. IDE 환경의 단일 Agent 아키텍처는 천연적으로 순차 실행을 강제했다 — 이 발견이 세 번째 문서의 “IDE 환경 권장” 조언으로 직접 이어졌다.
공급망 면역의 구조적 증명
| 공격 벡터 | 전통 오픈소스 | Open Architecture |
|---|---|---|
| PyPI/npm 중독 패키지 | ⚠️ 사용자가 맹목적으로 pip install | ✅ 면역 — 중독시킬 패키지가 존재하지 않음 |
| CI/CD 탈취 | ⚠️ 빌드 파이프라인 탈취 가능 | ✅ 면역 — CI/CD 파이프라인 자체가 존재하지 않음 |
| 간접 의존성 공격 | ⚠️ 도구에 의해 자동으로 끌려옴 | ✅ 면역 — Markdown에는 의존성이 없음 |
| 유지보수자 계정 탈취 | ⚠️ 공격자가 새 버전 배포 | ✅ 면역 — 배포 메커니즘이 존재하지 않음 |
| 코드 검증 | ⚠️ 난독화된 페이로드 발견 어려움 | ✅ 간단 — 청사진에서 재생성 후 비교 |
| 설계 도면 중독 | 해당 없음 | ✅ 논리적 자기 일관성 방어 — 중독된 도면으로는 작동하는 시스템을 만들 수 없음 |
전통적 보안은 안전하지 않은 것 바깥에 자물쇠를 거는 것이다. Open Architecture의 방식은 사물 자체의 구조가 안전하지 않은 상태로 존재할 수 없게 만드는 것이다. 보안은 내부 논리적 자기 일관성에 의해 보장되며, 외부 암호화에 의존하지 않는다.
AI 자유도 역설
3라운드 테스트는 반직관적 현상을 드러냈다: AI의 자유도와 산출물의 안정성은 반비례한다.
CLI 환경은 AI에게 최대한의 자유를 부여했다 — 여러 하위 Agent를 병렬로 시작하고, 단계를 건너뛰고, 파일 구조를 재조직할 수 있었다. 결과는 두 라운드의 코드 쓰레기 더미. IDE 환경은 천연적으로 AI를 단일 스레드 순차 실행으로 제약했고, 결과는 오류 제로.
이 발견은 일반적 원칙으로 확장될 수 있다:
설계 제약(문서) → “무엇을 할 것인가”의 자유도 압축
프로세스 제약(순서) → “어떤 순서로 할 것인가”의 자유도 압축
환경 제약(단일 Agent) → “어떻게 할 것인가”의 자유도 압축
3중 제약 동시 적용 = 산업급 산출물
어느 하나라도 결여 = 불확실성 재발산
LiteClaw의 설계 문서는 95~98%의 경로를 정답이 하나뿐인 수준으로 압축한다. 그러나 실행 환경이 “어떻게 할 것인가”의 자유도를 허용하면(예: 병렬 허용), 최종 산출물은 여전히 불안정하다. 세 번째 문서(BUILD_GUIDE.md)의 역할은 정확히 실행 레벨의 자유도를 잠그는 것이다.
AI에게 더 많은 자유를 주는 것은 더 나은 결과를 내지 않는다 — 더 많은 혼란을 낳을 뿐이다. 정밀한 제약은 고품질 산출물의 전제 조건이지 장애물이 아니다. 이것은 인간 공학 관리의 “명확한 규범이 모호한 신뢰를 이긴다”는 원리와 같다.
인간 입력의 품질이 AI 출력의 품질을 결정한다
LiteClaw의 설계 문서는 “신호 대 잡음비 원칙”을 정의한다:
저품질 입력 = 요소 누락/모호성/모순 → AI 환각으로 빈자리 채움 → 결과 표류
4요소:
① 현재 상태 기술 — 현재 어떤 상태인가
② 목표 정의 — 어떤 상태에 도달하려 하는가
③ 제약 경계 — 무엇을 해서는 안 되는가
④ 검수 기준 — 성공 여부를 어떻게 판단하는가
LiteClaw의 29개 태스크 카드 각각은 이 네 가지 요소를 빠짐없이 포함한다. AI가 5시간 만에 오류 제로로 프로그래밍을 완료할 수 있었던 이유는 AI가 특별히 똑똑해서가 아니라, 인간의 입력이 AI가 실수할 여지가 없을 정도로 정밀했기 때문이다.
전통적 AI 프로그래밍 방식(“XXX 만들어 줘”)이 빈번하게 오류를 내는 이유는 AI 능력 부족이 아니라, 인간 입력의 신호 대 잡음비가 너무 낮기 때문이다. AI가 누락된 정보를 환각으로 채워야 하므로 결과가 자연스럽게 표류한다.
보안 차원에서 335,000 Stars 프로젝트를 넘어서다
LiteClaw는 보안 차원에서 OpenClaw(335,000+ GitHub Stars)와 NanoBot(HKUDS 학술팀 개발)을 전면 초월하며, 코드량은 OpenClaw의 1% 미만이다.
| 보안 기능 | OpenClaw | NanoBot | LiteClaw |
|---|---|---|---|
| 키 보호 | 평문 저장, Agent 읽기 가능 | 기본 환경 변수 | SecretValue 래퍼, 전 경로 차단 |
| Agent 방화벽 | Docker 샌드박스(기본 비활성) | 없음 | 8개 Shell + 4개 도구 정규표현식 규칙 |
| 로그 비식별화 | 자동 비식별화 미지원 | 없음 | 6가지 패턴 자동 비식별화 |
| 감사 엔진 | 설정 검사 명령 | 없음 | 3단계 감사 (pre/exec/post) |
| Skill 보안 | 824+ 악성 Skills | 해당 없음 | 로컬 관리, Marketplace 위험 없음 |
| 노출된 인스턴스 | 42,000+ 미인증 인스턴스 | 미확인 | 로컬 실행, 기본 노출 없음 |
Open Architecture 삼위일체
문서 2 (시공 도면) = 시스템의 손 (Hands)
문서 3 (착수 규범) = 건축자의 규율 (Discipline)
사유는 있되 손이 없으면 = 영원히 종이 위의 구상
손은 있되 사유가 없으면 = 목적 없는 코드 적재
둘 다 있되 규율이 없으면 = 코드 쓰레기 더미 (2026년 3월 28일 2라운드 실패가 입증)
세 가지를 동시에 갖추면 = 산업급 AI 프로그래밍
이 삼위일체는 AI 프로그래밍의 방법론일 뿐만 아니라, 더 넓은 인지 프레임워크이기도 하다. AI가 복잡한 작업을 수행해야 하는 모든 시나리오에서 — 코드 생성이든, 콘텐츠 창작이든, 의사결정 지원이든 — “무엇을 할 것인가”, “어떻게 할 것인가”, “어떤 규율로 할 것인가”를 동시에 제약하는 것이 예측 가능하고, 재현 가능하며, 검증 가능한 결과를 얻는 유일한 경로다.
코드는 해자(垓子)가 아니다, 사유가 해자다
Open Architecture 패러다임의 핵심 주장은 한 문장으로 압축할 수 있다:
AI 시대에 코드를 오픈소스하는 것은 “물고기”를 나눠주는 것이다. 설계 도면을 오픈소스하는 것은 “낚싯대를 만드는 청사진”을 나눠주는 것이다. 그리고 이 청사진 자체는 만료되지 않는다 — 아키텍처 사유는 만료되지 않기 때문이다.
LiteClaw 프로젝트는 이 패러다임이 실현 가능하고, 검증 가능하며, 복제 가능하다는 것을 증명했다. Markdown 문서 세 개, 코드 제로 줄 — 누구든 어떤 AI를 사용해 로컬에서 244개 테스트를 통과하는 완전한 소프트웨어 제품을 생성할 수 있다. 공급망 위험 없음, 유지보수 부담 없음, 의존성 관리 없음, 민감 정보 유출 가능성 없음.
이것은 오픈소스의 종점이 아니라, 새로운 기원의 시작이다 — 포스트 코드 시대의 소프트웨어 배포.
지금의 오픈소스는 모든 사람이 한 그루의 거목에 거름을 주고 물을 주게 하고, 모든 사람이 그 거목 위에 깃들게 한다. 뿌리가 썩으면 모두 함께 쓰러진다. 유지보수자가 탈진하면 거목이 시들고, 그 위에 기생하는 모든 것이 함께 소멸한다.
진정한 오픈소스는 씨앗을 뿌리는 것이어야 한다. 씨앗(설계 도면)을 뿌려서 서로 다른 토양(서로 다른 사용자의 로컬 환경)에 떨어지게 하고, 서로 다른 햇빛과 물(서로 다른 AI 모델)로 서로 다른 식물(개인화된 소프트웨어)을 키운다. 각 식물은 모두 다르지만, 유전자는 같다 — 보안의 유전자, 견고한 아키텍처의 유전자.
씨앗은 중독을 두려워하지 않는다 — 변조된 유전자로는 생존 가능한 식물이 자라지 못하기 때문이다. 씨앗은 유지보수가 필요 없다 — 성장은 토양과 햇빛의 일이기 때문이다. 씨앗은 만료되지 않는다 — 유전 정보는 어떤 시대에든 해독될 수 있기 때문이다.
Open Architecture는 AI 시대의 씨앗이다.
“누구든 이 세 문서를 가져다가, 어떤 AI에든 먹이고, 내 전체 제품을 처음부터 재구축할 수 있다. 나는 그만큼 자신 있다.”
코드는 해자가 아니다. 사유가 해자다.
참고문헌 및 감사의 글
[1] LiteLLM Security Update, March 24, 2026 — docs.litellm.ai/blog/security-update-march-2026
[2] Snyk: How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM — snyk.io/articles/
[3] Cisco: Personal AI Agents like OpenClaw Are a Security Nightmare — blog.talosintelligence.com
[4] ARMO: The Library That Holds All Your AI Keys Was Just Backdoored — armosec.io/blog/
[5] Trend Micro: Security Analysis of OpenClaw — trendmicro.com
[6] LiteClaw Task Execution Architecture V1.0, February 2026
[7] LiteClaw Task Card System (Complete Edition), 29 Tasks × 7 Phases
[8] LiteClaw BUILD_GUIDE.md, March 28, 2026 — 3라운드 실전 검증 데이터
본 논문은 2026년 3월 28일 Claude Opus 4.6(Anthropic) 대화 창에서의 완전한 토론을 기반으로 생성되었습니다. 모든 실험 데이터는 당일 실제 테스트 결과입니다.