스킨 인 더 게임

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Please paste the content (excluding the source line you already provided) and I’ll convert it to Korean while preserving the original formatting and code blocks.

왜 이 글을 쓰는가

스스로에게 하는 메모: 기술을 설명하는 데서 그만두고 직접 구축하자. 나는 꽤 운이 좋은 사람이다. 호기심 덕분에 인생 전반에 걸쳐 놀라운 상황들을 경험했다. 언어를 배우고, 흥미로운 곳에 살았으며, 약 6년 전 인터넷이 어떻게 작동하는지 배우고 싶다고 결심했다. 그 호기심은 내가 정말 자랑스러워하는 DevOps, 클라우드, 쿠버네티스 분야의 경력으로 이어졌다.

오늘날 DevRel(Developer Relations)로서 호기심은 내가 하는 모든 일의 원동력이다. 역할은 회사마다, 심지어 주마다 크게 달라진다. 어느 주에는 블로그 포스트나 컨퍼런스 발표를 위한 새로운 사용 사례를 준비하고, 다음 주에는 동료들과 웹세미나와 콘텐츠 이니셔티브를 협업하거나 마케팅, 제품, 고객 성공 팀 사이의 다리 역할을 한다. 호기심 많은 사람들이 번창할 수 있는 직업이며, 나 역시 그런 경험을 해왔다.

설명과 구현 사이의 격차

내게는 단점이 하나 있다. 내 경력에는 길고 뚜렷한 “개발자 단계”가 포함되지 않았다. 나는 제품을 처음부터 만들고, 출시하고, 부수고, 그 결과와 함께 살아본 적이 몇 년도 되지 않는다. 이는 의미 있는 기술 경력을 위해 필수 조건은 아니지만, 내가 점점 더 의식하게 된 격차이다.

인프라, Kubernetes, 그리고 클라우드‑네이티브 툴링에 대한 호기심이 깊어질수록 내 관점의 한계도 뚜렷해졌다. 나는 시스템, 패턴, 트레이드‑오프를 설명할 수 있었지만, 항상 그것을 직접 체감하는 사람은 아니었다. 작업에 가까이 있었지만, 항상 그 안에 있지는 않았다.

그 격차는 내가 발표 중에 비즈니스 사례를 제시해야 할 때 가장 뚜렷하게 드러난다. 새로운 Kubernetes 아키텍처나 흥미로운 개발자 도구를 탐구할 때 나는 같은 안전한 데모—todo 리스트, 설문 조사 앱, 습관 추적기—에 의존한다. 이들은 익숙하고 위험이 적으며 설명하기 쉬우나, 동시에 흥미가 없고 너무 이론적이다.

MetalBear and mirrord

저는 mirrord를 만든 회사인 MetalBear에서 일하고 있습니다. mirrord는 개발자가 Kubernetes와 작업하는 방식을 근본적으로 바꾸는 도구입니다. 로컬 프로세스가 원격 Kubernetes 환경에서 실제 시스템, 실제 트래픽, 실제 의존성과 상호 작용할 수 있게 해 주며, 컨테이너화하거나 CI/CD를 트리거할 필요가 없습니다. 그런데도 저는 종종 같은 지루한 스톡 애플리케이션을 사용해 시연합니다. 단순한 폴링 앱에 다크 모드를 추가하는 것은 복잡하고 고위험 환경을 위해 설계된 도구의 가치를 충분히 보여주지 못합니다.

때때로 저는 실무자라기보다 역사가처럼 느껴집니다. 어떻게 동작하는지, 다른 사람들이 어떻게 사용하는지, 무엇을 만들 수 있는지 수동적으로 설명만 하고, 오늘 존재하는 것을 적극적으로 형성하지 못하는 것이죠. 솔직히 말해서, 지난주에 일어난 일을 기록하는 역사가 되기보다 다음에 일어날 일을 직접 영향을 미치는 사람이 되고 싶지 않나요?

행동에 대한 편향

제가 지금 원하는 것은 간단합니다: 행동에 편향된 DevRel이 되고 싶습니다. 오늘날 이용 가능한 방대한 양의 정보, 자원, 그리고 AI 도구 덕분에 아이디어와 실제 프로젝트 사이의 거리가 그 어느 때보다 짧아졌습니다. 피드백 루프는 더 촘촘해지고, 도구는 더 좋아졌으며, 시도와 실패의 비용도 그 어느 때보다 낮아졌습니다.

저는 이제 단순히 논평가로서 쿠버네티스와 클라우드‑네이티브 도구에 대해 이야기하는 것을 멈추고, 직접적인 이해관계를 가진 사람으로서 그것들과 교류하고 싶습니다. 단순히 개발자로서가 아니라, 실제 문제를 식별하고, 해결책을 제시하며, 적절한 도구를 선택하고, 아이디어 단계부터 전달 단계까지 전체 과정을 책임지는 사람으로서 말이죠. 저는 컨퍼런스 발표에서만 멋지게 보이는 프로젝트가 아니라, 실제 사용자와 실제 제약, 그리고 실제 트레이드‑오프에 맞서는 프로젝트를 만들고 싶습니다.

그러한 프로젝트 중 일부는 실패할 것입니다. 일부는 정체될 수도 있습니다. 어떤 것은 우연히 성공할 수도 있겠죠. 괜찮습니다. 중요한 것은 성공이 아니라 참여이며, 실제로 이해관계를 가지고 매일 이야기하는 도구들을 사용해 누군가에게 실제로 존재할 수 있는 무언가를 제공하려는 노력입니다.

공개적으로 만들기

개발자나 제품 소유자의 입장을 완전히 체험하는 것이 쉽지는 않을 것이며, 바로 그것이 요점이다. 회의에서 요구한다는 이유만으로 특정 도구나 기술 스택을 억지로 프로젝트에 끼워 넣지 않을 것이다. 나는 제작자의 관점에서 접근하여 각 프로젝트에 가장 적합한 방향을 결정할 것이다.

이것이 나에게 어떤 라벨을 붙이든—개발자, DevRel, DevOps 엔지니어—별로 신경 쓰지 않는다. 그런 것들은 크게 중요하지 않다. 중요한 것은 행동을 선택하고, 누군가에게 의미 있는 것을 만들며, 아이디어를 완전히 다듬기 전에 세상에 내놓고, 보호받기보다 현실에 노출되어 배우는 것이다.

공개적으로 만드는 것은 그것을 실천하는 가장 솔직한 방법처럼 느껴진다. 이는 위험을 높이고, 진정한 공감 능력을 향상시키며, 명확성을 강요한다. 개발자를 더 잘 이해하고 싶다면, 앞으로 나아갈 최선의 방법은 더 많은 설명이 아니라 공유된 경험이다.

Call to Action

저는 이 여정을 공개적으로 그리고 정기적으로 공유할 계획입니다: 제가 만들고 있는 것, 잘 되는 것, 잘 안 되는 것, 그리고 그 과정에서 배우는 것들을 말이죠. 이것이 여러분에게 공감된다면 진심으로 여러분의 이야기를 듣고 싶습니다. 더 많이 행동하고 말은 적게 하려는 마음이 있다면, 여러분이 만들고자 하는 것이 무엇인지 알려 주세요. 무엇을 검증하려 하고, 세상에 어떤 가치를 제공하고 싶으신가요?

2026년, 모두 행복하세요!