활발한 멘토이자 시스템 자동화 전문가

Jonathan: 안녕하세요, 여러분. Exercism 커뮤니티 팟캐스트에 오신 것을 환영해요. 오늘은 저희 메인테이너이자 기여자인 Isaac과 함께하게 되어 영광이에요. Isaac은 최근에 GoHort, 그러니까 저희가 30일 동안 운영한 학습 코호트에서 많은 학생을 멘토링해 줬어요. 지금까지 두 번 했고, 특히 Go와 Elixir로 진행했죠. Isaac은 Go 트랙도 도와줬는데 정말 멋졌어요. Isaac, 정말 반가워요. 어디에 있는지, 어디서 왔는지, 그리고 어떻게 기술 분야에 들어오게 됐는지 조금 이야기해 줄래요? Isaac: 네, 저는 캘리포니아에 있어요. 캘리포니아 산호세에 살아요. 솔직히 말하면, 형이 기술 쪽에 빠져 있었고 저는 형이 하는 건 뭐든 따라 했기 때문에 기술 분야에 들어오게 됐어요. 저는 형제자매가 많았어요. 서로 어울려 놀기를 좋아했는데, 어떤 사이는 더 가깝고 어떤 사이는 덜 가깝기도 했죠. 저는 특히 같이 놀고 싶은 형이 한 명 있었어요. 형은 저랑 노는 걸 그렇게 좋아하진 않았지만, 저는 형 뒤를 쫓아다니면서 형이 하는 일이면 뭐든 같이 하고 싶어 했어요. 형이 15살쯤에 집에 굴러다니던 《C for Dummies》 책을 집어 들었는데, 제가 기억하기로는 그때 제가 9살이었어요. 그래서 형이 C로 코딩을 하니까 저는 형이 하면 나도 해야지 하는 마음이었죠. 그 나이에 제 프로그램은 아주 단순하고 기초적이었어요. 이름이 뭐예요, 안녕 Bob 같은 연습 문제 수준이었죠. 그렇게 복잡하진 않았어요. 어디서든 시작은 해야죠. 거기서 시작한 거예요. 터미널에 문자를 하나 출력하면 소리가 난다는 걸 보고, 와, 멋지다 싶었어요. 말 그대로 슬래시 A만 출력하는 프로그램을 썼죠. 그렇게 9살에 시작해서 C 프로그램을 쓰고 있었어요. 집에는 DOS로 부팅되는 오래된 Windows 3.1 컴퓨터가 있었는데, 형이 배치 스크립트를 짜 놔서 컴퓨터가 부팅될 때 Windows 실행, 게임 실행 같은 걸 고를 수 있는 메뉴가 떴어요. 게임 메뉴 같은 것도 있었죠. Warcraft를 하려면 5번을 누르는 식이었어요. 그래서 다른 게임들을 설치하면서 배치 스크립트도 쓰고 그랬어요. 그 뒤로는 쭉 그렇게 이어졌죠. 형은 대학에 컴퓨터 공학을 전공하러 갔고, 또 저는 형이 하면 나도 해야지 하는 마음이었어요. 그래서 9살에 C를 쓰기 시작했어요. 고등학교 때는 Visual Basic 6를 쓰고 있었고요. 고등학교 때 팜 파일럿을 가지고 여기저기 프로그램을 짜기도 했어요. 저희 수학 선생님은 정말 멋진 분이었어요. 그때가 그 옛날 방식의… Jonathan: 그게 그러니까, 아이패드가 나오기 전에 나왔던 그거 있잖아요, 몇 사람만 써 봤던, 작은 펜으로 끄적이는 기능이 있던 거요. 다들 끝에서 튀어나오는 게 신기해서 엄청 멋지다고 했잖아요. 살짝 밀어 넣었다가 화면을 톡톡 두드릴 수 있었고요. 그러고 나서 아이패드가 나왔을 때 다들 아, 조금 일렀구나 싶었던 게 기억나요. 팜 파일럿은 그만큼 한발 앞서 있었던 거죠. 무슨 말인지 아시겠어요? Isaac: 10년 정도는 아주 잘 쓰였어요. 팜 그래피티라는 입력 방식이 있었는데, 작은 입력 패드에 글자를 써 넣어야 했어요. 알파벳을 본뜬 모양이라서 A는 삼각형, F는 직각 같은 식이었죠. 아무튼 고등학교 수학 선생님이, 프로그램을 직접 짰으면 시험에서 써도 괜찮다고 했어요. 그래서 고등학교 때 팜 파일럿 프로그램을 짰는데 정말 재미있었어요. 대학에서는 컴퓨터 공학을 전공했어요. 사람들이 스크립트 언어 얘기를 하길래 그게 뭔지 잘 몰라서 그냥 아무렇게나 Perl을 집어 들었어요. 그리고 대학원을 졸업하고 Google에 입사했죠. 2013년에는 회사가 저를 동부에서 캘리포니아로 옮겨 줬어요. 그때쯤 Python을 접했는데, 벌써 10년 전 일이네요. 지난 10년 동안 Python이 제 주 언어였어요. Google에서 일했기 때문에 제 스타일은 Google 스타일의 영향을 많이 받았고, 그래서 주로 그렇게 코드를 써 왔어요. 그러다 4년 전쯤, 2018년쯤이었나, Google이 내부에서 Go 언어를 밀기 시작해서 그때 Go를 배웠어요. Jonathan: 멋지네요. Isaac, 아까 Google 스타일 얘기를 했잖아요. 이게 이렇게 하는 게 맞다 하는 정해진 감각이 있는 건가요, 아니면 좀 다른 건가요? 조금 더 풀어서 얘기해 줄래요. 흥미로운 부분이라서요. Isaac: 코딩 스타일은 꼭 이게 옳은 방식이라기보다는, 모두가 따라야 하는 하나의 통일된 방식에 가까워요. 좋은 타협이나 좋은 거래는 아무도 만족하지 못하는 거래라고들 하잖아요. 스타일 가이드에 완전히 만족하는 사람은 없어요. 그래도 모두가 그걸 따르기만 하면 코드가 한결같아 보여요. 그러면 누구든 Google 코드베이스 안의 아무 코드나 집어서 고칠 수 있죠. 같은 스타일 가이드만 따르면 코드가 전부 통일되어 있으니까, 아, 이 코드베이스는 네 칸 들여쓰기를 쓰고 저건 두 칸을 쓰네, 하는 걸 신경 쓸 필요가 없어요. 네이밍 규칙이 이렇네 저렇네 할 필요도 없고요. 코드베이스 전체가 같은 방식으로 되어 있어요. 어느 부분이든 모두가 만족하는 건 없죠. 누구나 자기 방식대로 바뀌었으면 하는 부분이 있어요. 그래도 공개된 스타일 가이드가 문서로 있고, Google Python 스타일 가이드로 검색하면 Google에서는 이렇게 코드를 쓴다고 알려 줘요. 모두가 그 가이드만 지키면 코드가 아주 통일되어 보여요. 아무 코드베이스나 열어도, 아, 여기는 저렇게 쓰겠지, 하는 의외의 상황이 없다는 게 정말 좋아요. Jonathan: 그래서 Go가 그런 맥락에 잘 어울리는 건가요? 포맷이 정해져 있고, 이게 바로 정답이라는 느낌이잖아요. Go에는 Google의 영향이 확실히 보여요. Isaac: 네, Rob Pike가 Google 방식에 얼마나 영향을 받았는지, 아니면 그가 Google 방식에 얼마나 영향을 줬는지는 저도 잘 몰라요. 어느 쪽이 먼저였는지는 확실하지 않지만, Go는 그걸 확실히 한 단계 더 밀어붙였어요. Python을 보면 스타일이 여러 가지라서 사람마다 린터를 손봐서 서로 다른 걸 받아들이게 하잖아요. 예를 들어 Google 내부에서는 Python에 두 칸 들여쓰기를 쓰는데, 깊이 중첩된 코드가 많아서 공백이 잔뜩 늘어선 벽 같은 걸 만들고 싶지 않기 때문이에요. 외부에서는 대부분 네 칸을 쓰고, 그게 Python 문서에도 적혀 있고요. 그런데 Go는 그걸 한 단계 더 밀어붙여서 언어 자체에 포맷터가 들어 있어요. 포맷하는 방법은 딱 하나뿐이에요. 어떤 게 맞는 방식인지 두고 온라인에서 논쟁할 게 없어요. 방법은 하나뿐이에요. Jonathan: 서로 왔다 갔다 하는 논쟁을 엄청 줄여 주죠. 그렇게 말하는 게 좋겠네요. 네, 좋아요. Isaac: 네. Jonathan: 그럼 Google에 입사했을 때 Python은 아예 해본 적이 없었나요, 아니면 조금 해봤나요, 아니면 넘어가기 쉬웠나요? 아까 얘기를 들으면 Google에 취직하고 나서 자, 좋아, Python 배워 봅시다, 하는 느낌이었잖아요. Isaac: 맞아요. Google에 오기 전에는 Python을 한 번도 써 본 적이 없었던 것 같아요. 그때는 Perl을 한두 해쯤 쓰고 있었어요. 아마 그 무렵에 Perl을 쓰기 시작했을 거예요. 첫 여름 아르바이트 때였는데, 그건 또 다른 얘기고요. Google에 오기 6년 전부터 Perl을 썼으니까 그때는 Perl을 꽤 썼죠. Bash도 조금 썼어서 스크립트 언어에는 익숙했어요. 그래도 Python은 한 번도 써 본 적이 없었어요. 그런데 언어를 여러 개 다뤄 보면 새로운 언어를 배우는 학습 곡선이 조금 완만해져요. 대부분의 구조를 이미 봤고 문법만 조금 다르고 도구만 조금 다르니까요. 그러니까 거의 비슷한데 조금 다르게 쓰는 정도예요. 구조는 대체로 비슷해요. 그래서 네 개 언어를 익히고 나면 다섯 번째는, 아, 이건 그냥 조금 다르게 쓰는 거구나, 하는 수준이죠. Jonathan: 네, 네. 흥미롭네요. 아까 고등학교 때 첫 아르바이트 얘기에 웃었는데요. 그럼 그때부터 계속 엔지니어링 쪽, 그러니까 컴퓨터 일을 하겠다는 생각이었나요? 그게 늘 의식적인 생각이었나요, 아니면 그냥 자연스럽게 맞는 자리이고 재미있어서 했던 건가요? 어떻게… Isaac: 그런 것 같아요. 저는 형의 발자취를 따라가려고 했어요. 형은 컴퓨터 공학을 갔고, 프로그래밍을 쓰기 시작했어요. 제가 어릴 때 형이 프로그래밍을 시작했는데 저도 따라 했죠. 어릴 때부터 프로그램을 써 왔어요. 형이 컴퓨터 공학을 갔고, 저도 형이 하는 것과 똑같은 걸 하고 싶었고, 또 프로그래밍하는 게 정말 재미있었어요. 그래서 고등학교에 들어갈 때부터, 형은 이미 대학에 다니고 있었는데, 저는 제가 어디까지 가고 싶은지 알고 있었어요. Jonathan: 형이 몇 살 위니까, 형이 사람으로서 아주 큰 영향을 줬다는 느낌이에요. 다른 형제자매는 몇 명이나 있어요? 아니면 그냥 형이 눈에 최고로 멋져 보였던 건가요? Isaac: 형제자매가 여덟 명 있어요. 그중에서도 형이랑은 정말 잘 맞았어요. 여덟 명이면 어느 정도 편차가 있기 마련이죠. 형이랑은 아주 잘 지냈어요. 생각하는 방식도 비슷하고 관심사도 비슷해요. 우리는 늘 컴퓨터 얘기로 신나게 떠들었고, 지금도 그래요. 형수님은 그 얘기가 저녁 식탁 대화로 이어지는 걸 싫어해요. 식탁에서는 일 얘기 하지 말라고 하시죠. 우리는 그냥 늘 프로그래밍 얘기로 신나 하고, 그 얘기만 해요. 그게 형을 따라 하고 싶었던 건지, 그냥 관심사가 비슷했던 건지 따지기는 어려워요. 지금은 관심사가 확실히 비슷하고요. 그게 타고난 건지 자라면서 된 건지는 모르겠어요. 제가 형을 따라 한 건지 그냥 관심사가 비슷했던 건지에 대해선 뭐라 하기 어렵네요. 다만 어릴 때부터 형의 발자취를 따라갔으니까, 형이 어느 정도 길을 닦으면 제가 그 길을 따라간 셈이죠. Jonathan: 네, 정말 멋지네요. 그런데 형은 지금 어디에 있어요? 궁금해서 그러는데, 아직 동부에 있나요? Isaac: 아직 동부에 있어요. 기술 분야에서 일하고 있고요. 잠깐 같은 회사에서 일한 적도 있어요. Jonathan: 네, 좋아요. 궁금해서 물어봤어요. 그런데 최근에 진행한 코호트에서 정말 열심히 활동했잖아요. 가장 최근 학습 코호트, 특히 Go로 30일 동안 진행한 거요. 그리고 그전에 Exercism에서의 활동은 주로 메인테이닝이었는데, 제가 알기로는 멘토링도 꽤 많이 했고요. 그 둘을 나눠서 해 보니 어땠어요? 그러니까, Exercism은 어떻게 알게 됐고, 어떤 부분을 기여하는 게 재미있어요? Isaac: 처음 Exercism을 알게 된 건 Haskell을 다시 배워 보려다가였어요. Google에서 Haskell 101 수업을 들었는데 꽤 재미있었거든요. 그래서 아, 이걸 좀 더 해 봐야겠다 싶었는데 그러다 흐지부지됐고, 다시 해 볼까 하던 참이었어요. Jonathan: 그럼 다음에 또 뵐게요. Isaac: 어떤 언어든 가장 빨리 배우는 방법은 직접 그 언어로 코드를 써 보는 거예요. 가장 빨리 쓰는 방법은 쓸 목적을 갖는 거고요. 저는 Haskell을 쓸 만한 좋은 목적을 못 찾아서 익히기가 정말 어려웠어요. 그런데 Exercism을 알게 되고, 아, 이걸 하면 Haskell을 더 쓸 수 있겠다 싶었죠. 그게 제가 Exercism을 처음 알게 된 계기예요. 들어가 보니 Python 트랙도 있고 셸 트랙도 있고, 이런저런 연습 문제도 있더라고요. 그래서 그대로 토끼굴로 빠져들었죠. Jonathan: 그리고 토끼굴로 푹 빠져든 거죠. Isaac: 네. Python으로 연습 문제를 풀기 시작했고, Bash로도 문제를 풀기 시작했어요. Go 문제도 몇 개 풀었고요. GoHort가 열렸을 때 예전에 제출한 답안들을 훑어봤는데, 상당수가 3년 전에 제출한 거였어요. 저는 2019년에 처음 Go 트랙에 가입해서 그때 문제를 꽤 많이 풀었거든요. 그리고 그 시점에 Python은 10년째 하고 있었으니, Python 멘토로 참여하는 게 비교적 편했어요. 요즘도 연습 문제에 쓰는 시간은 대부분 거기서 보내고요. 그러다 Python 트랙에 뭔가 어긋난 것들이 있어서 PR, 그러니까 풀 리퀘스트를 보내기 시작했어요. 그다음에는 Bash 트랙에도 관여하게 됐고요. 어떻게 그렇게 됐는지는 저도 잘 모르지만, Bash 트랙에 수정 사항을 보내는 사람에서 Bash 메인테이너가 됐어요. Jonathan: 그야말로 순식간에요. 그러니까, 뭘 신청하는지 조심해야 한다는 거죠? Isaac: 네, 그러다가 Glenn이 Ock 트랙을 만들었는데, 저는 아, 나도 Ock을 알고 Ock을 좋아하니까 나도 끼어야겠다 싶었어요. 그래서 Ock 트랙의 연습 문제를 만드는 걸 도왔어요. 확실하진 않은데, 3년 전쯤 Go 문제를 보다가 트랙 전체를 다 풀었던 것 같아요. 그러자 멘토 한 분이 연습 문제를 다 끝냈으니 멘토가 되어 보는 게 어떻겠냐고 했어요. 저는 Go를 자주, 규칙적으로 쓰지 않아서 멘토링할 만큼 편하지는 않았어요. 그래서 사실 Go 멘토는 아니었죠. 그런데 GoHort에 참여했더니 멘토링을 받고 싶어 하는 사람들이 많아서, 아, 이번 달만 멘토로 신청해서 도와줄 수도 있겠다 싶었어요. 그런데 사실 최근에는 학생으로 GoHort에 참여했어요. 그러다 이제 학생 섹션에서 옆으로 옮겨 가려고요. Jonathan: 학생 섹션에서 옆으로 옮겨 간 거군요. 뭘 신청하는지 조심해야겠네요. 한 가지를 신청했다가 다른 게 되어 버리는 패턴이 생기는 것 같아요. 그래도 정말 멋진 일이죠. 그럼 특히 Go 트랙에서 학생들을 멘토링할 때 가장 흔하게 보이는 게 뭐예요? Go 트랙에는 아마 개발 경력이 어느 정도 있는 분들도 꽤 많았을 텐데, 사람들이 자주 막히는 지점 같은 게 눈에 띄었나요? 어떤 패턴이나, 아, 이건 흔하고 꾸준히 나오는구나 하는 게 있었나요? Isaac: 글쎄요. 제가 봐 온 멘토링은 대부분 완성된 답안에 대한 거였어요. 사람들은 멘토링을 받으러 오기 전에 이미 문제를 푼 경우가 더 많아요. 그래서 제가 나눈 대화 대부분은 사람들이 막혀서가 아니었어요. 대개는 문제를 성공적으로 끝내고 나서, 더 효율적인 방법이 있는지, 더 나은 알고리즘이 있는지 묻는 경우가 많았죠. 너무 자주 나오는 것 중 하나는 문자열 만들기예요. Go나 Python처럼 문자열이 불변인 언어에서는 문자열을 계속 이어 붙이는 게 그리 효율적이지 않아요. 그래서 배열로 만들어서 마지막에 합치라든가, Go에서는 문자열 빌더를 쓰라든가 하는 조언을 많이 하게 돼요. 그러니까 더 나은 패턴, 모범 사례와 패턴 쪽으로 이끌어 주는 일이 많아요. 시청해 주셔서 감사합니다. Jonathan: 좋아요, 멋지네요. 정말 흥미로워요. 그럼 지금 일상은 어떤가요? 개발은 어디에 들어가 있고요? 기술 분야에서 오래 일했으니 하루가 어떻게 흘러가나요? 어떤 어려움이 있고, 요즘 일에서 어떤 부분이 재미있어요? Isaac: 저는 사이트 신뢰성 엔지니어링, 그러니까 대략 DevOps와 비슷한 역할을 하고 있어요. 시스템 관리 쪽 일도 좀 있고요. 지난 10년 정도는 온콜 교대조에서 호출기를 들고 지냈어요. 그래서 일상은 제 온콜 주간인지 아닌지에 따라 크게 달라져요. 온콜일 때는 호출기를 계속 지켜보고, 티켓 큐와 지원 큐를 확인하면서 실패한 프로세스나 문제가 있으면 진단해서 고쳐요. 그게 대략 6주에 한 주 정도예요. 팀이 지금 얼마나 큰지에 따라 다르지만요. 나머지 시간에는 온콜이 아니에요. Jonathan: 네. Isaac: 자동화를 만지작거리며 시간을 많이 보내요. 그러니까 번거로운 프로세스를 찾아내서 덜 번거롭게 만드는 일이 많아요. … 그럴 만한 이유가 있을 수도 있지만, 일반적으로는 이런 문제가 생기면 이 명령, 저 명령을 직접 실행해서 수동으로 고치잖아요. 그러면 저는, 왜 이 명령들을 손으로 실행하고 있지? 이걸 전부 대신 해 줄 Python 스크립트를 쓰면 안 되나? 아니면 실패하지 않고 그 문제를 스스로 잡아내도록 도구를 개선할 수는 없나? 하는 생각을 해요. 시스템을 운영하는 일상을 개선해서 사람이 덜 개입하거나, 시스템이 매끄럽게 돌아가도록 그렇게 깊이 관여하지 않아도 되게 만드는 데 시간을 많이 쓰죠. Jonathan: 그럼 최적화할 수 있는 작은 부분들을 찾아내는 게 재미있어요? 일이 얼마나 반응하는 쪽이고, 반응하다가 아, 이거 기회다 싶어서 적극적으로 그런 부분을 찾아나가는 쪽인가요? 보통 균형이 어떻게 되나요? Isaac: 저는 자동화를 좋아해요. 아마 제 일에서 가장 좋아하는 부분이 뭔가를 자동화할 수 있다는 거예요. 항상 반응만 하는 건 아니에요. 반응이라고 해도 뭔가가 망가지는 경우도 있고, 아, 사람들이 이 명령을 복사해서 붙여 넣곤 하는데 내가 고쳐 볼 수 있을까? 하는 경우도 있죠. 누군가 런북을 고치거나 어딘가의 명령을 개선하는 걸 보면, 아, 저 명령은 꽤 엉망인데 처음부터 다시 써 볼까? 싶기도 하고요. 물론 그러려면 관심이 많이 필요하고, 다른 일과 균형도 맞춰야 하고, 더 큰 단어가 아니라 더 나은 표현을 써야 하고, 그런 것들이 다 필요하죠. 그러려면 그걸 잘 해내야 해요. 솔직히 제 일에서 하는 건 생각해 보면 다 그런 것 같아요. 저는 의욕이 아주 강한 사람이라서, 제가 좋아하는 일이라면 시간을 쏟는 건 당연하고, 그냥 해 보려고 하는 거예요. Jonathan: 제조라고 할 수도 있겠네요. Isaac: 리팩터링이죠. 쓰기 번거로운 도구를 발견하고는 다시 쓰거나 그 도구를 감싸는 래퍼를 짜기로 하는 거요. 크고 복잡한 프로그램의 코드 변경을 보다가, 아, 이 프로그램은 엉망이네. 들어가서 다시 쓰거나 리팩터링할 수 있을까? 하고 생각하기도 하고요. 새로 만드는 것도 있고요. 항상 리팩터링만은 아니고, 그냥 새 도구를 만드는 경우도 많아요. 20단계나 걸리는 프로세스가 있으면 그걸 전부 프로그램 하나에 밀어 넣자, 하는 식이죠. 대부분은 어떻게든 이런 것들을 발견해야 하는데, 어떤 작업을 맡아서 하다가 이걸 손으로 실행하고 싶지 않다는 데서 발견할 때도 있고, 그냥 우연히 눈에 띄어서 발견할 때도 있어요. 어딘가에서 코드를 찾아보다가, 아, 다른 팀이 관리하는 저쪽 코드는 좀 엉망이네, 저걸 리팩터링하거나 최신 라이브러리를 쓰게 하자, 싶을 때도 있고요. Jonathan: 그러니까 결국 보는 눈이 중요하네요. 그럼 재량권은 얼마나 있어요? 여기저기 돌아다니면서 휙 들어가서 손보는 게 꽤 자유로운가요? 꽤 재미있겠어요. Isaac: 제 매니저는 재량권을 많이 줘요. 정말 좋죠. 지금은 Google에 있지 않지만, 이게 Google에서의 경험에서 얼마나 온 건지는 모르겠어요. Google에서는 사람들이 아주 열려 있었어요. 휙 들어와서, 아, 저쪽에서 쓰는 라이브러리를 보니 이렇게 개선할 수 있겠네, 내가 고쳐야겠다, 하고 말이죠. 아주 잠깐이지만 문화가 아주 다른 스타트업에서 일한 적도 있어요. 훨씬 덜 열려 있었죠. 그 스타트업에서는 사람들이 자기 코드베이스를 아주 아껴서 다른 사람이 자기 코드를 고치는 걸 별로 좋아하지 않았어요. 그래서 제가 이 코드베이스에 문제가 있다고 해도 그 코드베이스를 고치게 해 주지 않았죠. Jonathan: 네, 물러서세요, 그런 거죠. 그런데 흥미로워요. 왜냐하면 스타트업이라면 그냥 일을 끝내고 최대한 저렴하게 처리하는 쪽일 거라고 생각하잖아요. 그런데 사실은 Google이 그런 개념을 훨씬 더 잘 받아들였을 수 있겠네요. 아, 죄송해요, 방금 불을 켰어요. 지금 듣고 계신 분들께는 불이 꺼져 있는 상태고, 케이프타운은 가끔 전기가 나가거든요. 방금 제 눈을 부셨지만 괜찮아요. 아무튼 스타트업 문화 얘기로 돌아가면 흥미롭네요. 사람들이 아이러니하게도 뭔가를 자기 소유라고 여기는 데 더 얽매여서 일을 조금 묶어 버리는 거죠. Isaac: 네, 스타트업이라는 게 꼭 열린 문화, 그러니까 즐기면서 일하는 문화와 잘 맞는지는 모르겠어요. Google에서는 사람들이 하는 일의 상당 부분이 놀이 같았어요. 자기가 좋아서 하는 일이니까 즐기면서 했죠. 서로 아주 우호적이고 열려 있었어요. 다른 직장 문화는 꼭 좋아서 하는 게 아니라 그냥 일이라든가, 이건 내 코드이고 나는 이게 어떻게 돌아가는지 아니까 다른 사람이 건드리지 않았으면 좋겠다는 쪽에 가까울 수도 있어요. 이런 직장 문화가 어떻게 바뀌는지는 저도 잘 모르겠어요. 그런데 Google은 모두가 모든 코드에 접근할 수 있고, 누구든 바꿀 권한이 있다는 분위기를 정말 잘 만들었어요. 옳다고 생각하는 대로 가서 하라는 거죠. 지금 일하는 곳의 매니저도 저에게 재량권을 많이 줘요. 고칠 게 있으면 고치라고, 개선할 부분을 찾았으면 알아서 하라고, 내가 도울 일이 있으면 알려 달라고 하죠. 그래서 제가 하는 일의 상당 부분을 스스로 정할 수 있어요. 아, 이건 더 나아지게 만들 수 있겠다 싶으면 좋으니까 해 보라고 해 줘요. Jonathan: 좋네요. 그런데 회사는 동부에 있고, 실제로는 원격으로 일하는 거죠? 예전에 옮겨 갈 예정이라고 했던 것 같은데, 코로나가 터지면서 그 계획이 끝나 버렸잖아요. 원격 근무, 거리, 시차 같은 건 어떻게 느껴요? 영향을 받나요? Isaac: 사무실에 있고 사람들을 직접 만나는 게 확실히 그리워요. 그런 점도 있고, 시차는 팀이 아주 잘 맞춰 줘요. 저는 팀의 다른 사람들보다 세 시간 느려요. 제가 놓치는 짧은 일일 스탠드업이 있고, 두 개 제품을 위한 일일 미팅이 두 개 있어요. 첫 번째 건 저는 못 들어가고, 팀이 거기서도 저를 잘 배려해 줘요. 내부적으로는 Slack을 많이 써서 그날 나온 이슈를 Slack 스레드에 정리해 두니까 제가 따라갈 수 있고, 뭔가 필요하면 저를 불러 줘요. 저도 최대한 빠르게 응답하려고 하고, 그런 것들을 아침에 되도록 빨리 확인해서 처리해요. 그래서 시차가 좋은 건 아니지만 그렇다고 아주 힘든 것도 아니고, 우리는 잘 해결해 왔어요. 반대로 팀에서 더 늦게까지 깨어 있는 사람이 있다는 걸 알기 때문에 이런 경우도 있어요. 동부가 저녁 6시일 때 뭔가가 망가지면, 아, Isaac이 서부에 있으니까 Isaac이 도와줄 수 있겠다, 거기는 아직 오후 3시니까요. 그래서 양방향으로 다 잘 돌아가요. 네, 그래서… Jonathan: 네. Isaac: 네, 저는 2019년에, 아 죄송해요, 2020년에 Google을 떠났어요. 면접은 2019년에 봤고, 2020년 5월에 입사할 예정이었어요. 2020년 4월에, 아니 8월에 이사할 계획이었는데 코로나가 시작되고 사무실이 닫혀 버렸죠. 사무실이 아직 안 열렸으니 열리면 바로 이사할 거라는 상황이 계속됐어요. 그러다 팬데믹이 2년쯤 지나자 사무실이 다시 열리기 시작했어요. 그런데 저는 이제 이사하고 싶은지 잘 모르겠더라고요. 뉴욕은 정말 흥미로워 보였는데, 가게들이 열려 있고 공연장 같은 것도 돌아가는 게 매력이었거든요. 그런데 팬데믹 이후로는 그런 게 그렇게 흥미롭게 느껴지지 않았어요. 그래서 2년간 원격으로 일한 뒤 정식으로 원격 근무로 전환했어요. Jonathan: 그럼 도시형인가요, 시골형인가요, 아니면 중간쯤인가요? 뉴욕은 도시잖아요. 100% 도시죠. 두말할 나위 없어요. 그러면 꽤 큰 변화였을 텐데요. 그래도 흥미롭긴 하죠. Isaac: 저는 대도시권에서 자라서 도시 생활이 낯설지 않아요. 지금은 교외에 살고 있어요. 등산과 자전거 타기를 좋아해서 가능하면 자주 밖에 나가려고 해요. 그래서 멋진 등산로와 자전거 도로가 가까운 교외 생활이 좋아요. 뉴욕으로 이사하는 건 꽤 큰 변화겠죠. 그래도 가끔은 판을 바꿔 보는 것도 나쁘지 않다고 생각해요. 뉴욕에서 사는 게 싫어지면 그냥 떠나면 되니까요. Jonathan: 그렇게 하는 게 그렇게 어렵진 않죠. 아무튼 멋지네요. 그럼 아마, 제가 틀렸다면 알려 주세요, 사무실이나 재택 사무실 같은 곳에서 화면 앞에 오래 앉아 있을 텐데요. 매일 밖에 나가나요? 화면 속 세계와 바깥 세계를 어떻게 균형 잡아요? 나가서 다른 걸 해야겠다고 정해 둔 시간이 있나요? Isaac: 그러면 좋겠어요. 어떤 날, 어떤 달, 어떤 해에는 더 잘하기도 해요. 2020년에는 거의 매일 자전거를 탈 만큼 잘했어요. 주말에는 대부분 밖에 나가고, 일주일에 한 번은 등산을 하려고 해요. 잘 못 할 때도 있지만 등산은 가려고요. 계절에 따라 다르죠. 저는 캘리포니아에 있는데 어떤 주는 엄청 덥거든요. 얼마 전에는 일주일 내내 섭씨 40도가 넘는 폭염이 있었어요. 그러면 밖에 나가기가 힘들어요. 캘리포니아는 산불도 있어서 일주일이나 이주일 동안 바깥 공기 질이 숨 쉬기에 안전하지 않을 때도 있어요. 그래서 어떤 주에는 야외 활동이 어려워요. 그리고 팬데믹 상황에서 실내에 있는 것도 힘들고요. 그래서 확실히 실내에 더 많이 있는 주도 있어요. 그래도 밖에 나가는 걸 좋아해요. 적어도 격주로 등산을 다니는 식으로 6개월씩 이어간 적도 있고요. Jonathan: 그리고… Isaac: 6개월 동안 매달 한 번씩 캠핑을 간 적도 있어요. 그래서 더 잘하는 시기도 있고, 2주 내내 집에만 있는 시기도 있어요. Jonathan: 네, 멋지네요. 그럼 Isaac, 다음은… 아마 이렇게 멀리까지는 생각 안 해 봤을 수도 있는데, 앞으로 5년은 어떻게 보내고 싶어요? 어떤 계획이 있어요? 아니면 직접 사업을 시작하고 싶다든가 이런 걸 하고 싶다든가, 아니면 그냥 인생을 즐기면서 지금 있는 자리를 만족하는 편인가요? Isaac: 서부로 이사 오기 전에는 제 미래가 어떻게 될지 잘 파악하고 있다고 생각했어요. 그런데 그게 전부 뒤집히는 걸 겪고 나니, 5년은커녕 1년 뒤에 무슨 일이 일어날지 예측하기도 정말 어렵다는 걸 배웠어요. 저는 지금 꽤 행복해요. 얼마 전에 이직했고, 2년, 2년 반 전쯤에 회사를 옮겼어요. 지금 일이 꽤 재미있어서 당장 바뀔 것 같진 않아요. 앞으로 2년, 3년, 아니면 5년까지 같은 회사에 있어도 좋아요. 캘리포니아에 사는 게 좋고, 등산하고 자전거 타고 캠핑하는 걸 할 수 있다는 게 좋아요. 그래서 당장 캘리포니아를 떠날 생각은 없어요. 일이 정말 재미있으니 회사도 당장 그만둘 생각은 없고요. 그래서 꽤 만족하고 있고, 큰 변화는 계획에 없어요. 그래도 앞일은 정말 알 수 없죠. Jonathan: 그럼 몇 가지 질문이 더 있는데, Isaac의 생각을 듣고 싶어요. 첫 번째는 아마 미리 준비해 둔 질문은 아닐 거예요. 만약, 지금 사무실에 낯선 사람 10명이 들어온다고 해 봐요. 하프 연주자, 정원사, 뭐든 좋아요. 그 사람들이 코딩에 대해 아무것도 모른다면, 코딩을 시작하는 법을 알려 주기 위해 가장 중요한 세 가지 조언은 뭘까요? 그러니까, 무슨 수를 써서라도 이건 해라, 하는 식으로 정리한다면 어떤 게 있을까요? Isaac: 첫 번째로 추천하고 싶은 건, 코딩으로 해결할 수 있는 문제를 찾아보라는 거예요. 그러니까 뚜렷한 목표가 없어도 스스로를 앞으로 밀어 줄 동기가 되는 구체적인 프로젝트를 하나 갖는 거죠. 다른 기술과 마찬가지로 코딩을 배우는 일은 정말 도전적이에요. 꽤 많은 끈기와 근성이 필요해요. 그냥 계속 붙들고 있어야 해요. 처음에는 아주 힘들고 답답할 수 있어요. 앞으로 나아가게 해 줄 뭔가가 없으면 포기하기 너무 쉬워요. 그래서 가능하다면 정말 하고 싶은 게 있으면 큰 도움이 돼요. 다 비슷한 맥락의 조언이에요. 그냥 계속 해 나가야 한다는 거죠. 스스로에게 너그러워지고, 새로운 기술을 배우는 중이라 많이 실패하게 될 거라는 걸 인정하는 게 큰 도움이 돼요. 코딩을 배우려다가 좌절하는 사람들을 봤어요. 저는 원래 뭘 잘하는 편인데 이건 처음부터 잘 안 된다고 하더라고요. 그래, 실패는 배움의 과정이에요. 그리고 실패하는 게 불편하면 새로운 기술을 익히기가 정말 힘들어져요. 스스로에게도, 그 과정에도 인내심을 갖고 계속 해 나가는 게 중요해요. Jonathan: 도움이 되네요. 그러니까 저는 메서드가 어떻게 동작하는지 이제야 알았어요. 그냥 계속 겪으면서요. 사람들이 뭔가를 얘기할 때, 특히 가르칠 때는 당연하게 여기는 지식이 너무 많잖아요. 그래서 갑자기 다들 메서드라는 단어를 막 쓰는데, 도대체 메서드가 뭐지? 무슨 일이지? 싶었어요. Go 코호트를 하면서야 아, 메서드는 이렇게 동작하는구나 하고 알게 됐어요. 퍼즐이 딱 맞춰지는 느낌이었는데, 그 환경과 용어에 오래 잠겨 있어야 스며들더라고요. 제가 배운 것 중 가장 큰 건, 전부 배우려고 하지 말고 단순한 개념 하나씩 조금씩 깎아 나가라는 거였어요. 모든 게 너무 촘촘히 얽혀 있어서 그러다 보면 결국 머릿속 모형을 하나로 엮어 나갈 수 있게 되거든요. 그게 정말 중요해요. 아주 좋은 도구네요. 그래서 사람들에게도 알려 줘야겠어요. Isaac의 조언, 참을성 있게, 스스로에게 너그럽게, 조금씩 깎아 나가기요. 정말 멋져요. 그럼 마지막 질문인데요, 하루를 마저 보내기 전에 하나만 더 물어볼게요. 저희 팀에서 기술에서 목숨 걸고 주장하는 것, 'hill you would die on'이라는 개념에 대해 얘기했어요. 그렇게 말하면 꽤 멜로드라마 같고 드라마틱하죠. 요점은, 기술 분야에서 절대 흔들리지 않는 사고방식이나 관점이라고 믿는 한 가지가 뭐냐는 거예요. 예를 들어 아주 사소한 걸로는, 저는 프런트엔드를 할 때 항상 함수를 먼저 쓰고 그다음에 CSS를 써요. 기능, 그다음 로직, 그다음 나머지 이런 식으로요. 아니면, Unison 트랙을 운영하는 Rebecca는, 자기 주장이 강하고 같이 일하기 까다로운 천재 한 명을 두느니, 팀에서 함께 문제를 푸는 걸 정말 좋아하는 사람 50명이 낫다고 했어요. 천재 한 명이 관리 측면에서 모든 자원을 잡아먹는 것보다요. 그게 그 사람의 방식이었고, 제가 좋게 표현했지만, Isaac이 기술 분야에서 절대 양보할 수 없는 원칙은 뭔가요? Isaac: 이건 아마 Google이 하는 방식에 아주 크게 영향을 받은 것 같아요. Google에는 가독성이라는 개념이 있어서 코드는 읽기 쉬워야 한다고 봐요. 제가 코드를 쓸 때도 읽고 이해하기 쉬운 코드를 원해요. 그런데 세상에는 효율성과 벤치마킹, 코드를 더 빠르게 만드는 데 집중하는 코드가 아주 많아요. 저는 제 방식이 꼭 가장 효율적이지는 않다는 걸 자주 인정해요. 그래도 코드가 더 읽기 쉬워진다면 아주 효율적인 코드보다 읽기 쉬운 비효율적인 코드를 선호해요. 그 유명한 말이 있잖아요, 누구 말인지는 정확히 모르겠지만, 성급한 최적화는 모든 악의 근원이라는 말이요. 사람들이 이걸 어떻게 하면 더 효율적으로 만들 수 있을까요? 하고 물으면 저는, 꼭 더 효율적이어야 하나요? 프로덕션에서 돌리면서 효율성 문제를 겪었나요? 프로덕션에서 쓰기엔 너무 느린가요? 코드가 프로덕션에서 더 효율적이어야 할 만한 문제를 실제로 겪은 적이 없다면 왜 더 효율적으로 만들려고 하나요? 지금 그대로도 읽기 쉽고 유지보수하기 쉽고 다른 사람들도 무슨 일인지 이해할 수 있는데요. CPU 사이클 몇 개 아끼자고 일하기 쉽고 유지보수하기 쉬운 잘 짠 코드를 포기할 이유가 뭐죠? 그냥 최적화를 하기 위해서라면, 전기와 CPU가 그만큼 싸니까 굳이 코드를 최적화할 필요가 없는 거 아닐까요? Jonathan: 네, 항상 웃긴 게, 저는 이런 편이에요. 우리 프로그램이 30밀리초에 컴파일되고 실행됐다고 하면, 사람들은 아, 그런데 우리는 20밀리초로 줄였어요, 하고 말하죠. 저는 어느 쪽이 더 빠르고 느린지 구분도 못 하겠어요. 빠르긴 빠르네요. 좋은 지적이라고 생각해요. Isaac의 코드를 읽으면 재미있을 것 같아요. 아무튼 좋았어요. Isaac, 시간을 내 줘서, 일찍 일어나 줘서, 그리고 남반구의 순환 정전을 견뎌 줘서 정말 고마워요. 저는 지금 완전한 어둠 속에 앉아 있는데, 아마 꽤 웃기게 보였겠죠. 아무튼 시간 내 줘서 정말 고마워요. 앞으로의 학습 코호트와 멘토링 방송에서 또 뵐게요. Exercism과 여러 곳에 기여해 줘서 고마워요. 정말 감사해요. 그리고 다시 한번 정말 고마워요. 곧 또 뵙죠. 아뇨, 제가 더 감사하죠. 잘 지내요, Isaac. 안녕. Isaac: 다시 한번 정말 고마워요. 아니에요, 별말씀을요. 잘 지내요, Isaac.