앤스로픽의 AI 네이티브 SDLC 플레이북을 실제 프로젝트에 적용해 본 사람 있나요?

그래서 난 Anthropic의 이번 결과물을 새로운 SDLC의 발명이라고 보지는 않음. 오히려 이 아이디어들을 하나의 구체적이고 기업 지향적인 운영 모델로 묶어내고, 그걸 현재의 에이전트 역량과 연결했다는 점에 의의가 있다고 봄.

아직 납득이 안 가는 부분

전체 아티팩트 체인은 프로덕트 오너, 아키텍트, 엔지니어, QA, 운영팀 간의 추적성을 높여줄 수는 있음. 하지만 작은 변경 사항까지 intent.md, spec.md, plan.md를 따로 만들고 관리하는 건 그냥 형식적인 절차(ceremony)가 될 가능성이 큼. Jira, 리포지토리, 마크다운 아티팩트에 정보가 다 중복으로 들어가면, 뭐가 진짜 진실의 원천(source of truth)인지 관리하기도 빡세질 거고.

특히 사람이 한 줄 한 줄 리뷰하는 방식에서 벗어나겠다는 건 좀 의문임. 에이전트가 명세서에 맞춰서 변경 사항을 체크할 수는 있겠지만, 명세서 자체가 틀렸거나 구현, 테스트, 리뷰가 똑같은 잘못된 가정을 공유하고 있으면 말짱 도루묵 아님? 에이전트가 검토를 여러 번 한다고 해서 자동으로 독립적인 검증이 되는 건 아니니까.

상태가 존재하는 시스템(Stateful systems)도 걱정되는 부분임. 이 데이터베이스 중심의 비판을 보면, 이 플레이북의 복구 모델은 기본적으로 코드를 되돌리거나 이전 이미지를 재배포하는 방식에 의존하고 있음. 근데 데이터베이스 마이그레이션, 운영 데이터, 락(lock), 스키마 드리프트, 동시성 변경 같은 건 항상 그렇게 되돌릴 수 있는 게 아니거든. Git은 선언된 의도는 기록할 수 있어도, 운영 데이터베이스의 실제 상태까지 보장하는 건 아니니까.

상세한 구현 중심 감사 결과, "제한적 승인"이라는 결론이 나왔어. 버전 관리되는 리뷰 정책, 계획-대-변경사항(plan-to-diff) 체크, 명시적인 실패 테스트, 단계별 운영 대응 같은 건 도입할 가치가 있더라고. 근데 소규모 프로젝트나 1인 개발 프로젝트에 전체 아티팩트 체인을 다 갖추는 건 좀 과하다는 의견도 있었지.

내가 하는 레거시 데이터 통합이나 ETL 마이그레이션 쪽은 이미 이런 간단한 흐름을 쓰고 있어:

분석 → 마이그레이션 → 독립적 품질 게이트

이것도 나름 쓸만하긴 한데, 중간 문서를 더 늘린다고 해서 분석이나 실행 가능한 테스트, 최종 검증을 개선하는 것보다 더 나은 결과가 나올지는 잘 모르겠네.

실제 사용자들에게 궁금한 점

여기서 이 플레이북이나, 아니면 그 핵심적인 부분이라도 데모 수준을 넘어서 실제로 구현해 본 사람 있어?

• 어떤 부분이 확실히 개선됐어?

• 커밋된 명세서가 재작업을 줄여줬어, 아니면 그냥 낡은 문서 쪼가리가 됐어?

• 수동 코드 리뷰를 뭘로 대체했고, 어떤 결함들이 여전히 빠져나갔어?

• 별도의 검증 에이전트가 진짜로 독립적인 체크를 수행했어?

• 데이터베이스나 상태를 유지하는 시스템은 어떻게 처리했어?

• 모델 사용료, CI 실행, 리뷰, 수정 비용까지 다 합치면 총비용은 어떻게 됐어?

• 어느 정도 규모의 작업부터 이 워크플로우가 쓸만했고, 또 어느 정도까지는 그냥 좋은 프롬프트랑 계획 모드만으로 충분했어?

가능하면 상황도 좀 알려줘: 신규 프로젝트(greenfield)인지 기존 프로젝트(brownfield)인지, 팀 규모는 어떤지, 규제가 있는 환경인지, 어떤 도구나 모델을 썼는지, 그리고 이게 그냥 몇 번 해본 건지 아니면 계속 운영 중인 건지도 말이야.

이론상으로 그럴싸한지보다는, 다섯 번, 스무 번, 백 번 넘게 수정해 본 뒤에 실제로 어떤 일이 벌어졌는지가 훨씬 궁금하네.