Agent Experience는 새로운 Developer Experience(DX)다

Developer Experience (DX)는 사람이 도구를 얼마나 잘 사용할 수 있는지를 묻습니다. Agent Experience는 기계에 대해 같은 질문을 던집니다.

이 페이지는 Claude Code, Cursor, 그리고 사람의 개입 수준이 다양한 맞춤형 에이전틱 워크플로처럼 코드를 작성, 실행, 반복하는 AI 코딩 에이전트를 중심으로 다룹니다. 동일한 원칙은 모델이 누군가를 대신해 소프트웨어나 인프라와 상호작용하는 모든 상황에 적용됩니다.

Agent Experience는 제품 카테고리가 아니라 설계 분야입니다. API, 명령줄 도구, 문서, 권한, 환경, 오류 메시지, 로그, 피드백 시스템 등 다양한 곳에서 나타납니다. 이러한 인터페이스 대부분은 원래 사람을 위해 설계되었습니다.

훌륭한 Developer Experience (DX)는 의도와 유용한 결과 사이의 거리를 좁혀줍니다. 사람은 시각적 계층 구조, 점진적 정보 공개, 이해하기 쉬운 설명, 탐색을 지원하는 인터페이스의 혜택을 받습니다.

에이전트는 같은 시스템과도 다르게 상호작용합니다. 시각적으로 훑어보기 좋게 설계된 대시보드는 기계에는 거의 쓸모없는 정보만 노출할 수 있습니다. 장황한 오류 메시지는 사람이 맥락을 이해하는 데는 도움이 되지만, 에이전트에게는 신호와 잡음을 구분하는 데 토큰을 소모하게 만듭니다. 대화형 프롬프트는 사람에게는 CLI를 더 쉽게 만들어 주지만, 자동화된 워크플로를 완전히 멈추게 할 수 있습니다.

두 사용자 모두를 위한 설계

Agent Experience는 Developer Experience (DX)를 대체하지 않습니다. 소프트웨어 시스템은 점점 더 두 사용자 모두를 지원하고 있습니다.

개발자는 시각적 인터페이스에서 풀 리퀘스트를 검토하는 동안, 에이전트는 API를 통해 동일한 변경 사항을 가져올 수 있습니다. 개발자는 전체 빌드 로그를 확인하는 동안, 에이전트는 실패한 단계와 관련 오류만 요청할 수 있습니다. 사람은 가이드가 있는 설정 흐름을 선호하는 반면, 에이전트에는 예측 가능한 출력을 제공하는 비대화형 명령이 필요합니다.

좋은 툴링은 동일한 기반 기능을 각 사용자에게 적합한 형태로 제공합니다.

개발자 도구는 수십 년 동안 키보드 앞에 사람이 있다는 것을 전제로 만들어져 왔습니다. 대시보드를 훑어보고, 예상치 못한 것을 알아차리고, 추가 정보를 찾고, 판단력을 발휘해 모호함을 해결할 수 있는 사람 말입니다.

에이전트는 이 전제를 바꿔 놓습니다. 소스 관리 시스템, 빌드 인프라, 패키지 레지스트리, 클라우드 플랫폼, 내부 API, 개발자 도구는 누군가를 대신해 동작하는 소프트웨어로부터 점점 더 많은 요청을 받고 있습니다.

에이전트는 소프트웨어의 사용자가 되어 가고 있다

에이전트는 과거에 개발자가 수동으로 조작하던 시스템과 점점 더 직접 상호작용합니다.

에이전트는 문서를 읽고, API를 호출하고, 명령을 실행하고, 리포지토리를 수정하고, 로그를 확인하고, 인프라를 조회하고, 워크플로를 실행시킵니다. 이 과정에 있는 모든 인터페이스는 에이전트가 작업을 안정적으로 완료할 수 있는지에 영향을 줍니다.

낮은 품질의 AX는 결국 사람의 일이 된다

구조화되지 않은 대량의 출력을 그대로 받은 에이전트는 무엇이 중요한지 파악하는 데 시간과 토큰을 써야 합니다. 모호한 API 응답은 불필요한 재시도나 잘못된 다음 작업으로 이어질 수 있습니다. 대화형 프롬프트는 자동화된 작업을 멈추고 사람에게 돌려보낼 수 있습니다.

문제는 워크플로 전반에 걸쳐 누적됩니다. 각 단계에서의 작은 모호함이 자율적인 작업을 반복적인 확인, 검토, 뒷정리로 바꿀 수 있습니다.

더 나은 모델이 인터페이스 설계를 불필요하게 만들지는 않는다

모델의 성능은 앞으로도 계속 향상될 것입니다. 팀은 모델이 상호작용하는 시스템, 즉 API 스키마, 문서, CLI 동작, 로그, 권한, 환경, 피드백을 훨씬 더 직접적으로 통제할 수 있습니다.

더 나은 모델은 부실한 인터페이스에 대해서도 더 효과적으로 추론할 수 있지만, 더 견고한 인터페이스는 애초에 필요한 추론의 양 자체를 줄여줍니다.

플랫폼 팀은 공유 인프라를 통해 다져진 길(paved path)을 만들어 이미 개발자를 위해 비슷한 작업을 하고 있습니다. 에이전틱 개발은 설계해야 할 또 다른 사용자를 추가합니다.

Agent Experience는 에이전트가 작업을 완료하기 위해 사용하는 모든 인터페이스의 속성입니다.

코딩 에이전트의 경우, 단 하나의 변경 사항에도 문서 읽기, 리포지토리 조회, 명령 실행, 파일 수정, 외부 도구 호출, 테스트 출력 해석, CI 상태 확인, 풀 리퀘스트 업데이트가 필요할 수 있습니다.

올바른 컨텍스트 확보하기

에이전트에게는 예측 가능하게 가져오고 해석할 수 있는 형태로 정보에 접근할 수 있는 권한이 필요합니다.

API는 안정적인 스키마와 구조화된 응답의 혜택을 받습니다. 문서는 정확한 예시, 명확한 버전 관리, 표준화된 지침의 혜택을 받습니다. CLI 도구는 기계가 읽을 수 있는 출력 모드의 혜택을 받습니다. 도구 설명은 정확한 이름, 입력, 출력, 경계의 혜택을 받습니다.

MCP와 같은 프로토콜은 인터페이스 설계를 특히 눈에 띄게 만듭니다. 도구 설명은 에이전트가 언제 해당 도구를 선택하고 요청을 어떻게 구성하는지를 결정하는 데 도움이 됩니다.

이용 가능한 컨텍스트가 많다고 해서 자동으로 더 나은 AX가 만들어지는 것은 아닙니다. 관련성 있는 컨텍스트가 그렇게 만듭니다.

안전하게 작업 수행하기

에이전트에게는 시스템을 변경할 수 있는 예측 가능한 방법이 필요합니다.

명령줄 도구는 비대화형 실행, 의미 있는 종료 코드, 결과가 명확하게 정의된 작업을 지원해야 합니다. 실용적인 범위 내에서, 반복 실행되는 명령은 안전하거나 중복 작업이 명확히 드러나야 합니다.

권한은 실수의 비용을 키우지 않으면서 에이전트에게 얼마나 많은 자율성을 부여할 수 있는지를 결정합니다. 범위를 좁힌 권한, 승인 경계, 격리된 환경, 정책 적용을 통해 에이전트는 의도치 않은 영향을 제한하면서도 유용한 작업을 수행할 수 있습니다.

무슨 일이 일어났는지 파악하기

에이전트는 어떤 작업이 성공했는지, 실패했는지, 아니면 예상치 못한 상태를 발생시켰는지 알아야 합니다.

기계가 읽을 수 있는 상태, 구체적인 오류, 구조화된 로그, 명시적인 상태는 다음 단계를 정하기 쉽게 만들어 줍니다. 유용한 오류는 무엇이 실패했는지, 어디에서 실패가 발생했는지, 시스템이 무엇을 기대했는지를 에이전트에게 알려줍니다.

필요할 때는 전체 세부 정보를 계속 이용할 수 있어야 합니다. 다만 그것이 기본 응답일 필요는 없습니다.

상태와 이력 파악하기

에이전트는 개발자라면 보통 다른 인터페이스를 열어 확인했을 정보를 필요로 하는 경우가 많습니다.

현재 어떤 배포가 실행 중인가? 어떤 파이프라인이 실패했는가? 이전 시도 이후 무엇이 바뀌었는가? API 호출이 완료되었는가? 이미 열려 있는 풀 리퀘스트가 있는가?

운영 상태를 프로그래밍 방식으로 노출하면, 에이전트는 대시보드의 정보를 사람이 해석해 주는 것에 의존하지 않고도 이러한 질문에 답할 수 있습니다.

Agent Experience를 개선한다고 해서 AI를 중심으로 플랫폼 전체를 다시 만들어야 하는 경우는 드뭅니다. 가장 가치 있는 변화 중 상당수는 기존 인터페이스를 더 명확하고, 더 구조화되고, 더 예측 가능하게 만드는 것만으로 이루어집니다.

1. 구조화된 정보를 반환하기

에이전트가 반복적으로 사용할 워크플로에는 기계가 읽을 수 있는 출력을 제공하세요.

CLI라면 문서화된 스키마에 맞춘 JSON 출력을 의미할 수 있습니다. API라면 안정적인 응답 타입과 명시적인 오류 상태를 의미합니다. 문서라면 누락된 가정을 에이전트가 스스로 재구성하지 않고도 실행할 수 있는 예제를 의미합니다.

사람이 읽을 수 있는 출력은 그대로 사람을 위해 남겨 둘 수 있습니다. 에이전트는 동일한 정보에 접근할 수 있는 기계 지향적 경로가 있을 때 더 큰 도움을 받습니다.

2. 소스 단계에서 컨텍스트를 정제하기

사용 가능한 모든 정보가 아니라 현재 결정에 필요한 정보만 반환하세요.

테스트 세 개가 실패했다면, 관련 없는 출력 수천 줄을 반환하기 전에 그 세 가지 실패를 특정하고 관련 세부 정보를 제공하세요. 매개변수가 유효하지 않아 작업이 실패했다면, 해당 매개변수와 예상 값을 직접 알려 주세요.

소스 단계에서 필터링하면 토큰 사용량이 줄고, 에이전트가 고려해야 할 타당한 해석의 수도 줄어듭니다.

3. 작업을 예측 가능하고 반복 가능하게 만들기

에이전트형 워크플로는 작업을 자주 재시도하고, 대안적인 접근 방식으로 분기하며, 이전 단계로 되돌아가는 일이 흔합니다.

멱등한 작업은 재시도를 안전하게 만듭니다. 명확한 상태 전이는 무언가가 이미 일어났는지 에이전트가 파악하는 데 도움이 됩니다. 정직한 종료 코드와 명시적인 상태는 에이전트가 텍스트만 보고 성공 여부를 추측해야 하는 상황을 막아 줍니다.

가드레일은 가능한 한 시스템 안에 두어야 합니다. 권한 경계와 정책 검사는 모든 에이전트가 문서화된 규칙을 스스로 발견하고 따를 것이라고 기대하는 것보다 훨씬 신뢰할 수 있습니다.

4. 지연 시간을 인터페이스의 일부로 다루기

피드백은 에이전트가 그 피드백을 만들어 낸 작업을 아직 수행하고 있는 동안 가장 유용합니다.

허용 가능한 지연 시간은 워크플로에 따라 다릅니다. 로컬 구문 검사는 거의 즉시 결과를 반환해야 할 수도 있습니다. 전체 통합 테스트는 더 오래 걸릴 수 있습니다. 배포는 본질적으로 몇 분이 걸릴 수도 있습니다.

중요한 질문은 그 타이밍이 에이전트가 다음에 내려야 할 결정에 맞는지입니다.

5. 에이전트의 성과를 측정하기

기존 UX 지표만으로는 에이전트가 시스템과 얼마나 잘 상호작용하는지 온전히 설명할 수 없습니다. 대표성 있는 작업을 소수 정의하고, 제품이 변경될 때마다 반복적으로 실행하세요.

유용한 AX 신호에는 다음이 포함될 수 있습니다.

• 첫 시도가 성공적으로 완료되는 빈도
• 작업에 필요한 재시도 또는 도구 호출 횟수
• 해결에 도달하기까지 필요한 시간 또는 추론 예산
• 사람이 개입해야 하는 빈도
• 실패한 시도 직전에 가장 자주 등장하는 도구나 인터페이스

반복되는 실패가 인터페이스 문제를 드러내면 이를 수정하고, 그 사례를 회귀 평가로 남겨 두세요. 이러한 평가는 API 스키마, 도구 정의, 구조화된 출력, 종료 코드, 권한 경계 같은 에이전트 대상 계약에 대한 테스트와 함께 CI에서 실행하세요.

기준선이 있으면 실제 AX 개선과, 사람 검토자에게 그저 더 깔끔해 보이기만 하는 변경을 구분할 수 있습니다.

반복되는 실패에서 시작하기

에이전트가 자주 수행하는 작업 하나를 골라, 실패한 시도를 처음부터 끝까지 살펴보세요.

에이전트가 컨텍스트가 부족했거나, 상태를 잘못 이해했거나, 잘못된 도구를 선택했거나, 모호한 피드백을 받았거나, 사람의 개입이 필요했던 최초의 지점을 찾으세요.

가장 유용한 AX 개선은 대개 모델 자체보다는 익숙한 소프트웨어 인터페이스에서 시작됩니다. 반복되는 실패를 수정했다면, 나중에 회귀를 포착할 수 있도록 평가 세트에 추가하세요.

AI 에이전트는 비결정론적입니다. 같은 작업을 두 번 시도해도 서로 다른 추론 경로, 도구 호출 순서, 해결책이 나올 수 있습니다.

인터페이스 설계는 이러한 차이가 만들어내는 변동의 폭을 늘릴 수도, 줄일 수도 있습니다.

전체 작업 로그를 받은 에이전트에게는 따라갈 수 있는 신호가 매우 많습니다. 관련 실패 내용, 영향을 받은 파일, 예상 동작, 보조 컨텍스트를 받은 에이전트는 훨씬 좁혀진 문제 정의에서 시작합니다.

두 번째 인터페이스가 모델을 결정론적으로 만드는 것은 아닙니다. 다만 불필요한 모호함을 줄여 줄 뿐입니다.

정밀한 도구 설명은 도구 선택의 폭을 좁힙니다. 안정적인 스키마는 해석의 여지를 줄입니다. 명시적 상태는 추측을 줄입니다. 명확하게 정의된 권한 경계는 사용 가능한 작업을 제한합니다.

좋은 AX는 모델의 변동성이 잘못되거나 비용이 많이 드는 동작으로 이어질 여지를 줄이도록 주변 시스템을 설계합니다.

위에서 설명한 원칙은 소프트웨어 스택 전반에 적용됩니다. CircleCI는 Agent Experience 중에서도 특정 부분, 즉 에이전트가 소프트웨어를 개발하는 동안 유용한 검증 피드백을 어떻게 얻는지, 그리고 팀이 에이전트가 생성한 변경 사항을 배포하기 전에 어떻게 독자적으로 검증하는지에 집중합니다.

코드 생성은 점점 더 빠르고 저렴해지고 있습니다. 그럼에도 추가되는 모든 변경 사항은 여전히 머지와 배포에 필요한 기준을 충족한다는 근거가 필요합니다.

CircleCI의 접근 방식은 에이전트의 작업 루프 안에서 이루어지는 빠른 피드백과 CI에서의 독자적인 검증을 연결합니다.

코딩 에이전트는 그럴듯한 변경 사항을 빠르게 만들어낼 수 있습니다. 하지만 그 변경 사항을 평가하는 데는 훨씬 더 많은 작업이 필요할 수 있습니다.

테스트를 통과했다는 것은 유용한 근거가 되지만, 그것이 알려주는 것은 실행한 검사가 통과했다는 사실뿐입니다. 어떤 변경 사항이 테스트 하나를 통과하더라도, 다른 곳에서 회귀를 일으키거나, 잘못된 문제를 해결하거나, 현재 테스트 스위트가 다루지 않는 다른 요구 사항을 충족하지 못할 수 있습니다.

에이전트형 개발에서는 빠른 피드백과 독자적인 검증의 중요성이 모두 커집니다. 에이전트는 작업하는 동안 효율적으로 반복하기 위한 충분한 신호가 필요하고, 팀은 코드가 공유되거나 배포 가능해지기 전에 더 폭넓은 검증 계층이 필요합니다.

우리는 단일 성공 신호를 정확성의 증거로 취급하는 대신, 어떤 변경 사항이 팀의 머지 요구 사항을 충족할 만큼 충분한 근거를 갖추었는지를 설명하기 위해 머지 품질이라는 용어를 사용합니다.

CI는 이러한 근거를 모으고 적용할 수 있는 독자적인 공간을 제공합니다.

에이전트적 소프트웨어 개발은 두 가지 피드백 루프에 걸쳐 이루어집니다.

이너 루프

이너 루프는 에이전트가 변경 사항을 실제로 작업하는 동안 일어나는 과정입니다.

작성 → 실행 → 확인 → 수정 → 반복

에이전트는 여전히 문제, 구현 내용, 최근 도구 출력을 활성 컨텍스트에 유지하고 있습니다. 여기서 빠르게 검증하면 푸시나 풀 리퀘스트 이전에 문제를 발견하는 데 도움이 됩니다.

아우터 루프

아우터 루프는 변경 사항이 공유 딜리버리 인프라에 도달하는 시점부터 시작됩니다.

여기에는 CI/CD 파이프라인, 통합 및 시스템 테스트, 보안 검사, 리뷰, 배포, 배포 후 검증이 포함될 수 있습니다.

아우터 루프는 다른 목적을 수행합니다. 그 결과는 개발자, 에이전트, 리뷰어, 그리고 다운스트림 시스템 전반에 공유됩니다. 이는 변경 사항이 생성된 환경 밖에서 독립적인 증거를 제공합니다.

루프 연결하기

뛰어난 Agent Experience는 두 루프 사이에서 유용한 피드백이 계속 흐르도록 합니다.

이너 루프에서 발견된 실패는 에이전트가 여전히 전체 작업 컨텍스트를 가지고 있는 동안 즉시 수정할 수 있는 경우가 많습니다. CI에서 발견된 실패는 에이전트가 문제 전체를 처음부터 다시 파악하지 않고도 작업을 이어갈 수 있을 만큼 충분히 구조화된 정보와 함께 돌아와야 합니다.

목표는 아우터 루프의 모든 검사를 이너 루프로 옮기는 것이 아닙니다. 각 루프가 자신의 역할을 잘 수행하도록 하고, 그 사이의 전달을 효율적으로 만드는 것입니다.

CircleCI는 에이전트가 코드를 더 빠르게 검증하고, CI로부터 더 신호가 높은 피드백을 받고, 개발자가 결과를 따로 해석해주지 않아도 실패에 바로 대응할 수 있도록 두 루프 전반에 걸쳐 에이전트 전용 인터페이스를 구축하고 있습니다.

1. 이너 루프의 CI 수준 검증

Chunk 사이드카는 푸시 이전에 격리된 환경에서 영향을 받은 코드에 대한 타겟 검증을 실행합니다.

에이전트는 전체 CI 파이프라인을 기다리지 않고도 구현 내용을 컨텍스트에 유지한 상태로 작업 디렉토리의 변경 사항을 검증할 수 있습니다. 사이드카는 이너 루프에 속하는 검사에 대해 1분 이내에 CI 수준의 피드백을 반환하도록 설계되었습니다.

빠른 이너 루프 검증은 문제가 발생한 지점에 더 가까운 곳에서 단순한 문제를 잡아내고, 아우터 루프가 더 깊은 공유 검사에 집중할 수 있도록 해줍니다.

2. 아우터 루프의 더 신호가 높은 검증

Smarter Testing은 테스트 영향 분석을 사용해 변경 사항의 영향을 받는 테스트만 실행하고, 사용 가능한 컴퓨팅 자원에 테스트 실행을 지능적으로 분산하며, 실패를 재실행해 플레이키 테스트를 식별합니다.

에이전트에 의한 개발은 CI를 통과하는 변경 사항과 검증 주기의 수를 늘릴 수 있습니다. 가장 관련성 높은 테스트를 신속하게 실행하면 볼륨이 늘어나도 피드백의 유용성을 유지하는 데 도움이 됩니다.

플레이키하거나 불필요한 테스트 실행을 줄이면 변경 사항이 주의가 필요한지에 대해 에이전트와 개발자 모두에게 더 명확한 신호를 제공합니다.

3. 아우터 루프의 실패를 다시 컨텍스트로 가져오기

CI 실패는 관련 정보가 에이전트의 작업 환경으로 직접 돌아올 때 가장 유용합니다.

CircleCI CLI는 --failure-report 플래그를 지원하며, 이는 실패한 작업을 에이전트가 전체 로그를 먼저 파싱하지 않고도 진단하는 데 필요한 정보로 압축해줍니다.

CircleCI는 Fix with Claude Code도 지원하며, 이는 실패한 CircleCI 실행의 구조화된 실패 요약을 터미널의 Claude Code로 다시 전송합니다.

아우터 루프는 문제를 감지합니다. 에이전트는 관련 컨텍스트를 받아 수정 사항을 제안하고, CI는 다음 변경 사항을 독자적으로 검증합니다.

4. 에이전트에게 CircleCI에 대한 직접 액세스 제공

CircleCI CLI는 구조화된 JSON 출력, 실패 리포팅, 파이프라인 작업, 배포 툴링을 갖춘 CircleCI용 머신 지향 인터페이스를 제공합니다.

CircleCI MCP 서버는 CircleCI 도구를 MCP 호환 에이전트에 직접 노출합니다. 에이전트는 파이프라인 상태를 조회하고, 실패와 테스트 결과를 확인하고, 워크플로를 재실행하고, 파이프라인을 트리거하는 등 지원되는 다른 작업을 개발자가 시스템 간에 수동으로 정보를 옮기지 않아도 수행할 수 있습니다.

신규 프로젝트의 경우 circleci onboard가 저장소를 검사하고, 초기 CircleCI 설정을 생성하며, 프로젝트를 CircleCI에 연결할 수 있습니다.

이러한 인터페이스들이 함께 작동하면 에이전트는 딜리버리 워크플로에 직접 참여할 수 있으며, CircleCI는 에이전트가 생성하는 코드를 둘러싼 독립적인 검증 계층으로 남습니다.

뛰어난 Agent Experience는 에이전트를 여러분의 제품 사용자로 취급하는 것에서 시작됩니다. 관련 컨텍스트, 예측 가능한 행동 방식, 명확한 시스템 상태, 그리고 다음 결정을 분명하게 해주는 피드백을 에이전트에게 제공하세요.

빈도가 높은 워크플로 하나를 선택해 에이전트가 처음부터 끝까지 사용할 수 있도록 만드세요. 대표적인 작업을 반복적으로 테스트하고, 반복되는 실패를 구체적인 인터페이스 개선으로 전환하세요. 에이전트 평가와 계약 테스트를 CI 피드백 루프의 일부로 만들면 제품이 변경될 때 AX 회귀를 잡아내는 데 도움이 됩니다.

CircleCI를 사용하면 AX는 딜리버리 워크플로 자체로 확장할 수 있습니다. 코딩 에이전트는 구조화된 CLI 출력과 MCP 도구에 접근하고, 이너 루프에서 변경 사항을 검증하며, 아우터 루프에서 CI로부터 더 신호가 높은 피드백을 받아 개발자가 결과를 대신 해석해주지 않아도 계속 작업할 수 있습니다.

AX를 제품에 구축한 다음, 이를 지속적으로 테스트하고 개선하는 대상으로 만드세요.