jyeongpark

제48회 데이터 분석 준전문가 합격 후기 자격증을 따게 된 이유서비스 기획이나 사용자 행동 데이터를 이해하는 일이 점점 중요해지고 있는 현재데이터 분석의 기본 개념을 정리하고 싶어 ADsP 자격증을 준비하게 되었다.ADsP 시험 구성시험은 총 90분 동안 진행되며, 과목별 문제 구성은 다음과 같다.1과목 데이터 이해 : 10문제2과목 데이터 분석 기획 : 10문제3과목 데이터 분석 : 30문제 총 50문제가 출제되며, 각 문제는 2점씩 배점된다.따라서 총점 100점 중 60점 이상이면 합격이다. 다만 한 가지 주의할 점이 있는데, 과목별 과락 기준이 있다.각 과목에서 정답률이 40% 이하일 경우 과락으로 불합격 처리된다. 예를 들어 총점이 60점을 넘더라도 특정 과목에서 너무 낮은 점수를 받으면 합격할 ..

보호되어 있는 글입니다.

Variant, Text, Boolean, Instance Swap을 활용한 Todo 컴포넌트Todo 리스트는 단순해 보이지만 상태, 데이터, 반복 사용을 모두 고려해야 하는 컴포넌트다.이번 글에서는 Figma에서 Todo 컴포넌트를 만들면서 Variant, Text, Boolean Variable, Instance Swap을 어떻게 함께 사용했는지, 그리고 이 방식이 왜 컴포넌트 관리에 유리한지 정리해보려고 한다. Todo 컴포넌트 목표이 Todo 컴포넌트는 다음 조건을 만족하도록 설계했다.완료 여부에 따라 시각적 상태가 바뀐다텍스트 내용은 인스턴스마다 달라질 수 있다체크 아이콘은 상태에 따라 교체된다컴포넌트 하나로 모든 Todo 상태를 표현한다즉, 하나의 컴포넌트로 여러 상태를 안정적으로 관리하는 것..

이전 글에서는 Figma의 Style과 Variable을 컬러 중심으로 비교했다. 컬러를 구조적으로 관리해보니, Variable은 단순히 색상을 위한 기능이 아니라 디자인에서 값이 되는 모든 것을 다루기 위한 시스템이라는 생각이 들었다. 그 이후 자연스럽게 이런 질문이 따라왔다. 그렇다면 컬러를 제외한 다른 값들은 어떻게 관리하는 게 맞을까? Typography, Spacing, 상태 값 같은 것들도 Style과 Variable로 나눌 수 있을까?이번 글에서는 컬러를 제외한 영역에서 Style과 Variable이 각각 어떤 역할을 하는지, 그리고 왜 이런 차이가 생겼는지를 정리해본다.Style은 어디까지 담당할 수 있을까Style은 여전히 강력한 도구다. 특히 시각적인 결과물이 중요한 영역에서는 Styl..

프론트엔드 개발자로서 개인 프로젝트를 만들기로 했을 때 머릿속에 있는 화면과 흐름을 정리해 표현할 도구가 필요했다. 회사에서 사용하던 디자인 툴이 있었고 자연스럽게 Figma를 선택했다. 다만 회사에서의 Figma 사용 경험은 제한적이었다. 직접 디자인을 설계하기보다는 이미 그려져 있는 화면을 기준으로 컴포넌트를 구현하고 스타일을 맞추는, 이른바 퍼블리싱에 가까운 작업이 대부분이었다. 개인 프로젝트에서는 상황이 달랐다. 디자인 시안이 따로 없었고 구조부터 스타일 결정까지 스스로 내려야 했다. 그래서 Figma의 사용법 자체를 제대로 이해하고 싶어졌고, 그 과정에서 가장 먼저 들었던 질문이 바로 Style과 Variable의 차이였다. 둘 다 Color를 설정할 수 있는데 왜 두 가지 기능이 존재하는지 이..

Next.js App Router(15) 환경에서 페이지 이동 시 useEffect의 cleanup(return) 함수가 실행되지 않는 문제를 겪었다.특히 로컬 개발(dev)에서는 정상 실행되지만, 배포(production)에서는 cleanup이 전혀 동작하지 않았다.이 글은 이 문제를 분석하고 원인을 정확히 파악한 기록이다. 디렉토리 구조문제가 발생한 상황의 디렉토리 구조는 다음과 같다.src/ app/ (afterLogin)/ layout.tsx main/ users/ all/ page.tsx reservation/ all/ page.tsx문제 상황사용자 목록 페이지(/main/u..

2025.09.15 - [개발/백엔드 공부하기] - 프론트엔드 개발자가 백엔드를 공부하는 이유 앞선 글에서, 프론트엔드 개발자인 내가 서버와 백엔드 영역에 관심을 갖게 된 계기를 정리했다. 그렇다면 서버 공부의 시작점으로 왜 하필 JPA를 선택했을까? 프론트엔드에서 데이터를 다루다 보면, 가장 가까운 접점은 API다. 하지만 API가 나오기까지의 과정은 사실 데이터베이스와 매우 밀접하다. 서버 개발자는 단순히 데이터를 주는 것이 아니라, 데이터베이스와 객체를 매핑하고, 그 데이터를 어떻게 효율적으로 관리할지 고민한다. 이때 등장하는 게 바로 JPA다. JPA는 자바 진영에서 가장 널리 쓰이는 ORM(Object-Relational Mapping) 기술로, 데이터베이스와 객체를 연결해주는 역할을 한다. 즉..

프론트엔드 개발자로 일을 하면서도, 가끔은 “백엔드 개발자가 다루는 영역은 어떤 느낌일까?” 하는 궁금증이 생기곤 했다. 사실 학부생 시절에 백엔드를 잠깐 경험해 본 적은 있다. 하지만 화면을 수정하면 바로 결과가 보이고, 빠른 피드백 속에서 개선점을 확인할 수 있는 프론트엔드 쪽이 훨씬 매력적으로 다가왔다. 그래서 자연스럽게 프론트엔드 개발자의 길을 걷게 되었다. 그런데 개발은 혼자 하는 일이 아니고, 협업은 필수불가결했다. 협업을 거듭하다 보니, 프론트엔드가 데이터를 화면에 그려내는 일을 한다면 그 데이터는 분명 서버 개발자가 다듬어서 오는 것일 텐데… "어떤 기준으로 데이터를 정리하고 전달하는 걸까?" 하는 생각이 들기 시작했다. 단순히 API를 받아 사용하는 입장을 넘어, 그 뒷단의 로직과 구조가..