글
디자인 토큰 & Variables 운영 전략 — Figma부터 코드 매핑까지 완전 가이드
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
디자이너는 "버튼 색 바꿨어요"라고 했는데 왜 화면에는 열다섯 군데가 다 다른가요? 디자인 토큰이 뭔지, Figma Variables로 어떻게 세팅하고, CSS Custom Properties와 Theme 객체로 코드에 매핑하는지, 그리고 실무에서 동기화가 깨지는 순간을 어떻게 막는지까지 — 이 글 하나로 다 정리해 드릴게요! 디자이너와 개발자 사이에 이런 대화, 다들 한 번쯤 겪어보셨을 거예요. "Primary 색상 조금 바꿨어요~" 한 마디에 개발자가 파일 열다섯 개를 열어서 색 코드를 하나씩 찾아 바꾸는 상황. 혹은 반대로, 개발자가 이미 코드에서 색을 바꿨는데 Figma 파일은 아직 옛날 색인 상황. 😅 이게 한두 번이면 모르겠는데, 프로젝트가 커질수록 이 문제는 기하급수적으로 커져요. 디자인 토큰은 바로 이 문제를 해결하기 위해 나온 개념이에요. "색, 간격, 폰트 크기 같은 디자인 결정 사항을 하나의 이름 붙인 변수로 관리하자"는 아이디어인데요, 말은 쉽지만 실제로 Figma Variables와 코드를 동기화해서 운영하는 건 생각보다 손이 많이 가요. 오늘은 그 전체 흐름을 처음부터 끝까지 정리해 드릴게요! 디자인 토큰이란 무엇인가요? 🔤 디자인 토큰(Design Token)은 UI를 구성하는 시각적 속성값을 이름 붙인 변수로 추상화한 것 이에요. 색상, 타이포그래피, 간격, 그림자, 모션 등 디자인 시스템에서 반복적으로 사용되는 값들이 모두 토큰의 대상이 될 수 있어요. 예를 들어 버튼의 배경색을 #6a1b9a 라는 HEX 값으로 직접 쓰는 대신, color.primary.500 이라는 토큰 이름으로 참조하는 거예요. 나중에 브랜드 색상이 바뀌어도 토큰 값 하나만 수정하면 그 토큰을 참조하는 모든 컴포넌트가 한꺼번에 업데이트되죠. 토큰의 3단계 계층 구조 실무에서 많이 쓰는 3-tier 구조를 알아두면...
Figma Auto Layout 안 쓰면 생기는 참사들 – 개발자가 울고 가는 디자인 파일의 비밀
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
Figma에서 디자인은 예쁘게 뽑았는데, 개발자가 받으면 왜 멘붕이 올까요? Auto Layout 없이 고정 좌표로 찍어놓은 디자인이 개발 단계에서 어떤 참사를 일으키는지, 그리고 CSS Flexbox/Grid와 어떻게 대응되는지 Before/After 예시로 낱낱이 풀어봤어요. 솔직히 고백할게요. 저도 예전에 Figma에서 Auto Layout 없이 디자인한 적이 꽤 있었어요. 프레임 안에 요소를 드래그해서 눈대중으로 배치하고, 간격은 화살표 키로 1px씩 맞추고… 화면에서 보기엔 완벽했거든요. 😅 그런데 그 파일을 넘겨받은 개발자분이 조용히 슬랙으로 보내온 메시지가 아직도 생생해요. "이거… 간격이 위에서는 12px인데 아래에서는 13px이고, 이 버튼은 텍스트가 길어지면 어떻게 되는 건가요?" 그때부터 Auto Layout을 제대로 공부하기 시작했어요. 고정 좌표 배치 vs Auto Layout, 뭐가 다른 건가요? 🤔 가장 근본적인 차이부터 짚어볼게요. Figma에서 요소를 배치하는 방식은 크게 두 가지예요. 구분 고정 좌표 배치 Auto Layout 배치 방식 X, Y 좌표로 절대 위치 지정 방향·간격·패딩 규칙으로 자동 배치 내용 변경 시 다른 요소 수동으로 재배치 필요 자동으로 리플로우 반응형 대응 ...
AWS RDS 커넥션 부족? max_connections 계산부터 HikariCP·PgBouncer 설정까지
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
AWS RDS에서 갑자기 'Too many connections' 에러가 뜬다면? PostgreSQL과 MySQL 환경에서 커넥션 풀이 필요한 이유, max_connections 계산법, 그리고 PgBouncer·HikariCP 등 실전 튜닝 방법까지 한 번에 정리했어요. 새벽에 슬랙 알림이 울려서 확인해보니 RDS 대시보드에 "Too many connections" 에러가 빼곡하게 찍혀 있었어요. 트래픽이 갑자기 몰린 것도 아닌데 왜 커넥션이 가득 찼는지, 그때는 정말 감이 안 잡히더라고요. 😓 알고 보니 문제는 DB 자체가 아니라 애플리케이션 쪽 커넥션 풀 설정에 있었어요. 이 경험 이후로 커넥션 풀 튜닝의 중요성을 뼈저리게 느꼈는데요, 오늘은 그때 배운 것들을 정리해서 공유해볼게요! 'Too many connections' 에러, 왜 발생하나요? 🤔 이 에러는 말 그대로 DB 서버가 허용하는 최대 동시 연결 수를 초과했을 때 발생해요. RDS에서 이 한도는 max_connections 파라미터로 결정되는데, 인스턴스 클래스(메모리 크기)에 따라 기본값이 달라요. 근데 진짜 문제는, max_connections 자체보다 커넥션을 낭비하는 구조 인 경우가 훨씬 많아요. 흔한 원인들을 보면요: 커넥션 풀 없이 매 요청마다 새 연결을 맺고 끊는 경우 커넥션 풀 사이즈를 서버 인스턴스 수만큼 곱해서 생각하지 않은 경우 슬로우 쿼리가 커넥션을 오래 점유하면서 풀이 고갈되는 경우 커넥션 누수(leak) — 사용 후 반환하지 않는 코드 버그 💡 알아두세요! 커넥션 풀(Connection Pool)은 미리 일정 수의 DB 연결을 만들어두고 재사용하는 기술이에요. 매번 연결을 새로 맺는 비용...