민규의_개발일지

[FE] FE 폴더구조 - 프랙탈 폴더구조 (FSD와 유사한?)

정_민_규 — Sun, 17 Aug 2025 19:49:58 +0900

최근 회사에서 실제로 적용하고 있는 폴더구조에 대해서 이야기를 해보고자 한다 ㅎㅎ.

FSD폴더구조와 유사한점이 많지만 자유도 측면에서 장점이 많은 프랙탈 폴더구조를 우리팀에선 채택하고 있다.

사실 프랙탈 폴더구조란 말은 없긴하다. FSD에서 영감을 받아서 커스터마이징한 폴더구조인데, 구조가 프랙탈처럼 같은 형태가 계속 반복되는 폴더구조라 네이밍을 붙이게 되었다.

좋은 폴더구조 ?

좋은 폴더구조는 뭘까?

좋은 폴더구조는 아래 항목중에 어떤게 잘 되어야 할까?

1. 내가 봐야할 부분을 바로 찾을 수 있는 구조

2. 공통화된 파일들을 추적하기 좋은 구조

3. 파일의 영향범위를 파악하기 쉬운구조

등등이 있을 것이다. 무엇보다 1번이 가장 중요한 것 같다라고 최근 생각한다. 기능을 추가하던, 고치던 내가 해당 레포의 어느 파일을 건드려야 할지 안다는 것은 매우 중요하다.

폴더엔 뭐가 들어가지?

그렇다면 FE개발을 할 때 우리가 정리해야할 파일들은 어떤것이 있는지 파악하는것도 중요하다. 일단 생각나는 것만 정리해보면,

(리액트 개발 기준)

- 컴포넌트 파일

- 레이아웃을 담당하는 페이지 파일

- 스타일

- 타입

- 상수

- 설정

- hook

- api연결 등 비즈니스 로직

- 유틸

- 등등...

생각나는대로만 적었는데도 정말 많다. 그렇다고 이 기준을 근거로 폴더구조를 잡으면 망하게 된다.

쉽게 생각해서 다이소를 생각해보자.

각 물건들의 재질을 나무, 플라스틱, 스티로품, 알루미늄 등등으로 나누어서 그 재료를 기준으로 물건을 진열한 것과 같다.

다이소..?

다이소? 그러면 다이소는 보통 어떻게 물건을 진열하는지에 대해 생각해볼 필요가 있다. 다이소는 우리가 어떤 물건을 찾기에 최적화된 진열배치를 가지고 있다.

다이소는 물건의 재질이나 특징으로 물건들을 모아두지 않는다.

예를 들어 의자를 생각해보자. 다이소는 의자를 한곳에 모아두지 않는다. 욕실용 의자는 욕실코너, 캠핑용 의자는 캠핑코너에 진열한다.

언뜻 의자를 구매하는 사람한테는 불편해 보일수도 있지만, 실제 구매자는 의자를 사는 경우 사용처가 확실하기 때문에 물건을 찾는데 헤매지 안흔ㄴ다.

다이소는 물건의 재질이 아닌, "용도"에 맞춰서 진열을 한다. 욕실용품, 주방용품, 캠핑 등등의 사용처를 기준으로 둔다.

조금 큰 규모의 다이소가 있어서 캠핑용품 코너가 매우크다고 생각해보자.

이 경우 캠핑용품 안에서도 용도를 나눌 수 있다.

삼겹살 굽기와 관련된 코너 (숯, 쌈장, 고기판 등), 수면을 위한 코너 (침낭, 담요 등)

이 세부 용도를 나눌 수 있고 사실 이 안에서도 더 나눌수도 있다.

FSD

FSD 파일구조는 위 다이소에서 소개한 진열방식을 FE 폴더구조에 잘 녹인 방식이라고 생각한다.

7개의 "용도"를 분리하고, 그 용도에 따라서 파일들을 차곡차곡 정리한다. 그 안에서 또다시 용도를 분리할만하게 큰 범위가 되면, 7개의 용도를 또다시 분리할 수 있다.

즉 마치 수학의 프랙탈처럼 같은 폴더이름이 계속 반복되게 된다.

이 경우의 폴더구조가 가지는 가장 강력한 장점은 "파일의 영향범위를 항상 알 수 있다"란 점이다.

해당 파일구조에서 특정 파일이 있다면 그 파일은 자신의 형제와 자식 파일에만 영향을 끼친다. 이는 프로젝트의 유지보수에서 매우 중요하다.

프랙탈 구조?

FSD의 아이디어는 정말 좋다고 생각한다. 근데 필자는 개인적으로 조금 치명적인 단점이 존재한다고 생각한다.

1. 폴더구조에 대해 공부해야함

2. 가끔 어떤 폴더에 넣어야할지 헷갈림

1번에서 말하는 공부는, 다이소를 예시로한 계층형식의 파일구조 개념이 아닌, 말 그대로 폴더이름자체에 공부를 해야한다는 점이다.

어떤 상황에 pages, ui, features 등을 넣어야 하는지 공부하고 해석하는 과정이 필요하다.

또, 프로젝트에 따라서는 7개의 폴더가 모두 필요 없을 수도 있다.

그래서 우리팀에서는 해당 구조의 장점을 골라낸 파일구조를 채택하고 있다.

먼저, 7개의 용도가 아닌 프로젝트에 필요하다고 생각하는 용도에 맞게 이를 분리한다.

assets : 정적 리소스
pages : 페이지 단위 컴포넌트
components : 컴포넌트
hooks : 커스텀 훅
services : 서버 통신, 비즈니스 로직 처리
styled : 스타일
utils : 유틸 함수
types : 타입 정의

만약에 작업이 필요한 경우, 우리팀에서는 pages를 기준으로 이를 잡았다. (필요시엔 도메인을 기준으로 해도 좋을 듯 하다)

만약 user-info 페이지를 만든다면, 그 페이지를 만드는 UserInfo.tsx 파일을 만든다. (index.tsx로 해도 무방 - 팀컨벤션에 따를 것)

그리고 이 UserInfo.tsx에만 사용되는 components들은 아래처럼 따로 분리한다.

또한, 해당 페이지를 만들기위해 사용되는 style, type, utils, hook 등도 필요하면 분리한다.

(style, type 등의 파일이 커지기 전에는 filename.style.tsx 이런식의 네이밍을 가지고 있다)

자, 이제 만약에 UserInfo.tsx에서 사용하는 UserName컴포넌트가 있는데, 이 컴포넌트가 매우 복잡해서 분리가 필요한 상황이라고 생각해보자. 그러면 아래와 같이 구분할 수 있다.

components안의 UserName.tsx임에도 그안에 components 폴더명이 반복된다. 프랙탈 구조가 나오게 되는 것이다

여기서 우리는 UserFirstName.tsx파일이 user-name폴더 안에서만 영향력이 있다는것을 명확히 알 수 있다.

그렇다면 공용 컴포넌트는 어떻게 관리할 수 있을까?

중요한건 이 폴더구조의 원리만 알고있으면 된다. 바로 최상위에 components를 만들면 된다.
폴더의 위치가 곧바로 그 폴더의 영향력과 1:1 매핑이 되므로 최상위의 components 폴더는 당연히 공용 shared의 역할을 할 수 있다.

해당 components는 특정 도메인이 아닌, 공용에서관리되는 얘들만 존재하게 된다. 만약 특정 도메인이나 페이지에서 사용되는 공용 컴포넌트라면, 그 안에 분리해야 한다.

당연히 공용 컴포넌트도 비대해지면 분리할 수 있다.

자! 이제 마지막으로 이 구조를 유지한 복잡한 폴더 구조를 봐보자. (GPT가 일을 참 잘하는 것 같다)

만약 당신이 이 대시보드 프로젝트의 관리자고, header의 api호출에 문제가 생겼다고 생각하면, 어느 파일을 보면 될까?

header.service.ts 파일을 보면된다. 만약 header위치에 service폴더가 없다면, 그 상위폴더로 올라가면서 탐색하면 된다.

또한 영향범위를 알기 때문에 개발자는 쉽게 header.service.ts 파일을 수정할 수 있을 것이다.

상위의 파일일수록, 개발자는 사이드 이팩트를 생각하면서 수정하게 되니 잠재적인 버그도 막을 수 있다.

정리

물론 이 폴더구조가 FE폴더구조의 정답이라고 생각하지 않는다. 애초에 정답이 없는 문제기도 하고, 모든 프로젝트마다 그에 어울리는 폴더구조는 다르다고 생각한다.

이 구조도 단점이 있다 ㅎㅎ. 만약에 "파일의 영향력"이라는 룰을 위반하는 파일들이 나타나면, 오히려 추적하는게 어려울 수도 있고 많은 depth에 의해 혼란이 가중될 수 있다. 꼼꼼한 관리가 필요한 폴더구조이다.

그럼에도 지금까지는 장점이 많은 구조라 생각한다.

1. 자유도 : 컨벤션, 폴더의 분류 등을 각 프로젝트 상황에 맞게 얼마든지 커스터마이징할 수 있다.

2. 영향력 : 파일의 영향도를 알기 때문에 사이드이팩트를 미리 예측할 수 있다.

3. 접근성 : 개발자가 어떤 기능을 구현/수정하는 경우 어디를 확인해야할 지 바로 파악이 가능하다.

4. 위치 고민 : 해당 파일을 언제 분리할지, 어디에 위치시킬지에 대한 고민을 줄여줄 수 있다.

프랙탈 폴더구조보다 다이소 폴더구조가 더 친근한거 같기도 하다 ㅎㅎ

AI에 MCP로 날개달기 (Cursor + MCP로 깃,노션 등 연동하기)

정_민_규 — Sun, 13 Apr 2025 17:14:58 +0900

요즘은 AI를 쓰고 안쓰고에 따라서 개발 생산성이 사람마다 천지차이로 나는 것 같다.

최근에 커서를 알게 된 이후로, VSCODE는 내 컴퓨터에서 거의 fade-out 되기 직전이다.

https://www.cursor.com/

Cursor - The AI Code Editor

Built to make you extraordinarily productive, Cursor is the best way to code with AI.

www.cursor.com

커서?

VSCODE를 포크떠서 만든 에디터로, 코파일럿처럼 IDE 내에서 AI를 사용할 수 있다.

월 20달러 (GPT 유료플랜이랑 동일)한 가격으로 이용할 수 있다.

개인적으로 코파일럿보다 매우매우 똑똑한 친구라고 생각한다. 내 프로젝트의 구조를 전반적으로 알고있기도 하고, 특히 미리 내가 할 일을 예측해서 도와주는 생산성이 말이 안된다.

간단한 예시로 내가 A파일에서 export하는 함수이름과 사용방식을 다 바꿨을 때, 탭 몇번 누르다보면 A의 함수를 쓰고있는 다른 파일들도 다 변경된다. 단순히 이름을 바꾸는게 아니라, 사용방식에 따라 다 바꿔진다.

사실 커서의 편리함은 말보다는 직접 체감하는게 빠르다고 생각한다. 2주동안은 커서 유료플랜을 무료로 체험할 수 있으니 한번 해보는걸 권장한다 ㅎㅎ

MCP?

아래 유튜브가 설명이 잘 되어있다.

https://www.youtube.com/watch?v=oAxunD8k0C8&t=397s

현재 대부분 개발자들이 AI를 접해본 경험이 있다. MCP는 AI에게 손을 달아주는 역할을 해준다.

결과론적으로 아래와 같은 일을 AI에게 시킬 수 있다.

"내가 최근에 작업한 PR 목록을 가져오고 정리해줘"
"[PR링크] 이 PR에 대해 리뷰해줘"
"지금 내가 이 브랜치에서 작업 한 내용을 가지고 PR을 만들어서 깃헙에 올려줘"
"지금 내가 보고있는 파일을 명세서 형식으로 노션에 정리해줘"
"[피그마 링크] 이 피그마 대로 기본적인 JSX 템플릿을 짜줘"

즉, AI의 결과물이 단순히 특정 Text에 국한되는게 아니라 AI에게 특정 도구들의 사용법을 연결해서 일을 시킬 수 있다. (앞으론 무얼 먹고 살아야 하는가)

심지어 대부분 유명한 툴들 (git, notion, figma, 등등..)은 이미 MCP가 다 만들어져 있다.

아래 사이트에서 만들어져 있는 MCP Protocol을 가져와서 연결하기만 하면된다.

https://smithery.ai/

Smithery - Model Context Protocol Registry

Enable AI agents to seamlessly interact with VS Code, enhancing their capabilities to modify files, open projects, and check extension statuses. Streamline your development workflow by integrating AI assistance directly into your coding environment. Experi

smithery.ai

예를 들어서 git을 연결해보자. MCP는 커서에 국한된 프로토콜은 아니므로 코파일럿, 클루드 등등 다 가능하지만 나는 커서를 예를들어서 설명을 해보겠다.

Cursor - preference - cursor setting - MCP

여기에 + Add new global MCP server를 누른 후, 만들어진 json파일에 정보를 추가하기만 하면 끝난다.

json정보는 방금 올린 Smithery 페이지에서 얻을 수 있다. 예를들어 git을 검색해 보자.

제일 다운로드 많은 github

많은 사람들이 사용한 프로토콜을 사용해보자.

로그인을 안했다면 로그인을 진행해주고, github PersonalAccessToken을 깃헙에 가서 다운받아준다.

github - profile - setting - developer setting - perseonal access token (classic) - generate new token(classic) - ( 권한은 자유롭게 repo정도 풀어주면 좋다. )

이후 발급받은 토큰을 넣고 connect해주고 json 탭을 보면 복사할 수 있는 값이 나온다.

밑은 토큰 부분이라 잘랐습니다

이 값을 커서 세팅의 mcp.json에 넣고, 커서를 재부팅하기만 하면 연결된다.

똑~같은 방법으로 지라, 노션들의 툴에도 적용이 가능하다. 아래는 지라를 연동한 후에 간단한 질문을 해본 결과이다.

간단한 질문을 해본거지만 내코드베이스를 바탕으로 지라이슈를 생성하거나 정리하여 노션이나 위키 등에 정리해주는 작업도 가능하다.

특히 Figma는 디자인을 활용해 템플릿도 만들어준다..

끄읏 -!

[FrontEnd] MFA(Micro Frontend Architecture) 란?!

정_민_규 — Sat, 8 Mar 2025 17:02:03 +0900

알면 좋은 배경지식

먼저 MFA는 MSA(Microservices Architecture) 의 프론트엔드 버전이다.

MSA이란?

- 커다란 하나의 모노리스 백엔드를 작은 서비스로 나누고 각 서비스는 느슨하게 결합되고 독립적으로 배치 가능한 서비스

말은 어렵지만.. 쉽게 생각해서 엄청나게 큰 프로젝트가 모놀리식하게(한개의 레포에서) 관리된다면 어떤 일이 발생할까?

한 프로젝트에 위와 같이 3개의 도메인이 존재한다고 생각해보자. 더 쉬운 이해를 위해, 각 도메인마다 팀이 존재한다고 생각해보자.

A팀에서 작업한 A도메인의 API만 변경되어도 전체의 배포 시나리오를 동작시켜야 한다. 그렇기 때문에 각팀의 배포 시나리오를 항상 맞춰야 하고, 각 팀의 독립성이 떨어지게 된다.

이를 위해 각 도메인 별 배포를 독립적으로 챙길 수 있게 환경을 구축하고 팀별로 도메인을 관리 한다면 독립성이 보장되게 된다. ( 그 외에도 백엔드에서 MSA를 적용하는 다양한 이유가 있겠지만 나는 프론트엔드 개발자라 아직 거기까진 파악하지 못했다 ㅠ )

MFA

MFA는 위에서 간략히 설명한 MSA구조를 프론트엔드에도 적용한 것을 말한다. 일반적인 경우, MFA를 도입한 프로젝트는 많지않다.

모든 기술이 그렇지만 MFA의 경우 왜 사용해야 하는지, 어떤 방식으로 적용되는지를 정확하게 알고 적용해야 하는것이 중요하다!

왜, 언제 MFA를 적용해야하는지를 설명하기 전에 MFA 구조에 대해 먼저 간략하게 이해해보자.

아래와 같은 구조의 페이지가 하나 있다고 생각해보자.

pagename/some-content

해당 페이지엔 B팀이 작업하는 주요 영역인 컨텐츠 영역이 존재한다. 또한 사이트의 전반적으로 들어가는 공지영역과 챗봇 영역이 존재하고, 각 영역은 A팀과 C팀이 해당 부분을 맡고 있다.

보통 프론트엔드 프로젝트는 한 곳에서 관리되는 경우가 많기 때문에, MSA를 소개할 때 발생했던 문제점들이 똑같이 발생하게 된다.

- 각 팀의 배포시점에 의존적이게 된다.

- 각 팀의 기술스택이 서로 의존되어 있어 새로운 기술을 도입하거나 기존 기술의 버전업이 어렵다.

만약 A,B,C팀이 사용하는 백엔드 팀에서의 MSA가 도입되어 있다면 현 상황을 아래처럼 도식화할 수 있다.

만약 프론트엔드에서도 각 팀이 배포독립성을 가질 수 있게 된다면 어떤 이점이 있을까?

만약 MSA구조를 Frontend에 도입하여 각 영역마다 배포독립성을 가지게 된다면 아래와 같이 된다.

만약 공지영역의 API가 변경되어서 그에대한 작업을 했다면, A도메인과 공지영역에 그 변경점을 반영하여 배포하면 된다.

기존 잘 동작하는 B,C도메인과 그 화면들은 신경쓸 필요가 없고, 각팀의 일정과 작업주기에 맞춰 각자 배포를 진행하면 된다.

장점

- 가장 큰 장점은 각 팀의 배포 독립성을 챙길 수 있다는 점이다.

- 각 팀이 자신의 프로젝트를 관리하게 되므로, 기술스택 버전업이나 선택 등에서 자유롭다.

물론 지금 예시는 한 페이지에서 여러 도메인의 영역이 합쳐진 복잡한 케이스를 가지고 이야기했지만 실제로 위와같은 케이스는 많지 않을 수 있다. 오히려 페이지별로 담당하는 도메인이 다른 경우 좀더 직관적이고 쉽게 MFA구조를 가져갈 수 있다.

단점

- 각팀의 독립성이 너무 커지면 공통영역에 대한 결합력이 약해져 같은 프로젝트로 사용자에게 인식되지 않을 수 있다. ( 각 팀마다 UI가 많이 달라진다던지.. )

- 공통영역에 대한 중복개발이 늘어날 수 있다. ( 폰트변경과 같은 전체 영역의 설정이 바뀌는 경우, 모두 바꿔줘야 함 )

MFA 구현 방법

백엔드와는 다르게 프론트엔드에서는 명확한 화면이 존재한다. 그렇다면 어떻게 한 화면 내의 다른 프로젝트들을 조합할 수 있을까?

이를 구현하기 위한 방법은 정말 다양한데, 하나씩 알아보자!

Ajax를 활용한 조합

가장 간단한 방법은 템플릿을 받아서 JS로 조합하는 방법이다.

JS의 Fetch를 이용하여 다른 서버에서 HTML을 받아오고, 이를 화면에서 조합하는 방식이다.

다른 서버의 리소스를 가져오지만, 동일 문서 내에서 실행되기 때문에 자연스럽다.

단 UI가 네트워크에 의존적이게 되며 스타일과 스크립트 격리에 주의해야 한다.

만약 가져온 HTML에 스크립트가 있는 경우 화면단의 스크립트와 연결하기 위한 별도의 작업이 필요하다.

당연하지만 네트워크 환경에 따라 깜박임이 발생할 수밖에 없다.

서버에서 Proxy를 이용한 페이지 분리

사용자의 요청을 서버에서 받고, 그에 맞는 리소스를 서버가 내려주는 형태이다.

Nginx를 이용한 Reverse Proxy Server가 일반적인 형태라 도입이 용이함
- 각팀이 다른 도메인을 사용하는것은 완전히 같은 서비스라는 인식을 주지 않을 수 있다. ( UX 적으로 좋지 않을 수 있음 )
- Location의 path로 구별되는 서버라는것을 인지하고 SPA를 사용하여 각자 구축하는 경우 주의해야 함.
- 팀간 이동시에 하드링크기 때문에 깜박임이 존재할 수 있음. 단, 팀간 확실한 분리가 보장된다.

Web Component

프론트엔드를 통제하는 중앙 shell에서 각 팀이 만든 bundle을 합쳐서 조합하는 형태이다.

https://developer.mozilla.org/ko/docs/Web/API/Web_components

웹 컴포넌트 - Web API | MDN

웹 컴포넌트는 그 기능을 나머지 코드로부터 캡슐화하여 재사용 가능한 커스텀 엘리먼트를 생성하고 웹 앱에서 활용할 수 있도록 해주는 다양한 기술들의 모음입니다.

developer.mozilla.org

- 웹 컴포넌트에 대한 이해가 필요하지만 이는 웹 표준이기때문에 장점이 있다.

- 여러 생명주기 메서드를 오버라이드가 가능한데, 이를 활용하면 리액트나 뷰로 만든 bundle들을 조합하여 페이지를 구성하는것도 가능하다.

- 아직 shadow DOM을 지원하지 않는 브라우저가 있을 수 있다.

Iframe을 이용한 결합

iframe을 활용하여 클라이언트에서 통합하는 방식으로, 현재도 많은곳에서 사용된다.

특히 iframe은 오래전부터 사용했기 때문에 구형 브라우저에서도 사용이 가능하다.

iframe내 컨텐츠는 다른 브라우저 컨텍스트를 생성하기 때문에 강력하게 격리되는데 이는 장점이자 단점이 된다. 각 팀의 독립성은 유지되지만, 중앙 shell과 통신을 해야하는 경우 postMessage와 같은 추가적인 작업이 필요하다.

Module Federation 을 통한 결합

webpack5에서 소개된 고급 모듈 통합 기능으로 모노레포 환경에서 여러 JS 애플리케이션 코드를 동적으로 공유할 수 있게 해준다. 타 방식과는 다르게 기존 코드베이스를 변경할 필요가 없다.

애초에 MFA를 목적으로 만든 기능으로, 각 어플리케이션이 독립적으로 개발&배포 되면서도 공통영역에 대한 고민점을 덜어줄 수 있는 기술이다.

이 역시 계속 들었던 예시를 보자면, A,B,C 팀이 모두 React를 사용한다고 생각해보자. 만약 iframe을 사용하여 이들을 결합한다면 3개의 브라우저는 모두 독립적이기 때문에 공유하는 라이브러리와 리소스 모두 별개로 받아와서 로딩하게 된다.

Module Federation의 Shared기능을 활용하면 A,B,C팀이 모두 사용하는 라이브러리를 한번만 로딩하여 나눠서 쓰게 하는것이 가능하다.

해당 Module Federation을 잘 활용하면 각 팀의 독립성과 공통영역에 대한 문제를 해결할 수 있다.

최근에는 Webpack뿐 아니라 vite등과 같은 최신 번들러에서도 Module Federation을 지원한다.

MFA, 언제 적용해야 하는가?

사실 본 게시글은 MFA를 "어떻게" 구현하는지에 대해 초점이 맞춰져 있지 않다. MFA가 "무엇"인지와 "왜" 사용해야 하는지에 대해 초점이 맞춰져 있다.

그렇다면 MFA는 어떤 경우에 적용해야 할까?

위에서 계속 서술했듯, MFA는 장점만 있는 구조가 아니다. 성능적으로는 당연히 여러 모듈을 런타임에서 조합하는 MFA방식이 좋을 수가 없다. 또한 각 팀의 공통영역에 대한 고민도 해야한다. Module Federation을 사용한다면, 그 기술에 대한 모든 팀원들이 이해도도 높아야 한다.

한 프로젝트 내에서 다양한 팀이 독립적으로 개발을 진행하다보면 공통 UI에 대한 가이드가 분명 필요한데, 따라서 디자인시스템의 도입또한 자연스럽게 고려해야 한다. 반복되지만 MFA는 최신기술이라서가 아닌, 꼭 필요해 의해 도입되어야 한다.

1. 프로젝트의 규모가 커서 여러 팀의 효과적인 프로젝트 관리가 필요한 경우

2. 공통 영역에 대한 처리가 가능한 경우 ( 디자인시스템, 중복작업에 대한 리소스 등 )

3. 백엔드 구조가 MSA구조라 MFA구조를 도입한 경우, 기능에 따른 효율적인 배포 시나리오를 가져갈 수 있는 경우

3번에 대해서 조금 더 부가 설명을 하자면, MFA가 적용된 아래 구조에선 배포 시나리오 측면에서 장점이 있다.

만약 공지 영역, 챗봇 영역에 신규기능이 추가되었다고 생각해보자.

공지 영역은 4주, 챗봇 영역이 6주 정도 걸린다 생각할 때, 각 팀은 다른 팀의 작업 흐름을 생각할 필요가 없게 된다.

조금 더 나아가서, 해당 회사의 팀 구조를 BE/FE가 아닌, A도메인/B도메인/C도메인으로 나눌수도 있다!

이게 https://micro-frontends.org/ 에서 설명하는 End-to-End 팀 개념이다.

micro-frontends.org/

끄읏 -!

2024 회고

정_민_규 — Tue, 31 Dec 2024 21:56:51 +0900

정말 오랜만에 블로그에 글을 쓰는 것 같습니다.

취직하고 바쁘기도 했고, 블로그 글쓰기도 시간이 애매했던 것 같은데 ( 배부른 소리 )

그래도 올해도 되돌아보고 내년을 준비하면서 올 한해 있었던 일들을 한번씩 생각해보려고 합니다.

1월~3월

졸업도 하고, 현실적으로 현재 취업시장의 어려움을 깨달은 시기였던 것 같습니다. 인생 첫 면접을 봐보기도 하고 이곳 저곳 지원도 하고 떨어지기도 하면서 위기감을 많이 느꼈던 것 같아요.

그럼에도 JS,React에 대한 공부를 조금 더 깊게 하면서 이 길이 내 길이구나, 많이 생각했던 시기 같습니다.

1년여간 했던 학원일도 이때쯤 그만뒀었네요,

학원강사를 하면서 느꼈던건, 누군가한테 내가 아는 지식을 알려주는건 참 재미있는 일이라는 점. 그러면서 참 많은 책임감이 드는 일이란 것이었습니다.

많진 않지만 돈도 벌면서 생활하는데 지장은 없었기에, 또 많이 나태했던 시기였던 것 같기도 합니다.

많이 부족한데 눈만 높아서 네카라쿠배당토 등등... 지원만 하면 붙을 줄 알고 지원을 많이 안했던 시기기도 합니다. 솔직히 나름 잘한다고 생각했는데 떨어질까봐 많이 겁이 났던것도 같아요.

이 시기에 많이 도움을 줬던건 역시 여자친구 아닐까 싶습니다. 저는 항상 제가 생각하는 기준치까지 도달하기 전에는 도전을 안하려는 못된 습관이 있었는데, 일단 도전을 해보면서 생각을 해보라는 저에게 참 잘 넣어주었던 것 같습니다.

덕분에 면접, 서류에서 많이 깨지기도하고, 이력서,포폴을 다시쓰는 과정에서 정말 많이 성장했던 것 같아요. (멘탈적으로나, 기술적으로나 )

3~6월

이무렵에는 여러 회사들과 부캠들을 가리지 않고 지원했던 것 같습니다. 운이 좋은건지 나쁜건지 소프트웨어 마에스트로 과정에 합격했습니다.

아, 네이버 공채도 이때 지원했네요!

소마를 진행하면서 살면서 첫 자취도 해보게 되었는데 그 방이 참 인상깊네요.

말이 자취지 사실상 고시원같은 방이었는데, 소마 활동을 역삼역에서 해서 고시원 위치가 조선호텔 바로 앞이었거든요.

항상 소마에서 개발마치고, 집에 돌아와서 작은 창문으로 조선호텔이 보였는데 언젠가 좋은 곳에 취직하면 저런 호텔에서도 하루쯤 잘 수 있으려나, 하는 생각을 하고 했던 것 같습니다.

소마 활동을 하며 만난 팀원들, 멘토님들은 1~3월에 가졌던 제 낡은 마인드를 많이 바꿔주었던 것 같습니다. 비록 소마에서 개발자체는 많이 하지 못했지만, 개발을 좋아하는 많은 사람들을 만나면서 개발자로의 꿈이 점점 좋아졌던 시기인 것 같습니다.

소마를 시작하고 나서는 해당 활동에 집중하고 싶어 취직활동을 병행하진 않았습니다. 다만 소마에 들어가기전에 지원했었던 과정들만 진행했는데 네이버 인턴, 삼성 SDS, 네이버 공채 이 세개만 남은 상황이었어요

네이버 인턴, 삼성 SDS 면접들을 먼저 보고 마지막으로 네이버 공채 면접을 보게 되었는데 이게 참 저에겐 행운인 것 같아요.

가장 가고싶던 기업의 면접을 마지막으로 볼 수 있었고, 소마 멘토님들께 많은 조언을 받아 좋은 결과가 있었다고 생각합니다.

친구들도 많이 취직을 했고, 불안감도 분명 많았던 시기라 다시 돌아가고 싶지는 않네요 ㅋㅋ

7~12월

하반기에는 네이버 공채에 합격해서 새로 자취방도 옮기고, 회사에 적응하느라 바빴던 것 같습니다. 예전부터 취업하면 꼭 하고싶던 취미인 클라이밍도 이때부터 본격적으로 시작했네요.

클라이밍에 너무 빠져서 회사 클라이밍 회사 클리이밍 반복하다가 여자친구한테 혼도나고..

너무 무리했는지 얼마전에 클라이밍 하다가 어깨가 탈골되서 지금은 잠깐 쉬고 있습니다. ( 1.1일부터 할 생각입니다 )

회사에 들어가서 느낀건..

전 아직도 많이 부족하단거였습니다.

저에게 주어진 일을 하면서 정말 많이 고민을 하면서 일을 하고 있는데, 스스로를 자책하기도 하고 뿌듯해하기도 하면서 회사에 적응하고 있습니다.

음.. 그래도 제가 생각하던 개발자의 삶을 살고 있는 것 같습니다.

블로그를 처음 쓸 때, 개발자를 택한 이유가 재미있기 때문이었는데 밥벌이가 된 지금도 개발이 재밌는 것 같아서 참 행운이라 생각하고 있습니다. 출근해서 퇴근까지 시간이 정말정말 빠르게 잘 가는것 같아요 ( 하는거에 비해 잘가서 문제긴 하지만.. )

그리고 저를 항상 성장시켜주는 여자친구가 네이버 인턴도 붙어서 우연치 않게(?) 사내커플을 경험중인데요, 같이 회사에서 밥도 먹고 그런게 참 신기하면서도 재밌는 것 같습니다 ㅎㅎ. 항상 고맙다고 생각해요

개인적으로는 7~12월 회사에 다닌 6개월 가량동안 성장 수치가 지난 2년여간 개발공부를 한 기간보다 성장수치가 높다고 생각합니다. 더 열심히 하고 많은 경험치를 쌓아서 언젠간 저도 꼭 다른 사람에게도 도움이 되는 사람이 되고 싶네요

내년?

내년엔 다시 블로그글을 조금씩 써보려고 합니다. 이전까지는 박리다매 느낌으로 글들을 양산했다면, 앞으로는 자주쓰진 못하더라도 블로그에서 찾기 힘든 주제들에 대해서 꽤 높은 퀄리티로 글을 써보고 싶다는 욕심은 있습니다.

클라이밍도 더 열심히 할 것같아요. 얼마전에 동기한테 개발자들은 성과중독자같다는 말을 들은적이 있는데 ... ㅋㅋ... 맞는 것 같습니다.

클라이밍은 헬스와 다르게 레벨과 성과가 눈에 확실히 보여서 훨씬 재밌는 것 같습니다. 내년엔 아마 개발과 클라이밍에 미쳐 살것 같네요.

결론은 음.. 더 많이 고민하고 더 재밌게 내년도 보내고 싶네요~!

[Front] 2024 네이버 공채 합격

정_민_규 — Sat, 15 Jun 2024 12:21:13 +0900

어떤 말로 시작해야 할진 모르겠지만.. 결과부터 말하자면 2024년도 네이버 공채에 당당하게 합격했습니다!!

네이버는 정말 예전부터 가고 싶었던 기업이기도 하고 꼭 붙어서 후기를 써보고 싶었는데 현실이 되서 너무 기쁘네요. 간략하게나마 어떻게 채용 프로세스가 진행되었는지 회고를 해보려 합니다.

서류 & 코딩 테스트

네이버는 서류 & 코테 결과를 한번에 줍니다! 두가지를 어느정도 다 보는 것 같아 한쪽이 부족해도 충분히 커버할 수 있는 구조 같아요

자기소개서에는 제가 실제로 겪었던 항목들을 많이 적었던 것 같아요. 프로젝트를 진행하며 있었던 일, 왜 웹 프론트엔드를 지망하게 되었는지, 어떻게 공부를 했는지 충분히 고민하고 솔직하게 적으려 노력했던거 같습니다.

자기소개서와 더불어서 제가 운영하고 있는 블로그와 포트폴리오를 제출했습니다. 사실 학벌이 엄청 좋지도 않고 영어도 못하고 자격증도 없어서 다른 대단한 분들에 비해서 서류는 큰 점수를 받지는 못했을 거 같아요

대신 저는 코딩테스트는 잘 보았던 것 같습니다 ㅎㅎ..

코딩테스트로 3문제가 나왔는데 중간쯤부터 화장실이 너무 급하더군요 ( 커피를 마셔서 그런가 ) 추가적인 검토는 생리적 이슈 때문에 못했지만 문제는 빠르게 다 풀고 30분정도 남기고 나왔던 기억이 있어요.

나중에 보니 다른 분들은 우선순위 큐를 활용해서 문제를 해결하신 분들이 많았는데 저는 JS를 써서 풀어서 그런가 누적합, 투포인터를 활용해서 풀었습니다.

아마 서류 & 코딩테스트 통합으로 보기 때문에 해당 과정을 합격할 수 있었던 것 같습니다.

기술 면접

코딩테스트를 잘 보았던 덕분인지 기술 역량 인터뷰에 참여할 수 있게 되었습니다.

사실 지금까지 면접을 4~5번정도 보았지만 모두 떨어졌던 저한테 네이버 기술면접이란 부분은 꽤나 공포로 다가왔던 것 같습니다.

지금 소프트웨어 마에스트로를 하고 있기도 해서 소마 활동을 하며 틈틈히 계속 기술 인터뷰를 준비했습니다.

따로 면접 스터디를 준비하거나 하진 않았지만 이전부터 조금씩 모아두었던 기술 질문들에 대해서 복기를 많이 했던 것 같습니다.

특히 저는 프론트엔드 개발자지만 분명 다른 부분의 개발자 분들이 제 면접을 볼 수 있다 생각했고 제 포트폴리오에도 풀스택으로 개발을 해본 경험이 존재하기 때문에 해당 부분에도 질문이 들어올 수 있다고 생각했습니다.

따라서 CS도 어느정도는 준비하고 특히 http, 서버 관련해서 백엔드로 일하고 있는 친구의 도움을 받아서 준비를 했습니다.

실제로 기술면접때 타 분야의 개발자 분들도 들어오셨습니다. 라이브코딩, 회사에 대한 질문, 서버, JS관련 질문 등등 70분 정도 되는 시간 내내 다양한 질문을 받았고 대답했습니다.

라이브코딩은 2문제 정도 받았고 난이도는 그렇게 높지는 않았습니다. (실버 정도??) 첫번째 문제는 충분히 잘 풀어냈는데 두번째 문제에서 정말 긴장했는지 충분히 풀만한 문제임에도 뭔가 코드가 안써내려지는? 기분을 받았던거 같습니다 ㅋㅋ

계속 멘탈을 붙잡고 충분히 풀 수 있는 문제라고 스스로를 다독이며 문제를 풀어냈던 것 같아요.

특히 서버쪽으로 꽤나 깊게 질문을 주셔서 애썼던 것 같습니다. 프론트 개발자임을 어느정도 감안해주셨지만 그래도 대답의 퀄리티 자체는 높지 않았던 것 같아요.

DNS, CDN, 로드밸런서 등등 웹페이지의 구동 방식에 대해서 여러가지 질문을 받았고 그에 대답했습니다.

어차피 어떤 질문이 들어올지 모르지만 결국 내 포트폴리오, 자기소개서에서 질문이 나오기 때문에 해당 부분을 준비하는것이 가장 중요할 것 같습니다.

사실 기술적으로 많이 털렸다고 생각해서 2차면접까지 크게 기대를 못했습니다. 사실 거의 떨어졌다고 생각하고 있기도 했고 좋은 경험했다고 생각하며 소마 센터에서 활동을 하고 있었는데

덜컥 2차에 붙어버렸습니다 ㅋㅋ.. 지금 생각하면 프론트 개발자임에도 여러 경험을 한걸 좋게 봐주셨던거 같아요 ( 리액트 파해치기, 풀스택 개발, 라즈베리파이로 웹서버 구축 ) 특히 라즈베리파이로 직접 low레벨 웹서버를 구축해보았던 경험을 좋게 봐준게 크지 않을까.. 싶습니다.

종합 역량 인터뷰

이때부턴 사실 면접 준비? 라고 할게 별로 없었습니다. 2주만에 기술적으로 제가 크게 성장하는 것은 물리적으로 불가능하다고 생각했고 내가 아는것을 솔직하게 말하는 거에 집중하자 라는 생각뿐이었습니다.

2차 인터뷰는 정말 정보가 없었습니다. 기술 100%, 기술50%인성50%, 인성 100% 사람마다 천차만별인거 같았습니다. 그렇기에 더 내가 아는것을 솔직하게 말하고, 나란 사람이 어떤 사람인지 후회없이 말하자. 에 집중했던 것 같습니다.

특히 소마 멘토님들이 참 많이 도움이 되었던 것 같습니다.

결국 종합면접까지 갔다는 것은 충분히 회사에서 뽑을 수 있는 역량이 된 사람이니 너무 걱정하지말고 회사에 맞추려 하지말고 내 스탠스를 그대로 유지하면 좋은 결과가 나올 것이다. "Be My Self" 라고 이야기를 해주셨는데 면접보기 직전까지도 혼자 저 단어를 외치면서 마인드를 잡았던 것 같습니다 ㅎㅎ. ( 감사합니다 멘토님 ㅎㅎ )

다른 멘토님께서도 모의면접을 봐주셨는데 정말 날카롭게 봐주셨습니다. 해당 멘토님도 제 솔직함은 칭찬해 주셨으나 지원동기 부분에 대해서 조금 생각을 많이 안해본 것 같다고 말씀을 해주셨습니다.

당연히 네카라쿠배의 네잖아..!

생각해보니 네이버에 가고싶었던 이유야 정말 많았지만 이를 잘 표현하는걸 준비를 안했다고 생각했습니다. 이부분을 면접 전날까지도 잘 못정해서 끙끙대고 있었는데 여자친구와 통화를 하며 깨달음을 얻을 수 있었고 왜 내가 네이버에 정말 가고싶었는지 생각해보았던 것 같습니다.

1. 네이버가 한국 IT기업중 인정받는 기업인건 누구나 알고 훌륭한 동료들과 함께 실력으로 인정받는 개발자가 되고싶다.

2. 네부캠 할때 가보았던 사옥의 분위기가 너무 좋았고 개발자들의 모습이 너무 부러웠다.

3. 블로그를 즐겨쓰는 입장에서 네이버 D2 는 너무 잘쓴 글이 많고 나도 꼭 글을 써서 기여하고 싶다.

4. 여러 글, 기사를 보면 다른 어떤 기업보다 개발자의 성장을 지원하고 있는 회사임이 느껴진다. 개발자의 성장 === 회사의 성장으로 보는 회사같다.

위 4가지 정도를 정리할 수 있었습니다.

2차 면접은 저같은 경우는 80~90% 정도는 인성면접 위주로 진행되었고 저는 제가 고민했었던 협업과 관련된 이야기들을 많이 풀어냈던 것 같습니다. 지금 생각해보면 질문을 잘 유도했던 것 같아요. 확실히 압박면접이었고 특정상황을 주시고 꼬리에 꼬리를 무는 질문이 계속 나와서 조금은 탈탈 털린 느낌이 들었습니다 ㅠㅠ

지원동기 관련 질문을 받았을때는 속으로 아주 좋아했습니다! ㅋㅋㅋ 정리했던 내용들을 차분하게 잘 말했고 네이버에 대한 제 진심(?)을

충분히 잘 전해드린거 같다는 생각은 했습니다.

면접 마지막쯤에는 개발과 상관없는 인성질문이 몰아쳐서 대답을 잘 못했던 것 같습니다. 분명 면접관님 의도는 파악이 되었는데 대답하기가 어려웠거든요 ㅠㅠ

50분정도의 짧다면 짧고 길다면 긴 시간이 끝나고 든 첫 감정은 후련함 이었던 것 같습니다. 사실 어느정도 마음고생도 하고 긴장도 되었는데 그래도 면접을 통해 충분히 "Be My Self" 했단 생각은 들었던것 같습니다.

최종 발표 대기

지금생각해도 이 시기가 정말 힘들었던 것 같습니다. 3개월조금 넘게 걸리는 긴 채용프로세스때문에 힘든것도 있지만 10분마다 면접때 잘 못말했던 부분이 생각나서 떨어진거 같기도 하고 붙은거 같기도 하고..

해당 시간은 정말 어쩔 수 없었던 것 같아요. 저는 소마 활동에 더 집중하면서 시간을 보냈던 것 같습니다.

특히 발표 몇일전에 뭘 잘못먹었는지 장염이 걸려서 골골대기도 하고.. 이렇게 인생에서 제일 긴 3주가량을 보내고..

처음에 올렸던 해당 화면을 보게 되었습니다! 인천으로 가는 버스에서 문자를 받고 해당 화면을 봤는데 처음에는 잘 안믿겨서 손이 덜덜 떨렸던 기억이 납니다. 그래도 이게 끝이라고는 생각 안합니다. 면접 때 말한 "네이버에 가서 기여를 할 수 있는 개발자"는 아직 안된거니까 좋은 기회를 받았다 생각하고 열심히 해보려 합니다.

정리?

글을 쓰면서 생각이 든건 참 많은 사람들에게 도움을 받은 것 같습니다. 자기소개서를 쓸때부터 면접준비까지 내 일보다 더 내 일같이 생각해준 소중한 여자친구, 여러가지 마인드셋과 정보를 주신 멘토님들, 백엔드 관련 면접대비를 도와준 친구, 소마 탈주(?)임에도 도와준 팀원들 등등 항상 혼자 개발했던 제게 소중한 사람들의 도움을 통해서 달성한 성과 같아 정말 감사하다고 말하고 싶습니다 ㅎㅎ

신나서 친구들 단톡방에도 올렸더니

지금 시기가 개발자로 취업하기 정말 힘든시기란걸 저도 알고 있기에 더 기적같은 기회가 왔다고 생각합니다.

다른 회사 지원들은 다떨어졌는데 어떻게 제일 가고싶던 기업에 합격했는지 아직도 얼떨떨하지만 이런말은 기억에 남는것 같습니다.

가장 가고싶은 기업의 면접을 가장 마지막에 볼 수 있는건 행운이다. 라는 말을 들었는데 맞는거 같단 생각을 했습니다. 아무것도 모르는 채로 면접을 봤다면 합격하진 못했을 것 같아요.

유일한 합격이 네이버, 소마

이렇게 긴 회고를 작성해 본적 처음이라 마무리를 어떻게 지내야 할 지 모르겠지만..!

저는 앞으로도 지금처럼 살아보려 합니다! 이 글을 보는 많은 개발자 취준생 분들도 꼭 좋은 결과 있었으면 진심으로 좋겠습니당

끄읏 -!

[JS] blocking과 sync는 다르다!

정_민_규 — Wed, 12 Jun 2024 15:36:42 +0900

자바스크립트는 non-blocking single thread 언어라고들 한다.

싱글 스레드임에도 멈추지 않고 비동기 지원이 되기 때는데, 이때 이벤트루프를 통해 이를 해결한다.

그렇다면 blocking-sync , non-blocking-async 개념은 같다고 볼 수 있을까?

마냥 그렇다고는 할 수 없다.

차이점

빠르게 결론부터 알아보자.

Blocking

- A함수가 B함수를 호출한 경우 B 함수의 작업종료 전까지 A함수에게 제어권을 주지 않는 것

Non-blocking

- A함수가 B함수를 호출한 경우 B함수가 제어권을 A에게 바로 주어 A함수가 바로 일을 할 수 있는 것

Sync

- A함수가 B함수를 호출한 경우 B함수 결과를 A가 처리하는 것

Async

- A함수가 B함수를 호출한 경우 B함수 결과를 B가 처리하는 것

물론 Blocking - sync , non-blocking-async가 비슷한 개념이긴 하다. 익숙한 개념을 아래 그림을 통해서 이해해보자.

https://homoefficio.github.io/2017/02/19/Blocking-NonBlocking-Synchronous-Asynchronous/

해당 부분은 익숙한 경우일 것이다. 대부분의 케이스가 아래 두가지 케이스로 작동된다.

Blocking - sync

A함수가 B를 호출한 경우 Blocking 상태이기 때문에 A는 작업을 할 수 없다. 또한 Sync이기 때문에 B함수의 결과를 A가 처리해야 하기 때문에 반환이 일어난 후에 A는 B의 결과를 받아 작업을 이어나가게 된다.

Non-blocking - async

A함수가 B를 호출한 경우에도 Non-blocking 상태이기 때문에 A의 작업은 진행된다. 또한 B 함수의 결과는 B가 처리하기 때문에 A와 B가 별도로 진행되게 된다.

Non-Blocking - async

A함수에서 B를 호출한 경우 Non-blocking 상태이기 때문에 B가 호출되어도 A는 계속해서 진행된다. 다만 B의 결과를 A에서 처리해야 하기 때문에 위 그림처럼 B의 작업이 완료되었는지 확인하는 과정이 필요하다.

Blocking - async

마지막이다. A가 B함수를 호출한 경우 Blocking 상태이기에 A의 작업은 멈추지만 B함수의 결과또한 B가 처리하기 때문에 그냥 B의 작업이 끝나면 A가 작동되는 경우이다.

구동 자체는 blocking-sync와도 유사해 보인다.

어쩌면 당연하지만 굳이 blocking-async 방식으로 프로그램을 설계할 필요는 없을 것 같다. 하지만 nonblcoking-async로 구현한 프로그램중에서 blocking으로 작동하는 함수가 하나라도 있다면 해당 부분에선 blocking-async으로 작동되는 경우가 있다.

결론

결론을 짓자면 blocking & non-blocking은 "제어권"까지 함수에게 넘기냐 안넘기냐가 중요한 포인트고

sync-async는 호출된 함수의 결과를 스스로 처리하는지 호출한 함수에서 처리하는지가 중요하다.

조금더 쉽게 이해하자면!

blocking - nonblocking : 요청에 대해 받은 쪽에서 처리가 끝나기 전에 리턴해주는가?

sync-async : 요청한 함수의 순서가 지켜지는가?

비슷한듯? 다른 용어였다.

[ Front ] Zustand 상태관리 라이브러리

정_민_규 — Mon, 10 Jun 2024 22:22:46 +0900

zustand는 최근 많이 인기가 올라온 전역상태 관리 라이브러리이다!!

최근 1년 사용량에 비해서도 jotai나 recoil에 비해서 많은 다운로드 수를 자랑하는 것을 확인할 수 있다.

특히 기간을 조금 더 늘려 보았을 때 현재 가장 성장세가 가파른 것을 확인할 수 있다.

재밌는 점은 zustand만든사람이 jotai까지 만들었다고 한다!

zustand <- 독일어로 "상태"

jotai <- 일본어로 "상태"

두 라이브러리의 차이는 아래 개발자가 직접 설명을 잘해 주었다.

https://github.com/pmndrs/jotai/issues/13

How is jotai different from zustand? · Issue #13 · pmndrs/jotai

Name Jotai means "state" in Japanese. Zustand means "state" in German. Analogy Jotai is close to Recoil. Zustand is close to Redux. Where state resides Jotai state is within React component tree. Z...

github.com

간단 하게만 설명하자면 jotai는 recoil에 좀 더 가깝고, zustand는 redux에 더 가깝다고 한다.

zustand의 장점

zustand는 우선 굉장히 쉽고 가볍다. 바닐라 자바스크립트 기준 핵심 로직이 42줄밖에 안된다고 한다.

또한 redux와 유사한것 처럼 redux devtool또한 사용이 가능하며 상태 변경 시 불필요한 리렌더링을 일으키지 않도록 제어하기 쉽다고 한다.

zustand는 redux와 같은 flex 패턴을 사용한다. ( 단방향 데이터 흐름을 지닌다 )

이제 document를 보면서 직접 사용해보자!

https://docs.pmnd.rs/zustand/getting-started/introduction

Zustand Documentation

Zustand is a small, fast and scalable bearbones state-management solution, it has a comfy api based on hooks

docs.pmnd.rs

먼저 vite를 활용해서 간단한 리액트 프로젝트 하나를 만들어주자.

npm init vite

이후 로컬 서버를 열어주자.

npm i
npm run dev

이제 npm을 활용해서 zustand를 설치해주자.

npm install zustand

zustand의 store는 훅으로 되어있다! 즉 따로 Provider를 감싸주는 작업 자체가 필요가 없다.

따라서 아래와 같이 store란 폴더를 하나 만들고, 훅의 규칙에 따라서 파일을 만들어보자.

공식문서에 따라서 아래 내용을 적어보자.

//useTestStore.ts

import { create } from "zustand";

export const useTestStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
  updateBears: (newBears) => set({ bears: newBears }),
}));

redux와 똑같이 상태가 있고 그 상태를 제어할 수 있는 액션들이 적혀있는 것을 확인할 수 있다.

이제 App.tsx 파일을 아래와 같이 작성해보자.

import "./App.css";
import { useTestStore } from "../store/useTestStore";

function App() {
  const increasePopulation = useTestStore((state) => state.increasePopulation);
  const bears = useTestStore((state) => state.bears);

  return (
    <>
      <h1>{bears} around here...</h1>
      <button onClick={increasePopulation}>one up</button>
    </>
  );
}

export default App;

전역상태 라이브러리와 같이 값을 가져오는 것도 가능하며, 액션을 통해서 상태관리의 값을 업데이트 하는 것 또한 가능하다.

실제로 동작도 잘 된다!

특히 사용법이 너무 쉽고 적용하기가 쉽다는 장점이 있는 것 같다.

타입스크립트를 적용하기 위해선 아래와 같이 타입 설정을 해주면 된다.

import { create } from 'zustand'

interface BearState {
  bears: number
  increase: (by: number) => void
}

const useBearStore = create<BearState>()((set) => ({
  bears: 0,
  increase: (by) => set((state) => ({ bears: state.bears + by })),
}))

[React] react에서 next처럼 라우팅하기

정_민_규 — Tue, 28 May 2024 12:23:17 +0900

https://github.com/zoubingwu/vite-plugin-next-react-router

GitHub - zoubingwu/vite-plugin-next-react-router: A Next.js style routing vite plugin for react.

A Next.js style routing vite plugin for react. Contribute to zoubingwu/vite-plugin-next-react-router development by creating an account on GitHub.

github.com

리액트에서도 next와 같은 폴더구조 기반 라우팅을 할 수 있는 플러그인이 있다.

react-router-dom 기반이기 때문에 아래와 같이 두가지 패키지를 설치해준다.

npm i vite-plugin-next-react-router
npm i react-router-dom

vite.config.js 에 아래와 같은 내용을 추가해준다.

//vite.config.js
import reactRouterPlugin from 'vite-plugin-next-react-router';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    //...
    reactRouterPlugin(),
  ],
});

main.ts에 아래와 같이 BrowserRouter를 감싸준다.

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.tsx";
import "./index.css";
import { BrowserRouter } from "react-router-dom";

ReactDOM.createRoot(document.getElementById("root")!).render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>
);

이후 아래와 같이 src파일 안에 pages 파일을 만들면 폴더구조별로 자동으로 라우팅이 된다.

[JS] 행렬과 연산

정_민_규 — Fri, 3 May 2024 11:08:15 +0900

Deque를 활용하여 해결하였다.

https://school.programmers.co.kr/learn/courses/30/lessons/118670

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

문제 자체는 단순했다. 행렬을 밑으로 밀어내거나 시계방향으로 회전하는 기능을 구현하면 되었다.

단, 시간복잡도를 생각해야 하는 문제이다.

행렬을 밑으로 밀어내는 것 자체는 어렵지 않다. Deque로 쉽게 구현할 수 있다.

시계방향으로 회전하는 기능또한 Deque로 구현할 수 있다.

이 두가지를 동시에 할 수 있게 하기 위해 Deque를 아래와 같이 조금은 특이하게 구조를 잡아보았다.

파란색으로 되어 있는 부분을 Deque라고 생각하였다.

즉 왼쪽,오른쪽 열을 Deque로 두고 가운데 부분을 2중 Deque를 사용하였다.

이 경우 회전이나 아래로 미는 것 모두 행렬의 한 행이나 열을 모두 탐색할 필요도 없기에 시간초과를 할 수 있다!

좀 어려운 점은 JS는 Deque가 지원을 안해줘서 만들어서 구현해야 하기에 귀찮았다.

class Node{
    constructor(val){
        this.val = val
        this.prev = null
        this.next = null
    }
}

//Deque 구현
class Deque{
    constructor(){
        this.head = null
        this.tail = null
        this.size = 0
    }
    
    push(node){
        this.size ++
        if(this.head===null){
            this.head = node
            this.tail = node
            return
        }
        this.tail.next = node
        node.prev = this.tail
        this.tail = node
        
    }
    
    pushLeft(node){
        this.size ++
        if(this.head===null){
            this.head = node
            this.tail = node
            return
        }
        this.head.prev = node
        node.next = this.head
        this.head = node
    }
    
    pop(){
        const ret = this.tail
        if(this.size===0) return
        if(this.size===1){
            this.head = null
            this.tail = null
            this.size = 0
            return ret
        }
        this.tail.prev.next = null
        this.tail = this.tail.prev
        this.size--
        return ret
    }
    
    popLeft(){
        const ret = this.head
        if(this.size===0) return
        if(this.size===1){
            this.head = null
            this.tail = null
            this.size = 0
            return ret
        }
        
        this.head.next.prev = null
        this.head = this.head.next
        this.size --
        return ret
    }
}



function solution(rc, operations) {
    
    const leftCol = new Deque()
    const rightCol = new Deque()
    const center = new Deque()
    
    //Deque로 변환
    for (const ary of rc){
        leftCol.push(new Node(ary[0]))
        rightCol.push(new Node(ary[ary.length-1]))
        const centerNode = new Deque()
        for (const arr of ary.slice(1,ary.length-1)){
            centerNode.push(new Node(arr))
        }
        center.push(new Node(centerNode))
    }
    
    const shiftRow = () => {
        leftCol.pushLeft(leftCol.pop())
        rightCol.pushLeft(rightCol.pop())
        center.pushLeft(center.pop())
    }
    
    const rotate = () => {
        center.head.val.pushLeft(leftCol.popLeft())
        rightCol.pushLeft(center.head.val.pop())
        center.tail.val.push(rightCol.pop())
        leftCol.push(center.tail.val.popLeft())
    }
    
    
    for (const operation of operations){
        if (operation === "Rotate") rotate()
        else shiftRow()
    }
    
    //Deque -> Array 변환
    const ret = []
    for (let i = 0 ; i < rc.length ; i++){
        const tmp = []
        tmp.push(leftCol.popLeft().val)
        const nums = center.popLeft().val
        while(nums.head){
            tmp.push(nums.popLeft().val)
        }
        tmp.push(rightCol.popLeft().val)
        ret.push(tmp)
    }
    
    return ret
    
}

[JS] 매출하락 최소화 (2021 카카오)

정_민_규 — Tue, 30 Apr 2024 14:40:29 +0900

tree + dp로 해결할 수 있는 문제였다.

https://school.programmers.co.kr/learn/courses/30/lessons/72416

프로그래머스

programmers.co.kr

트리구조와 DP를 활용하면 해결할 수 있는 문제이다.

문제를 처음 읽었을때의 생각은 선택을 했거나, 안했거나를 나누어서 계산을 하는 거였다.

(결과적으로 완전 틀린 접근은 아니었음)

다만 완전탐색으로 이를 해결하기에는 300,000명까지 사원이 있기에 불가능 했다. 주의를 둘 점은 트리구조이기 때문에 1번노드에서 단방향으로 퍼져나가는 구조라고 생각할 수 있다는 것이다.

DP 를

[ 해당 버튼을 누른 경우 최소 매출 , 해당 버튼을 누르지 않은 경우 최소 매출 ]

이라고 생각해보자.

1 ) 뿌리 노드인 경우

뿌리 인 경우 무조건 [ 해당 노드의 매출 , 0 ] 이 되게 된다.

2) 뿌리노드 X

해당 경우는 자식 노드들의 dp값중에서 최솟값들의 합을 취하면된다.

[ 해당노드의 매출 + 자식 노드들의 매출의 최솟값들의 합 , 자식 노드들의 매출의 최솟값들의 합 ]

조금 이상한 부분이 있을 것이다. 문제에서 한 팀에서 1명의 사람은 무조건 뽑아야 한다는 규칙이 있다.

따라서 자식 노드들 중에서 최솟값들을 더했을때 선택이 안된경우, 자식 노드들 중에서 적어도 한개는 선택을 해줘야 한다.

이 때, 선택을 해주었을때의 최솟값이 아닌 증가량을 기준으로 가장 적게 매출이 증가하는 노드를 선택해줘야 한다. 이 경우에는

[ 해당노드의 매출 + 자식 노드들의 매출의 최솟값들의 합 , 자식 노드들의 매출의 최솟값들의 합 + 자식노드를 하나 선택했을때의 증가량 ]

가 된다.

예시를 들어서 보자!

[ , ]

[ , ] [ , ]

먼저 DP를 비워주고 뿌리 노드들을 채워보자.

[ , ]

[ , ] [3,0]

[4,0] [5,0]

(2,6) 노드를 채우기 위해서는 먼저 자식 노드의 최솟값들의 합을 봐야한다.

이는 0이다. 즉 [ 6 , a] 까지는 채울 수 있다. a는 2번 노드를 선택하지 않았을때를 가정하는 것이므로 가장 매출 증가량이 적게 되는 5번 노드를 선택한다.

[ , ]

[6,4] [3,0]

[4,0] [5,0]

루트 노드 또한 같은 방식으로 계산해보자.

루트노드를 선택 -> 4 + 0 + 5 = 11

루트노드 선택 X

0 -> 3은 3의 매출이 더 필요하고

4 -> 6은 2의 매출이 더 필요하기에 버튼을 선택한다면 왼쪽 자식을 선택해야 함

[11,6]

[6,4] [3,0]

[4,0] [5,0]

이 되어서 루트노드 2개중 최솟값인 6이 답이 된다.

function solution(sales, links) {
    sales = [0,...sales] // 회사원 수 인덱스랑 맞추기
    
    const childs = [...Array(sales.length)].map(_=>[])
    for (const [s,e] of links){
        childs[s].push(e)
    }
    
    //return [parent를 누른 경우, parent를 안누른 경우]
    const getPoint = parent => {
        if(!childs[parent].length) return [sales[parent],0]
        let isSelect = false
        let curPoint = 0
        
        // 자식들을 통해 눌러도 되는 point와 아닌 포인트 계산
        const childPoints = []
        for (const child of childs[parent]){
            const [pushPoint,noPushPoint] = getPoint(child)
            
            if(pushPoint <= noPushPoint){
                isSelect = true
                curPoint += pushPoint
            } else {
                curPoint += noPushPoint
            }
            childPoints.push([pushPoint,noPushPoint])
        }
        
        // 자식에서 선택이 한명도 안된 경우
        if(!isSelect){
            let minDiff = Infinity
            for (const [pp,npp] of childPoints){
                minDiff = Math.min(minDiff,pp-npp)
            }
            return [sales[parent] + curPoint, curPoint + minDiff]
        }
        return [sales[parent]+curPoint,curPoint]
    }
    
    return Math.min(...getPoint(1))
}