에이전틱 자율성 레벨(Agentic Autonomy Levels)
TMT요즘 에이전틱 엔지니어링 이야기의 중심은 프롬프트를 잘 쓰는 것에서 에이전트를 **운영(operating)**하는 것으로 옮겨갔습니다. 아직 안갯속이긴 하지만, 최전선에서는 이런 것들이 등장하고 있습니다. 소프트웨어 공장, 목표, 루프, 백그라운드 세션, 서브에이전트, 훅, 샌드박스, 그리고 에이전트를 승인하는 에이전트. 앞으로 등장할 많은 제품에는 이런 방식이 첫날부터 기본으로 들어가 있을 것입니다. Claude Code와 Codex를 보면 이 변화가 그대로 드러납니다.
엔지니어 입장에서 보면, 위험을 줄이고 쉽게 되돌릴 수 있어야 하는 일에는 낮은 자율성을 쓰고, 명확하게 정의된 작업이나 대규모 코드베이스를 여러 에이전트로 안전하게 리팩터링하는 일에는 더 높은 자율성을 쓰게 됩니다. 어떤 작업이든 핵심 질문은 늘 같습니다. 이 작업에는 어느 수준의 자율성이 적당하고, 그 수준을 믿고 쓰려면 어떤 검증이 필요한가?
가장 앞서 나간 형태는 매니저 에이전트입니다. 정해진 트리거에 깨어나 하위 에이전트들에게 일을 맡기고, 결과물을 계속 검증하면서, 사람이 결정해야 할 것만 추려서 가져옵니다. 이런 구성을 쓰는 사람들은 이미 에이전트를 수백, 수천 개씩 돌리고 있을지도 모릅니다. 대부분은 오랫동안 관리해 온 코드베이스에서요. 자율성을 둘러싼 다른 논의가 대부분 그렇듯, 이 수준을 어떻게 볼지는 아직 사람마다 다릅니다.
가장 자주 인용되는 척도는 "Welcome to Gas Town"과 The Pragmatic Engineer에 소개된 Steve Yegge의 단일 축 사다리입니다. 내가 얼마나 AI 네이티브한지 숫자 하나로 확인하고 싶을 때 참고할 만합니다. 에이전트 하나를 얼마나 신뢰하는지를 숫자 하나로 보여주거든요. 한 가지 버전을 보면 다음과 같습니다.
2026년 초, 일하는 방식이 위임에서 오케스트레이션으로 넘어가기 시작하던 무렵에도 이 사다리는 위험을 가늠하는 데 꽤 쓸 만한 기준이었습니다. 하지만 지금은 여러 에이전트를 동시에 돌릴 수 있게 되면서 훨씬 중요해지고 영향력도 커진 역량이 많습니다. 사다리 한 칸으로는 멀티 에이전트 역량이 어느 정도인지 나타낼 수 없습니다.
그런데 제가 본 자율성 논쟁은 거의 다, 따로 놓고 봐야 할 두 가지 질문을 섞어 버립니다. 에이전트 하나가 내 손을 떠나 얼마나 멀리까지 가도록 둘 것인가, 그리고 여러 에이전트를 조율하는 우리 실력은 어느 정도인가?
이 두 가지를 따로 보기 위해 두 개의 축을 쓰겠습니다. **에이전시(agency)와 오케스트레이션(orchestration)**입니다.
에이전시 축에서 낮음(low)은 에이전트가 해볼 만한 액션을 제안하고 사람의 결정을 기다리는 수준입니다.
중간(mid)은 에이전트가 특정 작업을 맡아 진행하되, 정해진 범위를 지키고, 무엇을 했는지 근거와 함께 수시로 보고해서 사람이 계속 방향을 잡아줄 수 있는 수준입니다.
높은 에이전시 쪽 끝에서는 에이전트가 목표를 향해 움직입니다. 실험하고, 배우고, 테스트하고, 문제를 풀 방법을 찾고, 막히면 질문하고, 다른 방법을 시도하면서, 이 모든 과정을 **근거(evidence)**로 남겨 돌려줍니다.
오케스트레이션 축에서 낮음은 에이전트 하나에 스레드 하나입니다. 중간이 되면 에이전트 여러 개가 각자 자기 워크트리에서, 어쩌면 서로 다른 목표를 향해, 서로 격리된 채 일합니다. 높은 쪽 끝에는 백로그, 이슈 트래커, 일정 같은 큐를 받아 쉬지 않고 일로 바꿔내는 오케스트레이터가 있고, 사람은 뭔가 실패했을 때만 나서면 됩니다. 이른바 "예외에 의한 관리(management by exception)"입니다. 이런 아이디어를 담은 제품과 기능으로는 다음과 같은 것들이 있습니다.
- Claude Code의
/plan,/goal,/loop,/background,/batch,/code-review,/security-review모드, 서브에이전트, 훅, 체크포인트, 에이전트 위임과 관리 방식, 백그라운드 세션, 에이전트 팀 패턴,/schedule인자 - Codex의 로컬/클라우드 스레드, Goal 모드, 워크트리, Automations, 서브에이전트, 리뷰 창, GitHub 코드 리뷰, 훅, 샌드박스, Auto-review, 재실행(rerun)
이런 기능들은 사다리 하나로는 다 담아낼 수 없습니다.
오르는 길: 세 개의 시대, 하나의 사다리
사다리를 아래에서 위로 읽는다는 것은 에이전시와 오케스트레이션을 동시에 올라가는 그림을 그리는 셈입니다. 실제로 여섯 개의 레벨은 우리 모두가 거쳐 가는 세 개의 시대로 나눌 수 있습니다.
첫 번째 시대에는 운전대를 사람이 잡고 있고, 에이전트는 옆에서 지시를 기다리며 거드는 정도입니다.
두 번째 시대에는 범위가 정해진 작업이나 목표를 에이전트가 맡아 진행하지만, 사람이 여전히 옆에서 방향을 잡아주고 결과를 검증합니다.
세 번째, 오케스트레이션의 시대가 되면 시스템이 알아서 전체를 운영합니다. 여러 에이전트에 일을 나눠주고, 사람은 대체로 뭔가 잘못됐을 때만 개입합니다. "예외에 의한 관리"입니다.
이렇게 보면 이야기가 단순해집니다. 사다리에서 얼마나 높이 있느냐가 두 축을 한꺼번에 설명해 주고(오케스트레이션은 꼭대기 근처에서야 등장하니까요), 결국 한 칸씩 밟아 올라가는 하나의 여정이 되기 때문입니다. 그리고 이 오르막은 우리 모두가 겪고 있는 변화의 일부이기도 합니다.
일이 잘 풀리는 날에는 하루에도 여러 칸을 오르내리게 됩니다. 작업 하나를 하는 동안 시대 사이를 몇 번씩 왔다 갔다 하는 것도 자연스러운 일입니다.
여섯 레벨 자세히 보기
레벨 0: 보조(Assist)
에이전트가 제안을 내놓습니다. 대체로 괜찮고 가끔은 완벽하기도 하지만, 그걸 실제로 반영할지는 언제나 사람이 결정합니다. 자동완성이나 인라인 편집 제안, 혹은 아직 누구도 맡겠다고 하지 않은 변경을 두고 채팅으로 이야기만 나누는 상황을 떠올리면 됩니다. 실수하면 대가가 큰 일, 아주 작은 변경, 아직 어떻게 할지 판단이 서지 않은 일에 적합합니다. 검증은 대부분 로컬에서 이뤄집니다.
레벨 1: 감독 아래 실행(Supervised action)
에이전트가 사람 대신 파일을 고치거나 명령을 실행하되, 영향이 큰 일은 실행 전에 물어봅니다. 대부분의 사람이 기본으로 쓰는 방식입니다. 변경을 적용하기 전에 승인을 받는 로컬 샌드박스에서 할 수도 있고(이때는 승인 하나하나가 "이 변경은 적용해도 괜찮다"는 독립적인 검증이 됩니다), 대화형 세션에서 할 수도 있습니다. 여기서 빠지기 쉬운 함정은 승인 피로입니다. 뭘 승인하는지와 상관없이 모든 승인이 다 비슷해 보이기 시작하는 거죠. diff를 꼼꼼히 들여다보거나, 나름의 기준을 세우거나, 승인 전에 다른 사람에게 물어보거나, 아니면 아예 에이전트에게 책임을 맡기기로 하는 식으로 대응할 수 있습니다. Codex의 Auto-review는 애매한 경계에 걸린 최종 승인을 별도의 리뷰어 에이전트에게 맡기는 방식으로 이 문제를 풉니다.
레벨 2: 범위를 정한 작업 위임(Scoped task delegation)
범위가 분명한 작업 하나를 에이전트에게 통째로 맡깁니다. 이런 작업에는 명확한 목표와 제약 조건, 그리고 어떤 상태면 끝난 것인지에 대한 기준이 있습니다. 사람은 근처에 있으면서 언제든 끼어들 수 있지만, 대부분은 관여하지 않습니다. 지금 소프트웨어 엔지니어링의 무게중심이 바로 여기에 있습니다. 검증은 점점 사람 손을 떠나(사람도 쉬고 자야 하니까요) 에이전트가 만들어낼 수 있는 근거 쪽으로 옮겨가고 있습니다. 통과한 자동화 테스트, 제대로 붙은 타입, 린트 결과, 스크린샷, 재현 절차, 예시로 남긴 작업 근거 같은 것들입니다.
레벨 3: 목표 주도 자율성(Goal-driven autonomy)
에이전트가 목표를 이루기 위해 필요한 일을 알아서 하고, 정해진 조건이 충족될 때만 멈춥니다. 프롬프트 모드에서는 프롬프트 자체가 목표가 됩니다(예: "이 페이지의 time-to-interactive를 1초 아래로 줄여줘"). Codex에서는 Goal 모드가 여기에 해당합니다. 에이전트가 성공 기준을 만족할 때까지 계획→실행→테스트→리뷰를 반복합니다. Claude Code에서는 /goal, /loop, /schedule 명령이 그 역할을 합니다. 이 레벨이 제대로 쓸모 있으려면 멈추는 조건을 자동으로 측정할 수 있어야 합니다.
"전반적인 사용자 경험 개선"이나 "코드베이스를 더 테스트하기 좋게" 같은 두루뭉술한 목표를 에이전트에게 맡기지 마세요. 구체적이고, 측정할 수 있고, 자동으로 확인할 수 있는 목표를 고르세요. 정적 분석으로는 안 잡히는 프로덕션 버그 찾기, 로딩 시간 줄이기, 명시적 any가 하나도 없는 엄격한 TypeScript 빌드 만들기, 우리가 이해하고 있고 테스트를 통과하는 것만 남기도록 의존성 정리하기 같은 것들입니다. 그리고 한 가지 더, 프로덕션 버그를 찾게 하려면 에이전트도 프로덕션과 비슷한 환경에 있어야 합니다.
레벨 4: 병렬 위임(Parallel delegation)
여러 에이전트에게 일을 나눠 병렬로 진행합니다. 에이전트마다 서로 겹치지 않는 조각 하나씩을 맡습니다. 이 레벨에서 가장 큰 병목은 일을 쪼개는 것, 즉 맡기기 좋은 단위를 정하는 일입니다. 서브에이전트, 백그라운드 세션, /batch, 워크트리, 에이전트 팀 같은 기능이 이를 뒷받침합니다. 여기서 빠지기 쉬운 함정은 무늬만 병렬인 상황입니다. 서로 겹치는 영역에 에이전트 여러 개를 한꺼번에 붙이면, 일이 더 되는 게 아니라 머지 충돌과 중복된 결정만 쌓입니다. 잘하려면 에이전트끼리 격리해서 각자 자기 파일과 상태를 갖게 해야 하고, 리뷰 큐도 각자 따로 두어야 합니다. 마지막으로, 에이전트가 동시에 많이 돌수록 토큰 비용도 그만큼 늘어납니다. 사람 쪽에서도 조율하는 데 품이 들기 때문에, 에이전트가 몇 개를 넘어가면 하나 더 늘리는 비용이 점점 커집니다.
레벨 5: 예외에만 개입하는 오케스트레이션(Managed-by-exception orchestration)
성공이 어떤 모습인지, 어떤 정책을 적용할지를 정의해 둡니다. 그러면 매니저 에이전트가 트리거(새 이슈, 새 작업, 정해진 시각 등)에 따라 깨어나서 작업 에이전트들에게 일을 나눠주고, 진행 상황을 지켜보고, 결과물을 검증하고, 실패하면 재시도하고, 조건에 해당하면 더 뛰어난 에이전트나 사람에게 넘기고, 결과를 모아서, 최종 산출물(예: PR)과 근거를 외부 시스템에 전달합니다. 공장이라고 생각하면 됩니다. 이슈 트래커나 백로그가 입력이고, 처리된 이슈와 버그 수정이 출력입니다. 에이전트들은 겹겹이 격리된 환경에서(필요하면 빠져나갈 통로도 두고) 일하고, 이 공장이 무엇을 해야 하는지는 매니저 에이전트가 정의한 운영 체계가 정합니다.
이 운영 체계를 설계하는 것은 사람의 몫입니다. OpenAI는 Linear 보드를 중심에 둔 Symphony 스펙을 제안했습니다. 이슈마다 전용 에이전트 워크스페이스가 만들어지고, 에이전트는 자기 워크스페이스의 스펙 파일에 정의된 목표를 향해 잘 가고 있는지 스스로 계속 확인합니다. 사람의 리뷰는 근거가 만들어지는 지점에서 하면 되지만, 오케스트레이션 세계에서 정말 강력한 것은 수백, 수천 개의 에이전트가 쉬지 않고 돌아가는 에이전트 공장을 만드는 일입니다. 이쯤 오면 독립적인 검증이 점점 중요해집니다. 구현하는 쪽과 리뷰하는 쪽을 나누고, 테스트 실행과 QA를 나누고, 보안 점검을 따로 두고, 인수 여부를 판단하는 게이트도 따로 두는 것입니다.
위험도와 되돌릴 수 있는 정도가 상한선을 정한다
예전에 읽은 Anthropic 연구가 기억납니다. Claude Code로 아주 어려운 작업을 시켰을 때, 에이전트가 설명을 요청한 횟수가 사용자가 중단시킨 횟수보다 두 배 이상 많았다는 내용이었습니다. 숙련된 사용자(세션 50개 미만인 사용자와 비교한 약 750세션 사용자)는 자동 승인을 더 많이 쓰면서도, 진행 상황을 지켜보다가 중단시키는 일 역시 더 많았습니다.
Anthropic은 사람들이 Claude Code를 어떻게 쓰는지도 폭넓게 분석했습니다. 2025년 10월부터 2026년 4월까지 약 23만 5천 명이 만든 세션 40만 개를 살펴봤는데, 세션마다 프롬프트 하나에 몇 개의 액션을 요청하는지, 그중 무엇을 자동 승인하는지, 얼마나 자주 중단시키는지 같은 것을 알 수 있었습니다. 계획 단계의 결정은 약 70%를 사람이 내리지만, 실행은 약 80%를 Claude가 합니다. 높은 자율성이란 사람을 과정에서 빼버리는 게 아니라, 사람의 역할을 모든 단계를 직접 하는 것에서 다음 방향을 정하는 것으로 옮기는 일입니다.
대규모 AI 시스템이 정말 높은 자율성으로 돌아가고 있는지 판단하려면, 이 세 가지를 물어야 합니다.
- 이 시스템이 하는 일에 대해 우리가 잘못 알고 있다면, 얼마나 빨리 알아챌 수 있는가?
- 이 시스템이 하는 일을 얼마나 깔끔하게 되돌릴 수 있는가?
- 이 시스템이 하는 일에 대해 우리가 제대로 알고 있다는 것을 무엇으로 증명할 수 있는가?
세 질문의 답이 "금방은 모른다", "되돌리기 아주 어렵다", "요약을 믿는 수밖에 없다"라면, 그건 높은 자율성이 아닙니다.
에이전트를 돌리기 전에는 항상, 무엇을 하려는 것인지 정의하는 계약이 먼저 있어야 합니다.
목표: 이루려는 것. 활동이나 기법이 아니라 결과여야 합니다.
범위: 어떤 영역에서 일하는지, 어떤 방법까지 허용되는지.
목표가 아닌 것: 이번 목표에 포함되지 않는 것.
도구와 권한: 에이전트가 바깥 세계와 어떻게 상호작용할 수 있는지. 멈춤 조건: 언제 멈출지. 측정 가능한 값이면 가장 좋습니다.
근거: 작업이 완료됐음을 에이전트와 무관하게 확인할 수 있는 구체적인 테스트, 스크린샷, 로그, 데이터베이스 기록 같은 지표.
에스컬레이션: 어떤 상황에서 누가 개입하는지(에이전트를 누가 운영하는지 포함).
그리고 예산: 이 작업에 시간과 노력과 토큰을 얼마나 쓸지에 대한 한도. 토큰은 대형 AI 모델의 예산입니다. 시도 횟수 제한이나 병렬로 돌릴 개수 제한을 함께 둘 수도 있습니다.
지표가 있으면 자율성이 조금 더 믿을 만해진다
지표를 일이 끝난 뒤에 정하는 것으로는 부족합니다. 지표는 간단한 문서로 미리 정해둘 수 있습니다. 그러면 자율성이 더 믿을 만해지고, 일을 맡겨보자는 결심도 조금은 쉬워집니다.
성공을 재는 방법은 여러 가지지만, 자율성 레벨마다 다음과 같은 지표를 어떤 형태로든 추적해 보길 권합니다.
- 사람이 개입하는 간격의 평균 시간
- 사람 개입 없이 가장 오래 성공한 실행 기록(결과물이 승인된 경우)
- 샌드박스 안에서 처리된 액션과 에스컬레이션된 액션의 비율
- 자동 승인된 액션과 거부된 액션의 비율
- 사람의 지시 하나당 에이전트가 수행한 액션의 평균 개수
- 설명 요청 비율, 중단 비율
- 반영된 변경 하나당 리뷰 시간
- 신뢰 수준별 재작업 비율
- 신뢰 수준별 결함 유출률
- 반영된 변경 하나당 토큰 비용
이런 지표를 보면 상황이 읽힙니다. 사람이 일감을 계속 넘겨줘야만 바쁘게 도는 에이전트 하나는, 대시보드만 달아 놓은 레벨 4일 뿐입니다. 반대로 작업 자동 접수와 재시도, 충분한 근거가 갖춰지기 전에는 움직이지 않는 신중한 에이전트는 제대로 된 게이트를 갖춘 레벨 5입니다.
준비가 됐는지 따져보기
일을 위험도와 되돌리기 쉬운 정도에 따라 분류하세요. 자율성은 보수적으로 시작하고, 더 높은 레벨을 감당할 수 있다는 근거가 쌓일 때만 올리세요. 탄탄한 테스트, 리뷰어 에이전트, 깔끔한 롤백 경로를 갖춘 결제 엔진 리팩터링이, 참고할 정답이 아예 없는 문서 자동화 작업보다 오히려 훨씬 높은 자율성을 감당할 수 있습니다. 자율성 레벨은 작업의 이름이 아니라 검증 체계를 보고 정해야 합니다.
네 가지 안티패턴
조심하지 않으면 어떤 시스템이든 다음 네 가지 자율성 안티패턴에 쉽게 빠집니다.
과시용 자율성 - 에이전트의 자율성 등급이 실력을 과시하는 배지처럼 쓰입니다. 높은 자율성이 안전하다는 증거가 아니라 능력의 증거로 여겨지고, 검증이 감당할 수 있는 수준 이상으로 에이전트를 돌리게 됩니다. 해결책: 자기 상황에 맞는 자율성 수준을 지키고 무리하게 올리지 않는 사람을 인정하고 보상하세요.
권한 세탁 - 승인 피로에 지친 나머지 AI 에이전트와 도구에 필요 이상으로 훨씬 넓은 권한을 내주게 됩니다. 해결책: 답은 언제나 더 나은 경계 설정입니다. 샌드박스 프로필, 쓰기 가능 경로 제한, 명령어 허용 목록, 훅, Auto-review 같은 것들입니다.
요약으로 리뷰 때우기 - 요약만 봐도 충분하겠지 하며, 에이전트가 쓴 작업 요약이 리뷰를 대신하게 됩니다. 해결책: 직접 리뷰할 때와 똑같은 근거 자료(diff, 테스트, 로그, 스크린샷, 리뷰어 의견, 위험 요소, 미비한 부분 등)를 함께 받고, 판단을 통째로 맡겨버리지 않도록 하세요.
무늬만 함대(fleet cosplay) - 에이전트 수십 개가 병렬로 돌아가지만, 의존 관계 조율은 전부 사람이 손으로 합니다. 해결책: 상태 공유, 소유권 규칙, 의존성 추적을 개선하면 손으로 조율할 일이 서서히 줄어듭니다. 동시 진행 작업(WIP) 한도를 작게 잡으면 조율 과정을 규칙과 문서로 정리하는 데 집중하게 되고, 그렇게 하다 보면 오케스트레이션이 자동화됩니다.
스스로 점검해 보기
에이전트와 함께한 최근 작업 열 개를 돌아보세요. 작업마다 어떤 자율성 레벨을 썼는지, 위험은 어느 정도였는지, 되돌리기는 쉬웠는지, 검증을 위해 어떤 근거가 나왔는지, 리뷰에 시간이 얼마나 들었는지, 재작업이 있었는지, 그리고 다음에도 같은 레벨을 쓰는 게 맞을지를 기록해 보세요.
안전하게 올라가는 법
한 번에 한 축씩만 올리세요. 감독 아래 있는 에이전트 하나에게, 성공했다는 근거를 분명히 남길 수 있는 범위가 정해진 작업 하나를 맡기는 것부터 시작하세요(깔끔하게 해내면 자율성 레벨 1입니다). 그다음 서로 독립적인 세 방향으로 조금씩 넓혀가세요. 읽기 위주의 탐색 작업을 병렬로 돌리고(레벨 4), 파일 소유권을 제한한 별도 워크트리에서 일하는 쓰기 에이전트를 추가하고(레벨 4), 반복 자동화를 더한 다음, 이슈나 음성 등을 시작점으로 삼는 에이전트 주도 오케스트레이션으로 나아가세요. 한 단계 올라갈 때마다 새로운 실패 패턴이 생기고, 그에 맞는 안전장치도 새로 필요해집니다.
실패 패턴을 하나씩 짚어보면 이렇습니다. 에이전트 하나를 너무 오래 돌리면 방향을 잃거나, 컨텍스트가 오염되거나, 보고가 끊기거나, 목표에서 벗어날 수 있습니다. 백그라운드 작업은 낡은 가정 위에서 돌아가거나 인수인계가 부실해질 수 있습니다. 병렬 작업이 너무 많으면 머지 충돌과 중복 결정이 생깁니다. 반복 작업이 너무 많으면 토큰이 티도 안 나게 새거나 프롬프트가 낡은 채 방치됩니다. 예외에만 개입하는 방식은 리뷰 대기열을 길게 만들고 알림에 무뎌지게 할 수 있습니다. 해결책은 더 굳게 믿는 것이 아닙니다. 범위를 좁히고, 근거를 더 잘 갖추고, 값싸게 되돌릴 길을 마련하고, 게이트를 더 단단히 하고, 소유권 규칙을 더 분명히 하는 것입니다.
자율성 레벨별 활용법:
- 레벨 0은 조심스럽게 다뤄야 하는 작업, 그리고 아직 판단이 서지 않았을 때 좋습니다.
- 레벨 1은 대부분의 탐색 작업에 좋습니다. 익숙한 영역의 언저리에서 일할 때 특히 그렇습니다.
- 레벨 2는 범위가 정해진 대부분의 작업에 좋습니다. 미처 몰랐던 의존 관계나 예상 밖의 문제가 나올 수 있다는 점은 감안해야 합니다.
- 레벨 3은 성공 조건을 충분히 명확하게 적을 수 있을 때 좋습니다.
- 레벨 4는 그 성공 조건을 기준으로 일을 깔끔하게 나눌 수 있을 때 좋습니다.
- 레벨 5는 여러 성공 조건 사이의 조율과 소통 방식이 완전히 체계로 자리 잡은 뒤에야 좋습니다.
병목은 언제나 검증입니다.
지금의 자신감 넘치는 분위기나 도구 수준과는 별개로, AI 에이전트와 함께 일하는 엔지니어링 팀이 갖춰야 할 성숙한 태도는 **상황에 맞게 조율된 자율성(calibrated autonomy)**입니다.
병목은 조율, 검증, 유지보수, 제품에 대한 판단, 그리고 장애에서 배우는 일입니다.
머지않아 우리는 언제 일하고, 언제 검증하고, 언제 물어봐야 할지 아는 루프를 설계하게 될 것입니다. 하지만 엔지니어의 실력은 여전히, 상황에 맞는 자율성 수준을 고르는 것, 그리고 자율성의 위험한 구석을 막아줄 패턴과 확실한 근거를 쌓는 것에 있습니다.
참고: Pangram은 이 글을 100% 사람이 쓴 글로 판정했습니다: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
