Kwangmin Kim - 하네스 엔지니어링 산업 사례 — Project 1M, 역할 분리, 동료 스킬, 원클릭 도구

1 이 글의 위치

지금까지 24-Agent-Architecture 시리즈에서 하네스 엔지니어링의 이론적 골격을 세 차례 다뤘다.

번호	주제	다룬 것
31번	Prompt · Context · Harness 세 층위의 구분과 포함 관계	개념 정의 — 동심원 구조, 포함 관계, 실무 진단 순서
30번	Claude Code vs Copilot CLI 하네스 설계 차이	하네스 비교 — 5 대 축(압축·Tool lifecycle·길이·Skill 로딩·Protected zone) 통제 실험
32번	AGENT_GUIDE 체계 3 층 해부, Cross-cutting Concern, 아키텍트 vs 아키텍처	자체 체계 위치 분석 — Harness-aware Context Engineering 명명

이 세 글은 개념·비교·자기 체계 라는 학술 축에 머문다. 그러나 같은 시기에 산업 현장에서는 하네스 엔지니어링이 구체적 제품·인프라·서비스로 이미 구현되고 있다. 이 글은 그 산업 사례 를 정리하고, 31번 동심원 모델과 32번 자기 체계 해부에 어떻게 매핑되는지 명시한다.

이 글의 입장

이 글은 산업 동향의 카탈로그 가 아니다. 사례 하나하나를 31번 정의 안에서 어디에 위치시킬지, 32번 자기 체계와 어떻게 비교될지를 묻는다. 즉 산업 사례를 거울로 삼아 자체 framework 의 유효성을 검증 하는 것이 목적이다.

2 OpenAI Project 1M — 100 만 줄을 3 명이 만든 하네스 인프라

2.1 사례 개요

오픈AI 의 라이언 로포폴로가 2025-2026 년 발표한 사내 실험. 핵심 도전 과제는 단순했다.

“단 한 줄의 기능 코드도 직접 짜지 않고, AI 로 전체 프로젝트를 진행할 수 있을까.”

결과는 다음과 같이 보고됐다 (미라클레터 1010 호 인용).

항목	수치
인원	엔지니어 3 명
기간	5 개월
산출	프로덕션급 100 만 줄
버그 발생률	인간 작성 대비 40% 낮음
문서화	비교 불가능한 수준

성공의 본질은 모델 성능이나 프롬프트 기법이 아니라 AI 가 일하는 작업장의 구조 였다는 것이 사례의 핵심 주장이다. 로포폴로의 표현으로 “엔지니어의 핵심 역할은 모델을 훈련시키는 것이 아니라, 모델이 최상의 성과를 낼 수 있는 완벽한 작업장을 만드는 것” 이다.

2.2 신입사원 7 가지 도구

오픈AI 가 제시한 작업장의 구성 요소는 7 가지다. 인간 신입사원에게 회사가 제공하는 인프라와 구조적으로 동일하게 설계됐다.

도구	인간 비유	하네스 역할	31번 층위 매핑
Repository 문서화	회사 내부 위키	코드·문서·규칙·이력의 단일 진실 공간	Context (정보 위치)
`AGENTS.md`	입사 첫날 매뉴얼	회사 방식·읽을 순서·필수 규칙·확인 사항	Context + Prompt
Linter	친절한 선배의 즉시 지적	맞춤법·양식·규칙 위반 자동 감지	Harness (실행 시 강제)
구조 테스트	사내 시험	“고객 정보는 반드시 이 절차” 같은 도메인 규칙 검증	Harness (실행 게이트)
리뷰 자동화	엄격한 선배	결과물 처음부터 끝까지 실시간 확인	Harness (피드백 루프)
관측 가능성	업무 일지·증거	AI 가 무엇을 했는지·왜 실수했는지 추적	Harness (감사 추적)
워크트리(Worktree)	연습용 공책	본 프로젝트 전 테스트·수정 격리 공간	Harness (격리·롤백)

2.3 31번 모델로의 해석

이 7 가지를 31번의 동심원에 배치하면 5 개가 Harness 층 에 속한다. Project 1M 의 진정한 혁신은 모델 성능 개선이 아니라 Harness 인프라를 인간 회사 운영 모델과 동형으로 설계 한 것이라는 결론이 나온다.

┌─────────────────────────────────────────────┐
│  Harness Engineering — 5 개 도구            │
│  (Linter · 구조 테스트 · 리뷰 자동화 ·      │
│   관측 가능성 · Worktree)                   │
│                                             │
│  ┌─────────────────────────────────────┐   │
│  │  Context Engineering — 1.5 개       │   │
│  │  (Repository 문서화 + AGENTS.md     │   │
│  │   의 정보 배치·로딩 정책)            │   │
│  │  ┌───────────────────────────┐     │   │
│  │  │  Prompt — 0.5 개           │     │   │
│  │  │  (AGENTS.md 의 지시문)     │     │   │
│  │  └───────────────────────────┘     │   │
│  └─────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

AGENTS.md 가 Context 와 Prompt 를 동시에 건드리는 cross-cutting 성격을 띤다는 점은 32번에서 정의한 패턴과 정확히 일치한다.

2.4 `AGENTS.md` vs `CLAUDE.md` — 명명만 다른 동일 패턴

AGENTS.md 는 OpenAI 가 제안한 표준이고 CLAUDE.md 는 Anthropic Claude Code 의 사용자 진입점 파일이다. 두 파일의 역할은 본질적으로 같다.

비교 항목	`AGENTS.md` (OpenAI)	`CLAUDE.md` (Anthropic)
위치	프로젝트 루트	프로젝트 루트 또는 `~/.claude/`
로딩 시점	세션 시작	세션 시작
내용	회사 방식·규칙·읽을 순서	프로젝트 규칙·코드 컨벤션·페르소나
31번 층위	Context (정보 배치) + Prompt (지시문)	Context + Prompt
32번 패턴	Cross-cutting concern	Cross-cutting concern

이는 하네스 엔지니어링 시장이 사실상 동일한 패턴으로 수렴 중 임을 보여주는 강한 증거다. 이 블로그 프로젝트의 CLAUDE.md + AGENT_GUIDE.md 체계도 같은 패턴의 한 사례에 불과하다.

3 Anthropic 의 분리 모델 — 하네스 / 세션 / 샌드박스 3 분할

3.1 반려동물 vs 가축 비유

Anthropic 은 같은 시기에 다른 각도의 처방을 제시했다. 한 명의 신입(단일 LLM 인스턴스)이 모든 역할을 떠맡지 말고 역할별로 분리 하라는 것이다. 비유는 “반려동물(Pet) vs 가축(Cattle)” 인데, 운영 측면에서 익숙한 인프라 패턴이다.

반려동물 모델: 한 인스턴스가 모든 역할을 떠맡고 망가지면 전체 작업이 무너진다
가축 모델: 역할별 인스턴스로 분리해 하나가 망가져도 그 부분만 교체하면 된다

3.2 3 가지 역할

Anthropic 의 분리는 다음 3 분할이다 (미라클레터 1010 호 인용).

역할	책임	대응되는 LLM 인프라
Harness	생각·판단·다음 행동 결정	메인 추론 LLM, 라우팅
Session	지금까지 무엇을 했는지 기록	메모리 시스템·로깅
Sandbox	실제 작업 실행	격리된 실행 환경(컨테이너·VM·worktree)

3.3 31번·30번 모델과의 정합성

이 분리는 31번에서 정의한 Harness 층의 내부 구조 를 한 단계 더 쪼갠 것이다. 31번의 Harness 가 “모델·도구·맥락을 관리하는 시스템” 이라면, Anthropic 의 분리는 그 시스템을 판단 / 기록 / 실행 세 부분으로 분해한다.

또한 30번에서 다룬 Claude Code vs Copilot CLI 비교의 일부 차이가 이 분할 관점에서 재해석된다.

30번 5 대 축	Anthropic 3 분할 매핑	Claude Code	Copilot CLI
Auto-compaction	Session(기록) 정책	자동 압축	명시 호출만
Tool result lifecycle	Session(기록) 보존	임시 버퍼	한계 전 보존
Protected zone	Harness(판단) 격리	불확실	추정 존재
Skill 로딩	Harness(판단) → Sandbox(실행) 위임	Eager 메타 + Lazy	명시 Read
응답 길이 제약	Harness(판단) 출력 제어	25/100 단어 강제	약함

5 대 축이 모두 Harness/Session 두 영역에 매핑된다. Sandbox(실행) 분리는 두 CLI 모두 부분적 이며, 이 영역이 다음 산업 진화의 핵심 격전지가 된다는 해석이 가능하다 (뒤의 “원클릭 코딩” 참조).

4 두 접근의 비교 — 7 가지 도구 vs 3 분할

OpenAI 의 7 가지 도구와 Anthropic 의 3 분할은 다른 차원의 답 이다. 한쪽은 무엇을 갖출지 의 인프라 목록이고, 다른 쪽은 어떻게 분리할지 의 아키텍처 원칙이다.

4.1 매핑 표

OpenAI 도구	Anthropic 분리 매핑	책임 영역
Repository 문서화	Session(기록)	누적된 작업 이력
`AGENTS.md`	Harness(판단) 입력	행동 규칙
Linter	Sandbox(실행) 자동 검사	실행 시 게이트
구조 테스트	Sandbox(실행) 도메인 검증	비즈니스 규칙
리뷰 자동화	Harness(판단) 피드백 루프	품질 평가
관측 가능성	Session(기록) 추적	행동 로그
Worktree	Sandbox(실행) 격리	안전한 실험장

7 가지 도구가 3 분할에 빈틈없이 분배 된다. 두 모델이 표면상 다르지만 내부적으로는 상호 보완적 임을 의미한다. OpenAI 가 도구의 충실성으로 접근했다면, Anthropic 은 시스템의 분리 가능성으로 접근했다.

4.2 시사점 — 실무 도입 순서

만약 한 조직이 이 두 모델을 모두 받아들인다면 도입 순서는 다음과 같이 추론할 수 있다.

Sandbox 확보 우선: Worktree·격리 실행 환경부터 구축한다(되돌릴 수 있어야 실험이 가능)
Session 인프라 확장: Repository 문서화 + 관측 가능성으로 행동 추적을 확보한다
Harness 규칙 정립: AGENTS.md + 리뷰 자동화로 판단 기준을 명문화한다
자동 게이트 추가: Linter + 구조 테스트로 실행 시 강제 검증을 더한다

이 순서가 의미 있는 이유는 하위 인프라가 없으면 상위 규칙이 작동하지 않기 때문 이다. 격리 환경이 없는데 자동 리뷰 규칙만 추가하면, 잘못된 판단이 그대로 프로덕션을 망가뜨린다. 31번에서 “문제 해결은 자신의 층 또는 바깥 층에서 가능하다” 고 했던 원칙이 도입 순서에도 그대로 적용된다.

5 동료 스킬(리우 자오 사례) — 페르소나 보존이라는 새로운 차원

5.1 사례 개요

중국의 24 세 개발자 리우 자오가 2025-2026 년 깃허브에 공개한 프로젝트 “동료 스킬”. 슬로건은 다음과 같다.

“차가운 이별을 따뜻한 스킬로 바꿔보세요. 사이버 불멸의 세계에 온 것을 환영합니다.”

핵심 아이디어는 퇴사한 직원의 메신저 대화·이메일·코드·문서를 AI 에 학습시켜 디지털 페르소나 로 보존하는 것이다. 미라클레터 1010 호에 따르면 공개 후 3 주 만에 깃허브에서 1 만 3,400 개 이상의 스타를 획득했다.

5.2 기술 구성

미라클레터에 보고된 구성 요소는 다음 3 가지다.

단계	역할	31번 층위
데이터 정제	3 년치 슬랙 메시지·깃허브 커밋에서 업무 판단 근거 추출	Context (정보 큐레이션)
RAG 최적화	과거 문서·코드를 실시간 참조하여 의사결정	Context (외부 지식 주입)
말투 복제	파인튜닝으로 전문 용어·문체 재현	모델 가중치 (별도 층)

5.3 31번 모델로의 해석 — 4 번째 층의 등장 가능성

여기서 31번 동심원 모델에 균열이 생긴다. 동료 스킬의 말투 복제(파인튜닝) 는 Prompt·Context· Harness 어디에도 깔끔하게 속하지 않는다. 모델 가중치 자체를 페르소나에 맞게 조정하는 것은 모델 안쪽의 작업 이다.

엄격히 말하면 동심원의 가장 안쪽에 새 층이 추가될 수 있다.

┌─────────────────────────────────────────────┐
│  Harness                                    │
│  ┌─────────────────────────────────────┐   │
│  │  Context                            │   │
│  │  ┌───────────────────────────┐     │   │
│  │  │  Prompt                   │     │   │
│  │  │  ┌─────────────────┐     │     │   │
│  │  │  │  Model Weights  │     │     │   │  ← 동료 스킬은 여기를 건드린다
│  │  │  │  (Persona)      │     │     │   │
│  │  │  └─────────────────┘     │     │   │
│  │  └───────────────────────────┘     │   │
│  └─────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

중요한 단서: 31번에서 모델 가중치를 다루지 않은 것은 “그 층은 모델 벤더가 책임지는 영역” 이라 가정했기 때문이다. 동료 스킬은 그 가정을 깨고, 사용자가 직접 모델 가중치를 페르소나로 커스터마이즈 한다.

5.4 윤리·법적 차원 — 산업 적용 시 고려사항

미라클레터에 따르면 중국 경제일보가 다음과 같이 보도했다.

“직원의 전문 지식은 개인의 고유 자산이다. 대가 없는 AI 학습은 엄격히 금지되어야 한다.”

리우 자오의 항변은 다음과 같다.

“기술이 복제하는 것은 사람 전체가 아니라, 반복 가능한 업무 패턴과 모듈화된 지식일 뿐이다.”

이 논쟁은 하네스 엔지니어링이 단순 인프라 문제가 아니라 데이터 소유권·동의·정당한 사용 의 문제로 확장된다는 신호다. Anthropic 의 Sandbox 격리, OpenAI 의 관측 가능성도 결국 이 차원의 요구를 충족하기 위한 선제적 설계로 볼 여지가 있다.

6 원클릭 코딩 — 바이브엑스·누비다와 가축 모델의 본격화

6.1 사례 개요

미라클레터에서 소개된 두 도구는 Anthropic 의 가축 모델(역할 분리)을 사용자 인터페이스 수준 까지 밀어붙인 사례다.

도구	회사	출시	핵심
바이브엑스(Vibe X)	고투엑스(GotoX)	출시됨	자연어로 웹사이트 기획~배포 전 과정
누비다(nuvida)	오픈랩스	2026.6 예정	기획/코드/테스트/보안/배포 가상 개발팀

6.2 누비다의 역할 분리 — Anthropic 모델의 시각화

누비다는 미라클레터 보도 기준 3 개 AI 로 역할을 분리한다.

AI	역할	Anthropic 분리 매핑
AI 1	기획	Harness(판단) — 사용자 의도 → 사양
AI 2	코드 생성	Sandbox(실행) — 격리 환경 코드 작성
AI 3	테스트와 검증	Sandbox(실행) + Session(기록) — 검증 결과 누적

이 매핑은 Anthropic 의 3 분할 모델이 상품으로 구체화된 형태 임을 시사한다. 회사 내부망 설치 방식을 준비 중이라는 점에서 금융·공공기관 같은 보안 민감 환경을 정조준한다.

6.3 30번 비교 모델로의 해석

누비다의 출시는 30번에서 다룬 Claude Code vs Copilot CLI 의 trade-off 가 세 번째 진화 단계 로 넘어가고 있다는 신호다. 30번에서 두 도구의 약점을 정리한 결론을 다시 상기한다.

Claude Code 의 약점: 잊음(압축·길이 제약·tool result 비영속성)
Copilot CLI 의 약점: 무거움(보존 우선의 비용·지연·오버킬)

원클릭 코딩 도구는 이 두 약점을 역할 분리로 우회 한다. 기획 AI 가 잊음을 방지하고(상위 판단 보존), 코드 AI 가 무거움을 흡수하며(격리 실행), 테스트 AI 가 추적성을 담당한다. 30번에서 제시한 hybrid workflow 전략(탐색은 Claude Code, 작성은 Copilot CLI)이 제품 내부에 이미 내장된 형태 다.

6.4 한계 — 시장 위험 신호

다만 미라클레터의 보도 시점이 누비다의 출시 전 이라는 점은 주의해야 한다. 다음 위험이 관찰 가능한 시점에 검증돼야 한다.

위험	검증 시점	평가 기준
역할 간 통신 비용	출시 후	3 AI 호출의 latency 합
격리 실행 환경의 일관성	1~3 개월 후	동일 사양에서의 결과 reproducibility
엔터프라이즈 도입 실적	6 개월 후	금융·공공 도입 사례 수

7 시장 진화의 단계적 해석

미라클레터가 제시한 “프롬프트 → 컨텍스트 → 하네스” 진화는 31번 동심원 모델의 시간축 투영 으로 해석할 수 있다. 그러나 이번 글에서 본 사례를 더하면 한 단계 더 길어진다.

단계	시기	산업 표지 사례
프롬프트 엔지니어링	2022-2023	“잘 쓰는 프롬프트” 가이드 붐
컨텍스트 엔지니어링	2023-2024	RAG · LangChain 보편화
하네스 엔지니어링	2024-2025	Claude Code · Copilot CLI · `AGENTS.md`
페르소나 + 분리 엔지니어링	2026~	동료 스킬 · 누비다 · Anthropic 가축 모델

4 단계는 31번의 동심원에 두 가지 변화를 가져온다.

안쪽으로: 모델 가중치 층 추가(파인튜닝 기반 페르소나)
바깥쪽으로: 단일 하네스가 아닌 다중 하네스의 오케스트레이션 층 추가(가축 모델)

31번 동심원 모델의 갱신

원래 31번에서는 Prompt ⊂ Context ⊂ Harness 의 3 층 동심원을 제시했다. 2026 년 산업 사례를 반영하면 다음 5 층으로 확장 가능하다.

Orchestration  ⊃  Harness  ⊃  Context  ⊃  Prompt  ⊃  Model Weights
   (다중 하네스 조율)         (3 층 그대로)         (페르소나 커스터마이즈)

가장 안쪽 Model Weights 는 모델 벤더가 아닌 사용자가 직접 조정 한다는 점이 새롭고, 가장 바깥쪽 Orchestration 은 단일 LLM 의 한계를 다중 인스턴스 분리 로 풀어낸다.

8 이 블로그 AGENT_GUIDE 체계의 산업적 위치

32번에서 이 블로그 프로젝트의 AGENT_GUIDE 체계를 Harness-aware Context Engineering 으로 명명했다. 산업 사례를 거울로 삼아 그 위치를 다시 점검한다.

8.1 좌표 매핑

비교 축	이 프로젝트	산업 사례 위치
Harness	Claude Code · Gemini CLI 차용	OpenAI: 자체 구축 / Anthropic: 자체 구축 / 누비다: 자체 구축
`AGENTS.md` 등가물	`CLAUDE.md` + `AGENT_GUIDE.md`	OpenAI: `AGENTS.md`
Linter / 구조 테스트	Quarto render 검증, Self-Check 출력 의무	OpenAI: 자동화된 사내 도구
리뷰 자동화	`/audit` 슬래시 커맨드	OpenAI: 사내 리뷰 시스템
관측 가능성	git log + auto memory + MEMORY.md	OpenAI: 전사 추적 인프라
Worktree	Claude Code 의 worktree isolation	OpenAI: 격리 실행 환경
페르소나	사용자 1 명의 글 스타일 메모리	동료 스킬: 퇴사자 페르소나
분리	단일 LLM 세션	누비다: 3 AI 분리

8.2 결론 — 이 프로젝트의 산업적 좌표

이 블로그 프로젝트는 산업 진화의 3 단계(하네스) 끝자락 에 위치한다. OpenAI 7 가지 도구의 대부분을 차용 형태로 갖추고 있고, CLAUDE.md 가 AGENTS.md 와 동일 패턴을 구현한다. 그러나 4 단계(페르소나 + 분리) 의 두 축은 약하다.

페르소나 축: auto memory 가 사용자 선호를 누적하지만, 파인튜닝 기반 페르소나는 없음
분리 축: 단일 LLM 세션 의존, Subagent 시스템이 있으나 Anthropic 의 하네스/세션/샌드박스 분리에는 도달하지 못함

다음 진화 방향은 두 가지로 압축된다.

분리 도입: Subagent 를 더 명시적으로 Harness/Session/Sandbox 역할로 분리
페르소나 강화: auto memory 를 단순 누적에서 스타일 학습된 모드 로 발전

다만 이는 개인 블로그 프로젝트의 적정 규모를 넘는 과잉 엔지니어링 일 가능성이 크다. 32번의 결론과 동일하게, Harness 와 4 단계 인프라는 대기업 팀이 전담하는 영역이다. 이 프로젝트는 3 단계의 충실한 사용자 + 4 단계 trend 의 관찰자 로 위치하는 것이 합리적이다.

9 결론

9.1 한 문장 요약

2026 년 산업은 OpenAI 의 7 가지 도구(AGENTS.md · Linter · 구조 테스트 · 리뷰 자동화 · 관측 가능성 · Worktree · Repository 문서화), Anthropic 의 하네스/세션/샌드박스 3 분할, 동료 스킬의 페르소나 보존, 누비다의 다중 AI 분리로 하네스 엔지니어링을 인프라·아키텍처·페르소나·오케 스트레이션 4 차원으로 확장 하고 있다.

9.2 31번 동심원 모델의 갱신 제안

3 층(Prompt · Context · Harness) → 5 층(Model Weights · Prompt · Context · Harness · Orchestration) 으로 확장한다. 안쪽은 동료 스킬 같은 페르소나 커스터마이즈, 바깥쪽은 누비다 같은 다중 인스턴스 분리가 채운다.

9.3 30번 비교 모델의 다음 단계

Claude Code 의 “잊음” 과 Copilot CLI 의 “무거움” trade-off 는 역할 분리 로 우회 가능하다. 누비다의 3 AI 분리(기획·코드·테스트)가 그 가능성을 보여준다. 6 개월 후 출시 시점의 실측이 필요하다.

9.4 32번 자체 체계의 좌표 갱신

이 블로그 프로젝트는 산업 3 단계의 충실한 사용자 위치에 머물고, 4 단계(페르소나 + 분리) 는 관찰 대상으로 둔다. 개인 프로젝트의 적정 규모를 넘는 인프라는 대기업 책임 영역이라는 32번 결론은 유효하다.

9.5 핵심 메시지 3 가지

하네스 엔지니어링은 산업이 이미 구현 중인 사실 이며, 31번의 학술적 정의가 사후 정당화가 아닌 사전 진단으로 작동한다
OpenAI · Anthropic · 중국 · 한국의 사례 가 같은 패턴(Harness 인프라 + 분리 + 페르소나) 으로 수렴 중이며, AGENTS.md ≈ CLAUDE.md 가 그 표지다
다음 1 년의 격전지 는 Sandbox 분리와 페르소나 커스터마이즈이며, 두 축 모두 데이터 소유권·동의·정당한 사용의 윤리 논쟁과 결합된다

10 관련 주제

선행 시리즈 (이 글의 전제)

관련 아키텍처 분석

스킬 생태계

11 참고문헌

11.1 1 차 자료(공식)

Anthropic. (2025). Claude Code Documentation. https://docs.claude.com/claude-code
OpenAI. (2025). AGENTS.md Specification. https://agents.md (산업 표준 제안)
GitHub. (2025). GitHub Copilot CLI Documentation. https://docs.github.com/copilot

11.2 2 차 자료(저널리즘)

이상덕. (2026.4.20). 하네스 엔지니어링 A to Z. 미라클레터 1010 호. 매경미디어그룹.
- OpenAI Project 1M, Anthropic 분리 모델, 동료 스킬, 바이브엑스, 누비다 사례의 출처

11.3 학술 배경

Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. arXiv:2210.03629.
Packer, C. et al. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560.
Anthropic. (2024). Model Context Protocol (MCP) Specification. https://modelcontextprotocol.io

11.4 동료 스킬 관련 보도

중국 경제일보. (2026). 동료 스킬 윤리 논쟁 보도(미라클레터 1010 호 재인용).
리우 자오. (2026). Colleague Skill GitHub Repository (스타 13.4k+, 공개 후 3 주).

출처 검증 주의

OpenAI Project 1M 의 구체 수치(3 명, 100 만 줄, 버그 40% 감소) 와 누비다 출시 일정(2026.6) 은 미라클레터 1010 호 보도를 단일 출처로 한다. OpenAI · 오픈랩스의 공식 발표문이 별도로 확인되면 인용 신뢰도가 강화된다. 본 글은 보도 시점 기준 정보로 작성됐으며, 추후 사실 변경 시 이 글의 표·결론을 갱신해야 한다.