하나의 작은 팀이 많은 세대의 시스템을 책임지고 있었습니다
이 의료기관은 환자 포털, 예약, 수납과 보험 연계, 직원용 애플리케이션, EMR 주변 인터페이스를 운영합니다. 시스템의 수와 수명에 비해 내부 개발 조직은 크지 않았고, 오래된 연계 코드의 의미를 정확히 아는 사람은 일부 선임 엔지니어에 집중되어 있었습니다.
개발자들은 코드 탐색, 테스트 작성, 반복 유지보수에 AI 코딩 도구를 쓰고 싶어 했습니다. 보안 조직도 생산성 가능성에는 동의했습니다. 문제는 모델로 전달되는 정보와 실행 가능한 행동을 병원이 설명하고 제한할 수 있느냐였습니다.
기존 선택지는 허용하거나 금지하는 것뿐이었습니다
환자 식별자, 내부 소스 코드, 시스템 구성, 민감한 운영 정보가 통제 환경을 벗어날 가능성을 배제할 수 없었습니다. 어떤 모델이 문맥을 받았는지, AI가 어떤 파일을 읽었는지, 명령 실행이나 패키지 설치가 가능한지, 누가 행동을 승인했는지에 대한 답도 여러 도구에 흩어지거나 남지 않았습니다.
그래서 공식 정책은 외부 AI 코딩 도구를 금지하거나 극도로 제한하는 것이었습니다. 개발자의 개인적 기대와 병원의 책임 사이를 연결할 운영 모델이 없었습니다.
Patty Code가 사용 경험을, PCCP가 허용 근거를 만들었습니다
처음 관심을 끈 것은 코딩 에이전트인 Patty Code였지만 실제 도입을 가능하게 만든 것은 PCCP였습니다. 개발 환경 전체를 AI 중심으로 다시 설계하지 않고도, 모델·저장소·도구·실행 사이에 명시적인 통제 경계를 둘 수 있었기 때문입니다.
작게 시작하고 생산 환경을 명시적으로 제외했습니다
첫 단계는 개발자 18명, 저장소 6개, 약 8주로 제한했습니다. 예약, 청구 연계, 내부 포털, 알림 서비스, 공통 라이브러리와 오래된 연계 애플리케이션 하나가 포함됐습니다. 실시간 EMR 데이터와 생산 배포는 범위 밖이었습니다.
구현 과정
통제 경로를 먼저 정의했습니다
PCCP를 통제 환경 안에 배치하고 AI 보조 개발의 허가된 경로로 지정했습니다. Patty Code는 참여 개발자에게 제공했지만 모델 접근과 실행은 같은 정책 계층을 통과하도록 구성했습니다.
생산 데이터베이스와 환자 식별자: 차단
승인된 작업공간의 일반 저장소 읽기와 수정: 허용
패키지 설치와 민감 디렉터리: 추가 승인
생산 배포: 금지
정책을 실제 사용 기록으로 조정했습니다
초기에는 너무 많은 작업에 승인을 요구해 개발 흐름이 자주 끊겼습니다. 관찰 기록을 바탕으로 저위험 행동은 자동화하고, 민감한 파일·도구·환경 전환에는 승인 요구를 유지했습니다.
관찰된 변화
- 4일 → 2.5–3일
- 일상 유지보수 처리파일럿에 포함된 애플리케이션 기준
- 2–4시간 → 45–90분
- 낯선 레거시 코드의 초기 조사유용한 첫 분석까지의 관찰 범위
- 50%+
- 다수 코드 리뷰의 준비 시간 감소고객 팀의 파일럿 관찰
코드가 맞아도 운영 현실과 다를 수 있었습니다
AI가 소스 코드를 정확히 읽었더라도 해당 구조가 현재 운영에서 중요한지는 별개의 문제였습니다. 선임 엔지니어가 초기 시스템 지도를 검증했고, 차단된 문맥이나 행동은 실패가 아니라 통제가 실제로 작동했다는 증거로 다뤘습니다.
생산성 프로젝트로 시작했지만, 도입을 가능하게 한 것은 거버넌스였습니다
개발자는 Patty Code의 작업 능력을 중요하게 보았고 보안·컴플라이언스 조직은 PCCP의 경계와 기록을 중요하게 보았습니다. 이 단계에서는 사람이 직접 에이전트를 사용하는 것이 핵심이었기 때문에 Crew나 Pilot까지 확장할 필요는 없었습니다.
근거와 공개 범위
고객 보고 및 파일럿 관찰. 수치는 해당 기간과 포함된 애플리케이션에 한정된 근사값이며 전사 생산성 측정이 아닙니다.
고객의 신원을 보호하기 위해 기관명과 식별 가능한 시스템 정보는 공개하지 않았습니다. 직접 인용문을 사용하지 않았으며, 인터뷰 메모를 공개용 3인칭 서술로 재구성했습니다.