실무나 현업에서 프로그래밍은 대규모로 이루어진다. 대규모로 프로그래밍할땐 각자 역할을 나눠 , 무엇을 해야할지
파악하고 분석하며, 넓은 명세부터 시작해 점차 작은 부분으로 적절히 나눠 전체적으로 일관되어 있는지 확인해야 한다.
프로그래밍에서 작업 실행 코드 하나의 크기는 보통 한 사람이 작성한 크기 정도이다. 당연한 말이지만 한 사람의 코드가 잘못될 경우 에러가 발생한다. 그래서 다른 프로그래머들끼리 작성한 부분들이 함께 잘 작동하는지 확인하는 일이 어렵다.
사례로 NASA에서 개발자 한명이 미국 미터법 단위를 사용하는 프로그램에 궤도 수정용 데이터를 영국식 단위로 입력해
화성 궤도선이 고장난 사건이 있었다.
이처럼 컴파일러나 웹 브라우저는 코드가 수십만에서 수백만 행에 이를 것이다. 대규모 시스템은 수백만 행, 수천만 행의 코드로 되어 있고 수천 명의 사람이 동시에 작업할 수 있으며 , 시스템과 서버의 수명도 수십년에 이른다.
회사 측에서는 프로그램의 규모를 밝히는데 대체로 조심스러운 감이 있다고한다.
참고로 구글의 전체 코드 규모는 2015년 기준 20억 행이라고 한다. 현재는 거의 두배 이상 됐을 가능성이 있다.
구글같은 초대형 규모의 프로그래밍 같은 경우는 프로그래머, 테스트 담당자 , 문서 작성자로 이러우진 팀이 여럿 필요하다. 프로젝트의 진행을 위해서는 일정과 마감 시한을 정하고, 여러 계층에 걸쳐 관리가 이루어져야 하며 끊임없는 회의를
거쳐가야 한다. 정말 중요한 회의에서는 코드 한줄당 한번씩 회의가 있었다 할정도...
라이브러리, 인터페이스, 개발 키트
우리가 당장 집을 짓는다고 생각해 보자. 나무를 베어서 통나무를 만들고 찰흙을 파내서 벽돌을 만드는 것부터 시작하지 않는다. 배관설비, 난로 ,온수기 같이 미리 만들어진 부품을 산다. 집을 만든다는 것은 큰 일이지만 대신에 다른 사람들이나 기업들이 만들어놓은 제품들을 사용하거나 도움이 되는 인프라에 의존할 수 있다.
프로그래밍도 비슷하다고 보면 된다. 우리가 만드는 어떠한 프로젝트도 처음부터 새로 만들어지지 않는다. 다른사람들이 만들어 놓은 여러가지 구성요소를 바로 구해서 사용할 수 있다. 이때 사용하는 것이 라이브러리,인터페이스,개발키트다.
연관된 함수들의 모음을 '라이브러리' library 라고 한다. 각 프로그래밍 언어에는 디스크나 다른 위치에서 데이터를 읽고 쓰는 함수로 표준 라이브러리가 있다.
함수 라이브러리가 제공하는 서비스는 애플리케이션 프로그래밍 인터페이스, 즉 API로 프로그래머에게 제공된다.
API는
포함하는 함수와 더불어 함수의 용도가 무엇인지,
함수를 어떻게 사용해야하는지,
어떤 입력 데이터를 요구하는지,
어떤값을 만들어 내는지 나열한다.
또, API는 시스템 내부에서 주고받는 데이터의 구조를 의미하는 자료 구조와 기타 세부 사항도 기술할 수 있다.
이 모든 것이 모여서 개발자가 서비스를 요청하기 위해 무엇을 해야 하고 결과적으로 무엇이 계산될지 정의한다.
컴퓨터는 정말 정직하게 받은 명령만을 실행한다. 그러므로 API 명세는 정확하고 상세해야 한다.
위의 사진들은 개발키트이다.API는 구문과 관련된 기본 명세뿐만 아니라 시스템을 효과적으로 사용하도록 돕는 지원 문서도 포함한다. 요즘 대규모 시스템은 프로그래머들이 복잡한 소프트웨어 라이브러리를 잘 다룰 수 있도록 소프트웨어 개발키트, 즉 SDK 를 포함한다.
애플은 아이폰과 아이패드 코드를 작성하는 개발자를 위해 개발 환경과 지원 도구를 제공한다.
구글은 안드로이드용 SDK를 제공한다.
마이크로소프트는 윈도우 코드를 여러 가지 장치에 대해 다양한 언어로 작성할 수 있는 폭넓은 개발 환경을 제공한다.
SDK자체도 대형 소프트웨어 시스템이다.안드로이드 개발환경인 안드로이드 스튜디오는 용량이 1.6GB, 애플 개발 환경인 Xcode는 버전마다 다르지만 45GB이상의 여유공간 확보가 필요하다.
버그 (bug)
개발자뿐만 아니라 일반 사용자들도 버그를 안 겪어본 사람은 단 한명도 없을 것이다.
프로그램은 크든 작든 모두 결함이 있다. 이러한 결함은 bug라고 한다. 버그의 유래는 그레이스 호퍼라는 개발자가 작업중에 컴퓨터안쪽에서 죽은나방을 발견했고 그 상황을 동료들이 디버깅하고 있다고 말했다고 한다.
버그가 일으킨 수많은 원인들 중 대부분의 이유
- 발생할 수 있는 경우를 깜박하고 처리하지 못했다.
- 어떤 조건을 평가하기 위한 논리 테스트나 산술 테스트를 잘못 작성했다
- 프로그램이나 프로그램의 특정 부분에 할당된 영역 밖에 있는 메모리에 접근했다.
- 잘못된 공식을 사용.
- 특정 종류의 데이터에 잘못된 연산을 적용.
- 사용자 입력이 적합한지 검사하지 못한 경우
등등 아주 다양하다.
버그는 시스템을 공격에 취약하게 만들기도 하는데, 버그 떄문에 종종 해커가 메모리에 악성코드를 심어 놓기 쉬워지기도 한다. 악용될 수있는 버그를 취급하는 시장은 활발하다. 심지어 버그가 일어난 부분은 찾기도 힘들다.
업데이트가 잦다는 것은 그만큼 취약점이 널리 퍼져 있다는 것을 뜻한다. 웹 브라우저처럼 많은 해커의 이목이 집중되어 있는 중요한 프로그램이 그렇다. 견고한 프로그램을 만드는 것은 어려운일이며 해커들은 호시탐탐 버그가 일어난 틈을 타서
공격할 기회를 엿본다.
소프트웨어가 패치될 때 보안 취약점이 수정되므로 일반 사용자들은 소프트웨어를 최신 상태로 유지하는 것이 중요하다.
끊임없는 변화에 뒤쳐지지 않고 따라가는 것은 소프트웨어 유지보수에서 매우 중요하며, 반드시 수행해야 하는 일이다.
그렇지 않으면 프로그램은 '비트 부식' 이란 현상을 겪게 되어, 머지않아 컴파일을 다시 시작할 수도 없게될뿐만 아니라 몇몇 라이브러리가 너무 많이 바뀌어 더 이상 작동하지 않거나, 업데이트할 수 없는 상태가 되어 버린다.
한편으로는 프로그램의 문제를 해결하려는 시도나 새 기능을 추가하려는 시도가 의도치 않게 새로운 버그를 반들어 내거나, 사용자에게 익숙한 ㅂ아식을 바꿔버리는 결과를 낳기도 한다.
댓글