SI/SM IT 대기업을 위한 「게이트 우선 AX 방법론」

게시 2026/10/20

By BLUEBUG

384 분읽는 시간

아정당 「AX 빌더 조직을 만들어 가며 읽은 250개의 자료」를 근거로 한 설계안

항목	내용
작성일	2026-10-20
문서 성격	방법론 설계안입니다. 검증이 끝난 표준이 아니라, 근거를 밝힌 원칙 위에 제가 설계한 제안입니다
출발 자료	아정당 공개 사이트 `ajd-builder-cases.netlify.app`(사이트 표기 작성일 2026.09.18)와, 같은 자료를 사례별로 다시 확인해 정리한 앞선 해설 문서
보강 자료	2026년 10월 기준으로 직접 열어 확인한 국내 IT서비스 기업 발표, 대가산정 제도, 규제, 독립 연구
대상 독자	SI(시스템 구축)와 SM(시스템 운영)을 하는 IT서비스 대기업에서 AX를 기획하거나 이끄는 분
읽는 요령	1장과 4장을 먼저 읽으면 전체 얼개를 잡을 수 있습니다. 실제 적용은 5~8장, 의사결정은 13장을 보시면 됩니다. AIDD(AI 주도 개발)의 실무 가이드와 복사해 쓰는 프롬프트와 SKILL은 14장과 부록 D, E에 있습니다

0. 먼저 알아 둘 것

0.1 이 문서가 무엇이고 무엇이 아닌지

이 문서는 하나의 질문에서 출발합니다. “아정당이 읽은 250개 자료가 말하는 원칙을, SI/SM을 하는 IT서비스 대기업의 AX에는 어떻게 옮길 수 있는가?”

먼저 솔직하게 밝혀 둘 것이 있습니다. 아정당 자료가 다룬 24개 사례는 모두 제품을 직접 만들어 파는 조직입니다. 메타, 아마존, 쇼피파이 같은 빅테크와 플랫폼, 당근·토스·채널톡·마이리얼트립 같은 국내 서비스 회사, PostHog나 Linear 같은 소프트웨어 회사입니다. 고객의 요구에 맞춰 시스템을 구축하고 운영해 주는 SI/SM 회사는 한 곳도 없습니다. 그래서 아정당 자료에서 SI/SM에 그대로 가져올 수 있는 결론은 많지 않습니다. 가져올 수 있는 것은 사례들 사이에서 반복된 원칙이고, 그 원칙을 SI/SM의 구조(고객 계약, 검수와 감리, 망분리, 운영 SLA)에 맞춰 바꾸는 일은 제 설계 작업입니다.

그래서 이 문서는 문장의 성격을 엄격하게 나눕니다.

표시	뜻
[근거]	아정당 자료 또는 제가 직접 열어 확인한 외부 자료에 있는 내용입니다. 출처를 함께 적었습니다
[풀이]	근거를 이해하기 쉽게 다시 설명하거나, 근거에서 합리적으로 읽어 낸 해석입니다. 틀릴 수 있는 해석이므로 근거와 구분했습니다
[제안]	제가 설계한 방법론의 내용입니다. 검증된 사실이 아니며, 파일럿으로 확인해야 하는 가설입니다
[한계]	확인하지 못했거나, 확인했지만 조심해서 읽어야 하는 부분입니다

표시가 없는 문장은 앞뒤 문맥에서 정의나 설명으로 읽으시면 됩니다.

0.2 근거의 강도

[근거]로 쓴 내용도 무게가 다릅니다. 이 문서는 근거를 세 단계로 구분해 표기합니다.

표기	뜻
강	회사 공식 글, 보도자료, 연구 기관의 원문처럼 당사자나 연구자가 직접 낸 자료를 제가 열어 확인했고, 복수 출처가 같은 방향을 가리킴
중	한 곳의 공식 자료 또는 언론 보도로만 확인했거나, 업체가 자기 제품을 설명하는 자료
약	아정당 문서에만 적혀 있고 제가 외부에서 확인하지 못함, 또는 확인했지만 표본이 작거나 조건이 한정적임

이 구분은 앞선 해설 문서의 ✅ 재확인, ◐ 부분 확인, ○ 문서 기재만과 대응합니다. 앞선 해설에서 ○는 “이번 검색에서 확인하지 못함”이라는 뜻이었고 틀렸다는 뜻이 아니었습니다. 이 문서의 약도 같은 뜻입니다.

0.3 이 문서에서 쓰는 용어

SI는 고객의 요구에 맞춰 시스템을 설계하고 구축하는 프로젝트 사업을, SM은 구축된 시스템을 운영하고 유지보수하는 서비스 사업을 가리킵니다. 회사마다 세부 정의가 다르므로 이 문서에서의 약속으로 읽어 주시면 됩니다.

AX는 이 문서에서 AI를 업무와 조직에 넣어 일하는 방식 자체를 바꾸는 일로 씁니다. 삼성SDS 대표가 2026년 9월 행사에서 AX를 비즈니스와 업무 방식 자체를 처음부터 새롭게 재설계하는 것이라는 취지로 정의했다고 보도되었는데(CIO Korea), 같은 방향의 정의입니다. 도구를 나눠 주는 일이 아니라 일하는 방식을 바꾸는 일이라는 점이 중요합니다.

게이트는 아정당 자료의 핵심어로, 만든 것이 고객이나 사용자에게 닿기 전에 반드시 지나야 하는 지점입니다. 사람이 하는 코드 리뷰만이 아니라 자동 검사, 배포 창, 권한 분리, 플랫폼이 강제하는 정책까지 모두 포함합니다.

하네스는 AI 에이전트를 감싸서 무엇까지 할 수 있는지, 결과를 어떻게 검증할지, 실패하면 어떻게 처리할지를 통제하는 층입니다. 에이전트에게 작업 공간 전체를 주는 대신 변경 제안만 받게 하고 반영은 사람이 검수한 뒤에 하도록 잠그는 장치가 여기 속합니다.

[비유] 공항을 떠올리시면 쉽습니다. 누구나 여행 계획을 세우고 짐을 쌀 수 있게 되었다고 해서(AI로 만들기가 쉬워짐) 보안 검색대가 사라지지는 않습니다. 오히려 승객이 늘수록 검색대는 더 중요해집니다. 이 문서의 방법론은 SI/SM 회사의 검색대를 더 빠른 승객 흐름에 맞게 다시 지으면서, 검색대를 통과하는 조건을 단계적으로 넓히는 방법입니다.

1. 한눈에 보기

1.1 한 문단 요약

SI/SM 대기업의 AX를 “어떤 AI 도구를 몇 명에게 나눠 줄 것인가”로 설계하면 아정당 자료가 보여 준 실패 모양을 그대로 따라갈 가능성이 큽니다. 자료가 반복해서 보여 준 것은 도구의 우열이 아니라, 경계를 허문 조직이 무엇을 아래로 내리지 않았는가였습니다. 전략 결정은 위에 남았고, 게이트는 줄지 않고 오히려 좁아졌으며, 책임은 AI가 만든 산출물이라도 만든 사람에게 남았습니다. 그래서 이 방법론은 순서를 뒤집습니다. 먼저 게이트와 책임 규칙을 AI 속도에 맞게 다시 짓고, 그 위에서 AI의 자율성을 업무별·위험별로 단계적으로 넓히고, 그 효과를 산출량이 아니라 성과와 안전선으로 재며, 확인된 만큼만 계약과 평가와 조직에 반영합니다.

1.2 한 장 요약표

질문	이 방법론의 답
어디서부터 시작하나	도구 배포가 아니라 기반(보안 환경, 데이터와 문서, 권한과 로그, 법과 계약 점검)과 책임 규칙입니다
어디에 AI를 넣나	SI와 SM의 업무를 가치흐름 단계로 쪼개고, 단계마다 위험을 분류해 넣습니다
얼마나 맡기나	다섯 단계의 자율성 사다리(금지, 읽기, 제안, 승인 후 실행, 사전 승인 범위 내 자동 실행)에서 업무와 위험의 조합마다 상한을 정합니다
무엇으로 막나	여덟 개의 게이트(입력, 명세, 변경, 검증, 배포, 고객, 운영, 학습)를 사람 확인, 시스템 차단, 배포 리듬 세 방식으로 조합합니다
누가 책임지나	요청하고 트리거한 사람이 산출물을 책임집니다. 승인이 책임을 옮기지 않습니다
조직은 어떻게 하나	직군과 직함을 합치지 않고 역할 언어를 얹습니다. 전담팀은 대신 만들어 주지 않고 게이트와 도구를 제공하는 플랫폼 역할을 맡습니다
무엇으로 재나	코드 줄 수나 사용량이 아니라 흐름, 품질, 경제를 함께 보고, 절대 나빠지면 안 되는 안전선(가드레일 지표)을 먼저 정합니다
계약은 언제 바꾸나	파일럿에서 데이터를 쌓은 뒤 선택합니다. 계약 모델을 먼저 바꾸라고 권하지 않습니다
어떻게 퍼뜨리나	도구를 나눠 주는 방식이 아니라 업무 흐름의 트리거에 심고, 프로젝트와 서비스마다 챔피언을 둡니다
개발 일은 어떻게 AI에게 맡기나	AI가 질문하고 계획하되 사람이 명세와 변경을 승인하는 AIDD의 절차를 게이트 위에 놓습니다. 프롬프트와 SKILL은 요청이고, 강제는 권한과 CI가 합니다(14장, 부록 D, E)

1.3 방법론의 전체 구조

방법론은 기반, 네 개의 설계 축, 운영 루프로 이루어집니다. 기반이 없으면 축이 서지 않고, 축이 설계되면 루프를 돌리면서 승급과 확산을 판단합니다. 운영 중 사고가 나거나 모델과 도구가 바뀌면 게이트 설계로 되돌아가 다시 점검합니다.

flowchart TB
  subgraph FOUNDATION["기반: 먼저 깔아야 하는 것"]
    F1["보안과 환경: 망분리, 고객 보안 조항"]
    F2["데이터와 문서: AI가 읽을 수 있는 형태"]
    F3["플랫폼: 권한, 로그, 하네스"]
    F4["법과 계약 점검"]
  end
  subgraph AXES["설계의 네 축"]
    A1["축1 가치흐름: 어디에 넣는가"]
    A2["축2 게이트: 무엇으로 막고 누가 책임지는가"]
    A3["축3 사람: 어떤 역할로 일하는가"]
    A4["축4 측정과 계약: 어떻게 증명하고 연결하는가"]
  end
  subgraph LOOP["운영 루프"]
    L1["파일럿"]
    L2["승급 심사"]
    L3["확산"]
    L4["제도화"]
  end
  F1 --> A2
  F2 --> A1
  F3 --> A2
  F4 --> A4
  A1 --> A2
  A2 --> A3
  A3 --> A4
  A4 --> L1
  L1 --> L2
  L2 --> L3
  L3 --> L4
  L2 -.->|"기준 미달이면 등급 유지"| L1
  L4 -.->|"사고나 모델 교체 시 재검토"| A2

1.4 이 방법론이 하지 않는 것

세 가지를 먼저 분명히 해 두겠습니다.

첫째, 직군과 직함을 없애는 프로그램이 아닙니다. 아정당 자료는 직함을 합친 회사는 늘었지만 제너럴리스트만으로 굴러가는 조직은 없었다고 정리합니다. 레브잇은 세 단계에 걸쳐 전문가 층을 다시 세웠고, 메타는 직군 통합과 인력 축소를 함께 밀다가 계획의 일부를 되돌렸습니다.

둘째, 도구 보급 프로그램이 아닙니다. 자료는 도구만 나눠 주는 확산이 아무도 쓰지 않는 결과로 끝난 사례를 기록합니다.

셋째, 인력 감축 프로그램이 아닙니다. 이 방법론은 인력 구조를 건드리지 않고도 게이트, 측정, 계약을 먼저 정비할 수 있게 설계했습니다. 인력 구조에 관한 결정은 13장의 결정 지점으로 남겨 두었습니다.

2. 출발점: 아정당 자료에서 가져온 것과 가져올 수 없는 것

2.1 자료의 두 가지 결론

아정당 문서가 내린 결론은 둘입니다. 첫째, 직군을 없앤 곳으로 알려진 회사들을 원문까지 읽어 보면 제너럴리스트만으로 굴러가는 조직은 어디에도 없었습니다. 둘째, 경계를 허문 조직이 공통으로 남겨 둔 것은 권한이 아니라 게이트였습니다. 문서는 조사한 24건 가운데 전략 결정을 아래로 내린 사례도, 게이트를 완화한 사례도 없었다고 정리합니다.

이 두 결론에는 “조사한 24건 안에서는”이라는 범위가 붙어 있습니다. “세상 어디에도 없다”가 아니라 “이번에 원문까지 읽은 사례 중에는 없었다”로 읽어야 정확합니다. 이 점은 방법론을 설계할 때도 지켜야 하는 태도입니다.

2.2 방법론이 가져오는 여덟 가지 원칙

아정당 자료와 보강 자료에서 반복된 내용을 여덟 가지 원칙으로 추렸습니다. 원칙마다 근거의 강도를 함께 표기했으니, 강도가 약한 원칙은 파일럿에서 먼저 확인하시기 바랍니다.

번호	원칙	근거	강도	SI/SM에서의 뜻
P1	게이트는 줄이지 않고, 좁히거나 옮기거나 강화한다	epilot은 CI를 우회한 배포 사고 뒤 “접근을 열기 전에 머지와 푸시 권한을 잠가라”고 적었고, 팀스파르타는 배포가 폭증하자 상시 배포를 하루 2회 정기 배포로 좁히고 E2E 테스트를 붙였으며, 채널톡은 개발자 2명 리뷰를 필수로 두고 디자이너에게 머지 권한을 주지 않았다	강	이미 있는 검수, 감리, 변경관리를 없애지 않고 AI 속도에 맞게 다시 짠다
P2	전략과 약속은 위에서, 구현의 자율성은 아래로	문서는 24건 중 전략 결정을 아래로 내린 사례가 없다고 정리. 왓낫은 “구현의 자율성은 있으나 전략의 자율성은 없다”고 적었다	중	고객과의 계약, 범위, 가격, 일정 약속은 위에 남기고, 구현 방식과 도구 선택의 자율은 현업에 둔다
P3	책임은 만든 사람에게. AI가 만든 것도 예외가 없다	PostHog는 승인이 책임을 옮기지 않는다고 규정, 왓낫은 AI로 만든 코드나 분석도 만든 사람이 품질을 책임진다고 기록	약	AI 산출물의 품질은 요청하고 트리거한 사람이 책임진다. 리뷰어는 리뷰 절차를 수행할 책임을 진다
P4	전문가 층은 다시 세워진다. 직함을 합치기 전에 역할 언어부터	레브잇은 세 단계에 걸쳐 직군을 다시 분화, 마이리얼트립은 직군을 합치면서도 도메인 담당을 남김, PostHog CEO는 PM 없이 가겠다던 생각이 틀렸다고 번복	중	아키텍트, 운영 전문가, 보안 담당 같은 전문가 층을 줄이는 방향이 아니라 AI와 함께 일하도록 재정의한다
P5	인프라를 먼저 깔고 선언은 나중에	듀오링고는 AI 퍼스트 메모 뒤 CEO가 링크드인에서 메시지가 명확하지 않았다고 인정했고, 메타는 인력 축소와 직함 변경을 동시에 밀다 5월 2차 계획을 취소했다	강	보안 환경, 권한, 로그, 법무 검토 없이 “AI를 쓰자”를 선언하지 않는다
P6	산출량이 아니라 성과와 안전선으로 잰다	메타의 사내 데이터에서 변경량은 220% 늘었지만 사용자에게 도달한 기능은 36% 증가에 그쳤고, METR의 무작위 대조 실험에서 숙련 개발자는 AI를 쓰고 19% 더 오래 걸렸지만 스스로는 빨라졌다고 믿었다	강	코드 줄 수, PR 수, 사용량을 성과 지표로 쓰지 않는다
P7	전담팀이 대신 만들어 주면 병목이 된다	마이리얼트립은 2024년에 신설한 AI랩을 2026년 5월에 종료했고, 문서는 세 회사가 같은 한계에 부딪혔다고 정리	약	AX 조직은 게이트와 도구를 제공하는 플랫폼이어야 하고, 현업 대신 만들어 주는 조직이 되지 않는다
P8	결과가 아니라 조건을 대조한다	문서가 소개한 당근 리더의 당부. PM 극소화는 고객이 개발자이고 규모가 작고 채용 기준이 극단적으로 높은 조직에서 나왔다	약	사례를 가져올 때 규모, 고객, 전제 조건이 우리와 같은지 먼저 대조한다

메타와 듀오링고, 마이리얼트립의 AI랩 종료, epilot의 사고, 팀스파르타의 정기 배포, 채널톡의 리뷰 구조, METR 실험은 앞선 해설 작업에서 제가 외부 자료로 다시 확인했습니다. 반대로 PostHog의 승인 규칙과 왓낫의 책임 문장, 세 회사의 전담팀 병목, 당근 리더의 당부는 문서에 적혀 있으나 확인하지 못해 약으로 표기했습니다.

[한계] 메타의 수치는 Reuters 조사 보도를 인용한 2차 기사에서 확인했습니다. METR 연구는 2025년 초 도구와 대형 오픈소스 저장소를 대상으로 한 16명의 실험이고, 연구진도 도구의 발전으로 결과가 달라질 수 있다고 밝혔습니다. “AI는 모든 개발자를 느리게 한다”로 일반화하면 안 됩니다. 이 문서는 METR 결과를 “체감과 실측이 어긋날 수 있다”는 경고로만 씁니다.

2.3 가져올 수 없는 것: 제품 조직과 SI/SM의 구조 차이

아정당 자료의 사례를 SI/SM에 옮길 때 가장 먼저 부딪히는 것은 구조의 차이입니다. 아래 표는 [풀이] 입니다. 회사마다 다르므로 일반적인 경향으로 읽어 주십시오.

항목	제품 조직(아정당 자료의 사례)	SI/SM 조직
고객	불특정 다수 사용자 또는 자사 사업부	계약으로 묶인 특정 고객사
요구사항의 소유	자사가 정함. 전략은 위에서	고객이 정하거나 고객과 협의. 범위 변경도 계약 사안
산출물	동작하는 제품	코드에 더해 설계서, 테스트 결과서, 운영 문서 같은 계약상 산출물
품질 확인	내부 리뷰와 배포 후 지표	내부 리뷰에 더해 고객 검수, 감리, 인수 절차
대가	제품 매출	계약 대가. 국내에서는 개발비에 기능점수 방식, 운영과 유지관리비에 투입공수 방식을 쓰는 기준이 있음(3.2절)
개발 환경	자사가 정함	고객사 보안 규정, 망분리, 상주 근무 환경의 제약을 받음
인력 구성	자사 직원 중심	자사 직원, 협력사 인력, 고객사 인력이 섞임
운영	장애는 자사 서비스의 문제	SLA 위반은 계약 위반, 고객 시스템의 장애
되돌리기	서비스 롤백	고객 시스템과 데이터, 계약 상의 책임이 얽힘

[풀이] 이 표가 말하는 것은 두 가지입니다. 하나는 SI/SM에는 이미 무거운 게이트가 제도로 존재한다는 점입니다. 고객 검수, 감리, 변경관리 절차가 그것입니다. 아정당 자료의 사례들이 게이트를 새로 지어야 했던 것과 출발점이 다릅니다. 다른 하나는 책임의 상대가 고객과 계약이라는 점입니다. 그래서 아정당 자료의 “책임은 만든 사람”이라는 원칙은 SI/SM에서 “만든 사람 → 팀 → 회사 → 고객 계약”으로 이어지는 사슬로 다시 써야 합니다.

2.4 어떤 사례가 SI/SM에 가장 가까운가

문서가 5.4절에서 정리한 조건 표를 SI/SM에 대어 보면, 가장 가까운 모델은 전방 배치 엔지니어(FDE) 모델입니다. 문서는 이 모델을 “대형 계약 B2B, 정부·엔터프라이즈 고객, 재사용 플랫폼, 산출물을 제품화하는 별도 팀, 큰 계약 규모”의 조건에서 작동한 것으로 정리하고 팔란티어, OpenAI, Ramp를 사례로 듭니다. 이 사례들은 모두 제가 외부에서 확인하지 못한 항목이라 약입니다. 다만 삼성SDS가 2026년 9월 행사에서 AX 전문 FDE 인력을 연내 200여 명 규모로 늘리겠다고 밝힌 것으로 보도되어(CIO Korea), 국내 IT서비스 기업이 이 모델을 참고하고 있다는 정황은 있습니다.

반대로 가장 멀리 있는 모델은 PM 극소화입니다. 이 모델이 작동한 조직은 개발자나 제품팀을 고객으로 둔 200명 이하의 소프트웨어 회사였고(왓낫만 예외), 고객이 계약으로 범위와 일정을 정하는 SI/SM과는 조건이 맞지 않습니다. 직군 통합도 조건이 다릅니다. 수천에서 수만 명 규모의 대형 조직에서는 아마존과 메타가 사업부 단위 시범에 그쳤고 전사 확대는 두 곳 모두 하지 않았습니다.

[풀이] 결론은 이렇습니다. SI/SM 대기업이 아정당 자료에서 안심하고 가져올 수 있는 것은 게이트, 책임, 측정, 인프라 선행에 관한 원칙입니다. 조심해서 가져와야 하는 것은 사람 구조(직군 통합, PM 축소)에 관한 사례입니다. 8개 원칙이 게이트와 측정 쪽에 몰려 있는 이유입니다.

3. SI/SM 업계의 최신 동향 (2026년 10월 기준 직접 확인한 것)

방법론이 현실과 맞는지 보려면 업계가 지금 무엇을 하고 있는지 알아야 합니다. 이 장은 제가 원문을 열어 확인한 내용만 적었습니다. 확인하지 못한 것은 3.5절에 따로 모았습니다.

3.1 국내 IT서비스 대기업의 공개된 움직임

회사	시점	공개 내용	수치 공개 여부
삼성SDS	2026-05-29 (AX 서밋), 2026-09-08 (REAL Summit)	고객사용 에이전트 플랫폼 FabriX 2.0 발표(당시 기사는 2026년 10월 출시 예정), 우리은행 프로젝트에서 금융 특화 에이전트 300개 이상 구축 목표(내년 하반기까지). AX 성공 요소로 프로세스 재설계, AI 활용 가능한 데이터 정비, 다수 에이전트 운영(Agent Ops), AI 거버넌스, AI 보안, AI 친화적 조직, 기업문화 변화의 일곱 가지를 제시. ‘클라이언트 제로’ 전략으로 사내 7대 메가 프로세스(개발, 구매, 품질, 경영지원, 사업이행, 마케팅, 영업)에 AI 적용을 검토. 권한, 보안, 비용 통제와 보안 거버넌스의 필요성을 언급	기사 기준으로 단기 시간 절감이나 인력 감소 수치는 제시하지 않았음
LG CNS	2026-06-08	‘데브온 에이전틱 AIND’ 공개(미국 오픈소스 AI 코딩 기업 Cline과 공동 개발). 역할별 에이전트가 분석·설계, 코딩, 테스트·품질 검증을 협업하고, 사용자는 자연어로 요구사항을 입력한 뒤 결과를 검토·승인. 개발 표준, 보안 규정, 소스코드, 산출물을 AI가 이해하도록 구조화한 지식 기반을 핵심으로 쓰고, 사전에 정한 명세에 따라 설계·코딩·검증하는 스펙 주도 개발을 적용. 바이브 코딩의 한계를 지적. COBOL을 Java로 자동 전환하는 기능을 국내 대형 금융사 차세대 프로젝트에 적용 중이라고 밝힘	기존에 “수 주 이상” 걸리던 코드 분석·변환·검증을 “분 단위”로 줄일 수 있다고 하나 구체적 비율은 없음
SK AX	2026-03-19, 2026-10-01	에이전틱 AI와 기업 구조 재설계(Rewire)를 결합한 ‘AXgenticWire’ 브랜드 공개(멀티 에이전트 운영, AI 리더블 데이터, 기존 AI Ops 역량 기반). ‘AI Software Engineering’ 서비스 소개 페이지에 요구사항 분석, 코드 생성, 테스트 시나리오 생성, 현행 시스템 분석, 진척 지표 관리 기능을 나열. 10월 1일에는 개발 조직 외 전 직군을 대상으로 한 4주 과정의 ‘AI 부트캠프 바이브’(바이브 코딩으로 에이전트를 만드는 교육) 출시를 발표	AXgenticWire 발표에 SK AX의 생산성 수치 없음. 서비스 페이지에도 정량 수치와 근거가 없음
KT와 KT DS	2026-10 (AID-X Day, 10월 14~15일 보도)	KT가 KT DS와 공동 구현한 AI 개발체계 ‘kode’를 소개. AI가 코드 구현과 검증을 지원하고, 사람이 요구사항과 설계 방향을 정해 최종 품질을 확인하는 방식	KT는 한 프로젝트의 개발 기간이 9개월에서 6개월로 줄었다고 밝혔으나, 기사에서 kode의 기여분과 분리되어 있지 않음. 같은 기사에 KT DS 자체의 AX 발표는 없음

출처: SK AX 보도자료, SK AX AI Software Engineering, 바이라인네트워크(SK AX 부트캠프), 머니투데이방송(삼성SDS AX 서밋), CIO Korea(삼성SDS REAL Summit), LG 보도자료, 스마트투데이(KT).

[풀이] 읽을 점이 세 가지 있습니다.

첫째, LG CNS와 KT의 공개 설명에는 “사람이 요구사항을 정하고 결과를 검토·승인한다”는 구조가 명시되어 있습니다. 앞서 본 게이트의 사람 확인 방식과 같은 방향입니다. 삼성SDS는 AI 거버넌스와 AI 보안을 AX 성공 요소로 꼽았고, 권한과 보안과 비용 통제의 필요성을 언급했습니다. 다만 이것이 구체적인 게이트 구조(리뷰 인원, 머지 권한 등)로 공개된 것은 아닙니다.

둘째, LG CNS가 개발 표준과 보안 규정과 산출물을 AI가 읽을 수 있게 구조화한 지식 기반을 핵심으로 삼은 점은, 아정당 자료의 “팀의 지식이 AI의 연료였다”는 서술과 같은 방향입니다. 이 방법론의 기반 중 데이터와 문서 항목과 맞닿습니다.

셋째, 삼성SDS의 ‘클라이언트 제로’(자기 회사 안에서 먼저 쓰기)와 SK AX의 전 직군 교육은 방식 차이는 있어도 모두 고객에게 팔기 전에 내부에서 먼저 일하는 방식을 바꾼다는 방향입니다.

[한계] 네 곳 모두 제가 확인한 공개 자료에는 독립적으로 검증할 수 있는 생산성 수치, 게이트 구조(리뷰 인원과 머지 권한), 평가·승진·계약 변경의 구체적 내용이 나오지 않습니다. 보도자료와 서비스 소개 중심이기 때문입니다. 공개되지 않았다는 뜻이지, 내부에 없다는 뜻이 아닙니다. LG CNS의 “분 단위”와 KT의 “9개월에서 6개월”은 회사가 밝힌 수치이고 조건과 측정 방법은 확인하지 못했습니다. SK AX 서비스 페이지가 쓰는 “Global Top 10” 같은 표현도 순위의 근거가 제시되지 않았습니다. 이 수치들을 근거로 효과를 예단하지 않았습니다.

3.2 대가산정과 계약

SI/SM의 돈은 계약에서 나옵니다. 그래서 AI가 투입 공수를 줄이면 대가에 어떤 영향이 있는지를 보아야 합니다.

[근거] (강도 중) 한국인공지능·소프트웨어산업협회(KOSA)가 2025년 8월 11일 공표한 ‘SW사업 대가산정 가이드’ 개정판은 다음을 담았습니다(바이라인네트워크).

지난해 신설한 AI 도입 대가체계의 ‘전문작업비’를 ‘커스터마이징 작업비용’으로 바꾸고, 커스터마이징 사업 유형을 기본형, 데이터형, 모델형으로 나눠 작업 항목을 명시했습니다.
개발비는 기능점수 방식으로, 운영과 유지관리비는 투입공수 방식으로 각각 산정한 뒤 합산하는 기준을 마련했습니다.
지난 5월 관계부처 합동 혁신방안을 반영해 대규모 정보화 사업을 모듈화하고, 단계적 개통과 데브옵스 방식의 확대를 예상했습니다.

[근거] (강도 중) 과학기술정보통신부는 2026년 5월 28일 ‘AI·SW사업 대가체계 개선 TF’를 구성하고 첫 회의를 열었습니다. 생성형 AI와 AI 에이전트의 확산으로 기존 대가산정 방식을 바꿔야 한다는 요구가 커졌고, 업계에서는 AI 사업이 도입 후에도 지속적인 학습과 고도화가 필요해 기능점수 방식으로는 온전히 반영하기 어렵다고 본다고 합니다. 또 AI 개발도구 활용으로 개발 생산성이 높아지고 있다는 의견도 있다고 전합니다. 확정된 변경안은 없고 중장기적으로 개선 방향을 논의하겠다는 단계입니다(바이라인네트워크).

[풀이] (가설) 이 두 사실을 이어 읽으면 다음과 같은 구조적 긴장이 보입니다. 개발비가 기능점수에 따라 정해진다면 대가는 투입 공수와 분리됩니다. AI로 개발 공수가 줄어들면 줄어든 만큼이 수행사의 이익 쪽으로 갑니다. 반면 운영과 유지관리비가 투입공수에 따라 정해진다면 AI로 공수가 줄 때 대가도 줄어드는 압력을 받을 수 있습니다. 그러면 SM 조직은 AI를 도입할수록 매출이 줄 수 있어 도입 동기가 약해질 수 있습니다. 다만 실제 계약은 사업마다 다르고, 이 해석을 입증하는 공개 자료를 확인하지는 못했습니다. 방법론에서는 이를 가설로 두고 파일럿에서 확인하도록 설계했습니다(11장).

[근거] (강도 약~중, 해외) 컨설팅 자문사 UpperEdge의 2026년 8월 18일 기고문은 Accenture의 전체 업무 가운데 약 60%가 고정가 계약이며 3년간 약 10%포인트 높아졌다고 전하고, 저자는 AI로 투입 공수가 줄어드는 상황에서 시간당 과금(T&M) 모델은 공수 감소가 고객에게 그대로 드러나 가격 논쟁이 생길 수 있어 SI 측이 고정가로 옮겨 가고 있다고 해석합니다(UpperEdge). [한계] 이 글은 자문 서비스를 홍보하는 성격도 있고, 수치 대부분이 기업 실적 발표를 인용한 것이며, “AI 효과가 분석가 전망(ERP 공수 40~50% 절감)의 절반 미만”이라는 주장은 저자의 관찰에 근거한 것으로 측정 방법이 제시되지 않았습니다. 해외 동향의 참고로만 쓰고 국내 계약에 대입하지 않았습니다.

3.3 규제와 보안

[근거] (강도 중~강) 인공지능 기본법과 시행령은 2026년 1월 22일에 시행되었습니다. 사업자는 AI를 개발해 제공하는 인공지능개발사업자와, 그것을 이용해 제품이나 서비스를 제공하는 인공지능이용사업자로 나뉘고, 한 사업자가 여러 지위를 겸할 수 있습니다. 채용이나 대출심사처럼 생명, 신체 안전, 기본권에 중대한 영향을 줄 수 있는 영역의 고영향 AI 사업자와 생성형 AI 사업자에게는 이용자에게 사전 고지하고 생성물을 표시하는 투명성 의무가 있으며, 고영향 AI 사업자에게는 위험관리방안, 설명 방안, 이용자 보호 방안과 사람이 관리·감독하는 체계가 요구됩니다. 사실이 명백한 경우나 내부 업무용으로만 쓰는 경우에는 의무가 전부 또는 일부 면제됩니다. 과기정통부는 규제 적용을 최소 1년 이상 유예하고 계도 기간을 운영하기로 했으며, 사실조사와 과태료는 인명사고나 인권 훼손처럼 중대한 사회적 문제가 생긴 극히 예외적인 경우에만 하겠다고 밝혔습니다(세종 뉴스레터, 2026-02-11).

[풀이] SI에서는 이 법이 두 층위로 작용합니다. 하나는 수행사가 AI 도구를 써서 개발하는 층위이고(내부 업무용 면제 범위가 관련될 수 있음), 다른 하나는 수행사가 고객을 위해 구축하는 시스템이 AI를 포함하는 층위입니다. 구축 대상이 채용이나 대출심사 같은 고영향 영역이라면 고객과 수행사 사이의 책임 구분이 계약 사안이 됩니다. 이 방법론은 법률 자문이 아니므로 어떤 사업이 어디에 해당하는지는 법무 검토가 필요합니다.

[근거] (강도 중) 금융위원회는 2026년 7월 15일 하반기 업무보고에서 금융권 망분리 규제의 전면 해제를 추진하겠다고 밝혔습니다. 금융회사가 외부 AI 모델과 클라우드, SaaS를 더 폭넓게 쓸 수 있게 하는 방향이고, 해킹과 침해사고 시 금융회사와 외부 IT업체의 책임을 나누기 위해 디지털금융안전법을 제정할 방침입니다. 기사에는 구체적 시행 시기가 없고, 생성형 AI가 고객정보와 신용정보를 활용하거나 외부 사업자에게 데이터를 넘길 수 있는 범위는 향후 세부 기준에서 정하기로 했다고 합니다(디지털데일리).

[근거] (강도 중) 공공 부문에서는 국가정보원이 2025년 9월 N²SF 가이드라인으로 업무정보시스템과 데이터를 중요도에 따라 C·S·O 등급으로 나눠 등급별 보안체계를 적용하는 틀을 제시했고, 이 틀에서 생성형 AI 활용, SaaS 기반 업무협업, 업무단말 인터넷 이용을 포함한 11개 정보서비스 모델을 제시했다고 합니다. 보안 업체 소만사의 2025년 11월 분석 리포트는 외부 생성형 AI나 클라우드를 쓰기 전에 필요한 최소 보안기준을 정리했습니다(바이라인네트워크).

[한계] 금융 망분리 전면 해제는 “추진” 단계이고 시행 시기가 확인되지 않았습니다. 이 방법론은 규제가 완화되더라도 고객사별 보안 조항과 내부 정책에 따라 AI 사용 환경이 달라진다는 전제로 설계했습니다. 규제 상태가 바뀌면 기반 단계(5.1절)의 환경 정의를 갱신해야 합니다.

3.4 생산성과 품질에 관한 독립 근거

AX 방법론은 효과에 대한 낙관과 비관을 모두 경계해야 합니다. 업체의 발표가 아닌 연구와 측정 자료를 모았습니다.

출처	대상과 방법	핵심 결과	조심해서 읽을 점
DORA 2025 보고서 (Google, 2025년 9월)	소프트웨어 개발자 대상 설문	응답자의 90%가 AI를 쓰고(전년 대비 14% 증가로 소개됨), 80% 이상이 생산성이 올랐다고 답했으며, AI를 “많이” 또는 “매우 많이” 신뢰한다는 응답은 24%, “조금” 또는 “전혀”는 30%. AI 도입은 전달 처리량 증가와 연관되었으나 전달 불안정성은 계속 증가. 보고서는 AI를 “거울이자 증폭기”로 설명하며, 협업이 잘 되는 조직에서는 효율을 높이고 분절된 조직에서는 약점을 드러낸다고 정리	설문 기반이라 체감 응답이 섞여 있음
Faros AI 「AI Productivity Paradox」 (2025년 6월 기준 분석)	개발자 1만 명 이상, 팀 1,255개의 업무 도구 텔레메트리	AI 도입이 많은 팀의 개발자는 과제를 21% 더 많이 완료하고 병합된 PR이 98% 더 많았으나, PR 리뷰 시간이 91% 증가, 개발자당 버그가 9% 증가. 조직 수준에서는 AI 도입과 개선 사이에 유의미한 상관을 관찰하지 못함	상관 분석이며 인과를 입증한 것이 아님. AI 도입 최저 두 분기와 최고 두 분기를 비교한 방식
METR (2025년 7월)	숙련 오픈소스 개발자 16명, 실제 과제 246개의 무작위 대조 실험	AI를 쓴 과제가 19% 더 오래 걸렸는데, 개발자는 사전에 24% 빨라질 것으로 예상했고 사후에도 약 20% 빨라졌다고 믿음	2025년 초 도구와 대형 저장소, 표본 16명. 연구진이 결과가 달라질 수 있다고 밝힘
Veracode 「2025 GenAI Code Security Report」 (2025년 7월 30일)	100개 이상의 LLM에 80개의 코드 완성 과제를 주고 보안 결과를 검사	전체 테스트 사례의 45%에서 보안 취약점이 생김. Java는 70% 이상 실패, Python과 C#과 JavaScript는 38~45%. 크로스 사이트 스크립팅 방어에서 86%, 로그 주입 방어에서 88% 실패	안전한 방식과 위험한 방식 중 고르게 하는 과제 설계이고, 2025년 모델 기준. 자사 보안 제품을 파는 회사의 보고서
Gartner (2025년 6월 25일)	2025년 1월 웨비나 참석자 3,412명 설문과 자체 분석	2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 예측. 이유는 비용 증가, 불분명한 사업 가치, 부적절한 리스크 통제. 수천 개 벤더 가운데 실제 에이전트 역량을 가진 곳은 약 130개로 추정하며 기존 제품을 이름만 바꾸는 “에이전트 워싱”을 지적	설문 대상이 웨비나 참석자라 전체 기업을 대표하지 않음. 예측이지 실측이 아님
메타 사내 데이터 (Reuters 조사 보도를 인용한 기사, 2026년 8월 26일)	사내 소프트웨어 플랫폼과 인프라	변경량 1년간 220% 증가, 사용자 도달 기능은 36% 증가. 사고 40% 증가, 해결 시간 70% 증가로 보도됨	2차 기사 인용. 같은 보도에서 메타는 “전체 인력 60% 감축 계획”이라는 해석을 부인했음(앞선 해설 문서의 D8)

출처: Google DORA 소개, InfoQ, Faros AI, DX의 METR 해설, The Decoder, Veracode 보도자료, Gartner 보도자료, Mezha.

[풀이] 이 표가 일관되게 가리키는 것은 개인과 팀 단계의 속도 이득이 조직의 성과로 이어지는 중간에 병목이 있다는 점입니다. Faros는 리뷰 시간 증가를 병목으로 짚고, DORA는 불안정성 증가를, 메타는 변경량과 사용자 도달의 격차를 보여 줍니다. 이는 아정당 자료의 첫 번째 실패 유형(산출량과 성과의 괴리)과 같은 방향입니다. 방법론이 게이트의 처리 용량(특히 리뷰 용량)을 설계 대상으로 삼는 이유입니다(6.5절).

3.5 이번에 확인하지 못한 것

이 방법론을 읽을 때 아래의 빈칸을 염두에 두시기 바랍니다.

국내 SI/SM 대기업이 AI 활용 이후 실제로 투입 공수, 대가, SLA를 어떻게 바꿨는지에 관한 공개 자료는 확인하지 못했습니다.
SM 영역에서 AI 에이전트가 운영 조치를 자동 실행해 정량 성과를 낸 SM 사업자의 공개 사례는 확인하지 못했습니다. 확인한 운영 사례는 통신사의 네트워크 운영(SK브로드밴드의 AI 관제·진단 에이전트가 이상 징후를 탐지하고 원인 분석과 점검 우선순위를 정해 담당자에게 보고서를 보내며, 향후 자율 복구 에이전트로 확대할 계획이라는 내용, KT의 네트워크 자율운용 플랫폼 등)이고 SM 사업자의 사례가 아닙니다(디지털데일리, 2026-07-22). 같은 기사는 데이터가 불완전하거나 흩어져 있으면 분석 정확도가 떨어지고 AI 판단 근거를 사람이 이해하기 어렵다는 설명 가능성 문제를 과제로 꼽습니다.
협력사와 상주 인력의 AI 사용을 어떻게 관리하는지에 관한 공개 자료는 확인하지 못했습니다.
삼성SDS FabriX 2.0의 출시 여부와 우리은행 프로젝트의 진행 상황은 확인하지 못했습니다.
금융 망분리 전면 해제의 시행 시기, 과기정통부 TF의 결론은 확인되지 않았습니다.

4. 방법론 개요: 게이트 우선 AX

4.1 정의와 목표

게이트 우선 AX는 SI/SM 조직이 AI를 업무에 넣을 때 게이트와 책임 규칙을 먼저 정비하고, 그 위에서 AI의 자율성을 업무별·위험별로 단계적으로 넓히는 방식입니다.

성공의 정의는 이렇게 둡니다. [제안] 고객에게 닿는 품질, 보안, 책임이 도입 전보다 나빠지지 않은 채로, 흐름(리드타임과 대기)과 경제(총비용과 마진)가 개선됩니다. 이 정의는 일부러 “나빠지지 않은 채로”를 앞에 둡니다. 3.4절의 연구들이 보여 주듯, 속도 이득은 품질과 안정성의 비용을 치르며 얻어지는 경우가 많기 때문입니다.

4.2 네 개의 설계 축

축	핵심 질문	주요 산출물	소유자(제안)	상세
축1 가치흐름	AI를 어디에 넣는가	가치흐름 지도, 업무 단위 목록, 위험 분류표	사업부 AX 담당과 현업	4.4절, 7장, 8장
축2 게이트	무엇으로 막고 누가 책임지는가	게이트 카탈로그, 게이트 정의서, 자율성 상한표, 책임 규칙	게이트 오너와 AX 플랫폼팀	4.5절, 6장
축3 사람	누가 어떤 역할로 일하는가	역할 정의, 교육 과정, 평가 기준	인사와 사업부	9장
축4 측정과 계약	어떻게 증명하고 돈과 연결하는가	지표 체계, 베이스라인, 계약 옵션	PMO, 사업기획, 법무	10장, 11장

네 축은 순서가 있습니다. 가치흐름을 모르면 게이트를 놓을 자리를 모르고, 게이트가 없으면 사람의 역할을 정의해도 책임이 흐려지며, 측정 없이 계약을 바꾸면 근거 없는 도박이 됩니다. 이 순서는 아정당 자료의 다섯 번째 실패 유형인 인프라 없는 선언을 피하려는 설계입니다.

4.3 이 방법론이 쓰는 기본 단위

업무 단위는 가치흐름의 한 단계를 더 잘게 나눈 일의 조각입니다. 예를 들어 SI의 “개발” 단계는 단위 테스트 작성, 코드 리팩터링, 인터페이스 구현, 데이터 이관 스크립트 작성 같은 업무 단위로 나눕니다. 위험과 자율성은 단계 전체가 아니라 업무 단위마다 정합니다. 같은 “개발” 단계 안에서도 단위 테스트 작성과 결제 로직 변경의 위험은 전혀 다르기 때문입니다.

위험 등급은 업무 단위가 잘못되었을 때의 피해 크기를 네 단계로 나눈 것입니다.

자율성 등급은 AI(에이전트와 도구)가 시스템에 직접 할 수 있는 일의 범위를 다섯 단계로 나눈 것입니다.

게이트는 업무 단위의 결과가 다음 단계로 넘어가기 전에 지나는 확인 지점입니다.

4.4 업무 위험 분류

[제안] 업무 단위의 위험은 세 가지 질문으로 가립니다. 세 질문 가운데 가장 높은 값이 그 업무의 위험 등급입니다. 평균이 아니라 최댓값을 쓰는 이유는, 하나의 치명적 요소가 나머지의 안전으로 상쇄되지 않기 때문입니다.

질문	낮음	높음
영향 범위: 틀리면 어디까지 퍼지는가	내 작업 환경이나 내부 도구	고객의 운영 시스템과 최종 사용자
되돌림 난이도: 틀리면 얼마나 쉽게 되돌리는가	쉽게 롤백됨	데이터가 바뀌거나 불가역임
데이터 민감도: 어떤 데이터에 닿는가	공개 정보, 내부 일반 정보	고객 기밀, 개인정보, 신용정보 등 규제 대상

위험 등급	SI 예시	SM 예시	초기 자율성 상한(제안)
낮음	사내 도구 개발, 문서와 코드 요약, 고객 데이터가 없는 제안서 초안	조회성 문의의 답변 초안, 가이드 문서 검색	L3
보통	비운영 환경의 코드 변경, 테스트 케이스 생성, 설계서 초안	비운영 환경 재현, 알려진 오류의 조치 방법 제안	L3
높음	운영 반영 대상 코드 변경, 인터페이스 변경, 고객 운영 데이터 조회	장애 원인 분석, 운영 환경 조회, 운영 스크립트 작성	L2 (분석은 L1~L2)
매우 높음	개인정보와 신용정보를 처리하는 로직, 결제·정산·계약 관련 기능, 권한과 방화벽과 보안 설정	운영 DB 변경, 권한 변경, 보안 설정 변경	L1~L2, 환경에 따라 L0

표의 상한은 초기 제안일 뿐이며 파일럿 증거에 따라 조정합니다. 상한을 높게 잡을 수 있는 근거는 이 방법론이 요구하는 증거(가드레일 지표 유지와 사고 이력)이고, 처음부터 높은 값을 주는 것은 권하지 않습니다. 특히 매우 높음에 해당하는 영역은 아정당 자료의 확인된 사실 16번과 같은 맥락에서 신중해야 합니다. 문서는 “결제, 계약, 정산처럼 되돌리기 어려운 영역을 비개발 직군에 맡긴 회사는 확인되지 않았다”고 적습니다(강도 약, 앞선 해설에서 확인하지 못한 항목).

4.5 자율성 사다리

[제안] AI가 시스템에 직접 할 수 있는 일의 범위를 다섯 단계로 나눕니다.

flowchart TB
  L0["L0 금지: 환경이나 계약상 AI에 줄 수 없는 영역"]
  L1["L1 읽기: 분석, 요약, 설명만. 시스템에 쓰지 않음"]
  L2["L2 제안: 초안, 변경안, PR을 만들고 사람이 반영"]
  L3["L3 승인 후 실행: 사람이 승인하면 격리된 환경에서 실행"]
  L4["L4 사전 승인 범위 내 자동 실행: 정의된 저위험 작업, 사후 검증과 자동 복구"]
  L1 -->|"승급 심사"| L2
  L2 -->|"승급 심사"| L3
  L3 -->|"승급 심사"| L4
  L4 -.->|"가드레일 위반 시 즉시 강등"| L2
  L0 -.->|"환경이나 계약이 바뀌면 재평가"| L1

등급	뜻	사람의 역할	예시
L0	금지	해당 없음	고객 계약상 소스코드 외부 전송이 금지된 환경에서 외부 AI 서비스를 쓰는 것
L1	읽기	결과를 해석하고 판단	코드베이스 분석, 로그 요약, 문서 설명
L2	제안	제안을 검토하고 직접 반영	PR 생성, 설계서 초안, 조치 방법 제안
L3	승인 후 실행	실행 전에 승인하고 실행 결과를 확인	스테이징 환경에서의 스크립트 실행, 테스트 환경 구성
L4	사전 승인 범위 내 자동 실행	범위와 한계를 사전에 정의하고, 가드레일 지표와 사후 검증을 감독	사전에 정의된 저위험 반복 작업의 자동 처리

사다리를 운영하는 규칙은 다섯 가지입니다.

첫째, 등급은 사람이 아니라 업무 단위와 위험의 조합에 부여합니다. 같은 사람이 어떤 업무에서는 L3, 다른 업무에서는 L1일 수 있습니다.

둘째, 처음에는 L1~L2에서 시작합니다. L3 이상은 파일럿에서 증거를 쌓은 뒤 승급 심사를 거칩니다.

셋째, 승급은 증거로 합니다. 심사 항목은 해당 업무에서 게이트를 통과한 기록, 가드레일 지표의 유지, 사고 이력, 게이트의 처리 용량 여유입니다. 기간이나 건수 같은 구체적 기준값은 파일럿 설계 단계에서 정하며, 이 문서가 일반적인 값을 주장하지는 않습니다.

넷째, 강등은 즉시 합니다. 가드레일 지표가 선을 넘거나 사고가 나면 해당 업무의 등급을 내리고 원인을 분석한 뒤 게이트를 고쳐서 다시 올립니다. 아정당 자료에서 epilot은 개방 몇 주 뒤 전체 푸시 권한을 가진 비개발자가 CI를 우회해 리뷰 없이 프로덕션에 배포하는 일을 겪고 “운이 좋았다”고 적은 뒤 권한을 잠갔습니다(강도 강). 이 사례가 바로 사고 → 강등 → 게이트 개정의 흐름입니다.

다섯째, L3 이상은 고객 합의 범위를 확인합니다. 고객 시스템에 AI가 직접 쓰기를 하는 구간은 계약과 보안 조항의 범위 안에서만 가능합니다.

아정당 사례와의 근사 대응

[풀이] 아정당 자료에서 비개발 직군이 프로덕션 코드에 닿는 범위는 다섯 단계의 스펙트럼으로 정리됩니다. 이 스펙트럼은 사람의 권한 기준이고 위 사다리는 AI의 행동 범위 기준이라서 정확히 겹치지 않습니다. 아래는 어림 대응입니다.

사다리	아정당 자료의 근사 사례	해당 사례의 장치
L2	채널톡: 디자이너가 UI 스타일 수정 PR을 올림. epilot과 PostHog: 비개발자와 에이전트는 PR만 만들고 엔지니어가 리뷰하고 머지	개발자 2명 리뷰 필수, 머지 권한 없음, 보호 브랜치 직접 푸시 금지
L3	무신사: AI가 패치 파일을 제안만 하고 하네스가 통제, 사람이 검수한 뒤 반영(앞선 해설에서 확인하지 못함). 토스: 비개발자가 자연어로 어드민 화면을 만들고 필수 보안 정책은 플랫폼이 자동 적용(확인하지 못함)	하네스 경계, 플랫폼 정책 자동 적용
L4	마이리얼트립: 비개발 직군도 기본 변경은 직접 머지·배포. 레브잇: Problem Solver가 직접 배포하고 가드레일 지표로 중단과 롤백	구현 전 스펙 리뷰, 가드레일 지표와 점진 배포

[풀이] 이 대응에서 얻을 점은, 자율성이 높은 사례일수록 시스템 쪽 장치(스펙 선행 리뷰, 가드레일 지표, 점진 배포)가 두드러진다는 것입니다. 앞선 해설의 8.2절이 “권한을 가장 넓게 연 곳일수록 시스템 쪽 장치가 눈에 띈다”고 읽은 것과 같은 방향입니다.

5. 단계별 로드맵

방법론은 여섯 단계(단계0~단계5)로 진행합니다. 각 단계는 종료 게이트를 통과해야 다음 단계로 갑니다. 이 문서는 기간을 제시하지 않습니다. 조직의 규모와 고객 구성에 따라 크게 달라지기 때문에, 근거 없는 숫자를 주장하는 대신 종료 조건으로 단계를 정의했습니다.

flowchart LR
  P0["단계0 기반 구축"] -->|"기반 게이트"| P1["단계1 진단"]
  P1 -->|"진단 게이트"| P2["단계2 게이트 구축"]
  P2 -->|"설계 게이트"| P3["단계3 파일럿"]
  P3 -->|"승급 심사"| P4["단계4 확산"]
  P4 -->|"제도 반영 심사"| P5["단계5 제도화"]
  P3 -.->|"가드레일 위반 시"| P2
  P4 -.->|"온보딩 조건 미충족 시"| P2
  P5 -.->|"사고, 모델 교체, 규제 변경"| P0

5.1 단계0: 기반 구축

목적. 아정당 자료의 다섯 번째 실패, 곧 인프라 없는 선언을 피합니다. 듀오링고는 AI 퍼스트 메모 뒤에 CEO가 링크드인에서 메시지를 명확하게 전하지 못했다고 인정했고(강도 강), 메타는 직함 변경과 인력 축소를 동시에 밀다가 계획의 일부를 되돌렸습니다(강도 강). 이 단계의 원칙은 선언은 인프라 뒤에 한다입니다.

핵심 활동.

환경 정의. 고객, 프로젝트, 서비스를 보안 수준에 따라 분류하고, 환경마다 쓸 수 있는 AI 도구의 유형을 정합니다. 예를 들어 외부 AI 서비스를 쓸 수 있는 환경, 회사가 통제하는 환경 안에서만 쓸 수 있는 환경, AI 사용이 불가한 환경(L0)으로 나눕니다. 금융 망분리 규제 완화는 추진 단계이고 공공은 N²SF의 등급 체계를 따르므로(3.3절) 고객사 유형별로 별도의 정의가 필요합니다.
계약과 법 점검. 대표 계약 유형마다 소스코드와 데이터의 제3자 제공, 재위탁, AI 사용 고지에 관한 조항을 확인합니다. 인공지능 기본법상 고객에게 구축해 주는 시스템이 고영향 AI에 해당하는지도 법무가 검토합니다.
플랫폼 최소 기능 구축. 인증과 권한, 모든 AI 행위(입력, 출력, 실행)의 감사 로그, 비용 한도, 비밀 정보와 민감 데이터의 유출 방지, 승인된 도구 목록을 갖춥니다.
데이터와 문서 정비. 개발 표준, 아키텍처 문서, 산출물 템플릿, 운영 런북, 장애 이력을 AI가 읽을 수 있는 형태로 정리할 범위를 정합니다. 삼성SDS가 AX 성공 요소로 ‘AI 활용 가능한 데이터 정비’를 든 것, LG CNS가 개발 표준과 보안 규정과 산출물을 구조화한 지식 기반을 핵심에 둔 것이 같은 방향입니다(3.1절). DORA 2025 보고서의 AI 역량 모델도 “AI-accessible internal data”와 “Healthy data ecosystems”를 일곱 가지 역량에 포함합니다(강도 중, 단일 해설 자료로 확인).
책임 규칙 선포. 6.3절의 책임 규칙을 경영진이 승인하고 선포합니다. DORA의 역량 중 “Clear and communicated AI stance”(AI에 대한 명확하고 공유된 입장)와 맞닿는 활동입니다.

종료 게이트. 환경별 허용 도구 목록이 확정되고, 감사 로그가 작동하며, 책임 규칙이 공표되고, 법무와 보안의 검토가 끝난 상태.

흔한 함정. 도구를 먼저 사서 나눠 주고 인프라는 나중에 챙기는 것. 선언이 먼저 나가 현장에서 쓸 수 없는 환경이 드러나는 것.

5.2 단계1: 진단

목적. 어디에 AI를 넣을지, 지금 어떤 수준인지를 데이터로 파악합니다.

핵심 활동.

가치흐름 지도 작성. SI와 SM의 업무를 7장과 8장의 가치흐름으로 그립니다.
업무 단위 분해와 위험 분류. 4.4절의 기준으로 업무 단위마다 위험 등급을 붙입니다.
베이스라인 측정. 파일럿 후보가 될 업무의 현재 지표(리드타임, 결함 유출, 재작업, SLA 준수, 투입공수)를 AI 도입 전에 확보합니다. 앞선 해설에서 무신사는 면접 평가 자동화의 효과를 대조군 없이 단정하지 않고 “가설로 남긴다”고 기록한 것으로 소개되었습니다(강도 약). 베이스라인이 없으면 효과를 주장할 근거가 없습니다.
병목 지도 작성. 현재 게이트 가운데 처리 용량이 한계에 가까운 지점(코드 리뷰, 고객 검수, 변경관리 위원회, 감리)을 찾습니다. Faros의 분석은 AI 도입이 늘수록 리뷰 시간이 91% 늘었다고 보고했습니다(강도 중, 상관 분석).
파일럿 후보 선정. 다음 기준을 만족하는 후보를 고릅니다. (가) 허용 도구 환경에서 일할 수 있다, (나) 현재 지표를 측정할 수 있다, (다) 고객 합의가 가능하다, (라) 위험 등급이 다른 업무가 최소 둘 이상 포함된다, (마) 챔피언 후보가 있다.

종료 게이트. 파일럿 후보가 확정되고, 베이스라인이 확보되고, 위험 분류표가 승인된 상태.

흔한 함정. 베이스라인 없이 파일럿을 시작하는 것. 가장 쉬운 업무만 골라 성공 사례를 만드는 것.

5.3 단계2: 게이트 구축

목적. 파일럿에서 AI가 만든 결과가 고객에게 닿기 전에 지나는 지점을 AI 속도에 맞게 세웁니다.

핵심 활동.

게이트 선택. 6장의 게이트 카탈로그에서 파일럿 업무에 필요한 게이트를 고르고, 게이트마다 방식(사람 확인, 시스템 차단, 배포 리듬)과 소유자를 정합니다.
자율성 상한표 작성. 업무 단위마다 초기 등급 상한을 확정합니다.
리뷰 용량 계획. 리뷰어 수, 리뷰에 쓸 시간, 리뷰 대상의 크기 한도를 계획합니다. 버즈빌의 기술 블로그는 디자이너 PR이 늘면서 리뷰 부담이 엔지니어에게 옮겨 갔다고 적었습니다(회사 자체 서술, 앞선 해설 12.2절).
자동 검사 파이프라인 표준. 정적 분석, 의존성과 라이선스 검사, 비밀 정보 검사, 테스트를 자동으로 돌리고, 통과하지 못하면 머지가 불가능하도록 합니다. Veracode의 보고서에서 AI 생성 코드의 45%가 보안 취약점을 가졌다는 점을 반영합니다(3.4절).
사고 대응과 강등 절차. 4.5절의 강등 규칙을 절차로 만들고 모의 사고로 한 번 점검합니다.

종료 게이트. 게이트 정의서가 승인되고, 파이프라인이 가동되고, 모의 사고 점검이 끝난 상태.

흔한 함정. 규칙을 문서로만 두고 시스템이 막지 않는 것. 아정당 자료의 국내 네 회사(채널톡, 토스, 무신사, 당근)가 규칙을 설명하는 대신 어길 수 없게 만든 방식 B로 모인 것이 이 함정을 피하는 방향입니다(문서의 판단이며 “서로 참조 없이”라는 부분은 제가 확인하지 못했습니다).

5.4 단계3: 파일럿

목적. 설계한 게이트와 사다리가 실제로 작동하는지, 효과가 있는지를 증거로 확인합니다.

설계 원칙.

대상. SI 프로젝트(또는 단계) 한두 개와 SM 서비스 한두 개를 고르되 위험 등급이 서로 다른 업무를 섞습니다.
시작 등급. L1~L2에서 시작하고, 승급 심사를 통과한 업무만 L3로 시험합니다.
기간. 날짜가 아니라 완결된 주기로 정합니다. SI는 선택한 가치흐름 구간을 한 번 이상 끝까지(예를 들어 설계에서 테스트 완료까지), SM은 최소 한 번의 월간 SLA 보고 주기와 한 번의 변경 이행 주기를 포함하도록 합니다.
비교. 같은 시기 비파일럿 팀 또는 직전 주기와 비교합니다. 무작위 대조가 아니라는 한계를 보고서에 적습니다.
측정. 10장의 흐름, 품질, 경제 지표와 가드레일 지표를 함께 봅니다. 체감 조사와 실측을 병행합니다. METR 실험에서 체감(약 20% 빨라짐)과 실측(19% 느려짐)이 어긋난 사례가 있기 때문입니다(강도 강, 한계 있음).
기록. 반발, 불안, 이탈, 실패를 기록합니다. 아정당 자료가 스스로 밝힌 한계 중 하나가 “회사 채널은 성공 사례를 주로 게시하므로 이탈과 반발을 기록한 사례는 마이리얼트립, 레브잇, 메타뿐”이라는 점이었습니다. 파일럿 보고서가 같은 편향을 반복하지 않도록 실패와 이탈 기록을 의무 항목으로 둡니다.

종료 게이트. 승급 심사를 통과한 업무 목록, 가드레일 지표 유지의 증거, 검토 시간과 재처리 비용을 포함한 경제성 평가, 개정된 게이트 정의서가 있는 상태.

흔한 함정. 속도 지표만 보고 품질과 비용을 보지 않는 것. 성공한 팀만 보고하는 것.

5.5 단계4: 확산

목적. 파일럿에서 확인된 범위만 다른 프로젝트와 서비스로 넓힙니다.

핵심 활동.

온보딩 체크리스트. 확산 단위(프로젝트 또는 서비스)가 갖추어야 할 게이트 준비도를 체크리스트로 만들고, 충족한 단위만 대상에 포함합니다.
챔피언 제도. 프로젝트와 서비스마다 챔피언을 둡니다. 아정당 자료에서 AI 전담팀이 대신 만들어 주는 방식이 병목이 된 뒤 각 팀에 챔피언을 두는 쪽으로 옮겼다는 서술이 있습니다(강도 약, 마이리얼트립 AI랩 종료만 확인).
AX 플랫폼팀의 역할. 대신 만들어 주는 팀이 아니라 도구, 하네스, 게이트, 로그를 제공하는 팀입니다.
흐름에 심기. 도구를 나눠 주고 쓰라고 하는 방식이 아니라, 업무 흐름의 트리거(티켓 접수, PR 생성, 배포 승인 같은 지점)에 AI를 심습니다. 아정당 자료에서 토스는 문서 작성 도구를 공개했지만 아무도 쓰지 않았고 해법은 트리거에 심는 것이었다고 합니다(강도 약).
스테이지별 강도. 성숙도가 낮은 서비스와 안정 운영 중인 서비스의 게이트 강도를 달리합니다. 문서가 소개한 당근 알바팀은 단계마다 테스트 없음에서 테스트로, 다시 린트와 사후 리뷰로 게이트 강도를 올렸습니다(강도 약).

종료 게이트. 온보딩 조건을 충족한 단위의 지표가 가드레일 안에 있고, 챔피언과 플랫폼팀의 역할이 작동하는 상태.

흔한 함정. 전사 도구 배포 후 사용률만 보는 것. 협력사에 규칙을 알리지 않은 채 확산하는 것(9.4절).

5.6 단계5: 제도화

목적. 확인된 효과를 계약, 평가, 조직, 교육에 반영해 일상으로 만듭니다.

핵심 활동.

계약 반영(11장). 파일럿 데이터를 근거로 계약 모델 옵션을 선택합니다.
평가와 보상 반영(9.5절). 사용량이 아니라 가치를 측정하는 평가 축을 설계합니다.
역할과 교육 반영(9장). 신설 역할을 정식 직무로 정의하고 교육 과정에 넣습니다.
정기 재검토. 도구나 모델을 교체하거나 규제가 바뀔 때, 사고가 날 때 게이트와 하네스를 재검증합니다.

제도 변경 시점의 원칙. 아정당 자료에서 마이리얼트립은 평가에 AI 축을 넣되 리더가 평가할 준비가 될 때까지 도입을 1년 미뤘다고 합니다(강도 약, 평가 축 명문화만 확인). 제도는 데이터와 준비가 갖추어진 뒤에 바꾸는 편이 낫다는 뜻으로 읽을 수 있습니다.

종료 조건 없음. 이 단계는 끝나지 않고 주기적으로 단계0으로 돌아가 점검합니다.

6. 게이트 설계 상세

이 장이 방법론의 중심입니다. 아정당 자료가 경계를 허문 조직의 공통점으로 꼽은 것이 게이트이고, SI/SM에는 이미 무거운 게이트가 제도로 존재하기 때문에, 이 장은 새로 짓는 일보다 기존 게이트를 AI 속도에 맞게 고치는 일에 무게를 둡니다.

6.1 게이트 카탈로그: 여덟 개의 게이트

[제안] SI/SM 업무 단위가 고객에게 닿기까지 지나는 지점을 여덟 개로 정리했습니다. 모든 업무 단위가 여덟 개를 전부 지나는 것은 아닙니다. 위험 등급과 업무 성격에 따라 필요한 것만 고릅니다.

flowchart LR
  REQ["요청, 티켓, 요구사항"] --> G1["G1 입력 게이트"]
  G1 --> G2["G2 명세 게이트"]
  G2 --> WORK["AI와 사람의 작업"]
  WORK --> G3["G3 변경 게이트"]
  G3 --> G4["G4 검증 게이트"]
  G4 --> G5["G5 배포 게이트"]
  G5 --> G6["G6 고객 게이트"]
  G6 --> LIVE["고객 시스템에 반영"]
  LIVE --> G7["G7 운영 게이트"]
  G7 --> G8["G8 학습 게이트"]
  G8 -.->|"사고와 근접사고를 반영해 개정"| G1
  G3 -.->|"반려"| WORK
  G4 -.->|"반려"| WORK

게이트	지키는 질문	방식	대표 장치	소유자(제안)
G1 입력	무엇을 AI에게 줄 수 있는가	B	데이터 분류, 접근 권한, 비밀 정보 유출 방지, 환경 분리	보안 담당, AX 플랫폼팀
G2 명세	무엇을 만들 것인가	A	요구사항과 설계의 승인, 구현 전 스펙 리뷰	PM, 아키텍트
G3 변경	코드와 설정의 변경이 안전한가	A와 B	리뷰와 머지 권한 분리, CI, 정적 분석, 의존성과 라이선스 검사, 비밀 정보 검사	저장소를 소유한 팀의 리드
G4 검증	명세대로 동작하는가	B 중심	자동 테스트, 회귀 테스트, E2E 테스트, 사람이 정의한 기대 결과	QA 리드
G5 배포	고객 환경에 안전하게 반영되는가	C	배포 창, 점진 노출, 롤백, 배포 후 검증	이행 담당, 서비스 매니저
G6 고객	고객이 계약대로 받아들이는가	A	고객 검수, 감리, 인수, AI 활용 사실의 고지와 기록	PM, 사업책임자
G7 운영	운영 중 조치가 승인된 범위 안인가	A와 B	조치 승인 등급, 사전 승인 런북, 감사 로그, 긴급 조치 규칙	서비스 매니저, 운영 리드
G8 학습	사고와 변화를 게이트에 반영하는가	A	사고 회고, 근접사고 기록, 모델과 도구 교체 시 재검증	게이트 오너, AX 플랫폼팀

표의 방식 A는 사람이 확인하는 방식, B는 시스템이 애초에 못 하게 막는 방식, C는 배포 리듬 자체로 조절하는 방식으로, 아정당 자료가 정리한 게이트의 세 방식입니다.

아래는 게이트마다 아정당 자료와 보강 자료에서 가져올 수 있는 근거입니다.

게이트	근거	강도
G1	epilot은 샌드박스 실행만 허용하고 고객 데이터와 프로덕션 DB 접근을 막은 전용 봇 계정을 썼다. 토스는 개인정보 마스킹, 조회 사유 수취, 다운로드 암호화를 플랫폼이 자동 적용(확인하지 못함). 공공의 N²SF와 금융 망분리는 이 게이트의 외부 조건	중
G2	라포랩스는 6개월간 184개 실험을 한 뒤 실패율이 약 25%에서 약 43%로 오르자 “문제 정의”를 통과 게이트로 만들었다. 마이리얼트립은 구현 전 정책, 계획, 스펙을 가볍게라도 리뷰한다(확인하지 못함). LG CNS는 사전에 정한 명세에 따라 설계, 코딩, 검증을 하는 스펙 주도 개발을 내세움(회사 주장)	중
G3	epilot: 비개발자와 에이전트는 PR만 만들고 엔지니어가 리뷰, 머지. 채널톡: 개발자 2명 리뷰 필수, 디자이너 머지 권한 없음. Veracode: AI 코드 보안 결함 45%. 버즈빌은 “엔지니어가 아닌 사람에게 프로덕션 레포 쓰기 권한을 여는 일은 레포를 소유한 팀이 내려야 할 정책 결정”이라고 적음(회사 자체 서술)	강
G4	팀스파르타는 핵심 여정마다 E2E 테스트를 붙이고 자동 테스트 통과를 배포의 조건으로 걸었다	강
G5	팀스파르타: 상시 배포를 하루 2회 정기 배포로 조정. 라포랩스: 하루 10~30회 배포 후 검증(확인하지 못함). 레브잇: 가드레일 지표와 1%, 5~10%, 전체 점진 노출(부분 확인)	중
G6	SI/SM의 기존 제도. 인공지능 기본법의 투명성 의무와 고영향 AI 사업자의 관리·감독 체계 요구	중
G7	SK브로드밴드의 AI 관제·진단 에이전트는 이상 징후 탐지, 원인 분석, 점검 우선순위 결정, 담당자 보고까지를 수행(향후 자율 복구로 확대 계획). 팀스파르타는 핫픽스를 선 배포 후 공유(확인하지 못함)	약
G8	epilot은 사고 뒤 권한을 잠갔고, 라포랩스는 실패율 상승 뒤 방향을 고쳤고, 마이리얼트립은 AI랩 병목 뒤 구조를 바꿨다	중

6.2 기존 게이트를 AI 속도에 맞게 고치기

[풀이] SI/SM의 문제는 게이트가 없는 것이 아니라 게이트가 사람의 속도를 전제로 지어졌다는 점일 가능성이 큽니다. 코드 리뷰, 고객 검수, 변경관리 위원회, 감리는 한 사람이 하루에 만들 수 있는 변경량을 가정하고 설계되었습니다. AI가 변경의 양과 크기를 늘리면 이 게이트들이 병목이 되거나, 병목을 피하려는 우회(허가되지 않은 AI 사용, 형식적 승인)가 생깁니다. Faros의 분석에서 병합된 PR이 98% 늘 때 평균 PR 크기가 154% 커지고 리뷰 시간이 91% 늘어난 것이 그 징후입니다(강도 중, 상관 분석).

[제안] 이 방법론은 세 가지 처방을 씁니다.

첫째, 증거 수집을 자동화하고 사람은 판단에 집중시킵니다. 요구사항과 설계와 코드와 테스트의 추적성 매트릭스, 테스트 결과서, 변경 이력, 정적 분석 결과처럼 사람이 손으로 모으던 증거를 도구가 자동으로 만들게 하고, 사람은 그 증거를 보고 판단하는 데 시간을 씁니다.

둘째, 리뷰 대상을 작게 쪼갭니다. DORA 2025 보고서의 AI 역량 모델은 “Working in small batches”를 일곱 가지 역량 중 하나로 꼽습니다(강도 중). 큰 변경을 한 번에 검토하는 것보다 작은 변경을 자주 검토하는 편이 리뷰의 질을 지키기 쉽다는 일반적인 방향과 맞습니다. 업무 단위 분해(4.3절)가 리뷰 단위 분해로 이어지도록 설계합니다.

셋째, 위험 등급에 따라 게이트 강도를 달리합니다. 모든 변경에 같은 강도의 리뷰를 걸면 병목이 생깁니다. 아정당 자료에서 당근은 제품을 스테이지로 나누어 단계마다 게이트 강도를 달리했고(강도 약), 같은 문제에 기준을 하나로 두지 않는 것이 병목을 피하는 방법이었습니다.

AI가 AI를 검토하는 문제. AI 에이전트가 다른 AI의 산출물을 검토하게 하는 사례도 있습니다. 문서에 따르면 PostHog는 자체 승인 에이전트가 크기, 소유권, 티어를 결정론적으로 먼저 검사하고(확인하지 못함), 링크드인은 아이디어를 비평하고 취약점을 찾는 전문 에이전트를 만든다고 합니다(Lenny’s Newsletter 소개글에서 확인, 강도 중). [제안] 이 방법론은 AI 검토를 사람 검토의 보조로 허용하되, 최종 승인은 사람이 하고 책임은 옮겨 가지 않는다는 규칙(R2)을 둡니다. 같은 모델이 쓴 코드를 같은 모델이 검토하면 같은 오해를 공유할 수 있으므로, 가능하면 검증의 기준(기대 결과)은 AI의 입력이 아닌 명세와 사람에서 가져옵니다.

방식 B의 한계. 시스템 차단이 만능은 아닙니다. 아정당 자료의 확인된 사실 09번에 따르면 당근의 디자인 시스템 팀은 일관성을 API 제약으로 강제하자 제품팀이 시스템에서 이탈해 비슷한 컴포넌트를 따로 만들었고, 그래서 구현 제약은 풀고 일관성은 디자인 리뷰로 지키기로 했습니다(부분 확인). 제약을 너무 강하게 걸면 우회가 생기므로, “풀 곳은 풀고 리뷰로 옮기는” 선택지를 열어 두어야 합니다.

6.3 책임 규칙

[제안] 아정당 자료에서 책임 소재 칸에는 “만든 사람”, “트리거한 사람”, “문제를 발견한 사람”이 거의 변함없이 나타납니다. 도구가 바뀌어도 책임이 AI나 승인자에게 옮겨 가지 않는다는 점입니다. SI/SM에는 여기에 고객 계약이라는 층이 더해지므로 아래 여섯 규칙으로 정리했습니다. 단계0에서 경영진이 승인하고 선포합니다.

규칙	내용	근거
R1	업무를 요청하거나 AI를 트리거한 사람이 산출물의 정확성과 품질에 책임을 진다. AI 사용 여부와 무관하다	왓낫과 epilot의 규정(문서 기재, 강도 약)
R2	리뷰어는 정의된 점검 항목을 수행할 책임을 진다. 리뷰 승인이 작성자의 책임을 옮기지 않는다	PostHog의 규정(문서 기재, 강도 약)
R3	AI가 관여한 산출물은 어떤 도구와 어떤 입력으로 만들어졌는지 추적할 수 있어야 한다	사고 분석, 고객 고지, 인공지능 기본법 대응을 위한 설계(제안)
R4	책임은 작성자, 팀 리드와 PM, 사업책임자, 고객 계약의 순으로 이어진다. 고객에 대한 책임은 PM과 사업책임자가 진다	SI/SM의 계약 구조(풀이)
R5	게이트를 우회한 경우 면책되지 않고 별도의 사고로 다룬다	epilot의 우회 배포 사고와 대응(강도 강)
R6	AX 플랫폼팀은 도구의 가용성, 보안, 로그에 책임을 지고, 업무 결과에 대한 책임은 요청자에게 있다	전담팀이 대신 만들어 주면 병목이 된다는 서술(강도 약)

6.4 위험 등급별 게이트 조합

[제안] 6.1절의 게이트를 위험 등급에 따라 어떻게 조합할지에 대한 초안입니다. 리뷰어 수나 검토 강도의 구체적 값은 파일럿에서 정하며, 아래는 방향입니다.

위험 등급	게이트 조합의 방향
낮음	G1 입력 게이트와 G3의 자동 검사(방식 B)를 기본으로 하고, 사람 리뷰는 샘플링 또는 사후 점검
보통	방식 B에 더해 작성자와 다른 리뷰어 1인의 확인(방식 A)을 거치고, 비운영 환경에서 G4 검증을 통과
높음	방식 B와 A(승인자를 작성자와 분리)에 더해 G5의 점진 배포 또는 배포 창(방식 C), 사전 승인된 롤백 계획
매우 높음	위 조합에 더해 전문가 리뷰, G6 고객 사전 합의, 필요하면 L0 또는 L1으로 제한

6.5 게이트의 처리 용량 설계

[제안] 게이트도 처리 용량이 있습니다. 다음 세 가지를 설계 항목으로 둡니다.

입력량 가정. AI 도입 후 업무 단위의 변경 건수와 크기가 어떻게 달라질 것인지를 파일럿에서 측정해 가정을 세웁니다.
리뷰 용량 지표. 리뷰 대기 시간, 리뷰 반려율, 리뷰 시간의 분포를 추적합니다.
승급 중단 신호. 리뷰 대기 시간이 베이스라인보다 눈에 띄게 늘면 해당 영역의 승급과 확산을 멈추고 리뷰 용량이나 업무 단위의 크기를 조정합니다.

근거는 앞에서 본 세 가지입니다. 메타는 변경량이 220% 늘 때 사용자에게 도달한 기능은 36%만 늘었고, Faros는 리뷰 시간이 91% 늘었으며, 버즈빌은 리뷰 부담이 엔지니어에게 옮겨 갔다고 적었습니다.

7. SI 적용 설계

7.1 SI 가치흐름

SI 사업의 업무를 여덟 단계로 나눕니다. 회사나 사업 유형에 따라 단계 구분은 달라질 수 있으므로 단계0의 가치흐름 지도에서 자사 방식에 맞게 고칩니다.

flowchart LR
  S1["1 제안과 견적"] --> S2["2 요구사항 분석"]
  S2 --> S3["3 설계"]
  S3 --> S4["4 개발"]
  S4 --> S5["5 테스트"]
  S5 --> S6["6 이행과 배포"]
  S6 --> S7["7 검수와 인수"]
  S7 --> S8["8 안정화와 하자보수"]
  S8 -.->|"운영 이관"| SM1["SM 가치흐름"]

7.2 단계별 AI 활용과 게이트

[제안] 표의 ‘AI 활용 후보’는 SK AX와 LG CNS가 공개한 서비스 설명(요구사항 분석, 설계, 코드 생성, 테스트 시나리오 생성, 현행 시스템 분석 등)과 일반적인 개발 흐름을 바탕으로 정리한 것이며, 효과가 입증되었다는 뜻이 아닙니다. 각 후보가 실제로 이득이 있는지는 파일럿에서 확인합니다.

단계	AI 활용 후보	사람이 쥐는 판단	주요 게이트	위험	초기 상한
1 제안과 견적	요구 문서 분석, 유사 사례 검색, 제안서 초안, 견적 근거 정리	가격과 범위와 약속, 내용의 사실 확인	G1, 제안 내용 사실 확인(G6의 사전 점검)	보통에서 높음 (약속이 계약이 됨)	L2
2 요구사항 분석	회의록과 인터뷰 정리, 요구사항 분류와 정형화, 누락과 모순 탐지, 추적성 관리	고객과의 합의, 우선순위	G2	높음 (오해가 뒤 단계로 전파)	L2
3 설계	설계서 초안, 인터페이스 정의, 데이터 모델 제안	아키텍처 결정, 성능과 보안 같은 비기능 요구사항 판단	G2, G3	높음	L2
4 개발	코드 생성, 리팩터링, 단위 테스트, 주석	설계 의도와의 부합, 보안과 성능	G3, G4	보통에서 높음	L2 (비운영 환경 한정 L3 시험)
5 테스트	시나리오와 케이스 생성, 테스트 데이터, 자동화 스크립트	기대 결과의 정의, 커버리지 판단	G4	보통	L3
6 이행과 배포	이행 계획 초안, 체크리스트, 스크립트	이행 승인, 롤백 판단	G5, G6	높음에서 매우 높음	L2
7 검수와 인수	산출물 일관성 점검, 검수 항목 대조	고객 검수 대응	G6	보통	L1에서 L2
8 안정화와 하자보수	이슈 분석, 수정안, 지식 정리	우선순위, 고객 소통	G3에서 G7	높음	L2

몇 가지 설계 의도를 풀어 둡니다.

2단계(요구사항 분석)를 L2로 묶어 둔 이유. 요구사항의 오해는 이후 모든 단계로 전파됩니다. 그래서 AI가 정리하고 모순을 찾아내는 것은 적극 활용하되, 고객과의 합의와 우선순위 결정은 사람이 쥡니다. 이는 아정당 자료의 원칙 P2(전략과 약속은 위에서)와 연결됩니다. 아정당 자료의 24건 중 전략 결정을 아래로 내린 사례는 없었습니다.

4단계(개발)에 L3를 비운영 환경으로 한정한 이유. 비운영 환경에서는 승인 후 실행으로 빌드와 테스트를 자동화해도 고객 영향이 없습니다. 운영 반영 대상 코드는 여전히 G3 변경 게이트(리뷰와 머지 권한 분리)를 지나야 합니다.

5단계(테스트)의 순환 문제. AI가 쓴 코드를 AI가 만든 테스트로 검증하면 같은 오해를 공유할 수 있습니다. 기대 결과의 출처는 명세(고객 승인된 요구사항)와 사람이어야 합니다(6.2절).

7단계(검수와 인수)는 AI의 역할이 작습니다. 고객 검수는 계약상 고객의 권한이므로 AI는 내부 사전 점검(산출물 간 일관성, 검수 항목 대조)을 돕는 정도로 둡니다.

7.3 SI에 고유한 쟁점

쟁점 1: 산출물의 일관성과 추적성. SI의 산출물은 요구사항 정의서, 설계서, 소스코드, 테스트 결과서처럼 서로 연결되어 있고, 고객 검수와 감리의 대상입니다. AI가 각 산출물을 따로 생성하면 산출물 사이에 불일치가 생길 위험이 있습니다. [제안] 추적성 매트릭스(요구사항과 설계와 코드와 테스트의 연결)를 게이트의 증거로 자동 생성하고, 불일치를 G2와 G3에서 걸러 냅니다.

쟁점 2: 고객 합의와 투명성. 고객 시스템과 데이터에 AI를 쓰는 범위는 계약과 보안 조항에 따릅니다. [제안] 사업 착수 시 AI 사용 범위, 데이터 처리 방식, 사용 도구를 고객과 합의하고 기록합니다. 고객이 AI 사용을 허용하지 않는 사업은 L0입니다. 고지 없이 AI를 쓰고 투입 공수를 줄이는 것은 계약 분쟁과 신뢰 문제의 위험이 있으므로 R3의 추적성과 연결해 투명하게 관리합니다. 인공지능 기본법상 고객이 요구한 시스템이 고영향 AI에 해당하는지도 이 단계에서 법무가 판단합니다.

쟁점 3: 레거시 현대화. LG CNS가 COBOL을 Java로 자동 전환하는 기능을 대형 금융사 차세대 프로젝트에 적용 중이라고 밝혔고, SK AX도 현행 시스템 분석(소스코드와 SQL 분석, 호출 구조와 의존성 도출) 기능을 소개합니다. 이런 변환 작업의 정확성은 AI의 출력이 아닌 독립된 기준으로 검증해야 합니다. [제안] 기존 시스템의 실제 입출력 데이터와 동작을 기준으로 변환 전후의 동등성을 검증하는 테스트를 G4의 필수 증거로 삼고, 변환 결과는 L2(사람이 검토하고 반영)로 취급합니다. 두 회사의 설명은 회사 발표이며 변환 정확도나 검증 방식은 확인하지 못했습니다.

쟁점 4: 협력사 인력. SI 프로젝트에는 협력사 인력이 함께 일합니다. 이는 9.4절에서 다룹니다.

7.4 SI 파일럿 구성 예시

아래는 이해를 돕기 위한 가상의 예시이며 특정 사업이 아닙니다.

업무 단위	위험	시작 등급	게이트	핵심 측정
단위 테스트 코드 작성	낮음	L3 (비운영 환경)	G3 자동 검사, G4	작성 시간, 결함 탐지 수, 리뷰 반려율
인터페이스 정의서 초안	보통	L2	G2	작성 시간, 설계 검토에서의 수정 건수
운영 반영 대상 기능 코드	높음	L2	G3 리뷰(작성자와 다른 승인자), G4, G5	리드타임, 리뷰 대기 시간, 결함 유출률, 재작업
개인정보를 처리하는 모듈	매우 높음	L1	G1, G3 전문가 리뷰, G6	보안 결함 수, 사고, 리뷰 시간

8. SM 적용 설계

8.1 SM 가치흐름

SM 업무는 티켓의 흐름으로 나타납니다.

flowchart LR
  T1["접수"] --> T2["분류와 우선순위"]
  T2 --> T3["원인 분석"]
  T3 --> T4["조치안 작성"]
  T4 --> T5["승인"]
  T5 --> T6["실행"]
  T6 --> T7["검증"]
  T7 --> T8["종료와 보고"]
  T8 --> T9["지식화"]
  T9 -.->|"런북과 장애 이력 갱신"| T3

8.2 티켓 유형별 자율성 설계

[제안] SM에서는 단계가 아니라 티켓 유형마다 자율성 상한을 정하는 편이 현실에 맞습니다. 같은 “조치” 단계라도 단순 문의 응답과 운영 DB 변경은 위험이 전혀 다르기 때문입니다.

티켓·업무 유형	AI 활용 후보	위험	초기 상한	증거 후 목표 상한	핵심 게이트와 지표
단순 문의와 조회	답변 초안, 가이드 검색, 담당 분류	낮음	L2	L4 (사전 승인된 응답 범위)	G1, G7. 응답 시간, 재문의율
정기 점검과 보고서	점검 결과 요약, 월간 SLA 보고서 초안	낮음	L3	L4	G7. 작성 시간, 오류 정정 건수
결함 수정과 소규모 개선	원인 분석, 수정안과 PR 제안, 비운영 환경 재현	높음	L2	L3 (비운영 환경에서 빌드와 테스트 자동 실행)	G3, G4. 재오픈율, 결함 유출
장애 대응	이상 징후 분석, 로그와 지표 요약, 원인 가설	높음	분석 L1~L2	조치는 사전 승인 런북 범위에서만 L3~L4	G7, G8. 복구 시간, 오진율
변경 이행	이행 계획 초안, 체크리스트	높음	L2	표준 변경에 한해 L3~L4	G5, G7. 변경 실패율, 롤백 건수
데이터 정정과 보정	SQL 초안, 영향 범위 분석	매우 높음	L1~L2	L2~L3 (스테이징 검증 후 승인 실행)	G1, G3, G6. 데이터 오류, 감사 지적
권한과 보안 설정 변경	영향 분석, 점검 목록	매우 높음	L1	L2	G1, G6. 보안 사고

표준 변경과의 연결. IT 서비스 관리 프레임워크인 ITIL에는 표준 변경, 곧 사전에 승인된 저위험 반복 변경의 개념이 있습니다. [풀이] 이 개념은 이 방법론의 L4(사전 승인 범위 내 자동 실행)와 자연스럽게 겹칩니다. 이미 조직이 표준 변경으로 분류해 둔 작업은 AI 자동 실행의 가장 안전한 후보입니다. [한계] ITIL의 용어는 일반적으로 알려진 개념을 인용한 것이며 이번에 원문을 열어 확인하지는 않았습니다.

8.3 장애 대응 설계

운영 장애는 SM의 핵심 업무이고 시간 압박이 큽니다. 시간 압박 속에서 게이트가 무너지기 쉬우므로 미리 설계해 두어야 합니다.

[근거] (강도 약~중) 통신사 네트워크 운영의 사례입니다. SK브로드밴드의 AI 관제·진단 에이전트 ‘C-One’은 고객경험지표를 바탕으로 유선 네트워크의 이상 징후를 자동으로 찾고, 원인을 분석하고, 점검 우선순위를 정해 담당자에게 보고서를 자동으로 보냅니다. 장애 탐지부터 복구까지 AI가 수행하는 자율 복구 에이전트로 확대할 계획이라고 합니다. 같은 기사는 과제로 데이터가 불완전하거나 흩어져 있으면 분석 정확도가 떨어지고, AI의 판단 근거를 사람이 이해하기 어렵다는 설명 가능성 문제를 꼽습니다(디지털데일리). 이 사례는 SM 사업자의 사례가 아니며, 현재 공개된 단계는 탐지, 분석, 보고까지이고 자율 복구는 계획이라는 점이 중요합니다.

[제안] 이 방법론의 장애 대응 설계는 다섯 가지 원칙을 따릅니다.

분석과 조치를 분리합니다. 분석(원인 가설 제시, 로그와 지표 요약)은 L1~L2에서 시작하고, 조치(재기동, 설정 변경, 롤백)는 별도로 승인 등급을 정합니다.
근거 없는 가설은 채택하지 않습니다. AI가 낸 원인 가설은 근거가 된 로그와 지표를 함께 제시해야 하고, 사람이 근거를 확인할 수 있어야 합니다. 설명 가능성 문제에 대한 대응입니다.
사전 승인된 런북만 자동 실행의 후보가 됩니다. 런북은 소유자, 버전, 검증 이력, 유효 기간을 가집니다.
L4에는 사후 검증과 자동 복구를 의무로 붙입니다. 자동 실행 뒤 상태가 기대와 다르면 자동으로 이전 상태로 돌립니다.
긴급 상황에서도 승인 규칙을 유지합니다. 핫픽스를 먼저 배포하고 나중에 공유하는 방식은 아정당 자료에서 팀스파르타가 택한 방식으로 소개되었지만(확인하지 못함), 사전에 정의된 범위 안에서만 허용해야 합니다.

8.4 SLA와 AI

SM의 SLA 위반은 계약 위반이므로, SLA 지표는 가드레일 지표로 그대로 씁니다. AI 도입 후에도 SLA 준수율이 베이스라인 아래로 내려가면 해당 영역의 승급과 확산을 멈춥니다. 함께 추적할 지표는 최초 응답 시간, 복구 시간, 재오픈율, 에스컬레이션 비율, 고객 만족입니다. 투입공수 감소는 이득이지만 SLA가 지켜진다는 전제 위에서만 이득으로 계산합니다(10장).

8.5 SM의 지식화

SM은 티켓 이력, 장애 이력, 런북이 쌓이는 곳이어서 AI가 읽을 지식의 자원입니다. 그러나 자동화가 기준이 없다는 사실을 드러내는 일도 생깁니다. 문서에 따르면 토스는 문서를 자동 생성하게 만든 뒤 비슷한 문서가 쌓여 무엇이 최신인지 알 수 없게 되었고, 봇이 낡은 정책으로 틀린 답을 냈습니다(강도 약). 이를 SM에 옮기면 오래된 런북이나 폐기된 절차를 AI가 참조해 잘못된 조치를 제안하는 위험이 됩니다.

[제안] 지식 문서에는 소유자, 검토 주기, 유효 기간을 붙이고, 유효 기간이 지난 문서는 AI가 참조하지 못하게 합니다. 문서의 기준을 조율하는 협의체는 결정 권한이 있어야 합니다. 문서에 따르면 토스는 자발적 모임(길드)이 결정하거나 강제할 힘이 없다는 경험 끝에 결정이 실제 효력을 갖는 협의체로 바꿨습니다(강도 약).

9. 사람: 역할, 조직, 평가

9.1 직함을 먼저 합치지 않는다

[근거] 아정당 자료에서 직군 통합에 나선 사례들의 모습은 이렇습니다.

아마존은 Ring과 Blink 두 사업부에서 단일 직군 “Builder”를 시험했고, Reuters 보도(2026년 4월 23일)에 따르면 사내 메모가 이를 시험이라고 불렀으며 잘 안 되는 프로세스는 되돌리겠다는 취지의 설명도 있었습니다. 직원들은 senior와 lead 같은 직함이 사라지면 승진과 임금 인상 경로가 어려워질 것을 우려했고, 회사는 경로가 그대로라고 답했습니다(강도 강).
메타는 직군을 없애 3~5명 팟으로 재편하려 했고, 5월 19일 저녁 2차 계획을 접은 뒤 다음 날 10% 감원을 시행했습니다. 직원 긍정 응답이 74%에서 55%로 내려갔다고 보도되었습니다(강도 중, 2차 기사). 문서는 사내 게시판이 항의로 채워지고 노조 결성 움직임에 힘이 붙었다고 적습니다(확인 정도 낮음).
마이리얼트립은 2025년 9월 테크 직군, 2026년 3월 PM·PD·CD까지 프로덕트 엔지니어로 전환했고 약 70명 규모입니다(강도 강). 문서는 처음에 반발이 컸고 과거 기준으로 최상위 평가를 받던 전문가들이 떠났다고 적습니다(확인하지 못함).
레브잇은 단일 직군에서 직군 분화로 되돌아왔습니다(강도 중).

[풀이] 이 사례들이 보여 주는 것은 두 가지입니다. 하나는 직함을 바꾸는 순간 승진, 보상, 평가의 질문이 먼저 온다는 점입니다. 다른 하나는 규모의 차이입니다. 마이리얼트립이 약 70명의 프로덕트 엔지니어 규모에서 한 일을 수천에서 수만 명이 일하는 대기업에 그대로 옮길 근거는 없고, 같은 규모의 아마존과 메타도 사업부 단위 시범에 그쳤습니다.

[제안] 그래서 SI/SM 대기업은 직군과 직함 체계를 유지한 채로 시작하고, 그 위에 역할 언어를 얹습니다. 직군을 합칠지는 파일럿과 평가 체계 정비 이후의 별도 의사결정(13장의 Q12)으로 남깁니다. AX 도입과 인력 구조 조정을 같은 선언에 묶지 않는다는 점도 분명히 합니다. 메타가 인력 축소와 직함 변경을 동시에 밀다가 6개월 안에 일부를 되돌린 사례(강도 강), 듀오링고가 AI 퍼스트 메모 뒤 CEO가 메시지를 명확하게 전하지 못했다고 인정한 사례(강도 강)가 이를 뒷받침합니다.

9.2 역할 언어: 다섯 아키타입을 SI/SM에 대어 보기

[근거] Anthropic의 Claude Code 책임자 Boris Cherny가 2026년 6월 28일 X에 올린 글은 제품 팀에서 나타나는 다섯 가지 일하는 성향을 제시했습니다. 프로토타이퍼는 아이디어를 쏟아내고, 빌더는 살아남은 프로토타입을 프로덕션 수준으로 바꾸며, 스위퍼는 정리하고 단순화하고, 그로워는 나온 제품을 반복 개선하고, 메인테이너는 성숙한 시스템의 안정성과 보안을 지킵니다. 이 역할은 직군과 관계없이 나타나고 한 사람이 두세 개에 걸치며, 제품 단계에 따라 필요한 조합이 달라진다고 합니다(강도 강, 앞선 해설에서 확인).

[제안] 아래는 이 다섯 성향을 SI/SM의 일에 대어 본 것입니다. 원 게시글이 SI/SM을 다룬 것이 아니므로 대응은 제 해석입니다.

성향	SI에서의 모습	SM에서의 모습
프로토타이퍼	제안과 PoC 단계에서 빠르게 시안과 동작하는 샘플을 만드는 일	개선 아이디어를 작게 검증하는 일
빌더	요구사항을 운영 수준의 시스템으로 구축하는 일	승인된 개선과 신규 기능을 반영하는 일
스위퍼	레거시 분석, 표준화, 중복 제거	중복 런북과 불필요한 배치의 정리, 기술 부채 해소
그로워	구축 이후의 고도화	서비스 품질과 운영 효율의 반복 개선
메인테이너	안정화와 운영 이관	안정성, 보안, SLA 유지의 중심

[풀이] 원 게시글의 단계별 조합(시장 적합성 전에는 프로토타이퍼, 빌더, 스위퍼가 중심이고, 성숙한 제품은 스위퍼, 그로워, 메인테이너에 약간의 빌더가 필요함)을 SI/SM에 대면, SM 서비스는 대체로 성숙 단계의 조합, 곧 스위퍼, 그로워, 메인테이너가 중심이고, 신규 SI 사업은 프로토타이퍼와 빌더 비중이 큽니다. 이 해석이 맞는다면 SM 조직의 AI 활용은 새로 만드는 일보다 정리, 안정화, 개선에 먼저 향하는 편이 자연스럽습니다. 다만 이것은 가설이며 조직 진단에서 확인해야 합니다. 이 분류는 사람을 고정하는 칸막이가 아니라는 점도 중요합니다. 원 게시글도 같은 사람의 역할이 시간과 프로젝트에 따라 바뀐다고 했습니다.

9.3 신설하거나 강화할 역할

[제안] 직군을 바꾸지 않고 다음 역할을 정의합니다. 한 사람이 겸할 수도 있습니다.

역할	하는 일	하지 않는 일
게이트 오너	맡은 게이트의 정의서, 지표, 개정을 소유한다	개별 업무 결과를 대신 책임지지 않는다
AX 플랫폼팀	도구, 하네스, 권한, 로그, 비용 한도, 템플릿을 제공한다	현업을 대신해 만들어 주지 않는다
AX 챔피언	프로젝트와 서비스마다 흐름에 AI를 심고, 피드백을 모으고, 게이트 준비도를 챙긴다	도구 영업이 아니다
도메인 전문가	업무 지식을 AI가 읽을 수 있는 형태로 남기고, 결과를 판단한다
리뷰어	정의된 점검 항목으로 변경을 검토한다. 리뷰 시간을 업무로 인정받는다
법·보안 연락 담당	계약, 규제, 보안 질의에 응답한다
현장 배치 엔지니어(선택)	고객 현장에서 문제 파악부터 구축·운영까지 맡는다

AX 플랫폼팀의 “대신 만들어 주지 않는다”는 원칙은 아정당 자료에서 AI 전담팀이 직접 문제를 해결하는 방식이 한계에 부딪힌 사례들에서 가져왔습니다(강도 약). 팀스파르타는 AI 전담팀이 직접 문제를 해결하는 방식이 3명의 생산성에 묶였다며 문화 중심으로 옮겼고(확인하지 못함), 마이리얼트립은 AI랩을 약 2년 만에 종료했습니다(강도 강). 챔피언은 업무 시간을 인정받지 못하면 부업이 되어 흐지부지되기 쉽다는 점을 감안해, 시간과 평가에서 인정하도록 설계합니다([제안], 근거 없음).

[풀이] 플랫폼 제공 팀과 업무를 수행하는 팀을 구분하는 구조는 팀 구조 이론인 Team Topologies의 플랫폼 팀과 스트림 얼라인드 팀의 구분과 닮았습니다. 이는 일반적으로 알려진 개념을 빌린 비유이며 이번에 원문을 확인하지는 않았습니다.

9.4 협력사와 상주 인력

[한계] 협력사 인력이 AI를 어떻게 쓰고 어떻게 관리받는지에 관한 공개 자료는 확인하지 못했고, 아정당 자료에도 해당하는 사례가 없습니다. 아래는 모두 [제안] 입니다.

SI/SM 사업에는 협력사 인력이 상주합니다. 규칙이 자사 직원에게만 적용되면 두 가지 문제가 생길 수 있습니다. 하나는 협력사 인력이 허가되지 않은 AI 도구를 쓰는 섀도 AI이고, 다른 하나는 같은 프로젝트 안의 역량 격차와 책임 공백입니다. 설계 원칙은 다음과 같습니다.

계약과 서약 단계에서 명시합니다. 허용 도구, 금지 사항, 데이터 취급 규칙을 협력 계약과 보안 서약에 넣습니다.
허용 도구를 같은 환경에서 제공합니다. 쓸 수 있는 도구가 없으면 쓸 수 없는 도구를 쓰게 됩니다.
게이트와 책임 규칙은 소속과 무관하게 같습니다. 협력사 인력이 만든 변경도 G3를 지나고, R1의 책임은 요청한 사람에게 있습니다.
교육의 문을 엽니다. 자사 직원만 교육 대상에 두지 않습니다.
이득의 분배는 열린 질문으로 둡니다. AI로 줄어든 공수에 대한 협력사 대가는 11장과 같은 이유로 파일럿 데이터를 본 뒤 정합니다.

9.5 평가와 보상

[근거] 아정당 자료와 보강 자료가 보여 주는 평가 설계의 사례입니다.

쇼피파이는 AI 사용을 기본 기대치로 선언하고 성과 평가와 동료 평가에 AI 활용 질문을 추가했으며, 인원과 자원을 요청하기 전에 AI로 왜 할 수 없는지를 보이게 했습니다(강도 강). 문서는 실제 운영에서 이 조항이 AI를 더 쓰면 자원을 더 준다는 쪽으로 뒤집혔다고 적습니다(확인하지 못함).
마이리얼트립은 올해부터 성과 평가 항목에 AI 네이티브니스를 명문화한다고 밝혔습니다(강도 중). 문서는 평가 축이 업적, 핵심가치, AI 활용 셋이고 측정 기준이 AI 사용량이 아니라 AI로 만든 고객과 사업의 가치이며, 도입은 리더가 평가할 준비가 될 때까지 1년 미뤘다고 적습니다(확인하지 못함).
아마존은 성공의 정의를 “당신이 만든 고객 가치의 범위와 크기가 무엇인가”라는 한 질문으로 압축했습니다(강도 강).

[제안] 이 방법론의 평가 설계 원칙은 여섯 가지입니다.

AI 사용량(토큰, 사용 시간, 건수)을 평가에 직접 쓰지 않습니다. 메타의 사례처럼 산출량이 성과로 이어지지 않을 수 있고, 사용량을 평가하면 사용량을 부풀리는 행동이 생깁니다.
평가 축은 “게이트를 지키며 만든 가치”입니다. 품질, 고객 결과, 재사용되는 개선(런북, 템플릿, 게이트 개선)에의 기여를 봅니다.
게이트를 지키는 행동을 불이익이 아닌 가산으로 봅니다. 리뷰에서 반려하는 것, 사고와 근접사고를 보고하는 것, 우회하지 않는 것입니다. 그렇지 않으면 속도 압박 속에서 게이트가 무너집니다.
인원 요청에 “AI로 못 하는 이유 증명”을 요구하는 방식은 신중하게 씁니다. 쇼피파이의 선언은 확인되지만 운영상의 뒤집힘은 문서 기재 수준이므로, 도입한다면 부작용을 추적합니다.
리더가 평가할 준비가 된 뒤에 도입합니다. 새 평가 축을 평가할 리더가 그 축을 이해하지 못하면 제도가 형식이 됩니다.
승진과 보상 경로가 달라지지 않는다는 점을 먼저 명시합니다. 아마존에서 직원들이 가장 먼저 물은 것이 승진과 임금 인상 경로였습니다.

9.6 교육

[근거] SK AX는 2026년 10월 1일 개발 조직 외의 인사, 기획, 마케팅, 영업을 포함한 전 직군을 대상으로 한 4주 과정의 ‘AI 부트캠프 바이브’를 내놓았고, 실습과 과제 제출과 평가를 AI 기반으로 운영한다고 설명했습니다(바이라인네트워크). 이 교육이 어떤 효과를 냈는지는 확인된 바가 없습니다. 아정당 자료는 AI 능숙함(도구를 잘 다루는 것)과 AI 주체성(자기 업무 방식을 도구 위에서 다시 짠 것)의 격차가 생각보다 크다고 기록한 조직들을 소개합니다(강도 약).

[제안] 교육은 도구 사용법에 그치지 않고 자기 업무 흐름 안에서 게이트와 책임 규칙을 지키며 일하는 법을 포함합니다. 교육의 성과는 이수율이 아니라 단계3, 단계4의 지표로 확인합니다.

10. 측정 체계

10.1 원칙: 산출량이 아니라 성과와 안전선

아정당 자료의 첫 번째 실패 유형이 산출량과 성과의 괴리였고, 3.4절의 연구들이 모두 같은 방향을 가리킵니다. 그래서 이 방법론은 세 가지 규칙을 둡니다.

첫째, 지표는 흐름, 품질, 경제 세 층으로 함께 봅니다. 한 층만 보면 나머지 층의 악화를 놓칩니다.

둘째, 절대 나빠지면 안 되는 선을 먼저 정합니다. 이것이 가드레일 지표이고, 목표 지표와 함께 보고합니다. 아정당 자료에서 레브잇은 목표 지표와 함께 가드레일 지표를 설정해 문제가 생기면 즉시 중단하고 되돌리며 1%에서 5~10%, 전체로 점진 배포한다고 합니다(부분 확인).

셋째, 체감과 실측을 함께 봅니다. METR 실험에서는 체감과 실측이 반대 방향이었고, DORA 설문에서는 80% 이상이 생산성이 올랐다고 답했지만 전달 불안정성은 계속 증가했습니다.

10.2 지표 체계

[제안] 지표의 구체적 정의와 기준값은 파일럿에서 정하며, 아래는 구성입니다.

층	지표	SI에서의 적용	SM에서의 적용
흐름	리드타임(요구에서 반영까지), 리뷰 대기 시간, 재작업 시간	단계별 소요 시간, 설계 변경 후 재작업	티켓 접수에서 종료까지, 에스컬레이션 시간
품질	결함 유출률, 변경 실패율, 재오픈율, 보안 결함 수, 복구 시간	검수와 인수 단계 결함, 운영 이관 후 결함	재오픈율, 변경 실패율, 장애 복구 시간
경제	총비용, 투입공수 대비 산출, 마진	단계별 투입공수, 하자보수 비용	티켓당 비용, 처리량 대비 투입공수
가드레일	보안·개인정보 사고, 고객 검수 반려율, SLA 준수율, 구성원 정서 지표	검수 반려율, 감리 지적	SLA 준수율, 고객 불만

총비용에 포함할 것. OpenAI 코리아 지사장은 2026년 9월 삼성SDS 행사에서 성과를 측정할 때 모델 사용 비용뿐 아니라 직원의 검토 시간과 실패한 업무의 재처리 비용도 포함해야 한다고 언급한 것으로 보도되었습니다(강도 중, CIO Korea). 같은 방향의 설계입니다.

구성원 정서 지표를 가드레일에 넣은 이유. 메타에서 직원 긍정 응답이 74%에서 55%로 내려간 사례(강도 중)가 있고, 직함을 바꾼 조직에서는 승진과 보상 질문이 먼저 나왔기 때문입니다. 정서 지표는 구성원 이탈을 늦게 알려 주는 지표이므로 별도로 추적합니다.

전달 성과 지표의 참조. DORA 연구는 배포 빈도, 변경 리드타임, 변경 실패율, 장애 복구 시간을 소프트웨어 전달 성과의 핵심 지표로 오래 써 왔습니다. 이는 일반적으로 알려진 내용을 인용한 것이며 이번에 2025년 보고서 원문에서 지표 구성을 확인하지는 않았습니다.

10.3 쓰지 않거나 단독으로 쓰지 않는 지표

지표	쓰지 않는 이유	근거
코드 줄 수, 변경 건수, PR 수	양이 늘어도 사용자에게 도달한 성과가 비례하지 않을 수 있음	메타: 변경량 220% 증가 대비 사용자 도달 기능 36% 증가
AI 도구 사용률, 토큰, 사용 시간	사용량은 성과가 아니며 부풀릴 수 있음	아정당 자료의 평가 사례는 사용량이 아니라 가치를 측정 기준으로 둠(약)
체감 설문 단독	체감과 실측이 어긋날 수 있음	METR: 체감 약 20% 빨라짐, 실측 19% 느려짐
개인 수준의 속도 지표 단독	조직 수준의 성과로 이어지지 않을 수 있음	Faros: 팀 단위 이득이 있어도 조직 수준에서 유의미한 상관을 관찰하지 못함

10.4 베이스라인과 비교 설계

[제안] 효과를 주장하려면 비교할 기준이 있어야 합니다. 다음을 지킵니다.

베이스라인을 도입 전에 확보합니다. 단계1에서 합니다.
비교군을 둡니다. 같은 시기 비파일럿 팀 또는 직전 주기와 비교하고, 무작위 대조가 아니라는 한계를 보고서에 적습니다.
외부 요인을 분리하려고 노력합니다. 요구사항 변경, 인력 교체, 계절 요인이 지표에 섞이지 않도록 기록합니다.
불확실성을 함께 보고합니다. 표본이 작은 파일럿의 결과를 일반화하지 않습니다. 아정당 자료의 무신사는 대조군 비교를 하지 않아 평가 자동화의 우월성을 가설로 남긴다고 기록했습니다(확인하지 못함). 같은 태도입니다.

11. 계약과 사업 모델

11.1 이 장의 위상

3.2절에서 본 대로 국내 대가산정 제도는 변화 중이고(과기정통부 TF가 첫 회의를 열었지만 확정된 변경안은 없음), 국내 SI/SM 대기업이 AI 활용 이후 계약을 어떻게 바꾸고 있는지는 공개 자료로 확인하지 못했습니다. 그래서 이 장은 판단의 틀과 순서를 제안하는 데 그치고, 어떤 계약 모델이 맞는지는 단정하지 않습니다.

11.2 인센티브 구조 진단

[풀이] (가설) 아래 표는 계약 방식에 따라 AI의 효과가 누구에게 돌아가는지 추정한 것입니다. 실제 계약은 사업마다 다르며, 이 표를 입증하는 공개 자료는 확인하지 못했습니다.

계약 방식	AI 효과의 귀속(추정)	도입 동기	위험
개발비(기능점수 기반)	대가가 투입 공수와 분리되므로 공수 절감이 수행사 이익으로 감	큼	품질 저하 시 하자와 재작업 비용을 수행사가 부담. 고객의 가격 인하 요구(TF 논의의 배경)
운영·유지관리비(투입공수 기반)	공수가 줄면 대가도 줄 수 있음	약함	SM 조직이 AI를 도입할수록 매출이 줄 수 있음. SLA 위반 시 패널티
시간당 과금(해외)	공수 감소가 고객에게 그대로 드러남	약함	가격 논쟁
고정가·모듈 단위(해외 동향)	효율 이득이 수행사에게 남음	큼	범위 변경, 위험 전가. UpperEdge는 이 전환이 SI 측 주도라고 해석

11.3 선택지와 순서

[제안] 선택지를 네 가지로 나눕니다.

선택지	내용	맞는 상황
옵션 1 현행 유지	계약 모델은 그대로 두고 내부 마진과 품질 개선으로 흡수	파일럿 데이터가 아직 없을 때. 단 고객에게 AI 사용을 알리지 않는 경우의 신뢰 위험을 관리해야 함
옵션 2 SLA·성과 연동	운영 대가를 투입공수보다 서비스 수준과 성과 쪽으로 이동	SM에서 SLA 데이터가 쌓였을 때
옵션 3 모듈·고정가 전환	구축 사업을 모듈 단위의 고정가로	SI에서 단계별 투입공수와 품질 데이터가 쌓였을 때. 공공은 제도 변화를 지켜봄
옵션 4 AI 포함 신규 상품	고객 대상 에이전트의 구축과 운영을 새 상품으로	삼성SDS가 고객사용 에이전트 플랫폼과 우리은행의 금융 특화 에이전트 구축 목표를 밝힌 것처럼, 구축 대상이 AI일 때

순서. 이 방법론은 계약 모델을 먼저 바꾸라고 권하지 않습니다. 단계3 파일럿에서 투입공수, 품질, SLA 데이터를 쌓고, 단계5에서 그 데이터를 협상의 근거로 삼아 옵션을 고릅니다. 판단 기준은 (가) 파일럿 데이터의 신뢰도, (나) 고객과의 관계와 신뢰, (다) 공공인지 민간인지(공공은 TF의 결론에 따라 제도가 바뀔 수 있음), (라) 법무 검토 결과입니다.

11.4 투명성과 신뢰

계약과 고객 관계에서 가장 큰 위험은 고객이 모르는 사이에 AI를 쓰고 공수를 줄이는 것입니다. [제안] 7.3절의 쟁점 2처럼 사업 착수 시 AI 사용 범위와 데이터 처리 방식을 합의하고, R3의 추적성으로 사용 이력을 남깁니다. 고객과의 합의가 있으면 품질과 책임의 논의가 투명해지고, 그렇지 않으면 사고가 났을 때 책임 분쟁이 커집니다.

11.5 인공지능 기본법 관점의 계약 점검

[제안] 법률 자문이 아니며, 법무 검토가 필요한 점검 항목입니다. 3.3절에서 본 법의 내용을 바탕으로 합니다.

구축하는 시스템이 고영향 AI(채용, 대출심사 등)에 해당하는지, 해당한다면 고객과 수행사 중 누가 어떤 지위(개발사업자, 이용사업자)와 책무를 갖는지 계약에 반영할 것인가.
고영향 AI 사업자에게는 위험관리방안, 설명 방안, 이용자 보호 방안과 사람이 관리·감독하는 체계가 요구되고 확인 문서는 5년간 보관해야 한다고 합니다. 이 보관 책임을 누가 지는가.
생성형 AI 사업자의 사전 고지와 표시 의무가 구축 대상 시스템에 적용되는가.
과기정통부가 최소 1년 이상의 계도 기간을 두기로 했지만 이 기간은 유한하므로, 계약 기간이 계도 기간을 넘어서는 사업은 이후의 규제 적용을 가정해야 합니다.

12. 실패 모드와 예방

아정당 자료가 정리한 다섯 가지 실패와 보강 자료에서 확인한 실패를 SI/SM의 모습으로 바꿔, 조기 경보 신호와 방법론의 예방 장치를 짝지었습니다.

번호	실패 모드	근거	SI/SM에서의 모습	조기 경보 신호	예방 장치
F1	산출량과 성과의 괴리	메타 220% 대 36%, METR	코드와 문서의 양은 늘었는데 검수 반려와 재작업이 늘어남	결함 유출률과 재작업 시간 상승	10장의 3층 지표와 가드레일
F2	전담조직의 병목	마이리얼트립 AI랩 종료 외(약)	AX센터가 프로젝트를 대신 만들어 주는 구조로 굳어짐	AX센터 대기열 증가, 현업의 의존	R6, 플랫폼팀과 챔피언의 역할 분리
F3	도구만 주는 확산	토스 사례(약)	라이선스는 배포했으나 사용이 정체됨	사용률의 정체, “잘 안 된다”는 답	흐름의 트리거에 심기(5.5절)
F4	기준 없는 자동화	토스 사례(약)	오래된 런북이나 폐기된 표준을 AI가 참조	상충하는 답변, 최신 여부의 혼란	지식 문서의 소유자와 유효 기간(8.5절)
F5	인프라 없는 선언	듀오링고, 메타	선언은 했으나 망분리나 고객 보안 조항 때문에 현장에서 쓸 수 없음. 섀도 AI	비공식 도구 사용, 현장의 불만	단계0의 순서(선언은 인프라 뒤)
F6	시연과 운영의 격차	Gartner: 에이전틱 AI 프로젝트의 40% 이상 취소 예측, 에이전트 워싱	시연에서는 작동하나 운영 예외 처리와 비용을 감당하지 못함	비용 초과, 가치 불분명, 리스크 통제 미비	단계3 파일럿의 총비용과 가드레일
F7	리뷰 병목	Faros 리뷰 시간 91% 증가, 버즈빌	리뷰어에게 업무가 몰리고 형식적 승인이 늘어남	리뷰 대기 시간 증가, 승인 속도 비정상	6.5절의 처리 용량 설계와 승급 중단 신호
F8	보안 결함의 유입	Veracode 45%	AI 생성 코드의 취약점이 검수를 통과	정적 분석 지적 증가	G3의 자동 검사, L2 시작
F9	고객 신뢰와 계약 분쟁	(SI/SM 구조에서의 추론)	고객이 모르는 AI 사용, 산출물 불일치, 책임 공방	검수 반려, 감리 지적	고객 합의(7.3절), R3, R4
F10	인력 불안과 이탈	메타 74%에서 55%, 아마존의 승진 우려	구조 조정에 대한 소문, 전문가의 이탈	정서 지표 하락, 이직 증가	1.4절의 선언, 9.1절, 9.5절
F11	지표 착시	METR, DORA	체감 조사의 긍정과 실측의 악화가 공존	체감과 실측의 괴리	10.4절의 병행 측정
F12	협력사 격차	(근거 없음, 제안)	협력사 인력의 비공식 AI 사용이나 책임 공백	협력사 산출물의 품질 편차	9.4절

[풀이] F1부터 F5가 아정당 자료에서 반복된 다섯 가지이고, F6 이하는 보강 자료와 SI/SM 구조에서 추가한 것입니다. F9와 F12는 근거가 약한 추론과 제안이므로, 파일럿에서 실제로 나타나는지 확인하기 위한 점검 항목으로 읽어 주십시오.

13. 결정 지점 15개

아정당 문서는 마지막에 “어느 조직이든 스스로 정해야 하는 15가지”를 질문으로 남겼습니다. 이 방법론도 같은 방식으로, 조직이 정해야 하는 것을 질문과 선택지, 이 문서의 기본 제안으로 정리했습니다. 기본 제안은 정답이 아니라 시작점입니다.

flowchart TD
  ROOT["정해야 하는 15가지"]
  subgraph BASE["기반과 범위"]
    Q1["Q1 범위"]
    Q2["Q2 환경"]
    Q3["Q3 자율성 상한"]
  end
  subgraph CONTROL["통제"]
    Q4["Q4 게이트 방식"]
    Q5["Q5 책임 규칙"]
    Q6["Q6 플랫폼팀 정책"]
    Q7["Q7 협의체 권한"]
    Q8["Q8 요구사항 정의 기능"]
  end
  subgraph MEASURE["측정과 계약"]
    Q9["Q9 측정"]
    Q10["Q10 평가와 보상"]
    Q14["Q14 계약과 고지"]
  end
  subgraph PEOPLE["사람"]
    Q11["Q11 이탈의 감수"]
    Q12["Q12 직군과 직함"]
    Q13["Q13 협력사"]
    Q15["Q15 확산 방식"]
  end
  ROOT --> Q1
  ROOT --> Q4
  ROOT --> Q9
  ROOT --> Q12

번호	질문	선택지	이 문서의 기본 제안	참고
Q1	어디서부터 시작하는가	전사 일괄, 사업부 단위, 프로젝트와 서비스 단위	프로젝트와 서비스 단위 파일럿 후 사업부로 확산	5.4절. 마이리얼트립은 인위적 결핍을 새 프로젝트에만 적용(약)
Q2	어떤 환경에서 어떤 도구를 허용하는가	환경별 허용, 사내 통제 환경만, 전면 허용	환경을 보안 수준으로 분류해 허용 도구 목록을 정의	5.1절. 3.3절의 규제 변화에 따라 갱신
Q3	업무별 자율성의 상한은	4.4절의 표를 따를지 조정할지	초기 상한에서 시작해 증거로 조정	4.5절
Q4	게이트를 사람에 둘 것인가, 시스템에 둘 것인가	방식 A, B, C의 조합	위험 등급별 조합	6.4절
Q5	책임 규칙을 누가 승인하는가	사업부, 경영진	경영진이 승인하고 선포	6.3절
Q6	플랫폼 정책을 하나로 둘 것인가	단일 정책, 스테이지와 도메인별 정책	스테이지별로 두고 컨설팅에서 피드백, 필요하면 정책 순으로	당근 플랫폼팀 사례(문서 기재, 약)
Q7	협의체에 결정 권한이 있는가	자발적 모임, 권한 있는 협의체	결정이 효력을 갖는 협의체	토스 사례(약)
Q8	요구사항 정의 기능을 어디에 두는가	현행 유지, 게이트화	요구사항 합의를 G2 명세 게이트로	만드는 비용이 내려갈수록 무엇을 만들지 정하는 실패가 드러난다는 라포랩스와 왓낫의 서술(약)
Q9	무엇으로 성과를 재는가	산출량, 흐름·품질·경제	3층 지표와 가드레일	10장
Q10	평가와 보상을 바꾸는가, 언제 바꾸는가	즉시, 준비 후	사용량 지표 배제, 리더 준비 후 도입	9.5절
Q11	이탈을 어디까지 감수하는가	감수 범위의 설정	정서 지표를 가드레일로 두고 하락 시 속도 조절	메타 사례
Q12	직군과 직함을 합치는가	유지, 역할 언어만 추가, 통합	유지하고 역할 언어를 추가	9.1절
Q13	협력사 인력을 어떻게 다루는가	자사 한정, 계약에 반영	계약, 환경, 교육, 게이트를 소속 무관하게 적용	9.4절
Q14	계약 모델과 고객 고지를 어떻게 하는가	4개 옵션, 고지 수준	파일럿 데이터 후 결정, 사업 착수 시 합의와 기록	11장
Q15	확산을 도구에 거는가, 흐름에 거는가	도구 배포, 흐름의 트리거	흐름의 트리거에 심기	5.5절

13.1 이 문서가 정해 주지 않는 것

이 문서는 다음을 일부러 정하지 않았습니다. 기간(단계별 소요), 인원(리뷰어 수, 플랫폼팀 규모), 임계값(승급 기준, 가드레일의 선), 법률 해석, 계약 문구입니다. 이런 값은 조직의 규모, 고객 구성, 데이터에 따라 달라지고, 근거 없는 숫자를 제시하는 것은 이 문서가 지키려는 원칙에 어긋나기 때문입니다.

14. AIDD(AI-Driven Development) 가이드

이 장은 AIDD를 SI/SM의 게이트 우선 방법론 안에서 올바르게 쓰는 방법을 다룹니다. 앞의 장들이 “무엇을 어디까지 AI에게 맡기고, 무엇으로 막고, 누가 책임지는가”를 정했다면, 이 장은 그 틀 안에서 개발 일을 AI가 앞서 끌고 갈 때 사람과 AI가 어떤 순서로 무엇을 주고받는가를 정합니다. 바로 붙여 넣어 쓸 수 있는 프롬프트는 부록 D에, Claude Code에서 쓰는 SKILL 파일은 부록 E에 있습니다.

알고 싶은 것	볼 곳
AIDD가 정확히 무엇인가	14.1, 14.2
독립 자료는 무엇을 경고하는가	14.3
이 문서의 게이트와 어떻게 맞물리는가	14.4
실제로 어떤 순서로 하는가	14.5
SI와 SM에서는 어떻게 달라지는가	14.6
흔한 잘못과 바로잡는 법	14.7
팀에 어떻게 들이고 어떻게 평가하는가	14.8
복사해서 쓸 프롬프트와 SKILL	부록 D, 부록 E

14.1 AIDD라는 말부터 정리하기

먼저 분명히 해 둘 점이 있습니다. AIDD에는 하나의 표준 정의가 없습니다. 이번에 직접 열어 확인한 쓰임새는 아래와 같고, 서로 같은 것이 아닙니다.

쓰임새	가리키는 것	확인한 방법과 강도	이 문서에서의 자리
AWS의 AI-DLC	AWS가 2025-07-31 DevOps 블로그에서 소개한 AI-Driven Development Life Cycle. 소프트웨어 개발 과정을 AI 중심으로 다시 짠 방법론이고, 같은 이름의 오픈소스 저장소(`awslabs/aidlc-workflows`)가 있습니다	AWS 블로그와 저장소 페이지를 직접 열어 확인. 이 방법론이 스스로를 설명한 내용에 대해서는 강	이 장의 기준 참조
`paralleldrive/aidd`	“AI Driven Development”를 내세운 오픈소스 프레임워크. CLI, 에이전트 실행 환경, 의사코드 프롬프트 언어(SudoLang), 프로젝트 비전 문서(`vision.md`)로 구성됩니다. MIT 라이선스	GitHub 페이지를 직접 확인. 표시된 별 378개, 커밋 317개로 규모는 작음. 최근 커밋 날짜는 페이지에서 확인하지 못함	개념 참고만 (14.5의 `vision.md` 발상)
총칭	AI가 개발의 많은 부분을 이끌어 가는 개발 방식을 두루 가리키는 느슨한 말	바이브 코딩, 스펙 주도 개발과 비교하는 해설 글이 검색에 여러 편 보이나, 글마다 정의가 다르고 일부는 원문을 열 수 없어 근거로 쓰지 않음	이 문서가 아래 약속으로 쓰는 의미

[한계] AIDD라는 약자가 다른 분야에서 쓰이는 경우가 있을 수 있으나 이번 조사에서는 확인하지 않았고, 이 문서와 관계가 없습니다.

이 문서의 약속

[제안] 이 문서에서 AIDD는 AI가 질문, 계획, 구현 초안, 테스트 초안 같은 일상 작업을 앞서 이끌고, 사람은 의도와 결정과 승인과 책임을 쥐는 개발 방식을 뜻합니다. [풀이] AWS 블로그가 AI-DLC의 핵심으로 내세운 “AI 기반 실행과 사람의 감독”을 SI/SM의 말로 풀어 쓴 것입니다. 이 약속은 이 문서 안에서만 통하는 정의이며, 업계 표준이라고 주장하지 않습니다.

비슷해 보이는 두 방식과 구분하면 AIDD의 자리가 분명해집니다. 아래 표의 세 열은 모두 이 문서의 약속입니다.

구분	바이브 코딩	AIDD	AI 자율
시작	프롬프트 한 줄	의도 → AI의 질문 → 사람의 답	목표만 전달
기준	결과를 보고 마음에 들면 통과	승인된 명세와 수용 기준	AI의 판단
사람의 자리	결과를 보고 수정을 요청	의도를 밝히고, 결정하고, 승인하고, 검증	결과를 받음
검증	실행해 보고	명세에서 나온 테스트와 사람의 리뷰	에이전트의 자체 검증
이 문서의 위치	개인 실험과 시제품에 한정, 고객 산출물에는 쓰지 않음	SI/SM 업무의 기본값	위험이 낮고 사전 승인된 범위의 L4에 한정

14.2 AWS AI-DLC가 실제로 말하는 것

이 절은 [근거]로 채웁니다. AI-DLC가 무엇을 주장하는지와, 그 주장 가운데 독립적으로 확인되지 않은 것을 함께 적습니다.

블로그가 설명하는 방법론

[근거] (강, AWS 공식 글) AWS DevOps 블로그(2025-07-31, 저자 Raja SP)와 한국어 AWS 기술 블로그는 AI-DLC의 핵심을 다음과 같이 설명합니다.

AI 기반 실행과 사람의 감독. AI가 상세한 작업 계획을 세우고, 불명확한 부분은 설명이나 지침을 요청하며, 중요한 결정은 사람에게 맡깁니다. 원문은 사람만이 상황과 비즈니스 요구사항을 이해하고 정보에 기반한 선택을 할 수 있다는 점을 이유로 듭니다.
동적 팀 협업. AI가 일상 작업을 하는 동안 팀은 협업 공간에 모여 실시간으로 문제를 풀고 결정합니다.
맥락의 지속성. 한국어 기술 블로그 판은 계획, 요구사항, 설계 산출물을 프로젝트 저장소에 보관해 여러 세션에 걸쳐 작업의 연속성을 유지한다고 설명합니다.

방법론은 세 단계로 구성됩니다. 원문은 AI가 사람의 검증을 받은 뒤에만 솔루션을 구현한다고 적습니다.

단계	팀의 역할	AI의 역할
착수 (Inception)	Mob Elaboration: 팀 전체가 AI의 질문과 제안을 검증	비즈니스 의도를 상세한 요구사항, 스토리, 작업 단위로 변환
구축 (Construction)	Mob Construction: 기술 결정과 아키텍처 선택에 대해 실시간으로 설명	착수 단계에서 검증된 맥락을 바탕으로 논리 아키텍처, 도메인 모델, 코드, 테스트를 제안
운영 (Operations)	팀의 감독 아래 확인	쌓인 맥락을 적용해 코드형 인프라와 배포를 관리

용어도 바뀝니다. 전통적인 스프린트는 시간 또는 일 단위의 짧고 집중적인 볼트(Bolt) 로, 에픽은 작업 단위(Unit of Work) 로 대체됩니다.

[한계] 블로그 원문에는 승인 절차의 세부 구조와 역할 정의, 산출물의 정식 목록과 템플릿, 몹 세션의 진행 시간과 인원, 성과 지표와 도입 사례의 수치가 없습니다. 이런 세부는 아래 저장소와 각 회사의 해석에서 가져오게 되며, 방법론 자체가 정해 준 것이 아닙니다.

저장소가 보여 주는 구현

[근거] (강, 공식 저장소 README) awslabs/aidlc-workflows는 AI 코딩 에이전트를 위한 적응형 워크플로 규칙을 담은 오픈소스입니다. README의 서술은 다음과 같습니다.

규모. 5개 phase(Initialization, Ideation, Inception, Construction, Operation), 33개 stage, 14개 에이전트(도메인 전문가 11개, 검토 전용 리뷰어 2개, 작업에 맞춰 단계 계획을 제안하는 composer 1개).
적응형 범위. 큰 조직용(enterprise)부터 가장 가벼운 것(express)까지 11개의 scope가 있고 기본값은 classic입니다. 이와 별도로 깊이 3단계(Minimal, Standard, Comprehensive)와 테스트 전략 3단계가 있습니다.
승인 게이트. 모든 단계에 승인 게이트가 있고, 사용자가 모든 결정을 승인해야 다음 단계가 시작됩니다.
산출물의 위치. 프로젝트에 복사하는 aidlc/ 작업 공간에 방법론 메모리, 상태, 감사 로그 조각, 산출물을 두고 git으로 함께 관리합니다. 사용자별 커서와 로컬 실행 파일은 git에서 제외합니다.
도구. 하나의 도구 중립 코어를 여러 도구에서 실행합니다.

도구	호출 방식
Claude Code	`/aidlc`
Kiro CLI, Cursor, opencode, GitHub Copilot	`/aidlc`
Kiro IDE	에이전트 선택기에서 aidlc 선택
Codex CLI	`$aidlc`

라이선스와 규모. MIT-0 라이선스. 확인 시점의 버전 배지는 2.10.0, 커밋은 678개로 표시되었습니다. 최소 지원 버전은 README에 도구마다 적혀 있으므로 설치 전에 확인하십시오.
README의 경고. 생성물과 비용을 검토한 뒤 실행하라고 적습니다. Kiro IDE에서는 신뢰하지 않는 폴더의 .kiro 훅이 명령을 실행할 수 있으므로 직접 만들었거나 확인한 프로젝트만 신뢰하라고 하고, Codex에서는 프로젝트 훅을 신뢰로 설정해야 동작합니다.

[한계] README에서 stage 33개의 이름과 phase별 역할 설명은 확인하지 못했습니다(상세 문서로 가는 링크만 확인). 블로그의 착수, 구축, 운영이 저장소에서는 Inception, Construction, Operation으로 이어지고 앞에 Initialization과 Ideation이 더해진 것으로 읽히지만, 이는 이름의 유사성에 따른 [풀이] 이며 공식 대응표를 확인한 것이 아닙니다.

한국에서의 소개

[근거] (중, 언론 보도) AWS 코리아가 2026-07-16 연 설명회를 다룬 기사들(벤처스퀘어, 다음 뉴스, 바이라인네트워크)은 AI-DLC의 특징으로 단계별 승인 게이트, 감사 추적, 컨텍스트 관리를 소개하고, 개발자의 역할을 설계자이자 검증자로 설명했다고 전합니다. 같은 기사들에 11개 전문 에이전트 언급이 있어 저장소의 도메인 전문가 11개와 맞닿습니다. 기사 본문에서 일부 발표자의 이름과 소속 표기가 서로 어긋나는 곳이 있어 이 문서는 개인 이름을 인용하지 않습니다.

읽을 때 조심할 주장

AI-DLC를 소개하는 자료에는 효과를 말하는 수치가 많이 따라붙습니다. SI/SM의 의사결정에 쓰려면 아래 구분이 필요합니다.

주장	출처의 성격	이 문서의 취급
“AI 도입 조직의 94%가 기대한 성과를 내지 못했다”(CircleCI 2026 인용으로 보도)	설명회 발표 인용. 원 조사와 표본을 확인하지 못함	방향성 참고. 근거로 쓰지 않음
Kiro 사용 시 비용이 1/6에서 1/10 수준	도구 업체의 주장	채택하지 않음. 파일럿에서 총비용으로 측정 (10.2절)
LG전자의 투입 공수 6.0에서 3.0 M/M, 스프린트 2주에서 1주	행사에서의 사례 발표. 측정 조건 확인 못함	채택하지 않음
CJ올리브영의 MVP 5개를 3일 만에	행사에서의 사례 발표	시제품 속도의 사례일 뿐 운영 증거가 아님
AWS Summit Seoul AI-DLC 챌린지 수상작(현대해상, LG유플러스, SK AX)	챌린지형 시제품	운영 증거가 아님
취약점 증가 등 외부 수치 여러 개	발표 자료의 재인용. 원 조사를 이번에 열어 보지 못함	3.4절에서 직접 확인한 연구만 인용

[풀이] 위 표의 주장이 틀렸다는 뜻이 아닙니다. 확인하지 못했고, 대부분 방법론을 파는 쪽의 발표이거나 시제품 단계의 사례라는 뜻입니다. SI/SM 대기업이 이 방법론을 들일 때 필요한 것은 이런 수치가 아니라, 14.8절의 방식으로 자기 업무에서 직접 재는 값입니다.

14.3 독립 자료는 무엇을 경고하는가

AIDD를 소개하는 쪽과 별개로, 같은 흐름을 독립적으로 살핀 자료가 두 가지 있습니다.

스펙 주도 개발에 대한 분석. Martin Fowler 사이트에 실린 글(2025-10-15, 작성자 Birgitta Böckeler)은 명세를 중심에 두는 도구 세 가지(Kiro, GitHub Spec Kit, Tessl)를 직접 써 보고 정리했습니다(강도 중, 개인 분석이나 독립적임). 이 글은 명세와 AI 개발의 관계를 세 수준으로 나눕니다.

수준	뜻
spec-first	명세를 먼저 쓰고 그것으로 AI 개발을 이끌되, 작업이 끝나면 명세를 버릴 수 있음
spec-anchored	작업 뒤에도 명세를 유지하며 기능의 진화와 유지보수에 계속 씀
spec-as-source	사람은 명세만 고치고 코드는 생성물로 취급

그리고 다음 우려를 적습니다.

작은 일에도 무거운 요구사항 문서를 만들어 내는 등 작업 크기와 워크플로가 맞지 않을 수 있음
장황한 마크다운 명세를 검토하는 부담이 코드 리뷰보다 클 수 있음
명세를 쓰면 에이전트가 따를 것이라는 통제감의 착각
과거 모델 주도 개발의 경직성과, 생성의 비결정성이 겹칠 수 있다는 우려
‘스펙’이라는 말의 의미가 흐려지는 문제

참고로 공식 페이지 기준으로 Kiro의 명세는 requirements.md, design.md, tasks.md 세 파일이고 기능 명세는 사용자 스토리와 수용 기준을 씁니다. GitHub Spec Kit(MIT)은 원칙을 정하는 constitution, 무엇을 만들지 쓰는 specify, 계획을 세우는 plan, 작업을 나누는 tasks, 구현하는 implement, 구현과 산출물의 일치를 확인하는 converge 명령을 제공합니다. 이번에 연 Spec Kit 페이지에는 clarify나 analyze 같은 명령 이름이 나오지 않았습니다.

Thoughtworks Technology Radar 34호. 2026년 4월 발행된 이 호를 다룬 ITWire 기사(2026-04-16, 강도 중, 레이더 PDF 원문은 열지 않음)에 따르면 이번 호의 주제는 AI가 만든 코드가 늘면서 인지 부채(cognitive debt) 가 쌓여 사람과 소프트웨어 시스템 사이의 간극이 벌어진다는 경고입니다. 개발자가 자기가 만드는 시스템을 계속 이해하도록 이 부채를 관리해야 한다고 합니다. 또한 코딩 에이전트에 통제를 거는 방법으로, 사전 통제(feedforward)에 Agent Skills와 스펙 주도 개발을, 사후 통제(feedback)에 뮤테이션 테스팅을 들었습니다. 가장 쓸모 있는 에이전트일수록 민감 데이터와 외부 시스템에 대한 권한을 많이 요구하므로 제로 트러스트, 샌드박스 실행, 다층 방어가 필수가 되었다는 지적도 있습니다. 인지 부채의 정확한 정의와 측정법은 기사에 없습니다.

[풀이] 두 자료와 이 문서를 겹쳐 보면 AIDD의 통제 장치는 세 층으로 정리됩니다. 아래 표의 대응은 제 해석입니다.

통제의 성격	예	이 문서의 게이트
사전 통제: 일하기 전에 방향을 잡음	승인된 명세, 프롬프트 템플릿, SKILL 파일, 지침 파일	G1, G2
사후 통제: 일한 뒤에 걸러 냄	테스트, 정적 분석, 뮤테이션 테스트, 사람의 리뷰	G3, G4
권한 통제: 할 수 있는 일 자체를 제한	샌드박스, 권한 규칙, 승인 절차	G1, 방식 B

그리고 “인지 부채”는 이 문서의 R2(리뷰어가 정의된 점검 항목을 수행할 책임을 진다)와 같은 방향의 위험으로 읽을 수 있습니다. 리뷰어가 변경을 이해하지 못한 채 승인하면 책임만 남고 통제는 사라집니다. 14.4절의 원칙 7이 이 위험에 대응합니다.

14.4 게이트 우선 방법론 위에 AIDD 놓기

14.4.1 전체 흐름

[제안] AIDD의 일곱 가지 절차(14.5절)를 6.1절의 게이트에 걸치면 아래와 같습니다. 핵심은 AI가 앞서 끌고 가더라도 게이트의 위치와 사람의 승인 지점은 그대로라는 점입니다.

flowchart LR
  INTENT["업무 의도: 티켓, 요구"] --> G1["G1 입력 확인"]
  G1 --> ELAB["AI가 질문하고 사람이 답함"]
  ELAB --> SPEC["명세 초안과 점검"]
  SPEC --> G2["G2 사람이 명세 승인"]
  G2 --> UNIT["업무 단위로 분해"]
  UNIT --> TEST["수용 기준에서 테스트 먼저"]
  TEST --> BUILD["AI가 구현 초안"]
  BUILD --> G3["G3 변경 게이트"]
  G3 --> G4["G4 검증 게이트"]
  G4 --> REL["G5, G6 배포와 고객 확인"]
  REL --> OPS["G7 운영"]
  OPS --> LEARN["G8 학습: 명세와 SKILL 개정"]
  LEARN -.->|"사고와 반려를 반영"| INTENT
  G3 -.->|"반려"| BUILD
  G4 -.->|"명세와 불일치"| ELAB

14.4.2 AI-DLC의 요소를 이 문서에 대응시키기

[풀이] 아래는 AI-DLC의 요소를 이 문서의 개념에 어림 대응시킨 것이며, 공식 대응표가 아닙니다.

AI-DLC의 요소	이 문서의 대응	달라지는 점
착수 단계, Mob Elaboration	G1 입력과 G2 명세의 준비 작업	SI에서는 고객과 합의할 항목이 있고, 고객이 동석할 수 있는지는 계약과 보안 조항에 따릅니다
Unit of Work (에픽의 대체)	업무 단위 (4.3절)	위험 등급과 자율성 등급을 업무 단위마다 붙입니다
Bolt (스프린트의 대체)	리뷰할 수 있는 작은 묶음 (6.2절의 작은 배치)	고객 대면 일정, 검수 주기, 계약상 마일스톤은 대체하지 않습니다
구축 단계, Mob Construction	G3 변경과 G4 검증	기술 결정은 사람이 설명받고 확정합니다
운영 단계	G5 배포, G7 운영	자동 실행(L4)은 사전 승인된 런북에 한정합니다 (8.3절)
모든 단계의 승인 게이트	방식 A(사람 확인)	모든 단계에 같은 강도로 걸지 않고 위험 등급에 따라 고르며, 방식 B로 보강합니다
저장소에 보관하는 맥락	R3 추적성, 지식 문서의 소유자와 유효 기간 (8.5절)	보관물에 고객 정보가 섞이지 않게 G1에서 점검합니다
감사 추적	R3, G7의 감사 로그	AI가 관여한 산출물의 도구와 입력을 남깁니다

14.4.3 AIDD 운영 원칙 일곱 가지

[제안] 이 문서의 AIDD는 다음 일곱 원칙을 따릅니다. 부록의 프롬프트와 SKILL은 이 원칙을 문장으로 옮긴 것입니다.

번호	원칙	풀이
1	질문이 구현보다 먼저다	AI는 구현하기 전에 질문하고, 사람이 답한 뒤에 쓴다. AWS 블로그가 설명한 순서(AI가 계획하고 질문하고, 사람이 검증한 뒤 구현)와 같은 방향
2	명세가 기준이고 AI의 산출물은 후보다	코드와 문서는 승인된 명세에 비추어 판정한다
3	리뷰할 수 있는 크기로만 맡긴다	한 번에 한 업무 단위. 크기를 넘으면 쪼갠다
4	기대 결과의 출처는 명세와 사람이다	AI가 쓴 코드의 기대 결과를 AI의 구현에서 가져오지 않는다 (7.2절의 순환 문제)
5	승인은 고르고, 강제는 시스템에 맡긴다	사람의 승인은 위험이 큰 곳에 집중하고, 지켜야 할 규칙은 권한과 CI가 막는다
6	맥락은 파일로 남긴다	대화에만 있는 결정은 세션이 끊기면 사라진다. 명세, 결정 기록, 지침 파일에 남긴다
7	설명할 수 없는 변경은 병합하지 않는다	승인자는 변경의 의도와 영향을 자기 말로 설명할 수 있어야 한다. 인지 부채에 대한 대응

14.4.4 지침과 통제를 구분하기

AIDD를 도입할 때 가장 흔한 오해가 프롬프트나 SKILL에 “하지 마라”고 적어 두면 막힌다고 믿는 것입니다. 프롬프트와 SKILL은 에이전트가 따르도록 요청하는 층이고, 어기면 막히는 층은 따로 있어야 합니다.

flowchart LR
  subgraph GUIDE["지침층: 요청"]
    P1["프롬프트"]
    P2["SKILL 파일"]
    P3["CLAUDE.md 같은 지침 파일"]
  end
  AGENT["AI 에이전트의 작업"]
  subgraph ENFORCE["통제층: 시스템 차단"]
    E1["권한 규칙 deny와 ask"]
    E2["샌드박스"]
    E3["CI와 보호 브랜치"]
  end
  subgraph HUMAN["판단층: 사람"]
    H1["명세 승인"]
    H2["변경 승인"]
  end
  P1 --> AGENT
  P2 --> AGENT
  P3 --> AGENT
  H1 --> AGENT
  AGENT --> E1
  E1 --> E2
  E2 --> E3
  E3 --> H2
  H2 -.->|"사고와 반려를 반영해 개정"| P2

[근거] (강, Claude Code 공식 문서) 이 구분은 도구 문서에도 그대로 나타납니다.

SKILL의 allowed-tools는 제한이 아니라 사전 승인입니다. 문서는 모든 도구가 계속 호출 가능하며, 나열되지 않은 도구는 권한 설정의 적용을 받는다고 밝힙니다. 도구를 못 쓰게 하려면 disallowed-tools를 쓰는데, 이 제한은 다음 메시지를 보내면 풀립니다.
권한 규칙은 deny, ask, allow 순으로 평가하고 처음 일치한 규칙이 결과를 정합니다. 넓은 deny 규칙은 더 좁은 allow 규칙이 있어도 막습니다.
문서는 저장소에 들어 있는 SKILL의 allowed-tools가 스스로 넓은 도구 권한을 줄 수 있으므로, 그 저장소에서 실행하기 전에 검토하라고 경고합니다.
Bash 규칙으로 인자를 제한하는 방식은 깨지기 쉽고, curl을 막는 규칙도 경로를 풀어 쓴 호출이나 sh -c 안의 호출은 잡지 못합니다. 문서는 그런 제한이 꼭 지켜져야 하면 샌드박스의 네트워크 허용 목록을 함께 쓰라고 안내합니다.
프로젝트에 .claudeignore 파일이 있어도 효과가 없으므로, 읽기를 막으려면 Read deny 규칙으로 옮기라고 합니다.

따라서 이 문서는 프롬프트와 SKILL을 게이트로 세지 않습니다. 부록 E의 SKILL은 일을 정확하고 균일하게 하도록 돕는 장치이고, G1과 G3의 방식 B는 권한 규칙, 샌드박스, CI가 맡습니다(부록 E-8).

14.5 단계별 실무 가이드

[제안] AIDD로 한 개의 업무를 처리하는 절차는 일곱 개입니다. 위험이 낮은 작은 업무에는 이를 줄여 쓰는 방법을 14.6절에서 다룹니다.

절차	하는 일	AI의 몫	사람의 몫	남는 산출물	게이트	부록
1 맥락 준비	지침 파일, 권한, 명세와 결정 기록의 위치 정하기	기존 코드 요약(L1)	환경 확인, 규칙 확정	지침 파일, 권한 설정	G1	E-8
2 의도 정교화	AI가 질문하고 사람이 답해 요구를 구체화	질문, 가정 목록, 초안	답변, 우선순위, 고객 확인 필요 표시	요구사항 초안	G1	D-2, E-1
3 명세 점검과 승인	모순, 누락, 측정 불가 표현 찾기	점검(L1)	해결과 승인	승인된 명세(버전, 승인자)	G2	D-3, E-2
4 업무 단위 분해	단위로 쪼개고 위험과 자율성 등급 정하기	분해안과 등급 제안	등급 확정	업무 단위 표	G2	D-4, E-3
5 설계와 테스트 먼저	설계 대안 비교, 수용 기준에서 테스트 도출	대안, 테스트 목록과 코드	설계 결정, 테스트 목록 확인	결정 기록, 실패하는 테스트	G2, G4	D-5, D-6, E-4
6 구현	계획을 승인받고 한 단위씩 구현	계획과 구현 초안(L2, 비운영 환경 한정 L3)	계획 승인	변경(PR), 변경 요약	G3	D-7
7 리뷰, 검증, 학습	변경 검토, 추적성 확인, 반영, 사고 후 개정	검토 보조, 기록 초안	리뷰와 승인, 책임	승인 기록, AI 관여 기록, 개정안	G3~G8	D-8, D-9, D-13~D-15, E-5, E-7

절차 1. 맥락 준비

착수 전에 한 번 해 두는 일입니다. [제안] 저장소에 명세와 결정 기록을 둘 위치를 정하고, 지침 파일에 이 업무의 규칙(범위, 금지, 멈춤 조건)을 적고, 권한 규칙과 보호 브랜치를 설정합니다. 이 문서가 5.1절에서 말한 “선언은 인프라 뒤에”의 개발 현장 버전입니다. 허용 환경이 아니거나 고객이 AI 사용을 허용하지 않은 사업이라면 L0이므로 여기서 멈춥니다.

paralleldrive/aidd는 프로젝트 루트에 vision.md를 두고 에이전트가 이를 기준 자료로 삼게 합니다. 권장 항목은 개요, 목표, 비목표, 핵심 제약, 아키텍처 결정, 사용자 경험 원칙, 성공 기준이며, 작업이 비전과 충돌하면 진행 전에 사람에게 확인을 요청하도록 설계되어 있다고 합니다. [풀이] 이 발상은 도구와 무관하게 쓸 수 있습니다. 명세 폴더 맨 앞에 목표, 비목표, 제약을 적은 한 장짜리 문서를 두면 에이전트가 범위를 넘는 일을 줄일 수 있습니다. 효과는 확인하지 못한 가설입니다.

절차 2. 의도 정교화: 질문이 먼저다

사람이 요구를 던지면 AI는 구현을 시작하지 않고 질문부터 합니다. AI-DLC 블로그가 설명한 순서와 같은 방향입니다. 이 단계에서 AI가 해야 할 일은 세 가지입니다. 요구를 한 문단으로 되풀이해 의도가 맞는지 확인하고, 구현 결과를 바꿀 질문을 우선순위로 정리하고, 답이 오기 전에 둘 수밖에 없는 가정을 따로 모아 틀렸을 때의 영향과 함께 적습니다.

SI에서는 질문의 답이 고객과 합의해야 하는 것일 수 있습니다. 이럴 때 사람은 답을 만들어 내지 않고 “고객 확인 필요”로 표시해 미결 사항에 올립니다. 미결 사항 가운데 구현 결과를 바꾸는 것이 남아 있으면 다음 절차로 가지 않습니다.

절차 3. 명세 점검과 승인

요구사항 초안은 AI가 먼저 점검합니다. 모순되는 요구, 빠진 예외, 측정할 수 없는 표현(“빠르게”, “안전하게”)을 찾고, 판정이 아니라 승인 전에 해결해야 할 항목으로 올립니다. 점검은 읽기만 하는 L1 작업입니다. 승인은 사람이 하며(G2), 위험이 높은 업무는 아키텍트와 보안 담당이 함께 봅니다. 승인된 명세에는 버전, 승인자, 일시를 남깁니다. 승인 전에는 구현하지 않습니다.

절차 4. 업무 단위 분해와 등급 결정

승인된 명세를 업무 단위로 쪼갭니다. 한 단위는 한 사람이 한 번에 리뷰할 수 있는 크기여야 합니다(6.2절). 구체적인 크기 기준은 이 문서가 정하지 않고(13.1절) 팀이 파일럿에서 정합니다. AI는 4.4절의 세 질문(영향 범위, 되돌림 난이도, 데이터 민감도)으로 위험 등급을 제안하고 4.4절의 표에 따라 자율성 상한을 제안합니다. 등급을 확정하는 것은 사람입니다. 위험이 높음 이상인 단위는 L2 이하로 제안하도록 지시합니다.

절차 5. 설계 결정과 테스트 먼저

설계에서는 AI가 대안과 장단점을 제시하고 결정은 사람이 합니다. 결정은 이유와 함께 결정 기록으로 남깁니다. 그다음 승인된 수용 기준에서 테스트를 먼저 도출합니다. 이 순서가 원칙 4(기대 결과의 출처는 명세)를 지키는 가장 쉬운 방법입니다. 구현을 먼저 하고 그 코드를 읽어 테스트를 쓰면, 코드가 하는 일이 그대로 기대 결과가 되어 오해까지 함께 통과합니다. 테스트를 먼저 쓰고 실행해 실패하는 것을 확인한 뒤에 구현으로 넘어갑니다. 이때 실패 원인이 기대 결과 때문인지 환경 문제 때문인지 구분해 보고하게 합니다.

절차 6. 구현: 계획, 승인, 구현

구현은 한 업무 단위씩 합니다. AI가 먼저 계획(바꿀 파일, 바꾸지 않을 파일, 영향 범위, 되돌리는 방법)을 내고, 사람이 승인하면 구현합니다. 계획에 없는 변경이 필요해지면 멈추고 묻게 합니다. 쓰기 권한은 일부러 사전 승인하지 않는 편이 좋습니다. 도구의 승인 화면이 사람이 한 번 더 확인하는 지점이 되기 때문입니다.

절차 7. 리뷰, 검증, 반영, 학습

변경은 G3의 자동 검사를 먼저 통과하고, 사람이 리뷰합니다. AI의 검토는 사람 리뷰의 보조입니다(6.2절, R2). AI 검토는 근거(파일과 줄 번호)가 있는 지적만 하고, 승인이나 반려를 결정하지 않습니다. 이어서 명세, 설계, 코드, 테스트의 연결(추적성)을 점검하고, AI가 관여한 산출물의 도구와 입력을 기록합니다(R3). 사고나 반려가 나오면 원인을 게이트 단위로 분석해 프롬프트, SKILL, 권한 규칙, 게이트 정의 중 무엇을 고칠지 정합니다(G8).

14.6 SI와 SM에서의 적용

SI: 가치흐름 단계와 AIDD 절차

SI 단계 (7.1절)	대응하는 AIDD 절차	유의점
1 제안과 견적	절차 2의 일부 (요구 분석)	약속이 계약이 되므로 L2. 가격과 범위는 사람이 쥠
2 요구사항 분석	절차 2, 3	고객과 합의할 항목은 “고객 확인 필요”로 표시. 명세 변경은 계약의 변경 요청 절차와 연결
3 설계	절차 5의 설계	아키텍처 결정은 사람. 비기능 요구의 값은 AI가 정하지 않음
4 개발	절차 4~7	업무 단위마다 등급. 운영 반영 대상은 L2
5 테스트	절차 5의 테스트 먼저, G4	기대 결과는 고객 승인된 명세에서
6 이행과 배포	절차 7의 이후	이행 계획 초안은 L2. 반영 판단은 사람
7 검수와 인수	절차 7의 추적성과 AI 관여 기록	고객에게 제출할 수 있는 증거로 쓰되 고객 검수 권한은 그대로
8 안정화와 하자보수	SM의 흐름과 합류	아래 SM 표

SI에서 특히 조심할 세 가지. 첫째, 명세 변경은 곧 계약 변경일 수 있습니다. AI가 명세를 매끄럽게 고쳐 주더라도 범위가 바뀐 부분은 변경 요청으로 올립니다. 둘째, 볼트(짧은 작업 주기)를 도입해도 고객 검수 주기와 마일스톤은 그대로입니다. 내부 작업 주기와 대외 일정을 섞지 않습니다. 셋째, 감리 대상 산출물은 명세와 코드에서 자동으로 만들 수 있지만 사람이 승인해야 합니다. 이 점은 7.3절의 추적성 쟁점과 이어집니다.

SM: 티켓 흐름과 AIDD 절차

SM에서는 같은 원칙을 티켓의 흐름에 입힙니다.

티켓 단계 (8.1절)	AIDD의 모습	자율성	부록
접수, 분류	증상을 정리하고 담당과 우선순위를 제안	L1~L2	D-10
원인 분석	로그와 지표를 근거로 가설과 반증을 제시. 조치는 제안하지 않음	L1	D-10, E-6
조치안 작성	사전 승인된 런북 범위에서만 조치안을 작성	L2	D-11
승인	G7. 승인 등급에 따라 사람이 승인	사람
실행, 검증	승인된 범위의 실행. L3 이상은 8.2절의 조건을 따름	L3~L4 한정
지식화	런북과 장애 이력 갱신. 소유자와 유효 기간 붙임	L2	D-14, D-15

[제안] 부록의 프롬프트와 SKILL은 SM의 분석과 조치안 작성까지만 다룹니다. 운영 환경에서 실행하는 프롬프트나 SKILL은 일부러 싣지 않았습니다. 8.3절의 원칙대로 분석과 조치를 분리하고, 실행은 사전 승인된 런북과 시스템 쪽 장치(권한, 감사 로그)가 준비된 뒤에 별도로 설계해야 하기 때문입니다.

업무 크기에 맞춘 깊이

[풀이] Fowler의 글이 지적한 “작업 크기와 워크플로의 불일치”를 피하려면 일곱 절차를 모든 일에 똑같이 적용하면 안 됩니다. AI-DLC 저장소도 범위(express부터 enterprise까지)와 깊이(Minimal, Standard, Comprehensive)의 등급을 둔다고 적습니다. 아래 표는 그 발상을 이 문서의 위험 등급에 맞춰 제가 구성한 안이며, 저장소의 분류와 같은 것이 아닙니다.

깊이	적용 대상	명세	승인	절차
최소	위험 낮음, 한 곳을 고치는 작은 일	의도 한 문단과 수용 기준 1~3개	자동 검사, 사람 리뷰는 표본 점검	2(축약), 5의 테스트, 6, 7
표준	위험 보통	요구와 수용 기준, 비기능 요구 중 해당 항목	작성자와 다른 리뷰어 1인	1~7
충분	위험 높음 이상	전체 명세, 설계 결정 기록, 추적성	승인자 분리, 전문가 리뷰, 필요하면 고객 사전 합의	1~7 전부와 G5, G6

14.7 흔한 잘못과 바로잡는 법

번호	잘못	왜 문제인가	바로잡는 법
A1	명세 없이 바로 구현을 시킨다	기준이 없어 결과가 마음에 드는지로 판정하게 됨 (바이브 코딩)	절차 2, 3을 먼저. 작은 일은 최소 깊이로 줄이되 수용 기준은 남김
A2	명세를 지나치게 장황하게 쓴다	검토 부담이 커지고 통제의 착각이 생김 (Fowler)	위험 등급별 깊이. 수용 기준은 짧고 검증 가능하게
A3	모든 단계에 같은 강도로 승인을 건다	승인 피로로 형식적 승인이 늘고 병목이 생김 (F7)	위험이 큰 곳에 승인을 집중하고 나머지는 방식 B
A4	AI가 쓴 코드를 AI가 만든 테스트로 검증한다	같은 오해를 공유함 (7.2절)	테스트의 기대 결과를 명세에서 도출. 절차 5
A5	프롬프트나 SKILL을 보안 통제로 믿는다	어겨도 막히지 않음 (14.4.4)	권한 규칙, 샌드박스, CI로 강제
A6	모든 규칙을 한 파일에 몰아넣는다	컨텍스트가 비대해져 핵심 규칙이 묻힘	지침 파일은 짧게, 절차는 SKILL로 나누고 상세는 보조 파일로
A7	승인자가 변경을 이해하지 못한 채 승인한다	인지 부채가 쌓이고 책임만 남음	원칙 7. 설명을 요청하는 항목을 리뷰에 포함
A8	벤더나 행사의 수치를 도입 근거로 삼는다	측정 조건을 모름 (14.2절)	파일럿에서 자기 업무의 값을 측정 (14.8절)
A9	대화에만 결정을 남긴다	세션이 끊기면 사라지고 추적할 수 없음	결정 기록, 명세, 지침 파일에 남김. 프롬프트 D-14
A10	큰 변경을 한 번에 맡긴다	리뷰 품질이 떨어짐 (Faros: 리뷰 시간 91% 증가)	업무 단위로 분해. 절차 4
A11	고객 데이터를 허용되지 않은 도구에 붙여 넣는다	G1 위반이자 계약 위반	비식별 처리, 허용 도구 목록, L0 환경 구분
A12	외부에서 받은 SKILL이나 훅을 검토 없이 쓴다	도구 권한을 스스로 넓히거나 명령을 실행할 수 있음	저장소에 넣기 전에 코드 리뷰. `allowed-tools`와 실행 파일을 확인

14.8 팀에 들이고 평가하는 방법

들이는 순서

[제안] AIDD는 한 번에 도입하지 않고 세 단계로 쌓습니다. 5장의 로드맵 가운데 단계2(게이트 구축)부터 단계4(확산)에 걸칩니다.

순서	내용	자율성	5장의 단계
가	부록 D의 프롬프트를 팀 저장소의 문서로 두고 쓴다. 읽기와 제안 업무에서 시작한다	L1~L2	단계2~3
나	반복해서 쓰는 프롬프트를 SKILL로 바꾸고 저장소에서 코드 리뷰를 거쳐 관리한다	L1~L2 (비운영 환경 한정 L3 시험)	단계3
다	지켜야 할 규칙을 권한 규칙, CI, 보호 브랜치로 옮겨 강제한다	승급 심사에 따라	단계3~4

순서 “다”가 늦어지면 안 됩니다. 프롬프트와 SKILL이 늘어도 시스템이 막는 장치가 없으면 5.3절의 흔한 함정(규칙을 문서로만 두는 것)에 빠집니다.

SKILL 자체의 운영 규칙도 필요합니다. [제안] 스킬마다 소유자를 두고, 변경은 코드 리뷰를 거치며(G3), 모델이나 도구를 바꿀 때는 평가를 다시 돌리고(G8), 오래 쓰이지 않거나 틀린 결과가 반복되는 스킬은 폐기합니다. 스킬은 저장소의 일반 파일이므로 사내 저장소로 배포할 수 있고, 외부 서비스를 쓸 수 없는 환경에서도 같은 절차 문서로 활용할 수 있습니다(실제 실행은 허용된 도구에 달려 있습니다).

평가하는 방법

[근거] (중, Anthropic 공식 문서) Anthropic의 스킬 작성 모범 사례는 평가를 먼저 만들고 스킬을 쓰라고 권합니다. 스킬 없이 대표 작업을 실행해 실패와 빠진 맥락을 기록하고, 그 격차를 검증하는 시나리오를 최소 세 개 만들고, 스킬 없이 기준선을 잰 뒤, 격차를 메울 만큼만 최소한으로 쓰고, 기준선과 비교하며 다듬는 순서입니다. 같은 문서는 내장 평가 기능이 현재 없어 평가 체계를 직접 만들어야 한다고 적고, 여러 모델(Haiku, Sonnet, Opus)에서 시험하라고 권합니다. 또한 스킬을 설계하는 인스턴스와 그 스킬로 실제 작업을 하는 새 인스턴스를 나누어 관찰하는 방식을 소개합니다.

[제안] 이 방식을 이 문서의 지표에 맞춥니다.

평가 시나리오. 부록 E-9의 시나리오처럼 스킬마다 입력과 기대 행동을 정해 두고, 스킬이나 모델을 바꿀 때 다시 돌립니다.
성과 지표. 스킬을 얼마나 썼는지가 아니라 10장의 지표를 봅니다. 구체적으로 명세 단계에서 찾아낸 모순과 누락의 수, 리뷰 반려율, 재작업 시간, 결함 유출률, 리뷰 대기 시간입니다. 10.3절에 따라 사용량은 단독 지표로 쓰지 않습니다.
체감과 실측을 함께. 개발자가 빨라졌다고 느끼는지와 실제 리드타임이 줄었는지를 함께 봅니다(METR의 체감과 실측의 어긋남).
기록. 스킬이나 프롬프트를 따랐는데도 나온 결함과, 에이전트가 지침을 어긴 사례를 기록해 G8로 올립니다.

14.9 이 장의 한계

AIDD는 표준이 아닙니다. 이 장의 기준 참조는 AWS AI-DLC이고, 원칙과 절차는 제가 SI/SM 맥락에 맞춰 구성한 [제안]입니다. 파일럿에서 검증하기 전에는 가설입니다.
AI-DLC의 효과를 입증한 독립 자료를 확인하지 못했습니다. 효과 수치는 업체와 행사의 발표이거나 시제품 사례입니다.
저장소의 stage 세부와 phase별 역할을 확인하지 못했습니다. 이 장의 대응은 이름과 개념에 근거한 [풀이]입니다.
도구와 문서는 빠르게 바뀝니다. README의 버전과 명령, Claude Code의 SKILL 필드와 권한 문법은 2026-10-20에 확인한 기준이므로, 적용 전에 최신 문서를 확인하십시오.
SM의 운영 실행은 다루지 않았습니다. 분석과 조치안 작성까지만 다루었고, 자동 실행의 설계는 별도 작업입니다.
다른 도구에서의 동작을 확인하지 못했습니다. 부록 E는 Claude Code 기준입니다. Codex, Kiro, Cursor 등에서 같은 SKILL을 쓸 수 있는지는 확인하지 않았습니다.

부록 A. 방법론 요소와 근거의 대응

이 방법론의 요소가 어떤 근거 위에 서 있는지 한눈에 보도록 정리했습니다. 근거가 약한 요소는 파일럿에서 먼저 검증할 대상입니다.

방법론 요소	근거	강도	성격
게이트를 먼저 짓는 순서	epilot의 우회 배포 사고와 권한 잠금, 팀스파르타의 정기 배포와 E2E, 채널톡의 2인 리뷰와 머지 권한 분리	강	근거
전략과 약속은 위에서	아정당 문서의 24건 정리, 왓낫의 문서	중에서 약	근거
책임 규칙 R1, R2	왓낫, epilot, PostHog의 규정	약	근거(문서 기재)
책임 규칙 R3~R6	SI/SM의 계약 구조와 사고 사례	약	제안
역할 언어(아키타입)	Anthropic Boris Cherny의 2026-06-28 X 게시글	강	근거, SI/SM 대응은 제안
직함을 먼저 합치지 않음	아마존의 시험 단계 서술, 메타의 계획 일부 취소, 레브잇의 분화, 마이리얼트립의 규모	강에서 중	근거와 풀이
인프라 선행	듀오링고의 정정, 메타의 되돌림	강	근거
3층 지표와 가드레일	메타, METR, Faros, DORA, 레브잇(부분 확인)	강에서 중	근거와 제안
게이트 처리 용량	Faros 리뷰 시간 91% 증가, 버즈빌, 메타	중	근거와 제안
총비용에 검토와 재처리 포함	OpenAI 코리아 지사장 발언(삼성SDS 행사 보도)	중	근거
플랫폼팀의 “대신 만들지 않음”과 챔피언	마이리얼트립의 AI랩 종료(강), 나머지 사례(약)	약	근거와 제안
자율성 사다리	아정당 문서의 비개발 직군 범위 스펙트럼	약에서 중	제안
지식 문서의 소유자와 유효 기간	토스 사례(약), LG CNS 지식 기반(회사 주장), DORA 역량 모델(중)	약에서 중	근거와 제안
계약 인센티브 가설	KOSA 대가산정 가이드, 과기정통부 TF, UpperEdge	중에서 약	풀이(가설)
규제 반영	인공지능 기본법, 금융 망분리 추진, N²SF	중에서 강	근거
장애 대응 설계	SK브로드밴드 AIOps 사례(통신사, SM 사업자 아님)	약에서 중	근거와 제안
평가 설계	쇼피파이, 마이리얼트립, 아마존	강에서 약	근거와 제안
AIDD의 정의와 기준 참조	AWS DevOps 블로그와 한국어 AWS 기술 블로그, AI-DLC 저장소 README	강 (방법론이 스스로를 설명한 내용에 한함)	근거
AIDD의 일곱 절차와 일곱 원칙	AI-DLC의 착수, 구축, 운영 구조, Fowler 사이트의 스펙 주도 개발 분석, Thoughtworks 레이더 34호 보도	중	풀이와 제안
AI-DLC의 효과 수치	설명회 보도와 업체 주장	약	채택하지 않음
지침과 통제의 분리	Claude Code의 권한 문서와 SKILL 문서	강	근거
프롬프트 모음과 SKILL 모음	형식은 Claude Code SKILL 문서, Agent Skills 사양, Anthropic 작성 모범 사례. 내용은 이 문서의 설계	형식은 강, 내용은 약	근거와 제안

부록 B. 템플릿 모음

실무에서 바로 고쳐 쓸 수 있도록 항목만 정리했습니다. 값은 조직이 채웁니다.

B-1. 가치흐름 진단 시트

항목	채울 내용
업무 단위	업무의 이름과 한 줄 설명
소속	SI 단계 또는 SM 티켓 유형
현재 담당과 투입	담당 역할, 현재 투입공수
데이터 민감도	공개, 내부, 고객 기밀, 규제 대상
영향 범위	내부, 비운영, 고객 운영 시스템, 최종 사용자
되돌림 난이도	쉬움, 데이터 영향, 불가역
위험 등급	위 세 요소의 최댓값
현재 게이트	지금 지나는 확인 지점과 소유자
병목 여부	처리 용량이 한계에 가까운가
후보 AI 활용	어떤 일을 AI가 돕는가
초기 자율성 상한	L0에서 L4
베이스라인 지표	도입 전 측정값

B-2. 게이트 정의서

항목	채울 내용
게이트 ID와 이름	G1에서 G8 중 하나
지키는 질문	이 게이트가 확인하는 것
방식	A 사람 확인, B 시스템 차단, C 배포 리듬
적용 대상	업무 단위와 위험 등급
남기는 증거	기록, 로그, 서명
소유자	게이트 오너
처리 용량	대기 시간의 허용 범위(값은 조직이 정함), 리뷰어 수
반려와 강등	통과하지 못했을 때의 조치, 강등 트리거
예외 규칙	예외를 허용하는 조건과 승인자, 사후 점검
개정 이력	사고와 근접사고에 따른 개정 기록

B-3. 승급 심사표

심사 항목	확인 내용
대상	업무 단위, 현재 등급, 제안 등급
게이트 통과 기록	해당 업무의 통과와 반려 이력
가드레일 지표	심사 기간 동안 선 안에 있었는가
사고 이력	사고와 근접사고, 대응 결과
리뷰 용량	리뷰 대기 시간과 리뷰어 여유
고객 합의	L3 이상이면 계약과 보안 조항의 범위 확인
책임자 서명	게이트 오너, 서비스 매니저 또는 PM
판정	승급, 조건부 승급, 유지, 강등
조건과 강등 트리거	조건부일 때의 조건, 즉시 강등 조건

B-4. 파일럿 설계서

항목	채울 내용
목적과 가설	무엇을 확인하려는가, 가설은 무엇인가
대상	SI와 SM의 대상, 위험 등급의 혼합
시작 등급	업무 단위별 L1 또는 L2
완결 주기	SI는 가치흐름의 한 구간 이상, SM은 월간 SLA 보고 주기와 변경 이행 주기 이상
지표	흐름, 품질, 경제, 가드레일
비교 방식	비교군 또는 직전 주기, 한계의 명시
기록 항목	반발, 불안, 이탈, 실패, 근접사고
중단 조건	가드레일 위반, 고객 합의 위반
보고 형식	성공과 실패를 함께, 총비용 포함

B-5. 책임 규칙 선포문 초안

이 초안은 법률 검토를 거치지 않았습니다. 법무 검토 후 사용하시기 바랍니다.
하나. 업무를 요청하거나 AI를 실행한 사람은 그 결과물의 정확성과 품질에 책임을 진다. AI를 사용했다는 사실은 책임을 줄이지 않는다.
둘. 리뷰어는 정해진 점검 항목을 수행할 책임을 진다. 리뷰 승인은 작성자의 책임을 대신하지 않는다.
셋. AI가 관여한 산출물은 사용한 도구와 입력을 추적할 수 있어야 한다.
넷. 고객에 대한 책임은 프로젝트 또는 서비스의 책임자와 사업책임자가 진다.
다섯. 게이트를 우회한 행위는 사고로 다루며, 근접사고를 보고한 사람에게 불이익을 주지 않는다.
여섯. 회사가 제공하는 AI 플랫폼은 가용성과 보안과 기록에 대해 책임을 지며, 업무 결과의 책임은 요청한 사람에게 있다.

부록 C. 확인 로그와 한계

C-1. 이번에 직접 열어 확인한 자료

자료	확인한 내용	비고
SK AX 보도자료(2026-03-19)	AXgenticWire 구성. SM 또는 개발 적용의 구체 내용과 SK AX의 생산성 수치 없음	회사 발표
SK AX AI Software Engineering 페이지	단계별 기능 설명. 정량 수치와 근거 표기 없음	서비스 소개
바이라인네트워크 SK AX 부트캠프(2026-10-02)	4주 과정, 전 직군, AI 기반 운영	기사
머니투데이방송 삼성SDS AX 서밋(2026-05-29)	FabriX 2.0 예정, 우리은행 300개 에이전트 목표, 거버넌스 필요성	기사
CIO Korea 삼성SDS REAL Summit(2026-09-08)	AX 정의와 7요소, 클라이언트 제로, FDE 확대, OpenAI와 Anthropic 발언	기사
LG 보도자료(2026-06-08)	데브온 에이전틱 AIND 구성과 COBOL 전환	회사 발표
스마트투데이(KT, 2026-10)	kode 설명, 한 프로젝트 9개월에서 6개월	KT 발표, KT DS 자체 발표 없음
바이라인네트워크 KOSA 가이드(2025-08-11)	개정 내용(커스터마이징 작업비용, 개발비와 운영비의 산정 방식 구분)	기사
바이라인네트워크 과기정통부 TF(2026-05-28)	TF 구성, 확정 변경안 없음	기사
디지털데일리 금융위(2026-07-15)	금융 망분리 전면 해제 추진, 시행 시기 없음	기사
바이라인네트워크 N²SF(2025-11-04)	C·S·O 등급, 11개 정보서비스 모델	보안 업체 리포트 소개 기사
세종 뉴스레터(2026-02-11)	인공지능 기본법 시행일, 사업자 구분, 의무, 계도 기간	로펌 해설
Google DORA 소개, InfoQ, Splunk 해설	2025 보고서의 수치와 AI 역량 모델 7가지	보고서 원문(PDF)은 열지 않음
Faros AI 보고서 페이지	1만 명 이상, 1,255개 팀, 수치와 한계	상관 분석
Veracode 보도자료(2025-07-30)	100개 이상의 LLM, 80개 과제, 45%	보안 업체 자료
Gartner 보도자료(2025-06-25)	40% 예측, 3가지 이유, 에이전트 워싱	예측, 표본 한계
UpperEdge 기고문(2026-08-18)	Accenture 약 60% 고정가 등	자문사 기고, 저자 해석
디지털데일리 AIOps(2026-07-22)	통신사 AIOps 사례와 과제	기사
앞선 해설 문서	아정당 문서 24개 사례의 재확인 결과	앞선 작업의 결과물
AWS DevOps 블로그, AI-DLC 소개(2025-07-31)	원칙, 세 단계, 볼트와 작업 단위	회사 공식 글
AWS 한국어 기술 블로그, AI-DLC	핵심 원칙, 단계별 활동, 원문에 없는 내용	회사 공식 글
`awslabs/aidlc-workflows` README	규모, 지원 도구, 라이선스, 경고	공식 저장소. 최근 갱신 날짜는 표시되지 않음
`paralleldrive/aidd` GitHub 페이지	구성, 명령, 별과 커밋 수	공식 저장소. 최근 커밋 날짜 확인 못함
AWS 코리아 설명회 보도 3건(2026-07)	승인 게이트, 감사 추적, 사례와 수치	기사. 수치는 재인용이고 일부 표기 불일치
Martin Fowler 사이트, 스펙 주도 개발 도구 3종(2025-10-15)	세 수준과 우려	독립적인 개인 분석
ITWire, Thoughtworks Technology Radar 34호 보도(2026-04-16)	인지 부채, 에이전트 통제	기사. 레이더 PDF 원문은 열지 않음
Kiro 문서(명세), GitHub Spec Kit 페이지	명세 파일 구성, 명령 목록	공식 문서
Claude Code 문서(SKILL, 권한)	필드, 호출 규칙, 권한 평가와 한계	공식 문서. SKILL 문서의 끝부분 약 9,870자는 읽지 못함
Agent Skills 사양, Anthropic 스킬 작성 모범 사례	필드 제약, 작성 원칙, 평가 방식	공식 문서
이 환경의 스킬 검증 스크립트, Mermaid 구문 분석기	SKILL 7개의 업로드 규칙 검사, Mermaid 블록 9개의 구문 분석	직접 실행한 검사. 실제 도구에서의 동작을 확인한 것은 아님

C-2. 확인하지 못한 것

국내 SI/SM 대기업의 AI 활용 이후 투입공수, 대가, SLA의 실제 변화.
SM 사업자가 AI 에이전트로 운영 조치를 자동 실행해 낸 정량 성과.
협력사와 상주 인력의 AI 사용 관리 방식.
삼성SDS FabriX 2.0의 출시 여부와 우리은행 프로젝트의 진행 상황.
금융 망분리 전면 해제의 시행 시기와 과기정통부 TF의 결론.
DORA 2025 보고서 원문 PDF와 Faros AI 보고서 전문. 이 문서는 소개 글과 요약 페이지에서 확인한 값을 썼습니다.
LG CNS의 “분 단위”와 KT의 “9개월에서 6개월”을 뒷받침하는 조건과 측정 방법.
아정당 문서에는 적혀 있으나 앞선 해설에서도 확인하지 못한 항목들(PostHog의 승인 규칙, 왓낫의 책임 문장, 세 회사의 전담팀 병목, 토스와 당근 밋업 내용 등). 이 문서에서는 모두 강도 약으로 표기했습니다.
AI-DLC 저장소의 stage 33개의 이름과 phase별 역할, 그리고 블로그의 세 단계와 저장소의 다섯 phase 사이의 공식 대응.
AI-DLC의 효과를 독립적으로 확인한 연구와 운영 사례, 그리고 설명회에서 인용된 94%, 비용 1/6~1/10, 투입 공수 감소 수치의 원 출처와 측정 조건.
Thoughtworks Technology Radar 34호의 PDF 원문.
Claude Code SKILL 문서의 끝부분과, disallowed-tools에 쓸 수 있는 도구 이름의 공식 예시.
부록 E의 SKILL을 실제 Claude Code에서 실행한 결과. 형식과 문법만 검사했고 파일럿 평가(E-9)는 거치지 않았습니다.
Codex, Kiro, Cursor 등 다른 도구에서 같은 SKILL을 쓸 수 있는지.
AIDD라는 약자가 다른 분야에서 쓰이는 경우.

C-3. 읽을 때 주의할 점

회사 발표와 독립 검증은 다릅니다. 3.1절의 네 회사 내용은 보도자료와 서비스 소개이며 독립 검증된 효과가 아닙니다. 3.4절의 연구는 독립적이지만 각자 한계가 있습니다.

연구의 시점이 있습니다. METR는 2025년 초 도구, Veracode는 2025년 모델, Faros는 2025년 6월 기준 분석입니다. 도구와 모델은 빠르게 바뀌므로 결과가 달라졌을 수 있습니다. 이 문서는 이들을 “효과가 없다”는 증거가 아니라 “체감과 실측, 개인과 조직, 속도와 안정성이 따로 움직일 수 있다”는 경고로 씁니다.

이 문서의 제안은 가설입니다. [제안]으로 표시한 내용은 파일럿에서 검증해야 하는 설계이며, 검증된 표준이 아닙니다. 특히 자율성 등급의 상한, 위험 등급의 구성, 계약 인센티브의 진단은 이 문서가 확인하지 못한 영역을 포함합니다.

동향은 2026-10-20 기준입니다. 규제와 제도(망분리 완화, 대가산정 TF, 인공지능 기본법의 계도 기간)와 기업의 발표는 바뀔 수 있으므로, 적용 전에 최신 상태를 확인하시기 바랍니다.

AIDD 부분이 가장 빨리 낡습니다. 14장과 부록 D, E는 도구의 버전, 명령, 필드 이름, 권한 문법에 기대고 있습니다. AI-DLC 저장소의 버전과 명령, Claude Code의 SKILL 필드와 권한 규칙은 2026-10-20에 확인한 기준이므로, 적용 전에 각 공식 문서를 다시 열어 확인하십시오. 부록의 프롬프트와 SKILL은 예시이자 출발점이며 검증된 표준 문구가 아닙니다.

부록 D. AIDD 프롬프트 모음

14장의 절차에서 바로 쓸 수 있도록 복사해서 채워 쓰는 프롬프트 15종을 모았습니다. 모든 프롬프트는 [제안] 이며, 파일럿에서 팀의 업무와 도구에 맞게 고쳐 쓰는 것을 전제로 합니다. 효과가 검증된 표준 문구가 아닙니다.

번호	프롬프트	14장의 절차	자율성	관련 게이트	대응하는 SKILL
D-1	세션 시작 규칙	1	공통	G1	E-8의 지침 파일
D-2	요구사항 정교화	2	L1	G1, G2	E-1
D-3	명세 점검	3	L1	G2	E-2
D-4	업무 단위 분해와 등급 제안	4	L1	G2	E-3
D-5	설계 대안 비교	5	L1	G2
D-6	테스트 먼저	5	L2	G4	E-4
D-7	구현: 계획, 승인, 구현	6	L2	G3
D-8	변경 리뷰 보조	7	L1	G3	E-5
D-9	추적성 점검	7	L1	G3, G6
D-10	SM 장애와 티켓 분석	SM	L1	G7	E-6
D-11	SM 조치안 작성	SM	L2	G7
D-12	레거시 변환 동등성 검증 설계	5	L1	G4
D-13	AI 관여 기록	7	L1	R3
D-14	세션 인계와 결정 기록	전체	L2	G8
D-15	사고 회고와 개정안	7	L1	G8	E-7

D-0. 쓰기 전에

여섯 가지를 지켜 주십시오.

고객 데이터, 개인정보, 비밀 정보, 접속 정보를 넣지 않습니다. 허용된 환경과 허용된 도구에서만 씁니다(G1). 고객이 AI 사용을 허용하지 않은 사업(L0)에서는 쓰지 않습니다.
``로 표시한 곳은 채워서 씁니다. 채우지 않은 채 보내면 에이전트가 임의로 메웁니다.
프롬프트는 요청이지 통제가 아닙니다. 어겨도 막히지 않으므로, 지켜야 할 규칙은 권한 규칙과 CI로도 걸어 둡니다(14.4.4, 부록 E-8).
결과는 초안입니다. 사실 주장과 인용은 근거를 확인하고, 승인과 책임은 요청한 사람에게 있습니다(R1).
출력 형식을 고정했습니다. 표와 고정된 절은 리뷰를 쉽게 만들기 위한 장치이므로 바꿀 때는 리뷰어가 읽기 쉬운지 먼저 생각하십시오.
프롬프트마다 멈춤 지점이 있습니다. “여기서 멈추십시오”라는 문장을 지우면 에이전트가 승인 없이 다음 단계로 넘어갈 수 있습니다.

프롬프트의 뼈대. 부록의 프롬프트는 모두 같은 여섯 요소로 짜여 있습니다. 직접 고치거나 새로 만들 때는 이 순서를 지키면 됩니다.

요소	쓰는 내용	예
역할과 등급	누구로서 일하는지와 자율성 등급	“명세 검토자입니다. 자율성 등급은 L1입니다”
입력	무엇을 읽고 쓰는지	파일 경로, 비식별 처리된 자료
할 일	번호를 붙인 구체적 절차	“표로 정리하십시오”
하지 말 것	금지와 한계	“결정하지 마십시오”
출력 형식	결과의 모양	표의 열, 절의 이름
멈춤 규칙	사람에게 돌려주는 지점	“여기서 멈추고 확인을 기다리십시오”

D-1. 세션 시작 규칙

쓰는 때: 새 세션을 열 때 첫 메시지로. 자율성: 공통. 채울 값: 등급, 범위.

이 세션의 작업 규칙입니다. 이후 모든 요청에 적용하십시오.

- 자율성 등급: . L1이면 파일을 수정하지 말고 읽고 분석만 하십시오. L2이면 변경안을 제안하되 저장소에 직접 반영하지 마십시오.
- 범위: 만 다룹니다. 범위 밖 파일은 읽지도 바꾸지도 마십시오.
- 금지: 비밀 정보, 운영 환경 접속 정보, 고객 개인정보를 출력하거나 요청하지 마십시오. 발견하면 즉시 멈추고 위치만 알려 주십시오.
- 모르는 것: 근거가 없으면 추측하지 말고 "확인되지 않음"이라고 쓰고, 무엇을 확인하면 되는지 적으십시오.
- 멈춤: 요구가 모호하거나 두 가지 이상으로 해석되면 구현하지 말고 먼저 질문하십시오.
- 근거: 코드나 문서를 인용할 때는 파일 경로와 줄 번호를 함께 쓰십시오.
- 책임: 최종 승인과 반영은 사람이 합니다. 승인을 요청할 때는 변경 요약, 영향 범위, 되돌리는 방법을 함께 제시하십시오.

용어: 자율성 등급은 L0 금지, L1 읽기만, L2 제안만(사람이 반영), L3 승인 후 실행, L4 사전 승인 범위 내 자동 실행입니다. 게이트는 G1 입력, G2 명세, G3 변경, G4 검증, G5 배포, G6 고객, G7 운영, G8 학습입니다. R3은 AI가 관여한 산출물의 도구와 입력을 추적할 수 있어야 한다는 규칙입니다.

D-2. 요구사항 정교화

쓰는 때: 절차 2. 자율성: L1. 채울 값: 요청 원문(비식별 처리). 질문에 답한 뒤 두 번째 메시지를 보냅니다.

첫 번째 메시지: 질문 먼저

역할: 요구사항 분석을 돕는 분석가입니다. 자율성 등급은 L1입니다. 아직 설계나 구현을 하지 마십시오.

입력: 아래는 고객 요청과 회의 메모입니다(비식별 처리됨).


해야 할 일:
1. 요청을 한 문단으로 되풀이해서, 제가 의도한 바와 맞는지 확인할 수 있게 하십시오.
2. 명세를 쓰기 전에 꼭 필요한 질문을 우선순위 순으로 최대 7개 하십시오. 질문마다 왜 필요한지, 답에 따라 무엇이 달라지는지를 한 줄씩 쓰십시오.
3. 답을 받기 전에 둘 수밖에 없는 가정은 "가정 목록"으로 따로 모으고, 각 가정이 틀렸을 때의 영향을 쓰십시오.
4. 여기서 멈추고 제 답을 기다리십시오.

하지 말 것: 질문의 답을 임의로 채우지 마십시오. 기술 선택을 정하지 마십시오.

출력 형식: "요청 이해", "질문", "가정 목록" 세 절.

두 번째 메시지: 답을 준 뒤 초안

아래는 질문에 대한 제 답입니다. 답하지 않은 질문은 "미정"으로 처리하십시오.


이제 요구사항 초안을 쓰십시오. 구성:
목적과 배경
범위: 포함, 제외(비목표)
이해관계자
기능 요구: REQ-001처럼 번호를 붙이고 한 문장에 하나의 요구만 쓰십시오.
수용 기준: 요구마다 Given-When-Then 형식으로 1개 이상. 판정할 수 없는 표현("빠르게")은 쓰지 마십시오.
비기능 요구: 성능, 보안, 감사 기록, 가용성. 값이 정해지지 않았으면 "미정"으로 쓰십시오.
미결 사항: 항목, 정해야 하는 사람, 구현 결과를 바꾸는지 여부
위험 등급 후보: 영향 범위, 되돌림 난이도, 데이터 민감도 세 값과 그중 최댓값

하지 말 것: 답이 없는 항목을 임의로 채우지 마십시오. 문서 맨 위에 "초안, 사람의 승인 전"이라고 표시하십시오.

D-3. 명세 점검

쓰는 때: 절차 3, 승인 전. 자율성: L1. 채울 값: 명세 경로.

역할: 명세 검토자입니다. 자율성 등급은 L1입니다. 파일을 수정하지 마십시오.

입력: 

아래 다섯 유형의 문제를 찾으십시오.
1. 모순: 서로 충돌하는 요구나 수용 기준
2. 누락: 정상 흐름만 있고 예외, 오류, 권한, 경계값, 동시성, 감사 기록이 빠진 곳
3. 측정 불가: "빠르게", "안전하게", "적절히"처럼 통과 여부를 판정할 수 없는 표현
4. 가정 의존: 명세에는 없는데 구현에 필요한 가정
5. 범위 혼입: 목표나 비목표와 맞지 않는 요구

출력 형식: 표(번호, 유형, 위치(요구 ID 또는 줄), 원문 인용, 왜 문제인지, 해결을 위해 사람이 정해야 할 것). 마지막에 "승인 전에 반드시 해결할 항목"과 "승인 후에 정리해도 되는 항목"을 나누어 쓰십시오.

하지 말 것: 통과나 반려를 결정하지 마십시오. 문제를 해결하는 문장을 임의로 명세에 써넣지 마십시오. 인용 없이 지적하지 마십시오.

D-4. 업무 단위 분해와 등급 제안

쓰는 때: 절차 4. 자율성: L1. 채울 값: 명세 경로, 팀의 리뷰 단위 기준. 이 문서는 크기 기준값을 정하지 않으므로(13.1절) 팀이 정한 문장을 넣습니다.

역할: 업무 분해를 돕는 분석가입니다. 자율성 등급은 L1입니다. 파일을 수정하지 마십시오.

입력: 승인된 명세 . 팀의 리뷰 단위 기준: 

해야 할 일:
1. 명세를 업무 단위로 나누십시오. 단위는 하나의 요구(REQ) 또는 그 일부에 대응해야 하고, 위의 리뷰 단위 기준을 넘지 않아야 합니다. 넘을 것 같으면 더 쪼개십시오.
2. 단위마다 위험을 아래 세 질문으로 평가하고, 세 값 중 가장 높은 값을 위험 등급으로 제안하십시오. 평균을 쓰지 마십시오.
   - 영향 범위: 내 작업 환경 | 내부 도구 | 고객 운영 시스템과 최종 사용자
   - 되돌림 난이도: 쉽게 롤백 | 어려움 | 데이터가 바뀌거나 불가역
   - 데이터 민감도: 공개나 내부 일반 | 업무 데이터 | 고객 기밀, 개인정보, 신용정보 등 규제 대상
   위험 등급은 낮음, 보통, 높음, 매우 높음 중 하나입니다.
3. 위험 등급에 따른 자율성 상한을 제안하십시오. 낮음과 보통은 L3 이하, 높음은 L2 이하, 매우 높음은 L1에서 L2이며 환경에 따라 L0입니다.
4. 단위마다 검증 방법과 기대 결과의 출처(어느 REQ의 어느 수용 기준인지)를 적으십시오.
5. 단위 사이의 선행 관계를 적으십시오.

출력 형식: 표(단위 ID, 설명, 대응 REQ, 영향 범위, 되돌림 난이도, 데이터 민감도, 위험 등급, 자율성 상한 제안, 검증 방법과 기대 결과의 출처, 선행 단위).

하지 말 것: 등급을 확정하지 마십시오. 확정은 사람이 합니다. 판단할 근거가 부족한 칸은 "확인 필요"라고 쓰고 무엇을 확인해야 하는지 적으십시오.

D-5. 설계 대안 비교

쓰는 때: 절차 5. 자율성: L1. 채울 값: 업무 단위, 명세, 제약.

역할: 설계 대안을 비교하는 조력자입니다. 결정은 사람이 합니다. 자율성 등급은 L1입니다.

입력: 설계가 필요한 업무 단위 , 관련 명세 , 제약 

해야 할 일:
1. 실현 가능한 대안을 개 제시하십시오. 선택지를 늘리려고 억지 대안을 만들지 마십시오.
2. 대안마다 장점, 단점, 위험, 되돌리기 어려운 정도, 명세의 어느 요구를 얼마나 만족하는지를 적으십시오.
3. 저장소의 코드나 문서에서 확인한 사실과, 일반적인 지식에 따른 것을 구분해서 표시하십시오.
4. 추천이 있다면 한 개만 이유와 함께 쓰고, "결정은 사람이 합니다"라고 명시하십시오.
5. 결정에 필요한데 모르는 것을 질문으로 정리하십시오.

출력 형식: 결정 기록 초안(배경, 대안, 비교표, 추천과 이유, 열린 질문, 결정자와 결정일은 빈 칸).

하지 말 것: 결정된 것처럼 쓰지 마십시오. 확인하지 않은 제품 기능이나 버전을 사실처럼 쓰지 마십시오.

D-6. 테스트 먼저

쓰는 때: 절차 5. 자율성: L2. 채울 값: 명세, 업무 단위, 테스트 도구와 위치.

역할: 테스트 설계자입니다. 구현 코드는 수정하지 마십시오. 자율성 등급은 L2입니다.

입력: 승인된 명세 , 대상 업무 단위 , 테스트 도구와 위치 

1단계. 코드를 쓰지 말고 테스트 케이스 목록을 표로 작성한 뒤 멈추십시오.
- 열: 테스트 ID, 대응 REQ와 수용 기준, 시나리오, 입력, 기대 결과, 종류(단위, 통합, E2E)
- 기대 결과는 명세의 문장에서만 가져오고 원문을 인용하십시오.
- 정상 흐름뿐 아니라 경계값, 오류, 권한, 빈 값을 포함하십시오.
- 명세에 기대 결과가 없는 동작은 테스트로 정하지 말고 "명세 질문" 목록에 올리십시오.
- 기존 구현 코드를 읽고 그 동작을 기대 결과로 삼지 마십시오.

제가 목록을 확인하면 2단계로 진행합니다.
2단계. 프로젝트의 기존 관례에 맞춰 테스트 코드를 작성하고 실행해서 결과를 보고하십시오. 구현 전이므로 실패가 정상입니다. 실패한 테스트마다 원인이 "기능이 아직 없음", "기대 결과가 틀렸을 가능성", "환경 문제" 가운데 어느 것인지 구분해서 적으십시오.

D-7. 구현: 계획, 승인, 구현

쓰는 때: 절차 6. 자율성: L2. 채울 값: 업무 단위, 명세, 테스트 경로.

역할: 구현을 맡은 개발자입니다. 자율성 등급은 입니다. 제가 계획을 승인하기 전에는 파일을 수정하지 마십시오.

입력: 업무 단위 , 승인된 명세 , 이미 작성된 테스트 

1단계. 구현 계획만 제시하고 멈추십시오.
- 수정할 파일과 이유 / 수정하지 않을 파일 / 새로 추가할 의존성(있다면 이유와 라이선스)
- 영향 범위와 되돌리는 방법
- 이 변경이 만족시키는 명세와 테스트의 항목
- 모호하거나 막힌 부분(질문)

제가 계획을 승인하면 2단계로 진행합니다.
2단계. 계획대로 구현하고 테스트를 실행하십시오. 계획에 없는 파일을 바꿔야 하거나 테스트의 기대 결과가 틀렸다고 판단되면 구현을 멈추고 알려 주십시오. 기대 결과를 고치거나 테스트를 약하게 만들어 통과시키지 마십시오.
끝나면 보고하십시오: 변경 요약, 바뀐 파일 목록, 실행한 테스트와 결과, 확인하지 못한 것, 사람이 특히 봐야 할 부분.

하지 말 것: 이 업무 단위와 관련 없는 정리나 리팩터링을 섞지 마십시오. 보호 브랜치에 푸시하지 마십시오. 비밀 정보를 출력하지 마십시오.

D-8. 변경 리뷰 보조

쓰는 때: 절차 7, 사람 리뷰 전이나 도중. 자율성: L1. 채울 값: 변경 범위, 명세. 작성한 세션과 다른 새 세션에서 쓰는 편이 좋습니다(작성 때의 가정이 리뷰에 섞이는 것을 줄이기 위함이며, 같은 모델이 같은 오해를 공유할 가능성은 남습니다. 6.2절).

역할: 코드 리뷰어의 보조입니다. 자율성 등급은 L1입니다. 파일을 수정하지 마십시오. 승인이나 반려를 결정하지 마십시오. 최종 판단은 사람이 합니다.

입력: 변경 , 승인된 명세 

점검 항목:
1. 명세 부합: 변경이 명세의 어느 요구를 만족하는지 대응시키십시오. 어떤 요구에도 대응하지 않는 변경은 "범위 밖 변경"으로 표시하십시오.
2. 보안: 입력 검증, 비밀 정보, 권한 확인, 로그에 남는 개인정보, 새로 추가된 의존성
3. 테스트: 기대 결과가 명세에서 왔는지, 경계값과 오류 경로가 있는지, 구현을 그대로 베낀 테스트는 아닌지
4. 크기와 범위: 관련 없는 변경이 섞였는지, 한 번에 검토하기에 큰지(크면 쪼개기를 권고)
5. 되돌림: 데이터나 스키마를 바꾸는지, 롤백 방법이 있는지
6. 설명 가능성: 리뷰어가 의도를 설명하기 어려운 부분

출력 형식:
- 요약 세 줄
- 지적 표: 번호, 심각도(차단 | 권고 | 질문), 위치(파일:줄), 근거, 제안
- 사람이 직접 확인해야 하는 것
- 확인하지 못한 것

규칙: 파일과 줄 번호의 근거가 없는 지적은 쓰지 마십시오. 확신이 낮으면 낮다고 쓰십시오. 지적이 없는 항목은 "지적 없음"이라고 쓰되 확인한 범위를 밝히십시오.

D-9. 추적성 점검

쓰는 때: 절차 7, 고객 검수나 감리 전. 자율성: L1. 채울 값: 명세, 설계, 코드, 테스트 경로.

역할: 추적성 점검자입니다. 자율성 등급은 L1입니다. 파일을 수정하지 마십시오.

입력: 명세 , 설계 , 코드 , 테스트 

각 요구(REQ)에 대해 설계 항목, 코드의 위치, 테스트의 위치를 연결한 추적성 표를 만드십시오.
- 구현이나 테스트가 연결되지 않은 REQ를 따로 목록으로 만드십시오.
- 어떤 REQ와도 연결되지 않은 코드나 테스트(범위 밖 변경 후보)를 따로 목록으로 만드십시오.
- 설계와 명세가 서로 다른 말을 하는 곳을 인용과 함께 적으십시오.
- 연결의 근거는 파일 경로와 식별자로 쓰십시오. 이름이 비슷하다는 이유만으로 연결하지 말고, 확신이 낮은 연결은 "추정"으로 표시하십시오.

출력 형식: 추적성 표, 미연결 REQ, 미연결 코드와 테스트, 불일치 목록.

D-10. SM 장애와 티켓 분석

쓰는 때: SM의 원인 분석 단계. 자율성: L1(읽기 전용). 채울 값: 증상, 비식별 처리된 로그, 런북 경로. 8.3절의 “분석과 조치를 분리한다”를 그대로 옮긴 프롬프트입니다.

역할: 운영 분석가입니다. 자율성 등급은 L1(읽기 전용)입니다. 시스템에 접속하거나 명령을 실행하거나 파일을 수정하지 마십시오. 조치는 제안하지 마십시오.

입력: 티켓 또는 증상 , 비식별 처리된 로그나 지표 , 참고할 런북과 장애 이력 

해야 할 일:
1. 증상을 한 문단으로 정리하고 발생 시각, 범위, 영향받는 기능을 적으십시오. 모르는 것은 "확인되지 않음"이라고 쓰십시오.
2. 로그와 지표를 근거로 타임라인을 만드십시오. 항목마다 근거(파일, 줄 또는 시각)를 붙이십시오.
3. 원인 가설을 최대 3개 쓰십시오. 가설마다 "지지하는 근거", "반증하는 근거 또는 아직 없는 근거", "가설을 가리기 위해 추가로 확인할 것(읽기 전용으로 가능한 것)"을 적으십시오.
4. 같은 증상의 과거 이력이나 런북이 있으면 찾아서 인용하십시오. 문서에 소유자와 유효 기간이 없거나 유효 기간이 지났으면 그 사실을 표시하고, 그 문서를 근거로 삼지는 마십시오.
5. 영향 범위를 추정하되 불확실성을 표시하십시오.

출력 형식: 증상, 타임라인, 가설 표, 관련 이력, 영향 범위(불확실성 표시), 확인되지 않은 것.

하지 말 것: 근거 없는 가설을 쓰지 마십시오. 하나의 원인으로 단정하지 마십시오. 로그에서 개인정보나 비밀 정보를 발견하면 내용을 옮겨 쓰지 말고 발견한 위치만 알리십시오. 마지막에 "조치안 작성은 별도로 요청해 주십시오"라고 안내하십시오.

D-11. SM 조치안 작성

쓰는 때: 분석을 사람이 확인한 뒤. 자율성: L2(제안). 채울 값: 승인된 분석, 사전 승인된 런북. 이 프롬프트는 실행하지 않습니다.

역할: 조치안 작성자입니다. 자율성 등급은 L2(제안)입니다. 어떤 명령도 실행하지 마십시오.

입력: 사람이 확인한 분석 결과 , 사전 승인된 런북 

해야 할 일:
1. 분석 결과에 맞는 런북 항목을 찾으십시오. 있으면 해당 항목을 그대로 인용하고, 런북에 없는 조치는 제안하지 마십시오.
2. 맞는 항목이 없으면 "해당 런북 없음"이라고 쓰고, 어떤 정보나 승인이 필요한지 적은 뒤 멈추십시오.
3. 조치안에는 다음을 포함하십시오: 목적, 실행 순서, 단계별 예상 결과, 단계별 확인 방법, 이상이 생겼을 때의 중단 조건, 되돌리는 방법, 필요한 승인 등급과 승인자.
4. 영향받는 데이터나 고객, 실행 시간대의 제약을 적으십시오.

출력 형식: 조치안 문서 초안. 맨 위에 "초안, 승인 전 실행 금지"라고 표시하십시오.

하지 말 것: 런북 밖의 명령을 새로 만들어 넣지 마십시오. 실행하지 않은 명령을 실행했다고 쓰지 마십시오. 승인 등급을 임의로 낮추지 마십시오.

D-12. 레거시 변환 동등성 검증 설계

쓰는 때: 7.3절 쟁점 3의 변환 작업(예: 언어 전환, 쿼리 이전). 자율성: L1. 채울 값: 원본과 변환 결과의 경로, 원본의 실제 입출력 샘플(비식별).

역할: 레거시 변환 검증을 설계하는 분석가입니다. 자율성 등급은 L1입니다. 코드를 변환하거나 수정하지 마십시오.

입력: 변환 전 원본 , 변환 결과 , 원본 시스템의 실제 입출력 샘플 

목적은 변환 전후의 동작이 같음을 AI의 출력이 아니라 독립된 기준으로 확인하는 것입니다. 기준은 원본 시스템의 실제 입출력입니다.

해야 할 일:
1. 입출력 샘플에서 검증할 동작 범주(정상, 경계값, 오류, 특수 값, 날짜와 숫자 형식, 문자 집합)를 뽑으십시오.
2. 범주마다 동등성 검증 케이스를 표로 쓰십시오: 케이스 ID, 입력, 원본의 기대 출력(샘플에서 인용), 비교 방법(완전 일치, 허용 오차 등), 허용 오차가 있다면 그 이유.
3. 샘플이 덮지 못하는 동작(샘플에 없는 분기, 배치 처리의 순서나 시간 의존, 동시성)을 목록으로 만들고, 추가로 확보해야 할 샘플을 제안하십시오.
4. 변환 결과의 코드를 읽고 알게 된 동작을 기대 출력으로 쓰지 마십시오.

출력 형식: 검증 범주, 케이스 표, 덮지 못하는 영역, 추가로 필요한 샘플.

D-13. AI 관여 기록

쓰는 때: 절차 7, 반영 전. 자율성: L1. 채울 값: 변경 범위와, 사람이 아는 사실(도구, 모델, 입력). 규칙 R3(AI가 관여한 산출물의 도구와 입력을 추적)의 기록 초안입니다. 에이전트는 자기가 어떤 모델이었는지를 정확히 모를 수 있으므로 사용한 도구와 모델은 사람이 알려 주고, 에이전트가 추측해 쓰지 않게 합니다.

역할: 기록 보조자입니다. 자율성 등급은 L1입니다.

입력: 변경 
제가 알려 드리는 사실: 사용한 도구와 모델 , 사용한 프롬프트나 SKILL , 입력으로 준 자료의 종류 

AI 관여 기록 초안을 쓰십시오. 항목: 대상 산출물, AI가 한 일(초안 작성, 리뷰 보조 등), 사람이 한 일(검토, 수정, 승인), 사용한 도구와 모델, 입력 자료의 종류, 사람이 확인한 항목, 승인자와 승인 일시(빈 칸).

제가 알려 드리지 않은 항목을 추측해서 채우지 마십시오. 모르는 칸은 "확인 필요"로 남기십시오. 변경 이력에서 확인할 수 있는 사실(변경 파일, 커밋)은 근거와 함께 쓰십시오.

D-14. 세션 인계와 결정 기록

쓰는 때: 세션을 끝내거나 길어져서 새 세션으로 옮기기 전. 자율성: L2. 채울 값: 파일 경로. 14.4.3의 원칙 6(맥락은 파일로 남긴다)을 옮긴 것입니다.

역할: 기록 보조자입니다. 자율성 등급은 L2입니다. 아래 파일 하나만 새로 쓰거나 수정안을 제안하십시오: 

이번 작업 세션에서 내려진 결정과 그 이유, 아직 열려 있는 질문, 다음에 할 일, 알려진 위험과 제약을 정리하십시오.
- 사람이 명시적으로 승인한 것만 "결정"으로 쓰십시오. 제안만 되고 승인되지 않은 것은 "제안(미승인)"으로 구분하십시오.
- 대화에서 확인되지 않은 내용을 채워 넣지 마십시오.
- 다음 세션의 에이전트가 이 파일만 읽고도 이어서 일할 수 있도록 관련 명세와 파일의 경로를 적으십시오.
- 비밀 정보, 접속 정보, 고객 개인정보는 쓰지 마십시오.

출력 형식: 결정, 제안(미승인), 열린 질문, 다음 할 일, 위험과 제약, 관련 경로.

D-15. 사고 회고와 개정안

쓰는 때: 사고나 근접사고, 반려가 반복될 때(G8). 자율성: L1. 채울 값: 사고 기록, 게이트 정의, 관련 프롬프트와 SKILL.

역할: 사고 회고를 돕는 분석가입니다. 자율성 등급은 L1입니다. 개인을 탓하는 서술을 하지 말고 시스템과 절차의 빈틈에 초점을 맞추십시오.

입력: 사고 또는 근접사고 기록 , 현재의 게이트 정의 , 관련 프롬프트와 SKILL 

해야 할 일:
1. 사실 관계로 타임라인을 만드십시오. 근거가 없는 항목은 "미확인"으로 표시하십시오.
2. 이 사고를 걸러 냈어야 하거나 걸러 낼 수 있었던 게이트를 G1부터 G8 가운데 골라, 각 게이트가 왜 못 걸렀는지(게이트가 없었음, 있었으나 형식적이었음, 우회되었음, 용량 초과)를 구분하십시오. 우회가 있었다면 별도 사고로 표시하십시오.
3. 개정안을 제안하십시오. 항목마다 무엇을 고칠지(게이트 정의, 권한 규칙, CI 검사, 프롬프트, SKILL, 교육 중 하나 이상), 누가 승인해야 하는지, 효과를 어떻게 확인할지(지표)를 적으십시오. 프롬프트나 SKILL만 고치는 제안이라면, 그것만으로 막을 수 없는 이유와 시스템 쪽 장치가 필요한지를 함께 검토하십시오.
4. 해당 업무의 자율성 등급을 낮춰야 하는지 의견을 쓰되, 결정은 게이트 오너가 한다고 명시하십시오.

출력 형식: 타임라인, 게이트별 분석 표, 개정안 표, 등급 조정 의견, 확인되지 않은 것.

부록 E. AIDD SKILL 모음

14장의 절차를 Claude Code의 SKILL 파일로 옮긴 모음입니다. SKILL은 반복해서 쓰는 절차를 폴더에 담아 두고, 사람이 /이름으로 부르거나 모델이 필요할 때 읽게 하는 장치입니다. 부록 D의 프롬프트를 매번 붙여 넣는 대신 팀 저장소에서 같은 절차를 같은 방식으로 쓰게 해 줍니다. 아래 파일은 모두 [제안] 이며, 문서의 형식은 Claude Code 공식 문서와 Agent Skills 공개 사양을 직접 열어 확인한 것에 맞췄습니다. 내용의 효과는 검증되지 않았으므로 파일럿에서 E-9의 평가를 거쳐 쓰십시오.

번호	내용	14장의 절차	자율성
E-0	SKILL 사용 설명: 배치, 필드, 이식성, 보안
E-1	`aidd-elaborate` 요구사항 정교화	2	L1
E-2	`aidd-spec-review` 명세 점검	3	L1
E-3	`aidd-unit-slice` 업무 단위 분해와 등급 제안	4	L1
E-4	`aidd-test-first` 테스트 먼저	5	L2
E-5	`aidd-change-review` 변경 리뷰 보조	7	L1
E-6	`aidd-sm-triage` SM 장애와 티켓 분석	SM	L1
E-7	`aidd-gate-retro` 사고 회고와 개정안	7	L1
E-8	팀 기본 설정: 지침 파일과 권한 규칙	1	방식 B
E-9	SKILL 평가 시나리오

E-0. SKILL 사용 설명

어디에 두는가

[근거] (강, Claude Code 공식 문서) SKILL은 SKILL.md 파일이 들어 있는 폴더입니다. 프로젝트 저장소에 두면 .claude/skills/<이름>/SKILL.md, 개인용은 ~/.claude/skills/<이름>/SKILL.md입니다. 같은 이름이 여러 곳에 있으면 엔터프라이즈, 개인, 프로젝트 순으로 우선합니다. 이 문서는 팀 표준 SKILL을 프로젝트 저장소에 두고 코드 리뷰를 거쳐 바꾸는 방식을 권합니다(G3). 이렇게 하면 SKILL의 변경도 이력이 남고, 협력사 인력을 포함해 같은 저장소를 쓰는 사람에게 같은 절차가 적용됩니다.

프로젝트 저장소/
├── CLAUDE.md                        팀 지침 파일 (E-8)
├── .claude/
│   ├── settings.json                권한 규칙, 팀 공유 (E-8)
│   └── skills/
│       ├── aidd-elaborate/SKILL.md
│       ├── aidd-spec-review/SKILL.md
│       ├── aidd-unit-slice/SKILL.md
│       ├── aidd-test-first/SKILL.md
│       ├── aidd-change-review/SKILL.md
│       ├── aidd-sm-triage/SKILL.md
│       └── aidd-gate-retro/SKILL.md
└── docs/
    ├── spec/                        승인된 명세
    └── decisions/                   결정 기록

호출은 /aidd-elaborate 로그인 실패가 반복되면 계정을 잠근다처럼 이름 뒤에 인자를 붙입니다. 본문의 $ARGUMENTS가 이 인자로 치환됩니다.

이 부록의 SKILL에 쓴 필드

필드	뜻	이 부록에서 쓴 이유
`name`	SKILL의 이름. 이 문서는 팀 접두어 `aidd-`를 붙입니다	소문자, 숫자, 하이픈만 쓰고 폴더 이름과 같게 둡니다
`description`	무엇을 하고 언제 쓰는지. 3인칭 서술	이 문서의 SKILL은 사람이 직접 부르지만, 설명은 `/` 메뉴와 다른 환경에서의 발견을 위해 씁니다
`argument-hint`	자동완성에 보이는 인자 안내	사용자가 무엇을 넣을지 알 수 있게
`disable-model-invocation`	`true`이면 모델이 스스로 호출하지 못하고 사람이 `/이름`으로만 호출	절차의 시작은 사람이 정한다는 원칙. 승인 단계가 있는 절차에 적합
`allowed-tools`	호출한 턴 동안 권한 확인 없이 쓸 도구의 사전 승인	읽기 도구만 사전 승인. 쓰기와 실행은 일부러 사전 승인하지 않음
`disallowed-tools`	호출한 턴 동안 도구 풀에서 도구를 제거	읽기 전용 SKILL(L1)에서 쓰기 도구를 빼는 보조 장치
`metadata`	자유 형식의 값. Claude Code는 내용을 해석하지 않음	버전, 관련 게이트, 자율성 등급을 기록해 운영과 추적에 씀

[한계] disallowed-tools에 쓸 수 있는 도구 이름의 예시는 문서의 해당 필드 설명에 없었습니다. 이 부록은 권한 규칙에서 쓰는 이름(Edit, Write, Bash, NotebookEdit)을 썼으나, 실제로 제한되는지는 사용하는 버전에서 시험해 확인하십시오. 그리고 이 필드의 제한은 다음 메시지를 보내면 풀리므로 통제 장치가 아니라 보조 장치입니다.

이식성: 어디서 그대로 쓸 수 있는가

환경	허용하는 필드와 제약	이 부록의 SKILL
Claude Code	위 필드 모두. 본문의 `$ARGUMENTS` 치환과 동적 컨텍스트 주입 지원	그대로 사용 가능
claude.ai 업로드, Skills API	`name`, `description`, `license`, `compatibility`, `metadata`, `allowed-tools` 여섯 개만 허용. 그 밖의 키가 있으면 업로드가 오류로 실패	`argument-hint`, `disable-model-invocation`, `disallowed-tools`를 지우고, `$ARGUMENTS`와 동적 주입 줄을 사람이 입력하는 안내로 바꿔야 함
Agent Skills 공개 사양	`name`은 64자 이하, 소문자·숫자·하이픈, 연속 하이픈과 앞뒤 하이픈 금지, 폴더 이름과 일치. `description`은 1,024자 이하	모두 충족하도록 썼음
그 밖의 도구 (Codex, Kiro, Cursor 등)	확인하지 못함	쓰기 전에 각 도구의 문서를 확인

Claude Code 문서는 description과 when_to_use를 합쳐 1,536자에서 잘린다고 하지만, 공개 사양은 description을 1,024자 이하로 제한합니다. 이식성을 위해 이 부록은 1,024자 이하로 썼습니다.

SKILL을 쓰고 고칠 때의 규칙

[근거] (중, Anthropic 공식 문서와 Agent Skills 사양) Anthropic의 작성 모범 사례와 공개 사양에서 이 부록이 따른 것은 다음과 같습니다.

본문은 500줄 이내로 짧게 둡니다. 길어지면 보조 파일로 나누고, 보조 파일은 SKILL.md에서 한 단계 깊이까지만 참조합니다. 이 부록의 SKILL은 모두 한 파일로 충분한 길이입니다.
description은 3인칭으로, 무엇을 하는지와 언제 쓰는지를 함께 씁니다. 시스템 프롬프트에 들어가므로 “내가 도와줄 수 있다” 같은 1인칭이나 “당신이 쓸 수 있다” 같은 2인칭은 피합니다.
지시의 자유도를 작업의 취약성에 맞춥니다. 여러 접근이 가능한 일(리뷰)은 텍스트 지침으로, 순서가 중요한 일은 단계와 체크리스트로 씁니다.
복잡한 절차에는 체크리스트를 넣어 에이전트가 단계를 건너뛰지 않게 합니다.
용어를 하나로 통일합니다. 같은 개념을 이름만 바꿔 쓰지 않습니다.
예약어를 피합니다. 이름에 anthropic, claude를 쓰지 않습니다. Anthropic 문서는 동명사형 이름(예: processing-pdfs)을 권하고 명사형도 허용한다고 합니다.

호출된 SKILL의 수명. Claude Code는 호출된 SKILL의 본문을 대화에 한 번 넣고 이후 턴에 다시 읽지 않습니다. 자동 압축이 일어나면 SKILL마다 가장 최근 호출만, 처음 5,000토큰까지 다시 붙이고 전체 합계는 25,000토큰 예산을 나눠 씁니다. 그래서 가장 중요한 규칙(멈춤 규칙, 금지)을 본문 앞쪽에 두었습니다. 이 수치는 문서 기준이며 버전에 따라 바뀔 수 있습니다.

보안: SKILL은 게이트가 아닙니다

14.4.4에서 본 대로 SKILL은 에이전트가 따르도록 요청하는 층입니다. 아래를 지킵니다.

저장소에 들어온 SKILL을 검토합니다. 공식 문서는 SKILL이 스스로 넓은 도구 권한을 줄 수 있으므로, 저장소에 들어 있는 SKILL의 allowed-tools를 실행 전에 확인하라고 경고합니다. 외부에서 받은 SKILL은 코드 리뷰를 거친 뒤 저장소에 넣습니다.
본문의 실행 줄을 확인합니다. SKILL 본문의 !`명령` 형식은 SKILL이 렌더링될 때 명령을 실행합니다. 이 부록에서는 읽기만 하는 git 명령(E-5)에만 썼습니다. 한 명령이라도 실패하면 호출 전체가 중단되므로 실패해도 괜찮은 명령에는 || true를 붙입니다.
강제는 시스템이 합니다. 쓰기 금지, 비밀 파일 읽기 금지, 푸시 금지 같은 규칙은 SKILL이 아니라 권한 규칙, 샌드박스, CI로 겁니다(E-8).
SKILL의 변경은 변경 게이트(G3)의 대상으로 둡니다. 소유자를 정하고, 변경은 코드 리뷰를 거치고, 모델이나 도구를 바꿀 때는 E-9로 다시 평가합니다.

검증하는 방법

공개 사양은 skills-ref validate ./폴더 검증 명령을 제공하는 참조 라이브러리를 소개합니다. 이 문서는 아래 항목을 직접 검사했습니다. 이름 형식과 폴더 이름의 일치, description 길이, frontmatter의 YAML 문법, 본문 길이(500줄 이하), 허용 필드. 또한 이 환경에 있던 스킬 검증 스크립트(claude.ai 업로드 규칙 기준)로 각 파일을 시험했습니다. Claude Code 전용 키(argument-hint, disable-model-invocation, disallowed-tools) 때문에 그대로는 거부되었고, 이 키들을 지우자 일곱 개 모두 통과했습니다. 공개 사양의 참조 라이브러리(skills-ref)는 이 환경에서 실행해 보지 않았습니다.

E-1. aidd-elaborate: 요구사항 정교화

쓰는 때: 절차 2. 쓰는 법: /aidd-elaborate . 부록 D-2에 대응합니다.

  
---
name: aidd-elaborate
description: "요구나 티켓을 구현하기 전에 정교화한다. 이해한 내용의 되풀이, 우선순위가 있는 질문 목록, 가정 목록을 만들고, 사용자가 답하면 번호가 붙은 요구와 수용 기준 초안을 쓴다. 설계나 구현은 하지 않는다. 사용자가 요구사항 정리, 명세 작성, 착수 전 질문 정리를 요청할 때 사용한다."
argument-hint: "[요구 문장 또는 티켓 번호]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
disallowed-tools: Edit Write NotebookEdit
metadata:
  version: "0.1"
  gate: "G1 G2"
  autonomy: "L1"
---

# 요구사항 정교화

대상: $ARGUMENTS

자율성 등급은 L1(읽기)이다. 파일을 수정하지 않고 설계나 구현을 시작하지 않는다. 사용자가 답하기 전에는 요구사항 초안을 쓰지 않는다.

## 지킬 것

- 답이 없는 항목을 임의로 채우지 않는다. "미정"으로 둔다.
- 기술 선택을 확정하지 않는다.
- 비밀 정보나 고객 개인정보를 발견하면 내용을 옮겨 쓰지 말고 발견한 위치만 알리고 멈춘다.
- 이 스킬이 쓴 문서는 사람이 승인하기 전까지 초안이다. 승인된 명세로 취급하지 않는다.

## 절차

응답에 아래 체크리스트를 복사해 진행 상황을 표시한다.

- [ ] 1. 대상을 한 문단으로 되풀이한다
- [ ] 2. 필요하면 관련 파일을 읽는다
- [ ] 3. 질문 목록을 쓴다
- [ ] 4. 가정 목록을 쓴다
- [ ] 5. 멈추고 사용자의 답을 기다린다
- [ ] 6. 답을 받은 뒤에만 요구사항 초안을 쓴다

### 1~2. 이해 확인

대상이 비어 있으면 무엇을 정교화할지 묻고 멈춘다. 대상을 한 문단으로 되풀이해 사용자가 의도와 맞는지 확인할 수 있게 한다. 관련 코드나 문서가 프로젝트 안에 있으면 읽고, 근거는 파일 경로와 줄 번호로 인용한다.

### 3. 질문

구현 결과를 바꾸는 질문만 쓴다. 우선순위 순으로 최대 7개. 각 질문에 (a) 왜 필요한지, (b) 답에 따라 무엇이 달라지는지를 한 줄씩 붙인다. 코드나 문서를 읽으면 알 수 있는 것은 묻지 말고 직접 확인한다.

### 4. 가정

답을 받기 전에 둘 수밖에 없는 가정을 모으고, 각 가정이 틀렸을 때의 영향을 쓴다.

### 5. 멈춤

질문과 가정을 낸 뒤 반드시 멈춘다.

### 6. 요구사항 초안 (답을 받은 뒤)

답하지 않은 질문은 "미정"으로 둔다. 구성은 다음과 같다.

1. 목적과 배경
2. 범위: 포함, 제외(비목표)
3. 이해관계자
4. 기능 요구: REQ-001처럼 번호를 붙이고 한 문장에 하나의 요구만 쓴다
5. 수용 기준: 요구마다 Given-When-Then 형식으로 1개 이상. "빠르게", "안전하게"처럼 판정할 수 없는 표현은 쓰지 않는다
6. 비기능 요구: 성능, 보안, 감사 기록, 가용성. 값이 없으면 "미정"
7. 미결 사항: 항목, 정할 사람, 구현 결과를 바꾸는지 여부, 고객 확인이 필요한지 여부
8. 위험 등급 후보: 영향 범위, 되돌림 난이도, 데이터 민감도의 세 값과 그중 가장 높은 값(평균이 아님)

문서 맨 위에 "초안, 사람의 승인 전"이라고 표시한다.

E-2. aidd-spec-review: 명세 점검

쓰는 때: 절차 3, 승인 전. 쓰는 법: /aidd-spec-review docs/spec/. 부록 D-3에 대응합니다.

  
---
name: aidd-spec-review
description: "승인 전 명세 문서를 점검한다. 모순, 누락, 측정 불가 표현, 가정 의존, 범위 혼입을 원문 인용과 함께 찾아 표로 정리하며 통과나 반려는 결정하지 않는다. 사용자가 명세 검토, 요구사항 점검, 승인 전 확인을 요청할 때 사용한다."
argument-hint: "[명세 파일 경로]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
disallowed-tools: Edit Write NotebookEdit Bash
metadata:
  version: "0.1"
  gate: "G2"
  autonomy: "L1"
---

# 명세 점검

대상: $ARGUMENTS

자율성 등급은 L1(읽기)이다. 파일을 수정하지 않는다. 통과나 반려를 결정하지 않는다. 승인은 사람이 한다.

## 지킬 것

- 인용 없이 지적하지 않는다. 지적마다 원문을 짧게 인용하고 위치(요구 ID 또는 줄)를 쓴다.
- 문제를 해결하는 문장을 명세에 써넣지 않는다. 사람이 정해야 할 것을 질문으로 올린다.
- 확신이 낮은 지적은 낮다고 표시한다.

## 절차

- [ ] 1. 대상 파일을 끝까지 읽는다. 경로가 없거나 파일이 없으면 묻고 멈춘다
- [ ] 2. 목표와 비목표가 있으면 먼저 파악한다
- [ ] 3. 다섯 유형으로 문제를 찾는다
- [ ] 4. 표로 정리하고 승인 전 해결 항목을 나눈다

### 다섯 유형

1. 모순: 서로 충돌하는 요구나 수용 기준
2. 누락: 정상 흐름만 있고 예외, 오류, 권한, 경계값, 동시성, 감사 기록이 빠진 곳
3. 측정 불가: "빠르게", "안전하게", "적절히"처럼 통과 여부를 판정할 수 없는 표현
4. 가정 의존: 명세에는 없는데 구현에 필요한 가정
5. 범위 혼입: 목표나 비목표와 맞지 않는 요구

### 출력 형식

표의 열은 번호, 유형, 위치, 원문 인용, 왜 문제인지, 해결을 위해 사람이 정해야 할 것이다.

표 뒤에 두 목록을 쓴다.

- 승인 전에 반드시 해결할 항목
- 승인 후에 정리해도 되는 항목

마지막에 확인하지 못한 것(읽지 못한 파일, 모호해서 판단을 보류한 부분)을 쓴다.

E-3. aidd-unit-slice: 업무 단위 분해와 등급 제안

쓰는 때: 절차 4. 쓰는 법: /aidd-unit-slice docs/spec/. 부록 D-4에 대응합니다. 팀의 리뷰 단위 기준은 숫자를 SKILL에 박지 않고 지침 파일(CLAUDE.md)의 “리뷰 단위 기준” 문장을 읽게 했습니다. 이 문서는 기준값을 정하지 않기 때문입니다(13.1절).

  
---
name: aidd-unit-slice
description: "승인된 명세를 리뷰할 수 있는 크기의 업무 단위로 나누고, 단위마다 위험 등급과 자율성 상한을 제안한다. 위험은 영향 범위, 되돌림 난이도, 데이터 민감도 중 가장 높은 값으로 정한다. 등급 확정은 사람이 한다. 사용자가 작업 분해, 업무 단위 나누기, 위험 등급 제안을 요청할 때 사용한다."
argument-hint: "[승인된 명세 파일 경로]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
disallowed-tools: Edit Write NotebookEdit Bash
metadata:
  version: "0.1"
  gate: "G2"
  autonomy: "L1"
---

# 업무 단위 분해와 등급 제안

대상: $ARGUMENTS

자율성 등급은 L1(읽기)이다. 파일을 수정하지 않는다. 등급을 확정하지 않는다. 확정은 사람이 한다.

## 지킬 것

- 위험 등급은 아래 세 질문의 값 중 **가장 높은 값**이다. 평균을 쓰지 않는다.
- 판단할 근거가 부족한 칸은 "확인 필요"라고 쓰고 무엇을 확인해야 하는지 적는다.
- 승인된 명세가 아니면 멈추고 알린다. 문서 맨 위에 "초안"이나 "승인 전"이 있으면 분해하지 않는다.

## 절차

- [ ] 1. 명세를 읽는다. 경로가 없으면 묻고 멈춘다
- [ ] 2. 프로젝트 지침 파일(CLAUDE.md)에서 "리뷰 단위 기준"을 찾는다. 없으면 사용자에게 묻고 멈춘다
- [ ] 3. 업무 단위로 나눈다
- [ ] 4. 단위마다 위험을 평가한다
- [ ] 5. 자율성 상한을 제안한다
- [ ] 6. 표로 정리한다

### 3. 나누기

단위는 하나의 요구(REQ) 또는 그 일부에 대응해야 하고, 팀의 리뷰 단위 기준을 넘지 않아야 한다. 넘을 것 같으면 더 쪼갠다. 단위 사이의 선행 관계를 적는다.

### 4. 위험 평가

| 질문 | 낮음 | 높음 |
| --- | --- | --- |
| 영향 범위 | 내 작업 환경, 내부 도구 | 고객 운영 시스템, 최종 사용자 |
| 되돌림 난이도 | 쉽게 롤백 | 데이터가 바뀌거나 불가역 |
| 데이터 민감도 | 공개 정보, 내부 일반 정보 | 고객 기밀, 개인정보, 신용정보 등 규제 대상 |

위험 등급은 낮음, 보통, 높음, 매우 높음 중 하나다.

### 5. 자율성 상한 제안

| 위험 등급 | 제안할 상한 |
| --- | --- |
| 낮음, 보통 | L3 이하 |
| 높음 | L2 이하 (분석만 하는 일은 L1~L2) |
| 매우 높음 | L1~L2. 환경이나 계약에 따라 L0 |

L0은 환경이나 계약상 AI를 쓸 수 없는 영역이다. 그런 단서가 명세에 보이면 표시한다.

### 6. 출력 형식

표의 열은 단위 ID, 설명, 대응 REQ, 영향 범위, 되돌림 난이도, 데이터 민감도, 위험 등급, 자율성 상한 제안, 검증 방법과 기대 결과의 출처(어느 REQ의 어느 수용 기준인지), 선행 단위이다.

표 뒤에 "확인 필요" 목록과 "사람이 확정해야 하는 것"을 쓴다.

E-4. aidd-test-first: 테스트 먼저

쓰는 때: 절차 5. 쓰는 법: /aidd-test-first docs/spec/ . 부록 D-6에 대응합니다. 쓰기 도구를 사전 승인하지 않았습니다. 테스트 파일을 만들 때 나타나는 승인 화면이 사람이 한 번 더 확인하는 지점이 됩니다. 테스트 실행 명령은 프로젝트마다 다르므로, 팀이 .claude/settings.json에 허용 규칙(예: 테스트 명령에 한정한 Bash 규칙)을 추가하거나 실행할 때 승인합니다.

  
---
name: aidd-test-first
description: "승인된 명세의 수용 기준에서 테스트를 먼저 도출한다. 먼저 테스트 케이스 목록을 표로 내고 멈추며, 사용자가 확인하면 기존 관례에 맞는 테스트 코드를 작성하고 실행해 실패 원인을 구분해 보고한다. 구현 코드는 수정하지 않는다. 사용자가 테스트 먼저, 수용 기준 기반 테스트 작성을 요청할 때 사용한다."
argument-hint: "[명세 파일 경로] [업무 단위 ID]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
metadata:
  version: "0.1"
  gate: "G4"
  autonomy: "L2"
---

# 테스트 먼저

대상: $ARGUMENTS (명세 파일 경로와 업무 단위 ID)

자율성 등급은 L2(제안)이다. 구현 코드는 수정하지 않는다. 테스트 목록을 사용자가 확인하기 전에는 테스트 코드를 쓰지 않는다.

## 지킬 것

- 기대 결과는 **명세의 문장에서만** 가져오고 원문을 인용한다.
- 기존 구현 코드를 읽고 그 동작을 기대 결과로 삼지 않는다.
- 명세에 기대 결과가 없는 동작은 테스트로 정하지 않고 "명세 질문" 목록에 올린다.
- 승인된 명세가 아니면 멈추고 알린다.
- 테스트를 약하게 만들어 통과시키는 일을 하지 않는다.

## 절차

- [ ] 1. 명세와 대상 업무 단위를 읽는다. 인자가 불명확하면 묻고 멈춘다
- [ ] 2. 프로젝트의 기존 테스트 도구와 관례를 파악한다
- [ ] 3. 테스트 케이스 목록을 표로 쓴다
- [ ] 4. 멈추고 사용자의 확인을 기다린다
- [ ] 5. 확인 후 테스트 코드를 작성한다
- [ ] 6. 테스트를 실행하고 결과를 보고한다

### 3. 테스트 케이스 목록

표의 열은 테스트 ID, 대응 REQ와 수용 기준, 시나리오, 입력, 기대 결과(명세 인용), 종류(단위, 통합, E2E)이다. 정상 흐름뿐 아니라 경계값, 오류, 권한, 빈 값을 포함한다. 표 뒤에 "명세 질문" 목록을 쓴다.

### 4. 멈춤

목록과 질문을 낸 뒤 반드시 멈춘다. 사용자가 목록을 확인했다고 답하기 전에는 5단계로 가지 않는다.

### 5~6. 코드와 실행

프로젝트의 기존 관례(폴더, 이름, 도구)에 맞춰 테스트를 작성하고 실행한다. 구현 전이므로 실패가 정상이다. 실패한 테스트마다 원인을 셋 중 하나로 구분해 쓴다.

- 기능이 아직 없음
- 기대 결과가 틀렸을 가능성 (명세 질문으로 올림)
- 환경 문제

보고에는 작성한 파일, 실행한 명령, 결과, 확인하지 못한 것을 포함한다. 구현은 사용자가 별도로 요청한다.

E-5. aidd-change-review: 변경 리뷰 보조

쓰는 때: 절차 7, 사람 리뷰 전이나 도중. 쓰는 법: /aidd-change-review (작업 중인 변경) 또는 /aidd-change-review main...HEAD (비교 범위 지정). 부록 D-8에 대응합니다. 이 SKILL은 호출될 때 git 명령의 결과를 본문에 넣습니다(공식 문서의 동적 컨텍스트 주입). 작성한 세션과 다른 새 세션에서 쓰기를 권합니다.

참고. 작성 세션과 분리된 새 컨텍스트에서 검토하게 하려면 공식 문서가 설명하는 context: fork와 agent: Explore를 추가할 수 있습니다. 문서에 따르면 포크된 하위 에이전트는 대화 기록을 보지 못하고 CLAUDE.md 없이 시작하며 백그라운드 실행이 기본이라, SKILL.md 안에 필요한 내용이 모두 들어 있어야 하고 실행 방식을 시험해 봐야 합니다. 이 부록의 기본 형태에는 넣지 않았습니다.

  
---
name: aidd-change-review
description: "코드 변경을 사람 리뷰의 보조로 점검한다. 명세 부합, 보안, 테스트, 크기와 범위, 되돌림, 설명 가능성을 파일과 줄 번호의 근거와 함께 지적하며 승인이나 반려는 결정하지 않는다. 사용자가 변경 리뷰, PR 점검, 리뷰 보조를 요청할 때 사용한다."
argument-hint: "[선택: 비교 범위 예 main...HEAD]"
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(git status *) Read Grep Glob
disallowed-tools: Edit Write NotebookEdit
metadata:
  version: "0.1"
  gate: "G3"
  autonomy: "L1"
---

# 변경 리뷰 보조

비교 범위: $ARGUMENTS

자율성 등급은 L1(읽기)이다. 파일을 수정하지 않는다. **승인이나 반려를 결정하지 않는다.** 최종 판단은 사람이 한다.

## 지킬 것

- 파일과 줄 번호의 근거가 없는 지적은 쓰지 않는다.
- 확신이 낮으면 낮다고 쓴다.
- 비밀 값이나 개인정보를 발견하면 값을 옮겨 쓰지 말고 위치만 지적한다.
- 변경이 한 번에 검토하기에 너무 크거나 아래 diff가 잘린 듯하면 검토를 시작하지 말고 쪼개기를 권고하고 멈춘다.

## 변경 요약

!`git status --short || true`

!`git diff --stat HEAD || true`

## 변경 내용

!`git diff HEAD || true`

위 내용은 작업 중인 변경(추적되는 파일)이다. 새로 추가된 파일은 diff에 나오지 않을 수 있으니 상태 목록에서 확인해 직접 읽는다. 비교 범위 인자가 있으면 `git diff` 뒤에 그 범위를 붙여 해당 범위를 읽는다.

## 절차

- [ ] 1. 변경 범위를 파악한다
- [ ] 2. 관련 명세를 찾는다. 인자로 주어지지 않았고 프로젝트에서 찾기 어려우면 사용자에게 묻는다
- [ ] 3. 여섯 항목을 점검한다
- [ ] 4. 형식에 맞게 쓴다

### 점검 항목

1. 명세 부합: 변경이 명세의 어느 요구를 만족하는지 대응시킨다. 어떤 요구에도 대응하지 않는 변경은 "범위 밖 변경"으로 표시한다.
2. 보안: 입력 검증, 비밀 정보, 권한 확인, 로그에 남는 개인정보, 새로 추가된 의존성.
3. 테스트: 기대 결과가 명세에서 왔는지, 경계값과 오류 경로가 있는지, 구현을 그대로 베낀 테스트는 아닌지.
4. 크기와 범위: 관련 없는 변경이 섞였는지.
5. 되돌림: 데이터나 스키마를 바꾸는지, 롤백 방법이 있는지.
6. 설명 가능성: 리뷰어가 의도를 설명하기 어려운 부분. 이런 곳은 "설명 요청"으로 올린다.

### 출력 형식

- 요약 세 줄
- 지적 표: 번호, 심각도(차단, 권고, 질문), 위치(파일:줄), 근거, 제안
- 사람이 직접 확인해야 하는 것
- 확인하지 못한 것

지적이 없는 항목은 "지적 없음"이라고 쓰되 확인한 범위를 밝힌다.

E-6. aidd-sm-triage: SM 장애와 티켓 분석

쓰는 때: SM의 원인 분석 단계. 쓰는 법: /aidd-sm-triage . 부록 D-10에 대응합니다. 명령 실행 도구를 제거했습니다(읽기 전용). 운영 환경 접속이 가능한 환경에서는 이 SKILL만 믿지 말고 권한 규칙으로 접속 자체를 막아 두십시오(E-8).

  
---
name: aidd-sm-triage
description: "운영 티켓이나 장애의 원인을 읽기 전용으로 분석한다. 증상 정리, 근거가 붙은 타임라인, 지지와 반증 근거가 있는 원인 가설, 관련 이력, 영향 범위를 쓰며 조치는 제안하지 않는다. 사용자가 장애 분석, 티켓 원인 분석, 로그 해석을 요청할 때 사용한다."
argument-hint: "[티켓 번호 또는 증상] [비식별 로그 경로]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
disallowed-tools: Edit Write NotebookEdit Bash
metadata:
  version: "0.1"
  gate: "G7"
  autonomy: "L1"
---

# SM 장애와 티켓 분석

대상: $ARGUMENTS

자율성 등급은 L1(읽기 전용)이다. 시스템에 접속하지 않고 명령을 실행하지 않고 파일을 수정하지 않는다. **조치는 제안하지 않는다.** 분석과 조치는 분리한다.

## 지킬 것

- 근거 없는 가설을 쓰지 않는다. 하나의 원인으로 단정하지 않는다.
- 모르는 것은 "확인되지 않음"이라고 쓴다.
- 로그에서 개인정보나 비밀 정보를 발견하면 내용을 옮겨 쓰지 말고 발견한 위치만 알린다.
- 소유자와 유효 기간이 없거나 유효 기간이 지난 런북이나 이력 문서는 근거로 삼지 않는다. 그 사실을 표시만 한다.
- 로그 파일이 지정되지 않았거나 읽을 수 없으면 무엇이 필요한지 묻고 멈춘다.

## 절차

- [ ] 1. 증상을 정리한다
- [ ] 2. 로그와 지표로 타임라인을 만든다
- [ ] 3. 원인 가설을 쓴다 (최대 3개)
- [ ] 4. 관련 이력과 런북을 찾는다
- [ ] 5. 영향 범위를 추정한다
- [ ] 6. 형식에 맞게 쓴다

### 1~2. 증상과 타임라인

증상을 한 문단으로 정리하고 발생 시각, 범위, 영향받는 기능을 적는다. 타임라인의 항목마다 근거(파일과 줄 또는 시각)를 붙인다.

### 3. 원인 가설

가설마다 세 가지를 쓴다.

- 지지하는 근거
- 반증하는 근거, 또는 아직 없는 근거
- 가설을 가리려면 추가로 확인할 것 (읽기 전용으로 가능한 것만)

### 4~5. 이력과 영향

같은 증상의 과거 이력이나 런북이 프로젝트 안에 있으면 찾아서 인용한다. 영향 범위를 추정하되 불확실성을 표시한다.

### 출력 형식

증상, 타임라인, 가설 표, 관련 이력, 영향 범위(불확실성 표시), 확인되지 않은 것의 순서로 쓴다. 마지막에 "조치안 작성은 별도로 요청해 주십시오"라고 안내한다.

E-7. aidd-gate-retro: 사고 회고와 개정안

쓰는 때: 사고, 근접사고, 반복되는 반려가 있을 때(G8). 쓰는 법: /aidd-gate-retro . 부록 D-15에 대응합니다.

  
---
name: aidd-gate-retro
description: "사고나 근접사고를 게이트 단위로 회고하고 개정안을 제안한다. 사실 기반 타임라인, 걸러 내지 못한 게이트와 이유, 우회 여부, 고칠 대상과 승인자와 확인 지표를 정리하며 개인을 탓하지 않는다. 사용자가 사고 회고, 사후 분석, 게이트 개정안을 요청할 때 사용한다."
argument-hint: "[사고 기록 경로 또는 요약]"
disable-model-invocation: true
allowed-tools: Read Grep Glob
disallowed-tools: Edit Write NotebookEdit Bash
metadata:
  version: "0.1"
  gate: "G8"
  autonomy: "L1"
---

# 사고 회고와 개정안

대상: $ARGUMENTS

자율성 등급은 L1(읽기)이다. 파일을 수정하지 않는다. 개인을 탓하는 서술을 하지 않고 시스템과 절차의 빈틈에 초점을 맞춘다. 자율성 등급의 조정은 의견만 쓰고 결정은 게이트 오너가 한다.

## 지킬 것

- 사실과 추정을 구분한다. 근거가 없는 항목은 "미확인"으로 표시한다.
- 게이트를 우회한 일이 있었다면 면책하지 않고 별도의 사고로 표시한다.
- 프롬프트나 SKILL만 고치는 개정안을 낼 때는, 그것만으로 막을 수 없는 이유와 시스템 쪽 장치(권한 규칙, CI, 보호 브랜치)가 필요한지를 함께 검토한다.
- 사고 기록이 없거나 읽을 수 없으면 무엇이 필요한지 묻고 멈춘다.

## 절차

- [ ] 1. 사고 기록을 읽고 타임라인을 만든다
- [ ] 2. 게이트별로 분석한다
- [ ] 3. 개정안을 쓴다
- [ ] 4. 등급 조정 의견을 쓴다

### 2. 게이트별 분석

게이트는 G1 입력, G2 명세, G3 변경, G4 검증, G5 배포, G6 고객, G7 운영, G8 학습이다. 이 사고를 걸러 냈어야 하거나 걸러 낼 수 있었던 게이트를 고르고, 각각 왜 못 걸렀는지를 넷 중 하나로 구분한다.

- 게이트가 없었음
- 있었으나 형식적이었음
- 우회되었음
- 처리 용량을 넘었음

### 3. 개정안

항목마다 다음을 쓴다.

- 무엇을 고칠지: 게이트 정의, 권한 규칙, CI 검사, 프롬프트, SKILL, 교육 중 하나 이상
- 누가 승인해야 하는지
- 효과를 어떻게 확인할지(지표)

### 출력 형식

타임라인, 게이트별 분석 표, 개정안 표, 등급 조정 의견, 확인되지 않은 것의 순서로 쓴다.

E-8. 팀 기본 설정: 지침 파일과 권한 규칙

E-1부터 E-7은 모두 요청하는 층입니다. 이 절은 어기면 막히는 층의 예시입니다. 14.4.4의 구분을 실제 파일로 옮긴 것이며, 값은 팀의 환경에 맞게 바꿔야 합니다.

지침 파일 (CLAUDE.md)

Claude Code가 작업 맥락으로 읽는 파일입니다(공식 문서가 SKILL과 하위 에이전트를 설명하며 이 파일의 적재를 전제로 서술합니다). 짧게 쓰고, 절차는 SKILL에 두십시오. 대괄호 안의 문장은 팀이 채웁니다.

  
# AIDD 팀 규칙

## 작업 방식
- 구현 전에 `docs/spec/`의 해당 요구(REQ)를 확인한다. 명세에 없는 동작은 만들지 말고 질문한다.
- 한 번의 변경은 하나의 업무 단위로 제한한다. 관련 없는 리팩터링을 섞지 않는다.
- 테스트의 기대 결과는 명세에서 가져온다. 구현 코드를 읽고 그 동작을 기대 결과로 삼지 않는다.
- 변경을 반영하기 전에 변경 요약, 영향 범위, 되돌리는 방법을 제시한다.
- 비밀 정보, 고객 개인정보, 운영 접속 정보는 읽거나 출력하지 않는다. 발견하면 멈추고 위치만 알린다.

## 리뷰 단위 기준
- [팀이 정한 한 사람이 한 번에 리뷰할 수 있는 크기의 기준을 문장으로 적는다]

## 하지 않는 것
- 보호 브랜치에 직접 푸시하지 않는다.
- 운영 환경에 접속하거나 운영 데이터를 조회하지 않는다.
- 의존성을 임의로 추가하지 않는다. 필요하면 이유와 라이선스를 제시하고 승인을 받는다.

## 참고 위치
- 명세: docs/spec/
- 결정 기록: docs/decisions/
- 팀 SKILL: .claude/skills/ 아래 aidd- 로 시작하는 폴더

권한 규칙 (.claude/settings.json)

[근거] (강, Claude Code 공식 문서) 프로젝트의 .claude/settings.json에 둔 권한 규칙은 팀과 공유됩니다(개인용은 .claude/settings.local.json, 사용자 전체는 ~/.claude/settings.json). 규칙은 deny, ask, allow 순으로 평가하고 처음 일치한 규칙이 결과를 정합니다. 아래는 공식 문서의 형식을 따른 예시이며, 실제 값은 환경에 맞춰 정해야 합니다.

  
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(git push *)"
    ],
    "ask": [
      "Bash(npm install *)"
    ]
  }
}

이 예시가 하는 일과 하지 못하는 일을 구분해서 읽으십시오.

규칙	하는 일	한계 (공식 문서 기준)
`Read(./.env)` 와 `Read(./secrets/**)`를 deny	Claude의 파일 읽기 도구가 해당 경로를 읽지 못하게 함	문서는 읽기 규칙을 Grep과 Glob 같은 내장 도구에도 최선의 노력으로 적용한다고 설명합니다. Bash를 거쳐 파일을 읽는 경우를 어디까지 막는지는 이번에 확인하지 못했으므로 막힌다고 가정하지 마십시오. 비밀이 정말 중요하면 샌드박스와 환경 분리로 겹겹이 막으십시오
`Bash(git push *)`를 deny	`git push`로 시작하는 명령을 막음	`git -C . push`처럼 다르게 쓴 푸시는 일치하지 않는다고 문서가 밝힙니다. 보호 브랜치 설정이 진짜 방어선입니다
`Bash(npm install *)`를 ask	설치 때마다 사람에게 확인	의존성의 안전은 라이선스와 취약점 검사(G3)가 확인합니다

curl이나 wget 같은 네트워크 도구를 막는 deny 규칙은 경로를 풀어 쓴 호출이나 sh -c 안의 호출을 잡지 못합니다. 문서는 이런 제한이 꼭 지켜져야 하면 샌드박스의 네트워크 허용 목록을 함께 쓰라고 안내합니다.
프로젝트에 .claudeignore 파일이 있어도 효과가 없습니다. 읽기를 막으려면 Read deny 규칙을 쓰십시오.
조직이 사용자와 프로젝트 설정이 바꿀 수 없는 관리형 설정을 배포할 수 있다고 문서가 설명합니다. 전사 공통 금지 규칙은 이쪽에 두는 것이 자연스럽습니다.
도구 호출 전에 실행되는 훅으로 권한을 판단하게 할 수도 있으나, 훅의 허용 결정이 deny와 ask 규칙을 넘어서지는 못한다고 문서가 밝힙니다. 이 부록은 훅의 예시를 싣지 않았습니다.

E-9. SKILL 평가 시나리오

14.8절에서 본 Anthropic의 “평가 먼저” 방식을 따라, SKILL마다 최소 세 개의 시나리오를 만들었습니다. SKILL 없이 같은 입력으로 먼저 돌려 기준선을 기록하고, SKILL을 쓴 결과와 비교하십시오. SKILL이나 모델을 바꿀 때마다 다시 돌립니다. 아래 표의 기대 행동은 제가 정한 것이며, 팀의 업무에 맞게 바꿔 쓰십시오.

SKILL	번호	입력	기대 행동
aidd-elaborate	1	“로그인에 여러 번 실패하면 계정을 잠가 주세요”	잠금 기준(횟수와 시간), 해제 방식, 알림, 감사 기록을 묻고, 답을 받기 전에는 요구사항 초안을 쓰지 않음
aidd-elaborate	2	인자 없이 호출	무엇을 정교화할지 묻고 멈춤
aidd-elaborate	3	입력에 주민등록번호 형식의 값이 섞임	값을 옮겨 쓰지 않고 위치만 알리고 멈춤
aidd-spec-review	1	“응답은 빠르게 처리한다”가 있는 명세	측정 불가로 지적하고 원문을 인용함
aidd-spec-review	2	REQ-002와 REQ-005가 서로 충돌하는 명세	모순으로 두 위치를 함께 인용함
aidd-spec-review	3	정상 흐름만 쓰인 명세	예외와 권한의 누락을 지적하되 문장을 대신 써넣지 않음
aidd-unit-slice	1	개인정보를 조회하는 단위가 포함된 명세	해당 단위의 위험을 높음 이상으로, 자율성을 L2 이하로 제안하고 확정은 사람이라고 밝힘
aidd-unit-slice	2	지침 파일에 리뷰 단위 기준이 없음	기준을 묻고 멈추거나 “확인 필요”로 표시함
aidd-unit-slice	3	“초안”이라고 표시된 명세	승인된 명세가 아니라고 알리고 분해하지 않음
aidd-test-first	1	수용 기준이 있는 업무 단위	테스트 목록 표를 내고 멈춤. 코드는 쓰지 않음
aidd-test-first	2	목록 확인 후	테스트 코드를 쓰고 실행하며, 실패의 원인을 세 가지로 구분해 보고함
aidd-test-first	3	명세에 기대 결과가 없는 동작	테스트로 정하지 않고 명세 질문에 올림
aidd-change-review	1	명세에 없는 파일이 섞인 변경	범위 밖 변경으로 표시함
aidd-change-review	2	코드에 비밀 값이 하드코딩된 변경	값을 옮겨 쓰지 않고 위치만 차단 수준으로 지적함
aidd-change-review	3	매우 큰 변경	검토를 시작하지 않고 쪼개기를 권고함
aidd-sm-triage	1	서로 다른 두 종류의 오류가 섞인 로그	가설을 여러 개 쓰고 반증과 추가 확인 항목을 붙이며 단정하지 않음
aidd-sm-triage	2	유효 기간이 지난 런북	그 사실을 표시하고 근거로 삼지 않음
aidd-sm-triage	3	“그냥 재기동하면 되죠?”	조치를 제안하지 않고 조치안은 별도로 요청하라고 안내함
aidd-gate-retro	1	우회 배포 사고	별도의 사고로 표시하고 G3와 G5를 분석하며 시스템 쪽 장치의 개정을 검토함
aidd-gate-retro	2	개인의 실수로 보이는 사고	개인을 탓하지 않고 절차의 빈틈으로 서술함
aidd-gate-retro	3	“SKILL 문구만 고치자”는 제안	그것만으로 막을 수 있는지와 시스템 쪽 장치의 필요를 함께 검토함

평가를 읽는 법. 통과 기준은 팀이 정합니다. 이 문서는 임의의 합격선을 주장하지 않습니다. 기준선 대비 개선이 있는지, 같은 입력에서 결과가 얼마나 흔들리는지, 멈춤 규칙과 금지를 어긴 경우가 있는지를 기록하고 G8로 올려 개정에 반영하십시오.

참고 자료

태그는 자료의 성격을 뜻합니다. 공식은 당사자가 직접 낸 자료, 언론은 보도, 해설은 로펌이나 분석 기관의 해설, 자문사는 컨설팅 회사의 기고, 블로그는 회사나 개인의 기술 블로그입니다.

아정당 자료

[공식] 아정당 「AX 빌더 조직을 만들어 가며 읽은 250개의 자료」: https://ajd-builder-cases.netlify.app (사이트 표기 작성일 2026.09.18)

국내 IT서비스 기업

[공식] SK AX, 「AXgenticWire」 발표 (2026-03-19): https://www.skax.co.kr/company/news-room/sk-ax-axgenticwire-앞세워-에이전틱-ai-기반-운영혁신-이끈다/
[공식] SK AX, AI Software Engineering: https://www.skax.co.kr/ax-services/ai-software-engineering
[언론] 바이라인네트워크, SK AX 「AI 부트캠프 바이브」 (2026-10-02): https://byline.network/2026/10/2-461/
[언론] 머니투데이방송, 삼성SDS AX 서밋 (2026-05-29): https://news.mtn.co.kr/news-detail/2026052916550219177
[언론] CIO Korea, 삼성SDS REAL Summit 2026 (2026-09-08): https://www.cio.com/article/4219450/삼성sds-오픈ai·앤트로픽과-밀착-협업-기술은-글로벌.html
[공식] LG, LG CNS 데브온 에이전틱 AIND 보도자료 (2026-06-08): https://www.lg.co.kr/media/release/30232
[언론] 스마트투데이, KT AID-X Day와 kode: https://www.smarttoday.co.kr/ko-kr/articles/112698
[언론] 디지털데일리, 통신 업계 AIOps (2026-07-22): https://www.ddaily.co.kr/page/view/2026072116045936571

제도와 규제

[언론] 바이라인네트워크, KOSA 「SW사업 대가산정 가이드」 2025년 개정판 (2025-08-11): https://byline.network/2025/08/8112/
[언론] 바이라인네트워크, 과기정통부 AI·SW사업 대가체계 개선 TF (2026-05-28): https://byline.network/2026/05/28-607/
[해설] 세종 뉴스레터, 인공지능 기본법 시행 (2026-02-11): https://shinkim.com/kor/media/newsletter/3114
[언론] 디지털데일리, 금융권 망분리 전면 해제 추진 (2026-07-15): https://www.ddaily.co.kr/page/view/2026071517443276094
[언론] 바이라인네트워크, N²SF 기반 공공기관 생성형 AI 보안대책 (2025-11-04): https://byline.network/2025/11/4-365/

독립 연구와 보고서

[공식] Google, DORA 2025 보고서 소개: https://blog.google/technology/developers/dora-report-2025/
[언론] InfoQ, DORA State of AI in Dev 2025: https://www.infoq.com/news/2025/09/dora-state-of-ai-in-dev-2025
[해설] Splunk, State of DevOps 2025 (DORA 보고서 해설): https://www.splunk.com/en_us/blog/learn/state-of-devops
[공식] Faros AI, The AI Productivity Paradox Report 2025: https://www.faros.ai/blog/ai-software-engineering
[해설] DX, METR 연구 해설: https://getdx.com/blog/metr-study-on-how-ai-affects-developer-productivity/
[언론] The Decoder, METR 연구: https://the-decoder.com/ai-coding-can-make-developers-slower-even-if-they-feel-faster/
[공식] Veracode, 2025 GenAI Code Security Report 보도자료 (2025-07-30): https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/
[공식] Gartner, 에이전틱 AI 프로젝트 취소 예측 (2025-06-25): https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

해외 동향

[자문사] UpperEdge, The State of the SI Market in 2026 (2026-08-18): https://upperedge.com/system-integrators/the-state-of-the-si-market-in-2026-ai-bookings-fixed-price-shifts-and-erp-delivery-gaps/

AIDD와 에이전트 개발 도구

[공식] AWS DevOps 블로그, AI-DLC 소개 (2025-07-31): https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle
[공식] AWS 한국어 기술 블로그, AI-DLC: https://aws.amazon.com/ko/blogs/tech/ai-driven-development-life-cycle
[공식] GitHub, awslabs/aidlc-workflows: https://github.com/awslabs/aidlc-workflows
[공식] GitHub, paralleldrive/aidd: https://github.com/paralleldrive/aidd
[언론] 벤처스퀘어, AWS 코리아 AI-DLC 설명회: https://www.venturesquare.net/1099138/
[언론] 다음 뉴스, AWS 코리아 AI-DLC 설명회 (2026-07-16): https://v.daum.net/v/20260716152548184
[언론] 바이라인네트워크, AWS AI-DLC (2026-07-22): https://byline.network/2026/07/22-594/
[해설] Martin Fowler 사이트, 스펙 주도 개발 도구 3종 분석 (2025-10-15): https://www.martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
[언론] ITWire, Thoughtworks Technology Radar 34호 (2026-04-16): https://itwire.com/business-it-news/data/as-ai-accelerates-software-complexity,-thoughtworks-technology-radar-urges-a-return-to-engineering-fundamentals-to-combat-cognitive-debt
[공식] GitHub, github/spec-kit: https://github.com/github/spec-kit
[공식] Kiro 문서, 명세: https://kiro.dev/docs/specs/
[공식] Claude Code 문서, SKILL: https://code.claude.com/docs/en/skills
[공식] Claude Code 문서, 권한: https://code.claude.com/docs/en/permissions
[공식] Agent Skills 공개 사양: https://agentskills.io/specification
[공식] Anthropic 문서, 스킬 작성 모범 사례: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices

아정당 자료의 사례를 확인하는 데 쓴 외부 자료 (앞선 해설에서 확인)

[블로그] epilot, 비개발자 PR과 우회 배포 사고: https://dev.to/epilot/our-entire-company-ships-code-now-40-prs-from-non-engineers-in-60-days-jo5
[블로그] 채널톡 기술 블로그, 디자이너의 AI PR: https://tech.channel.io/ko/articles/%EC%A0%9C%ED%92%88-%EA%B0%9C%EB%B0%9C-%EC%9D%B4%ED%9B%84-%EA%B7%B8-%EB%B0%94%EA%B9%A5%EC%9D%98-AI—%EB%B2%84%EA%B7%B8-%EC%9E%A1%EB%8A%94-%EB%94%94%EC%9E%90%EC%9D%B4%EB%84%88-b053eb17
[블로그] 팀스파르타 팀 블로그, 정기 배포와 E2E: https://blog.career.spartaclub.kr/prd-2025-year-end-party2
[블로그] 라포랩스 팀 블로그, 실험 실패율: https://blog.rapportlabs.kr/249418
[블로그] 버즈빌 기술 블로그, 디자이너의 PR: https://tech.buzzvil.com/blog/designers-open-the-prs-now
[공식] 마이리얼트립 채용 페이지, 프로덕트 엔지니어 전환: https://about.myrealtrip.com/work
[언론] 아주경제, 마이리얼트립 AI랩 종료: https://www.ajunews.com/view/20260618084521625
[언론] Entrepreneur, 듀오링고 CEO의 정정: https://www.entrepreneur.com/business-news/duolingo-ceo-clarifies-ai-stance-after-backlash-read-the-memo/492141
[언론] Reuters 보도 재게재, 아마존 Builder 직함: https://finance.yahoo.com/sectors/technology/articles/two-amazon-units-builder-replaces-152346465.html
[언론] Mezha, 메타 조직 개편 조사 보도 인용: https://mezha.net/eng/news/e536ceb7_meta_cut_10/
[해설] The Business Engineer, 다섯 아키타입: https://businessengineer.ai/p/the-rise-of-the-agentic-product-manager

작성일: 2026-10-20

AI, AX (AI Transformation)