AI 에이전트 도입의 판단 기준──맡겨도 되는 일, 아직 맡기지 말아야 할 일 제9회

이 시리즈에서는 AI 에이전트를 개발 공정에 도입하는 방법을 써왔습니다.

마지막으로, 도입의 판단 기준을 정리합니다.

어떤 작업부터 시작해야 하는가.

어디까지 맡겨도 되는가.

아직 맡기지 않는 편이 좋은 작업은 무엇인가.

팀에서 사용한다면, 무엇을 먼저 정비해야 하는가.

AI 에이전트는 사용하는 것만이라면 간단합니다.

어려운 것은, 일상적인 업무에 넣는 것입니다.

처음부터 중요한 본 작업(production work)을 맡길 필요는 없습니다.

처음에 적합한 것은, 실패해도 되돌리기 쉽고, 결과물을 인간이 확인하기 쉬운 일입니다.

예를 들어,

• 기존 리포지토리(repository)의 read-only 조사
• 입력 파일의 정리
• 기존 테스트의 조사
• docs의 요약
• issue의 정리
• PR 설명문의 초안 작성
• review checklist 작성
• failing test 후보 작성
• 에러 로그의 시계열 정리
• 버그 보고의 정형화

이것들은 agent가 틀리더라도 인간이 고치기 쉽습니다.

게다가, 바로 도움이 됩니다.

처음부터 "기능을 통째로 만들어"가 아니라, "인간이 판단하기 쉬운 재료를 만들어"부터 시작한다.

이것이 가장 안정적입니다.

맡기는 방식은 4단계로 나눕니다.

Level 1: 읽게 하기 (read-only)
Level 2: 초안 작성시키기 (draft)
Level 3: 한정하여 변경시키기 (limited write)
...

Level 1은 read-only입니다.

조사, 요약, 입구 찾기, 로그 정리.

Level 2는 draft입니다.

PR 코멘트 안, 사양서 안, 수정 계획, runbook 안.

Level 3는 limited write입니다.

지정된 파일만 변경, 테스트만 추가, docs만 업데이트.

Level 4는 approval required입니다.

외부 서비스로의 게시, ticket 업데이트, PR 생성, staging 조작.

처음에는 Level 1과 Level 2만으로 충분합니다.

익숙해진 뒤에 Level 3.

Level 4는 마지막입니다.

AI 에이전트에게 맡기기 쉬운 작업에는 조건이 있습니다.

- 목적이 명확함
- 변경 범위가 작음
- 기존 패턴이 있음
...

이 조건에 많이 해당할수록 맡기기 쉽습니다.

예:

• 문구 수정
• docs 업데이트
• 작은 UI 수정
• 테스트 추가
• 기존 패턴에 따른 API 수정
• lint / type error의 국소적 수정
• 기존 로그의 정리

반대로, 조건에서 벗어날수록 신중하게 합니다.

다음 작업은 처음부터 맡기지 않는 편이 좋습니다.

• production deploy
• production DB write
• user data delete
• billing 변경
• 권한 변경
• 인증 설계의 큰 변경
• 암호화, 키 관리, secret rotation
• legal / compliance 판단
• 큰 DB migration
• 사양이 확정되지 않은 대규모 개수

이것들은 agent가 도움이 되지 않는다는 의미가 아닙니다.

직접 실행시키지 않는 편이 좋다는 의미입니다.

맡긴다면, 재료 만들기로 합니다.

deploy checklist를 만든다.
migration risk를 정리한다.
권한 변경의 영향 범위를 파악한다.
...

마지막 판단과 실행은 인간이나 기존의 승인 플로우(approval flow)에 남겨둡니다.

AI 에이전트 도입에서 실패하기 쉬운 것은, 편리해 보이는 곳부터 시작하는 것입니다.

큰 기능을 통째로 만들게 하려고.
쌓인 issue를 전부 처리하게 하려고.
테스트가 부족한 곳을 한꺼번에 고치게 하려고.

마음은 이해합니다.

하지만, 처음에 하기에는 너무 큽니다.

도입 초기에 보아야 할 것은, 편리함보다 관리하기 쉬움입니다.

작음
되돌릴 수 있음
볼 수 있음
...

이 5가지를 충족하는 작업부터 시작합니다.

팀에서 시작한다면, 처음 2주는 이것으로 충분합니다.

최소한이면 됩니다.

## Commands
- test:
- typecheck:
...

첫 번째 태스크는 구현이 아니라 조사로 합니다.

이 기능의 입구와 기존 테스트를 조사해 주세요.
아직 변경하지 마세요.

다음으로, 테스트만 추가합니다.

이 버그를 재현하는 failing test만 추가해 주세요.
구현은 변경하지 마세요.

대상 파일을 한정합니다.

이 2개 파일만 변경해 주세요.
refactor는 하지 마세요.

매번 보는 것을 고정합니다.

• 변경 범위가 너무 넓지는 않은가
• 테스트를 삭제하지 않았는가
• 권한, DB, 과금(Billing)에 손을 대지 않았는가
  ...

이것만으로 충분히 시작할 수 있습니다.

도입 효과는 "AI를 몇 번 사용했는가"로 측정하지 않습니다.

봐야 할 것은 업무가 안정되었는가입니다.

예를 들어,

• 조사 시간이 단축되었는가
• review의 입구가 알기 쉬워졌는가
• failing test가 늘어났는가
• 동일한 지적이 줄어들었는가
• PR의 변경 범위가 작아졌는가
• AGENTS.md / checklist가 성장하고 있는가
• incident runbook이 늘어나고 있는가
• 인간이 판단해야 할 점이 명확해졌는가

속도만을 보지 않는 것이 좋습니다.

빠르기만 하고 엉망이 된다면, 도입으로서 실패입니다.

빠르고, 보기 편하며, 되돌리기 쉬워지는 것.

이것을 봅니다.

AI 에이전트에는 비용이 따릅니다.

이용 요금뿐만이 아닙니다.

• review 비용
• 실패 시 되돌리는(Rollback) 비용
• context를 정돈하는 비용
• tool 권한 관리 비용
• 테스트 정비 비용
• team rule을 유지보수하는 비용

이것을 보지 않으면, "생성은 빠르지만 후처리가 무거운" 상태가 됩니다.

도입 초기에는 다음을 기록합니다.

Task:
Agent used:
Human time saved:
...

대략적이어도 괜찮습니다.

기록이 있으면 어떤 작업에 적합한지 보이기 시작합니다.

AI 에이전트를 도입해도 인간의 일은 남습니다.

오히려 더 명확해집니다.

인간이 가져야 할 것:

• 목적
• 우선순위
• 허용 리스크
• 사용자 경험(UX)의 판단
• 사양(Specification) 결정
• 운영 환경 반영 승인
• 보안과 권한의 경계 설정
• 하지 않기로 하는 판단

agent에게 적합한 것:

• 조사
• 초안 작성
• 재현
• 작은 구현
• 테스트 추가
• 차이(Diff) 정리
• checklist 작성
• runbook 업데이트 제안

이러한 분담이 가능해지면, agent는 상당히 강력한 조력자가 됩니다.

반대로 인간의 판단까지 모호한 상태로 agent에게 던지면, 결과도 모호해집니다.

도입 전에 사고 발생 시 되돌리는 방법도 정합니다.

## Rollback Policy
- agent의 변경은 반드시 diff로 review한다.
- 큰 변경은 1PR에 모으지 않는다.
...

사고를 제로로 만들 수는 없습니다.

하지만 되돌리기 쉽게 만들 수는 있습니다.

되돌리기 쉬운 작업부터 맡긴다.

이것이 도입의 기본입니다.

자주 발생하는 실패 사례를 듭니다.

처음부터 대규모 개수를 맡기면, review가 정체됩니다.

작게 시작합니다.

매번 똑같은 주의사항을 채팅으로 써야 하게 됩니다.

최소한의 규칙이라도 세워둡니다.

AI가 썼으니까 빠르다며 merge 하면 위험합니다.

diff review, test, 경계 확인을 포함합니다.

read-only와 write를 나누지 않으면 외부 상태가 변합니다.

처음에는 read-only.

생성 속도만 보면 리뷰 부채(Review debt)를 알아차리지 못합니다.

보기 편함, 되돌리기 쉬움, 재발 방지까지 봅니다.

마지막으로, 맡기는 방식의 판단표입니다.

작업	맡기는 방식
기존 코드 조사	맡겨도 좋다. read-only
...

AI 에이전트 도입은 모델 선택만으로 결정되지 않습니다.

어떤 업무부터 시작할 것인가.

어디까지 맡길 것인가.

어디서 멈출 것인가.

어떻게 review 할 것인가.

무엇을 다음으로 넘길 것인가.

여기서 결정됩니다.

처음에는 read-only와 draft부터 시작한다.

작은 변경만 맡긴다.

review와 test를 통과시킨다.

외부 tool은 권한을 나눈다.

실패하면 규칙, checklist, test, runbook으로 되돌린다.

AI 에이전트는 모든 것을 맡기는 상대가 아닙니다.

인간이 판단하기 쉬운 재료를 만들고, 작은 작업을 진행하며, 배움을 다음으로 넘기는 작업자입니다.

이러한 거리감을 두고 사용하면 개발 흐름은 상당히 변합니다.

단순히 빨라지는 것만이 아닙니다.

조사, 구현, review, 재발 방지가 조금씩 같은 흐름을 타게 됩니다.