본문으로 이동

소스 코드

한울위키, 우리 모두의 백과사전.
섬네일을 만드는 중 오류 발생: 이 문서는 프로그래밍에 관한 것입니다. 영화에 대해서는 소스 코드 (영화) 문서를 참고하십시오.
C 언어로 작성된 "Hello, World!" 프로그램의 간단한 소스 코드. 1974년 벨 연구소의 브라이언 커니핸이 저술한 중요한 책인 C 프로그래밍 언어 (책)에서 가져왔다.[1]
프로그램 실행
일반 개념
코드의 종류
컴파일 전략
저명한 런타임
저명한 컴파일러 및 툴체인
파일:Python script.svg
파이썬 프로그래밍 언어의 소스 코드. 알아보기 쉽게 하기 위해 여러 가지 색으로 강조되어 있다.

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

배경

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

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

구성

섬네일을 만드는 중 오류 발생:  소프트웨어 구성 관리 문서에 이 부분의 추가 정보가 있습니다.

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

파일:Code comments.svg
더 복잡한 자바 소스 코드 예시. 객체 지향 프로그래밍 스타일로 작성되었으며, 상용구 코드를 보여준다. 빨간색으로 표시된 프롤로그 주석, 녹색으로 표시된 인라인 주석, 파란색으로 표시된 프로그램 문장이 있다.

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

목적

평가

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

통신

소스 코드는 또한 당사자 간에 알고리즘을 전달하는 데 사용된다. 예를 들어, 온라인이나 책에 있는 스니펫이 있다.[13]

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

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

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

수정

섬네일을 만드는 중 오류 발생:  소프트웨어 개발 및 소프트웨어 유지보수 문서를 참고하십시오.

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

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

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

컴파일 및 실행

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

이식성

섬네일을 만드는 중 오류 발생:  소프트웨어 이식성 문서에 이 부분의 추가 정보가 있습니다.

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

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

품질

섬네일을 만드는 중 오류 발생:  소프트웨어 품질 문서에 이 부분의 추가 정보가 있습니다.

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

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

저작권 및 라이선스

섬네일을 만드는 중 오류 발생:  소프트웨어 저작권 및 소프트웨어 사용권 문서에 이 부분의 추가 정보가 있습니다.
섬네일을 만드는 중 오류 발생:  자유-오픈 소스 소프트웨어의 역사 문서를 참고하십시오.

상황은 전 세계적으로 다르지만, 1974년 이전 미국에서는 소프트웨어와 그 소스 코드는 저작권 보호를 받을 수 없었으므로 항상 퍼블릭 도메인 소프트웨어였다.[39] 1974년에 미국 신기술 사용에 관한 위원회 (CONTU)는 "컴퓨터 프로그램은 저작자의 독창적인 창작물을 구현하는 한, 저작권의 적절한 대상이 된다"고 결정했다.[40][41]

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

같이 보기

각주

  1. ↑ Kernighan, Brian W. “Programming in C: A Tutorial” (PDF). Bell Laboratories, Murray Hill, N. J. 2015년 2월 23일에 원본 문서 (PDF)에서 보존된 문서. 
  2. ↑ Gabbrielli & Martini 2023, 519쪽.
  3. ↑ Gabbrielli & Martini 2023, 520–521쪽.
  4. ↑ Gabbrielli & Martini 2023, 522쪽.
  5. ↑ Gabbrielli & Martini 2023, 521쪽.
  6. ↑ 가 나 Tracy 2021, 1쪽.
  7. ↑ 가 나 Tracy 2021, 121쪽.
  8. ↑ Lin et al. 2001, 238–239쪽.
  9. ↑ Katyal 2019, 1194쪽.
  10. ↑ 가 나 Tracy 2021, 122–123쪽.
  11. ↑ O'Regan 2022, 230–231, 233, 377쪽.
  12. ↑ Foster 2014, 249, 274, 280, 305쪽.
  13. ↑ 가 나 다 Spinellis, D: Code Reading: The Open Source Perspective. Addison-Wesley Professional, 2003. ISBN 0-201-79940-5
  14. ↑ "Art and Computer Programming" ONLamp.com 보관됨 20 2월 2018 - 웨이백 머신, (2005)
  15. ↑ Kaczmarek et al. 2018, 68쪽.
  16. ↑ Katyal 2019, 1186–1187쪽.
  17. ↑ 가 나 Katyal 2019, 1195쪽.
  18. ↑ 가 나 다 Offutt, Jeff (January 2018). “Overview of Software Maintenance and Evolution”. 《조지 메이슨 대학교 컴퓨터 과학과》. 2024년 5월 5일에 확인함. 
  19. ↑ Tripathy & Naik 2014, 296쪽.
  20. ↑ Tripathy & Naik 2014, 297쪽.
  21. ↑ Tripathy & Naik 2014, 318–319쪽.
  22. ↑ 가 나 O'Regan 2022, 375쪽.
  23. ↑ Tripathy & Naik 2014, 94쪽.
  24. ↑ 가 나 Dooley 2017, 272쪽.
  25. ↑ O'Regan 2022, 18, 21쪽.
  26. ↑ O'Regan 2022, 133쪽.
  27. ↑ Kaczmarek et al. 2018, 348–349쪽.
  28. ↑ Sebesta 2012, 28쪽.
  29. ↑ Galin 2018, 26쪽.
  30. ↑ O'Regan 2022, 68, 117쪽.
  31. ↑ O'Regan 2022, 3, 268쪽.
  32. ↑ 가 나 Varga 2018, 12쪽.
  33. ↑ Varga 2018, 5쪽.
  34. ↑ Tripathy & Naik 2014, 296–297쪽.
  35. ↑ Tripathy & Naik 2014, 309쪽.
  36. ↑ Varga 2018, 6–7쪽.
  37. ↑ Varga 2018, 7쪽.
  38. ↑ Varga 2018, 7–8쪽.
  39. ↑ Liu, Joseph P.; Dogan, Stacey L. (2005). 《Copyright Law and Subject Matter Specificity: The Case of Computer Software》 (영어). 《New York University Annual Survey of American Law》 61. 2021년 6월 25일에 원본 문서에서 보존된 문서. 
  40. ↑ Apple Computer, Inc. v. Franklin Computer Corporation Puts the Byte Back into Copyright Protection for Computer Programs 보관됨 7 5월 2017 - 웨이백 머신 in Golden Gate University Law Review Volume 14, Issue 2, Article 3 by Jan L. Nussbaum (January 1984)
  41. ↑ Lemley, Menell, Merges and Samuelson. Software and Internet Law, p. 34.
  42. ↑ Boyle 2003, 45쪽.
  43. ↑ Morin et al. 2012, Open Source versus Closed Source.
  44. ↑ Sen et al. 2008, 209쪽.
  45. ↑ Morin et al. 2012, Free and Open Source Software (FOSS) Licensing.
  46. ↑ O'Regan 2022, 106쪽.

외부 링크

섬네일을 만드는 중 오류 발생:
위키미디어 공용에 [{{fullurl:Commons:모듈:WikidataIB 508번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).|uselang=ko}} 소스 코드] 주제와 관련된 미디어 분류가 있습니다.

모듈:Authority_control 159번째 줄에서 Lua 오류: attempt to index field 'wikibase' (a nil value).

원본 주소 "https://www.hanul.wiki/w/index.php?title=소스_코드&oldid=50802"