JEHEECHEON

지난 달에 NFT 마켓플레이스에서 관심 있는 아이템을 발견했었다.그런데 가격이 좀 애매해서 판매자와 흥정해보고 싶었는데, 사이트 내에서 연락할 방법이 따로 존재하지 않았다.. 굳이 하려면 Discord 서버를 찾아보거나 트위터에서 직접 DM을 보내야만 했다...근데 거기까지 가면 이미 귀찮아서 안 하게 된다. "마켓플레이스 페이지를 떠나지 않고 바로 대화할 수 있으면?" 이라는 생각이 계속 남아 있었고, 그래서 사이드 프로젝트로 직접 만들어보기로 했다.근데 문제가 하나 있다. 채팅 서비스를 만들려면 반드시 서버가 필요하다.경험상, 사이드 프로젝트에 월 몇만원이라도 유지비가 발생하면 결국 나중에 내려버리게 되는 경험이 있었다그래서 이번 플젝에서는 스스로 제약을 하나 걸었다. "서버 비용 $0"WebRTC라는 기술이 있다. 이걸로 서버를 거치지 않고 직접(P2P) 데이터를 주고받을 수 있도록 할 수 있다. 텍스트든 음성이든 영상이든 서로 직접 교환하는 게 가능하다..!그런데 함정, 단점이 하나 있다.WebRTC를 쓰려면 "시그널링"이라는 단계가 필요하다. 두 브라우저가 서로를 찾고 연결을 맺기 위한 초기 정보를 교환하는 시그널링이란 단계가 필요하다는 것이다. 서버없는 구조를 원했지만 WebRTC 프로토콜 또한 구조상 어쨌든 중간 서버가 필요했다.그래서 시그널링을 위해서... 무료로 사용가능한 서버 후보를 리서치해봤다.나는 100% 무료인 Nostr를 골랐다. Trystero라는 라이브러리에서 Nostr 프로토콜도 쉽게 활용할 수 있는 구조여서 구현하기에 큰 부담도 되지 않을 거라 판단했다.그런데 트레이드오프가 100% 없진 않았다. 전용 시그널링 서버와 비교하면 지연시간 500ms 정도는 느렸다..!보통 일반적인 채팅앱은 세션을 서버가 발급하고 인증하지만, 나는 서버를 사용하는 옵션은 모두 배제해야 했다. 대신에 가용 가능한 방식이 "종단간 암호화"였다. 종단간 암호화란 클라이언트가 공개키/암호키 방식으로 직접 암호화/복호화 하며 데이터를 주고받는 방식이다.먼저 이 종단간 방식으로 구현하려면 개인키/공개키를 개인이 생성하거나 소유하고 있어야 하는데, 내 서비스는 이미 Web3에서 동작하는 웹앱이었다.즉 블록체인을 사용하는 사람이라면 월렛이라는 특수한 형태의 개인키를 모두 소유하고 있기 때문에, 이걸 그대로 사용하면 개인의 신원 증명 뿐만 아니라 메시지 암호/복호화에도 활용할 수 있었다.아무튼 채팅방에 입장할 때 양쪽 모두 자신의 지갑으로 서명을 하고, 상대방이 보낸 서명을 공개키로 검증하는 방식으로 디자인했다.이렇게 큰 틀은 완성시킬 수 있었으나 구현을 어느정도 진행하니 채팅방이라는 시스템에서 다뤄야할 엣지케이스가 꽤나 많았다. 채팅방의 주인 입장에서 갑자기 누군가 접속하면? -> 수락/거절할 수 있어야 한다. 신원 검증이 실패하면? 연결을 즉시 끊어야 한다. 한쪽이 브라우저를 강제종료되면? 상대방 화면에서 세션이 정리가 되어야 한다. 채팅 중에 네트워크가 끊기면?... 등등결국 Peer의 상태를 명시적으로 관리하는 상태머신을 그려보고 설계까지 이어지게 됐다.서명검증(Verifying) → 채팅요청(Requesting) → 승인 대기(Pending) → 채팅중(Chatting)+거절, 검증 실패, 연결 종료 같은 예외 분기까지. 총 8단계.이런 식의 P2P로 동작하는 채팅방에는 근본적인 한계가 하나 있다. 바로, 양쪽 모두 온라인 상태인 경우에만 서로 연결을 맺고 대화 가능한 상태가 되는 것이다...그래서 만약 어느 한 쪽이라도 오프라인이면 대화가 불가능하기 때문에 댓글 처럼 메시지를 남길 수 있는 수단이 필요했다. 그런데 댓글 또한 마찬가지로 DB와 서버 없이는 일반적으로 구현할 수 없다.그래서 여기서 Nostr를 또다시 활용해보게 됐다. 시그널링 용도로만 쓰려던 Nostr을 댓글을 저장/조회하는 데도 활용하는 것이다. Nostr 프로토콜은 누구나 데이터를 발행하고 조회할 수 있는 구조라서, 댓글 저장소로 쓰는 게 가능했다.다만 여기서도 Web3의 월렛을 이용했다. 댓글을 작성/수정/삭제 하기 전에 사용자의 월렛으로 메시지를 서명하여 댓글이 소유권이 보장되도록 구현했다.+ 다만 Nostr은 데이터를 영구 저장해주지 않을 수 있다. Nostr 릴레이는 각자의 보존 정책이 있어서 며칠에서 몇 달 정도 유지된다. 이건 $0 제약 안에서는 감수할 수밖에 없었다.해당 프로젝트는 Opensea 또는 Blur 같은 NFT 마켓플레이스에 채팅 수단을 제공하기 위한 목적으로 시작한 프로젝트였다.그런데 내 서비스를 사용하기 위해서 기존 호스팅 사이트 내부가 아닌 경로를 거쳐야 접근할 수 있다면 접근성이 떨어져서 아무도 사용하지 않을 게 분명했다...이때 떠오른 답이 크롬익스텐션으로 배포하는 것이었다. 익스텐션은 한 번만 설치해두면 외부사이트의 DOM을 조작할 수 있기 때문에, 내 서비스로 연결시켜주는 버튼을 주입시킬 수 있었다일반적으로 Web3 사용자 대부분은 자신의 월렛을 Metamask 등의 크롬익스텐션에 등록해둔다. 만약 웹페이지 내에서 월렛 서명이 필요한 경우에 이러한 익스텐션을 거쳐서 사용자의 월렛을 활용할 수 있는 구조이다.즉 사이트 내에서 사용자 월렛으로 데이터를 서명하려면 아래와 같은 순서를 따른다...!웹사이트 -> Metamask(Provider) -> 월렛그런데 문제는 내 서비스도 크롬익스텐션이라는 환경 내에서 실행되어야 했고, 일반적인 웹사이트와는 구동환경이 크게 다르다.브라우저에서 일반적인 방식으로 접근하는 페이지는 Main 환경이라 불리며, 크롬익스텐션으로 동작하는 웹앱은 "Isolated"라는 분리된 구동환경이다. 정리하면 아래와 같다.Metamask 같은 월렛제공자 역할을 하는 크롬익스텐션은 당연 Isolated 환경에서 실행되며, Main 환경인 호스트 웹페이지에서만 이것과 소통이 가능한 구조이다.그런데 내 서비스 또한 Isolated 환경에서 동작하는 익스텐션이기 때문에 Main 환경인 호스트와만 소통이 가능하다는 제약이 따라오게 됐다.즉, 익스텐션끼리 소통하는 게 원초적으로는 불가능하기 때문에, 내 익스텐션에서 Metamask를 통한 사용자 월렛에 도달하는 게 불가능한 구조였다.그래서 이리저리 방안을 찾아보았는데, 정공법으로 Main 환경에 프록시 역할을 하는 스크립트를 심는 게 가능했다.즉 익스텐션인 내 서비스가 Main 호스팅 환경을 거쳐서 Metamask와 통신하는 구조를 만드는 게 이론적으로는 가능했다. 위 구조를 통해서 사용자의 서명이 필요할 때 내 서비스에서 Background, ISOLATED, MAIN을 거쳐 지갑에 도달하고 다시 역순으로 결과를 받아내는 구조이다.꽤 복잡했지만... 이론적으로 가능한 설계였다스스로 걸어둔 "서버비용 $0"라는 제약이 나중에 기술적 의사결정에 많은 영향을 줬다. 서버를 호스팅하지 않기 위해 우회방법을 매번 고민하게 만들었다...시그널링? -> Nostr 프로토콜. 사용자 인증? -> Web3 서명. 댓글 저장? -> Nostr 프로토콜.서버비용을 없애려다보니 따라오는 트레이드오프도 당연 존재했다.WebRTC는 양방향 통신이니 서로가 온라인이어야 연결맺음이 가능하고, 무료로 가용 가능한 Nostr 서버는 어찌 됐든 빌려쓰는 것이기 때문에 데이터 보존보존 기간은 각각의 서버 정책에 의존해야 했다. 결국 서버비용 $0 제약 아래에서 모두 감수해야 했다.Chrome Web Store: 클릭GitHub: 클릭서버비용 $0, 스스로 걸어둔 제약 아래에서 방향을 이리저리 틀어가며 답을 찾아야했다. 막막하고 골아픈 지점이 꽤 많았지만, 그만큼 새로운 시도도 많이 해볼 수 있어서 꽤 

최근 거래 데이터를 시각화하는 과정에서, 일반적인 차트 라이브러리로는 해결하기 힘든 복합 차트(Composite Chart) 요구사항을 마주했다. 단일 차트가 아닌, 서로 다른 성격의 데이터를 하나의 좌표계 위에 중첩하여 표현하는 것이 핵심이었다.구체적으로 구현해야 했던 차트의 스펙은 다음과 같았다.초기에는 생태계에서 점유율이 높은 라이브러리들을 우선 검토했다. (, ,  등등...)이 라이브러리들은 공통적으로 “시작하기 쉬운 조건”을 갖고 있다.그 이유는그런데 이러한 라이브러리로 복합 차트를 만들기 시작하면 금방 한계점에 부딪힌다.왜냐하면 차트별 정교한 위치 조정이 어렵고, 서로 다른 도메인(Y축 스케일 등) 데이터를 한 차트에 동시에 표현하는 데 제약이 있기 때문이다. 툴팁을 부분별로 다르게 표현하는 것도 불가능하거나 매우 복잡했다.우리 팀에 필요했던 건 위와같은 "시작하기 쉬운 조건"이 아니라,…같은, 현실적으로 꽤 욕심 많은 조건이었다. (현실은 항상 빡셈)그래서 “커스터마이징”을 최우선 기준으로 다시 리서치했고, 최종적으로  라는 차팅 라이브러리를 선택하게 됐다.는 차트의 뼈대가 되는  안에 ,  같은 다양한 Series 컴포넌트들을 자식(children)으로 넣어 조립하는 방식을 취한다.거래량 막대그래프가 필요하면  컴포넌트를 끼워 넣고, 그 위에 라인그래프가 필요하면  컴포넌트를 추가하면 되는 식이다. 에서 대부분의 차트 컴포넌트가 이렇게 독립적으로 분리되어 있다 보니, 언뜻 보기에는 내가 원하는 대로 자유롭게 레이어를 쌓아 올리기만 하면 복합 차트가 뚝딱 완성될 것처럼 직관적이어 보였다.하지만 막상 개발 깊숙이 들어가자, 이 유연함 뒤에 숨겨진 명확한 Trade-off를 마주하게 되었다.가장 당황스러웠던 점은  측의 내부 소스코드에서 를 통해 부모 컴포넌트가 자식의 Props를 강제로 덮어씌우는 패턴이 빈번하다는 것이다. 이는 가 모든 요소를 독립적인 컴포넌트로 잘게 쪼개놓은 구조였기 때문에 발생하는 부작용이었다.각 컴포넌트가 독립적으로 존재하다 보니, 부모 컴포넌트가 자식에게 필요한 상태나 동작을 전달하기 위해 로 Props를 주입하는 방식을 택한 것이다.아래 예시코드에서  를 다음과 같이 전달하면, 보통은 툴팁이 비활성화 상태가 될 것을 예상한다. (아마도...)하지만 실제로 가 내부코드에서 무시된 채 툴팁이 버젓이 렌더링 된다....?! 이유는 부모인 가 내부에서 를 사용해 자식을 복제할 때, 자신의 로직에 따라  속성을 강제로 덮어씌워 버리기 때문이다.적어도 Props를 받을 거면 동작해야 하고, 동작을 안 시킬 거면 차라리 받지 않는 게 API 신뢰도 측면에서 맞지 않을까 싶었다...(당연한 건가..?)동작이 예상과 다르니 자연스럽게 문서를 찾게 되는데, 여기서 두 번째 문제가 터진다.공식 문서가 대부분 단일 차트(Single Chart) 기준으로만 정리되어 있었다.즉, 우리가 구현하려던 복합 차트에 필수적인 내용들은 정작 문서에서 빠져있는 부분이 많았다.로 인해 Props가 무시되는 상황에서 문서조차 얇으니, 결국 해결책은 하나뿐이었다.코드를 로컬로 내려받고 내부 소스 코드를 직접 까보며 개발하는 것....또는, 오픈소스를 Claude Code에 학습시키고 질문하는 것....결국 구현 과정은 아래와 같은 삽질의 반복이었다.로 바닥부터 만드는 것보다는 낫겠지만, 이런 상황이 가끔 반복될 때마다 라이브러리를 사용하는 이점이 희석되는 느낌이었다.그렇게 내부 코드를 뜯어보며, 왜 이런 불편함이 생겼는지 설계적인 이유를 알게 되었다.내가 겪은 불편함은 단순한 버그가 아니라, 를 얻기 위해 포기한 에서 오는 것이었다.: 거의 모든 기능이 독립적인 컴포넌트로 분리되어 있고 Provider 의존성이 없음.→ 장점: "블록 조립"하듯 자유로운 배치가 가능함.→ 단점: 부모-자식 간 데이터 전달을 위해  같은 무리한 패턴이 등장함. / : Provider 의존성이 강함.→ 단점: 컴포넌트를 개별적으로 떼어내어 사용하기 어려움.→ 장점: Context를 통해 상태를 공유하므로 동작이 예측 가능하고 구조가 명확함.결국 는 를 선택하는 대신 안정적인 한 셈이다.를 서비스에 붙이고 나니 예상치 못한 버그도 몇 번 나왔다. 그중 가장 인상적이었던 건 툴팁 위치 증발 이슈였다.차트 위에 툴팁이 떠 있는 상태에서 으로 다른 앱에 다녀오면, 툴팁이 갑자기 화면 좌상단(0,0) 좌표로 튀어버린다.근본적인 원인은 툴팁의  상태가 바뀔 때 컴포넌트의 Mount/Unmount가 반복되는 데 있었다.툴팁 컴포넌트가 다시 마운트될 때, 이전의 내부 상태(특히 마우스 위치 컨텍스트)를 잃어버리면서 기본 좌표값인 (0,0)으로 초기화되는 것이었다. (물론 이후 마우스를 살짝이라도 움직이면 다시 정상 위치로 돌아온다.)사용자 경험(UX) 관점에서 그냥 넘기기엔 너무 어색한 버그였다. 결국 코드를 파고들어 해당 로직을 수정했고, PR을 올려둔 상태다.(PR: https://github.com/reaviz/reaviz/pull/312)는 “자유로운 커스터마이징”이라는 목표에는 확실히 성공했다고 본다.하지만 그만큼의 대가로 개발자가 치러야 할 Trade-off가 컸고, DX 관점에서는 아쉬움이 남았다."이번 경험을 통해 자유도와 DX는 반비례 관계에 가깝다는 것을 뼈저리게 배웠다."만약 다시 선택의 순간이 온다면, 나는 이런 기준으로 결정할 것이다.

요즘 Solid.js가 꽤 빠르게 존재감을 키우고 있다.React와 문법이 비슷해서 진입장벽이 낮고, 성능은 “현시점 최상급”이라는 평가를 자주 본다.다만 프론트 기술을 선택할 때 늘 걸리는 질문이 있다.여기서 변수는 늘 똑같다.React는 커뮤니티와 레퍼런스, 그리고 압도적인 오픈소스 생태계를 가진다. Solid.js가 성능에서 강점을 가진다 해도, 는 별개의 이야기다.나는 React로 프론트를 제대로 시작했다. (엄밀히는 Blazor를 먼저 만지긴 했지만, “프론트 개발을 계속하게 만든 계기”는 React였다.)3년 정도 React/Next.js를 쓰면서, 성능이 아쉬워서 다른 걸 고민해본 적은 많지 않았다.솔직히 말하면, 내가 다뤘던 제품들은 “렌더링 성능이 치명적인” 종류가 아니었다.그래서 리렌더 비용이 커 보이는 곳에 useMemo, useCallback을 습관처럼 달아두긴 했지만… 대부분은 지워도 차이가 없었다.(이게 React가 느리다는 뜻이 아니라, 는 뜻에 가깝다.)그런데 Solid.js는 “React 문법과 비슷하다”는 이야기가 많아서, 한번 직접 체감해보고 싶었다.마땅한 토이 아이디어가 떠오르지 않던 시점에, 예전에 급하게 만들어 둔 블로그가 떠올랐다.React 입문 시절에 만들었던 거라 구조도 엉성했고, “언젠가 고쳐야지”가 계속 쌓여 있던 상태였다.그래서 결론은 단순했다.주말마다 조금씩 손대다 보니 대략 5월 초부터 시작해서 7월 초쯤 “굴러가는 수준”까지는 도달했다.이 글은 그 과정에서 느낀, 아주 현실적인 후기다.Solid.js는 “새로운 실험용 라이브러리”라기엔 꽤 성숙해 보였다.React에서 쓰던 것들이 Solid 버전으로 포팅되어 있는 경우가 많아서, 초반에 막히는 지점이 적었다.예를 들면 이런 것들:이건 분명 장점이다.그런데 개인적으로는 이번 목적은 “새로운 사고방식/개념을 배우는 것”에 가까웠는데,막상 개발을 시작하면 기존 React에서 쓰던 조합을 그대로 가져오게 되면서결국 또 Comfort zone에 머무르는 느낌이 들었다.Solid.js에서 제일 중요한 건 “React처럼 보인다”는 착시를 빨리 버리는 거였다.React가 Hooks 중심의 사고라면, Solid는  중심이다.그래서 네이밍도 보통 use- 대신 create-가 많다.겉으로 보기엔 비슷하지만, “비슷해 보이니까 React처럼 쓰면 되겠지”라는 기대는 금방 깨진다.가장 당황했던 건 이거였다.React에서는 너무 자연스러운 스타일인데, Solid에서는 조심해야 한다.처음엔 “이게 버그인가?” 싶었는데, 원리를 보면 납득은 된다. (props가 Proxy 기반으로 동작하고, 구조분해는 그 연결을 끊어버리는 식)문제는 납득과 별개로, 개발 경험은 이렇게 느껴졌다는 거다.즉, 제대로 쓰려면 결국 바닥부터 개념을 다시 잡아야 한다. Solid.js는 React의 “대체품”이라고 보기엔 극명하게 다르다.이번 프로젝트(블로그)에서는 Solid.js의 성능이 크게 체감되진 않았다.당연한 얘기다. 블로그 정도는 성능이 병목이 되는 경우가 드물고,지금은 배포 환경 자체가 무료 플랜이라 더 느린 쪽이 원인이다. (하하)그래도 얻은 건 있다.

이번 글에서는 이전에 깊게 다루지 못했던 Execution Context의 Lexical Environment에 대해 좀 더 파헤쳐보려 한다.Execution Context는 생성 단계에서 아래 3가지 구성요소를 만든다.는 현재 실행 중인 코드가 어떤 객체의 맥락에서 동작하는지를 가리키는 키워드다. 이 값은 함수의 호출방식에 따라 달라지며, 에 저장된다.단, 화살표 함수는 자체  없이 선언 시점 외부 스코프의 this를 사용한다. 이는 뒤에서 다룰 과 같은 원리다.이전 글에서 생성 단계에서 var 선언은 undefined로 초기화되고, 함수 선언문은 함수 객체 자체가 적재된다고 했다.이 처리가 이뤄지는 공간이 바로  이다.는 Execution Context 생성 시점의 초기 상태를 그대로 유지하는 것이 특징이다. 코드가 실행되면서 블록 스코프 등에 의해 환경이 변할 수 있는데, 는 그 변화와 무관하게 처음 상태를 보존한다.이번 글에서 집중적으로 다룰 대상이다.JavaScript에서 스코프는 함수가 호출된 위치가 아니라 정의된 위치(코드가 작성된 위치)를 기준으로 결정된다.이를 이라 부른다.는 이 규칙을 엔진 내부에서 구현하는 모델로, 식별자(변수/함수 이름)와 그 값을 연결하고 을 관리한다. 가 생성 시점의 초기 상태를 유지하는 반면, 는 실행 중 블록스코프(let/const) 진입 등에 따라 동적으로 변한다.Lexical Environment를 좀 더 자세히 들여다보자. 는 아래 두가지 구성요소로 이뤄진다.실제로 식별자와 값을 연결하고 저장하는 "저장소" 역할이다. 성격에 따라 두 종류로 나뉜다.현재 가 자신을 감싸는 외부 스코프를 가리키는 참조다. 이 참조들이 연쇄적으로 연결되면서 이 만들어진다.덕분에 내부 스코프에서 외부 스코프의 변수를 찾을 수 있다.그리고 이 구조가 그대로  와 연결된다.클로저는 함수가 선언될 당시의 outer Lexical Environment를 기억해두고, 나중에 실행될 때도 그 환경을 계속 참조할 수 있게 해준다. 즉, 함수 실행이 끝나도 참조가 살아있다면, 엔진은 그 환경을 GC로 정리하지 못한다.https://www.webdevlog.com/p/how-js-works-lexical-environment/http://dmitrysoshnikov.com/ecmascript/es5-chapter-3-1-lexical-environments-common-theory/

Execution Context를 한 줄 요약을 하면 아래와 같다.JavaScript는 C/C++처럼 main() 함수 안에서만 코드가 실행되는 구조가 아니다. 전역(Global)에서도 코드를 작성할 수 있고, 함수 내부에서도 별도의 코드 블록이 실행된다.엔진 입장에선 “지금 어떤 범위의 코드가 실행 중인지”를 추적해야 하므로, 실행 단위별로 컨텍스트를 만들어 관리한다.Execution Context는 크게 두 종류로 나뉜다.즉, 실행이 시작되면 가 먼저 생성되고, 함수가 호출될 때마다 그 위에 가 추가로 생긴다.C/C++에서는 main()이 스택의 시작점이지만, JavaScript는 명시적인 entry 함수가 없기 때문에 에 깔린다. 이후 함수 호출이 일어나면 컨텍스트가 스택 위로 쌓이고, 함수 실행이 끝나면 스택에서 빠진다.이 방식 덕분에 아래가 자연스럽게 가능해진다.그렇다면 Execution Context의 주기는 어떻게 될까?Execution Context의 주기는 일반적으로 아래와 같이 와 로 나눈다.생성 단계에서 엔진은 코드를 실행하기 전에 "실행을 위한 준비"를 한다. 이때 처리되는 항목은 다음과 같다.Execution Context의 생성단계에서 변수선언문과 함수선언문 각각 처리되는 방식이 극명하게 다르다. 키워드로 선언된 변수의 경우 메모리영역만 먼저 확보되고, 값이 할당되지 않음을 의미하는  로 초기화된다.때문에 아래 코드가 실행되면 생성단계에서 할당받는 기본값인  가 출력된다.그러나  키워드를 통한 함수선언문은 실질적인 메모리적재까지 받는다.때문에 코드의 물리적인 순서와 관계없이 호출가능한 상태가 되고 이런 이질적인 현상을 JS의 Hoisting 현상이라고 부르기도 한다.그런데 이러한 Hoisting현상은 Execution Context의 생성단계에 의한 단순한 성질일 뿐이었다. 겉으로는 함수코드가 물리적으로 위쪽으로 이동된 게 아닐까 싶지만, 근본적인 이유는 실행 전에 함수코드만 메모리적재를 먼저 받아내기 때문에 그렇다.생성단계를 실행에 필요한 준비단계라고 한다면, 실행단계는 코드의 직접적인 실행이 이뤄지는 단계라고 봐야한다.생성 단계에서 확보해둔 변수들의 메모리영역에 값 대입도 당연히 여기서 일어난다.예로 위 코드는 실행 단계에서 에 "number" 1이 할당된다. 생성단계에서는 메모리만 확보하여  였다면 실행단계에서는 비로서 a =1에 도달하며 원하는 값이 할당된다.추가로, 앞서 다룬 Execution Context의 원리는 JS의 클로저(Closure)와도 밀접하게 연결된다.아래 예시를 보자.위 코드가 실행되면 총 세 개의 Execution Context가 다음 순서로 Call Stack에 쌓이고 제거된다.1. Global Execution Context                                                                                               2. 의 Execution Context3. 의 Execution Context여기서 주목할 점이 있다.의 실행이 끝나고 Call Stack에서 제거된 이후에도, 은  안에 선언된 를 계속 참조할 수 있다.이는 이 생성시점의 부모 스코프에 대한 참조를, Execution Context 내부의 Lexical Environment를 통해 유지하고 있기 때문이다."Call Stack에서 이미 빠졌는데 왜 값이 살아 있는가?"라는 의문이 들 수 있다. 답은 간단하다.이것이 클로저가 동작하는 원리다. 강력하고 편리하지만, 때로는 직관적으로 이해하기 어려운 이유이기도 하다.+ 주의: 클로저는 불필요하게 큰 객체를 캡처하면 메모리 유지 비용이 생길 수도 있다.https://www.webdevlog.com/p/how-js-works-execution-contexthttps://blog.bitsrc.io/understanding-execution-context-and-execution-stack-in-javascript-1c9ea8642dd0

JavaScript를 쓴 지는 벌써 4년이 됐고, “제대로 이해하면서” 쓰기 시작한 건 1년 정도 된 것 같다. 그런데 막상 기본 동작 원리가 필요한 순간이 오면 Closure, Hoisting, Execution Context 같은 키워드가 반복해서 튀어나온다. 나는 그때그때 기능 구현에 급해서 “대충 훑고 넘어간” 경우가 많았다.하지만 React / Next.js 같은 프레임워크를 정확히 이해하려면, 결국 을 피할 수 없다. 그래서 이번 글에서는 가장 바닥에 있는 개념들(환경/엔진/파싱/JIT 흐름)을 한 번 정리해보려고 한다.JavaScript가 실행되는 “환경(Environment)”은 크게 두 가지로 나눌 수 있다.여기서 말하는 환경은 JavaScript가 에 대한 이야기다. 이 차이가 중요한 이유는, 환경에 따라 사용할 수 있는 가 달라지기 때문이다.여기서 헷갈리기 쉬운 포인트 하나:즉, “브라우저에서 돈다”가 “특정 엔진을 의미한다”는 뜻은 아니다. 브라우저마다 엔진이 다를 수 있고(Chrome/Edge, Safari, Firefox), Node/Deno도 각자 런타임이지만 내부적으로는 특정 엔진을 사용한다.엔진은 우리가 작성한 JavaScript 소스 코드를 읽고, 컴퓨터가 이해할 수 있는 형태로 변환해 실행한다. 소스 코드는 사람이 읽기 쉬운 텍스트일 뿐이고, CPU가 실행하려면 결국  수준으로 내려가야 한다.대표적인 JavaScript 엔진은 보통 아래가 자주 언급된다.추가로: 엔진은  을 실행하는 역할이고, 환경이 제공하는 Web API/Node API는 표준과 별개라서 브라우저/버전에 따라 차이가 날 수 있다.엔진은 먼저 코드를 읽고 문법적으로 유효한지 확인한다. 문법 오류가 있으면 이 단계에서 실행이 멈추고 에러가 발생한다.문법 검사가 끝나면 보통  를 만든다.AST는 JavaScript만의 개념이 아니라, 대부분의 언어 처리에서 등장하는 표준적인 중간 표현이다. “코드 구조를 트리로 만든 것”이라고 생각하면 된다.대부분의 현대 엔진은 AST를 바로 기계어로 바꾸기보다,  같은 중간 형태로 만들어 빠르게 실행을 시작한다.웹은 “일단 빨리 화면이 떠야” 하니까, 초기 응답 속도가 중요하다.실행을 하다 보면 어떤 코드가 “자주 반복 실행되는지(hot path)”가 보인다. 이 구간은 성능 최적화 가치가 크기 때문에, 엔진은 이런 부분을 골라 더 빠른 로 컴파일하고 최적화한다.조사를 하면서 든 의문은 "왜 Interpreter와 Compiler가 동시에 존재하는가?"였다.보통 C, C++, C#처럼 한 번에 모든 소스코드를 머신코드로 변환 후 사용하는 언어들은 오로지 Compiler만 존재했다.마찬가지로 Python 처럼 코드를 한줄 씩 읽고 즉시 결과를 출력하는 Interpreter 언어는 Compiler가 존재하지 않았다.사실 구시대 Javascript Engine들은 Inpterpreter로만 동작했기에 인터프리터 언어로 불렸다고 한다. 그러나 최근 대부분의 사용자가 사용하는 크롬 브라우저의 엔진 V8은 Interpreter와 Compiler가 결합된 JIT(Just In Time) 컴파러로 구현되어 있다고 한다.빠르게 실행 결과를 보여주어야 하는 웹의 특성 때문에 성능 개선이 필요했지만 Javascript는 Interpreter에 벗어나기엔 힘들었고, 이러한 환경에 느린 실행속도란 단점을 메우기 위해 Compiler와 결합한 JIT 컴파일 기술이 생겨났다고 한다.JIT 컴파일러는 이외에도 다양한 최적화 기법이 사용된 진보된 기술이라 하지만 이 이상 자세한 학습은 필요하지 않다 느껴 더이상 깊게 들어가보지 않았다.다음으로 이어서 Javascript의 Environment Context에 대해 정리해보려 합니다.https://www.webdevlog.com/p/how-js-engine-works-behind-the-scenes/https://www.freecodecamp.org/news/javascript-execution-context-and-hoisting/