AI 도입 전에 농가와 병원에서 배운 것

AI를 도입하면 조직이 원래 가지고 있던 강점과 약점이 그대로 커집니다. 기반이 오래된 팀일수록, 빨라지기는 하지만 그만큼 불안정해집니다.

어려운 점은 개발의 기반이 자신의 팀에 갖춰져 있더라도, 외부로 어떻게 확장할 것인가입니다.

조사해보니 농업이나 의료 분야가 수십 년 전부터 같은 문제에 접근하며 성공한 방법과 효과를 보지 못한 형태를 모두 남기고 있다는 것을 발견했습니다.

이 글을 통해 가져가셨으면 하는 것은 다음 세 가지입니다.

• 상사에게 말할 수 있는, AI 이전에 필요한 기반의 이유
• 타 분야에서 찾은, 강요하지 않고 뿌리내리게 하는 원칙과 함정
• 오늘부터 사용할 수 있는 점검 관점, 체크리스트, 측정 방법

급한 분들은 5절의 원칙과 8절의 체크리스트만이라도 참고해 주세요.

이 글은 시스템 개발팀에서 매니저를 맡고 있는 저(엔지니어 경력 15년 이상)가 부서 전체의 역량 향상을 맡게 되었을 때 조사한 내용을 기록한 것입니다.

AI를 도입하면 팀에 이미 존재하는 강점과 약점이 커집니다. 이것이 Google Cloud의 DORA팀이 2025년에 정리한 조사 보고서의 결론입니다 (Google Cloud 공식 블로그).

조사는 전 세계 약 5,000명의 기술자에게 진행되었습니다.

보고서는 기반이 없으면 AI로 창출된 생산성은 일부에 머무르기 쉽고, 후속 공정의 혼란으로 인해 사라지기 쉽다고도 언급하고 있습니다 (DORA 2025 리포트).

빨라지기는 합니다. 다만, 자동 테스트나 버전 관리, 빠른 피드백 같은 제동 장치가 없으면 변경이 늘어난 만큼 불안정해집니다 (Google Cloud Blog).

일본의 수치도 있습니다. AI를 도입한 기업 중 효과가 기대했던 대로였거나 그 이상이었던 곳은 31.8%였습니다 (정보처리진흥기구, 1,799개사).

가장 많았던 것은 '일정 부분 효과는 있었다'의 50.6%입니다. 활용 분야도 문서 요약이나 작성 등 업무 효율화가 중심이었습니다 (동).

같은 조사에서 부족하다고 지적된 것은 현장의 지식과 기초적인 AI 지식을 갖추고, 자사 내 AI 도입을 추진할 수 있는 인재였습니다 (동). 현장과 AI를 연결하는 다리 역할을 하는 사람입니다.

같은 시기에 이상한 유행도 생겨났습니다. AI의 토큰 소비량을 사내에서 순위로 매기고 많이 사용한 사람을 칭찬하는 활동입니다. 영어권에서는 'tokenmaxxing'이라고 불립니다.

DORA는 이를 입력량만 세고 있어 쉽게 속일 수 있는 지표라며 비판했습니다. 개인 점수는 유해하다고까지 언급하고 있습니다 (DORA).

그렇다면 AI의 효과를 내기 위해서는 무엇을 먼저 해야 할까요? 단서는 개발과는 다른 세계에 있었습니다.

상사로부터 부서 전체의 개발 역량 향상을 맡게 되었습니다. 부서를 둘러보니, 개발 방식도 도구 사용 숙련도도 팀마다 제각각이었습니다.

제가 요청받은 것은 저희 팀에서 AI 에이전트 도입이 빠르게 진행되고 있었기 때문이라고 생각합니다. 멤버들의 높은 감도 덕분에 많은 도움을 받았습니다.

제가 팀을 인계받은 건 올해 4월이었고, 전임 매니저는 실무에 치여서 팀을 볼 시간이 거의 없었습니다. '매니지먼트'가 뒷전이 되고 있는 상태가 저의 첫 번째 고민이었습니다.

개인의 문제라기보다는, 매니저에게도 실무가 쌓이고, 팀을 보는 시간이 시스템적으로 확보되어 있지 않았기 때문이라고 생각했습니다. 그래서 저는 먼저 그 시간을 확보하는 것부터 시작했습니다.

팀에서 진행한 일들은 소박합니다. 월 2회의 1on1에서는 멤버들에게 이야기하고 싶은 것을 말하게 했고, 매일 아침 회의에서는 '혹시 무슨 일 있어?'라고 물었습니다.

모든 프로젝트에 얼굴을 비추며 어디가 막히는지도 살폈습니다. 경험이 없는 업무는 먼저 할 수 있는 사람의 보조부터 시작하여, 맡기는 범위를 조금씩 넓혀갔습니다.

현장에서 추진한 AI 에이전트는 팀 목표에 포함시키고, 업무 시간으로 확보했습니다.

처음에는 AI를 관망하던 멤버들도, 기술 이벤트에 참여하며 변화를 몸소 느끼기 시작하자 자신의 프로젝트에 적용하고 싶다고 제안하기 시작했습니다.

팀의 기반은 갖춰졌습니다. 하지만 팀에서 했던 방식을 부서 전체로 확장하려니 막혔습니다.

팀에서 잘 된 것은, 어려움을 겪는 것을 1on1이나 아침 회의에서 직접 들을 수 있었고, 시간과 업무 배분을 스스로 결정할 수 있었다는 점입니다.

다른 팀들에게 저는 그 어느 것도 가지고 있지 않았습니다.

다음으로 생각한 것은 스터디 모임이었습니다. 하지만 '스터디 모임으로 매일의 방식이 바뀔까?'라는 의문을 품고 조사하던 중, '엔지니어링 이네이블먼트(Engineering Enablement)'라는 단어가 눈에 띄었습니다.

'이네이블먼트(Enablement)'는 '할 수 있게 하다'라는 의미입니다. 엔지니어가 힘을 쓸 수 있도록 조직 차원에서 지원하는 활동을 말합니다.

이 말을 단서로, 『엔지니어 팀의 생산성 높이는 법』(기술평론사, 2024년)의 제6장에 도달했습니다.

연수나 스터디는 누구에게나 쓸 수 있는 부분이기에, 자신의 현장 상황에 맞춰 재해석하는 과정이 남습니다. OJT는 현장에서 바로 사용할 수 있지만, 가르치는 사람에 따라 질이 흔들립니다(기술평론사).

널리 전달하는 것과 현장에서 즉시 사용할 수 있는 것을 모두 충족시키기 위해, 현장에 맞는 지식이나 노하우를 조직 차원에서 체계적으로 제공합니다. 이것이 이네이블먼트(enablement)라는 정리였습니다.

권한도 거리도 없는 상대에게 새로운 방식을 어떻게 뿌리내리게 할 것인가. 의료 분야에는 이 질문을 전문으로 다루는 '구현 과학(Implementation Science)'이라는 분야가 있습니다.

구현 과학에서는 올바른 방식만으로는 정착하기에 부족하다고 봅니다. 정착을 좌우하는 것은 근거의 질, 현장의 상황, 진행 방식 지원의 조합입니다(PARIHS).

방식 업데이트가 멈추는 것이 누군가가 게을러서가 아닙니다. 바쁜 현장에는 방식을 업데이트할 시스템이나 시간도 없기 때문입니다.

의료 분야에서도 연구 논문이 나와서 현장에 뿌리내리기까지 평균 17년이 걸린다는 보고가 자주 인용됩니다(의학계신문). 멈추는 것이 오히려 정상적인 일입니다.

멈춰 있는 현장에 AI만 도입하면, 제1절에서 본 것처럼 불안정해집니다. 그렇다면 AI의 효과를 내기 위한 조건은 무엇일까요? DORA는 이를 7가지 능력으로 정리했습니다. 주요 네 가지는 다음과 같습니다.

• 명확하고 모두에게 공지된 AI 정책
• 제대로 된 버전 관리
• 작은 단위에서의 작업
• 질 높은 사내 플랫폼

이 모든 것은 조직의 기반에 관한 이야기이며, 도구 이름은 하나도 언급되지 않습니다(Google Cloud 공식 블로그).

예를 들어 DORA는 버전 관리를 AI 시대의 안전망이라고 부릅니다.

자주 커밋할수록 개인에게, 주저 없이 되돌릴 수 있을 만큼 팀에, AI 효과가 크게 나타난다는 보고입니다(DORA).

제가 버전 관리의 감사함을 가장 느끼는 때는 AI 에이전트를 여러 개 나란히 개발할 때입니다. 에이전트별로 작업 공간을 나누고, 변경 사항을 확인한 후, 가져올지 버릴지 결정합니다.

이러한 병렬 개발은 버전 관리가 있어야만 가능합니다.

Claude Code의 공식 문서도 병렬 세션은 git의 작업 트리(worktree)로 분리하라고 안내하고 있습니다(Claude Code Docs).

# 에이전트별로 작업 공간을 나누기
git worktree add ../wt-agent-a -b agent-a
git worktree add ../wt-agent-b -b agent-b
...

기술로 커지는 것은 현재 가진 능력만으로 충분하다는 생각은, 개발도상국 지원 현장에서도 나왔습니다. 마이크로소프트 연구소에서 인도 IT 지원에 참여했던 연구자, 토지야마 켄타로 씨입니다.

토지야마 씨는 그 경험을 바탕으로 저서 『기술은 빈곤을 구하지 못한다』에서 기술로 커지는 것은 사람과 조직이 본래 가지고 있는 능력만이라고 썼습니다(미스즈 서방).

더 오래된 경고도 있습니다. 1983년 논문 '자동화의 아이러니'는 자동화할수록 사람에게 남는 일은 어렵고, 그 기술은 사용하지 않으면 퇴보한다고 지적했습니다.

2024년 연구는 생성 AI에서도 같은 일이 일어나고 있다고 보고합니다(Simkute 외). AI에 맡길수록 AI 출력을 확인하는 사람의 힘이 필요합니다.

새로운 방식을 아는 사람과, 바쁘게 자신들의 방식으로 돌아가는 현장. 그 사이에 서서, 방식을 현장에 뿌리내리게 하는 일이 있습니다.

조사해 보면, 이 일은 분야별로 다른 이름으로 수십 년 전부터 이어져 왔습니다.

가장 오래된 것은 농업입니다. 1948년에 시작된 협동농업 보급 사업에서는 도도부현의 보급 지도원이 농가에 직접 찾아가 연구 기관에서 탄생한 기술을 지역에 맞는 형태로 확산시킵니다(농림수산성).

농림수산성은 이 사업을 연구 기관과 농민을 잇는 양방향 다리 역할로 규정하고 있습니다(농림수산성). 현재도 전국에 약 7,200명의 보급 지도원 등이 있습니다(동).

병원 시스템은 개발 조직에 거의 그대로 중첩됩니다. 병원장 밑에 있는 감염 대책팀이 규칙을 정하고, 각 병동의 링크 나스(link nurse)가 자신의 병동에서 감염 대책을 확산시킵니다(일본의사협회지).

링크 나스는 현장의 문제를 팀에 전달하는 역할도 맡습니다. 영국에서 확립된 시스템으로, 현재는 욕창(상처) 대책이나 영양 지원에도 확장되었습니다(간호 전문과).

영업 분야도 같은 문제에 먼저 부딪혔습니다. 미국 조사 회사 Forrester가 2009년에 '세일즈 이네이블먼트(Sales Enablement)'라는 지속적인 노력으로 정의했습니다(Forrester).

IT 기업은 관리비(販管費)의 평균 19%를 영업 지원에 사용하고 있었습니다. 하지만 그 비용은 사내 곳곳의 예산에 분산되어 있었습니다 (Forrester).

제품 부문, 마케팅, 인사 등 각 부서가 선의로 영업을 돕고자 했던 결과였습니다. 15년 이상 전의 수치이지만, 개발 조직에서 각 팀이 선의로 개별 환경을 구축하는 것과 같은 구도입니다.

저는 '이네이블먼트(Enablement)'라는 용어를 선행했던 영업에서 엔지니어링 분야로 가져왔다는 출처를 찾을 수 없었습니다. 같은 문제에 대해 각기 다른 경로를 통해 도달했다고 생각합니다.

각 분야의 지식을 쌓아 9가지 원칙으로 정리했습니다. 이들은 모두 어느 분야에서 효과가 입증되었거나 실패로부터 배운 것입니다.

9가지는 관계 맺는 방식(13), 진행하는 방식(46), 체제(7~9)로 나뉩니다. 여기서 체제가 외부에서 지지하고, 그 내부에서 진행하는 방식과 관계 맺는 방식이 성립되는 관계입니다.

무엇을 갖추어야 하는지는 제8절의 체크리스트에 담겨 있고, 어떻게 뿌리내리게 할 것인지는 이 9가지 원칙에 정리되어 있습니다.

멤버를 바꾼 것도 제 설명보다는 기술 이벤트에서의 경험이었습니다. 팀에서 무의식적으로 하던 일을 부서 전체에서는 의도적으로 해야 합니다.

가장 고민했던 것은 원칙 7이었습니다. 강제하고 싶지는 않습니다. 하지만 사고를 막기 위한 새로운 방식은 효과가 눈에 잘 보이지 않고, 확산되는 것이 느리다는 것을 알고 있습니다 (Rogers).

병원 감염 대책팀은 병원장으로부터 권한을 위임받아 예방 규칙이 지켜지고 있는지 확인합니다 (일본의사협회지). 그 형태를 따라 규칙으로 정하는 것은 '수비'의 3가지로 한정했습니다.

그 3가지는 보안, AI 활용 규칙, 백업입니다. 이들은 모두 사고가 발생하면 되돌릴 수 없습니다. 빌드나 테스트 방식은 팀이 선택합니다.

원칙 3에서도 도움을 받았습니다. 사람은 '못하고 있다'는 말을 듣는 것보다, 바로 옆에 잘하는 동료가 있다는 것을 아는 편이 움직입니다.

베트남 아동 영양 개선 (1990년~)에서는 같은 가난함 속에서도 건강하게 자란 아이의 가정을 찾아내고, 그 방식을 주민들끼리 확산시켰습니다 (국제보건의료).

그래서 기획서에는 '못하고 있는 곳을 고친다'라고 쓰지 않고, '개발의 토대를 함께 업데이트한다'라고 썼습니다.

권한 없이 새로운 방식을 확산하는 방법은 소프트웨어 개발 분야에서도 패턴집이 되어 있습니다.

『Fearless Change』는 작은 성공을 축하하고, 조직 내에서 인맥이 넓은 사람의 협력을 얻는 등, 48가지 상황별 대응책을 모아놓은 책입니다 (편집자 목록).

원칙 뒤에는 효과가 없었던 형태도 있습니다. 이번 조사에서 특히 중요하게 본 것은 다음 3가지입니다.

농업에는 농민들이 밭에서 함께 배우는 '농민학교'라는 방법이 있으며, 개발도상국에서 널리 행해져 왔습니다. 참여한 농가는 지식이나 수확량, 소득이 증가합니다.

하지만 연구를 정리한 체계적 문헌고찰에서는 참여하지 않은 옆집 농가로 지식이 확산되지 않았습니다 (Waddington 외).

대규모로 진행했을 때는 효과도 나타나지 않았습니다 (같은 출처). 손으로 만져가며 배우는 방식은 듣기만 하는 것보다 전수되기 어렵다고 분석되었습니다 (평가기관 3ie 요약).

개발팀에서도 시범 팀의 성과는 옆 팀에 자연스럽게 확산되지 않는다고 생각하는 것이 안전합니다.

주도자가 있는 조직에서는 새로운 방식이 사용되는 비율이 증가하는 경향을 보였습니다. 조사된 7건의 연구 중 5건입니다. 다만, 어느 경우든 성과에 대한 효과는 명확하지 않습니다 (Santos 외).

링크나스 제도 역시 효과를 보여주는 견고한 증거가 부족하다고 여겨집니다. 효과를 내기 위한 조건으로 언급되는 것은 역할의 명확화, 구현 교육, 병동과 병원 상부로부터의 지원입니다 (Dekker 외).

2026년 5월에는 '주도자의 역설'을 논한 연구도 나왔습니다.

주도자를 유능하게 만드는 특징 때문에, 그 사람이 빠졌을 때 취약성도 생길 수 있다는 지적입니다 (구현과학 학술지).

연구자들은 추진력에 의존하는 방식에서 시스템에 의존하는 방식으로 전환할 것을 권장합니다(저자의 해설). 여기서 말하는 '추진력'은 조직의 힘이 자라날 때까지 한시적으로 존재하는 존재로 설정해야 한다는 생각입니다.

1980년대 미국에서는 QC 서클(QC Circle)이 급속도로 확산되었습니다. 이는 현장의 자발적인 인원들이 본래의 조직과는 별개로 모여 품질 개선에 대해 논의하는 작은 그룹입니다.

하버드 비즈니스 리뷰(HBR)의 논문들은 그중 상당수가 쇠퇴했다고 기록하고 있습니다.

그 이유는 중간 관리직의 저항, 예산 삭감, 그리고 참여자들의 열정이 식었기 때문이었습니다(HBR).

일본에서도 소규모 활동을 하는 사업장은 1984년의 60.2%에서 2004년의 30.9%로 줄어들었습니다. QC 서클 본부는 2002년에 그 활동을 '업무 일체'로 재정립했습니다(요코하마 국립대학교 논문).

스터디 그룹이나 자발적인 활동 역시, 본업 외에 분리되어 있으면 같은 길을 걷기 쉽습니다. 따라서 활동은 각 팀의 정례 업무나 목표 안에 통합해야 합니다.

다른 분야에서 먼저 빠졌던 함정들을 포함하여 표로 정리해 두겠습니다.

16가지 함정표 열기

만든 자료는 대부분 사용되지 않습니다. B2B 마케팅에서는 제작된 콘텐츠의 60~70%가 사용되지 못하고 끝난다고 합니다(Forrester).

주요 원인은 사용하는 사람을 모른 채 만드는 것이었습니다(같은 출처).

도구부터 시작하면, 사용되지 않습니다. 개발자 포털인 Backstage는 Spotify 사내에서는 거의 모든 사람이 사용합니다.

하지만 다른 회사에서의 평균 이용률은 약 10%에 불과하다고, Spotify 담당자 자신이 말했습니다(The New Stack).

그 이유는 개발자의 어려움을 이해하지 못한 채 도입하고, 시험 도입 단계를 넘지 못하기 때문이라고 합니다(같은 출처).

지원하는 측은 만능 해결사(何でも屋)가 되기 쉽습니다. 개발자 경험 전담 팀에는 주인이 없는 문제들이 연달아 쏟아져 들어온다고 지적됩니다(LeadDev).

BCG Digital Ventures의 지원팀은 '대신 작업해 달라'는 요청을 거절하기 위해, 팀의 작업 목록(백로그)을 공개하고 효과를 데이터로 계속 보여주었습니다(InfoQ).

가장 먼저 손대야 할 것은 교육보다 실제 현황 파악입니다. 처음 눈에 보이는 문제는 단지 예시일 뿐이며, 더 큰 문제가 숨어 있는 경우가 많습니다.

이 명칭은 '함께 재고 조사하기'로 정했습니다. 전문가가 진단하고 처방하는 방식이 효과를 보는 것은 상대방이 그 진단을 수용하고 스스로 실행할 때뿐입니다.

조직 심리학자 샤인(Schein)이 저서 『사람을 돕는다는 것은 무엇인가』에서 역설한 내용입니다(영지 출판사).

재고 조사에서는 다음 8가지를 살펴봅니다.

• 산출물: 코드나 데이터의 버전 관리, 백업
• 업무: 태스크·진행 상황·버그 관리
• 지식: 사양이나 노하우의 보관 장소, 개인 의존성(属人化)
• 제작 방식: 빌드나 환경 구축 수작업, 테스트, 변경 후 동작 확인까지 걸리는 시간
• 방어: 비밀번호나 열쇠 취급, 라이선스
• AI: 사용법, 규칙 유무, 외부 서비스에 입력된 정보
• 숨겨진 비용: 각 팀이 독자적으로 수행하는 환경 정비나 도구 제작 공수
• 잘하고 있는 사람: 같은 제약 조건 속에서 돌아가고 있는 사람과 그 방식(원칙 3)

조사 방법은 3단계로 구성했습니다. 먼저 가볍게 답할 수 있는 설문으로, 어려움을 느끼는 점이나 두려운 점, 그리고 잘 되고 있는 방식을 듣습니다. 무엇을 사용하고 있는지는 그다음 단계입니다.

다음으로 각 팀의 리더에게 30분간 인터뷰를 진행합니다. 여유가 되면 한 팀의 작업을 반나절 동안 참관합니다. 본인에게는 너무 당연해서 말로 표현되지 않는 것들은 직접 보지 않으면 발견할 수 없습니다.

우선순위는 피해 규모 × 발생 가능성 × 인지하기 어려움으로 매깁니다. 제조 업계의 FMEA(고장 분석)에서 사용하는 사고방식입니다(FMEA 해설).

백업이 없는 상태처럼, 문제가 발생할 때까지 아무도 알아차리지 못하는 것일수록 상위에 놓입니다. 돌이킬 수 없는 피해가 발생하는 것은 점수와 관계없이 먼저 처리합니다.

오래된 방식이라도 아무도 어려움을 느끼지 않고 사고 위험도 낮다면, 억지로 바꾸지는 않습니다.

제가 생각한 첫 반년의 순서는 다음과 같습니다.

시기 | 할 일 | 상에 보여줄 성과
|---|---|
| 1~2개월 차 | 상사와 방침 및 공수 범위를 정한다. AI 활용 규칙 등 '방어적' 조치는 전 팀에서 먼저 시작한다. 재고 조사(棚卸し)를 진행한다 | 전 팀의 재고 조사 완료, 우선순위가 지정된 과제 목록
| ... |
공수의 기준은 추진 측의 정례 회의가 월 1회 30분, 각 팀의 참여가 월 2시간 정도입니다. 작게 시작하는 것이 승인을 받기 쉽습니다.

스터디 모임 참가 인원이나 자료 열람 수는 세기 쉬워서 자꾸 목표로 삼고 싶어집니다. 하지만 행동을 대신할 수는 없습니다.

DORA는 코드의 라인 수나 커밋 수로 생산성을 측정하려 했던 역사를 되돌아보며, 토큰 소비량 순위도 같은 함정이라고 지적합니다(DORA).

3절에서 언급했듯이, 꾸준한 커밋은 좋은 습관입니다. 하지만 그 수를 성과 지표로 삼는 순간, 수 자체를 늘리는 것이 목적이 되어 의미를 잃습니다.

지표는 3단계로 나눕니다. 교육 평가의 고전인 커크패트릭의 4단계 평가(반응-학습-행동-결과)와 대응시키면 상에게 설명하기 쉽습니다(일본 인사부).

'반응'은 활동량에, '행동'은 정착도에, '결과'는 효과에 해당합니다. '학습' 단계는 시범 팀과의 동행을 통해 확인합니다.

| 단계 | 목적 | 지표 예시 | 빈도 |
|---|---|---|
| 활동량 | 멈추지 않고 진행되고 있음을 보여줌 | 재고 조사를 마친 팀 비율, 설문조사 응답률, 정례 회의 개최 횟수 | 매월 |
| ... |
새로 온 사람이 첫 변경 사항을 적용하기까지의 날짜는 싸게 측정할 수 있고 개선점도 보기 쉬운 지표입니다.

Spotify는 신입이 10번째 풀 리퀘스트(PR)를 병합하는 날짜를 가장 중요한 지표로 삼아, 60일에서 20일 미만까지 단축했습니다(Spotify).

마지막으로 보는 지표는 추진 역할 없이 돌아갈 수 있는 팀의 수입니다. 국제 협력에서도 능력은 외부에서 옮기는 것이 아니라 상대방이 스스로 계속 키워나가는 것으로 정의됩니다(JICA).

6절의 '추진 역할의 역설'을 받아서, 중요한 시점마다 하나의 질문을 추가합니다. 지금의 추진 역할이 내일 사라져도 이 팀은 돌아갈 수 있을까?

연구자들도 추진 역할이 빠진 상황을 가정하여 확인하는 것을 권장합니다(저자의 해설).

숫자는 개인 평가에 사용하지 않고, 팀 단위로만 다룹니다. 개인 평가에 쓰기 시작하면 사람들은 숫자를 좋게 보이도록 움직이기 때문입니다.

복사해서 자신의 팀에서 시도해 보세요.

성과물과 지식

• 코드는 모두 버전 관리 하에 있다
• 이미지나 데이터 등, 코드 외의 성과물도 이력을 추적할 수 있다
• 백업이 있고, 실제로 되돌릴 수 있음을 한 번 시도했다
• 태스크와 버그를 팀 전원이 볼 수 있는 장소에서 관리하고 있다
• 사양과 '왜 그렇게 결정했는지'가 특정인의 머릿속 밖에 존재한다

만드는 방법

• 새로 온 사람이 절차서만으로 개발 환경을 만들 수 있다
• 누구나 같은 절차로 빌드할 수 있다
• 빌드가 자동화되어 있다
• 자동 테스트가 조금이라도 있다
• 변경 후 동작을 확인하는 시간을 알고 있다

방어적 조치와 AI

• 비밀번호나 키를 코드나 채팅에 직접 적지 않는다
• 사용 중인 라이브러리나 소재의 라이선스를 확인하고 있다
• AI 활용 규칙이 있고, 모두가 알고 있다
• 외부 AI에 넣으면 안 되는 정보가 명확하다
• AI가 작성한 코드도 사람이 리뷰한 후에 적용하고 있다

팀의 도달도는 레벨로 보여줍니다. Google 자원봉사자들이 자동 테스트를 확산시켰을 때 단계 인증인 'Test Certified'를 받은 형태입니다(Mike Bland).

기반 다지기는 성과가 눈에 보이기까지 시간이 걸립니다.

2026년에 나온 DORA의 ROI 보고서도, AI 도입 효과는 일단 침체되었다가 올라가는 J커브를 그릴 것이라고 설명합니다(InfoQ).

보급 연구의 고전에서는, 명백히 우수한 옥수수 신품종조차 미국 농가에 퍼지는 데 10년 이상 걸렸습니다(『혁신의 확산』).

그러니 시작하기 전에 상에게 이해를 얻어두어야 합니다. 제가 준비한 말은 세 가지입니다.

첫 번째는 '병원에서 실시하는 감염 대책의 개발 버전'입니다. 전문 팀이 규칙을 정하고, 각 병동의 추진 역할과 함께 손 씻기 습관을 현장에 뿌리내리게 하는 시스템입니다.

누구나 아는 시스템이라 한마디로 전달됩니다. 효과의 증거로서가 아니라, 시스템을 전달하는 비유로 사용합니다.

두 번째는 '보이지 않는 업무를 가시화합니다'. 영업 분야에서는 임시방편적인 지원에 드는 비용이 간접비의 19%에 달했지만, 아무도 알아차리지 못했습니다.

재고 조사(棚卸し)를 통해 각 팀의 숨겨진 투입 시간(工数)을 모으면, 숫자로 이야기할 수 있게 됩니다.

세 번째는 '작업은 외부에 맡기되, 판단과 정착은 사내에 남깁니다'.

'파견이나 외주로 해결하면 안 되나요?'라는 질문을 반드시 받습니다.

행정학에는 '스마트 바이어(smart buyer)'라는 논의가 있습니다. 이는 외주를 맡기는 측이 무엇을 구매했고, 무엇을 받았는지 판단할 수 없다면, 오히려 문제가 악화된다는 것입니다 (Kettl).

경영학에서도 외부 지식을 활용하는 능력은 사내 관련 지식의 양에 따라 결정된다고 합니다 (赤門マネジメント・レビュー). 따라서 AI로 커져야 할 것은 자사의 역량이며, 기반을 외부에 맡기면 힘이 생기는 쪽은 외주처가 됩니다.

설명 자료의 골격으로는 '헌장(憲章)'이라는 1장의 문서를 만듭니다. 이 문서에는 목적, 대상, 다루는 과제, 제공하는 지원, 성과 측정 방법, 그리고 '대신 작업을 하지 않음'의 6가지 항목이 포함됩니다.

영업 분야 조사에 따르면, 공식적인 비전과 헌장을 가진 조직의 성과 달성률은 51.3%였고, 일회성 프로젝트로 진행한 조직은 34.7%였습니다 (CSO Insights). 이는 상관관계일 뿐 인과관계를 말할 수는 없습니다.

헌장은 다음과 같은 이미지입니다.

개발 역량 강화(イネーブルメント) 헌장

• 목적: AI 효과를 내기 위한 개발의 기반을 각 팀이 스스로 운영할 수 있는 상태로 만드는 것
• 대상: 부서 개발팀 (우선적으로 손을 들인 1~2개 팀)
• 다루는 과제: 재고 조사에서 우선순위가 높았던 상위 2~3가지 항목
• 제공하는 지원: 재고 조사, 시범 팀에 대한 동행 지원(伴走), 정기 데모 공유, 체크리스트
• 성과 측정 방법: 체크리스트 달성률, 환경 구축 및 빌드 대기 시간, 추진 주체 없이 운영 가능한 팀의 수
• 하지 않을 것: 각 팀을 대신하여 작업을 하지 않음

'이네이블먼트(イネーブルメント)'라는 외래어 그대로만 사용하면 개발 외부 사람들에게는 전달되지 않습니다. 자료에서는 '개발 역량 강화(イネーブルメント)'처럼 일본어를 주로 사용했습니다.

무엇을 하겠다고 생각하는 것보다, 언제 무엇을 할지 미리 결정하는 것이 사람이 실제로 움직이게 합니다.

94가지 검증을 정리한 연구에서도 명확한 효과가 나타났습니다 (Gollwitzer 외). 따라서 마지막은 이 형태로 작성합니다.

• 다음 팀 정기 회의가 열리면, '최근 가장 두려웠던 것'과 '최근 잘 되었던 것'을 각각 하나씩 묻는다.
• 상사와의 대화 기회가 생기면, '기반 다지기를 하지 않겠습니까?'라고 상담한다.
• 다음 주 금요일, 상사의 체크리스트로 자신의 팀을 채점하고 점수를 남긴다. 이것이 당신 팀의 출발점이 됩니다.

AI 이야기로 시작한 글이지만, 다음 주에 할 3가지 활동에는 AI 사용법 이야기는 하나도 나오지 않습니다. AI 효과를 내기 위해 먼저 해야 할 것은 사람과 시스템 측면의 문제입니다.

AI와 개발 기반

• State of AI-assisted Software Development 2025 (DORA 보고서 본문, PDF)
• 2025년 DORA 보고서: AI 지원에 의한 소프트웨어 개발 현황 (Google Cloud 공식 블로그)
• 도입부터 성과까지: DORA AI 기능 모델 활용 (Google Cloud 공식 블로그)
• Finding balance in the era of tokenmaxxing (DORA)
• 국내 기업의 DX 동향 및 AI 활용 동향 포인트 (IPA, 2026년 7월)
• 외야마 켄타로 『기술은 빈곤을 구하지 못한다』 (みすず書房)
• 다나카 요이치로 외 『엔지니어 팀의 생산성을 높이는 방법』 (技術評論社) 제6장

橋渡しの仕事の先行分野

• 보급 사업이란 (농림수산성)
• 감염 대책 위원회와 ICT의 역할 (일본의사협회 잡지)
• 구현 과학으로 목표하는 EBM의 다음 수순 (의학계 신문)
• 캐파시티 디벨롭먼트 개념 정리 (JICA)
• 에드거 H. 샤인 『사람을 돕는다는 것은 무엇인가』 (英治出版)
• 긍정적 일탈 접근법과 논리 프레임워크 접근법의 통합을 향하여 (국제보건의료)
• 에벨렛 로저스 『혁신의 확산』 (翔泳社)

효과가 없었던 형태

농가 개선 관행 및 농민 성과 향상을 위한 농장 학교 (Campbell Collaboration)

의료 현장에서 혁신을 구현하는 챔피언(champion)의 효과성 (Santos 외)

급성기 병원 간 감염 관리 연계 간호사: 범위 검토 (scoping review) (Dekker 외)

챔피언 역설 (The champion paradox) (Implementation Science Communications, 2026년)

유행이 지난 후의 품질 서클 (Quality Circles After the Fad) (Lawler & Mohrman, Harvard Business Review, 1985년)

1990년대 이후 일본의 소규모 집단 활동 (小川慎一, 横浜経営研究, 2011년)

워킹 그룹 제도 도입에 따른 링크 간호사의 인식 향상 (医療マネジメント学会雑誌, 2005년)

영업과 엔지니어의 이네이블먼트(Enablement)

• 판매 역량 강화(Sales Enablement)란 무엇이며 Forrester는 이를 어떻게 정의했는가? (Forrester)

• 전담팀을 통한 지속적 전달 실현 (InfoQ 일본어판, 2018년)

• Fearless Change 48 패턴 목록 (감역자의 블로그)

• 여기에 적은 원칙들은 저 혼자만의 힘이 아닙니다. AI에게 시스템 외 분야나 해외 사례를 찾아보도록 요청한 결과입니다. 각 실천 및 연구의 근거는 반드시 출처와 함께 제시했습니다.

• 링크 간호사나 추진 주체의 효과에 대해서는 견고한 증거가 부족하며, 병원의 예시에도 한계가 있습니다.

• 농민 학교 연구는 개발도상국의 농업을 대상으로 하므로, 개발팀에 그대로 적용된다고 할 수는 없습니다.

• 영업 분야에서 효과를 보여주는 많은 수치는 툴 벤더(tool vendor) 발 조사이며, 상관관계에 그칩니다.

• 일본의 소규모 집단 활동 실행률은 조사 연도별로 대상이나 정의가 조금씩 달라 엄밀히 비교할 수 없습니다.

• 의료 분야에서 자주 언급되는 '17년'이라는 기간은 측정 구간에 따라 숫자가 크게 바뀐다는 비판이 있습니다.

• 엔지니어링 세계가 영업 분야에서 용어를 가져왔음을 보여주는 출처는 찾을 수 없었습니다.