LOTS-OResearch Notes
같은 주제#LLM 10
10건 전체

2026-08-21 - Anthropic - The AI-Native SDLC Playbook

읽기 노트2026.09.23↻ 09.2633 min

2026-08-21 - Anthropic - The AI-Native SDLC Playbook

Source

  • 저자: Anthropic Applied AI team (기여 Jim Blackhurst, Will Steuk, Jamal Arif)
  • 유형: 공식 블로그 플레이북 (vendor guide)
  • 원문: [[80. Sources/articles/The AI-Native SDLC playbook Claude by Anthropic]]
  • URL: https://claude.com/blog/the-ai-native-sdlc-playbook
  • 발행/수집일: 발행 2026-08-21 / 수집 2026-09-23
  • 성격: 1차 공식 자료다. 다만 자사 제품(Claude Code·Design·Security·Tag) 도입을 전제로 한 벤더 플레이북이라 낙관 편향과 제품 종속이 있다. 정량 목표치(수주에서 수시간으로 등)는 검증된 성과가 아닌 벤더의 기대치로 보고 벤더 독립적 원리와 Claude 제품 종속 기능을 본문에서 구분한다.

TL;DR

  • 코드 작성이 더 이상 병목이 아니게 되면서 병목은 구현 전후에 사람이 처리하는 단계(plan·review/test·deploy), 사람이 코드 한 줄씩 검토하는 방식, 주간·월간 위원회를 거치는 승인 절차로 옮겨간다.
  • AI-native SDLC는 여섯 단계를 선형 파이프라인 대신 루프로 재구성하고 각 단계에 AI를 적용해 다음 단계를 자동으로 시작한다.
  • 각 단계는 버전관리에 아티팩트 하나를 커밋하고 끝나며(intent.md → spec.md → plan.md → diff·tests → PR·리뷰 findings → incident record → 다시 intent.md) 다음 단계는 그 파일을 읽어 시작한다.
  • 커밋된 아티팩트 체인이 그대로 감사 추적이 된다. 누가 무엇을 요청했고 에이전트가 무엇을 만들었으며 누가 승인했는지가 커밋 이력에 남는다.
  • 인간 책임은 사라지지 않고 게이트로 집중된다. 각 단계를 처음부터 시작하는 대신 에이전트가 문제로 표시한 부분을 검토한다.
  • 통제를 두 방식으로 나눈다. skill은 정책을 따르도록 안내하고, hook은 정해진 규칙에 따라 위반 행동을 차단한다.
  • 설정도 코드처럼 회귀 테스트한다. 에이전트를 조종하는 CLAUDE.md·skills·hooks 변경은 continuous evals로 게이팅한다.
  • 6단계 Maintain에서 정해진 규칙에 따른 탐지가 관리 한계선(control band) 이탈을 잡아 사람이 직접 실행하지 않아도 Claude를 호출하고 진단 결과를 다시 intent.md로 써서 루프를 닫는다.

코드는 더 이상 병목이 아니다

전통 SDLC는 계획·설계·구현·테스트·배포·운영 여섯 단계를 서로 다른 역할이 소유하고 문서·티켓·사인오프로 넘긴다. 이 구조는 코드 작성이 가장 오래 걸리고 비싼 시절, 그 긴 개발 기간 동안 정렬을 강제하려고 설계됐다. 이제 그 전제가 깨졌다.

build가 전통 SDLC가 허용하는 속도보다 빨라지면 세 가지 변화가 나타난다.

  • 병목이 구현 전후 단계로 이동한다. plan, review/test, deploy에는 여전히 사람이 처리해야 할 일이 남는다.
  • 통제가 현실과 맞지 않게 된다. 사람이 쓴 코드를 라인별로 검토하는 방식은 에이전트가 diff 대부분을 쓰기 시작하면 따라갈 수 없다.
  • 예외가 주간·월간 위원회로 라우팅되면서 거버넌스 비용이 오른다.

보안이 대표 사례다. 보안팀의 인력은 사람이 작성하는 코드의 양에 맞춰져 있어서 에이전트가 코드 산출을 늘리면 리뷰 대기열이 길어지거나 코드가 충분한 검토 없이 배포된다. 규제 조직은 둘 다 받아들일 수 없으므로 보안·정책 검사가 에이전트 속도를 따라가야 한다.

원문 도식 캡션

"Build is no longer the constraint — the human-speed steps around it are." 인간 속도 단계는 길이를 유지하는데 build만 몇 시간 단위로 붕괴한다는 것을 보여준다.

AI-native SDLC의 정의와 아티팩트 체인

AI-native SDLC는 옛 통제 목표를 새 강제 수단과 결합해 재구성한 프로세스다. 선형 흐름이 루프가 되고 각 단계에 적용된 AI가 다음 단계로 작업을 넘기고 시작한다. agentic SDLC, AI SDLC, agentic software development로도 불리며 같은 것을 가리킨다.

AI-native 방식의 공통 요소는 버전 관리에 남기는 산출물이다. 각 단계는 산출물 하나를 버전 관리에 남기고 끝나며 다음 단계는 그것을 읽어 시작한다. 초기 단계는 .md 파일이 주된 산출물이다. 제품 오너와 에이전트가 같은 파일을 읽고 행동할 수 있기 때문이다. Build부터는 산출물이 코드와 그 기록이 된다. 커밋 이력이 곧 감사 추적이다.

단계Traditional SDLCAI-native SDLC
Plan위원회가 요구사항을 모으고 워크숍·사인오프로 정제해 손으로 작성Claude가 여러 자료에서 문제점을 종합해 사람이 읽고 기계가 실행하는 intent.md에 기록
Design분석가가 명세를 작성하고 디자이너가 이를 해석요구사항·설계를 스킬로 인코딩된 표준의 안내를 받아 한 세션으로 압축, git에 버전관리
Build테스트·코드를 손으로 쓰고 문서는 개발 이후 작성테스트·코드를 AI가 생성하고 조직의 업무 규칙과 지식은 버전 관리되는 CLAUDE.md와 skills로 유지
Test단계 경계의 QA 게이트구현 전 과정에 짜여든 continuous evals
Deploy사람이 코드 한 줄씩 검토하고 승인·정책 검사는 리뷰 과정에서 일관성 없이 적용됨다층 에이전트 리뷰 + 규제·중요 코드만 사람 리뷰, 거버넌스는 hooks 승인 게이트로 행동 시점에 강제
Maintain사람이 프로덕션 버그를 감시에이전트가 라이브 배포를 모니터링, 관리 한계선 이탈은 진단 후 새 intent.md로 루프에 환류

기존 시스템과 기준 기록(source of truth)

이 원칙은 Build에만 해당하지 않고 각 단계가 만드는 모든 산출물에 적용된다. Jira·요구사항 관리 도구·Figma·변경 승인 시스템은 이미 감사와 협업에 쓰인다. 따라서 새 .md 파일을 만들 때도 기존 기록과의 관계를 정해야 한다. 원문은 산출물마다 기준이 되는 시스템 하나를 지정하고, 다른 시스템에는 복사본이나 원본 링크를 두도록 권한다.

구성기준 기록과 연결 방식
저장소가 기준Markdown 파일을 공식 기록으로 두고, 기존 시스템은 해당 파일이 포함된 커밋을 참조한다.
기존 시스템이 기준Jira·ServiceNow 등에 공식 기록을 두고 Markdown 파일은 작업 사본으로 쓴다. Claude가 MCP 연결을 통해 결과를 기존 시스템에 다시 기록한다.
두 시스템을 연결전환기의 최소 요건이다. Markdown 파일에는 기존 시스템의 기록 ID를, 기존 시스템에는 파일의 커밋 SHA를 남긴다. 이 경우 기준 기록이 두 곳에 있다는 점을 인정한다.

Plays (여섯 단계)

plays는 선형이 아닌 여섯 단계(Plan, Design, Build, Test, Deploy, Maintain)로 묶인다. 각 play는 무엇이 바뀌는가, 시작 방법, 구현 단계, 거버넌스 고려사항, 성공 측정법을 담고 각자 Prerequisites로 의존성을 명명한다. 의존 그래프에서는 들어오는 화살표가 없는 play부터 시작하면 되고 나머지는 자신을 가리키는 play를 먼저 도입한다.

한 단계는 아티팩트를 커밋하며 끝나고 그 커밋이 다음 단계를 연다. 채택된 intent.md가 요구사항·설계 단계를, 승인된 spec.md가 plan mode를, 머지된 PR이 파이프라인을, 프로덕션의 관리 한계선 이탈이 다음 intent.md를 시작한다. 처음에는 각 단계를 수동으로 시작한다. 최종 상태는 채택된 아티팩트가 다음 게이트를 여는 루프다.

Stage 1 · Plan (intent.md 캡처)

아이디어가 누군가 정리해 주기를 기다리지 않는다. 최초 제안자의 표현을 살려 의도를 한 번 기록하고, 버전 관리되는 파일로 남긴다.

  • 진입 경로: 사람의 아이디어, 파일된 티켓, 알림으로 표면화된 인시던트(Stage 6에서 되돌아온다).
  • 실행: originator가 Claude와 아이디어가 구체화될 때까지 브레인스토밍한다. Claude는 분석가가 물을 질문(범위·사용자·제약·성공 기준)을 던진다. 그다음 조직 템플릿(스킬로 인코딩 가능)으로 intent.md를 쓰고 originator가 오해한 부분을 교정한 뒤 shared home에 커밋한다.
  • 인프라: 비엔지니어용 Claude 접근(claude.ai 또는 Cowork), 합의된 intent.md 템플릿, 제품 오너가 지켜보는 버전관리 home. 단일 제품이면 repo 안 intent/ 폴더가 가장 단순하고 아티팩트 체인을 코드 옆에 둔다. 비개발자는 git을 직접 쓰지 않고 VCS connector를 통해 Claude가 대신 커밋한다.
  • 거버넌스: 증거는 커밋된 intent.md다. author·timestamp·전체 revision history가 git 이력에 남고 Stage 2로 보내는 채택/반려 결정은 merge 또는 closing review로 기록된다.
# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
 
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
 
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
 
## Affected users and systems
Claims handlers, portal team, claims-core API.
 
## Constraints
No new PII in the portal session. Existing authentication only.
 
## Open questions
Do third-party loss adjusters need access too?

Stage 2 · Design (요구사항·설계 단일 세션, spec.md)

요구사항과 설계가 한 세션으로 합쳐진다. 정책은 몇 주 뒤 리뷰에서 발견되는 대신 spec을 쓰는 동안 적용된다.

  • 실행: 제품 오너가 조직 스킬(brand·security·compliance·UX)이 로드된 세션에 intent.md를 첨부한다. 프롬프트는 intent.md를 가리키고 제약을 명명하며 우려 사항을 표시하도록 요구한다. 처음엔 수동, 다음엔 org-level slash command, 최종엔 intent.md merge를 트리거로 non-interactive job이 스킬을 로드해 spec.md를 PR로 커밋한다. 이후 제품 오너의 첫 개입은 리뷰다. 프론트엔드는 Claude Design(beta)에서 mock을 만들어 Claude Code로 export한다.
  • 에이전트가 표시한 우려 사항부터 해결한다. 분석가가 상위 담당자에게 보고했을 지점이므로 각 정책 책임자와 해소한 뒤 엔지니어링팀에 넘긴다.
  • 커밋: spec.md를 intent.md와 나란히 둔다. 파일 쌍이 요청된 것과 결정된 것을 기록한다. build 진행은 사람이 결정하고 조직이 고위험으로 분류하는 것은 tech lead와 상의한다.
Read the attached intent.md and produce a requirements and design spec for
integrating it into our existing codebase. Apply the skills available to you
so the plan conforms to our brand guidelines, security policies and UX
standards. Document the spec fully as spec.md, ready to hand to the
engineering team. Describe clearly any areas of concern, especially where
you cannot satisfy contradicting policies.

Stage 3 · Build (plan-first, 지식·가드레일의 코드화)

승인된 plan 없이는 아무것도 구현하지 않는다. 조직의 업무 규칙과 축적된 지식은 에이전트가 읽는 파일이 되고 가드레일은 습관 대신 코드로 실행된다.

  • plan mode를 기본 시작점으로: 승인된 spec.md를 주고 인터뷰시켜 plan을 반복한다. 이 대화를 못 본 엔지니어도 plan만으로 구현할 수 있을 때까지 다듬은 뒤 plan.md로 커밋한다. plan mode는 승인 전 파일 편집을 막으므로 설계 리뷰가 코드 생성 전에 일어난다. 견고한 plan이면 구현이 단일 패스로 끝나는 경우가 많다. 계획 이탈 시 같은 커밋에서 plan.md를 갱신하고 hook로 동기화를 강제할 수 있다.
  • auto mode: 가드레일이 성숙하면(튜닝된 CLAUDE.md, 정책 스킬, 차단 hook, 실행 가능한 테스트 스위트) routine 작업은 auto-accept가 기본이 된다. 감시는 편집을 지켜보는 방식에서 긴 자율 세션 뒤 아티팩트를 리뷰하는 방식으로 이동한다. worktree와 함께 병렬성을 키우며 Stage 6의 자율 루프의 토대가 된다.
  • CLAUDE.md: 신규 입사자가 첫날 필요할 컨텍스트(관례·명령·아키텍처·자주 하는 실수)다. /init로 초안을 만들어 한 페이지로 압축하고 repo root에 커밋해 코드처럼 리뷰한다. 작동 규칙은 Claude가 같은 실수를 두 번 하면 그 교정을 CLAUDE.md에 넣는 것이다.
  • skills: 일관되게 적용돼야 하는 조직의 업무 규칙과 지식은 skill로 쓴다. SKILL.md frontmatter가 트리거를, body가 행동을 정의하고 .claude/skills/<name>/에 두거나 plugin으로 조직 전체에 배포한다. skill은 권고적 통제라 정책을 따를 가능성을 높일 뿐 강제하지 못한다. 반드시 성립해야 하는 정책은 hook이나 PR 재검사로 뒷받침한다.
  • hooks(build-time 가드레일): skill 뒤의 결정론적 층이다. 보호 경로(생성 클래스·frozen 패키지) 편집 차단, 편집 후 formatter·linter 실행, 크리덴셜의 diff 유입 차단을 한다. 빠르고 변경 파일에 스코프되어야 하며 무거운 검사(전체 테스트)는 commit·PR로 넘긴다. 사람 승인을 요구하는 hook은 Stage 5로 간다. 병렬 작업이 사람의 승인을 기다리느라 멈추기 때문이다.
  • 병렬 세션·서브에이전트: 병렬 세션은 각자 worktree에서 도는 독립 Claude Code 인스턴스다. 2~3개가 현실적 시작점이고 상한은 사람이 제대로 리뷰할 수 있는 스트림 수다. 서브에이전트는 단일 세션 안의 스코프 헬퍼로 자체 컨텍스트·도구 제한을 갖고 반복 작업(code simplifier, verifier, researcher)에 맞다. .claude/agents/에 정의해 커밋한다.
# Plan: claims status self-service (from intent.md 2026-06-02)
 
## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py
 
## Order of work
1. Add the status endpoint behind existing auth.
2. Panel against the endpoint.
3. Wire into the portal nav.
 
## Risks
The claims-core API rate-limits at 50 rps; the panel must cache.
 
## Proof
test_status.py covers the four claim states; screenshot matches the
approved mock.

Stage 4 · Test (자기 검증 루프와 설정의 회귀 테스트)

모든 세션이 사람이 보기 전에 스스로 검증한다. 에이전트를 조종하는 설정도 그것이 쓰는 코드처럼 회귀 테스트를 받는다.

  • 피드백 루프: 테스트·빌드·스크린샷 diff 같은 자기 검증 수단을 항상 준다. 검증 과정을 단일 타깃(make test)으로 감싸 non-zero로 실패하게 하고 CLAUDE.md의 Commands에 정상 출력 예시를 적는다. 목표는 정량으로 명시한다("test_status.py의 모든 테스트 통과", "스크린샷이 mock과 일치"). 버그 수정은 실패 테스트를 먼저 쓴다. 버그를 테스트로 재현해 실패를 확인하고 커밋한 뒤, 테스트 편집을 막는 hook 아래에서 코드만 고치게 한다. UI는 브라우저·스크린샷 도구로 화면을 확인하고 수정하는 과정을 반복한다. 검증을 "done"의 정의에 넣고 완료 보고 전 출력을 붙인다.
  • 피드백 루프는 verifier 서브에이전트와 다르다. 루프는 작업 전체를 필요한 만큼 반복하며 관통하고 verifier는 세션이 완료라 여긴 시점에 fresh context로 한 번 최종 판정해 코드를 만든 가정에 판정이 오염되지 않게 한다.
  • continuous evals(CI): stage-gate QA의 AI-native 등가물이다. 최근 실제 작업 20~50개를 각각 eval(프롬프트 + 합격 기준)로 쓴다. CI에서 non-interactive로 스케줄에 더해 CLAUDE.md·skills·hooks 변경 시마다 돌린다. 이 설정이 에이전트를 조종하므로 코드가 받는 회귀 테스트를 받아야 한다. pass rate를 떨어뜨리는 설정 변경은 머지 전 리뷰하고 프로덕션 인시던트마다 eval을 추가해 회귀 테스트로 남긴다.

Stage 5 · Deploy (양방향 리뷰와 행동 시점 거버넌스)

리뷰가 양방향으로 돈다. 거버넌스는 에이전트가 행동하는 시점에 강제된다. 에이전트는 프로덕션 게이트까지 하고 그 너머는 넘지 못한다.

  • PR 리뷰 루프: Claude가 리뷰를 주고(조직 정책 대조, severity 랭킹) 받는다(자기 PR의 코멘트 처리). tech lead가 REVIEW.md를 repo root에 쓴다. passes(bugs / security / compliance against spec.md·plan.md·design principles), Important와 Nit의 정의, skip 목록을 담는다. findings는 자체로 승인·차단하지 않고 branch protection의 code owner 승인이 유지된다. @claude 태그로 코멘트를 처리·push하고 review findings는 두 번째로 잡히면 CLAUDE.md로 환류한다. managed Code Review(research preview) 또는 자체 CI의 claude-code-action(Bedrock·Vertex·Foundry 경유)으로 돌린다.
  • hooks 승인 게이트: Build의 allow/block hook에 더해 "ask"가 있다. 특정인이 승인할 때까지 행동을 정지시키며 릴리스 게이트가 대표 사례다. 팀 hook은 git의 .claude/settings.json에, 비협상 hook은 엔지니어가 끌 수 없는 managed settings에 둔다. 차단은 이유와 승인 경로를 Claude 출력에 함께 낸다.
  • CI/CD 통합: claude -p를 파이프라인에서 non-interactive로 돌린다. 읽기 전용 판단 단계(실패 빌드 triage, flaky 테스트 요약, changelog 초안)부터 시작해 write 단계는 기존 게이트 뒤에 붙인다. 에이전트 산출물은 PR로만 도착하고 main 직접 push 경로가 없다. 실행은 단명 스코프 토큰으로 sandbox에서 돌고 상시 프로덕션 크리덴셜을 갖지 않는다. 배포는 MCP tool(deploy·status·rollback, 환경별 스코프)로 노출해 배포 권한을 allowlist로 만든다. 환경에 따라 에이전트의 자율 실행 범위를 다르게 정한다(dev는 자유, prod은 release manager 승인 + hook 강제). rollback은 파이프라인에서 가장 잘 리허설된 단일 커맨드여야 한다.

Worked example · 규제 기업 managed settings

플랫폼 팀이 MDM·admin 콘솔로 배포하고 엔지니어가 편집·override할 수 없는 설정이다. permissions.deny로 시크릿·임의 네트워크 egress를 막고 permissions.allow로 안전한 inner loop를 사전 승인한다. disableBypassPermissionsMode + allowManagedPermissionRulesOnly로 규칙 확대를 봉인하고 sandbox가 OS 레벨 도메인 allowlist로 tool deny가 못 막는 shell egress를 차단한다. failIfUnavailable로 sandbox 초기화 실패 시 아예 시작을 거부한다. credentials가 ~/.ssh·~/.aws/credentials 읽기를 막고 allowManagedHooksOnly·disableSideloadFlags·strictKnownMarketplaces·allowManagedMcpServersOnly로 모든 skill·agent·hook·MCP를 승인된 마켓플레이스 경유로 제한한다. requiredMinimumVersion으로 평가된 버전 아래는 시작을 거부한다. 그대로 복사하기보다 데이터 분류에 맞춰 조정할 출발점이다.

Stage 6 · Maintain (루프 닫기)

루프가 닫힌다. 사람이 직접 실행하지 않아도 이벤트가 Claude를 호출하고, Claude가 찾은 내용을 intent.md로 작성해 파이프라인에 다시 넣는다.

  • 관리 한계선으로 루프 닫기: 정해진 규칙에 따라 동작하는 스크립트가 프로덕션을 감시한다. 롤링 윈도의 mean·std에 Western Electric 규칙을 얹어 느린 drift와 스파이크를 모두 잡고 탐지는 모델 없이 완전히 결정론적으로 둔다. 응답 tier는 버전관리 config(bands.yaml)로 정의한다. 1σ는 로그만, 2σ는 read-only 진단 호출, 3σ는 행동(PR 열기 또는 사전 승인 runbook)이다. 에이전트는 진단을 Stage 1 포맷 intent.md로 써서 파이프라인에 넣는다. 실행이 stateless·non-interactive라 아무도 시작하지 않아도 루프가 시작되고 끝난다. fix 배포 시 인시던트 eval을 추가한다.
  • recurring codebase scans (Claude Security): 보안 스캔은 특정 모델 아래의 시점 진술이라 코드와 모델 양쪽이 노후한다. 스케줄 스캔을 사람 호출 경로 없이 돌리고 발견을 다른 변경과 같은 게이트로 보낸다. Claude Security(Enterprise public beta)는 이 스케줄 스캔의 호스티드 형태로, Anthropic 인프라의 "Claude Mythos 5"에서 돌며 finding마다 validated + confidence rating을 붙이고 patch는 Claude Code on the web에서 리뷰한다. 한 PR에 맞는 finding은 리뷰 게이트로, 더 큰 것은 intent.md로 Plan에서 시작한다.
  • Claude Tag on-call: 인시던트는 Slack·Teams로도 도착한다(밤 10시 긴급 수정 메시지). Claude Tag(Slack public beta)가 자체 identity로 채널 멤버가 되어 첫 responder 역할을 한다. 채널이 감사 추적이 되어 요청·진단·인간 승인·fix가 한곳에 남는다. Claude는 MCP로 metric이 baseline으로 돌아왔는지 확인하고 post-mortem을 버전관리 lessons 파일에 쓴다. 인시던트가 아닌 작업도 같은 방식으로 triage해 작은 fix는 PR, 큰 것은 intent.md로 보낸다.
metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

단계별 측정 지표

플레이북은 각 play를 leading(선행)·lagging(후행) 지표로 계측하고 대부분 git 타임스탬프, PR 메타데이터, OpenTelemetry export처럼 이미 있는 신호에서 읽는다.

단계선행 지표후행 지표
Plan첫 대화에서 intent.md 커밋까지 시간(수주에서 수시간으로 기대)intent.md 채택률(survival rate), 첫 spec.md 커밋 이후 생긴 intent.md 변경 수
Designintent.md에서 spec.md 커밋까지 경과(두 git 타임스탬프)build 착수 후 요구사항 재작업(첫 plan.md 이후 spec.md 커밋 수)
Build1차 구현 패스로 머지되는 비율, 계획 승인에서 머지까지 시간변경당 재작업 사이클, 머지 diff가 plan.md와 일치하는 빈도
Test에이전트 변경의 1차 CI 통과율, eval pass rate 추이PR당 리뷰 시간, change failure rate, CI에서 잡힌 회귀 대 프로덕션 회귀
Deploy첫 리뷰까지 시간(분 단위로 하락 기대), 사람 개입 없이 해소된 리뷰 코멘트 비율, 게이트별 대기 시간머지 전 잡힌 결함·취약점 대 프로덕션 유출, DORA 지표
Maintainband 위반에서 triage 큐 intent.md까지 시간, 스케줄에 오른 repo 커버리지findings가 머지된 fix가 되는 비율, 동종 반복 인시던트 감소

결론

모델과 하네스가 발전하면서 코드 생산 방식을 넘어 SDLC 전체를 전환할 수 있게 됐다. 이 전환은 인간 판단을 프로세스 중심에 두고 대규모 엔터프라이즈의 거버넌스·규제 요구를 고려한다. 루프는 계속 돌고 인간 판단은 그 위에 남는다.

Open Questions

  • 벤더 낙관 편향을 어디까지 신뢰할지. 정량 목표(수주에서 수시간으로, "single pass" 구현)는 Applied AI team 사례에서 제시한 목표치이며, 독립적으로 검증되지는 않았다. 우리 맥락의 재현성은 실험해야 확인된다.
  • 제품 종속·베타 상태의 현재 유효성. Claude Design(beta), Claude Tag(Slack public beta), Claude Security(public beta, "Claude Mythos 5" 모델), managed Code Review(research preview)는 모두 2026-08-21 기준이라 현재 가용성·명칭을 확인해야 한다.
  • legacy source of truth 세 구성(repo / legacy system / linkage) 중 개인 볼트·소규모 팀에는 무엇이 맞는가.
  • 벤더 독립 원리(아티팩트 체인, plan-first, skill·hook 이원, 관리 한계선)와 Claude 제품 종속 기능의 경계는 어디인가. 책 집필의 일반화 질문과 연결된다.
  • intent.md·spec.md·plan.md 템플릿을 이 볼트에 도입한다면 99. System/Templates와 99. System/Skills 중 어디에 두고 무엇으로 트리거하는가.

Connections

Discussion

Comments

댓글은 승인 후 공개됩니다.

연결 그래프