3줄 요약

• AI에게 비판자 역할을 부여하는 「적대적 리뷰 (Adversarial Review)」가 확산되고 있다. 이 기사는 지적이 돌아온 후의 채택 여부를 실제 로그 9건의 분류를 통해 보여준다.
• 이번 9건의 내역은 요구대로 수용한 5건, 수용할 수준을 선택한 2건, 문서 외의 사실을 확인하지 않으면 결정할 수 없는 2건이었다. 거절은 0건이었다.
• 채택 여부의 난점은 거절하는 용기가 아니라, 어느 수준에서 수용할 것인가의 선택에 있다. 선택하지 않은 수준은 숨기지 않고 문서에 기록하며, 그 기록이 경영 회의의 예상 문답이 된다.

리뷰를 시키는 것까지는 누구나 같다

AI에게 비판자 역할을 부여하여 리뷰를 시키는 패턴이 확산되기 시작한 듯하다.

얼마 전에도, 요청 방식을 「리뷰해줘」에서 「적대적으로 검증해줘」로 바꾸면 지적의 질이 달라진다는 기사가 널리 읽혔다.

그 기사는 수용할 것인지, 수용 수준을 낮출 것인지, 거절할 것인지, 채택 여부를 결정하는 것은 인간이라고 결론지으며, 자신의 기사에 대한 지적을 어떻게 처리했는지에 대한 실제 사례까지 싣고 있다.

전적으로 동감하며, 나 또한 같은 패턴을 일상적인 운용에 도입하고 있는 쪽이다.

프롬프트와 운용 방식은 이전 기사에 썼다.

그 이전 기사에서, 돌아온 지적의 채택 여부를 결정하는 것이 이 패턴에서 가장 머리를 써야 하는 부분이라고 썼다.

1차 지적 중 1~2%는 채택하지 않는다고도 썼다.

이번에는 그 「채택하지 않는」 내용의 실체를 공개한다.

채택하지 않은 지적을 되돌아보면, 검증해 보니 사실이 달랐던 것, 이쪽의 문맥을 알지 못하기 때문에 발생한 오폭(誤爆), 그리고 주장은 맞지만 요구의 일부만 수용한 것이 섞여 있다.

처음 두 가지는 지적 측의 문제이므로 판단이 어렵지 않다.

어려운 것은 세 번째로, 지적이 맞는데 전부 수용하지는 않는 처리에는 수용할 것인가 거절할 것인가라는 이지선택이 통하지 않는다.

실제로 제대로 만들어진 적대적 리뷰의 지적 중, 정면으로 거부할 수 있는 것은 거의 섞여 들어오지 않는다.

그럼에도 불구하고 전부 말하는 대로 수용해 나가면, 제안은 전혀 다른 것으로 변해간다.

이 딜레마를 실제로 어떻게 처리했는지를, 경영 회의용 제안서 데모에 돌아온 실제 로그 9건의 분류를 통해 보여준다.

개정판에 2차 리뷰를 돌렸더니 9건이 돌아왔다

이전 기사의 데모를 이어간다.

지난번에는 8개의 허점을 심어둔 가상의 제안서(생성 AI 코딩 지원 도구 도입 제안)에 적대적 리뷰를 가하고, 지적을 반영한 개정판까지 만들었다.

150명에 대한 일제 도입이 30명의 파일럿(Pilot) 도입이 되고, 근거 없는 ROI가 검증 설계로 바뀐 버전이다.

이번에는 그 개정판을 이전과 동일한 프롬프트로, 문맥을 가지지 않은 새로운 세션의 리뷰에 돌렸다.

주제는 가상이지만, 로그는 실제로 AI가 내놓은 것이다.

응답 전문은 기사 말미의 부록에 두었으며, 본문에서는 요지로 나타낸다.

돌아온 것은 9건. 중대 6건, 중등도 2건, 경미 1건이었다.

• 【중대】 과제는 고객 프로젝트의 리드 타임(Lead time)인데, 파일럿은 자사 프로덕트 한정. 성공해도 과제가 해결되지 않는 설계다.
• 【중대】 「코딩이 지연의 원인」이라는 전제에 근거가 없다. 병목(Bottleneck)이 다른 곳이라면 효과가 없는 약이다.
• 【중대】 대조군이 없다. 10%의 개선이 도구의 효과인지, 우연히 쉬운 프로젝트가 이어진 것인지 구별할 수 없다. 10%·60%라는 임계값(Threshold)의 근거도 없다.
• 【중대】 「효율화율은 실측한다」라고 말하면서 측정 수단이 적혀 있지 않다. 자기 보고(Self-reporting)에 의존할 것이 눈에 보인다.
• 【중대】 품질 지표가 제로(0). 라이선스 혼입 등 AI 생성 코드 특유의 리스크에 대해서도 언급이 없다.
• 【중대】 「3명의 증원 억제」로의 비약. 전사 전개 시의 총비용도 제시되지 않았다.
• 【중】 법무와 정보 시스템 부서의 확인이 끝나지 않았는데 상정하고 있다. 순서가 반대다.
• 【중】 교육과 운용의 공수를 금액화하지 않아, 총비용이 54만 엔으로 보인다.
• 【경】 판단이 「전사 전개냐 계약 종료냐」의 이지선택이며, 중간 케이스의 취급과 30명의 선정 방법이 없다.

총평은 혹독하다.

「이대로 승인하면, 3개월 후에 『체감상으로는 호평이었습니다』 이상의 자료가 나오지 않아, 흐지부지한 전사 전개나 근거 없는 철수 중 하나가 될 가능성이 높다」.

다만, 그 총평 속에는 이런 구절도 있었다.

「과잉의 관점에서 본 중대한 지적은 없습니다. 54만 엔 + 3개월이라는 규모 자체는 타당합니다」.

1차 리뷰에서 「효과 미검증 상태로 150명에게 일제 도입」이라고 지적받았던 제안이, 규모에 대해서는 합격점을 받았다.

리뷰 출력은 매번 흔들리기 때문에, 이것 한 번으로 고쳐졌다는 증명은 되지 않는다.

그럼에도 지난번에 강하게 공격받았던 부분이 조용해지는 것은, 루프(Loop)를 돌리면서 얻을 수 있는 가장 알기 쉬운 피드백이다.

한편, 이번 9건에는 질적인 변화가 있었다.

1차 때도 캐시 환산이나 품질 같은 설계에 파고드는 지적은 있었지만, 대부분은 「계산식을 써라」, 「리스크를 언급해라」와 같이, 써야 할 것이 써져 있지 않다는 형태였다.

두 번째 순회는, 「그 검증 설계로 전개 판단을 내리기에 충분한 수치를 정말로 얻을 수 있는가」라는, 검증이 성립하는지 여부에 집중하고 있다.

모두 그럴듯하다.

사실 오인으로 일축할 수 있는 지적은 단 하나도 없었다.

그리고 그럴듯한 지적이 9건이나 나열되어 있는 것을 마주하면, 전부 수정하고 싶어진다.

여기서 갈림길이 생긴다.

전부 받아들이면 어떻게 되는가

지적은 전부 수정하는 것이라고 나도 초기에는 생각했다.

빈틈을 메우고, 리스크 항목을 추가하고, 단정을 약화시킨다.

그렇게 견고하게 만든 문서가 다시 읽어보면 묘하게 설득력이 떨어지는 듯한 체감, 이것이 이 분류(sorting)를 고민하기 시작한 계기다.

체감만으로는 이야기가 되지 않으므로, 이번 9건을 통해 확인해 본다.

지적을 요구 사항의 가장 강한 해석으로 받아들인다면 어떻게 될까.

지적 3을 상한선까지 받아들이면, 툴을 사용하지 않는 팀을 병행시키고 안건의 조건을 맞춰 관리하는 비교 실험이 된다.

지적 2를 상한선까지 받아들이면, 제안 전에 리드 타임(lead time) 전체의 요인 분석이 선행된다.

둘 다 단독으로는 올바른 방향을 향하고 있다.

하지만 둘 다 수 주에서 수개월이 소요되는 별개의 업무이며, 이를 쌓아 올리면 「54만 엔으로 3개월간 테스트하게 해달라」는 제안이, 긴 준비 기간을 요하는 검증 프로젝트 계획서로 변질된다.

빈틈은 메워지지만, 「작고 빠르게 시작한다」는 이 제안의 유일한 셀링 포인트(selling point)가 죽어버린다.

여기서 핵심이 되는 것은, 하나의 지적에는 요구 수준의 폭이 존재한다는 사실이다.

「대조군이 없다」는 통계적인 비교 실험을 하라는 뜻으로도 읽힐 수 있고, 비교할 만한 수치라도 가져오라는 뜻으로도 읽힐 수 있다.

어느 수준에서 받아들여야 할지는 지적 어디에도 적혀 있지 않다.

적혀 있을 리도 없다.

리뷰어(Reviewer)는 제안이 무엇에 승부를 걸고 있는지(betting)를 책임지고 있지 않기 때문이다.

따라서 받아들이는 수준을 결정하는 작업만은 리뷰의 외부에 계속 남게 된다.

채택 및 기각의 절차와 보조선

가장 먼저 할 일은 채택 여부가 아니라 검증이다.

지적이 제시한 사실이나 계산이 맞는지 확인한다.

AI의 지적은 정답이 아니므로, 오인한 지적을 그대로 받아들이면 문서는 오히려 부정확해진다.

이전 글의 데모에서도 「공수 절감은 캐시를 1엔도 만들어내지 못한다」라는 지적의 「1엔도」는 과장되었다고 판정하는 한편, 환산 경로를 적지 않았다는 부분만을 채택했다.

기각(rejection)이 등장할 차례는 주로 이 검증 단계에서 지적 측의 논리가 무너졌을 때이며, 따라서 검증을 통과한 지적에 기각이 내려지는 경우는 거의 없다.

검증을 통과한 지적은 네 가지 종류로 분류한다.

• 사실이나 계산의 오류에 대한 지적: 받아들인다. 확인 결과 옳았던 오류를 문서에 남겨둘 이유는 없다.
• 논리적 단절에 대한 지적 (주장과 근거가 연결되지 않음): 원칙적으로 받아들인다. 단, 수정 방법까지 지적을 따를 필요는 없다.
• 리스크와 망라성에 대한 요구 (이것도 검토해라, 이것도 써라): 받아들일 수준을 선택한다. 제안의 승부(bet)를 건드리지 않는 범위 내에서 가장 가벼운 형태부터 검토한다.
• 상황을 모르면 결정할 수 없는 지적: 문서를 수정하지 않고 숙제로 가져간다.

수준을 선택할 때의 보조선은 두 가지 질문으로 이루어져 있다.

첫 번째.

이 지적에 이 수준으로 응했을 때, 의사 결정에 사용할 수 있는 재료가 늘어나는가, 아니면 문서를 무난하게 만들기만 하는가.

여기서 말하는 「강한 문서」는 통과되기 쉬운 문서를 의미하는 것이 아니다.

판단 재료가 갖춰져 있어 의사 결정자가 올바르게 승부를 평가할 수 있는 문서를 의미한다.

두 번째.

재료가 늘어난다고 가정할 때, 그것을 얻기 위한 비용이 판단의 무게에 상응하는가.

재료는 공짜로 늘어나지 않는다.

대조군은 확실히 판단 재료를 늘려주지만, 54만 엔으로 3개월간, 그만두고 싶으면 그만둘 수 있는 실험을 위해 본체(main project)를 넘어서는 공수의 엄격함을 쌓는 것은 균형이 맞지 않는다.

이것이 전사 전개와 같이 되돌리기 어려운 판단 앞이라면 균형은 달라진다.

재료의 가치는 그것이 뒷받침하는 판단의 무게에 의해 결정된다.

그리고 수준을 낮춘 사실과 이유는 숨기지 않고 문서의 「검증의 한계」로서 기술한다.

불리한 지적을 뭉개기 위한 분류라면 리뷰를 할 의미가 없다.

선 긋기도 추가해 둔다.

승부(bet)라고 부르며 수준을 낮춰도 되는 것은 제안의 설계 판단(규모, 속도, 검증의 거칠기)에 한정한다.

법령, 안전, 품질의 하한선과 관련된 지적은 승부의 재료로 삼지 않는다.

그 하한선을 최종적으로 결정하는 것도 작성자가 아니라 법무나 품질의 각 담당자다.

여기서 말하는 수준의 선택은 그 직전 단계에서 작성자가 제안의 형태를 결정하는 작업을 가리킨다.

이 선을 넘어서 물러나기 시작하면, 적대적 리뷰(adversarial review)는 지적을 흘려듣기 위한 의식으로 변질된다.

9건을 어떻게 처리했는가

내역을 말하자면, 요구대로 받아들인 것이 5건, 받아들일 수준을 선택한 것이 2건, 문서 외부의 사실을 확인하지 않으면 결정할 수 없었던 것이 2건이다.

기각은 0건이었다.

미리 밝혀두자면, 이 분류 방식은 지적의 옳고 그름을 판정하는 것이 아니라 우리의 대응 방침을 분류한 것이며, 경계는 모호할 수 있다.

외부로 나가는 2건에 대해서도 문서를 수정했고, 수준(level)을 선택한 2건도 일부는 요구대로 수용했다.

그럼에도 불구하고, "지적이 틀렸기 때문에 수용하지 않겠다"라는 처리가 단 한 번도 나오지 않았다는 것이 '기각 제로(zero)'의 의미다.

요구대로 수용한 5건은 측정 수단의 결여(지적 4), 품질 지표의 결여(지적 5), 비용 개산의 결여(지적 6), 비용의 과소 표시(지적 8), 판단의 이지선다와 선정 방법(지적 9)이었다.

모두 응답할수록 판단 재료가 늘어난다.

효율화율은 툴(tool)의 이용 로그(제안 수락률 및 생성량)와 PR 통계로부터 추정하며, 추정에 그친다는 점을 명기한 상태에서 자기 신고 설문조사를 보조 수단으로 활용했다.

품질은 버그율과 리버트율(revert rate) 및 리뷰 지적 수를 KPI에 추가하고, 생성된 코드의 라이선스 스캔을 운용에 포함했으며, 리뷰 부하는 리뷰 시간의 추이를 통해 확인한다.

전사 전개 시의 비용은 교육과 운용을 포함한 총액 개산을 추가하였고, "인원 3명 증원을 억제한다"라는 단정적인 표현은 "억제 판단의 재료로 삼는다"로 완화했다.

중간 결과가 나왔을 때의 방침과 30명의 선정 방법(자원한 에이스급을 모으지 않고, 통상적인 안건을 처리하는 팀 단위로 선정)도 추가했다.

이 중 품질 지표의 결여에 대해서는 뼈아픈 지점이 있었다.

다시 읽어보니, 1차 로그에도 "품질 저하를 측정할 지표도 없다"라는 한마디가 들어 있었다.

개정할 때 속도에 대한 KPI만을 추가하고, 품질을 방치했던 것이다.

리뷰의 출력은 흔들리기 때문에, 메워지지 않은 구멍이 매번 포착된다는 보장은 없다.

그렇다고 해서 구멍 쪽에서 저절로 사라져 주지도 않는다.

이번 사례의 경우, 2차 리뷰에서 동일한 지적이 왔다는 사실 자체가 1차 채택 여부 판단에서의 누락을 검출해 주었다.

판단이 필요했던 것은 수준을 선택한 2건 쪽이다.

지적 3, 대조군(control group)이 없다.

전후 비교만으로는 개선이 툴의 효과인지, 아니면 단순히 편한 안건이 이어졌을 뿐인지 구분할 수 없다는 지적이다.

요구의 핵심은 "비교 대상(counterpart)을 가져올 것"과 "임계값(threshold)의 근거를 제시할 것"이라는 두 가지에 있다.

임계값의 근거는 수용했다.

10%라는 합격 라인을 과거 사이클 타임(cycle time)의 변동 폭으로부터 설정했다는 내용을 추가했다.

"9%라면 실패인가?"라고 묻는다면, "지난 1년간의 자연스러운 변동 폭이 이 정도이므로, 이를 밑도는 개선은 효과로 간주하지 않는 설계입니다"라고 답할 수 있다.

비교에 대해서는 수준을 선택했다.

상한선까지 수용한다면, 팀을 둘로 나누어 조건을 관리하는 비교 실험.

하한선이라면, 툴을 사용하지 않는 팀의 동일 기간 실적을 참고치로 나란히 배치하는 정도까지.

선택한 것은 하한선이다.

실험의 조정과 관리에 공수를 할애하면, '작고 빠르게'라는 이 제안의 도박(bet)을 포기하게 된다.

대신, 이 수치만으로는 효과의 증명까지는 할 수 없다는 한계를 문서에 명기했다.

한계를 적음으로써, 이 검증을 통해 결정해도 좋은 범위도 정해진다.

임계값을 넘었을 때 허용되는 것은 전사 전개 그 자체가 아니라, 실측치를 가지고 다시 상정(re-submit)하는 단계까지다.

전개 판단에는 그때 다시 재료를 보충한다.

구두로 준비한 예상 문답도 작성한 한계에 대한 보충으로서 자연스럽게 결정된다.

"말씀하신 대로 엄격한 비교는 하지 않았습니다. 과거의 변동 폭과 참고치를 통해 보는 설계입니다. 이 정밀도로 부족하다면, 전사 전개 판단 전에 비교 설계를 검토하겠습니다."

지적 2, 코딩이 지연의 원인이라는 근거가 없다.

지연의 주된 원인이 리뷰 대기나 테스트에 있다면, 코딩을 빠르게 해도 전체 시간은 줄어들지 않는다는 지적이며, 이 또한 옳다.

상한선까지 수용한다면, 리드 타임(lead time) 전체의 요인 분석을 먼저 수행해야 한다.

수 주일이 걸리는 다른 업무 때문에, 역시 도박을 포기하게 된다.

선택한 수준은 코딩 시간 비중의 현재 개산을 배경으로 추가하고, 효과가 미치는 범위가 코딩 공정에 한정된다는 점을 명기하여 과도한 약속을 문서에서 지우는 정도까지다.

병목(bottleneck)을 특정하지 않았다는 한계도 마찬가지로 적는다.

요인 분석 자체의 가치를 부정하는 것은 아니다.

이 54만 엔 규모의 검증보다 먼저 해야 할 일인지에 대한 판단이며, 먼저 해야 한다고 생각한다면 그것은 이 제안을 내지 않겠다는 판단이 된다.

남은 2건은 문서와 리뷰 양측 모두에 답이 없었다.

지적 7, 법무와 정보시스템(IT) 부서의 확인이 끝나지 않았는데 상정했다.

정론처럼 보인다.

하지만 확인을 먼저 마친 뒤에 상정해야 하는지, 조건부로 승인을 얻고 확인을 병행해야 하는지는 문서의 내용이 아니라 조직의 결재(稟議, ringi) 관행에 따라 결정된다.

먼저 승인이 나지 않으면 타 부서가 움직여주지 않는 조직이 있는가 하면, 확인 없는 상정을 반려하는 조직도 있다.

AI는 이 조직의 관행을 모른다.

따라서 이 채택 여부는 가져가서 확인해 본 뒤에야 결정할 수 있다.

지적 1, 과제는 고객 안건인데 파일럿(pilot)은 자사 프로덕트로 한정되었다.

이것 역시 같은 유형이다.

수탁 안건 중 AI 툴을 사용할 수 있는 코드가 몇 할이나 되는가 하는, 문서 외부의 사실에 따라 지적의 무게가 달라진다.

9할 정도 사용할 수 있다면 보충 설명으로 끝낼 수 있지만, 1할뿐이라면 제안의 전제 자체가 무너진다.

모르는 채로 진행할 수는 없기에, 계약 현황 파악(棚卸し)을 승인 후 2주간의 준비 기간 작업에 포함했다.

비율이 예상보다 크게 낮다면, 라이선스 비용을 쓰기 전에 중지한다.

자사 프로덕트에서 측정한 결과를 수탁 안건에 그대로 적용할 수 없다는 한계도 「검증의 한계」에 추가했다.

솔직히 고백하자면, 이 2건은 이 데모 안에서는 공중에 뜬 상태로 남게 된다.

가공의 회사이기에 현황 파악 결과도 품의 관행도, 이 이후로는 확인할 방법이 없다.

실례로서는 부족하지만, 그것 자체가 이 공정의 성질이기도 하다.

문서와 리뷰 로그만으로 끝나는 것이 아니라, 실재하는 조직 안에서만 완료되는 부분이 채택 여부에 포함되어 있다.

그리고 품의 관행도 계약의 분포도, 이쪽에서 전달하지 않는 한 AI 측에서는 나오지 않는다.

수렴과 기록의 보관 장소

개정했다면 다시 새로운 세션의 리뷰에 부친다.

새로운 중대 지적이 나오지 않을 때까지 반복하는 것과, 중대 여부의 기준을 스스로 결정하는 것은 이전 기사에서 쓴 바와 같다.

수렴 판정도 마찬가지다.

경영 회의에서 그 자리에서 대답할 수 없는 지적이 없어지면 끝이다.

한 가지, 이전 기사에서 쓰지 않은 운용을 추가한다.

채택 여부의 기록을 리뷰 로그와 함께 파일로 남긴다.

받은 지적은 문서에 흔적이 남지만, 선택하지 않은 수준과 그 이유는 남겨두지 않으면 사라진다.

구분하여 기록할 장소는 두 가지가 있다.

의사결정을 좌우하는 한계는 문서의 「검증의 한계」에 적어 판단하는 사람에게 보이도록 한다.

구두로 준비한 예상 문답은 그 보충에 철저히 집중한다.

질문을 받았을 때 대답하기 위한 히든카드를 쌓아두기 위한 기록이 아니다.

그 위에서, 이 기록은 다음 제안부터 효과를 발휘한다.

대조군 요구도, 비용 총액을 내놓으라는 요구도, 리뷰어 역할을 맡는 사람이 있다면 매번 나올 법한 종류의 것이다.

이유와 함께 기록해 두었다면, 다음에는 처음부터 반영하여 작성할 수 있다.

리뷰 루프는 눈앞의 한 건을 강하게 만들지만, 채택 여부의 기록은 다음 건부터 힘을 발휘한다.

마치며

적대적 리뷰(Adversarial Review)는 프롬프트 한 장으로 시작할 수 있다.

그렇기에 차이가 벌어지는 지점은 지적의 양이 아니라, 채택 여부로 넘어간다.

적어도 이번 9건에 대해서 말하자면, 거절할 용기가 필요한 순간은 없었다.

있었던 것은 어느 수준에서 수락할 것인가에 대한 선택과, 문서 외부에서 가져온 사실이다.

분류를 마쳤을 때, 손에는 개정판과 함께 선택하지 않은 수준의 목록이 남는다.

그것은 자신의 제안이 무엇에 걸려 있는지를 보여주는 목록이기도 하다.

벽치기(Wall-hitting) 단계에서 시책으로 키워 성과물로 완성하기까지의 운용 전체는 별도의 기사에서 다룬다.

부록: 데모의 1차 자료

본문의 데모를 검증할 수 있도록 소재를 가공하지 않고 놓아둔다.

전제가 되는 초안 v1과 1회차 로그는 이전 기사의 부록에 있다.

채택 여부 목록 (9건)

적대적 리뷰 2회차 응답 전문 (Claude · 1회 실행 · 무편집)

리뷰어(공격하는 측)로서 지적합니다. 중요도 순입니다.

【중대 1】 모순 + 허점: 해결하려는 과제와 검증하는 장소가 어긋나 있음

어디가: 「배경과 과제」는 수주 증가에 따른 고객 안건의 리드 타임(Lead Time) 장기화를 문제로 삼고 있는데, 파일럿 대상은 「자사 프로덕트 개발 팀으로 한정」되어 있다. 게다가 절감 공수의 용처는 「수주 완료된 안건의 리드 타임 단축」으로 돌아가 있다.

왜 문제인가: 자사 프로덕트 개발에서 효과가 나타나더라도, 과제의 핵심인 고객 안건에 적용할 수 있다는 보장이 없다. 게다가 본문 스스로가 「고객과의 계약으로 AI 이용에 제약이 있는 코드는 대상 외」라고 인정하고 있으며, 제약의 분포에 따라서는 전사적으로 전개하더라도 정작 중요한 수탁 안건의 대부분에서는 사용할 수 없을 가능성이 있다. 파일럿이 성공해도 과제는 1mm도 해결되지 않는 결말로 이어질 수 있는 설계다.

경영진의 공격: "자사 프로덕트에서 측정한 수치를 계약 제약이 있는 고객 안건에 그대로 적용할 수 있는가? 애초에 수탁 안건 중 AI 이용이 가능한 코드는 몇 할이나 되는가? 그것이 1할이라면 이 파일럿은 무엇을 위해 하는 것인가?"

【중대 2】 허점: 「코딩이 지연의 원인」이라는 전제에 근거가 없음

어디가: 리드 타임 장기화 → 생성형 AI 코딩 지원으로 일직선으로 연결하고 있지만, 리드 타임 장기화의 요인 분석이 전혀 없다.

왜 문제인가: 지연의 주된 원인이 요구사항 조정·리뷰 대기·테스트·릴리스 절차에 있다면, 코딩을 30% 빠르게 하더라도 전체 리드 타임은 거의 단축되지 않는다. 효과 산출식에 「코딩 시간 비율」이 포함되어 있다는 것은, 제안자 스스로 코딩이 공수의 일부일 뿐임을 인정하고 있음에도 그 비율의 현재값(최소한 개략적인 수치라도)조차 제시하지 않았음을 의미한다. 비율이 20%라면 30% 효율화되어도 전체적으로는 3~6% 수준의 이야기이며, 이는 논의의 규모감을 완전히 바꿔 놓는다.

경영진의 지적: "개발 리드 타임의 내역을 제시하라. 코딩이 대기 시간의 주된 원인이라는 데이터가 있는가? 병목 현상(Bottleneck)이 다른 곳에 있다면, 이 도구는 효과가 없는 약이다."

【중대 3】 허점: 지속 판단의 기준이 「효과의 증명」이 되어 있지 않음

어디가: "사이클 타임(Cycle Time) 10% 이상의 개선 시 전사 확대"라고 되어 있으나, 비교 대상(도구를 사용하지 않는 팀)이 없다. 10%·60%라는 임계값의 근거도 제시되지 않았다.

왜 문제인가: PR 사이클 타임은 프로젝트의 성격·업무량의 변동·멤버 구성에 따라 보통 10% 정도는 움직인다. 전후 비교만으로는 「도구 덕분」인지 「우연히 쉬운 프로젝트가 이어졌는지」를 구분할 수 없다. 반대로 효과가 있더라도 까다로운 프로젝트 때문에 수치가 악화되어, 잘못하여 계약을 종료할 가능성도 있다. 54만 엔을 지불하고 「판단 자료가 되지 않는 숫자」를 얻게 된다면, 파일럿의 목적(실측하여 판단함)을 달성할 수 없다.

경영진의 지적: "비이용 팀과의 비교는 하지 않는가? 3개월 후에 10% 개선되었습니다라고 보고했을 때, 그것이 도구의 효과라는 것을 어떻게 증명할 셈인가? 왜 하필 10%인가? 9%라면 실패인가?"

【중대 4】 허점: 효과 산출식이 제시한 KPI로 채워지지 않음

어디가: "비율과 효율화율은 파일럿을 통해 실측한다"라고 되어 있으나, KPI는 사이클 타임·이용률·설문조사 3가지뿐이다. 「코딩 시간 비율」과 「효율화율」을 어떻게 측정할 것인지, 그 수단이 어디에도 적혀 있지 않다.

왜 문제인가: 3개월 후, 식에 넣을 숫자가 설문조사의 자기 보고(「체감상 30% 빨라졌다」)밖에 없는 상황이 눈에 선하다. 자기 보고식 효율화율은 과다하게 측정되는 경향이 있으며, 이를 인건비에 대입하여 「절감 공수」로 간주하고 증원 억제의 근거로 삼는 것은 위험하다.

경영진의 지적: "실측한다고 했지만, 측정 방법은 어디에 적혀 있는가? 설문조사로 『빨라진 느낌이 든다』를 수집해서 곱셈을 할 생각이라면, 그것은 실측이라고 부르지 않는다."

【중대 5】 누락: 품질 리스크에 대해 한마디도 언급하지 않음

어디가: KPI가 속도(사이클 타임)와 이용 상황뿐이며, 품질 지표(버그율, 장애 수, 리버트(Revert)율, 리뷰 지적 수)가 제로(0)이다. AI 생성 코드 특유의 리스크(취약점 혼입, OSS 라이선스 유래 코드 혼입, 리뷰 부하 증가)에 대해서도 언급이 없다.

왜 문제인가: 빨라졌지만 결함이 늘어났다면, 고객 만족이라는 당초의 목적에 대해 역효과를 낳는다. 속도만을 측정하는 설계는 「빨라지기만 하면 합격」이라는 잘못된 인센티브를 30명에게 부여한다. 라이선스 혼입은 고객 납품물일 경우 계약 문제로 직결된다.

경영진의 지적: "속도만 측정할 것인가? 품질이 떨어지지 않았다는 것은 어떻게 담보할 것인가? AI가 작성한 코드의 라이선스 문제가 납품 후에 발견된다면, 54만 엔 정도의 손해로 끝나지 않을 것이다."

【중대 6】 허점: 「3명 증원 억제」로의 비약과 전사 확대 시 총비용의 결여

어디가: 파일럿 결과 → 「다음 분기 증원 계획(3명)의 억제」라고 기술하고 있으나, 그 사이의 계산 과정이 전혀 없다. 전사 확대 시의 비용(대상 인원 × 월액 × 연간)도 제시되지 않았다.

왜 문제인가: 3명 억제는 인건비로 연간 2,000~3,000만 엔급의 경영 판단이며, 30명·3개월의 실험에서 도출할 수 있는 결론이 아니다. 또한, 승인을 요청하는 금액은 54만 엔일지라도, 이 제안의 진정한 의사결정은 「전사로 확대할 것인가 여부」이다. 그때의 연간 비용과 ROI(투자 대비 수익) 전망을 제시하지 않고 입구만 통과시키는 것은, 판단의 유보가 아니라 판단 자료의 은폐로 보인다.

경영진의 지적: "전사 확대 시 연간 얼마인가? 그것이 증원 3명분과 맞먹는다는 추산치를, 대략적이라도 좋으니 지금 내놓아라. 내놓지 못한다면 3개월 후에도 내놓지 못할 것이다."

【중간 정도 7】 모순: 승인 순서가 거꾸로임

어디가: 「정보시스템부·법무부의 사전 확인을 승인 조건으로 한다」 = 즉, 확인이 아직 완료되지 않은 상태로 경영 회의에 상정하고 있다. 반면 스케줄은 「승인 후 2주 이내에 대상 팀 선정 및 가이드라인 정비, 1개월 차에 이용 개시」로 되어 있다.

왜 문제인가: 정보시스템·법무의 확인, 벤더의 보안 심사, 고객 계약 검토가 2주 안에 끝난다는 보장이 없으며, 만약 거부(NG)가 나온다면 승인 자체가 무의미해진다. 「사전 확인」이라고 말하면서 승인 이후의 단계로 배치한 것은 용어의 모순이다. 보통은 법무·정보시스템의 견해를 첨부하여 상정한다.

경영진의 지적: "법무에서 안 된다고 하면 이 승인은 어떻게 되는 건가. 먼저 확인을 받은 다음에 가져와라. 정보시스템(情シス) 심사가 길어지면 스케줄도 전부 뒤로 밀릴 것 아닌가."

【중등도 8】 구멍: 총비용이 54만 엔으로 보이는 작성 방식

어디가: 비용란에 라이선스비만 금액으로 표시하고, 연수(30명 × 2시간)와 관리자 공수(0.3인월)는 "공수로 계상"이라고만 적고 금액화하지 않았다.

왜 문제인가: 대략적으로 추산해도 연수 60시간 + 관리 0.3인월로 30~60만 엔 상당이다. 실질 비용은 라이선스비와 거의 맞먹거나 그 이상이며, 총액은 100만 엔을 초과한다. 여기에 정보시스템·법무의 확인 공수, 가이드라인 정비 공수도 추가된다. "54만 엔의 작은 규모입니다"라는 식의 보여주기는, 효과 검증을 내세우는 제안으로서 자신의 비용 계산이 안일하다는 것을 의미한다.

경영진의 지적: "효과는 정밀하게 측정하겠다고 하면서, 자신의 비용은 라이선스비만 계산하는 건가. 총액이 얼마 드는지 다시 뽑아와."

【경미 9】 누락: 판단이 "전사 전개 vs 계약 종료"의 이지선다이며, 조건의 분리가 없음

어디가: 지속 판단이 2가지 조건의 AND 합격 여부뿐이다. 한쪽 조건만 달성했을 경우(이용률은 높지만 사이클 타임 개선은 8%인 경우 등)의 취급, 규모를 변경하여 지속하는 중간안, 이용률이 낮은 원인(툴이 문제인지, 연수·운영이 문제인지)의 분리에 대해 언급하지 않았다.

왜 문제인가: 운영의 실패로 인해 툴을 불합격 처리하거나(또는 그 반대) 잘못된 판단을 내리기 쉽다. 또한 30명의 선정 방법도 적혀 있지 않아, 지원자나 정예 인원을 모으면 효과가 과대하게 나타날 수 있다(전사 전개 시 재현되지 않음).

경영진의 지적: "이용률 59%·개선 9.8%라면 그만두는 건가. 30명은 누가 어떻게 뽑는 거지? 에이스급을 모은 결과를 전사에 외삽(Extrapolation)해도 곤란하다."

과잉에 대하여

과잉 관점에서의 중대한 지적은 없습니다. 54만 엔 + 3개월이라는 규모 자체는 타당합니다. 오히려 문제는 반대입니다.

이 검증 설계는 54만 엔을 지불하더라도 전개 판단에 충분한 재료를 얻을 수 없다(중대 1~4)는 점에 집중되어 있습니다.

총평: 금액이 작아 통과하기 쉬워 보이지만, "파일럿의 목적 = 당사에서의 효과 실증"에 대하여, 실증 설계(대상의 대표성·측정 방법·비교 대상·품질 측면)가 무너져 있습니다. 이대로 승인하면 3개월 후에 "체감상 호평이었습니다" 이상의 재료가 나오지 않아, 흐지부지 전사 전개를 하거나 근거 없는 철수를 하는 상황 중 하나가 될 가능성이 높습니다.

개정판 v3 전문 (2차 채택 여부 판단을 반영한 상태)

생성 AI 코딩 지원 툴 파일럿 도입 제안 (제2개정판)

배경 및 과제

개발 부문에서는 최근 2년간 채용이 계획을 밑도는 한편 수주는 늘어나고 있으며, 개발 리드 타임(Lead Time)의 장기화가 고객 만족도 저하와 수주 기회 손실로 이어지기 시작했다. 생산성 향상의 선택지로서 생성 AI 코딩 지원 툴의 도입을 검토하고자 한다.

사내 타임 트래킹(Time Tracking) 실적에 따르면, 개발 공수 중 코딩이 차지하는 비율은 대체로 3할이다. 본 툴의 효과는 이 코딩 공정에 국한되며, 리드 타임 전체의 단축을 보장하는 것은 아니다 ("검증의 한계" 참조).

벤더 각사는 "코딩 효율 30% 향상" 등을 공표하고 있으나, 당사에서의 효과는 미실증 상태이므로 소규모 파일럿을 통해 실측한 후 전개 여부를 판단한다.

요청 사항

파일럿 도입(30명·3개월·총액 약 110만 엔)의 승인.

본 파일럿의 결과로 허용되는 것은 전사 전개를 위한 재상정까지이며, 전개 자체에 대한 판단은 실측치를 첨부하여 다시 논의한다.

효과 검증 설계

• 효과 추산식: 절감 공수 = 대상자의 인건비 × 코딩 시간 비중 × 효율화율
• 측정 방법: 효율화율은 툴의 이용 로그(제안 수락률·생성 코드량)와 PR 통계로부터 추정한다. 추정치라는 점을 보고서에 명기하며, 개발자 설문(자기 신고)은 보조 지표로만 활용한다.
• 속도 KPI: PR 사이클 타임(Cycle Time), 주간 활성 이용률
• 품질 KPI: 버그율, 리버트(Revert)율, 리뷰 지적 수, 리뷰 시간의 추이
• 지속 판단 (3개월 후): 활성 이용률 60% 이상, 그리고 사이클 타임 10% 이상의 개선 시 전사 전개를 재상정한다. 임계값의 근거: 10%는 지난 1년간의 사이클 타임의 자연 변동 폭을 상회하는 수준으로 설정
• 중간 결과 (한쪽 조건만 달성한 경우 등)의 경우: 원인 분리를 첨부하여, 조건을 변경한 3개월 연장을 선택지에 포함한다. 기준 미달 및 개선 전망이 없는 경우에는 계약을 종료한다.
• 대상 30명의 선정: 지원자나 에이스급으로의 편중을 피하고, 통상적인 안건을 담당하는 팀 단위로 선정한다 (전사 전개 시의 재현성을 위해).
• 절감 공수의 용도: 수주 완료된 안건의 리드 타임 단축에 투입하여, 내년도 증원 계획(3명)의 판단 재료로 삼는다.

검증의 한계

• 대조 실험은 실시하지 않는다. 툴을 이용하지 않는 팀의 동일 기간 실적을 참고치로서 병기하지만, 안건 조건을 동일하게 맞춘 비교가 아니므로 효과의 증명이 아닌 판단 재료에 머무른다.
• 리드 타임 (Lead Time) 장기화의 요인 분석은 본 제안의 범위 외이며, 코딩이 병목 (Bottleneck) 구간이라는 점을 특정하지는 않았다.
• 파일럿 (Pilot)은 자사 프로덕트 개발 팀에서 수행하므로, 그 결과를 수탁 안건에 그대로 외삽 (Extrapolation)할 수 없다.

보안 및 계약

• 본 툴은 소스 코드를 외부 서비스로 전송하므로, 정보시스템부 및 법무부의 확인을 이용 시작의 전제로 한다.
• 고객과의 계약에서 AI 이용에 제약이 있는 코드는 대상에서 제외한다. 준비 기간 중에 수탁 안건의 계약을 전수 조사하여, AI 이용이 가능한 코드의 비율을 파악한다. 비율이 예상보다 크게 낮을 경우, 라이선스 비용 지출 전에 중단을 판단한다.
• 입력 코드를 모델 학습에 사용하지 않도록 하는 설정 (Opt-out)을 필수 사항으로 한다.
• 생성된 코드의 라이선스 혼입 방지 대책으로서, 기존 OSS (Open Source Software)와의 일치 검출 (License Scan)을 파일럿 운용에 포함한다.

툴 선정

후보 3개 툴을 데이터 취급, 단가, 에디터 대응의 3가지 관점에서 비교하여, 학습 옵트아웃 (Opt-out) 및 감사 로그 (Audit Log)에 대응하는 후보 A를 제1후보로 한다 (비교표는 별첨).

비용 (파일럿 총액 약 110만 엔)

• 라이선스 비용: 월 6,000엔 × 30명 × 3개월 = 54만 엔
• 교육: 온보딩 (Onboarding) 2시간 × 30명 ≒ 약 30만 엔 상당의 공수
• 운용: 관리자 공수 0.1인월 × 3개월 ≒ 약 24만 엔 상당의 공수
  참고: 전사 전개 시 (150명)의 첫해 개산은 약 1,400만 엔 (라이선스 비용 1,080만 엔 + 교육·운용 예상액 약 370만 엔). 정밀한 비용 대비 효과는 파일럿 실측치를 사용하여 재상정 시 제시한다.

스케줄