WEBVTT

00:00:00.000 --> 00:00:03.940
M365 FM에서 제공하는 마이크로소프트 지식나겟, 또 다른 에피소드에 오신 것을 환영합니다.

00:00:04.080 --> 00:00:05.680
진행을 맡은 미르코 피터스입니다.

00:00:05.900 --> 00:00:10.140
오늘의 주제는 거의 모든 사람이 들어는 받지만 제대로 이해하는 사람은 드문 플랫폼 엔지니어링입니다.

00:00:10.340 --> 00:00:12.800
아마 데브옵스, 데브옵스에 대해 들어보셨을 겁니다.

00:00:13.060 --> 00:00:17.280
개발자와 운영팀이 원활하게 협업한다는 아이디어였지만, 그 과정에서 약속은 어딘가 꼬이고 말았습니다.

00:00:17.580 --> 00:00:20.360
개발자가 운영 업무까지 떠막게 되면서 시스템이 무너진 것이죠.

00:00:20.540 --> 00:00:24.980
이번 에피소드가 끝날 때 쯤이면 데브옵스에 무엇이 잘못되었는지, 내부 개발자 플랫폼이 실제로 무엇인지,

00:00:24.980 --> 00:00:31.200
골든패스가 어떻게 팀에게 명확한 길을 제시하는지, 그리고 왜 가장 똑똑한 엔지니어링 팀들이 벌써 이를 구축하고 있는지 이해하게 될 것입니다.

00:00:31.360 --> 00:00:34.280
데브옵스가 남긴 혼란, 그 시작점으로 돌아가 봅시다.

00:00:34.480 --> 00:00:38.500
데브옵스는 개발자와 운영 사이의 벽을 허물겠다는 단순하지만 훌륭한 목표를 가진 아이디어였습니다.

00:00:38.680 --> 00:00:41.200
더 이상 코드를 담장 너머로 던져두고 잘 되길 바라는 일은 없어야 했죠.

00:00:41.340 --> 00:00:45.180
시프트 레프트, 쉬프트 레프트를 통해 테스트, 보안, 운영을 프로세스 초기 단계로 옮기는 것이 없습니다.

00:00:45.180 --> 00:00:47.980
더 빠른 전달, 더 적은 인수 인계, 더 큰 책임감이 기대되었습니다.

00:00:48.160 --> 00:00:49.660
이론적으로는 완벽해 보였습니다.

00:00:49.840 --> 00:00:51.700
하지만 실제로는 무언가 잘못되었습니다.

00:00:51.940 --> 00:00:55.480
시프트 레프트는 단순히 책임을 옮긴 것이 아니라 업무를 가중시켰습니다.

00:00:55.660 --> 00:01:06.660
코드만 작성하고 티켓을 발행하던 개발자가 이제는 인프라, 보안, 모니터링, 후버네티스, CI, CD파이프 라인, 비밀관리, 그리고 들어본 적도 없는 15가지 클라우드 서비스까지 모두 책임지게 되었습니다.

00:01:06.920 --> 00:01:10.260
한 사람이 제품을 개발하면서의 모든 것을 처리해야 하는 상황입니다.

00:01:10.260 --> 00:01:11.740
실제 상황은 이렇습니다.

00:01:12.000 --> 00:01:14.860
어떤 팀이 기능을 테스트하기 위해 새로운 환경을 구축하려고 합니다.

00:01:15.060 --> 00:01:17.420
데브옵스 이전에는 티켓을 발행하고 기다리면 되었습니다.

00:01:17.420 --> 00:01:19.800
데브옵스 도입 후에는 스스로 해결해야 합니다.

00:01:19.960 --> 00:01:29.480
이론상으로는 좋아 보이지만 이제는 테라폼 모듈을 작성하고, 쿠버네티스 클러스터를 구성하고, 네트워크 규칙을 설정하고, 모니터링을 연결하고, 비밀관리를 해결하고, 보안정책이 적용되었는지 확인해야 합니다.

00:01:29.660 --> 00:01:33.700
다른 사람이 1시간 만에 처리하던 티켓이 이제는 개발자의 사흘을 잡아먹습니다.

00:01:33.960 --> 00:01:36.220
제품 코드를 작성하지 못하는 사흘인 셈입니다.

00:01:36.420 --> 00:01:40.960
개발자들은 YAML 파일과 실음하고 로드 밸런서가 왜 트래픽을 제대로 라우팅하지 않는지 디버깅하느라 시간을 보냅니다.

00:01:41.120 --> 00:01:42.440
정신적 부담이 엄청납니다.

00:01:42.440 --> 00:01:46.520
모든 팀이 각자의 파이프라인, 배포 스크립트, 모니터링 대시보드를 직접 구축하게 됩니다.

00:01:46.700 --> 00:01:49.260
다들 업무에 쫓기다 보니 결국 무언가를 대충 넘기게 됩니다.

00:01:49.480 --> 00:01:52.040
마감기한이 금요일이라는 이유로 보안점검은 건너뛰게 됩니다.

00:01:52.240 --> 00:01:56.120
테스트 환경을 종료하는 것을 잊어버려서 클라우드 비용이 2배가 되어도 아무도 알아차리지 못합니다.

00:01:56.320 --> 00:02:00.260
그리고 새벽 2시에 문제가 발생하면 그것을 만든 개발자만이 유일한 해결사로 호출됩니다.

00:02:00.460 --> 00:02:03.460
이건 지속가능하지 않으며 지금이 문제가 그 어느 때고 다 중요한 이유는 다음과 같습니다.

00:02:03.700 --> 00:02:05.580
클라우드의 복잡성은 계속해서 커지고 있습니다.

00:02:05.580 --> 00:02:09.040
매년 더 많은 서비스와 도구가 쏟아지고 더 많은 결정을 내려야 하기 때문입니다.

00:02:09.160 --> 00:02:14.880
이제 AI 코딩 도구를 사용하면 개발자가 그 어느 때보다 빠르게 하루에 10배, 20배, 심지어 30배 더 많은 코드를 배포할 수 있습니다.

00:02:15.100 --> 00:02:18.320
하지만 그 모든 코드에도 인프라, 보안, 모니터링은 여전히 필요합니다.

00:02:18.500 --> 00:02:21.540
더 나은 시스템 없이 코드만 늘어나는 것은 혼란만 가속할 뿐입니다.

00:02:21.740 --> 00:02:24.980
YAML 과테라 폼에 파묻혀 있다고 느낀다면 당신만 그런 것은 아닙니다.

00:02:25.140 --> 00:02:26.500
이는 개인의 잘못이 아닙니다.

00:02:26.700 --> 00:02:27.820
시스템적인 문제입니다.

00:02:28.040 --> 00:02:30.320
현재의 모델은 플랫폼 엔지니어링의 본질을 왜곡했습니다.

00:02:30.640 --> 00:02:31.920
그럼 해결책은 무엇일까요?

00:02:31.920 --> 00:02:33.520
바로 플랫폼 엔지니어링입니다.

00:02:33.720 --> 00:02:35.660
가장 쉽게 이해하는 방법은 다음과 같습니다.

00:02:35.980 --> 00:02:39.300
이 분야는 개발자를 위해 복잡성을 흡수하는 내부계층을 구축합니다.

00:02:39.500 --> 00:02:41.580
큰 사무실 건물에 들어간다고 상상해보세요.

00:02:41.900 --> 00:02:46.640
누가 어떤 층에 접근할 수 있는지, 어떤 보안카드가 작동하는지, 비상구는 어디인지 고민할 필요가 없습니다.

00:02:46.900 --> 00:02:50.200
안내데스크가 그 모든 것을 처리해주니 당신은 그저 들어가서 업무를 시작하면 됩니다.

00:02:50.460 --> 00:02:53.220
그것이 바로 플랫폼 엔지니어링이 개발자에게 해주는 일입니다.

00:02:53.440 --> 00:02:58.280
모든 개발자가 쿠버네티스, 페라폼, 네트워킹, 보안의 전문가가 될 필요 없이

00:02:58.280 --> 00:03:01.900
중앙 플랫폼 팀이 그 모든 복잡성을 관리하는 계층을 만듭니다.

00:03:02.080 --> 00:03:07.920
개발자는 간단한 인터페이스에서 버튼을 클릭하거나, 명령어를 실행하거나, 양식을 작성하기만 하면 플랫폼이 나머지를 모두 처리합니다.

00:03:08.120 --> 00:03:11.000
하지만 여기서 중요한 점은 이것이 데브옵스, 데브옵스와는 다르다는 것입니다.

00:03:11.160 --> 00:03:15.700
데브옵스는 모든 팀이 자신의 인프라를 직접 관리하라고 했지만, 플랫폼 엔지니어링은 그것이 번아웃의 원인이 된다고 봅니다.

00:03:15.700 --> 00:03:21.160
대신 플랫폼 팀은 공통작업을 처리할 수 있는 표준화되고 검증된 안전한 길, 즉 포장된 도로를 제공합니다.

00:03:21.340 --> 00:03:24.880
그들은 도로를 만들고 유지관리하며, 제품팀은 그 위를 달리기만 하면 됩니다.

00:03:25.100 --> 00:03:30.000
플랫폼 엔지니어링의 핵심 결과물은 내부 개발자 플랫폼, 줄여서 IDP라고 불리는 것입니다.

00:03:30.200 --> 00:03:34.100
반복적인 모든 작업을 자동화하는 셀프 서비스 시스템이라고 생각하면 됩니다.

00:03:34.380 --> 00:03:40.400
인프라 프로비저닝, CI, CD 파이프라인, 보안검사, 모니터링 등이 모두 내장되어 표준화됩니다.

00:03:40.400 --> 00:03:42.000
구체적인 예시를 들어보겠습니다.

00:03:42.380 --> 00:03:48.900
플랫폼 없이 새로운 서비스를 배포하려면 개발자는 며칠 동안 인프라를 설정하고, 파이프라인을 작성하며, 모니터링을 구성해야 합니다.

00:03:48.900 --> 00:03:58.120
IDP가 있으면 UI에서 배포 버튼을 클릭하거나 명령어 하나만 실행하면, 플랫폼이 프로비저닝, 패스트, 모니터링, 배포까지 며칠 걸릴 작업을 몇 분 만에 처리합니다.

00:03:58.300 --> 00:04:00.240
그렇다면 이것이 당신에게 어떤 의미일까요?

00:04:00.440 --> 00:04:04.320
더 이상 인프라 잡무에 매달리지 않고, 자신의 실제 제품을 위한 전문가가 될 수 있습니다.

00:04:04.520 --> 00:04:09.840
테라폼 상태 파일이 왜 손상되었는지 디버깅하는 대신, 고객에게 중요한 기능을 구축하는 본연의 업무로 돌아가는 것입니다.

00:04:10.000 --> 00:04:11.200
그것이 바로 핵심입니다.

00:04:11.420 --> 00:04:13.360
쉽게 풀어본 내부 개발자 플랫폼입니다.

00:04:13.580 --> 00:04:16.300
자, 내부 개발자 플랫폼이 실제로 무엇인지 자세히 살펴보겠습니다.

00:04:16.300 --> 00:04:18.920
모든 것을 하나의 시스템으로 통합하는 엔진입니다.

00:04:19.080 --> 00:04:23.560
CI, CD 파이프 라인, 인프라 템플릿, 보안 정책, 모니터링, 그리고 로깅까지.

00:04:23.800 --> 00:04:26.220
서로 연결해야 하는 6개의 개별 도구 대신 말이죠.

00:04:26.380 --> 00:04:27.520
비유를 하나 들어볼게요.

00:04:27.800 --> 00:04:30.880
처음부터 직접 요리하는 것과 자판기를 사용하는 것의 차이로 생각해보세요.

00:04:31.140 --> 00:04:35.340
직접 요리하려면 재료를 사고, 채소를 썰고, 양념을 맞추고, 불을 지켜봐야 하죠.

00:04:35.500 --> 00:04:38.540
결정할 것도 많고, 단계도 많고, 실수할 가능성도 많습니다.

00:04:38.740 --> 00:04:41.260
반면 자판기는 버튼 한 번만 누르면 결과물이 나옵니다.

00:04:41.440 --> 00:04:44.200
결정은 줄어들고, 결과는 빠르며, 품질은 일정하죠.

00:04:44.200 --> 00:04:46.020
IDP가 바로 그 자판기입니다.

00:04:46.160 --> 00:04:50.060
개발자는 인프라가 어떻게 프로비저닝되는지, 비밀 정보가 어디에 저장되는지 알 필요가 없습니다.

00:04:50.300 --> 00:04:51.720
그저 버튼만 누르면 되니까요.

00:04:51.860 --> 00:04:53.640
그 자판기 안에는 무엇이 들어있을까요?

00:04:53.800 --> 00:04:55.800
핵심 구성 요소들은 꽤 표준화되어 있습니다.

00:04:56.100 --> 00:05:00.560
일관된 빌드를 위한 CI, CD 템플릿, 자동환경 구성을 위한 인프라 프로비저닝,

00:05:00.980 --> 00:05:03.780
구성 파일에 자격 증명이 노출되지 않도록 하는 비밀 관리,

00:05:04.100 --> 00:05:07.440
그리고 당황하지 않고 문제를 해결할 수 있는 관측성이 포함된 로깅입니다.

00:05:07.640 --> 00:05:11.280
이 모든 것이 플랫폼 팀에 의해 사전에 구성되고, 테스트되며 유지관리됩니다.

00:05:11.280 --> 00:05:17.400
구체적인 예를 들어보죠. 개발자가 명령줄에 새 서비스 생성을 입력하거나 포털에서 버튼을 클릭합니다.

00:05:17.580 --> 00:05:20.600
백그라운드에서 IDP가 올바른 구조의 새 저장소를 만들고,

00:05:20.960 --> 00:05:23.460
자동으로 테스트를 실행하는 빌드 파이프라인을 설정하며,

00:05:23.860 --> 00:05:27.840
개발 환경에 서비스를 배포하고, 로깅이 포함된 상태 확인 앤드 포인트를 추가합니다.

00:05:28.040 --> 00:05:30.020
이 모든 과정이 단 몇 분 만에 이루어집니다.

00:05:30.180 --> 00:05:33.720
개발자는 테라폰 파일 하나 만들 필요도, 쿠버네티스 매니페스트를 설정할 필요도 없었습니다.

00:05:33.940 --> 00:05:36.240
명령어 한 줄 입력했을 뿐인데 실행 중인 서비스가 생긴 거죠.

00:05:36.240 --> 00:05:39.300
이게 왜 중요할까요? 일관성이 핵심적인 이유입니다.

00:05:39.460 --> 00:05:42.000
각 팀이 파이프라인을 직접 구축하고 배포 스크립트를 작성하면,

00:05:42.320 --> 00:05:44.580
결국 제각각인 스노우 플레이크 구성이 되어버립니다.

00:05:44.780 --> 00:05:47.880
50개의 서비스가 있다면, 50가지의 처리 방식이 존재하는 셈이죠.

00:05:48.100 --> 00:05:51.340
문제가 생기면, 그걸 만든 사람 외에는 아무도 디버깅할 수 없습니다.

00:05:51.680 --> 00:05:53.860
만약 그 사람이 퇴사했다면, 행운을 빕니다.

00:05:54.080 --> 00:05:58.100
IDP는 모든 서비스가 같은 패턴을 따르고, 모든 배포가 동일한 파이프라인을 사용하며,

00:05:58.460 --> 00:06:00.740
모든 팀이 같은 기본 설정을 갖게 함으로써 이를 해결합니다.

00:06:00.960 --> 00:06:03.980
문제가 발생해도 패턴이 익숙하고, 해결 방법도 문서화되어 있죠.

00:06:03.980 --> 00:06:06.060
자, 이것이 여러분에게 어떤 의미일까요?

00:06:06.240 --> 00:06:08.900
만약 조직 내 50개 팀이 각기 다른 50가지 방식으로 배포하고 있다면,

00:06:09.220 --> 00:06:10.080
IDP가 정답입니다.

00:06:10.240 --> 00:06:12.220
그렇다고 팀의 자율성이 사라지는 건 아닙니다.

00:06:12.400 --> 00:06:14.580
지루하고 반복적이며 오류가 잦은 부분은 표준화하고,

00:06:14.880 --> 00:06:17.220
대신 흥미롭고 창의적인 업무는 다양하게 할 수 있다는 뜻이죠.

00:06:17.360 --> 00:06:18.800
해볼 만한 가치가 있는 거래입니다.

00:06:18.980 --> 00:06:21.940
골든패스, 그것은 가두는 우리, 케이지, 가 아니라 나아갈 길, 웨이, 입니다.

00:06:22.160 --> 00:06:23.560
골든패스에 대해 이야기해봅시다.

00:06:23.740 --> 00:06:25.900
이름은 들어보셨겠지만, 아이디어는 간단합니다.

00:06:25.900 --> 00:06:30.440
골든패스란 옳은 일을 가장 쉽게 할 수 있도록 미리 만들어진 권장 워크플로우를 의미합니다.

00:06:30.560 --> 00:06:32.040
플랫폼 팀이 이렇게 말합니다.

00:06:32.280 --> 00:06:33.860
저희는 이런 방식을 권장합니다.

00:06:34.100 --> 00:06:37.620
이미 테스트를 마쳤고, 잘 작동하며, 문제가 생기면 저희가 지원하겠습니다.

00:06:37.920 --> 00:06:39.520
권장이라는 단어에 주목하세요.

00:06:39.900 --> 00:06:41.340
골든패스는 의무가 아닙니다.

00:06:41.540 --> 00:06:45.140
개발자는 필요시의 경로를 벗어날 수 있지만, 이 경로는 빠르고 안전한 기본값이 됩니다.

00:06:45.400 --> 00:06:47.740
이미 실행 중이고, 지원되며, 문서화까지 되어 있죠.

00:06:47.940 --> 00:06:49.960
모든 것을 처음부터 직접 알아낼 필요가 없습니다.

00:06:49.960 --> 00:06:52.320
가드레일보다는 철길이라고 생각해보세요.

00:06:52.520 --> 00:06:54.620
가드레일은 충돌할 때 여러분을 막아줍니다.

00:06:54.800 --> 00:06:58.080
반응형이며 절벽 아래로 떨어지는 것을 막아주지만, 주행을 돕지는 않습니다.

00:06:58.280 --> 00:07:01.880
철길은 경로를 따라 부드럽게 안내하므로, 어디로 꺾을지 고민할 필요가 없습니다.

00:07:02.180 --> 00:07:03.780
골든패스가 바로 그 철길입니다.

00:07:04.020 --> 00:07:06.720
단순히 실패를 막는 게 아니라, 여러분을 앞으로 나아가게 합니다.

00:07:06.940 --> 00:07:08.460
많은 팀이 여기서 실수를 합니다.

00:07:08.720 --> 00:07:11.640
개발자가 아닌 플랫폼 팀을 위한 골든패스를 만듭니다.

00:07:11.840 --> 00:07:17.120
아키텍처의 순수성, 보안 준수, 혹은 플랫폼 팀 외에는 아무도 모르는 내부 규칙에 최적화하죠.

00:07:17.120 --> 00:07:20.720
결과는 화이트보드 위에서는 훌륭해 보이지만, 실제 사용감은 형편없습니다.

00:07:20.840 --> 00:07:25.780
개발자들은 조용히 우회로를 찾고, 채택률은 떨어지며, 플랫폼 팀은 왜 아무도의 노력을 알아주지 않는지 위하에 합니다.

00:07:25.940 --> 00:07:28.080
해결책은 간단하지만 실행하기는 어렵습니다.

00:07:28.240 --> 00:07:29.340
8출구가 필요합니다.

00:07:29.560 --> 00:07:32.640
경로가 개발자의 사용 사례에 맞지 않으면 빠져나갈 방법이 필요합니다.

00:07:32.820 --> 00:07:37.020
기본값을 재정해하거나, 자체 파이프라인을 도입하거나, 플랫폼 밖으로 완전히 나갈 수 있는 방법 말입니다.

00:07:37.220 --> 00:07:38.720
그리고 여기서 중요한 부분이 있습니다.

00:07:39.000 --> 00:07:41.360
개발자가 경로를 벗어나는 것은 실패가 아니라 피드백입니다.

00:07:41.360 --> 00:07:44.540
개발자가 골든패스를 벗어날 때마다 무언가 실질적인 정보를 얻게 됩니다.

00:07:44.700 --> 00:07:48.880
경로에 필요한 기능이 빠졌거나, 아니면 그 사용 사례가 애초에 경로에 적합하지 않은 경우죠.

00:07:49.000 --> 00:07:50.320
두 신호 모두 가치가 있습니다.

00:07:50.660 --> 00:07:52.820
실제 잘 구현된 골든패스는 이런 모습입니다.

00:07:53.000 --> 00:07:55.160
한 팀이 새로운 백엔드 서비스를 배포하려 합니다.

00:07:55.360 --> 00:07:56.600
그들은 경로를 이용합니다.

00:07:56.780 --> 00:08:05.200
적절한 구조의 템플릿 저장소, 이미 테스트된 표준 CI, CD 파이프 라인, 내장된 로깅 및 모니터링, 문제가 생겼을 때 클릭 한 번으로 되돌리는 기능을 제공받죠.

00:08:05.200 --> 00:08:10.780
며칠 걸릴 일이 몇 분 만에 끝나며, 플랫폼 팀이 경로를 유지관리함으로 문제가 생기면 그들이 해결해줍니다.

00:08:10.960 --> 00:08:13.660
개발자가 파이프라인 디버깅 전문가가 될 필요가 없습니다.

00:08:13.940 --> 00:08:16.080
이는 여러분에게 놀랄 일이 줄어든다는 의미입니다.

00:08:16.260 --> 00:08:18.380
경로가 검증되었으니 더 빠르게 출시할 수 있습니다.

00:08:18.580 --> 00:08:20.980
보안과 모니터링이 내장되어 있어 더 안전하게 출시합니다.

00:08:21.200 --> 00:08:23.640
클릭 한 번으로 롤백이 가능하니 확신을 가지고 출시합니다.

00:08:23.840 --> 00:08:26.860
경로는 여러분을 돕기 위해 존재하는 것이지, 가로막기 위한 것이 아닙니다.

00:08:27.060 --> 00:08:27.660
사용하세요.

00:08:27.920 --> 00:08:29.120
인지 부하를 줄여줍니다.

00:08:29.380 --> 00:08:31.020
여기서 진짜 성과가 나타납니다.

00:08:31.020 --> 00:08:34.660
플랫폼이 힘든 작업을 대신해주면 개발자는 비로소 코드에 집중할 수 있습니다.

00:08:34.880 --> 00:08:37.260
어떤 쿠버네티스 버전이 실행 중인지 알 필요가 없습니다.

00:08:37.540 --> 00:08:41.020
클라우드 제공업체가 API를 바꿀 때 마다 테라폼 모듈을 업데이트할 필요도 없죠.

00:08:41.160 --> 00:08:42.540
그저 기능을 개발하기만 하면 됩니다.

00:08:42.800 --> 00:08:44.720
플랫폼 엔지니어들이 그 복잡성을 흡수하니까요.

00:08:44.840 --> 00:08:47.100
그들은 개발자가 무엇을 봐야 하고 무엇을 숨겨야 할지 결정합니다.

00:08:47.300 --> 00:08:49.620
이것은 단순한 기술적 선택이 아닌 실제 설계적 선택입니다.

00:08:49.800 --> 00:08:54.120
플랫폼 사용자에게 어떤 세부 정보가 중요하고, 어떤 것이 소음일 뿐인지 파악하는 것이 중요하죠.

00:08:54.300 --> 00:08:55.500
구체적인 예를 들어보겠습니다.

00:08:55.500 --> 00:09:01.700
새 서비스를 배포하는 개발자는 클러스터 노드 크기, 인스턴스 유형, 오토 스케일링 인계각 같은 것에 신경 쓰지 않습니다.

00:09:01.860 --> 00:09:05.240
오직 서비스가 잘 돌아가는지 응답 속도는 어떤지만 중요할 뿐이죠.

00:09:05.400 --> 00:09:07.980
그래서 플랫폼은 앱 티어에 맞춰 이 모든 것을 미리 설정합니다.

00:09:08.140 --> 00:09:10.340
작은 서비스라면 그에 맞는 적절한 설정을 제공합니다.

00:09:10.500 --> 00:09:12.680
트래픽이 많은 서비스라면 또 다른 구성을 제공하죠.

00:09:12.840 --> 00:09:15.460
개발자는 굳이 그런 선택을 할 필요가 없기에 직접 하지 않습니다.

00:09:15.640 --> 00:09:16.760
왜 이것이 중요할까요?

00:09:16.940 --> 00:09:20.760
개발자가 15가지 걱정을 동시에 하지 않으면 번아웃이 줄어들기 때문입니다.

00:09:20.980 --> 00:09:23.840
성숙한 플랫폼 팀들은 인지 부하를 거의 절반 가까이 줄였습니다.

00:09:23.840 --> 00:09:26.900
정신적 부담을 40에서 50% 정도 덜어내는 것이죠.

00:09:27.040 --> 00:09:28.020
엄청난 변화입니다.

00:09:28.220 --> 00:09:33.100
퇴근할 때 에너지가 남느냐, 아니면 밤 10시에 터미널을 보며 왜 파이프라인이 실패했는지 고민하느냐의 차이죠.

00:09:33.280 --> 00:09:34.620
하지만 주의할 점이 있습니다.

00:09:34.840 --> 00:09:36.080
환상을 만들지 마세요.

00:09:36.280 --> 00:09:38.200
일부 플랫폼 팀은 함정에 빠지곤 합니다.

00:09:38.460 --> 00:09:42.740
개발자에게 내부에서 무슨 일이 일어나는지 이해할 방법조차 주지 않고 설정을 숨겨버리죠.

00:09:42.920 --> 00:09:46.520
이건 추상화가 아니라 기만이며 문제가 생기는 순간 역효과를 냅니다.

00:09:46.740 --> 00:09:48.340
개발자는 앞이 보이지 않는 벽에 부딪히게 되고,

00:09:48.720 --> 00:09:51.060
갑자기 플랫폼은 자신들을 방해하는 블랙박스처럼 느껴지게 됩니다.

00:09:51.060 --> 00:09:53.580
이런 현상을 센추상화, 니키 앱스트랙션 라고 합니다.

00:09:53.700 --> 00:09:56.380
복잡성을 숨겼지만 결국 그 복잡성이 밖으로 새어나오는 것이죠.

00:09:56.540 --> 00:09:58.560
데이터베이스가 느려지거나, 배포가 실패하거나,

00:09:58.840 --> 00:10:00.700
보안 정책이 예상치 못한 것을 차단할 때 말입니다.

00:10:00.900 --> 00:10:04.740
개발자는 플랫폼이 정보를 전혀 주지 않았기에 무슨 일이 일어나는지 머릿속으로 그려볼 수 없습니다.

00:10:04.980 --> 00:10:06.120
투명성이 중요합니다.

00:10:06.340 --> 00:10:08.720
개발자에게 필요한 정보를 필요할 때 보여주세요.

00:10:08.960 --> 00:10:11.160
그저 모든 것을 숨기고 잘 되길 바라기만 해서는 안 됩니다.

00:10:11.440 --> 00:10:14.820
이것이 여러분에게 의미하는 바는 컨텍스트 스위칭은 줄고 몰입 상태는 늘어난다는 것입니다.

00:10:14.820 --> 00:10:20.120
아침에 쿠버네티스 클러스터 업그레이드 여부를 고민하는 대신 다음주 마감인 기능 구현부터 시작하는 거죠.

00:10:20.300 --> 00:10:22.420
본연의 업무를 다시 시작할 수 있게 됩니다.

00:10:22.660 --> 00:10:24.720
플랫폼을 하나의 제품으로 대하는 것입니다.

00:10:24.940 --> 00:10:28.520
오늘 우리는 내부 도구가 실제로 작동하는 방식을 바꾸는 것에 대해 이야기합니다.

00:10:28.720 --> 00:10:31.400
대부분은 플랫폼팀을 단순한 인프라팀이라고 생각합니다.

00:10:31.620 --> 00:10:32.380
그렇지 않습니다.

00:10:32.640 --> 00:10:37.160
플랫폼팀은 제품팀이며, 플랫폼을 사용하는 개발자는 티켓을 제출하는 사람이 아니라 그들의 고객입니다.

00:10:37.320 --> 00:10:38.760
그 사실이 모든 것을 바꿉니다.

00:10:38.960 --> 00:10:41.700
제품팀은 고객과 대화하고, 무엇이 정말 고통스러운지 파악하며,

00:10:41.700 --> 00:10:44.540
실제 필요에 따라 기능을 우선순위화하고 채택률을 측정합니다.

00:10:44.640 --> 00:10:47.720
단순히 무언가를 만들고 떠나는 것이 아니라 끊임없이 반복합니다.

00:10:47.920 --> 00:10:50.100
그렇다면 실제 제품팀의 모습은 어떨까요?

00:10:50.300 --> 00:10:52.240
그들은 헬프데스크처럼 운영되지 않습니다.

00:10:52.460 --> 00:10:55.600
개발자가 티켓을 제출하면 플랫폼팀이 수동으로 처리하는 방식 말입니다.

00:10:55.820 --> 00:10:59.180
그건 플랫폼 엔지니어링이 아니라 이름만 바꾼 중앙집중식 운영일 뿐입니다.

00:10:59.360 --> 00:11:01.100
확장성도 없고 인지 부하도 줄이지 못하며,

00:11:01.380 --> 00:11:03.260
병목현상을 한 팀에서 다른 팀으로 옮길 뿐입니다.

00:11:03.420 --> 00:11:04.620
대신 그들은 이렇게 합니다.

00:11:04.880 --> 00:11:06.420
그들은 올바른 지표를 측정합니다.

00:11:06.420 --> 00:11:10.980
최초 배포까지 걸리는 시간, 팀 신규 멤버에 온 보딩 속도, 개발자 만족도 점수 등이 그것입니다.

00:11:11.120 --> 00:11:15.640
이런 지표들이 플랫폼이 실제로 사람들에게 도움을 주는지, 아니면 복잡성만 더하고 있는지 알려줍니다.

00:11:15.880 --> 00:11:17.200
스포티파이가 좋은 예입니다.

00:11:17.440 --> 00:11:19.920
그들의 플랫폼팀은 제대로 된 제품 조직처럼 운영됩니다.

00:11:20.140 --> 00:11:21.820
그들은 로드맵과 OKR을 가지고 있으며,

00:11:22.160 --> 00:11:24.700
무엇이 효과적이고 무엇이 그렇지 않은지 개발자들과 대화합니다.

00:11:24.940 --> 00:11:27.680
그들은 플랫폼을 매일 채택되어야 하는 존재로 여기며,

00:11:28.100 --> 00:11:29.380
그것이 핵심 아이디어입니다.

00:11:29.620 --> 00:11:31.980
아무도 쓰지 않는 플랫폼은 그냥 프로젝트일 뿐이며,

00:11:31.980 --> 00:11:33.760
구석에서 먼지만 쌓일 뿐입니다.

00:11:33.920 --> 00:11:35.960
채택이야말로 궁극적인 검증입니다.

00:11:36.160 --> 00:11:39.800
개발자가 직접 도구를 만드는 대신 당신의 플랫폼을 선택한다면 성공한 것입니다.

00:11:40.000 --> 00:11:43.160
만약 개발자가 플랫폼을 피한다면 아무리 기술적으로 뛰어나도 해결할 수 없습니다.

00:11:43.420 --> 00:11:44.920
이게 여러분에게 어떤 의미일까요?

00:11:45.100 --> 00:11:50.000
플랫폼을 구축한다면 아키텍처 다이어그램이나 쿠버네티스 클러스터, 테라폼 모듈부터 시작하지 마세요.

00:11:50.180 --> 00:11:53.580
사용자 인터뷰부터 시작하고, 플랫폼을 사용할 개발자들과 대화하세요.

00:11:53.820 --> 00:11:55.680
무엇이 실제로 고통스러운지 찾아내세요.

00:11:55.880 --> 00:11:58.400
실제 문제를 해결하는 것 하나를 만들고, 그 다음 반복하세요.

00:11:58.400 --> 00:12:01.200
그것이 사람들이 정말로 사용하고 싶어하는 것을 만드는 방법입니다.

00:12:01.340 --> 00:12:02.080
왜 지금일까요?

00:12:02.280 --> 00:12:03.580
AI 위 물결 때문입니다.

00:12:03.760 --> 00:12:05.300
그렇다면 왜 지금이 이야기를 하는 걸까요?

00:12:05.460 --> 00:12:06.680
왜 5년 전에는 아니었을까요?

00:12:06.880 --> 00:12:07.980
정답은 AI입니다.

00:12:08.200 --> 00:12:12.720
기터브 코파일럿 같은 AI 코딩 도구는 개발자들이 전례 없는 속도로 코드를 배포하게 해줍니다.

00:12:12.920 --> 00:12:16.340
불과 몇 년 전 가능했던 것보다 하루에 10배, 20배 더 많은 코드를 생산하죠.

00:12:16.520 --> 00:12:18.320
멋진 일처럼 들리고, 실제로도 그렇습니다.

00:12:18.520 --> 00:12:19.680
하지만 여기에 함정이 있습니다.

00:12:19.940 --> 00:12:21.640
그 모든 코드는 여전히 인프라가 필요합니다.

00:12:21.840 --> 00:12:22.860
여전히 보안이 필요합니다.

00:12:23.120 --> 00:12:25.300
여전히 배포되고, 테스트되고, 운영되어야 합니다.

00:12:25.300 --> 00:12:28.220
더 나은 시스템 없이 코드만 많아진다고 해서 속도가 빨라지지는 않습니다.

00:12:28.380 --> 00:12:30.020
그저 혼란만 더 빠르게 만들 뿐입니다.

00:12:30.180 --> 00:12:34.140
개발자가 이미 YAML 과테라 폼에 파묻혀 있다면, AI가 이를 해결해주지는 않습니다.

00:12:34.340 --> 00:12:38.040
지원은 더 필요하고 코드는 더 많이 생산되니, 오히려 더 빨리 압도될 뿐입니다.

00:12:38.200 --> 00:12:42.680
현재 약 55%의 기업이 이미 어떤 형태로든 플랫폼 엔지니어링을 도입했습니다.

00:12:43.000 --> 00:12:46.620
같은 어느니 수치가 2026년 말까지 80%에 이를 것으로 예측합니다.

00:12:46.840 --> 00:12:48.380
이는 결코 느린 추세가 아닙니다.

00:12:48.600 --> 00:12:50.080
지금 바로 일어나고 있는 변화입니다.

00:12:50.080 --> 00:12:53.860
기업들은 플랫폼 계층 없이는 엔지니어링 팀의 규모를 확장할 수 없다는 것을 깨닫고 있습니다.

00:12:54.100 --> 00:12:58.260
AI 속도로 코드를 배포하는 상황에서 모든 팀이 스스로 모든 것을 처리하던 기존 방식은 더 이상 통하지 않습니다.

00:12:58.460 --> 00:12:59.880
많은 사람들이 놓치는 점이 있습니다.

00:13:00.160 --> 00:13:02.520
AI는 플랫폼에 대한 필요성만 만들어내는 것이 아닙니다.

00:13:02.680 --> 00:13:04.040
플랫폼 구축을 돕기도 합니다.

00:13:04.260 --> 00:13:09.060
플랫폼 팀은 AI를 활용해 테라폼 모듈을 생성하고, 문서를 작성하며, 파이프라인을 디버깅합니다.

00:13:09.280 --> 00:13:12.500
시급함을 유발하는 바로 그 기술이 이를 해결할 도구도 제공하고 있습니다.

00:13:12.800 --> 00:13:14.660
이제 주의할 점을 한 가지 말씀드리겠습니다.

00:13:14.660 --> 00:13:17.300
AI는 이미 가지고 있는 것을 증폭시킵니다.

00:13:17.420 --> 00:13:23.080
탄탄한 아키텍처와 잘 설계된 플랫폼처럼 기본기가 탄탄하다면, AI는 생산성을 2에서 3배 높여줍니다.

00:13:23.280 --> 00:13:27.000
하지만 기반이 약하다면 AI는 더 큰 실수를 더 빠르게 저지르도록 도울 뿐입니다.

00:13:27.180 --> 00:13:31.140
잘못된 설정, 보안 허점, 고장난 인프라가 모두 아무도 눈치채지 못한 채 프로덕션에 배포됩니다.

00:13:31.320 --> 00:13:33.160
AI는 나쁜 기반을 고쳐주지 않습니다.

00:13:33.360 --> 00:13:34.580
오히려 드러나게 만듭니다.

00:13:34.780 --> 00:13:35.860
실제 사례를 들어보겠습니다.

00:13:36.280 --> 00:13:40.220
내부 개발자 플랫폼이 잘 갖춰진 기업은 비엔지니어도 안전하게 AI 도구를 배포할 수 있습니다.

00:13:40.220 --> 00:13:42.360
플랫폼이 가이드라인을 제공하기 때문입니다.

00:13:42.520 --> 00:13:43.800
보안 정책을 강제합니다.

00:13:44.040 --> 00:13:45.340
인프라를 직접 처리합니다.

00:13:45.540 --> 00:13:50.920
따라서 제품관리자는 쿠버네티스나 클라우드 네트워킹을 이해하지 못해도 AI 기반 프로토타입을 가동할 수 있습니다.

00:13:51.140 --> 00:13:52.260
이는 매우 강력합니다.

00:13:52.500 --> 00:13:56.960
AI 시대를 준비하는 팀과 뒤처질 팀을 구분짓는 요소가 바로 이런 것입니다.

00:13:57.220 --> 00:13:59.000
이것이 여러분에게 어떤 의미일까요?

00:13:59.240 --> 00:14:01.380
플랫폼을 구축할 기회에 창이 닫히고 있습니다.

00:14:01.680 --> 00:14:07.300
기술이 사라져서가 아니라 플랫폼을 갖춘 팀과 그렇지 못한 팀 간의 격차가 빠르게 벌어지고 있기 때문입니다.

00:14:07.300 --> 00:14:11.080
망설이는 매달 이미 플랫폼을 갖춘 팀들은 훨씬 앞서나가고 있습니다.

00:14:11.340 --> 00:14:15.200
그들은 더 빠르게 배포하고 번아웃은 덜 겪으며 새로운 도구에 더 빨리 적응합니다.

00:14:15.360 --> 00:14:17.560
플랫폼이 없는 팀들은 계속해서 뒤처지고 있습니다.

00:14:17.860 --> 00:14:19.060
선택은 여러분의 몫입니다.

00:14:19.300 --> 00:14:20.780
하나의 골든패스로 시작하세요.

00:14:21.020 --> 00:14:22.900
그렇다면 실제로 어디서부터 시작해야 할까요?

00:14:23.060 --> 00:14:26.820
내부 개발자 플랫폼 전체를 처음부터 구축해야 한다고 생각하고 있다면 멈추세요.

00:14:27.020 --> 00:14:29.720
그것은 프로젝트를 시작하기도 전에 망치는 가장 빠른 길입니다.

00:14:29.900 --> 00:14:33.000
팀들이 저지르는 가장 큰 실수는 모든 것을 한꺼번에 만들려 하는 것입니다.

00:14:33.000 --> 00:14:36.500
몇 달 동안 완벽한 플랫폼을 설계하며 생각나는 모든 기능을 집어넣습니다.

00:14:36.720 --> 00:14:38.880
그러고는 출시하지만 아무런 반응도 얻지 못합니다.

00:14:39.080 --> 00:14:40.240
아무도 사용하지 않습니다.

00:14:40.460 --> 00:14:40.940
왜일까요?

00:14:41.180 --> 00:14:44.860
아무도 요구하지 않은 문제를 해결하며 시작하기 위해 작은 매뉴얼을 읽어야 하기 때문입니다.

00:14:45.020 --> 00:14:46.960
분명히 말씀드리지만 그렇게 하지 마세요.

00:14:47.120 --> 00:14:48.180
대신 작게 시작하세요.

00:14:48.420 --> 00:14:51.940
아키텍트나 관리자 혹은 본인의 추측이 아니라 개발자들과 직접 대화하세요.

00:14:52.140 --> 00:14:54.040
매일 기능을 개발하는 사람들을 찾으세요.

00:14:54.260 --> 00:14:55.700
무엇이 가장 힘든지 물어보세요.

00:14:56.000 --> 00:15:00.420
가장 오래 걸리고 가장 많은 사람을 좌절시키며 필요 이상으로 자주 건너뛰는 워크플로우 하나를 찾으세요.

00:15:00.420 --> 00:15:03.340
그런 다음 끝까지 이어지는 단 하나의 골든패스를 만드세요.

00:15:03.480 --> 00:15:06.220
어쩌면 새로운 마이크로 서비스를 생성하고 배포하는 일일 수도 있습니다.

00:15:06.420 --> 00:15:08.900
어쩌면 개발 환경을 처음부터 설정하는 일일 수도 있죠.

00:15:09.120 --> 00:15:12.300
어쩌면 운영 환경에 아무런 문제 없이 핫픽스를 배포하는 일일 수도 있습니다.

00:15:12.560 --> 00:15:15.800
가장 고통스러운 문제를 골라 그 고통을 없애줄 경로를 구축하세요.

00:15:16.020 --> 00:15:19.240
구축하고 실제 사용자와 테스트하고 피드백을 수집하고 개선하세요.

00:15:19.420 --> 00:15:21.880
그 다음 또 다른 경로를 추가하고 그 이후에도 계속 추가해 나가세요.

00:15:22.040 --> 00:15:23.740
모든 문제를 한 번에 해결하려고 하지 마세요.

00:15:23.920 --> 00:15:26.440
한 가지 문제를 제대로 해결하고 그 추진력을 동력으로 삼으세요.

00:15:26.600 --> 00:15:28.380
잘 작동하고 있는지 어떻게 알 수 있을까요?

00:15:28.380 --> 00:15:29.860
올바른 지표를 측정하세요.

00:15:30.000 --> 00:15:31.720
아이디어에서 첫 배포까지 걸리는 시간.

00:15:32.040 --> 00:15:32.980
제거한 수동 단계의 수.

00:15:33.240 --> 00:15:34.380
자발적 채택률을 확인하세요.

00:15:34.560 --> 00:15:37.880
개발자가 직접 만드는 대신 여러분의 경로를 선택한다면 여러분이 이기고 있는 겁니다.

00:15:38.120 --> 00:15:40.700
만약 개발자들이 피한다면 위견을 듣고 방향을 바꾸세요.

00:15:40.860 --> 00:15:42.060
피해야 할 함정이 있습니다.

00:15:42.340 --> 00:15:43.740
플랫폼을 의무화하지 마세요.

00:15:43.920 --> 00:15:46.300
개발자들에게 강제로 경로를 따르게 하면 그들은 반감을 가질 것입니다.

00:15:46.480 --> 00:15:47.800
그들은 우회할 방법을 찾을 것입니다.

00:15:48.040 --> 00:15:49.940
자신만의 스크립트를 만들어서 여러분 몰래 숨길 것입니다.

00:15:50.120 --> 00:15:51.680
대신 그 경로를 쉽게 만드세요.

00:15:51.860 --> 00:15:53.460
다른 대안보다 더 빠르게 만드세요.

00:15:53.460 --> 00:15:56.200
당연한 선택지로 만들되 결코 유일한 선택지로 만들지는 마세요.

00:15:56.320 --> 00:15:58.060
첫 번째 경로가 언제나 가장 어렵습니다.

00:15:58.260 --> 00:16:00.460
그 과정에서 제품 사고 방식의 모든 것을 배우게 됩니다.

00:16:00.680 --> 00:16:02.560
사용자와 소통하고 우선순위를 정하는 법을 배우게 되며

00:16:02.560 --> 00:16:06.580
단순히 작동하는 것을 만드는 것보다 사람들이 진정으로 원하는 것을 만드는 게 훨씬 어렵다는 사실을 깨닫게 되죠.

00:16:06.720 --> 00:16:08.800
하지만 한 번 해내고 나면 두 번째 경로는 더 쉬어지고

00:16:08.800 --> 00:16:10.180
세 번째는 훨씬 더 쉬어집니다.

00:16:10.320 --> 00:16:12.160
플랫폼을 한 번에 다 만드는 것이 아닙니다.

00:16:12.340 --> 00:16:14.260
한 번에 하나의 경로씩 만들어 나가는 것입니다.

00:16:14.480 --> 00:16:15.640
그것이 바로 시스템입니다.

00:16:15.640 --> 00:16:20.580
플랫폼 엔지니어링 이란 개발자가 포트홀을 메우는 대신 운전에 집중할 수 있도록 잘 닦인 도로를 만드는 일입니다.

00:16:20.720 --> 00:16:21.980
인프라와 씨름하는데 지쳤다면

00:16:21.980 --> 00:16:24.660
팀에서 단 하나의 골든 패스를 찾는 것부터 시작해보세요.

00:16:24.860 --> 00:16:25.620
딱 하나만요.

00:16:25.800 --> 00:16:27.420
이 내용이 필요한 사람에게 공유하고

00:16:27.420 --> 00:16:29.700
더 많은 분석 영상을 보려면 구독하세요.