탐험, Elixir 그리고 Exercism

Jonathan: 안녕하세요 여러분, 좋은 저녁이에요. Exercism 팟캐스트에 오신 것을 환영해요. **Brian **Underwood와 함께하게 되어 영광이에요. Brian, 지금은 어디에 살고 있어요? 그리고 어떻게 지금 있는 곳까지 오게 됐는지, 이야기도 조금 들려주세요.

Brian: 네, 그럼요. 초대해 주셔서 감사해요. 저는 스웨덴 스톡홀름에 있어요. 원래는 미국 오하이오에서 태어났으니, 거기서부터 꽤 긴 여정이었죠.

Jonathan: 아니요.

Brian: 음, 아마 제가... 제가 어디 출신인지, 그 중간의 여정이 궁금하셨던 거죠?

Jonathan: 네, 맞아요. 미국 중부에서 스웨덴, 그러니까 북유럽으로 어떻게 오게 된 거예요? 꽤 큰 도약이잖아요.

Brian: 그럼요. 네. 물론이죠, 미국 중부예요. 오하이오가 어디인지 아무도 잘 모르니까요. 그래서 그냥 넘어가셔도 전혀 이해해요. 저는 대학을 오하이오 주립대(Ohio State)에 갔어요. 컴퓨터과학, 그러니까 컴퓨터 교육 쪽이었어요. 재미있었고, 즐겁게 했어요. 그동안 계속 인문대학에서 기술 지원 같은 걸 했어요. 다닐 때 운 좋게 그쪽에서 일자리를 얻었고, 졸업하고 나서도 몇 년을 이어서 했어요. 그런데 그때 제가 있던 자리와 하는 일에 조금 지루해졌던 것 같아요. 그리고 여자친구도 저랑 헤어졌죠. 그 얘긴 그만, 그만둬요.

Jonathan: 별로 좋은 기억은 아니었다고 할 수 있겠네요.

Brian: 네, 돌이켜 보면 다 괜찮았어요. 그런데 뭐랄까, 여기에 기회가 있다고 생각한 거예요. 그래서 몇 주 동안 유럽을 여행하기로 했어요. 그때가 제가 처음으로 미국을 오래 벗어나 본 거였어요. 유럽 여행은 좋았어요. 그런데 그걸 하기 전에 이사를 가기로 마음먹었어요. 보스턴으로 이사하기로 정했죠. 제가 운이 좋았는지는 모르겠는데, 몇 가지 기회가 있었어요. 제가 늘 해 온 게 맥(Mac) 지원이었거든요. 그래서 보스턴에서 맥 기술 지원 일자리 하나를 잡을 기회가 있었어요. 또 하나는 작은 스타트업이었는데, 휴대폰 회사들을 위해 매장에 상품을 어떻게 진열할지 같은 소프트웨어를 만드는 곳이었어요. 저는 정말 프로그래머로 전환하고 싶었어요. 그런데 맥 지원 일은 제가 오래 해 온 일이었죠. 그래도 저는 새로운 삶, 그러니까 제가 원하는 커리어를 받아들이는 쪽으로 마음이 기울었어요. 그 일자리를 얻은 건 운도 좀 있었던 것 같아요. 사람이 정말 필요했던 것 같거든요. 그래서 그냥 저를 받아들여 줬죠. 그게 몇 년 동안 하게 된 꽤 큰 일자리가 됐어요. 그게 시작이었어요. 요약하면 거기서 지금의 아내를 만났고, 프로비던스로 이사 가서 결혼했어요. 그다음에 캘리포니아로 이사했어요. 아내가 샌프란시스코에서 일자리를 얻은 것 같아요. 저는 '그래, 나는 소프트웨어 개발자니까 샌프란시스코에서 일자리를 찾을 수 있어'라고 했죠. 문제없어요. 좋았어요. 오클랜드에 살면서 샌프란시스코에서 몇 년 동안 일했어요. 그런데 그다음에는 몇 년 동안 여행을 다니고 싶다고 결정했어요. 그래서 2년 동안 세계 일주를 했어요. 그때쯤에는 두 살 반짜리 아들이 있었고, 그래서 아들과 함께 몇 년을 여행했어요. 그리고 다시 미국으로 돌아와서 몇 년을 있었죠. 그다음에 여행 중에 스톡홀름을 지나갔는데, 정말 마음에 들었어요. 그래서 '좋아, 다시 오자'라고 했고, 지난 4년 정도를 여기서 지내고 있어요.

Jonathan: 아내분이 스웨덴 사람인가요, 아니면 그냥 스톡홀름이 좋아서인가요? 그게 어떻게 된 거예요? 무슨 사연이 있어요?

Brian: 네, 좋은 질문이에요. 많은 분들이 하는 질문이죠. 그런데 아니에요, 우리 둘 다 미국 사람이에요. 아들까지 셋 다 미국 사람이에요. 아들은 저희 둘보다 스웨덴어를 훨씬 잘해요. 지금 열심히 배우고 있어요. 아무튼, 그냥 정말 마음에 들었어요. 여행하면서 '여기 살아도 좋겠다' 싶었던 곳이 몇 군데 있었어요. 하나는 오클랜드였는데, 지나가다가 정말 좋았어요. 뉴질랜드요? 오클랜드, 뉴질랜드 말하는 거예요? 뉴질랜드, 맞아요. 그런데 좀 멀었어요. 가족 만나러 오하이오로 돌아가려면 꽤 먼 길이었을 거예요. 스웨덴에서도 물론 좀 먼 편이죠.

Jonathan: 네, 아무튼 아까 컴퓨터 프로그래밍, 아니 컴퓨터과학과 프로그래밍에 대해 말씀하셨잖아요. 어떤 차이였어요? 제 생각에는 컴퓨터과학이 곧 프로그래밍인 것 같은데, 꼭 그렇지는 않은가 봐요. 아니면 맞을 수도 있고요, 잘 모르겠어요. 구체적으로 무슨 뜻이었어요?

Brian: 네. 제가 그 차이를 아는지 모르겠어요. 저는 컴퓨터과학 학위를 땄고, 그게 프로그래밍이었다고 생각해요. 그런데 대학 학위로 항상 배우는 건 아니잖아요, 직장에서 배우고 하게 되는 실제적인 것들은요. 아마 제가 대학 다닐 때 이후로 좀 바뀌었을 거예요. 더 실용적인 교육 쪽으로 움직였다고 생각해요. 기억나는 게... 그때 우리가 배운 주요 언어 중 두 가지가 C와 Java였어요. 특히 한 수업에서 Java로 뭔가를 배웠던 게 기억나요. 아주, 그러니까 이건 교수법이었거나 어떤 접근 방식이었는데, 각 함수마다 아주 꼼꼼하게 주석을 달아서... design by contract라고 부르는 거였어요. 법률 계약서에서처럼 '당신의 책임은 무엇이고 제 책임은 무엇인가'를 따지는 거죠. 그래서 함수를 계약에 따라 설계한다는 건, 예를 들어 '이 변수들에 이 값을 넣어 주는데, 이건 절대 음수를 주지 마세요. 그리고 이 문자열은 절대 비어 있지 않게 해 주세요' 같은 거예요. 이런 것들이 당신의 책임이고, 그러면 나는 이걸 하겠다고 약속하는 거죠. 그래서 그런 주석 구조가 있었는데, 저는 주석이 어쩐지 실행되고 프로그램의 일부인 줄 알고 아주 혼란스러웠던 기억이 있어요. 며칠 동안 '뭘 어떻게 하라는 거지?' 하고 고민했던 것 같아요. 그러다 결국 아주 형식적인 방법일 뿐이라는 걸 깨달았고요. 그리고 그게 어떤 면에서는 좋았어요, 생각이 가끔 제 사고방식을 잡아 주거든요. 함수 하나가 일어날 수 있는 모든 일을 다 처리할 수 있게 하지 않는 것도 생각해 볼 만해요. 그러면 그냥 혼란만 커지니까요.

Jonathan: 그러면 컴퓨터과학을 주 전공으로 해서 대학에 가셨는데, 그건 어떻게 결정한 거예요? 학교나 고등학교에서 과학 쪽 과목에 자연스럽게 끌렸던 건가요, 아니면 '이게 정말 나한테 맞는다' 싶었던 순간이 있었나요? 컴퓨터과학을 전공하고 싶다고 결심하게 된 배경이 뭐였어요?

Brian: 네, 그냥 자연스럽게 끌린 편이었으니 꽤 운이 좋았던 것 같아요. 잘 모르겠지만, 기억나는 게... 한때 전공 선택지가 있었는데, 문리대 컴퓨터과학 트랙이나 공대 컴퓨터과학 트랙 중에 고를 수 있었어요. 하나는 어학 과목을 들어야 했고, 고등학교 때부터 이어 온 스페인어가 그거였어요. 다른 하나는 외국어는 안 해도 되지만 물리와 수학을 더 들어야 했죠. 그래서 '좋아, 그걸로 해 줘'라고 했어요. 그래서 저는 그쪽에 끌렸던 것 같아요. 다만 자주 생각하는 게 있는데, 어쩌면 이건 제가 가진 과학이나 수학에 대한 관심의 특권일 수도 있어요. 아마 수학, 수학을 하는 것... 많은 사람들이 '수학은 긴장되고 스트레스 받아'라고 하죠. 그럴 수 있다는 걸 이해해요. 그런데 가끔은 어떤 사람들은 그냥 수학에서 재미를 찾고 신나 하더라고요. 들이는 수고와 머리를 쓰는 양은 똑같은데, 재미있게 하면 수고가 덜 느껴지니까요. 그게 꼭 정확한 건 아닐 거예요. 제가 가진 엉뚱한 가설이고, 아마 절반만 맞을 거예요.

Jonathan: 그런데 재미있었던 게, 영국에서 GCSE 하면서 3년 동안 화학을 했거든요. GCSE 시험 전까지 3년 배우고, 16살에 큰 시험을 보는데, 과목 범위가 아주 넓어서 열 과목 정도를 하니까 꽤 많아요. 그리고 나서 '좋아, A level을 할 거야, 수학이나 과학을 더 할까, 아니면 영어나 연극을 할까'를 정하죠. 그런데 제 기억에 화학은 2년 정도는 이해가 안 됐어요. 그러다 시험 일주일 전쯤에 갑자기 다 이해가 됐어요. 주기율표랑 그게 어떻게 돌아가는지, '아, 주기율표에서 답을 다 얻을 수 있구나, 낱말 퍼즐 같은 거네' 하고요. 전구가 켜지는 순간이었죠. 그때부터 '아, 이게 세상에서 제일 쉬운 과목이네'라고 생각했어요. 그런데 거기까지 오는 데 2년이 걸렸어요. 재미있는 게, 저한테는 코딩도 비슷한 것 같아요. 오랫동안 푹 빠져 있다 보면 어느 순간 확 깨닫게 되는 거죠. 그런 방향으로 가고 있다는 느낌이 들어서 기대돼요. 그런데 아까 하신 얘기를 보면, 저는 처음부터 아주 빨리 이해하고 즐기는 친구들도 봤어요. 문제 해결이 학습의 핵심이었죠. 아주 흥미롭다고 생각해요. 직접 그런 경험을 하셨다니 좋네요.

Brian: 제 아들이 아이패드로 한 앱이 있는데, Dragon Box라는 회사, 아니 앱 시리즈가 있어요. 들어보셨는지 모르겠어요. 정말 잘 만든 교육용 앱을 만드는데, 보통 저는 대부분의 교육 앱에 회의적인데, 이건 정말 잘 만든 게 몇 개 있어요. 그중 하나가 기하학에 관한 거예요. 저는 이걸 자주 은유로 생각하는데, 사실 기하학이 아니라 대수학이었어요. 기하학 것도 있어요. 그런데 대수학 앱은 대수학의 개념을 가르치는 게 아니라 대수학의 기본 조작을 몸으로 익히게 해요.

Jonathan: 이 영상이 좋았다면 좋아요를 눌러 주시고, 이런 영상이 더 많으니 채널 구독도 부탁드려요.

Brian: 양쪽에 서로 다른 상자가 있고, 양쪽이 균형을 이루게 만들어야 하는 방식이에요. 괴물을 한쪽에서 다른 쪽으로 옮기거나, 어떤 괴물을 다른 종류로 변신시켜야 하죠. 본 지 좀 됐지만, 아주 선명하게 기억나는 건 아들이 자기가 뭘 향해 가고 왜 이걸 하는지도 모르면서 대수학의 기본 조작을 익히고 있었다는 거예요. 그런데 하는 게 재미있었고, 아주 몰입되게 만들었어요. 정말 좋다고 생각하는 점은, 나중에 대수학을 시작할 때 아들을 이 앱에 다시 들여보내고 싶다는 거예요. 조작을 익혀 두면 그런 걸 그렇게 걱정하지 않아도 되고, 그런 것에 스트레스 받지 않고 더 높은 차원을 생각할 수 있으니까요. 아까 화학 얘기도 그런 것 같아요. 그때 그런 경험이었는지는 모르겠지만, 아마 '이 조작이며 규칙이며 이런 것들을 왜 신경 써야 하지?' 싶다가 어느 순간 '좋아, 여기까지 힘들게 왔으니 이제는 왜 이걸 하는지 생각할 수 있겠다'가 되는 거죠.

Jonathan: 네, 맞아요. 정말 흥미로운 경험이었어요. 왜냐하면 뭔가를 이해하는 그 과정을 처음 겪어본 거였거든요. 그러다 그 과목들에 대해 자신감을 많이 잃는 시기를 지나요. '내 머리는 그런 사고방식에는 안 맞나 보다' 싶으니까요. 그런데 사실 영문학을 보면, 제가 했던 건데, 언어와 구조를 아주 체계적으로 파고들면서 이해하죠. 그런데 거기엔 뉘앙스도 있고 예술적인 면도 있어요. 개발과 코딩에도 그런 예술적인 요소가 있다고 할 수 있고요. 사람마다 자기만의 색이 있고, 점점 더 느끼는 건 어떤 것에도 정해진 규칙은 없다는 거예요. 다 트레이드오프죠. 정말 흥미로웠어요. 그런데 아까 코호트에서 도와주셨잖아요. 듣고 계신 분들을 위해 말하면, 저희가 Elixir와 Golang으로 학습 경험을 진행했는데, Brian이 Elixir 코호트에서 조금 도와주셨어요. 그럼 Elixir라는 언어는 어떻게 시작하게 됐어요? 어떤 배경이 있었어요?

Brian: 네, 재미있어요. 오늘 누가 저한테 딱 그 질문을 했거든요. 어떤 면에서는 틈새 언어이긴 하죠. 그런데 저는 Ruby를 오래 했어요. Ruby 개발자로 오래 있었고, Ruby를 정말 좋아해요. 저는 뭔가를 끝내고 싶어 하고, 어려운 문제를 해결하고 싶어 하는 프로그래머거든요. 그런데 사소한 디테일이나 포인터 같은 걸 신경 쓰면서는 어려운 문제를 해결하기 어렵죠. 그래서 Ruby가 그런 면에서 훌륭했어요. 그리고 Elixir를 만든 Joseph Alim은 Ruby 세계에서 나왔어요. Ruby 세계에서 이미 활발하게 활동했는데, 자기 언어를 만들어서 그쪽에서도 활발히 하고 싶었던 거예요. 정말 잘 해냈고요. 그래서 저도 그 세계에 푹 빠졌어요. Ruby 얘기가 나오는 팟캐스트를 듣다가 '아, Elixir라는 새로운 게 있네' 하게 됐죠. 그리고 좀 근본적인 계기가 있었는데, 그때 제가 콜럼버스로 잠깐 돌아가 있었어요. 오하이오 콜럼버스요. Joseph Aleem이 콜럼버스의 Ruby 모임인 Columbus Ruby Brigade에 왔어요. 사람들은 'Joseph Aleem이 오셔서 하고 싶은 얘기를 해 주신대'라고 했죠. 물론 그는 '네, 제가 만든 Elixir에 대해 얘기하겠습니다. 정말 기대돼요'라고 했고요. 네, 맞아요. 그리고 기억나요, 재미있게도 작년에 그 발표 녹화본을 찾았어요. 화질은 좀 안 좋지만 여전히 볼 수 있어요. 제가 Joseph에게 질문했던 장면도 찾을 수 있었어요. 그때 제가 아주 혼란스러워했던 게 기억나요, 정확히 어떻게 되는 건지.

Jonathan: 정말 기대돼요.

Brian: 프로세스를 만들면, 슈퍼바이저 같은 게 있으면 실패에서 복구할 수 있다는 개념이요. 그가 정확히 뭐라고 했는지는 기억나지 않지만, 저는 '그게 어떻게 되는 거예요?'라고 했어요. '오류에서 복구한다는 건 알겠는데, 그러면 그 오류에 대해 뭔가를 배우긴 하나요? 아니면 무슨 일이 일어나는 거죠?' 하고요. 그게 무슨 의미인지 배우는 데 꽤 오랜 과정이 걸렸어요. 아주 흥미로운 과정이라고 생각해요. 그때는 Elixir 커뮤니티의 많은 사람이 이런 개념을 어떻게 설명할지 고민했던 것 같아요. 지금은 블로그 글도 더 많고, 사람들이 더 빨리 흡수해서 들어올 수 있는 것들이 많아졌어요. 아무튼 그런 곳에서 시작했어요. '아, 흥미롭네. Jose가 좋다고 하면 한번 봐야지' 하는 식이었죠.

Jonathan: 그러면 그때가 마침 옮겨가기 좋은 타이밍이었던 건가요? 여러 가지가 맞아떨어져서 자연스러웠던 거고요. 다른 언어도 살펴보고 있었어요? 아까 포인터 얘기를 하셨는데, 그게 Go를 가리키는 거였어요, 아니면 그냥 본인에게 맞는 언어를 찾고 있었던 건가요?

Brian: 제 생각에는... 네, 저는 서로 다른 것들이 서로 다른 목적에 좋다는 생각을 아주 좋아해요. 그리고 지금은 Elixir에 푹 빠져 있고요. 아마 제가 좀 편향됐을 수도 있어요. 'Elixir는 거의 모든 것에 쓸 수 있다'는 식으로요. 그게 완전히 사실은 아닐 거예요. 포인터 얘기는 그냥 C가 떠올랐던 것 같아요. 대학에서 C, C++을 좀 했거든요.

네, 그래서 몇 년 동안 그래프 데이터베이스인 Neo4j로 일했어요. 그거에 아주 빠져 있었고, Ruby용 Neo4j 젬의 메인테이너 중 한 명이었어요. 왜냐하면...

너무 깊이 들어갈 필요는 없지만, 그래프 데이터베이스는 어떤 일을 더 빠르게, 어떤 면에서는 더 쉽게 할 수 있게 해 줘요. 많은 사람이 이 용도로 Neo4j를 쓰진 않지만, 저한테는 Ruby와 비슷했어요. 더 높은 차원에서 생각하도록 도와주고, 그래서 일을 더 멋지게 할 수 있게 해 주죠. 저는 그런 생각을 좋아해요. 그래프 데이터베이스는 이런 목적에, 관계형 데이터베이스는 이런 목적에, 문서 데이터베이스는 이런 목적에 좋다는 거요. 그리고 아주 빠르게 동작해야 하는 작은 서비스를 만들어야 한다면 Rust나 Go 같은 걸로 만들 수도 있고, 그러면 그런 언어들도 알아야 하고요. 더 높은 차원의 일에는 Ruby와 Python이 있고, 이제는 Elixir도 있고요. Elixir는 정말 많은 장점이 있어요. 어떤 게 어떤 것에 좋은지 알아내는 건 아주 어려운 일이에요. 언어 하나에 워낙 많은 게 얽혀 있어서 어떤 용도에 좋은지 판단하기가 어렵죠. 그리고 저를 포함해 많은 사람이 이런저런 이유로 좋아하는 언어에 감정적으로 투자하게 되고요. 그래서 어렵죠. 음.

Jonathan: 그리고 Brian, 일할 때 Elixir를 매일 쓰세요? 지금 하고 있는 일은 뭐예요? 요즘 하루하루는 어떤 모습이에요?

Brian: 네, 저는 Erlang Solutions의 컨설턴트예요. Erlang Solutions의 고객사인 VicAI라는 회사와 일하고 있어요. 들어보셨는지 모르겠어요. Lars Wirthven이 이 회사를 좀 도와주고 블로그에 조금 썼던 것 같아요. Elixir 세계에서 반쯤 유명한 사람이죠. 그 회사는 다른 회사들을 돕는데, 인공지능을 이용해 청구서를 반자동 또는 완전 자동으로 처리하도록 돕는 애플리케이션을 만들어요. 물론 머신러닝 모델도 있지만, 여러 가지를 조율할 수 있게 해 주는 Elixir API도 있어요.

Jonathan: 네. 그럼 하루에 여러 고객사를 상대하세요, 아니면 한 팀과 함께 하면서 파트너처럼 일하나요? 어떻게 돌아가요?

Brian: 네, 저는 보통 프로덕트 매니저와 함께 기능 팀에 있어요. 웹 개발자, 모바일 개발자, 때로는 백엔드 개발자, 머신러닝 팀도 있고요. 그리고 가끔 프로덕트나 QA 담당자가 고객사와 소통하면서 저희에게 가장 관련 있고 가장 필요한 것, 그러니까 사용자와 고객사가 실제로 무엇을 필요로 하는지 알려 주면 좋아요. 그런데 좀 층이 나뉘어 있어요. 큰 직접 고객사 하나가 있고, 또 회계 시스템이나 ERP 같은 것들과도 일하는데, 그쪽에는 고객 정보를 입력하는 사람들이 있어요. 솔직히 저는 고객 쪽 일을 그렇게 많이 하진 않아요. 그래도 고객사와 소통하는 방식이 여러 가지이고, 통합하려면 여러 가지 춤을 춰야 하는데, 그 자체로 흥미로운 문제예요.

Jonathan: 그럼 한 주가 꽤 다양한가요, 여러 가지 일을 하세요, 아니면 꽤 예측 가능한가요?

Brian: 음, 네. 저는 꽤 운이 좋은 편이에요. 보통 한 프로젝트를 하고 있어요. 예를 들어 최근에는 청구서를 처리할 때 계산이 정확한지 확인하는 일을 도왔어요. 그게 까다로울 수 있거든요. 특히 여러 업체에서 청구서가 들어오고, 업체마다 방식이 다를 수 있으니까요. 그래도 저는 운이 좋은 편이에요. 회사에서 코드 품질을 잘 관리하고 전반적으로 상황을 파악하고 있길 원하거든요. 그래서 저희는 개선하고 코드를 더 낫게 만드는 데 꽤 많은 시간을 쓰려고 해요. 저도 원래 그런 편이고요. 항상 시간을 조금이라도 확보해서, 예를 들어 DataDog을 애플리케이션에 연동해서 요청과 백그라운드 작업을 추적할 수 있게 해요. 그런 걸 해 두면 정말 뿌듯해요. '이제 일할 도구가 갖춰졌다' 싶으니까요. 그리고 최근에 코드를 정리하고 다른 모듈을 참조하는 방식에 관심이 생겼어요. Elixir 생태계에는 Credo라는 도구가 있어서 코드 스타일 규칙을 강제할 수 있어요. 그래서 그 규칙을 강제할 새로운 Credo 규칙을 만들어 봤어요. 어떻게 될지 궁금해요.

Jonathan: 좋아요. 솔직히 제겐 좀 어려운 얘기지만, 분명 누군가는 알아들을 거예요. 아까 스타트업에서 조금 일했다고 하셨죠? 기술 지원 쪽 일도 있었고, 스타트업 이야기도 있었고요. 앞으로도 그런 쪽에 관심이 있으세요, 아니면 늘 마음 한구석에 있는 생각인가요? 프로그래밍 쪽으로 앞으로 5년, 10년 동안 어떤 방향을 그리고 있어요? 모르실 수도 있지만, '5년, 10년 뒤에 자신이 어디 있을 것 같은가'를 사람들에게 묻는 게 재미있어서요.

Brian: 네, 좋은 질문이에요. 저는... 스타트업 쪽은, 저는 늘 중소기업 사이를 오갔어요.

Jonathan: 감사합니다.

Brian: 아주 큰 회사에서도 행복했고요. 최근까지 컨설턴트가 될 거라고는 생각하지 못했어요. '이건 좀... 여러 회사를 다니면서 그들의 문제를 해결하도록 돕고, 그러다 다른 회사로 옮기는 것도 흥미롭겠다' 싶었죠. Big Gag 쪽에서 듣고 계신다면, 저는 지금 불만은 없어요.

Jonathan: 팟캐스트에서 이런 걸 물어봐도 되나 싶었는데, 뭐, 모든 게 잘 되고 있다고 가정하는 거죠. 죄송해요, 고양이가 문을 긁고 있네요.

Brian: 아, 네. 저희는 한 달 전쯤 강아지를 들였어요. 그래서 계속 신경을 써야 해요. 짖기도 하고, 한두 번은 침대에 오줌을 싸기도 해서 '이걸 처리해야 한다' 싶죠.

Jonathan: 저희도 막 들였는데, 정말 장난 아니에요. 아침 5시마다요. 새벽 4시 30분이면 침대 위로 뛰어올라서 얼굴을 앞발로 톡톡 건드려요. 귀엽긴 한데, 시간이 좀 지나면 '아, 좀' 싶죠. 그런데 다시 향후 몇 년 얘기로 돌아가서, 어떤 걸 해내고 싶거나 이루고 싶으세요?

Brian: 네, 좋은 질문이에요. Elixir가 아직 좀 새롭다는 게 저한테 매력적인 것 같아요. 그래서 새로운 길을 열고 새로운 패턴을 찾는 방법에 관심이 있어요. 저는 Ruby 세계에 오래 있었는데, Elixir로 오면서 '아, Ruby에서 아쉬웠던 게 이거였는데, 이걸 만들면 좋겠다' 싶은 게 있기도 해요. 또 '이건 Ruby에서는 잘 못 했는데, 이렇게 하면 Elixir의 강점을 살려서 훨씬 멋지게 할 수 있겠다' 싶은 것도 있고요. 그래서 저는 멋진 사용 사례를 찾아서 얘기하고 공유하는 걸 좋아해요. 실제 사용 사례에 대한 글을 읽고 세부 사항을 볼 때 영감을 받거든요. '이걸 했다, 이렇게 했다'가 아니라 코드는 어디서 볼 수 있지, 세부 내용은 뭐지, 하는 거요.

Jonathan: 뭔가를 더 낫고 더 효율적으로 만드는 새로운 길을 개척하는, 최적화하는 쪽을 즐기시는 것 같아요. 제가 이해한 바로는요. 맞나요?

Brian: 네, 효율적인 것도 좋아요. 그런데 아마 더 좋아하는 건 일을 즐겁게 만드는 방법을 찾는 거예요. 문제를 해결해서 더 이상 신경 쓰지 않아도 되게 하는 아이디어를 정말 좋아해요. 라이브러리를 만들어서 '좋아, 그 문제는 해결됐으니 이제 우리 시간을 더 잘 쓰는 다른 일로 넘어가자' 하는 거죠.

Jonathan: 그렇죠, 이해돼요. 제가 사람들에게 특히 좋아하는 질문이 있어요. 저는 IT 업계 전체로 보면 꽤 신입이고, 어릴 때부터 개발을 해 온 배경도 아니에요. 그래서 종종 눈에 띄는 게, IT 쪽 친구들에게 자주 듣는 얘기인데, 의견이 참 많다는 거예요. 사실인 것 같고요. 그래서 저희 팟캐스트에 나오는 분들에게 묻는 질문이 있는데, 'IT에서 목숨 걸고 지킬 만한 주장(the hill you would die on)'이 뭐냐는 거예요. 물론 농담 섞어서요. 어떤 마음가짐이나 의견이 있으면 '이건 내가 지킬 것이다' 하는 게 있어요? 뭐든 좋아요. 좋은 예로, 저희 메인테이너 중 한 명인 DJ가 있는데, 아실 수도 있어요. 그의 주장은 정말 핵심적인 대화의 역할이었어요. IT 분야에서 선의를 가지고 잘 짜인 대화를 나누는 거죠. 올바른 토대 위에서 이뤄지는, 건강하고 도전적인 질문이요. 다른 분이 뭐라고 했는지 생각해 보면, Unison의 Rebecca는 팀에 50명의 성실하고 근면한, 어쩌면 재능은 덜한 사람을 두는 게, 함께 일하기 힘든 천재 한 명보다 낫다고 했어요. 좋은 예시죠. 그리고 갑자기 질문을 던져서 좀 곤란하게 만들었네요. 여러 관점이 있으실 텐데, '아니, 이건 나는 굽히지 않겠다' 하는 게 있나요?

Brian: 음. 네. 처음 떠오른 게 camelCase 대 snake_case 같은 거였어요. 그런데 그걸로 목숨을 걸지는 모르겠어요. 그런 건...

Jonathan: 저는 못...

Brian: 네, 그래도 그런 것들은 시간이 지나면서 덜 고집하게 되는 것 같아요. 그런데 아까 말씀하신 더 높은 차원의 것들은 좋아요. 한번 꺼내 볼게요. 아쉽게도 편집을 하시니까 제 멈춤은 다 사라지겠네요, 그죠?

Jonathan: 적어도 계획은 그래요.

Brian: 네. Remote Retro라는 도구가 있어요. 여러 번 써 봤고 정말 추천해요. Elixir로 만들어져서 알게 됐는데, 그건 그렇고 아주 잘 설계됐다고 생각해요. 시간이 지나면서 점점 더 좋은 도구가 됐고요. 시작할 때 항상 'Prime directive'가 나오는데, 지금 보니 Norm Keith에게서 가져온 거네요. 여기 위키 페이지가 있으니 찾아보실 수 있어요. remote-retro.org에 가면 볼 수 있어요. Prime directive는 회고를 시작할 때 사람들을 올바른 마음가짐으로 이끌기 위해 읽는 건데, '우리가 무엇을 발견하든, 모든 사람이 그 당시 알고 있던 것과 자신의 기술과 능력, 가용한 자원, 그리고 당시 상황 속에서 최선을 다했다는 것을 이해하고 진심으로 믿는다'라는 거예요. 좋은 말이라고 생각해요. 비슷한 것 같은데, 항상... 아니, 하나 더 말할게요. 인터뷰가 하나 있었는데, 원하시면 링크를 쇼 노트에 넣어 드릴게요.

Jonathan: 꼭 참고할게요.

Brian: 네, 저는 이 글을 항상 추천해요. 찾기가 정말 어렵고, 지금은 좀 잊힌 것 같기도 한데, 미국 재향군인회, 그러니까 정부 부처의 관리자였던 분이 있었어요. 특히 의료 시스템을 담당했던 것 같아요. 그분이 항공우주 분야에서 온 사람인데, 인터뷰에서 한 얘기가, 항공우주에서는, 모든 곳이 완벽하진 않겠지만 그가 경험한 많은 곳에서는 사람을 탓하지 않고 과정을 탓한다는 거였어요. 뭔가 잘못되면 '내가 프로덕션에서 테이블을 지웠다'고 해도, 다행히 아무도 저를 탓하지 않았어요. '좋아, 이제 어떻게 하지? 프로덕션 콘솔에 들어가면 프롬프트가 빨간색으로 나오게 하자. 그러면 프로덕션에 있다는 게 확실해지니까.' 저는 개발 환경인 줄 알았거든요. 그래서 저는 과정을 탓하고 사람을 탓하지 않는 사무실에서 일한 게 운이 좋았어요. 정말 좋았어요. 그분이 의료 맥락에서도 그 얘기를 했어요. 간호사가 환자에게 잘못된 약을 줄 수도 있는데, 라벨이 헷갈리거나 뭔가 불편하게 되어 있으면 '그걸 고치자, 환자를 정말 신경 쓴다면 잘못되기 어려운 과정을 만들자'는 거죠. 그게 저한테는 아주 중요한 거예요.

Jonathan: 정말 멋져요. 쇼 노트에 꼭 넣을게요. 그게 애자일에서 나온 건가요, 애자일 방법론에 기반한 건가요? 아니면 좀 다른 건가요? 어떻게 생각하세요?

Brian: 좋은 질문이에요. 제가 받은 인상으로는, 항공우주 엔지니어링 쪽 일부에서 꽤 오래된 전통의 일부인 것 같았어요. 항공우주라면, 비행기나 로켓을 만든다면 '이건 반드시 작동해야 한다'는 일을 하는 거잖아요. 그리고 우주비행사든 승객이든 사람을 태우면, 작동할 가능성을 최대한 높여야 해요. 그러려면 자존심을 내려놓고 '그래서 뭘 해야 할까요?'를 묻는 거죠.

Jonathan: 네

Brian: 과정을 그대로 따르기만 하면 매번 최대한 잘 작동하게 하는 것, 그게 그 일부인 것 같아요.

Jonathan: Remote Retro를 찾아봤을 때 애자일 용어가 많이 보였거든요. 그래서 어딘가에서 바뀐 건가 싶었어요. 아무튼 정말 멋져요. 처음 들어봤어요. 제가 들어본 건 체크리스트에 관한 건데, 특히 의료와 항공우주 쪽이요. 조종사가 체크리스트를 하나하나 확인하고 거기서 벗어나지 않죠. 의사도 마찬가지고요. 정말 멋져요. Brian, 이제 슬슬 마무리해 볼게요. 오늘 저녁 마지막 질문이 있어요. 다음 주에 Exercism 커뮤니티를 위한 추천이 뭐예요? 한 가지 조언을 해 주신다면, 뭐든 좋아요. 동네 델리에서 콤부차를 마셔라, 아니면 북극해에서 달리기하고 수영을 해라, 뭐든요. Exercism 커뮤니티에 '이거 한번 해 보세요'라고 추천할 한 가지가 있다면, 이번 주엔 뭘까요?

Brian: 건배! 음. 제가 말하자면... 자기 능력 범위 안에서요. 모두에게 조언하기는 항상 어려우니까요. 저한테 큰 계기가 된 게 하나 있는데, 한번은 갑자기 두통이 심해서 응급실에 갔어요. 벼락 두통 같은 걸 수도 있어서 좀 심각할 수 있거든요. 그래서 가서 의사 선생님께 진찰을 받았고 다 괜찮았어요. 그런데 의사가 일반적인 질문을 하면서 '운동은 얼마나 하세요? 활동은 어때요?' 하고 물었어요. 저는 미국 사람이라 '글쎄요, 좀 걷긴 해요. 하루 평균 8000보 정도요'라고 했죠. 그랬더니 '일주일에 세 번, 45분씩 땀이 날 정도로 운동하셔야 해요'라고 하더라고요. 바로 시작하진 않았는데, 오륙 개월쯤 뒤에 달리기 습관이 생겼어요. 보통 일주일에 세 번, 때로는 두 번이었지만요. 그게 제 인생에서 꽤 큰 변화였어요. 많이 도움이 됐어요. 아주 하기 어려운 일이고, 저도 시작하기 정말 어려웠어요. 제가 한 방법은 이거였어요. '나가서 75%를 걷게 되더라도 그래, 그냥 그러자. 조금씩 늘려 가자' 하는 거였죠.

Jonathan: 좋아요. 그 얘기가 흥미로웠어요, 왜냐하면 저희가...

Brian: 그 얘기가 흥미로웠어요, 왜냐하면 저희가...

Jonathan: 아니요, 정말 멋져요. 코호트를 하면서 고민했던 것 중 하나가 사람들이 코딩 여정에서 성장하고 배우고 나아가면서 추진력을 얻도록 뭘 해 줄까였어요. 그중 하나가 그냥 나가서 해 보는 거였어요. 하루 10분이라도, 그냥 한번 해 보는 자리에 서 보는 거죠. 별로 나아가지 못해도, 안내문만 읽고 그날은 끝나도, 어떤 형태로든 나오기만 하면 큰 차이가 있어요. 정말 좋은 추천이에요. 실내에 앉아 있으면 너무 앉아 있게 되니까 저도 운동을 좀 시작해야겠다는 생각이 들어요. 듣고 계신 분들도 Brian의 조언을 따라 한번 달리러 나가 보세요. 그런데 스톡홀름은 앞으로 몇 주 동안 좀 더 추워질 거예요. 한겨울에도 계속 달리세요, 아니면 실내에서 달리세요?

Brian: 네, 계속 달려요. 그리고 일주일에 세 번, 하루 30~40분씩 나가려면, 가장 좋은 운동은 본인이 가장 즐기는 것이라고 말하고 싶어요. 달리기가 즐겁지 않으면 오래 못 하니까요. 그걸 먼저 말할게요. 겨울에는, 스톡홀름은 어둡기도 해서, 아내가 재귀반사 섬유가 들어간 모자를 사 줬어요. 그래서 안전하게 달릴 수 있고요. 안면 마스크와 귀마개도 챙겨서 써요. 아무튼 단단히 껴입어야 하지만, 추울 때는 오히려 좋기도 해요. 심박을 낮게 유지하면서도 운동 효과는 얻을 수 있으니까요. 네, 맞아요.

Jonathan: 아, 멋져요. Brian, 오늘 저녁 시간 내주셔서 정말 감사하다고 말하고 싶어요. 아마 긴 하루였을 거예요. 아이, 일, 새 강아지, 이런저런 것들로요. 시간 내주시고 저희와 이야기 나눠 주셔서 감사해요. 듣고 계신 분들을 위해, 쇼 노트는 아래 설명에 넣어 둘게요. 기회가 되면, 그리고 이걸 듣고 계신다면 Elixir 트랙을 한번 확인해 보세요. 그리고 **Brian **이 Elixir 트랙에서 멘토링을 하시는지는 모르겠지만, 혹시 멘토링을 하신다면 새로 들어와서 이것저것 해 보는 분들을 만나게 될지도 모르겠네요. Elixir에 대한 좋은 얘기를 많이 들었어요. 앞으로 지켜볼 만한 언어라고 생각해요. 좋은 저녁 보내세요, Brian. 녹음을 멈출 때까지 조금만 기다려 주세요. 함께해 주셔서 좋았고, Brian Underwood의 삶에 대한 통찰을 나눠 주셔서 감사해요. 들어주신 모든 분들 감사하고, 좋은 저녁 보내세요. 곧 또 봬요.