앤트로픽이 The AI-Native SDLC Playbook 이라는 글을 8월 21일에 올렸습니다. 쓴 사람은 Louis Claxton 이고, 카테고리는 Enterprise AI 와 Claude Code 입니다. 같은 이름으로 무료 코스도 같이 열렸습니다. 14차시에 전체 1시간, Claude Academy 쪽에 올라가 있고 로그인하면 진행 상황이 저장되는 형태입니다. 차시 제목이 글의 소제목과 거의 그대로 겹치니까, 글을 읽고 나서 코스를 보면 같은 내용을 목소리로 한 번 더 듣는 셈입니다.
읽어보게 된 단순한 이유입니다. 제가 지금 만들어 왔던것이 글에 적힌 파일 이름들과 상당히 유사합니다. CLAUDE.md 가 있고, 스킬이 있고, 커밋 직전에 도는 훅이 있고, 서브에이전트를 정의해 둔 폴더가 있습니다. 그러니까 이 문서는 제가 어쩌다 그렇게 쌓아 올린 것들을 누군가 정리해서 이름을 붙여 놓은 문서일 가능성이 있었습니다. 실제로 절반은 그랬고, 절반은 제가 이미 해보고 실패한 구조였습니다.
먼저 여섯 단계를 차례로 정리하겠습니다.
이제 코드가 병목이 아니라는 것 전제는 하나입니다
문서의 첫 주장이 "Code is no longer the bottleneck" 입니다. 근거로 드는 문장이 이겁니다.
Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven't changed at the same pace.
코드는 1년 전에는 상상하기 어려웠던 속도로 나오는데, 코드 주변의 프로세스는 같은 속도로 바뀌지 않았다는 겁니다. 그래서 "Many engineering teams still have the same approval gates, reviews, handoffs, and policies, stalling productivity gains" 라고 적었습니다. 승인 게이트와 리뷰와 핸드오프가 그대로 남아서, 올라간 생산성을 그것들이 다시 잡아먹고 있다는 겁니다.
여기서 한 걸음 더 나간 진단이 나오는데, 저는 이 문장이 이 문서에서 제일 중요하다고 봅니다. 전통적인 SDLC 는 코드를 쓰고 구현하는 단계가 가장 오래 걸리고 가장 비쌌던 시대에 효율을 극대화하도록 설계된 것이고, 이제 그게 사실이 아니라는 서술입니다. 그러니까 프로세스가 낡았다는 말이 아니라, 프로세스가 최적화하던 대상이 사라졌다는 말입니다. 이렇게 놓으면 "그럼 어디를 최적화해야 하나" 라는 질문으로 자연스럽게 넘어가고, 문서의 나머지가 그 답입니다.
Plan 단계에서 백로그 대신 intent.md 한 장을 씁니다
기존 흐름을 이렇게 적어놨습니다. "An idea passes through backlog entries, user stories, story points, and refinement meetings before anyone can act on it." 아이디어 하나가 백로그 항목과 유저 스토리와 스토리 포인트와 리파인먼트 미팅을 거친 다음에야 누군가 손을 댈 수 있다는 거죠.
이제는 이렇게 합니다. "The originator brainstorms with Claude and writes the result down as intent.md, a proto-spec in the originator's own terms." 제안한 사람이 클로드와 이야기를 나누고 그 결과를 intent.md 로 적습니다. 중요한 건 뒤쪽입니다. 제안한 사람이 자기 말로 쓴 초기 스펙이라는 조건이 붙어 있습니다. 담을 내용은 "what is wanted, why, and under which constraints" 세 가지고요. 무엇을 원하는지, 왜인지, 어떤 제약 아래에서인지.
승인 구조도 같이 적혀 있습니다. 프로덕트 오너가 에이전트가 쓴 intent.md 를 검토하고 고친 다음 커밋한다는 것, 그리고 받아들이거나 거부한 결정이 머지 또는 리뷰 종료로 기록에 남는다는 것.
읽으면서 이 단계가 가장 저항이 적을 것 같다고 느꼈습니다. 백로그 항목을 쓰는 일이 즐거운 사람은 별로 없고, 그 문서가 나중에 누군가에게 실제로 읽힌 경험도 흔치 않으니까요. 대신 이 단계가 잘 굴러가는 조직은 그 전에도 이미 잘 굴러갔을 겁니다. 제안한 사람이 자기 말로 무엇을 원하는지 적을 수 있어야 하고, 그게 먼저니까요. 그게 안 되는 조직에서는 intent.md 도 결국 리파인먼트 미팅에서 받아쓰기한 문서가 됩니다.
Design 단계는 요구사항과 설계를 한 세션에 넣습니다
기존 방식을 꽤 정직하게 적어놨습니다. "Requirements and design are separate phases run by separate teams... The separation exists for accountability, but it is slow and lossy." 요구사항과 설계를 다른 팀이 다른 단계에서 하는 이유가 책임 소재 때문이라고 인정하고, 그런데도 느리고 손실이 있다고 적었습니다. 이렇게 적어두면 반박하기가 어렵습니다. 분리의 목적을 부정하지 않고 비용만 지적하는 형태니까요.
두 단계를 한 번의 프롬프트 세션에 넣으라고 합니다. 클로드가 intent.md 를 받아서 요구사항과 설계 스펙을 만들고, 우려되는 부분에 표시를 남깁니다. 그 스펙은 프로덕트 오너가 승인하고, 조직이 고위험으로 분류한 것은 테크 리드나 아키텍트에게 갑니다. 조직 차원의 스킬이 이 세션을 안내하는 구조라서, 회사마다 다른 설계 관행이 그 스킬 안에 들어갑니다.
한 가지 의문이 남습니다. 분리가 책임 소재 때문에 있다고 인정하고서 합치는 쪽을 골랐으니, 합친 뒤의 책임은 승인하는 한 사람에게 모입니다. 문서는 그 사람을 프로덕트 오너로 적어놨는데, 요구사항까지는 그 사람 일이 맞지만 설계가 타당한지 판단하는 것도 같은 사람 일인지는 다른 문제입니다. 고위험으로 분류한 것은 테크 리드나 아키텍트가 본다고 해뒀으니 답이 아예 없지는 않습니다. 다만 무엇을 고위험으로 분류할지 정하는 것도 결국 같은 사람이라, 이 단계가 실제로 빨라지는지는 조직에 따라 달라질 것 같습니다.
Build 단계는 계획을 먼저 쓰게 만드는 데서 시작합니다
지금까지는 이랬다고 적어놨습니다. "An engineer reads the design and starts writing code. How the change will be made... stays in the engineer's head." 설계를 읽고 코드를 쓰기 시작하는데, 어떻게 바꿀지는 그 사람 머릿속에만 있다는 거죠.
이제는 클로드가 plan mode 에서 만든 계획을 먼저 씁니다. plan.md 에 담을 것도 구체적으로 적어놨습니다. "The plan names the files that change, the order of the work, and the tests that prove it." 바뀌는 파일, 작업 순서, 그걸 증명하는 테스트.
그리고 한 줄이 더 붙어 있습니다.
When implementation departs from the plan, update plan.md in the same commit
구현이 계획에서 벗어나면 같은 커밋에서 plan.md 를 고치라는 겁니다. 이 한 줄에 대해서는 뒤에서 따로 이야기하겠습니다.
이 단계에 붙은 나머지 요소가 셋입니다. CLAUDE.md 는 코드베이스의 관행과 자주 나오는 실수를 담는 파일이고, 스킬은 조직의 정책을 일관되게 적용하는 수단입니다. 문서가 스킬을 "institutional knowledge" 라고 부르는데, 사람이 나가면 사라지던 것을 파일로 남긴다는 뜻으로 읽힙니다.
세 번째가 병렬 세션입니다. "One engineer runs several Claude sessions at once, each in its own worktree on its own task." 엔지니어 한 명이 여러 세션을 동시에 띄우고, 각 세션은 자기 워크트리에서 자기 과제를 맡습니다. 반복되는 일은 서브에이전트로 떼어냅니다. .claude/agents/ 아래 마크다운으로 정의하고, 언제 부를지와 어떤 도구를 쓸지를 적어둡니다. 코드를 단순화하는 역할, 동작을 테스트해서 확인하는 역할, 코드베이스를 뒤지는 역할 같은 예를 들었습니다.
여기서 제한을 스스로 걸어놓은 게 눈에 띕니다. 두세 개로 시작하라고 하고, 실제 상한은 리뷰 능력이 결정한다고 적었습니다. 병렬 세션 개수를 성과 지표처럼 쓰지 않겠다는 뜻으로 보입니다. 이건 맞는 판단입니다. 세션을 여덟 개 띄워놓고 결과물을 다 읽지 못하면 그건 여덟 배 일한 게 아니라 검토를 일곱 개 건너뛴 겁니다.
Test 단계는 스스로 확인하게 만들고, 설정 자체를 회귀 테스트합니다
기존 방식을 적어놓은 문장이 좀 아팠습니다. "The signal that code works arrives late. CI minutes later, a tester days later, production weeks later." 코드가 돈다는 신호가 늦게 도착한다는 겁니다. CI 는 몇 분 뒤, 테스터는 며칠 뒤, 프로덕션은 몇 주 뒤.
이제는 이렇게 합니다. "The session is given a way to check its own work before a person sees it." 사람이 보기 전에 세션이 자기 작업을 스스로 확인해볼 수 있게 만들어준다는 겁니다. 테스트를 돌리거나 스크린샷을 찍는 것 같은 즉시 피드백을 붙이면, 세션이 자기 실수를 자기가 고친 뒤에 사람 앞에 옵니다.
버그 수정에는 조건을 하나 더 걸었습니다. 실패하는 테스트를 사람이 먼저 쓰고, 수정 과정에서 에이전트가 그 테스트를 건드리지 못하게 한다는 겁니다. 그래야 버그가 실제로 사라진 게 증명된다는 논리고요. 이건 게이트로 성립합니다. 테스트 파일이 바뀌었는지는 모델이 뭐라고 주장하든 값이 정해지는 사실이니까요.
두 번째가 CI 에서 실행되는 평가셋입니다. 원문 용어는 continuous evals 입니다. 여기서 평가하는 게 코드가 아닙니다. CLAUDE.md 와 스킬과 훅, 즉 에이전트 설정 자체를 결과가 알려진 실제 과제 20~50개에 던져봅니다.
The suite runs non-interactive in CI on a schedule and on any change to CLAUDE.md, skills or hooks.
주기적으로 실행되고, CLAUDE.md 나 스킬이나 훅이 바뀌면 그때도 실행됩니다. 설정 변경은 통과율을 기준으로 막고, 프로덕션에서 터진 사고는 영구 회귀 테스트가 됩니다.
이 항목이 문서에서 제일 새로웠습니다. 프롬프트와 설정 파일을 코드처럼 취급해서 회귀 테스트를 붙이는 발상인데, 저는 제 CLAUDE.md 를 여러 번 고치면서 그게 좋아졌는지 나빠졌는지 확인해본 적이 없습니다. 고치고 나서 다음 세션이 잘 돌아가면 잘 고친 거라고 여겼죠. 그건 확인이 아니라 인상입니다.
Deploy 단계는 훅이 멈춰 세우고 사람이 통과시키는 구조입니다
여기서 지적하는 현재 모습이 "Humans review every line of code and governance occurs in review cycles, often inconsistently" 입니다. 사람이 모든 줄을 읽고 거버넌스는 리뷰 주기 안에서만 일어나는데, 일관성도 자주 없다는 겁니다. 에이전트 리뷰를 여러 단계로 두고, 사람 리뷰는 규제 대상이거나 중요한 코드에만 남겨두라고 합니다.
이 단계를 제일 조심스럽게 써놨습니다. 훅은 승인 게이트로 씁니다. "A hook can also ask, pausing the action until a specific person approves." 훅이 물어볼 수도 있고, 특정한 사람이 승인할 때까지 동작을 멈춰 세운다는 겁니다. 허용 목록에는 make build 같은 안전한 명령만 허용하고 자격증명 접근과 임의 네트워크 호출은 거부합니다. 샌드박스는 OS 수준에서 격리하고 도메인을 제한합니다.
CI/CD 로 들어가는 순서도 정해놨습니다. 처음에는 비대화형 읽기 전용 작업으로만 넣고, 쓰기는 기존 승인 게이트 뒤에서만 허용합니다. "Agent jobs run in containers under a network policy with short-lived scoped tokens, and hold no production credentials by default." 컨테이너 안에서 네트워크 정책이 적용된 채로 실행되고, 수명이 짧고 범위가 좁은 토큰을 쓰고, 기본적으로 프로덕션 자격증명을 갖지 않습니다.
직무 분리는 명확하게 적어놨습니다.
Separation of duties is preserved, because the agent that wrote the code has no way to approve it... Approval comes from a human through branch protection
코드를 쓴 에이전트에게는 그걸 승인할 방법이 아예 없고, 승인은 branch protection 을 거쳐 사람이 합니다.
Maintain 단계에서 탐지에는 모델을 넣지 않습니다
마지막 단계에서 한 바퀴가 완성됩니다. 기존 형태는 "All tickets or incidents wait on a person to act on it" 이고, 이제는 관리 한계를 벗어났다는 신호 같은 트리거가 사람 없이 클로드를 부릅니다.
보안 스캔은 이벤트 기반에서 예정된 주기로 옮겼습니다. 연결된 모든 저장소를 대상으로, 가용한 가장 강력한 모델로 돌리고, "with findings validated before anyone reads them" 이라고 적었습니다. 누가 읽기 전에 탐지 결과를 먼저 검증한다는 것이고, 신뢰도 등급이 붙습니다. 스캐너가 뱉은 걸 그대로 사람에게 보내면 사람이 오탐을 걸러내는 일을 하게 되는데, 그 일을 사람 앞에 오기 전으로 옮긴 셈입니다.
프로덕션 모니터링 쪽이 이 문서에서 제일 단호합니다. 탐지 스크립트는 이동 기준선과 통계 규칙을 쓰고, Western Electric 규칙을 이름으로 들었습니다. 그리고 이렇게 못 박았습니다.
Detection stays entirely deterministic, with no model involved.
탐지는 처음부터 끝까지 정해진 규칙으로만 하고 모델은 넣지 않습니다. 모델은 탐지가 끝난 다음에 들어옵니다. 1σ 를 벗어나면 로그만 남기고, 2σ 에서는 클로드가 읽기 전용으로 진단하고, 3σ 에서는 클로드가 PR 을 열거나 사전 승인된 런북을 실행합니다. 그리고 그 진단 결과가 intent.md 로 쓰여서 파이프라인 맨 앞으로 다시 들어갑니다.
그래서 여섯 단계가 일직선이 아니라 한 바퀴 돌아옵니다. intent.md 에서 시작해서 intent.md 로 돌아옵니다.
다섯 개의 파일이 감사 기록이 됩니다
여섯 단계를 하나로 묶는 게 단계마다 남기는 산출물입니다. 단계마다 다음 단계가 읽을 수 있는 산출물을 커밋합니다.
Together, the intent, the spec, the plan, the diff and the review findings are the audit trail.
의도와 스펙과 계획과 코드 변경과 리뷰에서 나온 지적이 합쳐져서 감사 기록이 된다는 겁니다. 거버넌스 원칙도 한 줄로 적혀 있습니다. "Humans remain accountable for every decision that requires judgment." 판단이 필요한 모든 결정은 사람이 계속 책임진다는 겁니다. 그 뒤에 설명이 하나 붙는데, 에이전트 SDLC 에서는 사람의 주의가 검토해야 하는 산출물을 따라 옮겨간다고 적었습니다.
이 대목에서 제가 조금 멈췄습니다. 사람의 주의가 옮겨간다는 표현은 옮겨간 다음에 할 일이 더 가벼워졌다는 뜻으로 읽히기 쉬운데, 실제로는 읽어야 할 게 늘었습니다. 예전에는 코드 변경만 읽었습니다. 이제는 의도와 스펙과 계획과 코드 변경과 리뷰에서 나온 지적을 읽습니다. 문서를 쓰는 주체가 사람에서 에이전트로 바뀌었을 뿐, 문서의 개수는 줄지 않았습니다.
그렇다고 이게 결함이라고 보지는 않습니다. 줄 단위로 읽는 일이 애초에 지속 가능하지 않다는 게 이 문서의 전제고, 그 문장도 직접 적혀 있습니다. "Reviewing each line by hand made sense when a person had written it, but it can't keep up once agents write most of the diff." 사람이 썼을 때는 손으로 한 줄씩 읽는 게 말이 됐지만, 에이전트가 코드 변경 대부분을 쓰면 따라갈 수 없다는 겁니다. 맞습니다. 다만 그렇게 되면 사람이 하는 일은 더 위쪽 문서를 더 꼼꼼히 읽는 일이 되고, 그건 가벼워진 게 아니라 종류가 바뀐 겁니다. 문서가 이걸 "orchestrating parallel work streams and triaging findings" 라고 적었습니다. 병렬 작업을 지휘하고 탐지 결과를 선별하는 일이죠. 그 선별이 본업이 되는 쪽이 실제 모습에 가까울 것 같습니다.
plan mode 와 훅은 같은 종류의 게이트가 아닙니다
이 문서를 읽으면서 제일 오래 들여다본 대목입니다. 둘 다 승인 게이트로 소개되는데, 저는 두 개가 전혀 다른 것이라고 봅니다.
plan mode 는 이렇게 적었습니다. "Plan mode enforces this itself, since Claude cannot edit files until the engineer accepts the plan." 엔지니어가 계획을 받아들이기 전까지 클로드가 파일을 고칠 수 없기 때문에 plan mode 가 스스로 강제한다는 겁니다. 이건 성립합니다. 파일 수정 권한이 있느냐 없느냐는 모델이 무슨 말을 하든 바뀌지 않는 사실이고, 그래서 모델의 협조에 의존하지 않습니다.
훅은 다릅니다. 훅 자체는 정해진 대로 실행되지만, 훅이 무엇을 검사하는지는 훅을 짠 사람이 정합니다. 그리고 저는 이 지점에서 실패했습니다. 사이드 프로젝트에 검토를 자동화한 훅을 걸어놓고 넉 달을 굴렸는데, 나중에 열어보니 그중 이 레포를 보고 있는 게 하나도 없었습니다. 경로가 안 맞았거나, 조건이 절대 참이 되지 않았거나, 검사 대상이 제가 실제로 쓰는 것과 달랐습니다. 훅이 있다는 사실과 훅이 무언가를 막고 있다는 사실 사이가 그렇게 멀었습니다.
한 번 확인한 경험이 신뢰를 만들어버리는 것도 같은 문제입니다. 이 블로그를 굴리는 레포에는 커밋 직전에 도는 시크릿 스캔이 있고, 실제로 자격증명 파일을 실수로 스테이지했을 때 막혔습니다. 그래서 몇 달을 의심하지 않았는데, 정규식을 떼어내 가짜 시크릿에 던져보니 하나도 못 잡았습니다. 제가 가진 자격증명을 기준으로 목록을 만들었으니 제가 안 가진 종류는 전부 통과였던 거죠.
그러니까 훅을 승인 게이트로 쓰라는 조언은, 실제로는 "훅이 검사하는 항목을 계속 검증하라"는 조언이 되어야 합니다. 문서에 이 부분이 아예 없는 건 아닙니다. Test 단계의 평가셋이 훅이 바뀔 때마다 실행되는 구조니까요. 다만 그건 훅이 바뀌었을 때 실행되는 거고, 처음부터 아무것도 안 잡던 훅은 바뀌지 않으니 계속 안 잡습니다. 넉 달 동안 조용했던 제 훅들이 정확히 그 상태였습니다.
같은 이유로 저는 AI 에게 PR 을 리뷰하게 맡기는 것도 조심스럽게 봅니다. 이 부분은 문서가 잘 처리했습니다. 에이전트 리뷰를 여러 단계로 두되 승인 권한은 주지 않고, branch protection 을 통해 사람에게서 받게 만들어놨으니까요. 리뷰와 승인을 분리한 것이 핵심이고, 이게 흐려지는 순간 검문소와 통행증 발급처가 같아집니다. 저도 예전에 발행 스크립트가 검수 문서의 합격 표시를 찾아서 통과 여부를 정하게 해뒀다가 걷어냈습니다. 그 표시를 검사받는 쪽이 직접 쓰고 있었거든요.
계획에서 벗어났을 때 고치는 것 역시 계획입니다
plan.md 에 대해서는 제가 이미 한 번 반대 의견을 적어놨습니다. 계획을 먼저 세우고 그대로 구현시키라는 절차가 커뮤니티에서 꽤 읽히던 시기가 있었고, 저는 계획서대로 짰으면 그 버그는 그대로 나갔다고 썼습니다. 실제로 그날 고친 버그들 중 뒤쪽에 가서야 패턴에 이름이 붙었고, 앞에서 승인받은 설계는 그 시점에 이미 틀린 문서였습니다.
그래서 Build 단계를 읽을 때 경계하고 들어갔는데, 아까 인용한 한 줄에서 생각이 바뀌었습니다.
When implementation departs from the plan, update plan.md in the same commit
구현이 계획에서 벗어나면 같은 커밋에서 계획을 고치라는 겁니다. 이건 제가 반대한 것과 다릅니다. 제가 반대한 건 "계획대로 구현하라"였고, 이 문장은 계획에서 벗어나는 것을 정상 경로로 인정한 다음에 기록을 맞추라고 합니다. 계획을 지시서로 두지 않고, 지금 이해한 내용을 적어둔 문서로 두는 겁니다.
plan.md 를 두는 이유도 거기 있다고 봅니다. 계획이 코드를 결정하는 게 아니라, 어떻게 바꿀지가 그 사람 머릿속에만 있는 상태를 끝내는 데 값어치가 있습니다. 문서가 예전 방식을 적으면서 쓴 표현이 "stays in the engineer's head" 였는데, 에이전트가 코드를 쓰는 환경에서는 그 머릿속이 심지어 사람 것도 아닙니다. 세션이 닫히면 사라지고요. 그러니 벗어난 계획을 고쳐서라도 남겨두는 게 맞습니다.
판단이 필요한 결정을 누가 정하는지는 여전히 남는 질문입니다
문서를 다 읽고 남은 게 이 질문 하나입니다. "Humans remain accountable for every decision that requires judgment" 는 원칙으로는 반박할 데가 없습니다. 그런데 어떤 결정이 판단을 요구하는 결정인지는 이 문장이 정해주지 않습니다.
문서 내용의 그 경계가 조직의 분류에 맡겨져 있습니다. 고위험으로 분류한 것은 테크 리드에게 가고, 규제 대상 코드는 사람이 읽고, 사전 승인된 런북은 3σ 에서 자동으로 실행됩니다. 그 분류 자체는 누가 어떤 근거로 만드는지가 비어 있는데, 이건 문서의 흠이라기보다 조직마다 다를 수밖에 없는 부분이라서 비워둔 것으로 읽힙니다. 다만 실제로 여기서 사고가 납니다. 저는 자동으로 실행되던 게 아무것도 안 잡고 있었다는 걸 넉 달 뒤에 알았고, 그 넉 달 동안 제 분류는 "이건 자동화해도 되는 일" 이었습니다.
그리고 한 가지, 도구를 파는 회사가 프로세스를 함께 내놓았다는 사실도 짚어둘 만합니다. 여섯 단계 전부가 특정 제품의 기능 이름으로 채워져 있고, plan mode 와 스킬과 훅과 서브에이전트와 MCP 가 각 단계의 답으로 배치돼 있습니다. 그게 곧 틀렸다는 뜻은 아닙니다. 실제로 그 기능들로 지금 돌아가는 것들이 있으니까요. 다만 이 문서를 읽는 방식은 "우리 프로세스를 여기에 맞추자" 가 아니라 "우리 프로세스의 어디가 이 문서가 말하는 병목인지 찾자" 쪽이어야 할 것 같습니다. 앞의 방식으로 읽으면 산출물 다섯 종을 먼저 만들고 그 다음에 쓸 데를 찾게 되는데, 그건 제가 훅 열두 개를 걸어놓고 넉 달 뒤에 열어본 것과 같은 순서입니다.
코스는 아직 다 안 봤습니다. 차시 제목이 글의 소제목과 겹치니 내용이 크게 다르지는 않을 것 같은데, Test 단계의 평가셋 쪽은 글에 적힌 것보다 구체적인 게 나올지 알고 싶어서 그 차시부터 볼 생각입니다. 제 CLAUDE.md 와 스킬을 결과가 알려진 과제에 던져보는 건 지금 당장 해볼 수 있는 일이기도 하고요.
확인한 자료
본문의 영어 인용은 위 원문 표현이고, 우리말 풀이는 제가 옮긴 것입니다. Maintain 단계의 보안 스캔에 적힌 모델명은 페이지에서 확실하게 읽어내지 못해 원문 표현대로 "가용한 가장 강력한 모델" 로만 적었습니다. 코스 14차시의 개별 소요 시간도 확인하지 못했고, 첫 차시 16분과 전체 1시간만 확인했습니다.
댓글
댓글 쓰기