AI가 무엇이든 발행하는 것을 그 어느 때보다 쉽게 만들면서, 우리는 모두 콘텐츠의 홍수 속에 빠져 있으며 그 중 상당수는 소음(noise)에 불과합니다. 게다가 개발자들은 다른 어떤 오디언스보다도 '슬롭 (slop, 저질 콘텐츠)'을 귀신같이 알아차리며, 한 번 신뢰를 잃으면 더 자극적인 헤드라인을 사용한다고 해서 다시 얻을 수 없습니다. 따라서 DevRel (Developer Relations)에서의 우리의 역할은 그 더미에 무언가를 더 얹는 것이 아닙니다. 우리가 무언가를 발행했을 때 개발자들이 실제로 멈춰 서서 읽을 수 있을 만큼 충분한 신뢰를 얻는 것입니다. 여기서 질문이 남습니다.

어떻게 하면 개발자의 신뢰를 얻는 콘텐츠 전략을 구축할 수 있을까요?

압도적이라는 말로는 부족했습니다!

솔직히 제 첫 생각은 '지금 농부가 되기엔 너무 늦었나?'였습니다. 😅 농담은 제쳐두고, 저는 이 혼란을 정리할 방법이 필요했기에 몇 가지 질문으로 시작했습니다:

• 아이디어는 어디에서 오는가?
• 어떤 종류의 콘텐츠를 만들 수 있는가?
• 각 콘텐츠는 누구를 위한 것인가?
• 마지막으로, 무엇을 우선순위에 둘지 어떻게 결정하는가?

1단계: 모든 아이디어를 테이블 위에 올려놓기

무엇을 만들지 결정하기 전에, 우리가 어떤 콘텐츠 테마를 가지고 있는지 알아야 했습니다. 여기서 테마란 완성된 콘텐츠가 아니라, Vega 성능 개선 또는 _우리 MCP 서버 시작하기_와 같은 아이디어나 주제를 의미합니다. 그래서 저는 이러한 테마들이 어디에서 오는지 수집하는 것부터 시작했습니다. 우리 백로그 (backlog)에 있는 모든 테마는 반드시 다음 소스 중 적어도 하나로 거슬러 올라가야 합니다:

• 개발자의 목소리 (Voice of the Developer). 개발자들이 실제로 우리에게 무엇을 말하고 있는가? 포럼 게시글, GitHub 이슈, 이벤트 대화, 설문 조사 데이터, DM 등입니다. 우리가 그들이 원할 것이라고 추측하는 것이 아닙니다.
• 목표 (Goals). 팀과 조직으로서 우리가 달성하고자 하는 것은 무엇인가? 만약 어떤 콘텐츠가 우리가 약속한 무언가로 연결되지 않는다면, 우선순위를 낮출 가치가 있습니다.
• 시장 출시 (Go To Market). 무엇이 출시되는가? 새로운 디바이스, SDK 출시, Appstore API 등입니다. 제품이 무언가를 출시한다면, 개발자들은 그것을 사용하는 데 도움이 필요할 것이며 우리는 이에 대해 계획을 세워야 합니다.
• 제품 직접 사용하기 (Walk the product). 우리가 직접 제품을 사용하여 빌드했을 때 무엇을 발견했는가? 개발자의 페인 포인트 (pain point)가 되기 전에 우리가 마주한 마찰 (friction)을 완화하는 것이 중요합니다.
• 우리의 경험 (Our own experience). 수년간 이 일을 해온 것을 바탕으로, 개발자들에게 무엇이 필요하다고 생각하는가? 이것은 가장 주관적이며 과도하게 비중을 두기 가장 쉬운 요소이므로, 우리는 이를 다섯 가지 목소리 중 하나로 취급하며, 결코 방 안에서 가장 큰 목소리가 되지 않도록 합니다.

Where DevRel content comes from

소스들이 명시되었으므로, 저는 어떤 스프린트 (sprint)의 백로그 (backlog)라도 살펴보고 우리가 범위를 제대로 다루고 있는지 빠르게 확인할 수 있습니다. 만약 이러한 소스 중 어느 하나라도 조용하다면, 다른 것을 만들기 전에 대화를 나눠볼 가치가 있습니다.

2단계: 각 아이디어에 적합한 형식 선택하기

테마 목록이 확보되면, 다음 결정 사항은 각 테마가 어떤 형태를 취해야 하는지 파악하는 것이었습니다. 이 지점에서 팀들은 보통 기본적으로 자신들이 선호하는 형식을 선택하곤 합니다 (예: 우리는 영상 팀이다, 우리는 블로그를 좋아한다, 누군가는 워크숍을 사랑한다). 저는 그런 관행을 멈추고 싶었습니다.

그래서 제가 가장 먼저 한 일은 우리가 만들 수 있는 모든 형식을 적고, 각각 대략 어느 정도의 시간이 걸리는지, 어디에 게시되는지, 그리고 실제 대상이 누구인지를 기록하는 것이었습니다.

Types of Developer Content

모든 형식을 테이블 위에 올려두고 나면, 특정 주제에 대해 하나를 선택하는 것은 판단의 영역이 되지만, 결코 무작위적인 선택은 아닙니다. 제가 사용하는 대략적인 경험칙(rule of thumb)은 다음과 같습니다:

• 시각적인 것이라면, 보여주세요 → 비디오 (Video). UI, 장치 상호작용, 또는 화면 / IDE 흐름이 포함된 모든 것은 기본적으로 비디오 튜토리얼 (video tutorial) 또는 **라이브 스트림 / 오피스 아워 (livestream / office hours)**가 됩니다. 누군가에게 "왼쪽을 누르고, 그다음 OK를 누른 뒤, 다음 일반적인 화면이 나올 때까지 기다리세요"라고 말하는 튜토리얼은 해당 매체(medium)의 특성에 역행하는 것입니다.
• 일련의 결정 과정이라면, 글로 쓰세요 → 텍스트 (Written). 아키텍처 선택, 트레이드오프 (trade-offs), 그리고 "왜 이것인가, 왜 저것이 아닌가"에 대한 글은 기술 튜토리얼 (technical tutorial) 또는 **사고 리더십 기사 (thought leadership article)**에 적합합니다. 독자들은 내용을 훑어보고, 건너뛰며, 정보에 기반한 결정을 내릴 수 있습니다.
• 직접 만들어봐야 한다면, 실습 위주로 구성하세요 → 핸즈온 (Hands-On). 결과물이 "개발자의 로컬 머신에서 실행되는 무언가"일 때, 이는 코드 랩 (code lab), 샘플 앱 (sample app), 또는 **보일러플레이트 / 템플릿 (boilerplate / template)**이 됩니다. 글로 된 설명만으로는 충분하지 않습니다. 이를 오프라인 버전으로 진행하면 **워크숍 (workshops)**이 됩니다.
• AI가 작업을 수행한다면, AI의 형태를 갖추세요 → AI. 개발자가 이 문제를 해결하기 위해 Claude나 Kiro와 페어 프로그래밍 (pair-programming)을 할 예정이라면, 콘텐츠는 반드시 그 워크플로 (workflow) _내부_에 녹아들어야 합니다. 여기서 에이전트 기술 (agent skills), 프롬프트 라이브러리 (prompt libraries), MCP 서버 설정 (MCP server configurations), 그리고 **AI 임베디드 튜토리얼 (AI-embedded tutorials)**이 단순한 신기한 요소가 아니라 제 자리를 잡게 됩니다.
• 특정한 순간(moment)이라면, 그 순간을 만드세요 → 텍스트 + 소셜 (Written + Social). 출시, 마일스톤 (milestones), 커뮤니티의 승리, 큰 배움 등입니다. developer.amazon.com의 블로그 포스트 (Blog posts), 사례 연구 / 스포트라이트 (case studies / spotlights), 그리고 LinkedIn 및 dev.to의 **소셜 콘텐츠 (social content)**가 이에 해당합니다. 깊이보다는 도달 범위와 타이밍에 최적화됩니다.

이것들은 결코 엄격한 규칙이 아닙니다. 많은 테마가 하나 이상의 형식 (예: 출시 시 블로그, 영상, 샘플 앱을 모두 활용)을 갖기도 하지만, 이러한 경험 법칙 (rule of thumb)은 첫 번째 형식 선택이 덜 임의적으로 느껴지게 하며, 우리가 그 규칙에서 벗어날 때 그 이유를 정당화하도록 강제합니다.

이제 우리는 테마가 무엇인지, 그리고 그것이 어떤 형태를 띨지 알게 되었습니다. 마지막 질문은 이것이 개발자의 여정 (developer's journey) 중 어디에 속하느냐 하는 것인데, 이는 우리가 활성화 (activation)를 목표로 할 지점을 결정하는 방식이기 때문입니다.

3단계: 각 아이디어를 개발자 여정의 단계에 매핑하기

모든 개발자는 새로운 플랫폼에 도착했을 때 대략적으로 동일한 단계를 거칩니다. 플랫폼을 발견하고 (discover), 자신에게 맞는지 평가하며 (evaluate), 실제로 그것을 사용하여 무언가를 구축하고 (build), 그리고 (바라건대) 출시하고 (ship), 성장시키며 (grow), 수익화 (monetise)합니다. 만약 우리의 모든 콘텐츠가 "발견 (discover)" 단계에만 머물러 있다면, 개발자들은 흥분했다가도 실제로 구축하는 데 도움이 될 만한 것이 없기 때문에 이탈 (bounce)하게 됩니다. 반대로 모든 콘텐츠가 "구축 (build)" 단계에만 있다면, 애초에 아무도 우리를 찾지 못할 것입니다.

따라서 우리는 모든 테마에 그것이 활성화하는 단계를 태그로 지정합니다. 이것은 엄격한 규칙이라기보다는 일종의 건전성 검사 (sanity check)에 가깝습니다. 분기별 아이디어 목록을 검토할 때 우리는 다음과 같이 자문합니다. "이 아이디어들이 여정 전반에 걸쳐 균형 있게 분포되어 있는가? 아니면 실수로 발견 단계의 콘텐츠만 5개 만들고, 누군가가 실제로 제품을 출시하는 데 도움이 될 만한 콘텐츠는 하나도 만들지 않고 있는가?"

Mapping DevRel content to the Developer journey

무엇을 만들지 결정하는 방법

모든 테마에 소스(source), 형식(format), 그리고 활성화 단계(activation stage)가 갖춰지고 나면, 무엇을 우선순위에 둘지 결정하는 것은 더 이상 단순한 느낌(vibes)에 의존하는 작업이 아니게 됩니다. 우리에게 남는 것은 소스, 형식, 그리고 여정 단계(journey stages) 전반에 걸쳐 잘 분산된, 잘 큐레이션된 백로그(backlog)이며, 이는 제가 처음에 마주했던 산더미 같은 양보다 훨씬 덜 압도적입니다. 그리고 새로운 아이디어가 들어오면 동일한 세 번의 검토 과정을 거칩니다. 이 세 가지를 모두 통과하는 것은 백로그에 추가되어 스프린트(sprints) 기간 동안 할당됩니다. 하지만 궁극적으로 이 방식은 회의실에 있는 모든 이해관계자—제품(Product), 마케팅(marketing), 제 팀, 그리고 개발자 자신들—에게 방어 가능한 답변을 제공합니다.

그리고 개발자의 목소리(Voice of the Developer)에 대해 덧붙이자면, Amazon 기기에 대해 저희가 다루어 주기를 바랐던 내용이 있다면 댓글로 남겨주세요. 백로그에 추가하도록 하겠습니다 😉.