파라미터와 매개변수, 인자

  • 파라미터
  • 매개변수
  • 인자
  • 인수
  • 아규먼트
2026-09-06

한 줄 결론

파라미터와 매개변수는 parameter라는 하나의 개념을 음차한 이름과 번역한 이름이다. 정작 구분해서 써야 하는 짝은 매개변수(parameter)와 인자(argument)이고, 앞은 함수를 정의할 때 적는 이름, 뒤는 함수를 호출할 때 넘기는 값이다.

질문 바로잡기

파라미터와 매개변수가 무엇이 다르냐는 질문에는 답이 없다. 둘은 영어 parameter 하나를 옮긴 두 방식이기 때문이다. 소리대로 옮기면 파라미터가 되고 뜻으로 옮기면 매개변수가 된다. "매개"는 값을 함수 안으로 이어 준다는 뜻이라 매개변수는 대상의 역할을 그대로 담은 번역이다.

argument도 같은 방식으로 이름이 여럿 생겼다. 소리대로 옮긴 말이 아규먼트이고, 뜻으로 옮긴 말이 인자와 인수다. 인자와 인수는 수학 용어 번역에서 넘어온 말이라 둘 중 무엇이 표준인지 아직 굳지 않았다. 한국어 MDN 용어사전 페이지 하나만 봐도 본문에서 인자를 쓰다가 "매개변수는 넘겨받은 인수값으로 초기화됩니다"라며 같은 문단에서 인수로 넘어간다.

parameter argument 음차 파라미터 아규먼트 번역 매개변수 인자 / 인수
파라미터와 매개변수는 같은 parameter 열에, 아규먼트와 인자, 인수는 같은 argument 열에 위아래로 놓인다. 실제로 갈리는 짝은 parameter 열과 argument 열이다.

그런데도 파라미터가 매개변수보다 넓은 말처럼 느껴지는 데는 이유가 있다. 실무에서 파라미터를 느슨하게 쓰기 때문이다. 함수 정의부의 이름도, 호출부에서 넘기는 값도, 쿼리 스트링의 ?page=2도 모두 파라미터라고 부른다. 파라미터라는 단어가 argument 자리까지 넘어가 쓰이다 보니 넓어 보일 뿐, 단어가 가리키는 개념은 매개변수와 같다.

정리하면 이름은 다섯 개지만 가리키는 개념은 parameter와 argument 둘뿐이다. 같은 열 안에서 어느 이름을 골라도 정확도는 달라지지 않고, parameter 자리에 argument 계열 단어를 쓰거나 그 반대로 쓸 때만 뜻이 어긋난다. 그래서 실제로 갈라 써야 하는 것은 매개변수와 인자다.

무엇으로 갈리는가: 정의 시점과 호출 시점

매개변수와 인자는 코드의 어느 시점에 존재하는지로 갈린다. 매개변수는 함수를 정의하는 순간 이미 존재하고 그 뒤로 바뀌지 않는다. 인자는 함수를 부를 때마다 새로 생기고 호출이 끝나면 사라진다.

매개변수(parameter)는 함수 정의에 이름으로 등장하는 변수다. MDN 용어집은 매개변수를 함수 정의에 나열된 이름이라 정의하고, 함수에 전달된 인자를 가리키는 데 쓴다고 덧붙인다. 판별은 눈으로 한다. function greet(name)에서 괄호 안에 적힌 것이 매개변수이고, 함수 시그니처만 보고 셀 수 있으면 매개변수다. 정의 시점에 놓이는 까닭은 이 이름이 값 없이도 존재하기 때문이다. 아직 아무도 이 함수를 부르지 않았어도 name이라는 이름은 코드에 적혀 있다.

인자(argument)는 함수를 호출할 때 실제로 넘기는 값이다. MDN 용어집은 인자를 함수에 입력으로 전달되는 값이라 정의하고, 매개변수와 혼동하지 말라는 문장을 바로 뒤에 붙여 둔다. 판별 기준은 호출식이다. greet('Kim')에서 괄호 안에 적힌 'Kim'처럼 함수를 부르는 쪽 코드에서만 보이면 인자다. 호출 시점에 놓이는 까닭은 호출이 있어야만 존재하기 때문이다. 같은 함수를 세 번 부르면 매개변수는 여전히 하나지만 인자는 세 벌 생긴다.

정의 시점 매개변수 / 파라미터 greet(name) 호출 시점 인자 / 인수 / 아규먼트 greet('Kim') 실행 시점 함수 안의 지역 변수 name === 'Kim' 자리를 만듦 값을 채움
매개변수는 함수를 정의하는 순간 자리로 존재하고, 인자는 호출할 때마다 그 자리에 들어갈 값으로 새로 생긴다. 두 개념을 가르는 기준은 시점이다.

왜 이렇게 나뉘는가

함수는 아직 정해지지 않은 값을 두고 미리 로직을 써 두는 장치다. 값이 없는 상태에서 그 값을 가리켜야 하니 값을 대신할 이름이 필요하고, 그 이름이 매개변수다. 매개변수는 값이 아니라 값이 들어올 자리다. 인자는 그 자리에 실제로 들어가는 값이고 호출할 때마다 달라진다. 자리 하나에 호출 횟수만큼의 값이 대응되므로, 둘을 같은 이름으로 부르면 몇 번째 호출의 값인지 말할 방법이 사라진다.

정의부 function fetchList(page) 매개변수 page 하나 호출부 fetchList(1) fetchList(2) fetchList(3) 1을 채움 2를 채움 3을 채움
같은 함수를 세 번 부르면 인자는 세 번 새로 생기지만 받는 자리는 정의부의 page 하나다. 자리와 값의 개수가 처음부터 다르다.

이 비대칭은 문법에도 그대로 드러난다. MDN 함수 레퍼런스는 매개변수 쪽에 기본값 매개변수, 나머지 매개변수, 구조 분해라는 특수 문법 세 가지를 따로 정리해 둔다. 셋 다 들어오는 값을 어떤 모양으로 받을지 정하는 장치다. 인자 쪽에는 값을 나열하는 것 외에 전개 문법(...) 하나만 있고, 이마저 배열을 펼쳐 값 여러 개로 바꿔 넣는 일만 한다. 매개변수는 값을 받는 방식을 규정하는 쪽이라 문법이 늘어났고, 인자는 그 규정에 실려 들어오는 값이라 문법이 늘어날 이유가 없었다. 규정하는 쪽과 규정되는 쪽이라는 역할 차이가 문법 개수의 차이로 나타난 셈이다.

기본값이라는 기능도 같은 구조에서 나온다. 기본값은 인자가 오지 않았을 때 자리를 어떻게 채울지 정의부가 미리 정해 두는 장치라서 매개변수 쪽에만 있다. 호출부가 값을 넘기지 않아도 함수가 동작하는 까닭은 자리와 값이 분리돼 있고 자리 쪽이 자신의 기본 상태를 알고 있기 때문이다.

경계 사례

function fetchList(page = 1) {}
 
fetchList()

인자 없이 호출했을 때 값 1은 매개변수일까 인자일까. 판별 기준을 그대로 적용하면 된다. 1은 정의부에 적혀 있으므로 매개변수 page의 기본값이고, 호출부는 아무것도 넘기지 않았으므로 이 호출의 인자는 0개다. MDN도 기본값 매개변수를 값이 전달되지 않거나 undefined가 전달됐을 때 매개변수를 초기화하는 문법이라 설명한다. 함수 안에서 page의 값이 1이라 인자처럼 느껴지지만, 그 값이 어느 코드에 적혀 있는지를 보면 갈린다.

fetchList(count + 1)

값 대신 식을 넘기면 인자는 count + 1이라는 식이 평가된 결과값이다. ECMAScript 명세의 인자 목록 평가 절차(ArgumentListEvaluation)는 인자 자리에 적힌 식을 하나씩 평가하고 GetValue로 값을 꺼내 목록에 담는다. 함수가 받는 것은 이렇게 만들어진 값 목록이다. 인자를 값으로 정의한 이상, 아직 값이 아닌 식은 인자가 되기 전 단계다.

function log(...rest) {}
 
log('a', 'b', 'c')

이렇게 호출하면 매개변수는 ...rest 하나이고 인자는 세 개다. MDN도 ...rest를 rest parameter라 부르고 그것이 모으는 값들을 arguments라 부른다. 개수가 1대 3으로 어긋나는 것이 이상해 보이지만, 매개변수는 자리이고 인자는 값이라는 구분을 적용하면 자연스럽다. 자리 하나가 값 여러 개를 받도록 정의됐을 뿐이다.

const items = ['a', 'b', 'c']
 
log(...items)

호출부에 적힌 ...은 전개 문법이다. 생김새는 나머지 매개변수와 같아도 정의부에 있으면 값을 모으는 매개변수이고, 호출부에 있으면 배열을 펼쳐 인자 여러 개로 넘기는 문법이다. MDN도 두 문법을 생김새는 같지만 하는 일은 서로 반대라고 설명한다.

호출부 log(...items) 배열 하나를 넘김 인자 3개 'a' 'b' 'c' 정의부 function log(...rest) 매개변수 하나로 모음 전개 문법: 펼침 나머지 매개변수: 모음
같은 ... 기호가 호출부에서는 배열을 인자 여러 개로 펼치고, 정의부에서는 그 인자들을 매개변수 하나로 다시 모은다. 이름을 정하는 것은 기호가 적힌 자리다.

실제로 쓰는 문장

정의부를 바꾸자고 할 때

시그니처를 바꾸자는 리뷰 코멘트에는 매개변수를 쓴다. "이 함수 매개변수 순서를 바꾸면 호출부를 전부 고쳐야 함"이 정확한 문장이다. 바꾸려는 대상이 정의부에 적힌 이름이므로 정의 시점의 단어를 써야 한다.

호출부에서 문제가 났을 때

버그가 호출부에 있을 때는 인자를 쓴다. "세 번째 인자가 undefined로 들어오고 있음"처럼 말하면 문제 지점이 호출식이라는 사실까지 함께 전달된다. 같은 상황에서 "세 번째 파라미터를 잘못 넘기고 있음"이라고 하면 정의부를 고치자는 말처럼 읽혀서 듣는 쪽이 엉뚱한 파일을 연다.

정의와 호출이 어긋났을 때

두 시점을 한 문장에 담을 때 구분이 가장 잘 드러난다. "매개변수는 optional로 선언돼 있는데 모든 호출부가 인자를 넘기고 있어서 사실상 필수임" 같은 문장은 정의와 호출이 어긋난 상황을 한 번에 설명한다.

API 문서를 쓸 때

API 문서나 함수 설명에서 "이 엔드포인트의 파라미터"라고 쓰는 것은 정확하다. 문서가 기술하는 대상이 받는 쪽의 규격이므로 정의 시점의 단어가 맞다. 반대로 요청을 보내는 코드를 설명하면서 "파라미터를 넘김"이라고 쓰면 어긋난다. "인자로 넘김"이 맞다.

팀 용어를 정할 때

팀에서 파라미터로 통일했다면 그대로 쓰면 된다. 음차어를 골랐다고 정확도가 떨어지지는 않으니, 그 단어를 정의부에 대해 쓰고 있는지만 점검하면 된다.

근거