문제 해결을 통해 테크 리드가 되기까지

Jonathan: 자, 안녕하세요 여러분. 제 이름은 Jonathan이에요. 오늘 저녁 여러분의 진행을 맡게 되어 기뻐요. 오늘 방송에 아주 영광스럽게도 모신 게스트가 있는데요. Gabriel Nelle을 소개할게요. Gabriel은 Exercism의 핵심 기여자 중 한 명이에요. 특히 Go 트랙에서 아주 활발하게 활동해 왔는데, 자세한 이야기는 곧 본인이 직접 소개해 주실 거예요. 그런데 Gabriel, 정말 반가워요. 함께해 주셔서 감사하고, 오늘 방송을 듣는 모든 청취자만큼 즐거운 시간 보내시길 바라요. 자, Gabriel, 시작해 볼까요? 어디서 오셨는지, 그리고 어떻게 지금 계신 곳에 오게 됐는지 조금 이야기해 주세요.

Gabriel: 네. 안녕하세요. 저는 Gabriel이에요. 초대해 주셔서 감사해요. 저는 독일 남부 출신인데, 거기서 자랐고 지금도 그쪽에 살아요. 같은 동네는 아니지만 여전히 남부 독일이에요. 음, 저는 80년대 초반에 태어난 사람이라 81년생이에요. 이야기의 시작은 80년대 후반, 아버지가 첫 컴퓨터를 집에 가져오셨을 때인 것 같아요. 적어도 기술 이야기는 거기서 시작하죠.

Jonathan: 네.

Gabriel: MS-DOS가 설치되어 있었는데, 정확히 무슨 버전이었는지는 잘 모르겠어요. 아마 좀 오래된 버전이었을 거예요. 제 기억이 맞다면, 아버지가 그 컴퓨터를 집에 가져오신 건 회사에서 그냥 버린 물건이었거든요. 회사에 새 컴퓨터가 들어와서 아버지가 그걸 집에 가져올 수 있었던 거예요. 그게 컴퓨터에 대한 제 첫인상이었어요. MS-DOS요. 흥미롭고도 이상했죠.

Jonathan: 검은 화면 위의 그 선들, 색깔 있는 선들이요? 그게 꽤

Gabriel: 네, 그냥 검은 화면에 흰 글씨였어요. 거의 다 그런 식이었죠. 그리고 대부분 명령줄이었는데, 제가 처음 접한 게 그거였어요. 그다음에 아버지와 함께, 그러니까 90년, 1991년쯤에 아버지가 QBasic으로 첫 for문을 가르쳐 주셨어요. 저는 그때 열 살쯤이었어요. 그리고 단어 외우기도 있었어요. 아버지가 어휘 학습 프로그램을 사 주셨는데, QBasic 기반이었고 마우스로 클릭했던 것 같아요. 백 퍼센트 확실하진 않아요. 어쨌든 그 무렵이 제가 컴퓨터를 처음 만지기 시작한 시기였고, 몇 번이나 고장 내기도 했어요. 아버지가 몇 번 고쳐 주셔야 했죠. 그렇게 저는 이걸 배우는 데 확실히 관심이 많았어요. 그렇다고 제가 앉아서 "이걸 꼭 배워야지" 하고 결심한 건 아니었고, 그걸로 뭘 할 수 있는지 이해하는 게 정말 재미있었고 저를 끌어당겼어요.

Jonathan: 그런데 아버지께서는 컴퓨터 관련 일을 하셨나요? 아니면 그냥 회사 일을 하시다가 우연히 컴퓨터를 집에 가져오신 건가요? 아니면 집에 가져오신 특별한 이유가 있었나요? 컴퓨터 때문이었는지, 기술적인 이유였는지 궁금해요.

Gabriel: 네, 아버지는 원래 배운 게 전기 기사예요. 그런데 당시 Bosch에서 일하셨는데, 자동차용 새 칩이나 새로운 부품을 개발하는 전자 부서에서 일하셨어요. 그 부서에는 당연히 컴퓨터도 있었고, 아버지는 꽤 일찍부터 컴퓨터나 네트워크 프린터 같은 것들을 전부 담당하셨어요. 그렇게 컴퓨터 쪽으로 들어가신 거예요. 그곳에서 일이 돌아가게 하려면 필요한 모든 걸 사실상 아버지가 하셨죠. 부서의 다른 사람들 대부분처럼 박사 학위가 없었기 때문에 그런 일을 맡아 하셨고, 컴퓨터에 대해 많이 배우셨어요. 네.

Jonathan: 네. 좋아요. 아, 죄송해요, 제가 중간에 껴들었네요. 아까 컴퓨터를 가지고 놀다가 몇 번 고장 냈다고 하셨는데, 그게 컴퓨터와 하드웨어에 대한 첫 경험이었고요. 그다음엔 어떻게 됐나요? 그 시점부터 무슨 일이 있었고, 어떻게 발전해 나갔나요?

Gabriel: 그다음 큰 걸음은 제 컴퓨터를 갖게 된 거였어요. 아마 오륙 년쯤 뒤였을 거예요, 제가 좀 컸을 때요. 컴퓨터에 더 관심이 많아졌고, 학교에서도 컴퓨터 관련 수업을 좀 들었어요. 숙제도 컴퓨터로 쓰기 시작했고요. 그때가 이미 Word, MS Word 같은 게 나오던 시절이었죠. 그리고 어느 날 시작됐다고 할 수 있는데, 아버지는 항상 우리 교회를 위해 문헌 작업을 하셨어요. 우리는 아주 작은 교회에서 자랐고, 우리가 쓰던 문헌이 있었는데 아버지가 그 문헌을 디지털화하시거나 도와주셨어요. 처음에는 부업 프로젝트였는데, 나중에는 그 문헌을 담당하던 미국의 출판사에서 일하는, 제 첫 정규직이 됐어요. 잠깐만요, 저것 좀 봐 주시겠어요?

Jonathan: 네.

Gabriel: 간단히 말해 아버지가 저한테 이렇게 물으셨어요. "나한테 매크로가 잔뜩 있는데, 이걸 Euroscript로 작성했어. 그건 Word 이전 버전을 기반으로 한 거라고 볼 수 있어. 이제 Word로 옮기고 싶은데, 매크로를 전부 Word에서 쓸 수 있어야 해." 그래서 제가 "알았어요" 했죠. 그렇게 제가 Word 프로그래밍을 시작했어요. Visual Basic for Applications인데, 처음에는 매크로를 기록할 수 있었어요. 코드를 보고 무슨 일을 하는지 확인한 다음 개선할 수 있었고, 매크로를 그렇게 많이 개선해서 자동화할 수 있게 됐어요. 예전에는 커서를 여기 두고 키를 누르면 다음 몇 줄에서 뭔가가 실행되는 정도였는데, 나중에는 Word 문서 전체를 위에서 아래로 완전히 자동으로 처리하게 됐어요. 그게 계기가 되어 그 일을 위해 매크로를 정말 많이 작성했어요. 큰 반향이 있었고, 아버지에게 여가 시간에 이런 일을 맡긴 사람들이 "와, 대단하다. 더 하자, 점점 더 자동화하자"고 했어요. 네, 그렇게 시작하게 됐어요.

Jonathan: 그러니까 아버지의 시간을 많이 아껴 드린 거네요.

Gabriel: 네.

Jonathan: 그런 의미에서, 어린 나이에요.

Gabriel: 그렇게 말할 수 있겠네요. 그래서 Word에서 매크로를 쓰고, 나중에는 Excel로요. 작은 가게를 위한 Excel 기반 계산대 시스템을 만들었어요. 유기농 식품 같은 걸 파는 작은 가게였는데, 원래는 가격을 전부 적어 놓고 머릿속이나 종이에 계산했어요. 처음에는 그렇게 했죠. 그래서 바코드 스캔과 저울이 있는 시스템을 만들었어요. 물건을 올려서 무게를 재고 영수증을 받아서, 계산할 때 그걸 스캔하는 식이었죠. 전부 Excel 기반이었어요. 네, 그렇긴 한데 지금 같으면 분명 다르게 만들었을 거예요. Excel이 데이터베이스이자 동시에 인쇄기였거든요. 모든 걸 Excel 시트에서 서식을 잡고, 그게 영수증 프린터로 출력되는 식이었어요. 어쨌든 그래서 그게 제 커리어의 시작이었다고 할 수 있어요.

Jonathan: 그걸 다 하셨을 때 몇 살이었어요? 그리고 그다음에는 어떻게 이어졌나요? 대학 전이었나요, 고등학교 때쯤이었나요? 그 경험이 커리어 방향에 큰 영향을 줬나요?

Gabriel: 네, 전부 대학 전이었어요. 가게 시스템은 제가 20, 21살쯤일 때 만들었고, 그 무렵에 대체 복무도 했어요.

Jonathan: 네?

Gabriel: 매크로 작업은 열여섯 살쯤이었어요. 그 사이에 편지를 보낼 때 붙일 라벨을 인쇄하는, Access 기반 시스템도 만들었어요. 주소 같은 걸 인쇄하는 거였죠. 그리고 나서 대학 공부가 시작됐는데, 놀랍게도 저는 컴퓨터공학을 전공하지 않았어요.

Jonathan: 네.

Gabriel: 저는 수학과 독일어 교사가 되기 위해 공부했어요. 몇 살부터 몇 살까지였는지 계산해 볼게요. 10살에서 19, 20살까지요. 그 나이대 학생들을 가르치는 거였죠. 그러니까 5학년부터

Jonathan: 그러니까

Gabriel: 13학년까지요.

Jonathan: 그럼 커리어 방향이 정해지기 시작한 거네요. 그 결정은 무엇을 바탕으로 한 거였나요?

Gabriel: 사실 아마 프로그래밍 쪽으로 갔을 가능성도 컸어요. 그런데 대체 복무를 하면서 기술적인 것 말고도 훨씬 많은 걸 배웠어요. 요양원을 담당하는 작은 팀에 있었는데, 방이 대여섯 개쯤 있었어요. 여러 사람이 있었고 저는 주로 한 분을 담당했는데, 그분은 55, 60살쯤이었고 알츠하이머를 앓고 계셨어요. 그게 저에게 큰 인상을 남겼어요. 그 나이에 그런 상황을 마주하면, 스무 살인 저한테 60살은 나이 들어 보였지만, 그런 일이 누구에게나 일어날 수 있고 저한테도 일어날 수 있다는 게 분명해졌거든요. 그래서 삶의 사회적인 영역에 훨씬 더 관심을 갖게 됐고

Jonathan: 흥미롭네요.

Gabriel: 사회적인 커리어 경로에도요. 그게 사실, 그게 바로 제가 그때 교사가 되기로 한 이유예요. 그래서 저는 가르치는 일을 하고 싶었어요. 특히 학교에서 친구들을 도와주는 걸 정말 잘했어요. 그리고 수학은 제가 가장 잘하는 분야였고 항상 좋아했어요. 다른 사람이 실력을 키우도록 도와주는 걸 늘 좋아했고, 상대방이 갑자기 이해하는 순간, 눈빛에서 "아, 이제 알겠구나" 하는 걸 볼 때 정말 좋았어요. 그래서 저는 실제로 교사가 됐어요.

Jonathan: 아, 멋지네요. 그런데 아까 말씀하신 대체 복무, 그거요. 독일에서는 모든 학생이, 대학에 가기 전에 꼭 해야 하는 건가요? 독일 문화에서 그게 어떻게 자리 잡고 있나요?

Gabriel: 그때는 군대에 가는 것에 대한 대안이었어요. 9개월 군 복무를 하거나, 11개월 대체 복무를 하거나 둘 중 하나였죠. 그게 의무였어요.

Jonathan: 네.

Gabriel: 남자한테만 해당됐고, 여자에게는 아니었어요.

Jonathan: 독일에서는 지금도 그런가요?

Gabriel: 아니요, 지금은 그렇지 않아요. 아니에요.

Jonathan: 네. 스위스에서는 그렇다고 들었어요, 제 아내가 스위스 출신이거든요. 그래서 그런 제도가 여전히 남아 있는 거네요. 자, 이제 수학을 하셨고 교사가 되기 위해 공부하셨는데, 프로그래밍도 인생에서 상당히 큰 부분을 차지했잖아요. 그럼 언제쯤이었나요, 그러니까 "나는 지금 가르치는 일을 하고 있고, 이게 재미있지만, 그래도 프로그래밍이라는 부분이 여전히 살아 있다"고 느낀 순간이 있었나요? 가르치는 일과 프로그래밍, 이 둘은 어떻게 균형을 이뤘나요?

Gabriel: 제가 어떻게 프로그래밍으로 돌아왔는지 말이죠? 네.

Jonathan: 네

Gabriel: 네. 대학생 때 부업으로 기본적으로 두 가지를 했어요. 하나는 가르치는 일이었어요. 과외 기관에서 가르쳤고, 대학에서도 저학년, 주로 1, 2학기에 수학을 가르쳤어요. 동시에 IT 회사에서도 일했는데, 거기서는 주로 Access 기반이었어요.

Jonathan: 네.

Gabriel: 카셰어링, 그리고 직원들에게 차를 빌려주는 차량을 많이 보유한 회사들을 위한 하드웨어와 소프트웨어를 만드는 회사였어요. 거기서 저는 처음에 문서 작성 담당으로 시작했는데, 제가 프로그래밍도 할 수 있다는 걸 알게 되고는 금방 프로그래밍 쪽으로 옮겼어요. 그리고 상황이 크게 바뀐 건 대학의 마지막 부분, 그러니까 학교 실습을 반드시 나가야 하는 시기였는데, 6주를 나가야 하고 또 4주를 나가야 하는 그런 과정이었어요. 그리고 제 생각에는

Jonathan: 네.

Gabriel: 경험 많고 아주 헌신적인 선생님들과 이야기하면서 분명해졌어요. 시대가 많이 변했고 학생들도 많이 변했다는 걸요. 한 선생님은 항상 5, 6학년을 가르치셨는데, 제게 이렇게 말했어요. 5년 전에는 반에 문제가 있는 학생이 한 명이었는데, 부모님 이혼이나 가정 문제 같은 게 있었죠. 그런데 지금은 그런 학생이 50%가 넘는다고요.

Jonathan: 그렇군요.

Gabriel: 그게 10년, 15년 전 이야기였어요. 2006, 2007년쯤이었을 테니 15년 전이네요. 그만큼 세상이 많이 변했다는 거죠. 그리고 요즘 학생들은 그냥 배우려고 하지 않는다는 것도 아주 분명했어요. 그리고 교사는 항상 맨 뒤에 있어요. 전체에서 꼬리 같은 존재죠. 학부모와 교장, 그리고 학생들이 사실상 모두 교사의 주인인 셈이에요. 교사는 항상 마지막 지푸라기 같은 존재라고 할까요, 영어로 어떻게 표현해야 할지 모르겠지만요. 항상 모든 책임을 떠안아야 하는데 권리는 없는 사람이에요.

Jonathan: 행동할 권한이요. 네.

Gabriel: 네.

Jonathan: 그래서 결정에... 아, 죄송해요, 말을 끊었네요. 계속, 계속 하세요.

Gabriel: 그런 것들이 적어도 저를 많이 생각하게 했어요. 대학을 마친 뒤에는 그냥 다시 프로그래밍으로 흘러 들어갔어요. 제 친구 한 명이, 아버지에게 그 문헌 작업을 맡겼던 사람인데, 프로젝트 하나를 도와줄 수 있냐고 물었거든요. 처음에는 4주나 6주짜리로 생각했던 그 프로젝트가 2년 반, 3년 반짜리가 됐어요. 3년 반짜리 프로젝트요.

Jonathan: 스코프 크리프네요. 스코프 크리프가 진짜였어요.

Gabriel: 네. 처음에는 뭔가를 도와달라고 했어요. 그런데 그는 계속 미국에 있는 그 출판사 사람과 연락하고 있었고, 출판사는 항상 이렇게 말했어요. "이 문헌을 담는 공개 홈페이지를 만들고 싶다. 사람들이 책 전체를 온라인에서 읽을 수 있게 하고 싶다."

Jonathan: 오, 대단하네요.

Gabriel: 어느 순간 제가 친구한테 그냥 말했어요. 친구가 출판사 사람과 통화하고 있었는데, "나도 그거 해볼 만할 것 같아. 지금 딱히 할 일도 없고"라고 했더니 친구가 "오, Gabriel이 하겠대"라고 말했어요. 그렇게 시작됐어요.

Jonathan: 와.

Gabriel: 그렇게 프로젝트를 맡았고, 3년 반 동안 그 프로젝트를 했어요. 수천 권의 책을 온라인에 올렸죠. 문헌 라이브러리 전체를요.

Jonathan: 와.

Gabriel: 색인도요. 서로 다른 언어들이 연결되어 있어요. 네, 그 웹사이트는 아직 살아 있어요. egwwritings.org예요. 관심 있는 분은 한번 보세요. 새 디자인으로 바뀌었어요. 작년 12월쯤에 새 디자인으로 바뀐 걸 봤는데, 밑에 있는 코드는

Jonathan: 여전히 같아요.

Gabriel: 대부분 제 코드예요, 왜냐하면 알 수 있거든요. 대부분 JavaScript 기반이었으니까요.

Jonathan: 네.

Gabriel: 코드는 아주 비슷하게 생겼어요. 파일 구성은 달라졌지만 스타일은 여전히 같아요.

Jonathan: 링크를 보내 주세요. 그럼 쇼 노트에 알맞은 때에 올릴게요. 그런데 3년 반, 그러니까 3년 동안 이 프로젝트를 하셨고, 이 모든 걸 색인하셨잖아요. 그때 주로 쓰신 언어가 JavaScript였나요? 기술 환경은 어땠어요? 어떤 쪽에 집중하고 계셨나요?

Gabriel: 그게 Windows 기반 소프트웨어에서 벗어나는 큰 전환이었어요. 그전에는 Visual Basic과 Visual Basic .NET이었는데, 이제는 jQuery, JavaScript, 그리고 백엔드의 PHP뿐이었어요.

Jonathan: 네.

Gabriel: 연구를 할 때는 시급을 낮게 받기로 합의도 했어요.

Jonathan: 네.

Gabriel: 실제로 프로그래밍할 때의 3분의 1이었죠. 그 덕분에 일하면서 배울 수 있는 자유가 생겼어요. 네.

Jonathan: 멋지네요. 그러면 그다음은요, Exercism이요. 지금은 여러 가지 일을 하고 계시잖아요. Go가 주된 부분이라고 해도 될까요? 멘토링도 많이 하시고, Exercism의 Go 쪽에 참여해서 여러 가지를 도와주고 계시고요. 그건 언제부터 시작됐고, 왜 흥미로웠나요? 말씀해 주세요.

Gabriel: 네, 2016년이었어요. 큰 프로젝트 이후 첫 직장이었죠. 사실 그 프로젝트 끝무렵부터 Go로 옮겨 가기 시작했어요. 그 직장에서는 주로 PHP와 Python을 좀 했어요. 그런데 Go는 금방 제가 가장 좋아하는 언어가 됐어요. 단순함이 있기 때문이죠. 점점 더 많은 기능과 언어가 생겨나고, 그것들이 갈수록 복잡해지고 개발자의 부담만 커지는 세상에서 벗어나려는 거예요. 개발자는 어느 방식으로 할지 선택해야 하고, 다른 사람들이 하는 모든 방식도 이해해야 하니까요. 그런 부담이 가득한데 Go는 갑자기 고요함과, 다시 단순해지는 걸 가져왔어요. 그리고 그게 금방 제 최우선이 됐어요. 퇴사하기 반년쯤 전에 그 회사에서 프로토타입을 만들었는데, 회사가 Go로 전환하고 싶어 했거든요. 물론 처음에는 그 언어에서 할 수 없는 것들에 부딪히고, 왜 그렇게 하는 게 말이 안 되는지, 왜 다른 방식이 더 나은지 이해하게 되는 초기 과정이 있었어요. 저는 그런 걸 배우는 데 정말 관심이 많았어요. 그래서 Go Time 팟캐스트를 듣기 시작했어요. Changelog에서 만든 거예요.

Jonathan: 네.

Gabriel: 그리고 Katrina Owen이 그 팟캐스트에 두 번인가 나왔어요. 적어도 두 번은 들었던 것 같아요. 네. 그렇게 Exercism을 찾아보기 시작했어요. 2017년에 Exercism에 가입한 것 같은데, 확실하진 않아서 확인해 봐야 해요.

Jonathan: 그럴 것 같아요. 맞나요?

Gabriel: 네, 어쩌면 아직 버전 1이었을지도 몰라요. 처음에는 피드백을 거의 못 받았거든요. 연습 문제 몇 개를 풀었는데 피드백을 전혀 못 받았어요. 다른 사람에게 피드백을 줄 수는 있었고 실제로 줬어요. 그런데 저는 피드백을 못 받았죠. 제대로 피드백을 받을 수 있는 절차가 없었어요. 하고 싶으면 하고, 하기 싫으면 그냥 놔두는 식이었어요. 네. 그게 버전 1이었던 것 같아요, 맞죠?

Jonathan: 그럴 것 같아요. 버전 1에서 버전 3까지 꽤 많은 변화가 있었으니까요.

Gabriel: 네. 맞아요.

Jonathan: 버전 1은 피드백이 거의 없었고, 버전 2는 엄청난 양의 피드백이 필요했고, 버전 3은 어딘가 중간쯤에 자리 잡았어요. 조금 적은 쪽일 수도 있지만요. 그런데 버전 3을 만드는 데 참여하셨나요? 어떤 식으로 참여하셨어요? 제가 그 부분을 정확히 모르는데, 알고 싶어요.

Gabriel: 잠깐 한 걸음 뒤로 가도 될까요. Katrina의 두 번째 인터뷰를 듣고 Exercism에 다시 들어왔어요.

Jonathan: 네.

Gabriel: 그때가 버전 2가 있던 시기였어요. 해야 할 일이 많았고 피드백도 많이 필요했죠. 저는 거기에 뛰어들었고, 피드백을 주는 게 정말 좋았어요.

Jonathan: 네.

Gabriel: 그래서 이걸 어떻게 하면 더 빠르게 할 수 있을지 생각하기 시작했어요. 특히 첫 연습 문제들에서는 같은 답변을 계속 반복해서 하게 된다는 걸 금방 깨달았거든요.

Jonathan: 네.

Gabriel: 그리고 물론 어떤 때는 이 두 가지 문제가, 어떤 때는 이 문제가, 또 다른 문제가 있기도 했어요. 그래서 기본적으로 이걸 최적화하기 시작했어요. 정적 분석을 사용하는 작은 Go 프로그램을 쓰기 시작했는데, 정적 분석을 해 보고 싶었거든요. 전에는 해 본 적이 없어서 알고 싶었어요. 어쨌든 해 보고 싶었고 좋은 생각처럼 보였어요. 코드가 늘 아주 흔하거나 아주 비슷했으니까요. 연습 문제의 풀이는, 특히 첫 문제들은 아주 비슷해요. 그렇게 정적 분석에 들어가게 됐고, 코드에서 여러 패턴을 찾아서 자동으로 답변 블록이나 미리 정의된 블록을 답변에 추가했어요. 처음에는 로컬에서 시작했고, 그렇게 일주일에 100개, 200개쯤 처리할 수 있었어요. 그것도 전업이 아니라 직장 일과 병행하면서요. 그러다 알려지기 시작했는데, Pitfield가 첫 번째였던 것 같아요. John Arun이 본명인 것 같고요. 그 사람이 처음으로 "와, 이거 대단하다. 정말 훌륭하다"고 했어요. 그렇게 제가 한 일과 정적 분석이 알려지기 시작했어요. 그게 버전 3에서 큰 부분이었다고 생각해요. 우리는 이런 도구, 그러니까 정적 분석이나 코드를 자동으로 검사하고 자동으로 피드백을 주는 도구를 통해 튜터의 일을 줄일 방법을 생각하기 시작했어요. 멘토가 아예 관여하지 않아도 완전히 자동으로요. 그리고 멘토를 보면, 멘토가 있긴 하지만 그 일을 감당하기에 충분하지 않다는 게 분명했어요. 멘토링 도구도 있었고, 많은 멘토가 번아웃되어 사라지는 것도 봤어요. 너무 많았어요. 많은 멘토에게 부담이 너무 컸죠. 멘토 한 명이 500개 이상의 풀이를 멘토링해야 했고, 어떤 때는 한 달 이상 대기하는 경우도 있었어요. 그러다 보니 학생들도 어느 순간 떠나가게 되는 상황이었죠. 네.

Jonathan: 음. 며칠 전에 Jeremy가 하는 말이 재미있었어요. 제출되는 모든 풀이 중에 75% 정도가 완전히 독특하다고 하더라고요. 저도 그게 신기했어요. Hello World 연습 문제 같은 걸 보면 아주 단순하니까 분명 정형화된 패턴이 있을 텐데 말이죠. 그런데 사람들은 온갖 다양한 걸 시도한다고 하더라고요. 그리고 그 교차점이 재미있어요. 코딩이 더 인기를 얻고 개발과 프로그래밍을 시작하는 사람이 많아지면, 자동화가 언제부터 개발자의 역할을 없애기 시작할까 궁금해지잖아요. 저는 잘 모르겠어요, 정말 그렇게 될지는 모르겠어요. 아직 필요한 게 너무 많다고 생각해요. 그런데 Exercism에서는 최근에 멘토링을 크게 밀고 있는 게 정말 흥미로워요. 말씀하신 것처럼, 계속 반복해서 해 줘야 하는 그런 가르침을 사람들이 감당할 수 있는 방식으로 정리하는 거니까요. 동시에, 그게 정말 사람의 상호작용, 콘텐츠를 함께 다뤄 줄 사람이 필요한 영역으로 넘어가는 건지도 궁금하고요. 이 부분에 대한 생각이 있으신지 모르겠지만, 지금 시점에서 흥미로운 영역이라고 생각해요.

Gabriel: 네, 개발자가 곧 대체되지는 않을 거라고 생각해요. 아직 꽤 오래 걸릴 거예요. 개발, 일반적인 애플리케이션, 그리고 멘토링에서도요. 정적 분석과 자동 멘토링, 그리고 Exercism의 자동 멘토링 전반은 큰 도움이 될 수 있어요. 하지만 진짜 멘토링에는 멘토가 필요하다고 생각해요. 예를 들어 제가 멘토링하는 사람이 있는데, 두세 달에 한 번씩 통화하고, 때로는 더 자주 해요. 그 사람의 커리어를 멘토링하는 셈이죠. 기술적으로도 아주 깊이 들어가기도 하지만, 풀이를 보고 개선할 점을 알려주는 것과는 완전히 다른 방식의 멘토링이에요. 기존 멘토가 여전히, 그리고 앞으로도 분명히 필요한 이유가 그거라고 생각해요. 그게 우리가 집중할 수 있는 부분이고요. 반면에 풀이에 대해서는 멘토를 완전히 대체할 수 없다고 생각하고, 그래서도 안 된다고 봐요. 많은 걸 자동화할 수 있지만, 멘토는 방향을 짚어 줄 수 있는 사람이에요. 지금 어떤 문제로 어려움을 겪는지 보고, "이것과 이것을 이해해 보세요"라고 말해 줄 수 있죠. 그냥 "네 코드를 이렇게 고쳐야 해요"가 아니라요.

Jonathan: 네, 맞아요.

Gabriel: 그리고 솔직히 말하면 Exercism에서 멘토링이 다시 더 많아졌으면 좋겠어요. 그래서 우리가 다시 그렇게 해야 하지 않을까 생각하는데

Jonathan: 사람과 직접 상호작용하는 거 말씀이세요?

Gabriel: 네. 예전에는 10개 연습 문제를 통과하는 경로가 있었는데, 적어도 10개였고, 멘토링을 받아야만 다음으로 넘어갈 수 있었어요.

Jonathan: 네.

Gabriel: 지금 있는 자동화 덕분에 그걸 다시 켤 수도 있을 것 같아요. 지금은 아니더라도 나중에는요. 그러면 좋겠어요.

Jonathan: 그럼요, 그건 커뮤니티 콜에서 꼭 꺼내야겠어요. 다시 주목할 만한 주제로 가져오면 좋을 것 같아요. 자, Gabriel, 우리가 자주 하는 질문 중에 하나가 있는데, 아까 미리 말씀드린 그 질문은 아니고요. 제가 즐겨 하는 질문 중 하나인데, 항상 재미있고 사람마다 달라서요. 프로그래밍이 어느 순간 "딱" 하고 이해된 적이 있나요? 갑자기 모든 게 이해되는 경험을 했다는 사람들이 있거든요. 저는 자주 하는 이야기가 있어요. 제가 학교에서 화학을 배울 때 얘기를 예로 들어 볼게요. 제가 다닌 영국에서는 시험이 있어요. 그래서 3년 전부터 그 시험을 향해 모든 게 이어져요. 3년 동안 공부하고 마지막 시험으로 이어지는 거예요. 모든 과목이 그렇고, 그중 하나가 당연히 화학이었어요. 저는 3년 내내 화학을 전혀 몰랐어요. 도저히 이해가 안 됐죠. 그런데 시험 일주일 전에 갑자기 퍼즐이 맞춰지는 느낌이었어요. "아, 이제 알겠다" 하는 순간이 온 거예요. 그러고는 "이런, 주기율표만 있으면 모든 걸 알 수 있구나. 주기율표의 숫자만 알면 이것도 저것도 다 이해할 수 있구나" 싶었어요. 그때 모든 게 정말 단순해졌어요. 프로그래밍에서도 그런 순간이 있었나요? 아니면 자연스럽게 이해가 됐나요? 그런 순간이 있었다면 언제였나요?

Gabriel: 그렇게 확실한 순간이 있었는지는 잘 모르겠어요. Visual Basic for Applications로 매크로를 녹화하고 아주 일찍부터 코드를 들여다본 게 큰 도움이 됐다고 생각해요. 지금도 그런 게 있는지는 모르겠어요. Word에서 여전히 할 수 있을 거예요. 그런데 이렇게 녹화하고 나서 코드를 보고 그렇게 배울 수 있는 경우는 흔치 않아요. 처음에 많이 헤맸기 때문에 그게 저를 훨씬 수월하게 해 줬어요. 제가 "아, 이해했다"라기보다는 "내가 지금 제대로 하고 있는 건가"를 깨달은 순간이 하나 있는데, 학생 때 그 회사에 들어갔을 때였어요. 다른 개발자와 함께 일한 게 사실상 처음이었어요. 그전에는 항상 혼자였고 모든 걸 다 해야 했어요. 그리고 항상 큰 의문이 있었죠. "보통 이렇게 하나? 이상한데. 복잡한데. 작동은 하는 것 같은데, 이게 맞는 건가?" 그런 의문이 그 회사에 들어가서 일하기 시작하면서 어느 정도 해결됐어요. 배워야 할 게 정말 많았고 많이 배웠어요. 예를 들어 Access 레코드셋은 전에는 제대로 이해하지 못했어요. 써 보긴 했지만

Jonathan: 네.

Gabriel: 네, 작동은 했어요.

Jonathan: 네. 뭔가

Gabriel: 그러다 정말 이해하게 됐어요. 그게 제가 "딱" 이해한 지점이었을지도 몰라요. 동료가 있었는데 그분이 설명해 줬고, 어느 날 갑자기 어떻게 동작하는지 이해가 됐어요.

Jonathan: 네.

Gabriel: 어떻게 동작하도록 만들어졌는지, 어떻게 올바르게 쓰는지 같은 것들이요. 그래서 그게 그런 순간 중 하나였을 거예요. 그런데 그런 순간은 일을 하면서 아주 자주 찾아와요. 딱 하나의 순간이 있는 게 아니라, 어쩌면 그게 첫 번째 지점이었겠죠. Go에서도 "아, 이래서 이렇게 되어 있구나" 하고 깨닫는 곳이 아주 많아요. 왜 그렇게 되어 있는지, 어떻게 쓰는 게 맞는지요. 예를 들어 컨텍스트 같은 거요.

Jonathan: 네.

Gabriel: 네. 예를 들어 컨텍스트는 1.6이나 1.7쯤에 추가됐던 것 같은데, 정확하진 않아요. 그 무렵에 저는 컨텍스트를 보지 않았어요. 솔직히 처음에는 별로 필요하지 않았거든요. 그러다 밋업 같은 자리에 갔는데, 누군가 컨텍스트에 대해, 어떻게 쓰는지 같은 걸 발표하는 걸 봤어요. 그리고 "한번 봐야겠다"는 생각이 들었죠.

Jonathan: 네.

Gabriel: 그래도 실제로 들여다보고 왜 필요한지 이해하기까지는 몇 달이 더 걸렸어요. 예를 들어 close channel 같은 건데, 인터넷에서 아직도 고루틴을 close channel로 닫으라고 하는 사람들이 많다는 거 아세요? 그러면 안 되는데요. 컨텍스트가 바로 그걸 위한 거예요. 컨텍스트를 쓰고, 컨텍스트를 취소하면, 그걸로 고루틴을 끝낼 수 있어요. 닫힌 채널을 쓰는 건 컨텍스트가 내부에서 하는 일을 직접 수동으로 하는 셈이고, 피해야 할 함정이 아주 많아요. 그래서 보통은 사람들이 잘못 쓰게 되죠.

Jonathan: 예전에 라이브 스트리밍에서 그런 얘기를 하셨던 것 같아요. 기억이 나요, 그냥 컨텍스트를 쓰라고 하셨던 것 같은데, 왜냐하면

Gabriel: 네.

Jonathan: 아주 타당하니까요.

Gabriel: 제가 그 얘기를 했던 게 기억나네요.

Jonathan: 네. 그런데 과거에 사람들을 멘토링하셨을 때, 어떤 점이 있었나요? 뭔가를 빨리 습득하는 사람들의 행동이나 특징을 짚어 낼 수 있나요? 그런 사람들이 더 빨리, 더 효과적으로 배우기 위해 스스로를 어떻게 준비시키는지요? 아니면 멘토링한 사람들이 대부분 자연스럽게 그런 식으로 참여하는 편인가요? 아니면 "와, 이 사람들은 뭔가를 하는구나, 스스로를 가속하는 방법을 아는구나" 싶은 사람이 있었나요?

Gabriel: 다른 사람에 대해서는 잘 모르겠어요. 제 자신에 대해서는 확실히 말할 수 있어요. 저는 부모님께 배웠다고 생각해요. 부모님은 스스로 많은 걸 익혔고, 저도 그분들에게 스스로 배우는 법을 배웠어요. 그래서 프로그래밍도 완전히 혼자 배웠어요. 처음에는 아버지가 있었고, 학교에서도 몇 가지가 있었지만요. 학교의 윗 학년에서는 사실 저도, 우리도, 거의 모두가 선생님보다 나았어요. 그래서 제대로 배우는 건 없었고, 서로에게 배우는 쪽이었어요. 그런데

Jonathan: 네.

Gabriel: 전반적으로 저는 모든 걸 혼자 배웠어요. 프로그래밍에서는 그게 필요하다고 생각해요. 전에 본 적 없는 것들을 계속 파고들어야 하니까요. 잘 모르는 것들을 찾아서 읽어야 하죠. 뭐라고 해야 할까요, 이런 능력이요. 어떤 걸 파고들어 스스로 배우는 능력이 프로그래밍 학습에서는 핵심이라고 생각해요. 물론 그걸 알려 주는 사람을 찾으면 훨씬 빨리 배울 수 있어요. 그러니까 멘토를 찾지 말라거나 Exercism에 가지 말라는 건 아니에요. 그건 훨씬 빠르게 성장하도록 도와주죠. 그래도 결국은 그런 거예요. 제 생각은 그렇습니다.

Jonathan: 제가 보기에는 문제를 실제로 해결하려고 하면서 배우신 것 같아요. 매크로를 만들어서 더 효율적으로 하려는 것이든, 그게 삶에서 반복된 핵심 주제였다는 생각이 들어요. 그리고 그건 Exercism이 사람들이 실제로 뭔가를 할 수 있도록 돕는 방식과 많이 맞닿아 있는 것 같아요.

Gabriel: 네. 맞아요.

Jonathan: 네, 정말 멋지네요. 자, Gabriel, 시간이 얼마 남지 않았는데요, 마지막으로 두 가지가 있어요. 질문은 아니고요. 하나는 질문이고, 의견을 하나 공유해 달라고 부탁드릴 거예요. 그리고 나머지 하나는, 이것도 일종의 의견이 될 수 있는데, 이번 주에 꼭 해 봐야 할 걸 커뮤니티에 추천해 달라고 부탁드릴게요. 그런데 먼저, 우리는 인터뷰했던 많은 분과 이야기를 나눴고, 이 팟캐스트나 라이브 스트림을 조금이라도 들어 보셨다면 아시겠지만, 보통 라이브 스트림 끝자락에 큰 질문 하나를 던져요. 그 질문은 "기술 분야에서 당신이 목숨을 걸고라도 주장하고 싶은 것은 무엇인가요?"예요. 아주 확고하게 믿는 의견 하나가 뭔가요? 물론 이유를 잘 대야 해요. 그냥 "이게 제 의견이에요" 하고 끝낼 수는 없고, 스스로를 변호할 수 있어야 하죠. 아무리 강렬해도, 아무리 사소해도 좋아요. 어떤가요?

Gabriel: 속담 같은 건데요, Go 커뮤니티에서 누가 한 말이 있어요. "지루한 코드가 영리한 코드보다 낫다"요.

Jonathan: 좋네요. 무슨 뜻인가요?

Gabriel: 무슨 뜻이냐면요, 기본적으로 Go 철학의 큰 부분, 단순함과 가독성에 관한 걸 요약한 말이에요. 그래서 Go 코드를 보다가 "와, 이거 영리하다" 싶으면 사실 나쁜 코드예요. 그 코드를 쓴 사람이 아주 똑똑하고 아주 영리하게 짠 코드라도요. 그리고 가끔은, Go의 단순함과 관용구를 정말 잘 따르면, 코드베이스 전체에서 "이 코드 좀 봐, 얼마나 잘 짰는지 봐" 하고 가리킬 만한 코드가 없어요. 모든 코드가 사실 지루하고 아주 단순하니까요. 그리고 코드를 보는 사람마다 "이게 뭐가 그렇게 특별한데?"라고 하죠. 네, 그런데 핵심은, 좋은 프로그래머이기 때문에 그 단순함에 도달했다는 거예요. 그리고 그건 반복의 과정이에요. 복잡한 코드는 쓰기가 아주 쉬워요. 단순한 코드는 어렵죠. 먼저 머릿속에서 문제를 단순하게 만들어야 하고, 그다음 코드를 올바르게 쓰고, 그것을 반복해서 단순하게 다듬어야 하니까요. 훨씬 긴 과정이고, 복잡한 코드를 쓰는 것보다 훨씬 뛰어난 개발자가 필요해요. 복잡한 코드는 보기에도 이해하기 어렵고, 읽기 어렵고, 유지보수하기 어렵고, 바꾸기도 어려워요.

Jonathan: 결국 끊임없는 트레이드오프죠? 저는 IT 분야에 들어온 지 3년밖에 안 됐고, 개발 쪽에서 온 게 아니라 제품 쪽, 그러니까 더 비즈니스 관점에서 왔어요. 그런데 정말 흥미로웠던 건, 모든 게 트레이드오프라는 게 점점 더 분명해졌다는 거예요. 단순한 코드 대 복잡한 코드의 트레이드오프처럼요. 복잡한 코드는 나중에 더 다루기 힘들고 까다로워질 수 있고, 단순한 코드는 처음에 시간이 더 걸리고 더 많은 에너지와 노력이 필요하죠. 그게 항상 이루어지는 트레이드오프예요. 그래서, 이 부분에 대해 어떻게 생각하시는지 모르겠지만, 저는 그 단순함 쪽이 정말 와닿아요. 대학 때 한 친구가 있었는데, 과제 에세이를 항상 두 페이지로만 썼대요. 모든 걸 두 페이지에 담아낼 수 있어서 최고 점수를 받았죠. 그래서 단순함이라는 개념과 맞닿아 있다고 생각해요. 단순한 코드를 쓰는 건 정말 어려워요. 그냥 코딩만이 아니라 명확한 사고가 필요하니까요. 그러니까 그건 지킬 만한 주장이고, 잘 풀어서 말씀해 주셨어요.

Gabriel: 아, 어려운 질문이네요. 뭐든 좋다고 하셨으니 두 가지를 드려도 될까요?

Jonathan: 네, 두 개 하셔도 돼요.

Gabriel: 네. 하나는요. 저는 사실 채식주의자예요. 채식으로 자랐고 고기를 먹어 본 적이 없어요. 사실 비건으로 자랐어요, 어린 시절과 청소년기의 대부분을요. 그러니 유제품 없이 일주일을 보내 보세요. 그게 하나고요. 다른 하나는, 일주일 안에 할 수 있을지는 모르겠지만, 좋은 개발자라면 할 수 있어요. 여러 서비스 사이에서 공유되는 메모리, 같은 서비스든 여러 서비스든 공유 메모리를 만들어 보는 게 아주 흥미롭고 해 볼 만해요. raft 프로토콜을 써서 공유 메모리를 구현해 보세요. 라이브러리를 써도 되고, raft 자체를 구현할 필요는 없어요. 그런데

Jonathan: raft요. 링크를 보내 주셔야 제가 아래에 올릴 수 있어요. 그럼 이게 Gabriel의 도전, 음, "이번 주 Gabriel의 도전"이라고 부르는 게 낫겠네요. 추천이라기보다는요. 어쩌면 우리는

Gabriel: 네. 해 볼 만한 것에 가깝죠.

Jonathan: 도전 과제를 하나 내주시는 거네요. 재미있겠어요. 그러니까 고기 제품을 전혀 먹지 않는 한 주, 어떻게 되는지 보자, 그리고 공유 메모리 서버를 만들어 보자. 뭐라고 하셨죠? 서비스, 공유

Gabriel: 네, 인메모리 키-값이라고 부르면 되겠네요.

Jonathan: 네.

Gabriel: 여러 서비스든, 하나의 데이터베이스든, 하나의 서비스든요. 네.

Jonathan: 좋아요. 그건

Gabriel: 데이터베이스가 내부에서 어떻게 동작하는지 많이 가르쳐 주거든요. 특히 공유되는 모델들, 그러니까 잘 모르겠지만요. Cassandra나 ScyllaDB 같은 거요, ScyllaDB 아시는지 모르겠네요. Cassandra 같은 건데 C++로 되어 있고, 요즘은 raft 프로토콜로 바꾸고 있어요. 아니면 키-값 데이터베이스요. 공유되는 건 etcd인데, 아, 데이터베이스는 아니고요. 키-값 저장소예요. 음, Degraf Beja의 Be degraff이에요. 그것도 내부적으로 raft를 써서 데이터를 분산할 거예요. 확실하진 않아요, 다시 찾아봐야 해요. 그런데 이걸 쓰는 데이터베이스가 많아요. 분산 시스템이요. 분산 시스템은 우리 현대의 큰 도전 과제라고 할 수 있어요. 지금 해결해 나가는 중이지만 아직 넘어야 할 과제가 많아요. 그런 관점으로 생각할 수 있으면 항상 좋아요, 그러면 많은 가능성이 열리니까요.

Jonathan: 네.

Gabriel: 필요하다면요. 지난 회사에서 저도 그 길로 가고 있었어요. 여러 서비스 사이에 동시에 공유 메모리를 두는 거요. 네.

Jonathan: 어쩌면 이걸 마스터클래스로 기획해야겠네요. 사람들이 몇 주 동안 도전해 볼 수 있게요. 그럼 Gabriel,

Gabriel: 그게, 그게 마스터 클래스죠.

Jonathan: 네,

Gabriel: Exercism을 다 끝내고, 모든 연습 문제를 다 풀었을 때요.

Jonathan: 그게 큰 과제예요, 큰 과제. 모든 걸 하나로 묶어 주죠. Gabriel, 시간 내주셔서 정말 감사해요. 오늘 저녁 이야기 나눠서 정말 즐거웠어요. 녹음을 마친 뒤에 잠깐 남아 주셔도 되고요, 짧게요. 정말 감사하다는 말씀을 드리고 싶고, Exercism에 쏟아 주신 모든 것에 정말 감사해요. 우리뿐만 아니라 더 넓은 곳에서 하시는 모든 멘토링과 사람들이 더 나은 코드를 쓰도록 돕는 일까지요. 어디서나 큰 감사를 받고 있을 거라고 확신해요. 시간 내주셔서 감사합니다. Gabriel에게 연락해 보세요. Exercism에 계시다면 메시지를 보내고 멘토링을 요청해 보세요. Gabriel과 좋은 시간 보내실 거예요. 좋습니다.

Gabriel: 정말 감사합니다.

Jonathan: 녹음을 마치고요. 네, 아니, 함께해 주셔서 감사해요. 곧 어딘가의 플랫폼에서 뵐게요.

Gabriel: 감사합니다.