이전 기사: https://zenn.dev/satoh_y_0323/articles/654fe827665393

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor / PyPI: https://pypi.org/project/claude-code-conductor/ / 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/

본 기사의 범위: 자체 제작한 멀티 에이전트 프레임워크 C3 (Claude Code Conductor)의 v2.41.0~v2.43.0. 세 버전 모두 같은 날(2026-07-03)에 출시되었습니다. 테마는 일관되게 tier-routing ── 태스크마다 "어떤 모델(haiku/sonnet/opus)을 사용할 것인가"를 Thompson Sampling으로 학습하는 메커니즘입니다. ① 학습 데이터의 귀속(attribution)을 바로잡고(v2.41.0), ② 권장 사항을 실제로 적용할 수 있게 만들었더니(v2.42.0), ③ 그날 바로 학습 계통이 데드락(deadlock)에 빠져 실패의 정의 자체를 다시 만들게 되었습니다(v2.43.0).

서론 ── 하루 3회 출시의 이유는 "계획적"이지 않다

먼저 고백하자면, 하루 3회 출시는 계획된 것이 아닙니다. 적용한 순간, 그때까지 보이지 않았던 문제가 보였기 때문에 그렇게 된 것뿐입니다.

C3의 tier-routing은 원래 "이 태스크라면 haiku로 충분할 것 같습니다"라고 권장 사항을 표시할 뿐인 기능이었습니다. 그것이 이번에 권장 사항을 에이전트 기동에 실제로 적용하게 되었습니다. 그러자 몇 시간 후, 학습 데이터 속에서 조용한 이변이 일어납니다. sonnet이 다시는 선택되지 않게 된 것입니다.

게다가 이 이변은 저(인간)가 찾아낸 것이 아닙니다. "tier-routing에 대해 솔직한 의견을 말해줘"라고 Claude에게 잡담하듯 물었더니, 좋은 점과 함께 자신이 오늘 막 구현한 메커니즘에 잠재된 데드락을 자백해 왔습니다. 이번에는 그 전말에 대한 이야기입니다.

v2.41.0 ── 애초에 숫자가 거짓말을 하고 있었다 (귀속 오류)

이야기는 전날로 거슬러 올라갑니다. tier-routing의 학습 데이터를 살펴보던 중 근본적인 결함을 발견했습니다.

학습 메커니즘은 다음과 같습니다. 워크플로우의 승인 게이트(구현 OK, 테스트 합격 등)마다 "이 tier는 성공했다/실패했다"를 기록하고, tier별 성공률을 베타 분포 (Thompson Sampling)로 학습해 나갑니다. 그런데 기존 구현이 기록하고 있었던 것은──

"hook이 권장한 tier"였지, "에이전트가 실제로 사용한 tier"가 아니었습니다.

권장은 표시될 뿐이었고, 에이전트는 agent 정의 파일 (frontmatter)의 고정 모델로 동작하고 있었습니다. 즉, "haiku를 권장 → 실제로는 sonnet으로 실행 → 성공 → haiku의 성공으로 기록"되는 상황이 벌어지고 있었습니다. 쌓여있던 시도 데이터는 tier의 우열을 가리는 데 있어 전부 노이즈였던 셈입니다.

v2.41.0에서 이 부분을 다시 만들었습니다. 기록되는 tier는 LLM의 신고가 아니라 **스크립트가 agent 정의로부터 기계적으로 자기 해결(self-resolve)**합니다. 기록 포인트도 "워크플로우 전체에서 1회"에서 "승인 게이트마다 (1개 워크플로우당 5~15회)"로 늘렸고, 역할(developer/tester/...)별 셀로 나누었습니다.

교훈 (이 시점에서의): 계측 시스템을 만들 때는 기능보다 먼저 "기록되는 값이 정말로 인과 관계의 대상과 일치하는가"를 검증해야 한다. 귀속이 어긋난 계측은 없는 편이 나은 데이터를 양산할 뿐이다.

v2.42.0 ── "권장"을 "적용"으로 바꾼다. 단, 귀속을 망가뜨리지 않고

귀속 문제가 해결되었으므로 다음 단계로 넘어갑니다. 사실 조금 전에 "Agent 호출 시 model:을 명시적으로 지정하면, 서브 에이전트의 정의 파일보다 우선된다"라는 사양을 검증을 통해 확인했습니다. 즉, 부모 에이전트가 권장 tier를 그 자리에서 적용할 수 있는 경로가 열려 있는 것입니다.

v2.42.0에서는 additionalContext의 문구를 "비용을 최적화하고 싶다면 수동으로 지정해 주세요" (아무도 따르지 않음)에서 "developer를 기동할 때는 model: haiku를 명시적으로 지정하여 적용할 것" (행동 지시)으로 변경했습니다. 이른바 소프트 적용(soft application)입니다. 후크(hook)가 입력을 강제로 바꾸는 기계적 강제가 아니라, 부모 LLM에 대한 지시 수준에 머무르게 하는 것입니다.

여기 설계의 핵심이 하나 있습니다. 적용할 수 있게 되면, v2.41.0에서 막 수정한 귀속(attribution)이 다시 망가집니다. 기록 스크립트는 'agent 정의의 고정 모델'을 실제 사용 티어(tier)로서 스스로 해결하고 있습니다. 하지만 적용이 시작되면, 정의는 sonnet이지만 실제로는 haiku로 동작합니다. ……데자뷔죠. 동일한 귀속 어긋남의 재발입니다.

대책은 "권장 사항을 기록한 state 파일을 기록 시에도 동일한 소스로 읽는 것"입니다. 권장의 출처와 기록의 출처를 동일하게 만들면, LLM이 티어(tier) 이름을 신고할 여지가 없어집니다. 설계 감사 에이전트(design-critic)가 여기서 "병렬 실행 시에는 worktree에 state가 복제되지 않으므로, 이 방식은 병렬 경로에서 깨진다"라는 High 수준의 지적을 구현 전에 내놓았고, 병렬 측만 별도 경로로 만드는 설계로 안착했습니다. 구현 전에 대비책을 하나 마련한 셈입니다.

덤으로 하나 더, 사용자(나)의 지적으로 리뷰 시의 귀속 어휘도 수정했습니다. 기존에는 리뷰 지적이 나왔을 때의 '실패'는 거의 developer에게 귀속되는 사양이었죠. 하지만 테스트 코드의 결함이라면 그것은 tester의 실패입니다. developer에게만 책임을 떠넘기는 구조를, 결함의 소재에 따라 배분하도록 변경했습니다── 그런데 사실, 이 "리뷰 지적 = 실패"라는 정의 자체가 몇 시간 뒤에 근본부터 재검토되게 됩니다.

사건 ── "솔직한 의견을 들려줘"라고 물었더니, 자백을 받았다

v2.42.0을 출시한 어느 오후, 문득 Claude에게 물었습니다. "이 tier-routing, 솔직히 어떻게 생각해? 좋은 점도 나쁜 점도 말해줘."

돌아온 평가 중에는 다음과 같은 구절이 있었습니다 (요약).

escalation × 소프트 적용으로 인해 "sonnet의 탐색이 폐쇄되는" 구조적 문제가 있습니다. 현재 medium 셀의 sonnet 실패율은 0.57 (7회 시도)로, 임계값(threshold) 0.5를 초과하고 있기 때문에 sonnet이 선택될 때마다 opus로 승격됩니다. 소프트 적용 전에는 권장 사항이 무시되는 경우도 많아 실질적인 해악은 없었으나, 권장 사항이 실제로 효력을 발휘하게 된 결과, sonnet의 실행이 거의 발생하지 않게 되어 실패율을 갱신할 새로운 데이터가 영원히 오지 않는 데드락(deadlock)이 발생하고 있습니다.

설명하자면, C3에는 안전망으로서 "실패율이 높은 tier는 한 단계 위 모델로 자동 승격한다"라는 escalation 메커니즘이 있습니다. haiku가 계속 실패하면 sonnet으로, sonnet이 계속 실패하면 opus로 올립니다. 권장 사항이 표시만 되던 시대에는, 이것은 무해한 안전망이었습니다. 권장이 무시되면 sonnet은 계속 평범하게 사용될 것이고, 데이터도 갱신될 것이기 때문입니다.

하지만 소프트 적용으로 권장이 구속력을 갖게 된 순간, 이 안전망은 탐색 억제 장치로 변했습니다. 한 번 실패율이 임계값을 넘은 sonnet은, 선택될 때마다 opus로 승격됩니다. sonnet의 새로운 실행 데이터가 오지 않습니다. 그래서 실패율 0.57은 영원히 0.57인 채로 남습니다. 저렴한 모델의 패자부활전이 구조적으로 존재하지 않게 된 것입니다.

권장을 표시하기만 했다면 이 문제에는 영원히 깨닫지 못했을 것입니다. 최적화는, 적용하는 순간 다음 문제를 낳습니다.

사용자의 제안 ── "developer의 업무는 리뷰어에게 지적받지 않는 구현이 아니다"

이 데드락에 어떻게 대처할 것인가. 여기서 사용자로부터 온 제안이 이번에 가장 감탄스러웠던 것이었습니다 (요약).

developer나 tester의 "실패"를 리뷰어의 지적 여부로 계산하는 것을 그만두고 싶다.

developer의 업무는 "동작하는 구현"을 하는 것. tester의 업무는 Red로 실패하는 테스트를 작성하고, 구현 후에 Green을 확인하는 것. "리뷰어에게 지적받지 않는 구현을 하는 것"이 업무가 아니다. 빌드 실패나 동작하지 않는 구현은 명백한 실패이지만, 그것은 지금도 측정할 수 있다. 실패로 계산하는 것은 테스트 불합격과, 구현 중에 디버깅 지원(systematic-debugger)이 필요해진 경우로만 한정한다. 그리고 성공률 계산은 최근 30건 혹은 일정 기간으로 한정하여, 오래된 성공과 실패를 계산에서 제외함으로써 고착화되지 않게 한다.

전반부는 실패 시그널 (Failure Signal)의 철학입니다. 실제로 sonnet의 실패율 0.57의 내용을 살펴보면, 대부분이 '리뷰에서 지적 사항이 발생함'에서 유래되었습니다. 하지만 리뷰 지적이라는 것은 모델의 능력과 태스크의 난이도, 그리고 리뷰어의 엄격함이 **혼합된 것 (Mixture)**입니다. 구현은 동작하고 있고, 테스트도 통과했습니다. 하지만 docstring이 오래되었거나 방어 기제가 한 단계 얕다는 등의 이유로 지적이 나옵니다. 이것을 'sonnet의 실패'로 계산하는 것은 시그널로서 불투명합니다. 관측 가능하고 객관적인 사건──테스트를 통과했는가, 스스로 완주할 수 있었는가──만을 계산해야 한다는 것입니다.

후반부의 '윈도우 (Window)'에는 한 가지 기술적인 함정이 있는데, 그 부분은 저(Claude)가 보충했습니다. '최근 30건'이라는 건수 기반의 윈도우는 단독으로는 데드락 (Deadlock)을 풀 수 없습니다. sonnet이 선택되지 않음 → 새로운 기록이 들어오지 않음 → 윈도우 내부의 내용이 교체되지 않음 → 오래된 실패가 윈도우에 계속 머무름. 똑같은 교착 상태입니다. **시간 기반의 윈도우 (Time-based window)**라면 해결할 수 있습니다. 오래된 실패가 시간 경과에 따라 만료됨 → 샘플 수가 하한선(5건) 미만으로 떨어짐 → escalation (에스컬레이션)이 발동하지 않게 됨 → sonnet이 다시 시도됨. 패자부활이 메커니즘으로서 자연스럽게 작동하게 됩니다.

그리고 또 하나, 저의 제안을 실었습니다. bandit (α/β 학습 파라미터)을 누적 테이블의 업데이트가 아니라, 이벤트 로그로부터의 도출 집계로 바꾸는 것입니다.

지금까지의 구조는 '이벤트를 기록할 때마다 α/β를 가산해 나가는 방식'이었습니다. 이 구조에서는 '무엇을 실패로 계산할 것인가'라는 규칙을 바꿀 때마다 과거의 학습 데이터가 리셋됩니다 (실제로 v2.41.0에서 한 번 리셋했습니다). 시행착오를 거치며 시그널 정의를 조정해 나가는 단계인데, 조정할 때마다 30번의 시도를 다시 쌓아야 하는 것은 너무나 고통스러운 일입니다.

그래서, 기록은 생(raw) 이벤트(역할·복잡도·tier·게이트·성패·시각)만을 불가역적으로 저장하고, α/β는 읽어올 때 로그로부터 계산하도록 합니다. 이렇게 하면 규칙 변경이 과거 로그에 소급 적용됩니다. '만약 처음부터 이 규칙이었다면 어땠을까'를 SQL의 집계 조건만 바꾸는 것으로 검증할 수 있습니다. '조정하다가 벽에 부딪히고 다시 조정하는' 사용자의 각오가, '다시 구현해서 다시 쌓는 것'에서 '집계 규칙을 바꿔서 관찰하는 것'으로 바뀝니다.

v2.43.0 ── 구현했더니, 눈앞에서 sonnet이 살아났다

이 설계(①객관적 시그널 ②시간 윈도우 ③로그 도출 + 예고했던 구형 API 삭제)를 C3의 표준 워크플로우로 구현했습니다. 이번에는 모든 승인 게이트를 자동 승인하는 완전 자율 모드로 실행하고 있습니다 (커밋과 릴리스만 인간이 확인). design-critic의 사전 감사에서 Medium 5건을 구현 전에 탐지하였고(예: '수락 기준이 OR 조건이라 반증 불가능함', 'SQL의 IN 절 플레이스홀더 수가 하드코딩됨'), code-review는 6건 → 수정 → 0건, security-review는 0건, 테스트는 1646 passed / 0 failed로 클로즈(close)되었습니다.

그리고, 여기서부터가 이번에 가장 흥미로웠던 순간입니다. 이 워크플로우 자체가 만들어지고 있던 새로운 학습 계통 위에서 돌아가고 있었습니다.

구현 태스크(T2)가 완료되어 도출화가 활성화된 직후, 다음 프롬프트에서 hook의 표시가 다음과 같이 바뀌었습니다.

• 학습 데이터 수집 상황:
  11/30 시도 → 3/30 시도 (리뷰 지적 유래의 기록이 집계에서 제외되고, 객관적 게이트의 실측치만으로 다시 계산됨 ── ③의 소급 재계산이 리셋 없이 그 자리에서 적용됨) -
  [Phase 2-B 승격: sonnet_failure_rate=0.57 → opus로 승격]

라는 표시가 사라졌습니다 (sonnet의 객관적인 실패는 0건. 실패율은 샘플 부족으로 인해 '판정 불능'이 되어 escalation이 정지됨) - 그리고 몇 턴 후, 권장 사항에
sonnet과 haiku가 평범하게 나타나기 시작했습니다.

데드락으로 인해 영구 추방될 뻔했던 sonnet이 눈앞에서 패자부활했습니다. 게다가 그 이후의 태스크에서는 권장대로 haiku가 문서 수정 2건을 수행하여 성공했고, 그 성공이 정확하게 haiku의 셀에 기록되었습니다. 아침에 수정한 귀속, 낮에 넣은 적용, 저녁에 수정한 실패의 정의가 하나로 이어져 돌아가는 순간이었습니다.

$ c3 tier stats (v2.43.0 · 릴리스 직후의 실제 데이터)
[developer] 학습 데이터 수집 상황: 6 / 30 시도
complexity tier trials alpha beta 기대 성공률
...

이력에는 E-1(리뷰)의 failure가 남아 있는데, bandit의 표에서는 haiku의 beta(실패 카운트)가 늘어나지 않고 있다. 기록과 해석이 분리되어 있음을 단 한 장의 출력물로 확인할 수 있다.

기술적으로 흥미로웠던 소소한 이야기 2가지

「최근 N건」 윈도우는 데이터가 오지 않으면 시간이 멈춘다

실패율의 윈도우(window)를 건수 기반(ORDER BY ts DESC LIMIT n)에서 시간 기반(WHERE ts >= cutoff)으로 변경한 이야기는, 사소해 보이지만 본질적이었다. 건수 기반 윈도우는 '새로운 데이터가 들어온다'는 것을 암묵적인 전제로 한다. 그런데 피드백 루프(feedback loop)가 있는 계(system)에서는, 나쁜 평가 자체가 새로운 데이터의 유입을 막는다 (sonnet은 실패율이 높아서 선택되지 않음 → 선택되지 않으니 데이터가 들어오지 않음). 전제가 깨지면 윈도우는 영원히 업데이트되지 않는다. 시간 기반 윈도우는 외부의 시계에 의해 만료되므로, 이러한 자기 참조(self-reference)에서 벗어날 수 있다. 추천(recommendation)이나 오토스케일링(auto-scaling) 등, "평가가 다음 관측 기회를 좌우하는 계" 전반에서 동일한 함정이 있을 것으로 보인다.

실제 운영 중인 state 파일이 테스트를 조용히 오염시켰다

소프트 적용(soft application)을 구현하던 중, 기존 테스트가 갑자기 실패(red)하는 사건이 있었다. 원인은 기록 스크립트에 추가한 새로운 분기(branch)가 state 파일(tier_selection.json)을 읽도록 바뀌었기 때문이었다. 테스트의 대부분은 이 경로를 모킹(mocking)하고 있었지만, 모킹하지 않은 오래된 테스트가 십여 개 있었고, 이것들이 개발 중인 세션 자체가 실시간으로 쓰고 있는 진짜 state를 읽어버린 것이다. 테스트의 성패가 "그때 hook이 무엇을 추천했는가"에 따라 달라지는, 재현성 없는 플래키(flaky) 테스트였다. 결국 "해당 state에 닿을 가능성이 있는 테스트를 grep으로 기계적으로 전수 조사하여 격리하기"까지 두 번의 시행착오를 겪었다 (첫 번째 감사에서 5개를 수정했고, 리뷰에서 "동일한 패턴이 7개 더 남아 있다"는 지적을 받았다). 실제 운영 파일을 읽는 분기를 추가할 때는, 해당 파일에 접촉하는 테스트의 전수 조사를 세트로 진행해야 한다.

업무 및 개인 개발에 활용할 수 있는 점

1. 최적화는 「적용」하고 나서야 비로소 다음 문제가 보인다

추천을 표시하던 몇 주 동안, 데드락(deadlock)의 싹은 계속 그곳에 있었다. 아무도 따르지 않았기에 발화하지 않았을 뿐이다. dry-run과 실제 적용 사이에는 질적인 단절이 존재한다. 측정한다 → 적용한다 → 다시 측정한다. 적용 후의 관측까지가 하나의 세트이며, 거기서 발생한 문제는 실패가 아니라, 적용하지 않았다면 얻을 수 없었을 정보이다.

2. 실패 시그널은 「관측 가능한 객관적 사실」로 정의한다

"리뷰에서 지적되었다"를 실패로 계산하면, 모델 능력·태스크 난이도·리뷰어의 엄격함이 뒤섞인 탁한 시그널이 된다. 테스트 합격 여부·자력 완주와 같이 기계적으로 관측할 수 있는 사실만을 계산한다. 이러한 정리의 근간이 된 "developer의 업무는 동작하는 구현이지, 리뷰어에게 지적받지 않는 구현이 아니다"라는 직무 정의로부터의 역산은, 인사 평가나 팀의 KPI 설계에도 그대로 통용될 것 같다.

3. 기록과 해석을 분리한다 ── 규칙을 바꿔도 소급하여 다시 계산할 수 있는 구조로

집계값(α/β)을 매번 업데이트하는 구조는 집계 규칙이 안정된 후에 선택하는 것이다. 규칙을 탐색하고 있는 단계에서는, 생 이벤트(raw event)를 불가역적으로 쌓아두고, 해석은 읽기 시점에 도출한다. 규칙 변경이 과거 로그에 소급 적용되므로, 시행착오의 비용이 차원이 달라진다. 이벤트 소싱(event sourcing)의 교과서적인 장점이지만, "학습 데이터를 몇 번이고 리셋해야 했던 고통"을 거치고 나면 진심으로 납득하게 된다.

4. 안전망은 전제가 바뀌면 흉기가 된다

escalation은 "추천이 무시될 수 있는" 세계에서는 올바른 안전망이었다. 추천이 구속력을 갖는 순간, 탐색을 죽이는 장치로 변했다. 부품의 선악은 그것 단독으로는 결정되지 않는다. 전제(여기서는 "추천의 구속력")를 바꾸는 변경을 도입할 때는, 기존의 안전망·가드(guard)·폴백(fallback)이 새로운 전제에서도 안전한 방향으로 작동하는지 한 차례 재검토할 가치가 있다.

5. AI에게 「솔직한 의견」을 묻는 것은 리뷰와는 별개의 탐지 채널이다

이번 데드락은 리뷰에서도 감사에서도 나타나지 않았다. 나타난 것은 "솔직히 어떻게 생각해? 좋은 부분도 나쁜 부분도"라는 잡담으로부터였다. 리뷰는 차이(diff)를 보지만, 평가를 요구받은 AI는 시스템 전체의 구조를 본다. 정기적으로 "본심 섞인 감상"을 묻는 것은 포멀한 리뷰를 보완하는 저렴한 탐지 채널로서 추천한다. 다만, 본심을 말할 수 있는 관계(말한 내용으로 꾸중 듣지 않은 실적)가 먼저 선행되어야 할 것 같다.

요약

같은 날의 3가지 릴리스는 다음과 같이 연결되어 있었습니다.

v2.41.0: 기록된 학습 데이터가 "권장된 tier"와 "실제로 사용된 tier"가 일치하지 않음 (귀속 불일치). 기록을 기계적인 자기 해결 방식으로 변경하고, 승인 게이트(approval gate) 단위 및 역할별 기록으로 재설계.

v2.42.0: 권장 사항을 Agent 기동 시의 model: 명시 지정으로 실제로 적용하는 소프트 적용(soft application). 귀속 불일치가 재발하지 않는 기록 경로와, 리뷰 지적 시의 tester 귀속 문제도 함께 해결.

그날 오후: "솔직한 의견을 들려줘" → escalation(에스컬레이션) × 적용 과정에서 **저렴한 모델이 다시는 선택되지 않는 데드락(deadlock)**이 진행 중임을 발견 (sonnet 실패율 0.57로 동결).

v2.43.0: 실패의 정의를 객관적 현상(테스트 합격 여부·스택)으로 한정하고, 실패율을 시간 창(time window)으로 설정하며, bandit(밴딧)을 이벤트 로그로부터 도출하는 방식으로 변경. 구현된 워크플로우 내에서 sonnet의 패자부활과 haiku의 첫 성과를 실시간으로 관측. 테스트 1646 passed / 리뷰 지적 0건.

권장 사항을 표시하기만 하는 도구였다면, 이 글에 쓴 일들은 전부 일어나지도 않았을 것이고 알아차리지도 못했을 것입니다. 적용하기 때문에, 망가집니다. 망가지기 때문에, 고칠 수 있습니다. 학습 계통은 아직 6/30 시행의 수집기입니다. 30일에 도달할 무렵, Thompson Sampling(톰슨 샘플링)이 무엇을 말하기 시작할지 다시 쓰겠습니다.

C3를 써보고 싶다면 ── 시작하기

pip install claude-code-conductor # C++ 컴파일러 불필요
cd your-project
c3 init # .claude/ 디렉토리에 에이전트 정의·skill·hook이 전개됨

그 후 Claude Code에서 /start를 입력하세요.

v2.43.0의 tier-routing은 권장 사항의 적용, 객관적 시그널을 통한 학습, c3 tier stats를 통한 시각화까지 모두 포함되어 있습니다 (학습 데이터는 귀하의 프로젝트 워크플로우에서 쌓입니다). 어댑터는 Claude / Codex / Cursor / OpenCode 4가지를 지원합니다 (c3 init --platform ...). "여기서 막혔다", "이 부분이 이상하다" ── 막힌 지점에 대한 보고가 가장 큰 도움이 됩니다. Issue나 PR로 언제든 편하게 말씀해 주세요.

링크

C3 GitHub: https://github.com/satoh-y-0323/claude-code-conductor

C3 PyPI: https://pypi.org/project/claude-code-conductor/

C3 공식 문서: https://satoh-y-0323.github.io/claude-code-conductor/

v2.41.0 릴리스 노트: https://github.com/satoh-y-0323/claude-code-conductor/releases/tag/v2.41.0

v2.42.0 릴리스 노트: https://github.com/satoh-y-0323/claude-code-conductor/releases/tag/v2.42.0

v2.43.0 릴리스 노트: https://github.com/satoh-y-0323/claude-code-conductor/releases/tag/v2.43.0

이전 기사 (『이번에는 AI가 "적당히 합시다"라고 말했다』/ C3 v2.40.0): https://zenn.dev/satoh_y_0323/articles/654fe827665393

Discussion