📖 약 6분 읽기
AI 코딩 도구에 기능을 요청하면 몇 분 안에 “완료했습니다”라는 답이 돌아옵니다. 그런데 막상 업무에 써 보면 특정 경우에 오류가 나거나, 요청하지 않은 파일까지 바뀌어 있거나, 테스트를 실제로 돌리지 않은 경우가 있습니다. AutoDev가 가장 먼저 세운 원칙은 단순합니다. AI가 했다고 말한 것과 실제로 성공한 것은 다르다는 것입니다.
완료를 다섯 단계로 나눕니다
| 단계 | 의미 | 확인하는 방법 |
|---|---|---|
| 기능 작성 | 코드나 자동화 도구가 만들어진 상태 | 변경 내용 확인 |
| 테스트 통과 | 정해 둔 기준으로 실행해 통과한 상태 | 실제 테스트 실행 결과 |
| 독립 검증 | 개발하지 않은 쪽이 다시 확인한 상태 | 다른 AI의 검토 판정 |
| 운영 반영 | 사람이 승인해 실제 환경에 반영한 상태 | 승인 기록과 반영 확인 |
| 업무 성공 | 실제 업무에서 기대한 결과가 나온 상태 | 운영 후 결과 확인 |
AutoDev는 이 다섯 단계를 따로 기록하고, 어디까지 확인되었는지를 그대로 보고합니다. 테스트를 통과했다고 해서 업무 성공으로 보고하지 않고, 한 가지 경우에서 성공했다고 해서 모든 경우가 검증되었다고 말하지 않습니다.
장치 1: 작업 계약으로 범위를 먼저 고정합니다
개발을 시작하기 전에 작업 계약(Work Contract)을 씁니다. 무엇을 바꿀지, 어떤 파일과 데이터에 손대도 되는지, 무엇을 확인하면 완료로 볼지를 문서로 정하고 사람이 승인합니다. 계약에 없는 파일을 고치려 하면 작업을 멈추도록 설계했습니다. AI가 “이것도 고치는 게 좋겠다”며 범위를 넓히는 일을 막기 위해서입니다.
장치 2: 개발한 AI와 검증하는 AI를 나눕니다
같은 AI가 자기 결과를 스스로 평가하면 놓치는 부분이 생기기 쉽습니다. 그래서 AutoDev는 구현한 쪽과 최종 검증하는 쪽을 다른 AI로 나눕니다. 예를 들어 ChatGPT 계열이 개발했다면 Claude 계열이, Claude 계열이 개발했다면 다른 쪽이 검증하는 식입니다. 사람 조직에서 개발자와 QA 담당자를 나누는 것과 같은 이유입니다.
장치 3: 보정 횟수를 정해 둡니다
검증에서 문제가 나오면 고칩니다. 다만 고치는 횟수에 상한을 둡니다. 문제를 묶어서 정해진 횟수 안에 고치고, 그래도 해결되지 않으면 AI가 계속 시도하게 두지 않고 사람에게 판단을 넘깁니다. 끝없이 고치다가 원래 범위를 벗어나는 일을 막기 위한 장치입니다.
장치 4: 되돌리기 어려운 일은 사람이 승인합니다
운영 환경 반영, 외부 발송, 데이터베이스나 인증 설정 변경처럼 되돌리기 어려운 일은 사람이 승인한 뒤에만 진행합니다. AI가 아무리 잘 검증된 결과를 내도 마지막 반영 여부는 사람이 결정합니다.
실제 제품 개발에서 확인한 것
비즈스프링은 이 체계를 사내 제품 개발에 먼저 적용했습니다. 콘텐츠·데이터 제품을 잇는 실제 업무 흐름에서 작업 계약에 따른 보정, 재검증, 독립 검증, 사람 승인으로 이어지는 구조가 동작하는 것을 확인했고, 이후 다른 업무 흐름에서도 같은 방식을 재사용하고 있습니다. 현재는 AutoDev 체계 자체를 더 만드는 것보다, 이 체계로 실제 개발을 하면서 근거를 쌓는 단계입니다.
가상 사례: “완료했습니다”가 실제로는 어디까지였나
한 회사(가상 사례)가 AI 코딩 도구에 “매일 아침 광고비가 전날보다 크게 늘면 팀 메신저로 알려 주는 기능”을 요청했습니다. AI는 몇 분 만에 “완료했습니다”라고 답했습니다. 같은 요청을 AutoDev 방식으로 다시 점검하면 다음과 같이 나뉩니다.
| 단계 | AI 답변만 믿었을 때 | AutoDev로 확인했을 때(가상) |
|---|---|---|
| 기능 작성 | “완료” | 알림 코드 작성 확인 |
| 테스트 통과 | 확인하지 않음 | 평일 데이터로는 통과, 주말·휴일 데이터에서 계산 오류 발견 |
| 독립 검증 | 없음 | 다른 AI가 “광고비가 0인 날 나눗셈 오류” 지적 |
| 보정 | 없음 | 정해진 횟수 안에서 두 문제를 묶어 수정 후 재검증 통과 |
| 운영 반영 | 바로 반영될 뻔함 | 담당자가 알림 문구와 기준값을 확인한 뒤 승인 |
| 업무 성공 | 알 수 없음 | 2주 동안 실제 알림이 기준대로 오는지 확인 |
AI의 “완료”는 첫 줄에 해당했을 뿐입니다. 실제로 쓸 수 있는 상태가 되기까지 테스트, 독립 검증, 보정, 승인, 운영 확인이 더 필요했습니다.
작업 계약에는 무엇을 적나
| 항목 | 적는 내용(예시) |
|---|---|
| 목표 | 전날 대비 광고비가 정한 비율 이상 늘면 팀 메신저로 알림 |
| 바꿔도 되는 범위 | 알림용 새 파일 하나와 설정 파일 한 줄 |
| 바꾸면 안 되는 것 | 광고 계정 설정, 예산, 기존 보고서 코드 |
| 완료 기준 | 평일·주말·광고비 0원인 날 데이터에서 모두 기대한 결과 |
| 사람 승인이 필요한 일 | 알림 기준값 결정, 실제 메신저 채널 연결 |
| 보정 한도 | 묶음 보정 정해진 횟수, 넘으면 사람에게 판단 요청 |
고객에게 달라지는 점
- 무엇이 바뀌는지 개발 전에 문서로 확인할 수 있습니다.
- 결과를 받을 때 테스트와 독립 검증 결과를 함께 받습니다.
- 어디까지 확인되었고 무엇이 아직 확인되지 않았는지 구분해 보고받습니다.
- 운영 반영은 승인 후에만 진행됩니다.
AutoDev의 개발 방식과 검증·안전 원칙은 사이트의 개발 방식(https://autodev.nunchi.biz/how-it-works/)과 검증·안전 원칙(https://autodev.nunchi.biz/principles/) 페이지에 정리해 두었습니다.