개발자 애드보킷의 종말

URL: https://www.youtube.com/watch?v=Lrw0jqBNaw0
날짜: 2026-08-27
채널: aiDotEngineer
인물: Stephanie Jarmak (Sourcegraph)

📌 핵심 질문 / 핵심 논점

==개발자 애드보케이트(Developer Advocate)는 사라지는 것이 아니라, 인간 개발자만 상대하던 개발자 관계(DevRel)를 에이전트 애드보케이트(Agent Advocate)로 확장해야 한다.== 에이전트는 제품을 사용하는 소비자이면서 문서와 API를 읽고 도구를 추천하는 새로운 ICP(이상적 고객 프로필)이므로, 개발자 경험(DX)뿐 아니라 에이전트 경험(Agent Experience)을 측정하고 설계해야 한다.

• 1980년대의 소프트웨어 에반젤리즘(Software Evangelism)은 제품의 좋은 점을 일방적으로 전파했지만, 2010년대의 DevRel은 개발자의 필요를 제품에 되돌려주는 피드백 루프와 양방향 관계로 발전했다.
• 2026년의 개발자는 혼자 코드를 작성하는 사람이 아니라 에이전트 군집을 오케스트레이션(orchestration)하고 감독하는 사람이며, 에이전트 역시 문서·API·에러·토큰 비용을 직접 경험하는 사용자다.
• 에이전트 추천 실험에서 비교 구매 프롬프트에는 Sourcegraph가 65% 추천됐지만, 실제 고충을 제시한 프롬프트에는 언급조차 되지 않았다. 인간이 예상하는 메시지와 에이전트가 검색·추천하는 메시지 사이의 간극을 측정해야 한다.

DevRel의 핵심인 교육(enablement), 커뮤니티, 피드백 루프, 신뢰도는 그대로 남는다. 다만 교육 대상에 에이전트를 추가하고, 기계가 읽기 좋은 콘텐츠·에이전트 친화적 API·MCP 레지스트리 노출을 갖추며, 에이전트가 인간의 업무 흐름에 제품을 삽입할 수 있는지까지 책임져야 한다. 에이전트를 위한 턱 낮춤(cur­b cut)을 만들면 휠체어용 경사로가 유모차와 여행 가방에도 유용하듯 인간 개발자의 경로도 함께 매끄러워진다.

1. ‘개발자 애드보케이트의 종말’이라는 제목과 새로운 역할의 출발

1.1. 농담으로 시작한 부고와 Stephanie Jarmak의 배경

1. 청중을 향한 도발적인 인사

   1. 행사 초반 기술적 문제가 있었지만, Stephanie Jarmak은 “이 트랙의 끝까지 왔다”는 사실을 기뻐하며 오래 남아준 청중에게 감사했다.
   2. 개발자 애드보케이트 또는 DevRel 종사자에게 손을 들라고 요청한 뒤, 손을 든 사람들에게 “죽었다고 말하는데 나에게 토마토를 던지러 온 것이냐”고 농담했다.
   3. 제목이 어둡지만 전부 절망적인 이야기는 아니라고 선을 그었다.

2. 연구과학자에서 에이전트 애드보케이트로

   1. Stephanie Jarmak은 연구과학자이며, 불과 지난해에는 천문학자였다. 당시에는 GTM(Go-to-Market)이 무엇인지도 몰랐다.
   2. 과학적 평가(evaluation)를 다루는 다소 지루한 발표안을 여러 개 제출했지만, 이번 컨퍼런스에서 무심히 휴지통에 버려졌을 것이라고 스스로 생각했다.
   3. 개발자 애드보케이트인 매니저가 “The Death of Developer Advocates”라는 더 화제성 있고 유행을 타는 제목을 제출했다. 다만 매니저 자신이 개발자 애드보케이트였으므로 자신이 그 직무의 장례식 추도사를 하는 것은 어색했다.
   4. 둘은 Stephanie Jarmak을 로봇으로 분장시켜 매니저를 무대에서 공격하고 제압하는 연출도 생각했지만 실행이 복잡했다. 결국 매니저는 휴가를 갔고, Stephanie Jarmak이 ‘에이전트 애드보케이트’가 되어 새로운 역할을 변호하게 됐다.

1.2. DevRel이 걸어온 경로

1. 소프트웨어 에반젤리즘에서 개발자 애드보커시로

   1. 1980년대에는 소프트웨어 에반젤리즘이라는 이름이 쓰였다. 에반젤리스트는 제품의 좋은 소식을 전하러 다니며 제품을 바깥세상에 알리는 일방향 전달자였다.
   2. 2010년대에 개발자 애드보커시(Developer Advocacy)가 자리를 잡으면서 커뮤니케이션 경로가 단선에서 피드백 루프로 바뀌었다.
   3. 개발자와 깊이 공감하고 개발자의 언어를 구사하는 사람이 개발자의 실제 필요를 이해한 뒤 그 정보를 제품 조직으로 가져오는 양방향 거리가 형성됐다.

2. 개발자 경험의 전략적 가치

   1. 개발자는 조직 내부에서 큰 영향력을 행사하며 도구 선택을 좌우하는 킹메이커(kingsmaker)가 됐다.
   2. 따라서 개발자 경험(Developer Experience)은 단순한 사용성 문제가 아니라 GTM 전략의 중요한 축이 됐다.
   3. 개발자의 역할이 근본적으로 바뀌면, 개발자와 관계를 맺는 애드보케이트의 역할도 바뀌어야 한다.

2. 2026년 개발자와 에이전트라는 새 사용자

2.1. 개발자는 혼자 일하지 않는다

1. 에이전트 군집의 오케스트레이터

   1. 2026년 개발자는 더 이상 혼자 일하는 사람이 아니다. 여러 에이전트로 구성된 플릿(fleet)을 오케스트레이션하고 때로는 그들을 돌보는 베이비시터가 된다.
   2. 실제 채용 공고의 언어도 계속 바뀌며, 개발자에게 AI 활용 능력(AI fluency)을 기대한다.
   3. 개발자라는 직업의 의미가 완전히 바뀌었으므로, 개발자에게 관계를 맺는 직무의 대상도 재정의해야 한다.

2. 비엔지니어도 개발 도구를 쓰는 사용자

   1. Stephanie Jarmak은 지난해 GitHub 커밋이 0건에 가까웠지만 지금은 약 12,000건을 기록했고, 멀티에이전트 오케스트레이션 프레임워크의 오픈소스 메인테이너가 됐다.
   2. 에이전트가 제공하는 능력 덕분에 누구나 사실상 개발 도구를 사용할 수 있다.
   3. 따라서 기존 엔지니어 개발자만이 아니라 연구과학자 같은 비엔지니어도 별도의 페르소나이자 ICP가 된다. 제품을 사용할 때 이 사용자군의 경험과 공감 지점을 따로 이해해야 한다.

2.2. 에이전트는 사용자이자 추천자다

1. 기계 방식으로 제품을 사용하는 사용자

   1. 에이전트는 개발자와 마찬가지로 제품 문서를 읽고 API를 호출한다.
   2. 다만 문서를 읽는 방식이 기계적이며, 도구를 호출하는 과정에서 에러를 만났을 때 어떻게 복구할지에 관한 고유한 좌절을 겪는다.
   3. 즉 제품의 성공 기준은 사람에게 설명이 쉬운가만이 아니라, 에이전트가 올바른 도구를 선택하고 한 번에 실행하며 실패 뒤 회복할 수 있는가까지 포함한다.

2. 도구를 워크플로에 삽입하는 추천자

   1. 에이전트는 제품 사용자가 될 뿐 아니라 제품을 추천하는 주체이기도 하다.
   2. ChatGPT나 Claude의 질의응답 환경에서 제품을 직접 호출할 수도 있고, 사용자의 요청을 처리하기 위해 라이브러리나 프레임워크를 스스로 설치할 수도 있다.
   3. 행사에서 “에이전트가 라이브러리를 대신 설치하도록 허용해본 사람”을 묻자 많은 사람이 손을 들었다. 에이전트는 도구를 단순히 소개하는 것이 아니라 워크플로에 직접 임베드한다.
   4. DevRel이 추구해온 상향식(bottom-up) 채택과 추천의 상당 부분이 이제 인간 개발자의 입소문뿐 아니라 에이전트의 판단에 의해 움직인다.

3. 에이전트 경험을 측정하는 CodeScaleBench

3.1. 벤치마크와 관찰 가능한 실행 추적

1. 소프트웨어 개발 생명주기를 반영한 작업 설계

   1. 데이터과학자이기도 한 Stephanie Jarmak은 에이전트 사용 경험을 측정하기 위해 CodeScaleBench라는 벤치마크를 만들었다.
   2. 소프트웨어 개발 생명주기(Software Development Life Cycle)를 반영하는 수백 개의 작업을 개발했다.
   3. Sourcegraph의 제품 도구를 사용하는 조건과 사용하지 않는 조건에서 에이전트를 실행해 도구가 실제 작업 수행을 얼마나 돕는지 비교했다.

2. Sourcegraph 도구와 피드백 루프

   1. 비교 대상에는 Sourcegraph의 코드 내비게이션 MCP(Model Context Protocol) 도구가 포함됐다.
   2. 목적은 도구가 에이전트의 업무를 어떻게 개선하는지, 잘 작동하지 않을 때 정확히 무엇이 문제인지 파악하는 것이다.
   3. 수천 개의 실행 추적(trace)을 쌓으면 에이전트가 어느 단계에서 무너지는지 확인하고 해당 지점을 제품·도구 설명·에러 처리로 고칠 수 있다.
   4. 에이전트 실행 로그는 매우 촘촘한 피드백 루프를 제공한다. 사람에게 인터뷰를 요청하는 것보다 훨씬 많은 반복 실험으로 특정 마찰을 재현할 수 있다.

3.2. ‘한 턴’을 태우는 도구 설명의 오류

1. 모델의 학습 편향과 파라미터 기대치

   1. 한 사례에서 에이전트가 read 도구를 사용하려 했고, 모델은 학습 데이터의 편향을 바탕으로 특정 명령 파라미터가 있을 것이라 기대했다.
   2. Sourcegraph 도구 설명에는 그렇게 오해할 만한 내용이 없었지만, 모델은 실제로 존재하는 start line 대신 read line 같은 파라미터를 시도했다.
   3. 호출은 실패했지만 에러 메시지가 실패 원인을 알려주었고, 에이전트는 스스로 수정할 수 있었다.

2. 성공한 복구도 제품 경험의 손실이다

   1. 에이전트가 결국 고쳤다는 사실만 보면 시스템이 정상 작동한 것처럼 보이지만, 실패와 복구에 전체 한 턴(turn)을 소비했다.
   2. 개발자에게는 사소해 보이는 명명 차이가 에이전트에게는 토큰·시간·실행 비용으로 나타난다.
   3. 이런 마찰을 발견하면 도구 설명이나 인터페이스를 고쳐 에이전트가 처음부터 올바른 호출을 만들도록 해야 한다.

3. 조직의 새로운 평가 기준

   1. 조직은 제품이 단순히 기능하는지만 평가하지 않는다.
   2. 에이전트가 해당 도구를 사용하기 위해 처리해야 하는 토큰 수와 응답 속도도 평가한다.
   3. 따라서 에이전트 애드보케이트의 핵심 업무에는 실제 사용 방식 측정, 실패 지점 추적, 토큰·속도·복구 비용 개선이 포함된다.

4. SEO에서 GEO로: 에이전트의 추천 경로 설계

4.1. Code Intelligence 추천 실험이 드러낸 간극

1. GEO의 의미

   1. SEO(Search Engine Optimization)가 검색엔진의 노출을 다룬다면, GEO(Generative Engine Optimization)는 생성형 엔진과 에이전트가 제품을 발견하고 추천하도록 만드는 작업이다.
   2. Stephanie Jarmak은 QR 코드로 공유할 GitHub 저장소와 두 개의 작은 토이 프로젝트를 준비했으며, 청중이 스크린샷을 찍지 않아도 관련 데이터와 템플릿을 확인할 수 있게 했다.

2. 비교 구매 상황에서는 65% 추천

   1. 여러 챗봇과 에이전트가 Sourcegraph 제품을 언급하거나 추천하는지 확인하는 실험을 설계했다.
   2. 코드 인텔리전스 도구를 적극적으로 구매 중이며 여러 제품을 비교하는 사람처럼 프롬프트를 작성하자 Sourcegraph가 65%의 비율로 추천됐다.
   3. 제품을 찾으러 온 사용자를 상정한 비교 프롬프트에서는 제품 카테고리와 메시지가 에이전트에게 잘 전달된 셈이다.

3. 실제 고충 상황에서는 0% 언급

   1. 더 전형적이고 중요한 상황은 특정 고통이나 필요가 발생했을 때 제품이 먼저 떠오르는 경우다.
   2. “공유 라이브러리를 변경할 때 모든 소비자를 볼 수 없어서 다운스트림 서비스를 계속 망가뜨린다”는 프롬프트를 입력했다.
   3. Sourcegraph에는 여러 저장소를 가로질러 의존 관계를 관찰하는 계층이 있으므로, 에이전트가 “이런 도구를 써보라”고 연결해주기를 기대할 만한 상황이었다.
   4. 그러나 결과는 Sourcegraph에 대한 언급 0건이었다. 에이전트는 개발자에게 위키 페이지를 만들라고만 제안했다.

4.2. 에이전트가 제품을 발견하도록 만드는 콘텐츠

1. 메시지와 고통의 연결을 가설로 세우기

   1. 이 차이는 제품이 실제 문제를 해결하지 못한다는 증거가 아니라, 현재 메시지가 고통과 사용 사례를 에이전트가 알아볼 만큼 분명하게 연결하지 못한다는 가설을 세우게 한다.
   2. 웹사이트의 문구와 콘텐츠를 바꾸는 캠페인을 진행하고, 웹 검색 도구를 호출하는 에이전트가 제품 정보를 어떻게 해석하는지 직접 측정할 수 있다.
   3. 측정 대상은 단순한 학습 데이터 속 인지도가 아니라, 변경된 웹 콘텐츠가 실제 추천·언급 비율을 얼마나 끌어올리는지다.

2. 오래된 학습 데이터가 만드는 소음

   1. AI 분야는 빠르게 변하므로 모델의 학습 데이터는 언제나 낡을 수밖에 없다.
   2. GEO 파일럿 실험의 이전 결과는 Claude Sonnet 4를 사용했다. 발표 당일 오후 최신 모델인 4.6으로 다시 실행하면 제품에 대한 더 나은 최신 정보가 반영될 것이라고 예상했다.
   3. 이전 모델은 Sourcegraph의 오래된 제품인 Cody를 계속 추천했는데, 4.6은 Cody를 오히려 더 자주 추천했다.
   4. 오래된 모델 출력이 인터넷에 계속 쌓이면 그 정보가 다시 검색·학습·생성에 사용되어 낡은 내용이 복리처럼 증폭된다. 진짜 신호가 과거 정보의 소음을 덮도록 해야 한다.

3. 신뢰할 수 있고 인용 가능한 최신 정보 제공

   1. 일부 팀은 llms.txt와 같은 페이지를 만들어 에이전트를 더 권위 있는 사실의 원천으로 유도한다.
   2. 그러나 정적 페이지 하나만으로는 부족하다. 에이전트가 도구와 실시간 정보, 출처(provenance)를 사용해 제품에 대한 정확한 답을 만들 수 있어야 한다.
   3. 에이전트가 사용자에게 그대로 가져가 팔 수 있는 문장과 인용 가능한 근거를 제공해야 한다.
   4. 실제 사용 사례를 현재 상태로 유지하고, 제품이 2년 동안 바뀌지 않았더라도 콘텐츠를 최신 상태로 갱신해야 한다. 에이전트의 관련성 알고리즘이 최신성과 구조를 신호로 사용하기 때문이다.
   5. 차트와 FAQ처럼 구조화되고 인용하기 쉬운 형식도 에이전트가 선호하는 정보다.

4. 에이전트가 찾는 장소와 채택 경로

   1. 제품을 에이전트가 발견할 수 있는 곳에 배치해야 한다. 에이전트 마켓플레이스와 MCP 레지스트리 등 에이전트가 도구를 찾을 법한 모든 장소가 대상이다.
   2. 발견에서 워크플로 삽입까지의 마찰을 줄여야 한다. 에이전트가 제품을 찾았는데 데모 세 번, 영업 담당자와의 이메일 교환 같은 절차가 필요하다면 사용자에게 추천하지 않는다.
   3. 에이전트는 “이 도구를 써보라. 단, 먼저 여러 절차를 거쳐야 한다”고 말하며 추천하지 않는다. 따라서 즉시 시험하고 연결할 수 있는 API·문서·설치 흐름이 필요하다.
   4. 사람들이 실제로 고통을 겪는 순간을 중심으로 충분한 웹 콘텐츠를 만들면 에이전트가 문제와 제품을 연결할 기회가 늘어난다.

5. 에이전트 애드보커시의 조직 내 위치

5.1. 엔지니어링·제품·마케팅에 모두 걸친 역할

1. 경계가 흐려지는 이유

   1. DevRel과 애드보커시가 엔지니어링인지, 제품인지, 마케팅인지 묻는다면 답은 “그렇다, 모두 그렇다”이다.
   2. 에이전트의 등장으로 이 경계가 더 선명해진 것이 아니라 조직 전체의 역할 경계가 더 흐려졌다.
   3. 이 흐릿함은 단점만은 아니다. 직원의 기술과 제품의 당면 과제에 따라 역할을 섞고 맞출 수 있는 여지가 커진다.

2. 엔지니어링형 에이전트 애드보커시

   1. 엔지니어링 팀과 직접 협력해 에이전트가 MCP 서버를 통해 제품과 대화하는 인터페이스를 만든다.
   2. 에이전트가 어떤 작업을 성공적으로 수행하는지 확인하는 평가(evals)를 만들고, 호출·실패·복구를 계측(instrumentation)한다.
   3. CodeScaleBench 같은 실행 추적을 사용해 에이전트가 실제로 겪는 마찰을 기술적으로 제거한다.

3. 제품형 에이전트 애드보커시

   1. 에이전트가 제품을 발견하고 이해하고 호출하고 결과를 받는 종단간(end-to-end) 에이전트 경험을 소유한다.
   2. 평가 결과를 제품 팀이 사용할 수 있는 요구사항으로 번역하고, 에이전트 경험을 판단하는 루브릭(rubric)을 만든다.
   3. 에이전트가 콘텐츠를 어떻게 접하고 어떤 순서로 실패하는지까지 제품 품질의 일부로 다룬다.

4. 마케팅형 에이전트 애드보커시

   1. 에이전트가 퍼널에 진입해 제품을 발견하는 경로와 파이프라인 생성(pipe generation)을 소유한다.
   2. GEO 실험으로 어떤 프롬프트에서 제품이 언급·추천되는지 확인하고, 에이전트가 개발자에게 추천을 전달하도록 만든다.
   3. 에이전트만 퍼널에 넣는 것이 아니라, 에이전트를 따라오는 인간 개발자까지 제품 채택으로 연결한다.

6. DevRel의 본질은 유지된다: 교육·커뮤니티·피드백·신뢰

6.1. 바뀐 대상에 맞춘 enablement

1. 교육 대상의 확장

   1. DevRel의 핵심인 enablement는 여전히 중요하다. 달라진 것은 교육 대상의 직무와 구성이다.
   2. 개발자는 에이전트 플릿을 오케스트레이션하는 새로운 일을 하므로, 그 업무를 수행할 수 있도록 교육해야 한다.
   3. 동시에 에이전트도 교육해야 한다. 문서를 기계가 읽을 수 있게 만들고, 에이전트 친화적 API와 명확한 도구 계약(tool contract)을 제공해야 한다.
   4. 목표는 인간 개발자와 그들이 사용하는 에이전트가 같은 제품을 최대한 쉽게 활용하게 만드는 것이다.

2. 사람과 에이전트가 함께 있는 커뮤니티

   1. 인간 대 인간의 연결은 오히려 더 중요해진다. 개발자가 커뮤니티에 자신의 에이전트도 함께 데려오는 상황을 고려해야 한다.
   2. Discord에 Claude 같은 에이전트를 들여와 대화를 기록하게 하면 개인정보와 데이터 관리 문제가 새롭게 발생한다.
   3. 커뮤니티 빌더는 누가 무엇을 기록하고, 에이전트가 어떤 대화를 학습·전달하며, 사람의 동의가 어디까지 필요한지 설계해야 한다.

6.2. 양방향 피드백과 서로 다른 신뢰도

1. 인간 개발자의 목소리를 조직으로 가져오기

   1. 에이전트를 사용하는 개발자의 목소리를 제품 조직으로 되돌리는 책임은 여전히 DevRel에 있다.
   2. “에이전트가 특정 도구를 이해하지 못한다”, “토큰을 너무 많이 쓴다”, “에러에서 돌아오지 못한다” 같은 관찰을 제품 개선으로 연결해야 한다.
   3. 동시에 수천 개의 에이전트를 실행해 인간 개발자에게는 하기 어려운 규모의 실험을 반복할 수 있다. 개발자는 매번 대화를 나누고 싶어 하지 않을 수 있지만 에이전트는 같은 조건에서 계속 테스트할 수 있다.

2. 인간과 에이전트에게 각각 신뢰를 얻기

   1. 인간 개발자에게는 Claude가 만든 티가 나는 저품질 콘텐츠, 즉 “Claude의 슬롭(slop)”을 던지지 말아야 한다. 영업 담당자(AE)에게도 그런 콘텐츠를 멈추라고 해야 한다.
   2. 사람들은 이미 그런 콘텐츠를 알아보고 좋아하지 않는다. 인간에게 신뢰를 얻으려면 실제 경험과 정확한 정보가 필요하다.
   3. 반대로 Claude는 어떤 이유에서인지 자기와 비슷한 슬롭을 좋아하는 경향이 있다. 에이전트는 자기 생태계에서 나온 콘텐츠를 편향되게 선호할 수 있다.
   4. 에이전트 대상 콘텐츠는 구조화되어 있기만 하면 긴 대시(em dash)를 많이 사용하는 등 인간에게는 어색한 형태도 작동할 수 있다. 인간과 에이전트의 신뢰 형성 규칙은 다르다.

7. 에이전트를 위한 ‘턱 낮춤’과 즉시 실행 항목

7.1. Curb cut 비유가 뜻하는 것

1. 특정 사용자를 위한 경사로가 모두에게 이익이 되는 구조

   1. 턱 낮춤(cur­b cut)은 휠체어 사용자가 이동하도록 만든 경사로다.
   2. 하지만 지금은 바퀴가 달린 유모차, 여행 가방, 자전거 등 모든 사람이 그 경사로의 혜택을 누린다.
   3. 에이전트를 위해 문서·API·발견 경로를 정비하면 에이전트만 편해지는 것이 아니라, 그 뒤에 있는 인간 개발자도 제품에 도달하기 쉬워진다.

2. 방 안에 사용자가 한 명 더 들어온 상황

   1. 에이전트는 인간을 대체하는 별도의 고객이 아니라 인간을 섬기는 새로운 사용자다.
   2. 에이전트가 제품을 사용하고 추천하고 워크플로에 연결하지만, 최종 가치는 그 에이전트를 사용하는 사람에게 돌아간다.
   3. DevRel은 에이전트와 인간을 서로 분리하지 않고 함께 일하는 시스템으로 설계해야 한다.

7.2. 직무별로 오늘 시작할 실험

1. DevRel 담당자의 첫 실험

   1. 코딩 에이전트가 제품 문서를 처음부터 끝까지 사용하도록 지시한다.
   2. 에이전트의 실행 대화 기록을 살펴보며 어디에서 막히고, 어떤 문장을 오해하고, 어떤 호출을 재시도하는지 확인한다.
   3. 그 기록을 기반으로 에이전트 경험 보고서(Agent Experience Report)를 만들고 문서와 도구 계약을 개선한다.

2. GTM·마케팅 담당자의 첫 실험

   1. 실제 사용자의 고충을 담은 프롬프트를 여러 개 작성해 GEO 실험을 구성한다.
   2. 제품이 단순히 언급되는지, 실제로 추천되는지 구분해 측정한다.
   3. 웹사이트 콘텐츠를 바꾼 뒤 웹 검색을 사용하는 에이전트의 언급·추천 비율이 상승하는지 확인한다.

3. 공유 가능한 출발점

   1. Stephanie Jarmak은 자료 자체를 에이전트가 읽을 수 있게 만들었고, QR 코드와 두 개의 토이 저장소에 시작용 템플릿을 넣었다.
   2. 청중은 화면을 급히 촬영하지 않아도 관련 데이터와 예시를 에이전트에게 전달해 활용할 수 있다.
   3. 에이전트 애드보케이트는 별도의 거대한 조직을 기다리기보다 문서 읽기 실험, 실행 추적, GEO 프롬프트 테스트부터 시작할 수 있다.

주요 발언 모음

“개발자의 역할이 근본적으로 바뀌고 있다면, 개발자 애드보케이트의 역할도 바뀌어야 한다.”

“에이전트는 도구의 사용자이면서 도구의 추천자다.”

“에이전트가 한 턴 전체를 실패에 쓰고 스스로 고쳤다고 해도, 그건 여전히 고쳐야 할 마찰이다.”

“에이전트를 위한 턱 낮춤을 만들면, 그 뒤의 인간 경로도 함께 정리된다.”

“에이전트가 제품을 발견한 뒤 워크플로에 넣기까지 데모 세 번과 영업 이메일을 거쳐야 한다면, 에이전트는 사용자에게 그 제품을 추천하지 않는다.”

“인간 개발자에게 Claude 슬롭을 보내지 말고, 영업 담당자에게도 그러지 말라고 해야 한다. 모두가 그것이 무엇인지 알고 아무도 좋아하지 않는다.”

핵심 데이터 & 수치

• 약 1980년대: 소프트웨어 에반젤리즘이라는 일방향 제품 전파가 사용됐다.
• 2010년대: 개발자 애드보커시가 양방향 피드백 루프와 함께 확산됐다.
• 2026년: 개발자는 에이전트 플릿을 오케스트레이션하고 AI fluency를 요구받는 역할로 이동하고 있다.
• 0건 → 약 12,000건: Stephanie Jarmak의 GitHub 커밋은 지난해 거의 0건에서 현재 약 12,000건으로 늘었고, 멀티에이전트 오케스트레이션 프레임워크 오픈소스 메인테이너가 됐다.
• 수백 개 작업: CodeScaleBench는 소프트웨어 개발 생명주기를 반영한 수백 개의 에이전트 작업으로 구성됐다.
• 수천 개 추적: Sourcegraph 도구가 포함된 에이전트 실행에서 수천 개의 trace를 확보해 실패 지점과 토큰·시간 마찰을 분석했다.
• 65% 추천: 코드 인텔리전스 도구를 적극적으로 비교 구매하는 프롬프트에서는 Sourcegraph가 65%의 비율로 추천됐다.
• 0건 언급: 공유 라이브러리 변경으로 다운스트림 서비스를 망가뜨리는 실제 고충 프롬프트에서는 Sourcegraph가 한 번도 언급되지 않았고, 위키 페이지 작성이 대신 제안됐다.
• Claude Sonnet 4와 4.6: 최신 모델이 더 정확한 제품 정보를 알 것이라는 기대와 달리, 4.6은 오래된 Cody 제품을 이전 모델보다 더 많이 추천했다.
• 1턴 비용: read line과 start line처럼 도구 파라미터를 잘못 고르면 에이전트가 복구하더라도 전체 실행 턴 하나를 소모한다.

결론 및 시사점

1. 개발자 애드보케이트의 ‘종말’은 직무 폐지가 아니라 관계 맺는 대상의 확장이다. 개발자와 에이전트를 동시에 이해하는 에이전트 애드보케이트가 필요하다.
2. 에이전트는 문서를 읽고 API를 호출하는 사용자이며, 제품을 선택하고 설치하고 추천하는 유통 채널이기도 하다.
3. 개발자 경험만으로는 부족하므로 에이전트 성공률, 실패 복구, 토큰 수, 응답 속도, 워크플로 삽입까지 측정해야 한다.
4. CodeScaleBench 같은 반복 가능한 벤치마크와 실행 trace는 에이전트가 실제로 겪는 마찰을 추측이 아닌 데이터로 바꾼다.
5. GEO는 비교 구매 키워드를 넣는 데서 끝나지 않는다. 실제 고통이 제시됐을 때 제품이 해결책으로 연결되는지 측정해야 한다.
6. 오래된 모델 출력과 낡은 웹 콘텐츠가 인터넷에 누적되므로, 권위 있는 출처·실시간 도구·provenance·현재 사례·차트·FAQ를 지속적으로 제공해야 한다.
7. 에이전트 마켓플레이스와 MCP 레지스트리에 제품을 노출하고, 발견에서 설치·호출까지의 데모와 영업 절차를 줄여야 한다.
8. DevRel은 엔지니어링·제품·마케팅의 교차점에서 MCP 인터페이스와 평가, 종단간 경험, GEO 파이프라인을 제품 상황에 맞게 조합할 수 있다.
9. 교육·커뮤니티·피드백·신뢰라는 DevRel의 본질은 유지된다. 다만 사람에게는 진짜 경험을, 에이전트에게는 구조화된 최신 정보를 제공하는 이중 전략이 필요하다.
10. 오늘 바로 코딩 에이전트로 문서를 테스트해 Agent Experience Report를 만들고, GEO 프롬프트에서 언급과 추천을 분리해 측정하는 것이 새로운 DevRel의 출발점이다.