Freshworks, Claude를 Codex로 검증

요약

• Freshworks는 기계가 읽는 규칙과 전문 에이전트 체계를 구축했습니다.
• Claude가 작성한 코드를 OpenAI Codex가 교차 검증하도록 설계했습니다.
• 개발자는 코드 작성자에서 시스템 규칙을 설계하는 아키텍트로 이동합니다.

명세서와 작업 티켓 없이 개발을 시작하는 방법

개발자가 인공지능 도구와 대화하며 코드 한 줄씩 완성해 가는 방식은 이미 흔한 풍경이 되었습니다. 하지만 복잡한 서비스 환경에서 기획 회의도 거치지 않고, 잘게 쪼갠 티켓도 없이 요구사항 문장 하나만으로 엔지니어링 작업을 완수할 수 있을까요?

수백만 건의 고객 요청을 처리하는 고객 지원 솔루션 Freshdesk를 운영하는 Freshworks는 이 질문에 대해 새로운 소프트웨어 개발 방식을 제시했습니다. Freshworks 엔지니어링 블로그에서 Ajay Ravichandran은 “엔지니어링 팀은 무엇을 왜 만들어야 하는지 정의하고, 에이전트는 어떻게 만들 것인지를 다룹니다.”라고 설명합니다. 개발자가 직접 코드를 작성하고, 테스트하고, 검토하던 기존 작업 흐름을 자율 에이전트 시스템으로 전환한 것입니다.

글은 소프트웨어 산업이 전환점에 다가가고 있다고 진단합니다. 수십 년 동안 엔지니어링 생산성은 팀이 잘 테스트되고 잘 리뷰된 코드를 얼마나 빨리 내보내느냐로 측정되었고, 그 코드는 사람이 쓴다는 것이 암묵적 전제였습니다. 글은 이 전제가 더 이상 맞지 않는다고 말합니다.

이 시스템이 시험대에 오른 과제는 데이터베이스에서 오래된 레코드를 주기적으로 지우는 자동 실행 정리 크론 프레임워크 개발이었습니다. 작업 조율과 상태 추적에는 분산 메모리 저장소인 Redis를 사용하는 조건이 붙었습니다. 상세한 기술 명세나 작업 티켓은 전혀 주어지지 않았습니다.

기존 방식이었다면 기획 회의를 열고, 한 스프린트 분량의 티켓을 발행한 뒤, 여러 엔지니어가 몇 주 동안 맥락 전환을 겪으며 처리해야 했을 일입니다. 하지만 수백만 건의 요청이 오가는 대규모 서비스에서는 속도만큼이나 안전성이 중요합니다. 가드레일 없는 자율 에이전트는 발전이 아니라 회사의 거대한 부담이 될 수 있기 때문입니다.

저장소 안의 규칙과 전문화된 실행 체계

Freshworks는 에이전트가 제멋대로 행동하지 못하도록 통제권을 프롬프트 창 바깥의 코드 저장소 안에 두었습니다. 대상 저장소의 .ai/ 디렉터리 안에 세 가지 핵심 범주를 구성했습니다.

첫 번째는 rules/입니다. 항상 적용되며 에이전트가 덮어쓸 수 없는 전사 표준 파일들이 담깁니다. 코드 품질, 테스트 커버리지 기준, PR 기대치를 정의한 엔지니어링 가이드라인을 비롯해 언어별 스타일 가이드, 데이터베이스 표준(이름 규칙, 인덱스 생성, 마이그레이션 정책), 보안 가이드라인(인증, 비밀 정보 관리, 데이터 처리 규칙)이 포함됩니다. Freshdesk의 엔지니어링 문화를 기계가 읽을 수 있는 가드레일로 바꾼 셈입니다.

두 번째는 skills/입니다. 에이전트가 작업 상황에 맞춰 필요할 때 불러오는 재사용 플레이북입니다. 백그라운드 작업 규칙(크론 규칙, 재시도 로직, 멱등성 유지), 안전한 스키마 마이그레이션 및 롤백 패턴, 캐싱 패턴(캐시 무효화, 데이터 만료 시간인 TTL 전략, 스탬피드 방지) 등이 들어 있습니다.

세 번째는 agents/입니다. 단일 책임을 지는 실행 단위들로 채워집니다. 문제를 나누고 계획을 세우는 오케스트레이터 에이전트(planner, delegator), 실제 작업을 수행하는 실행 에이전트(worker, database, pr), 검증을 맡는 에이전트(safety, reliability, reviewer)로 나뉩니다. 이렇게 에이전트가 작성한 모든 최종 코드는 같은 저장소의 src/ 디렉터리에 차곡차곡 저장됩니다.

.ai 디렉터리 기반 에이전트 구조

작업이 시작되면 오케스트레이터 에이전트가 두뇌 역할을 맡아 요구사항을 하위 작업으로 쪼개고 실행 계획을 세웁니다. 그리고 Cursor 같은 개발 도구 안에서 돌아가는 하위 에이전트들에게 작업을 맡깁니다.

정리 크론 프레임워크 구축에서 오케스트레이터는 데이터베이스 에이전트에게 스키마 마이그레이션과 데이터 삭제 쿼리를 맡기고, 워커 에이전트에게는 Redis 기반 작업 조율과 배치 처리 로직을 맡겨 비동기 병렬로 작업을 진행시켰습니다. 오케스트레이터는 작업 간의 의존 관계를 파악해 꼭 필요한 부분만 순서대로 직렬 실행했습니다. 그 뒤를 이어 커밋 에이전트가 작업 단위마다 관례에 맞는 메시지를 달아 원자적 커밋을 남겼고, PR 에이전트가 전체 변경 사항을 읽기 쉬운 하나의 PR로 묶었습니다.

실제 환경에서는 planner가 담당 에이전트, 입출력 규격, 선행 작업이 정의된 작업 분해 파일을 생성하고, delegator가 선행 조건이 완료된 작업만 골라 하위 에이전트에 전달했을 것입니다. 에이전트 간의 파일 수정 충돌을 막기 위해 작업 단위별로 수정 가능한 파일 범위를 미리 엄격하게 제한했을 가능성이 높습니다.

위험을 차단하고 성능을 지키는 가드레일

대규모 분산 환경에서 에이전트가 생성한 코드가 시스템을 망가뜨리지 않도록, Freshworks는 단계별 안전장치를 촘촘하게 배치했습니다.

모든 에이전트는 코드 한 줄을 작성하기 전에 반드시 .ai/rules/의 규칙들을 먼저 읽어야 합니다. 데이터베이스 명명 규칙, 멀티테넌트 데이터 격리 패턴, 테스트 커버리지 기준, 보안 규정은 에이전트가 즉흥적으로 변형하거나 타협할 수 없는 절대적 기준입니다.

여기에 특정 기술에 특화된 지식은 스킬 파일로 주입됩니다. 예를 들어 Redis 패턴 스킬(redis-patterns.md)은 Freshdesk 코드베이스의 TTL 전략, 대량 데이터 작업의 안전한 패턴과 캐시 무효화 시 여러 프로세스가 동시에 DB로 몰려드는 thundering herd 현상을 막는 법을 알려줍니다. 이를 통해 범용 인공지능 모델이 수년간 Freshdesk 코드를 다뤄온 노련한 시니어 엔지니어처럼 행동하게 만듭니다.

개발 환경의 보안은 샌드박스 에이전트(safety-agent)가 책임집니다. 에이전트가 내리는 모든 명령을 실행 직전에 가로채서 검증합니다. 삭제 조건을 지정하는 WHERE 절이 빠진 치명적인 데이터베이스 작업, 운영 환경의 자격 증명에 접근하려는 시도, Redis 네임스페이스 전체를 날려버리는 플러시(flush) 명령을 사전에 차단합니다.

실제로는 셸 명령이나 데이터베이스 쿼리를 실행하기 직전에 훅(hook)을 걸어 정적 분석으로 명백한 금지 명령을 즉시 튕겨내고, 모호한 동작은 규칙 파일을 기준으로 모델이 판단했을 것입니다. 개발 환경에는 처음부터 운영 환경 자격 증명을 아예 두지 않는 격리 조치도 병행되었을 것입니다.

시스템 부하를 막는 역할은 신뢰성 에이전트가 담당합니다. CPU, Redis, 데이터베이스 연결 풀, 하위 시스템이 급격한 트래픽에 휩쓸리지 않도록 보호합니다. 대량 데이터를 지울 때 자주 쓰는 LIMIT-OFFSET 방식은 구현하기는 쉽지만, 건너뛸 행이 많아질수록 데이터베이스가 거대한 결과를 훑어야 하므로 같은 연결 풀을 쓰는 다른 모든 쿼리까지 느려지게 만듭니다. 신뢰성 에이전트는 이를 원천 차단하고 커서 기반 페이지네이션을 강제합니다. 마지막으로 처리한 식별자(id) 다음부터 LIMIT 1000 단위로 삭제하게 하여, 첫 번째 배치부터 백만 번째 배치까지 일정한 처리 속도를 유지시킵니다. 배치 작업 사이에 조절 가능한 대기 시간(sleep)을 두어 피크 트래픽 시간대에도 시스템 자원을 독점하지 않도록 했습니다. 시니어 개발자의 오랜 운영 경험이 기본 시스템 규칙으로 강제된 것입니다.

대량 데이터 삭제 방식 비교

작업의 정확도를 높이기 위해 TDD 에이전트도 투입됩니다. 하위 에이전트에게 테스트 코드를 먼저 작성하게 하고, 그 테스트를 통과할 수 있는 최소한의 코드만 작성하도록 강제합니다. 이는 코드 검증뿐만 아니라 대규모 언어 모델의 컨텍스트 창을 효율적으로 관리하기 위한 전략이기도 합니다. 에이전트가 자신이 맡은 테스트 케이스와 필수 규칙에만 집중하게 만들어 불필요한 정보 확장을 막고, 모델이 엉뚱한 결과물을 지어내는 환각 현상을 억제합니다. 이때 미리 작성된 테스트는 에이전트가 따라야 할 명세 역할을 합니다.

Claude가 쓰고 OpenAI Codex가 검토하는 교차 검증

코드가 완성된 후에도 Freshworks는 같은 모델에게 자체 검토를 맡기지 않습니다. 코드는 Claude가 작성하고, 코드 리뷰는 다른 회사의 모델인 OpenAI Codex가 수행하도록 역할을 나눴습니다.

자신이 작성한 결과물을 스스로 평가하는 인공지능 모델은 자신이 세운 전제를 비판 없이 수용하고 평소 자주 범하는 패턴을 그대로 지나치는 맹점을 가집니다. 학습 데이터와 내부 아키텍처 편향이 서로 다른 두 모델을 검토 루프로 맞물려 놓음으로써, Codex가 Claude가 놓칠 수 있는 미세한 성능 안티패턴, 예외 처리 누락, 사내 규칙과의 불일치를 효과적으로 잡아내도록 했습니다.

실제 구현 과정에서는 Codex 리뷰어에게 Claude의 생성 대화 내역 전체를 넘겨주지 않고 최종 패치 diff, 사내 규칙, 스킬 플레이북, 작업 명세만 전달했을 것입니다. 이전 대화 기록이 리뷰어 모델에 편향을 주는 것을 막기 위해서입니다. 만약 검토와 수정이 반복되는 루프에 빠질 경우를 대비해 재시도 한도를 정해 두고, 해결되지 않는 문제는 PR 설명에 올려 사람이 직접 판단하게 했을 것입니다.

리뷰어 에이전트의 승인을 거치면 PR 에이전트가 무엇을 만들었는지, 핵심 결정의 이유가 무엇인지, 시스템 구성 요소가 어떻게 맞물리는지를 상세히 설명하는 PR을 생성합니다.

여기서 사람 엔지니어가 개입해 코드를 최종 검토합니다. 검토를 통과한 코드는 사람이 직접 작성한 코드와 똑같이 사전 운영 환경인 스테이징 검증 파이프라인을 필수적으로 통과해야만 배포됩니다. Ajay Ravichandran은 이 최종 관문을 두고 “자율적이라는 말이 검증되지 않았음을 뜻하는 것은 아닙니다.”라고 강조합니다.

코드 작성자에서 시스템 아키텍트로

Freshworks 엔지니어링 블로그는 이 도입 사례를 소개하면서 개발 속도가 몇 배 빨라졌다거나 결함률이 얼마나 줄었는지와 같은 정량적 지표는 일절 공개하지 않았습니다. 대신 실제로 운영 가능한 수준의 정리 크론 시스템을 만들어낸 아키텍처와 엔지니어링 역할의 근본적인 변화에 초점을 맞췄습니다.

전통적인 방식에서 수 주일 동안 스프린트 티켓을 오가며 씨름해야 했던 복잡한 백그라운드 시스템이, 오케스트레이터 에이전트와 전문 하위 에이전트의 협업을 통해 운영 규율을 지킨 상태로 구현되었습니다.

이 과정에서 조직 구성원의 역할 분담도 완전히 재편되었습니다. 사람 엔지니어는 규칙과 스킬, 에이전트의 동작 방식을 설계하는 아키텍트가 됩니다. 오케스트레이터는 문제를 나누고 작업을 위임하는 테크 리드 역할을 맡습니다. 하위 에이전트는 분업화된 전문 작업을 병렬로 수행하는 엔지니어링 팀이 되고, 리뷰 에이전트는 사람이 코드를 보기 전에 결함을 걸러내는 품질 관문 역할을 합니다.

이러한 변화는 개발자를 기계로 대체하는 것이 아닙니다. 개발자가 시간을 쏟고 가치를 만들어내는 층위를 한 단계 위로 끌어올리는 과정입니다.

앞으로 엔지니어의 역량은 키보드를 빠르게 두드려 코드를 작성하는 속도가 아니라, 정교한 에이전트 시스템을 설계하고, 기계가 지켜야 할 좋은 규칙을 명문화하며, 어디까지를 인공지능에 맡기고 어디서부터 사람의 감독을 개입시킬지 판단하는 분별력으로 평가받게 될 것입니다.

---

출처

Freshworks Engineering (Medium) — Pivoting to Autonomous Agentic Development — https://medium.com/freshworks-engineering-blog/pivoting-to-autonomous-agentic-development-ad9ba8408fe3 — 2026-05-28 (Ajay Ravichandran)