Freshworks가 코딩 에이전트를 다루는 법

1. 왜 이 사례인가

보통 코딩 에이전트는 엔지니어 한 명이 에이전트 하나와 대화하며 코드를 작성하는 방식으로 활용됩니다. Freshworks의 고객 지원 제품인 Freshdesk 엔지니어링 조직은 여기서 한 걸음 더 나아간 구조를 소개합니다. 요구사항을 전달받은 오케스트레이터 에이전트가 업무를 나누고, 역할이 명확히 나뉜 하위 에이전트들이 계획 수립, 코딩, 테스트, PR 작성을 나누어 맡습니다. 엔지니어는 아키텍처 설계, 코드 리뷰, 가드레일 설정, 최종 판단에 집중합니다.

Freshworks 엔지니어링 블로그에서 Ajay Ravichandran은 이를 두고 “엔지니어링 팀은 무엇을, 왜 할지 정하고, 에이전트는 어떻게 할지를 맡는다”고 요약합니다. 이 글은 프레임워크의 구조와 설계 판단을 설명하며, 실제로 이 프레임워크를 통해 프로덕션 수준의 정리(cleanup) 크론 시스템을 구축한 사례를 보여 줍니다.

이 사례를 눈여겨볼 이유는 가드레일을 저장소 안의 파일과 전담 에이전트로 구현한 방식이 구체적이기 때문입니다. 회사 규칙을 모든 에이전트가 코드를 작성하기 전에 먼저 읽는 파일로 두고, 위험한 데이터베이스 작업을 차단하는 에이전트와 부하 안전성을 강제하는 에이전트를 따로 두었습니다. 아울러 Claude가 작성한 코드를 다른 회사의 모델인 OpenAI Codex가 리뷰하도록 설계했습니다. 수백만 건의 고객 요청을 처리하는 대규모 서비스에서 자율 에이전트를 어디까지, 어떤 안전장치로 신뢰할 수 있는지 보여 주는 사례입니다.

2. Problem

해당 글은 소프트웨어 산업이 중대한 전환점에 다가가고 있다고 진단합니다. 수십 년 동안 엔지니어링 생산성을 평가하는 기준은 충분히 검증되고 리뷰된 코드를 팀이 얼마나 빠르게 배포하느냐였으며, 그 코드는 당연히 사람이 작성한다고 전제했습니다. 글은 이러한 전제가 더 이상 유효하지 않다고 말합니다.

글에서 드는 예시는 개발 현장에서 흔히 마주치는 요구사항입니다. 오래된 데이터베이스 레코드를 지우는 자동 실행 정리 크론 프레임워크를 구축하고, 작업 조율과 상태 추적에는 Redis를 활용하는 일입니다. 상세한 명세서도, 사전에 잘게 쪼개 둔 티켓도 없습니다. 기존 방식대로라면 이 요구사항은 기획 회의를 거쳐 한 스프린트 분량의 티켓으로 나뉘고, 여러 엔지니어가 몇 주 동안 맥락을 전환해가며 작업해야 하는 일입니다.

동시에 Freshdesk는 수백만 건의 고객 요청을 처리하는 서비스이므로 안전성과 신뢰성, 엔지니어링 표준 준수를 결코 포기할 수 없습니다. 글에서는 가드레일 없는 자율 에이전트는 혁신이 아니라 부담일 뿐이라고 짚습니다. 글의 예시처럼 WHERE 절이 누락된 삭제 작업은 데이터를 통째로 날려버리고, LIMIT-OFFSET 방식의 대량 삭제는 동일한 연결 풀을 공유하는 쿼리 전체를 느려지게 만듭니다. 요구사항을 에이전트에 안심하고 맡기려면 작업 속도와 더불어 이런 잠재적 위험을 원천 차단하는 장치가 필수적이었습니다.

확인된 사실: 사람이 코드를 쓴다는 전제에 대한 글의 문제 제기, 정리 크론 프레임워크 요구사항(오래된 레코드 삭제, Redis 기반 조율·상태 추적, 상세 명세·티켓 없음), 기존 방식의 기획 회의·스프린트 티켓·수 주의 맥락 전환, 수백만 건의 고객 요청을 처리하는 Freshdesk의 안전성·신뢰성 요구, 가드레일 없는 자율 에이전트는 부담이라는 판단.

3. Solution

3.1 저장소 안의 .ai/ 디렉터리

프레임워크는 대상 저장소 안에 .ai/ 디렉터리를 두고 다음 세 가지 범주의 파일을 관리합니다.

에이전트가 생성한 코드는 모두 동일한 저장소의 src/ 경로에 저장됩니다.

3.2 오케스트레이터와 하위 에이전트

요구사항이 들어오면 곧바로 시스템의 두뇌 역할을 하는 오케스트레이터 에이전트에 전달됩니다. 오케스트레이터는 문제를 세부 단위로 나누어 실행 계획을 세운 뒤, Cursor 같은 도구 환경에서 작동하는 전문 하위 에이전트들에게 작업을 분배합니다. 하위 에이전트는 각자 단일 책임만 맡아, 회사가 정의한 엄격한 가드레일 안에서 자율적으로 작업을 수행합니다.

정리 크론 개발 사례에서 오케스트레이터는 전체 작업을 병렬 워크플로로 나누었습니다. 데이터베이스 에이전트는 스키마 마이그레이션과 삭제 쿼리를 맡고, 워커 에이전트는 Redis 기반 조율과 배치 처리 로직이 포함된 크론 작업을 맡아 비동기로 동시에 진행했습니다. 오케스트레이터는 작업 사이의 의존 관계를 계산해 꼭 필요한 지점에서만 순차적으로 실행되도록 제어했습니다. 커밋 에이전트는 하위 에이전트의 작업 단위에 맞춰 팀 규칙에 부합하는 원자적 커밋을 생성했고, 마지막에는 PR 에이전트가 작업 내용과 상세 설명이 포함된 풀 리퀘스트 하나로 묶어냈습니다.

3.3 가드레일

글에서는 프로덕션 환경에 배포 가능한 수준을 보장하는 장치들을 다음과 같이 설명합니다.

* 규칙(Rules): 모든 에이전트는 코드 작성을 시작하기 전에 반드시 .ai/rules/를 읽어야 합니다. 여기에는 데이터베이스 명명 규칙, 멀티테넌트 데이터 격리 패턴, 테스트 커버리지 기준, 보안 정책처럼 타협할 수 없는 사내 표준이 정의되어 있으며, 에이전트가 이를 임의로 수정할 수 없습니다. 글에서는 이를 두고 Freshdesk의 엔지니어링 문화를 기계가 읽을 수 있는 형태의 가드레일로 구현한 것이라고 설명합니다.

* 스킬(Skills): 조직에 누적된 지식을 정리한 도메인별 실행 가이드입니다. 예를 들어 Redis 패턴 스킬은 Freshdesk 코드베이스에서 TTL 전략을 어떻게 설정하는지, 대량 작업 시 안전한 패턴이 무엇인지, 캐시 무효화 시 발생하는 몰림 현상(thundering herd)을 어떻게 방지하는지 알려 줍니다. 글에서는 이러한 스킬 덕분에 범용 AI 모델도 오랜 경험을 쌓은 Freshdesk 엔지니어처럼 작업할 수 있다고 설명합니다.

* 샌드박스 에이전트: 개발 환경의 보안 계층으로, 모든 에이전트의 동작을 실행 직전에 가로채 검사합니다. WHERE 절이 없는 파괴적 데이터베이스 작업, 프로덕션 접근 정보 열람, Redis 네임스페이스 전체 삭제(flush) 같은 명령은 실행되기 전에 차단됩니다. 디렉터리 구성 예시에서는 safety-agent로 명시되어 있습니다.

* 신뢰성 에이전트: CPU, Redis, 데이터베이스 연결 풀, 하위 소비자를 급격한 부하로부터 보호하는 설계 패턴을 강제합니다. 대표적인 예가 대량 배치 삭제입니다. LIMIT-OFFSET 방식은 구현이 단순하지만, 오프셋 값이 커질수록 데이터베이스가 건너뛸 행을 찾기 위해 방대한 결과 집합을 스캔하므로 동일한 연결 풀을 공유하는 모든 쿼리의 성능을 떨어뜨립니다. 신뢰성 에이전트는 이를 방지하기 위해 커서 기반 페이지네이션을 강제합니다. 마지막으로 처리한 id 이후부터 LIMIT 1000 단위로 삭제하는 방식이어서 첫 번째 배치부터 백만 번째 배치까지 일관된 성능을 유지합니다. 아울러 배치 사이에 대기 시간을 설정해, 트래픽이 몰리는 시간대에도 공유 자원을 독점하지 않고 백그라운드에서 안전하게 나누어 삭제하도록 합니다. 글은 평소 시니어 엔지니어의 숙련도에 의존하던 운영 규율이 에이전트 프레임워크에서는 기본값으로 강제된다고 설명합니다.

* TDD 에이전트: 각 하위 에이전트가 테스트 코드를 먼저 작성하고, 해당 테스트를 통과하는 데 필요한 최소한의 코드만 작성하도록 유도합니다. 글은 이것이 코드의 정확성을 담보할 뿐만 아니라 컨텍스트 창을 의도적으로 관리하는 전략이라고 설명합니다. 에이전트가 자신에게 할당된 테스트 케이스와 공통 규칙만 참고하도록 제한하면 작업 맥락이 작고 명확해져 환각 현상을 줄일 수 있으며, 테스트 자체가 명세서 구실을 하게 됩니다.

* 리뷰어 에이전트의 교차 모델 리뷰: 코드는 Claude가 작성하고, 코드 리뷰는 의도적으로 다른 모델인 OpenAI Codex에 맡깁니다. 글에 따르면 모델이 자신이 생성한 결과물을 직접 평가할 경우, 자체적인 전제를 무비판적으로 수용하고 평소 자주 범하는 실수를 그대로 지나치는 경향이 있습니다. 학습 데이터와 구조적 편향이 서로 다른 별도의 모델을 배치함으로써 견제와 균형을 갖춘 리뷰 루프가 만들어지며, Codex는 Claude가 놓치기 쉬운 미세한 성능 안티패턴, 예외 처리 누락, 기존 사내 규칙과의 불일치 등을 효과적으로 잡아냅니다.

3.4 사람의 리뷰와 스테이징 검증

리뷰어 에이전트가 검토를 마치고 승인하면, PR 에이전트가 구현 내용, 핵심 설계 판단의 이유, 각 컴포넌트 간의 연계 방식을 정리해 풀 리퀘스트를 생성합니다. 인간 엔지니어는 이 시점에 개입하여 코드를 리뷰합니다. 에이전트가 작성한 코드는 실제 프로덕션에 반영되기 전에 사람이 작성한 코드와 동일하게 사전 운영(staging) 환경에서 필수 스테이징 검증 단계를 통과해야 합니다. 글은 이 최종 관문이 존재함으로써 “자율”이 결코 “검증 없음”을 뜻하지 않게 된다고 강조합니다.

확인된 사실: .ai/의 rules·skills·agents 구성과 예시 파일, Cursor 같은 도구 안에서 돌아가는 하위 에이전트, 정리 크론 예의 작업 분할(데이터베이스·워커 에이전트 병렬, 필요한 곳만 순차, 커밋 에이전트의 원자적 커밋, PR 에이전트), 규칙 선독과 그 내용, Redis 패턴 스킬, 샌드박스 에이전트가 막는 작업, 커서 기반 페이지네이션과 배치 간 대기, TDD와 컨텍스트 관리, Claude 작성·OpenAI Codex 리뷰, 사람 리뷰, 필수 스테이징 검증.

4. Impact

이 글은 도입 규모나 개발 속도, 결함률 같은 정량 지표를 제시하지 않습니다. 그 대신 프레임워크를 통해 얻은 구체적인 산출물과 업무 방식의 근본적인 변화를 중점적으로 설명합니다.

글이 제시하는 실제 결과물은 이 프레임워크를 통해 구축된 프로덕션 수준의 정리 크론 시스템입니다. 기존 방식대로라면 기획 회의와 한 스프린트 분량의 티켓, 몇 주에 걸친 맥락 전환이 불가피했을 요구사항이었습니다. 하지만 이번 사례에서는 별도의 상세 명세나 티켓 없이도 오케스트레이터에 전달되어 병렬 작업, 원자적 커밋, 상세한 설명이 포함된 PR로 완성되었습니다. 결과물에는 커서 기반 배치 삭제와 배치 간 대기 시간 설정 등 신뢰성 에이전트가 요구하는 엄격한 운영 패턴이 충실히 반영되었습니다.

글은 개발 조직의 역할 구분이 다음과 같이 재편된다고 정리합니다.

글은 이러한 변화가 개발자를 대체하는 흐름이 아니라, 개발자가 가치를 더하는 영역을 한 단계 끌어올리는 과정이라고 평가합니다. 앞으로 이 같은 전환을 이끌 엔지니어는 단순한 타이핑 속도가 아니라, 정교한 에이전트 시스템을 설계하는 역량, 실효성 있는 규칙을 수립하는 능력, 나아가 기계에 위임할 영역과 사람이 직접 검토해야 할 영역을 명확히 구분해 내는 판단력으로 평가받게 될 것이라고 전망합니다.

확인된 사실: 정량 지표 없음, 프로덕션 수준 정리 크론 시스템이라는 적용 예, 기존 방식과의 작업 흐름 비교, 역할 변화 네 가지, 개발자 대체가 아니라는 글의 입장.

5. Insight

가드레일은 프롬프트가 아니라 저장소의 파일과 전담 에이전트로 둡니다. Fresh