[GL 2기] 멀티탭 데이터 공유, 코틀린 스코프 함수, 그리고 예상 못한 EC2 과금 (성장일지 4회차 큐레이션) 🌱

안녕하세요! 그로스로그 입니다!😊 🌱

탭 여러 개가 데이터를 나눠 쓰게 만들다 메모리 누수를 밟은 이야기, 코틀린 문법 정리, 그리고 배포하다 요금을 문 이야기. 2기 4회차입니다.

성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.

 

01

🔗 React에서 Shared Worker 사용하기

이종경 님

이종경 님 원문에 실린 이미지

이런 내용이에요
브라우저 탭을 여러 개 띄웠을 때, 탭들이 같은 데이터를 실시간으로 공유하게 만드는 방법을 다룹니다. Shared Worker라는 브라우저 기능을 React에 붙인 사례예요.
그런데 이 글의 백미는 성공담이 아니라 함정을 밟은 기록입니다. Shared Worker는 탭이 닫혀도 살아 있는 성질이 있어서, 탭에 대한 참조가 남으면 메모리 누수가 생깁니다.
이걸 WeakRef로 막는 과정이 담겨 있어요. 실제로 누수를 겪어본 사람만 쓸 수 있는 내용이라, 회고에 가까운 기술 글이 됐습니다.

같은 사이트를 탭 두 개로 열어두면 각 탭은 서로를 모릅니다. 한쪽에서 로그아웃해도 다른 쪽은 여전히 로그인 상태로 보이죠. 실시간 알림을 받는 서비스라면 탭 수만큼 웹소켓이 연결되고요.

Shared Worker는 이 문제를 다룹니다. 탭들이 함께 쓰는 백그라운드 스크립트를 하나 두는 방식이에요.

조금 더 들어가 보면

브라우저에는 Worker가 몇 종류 있습니다.

Web Worker는 탭 하나에 종속됩니다. 무거운 계산을 백그라운드로 넘겨 화면이 멈추지 않게 하는 용도예요. 탭이 닫히면 같이 사라집니다.

Shared Worker는 다릅니다. 같은 출처의 여러 탭이 하나의 Worker를 공유합니다. 탭 A가 만들고 탭 B가 접속하면 둘은 같은 인스턴스에 붙어요. 그래서 웹소켓 연결을 여기 하나만 두고 모든 탭이 그 결과를 받아볼 수 있습니다. 서버 부담도 줄고 탭 간 상태도 자연스럽게 맞춰지죠.

문제는 생명주기입니다.

Shared Worker는 마지막 탭이 닫힐 때까지 살아 있습니다. 그런데 "탭이 닫혔다"를 Worker가 정확히 알기가 생각보다 까다로워요. 각 탭은 MessagePort라는 통로로 Worker에 연결되는데, Worker가 그 포트 목록을 배열에 담아두고 있으면 탭이 닫혀도 그 참조가 남습니다.

그러면 어떻게 될까요. Worker는 이미 없어진 탭에게 계속 메시지를 보내려 하고, 가비지 컬렉터는 그 포트를 치울 수 없습니다. 참조가 살아 있으니까요. 탭을 열고 닫기를 반복할수록 죽은 포트가 쌓이고, 메모리가 야금야금 늘어납니다.

WeakRef가 여기서 나옵니다. 일반 참조는 "이거 내가 쓰고 있으니 치우지 마"라고 붙잡지만, 약한 참조(WeakRef)는 붙잡지 않습니다. 다른 곳에서 아무도 안 쓰면 가비지 컬렉터가 치워도 되고, 그러면 deref()가 undefined를 돌려줘요. Worker는 그걸 보고 "아, 이 탭은 없어졌구나" 하고 목록에서 뺄 수 있습니다.

이런 종류의 누수가 특히 성가신 이유는 개발 중에는 거의 안 보인다는 점입니다. 탭 두세 개 열고 테스트하면 아무 문제 없어요. 사용자가 하루 종일 탭을 열고 닫으며 쓰기 시작해야 드러납니다.

큐레이터 노트

함정을 실제로 밟은 흔적이 남아 있어서 뽑았습니다.

Shared Worker 사용법만 정리한 글이었다면 평범했을 겁니다. 그런데 이 글은 누수가 생기는 지점과 그걸 막는 방법까지 갔어요. WeakRef는 자바스크립트에서 자주 쓰이는 기능이 아닙니다. 이걸 꺼내 쓸 상황을 실제로 만났다는 게 이 글의 근거예요.

멀티탭 데이터 공유라는 주제 자체도 흥미로웠습니다. 대시보드나 실시간 협업 도구를 만든다면 반드시 마주치는 문제인데, 국내 자료가 많지 않은 영역이거든요.

원문 읽으러 가기  ↗velog.io/@jong-kyung/React%EC%97%90%EC%84%9C-Shared-Worker…

 

02

🧰 코틀린의 스코프 함수(scope functions)

오연수 님

오연수 님 원문에 실린 이미지

이런 내용이에요
코틀린의 let, run, with, apply, also 다섯 가지 스코프 함수를 정리한 글입니다.
이름도 비슷하고 하는 일도 비슷해 보여서, 코틀린을 처음 쓰면 "언제 뭘 써야 하지"에서 헷갈리는 대표적인 지점이에요.
글은 각각의 차이를 깔끔한 코드 예제와 함께 정리했습니다. 수업 과제가 아니라 개인적으로 언어를 공부한 기록이라는 점도 눈에 띄었어요.

코틀린을 쓰다 보면 반드시 만나는 다섯 함수입니다. 문법 자체는 어렵지 않은데, 구분이 헷갈립니다.

조금 더 들어가 보면

다섯 함수가 헷갈리는 이유는 두 개의 축이 섞여 있기 때문입니다.

첫 번째 축은 객체를 무엇으로 부르는가입니다. it으로 받는 것(let, also)과 this로 받는 것(run, with, apply)이 있어요. this는 생략할 수 있어서 코드가 짧아지고, it은 명시적이라 헷갈릴 일이 적습니다.

두 번째 축은 무엇을 돌려주는가입니다. 블록의 마지막 값을 돌려주는 것(let, run, with)과 객체 자신을 돌려주는 것(apply, also)이 있습니다. 이게 실제 쓰임을 가릅니다.

정리하면 이렇게 씁니다.

apply — 객체를 만들면서 설정할 때. 객체 자신을 돌려주니 그대로 변수에 담을 수 있어요. 빌더처럼 쓰입니다.

also — 객체는 그대로 두고 곁다리 작업을 할 때. 로그를 찍거나 검증하는 용도예요. it으로 받아서 "이 객체에 대해 부수적으로 이것도 한다"는 의도가 드러납니다.

let — null 처리에 가장 많이 쓰입니다. ?.let { } 형태로 쓰면 값이 null이 아닐 때만 블록이 실행돼요. 변환 결과를 돌려주니 체이닝에도 좋고요.

run — 객체 컨텍스트에서 여러 작업을 하고 결과를 받아올 때.

with — 확장 함수가 아니라 일반 함수라 with(obj) { } 형태로 씁니다. 한 객체에 여러 번 접근할 때 반복을 줄여줘요.

실무에서 중요한 건 문법을 외우는 게 아니라 의도를 드러내는 것입니다. apply를 봤을 때 "설정하는구나", also를 봤을 때 "부수 작업이구나"를 읽는 사람이 바로 알 수 있어야 해요. 그래서 팀에서는 아예 어떤 상황에 뭘 쓸지 컨벤션으로 정해두는 경우도 많습니다.

남용하면 오히려 읽기 어려워지는 것도 사실입니다. 스코프 함수를 여러 겹 중첩하면 it이 뭘 가리키는지 헷갈리기 시작하거든요.

큐레이터 노트

과제가 아니라 스스로 공부한 기록이라는 점이 좋았습니다.

성장일지에는 수강 중인 과목 정리가 자주 올라옵니다. 그것도 좋은 기록이에요. 그런데 누가 시키지 않았는데 파고든 것은 결이 다릅니다. 필요해서 찾아본 것이든 궁금해서 본 것이든, 스스로 정한 주제라는 게 드러나거든요.

코드 예제가 깔끔한 것도 뽑은 이유입니다. 스코프 함수처럼 비슷비슷한 걸 설명할 때는 예제가 곧 설명이에요. 말로 백 마디 하는 것보다 다섯 개를 나란히 놓은 코드 한 덩어리가 낫습니다.

원문 읽으러 가기  ↗devlemon.tistory.com/14

 

03

💸 스프링부트 프로젝트 EC2에 배포하기 (w. 과금)

이민경 님

이민경 님 원문에 실린 이미지

이런 내용이에요
스프링부트 프로젝트를 AWS EC2에 배포한 기록인데, 제목에 "과금"이 들어가 있습니다.
성공 과정만 정리한 배포 글과 달리, 중간에 만난 에러들과 예상하지 못한 요금까지 그대로 남겼어요.
처음 클라우드에 뭔가를 올리는 사람이 실제로 겪게 될 일들이 담겨 있어서, 안내서보다는 경고 자료에 가깝습니다.

1기 6회차에서 AWS 프리티어의 함정을 다룬 글을 소개해드렸는데, 이 글도 같은 계열입니다. 다만 이쪽은 직접 배포하다 요금을 문 기록이에요.

조금 더 들어가 보면

EC2에 스프링부트를 올릴 때 초보자가 요금을 맞는 경로가 몇 가지 정해져 있습니다.

인스턴스 타입을 잘못 고르기 — 프리티어는 t2.micro나 t3.micro만 무료입니다. 그런데 스프링부트는 메모리를 꽤 씁니다. JVM이 뜨고 스프링 컨텍스트가 로드되면 1GB로는 빠듯해요. 그래서 "느린데 좀 키울까" 하고 t3.small로 올리는 순간 과금이 시작됩니다.

메모리 부족으로 인한 우회 — t2.micro(1GB)에서 빌드하다 보면 메모리가 모자라 프로세스가 죽는 일이 흔합니다. 이때 스왑 메모리를 잡거나, 로컬에서 빌드해서 jar만 올리는 식으로 우회하는데, 이 과정을 모르면 인스턴스를 키우는 쪽으로 가게 되죠.

RDS를 프리티어 밖으로 만들기 — DB를 따로 두려고 RDS를 만들 때, 기본 선택값이 프리티어 범위를 벗어나는 경우가 있습니다. Multi-AZ 옵션이 켜져 있거나 스토리지 타입이 다르거나요.

끄지 않고 방치하기 — 가장 흔합니다. 테스트해보려고 만든 인스턴스, 실습하다 만든 RDS를 그대로 두면 조용히 요금이 쌓입니다. 탄력적 IP도 인스턴스를 끄면 오히려 과금된다는 걸 모르는 경우가 많고요.

그래서 클라우드를 처음 쓸 때 진짜 필요한 건 배포 방법이 아니라 비용을 감시하는 습관입니다. AWS Budgets에 1달러 알림을 걸어두고, 실습이 끝나면 만든 걸 지우는 체크리스트를 갖는 것. 이 글이 경고 자료로서 값진 이유입니다.

큐레이터 노트

성공만 쓰지 않았다는 점에서 뽑았습니다.

배포 글은 대개 다 끝난 뒤에 쓰입니다. 그래서 깔끔하고, 그래서 도움이 덜 돼요. 실제로 막혀 있는 사람이 궁금한 건 "정답 순서"가 아니라 "여기서 뭐가 잘못될 수 있는가"거든요.

이 글은 에러도 요금도 그대로 적었습니다. 제목에 "과금"을 넣은 것부터가 정직합니다. 검색해서 이 글을 만난 사람은 배포 방법과 함께 조심할 것을 같이 얻어가게 돼요.

이민경 님은 1기에도 배포 관련 글로 큐레이션되셨습니다(Vercel과 Heroku). 처음 배포하며 헤맨 기록을 계속 남기고 계신 셈인데, 그 연속성이 이 분 글의 특징입니다.

원문 읽으러 가기  ↗velog.io/@gaonlee/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%…

💡 세 편을 겹쳐 읽으며

세 글의 성격이 다릅니다. 하나는 브라우저 심화, 하나는 언어 문법 정리, 하나는 배포 시행착오예요.

그런데 첫 번째와 세 번째를 나란히 놓으면 닮은 데가 있습니다. 둘 다 "나중에 드러나는 비용"을 다룹니다.

Shared Worker의 메모리 누수는 개발 중엔 안 보입니다. 탭을 몇 번 열고 닫아서는 티가 안 나요. 사용자가 오래 쓰기 시작해야 드러납니다. AWS 요금도 마찬가지죠. 배포한 날은 아무 일도 없습니다. 한 달 뒤 청구서로 옵니다.

개발에는 이런 종류의 문제가 꽤 있습니다. 당장은 멀쩡한데 시간이 지나면서 쌓이는 것들이요. 메모리 누수, 클라우드 비용, 기술 부채, 로그 용량 같은 것들입니다.

즉시 드러나지 않는 비용을 미리 알아두는 것 — 두 글이 각자의 영역에서 그걸 기록했습니다.

이번 회차에서 가져갈 것

1. 오래 켜둬야 드러나는 문제가 있다. 메모리 누수 같은 건 짧은 테스트로는 안 잡힙니다. 장시간 사용을 가정한 확인이 따로 필요해요. 탭을 여러 번 열고 닫아보거나, 메모리 사용량을 시간 축으로 관찰해보는 식으로요.

2. 비슷한 기능은 "의도"로 구분하기. 코틀린 스코프 함수처럼 기능이 겹치는 것들은 무엇이 가능한가가 아니라 어떤 의도를 드러내는가로 골라야 합니다. 팀 컨벤션으로 정해두면 코드가 훨씬 잘 읽혀요.

3. 클라우드는 만든 것보다 지운 것을 기억하기. 실습으로 만든 인스턴스, 테스트용 DB, 방치된 탄력적 IP. 예산 알림을 걸어두고, 끝나면 지우는 체크리스트를 갖는 게 배포 방법을 아는 것만큼 중요합니다.

---

좋은 글 남겨주신 이종경 님, 오연수 님, 이민경 님께 감사드립니다! 😊

다음 큐레이션으로 다시 찾아오겠습니다! 🌱

- 에디터 · 성장일지 큐레이터 -

---

※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.