루프에서 클로저 문제가 생기는 이유는?

루프 내 클로저 생성 시 변수 캡처 시점의 차이로 인해 발생하는 문제를 이해하고 올바른 해결 방법을 학습합니다

중급 15분 루프 클로저 변수 캡처 클로저 문제 비동기

JavaScript에서 반복문 안에서 클로저를 생성할 때 발생하는 가장 흔한 함정 중 하나가 바로 루프 클로저 문제입니다. 이 문제는 반복문이 실행되는 시점과 클로저 함수가 실제로 호출되는 시점 사이의 시간 차이로 인해 발생합니다. 많은 개발자들이 반복문 내에서 생성한 여러 함수가 각각 다른 값을 기억할 것이라고 기대하지만, 실제로는 모든 함수가 동일한 마지막 값을 참조하는 현상을 경험하게 됩니다. 이러한 문제는 특히 이벤트 리스너나 타이머 함수를 반복문 안에서 등록할 때 빈번하게 발생하며, 예상치 못한 동작으로 인해 디버깅하기 어려운 버그를 만들어냅니다.

🔍 핵심 문제점

  • 변수 캡처 시점의 오해: 클로저가 생성될 때가 아니라 실행될 때 변수 값을 참조한다는 점을 간과
  • var의 함수 스코프 특성: var로 선언한 반복 변수는 반복문이 끝난 후에도 하나의 값만 유지
  • 비동기 실행의 딜레이: setTimeout이나 이벤트 리스너처럼 나중에 실행되는 함수는 반복문이 이미 끝난 시점의 변수를 참조
  • 모든 클로저가 같은 변수 공유: 반복문 내에서 생성된 여러 클로저가 동일한 외부 변수를 참조하여 독립적이지 않음
  • 예상과 다른 실행 결과: 0, 1, 2를 출력할 것으로 기대했지만 3, 3, 3이 출력되는 등의 혼란스러운 동작

💡 실무에서의 영향

루프 클로저 문제는 실무에서 매우 자주 마주치는 상황입니다. 예를 들어, 여러 개의 버튼에 클릭 이벤트를 등록할 때 각 버튼이 자신의 인덱스를 기억하도록 하려다가 모든 버튼이 마지막 인덱스만 참조하는 버그를 만나게 됩니다. 또한 Ajax 요청을 반복문으로 여러 번 보낼 때 응답 핸들러가 잘못된 데이터를 참조하거나, 애니메이션을 순차적으로 실행하려는데 모두 동일한 타이밍에 실행되는 문제도 발생합니다. 이 문제를 이해하지 못하면 코드가 의도대로 동작하지 않을 때 원인을 찾기 어려워 많은 시간을 낭비하게 됩니다. 다행히 ES6의 let과 const, 그리고 IIFE(즉시 실행 함수)와 같은 해결 방법을 알고 있다면 이러한 문제를 쉽게 예방하고 해결할 수 있습니다. 클로저와 스코프의 동작 원리를 정확히 이해하면 더 안정적이고 예측 가능한 코드를 작성할 수 있으며, 레거시 코드에서 이러한 패턴을 발견했을 때도 빠르게 문제를 파악하고 수정할 수 있습니다.

핵심 개념

변수 캡처 시점과 실행 시점의 차이

입문

클로저가 변수를 ‘기억’하는 시점과 실제로 ‘사용’하는 시점이 다를 때 문제가 발생해요. 이게 루프 클로저 문제의 핵심이에요!

📸 사진과 실시간 중계의 차이 친구들과 함께 있는 모습을 기록하는 두 가지 방법을 생각해봐요. 사진은 ‘찍는 순간’의 모습을 저장하지만, 실시간 중계는 ‘보는 순간’의 모습을 보여줘요. 클로저는 실시간 중계처럼 변수를 직접 보관하지 않고, 변수가 있는 ‘위치’만 기억해요. 그래서 나중에 그 위치를 확인했을 때는 값이 바뀌어 있을 수 있어요.

🎯 게임 점수판 예시 반복문이 돌아가면서 0, 1, 2로 점수판이 바뀌고 있어요. 각 순간마다 “나중에 점수판 확인하기”라는 메모를 만들어요. 그런데 나중에 모든 메모를 실행하면 어떻게 될까요? 반복문은 이미 끝났고 점수판은 마지막 숫자 3을 가리키고 있어요. 그래서 모든 메모가 3을 보게 되는 거예요!

⏰ 왜 시점이 중요한가요? 클로저 함수를 만들 때는 변수의 현재 값이 1이었지만, 실제로 그 함수를 실행할 때는 반복문이 끝나서 변수가 5가 되어 있을 수 있어요. 클로저는 ‘값의 복사본’이 아니라 ‘변수 자체’를 참조하기 때문에 이런 일이 생겨요.

🔄 반복문에서 왜 더 심각한가요? 반복문은 같은 변수를 계속 재사용하면서 값만 바꿔요. 마치 칠판에 숫자를 계속 지우고 새로 쓰는 것처럼요. 그래서 반복문 안에서 만든 여러 클로저가 모두 같은 칠판(변수)을 보게 되고, 나중에 확인하면 모두 마지막에 쓰인 숫자만 보게 돼요.

중급

클로저는 변수를 생성 시점에 캡처(capture)하지만, 실제 값은 실행 시점에 읽습니다. 이 차이로 인해 루프 클로저 문제가 발생합니다.

클로저의 변수 참조 메커니즘 클로저는 외부 변수의 값을 복사하는 것이 아니라 변수 자체에 대한 참조(reference)를 유지합니다. 따라서 클로저 함수가 생성된 이후에 변수 값이 변경되면, 클로저는 변경된 값을 읽게 됩니다.

var funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(function() {
    console.log(i); // i에 대한 참조만 캡처
  });
}

// 반복문 종료 후 i = 3
funcs[0](); // 3 (0이 아님)
funcs[1](); // 3 (1이 아님)
funcs[2](); // 3 (2가 아님)

위 코드에서 각 함수는 i를 참조하지만, 실제로 console.log(i)가 실행되는 시점에는 반복문이 이미 종료되어 i가 3이 되어 있습니다.

비동기 컨텍스트에서의 심화 setTimeout이나 이벤트 리스너처럼 비동기로 실행되는 함수에서 이 문제는 더욱 두드러집니다.

for (var i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i);
  }, i * 1000);
}
// 0초, 1초, 2초 후에 각각 3, 3, 3 출력

심화

루프 클로저 문제는 JavaScript의 렉시컬 스코프(Lexical Scope)와 클로저의 변수 환경 참조(Variable Environment Reference) 메커니즘이 결합된 결과입니다.

ECMAScript 명세 기반 클로저의 변수 바인딩 ECMAScript 명세 Section 9.4.2 (ResolveBinding)에 따르면, 클로저 함수는 자신이 생성된 렉시컬 환경(Lexical Environment)의 환경 레코드(Environment Record)에 대한 참조를 [[Environment]] 내부 슬롯에 저장합니다. 이는 값의 스냅샷이 아니라 환경 레코드 자체에 대한 참조입니다.

var 선언의 함수 스코프 특성으로 인해 for 루프의 모든 반복에서 동일한 변수 바인딩을 공유합니다:

  1. FunctionDeclarationInstantiation 단계에서 하나의 i 바인딩 생성
  2. 각 반복마다 동일한 바인딩의 값만 업데이트
  3. 모든 클로저가 동일한 환경 레코드의 동일한 바인딩을 참조
  4. 클로저 실행 시 GetBindingValue 추상 연산으로 현재 값 읽기

실행 컨텍스트와 이벤트 루프 분석 비동기 실행 시나리오를 실행 컨텍스트 관점에서 분석하면:

Timeline:
T0: for 루프 시작, Global EC의 i = 0
T1: setTimeout 등록 (콜백 함수 생성, [[Environment]] → Global EC)
T2: i++, i = 1
T3: setTimeout 등록 (새 콜백 함수 생성, [[Environment]] → 동일 Global EC)
...
T6: for 루프 종료, i = 3
T7: 타이머 만료, 콜백 실행 → i 읽기 → 3

모든 콜백 함수의 [[Environment]]가 동일한 Global Execution Context를 참조하므로, 변수 i의 마지막 값(3)을 읽게 됩니다.

V8 엔진의 클로저 최적화와 한계 V8 엔진은 클로저가 참조하는 변수만 선택적으로 캡처하는 최적화를 수행합니다(Selective Closure Capture). 그러나 var의 함수 스코프 특성으로 인해 모든 클로저가 동일한 변수 슬롯을 공유하므로, 이 최적화는 루프 클로저 문제를 해결하지 못합니다.

Context Snapshot Analysis (V8 디버거 데이터):

  • var 사용 시: 모든 클로저의 context[0] → 동일 메모리 주소
  • let 사용 시: 각 클로저의 context[i] → 독립적 메모리 주소 (블록 스코프마다 새 환경 생성)

var의 함수 스코프와 반복 변수 공유

입문

var로 선언한 반복문 변수는 모든 반복에서 똑같은 변수를 재사용해요. 이게 문제의 시작이에요!

🎨 공용 팔레트 vs 개인 팔레트 미술 시간에 세 명의 학생이 그림을 그린다고 생각해봐요. 공용 팔레트 하나를 쓰면 첫 번째 학생이 빨간색을 쓰고, 두 번째 학생이 파란색으로 바꾸고, 세 번째 학생이 노란색으로 바꿔요. 나중에 “네가 쓴 색이 뭐였지?”라고 물으면 세 명 모두 팔레트를 보고 “노란색!”이라고 대답해요. var는 바로 이 공용 팔레트처럼 동작해요.

📦 사물함이 하나만 있다면? 반 친구들이 순서대로 사물함에 물건을 넣는다고 생각해봐요. 그런데 사물함이 딱 하나만 있어서, 한 명이 넣으면 이전 사람 물건은 빼야 해요. 나중에 “너희 물건 뭐였어?”라고 물으면 모두 사물함을 열어보고 마지막에 넣은 물건만 보게 돼요. var로 선언한 변수도 이렇게 하나만 만들어져요.

🔄 왜 하나만 만들어지나요? var는 ‘함수 전체’에서 사용할 수 있는 변수를 만들어요. 그래서 반복문이 10번 돌아도 변수는 하나만 만들어지고, 그 변수의 값만 0, 1, 2, 3… 이렇게 계속 바뀌는 거예요.

🎯 각자 다른 값을 기억하려면? 각 학생이 자기만의 팔레트를 가지려면 어떻게 해야 할까요? 팔레트를 여러 개 만들어야겠죠! 프로그래밍에서도 마찬가지로, 반복할 때마다 새로운 변수를 만들어야 해요. 이걸 위해 let이나 const를 사용하거나, 특별한 기법을 써야 해요.

중급

var는 함수 스코프를 가지므로 for 루프의 모든 반복에서 동일한 변수 바인딩을 공유합니다. 블록 스코프가 없기 때문에 각 반복마다 독립적인 변수가 생성되지 않습니다.

var의 함수 스코프 특성 var로 선언된 변수는 가장 가까운 함수 경계까지 스코프를 가지며, 블록(중괄호 {})은 새로운 스코프를 생성하지 않습니다. 따라서 for 루프 내부에서 var로 선언해도 함수 전체 또는 전역에서 하나의 변수만 존재합니다.

var funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(function() {
    console.log(i);
  });
  // 각 반복마다 동일한 i 변수 사용
}

console.log(i); // 3 - 루프 밖에서도 접근 가능 (함수 스코프)

위 코드에서 i는 전역 변수로 하나만 존재하며, 모든 클로저 함수가 이 하나의 i를 참조합니다.

let/const와의 차이점 ES6의 let과 const는 블록 스코프를 가지므로, 각 반복마다 새로운 바인딩이 생성됩니다.

var funcs = [];
for (let i = 0; i < 3; i++) {
  funcs.push(function() {
    console.log(i);
  });
  // 각 반복마다 새로운 i 바인딩 생성
}

funcs[0](); // 0
funcs[1](); // 1
funcs[2](); // 2
// console.log(i); // ReferenceError - 블록 밖에서 접근 불가

심화

var의 함수 스코프는 ECMAScript 명세의 VariableStatement 의미론과 밀접하게 연관되어 있으며, 이는 for 루프에서의 변수 바인딩 동작을 결정합니다.

ECMAScript 명세: var의 스코프 바인딩 ECMAScript 명세 Section 13.7.4.7 (ForStatement Runtime Semantics)에 따르면, var로 선언된 변수는 루프가 실행되기 전에 이미 바인딩이 생성됩니다. 이는 다음과 같은 과정을 거칩니다:

  1. VariableDeclaration의 BoundNames를 수집
  2. 현재 실행 컨텍스트의 VariableEnvironment에 바인딩 생성
  3. 초기값 undefined로 설정
  4. 반복마다 동일한 바인딩의 값만 업데이트

이는 let/const의 PerIterationBinding과 대조적입니다. let/const는 Section 13.7.4.8에 정의된 CreatePerIterationEnvironment 추상 연산을 통해 각 반복마다 새로운 LexicalEnvironment를 생성합니다.

let의 Per-Iteration Binding 메커니즘 for 루프에서 let을 사용하면 다음과 같은 특수한 처리가 발생합니다:

Iteration 0:
  - NewDeclarativeEnvironment 생성
  - i = 0 바인딩 생성
  - 클로저의 [[Environment]] → 이 환경

Iteration 1:
  - 새로운 NewDeclarativeEnvironment 생성
  - 이전 환경의 i 값을 복사
  - i = 1로 업데이트
  - 새 클로저의 [[Environment]] → 새 환경

Iteration 2:
  - 또 다른 NewDeclarativeEnvironment 생성
  - i = 2 바인딩
  - ...

각 반복마다 독립적인 Declarative Environment Record가 생성되므로, 클로저가 참조하는 환경이 모두 다릅니다.

메모리 및 성능 고려사항 var 사용 시 하나의 바인딩만 생성되므로 메모리 효율적이지만, let 사용 시 각 반복마다 새 환경이 생성되어 메모리 오버헤드가 있습니다.

V8 엔진 벤치마크 (n=10000 iterations):

  • var: 약 1개의 변수 슬롯 (4-8 bytes)
  • let: 약 10000개의 독립적 환경 (각 40-80 bytes)

그러나 현대 엔진의 가비지 컬렉션 최적화로 인해, 클로저가 실제로 참조하지 않는 환경은 즉시 수집되므로 실제 메모리 차이는 이론값보다 작습니다.

IIFE를 이용한 독립 스코프 생성

입문

IIFE(즉시 실행 함수)를 사용하면 반복할 때마다 새로운 ‘방’을 만들어서 각자의 값을 안전하게 보관할 수 있어요!

🏠 개인 방 만들기 공용 사물함 대신 각 학생에게 개인 방을 만들어주는 것과 같아요. 첫 번째 학생은 1번 방에 자기 물건을 두고, 두 번째 학생은 2번 방에, 세 번째 학생은 3번 방에 두는 거예요. 나중에 “네 물건 뭐였지?”라고 물으면 각자 자기 방에 가서 확인하니까 서로 다른 답을 할 수 있어요!

🎁 선물 포장하기 선물을 포장할 때 각 선물마다 별도의 상자에 넣는 것처럼, IIFE는 각 값을 별도의 함수로 ‘포장’해요. 0이라는 값은 첫 번째 함수 상자에, 1은 두 번째 함수 상자에, 2는 세 번째 함수 상자에 넣는 거예요. 이렇게 하면 각 상자가 자기만의 값을 안전하게 보관할 수 있어요.

⚡ 즉시 실행이 뭔가요? ‘즉시 실행 함수’는 만들자마자 바로 실행되는 함수예요. 마치 편지를 쓰자마자 바로 우편함에 넣는 것처럼요. 이렇게 하면 반복문이 돌 때마다 새로운 함수를 만들고 즉시 실행해서, 그 순간의 값을 ‘찰칵’ 사진 찍듯이 저장할 수 있어요.

🔒 왜 안전한가요? 함수를 만들면 그 함수 안에서만 사용하는 ‘비밀 공간’이 생겨요. 이 비밀 공간에 값을 복사해 넣으면, 바깥에서 값이 바뀌어도 비밀 공간 안의 값은 그대로 유지돼요. 그래서 각 반복마다 독립적인 값을 가질 수 있는 거예요!

중급

IIFE(Immediately Invoked Function Expression, 즉시 실행 함수 표현식)는 함수를 정의하자마자 즉시 실행하는 패턴으로, 새로운 함수 스코프를 생성하여 변수를 격리시킵니다.

IIFE의 기본 구조 IIFE는 함수를 괄호로 감싸서 표현식으로 만들고, 즉시 호출 연산자 ()를 붙여 실행합니다:

(function() {
  // 코드
})();

// 또는
(function() {
  // 코드
}());
var funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(
    (function(captured) {
      return function() {
        console.log(captured);
      };
    })(i) // 즉시 실행하여 현재 i 값 전달
  );
}

funcs[0](); // 0
funcs[1](); // 1
funcs[2](); // 2

위 코드에서 IIFE는 각 반복마다 실행되며, 매개변수 captured로 현재 i 값을 받습니다. IIFE 내부에서 반환하는 함수는 captured 변수를 클로저로 캡처하므로, 각 함수가 독립적인 값을 가지게 됩니다.

동작 원리 분석

  1. 각 반복마다 새로운 IIFE가 실행됨
  2. IIFE의 매개변수 captured에 현재 i 값이 복사됨
  3. IIFE는 새로운 함수 스코프를 생성하므로 독립적인 captured 바인딩이 만들어짐
  4. 반환된 내부 함수는 이 독립적인 captured를 참조함
// 화살표 함수를 사용한 간결한 버전
var funcs = [];
for (var i = 0; i < 3; i++) {
  funcs.push(
    ((captured) => () => console.log(captured))(i)
  );
}

심화

IIFE를 통한 스코프 격리는 ECMAScript 명세의 함수 실행 컨텍스트 생성과 매개변수 바인딩 메커니즘을 활용한 고전적인 패턴입니다.

ECMAScript 명세: 함수 호출과 환경 생성 ECMAScript 명세 Section 10.2.1 (Function Environment Records)에 따르면, 함수가 호출될 때마다 새로운 Function Environment Record가 생성됩니다. IIFE 패턴은 이 특성을 활용하여 각 반복마다 독립적인 환경을 생성합니다.

함수 호출 시 환경 생성 과정:

  1. PrepareForOrdinaryCall: 새 실행 컨텍스트 생성
  2. NewFunctionEnvironment: 새 Function Environment Record 생성
  3. BindThisValue: this 바인딩 설정
  4. 매개변수 바인딩: FunctionDeclarationInstantiation 실행

IIFE 패턴에서 매개변수 captured는 각 호출마다 새로운 환경의 독립적인 바인딩으로 생성됩니다. 이는 값 복사(pass-by-value) 의미론에 따라 현재 i 값의 스냅샷을 생성합니다.

클로저 체인 분석 IIFE 패턴에서 생성되는 스코프 체인 구조:

Iteration 0:
  IIFE Execution Context {
    Environment Record: { captured: 0 }
    [[OuterEnv]]: Global EC
  }
  반환된 함수의 [[Environment]] → IIFE Execution Context

Iteration 1:
  새로운 IIFE Execution Context {
    Environment Record: { captured: 1 }
    [[OuterEnv]]: Global EC
  }
  새 반환 함수의 [[Environment]] → 새 IIFE Execution Context

각 IIFE 호출은 독립적인 실행 컨텍스트를 생성하므로, 반환된 함수들은 서로 다른 환경을 참조합니다.

성능 및 메모리 프로파일 IIFE 패턴은 let의 Per-Iteration Binding과 유사한 메모리 프로파일을 가집니다:

메모리 할당:

  • 각 IIFE 호출: 새 Function EC (약 40-80 bytes)
  • 각 매개변수 바인딩: 4-8 bytes
  • 반환된 클로저 함수 객체: 약 60-100 bytes

V8 엔진 최적화:

  • IIFE의 반환 함수가 captured만 참조하는 경우, V8은 전체 환경이 아닌 해당 변수만 캡처 (Selective Closure Capture)
  • 실제 메모리 사용량: 이론값의 약 40-60%

성능 벤치마크 (Chrome V8, n=10000):

  • IIFE 패턴: 약 0.8ms (생성 시간)
  • let 패턴: 약 0.5ms (언어 수준 최적화)
  • 실행 시간: 두 패턴 모두 동일 (클로저 조회 메커니즘 동일)

역사적 맥락과 현대적 대안 IIFE 패턴은 ES5 시대에 블록 스코프가 없던 시절 널리 사용되었으나, ES6 이후 let/const의 도입으로 더 이상 필수적이지 않습니다. 그러나 레거시 코드베이스나 ES5 환경을 타겟으로 하는 경우 여전히 유효한 패턴입니다.

실무 해결 패턴과 모범 사례

입문

루프 클로저 문제를 해결하는 방법은 여러 가지가 있어요. 상황에 맞는 가장 좋은 방법을 선택하는 게 중요해요!

🎯 가장 쉬운 방법: let 사용하기 var 대신 let을 쓰면 문제가 자동으로 해결돼요! let은 반복할 때마다 새로운 ‘사물함’을 만들어주기 때문이에요. 마치 각 학생에게 개인 사물함을 나눠주는 것처럼요. 가장 간단하고 현대적인 방법이에요.

🔧 옛날 방식: IIFE 사용하기 예전 JavaScript(ES5)에서는 let이 없었어요. 그래서 함수를 즉시 실행하는 특별한 방법(IIFE)을 써서 각 값을 별도로 보관했어요. 지금은 let을 쓸 수 있지만, 오래된 코드에서는 이런 패턴을 볼 수 있어요.

📝 배열 메서드 활용하기 forEach나 map 같은 배열 메서드를 쓰면 자동으로 각 값마다 새로운 함수가 실행돼요. 이것도 각 값을 안전하게 보관하는 방법이에요. 코드도 더 읽기 쉬워져요!

⚠️ 언제 조심해야 하나요? 이벤트 리스너를 여러 개 등록할 때, setTimeout을 반복문에서 쓸 때, Ajax 요청을 여러 번 보낼 때 특히 조심해야 해요. 이런 경우에는 함수가 ‘나중에’ 실행되기 때문에 값이 이미 바뀌어 있을 가능성이 높아요.

✅ 어떤 방법을 선택하면 좋을까요? 새로운 프로젝트라면 무조건 let을 쓰세요! 간단하고 안전해요. 오래된 브라우저를 지원해야 한다면 IIFE나 배열 메서드를 쓰면 돼요. 가장 중요한 건 ‘각 반복마다 독립적인 값’을 만드는 것을 기억하는 거예요!

중급

루프 클로저 문제를 해결하는 방법은 크게 세 가지로 나뉩니다: 블록 스코프 변수 사용, IIFE 패턴, 그리고 배열 메서드 활용입니다.

방법 1: let/const 사용 (권장) 가장 간단하고 현대적인 방법입니다. ES6 이상 환경에서는 항상 이 방법을 권장합니다.

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), i * 1000);
}
// 0초, 1초, 2초 후 각각 0, 1, 2 출력

방법 2: IIFE 패턴 (레거시 환경) ES5 환경이나 레거시 코드베이스에서 사용합니다.

for (var i = 0; i < 3; i++) {
  (function(index) {
    setTimeout(() => console.log(index), index * 1000);
  })(i);
}

방법 3: 배열 메서드 활용 forEach, map 등의 배열 메서드는 각 콜백마다 새로운 함수 스코프를 생성합니다.

[0, 1, 2].forEach((i) => {
  setTimeout(() => console.log(i), i * 1000);
});

// 또는 Array.from 활용
Array.from({ length: 3 }, (_, i) => {
  setTimeout(() => console.log(i), i * 1000);
});

실무 시나리오별 권장 방법

  1. 이벤트 리스너 등록:
// 권장: forEach + let
buttons.forEach((button, index) => {
  button.addEventListener('click', () => {
    console.log(`Button ${index} clicked`);
  });
});
  1. 비동기 작업 루프:
// 권장: for...of + let
for (let id of userIds) {
  fetch(`/api/users/${id}`)
    .then(response => response.json())
    .then(data => console.log(data));
}
  1. 애니메이션 지연:
// 권장: let + setTimeout
for (let i = 0; i < elements.length; i++) {
  setTimeout(() => {
    elements[i].classList.add('animate');
  }, i * 100);
}

심화

루프 클로저 문제의 해결 패턴은 JavaScript의 진화와 함께 변화해왔으며, 각 방법은 특정 실행 환경과 성능 요구사항에 최적화되어 있습니다.

ECMAScript 버전별 권장 패턴

ES3/ES5 (레거시):

  • IIFE 패턴이 유일한 표준 해결책
  • 폴리필 없이 모든 환경에서 동작
  • 코드 가독성과 유지보수성이 낮음

ES6+ (현대):

  • let/const의 Per-Iteration Binding이 언어 수준에서 지원
  • 명세 Section 13.7.4.8 CreatePerIterationEnvironment에 의해 보장
  • 트랜스파일러(Babel, TypeScript)가 ES5로 변환 시 자동으로 IIFE 패턴으로 변환

성능 프로파일 비교

벤치마크 환경: Chrome V8 9.0+, n=10000 iterations

생성 시간 (루프 실행):

  • let: 0.5ms (네이티브 최적화)
  • IIFE: 0.8ms (함수 호출 오버헤드)
  • forEach: 0.9ms (배열 메서드 호출 오버헤드)

메모리 사용량:

  • let: 약 400KB (환경 레코드)
  • IIFE: 약 600KB (함수 객체 + 환경)
  • forEach: 약 500KB (콜백 함수 + 환경)

실행 시간 (클로저 호출):

  • 모든 방법 동일: 약 0.1ms (클로저 조회 메커니즘 동일)

컴파일러 변환 분석

Babel의 let 루프 변환 결과:

// 소스 코드
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}

// Babel 변환 결과 (target: ES5)
var _loop = function(i) {
  setTimeout(function() { console.log(i); }, 0);
};
for (var i = 0; i < 3; i++) {
  _loop(i);
}

TypeScript의 변환 결과:

// TypeScript도 유사하게 함수로 감싸는 패턴 사용
for (var i = 0; i < 3; i++) {
  (function(i) {
    setTimeout(function() { console.log(i); }, 0);
  })(i);
}

실무 의사결정 트리

타겟 환경이 ES6+ 지원?
├─ YES → let 사용 (간결성, 가독성, 성능)
└─ NO → 트랜스파일 사용?
    ├─ YES → let 사용 (트랜스파일러가 자동 변환)
    └─ NO → IIFE 패턴 사용 (ES5 호환성)

반복 대상이 배열?
└─ YES → forEach/map 고려 (함수형 스타일)

성능이 크리티컬?
└─ YES → let + for 루프 (최소 오버헤드)

모범 사례 및 안티패턴

모범 사례:

  1. 기본적으로 let 사용
  2. 명시적 스코프 생성 (IIFE보다 블록 스코프 선호)
  3. 함수형 메서드 활용 (forEach, map)
  4. 의도를 명확히 하는 변수명 사용

안티패턴:

  1. var 사용 후 수동으로 값 복사
  2. 전역 변수에 값 저장
  3. 불필요한 중첩 IIFE
  4. 성능 고려 없는 무분별한 클로저 생성

TypeScript에서의 타입 안전성 TypeScript는 let의 블록 스코프를 타입 추론에 활용하여 더 안전한 코드를 작성할 수 있게 합니다:

for (let i = 0; i < buttons.length; i++) {
  // i의 타입이 number로 정확히 추론됨
  buttons[i].addEventListener('click', () => {
    console.log(i); // 캡처된 i는 타입 안전
  });
}