개발 블로그

(1) 자료 구조란?

코딩 테스트를 준비하기 전에 자료구조부터 제대로 정리하고 싶어 자료구조 부터 알고리즘 까지 공부하는 과정을 블로그에 기록하기로 했다! 그냥 외우는 것이 아니라 왜 이런 구조가 존재하는지, 언제 써야 하는지, 직접 코드로 구현하면서 공부하기로 결심했다. 그래서 미래에 나를 위한 레퍼런스이니까 한번 잘 정리해보려고 한다. 자료구조란 무엇인가?위키백과 정의를 보면 이렇게 나온다. 자료구조는 효율적인 접근 및 수정을 가능케 하는 자료의 조직, 관리, 저장을 의미한다. 더 정확히는, 데이터 값의 모임, 데이터 간의 관계, 그리고 데이터에 적용할 수 있는 함수나 명령을 뜻한다.쉽게 말하면 이렇다. 데이터를 어떤 모양으로, 어떤 규칙으로 담느냐가 자료구조이다.프론트엔드 개발을 하면서 이미 자료구조를 쭉 써왔다. 눈치..

알고리즘 관련 공부를 진행하기 전에 왜 알고리즘 공부를 해야하는지에 대해서 짚고 넘어가면 좋을 것 같아 블로그 글을 작성하게 되었다. 예를 들어 같은 문제를 푸는 두 개의 프로그램이 있다고 가정해보았을때 하나는 1초만에 결과를 내고, 다른 하나는 10분이 걸린다고 해보자, 둘다 정답을 도출하지만 실문에서는 전혀 다른 평가를 받을 것이다. 이 차이를 만들어 내는 것이 바로 알고리즘의 효율성이다.효율적인 알고리즘은 더 적은 컴퓨팅 자원을 사용하면서 빠르게 결과를 도출할 수 있고, 이는 곧 서버 비용 절감과 사용자 경험 향상으로 이어질 수 있다.특히 대규모 데이터를 처리하는 환경에서는 이 차이로 인해 결과가 극적으로 벌어질 수 있을 것이다.데이터 1000건을 처리할 때 0.01초 차이였던 것이, 1000만 건..

2024년 12월, 이직에 성공했다.새로운 환경에서의 시작은 기대만큼 설렜고, 2025년은 꽤 즐거운 해였다.그토록 원했던 팀원들, 성장 가능성 충만한 업무 분위기, 드디어 원하던 업무들..! 일이 재미있었고, 배우는 것도 많았다.1년이라는 시간이 짧다면 짧지만, 나에게는 분명 성장의 시간이었다.그리고 2025년 12월, 회사 사정으로 권고사직을 받았다.2026년 2월까지 근무를 마치며 그 시간을 정리하게 되었다. 2025년 돌아보기확실히 이전 회사와는 분명히 달랐다. 프론트엔드 개발자가 나 혼자라는 사실은 변함 없지만 하나의 서비스를 나혼자 책임지는 것이 아니라 기획자,디자이너,백엔드 개발자,AI 엔지니어 등 다양한 직군의 사람들과같이 프로덕트를 개발하고 운영하는 경험을 할 수 있었다. 25년 한 해동..

프론트엔드 개발자 면접을 가면 React 와 Vue 를 비교해보라는 질문을 굉장히 많이 받는다.그럴 때마다 개인적인 경험을 이야기하면서 비교하곤 했는데 기술적으로 잘 대답하고 싶다는 생각이 들었다. 그래서 React 와 Vue를 모두 경험해본 입장으로써 한번 이 둘을 비교하는 글을 기록해보면 좋을 것 같다는 생각이 들었다. 내가 생각할때는 React와 Vue를 비교할 때 가장 중요한 것은 성능도, 문법도, 커뮤니티도 아닌 것 같다.바로 라이브러리 vs 프레임워크라는 근본적인 철학의 차이이다. 이 차이가 모든 것을 결정한다고 생각한다. 실제로 두가지를 활용해 프로젝트를 개발해보면서 React는 자유도가 높아 팀 내부에서 어떤 라이브러리를 선택할지에 대해서 꽤나 리소스를 많이 소모했어야 했다.하지만 우리 팀..

상태관리는 현대 프론트엔드 개발에서 가장 중요한 개념 중 하나라고 생각한다.특히 React와 Vue를 사용할 때 "단방향"과 "양방향" 상태관리의 차이를 이해하는 것은 필수이기 때문에 해당 개념에 대해 공부하고 정리한 내용을 기록해보려고 한다. 상태관리란?먼저 "상태(State)"가 뭔지 정의해보자 상태 = 애플리케이션이 가지고 있는 모든 데이터 예: - 로그인한 사용자 정보 - 장바구니의 상품들 - 좋아요 수 - 다크모드 ON/OFF 상태관리는 이 데이터들이 어떻게 변경되고, 어떤 경로를 통해 변경되며, 어떻게 컴포넌트들에게 공유되는지를 관리하는 것이다.여기서 중요한것은 이 상태관리를 어떻게 할 것이냐 이다. 단방향 vs 양방향: 개념부터 이해하기상태관리는 크게 두 가지 철학으로 나뉜다. 이것을 먼저 ..

UI 아키텍처를 설계할 때 가장 흔히 마주치는 두 가지 패턴, MVC와 MVVM.이 둘은 비슷해 보이지만 근본적으로 다른 철학을 가지고 있습니다.핵심 비교항목MVCMVVM중간 역할ControllerViewModel주요 기능View와 Model을 직접 조율View와 Model을 연결/변환데이터 흐름단방향 (Controller 중심)양방향 (Data Binding)View-Model 관계의존성 높음의존성 낮음적합한 규모소·중규모 프로젝트대규모, 복잡한 UI테스트 난이도중간~높음낮음MVC 패턴구조와 역할MVC는 Model-View-Controller 세 가지 계층으로 구성됩니다.Model: 데이터와 비즈니스 로직 담당프론트엔드에선 상태 저장, API 응답 데이터 관리를 담당함.View: 사용자에게 보이는 UI..

최근에 사이드 프로젝트를 개발하려고 하는 순간..!몇달 되지도 않았지만 쌓여있는 레거시 코드들을 보면서 뭐가 이렇게 급해서 모든 기능들이 한 파일안에 전부 들어가 있는지..가독성도 떨어지고 기능 하나 수정하려고 스크롤을 위 아래로 왔다 갔다 하다가 깨달았다.이거 분리해야겠다고..그래서 한 파일에 몰려있던 UI, 로직, API 호출을 쪼개고, Custom Hook으로 분리하고, 유틸 함수로 빼냈다.나름 뿌듯했다.그런데 피드백을 받고 깨달았다.나는 "관심사 분리"를 너무 좁게 생각하고 있었다.내가 한 건 "함수 단위 분리"였다. 사이드 이펙트 줄이기, 재사용성 높이기, 코드 정리하기. 틀린 건 아니지만, 관심사 분리의 일부분일 뿐이었다.알고 보니 관심사 분리는 어떤 관점에서 바라보느냐에 따라 완전히 다른 이..

디자이너 없이 개발을 하려고할때 주로 UI 라이브러리를 써볼까? 하는 생각이 든다.그래서 이런 저런 UI 라이브러리를 사용하다보면 항상 부딪히는 문제가 있다.프로젝트에 맞게 스타일을 바꾸려고 하면 생각보다 손이 많이 간다는 것이다ㅠㅠ그런데 최근에 Headless UI를 알게 됐는데, 꽤 괜찮아서 공부해본것들을 정리해보려고 한다.https://headlessui.com/ Headless UICompletely unstyled, fully accessible UI components, designed to integrate beautifully with Tailwind CSS.headlessui.com우선 Headless UI 공식 홈페이지를 가면 아래와 같이 설명하고 있다."Completely unstyl..

사이드 프로젝트를 시작할 때마다 늘 똑같았다."일단 만들면서 생각하자"로 시작해서, 중간에 뭔가 꼬이고, 결국 처음부터 다시 짜는 패턴이었는데,이번엔 다르게 해보고 싶었다. 이미 기존에 유저 인증 관련 기능들은 개발을 해서 게시글 CRUD 기능을 개발 하기 전에 제대로 설계하고 시작하면 어떨까 싶어서 개발 명세서를 먼저 써봤다. 우선 프로젝트 개요, 기술 스택, 기능 요구사항 이렇게 크게 세 파트로 나눠서 작성했다.프로젝트 개요는 간단하게 프로젝트명이랑 버전, 설명 정도만 정리했고,기술 스택은 프론트엔드, 백엔드, 인증, 클라우드까지 어떤 기술을 왜 선택했는지 작성했다.기능 요구사항은 게시글 작성, 목록 조회, 상세 조회, 수정, 삭제 각각에 대해 상세 요구사항, 예외 케이스, 테스트 시나리오를 정리했다..

예전에 같이 개발을 공부하던 팀원들과 프로젝트를 만들때 속도감 있게 개발하자! 가 중요한 우선순위여서 나는 전통적으로 CSS 파일을 관리하기 보다 Tailwind CSS를 선택해서 프론트 개발을 했었다.그때의 나는 단지 Tailwind 가 쉽게 UI 개발을 도와주는 프레임워크라고 생각해 선택해서 사용했던 것 같다.그런데 프로젝트의 규모가 커지면서 기능들이 많아지고 구현해야할 UI 가 늘어나면서 점점 클래스가 길어지기 시작했다..결국 단순한 UI 하나를 수정하려면 긴~ 클래스 하나하나 살펴보면서 수정해야했다. 그러면서 Tailwind에 대한 나의 결론은 " 온보딩 하기에는 쉬우나 규모가 큰 프로젝트에는 못쓰겠구만! " 이였다.그런데 이번에 개인적으로 사이드 프로젝트를 개발하면서 역시나 같은 마인드로 .. ..