기술 스택은 우리가 개발을 배울 때와 프로젝트를 시작할 때 항상 처음 정하는 것이라 너무 익숙하지만, 그만큼 기술 스택이라는 것 그 자체에 대해서는 깊게 생각하지 않는 것 같습니다. 그래서 이 글을 통해 기술 스택에 관한 제 생각을 한번 설명해 보는 시간을 가져보려고 합니다. 앞선 ‘2024 프론트엔드 기술 스택 트렌드 이야기 (1)’에서는 기술 스택 트렌드가 어떻게 만들어지는지, 캐즘과 하이프 사이클, 2024 프론트엔드 트렌드를 살펴봤습니다. 2부에서는 어떤 기술 스택을 배워야 하는지, 기술 스택을 선택하는 방법, 알아두면 좋은 2024 프론트엔드 기술 스택과 범주 등을 살펴보겠습니다.

오늘 해볼 이야기는 ‘2024년 프론트엔드 기술 스택’입니다. 기술 스택은 우리가 개발을 배울 때와 프로젝트를 시작할 때 항상 처음 정하는 것이라 너무 익숙하지만, 그만큼 기술 스택이라는 것 그 자체에 대해서는 깊게 생각하지 않는 것 같습니다. 그래서 이 글을 통해 기술 스택에 관한 제 생각을 한번 설명해 보는 시간을 가져보려고 합니다. 꽤 긴 내용이 될 것 같아 1, 2부로 나눴고, 이번 1부에서는 기술 스택이란 무엇이고 어떻게 트렌드가 만들어지는지, 캐즘과 하이프 사이클, 2024 프론트엔드 트렌드에 대해 살펴보겠습니다.

이번 글은 개발 실력을 늘리기 위한 방법과 컴퓨터적으로 사고하는 법에 대한 개인적인 고찰에 관한 글입니다. 운동이라 생각하고 꾸준히 훈련하기, 요구사항을 데이터 관점으로 사고하기라는 핵심 철학을 바탕으로 어떻게 하면 개발 실력을 효과적으로 키우고, 컴퓨터적으로 생각하게 할 수 있을지에 대해 얘기하려고 합니다. 이 글이 개발 실력을 늘리고 나에게 맞는 공부법을 찾는 데 도움이 되기를 바랍니다.

RxJS를 배우고 있거나 처음인 분들을 위해 어려운 개념들에 대해 조금 더 이해를 높일 수 있는 중요한 내용들을 한번 적어보았습니다. RxJS의 강의나 교과서적인 내용보다는 개인적으로 RxJS를 이해하고 나서 알게 된 인사이트를 바탕으로 재해석한 글입니다. 지금 RxJS를 공부 중인 개발자에게 조금 더 와닿을 것 같으며, 아예 모르는 분들은 그냥 흥미로 읽어도 괜찮습니다.

처음에는 그냥 기능 구현을 하면 되지만 프로젝트의 크기가 커지다 보면 ‘제대로 정리해두지 않으면 정말 안 될 것 같은 순간’들을 맞이하게 됩니다. 그냥 만들면 쉬운 요구사항도 기존 코드에 확장하는 것이 쉽지 않고, 점점 디버깅도 힘들어지는 걸 느낍니다. 이러한 문제에 부딪힌 많은 프론트엔드 개발자가 기존 구조에서 조금씩 더 나은 아키텍처와 프레임워크 형태, 그리고 라이브러리리를 제안했습니다. 덕분에 짧은 시간 안에 새로운 아키텍처들과 방법들이 꾸준히 탄생했습니다.

이번 글은 ‘비트(Vite)’에 관한 내용입니다. 최근 ‘스벨트(Svelte)’와 관련한 사내 발표 내용 중 다들 재미있어했던 Vite에 관한 이야기를 블로그 형식으로 각색하여 다시 정리해보았습니다. 특히 이번 글은 Vite에 대한 전문적인 내용을 다루기 보다는 조금 더 가볍게 준비해보았습니다. 그렇지만 중요한 핵심과 흐름을 담았기 때문에 Vite가 궁금하다면 이 글이 정말 간략하게나마 이해하는 데 도움이 될 것입니다.

오늘 해볼 이야기는 ‘어떻게 하면 조금 더 효율적으로 다 같이 개발을 설계하고 진행할 수 있을지’에 대한 이야기입니다. 아이디어를 구체화하고 기획 구현을 시작하면 이제 ‘이걸 어떻게 태스크로 나눠서 분배해야 하는지’, ‘진행도는 어떻게 체크해야 하는지’, ‘다른 사람들은 어디까지 했는지’ 등 프로젝트 파악이 필요합니다. 태스크 및 일정 관리에 정답은 없겠지만, 직접 스프린트를 진행하면서 긍정적인 효과를 보았던 BDD(Behavior Driven Development)와 SDD(Schema Driven Development)를 바탕으로 프로젝트 설계 및 일정 관리에 대해 한 번 이야기해보겠습니다.

좋은 폴더 구조에 관한 이야기는 개발자들 간의 끊임없는 떡밥입니다. 정답이 있지 않고 프로젝트의 특징이나 크기, 주관적인 해석에 따라 정말 여러 가지 방법들이 존재하기 때문입니다. 마치 ‘좋은 코드란 무엇일까?’와 같은 급의 질문이 아닐까 생각이 듭니다. 이번 글에서는 좋은 폴더 구조 이야기 중 먼저 컴포넌트에 한정해서 한번 이야기해보려고 합니다. 컴포넌트를 정리하거나 아키텍처 혹은 디자인 시스템을 검색하다 보면 한번쯤은 만나게 되는 바로 Atomic Design Pattern에 대한 이야기입니다.

함수형 프로그래밍을 배우면서 깨달은 것이 있습니다. 실제 함수형 프로그래밍의 본질은 그렇게 어려운 것이 아닌데 이걸 설명하기 위해서는 대단히 어려운 일이 많았습니다. 아마 함수형 프로그래밍에 쓰이는 용어들이 대부분 낯설기 때문일지도 모릅니다. 최근 함수형 프로그램을 더 깊이 공부하다가 실제로 알려주고 싶었던 것이 방법이나 용어가 아닌, 코드를 함수형으로 생각하는 ‘함수형 사고 패러다임’이라는 걸 깨달았습니다. 그래서 오늘은 함수형 사고 패러다임을 바탕으로 새롭게 함수형 프로그래밍에 관한 글을 써보려고 합니다.

이번 글은 일하는 방식에 대한 이야기입니다. 소프트웨어 사업은 거대하기에 혼자서 다 할 수 있는 것이 아니기에 언젠가는 함께 일해야만 합니다. 애자일과 구글 스프린트를 접하면서 그동안 겪었던 경험을 바탕으로 협업 방식을 바꾸기 위한 시도를 많이 했었습니다. 일부는 성과가 있었고 일부는 맞지 않는 방법들도 있었습니다. 오늘은 제가 경험한 Best Practice를 찾아가는 이야기를 통해 어떻게 협업을 하면 좋은지에 대한 주관적인 의견을 설명하고자 합니다.