Claude Code의 효과는 '사용법'이 아니라 '체제'로 결정된다 ― 6개 프로젝트의 실데이터 분석

우선 결론부터 (TL;DR)

사내 과제 관리 도구(Backlog)의 로그를 사용하여, Claude Code 도입 전후로 '1인당 과제 완료 수'가 어떻게 변했는지를 몇몇 프로젝트에서 비교해 보았습니다.

그랬더니 꽤 확연한 차이가 나타나더군요.

같은 도구를 도입해도, 성장하는 팀과 성장하지 않는 팀이 뚜렷하게 나뉘었습니다.

그 차이를 가장 잘 설명할 수 있는 것은 도구도 개인의 기술도 아닌 '체제(Structure)' —— 구체적으로는 '코어 멤버가 고정되어 있는가(지속성)'와 '요건부터 구현까지 동일한 사람이 일관되게 담당하는가(End-to-End)'라는 두 가지였습니다.

대략적으로 요약하면,

고정된 소수의 내제(In-house) 팀은,
1인당 완료 수가 2.4~2.5배로 증가 🚀
멤버 교체가 많거나 대규모 팀은,
거의 보합세 ~ 오히려 미세 감소
'팀의 지속률'과 '효율의 성장' 사이에는,
상관계수 r = 0.79라는 꽤 강한 상관관계가 있음
나아가 '
기표(Issue Creation) = 구현의 일치율(일관성)'을 보면, 성장한 팀은 91~100%, 보합세 팀은 약 50%. '같은 사람이 있다'는 것만으로는 부족하며, 상류 단계부터 구현까지 장악하고 있는가가 핵심이었다

요컨대, Claude Code의 효과는 '도입했느냐'보다 '어떤 체제로 사용하느냐'에 따라 상당히 달라진다는 이야기입니다.

왜 조사하려고 했는가

"AI로 개발이 엄청 빨라졌다!"와 같은 체감되는 목소리는 자주 듣지만, 팀 단위로 얼마나, 왜 효과가 있는지에 대해서는 의외로 언어화되지 않았다고 느꼈습니다.

그리고 또 하나. 최근 세상에서는 이런 식으로 이야기되곤 하죠.

"AI를 사용하면 생산성은 몇 배로 늘어난다"

"앞으로는 전문 지식이 없어도 누구나 개발할 수 있게 된다"

"성과가 나오지 않는 것은 아직 제대로 활용하지 못하고 있기 때문이다"

기대가 큰 것은 좋은 일이라고 생각합니다. 하지만 현장에서 매일 Claude Code를 본격적으로 사용하고 있는 측의 실감으로는, "음, 조금 다른 것 같은데?"라는 답답함이 있었습니다. 효과가 나는 사람과 나지 않는 사람의 차이는 '사용법'보다 훨씬 더 구조적인 곳에 있는 것이 아닐까 하고 말이죠.

이 답답함을 체감이 아닌 숫자로 확인하고 싶었습니다. 마침 수중에 있는 과제 관리 도구에 완료된 과제의 로그가 쌓여 있었기에, "그럼 한번 볼까" 하고 시작한 것이 이 글의 계기입니다.

어떻게 측정했는가

대략 다음과 같습니다 (구체적인 API나 집계 코드는 이 글의 말미에 '부록: 재현을 위한 측정 절차'로 정리해 두었습니다).

데이터 소스: Backlog의 과제 (API로 취득)
대상: 완료 과제가 많은 '개발계' 프로젝트 6개 (운영·서포트계는 성격이 다르므로 제외)
'완료'의 정의: 상태(Status) = '완료'이며, 해당 갱신 월을 완료 월로 간주

(Backlog API에는 '완료일' 기준 필터링이 없으므로, 이는 근사치입니다)

도입 전후의 구분: 회사 차원에서 Claude Code를 본격적으로 도입한 2025년 12월 말을 기점으로
- 도입 전: 2025년 7월 ~ 12월 (6개월)
- 도입 후: 2026년 1월 ~ 6월 (6개월, 6월은 중간까지)
효율 지표: 완료 수 ÷ 총 투입 맨먼스 (Man-Month)

(= 1맨먼스당 완료 수)

인원수나 가동 월수의 차이를 보정할 수 있으므로, 단순 건수보다 공정합니다.

지속률: "도입 전에 활동하던 멤버 중 도입 후에도 남은 비율"

결과 1: 성장한 팀 · 성장하지 않은 팀

프로젝트 이름은 숨기고 성격만 기재합니다 (A~F).

프로젝트	체제의 성격	완료 수 (전→후)	1맨먼스당 (전→후)	효율 배율	코어 지속률
A	내제·고정 소수(2명)	61→155	5.1 → 12.9	×2.54	100%
B	내제·고정 소수(2→3명)	86→236	10.8 → 26.2	×2.44	100%
C	안정·중규모(5명)	225→283	11.2 → 14.9	×1.32	80%
D	교체 많음(6명)	145→144	6.9 → 7.6	×1.10	50%
E	대규모·유동적(13명)	228→196	5.1 → 4.8	×0.94	85%
F	교체 많음(9명)	306→207	9.6 → 8.6	×0.90	56%

보시는 바와 같이, 고정된 소규모 내부 팀(A·B)만이 독보적으로 성장했습니다. 게다가 인원을 늘리지 않고도 1인당 효율이 2배 이상 증가했습니다. 이 점이 핵심입니다.

결과 2: 「팀의 고정도」와 「효율의 성장」은 상관관계가 있었다 (r = 0.79)

가로축에는 코어 멤버의 지속률을, 세로축에는 효율 배율을 둔 산점도는 다음과 같습니다.

우측 상단(지속률 100%)의 A·B가 압도적임 (빨간색 = 고정된 소규모 내부 팀)
지속률이 낮아질수록 효율 배율도 낮아지는, 비교적 깔끔한 정의 상관관계 (r=0.79)
단, E만 이상치(Outlier): 지속률은 높음(85%)에도 불구하고 효율은 정체

이 E라는 이상치가 사실 이번 분석에서 가장 흥미로운 포인트였습니다. "지속률이 높다 = 동일한 인원이 남아 있다"에도 불구하고 왜 성장이 없을까요? 이는 후반부(결과 4)에서 또 다른 축을 도입하면 명쾌하게 설명할 수 있습니다. 우선 다음으로 넘어가겠습니다.

결과 3: 효과는 「도입의 경계선」에서 나타나는가?

"그건 그냥 우연히 우상향한 것 아니냐?"라는 반론을 방지하기 위해, 성장한 2개 팀(A·B)의 월별 추이를 살펴보겠습니다. 빨간색 점선이 도입 시점(2025년 12월 말)입니다.

B: 도입 전에는 1인당 ≒ 12 수준에서 정체 → 2026년 1월부터 갑자기 계단식 상승, 4월에 정점
A: 도입 전에는 1인당 ≒ 5 수준에서 안정적 → 2월 이후 수준이 급격히 상승하여 그대로 높은 수준 유지

단순한 우상향이 아니라, 경계선을 넘어서는 순간 「수준 자체가 한 단계 올라가는」 step-change가 나타난다는 점이 포인트입니다. 특히 B가 도입 직후인 1월부터 급증한 것은 계절적 요인만으로는 설명하기 어려운 움직임입니다.

결과 4: 「같은 사람이 있다」는 것만으로는 부족하다 ― "체제"를 2개 축으로 분해하기

여기까지 오면 한 가지 의문이 생깁니다. **산점도에서 이상치였던 E는 지속률이 85%로 높음에도 효율은 정체(×0.94)**되어 있습니다. "같은 사람이 남아 있는데 왜 그럴까?"라는 의문이죠.

여기에 축을 하나 더 추가해 보겠습니다. 바로 「과제를 생성한 사람 = 구현한 사람」의 일치율입니다. 이를 「요구사항·설계부터 구현까지 동일한 인원이 일관되게(End-to-End) 담당하는가」를 나타내는 대리 지표로 활용합니다 (완벽한 지표는 아니지만, 워크플로우가 분업화되어 끊겨 있는지 판단하는 기준이 됩니다).

프로젝트	일관성 (생성=담당)	지속률	효율 배율
B	100%	100%	×2.44
A	91%	100%	×2.54
D	93%	50%	×1.10
C	85%	80%	×1.32
E	53%	85%	×0.94
F	48%	56%	×0.90

흥미로운 점은 **E는 일관성이 53%, F는 48%**라는 것입니다. 즉, 약 절반 정도가 「누군가가 요구사항을 생성 → 다른 사람이 구현」하는 분업 구조였다는 뜻입니다. 반면, 성장한 A·B는 91~100%로, 한 사람이 요구사항부터 구현까지 모두 담당하고 있습니다.

이 두 축(지속성 × 일관성)으로 매핑하면 다음과 같습니다.

효율이 크게 성장하는 것(초록색·큰 원)은 우측 상단의 A·B뿐임 = 「지속성 × 일관성」을 모두 확보
D: 일관성은 높지만 지속률이 낮음 → 지식이 리셋되어 정체
E: 지속률은 높지만, 분업으로 인해 워크플로우가 단절됨 → 정체

즉, 「지속성(축적된 지식)」과 「일관된 담당 범위(워크플로우의 비단절)」는 서로 다른 축이며, 두 가지가 모두 갖춰져야 비로소 효과가 나타납니다. "같은 사람이 있다"는 것만으로는 부족했던 것입니다. 이것이 E가 이상치였던 이유를 잘 설명해 줍니다.

왜 「워크플로우 단절」이 Claude Code에서 특히 치명적인가

이 부분은 Plan 모드(사양 주도 방식)를 떠올리면 이해가 쉽습니다.

Plan 모드의 가치는 "의도 ↔ 사양 ↔ 구현"을 하나의 루프로 돌릴 수 있다는 점에 있습니다. 요구사항을 다른 사람이 확정해서 넘겨주는 분업 구조라면, 사양이 "동결된 상태"로 전달되기 때문에 AI와 함께 사양을 다시 다듬는 왕복 과정을 거칠 수 없습니다. 구현자는 타인의 결정을 그대로 따라가기만 하는 경향이 생깁니다.
"왜 해당 요구사항이 필요한가"에 대한 암묵지(Tacit Knowledge)가 상류 단계에 남겨지게 됩니다. 구현자의 손에 있지 않기 때문에 프롬프트의 해상도를 높일 수 없습니다.
의문이 생겼을 때의 해결 속도 차이입니다. 일관된 담당자라면 즉시 스스로 해결(AI에게 물어보고 결정)할 수 있습니다. 하지만 분업 구조라면 상류 단계와 소통하기 위해 왕복해야 하며, 이 과정에서 고속 루프가 끊기게 됩니다.
상류 단계까지 담당하는 사람은 → AI에게 전달할 문맥(Context)의 질이 한 단계 높아집니다. CLAUDE.md에 "사양의 의도"까지 작성할 수 있기 때문입니다.

역으로 말하면, "구현만 따로 떼어내어 외부로 보내는" 체제라면 Claude Code의 가장 맛있는 부분(사양부터 일괄적으로 처리하는 것)을 제대로 활용하지 못하고 있을 가능성이 높다는 뜻입니다.

왜 "체제"에 따라 이토록 차이가 나는가

앞서 언급한 "플로우 단절"은 ②일괄 처리 (End-to-End) 축에 관한 이야기였습니다. 여기서는 또 다른 축인 ①지속성 (축적된 지식) 을 포함하여, 효과가 발생하는 메커니즘을 정리합니다.

기저에 깔린 생각은 간단합니다. AI 코딩의 효과는 도구 단독이 아니라 "사용자의 문맥(Context)과 판단력"의 곱셈으로 결정된다는 것입니다. 이렇게 파악하면 모든 것이 명쾌하게 설명됩니다.

1. 지시의 질은 도메인 지식에 비례한다

AI의 출력 품질은 전달하는 문맥(사양, 제약 사항, "어느 파일의 어느 부분을 수정할 것인가")의 정밀도에 강하게 의존합니다. 코드베이스와 도메인을 완벽히 파악하고 있는 사람일수록 정확한 지시를 내릴 수 있으므로, 동일한 도구로부터 끌어낼 수 있는 성과가 훨씬 큽니다.

2. 리뷰의 "안목"이 재작업을 없앤다

AI는 의외로 아주 자신만만하게 틀리곤 합니다. 그 오류를 즉시 간파하고 좋은 차분(Diff)을 빠르게 수용할 수 있는 판단력이 있을수록 실질적인 처리량(Throughput)이 늘어납니다. 이 판단력이야말로 축적된 지식 그 자체입니다.

3. 문맥 자본은 "복리"로 작용한다

CLAUDE.md, 코딩 규약, 과거 의사결정의 경위…… 이러한 문맥이 같은 팀에 계속 쌓이게 되면, 인간↔AI 루프가 돌아갈수록 효율이 올라갑니다. 반대로 멤버가 교체되면 이 문맥 자본이 리셋되어 버립니다.

4. 소규모 인원은 조정 비용이 적다

사양 전달이나 리뷰를 주고받는 왕복 과정이 적을수록, AI로 절약한 시간이 그대로 생산량으로 전환됩니다. 인원이 많으면 이 과정에서 효율이 깎이기 쉽습니다.

이를 뒤집어 생각하면, 교체가 잦거나 인원이 많은 팀은 온보딩(Onboarding) 비용과 문맥 리셋 때문에 도구의 잠재력을 다 끌어내지 못하고 있다고 볼 수 있습니다.

"도입했는데 효과가 없다"는 분들을 위한 체크리스트

데이터를 역산하여 도출한, 효과를 끌어내기 위한 실무적인 포인트입니다. 해당 사항이 있다면 꼭 확인해 보세요.

코어 멤버를 고정한다: 이것이 가장 효과적입니다. 단기적으로 인원을 교체할수록 효과를 보기 어렵습니다.
구현자가 상류(요건·설계)도 장악한다: "요건은 다른 사람이, 구현만 의뢰"하는 식이라면 플로우가 끊깁니다. Plan 모드로 사양부터 일괄적으로 처리하는 것이 효과적입니다.
문맥 자본을 쌓는다: CLAUDE.md / README / ADR(의사결정 기록)을 가꾸어, AI에게 매번 전달할 수 있는 상태로 만듭니다.
소규모로 밀도 있게 운영한다: 우선 1~2명의 밀도 높은 팀에서 승리 패턴을 만든 후 확장합니다.
리뷰를 전제로 사용한다: 안목을 거치는 운영 방식을 채택합니다 (AI의 출력을 맹신하지 마세요).
익숙한 영역에서 사용한다: 지식이 전혀 없는 신규 프로젝트보다, 잘 알고 있는 코드베이스에서 초반 속도를 내기 쉽습니다.
지시의 해상도를 높인다: "어디를·왜·어떻게"를 구체적으로. 모호한 지시는 모호한 출력을 낳습니다.

"도구를 배포하는 것으로 끝"낸다면, E 사례처럼 정체(Plateau) 상태로 끝나기 쉽습니다. 효과는 상당히 체제와 운영에 달려 있습니다.

한계 및 기타 고려 요인 (솔직한 고백)

공개 데이터가 아니기에 해석의 한계가 있음을 명시해 둡니다. 이 점이 중요합니다.

지표는 근사치: 완료 수는 「상태 완료 × 업데이트 월」로 측정했기에, 엄밀한 완료일과는 약간의 차이가 발생할 수 있습니다. 태스크의 크기도 정규화되지 않았습니다. -
담당자 필드의 변동성 보정: 티켓 생성 시의 담당자 상태로 업데이트되지 않고, 실제 작업을 하지 않는 사람이 「담당자」로 남아 있는 경우가 있습니다 (실제로 A 팀에서 1건 발생). 확인된 부분은 작업자 카운트에서 제외했습니다. -
관측 기간이 짧음: 도입 후 6개월이며, 게다가 최근 달은 중간 집계 상태입니다 (= 배율은 오히려 보수적인 편). -
상관관계 ≠ 인과관계: r=0.79는 어디까지나 관찰된 상관관계이며, 샘플은 6개 프로젝트입니다. -
「일관성(End-to-End)」도 대리 지표: 「티켓 생성 = 담당자 일치율」로 측정하고 있지만, PM이 일괄 생성하는 운영 방식이라면 낮게 나오며, 구현자가 티켓을 생성했더라도 사양의 의도는 다른 사람에게 있는 경우도 있을 수 있습니다. 플로우의 일관성을 직접 측정하고 있는 것은 아니며, Plan 모드/사양 주도(Specification-driven) 방식을 실제로 사용하고 있는지도 측정하지 못했습니다 (어디까지나 메커니즘에 대한 추론입니다). -
「효율이 올라갔다」 이외의 설명도 가능함: 이번 수치는 Claude Code 이외의 요인으로도 변할 수 있습니다. 예를 들어——-
- Backlog 활용도가 높아졌을 뿐: 애초에 과제를 제대로 생성하고 클로즈(Close)하는 운영 방식으로 바뀌면 완료 수는 증가합니다. -
- 프로젝트 페이즈(Phase) 차이: 성장한 2개 팀은 신규 개발 가속 페이즈였으며, 원래 완료가 나오기 쉬운 시기였을 가능성 -
- 태스크 정리(Inventory): 방치되어 있던 과제들을 한꺼번에 「완료」 처리하는 것과 같은 일시적인 스파이크(Spike)가 섞여 있을 가능성 -
- 내재화 및 체제 변경: 성장한 2개 팀은 「내재화」와 「Claude 도입」이 겹쳐 있어, Claude 단독의 기여도를 완전히 분리해낼 수 없음

따라서 이것은 어디까지나 자사 환경에서의 한 사례일 뿐이며, 「Claude Code를 도입하면 반드시 2.4배가 된다」와 같은 이야기는 아닙니다. 이 점은 강조해 둡니다.

그럼에도 불구하고, 여러 팀에서 일관되게 같은 방향의 결과가 나왔다는 점, **경계 지점에서의 step-change(계단식 변화)**가 보였다는 점, 그리고 E 팀의 이상치(Outlier)가 "일관성"이라는 제2의 축으로 깔끔하게 설명되었다는 점은, 「체제(지속성 × 일관성)가 효과가 있다」는 가설을 어느 정도 뒷받침해 준다고 생각합니다.

요약

Claude Code의 효과는 「도입했는가」보다 「
어떤 체제로 사용하는가」에 따라 크게 달라진다 - 자사 데이터에서는,
고정된 소수 인원의 내재화 팀이 1인당 2.4~2.5배, 교체가 잦은/대규모 팀은 보합세 -
효과가 있는 것은 2가지 축:
① 지속성 (코어 인원이 고정되어 지식이 쌓임) × ② 일관성 (요건~구현을 동일한 사람이 담당). 두 가지가 모두 갖춰져야 비로소 성장한다 - 「같은 사람이 있다」는 것만으로는 부족하다——
E 팀은 지속률이 85%임에도, 구현이 분업화(일관성 53%)되어 있어 보합세였다 -
효과가 나타나지 않는다면, 우선
코어 인원의 고정화 · 상류부터 구현까지 담당 (Plan 모드로 사양 주도) · 문맥 자본(Context Capital)의 축적 · 소수 인원으로 밀도 있게부터 시작하라

AI 코딩은 「은탄환 (Silver Bullet)」이 아니라 「증폭기 (Amplifier)」라고 생각합니다. 증폭될 토대(쌓인 지식과 판단력)가 있는 팀일수록 효과가 폭발적으로 나타난다 ——는 것이 이번의 배움이었습니다.

마치며: AI는 "밑바닥 끌어올리기"가 아니라 "증폭기"라고 생각합니다

마지막으로, 이 글을 쓰고 싶었던 진짜 동기를 조금만 말씀드리겠습니다.

서두에서 언급한 「AI로 생산성이 몇 배로」「전문 지식이 없어도 누구나 개발할 수 있다」「안 나오는 것은 제대로 활용하지 못하고 있을 뿐이다」 —— 세상에 흔히 퍼져 있는 이 "분위기"에 대해, 현장에서의 하나의 반증을 남겨두고 싶었습니다.

사실, 성장한 A 팀은 저 자신이 관여하고 있는 팀입니다. 그 경험을 바탕으로 말씀드리면, Claude Code에 가장 효과적이었던 것은 「제품에 대한 지식」만이 아니었습니다. 요건을 어떻게 분해할 것인가, 어떻게 설계할 것인가, 어떤 순서로 프로젝트를 진행할 것인가 —— 엔지니어로서 쌓아온 "기본적인 틀(Base pattern)" 같은 것. 이것이 있으면 있을수록 AI로부터 끌어낼 수 있는 양이 차원이 다르게 늘어납니다. 반대로, 이 부분이 얇으면 같은 도구를 사용하더라도 겉돌기 쉽습니다.

그래서 저는, AI는 **「밑바닥 끌어올리기 (누구나 동일한 수준이 되는 것)」가 아니라 「증폭기 (쌓아온 사람이 더욱 성장하는 것)」**라고 생각합니다. 이번 데이터도 그 관점과 깔끔하게 일치했습니다.

여기서, 특히 "도입을 주도하는 입장"에 있는 분들에게 전달되었으면 하는 것이 두 가지 있습니다.

「효과가 없다 = 사용법이 잘못되었다」라며 개인의 탓으로 돌리기 전에, "체제"를 봐주길 바랍니다. 이번에 살펴본 바로는, 성과가 나는지 여부는 개인의 노력보다 지속성이나 일관된 흐름(End-to-End)과 같은 구조에 상당히 좌우되었습니다. 단순히 "무조건 써라"라고만 해서는, 구조가 병목(Bottleneck)인 팀은 성장할 수 없습니다.
AI의 혜택을 최대화하고 싶다면, "쌓아 올린 사람"이 계속 남아있을 수 있는 환경을 만드는 것이 툴 도입만큼이나 중요합니다. 증폭기는 증폭할 원천(축적된 지견과 판단력)이 있어야 비로소 효과를 발휘합니다. 새로운 인원을 늘리는 한편, 지견을 가진 사람들이 조용히 빠져나가는 상황을 최근 자주 듣습니다. 하지만 그것은 AI로 가장 크게 성장해야 할 "토대" 그 자체를 놓치고 있는 것일지도 모릅니다.

채용을 늘리는 것과 지견을 가진 사람이 계속 정착하는 것. 이 두 바퀴가 맞물려 돌아갈 때 비로소 AI의 효과가 최대화되는 것이 아닐까 생각합니다.

AI는 마법이 아닙니다. 하지만 지금까지 쌓아온 것들을 몇 배로 만들어 주는 아주 좋은 증폭기입니다. 그 "원천"을 소중히 여기는 팀과 회사일수록 앞으로 격차가 벌어질 것이라고 믿으며 이 글을 썼습니다.

부록: 재현을 위한 측정 절차

자신의 팀에서도 동일한 작업을 해보고 싶은 분들을 위해 절차를 남겨둡니다. Backlog API를 사용합니다.

1. 프로젝트 특정하기

curl -s "https://YOUR_SPACE.backlog.com/api/v2/projects?apiKey=$BACKLOG_API_KEY" \
| jq '.[] | {id, projectKey, name}'

2. 월별 완료 건수 세기 (건수 API)

statusId는 Backlog 표준 기준으로 "완료"가 4입니다. updatedSince / updatedUntil은 yyyy-MM-dd 형식입니다.

# 예: 특정 프로젝트의 2026년 1월 완료 건수
curl -s "https://YOUR_SPACE.backlog.com/api/v2/issues/count?apiKey=$BACKLOG_API_KEY" \
--data-urlencode "projectId[]=PROJECT_ID" \
...

이를 월별로 실행하면 월간 완료 건수(결과 1, 결과 3의 막대그래프)를 만들 수 있습니다. 건수 API는 가볍고 정확하므로, 건수만 파악할 때는 이 방법이 가장 간편합니다.

3. 담당자(인원수·공수) 집계하기

인원수는 이슈 본체를 가져와 assignee를 집계합니다. 1회 요청당 최대 100건이므로 offset으로 페이지네이션(Pagination)을 수행합니다.

curl -s "https://YOUR_SPACE.backlog.com/api/v2/issues?apiKey=$BACKLOG_API_KEY" \
--data-urlencode "projectId[]=PROJECT_ID" \
--data-urlencode "statusId[]=4" \
...

💡 이슈 객체는 댓글이나 첨부파일을 포함하면 상당히 커질 수 있습니다.

count=100 설정 시 응답 데이터가 너무 크다면 count=30~40 정도로 낮추면 안정적입니다.

4. 집계 로직 (Python 의사 코드)

import collections
# issues: 취득한 모든 이슈 (updated와 assignee.name을 가진 dict의 리스트)
before = {f"2025-{m:02d}" for m in range(7, 13)}
...

이를 각 프로젝트에서 실행하여 (지속률, 효율 배율)을 산점도(Scatter Plot)로 그리면 결과 2를 재현할 수 있습니다.

측정은 사내 이슈 관리 데이터를 익명 집계한 것입니다. 수치는 어디까지나 자사 환경에서의 한 예시이며, 타 환경에서의 재현을 보장하지 않습니다.