소스 코드

섬네일|right|300px|파이썬 프로그래밍 언어의 소스 코드. 알아보기 쉽게 하기 위해 여러 가지 색으로 강조되어 있다.
소스 코드() 또는 원시 코드는 궁극적으로 컴퓨터의 동작을 제어할 수 있는 사람이 읽을 수 있는 플레인 텍스트이다. 컴퓨터를 제어하려면 컴퓨터 프로그램에 의해 처리되어야 한다. 인터프리터를 통해 직접 실행되거나 컴파일러를 통해 더 컴퓨터가 소비할 수 있는 형태로 트랜슬레이터되어야 한다. 때때로 코드는 추가 처리 없이 컴퓨터의 기본 언어로 실행될 수 있도록 기계어로 직접 컴파일된다. 그러나 많은 현대 환경에서는 인터프리터를 통해 실행되거나 JIT 컴파일을 통해 온디맨드로 기계어로 컴파일될 수 있는 바이트코드와 같은 중간 표현으로 컴파일하는 과정을 포함한다.

 배경 
1940년대 말에 등장한 최초의 프로그램 가능한 컴퓨터는 기계어 (프로세서가 직접 실행할 수 있는 간단한 명령어)로 프로그래밍되었다. 기계어는 디버깅하기 어려웠고 다른 컴퓨터 시스템 간에 이식성이 없었다. 처음에는 하드웨어 자원이 부족하고 비쌌지만, 인적자원은 더 저렴했다. 프로그램이 복잡해짐에 따라 프로그래머 생산성이 병목 현상이 되었다. 이는 1950년대 중반에 포트란과 같은 고급 프로그래밍 언어의 도입으로 이어졌다. 이 언어들은 하드웨어의 세부 사항을 추상화했으며, 인간이 더 쉽게 이해할 수 있는 알고리즘을 표현하도록 설계되었다. 기본 컴퓨터 하드웨어와는 다른 명령어로서, 소프트웨어는 포트란, 리스프, 코볼과 같은 초기 프로그래밍 언어에서 시작되어 상대적으로 최근에 등장했다. 고급 프로그래밍 언어의 발명은 소스 코드를 컴퓨터 하드웨어에서 직접 실행될 수 있는 기계어로 자동 번역하는 데 필요한 컴파일러와 동시에 이루어졌다.

소스 코드는 일반적으로 고급 프로그래밍 언어로 인간이 직접 수정하는 코드 형태이다. 목적 파일은 기계에 의해 직접 실행될 수 있으며, 종종 어셈블리어와 같은 중간 단계를 거쳐 소스 코드로부터 자동으로 생성된다. 목적 파일은 특정 플랫폼에서만 작동하는 반면, 소스 코드는 다른 기계로 이식되어 재컴파일될 수 있다. 동일한 소스 코드에 대해 목적 파일은 컴파일되는 기계뿐만 아니라 컴파일러의 성능 최적화에 따라 크게 달라질 수 있다.

 구성 

대부분의 프로그램은 실행하는 데 필요한 모든 리소스를 포함하지 않으며 외부 라이브러리에 의존한다. 컴파일러의 기능 중 하나는 프로그램이 하드웨어에 의해 실행될 수 있도록 이러한 파일을 연결하는 것이다.


소프트웨어 개발자들은 종종 소프트웨어 구성 관리를 사용하여 소스 코드 파일의 변경 사항을 추적한다 (버전 관리). 구성 관리 시스템은 또한 어떤 목적 파일이 어떤 버전의 소스 코드 파일에 해당하는지 추적한다.

 목적 
 평가 
소스 라인 오브 코드 (SLOC)의 수는 컴퓨터 프로그래머의 생산성, 코드 베이스의 경제적 가치, 개발 중인 프로젝트의 노력 추정, 출시 후 소프트웨어 유지보수의 지속적인 비용을 평가할 때 지표로 자주 사용된다.

 통신 
소스 코드는 또한 당사자 간에 알고리즘을 전달하는 데 사용된다. 예를 들어, 온라인이나 책에 있는 스니펫이 있다.Spinellis, D: Code Reading: The Open Source Perspective. Addison-Wesley Professional, 2003. 

컴퓨터 프로그래머들은 프로그래밍 기술에 대해 배우기 위해 기존 소스 코드를 검토하는 것이 도움이 될 수 있다. 개발자들 간의 소스 코드 공유는 프로그래밍 기술이 성숙하는 데 기여하는 요인으로 자주 언급된다. 일부는 소스 코드를 표현적인 예술적 매체로 간주한다."Art and Computer Programming" ONLamp.com , (2005)

소스 코드에는 종종 주석—컴파일러가 무시하도록 표시된 텍스트 블록—이 포함된다. 이 내용은 프로그램 논리의 일부가 아니라 독자가 프로그램을 이해하는 데 도움이 되도록 의도된 것이다.

기업들은 종종 영업 비밀로 간주되는 알고리즘을 숨기기 위해 소스 코드를 기밀로 유지한다. 독점적인 비밀 소스 코드와 알고리즘은 형사 사법과 같은 민감한 정부 애플리케이션에 널리 사용되며, 이는 알고리즘 방법론에 대한 투명성 부족으로 블랙박스 행동을 초래한다. 그 결과 편향과 같은 문제에 대한 대중의 감시를 피하게 된다.

 수정 

소스 코드 (목적 파일뿐만 아니라)에 대한 접근은 이를 수정하는 데 필수적이다. 기존 코드를 이해하는 것은 코드가 어떻게 작동하는지 이해하는 데 필요하다 수정하기 전에 말이다. 이해 속도는 코드 베이스와 프로그래머의 기술에 모두 의존한다. 숙련된 프로그래머는 코드가 높은 수준에서 무엇을 하는지 이해하는 데 더 쉽다. 소프트웨어 시각화는 때때로 이 과정을 가속화하는 데 사용된다.

많은 소프트웨어 프로그래머는 생산성을 향상시키기 위해 통합 개발 환경 (IDE)을 사용한다. IDE는 일반적으로 프로그래머에게 일반적인 오류를 알려줄 수 있는 소스 코드 편집기를 포함한 여러 기능을 내장하고 있다. 수정은 종종 리팩터링 (기능을 변경하지 않고 구조 개선) 및 재구조화 (구조와 기능을 동시에 개선)를 포함한다. 거의 모든 코드 변경은 새로운 버그 또는 예상치 못한 파급 효과를 유발하며, 이는 또 다른 수정 과정을 필요로 한다.

다른 개발자들의 코드 검토는 프로젝트에 새로 추가된 코드를 면밀히 검토하는 데 자주 사용된다. 이 단계의 목적은 종종 코드가 스타일 및 유지보수성 표준을 충족하는지, 그리고 소프트웨어 설계의 올바른 구현인지 확인하는 것이다. 일부 추정치에 따르면, 코드 검토는 소프트웨어 테스트 완료 후에도 남아있는 버그 수를 극적으로 줄인다. 코드를 실행하여 작동하는 소프트웨어 테스트와 함께, 정적 프로그램 분석은 자동화된 도구를 사용하여 소스 코드의 문제를 감지한다. 많은 IDE는 코드 분석 도구를 지원하며, 이는 코드의 명확성과 유지보수성에 대한 지표를 제공할 수 있다. 디버거는 프로그래머가 실행을 단계별로 진행하면서 각 상태 변경에 해당하는 소스 코드를 추적할 수 있도록 하는 도구이다.

 컴파일 및 실행 
고급 프로그래밍 언어로 작성된 소스 코드 파일은 명령어가 수행되기 전에 기계어로 전처리하는 단계를 거쳐야 한다. 컴파일된 후 프로그램은 목적 파일로 저장될 수 있으며, 로더 (운영 체제의 일부)는 이 저장된 파일을 가져와 컴퓨터 하드웨어에서 실행할 수 있다. 일부 프로그래밍 언어는 컴파일러 대신 인터프리터를 사용한다. 인터프리터는 실행 시점에 프로그램을 기계어로 변환하며, 이는 컴파일된 프로그래밍 언어보다 10배에서 100배 느리게 만든다.

 이식성 

많은 프로그램이 실행 가능한 이진 파일 대신 소스 코드 형태로 배포되는 또 다른 이유는 (종종) 단일 소스 코드 파일이 한 번 작성되면 다양한 최종 사용자 기계 (각각 자체 로컬 컴파일러 또는 인터프리터를 가짐)에서 실행될 수 있다는 점인데, 이는 일반적으로 거의 동일한 기계에서만 작동하는 실행 파일과는 다르다. 소스 코드는 유닉스의 역사 초기에 유닉스 운영 체제를 배포하는 데, 그리고 나중에 스크립트 언어 (특히 자바스크립트 클라이언트 사이드 스크립트 언어)로 작성된 프로그램이 다양한 기계에서 실행될 수 있도록 하는 데 사용되었다.

이 목표를 위해 축소되거나, 난독화되거나, 역컴파일된 소스 코드 파일 (모두 원본 코드의 주석을 제거함)은 원래 소스 코드 파일 (거의 항상 주석을 포함함)과 마찬가지로 일반적으로 이식성이 좋지만, 수정에는 훨씬 덜 유용하므로 GNU 일반 공중 사용 허가서 버전 2 (GPL2)의 소스 코드 정의를 충족하지 못한다.

 품질 

소프트웨어 품질은 코드의 정확하고 효율적인 동작, 재사용성 및 이식성, 또는 수정 용이성을 나타낼 수 있는 포괄적인 용어이다. 일반적으로 개발 과정의 나중에 품질을 추가하려고 시도하는 것보다 처음부터 제품에 품질을 구축하는 것이 더 비용 효율적이다. 고품질 코드는 높은 신뢰성과 유지보수성을 통해 공급업체와 고객 모두에게 평생 비용을 줄여준다.

유지보수성은 기존 기능을 손상시키지 않고 소프트웨어를 쉽게 수정할 수 있도록 하는 소프트웨어의 품질이다. 명확한 함수 및 변수 이름을 사용하여 목적에 맞게 코딩 규칙을 따르면 유지보수가 더 쉬워진다. 코드가 두 번 이상 실행될 수 있는 경우에만 조건 루프 문을 사용하고, 절대 실행되지 않을 코드를 제거하는 것도 이해도를 높일 수 있다. 많은 소프트웨어 개발 조직은 개발 단계에서 유지보수성을 간과하지만, 이는 장기적인 비용을 증가시킨다. 기술 부채는 프로그래머가 종종 게으름이나 마감일을 맞추기 위한 긴급함으로 인해 유지보수성을 코딩에 구축하기보다는 빠르고 지저분한 해결책을 선택할 때 발생한다. 일반적인 원인은 소프트웨어 개발 노력 추정에 대한 과소평가로 인해 개발에 할당되는 자원이 부족한 것이다. 유지보수성의 어려움은 많은 소프트웨어 공학 과정에서 이를 강조하지 않는다는 점이다. 소프트웨어 유지보수에 대한 책임이 없을 것이라는 것을 아는 개발 엔지니어는 유지보수성을 구축할 인센티브가 없다.

 저작권 및 라이선스 

상황은 전 세계적으로 다르지만, 1974년 이전 미국에서는 소프트웨어와 그 소스 코드는 저작권 보호를 받을 수 없었으므로 항상 퍼블릭 도메인 소프트웨어였다. 1974년에 미국 신기술 사용에 관한 위원회 (CONTU)는 "컴퓨터 프로그램은 저작자의 독창적인 창작물을 구현하는 한, 저작권의 적절한 대상이 된다"고 결정했다.Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs  in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (January 1984)Lemley, Menell, Merges and Samuelson. Software and Internet Law, p. 34.

사유 소프트웨어는 소스 코드 형태로 거의 배포되지 않는다. 오픈 소스 소프트웨어라는 용어는 문자 그대로 소스 코드에 대한 공개 접근을 의미하지만, 오픈 소스 소프트웨어는 추가 요구 사항을 갖는다: 자유로운 재배포, 소스 코드 수정 및 동일한 라이선스 하에 파생 저작물 배포 허용, 상업적 사용을 포함한 다양한 사용 간의 비차별. 오픈 소스 소프트웨어의 자유로운 재사용성은 개발을 가속화할 수 있다.

 같이 보기 
 레거시 모드
 머신 모드
 오픈 소스 소프트웨어
 구문 강조
 목적 코드

 각주 

 외부 링크 

  Source Code Definition by The Linux Information Project (LINFO)