검수요청.png검수요청.png

소스코드

해시넷
(소스에서 넘어옴)
이동: 둘러보기, 검색
소스코드(source code)

소스코드(source code)는 컴파일(compile) 되어 기계어로 번역되기 전의 원래 프로그램 코드이다. 간략한 설명과 메모를 적은 주석(comment)을 덧붙일 수도 있다. 원시코드 또는 소스(source)라고도 불린다.

개요[편집]

소스코드는 주로 실행 프로그램을 만드는 과정을 입력하는 데 이용되며, 사람들 사이에 알고리즘을 주고받는 방식으로 이용된다. 프로그래머는 프로그래밍 기술을 배우려면 기존에 있던 소스코드를 살펴보는 것도 도움이 되기도 한다. 개발자들 사이의 소스 공유는 프로그래밍 기술의 성숙 요소에 기여하는 역할을 하며 자주 인용된다. 또한, 일부 사람들은 소스코드를 풍부한 화재로 생각되어지며, 소프트웨어를 다른 컴퓨터 플랫폼포팅하는 것은 일반적으로 소스코드 없이는 불가능하다. 이진 번역과 원본 플랫폼의 애뮬레이션과 같이 이용할 수 있는 포팅 옵션들이 있고, 실행 프로그램의 디컴파일은 고급 언어에서나 어셈블리어로 소스코드를 만들어 내는데 쓰인다.[1]

컴파일러는 해석기, 번역기라는 뜻으로, 어떤 프로그래밍 언어로 쓰여진 소스파일을 다른 프로그램이 언어로 옮기는 번역 프로그램이다. 소스코드와 목적코드는 프로그램이 컴파일러에 의해 컴파일 되기 이전과 이후 버전이다. 프로그래머가 특정한 컴퓨터 소프트웨어 프로그램을 만들 때는 설계도가 필요하며, 이러한 설계도로 비유할 수 있는 것이 바로 소스코드이다. 소스코드로 만든 프로그램을 실행하려면 프로그래머는 컴퓨터가 이해할 수 있는 기계어로 번역을 해야 한다. 소스코드는 사람이 읽을 수 있는 형태이지만 컴퓨터가 이해하지는 못한다. 따라서 기계어로 번역을 해줘야 하는데 그 첫 번째 단계가 컴파일러라고 하는 컴퓨터 프로그램을 이용하여 소스코드를 목적코드로 만들어 주는 것이다.[2]

역사[편집]

소스코드(source code)는 사람이 읽을 수 있는 컴퓨터 프로그램 및 프로그래밍 언어로 기술한 글이다. 한 개, 또는 여러 개의 텍스트 파일로 구성되어 있다. 현대 소프트웨어 개발에서 기계어는 극히 일부 영역에서만 쓰이며, 대부분 고급 언어로 된 소스코드를 컴파일하여 개발한다. 소프트웨어와 이에 동반하는 소스코드는 일반적으로 크게 자유 소프트웨어와 사유 소프트웨어 가운데 하나의 라이선스를 지니고 있다. 프로그램 내장식 컴퓨터를 위한 최초의 프로그램들은 컴퓨터의 전면 패널 스위치를 통해 바이너리 형태로 입력되었다. 1세대 프로그래밍 언어는 소스코드와 기계어 간의 구별이 없었다. IBM이 최초로 기계와 함께 작업할 소프트웨어를 제공했을 때 소스코드는 무료로 제공되었다. 당시 소프트웨어를 개발하고 지원하는 비용이 하드웨어의 가격에 포함되었다. 수십 년간 IBM은 1983년까지 소스코드를 자사의 소프트웨어 제품 라이선스와 함께 배포했다.[3]

프로그래머는 프로그래밍 기술을 배우려면 기존에 있던 소스코드를 살펴보는 것이 도움이 된다. 개발자들 사이의 소스 공유는 프로그래밍 기술의 성숙 요소에 기여하는 역할을 하며 자주 인용된다. 일부 사람들은 소스코드를 풍부한 화재로 생각 되어지며, 소프트웨어를 다른 컴퓨터 플랫폼에 포팅 하는 것은 일반적으로 소스코드 없이는 불가능하다. 이진 번역과 원본 플랫폼의 에뮬레이션과 같이 이용할 수 있는 포팅 옵션들이 있고, 실행 프로그램의 비컴 파일은 고급 언어에서나 어셈블리어로 소스코드를 만들어내는 데 쓰인다.[4]

특징[편집]

오픈 소스[편집]

오픈소스(Open source)란 소프트웨어 또는 하드웨어의 제작자의 권리를 지키면서 누구에게나 무상으로 소스코드를 공개하여 일반인들이 사용하고 수정할 수 있도록 만든 것이다. 프로그래머는 오픈소스를 활용한 2차적인 프로그램을 창작할 수도 있으며, 심지어 상업적인 용도로 사용하기도 한다. 또한 글꼴과 같은 데이터에도 개발 모델로서 적용되는 경우가 있다. 일반적으로 경제적인 관점에서의 무료라는 것만을 의미하는 것이 아니다. 무료라는 의미보다는 기술을 공개하여 공개적인 협업이라는 의미에 더욱 가치가 있는 것이다. 오픈소스의 정신은 기술을 대중들에게 공유하여 그것을 바탕으로 서로 발전해 나가는 것을 원하는 것이다. 오픈소스 소프트웨어는 소스코드가 공개되어 있어 누구나 접근할 수 있는 것은 맞지만, 소스코드를 사용하는 이용자는 그에 따른 법적 책임도 뒤따른다. 반드시 그 소프트웨어의 개발자가 규정한 라이선스를 읽어 보고 지켜야 한다. 이를 위반할 경우 라이선스 위반 및 저작권 침해가 발생하고, 이에 대한 법적인 처벌을 받게 된다. 일반적으로 오픈소스 소프트웨어 라이선스는 기본적으로 사용자의 자유로운 사용, 수정, 배포를 보장하고 있다. 라이선스는 해당 오픈소스 소프트웨어를 자유롭게 사용, 복제, 수정할 수 있다. 일정한 조건하에 재배포하거나 수정된 내용을 재배포할 수도 있다. 또한, 라이선스는 해당 오픈소스 소프트웨어의 소스코드를 자유롭게 획득하고 접근할 수 있다.

독점 소프트웨어 라이선스에서 규정된 의무사항과 비교하면 오픈 소수 소프트웨어 라이선스가 요구하는 내용은 결코 어렵지 않으며, 이를 잘 이해하고 준수하면 독점 소프트웨어보다 훨씬 비용을 절감할 수 있다. 또한, 소수의 라이선스만이 독자 개발한 소스코드의 공개를 요구하고 있기 때문에 이를 잘 분석한 후 사용한다면 문제 발생 소지는 거의 없다고 봐야 할 것이다. 따라서 오픈소스 소프트웨어를 다운로드하여 개발에 적용할 때에는 반드시 라이선스의 요구 사항을 확인하여야 한다. 자체 판단이 불가능할 경우에는 전문가에게 조언을 의뢰하여 개발 시작 전 해당 라이선스의 요구 사항과 오픈소스 소프트웨어의 사용 목적을 확실히 분석하여야 합니다. 이렇게 하는 것만으로도 충분히 올바르게 활용할 수 있으며, 나중에 발생할 수 있는 문제들을 사전에 차단할 수 있다.[5]

오픈소스이니셔티브

오픈소스는 소스코드를 알면 그 소프트웨어와 비슷한 것을 만들거나 소프트웨어에서 이용하고 있는 기술을 간단히 전용할 수 있다. 이에, 기업 등에서는 자사에서 개발한 소프트웨어의 소스코드를 극비로 하고 있으며, 이를 다른 사람에게 제공할 때는 사용료인 라이선스료를 받는다. 오픈소스의 개념은 소스코드를 공개하여 유용한 기술을 공유함으로, 전 세계의 누구나가 자유롭게 소프트웨어의 개발 및 개량에 참여할 수 있게 하는 것이 우수한 소프트웨어를 만드는 데 도움이 된다는 것에 바탕을 두고 있다. 하지만, 오픈소스라가 주목받게 되면서 이를 사용하는 사람에 따라 그 의미에 혼돈이 생기게 되었다. 이런 사태를 수습하기 위해서 오픈소스 이니셔티브(OSI) 단체에서 오픈소스정의(OSD)를 발표했다. 이 정의는 자유로운 재배포의 허가, 파생 소프트웨어 배포의 허가, 개인이나 집단의 차별 금지, 적용 분야 제한의 금지 등 10개의 항목으로 이루어져 있다. 이에 준거하여 소프트웨어 라이선스에는 오픈소스 인정 마크가 부여된다. 오픈소스정의는 개발자 커뮤니티 등에서 엄밀한 이론을 하는 경우에는 참조되지만, 사용자들이 일상적으로 사용하는 오픈소스라는 말이 오픈소스정의 내용을 가리키고 있다고는 볼 수 없다.[1]

활용[편집]

컴파일 방식[편집]

컴퓨터는 모든 명령을 중앙처리장치(CPU)가 처리하고 중앙처리장치는 모든 명령을 0과 1로 이해하고 실행한다. 중앙처리장치는 0과 1, 오직 두 가지 경우밖에 모르기 때문이다. 'A'라는 알파벳을 입력할 때 컴퓨터는 00110010와 같은 이진코드로 해석하고 명령을 처리한다. 즉, 사람의 언어는 컴퓨터가 이해하지 못하여 컴퓨터가 이해할 수 있는 통역사가 필요하며, 통역이 바로 컴파일이다.[6]

컴파일 방식은 소스코드를 컴퓨터가 바로 읽을 수 있도록 기계어로 변환 시키는 언어이다. 컴파일 방식은 기계어로 바로 번역시켜두고 실행하기 때문에 다른 방식에 비해서 실행 속도가 빠르다. 기계어로 번역이 되어버렸기 때문에 소스코드의 원본이 노출될 우려가 매우 적어 거의 없다. [7]

인터프리터 방식[편집]

인터프리터(Interpreter) 방식은 소스코드를 두고 그걸 한 줄씩 읽어가면서 실행하는 방식이다. 컴파일 방식과 다르게 그때그때 번역을 하면서 실행해야 하므로 실행 속도가 느린 편이다. 또한, 이는 소스코드를 바로 번역해서 실행하기 때문에 원본 소스코드가 그대로 노출된다는 단점이 있다. 하지만, 운영체제에 종속되지 않는다는 장점이 있다. 이 소스코드를 읽는 프로그램은 각 운영체제마다 따로 만들어져 있기 때문에 이를 어디 들고 가도 읽을 수 있다. 예를들어, 인터넷 웹 페이지를 리눅스(Linux), 안드로이드(Android), 윈도우(Windows) 등에서 다 같이 읽을 수 있다.[7]

런타임 이전에 기계어로 프로그래밍 언어를 변환하는 컴파일 방식과 다르게, 런타임 이후에 줄 단위로 해석하며 프로그램을 구동시킨다. 런타임에 직접 코드를 구동시키는 특징이 있기 때문에 실제 실행 시간은 느리며, 대신 런타임에 실시간 디버깅 및 코드 수정이 가능하다. 또한, 메모리를 별도로 할당받아 수행되지 않으며, 필요할 때 할당하여 사용한다. 이와 관련되어 코드의 흐름 자체도 실제 필요할 때, 실제 수행되어야 하는 시점에 수행되기 때문에 덕타이핑(Duck Typing) 이 가능한 측면이 있으나, 반대로 정적 분석이 되지 않는 트레이드오프(Trade off)를 갖고 있다. 대표적인 인터프리터 언어로는 자바스크립트(Javascript)와 같은 스크립팅 언어들이 있다. 하지만, 스크립트(Scrypt) 언어뿐 아니라 컴파일 이후의 동작에서 인터프릿(Interpret)을 수행하는 언어들도 많이 존재한다. 많은 프로그래밍 언어들의 인터프리터는 해석을 위한 가상머신(Virtual Machine)을 두고, 머신 위에서 인터 프릿을 수행하게 되는데, 이때 해석의 기반이 되는 머신들이 운영체제 환경들을 지원해 줌으로써, 해당 방식으로 인터프리터는 운영체제 및 플랫폼에 종속되지 않는 프로그램 구동이 가능하게 된다.[8]

하이브리드 방식[편집]

하이브리드 방식은 컴파일 방식과 인터프리터 방식의 장점을 섞어놓은 언어이다. 하이브리드 방식은 우선 소스코드를 바이트 방식으로 변경해둔다. 그리고 이 바이트 코드를 한 줄씩 읽어서 실행하는 방식이다. 일단 컴파일 방식에 비해서 속도 도 느리지만, 소스코드 원본의 노출 우려가 적다고 일반적으로 가르친다. 하지만, 프로그램을 이용하면 금세 소스코드로 복원되고, 운영체제에 종속되지 않는 장점이 있다. 이는 소스코드를 바이트 코드로 변경해둔 파일을 각 운영체제에 있는 인터프리터가 읽어주는 방식이기 때문이다. 하이브리드 방식을 이용하면 실행 속도가 인터프리터 방식에 비해서는 빠르다. 단, 컴파일 방식에 비해서는 느린 편이다.[7]

하이브리드 방식은 소스코드를 컴파일하여 중간 코드(바이트코드)를 생성한다. 중간 노드는 소스코드를 기계어로 번역해 놓은 상태로 실행 루팅과 라이브러리가 빠져있는 형태이다. 즉, 중간 코드는 컴파일 언어의 목적코드와 비슷한 형태이다. 이러한 중간 코드는 운영체제별로 존재하는 인터프리터에 의해 실행된다. 자바(Java)나 C샵(C#) 같은 하이브리드 언어는 소스코드를 중간 코드로 컴파일해 놓고, 운영체제별로 존재하는 자바 가상머신(JVM)과 닷넷 프레임 워크를 통해 코드의 수정이나 재컴파일 작업 없이 곧바로 프로그램을 실행할 수 있다.[9]

분류[편집]

절차지향 프로그래밍[편집]

절차지향 프로그래밍은 물이 위에서 아래로 흐르는 것처럼 순차적인 처리가 중요시되며, 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법이다. 대표적인 절차지향 언어에는 C 언어가 있다. 이는 컴퓨터의 작업 처리 방식과 유사하기 때문에 객체지향 언어를 사용하는 것에 비해 더 빨리 처리되어 시간적으로 유리하다. 이전에는 하드웨어와 소프트웨어의 개발 속도 차이가 크지 않았지만, 소프트웨어 언어의 발달과 컴파일러의 발달로 하드웨어가 소프웨어의 발달을 따라오지 못하는 상황이 발생했다. 이는 객체지향 언어가 등장하게 되는 계기로 작용하였다. 객체지향 프로그래밍은 개발하려는 것을 기능별로 묶어 모듈화를 함으로써 하드웨어가 같은 기능을 중복으로 연산하지 않도록 하고, 모듈을 재활용하기 때문에 하드웨어의 처리 양을 획기적으로 줄여주었다. 절차지향 프로그래밍 기법은 실행 순서가 정해져 있어 코드의 순서가 바뀌면 동일한 결과를 보장하기와 디버깅 및 유지 보수가 어렵다는 단점이 있지만, 컴퓨터의 처리 구조와 유사하여 실행 속도가 빠르다는 이점이 있다.[10]

객체지향 프로그래밍[편집]

객체지향 프로그래밍(OOP) 실제 세계를 모델링 하여 소프트웨어를 개발하는 방법이다. 객체지향 프로그래밍에서는 데이터와 절차를 하나의 덩어리로 묶어서 생각하게 된다. 이는 마치 컴퓨터 부품을 하나씩 사다가 컴퓨터를 조립하는 것과 같은 방법이다. 객체지향 프로그래밍의 캡슐화는 관련된 데이터와 알고리즘 코드가 하나의 묶음으로 정리되어 개발자가 만들었으며, 관련된 코드와 데이터가 묶여있고 오류가 없어 사용이 편리하다. 데이터를 감추고 외부 세계와의 상호작용은 메소드를 통하는 방법이며, 라이브러리로 만들어 업그레이드하면 쉽게 바꿀 수 있다. 상속은 부모 클래스를 재사용해서 자식 클래스를 빨리 개발할 수 있으며, 반복된 코드의 중복을 줄여주고, 유지 보수의 편리성을 제공해 준다. 부모 클래스를 한 번만 수정하여 자식 클래스를 수정할 필요가 없으며, 객체의 다형성을 구현할 수 있다. 객체지향 프로그래밍의 다형성은 처리 속도가 절차지향보다 느려서 설계에 많은 시간요소가 들어간다는 단점이 있지만, 코드의 재활용성이 높고 코딩이 절차지향보다 간편하여 디버깅이 쉽다.[10]

  • 캡슐화(encapsulation)
캡슐화는 중요한 데이터를 보존, 보호한다. 일반적으로 연관 있는 변수와 함수를 클래스로 묶는 작업을 말한다. 그런데 이 작업은 클래스 만드는 작업과 비슷하다고 여길 수도 있지만, 은닉성이 있어서 클래스에 담는 내용 중 중요한 데이터나 기능을 외부에서 접근하지 못하게 할 수 있다. 객체의 필드와 메소드를 하나로 묶어 실제 구현 내용을 외부에 감춘다. 외부 객체는 객체 내부의 구조를 얻지 못하며, 객체가 노출해서 제공하는 필드와 메소드만 이용할 수 있다. 필드와 메소드를 캡슐화하여 보호하는 이유는 외부의 잘못된 사용으로 인해 객체가 손상되지 않도록 하는 데 있으며, 자바 언어는 캡슐화된 멤버를 노출시킬 것인지 숨길 것인지를 결정하기 위해 접근 제한자(Access Modifier)를 사용한다.[11]
  • 상속(Inheritance)
일반적으로 부모가 자식에게 물려주는 행위 및 부모가 자식을 선택해서 물려주는 행위의 의미 이지만, 객체지향 프로그래밍에서의 상속은 이와 반대로 자식이 부모를 선택해서 물려받는 것을 의미한다. 자식인 하위 및 파생 클래스가 부모인 상위 클래스의 멤버를 물려 받는다. 여기서 상속 대상은 부모의 필드와 메소드이다. 이는 부모 클래스를 재사용해서 자식 클래스를 빨리 개발할 수 있다. 반복된 코드의 중복을 줄여주며, 유지 보수의 편리성을 제공해 준다. 또한, 부모 클래스를 한 번만 수정하여 자식 클래스를 수정할 필요가 없다. 상속은 객체의 다형성을 구현할 수도 있다.[11]
  • 다형성(polymorphism)
다형성은 같은 타입이지만, 실행 결과가 다양한 객체를 대입 및 이용할 수 있는 성질이다. 부모 타입에는 모든 자식 객체가 대입될 수 있으며 자식 타입은 부모 타입으로 자동 타입 변환이 된다. 다형성은 객체를 부품화시킬 수 있다. 즉, 자동차란 객체가 있을 경우 자동차를 설계를 할 때 타이어 부분에 사용된 부분을 타이어 타입이라고 가정한다면 자동차의 타이어 타입으로 한국 타이어와 금호 타이어가 있다고 한다면 어떤 타이어 타입을 사용하느냐에 따라 각 타이어의 성능은 다르게 나올 수 있다는 것이 다형성이라는 측면이다.[11]

각주[편집]

  1. 1.0 1.1 시큐비엠 Security_IBM, 〈소스코드란?〉, 《티스토리》, 2018-10-01
  2. Code.D, 〈소스코드와 오픈소스〉, 《티스토리》, 2017-02-13
  3. 소스 코드 위키백과 - https://ko.wikipedia.org/wiki/%EC%86%8C%EC%8A%A4_%EC%BD%94%EB%93%9C
  4. 소스 코드 리브레 위키 - https://librewiki.net/wiki/%EC%86%8C%EC%8A%A4_%EC%BD%94%EB%93%9C
  5. OSS, 〈공개SW 가이드/보고서〉, 《오픈소스소프트웨어》, 2017-08-24
  6. Mark J, 〈컴파일이란〉, 《네이버 블로그》, 2017-05-11
  7. 7.0 7.1 7.2 lazyig, 〈프로그래밍 언어의 종류〉, 《개인 블로그》, 2018-10-01
  8. Mark J, 〈컴파일러(Compiler) 와 인터프리터(Interpreter) 의 개념과 차이점〉, 《네이버 블로그》, 2019-08-08
  9. ㅇㅏㅈㅏ, 〈인터프리터/컴파일러/하이브리드〉, 《네이버 블로그》, 2019-08-08
  10. 10.0 10.1 불곰, 〈절차지향 VS 객체지향〉, 《티스토리》, 2018-12-22
  11. 11.0 11.1 11.2 재희 jaiyah, 〈객체지향 프로그래밍의 캡슐화, 상속, 다형성〉, 《티스토리》, 2016-09-29

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 소스코드 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.