구글 같은 서비스는 어떻게 개발할까?

현실에서 프로그래밍은 대규모로 이루어지는 경향이 있다. 이때 사용되는 전략은 책을 쓰거나 다른 큰 프로젝트에 착수할 때와 비슷하다. 무엇을 해야 할지 파악하고, 넓은 명세부터 시작해서 점차 작은 부분으로 적절히 나누고, 각 부분을 작업하면서 전체적으로 일관되어 있는지 확인해야 한다. 프로그래밍에서 작업 하나의 크기는 보통 한 사람이 프로그래밍 언어로 정확한 처리 단계를 작성할 수 있는 정도다. 프로그래밍 입문 수업에서 작성할 만한 작은 프로그램은 수십에서 수백 행의 코드로 되어 있다. 오늘날 유용한 작업을 하기 위해 만들어진 더 큰 프로그램은 아마 수천에서 수만 행 정도가 될 것이고, 컴파일러나 웹 브라우저는 코드가 수십만에서 수백만 행에 이를 것이며, 대규모 시스템은 수백만 행, 심지어 수천만 행의 코드로 되어있고, 수백에서 수천 명의 사람이 동시에 작업할 수 있으며, 시스템의 수명도 수십 년에 이른다. 예를 들어 2015년 구글 행사에 있었던 발표에 따르면 당시 구글의 전체 코드 규모는 약 20억 행이었다고 한다. 지금은 그 두 배 이상 됐을 가능성도 있다.

 이 정도 규모의 소프트웨어를 개발하려면 프로그래머, 테스트 담당자, 문서 작성자로 이루어진 팀이 여럿 필요하다. 프로젝트의 진행을 위해서는 일정과 마감 시한을 정하고, 여러 계층에 걸쳐 관리가 이루어져야 하며, 끊임없는 회의를 거쳐야 한다.

 

라이브러리, 인터페이스, 개발 키트

여러분이 당장 집을 지으려고 한다고 생각해 보자. 나무를 베어서 통나무를 만들고, 찰흙을 파내서 벽돌을 만드는 것부터 시작하지는 않는다. 그 대신 문, 창문, 배관 설비, 난로, 온수기같이 미리 만들어진 부품을 산다. 집을 짓는 것은 여전히 큰일이지만, 그래도 할 만하다는 생각이 드는 까닭은 다른 이들이 만들어 놓은 것을 가져다 쓸 수도 있고, 도움이 되는 인프라(실제로는 전체 산업)에 의존할 수 있기 때문이다

 프로그래밍도 마찬가지다. 어떤 중요한 프로그램도 완전히 처음부터 새로 만들어지지는 않는다. 다른 사람들이 만들어 놓은 여러 가지 구성 요소를 바로 구해서 사용할 수 있다. 예를 들어 윈도우나 맥 OS용 프로그램을 작성하려고 한다면 사전에 제작된 메뉴, 버튼, 그래픽 연산, 네트워크 연결, 데이터베이스 접근 등에 필요한 코드를 구한다. 프로그래밍 작업의 대부분은 이미 있는 구성 요소를 이해하고 자신만의 방식으로 이어 붙이는 것이다. 물론 구성 요소들은 단계적으로 더 단순하고 기본적인 구성 요소로 이루어져 있는데 보통 몇 개의 층위를 갖는다. 그 기저에는 운영체제가 있어 모든 구성 요소가 그 위에서 돌아간다. 운영체제는 하드웨어를 관리하고 일어나는 모든 일을 제어하는 프로그램이다.

 가장 단순한 수준에서 프로그래밍 언어는 함수 메커니즘을 제공한다. 함수 메커니즘은 어떤 프로그래머가 유용한 작업을 수행하는 코드를 작성하면 다른 프로그래머가 그 내부 작동 방식을 모르더라도 프로그램에 사용할 수 있는 형태로 코드를 패키지화할 수 있게 해 준다. 

 함수는 이름이 있고, 작업ㅇㄹ 수행하는 데 필요한 입력 데이터 값을 받는다. 함수는 계산을 수행하며, 프로그램 내에서 함수를 호출한 부분으로 계산 결과를 돌려줄 수도 있다. 함수를 이용하면 따로 만들어진 구성 요소를 필요에 따라 적절하게 조합하여 프로그램을 만들 수 있다.

 연관된 함수들의 모음을 보통 라이브러리라고 한다. 함수 라이브러리가 제공하는 서비스는 애플리케이션 프로그래밍 인터페이스(Application Programming Interface), 즉 API로  프로그래머에게 제공된다. API는 포함하는 함수와 더불어 함수의 용도가 무엇인지, 함수를 어떻게 사용해야 하는지, 어떤 입력 데이터를 요구하는지, 어떤 값을 만들어 내는지 나열한다. 또한 API는 시스템 내부에서 주고받는 데이터의 구조를 의미하는 자료 구조와 기타 세부 사항도 기술할 수 있다. 이 모든 것이 모여 프로그래머가 서비스를 요청하기 위해 무엇을 해야 결과적으로 무엇이 계산될지 정의한다. 이러한 명세는 상세하고 정확해야 한다. 결국 프로그램을 해석하는 것은 친절하고 협조적인 사람이 아니라 말도 안 통하고 명령을 곧이곧대로 받아들이는 컴퓨터이기 때문이다.

 API는 구문과 관련된 기본 명세뿐만 아니라 시스템을 효과적으로 사용하도록 돕는 지원 문서도 포함된다. 요즘 대규모 시스템은 프로그래머들이 복잡한 소프트웨어 라이브러리를 잘 다룰 수 있도록 소프트웨어 개발 키트(Software Development Kit) 즉 SDK를 포함한다. 예를 들어 애플은 아이폰과 아이패드 코드를 작성하는 개발자를 위해 개발 환경과 지원 도구를 제공한다. 구글은 안드로이드용 SDK를 제공한다. 마이크로소프트는 윈도우 코드를 여러 가지 장치에 대해 다양한 언어로 작성할 수 있는 폭넓은 개발 환경을 제공한다. SDK 자체도 대형 소프트웨어 시스템이다. 예를 들어 개발 환경을 제공한다. SDK 자체도 대형 소프트웨어 시스템이다. 예를 들어, 안드로이드 개발 환경인 안드로이드 스튜디오는 용량이 1.6GB이고 애플 개발 환경인 Xcode는 그보다 훨씬 크다

버그

안타깝게도 프로그램이 일정 규모 이상 커지면 한 번에 제대로 작동하지 않는다. 잉ㄴ생은 너무 복잡하고 프로그램은 인생의 복잡성을 반영한다. 프로그래밍은 세부 사항까지 완벽하게 주의를 기울여야 하는데, 그렇게 할 수 있는 사람은 적다. 크든 작든 모든 프로그램에는 결함이 있다. 컴퓨터는 시키지도 않은 엉뚱한 일을 하거나 잘못된 답을 내놓기도 한다. 이러한 결함을 버그라고 한다. 이 용어는 그레이스 호퍼가 만들었다고 흔히 알려져 있다. 1974년에 호퍼의 동료들은 작업 중이던 기계식 컴퓨터인 하버드 마크 2에서 말 그대로 죽은 나방을 발견했고, 호퍼는 동료들이 컴퓨터를 디버깅하고 있다고 말했다고 한다. 그 벌레는 보존되어 불멸의 존재처럼 되었다. 

 버그는 너무나 다양한 방식으로 발생한다. 버그를 일으키는 수많은 원인으로는, 발생할 수 있는 경우를 깜빡하고 처리하지 못했거나, 어떤 조건을 평가하기 위한 논리 테스트나 산술 테스트를 잘못 작성했거나, 잘못된 공식을 사용했거나, 프로그램이 프로그램의 특정 부분에 할당된 영역 밖에 있는 메모리에 접근했거나, 특정 종류의 데이터에 잘못된 연산을 적용했거나, 사용자 입력이 적합한지 검사하지 못한 경우 등이 있다. 그래서 테스트는 실제로 프로그래밍에서 큰 부분을 차지한다. 소프트웨어를 개발하는 기업에는 흔히 구현 코드보다 테스트 코드가 더 많고, 프로그래머보다 테스터가 더 많다. 소프트웨어가 출시되기 전에 가능한 많은 버그를 발견하기 바라기 때문이다. 버그를 완전히 없애는 건 어렵겠지만 적어도 드물게 발생하도록 만들 수는 있다.

 버그는 시스템을 공격에 취약하게 만드릭도 하는데, 버그 때문에 종종 공격자가 메모리에 악성코드를 심어 놓기 쉬워지기도 한다. 악용될 수 있는 버그를 취급하는 시장은 활발하다. 선량한 해커는 문제를 해결하고 악의적인 해커는 문제를 악용한다. 중간에는 미국 국가안보국 같은 정부 기관이 공격 방법을 나중에 이용하거나 해결할 용도로 비축해 두는 애매한 회색 영역이 존재한다.

 업데이트가 잦다는 것은 그만큼 취약점이 널리 퍼져 있다는 것을 뜻한다. 웹 브라우저처럼 많은 해커의 이목이 집중되어 있는 중요한 프로그램이 그렇다. 견고한 프로그램을 작성하는 일은 어려우며, 악당들은 언제나 공격할 틈이 생기기를 호시탐탐 노리고 있다. 소프트웨어가 패치될 때 보안 취약점이 수정되므로 일반 사용자들은 소프트웨어를 최신 상태로 유지하는 것이 중요하다. 

 소프트웨어 개발에 복잡함을 더하는 또 다른 요인은 급변하는 환경이다. 환경은 항상 변하고 프로그램은 거기에 발 빠르게 대응해야 한다. 새로운 하드웨어가 개발되면 새로운 소프트웨어가 필요한데, 이 때문에 시스템을 변경해야 할 수도 있다. 새로운 법이나 기타 요구사항이 등장하면 프로그램의 사양이 바뀐다. 일례로 터보택스 같은 프로그램은 서로 다른 관할권에서 세법이 바뀔 때마다 대응해야 한다. 컴퓨터 기종, 각종 툴, 프로그래밍 언어, 물리적 장치가 구식이 되면 교체되어야만 한다. 데이터 형식이 구식이 되기도 한다. 예를 들어 1990년대 초에 작성된 워드 파일은 최신 버전의 워드 프로그램에서 열 수 없다. 한 분야의 전문 직종도 환경이 바뀌면서 사람들이 점차 퇴직하고, 죽고, 사업 축소로 해고되면서 사라지게 된다. 대학에서 학생이 만든 시스템도 담당자가 졸업하면 같은 방식으로 어려움을 겪는다.

 끊임없는 변화에 뒤쳐지지 않고 따라가는 것은 소프트웨어 유지보수에서 매우 중요하며, 반드시 수행해야 하는 일이다. 그렇지 않으면 프로그램은 '비트 부식'을 겪게 되어, 머지않아 재컴파일할 수 없게 되거나 몇몇 라이브러리가 너무 많이 바뀌어 더 이상 작동하지 않거나, 업데이트할 수 없는 상태가 되어 버린다. 한편으로는 프로그램의 문제를 해결하려는 시도나 새 기능을 추가하려는 시도가 의도치 않게 새로운 버그를 만들어 내거나, 사용자에게 익숙한 방식을 바꾸어 버리는 결과를 낳기도 한다.