MerciYanis의 AI 백로그 실험

요약

• MerciYanis는 실제 백로그 티켓을 코딩 에이전트에 맡겨 성능을 측정했습니다.
• 약 95% 머지율과 최대 32배의 속도를 얻었으나 병목은 리뷰로 옮겨갔습니다.
• 에이전트 도입의 성패는 모델 성능보다 사내 문서화와 격리 인프라에 달렸습니다.

감이 아닌 실제 업무를 에이전트에게 맡기다

새로운 인공지능 모델이 나올 때마다 업무 방식이 완전히 바뀐다는 소문이 무성하지만, 정작 개발 현장에서는 자동 완성 기능이나 일회성 코드 개선에 머무르는 경우가 많습니다. 복잡한 실제 업무를 인공지능에게 통째로 맡겼다가는 내부 규칙을 무시한 엉성한 코드가 쏟아져 결국 사람이 수습하느라 시간을 다 보내기 일쑤이기 때문입니다.

스마트 오피스와 사물인터넷(IoT) 기반 시설 운영 관리 소프트웨어를 만드는 프랑스의 25인 기업 MerciYanis는 다른 길을 택했습니다. 이 회사의 최고기술책임자(CTO) Matthieu Jabbour는 2026년 4월 회사 엔지니어링 블로그를 통해, 막연한 기대 대신 실제 스프린트 백로그를 에이전트에게 맡겨 검증한 실험 결과를 공개했습니다. 백로그는 개발팀이 앞으로 해결해야 할 작업 목록을 뜻합니다.

2025년 11월 Opus 4.5와 GPT-5.2가 출시되자, MerciYanis는 사람 엔지니어와 에이전트를 같은 작업 티켓에 나란히 배치했습니다. 갓 졸업한 신입부터 수십 년 경력을 갖춘 시니어까지 폭넓게 구성된 제품 팀은 평소 진행하던 정기 개발 주기인 스프린트를 그대로 따르며 실험을 이어갔습니다. 엔지니어들이 평소에 받던 가공되지 않은 사용자 요구사항과 화면 캡처, 디자인 파일, 화면 설계도를 에이전트에게 그대로 넘겼고, 통과 기준도 사람과 똑같이 변경된 코드를 자동으로 검증하는 지속적 통합(CI) 품질 검사를 통과하고 동료 엔지니어에게 코드 검토를 요청해 승인을 얻는 풀 리퀘스트(PR) 과정을 엄격히 거치도록 했습니다. 이와 함께 실험 과정에서 사람과 에이전트 사이에 피드백이 오간 횟수와 전체 토큰 청구 비용도 모두 기록했습니다.

세 가지 암초: 맥락 부재, 인프라 충돌, 부서 간 단절

실험 초기에는 에이전트를 실무에 곧바로 투입하기 어려운 세 가지 구조적 걸림돌이 드러났습니다.

첫째는 맥락이 없는 에이전트가 만들어 내는 엉성한 코드였습니다. 전체 시스템 구조나 사내에서 특정 라이브러리를 쓰지 못하게 막아 둔 이유를 모르는 에이전트는 어떻게든 작동만 하는 상태를 만들려고 제멋대로 판단을 내렸습니다. 겉으로는 돌아가지만 장기적으로 아키텍처를 망가뜨리는 코드가 쌓였습니다. Matthieu Jabbour는 “팀이 이해하지도 통제하지도 못하는 코드를 내보내는 것은 제품을 외주 주는 것과 같고, 첫 장애나 데이터 이전, 규모 확장 때 반드시 대가를 치른다”고 지적했습니다.

둘째는 동시 작업에서 터져 나온 데이터베이스 충돌이었습니다. 사람은 보통 한 번에 하나의 작업 브랜치에서 일하지만, 에이전트는 수십 개 세션이 동시에 병렬로 돌아갑니다. 단순히 Git worktree 기능으로 코드 작업 공간을 나누는 정도로는 여러 저장소와 공유 인프라를 감당할 수 없었습니다. 특히 여러 에이전트가 하나의 테스트 데이터베이스에 테이블 구조를 바꾸는 스키마 마이그레이션을 실행하자, 데이터 상태가 꼬이면서 모든 작업이 연쇄적으로 멈추는 사태가 벌어졌습니다.

셋째는 고객 접점 부서와 엔지니어링 사이의 소통 단절이었습니다. 25명 규모의 작은 조직이었지만, 영업팀이나 고객 성공 매니저(CSM)가 고객을 만나 듣고 온 요구사항이 실제 제품에 반영되기까지는 오랜 시간이 걸렸습니다. 개발 지식이 없는 비즈니스 담당자에게 Docker 환경을 띄우거나 소스코드를 내려받아 테스트해 보라고 요구할 수는 없었기 때문입니다.

암묵지를 실행 가능한 코드로 바꾼 Handbook

MerciYanis는 에이전트에게 맥락을 제공하기 위해 사내 지식 관리 도구인 Notion에 흩어져 있던 지식을 모두 모아 마크다운 형태의 저장소인 Handbook을 구축했습니다. 신입 엔지니어가 입사 후 첫 석 달 동안 체득해야 할 모든 맥락을 에이전트에게 사전에 전달하려는 목적이었습니다. 이 저장소에는 엔지니어링 기본 원칙, 시스템 아키텍처, 코드베이스 경계, 인프라 배포 기준, 모범 개발 사례, 단위 테스트 작성 규칙이 체계적으로 담겼습니다.

MerciYanis는 코딩 도구인 Claude Code에 사용자 정의 슬래시 명령인 /fix를 만들고, 에이전트가 정해진 순서를 반드시 지키도록 강제했습니다. 에이전트는 작업을 시작하면 먼저 2장을 읽고 서비스 경계를 파악해야 합니다. 이어서 5장을 확인해 프로젝트에서 허용된 라이브러리와 설계 패턴만 골라냅니다. 다음으로 로컬 환경에서 버그를 재현하고, 재현에 실패하면 작업을 즉시 중단합니다. 버그 수정은 코드 변경 폭을 가장 작게 줄여 진행하며, 8장을 읽고 단위 테스트를 작성합니다. 마지막으로 전체 테스트 스위트를 돌려 성공했을 때만 9장의 규칙에 따라 PR을 생성합니다.

/fix 명령의 일곱 단계 순서

지침을 문서로 남기는 데 그치지 않고 개발 도구의 명령어 실행 흐름에 직접 연결하자, 에이전트가 만든 결과물의 품질은 “대부분 프로덕션 수준에 가까움”에서 “거의 100% 품질”로 향상되었습니다.

5분 만에 전체 시스템을 복제하는 격리 인프라

수십 개의 에이전트 세션이 서로의 작업을 방해하지 않도록, MerciYanis는 명령어 한 번으로 전체 플랫폼을 복제하는 인프라를 구축했습니다. 초기 데이터가 채워진 데이터베이스, 메시지 브로커인 Kafka, 모든 마이크로서비스, 소스코드에서 직접 빌드한 사내 공용 라이브러리까지 전체 스택이 5분 안에 작동합니다. 에이전트 세션마다 독립된 전용 컨테이너 환경이 만들어지고, 작업이 끝나면 흔적 없이 삭제되므로 스키마 변경이나 데이터 조작이 다른 세션에 영향을 주지 않습니다.

여기에 오픈소스 리버스 프록시 도구인 Traefik의 동적 라우팅을 결합했습니다. 덕분에 서버 한 대 안에서 수십 개의 독립된 환경이 포트 충돌 없이 각자 고유한 주소로 원활하게 동작합니다.

실제로는 작업 요청이 들어올 때마다 고유한 작업 식별자를 기반으로 도커 환경을 찍어내는 오케스트레이션 스크립트가 실행되었을 가능성이 높습니다. 미리 준비된 데이터베이스 스냅샷을 마운트해 초기 구동 시간을 초 단위로 줄이고, 컨테이너 레이블에 Traefik 주소를 동적으로 주입해 라우팅 테이블을 실시간으로 갱신했을 것입니다. 작업이 끝나면 컨테이너와 임시 저장소를 즉시 정리해 서버 자원을 회수하는 방식으로 설계했을 것입니다.

이러한 환경 복제 자동화는 사람에게도 큰 혜택을 주었습니다. 과거에는 신입 엔지니어가 입사해 첫 PR을 올리기까지 4일이 걸렸으나, 2025년에는 1시간 미만으로 줄었고, 지금은 스택 구동 5분을 포함해 10분 미만으로 단축되었습니다. 사람이 일하기 좋은 환경을 만드는 투자가 에이전트가 일하기 좋은 토대가 된 셈입니다.

Slack 봇으로 완성한 전사 기능 제작과 뜻밖의 발견

MerciYanis는 개발자가 아닌 직원들도 에이전트를 다룰 수 있도록 Slack 봇을 만들었습니다. 에이전트 스택이 독립된 전용 서버에서 돌고 있기 때문에 사용자 PC에 개발 환경을 설치할 필요가 전혀 없습니다.

디자이너, 프로덕트 매니저(PM), 영업 담당자, CSM이 Slack에서 봇을 호출해 요구사항을 입력하면, 시스템은 새로운 복제 환경을 띄우고 에이전트를 구동합니다. 작업이 끝나면 수정된 웹 애플리케이션과 관리자 화면(백오피스)의 실시간 미리보기 주소를 Slack 스레드에 바로 전달합니다. 비개발 직군도 실제 작동하는 화면을 직접 눌러 보며 공개 스레드에서 피드백을 주고받을 수 있게 되었습니다. 2026년 3월 전사 도입 이후 매주 약 15건의 새로운 요청이 Slack 봇을 통해 접수되고 있습니다.

비동기 작업 큐를 통해 Slack 요청을 처리하고 미리보기 주소를 스레드에 응답했을 가능성이 높습니다. 그런데 운영 과정에서 뜻밖의 쓰임새가 나타났습니다. Slack 봇이 사내 코드베이스를 바탕으로 실시간 질문에 답하는 도구로 진화한 것입니다. 영업팀은 고객사와의 계약 과정에서 필요한 보안 인증 현황, 개인정보 처리 방식, 외부 협력업체 서비스 사용 여부 같은 복잡한 컴플라이언스 질문을 엔지니어링팀에 묻지 않고도 정확하게 확인해 답할 수 있게 되었습니다.

실제로 이 Slack 봇은 코드베이스와 전체 시스템 설계에 관한 질문을 받으면 이를 비즈니스 현장에서 쓰는 업무 용어로 알기 쉽게 바꾸어 설명해 줍니다. 이러한 코드 질의응답을 처리할 때는 전체 작업 환경을 매번 새로 띄우지 않고, main 브랜치의 최신 코드와 사내 안내 문서인 Handbook 마크다운 문서를 검색하여 답변을 조합해 냈을 가능성이 높습니다.

숫자로 증명된 효율과 새로운 병목의 등장

MerciYanis가 진행한 백로그 벤치마크 결과, 에이전트가 올린 티켓의 최종 머지율은 약 95% 수준에 도달했습니다. 속도 면에서는 시니어 엔지니어의 예상 소요 시간 대비 최대 약 10배, 주니어 엔지니어 대비 최대 약 32배 빨랐습니다. 티켓의 성격에 따라 차이는 있었는데, 단순 반복 코드를 다루는 보일러플레이트 티켓에서는 최대 86배까지 빨라진 반면, 복잡한 비즈니스 규칙이 얽힌 도메인 로직 티켓에서는 약 5배 수준의 차이를 보였습니다.

대표적인 티켓 14개를 묶어 분석한 결과, 주니어 엔지니어가 작업했다면 7,200분, 시니어 엔지니어가 작업했다면 2,190분이 걸렸을 분량을 에이전트는 220분 만에 마쳤습니다. 이때 들어간 모델 토큰 비용은 총 84.05유로였으며, 머지된 PR 하나당 지출된 토큰 비용의 중앙값은 3유로 미만이었습니다. 대다수 티켓은 사람이 0회에서 1회 정도의 피드백만 주고 바로 머지 승인을 받았습니다. 표본 중 피드백이 가장 많았던 작업은 복잡한 일정 반복 규칙을 다루는 버그 티켓으로 5회의 피드백이 오갔습니다.

대표 티켓 14개 소요 시간 비교

작업 속도가 10배 빨라지자 조직의 병목은 코드를 짜는 과정에서 다른 곳으로 완전히 이동했습니다. PR 발행량이 평소보다 약 10배 폭증하면서 코드를 검토하는 코드 리뷰와, 수많은 프로토타입 중 어떤 것을 실제 서비스에 반영할지 결정하는 제품 판단이 새로운 병목이 되었습니다. MerciYanis는 밀려드는 PR을 감당하기 위해 자동 CI 리뷰, 보안 취약점 검사, 에이전트가 먼저 코드를 교차 검토하는 사전 리뷰 방식을 시험하고 있습니다.

코드를 쓰는 사람에서 제품과 플랫폼을 짓는 사람으로

MerciYanis의 사례는 개발 조직에서 사람의 역할이 어떻게 변하는지 명확히 보여줍니다. 코딩 자체가 자동화되면서 엔지니어의 업무는 크게 두 축으로 나뉘어 가고 있습니다. 고객 문제를 정의하고 어떤 기능을 만들어야 할지 결정하는 제품 빌더(Product Builder), 그리고 수많은 에이전트가 코드를 쏟아내도 시스템 구조가 무너지지 않도록 규칙과 인프라를 지탱하는 플랫폼 엔지니어(Platform Engineer)입니다.

이 실험이 비개발 직군과 기업 리더에게 주는 교훈은 명확합니다. 최신 AI 모델을 구독한다고 해서 곧바로 조직의 생산성이 올라가지 않습니다. 에이전트가 길을 잃지 않도록 사내 규칙과 맥락을 문서로 정돈하고, 에이전트가 마음껏 실패하고 검증할 수 있는 격리된 작업 인프라를 갖추는 일이 먼저입니다. 사람을 위한 온보딩 환경을 닦아 두는 것이 곧 인공지능 전환(AX)을 성공으로 이끄는 지름길입니다.

---

출처

MerciYanis Engineering Blog — Going AI-Native: How We Handed Our Backlog to Agents — https://engineering.merciyanis.com/blog/going-ai-native-how-we-handed-our-backlog-to-agents — 2026-04-20