서론

구조로 키우는 프로덕트 조직 시리즈에서는, 프로덕트 조직을 "강한 사람을 모으면 자연스럽게 강해지는 것"이 아니라, 관측·판단·실행·검증·학습이 남는 구조로 바라보았습니다.

이 부록에서는 그 연장선상에서, AI 주도 개발(AI-driven development)을 본업에서 운용하기 위한 개발 조직을 다룹니다.

AI 코딩 지원은 이미 드문 일이 아니게 되었습니다.

GitHub Copilot, Cursor, Claude Code, Devin 계열의 개발 에이전트(Development Agent), 사내 RAG, PR 리뷰 지원, 테스트 생성, 문서 생성 등 개발의 곳곳에 AI가 스며들기 시작했습니다.

하지만 실제로 개발 조직에 도입해 보면 바로 알 수 있는 것이 있습니다.

AI로 코드를 빠르게 작성하는 것과 개발 조직으로서 안전하게 빨라지는 것은 별개의 문제입니다.

AI는 코드를 쓰는 속도를 높입니다.

조사도 빠르게 합니다.

테스트 안도 내놓습니다.

PR 설명도 깔끔하게 작성합니다.

하지만 조직 측에 이를 받아낼 메커니즘이 없다면, 늘어나는 것은 생산성이 아니라 리뷰 불가능한 차분(diff)일지도 모릅니다.

AI 주도 개발에서 정말로 설계해야 하는 것은 AI 도구 그 자체만이 아닙니다.

설계해야 하는 것은, AI가 무엇을 전제로 변경안을 내놓는지, 그 변경안을 누가 확인하는지, 어떤 권한으로 반영하는지, 어떤 테스트로 보증하는지, 어떤 조건으로 릴리스(Release)하는지, 그리고 실패했을 때 어떻게 되돌릴 것인가입니다.

그리고 여기서 필요해지는 규율의 상당수는 사실 AI 이전부터 존재했습니다.

좋은 이슈(Issue)를 작성하기.

설계 의도를 남기기.

리뷰 가능한 차분(diff)으로 만들기.

사양(Specification)에 기반한 테스트를 작성하기.

권한을 분리하기.

단계적으로 릴리스하기.

실패 시 되돌릴 수 있도록 하기.

모두 예전부터 말해온 평범하고 좋은 실천들입니다.

AI가 바꾼 것은 이러한 중요성이 아닙니다.

나태해졌을 때의 파탄 속도입니다.

AI는 모호한 이슈에도 변경안을 내놓습니다.

설계 의도가 남아 있지 않아도 국소적으로 동작하는 패치(patch)를 만듭니다.

PR 설명을 깔끔하게 정리합니다.

테스트다운 것도 늘려줍니다.

그렇기 때문에 조직 측의 규율이 약하면, 문제가 보이지 않는 상태에서 차분(diff)만 늘어납니다.

이 기사에서는 AI 주도 개발을 단순한 "AI로 코드를 쓰는 이야기"가 아니라, 기존의 좋은 개발 실천을 AI 시대에 나태해질 수 없는 운용으로 바꾸는 설계 문제로서 정리합니다.

본 시리즈의 맥락에서 말하자면, 이것은 "AI를 사용하는 개발자 개인의 생산성" 이야기가 아닙니다.

AI가 늘리는 변경안을 개발 조직이 어떻게 받아들이고, 어떻게 검증하며, 어떻게 책임을 지고 본업으로 흘려보내며, 어떻게 학습으로 바꿀 것인가에 대한 이야기입니다.

AI 주도 개발은 "코드 생성"만이 아니다

많은 경우 AI 주도 개발은 처음에 다음과 같이 이해됩니다.

AI에게 코드를 쓰게 한다.

AI에게 테스트를 쓰게 한다.

AI에게 리뷰를 시킨다.

AI에게 조사를 시킨다.

이것들은 편리합니다.

다만 기업이나 팀에서 본업으로 운용할 경우, 이것만으로는 부족합니다.

왜냐하면 실제 개발에서는 코드를 쓸 수 있느냐보다, 그 코드를 안전하게 반영할 수 있느냐가 더 중요하기 때문입니다.

예를 들어, AI가 어떤 API의 수정 코드를 내놓았다고 가정해 봅시다.

코드 자체는 깔끔하고 테스트도 통과한 것처럼 보입니다.

하지만 그 변경이 다음과 같은 것들에 영향을 미친다면 어떨까요?

• 과금 처리
• 인증·인가 (Authentication/Authorization)
• DB 마이그레이션 (DB Migration)
• 외부 연동
• 감사 로그 (Audit Log)
• 알림 처리
• 관리 화면
• 운용 런북 (Runbook)
• 기존 유저의 데이터 호환성

AI가 국소적으로 올바른 코드를 작성하더라도, 개발 조직이 전체적인 영향을 간과하면 본업에서는 망가집니다.

즉, AI 주도 개발의 본질은 이렇습니다.

AI로 코드를 쓰는 것이 아니라, AI가 내놓은 변경안을 팀이 이해하고, 리뷰하고, 검증하고, 릴리스하고, 실패 시 되돌릴 수 있는 형태로 변환하는 것.

이 지점을 놓치면 AI 도입은 개발 속도의 향상이 아니라 "변경량의 증가"가 됩니다.

변경량만 늘어난다면 리뷰, 테스트, 설계, 운용은 오히려 더 힘들어집니다.

AI는 새로운 규율을 요구하고 있는 것이 아니다

AI 주도 개발 논의에서는 마치 AI 시대에 완전히 새로운 개발 조직론이 필요해진 것처럼 이야기되곤 합니다.

하지만 실제로 필요해지는 규율의 상당수는 AI 이전부터 존재했습니다.

즉, AI가 새로운 것은 규율 그 자체가 아닙니다.

새로운 것은, 규율을 게을리했을 때 차이(diff)가 늘어나고, 리뷰가 정체되며, 책임 소재가 무너지고, 운영 환경에 미치는 영향이 빠르게 확산된다는 점입니다.

원칙은 오래되었습니다.

파탄이 나는 방식이 새로운 것입니다.

이 전제에 서면, AI 주도 개발(AI-driven development)로 갈팡질팡하는 조직에 부족한 것은 반드시 고도의 AI 지식은 아닙니다.

오히려, 예전부터 필요하다고 말해온 개발 규율을 조직으로서 실제로 운용하는 힘입니다.

AI를 「개발자」가 아니라 「변경안을 내놓는 엔진」으로 다루기

AI 주도 개발에서 우선 중요한 것은 AI의 위치 설정입니다.

AI를 갑자기 「개발자」나 「책임자」로 다루면 설계가 무너집니다.

AI는 어디까지나 변경안을 내놓는 엔진으로서 다루어야 합니다.

AI가 낼 수 있는 것은 많이 있습니다.

AI가 낼 수 있는 것:
- 구현안
- 테스트안
...

반면, 개발 조직이 결정해야 하는 것들이 있습니다.

개발 조직이 결정하는 것:
- 해당 변경을 채택할 것인가
- 설계로서 타당한가
...

AI는 강력한 제안자입니다.

하지만 최종적인 책임 주체는 아닙니다.

AI가 작성한 코드라 할지라도, 머지(merge)하는 순간 그것은 팀의 코드입니다.

팀이 이해할 수 없는 코드라면, 팀의 자산으로 삼을 수 없습니다.

조금 강하게 말하자면,

AI가 작성한 코드를 이해할 수 없다면, 머지해서는 안 됩니다.

AI를 사용하는 것 자체가 문제는 아닙니다.

AI의 출력을 팀이 이해할 수 있는 형태로 변환하지 않은 채 받아들이는 것이 문제입니다.

AI로 인해 노출·증폭되는 기존의 약점

AI 주도 개발을 도입하면 처음에는 개인의 작업 효율이 올라갑니다.

하지만 조직으로서 운용하기 시작하면 몇 가지 약한 부분이 노출됩니다.

티켓이 모호한 채로 AI에게 던져짐

예를 들어, 이슈(Issue)에 다음과 같이 적혀 있다고 가정해 봅시다.

결제 관련 부분을 개선한다

로그인 경험을 좋게 만든다

관리 화면의 표시를 수정한다

사람 사이에서도 위험한 입도(granularity)이지만, AI에게 던지면 더욱 위험합니다.

AI는 모호한 의뢰에도 그럴듯한 답을 내놓습니다.

그리고 그럴듯한 변경안이나 코드를 내놓습니다.

문제는 그 변경이 정말로 필요한 것인지, 무엇을 전제로 하고 있는지, 어디까지 영향을 미치는지 모호한 채로 진행되어 버린다는 점입니다.

AI에게 작업을 의뢰하려면 티켓 측에 최소한의 전제가 필요합니다.

• 무엇을 바꾸고 싶은가
• 왜 바꾸고 싶은가
• 바꾸면 안 되는 것은 무엇인가
• 관련 사양(specification)은 어디인가
• 관련 코드는 어디인가
• 기대하는 테스트 관점은 무엇인가
• 영향 범위는 어디인가
• 리스크는 어느 정도인가

AI가 똑똑한가 이전에, 의뢰가 모호하면 출력도 위태로워집니다.

AI가 기존 설계를 모른 채 국소 수정함

AI는 눈앞의 파일이나 함수를 잘 고칠 때가 있습니다.

하지만 코드베이스 전체의 설계 의도를 모르는 채 수정하면, 국소적으로는 맞지만 전체적으로는 망가지는 변경이 발생합니다.

예를 들어,

• 본래는 유스케이스(UseCase) 계층에 두어야 할 처리를 컨트롤러(Controller)에 작성함
• 공통 라이브러리가 아니라 개별 구현을 늘림
• 기존의 이벤트 설계를 무시하고 동기 호출(synchronous call)을 추가함
• DB 제약 조건과 애플리케이션 제약 조건을 이중으로 가짐
• 임시 대응일 뿐인데 영구 구현처럼 보이는 형태로 들어감

이런 변경은 컴파일도 통과하고 테스트도 통과할 수 있습니다.

그렇기에 위험합니다.

AI에게 코드를 쓰게 하려면 AI가 참조할 수 있는 설계 문서, ADR(Architecture Decision Record), 코딩 규약, 금지 패턴을 정비해야 합니다.

AI에게 「분위기를 파악하라」는 통하지 않습니다.

분위기는 문서나 규칙, 혹은 테스트로 떨어뜨려 놓아야 합니다.

PR 설명이 너무 깔끔해서, 리뷰한 것 같은 기분이 듦

AI는 PR(Pull Request) 설명을 쓰는 데 능숙합니다.

배경, 변경점, 테스트, 영향 범위를 그럴싸하게 정리해 줍니다.

이것은 편리합니다.

하지만 여기에도 함정이 있습니다.

깔끔한 설명이 올바른 것을 의미하지는 않습니다.

PR 설명이 잘 정돈되어 있으면 리뷰어는 「제대로 생각되었구나」라고 느끼기 쉽습니다.

하지만 그 설명이 정말로 코드 차이(diff)와 일치하는지, 영향 범위를 누락하지 않았는지, 테스트가 의미 있는 사양을 지키고 있는지는 별개의 문제입니다.

AI 시대의 리뷰에서는 설명문의 자연스러움이 아니라 다음을 보아야 합니다.

• 어떤 전제를 보고 변경했는가
• 참조해야 할 사양을 보고 있는가
• 영향 범위가 과소 보고되지 않았는가
• 테스트가 정말로 지켜야 할 사양을 짚고 있는가
• 확인되지 않은 가정이 남아 있지 않은가
• 실패 시 되돌릴 수 있는가

PR 설명은 편리합니다.

하지만 리뷰를 대신할 수는 없습니다.

테스트는 늘어나지만, 지켜야 할 사양을 짚지 못함

AI는 테스트도 쓸 수 있습니다.

하지만 AI가 생성하는 테스트는 구현에 끌려가기 쉽습니다.

즉, "이 코드가 이렇게 동작한다"는 테스트는 늘어나더라도, "본래 이 사양을 지켜야 한다"는 테스트가 되지 못하는 경우가 있습니다.

위험한 것은 테스트 수만 늘어나고 안심하는 것입니다.

AI 주도 개발 (AI-Driven Development)에서는 테스트에 대해서도 다음을 확인해야 합니다.

• 사양으로부터 도출된 테스트인가
• 현재 구현의 동작을 고정하고 있을 뿐인가
• 이상계 (Exception cases)를 다루고 있는가
• 외부 연동이나 경계 조건 (Boundary conditions)을 다루고 있는가
• 회귀 버그 (Regression bugs)를 방지할 수 있는가
• 테스트 명칭에서 의도를 알 수 있는가

AI가 생성한 테스트는 테스트 코드로서는 올바르더라도, 품질 보증 (QA) 측면에서는 약할 수 있습니다.

리뷰량이 늘어나고, 리뷰어가 피로해진다

AI로 구현 속도가 올라가면, PR (Pull Request)의 수나 차분 (Diff) 양이 늘어납니다.

그러면 리뷰어가 병목이 됩니다.

리뷰 대기가 늘어납니다.

리뷰가 얕아집니다.

LGTM이 의식이 됩니다.

이는 흔히 발생하는 실패입니다.

AI 도입으로 생성 속도만 높이면, 병목은 리뷰, 테스트, 릴리스 판단으로 이동합니다.

즉, AI 주도 개발을 하려면 리뷰 설계도 바꿔야 합니다.

모든 것을 동일한 입도로 리뷰하는 것이 아니라, 리스크에 따라 리뷰의 깊이를 바꿉니다.

AI에게 리뷰 관점을 만들게 합니다.

PR에 필요한 설명을 자동으로 수집합니다.

고위험 변경 사항만 두텁게 검토합니다.

그렇게 하지 않으면, AI는 리뷰어의 일을 줄여주기는커녕 오히려 늘립니다.

변경의 출처가 섞인다

AI 주도 개발에서는 변경의 출처도 모호해지기 쉽습니다.

예를 들어, 다음과 같은 흐름은 흔히 일어납니다.

AI가 구현안을 제시한다
↓
인간이 일부를 다시 쓴다
...

이때 어디까지가 AI 생성이고, 어디서부터가 인간의 판단인지 쉽게 알 수 없습니다.

모든 것을 완전히 분리할 필요는 없습니다.

하지만 적어도 다음 사항은 알 수 있도록 해두어야 합니다.

• AI를 어느 단계에서 사용했는가
• AI가 생성한 것을 인간이 확인했는가
• 어떤 전제를 참조하여 변경했는가
• 최종적인 판단을 누가 책임졌는가
• 장애 발생 시 변경 이유를 추적할 수 있는가

AI 시대의 증적 설계 (Audit trail design)에서는 AI가 썼는지 여부만으로는 부족합니다.

중요한 것은 그 변경을 팀이 어떻게 수용했는지를 나중에 추적할 수 있는 것입니다.

개발 조직 설계

AI 주도 개발을 실무에 운용하려면, 개발 조직의 역할도 조금 변합니다.

여기서는 필요한 기능을 5가지로 나누어 정리합니다.

1. 프로덕트 개발 팀

프로덕트 개발 팀은 계속해서 중심 역할을 합니다.

다만 역할은 조금 변합니다.

기존의 개발자는 주로 스스로 조사하고, 스스로 구현하며, 스스로 테스트를 작성하는 존재였습니다.

AI 주도 개발에서 개발자는 AI에게 작업을 의뢰하고, 나온 변경안을 선별하며, 팀으로서 도입할 수 있는 형태로 정돈하는 존재가 됩니다.

주요 책무는 다음과 같습니다.

• Issue를 구체화하기
• AI에게 전달할 전제 조건 정리하기
• AI에게 변경 계획을 세우게 하기
• AI의 구현안 확인하기
• 변경 의도 이해하기
• 테스트와 리뷰 관점 정비하기
• 책임감을 가지고 PR 제출하기

중요한 것은 AI가 작성한 코드라 할지라도 팀이 책임을 지는 것입니다.

"AI가 이렇게 작성해서 잘 모르겠습니다"는 통하지 않습니다.

머지(Merge)할 것이라면 이해한다.

이해할 수 없다면 범위를 좁히거나 다시 작성한다.

2. AI Platform / DevEx 팀

AI 주도 개발을 각 팀에 맡겨두면 혼란스러워집니다.

• 팀마다 사용하는 AI 도구가 다르다
• 프롬프트 (Prompt)가 개인의 역량에 의존한다 (Siloed)
• 어떤 코드를 AI에게 읽히고 있는지 알 수 없다
• 비밀 정보 취급이 모호해진다
• 이용 로그가 남지 않는다
• 비용이 보이지 않는다
• 사내 문서를 참조할 수 있는 팀과 없는 팀이 생긴다

이를 피하기 위해 AI Platform / DevEx 팀이 필요해집니다.

이 팀의 역할은 AI를 안전하게 사용하기 위한 개발 기반을 만드는 것입니다.

구체적으로는,

• IDE 통합
• 사내 코드 검색
• 사양서·ADR·Runbook 검색 기반
• AI에게 전달할 컨텍스트 (Context) 생성
• 모델 및 도구 선정
• 시크릿 (Secret) 제외
• 권한 관리
• AI 이용 로그
• 비용 관리
• PR 템플릿 및 리뷰 지원
• 개발자용 CLI 및 ChatOps

등입니다.

AI Platform / DevEx 팀은 편리한 AI 도구를 나눠주는 역할이 아닙니다.

AI가 개발 프로세스에 들어오기 위한 안전한 통로를 만드는 팀입니다.

3. 아키텍처 책임자 / 설계 리뷰 팀

AI는 국소적인 수정에 능숙합니다.

그렇기 때문에 아키텍처의 경계를 명시하는 역할이 중요해집니다.

예를 들어, 다음과 같은 영역입니다.

• API 경계
• DB 경계
• 인증·인가 (Authentication/Authorization)
• 과금
• 이벤트 설계
• 비동기 처리
• 외부 연동
• 로그·감사
• 멀티테넌트 (Multi-tenant) 경계
• 데이터 삭제
• 권한 변경

이것들은 AI에게 자유롭게 맡기면 위험한 영역입니다.

아키텍처 책임자나 설계 리뷰 팀은 다음을 정비합니다.

• 변경해도 좋은 영역
• 신중하게 다뤄야 할 영역
• 변경 금지 패턴
• 기존 설계의 의도
• ADR (Architecture Decision Records)
• API 설계 방침
• DB 마이그레이션 (Migration) 방침
• 고위험 변경의 리뷰 조건

한마디로 말하면, AI가 길을 잃지 않도록 코드베이스의 지도를 만드는 역할입니다.

지도 없이 AI를 걷게 하면, AI는 능숙하게 벽 안에 계단을 만들어 버립니다.

4. Release Engineering / SRE

AI 주도 개발에서는 변경량이 증가합니다.

따라서 릴리스와 운영 설계가 점점 더 중요해집니다.

Release Engineering / SRE의 역할은 AI가 내놓은 변경 사항을 안전하게 운영 환경으로 흘려보내기 위한 조건을 갖추는 것입니다.

구체적으로는,

• CI/CD
• feature flag
• canary release
• shadow traffic
• rollback 절차
• 모니터링
• 알람
• 변경 이력 추적
• 장애 발생 시 원인 식별
• postmortem
• 릴리스 기준

등이 있습니다.

AI 주도 개발에서 두려운 것은 단순히 버그가 늘어나는 것이 아닙니다.

정말로 두려운 것은 장애가 발생했을 때, 어떤 변경이, 왜, 어떤 전제하에 들어왔는지 추적할 수 없는 것입니다.

AI로 개발 속도를 높이려면, SRE는 후속 공정이 아니라 개발 프로세스의 일부로 다뤄야 합니다.

5. Security / Compliance

AI는 편리하지만, 권한 설계를 잘못하면 위험합니다.

특히 주의해야 할 것은 다음과 같습니다.

• 비밀 정보
• 개인 정보
• 인증 정보
• 운영 데이터
• 권한 변경
• 데이터 삭제
• dependency 추가
• 외부 API 연동
• 라이선스
• 생성된 코드의 취약점

Security / Compliance는 AI를 금지하기 위한 역할이 아닙니다.

안전하게 사용할 수 있는 범위를 정의하는 역할입니다.

AI가 할 수 있는 일을 늘릴수록, 권한의 경계는 더욱 명확히 해야 합니다.

개발 프로세스 설계

다음으로 AI 주도 개발의 프로세스를 살펴보겠습니다.

이상적인 흐름은 다음과 같습니다.

Issue
↓
전제 확인
...

포인트는 AI의 출력을 곧바로 PR (Pull Request)로 만들지 않는 것입니다.

AI에게 처음부터 코드를 쓰게 하는 것이 아니라, 먼저 전제를 정리하고 변경 계획을 내놓게 한 뒤, 그 계획을 확인하고 나서 구현으로 나아갑니다.

Issue에 「AI에게 전달할 전제」를 담기

AI 주도 개발에서는 Issue의 질이 상당히 중요해집니다.

Issue가 모호한 상태로 AI에게 던져지면, AI는 모호한 전제를 바탕으로 변경안을 내놓습니다.

Issue에는 최소한 다음 정보를 포함하고 싶습니다.

## 목적
무엇을 달성하고 싶은가
## 배경
...

매번 모든 내용을 깔끔하게 적을 필요는 없습니다.

다만, 고위험 변경일수록 전제 조건은 두텁게 작성해야 합니다.

처음에는 코드가 아니라 변경 계획을 쓰게 하기

AI에게는 갑자기 코드를 쓰게 하지 않는 편이 좋습니다.

먼저 변경 계획을 쓰게 합니다.

변경 계획에는 다음을 포함합니다.

## 변경 대상
어떤 파일, 모듈, API를 수정하는가
## 변경 이유
...

이 단계에서 리뷰해야 할 것은 코드의 세부 사항이 아닙니다.

봐야 할 것은 방향성입니다.

• 수정하는 위치가 올바른가
• 영향 범위를 간과하지 않았는가
• 더 안전한 대안은 없는가
• 테스트 방침이 타당한가
• 확인되지 않은 전제가 위험하지는 않은가

여기서 잘못된 점을 잡아낼 수 있다면 불필요한 구현을 줄일 수 있습니다.

AI에게 처음부터 코드를 쓰게 하면 리뷰 대상이 갑자기 거대해집니다.

먼저 변경 계획을 내놓게 함으로써, 잘못된 방향으로의 구현을 조기에 차단할 수 있습니다.

구현은 sandbox branch에서 수행

AI에게 구현을 시킬 경우, 처음에는 sandbox branch나 임시 브랜치에서 수행하는 것이 안전합니다.

AI에게 허용하는 작업은 처음에는 제한합니다.

허용하는 것:

• 리포지토리 읽기
• patch 생성
• 테스트 실행
• lint 실행
• PR 설명 초안 작성

금지하는 것:

• main 브랜치로의 직접 커밋 (direct commit)
• 운영 환경(production environment)으로의 접속
• secret 참조
• 마이그레이션 (migration) 실행
• 배포 (deploy)
• 권한 변경
• 외부 알림
• 데이터 삭제

AI의 권한은 편리함만으로 결정해서는 안 됩니다.

"할 수 있는 것"과 "허가해도 되는 것"은 별개입니다.

PR은 "차이(diff)"가 아니라 "변경의 증거 세트"로 만들어야 합니다

AI 시대의 PR은 단순한 diff만으로는 부족합니다.

PR은 변경 사항을 리뷰 가능하게 만들기 위한 증거 세트여야 합니다.

PR에는 최소한 다음을 포함하고 싶습니다.

## 목적
이 PR을 통해 무엇을 달성할 것인가
## 배경
...

중요한 것은 AI가 작성한 설명을 그대로 믿지 않는 것입니다.

PR 설명은 AI가 작성해도 좋습니다.

단, 인간이 확인한 범위를 명시해야 합니다.

리뷰 관점을 바꾸기

AI 주도 개발에서는 리뷰의 관점도 바뀝니다.

기존의 리뷰에서는 주로 다음을 확인했습니다.

• 코드가 올바른가
• 읽기 쉬운가
• 테스트가 있는가
• 네이밍 (naming)이 타당한가
• 설계에 부합하는가

물론 이것들도 여전히 중요합니다.

하지만 AI 주도 개발에서는 추가로 다음을 확인해야 합니다.

• 전제 조건이 충분한가
• AI가 건드려서는 안 되는 영역을 건드리지 않았는가
• 영향 범위가 과소 보고되지 않았는가
• 사양(specification)과 구현이 어긋나지 않았는가
• 테스트가 사양을 준수하고 있는가
• AI 생성 코드를 팀이 이해할 수 있는가
• 확인되지 않은 전제가 남아있지 않은가
• 실패 시 되돌릴 수 있는가

AI 시대의 리뷰는 코드 채점이 아닙니다.

변경 사항을 운영 환경으로 통과시켜도 될지 확인하는 행위입니다.

리스크별로 AI의 권한 나누기

모든 변경을 동일한 규칙으로 다루면 현장은 지칩니다.

README 수정과 결제 처리 변경을 같은 무게로 다룰 필요는 없습니다.

반대로, 결제 처리 변경을 README 수정과 같은 가벼움으로 다뤄서도 안 됩니다.

AI의 권한은 툴 단위가 아니라, 변경의 리스크 단위로 나누어야 합니다.

중요한 것은 "이 AI 툴을 사용해도 되는가"가 아니라, "이 변경에 대해 AI에게 무엇을 허용할 것인가"입니다.

같은 AI라도 README에서는 PR 생성까지 허용해도 될 것입니다.

반면, 권한 관리나 데이터 삭제에서는 제안 단계에 머물러야 합니다.

개발자 경험 (Developer Experience) 설계

지금까지의 이야기는 조금 무겁게 느껴질 수도 있습니다.

전제 확인, 변경 계획, 증거 세트, 리뷰, 리스크 분류.

이것만 들으면 번거로운 프로세스를 늘리는 것처럼 느껴집니다.

하지만 개발자 경험으로서 잘 설계한다면 오히려 편해집니다.

중요한 것은 가드레일(guardrail)을 금지의 벽이 아니라, 안전하게 나아가기 위한 안내로 설계하는 것입니다.

IDE 경험

이상적으로는 개발자가 이슈(Issue)를 열었을 때, IDE 상에서 다음 내용이 보이면 좋습니다.

• 관련 사양
• 관련 ADR (Architecture Decision Record)
• 관련 PR
• 관련 Runbook
• 관련 코드
• 오너 (owner)
• 리스크 분류
• 변경 금지 영역
• 과거 장애 사례
• 테스트 후보

개발자는 거기서 다음 조작을 선택할 수 있습니다.

- 이 전제로 변경 계획을 만든다
- 부족한 전제를 찾는다
- 이 범위에 대해서만 patch를 만든다
...

자연어로 AI에게 요청할 수 있는 것은 편리합니다.

하지만 기업 개발에서는 자유 입력에만 의존하면 개인의 역량에 따라 결과가 달라지는 속인화(属人化, dependency on individuals)가 발생합니다.

좋은 개발자 경험은 채팅과 구조화된 조작을 결합하는 것입니다.

현행 툴에 적용한다면

지금까지의 이야기는 추상적인 이상론만이 아닙니다.

현행 AI 개발 툴에서도 유사한 형태로 구현할 수 있습니다.

예를 들어, 다음과 같은 대응 관계가 있습니다.

중요한 것은 특정 툴을 그대로 믿는 것이 아닙니다.

툴의 기능을 개발 프로세스 상의 어느 단계에 대응시킬 것인가입니다.

예를 들어, CLI나 ChatOps로 조작한다면 다음과 같은 형태를 생각할 수 있습니다.

ai observe ISSUE-123
ai plan ISSUE-123 --risk medium
ai patch ISSUE-123 --scope billing-ui
...

이 예에서 중요한 것은 커맨드 이름 그 자체가 아닙니다.

AI와의 대화를 최종 결과물로 만들지 않는 것입니다.

대화는 입구로 충분합니다.

하지만 최종적으로는 Issue, 변경 계획, PR, 테스트 결과, 릴리스 기록과 같이 팀이 공유할 수 있는 결과물로 귀결시켜야 합니다.

또한, 외부 툴 연동을 늘릴수록 권한 경계는 중요해집니다.

AI가 Issue를 읽을 수 있을 것.

코드를 읽을 수 있을 것.

patch를 만들 수 있을 것.

테스트를 실행할 수 있을 것.

PR을 만들 수 있을 것.

deploy할 수 있을 것.

이것들은 모두 별개의 권한으로 취급해야 합니다.

편리하다고 해서 한꺼번에 허가하는 것이 아니라, 변경 리스크에 따라 단계적으로 허가합니다.

PR 경험

PR 화면에서는 diff뿐만 아니라 다음 내용이 보이면 리뷰하기 쉬워집니다.

• AI가 생성한 부분
• 인간이 확인한 부분
• 참조한 사양
• 영향 범위
• 리스크 분류
• 테스트 결과
• 보안 체크 결과
• 미확인 전제
• 되돌리는 방법 (rollback)
• 리뷰어에게 확인이 필요한 포인트

AI 주도 개발에서는 리뷰어의 부담을 줄이는 장치가 중요합니다.

단순히 PR 수만 늘어난다면 조직은 한계에 부딪힙니다.

리뷰어가 짧은 시간 안에 중요한 부분에 집중할 수 있도록 만들어야 합니다.

가드레일 경험

AI 이용을 제한할 때, 나쁜 경험은 다음과 같습니다.

이 조작은 허용되지 않습니다.

이것만으로는 개발자가 왜 차단되었는지 알 수 없습니다.

다음에 무엇을 해야 하는지도 알 수 없습니다.

그 결과, 우회하려는 시도가 발생합니다.

좋은 경험은 다음과 같습니다.

이 변경은 결제 처리에 영향을 줄 가능성이 있습니다.
관련 사양서와 회계 연동 테스트가 미확인 상태입니다.
다음 중 하나를 선택해 주세요.
...

가드레일은 개발자의 적이 아닙니다.

하지만 이유와 다음 선택지가 없다면 방해꾼으로 간주되어 형식적으로 흐르게 됩니다.

안전한 프로세스는 과정을 무겁게 만드는 것이 아니라, 망설이지 않게 만들어야 합니다.

측정해야 할 지표와, 출처가 섞이는 문제

AI 주도 개발을 도입하면 무심코 알기 쉬운 지표를 보고 싶어집니다.

예를 들어,

• AI가 생성한 코드 라인 수
• AI 이용 횟수
• PR 수
• 절감 시간에 대한 자기 신고
• AI가 만든 테스트 수

이것들은 참고가 될 수 있습니다.

하지만 주 지표(primary metric)로 삼는 것은 위험합니다.

코드 라인 수가 늘어났다고 해서 가치가 늘어났다고 단정할 수 없습니다.

PR 수가 늘어났다고 해서 개발이 건전해졌다고 단정할 수 없습니다.

테스트 수가 늘어났다고 해서 사양이 지켜지고 있다고 단정할 수 없습니다.

봐야 할 것은 AI에 의해 개발이 안전하고 빨라졌는가입니다.

예를 들어, 다음과 같은 지표입니다.

• lead time
• change failure rate
• MTTR
• rollback 성공률
• 릴리스 후 장애율
• AI를 사용한 PR의 revert율
• AI를 사용한 PR의 추가 수정률
• 리뷰 대기 시간
• 리뷰 부하
• 보안 지적률
• 미확인 전제의 잔존 수
• 영향 범위 간과 건수
• 장애 시 변경 이유를 추적할 수 있는 비율
• 테스트가 사양과 연결되어 있는 비율

다만, 여기에는 주의점이 있습니다.

AI 주도 개발에서는 변경의 출처(origin)가 섞입니다.

AI가 생성하고, 인간이 편집하며, 다른 AI가 리뷰하고, 다시 인간이 수정한 차분(diff)에서는 어디까지를 AI 기인으로 볼 것인지 결정하는 것이 쉽지 않습니다.

따라서 처음부터 정밀한 인과 관계 측정을 목표로 너무 과하게 접근하지 않는 것이 좋습니다.

우선은 PR (Pull Request) 단위로, AI를 어디에 사용했는지를 거칠게 기록하는 것부터 시작합니다.

이 기록 템플릿은 뒤에 이어지는 「작게 시작한다면」의 Step 1에서 제시하겠습니다.

그 후에, revert (되돌리기), 추가 수정, 장애, 리뷰 시간, 보안 지적 사항과의 관계를 경향성으로서 살펴봅니다.

AI가 얼마나 많이 작성했느냐가 아니라, AI에 의해 변경 사항이 얼마나 안전하게 흘러가게 되었는지를 보아야 합니다.

구체적인 예시: 환불 상태를 추가하기

구체적인 예로 생각해 보겠습니다.

「환불 API에 pending_review라는 새로운 상태를 추가한다」라는 변경이 있다고 가정합니다.

나쁜 진행 방식

나쁜 진행 방식은 다음과 같습니다.

개발자:
환불 API에 pending_review를 추가해줘
AI:
...

언뜻 보기에는 좋아 보입니다.

하지만 환불 상태는 API만의 문제가 아닐 수도 있습니다.

• DB (데이터베이스)에는 저장할 수 있는가
• 관리 화면에서 표시할 수 있는가
• 회계 연동은 대응하고 있는가
• 사용자 통지는 어떻게 되는가
• 기존 배치 처리 (batch process)는 어떻게 다루는가
• 감사 로그 (audit log)에 남는가
• 외부 API 계약은 변경되는가
• 기존 상태와의 상태 전이 (state transition)는 타당한가
• rollback (롤백) 시에 어떻게 되돌리는가

이러한 점들을 간과하면 운영 환경에서 문제가 발생합니다.

좋은 진행 방식

좋은 진행 방식에서는 먼저 전제를 정리합니다.

## 목적
환불 처리에 수동 확인 대기 상태를 추가한다
## 변경하고 싶은 동작
...

다음으로, AI에게는 코드가 아니라 변경 계획을 작성하게 합니다.

## 변경 계획
1. RefundStatus에 pending_review를 추가
2. 상태 전이 규칙에 pending_review를 추가
...

이 계획을 리뷰합니다.

그 후에, AI에게 sandbox branch (샌드박스 브랜치)에서 patch (패치)를 만들게 합니다.

CI (지속적 통합)에서 unit test (단위 테스트), integration test (통합 테스트), contract test (계약 테스트), migration dry-run (마이그레이션 드라이런)을 실행합니다.