한빛출판네트워크

제공 : 한빛 네트워크
저자 : Howard Wen
역자 : 임혜연
원문 : The rewards of simple code

"Code Simplicity" 저자 Max Kanat-Alexander에게 듣는 단순한 코드의 우아함과 유용성

Bugzilla 프로젝트의 최고 설계자로서의 경험과 구글 소프트웨어 엔지니어로서의 경험에 기반하여 Max Kanat-Alexander (@mkanat) 는 효율적인 코드를 설계하는 메소드와 철학을 만들어 냈는데 그것의 핵심은 모두 단순성이다. 그는 그 아이디어로 "Code Simplicity" 라는 책을 썼다. 이 책에서는 개발자가 소프트웨어 프로젝트를 위한 구조 계획을 최적화할 수 있는 방법을 설명한다.

다음 인터뷰에서, Kanat-Alexander는 엉망진창인 코드를 야기할 수 있는 부정적인 요인들과 왜 수많은 프로젝트 개발자들이 소프트웨어 설계의 질을 약화시킬 필요가 없는지 논한다.

"단순하지 않은" 코드를 야기하는 요인들은 무엇인가?

Max Kanat-Alexander: 내가 일했던 프로젝트, 소프트웨어 개발 분야에서 읽은 모든 것들, 몇 년에 걸친 개발자 인터뷰 경험을 돌이켜보면, 대부분의 단순하지 않은 코드는 전적으로 사람에게서 나왔다. 몇몇 사람들은 도구가 삶을 힘들게 한다고 하고 - 가끔 그렇긴 하지만 - 복잡성은 결국 코드를 작성하는 개발자가 자기 일의 특성과 소프트웨어 개발의 근본적 원리를 이해하는가로 설명할 수 있다.

이 책에서 지향하고자 한 바가 그 개발의 근본 원리이다. 종종 고급 개발자들이 단지 그들이 하려는 것을 알 뿐, 다른 사람들에게 어째서인지 설명하지 못하는 것을 본 적이 있을 것이다. 부분적으로는, 그것이 바로 세상에 그렇게 많은 단순하지 않은 코드가 생기는 이유인데, 왜냐면 우리가 그 지식을 효율적으로 수준이 더 낮은 개발자에게 전달하지 못하기 때문이다. 모든 지식과 경험을 압축하여 폭넓고 견고한 진리로 만들어 누구나 그저 읽는 것만으로 바로 이해할 수 있는 것, 바로 그것이 이 책이 여기서 제시하는 해결책의 한 부분이다.

고급 개발자들이 잊었거나 그저 모르는 것일지도 모르는 (중요한?) 것들이 있다. 사람들을 가르치기 위해 전적으로 경험에만 의존할 때, 그들이 모두 같은 경험을 하게 되지는 않는다는 것이다. 그래서 개발자가 정말로 훌륭한 프로그래머가 되기 위해 필요한 모든 기본 원리를 얻게 된다는 보장이 없다.

소프트웨어 프로젝트에 연관된 개발자 수가 어떻게 코드의 단순성에 영향을 미치는가?

Max Kanat-Alexander: "맨먼스 미신"(The Mythical Man-Month)에서 인용된 유명한 구절이 있다. "진행이 늦은 프로젝트에 개발자를 더하는 것은 완료를 더욱 늦출 뿐이다." 복잡성은 가장 주요한 원인이다. 그러나 그저 몇몇 개발자가 프로젝트를 한다고 해서 프로젝트가 복잡해져야 하는 것은 아니다.

새로 사람을 투입하는 것이 일을 좀 복잡하게 만드는 것은 사실이기 때문에, 그것에는 대비해야 한다. 수많은 새 사람들을 시스템에 투입하기 전 기존 시스템에 견고한 단순성의 기초가 있고, 그 기초가 지원하는 것보다 빠르게 투입할 수 없다는 것을 확실히 하고 싶을 것이다. 그렇지 않다면, 새 친구들은 시스템에 복잡성을 더할 것이다.

그러나 "X명 이상의 개발자가 있는 프로젝트는 반드시 복잡하다" 라는 대원칙은 없다. 이론적으로, 시스템의 올바른 개발 관행과 올바른 설계가 있으면, 거의 무한한 수의 사람들을 한 시스템에서 작업하게 하면서 복잡성을 피할 수 있다. 작업은 왔다갔다하는 의사소통 때문에 굉장히 느려지겠지만 정말로 모두가 노력한다면 시스템은 단순한 채로 유지할 수 있다.

나 자신은 작은 팀을 지지하지만, 그것이 큰 팀으로는 단순한 시스템을 만들 수 없다는 뜻은 아니다. 그저 작은 팀으로 하는 것보다는 훨씬 어렵고, 아마 더 느린 속도로 진행될 것이다.

그래서, 질문에 답하자면, 수많은 사람들과 작업하는 것이 그 자체로 복잡성으로 이어지는 것은 아니지만 프로그래밍 현실 세계에서는 단순성을 유지하기 어렵게 한다는 점은 확실하다.

코드를 짜는 잘못된 방식은 무엇인가?

Max Kanat-Alexander: 잘못된 방법은 이해하지 않고 소프트웨어를 작성하는 것이다. 올바른 방법은 이해할 수 있는 한 많이 이해하여 소프트웨어를 작성하는 것이다.

하고 있는 일에 대해 더 잘 알수록 더 잘 할 수 있다. 그리고 바로 그것이 책에서 전달하려는 것이다. 과학의 토대를 전달하여 소프트웨어 개발에 대해 가장 중요한 것들을 이해하고, 그 아이디어들을 마음과 매일의 개발 작업에 기초로 삼을 수 있도록.

개발자들이 코드를 단순하고 더욱 효율적으로 만들기 위해 곧바로 할 수 있는 일은 무엇일까?

Max Kanat-Alexander: 먼저 "곧바로" 라는 단어에 대해 말해보자. 대부분의 개발자들은 자신의 코드에서 곤란을 겪는데 미래에 대한 계획을 전혀 하지 않았거나, 혹은 인내심이 부족하고 미래가 와서 실제로 볼 수 있을 때까지 기다리고 싶지 않아 미래에 대한 잘못된 예측을 했기 때문이다. 그래서, 만약 코드를 단순하게 만들기 위해 무엇을 곧바로 하고 싶다면, 그것은 그렇게 곧바로 생각하기를 멈추는 것이다. 미래에 시스템을 유지관리하기 위해 얼마나 작업해야 할지 생각하는 데서 시작하라. 어쩌면 지금 약간, 혹은 많은 작업을 해서 유지관리하기 쉽게 시스템을 만드는 것은 가치가 있을지도 모른다. 가끔 리팩터하기 어렵다는 것과 정말 그저 기능을 그 자리에서 얻고 싶을 수도 있다는 것도 알지만, 코드 베이스의 상태를 조금 더 책임감을 갖는 것은 가치가 있다. 어떤 굉장한 새 기능과 함께 새 복잡성 뭉치를 더하기 시작하기 전 코드 베이스를 더 단순하게 만들고 싶을 것이다. 이 모든 것에 당신의 팀 동료만큼이나 혜택을 보는 것은 바로 "미래의 당신"이다. "미래의 당신"을 행복하게 해주어라.

그래서, 위의 사항을 염두에 두고, "효율적" 이란 단어에 시비를 걸 수 있다. 만약 우리가 프로그램 실행 속도 혹은 무언가 차지하는 공간에 대한 효율에 대해 이야기하기 시작한다면, 먼저 그 시스템이 단순하고 유지관리하기 쉬운지 확실히 하고 싶을 것이다. 왜냐하면 지금 무언가를 최적화할 수 있다 하더라도 그것이 언제까지나 최적의 해결책이 되어줄 것이라는 의미는 아니기 때문이다. 그리고 그저 무언가를 최적화하기 위해 조급하게 시스템에 복잡성을 추가한다면, 시간이 흐르면서 시스템이 계속해서 최적화되어 있도록 유지할 수 없을 것이다. 그래서, 비록 종종 복잡성을 더해 단기적 효율을 얻을 수 있더라도, 정말로 장기적 관점에서의 효율을 얻어내는 것은 단순성이다. 절대로 최적화하지 말라고 하는 것은 아니다 - 중요하다면 해야 한다. 그러나 만든 것의 트레이드오프에 대해 이해해야 하고, 최적화로 인해 미래에 얼마나 혼란스러울 것인지 좀 생각해 봐야 한다.

좋은 소프트웨어 설계에 대한 고유한 철학이나 원칙들이 있는가?

Max Kanat-Alexander: 소프트웨어 개발에 대한 폭넓은 의견과, 그 근본에는 연구하고 발견한 단단한 사실이 있다. 책에서는 그 사실에 초점을 맞추고 있고, 그 사실들에 대한 약간의 내 관점이 가끔 섞여 있다.

소프트웨어에 대한 개인적 생각을 담은 몇몇 다른 책들도 쓸 수 있고, 거기서도 또한 더 많은 것들을 발견할 수 있을 것이라 확신한다. 그러나 먼저 소프트웨어 개발에 대한 과학적 기반을 개발하고 전달하는 것이 더 중요하다고 생각했다. 그 일이 끝나면, 어떤 아이디어나 의견이 최선일지에 대한 수많은 흥미로운 이론적 논의를 시작할 수 있을 것이다.