AI 에이전트가 이슈 85%를 줄였어요 | 성과가 갈린 자리
클라우드플레어가 오픈소스 프로젝트 깃허브 이슈를 200건대에서 30건 안팎으로 줄였어요. 국내에선 농심그룹이 14개 계열사·7개 해외법인 업무를 AI 전환으로 재편했고요. 두 사례에서 성과를 만든 3가지를 정리했어요.
핵심 요약 — 이번 주 나온 숫자 하나가 눈에 띄었어요. 클라우드플레어가 오픈소스 프레임워크 Astro의 깃허브 이슈를 200건대에서 30건 안팎까지, 약 85% 줄였다고 밝혔어요. 국내에서는 농심그룹이 국내 14개 계열사와 해외법인 7곳의 업무 체계를 AI 전환으로 재편했다는 소식이 나왔고요. 두 사례를 나란히 놓고 보면 성과를 만든 건 에이전트의 성능이 아니라 그 앞에 깔아둔 세 가지였어요. 사람이 확인하는 관문, 미리 정리해둔 데이터, 그리고 에이전트가 멈춰도 업무가 굴러가는 구조예요. 직접 만들고 자체 SaaS를 운영해온 개발사 기준으로 정리했어요.
📰 2026년 8월 23일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.
“AI 에이전트 도입하면 얼마나 줄어드나요?”
요즘 상담에서 가장 자주 듣는 질문이에요. 그런데 답하기가 늘 애매했어요. 사례로 도는 숫자는 대부분 도구를 만든 회사가 낸 자료였거든요. 이번 주에는 조금 다른 게 나왔어요. 실제로 굴러가는 오픈소스 저장소에서 나온 숫자였고, 어디서 실패했는지까지 같이 공개됐어요.
1. 이번 주 나온 숫자 — 이슈 200건이 30건이 됐어요
클라우드플레어는 웹 프레임워크 Astro의 이슈 처리에 AI 에이전트를 붙였어요. 쌓여 있던 열린 이슈가 200건이 넘었는데, 지금은 30건 안팎이에요. 감소율로는 약 85%고, 팀은 0건을 목표로 두고 있다고 밝혔어요.
구조가 흥미로워요. 하나의 큰 에이전트가 다 하는 방식이 아니라, 역할을 넷으로 쪼갰어요.
| 역할 | 하는 일 |
|---|---|
| 재현 | 신고된 증상이 실제로 재현되는지 확인해요 |
| 진단 | 코드에 계측을 붙여 원인이 되는 지점을 좁혀요 |
| 검증 | 관련 테스트·문서·기존 코멘트를 살펴요 |
| 수정 | 재현 절차를 테스트로 바꾸고 수정안을 만들어요 |
넷은 하나의 기억을 공유하지 않아요. report.md라는 파일에 각자 결과를 적어 넘겨요. 사람으로 치면 회의 대신 인수인계 문서를 쓰는 방식이에요. 앞 단계가 무엇을 근거로 그렇게 판단했는지 뒤 단계가 눈으로 확인할 수 있어요.
2. 자동으로 고친 게 아니라, 사람이 확인하는 관문이 있었어요
기사에서 가장 눈여겨본 대목은 감소율이 아니라 이 부분이었어요. 에이전트가 수정안을 만들었다고 바로 반영되지 않아요.
흐름은 이래요. 에이전트가 고칠 방법을 찾으면 미리보기 버전을 만들어 해당 이슈에 결과를 올려요. 그러면 처음 문제를 신고한 사람이 그 패치가 실제로 자기 문제를 해결했는지 확인해요. 확인이 끝나야 비로소 봇이 코드 반영 요청을 열어요. 사람 검토자에게는 이 과정을 다 통과한 것만 올라와요.
진행 상태는 깃허브 라벨로 관리해요. 분류 필요에서 수정 검증됨까지 라벨이 곧 상태값이고, 에이전트는 라벨을 보고 다음에 무엇을 할지 정해요. 상태가 화면에 그대로 보이니 사람이 언제든 끼어들 수 있어요.
저희가 상담에서 자주 드리는 말이 이거예요. 에이전트를 붙일 때 정말 설계해야 하는 건 에이전트가 아니라 에이전트가 만든 결과를 누가, 무엇을 보고 통과시킬지예요. 이 관문이 없으면 결과물을 아무도 믿지 못해서 결국 사람이 처음부터 다시 봐요. 그러면 일은 줄지 않고 늘어요.
3. 에이전트가 실패한 자리가 곧 코드의 약한 자리였어요
성과만 나온 게 아니에요. 한계도 같이 공개됐어요.
테스트가 충분하지 않은 코드에서 에이전트가 조건문을 반복해서 고치다가 멀쩡히 돌던 기능을 망가뜨린 일이 있었어요. 그런데 해결 방법이 의외였어요. 그 코드에 설명 주석을 붙였더니 에이전트의 행동이 달라졌고 같은 실패가 반복되지 않았어요.
이걸 두고 기사는 이렇게 정리했어요. 에이전트는 코드베이스가 얼마나 잘 관리돼 있는지를 드러낸다고요. 저희 경험과도 맞아요. 사람 신입이 헤매는 자리와 에이전트가 헤매는 자리는 대체로 같아요. 왜 이렇게 짰는지 아무도 설명하지 못하는 코드, 테스트가 없어서 고쳤을 때 뭐가 깨지는지 알 수 없는 코드예요.
운영사 Tip — 에이전트 도입 검토 전에 짧게 확인해볼 게 있어요. 지금 우리 시스템에서 코드를 한 줄 고쳤을 때, 뭐가 깨졌는지 사람이 몇 분 만에 알 수 있나요? 그 답이 “돌려봐야 안다”면 에이전트를 붙여도 같은 속도로 굴러가요. 검증할 방법이 없는 자리에서는 사람이든 에이전트든 느려져요.
4. 국내에서는 도구보다 데이터 정리가 먼저였어요
같은 주에 국내 소식도 나왔어요. 메가존소프트가 농심그룹의 구글 워크스페이스 기반 AI 전환 체계를 구축했다고 밝혔어요. 범위는 국내 계열사 14곳과 해외법인 7곳이에요.
여기서 실제로 한 일이 무엇인지 보면 그림이 잡혀요. 기존 데이터를 구글 드라이브로 옮기고, 예전부터 쓰던 시스템과 외부 솔루션을 새 환경에 연결하고, 그 위에서 업무 방식을 다시 짜는 순서였어요. AI 모델을 고르는 일은 여기 목록에 없어요.
이게 기업 AI 도입의 실제 모습에 더 가까워요. 자료가 어디에 흩어져 있고 누가 볼 수 있는지가 정리되지 않으면, 그 위에 무엇을 얹어도 대답이 부정확해요. AI가 참고할 자료가 3년 전 파일이면 3년 전 답이 나오니까요.
관련해서 데이터 정리가 왜 AI 도입의 첫 관문인지는 AI 도입 전 데이터 정리 이야기에서 더 자세히 다뤘어요.
5. 그래서 도입 순서가 뒤집혀요 — 도구는 세 번째예요
두 사례를 겹쳐 보면 순서가 보여요. 대부분의 회사는 도구부터 고르는데, 성과가 난 곳은 반대였어요.
| 순서 | 하는 일 | 이 단계에서 정할 것 |
|---|---|---|
| 1 | 맡길 업무 고르기 | 절차가 반복되고, 잘했는지 판정 기준이 분명한 업무인가요 |
| 2 | 자료·권한 정리 | 참고할 자료가 최신인가요. 어디까지 열어줄 건가요 |
| 3 | 도구 선택 | 위 두 가지가 정해진 뒤에 골라도 늦지 않아요 |
| 4 | 확인 관문 만들기 | 결과를 누가, 무엇을 보고 통과시키나요 |
| 5 | 멈췄을 때 대비 | 에이전트가 안 돌아도 업무가 이어지나요 |
특히 1번에서 많이 갈려요. “판정 기준이 분명한가”를 넘기고 시작하면, 결과가 맞는지 사람마다 다르게 말하게 돼요. 그 순간부터는 자동화가 아니라 검토 회의가 늘어나요.
5번도 자주 빠져요. 에이전트가 멈추는 상황은 생각보다 자주 와요. 외부 서비스 점검, 사용량 한도, 요금제 변경 같은 이유로요. 그때 업무가 통째로 멈추면 도입 전보다 위험해져요.
6. 우리 회사에서 먼저 확인할 5가지
검토 단계에서 저희가 실제로 여쭤보는 것들이에요. 기술 질문이 아니라 업무 질문이라, 개발을 몰라도 답할 수 있어요.
- 이 업무는 한 달에 몇 번 반복되나요? 횟수가 적으면 붙이는 비용이 회수되지 않아요.
- 결과가 맞았는지 누가 판정하나요? 판정자가 정해지지 않은 업무는 아직 자동화 대상이 아니에요.
- 참고 자료는 어디 있고, 최신인가요? 흩어져 있으면 그걸 모으는 게 1단계 일이에요.
- 틀렸을 때 무슨 일이 벌어지나요? 내부 참고 자료면 가볍고, 고객에게 나가는 문서면 관문을 더 둬야 해요.
- 에이전트가 멈추면 그 업무는 어떻게 되나요? 대체 경로를 미리 정해두세요.
직접 운영해보니 — 저희도 자체 SaaS 4종을 운영하면서 반복 업무 일부를 에이전트에 넘겨봤어요. 효과가 확실했던 건 판정 기준이 기계적인 것들이었어요. 예를 들면 결과물이 규격에 맞는지 검사하는 일이요. 반대로 “이 정도면 괜찮은가”를 사람이 판단해야 하는 일은 넘겨도 검토 시간이 그대로였어요.
헷갈리는 말부터 정리해볼까요
AI 에이전트 — 질문에 답만 하는 게 아니라, 목표를 주면 도구를 써서 여러 단계를 스스로 진행하는 프로그램이에요. 파일을 읽고, 명령을 실행하고, 결과를 보고 다음 행동을 정해요. 실무에선 “챗봇은 답을 주고, 에이전트는 일을 한다” 정도로 구분해요.
AX(AI 전환) — 업무 방식 자체를 AI를 전제로 다시 짜는 걸 말해요. 기존 방식에 AI를 얹는 게 아니라, 자료가 놓인 자리와 결재 흐름까지 바꾸는 범위예요. 농심그룹 사례가 여기 해당해요.
사람 확인 관문(Human-in-the-loop) — 자동 처리 중간에 사람이 확인하고 통과시키는 지점을 두는 방식이에요. 실무에선 “어디에 관문을 둘지”가 곧 위험 관리라 견적 단계에서 같이 정해요.
7. 운영까지 보면 무엇이 달라질까요
납품으로 끝나는 자동화와 계속 돌아가는 자동화는 다르다고 생각해요. 차이가 나는 자리는 대개 셋이에요.
첫째, 사용량과 비용이 움직여요. 모델 요금제는 자주 바뀌고 사용량은 업무량을 따라 늘어요. 처음 견적의 월 비용이 6개월 뒤에도 같을 거라고 보면 곤란해요. 계약할 때 사용량 상한과 초과 시 처리 방식을 정해두는 편이 안전해요.
둘째, 결과 품질이 조용히 나빠질 수 있어요. 참고 자료가 낡거나 업무 규칙이 바뀌었는데 에이전트만 그대로면 답이 어긋나요. 그런데 이건 오류 메시지가 뜨지 않아서 한참 뒤에 발견돼요. 정기적으로 표본을 뽑아 확인하는 절차를 운영에 넣어두세요.
셋째, 사람이 그 일을 못 하게 될 수 있어요. 몇 달 자동으로 돌리다 보면 원래 절차를 아는 사람이 없어져요. 에이전트가 멈췄을 때 손으로 처리할 수 있는 사람이 남아 있는지도 운영 항목이에요.
AI 도입 비용이 실제로 어디에서 붙는지는 AI 도입 비용 가이드에, 에이전트에 계정 권한을 열어줄 때 정할 것들은 권한 범위 정리 글에 따로 정리해뒀어요.
8. 자주 묻는 질문
AI 에이전트를 도입하면 우리 회사도 업무가 85% 줄어드나요?
그 숫자는 오픈소스 프로젝트의 깃허브 이슈 처리에서 나온 값이라, 업무 전체가 85% 줄었다는 뜻이 아니에요. 클라우드플레어가 줄인 건 재현하고, 원인을 좁히고, 고쳐졌는지 검증하는 반복 절차였어요. 우리 회사에 옮겨보려면 그만큼 절차가 반복적이고 판정 기준이 분명한 업무가 무엇인지부터 찾아야 해요.
AI 도입은 도구를 먼저 정해야 하나요, 데이터를 먼저 정리해야 하나요?
데이터와 절차가 먼저예요. 클라우드플레어 사례에서 에이전트가 같은 자리에서 반복 실패한 원인은 테스트가 부족한 코드였고, 사람이 설명을 덧붙이자 행동이 달라졌어요. 농심그룹도 계열사 데이터를 옮기고 기존 시스템을 연결하는 작업이 먼저였고요. 순서를 뒤집으면 좋은 도구를 붙여놓고도 결과를 믿지 못해 다시 사람이 전부 확인하게 돼요.
AI 에이전트 도입을 외부 개발사에 맡기면 무엇을 맡기게 되나요?
모델을 고르는 일보다 그 앞뒤를 붙이는 일이 대부분이에요. 사내 데이터를 어디까지 넘길지 정하고, 기존 시스템과 연결하고, 결과를 사람이 확인하는 관문을 만들고, 멈췄을 때 업무가 이어지도록 대체 경로를 두는 작업이에요. 견적에서도 모델 사용료보다 이 연결·검증 부분이 기간과 비용을 크게 좌우해요.
9. 마무리 — 숫자보다 그 앞에 깔아둔 것을 보세요
이번 주 사례에서 저희가 얻은 건 85%라는 숫자가 아니라, 그 숫자 앞에 무엇이 있었는지였어요. 역할을 쪼갠 구조, 신고자가 직접 확인하는 관문, 실패를 숨기지 않고 코드 설명을 보강한 대응이요. 농심 사례에서도 눈에 띈 건 데이터를 옮기고 기존 시스템을 연결한 준비 과정이었고요.
AI 에이전트를 어디부터 붙여야 할지 아직 흐릿해도 괜찮아요. 오히려 그 단계에서 업무를 같이 들여다보는 게 순서를 덜 꼬이게 해요. 어떤 업무부터 맡길지 같이 짚어볼까요 →
저희는 10년 넘게 50개가 넘는 프로젝트를 진행하면서 자체 SaaS 4종을 직접 기획하고 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고, AI 마케팅 CDP(고객 데이터 플랫폼)를 직접 만들어 굴려보며 데이터가 정리되지 않은 상태에서 무엇이 어긋나는지도 겪어봤어요.
함께 보면 좋은 글
참고: 클라우드플레어의 Astro 이슈 처리 사례는 InfoQ 2026년 8월 보도, 농심그룹 AI 전환 구축 소식은 AI타임스 2026년 8월 보도를 근거로 정리했어요.