AI가 DevOps 및 SRE 문화를 변화시키는 방법 | Better Stack 팟캐스트 Ep. 12
BBetter Stack
Computing/SoftwareAuto EnthusiastManagementTelecommutingMental HealthInternet Technology
Transcript
00:00:00이렇게 말씀드려 볼게요. 클로드 코드 프로젝트를 열고 거기에 다리를 설계해 달라고 요청해 보세요.
00:00:05아니면 초고층 빌딩이요.
00:00:08그런 다음 그 설계를 가지고 직접 나가서 그것을 실제로 지어보라고 하는 겁니다.
00:00:12그리고 나서 그 안에 직접 들어가 앉아 보라고 하세요. 그렇게 하는 게 편안하실 것 같나요?
00:00:16AI가 설계한 그 다리를 직접 운전해서 건널 수 있으시겠어요?
00:00:19고개를 젓는 걸 멈추실 때까지요. 우리에게는 여전히 엔지니어들이 필요합니다.
00:00:25소프트웨어 개발, AI, 그리고 온갖 신기술에 대해 이야기를 나누는 베터 스택 팟캐스트에 오신 것을 환영합니다.
00:00:32저는 진행자 중 한 명인 안드리스이고, 오늘 함께해 주실 분은 위시스...
00:00:38그리고 아민 아스타니입니다. 안녕하세요, 아민. 잘 지내셨죠? 이렇게 모시게 되어 기쁩니다.
00:00:44네, 초대해 주셔서 감사합니다. 정말 큰 영광입니다. 제가 알고 있는 바로는
00:00:51뭐랄까, 당신은
00:00:53SRE 마법사 같은 분이신 것 같아요. 그 분야에 매우 깊이 관여하고 계시고 해당 주제로 직접 팟캐스트도 운영하시니까요.
00:01:01그래서 이 분야를 어떻게 시작하게 되셨는지, 그리고 지금까지 소프트웨어 개발 커리어가 어땠는지 궁금합니다.
00:01:08어떻게 걸어오셨는지 말이죠.
00:01:11네, 좋은 질문입니다, 안드리스, 위시스. 초대해 주셔서 감사해요. 네, 제가 어떻게 시작하게 되었냐면요.
00:01:17고등학교 시절에 여자친구 어머니께서 레드햇 리눅스를 소개해 주셨어요.
00:01:23그분은 커뮤니티 칼리지에서 컴퓨터 과학 수업을 듣고 계셨는데,
00:01:29자신의 데스크톱 화면을 보여주셨죠. 윈도우도 아니고 맥도 아니었어요. 저는 이게 뭔지 정말 혼란스러웠는데, 알고 보니 레드햇 리눅스 위에서 실행되는 KDE 데스크톱이었어요.
00:01:37저는 완전히 매료되었고, 고등학교 2학년 때부터 그 세계에 푹 빠지게 되었습니다.
00:01:44그리고 대학에서 컴퓨터 과학 학위를 취득하고...
00:01:47인프라와 운영체제에 큰 관심을 갖게 되었고, 예전에는 우리가 제어할 수 없었던 일들을 컴퓨터가 수행하도록 가르치는 데 흥미를 느꼈습니다.
00:01:55그것이 바로 시작이었죠.
00:02:00그럼 리눅스를 사용해 오셨으니 처음부터 오픈소스 소프트웨어의 열렬한 지지자이셨겠네요.
00:02:06아, 100%죠.
00:02:08리눅스는 제 주력 운영체제였습니다.
00:02:10벌써 20년이 넘게요. 그러니까
00:02:122005년부터요.
00:02:15 그렇군요. 그렇다면 SRE에 본격적으로 빠져들게 된 시점은 언제인가요?
00:02:20네, 대략 10년 전쯤입니다. 그전에는 아쿠아(Acquia)라는 급성장 중인 SaaS 기업에서 전형적인 인프라 운영 담당자로 일했어요.
00:02:29드루팔을 아신다면 아실 겁니다. 드루팔 오픈소스 프로젝트의 창시자가 만든 회사인데,
00:02:34드루팔 웹사이트들을 위한 전문 서비스, 호스팅, 지원을 제공하는 곳이었죠.
00:02:38그래서 저는 그곳의 운영 팀에 있었는데, 회사가 로켓처럼 폭발적으로 성장함에 따라
00:02:45이름만 대면 알 만한 대형 고객들이 많아졌고, 그 규모에 비례해 수많은 수고스러운 수작업 업무가 생겨났습니다. 바로 이거죠.
00:02:51이제야 SRE에 대한 이야기가 나오네요. 수고스러운 반복 업무가 정말 많았고 장애도 빈번했습니다.
00:02:55우리는 대규모 운영의 현실과, 애초에 시작했던 아키텍처 및 프로세스 간의 괴리에 직면하기 시작했어요.
00:03:01그래서 『피닉스 프로젝트(The Phoenix Project)』를 읽기 시작했고, 그리고...
00:03:09SRE에 관한 최초의 책이었던 『클라우드 시스템즈 어드미니스트레이션(The Practice of Cloud System Administration)』도 접하게 되었습니다.
00:03:12구글의 SRE 책은 아니었고, SRE 내용은 몇 페이지에 불과했으며 12가지 실천 지침이 담겨 있었죠.
00:03:17다시 한번 큰 흥미를 느꼈고 그때부터 이를 실천하기 시작했습니다.
00:03:21그런데 사실 『피닉스 프로젝트』가 뭔지 잘 모르겠네요. 오, 이런!
00:03:26네, 맞아요. 『피닉스 프로젝트』는 원조 DevOps(데브옵스) 책과도 같은 책입니다.
00:03:31정말 훌륭한 책이죠.
00:03:34스토리 형식으로 되어 있는데, 내용은
00:03:39IT 운영 부사장이 심각한 조직적 문제들을 해결해 나가는 과정을 다루고 있습니다.
00:03:45그는 나중에 알고 보니 회사 이사회 멤버였던 정체불명의 멘토의 조언을 통해
00:03:53배우게 됩니다.
00:03:55뭐랄까,
00:03:56고전적인 공장 제조 개념들이 어떻게 소프트웨어 엔지니어링과 IT 운영에 직접적으로 적용되는지를요.
00:04:05거기서 소개된 많은 개념들을 저는 지금도 사용하고 있고 고객들에게도 이야기하곤 합니다. 여전히 극도로 유효하니까요.
00:04:11네, 그게 원조 책이었고 그 외에도
00:04:13그 이후로 정말 다양한 책들을 읽었습니다. 특히 경영 관리 분야의 책들이요.
00:04:18SRE이자 소프트웨어 엔지니어로서 역량을 키우기 위해 읽는 기술적인 책들 외에도, 관리 측면의 내용도 중요합니다.
00:04:24왜냐하면 데브옵스와 SRE는 사회기술적(sociotechnical) 실천법이기 때문이죠.
00:04:29기술이 할 수 있는 일과 인간이 그것을 활용해 비즈니스 성과를 창출하는 방식 사이의 간극을 잇는 역할을 하니까요.
00:04:36그 과정에서 상당한 인적 오류와 그에 대한 대처가 개입되겠군요, 맞죠?
00:04:42네, 물론입니다. 정말 그렇고말고요. 인적 오류에 관한 책도 있으니 아마 그것도 읽어보셔야 할 겁니다.
00:04:50어떤 분이 계신데, 안타깝게도 지금 이름이 잘 기억나지 않지만 그분은
00:04:57호주 시드니의 어떤 교수님이신데, 항공기 사고와 인적 오류가 어떻게 연관되는지 등에 대해서만 연구하시는 분입니다.
00:05:05포스트모템(회고) 문화에서 인적 오류는 정말 중요해요. 인적 오류가 논의의 끝이 되어서는 안 됩니다.
00:05:10만약 프로덕션 장애가 발생한 원인이 '인적 오류'라고 단순히 결론 내린다면,
00:05:16아니요, 그건 논의의 시작점이지 끝이 아닙니다. 어떤 요인들이 기여했는지를 따져봐야죠.
00:05:21예를 들어 그 사람이 특정 위치에서 오타를 쳐서 프로덕션 데이터베이스를 날려버리게 된 배경 말입니다.
00:05:27그 사람이 프로덕션 데이터베이스에 접근할 권한이 애초에 있었어야 했는지, 사용 중인 도구들의 인체공학적 설계는 적절했는지, 전날 잠은 제대로 잤는지,
00:05:34호출(Paging)은 얼마나 많이 받았는지 등 온갖 요소들이 얽혀 있습니다.
00:05:38아무튼 사람들이 '인적 오류'라고 말할 때 저는 바로 그 책을 떠올립니다. 쇼 노트에 링크를 남겨드려야겠네요.
00:05:45제 첫... 제 생각에 저의 첫 번째
00:05:49E2E(종단간) 테스트 입문은 어떤 강의를 들었을 때였던 것 같아요. 누군가 이런 일화를 들려주었죠.
00:05:54외과 의사들을 위해 개발된 소프트웨어가 있었는데 특정 순서대로
00:05:58버튼을 클릭해야 했다고요.
00:06:03그런데 의사들이 너무 익숙해진 나머지 버튼을 너무 빨리 누른 나머지
00:06:07소프트웨어에 오류가 나기 시작했고, 아무도 그런 일이 일어날 거라고는 예상하지 못했다는 이야기였어요.
00:06:13정말 흥미로운 일이죠.
00:06:15맞습니다. 인간과 자동화 사이의 교차점은 우리가 운영하는 제품에서 항상 주의를 기울여야 하는 부분입니다.
00:06:25네.
00:06:26그리고 또 들은바로는, 처음
00:06:28데브옵스와 SRE를 시작하셨을 때 삐삐(페이저)를 들고 다니던 시절이셨다면서요? 맞나요?
00:06:35네, 맞습니다. 실제로 온콜(비상 대기) 근무를 처음 할 때 물리적인
00:06:42페이저를 지급받았죠. 물론... 오, 와우. 대체 몇 년도인가요?
00:06:462005년이었습니다.
00:06:48오, 와우. 그렇군요. 제 첫 번째 기술직 일터는... 아, 이거 정말 재밌네요.
00:06:55플로리다주 플랜트시티에 있는 차고에서 일했어요. 모든 성공적인 스타트업이 그렇듯이요.
00:07:02친한 친구의
00:07:04아버님이 부업으로 차고에서 웹 호스팅, 이메일 호스팅, 다이얼업 ISP 사업을 하고 계셨습니다.
00:07:12이름이 커티스 펠레니(Curtis Fellaini) 분이신데, 정말 깊이 존경하는 분입니다. 그분이
00:07:18제게 모든 것을 가르쳐 주셨죠. 당시 저희는 '왓츠업 골드(WhatsUp Gold)'라는 온콜 도구를 사용했어요.
00:07:24이름은 기억하시겠지만, 그 도구가 하는 일은 HTTP 검사를 하는 게 아니었습니다.
00:07:33서버에 ICMP 핑을 날리는 거였죠. 그냥 옛날 방식의 핑을 보내서 응답이 안 오면
00:07:40호출을
00:07:42보내는 식이었습니다. 그곳에서 일할 때 한동안 페이저를 들고 다녔어요.
00:07:48그 직후에 모교의 슈퍼컴퓨팅(HPC) 부서에서 일할 때는 나기오스(Nagios)를 썼고
00:07:54휴대폰으로 문자 메시지를 받았죠.
00:07:57그게 의도적인 선택이었나요, 아니면 그때쯤엔 이미 방금 말씀하신 SMS 문자 같은 더 새로운 기술들이 나와 있었나요?
00:08:07맞아요, 그 시절에도 도구들은 더 있었습니다.
00:08:11비록 제한적이긴 했지만 당시 인프라를 모니터링할 수 있는 도구들이 더 있었죠.
00:08:15사우스플로리다 대학교의 HPC 부서에 있을 때는 이미 수백 대 규모의 서버를 다루고 있었습니다.
00:08:22HPC 환경이니까요. 연산 작업을 수행하는 서버 랙들이 늘어서 있는 식이었죠. 그래서 우리는
00:08:27조금 더 무언가가 필요했습니다.
00:08:31페이저보다는 말이죠.
00:08:34그리고 호출에 담기는 내용도 중요했어요. 만약 그냥 단순한
00:08:40메시지만 받으면 '아, 삐삐가 울렸으니 뭔지 확인하러 가야겠네' 하는 식이었지만,
00:08:45나기오스를 쓰면서부터는 최소한 어떤 맥락을 얻을 수 있었습니다. 이 서버가
00:08:50다운되었다거나 이 서버에 연결된 서비스가 다운되었다는 식이었죠. 그래서 그때 당시에도
00:08:56호스트별 또는 서비스별로 모니터링하고 싶은 사항을
00:09:01설정할 수 있는
00:09:03어느 정도의 정교함은 갖추고 있었습니다.
00:09:06확실히 SLO(서비스 수준 목표) 개념이 나오기 전이었고, 그런 건 생각조차 안 하던 때였죠.
00:09:13그저 이 포트가 열려 있는지, 그리고 기대한 응답을 주는지만 생각했습니다.
00:09:17와, 2005년이요. 저는 그때 아마 중학교에 다닐 때였을 텐데, 컴퓨터
00:09:26과학 같은 건
00:09:28생각조차 안 하던 시절이었네요.
00:09:30나이는 안 그렇게 보이지만 제가 생각보다 나이가 많습니다. 네, 그렇군요. 정말 동안이시네요. 감사합니다.
00:09:37조사해 보니 메타(Meta)에서도 일하셨던 것 같은데, 거기서는 어떤 일을 하셨나요?
00:09:43그리고 메타에서 일하는 것은 어땠나요?
00:09:45오, 정말 멋진 경험이었죠. 저는 프로덕션 엔지니어이자
00:09:48프로덕션 엔지니어링 매니저로 일했습니다.
00:09:52그게 무슨 뜻이냐면, 메타 식의 SRE라고 보시면 됩니다. 저는 두 가지 프로젝트에서 일했는데, 첫 번째 프로젝트는 몇 달 동안만 참여했던
00:10:00컨베이어(Conveyor)라는 팀이었습니다. IEEE 등에 컨베이어에 관한 공개 논문도 나와 있을 겁니다.
00:10:06컨베이어는 아마 지구상에서 가장 큰 규모의 지속적 배포(CD) 시스템 중 하나일 겁니다.
00:10:11그래서 메타의 백엔드 서비스들을 위해 빌드된 모든 아티팩트들은
00:10:18컨베이어를 거치게 되며, 수천, 수만 개에 달하는 백엔드 서비스들에 모든 변경 사항이 점진적으로 배포됩니다.
00:10:25그게 메타 내부 전용 시스템인가요?
00:10:29내부 전용이요, 네.
00:10:31보리스 구브릭이 쓴 관련 논문이 있으니까 꼭 읽어보시면 좋겠네요.
00:10:37그들이 무엇을 만들었는지 아주 흥미롭습니다.
00:10:39그것을 확장하던 시기에 몇 달 동안 그곳에 있었고
00:10:43초기 단계였기 때문에 경보 시스템 구축을 도왔습니다.
00:10:46매주 수백 건의 경보가 울리는 식이었는데 저는 생각했죠.
00:10:49“잠깐, 이걸 좀 정리해서
00:10:51최소한 장애가 발생했을 때 언제 일어나는지 알 수 있도록 가시성을 확보하자”고요. 그리고
00:10:58몇 가지 절차도 마련했습니다.
00:11:00기능 플래그 툴을 사용해 핵심 기능을 차단하는 긴급 절차 같은 걸 뭐라고 해야 할까요?
00:11:06음, 인시던트 발생 시 신속하게 복구할 수 있도록 말이죠.
00:11:10그렇게 몇 달 동안 일했지만 제 재직 기간의 대부분은
00:11:13다른 팀에서 보냈습니다.
00:11:16일종의 사내 헤로쿠 같은 곳이었죠. 아주 단순한 무상태(stateless) 서비스들이 있고
00:11:23팀들은 이런 서비스를 끊임없이 만들어내며 어딘가에서 실행해야 했습니다.
00:11:29그 팀과 서비스는 그 과정을 단순화하기 위해 존재했어요. 예전에는 서비스를 세팅하는 게 매우 어려웠거든요. 그래서 저는 첫 번째
00:11:37프로덕션 엔지니어로
00:11:40그 팀에 합류했습니다. 꽤 대단한 일들이 있었죠. 거기서 제가 한 일이 바로 그겁니다.
00:11:44확실히 정말 재미있었어요. 함께 일했던 사람들 중에는
00:11:48두뇌가 저보다 다섯 배는
00:11:51더 큰 사람들 같았어요. 그런 회사에서 같이 일하는 사람들은 정말
00:11:55엄청나게 명석하고 거기서 정말 많은 것을 배웠습니다. 아, 그리고 허니콤이라는 회사가 있는데
00:12:02그 창업자인 채리티 메이저스가 메타에 있었잖아요?
00:12:06그분 아시나요? 만나본 적 있으세요?
00:12:09음, 네. 정말 흥미롭네요.
00:12:12그 질문을 하시니 말인데, 1년 반 전에 보스턴에서 열린 옵저버빌리티 데이 행사이서 직접 만났습니다.
00:12:20맞아요, 그분은 메타에서 일하셨고
00:12:22허니콤의 영감을 얻은 곳은
00:12:26행성 규모의 관측 가능성 툴인 스쿠바(Scuba)였습니다.
00:12:30맞습니다. 저도 스쿠바를 정말 잘 썼고 좋아했어요. 그분이 그런 방향으로
00:12:37회사를 창업하게 되어 기쁩니다. 최근에 우리 둘 다 관심 있는 주제 때문에
00:12:44링크드인에서 가끔 이야기를 나누기도 했는데요,
00:12:47에이전틱 코딩이 신뢰성에 어떤 영향을 미칠지에 대한 공통된 관심사 때문이죠.
00:12:51그래서 그 주제에 대해 가끔 이야기를 나누곤 했습니다.
00:12:54아무튼 그분은 정말 멋진 분이고 가끔 대화를 나눌 수 있다는 건 큰 영광입니다.
00:12:59네, 그럼 자연스럽게 저희가 여쭤보고 싶었던 주제로 넘어가 보죠. AI가 SRE와 데브옵스,
00:13:06그리고 이러한 관행들을 어디로 이끌 거라고 생각하시나요?
00:13:13아이고, 좋습니다. 훌륭한 질문이네요. 바로 본론으로 들어가겠습니다.
00:13:19소프트웨어 엔지니어들에게는 아주 놀라운 도구가 주어졌습니다.
00:13:24바로 에이전틱 개발이죠. 클로드 같은 툴을 통해 원할 때마다 코드가 마법처럼 생성되는 시대입니다.
00:13:35이 말은 곧 앞으로 엄청난 양의 코드가
00:13:39흘러들어오게 될 거라는 뜻입니다.
00:13:42가치 스트림, CI/CD 파이프라인, 테스팅, 리뷰, 코드 배포, 인시던트 대응, 변경 관리 절차 등 말이죠.
00:13:50이 모든 코드가 우리 각자가 회사를 위해 구축한 시스템을 거쳐 지나가게 될 것입니다.
00:13:56그 말인즉슨 우리가 보유한 모든 역량이
00:13:58스트레스 테스트를 받게 된다는 뜻입니다. 예를 들어
00:14:01소프트웨어에 가할 수 있는 변경 횟수와
00:14:04받게 되는 경보나
00:14:06인시던트 발생 건수 사이에는 선형적인 관계가 존재합니다.
00:14:12이것은 확립된 사실입니다.
00:14:14그러므로
00:14:15파이프라인을 통과하는 코드의 흐름을 10배 늘리면
00:14:20경보도 10배로 늘어날 거라고 가정하는 것이 합리적입니다.
00:14:23그렇다면 조직은
00:14:26이에 어떻게 대응해야 할까요? SRE 관점에서 볼 때 저는 이렇게 예상합니다.
00:14:32앞으로 우리 운영 담당자들이 매우
00:14:39큰 인기를 끌게 될 것입니다. 우리가 바로 병목 구간이 될 테니까요.
00:14:42이제 코드를 작성하고 배포하는 것은 문제가 아닙니다. 중요한 건 “어떻게 운영할 것인가?”입니다.
00:14:49잘 작동하고 있는가? 고객의 기대를 충족하고 있는가?
00:14:51음,
00:14:53그리고
00:14:55이것이 바로 주요한 변화가 될 것이라고 예상합니다.
00:14:58이 전환기 동안 잘못될 수 있는 부분이 너무 많기 때문에 엄청난 도전 과제입니다.
00:15:04앞서 말했듯이 인시던트가 훨씬 더 많이 발생할 수 있습니다. 실패로부터 어떻게 배우고 있으며
00:15:09사후 분석(포스트모텀)은 계속하고 있는지, 실제로 작동하는 CI/CD 파이프라인을 구축하고 있는지,
00:15:15결과적으로 인간의 노력이 항상 높은 레버리지를 가지도록 만들고 있는지가 중요합니다.
00:15:20재미있는 점은 우리가 이 순간을 위해 수십 년 동안 준비해왔다는 것입니다. 다만
00:15:27엔지니어가 2만 명이나 있는 빅테크의 관점에서 생각하는 경향이 있었죠.
00:15:31하지만
00:15:33이제는 더 작은 조직도 10배 많은 코드를 다룰 수 있게 되었고, 결과적으로 흐름은 같아졌습니다.
00:15:38따라서 대기업들이
00:15:40지난 10년 동안 글을 쓰고 이야기해 온 모든 기본 원칙들을
00:15:47이제 우리 모두가 실제로 실천해야 합니다.
00:15:49모든 기본기를 실제로 지켜야 하는 거죠. 그리고 또 다른 문제는
00:15:53이겁니다.
00:15:56소프트웨어 개발 조직들이 가장 많은 시간이 소요되는 작업이 코딩이라는 생각 하에 조직되어 있었다는 점입니다.
00:16:03그래서 엔지니어들이 최대한 많은 시간을 코딩에 쏟게 해야 했죠.
00:16:05만약 그것이 더 이상 진실이 아니라면,
00:16:09우리는 이제 가장 많은 시간이 걸리는 활동을 중심으로 조직을 재편해야 합니다.
00:16:15따라서 이러한 조직을 운영하는 방식에도 약간의 변화가 생길 것입니다. 마지막으로
00:16:20AI SRE 트렌드에서도 이미 보셨을 텐데요.
00:16:23제가 제 팟캐스트에서 종종 이야기했듯이, 우리는 적절한 곳에 기술을 능숙하게 도입해야 합니다.
00:16:31운영 작업을 수행하는 데 큰 레버리지를 얻을 수 있는 곳에 말이죠.
00:16:37좋은 예로 incident.io 같은 기업이 있습니다. 호출을 받으면
00:16:44침대에서 일어나기도 전에
00:16:47“최근 코드베이스에 어떤 변경 사항이 있었지?” 같은 에이전틱 워크플로가 이미 작동합니다.
00:16:53경보는 정확히 무엇을 말하는가? 지표는 무엇을 보여주는가? 를 파악하여
00:16:59침대에서 일어나 눈곱도 떼기 전에 초동 진단을 시도해 줍니다.
00:17:04따라서 우리가 가진 운영 책임 영역 중에는 AI로부터
00:17:09큰 이점을 얻을 수 있는 곳들이 있습니다. 하지만 모든 것을 무작정 도입해서는 안 되며
00:17:12실제 문제가 무엇인지, ROI가 무엇인지 신중하게 생각해 봐야 합니다.
00:17:16아무튼 이게 제 주장입니다. 몇 주 뒤에 바로 이 주제로 웨비나도 진행할 예정입니다.
00:17:23정말 흥미롭네요. 왜냐하면 앞서 말씀하신 유스케이스,
00:17:29침대에서 일어날 때 무언가에 대해 이미 호출을 받는 상황 말이죠.
00:17:32그게 실제로 구현된 적이 있나요? 제가 보기에
00:17:36잘못될 수 있다고 생각되는 점은, 예를 들어 첫 번째 트리아지 단계에서
00:17:43AI가 스스로 해결할 수도 있겠지만, 그다음에는 인간의 개입이 필요하다는 것입니다.
00:17:51코딩에 비유해 보면, 클로드 코드가 추론을 하다가 '이렇게 해야지' 하다가도
00:17:56“잠깐만, 아니야
00:17:59이거
00:17:59다 지우고 처음부터 다시 이렇게 해야겠어”라고 할 때가 있잖아요.
00:18:02이런 인시던트 관리 봇들에게도 똑같은 일이 일어날 수 있을 것 같아요. “아, 이거 쉬운 해결책이네,
00:18:10잠깐, 내 혼자서 해결할 수 있을지도 몰라” 하는 식의 상황 말이죠.
00:18:13네, 100% 맞는 말씀입니다.
00:18:151970년대 IBM의 이런 명언이 최근 다시 회자되고 있죠. “컴퓨터에게 관리적 결정을 내리게 하지 마라.”
00:18:22제가 드리고 싶은 말씀은, 이러한 AI 툴링이나
00:18:27일반적인 자동화를 사용하는 방식에는
00:18:29두 가지 철학이 존재한다는 것입니다.
00:18:32첫 번째는 '잔여물 원칙(leftover principle)'이라고 불리는 것으로, AI가 아니더라도
00:18:38이러한 모든 작업을 우리 대신 자율적으로 수행해 주는 툴을 도입하고
00:18:43우리는 신경 쓸 필요가 없다고 여기는 방식입니다.
00:18:46그리고 인간에게는 보통 박사 학위가 있어야 해결할 수 있는 일들만 잔여물로 남겨두죠.
00:18:51음,
00:18:53이것은
00:18:54박사급 인력에게 예산을 다 쏟아부어야 하므로 효율적이지 않고,
00:18:57자율적으로 실행되는 시스템에 너무 많은 신뢰를 두게 되어 잘못된 판단을 내릴 경우 큰 곤경에 처할 수 있습니다.
00:19:04반면에 더
00:19:07유연하고 합리적인 철학은 '보상 원칙(compensatory principle)'이라고 불리는 것으로, 인간의 노력을 배증시키는 것입니다.
00:19:15컴퓨터와 자동화가 잘하는 일은 그것들이 맡게 하고, 인간이 잘하는 일은 인간이 하도록 하는 것이죠.
00:19:22인간이 잘하는 일은 바로
00:19:25이런 것입니다.
00:19:26우리는 시스템의 맥락을 이해합니다. 해결하려는 문제가 무엇인지 알고 있고, 고객 경험이 어떤지도 알고 있죠.
00:19:33우리 머릿속에는 엄청나게 많은 맥락이 담겨 있어서
00:19:38AI에게 모든 것을 맡기는 것보다 우리가 직접 활용하는 것이 훨씬 더 유리합니다. 따라서 질문에 더 직접적으로 답하자면,
00:19:44이 AI 기반의 도구 재편 작업은
00:19:50잘 통제되고 정의된 경로가 있는 경우가 아니라면 프로덕션 환경에 변경을 가하는 방식으로 이루어져서는 안 됩니다.
00:19:58예를 들어 코드의 자동 롤백 같은 걸 들 수 있죠. 쿠버네티스를 생각해보시면 AI 없이도
00:20:06그런 걸 자동으로 처리하잖아요? 배포를 진행하면서 새 컨테이너 이미지 버전으로 바꾸는데
00:20:13준비 상태(Readiness) 검증에 실패하면 어떻게 될까요?
00:20:16변경 사항이 배포되지 않겠죠.
00:20:19맞습니다. 그런 메커니즘은 매우 단순하고 이해하기 쉬우며, 이를 통해 우리가 안전하게 변경 작업을 수행할 수 있게 해줍니다.
00:20:26그런 잘 정의된 문제 유형들은 자동화에 맡겨도 되며, 자동화는 이미 그런 작업을 수행하고 있습니다.
00:20:32하지만 지금 당장
00:20:35AI가 사람의 개입 없이 “그래, 인프라를 이렇게 수정하자”라고 그냥 말하게 놔두는 것은
00:20:41무책임하다고 생각합니다. 앞서 제기했던 제약에 대한 이야기로 돌아가서, 우리 인간의
00:20:46시간은 이제 다음과 같은 일로 전환될 것입니다.
00:20:49과연 이것이 정말 올바른 결정인가?
00:20:52그러니까 그런 승인이나 코드 리뷰, 인프라 변경 사항에 대한 검토 과정이
00:20:59우리의 많은 노력이
00:21:00투입될 것이라고 생각합니다.
00:21:03물론 가능한 부분은 자동화하고 싶어 하겠지만, 거기에는 규율과 안전성 입증 기록이 뒷받침되어야 합니다.
00:21:09네, 그리고 아까 하셨던 말씀과 관련해서 또 다른 질문은, 코드가 많아질수록 장애도 늘어난다는
00:21:19선형적 비교 관계에 대한 것입니다. 이 분야에서 컨설턴트로 일해 오셨는데,
00:21:22실제로 기업들이 이런 현상을 겪고 있다는 이야기를 들으신 적이 있나요? 예를 들면
00:21:28더 많은 코드를
00:21:30생성하거나
00:21:31AI에게 더 많은 코드를 오프로딩하면서 그 결과로 더 많은 장애를 겪고 있는지 말입니다.
00:21:36분명히 그렇습니다, 확실히 그렇고말고요.
00:21:39틀림없이 그렇습니다. 게다가 이러한 변화로 인해 새롭게 나타나기 시작하는 다른 실패 모드(failure mode)들도 있다고 덧붙이고 싶습니다.
00:21:47생각해 보면
00:21:49정말 쉽고 직관적으로 이해할 수 있는 대표적인 문제가 바로
00:21:53CI/CD
00:21:54파이프라인이 정체되는 현상입니다. 빌드 아티팩트가 생성된 후 프로덕션으로 배포되기까지의 지연 시간이 점점 길어지고 있습니다.
00:22:00파이프라인을 거쳐 가는 변경 사항이 그만큼 많아졌기 때문이죠. 따라서 조직들은 이미
00:22:05이러한 고통을 체감하기 시작하고 있습니다. 간단한 사례 연구를 하나 말씀드리자면, 최근에 진단을 수행한
00:22:12고객사가 있었습니다. 제 업무 중 하나가 회사의 전체적인 운영 태세,
00:22:17즉 코드를 배포하고 운영하는 방식을 전반적으로 살펴보고 다음에 무엇을 해야 할지 가이드를 제공하는 것이거든요.
00:22:24그 팀 중 한 곳이 “아, 이 Claude라는 거 정말 대단하네. 이걸로 기능들을 막 찍어내자”라고 생각했고,
00:22:31실제로 그렇게 했습니다. 하지만
00:22:33릴리스 방식은 바꾸지 않았고 탄탄한 코드 리뷰 프로세스도 갖추지 않았습니다.
00:22:38그랬더니 장애 건수가 즉시 치솟았습니다. 그래서 그들은
00:22:43코드에 집중하며 하려던 것들을 마음껏 배포하는 대신, 고객 문의와 장애 대응에 파묻히게 되었습니다.
00:22:49말 그대로 정신을 차리지 못했죠.
00:22:51그러니까 이건 이론적인 이야기가 아니라 지금 당장 일어나고 있는 일입니다.
00:22:55프로덕션에 반영되는 변경 사항의 규모가 이렇게 몇 배나 커지면,
00:23:01결국
00:23:03운영 태세에 있는 모든 약점이 드러나게 됩니다.
00:23:06그렇다면 SRE 닥터로서
00:23:09이런 문제를 겪고 있는 클라이언트에게는 어떤 조언을 해주시겠습니까? 방금 말씀하신 것처럼 말입니다.
00:23:16맞습니다. 아까 살짝 언급했듯이,
00:23:18우리가 지난 1~2년 또는 그 이상 기간 동안 이야기해 온 기본기로 다시 돌아가야 합니다.
00:23:24팀들이 기본에 집중해야 한다는 뜻입니다.
00:23:27예를 들어
00:23:29유효한 테스트 전략을 갖추고 있어야 하고요.
00:23:35프로덕션에 배포하려는 코드가 높은 품질을 갖추고 있음을 확실히 알아야 합니다.
00:23:39과거에 배웠던 모든 것들 외에도, 저는 서비스 수준 목표(SLO)의 열렬한 신봉자입니다.
00:23:43SLO를 적극적으로 도입해야 한다고 생각합니다.
00:23:47이를 통해 고객의 관점에서 프로덕션 시스템의 건강 상태를 파악할 수 있기 때문입니다.
00:23:52따라서 그것은
00:23:54퍼즐의 아주 큰 조각입니다. 데이터에 기반하여 기능 요청 등의 프로덕션 변경 속도를 조절할 수 있게 해주니까요.
00:23:59그렇게 함으로써 새로운 수익원을 쫓는 동안
00:24:03기존의 수익원을 위험에 빠뜨리지 않을 수 있습니다.
00:24:07그것이 바로 비즈니스 관점에서 SLO가 필요한 이유입니다.
00:24:10제가 이전 회사에서 SLO와 관련해 한 가지 느낀 점이 있는데, 거기는 각 팀이
00:24:16SLO 목표를 유지해야 한다고 하면서도
00:24:19일부 팀의 경우 워낙 빠르게 움직이다 보니 그 목표를 달성하지 못했습니다.
00:24:25많은 팀이 뒤처지게 되었죠.
00:24:28그러자 경영진은 이렇게 결정했습니다.
00:24:30“됐고, SLO 목표를 지키는 것보다 기능을 빨리 출시하는 게 훨씬 중요하다.”
00:24:36맞습니다.
00:24:37그리고 그것이 아마도 10년 전에 구글이 약속했던 것만큼 SLO가 효과적이지 못했던 가장 큰 이유일 것입니다.
00:24:44이런 겁니다. 이전 콘텐츠에서도 이야기한 적이 있지만, SLO 프로그램을 도입할 수는 있습니다.
00:24:49엔지니어들을 구석에 모아 놓고 “자, 유저 여정이 어떻게 되지? 이걸 정량화해 보자, 그리고 모니터링을 붙이자”라며
00:24:55프로메테우스나 오픈텔레메트리를 설정하고 아주 그럴듯한 대시보드를 만들 수도 있겠죠.
00:24:57하지만
00:25:01제품 관리자(PM)
00:25:05그리고 제품 조직이 이에 협조할 마음이 없다면,
00:25:07임원진이 협조할 마음이 없다면
00:25:09그건
00:25:12아무 소용이 없습니다.
00:25:14그저 SRE들이나 일부 엔지니어들이 구석에 박혀서 “야, 지금 시스템 상태가 안 좋아”라고 외치는 꼴밖에 안 됩니다.
00:25:19반면에
00:25:21리더십은 계속해서 출시를 밀어붙이려 하죠. SLO가 성공하려면
00:25:26모두가 함께 참여하는 게임이어야 합니다. 그래서 제가 조직의
00:25:32SLO 태세를 진단할 때, 즉 제가 주로 하는 일 중 하나인데, 보통 이런 질문을 던집니다. 에러 예산이 소진되면
00:25:38제품 관리자는 어떻게 행동하는가?
00:25:41만약 PM이 “알겠습니다, 다음 스프린트 범위는 조정하겠습니다”라고 나온다면
00:25:46좋습니다.
00:25:48그건 중간 단계의 성숙도를 가진 것입니다. 만약 그렇게 하지 않는다면
00:25:50성숙도가 낮은 것입니다. 저는 기업들이 현재 여정의 어느 위치에 있는지 파악할 수 있도록 1단계(미성숙)부터 5단계(최적화)까지의 SLO 성숙도 모델을 직접 개발하기도 했습니다.
00:25:58말씀하신 대로 많은 조직들이 그렇습니다. 제대로
00:26:03SLO를 활용하지 않아요. 대시보드만 있고, 그 위에 지표는 뜨고, 엔지니어들은 그것 때문에 돈을 받지만
00:26:08막상
00:26:10비즈니스 의사결정에는 SLO가 활용되지 않습니다.
00:26:12그저 알림용으로만 쓰일 뿐이죠.
00:26:16그렇다면 선생님을 찾아오는 고객들의 경우, 어떤
00:26:21상황에 처해 있을 때 도움을 요청하나요?
00:26:24좋은 상황인가요, 나쁜 상황인가요, 아니면 그 중간인가요?
00:26:28상황에 따라 다릅니다. 제가 고객들과 함께 일하게 되는 변곡점은 대략 두 가지가 있습니다. 첫 번째 변곡점은
00:26:37투자 유치를 막 마치고 영업 조직이 승승장구하며 제품-시장 적합성(PMF)을 달성한 초기 단계의 회사입니다.
00:26:44하지만 이들은 세상 물정을 잘 모르고 엔터프라이즈급 인프라를 다뤄본 적이 없으며
00:26:49엔터프라이즈 고객에게 판매해 본 적이 없기 때문에, 커진 규모의 압박 속에서
00:26:53흔들리기 시작하는 경우입니다. 이는 제 커리어 초기에 제가 직접 겪었던 경험과 매우 흡사합니다.
00:26:59제가 직접 겪어봤기 때문에 아주 잘 아는 분야죠. 그것이 첫 번째 변곡점입니다.
00:27:04그건 재미있는 변곡점이에요. 비록 그곳에서 일하는 사람들에게는 스트레스가 될 수 있겠지만, 겪어볼 만한 좋은 문제죠.
00:27:09두 번째 변곡점은
00:27:12보통 규모가 더 큰 조직이 되어서 이제 여러 팀에 걸쳐 운영 방식을
00:27:17표준화해야 할 필요가 생겼을 때입니다.
00:27:21어쩌면 SRE 프로그램을 이미 가지고 있고, 그 SRE 프로그램이 얼마나 효과적인지, 프로세스가 잘 작동하고 있는지 평가해야 할 수도 있죠.
00:27:28협업 모델이 제대로 돌아가는지, 엔지니어링 팀과 제품 팀이 실제로 프로세스에 적극적으로 참여하고 있는지 확인해야 합니다.
00:27:34그래서 인수합병을 많이 하는 기업들이
00:27:37보통 저를 찾아옵니다. 인수할 때마다 완전히 새로운 기술 스택이 유입되기 때문에 이 통제 불능의 야수들을 길들이려 하기 때문이죠.
00:27:44따라서 모든 사람이 동일한 규칙에 따라 움직이도록 만들기 위해 고민해야 할 상위 수준의 거버넌스가 많이 존재합니다.
00:27:50그렇군요.
00:27:55그렇죠.
00:27:57아까 말씀하신 규모가 작은 회사들, 즉 투자를 받은 회사들의 경우를 보면,
00:28:02AI가 등장하고 사람들이 AI로 기능을 구축하게 되면서
00:28:06사람들이 AI를 이용해 기능을 대충 만들고 배포하기만 하니 구조적인 부족함이 더욱 가중될 것 같습니다.
00:28:13로그, 메트릭, 트레이스 같은 건 전혀 신경 쓰지 않고요.
00:28:16초기 단계에 있는 기업들이 문제를 겪으며 찾아올 때, 전문가 눈에는 뻔히 보이는데 당사자들은 문제로 여기지 않는
00:28:23가장 큰 문제들은 보통 어떤 것들이 있나요?
00:28:27네, 이전 답변에서도 살짝 언급긴 했지만, 거시적인 관점에서 틀을 잡고 말씀드리겠습니다.
00:28:34그러니까
00:28:36제가 눈에 띄게 보는 문제는 프로덕션에서 일어나는 일과
00:28:41고객 경험에서 일어나는 일, 그리고 제품 우선순위 설정 사이에 피드백 루프가 망가져 있다는 점입니다.
00:28:46저는 오랜 시간 동안 수많은 팀에서 이런 현상을 목격해 왔습니다. 아마 가장 흔한 문제일 겁니다.
00:28:55그래서 제가 컨설턴트로 일할 때
00:28:58이면에서 고민하는 것 중 하나는 이 피드백 루프가 제대로 구축되도록 어떻게 보장할 것인가입니다.
00:29:03정말 놀랍게도
00:29:05많은 기업들이 장애를 겪고
00:29:08고객들이 화를 내며
00:29:10지원 부서에 티켓을 접수하고, 지원 부서는 티켓으로 마비되곤 합니다.
00:29:13지원 부서는 제품 엔지니어링 조직에게 '피드백'이라는 엄청난 선물을 줄 수 있습니다. 그들은 알고 있죠.
00:29:23고객이 무엇 때문에 화가 나고 서비스를 즐기지 못하는지, 그리고 무엇이 그들을 이탈하게 만드는지
00:29:30그리고 저는 반복해서 목격해 왔습니다
00:29:33그러한 피드백이 완전히 무시되거나 신기능 개발 작업보다 낮은 우선순위로 밀려나는 것을요.
00:29:41그 결과 최종적으로 나타나는 모습은
00:29:44제품에 불이 났는데도 기능 개발에만 전속력으로 전진하는 것입니다. 제 눈에는 그것이
00:29:51팀들을 인터뷰하고 진단할 때 바로 눈에 띄는 부분입니다.
00:29:55하지만 보통 회사 내부에서 일할 때는 잘 보이지 않습니다. '아, 나는 소프트웨어 엔지니어고
00:29:59기능 출시로 평가받으니까 지난 분기에 위젯 50개 냈어, 멋져, 보너스 받겠네'라고 생각하니까요.
00:30:05제품 관리자들도 똑같이 생각합니다.
00:30:07'그래, 이 프로젝트들을 끝냈어. 이 고객이 우리 덕분에 계약했지.' 하지만 그 사이에
00:30:11기존 고객들은 극도로 분노해 있습니다. 현재 상황에 전혀 만족하지 못하고 있죠.
00:30:16즉, 피드백 루프가 망가져 있는 겁니다.
00:30:19그게 혹시 샌프란시스코의 문화 때문인가요, 아니면 단순히
00:30:22사람들이 경쟁사보다 더 나아 보이기를 원해서인가요? 잘 모르겠네요. 왜 그렇다고 생각하시나요?
00:30:28샌프란시스코만의 고유한 특성이라고는 생각하지 않습니다. 비즈니스 전반의 본질, 즉 보상 구조에서 비롯된 문제라고 봐요.
00:30:36왜냐하면 비즈니스 문화에서는
00:30:39어떤
00:30:41조직이든
00:30:42부서가 나뉘게 될 때 말입니다.
00:30:44회사가 성장하면서 노력을 조직화해야 하므로 이는 자연스럽게 발생합니다.
00:30:49그러면 부서 간 벽이 생기죠.
00:30:51'저쪽에는 소프트웨어 엔지니어들이 있고, 이쪽에는 제품 관리자들이 있어.' 엔지니어링 팀에
00:30:55배치되어 있을 수도 있지만 각자 자신만의 보상 체계가 있습니다. 지원 부서와 데브옵스, SRE 팀도 마찬가지고요.
00:31:01그들 모두 각자 따로 놀고 있고, 인센티브도 서로 상충됩니다.
00:31:06맞습니다. 그리고
00:31:09보통
00:31:11이 단계에서는 아무도 그들과 진지하게 마주 앉아 이렇게 말하지 않습니다.
00:31:13'우리가 어떻게 보상 구조를 바꿔야 모두가 같은 방향으로 나아갈 수 있을까?'라고요.
00:31:18메타가 했던 일들 중에서 제가 정말 좋아하고
00:31:21매우 효과적이라고 생각하는 방식 중 하나는
00:31:25적어도 제가 함께 일했던 팀에서는 엔지니어의 성과를 평가할 때 단순히 기능만 보는 것이 아니었다는 점입니다.
00:31:31운영 우수성과 프로덕션 우수성을 평가했죠.
00:31:34어떤 장애 대응에 참여했는지, 어떤 신뢰성 관련 작업을 했는지, 어떤 확장성 작업을 수행했는지를 살펴보았습니다.
00:31:41시스템을 더 안정적이고 운영하기 쉽게 만들기 위해 무엇을 했는지가
00:31:45보너스를 받을지, 승진을 할지와 직결되는 중요한 기준이었습니다.
00:31:51평가 기준의 핵심적인 부분이었죠.
00:31:54그래서
00:31:57그런 부분에
00:31:58본격적으로 집중하기 시작하자 소프트웨어 엔지니어들의 인센티브가 변했습니다. 제가 속했던 팀에서도
00:32:05함께 일하는 엔지니어링 리드들과
00:32:07그 방향을 강력하게 밀어붙였을 때
00:32:12엔지니어들이 마법처럼 저에게 찾아와 '저도 안정성 관련 작업에 같이 참여하고 싶습니다, 부하 테스트 프로세스를 제가 맡아도 될까요?'라고 물어보더군요.
00:32:18그럼요, 물론이죠. 여기 런북과 스크립트들이 있으니
00:32:20마음껏 해보라고 했습니다. 인센티브가 바뀔 때 어떤 일이 벌어지는지 보면 정말 놀랍습니다.
00:32:25따라서 모든 조직에게 이는 자연스러운 진화 과정이라고 생각합니다. 모든 사람이 모든 것을 책임지는 아주 작은 스타트업이라면 말이죠.
00:32:29상황이 달라지면
00:32:31모든 것이 제각각인 아주 작은 스타트업에서 일한다면 이는 어느 조직에게나 자연스러운 발전 과정이라고 생각합니다
00:32:38그리고 투자를 유치하려 하고 초기 고객들을 확보하며 그들을 만족시키려 애쓰죠
00:32:43제 생각에는 이해관계가 이미 잘 맞아떨어져 있다고 봅니다
00:32:45그렇지 않다면 회사가 살아남지 못했을 테니까요. 하지만 규모가 커지고 관심사가 분화되기 시작하면
00:32:51조직 전체의 이해관계를 맞추는 보상 구조를 유지하기가 점점 더 어려워집니다
00:32:55맞아요, 바로 이 지점에서 SRE와 데브옵스를 다룰 때 사회기술적 요소들이 대두되기 시작하죠
00:33:00그렇군요. 그리고 AI가 전력 질주하고 있는 이 시점에
00:33:06이 분야에서 일하는 당신 같은 사람들이 더 많이 필요해질 거라고 하셨는데, 한편으로는
00:33:12소프트웨어 엔지니어링은 죽었다고들 하잖아요? 이제 일자리가 없다고요
00:33:17그렇다면 이 팟캐스트를 듣고 있는 주니어 개발자들의 입장에서 볼 때
00:33:23지금 이 시점에 SRE와 데브옵스는 뛰어들기 좋은 분야일까요? 네, 당연히 그렇죠
00:33:30저는 소프트웨어 엔지니어링이 죽었다고 말하는 사람이 되지는 않겠습니다. 확실히 반박할 수 있어요.
00:33:36사실 저는 기본기가
00:33:38오히려 더욱
00:33:41중요해졌다고 생각합니다
00:33:43프로그래밍 언어와 그 작동 원리를 이해하는 것, 알고리즘과 그 작동 방식을 아는 것이 훨씬 더 중요해졌어요
00:33:50왜냐하면
00:33:53AI가 생성한 코드를 우리가 도대체 어떻게 검토해야 할까요?
00:33:56그리고 제대로 작동하는 시스템을 어떻게 설계해야 할까요? LLM 모델에게 그냥 “이것 좀 설계해 줘”라고 던져준다고 해서
00:34:04그게 확실히 작동할 거라고 장담할 수 있나요? 이렇게 말씀드려 보죠. Claude Code 프로젝트를 열고
00:34:08다리나 초고층 건물을 설계해 달라고 요청해 보세요
00:34:11그런 다음 그 설계를 가지고 실제로 건설을 해보라고 한 뒤에
00:34:15그 건물이 직접 들어가서 앉아보라고 한다면, 과연 편안하게 그럴 수 있겠습니까?
00:34:18AI가 설계한 다리를 편안한 마음으로 건널 수 있으신가요?
00:34:22고개를 내젓는 걸 멈추기 전까지는 말이죠. 우리에게는 여전히 그런 엔지니어들이 필요합니다
00:34:25맞습니다. 그리고 SRE와 데브옵스 인력의 경우에도 당연히
00:34:31더 많은 인재가 필요합니다. 왜냐하면 병목 현상이 바로 거기서 발생하기 때문이죠
00:34:34시스템에 그토록 많은 변화를 준다면, 우리는 반드시 서비스가 정상적인지 확인해야 하고
00:34:39프로덕션 환경에 미치는 변경의 여파를 제대로 이해하고 있어야 합니다
00:34:43최상위 수준으로 확장해 보면 건강하고 모니터링이 잘 되며 프로덕션 서비스처럼 다뤄지는 CI/CD 파이프라인과 가치 스트림을 갖춰야 하죠
00:34:51제 관점에서는 이러한 모든 기술들이 앞으로 훨씬 더 중요해질 것입니다
00:34:58제가 보통 바라보는 관점은 이런 겁니다. F1 경주를 보면 피트 크루가 있잖아요.
00:35:04그 피트 크루는 차량에 대해 모든 것을 알고 모든 부품을 교체할 수 있으며 드라이버가 트랙을 지배할 수 있게 해줍니다.
00:35:12그런 사람들이 반드시 필요합니다
00:35:15왜냐하면 그것이 제품 관리자와 아키텍트들에게 환경을 제공해 주기 때문이죠
00:35:22그러한 제약 없이 빠르게 반복 작업을 하고 변경 사항을 배포할 수 있도록 말입니다
00:35:27그러므로 제 생각에는
00:35:29말이죠
00:35:30지금은 SRE가 되기에 정말 좋은 시기입니다. 몇 년 전과는 분위기가 달랐죠. 다들 해고를 당하던 때였으니까요
00:35:35하지만 제 생각에는
00:35:37기본기에 정말 깊이 집중하고 이해한다면 말입니다
00:35:39리눅스와 시스템뿐만 아니라 사회 기술적인 부분, 즉 진정한 SRE가 된다는 게 어떤 의미인지 잘 파악한다면
00:35:46이 커리어에서
00:35:49매우 멀리 나아갈 수 있다고 봅니다
00:35:51이러한 에이전틱 개발의 도래에 대해 항상 인지하고 있어야 합니다. 모래에 머리를 박고 외면해서는 안 돼요
00:35:57모른 척할 수가 없죠
00:35:59앞서 언급하셨던 책이
00:36:02피닉스 프로젝트였나요? 네, 그 책이요
00:36:05그렇다면 이 주제를 아주 깊게 파고들고 싶어 하는 사람에게 유용한 또 다른 리소스는 어떤 것이 있을까요?
00:36:12아, 정말 많죠. 소문난 명저들을 몇 가지 소개해 드리겠습니다
00:36:18데브옵스 핸드북(The DevOps Handbook)도 좋습니다. 그 책이 나왔을 때 느꼈던 건
00:36:21책이 출간되기 전에 제가 배웠던 모든 내용이 아주 훌륭하게 요약되어 있었다는 점입니다
00:36:27존 코터(John Kotter)의 '변화의 리더십(Leading Change)'도 훌륭한 책입니다
00:36:30조직 내의 변혁적 변화와 리더십을 다루는 책이죠
00:36:34팀에서 SRE로 활동하거나 신뢰성 혁신을 주도하고자 할 때 유용한 프레임워크를 제공해 줍니다
00:36:41알아두면 좋은 책이고요, '토요타 카타(Toyota Kata)'도 있습니다
00:36:45토요타가 자동차 제조 과정에서 어떻게 지속적인 개선을 이루어내는지 다룬 책인데
00:36:52정말 유용합니다. 해당 시스템을 처음으로 만들어낸 곳들 중 하나죠. 네, 들어본 적이 있는 것 같네요
00:36:59감사합니다.
00:37:02초대해 주셔서 감사합니다.
00:37:04일본의 경제적 기적이 애자일을 탄생시켰고
00:37:07데브옵스의 전신이 되었죠. 경영의 실제 같은 다른 책들도
00:37:13새로운 개정판이 나온 것 같은데 아주 유용합니다
00:37:17구글이 내놓은 SRE 책들도 좋지만, 단서를 하나 달자면
00:37:22그런 책들은 규모가 엄청나고 예산이 무한한 기업에 다니는
00:37:27예산이 무제한인 사람들이 쓴 책들이니까요.
00:37:30그래서 그들의 업무 방식이나 접근 방식은 여러분이
00:37:354인조 스타트업에서 일하는 방식과는 다를 겁니다.
00:37:37하지만 그 모든 조각들을 하나로 모아보면 엔지니어로서, 또
00:37:44리더로서,
00:37:44그리고
00:37:46전략가로서 데브옵스와 SRE 이니셔티브를 주도하는 법을 이해할 수 있게 될 겁니다.
00:37:49그래서 저는 전체적인 관점에서 생각하기 때문에 좀 더 독특한 시각을 가지고 있다고 생각합니다. 저는 단순히
00:37:55쿠버네티스만 파고들어서 작동하게 만드는 게 아닙니다. 팀이 제대로 일할 수 있게 만들려고 하죠.
00:37:59그러고 나서 기술적인 문제를 파악하고 해결하는 겁니다.
00:38:03청취자 여러분, 언급된 책들은 쇼 노트에 링크해 두겠습니다.
00:38:09음, 제가 여쭤보려고 했던 건데요. 다시 AI 이야기로 돌아가서, 기본기를 배워야 한다는 점이나
00:38:16소프트웨어 엔지니어링이나 개발이 사라지지 않을 거라는 데는 동의합니다. 하지만 요즘 이런 경향이 있잖아요.
00:38:21코드를 검토조차 하지 않고 프로덕션에 배포하는 사람들이 점점 늘어나고 있다는 걸 봅니다.
00:38:26물론 이런 사람들은 트위터나 X에서 그냥
00:38:30자랑하는 사람들일 뿐이고 실제로는 아닐 거라고 확신합니다.
00:38:32하지만 다리오나 머스크 같은 AI 기업 운영자들 같은 사상적 리더들이 이런 말을 하기도 하죠.
00:38:39내년인 2027년이나 언제가 되면
00:38:41코드를 직접 보지 않고도 작성해서 배포할 수 있게 된다거나, 아니면
00:38:47프로그래밍 언어를 직접 쓰지 않고도 컴파일된 코드를 만들 수 있어서 프로그래밍 언어가 사장될 거라고요. 이에 대해 어떻게 생각하시나요?
00:38:54저는 그런 사상가들이 직접 당직을 서거나 장애 대응을 할 거라고는 도저히 생각지 않습니다.
00:38:58만약 그렇다면 전혀 다른 소리를 하고 있을 테니까요.
00:39:02말도 안 되죠.
00:39:04그들은 인프라를 담당하지도 않고, 정보보안 그룹에 있지도 않습니다.
00:39:08새로 도입되는 취약점 때문에
00:39:09비명을 지르거나 고객들이 화를 낼 때 발생하는 상황을 겪어본 적이 없으니까요. 물론 LLM이
00:39:13문법적으로 맞고 어느 정도 논리적인
00:39:16코드를 만들어낼 수는 있겠죠.
00:39:21하지만 그게 한
00:39:2320~30% 정도 맞을까요?
00:39:25그렇다 쳐도 말입니다.
00:39:29여전히 적절한 모니터링과 가시성 확보는
00:39:31필요할 겁니다.
00:39:37자티가 주장하듯 프로덕션 환경에서의 테스트를 원한다면 말입니다. 그럴 경우
00:39:42사전에 반드시 투자해야 하는
00:39:45영역이 존재합니다. 그녀의 관점에 따르면
00:39:48그건 바로 가시성과 소프트웨어의 동작 방식을 이해하는 것입니다. 하지만 설령 그렇다 해도 제가
00:39:54만약에
00:39:56정부 기관이고 소프트웨어를 구매해야 한다면
00:39:59그 소프트웨어는 보안 통제 기준을 반드시 충족해야 합니다.
00:40:03만약 제가 의료 회사이고 환자의 생명을 유지하는 데 직결되는 소프트웨어를 작성하고 있다면,
00:40:09검토도 없이 LLM이 그걸 생성하도록 내버려 두고 싶으신가요? 제정신으로는 할 수 없는 짓입니다.
00:40:15결국 다리나 고층 빌딩 예시로 돌아가는 거죠. 다리나 고층 빌딩을 LLM이 설계하게 만들고 싶으십니까?
00:40:21그냥 검토 없이 시멘트 붓고 철근 넣어서 완공하자고 하실 건가요? 절대 아니죠.
00:40:27아니요, 절대 그럴 수 없습니다.
00:40:31맞아요, 그 다리와 빌딩 비유는 정말 훌륭한 관점네요. 저도 그런 생각은 못 해 봤습니다.
00:40:37만약 당신이 엔지니어라면
00:40:39제로베이스부터 직접 지은 다리를 스스로 건너보고 싶으시겠어요?
00:40:43맞습니다. 바로 이 점을 생각해 봐야 합니다. 제가 커티스를 언급했었죠.
00:40:49이 에피소드 초반에도 말씀드렸지만 정말 좋아하는 친구입니다.
00:40:52그는 PE였는데요,
00:40:56전기공학 분야의 전문 기술사(PE)였습니다. 그 말은 학교를 졸업하고
00:41:02PE 시험을 치르고, 회사에서 수년간 인턴십을 거친 후, 엄청난 시험을 통과한 끝에야 비로소
00:41:09비로소 엔지니어링 프로젝트를 수행할 수 있었다는 뜻입니다. 업무를 수행하는 방식에는 아주 높은 수준의 규율이 존재합니다.
00:41:18말하자면
00:41:21의사들도 마찬가지죠.
00:41:23이론을 배우지만, 실제로 의료 행위를 하기 전에는 현장에서 수년간 감독을 받으며 수련을 거칩니다.
00:41:30다 이유가 있는 법입니다. 왜냐하면
00:41:33우리가 내리는 결정이 인간의 삶과 환경, 그리고
00:41:40세상에 엄청난 파장을 미치기 때문입니다. 그런데 소프트웨어 업계는 아직
00:41:44그 수준에 이르지 못했습니다.
00:41:47제가 꼭 그런 모델들을 그대로 모방해야 한다고 주장하는 건 아닙니다만,
00:41:52최소한 우리가 도입하고 있는
00:41:54위험을 직시해야 합니다. 인간의 삶에 영향을 미치는 무언가를 만들 때는 그에 걸맞은 규율을 갖춰야 합니다.
00:42:01위험에 대해 생각해야 하고, 부작용에 대해서도 고민해야 합니다. 책임을 져야 하죠.
00:42:05그런데 많은 조직들은 그런 이야기를 듣고 싶어 하지 않습니다.
00:42:08그것이 자신들의 빠른 발전 속도에 제동을 건다고 생각하기 때문입니다. 하지만
00:42:14우리가 왜 소프트웨어를 만들고 있나요?
00:42:16사람들의 문제를 해결하기 위해서입니다. 새로운 문제를 만들어내서는 안 됩니다.
00:42:23네, 그리고 친구분이신 PE(전문 기술사) 커티스에 대해 하신 말씀도 아주 흥미롭습니다. 커티스는...
00:42:31맞아요, 왜냐하면 캐나다에서는
00:42:33'엔지니어'라는 호칭을 쓰려면 실제로 자격증이 있어야 한다는 논의가 있었거든요.
00:42:40그래서 소프트웨어 엔지니어들은 그런 자격증을 취득한 적이 없으니 엔지니어라는 직함을 쓰면 안 된다는 논쟁도 있었고요.
00:42:48맞습니다.
00:42:51네, 정말 공감이 가는 부분입니다.
00:42:53네, 우리 업계와 그쪽 업계 사이에는 요구되는 규율의 수준이 완전히 다릅니다.
00:42:57정말 그렇습니다. 음, 그리고 본인 링크드인 프로필에 적어두신 문구에 대해 여쭤보고 싶은데요.
00:43:03'번아웃과 병목 현상에서 벗어나 신뢰할 수 있고 빠르게 움직이는 팀과 시스템으로'라고 쓰셨더라고요.
00:43:12그렇다면 번아웃에 대해 어떤 경험을 갖고 계신가요?
00:43:16아이구, 저한테는 번아웃 관련 경험이 아주 많습니다.
00:43:21빠르게 성장하는 조직에서 운영을 담당하다 보면
00:43:26틀림없이
00:43:28영웅주의에 빠진 사람들, 자신을 증명하고 싶어 하는 사람들, 그리고
00:43:35자원해서 나서서 모든 걸 떠맡아야만 한다는 강박을 느끼는 심리적 특성을 가진 사람들이 존재합니다.
00:43:39취약점인 셈이죠. 사기꾼 증후군 같은 거요.
00:43:45우리 모두가 가진 그런 성향이나 남을 만족시키려는 태도 같은 것들이 결국 번아웃을 유발할 수 있어요
00:43:52남들에게 증명하는 데 너무 몰두한 나머지 내 몸의 소리를 듣지 않고,
00:43:59자신의 몸에 귀를 기울이지 않고,
00:44:02감정 상태에 집중하지 않게 되죠. 내면을 돌아보지 않고 휴식을 위한 시간과 공간을 주지 않아요.
00:44:08휴식과의 관계가 망가져 있는 거예요. 예전에는 휴식이 나쁘다고 생각했던 시기도 있었어요.
00:44:14아무것도 하지 않는 것은
00:44:16시간 낭비라고 생각했죠. 하지만 지금
00:44:20인생의 이 시기에 와서 이런 생각을 많이 해보니, 휴식이야말로
00:44:25나중에 더 큰 도전을 해낼 수 있는 힘을 줍니다.
00:44:29보세요, 보디빌딩을 하는 사람들도 매일 체육관에 가서
00:44:35모든 근육 부위를 훈련하는 게 아니잖아요. 스스로에게 시간을 주죠.
00:44:40근육의 섬유를 다시 회복시킬 수 있도록 말이에요.
00:44:45그런데 왜 우리는
00:44:47음,
00:44:49마음에는 그렇게 할 수 없다고 말하는 걸까요?
00:44:51이게 바로 그 주제예요. 그런데 제가 기억하기로는
00:44:55메타를 떠난 후 저는 거대한 해고 물결 속의 0호 환자 같았어요.
00:45:01그래서 저도 해고 여파를 겪었죠. 그게 뭐였냐면… 아, 미안해요.
00:45:04아니에요, 제 말은, 그 일이 없었다면 쉬어모토는 존재하지 않았을 거란 뜻이에요. 알겠어요, 멋지죠.
00:45:08말하자면 잿더미에서 피어난 불사조 같은 거죠? 확실히 제 반응은 그랬어요.
00:45:13그것에 대한 제 반응은 그랬죠. 하지만 제 사업을 시작하고
00:45:18업계에서 한 발 물러서서 내가 어떻게 일하고 싶은지 고민하던 그 시기는 정말로
00:45:23제가 짊어지고 있으면서도 인정하지 않았던 번아웃을 아주 잘 자각하게 만들어 줬어요. 그리고 음,
00:45:32제 커리어 초기에 제가 까칠한 시스템 관리자였다는 게 기억나요. 혹시 아쿠아 출신이나 예전 아쿠아 직원이
00:45:38이 방송을 듣고 있다면 제가 무슨 말 하는지 알 거예요.
00:45:42전 정말 까칠했거든요.
00:45:44그리고 지금은 제 자신을 좀 돌아보는 작업을 거쳐서 아주 유쾌하지만요,
00:45:49그건 그냥 번아웃이었고 저는 그걸 몰랐던 거예요.
00:45:51그냥 너무 많은 사람들이 와서 나한테 요청을 해댄다고 생각했어요.
00:45:56스스로 알아서 해결해야 하는데 말이죠. 매뉴얼 좀 읽으라고요, 무슨 말인지 알죠?
00:45:59저는 정말 많은 번아웃을 겪었어요. 제 생각에 제 사업과 그 운영 방식은 제게
00:46:04공간을 줍니다
00:46:07이
00:46:08그런 난관에 정면으로 맞서고, 일과 더 건강한 방식으로 상호작용할 수 있는
00:46:13공간을 말이죠. 내 뇌가 작동하는 방식과 내가 삶에서 원하는 바에 더 부합하도록 말이에요.
00:46:20그 아시겠지만, 제가
00:46:23일하기 위해 사는 게 아니라, 일하고
00:46:25있는 거라는 점이에요. 삶을 채워줄 경험을 얻기 위해서요. 무슨 뜻인지 아시죠?
00:46:28이 얘기 들으니 어떠세요? 제가 좀 말을 이리저리 돌렸죠.
00:46:31아까 그 괴팍한
00:46:34시스템 관리자 이야기는 정말 공감이 가네요. 저 자신은 아니지만, 다녔던 회사들을 보면 항상 그런 사람이 있거든요.
00:46:40쿠버네티스를 다룰 줄 알거나 AWS에 대해 모르는 게 없는 사람이요. 그 사람한테 뭘 좀 부탁하려면
00:46:44엄청 귀찮아하면서 결국 해주긴 하는데 사실 하고 싶어 하진 않죠. 그래서 그 모습에 공감해요.
00:46:49하지만 왜 그런 일이 일어나고 어디서 비롯되는지 충분히 이해할 수 있어요. 워낙 자주 있는 일이기도 하고요.
00:46:56그래서 그 답답함도 충분히 공감합니다.
00:46:59그래서 말인데, 그런 상황에서 잠시 벗어나 자신을 돌아보고 다른 시도를 해보는 건 좋은 일 같아요.
00:47:05거기엔 분명 개인적인 책임감도 따르지만, 자신이 일하는 환경의 문화와
00:47:11팀 분위기, 그리고 함께 소통하는 사람들을 잘 살피는 것도 중요해요.
00:47:15자신에게 가장 잘 맞는 곳을 선택해야죠. 물론 요즘 채용 시장이 여전히 좀 유별나서
00:47:21그런 선택을 내리거나
00:47:22다른 곳으로 곧장 옮기겠다고 말하기가 어려울 수 있다는 점은 저도 잘 알고 있어요.
00:47:26그것도 충분히 이해하지만, 최소한 자신이 처한 환경을 의식하고
00:47:30자신의 감정과 몸의 신호에 귀를 기울이며 그에 맞춰 대처하는 것이 퍼즐의 중요한 조각이라고 생각해요.
00:47:36그리고 이런 분도 계세요.
00:47:39크리스티나 마슬라크 박사라고 있는데, 번진 인벤토리라는 걸 만들었죠.
00:47:44본인이 의료 분야에 계셨기 때문에 원래는 의료진을 위해 고안한 거였어요.
00:47:49하지만 그 번아웃 척도와 관련 연구들은 테크 업계에도 엄청나게 적용할 수 있거든요.
00:47:56그래서 그분의 강연들을 찾아보실 수도 있어요.
00:47:58제 기억엔 아마
00:48:01『피닉스 프로젝트』의 저자가 운영하는 연례 데브옵스 행에서도 강연을 하셨던 것 같아요.
00:48:06그래서
00:48:08네,
00:48:09저도 직접 겪어보기도 했고 번아웃의 임상적 측면에 대해 조금 읽어보기도 했거든요.
00:48:15네, 그리고 이번 해고가 결국 선생님께 좋은 기회로 이어져서 정말 다행이에요. 그 덕분에
00:48:24자신의 회사를 설립하게 되셨으니까요. 게시물들을 보니 정말 흥미로웠던 게, 뭐랄까
00:48:31기본적으로 회사를 운영하고 계신데
00:48:33말하자면 길 위에서 일하고 계신 거네요?
00:48:35계속 이동하시면서 유목민 같은 삶을 살고 계신 셈인데, 맞나요? 네, 맞습니다.
00:48:42네, 정말 유목민처럼 살고 있어요. 지금도 네바다주 한복판의 황무지에서 스타링크로 이 통화에 접속해 있죠.
00:48:50제 타코마 픽업트럭을 개조했는데,
00:48:54몰리라고 이름을 붙였어요. 제 픽업트럭을
00:48:59움직이는 전투 지휘소로 개조했습니다. 지금 트럭
00:49:02적재함에 서서
00:49:04통화 중인데요.
00:49:05안락한 침실과 300와트 태양광 패널,
00:49:09냉장고까지 직접 구축한 전력 시스템을 갖추고 있어요. 이 트럭을 하나의
00:49:16초소형 주택으로 만든 거죠. 네바다의 제 사유지부터 보스턴 어딘가의 AMC 영화관
00:49:23주차장까지 정말 어디서든 일합니다. 이런 생활을 한 지는 꽤 재미있게도
00:49:29이런 생활을 한 지
00:49:312년 반 정도 되었네요. 회사는 3년 전에 창업했고
00:49:34지난 2년 반 동안 유목민처럼 살아왔는데 제 인생 최고의 모험이자 경험이었어요.
00:49:41뭐랄까,
00:49:43산속에서 일하고 있는데 언젠가 곰이 제 트럭에 기어올라 온 적도 있어요.
00:49:46와, 정말요?
00:49:48네, 그때 기분이 어땠냐면요.
00:49:51좀 무서웠죠. 그땐 지금의 멋진 캠퍼가 아니라 루프탑 텐트에서 지내던 시절이었거든요.
00:49:54흑곰이었나요, 아니면 회색곰이었나요?
00:49:58글쎄요, 제가 이렇게 살아있다는 건 흑곰이었다는 뜻이겠죠. 하하.
00:50:02제가 본 흑곰 중에 가장 컸어요. 진짜 거대했죠.
00:50:06피크닉 바구니 같은 걸 찾고 있었나 봐요.
00:50:08그런데
00:50:09루프탑 텐트가 있는 베드 랙 위에서 제가 자고 있던 트럭 적재함 쪽으로 기어올라 와서 무게 중심이 쏠리더라고요.
00:50:17주머니에서 급하게 차 키를 꺼내서 경보기 버튼을 눌러야 했어요.
00:50:21경보기가 울리니까 곰이 황급히 도망치더라고요.
00:50:24맞아요, 그 일을 겪고 나니 이런 식의 폐쇄된 공간을 만들어야겠다고 절실히 느꼈죠. 적어도 곰이 저를 볼 수도 없고 들어올 수도 없으니까요.
00:50:30들어올 수도 없으니까요, 그러니까
00:50:33네바다랑 보스턴을 언급하셨는데, 트럭으로 매년 대륙횡단 여행을 하신 거네요. 네, 매년요.
00:50:42사실 한 달 뒤에 다시 동북부로 돌아갈 계획이에요. 지금 6x10 피트 화물 트레일러를 개조하고 있거든요.
00:50:48이 통화 끝나고 나면 구멍 뚫고 창문이랑 환풍기도 설치할 거예요.
00:50:521000와트짜리 태양광 패널도 설치하고 온갖 작업을 다 해서 제 이동식
00:50:58이동식 작전 상황실이자 날씨가 좋을 때 일할 수 있는 사무실로 만들 거예요.
00:51:02정말 멋지네요. 엔지니어분들이나 이런 거에 관심 있는 분들을 위해서,
00:51:08이런 이동식 주택을 직접 만드려면 비용이 얼마나 드나요?
00:51:13화물 트레일러 자체는 사실 꽤 경제적이에요. 4천~5천 달러면 살 수 있고, 그 다음에
00:51:20필요한 작업을 추가하면 비용이 올라가죠. 단열도 해야 하고
00:51:24당연히 환풍 시설이나 전력 설비도 넣어야 하니까요.
00:51:27이런 걸 하는 사람들이 세상에 정말 많아요.
00:51:31전 그중에서 유목민의 삶과 기술을 결합해서 해낸 몇 안 되는 사람일 뿐이죠.
00:51:36트럭은 '고 패스트(Go Fast)'라는 회사에서 나온 맞춤형 캠퍼가 장착된 타코마예요.
00:51:41이건 중고로 구했는데, 음
00:51:44네, 정말 본인 필요에 따라 달라요. 프리우스 안에서 멋지게 해내는 사람들도 있고
00:51:51더 정교한 차량을 타고 다니는 사람들도 있더라고요.
00:51:55차에 대해 조금 알고 직접 걷어붙이고 일할 의향이 있다면
00:52:01시작 비용은 꽤 낮출 수 있어요.
00:52:04그럼 이런 캠핑이랑 여행, 그리고
00:52:07차량 개조를 시작하게 된 계기가 뭔가요?
00:52:10차를 멋지게 꾸미는 거요.
00:52:11네, 음, 이 여정을 시작하기 전에는 딱 두 곳에서만 살았어요.
00:52:14평생 일만 하면서 기본적으로 남들이 하라는 대로 살았죠.
00:52:21젊은 남자에게 기대하는 거요. 대학 가고, 학위 따고, 좋은 직장 구해서
00:52:26열심히 올라가는 거요. 저도 그렇게 살았는데
00:52:28음
00:52:29그 뻔한 회사원의 길의 끝에 다다랐을 때 깨달았죠. '이봐, 내가 이렇게까지
00:52:34행복해야 하는 건가?' 엄청난 성취를 이루긴 했는데 마음이 허전했어요. 제 사업을 시작하고 나서 깨달았죠.
00:52:41'보스턴 대도시권에서 이 비싼 월세를 정말 계속 내야 할까?'
00:52:44보스턴에 안 살 거면 뭘 할 수 있을까 하다가, 어떤 사람이 유훌 트럭, 그러니까
00:52:51이삿짐 트럭을 가지고
00:52:53바퀴 달린 아파트로 개조한 유튜브 영상 을 보게 됐어요.
00:52:55'어?' 하고요.
00:52:58꽤 멋있더라고요.
00:53:00그래서 유튜브의 세계로 빠져들게 되었죠.
00:53:05알고 보니 이런 삶을 사는 커뮤니티가 꽤 많더라고요.
00:53:08그래서 열심히 찾아보고 유튜브도 잔뜩 본 다음에 결국 다 팔아치웠어요.
00:53:13그 아파트 계약도 갱신하지 않았고요.
00:53:16시빅을 타고 서쪽으로 운전해서 갔죠. 몇 달 뒤에 몰리를 구해서 세팅을 마치고
00:53:22시작하게 되었어요. 뭐랄까, 제게는 채워야 할
00:53:28인생 경험이 아주 많다는 걸 깨달았던 거죠.
00:53:31반어적이게도 기술 팟캐스트에 너무 많은 시간을 썼더라고요. 컴퓨터 앞에만 너무 오래 앉아 있고
00:53:37바깥세상에서는 시간을 너무 안 보냈던 거예요. 저를 균형 있게 만들어 줄 그런 경험이 필요하다는 걸 깨달았어요.
00:53:44저는 그냥 코드에 미친 개발자 그 이상이니까요. 저만의 색깔을 가진
00:53:49그런 한 사람의 인간이잖아요.
00:53:52경험도 쌓아야 하고요. 자연도 좀 만져야죠.
00:53:55바깥세상에 나와서 풀 말고도 엄청난 걸 만져봤죠. 바위라든가,
00:53:59알다시피 산이나 물 같은 온갖 것들이 있죠. 밖에는 만져볼 게 정말 많아요. 맞아요, 100%
00:54:04아까 곰 이야기하셨는데, 혹시 다른
00:54:08재미있는 모험은 또 없었나요?
00:54:12진짜 너무 많죠. 친구들과 콜로라도의 시나몬 패스를 다녀오기도 했어요. 오프로드인데 좀
00:54:18기술도 필요하고 난이도가 좀 있거든요. 와이오밍도 가고, 옐로스톤이랑 그랜드 티턴도 갔었죠.
00:54:24그 근처 공공 토지에서 캠핑도 했는데 거기서는 곰도 볼 수 있어요. 가끔은 제가 있는 곳 근처에서
00:54:30야생 당나귀 소리도 들려요. 며칠 전에는 야생마도 봤고요.
00:54:34걷는 소리가 들려서 텐트 창밖을 내다보면 말이 딱 서 있어요.
00:54:39어...
00:54:41아무튼 나라 전체를 꽤 여러 번 횡단했어요.
00:54:45어...
00:54:47정말 좋았어요. 저의 이런 미친 짓을 기꺼이 받아주는
00:54:51소중한 사람이 있어서 함께 모험을 떠나곤 하거든요.
00:54:54어, 네, 뭐 정말 재미있었어요. 제가 가본 미친 곳들에 대해서만 해도 에피소드 하나는 족히 나올 거예요.
00:55:01아, 그러네요.
00:55:03정말 멋지네요. 본인 팟캐스트에도 이와 관련된 에피소드가 있겠죠?
00:55:08네, 있어야죠. 보통은 게스트를 초대해서 그 주제로 이야기를 나누지만요,
00:55:15저 혼자 이 주제로 에피소드를 하나 만들어야 할까 봐요.
00:55:20네, 번아웃에 대한 생각과 교훈 같은 내용도 정말
00:55:25많은 엔지니어들에게 유용한 에피소드가 될 것 같아요. 특히 요즘 같은 때에요.
00:55:29AI가 우리를 더 생산적으로 만들어 주어서
00:55:33일하는 시간을 줄여줄 거라고 약속받았지만, 현실은 그 반대인 것 같거든요.
00:55:41때로는 이 도구들이 생기면서 처리해야 하는 방대한 양의 업무 때문에 오히려 번아웃이 오기도 하니까요.
00:55:50맞아요, 거기에 대한 제 생각은 아마 아주 파괴적이라고 여겨질지도 몰라요.
00:55:53그냥 이렇게만 해둘게요. 솔직히 말해서 우리에겐 더 많은 노동자가 필요해요.
00:55:58맞아요, 우리는 노동자입니다. 더 인간적인 근로 조건이 필요해요
00:56:03맞아요.
00:56:06네, 동의합니다.
00:56:08저희는 항상 게스트분들께 묻곤 합니다. SRE나 데브옵스,
00:56:14AI 혹은 기술과 관련된 날카로운 생각이 있으신가요? 네, 좋습니다. 자, 날카로운 의견을 말씀드릴게요.
00:56:22최고의 존중을 담아 말씀드리는 것이니 SRE라는 직무를 배타적으로 대하려는 의도는 아닙니다.
00:56:26하지만 이렇게 말씀드리고 싶네요. 본인의 SRE 역할이 있다면, 직함이
00:56:29SRE인데
00:56:32지금 구석에 앉아서 YAML 파일이나 작성하고
00:56:34호출(페이저)을 받고 있다면
00:56:37과연 그것이 진정한 SRE 역할인지 진지하게 자문해 보셨으면 좋겠어요.
00:56:40SRE는 신뢰성이 떨어지는 시스템을 신뢰할 수 있는 시스템으로 탈바꿈하고,
00:56:45SLO를 통해 고객을 만족시키는 실천 방식입니다.
00:56:47잡무 관리, 용량 계획 등 이 모든 고차원적인 운영 책임을 다하고
00:56:50소프트웨어 공학을 활용하는 것, 그것이 정말 중요합니다. 그것이 바로 SRE 실천입니다.
00:56:59그러므로 YAML은 프로그래밍 언어가 아닙니다. 만약 그것만 하고 있다면
00:57:01더 깊은 바다로 나아가 보시라고 권하고 싶어요. 거긴 아주 멋진 곳입니다.
00:57:06훌륭한 커뮤니티도 많고 여러분을 기꺼이 가르쳐 줄 사람들로 넘쳐나니까요.
00:57:11다만 여러분에게 도전이 되고 성장을 돕는
00:57:15역할을 찾고 있는지 꼭 확인하세요.
00:57:18'피닉스 프로젝트'라는 책이 데브옵스라는 단어를 대중적으로 만들었는데, 그 이후로 데브옵스 엔지니어라면서 하는 일이 뭐라고요?
00:57:26아까 말씀하신 것처럼 YAML 작성하기나
00:57:29쿠버네티스 철자 맞추기 같은 것들이죠. 책에서 말하던 데브옵스는
00:57:33그런 일을 하는 사람이 아니잖아요. 방금 설명하신 것처럼 서로 다른 두 가지를 연결하는 것에 가깝죠.
00:57:39시스템이 아니라 뭐라고 해야 할까요, 두 가지 전문 분야를 연결하는 거요.
00:57:43세상에 '저는 데브옵스 엔지니어입니다'라거나 '데브옵스를 배우고 있어요'라고 말하는 사람들이 많은 건 꽤 흔한 일 같아요.
00:57:48하지만 그런 게 아니라 방금 설명해주신
00:57:51그런 의미죠. 이제는 데브옵스 엔지니어라는 말이 너무 흔해져서 그 간극을 메우기가 어려워진 것 같아요.
00:57:56제가 설명한 그런 의미로 여겨지지도 않고요. 네, 이제 와서 되돌리기는 어렵겠죠?
00:58:02맞아요, 결국 의미와 이름에 관한 이야기니까요. 제가 '데브옵스'라고 말할 때는 제 뜻을 명확히 정의하려고 노력해야겠네요.
00:58:09네, 맞습니다.
00:58:10우리는 일련의 도구들에 대해 이야기하는 게 아닙니다. 특정 팀, 직함, 도구, 팀을 이야기하는 게 아니에요. 사람들은 늘 이에 대해 이야기하죠.
00:58:15아니요, 그게 아닙니다. 그것은 바로 기술, 사람, 리더십, 프로세스를
00:58:19하나로 결합하여 소프트웨어를 고객에게 최대한 빠르게 전달할 수 있도록 하는 실천 방식입니다.
00:58:27협력적이며 비즈니스에 최대한 도움이 되는 방식 말입니다. 제게 데브옵스란 그런 것이고, 거기에 도달하기 위한 수단은
00:58:34다양합니다.
00:58:35단순히 쿠버네티스만이 아닙니다. 쿠버네티스는 퍼즐 조각 중 하나일 뿐이에요. CI/CD만 있는 것도 아니죠.
00:58:40그것도 퍼즐의 일부입니다. 때로는 가만히 앉아서 사람들의 이야기를 경청하는 것이기도 하고, 비전과 전략을 구축하는 것에 대해 논하는 것이기도 하며,
00:58:47새벽 3시에 너무 자주 호출을 받은 팀원들에게 하루 휴가를 보내주는 것일 수도 있습니다.
00:58:52데브옵스는 그런 전체적인 관점에 대한 것입니다.
00:58:55단순히 도구들만이 아니죠. 도구들이 매력적이(섹시하)다는 건 이해합니다. 사람들은 도구를 팔고 싶어 하니까요.
00:59:01하지만 그건 전체 경험의 일면일 뿐입니다. 네, 도구 이야기가 나왔으니 말인데, 혹시 즐겨 사용하는 도구가 있으신가요?
00:59:08아이고, 글쎄요. 음, 생각해 볼게요. 네, 자원해서 하나 소개해 드릴게요.
00:59:14최근에
00:59:15GitHub에서 장애가 꽤 많이 발생했었죠.
00:59:20그래서 빌드 프로세스와 테스트 파이프라인이 내부에 있었으면 좋겠다는 생각을 하게 되었는데요,
00:59:26직접 호스팅(셀프 호스팅)하고 싶다면 대신 사용할 수 있는 '콩코스(Concourse)'라는 도구가 있습니다.
00:59:32콩코스라는 도구인데요.
00:59:35저는 콩코스를 좋아합니다. 아주 정교한 파이프라인을 구축할 수 있게 해주거든요.
00:59:38테스트, 빌드, 배송 등을 위해 YAML을 사용해 구축할 수 있으며, 각 작은 섹션은 컨테이너 안에서 실행됩니다.
00:59:47하지만 직접 호스팅을 해야 하죠. 제가 이 도구를 정말 좋아하는 이유는
00:59:50오픈소스 커뮤니티의
00:59:53거버넌스 모델이 독자적이기 때문입니다.
00:59:56라이선스를 갑자기 바꾸고 SaaS로 전환해 버릴 수 있는
01:00:01회사가 소유한 게 아니죠. 다른 프로젝트에서도 흔히 봐왔듯이 말이에요. 그래서 만약에 좀
01:00:06그 뭐랄까,
01:00:09CI/CD용 클라우드 서비스 쓰다가 지치셨다면 Concourse를 한번 써보세요. 온프레미스로 실행하는 거죠.
01:00:16철학적으로는 한 5년에서 10년 정도 퇴보한 것 같을 수도 있겠지만 더 안정적일지도 몰라요. 누가 알겠어요?
01:00:20멋지네요. 처음 들어보는 건데 한번 알아봐야겠어요.
01:00:23네, 저도요.
01:00:26네, 좋은 도구예요. 확실히 이 도구를 쓰는 기업들이 꽤 있거든요.
01:00:29그리고 친구한테 젠킨스를 쓰게 하면 안 됩니다. 이제 그건 끝났어요. 그러지 마세요, 정말 그러지 마세요.
01:00:35그럼 젠킨스가 죽었다는 말씀이신가요?
01:00:38제가 그런 말을 했던가요?
01:00:41아니요, 아니요. 그냥 넌지시 던져본 질문은 아니고요?
01:00:44하지만 제가 말하려는 건 더 많은 선택지들이 있다는 겁니다
01:00:47그리고 더 이상 Groovy 스크립트를 작성하고 싶어 하지도 않고요. 그래서 뭐,
01:00:51다른 기술들도 저한테 꽤 골칫거리였거든요.
01:00:54맞아요, 저도 쓸 때 그랬어요.
01:00:57네.
01:00:59아주 좋네요.
01:01:01혹시 홍보하고 싶으신 게 있으신가요? 팟캐스트를 운영 중이신데, 마무리하기 전에 더 이야기하고 싶은 부분이 있으신가요?
01:01:06그럼요, 그러죠. 늘 이런 기회에는 감사하고 있습니다. 네.
01:01:09저는 제 회사 '체르토모도(chertomodo)'에서 컨설턴트로 일하고 있습니다. 알파벳으로는 c-e-r-t-o-m-o-d-o.io입니다. 저는
01:01:18기업의 신뢰성, 데브옵스, SRE 태세를 진단하는 일을 전문으로 하고 있습니다. 만약 호출을 너무 많이 받고,
01:01:22배포를 자주 하지 못하며, 고객들이 화가 나 있다면
01:01:26제 캘린더에 일정을 꼭 잡아보세요. 저는 또한 '릴라이아빌리티 레벨스(Reliability Rebels)'라는 팟캐스트도 운영하고 있는데요,
01:01:31그곳에서는 다음과 같은 주제로 사람들을 인터뷰합니다.
01:01:33SRE가 단순히 도구 다루기에 그치지 않고 현상 유지에 도전하는 것인지에 대해서요.
01:01:38사회기술적 측면에 대해 이야기하고 있고요. 그리고 2월
01:01:4124일에는 다음과 관련한 웨비나를 진행합니다.
01:01:45바로
01:01:47AI 코드의 범람에 대한 내용인데요,
01:01:48'AI 코드 쓰나미'라고 이름 붙였던 것 같네요. 흥미로운 온갖 주제로 매달 웨비나를 진행하고 있습니다.
01:01:54관심 있으시다면 제 웹사이트를 확인해 보세요. 그 모든 것에 대해 알아보실 수 있습니다. 홍보할 기회를 주셔서 정말 감사합니다.
01:01:59천만에요. 감사합니다. 참여해 주셔서
01:02:03이 모든 흥미진진한 모험과 배운 교훈들에 대해 이야기해 주셔서 감사합니다. 모시게 되어 정말 즐거웠습니다.
01:02:09그럼 '베터 스택 팟캐스트' 이번 에피소드를 들어주신 모든 분께 감사드립니다.
01:02:13애플, 스포티파이, 유튜브 등 팟캐스트를 접하시는 플랫폼 어디서나 저희 방송을 구독해 주세요. 하지만 지금은
01:02:20작별 인사를 전합니다.
01:02:22저도 작별 인사를 드려요.
01:02:25저도 작별 인사드릴게요.
01:02:33(신나는 음악)