테마
08. 프로그래밍의 본질 - 절차적 글쓰기와 실행 모델
학습 목표
- 프로그래밍이 본질적으로 "절차적 글쓰기"임을 이해한다.
- 컴퓨터가 명령을 해석하는 방식(비모호성)의 중요성을 체감한다.
- 절차적 글쓰기의 3단계(조건 분석, 절차 설계, 기술)를 설명할 수 있다.
- 고급 언어와 저급 언어의 차이를 이해한다.
- 컴파일, 인터프리터, Managed Code 세 가지 실행 모델을 비교하고 설명할 수 있다.
- SDK와 함수의 개념을 파악한다.
전체 구조
1. 프로그래밍 = 절차적 글쓰기
프로그래밍은 특별한 것이 아니다
많은 사람이 "프로그래밍"이라는 단어를 들으면 어렵고 전문적인 작업을 떠올린다. 하지만 프로그래밍의 본질을 한마디로 정의하면 **"절차적 글쓰기"**에 불과하다.
우리가 일상에서 하는 글쓰기를 생각해 보자.
- 보고서를 쓸 때: 현황 분석 --> 문제 정의 --> 해결 방안 --> 기대 효과 순서로 기술한다.
- 요리 레시피를 쓸 때: 재료 준비 --> 손질 --> 조리 --> 플레이팅 순서로 기술한다.
- 조립 설명서를 쓸 때: 부품 확인 --> 1단계 조립 --> 2단계 조립 --> 완성 순서로 기술한다.
프로그래밍도 정확히 같다. 해야 할 일을 정한 순서(절차)대로 기술하여 실행에 옮기는 것이 프로그래밍이다. 차이가 있다면, 그 글을 읽고 실행하는 주체가 사람이 아닌 컴퓨터라는 점뿐이다.
문법보다 중요한 것
프로그래밍 언어의 문법(syntax)을 배우는 것은 출발점일 뿐이다. 진짜 중요한 것은 세 가지 능력이다.
| 순서 | 능력 | 설명 |
|---|---|---|
| 1 | 절차적 사고 | 해결해야 할 문제를 순서가 있는 단계로 분해하는 능력 |
| 2 | 논리적 흐름 설계 | 분해한 단계들을 빈틈 없이 연결하는 능력 |
| 3 | 비모호한 기술 | 설계한 흐름을 누가 읽어도(컴퓨터가 읽어도) 하나의 의미로만 해석되도록 적는 능력 |
한국어 문법을 안다고 해서 좋은 소설을 쓸 수 있는 것은 아니다. 문법은 최소한의 도구이고, 좋은 글을 쓰려면 구성력, 논리력, 표현력에 대한 별도의 훈련이 필요하다. 프로그래밍도 마찬가지다. Python이나 Java의 문법을 외워도 좋은 프로그램을 만들 수 없다. 절차적 사고를 훈련해야 비로소 의미 있는 코드를 작성할 수 있다.
위 다이어그램에서 주목할 점은 1단계인 절차적 사고가 가장 굵은 테두리로 표현되어 있다는 것이다. 문법 학습과 코딩은 절차적 사고라는 기반 위에서만 의미를 가진다. 그리고 코딩을 하면서 다시 절차적 사고가 강화되는 선순환이 발생한다.
2. 땅콩버터 빵 사례 - 절차 기술의 어려움
SBS 다큐멘터리의 실험
SBS 다큐멘터리에서 매우 인상적인 장면이 등장한다. 한 아버지가 두 아이(아들과 딸)에게 이렇게 말한다.
"땅콩버터 빵 만드는 방법을 종이에 적어와라."
아이들은 자신 있게 종이에 방법을 적어 왔다. 아이들이 적은 내용은 대략 이런 식이었다.
1. 빵에 땅콩버터를 바른다.
2. 다른 빵을 위에 얹는다.
3. 먹는다.아버지는 아이들이 적어온 종이를 받아들고, 적힌 대로만 정확히 실행하기 시작했다. 마치 컴퓨터처럼.
아버지의 실행 결과
**"빵에 땅콩버터를 바른다"**라는 첫 번째 지시를 받은 아버지는 이렇게 행동했다.
- 땅콩버터 병의 뚜껑을 열라는 지시가 없으므로 --> 뚜껑이 닫힌 채로 빵 위에 병을 문지른다.
- 칼을 꺼내라는 지시가 없으므로 --> 맨손으로 하려 한다.
- "바른다"가 무엇을 의미하는지 명시되어 있지 않으므로 --> 병째로 빵 위에 올려놓는다.
아이들의 절차에는 수많은 빈틈이 있었다.
- 땅콩버터 병의 뚜껑을 연다.
- 나이프를 꺼낸다.
- 나이프로 땅콩버터를 적당량 떠낸다.
- 떠낸 땅콩버터를 빵 한쪽 면에 골고루 펴 바른다.
이 모든 "당연한" 단계가 생략되어 있었던 것이다.
두 아이의 다른 반응
| 반응 | 아들 | 딸 |
|---|---|---|
| 첫 반응 | "아빠, 알면서 왜 그래!" 짜증을 냄 | 당황하지만 종이를 다시 가져감 |
| 이후 행동 | 포기하거나 계속 불평 | 빠진 단계를 하나씩 추가하며 수정 |
| 결과 | 완성하지 못함 | 여러 번의 수정 끝에 완성도 높은 절차 완성 |
이 실험에서 딸의 태도가 바로 프로그래머의 태도다. 컴퓨터는 "개떡같이 말해도 찰떡같이 알아듣는" 존재가 절대 아니다. 적힌 대로만, 오직 적힌 대로만 실행한다.
핵심 교훈
컴퓨터는 맥락을 이해하지 못한다. 모호함을 추론하지 못한다. 빠진 단계를 스스로 채워 넣지 못한다. 오직 명시된 절차를 문자 그대로 실행할 뿐이다.
따라서 프로그래밍에서 가장 중요한 능력은 **"상대방(컴퓨터)이 아무것도 모른다는 전제 하에, 빈틈 없이 절차를 기술하는 것"**이다.
좋은 절차 기술은 각 단계가 하나의 동작만 수행하며, 대상과 방법이 명확하게 특정되어 있다. 나쁜 절차 기술은 여러 동작이 하나의 문장에 뭉뚱그려져 있고, 전제 조건이 생략되어 있다.
3. 절차적 글쓰기의 3단계
프로그래밍, 즉 절차적 글쓰기는 세 단계로 이루어진다. 이 단계를 "땅콩버터 빵 만들기"에 대입하며 살펴보자.
1단계: 조건 분석
절차를 설계하기 전에 먼저 현재 상황과 제약 조건을 파악해야 한다. 무엇이 있고, 무엇이 없는지, 어떤 제한이 있는지를 명확히 하는 단계다.
땅콩버터 빵의 경우:
| 분석 항목 | 구체적 질문 |
|---|---|
| 재료 | 식빵이 몇 장 있는가? 땅콩버터는 충분한가? |
| 도구 | 나이프가 있는가? 나이프의 크기와 종류는? 접시가 있는가? |
| 상태 | 땅콩버터 병의 뚜껑은 열려 있는가, 닫혀 있는가? |
| 제약 조건 | 알레르기가 있는 사람은 없는가? 시간 제한은? |
이 단계를 건너뛰면 중간에 "어, 나이프가 없네?"와 같은 문제에 부딪히게 된다. 프로그래밍에서도 마찬가지로, 코딩을 시작하기 전에 입력 데이터의 형식, 시스템 환경, 사용자 시나리오 등을 먼저 분석해야 한다.
2단계: 절차 설계 (머릿속 시뮬레이션)
분석한 조건을 바탕으로 단계별 순서를 설계하는 단계다. 이때 핵심은 머릿속에서 시뮬레이션을 돌려보는 것이다.
"1번 단계를 실행하면 어떤 상태가 되는가? 그 상태에서 2번 단계를 실행하면? 혹시 예외 상황이 발생하지는 않는가?"
예외 상황까지 고려해야 한다.
- 만약 땅콩버터가 거의 바닥이라면? --> 병을 기울여서 긁어내는 단계를 추가해야 한다.
- 만약 나이프가 너무 작다면? --> 여러 번 나눠서 바르는 단계로 설계해야 한다.
- 만약 식빵이 냉동 상태라면? --> 해동하는 단계가 선행되어야 한다.
이런 "만약"을 고려하는 것이 프로그래밍에서 **조건문(if-else)**의 원형이다.
3단계: 기술 (문서화)
설계한 절차를 비모호하게 글로 작성하는 단계다. 그리고 작성 후에는 반드시 실행하여 검증해야 한다.
여기서 중요한 팁이 하나 있다. 노트에 글로 직접 써보는 것이 머릿속 시뮬레이션보다 훨씬 효과적이다. 그 이유는:
- 머릿속에서는 무의식적으로 빠진 단계를 보충해 버린다. (사람의 뇌는 모호함을 자동으로 채운다.)
- 글로 적으면 빠진 단계가 물리적으로 비어 있으므로 발견하기 쉽다.
- 다른 사람에게 보여주고 검증받을 수 있다.
프로그래머들이 코딩 전에 의사코드(pseudo-code)를 작성하거나, 설계 문서를 먼저 쓰는 이유가 바로 이것이다.
검증 단계에서 문제가 발견되면 다시 이전 단계로 돌아간다. 이 반복 과정이 프로그래밍에서의 **디버깅(debugging)**에 해당한다.
4. 프로그래밍 언어란?
인간과 컴퓨터 사이의 약속
프로그래밍 언어란 인간이 컴퓨터에게 명령을 전달하기 위해 만든 인공 언어다.
자연 언어(한국어, 영어 등)는 모호함이 허용된다. "적당히 해", "대충 넣어"와 같은 표현이 통한다. 하지만 프로그래밍 언어는 모호함이 허용되지 않는다. 모든 명령은 하나의 의미로만 해석되어야 한다.
대표적인 프로그래밍 언어
| 언어 | 주요 용도 | 특징 |
|---|---|---|
| Python | 데이터 분석, AI, 웹 백엔드, 자동화 | 배우기 쉬운 문법, 방대한 라이브러리 |
| C | 운영체제, 임베디드 시스템, 하드웨어 제어 | 하드웨어에 가까운 저수준 제어 가능 |
| C++ | 게임 엔진, 시스템 소프트웨어, 고성능 응용 | C의 확장, 객체 지향 프로그래밍 지원 |
| Java | 기업용 시스템, 안드로이드 앱 | 플랫폼 독립적, 가상 머신(JVM) 기반 |
| JavaScript | 웹 프론트엔드, 웹 백엔드(Node.js) | 브라우저에서 동작하는 유일한 언어(역사적) |
| Go | 서버, 클라우드 인프라, CLI 도구 | 간결한 문법, 뛰어난 동시성 지원 |
문법은 도구, 절차적 사고는 능력
각 언어마다 문법(syntax)이 다르다. Python은 들여쓰기로 블록을 구분하고, C는 중괄호로 블록을 구분하며, Go는 세미콜론 없이 줄바꿈으로 문장을 구분한다.
하지만 절차적 사고의 핵심은 언어에 관계없이 동일하다. 어떤 언어를 쓰든 "문제를 분석하고, 단계를 나누고, 빈틈 없이 기술하는" 과정은 변하지 않는다.
비유하자면, 문법은 연필, 볼펜, 만년필 같은 필기도구이고, 절차적 사고는 글쓰기 능력 자체다. 좋은 글쓰기 능력이 있으면 어떤 필기도구로든 좋은 글을 쓸 수 있다.
5. 고급 언어 vs 저급 언어
분류 기준: 인간에게 가까운가, 기계에게 가까운가
프로그래밍 언어는 추상화 수준에 따라 **고급 언어(High-Level Language)**와 **저급 언어(Low-Level Language)**로 나뉜다. 여기서 "고급"과 "저급"은 성능의 우열이 아니라 추상화 수준을 의미한다.
| 구분 | 고급 언어 | 저급 언어 |
|---|---|---|
| 의미 | 인간이 이해하기 쉽게 추상화된 언어 | 기계(CPU)에 가까운 언어 |
| 예시 | Python, Java, C, C++, JavaScript, Go | 어셈블리어, 기계어 |
| 가독성 | 높음 (자연 언어에 가까운 키워드 사용) | 낮음 (숫자 코드나 약어 사용) |
| 이식성 | 높음 (여러 플랫폼에서 사용 가능) | 낮음 (특정 CPU 아키텍처에 종속) |
| 하드웨어 제어 | 간접적 | 직접적 |
기계어 (Machine Language)
기계어는 CPU가 직접 이해하고 실행할 수 있는 유일한 언어다. 0과 1로만 구성되어 있다.
10110000 01100001위 코드는 x86 CPU에서 "AL 레지스터에 값 97을 넣어라"라는 명령이다. 인간이 이것을 읽고 이해하기는 극히 어렵다.
어셈블리어 (Assembly Language)
어셈블리어는 기계어를 인간이 약간이나마 읽을 수 있도록 변환한 것이다. 0과 1 대신 기호(mnemonic)를 사용한다.
MOV AL, 61h같은 명령이지만 "MOV(이동해라), AL(이 레지스터에), 61h(이 값을)"이라는 의미를 추측할 수 있다. 어셈블리어를 기계어로 변환하는 프로그램을 **어셈블러(Assembler)**라고 한다.
핵심 원리
어떤 고급 언어로 코드를 작성하든, 궁극적으로는 기계어로 변환(번역)되어야만 CPU가 실행할 수 있다. 이 번역 방식의 차이가 바로 다음에 다룰 "컴파일"과 "인터프리터"의 차이다.
6. 컴파일 (Compile) 방식
개념
컴파일 방식은 소스 코드 전체를 한꺼번에 기계어로 번역하는 방식이다. 이 번역을 수행하는 프로그램을 **컴파일러(Compiler)**라고 한다.
실생활 비유
출판 번역과 같다. 영어 원서를 한국어로 번역할 때, 번역가가 책 전체를 한국어로 옮긴 뒤 한국어판을 출판한다. 이후 독자는 번역본만 읽으면 되므로, 읽을 때마다 번역 작업을 반복할 필요가 없다.
동작 흐름
특징
| 항목 | 설명 |
|---|---|
| 번역 시점 | 실행 전에 한 번 |
| 번역 결과 | 독립적인 실행 파일 생성 |
| 실행 속도 | 빠름 (이미 기계어이므로 CPU가 바로 실행) |
| 플랫폼 종속성 | 있음 (Windows용으로 컴파일하면 macOS에서 실행 불가) |
| 오류 발견 시점 | 컴파일 시점에 문법 오류 등을 미리 발견 |
| 대표 언어 | C, C++, Go, Rust |
장점과 단점
장점: 번역은 한 번만 하면 되고, 이후에는 실행 파일만 배포하면 된다. 실행 속도가 매우 빠르다. 소스 코드를 공개하지 않아도 실행 파일만 배포할 수 있다.
단점: 코드를 수정할 때마다 전체를 다시 컴파일해야 한다. 플랫폼(Windows, macOS, Linux)마다 각각 컴파일해야 한다.
7. 인터프리터 (Interpreter) 방식
개념
인터프리터 방식은 소스 코드를 한 줄씩 읽어서 즉시 실행하는 방식이다. 이 작업을 수행하는 프로그램을 **인터프리터(Interpreter)**라고 한다.
실생활 비유
동시통역과 같다. 국제 회의에서 통역사가 발표자의 말을 한 마디씩 듣고 즉시 통역한다. 책을 통째로 번역하는 것보다 전체 속도는 느리지만, 발표가 시작되는 즉시 소통이 가능하다. 그리고 발표 내용이 바뀌어도 즉시 대응할 수 있다.
동작 방식
- 소스 코드의 1번째 줄을 읽는다 --> 기계어로 번역한다 --> 실행한다.
- 소스 코드의 2번째 줄을 읽는다 --> 기계어로 번역한다 --> 실행한다.
- ... 이 과정을 마지막 줄까지 반복한다.
실행 파일을 별도로 생성하지 않는다. 실행할 때마다 매번 번역 과정을 거친다.
특징
| 항목 | 설명 |
|---|---|
| 번역 시점 | 실행할 때마다 매번 |
| 번역 결과 | 실행 파일을 생성하지 않음 |
| 실행 속도 | 느림 (매번 번역 비용이 발생) |
| 플랫폼 종속성 | 낮음 (인터프리터만 설치되어 있으면 어디서든 실행) |
| 오류 발견 시점 | 실행 중에 해당 줄에 도달했을 때 발견 |
| 대표 언어 | Python, JavaScript, Ruby |
장점과 단점
장점: 코드를 수정하면 즉시 실행하여 결과를 확인할 수 있다 (빠른 개발 사이클). 인터프리터만 있으면 운영 체제에 관계없이 실행할 수 있다. 대화형(REPL) 환경에서 한 줄씩 실행하며 실험할 수 있다.
단점: 실행할 때마다 번역하므로 컴파일 방식보다 느리다. 오류가 있어도 해당 줄이 실행될 때까지 발견되지 않을 수 있다.
8. Managed Code (관리형 코드)
컴파일과 인터프리터의 중간 지대
컴파일 방식과 인터프리터 방식은 각각 장단점이 있다. 이 두 방식의 장점을 결합하려는 시도가 Managed Code (관리형 코드) 방식이다.
동작 원리
- 소스 코드를 **중간 코드(바이트코드, Bytecode)**로 컴파일한다.
- 이 중간 코드는 기계어가 아니라, **가상 머신(Virtual Machine)**이 이해하는 코드다.
- 가상 머신이 중간 코드를 읽어서 실행한다.
비유하자면, 영어 원서를 "에스페란토어(인공 국제어)"로 먼저 번역하고, 각 나라의 에스페란토어 통역사가 자국어로 변환하는 것과 같다. 에스페란토어로 한 번만 번역하면 어느 나라에서든 실행(통역)할 수 있다.
대표 사례
| 언어 | 중간 코드 | 가상 머신 |
|---|---|---|
| Java | Java Bytecode (.class) | JVM (Java Virtual Machine) |
| C# | CIL (Common Intermediate Language) | .NET CLR (Common Language Runtime) |
| Kotlin | Java Bytecode | JVM |
가상 머신이 해주는 것들
Managed Code라고 불리는 이유는 가상 머신이 많은 것을 "관리(manage)"해주기 때문이다.
- 메모리 관리: 사용이 끝난 메모리를 자동으로 회수한다 (가비지 컬렉션, Garbage Collection).
- 보안 관리: 코드가 허용된 범위를 벗어나는 동작을 하지 못하도록 감시한다.
- 플랫폼 독립성: 가상 머신만 설치하면 Windows, macOS, Linux 어디서든 동일한 바이트코드를 실행할 수 있다.
성능 비교
Managed Code는 컴파일 방식보다는 느리지만, 순수 인터프리터 방식보다는 빠르다. 최신 JVM은 JIT(Just-In-Time) 컴파일 기술을 사용하여 자주 실행되는 바이트코드를 기계어로 변환해 두므로, 성능 격차가 많이 줄어들었다.
| 항목 | 컴파일 | 인터프리터 | Managed Code |
|---|---|---|---|
| 번역 단위 | 전체 | 한 줄씩 | 전체 --> 중간 코드 |
| 실행 파일 | 생성됨 | 생성 안 됨 | 중간 코드 생성 |
| 실행 속도 | 가장 빠름 | 가장 느림 | 중간 (JIT로 개선) |
| 플랫폼 독립성 | 낮음 | 높음 | 높음 (VM만 있으면 됨) |
| 메모리 관리 | 수동 (개발자 책임) | 언어에 따라 다름 | 자동 (VM이 관리) |
| 대표 언어 | C, C++, Go, Rust | Python, JS, Ruby | Java, C#, Kotlin |
9. SDK (Software Development Kit) 개념
SDK란?
SDK는 Software Development Kit의 약자로, 직역하면 "소프트웨어 개발 도구 모음"이다. 특정 플랫폼이나 서비스를 대상으로 소프트웨어를 개발할 때 필요한 도구, 라이브러리, 문서 등을 하나로 묶어 제공하는 것이다.
실생활 비유
화가의 그림 도구 세트를 생각해 보자. "유화 세트"에는 유화 물감, 유화 붓, 팔레트, 린시드 오일, 캔버스 등이 들어 있다. "수채화 세트"에는 수채화 물감, 수채화 붓, 물통, 수채화 용지가 들어 있다. 각 세트는 **특정 목적(유화 그리기, 수채화 그리기)**에 맞춰 필요한 도구를 모아 놓은 것이다.
SDK도 마찬가지다. "무엇을 개발하려는가"라는 목적에 따라 필요한 도구가 달라진다.
SDK에 포함되는 요소
| 구성 요소 | 설명 | 비유 |
|---|---|---|
| 컴파일러/빌드 도구 | 코드를 실행 가능한 형태로 변환 | 가마 (도자기를 구워 완성) |
| 라이브러리 | 미리 만들어진 기능 모음 (함수들) | 기성품 재료 (이미 만들어진 유약) |
| API | 플랫폼이 제공하는 기능을 호출하는 인터페이스 | 작업 주문서 양식 (정해진 형식으로 요청) |
| 문서 | 사용법 설명서 | 사용 설명서 |
| 샘플 코드 | 예제 프로젝트 | 완성 작품 사진 |
| 디버거/에뮬레이터 | 테스트 및 오류 탐지 도구 | 시제품 검수 도구 |
대표적인 SDK 예시
| SDK 이름 | 목적 | 대상 플랫폼 |
|---|---|---|
| Android SDK | 안드로이드 앱 개발 | Android OS |
| iOS SDK (Xcode) | 아이폰/아이패드 앱 개발 | iOS / iPadOS |
| AWS SDK | AWS 클라우드 서비스 연동 개발 | AWS 플랫폼 |
| Windows SDK | 윈도우 데스크톱 앱 개발 | Windows OS |
| Flutter SDK | 크로스 플랫폼 모바일 앱 개발 | Android + iOS |
SDK를 이해하는 핵심: 목적 파악
SDK를 접할 때 가장 먼저 파악해야 할 것은 **"이 SDK는 무엇을 개발하기 위한 것인가?"**이다.
- 목적: 무엇을 만들기 위한 SDK인가?
- 플랫폼: 어떤 환경에서 실행되는 소프트웨어를 만드는가?
- 제공 API: 어떤 기능을 제공하는가?
이 세 가지를 파악하면 처음 보는 SDK라도 빠르게 이해할 수 있다.
10. 함수 (Function)
함수란?
함수는 특정 작업을 수행하는 코드 덩어리에 이름을 붙인 것이다. 한 번 만들어 두면 필요할 때마다 이름을 불러서 재사용할 수 있다.
수학의 함수와 비교
수학에서 f(x) = 2x + 1이라는 함수를 생각해 보자.
- f(3) = 7 --> 입력이 3이면 출력이 7
- f(5) = 11 --> 입력이 5이면 출력이 11
프로그래밍의 함수도 동일한 구조다.
- 입력(매개변수, Parameter): 함수에 전달하는 값
- 처리 로직: 입력을 가지고 수행하는 작업
- 출력(반환값, Return Value): 처리 결과로 돌려주는 값
함수를 만드는 이유
요리사가 매일 같은 소스를 만든다고 하자. 매번 처음부터 재료를 계량하고, 섞고, 끓이는 과정을 반복하는 것은 비효율적이다. 그래서 "기본 토마토 소스 레시피"를 한 번 작성해 놓고, 필요할 때마다 그 레시피를 참조한다.
프로그래밍에서도 마찬가지다. 같은 작업을 여러 번 수행해야 한다면, 해당 작업을 함수로 만들어 놓고 필요할 때마다 호출하면 된다.
| 이유 | 설명 |
|---|---|
| 재사용성 | 한 번 작성하고 여러 곳에서 호출 |
| 가독성 | 복잡한 로직에 의미 있는 이름을 붙여 코드를 읽기 쉽게 만듦 |
| 유지보수성 | 수정이 필요하면 함수 내부만 고치면 모든 호출 지점에 반영 |
| 추상화 | 내부 동작을 몰라도 입력과 출력만 알면 사용 가능 |
함수의 구성 요소
함수 이름(매개변수1, 매개변수2) {
처리 로직
return 반환값
}- 이름: 함수가 하는 일을 나타내는 명칭 (예: calculateTotal, sendEmail)
- 매개변수(Parameter): 함수에 전달되는 입력값
- 처리 로직: 매개변수를 사용하여 수행하는 작업
- 반환값(Return Value): 처리 결과를 호출한 쪽에 돌려주는 값
라이브러리와 API
다른 사람(또는 조직)이 미리 만들어 놓은 함수들의 모음을 **라이브러리(Library)**라고 한다. 그리고 이 함수들을 외부에서 호출할 수 있도록 정의한 규약을 **API(Application Programming Interface)**라고 한다.
프로그래밍에서는 모든 것을 처음부터 직접 만들 필요가 없다. 잘 만들어진 라이브러리의 함수를 호출하여 활용하는 것도 중요한 능력이다. 이것이 앞에서 다룬 SDK에 라이브러리와 API가 포함되는 이유이기도 하다.
핵심 암기 포인트
| 번호 | 핵심 내용 |
|---|---|
| 1 | 프로그래밍 = 절차적 글쓰기. 문법보다 절차적 사고가 먼저다. |
| 2 | 컴퓨터는 적힌 대로만 실행한다. 모호하면 의도대로 동작하지 않는다. |
| 3 | 절차적 글쓰기 3단계: 조건 분석 --> 절차 설계 --> 기술(문서화) --> 실행/검증 |
| 4 | 컴파일: 전체 번역 --> 실행 파일 생성 --> 빠른 실행 (C, C++, Go, Rust) |
| 5 | 인터프리터: 한 줄씩 번역+실행 --> 느리지만 즉시 실행, 플랫폼 독립적 (Python, JS) |
| 6 | Managed Code: 중간 코드(바이트코드) --> VM이 실행 --> 플랫폼 독립적 + 자동 메모리 관리 (Java, C#) |
| 7 | SDK: 특정 목적의 개발 도구 모음. 목적, 플랫폼, 제공 API를 파악하는 것이 핵심. |
| 8 | 함수: 재사용 가능한 코드 덩어리. 입력 --> 처리 --> 출력 구조. |
확인 질문
Q1. 프로그래밍에서 문법보다 중요한 것은 무엇인가?
절차적 사고 능력이다. 문법은 명령을 기술하기 위한 도구에 불과하며, 문제를 단계별로 분해하고 빈틈 없이 논리적 흐름을 설계하는 절차적 사고가 프로그래밍의 본질이다. 한국어 문법을 안다고 좋은 글을 쓸 수 없듯, 프로그래밍 언어 문법을 안다고 좋은 프로그램을 만들 수 없다.
Q2. 컴파일 방식과 인터프리터 방식의 차이는 무엇인가?
컴파일 방식은 소스 코드 전체를 한꺼번에 기계어로 번역하여 실행 파일을 생성하며, 이후 실행 시에는 번역 없이 바로 실행하므로 속도가 빠르다 (예: C, Go). 인터프리터 방식은 소스 코드를 한 줄씩 읽어서 번역과 실행을 동시에 수행하며, 실행 파일을 생성하지 않으므로 실행 시마다 번역 비용이 발생하여 느리지만, 즉시 실행이 가능하고 플랫폼 독립적이다 (예: Python, JavaScript).
Q3. Managed Code의 특징과 대표 언어는?
Managed Code는 소스 코드를 중간 코드(바이트코드)로 컴파일한 뒤, 가상 머신(VM)이 이를 실행하는 방식이다. VM이 메모리 관리(가비지 컬렉션), 보안, 플랫폼 독립성을 자동으로 처리해 준다. 대표 언어는 Java(JVM), C#(.NET CLR), Kotlin 등이 있다.
Q4. 절차적 글쓰기의 3단계는 무엇인가?
1단계는 조건 분석(재료, 도구, 상태, 제약 조건 파악), 2단계는 절차 설계(단계별 순서 결정 + 예외 상황 고려 + 머릿속 시뮬레이션), 3단계는 기술/문서화(비모호하게 글로 작성 + 실행하여 검증)이다. 검증에서 문제가 발견되면 이전 단계로 돌아가 수정한다.
Q5. SDK란 무엇이며, 이해할 때 파악해야 할 3가지는?
SDK(Software Development Kit)는 특정 플랫폼이나 서비스를 대상으로 소프트웨어를 개발할 때 필요한 도구, 라이브러리, 문서 등을 묶어 제공하는 개발 도구 모음이다. SDK를 이해할 때 파악해야 할 3가지는: (1) 목적 - 무엇을 만들기 위한 SDK인가, (2) 플랫폼 - 어떤 환경에서 실행되는 소프트웨어를 만드는가, (3) 제공 API - 어떤 기능을 제공하는가이다.