이 글은 Shane Tomlinson와 Robert Nyman [Editor]이 쓴 How can we write better software? – Interview series, part 1 with Fernando Jimenez Moreno의 한국어 번역본입니다.

코드를 보면서 “WTF(이런 젠장)”이라고 중얼거려 본 적 있나요? 저도 그런 적 있습니다. 보통 제 자신의 코드를 보면서 그럽니다.

저는 지금까지 일 해오면서 자랑할 수 있는 코드를 만들려고 노력했습니다. “제대로 동작하는” 소프트웨어를 만드는 것은 어려운 일입니다. 그런데 제대로 동작하면서 동시에 버그 없고, 읽기 쉽고, 확장하기 쉽고, 유지보수하기 쉽고, 안전한 소프트웨어를 만드는 것은 위대한 일입니다.

운 좋게도, 저는 업계 최고의 개발팀, QA팀, 보안팀으로 구성된 커뮤니티에 속해있습니다. 모질리안(Mozillians)들은 웹메이커(Webmaker), MDN, 파이어폭스, 파이어폭스OS 같은 프로젝트들을 통해 수없이 스스로를 증명해왔습니다. 모질라 프로젝트들은 복잡하고, 규모가 클 뿐 아니라, 오랜 시간 동안 많은 사람들이 참여해서 개발한 것들입니다.

우리 커뮤니티는 놀랍고, 재능이 넘쳐나고, 배울 것이 많습니다.

인터뷰와 피드백

이것은 제가 견습생 입장에서 모질라의 최고 엔지니어들을 청해 만든 첫 인터뷰 시리즈입니다.

“개발자로서 우리는 어떻게 해야 좀 더 멋진 소프트웨어를 만들 수 있을까요?”

수백만명의 사람들에게 소프트웨어를 전달하는 일은 단지 코드를 만드는 것만으로 끝나는 일이 아닙니다. 그렇기 때문에 다양한 측면에서 이 질문(멋진 소프트웨어를 만드는 방법)에 접근하려고 합니다. QA, 보안, 개발 등 모든 측면을 살펴볼 것입니다.

이 글의 대상 청중은 소프트웨어를 만드는 사람이며, 다루는 언어나 경험 수준은 상관 없습니다. 이 글을 읽는 당신이 곧 대상 청중입니다! 대부분이 개념적 질문들이기 때문에 어떤 언어에도 일반적으로 적용됩니다. 극히 일부 질문들만이 특정 도구나 특정 언어에 한정됩니다.

질문

인터뷰는 다음과 같은 질문들로 구성됩니다.

• 다른 개발자들은 높은 품질의 유지보수가 쉬운 소프트웨어를 만들기 위해 어떻게 노력하나요?
• “높은 품질의 유지보수가 쉬운 소프트웨어”란 무엇인가요?
• 어떤 프로세스/표준/도구를 사용하나요?
• 다른 개발자들은 코드를 어떻게 리뷰 하나요?
• 개발팀/보안팀/QA팀은 서로를 지원하기 위해 어떻게 협력하나요?
• 보안(security)과 관련된 문제에는 어떤 것이 있나요? 다른 개발자들은 코드를 리뷰할 때 무엇을 살펴보나요?
• QA에 관련된 문제에는 어떤 것이 있나요? 다른 개발자들은 개발을 마무리하고 릴리즈할 때 무엇을 살펴보나요?
• 나는 개발자로서 멋진 소프트웨어를 작성하고 전체 프로세스에 기여하기 위해 무엇을 해야 하나요?

기사 마다 한개 내지 두개의 인터뷰를 요약해서 게재할 것입니다. 각 인터뷰 말미에 대상 인물에 대한 짧은 소개를 곁들일 것입니다.

인터뷰 내용을 녹음한 경우에는 녹음 대본을 링크할 것입니다. 이메일을 통해 인터뷰한 경우에는 원본 이메일을 링크할 것입니다.

그럼, 첫번째 인터뷰입니다!

Fernando Jimenez Moreno를 소개합니다

첫번째 인터뷰 상대는 Fernando Jimenez Moreno 입니다.그는 텔레포니카(Telefonica) 소속의 파이어폭스OS 개발자입니다. 필자는 작년 가을에 Fernando와 함께 일할 기회가 있었습니다. 당시 우리는 파이어폭스의 계정 시스템을 파이어폭스OS에 통합시키는 일을 했습니다. 필자는 Fernando의 기술적 능력 뿐 아니라 3개 회사, 6개 나라, 2개 대륙에서 온 다양한 개발자들이 서로 협력해서 공동의 목표를 달성하도록 끌고 가는 그의 조율 능력에 크게 감명 받았습니다.

Fernando는 텔레포니카가 어떻게 파이어폭스OS에 참여하게 됐는지, 어떻게 이질적인 그룹을 하나로 묶을 수 있었는지 이야기 합니다. 그리고 공통 작업 표준과 코드 리뷰에 대해 지극히 실용적인 관점에서 설명합니다.

텔레포니카에서 당신과 당신 팀이 하는 일은 무엇입니까?

나는 플랫폼 팀이라 불리는 곳 소속입니다. 텔레포니카에는 다양한 팀들이 있습니다. 어떤 팀은 Gaia의 프론트엔드 개발에 집중하고 있고, 어떤 팀은 Gecko, Gonk, 외부-서비스(External Service) 같은 플랫폼 자체에 집중하고 있습니다. 우리는 Gecko, Gaia, 그리고 SimplePush 서버 같은 서비스까지 파이어폭스OS의 여러 부분을 개발하고 있습니다. 나는 라디오 인터페이스 레이어(Radio Interface Layer: RIL), 결제시스템(payments), 어플리케이션 API와 기타 다른 Web API 들을 개발했습니다. 거의 언제나 Gecko에서 Gaia까지 왔다갔다 합니다. 최근에는 파이어폭스OS 에서의 WebRTC 개발 작업을 시작했습니다.

텔레포니카는 어떻게 모질라와 함께 하게 됐나요?

글쎄요, 긴 이야기 입니다. 우리는 파이어폭스OS와 비슷한 프로젝트를 진행한 적이 있습니다. 하지만 Gecko 기반이 아니라 WebKit 기반이었습니다. 우리는 WebKit 기반의 오픈 웹 디바이스 플랫폼을 만들었던 거죠. 그런데 모질라가 Gecko를 이용해서 같은 일을 한다는 이야기를 들었습니다. 우리는 모질라에 연락해서 함께 하기로 결정했습니다. 그때까지 우리는 WebKit의 비공개 포팅 코드를 기반으로 일했는데 비공개 코드를 기반으로 일하는 것이 무척 힘들었습니다. 그이후로, 저의 일상은 텔레포니카의 다른 파이어폭스OS 팀 멤버들의 일상과 같아졌습니다. B2G 프로젝트에 참여하는 다른 모질라 엔지니어들의 일상과 똑같은 일상이죠.

당신은 훌륭한 아키텍트이자, 개발자이자, 의견 조율자로 알려져 있습니다. 파이어폭스OS에 구현한 파이어폭스 계정 시스템의 경우, 당신은 텔레포니카, 텔레노르(Telenor), 그리고 모질라 사람들을 융합시켜야 했습니다. 다양한 회사의 사람들과 함께 일할 때 어려운 점은 무엇인가요?

무척 어려운 일이었습니다. 특히 파이어폭스OS 초창기에 더욱 어려웠습니다. 우리가 모질라와 함께 일한 것은 2011년으로 거슬러 올라갑니다. 두 회사 모두에게 잘 맞는 공통된 작업 절차를 찾기까지 꽤 많은 시간이 걸렸습니다. 제말은, 우리는 텔코(telco) 문화에서 일하던 사람입니다. 텔코 문화에서는 대부분의 작업들이 폐쇄적이고 비밀입니다. 이것은 모질라의 공개적이고 투명한 문화와는 반대죠. 우리들 중 일부는 다른 오픈소스 프로젝트에서 일한 경험이 있었기 때문에 공개된 포럼에서 작업에 대해 갑론을박하는 오픈소스 문화에 적응하는 것이 그리 어렵지 않았습니다. 하지만 팀의 다른 멤버들은 그런 새로운 작업 방식과 새로운 프리젠테이션 방식에 적응하기까지 시간이 필요했습니다.

우리는 텔레포니카에서 애자일 방법론을 쓰고 있었는데, 당시 모질라는 애자일 방법론을 쓰고 있지 않았습니다. 우리는 양쪽 모두에게 맞는 작업 절차를 찾아야 했습니다. 그러기 위해 꽤 많은 시간이 필요했습니다. 작업 절차에 대해 의논하기 위해 아주 많이 만났고, 아주 많이 토론했습니다. 다른 텔코 회사들과 일하는 것의 경우는 지금까지 무척 만족합니다. 특히 텔레노르와 잘 협조하고 있습니다. 아직까지 우리는 그들(텔레노르)과 정보를 공유할 때 조심합니다. 왜냐하면 궁극적으로 그들은 우리의 경쟁사니까요. 하지만 그렇다고 해서 파이어폭스 계정 시스템 개발 같은 공동의 목표를 위해 협조 못한다는 말은 아닙니다.

모질라와 텔레포니카가 개발 프로세스에 합의했을 때, 양쪽 모두 변해야 했습니다. 당신은 어떤 개발 관례를 따를지 어떻게 결정했나요? 그리고 공통된 문화를 만들기 위해 어떻게 노력했나요?

나는 애자일 방법론을 선호했습니다. 우리는 프론트엔드 쪽에 먼저 집중했습니다. 왜냐하면 Gecko 쪽에는 이미 잘 정립된 프로세스와 개발 방식이 존재했기 때문입니다. Gecko 쪽은 개발 프로세스를 다루는 6주 분량의 교육 자료도 갖추고 있습니다. 공통 워크플로우를 확립하기 위해 프론트엔드 팀이 가장 집중적으로 가장 많은 노력을 기울였습니다. 왜냐하면 우리는 Gaia를 기반으로 작업을 시작했는데 Gaia는 새로운 프로젝트여서 확립된 개발 방법론이 존재하지 않았기 때문입니다.

나는 우리가 워크플로우를 정말 완벽하게 확립했다고 생각하지 않습니다. 하지만 꽤 괜찮은 일을 한 것 같습니다. 우리는 애자일 방법론에 따라 일하고 있습니다. 하지만 언젠가 Gecko 개발에 참여해야 할 일이 있다면 우리는 Gecko 개발 방식을 따를 것입니다.

많은 원칙이 적용되고, 많은 회사가 참여하는 프로젝트의 경우 스타일가이드, 도구, 프로세스 등의 공통 표준이 얼마나 중요한가요?

글쎄요, 나는 소프트웨어 엔지니어링에 대해 일반적으로 말할 때 표준이 중요하다고 합니다. 하지만, 나는 그것을 SCRUM이라고 부르던, KANBAN이라고 부르던, SCRUMBAN이라고 부런던 상관하지 않습니다. 마찮가지로 Git 워크플로우를 따르던, Mercurial 워크플로우를 따르던, 아니면 구글의 자바스크립트 스타일가이드를 따르던, 모질라의 자바스크립트 스타일가이드를 따르던 상관하지 않습니다. 어떤 공통의 프로세스와 표준은 반드시 필요합니다. 특히 대규모의 엔지니어링 그룹의 경우는 더욱 그렇습니다. 오픈소스 프로젝트나 모질라 프로젝트가 이에 해당합니다. 공통 표준에 대해 말하자면, 규칙은 매우 간단합니다. 보통의 경우 이런 표준과 공통 프로세스들을 정의하고 토론하는데 너무 많은 시간을 소비하는 나머진 진정한 개발 목표를 잃어버리는 수가 있습니다. 나는 이런 공통 표준이 결국은 도구일뿐이라는 사실을 잊으면 안된다고 생각합니다. 우리 개발자들과 우리 매니저들을 돕는 도구지요. 공통 표준에 대해 유연하게 접근하는 지혜가 필요합니다.

우리는 코드를 리뷰할 때 코딩 스타일을 많이 보곤합니다. 하지만 결과적으로 우리가 원하는 것은 코드를 수정해서 문제를 해결하는 것입니다. 만약 코딩 스타일에 문제가 있다면 고치면 됩니다. 연습삼아 패치를 남기는 상황이라면 일단 패치 코드를 버그 시스템에 기록으로 남겨 두세요. 그러면 코드 리뷰어가 기회 있을 때 코멘트할 것입니다.

파이어폭스OS는 Gonk, Gecko, Gaia를 기반으로 만들어졌습니다. 각 시스템은 규모가 크고 복잡해서 처음 접하는 사람에게는 두려울 정도입니다. 당신은 Gecko와 Gaia에 정기적으로 코드를 서브밋하고 있습니다. 이미 존재하는 프로젝트에 참여할 때, 대상 시스템을 공부하는 비결이 있을까요?

특별한 비법은 없는 것 같습니다. 내게 효과적인 방법이 다른 사람들에게도 효과적이지는 않을 것입니다. 내가 주로 시도하는 것은 코드 안팎의 문서를 가능한 많이 읽는 것입니다. 필요할 경우 코드의 원래 작성자에게 물어보기도 합니다. 물론 가능할 때 입니다. 때로는 원래 작성자가 지금은 다른 일을 한다거나, 연락할 수 없는 경우도 있습니다. 처음부터 코드를 한줄 한줄 읽는 것은 피하려고 합니다. 그리고 특정 코드를 깊이 파야하는 경우에는 항상 큰 그림을 먼저 이해하려고 시도합니다. 내 생각엔 경력이 쌓일수록 우리는 코드 속에의 패턴과 공통 아키텍처를 식별하는 능력을 갖게되는 것 같습니다. 그런 능력이 직면한 소프트웨어 문제를 해결하는데 도움이 됩니다.

익숙하지 않은 영역의 코딩을 시작할 때, 당신이 만든 코드가 의도하지 않은 사이드이펙트를 발생시키지 않는다고 확신할 방법이 있나요? 테스트가 정답인가요?

그렇습니다. 기본적으로 테스트죠. 테스트하고 또 테스트해야 합니다. 스모크 테스트, 블랙박스 테스트, 일반 테스트 모두 필요합니다. 그리고 우선, 리뷰어의 말에 의지해야 합니다. 일단 리뷰어를 믿어야 합니다. 때에 따라서는 QA나 리뷰어에게 당신이 만든 패치 코드에 대한 테스트 슈트를 추가해달라고 요청할 수 있습니다.

관점을 바꿔서 당신은 리뷰어이기도 합니다. 그래서 다른 사람의 코드를 리뷰하고 있습니다. 이런 경우, “좋아요, 이 코드가 이런 기능을 추가했군요. 그런데 이 코드가 다른 문제를 일으키지 않는다고 어떻게 확신하죠?” 라고 말할 때도 테스트에 의지하나요?

나는 주어진 패치 코드가 회귀적(regression) 문제를 유발할 것 같은 의심이 들면 테스트를 실시합니다. “시험(try)” 서버에서 테스트를 실행하기도 하고 또는 개발자에게 직접 “시험(try)”을 실행하라고 요청하기도 합니다.

그래요, 테스트군요… 아주 많은 테스트요.

그렇습니다. 이제 파이어폭스OS를 위한 훌륭한 테스트 슈트들이 갖춰지기 시작했습니다. 그런 것들을 잘 활용해야죠.

코드를 리뷰할 때 무엇을 살펴보나요?

일반적으로 제가 가장 먼저 확인하는 것은 정확성입니다. 그러니까, 패치 코드는 원래 의도했던 문제를 실제로 해결해야 합니다. 그리고 당연히 부가적인 문제를 일으켜서는 안됩니다. 어떤 회귀적 문제도 일으켜서는 안됩니다. 시간이 허락되면 패치 코드를 제가 직접 테스트합니다. 패치 코드가 어떻게 동작하는지 알고 싶어서 이기도 하고, 아주 중요한 패치 코드일 경우 제대로 동작하는지 회귀적 문제를 일으키지는 않는지 확인하고 싶어서 이기도 합니다. 또 코드가 효율적으로 동작하는지 안전한지 살펴봅니다. 패치 코드에 대한 테스트 슈트 작성이 가능해 보이면 거의 언제나 테스트 슈트 작성을 요구합니다. 마지막으로 전반적인 코드의 품질, 문서, 코딩스타일, 기여정도, 프로세스의 정확성 등을 살펴봅니다.

당신은 파이어폭스 계정 시스템을 파이어폭스OS에 통합할 때 지금까지 제가 만든 가장 큰 패치 코드를 리뷰했습니다. 당신은 지금까지 제가 겪은 다른 어떤 리뷰어보다 더 일관성을 강조했습니다. 다른 어떤 리뷰어보다 말이죠.

글쎄요. 일관성은 코드의 전반적인 품질을 향상시킵니다. 리뷰할 때, 나는 종종 “nit:”라는 코멘트를 남깁니다. 이건 모질라에서 아주 일반적인 코멘트인데, “이 코드를 수정하면 좋겠습니다. 만약 수정하지 않더라도 리뷰 결과는 긍정적입니다. 하지만 이 코드가 조금 더 수정되기를 희망합니다.”라는 뜻입니다.

두개의 관점에서 질문 드립니다. 리뷰어로서 당신은 당신의 코멘트가 개발자에게 지나친 간섭처럼 느껴지지 않을거라고 확신하나요? 또다른 질문은, 개발자로서 당신은 리뷰어의 코멘트를 지나친 간섭이라고 느낀적 없나요?

기록상, 나는 몇차례 아주 혹독한 리뷰를 경험했습니다. 나는 그것을 감정적으로 받아들이지 않았습니다. 그러니까, 나는 언제나 리뷰를 긍정적인 학습의 기회로 삼으려 했습니다. 나는 리뷰어들에게 시간이 넉넉하지 못하다는 사실을 압니다. 리뷰어들도 코드를 작성해야 합니다. 그래서 리뷰어들은 별다른 고민 없이 무뚝뚝하게 “수정해야 함”이라고 코멘트를 남깁니다. 리뷰어들은 당신 코드의 부정적인 것에 대해서만 이야기 합니다. 부정적인 것이라기 보다는 리뷰어의 생각에 좋지 않은 점이죠. 하지만 리뷰어들은 당신 코드의 좋은 점에 대해서는 이야기 하지 않습니다. 그것이 처음에는 쉽지 않은 일이라는 것을 나도 알고 있습니다.

하지만 일단 시작하고 보면, 리뷰어들이 왜 상냥하지 못한지 이해할 것입니다. 그러니까, 당신에게는 당신 몫의 일이 있는 겁니다. 리뷰하는 일이 영어를 모국어로 하고 있지 않은 나 같은 사람에게는 무척 힘든 일입니다. 왜냐하면 어떤 때는 최대한 상냥하게 말하고 싶은데 어휘력의 문제로 리뷰 코멘트가 의도했던 것보다 강하게 표현되기도 합니다. 그래서 나는 가능하면 아주 많은 웃음 기호를 사용하려고 노력합니다. 그리고 언제나 “r-” 플랙은 피하려고 합니다. “r-” 플랙은 정말 나쁜 경우입니다. 가능하다면 “feedback +” 같은 코멘트를 남기려고 노력합니다.

개발자로서 당신은 엄격한 리뷰를 배우는 기회로 삼으려 했단 말이지요? 그렇다면 리뷰어로서 리뷰를 가르치는 수단으로 사용하기도 했나요?

예, 물론입니다. 그러니까 패치 코드를 리뷰하는 것은 가르치는 일입니다. 리뷰어는 코드를 작성한 사람에게 옳다고 생각하는 것을 말하는 것입니다. 때때로 코멘트를 뒷받침할만한 이론이나 이유가 불분명할 때도 있지만, 리뷰어는 자기 주장을 해야 합니다. 리뷰어는 가능한 최선의 이유를 설명해야 하고 최선의 진보를 이뤄내야 합니다.

당신이 스스로 만들었거나 다른 사람이 만든 코드 중에서 다른 사람들이 보고 배울만한 샘플 코드가 있나요?

나는 스스로 만든 코드에 대해 무척 비판적입니다. 그래서 내가 만든 코드 중에서 남들에게 자랑할만한 샘플이 있다고 생각하지 않습니다 :). 하지만 굳이 골라야 한다면 얼마전 크게 리팩토링한 가이아 다이얼러 앱(Gaia Dialer app)의 통화기록(call log) 데이터베이스 코드와 최근에 작성한 모바일 인증 (Mobile Identity) API 구현 코드를 들 수 있을 것 같습니다.

다른 사람들에게 참여를 독려할만한 오픈소스 프로젝트가 있나요? 있다면 어떻게 시작해야 하나요?

물론 파이어폭스OS 입니다! 정말이에요. 나는 파이어폭스OS가 소프트웨어 엔지니어들에게 좋은 기회라고 생각합니다. 깊은 레벨(low level)의 코드부터 프론트엔드 코드에 이르기까지 엄청난 기술적 도전으로 가득찬 놀라운 오픈소스 커뮤니티에 참여할 수 있는 기회 말이죠. 웹브라우저와 모바일 운영체제의 핵심 코드를 파헤쳐 볼 수 있는 것은 아주 특별한 기회입니다. 처음엔 개발 프로세스에 참여해서 코드를 작성하는 것이 어렵게 느껴질 수도 있습니다. 하지만, 참조할 수 있는 아주 훌륭한 파이어폭스OS 문서들이 이미 MDN에 존재합니다. 그리고 아주 훌륭한 많은 사람들이 IRC (#b2g and #gaia), 메일링 리스트 (dev-b2g and dev-gaia), ask.mozilla.org 등을 통해 도울 준비를 하고 있습니다.

당신의 작업을 계속 지켜보려면 어떻게 해야 하나요?

나는 블로그를 하지 않아요. 하지만 GitHub 계정과 Twitter 계정을 쓰고 있습니다.

대본

긴 인터뷰에 응해준 Fernando에게 깊이 감사 드립니다.

GitHub에서 인터뷰의 전체 대본을 볼 수 있습니다.

다음 기사 예고

다음 기사에서는, 클라우드 서비스팀의 Brian Warner를 인터뷰할 것입니다. Brian은 보안 전문가로서 보안 아키텍처에 대한 자신의 생각을 공유하고, 보안 위협을 분석하고, 시스템이 장애에 무너지지 않도록 백업(“belts and suspenders”)하고, 보안기준을 준수하는 코드를 작성합니다.

끝으로, 저에겐 이번 인터뷰가 크게 즐거웠습니다. 이 시리즈를 보다 유용하게 만들 수 있도록 아이디어를 주세요. 인터뷰할 모질리안(Mozillians)을 찾고 있습니다. 만약 만나보고 싶은 사람이 있다면 알려주세요. 당신 자신이어도 좋습니다! stomlinson@mozilla.com로 이메일 주시면 됩니다.