M365 FM에서 제공하는 마이크로소프트 지식나겟, 또 다른 에피소드에 오신 것을 환영합니다.진행을 맡은 미르코 피터스입니다.오늘의 주제는 거의 모든 사람이 들어는 받지만 제대로 이해하는 사람은 드문 플랫폼 엔지니어링입니다.아마 데브옵스, 데브옵스에 대해 들어보셨을 겁니다.개발자와 운영팀이 원활하게 협업한다는 아이디어였지만, 그 과정에서 약속은 어딘가 꼬이고 말았습니다.개발자가 운영 업무까지 떠막게 되면서 시스템이 무너진 것이죠.이번 에피소드가 끝날 때 쯤이면 데브옵스에 무엇이 잘못되었는지, 내부 개발자 플랫폼이 실제로 무엇인지,골든패스가 어떻게 팀에게 명확한 길을 제시하는지, 그리고 왜 가장 똑똑한 엔지니어링 팀들이 벌써 이를 구축하고 있는지 이해하게 될 것입니다.데브옵스가 남긴 혼란, 그 시작점으로 돌아가 봅시다.데브옵스는 개발자와 운영 사이의 벽을 허물겠다는 단순하지만 훌륭한 목표를 가진 아이디어였습니다.더 이상 코드를 담장 너머로 던져두고 잘 되길 바라는 일은 없어야 했죠.시프트 레프트, 쉬프트 레프트를 통해 테스트, 보안, 운영을 프로세스 초기 단계로 옮기는 것이 없습니다.더 빠른 전달, 더 적은 인수 인계, 더 큰 책임감이 기대되었습니다.이론적으로는 완벽해 보였습니다.하지만 실제로는 무언가 잘못되었습니다.시프트 레프트는 단순히 책임을 옮긴 것이 아니라 업무를 가중시켰습니다.코드만 작성하고 티켓을 발행하던 개발자가 이제는 인프라, 보안, 모니터링, 후버네티스, CI, CD파이프 라인, 비밀관리, 그리고 들어본 적도 없는 15가지 클라우드 서비스까지 모두 책임지게 되었습니다.한 사람이 제품을 개발하면서의 모든 것을 처리해야 하는 상황입니다.실제 상황은 이렇습니다.어떤 팀이 기능을 테스트하기 위해 새로운 환경을 구축하려고 합니다.데브옵스 이전에는 티켓을 발행하고 기다리면 되었습니다.

데브옵스 도입 후에는 스스로 해결해야 합니다.이론상으로는 좋아 보이지만 이제는 테라폼 모듈을 작성하고, 쿠버네티스 클러스터를 구성하고, 네트워크 규칙을 설정하고, 모니터링을 연결하고, 비밀관리를 해결하고, 보안정책이 적용되었는지 확인해야 합니다.다른 사람이 1시간 만에 처리하던 티켓이 이제는 개발자의 사흘을 잡아먹습니다.제품 코드를 작성하지 못하는 사흘인 셈입니다.개발자들은 YAML 파일과 실음하고 로드 밸런서가 왜 트래픽을 제대로 라우팅하지 않는지 디버깅하느라 시간을 보냅니다.정신적 부담이 엄청납니다.모든 팀이 각자의 파이프라인, 배포 스크립트, 모니터링 대시보드를 직접 구축하게 됩니다.다들 업무에 쫓기다 보니 결국 무언가를 대충 넘기게 됩니다.마감기한이 금요일이라는 이유로 보안점검은 건너뛰게 됩니다.테스트 환경을 종료하는 것을 잊어버려서 클라우드 비용이 2배가 되어도 아무도 알아차리지 못합니다.그리고 새벽 2시에 문제가 발생하면 그것을 만든 개발자만이 유일한 해결사로 호출됩니다.이건 지속가능하지 않으며 지금이 문제가 그 어느 때고 다 중요한 이유는 다음과 같습니다.클라우드의 복잡성은 계속해서 커지고 있습니다.매년 더 많은 서비스와 도구가 쏟아지고 더 많은 결정을 내려야 하기 때문입니다.이제 AI 코딩 도구를 사용하면 개발자가 그 어느 때보다 빠르게 하루에 10배, 20배, 심지어 30배 더 많은 코드를 배포할 수 있습니다.하지만 그 모든 코드에도 인프라, 보안, 모니터링은 여전히 필요합니다.더 나은 시스템 없이 코드만 늘어나는 것은 혼란만 가속할 뿐입니다. YAML 과테라 폼에 파묻혀 있다고 느낀다면 당신만 그런 것은 아닙니다.이는 개인의 잘못이 아닙니다.시스템적인 문제입니다.현재의 모델은 플랫폼 엔지니어링의 본질을 왜곡했습니다.그럼 해결책은 무엇일까요?바로 플랫폼 엔지니어링입니다.

가장 쉽게 이해하는 방법은 다음과 같습니다.이 분야는 개발자를 위해 복잡성을 흡수하는 내부계층을 구축합니다.큰 사무실 건물에 들어간다고 상상해보세요.누가 어떤 층에 접근할 수 있는지, 어떤 보안카드가 작동하는지, 비상구는 어디인지 고민할 필요가 없습니다.안내데스크가 그 모든 것을 처리해주니 당신은 그저 들어가서 업무를 시작하면 됩니다.그것이 바로 플랫폼 엔지니어링이 개발자에게 해주는 일입니다.모든 개발자가 쿠버네티스, 페라폼, 네트워킹, 보안의 전문가가 될 필요 없이중앙 플랫폼 팀이 그 모든 복잡성을 관리하는 계층을 만듭니다.개발자는 간단한 인터페이스에서 버튼을 클릭하거나, 명령어를 실행하거나, 양식을 작성하기만 하면 플랫폼이 나머지를 모두 처리합니다.하지만 여기서 중요한 점은 이것이 데브옵스, 데브옵스와는 다르다는 것입니다.데브옵스는 모든 팀이 자신의 인프라를 직접 관리하라고 했지만, 플랫폼 엔지니어링은 그것이 번아웃의 원인이 된다고 봅니다.대신 플랫폼 팀은 공통작업을 처리할 수 있는 표준화되고 검증된 안전한 길, 즉 포장된 도로를 제공합니다.그들은 도로를 만들고 유지관리하며, 제품팀은 그 위를 달리기만 하면 됩니다.플랫폼 엔지니어링의 핵심 결과물은 내부 개발자 플랫폼, 줄여서 IDP라고 불리는 것입니다.반복적인 모든 작업을 자동화하는 셀프 서비스 시스템이라고 생각하면 됩니다.인프라 프로비저닝, CI, CD 파이프라인, 보안검사, 모니터링 등이 모두 내장되어 표준화됩니다.구체적인 예시를 들어보겠습니다.플랫폼 없이 새로운 서비스를 배포하려면 개발자는 며칠 동안 인프라를 설정하고, 파이프라인을 작성하며, 모니터링을 구성해야 합니다. IDP가 있으면 UI에서 배포 버튼을 클릭하거나 명령어 하나만 실행하면, 플랫폼이 프로비저닝, 패스트, 모니터링, 배포까지 며칠 걸릴 작업을 몇 분 만에 처리합니다.

그렇다면 이것이 당신에게 어떤 의미일까요?더 이상 인프라 잡무에 매달리지 않고, 자신의 실제 제품을 위한 전문가가 될 수 있습니다.테라폼 상태 파일이 왜 손상되었는지 디버깅하는 대신, 고객에게 중요한 기능을 구축하는 본연의 업무로 돌아가는 것입니다.그것이 바로 핵심입니다.쉽게 풀어본 내부 개발자 플랫폼입니다.자, 내부 개발자 플랫폼이 실제로 무엇인지 자세히 살펴보겠습니다.모든 것을 하나의 시스템으로 통합하는 엔진입니다. CI, CD 파이프 라인, 인프라 템플릿, 보안 정책, 모니터링, 그리고 로깅까지.서로 연결해야 하는 6개의 개별 도구 대신 말이죠.비유를 하나 들어볼게요.처음부터 직접 요리하는 것과 자판기를 사용하는 것의 차이로 생각해보세요.직접 요리하려면 재료를 사고, 채소를 썰고, 양념을 맞추고, 불을 지켜봐야 하죠.결정할 것도 많고, 단계도 많고, 실수할 가능성도 많습니다.반면 자판기는 버튼 한 번만 누르면 결과물이 나옵니다.결정은 줄어들고, 결과는 빠르며, 품질은 일정하죠. IDP가 바로 그 자판기입니다.개발자는 인프라가 어떻게 프로비저닝되는지, 비밀 정보가 어디에 저장되는지 알 필요가 없습니다.그저 버튼만 누르면 되니까요.그 자판기 안에는 무엇이 들어있을까요?핵심 구성 요소들은 꽤 표준화되어 있습니다.일관된 빌드를 위한 CI, CD 템플릿, 자동환경 구성을 위한 인프라 프로비저닝,구성 파일에 자격 증명이 노출되지 않도록 하는 비밀 관리,그리고 당황하지 않고 문제를 해결할 수 있는 관측성이 포함된 로깅입니다.이 모든 것이 플랫폼 팀에 의해 사전에 구성되고, 테스트되며 유지관리됩니다.구체적인 예를 들어보죠. 개발자가 명령줄에 새 서비스 생성을 입력하거나 포털에서 버튼을 클릭합니다.백그라운드에서 IDP가 올바른 구조의 새 저장소를 만들고,자동으로 테스트를 실행하는 빌드 파이프라인을 설정하며,개발 환경에 서비스를 배포하고, 로깅이 포함된 상태 확인 앤드 포인트를 추가합니다.

이 모든 과정이 단 몇 분 만에 이루어집니다.개발자는 테라폰 파일 하나 만들 필요도, 쿠버네티스 매니페스트를 설정할 필요도 없었습니다.명령어 한 줄 입력했을 뿐인데 실행 중인 서비스가 생긴 거죠.이게 왜 중요할까요? 일관성이 핵심적인 이유입니다.각 팀이 파이프라인을 직접 구축하고 배포 스크립트를 작성하면,결국 제각각인 스노우 플레이크 구성이 되어버립니다. 50개의 서비스가 있다면, 50가지의 처리 방식이 존재하는 셈이죠.문제가 생기면, 그걸 만든 사람 외에는 아무도 디버깅할 수 없습니다.만약 그 사람이 퇴사했다면, 행운을 빕니다. IDP는 모든 서비스가 같은 패턴을 따르고, 모든 배포가 동일한 파이프라인을 사용하며,모든 팀이 같은 기본 설정을 갖게 함으로써 이를 해결합니다.문제가 발생해도 패턴이 익숙하고, 해결 방법도 문서화되어 있죠.자, 이것이 여러분에게 어떤 의미일까요?만약 조직 내 50개 팀이 각기 다른 50가지 방식으로 배포하고 있다면, IDP가 정답입니다.그렇다고 팀의 자율성이 사라지는 건 아닙니다.지루하고 반복적이며 오류가 잦은 부분은 표준화하고,대신 흥미롭고 창의적인 업무는 다양하게 할 수 있다는 뜻이죠.해볼 만한 가치가 있는 거래입니다.골든패스, 그것은 가두는 우리, 케이지, 가 아니라 나아갈 길, 웨이, 입니다.골든패스에 대해 이야기해봅시다.이름은 들어보셨겠지만, 아이디어는 간단합니다.골든패스란 옳은 일을 가장 쉽게 할 수 있도록 미리 만들어진 권장 워크플로우를 의미합니다.플랫폼 팀이 이렇게 말합니다.저희는 이런 방식을 권장합니다.이미 테스트를 마쳤고, 잘 작동하며, 문제가 생기면 저희가 지원하겠습니다.권장이라는 단어에 주목하세요.골든패스는 의무가 아닙니다.개발자는 필요시의 경로를 벗어날 수 있지만, 이 경로는 빠르고 안전한 기본값이 됩니다.이미 실행 중이고, 지원되며, 문서화까지 되어 있죠.

모든 것을 처음부터 직접 알아낼 필요가 없습니다.가드레일보다는 철길이라고 생각해보세요.가드레일은 충돌할 때 여러분을 막아줍니다.반응형이며 절벽 아래로 떨어지는 것을 막아주지만, 주행을 돕지는 않습니다.철길은 경로를 따라 부드럽게 안내하므로, 어디로 꺾을지 고민할 필요가 없습니다.골든패스가 바로 그 철길입니다.단순히 실패를 막는 게 아니라, 여러분을 앞으로 나아가게 합니다.많은 팀이 여기서 실수를 합니다.개발자가 아닌 플랫폼 팀을 위한 골든패스를 만듭니다.아키텍처의 순수성, 보안 준수, 혹은 플랫폼 팀 외에는 아무도 모르는 내부 규칙에 최적화하죠.결과는 화이트보드 위에서는 훌륭해 보이지만, 실제 사용감은 형편없습니다.개발자들은 조용히 우회로를 찾고, 채택률은 떨어지며, 플랫폼 팀은 왜 아무도의 노력을 알아주지 않는지 위하에 합니다.해결책은 간단하지만 실행하기는 어렵습니다. 8출구가 필요합니다.경로가 개발자의 사용 사례에 맞지 않으면 빠져나갈 방법이 필요합니다.기본값을 재정해하거나, 자체 파이프라인을 도입하거나, 플랫폼 밖으로 완전히 나갈 수 있는 방법 말입니다.그리고 여기서 중요한 부분이 있습니다.개발자가 경로를 벗어나는 것은 실패가 아니라 피드백입니다.개발자가 골든패스를 벗어날 때마다 무언가 실질적인 정보를 얻게 됩니다.경로에 필요한 기능이 빠졌거나, 아니면 그 사용 사례가 애초에 경로에 적합하지 않은 경우죠.두 신호 모두 가치가 있습니다.실제 잘 구현된 골든패스는 이런 모습입니다.한 팀이 새로운 백엔드 서비스를 배포하려 합니다.그들은 경로를 이용합니다.적절한 구조의 템플릿 저장소, 이미 테스트된 표준 CI, CD 파이프 라인, 내장된 로깅 및 모니터링, 문제가 생겼을 때 클릭 한 번으로 되돌리는 기능을 제공받죠.며칠 걸릴 일이 몇 분 만에 끝나며, 플랫폼 팀이 경로를 유지관리함으로 문제가 생기면 그들이 해결해줍니다.

개발자가 파이프라인 디버깅 전문가가 될 필요가 없습니다.이는 여러분에게 놀랄 일이 줄어든다는 의미입니다.경로가 검증되었으니 더 빠르게 출시할 수 있습니다.보안과 모니터링이 내장되어 있어 더 안전하게 출시합니다.클릭 한 번으로 롤백이 가능하니 확신을 가지고 출시합니다.경로는 여러분을 돕기 위해 존재하는 것이지, 가로막기 위한 것이 아닙니다.사용하세요.인지 부하를 줄여줍니다.여기서 진짜 성과가 나타납니다.플랫폼이 힘든 작업을 대신해주면 개발자는 비로소 코드에 집중할 수 있습니다.어떤 쿠버네티스 버전이 실행 중인지 알 필요가 없습니다.클라우드 제공업체가 API를 바꿀 때 마다 테라폼 모듈을 업데이트할 필요도 없죠.그저 기능을 개발하기만 하면 됩니다.플랫폼 엔지니어들이 그 복잡성을 흡수하니까요.그들은 개발자가 무엇을 봐야 하고 무엇을 숨겨야 할지 결정합니다.이것은 단순한 기술적 선택이 아닌 실제 설계적 선택입니다.플랫폼 사용자에게 어떤 세부 정보가 중요하고, 어떤 것이 소음일 뿐인지 파악하는 것이 중요하죠.구체적인 예를 들어보겠습니다.새 서비스를 배포하는 개발자는 클러스터 노드 크기, 인스턴스 유형, 오토 스케일링 인계각 같은 것에 신경 쓰지 않습니다.오직 서비스가 잘 돌아가는지 응답 속도는 어떤지만 중요할 뿐이죠.그래서 플랫폼은 앱 티어에 맞춰 이 모든 것을 미리 설정합니다.작은 서비스라면 그에 맞는 적절한 설정을 제공합니다.트래픽이 많은 서비스라면 또 다른 구성을 제공하죠.개발자는 굳이 그런 선택을 할 필요가 없기에 직접 하지 않습니다.왜 이것이 중요할까요?개발자가 15가지 걱정을 동시에 하지 않으면 번아웃이 줄어들기 때문입니다.성숙한 플랫폼 팀들은 인지 부하를 거의 절반 가까이 줄였습니다.정신적 부담을 40에서 50% 정도 덜어내는 것이죠.엄청난 변화입니다.퇴근할 때 에너지가 남느냐, 아니면 밤 10시에 터미널을 보며 왜 파이프라인이 실패했는지 고민하느냐의 차이죠.

하지만 주의할 점이 있습니다.환상을 만들지 마세요.일부 플랫폼 팀은 함정에 빠지곤 합니다.개발자에게 내부에서 무슨 일이 일어나는지 이해할 방법조차 주지 않고 설정을 숨겨버리죠.이건 추상화가 아니라 기만이며 문제가 생기는 순간 역효과를 냅니다.개발자는 앞이 보이지 않는 벽에 부딪히게 되고,갑자기 플랫폼은 자신들을 방해하는 블랙박스처럼 느껴지게 됩니다.이런 현상을 센추상화, 니키 앱스트랙션 라고 합니다.복잡성을 숨겼지만 결국 그 복잡성이 밖으로 새어나오는 것이죠.데이터베이스가 느려지거나, 배포가 실패하거나,보안 정책이 예상치 못한 것을 차단할 때 말입니다.개발자는 플랫폼이 정보를 전혀 주지 않았기에 무슨 일이 일어나는지 머릿속으로 그려볼 수 없습니다.투명성이 중요합니다.개발자에게 필요한 정보를 필요할 때 보여주세요.그저 모든 것을 숨기고 잘 되길 바라기만 해서는 안 됩니다.이것이 여러분에게 의미하는 바는 컨텍스트 스위칭은 줄고 몰입 상태는 늘어난다는 것입니다.아침에 쿠버네티스 클러스터 업그레이드 여부를 고민하는 대신 다음주 마감인 기능 구현부터 시작하는 거죠.본연의 업무를 다시 시작할 수 있게 됩니다.플랫폼을 하나의 제품으로 대하는 것입니다.오늘 우리는 내부 도구가 실제로 작동하는 방식을 바꾸는 것에 대해 이야기합니다.대부분은 플랫폼팀을 단순한 인프라팀이라고 생각합니다.그렇지 않습니다.플랫폼팀은 제품팀이며, 플랫폼을 사용하는 개발자는 티켓을 제출하는 사람이 아니라 그들의 고객입니다.그 사실이 모든 것을 바꿉니다.제품팀은 고객과 대화하고, 무엇이 정말 고통스러운지 파악하며,실제 필요에 따라 기능을 우선순위화하고 채택률을 측정합니다.단순히 무언가를 만들고 떠나는 것이 아니라 끊임없이 반복합니다.그렇다면 실제 제품팀의 모습은 어떨까요?그들은 헬프데스크처럼 운영되지 않습니다.개발자가 티켓을 제출하면 플랫폼팀이 수동으로 처리하는 방식 말입니다.

그건 플랫폼 엔지니어링이 아니라 이름만 바꾼 중앙집중식 운영일 뿐입니다.확장성도 없고 인지 부하도 줄이지 못하며,병목현상을 한 팀에서 다른 팀으로 옮길 뿐입니다.대신 그들은 이렇게 합니다.그들은 올바른 지표를 측정합니다.최초 배포까지 걸리는 시간, 팀 신규 멤버에 온 보딩 속도, 개발자 만족도 점수 등이 그것입니다.이런 지표들이 플랫폼이 실제로 사람들에게 도움을 주는지, 아니면 복잡성만 더하고 있는지 알려줍니다.스포티파이가 좋은 예입니다.그들의 플랫폼팀은 제대로 된 제품 조직처럼 운영됩니다.그들은 로드맵과 OKR을 가지고 있으며,무엇이 효과적이고 무엇이 그렇지 않은지 개발자들과 대화합니다.그들은 플랫폼을 매일 채택되어야 하는 존재로 여기며,그것이 핵심 아이디어입니다.아무도 쓰지 않는 플랫폼은 그냥 프로젝트일 뿐이며,구석에서 먼지만 쌓일 뿐입니다.채택이야말로 궁극적인 검증입니다.개발자가 직접 도구를 만드는 대신 당신의 플랫폼을 선택한다면 성공한 것입니다.만약 개발자가 플랫폼을 피한다면 아무리 기술적으로 뛰어나도 해결할 수 없습니다.이게 여러분에게 어떤 의미일까요?플랫폼을 구축한다면 아키텍처 다이어그램이나 쿠버네티스 클러스터, 테라폼 모듈부터 시작하지 마세요.사용자 인터뷰부터 시작하고, 플랫폼을 사용할 개발자들과 대화하세요.무엇이 실제로 고통스러운지 찾아내세요.실제 문제를 해결하는 것 하나를 만들고, 그 다음 반복하세요.그것이 사람들이 정말로 사용하고 싶어하는 것을 만드는 방법입니다.왜 지금일까요? AI 위 물결 때문입니다.그렇다면 왜 지금이 이야기를 하는 걸까요?왜 5년 전에는 아니었을까요?정답은 AI입니다.기터브 코파일럿 같은 AI 코딩 도구는 개발자들이 전례 없는 속도로 코드를 배포하게 해줍니다.불과 몇 년 전 가능했던 것보다 하루에 10배, 20배 더 많은 코드를 생산하죠.멋진 일처럼 들리고, 실제로도 그렇습니다.

하지만 여기에 함정이 있습니다.그 모든 코드는 여전히 인프라가 필요합니다.여전히 보안이 필요합니다.여전히 배포되고, 테스트되고, 운영되어야 합니다.더 나은 시스템 없이 코드만 많아진다고 해서 속도가 빨라지지는 않습니다.그저 혼란만 더 빠르게 만들 뿐입니다.개발자가 이미 YAML 과테라 폼에 파묻혀 있다면, AI가 이를 해결해주지는 않습니다.지원은 더 필요하고 코드는 더 많이 생산되니, 오히려 더 빨리 압도될 뿐입니다.현재 약 55%의 기업이 이미 어떤 형태로든 플랫폼 엔지니어링을 도입했습니다.같은 어느니 수치가 2026년 말까지 80%에 이를 것으로 예측합니다.이는 결코 느린 추세가 아닙니다.지금 바로 일어나고 있는 변화입니다.기업들은 플랫폼 계층 없이는 엔지니어링 팀의 규모를 확장할 수 없다는 것을 깨닫고 있습니다. AI 속도로 코드를 배포하는 상황에서 모든 팀이 스스로 모든 것을 처리하던 기존 방식은 더 이상 통하지 않습니다.많은 사람들이 놓치는 점이 있습니다. AI는 플랫폼에 대한 필요성만 만들어내는 것이 아닙니다.플랫폼 구축을 돕기도 합니다.플랫폼 팀은 AI를 활용해 테라폼 모듈을 생성하고, 문서를 작성하며, 파이프라인을 디버깅합니다.시급함을 유발하는 바로 그 기술이 이를 해결할 도구도 제공하고 있습니다.이제 주의할 점을 한 가지 말씀드리겠습니다. AI는 이미 가지고 있는 것을 증폭시킵니다.탄탄한 아키텍처와 잘 설계된 플랫폼처럼 기본기가 탄탄하다면, AI는 생산성을 2에서 3배 높여줍니다.하지만 기반이 약하다면 AI는 더 큰 실수를 더 빠르게 저지르도록 도울 뿐입니다.잘못된 설정, 보안 허점, 고장난 인프라가 모두 아무도 눈치채지 못한 채 프로덕션에 배포됩니다. AI는 나쁜 기반을 고쳐주지 않습니다.오히려 드러나게 만듭니다.실제 사례를 들어보겠습니다.내부 개발자 플랫폼이 잘 갖춰진 기업은 비엔지니어도 안전하게 AI 도구를 배포할 수 있습니다.

플랫폼이 가이드라인을 제공하기 때문입니다.보안 정책을 강제합니다.인프라를 직접 처리합니다.따라서 제품관리자는 쿠버네티스나 클라우드 네트워킹을 이해하지 못해도 AI 기반 프로토타입을 가동할 수 있습니다.이는 매우 강력합니다. AI 시대를 준비하는 팀과 뒤처질 팀을 구분짓는 요소가 바로 이런 것입니다.이것이 여러분에게 어떤 의미일까요?플랫폼을 구축할 기회에 창이 닫히고 있습니다.기술이 사라져서가 아니라 플랫폼을 갖춘 팀과 그렇지 못한 팀 간의 격차가 빠르게 벌어지고 있기 때문입니다.망설이는 매달 이미 플랫폼을 갖춘 팀들은 훨씬 앞서나가고 있습니다.그들은 더 빠르게 배포하고 번아웃은 덜 겪으며 새로운 도구에 더 빨리 적응합니다.플랫폼이 없는 팀들은 계속해서 뒤처지고 있습니다.선택은 여러분의 몫입니다.하나의 골든패스로 시작하세요.그렇다면 실제로 어디서부터 시작해야 할까요?내부 개발자 플랫폼 전체를 처음부터 구축해야 한다고 생각하고 있다면 멈추세요.그것은 프로젝트를 시작하기도 전에 망치는 가장 빠른 길입니다.팀들이 저지르는 가장 큰 실수는 모든 것을 한꺼번에 만들려 하는 것입니다.몇 달 동안 완벽한 플랫폼을 설계하며 생각나는 모든 기능을 집어넣습니다.그러고는 출시하지만 아무런 반응도 얻지 못합니다.아무도 사용하지 않습니다.왜일까요?아무도 요구하지 않은 문제를 해결하며 시작하기 위해 작은 매뉴얼을 읽어야 하기 때문입니다.분명히 말씀드리지만 그렇게 하지 마세요.대신 작게 시작하세요.아키텍트나 관리자 혹은 본인의 추측이 아니라 개발자들과 직접 대화하세요.매일 기능을 개발하는 사람들을 찾으세요.무엇이 가장 힘든지 물어보세요.가장 오래 걸리고 가장 많은 사람을 좌절시키며 필요 이상으로 자주 건너뛰는 워크플로우 하나를 찾으세요.그런 다음 끝까지 이어지는 단 하나의 골든패스를 만드세요.어쩌면 새로운 마이크로 서비스를 생성하고 배포하는 일일 수도 있습니다.

어쩌면 개발 환경을 처음부터 설정하는 일일 수도 있죠.어쩌면 운영 환경에 아무런 문제 없이 핫픽스를 배포하는 일일 수도 있습니다.가장 고통스러운 문제를 골라 그 고통을 없애줄 경로를 구축하세요.구축하고 실제 사용자와 테스트하고 피드백을 수집하고 개선하세요.그 다음 또 다른 경로를 추가하고 그 이후에도 계속 추가해 나가세요.모든 문제를 한 번에 해결하려고 하지 마세요.한 가지 문제를 제대로 해결하고 그 추진력을 동력으로 삼으세요.잘 작동하고 있는지 어떻게 알 수 있을까요?올바른 지표를 측정하세요.아이디어에서 첫 배포까지 걸리는 시간.제거한 수동 단계의 수.자발적 채택률을 확인하세요.개발자가 직접 만드는 대신 여러분의 경로를 선택한다면 여러분이 이기고 있는 겁니다.만약 개발자들이 피한다면 위견을 듣고 방향을 바꾸세요.피해야 할 함정이 있습니다.플랫폼을 의무화하지 마세요.개발자들에게 강제로 경로를 따르게 하면 그들은 반감을 가질 것입니다.그들은 우회할 방법을 찾을 것입니다.자신만의 스크립트를 만들어서 여러분 몰래 숨길 것입니다.대신 그 경로를 쉽게 만드세요.다른 대안보다 더 빠르게 만드세요.당연한 선택지로 만들되 결코 유일한 선택지로 만들지는 마세요.첫 번째 경로가 언제나 가장 어렵습니다.그 과정에서 제품 사고 방식의 모든 것을 배우게 됩니다.사용자와 소통하고 우선순위를 정하는 법을 배우게 되며단순히 작동하는 것을 만드는 것보다 사람들이 진정으로 원하는 것을 만드는 게 훨씬 어렵다는 사실을 깨닫게 되죠.하지만 한 번 해내고 나면 두 번째 경로는 더 쉬어지고세 번째는 훨씬 더 쉬어집니다.플랫폼을 한 번에 다 만드는 것이 아닙니다.한 번에 하나의 경로씩 만들어 나가는 것입니다.그것이 바로 시스템입니다.플랫폼 엔지니어링 이란 개발자가 포트홀을 메우는 대신 운전에 집중할 수 있도록 잘 닦인 도로를 만드는 일입니다.

인프라와 씨름하는데 지쳤다면팀에서 단 하나의 골든 패스를 찾는 것부터 시작해보세요.딱 하나만요.이 내용이 필요한 사람에게 공유하고더 많은 분석 영상을 보려면 구독하세요.