방송대 프로그래밍언어론 2강: 언어 발전과 구현·평가 기준
어떤 언어가 가장 좋은가라는 질문에는 조건 없는 정답이 없다. 계산, 교육, 시스템 개발, 안전성, 웹처럼 시대마다 해결하려는 문제가 달랐고, 사람이 쓴 소스를 기계가 실행하게 만드는 방법도 달라졌다. 언어의 발전사를 ‘새 요구에 대한 선택’으로 읽으면 구현 방식의 차이와 평가 기준 사이의 절충까지 한 흐름으로 판단할 수 있다.
언어의 역사는 더 좋은 문법의 순위표가 아니다
학습을 위해 두 언어 후보를 가정해 보자. 후보 A는 실행 전에 많은 오류를 검사하지만 새 기능을 자유롭게 붙이기 어렵다. 후보 B는 표현 제약이 적지만 실행 전에 확인할 수 있는 오류가 적다. A와 B 가운데 어느 하나를 무조건 우수하다고 말하려면 먼저 사용 목적과 평가 기준을 숨긴 셈이 된다.
프로그래밍 언어의 발전도 같은 방식으로 읽어야 한다. 새 언어는 이전 언어의 모든 특성을 단순히 개선해서 등장한 것이 아니라, 특정 시대의 계산 환경과 응용 분야, 표현 방식에서 중요해진 문제에 답하며 나타났다. 따라서 연도와 이름을 외우기 전에 다음 세 질문을 붙인다.
- 어떤 문제가 중요해졌는가? 과학 계산, 사무 처리, 교육, 시스템, 안전성, 웹처럼 요구를 찾는다.
- 어떤 표현이나 실행 방식으로 대응했는가? 구조화, 함수형, 객체지향, 타입 검사, 가상기계 등을 연결한다.
- 무엇을 얻고 무엇과 절충했는가? 가독성, 작성력, 신뢰성, 효율성, 유연성의 변화를 비교한다.
판단 핵심: 나중에 등장한 언어가 항상 앞선 언어를 대체하는 것은 아니다. 각 언어가 해결하려 한 문제와 설계 선택을 함께 보아야 발전의 의미가 드러난다.
컴퓨터와 운영체제의 변화가 언어의 사용 환경을 넓혔다
계산 자동화는 처음에는 상상 속 기계의 설계에서 출발했고, 전자식 컴퓨터가 등장하면서 전자 신호를 이용한 계산으로 옮겨 갔다. 프로그램 저장 방식의 컴퓨터에서는 프로그램과 처리기가 분리되며, 저장한 명령을 바꾸어 같은 기계로 여러 작업을 수행할 수 있는 토대가 마련되었다.
운영체제의 발전도 언어 사용 방식에 영향을 주었다. 일괄처리 환경에서는 작업을 모아 처리했고, 관리자 역할을 대신하는 프로그램이 등장했다. 시분할 환경에서는 여러 사용자가 한 컴퓨터를 함께 사용할 수 있게 되었다. 이어 DOS와 개인용 컴퓨터가 보급되고, GUI 운영체제와 Linux가 발전하면서 프로그래밍은 제한된 계산실을 넘어 더 다양한 사용자와 응용으로 확장되었다.
연결해서 읽기: 하드웨어와 운영체제의 변화는 배경 사건에 그치지 않는다. 사용자가 늘고 응용이 다양해질수록 언어에는 더 쉬운 작성, 다양한 추상화, 이식성과 안정적인 실행 같은 새로운 요구가 생긴다.
1950년대는 계산을 기호와 구조로 표현하기 시작한 시기다
1950년대의 초기 언어는 사람이 계산과 알고리즘을 기계 명령보다 높은 수준에서 표현할 수 있게 했다. 이 시기의 언어를 하나의 계보로만 보지 말고, 서로 다른 표현 문제에 대한 세 가지 응답으로 구분하면 기억하기 쉽다.
| 언어 | 중심 문제 | 강의에서 강조한 변화 |
|---|---|---|
| Fortran | 과학 계산을 수식과 문장으로 표현 | John Backus가 개발했으며 수식·문장·제어문을 사용한 과학 계산용 언어 |
| Algol | 알고리즘을 구조적으로 기술 | ACM-GAMM 국제위원회가 설계한 알고리즘 기술 언어로 구조화 프로그래밍의 발전에 연결 |
| LISP | 함수 적용으로 계산을 표현 | John McCarthy가 설계한 초기 함수형 언어 |
Fortran은 계산식을 기계 명령보다 익숙한 형태로 옮기는 데, Algol은 알고리즘의 블록과 제어 구조를 나타내는 데, LISP는 함수를 중심으로 계산을 구성하는 데 초점을 두었다. 같은 시기의 언어라도 해결하려 한 표현 문제가 다르다.
1960년대는 응용 분야와 사용자층이 갈라지기 시작했다
1960년대에는 하나의 언어가 모든 목적을 만족시키기보다 업무와 학습 목적에 맞춘 선택이 두드러졌다. COBOL은 Grace Hopper가 이끄는 미 해군 팀의 개발과 관련되며, 레코드 타입을 사용한 사무용 언어로 소개된다. BASIC은 이름 그대로 초보자를 위한 범용 기호 명령 코드로서 교육 목적을 강조했다. Simula는 시뮬레이션을 다루며 객체지향 개념의 등장과 연결된다.
반면 PL/I는 여러 언어의 기능을 한데 모으려 했지만 결과적으로 지나치게 복잡해졌다고 강의는 평가한다. 이 사례는 기능 수가 많으면 표현력이 늘 수 있어도, 언어 전체를 배우고 일관되게 사용하는 부담도 함께 커질 수 있음을 보여 준다.
역사에서 얻는 설계 기준: 기능을 더하는 것과 좋은 언어를 만드는 것은 같은 일이 아니다. 추가 기능이 기존 기능과 규칙적으로 조합되는지, 복잡도를 통제할 수 있는지를 함께 따져야 한다.
1970년대는 단순화와 패러다임의 분화가 함께 진행됐다
1970년대에는 교육과 시스템 개발을 위한 구조화 언어가 자리 잡는 동시에, 논리·객체·안전성·타입 같은 서로 다른 관점이 뚜렷해졌다.
| 문제 또는 관점 | 관련 언어 | 강의의 핵심 |
|---|---|---|
| 구조화 교육 | Pascal | Niklaus Wirth가 개발한 차세대 교육용 언어 |
| 시스템 개발 | C | Dennis Ritchie가 개발한 Unix용 시스템 언어로 여러 후속 언어에 영향 |
| 논리적 선언 | Prolog | 초기의 대표적인 선언적 논리 언어 |
| 객체와 상호작용 | Smalltalk | 객체지향 언어 발전과 GUI·마우스 도입을 강조 |
| 안전성 | Ada | 미국 국방성 공모와 관련되며 높은 복잡성 때문에 첫 컴파일러까지 긴 시간이 걸림 |
| 타입과 간결성 | ML, Scheme | ML은 정적 타입 검사·타입 추론·패턴 검사·예외 처리를, Scheme은 간결한 LISP 계열 교육을 강조 |
이 시기를 ‘언어가 단순해졌다’는 한 문장으로만 외우면 Ada와 ML, Prolog 같은 흐름을 놓친다. 언어 전체를 단순화하려는 요구와 특정 문제를 더 정확하게 표현하려는 전문화가 동시에 진행되었다고 보는 편이 적절하다.
1980년대 이후에는 기존 관점의 결합과 대중화가 두드러졌다
1980년대에는 기존 언어의 계보에 객체지향이나 다른 패러다임을 결합하는 움직임이 나타났다. Common Lisp는 방대한 LISP 계열을 통합하며 함수형과 객체지향 패러다임을 함께 지원했다. Objective-C는 C를 바탕으로 객체지향 개념을 결합했고, C++는 Bjarne Stroustrup이 C에 클래스 개념을 도입하며 발표했다. Perl은 Larry Wall이 설계한 문자열 처리 언어로 정규식 기반의 패턴 매칭을 강조했다.
1990년대 이후에는 언어가 더 넓은 사용자와 실행 환경으로 확산되었다. Java는 James Gosling이 이끈 팀이 개발했으며 JVM을 중심으로 임베디드 컴퓨팅에서 웹브라우저로 활용 영역이 이어졌다. JavaScript는 웹 프로그래밍 언어로 등장했고 여러 변종 언어로 발전했다. Python은 Guido van Rossum이 만든 빠른 프로토타이핑·스크립트 언어로 동적 언어와 다중 패러다임을 지향했다. Haskell은 국제위원회가 만든 순수 함수형 언어로 소개된다.
여기서 중요한 변화는 특정 패러다임 하나가 승리했다는 결론이 아니다. 서로 다른 표현 관점을 한 언어에 결합하거나, 가상 실행 환경과 웹 같은 새로운 배포 환경에 맞추며 언어 선택지가 넓어진 것이다.
프로그램이 실행되려면 저장장치에서 CPU까지 이동해야 한다
역사에서 실행 원리로 관점을 옮기면 언어 구현이 필요한 이유가 분명해진다. 컴퓨터의 CPU, 메모리, 저장장치와 입출력장치는 버스로 연결된다. 전원을 켜면 ROM의 BIOS가 하드웨어를 점검하고 저장장치의 부트로더를 실행한다. 부트로더는 운영체제를 메모리에 적재해 실행한다.
사용자가 실행한 프로그램도 CPU가 곧바로 저장장치의 파일을 읽는 것으로 끝나지 않는다. 실행할 프로그램과 필요한 데이터가 메모리에 놓이고, CPU는 메모리의 명령어를 인출 → 해석 → 실행하는 주기를 반복한다.
- 인출: 다음에 처리할 명령어를 메모리에서 가져온다.
- 해석: 명령이 요구하는 연산과 피연산자를 판별한다.
- 실행: 계산, 이동, 비교, 분기 같은 동작을 수행한다.
- 반복: 다음 명령으로 이동하여 같은 주기를 계속한다.
오개념 교정: 소스 파일이 저장장치에 있다는 사실만으로 CPU가 그 고급 언어 문장을 직접 실행하는 것은 아니다. CPU가 수행할 수 있는 표현으로 번역하거나, 실행 중 해석해 주는 구현 계층이 필요하다.
기계어와 고급 언어 사이의 간극을 번역기가 메운다
기계어는 CPU가 이해하고 수행하는 이진수 형태의 명령어다. 사람에게는 작성과 이해가 어렵다. 어셈블리어는 기계어에 거의 일대일로 대응하는 기호를 사용하지만 특정 CPU에 종속되므로 이식성이 매우 낮다. 고급 프로그래밍 언어는 사람에게 가까운 표현과 기계 독립성을 제공하지만, 그대로는 CPU가 처리할 수 없다.
따라서 사람이 작성한 소스 프로그램과 CPU가 수행할 수 있는 목적 프로그램 사이의 간극을 메워야 한다. 핵심 질문은 ‘번역이 필요한가?’가 아니라 언제, 어느 범위까지 번역하는가?이다.
| 표현 수준 | 사람의 이해 | 기계 의존성 | 실행을 위한 과제 |
|---|---|---|---|
| 기계어 | 매우 어려움 | CPU에 직접 종속 | CPU가 바로 수행할 수 있음 |
| 어셈블리어 | 기계어보다 기호가 분명함 | CPU에 거의 일대일 대응 | 기계어로 옮겨야 함 |
| 고급 언어 | 문제와 사람에 가까운 표현 | 특정 기계에서 비교적 독립적 | 해석 또는 번역 계층이 필요함 |
인터프리터·컴파일러·하이브리드는 번역 시점이 다르다
강의의 세 구현 방법은 같은 소스 프로그램이 실행 결과에 도달하는 경로로 비교하면 쉽게 구분된다.
| 방식 | 실행 경로 | 해석이 일어나는 시점과 위치 |
|---|---|---|
| 인터프리터 | 소스 프로그램 → 인터프리터 → 하드웨어 → 결과 | 실행하면서 고수준 명령을 하나씩 해석하며 CPU의 인출·해석·실행 주기를 흉내 냄 |
| 컴파일러 | 소스 프로그램 → 컴파일러 → 기계어 코드 → 하드웨어 → 결과 | 실행 전에 해석과 번역을 미리 수행하여 CPU가 처리할 형태를 만듦 |
| 하이브리드 | 소스 프로그램 → 작은 컴파일러 → 중간 코드 → 가상기계 → 결과 | 중간 코드까지 먼저 컴파일하고, 가상기계의 인터프리터가 이후 실행을 담당함 |
학습용으로 ‘할인 금액 계산’ 소스를 실행한다고 가정하자. 인터프리터 방식은 실행 요청 뒤 소스 명령을 차례로 해석한다. 컴파일 방식은 배포 전 소스 전체를 기계어 코드로 만들어 놓고 실행 시 그 코드를 사용한다. 하이브리드 방식은 먼저 기계와 소스 사이의 중간 코드로 바꾸고, 실행 환경의 가상기계가 이를 해석한다.
구분 질문: 소스가 바로 실행 환경으로 들어가는가, 미리 기계어 코드가 만들어지는가, 아니면 중간 코드와 가상기계를 거치는가를 순서대로 확인한다.
언어의 세 요구사항은 평가 질문의 출발점이 된다
프로그래밍 언어는 프로그래머의 아이디어를 충분히 나타내고, 작성한 프로그램을 변화에 맞게 고칠 수 있으며, 실제 컴퓨터에서 실행할 수 있어야 한다. 강의는 이를 표현 풍부성, 유지보수성, 실행 가능성이라는 세 요구사항으로 정리한다.
| 요구사항 | 핵심 질문 | 관련 평가 기준 |
|---|---|---|
| 표현 풍부성 | 프로그래머의 아이디어와 필요한 기능을 나타낼 수 있는가? | 작성력, 직교성, 일관성, 확장성, 유연성 |
| 유지보수성 | 읽고 검사하며 변화에 맞게 수정하기 쉬운가? | 작성력, 가독성, 신뢰성, 직교성, 일관성, 확장성, 효율성, 유연성, 이식성 |
| 실행 가능성 | 오류 가능성과 실행 비용을 관리하며 실제 환경에서 수행되는가? | 신뢰성, 효율성, 이식성 |
하나의 평가 기준이 여러 요구사항에 동시에 기여할 수 있다. 예를 들어 작성력은 아이디어를 표현하는 데 필요하면서 수정 가능한 코드를 만드는 데도 관련된다. 이식성은 다른 환경에서 실행할 수 있게 하므로 실행 가능성과 유지보수성에 모두 연결된다.
설계 원칙은 기능을 더하는 방법까지 평가한다
규칙성은 언어 기능이 잘 조합될 수 있어야 한다는 원칙이다. 일반성은 기능이 넓은 상황에 적용되는지, 직교성은 기능끼리 불필요하게 간섭하지 않는지, 일관성은 유사한 기능을 비슷한 형태로 표현하는지를 살핀다.
추상화 지원은 실세계 대상을 필요한 관점으로 나타내고 그 대상을 연산할 수 있게 하는 능력이다. 데이터 추상화, 제어 추상화, 추상 데이터 타입 정의가 이 원칙과 연결된다. 복잡도 제어는 복잡한 대상과 처리 방법을 관리하는 원칙이며 캡슐화와 모듈화가 대표 수단이다.
기능이 많아도 서로 조합할 때 예외 규칙이 계속 생기면 규칙성이 낮을 수 있다. 추상화를 제공해도 내부 세부가 모두 노출되면 복잡도 제어가 약할 수 있다. 그러므로 기능 목록보다 기능이 결합되고 감춰지고 나뉘는 방식을 살펴야 한다.
아홉 평가 기준은 서로 다른 질문에 답한다
| 평가 기준 | 판단 질문 | 혼동 방지 기준 |
|---|---|---|
| 작성력 | 수식·문장·기능을 쉽게 표현하는가? | 읽는 사람보다 작성하는 사람의 표현 부담에 초점 |
| 가독성 | 작성된 프로그램을 쉽게 이해하는가? | 짧은 코드와 이해하기 쉬운 코드를 동일시하지 않음 |
| 신뢰성 | 프로그램이 오류에 빠질 가능성을 줄이는가? | 빠른 실행보다 올바른 동작 가능성에 초점 |
| 직교성 | 기능이 간섭 없이 자유롭게 조합되는가? | 같은 형태의 표현인 일관성과 구분 |
| 일관성 | 유사한 기능을 같은 형태로 나타내는가? | 기능 조합의 독립성인 직교성과 구분 |
| 확장성 | 사용자가 새로운 기능을 추가할 수 있는가? | 기존 표현을 폭넓게 허용하는 유연성과 구분 |
| 효율성 | 작성된 프로그램이 효율적으로 수행되는가? | 개발 편의보다 실행 자원과 비용에 초점 |
| 유연성 | 원하는 내용을 제약 없이 수용하는가? | 기능 추가 자체보다 표현의 허용 범위에 초점 |
| 이식성 | 프로그램을 다른 실행 환경으로 옮길 수 있는가? | 한 환경에서의 실행 속도와 구분 |
좋은 선택은 상충하는 기준의 우선순위를 밝힌다
평가 기준은 모두 높을수록 좋다고 말하기 쉽지만 실제 설계와 선택에서는 비용이 생긴다. 강의는 대표적인 세 절충 관계를 제시한다.
- 효율성 ↔ 신뢰성: 사용자는 검사 비용이 적고 빠른 실행을 원할 수 있지만, 개발자는 오류를 줄이기 위해 더 많은 검사를 요구할 수 있다.
- 가독성 ↔ 작성력: 단순한 기능은 이해하기 쉽지만, 작성자는 복잡하더라도 많은 기능을 지원받아 짧게 표현하기를 원할 수 있다.
- 신뢰성 ↔ 유연성: 안전을 위한 제약은 오류 가능성을 줄이지만, 프로그래머가 허용받는 표현 범위는 좁아질 수 있다.
앞에서 가정한 후보 A와 B를 다시 판단해 보자. 오류 비용이 크고 변경 후 검증이 중요한 프로그램이라면 A의 검사와 신뢰성에 더 높은 가중치를 둘 수 있다. 빠른 실험과 표현의 자유가 중요한 학습용 탐색이라면 B의 유연성을 더 높게 볼 수 있다. 이는 A 또는 B의 절대적 우열이 아니라 상황별 기준의 우선순위다.
- 프로그램의 사용자와 개발자가 가장 피해야 할 실패를 적는다.
- 아홉 기준 가운데 우선순위가 높은 두세 가지를 고른다.
- 높이려는 기준 때문에 낮아질 수 있는 반대 기준을 찾는다.
- 구현 방식, 실행 환경, 팀의 경험을 포함해 허용 가능한 절충점을 정한다.
언어 선택에는 기술 특성 밖의 학습 가치도 포함된다
강의는 언어 선택에서 해당 언어를 사용하는 커뮤니티가 활발하고 호의적인지, 뚜렷한 응용 분야가 있는지, 아직 경험하지 못한 프로그래밍 패러다임을 배울 수 있는지를 살피라고 제안한다. 즉 언어 선택은 현재 프로그램 하나의 실행 성능만 고르는 일이 아니다.
선택 전에 다음 세 축을 함께 점검할 수 있다.
- 문제 적합성: 목표 응용에서 필요한 표현과 추상화를 지원하는가?
- 실행 적합성: 번역 방식과 실행 환경이 배포·효율·이식성 요구에 맞는가?
- 성장 적합성: 커뮤니티의 도움을 받을 수 있고 새로운 패러다임을 학습할 기회가 있는가?
최종 선택 공식: 언어의 이름이나 등장 연도만 보지 말고 ‘해결할 문제 → 실행 경로 → 평가 기준 → 허용할 절충 → 학습·커뮤니티 환경’ 순서로 판단한다.
핵심 개념 정리
- 발전의 의미: 각 시대의 언어는 과학 계산, 업무, 교육, 구조화, 패러다임, 안전성, 웹과 같은 서로 다른 요구에 대응했다.
- 실행의 전제: CPU는 메모리의 명령을 인출·해석·실행하며, 고급 언어와 기계어 사이에는 구현 계층이 필요하다.
- 구현 경로: 인터프리터는 실행 중 소스를 해석하고, 컴파일러는 실행 전에 기계어 코드로 번역하며, 하이브리드는 중간 코드와 가상기계를 사용한다.
- 설계 원칙: 규칙성은 기능 조합, 추상화 지원은 핵심 표현, 복잡도 제어는 캡슐화·모듈화를 점검한다.
- 평가 구조: 작성력부터 이식성까지 아홉 기준은 표현 풍부성, 유지보수성, 실행 가능성 요구에 여러 방식으로 연결된다.
- 절충 판단: 효율성과 신뢰성, 가독성과 작성력, 신뢰성과 유연성은 사용 목적에 따라 우선순위를 조정해야 한다.
언어를 비교할 때 먼저 그 언어가 어떤 시대적·응용 문제에 답했는지 찾고, 소스가 실행 결과로 바뀌는 경로를 그린다. 이어 표현·유지보수·실행 요구를 아홉 평가 기준으로 구체화한 뒤, 서로 상충하는 기준 가운데 현재 과제에 중요한 것을 고른다. 이 순서는 다음 차시에서 프로그래밍 패러다임을 비교할 때도 ‘무엇을 어떤 관점으로 표현하는가’를 판단하는 기반이 된다.
예상문제 10선
1. 1950년대 초기 언어와 강의에서 강조한 특징의 연결로 옳은 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ④
- ① 오답: 논리 언어의 흐름은 1970년대 Prolog와 연결되며 Fortran은 과학 계산용으로 소개된다.
- ② 오답: 레코드 타입과 사무 처리는 1960년대 COBOL의 특징이다.
- ③ 오답: LISP는 초기 함수형 언어이며 구조화 교육용이라는 설명은 Pascal과 더 가깝다.
- ④ 정답: Fortran은 수식·문장·제어문으로 과학 계산을 표현하려는 초기 언어다.
2. 프로그래밍 언어 발전사를 해석한 주장 중 수정이 필요한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 언어를 당시의 계산·교육·업무·시스템 요구와 연결한 올바른 해석이다.
- ② 정답: 언어는 서로 다른 목적과 절충을 가지므로 등장 시점만으로 모든 기준의 우열을 정할 수 없다.
- ③ 오답: 기능을 많이 합치면 오히려 복잡해질 수 있다는 강의의 사례와 맞는다.
- ④ 오답: Pascal·C의 구조화 흐름과 Prolog·Smalltalk·ML 등 다양한 관점이 함께 등장했다.
3. 컴퓨터 전원을 켠 뒤 운영체제가 실행되기까지의 순서로 가장 적절한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ①
- ① 정답: ROM의 BIOS가 점검을 수행하고 저장장치의 부트로더가 운영체제를 메모리에 올린다.
- ② 오답: 운영체제가 실행되려면 BIOS와 부트로더 단계가 먼저 진행되어야 한다.
- ③ 오답: 부트로더의 목적은 운영체제를 종료하는 것이 아니라 메모리에 적재해 실행하는 것이다.
- ④ 오답: CPU가 고급 언어 소스를 직접 해석하여 운영체제를 컴파일하는 순서가 아니다.
4. CPU가 메모리에 적재된 프로그램의 명령어를 수행할 때 반복하는 기본 주기는?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ③
- ① 오답: 프로그램 개발·유통의 일부 과정이며 CPU 명령 처리 주기가 아니다.
- ② 오답: 데이터 관리에서 가능한 동작을 나열했지만 명령어 처리의 기본 단계가 아니다.
- ③ 정답: CPU는 다음 명령을 가져오고 뜻을 판별한 뒤 해당 동작을 수행한다.
- ④ 오답: 언어 설계에서 복잡성을 다루는 개념이며 CPU의 명령 실행 단계가 아니다.
5. 인터프리터와 컴파일러의 차이를 올바르게 설명한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 실행 중 문장 해석과 사전 번역의 역할을 서로 뒤바꿨다.
- ② 정답: 두 방식의 결정적인 차이는 고수준 명령을 해석·번역하는 시점과 실행 경로다.
- ③ 오답: 중간 코드와 가상기계의 결합은 하이브리드 구현의 특징이다.
- ④ 오답: 두 구현 모두 프로그래밍 언어의 소스와 컴퓨터 실행 사이를 연결한다.
6. 하이브리드 구현에서 소스 프로그램이 실행되는 경로로 알맞은 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ④
- ① 오답: 하드웨어가 고급 언어 소스를 직접 해석하지 않으며 중간 코드는 먼저 컴파일되어 나온다.
- ② 오답: 실행 경로에는 중간 코드 생성과 가상기계 해석이 필요하다.
- ③ 오답: BIOS와 부트로더는 컴퓨터 시동 과정이며 하이브리드 언어 구현의 번역 단계가 아니다.
- ④ 정답: 사전 컴파일과 실행 중 해석을 중간 코드·가상기계로 결합한 경로다.
7. 두 언어 기능이 서로 간섭하지 않고 자유롭게 조합되는지를 평가하려 한다. 적용할 기준은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ③
- ① 오답: 이식성은 프로그램을 다른 실행 환경으로 옮길 수 있는지를 묻는다.
- ② 오답: 효율성은 작성된 프로그램의 실행 비용과 수행 효율을 평가한다.
- ③ 정답: 기능 사이의 간섭이 적고 독립적으로 조합되는 성질이 직교성이다.
- ④ 오답: 확장성은 사용자가 새로운 기능을 추가할 수 있는지에 초점을 둔다.
8. 작성된 프로그램을 다른 실행 환경으로 이전할 수 있는지를 묻는 평가 기준은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ①
- ① 정답: 실행 환경이 바뀌어도 프로그램을 옮겨 사용할 수 있는 성질을 이식성이라고 한다.
- ② 오답: 일관성은 유사한 기능을 같은 형태로 나타내는지를 평가한다.
- ③ 오답: 작성력은 프로그래머가 수식·문장·기능을 쉽게 표현할 수 있는지에 관한 기준이다.
- ④ 오답: 신뢰성은 프로그램이 오류에 빠질 가능성을 줄이는지에 관한 기준이다.
9. 오류 비용이 매우 큰 프로그램에서 실행 전 검사를 강화했더니 표현 제약이 늘었다. 강의의 절충 관계로 가장 적절한 해석은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ③
- ① 오답: 상황의 핵심은 이해하기 쉬운 표현이 아니라 오류 검사와 표현 제약이다.
- ② 오답: 실행 환경 이전에 관한 조건이 없고 실행 가능성을 없앤다는 해석도 맞지 않는다.
- ③ 정답: 안전을 위한 제약은 신뢰성을 높일 수 있지만 허용되는 표현의 유연성을 줄일 수 있다.
- ④ 오답: 직교성은 기능 조합의 독립성, 일관성은 유사 기능의 표현 형태를 다룬다.
10. 새 프로젝트에 사용할 언어를 선택하는 절차로 가장 적절한 것은?
정답입니다.
오답입니다. 답안을 다시 선택해 보세요.
정답 및 해설 보기
정답: ②
- ① 오답: 등장 시점은 문제 적합성, 실행 경로, 유지보수 요구를 대신하지 못한다.
- ② 정답: 기술적 평가와 현실의 사용·학습 환경을 연결하고 상충 기준의 우선순위까지 밝히는 절차다.
- ③ 오답: 효율성과 신뢰성처럼 동시에 높이기 위해 비용이 드는 기준이 있어 목적별 가중치가 필요하다.
- ④ 오답: 구현 방식 하나만으로 작성력, 이식성, 커뮤니티와 응용 적합성을 판단할 수 없다.
참고 자료와 작성 기준
이 글은 해당 차시 강의자료를 바탕으로 학습 목적에 맞게 재구성한 비공식 학습자료입니다. 시대별 문제-응답 관계, 구현 경로 비교, 평가 기준의 절충 사례와 문제 해설은 학습자가 판단 과정을 재현하도록 독자적으로 구성하고 검토했습니다.
- 작성·편집: 올에이클래스 학습연구팀
- 주요 근거: 한국방송통신대학교 컴퓨터과학과 「프로그래밍언어론」 2강 ‘프로그래밍 언어의 발전 및 동작 원리’ 강의자료(2025년 제작본)
- 보충 자료: 별도의 외부 자료를 사용하지 않고 해당 차시 강의 범위 안에서 재구성
- 편집 원칙: 올에이클래스 편집 정책
- 최종 내용 검토: 2026-08-27
댓글
댓글 쓰기