수석 엔지니어의 역할 정의

Clarke Rodgers(00:11):
Paul, 오늘 함께 해 주셔서 감사합니다.

Paul Vixie(00:13):
초대해 주셔서 감사합니다.

Clarke Rodgers(00:15):
괜찮으시다면 Paul의 배경에 대해 설명해 주시겠어요? Paul은 DNS 분야에서 인터넷의 발명에 기여한 저명한 혁신가이자 사고 리더이신데요, 이에 대해 자세히 설명해 주세요.

Paul Vixie(00:30):
제가 초기에 역할을 하긴 했지만, 그렇다고 앨 고어 같은 정도는 아니었고 제가 발명한 것도 아닙니다. DNS와 관련해서는 그냥 스스로 문제를 해결하려고 시작했어요. 저는 80년대 후반에 미니 컴퓨터 회사에서 일했는데 소프트웨어가 형편없었고 프로토콜에 대한 이해도 잘 되어 있지 않았습니다. 그래서 자기 방어 차원에서 하다 보니 계속 하게 되었고 이를 유지하기 위해 회사를 차렸어요. 그런 다음 그 회사를 그만두고 보안 분야의 스타트업을 창업했습니다.

그러던 중에 인터넷 명예의 전당에 이름이 오르게 되었고, 일본 게이오 대학에서 박사 학위를 취득했습니다. 이 모든 것이 1980년에 고등학교를 중퇴하고 시작된 것이니 일이 신기하게 흘러간 거죠.

Clarke Rodgers(01:18):
대단하시네요. 그 얘기를 조금 더 해보죠. 고등학교를 중퇴하고 기술 분야로 옮기게 된 계기는 무엇이었나요?

Paul Vixie(01:28):
당시 저는 미니 컴퓨터 분야에서 일종의 아르바이트를 했어요. 그런데 진학 상담사 선생님이 "너 내년에 다시 3학년을 다녀야 해"라고 말을 했죠. 왜냐하면 저는 항상 컴퓨터실에만 있었거든요.

Clarke Rodgers(01:43):
대단하시네요.

Paul Vixie(01:44):
그래서 상황이 나아지지 않을 것 같아서, 그냥 그만둬야겠다고 생각했어요. 이후에는 나이 때문에 어쩔 수 없이 학교를 그만두게 되었어요. 저는 가난한 학생이었고 프로그래밍을 하느라 너무 많은 시간을 보냈었거든요.

Clarke Rodgers(02:00):
결국에는 잘된 일이네요.

Paul Vixie(02:03):
특이한 결정이긴 했지만 그렇게 결정한 것에 대해 만족해요.

Clarke Rodgers(02:08):
괜찮으시다면 AWS에서의 역할에 대해 조금만 말씀해 주세요.

Paul Vixie(02:13):
저는 두 가지 역할을 맡고 있습니다. 어쩌면 세 가지일지도 모르겠네요. 저는 수석 엔지니어 겸 부사장으로 채용되었는데, 이는 매우 경험이 많은 소수의 사람들로 구성된 그룹입니다. 그래서 매우 자기 주도적인 역할이에요. 수석 엔지니어 겸 부사장의 직무는 문제를 발견하고 그 문제에 뛰어드는 것입니다. 누군가 "Paul, 어떤 일을 해주셔야겠는데요"라고 말하는 경우는 매우 드뭅니다. 설립한 지 25년이나 지났고 특히 회사의 성장 과정을 알지 못하는 사람이 이 정도 규모의 회사에서 이렇게 자율적으로 일하게 된 것은 큰 영광이죠. 정말 대단한 일이었죠.

지난 여름에 저는 AWS의 정보 보안 부책임자로 임명되었고, 어쩌다 보니 CISO실을 이끌게 되었습니다. CISO실은 임원급 솔루션 아키텍트라고 생각하시면 됩니다. 고객과의 대화에 임원이 참석할 경우 보통 CISO를 그 자리에 앉히고 싶어합니다. 문제는 CISO는 한 명뿐이고 참석해야 할 자리가 많기 때문에, 우리는 CISO를 위한 백업 밴드와 같은 역할을 합니다. 그리고 이 분야의 최고 전문가로 구성된 6명이 이 직무를 맡고 있습니다. 그리고 다른 동료들과 협력하며 고객 연락 업무를 수행하고 있습니다. 바로 그러한 이유로 제가 팀을 이끌게 된 것 같습니다.

Clarke Rodgers(03:44):
AWS에 매력을 느낀 계기가 있으신가요?

Paul Vixie(03:47):
직무에 대한 설명이었어요. 다시 말씀드리자면, 만약 제가 이곳에 와서 부사장이 되어 특정 직무를 담당하라는 요청을 받았다면 "예, 해봤던 일이네요."라고 대답했을 것입니다. 하지만 이 직무는 기본적으로 기술 직책이고, 적어도 제 업무 중 수석 엔지니어 업무는 기본적으로 임원급 개인 기여자 직책입니다. 그것이 흥미로웠던 이유를 설명하자면, 제 직함에 “엔지니어”라는 단어가 마지막으로 들어간 것은 제가 아닌 다른 사람이 저에게 채용 확약서를 썼을 때가 마지막이었고, 그 엔지니어 일은 1993년에 그만두었습니다. 저는 스타트업의 CEO로 일해왔고, 코딩을 하는 CEO였을 뿐 전문 엔지니어는 아니었습니다. 제가 차린 회사 중에 어떤 회사에서도 그것은 저의 주 업무가 아니었죠.

그래서 스타트업을 창립하지 않았다면 가게 되었을 원래의 길로 돌아가 도움을 주는 개인 엔지니어가 된다는 것은 기분 좋은 일이었습니다. 제가 지금이라도 그것을 할 수 있을 것이라고는 생각하지 못했습니다. 회사에서 저를 설득해야 했죠. 하지만 그 직책에 대한 설명을 듣는 순간 제 머릿속에서 "그래, 내가 정말 그 자리로 돌아가고 싶어하는구나"라는 생각이 들더군요. 저는 몰랐어요. 저는 인터넷과 보안 업계에서 약간의 인지도가 있을 뿐이었고 다소 논란을 불러일으키는 사람으로 알려져 있었기 때문에 제가 채용될 수 있을 것이라고는 전혀 생각하지 못했어요. 그래서 저는 제가 이 직무를 맡기에는 너무 논란의 여지가 많다고 생각했어요. 하지만 회사는 다르게 생각했습니다. 지금까지는 회사가 옳았어요.

Clarke Rodgers(05:22):
입사하신 지 좀 오래 되셨네요. 여기저기 둘러보셨겠군요. AWS의 보안 문화에 대해 구체적으로 어떤 인상을 받으셨나요?

Paul Vixie(05:32):
저는 창업했던 여러 스타트업 회사를 AWS와 같은 회사에 매각을 했어요. 기업 거버넌스는 모든 회사에서 거의 동일하지만, AWS가 다른 점은 보안팀이 생긴 지 매우 오래되었고 그만큼 보안이 0순위라는 주장이 결코 말뿐인 주장이 아닌 정당한 주장이라는 것입니다. 이는 조직도와 운영 계획, 예산의 우선순위 전체에 철저하게 반영되어 있습니다.

즉, 모든 기업이 고객을 위해 존재하는 것처럼 우리도 고객을 위해 존재합니다. 다른 점은 AWS는 고객의 보안에 해가 되는 일을 하지 않는다는 것입니다. 우리는 보안을 절대 가볍게 생각하지 않습니다. 이것이 바로 AWS가 다른 점입니다.

Clarke Rodgers(06:20):
예를 들어, 수석 엔지니어 역할을 수행하면서 서비스 팀과 자세하게 논의하다 보면 기능 릴리스와 보안 수정 중에 무얼 선택해야 할지를 놓고 갈등이 생기기도 하나요? 아니면 그냥 "아니요, 보안 수정을 꼭 해야 합니다"라고만 하나요? 이러한 논의는 어떤 식으로 이루어지나요?

Paul Vixie(06:42):
우리는 "이런, 애플리케이션 보안 테스트 결과 등을 이유로 이 출시를 막으면 너무 늦어질 거예요. 출시 시기를 놓치게 될 것이고, 이 일은 이미 진행 중이에요."라는 식의 불만은 들어본 적이 없습니다. 그런 일은 일어나지 않아요. 그런 일이 없도록 의도적으로 확실히 하고 있어요. 가끔은 정말 "해야 하는 일"이지만 "반드시 해야 하는 일"이 아닌 경우에는, 저나 AWS 보안 담당자가 "이것 때문에 문제가 생길 거고 나중에 고치는 데 훨씬 더 많은 비용이 들 거예요"라고 말할 때가 있습니다. AWS 서비스 팀이 갖는 자율성은 이 정도입니다.

서비스 팀이 무엇이 중요한지를 결정할 수 있지만, 보안 문제가 발생하면 우리가 그 문제에 대해 이야기한 것이 기록으로 남는다는 사실을 알고 있습니다. 그들이 해명해야 할 것이 생기는 거죠. 네, 그래서 갈등이 생길 때도 있어요. 누구나 상사가 있고 상사가 어느 날짜까지 이걸 해내야 한다고 하면 그 날짜에 맞춰 끝내야 하고 이런 것에 민감하니까요. 우리는 무언가를 망치고 싶지 않습니다. 하지만 우리와 함께 일하는 사람들에겐 지표를 달성하는 것이 최우선 목표이고, 우리는 두 번째 목표라는 것을 잘 알고 있습니다.

Clarke Rodgers(08:09):
이제 이야기를 바꿔 보겠습니다. CISO실을 이끄시면서 고객에게 많이 노출되고 대면 방식이든 가상 방식이든 전 세계의 고객과 소통을 하실 텐데요. AWS에서 참여하신 모임 중 하나가 AWS CISO 서클인데, 이에 대한 소개와 참여 경험을 공유해 주시겠어요?

Paul Vixie(08:30):
제가 CISO 서클에 대해 처음 들은 것은 “혹시 어디 좀 갈 수 있냐...” 이 경우는 마드리드였는데요. “가서 CISO 서클에 참가할 수 있냐”는 질문을 받았던 때였습니다. 그래서 저는 "그게 뭔가요, 제가 어떤 식으로 참여하는 건가요?"라고 대답할 수 밖에 없었습니다. 당시 저는 이곳에 온 지 1년밖에 되지 않았거든요. 우리가 누구이고 어떻게 여기까지 왔는지에 대해 저보다 더 전문성을 갖춘 사람이 필요하지 않을까 생각했어요. 어쨌든 제가 참석하게 되었고, 특정 산업 분야의 CISO들이 한자리에 모여 있었기 때문에 정말 대단했습니다. 그리고 모든 것에 약간의 기밀유지협약이 적용되었기 때문에 자유롭게 이야기할 수 있었어요. 다른 사람들이 제가 말한 내용을 발설하지 않을 테니까요.

Clarke Rodgers(09:20):
채텀 하우스 규칙이죠.

Paul Vixie(09:21):
채텀 하우스 규칙을 따랐고, 이들은 경우에 따라 경쟁자입니다. 이들은 같은 업계에 있거나 같은 지역에 있는 회사의 CISO들인데, 보통은 아이디어나 경험을 공유하지 않죠. 하지만 그러한 분들이 우리가 마련한 장소에 모였고 우리는 그 자리에 있었기 때문에 우리는 토론을 중재하고 다양한 기술에 대한 프레젠테이션으로 토론의 씨앗을 뿌린 다음 토론을 장려하고 이의를 제기하도록 장려했으며 궁극적으로 서로 논쟁을 하도록 장려했습니다.

중대형 기업이 할 수 있는 일 중 하나는 경쟁사의 경험을 통해 이익을 얻는 것이기 때문에 그 모습은 정말 아름다웠습니다. 그리고 우리는 누구의 보안이 더 강력한지를 기준으로 경쟁해서는 안 됩니다. 왜냐하면 우리는 같은 업계에 종사하고 있고 상대가 보안 침해를 당한다면 그것은 저에게도 타격이 되고, 다음 차례는 제가 될 수도 있기 때문입니다. 그렇기 때문에 이런 방식으로...

Clarke Rodgers(10:24):
정보와 모범 사례를 공유하면서 말이죠...

Paul Vixie(10:26):
맞아요. 우리는 어떤 분야에서는 경쟁하지만 또 다른 분야에서는 힘을 합쳐야 합니다. 그리고 이들은 서로를 알아가고 회사의 비밀을 노출하지 않으면서 얼마나 더 신뢰할 수 있는지 등에 대해 알게 되었습니다. 그리고 그 의도는 행사가 끝난 후에도 서로 연락을 유지하는 것이었습니다. 물론 그러다 보면 당연히 "그날 클라우드의 어떤 API 때문에 너무 힘들었다"고 말하는 사람도 있고, "잘 작동한다"고 말하는 사람도 있을 겁니다. 결국 이들이 서로에게 AWS에 대해 불평하게 된다면 그 또한 받아들여야 하겠지요.

무엇이 잘못되고 있는지 알지 못하면 고객에게 더 나은 서비스를 제공할 수 없습니다. 그래서 이는 우리에게 비즈니스 인텔리전스의 큰 원천이 되고 있습니다. "아, 이런 게 있으면 좋을 텐데..."라고 말을 하다가도 "그런 거 실제로 있어요."라고 말하게 되는 경우도 있습니다. 우리는 매우 큰 회사이고 많은 혁신을 하고 있으며, 어떤 고객도 따라잡을 수 없는 속도로 새로운 기능이나 신기술을 개발하고 있습니다. 제 말은, 그렇게 하는 것이 제 업무인데 그것을 계속 제대로 해내기가 어렵다는 말입니다.

따라서 고객의 문제가 무엇인지, 업계의 문제가 무엇인지, 고객이 무엇을 어떻게 하고 있는지, 고객의 불만 사항이 무엇인지 아는 사람이 있는 고객과의 접점이 있어야 합니다. 알고 보니 우리에게 그러한 업무를 수행하는 직원들이 있지만, 고객이 이들을 정기적으로 시간을 내서 만나야 한다는 사실을 모르고 있었던 것이었습니다. CISO 서클이 그런 일을 하는 데 도움이 된다면, 하나둘씩 입소문을 타고 확산되어 하나의 운동이 되었으면 좋겠습니다.

Clarke Rodgers(11:59):
훌륭합니다. Paul, 오늘 함께 해 주셔서 감사합니다.

Paul Vixie(12:02):
좋은 시간이었습니다. 초대해 주셔서 다시 한 번 감사드립니다.