오류 메시지에 syntax, 문서에는 expression, 코드 리뷰에는 statement가 나오면 모두 ‘코드 한 줄’처럼 보일 수 있다. 하지만 각 용어는 코드를 보는 단위가 다르다.
total = price * quantity이 한 줄을 여러 관점으로 나누면 문법 용어가 훨씬 선명해진다.
아래 그림처럼 하나의 코드에서도 식은 값을 만들고, 문은 그 식을 포함하는 더 큰 실행 단위가 된다.
syntax statement expression operator는 무엇을 가리킬까?
한 줄 전체는 실행할 문이고, 그 안의 계산식은 값을 만드는 식이며, 곱셈 기호는 연산자다. 아래 표도 이 포함 관계를 기준으로 읽으면 된다.
| 용어 | 뜻 | 예제에서 찾기 |
|---|---|---|
syntax | 코드를 올바르게 쓰는 형식과 규칙 | 이름·연산자·배치가 언어 문법에 맞는가 |
statement | 실행할 하나의 문 | 대입문 전체 |
expression | 평가되어 값을 만드는 식 | price * quantity |
operator | 값에 연산을 적용하는 기호·키워드 | *, = |
operand | 연산의 대상이 되는 값 | price, quantity |
식은 다른 문의 일부가 될 수 있다. price * quantity가 값을 만들고, 대입문은 그 값을 total에 연결한다. 언어에 따라 대입 자체도 값을 만드는 표현식일 수 있으므로 마지막 판단은 해당 언어 규칙을 따른다.
signature는 함수의 이름만 뜻할까?
함수나 메서드의 signature는 호출 대상을 구분하는 이름과 매개변수 정보의 조합을 뜻한다. 반환 타입을 포함하는지는 언어마다 다르다.
calculate(price, quantity)
calculate(price, quantity, discount)두 호출은 매개변수 개수가 다르다. 오버로딩을 지원하는 언어라면 시그니처 차이로 서로 다른 함수를 고를 수 있다. 문서에서 시그니처를 볼 때는 이름, 매개변수 순서·타입, 선택 인수, 반환 타입 표기 규칙을 확인한다.
parameter는 함수를 정의할 때 선언한 매개변수이고, argument는 호출할 때 전달하는 실제 인수다. 둘을 모두 ‘파라미터’라고 부르기도 하지만 오류를 설명할 때는 어느 쪽인지 구분하면 빠르다.
syntax가 맞는데도 프로그램이 틀릴 수 있는 이유
semantics는 문법적으로 올바른 코드가 어떤 의미와 동작을 갖는지 정하는 규칙이다. 다음 식은 문법에 맞아도 요구사항이 ‘세금 포함 가격’이라면 의미상 틀릴 수 있다.
total = price * quantity # tax를 반영하지 않음컴파일이 성공했다는 사실은 문법과 타입 규칙 일부를 통과했다는 뜻이지 업무 결과가 옳다는 보장은 아니다. 단위 테스트에서는 같은 입력에 기대한 결과가 나오는지 확인해야 한다.
parse compile runtime 오류는 어느 단계일까?
parse는 문자로 된 입력을 문법 구조나 값으로 해석하는 과정이다. compile은 소스 코드를 다른 실행 형태로 변환하고 오류를 검사하는 과정이며, runtime은 실제 프로그램이 실행되는 시점이다.
- 괄호가 닫히지 않음: syntax·parse 단계에서 발견될 수 있음
- 존재하지 않는 이름이나 맞지 않는 타입: 언어에 따라 compile 단계에서 발견될 수 있음
- 0으로 나누기, null 접근, 파일 부재: runtime에 실제 경로가 실행될 때 발생할 수 있음
- 결과 계산이 요구와 다름: 실행은 성공해도 semantics나 업무 로직 문제일 수 있음
핵심 요약
syntax는 코드 형식의 규칙, statement는 실행 단위인 문, expression은 값을 만드는 식, operator는 연산을 나타낸다. signature는 함수를 식별하고 호출하는 데 필요한 이름과 매개변수 정보다. 문법 오류, 실행 오류, 의미 오류를 구분하면 ‘코드가 안 된다’는 한 문장을 실제 점검 단계로 바꿀 수 있다.
