하버드 마크 II의 벌레
구글 같은 서비스는 어떻게 개발할까?
현실에서 프로그래밍은 대규모로 이루어지는 경향이 있다. 이를 만드는 과정은 다른 큰 프로젝트에 착수할 때와 같다.무엇을 할지 파악하고, 넓은 명세부터 시작해서 점차 작은 부분으로 적절히 나누고, 각 부분을 작업하면서 전체적으로 일관되어 있는지 확인해야 한다.
프로그래밍에서 작업 하나의 크기는 보통 한 사람이 프로그래밍 언어로 정확한 처리 단계를 작성할 수 있는 정도다. 다른 프로그래머들이 작성한 부분들이 함께 작동하는지 확인하는 일은 어렵지만 이걸 바로잡지 못하면 에러가 발생할 소지가 크다. 유명한 예시로 1990년대 화성 기후 궤도선이 고장을 일으킨 사건이 있었다. 비행 시스템 소프트웨어는 추진력 계산에 미터법을 사용했지만 궤도 수정용 데이터는 야드-파운트법을 사용해서 일어난 사고였다.
오늘날 유용한 작업을 하기 위해 만들어진 더 큰 프로그램은 아마 수천에서 수만 행 정도일 것이다. 컴파일러나 웹 브라우저는 코드가 수심만에서 수백만 행에 이를 것이다. 예를 들어 2015년 구글 행사에서 있었던 발표에 따르면 당시 구굴 전체 코드 규모는 약 20억행이었다고 한다. 지금은 그 두 배 이상 됐을 가능성이 있다. 이정도 규모의 소프트웨어를 개발하기 위해서는 프로그래머, 테스트 담당자, 문서 장성자로 이루어진 팀이 여럿 필요하다. 여러 계층에 걸쳐 관리가 이루어져야 하며, 끊임없는 회의를 거쳐야 한다.
라이브러리, 인터페이스, 개발 키트
당장 집을 지으려고 한다고 생각해보자. 나무를 베어서 통나무를 만들고, 찰흙을 파내서 벽돌을 만드는 것부터 시작하지는 않는다. 그 대신 문, 창문, 배관 설비, 난로, 온수기같이 미리 만들어진 부품을 구매한다. 이렇게 생각하면 집을 짓는다는 건 여전히 큰일이지만 그래도 할만하다는 생각이 드는 까닭은 이미 만들어 놓은것을 가져다 쓰거나 도움이 되는 인프라에 의존할 수 있기 때문이다.
프로그래밍도 마찬가지다. 어떤 중요한 프로그램도 완전히 처음부터 새로 만들어지지는 않는다. 다른 사람들이 만들어 놓은 여러 가지를 구해서 사용할 수 있다. 가장 단순한 수준에서 프로그래밍 언어는 함수(Function)메커니즘을 제공한다. 함수 메커니즘은 어떤 프로그래머가 유용한 작업을 수행하는 코드를 작성하면 다른 프로그래머가 그 내부 작동 방식을 모드더라도 프로그램에 사용할 수 있는 형태로 패키지화 할 수 있게 해준다. 이런 연관된 함수들의 모음을 보통 라이브러러리라고 한다. 함수 라이브러리가 제공하는 서비스는 애플리케이션 프로그래밍 인터페이스, 즉 API로 프로그래머에게 제공된다. API는 포함하는 함수와 더불어 함수의 용도가 무엇인지, 함수를 어떻게 사용해야하는지, 어떤 입력 데이터를 요구하는지, 어떤 값을 만들어 내는지 나열한다. 이 모든 것이 모여 프로그래머가 서비스를 요청하기 위해 무엇을 해야하고 무엇이 계산될지 정의한다.
API는 보통 지원 문서도 포함하는데 복잡한 소프트웨어 라이브러리를 잘 다룰 수 있도록 소프트웨어 개발 키트 (Sofware Development Kit) 즉 SDK를 포함한다. 예시로 애플은 아이폰과 아이패드 코드를 작성하는 개발자를 위해 개발 환경과 지원 도구를 제공한다.
버그
인생은 너무 복잡하고 프로그램은 인생의 복잡성을 반영한다. 크든 작든 모든 프로그램에는 결함이 있다. 시키지 않은 일을 하거나 잘못된 답을 내놓기도 한다. 버그라는 단어는 1947년에 기계식 컴퓨터인 하버드 마크 II에서 말 그대로 죽은 벌레(나방)을 발견했고 동료들은 버그를 치우는 (debugging) 디버깅을 했다. 그 벌레는 박물관에 보관되어 보존되고 있다.
하지만 버그라는 단어를 쓴 것은 호퍼가 처음이 아닌데, 옥스퍼드 영어사전에 따르면 1889년에 먼저 쓰였다고 한다.
bug : 기계, 계획 등에 생긴 흠이나 결함(유래:미국). 어려운 문제를 해결했음을 나타낸 표현으로, 상상의 곤충이 몰래 숨어들어서 문제를 일으킨다는 것을 뜻함.
버그는 너무나 다양한 방식으로 발생한다. 이를 이용하는 해커도 있기 때문에, 많은 기업에는 구현 코드보다 테스트 코드가 더 많고, 프로그래머보다 테스터가 더 많다. 우리는 업데이트를 이용해서 취약점을 수정한다.
끊임없는 변화에 뒤처지지 않고 따라가는 것은 소프트웨어 유지보수에서 매우 중요하며, 반드시 수행해야 하는 일이다. 그렇지 않으면 프로그램은 "비트 부식"겪게 되어, 머지않아 재컴파일할 수 없게 되거나 몇몇 라이브러리가 너무 많이 바뀌어 더 이상 작동하지 않거나, 업데이트할 수 없는 상태가 되어버린다. 물론, 프로그램의 문제를 해결하려는 시도가 새 기능을 추가하려다가 새로운 버그가 만들어질 수도 있고, 사용자에게 익숙한 방식을 바꾸어 버리는 결과를 낳기도 한다.
