Dart 인턴의 하루
Dart 인턴의 하루
"Dart 선언 지점 가변성(declaration-site variance)"의 동반 게시물로, Google Dart 팀에서의 인턴 경험에 대해 들어보세요.
본문
"모르겠어요."
소프트웨어 엔지니어의 머릿속에는 이 세 단어가 매일 스쳐 지나가요. 엔지니어링 작업은 퍼즐과 문제로 이루어져 있어서, 무언가를 모른다는 것은 그 엔지니어가 성장할 여지가 있다는 또 하나의 신호일 뿐이에요. 하지만 지식이 부족하다는 것은 자기도 모르게 자기 의심을 불러일으킬 수도 있어요.
올가을 인턴십을 시작하기 전에 저는 프로그래밍 언어, 타입 시스템, 심지어 가변성(이게 제 프로젝트 전체였는데요)에 대해서도 잘 몰랐어요. 제가 알기로 가변성(variance)은 표준 편차를 구하기 위해 제곱근을 계산해야 할 값에 불과했어요. 프로그래밍 언어와 컴파일러는 대부분의 개발자를 현혹시키는 일종의 흑마법처럼 보였어요.
다행히도 제 매니저님은 마음을 읽는 사람이라서 제 기분을 이해하고 불안을 달래 주셨어요.
"솔직하게 말할게요. 이 프로젝트는 당신을 완전히 맹렬한 수영장으로 던져 넣을 거예요. 아직 아무것도 모르겠지만 괜찮아요. 나는 당신이 질문을 하길, 그것도 아주 많이 하길 바라니까요."라고 설명해 주셨어요.
배경 지식이 거의 없는 작업에 앞서서 뛰어드는 것은 무서운 일이었지만, 매니저님이 저를 지지해 주신다는 걸 알았어요. 매니저님은 저에게 시도할 자유와 실수할 자유를 주셨어요. 그게 저에게 큰 의미가 있었어요.
매니저님과의 그 짧은 대화가 여기서의 첫 달을 힘차게 시작하게 해 줬어요. 저는 시애틀 프리몬트(Fremont)에서 팀을 만났고, "variance"라는 깊은 미지의 세계에 몸을 던질 준비를 했어요. 그 내용은 Dart 선언 지점 가변성 기사에서 읽을 수 있어요.
저는 매니저님과 매주 가변성 부트캠프를 가졌고, 코드로 옮겨야 할 이론을 배웠어요. 제가 구현하게 될 가변성 기능의 제안서를 읽으면서, 프로젝트를 완료하는 데 필요한 일곱 단계에 압도되었던 기억이 나요. (1) 새 키워드 스캔 후 파싱, (2) kernel AST 수정, (3) 서브타이핑 알고리즘에서 가변성 지원, (4) 오류·경고 추가, (5) 상한·하한 계산 변경, (6) 타입 추론 규칙 변경, (7) 런타임 동작 변경 작업이었죠.
kernel(컴파일러의 중간 표현)과 서브타이핑 로직을 바꾸는 과정에서, 가변성 어노테이션을 직렬화·역직렬화해야 했어요. 런타임 동작은 스트레치 목표로 여겨졌지만, 그 전의 여섯 가지 작업조차 거의 이해하지 못했어요. 어디서 어떻게 시작해야 할지 몰랐어요.
하지만 점점 나아졌어요.
저는 매일 오전 9시에 근무를 시작했어요. 스크램블드 에그, 소시지, 케일, 오렌지 주스면 충분했죠. 그리고 사람들이 도대체 어떻게 최초의 컴파일러를 만들었을까 궁금하며 코드를 곁눈질할 준비를 했어요.
저는 서로 다른 컴포넌트들을 병렬로 작업하는 경우가 많았어요. 바쁘게 유지해 줬고, 목표를 정리하는 것도 즐거웠어요. 매일 아침 달성하고 싶은 것을 나열하는 새 문서를 만들고, 목표를 관리 가능한 작업으로 세분화했어요.
밤에는 덴마크 오르후스(Aarhus)의 Google 사무실이 활기차게 돌아갔어요. 덴마크의 몇몇 엔지니어와 함께 작업해야 한다는 걸 알았기 때문에, 저는 종종 시애틀 한밤중에 질문을 정리하고 마무리해서 보냈어요. 코드 리뷰 시간이 9시간 앞으로 당겨졌지만, 다행히 그 시차 덕분에 내 코드가 비판받기 전에 스스로 교정할 기회가 더 많아졌어요.
팀의 비판은 제가 내 코드를 판단하는 능력과, 서로 다른 구현의 트레이드오프를 숙고하는 능력을 키워줬어요. 리뷰어들은 제가 놓친 부분을 지적하고, variance가 무엇인지 그리고 어떻게 사용하는지에 대해 질문했어요. 저는 코드를 고치고 그 질문에 답하면서, 앞으로 같은 문제를 조심해야겠다고 다짐했어요. 더 중요하게는, 더 깊이 파고들어 스스로에게 물었어요. 그들은 어떻게 이 개선을 생각해 냈을까? 이로부터 고쳐진 코드 버전보다 더 무엇을 얻어갈 수 있을까? 모든 댓글에서 배우는 것이 저에게 중요했어요. 의미 없이 편리한 Done 버튼만 클릭하는 대신 말이죠.
저는 질문을 통해 배웠어요. 이빨을 악물고 이해가 안 되는 코드를 갈아내는 고집 센 소프트웨어 엔지니어가 되기와, 마지못해 그 코드베이스의 전문가를 꾀어 도움을 받기 사이에는 항상 미묘한 균형이 존재해요. 후자가 거의 항상 더 많은 시간을 아껴줬어요. 저는 꽤 많은 시간을 혼자 작업에 할애하고, 새 영역을 만날 때마다 메모하고 질문을 적은 다음, 2~3개의 질문과 확실한 장애물이 생겼을 때 다른 엔지니어를 찾아가는 방식을 선호했어요. 혼자서 3시간을 디버깅해야 할 문제를, 다른 사람에게 10분의 지도와 설명만으로 해결하는 게 훨씬 생산적이라는 걸 깨달았어요.
직장에서의 안전감도 생산성을 높여요.
저에게 안전감은 질문하기, 농담 던지기, 팀과 점심 먹기에서 나왔어요. 시계가 11시 30분으로 바뀌는 순간, 다음 30분은 따뜻한 음식과 밝은 얼굴로 가득 차리라는 걸 알았어요. 매일 저는 가장 정교한 이야기와 생각을 들었어요. 손가락이 여섯 개의 장점, 크리스마스 선물로 받은 삶은 랍스터, Factorio에서 서로 다른 두 파이프를 섞은 뒤의 몇 시간짜리 청소 등... 정말 온갖 이야기였죠. 제 팀은 제 실수와 성취를 모두 지지해 줬어요. 좋은 팀 덕분에 아침에 일어나 출근하는 게 훨씬 쉬워져요.
점심 전후의 시간도 마찬가지로 즐거웠어요. 저는 대부분의 시간을 코드를 읽고 새 개념을 이해하는 데 보냈어요. Dart 컴파일러는 크고 끊임없이 변하는 많은 컴포넌트로 이루어져 있어서, 몇 가지 다른 코드베이스에 뛰어들어야 했어요. 정적 분석을 담당하는 프론트엔드 팀과 런타임 동작을 관리하는 백엔드 팀에게 연락할 기회가 있다는 게 정말 좋았어요. 컴포넌트들이 어떻게 협력해서 Dart 언어의 새 기능을 만들어내는지 보는 건 놀라웠어요.
구현과 이론 사이의 간극이 제 프로젝트에서 가장 어려운 부분이었어요. 증명을 구체적인 코드로 굳힐 일은 매일 있는 게 아니죠. 가변성 작업을 하는 동안, 질문이 생길 때마다 이 간극이 표면에 드러났어요. 때로는 제 질문이 언어 제안서의 컴포넌트를 적절한 구현과 엮어내려고 했죠. 답을 찾으러 찾아간 사람들은 서브타이핑 알고리즘이 들어있는 파일을 알거나, 서브타이핑 변경이 할당 연산에 어떤 영향을 미치는지 알거나 했지만, 결코 둘 다는 알지 못했어요. 마치 합판 몇 조각과 결과물에 대한 예술가의 상상도로 나무집을 짓는 것 같았어요.
그래도 Dart 작업은 엄청나게 보람차고 재미있었어요. 저는 그 도전을 사랑했어요. 특히 variance 너머에도 배울 것이 아주 많다는 걸 알게 되면서 더욱 그랬어요. Dart는 그 언어를 사용하는 개발자들을 더 잘 지원하기 위해 성장하고 진화해 왔고, 여전히 그러해요. 저는 중요한 이슈가 떠오르고 즉각적인 주의가 필요할 때 팀이 정밀하게 맞물린 기계처럼 움직이는 걸 지켜봤어요. 팀이 과거의 실수를 되돌아보며 미래의 프로세스가 같은 실수를 반복하지 않도록 하는 이야기도 들었어요.
Dart 팀에서의 인턴십은 제 엔지니어링 능력, 커뮤니케이션 능력, 그리고 제 능력에 대한 자신감을 키워줬어요. 친근하면서도 아주 기능적인 팀의 중요성을 가르쳐 줬어요. 이론이 코드로 옮겨질 수 있는 여러 방법과, 그렇게 하기 위해 필요한 문제 해결 기법을 가르쳐 줬어요. 그리고 제 자신과 제가 하는 일에서 무엇을 소중히 여기는지에 대해 더 많이 알게 해 줬어요.
Dart, 고마워요. 다음에 또 만나요.